From xen-devel-bounces@lists.xen.org Sat Nov 01 01:05:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 01:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkN7k-000709-8p; Sat, 01 Nov 2014 01:05: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@citrix.com>) id 1XkN7j-000704-3d
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 01:04:59 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	99/BD-23358-9B134545; Sat, 01 Nov 2014 01:04:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1414803895!12347573!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29688 invoked from network); 1 Nov 2014 01:04:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 01:04:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188454421"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 31 Oct 2014 21:04:24 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkN7A-0006Uo-IU;
	Sat, 01 Nov 2014 01:04:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkN7A-0006Ba-7E;
	Sat, 01 Nov 2014 01:04:24 +0000
Date: Sat, 1 Nov 2014 01:04:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31284-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8263
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31284: 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: multipart/mixed; boundary="===============5453763665648915562=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5453763665648915562==
Content-Type: text/plain
Content-Length: 7990
Content-Transfer-Encoding: quoted-printable

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              720be2eb5f0216564d158dca99c466fac2c16a53
baseline version:
 libvirt              9babbaa5fe38a433cef759a930e49d8291f040a8

------------------------------------------------------------
People who touched revisions under test:
  Jim Fehlig <jfehlig@suse.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Luyao Huang <lhuang@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Roman Bogorodskiy <bogorodskiy@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3D720be2eb5f0216564d158dca99c466fac2c16a53
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 720be2eb5f0216564d158dca99c466fac2c16a53
+ branch=3Dlibvirt
+ revision=3D720be2eb5f0216564d158dca99c466fac2c16a53
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 720be2eb5f0216564d158dca99c466fac2c16a53:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   9babbaa..720be2e  720be2eb5f0216564d158dca99c466fac2c16a53 -> xen-tested-master


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

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

--===============5453763665648915562==--

From xen-devel-bounces@lists.xen.org Sat Nov 01 01:05:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 01:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkN7k-000709-8p; Sat, 01 Nov 2014 01:05: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@citrix.com>) id 1XkN7j-000704-3d
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 01:04:59 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	99/BD-23358-9B134545; Sat, 01 Nov 2014 01:04:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1414803895!12347573!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29688 invoked from network); 1 Nov 2014 01:04:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 01:04:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188454421"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 31 Oct 2014 21:04:24 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkN7A-0006Uo-IU;
	Sat, 01 Nov 2014 01:04:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkN7A-0006Ba-7E;
	Sat, 01 Nov 2014 01:04:24 +0000
Date: Sat, 1 Nov 2014 01:04:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31284-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8263
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31284: 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: multipart/mixed; boundary="===============5453763665648915562=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5453763665648915562==
Content-Type: text/plain
Content-Length: 7990
Content-Transfer-Encoding: quoted-printable

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              720be2eb5f0216564d158dca99c466fac2c16a53
baseline version:
 libvirt              9babbaa5fe38a433cef759a930e49d8291f040a8

------------------------------------------------------------
People who touched revisions under test:
  Jim Fehlig <jfehlig@suse.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Luyao Huang <lhuang@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Roman Bogorodskiy <bogorodskiy@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3D720be2eb5f0216564d158dca99c466fac2c16a53
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 720be2eb5f0216564d158dca99c466fac2c16a53
+ branch=3Dlibvirt
+ revision=3D720be2eb5f0216564d158dca99c466fac2c16a53
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 720be2eb5f0216564d158dca99c466fac2c16a53:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   9babbaa..720be2e  720be2eb5f0216564d158dca99c466fac2c16a53 -> xen-tested-master


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

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

--===============5453763665648915562==--

From xen-devel-bounces@lists.xen.org Sat Nov 01 04:23:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 04:23:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkQD2-0007SE-7c; Sat, 01 Nov 2014 04:22:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkQD1-0007S9-7V
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 04:22:39 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	73/E2-31453-E0064545; Sat, 01 Nov 2014 04:22:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1414815756!8827986!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18124 invoked from network); 1 Nov 2014 04:22:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 04:22:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188477417"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 00:22:34 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkQCw-0007RO-Fp;
	Sat, 01 Nov 2014 04:22:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkQCv-0008Vg-1h;
	Sat, 01 Nov 2014 04:22:33 +0000
Date: Sat, 1 Nov 2014 04:22:33 +0000
Message-ID: <E1XkQCv-0008Vg-1h@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [seabios bisection] complete
	test-amd64-amd64-xl-winxpsp3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-winxpsp3
test windows-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  seabios git://git.seabios.org/seabios.git
  Bug introduced:  99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Bug not present: 46000f5608a0ed1156463218f49d33044c4df843


  commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Author: Kevin O'Connor <kevin@koconnor.net>
  Date:   Tue Oct 21 14:34:06 2014 -0400
  
      Do full BREGS backup/restore for pmm, pnp, and irqentry_extrastack
      
      Although these entry points only require backup and restore of the
      registers that the C code clobbers, there is no harm in backing up
      some additional registers.  This allows the BREGS macros to be used
      which makes the code a little more readable.
      
      Signed-off-by: Kevin O'Connor <kevin@koconnor.net>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.seabios.test-amd64-amd64-xl-winxpsp3.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31253 fail [host=rice-weevil] / 30767 ok.
Failure / basis pass flights: 31253 / 30767
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 6688825c240586708129df8887ad9b12a1708497
Basis pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#d7892a4c389d54bccb9bce8e65eb053a33bbe290-d7892a4c389d54bccb9bce8e65eb053a33bbe290 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#c9d8f8b755e8960edf7725e05f3e6ac743a5e12e-c9d8f8b755e8960edf7725e05f3e6ac743a5e12e git://git.seabios.org/seabios.git#bfb7b58b30681f5c421e838fdef3dbc358e80f1e-136d4ec190af616bb4fa8624dd9c648e5c9e0d2a git://xenbits.xen.org/xen.git#4d57153b52a36183d58e8de6ba613929f906386a-6688825c240586708129df8887ad9b12a1708497
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 2001 nodes in revision graph
Searching for test results:
 30761 pass irrelevant
 30767 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
 31223 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 6688825c240586708129df8887ad9b12a1708497
 31274 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 283ae1f07949c463cbba0b8cd20f703a8c1389b6 6688825c240586708129df8887ad9b12a1708497
 31299 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 6688825c240586708129df8887ad9b12a1708497
 31302 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 6688825c240586708129df8887ad9b12a1708497
 31281 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e f4b1dbc9ac47d24a644462c91c5fb1514da3829b 6688825c240586708129df8887ad9b12a1708497
 31303 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 6688825c240586708129df8887ad9b12a1708497
 31265 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
 31304 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 6688825c240586708129df8887ad9b12a1708497
 31269 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 6688825c240586708129df8887ad9b12a1708497
 31253 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 6688825c240586708129df8887ad9b12a1708497
 31286 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 78c42e504c4a93cc5802415ae5e4f69534e6c0fd 6688825c240586708129df8887ad9b12a1708497
 31272 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 54a1c6d629b7aafe52974a2a9f5c8cf3a3780413 8878d01936594d2b6a4366bc7be191edbc546aa8
 31291 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 6688825c240586708129df8887ad9b12a1708497
 31295 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 6688825c240586708129df8887ad9b12a1708497
Searching for interesting versions
 Result found: flight 30767 (pass), for basis pass
 Result found: flight 31223 (fail), for basis failure
 Repro found: flight 31265 (pass), for basis pass
 Repro found: flight 31269 (fail), for basis failure
 0 revisions at d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 6688825c240586708129df8887ad9b12a1708497
No revisions left to test, checking graph state.
 Result found: flight 31291 (pass), for last pass
 Result found: flight 31295 (fail), for first failure
 Repro found: flight 31299 (pass), for last pass
 Repro found: flight 31302 (fail), for first failure
 Repro found: flight 31303 (pass), for last pass
 Repro found: flight 31304 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  seabios git://git.seabios.org/seabios.git
  Bug introduced:  99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Bug not present: 46000f5608a0ed1156463218f49d33044c4df843

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Author: Kevin O'Connor <kevin@koconnor.net>
  Date:   Tue Oct 21 14:34:06 2014 -0400
  
      Do full BREGS backup/restore for pmm, pnp, and irqentry_extrastack
      
      Although these entry points only require backup and restore of the
      registers that the C code clobbers, there is no harm in backing up
      some additional registers.  This allows the BREGS macros to be used
      which makes the code a little more readable.
      
      Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

Revision graph left in /home/xc_osstest/results/bisect.seabios.test-amd64-amd64-xl-winxpsp3.windows-install.{dot,ps,png,html}.
----------------------------------------
31304: tolerable ALL FAIL

flight 31304 seabios real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31304/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-winxpsp3  7 windows-install         fail baseline untested


jobs:
 test-amd64-amd64-xl-winxpsp3                                 fail    


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

Logs, config files, etc. are available at
    http://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 Nov 01 04:23:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 04:23:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkQD2-0007SE-7c; Sat, 01 Nov 2014 04:22:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkQD1-0007S9-7V
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 04:22:39 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	73/E2-31453-E0064545; Sat, 01 Nov 2014 04:22:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1414815756!8827986!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18124 invoked from network); 1 Nov 2014 04:22:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 04:22:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188477417"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 00:22:34 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkQCw-0007RO-Fp;
	Sat, 01 Nov 2014 04:22:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkQCv-0008Vg-1h;
	Sat, 01 Nov 2014 04:22:33 +0000
Date: Sat, 1 Nov 2014 04:22:33 +0000
Message-ID: <E1XkQCv-0008Vg-1h@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [seabios bisection] complete
	test-amd64-amd64-xl-winxpsp3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-winxpsp3
test windows-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  seabios git://git.seabios.org/seabios.git
  Bug introduced:  99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Bug not present: 46000f5608a0ed1156463218f49d33044c4df843


  commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Author: Kevin O'Connor <kevin@koconnor.net>
  Date:   Tue Oct 21 14:34:06 2014 -0400
  
      Do full BREGS backup/restore for pmm, pnp, and irqentry_extrastack
      
      Although these entry points only require backup and restore of the
      registers that the C code clobbers, there is no harm in backing up
      some additional registers.  This allows the BREGS macros to be used
      which makes the code a little more readable.
      
      Signed-off-by: Kevin O'Connor <kevin@koconnor.net>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.seabios.test-amd64-amd64-xl-winxpsp3.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31253 fail [host=rice-weevil] / 30767 ok.
Failure / basis pass flights: 31253 / 30767
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 6688825c240586708129df8887ad9b12a1708497
Basis pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#d7892a4c389d54bccb9bce8e65eb053a33bbe290-d7892a4c389d54bccb9bce8e65eb053a33bbe290 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#c9d8f8b755e8960edf7725e05f3e6ac743a5e12e-c9d8f8b755e8960edf7725e05f3e6ac743a5e12e git://git.seabios.org/seabios.git#bfb7b58b30681f5c421e838fdef3dbc358e80f1e-136d4ec190af616bb4fa8624dd9c648e5c9e0d2a git://xenbits.xen.org/xen.git#4d57153b52a36183d58e8de6ba613929f906386a-6688825c240586708129df8887ad9b12a1708497
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 2001 nodes in revision graph
Searching for test results:
 30761 pass irrelevant
 30767 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
 31223 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 6688825c240586708129df8887ad9b12a1708497
 31274 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 283ae1f07949c463cbba0b8cd20f703a8c1389b6 6688825c240586708129df8887ad9b12a1708497
 31299 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 6688825c240586708129df8887ad9b12a1708497
 31302 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 6688825c240586708129df8887ad9b12a1708497
 31281 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e f4b1dbc9ac47d24a644462c91c5fb1514da3829b 6688825c240586708129df8887ad9b12a1708497
 31303 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 6688825c240586708129df8887ad9b12a1708497
 31265 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
 31304 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 6688825c240586708129df8887ad9b12a1708497
 31269 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 6688825c240586708129df8887ad9b12a1708497
 31253 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 6688825c240586708129df8887ad9b12a1708497
 31286 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 78c42e504c4a93cc5802415ae5e4f69534e6c0fd 6688825c240586708129df8887ad9b12a1708497
 31272 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 54a1c6d629b7aafe52974a2a9f5c8cf3a3780413 8878d01936594d2b6a4366bc7be191edbc546aa8
 31291 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 6688825c240586708129df8887ad9b12a1708497
 31295 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 6688825c240586708129df8887ad9b12a1708497
Searching for interesting versions
 Result found: flight 30767 (pass), for basis pass
 Result found: flight 31223 (fail), for basis failure
 Repro found: flight 31265 (pass), for basis pass
 Repro found: flight 31269 (fail), for basis failure
 0 revisions at d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 6688825c240586708129df8887ad9b12a1708497
No revisions left to test, checking graph state.
 Result found: flight 31291 (pass), for last pass
 Result found: flight 31295 (fail), for first failure
 Repro found: flight 31299 (pass), for last pass
 Repro found: flight 31302 (fail), for first failure
 Repro found: flight 31303 (pass), for last pass
 Repro found: flight 31304 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  seabios git://git.seabios.org/seabios.git
  Bug introduced:  99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Bug not present: 46000f5608a0ed1156463218f49d33044c4df843

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Author: Kevin O'Connor <kevin@koconnor.net>
  Date:   Tue Oct 21 14:34:06 2014 -0400
  
      Do full BREGS backup/restore for pmm, pnp, and irqentry_extrastack
      
      Although these entry points only require backup and restore of the
      registers that the C code clobbers, there is no harm in backing up
      some additional registers.  This allows the BREGS macros to be used
      which makes the code a little more readable.
      
      Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

Revision graph left in /home/xc_osstest/results/bisect.seabios.test-amd64-amd64-xl-winxpsp3.windows-install.{dot,ps,png,html}.
----------------------------------------
31304: tolerable ALL FAIL

flight 31304 seabios real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31304/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-winxpsp3  7 windows-install         fail baseline untested


jobs:
 test-amd64-amd64-xl-winxpsp3                                 fail    


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

Logs, config files, etc. are available at
    http://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 Nov 01 08:13:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 08: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 1XkToL-0001iz-08; Sat, 01 Nov 2014 08:13:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkToJ-0001iu-DK
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 08:13:23 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	52/1D-27785-22694545; Sat, 01 Nov 2014 08:13:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1414829600!7288697!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28427 invoked from network); 1 Nov 2014 08:13:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 08:13:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187142262"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 04:13:18 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkToE-00008I-R8;
	Sat, 01 Nov 2014 08:13:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkToC-0003Ef-EW;
	Sat, 01 Nov 2014 08:13:16 +0000
Date: Sat, 1 Nov 2014 08:13:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31280-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31280: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 26303
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303
 test-amd64-i386-xl-qemuu-winxpsp3 12 guest-localmigrate.2 fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 01 08:13:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 08: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 1XkToL-0001iz-08; Sat, 01 Nov 2014 08:13:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkToJ-0001iu-DK
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 08:13:23 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	52/1D-27785-22694545; Sat, 01 Nov 2014 08:13:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1414829600!7288697!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28427 invoked from network); 1 Nov 2014 08:13:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 08:13:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187142262"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 04:13:18 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkToE-00008I-R8;
	Sat, 01 Nov 2014 08:13:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkToC-0003Ef-EW;
	Sat, 01 Nov 2014 08:13:16 +0000
Date: Sat, 1 Nov 2014 08:13:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31280-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31280: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 26303
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303
 test-amd64-i386-xl-qemuu-winxpsp3 12 guest-localmigrate.2 fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 01 09:13:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 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 1XkUkE-0002Fl-Ta; Sat, 01 Nov 2014 09:13:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkUkE-0002Fg-0o
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 09:13:14 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	56/C5-11581-924A4545; Sat, 01 Nov 2014 09:13:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1414833190!7757610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18413 invoked from network); 1 Nov 2014 09:13:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 09:13:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187147050"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 05:12:42 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkUji-0000QS-1Q;
	Sat, 01 Nov 2014 09:12:42 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkUjg-0007C1-Au;
	Sat, 01 Nov 2014 09:12:40 +0000
Date: Sat, 1 Nov 2014 09:12:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31288-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31288: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 30594
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail REGR. vs. 30574
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 30594

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Sat Nov 01 09:13:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 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 1XkUkE-0002Fl-Ta; Sat, 01 Nov 2014 09:13:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkUkE-0002Fg-0o
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 09:13:14 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	56/C5-11581-924A4545; Sat, 01 Nov 2014 09:13:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1414833190!7757610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18413 invoked from network); 1 Nov 2014 09:13:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 09:13:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187147050"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 05:12:42 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkUji-0000QS-1Q;
	Sat, 01 Nov 2014 09:12:42 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkUjg-0007C1-Au;
	Sat, 01 Nov 2014 09:12:40 +0000
Date: Sat, 1 Nov 2014 09:12:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31288-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31288: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 30594
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail REGR. vs. 30574
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 30594

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Sat Nov 01 11:25:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 11:25:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkWnR-0003JU-DT; Sat, 01 Nov 2014 11:24:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkWnP-0003JP-D1
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 11:24:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0F/85-09842-6F2C4545; Sat, 01 Nov 2014 11:24:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1414841076!4780216!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10194 invoked from network); 1 Nov 2014 11:24:37 -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;
	1 Nov 2014 11:24:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188519470"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 07:24:34 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkWnJ-00013f-TD;
	Sat, 01 Nov 2014 11:24:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkWnJ-0005L7-Dg;
	Sat, 01 Nov 2014 11:24:33 +0000
Date: Sat, 1 Nov 2014 11:24:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31282-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 10854
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31282: 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: multipart/mixed; boundary="===============5951623862411973271=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5951623862411973271==
Content-Type: text/plain
Content-Length: 10594
Content-Transfer-Encoding: quoted-printable

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 31241
 test-amd64-amd64-pair         2 hosts-allocate           running [st=3Drunning!]

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                3a2f22b7d0cc64482a91529e23c2570aa0602fa6
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
People who touched revisions under test:
  Adel Gadllah <adel.gadllah@gmail.com>
  Alexandre Belloni <alexandre.belloni@free-electrons.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andriy Skulysh <askulysh@gmail.com>
  Andr=C3=A1s Mur=C3=A1nyi <muranyia@gmail.com>
  Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
  Arnd Bergmann <arnd@arndb.de>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Christian Vogel <vogelchr@vogel.cx>
  Christoph Lameter <cl@linux.com>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Streetman <ddstreet@ieee.org>
  Daniel Gl=C3=B6ckner <dg@emlix.com>
  Daniel Mack <daniel@zonque.org>
  David Rientjes <rientjes@google.com>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Dmitry Torokhov <dmitry.torokhov@gmail.com>
  Fabio Estevam <fabio.estevam@freescale.com>
  Felipe Balbi <balbi@ti.com>
  H. Nikolaus Schaller <hns@goldelico.com>
  Ian Munsie <imunsie@au1.ibm.com>
  James Morris <james.l.morris@oracle.com>
  Jan Kara <jack@suse.cz>
  Jason Gerecke <jason.gerecke@wacom.com>
  Jason Gerecke <killertofu@gmail.com>
  Jeff Kirsher <jeffrey.t.kirsher@intel.com>
  Jens Axboe <axboe@fb.com>
  Jeremy Kerr <jk@ozlabs.org>
  Jerry Hoemann <jerry.hoemann@hp.com>
  Jiri Kosina <jkosina@suse.cz>
  Joe Perches <joe@perches.com>
  Johannes Weiner <hannes@cmpxchg.org>
  Joonsoo Kim <iamjoonsoo.kim@lge.com>
  Kailang Yang <kailang@realtek.com>
  Kevin Fenzi <kevin@scrye.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Konstantin Khlebnikov <k.khlebnikov@samsung.com>
  Lars-Peter Clausen <lars@metafoo.de>
  Laurent Pinchart <laurent.pinchart@ideasonboard.com>
  Liam Girdwood <liam.r.girdwood@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Maarten ter Huurne <maarten@treewalker.org>
  Marek Belisko <marek@goldelico.com>
  Marek Szyprowski <m.szyprowski@samsung.com>
  Mark Brown <broonie@kernel.org>
  Mark Rustad <mark.d.rustad@intel.com>
  Martin K. Petersen <martin.petersen@oracle.com>
  Martin Schwidefsky <schwidefsky@de.ibm.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael L. Semon <mlsemon35@gmail.com>
  Michal Hocko <mhocko@suse.cz>
  Mikulas Patocka <mpatocka@redhat.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Minchan Kim <minchan@kernel.org>
  Ming Lei <tom.leiming@gmail.com>
  Nathan Fontenot <nfont@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
  Olivier Gay <ogay@logitech.com>
  Paul Cercueil <paul@crapouillou.net>
  Pavel Machek <pavel@denx.de>
  Pavel Machek <pavel@ucw.cz>
  Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
  Pranith Kumar <bobby.prani@gmail.com>
  Richard Weinberger <richard@nod.at>
  Riku Voipio <riku.voipio@linaro.org>
  Robert Elliott <elliott@hp.com>
  Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
  Stanimir Varbanov <svarbanov@mm-sol.com>
  Sudip Mukherjee <sudip@vectorindia.org>
  Sudip Mukherjee <sudipm.mukherjee@gmail.com>
  Takashi Iwai <tiwai@suse.de>
  Takashi Sakamoto <o-takashi@sakamocchi.jp>
  Tomi Valkeinen <tomi.valkeinen@ti.com>
  Tony Battersby <tonyb@cybernetics.com>
  Vlastimil Babka <vbabka@suse.cz>
  Wang Nan <wangnan0@huawei.com>
  Weijie Yang <weijie.yang@samsung.com>
  Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
  Yu Zhao <yuzhao@google.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary

broken test-amd64-amd64-pair hosts-allocate running

Not pushing.

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


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

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

--===============5951623862411973271==--

From xen-devel-bounces@lists.xen.org Sat Nov 01 11:25:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 11:25:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkWnR-0003JU-DT; Sat, 01 Nov 2014 11:24:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkWnP-0003JP-D1
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 11:24:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0F/85-09842-6F2C4545; Sat, 01 Nov 2014 11:24:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1414841076!4780216!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10194 invoked from network); 1 Nov 2014 11:24:37 -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;
	1 Nov 2014 11:24:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188519470"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 07:24:34 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkWnJ-00013f-TD;
	Sat, 01 Nov 2014 11:24:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkWnJ-0005L7-Dg;
	Sat, 01 Nov 2014 11:24:33 +0000
Date: Sat, 1 Nov 2014 11:24:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31282-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 10854
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31282: 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: multipart/mixed; boundary="===============5951623862411973271=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5951623862411973271==
Content-Type: text/plain
Content-Length: 10594
Content-Transfer-Encoding: quoted-printable

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 31241
 test-amd64-amd64-pair         2 hosts-allocate           running [st=3Drunning!]

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                3a2f22b7d0cc64482a91529e23c2570aa0602fa6
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
People who touched revisions under test:
  Adel Gadllah <adel.gadllah@gmail.com>
  Alexandre Belloni <alexandre.belloni@free-electrons.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andriy Skulysh <askulysh@gmail.com>
  Andr=C3=A1s Mur=C3=A1nyi <muranyia@gmail.com>
  Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
  Arnd Bergmann <arnd@arndb.de>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Christian Vogel <vogelchr@vogel.cx>
  Christoph Lameter <cl@linux.com>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Streetman <ddstreet@ieee.org>
  Daniel Gl=C3=B6ckner <dg@emlix.com>
  Daniel Mack <daniel@zonque.org>
  David Rientjes <rientjes@google.com>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Dmitry Torokhov <dmitry.torokhov@gmail.com>
  Fabio Estevam <fabio.estevam@freescale.com>
  Felipe Balbi <balbi@ti.com>
  H. Nikolaus Schaller <hns@goldelico.com>
  Ian Munsie <imunsie@au1.ibm.com>
  James Morris <james.l.morris@oracle.com>
  Jan Kara <jack@suse.cz>
  Jason Gerecke <jason.gerecke@wacom.com>
  Jason Gerecke <killertofu@gmail.com>
  Jeff Kirsher <jeffrey.t.kirsher@intel.com>
  Jens Axboe <axboe@fb.com>
  Jeremy Kerr <jk@ozlabs.org>
  Jerry Hoemann <jerry.hoemann@hp.com>
  Jiri Kosina <jkosina@suse.cz>
  Joe Perches <joe@perches.com>
  Johannes Weiner <hannes@cmpxchg.org>
  Joonsoo Kim <iamjoonsoo.kim@lge.com>
  Kailang Yang <kailang@realtek.com>
  Kevin Fenzi <kevin@scrye.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Konstantin Khlebnikov <k.khlebnikov@samsung.com>
  Lars-Peter Clausen <lars@metafoo.de>
  Laurent Pinchart <laurent.pinchart@ideasonboard.com>
  Liam Girdwood <liam.r.girdwood@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Maarten ter Huurne <maarten@treewalker.org>
  Marek Belisko <marek@goldelico.com>
  Marek Szyprowski <m.szyprowski@samsung.com>
  Mark Brown <broonie@kernel.org>
  Mark Rustad <mark.d.rustad@intel.com>
  Martin K. Petersen <martin.petersen@oracle.com>
  Martin Schwidefsky <schwidefsky@de.ibm.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael L. Semon <mlsemon35@gmail.com>
  Michal Hocko <mhocko@suse.cz>
  Mikulas Patocka <mpatocka@redhat.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Minchan Kim <minchan@kernel.org>
  Ming Lei <tom.leiming@gmail.com>
  Nathan Fontenot <nfont@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
  Olivier Gay <ogay@logitech.com>
  Paul Cercueil <paul@crapouillou.net>
  Pavel Machek <pavel@denx.de>
  Pavel Machek <pavel@ucw.cz>
  Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
  Pranith Kumar <bobby.prani@gmail.com>
  Richard Weinberger <richard@nod.at>
  Riku Voipio <riku.voipio@linaro.org>
  Robert Elliott <elliott@hp.com>
  Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
  Stanimir Varbanov <svarbanov@mm-sol.com>
  Sudip Mukherjee <sudip@vectorindia.org>
  Sudip Mukherjee <sudipm.mukherjee@gmail.com>
  Takashi Iwai <tiwai@suse.de>
  Takashi Sakamoto <o-takashi@sakamocchi.jp>
  Tomi Valkeinen <tomi.valkeinen@ti.com>
  Tony Battersby <tonyb@cybernetics.com>
  Vlastimil Babka <vbabka@suse.cz>
  Wang Nan <wangnan0@huawei.com>
  Weijie Yang <weijie.yang@samsung.com>
  Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
  Yu Zhao <yuzhao@google.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary

broken test-amd64-amd64-pair hosts-allocate running

Not pushing.

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


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

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

--===============5951623862411973271==--

From xen-devel-bounces@lists.xen.org Sat Nov 01 13:34:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 13:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkYog-0004vm-7v; Sat, 01 Nov 2014 13:34:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkYof-0004vh-43
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 13:34:05 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	6E/B3-07724-C41E4545; Sat, 01 Nov 2014 13:34:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1414848842!11047172!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20637 invoked from network); 1 Nov 2014 13:34:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 13:34:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187175125"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 09:34:01 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkYob-0002ID-0b;
	Sat, 01 Nov 2014 13:34:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkYoa-0004u2-2k;
	Sat, 01 Nov 2014 13:34:00 +0000
Date: Sat, 1 Nov 2014 13:34:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31285-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31285: 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 31285 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31285/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl           9 guest-start                 fail pass in 31270
 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-start.2       fail pass in 31270
 test-amd64-amd64-rumpuserxen-amd64 3 host-install(3) broken in 31270 pass in 31285
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 31270 pass in 31285
 test-amd64-i386-freebsd10-amd64 10 guest-saverestore fail in 31270 pass in 31285

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31270

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-armhf-armhf-xl          10 migrate-support-check fail in 31270 never pass

version targeted for testing:
 xen                  0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
baseline version:
 xen                  0f2bde078ace619fe8e26730495b6ef2c3a2e9bf

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Sat Nov 01 13:34:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 13:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkYog-0004vm-7v; Sat, 01 Nov 2014 13:34:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkYof-0004vh-43
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 13:34:05 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	6E/B3-07724-C41E4545; Sat, 01 Nov 2014 13:34:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1414848842!11047172!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20637 invoked from network); 1 Nov 2014 13:34:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 13:34:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187175125"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 09:34:01 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkYob-0002ID-0b;
	Sat, 01 Nov 2014 13:34:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkYoa-0004u2-2k;
	Sat, 01 Nov 2014 13:34:00 +0000
Date: Sat, 1 Nov 2014 13:34:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31285-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31285: 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 31285 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31285/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl           9 guest-start                 fail pass in 31270
 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-start.2       fail pass in 31270
 test-amd64-amd64-rumpuserxen-amd64 3 host-install(3) broken in 31270 pass in 31285
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 31270 pass in 31285
 test-amd64-i386-freebsd10-amd64 10 guest-saverestore fail in 31270 pass in 31285

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31270

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-armhf-armhf-xl          10 migrate-support-check fail in 31270 never pass

version targeted for testing:
 xen                  0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
baseline version:
 xen                  0f2bde078ace619fe8e26730495b6ef2c3a2e9bf

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Sat Nov 01 16:04:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 16: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 1XkbA1-00070G-Hl; Sat, 01 Nov 2014 16:04:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkbA0-00070B-26
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 16:04:16 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	F6/5F-09284-F7405545; Sat, 01 Nov 2014 16:04:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1414857853!11050104!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4298 invoked from network); 1 Nov 2014 16:04:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 16:04:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187192490"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 12:04:12 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xkb9v-00030V-Ln;
	Sat, 01 Nov 2014 16:04:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xkb9v-0001xe-4W;
	Sat, 01 Nov 2014 16:04:11 +0000
Date: Sat, 1 Nov 2014 16:04:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31287-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31287: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            2 hosts-allocate           running [st=running!]

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt      4 xen-install             fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)    broken baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail baseline untested
 test-amd64-i386-pair          7 xen-boot/src_host       fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                4fbe40970dc154aaeeda0584aab8913fc073127b
baseline version:
 linux                a7ca10f263d7e673c74d8e0946d6b9993405cc9c

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           broken  
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

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


Push not applicable.


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

From xen-devel-bounces@lists.xen.org Sat Nov 01 16:04:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 16: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 1XkbA1-00070G-Hl; Sat, 01 Nov 2014 16:04:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkbA0-00070B-26
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 16:04:16 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	F6/5F-09284-F7405545; Sat, 01 Nov 2014 16:04:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1414857853!11050104!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4298 invoked from network); 1 Nov 2014 16:04:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 16:04:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187192490"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 12:04:12 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xkb9v-00030V-Ln;
	Sat, 01 Nov 2014 16:04:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xkb9v-0001xe-4W;
	Sat, 01 Nov 2014 16:04:11 +0000
Date: Sat, 1 Nov 2014 16:04:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31287-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31287: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            2 hosts-allocate           running [st=running!]

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt      4 xen-install             fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)    broken baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail baseline untested
 test-amd64-i386-pair          7 xen-boot/src_host       fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                4fbe40970dc154aaeeda0584aab8913fc073127b
baseline version:
 linux                a7ca10f263d7e673c74d8e0946d6b9993405cc9c

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           broken  
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

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


Push not applicable.


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

From xen-devel-bounces@lists.xen.org Sat Nov 01 17:03:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 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 1Xkc51-0007su-4m; Sat, 01 Nov 2014 17:03:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@roeck-us.net>) id 1Xkc4z-0007sp-Bi
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 17:03:09 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	E7/18-28865-C4215545; Sat, 01 Nov 2014 17:03:08 +0000
X-Env-Sender: linux@roeck-us.net
X-Msg-Ref: server-13.tower-206.messagelabs.com!1414861384!12356839!1
X-Originating-IP: [208.91.199.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20608 invoked from network); 1 Nov 2014 17:03:05 -0000
Received: from bh-25.webhostbox.net (HELO bh-25.webhostbox.net)
	(208.91.199.152)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Nov 2014 17:03:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roeck-us.net;
	s=default; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=+vyobUtl6o+NbWxalKaZXZhrn9jkKWElOVIpoJS9yKM=; 
	b=8HYClz2bG/I0l/otDvrmOcGtvH5W9XibcmFaeK9mu2Zv6n2jvucdVZJclrw+8pZdCXnHgzj34agQymeZBNwQcQnipk6PgXc57W9e/L6rBQZOJgSPNIzNlth5+oIJUp8OINfG4R14DueHoHKH/ti7UbmdXYXgZTmdn9LT4KWvnmg=;
Received: from mailnull by bh-25.webhostbox.net with sa-checked (Exim 4.82)
	(envelope-from <linux@roeck-us.net>) id 1Xkc4t-000apr-Jz
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 17:03:03 +0000
Received: from 108-223-40-66.lightspeed.sntcca.sbcglobal.net
	([108.223.40.66]:34590 helo=server.roeck-us.net)
	by bh-25.webhostbox.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128)
	(Exim 4.82) (envelope-from <linux@roeck-us.net>)
	id 1Xkc4r-000aNg-FX; Sat, 01 Nov 2014 17:03:02 +0000
Message-ID: <54551242.2020604@roeck-us.net>
Date: Sat, 01 Nov 2014 10:02:58 -0700
From: Guenter Roeck <linux@roeck-us.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Hans-Christian Egtvedt <egtvedt@samfundet.no>
References: <1412659726-29957-1-git-send-email-linux@roeck-us.net>
	<1412659726-29957-34-git-send-email-linux@roeck-us.net>
	<20141101101637.GA5765@samfundet.no>
In-Reply-To: <20141101101637.GA5765@samfundet.no>
X-Authenticated_sender: linux@roeck-us.net
X-OutGoing-Spam-Status: No, score=0.0
X-Spam-Checker-Version: spamc_ctasd client on
	localost
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=50.0 tests=SpamClass_Unknown,
	VirusClass_Unknown autolearn=disabled version=1.0.0
X-CTCH-PVer: 0000001
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-Flags: 0
X-CTCH-RefID: str=0001.0A020208.54551247.019B, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-Score: 0.001
X-CTCH-ScoreCust: 0.000
X-CTCH-Rules: C_4847,
X-CTCH-SenderID: linux@roeck-us.net
X-CTCH-SenderID-Flags: 0
X-CTCH-SenderID-TotalMessages: 15
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-TotalRecipients: 0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - lists.xenproject.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from
	get_relayhosts_entry
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: linux-m32r-ja@ml.linux-m32r.org, linux-mips@linux-mips.org,
	linux-efi@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-xtensa@linux-xtensa.org, devel@driverdev.osuosl.org,
	linux-s390@vger.kernel.org, lguest@lists.ozlabs.org,
	linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org,
	linux-sh@vger.kernel.org, linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org, Haavard Skinnemoen <hskinnemoen@gmail.com>,
	devicetree@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net,
	linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net,
	linux-m68k@lists.linux-m68k.org, linux-am33-list@redhat.com,
	linux-tegra@vger.kernel.org, openipmi-developer@lists.sourceforge.net,
	linux-metag@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
	linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [Xen-devel] [PATCH 33/44] avr32: atngw100: Register with kernel
 poweroff handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/01/2014 03:16 AM, Hans-Christian Egtvedt wrote:
> Around Mon 06 Oct 2014 22:28:35 -0700 or thereabout, Guenter Roeck wrote:
>> Register with kernel poweroff handler instead of setting pm_power_off
>> directly.
>>
>> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
>> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>
> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
>

Thanks!

Guenter


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

From xen-devel-bounces@lists.xen.org Sat Nov 01 17:03:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 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 1Xkc51-0007su-4m; Sat, 01 Nov 2014 17:03:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@roeck-us.net>) id 1Xkc4z-0007sp-Bi
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 17:03:09 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	E7/18-28865-C4215545; Sat, 01 Nov 2014 17:03:08 +0000
X-Env-Sender: linux@roeck-us.net
X-Msg-Ref: server-13.tower-206.messagelabs.com!1414861384!12356839!1
X-Originating-IP: [208.91.199.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20608 invoked from network); 1 Nov 2014 17:03:05 -0000
Received: from bh-25.webhostbox.net (HELO bh-25.webhostbox.net)
	(208.91.199.152)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Nov 2014 17:03:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roeck-us.net;
	s=default; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=+vyobUtl6o+NbWxalKaZXZhrn9jkKWElOVIpoJS9yKM=; 
	b=8HYClz2bG/I0l/otDvrmOcGtvH5W9XibcmFaeK9mu2Zv6n2jvucdVZJclrw+8pZdCXnHgzj34agQymeZBNwQcQnipk6PgXc57W9e/L6rBQZOJgSPNIzNlth5+oIJUp8OINfG4R14DueHoHKH/ti7UbmdXYXgZTmdn9LT4KWvnmg=;
Received: from mailnull by bh-25.webhostbox.net with sa-checked (Exim 4.82)
	(envelope-from <linux@roeck-us.net>) id 1Xkc4t-000apr-Jz
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 17:03:03 +0000
Received: from 108-223-40-66.lightspeed.sntcca.sbcglobal.net
	([108.223.40.66]:34590 helo=server.roeck-us.net)
	by bh-25.webhostbox.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128)
	(Exim 4.82) (envelope-from <linux@roeck-us.net>)
	id 1Xkc4r-000aNg-FX; Sat, 01 Nov 2014 17:03:02 +0000
Message-ID: <54551242.2020604@roeck-us.net>
Date: Sat, 01 Nov 2014 10:02:58 -0700
From: Guenter Roeck <linux@roeck-us.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Hans-Christian Egtvedt <egtvedt@samfundet.no>
References: <1412659726-29957-1-git-send-email-linux@roeck-us.net>
	<1412659726-29957-34-git-send-email-linux@roeck-us.net>
	<20141101101637.GA5765@samfundet.no>
In-Reply-To: <20141101101637.GA5765@samfundet.no>
X-Authenticated_sender: linux@roeck-us.net
X-OutGoing-Spam-Status: No, score=0.0
X-Spam-Checker-Version: spamc_ctasd client on
	localost
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=50.0 tests=SpamClass_Unknown,
	VirusClass_Unknown autolearn=disabled version=1.0.0
X-CTCH-PVer: 0000001
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-Flags: 0
X-CTCH-RefID: str=0001.0A020208.54551247.019B, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-Score: 0.001
X-CTCH-ScoreCust: 0.000
X-CTCH-Rules: C_4847,
X-CTCH-SenderID: linux@roeck-us.net
X-CTCH-SenderID-Flags: 0
X-CTCH-SenderID-TotalMessages: 15
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-TotalRecipients: 0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - lists.xenproject.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from
	get_relayhosts_entry
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: linux-m32r-ja@ml.linux-m32r.org, linux-mips@linux-mips.org,
	linux-efi@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-xtensa@linux-xtensa.org, devel@driverdev.osuosl.org,
	linux-s390@vger.kernel.org, lguest@lists.ozlabs.org,
	linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org,
	linux-sh@vger.kernel.org, linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org, Haavard Skinnemoen <hskinnemoen@gmail.com>,
	devicetree@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net,
	linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net,
	linux-m68k@lists.linux-m68k.org, linux-am33-list@redhat.com,
	linux-tegra@vger.kernel.org, openipmi-developer@lists.sourceforge.net,
	linux-metag@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
	linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [Xen-devel] [PATCH 33/44] avr32: atngw100: Register with kernel
 poweroff handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/01/2014 03:16 AM, Hans-Christian Egtvedt wrote:
> Around Mon 06 Oct 2014 22:28:35 -0700 or thereabout, Guenter Roeck wrote:
>> Register with kernel poweroff handler instead of setting pm_power_off
>> directly.
>>
>> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
>> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>
> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
>

Thanks!

Guenter


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

From xen-devel-bounces@lists.xen.org Sat Nov 01 17:44:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 17:44:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkciY-0008II-HA; Sat, 01 Nov 2014 17:44:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XkciX-0008ID-N9
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 17:44:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9F/8A-24532-0EB15545; Sat, 01 Nov 2014 17:44:00 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1414863840!12123017!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23529 invoked from network); 1 Nov 2014 17:44:00 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 17:44:00 -0000
Received: by mail-wg0-f54.google.com with SMTP id n12so3101344wgh.27
	for <xen-devel@lists.xenproject.org>;
	Sat, 01 Nov 2014 10:44:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=NMbNWEES+OjDByWg9iNDCQy9VwN4od8meqz7rMGs9Oc=;
	b=a6eMeznz63qiS0nsmFPTxj5QG9GMybqlohgo2LxUIzCpaE3N2hMCC/K+0gAl5uOww2
	tUwRD5SvesIVrwVETw2RUNKBY1chOEipbC/lD0st7VBlwK4/RDf7TvvMlvQcuYRbW0AY
	aV5drFUjJ/1BJb3YqDIEYhfF/z6TprDRpYCXC6WTI7rANG2SBtYw4rTdTYxKJD5J51Mi
	YOekEInLP4vDIL0j9ducQEFnuYriQYzVUVLlk+ylHBmtPKHCxpUQv1WpfN1AAukT2q2Q
	BZq56ZmSYLI7ELuiICSQKE3MQcIWBfSH3waFg84qQXW4ok5tltWrOYy/xRhk1TiizN93
	39Qg==
X-Gm-Message-State: ALoCoQkpHNe9OCZ3452NYdvFN+LIsgjYM7/QrJvWA1TvilqkGET9zbbfkacgFbObJot+kIFusW+4
X-Received: by 10.194.172.131 with SMTP id bc3mr13422810wjc.64.1414863840031; 
	Sat, 01 Nov 2014 10:44:00 -0700 (PDT)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id
	w10sm16003887wje.10.2014.11.01.10.43.58 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 01 Nov 2014 10:43:59 -0700 (PDT)
Message-ID: <54551BDD.5080800@linaro.org>
Date: Sat, 01 Nov 2014 17:43:57 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<CAAiw7J=Mbb1YGYj=XQv6TmqyAMvcctUs7AvHQN_1O27xCRSp_Q@mail.gmail.com>
	<20141031142403.GA6913@laptop.dumpdata.com>
	<54539D4D.1040108@linaro.org>
	<20141031210156.GA20039@laptop.dumpdata.com>
In-Reply-To: <20141031210156.GA20039@laptop.dumpdata.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com,
	xen-devel <xen-devel@lists.xenproject.org>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	manish jaggi <manishjaggi.oss@gmail.com>
Subject: Re: [Xen-devel] Xen 4.5-rc1 update (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Konrad,

On 31/10/2014 21:01, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 31, 2014 at 02:31:41PM +0000, Julien Grall wrote:
>> On 10/31/2014 02:24 PM, Konrad Rzeszutek Wilk wrote:
>>>>> *  PVH - PCI passthrough for DomU.
>>>> I am working on Cavium Thunder (ARM64) on this feature.
>>>> [Xen SMMU driver changes + PCI passthrough changes in Xen and Linux]
>>
>> FYI, I'm currently reworking the SMMU drivers to resync with Linux. With
>> thoses changes, you should not need to modify the SMMU code.
>
> Thank you for the update. Put your name behind that for 4.6.
>>
>>> Ok, replaced Julien's name with yours. Please make sure
>>> that for the Linux patches you CC xen-devel and the
>>> maintainers (David, Stefano, Boris and me).
>>
>> There is 2 distinct passthrough: platform (i.e non-PCI) and PCI one.
>>
>> While Manish is working on PCI passthrough, I'm still working the
>> non-PCI one. Please don't drop my name.
>
> I thought that Arianna's patches had taken care of that (the MMIO
> part?). Or does each platform need a different implementation of
> that?

To passthrough a platform device you need to be able to assign the 
device to the guest via the IOMMU and map MMIOs (done by Arianna's 
series) and interrupts.

There is also a toolstack part to add the description of the device in 
the device tree. See the V2 [1] for more details.

[1] http://lists.xen.org/archives/html/xen-devel/2014-07/msg04090.html

Regards,

-- 
Julien Grall


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

From xen-devel-bounces@lists.xen.org Sat Nov 01 17:44:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 17:44:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkciY-0008II-HA; Sat, 01 Nov 2014 17:44:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XkciX-0008ID-N9
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 17:44:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9F/8A-24532-0EB15545; Sat, 01 Nov 2014 17:44:00 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1414863840!12123017!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23529 invoked from network); 1 Nov 2014 17:44:00 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 17:44:00 -0000
Received: by mail-wg0-f54.google.com with SMTP id n12so3101344wgh.27
	for <xen-devel@lists.xenproject.org>;
	Sat, 01 Nov 2014 10:44:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=NMbNWEES+OjDByWg9iNDCQy9VwN4od8meqz7rMGs9Oc=;
	b=a6eMeznz63qiS0nsmFPTxj5QG9GMybqlohgo2LxUIzCpaE3N2hMCC/K+0gAl5uOww2
	tUwRD5SvesIVrwVETw2RUNKBY1chOEipbC/lD0st7VBlwK4/RDf7TvvMlvQcuYRbW0AY
	aV5drFUjJ/1BJb3YqDIEYhfF/z6TprDRpYCXC6WTI7rANG2SBtYw4rTdTYxKJD5J51Mi
	YOekEInLP4vDIL0j9ducQEFnuYriQYzVUVLlk+ylHBmtPKHCxpUQv1WpfN1AAukT2q2Q
	BZq56ZmSYLI7ELuiICSQKE3MQcIWBfSH3waFg84qQXW4ok5tltWrOYy/xRhk1TiizN93
	39Qg==
X-Gm-Message-State: ALoCoQkpHNe9OCZ3452NYdvFN+LIsgjYM7/QrJvWA1TvilqkGET9zbbfkacgFbObJot+kIFusW+4
X-Received: by 10.194.172.131 with SMTP id bc3mr13422810wjc.64.1414863840031; 
	Sat, 01 Nov 2014 10:44:00 -0700 (PDT)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id
	w10sm16003887wje.10.2014.11.01.10.43.58 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 01 Nov 2014 10:43:59 -0700 (PDT)
Message-ID: <54551BDD.5080800@linaro.org>
Date: Sat, 01 Nov 2014 17:43:57 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<CAAiw7J=Mbb1YGYj=XQv6TmqyAMvcctUs7AvHQN_1O27xCRSp_Q@mail.gmail.com>
	<20141031142403.GA6913@laptop.dumpdata.com>
	<54539D4D.1040108@linaro.org>
	<20141031210156.GA20039@laptop.dumpdata.com>
In-Reply-To: <20141031210156.GA20039@laptop.dumpdata.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com,
	xen-devel <xen-devel@lists.xenproject.org>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	manish jaggi <manishjaggi.oss@gmail.com>
Subject: Re: [Xen-devel] Xen 4.5-rc1 update (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Konrad,

On 31/10/2014 21:01, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 31, 2014 at 02:31:41PM +0000, Julien Grall wrote:
>> On 10/31/2014 02:24 PM, Konrad Rzeszutek Wilk wrote:
>>>>> *  PVH - PCI passthrough for DomU.
>>>> I am working on Cavium Thunder (ARM64) on this feature.
>>>> [Xen SMMU driver changes + PCI passthrough changes in Xen and Linux]
>>
>> FYI, I'm currently reworking the SMMU drivers to resync with Linux. With
>> thoses changes, you should not need to modify the SMMU code.
>
> Thank you for the update. Put your name behind that for 4.6.
>>
>>> Ok, replaced Julien's name with yours. Please make sure
>>> that for the Linux patches you CC xen-devel and the
>>> maintainers (David, Stefano, Boris and me).
>>
>> There is 2 distinct passthrough: platform (i.e non-PCI) and PCI one.
>>
>> While Manish is working on PCI passthrough, I'm still working the
>> non-PCI one. Please don't drop my name.
>
> I thought that Arianna's patches had taken care of that (the MMIO
> part?). Or does each platform need a different implementation of
> that?

To passthrough a platform device you need to be able to assign the 
device to the guest via the IOMMU and map MMIOs (done by Arianna's 
series) and interrupts.

There is also a toolstack part to add the description of the device in 
the device tree. See the V2 [1] for more details.

[1] http://lists.xen.org/archives/html/xen-devel/2014-07/msg04090.html

Regards,

-- 
Julien Grall


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

From xen-devel-bounces@lists.xen.org Sat Nov 01 18:38:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 18:38:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkdYX-0000VB-Um; Sat, 01 Nov 2014 18:37:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkdYW-0000V4-9a
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 18:37:44 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	24/C9-11608-77825545; Sat, 01 Nov 2014 18:37:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1414867061!11043257!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18905 invoked from network); 1 Nov 2014 18:37:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 18:37:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187209182"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 14:37:40 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkdYR-0003jq-FW;
	Sat, 01 Nov 2014 18:37:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkdYR-0000nn-2E;
	Sat, 01 Nov 2014 18:37:39 +0000
Date: Sat, 1 Nov 2014 18:37:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31292-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31292: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot             fail pass in 31277

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31277 never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 01 18:38:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 18:38:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkdYX-0000VB-Um; Sat, 01 Nov 2014 18:37:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkdYW-0000V4-9a
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 18:37:44 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	24/C9-11608-77825545; Sat, 01 Nov 2014 18:37:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1414867061!11043257!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18905 invoked from network); 1 Nov 2014 18:37:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 18:37:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187209182"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 14:37:40 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkdYR-0003jq-FW;
	Sat, 01 Nov 2014 18:37:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkdYR-0000nn-2E;
	Sat, 01 Nov 2014 18:37:39 +0000
Date: Sat, 1 Nov 2014 18:37:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31292-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31292: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot             fail pass in 31277

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31277 never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 01 18:57:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 18:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkdqp-0000oO-03; Sat, 01 Nov 2014 18:56:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xkdqn-0000oJ-5F
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 18:56:37 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	EF/0B-25547-4EC25545; Sat, 01 Nov 2014 18:56:36 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-31.messagelabs.com!1414868195!6593370!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14099 invoked from network); 1 Nov 2014 18:56:35 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 18:56:35 -0000
Received: by mail-wi0-f171.google.com with SMTP id q5so3616050wiv.10
	for <xen-devel@lists.xenproject.org>;
	Sat, 01 Nov 2014 11:56:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=h0nK4tfyjpi5SNId7SaVaDfQMSnZj/cKh1YrYVwNcYk=;
	b=MKMSE0WSC52jvh0fJVULv8gfjziLgTg4erJXNhmMCiyOK7B/iSIv3gyR4zKWEo26ct
	vOC4pM/WNBceLcU/qvnbf+YikEUjTQtoTo0neadu9JAnaUcL/p9im0B47VspD5/sMHGh
	k++w2Hj71isbXmHGfc2gF05Kj3DcDBdjOznsb/CSDu9kK6iodxDpRjuEEiGEblwXi8JJ
	B20Nt6x1twCT//FfoacY973iS9qPH4D+z29sL18gbikrgUcXH9CAZFgIeNcF0MKkoCL5
	+zSrs2G2wdBFU2ns76qHbxeh2DvAcHjm6PDZi0MYuJm+nBXajWLaoYMSzGt3iiEUrIaa
	Tp1w==
X-Gm-Message-State: ALoCoQkHxBzYk9wVJ5+fpM3Z8Sv2tmwNG69Kr670WRZ+JQ9V8qimsMvt2R2slpKDbdTxSonjAizb
X-Received: by 10.194.71.6 with SMTP id q6mr36234729wju.98.1414868195452;
	Sat, 01 Nov 2014 11:56:35 -0700 (PDT)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id i3sm2771237wix.0.2014.11.01.11.56.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 01 Nov 2014 11:56:34 -0700 (PDT)
Message-ID: <54552CE1.4070205@linaro.org>
Date: Sat, 01 Nov 2014 18:56:33 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<54537126.5010401@linaro.org>
	<54539EA50200007800043EAE@mail.emea.novell.com>
	<54539458.3010901@linaro.org>
	<5453B5060200007800043F9B@mail.emea.novell.com>
In-Reply-To: <5453B5060200007800043F9B@mail.emea.novell.com>
Cc: ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 31/10/2014 15:12, Jan Beulich wrote:
>>>> On 31.10.14 at 14:53, <julien.grall@linaro.org> wrote:
>> On 10/31/2014 01:37 PM, Jan Beulich wrote:
>>>>>> On 31.10.14 at 12:23, <julien.grall@linaro.org> wrote:
>>>> On 31/10/2014 09:02, Jan Beulich wrote:
>>>>>> --- a/xen/include/public/domctl.h
>>>>>> +++ b/xen/include/public/domctl.h
>>>>>> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
>>>>>>    typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
>>>>>>    DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
>>>>>>
>>>>>> +#if defined(__arm__) || defined(__aarch64__)
>>>>>> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
>>>>>> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
>>>>>> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
>>>>>> +/* XEN_DOMCTL_configure_domain */
>>>>>> +struct xen_domctl_configuredomain {
>>>>>
>>>>> The naming suggests that the #if really should be around just the
>>>>> gic_version field (with a dummy field in the #else case to be C89
>>>>> compatible, e.g. a zero width unnamed bitfield) and the
>>>>> corresponding #define-s above, ...
>>>>
>>>> It's a bit like xen_domctl_setvcpuextstate which is defined only for x86
>>>> while the name seem pretty common.
>>>
>>> That's a particularly bad example to compare with, as this is about
>>> CPU registers having got added after the ABI was defined. This
>>> (hopefully) shouldn't have many similar cases on other architectures.
>>> Plus, doing things in an odd way just because there's an odd
>>> precedent is always suspicious to me.
>>>
>>>> I think we have to stay consistent in this header and not defining
>>>> DOMCTL which is not used for a specific architecture.
>>>
>>> Yes, I always advocate for consistency - provided what is there is
>>> a reasonable reference and was done properly.
>>
>> Would renaming the structure name with "xen_arm_domctl_configuredomain"
>> would be sufficient for you?
>
> Maybe (better xen_domctl_arm_configure_domain then), if you are
> reasonably certain this can't become useful for another arch.

IIRC, DOMCTL can be modify whenever we want.

I doubt that x86 will use it, so if we plan to add a new architecture 
which require this DOMCTL then we could rename the structure at that time.

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Sat Nov 01 18:57:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 18:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkdqp-0000oO-03; Sat, 01 Nov 2014 18:56:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xkdqn-0000oJ-5F
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 18:56:37 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	EF/0B-25547-4EC25545; Sat, 01 Nov 2014 18:56:36 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-31.messagelabs.com!1414868195!6593370!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14099 invoked from network); 1 Nov 2014 18:56:35 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 18:56:35 -0000
Received: by mail-wi0-f171.google.com with SMTP id q5so3616050wiv.10
	for <xen-devel@lists.xenproject.org>;
	Sat, 01 Nov 2014 11:56:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=h0nK4tfyjpi5SNId7SaVaDfQMSnZj/cKh1YrYVwNcYk=;
	b=MKMSE0WSC52jvh0fJVULv8gfjziLgTg4erJXNhmMCiyOK7B/iSIv3gyR4zKWEo26ct
	vOC4pM/WNBceLcU/qvnbf+YikEUjTQtoTo0neadu9JAnaUcL/p9im0B47VspD5/sMHGh
	k++w2Hj71isbXmHGfc2gF05Kj3DcDBdjOznsb/CSDu9kK6iodxDpRjuEEiGEblwXi8JJ
	B20Nt6x1twCT//FfoacY973iS9qPH4D+z29sL18gbikrgUcXH9CAZFgIeNcF0MKkoCL5
	+zSrs2G2wdBFU2ns76qHbxeh2DvAcHjm6PDZi0MYuJm+nBXajWLaoYMSzGt3iiEUrIaa
	Tp1w==
X-Gm-Message-State: ALoCoQkHxBzYk9wVJ5+fpM3Z8Sv2tmwNG69Kr670WRZ+JQ9V8qimsMvt2R2slpKDbdTxSonjAizb
X-Received: by 10.194.71.6 with SMTP id q6mr36234729wju.98.1414868195452;
	Sat, 01 Nov 2014 11:56:35 -0700 (PDT)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id i3sm2771237wix.0.2014.11.01.11.56.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 01 Nov 2014 11:56:34 -0700 (PDT)
Message-ID: <54552CE1.4070205@linaro.org>
Date: Sat, 01 Nov 2014 18:56:33 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<54537126.5010401@linaro.org>
	<54539EA50200007800043EAE@mail.emea.novell.com>
	<54539458.3010901@linaro.org>
	<5453B5060200007800043F9B@mail.emea.novell.com>
In-Reply-To: <5453B5060200007800043F9B@mail.emea.novell.com>
Cc: ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 31/10/2014 15:12, Jan Beulich wrote:
>>>> On 31.10.14 at 14:53, <julien.grall@linaro.org> wrote:
>> On 10/31/2014 01:37 PM, Jan Beulich wrote:
>>>>>> On 31.10.14 at 12:23, <julien.grall@linaro.org> wrote:
>>>> On 31/10/2014 09:02, Jan Beulich wrote:
>>>>>> --- a/xen/include/public/domctl.h
>>>>>> +++ b/xen/include/public/domctl.h
>>>>>> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
>>>>>>    typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
>>>>>>    DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
>>>>>>
>>>>>> +#if defined(__arm__) || defined(__aarch64__)
>>>>>> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
>>>>>> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
>>>>>> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
>>>>>> +/* XEN_DOMCTL_configure_domain */
>>>>>> +struct xen_domctl_configuredomain {
>>>>>
>>>>> The naming suggests that the #if really should be around just the
>>>>> gic_version field (with a dummy field in the #else case to be C89
>>>>> compatible, e.g. a zero width unnamed bitfield) and the
>>>>> corresponding #define-s above, ...
>>>>
>>>> It's a bit like xen_domctl_setvcpuextstate which is defined only for x86
>>>> while the name seem pretty common.
>>>
>>> That's a particularly bad example to compare with, as this is about
>>> CPU registers having got added after the ABI was defined. This
>>> (hopefully) shouldn't have many similar cases on other architectures.
>>> Plus, doing things in an odd way just because there's an odd
>>> precedent is always suspicious to me.
>>>
>>>> I think we have to stay consistent in this header and not defining
>>>> DOMCTL which is not used for a specific architecture.
>>>
>>> Yes, I always advocate for consistency - provided what is there is
>>> a reasonable reference and was done properly.
>>
>> Would renaming the structure name with "xen_arm_domctl_configuredomain"
>> would be sufficient for you?
>
> Maybe (better xen_domctl_arm_configure_domain then), if you are
> reasonably certain this can't become useful for another arch.

IIRC, DOMCTL can be modify whenever we want.

I doubt that x86 will use it, so if we plan to add a new architecture 
which require this DOMCTL then we could rename the structure at that time.

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Sat Nov 01 19:42:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 19: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 1XkeYl-0001I8-Ru; Sat, 01 Nov 2014 19:42:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1XkeYl-0001I3-2X
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 19:42:03 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	7D/C8-19763-A8735545; Sat, 01 Nov 2014 19:42:02 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1414870921!13068113!1
X-Originating-IP: [217.70.183.197]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29290 invoked from network); 1 Nov 2014 19:42:01 -0000
Received: from relay5-d.mail.gandi.net (HELO relay5-d.mail.gandi.net)
	(217.70.183.197)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Nov 2014 19:42:01 -0000
Received: from mfilter32-d.gandi.net (mfilter32-d.gandi.net [217.70.178.163])
	by relay5-d.mail.gandi.net (Postfix) with ESMTP id B754841C04B;
	Sat,  1 Nov 2014 20:42:01 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter32-d.gandi.net
Received: from relay5-d.mail.gandi.net ([217.70.183.197])
	by mfilter32-d.gandi.net (mfilter32-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id JZ3CaflpdnLo; Sat,  1 Nov 2014 20:42:00 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 6C02441C06C;
	Sat,  1 Nov 2014 20:41:53 +0100 (CET)
Date: Sat, 1 Nov 2014 12:41:52 -0700
From: Josh Triplett <josh@joshtriplett.org>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20141101194151.GA11810@thin>
References: <7159269982aac3b732af2c33a2e3d04e2048bdfb.1414598511.git.josh@joshtriplett.org>
	<9d77d0e4df8feb2cb55fb21689e016a3145cb7f8.1414598511.git.josh@joshtriplett.org>
	<alpine.DEB.2.11.1410292155300.5308@nanos>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.11.1410292155300.5308@nanos>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Kees Cook <keescook@chromium.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 3/3] x86: Support compiling out userspace
 I/O (iopl and ioperm)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 29, 2014 at 10:00:54PM +0100, Thomas Gleixner wrote:
> On Wed, 29 Oct 2014, Josh Triplett wrote:
> > v3: Eliminated several #ifdefs, and in particular almost all #ifdefs in
> >     .c files, by adding a macro INIT_SET_IOPL_MASK to use in place of
> >     the initializer for set_iopl_mask, and using __maybe_unused rather
> >     than wrapping function definitions in #ifdef.  Rebased on v3.18-rc1.
> >     Recomputed bloat-o-meter.
> 
> Can you please split this patch into smaller pieces?
> 
>     - Seperate the code move to header files
>     - Seperate the macro stuff
>     - Add the #ifdef CONFIG_.... changes

Done; sending v4 now.

- Josh Triplett

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

From xen-devel-bounces@lists.xen.org Sat Nov 01 19:42:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 19: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 1XkeYl-0001I8-Ru; Sat, 01 Nov 2014 19:42:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1XkeYl-0001I3-2X
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 19:42:03 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	7D/C8-19763-A8735545; Sat, 01 Nov 2014 19:42:02 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1414870921!13068113!1
X-Originating-IP: [217.70.183.197]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29290 invoked from network); 1 Nov 2014 19:42:01 -0000
Received: from relay5-d.mail.gandi.net (HELO relay5-d.mail.gandi.net)
	(217.70.183.197)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Nov 2014 19:42:01 -0000
Received: from mfilter32-d.gandi.net (mfilter32-d.gandi.net [217.70.178.163])
	by relay5-d.mail.gandi.net (Postfix) with ESMTP id B754841C04B;
	Sat,  1 Nov 2014 20:42:01 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter32-d.gandi.net
Received: from relay5-d.mail.gandi.net ([217.70.183.197])
	by mfilter32-d.gandi.net (mfilter32-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id JZ3CaflpdnLo; Sat,  1 Nov 2014 20:42:00 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 6C02441C06C;
	Sat,  1 Nov 2014 20:41:53 +0100 (CET)
Date: Sat, 1 Nov 2014 12:41:52 -0700
From: Josh Triplett <josh@joshtriplett.org>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20141101194151.GA11810@thin>
References: <7159269982aac3b732af2c33a2e3d04e2048bdfb.1414598511.git.josh@joshtriplett.org>
	<9d77d0e4df8feb2cb55fb21689e016a3145cb7f8.1414598511.git.josh@joshtriplett.org>
	<alpine.DEB.2.11.1410292155300.5308@nanos>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.11.1410292155300.5308@nanos>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Kees Cook <keescook@chromium.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 3/3] x86: Support compiling out userspace
 I/O (iopl and ioperm)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 29, 2014 at 10:00:54PM +0100, Thomas Gleixner wrote:
> On Wed, 29 Oct 2014, Josh Triplett wrote:
> > v3: Eliminated several #ifdefs, and in particular almost all #ifdefs in
> >     .c files, by adding a macro INIT_SET_IOPL_MASK to use in place of
> >     the initializer for set_iopl_mask, and using __maybe_unused rather
> >     than wrapping function definitions in #ifdef.  Rebased on v3.18-rc1.
> >     Recomputed bloat-o-meter.
> 
> Can you please split this patch into smaller pieces?
> 
>     - Seperate the code move to header files
>     - Seperate the macro stuff
>     - Add the #ifdef CONFIG_.... changes

Done; sending v4 now.

- Josh Triplett

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

From xen-devel-bounces@lists.xen.org Sat Nov 01 20:11:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 20:11:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkf0R-0001hz-HF; Sat, 01 Nov 2014 20:10:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xkf0Q-0001hu-7a
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 20:10:38 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	C2/7E-11608-D3E35545; Sat, 01 Nov 2014 20:10:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-31.messagelabs.com!1414872636!11048997!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21170 invoked from network); 1 Nov 2014 20:10:36 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 20:10:36 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so8635580wgg.33
	for <xen-devel@lists.xenproject.org>;
	Sat, 01 Nov 2014 13:10:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=E2OB7WLM9JWYwzL6sUkb3yoecDwXNQ5svDDnAruti5c=;
	b=Q0eOqJW8/iOBd+pndWXx5F07zSmH7L/UUj3BVBsWLv4ym8iqyD0ermqXcAcjXwLydQ
	MckJbZcKJkiKOU4I6BVdRA7l7B59pPFEoYMmTny+/89nIjVTjyrve/cAvGKfE8+9eCgD
	fiPuF3aRyDe0NXXSizI1Yf+XuYM5F6OB/z5RY/8GYv+5It9tUOXhuSr8w+29hZJ+k/0S
	8xPinTPHTMnzfGIyVG5wpEkT6cFZp9UePJtN+FwNYw/4tyz4k5kj/Y2hhpFc4cMVgYe0
	s2KIrvvwvBmKux6sHCpQ1ZVE0hF8DF4d4h2PfuEh58H5O0na3QwpOrTbaVG+AWPBsBqJ
	bPkw==
X-Gm-Message-State: ALoCoQkBFhUA8WxOXIymM6OF+rPDYwh7JmyBwUYrld6+GgfWM1u5B22cR5IfjlBR3r+lpHllclos
X-Received: by 10.180.211.70 with SMTP id na6mr5631241wic.3.1414872635898;
	Sat, 01 Nov 2014 13:10:35 -0700 (PDT)
Received: from belegaer.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id f1sm471355wiy.17.2014.11.01.13.10.34
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 01 Nov 2014 13:10:34 -0700 (PDT)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Sat,  1 Nov 2014 20:10:25 +0000
Message-Id: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 1.7.10.4
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3 for
	domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 vGIC will emulate the same version as the hardware. The toolstack has
to retrieve the version of the vGIC in order to be able to create the
corresponding device tree node.

A new DOMCTL has been introduced for ARM to configure the domain. For now
it only allow the toolstack to retrieve the version of vGIC.
This DOMCTL will be extend later to let the user choose the version of the
emulated GIC.

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Wei Liu <wei.liu2@citrix.com>

---
    Changes in v2:
        - Use memcpu in xc_domain_configure
        - Rename the DOMCTL into domctl_arm_configuredomain
        - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
        and fold the code in arch_domain_init_hw_description
        - Return -EOPNOTSUPP when the value of gic_version is not
        supported

This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
defer the initialization of the vGIC [2].

Xen 4.5 has already support for the hardware GICv3. While it's possible to
boot and use DOM0, there is no guest support. The first version of this patch
has been sent a couple of months ago, but has never reached unstable for
various reasons (based on deferred series, lake of review at that time...).
Without it, platform with GICv3 support won't be able to boot any guest.

The patch has been reworked to make it acceptable for Xen 4.5. Except the new
DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.

Features such as adding a new config option to let the user choose the GIC
version are deferred to Xen 4.6.

It has been tested on both GICv2/GICv3 platform. And build tested for x86.

[1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
[2] https://patches.linaro.org/34664/
---
 tools/flask/policy/policy/modules/xen/xen.if |    2 +-
 tools/libxc/include/xenctrl.h                |    6 ++
 tools/libxc/xc_domain.c                      |   20 ++++++
 tools/libxl/libxl_arm.c                      |   97 ++++++++++++++++++++++++--
 xen/arch/arm/domctl.c                        |   35 ++++++++++
 xen/arch/arm/gic-v3.c                        |   16 ++++-
 xen/include/public/arch-arm.h                |   16 +++++
 xen/include/public/domctl.h                  |   17 +++++
 xen/xsm/flask/hooks.c                        |    3 +
 xen/xsm/flask/policy/access_vectors          |    2 +
 10 files changed, 206 insertions(+), 8 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 641c797..fa69c9d 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -49,7 +49,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			getscheduler getvcpuinfo getvcpuextstate getaddrsize
 			getaffinity setaffinity };
-	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
+	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 564e187..45e282c 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
                      uint32_t flags,
                      uint32_t *pdomid);
 
+#if defined(__arm__) || defined(__aarch64__)
+typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
+
+int xc_domain_configure(xc_interface *xch, uint32_t domid,
+                        xc_domain_configuration_t *config);
+#endif
 
 /* Functions to produce a dump of a given domain
  *  xc_domain_dumpcore - produces a dump to a specified file
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index a9bcd4a..1aa1f45 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
     return 0;
 }
 
+#if defined(__arm__) || defined(__aarch64__)
+int xc_domain_configure(xc_interface *xch, uint32_t domid,
+                        xc_domain_configuration_t *config)
+{
+    int rc;
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
+    domctl.domain = (domid_t)domid;
+    /* xc_domain_configure_t is an alias to xen_domctl_arm_configuredomain */
+    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
+
+    rc = do_domctl(xch, &domctl);
+    if ( !rc )
+        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
+
+    return rc;
+}
+#endif
+
 int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
                          xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
 {
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index a122e4a..3dd6e7c 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -23,6 +23,18 @@
 #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
 #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
 
+static const char *gicv_to_string(uint8_t gic_version)
+{
+    switch (gic_version) {
+    case XEN_DOMCTL_CONFIG_GIC_V2:
+        return "V2";
+    case XEN_DOMCTL_CONFIG_GIC_V3:
+        return "V3";
+    default:
+        return "unknown";
+    }
+}
+
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                               uint32_t domid)
 {
@@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
     return 0;
 }
 
-static int make_intc_node(libxl__gc *gc, void *fdt,
-                          uint64_t gicd_base, uint64_t gicd_size,
-                          uint64_t gicc_base, uint64_t gicc_size)
+static int make_gicv2_node(libxl__gc *gc, void *fdt,
+                           uint64_t gicd_base, uint64_t gicd_size,
+                           uint64_t gicc_base, uint64_t gicc_size)
 {
     int res;
     const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
@@ -350,6 +362,57 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
     return 0;
 }
 
+static int make_gicv3_node(libxl__gc *gc, void *fdt)
+{
+    int res;
+    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
+    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
+    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
+    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
+    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
+
+    res = fdt_begin_node(fdt, name);
+    if (res) return res;
+
+    res = fdt_property_compat(gc, fdt, 1,
+                              "arm,gic-v3");
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#address-cells", 0);
+    if (res) return res;
+
+    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "redistributor-stride",
+                            GUEST_GICV3_RDIST_STRIDE);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#redistributor-regions",
+                            GUEST_GICV3_RDIST_REGIONS);
+    if (res) return res;
+
+    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
+                            2,
+                            gicd_base, gicd_size,
+                            gicr0_base, gicr0_size);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
+    if (res) return res;
+
+    res = fdt_end_node(fdt);
+    if (res) return res;
+
+    return 0;
+}
+
 static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
 {
     int res;
@@ -456,6 +519,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl_domain_build_info *info,
                                            struct xc_dom_image *dom)
 {
+    xc_domain_configuration_t config;
     void *fdt = NULL;
     int rc, res;
     size_t fdt_size = 0;
@@ -471,8 +535,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
     ainfo = get_arch_info(gc, dom);
     if (ainfo == NULL) return ERROR_FAIL;
 
+    LOG(DEBUG, "configure the domain");
+    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
+    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
+        LOG(ERROR, "counldn't configure the domain");
+        return ERROR_FAIL;
+    }
+
     LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
         vers->xen_version_major, vers->xen_version_minor);
+    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
 
 /*
  * Call "call" handling FDR_ERR_*. Will either:
@@ -520,9 +592,22 @@ next_resize:
         FDT( make_psci_node(gc, fdt) );
 
         FDT( make_memory_nodes(gc, fdt, dom) );
-        FDT( make_intc_node(gc, fdt,
-                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
-                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
+
+        switch (config.gic_version) {
+        case XEN_DOMCTL_CONFIG_GIC_V2:
+            FDT( make_gicv2_node(gc, fdt,
+                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
+                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
+            break;
+        case XEN_DOMCTL_CONFIG_GIC_V3:
+            FDT( make_gicv3_node(gc, fdt) );
+            break;
+        default:
+            LOG(ERROR, "Unknown how to create the DT node for gic_version = %d",
+                config.gic_version);
+            rc = ERROR_FAIL;
+            goto out;
+        }
 
         FDT( make_timer_node(gc, fdt, ainfo) );
         FDT( make_hypervisor_node(gc, fdt, vers) );
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 45974e7..5b8ff57 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -10,6 +10,8 @@
 #include <xen/errno.h>
 #include <xen/sched.h>
 #include <xen/hypercall.h>
+#include <asm/gic.h>
+#include <xen/guest_access.h>
 #include <public/domctl.h>
 
 long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
@@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 
         return p2m_cache_flush(d, s, e);
     }
+    case XEN_DOMCTL_arm_configure_domain:
+    {
+        uint8_t gic_version;
+
+        /*
+         * Xen 4.5: The vGIC is emulating the same version of the
+         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
+         * is allowed. The DOMCTL will return the actual version of the
+         * GIC.
+         */
+        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
+            return -EOPNOTSUPP;
+
+        switch ( gic_hw_version() )
+        {
+        case GIC_V3:
+            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+            break;
+        case GIC_V2:
+            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
+            break;
+        default:
+            BUG();
+        }
+
+        domctl->u.configuredomain.gic_version = gic_version;
+
+        /* TODO: Make the copy generic for all ARCH domctl */
+        if ( __copy_to_guest(u_domctl, domctl, 1) )
+            return -EFAULT;
+
+        return 0;
+    }
 
     default:
         return subarch_do_domctl(domctl, d, u_domctl);
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 91161a2..076aa62 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
         d->arch.vgic.rdist_count = gicv3.rdist_count;
     }
     else
-        d->arch.vgic.dbase = GUEST_GICD_BASE;
+    {
+        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
+        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
+
+        /* XXX: Only one Re-distributor region mapped for the guest */
+        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
+
+        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
+        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
+
+        /* The first redistributor should contain enough space for all CPUs */
+        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
+        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
+        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
+    }
 
     d->arch.vgic.nr_lines = 0;
 
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index eecc561..d7df274 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
  */
 
 /* Physical Address Space */
+
+/* vGIC mappings: Only one set of mapping is used by the guest.
+ * Therefore they can overlap.
+ */
+
+/* vGIC v2 mappings */
 #define GUEST_GICD_BASE   0x03001000ULL
 #define GUEST_GICD_SIZE   0x00001000ULL
 #define GUEST_GICC_BASE   0x03002000ULL
 #define GUEST_GICC_SIZE   0x00000100ULL
 
+/* vGIC v3 mappings */
+#define GUEST_GICV3_GICD_BASE      0x03001000ULL
+#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
+
+#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
+#define GUEST_GICV3_RDIST_REGIONS  1
+
+#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */
+#define GUEST_GICV3_GICR0_SIZE     0x00200000ULL
+
 /* 16MB == 4096 pages reserved for guest to use as a region to map its
  * grant table in.
  */
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 58b19e7..8da204e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
 
+#if defined(__arm__) || defined(__aarch64__)
+#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
+#define XEN_DOMCTL_CONFIG_GIC_V2        1
+#define XEN_DOMCTL_CONFIG_GIC_V3        2
+/* XEN_DOMCTL_configure_domain */
+struct xen_domctl_arm_configuredomain {
+    /* IN/OUT parameters */
+    uint8_t gic_version;
+};
+typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
+#endif
+
 /* XEN_DOMCTL_getdomaininfo */
 struct xen_domctl_getdomaininfo {
     /* OUT variables. */
@@ -1056,6 +1069,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_vcpu_msrs                 73
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
+#define XEN_DOMCTL_arm_configure_domain          76
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1064,6 +1078,9 @@ struct xen_domctl {
     domid_t  domain;
     union {
         struct xen_domctl_createdomain      createdomain;
+#if defined(__arm__) || defined(__aarch64__)
+        struct xen_domctl_arm_configuredomain configuredomain;
+#endif
         struct xen_domctl_getdomaininfo     getdomaininfo;
         struct xen_domctl_getmemlist        getmemlist;
         struct xen_domctl_getpageframeinfo  getpageframeinfo;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d0fe72..846cf88 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_psr_cmt_op:
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
 
+    case XEN_DOMCTL_configure_domain:
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
+
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
         return -EPERM;
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index de0c707..bfe2fa5 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -216,6 +216,8 @@ class domain2
     get_vnumainfo
 # XEN_DOMCTL_psr_cmt_op
     psr_cmt_op
+# XEN_DOMCTL_configure_domain
+    configure_domain
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Sat Nov 01 20:11:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 20:11:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkf0R-0001hz-HF; Sat, 01 Nov 2014 20:10:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xkf0Q-0001hu-7a
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 20:10:38 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	C2/7E-11608-D3E35545; Sat, 01 Nov 2014 20:10:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-31.messagelabs.com!1414872636!11048997!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21170 invoked from network); 1 Nov 2014 20:10:36 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 20:10:36 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so8635580wgg.33
	for <xen-devel@lists.xenproject.org>;
	Sat, 01 Nov 2014 13:10:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=E2OB7WLM9JWYwzL6sUkb3yoecDwXNQ5svDDnAruti5c=;
	b=Q0eOqJW8/iOBd+pndWXx5F07zSmH7L/UUj3BVBsWLv4ym8iqyD0ermqXcAcjXwLydQ
	MckJbZcKJkiKOU4I6BVdRA7l7B59pPFEoYMmTny+/89nIjVTjyrve/cAvGKfE8+9eCgD
	fiPuF3aRyDe0NXXSizI1Yf+XuYM5F6OB/z5RY/8GYv+5It9tUOXhuSr8w+29hZJ+k/0S
	8xPinTPHTMnzfGIyVG5wpEkT6cFZp9UePJtN+FwNYw/4tyz4k5kj/Y2hhpFc4cMVgYe0
	s2KIrvvwvBmKux6sHCpQ1ZVE0hF8DF4d4h2PfuEh58H5O0na3QwpOrTbaVG+AWPBsBqJ
	bPkw==
X-Gm-Message-State: ALoCoQkBFhUA8WxOXIymM6OF+rPDYwh7JmyBwUYrld6+GgfWM1u5B22cR5IfjlBR3r+lpHllclos
X-Received: by 10.180.211.70 with SMTP id na6mr5631241wic.3.1414872635898;
	Sat, 01 Nov 2014 13:10:35 -0700 (PDT)
Received: from belegaer.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id f1sm471355wiy.17.2014.11.01.13.10.34
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 01 Nov 2014 13:10:34 -0700 (PDT)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Sat,  1 Nov 2014 20:10:25 +0000
Message-Id: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 1.7.10.4
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3 for
	domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 vGIC will emulate the same version as the hardware. The toolstack has
to retrieve the version of the vGIC in order to be able to create the
corresponding device tree node.

A new DOMCTL has been introduced for ARM to configure the domain. For now
it only allow the toolstack to retrieve the version of vGIC.
This DOMCTL will be extend later to let the user choose the version of the
emulated GIC.

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Wei Liu <wei.liu2@citrix.com>

---
    Changes in v2:
        - Use memcpu in xc_domain_configure
        - Rename the DOMCTL into domctl_arm_configuredomain
        - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
        and fold the code in arch_domain_init_hw_description
        - Return -EOPNOTSUPP when the value of gic_version is not
        supported

This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
defer the initialization of the vGIC [2].

Xen 4.5 has already support for the hardware GICv3. While it's possible to
boot and use DOM0, there is no guest support. The first version of this patch
has been sent a couple of months ago, but has never reached unstable for
various reasons (based on deferred series, lake of review at that time...).
Without it, platform with GICv3 support won't be able to boot any guest.

The patch has been reworked to make it acceptable for Xen 4.5. Except the new
DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.

Features such as adding a new config option to let the user choose the GIC
version are deferred to Xen 4.6.

It has been tested on both GICv2/GICv3 platform. And build tested for x86.

[1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
[2] https://patches.linaro.org/34664/
---
 tools/flask/policy/policy/modules/xen/xen.if |    2 +-
 tools/libxc/include/xenctrl.h                |    6 ++
 tools/libxc/xc_domain.c                      |   20 ++++++
 tools/libxl/libxl_arm.c                      |   97 ++++++++++++++++++++++++--
 xen/arch/arm/domctl.c                        |   35 ++++++++++
 xen/arch/arm/gic-v3.c                        |   16 ++++-
 xen/include/public/arch-arm.h                |   16 +++++
 xen/include/public/domctl.h                  |   17 +++++
 xen/xsm/flask/hooks.c                        |    3 +
 xen/xsm/flask/policy/access_vectors          |    2 +
 10 files changed, 206 insertions(+), 8 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 641c797..fa69c9d 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -49,7 +49,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			getscheduler getvcpuinfo getvcpuextstate getaddrsize
 			getaffinity setaffinity };
-	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
+	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 564e187..45e282c 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
                      uint32_t flags,
                      uint32_t *pdomid);
 
+#if defined(__arm__) || defined(__aarch64__)
+typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
+
+int xc_domain_configure(xc_interface *xch, uint32_t domid,
+                        xc_domain_configuration_t *config);
+#endif
 
 /* Functions to produce a dump of a given domain
  *  xc_domain_dumpcore - produces a dump to a specified file
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index a9bcd4a..1aa1f45 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
     return 0;
 }
 
+#if defined(__arm__) || defined(__aarch64__)
+int xc_domain_configure(xc_interface *xch, uint32_t domid,
+                        xc_domain_configuration_t *config)
+{
+    int rc;
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
+    domctl.domain = (domid_t)domid;
+    /* xc_domain_configure_t is an alias to xen_domctl_arm_configuredomain */
+    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
+
+    rc = do_domctl(xch, &domctl);
+    if ( !rc )
+        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
+
+    return rc;
+}
+#endif
+
 int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
                          xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
 {
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index a122e4a..3dd6e7c 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -23,6 +23,18 @@
 #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
 #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
 
+static const char *gicv_to_string(uint8_t gic_version)
+{
+    switch (gic_version) {
+    case XEN_DOMCTL_CONFIG_GIC_V2:
+        return "V2";
+    case XEN_DOMCTL_CONFIG_GIC_V3:
+        return "V3";
+    default:
+        return "unknown";
+    }
+}
+
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                               uint32_t domid)
 {
@@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
     return 0;
 }
 
-static int make_intc_node(libxl__gc *gc, void *fdt,
-                          uint64_t gicd_base, uint64_t gicd_size,
-                          uint64_t gicc_base, uint64_t gicc_size)
+static int make_gicv2_node(libxl__gc *gc, void *fdt,
+                           uint64_t gicd_base, uint64_t gicd_size,
+                           uint64_t gicc_base, uint64_t gicc_size)
 {
     int res;
     const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
@@ -350,6 +362,57 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
     return 0;
 }
 
+static int make_gicv3_node(libxl__gc *gc, void *fdt)
+{
+    int res;
+    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
+    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
+    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
+    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
+    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
+
+    res = fdt_begin_node(fdt, name);
+    if (res) return res;
+
+    res = fdt_property_compat(gc, fdt, 1,
+                              "arm,gic-v3");
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#address-cells", 0);
+    if (res) return res;
+
+    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "redistributor-stride",
+                            GUEST_GICV3_RDIST_STRIDE);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#redistributor-regions",
+                            GUEST_GICV3_RDIST_REGIONS);
+    if (res) return res;
+
+    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
+                            2,
+                            gicd_base, gicd_size,
+                            gicr0_base, gicr0_size);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
+    if (res) return res;
+
+    res = fdt_end_node(fdt);
+    if (res) return res;
+
+    return 0;
+}
+
 static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
 {
     int res;
@@ -456,6 +519,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl_domain_build_info *info,
                                            struct xc_dom_image *dom)
 {
+    xc_domain_configuration_t config;
     void *fdt = NULL;
     int rc, res;
     size_t fdt_size = 0;
@@ -471,8 +535,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
     ainfo = get_arch_info(gc, dom);
     if (ainfo == NULL) return ERROR_FAIL;
 
+    LOG(DEBUG, "configure the domain");
+    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
+    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
+        LOG(ERROR, "counldn't configure the domain");
+        return ERROR_FAIL;
+    }
+
     LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
         vers->xen_version_major, vers->xen_version_minor);
+    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
 
 /*
  * Call "call" handling FDR_ERR_*. Will either:
@@ -520,9 +592,22 @@ next_resize:
         FDT( make_psci_node(gc, fdt) );
 
         FDT( make_memory_nodes(gc, fdt, dom) );
-        FDT( make_intc_node(gc, fdt,
-                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
-                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
+
+        switch (config.gic_version) {
+        case XEN_DOMCTL_CONFIG_GIC_V2:
+            FDT( make_gicv2_node(gc, fdt,
+                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
+                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
+            break;
+        case XEN_DOMCTL_CONFIG_GIC_V3:
+            FDT( make_gicv3_node(gc, fdt) );
+            break;
+        default:
+            LOG(ERROR, "Unknown how to create the DT node for gic_version = %d",
+                config.gic_version);
+            rc = ERROR_FAIL;
+            goto out;
+        }
 
         FDT( make_timer_node(gc, fdt, ainfo) );
         FDT( make_hypervisor_node(gc, fdt, vers) );
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 45974e7..5b8ff57 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -10,6 +10,8 @@
 #include <xen/errno.h>
 #include <xen/sched.h>
 #include <xen/hypercall.h>
+#include <asm/gic.h>
+#include <xen/guest_access.h>
 #include <public/domctl.h>
 
 long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
@@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 
         return p2m_cache_flush(d, s, e);
     }
+    case XEN_DOMCTL_arm_configure_domain:
+    {
+        uint8_t gic_version;
+
+        /*
+         * Xen 4.5: The vGIC is emulating the same version of the
+         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
+         * is allowed. The DOMCTL will return the actual version of the
+         * GIC.
+         */
+        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
+            return -EOPNOTSUPP;
+
+        switch ( gic_hw_version() )
+        {
+        case GIC_V3:
+            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+            break;
+        case GIC_V2:
+            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
+            break;
+        default:
+            BUG();
+        }
+
+        domctl->u.configuredomain.gic_version = gic_version;
+
+        /* TODO: Make the copy generic for all ARCH domctl */
+        if ( __copy_to_guest(u_domctl, domctl, 1) )
+            return -EFAULT;
+
+        return 0;
+    }
 
     default:
         return subarch_do_domctl(domctl, d, u_domctl);
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 91161a2..076aa62 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
         d->arch.vgic.rdist_count = gicv3.rdist_count;
     }
     else
-        d->arch.vgic.dbase = GUEST_GICD_BASE;
+    {
+        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
+        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
+
+        /* XXX: Only one Re-distributor region mapped for the guest */
+        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
+
+        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
+        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
+
+        /* The first redistributor should contain enough space for all CPUs */
+        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
+        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
+        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
+    }
 
     d->arch.vgic.nr_lines = 0;
 
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index eecc561..d7df274 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
  */
 
 /* Physical Address Space */
+
+/* vGIC mappings: Only one set of mapping is used by the guest.
+ * Therefore they can overlap.
+ */
+
+/* vGIC v2 mappings */
 #define GUEST_GICD_BASE   0x03001000ULL
 #define GUEST_GICD_SIZE   0x00001000ULL
 #define GUEST_GICC_BASE   0x03002000ULL
 #define GUEST_GICC_SIZE   0x00000100ULL
 
+/* vGIC v3 mappings */
+#define GUEST_GICV3_GICD_BASE      0x03001000ULL
+#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
+
+#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
+#define GUEST_GICV3_RDIST_REGIONS  1
+
+#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */
+#define GUEST_GICV3_GICR0_SIZE     0x00200000ULL
+
 /* 16MB == 4096 pages reserved for guest to use as a region to map its
  * grant table in.
  */
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 58b19e7..8da204e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
 
+#if defined(__arm__) || defined(__aarch64__)
+#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
+#define XEN_DOMCTL_CONFIG_GIC_V2        1
+#define XEN_DOMCTL_CONFIG_GIC_V3        2
+/* XEN_DOMCTL_configure_domain */
+struct xen_domctl_arm_configuredomain {
+    /* IN/OUT parameters */
+    uint8_t gic_version;
+};
+typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
+#endif
+
 /* XEN_DOMCTL_getdomaininfo */
 struct xen_domctl_getdomaininfo {
     /* OUT variables. */
@@ -1056,6 +1069,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_vcpu_msrs                 73
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
+#define XEN_DOMCTL_arm_configure_domain          76
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1064,6 +1078,9 @@ struct xen_domctl {
     domid_t  domain;
     union {
         struct xen_domctl_createdomain      createdomain;
+#if defined(__arm__) || defined(__aarch64__)
+        struct xen_domctl_arm_configuredomain configuredomain;
+#endif
         struct xen_domctl_getdomaininfo     getdomaininfo;
         struct xen_domctl_getmemlist        getmemlist;
         struct xen_domctl_getpageframeinfo  getpageframeinfo;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d0fe72..846cf88 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_psr_cmt_op:
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
 
+    case XEN_DOMCTL_configure_domain:
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
+
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
         return -EPERM;
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index de0c707..bfe2fa5 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -216,6 +216,8 @@ class domain2
     get_vnumainfo
 # XEN_DOMCTL_psr_cmt_op
     psr_cmt_op
+# XEN_DOMCTL_configure_domain
+    configure_domain
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Sat Nov 01 23:37:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 23: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 1XkiDv-00045v-Gd; Sat, 01 Nov 2014 23:36: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@citrix.com>) id 1XkiDu-00045q-Kx
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 23:36:46 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	D2/B4-27584-D8E65545; Sat, 01 Nov 2014 23:36:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1414885003!8296367!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24942 invoked from network); 1 Nov 2014 23:36:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 23:36:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188600431"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 19:36:41 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkiDp-0005AG-3R;
	Sat, 01 Nov 2014 23:36:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkiDo-0008Ke-Fz;
	Sat, 01 Nov 2014 23:36:40 +0000
Date: Sat, 1 Nov 2014 23:36:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31305-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 5709
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31305: 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: multipart/mixed; boundary="===============2693138369713841726=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2693138369713841726==
Content-Type: text/plain
Content-Length: 5369
Content-Transfer-Encoding: quoted-printable

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt       3 host-install(3)         broken REGR. vs. 31284

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              d91c8e640bf016a359124c8b34aee59774631aa9
baseline version:
 libvirt              720be2eb5f0216564d158dca99c466fac2c16a53

------------------------------------------------------------
People who touched revisions under test:
  Eric Blake <eblake@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Pavel Hrdina <phrdina@redhat.com>
  Weiwei Li <nuonuoli@tencent.com>
  weiwei li <weiweili821@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      broken  


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary

broken-step test-amd64-i386-libvirt host-install(3)

Not pushing.

------------------------------------------------------------
commit d91c8e640bf016a359124c8b34aee59774631aa9
Author: Pavel Hrdina <phrdina@redhat.com>
Date:   Fri Oct 31 19:00:19 2014 +0100

    mingw: fix build failure
    
    This macro seems to be defined only on linux/unix and it fails during
    mingw build. Its value is '16' (taken from net/if.h) so define it if
    it's not defined.
    
    Signed-off-by: Pavel Hrdina <phrdina@redhat.com>

commit 9998a657fdb7e32317e1e725ebf85146e901416c
Author: Eric Blake <eblake@redhat.com>
Date:   Thu Oct 30 13:42:44 2014 -0600

    domain: fix parsing of memory tunables on 32-bit machines
    
    Commit 6c9a8a4 (Oct 2014) exposed a long-standing issue on 32-bit
    machines: code related to virDomainSetMemoryParameters has always
    been documented as using a 64-bit limit, but it was implemented by
    calling virDomainParseMemory which enforced an 'unsigned long'
    limit.  Since VIR_DOMAIN_MEMORY_PARAM_UNLIMITED capped to a
    long is -1, but virDomainParseScaledValue no longer accepts
    negative values, an attempt to use 2^53-1 as a hard memory limit
    started failing the testsuite.  However, the problem with capping
    things artificially low has existed for much longer - ever since
    commits 4888f0fb and 2e22f23 (Mar 2012) switched internal tracking
    from 'unsigned long' to 'unsigned long long' (prior to that time,
    the cap was a side-effect of the choice of types).  We _have_ to
    cap the balloon memory values, (no thanks to baked in 'unsigned long'
    of API such as virDomainSetMaxMemory or virDomainGetInfo with no
    counterpart API that guarantees 64-bit access to those numbers)
    but memory parameters have never needed the artificial limit.
    
    At any rate, the solution is to make the parser function gain a
    parameter, and only do the reduced 32-bit cap for the values that
    are constrained due to API.
    
    * src/conf/domain_conf.h (_virDomainMemtune): Add comments.
    * src/conf/domain_conf.c (virDomainParseMemory): Add parameter.
    (virDomainDefParseXML): Adjust callers.
    
    Signed-off-by: Eric Blake <eblake@redhat.com>

commit be598c5ff84656d3498b950d473fafe5b86f87b4
Author: weiwei li <weiweili821@gmail.com>
Date:   Fri Oct 31 16:16:22 2014 +0800

    qemu: Release nbd port from migrationPorts instead of remotePorts
    
    commit 3e1e16aa8d4238241a1806cb9bdb3b9ad60db777 (Use a port from the
    migration range for NBD as well) changed ndb port allocation from
    remotePorts to migrationPorts, but did not change the port releasing
    process, which makes an error when migrating several times (above 64):
    error: internal error: Unable to find an unused port in range
    'migration' (49152-49215)
    
    https://bugzilla.redhat.com/show_bug.cgi=3Fid=3D1159245
    
    Signed-off-by: Weiwei Li <nuonuoli@tencent.com>
    Signed-off-by: J=C3=A1n Tomko <jtomko@redhat.com>


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

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

--===============2693138369713841726==--

From xen-devel-bounces@lists.xen.org Sat Nov 01 23:37:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Nov 2014 23: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 1XkiDv-00045v-Gd; Sat, 01 Nov 2014 23:36: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@citrix.com>) id 1XkiDu-00045q-Kx
	for xen-devel@lists.xensource.com; Sat, 01 Nov 2014 23:36:46 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	D2/B4-27584-D8E65545; Sat, 01 Nov 2014 23:36:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1414885003!8296367!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24942 invoked from network); 1 Nov 2014 23:36:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Nov 2014 23:36:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188600431"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 19:36:41 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkiDp-0005AG-3R;
	Sat, 01 Nov 2014 23:36:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkiDo-0008Ke-Fz;
	Sat, 01 Nov 2014 23:36:40 +0000
Date: Sat, 1 Nov 2014 23:36:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31305-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 5709
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31305: 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: multipart/mixed; boundary="===============2693138369713841726=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2693138369713841726==
Content-Type: text/plain
Content-Length: 5369
Content-Transfer-Encoding: quoted-printable

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt       3 host-install(3)         broken REGR. vs. 31284

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              d91c8e640bf016a359124c8b34aee59774631aa9
baseline version:
 libvirt              720be2eb5f0216564d158dca99c466fac2c16a53

------------------------------------------------------------
People who touched revisions under test:
  Eric Blake <eblake@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Pavel Hrdina <phrdina@redhat.com>
  Weiwei Li <nuonuoli@tencent.com>
  weiwei li <weiweili821@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      broken  


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary

broken-step test-amd64-i386-libvirt host-install(3)

Not pushing.

------------------------------------------------------------
commit d91c8e640bf016a359124c8b34aee59774631aa9
Author: Pavel Hrdina <phrdina@redhat.com>
Date:   Fri Oct 31 19:00:19 2014 +0100

    mingw: fix build failure
    
    This macro seems to be defined only on linux/unix and it fails during
    mingw build. Its value is '16' (taken from net/if.h) so define it if
    it's not defined.
    
    Signed-off-by: Pavel Hrdina <phrdina@redhat.com>

commit 9998a657fdb7e32317e1e725ebf85146e901416c
Author: Eric Blake <eblake@redhat.com>
Date:   Thu Oct 30 13:42:44 2014 -0600

    domain: fix parsing of memory tunables on 32-bit machines
    
    Commit 6c9a8a4 (Oct 2014) exposed a long-standing issue on 32-bit
    machines: code related to virDomainSetMemoryParameters has always
    been documented as using a 64-bit limit, but it was implemented by
    calling virDomainParseMemory which enforced an 'unsigned long'
    limit.  Since VIR_DOMAIN_MEMORY_PARAM_UNLIMITED capped to a
    long is -1, but virDomainParseScaledValue no longer accepts
    negative values, an attempt to use 2^53-1 as a hard memory limit
    started failing the testsuite.  However, the problem with capping
    things artificially low has existed for much longer - ever since
    commits 4888f0fb and 2e22f23 (Mar 2012) switched internal tracking
    from 'unsigned long' to 'unsigned long long' (prior to that time,
    the cap was a side-effect of the choice of types).  We _have_ to
    cap the balloon memory values, (no thanks to baked in 'unsigned long'
    of API such as virDomainSetMaxMemory or virDomainGetInfo with no
    counterpart API that guarantees 64-bit access to those numbers)
    but memory parameters have never needed the artificial limit.
    
    At any rate, the solution is to make the parser function gain a
    parameter, and only do the reduced 32-bit cap for the values that
    are constrained due to API.
    
    * src/conf/domain_conf.h (_virDomainMemtune): Add comments.
    * src/conf/domain_conf.c (virDomainParseMemory): Add parameter.
    (virDomainDefParseXML): Adjust callers.
    
    Signed-off-by: Eric Blake <eblake@redhat.com>

commit be598c5ff84656d3498b950d473fafe5b86f87b4
Author: weiwei li <weiweili821@gmail.com>
Date:   Fri Oct 31 16:16:22 2014 +0800

    qemu: Release nbd port from migrationPorts instead of remotePorts
    
    commit 3e1e16aa8d4238241a1806cb9bdb3b9ad60db777 (Use a port from the
    migration range for NBD as well) changed ndb port allocation from
    remotePorts to migrationPorts, but did not change the port releasing
    process, which makes an error when migrating several times (above 64):
    error: internal error: Unable to find an unused port in range
    'migration' (49152-49215)
    
    https://bugzilla.redhat.com/show_bug.cgi=3Fid=3D1159245
    
    Signed-off-by: Weiwei Li <nuonuoli@tencent.com>
    Signed-off-by: J=C3=A1n Tomko <jtomko@redhat.com>


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

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

--===============2693138369713841726==--

From xen-devel-bounces@lists.xen.org Sun Nov 02 00:43:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 00: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 1XkjGK-0005JC-1k; Sun, 02 Nov 2014 00:43:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkjGI-0005J7-Jg
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 00:43:18 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	FA/BB-17694-52E75545; Sun, 02 Nov 2014 00:43:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1414888995!6613853!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4974 invoked from network); 2 Nov 2014 00:43:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 00:43:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187236553"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 20:43:13 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkjGD-0005Tv-I8;
	Sun, 02 Nov 2014 00:43:13 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkjGD-0005wp-Ad;
	Sun, 02 Nov 2014 00:43:13 +0000
Date: Sun, 2 Nov 2014 00:43:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31289-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31289: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                    fail pass in 31273
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31253
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate.2 fail in 31273 pass in 31289
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-localmigrate/x10 fail in 31273 pass in 31289
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate/x10 fail in 31273 pass in 31289
 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 31273 pass in 31289
 test-amd64-i386-rhel6hvm-amd 10 guest-destroy      fail in 31253 pass in 31289
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 12 guest-localmigrate.2 fail in 31253 pass in 31289

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              136d4ec190af616bb4fa8624dd9c648e5c9e0d2a
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 311 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 Nov 02 00:43:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 00: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 1XkjGK-0005JC-1k; Sun, 02 Nov 2014 00:43:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkjGI-0005J7-Jg
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 00:43:18 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	FA/BB-17694-52E75545; Sun, 02 Nov 2014 00:43:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1414888995!6613853!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4974 invoked from network); 2 Nov 2014 00:43:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 00:43:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187236553"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 1 Nov 2014 20:43:13 -0400
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkjGD-0005Tv-I8;
	Sun, 02 Nov 2014 00:43:13 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkjGD-0005wp-Ad;
	Sun, 02 Nov 2014 00:43:13 +0000
Date: Sun, 2 Nov 2014 00:43:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31289-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31289: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                    fail pass in 31273
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31253
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate.2 fail in 31273 pass in 31289
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-localmigrate/x10 fail in 31273 pass in 31289
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate/x10 fail in 31273 pass in 31289
 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 31273 pass in 31289
 test-amd64-i386-rhel6hvm-amd 10 guest-destroy      fail in 31253 pass in 31289
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 12 guest-localmigrate.2 fail in 31253 pass in 31289

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              136d4ec190af616bb4fa8624dd9c648e5c9e0d2a
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 311 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 Nov 02 06:04:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 06:04:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkoGH-0006iR-IL; Sun, 02 Nov 2014 06:03:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XkoGF-0006iM-Cj
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 06:03:35 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	AB/1A-03145-639C5545; Sun, 02 Nov 2014 06:03:34 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1414908212!8675543!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19417 invoked from network); 2 Nov 2014 06:03:33 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 06:03:33 -0000
Received: by mail-vc0-f171.google.com with SMTP id lf12so2858610vcb.30
	for <xen-devel@lists.xenproject.org>;
	Sat, 01 Nov 2014 23:03:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=jKxxFErN228pyb/7lCrADJbyW8jx0XhUT/psfrxK4Pw=;
	b=C5gn4WTJSRh19hM1FFy0fXyx1wK6aeWWOVt8+z2fl0074v6PahaXkuVxJQvNwn+wRa
	cMniMY8naOUyRlqEIEO30dQzDDW0OozC7WEnLZTGQ7Ij/h7hZgjE+SYXGASbzsBnGcNv
	RtJoYkwoiD2GLLifDqu5+2NuREmTH+WYHjzAjHAd+ji4Ad2fBo6wVMZbtIKFo4lro36m
	ovsV4PkXydQKUh3omMeSpHyUZxjdVHEny9+IO6WbTzMPCxod6IvOaVBMzkI21+kXMHkv
	Z3KJMe4IF+GXfyOfg1ukrcVEJxtKktYnD3SlZAcpImVCOmw+RHK1vL0WvoUe9c16YVQQ
	tm+A==
MIME-Version: 1.0
X-Received: by 10.52.229.33 with SMTP id sn1mr4785243vdc.53.1414908212346;
	Sat, 01 Nov 2014 23:03:32 -0700 (PDT)
Received: by 10.221.57.8 with HTTP; Sat, 1 Nov 2014 23:03:32 -0700 (PDT)
In-Reply-To: <54551BDD.5080800@linaro.org>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<CAAiw7J=Mbb1YGYj=XQv6TmqyAMvcctUs7AvHQN_1O27xCRSp_Q@mail.gmail.com>
	<20141031142403.GA6913@laptop.dumpdata.com>
	<54539D4D.1040108@linaro.org>
	<20141031210156.GA20039@laptop.dumpdata.com>
	<54551BDD.5080800@linaro.org>
Date: Sun, 2 Nov 2014 11:33:32 +0530
Message-ID: <CAAiw7J=0RbBwTJUS8AP9V88r7D+iKGjMpfF4rH_EOKi1GwBWMw@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com,
	xen-devel <xen-devel@lists.xenproject.org>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [Xen-devel] Xen 4.5-rc1 update (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 1 November 2014 23:13, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Konrad,
>
>
> On 31/10/2014 21:01, Konrad Rzeszutek Wilk wrote:
>>
>> On Fri, Oct 31, 2014 at 02:31:41PM +0000, Julien Grall wrote:
>>>
>>> On 10/31/2014 02:24 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>
>>>>>> *  PVH - PCI passthrough for DomU.
>>>>>
>>>>> I am working on Cavium Thunder (ARM64) on this feature.
>>>>> [Xen SMMU driver changes + PCI passthrough changes in Xen and Linux]
>>>
>>>
>>> FYI, I'm currently reworking the SMMU drivers to resync with Linux. With
>>> thoses changes, you should not need to modify the SMMU code.
>>
>>
>> Thank you for the update. Put your name behind that for 4.6.
>>>
>>>
>>>> Ok, replaced Julien's name with yours. Please make sure
>>>> that for the Linux patches you CC xen-devel and the
>>>> maintainers (David, Stefano, Boris and me).
>>>
>>>
>>> There is 2 distinct passthrough: platform (i.e non-PCI) and PCI one.
>>>
>>> While Manish is working on PCI passthrough, I'm still working the
>>> non-PCI one. Please don't drop my name.
>>
>>
>> I thought that Arianna's patches had taken care of that (the MMIO
>> part?). Or does each platform need a different implementation of
>> that?
>
>
> To passthrough a platform device you need to be able to assign the device to
> the guest via the IOMMU and map MMIOs (done by Arianna's series) and
> interrupts.
>
For a PCI passthrough SMMU ops are to be added. The way the smmu for a
pci device is found needs to be updated in the smmu.c, so there are
some substantial changes to smmu.c for pci passthrough.
Also MMIO mapping code the same pci device to be added.
So in short there changes, and as they are in the same files and
features are also similar,  is it possible that we work together may
be julien can provide a design document (simple txt file would do). I
have already shared mine in another mail thread with stefano.


> There is also a toolstack part to add the description of the device in the
> device tree. See the V2 [1] for more details.
>
> [1] http://lists.xen.org/archives/html/xen-devel/2014-07/msg04090.html
>
> Regards,
>
> --
> Julien Grall
>

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 06:04:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 06:04:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkoGH-0006iR-IL; Sun, 02 Nov 2014 06:03:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XkoGF-0006iM-Cj
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 06:03:35 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	AB/1A-03145-639C5545; Sun, 02 Nov 2014 06:03:34 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1414908212!8675543!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19417 invoked from network); 2 Nov 2014 06:03:33 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 06:03:33 -0000
Received: by mail-vc0-f171.google.com with SMTP id lf12so2858610vcb.30
	for <xen-devel@lists.xenproject.org>;
	Sat, 01 Nov 2014 23:03:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=jKxxFErN228pyb/7lCrADJbyW8jx0XhUT/psfrxK4Pw=;
	b=C5gn4WTJSRh19hM1FFy0fXyx1wK6aeWWOVt8+z2fl0074v6PahaXkuVxJQvNwn+wRa
	cMniMY8naOUyRlqEIEO30dQzDDW0OozC7WEnLZTGQ7Ij/h7hZgjE+SYXGASbzsBnGcNv
	RtJoYkwoiD2GLLifDqu5+2NuREmTH+WYHjzAjHAd+ji4Ad2fBo6wVMZbtIKFo4lro36m
	ovsV4PkXydQKUh3omMeSpHyUZxjdVHEny9+IO6WbTzMPCxod6IvOaVBMzkI21+kXMHkv
	Z3KJMe4IF+GXfyOfg1ukrcVEJxtKktYnD3SlZAcpImVCOmw+RHK1vL0WvoUe9c16YVQQ
	tm+A==
MIME-Version: 1.0
X-Received: by 10.52.229.33 with SMTP id sn1mr4785243vdc.53.1414908212346;
	Sat, 01 Nov 2014 23:03:32 -0700 (PDT)
Received: by 10.221.57.8 with HTTP; Sat, 1 Nov 2014 23:03:32 -0700 (PDT)
In-Reply-To: <54551BDD.5080800@linaro.org>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<CAAiw7J=Mbb1YGYj=XQv6TmqyAMvcctUs7AvHQN_1O27xCRSp_Q@mail.gmail.com>
	<20141031142403.GA6913@laptop.dumpdata.com>
	<54539D4D.1040108@linaro.org>
	<20141031210156.GA20039@laptop.dumpdata.com>
	<54551BDD.5080800@linaro.org>
Date: Sun, 2 Nov 2014 11:33:32 +0530
Message-ID: <CAAiw7J=0RbBwTJUS8AP9V88r7D+iKGjMpfF4rH_EOKi1GwBWMw@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com,
	xen-devel <xen-devel@lists.xenproject.org>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [Xen-devel] Xen 4.5-rc1 update (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 1 November 2014 23:13, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Konrad,
>
>
> On 31/10/2014 21:01, Konrad Rzeszutek Wilk wrote:
>>
>> On Fri, Oct 31, 2014 at 02:31:41PM +0000, Julien Grall wrote:
>>>
>>> On 10/31/2014 02:24 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>
>>>>>> *  PVH - PCI passthrough for DomU.
>>>>>
>>>>> I am working on Cavium Thunder (ARM64) on this feature.
>>>>> [Xen SMMU driver changes + PCI passthrough changes in Xen and Linux]
>>>
>>>
>>> FYI, I'm currently reworking the SMMU drivers to resync with Linux. With
>>> thoses changes, you should not need to modify the SMMU code.
>>
>>
>> Thank you for the update. Put your name behind that for 4.6.
>>>
>>>
>>>> Ok, replaced Julien's name with yours. Please make sure
>>>> that for the Linux patches you CC xen-devel and the
>>>> maintainers (David, Stefano, Boris and me).
>>>
>>>
>>> There is 2 distinct passthrough: platform (i.e non-PCI) and PCI one.
>>>
>>> While Manish is working on PCI passthrough, I'm still working the
>>> non-PCI one. Please don't drop my name.
>>
>>
>> I thought that Arianna's patches had taken care of that (the MMIO
>> part?). Or does each platform need a different implementation of
>> that?
>
>
> To passthrough a platform device you need to be able to assign the device to
> the guest via the IOMMU and map MMIOs (done by Arianna's series) and
> interrupts.
>
For a PCI passthrough SMMU ops are to be added. The way the smmu for a
pci device is found needs to be updated in the smmu.c, so there are
some substantial changes to smmu.c for pci passthrough.
Also MMIO mapping code the same pci device to be added.
So in short there changes, and as they are in the same files and
features are also similar,  is it possible that we work together may
be julien can provide a design document (simple txt file would do). I
have already shared mine in another mail thread with stefano.


> There is also a toolstack part to add the description of the device in the
> device tree. See the V2 [1] for more details.
>
> [1] http://lists.xen.org/archives/html/xen-devel/2014-07/msg04090.html
>
> Regards,
>
> --
> Julien Grall
>

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 07:20:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 07:20:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkpRq-0007ZW-5F; Sun, 02 Nov 2014 07:19:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkpRo-0007Z4-M7
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 07:19:36 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	0E/24-28296-70BD5545; Sun, 02 Nov 2014 07:19:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1414912773!7348621!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19735 invoked from network); 2 Nov 2014 07:19:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 07:19:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188638430"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 02:19:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkpRj-0007SS-Fa;
	Sun, 02 Nov 2014 07:19:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkpRj-0005zm-8L;
	Sun, 02 Nov 2014 07:19:31 +0000
Date: Sun, 2 Nov 2014 07:19:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31301-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9785
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31301: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0379862838285841701=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0379862838285841701==
Content-Type: text/plain
Content-Length: 9509
Content-Transfer-Encoding: quoted-printable

flight 31301 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31301/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass

version targeted for testing:
 qemuu                ee29498e4f0f3eff90eeeb7f5fa1703abedd2fb6
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Walle <michael@walle.cc> (for lm32)
  Mikhail Ilyin <m.ilin@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============0379862838285841701==--

From xen-devel-bounces@lists.xen.org Sun Nov 02 07:20:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 07:20:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkpRq-0007ZW-5F; Sun, 02 Nov 2014 07:19:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkpRo-0007Z4-M7
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 07:19:36 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	0E/24-28296-70BD5545; Sun, 02 Nov 2014 07:19:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1414912773!7348621!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19735 invoked from network); 2 Nov 2014 07:19:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 07:19:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188638430"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 02:19:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkpRj-0007SS-Fa;
	Sun, 02 Nov 2014 07:19:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkpRj-0005zm-8L;
	Sun, 02 Nov 2014 07:19:31 +0000
Date: Sun, 2 Nov 2014 07:19:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31301-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9785
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31301: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0379862838285841701=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0379862838285841701==
Content-Type: text/plain
Content-Length: 9509
Content-Transfer-Encoding: quoted-printable

flight 31301 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31301/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass

version targeted for testing:
 qemuu                ee29498e4f0f3eff90eeeb7f5fa1703abedd2fb6
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Walle <michael@walle.cc> (for lm32)
  Mikhail Ilyin <m.ilin@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============0379862838285841701==--

From xen-devel-bounces@lists.xen.org Sun Nov 02 09:58:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 09:58:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkrvB-00018s-R7; Sun, 02 Nov 2014 09:58:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xkrv9-00018n-Nb
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 09:58:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	06/98-09936-A2006545; Sun, 02 Nov 2014 09:58:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1414922281!8737021!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21380 invoked from network); 2 Nov 2014 09:58:02 -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;
	2 Nov 2014 09:58:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187284990"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 04:57:59 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xkrv5-0008DE-0I;
	Sun, 02 Nov 2014 09:57:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xkrv4-00052k-PY;
	Sun, 02 Nov 2014 09:57:58 +0000
Date: Sun, 2 Nov 2014 09:57:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31309-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31309: 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 31309 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31309/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 26303
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install   fail pass in 31280
 test-amd64-i386-freebsd10-i386  3 host-install(3)         broken pass in 31280
 test-amd64-i386-xl-qemuu-winxpsp3 12 guest-localmigrate.2 fail in 31280 pass in 31309

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

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

broken-step test-amd64-i386-freebsd10-i386 host-install(3)

Not pushing.

(No revision log; it would be 27231 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 Nov 02 09:58:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 09:58:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkrvB-00018s-R7; Sun, 02 Nov 2014 09:58:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xkrv9-00018n-Nb
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 09:58:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	06/98-09936-A2006545; Sun, 02 Nov 2014 09:58:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1414922281!8737021!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21380 invoked from network); 2 Nov 2014 09:58:02 -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;
	2 Nov 2014 09:58:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187284990"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 04:57:59 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xkrv5-0008DE-0I;
	Sun, 02 Nov 2014 09:57:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xkrv4-00052k-PY;
	Sun, 02 Nov 2014 09:57:58 +0000
Date: Sun, 2 Nov 2014 09:57:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31309-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31309: 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 31309 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31309/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 26303
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install   fail pass in 31280
 test-amd64-i386-freebsd10-i386  3 host-install(3)         broken pass in 31280
 test-amd64-i386-xl-qemuu-winxpsp3 12 guest-localmigrate.2 fail in 31280 pass in 31309

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

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

broken-step test-amd64-i386-freebsd10-i386 host-install(3)

Not pushing.

(No revision log; it would be 27231 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 Nov 02 10:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XksEO-0001XQ-Q3; Sun, 02 Nov 2014 10:17:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XksEN-0001XL-8E
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 10:17:55 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	06/F9-17735-2D406545; Sun, 02 Nov 2014 10:17:54 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-31.messagelabs.com!1414923473!10962142!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5881 invoked from network); 2 Nov 2014 10:17:53 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 10:17:53 -0000
Received: by mail-wg0-f41.google.com with SMTP id k14so9184036wgh.28
	for <xen-devel@lists.xenproject.org>;
	Sun, 02 Nov 2014 02:17:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=mFQpKhAMgbJWFN9Mb3Zh65O49aL2I526FVka2XzkaHM=;
	b=dp/FD8742OVF7RlGAplomranIc+uyLDHTo4saOOJAonYi27i6AsH20FdAC9eVdOT4d
	2wuSs16pkDFudln9QIwFXVdGZTpIxsOZEGnZymtySvTQM4wfeZQSgksDRjO/QzzTWj1v
	Qp7ZK9PyNYvXHYLIaEOBcj6jeGIjm3g5Xvr//1TdQSizG5dzEW9F48bsn+OILLkKQ54H
	aj0iZO+kii1CYpA2UvYQQmDFPnPE/5uo8aT+ZEf4robyJi1dFPfSa3IeneQX2EU7tFw2
	g2A2+HqyrwKcTPMzS46efcMZV1kEVXn2HeDYE06V3cgGoVrKwBt5zOBgCqOERYIKu2Zc
	SmMQ==
X-Gm-Message-State: ALoCoQlisofN9zy67EshP9Wk3eeQHV+6VdORc7pPImF+SfHIal7p8U83f4pH5Ce6TM6cF6dcaXpr
X-Received: by 10.180.88.102 with SMTP id bf6mr8734831wib.43.1414923473251;
	Sun, 02 Nov 2014 02:17:53 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id
	ws2sm18116858wjc.32.2014.11.02.02.17.51 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 02 Nov 2014 02:17:52 -0800 (PST)
Message-ID: <545604CF.60905@linaro.org>
Date: Sun, 02 Nov 2014 10:17:51 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>	<CAAiw7J=Mbb1YGYj=XQv6TmqyAMvcctUs7AvHQN_1O27xCRSp_Q@mail.gmail.com>	<20141031142403.GA6913@laptop.dumpdata.com>	<54539D4D.1040108@linaro.org>	<20141031210156.GA20039@laptop.dumpdata.com>	<54551BDD.5080800@linaro.org>
	<CAAiw7J=0RbBwTJUS8AP9V88r7D+iKGjMpfF4rH_EOKi1GwBWMw@mail.gmail.com>
In-Reply-To: <CAAiw7J=0RbBwTJUS8AP9V88r7D+iKGjMpfF4rH_EOKi1GwBWMw@mail.gmail.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com,
	xen-devel <xen-devel@lists.xenproject.org>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: [Xen-devel] [ARM] SMMU and PCI passthrough Was: Re: Xen 4.5-rc1
 update (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(Renaming the subject of the thread).

On 02/11/2014 06:03, manish jaggi wrote:
> On 1 November 2014 23:13, Julien Grall <julien.grall@linaro.org> wrote:
>> Hi Konrad,
>>
>>
>> On 31/10/2014 21:01, Konrad Rzeszutek Wilk wrote:
>>>
>>> On Fri, Oct 31, 2014 at 02:31:41PM +0000, Julien Grall wrote:
>>>>
>>>> On 10/31/2014 02:24 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>
>>>>>>> *  PVH - PCI passthrough for DomU.
>>>>>>
>>>>>> I am working on Cavium Thunder (ARM64) on this feature.
>>>>>> [Xen SMMU driver changes + PCI passthrough changes in Xen and Linux]
>>>>
>>>>
>>>> FYI, I'm currently reworking the SMMU drivers to resync with Linux. With
>>>> thoses changes, you should not need to modify the SMMU code.
>>>
>>>
>>> Thank you for the update. Put your name behind that for 4.6.
>>>>
>>>>
>>>>> Ok, replaced Julien's name with yours. Please make sure
>>>>> that for the Linux patches you CC xen-devel and the
>>>>> maintainers (David, Stefano, Boris and me).
>>>>
>>>>
>>>> There is 2 distinct passthrough: platform (i.e non-PCI) and PCI one.
>>>>
>>>> While Manish is working on PCI passthrough, I'm still working the
>>>> non-PCI one. Please don't drop my name.
>>>
>>>
>>> I thought that Arianna's patches had taken care of that (the MMIO
>>> part?). Or does each platform need a different implementation of
>>> that?
>>
>>
>> To passthrough a platform device you need to be able to assign the device to
>> the guest via the IOMMU and map MMIOs (done by Arianna's series) and
>> interrupts.
>>
> For a PCI passthrough SMMU ops are to be added. The way the smmu for a
> pci device is found needs to be updated in the smmu.c, so there are
> some substantial changes to smmu.c for pci passthrough.

The SMMU drivers in Linux already supports PCI. As I'm currently resync 
our driver with this version PCI assignment in the SMMU should come freely.

I expect the only plumbing for the Xen callback and few bugs fixes will 
be necessary.

> Also MMIO mapping code the same pci device to be added.

Hmmm? What do you mean? MMIO mapping code is definitely not part of the 
SMMU drivers.

IIRC, this should be done by either the toolstack or PCI back in Linux.

> So in short there changes, and as they are in the same files and
> features are also similar,  is it possible that we work together may
> be julien can provide a design document (simple txt file would do).

There is no need of design document for the SMMU drivers. Everything for 
DT passthrough is already there.

 > I
> have already shared mine in another mail thread with stefano.

Could you send a link to this mail?

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 10:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XksEO-0001XQ-Q3; Sun, 02 Nov 2014 10:17:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XksEN-0001XL-8E
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 10:17:55 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	06/F9-17735-2D406545; Sun, 02 Nov 2014 10:17:54 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-31.messagelabs.com!1414923473!10962142!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5881 invoked from network); 2 Nov 2014 10:17:53 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 10:17:53 -0000
Received: by mail-wg0-f41.google.com with SMTP id k14so9184036wgh.28
	for <xen-devel@lists.xenproject.org>;
	Sun, 02 Nov 2014 02:17:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=mFQpKhAMgbJWFN9Mb3Zh65O49aL2I526FVka2XzkaHM=;
	b=dp/FD8742OVF7RlGAplomranIc+uyLDHTo4saOOJAonYi27i6AsH20FdAC9eVdOT4d
	2wuSs16pkDFudln9QIwFXVdGZTpIxsOZEGnZymtySvTQM4wfeZQSgksDRjO/QzzTWj1v
	Qp7ZK9PyNYvXHYLIaEOBcj6jeGIjm3g5Xvr//1TdQSizG5dzEW9F48bsn+OILLkKQ54H
	aj0iZO+kii1CYpA2UvYQQmDFPnPE/5uo8aT+ZEf4robyJi1dFPfSa3IeneQX2EU7tFw2
	g2A2+HqyrwKcTPMzS46efcMZV1kEVXn2HeDYE06V3cgGoVrKwBt5zOBgCqOERYIKu2Zc
	SmMQ==
X-Gm-Message-State: ALoCoQlisofN9zy67EshP9Wk3eeQHV+6VdORc7pPImF+SfHIal7p8U83f4pH5Ce6TM6cF6dcaXpr
X-Received: by 10.180.88.102 with SMTP id bf6mr8734831wib.43.1414923473251;
	Sun, 02 Nov 2014 02:17:53 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id
	ws2sm18116858wjc.32.2014.11.02.02.17.51 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 02 Nov 2014 02:17:52 -0800 (PST)
Message-ID: <545604CF.60905@linaro.org>
Date: Sun, 02 Nov 2014 10:17:51 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>	<CAAiw7J=Mbb1YGYj=XQv6TmqyAMvcctUs7AvHQN_1O27xCRSp_Q@mail.gmail.com>	<20141031142403.GA6913@laptop.dumpdata.com>	<54539D4D.1040108@linaro.org>	<20141031210156.GA20039@laptop.dumpdata.com>	<54551BDD.5080800@linaro.org>
	<CAAiw7J=0RbBwTJUS8AP9V88r7D+iKGjMpfF4rH_EOKi1GwBWMw@mail.gmail.com>
In-Reply-To: <CAAiw7J=0RbBwTJUS8AP9V88r7D+iKGjMpfF4rH_EOKi1GwBWMw@mail.gmail.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com,
	xen-devel <xen-devel@lists.xenproject.org>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: [Xen-devel] [ARM] SMMU and PCI passthrough Was: Re: Xen 4.5-rc1
 update (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(Renaming the subject of the thread).

On 02/11/2014 06:03, manish jaggi wrote:
> On 1 November 2014 23:13, Julien Grall <julien.grall@linaro.org> wrote:
>> Hi Konrad,
>>
>>
>> On 31/10/2014 21:01, Konrad Rzeszutek Wilk wrote:
>>>
>>> On Fri, Oct 31, 2014 at 02:31:41PM +0000, Julien Grall wrote:
>>>>
>>>> On 10/31/2014 02:24 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>
>>>>>>> *  PVH - PCI passthrough for DomU.
>>>>>>
>>>>>> I am working on Cavium Thunder (ARM64) on this feature.
>>>>>> [Xen SMMU driver changes + PCI passthrough changes in Xen and Linux]
>>>>
>>>>
>>>> FYI, I'm currently reworking the SMMU drivers to resync with Linux. With
>>>> thoses changes, you should not need to modify the SMMU code.
>>>
>>>
>>> Thank you for the update. Put your name behind that for 4.6.
>>>>
>>>>
>>>>> Ok, replaced Julien's name with yours. Please make sure
>>>>> that for the Linux patches you CC xen-devel and the
>>>>> maintainers (David, Stefano, Boris and me).
>>>>
>>>>
>>>> There is 2 distinct passthrough: platform (i.e non-PCI) and PCI one.
>>>>
>>>> While Manish is working on PCI passthrough, I'm still working the
>>>> non-PCI one. Please don't drop my name.
>>>
>>>
>>> I thought that Arianna's patches had taken care of that (the MMIO
>>> part?). Or does each platform need a different implementation of
>>> that?
>>
>>
>> To passthrough a platform device you need to be able to assign the device to
>> the guest via the IOMMU and map MMIOs (done by Arianna's series) and
>> interrupts.
>>
> For a PCI passthrough SMMU ops are to be added. The way the smmu for a
> pci device is found needs to be updated in the smmu.c, so there are
> some substantial changes to smmu.c for pci passthrough.

The SMMU drivers in Linux already supports PCI. As I'm currently resync 
our driver with this version PCI assignment in the SMMU should come freely.

I expect the only plumbing for the Xen callback and few bugs fixes will 
be necessary.

> Also MMIO mapping code the same pci device to be added.

Hmmm? What do you mean? MMIO mapping code is definitely not part of the 
SMMU drivers.

IIRC, this should be done by either the toolstack or PCI back in Linux.

> So in short there changes, and as they are in the same files and
> features are also similar,  is it possible that we work together may
> be julien can provide a design document (simple txt file would do).

There is no need of design document for the SMMU drivers. Everything for 
DT passthrough is already there.

 > I
> have already shared mine in another mail thread with stefano.

Could you send a link to this mail?

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 10:43:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkscT-0001tQ-3H; Sun, 02 Nov 2014 10:42:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XkscR-0001ss-W7
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 10:42:48 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	66/F7-23865-7AA06545; Sun, 02 Nov 2014 10:42:47 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1414924965!11104611!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5644 invoked from network); 2 Nov 2014 10:42:46 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-11.tower-31.messagelabs.com with SMTP;
	2 Nov 2014 10:42:46 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 02 Nov 2014 02:36:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="409897928"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 02 Nov 2014 02:34:24 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 01:39:17 -0500
Message-Id: <1414910357-27644-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com,
	armbru@redhat.com, lcapitulino@redhat.com, aliguori@amazon.com,
	pbonzini@redhat.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for
	HVM virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series are only the Qemu part to enable Xen stubdom vTPM for HVM virtual 
machine. it will work w/ Xen patch series and seaBios patch series.

..
Build it with --enable-tpm and --enable-xen options and link with Xen, or change 
QEMU_STUBDOM_VTPM compile option from 'n' to 'y' in <Xen>/Config.mk, when the Qemu/
SeaBios patch series are merged.

..
Run Xen virtual mahcine with below QEMU command line options:
  "-tpmdev xenstubdoms,id=xenvtpm0 -device tpm-tis,tpmdev=xenvtpm0" 

or Xen xl tool adds this options when virtual machine cfg includes:

  ** 
  vtpm=["backend=vtpmN"]
  **

..
qemu-system-* --tpmdev help
Supported TPM types (choose only one):
 passthrough   Passthrough TPM backend driver
 xenstubdoms   Xenstubdoms TPM backend driver



Signed-off-by: Quan Xu <quan.xu@intel.com>

 configure                    |  13 ++++
 hmp.c                        |   7 ++
 hw/tpm/Makefile.objs         |   1 +
 hw/tpm/tpm_xenstubdoms.c     | 238 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen/Makefile.objs         |   1 +
 hw/xen/xen_backend.c         | 181 ++++++++++++++++++++++++++++++++++++++++++++++-
 hw/xen/xen_stubdom_vtpm.c    | 323 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  11 +++
 include/hw/xen/xen_common.h  |   7 ++
 qapi-schema.json             |  17 ++++-
 qemu-options.hx              |  13 +++-
 tpm.c                        |   7 +-
 vl.c                         |  16 +++--
 xen-hvm.c                    |  13 ++++
 14 files changed, 835 insertions(+), 13 deletions(-)


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 10:43:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkscY-0001tx-GI; Sun, 02 Nov 2014 10:42:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XkscW-0001tn-KA
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 10:42:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	15/F4-24532-CAA06545; Sun, 02 Nov 2014 10:42:52 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1414924970!4155303!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25111 invoked from network); 2 Nov 2014 10:42:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	2 Nov 2014 10:42:50 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 02 Nov 2014 02:42:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,295,1413270000"; d="scan'208";a="600565166"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 02 Nov 2014 02:42:48 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 01:39:21 -0500
Message-Id: <1414910361-27681-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: lcapitulino@redhat.com, armbru@redhat.com, Quan Xu <quan.xu@intel.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] Qemu-Xen-vTPM: Support for Xen stubdom vTPM
	command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 configure        | 14 ++++++++++++++
 hmp.c            |  7 +++++++
 qapi-schema.json | 17 +++++++++++++++--
 qemu-options.hx  | 13 +++++++++++--
 tpm.c            |  7 ++++++-
 5 files changed, 53 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index a9e4d49..d63b8a1 100755
--- a/configure
+++ b/configure
@@ -2942,6 +2942,16 @@ else
 fi
 
 ##########################################
+# TPM xenstubdoms is only on x86 Linux
+
+if test "$targetos" = Linux && test "$cpu" = i386 -o "$cpu" = x86_64 && \
+   test "$xen" = "yes"; then
+  tpm_xenstubdoms=$tpm
+else
+  tpm_xenstubdoms=no
+fi
+
+##########################################
 # attr probe
 
 if test "$attr" != "no" ; then
@@ -4333,6 +4343,7 @@ echo "gcov              $gcov_tool"
 echo "gcov enabled      $gcov"
 echo "TPM support       $tpm"
 echo "libssh2 support   $libssh2"
+echo "TPM xenstubdoms   $tpm_xenstubdoms"
 echo "TPM passthrough   $tpm_passthrough"
 echo "QOM debugging     $qom_cast_debug"
 echo "vhdx              $vhdx"
@@ -4810,6 +4821,9 @@ if test "$tpm" = "yes"; then
   if test "$tpm_passthrough" = "yes"; then
     echo "CONFIG_TPM_PASSTHROUGH=y" >> $config_host_mak
   fi
+  if test "$tpm_xenstubdoms" = "yes"; then
+    echo "CONFIG_TPM_XENSTUBDOMS=y" >> $config_host_mak
+  fi
 fi
 
 echo "TRACE_BACKENDS=$trace_backends" >> $config_host_mak
diff --git a/hmp.c b/hmp.c
index 63d7686..5d2bcf9 100644
--- a/hmp.c
+++ b/hmp.c
@@ -689,6 +689,7 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
     Error *err = NULL;
     unsigned int c = 0;
     TPMPassthroughOptions *tpo;
+    TPMXenstubdomsOptions *txo;
 
     info_list = qmp_query_tpm(&err);
     if (err) {
@@ -718,6 +719,12 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
                            tpo->has_cancel_path ? ",cancel-path=" : "",
                            tpo->has_cancel_path ? tpo->cancel_path : "");
             break;
+       case TPM_TYPE_OPTIONS_KIND_XENSTUBDOMS:
+            txo = ti->options->xenstubdoms;
+            if (!txo) {
+                monitor_printf(mon, "null TPMXenstubdomsOptions error!\n");
+            }
+            break;
         case TPM_TYPE_OPTIONS_KIND_MAX:
             break;
         }
diff --git a/qapi-schema.json b/qapi-schema.json
index 24379ab..23ecb4b 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2853,10 +2853,11 @@
 # An enumeration of TPM types
 #
 # @passthrough: TPM passthrough type
+# @xenstubdoms: TPM xenstubdoms type
 #
 # Since: 1.5
 ##
-{ 'enum': 'TpmType', 'data': [ 'passthrough' ] }
+{ 'enum': 'TpmType', 'data': [ 'passthrough', 'xenstubdoms' ] }
 
 ##
 # @query-tpm-types:
@@ -2884,6 +2885,16 @@
 { 'type': 'TPMPassthroughOptions', 'data': { '*path' : 'str',
                                              '*cancel-path' : 'str'} }
 
+# @TPMXenstubdomsOptions:
+#
+# Information about the TPM xenstubdoms type
+#
+# Since: > 2.1.0
+##
+{ 'type': 'TPMXenstubdomsOptions', 'data': {  } }
+#
+##
+
 ##
 # @TpmTypeOptions:
 #
@@ -2894,7 +2905,9 @@
 # Since: 1.5
 ##
 { 'union': 'TpmTypeOptions',
-   'data': { 'passthrough' : 'TPMPassthroughOptions' } }
+  'data': { 'passthrough' : 'TPMPassthroughOptions',
+            'xenstubdoms' : 'TPMXenstubdomsOptions' } }
+##
 
 ##
 # @TpmInfo:
diff --git a/qemu-options.hx b/qemu-options.hx
index 1e7d5b8..fd73f57 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2485,7 +2485,8 @@ DEF("tpmdev", HAS_ARG, QEMU_OPTION_tpmdev, \
     "-tpmdev passthrough,id=id[,path=path][,cancel-path=path]\n"
     "                use path to provide path to a character device; default is /dev/tpm0\n"
     "                use cancel-path to provide path to TPM's cancel sysfs entry; if\n"
-    "                not provided it will be searched for in /sys/class/misc/tpm?/device\n",
+    "                not provided it will be searched for in /sys/class/misc/tpm?/device\n"
+    "-tpmdev xenstubdoms,id=id\n",
     QEMU_ARCH_ALL)
 STEXI
 
@@ -2495,7 +2496,8 @@ The general form of a TPM device option is:
 @item -tpmdev @var{backend} ,id=@var{id} [,@var{options}]
 @findex -tpmdev
 Backend type must be:
-@option{passthrough}.
+@option{passthrough}, or
+@option{xenstubdoms}.
 
 The specific backend type will determine the applicable options.
 The @code{-tpmdev} option creates the TPM backend and requires a
@@ -2545,6 +2547,13 @@ To create a passthrough TPM use the following two options:
 Note that the @code{-tpmdev} id is @code{tpm0} and is referenced by
 @code{tpmdev=tpm0} in the device option.
 
+To create a xenstubdoms TPM use the following two options:
+@example
+-tpmdev xenstubdoms,id=tpm0 -device tpm-tis,tpmdev=tpm0
+@end example
+Note that the @code{-tpmdev} id is @code{tpm0} and is referenced by
+@code{tpmdev=tpm0} in the device option.
+
 @end table
 
 ETEXI
diff --git a/tpm.c b/tpm.c
index c371023..ee9acb8 100644
--- a/tpm.c
+++ b/tpm.c
@@ -25,7 +25,7 @@ static QLIST_HEAD(, TPMBackend) tpm_backends =
 
 
 #define TPM_MAX_MODELS      1
-#define TPM_MAX_DRIVERS     1
+#define TPM_MAX_DRIVERS     2
 
 static TPMDriverOps const *be_drivers[TPM_MAX_DRIVERS] = {
     NULL,
@@ -256,6 +256,7 @@ static TPMInfo *qmp_query_tpm_inst(TPMBackend *drv)
 {
     TPMInfo *res = g_new0(TPMInfo, 1);
     TPMPassthroughOptions *tpo;
+    TPMXenstubdomsOptions *txo;
 
     res->id = g_strdup(drv->id);
     res->model = drv->fe_model;
@@ -275,6 +276,10 @@ static TPMInfo *qmp_query_tpm_inst(TPMBackend *drv)
             tpo->has_cancel_path = true;
         }
         break;
+    case TPM_TYPE_XENSTUBDOMS:
+        res->options->kind = TPM_TYPE_OPTIONS_KIND_XENSTUBDOMS;
+        txo = g_new0(TPMXenstubdomsOptions, 1);
+        res->options->xenstubdoms = txo;
     case TPM_TYPE_MAX:
         break;
     }
-- 
1.8.3.2


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 10:43:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkscT-0001tQ-3H; Sun, 02 Nov 2014 10:42:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XkscR-0001ss-W7
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 10:42:48 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	66/F7-23865-7AA06545; Sun, 02 Nov 2014 10:42:47 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1414924965!11104611!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5644 invoked from network); 2 Nov 2014 10:42:46 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-11.tower-31.messagelabs.com with SMTP;
	2 Nov 2014 10:42:46 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 02 Nov 2014 02:36:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="409897928"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 02 Nov 2014 02:34:24 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 01:39:17 -0500
Message-Id: <1414910357-27644-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com,
	armbru@redhat.com, lcapitulino@redhat.com, aliguori@amazon.com,
	pbonzini@redhat.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for
	HVM virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series are only the Qemu part to enable Xen stubdom vTPM for HVM virtual 
machine. it will work w/ Xen patch series and seaBios patch series.

..
Build it with --enable-tpm and --enable-xen options and link with Xen, or change 
QEMU_STUBDOM_VTPM compile option from 'n' to 'y' in <Xen>/Config.mk, when the Qemu/
SeaBios patch series are merged.

..
Run Xen virtual mahcine with below QEMU command line options:
  "-tpmdev xenstubdoms,id=xenvtpm0 -device tpm-tis,tpmdev=xenvtpm0" 

or Xen xl tool adds this options when virtual machine cfg includes:

  ** 
  vtpm=["backend=vtpmN"]
  **

..
qemu-system-* --tpmdev help
Supported TPM types (choose only one):
 passthrough   Passthrough TPM backend driver
 xenstubdoms   Xenstubdoms TPM backend driver



Signed-off-by: Quan Xu <quan.xu@intel.com>

 configure                    |  13 ++++
 hmp.c                        |   7 ++
 hw/tpm/Makefile.objs         |   1 +
 hw/tpm/tpm_xenstubdoms.c     | 238 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen/Makefile.objs         |   1 +
 hw/xen/xen_backend.c         | 181 ++++++++++++++++++++++++++++++++++++++++++++++-
 hw/xen/xen_stubdom_vtpm.c    | 323 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  11 +++
 include/hw/xen/xen_common.h  |   7 ++
 qapi-schema.json             |  17 ++++-
 qemu-options.hx              |  13 +++-
 tpm.c                        |   7 +-
 vl.c                         |  16 +++--
 xen-hvm.c                    |  13 ++++
 14 files changed, 835 insertions(+), 13 deletions(-)


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 10:43:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkscb-0001uO-Se; Sun, 02 Nov 2014 10:42:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xkscb-0001uE-1r
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 10:42:57 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	52/08-24124-0BA06545; Sun, 02 Nov 2014 10:42:56 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1414924973!8945122!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25140 invoked from network); 2 Nov 2014 10:42:54 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-206.messagelabs.com with SMTP;
	2 Nov 2014 10:42:54 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 02 Nov 2014 02:41:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,295,1413270000"; d="scan'208";a="629795495"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 02 Nov 2014 02:42:51 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 01:39:25 -0500
Message-Id: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: stefano.stabellini@eu.citrix.com, Quan Xu <quan.xu@intel.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
	frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This drvier transfers any request/repond between TPM xenstubdoms
driver and Xen vTPM stubdom, and facilitates communications between
Xen vTPM stubdom domain and vTPM xenstubdoms driver

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/xen/Makefile.objs         |   1 +
 hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
 hw/xen/xen_stubdom_vtpm.c    | 333 +++++++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  11 ++
 include/hw/xen/xen_common.h  |   6 +
 xen-hvm.c                    |  13 ++
 6 files changed, 544 insertions(+), 2 deletions(-)
 create mode 100644 hw/xen/xen_stubdom_vtpm.c

diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index a0ca0aa..724df8d 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,6 @@
 # xen backend driver support
 common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
 
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..45a5778 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state)
     return 0;
 }
 
+/*get stubdom backend*/
+static char *xen_stubdom_be(const char *type, int dom, int dev)
+{
+    char *val, *domu;
+    char path[XEN_BUFSIZE];
+    unsigned int len, ival;
+
+    /*front domu*/
+    domu = xs_get_domain_path(xenstore, dom);
+    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
+             domu, type, dev);
+    g_free(domu);
+
+    val = xs_read(xenstore, 0, path, &len);
+    if (!val || 1 != sscanf(val, "%d", &ival)) {
+        g_free(val);
+        return NULL;
+    }
+    g_free(val);
+
+    /*backend domu*/
+    domu = xs_get_domain_path(xenstore, ival);
+
+    return domu;
+}
+
 /* ------------------------------------------------------------- */
 
 struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
@@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
                                            struct XenDevOps *ops)
 {
     struct XenDevice *xendev;
+    char *stub;
 
     xendev = xen_be_find_xendev(type, dom, dev);
     if (xendev) {
@@ -235,8 +262,15 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
     xendev->dev   = dev;
     xendev->ops   = ops;
 
-    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
-             xendev->type, xendev->dom, xendev->dev);
+    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
+        stub = xen_stubdom_be(xendev->type, xendev->dom, xendev->dev);
+        snprintf(xendev->be, sizeof(xendev->be), "%s/backend/%s/%d/%d",
+                 stub, xendev->type, xendev->dom, xendev->dev);
+        g_free(stub);
+    } else {
+        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
+                 xendev->type, xendev->dom, xendev->dev);
+    }
     snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
              xendev->type, xendev->dev);
 
@@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int dom, struct XenDevOps *ops)
     return 0;
 }
 
+static void stubdom_update_be(char *watch, char *type, int dom,
+                              struct XenDevOps *ops)
+{
+    struct XenDevice *xendev;
+    char path[XEN_BUFSIZE];
+    char *ptr, *bepath;
+    unsigned int len, dev;
+
+    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
+        return;
+    }
+
+    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
+    ptr = strstr(watch, path);
+    if (ptr == NULL) {
+        return;
+    }
+
+    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
+        strcpy(path, "");
+        if (sscanf(ptr+len, "/%u", &dev) != 1) {
+            dev = -1;
+        }
+    }
+
+    if (dev == -1) {
+        return;
+    }
+
+    xendev = xen_be_get_xendev(type, dom, dev, ops);
+    if (xendev != NULL) {
+        bepath = xs_read(xenstore, 0, xendev->be, &len);
+        if (bepath == NULL) {
+            xen_be_del_xendev(dom, dev);
+        } else {
+            free(bepath);
+            xen_be_backend_changed(xendev, path);
+        }
+    }
+}
+
 static void xenstore_update_be(char *watch, char *type, int dom,
                                struct XenDevOps *ops)
 {
@@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
     if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
         xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
     }
+    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%" PRIxPTR,
+               &type, &dom, &ops) == 3) {
+        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
+    }
 
 cleanup:
     free(vec);
@@ -732,11 +811,74 @@ err:
     return -1;
 }
 
+int xen_vtpm_register(struct XenDevOps *ops)
+{
+    struct XenDevice *xendev;
+    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
+    char *domu;
+    unsigned int cdev, j, rc;
+    const char *type = "vtpm";
+    char **dev = NULL;
+
+    /*front domu*/
+    domu = xs_get_domain_path(xenstore, xen_domid);
+    snprintf(path, sizeof(path), "%s/device/%s",
+             domu, type);
+    free(domu);
+    dev = xs_directory(xenstore, 0, path, &cdev);
+    if (dev == NULL) {
+        return 0;
+    }
+
+    for (j = 0; j < cdev; j++) {
+        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]), ops);
+        if (xendev == NULL) {
+            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is NULL.\n");
+            continue;
+        }
+
+        if (xendev->ops->initialise) {
+            rc = xendev->ops->initialise(xendev);
+
+            /*if initialise failed, delete it*/
+            if (rc != 0) {
+                xen_be_del_xendev(xen_domid, atoi(dev[j]));
+                continue;
+            }
+        }
+
+        /*setup watch*/
+        snprintf(token, sizeof(token), "stub:%p:%d:%p",
+                 type, xen_domid, xendev->ops);
+        if (!xs_watch(xenstore, xendev->be, token)) {
+            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch failed.\n");
+            return -1;
+        }
+    }
+
+    free(dev);
+    return 0;
+}
+
 int xen_be_register(const char *type, struct XenDevOps *ops)
 {
     return xenstore_scan(type, xen_domid, ops);
 }
 
+int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom)
+{
+    xendev->local_port = xc_evtchn_bind_unbound_port(xendev->evtchndev,
+                                                     remote_dom);
+    if (xendev->local_port == -1) {
+        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
+        return -1;
+    }
+    xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
+    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
+                        xen_be_evtchn_event, NULL, xendev);
+    return 0;
+}
+
 int xen_be_bind_evtchn(struct XenDevice *xendev)
 {
     if (xendev->local_port != -1) {
@@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice *xendev)
     return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
 }
 
+int xen_vtpm_send(unsigned char *buf, size_t count)
+{
+    struct XenDevice *xendev;
+    int rc = -1;
+
+    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
+    if (xendev == NULL) {
+        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
+        return -1;
+    }
+
+    if (xendev->ops->send) {
+        rc = xendev->ops->send(xendev, buf, count);
+    }
+
+    return rc;
+}
+
+int xen_vtpm_recv(unsigned char *buf, size_t *count)
+{
+    struct XenDevice *xendev;
+    int rc = -1;
+
+    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
+    if (xendev == NULL) {
+        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
+        return -1;
+    }
+
+    if (xendev->ops->recv) {
+        xendev->ops->recv(xendev, buf, count);
+    }
+
+    return rc;
+}
+
 /*
  * msg_level:
  *  0 == errors (stderr + logfile).
diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
new file mode 100644
index 0000000..0d740c1
--- /dev/null
+++ b/hw/xen/xen_stubdom_vtpm.c
@@ -0,0 +1,333 @@
+/*
+ * Connect to Xen vTPM stubdom domain
+ *
+ *  Copyright (c) 2014 Intel Corporation
+ *  Authors:
+ *    Quan Xu <quan.xu@intel.com>
+ *
+ * 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 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, see <http://www.gnu.org/licenses/>
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdarg.h>
+#include <string.h>
+#include <unistd.h>
+#include <signal.h>
+#include <inttypes.h>
+#include <time.h>
+#include <fcntl.h>
+#include <errno.h>
+#include <sys/ioctl.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <sys/uio.h>
+
+#include "hw/hw.h"
+#include "block/aio.h"
+#include "hw/xen/xen_backend.h"
+
+enum tpmif_state {
+    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel complete */
+    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
+    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
+    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
+};
+
+static AioContext *vtpm_aio_ctx;
+
+enum status_bits {
+    VTPM_STATUS_RUNNING  = 0x1,
+    VTPM_STATUS_IDLE     = 0x2,
+    VTPM_STATUS_RESULT   = 0x4,
+    VTPM_STATUS_CANCELED = 0x8,
+};
+
+struct tpmif_shared_page {
+    uint32_t length;         /* request/response length in bytes */
+
+    uint8_t  state;           /* enum tpmif_state */
+    uint8_t  locality;        /* for the current request */
+    uint8_t  pad;             /* should be zero */
+
+    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be zero */
+    uint32_t extra_pages[0]; /* grant IDs; length is actually nr_extra_pages */
+};
+
+struct QEMUBH {
+    AioContext *ctx;
+    QEMUBHFunc *cb;
+    void *opaque;
+    QEMUBH *next;
+    bool scheduled;
+    bool idle;
+    bool deleted;
+};
+
+struct XenVtpmDev {
+    struct XenDevice xendev;  /* must be first */
+    struct           tpmif_shared_page *shr;
+    xc_gntshr        *xen_xcs;
+    int              ring_ref;
+    int              bedomid;
+    QEMUBH           *sr_bh;
+};
+
+static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
+{
+    switch (vtpmdev->shr->state) {
+    case TPMIF_STATE_IDLE:
+    case TPMIF_STATE_FINISH:
+        return VTPM_STATUS_IDLE;
+    case TPMIF_STATE_SUBMIT:
+    case TPMIF_STATE_CANCEL:
+        return VTPM_STATUS_RUNNING;
+    default:
+        return 0;
+    }
+}
+
+static int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)
+{
+    xs_transaction_t xbt = XBT_NULL;
+
+    if (xendev->fe_state == xbus) {
+        return 0;
+    }
+
+    xendev->fe_state = xbus;
+
+retry_transaction:
+    xbt = xs_transaction_start(xenstore);
+    if (xbt == XBT_NULL) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(xendev->fe, "state", xbus)) {
+        goto abort_transaction;
+    }
+
+    if (!xs_transaction_end(xenstore, xbt, 0)) {
+        if (errno == EAGAIN) {
+            goto retry_transaction;
+        }
+    }
+
+    return 0;
+
+abort_transaction:
+    xs_transaction_end(xenstore, xbt, 1);
+    return -1;
+}
+
+static int vtpm_aio_wait(QEMUBH *qbh)
+{
+    return aio_poll(qbh->ctx, true);
+}
+
+static void sr_bh_handler(void *opaque)
+{
+}
+
+static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    struct tpmif_shared_page *shr = vtpmdev->shr;
+    unsigned int offset;
+
+    if (shr->state == TPMIF_STATE_IDLE) {
+        return -ECANCELED;
+    }
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpmdev->sr_bh);
+    }
+
+    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
+    memcpy(buf, offset + (uint8_t *)shr, shr->length);
+    *count = shr->length;
+
+    return 0;
+}
+
+static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    struct tpmif_shared_page *shr = vtpmdev->shr;
+    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpmdev->sr_bh);
+    }
+
+    memcpy(offset + (uint8_t *)shr, buf, count);
+    shr->length = count;
+    barrier();
+    shr->state = TPMIF_STATE_SUBMIT;
+    xen_wmb();
+    xen_be_send_notify(&vtpmdev->xendev);
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpmdev->sr_bh);
+    }
+
+    return count;
+}
+
+static int vtpm_initialise(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    xs_transaction_t xbt = XBT_NULL;
+    unsigned int ring_ref;
+
+    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev, "frontend");
+    if (vtpmdev->xendev.fe == NULL) {
+        return -1;
+    }
+
+    /* Get backend domid */
+    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
+                             &vtpmdev->bedomid)) {
+        return -1;
+    }
+
+    /*alloc share page*/
+    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs, vtpmdev->bedomid, 1,
+                                         &ring_ref, PROT_READ|PROT_WRITE);
+    vtpmdev->ring_ref = ring_ref;
+    if (vtpmdev->shr == NULL) {
+        return -1;
+    }
+
+    /*Create event channel */
+    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0, vtpmdev->bedomid)) {
+        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+        return -1;
+    }
+
+    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
+                     vtpmdev->xendev.local_port);
+
+again:
+    xbt = xs_transaction_start(xenstore);
+    if (xbt == XBT_NULL) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
+                           vtpmdev->ring_ref)) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
+                           vtpmdev->xendev.local_port)) {
+        goto abort_transaction;
+    }
+
+    /* Publish protocol v2 feature */
+    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1)) {
+        goto abort_transaction;
+    }
+
+    if (!xs_transaction_end(xenstore, xbt, 0)) {
+        if (errno == EAGAIN) {
+            goto again;
+        }
+    }
+    /* Tell vtpm backend that we are ready */
+    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
+
+    return 0;
+
+abort_transaction:
+    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+    xs_transaction_end(xenstore, xbt, 1);
+    return -1;
+}
+
+static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    int be_state;
+
+    if (strcmp(node, "state") == 0) {
+        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
+        switch (be_state) {
+        case XenbusStateConnected:
+            /*TODO*/
+            break;
+        case XenbusStateClosing:
+        case XenbusStateClosed:
+            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
+            break;
+        default:
+            break;
+        }
+    }
+}
+
+static int vtpm_free(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    QEMUBH *qbh = vtpmdev->sr_bh;
+
+    aio_poll(qbh->ctx, false);
+    qemu_bh_delete(vtpmdev->sr_bh);
+    if (vtpmdev->shr) {
+        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+    }
+    xc_interface_close(vtpmdev->xen_xcs);
+    return 0;
+}
+
+static void vtpm_alloc(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+
+    vtpm_aio_ctx = aio_context_new(NULL);
+    if (vtpm_aio_ctx == NULL) {
+        return;
+    }
+    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler, vtpmdev);
+    qemu_bh_schedule(vtpmdev->sr_bh);
+    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
+}
+
+static void vtpm_event(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+
+    qemu_bh_schedule(vtpmdev->sr_bh);
+}
+
+struct XenDevOps xen_vtpmdev_ops = {
+    .size             = sizeof(struct XenVtpmDev),
+    .flags            = DEVOPS_FLAG_IGNORE_STATE |
+                        DEVOPS_FLAG_STUBDOM_BE,
+    .event            = vtpm_event,
+    .free             = vtpm_free,
+    .alloc            = vtpm_alloc,
+    .initialise       = vtpm_initialise,
+    .backend_changed  = vtpm_backend_changed,
+    .recv             = vtpm_recv,
+    .send             = vtpm_send,
+};
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 3b4125e..45fd6d3 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -15,6 +15,8 @@ struct XenDevice;
 #define DEVOPS_FLAG_NEED_GNTDEV   1
 /* don't expect frontend doing correct state transitions (aka console quirk) */
 #define DEVOPS_FLAG_IGNORE_STATE  2
+/*dev backend is stubdom*/
+#define DEVOPS_FLAG_STUBDOM_BE    4
 
 struct XenDevOps {
     size_t    size;
@@ -26,6 +28,8 @@ struct XenDevOps {
     void      (*event)(struct XenDevice *xendev);
     void      (*disconnect)(struct XenDevice *xendev);
     int       (*free)(struct XenDevice *xendev);
+    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t count);
+    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t *count);
     void      (*backend_changed)(struct XenDevice *xendev, const char *node);
     void      (*frontend_changed)(struct XenDevice *xendev, const char *node);
 };
@@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice *xendev);
 void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...)
     GCC_FMT_ATTR(3, 4);
 
+/*Xen stubdom vtpm*/
+int xen_vtpm_register(struct XenDevOps *ops);
+int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
+int xen_vtpm_send(unsigned char *buf, size_t count);
+int xen_vtpm_recv(unsigned char *buf, size_t *count);
+
 /* actual backend drivers */
 extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
 extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c */
 extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
 extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c        */
 extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c         */
+extern struct XenDevOps xen_vtpmdev_ops;      /* xen_stubdom_vtpm.c*/
 
 void xen_init_display(int domid);
 
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 95612a4..fb43084 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
     return xc_interface_open(logger, dombuild_logger, open_flags);
 }
 
+static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
+                                           unsigned int open_flags)
+{
+    return xc_gntshr_open(logger, open_flags);
+}
+
 /* FIXME There is now way to have the xen fd */
 static inline int xc_fd(xc_interface *xen_xc)
 {
diff --git a/xen-hvm.c b/xen-hvm.c
index 21f1cbb..c99ace8 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
     int i, rc;
     unsigned long ioreq_pfn;
     unsigned long bufioreq_evtchn;
+
+#ifdef CONFIG_TPM_XENSTUBDOMS
+    unsigned long stubdom_vtpm = 0;
+#endif
+
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
         fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
         return -1;
     }
+
+#ifdef CONFIG_TPM_XENSTUBDOMS
+    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
+    if (stubdom_vtpm) {
+        xen_vtpm_register(&xen_vtpmdev_ops);
+    }
+#endif
+
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
-- 
1.8.3.2


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 10:43:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkscY-0001tx-GI; Sun, 02 Nov 2014 10:42:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XkscW-0001tn-KA
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 10:42:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	15/F4-24532-CAA06545; Sun, 02 Nov 2014 10:42:52 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1414924970!4155303!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25111 invoked from network); 2 Nov 2014 10:42:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	2 Nov 2014 10:42:50 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 02 Nov 2014 02:42:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,295,1413270000"; d="scan'208";a="600565166"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 02 Nov 2014 02:42:48 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 01:39:21 -0500
Message-Id: <1414910361-27681-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: lcapitulino@redhat.com, armbru@redhat.com, Quan Xu <quan.xu@intel.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] Qemu-Xen-vTPM: Support for Xen stubdom vTPM
	command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 configure        | 14 ++++++++++++++
 hmp.c            |  7 +++++++
 qapi-schema.json | 17 +++++++++++++++--
 qemu-options.hx  | 13 +++++++++++--
 tpm.c            |  7 ++++++-
 5 files changed, 53 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index a9e4d49..d63b8a1 100755
--- a/configure
+++ b/configure
@@ -2942,6 +2942,16 @@ else
 fi
 
 ##########################################
+# TPM xenstubdoms is only on x86 Linux
+
+if test "$targetos" = Linux && test "$cpu" = i386 -o "$cpu" = x86_64 && \
+   test "$xen" = "yes"; then
+  tpm_xenstubdoms=$tpm
+else
+  tpm_xenstubdoms=no
+fi
+
+##########################################
 # attr probe
 
 if test "$attr" != "no" ; then
@@ -4333,6 +4343,7 @@ echo "gcov              $gcov_tool"
 echo "gcov enabled      $gcov"
 echo "TPM support       $tpm"
 echo "libssh2 support   $libssh2"
+echo "TPM xenstubdoms   $tpm_xenstubdoms"
 echo "TPM passthrough   $tpm_passthrough"
 echo "QOM debugging     $qom_cast_debug"
 echo "vhdx              $vhdx"
@@ -4810,6 +4821,9 @@ if test "$tpm" = "yes"; then
   if test "$tpm_passthrough" = "yes"; then
     echo "CONFIG_TPM_PASSTHROUGH=y" >> $config_host_mak
   fi
+  if test "$tpm_xenstubdoms" = "yes"; then
+    echo "CONFIG_TPM_XENSTUBDOMS=y" >> $config_host_mak
+  fi
 fi
 
 echo "TRACE_BACKENDS=$trace_backends" >> $config_host_mak
diff --git a/hmp.c b/hmp.c
index 63d7686..5d2bcf9 100644
--- a/hmp.c
+++ b/hmp.c
@@ -689,6 +689,7 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
     Error *err = NULL;
     unsigned int c = 0;
     TPMPassthroughOptions *tpo;
+    TPMXenstubdomsOptions *txo;
 
     info_list = qmp_query_tpm(&err);
     if (err) {
@@ -718,6 +719,12 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
                            tpo->has_cancel_path ? ",cancel-path=" : "",
                            tpo->has_cancel_path ? tpo->cancel_path : "");
             break;
+       case TPM_TYPE_OPTIONS_KIND_XENSTUBDOMS:
+            txo = ti->options->xenstubdoms;
+            if (!txo) {
+                monitor_printf(mon, "null TPMXenstubdomsOptions error!\n");
+            }
+            break;
         case TPM_TYPE_OPTIONS_KIND_MAX:
             break;
         }
diff --git a/qapi-schema.json b/qapi-schema.json
index 24379ab..23ecb4b 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2853,10 +2853,11 @@
 # An enumeration of TPM types
 #
 # @passthrough: TPM passthrough type
+# @xenstubdoms: TPM xenstubdoms type
 #
 # Since: 1.5
 ##
-{ 'enum': 'TpmType', 'data': [ 'passthrough' ] }
+{ 'enum': 'TpmType', 'data': [ 'passthrough', 'xenstubdoms' ] }
 
 ##
 # @query-tpm-types:
@@ -2884,6 +2885,16 @@
 { 'type': 'TPMPassthroughOptions', 'data': { '*path' : 'str',
                                              '*cancel-path' : 'str'} }
 
+# @TPMXenstubdomsOptions:
+#
+# Information about the TPM xenstubdoms type
+#
+# Since: > 2.1.0
+##
+{ 'type': 'TPMXenstubdomsOptions', 'data': {  } }
+#
+##
+
 ##
 # @TpmTypeOptions:
 #
@@ -2894,7 +2905,9 @@
 # Since: 1.5
 ##
 { 'union': 'TpmTypeOptions',
-   'data': { 'passthrough' : 'TPMPassthroughOptions' } }
+  'data': { 'passthrough' : 'TPMPassthroughOptions',
+            'xenstubdoms' : 'TPMXenstubdomsOptions' } }
+##
 
 ##
 # @TpmInfo:
diff --git a/qemu-options.hx b/qemu-options.hx
index 1e7d5b8..fd73f57 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2485,7 +2485,8 @@ DEF("tpmdev", HAS_ARG, QEMU_OPTION_tpmdev, \
     "-tpmdev passthrough,id=id[,path=path][,cancel-path=path]\n"
     "                use path to provide path to a character device; default is /dev/tpm0\n"
     "                use cancel-path to provide path to TPM's cancel sysfs entry; if\n"
-    "                not provided it will be searched for in /sys/class/misc/tpm?/device\n",
+    "                not provided it will be searched for in /sys/class/misc/tpm?/device\n"
+    "-tpmdev xenstubdoms,id=id\n",
     QEMU_ARCH_ALL)
 STEXI
 
@@ -2495,7 +2496,8 @@ The general form of a TPM device option is:
 @item -tpmdev @var{backend} ,id=@var{id} [,@var{options}]
 @findex -tpmdev
 Backend type must be:
-@option{passthrough}.
+@option{passthrough}, or
+@option{xenstubdoms}.
 
 The specific backend type will determine the applicable options.
 The @code{-tpmdev} option creates the TPM backend and requires a
@@ -2545,6 +2547,13 @@ To create a passthrough TPM use the following two options:
 Note that the @code{-tpmdev} id is @code{tpm0} and is referenced by
 @code{tpmdev=tpm0} in the device option.
 
+To create a xenstubdoms TPM use the following two options:
+@example
+-tpmdev xenstubdoms,id=tpm0 -device tpm-tis,tpmdev=tpm0
+@end example
+Note that the @code{-tpmdev} id is @code{tpm0} and is referenced by
+@code{tpmdev=tpm0} in the device option.
+
 @end table
 
 ETEXI
diff --git a/tpm.c b/tpm.c
index c371023..ee9acb8 100644
--- a/tpm.c
+++ b/tpm.c
@@ -25,7 +25,7 @@ static QLIST_HEAD(, TPMBackend) tpm_backends =
 
 
 #define TPM_MAX_MODELS      1
-#define TPM_MAX_DRIVERS     1
+#define TPM_MAX_DRIVERS     2
 
 static TPMDriverOps const *be_drivers[TPM_MAX_DRIVERS] = {
     NULL,
@@ -256,6 +256,7 @@ static TPMInfo *qmp_query_tpm_inst(TPMBackend *drv)
 {
     TPMInfo *res = g_new0(TPMInfo, 1);
     TPMPassthroughOptions *tpo;
+    TPMXenstubdomsOptions *txo;
 
     res->id = g_strdup(drv->id);
     res->model = drv->fe_model;
@@ -275,6 +276,10 @@ static TPMInfo *qmp_query_tpm_inst(TPMBackend *drv)
             tpo->has_cancel_path = true;
         }
         break;
+    case TPM_TYPE_XENSTUBDOMS:
+        res->options->kind = TPM_TYPE_OPTIONS_KIND_XENSTUBDOMS;
+        txo = g_new0(TPMXenstubdomsOptions, 1);
+        res->options->xenstubdoms = txo;
     case TPM_TYPE_MAX:
         break;
     }
-- 
1.8.3.2


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 10:43:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkscb-0001uO-Se; Sun, 02 Nov 2014 10:42:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xkscb-0001uE-1r
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 10:42:57 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	52/08-24124-0BA06545; Sun, 02 Nov 2014 10:42:56 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1414924973!8945122!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25140 invoked from network); 2 Nov 2014 10:42:54 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-206.messagelabs.com with SMTP;
	2 Nov 2014 10:42:54 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 02 Nov 2014 02:41:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,295,1413270000"; d="scan'208";a="629795495"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 02 Nov 2014 02:42:51 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 01:39:25 -0500
Message-Id: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: stefano.stabellini@eu.citrix.com, Quan Xu <quan.xu@intel.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
	frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This drvier transfers any request/repond between TPM xenstubdoms
driver and Xen vTPM stubdom, and facilitates communications between
Xen vTPM stubdom domain and vTPM xenstubdoms driver

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/xen/Makefile.objs         |   1 +
 hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
 hw/xen/xen_stubdom_vtpm.c    | 333 +++++++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  11 ++
 include/hw/xen/xen_common.h  |   6 +
 xen-hvm.c                    |  13 ++
 6 files changed, 544 insertions(+), 2 deletions(-)
 create mode 100644 hw/xen/xen_stubdom_vtpm.c

diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index a0ca0aa..724df8d 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,6 @@
 # xen backend driver support
 common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
 
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..45a5778 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state)
     return 0;
 }
 
+/*get stubdom backend*/
+static char *xen_stubdom_be(const char *type, int dom, int dev)
+{
+    char *val, *domu;
+    char path[XEN_BUFSIZE];
+    unsigned int len, ival;
+
+    /*front domu*/
+    domu = xs_get_domain_path(xenstore, dom);
+    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
+             domu, type, dev);
+    g_free(domu);
+
+    val = xs_read(xenstore, 0, path, &len);
+    if (!val || 1 != sscanf(val, "%d", &ival)) {
+        g_free(val);
+        return NULL;
+    }
+    g_free(val);
+
+    /*backend domu*/
+    domu = xs_get_domain_path(xenstore, ival);
+
+    return domu;
+}
+
 /* ------------------------------------------------------------- */
 
 struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
@@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
                                            struct XenDevOps *ops)
 {
     struct XenDevice *xendev;
+    char *stub;
 
     xendev = xen_be_find_xendev(type, dom, dev);
     if (xendev) {
@@ -235,8 +262,15 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
     xendev->dev   = dev;
     xendev->ops   = ops;
 
-    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
-             xendev->type, xendev->dom, xendev->dev);
+    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
+        stub = xen_stubdom_be(xendev->type, xendev->dom, xendev->dev);
+        snprintf(xendev->be, sizeof(xendev->be), "%s/backend/%s/%d/%d",
+                 stub, xendev->type, xendev->dom, xendev->dev);
+        g_free(stub);
+    } else {
+        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
+                 xendev->type, xendev->dom, xendev->dev);
+    }
     snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
              xendev->type, xendev->dev);
 
@@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int dom, struct XenDevOps *ops)
     return 0;
 }
 
+static void stubdom_update_be(char *watch, char *type, int dom,
+                              struct XenDevOps *ops)
+{
+    struct XenDevice *xendev;
+    char path[XEN_BUFSIZE];
+    char *ptr, *bepath;
+    unsigned int len, dev;
+
+    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
+        return;
+    }
+
+    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
+    ptr = strstr(watch, path);
+    if (ptr == NULL) {
+        return;
+    }
+
+    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
+        strcpy(path, "");
+        if (sscanf(ptr+len, "/%u", &dev) != 1) {
+            dev = -1;
+        }
+    }
+
+    if (dev == -1) {
+        return;
+    }
+
+    xendev = xen_be_get_xendev(type, dom, dev, ops);
+    if (xendev != NULL) {
+        bepath = xs_read(xenstore, 0, xendev->be, &len);
+        if (bepath == NULL) {
+            xen_be_del_xendev(dom, dev);
+        } else {
+            free(bepath);
+            xen_be_backend_changed(xendev, path);
+        }
+    }
+}
+
 static void xenstore_update_be(char *watch, char *type, int dom,
                                struct XenDevOps *ops)
 {
@@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
     if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
         xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
     }
+    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%" PRIxPTR,
+               &type, &dom, &ops) == 3) {
+        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
+    }
 
 cleanup:
     free(vec);
@@ -732,11 +811,74 @@ err:
     return -1;
 }
 
+int xen_vtpm_register(struct XenDevOps *ops)
+{
+    struct XenDevice *xendev;
+    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
+    char *domu;
+    unsigned int cdev, j, rc;
+    const char *type = "vtpm";
+    char **dev = NULL;
+
+    /*front domu*/
+    domu = xs_get_domain_path(xenstore, xen_domid);
+    snprintf(path, sizeof(path), "%s/device/%s",
+             domu, type);
+    free(domu);
+    dev = xs_directory(xenstore, 0, path, &cdev);
+    if (dev == NULL) {
+        return 0;
+    }
+
+    for (j = 0; j < cdev; j++) {
+        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]), ops);
+        if (xendev == NULL) {
+            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is NULL.\n");
+            continue;
+        }
+
+        if (xendev->ops->initialise) {
+            rc = xendev->ops->initialise(xendev);
+
+            /*if initialise failed, delete it*/
+            if (rc != 0) {
+                xen_be_del_xendev(xen_domid, atoi(dev[j]));
+                continue;
+            }
+        }
+
+        /*setup watch*/
+        snprintf(token, sizeof(token), "stub:%p:%d:%p",
+                 type, xen_domid, xendev->ops);
+        if (!xs_watch(xenstore, xendev->be, token)) {
+            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch failed.\n");
+            return -1;
+        }
+    }
+
+    free(dev);
+    return 0;
+}
+
 int xen_be_register(const char *type, struct XenDevOps *ops)
 {
     return xenstore_scan(type, xen_domid, ops);
 }
 
+int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom)
+{
+    xendev->local_port = xc_evtchn_bind_unbound_port(xendev->evtchndev,
+                                                     remote_dom);
+    if (xendev->local_port == -1) {
+        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
+        return -1;
+    }
+    xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
+    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
+                        xen_be_evtchn_event, NULL, xendev);
+    return 0;
+}
+
 int xen_be_bind_evtchn(struct XenDevice *xendev)
 {
     if (xendev->local_port != -1) {
@@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice *xendev)
     return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
 }
 
+int xen_vtpm_send(unsigned char *buf, size_t count)
+{
+    struct XenDevice *xendev;
+    int rc = -1;
+
+    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
+    if (xendev == NULL) {
+        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
+        return -1;
+    }
+
+    if (xendev->ops->send) {
+        rc = xendev->ops->send(xendev, buf, count);
+    }
+
+    return rc;
+}
+
+int xen_vtpm_recv(unsigned char *buf, size_t *count)
+{
+    struct XenDevice *xendev;
+    int rc = -1;
+
+    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
+    if (xendev == NULL) {
+        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
+        return -1;
+    }
+
+    if (xendev->ops->recv) {
+        xendev->ops->recv(xendev, buf, count);
+    }
+
+    return rc;
+}
+
 /*
  * msg_level:
  *  0 == errors (stderr + logfile).
diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
new file mode 100644
index 0000000..0d740c1
--- /dev/null
+++ b/hw/xen/xen_stubdom_vtpm.c
@@ -0,0 +1,333 @@
+/*
+ * Connect to Xen vTPM stubdom domain
+ *
+ *  Copyright (c) 2014 Intel Corporation
+ *  Authors:
+ *    Quan Xu <quan.xu@intel.com>
+ *
+ * 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 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, see <http://www.gnu.org/licenses/>
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdarg.h>
+#include <string.h>
+#include <unistd.h>
+#include <signal.h>
+#include <inttypes.h>
+#include <time.h>
+#include <fcntl.h>
+#include <errno.h>
+#include <sys/ioctl.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <sys/uio.h>
+
+#include "hw/hw.h"
+#include "block/aio.h"
+#include "hw/xen/xen_backend.h"
+
+enum tpmif_state {
+    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel complete */
+    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
+    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
+    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
+};
+
+static AioContext *vtpm_aio_ctx;
+
+enum status_bits {
+    VTPM_STATUS_RUNNING  = 0x1,
+    VTPM_STATUS_IDLE     = 0x2,
+    VTPM_STATUS_RESULT   = 0x4,
+    VTPM_STATUS_CANCELED = 0x8,
+};
+
+struct tpmif_shared_page {
+    uint32_t length;         /* request/response length in bytes */
+
+    uint8_t  state;           /* enum tpmif_state */
+    uint8_t  locality;        /* for the current request */
+    uint8_t  pad;             /* should be zero */
+
+    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be zero */
+    uint32_t extra_pages[0]; /* grant IDs; length is actually nr_extra_pages */
+};
+
+struct QEMUBH {
+    AioContext *ctx;
+    QEMUBHFunc *cb;
+    void *opaque;
+    QEMUBH *next;
+    bool scheduled;
+    bool idle;
+    bool deleted;
+};
+
+struct XenVtpmDev {
+    struct XenDevice xendev;  /* must be first */
+    struct           tpmif_shared_page *shr;
+    xc_gntshr        *xen_xcs;
+    int              ring_ref;
+    int              bedomid;
+    QEMUBH           *sr_bh;
+};
+
+static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
+{
+    switch (vtpmdev->shr->state) {
+    case TPMIF_STATE_IDLE:
+    case TPMIF_STATE_FINISH:
+        return VTPM_STATUS_IDLE;
+    case TPMIF_STATE_SUBMIT:
+    case TPMIF_STATE_CANCEL:
+        return VTPM_STATUS_RUNNING;
+    default:
+        return 0;
+    }
+}
+
+static int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)
+{
+    xs_transaction_t xbt = XBT_NULL;
+
+    if (xendev->fe_state == xbus) {
+        return 0;
+    }
+
+    xendev->fe_state = xbus;
+
+retry_transaction:
+    xbt = xs_transaction_start(xenstore);
+    if (xbt == XBT_NULL) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(xendev->fe, "state", xbus)) {
+        goto abort_transaction;
+    }
+
+    if (!xs_transaction_end(xenstore, xbt, 0)) {
+        if (errno == EAGAIN) {
+            goto retry_transaction;
+        }
+    }
+
+    return 0;
+
+abort_transaction:
+    xs_transaction_end(xenstore, xbt, 1);
+    return -1;
+}
+
+static int vtpm_aio_wait(QEMUBH *qbh)
+{
+    return aio_poll(qbh->ctx, true);
+}
+
+static void sr_bh_handler(void *opaque)
+{
+}
+
+static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    struct tpmif_shared_page *shr = vtpmdev->shr;
+    unsigned int offset;
+
+    if (shr->state == TPMIF_STATE_IDLE) {
+        return -ECANCELED;
+    }
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpmdev->sr_bh);
+    }
+
+    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
+    memcpy(buf, offset + (uint8_t *)shr, shr->length);
+    *count = shr->length;
+
+    return 0;
+}
+
+static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    struct tpmif_shared_page *shr = vtpmdev->shr;
+    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpmdev->sr_bh);
+    }
+
+    memcpy(offset + (uint8_t *)shr, buf, count);
+    shr->length = count;
+    barrier();
+    shr->state = TPMIF_STATE_SUBMIT;
+    xen_wmb();
+    xen_be_send_notify(&vtpmdev->xendev);
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpmdev->sr_bh);
+    }
+
+    return count;
+}
+
+static int vtpm_initialise(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    xs_transaction_t xbt = XBT_NULL;
+    unsigned int ring_ref;
+
+    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev, "frontend");
+    if (vtpmdev->xendev.fe == NULL) {
+        return -1;
+    }
+
+    /* Get backend domid */
+    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
+                             &vtpmdev->bedomid)) {
+        return -1;
+    }
+
+    /*alloc share page*/
+    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs, vtpmdev->bedomid, 1,
+                                         &ring_ref, PROT_READ|PROT_WRITE);
+    vtpmdev->ring_ref = ring_ref;
+    if (vtpmdev->shr == NULL) {
+        return -1;
+    }
+
+    /*Create event channel */
+    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0, vtpmdev->bedomid)) {
+        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+        return -1;
+    }
+
+    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
+                     vtpmdev->xendev.local_port);
+
+again:
+    xbt = xs_transaction_start(xenstore);
+    if (xbt == XBT_NULL) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
+                           vtpmdev->ring_ref)) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
+                           vtpmdev->xendev.local_port)) {
+        goto abort_transaction;
+    }
+
+    /* Publish protocol v2 feature */
+    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1)) {
+        goto abort_transaction;
+    }
+
+    if (!xs_transaction_end(xenstore, xbt, 0)) {
+        if (errno == EAGAIN) {
+            goto again;
+        }
+    }
+    /* Tell vtpm backend that we are ready */
+    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
+
+    return 0;
+
+abort_transaction:
+    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+    xs_transaction_end(xenstore, xbt, 1);
+    return -1;
+}
+
+static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    int be_state;
+
+    if (strcmp(node, "state") == 0) {
+        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
+        switch (be_state) {
+        case XenbusStateConnected:
+            /*TODO*/
+            break;
+        case XenbusStateClosing:
+        case XenbusStateClosed:
+            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
+            break;
+        default:
+            break;
+        }
+    }
+}
+
+static int vtpm_free(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    QEMUBH *qbh = vtpmdev->sr_bh;
+
+    aio_poll(qbh->ctx, false);
+    qemu_bh_delete(vtpmdev->sr_bh);
+    if (vtpmdev->shr) {
+        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+    }
+    xc_interface_close(vtpmdev->xen_xcs);
+    return 0;
+}
+
+static void vtpm_alloc(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+
+    vtpm_aio_ctx = aio_context_new(NULL);
+    if (vtpm_aio_ctx == NULL) {
+        return;
+    }
+    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler, vtpmdev);
+    qemu_bh_schedule(vtpmdev->sr_bh);
+    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
+}
+
+static void vtpm_event(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+
+    qemu_bh_schedule(vtpmdev->sr_bh);
+}
+
+struct XenDevOps xen_vtpmdev_ops = {
+    .size             = sizeof(struct XenVtpmDev),
+    .flags            = DEVOPS_FLAG_IGNORE_STATE |
+                        DEVOPS_FLAG_STUBDOM_BE,
+    .event            = vtpm_event,
+    .free             = vtpm_free,
+    .alloc            = vtpm_alloc,
+    .initialise       = vtpm_initialise,
+    .backend_changed  = vtpm_backend_changed,
+    .recv             = vtpm_recv,
+    .send             = vtpm_send,
+};
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 3b4125e..45fd6d3 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -15,6 +15,8 @@ struct XenDevice;
 #define DEVOPS_FLAG_NEED_GNTDEV   1
 /* don't expect frontend doing correct state transitions (aka console quirk) */
 #define DEVOPS_FLAG_IGNORE_STATE  2
+/*dev backend is stubdom*/
+#define DEVOPS_FLAG_STUBDOM_BE    4
 
 struct XenDevOps {
     size_t    size;
@@ -26,6 +28,8 @@ struct XenDevOps {
     void      (*event)(struct XenDevice *xendev);
     void      (*disconnect)(struct XenDevice *xendev);
     int       (*free)(struct XenDevice *xendev);
+    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t count);
+    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t *count);
     void      (*backend_changed)(struct XenDevice *xendev, const char *node);
     void      (*frontend_changed)(struct XenDevice *xendev, const char *node);
 };
@@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice *xendev);
 void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...)
     GCC_FMT_ATTR(3, 4);
 
+/*Xen stubdom vtpm*/
+int xen_vtpm_register(struct XenDevOps *ops);
+int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
+int xen_vtpm_send(unsigned char *buf, size_t count);
+int xen_vtpm_recv(unsigned char *buf, size_t *count);
+
 /* actual backend drivers */
 extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
 extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c */
 extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
 extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c        */
 extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c         */
+extern struct XenDevOps xen_vtpmdev_ops;      /* xen_stubdom_vtpm.c*/
 
 void xen_init_display(int domid);
 
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 95612a4..fb43084 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
     return xc_interface_open(logger, dombuild_logger, open_flags);
 }
 
+static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
+                                           unsigned int open_flags)
+{
+    return xc_gntshr_open(logger, open_flags);
+}
+
 /* FIXME There is now way to have the xen fd */
 static inline int xc_fd(xc_interface *xen_xc)
 {
diff --git a/xen-hvm.c b/xen-hvm.c
index 21f1cbb..c99ace8 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
     int i, rc;
     unsigned long ioreq_pfn;
     unsigned long bufioreq_evtchn;
+
+#ifdef CONFIG_TPM_XENSTUBDOMS
+    unsigned long stubdom_vtpm = 0;
+#endif
+
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
         fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
         return -1;
     }
+
+#ifdef CONFIG_TPM_XENSTUBDOMS
+    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
+    if (stubdom_vtpm) {
+        xen_vtpm_register(&xen_vtpmdev_ops);
+    }
+#endif
+
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
-- 
1.8.3.2


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 10:43:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkscg-0001wg-K3; Sun, 02 Nov 2014 10:43:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xksce-0001vS-J8
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 10:43:00 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	61/3B-22777-3BA06545; Sun, 02 Nov 2014 10:42:59 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1414924978!13121889!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2806 invoked from network); 2 Nov 2014 10:42:59 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-206.messagelabs.com with SMTP;
	2 Nov 2014 10:42:59 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 02 Nov 2014 02:42:58 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,295,1413270000"; d="scan'208";a="624941338"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 02 Nov 2014 02:42:56 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 01:39:31 -0500
Message-Id: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: pbonzini@redhat.com, Quan Xu <quan.xu@intel.com>, aliguori@amazon.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is
	initialized before tpm_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>
MIME-Version: 1.0
Content-Type: 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 sure QEMU machine class is initialized and QEMU has registered
Xen stubdom vTPM driver when call tpm_init() [vl.c]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 vl.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/vl.c b/vl.c
index f6b3546..dd437e1 100644
--- a/vl.c
+++ b/vl.c
@@ -4114,12 +4114,6 @@ int main(int argc, char **argv, char **envp)
         exit(1);
     }
 
-#ifdef CONFIG_TPM
-    if (tpm_init() < 0) {
-        exit(1);
-    }
-#endif
-
     /* init the bluetooth world */
     if (foreach_device_config(DEV_BT, bt_parse))
         exit(1);
@@ -4225,6 +4219,16 @@ int main(int argc, char **argv, char **envp)
             exit(1);
     }
 
+    /* For compatible with Xen stubdom vTPM driver, make
+     * sure QEMU machine class is initialized and QEMU has
+     * registered Xen stubdom vTPM driver ..
+    */
+#ifdef CONFIG_TPM
+    if (tpm_init() < 0) {
+        exit(1);
+    }
+#endif
+
     /* init generic devices */
     if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func, NULL, 1) != 0)
         exit(1);
-- 
1.8.3.2


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 10:43:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkscg-0001wg-K3; Sun, 02 Nov 2014 10:43:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xksce-0001vS-J8
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 10:43:00 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	61/3B-22777-3BA06545; Sun, 02 Nov 2014 10:42:59 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1414924978!13121889!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2806 invoked from network); 2 Nov 2014 10:42:59 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-206.messagelabs.com with SMTP;
	2 Nov 2014 10:42:59 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 02 Nov 2014 02:42:58 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,295,1413270000"; d="scan'208";a="624941338"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 02 Nov 2014 02:42:56 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 01:39:31 -0500
Message-Id: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: pbonzini@redhat.com, Quan Xu <quan.xu@intel.com>, aliguori@amazon.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is
	initialized before tpm_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>
MIME-Version: 1.0
Content-Type: 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 sure QEMU machine class is initialized and QEMU has registered
Xen stubdom vTPM driver when call tpm_init() [vl.c]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 vl.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/vl.c b/vl.c
index f6b3546..dd437e1 100644
--- a/vl.c
+++ b/vl.c
@@ -4114,12 +4114,6 @@ int main(int argc, char **argv, char **envp)
         exit(1);
     }
 
-#ifdef CONFIG_TPM
-    if (tpm_init() < 0) {
-        exit(1);
-    }
-#endif
-
     /* init the bluetooth world */
     if (foreach_device_config(DEV_BT, bt_parse))
         exit(1);
@@ -4225,6 +4219,16 @@ int main(int argc, char **argv, char **envp)
             exit(1);
     }
 
+    /* For compatible with Xen stubdom vTPM driver, make
+     * sure QEMU machine class is initialized and QEMU has
+     * registered Xen stubdom vTPM driver ..
+    */
+#ifdef CONFIG_TPM
+    if (tpm_init() < 0) {
+        exit(1);
+    }
+#endif
+
     /* init generic devices */
     if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func, NULL, 1) != 0)
         exit(1);
-- 
1.8.3.2


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 10:43:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:43:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkscv-00022p-5P; Sun, 02 Nov 2014 10:43:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xksct-000227-Kv
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 10:43:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	78/2C-09842-3CA06545; Sun, 02 Nov 2014 10:43:15 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1414924991!12166030!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29911 invoked from network); 2 Nov 2014 10:43:12 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-15.tower-21.messagelabs.com with SMTP;
	2 Nov 2014 10:43:12 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 02 Nov 2014 02:36:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,295,1413270000"; d="scan'208";a="615518610"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 02 Nov 2014 02:42:54 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 01:39:28 -0500
Message-Id: <1414910368-27757-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: stefano.stabellini@eu.citrix.com, Quan Xu <quan.xu@intel.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms driver.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This driver provides vTPM initialization and sending data and TPM
commends to a Xen stubdom vTPM domain.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/tpm/Makefile.objs     |   1 +
 hw/tpm/tpm_xenstubdoms.c | 238 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 239 insertions(+)
 create mode 100644 hw/tpm/tpm_xenstubdoms.c

diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 99f5983..39fc0f9 100644
--- a/hw/tpm/Makefile.objs
+++ b/hw/tpm/Makefile.objs
@@ -1,2 +1,3 @@
 common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
 common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o
diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
new file mode 100644
index 0000000..845df18
--- /dev/null
+++ b/hw/tpm/tpm_xenstubdoms.c
@@ -0,0 +1,238 @@
+/*
+ * Xen Stubdom vTPM driver
+ *
+ *  Copyright (c) 2014 Intel Corporation
+ *  Authors:
+ *    Quan Xu <quan.xu@intel.com>
+ *
+ * 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 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, see <http://www.gnu.org/licenses/>
+ */
+
+#include <dirent.h>
+#include "qemu-common.h"
+#include "qapi/error.h"
+#include "qemu/sockets.h"
+#include "qemu/log.h"
+#include "sysemu/tpm_backend.h"
+#include "tpm_int.h"
+#include "hw/hw.h"
+#include "hw/i386/pc.h"
+#include "hw/xen/xen_backend.h"
+#include "sysemu/tpm_backend_int.h"
+#include "tpm_tis.h"
+
+#ifdef DEBUG_TPM
+#define DPRINTF(fmt, ...) \
+    do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+    do { } while (0)
+#endif
+
+#define TYPE_TPM_XENSTUBDOMS "tpm-xenstubdoms"
+#define TPM_XENSTUBDOMS(obj) \
+    OBJECT_CHECK(TPMXenstubdomsState, (obj), TYPE_TPM_XENSTUBDOMS)
+
+static const TPMDriverOps tpm_xenstubdoms_driver;
+
+/* data structures */
+typedef struct TPMXenstubdomsThreadParams {
+    TPMState *tpm_state;
+    TPMRecvDataCB *recv_data_callback;
+    TPMBackend *tb;
+} TPMXenstubdomsThreadParams;
+
+struct TPMXenstubdomsState {
+    TPMBackend parent;
+    TPMBackendThread tbt;
+    TPMXenstubdomsThreadParams tpm_thread_params;
+    bool had_startup_error;
+};
+
+typedef struct TPMXenstubdomsState TPMXenstubdomsState;
+
+/* functions */
+
+static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb);
+
+static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
+{
+    size_t rlen;
+    xen_vtpm_send(locty_data->w_buffer.buffer, locty_data->w_offset);
+    xen_vtpm_recv(locty_data->r_buffer.buffer, &rlen);
+    return 0;
+}
+
+static void tpm_xenstubdoms_worker_thread(gpointer data,
+                                          gpointer user_data)
+{
+    TPMXenstubdomsThreadParams *thr_parms = user_data;
+    TPMBackendCmd cmd = (TPMBackendCmd)data;
+
+    switch (cmd) {
+    case TPM_BACKEND_CMD_PROCESS_CMD:
+        /* here need a the cmd process function */
+        tpm_xenstubdoms_unix_transfer(thr_parms->tpm_state->locty_data);
+        thr_parms->recv_data_callback(thr_parms->tpm_state,
+                                      thr_parms->tpm_state->locty_number);
+        break;
+    case TPM_BACKEND_CMD_INIT:
+    case TPM_BACKEND_CMD_END:
+    case TPM_BACKEND_CMD_TPM_RESET:
+        /* nothing to do */
+        break;
+    }
+}
+
+/*
+ *  * Start the TPM (thread). If it had been started before, then terminate
+ *   * and start it again.
+ *    */
+static int tpm_xenstubdoms_startup_tpm(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_backend_thread_tpm_reset(&tpm_xs->tbt, tpm_xenstubdoms_worker_thread,
+                                 &tpm_xs->tpm_thread_params);
+
+    return 0;
+}
+
+static void tpm_xenstubdoms_reset(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_backend_thread_end(&tpm_xs->tbt);
+    tpm_xs->had_startup_error = false;
+}
+
+static int tpm_xenstubdoms_init(TPMBackend *tb, TPMState *s,
+                                TPMRecvDataCB *recv_data_cb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_xs->tpm_thread_params.tpm_state = s;
+    tpm_xs->tpm_thread_params.recv_data_callback = recv_data_cb;
+    tpm_xs->tpm_thread_params.tb = tb;
+    return 0;
+}
+
+static bool tpm_xenstubdoms_get_tpm_established_flag(TPMBackend *tb)
+{
+    return false;
+}
+
+static bool tpm_xenstubdoms_get_startup_error(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    return tpm_xs->had_startup_error;
+}
+
+static size_t tpm_xenstubdoms_realloc_buffer(TPMSizedBuffer *sb)
+{
+    size_t wanted_size = 4096; /* Linux tpm.c buffer size */
+
+    if (sb->size != wanted_size) {
+        sb->buffer = g_realloc(sb->buffer, wanted_size);
+        sb->size = wanted_size;
+    }
+    return sb->size;
+}
+
+static void tpm_xenstubdoms_deliver_request(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+    tpm_backend_thread_deliver_request(&tpm_xs->tbt);
+}
+
+static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb)
+{
+}
+
+static const char *tpm_xenstubdoms_create_desc(void)
+{
+    return "Xenstubdoms TPM backend driver";
+}
+
+static TPMBackend *tpm_xenstubdoms_create(QemuOpts *opts, const char *id)
+{
+    Object *obj = object_new(TYPE_TPM_XENSTUBDOMS);
+    TPMBackend *tb = TPM_BACKEND(obj);
+
+    tb->id = g_strdup(id);
+    tb->fe_model = -1;
+    tb->ops = &tpm_xenstubdoms_driver;
+    return tb;
+}
+
+static void tpm_xenstubdoms_destroy(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xh = TPM_XENSTUBDOMS(tb);
+    tpm_backend_thread_end(&tpm_xh->tbt);
+
+    g_free(tb->id);
+}
+
+static const QemuOptDesc tpm_xenstubdoms_cmdline_opts[] = {
+    TPM_STANDARD_CMDLINE_OPTS,
+    {},
+};
+
+static const TPMDriverOps tpm_xenstubdoms_driver = {
+    .type                     = TPM_TYPE_XENSTUBDOMS,
+    .opts                     = tpm_xenstubdoms_cmdline_opts,
+    .desc                     = tpm_xenstubdoms_create_desc,
+    .create                   = tpm_xenstubdoms_create,
+    .destroy                  = tpm_xenstubdoms_destroy,
+    .init                     = tpm_xenstubdoms_init,
+    .startup_tpm              = tpm_xenstubdoms_startup_tpm,
+    .realloc_buffer           = tpm_xenstubdoms_realloc_buffer,
+    .reset                    = tpm_xenstubdoms_reset,
+    .had_startup_error        = tpm_xenstubdoms_get_startup_error,
+    .deliver_request          = tpm_xenstubdoms_deliver_request,
+    .cancel_cmd               = tpm_xenstubdoms_cancel_cmd,
+    .get_tpm_established_flag = tpm_xenstubdoms_get_tpm_established_flag,
+};
+
+static void tpm_xenstubdoms_inst_init(Object *obj)
+{
+}
+
+static void tpm_xenstubdoms_inst_finalize(Object *obj)
+{
+}
+
+static void tpm_xenstubdoms_class_init(ObjectClass *klass, void *data)
+{
+    TPMBackendClass *tbc = TPM_BACKEND_CLASS(klass);
+    tbc->ops = &tpm_xenstubdoms_driver;
+}
+
+static const TypeInfo tpm_xenstubdoms_info = {
+    .name = TYPE_TPM_XENSTUBDOMS,
+    .parent = TYPE_TPM_BACKEND,
+    .instance_size = sizeof(TPMXenstubdomsState),
+    .class_init = tpm_xenstubdoms_class_init,
+    .instance_init = tpm_xenstubdoms_inst_init,
+    .instance_finalize = tpm_xenstubdoms_inst_finalize,
+};
+
+static void tpm_xenstubdoms_register(void)
+{
+    type_register_static(&tpm_xenstubdoms_info);
+    tpm_register_driver(&tpm_xenstubdoms_driver);
+}
+
+type_init(tpm_xenstubdoms_register)
-- 
1.8.3.2


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 10:43:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 10:43:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkscv-00022p-5P; Sun, 02 Nov 2014 10:43:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xksct-000227-Kv
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 10:43:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	78/2C-09842-3CA06545; Sun, 02 Nov 2014 10:43:15 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1414924991!12166030!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29911 invoked from network); 2 Nov 2014 10:43:12 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-15.tower-21.messagelabs.com with SMTP;
	2 Nov 2014 10:43:12 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 02 Nov 2014 02:36:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,295,1413270000"; d="scan'208";a="615518610"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 02 Nov 2014 02:42:54 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 01:39:28 -0500
Message-Id: <1414910368-27757-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: stefano.stabellini@eu.citrix.com, Quan Xu <quan.xu@intel.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms driver.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This driver provides vTPM initialization and sending data and TPM
commends to a Xen stubdom vTPM domain.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/tpm/Makefile.objs     |   1 +
 hw/tpm/tpm_xenstubdoms.c | 238 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 239 insertions(+)
 create mode 100644 hw/tpm/tpm_xenstubdoms.c

diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 99f5983..39fc0f9 100644
--- a/hw/tpm/Makefile.objs
+++ b/hw/tpm/Makefile.objs
@@ -1,2 +1,3 @@
 common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
 common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o
diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
new file mode 100644
index 0000000..845df18
--- /dev/null
+++ b/hw/tpm/tpm_xenstubdoms.c
@@ -0,0 +1,238 @@
+/*
+ * Xen Stubdom vTPM driver
+ *
+ *  Copyright (c) 2014 Intel Corporation
+ *  Authors:
+ *    Quan Xu <quan.xu@intel.com>
+ *
+ * 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 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, see <http://www.gnu.org/licenses/>
+ */
+
+#include <dirent.h>
+#include "qemu-common.h"
+#include "qapi/error.h"
+#include "qemu/sockets.h"
+#include "qemu/log.h"
+#include "sysemu/tpm_backend.h"
+#include "tpm_int.h"
+#include "hw/hw.h"
+#include "hw/i386/pc.h"
+#include "hw/xen/xen_backend.h"
+#include "sysemu/tpm_backend_int.h"
+#include "tpm_tis.h"
+
+#ifdef DEBUG_TPM
+#define DPRINTF(fmt, ...) \
+    do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+    do { } while (0)
+#endif
+
+#define TYPE_TPM_XENSTUBDOMS "tpm-xenstubdoms"
+#define TPM_XENSTUBDOMS(obj) \
+    OBJECT_CHECK(TPMXenstubdomsState, (obj), TYPE_TPM_XENSTUBDOMS)
+
+static const TPMDriverOps tpm_xenstubdoms_driver;
+
+/* data structures */
+typedef struct TPMXenstubdomsThreadParams {
+    TPMState *tpm_state;
+    TPMRecvDataCB *recv_data_callback;
+    TPMBackend *tb;
+} TPMXenstubdomsThreadParams;
+
+struct TPMXenstubdomsState {
+    TPMBackend parent;
+    TPMBackendThread tbt;
+    TPMXenstubdomsThreadParams tpm_thread_params;
+    bool had_startup_error;
+};
+
+typedef struct TPMXenstubdomsState TPMXenstubdomsState;
+
+/* functions */
+
+static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb);
+
+static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
+{
+    size_t rlen;
+    xen_vtpm_send(locty_data->w_buffer.buffer, locty_data->w_offset);
+    xen_vtpm_recv(locty_data->r_buffer.buffer, &rlen);
+    return 0;
+}
+
+static void tpm_xenstubdoms_worker_thread(gpointer data,
+                                          gpointer user_data)
+{
+    TPMXenstubdomsThreadParams *thr_parms = user_data;
+    TPMBackendCmd cmd = (TPMBackendCmd)data;
+
+    switch (cmd) {
+    case TPM_BACKEND_CMD_PROCESS_CMD:
+        /* here need a the cmd process function */
+        tpm_xenstubdoms_unix_transfer(thr_parms->tpm_state->locty_data);
+        thr_parms->recv_data_callback(thr_parms->tpm_state,
+                                      thr_parms->tpm_state->locty_number);
+        break;
+    case TPM_BACKEND_CMD_INIT:
+    case TPM_BACKEND_CMD_END:
+    case TPM_BACKEND_CMD_TPM_RESET:
+        /* nothing to do */
+        break;
+    }
+}
+
+/*
+ *  * Start the TPM (thread). If it had been started before, then terminate
+ *   * and start it again.
+ *    */
+static int tpm_xenstubdoms_startup_tpm(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_backend_thread_tpm_reset(&tpm_xs->tbt, tpm_xenstubdoms_worker_thread,
+                                 &tpm_xs->tpm_thread_params);
+
+    return 0;
+}
+
+static void tpm_xenstubdoms_reset(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_backend_thread_end(&tpm_xs->tbt);
+    tpm_xs->had_startup_error = false;
+}
+
+static int tpm_xenstubdoms_init(TPMBackend *tb, TPMState *s,
+                                TPMRecvDataCB *recv_data_cb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_xs->tpm_thread_params.tpm_state = s;
+    tpm_xs->tpm_thread_params.recv_data_callback = recv_data_cb;
+    tpm_xs->tpm_thread_params.tb = tb;
+    return 0;
+}
+
+static bool tpm_xenstubdoms_get_tpm_established_flag(TPMBackend *tb)
+{
+    return false;
+}
+
+static bool tpm_xenstubdoms_get_startup_error(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    return tpm_xs->had_startup_error;
+}
+
+static size_t tpm_xenstubdoms_realloc_buffer(TPMSizedBuffer *sb)
+{
+    size_t wanted_size = 4096; /* Linux tpm.c buffer size */
+
+    if (sb->size != wanted_size) {
+        sb->buffer = g_realloc(sb->buffer, wanted_size);
+        sb->size = wanted_size;
+    }
+    return sb->size;
+}
+
+static void tpm_xenstubdoms_deliver_request(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+    tpm_backend_thread_deliver_request(&tpm_xs->tbt);
+}
+
+static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb)
+{
+}
+
+static const char *tpm_xenstubdoms_create_desc(void)
+{
+    return "Xenstubdoms TPM backend driver";
+}
+
+static TPMBackend *tpm_xenstubdoms_create(QemuOpts *opts, const char *id)
+{
+    Object *obj = object_new(TYPE_TPM_XENSTUBDOMS);
+    TPMBackend *tb = TPM_BACKEND(obj);
+
+    tb->id = g_strdup(id);
+    tb->fe_model = -1;
+    tb->ops = &tpm_xenstubdoms_driver;
+    return tb;
+}
+
+static void tpm_xenstubdoms_destroy(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xh = TPM_XENSTUBDOMS(tb);
+    tpm_backend_thread_end(&tpm_xh->tbt);
+
+    g_free(tb->id);
+}
+
+static const QemuOptDesc tpm_xenstubdoms_cmdline_opts[] = {
+    TPM_STANDARD_CMDLINE_OPTS,
+    {},
+};
+
+static const TPMDriverOps tpm_xenstubdoms_driver = {
+    .type                     = TPM_TYPE_XENSTUBDOMS,
+    .opts                     = tpm_xenstubdoms_cmdline_opts,
+    .desc                     = tpm_xenstubdoms_create_desc,
+    .create                   = tpm_xenstubdoms_create,
+    .destroy                  = tpm_xenstubdoms_destroy,
+    .init                     = tpm_xenstubdoms_init,
+    .startup_tpm              = tpm_xenstubdoms_startup_tpm,
+    .realloc_buffer           = tpm_xenstubdoms_realloc_buffer,
+    .reset                    = tpm_xenstubdoms_reset,
+    .had_startup_error        = tpm_xenstubdoms_get_startup_error,
+    .deliver_request          = tpm_xenstubdoms_deliver_request,
+    .cancel_cmd               = tpm_xenstubdoms_cancel_cmd,
+    .get_tpm_established_flag = tpm_xenstubdoms_get_tpm_established_flag,
+};
+
+static void tpm_xenstubdoms_inst_init(Object *obj)
+{
+}
+
+static void tpm_xenstubdoms_inst_finalize(Object *obj)
+{
+}
+
+static void tpm_xenstubdoms_class_init(ObjectClass *klass, void *data)
+{
+    TPMBackendClass *tbc = TPM_BACKEND_CLASS(klass);
+    tbc->ops = &tpm_xenstubdoms_driver;
+}
+
+static const TypeInfo tpm_xenstubdoms_info = {
+    .name = TYPE_TPM_XENSTUBDOMS,
+    .parent = TYPE_TPM_BACKEND,
+    .instance_size = sizeof(TPMXenstubdomsState),
+    .class_init = tpm_xenstubdoms_class_init,
+    .instance_init = tpm_xenstubdoms_inst_init,
+    .instance_finalize = tpm_xenstubdoms_inst_finalize,
+};
+
+static void tpm_xenstubdoms_register(void)
+{
+    type_register_static(&tpm_xenstubdoms_info);
+    tpm_register_driver(&tpm_xenstubdoms_driver);
+}
+
+type_init(tpm_xenstubdoms_register)
-- 
1.8.3.2


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 11:04:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 11: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 1Xkswh-0002sB-1B; Sun, 02 Nov 2014 11:03:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xkswf-0002s6-PS
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 11:03:41 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	86/D2-03148-D8F06545; Sun, 02 Nov 2014 11:03:41 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1414926219!12001296!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10366 invoked from network); 2 Nov 2014 11:03:40 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-27.messagelabs.com with SMTP;
	2 Nov 2014 11:03:40 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 02 Nov 2014 03:03:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,295,1413270000"; d="scan'208";a="624954187"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by fmsmga002.fm.intel.com with ESMTP; 02 Nov 2014 03:03:36 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Sun, 2 Nov 2014 19:03:35 +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.3.195.1; Sun, 2 Nov 2014 19:03:35 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.44]) with mapi id
	14.03.0195.001; Sun, 2 Nov 2014 19:03:34 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM
	parameter for HVM virtual machine
Thread-Index: AQHP9DbHLV3lrnmClECyXqXbZ9NI5ZxIAKAAgACIFhCAABuCWoAAC/3AgAFHs4CAAzeFIA==
Date: Sun, 2 Nov 2014 11:03:33 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E81E000@SHSMSX101.ccr.corp.intel.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<1414654731-32641-3-git-send-email-quan.xu@intel.com>
	<545225D2.8090203@citrix.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81CCD8@SHSMSX101.ccr.corp.intel.com>
	<54522C3C.4040807@citrix.com>
	<alpine.DEB.2.02.1410301328250.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81CF19@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1410311749320.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1410311749320.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM
 parameter for HVM virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Saturday, November 01, 2014 1:51 AM
> To: Xu, Quan
> Cc: Stefano Stabellini; Andrew Cooper; xen-devel@lists.xen.org;
> ian.jackson@eu.citrix.com; tim@xen.org; keir@xen.org; ian.campbell@citrix.com;
> jbeulich@suse.com
> Subject: RE: [Xen-devel] [PATCH 2/6] vTPM: add
> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> 
> On Thu, 30 Oct 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Thursday, October 30, 2014 9:35 PM
> > > To: Andrew Cooper
> > > Cc: Xu, Quan; xen-devel@lists.xen.org; ian.jackson@eu.citrix.com;
> > > tim@xen.org; keir@xen.org; ian.campbell@citrix.com;
> > > jbeulich@suse.com
> > > Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> > > HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> > >
> > > On Thu, 30 Oct 2014, Andrew Cooper wrote:
> > > > On 30/10/14 12:05, Xu, Quan wrote:
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> > > > >> Sent: Thursday, October 30, 2014 7:50 PM
> > > > >> To: Xu, Quan; xen-devel@lists.xen.org
> > > > >> Cc: keir@xen.org; ian.campbell@citrix.com; tim@xen.org;
> > > > >> ian.jackson@eu.citrix.com; jbeulich@suse.com
> > > > >> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> > > > >> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> > > > >>
> > > > >> On 30/10/14 07:38, Quan Xu wrote:
> > > > >>> Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > > >> What is the purpose of this parameter?  A patch like this is
> > > > >> currently unacceptable, especially as the libxl hunk indicates
> > > > >> that the parameter name does not match whatever information you
> > > > >> are putting
> > > into it.
> > > > >>
> > > > > Thanks for your suggestion.
> > > > > This parameter tell the Qemu whether to register Qemu vTPM
> > > > > frontend in
> > > xen_hvm_init().
> > > > > Qemu will get the parameter value by xc_get_hvm_param(). How can
> > > > > I
> > > change it?
> > > >
> > > > This is surely something which should be a command line parameter
> > > > to qemu, or perhaps for qemu to read out of xenstore.
> > > >
> > > > An HVM param is entirely inappropriate for this purpose, in my opinion.
> > >
> > > I agree that an HVM param for this might not the best way to do it,
> > > but I can see why Quan did it that way as we already have a few key
> > > parameters passed to QEMU that way.
> > >
> > > A QEMU command line option, QMP command or xenstore key would be
> better.
> >
> > If hvm param is not the best way, I think xenstore key would be better.
> >
> > Below is part of Qemu patch, that's why I add HVM_PARAM_STUBDOM_VTPM
> param.
> > xen_vtpm_register() is similar to xen_be_register()
> >
> > ### Qemu : xen_hvm_init() [xen-hvm.c]###
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    xc_get_hvm_param(xen_xc, xen_domid,
> HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > +    if (stubdom_vtpm) {
> > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > +    }
> > +#endif
> 
> I think I would need to see the rest of the QEMU patches to be able to tell you
> which way I think is best.
> In this context is vtpm an emulated device or a PV backend?
> 

I have submitted Qemu patch series -- "[PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for	HVM virtual machine"

It is not an emulated device. It is a pv backend. This driver transfers any request/repond between TPM xenstubdoms driver 
and Xen vTPM stubdom, and facilitates communications between Xen vTPM stubdom domain and vTPM xenstubdoms driver

Quan 

> >     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);
> > ##### Qemu ####
> >
> >
> > Quan
> >

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 11:04:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 11: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 1Xkswh-0002sB-1B; Sun, 02 Nov 2014 11:03:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xkswf-0002s6-PS
	for xen-devel@lists.xen.org; Sun, 02 Nov 2014 11:03:41 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	86/D2-03148-D8F06545; Sun, 02 Nov 2014 11:03:41 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1414926219!12001296!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10366 invoked from network); 2 Nov 2014 11:03:40 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-27.messagelabs.com with SMTP;
	2 Nov 2014 11:03:40 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 02 Nov 2014 03:03:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,295,1413270000"; d="scan'208";a="624954187"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by fmsmga002.fm.intel.com with ESMTP; 02 Nov 2014 03:03:36 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Sun, 2 Nov 2014 19:03:35 +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.3.195.1; Sun, 2 Nov 2014 19:03:35 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.44]) with mapi id
	14.03.0195.001; Sun, 2 Nov 2014 19:03:34 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM
	parameter for HVM virtual machine
Thread-Index: AQHP9DbHLV3lrnmClECyXqXbZ9NI5ZxIAKAAgACIFhCAABuCWoAAC/3AgAFHs4CAAzeFIA==
Date: Sun, 2 Nov 2014 11:03:33 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E81E000@SHSMSX101.ccr.corp.intel.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<1414654731-32641-3-git-send-email-quan.xu@intel.com>
	<545225D2.8090203@citrix.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81CCD8@SHSMSX101.ccr.corp.intel.com>
	<54522C3C.4040807@citrix.com>
	<alpine.DEB.2.02.1410301328250.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81CF19@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1410311749320.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1410311749320.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM
 parameter for HVM virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Saturday, November 01, 2014 1:51 AM
> To: Xu, Quan
> Cc: Stefano Stabellini; Andrew Cooper; xen-devel@lists.xen.org;
> ian.jackson@eu.citrix.com; tim@xen.org; keir@xen.org; ian.campbell@citrix.com;
> jbeulich@suse.com
> Subject: RE: [Xen-devel] [PATCH 2/6] vTPM: add
> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> 
> On Thu, 30 Oct 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Thursday, October 30, 2014 9:35 PM
> > > To: Andrew Cooper
> > > Cc: Xu, Quan; xen-devel@lists.xen.org; ian.jackson@eu.citrix.com;
> > > tim@xen.org; keir@xen.org; ian.campbell@citrix.com;
> > > jbeulich@suse.com
> > > Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> > > HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> > >
> > > On Thu, 30 Oct 2014, Andrew Cooper wrote:
> > > > On 30/10/14 12:05, Xu, Quan wrote:
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> > > > >> Sent: Thursday, October 30, 2014 7:50 PM
> > > > >> To: Xu, Quan; xen-devel@lists.xen.org
> > > > >> Cc: keir@xen.org; ian.campbell@citrix.com; tim@xen.org;
> > > > >> ian.jackson@eu.citrix.com; jbeulich@suse.com
> > > > >> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> > > > >> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> > > > >>
> > > > >> On 30/10/14 07:38, Quan Xu wrote:
> > > > >>> Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > > >> What is the purpose of this parameter?  A patch like this is
> > > > >> currently unacceptable, especially as the libxl hunk indicates
> > > > >> that the parameter name does not match whatever information you
> > > > >> are putting
> > > into it.
> > > > >>
> > > > > Thanks for your suggestion.
> > > > > This parameter tell the Qemu whether to register Qemu vTPM
> > > > > frontend in
> > > xen_hvm_init().
> > > > > Qemu will get the parameter value by xc_get_hvm_param(). How can
> > > > > I
> > > change it?
> > > >
> > > > This is surely something which should be a command line parameter
> > > > to qemu, or perhaps for qemu to read out of xenstore.
> > > >
> > > > An HVM param is entirely inappropriate for this purpose, in my opinion.
> > >
> > > I agree that an HVM param for this might not the best way to do it,
> > > but I can see why Quan did it that way as we already have a few key
> > > parameters passed to QEMU that way.
> > >
> > > A QEMU command line option, QMP command or xenstore key would be
> better.
> >
> > If hvm param is not the best way, I think xenstore key would be better.
> >
> > Below is part of Qemu patch, that's why I add HVM_PARAM_STUBDOM_VTPM
> param.
> > xen_vtpm_register() is similar to xen_be_register()
> >
> > ### Qemu : xen_hvm_init() [xen-hvm.c]###
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    xc_get_hvm_param(xen_xc, xen_domid,
> HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > +    if (stubdom_vtpm) {
> > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > +    }
> > +#endif
> 
> I think I would need to see the rest of the QEMU patches to be able to tell you
> which way I think is best.
> In this context is vtpm an emulated device or a PV backend?
> 

I have submitted Qemu patch series -- "[PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for	HVM virtual machine"

It is not an emulated device. It is a pv backend. This driver transfers any request/repond between TPM xenstubdoms driver 
and Xen vTPM stubdom, and facilitates communications between Xen vTPM stubdom domain and vTPM xenstubdoms driver

Quan 

> >     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);
> > ##### Qemu ####
> >
> >
> > Quan
> >

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 13:53:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 13:53:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkvak-0004fZ-05; Sun, 02 Nov 2014 13:53: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@citrix.com>) id 1Xkvah-0004fU-ON
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 13:53:11 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	A3/55-02696-74736545; Sun, 02 Nov 2014 13:53:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1414936388!11955687!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4491 invoked from network); 2 Nov 2014 13:53:09 -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;
	2 Nov 2014 13:53:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187307606"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 08:53:07 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xkvac-0000uX-NR;
	Sun, 02 Nov 2014 13:53:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xkvac-0006rK-9V;
	Sun, 02 Nov 2014 13:53:06 +0000
Date: Sun, 2 Nov 2014 13:53:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31313-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 18214
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31313: 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: multipart/mixed; boundary="===============4967953252405999262=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4967953252405999262==
Content-Type: text/plain
Content-Length: 18138
Content-Transfer-Encoding: quoted-printable

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                9f935675d41aa51ebf929fc977cf530ff7d1a7fc
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
People who touched revisions under test:
  Aaron Brown "aaron.f.brown@intel.com"
  Aaron Brown <aaron.f.brown@intel.com>
  Adel Gadllah <adel.gadllah@gmail.com>
  Alex Gartrell <agartrell@fb.com>
  Alexander Duyck <alexander.h.duyck@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexandre Belloni <alexandre.belloni@free-electrons.com>
  Alexandre Courbot <acourbot@nvidia.com>
  Alexei Starovoitov <ast@plumgrid.com>
  Andrew Lunn <andrew@lunn.ch>
  Andrew Morton <akpm@linux-foundation.org>
  Andriy Skulysh <askulysh@gmail.com>
  Andr=C3=A1s Mur=C3=A1nyi <muranyia@gmail.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
  Anish Bhatt <anish@chelsio.com>
  Arnaldo Carvalho de Melo <acme@redhat.com>
  Arnd Bergmann <arnd@arndb.de>
  Arturo Borrero <arturo.borrero.glez@gmail.com>
  Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
  Avinash Patil <patila@marvell.com>
  Ben Hutchings <ben@decadent.org.uk>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bjorn Helgaas <bhelgaas@google.com>
  Borislav Petkov <bp@suse.de>
  Brian Silverman <bsilver16384@gmail.com>
  Casey Leedom <leedom@chelsio.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Cathy Luo <cluo@marvell.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Chin-Ran Lo <crlo@marvell.com>
  Christian Vogel <vogelchr@vogel.cx>
  Christoph Lameter <cl@linux.com>
  Christophe Leroy <christophe.leroy@c-s.fr>
  Clemens Ladisch <clemens@ladisch.de>
  Cong Wang <cwang@twopensource.com>
  Cong Wang <xiyou.wangcong@gmail.com>
  Cyril Brulebois <kibi@debian.org>
  Dan Carpenter <dan.carpenter@oracle.com>
  Dan Streetman <ddstreet@ieee.org>
  Daniel Borkmann <dborkman@redhat.com>
  Daniel Gl=C3=B6ckner <dg@emlix.com>
  Daniel Lezcano <daniel.lezcano@linaro.org>
  Daniel Mack <daniel@zonque.org>
  Daniel Wagner <daniel.wagner@bmw-carit.de>
  Darrick J. Wong <darrick.wong@oracle.com>
  Dave Jones <davej@redhat.com>
  David Rientjes <rientjes@google.com>
  David S. Miller <davem@davemloft.net>
  David Vrabel <david.vrabel@citrix.com>
  Davidlohr Bueso <dave@stgolabs.net>
  Davidlohr Bueso <dbueso@suse.de>
  Dexuan Cui <decui@microsoft.com>
  Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
  Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Dmitry Monakhov <dmonakhov@openvz.org>
  Dmitry Torokhov <dmitry.torokhov@gmail.com>
  Dwight Engen <dwight.engen@oracle.com>
  Edward Cree <ecree@solarflare.com>
  Eli Cohen <eli@dev.mellanox.co.il>
  Eli Cohen <eli@mellanox.com>
  Emil Tantilov <emil.s.tantilov@intel.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Eric B Munson <emunson@akamai.com>
  Eric Dumazet <edumazet@google.com>
  Eric Paris <eparis@redhat.com>
  Eric Rannaud <e@nanocritical.com>
  Fabian Frederick <fabf@skynet.be>
  Fabio Estevam <fabio.estevam@freescale.com>
  Felipe Balbi <balbi@ti.com>
  Felix Fietkau <nbd@openwrt.org>
  Florian Fainelli <f.fainelli@gmail.com>
  Florian Westphal <fw@strlen.de>
  Francesco Ruggeri <fruggeri@arista.com>
  Francesco Ruggeri <fruggeri@aristanetworks.com>
  Geert Uytterhoeven <geert+renesas@glider.be>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Govindarajulu Varadarajan <_govind@gmx.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Guenter Roeck <linux@roeck-us.net>
  H. Nikolaus Schaller <hns@goldelico.com>
  H. Peter Anvin <hpa@linux.intel.com>
  Haim Dreyfuss <haim.dreyfuss@intel.com>
  Haiyang Zhang <haiyangz@microsoft.com>
  Hannes Frederic Sowa <hannes@stressinduktion.org>
  Hans de Goede <hdegoede@redhat.com>
  Hariprasad Shenai <hariprasad@chelsio.com>
  Hauke Mehrtens <hauke@hauke-m.de>
  Hayes Wang <hayeswang@realtek.com>
  hayeswang <hayeswang@realtek.com>
  Heiko Schocher <hs@denx.de>
  Herbert Xu <herbert@gondor.apana.org.au>
  Houcheng Lin <houcheng@gmail.com>
  Ian Morgan <imorgan@primordial.ca>
  Ian Munsie <imunsie@au1.ibm.com>
  Imre Deak <imre.deak@intel.com>
  Ingo Molnar <mingo@kernel.org>
  James Morris <james.l.morris@oracle.com>
  Jan Kara <jack@suse.cz>
  Jan-Benedict Glaw <jbglaw@lug-owl.de>
  Jason Gerecke <jason.gerecke@wacom.com>
  Jason Gerecke <killertofu@gmail.com>
  Javier Martinez Canillas <javier.martinez@collabora.co.uk>
  Jay Vosburgh <jay.vosburgh@canonical.com>
  Jean Pihet <jean.pihet@linaro.org>
  Jeff Epler <jepler@unpythonic.net>	# on v3.14-rt
  Jeff Kirsher <jeffrey.t.kirsher@intel.com>
  Jeff Mahoney <jeffm@suse.com>
  Jens Axboe <axboe@fb.com>
  Jeremy Kerr <jk@ozlabs.org>
  Jerry Hoemann <jerry.hoemann@hp.com>
  Jiang Liu <jiang.liu@linux.intel.com>
  Jim Davis <jim.epost@gmail.com>
  Jim Young <jamesx.m.young@intel.com>
  Jiri Kosina <jkosina@suse.cz>
  Jiri Olsa <jolsa@kernel.org>
  Joe Perches <joe@perches.com>
  Johannes Berg <johannes.berg@intel.com>
  Johannes Weiner <hannes@cmpxchg.org>
  John W. Linville <linville@tuxdriver.com>
  Jon Cooper <jcooper@solarflare.com>
  Jon Maloy <jon.maloy@ericsson.com>
  Jonathan Corbet <corbet@lwn.net>
  Joonsoo Kim <iamjoonsoo.kim@lge.com>
  Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
  Junwei Zhang <linggao.zjw@alibaba-inc.com>
  Juri Lelli <juri.lelli@arm.com>
  Kailang Yang <kailang@realtek.com>
  Kamal Mostafa <kamal@canonical.com>
  Kan Liang <kan.liang@intel.com>
  Karl Beldan <karl.beldan@rivierawaves.com>
  Karsten Wiese <fzuuzf@googlemail.com>
  Kees Cook <keescook@chromium.org>
  Ken Chen <kenchen@google.com>
  Kevin Fenzi <kevin@scrye.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Kirill Smelkov <kirr@nexedi.com>
  Kirill Tkhai <ktkhai@parallels.com>
  Konstantin Khlebnikov <k.khlebnikov@samsung.com>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lars-Peter Clausen <lars@metafoo.de>
  Laurent Pinchart <laurent.pinchart@ideasonboard.com>
  Len Sorensen <lsorense@csclub.uwaterloo.ca>
  Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  LEROY Christophe <christophe.leroy@c-s.fr>
  Li RongQing <roy.qing.li@gmail.com>
  Liad Kaufman <liad.kaufman@intel.com>
  Liam Girdwood <liam.r.girdwood@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Linus Walleij <linus.walleij@linaro.org>
  Lubomir Rintel <lkundrak@v3.sk>
  Lucas Stach <l.stach@pengutronix.de>
  Luciano Coelho <luciano.coelho@intel.com>
  Lv Zheng <lv.zheng@intel.com>
  Maarten ter Huurne <maarten@treewalker.org>
  Maciej W. Rozycki <macro@linux-mips.org>
  Marc Yang <yangyang@marvell.com>
  Marc Zyngier <marc.zyngier@arm.com>
  Marcelo Leitner <mleitner@redhat.com>
  Marcelo Ricardo Leitner <mleitner@redhat.com>
  Marek Belisko <marek@goldelico.com>
  Marek Szyprowski <m.szyprowski@samsung.com>
  Mark Brown <broonie@kernel.org>
  Mark Rustad <mark.d.rustad@intel.com>
  Mark Rutland <mark.rutland@arm.com>
  Martin K. Petersen <martin.petersen@oracle.com>
  Martin Schwidefsky <schwidefsky@de.ibm.com>
  Martin Zhang <martinbj2008@gmail.com>
  Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
  Masanari Iida <standby24x7@gmail.com>
  Mathias Krause <minipli@googlemail.com>
  Matti Gottlieb <matti.gottlieb@intel.com>
  Mauro Carvalho Chehab <mchehab@osg.samsung.com>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael L. Semon <mlsemon35@gmail.com>
  Michal Hocko <mhocko@suse.cz>
  Michal Nazarewicz <mina86@mina86.com>
  Michal Simek <michal.simek@xilinx.com>
  Mika Westerberg <mika.westerberg@linux.intel.com>
  Mikulas Patocka <mpatocka@redhat.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Minchan Kim <minchan@kernel.org>
  Ming Lei <tom.leiming@gmail.com>
  Mugunthan V N <mugunthanvnm@ti.com>
  Namhyung Kim <namhyung@kernel.org>
  Nathan Fontenot <nfont@linux.vnet.ibm.com>
  Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Nikolay Aleksandrov <nikolay@redhat.com>
  Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
  Oleg Nesterov <oleg@redhat.com>
  Oliver Neukum <oneukum@suse.de>
  Olivier Blin <olivier.blin@softathome.com>
  Olivier Gay <ogay@logitech.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Pablo Neira Ayuso <pablo@netfilter.org>
  Patrick McLean <chutzpah@gentoo.org>
  Paul Cercueil <paul@crapouillou.net>
  Paul E. McKenney <paulmck@linux.vnet.ibm.com>
  Pavel Machek <pavel@denx.de>
  Pavel Machek <pavel@ucw.cz>
  Peter Foley <pefoley2@pefoley.com>
  Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Peter Zijlstra <peterz@infradead.org>
  Phil Schmitt <phillip.j.schmitt@intel.com>
  Philipp Zabel <p.zabel@pengutronix.de>
  Plus Chen <pchen@marvell.com>
  Pranith Kumar <bobby.prani@gmail.com>
  Pravin B Shelar <pshelar@nicira.com>
  Rabin Vincent <rabin@rab.in>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
  Randy Dunlap <rdunlap@infradead.org>
  Richard Cochran <richardcochran@gmail.com>
  Richard Weinberger <richard@nod.at>
  Richard Zhu <r65037@freescale.com>
  Richard Zhu <richard.zhu@freescale.com>
  Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
  Riku Voipio <riku.voipio@linaro.org>
  Robert Elliott <elliott@hp.com>
  Roman Gushchin <klamm@yandex-team.ru>
  Sabrina Dubroca <sd@queasysnail.net>
  Sasha Levin <sasha.levin@oracle.com>
  Sathya Perla <sathya.perla@emulex.com>
  Serge E. Hallyn <serge.hallyn@ubuntu.com>
  Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
  Simon Horman <horms@verge.net.au>
  Simon Horman <simon.horman@netronome.com>
  Stanimir Varbanov <svarbanov@mm-sol.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Steven Noonan <steven@uplinklabs.net>
  Steven Rostedt <rostedt@goodmis.org>
  Sudeep Holla <sudeep.holla@arm.com>
  Sudip Mukherjee <sudip@vectorindia.org>
  Sudip Mukherjee <sudipm.mukherjee@gmail.com>
  Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Takashi Iwai <tiwai@suse.de>
  Takashi Sakamoto <o-takashi@sakamocchi.jp>
  Tej Parkash <tej.parkash@qlogic.com>
  Theodore Ts'o <tytso@mit.edu>
  Thomas Gleixner <tglx@linutronix.de>
  Thomas Graf <tgraf@suug.ch>
  Tobias Klauser <tklauser@distanz.ch>
  Tom Herbert <therbert@google.com>
  Tom Lendacky <thomas.lendacky@amd.com>
  Tomi Valkeinen <tomi.valkeinen@ti.com>
  Tony Battersby <tonyb@cybernetics.com>
  Tony Lindgren <tony@atomide.com>
  Vince Bridgers <vbridger@opensource.altera.com>
  Viresh Kumar <viresh.kumar@linaro.org>
  Vlastimil Babka <vbabka@suse.cz>
  WANG Chao <chaowang@redhat.com>
  WANG Cong <xiyou.wangcong@gmail.com>
  Wang Nan <wangnan0@huawei.com>
  Wei Liu <wei.liu2@citrix.com>
  Weijie Yang <weijie.yang@samsung.com>
  Yanko Kaneti <yaneti@declera.com>
  Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
  Ying Xue <ying.xue@windriver.com>
  Yu Zhao <yuzhao@google.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary

broken-step test-armhf-armhf-xl host-install(3)

Not pushing.

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


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

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

--===============4967953252405999262==--

From xen-devel-bounces@lists.xen.org Sun Nov 02 13:53:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 13:53:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkvak-0004fZ-05; Sun, 02 Nov 2014 13:53: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@citrix.com>) id 1Xkvah-0004fU-ON
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 13:53:11 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	A3/55-02696-74736545; Sun, 02 Nov 2014 13:53:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1414936388!11955687!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4491 invoked from network); 2 Nov 2014 13:53:09 -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;
	2 Nov 2014 13:53:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187307606"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 08:53:07 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xkvac-0000uX-NR;
	Sun, 02 Nov 2014 13:53:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xkvac-0006rK-9V;
	Sun, 02 Nov 2014 13:53:06 +0000
Date: Sun, 2 Nov 2014 13:53:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31313-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 18214
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31313: 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: multipart/mixed; boundary="===============4967953252405999262=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4967953252405999262==
Content-Type: text/plain
Content-Length: 18138
Content-Transfer-Encoding: quoted-printable

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                9f935675d41aa51ebf929fc977cf530ff7d1a7fc
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
People who touched revisions under test:
  Aaron Brown "aaron.f.brown@intel.com"
  Aaron Brown <aaron.f.brown@intel.com>
  Adel Gadllah <adel.gadllah@gmail.com>
  Alex Gartrell <agartrell@fb.com>
  Alexander Duyck <alexander.h.duyck@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexandre Belloni <alexandre.belloni@free-electrons.com>
  Alexandre Courbot <acourbot@nvidia.com>
  Alexei Starovoitov <ast@plumgrid.com>
  Andrew Lunn <andrew@lunn.ch>
  Andrew Morton <akpm@linux-foundation.org>
  Andriy Skulysh <askulysh@gmail.com>
  Andr=C3=A1s Mur=C3=A1nyi <muranyia@gmail.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
  Anish Bhatt <anish@chelsio.com>
  Arnaldo Carvalho de Melo <acme@redhat.com>
  Arnd Bergmann <arnd@arndb.de>
  Arturo Borrero <arturo.borrero.glez@gmail.com>
  Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
  Avinash Patil <patila@marvell.com>
  Ben Hutchings <ben@decadent.org.uk>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bjorn Helgaas <bhelgaas@google.com>
  Borislav Petkov <bp@suse.de>
  Brian Silverman <bsilver16384@gmail.com>
  Casey Leedom <leedom@chelsio.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Cathy Luo <cluo@marvell.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Chin-Ran Lo <crlo@marvell.com>
  Christian Vogel <vogelchr@vogel.cx>
  Christoph Lameter <cl@linux.com>
  Christophe Leroy <christophe.leroy@c-s.fr>
  Clemens Ladisch <clemens@ladisch.de>
  Cong Wang <cwang@twopensource.com>
  Cong Wang <xiyou.wangcong@gmail.com>
  Cyril Brulebois <kibi@debian.org>
  Dan Carpenter <dan.carpenter@oracle.com>
  Dan Streetman <ddstreet@ieee.org>
  Daniel Borkmann <dborkman@redhat.com>
  Daniel Gl=C3=B6ckner <dg@emlix.com>
  Daniel Lezcano <daniel.lezcano@linaro.org>
  Daniel Mack <daniel@zonque.org>
  Daniel Wagner <daniel.wagner@bmw-carit.de>
  Darrick J. Wong <darrick.wong@oracle.com>
  Dave Jones <davej@redhat.com>
  David Rientjes <rientjes@google.com>
  David S. Miller <davem@davemloft.net>
  David Vrabel <david.vrabel@citrix.com>
  Davidlohr Bueso <dave@stgolabs.net>
  Davidlohr Bueso <dbueso@suse.de>
  Dexuan Cui <decui@microsoft.com>
  Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
  Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Dmitry Monakhov <dmonakhov@openvz.org>
  Dmitry Torokhov <dmitry.torokhov@gmail.com>
  Dwight Engen <dwight.engen@oracle.com>
  Edward Cree <ecree@solarflare.com>
  Eli Cohen <eli@dev.mellanox.co.il>
  Eli Cohen <eli@mellanox.com>
  Emil Tantilov <emil.s.tantilov@intel.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Eric B Munson <emunson@akamai.com>
  Eric Dumazet <edumazet@google.com>
  Eric Paris <eparis@redhat.com>
  Eric Rannaud <e@nanocritical.com>
  Fabian Frederick <fabf@skynet.be>
  Fabio Estevam <fabio.estevam@freescale.com>
  Felipe Balbi <balbi@ti.com>
  Felix Fietkau <nbd@openwrt.org>
  Florian Fainelli <f.fainelli@gmail.com>
  Florian Westphal <fw@strlen.de>
  Francesco Ruggeri <fruggeri@arista.com>
  Francesco Ruggeri <fruggeri@aristanetworks.com>
  Geert Uytterhoeven <geert+renesas@glider.be>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Govindarajulu Varadarajan <_govind@gmx.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Guenter Roeck <linux@roeck-us.net>
  H. Nikolaus Schaller <hns@goldelico.com>
  H. Peter Anvin <hpa@linux.intel.com>
  Haim Dreyfuss <haim.dreyfuss@intel.com>
  Haiyang Zhang <haiyangz@microsoft.com>
  Hannes Frederic Sowa <hannes@stressinduktion.org>
  Hans de Goede <hdegoede@redhat.com>
  Hariprasad Shenai <hariprasad@chelsio.com>
  Hauke Mehrtens <hauke@hauke-m.de>
  Hayes Wang <hayeswang@realtek.com>
  hayeswang <hayeswang@realtek.com>
  Heiko Schocher <hs@denx.de>
  Herbert Xu <herbert@gondor.apana.org.au>
  Houcheng Lin <houcheng@gmail.com>
  Ian Morgan <imorgan@primordial.ca>
  Ian Munsie <imunsie@au1.ibm.com>
  Imre Deak <imre.deak@intel.com>
  Ingo Molnar <mingo@kernel.org>
  James Morris <james.l.morris@oracle.com>
  Jan Kara <jack@suse.cz>
  Jan-Benedict Glaw <jbglaw@lug-owl.de>
  Jason Gerecke <jason.gerecke@wacom.com>
  Jason Gerecke <killertofu@gmail.com>
  Javier Martinez Canillas <javier.martinez@collabora.co.uk>
  Jay Vosburgh <jay.vosburgh@canonical.com>
  Jean Pihet <jean.pihet@linaro.org>
  Jeff Epler <jepler@unpythonic.net>	# on v3.14-rt
  Jeff Kirsher <jeffrey.t.kirsher@intel.com>
  Jeff Mahoney <jeffm@suse.com>
  Jens Axboe <axboe@fb.com>
  Jeremy Kerr <jk@ozlabs.org>
  Jerry Hoemann <jerry.hoemann@hp.com>
  Jiang Liu <jiang.liu@linux.intel.com>
  Jim Davis <jim.epost@gmail.com>
  Jim Young <jamesx.m.young@intel.com>
  Jiri Kosina <jkosina@suse.cz>
  Jiri Olsa <jolsa@kernel.org>
  Joe Perches <joe@perches.com>
  Johannes Berg <johannes.berg@intel.com>
  Johannes Weiner <hannes@cmpxchg.org>
  John W. Linville <linville@tuxdriver.com>
  Jon Cooper <jcooper@solarflare.com>
  Jon Maloy <jon.maloy@ericsson.com>
  Jonathan Corbet <corbet@lwn.net>
  Joonsoo Kim <iamjoonsoo.kim@lge.com>
  Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
  Junwei Zhang <linggao.zjw@alibaba-inc.com>
  Juri Lelli <juri.lelli@arm.com>
  Kailang Yang <kailang@realtek.com>
  Kamal Mostafa <kamal@canonical.com>
  Kan Liang <kan.liang@intel.com>
  Karl Beldan <karl.beldan@rivierawaves.com>
  Karsten Wiese <fzuuzf@googlemail.com>
  Kees Cook <keescook@chromium.org>
  Ken Chen <kenchen@google.com>
  Kevin Fenzi <kevin@scrye.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Kirill Smelkov <kirr@nexedi.com>
  Kirill Tkhai <ktkhai@parallels.com>
  Konstantin Khlebnikov <k.khlebnikov@samsung.com>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lars-Peter Clausen <lars@metafoo.de>
  Laurent Pinchart <laurent.pinchart@ideasonboard.com>
  Len Sorensen <lsorense@csclub.uwaterloo.ca>
  Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  LEROY Christophe <christophe.leroy@c-s.fr>
  Li RongQing <roy.qing.li@gmail.com>
  Liad Kaufman <liad.kaufman@intel.com>
  Liam Girdwood <liam.r.girdwood@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Linus Walleij <linus.walleij@linaro.org>
  Lubomir Rintel <lkundrak@v3.sk>
  Lucas Stach <l.stach@pengutronix.de>
  Luciano Coelho <luciano.coelho@intel.com>
  Lv Zheng <lv.zheng@intel.com>
  Maarten ter Huurne <maarten@treewalker.org>
  Maciej W. Rozycki <macro@linux-mips.org>
  Marc Yang <yangyang@marvell.com>
  Marc Zyngier <marc.zyngier@arm.com>
  Marcelo Leitner <mleitner@redhat.com>
  Marcelo Ricardo Leitner <mleitner@redhat.com>
  Marek Belisko <marek@goldelico.com>
  Marek Szyprowski <m.szyprowski@samsung.com>
  Mark Brown <broonie@kernel.org>
  Mark Rustad <mark.d.rustad@intel.com>
  Mark Rutland <mark.rutland@arm.com>
  Martin K. Petersen <martin.petersen@oracle.com>
  Martin Schwidefsky <schwidefsky@de.ibm.com>
  Martin Zhang <martinbj2008@gmail.com>
  Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
  Masanari Iida <standby24x7@gmail.com>
  Mathias Krause <minipli@googlemail.com>
  Matti Gottlieb <matti.gottlieb@intel.com>
  Mauro Carvalho Chehab <mchehab@osg.samsung.com>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael L. Semon <mlsemon35@gmail.com>
  Michal Hocko <mhocko@suse.cz>
  Michal Nazarewicz <mina86@mina86.com>
  Michal Simek <michal.simek@xilinx.com>
  Mika Westerberg <mika.westerberg@linux.intel.com>
  Mikulas Patocka <mpatocka@redhat.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Minchan Kim <minchan@kernel.org>
  Ming Lei <tom.leiming@gmail.com>
  Mugunthan V N <mugunthanvnm@ti.com>
  Namhyung Kim <namhyung@kernel.org>
  Nathan Fontenot <nfont@linux.vnet.ibm.com>
  Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Nikolay Aleksandrov <nikolay@redhat.com>
  Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
  Oleg Nesterov <oleg@redhat.com>
  Oliver Neukum <oneukum@suse.de>
  Olivier Blin <olivier.blin@softathome.com>
  Olivier Gay <ogay@logitech.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Pablo Neira Ayuso <pablo@netfilter.org>
  Patrick McLean <chutzpah@gentoo.org>
  Paul Cercueil <paul@crapouillou.net>
  Paul E. McKenney <paulmck@linux.vnet.ibm.com>
  Pavel Machek <pavel@denx.de>
  Pavel Machek <pavel@ucw.cz>
  Peter Foley <pefoley2@pefoley.com>
  Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Peter Zijlstra <peterz@infradead.org>
  Phil Schmitt <phillip.j.schmitt@intel.com>
  Philipp Zabel <p.zabel@pengutronix.de>
  Plus Chen <pchen@marvell.com>
  Pranith Kumar <bobby.prani@gmail.com>
  Pravin B Shelar <pshelar@nicira.com>
  Rabin Vincent <rabin@rab.in>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
  Randy Dunlap <rdunlap@infradead.org>
  Richard Cochran <richardcochran@gmail.com>
  Richard Weinberger <richard@nod.at>
  Richard Zhu <r65037@freescale.com>
  Richard Zhu <richard.zhu@freescale.com>
  Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
  Riku Voipio <riku.voipio@linaro.org>
  Robert Elliott <elliott@hp.com>
  Roman Gushchin <klamm@yandex-team.ru>
  Sabrina Dubroca <sd@queasysnail.net>
  Sasha Levin <sasha.levin@oracle.com>
  Sathya Perla <sathya.perla@emulex.com>
  Serge E. Hallyn <serge.hallyn@ubuntu.com>
  Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
  Simon Horman <horms@verge.net.au>
  Simon Horman <simon.horman@netronome.com>
  Stanimir Varbanov <svarbanov@mm-sol.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Steven Noonan <steven@uplinklabs.net>
  Steven Rostedt <rostedt@goodmis.org>
  Sudeep Holla <sudeep.holla@arm.com>
  Sudip Mukherjee <sudip@vectorindia.org>
  Sudip Mukherjee <sudipm.mukherjee@gmail.com>
  Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Takashi Iwai <tiwai@suse.de>
  Takashi Sakamoto <o-takashi@sakamocchi.jp>
  Tej Parkash <tej.parkash@qlogic.com>
  Theodore Ts'o <tytso@mit.edu>
  Thomas Gleixner <tglx@linutronix.de>
  Thomas Graf <tgraf@suug.ch>
  Tobias Klauser <tklauser@distanz.ch>
  Tom Herbert <therbert@google.com>
  Tom Lendacky <thomas.lendacky@amd.com>
  Tomi Valkeinen <tomi.valkeinen@ti.com>
  Tony Battersby <tonyb@cybernetics.com>
  Tony Lindgren <tony@atomide.com>
  Vince Bridgers <vbridger@opensource.altera.com>
  Viresh Kumar <viresh.kumar@linaro.org>
  Vlastimil Babka <vbabka@suse.cz>
  WANG Chao <chaowang@redhat.com>
  WANG Cong <xiyou.wangcong@gmail.com>
  Wang Nan <wangnan0@huawei.com>
  Wei Liu <wei.liu2@citrix.com>
  Weijie Yang <weijie.yang@samsung.com>
  Yanko Kaneti <yaneti@declera.com>
  Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
  Ying Xue <ying.xue@windriver.com>
  Yu Zhao <yuzhao@google.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary

broken-step test-armhf-armhf-xl host-install(3)

Not pushing.

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


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

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

--===============4967953252405999262==--

From xen-devel-bounces@lists.xen.org Sun Nov 02 14:32:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 14:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkwCP-00059u-8U; Sun, 02 Nov 2014 14:32:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkwCN-00059m-Pn
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 14:32:07 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	84/C8-19763-66046545; Sun, 02 Nov 2014 14:32:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1414938724!13156820!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31194 invoked from network); 2 Nov 2014 14:32:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 14:32:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188686073"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 09:32:03 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkwCI-00016M-Ct;
	Sun, 02 Nov 2014 14:32:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkwCI-0000B4-4A;
	Sun, 02 Nov 2014 14:32:02 +0000
Date: Sun, 2 Nov 2014 14:32:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31310-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31310: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31310
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31310
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31310

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 14:32:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 14:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkwCP-00059u-8U; Sun, 02 Nov 2014 14:32:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkwCN-00059m-Pn
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 14:32:07 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	84/C8-19763-66046545; Sun, 02 Nov 2014 14:32:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1414938724!13156820!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31194 invoked from network); 2 Nov 2014 14:32:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 14:32:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188686073"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 09:32:03 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkwCI-00016M-Ct;
	Sun, 02 Nov 2014 14:32:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkwCI-0000B4-4A;
	Sun, 02 Nov 2014 14:32:02 +0000
Date: Sun, 2 Nov 2014 14:32:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31310-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31310: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31310
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31310
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31310

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz02-00076q-GE; Sun, 02 Nov 2014 17:31:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz01-00076l-9B
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:31:33 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	AB/86-23358-47A66545; Sun, 02 Nov 2014 17:31:32 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1414949491!11487324!1
X-Originating-IP: [217.70.183.198]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14276 invoked from network); 2 Nov 2014 17:31:31 -0000
Received: from relay6-d.mail.gandi.net (HELO relay6-d.mail.gandi.net)
	(217.70.183.198)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:31:31 -0000
Received: from mfilter41-d.gandi.net (mfilter41-d.gandi.net [217.70.178.173])
	by relay6-d.mail.gandi.net (Postfix) with ESMTP id 57E41FB882;
	Sun,  2 Nov 2014 18:31:31 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter41-d.gandi.net
Received: from relay6-d.mail.gandi.net ([217.70.183.198])
	by mfilter41-d.gandi.net (mfilter41-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id v5KDbmId-sJi; Sun,  2 Nov 2014 18:31:29 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id EB6E2FB88B;
	Sun,  2 Nov 2014 18:31:24 +0100 (CET)
Date: Sun, 2 Nov 2014 09:31:22 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 00/10] x86: Support compiling out userspace
 IO (iopl and ioperm)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 makes it possible to compile out the userspace IO system
calls, iopl and ioperm.

The first patch does some 32/64 unification in copy_thread to make subsequent
changes easier.  The second patch simplifies the complex calculation of the TSS
segment limit, which also makes it easier to change in the last patch.  Patches
3-9 introduce helpers to make it easier to compile out IO.  The last patch adds
and uses the new CONFIG_X86_IOPORT to support compiling out userspace IO.

v3 had patches 3-10 as a single patch; v4 splits out the various helpers and
macros into separate patches, as requested by Thomas Gleixner.

I've verified that this compiles after each patch.

Josh Triplett (10):
  x86: process: Unify 32-bit and 64-bit copy_thread I/O bitmap handling
  x86: tss: Eliminate fragile calculation of TSS segment limit
  x86: processor.h: Introduce macros to initialize IO fields of thread
    and TSS
  x86: paravirt: Wrap initialization of set_iopl_mask in a macro
  x86: cpu: Add helper function unifying 32-bit and 64-bit IO init in
    cpu_init
  x86: process: Introduce helper to clear a thread's IO bitmap
  x86: process: Introduce helper to switch iopl mask
  x86: process: Introduce helper for IO-related bits of exit_thread
  x86: process: Introduce helper to switch IO bitmap
  x86: Support compiling out userspace IO (iopl and ioperm)

 arch/x86/Kconfig                      | 10 ++++
 arch/x86/include/asm/desc.h           | 11 +----
 arch/x86/include/asm/paravirt.h       |  2 +
 arch/x86/include/asm/paravirt_types.h |  5 ++
 arch/x86/include/asm/processor.h      | 55 +++++++++++++++++----
 arch/x86/include/asm/syscalls.h       |  3 ++
 arch/x86/kernel/Makefile              |  3 +-
 arch/x86/kernel/cpu/common.c          | 12 +----
 arch/x86/kernel/entry_64.S            |  9 ++--
 arch/x86/kernel/paravirt.c            |  2 +-
 arch/x86/kernel/process-io.h          | 93 +++++++++++++++++++++++++++++++++++
 arch/x86/kernel/process.c             | 34 ++-----------
 arch/x86/kernel/process_32.c          | 41 +++++----------
 arch/x86/kernel/process_64.c          | 27 +++-------
 arch/x86/kernel/ptrace.c              |  8 +++
 arch/x86/xen/enlighten.c              |  4 +-
 drivers/tty/vt/vt_ioctl.c             |  2 +-
 kernel/sys_ni.c                       |  5 ++
 18 files changed, 208 insertions(+), 118 deletions(-)
 create mode 100644 arch/x86/kernel/process-io.h

-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz02-00076q-GE; Sun, 02 Nov 2014 17:31:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz01-00076l-9B
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:31:33 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	AB/86-23358-47A66545; Sun, 02 Nov 2014 17:31:32 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1414949491!11487324!1
X-Originating-IP: [217.70.183.198]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14276 invoked from network); 2 Nov 2014 17:31:31 -0000
Received: from relay6-d.mail.gandi.net (HELO relay6-d.mail.gandi.net)
	(217.70.183.198)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:31:31 -0000
Received: from mfilter41-d.gandi.net (mfilter41-d.gandi.net [217.70.178.173])
	by relay6-d.mail.gandi.net (Postfix) with ESMTP id 57E41FB882;
	Sun,  2 Nov 2014 18:31:31 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter41-d.gandi.net
Received: from relay6-d.mail.gandi.net ([217.70.183.198])
	by mfilter41-d.gandi.net (mfilter41-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id v5KDbmId-sJi; Sun,  2 Nov 2014 18:31:29 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id EB6E2FB88B;
	Sun,  2 Nov 2014 18:31:24 +0100 (CET)
Date: Sun, 2 Nov 2014 09:31:22 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 00/10] x86: Support compiling out userspace
 IO (iopl and ioperm)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 makes it possible to compile out the userspace IO system
calls, iopl and ioperm.

The first patch does some 32/64 unification in copy_thread to make subsequent
changes easier.  The second patch simplifies the complex calculation of the TSS
segment limit, which also makes it easier to change in the last patch.  Patches
3-9 introduce helpers to make it easier to compile out IO.  The last patch adds
and uses the new CONFIG_X86_IOPORT to support compiling out userspace IO.

v3 had patches 3-10 as a single patch; v4 splits out the various helpers and
macros into separate patches, as requested by Thomas Gleixner.

I've verified that this compiles after each patch.

Josh Triplett (10):
  x86: process: Unify 32-bit and 64-bit copy_thread I/O bitmap handling
  x86: tss: Eliminate fragile calculation of TSS segment limit
  x86: processor.h: Introduce macros to initialize IO fields of thread
    and TSS
  x86: paravirt: Wrap initialization of set_iopl_mask in a macro
  x86: cpu: Add helper function unifying 32-bit and 64-bit IO init in
    cpu_init
  x86: process: Introduce helper to clear a thread's IO bitmap
  x86: process: Introduce helper to switch iopl mask
  x86: process: Introduce helper for IO-related bits of exit_thread
  x86: process: Introduce helper to switch IO bitmap
  x86: Support compiling out userspace IO (iopl and ioperm)

 arch/x86/Kconfig                      | 10 ++++
 arch/x86/include/asm/desc.h           | 11 +----
 arch/x86/include/asm/paravirt.h       |  2 +
 arch/x86/include/asm/paravirt_types.h |  5 ++
 arch/x86/include/asm/processor.h      | 55 +++++++++++++++++----
 arch/x86/include/asm/syscalls.h       |  3 ++
 arch/x86/kernel/Makefile              |  3 +-
 arch/x86/kernel/cpu/common.c          | 12 +----
 arch/x86/kernel/entry_64.S            |  9 ++--
 arch/x86/kernel/paravirt.c            |  2 +-
 arch/x86/kernel/process-io.h          | 93 +++++++++++++++++++++++++++++++++++
 arch/x86/kernel/process.c             | 34 ++-----------
 arch/x86/kernel/process_32.c          | 41 +++++----------
 arch/x86/kernel/process_64.c          | 27 +++-------
 arch/x86/kernel/ptrace.c              |  8 +++
 arch/x86/xen/enlighten.c              |  4 +-
 drivers/tty/vt/vt_ioctl.c             |  2 +-
 kernel/sys_ni.c                       |  5 ++
 18 files changed, 208 insertions(+), 118 deletions(-)
 create mode 100644 arch/x86/kernel/process-io.h

-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 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 1Xkz0c-0007CX-TO; Sun, 02 Nov 2014 17:32:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz0b-0007CM-NG
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FA/7E-09936-89A66545; Sun, 02 Nov 2014 17:32:08 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1414949526!4190175!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9643 invoked from network); 2 Nov 2014 17:32:06 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:06 -0000
Received: from mfilter12-d.gandi.net (mfilter12-d.gandi.net [217.70.178.129])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 31F03172070;
	Sun,  2 Nov 2014 18:32:06 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter12-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter12-d.gandi.net (mfilter12-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id MVKr2NIqbDsA; Sun,  2 Nov 2014 18:32:04 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id DCC45172080;
	Sun,  2 Nov 2014 18:31:59 +0100 (CET)
Date: Sun, 2 Nov 2014 09:31:57 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <7159269982aac3b732af2c33a2e3d04e2048bdfb.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 01/10] x86: process: Unify 32-bit and 64-bit
 copy_thread I/O bitmap 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

The 32-bit and 64-bit versions of copy_thread have functionally
identical handling for copying the I/O bitmap, modulo differences in
error handling.  Clean up the error paths in both by moving the copy of
the I/O bitmap to the end, to eliminate the need to free it if
subsequent copy steps fail; move the resulting identical code to a
static inline in a common header.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/kernel/process-io.h | 22 ++++++++++++++++++++++
 arch/x86/kernel/process_32.c | 28 ++++++++--------------------
 arch/x86/kernel/process_64.c | 25 +++++--------------------
 3 files changed, 35 insertions(+), 40 deletions(-)
 create mode 100644 arch/x86/kernel/process-io.h

diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
new file mode 100644
index 0000000..d884444
--- /dev/null
+++ b/arch/x86/kernel/process-io.h
@@ -0,0 +1,22 @@
+#ifndef _X86_KERNEL_PROCESS_IO_H
+#define _X86_KERNEL_PROCESS_IO_H
+
+static inline int copy_io_bitmap(struct task_struct *me,
+				 struct task_struct *p)
+{
+	if (unlikely(test_tsk_thread_flag(me, TIF_IO_BITMAP))) {
+		p->thread.io_bitmap_ptr = kmemdup(me->thread.io_bitmap_ptr,
+						  IO_BITMAP_BYTES, GFP_KERNEL);
+		if (!p->thread.io_bitmap_ptr) {
+			p->thread.io_bitmap_max = 0;
+			return -ENOMEM;
+		}
+		set_tsk_thread_flag(p, TIF_IO_BITMAP);
+	} else {
+		p->thread.io_bitmap_ptr = NULL;
+	}
+
+	return 0;
+}
+
+#endif /* _X86_KERNEL_PROCESS_IO_H */
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 8f3ebfe..07550ff 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -55,6 +55,8 @@
 #include <asm/debugreg.h>
 #include <asm/switch_to.h>
 
+#include "process-io.h"
+
 asmlinkage void ret_from_fork(void) __asm__("ret_from_fork");
 asmlinkage void ret_from_kernel_thread(void) __asm__("ret_from_kernel_thread");
 
@@ -134,7 +136,6 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 {
 	struct pt_regs *childregs = task_pt_regs(p);
 	struct task_struct *tsk;
-	int err;
 
 	p->thread.sp = (unsigned long) childregs;
 	p->thread.sp0 = (unsigned long) (childregs+1);
@@ -166,32 +167,19 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 
 	p->thread.io_bitmap_ptr = NULL;
 	tsk = current;
-	err = -ENOMEM;
-
-	if (unlikely(test_tsk_thread_flag(tsk, TIF_IO_BITMAP))) {
-		p->thread.io_bitmap_ptr = kmemdup(tsk->thread.io_bitmap_ptr,
-						IO_BITMAP_BYTES, GFP_KERNEL);
-		if (!p->thread.io_bitmap_ptr) {
-			p->thread.io_bitmap_max = 0;
-			return -ENOMEM;
-		}
-		set_tsk_thread_flag(p, TIF_IO_BITMAP);
-	}
-
-	err = 0;
 
 	/*
 	 * Set a new TLS for the child thread?
 	 */
-	if (clone_flags & CLONE_SETTLS)
+	if (clone_flags & CLONE_SETTLS) {
+		int err;
 		err = do_set_thread_area(p, -1,
 			(struct user_desc __user *)childregs->si, 0);
-
-	if (err && p->thread.io_bitmap_ptr) {
-		kfree(p->thread.io_bitmap_ptr);
-		p->thread.io_bitmap_max = 0;
+		if(err)
+			return err;
 	}
-	return err;
+
+	return copy_io_bitmap(tsk, p);
 }
 
 void
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 3ed4a68..b1babb4 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -50,6 +50,8 @@
 #include <asm/debugreg.h>
 #include <asm/switch_to.h>
 
+#include "process-io.h"
+
 asmlinkage extern void ret_from_fork(void);
 
 __visible DEFINE_PER_CPU(unsigned long, old_rsp);
@@ -154,7 +156,6 @@ static inline u32 read_32bit_tls(struct task_struct *t, int tls)
 int copy_thread(unsigned long clone_flags, unsigned long sp,
 		unsigned long arg, struct task_struct *p)
 {
-	int err;
 	struct pt_regs *childregs;
 	struct task_struct *me = current;
 
@@ -191,21 +192,11 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 	if (sp)
 		childregs->sp = sp;
 
-	err = -ENOMEM;
-	if (unlikely(test_tsk_thread_flag(me, TIF_IO_BITMAP))) {
-		p->thread.io_bitmap_ptr = kmemdup(me->thread.io_bitmap_ptr,
-						  IO_BITMAP_BYTES, GFP_KERNEL);
-		if (!p->thread.io_bitmap_ptr) {
-			p->thread.io_bitmap_max = 0;
-			return -ENOMEM;
-		}
-		set_tsk_thread_flag(p, TIF_IO_BITMAP);
-	}
-
 	/*
 	 * Set a new TLS for the child thread?
 	 */
 	if (clone_flags & CLONE_SETTLS) {
+		int err;
 #ifdef CONFIG_IA32_EMULATION
 		if (test_thread_flag(TIF_IA32))
 			err = do_set_thread_area(p, -1,
@@ -214,16 +205,10 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 #endif
 			err = do_arch_prctl(p, ARCH_SET_FS, childregs->r8);
 		if (err)
-			goto out;
-	}
-	err = 0;
-out:
-	if (err && p->thread.io_bitmap_ptr) {
-		kfree(p->thread.io_bitmap_ptr);
-		p->thread.io_bitmap_max = 0;
+			return err;
 	}
 
-	return err;
+	return copy_io_bitmap(me, p);
 }
 
 static void
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 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 1Xkz0c-0007CX-TO; Sun, 02 Nov 2014 17:32:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz0b-0007CM-NG
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FA/7E-09936-89A66545; Sun, 02 Nov 2014 17:32:08 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1414949526!4190175!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9643 invoked from network); 2 Nov 2014 17:32:06 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:06 -0000
Received: from mfilter12-d.gandi.net (mfilter12-d.gandi.net [217.70.178.129])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 31F03172070;
	Sun,  2 Nov 2014 18:32:06 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter12-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter12-d.gandi.net (mfilter12-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id MVKr2NIqbDsA; Sun,  2 Nov 2014 18:32:04 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id DCC45172080;
	Sun,  2 Nov 2014 18:31:59 +0100 (CET)
Date: Sun, 2 Nov 2014 09:31:57 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <7159269982aac3b732af2c33a2e3d04e2048bdfb.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 01/10] x86: process: Unify 32-bit and 64-bit
 copy_thread I/O bitmap 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

The 32-bit and 64-bit versions of copy_thread have functionally
identical handling for copying the I/O bitmap, modulo differences in
error handling.  Clean up the error paths in both by moving the copy of
the I/O bitmap to the end, to eliminate the need to free it if
subsequent copy steps fail; move the resulting identical code to a
static inline in a common header.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/kernel/process-io.h | 22 ++++++++++++++++++++++
 arch/x86/kernel/process_32.c | 28 ++++++++--------------------
 arch/x86/kernel/process_64.c | 25 +++++--------------------
 3 files changed, 35 insertions(+), 40 deletions(-)
 create mode 100644 arch/x86/kernel/process-io.h

diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
new file mode 100644
index 0000000..d884444
--- /dev/null
+++ b/arch/x86/kernel/process-io.h
@@ -0,0 +1,22 @@
+#ifndef _X86_KERNEL_PROCESS_IO_H
+#define _X86_KERNEL_PROCESS_IO_H
+
+static inline int copy_io_bitmap(struct task_struct *me,
+				 struct task_struct *p)
+{
+	if (unlikely(test_tsk_thread_flag(me, TIF_IO_BITMAP))) {
+		p->thread.io_bitmap_ptr = kmemdup(me->thread.io_bitmap_ptr,
+						  IO_BITMAP_BYTES, GFP_KERNEL);
+		if (!p->thread.io_bitmap_ptr) {
+			p->thread.io_bitmap_max = 0;
+			return -ENOMEM;
+		}
+		set_tsk_thread_flag(p, TIF_IO_BITMAP);
+	} else {
+		p->thread.io_bitmap_ptr = NULL;
+	}
+
+	return 0;
+}
+
+#endif /* _X86_KERNEL_PROCESS_IO_H */
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 8f3ebfe..07550ff 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -55,6 +55,8 @@
 #include <asm/debugreg.h>
 #include <asm/switch_to.h>
 
+#include "process-io.h"
+
 asmlinkage void ret_from_fork(void) __asm__("ret_from_fork");
 asmlinkage void ret_from_kernel_thread(void) __asm__("ret_from_kernel_thread");
 
@@ -134,7 +136,6 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 {
 	struct pt_regs *childregs = task_pt_regs(p);
 	struct task_struct *tsk;
-	int err;
 
 	p->thread.sp = (unsigned long) childregs;
 	p->thread.sp0 = (unsigned long) (childregs+1);
@@ -166,32 +167,19 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 
 	p->thread.io_bitmap_ptr = NULL;
 	tsk = current;
-	err = -ENOMEM;
-
-	if (unlikely(test_tsk_thread_flag(tsk, TIF_IO_BITMAP))) {
-		p->thread.io_bitmap_ptr = kmemdup(tsk->thread.io_bitmap_ptr,
-						IO_BITMAP_BYTES, GFP_KERNEL);
-		if (!p->thread.io_bitmap_ptr) {
-			p->thread.io_bitmap_max = 0;
-			return -ENOMEM;
-		}
-		set_tsk_thread_flag(p, TIF_IO_BITMAP);
-	}
-
-	err = 0;
 
 	/*
 	 * Set a new TLS for the child thread?
 	 */
-	if (clone_flags & CLONE_SETTLS)
+	if (clone_flags & CLONE_SETTLS) {
+		int err;
 		err = do_set_thread_area(p, -1,
 			(struct user_desc __user *)childregs->si, 0);
-
-	if (err && p->thread.io_bitmap_ptr) {
-		kfree(p->thread.io_bitmap_ptr);
-		p->thread.io_bitmap_max = 0;
+		if(err)
+			return err;
 	}
-	return err;
+
+	return copy_io_bitmap(tsk, p);
 }
 
 void
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 3ed4a68..b1babb4 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -50,6 +50,8 @@
 #include <asm/debugreg.h>
 #include <asm/switch_to.h>
 
+#include "process-io.h"
+
 asmlinkage extern void ret_from_fork(void);
 
 __visible DEFINE_PER_CPU(unsigned long, old_rsp);
@@ -154,7 +156,6 @@ static inline u32 read_32bit_tls(struct task_struct *t, int tls)
 int copy_thread(unsigned long clone_flags, unsigned long sp,
 		unsigned long arg, struct task_struct *p)
 {
-	int err;
 	struct pt_regs *childregs;
 	struct task_struct *me = current;
 
@@ -191,21 +192,11 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 	if (sp)
 		childregs->sp = sp;
 
-	err = -ENOMEM;
-	if (unlikely(test_tsk_thread_flag(me, TIF_IO_BITMAP))) {
-		p->thread.io_bitmap_ptr = kmemdup(me->thread.io_bitmap_ptr,
-						  IO_BITMAP_BYTES, GFP_KERNEL);
-		if (!p->thread.io_bitmap_ptr) {
-			p->thread.io_bitmap_max = 0;
-			return -ENOMEM;
-		}
-		set_tsk_thread_flag(p, TIF_IO_BITMAP);
-	}
-
 	/*
 	 * Set a new TLS for the child thread?
 	 */
 	if (clone_flags & CLONE_SETTLS) {
+		int err;
 #ifdef CONFIG_IA32_EMULATION
 		if (test_thread_flag(TIF_IA32))
 			err = do_set_thread_area(p, -1,
@@ -214,16 +205,10 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 #endif
 			err = do_arch_prctl(p, ARCH_SET_FS, childregs->r8);
 		if (err)
-			goto out;
-	}
-	err = 0;
-out:
-	if (err && p->thread.io_bitmap_ptr) {
-		kfree(p->thread.io_bitmap_ptr);
-		p->thread.io_bitmap_max = 0;
+			return err;
 	}
 
-	return err;
+	return copy_io_bitmap(me, p);
 }
 
 static void
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz0i-0007Dm-AZ; Sun, 02 Nov 2014 17:32:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz0g-0007DQ-Nd
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:14 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	31/72-02712-D9A66545; Sun, 02 Nov 2014 17:32:13 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1414949533!8727416!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29183 invoked from network); 2 Nov 2014 17:32:13 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:13 -0000
Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 113CD172077;
	Sun,  2 Nov 2014 18:32:13 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id JNRMcpx7DdhG; Sun,  2 Nov 2014 18:32:11 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 32547172071;
	Sun,  2 Nov 2014 18:32:08 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:07 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <8982dc6cc6beadae9488830d566fb1c8cf42d4ee.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 02/10] x86: tss: Eliminate fragile
 calculation of TSS segment limit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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_tss_desc has a complex calculation of the TSS segment limit,
duplicating the quirky details of the I/O bitmap array length, and
requiring a complex comment to explain.  Replace that calculation with a
simpler one based on the offsetof the "stack" field that follows the
array.

That then removes the last use of IO_BITMAP_OFFSET, so delete it.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Alexander van Heukelum <heukelum@fastmail.fm>
---
 arch/x86/include/asm/desc.h      | 11 +----------
 arch/x86/include/asm/processor.h |  4 +++-
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 50d033a..f8dc455 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -177,16 +177,7 @@ static inline void __set_tss_desc(unsigned cpu, unsigned int entry, void *addr)
 	struct desc_struct *d = get_cpu_gdt_table(cpu);
 	tss_desc tss;
 
-	/*
-	 * sizeof(unsigned long) coming from an extra "long" at the end
-	 * of the iobitmap. See tss_struct definition in processor.h
-	 *
-	 * -1? seg base+limit should be pointing to the address of the
-	 * last valid byte
-	 */
-	set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS,
-			      IO_BITMAP_OFFSET + IO_BITMAP_BYTES +
-			      sizeof(unsigned long) - 1);
+	set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, TSS_LIMIT);
 	write_gdt_entry(d, entry, &tss, DESC_TSS);
 }
 
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index eb71ec7..76751cd 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -258,9 +258,11 @@ struct x86_hw_tss {
 #define IO_BITMAP_BITS			65536
 #define IO_BITMAP_BYTES			(IO_BITMAP_BITS/8)
 #define IO_BITMAP_LONGS			(IO_BITMAP_BYTES/sizeof(long))
-#define IO_BITMAP_OFFSET		offsetof(struct tss_struct, io_bitmap)
 #define INVALID_IO_BITMAP_OFFSET	0x8000
 
+/* Segment limits point to the last valid byte, hence the -1 */
+#define TSS_LIMIT	(offsetof(struct tss_struct, stack) - 1)
+
 struct tss_struct {
 	/*
 	 * The hardware state:
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz0i-0007Dm-AZ; Sun, 02 Nov 2014 17:32:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz0g-0007DQ-Nd
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:14 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	31/72-02712-D9A66545; Sun, 02 Nov 2014 17:32:13 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1414949533!8727416!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29183 invoked from network); 2 Nov 2014 17:32:13 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:13 -0000
Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 113CD172077;
	Sun,  2 Nov 2014 18:32:13 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id JNRMcpx7DdhG; Sun,  2 Nov 2014 18:32:11 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 32547172071;
	Sun,  2 Nov 2014 18:32:08 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:07 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <8982dc6cc6beadae9488830d566fb1c8cf42d4ee.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 02/10] x86: tss: Eliminate fragile
 calculation of TSS segment limit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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_tss_desc has a complex calculation of the TSS segment limit,
duplicating the quirky details of the I/O bitmap array length, and
requiring a complex comment to explain.  Replace that calculation with a
simpler one based on the offsetof the "stack" field that follows the
array.

That then removes the last use of IO_BITMAP_OFFSET, so delete it.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Alexander van Heukelum <heukelum@fastmail.fm>
---
 arch/x86/include/asm/desc.h      | 11 +----------
 arch/x86/include/asm/processor.h |  4 +++-
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 50d033a..f8dc455 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -177,16 +177,7 @@ static inline void __set_tss_desc(unsigned cpu, unsigned int entry, void *addr)
 	struct desc_struct *d = get_cpu_gdt_table(cpu);
 	tss_desc tss;
 
-	/*
-	 * sizeof(unsigned long) coming from an extra "long" at the end
-	 * of the iobitmap. See tss_struct definition in processor.h
-	 *
-	 * -1? seg base+limit should be pointing to the address of the
-	 * last valid byte
-	 */
-	set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS,
-			      IO_BITMAP_OFFSET + IO_BITMAP_BYTES +
-			      sizeof(unsigned long) - 1);
+	set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, TSS_LIMIT);
 	write_gdt_entry(d, entry, &tss, DESC_TSS);
 }
 
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index eb71ec7..76751cd 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -258,9 +258,11 @@ struct x86_hw_tss {
 #define IO_BITMAP_BITS			65536
 #define IO_BITMAP_BYTES			(IO_BITMAP_BITS/8)
 #define IO_BITMAP_LONGS			(IO_BITMAP_BYTES/sizeof(long))
-#define IO_BITMAP_OFFSET		offsetof(struct tss_struct, io_bitmap)
 #define INVALID_IO_BITMAP_OFFSET	0x8000
 
+/* Segment limits point to the last valid byte, hence the -1 */
+#define TSS_LIMIT	(offsetof(struct tss_struct, stack) - 1)
+
 struct tss_struct {
 	/*
 	 * The hardware state:
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz0o-0007Fg-Ny; Sun, 02 Nov 2014 17:32:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz0n-0007FG-Ev
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2A/E3-24532-4AA66545; Sun, 02 Nov 2014 17:32:20 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1414949540!12191738!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12901 invoked from network); 2 Nov 2014 17:32:20 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:20 -0000
Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 1CEDD172089;
	Sun,  2 Nov 2014 18:32:20 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id MSf7-cHtRym7; Sun,  2 Nov 2014 18:32:18 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 4548417208C;
	Sun,  2 Nov 2014 18:32:15 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:14 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <a7a86806f71398b4b0bbb78eecee0d72a05acc23.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 03/10] x86: processor.h: Introduce macros to
 initialize IO fields of thread and TSS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 change, just splitting out parts of the existing
INIT_THREAD and INIT_TSS macros.  This will simplify making those fields
optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/include/asm/processor.h | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 76751cd..0a12534 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -842,12 +842,7 @@ static inline void spin_lock_prefetch(const void *x)
 #define STACK_TOP		TASK_SIZE
 #define STACK_TOP_MAX		STACK_TOP
 
-#define INIT_THREAD  {							  \
-	.sp0			= sizeof(init_stack) + (long)&init_stack, \
-	.vm86_info		= NULL,					  \
-	.sysenter_cs		= __KERNEL_CS,				  \
-	.io_bitmap_ptr		= NULL,					  \
-}
+#define INIT_THREAD_IO .io_bitmap_ptr = NULL,
 
 /*
  * Note that the .io_bitmap member must be extra-big. This is because
@@ -855,6 +850,15 @@ static inline void spin_lock_prefetch(const void *x)
  * permission bitmap. The extra byte must be all 1 bits, and must
  * be within the limit.
  */
+#define INIT_TSS_IO .io_bitmap = { [0 ... IO_BITMAP_LONGS] = ~0 },
+
+#define INIT_THREAD  {							  \
+	.sp0			= sizeof(init_stack) + (long)&init_stack, \
+	.vm86_info		= NULL,					  \
+	.sysenter_cs		= __KERNEL_CS,				  \
+	INIT_THREAD_IO							  \
+}
+
 #define INIT_TSS  {							  \
 	.x86_tss = {							  \
 		.sp0		= sizeof(init_stack) + (long)&init_stack, \
@@ -862,7 +866,7 @@ static inline void spin_lock_prefetch(const void *x)
 		.ss1		= __KERNEL_CS,				  \
 		.io_bitmap_base	= INVALID_IO_BITMAP_OFFSET,		  \
 	 },								  \
-	.io_bitmap		= { [0 ... IO_BITMAP_LONGS] = ~0 },	  \
+	INIT_TSS_IO							  \
 }
 
 extern unsigned long thread_saved_pc(struct task_struct *tsk);
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz0o-0007Fg-Ny; Sun, 02 Nov 2014 17:32:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz0n-0007FG-Ev
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2A/E3-24532-4AA66545; Sun, 02 Nov 2014 17:32:20 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1414949540!12191738!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12901 invoked from network); 2 Nov 2014 17:32:20 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:20 -0000
Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 1CEDD172089;
	Sun,  2 Nov 2014 18:32:20 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id MSf7-cHtRym7; Sun,  2 Nov 2014 18:32:18 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 4548417208C;
	Sun,  2 Nov 2014 18:32:15 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:14 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <a7a86806f71398b4b0bbb78eecee0d72a05acc23.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 03/10] x86: processor.h: Introduce macros to
 initialize IO fields of thread and TSS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 change, just splitting out parts of the existing
INIT_THREAD and INIT_TSS macros.  This will simplify making those fields
optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/include/asm/processor.h | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 76751cd..0a12534 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -842,12 +842,7 @@ static inline void spin_lock_prefetch(const void *x)
 #define STACK_TOP		TASK_SIZE
 #define STACK_TOP_MAX		STACK_TOP
 
-#define INIT_THREAD  {							  \
-	.sp0			= sizeof(init_stack) + (long)&init_stack, \
-	.vm86_info		= NULL,					  \
-	.sysenter_cs		= __KERNEL_CS,				  \
-	.io_bitmap_ptr		= NULL,					  \
-}
+#define INIT_THREAD_IO .io_bitmap_ptr = NULL,
 
 /*
  * Note that the .io_bitmap member must be extra-big. This is because
@@ -855,6 +850,15 @@ static inline void spin_lock_prefetch(const void *x)
  * permission bitmap. The extra byte must be all 1 bits, and must
  * be within the limit.
  */
+#define INIT_TSS_IO .io_bitmap = { [0 ... IO_BITMAP_LONGS] = ~0 },
+
+#define INIT_THREAD  {							  \
+	.sp0			= sizeof(init_stack) + (long)&init_stack, \
+	.vm86_info		= NULL,					  \
+	.sysenter_cs		= __KERNEL_CS,				  \
+	INIT_THREAD_IO							  \
+}
+
 #define INIT_TSS  {							  \
 	.x86_tss = {							  \
 		.sp0		= sizeof(init_stack) + (long)&init_stack, \
@@ -862,7 +866,7 @@ static inline void spin_lock_prefetch(const void *x)
 		.ss1		= __KERNEL_CS,				  \
 		.io_bitmap_base	= INVALID_IO_BITMAP_OFFSET,		  \
 	 },								  \
-	.io_bitmap		= { [0 ... IO_BITMAP_LONGS] = ~0 },	  \
+	INIT_TSS_IO							  \
 }
 
 extern unsigned long thread_saved_pc(struct task_struct *tsk);
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz0w-0007II-46; Sun, 02 Nov 2014 17:32:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz0v-0007Hw-Ij
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:29 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	BB/61-27785-CAA66545; Sun, 02 Nov 2014 17:32:28 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1414949548!12062812!1
X-Originating-IP: [217.70.183.197]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20602 invoked from network); 2 Nov 2014 17:32:28 -0000
Received: from relay5-d.mail.gandi.net (HELO relay5-d.mail.gandi.net)
	(217.70.183.197)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:28 -0000
Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168])
	by relay5-d.mail.gandi.net (Postfix) with ESMTP id EF34E41C04B;
	Sun,  2 Nov 2014 18:32:27 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net
Received: from relay5-d.mail.gandi.net ([217.70.183.197])
	by mfilter37-d.gandi.net (mfilter37-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id UaoSjwEzpVL1; Sun,  2 Nov 2014 18:32:26 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id BA80341C054;
	Sun,  2 Nov 2014 18:32:22 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:20 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <d50798c4b4860edfed4f95e34b7ffac3e6622aaf.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 04/10] x86: paravirt: Wrap initialization of
 set_iopl_mask in a macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will allow making set_iopl_mask optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/include/asm/paravirt_types.h | 1 +
 arch/x86/kernel/paravirt.c            | 2 +-
 arch/x86/xen/enlighten.c              | 4 ++--
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 7549b8b..3caf2a8 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -143,6 +143,7 @@ struct pv_cpu_ops {
 	void (*load_sp0)(struct tss_struct *tss, struct thread_struct *t);
 
 	void (*set_iopl_mask)(unsigned mask);
+#define INIT_SET_IOPL_MASK(f) .set_iopl_mask = f,
 
 	void (*wbinvd)(void);
 	void (*io_delay)(void);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 548d25f..e7969d4 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -383,7 +383,7 @@ __visible struct pv_cpu_ops pv_cpu_ops = {
 	.iret = native_iret,
 	.swapgs = native_swapgs,
 
-	.set_iopl_mask = native_set_iopl_mask,
+	INIT_SET_IOPL_MASK(native_set_iopl_mask)
 	.io_delay = native_io_delay,
 
 	.start_context_switch = paravirt_nop,
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 1a3f044..8ad0778 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -912,7 +912,7 @@ static void xen_load_sp0(struct tss_struct *tss,
 	xen_mc_issue(PARAVIRT_LAZY_CPU);
 }
 
-static void xen_set_iopl_mask(unsigned mask)
+static void __maybe_unused xen_set_iopl_mask(unsigned mask)
 {
 	struct physdev_set_iopl set_iopl;
 
@@ -1279,7 +1279,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.write_idt_entry = xen_write_idt_entry,
 	.load_sp0 = xen_load_sp0,
 
-	.set_iopl_mask = xen_set_iopl_mask,
+	INIT_SET_IOPL_MASK(xen_set_iopl_mask)
 	.io_delay = xen_io_delay,
 
 	/* Xen takes care of %gs when switching to usermode for us */
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz0w-0007II-46; Sun, 02 Nov 2014 17:32:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz0v-0007Hw-Ij
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:29 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	BB/61-27785-CAA66545; Sun, 02 Nov 2014 17:32:28 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1414949548!12062812!1
X-Originating-IP: [217.70.183.197]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20602 invoked from network); 2 Nov 2014 17:32:28 -0000
Received: from relay5-d.mail.gandi.net (HELO relay5-d.mail.gandi.net)
	(217.70.183.197)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:28 -0000
Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168])
	by relay5-d.mail.gandi.net (Postfix) with ESMTP id EF34E41C04B;
	Sun,  2 Nov 2014 18:32:27 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net
Received: from relay5-d.mail.gandi.net ([217.70.183.197])
	by mfilter37-d.gandi.net (mfilter37-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id UaoSjwEzpVL1; Sun,  2 Nov 2014 18:32:26 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id BA80341C054;
	Sun,  2 Nov 2014 18:32:22 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:20 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <d50798c4b4860edfed4f95e34b7ffac3e6622aaf.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 04/10] x86: paravirt: Wrap initialization of
 set_iopl_mask in a macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will allow making set_iopl_mask optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/include/asm/paravirt_types.h | 1 +
 arch/x86/kernel/paravirt.c            | 2 +-
 arch/x86/xen/enlighten.c              | 4 ++--
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 7549b8b..3caf2a8 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -143,6 +143,7 @@ struct pv_cpu_ops {
 	void (*load_sp0)(struct tss_struct *tss, struct thread_struct *t);
 
 	void (*set_iopl_mask)(unsigned mask);
+#define INIT_SET_IOPL_MASK(f) .set_iopl_mask = f,
 
 	void (*wbinvd)(void);
 	void (*io_delay)(void);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 548d25f..e7969d4 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -383,7 +383,7 @@ __visible struct pv_cpu_ops pv_cpu_ops = {
 	.iret = native_iret,
 	.swapgs = native_swapgs,
 
-	.set_iopl_mask = native_set_iopl_mask,
+	INIT_SET_IOPL_MASK(native_set_iopl_mask)
 	.io_delay = native_io_delay,
 
 	.start_context_switch = paravirt_nop,
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 1a3f044..8ad0778 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -912,7 +912,7 @@ static void xen_load_sp0(struct tss_struct *tss,
 	xen_mc_issue(PARAVIRT_LAZY_CPU);
 }
 
-static void xen_set_iopl_mask(unsigned mask)
+static void __maybe_unused xen_set_iopl_mask(unsigned mask)
 {
 	struct physdev_set_iopl set_iopl;
 
@@ -1279,7 +1279,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.write_idt_entry = xen_write_idt_entry,
 	.load_sp0 = xen_load_sp0,
 
-	.set_iopl_mask = xen_set_iopl_mask,
+	INIT_SET_IOPL_MASK(xen_set_iopl_mask)
 	.io_delay = xen_io_delay,
 
 	/* Xen takes care of %gs when switching to usermode for us */
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17: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 1Xkz13-0007LV-Ij; Sun, 02 Nov 2014 17:32:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz11-0007Kf-WC
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:36 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	51/08-22737-3BA66545; Sun, 02 Nov 2014 17:32:35 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-16.tower-206.messagelabs.com!1414949554!8973921!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21082 invoked from network); 2 Nov 2014 17:32:34 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Nov 2014 17:32:34 -0000
Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 8937B17208C;
	Sun,  2 Nov 2014 18:32:34 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter16-d.gandi.net (mfilter16-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id 4z-V+XFXOcl3; Sun,  2 Nov 2014 18:32:33 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id AF5A4172080;
	Sun,  2 Nov 2014 18:32:30 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:28 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <225193735620e87b14c5b34fda264c81b9f49a3f.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 05/10] x86: cpu: Add helper function unifying
 32-bit and 64-bit IO init in cpu_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

Previously, the 64-bit code initialized both the io_bitmap_base and
io_bitmap, while the 32-bit code only initialized io_bitmap_base.

Factor the initialization out into a helper function init_tss_io, and
call it from both versions of cpu_init.

This will also make it easier to make these IO-related fields optional
later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/include/asm/processor.h | 14 ++++++++++++++
 arch/x86/kernel/cpu/common.c     | 12 ++----------
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 0a12534..1fa78f7 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -286,6 +286,20 @@ struct tss_struct {
 
 DECLARE_PER_CPU_SHARED_ALIGNED(struct tss_struct, init_tss);
 
+static inline void init_tss_io(struct tss_struct *t)
+{
+	int i;
+
+	t->x86_tss.io_bitmap_base = offsetof(struct tss_struct, io_bitmap);
+
+	/*
+	 * <= is required because the CPU will access up to
+	 * 8 bits beyond the end of the IO permission bitmap.
+	 */
+	for (i = 0; i <= IO_BITMAP_LONGS; i++)
+		t->io_bitmap[i] = ~0UL;
+}
+
 /*
  * Save the original ist values for checking stack pointers during debugging
  */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 4b4f78c..ae2e8d7 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1297,7 +1297,6 @@ void cpu_init(void)
 	struct tss_struct *t;
 	unsigned long v;
 	int cpu = stack_smp_processor_id();
-	int i;
 
 	wait_for_master_cpu(cpu);
 
@@ -1357,14 +1356,7 @@ void cpu_init(void)
 		}
 	}
 
-	t->x86_tss.io_bitmap_base = offsetof(struct tss_struct, io_bitmap);
-
-	/*
-	 * <= is required because the CPU will access up to
-	 * 8 bits beyond the end of the IO permission bitmap.
-	 */
-	for (i = 0; i <= IO_BITMAP_LONGS; i++)
-		t->io_bitmap[i] = ~0UL;
+	init_tss_io(t);
 
 	atomic_inc(&init_mm.mm_count);
 	me->active_mm = &init_mm;
@@ -1419,7 +1411,7 @@ void cpu_init(void)
 	load_TR_desc();
 	load_LDT(&init_mm.context);
 
-	t->x86_tss.io_bitmap_base = offsetof(struct tss_struct, io_bitmap);
+	init_tss_io(t);
 
 #ifdef CONFIG_DOUBLEFAULT
 	/* Set up doublefault TSS pointer in the GDT */
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17: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 1Xkz13-0007LV-Ij; Sun, 02 Nov 2014 17:32:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz11-0007Kf-WC
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:36 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	51/08-22737-3BA66545; Sun, 02 Nov 2014 17:32:35 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-16.tower-206.messagelabs.com!1414949554!8973921!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21082 invoked from network); 2 Nov 2014 17:32:34 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Nov 2014 17:32:34 -0000
Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 8937B17208C;
	Sun,  2 Nov 2014 18:32:34 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter16-d.gandi.net (mfilter16-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id 4z-V+XFXOcl3; Sun,  2 Nov 2014 18:32:33 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id AF5A4172080;
	Sun,  2 Nov 2014 18:32:30 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:28 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <225193735620e87b14c5b34fda264c81b9f49a3f.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 05/10] x86: cpu: Add helper function unifying
 32-bit and 64-bit IO init in cpu_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

Previously, the 64-bit code initialized both the io_bitmap_base and
io_bitmap, while the 32-bit code only initialized io_bitmap_base.

Factor the initialization out into a helper function init_tss_io, and
call it from both versions of cpu_init.

This will also make it easier to make these IO-related fields optional
later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/include/asm/processor.h | 14 ++++++++++++++
 arch/x86/kernel/cpu/common.c     | 12 ++----------
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 0a12534..1fa78f7 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -286,6 +286,20 @@ struct tss_struct {
 
 DECLARE_PER_CPU_SHARED_ALIGNED(struct tss_struct, init_tss);
 
+static inline void init_tss_io(struct tss_struct *t)
+{
+	int i;
+
+	t->x86_tss.io_bitmap_base = offsetof(struct tss_struct, io_bitmap);
+
+	/*
+	 * <= is required because the CPU will access up to
+	 * 8 bits beyond the end of the IO permission bitmap.
+	 */
+	for (i = 0; i <= IO_BITMAP_LONGS; i++)
+		t->io_bitmap[i] = ~0UL;
+}
+
 /*
  * Save the original ist values for checking stack pointers during debugging
  */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 4b4f78c..ae2e8d7 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1297,7 +1297,6 @@ void cpu_init(void)
 	struct tss_struct *t;
 	unsigned long v;
 	int cpu = stack_smp_processor_id();
-	int i;
 
 	wait_for_master_cpu(cpu);
 
@@ -1357,14 +1356,7 @@ void cpu_init(void)
 		}
 	}
 
-	t->x86_tss.io_bitmap_base = offsetof(struct tss_struct, io_bitmap);
-
-	/*
-	 * <= is required because the CPU will access up to
-	 * 8 bits beyond the end of the IO permission bitmap.
-	 */
-	for (i = 0; i <= IO_BITMAP_LONGS; i++)
-		t->io_bitmap[i] = ~0UL;
+	init_tss_io(t);
 
 	atomic_inc(&init_mm.mm_count);
 	me->active_mm = &init_mm;
@@ -1419,7 +1411,7 @@ void cpu_init(void)
 	load_TR_desc();
 	load_LDT(&init_mm.context);
 
-	t->x86_tss.io_bitmap_base = offsetof(struct tss_struct, io_bitmap);
+	init_tss_io(t);
 
 #ifdef CONFIG_DOUBLEFAULT
 	/* Set up doublefault TSS pointer in the GDT */
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz1B-0007QC-9z; Sun, 02 Nov 2014 17:32:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz19-0007Ow-IX
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:43 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	B7/6D-02576-ABA66545; Sun, 02 Nov 2014 17:32:42 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1414949562!8727444!1
X-Originating-IP: [217.70.183.195]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTUgPT4gMzc4NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31197 invoked from network); 2 Nov 2014 17:32:42 -0000
Received: from relay3-d.mail.gandi.net (HELO relay3-d.mail.gandi.net)
	(217.70.183.195)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:42 -0000
Received: from mfilter39-d.gandi.net (mfilter39-d.gandi.net [217.70.178.170])
	by relay3-d.mail.gandi.net (Postfix) with ESMTP id 18F74A80BC;
	Sun,  2 Nov 2014 18:32:42 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter39-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
	by mfilter39-d.gandi.net (mfilter39-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id 2YMV7dwwEL1f; Sun,  2 Nov 2014 18:32:40 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id E1BEDA80AF;
	Sun,  2 Nov 2014 18:32:36 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:34 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <502c33cf56eed0a4cf98df1fe8ad665788d20284.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 06/10] x86: process: Introduce helper to
 clear a thread's IO bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will make it easier to make the io_bitmap_ptr field optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/kernel/process-io.h | 5 +++++
 arch/x86/kernel/process_32.c | 4 ++--
 arch/x86/kernel/process_64.c | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
index d884444..ffa65e8 100644
--- a/arch/x86/kernel/process-io.h
+++ b/arch/x86/kernel/process-io.h
@@ -1,6 +1,11 @@
 #ifndef _X86_KERNEL_PROCESS_IO_H
 #define _X86_KERNEL_PROCESS_IO_H
 
+static inline void clear_thread_io_bitmap(struct task_struct *p)
+{
+	p->thread.io_bitmap_ptr = NULL;
+}
+
 static inline int copy_io_bitmap(struct task_struct *me,
 				 struct task_struct *p)
 {
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 07550ff..b55f78e 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -154,7 +154,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 		childregs->orig_ax = -1;
 		childregs->cs = __KERNEL_CS | get_kernel_rpl();
 		childregs->flags = X86_EFLAGS_IF | X86_EFLAGS_FIXED;
-		p->thread.io_bitmap_ptr = NULL;
+		clear_thread_io_bitmap(p);
 		return 0;
 	}
 	*childregs = *current_pt_regs();
@@ -165,7 +165,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 	p->thread.ip = (unsigned long) ret_from_fork;
 	task_user_gs(p) = get_user_gs(current_pt_regs());
 
-	p->thread.io_bitmap_ptr = NULL;
+	clear_thread_io_bitmap(p);
 	tsk = current;
 
 	/*
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index b1babb4..d18f3fc 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -164,7 +164,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 	p->thread.sp = (unsigned long) childregs;
 	p->thread.usersp = me->thread.usersp;
 	set_tsk_thread_flag(p, TIF_FORK);
-	p->thread.io_bitmap_ptr = NULL;
+	clear_thread_io_bitmap(p);
 
 	savesegment(gs, p->thread.gsindex);
 	p->thread.gs = p->thread.gsindex ? 0 : me->thread.gs;
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz1B-0007QC-9z; Sun, 02 Nov 2014 17:32:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz19-0007Ow-IX
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:43 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	B7/6D-02576-ABA66545; Sun, 02 Nov 2014 17:32:42 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1414949562!8727444!1
X-Originating-IP: [217.70.183.195]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTUgPT4gMzc4NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31197 invoked from network); 2 Nov 2014 17:32:42 -0000
Received: from relay3-d.mail.gandi.net (HELO relay3-d.mail.gandi.net)
	(217.70.183.195)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:42 -0000
Received: from mfilter39-d.gandi.net (mfilter39-d.gandi.net [217.70.178.170])
	by relay3-d.mail.gandi.net (Postfix) with ESMTP id 18F74A80BC;
	Sun,  2 Nov 2014 18:32:42 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter39-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
	by mfilter39-d.gandi.net (mfilter39-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id 2YMV7dwwEL1f; Sun,  2 Nov 2014 18:32:40 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id E1BEDA80AF;
	Sun,  2 Nov 2014 18:32:36 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:34 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <502c33cf56eed0a4cf98df1fe8ad665788d20284.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 06/10] x86: process: Introduce helper to
 clear a thread's IO bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will make it easier to make the io_bitmap_ptr field optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/kernel/process-io.h | 5 +++++
 arch/x86/kernel/process_32.c | 4 ++--
 arch/x86/kernel/process_64.c | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
index d884444..ffa65e8 100644
--- a/arch/x86/kernel/process-io.h
+++ b/arch/x86/kernel/process-io.h
@@ -1,6 +1,11 @@
 #ifndef _X86_KERNEL_PROCESS_IO_H
 #define _X86_KERNEL_PROCESS_IO_H
 
+static inline void clear_thread_io_bitmap(struct task_struct *p)
+{
+	p->thread.io_bitmap_ptr = NULL;
+}
+
 static inline int copy_io_bitmap(struct task_struct *me,
 				 struct task_struct *p)
 {
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 07550ff..b55f78e 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -154,7 +154,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 		childregs->orig_ax = -1;
 		childregs->cs = __KERNEL_CS | get_kernel_rpl();
 		childregs->flags = X86_EFLAGS_IF | X86_EFLAGS_FIXED;
-		p->thread.io_bitmap_ptr = NULL;
+		clear_thread_io_bitmap(p);
 		return 0;
 	}
 	*childregs = *current_pt_regs();
@@ -165,7 +165,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 	p->thread.ip = (unsigned long) ret_from_fork;
 	task_user_gs(p) = get_user_gs(current_pt_regs());
 
-	p->thread.io_bitmap_ptr = NULL;
+	clear_thread_io_bitmap(p);
 	tsk = current;
 
 	/*
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index b1babb4..d18f3fc 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -164,7 +164,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
 	p->thread.sp = (unsigned long) childregs;
 	p->thread.usersp = me->thread.usersp;
 	set_tsk_thread_flag(p, TIF_FORK);
-	p->thread.io_bitmap_ptr = NULL;
+	clear_thread_io_bitmap(p);
 
 	savesegment(gs, p->thread.gsindex);
 	p->thread.gs = p->thread.gsindex ? 0 : me->thread.gs;
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz1G-0007Tr-O0; Sun, 02 Nov 2014 17:32:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz1F-0007T9-Uu
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:50 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	7A/FB-02984-1CA66545; Sun, 02 Nov 2014 17:32:49 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1414949568!8727451!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31598 invoked from network); 2 Nov 2014 17:32:48 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:48 -0000
Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 5850D172074;
	Sun,  2 Nov 2014 18:32:48 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter37-d.gandi.net (mfilter37-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id JX49a0kzWV5g; Sun,  2 Nov 2014 18:32:47 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 829A2172089;
	Sun,  2 Nov 2014 18:32:44 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:42 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <38733fd32dae1cbf8a3891773ff7ae0336f063de.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 07/10] x86: process: Introduce helper to
	switch iopl mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This simplifies __switch_to a bit, and will make it easier to make iopl
optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/kernel/process-io.h | 13 +++++++++++++
 arch/x86/kernel/process_32.c |  9 +--------
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
index ffa65e8..6d4f147 100644
--- a/arch/x86/kernel/process-io.h
+++ b/arch/x86/kernel/process-io.h
@@ -24,4 +24,17 @@ static inline int copy_io_bitmap(struct task_struct *me,
 	return 0;
 }
 
+static inline void switch_iopl_mask(struct thread_struct *prev,
+				    struct thread_struct *next)
+{
+        /*
+         * Restore IOPL if needed.  In normal use, the flags restore
+         * in the switch assembly will handle this.  But if the kernel
+         * is running virtualized at a non-zero CPL, the popf will
+         * not restore flags, so it must be done in a separate step.
+         */
+        if (get_kernel_rpl() && unlikely(prev->iopl != next->iopl))
+                set_iopl_mask(next->iopl);
+}
+
 #endif /* _X86_KERNEL_PROCESS_IO_H */
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index b55f78e..3b82293 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -265,14 +265,7 @@ __switch_to(struct task_struct *prev_p, struct task_struct *next_p)
 	 */
 	load_TLS(next, cpu);
 
-	/*
-	 * Restore IOPL if needed.  In normal use, the flags restore
-	 * in the switch assembly will handle this.  But if the kernel
-	 * is running virtualized at a non-zero CPL, the popf will
-	 * not restore flags, so it must be done in a separate step.
-	 */
-	if (get_kernel_rpl() && unlikely(prev->iopl != next->iopl))
-		set_iopl_mask(next->iopl);
+	switch_iopl_mask(prev, next);
 
 	/*
 	 * If it were not for PREEMPT_ACTIVE we could guarantee that the
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz1G-0007Tr-O0; Sun, 02 Nov 2014 17:32:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz1F-0007T9-Uu
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:50 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	7A/FB-02984-1CA66545; Sun, 02 Nov 2014 17:32:49 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1414949568!8727451!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gMzk1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31598 invoked from network); 2 Nov 2014 17:32:48 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:48 -0000
Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 5850D172074;
	Sun,  2 Nov 2014 18:32:48 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter37-d.gandi.net (mfilter37-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id JX49a0kzWV5g; Sun,  2 Nov 2014 18:32:47 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 829A2172089;
	Sun,  2 Nov 2014 18:32:44 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:42 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <38733fd32dae1cbf8a3891773ff7ae0336f063de.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 07/10] x86: process: Introduce helper to
	switch iopl mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This simplifies __switch_to a bit, and will make it easier to make iopl
optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/kernel/process-io.h | 13 +++++++++++++
 arch/x86/kernel/process_32.c |  9 +--------
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
index ffa65e8..6d4f147 100644
--- a/arch/x86/kernel/process-io.h
+++ b/arch/x86/kernel/process-io.h
@@ -24,4 +24,17 @@ static inline int copy_io_bitmap(struct task_struct *me,
 	return 0;
 }
 
+static inline void switch_iopl_mask(struct thread_struct *prev,
+				    struct thread_struct *next)
+{
+        /*
+         * Restore IOPL if needed.  In normal use, the flags restore
+         * in the switch assembly will handle this.  But if the kernel
+         * is running virtualized at a non-zero CPL, the popf will
+         * not restore flags, so it must be done in a separate step.
+         */
+        if (get_kernel_rpl() && unlikely(prev->iopl != next->iopl))
+                set_iopl_mask(next->iopl);
+}
+
 #endif /* _X86_KERNEL_PROCESS_IO_H */
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index b55f78e..3b82293 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -265,14 +265,7 @@ __switch_to(struct task_struct *prev_p, struct task_struct *next_p)
 	 */
 	load_TLS(next, cpu);
 
-	/*
-	 * Restore IOPL if needed.  In normal use, the flags restore
-	 * in the switch assembly will handle this.  But if the kernel
-	 * is running virtualized at a non-zero CPL, the popf will
-	 * not restore flags, so it must be done in a separate step.
-	 */
-	if (get_kernel_rpl() && unlikely(prev->iopl != next->iopl))
-		set_iopl_mask(next->iopl);
+	switch_iopl_mask(prev, next);
 
 	/*
 	 * If it were not for PREEMPT_ACTIVE we could guarantee that the
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz1P-0007Yv-5b; Sun, 02 Nov 2014 17:32:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz1N-0007Y8-K0
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	74/BE-09936-9CA66545; Sun, 02 Nov 2014 17:32:57 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1414949574!12182080!1
X-Originating-IP: [217.70.183.195]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTUgPT4gMzc4NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30201 invoked from network); 2 Nov 2014 17:32:54 -0000
Received: from relay3-d.mail.gandi.net (HELO relay3-d.mail.gandi.net)
	(217.70.183.195)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:54 -0000
Received: from mfilter34-d.gandi.net (mfilter34-d.gandi.net [217.70.178.165])
	by relay3-d.mail.gandi.net (Postfix) with ESMTP id 919A9A80AF;
	Sun,  2 Nov 2014 18:32:54 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter34-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
	by mfilter34-d.gandi.net (mfilter34-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id g9o6xlArn0FS; Sun,  2 Nov 2014 18:32:52 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 75900A80AD;
	Sun,  2 Nov 2014 18:32:50 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:48 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <0a47e59dec909be4e6b4fd7769e371a5fb14e3e4.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 08/10] x86: process: Introduce helper for
 IO-related bits of exit_thread
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This makes the two major functions of exit_thread (IO and FPU) more
obvious, and will make it easier to make IO optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/kernel/process-io.h | 20 ++++++++++++++++++++
 arch/x86/kernel/process.c    | 20 +++-----------------
 2 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
index 6d4f147..012c1d5 100644
--- a/arch/x86/kernel/process-io.h
+++ b/arch/x86/kernel/process-io.h
@@ -24,6 +24,26 @@ static inline int copy_io_bitmap(struct task_struct *me,
 	return 0;
 }
 
+static inline void exit_thread_io(struct task_struct *me)
+{
+        struct thread_struct *t = &me->thread;
+        unsigned long *bp = t->io_bitmap_ptr;
+
+        if (bp) {
+                struct tss_struct *tss = &per_cpu(init_tss, get_cpu());
+
+                t->io_bitmap_ptr = NULL;
+                clear_thread_flag(TIF_IO_BITMAP);
+                /*
+                 * Careful, clear this in the TSS too:
+                 */
+                memset(tss->io_bitmap, 0xff, t->io_bitmap_max);
+                t->io_bitmap_max = 0;
+                put_cpu();
+                kfree(bp);
+        }
+}
+
 static inline void switch_iopl_mask(struct thread_struct *prev,
 				    struct thread_struct *next)
 {
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index e127dda..37b45ca 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -29,6 +29,8 @@
 #include <asm/debugreg.h>
 #include <asm/nmi.h>
 
+#include "process-io.h"
+
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
  * no more per-task TSS's. The TSS size is kept cacheline-aligned
@@ -104,23 +106,7 @@ void arch_task_cache_init(void)
 void exit_thread(void)
 {
 	struct task_struct *me = current;
-	struct thread_struct *t = &me->thread;
-	unsigned long *bp = t->io_bitmap_ptr;
-
-	if (bp) {
-		struct tss_struct *tss = &per_cpu(init_tss, get_cpu());
-
-		t->io_bitmap_ptr = NULL;
-		clear_thread_flag(TIF_IO_BITMAP);
-		/*
-		 * Careful, clear this in the TSS too:
-		 */
-		memset(tss->io_bitmap, 0xff, t->io_bitmap_max);
-		t->io_bitmap_max = 0;
-		put_cpu();
-		kfree(bp);
-	}
-
+	exit_thread_io(me);
 	drop_fpu(me);
 }
 
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:32:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz1P-0007Yv-5b; Sun, 02 Nov 2014 17:32:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz1N-0007Y8-K0
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:32:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	74/BE-09936-9CA66545; Sun, 02 Nov 2014 17:32:57 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1414949574!12182080!1
X-Originating-IP: [217.70.183.195]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTUgPT4gMzc4NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30201 invoked from network); 2 Nov 2014 17:32:54 -0000
Received: from relay3-d.mail.gandi.net (HELO relay3-d.mail.gandi.net)
	(217.70.183.195)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:32:54 -0000
Received: from mfilter34-d.gandi.net (mfilter34-d.gandi.net [217.70.178.165])
	by relay3-d.mail.gandi.net (Postfix) with ESMTP id 919A9A80AF;
	Sun,  2 Nov 2014 18:32:54 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter34-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
	by mfilter34-d.gandi.net (mfilter34-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id g9o6xlArn0FS; Sun,  2 Nov 2014 18:32:52 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 75900A80AD;
	Sun,  2 Nov 2014 18:32:50 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:48 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <0a47e59dec909be4e6b4fd7769e371a5fb14e3e4.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 08/10] x86: process: Introduce helper for
 IO-related bits of exit_thread
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This makes the two major functions of exit_thread (IO and FPU) more
obvious, and will make it easier to make IO optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/kernel/process-io.h | 20 ++++++++++++++++++++
 arch/x86/kernel/process.c    | 20 +++-----------------
 2 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
index 6d4f147..012c1d5 100644
--- a/arch/x86/kernel/process-io.h
+++ b/arch/x86/kernel/process-io.h
@@ -24,6 +24,26 @@ static inline int copy_io_bitmap(struct task_struct *me,
 	return 0;
 }
 
+static inline void exit_thread_io(struct task_struct *me)
+{
+        struct thread_struct *t = &me->thread;
+        unsigned long *bp = t->io_bitmap_ptr;
+
+        if (bp) {
+                struct tss_struct *tss = &per_cpu(init_tss, get_cpu());
+
+                t->io_bitmap_ptr = NULL;
+                clear_thread_flag(TIF_IO_BITMAP);
+                /*
+                 * Careful, clear this in the TSS too:
+                 */
+                memset(tss->io_bitmap, 0xff, t->io_bitmap_max);
+                t->io_bitmap_max = 0;
+                put_cpu();
+                kfree(bp);
+        }
+}
+
 static inline void switch_iopl_mask(struct thread_struct *prev,
 				    struct thread_struct *next)
 {
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index e127dda..37b45ca 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -29,6 +29,8 @@
 #include <asm/debugreg.h>
 #include <asm/nmi.h>
 
+#include "process-io.h"
+
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
  * no more per-task TSS's. The TSS size is kept cacheline-aligned
@@ -104,23 +106,7 @@ void arch_task_cache_init(void)
 void exit_thread(void)
 {
 	struct task_struct *me = current;
-	struct thread_struct *t = &me->thread;
-	unsigned long *bp = t->io_bitmap_ptr;
-
-	if (bp) {
-		struct tss_struct *tss = &per_cpu(init_tss, get_cpu());
-
-		t->io_bitmap_ptr = NULL;
-		clear_thread_flag(TIF_IO_BITMAP);
-		/*
-		 * Careful, clear this in the TSS too:
-		 */
-		memset(tss->io_bitmap, 0xff, t->io_bitmap_max);
-		t->io_bitmap_max = 0;
-		put_cpu();
-		kfree(bp);
-	}
-
+	exit_thread_io(me);
 	drop_fpu(me);
 }
 
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:33:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz1T-0007bz-L0; Sun, 02 Nov 2014 17:33:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz1S-0007ae-0a
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:33:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CB/14-24532-DCA66545; Sun, 02 Nov 2014 17:33:01 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1414949580!12246700!1
X-Originating-IP: [217.70.183.198]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21676 invoked from network); 2 Nov 2014 17:33:01 -0000
Received: from relay6-d.mail.gandi.net (HELO relay6-d.mail.gandi.net)
	(217.70.183.198)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:33:01 -0000
Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167])
	by relay6-d.mail.gandi.net (Postfix) with ESMTP id D1694FB8A1;
	Sun,  2 Nov 2014 18:33:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net
Received: from relay6-d.mail.gandi.net ([217.70.183.198])
	by mfilter36-d.gandi.net (mfilter36-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id G9m8ARn+SJly; Sun,  2 Nov 2014 18:32:59 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id C7965FB86B;
	Sun,  2 Nov 2014 18:32:56 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:55 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <7da73a194a9856de21cf9cf035be29239ce88ef3.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 09/10] x86: process: Introduce helper to
	switch IO bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This simplifies __switch_to_xtra, and will make it easier to make IO
optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/kernel/process-io.h | 23 +++++++++++++++++++++++
 arch/x86/kernel/process.c    | 14 +-------------
 2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
index 012c1d5..e48d5c9 100644
--- a/arch/x86/kernel/process-io.h
+++ b/arch/x86/kernel/process-io.h
@@ -57,4 +57,27 @@ static inline void switch_iopl_mask(struct thread_struct *prev,
                 set_iopl_mask(next->iopl);
 }
 
+static inline void switch_io_bitmap(struct tss_struct *tss,
+				    struct task_struct *prev_p,
+				    struct task_struct *next_p)
+{
+        struct thread_struct *prev, *next;
+        prev = &prev_p->thread;
+        next = &next_p->thread;
+
+        if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) {
+                /*
+                 * Copy the relevant range of the IO bitmap.
+                 * Normally this is 128 bytes or less:
+                 */
+                memcpy(tss->io_bitmap, next->io_bitmap_ptr,
+                       max(prev->io_bitmap_max, next->io_bitmap_max));
+        } else if (test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) {
+                /*
+                 * Clear any possible leftover bits:
+                 */
+                memset(tss->io_bitmap, 0xff, prev->io_bitmap_max);
+        }
+}
+
 #endif /* _X86_KERNEL_PROCESS_IO_H */
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 37b45ca..7ac01bf 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -211,19 +211,7 @@ void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
 			hard_enable_TSC();
 	}
 
-	if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) {
-		/*
-		 * Copy the relevant range of the IO bitmap.
-		 * Normally this is 128 bytes or less:
-		 */
-		memcpy(tss->io_bitmap, next->io_bitmap_ptr,
-		       max(prev->io_bitmap_max, next->io_bitmap_max));
-	} else if (test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) {
-		/*
-		 * Clear any possible leftover bits:
-		 */
-		memset(tss->io_bitmap, 0xff, prev->io_bitmap_max);
-	}
+	switch_io_bitmap(tss, prev_p, next_p);
 	propagate_user_return_notify(prev_p, next_p);
 }
 
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:33:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz1T-0007bz-L0; Sun, 02 Nov 2014 17:33:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz1S-0007ae-0a
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:33:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CB/14-24532-DCA66545; Sun, 02 Nov 2014 17:33:01 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1414949580!12246700!1
X-Originating-IP: [217.70.183.198]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21676 invoked from network); 2 Nov 2014 17:33:01 -0000
Received: from relay6-d.mail.gandi.net (HELO relay6-d.mail.gandi.net)
	(217.70.183.198)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:33:01 -0000
Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167])
	by relay6-d.mail.gandi.net (Postfix) with ESMTP id D1694FB8A1;
	Sun,  2 Nov 2014 18:33:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net
Received: from relay6-d.mail.gandi.net ([217.70.183.198])
	by mfilter36-d.gandi.net (mfilter36-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id G9m8ARn+SJly; Sun,  2 Nov 2014 18:32:59 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id C7965FB86B;
	Sun,  2 Nov 2014 18:32:56 +0100 (CET)
Date: Sun, 2 Nov 2014 09:32:55 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <7da73a194a9856de21cf9cf035be29239ce88ef3.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 09/10] x86: process: Introduce helper to
	switch IO bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This simplifies __switch_to_xtra, and will make it easier to make IO
optional later.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/kernel/process-io.h | 23 +++++++++++++++++++++++
 arch/x86/kernel/process.c    | 14 +-------------
 2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
index 012c1d5..e48d5c9 100644
--- a/arch/x86/kernel/process-io.h
+++ b/arch/x86/kernel/process-io.h
@@ -57,4 +57,27 @@ static inline void switch_iopl_mask(struct thread_struct *prev,
                 set_iopl_mask(next->iopl);
 }
 
+static inline void switch_io_bitmap(struct tss_struct *tss,
+				    struct task_struct *prev_p,
+				    struct task_struct *next_p)
+{
+        struct thread_struct *prev, *next;
+        prev = &prev_p->thread;
+        next = &next_p->thread;
+
+        if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) {
+                /*
+                 * Copy the relevant range of the IO bitmap.
+                 * Normally this is 128 bytes or less:
+                 */
+                memcpy(tss->io_bitmap, next->io_bitmap_ptr,
+                       max(prev->io_bitmap_max, next->io_bitmap_max));
+        } else if (test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) {
+                /*
+                 * Clear any possible leftover bits:
+                 */
+                memset(tss->io_bitmap, 0xff, prev->io_bitmap_max);
+        }
+}
+
 #endif /* _X86_KERNEL_PROCESS_IO_H */
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 37b45ca..7ac01bf 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -211,19 +211,7 @@ void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
 			hard_enable_TSC();
 	}
 
-	if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) {
-		/*
-		 * Copy the relevant range of the IO bitmap.
-		 * Normally this is 128 bytes or less:
-		 */
-		memcpy(tss->io_bitmap, next->io_bitmap_ptr,
-		       max(prev->io_bitmap_max, next->io_bitmap_max));
-	} else if (test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) {
-		/*
-		 * Clear any possible leftover bits:
-		 */
-		memset(tss->io_bitmap, 0xff, prev->io_bitmap_max);
-	}
+	switch_io_bitmap(tss, prev_p, next_p);
 	propagate_user_return_notify(prev_p, next_p);
 }
 
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:33:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz1a-0007gN-4g; Sun, 02 Nov 2014 17:33:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz1Z-0007fO-2o
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:33:09 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	D8/91-27785-4DA66545; Sun, 02 Nov 2014 17:33:08 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1414949587!12052627!1
X-Originating-IP: [217.70.183.195]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTUgPT4gMzc4NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6941 invoked from network); 2 Nov 2014 17:33:07 -0000
Received: from relay3-d.mail.gandi.net (HELO relay3-d.mail.gandi.net)
	(217.70.183.195)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:33:07 -0000
Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167])
	by relay3-d.mail.gandi.net (Postfix) with ESMTP id A8BE7A80B6;
	Sun,  2 Nov 2014 18:33:07 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
	by mfilter36-d.gandi.net (mfilter36-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id 5h6q62ZopkKn; Sun,  2 Nov 2014 18:33:05 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 74286A80B1;
	Sun,  2 Nov 2014 18:33:03 +0100 (CET)
Date: Sun, 2 Nov 2014 09:33:01 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <ec10c497d3a7f44f335dbc267edd6de5b4acd671.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 10/10] x86: Support compiling out userspace
 IO (iopl and ioperm)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On the vast majority of modern systems, no processes will use the
userspsace IO syscalls, iopl and ioperm.  Add a new config option,
CONFIG_X86_IOPORT, to support configuring them out of the kernel
entirely.  Most current systems do not run programs using these
syscalls, so X86_IOPORT does not depend on EXPERT, though it does still
default to y.

In addition to saving a significant amount of space, this also reduces
the size of several major kernel data structures, drops a bit of code
from several task-related hot paths, and reduces the attack surface of
the kernel.

bloat-o-meter results:

add/remove: 0/4 grow/shrink: 4/9 up/down: 83/-9074 (-8991)
function                                     old     new   delta
drop_fpu                                      80     160     +80
perf_event_init_task                         638     639      +1
perf_event_exec                              192     193      +1
perf_event_aux                               132     133      +1
test_tsk_thread_flag                          10       -     -10
ioperm_active                                 14       3     -11
init_task                                    916     904     -12
flush_thread                                 168     149     -19
cpu_init                                     364     339     -25
__drop_fpu                                    60       -     -60
ioperm_get                                    92       6     -86
exit_thread                                  105      10     -95
sys_iopl                                     106       -    -106
copy_thread                                  364     257    -107
__switch_to_xtra                             234     123    -111
sys_ioperm                                   240       -    -240
init_tss                                    8576     384   -8192

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/Kconfig                      | 10 ++++++++++
 arch/x86/include/asm/paravirt.h       |  2 ++
 arch/x86/include/asm/paravirt_types.h |  4 ++++
 arch/x86/include/asm/processor.h      | 19 ++++++++++++++++++-
 arch/x86/include/asm/syscalls.h       |  3 +++
 arch/x86/kernel/Makefile              |  3 ++-
 arch/x86/kernel/entry_64.S            |  9 ++++++---
 arch/x86/kernel/process-io.h          | 10 ++++++++++
 arch/x86/kernel/ptrace.c              |  8 ++++++++
 drivers/tty/vt/vt_ioctl.c             |  2 +-
 kernel/sys_ni.c                       |  5 +++++
 11 files changed, 69 insertions(+), 6 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f2327e8..a7de2eb 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -984,6 +984,16 @@ config X86_ESPFIX64
 	def_bool y
 	depends on X86_16BIT && X86_64
 
+config X86_IOPORT
+	bool "iopl and ioperm system calls"
+	default y
+	---help---
+	  This option enables the iopl and ioperm system calls, which allow
+	  privileged userspace processes to directly access I/O ports. This
+	  is used by software that drives hardware directly from userspace
+	  without using a kernel driver. Unless you intend to run such
+	  software, you can safely say N here.
+
 config TOSHIBA
 	tristate "Toshiba Laptop support"
 	depends on X86_32
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index cd6e161..52d2ec8 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -299,10 +299,12 @@ static inline void write_idt_entry(gate_desc *dt, int entry, const gate_desc *g)
 {
 	PVOP_VCALL3(pv_cpu_ops.write_idt_entry, dt, entry, g);
 }
+#ifdef CONFIG_X86_IOPORT
 static inline void set_iopl_mask(unsigned mask)
 {
 	PVOP_VCALL1(pv_cpu_ops.set_iopl_mask, mask);
 }
+#endif /* CONFIG_X86_IOPORT */
 
 /* The paravirtualized I/O functions */
 static inline void slow_down_io(void)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 3caf2a8..a22a5d4 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -142,8 +142,12 @@ struct pv_cpu_ops {
 
 	void (*load_sp0)(struct tss_struct *tss, struct thread_struct *t);
 
+#ifdef CONFIG_X86_IOPORT
 	void (*set_iopl_mask)(unsigned mask);
 #define INIT_SET_IOPL_MASK(f) .set_iopl_mask = f,
+#else
+#define INIT_SET_IOPL_MASK(f)
+#endif
 
 	void (*wbinvd)(void);
 	void (*io_delay)(void);
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 1fa78f7..6e0b639 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -255,7 +255,11 @@ struct x86_hw_tss {
 /*
  * IO-bitmap sizes:
  */
+#ifdef CONFIG_X86_IOPORT
 #define IO_BITMAP_BITS			65536
+#else
+#define IO_BITMAP_BITS			0
+#endif
 #define IO_BITMAP_BYTES			(IO_BITMAP_BITS/8)
 #define IO_BITMAP_LONGS			(IO_BITMAP_BYTES/sizeof(long))
 #define INVALID_IO_BITMAP_OFFSET	0x8000
@@ -269,6 +273,7 @@ struct tss_struct {
 	 */
 	struct x86_hw_tss	x86_tss;
 
+#ifdef CONFIG_X86_IOPORT
 	/*
 	 * The extra 1 is there because the CPU will access an
 	 * additional byte beyond the end of the IO permission
@@ -276,6 +281,7 @@ struct tss_struct {
 	 * be within the limit.
 	 */
 	unsigned long		io_bitmap[IO_BITMAP_LONGS + 1];
+#endif /* CONFIG_X86_IOPORT */
 
 	/*
 	 * .. and then another 0x100 bytes for the emergency kernel stack:
@@ -288,6 +294,7 @@ DECLARE_PER_CPU_SHARED_ALIGNED(struct tss_struct, init_tss);
 
 static inline void init_tss_io(struct tss_struct *t)
 {
+#ifdef CONFIG_X86_IOPORT
 	int i;
 
 	t->x86_tss.io_bitmap_base = offsetof(struct tss_struct, io_bitmap);
@@ -298,6 +305,9 @@ static inline void init_tss_io(struct tss_struct *t)
 	 */
 	for (i = 0; i <= IO_BITMAP_LONGS; i++)
 		t->io_bitmap[i] = ~0UL;
+#else
+	t->x86_tss.io_bitmap_base = INVALID_IO_BITMAP_OFFSET;
+#endif
 }
 
 /*
@@ -524,11 +534,13 @@ struct thread_struct {
 	unsigned int		saved_fs;
 	unsigned int		saved_gs;
 #endif
+#ifdef CONFIG_X86_IOPORT
 	/* IO permissions: */
 	unsigned long		*io_bitmap_ptr;
 	unsigned long		iopl;
 	/* Max allowed port in the bitmap, in bytes: */
 	unsigned		io_bitmap_max;
+#endif /* CONFIG_X86_IOPORT */
 	/*
 	 * fpu_counter contains the number of consecutive context switches
 	 * that the FPU is used. If this is over a threshold, the lazy fpu
@@ -545,7 +557,7 @@ struct thread_struct {
  */
 static inline void native_set_iopl_mask(unsigned mask)
 {
-#ifdef CONFIG_X86_32
+#if defined(CONFIG_X86_IOPORT) && defined(CONFIG_X86_32)
 	unsigned int reg;
 
 	asm volatile ("pushfl;"
@@ -856,6 +868,7 @@ static inline void spin_lock_prefetch(const void *x)
 #define STACK_TOP		TASK_SIZE
 #define STACK_TOP_MAX		STACK_TOP
 
+#ifdef CONFIG_X86_IOPORT
 #define INIT_THREAD_IO .io_bitmap_ptr = NULL,
 
 /*
@@ -865,6 +878,10 @@ static inline void spin_lock_prefetch(const void *x)
  * be within the limit.
  */
 #define INIT_TSS_IO .io_bitmap = { [0 ... IO_BITMAP_LONGS] = ~0 },
+#else
+#define INIT_THREAD_IO
+#define INIT_TSS_IO
+#endif
 
 #define INIT_THREAD  {							  \
 	.sp0			= sizeof(init_stack) + (long)&init_stack, \
diff --git a/arch/x86/include/asm/syscalls.h b/arch/x86/include/asm/syscalls.h
index 592a6a6..4db79ea 100644
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -16,9 +16,12 @@
 #include <linux/types.h>
 
 /* Common in X86_32 and X86_64 */
+
+#ifdef CONFIG_X86_IOPORT
 /* kernel/ioport.c */
 asmlinkage long sys_ioperm(unsigned long, unsigned long, int);
 asmlinkage long sys_iopl(unsigned int);
+#endif /* CONFIG_X86_IOPORT */
 
 /* kernel/ldt.c */
 asmlinkage int sys_modify_ldt(int, void __user *, unsigned long);
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 8f1e774..84d5fbe 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -20,7 +20,8 @@ CFLAGS_irq.o := -I$(src)/../include/asm/trace
 
 obj-y			:= process_$(BITS).o signal.o entry_$(BITS).o
 obj-y			+= traps.o irq.o irq_$(BITS).o dumpstack_$(BITS).o
-obj-y			+= time.o ioport.o ldt.o dumpstack.o nmi.o
+obj-y			+= time.o ldt.o dumpstack.o nmi.o
+obj-$(CONFIG_X86_IOPORT) += ioport.o
 obj-y			+= setup.o x86_init.o i8259.o irqinit.o jump_label.o
 obj-$(CONFIG_IRQ_WORK)  += irq_work.o
 obj-y			+= probe_roms.o
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index df088bb..1e6a74e0 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -609,6 +609,11 @@ ENTRY(stub_\func)
 END(stub_\func)
 	.endm
 
+	FORK_LIKE  clone
+	FORK_LIKE  fork
+	FORK_LIKE  vfork
+
+#ifdef CONFIG_X86_IOPORT
 	.macro FIXED_FRAME label,func
 ENTRY(\label)
 	CFI_STARTPROC
@@ -621,10 +626,8 @@ ENTRY(\label)
 END(\label)
 	.endm
 
-	FORK_LIKE  clone
-	FORK_LIKE  fork
-	FORK_LIKE  vfork
 	FIXED_FRAME stub_iopl, sys_iopl
+#endif /* CONFIG_X86_IOPORT */
 
 ENTRY(ptregscall_common)
 	DEFAULT_FRAME 1 8	/* offset 8: return address */
diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
index e48d5c9..3e773fa 100644
--- a/arch/x86/kernel/process-io.h
+++ b/arch/x86/kernel/process-io.h
@@ -3,12 +3,15 @@
 
 static inline void clear_thread_io_bitmap(struct task_struct *p)
 {
+#ifdef CONFIG_X86_IOPORT
 	p->thread.io_bitmap_ptr = NULL;
+#endif /* CONFIG_X86_IOPORT */
 }
 
 static inline int copy_io_bitmap(struct task_struct *me,
 				 struct task_struct *p)
 {
+#ifdef CONFIG_X86_IOPORT
 	if (unlikely(test_tsk_thread_flag(me, TIF_IO_BITMAP))) {
 		p->thread.io_bitmap_ptr = kmemdup(me->thread.io_bitmap_ptr,
 						  IO_BITMAP_BYTES, GFP_KERNEL);
@@ -20,12 +23,14 @@ static inline int copy_io_bitmap(struct task_struct *me,
 	} else {
 		p->thread.io_bitmap_ptr = NULL;
 	}
+#endif /* CONFIG_X86_IOPORT */
 
 	return 0;
 }
 
 static inline void exit_thread_io(struct task_struct *me)
 {
+#ifdef CONFIG_X86_IOPORT
         struct thread_struct *t = &me->thread;
         unsigned long *bp = t->io_bitmap_ptr;
 
@@ -42,11 +47,13 @@ static inline void exit_thread_io(struct task_struct *me)
                 put_cpu();
                 kfree(bp);
         }
+#endif /* CONFIG_X86_IOPORT */
 }
 
 static inline void switch_iopl_mask(struct thread_struct *prev,
 				    struct thread_struct *next)
 {
+#ifdef CONFIG_X86_IOPORT
         /*
          * Restore IOPL if needed.  In normal use, the flags restore
          * in the switch assembly will handle this.  But if the kernel
@@ -55,12 +62,14 @@ static inline void switch_iopl_mask(struct thread_struct *prev,
          */
         if (get_kernel_rpl() && unlikely(prev->iopl != next->iopl))
                 set_iopl_mask(next->iopl);
+#endif /* CONFIG_X86_IOPORT */
 }
 
 static inline void switch_io_bitmap(struct tss_struct *tss,
 				    struct task_struct *prev_p,
 				    struct task_struct *next_p)
 {
+#ifdef CONFIG_X86_IOPORT
         struct thread_struct *prev, *next;
         prev = &prev_p->thread;
         next = &next_p->thread;
@@ -78,6 +87,7 @@ static inline void switch_io_bitmap(struct tss_struct *tss,
                  */
                 memset(tss->io_bitmap, 0xff, prev->io_bitmap_max);
         }
+#endif /* CONFIG_X86_IOPORT */
 }
 
 #endif /* _X86_KERNEL_PROCESS_IO_H */
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 749b0e4..fdb74a8 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -785,7 +785,11 @@ static int ptrace_set_debugreg(struct task_struct *tsk, int n,
 static int ioperm_active(struct task_struct *target,
 			 const struct user_regset *regset)
 {
+#ifdef CONFIG_X86_IOPORT
 	return target->thread.io_bitmap_max / regset->size;
+#else
+	return 0;
+#endif
 }
 
 static int ioperm_get(struct task_struct *target,
@@ -793,12 +797,16 @@ static int ioperm_get(struct task_struct *target,
 		      unsigned int pos, unsigned int count,
 		      void *kbuf, void __user *ubuf)
 {
+#ifdef CONFIG_X86_IOPORT
 	if (!target->thread.io_bitmap_ptr)
 		return -ENXIO;
 
 	return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
 				   target->thread.io_bitmap_ptr,
 				   0, IO_BITMAP_BYTES);
+#else
+	return -ENXIO;
+#endif
 }
 
 /*
diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c
index 2bd78e2..7c7d405 100644
--- a/drivers/tty/vt/vt_ioctl.c
+++ b/drivers/tty/vt/vt_ioctl.c
@@ -410,7 +410,7 @@ int vt_ioctl(struct tty_struct *tty,
 		 *
 		 * XXX: you should never use these, just call ioperm directly..
 		 */
-#ifdef CONFIG_X86
+#ifdef CONFIG_X86_IOPORT
 	case KDADDIO:
 	case KDDELIO:
 		/*
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 02aa418..f3014fe 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -224,3 +224,8 @@ cond_syscall(sys_seccomp);
 
 /* access BPF programs and maps */
 cond_syscall(sys_bpf);
+
+/* userspace I/O port access */
+cond_syscall(stub_iopl);
+cond_syscall(sys_iopl);
+cond_syscall(sys_ioperm);
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:33:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xkz1a-0007gN-4g; Sun, 02 Nov 2014 17:33:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xkz1Z-0007fO-2o
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 17:33:09 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	D8/91-27785-4DA66545; Sun, 02 Nov 2014 17:33:08 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1414949587!12052627!1
X-Originating-IP: [217.70.183.195]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTUgPT4gMzc4NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6941 invoked from network); 2 Nov 2014 17:33:07 -0000
Received: from relay3-d.mail.gandi.net (HELO relay3-d.mail.gandi.net)
	(217.70.183.195)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 17:33:07 -0000
Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167])
	by relay3-d.mail.gandi.net (Postfix) with ESMTP id A8BE7A80B6;
	Sun,  2 Nov 2014 18:33:07 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
	by mfilter36-d.gandi.net (mfilter36-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id 5h6q62ZopkKn; Sun,  2 Nov 2014 18:33:05 +0100 (CET)
X-Originating-IP: 50.43.41.112
Received: from thin (static-50-43-41-112.bvtn.or.frontiernet.net
	[50.43.41.112]) (Authenticated sender: josh@joshtriplett.org)
	by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 74286A80B1;
	Sun,  2 Nov 2014 18:33:03 +0100 (CET)
Date: Sun, 2 Nov 2014 09:33:01 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, x86@kernel.org,
	xen-devel@lists.xenproject.org
Message-ID: <ec10c497d3a7f44f335dbc267edd6de5b4acd671.1414870871.git.josh@joshtriplett.org>
References: <cover.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cover.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [Xen-devel] [PATCH v4 10/10] x86: Support compiling out userspace
 IO (iopl and ioperm)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On the vast majority of modern systems, no processes will use the
userspsace IO syscalls, iopl and ioperm.  Add a new config option,
CONFIG_X86_IOPORT, to support configuring them out of the kernel
entirely.  Most current systems do not run programs using these
syscalls, so X86_IOPORT does not depend on EXPERT, though it does still
default to y.

In addition to saving a significant amount of space, this also reduces
the size of several major kernel data structures, drops a bit of code
from several task-related hot paths, and reduces the attack surface of
the kernel.

bloat-o-meter results:

add/remove: 0/4 grow/shrink: 4/9 up/down: 83/-9074 (-8991)
function                                     old     new   delta
drop_fpu                                      80     160     +80
perf_event_init_task                         638     639      +1
perf_event_exec                              192     193      +1
perf_event_aux                               132     133      +1
test_tsk_thread_flag                          10       -     -10
ioperm_active                                 14       3     -11
init_task                                    916     904     -12
flush_thread                                 168     149     -19
cpu_init                                     364     339     -25
__drop_fpu                                    60       -     -60
ioperm_get                                    92       6     -86
exit_thread                                  105      10     -95
sys_iopl                                     106       -    -106
copy_thread                                  364     257    -107
__switch_to_xtra                             234     123    -111
sys_ioperm                                   240       -    -240
init_tss                                    8576     384   -8192

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 arch/x86/Kconfig                      | 10 ++++++++++
 arch/x86/include/asm/paravirt.h       |  2 ++
 arch/x86/include/asm/paravirt_types.h |  4 ++++
 arch/x86/include/asm/processor.h      | 19 ++++++++++++++++++-
 arch/x86/include/asm/syscalls.h       |  3 +++
 arch/x86/kernel/Makefile              |  3 ++-
 arch/x86/kernel/entry_64.S            |  9 ++++++---
 arch/x86/kernel/process-io.h          | 10 ++++++++++
 arch/x86/kernel/ptrace.c              |  8 ++++++++
 drivers/tty/vt/vt_ioctl.c             |  2 +-
 kernel/sys_ni.c                       |  5 +++++
 11 files changed, 69 insertions(+), 6 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f2327e8..a7de2eb 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -984,6 +984,16 @@ config X86_ESPFIX64
 	def_bool y
 	depends on X86_16BIT && X86_64
 
+config X86_IOPORT
+	bool "iopl and ioperm system calls"
+	default y
+	---help---
+	  This option enables the iopl and ioperm system calls, which allow
+	  privileged userspace processes to directly access I/O ports. This
+	  is used by software that drives hardware directly from userspace
+	  without using a kernel driver. Unless you intend to run such
+	  software, you can safely say N here.
+
 config TOSHIBA
 	tristate "Toshiba Laptop support"
 	depends on X86_32
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index cd6e161..52d2ec8 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -299,10 +299,12 @@ static inline void write_idt_entry(gate_desc *dt, int entry, const gate_desc *g)
 {
 	PVOP_VCALL3(pv_cpu_ops.write_idt_entry, dt, entry, g);
 }
+#ifdef CONFIG_X86_IOPORT
 static inline void set_iopl_mask(unsigned mask)
 {
 	PVOP_VCALL1(pv_cpu_ops.set_iopl_mask, mask);
 }
+#endif /* CONFIG_X86_IOPORT */
 
 /* The paravirtualized I/O functions */
 static inline void slow_down_io(void)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 3caf2a8..a22a5d4 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -142,8 +142,12 @@ struct pv_cpu_ops {
 
 	void (*load_sp0)(struct tss_struct *tss, struct thread_struct *t);
 
+#ifdef CONFIG_X86_IOPORT
 	void (*set_iopl_mask)(unsigned mask);
 #define INIT_SET_IOPL_MASK(f) .set_iopl_mask = f,
+#else
+#define INIT_SET_IOPL_MASK(f)
+#endif
 
 	void (*wbinvd)(void);
 	void (*io_delay)(void);
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 1fa78f7..6e0b639 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -255,7 +255,11 @@ struct x86_hw_tss {
 /*
  * IO-bitmap sizes:
  */
+#ifdef CONFIG_X86_IOPORT
 #define IO_BITMAP_BITS			65536
+#else
+#define IO_BITMAP_BITS			0
+#endif
 #define IO_BITMAP_BYTES			(IO_BITMAP_BITS/8)
 #define IO_BITMAP_LONGS			(IO_BITMAP_BYTES/sizeof(long))
 #define INVALID_IO_BITMAP_OFFSET	0x8000
@@ -269,6 +273,7 @@ struct tss_struct {
 	 */
 	struct x86_hw_tss	x86_tss;
 
+#ifdef CONFIG_X86_IOPORT
 	/*
 	 * The extra 1 is there because the CPU will access an
 	 * additional byte beyond the end of the IO permission
@@ -276,6 +281,7 @@ struct tss_struct {
 	 * be within the limit.
 	 */
 	unsigned long		io_bitmap[IO_BITMAP_LONGS + 1];
+#endif /* CONFIG_X86_IOPORT */
 
 	/*
 	 * .. and then another 0x100 bytes for the emergency kernel stack:
@@ -288,6 +294,7 @@ DECLARE_PER_CPU_SHARED_ALIGNED(struct tss_struct, init_tss);
 
 static inline void init_tss_io(struct tss_struct *t)
 {
+#ifdef CONFIG_X86_IOPORT
 	int i;
 
 	t->x86_tss.io_bitmap_base = offsetof(struct tss_struct, io_bitmap);
@@ -298,6 +305,9 @@ static inline void init_tss_io(struct tss_struct *t)
 	 */
 	for (i = 0; i <= IO_BITMAP_LONGS; i++)
 		t->io_bitmap[i] = ~0UL;
+#else
+	t->x86_tss.io_bitmap_base = INVALID_IO_BITMAP_OFFSET;
+#endif
 }
 
 /*
@@ -524,11 +534,13 @@ struct thread_struct {
 	unsigned int		saved_fs;
 	unsigned int		saved_gs;
 #endif
+#ifdef CONFIG_X86_IOPORT
 	/* IO permissions: */
 	unsigned long		*io_bitmap_ptr;
 	unsigned long		iopl;
 	/* Max allowed port in the bitmap, in bytes: */
 	unsigned		io_bitmap_max;
+#endif /* CONFIG_X86_IOPORT */
 	/*
 	 * fpu_counter contains the number of consecutive context switches
 	 * that the FPU is used. If this is over a threshold, the lazy fpu
@@ -545,7 +557,7 @@ struct thread_struct {
  */
 static inline void native_set_iopl_mask(unsigned mask)
 {
-#ifdef CONFIG_X86_32
+#if defined(CONFIG_X86_IOPORT) && defined(CONFIG_X86_32)
 	unsigned int reg;
 
 	asm volatile ("pushfl;"
@@ -856,6 +868,7 @@ static inline void spin_lock_prefetch(const void *x)
 #define STACK_TOP		TASK_SIZE
 #define STACK_TOP_MAX		STACK_TOP
 
+#ifdef CONFIG_X86_IOPORT
 #define INIT_THREAD_IO .io_bitmap_ptr = NULL,
 
 /*
@@ -865,6 +878,10 @@ static inline void spin_lock_prefetch(const void *x)
  * be within the limit.
  */
 #define INIT_TSS_IO .io_bitmap = { [0 ... IO_BITMAP_LONGS] = ~0 },
+#else
+#define INIT_THREAD_IO
+#define INIT_TSS_IO
+#endif
 
 #define INIT_THREAD  {							  \
 	.sp0			= sizeof(init_stack) + (long)&init_stack, \
diff --git a/arch/x86/include/asm/syscalls.h b/arch/x86/include/asm/syscalls.h
index 592a6a6..4db79ea 100644
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -16,9 +16,12 @@
 #include <linux/types.h>
 
 /* Common in X86_32 and X86_64 */
+
+#ifdef CONFIG_X86_IOPORT
 /* kernel/ioport.c */
 asmlinkage long sys_ioperm(unsigned long, unsigned long, int);
 asmlinkage long sys_iopl(unsigned int);
+#endif /* CONFIG_X86_IOPORT */
 
 /* kernel/ldt.c */
 asmlinkage int sys_modify_ldt(int, void __user *, unsigned long);
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 8f1e774..84d5fbe 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -20,7 +20,8 @@ CFLAGS_irq.o := -I$(src)/../include/asm/trace
 
 obj-y			:= process_$(BITS).o signal.o entry_$(BITS).o
 obj-y			+= traps.o irq.o irq_$(BITS).o dumpstack_$(BITS).o
-obj-y			+= time.o ioport.o ldt.o dumpstack.o nmi.o
+obj-y			+= time.o ldt.o dumpstack.o nmi.o
+obj-$(CONFIG_X86_IOPORT) += ioport.o
 obj-y			+= setup.o x86_init.o i8259.o irqinit.o jump_label.o
 obj-$(CONFIG_IRQ_WORK)  += irq_work.o
 obj-y			+= probe_roms.o
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index df088bb..1e6a74e0 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -609,6 +609,11 @@ ENTRY(stub_\func)
 END(stub_\func)
 	.endm
 
+	FORK_LIKE  clone
+	FORK_LIKE  fork
+	FORK_LIKE  vfork
+
+#ifdef CONFIG_X86_IOPORT
 	.macro FIXED_FRAME label,func
 ENTRY(\label)
 	CFI_STARTPROC
@@ -621,10 +626,8 @@ ENTRY(\label)
 END(\label)
 	.endm
 
-	FORK_LIKE  clone
-	FORK_LIKE  fork
-	FORK_LIKE  vfork
 	FIXED_FRAME stub_iopl, sys_iopl
+#endif /* CONFIG_X86_IOPORT */
 
 ENTRY(ptregscall_common)
 	DEFAULT_FRAME 1 8	/* offset 8: return address */
diff --git a/arch/x86/kernel/process-io.h b/arch/x86/kernel/process-io.h
index e48d5c9..3e773fa 100644
--- a/arch/x86/kernel/process-io.h
+++ b/arch/x86/kernel/process-io.h
@@ -3,12 +3,15 @@
 
 static inline void clear_thread_io_bitmap(struct task_struct *p)
 {
+#ifdef CONFIG_X86_IOPORT
 	p->thread.io_bitmap_ptr = NULL;
+#endif /* CONFIG_X86_IOPORT */
 }
 
 static inline int copy_io_bitmap(struct task_struct *me,
 				 struct task_struct *p)
 {
+#ifdef CONFIG_X86_IOPORT
 	if (unlikely(test_tsk_thread_flag(me, TIF_IO_BITMAP))) {
 		p->thread.io_bitmap_ptr = kmemdup(me->thread.io_bitmap_ptr,
 						  IO_BITMAP_BYTES, GFP_KERNEL);
@@ -20,12 +23,14 @@ static inline int copy_io_bitmap(struct task_struct *me,
 	} else {
 		p->thread.io_bitmap_ptr = NULL;
 	}
+#endif /* CONFIG_X86_IOPORT */
 
 	return 0;
 }
 
 static inline void exit_thread_io(struct task_struct *me)
 {
+#ifdef CONFIG_X86_IOPORT
         struct thread_struct *t = &me->thread;
         unsigned long *bp = t->io_bitmap_ptr;
 
@@ -42,11 +47,13 @@ static inline void exit_thread_io(struct task_struct *me)
                 put_cpu();
                 kfree(bp);
         }
+#endif /* CONFIG_X86_IOPORT */
 }
 
 static inline void switch_iopl_mask(struct thread_struct *prev,
 				    struct thread_struct *next)
 {
+#ifdef CONFIG_X86_IOPORT
         /*
          * Restore IOPL if needed.  In normal use, the flags restore
          * in the switch assembly will handle this.  But if the kernel
@@ -55,12 +62,14 @@ static inline void switch_iopl_mask(struct thread_struct *prev,
          */
         if (get_kernel_rpl() && unlikely(prev->iopl != next->iopl))
                 set_iopl_mask(next->iopl);
+#endif /* CONFIG_X86_IOPORT */
 }
 
 static inline void switch_io_bitmap(struct tss_struct *tss,
 				    struct task_struct *prev_p,
 				    struct task_struct *next_p)
 {
+#ifdef CONFIG_X86_IOPORT
         struct thread_struct *prev, *next;
         prev = &prev_p->thread;
         next = &next_p->thread;
@@ -78,6 +87,7 @@ static inline void switch_io_bitmap(struct tss_struct *tss,
                  */
                 memset(tss->io_bitmap, 0xff, prev->io_bitmap_max);
         }
+#endif /* CONFIG_X86_IOPORT */
 }
 
 #endif /* _X86_KERNEL_PROCESS_IO_H */
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 749b0e4..fdb74a8 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -785,7 +785,11 @@ static int ptrace_set_debugreg(struct task_struct *tsk, int n,
 static int ioperm_active(struct task_struct *target,
 			 const struct user_regset *regset)
 {
+#ifdef CONFIG_X86_IOPORT
 	return target->thread.io_bitmap_max / regset->size;
+#else
+	return 0;
+#endif
 }
 
 static int ioperm_get(struct task_struct *target,
@@ -793,12 +797,16 @@ static int ioperm_get(struct task_struct *target,
 		      unsigned int pos, unsigned int count,
 		      void *kbuf, void __user *ubuf)
 {
+#ifdef CONFIG_X86_IOPORT
 	if (!target->thread.io_bitmap_ptr)
 		return -ENXIO;
 
 	return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
 				   target->thread.io_bitmap_ptr,
 				   0, IO_BITMAP_BYTES);
+#else
+	return -ENXIO;
+#endif
 }
 
 /*
diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c
index 2bd78e2..7c7d405 100644
--- a/drivers/tty/vt/vt_ioctl.c
+++ b/drivers/tty/vt/vt_ioctl.c
@@ -410,7 +410,7 @@ int vt_ioctl(struct tty_struct *tty,
 		 *
 		 * XXX: you should never use these, just call ioperm directly..
 		 */
-#ifdef CONFIG_X86
+#ifdef CONFIG_X86_IOPORT
 	case KDADDIO:
 	case KDDELIO:
 		/*
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 02aa418..f3014fe 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -224,3 +224,8 @@ cond_syscall(sys_seccomp);
 
 /* access BPF programs and maps */
 cond_syscall(sys_bpf);
+
+/* userspace I/O port access */
+cond_syscall(stub_iopl);
+cond_syscall(sys_iopl);
+cond_syscall(sys_ioperm);
-- 
2.1.1


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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:43:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:43:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkzBT-0000JF-L3; Sun, 02 Nov 2014 17:43:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkzBR-0000JA-GX
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 17:43:21 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	B4/E0-22777-83D66545; Sun, 02 Nov 2014 17:43:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1414950197!5601988!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15956 invoked from network); 2 Nov 2014 17:43:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 17:43:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188709555"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 12:43:16 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkzBL-00020f-RC;
	Sun, 02 Nov 2014 17:43:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkzBL-0003PO-D9;
	Sun, 02 Nov 2014 17:43:15 +0000
Date: Sun, 2 Nov 2014 17:43:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31315-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 31285

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31285
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 31285
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31285

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c
baseline version:
 xen                  0f2bde078ace619fe8e26730495b6ef2c3a2e9bf

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 5283b310e14884341f51be35253cdd59c4cb034c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:32:27 2014 +0100

    x86/HVM: only kill guest when unknown VM exit occurred in guest kernel mode
    
    A recent KVM change by Nadav Amit <namit@cs.technion.ac.il> pointed out
    that unconditional VM exits (like VMX'es ones for the INVEPT, INVVPID,
    and XSETBV instructions) may result from guest user mode activity (in
    the example cases, e.g. prior to a privilege level check being done).
    Consequently convert the unconditional domain_crash() to a conditional
    one (when guest is in kernel mode) with the alternative of injecting
    #UD (when in user mode).
    
    This is meant to be a precaution against in-guest security issues
    introduced when any such VM exit becomes possible (on newer hardware)
    without the hypervisor immediately being aware of it. There are no such
    unhandled VM exits currently (and hence this is not an active security
    issue), but old (no longer security maintained) versions exhibit issues
    in the cases given as examples above.
    
    Suggested-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Acked-by: Kevin Tian <kevin.tian@intel.com>

commit 93cc5c6f1641e90eb120826d42f103b7726efb8e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:31:11 2014 +0100

    VMX: values written to MSR_IA32_SYSENTER_E[IS]P should be canonical
    
    A recent KVM change by Nadav Amit <namit@cs.technion.ac.il> helped spot
    that we have the same issue as they did.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Kevin Tian <kevin.tian@intel.com>

commit 9cf71226edabd8b9bc81a5eb57823dacbe8b4bd8
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Fri Oct 31 11:28:36 2014 +0100

    process softirqs while dumping domains
    
    Process softirqs once per domain, and once every 64 vcpus in a guest to avoid
    being hit by the NMI watchdog.  Discovered against a VM which had accidentally
    been assigned 8192 vcpus.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 17:43:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 17:43:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XkzBT-0000JF-L3; Sun, 02 Nov 2014 17:43:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XkzBR-0000JA-GX
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 17:43:21 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	B4/E0-22777-83D66545; Sun, 02 Nov 2014 17:43:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1414950197!5601988!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15956 invoked from network); 2 Nov 2014 17:43:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Nov 2014 17:43:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="188709555"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 12:43:16 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XkzBL-00020f-RC;
	Sun, 02 Nov 2014 17:43:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XkzBL-0003PO-D9;
	Sun, 02 Nov 2014 17:43:15 +0000
Date: Sun, 2 Nov 2014 17:43:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31315-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 31285

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31285
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 31285
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31285

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c
baseline version:
 xen                  0f2bde078ace619fe8e26730495b6ef2c3a2e9bf

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 5283b310e14884341f51be35253cdd59c4cb034c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:32:27 2014 +0100

    x86/HVM: only kill guest when unknown VM exit occurred in guest kernel mode
    
    A recent KVM change by Nadav Amit <namit@cs.technion.ac.il> pointed out
    that unconditional VM exits (like VMX'es ones for the INVEPT, INVVPID,
    and XSETBV instructions) may result from guest user mode activity (in
    the example cases, e.g. prior to a privilege level check being done).
    Consequently convert the unconditional domain_crash() to a conditional
    one (when guest is in kernel mode) with the alternative of injecting
    #UD (when in user mode).
    
    This is meant to be a precaution against in-guest security issues
    introduced when any such VM exit becomes possible (on newer hardware)
    without the hypervisor immediately being aware of it. There are no such
    unhandled VM exits currently (and hence this is not an active security
    issue), but old (no longer security maintained) versions exhibit issues
    in the cases given as examples above.
    
    Suggested-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Acked-by: Kevin Tian <kevin.tian@intel.com>

commit 93cc5c6f1641e90eb120826d42f103b7726efb8e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:31:11 2014 +0100

    VMX: values written to MSR_IA32_SYSENTER_E[IS]P should be canonical
    
    A recent KVM change by Nadav Amit <namit@cs.technion.ac.il> helped spot
    that we have the same issue as they did.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Kevin Tian <kevin.tian@intel.com>

commit 9cf71226edabd8b9bc81a5eb57823dacbe8b4bd8
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Fri Oct 31 11:28:36 2014 +0100

    process softirqs while dumping domains
    
    Process softirqs once per domain, and once every 64 vcpus in a guest to avoid
    being hit by the NMI watchdog.  Discovered against a VM which had accidentally
    been assigned 8192 vcpus.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 20:10:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 20:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl1TK-0001pU-Fi; Sun, 02 Nov 2014 20:09:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Xl1TI-0001pP-Tt
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 20:09:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	94/09-09842-49F86545; Sun, 02 Nov 2014 20:09:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1414958994!12194475!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2593 invoked from network); 2 Nov 2014 20:09:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Nov 2014 20:09: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
	sA2K9kLl031261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 2 Nov 2014 15:09:47 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sA2K9kro031259;
	Sun, 2 Nov 2014 15:09:46 -0500
Date: Sun, 2 Nov 2014 16:09:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141102200945.GA31191@andromeda.dapyr.net>
References: <544E397F0200007800042651@mail.emea.novell.com>
	<20141027170115.GC11893@laptop.dumpdata.com>
	<544E8283.1030907@citrix.com>
	<20141027180010.GB12989@laptop.dumpdata.com>
	<20141027211338.GA17750@laptop.dumpdata.com>
	<544F81640200007800042BE5@mail.emea.novell.com>
	<20141028200734.GA31298@laptop.dumpdata.com>
	<5450B32E0200007800042FC8@mail.emea.novell.com>
	<20141029211125.GA7967@laptop.dumpdata.com>
	<54520D3202000078000435FA@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54520D3202000078000435FA@mail.emea.novell.com>
User-Agent: Mutt/1.5.9i
Cc: keir@xen.org, ian.campbell@citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>, tim@xen.org,
	xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v8 for-xen-4.5 2/2] dpci: Replace tasklet
	with an softirq (v8)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > -void pci_release_devices(struct domain *d)
> > +int pci_release_devices(struct domain *d)
> >  {
> >      struct pci_dev *pdev;
> >      u8 bus, devfn;
> > +    int ret;
> >  
> >      spin_lock(&pcidevs_lock);
> > -    pci_clean_dpci_irqs(d);
> > +    ret = pci_clean_dpci_irqs(d);
> > +    if ( ret == -ERESTART )
> > +    {
> > +        spin_unlock(&pcidevs_lock);
> > +        return ret;
> > +    }
> >      while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
> >      {
> >          bus = pdev->bus;
> 
> Even if errors other than -ERESTART aren't possible right now, the
> code now looks like it is ignoring such. I think it would be better if
> you simply dropped the special casing of -ERESTART and propagated
> all errors here.

The will cause a regression. The pci_clean_dpci_irqs will
now return -EINVAL if the iommu is turned off - which will mean
that we won't be able to kill an HVM guest without passthrough.

I can do:

1). if ( ret && !(ret == -EINVAL || ret == -E..))

2). Or remove the various 'return -EINVAL' in the  pci_clean_dpci_irqs
   for the causes where IOMMU is off or there are no PCI passthrough
   devices - and just make them return 0.

3). Leave it as is.

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 20:10:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 20:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl1TK-0001pU-Fi; Sun, 02 Nov 2014 20:09:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Xl1TI-0001pP-Tt
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 20:09:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	94/09-09842-49F86545; Sun, 02 Nov 2014 20:09:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1414958994!12194475!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2593 invoked from network); 2 Nov 2014 20:09:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Nov 2014 20:09: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
	sA2K9kLl031261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 2 Nov 2014 15:09:47 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sA2K9kro031259;
	Sun, 2 Nov 2014 15:09:46 -0500
Date: Sun, 2 Nov 2014 16:09:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141102200945.GA31191@andromeda.dapyr.net>
References: <544E397F0200007800042651@mail.emea.novell.com>
	<20141027170115.GC11893@laptop.dumpdata.com>
	<544E8283.1030907@citrix.com>
	<20141027180010.GB12989@laptop.dumpdata.com>
	<20141027211338.GA17750@laptop.dumpdata.com>
	<544F81640200007800042BE5@mail.emea.novell.com>
	<20141028200734.GA31298@laptop.dumpdata.com>
	<5450B32E0200007800042FC8@mail.emea.novell.com>
	<20141029211125.GA7967@laptop.dumpdata.com>
	<54520D3202000078000435FA@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54520D3202000078000435FA@mail.emea.novell.com>
User-Agent: Mutt/1.5.9i
Cc: keir@xen.org, ian.campbell@citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>, tim@xen.org,
	xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v8 for-xen-4.5 2/2] dpci: Replace tasklet
	with an softirq (v8)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > -void pci_release_devices(struct domain *d)
> > +int pci_release_devices(struct domain *d)
> >  {
> >      struct pci_dev *pdev;
> >      u8 bus, devfn;
> > +    int ret;
> >  
> >      spin_lock(&pcidevs_lock);
> > -    pci_clean_dpci_irqs(d);
> > +    ret = pci_clean_dpci_irqs(d);
> > +    if ( ret == -ERESTART )
> > +    {
> > +        spin_unlock(&pcidevs_lock);
> > +        return ret;
> > +    }
> >      while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
> >      {
> >          bus = pdev->bus;
> 
> Even if errors other than -ERESTART aren't possible right now, the
> code now looks like it is ignoring such. I think it would be better if
> you simply dropped the special casing of -ERESTART and propagated
> all errors here.

The will cause a regression. The pci_clean_dpci_irqs will
now return -EINVAL if the iommu is turned off - which will mean
that we won't be able to kill an HVM guest without passthrough.

I can do:

1). if ( ret && !(ret == -EINVAL || ret == -E..))

2). Or remove the various 'return -EINVAL' in the  pci_clean_dpci_irqs
   for the causes where IOMMU is off or there are no PCI passthrough
   devices - and just make them return 0.

3). Leave it as is.

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

From xen-devel-bounces@lists.xen.org Sun Nov 02 20:28:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 20: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 1Xl1lB-000283-GN; Sun, 02 Nov 2014 20:28:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xl1l9-00027y-So
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 20:28:24 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	8F/89-02984-6E396545; Sun, 02 Nov 2014 20:28:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1414960100!12064317!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10409 invoked from network); 2 Nov 2014 20:28:21 -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;
	2 Nov 2014 20:28:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187352682"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 15:28:19 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xl1l4-0002nd-WF;
	Sun, 02 Nov 2014 20:28:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xl1l4-00059A-Qk;
	Sun, 02 Nov 2014 20:28:18 +0000
Date: Sun, 2 Nov 2014 20:28:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31318-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31318: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 31292
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate/x10 fail pass in 31277
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot    fail in 31292 pass in 31318

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31277 never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 02 20:28:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 20: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 1Xl1lB-000283-GN; Sun, 02 Nov 2014 20:28:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xl1l9-00027y-So
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 20:28:24 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	8F/89-02984-6E396545; Sun, 02 Nov 2014 20:28:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1414960100!12064317!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10409 invoked from network); 2 Nov 2014 20:28:21 -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;
	2 Nov 2014 20:28:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187352682"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 15:28:19 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xl1l4-0002nd-WF;
	Sun, 02 Nov 2014 20:28:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xl1l4-00059A-Qk;
	Sun, 02 Nov 2014 20:28:18 +0000
Date: Sun, 2 Nov 2014 20:28:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31318-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31318: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 31292
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate/x10 fail pass in 31277
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot    fail in 31292 pass in 31318

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31277 never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 02 21:31:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 21:31:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl2jg-0002qm-E5; Sun, 02 Nov 2014 21:30:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xl2je-0002qh-QQ
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 21:30:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	89/22-09936-E82A6545; Sun, 02 Nov 2014 21:30:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1414963851!4938655!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9384 invoked from network); 2 Nov 2014 21:30:53 -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 Nov 2014 21:30:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187359809"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 16:30:45 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xl2jV-00036I-4g;
	Sun, 02 Nov 2014 21:30:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xl2jU-0006N5-U8;
	Sun, 02 Nov 2014 21:30:44 +0000
Date: Sun, 2 Nov 2014 21:30:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31327-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8251
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31327: 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: multipart/mixed; boundary="===============4030713935602537736=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4030713935602537736==
Content-Type: text/plain
Content-Length: 7978
Content-Transfer-Encoding: quoted-printable

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              e7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad
baseline version:
 libvirt              720be2eb5f0216564d158dca99c466fac2c16a53

------------------------------------------------------------
People who touched revisions under test:
  Eric Blake <eblake@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Pavel Hrdina <phrdina@redhat.com>
  Weiwei Li <nuonuoli@tencent.com>
  weiwei li <weiweili821@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3De7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt e7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad
+ branch=3Dlibvirt
+ revision=3De7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git e7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   720be2e..e7e0580  e7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad -> xen-tested-master


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

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

--===============4030713935602537736==--

From xen-devel-bounces@lists.xen.org Sun Nov 02 21:31:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Nov 2014 21:31:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl2jg-0002qm-E5; Sun, 02 Nov 2014 21:30:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xl2je-0002qh-QQ
	for xen-devel@lists.xensource.com; Sun, 02 Nov 2014 21:30:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	89/22-09936-E82A6545; Sun, 02 Nov 2014 21:30:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1414963851!4938655!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9384 invoked from network); 2 Nov 2014 21:30:53 -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 Nov 2014 21:30:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="187359809"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 16:30:45 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xl2jV-00036I-4g;
	Sun, 02 Nov 2014 21:30:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xl2jU-0006N5-U8;
	Sun, 02 Nov 2014 21:30:44 +0000
Date: Sun, 2 Nov 2014 21:30:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31327-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8251
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31327: 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: multipart/mixed; boundary="===============4030713935602537736=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4030713935602537736==
Content-Type: text/plain
Content-Length: 7978
Content-Transfer-Encoding: quoted-printable

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              e7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad
baseline version:
 libvirt              720be2eb5f0216564d158dca99c466fac2c16a53

------------------------------------------------------------
People who touched revisions under test:
  Eric Blake <eblake@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Pavel Hrdina <phrdina@redhat.com>
  Weiwei Li <nuonuoli@tencent.com>
  weiwei li <weiweili821@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3De7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt e7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad
+ branch=3Dlibvirt
+ revision=3De7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git e7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   720be2e..e7e0580  e7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad -> xen-tested-master


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

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

--===============4030713935602537736==--

From xen-devel-bounces@lists.xen.org Mon Nov 03 02:04:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 02:04:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl6zs-0002oE-2l; Mon, 03 Nov 2014 02:03:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xl6zr-0002o9-60
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 02:03:55 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	97/03-17694-A82E6545; Mon, 03 Nov 2014 02:03:54 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1414980232!11122937!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15098 invoked from network); 3 Nov 2014 02:03:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 02:03:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Nov 2014 18:03:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,304,1413270000"; d="scan'208";a="615755424"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 02 Nov 2014 18:03:24 -0800
Message-ID: <5456E26B.9040106@intel.com>
Date: Mon, 03 Nov 2014 10:03:23 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414721915-11186-1-git-send-email-tiejun.chen@intel.com>
	<545361450200007800043DBC@mail.emea.novell.com>
In-Reply-To: <545361450200007800043DBC@mail.emea.novell.com>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/31 17:15, Jan Beulich wrote:
>>>> On 31.10.14 at 03:18, <tiejun.chen@intel.com> wrote:
>
> (You omitted half of the tools maintainers; Cc-ing them now.)

I think I already pick all relevant maintainers to review this patch,

$ ./scripts/get_maintainer.pl 
0004-tools-hvmloader-link-errno.h-from-xen-internal.patch
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Wei Liu <wei.liu2@citrix.com>
xen-devel@lists.xen.org

So please tell me whom should be included specifically.

>
>> We will use some error numbers in hvmloader so here just link
>> this head file from xen.
>
> This is not a proper reasoning for using the Xen internal header here.
> You should make clear that we want to act on specific hypercall
> error codes, and hence require the hypervisors view on the errno.h
> values rather than the build environment's (as was sufficient for the
> use in xenbus.c).
>

So rephrase,

     tools/hvmloader: link errno.h from xen internal

     We need to act on some specific hypercall error numbers, so
     require the hypervisor view on the errno.h value rather than
     just the build environment's number. So here link this headfile
     from xen.

>> --- a/tools/firmware/hvmloader/Makefile
>> +++ b/tools/firmware/hvmloader/Makefile
>> @@ -84,9 +84,13 @@ ROMS += $(SEABIOS_ROM)
>>   endif
>>
>>   .PHONY: all
>> -all: subdirs-all
>> +all: subdirs-all .dir
>>   	$(MAKE) hvmloader
>>
>> +.dir:
>> +	@rm -rf errno.h
>
> Why?

We should make sure we are linking to create a non-existing file, 
otherwise you may see this,

ln: failed to create symbolic link '...': File exists

>
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -6,6 +6,7 @@
>>   #include <stddef.h>
>>   #include <xen/xen.h>
>>   #include <xen/hvm/hvm_info_table.h>
>> +#include "errno.h"
>
> Does this allow xenbus.c to still build? I think this either should go into

I did a test as follows:
1: make clean
2: make xen
3: make tools
4: make clean
5: make tools

Is this covering xenbus?

> the .c file wanting to use the values (preferable - remember my earlier
> comment about introducing unnecessary dependencies?), or the

Okay, I can remove this part, then just add this head file into any 
necessary .c files. This will be addressed in other RMRR patches.

Thanks
Tiejun

> respective #include <errno.h> in xenbus.c should be dropped.
>
> Jan
>
>

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 02:04:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 02:04:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl6zs-0002oE-2l; Mon, 03 Nov 2014 02:03:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xl6zr-0002o9-60
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 02:03:55 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	97/03-17694-A82E6545; Mon, 03 Nov 2014 02:03:54 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1414980232!11122937!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15098 invoked from network); 3 Nov 2014 02:03:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 02:03:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Nov 2014 18:03:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,304,1413270000"; d="scan'208";a="615755424"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 02 Nov 2014 18:03:24 -0800
Message-ID: <5456E26B.9040106@intel.com>
Date: Mon, 03 Nov 2014 10:03:23 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414721915-11186-1-git-send-email-tiejun.chen@intel.com>
	<545361450200007800043DBC@mail.emea.novell.com>
In-Reply-To: <545361450200007800043DBC@mail.emea.novell.com>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/31 17:15, Jan Beulich wrote:
>>>> On 31.10.14 at 03:18, <tiejun.chen@intel.com> wrote:
>
> (You omitted half of the tools maintainers; Cc-ing them now.)

I think I already pick all relevant maintainers to review this patch,

$ ./scripts/get_maintainer.pl 
0004-tools-hvmloader-link-errno.h-from-xen-internal.patch
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Wei Liu <wei.liu2@citrix.com>
xen-devel@lists.xen.org

So please tell me whom should be included specifically.

>
>> We will use some error numbers in hvmloader so here just link
>> this head file from xen.
>
> This is not a proper reasoning for using the Xen internal header here.
> You should make clear that we want to act on specific hypercall
> error codes, and hence require the hypervisors view on the errno.h
> values rather than the build environment's (as was sufficient for the
> use in xenbus.c).
>

So rephrase,

     tools/hvmloader: link errno.h from xen internal

     We need to act on some specific hypercall error numbers, so
     require the hypervisor view on the errno.h value rather than
     just the build environment's number. So here link this headfile
     from xen.

>> --- a/tools/firmware/hvmloader/Makefile
>> +++ b/tools/firmware/hvmloader/Makefile
>> @@ -84,9 +84,13 @@ ROMS += $(SEABIOS_ROM)
>>   endif
>>
>>   .PHONY: all
>> -all: subdirs-all
>> +all: subdirs-all .dir
>>   	$(MAKE) hvmloader
>>
>> +.dir:
>> +	@rm -rf errno.h
>
> Why?

We should make sure we are linking to create a non-existing file, 
otherwise you may see this,

ln: failed to create symbolic link '...': File exists

>
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -6,6 +6,7 @@
>>   #include <stddef.h>
>>   #include <xen/xen.h>
>>   #include <xen/hvm/hvm_info_table.h>
>> +#include "errno.h"
>
> Does this allow xenbus.c to still build? I think this either should go into

I did a test as follows:
1: make clean
2: make xen
3: make tools
4: make clean
5: make tools

Is this covering xenbus?

> the .c file wanting to use the values (preferable - remember my earlier
> comment about introducing unnecessary dependencies?), or the

Okay, I can remove this part, then just add this head file into any 
necessary .c files. This will be addressed in other RMRR patches.

Thanks
Tiejun

> respective #include <errno.h> in xenbus.c should be dropped.
>
> Jan
>
>

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 02:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 02:06:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl72l-0002u7-Mv; Mon, 03 Nov 2014 02:06:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xl72j-0002tx-Lv
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 02:06:53 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	92/01-26858-C33E6545; Mon, 03 Nov 2014 02:06:52 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1414980411!11175218!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5569 invoked from network); 3 Nov 2014 02:06:52 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 02:06:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 02 Nov 2014 18:06:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,304,1413270000"; d="scan'208";a="615756469"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 02 Nov 2014 18:06:48 -0800
Message-ID: <5456E337.7040704@intel.com>
Date: Mon, 03 Nov 2014 10:06:47 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com
References: <1414721915-11186-1-git-send-email-tiejun.chen@intel.com>
	<54535E97.2000105@citrix.com>
In-Reply-To: <54535E97.2000105@citrix.com>
Cc: JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/31 18:04, Andrew Cooper wrote:
> On 31/10/14 02:18, Tiejun Chen wrote:
>> We will use some error numbers in hvmloader so here just link
>> this head file from xen.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>
> We already use stdint, stdarg, stdarg and error (in xenbus.c) from the
> build environment.
>
> All of these are safe from an embedded point of view, which is
> essentially what we are doing with hvmloader.
>
> I highly suggest we just go with the environments error.h and be done
> with it.  C99 is very nice to us in this way.

Thanks for your comments. But looks we should follow-up Jan's further 
explanation.

Thanks
Tiejun

>
> ~Andrew
>
>> ---
>>   .gitignore                        | 1 +
>>   tools/firmware/hvmloader/Makefile | 8 ++++++--
>>   tools/firmware/hvmloader/util.h   | 1 +
>>   3 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/.gitignore b/.gitignore
>> index b24e905..52c3038 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -127,6 +127,7 @@ tools/firmware/hvmloader/acpi/ssdt_*.h
>>   tools/firmware/hvmloader/hvmloader
>>   tools/firmware/hvmloader/roms.h
>>   tools/firmware/hvmloader/roms.inc
>> +tools/firmware/hvmloader/errno.h
>>   tools/firmware/rombios/BIOS-bochs-[^/]*
>>   tools/firmware/rombios/_rombios[^/]*_.c
>>   tools/firmware/rombios/rombios[^/]*.s
>> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
>> index 46a79c5..2e0f062 100644
>> --- a/tools/firmware/hvmloader/Makefile
>> +++ b/tools/firmware/hvmloader/Makefile
>> @@ -84,9 +84,13 @@ ROMS += $(SEABIOS_ROM)
>>   endif
>>
>>   .PHONY: all
>> -all: subdirs-all
>> +all: subdirs-all .dir
>>   	$(MAKE) hvmloader
>>
>> +.dir:
>> +	@rm -rf errno.h
>> +	ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
>> +
>>   ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
>>   smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
>>
>> @@ -136,7 +140,7 @@ endif
>>
>>   .PHONY: clean
>>   clean: subdirs-clean
>> -	rm -f roms.inc roms.inc.new acpi.h
>> +	rm -f roms.inc roms.inc.new acpi.h errno.h
>>   	rm -f hvmloader hvmloader.tmp *.o $(DEPS)
>>
>>   -include $(DEPS)
>> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
>> index a70e4aa..1352025 100644
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -6,6 +6,7 @@
>>   #include <stddef.h>
>>   #include <xen/xen.h>
>>   #include <xen/hvm/hvm_info_table.h>
>> +#include "errno.h"
>>
>>   #define __STR(...) #__VA_ARGS__
>>   #define STR(...) __STR(__VA_ARGS__)
>
>
>

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 02:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 02:06:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl72l-0002u7-Mv; Mon, 03 Nov 2014 02:06:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xl72j-0002tx-Lv
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 02:06:53 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	92/01-26858-C33E6545; Mon, 03 Nov 2014 02:06:52 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1414980411!11175218!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5569 invoked from network); 3 Nov 2014 02:06:52 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 02:06:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 02 Nov 2014 18:06:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,304,1413270000"; d="scan'208";a="615756469"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 02 Nov 2014 18:06:48 -0800
Message-ID: <5456E337.7040704@intel.com>
Date: Mon, 03 Nov 2014 10:06:47 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com
References: <1414721915-11186-1-git-send-email-tiejun.chen@intel.com>
	<54535E97.2000105@citrix.com>
In-Reply-To: <54535E97.2000105@citrix.com>
Cc: JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/31 18:04, Andrew Cooper wrote:
> On 31/10/14 02:18, Tiejun Chen wrote:
>> We will use some error numbers in hvmloader so here just link
>> this head file from xen.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>
> We already use stdint, stdarg, stdarg and error (in xenbus.c) from the
> build environment.
>
> All of these are safe from an embedded point of view, which is
> essentially what we are doing with hvmloader.
>
> I highly suggest we just go with the environments error.h and be done
> with it.  C99 is very nice to us in this way.

Thanks for your comments. But looks we should follow-up Jan's further 
explanation.

Thanks
Tiejun

>
> ~Andrew
>
>> ---
>>   .gitignore                        | 1 +
>>   tools/firmware/hvmloader/Makefile | 8 ++++++--
>>   tools/firmware/hvmloader/util.h   | 1 +
>>   3 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/.gitignore b/.gitignore
>> index b24e905..52c3038 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -127,6 +127,7 @@ tools/firmware/hvmloader/acpi/ssdt_*.h
>>   tools/firmware/hvmloader/hvmloader
>>   tools/firmware/hvmloader/roms.h
>>   tools/firmware/hvmloader/roms.inc
>> +tools/firmware/hvmloader/errno.h
>>   tools/firmware/rombios/BIOS-bochs-[^/]*
>>   tools/firmware/rombios/_rombios[^/]*_.c
>>   tools/firmware/rombios/rombios[^/]*.s
>> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
>> index 46a79c5..2e0f062 100644
>> --- a/tools/firmware/hvmloader/Makefile
>> +++ b/tools/firmware/hvmloader/Makefile
>> @@ -84,9 +84,13 @@ ROMS += $(SEABIOS_ROM)
>>   endif
>>
>>   .PHONY: all
>> -all: subdirs-all
>> +all: subdirs-all .dir
>>   	$(MAKE) hvmloader
>>
>> +.dir:
>> +	@rm -rf errno.h
>> +	ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
>> +
>>   ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
>>   smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
>>
>> @@ -136,7 +140,7 @@ endif
>>
>>   .PHONY: clean
>>   clean: subdirs-clean
>> -	rm -f roms.inc roms.inc.new acpi.h
>> +	rm -f roms.inc roms.inc.new acpi.h errno.h
>>   	rm -f hvmloader hvmloader.tmp *.o $(DEPS)
>>
>>   -include $(DEPS)
>> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
>> index a70e4aa..1352025 100644
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -6,6 +6,7 @@
>>   #include <stddef.h>
>>   #include <xen/xen.h>
>>   #include <xen/hvm/hvm_info_table.h>
>> +#include "errno.h"
>>
>>   #define __STR(...) #__VA_ARGS__
>>   #define STR(...) __STR(__VA_ARGS__)
>
>
>

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 02:22:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 02:22:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl7I0-0003Dd-KM; Mon, 03 Nov 2014 02:22:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xl7Hz-0003DU-Ji
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 02:22:39 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	99/79-17694-EE6E6545; Mon, 03 Nov 2014 02:22:38 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1414981357!11098043!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17562 invoked from network); 3 Nov 2014 02:22:38 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 02:22:38 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Nov 2014 18:22:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,304,1413270000"; d="scan'208";a="615761280"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 02 Nov 2014 18:22:34 -0800
Message-ID: <5456E6E9.1080104@intel.com>
Date: Mon, 03 Nov 2014 10:22:33 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
In-Reply-To: <545352F40200007800043D82@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/31 16:14, Jan Beulich wrote:
>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>> when we really need them.
>>>>>
>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>> files are to be present in headers, and the defining .c file has to
>>>>> include that header (making sure declaration and definition are and
>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>> shouldn't forget it's not application code that you're modifying.
>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>> (and certain other code system components) the consequences of
>>>>> being lax are much more severe.
>>>>
>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>> '<xen/memory.h>,
>>>>
>>>> #include "util.h"
>>>> ...
>>>> #include <xen/memory.h>
>>>>
>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>
>>> Redefine? I said forward declare.
>>
>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>> the head file, tools/firmware/hvmloader/util.h,
>>
>> unsigned int hvm_get_reserved_device_memory_map(void);
>
> To me this looks very much like poor programming style, even if in
> the context of hvmloader communicating information via global
> variables rather than function arguments and return values is

Do you mean you don't like a global variable? But it can be use to get 
RDM without more hypercall or function call in the context of hvmloader.

> generally possible.

The following is what I did:

+struct xen_reserved_device_memory *rdm_map;
+static int
+get_reserved_device_memory_map(struct xen_reserved_device_memory entries[],
+                               uint32_t *max_entries)
+{
+    int rc;
+    struct xen_reserved_device_memory_map xrdmmap = {
+        .nr_entries = *max_entries
+    };
+
+    set_xen_guest_handle(xrdmmap.buffer, entries);
+
+    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map, &xrdmmap);
+    if ( rc == -ENOBUFS )
+        *max_entries = xrdmmap.nr_entries;
+
+    return rc;
+}
+
+/*
+ * Getting all reserved device memory map info in case of hvmloader.
+ * We just return zero for any failed cases, and this means we
+ * can't further handle any reserved device memory.
+ */
+unsigned int hvm_get_reserved_device_memory_map(void)
+{
+ ...
+}

So if you think they're not good, just please define these prototypes 
then I can finish them.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 02:22:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 02:22:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl7I0-0003Dd-KM; Mon, 03 Nov 2014 02:22:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xl7Hz-0003DU-Ji
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 02:22:39 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	99/79-17694-EE6E6545; Mon, 03 Nov 2014 02:22:38 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1414981357!11098043!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17562 invoked from network); 3 Nov 2014 02:22:38 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 02:22:38 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Nov 2014 18:22:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,304,1413270000"; d="scan'208";a="615761280"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 02 Nov 2014 18:22:34 -0800
Message-ID: <5456E6E9.1080104@intel.com>
Date: Mon, 03 Nov 2014 10:22:33 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
In-Reply-To: <545352F40200007800043D82@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/31 16:14, Jan Beulich wrote:
>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>> when we really need them.
>>>>>
>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>> files are to be present in headers, and the defining .c file has to
>>>>> include that header (making sure declaration and definition are and
>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>> shouldn't forget it's not application code that you're modifying.
>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>> (and certain other code system components) the consequences of
>>>>> being lax are much more severe.
>>>>
>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>> '<xen/memory.h>,
>>>>
>>>> #include "util.h"
>>>> ...
>>>> #include <xen/memory.h>
>>>>
>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>
>>> Redefine? I said forward declare.
>>
>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>> the head file, tools/firmware/hvmloader/util.h,
>>
>> unsigned int hvm_get_reserved_device_memory_map(void);
>
> To me this looks very much like poor programming style, even if in
> the context of hvmloader communicating information via global
> variables rather than function arguments and return values is

Do you mean you don't like a global variable? But it can be use to get 
RDM without more hypercall or function call in the context of hvmloader.

> generally possible.

The following is what I did:

+struct xen_reserved_device_memory *rdm_map;
+static int
+get_reserved_device_memory_map(struct xen_reserved_device_memory entries[],
+                               uint32_t *max_entries)
+{
+    int rc;
+    struct xen_reserved_device_memory_map xrdmmap = {
+        .nr_entries = *max_entries
+    };
+
+    set_xen_guest_handle(xrdmmap.buffer, entries);
+
+    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map, &xrdmmap);
+    if ( rc == -ENOBUFS )
+        *max_entries = xrdmmap.nr_entries;
+
+    return rc;
+}
+
+/*
+ * Getting all reserved device memory map info in case of hvmloader.
+ * We just return zero for any failed cases, and this means we
+ * can't further handle any reserved device memory.
+ */
+unsigned int hvm_get_reserved_device_memory_map(void)
+{
+ ...
+}

So if you think they're not good, just please define these prototypes 
then I can finish them.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 02:25:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 02:25:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl7KM-0003MV-6j; Mon, 03 Nov 2014 02:25:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xl7KL-0003MN-0I
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 02:25:05 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	99/6B-14214-087E6545; Mon, 03 Nov 2014 02:25:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1414981501!9008540!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21725 invoked from network); 3 Nov 2014 02:25:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 02:25:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,304,1413244800"; d="scan'208";a="188762237"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 21:25:00 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xl7KG-0004Ur-3e;
	Mon, 03 Nov 2014 02:25:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xl7KF-0008Ee-MZ;
	Mon, 03 Nov 2014 02:24:59 +0000
Date: Mon, 3 Nov 2014 02:24:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31322-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31322: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31253
 test-amd64-i386-rhel6hvm-amd 10 guest-destroy      fail in 31253 pass in 31322
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 12 guest-localmigrate.2 fail in 31253 pass in 31322

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              136d4ec190af616bb4fa8624dd9c648e5c9e0d2a
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 311 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 Nov 03 02:25:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 02:25:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl7KM-0003MV-6j; Mon, 03 Nov 2014 02:25:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xl7KL-0003MN-0I
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 02:25:05 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	99/6B-14214-087E6545; Mon, 03 Nov 2014 02:25:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1414981501!9008540!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21725 invoked from network); 3 Nov 2014 02:25:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 02:25:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,304,1413244800"; d="scan'208";a="188762237"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 2 Nov 2014 21:25:00 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xl7KG-0004Ur-3e;
	Mon, 03 Nov 2014 02:25:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xl7KF-0008Ee-MZ;
	Mon, 03 Nov 2014 02:24:59 +0000
Date: Mon, 3 Nov 2014 02:24:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31322-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31322: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31253
 test-amd64-i386-rhel6hvm-amd 10 guest-destroy      fail in 31253 pass in 31322
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 12 guest-localmigrate.2 fail in 31253 pass in 31322

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              136d4ec190af616bb4fa8624dd9c648e5c9e0d2a
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 311 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 Nov 03 05:08:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 05:08:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl9sM-00062U-TK; Mon, 03 Nov 2014 05:08:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1Xl9sL-00062O-6M
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 05:08:21 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	ED/C2-02698-4CD07545; Mon, 03 Nov 2014 05:08:20 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1414991298!12106985!1
X-Originating-IP: [209.85.220.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30272 invoked from network); 3 Nov 2014 05:08:19 -0000
Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com)
	(209.85.220.180)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 05:08:19 -0000
Received: by mail-vc0-f180.google.com with SMTP id hy10so5450932vcb.11
	for <xen-devel@lists.xenproject.org>;
	Sun, 02 Nov 2014 21:08:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Xuzq/ssUK7O1yMQLkOLWRbnkevaqiBoPe6x5gVwGkR8=;
	b=BbHIHca7QMrF9m5YgjSbhNgMxIihzeDp6CHW3FcHZKMWS7gAhYty3D4O4hcx9+Yfal
	dpR+moTcyyjgCDoOv1l73pLsVqsEOsB35nUCoB/IcVpA0w+B29tEq/x850UicEgzay21
	N/7aa/eqnBxGXqaXwFeb0q9YWBFW2Pv0bCNrL6/oOMjBqSEVArGnz1/zSiSYiVz3u757
	4Le68Huo8HxxGa+QLrd0K2Ubooe/EVVR9vi0K51BOLk4T8kXD9LOyjl6QFwlL2hJc/zw
	gd1bhj4fWAm6K9Kfwa2QjqwghiBBrt5frsGTNqod2tPrfHAxoqGFD2fkj6UkQB+kf97e
	B4cQ==
MIME-Version: 1.0
X-Received: by 10.220.16.70 with SMTP id n6mr202161vca.36.1414991298434; Sun,
	02 Nov 2014 21:08:18 -0800 (PST)
Received: by 10.221.57.8 with HTTP; Sun, 2 Nov 2014 21:08:18 -0800 (PST)
In-Reply-To: <545604CF.60905@linaro.org>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<CAAiw7J=Mbb1YGYj=XQv6TmqyAMvcctUs7AvHQN_1O27xCRSp_Q@mail.gmail.com>
	<20141031142403.GA6913@laptop.dumpdata.com>
	<54539D4D.1040108@linaro.org>
	<20141031210156.GA20039@laptop.dumpdata.com>
	<54551BDD.5080800@linaro.org>
	<CAAiw7J=0RbBwTJUS8AP9V88r7D+iKGjMpfF4rH_EOKi1GwBWMw@mail.gmail.com>
	<545604CF.60905@linaro.org>
Date: Mon, 3 Nov 2014 10:38:18 +0530
Message-ID: <CAAiw7J=PvYq6s_DQ0gyaZx8gs_Xw2Z-X1BpKe6a3KwhNTkd+Uw@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>, manish.jaggi@caviumnetworks.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ARM] SMMU and PCI passthrough Was: Re: Xen 4.5-rc1
 update (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2 November 2014 15:47, Julien Grall <julien.grall@linaro.org> wrote:
> (Renaming the subject of the thread).
>
> On 02/11/2014 06:03, manish jaggi wrote:
>>
>> On 1 November 2014 23:13, Julien Grall <julien.grall@linaro.org> wrote:
>>>
>>> Hi Konrad,
>>>
>>>
>>> On 31/10/2014 21:01, Konrad Rzeszutek Wilk wrote:
>>>>
>>>>
>>>> On Fri, Oct 31, 2014 at 02:31:41PM +0000, Julien Grall wrote:
>>>>>
>>>>>
>>>>> On 10/31/2014 02:24 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> *  PVH - PCI passthrough for DomU.
>>>>>>>
>>>>>>>
>>>>>>> I am working on Cavium Thunder (ARM64) on this feature.
>>>>>>> [Xen SMMU driver changes + PCI passthrough changes in Xen and Linux]
>>>>>
>>>>>
>>>>>
>>>>> FYI, I'm currently reworking the SMMU drivers to resync with Linux.
>>>>> With
>>>>> thoses changes, you should not need to modify the SMMU code.
>>>>
>>>>
>>>>
>>>> Thank you for the update. Put your name behind that for 4.6.
>>>>>
>>>>>
>>>>>
>>>>>> Ok, replaced Julien's name with yours. Please make sure
>>>>>> that for the Linux patches you CC xen-devel and the
>>>>>> maintainers (David, Stefano, Boris and me).
>>>>>
>>>>>
>>>>>
>>>>> There is 2 distinct passthrough: platform (i.e non-PCI) and PCI one.
>>>>>
>>>>> While Manish is working on PCI passthrough, I'm still working the
>>>>> non-PCI one. Please don't drop my name.
>>>>
>>>>
>>>>
>>>> I thought that Arianna's patches had taken care of that (the MMIO
>>>> part?). Or does each platform need a different implementation of
>>>> that?
>>>
>>>
>>>
>>> To passthrough a platform device you need to be able to assign the device
>>> to
>>> the guest via the IOMMU and map MMIOs (done by Arianna's series) and
>>> interrupts.
>>>
>> For a PCI passthrough SMMU ops are to be added. The way the smmu for a
>> pci device is found needs to be updated in the smmu.c, so there are
>> some substantial changes to smmu.c for pci passthrough.
>
>
> The SMMU drivers in Linux already supports PCI. As I'm currently resync our
> driver with this version PCI assignment in the SMMU should come freely.
>
> I expect the only plumbing for the Xen callback and few bugs fixes will be
> necessary.
>
we can discuss more on design level. There are changes
>> Also MMIO mapping code the same pci device to be added.
>
>
> Hmmm? What do you mean? MMIO mapping code is definitely not part of the SMMU
> drivers.
>
> IIRC, this should be done by either the toolstack or PCI back in Linux.
>
>> So in short there changes, and as they are in the same files and
>> features are also similar,  is it possible that we work together may
>> be julien can provide a design document (simple txt file would do).
>
>
> There is no need of design document for the SMMU drivers. Everything for DT
> passthrough is already there.
>
It would be helpful if you can provide a basic flow.
>> I
>>
>> have already shared mine in another mail thread with stefano.
>
>
> Could you send a link to this mail?
[RFC + Queries] Flow of PCI passthrough in ARM
>
> Regards,
>
> --
> Julien Grall
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 03 05:08:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 05:08:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xl9sM-00062U-TK; Mon, 03 Nov 2014 05:08:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1Xl9sL-00062O-6M
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 05:08:21 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	ED/C2-02698-4CD07545; Mon, 03 Nov 2014 05:08:20 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1414991298!12106985!1
X-Originating-IP: [209.85.220.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30272 invoked from network); 3 Nov 2014 05:08:19 -0000
Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com)
	(209.85.220.180)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 05:08:19 -0000
Received: by mail-vc0-f180.google.com with SMTP id hy10so5450932vcb.11
	for <xen-devel@lists.xenproject.org>;
	Sun, 02 Nov 2014 21:08:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Xuzq/ssUK7O1yMQLkOLWRbnkevaqiBoPe6x5gVwGkR8=;
	b=BbHIHca7QMrF9m5YgjSbhNgMxIihzeDp6CHW3FcHZKMWS7gAhYty3D4O4hcx9+Yfal
	dpR+moTcyyjgCDoOv1l73pLsVqsEOsB35nUCoB/IcVpA0w+B29tEq/x850UicEgzay21
	N/7aa/eqnBxGXqaXwFeb0q9YWBFW2Pv0bCNrL6/oOMjBqSEVArGnz1/zSiSYiVz3u757
	4Le68Huo8HxxGa+QLrd0K2Ubooe/EVVR9vi0K51BOLk4T8kXD9LOyjl6QFwlL2hJc/zw
	gd1bhj4fWAm6K9Kfwa2QjqwghiBBrt5frsGTNqod2tPrfHAxoqGFD2fkj6UkQB+kf97e
	B4cQ==
MIME-Version: 1.0
X-Received: by 10.220.16.70 with SMTP id n6mr202161vca.36.1414991298434; Sun,
	02 Nov 2014 21:08:18 -0800 (PST)
Received: by 10.221.57.8 with HTTP; Sun, 2 Nov 2014 21:08:18 -0800 (PST)
In-Reply-To: <545604CF.60905@linaro.org>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<CAAiw7J=Mbb1YGYj=XQv6TmqyAMvcctUs7AvHQN_1O27xCRSp_Q@mail.gmail.com>
	<20141031142403.GA6913@laptop.dumpdata.com>
	<54539D4D.1040108@linaro.org>
	<20141031210156.GA20039@laptop.dumpdata.com>
	<54551BDD.5080800@linaro.org>
	<CAAiw7J=0RbBwTJUS8AP9V88r7D+iKGjMpfF4rH_EOKi1GwBWMw@mail.gmail.com>
	<545604CF.60905@linaro.org>
Date: Mon, 3 Nov 2014 10:38:18 +0530
Message-ID: <CAAiw7J=PvYq6s_DQ0gyaZx8gs_Xw2Z-X1BpKe6a3KwhNTkd+Uw@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>, manish.jaggi@caviumnetworks.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ARM] SMMU and PCI passthrough Was: Re: Xen 4.5-rc1
 update (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2 November 2014 15:47, Julien Grall <julien.grall@linaro.org> wrote:
> (Renaming the subject of the thread).
>
> On 02/11/2014 06:03, manish jaggi wrote:
>>
>> On 1 November 2014 23:13, Julien Grall <julien.grall@linaro.org> wrote:
>>>
>>> Hi Konrad,
>>>
>>>
>>> On 31/10/2014 21:01, Konrad Rzeszutek Wilk wrote:
>>>>
>>>>
>>>> On Fri, Oct 31, 2014 at 02:31:41PM +0000, Julien Grall wrote:
>>>>>
>>>>>
>>>>> On 10/31/2014 02:24 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> *  PVH - PCI passthrough for DomU.
>>>>>>>
>>>>>>>
>>>>>>> I am working on Cavium Thunder (ARM64) on this feature.
>>>>>>> [Xen SMMU driver changes + PCI passthrough changes in Xen and Linux]
>>>>>
>>>>>
>>>>>
>>>>> FYI, I'm currently reworking the SMMU drivers to resync with Linux.
>>>>> With
>>>>> thoses changes, you should not need to modify the SMMU code.
>>>>
>>>>
>>>>
>>>> Thank you for the update. Put your name behind that for 4.6.
>>>>>
>>>>>
>>>>>
>>>>>> Ok, replaced Julien's name with yours. Please make sure
>>>>>> that for the Linux patches you CC xen-devel and the
>>>>>> maintainers (David, Stefano, Boris and me).
>>>>>
>>>>>
>>>>>
>>>>> There is 2 distinct passthrough: platform (i.e non-PCI) and PCI one.
>>>>>
>>>>> While Manish is working on PCI passthrough, I'm still working the
>>>>> non-PCI one. Please don't drop my name.
>>>>
>>>>
>>>>
>>>> I thought that Arianna's patches had taken care of that (the MMIO
>>>> part?). Or does each platform need a different implementation of
>>>> that?
>>>
>>>
>>>
>>> To passthrough a platform device you need to be able to assign the device
>>> to
>>> the guest via the IOMMU and map MMIOs (done by Arianna's series) and
>>> interrupts.
>>>
>> For a PCI passthrough SMMU ops are to be added. The way the smmu for a
>> pci device is found needs to be updated in the smmu.c, so there are
>> some substantial changes to smmu.c for pci passthrough.
>
>
> The SMMU drivers in Linux already supports PCI. As I'm currently resync our
> driver with this version PCI assignment in the SMMU should come freely.
>
> I expect the only plumbing for the Xen callback and few bugs fixes will be
> necessary.
>
we can discuss more on design level. There are changes
>> Also MMIO mapping code the same pci device to be added.
>
>
> Hmmm? What do you mean? MMIO mapping code is definitely not part of the SMMU
> drivers.
>
> IIRC, this should be done by either the toolstack or PCI back in Linux.
>
>> So in short there changes, and as they are in the same files and
>> features are also similar,  is it possible that we work together may
>> be julien can provide a design document (simple txt file would do).
>
>
> There is no need of design document for the SMMU drivers. Everything for DT
> passthrough is already there.
>
It would be helpful if you can provide a basic flow.
>> I
>>
>> have already shared mine in another mail thread with stefano.
>
>
> Could you send a link to this mail?
[RFC + Queries] Flow of PCI passthrough in ARM
>
> Regards,
>
> --
> Julien Grall
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 03 05:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 05:49:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlAVo-0006fZ-6z; Mon, 03 Nov 2014 05:49:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlAVn-0006fR-8c
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 05:49:07 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F5/73-17958-25717545; Mon, 03 Nov 2014 05:49:06 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1414993744!11167419!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 916 invoked from network); 3 Nov 2014 05:49:05 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 05:49:05 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 02 Nov 2014 21:49:03 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="625267247"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga002.fm.intel.com with ESMTP; 02 Nov 2014 21:49:00 -0800
Message-ID: <5457174C.8020400@intel.com>
Date: Mon, 03 Nov 2014 13:49:00 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Kevin Tian <kevin.tian@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
In-Reply-To: <545354500200007800043D94@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/31 16:20, Jan Beulich wrote:
>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>   From: Chen, Tiejun
>>> Sent: Friday, October 31, 2014 1:41 PM
>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>> Thinking about this some more, this odd universal hole punching in
>>>> the E820 is very likely to end up causing problems. Hence I think
>>>> this really should be optional behavior, with pass through of devices
>>>> associated with RMRRs failing if not used. (This ought to include
>>>> punching holes for _just_ the devices passed through to a guest
>>>> upon creation when the option is not enabled.)
>>>
>>> Yeah, we had a similar discussion internal to add a parameter to force
>>> reserving RMRR. In this case we can't create a VM if these ranges
>>> conflict with anything. So what about this idea?
>>>
>>
>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>> approach. When the parameter is on, RMRR check/hole punch is
>> activated at VM creation. Otherwise we just keep existing behavior.
>>
>> If user configures device pass-through at creation time, this parameter
>> will be set by default. If user wants the VM capable of device hot-plug,
>> an explicit parameter can be added in the config file to enforce RMRR
>> check at creation time.
>
> Not exactly, I specifically described it slightly differently above. When
> devices get passed through and the option is absent, holes should be
> punched only for the RMRRs associated with those devices (i.e.
> ideally none). Of course this means we'll need a way to associate
> RMRRs with devices in the tool stack and hvmloader, i.e. the current
> XENMEM_reserved_device_memory_map alone won't suffice.

Yeah, current hypercall just provide RMRR entries without that 
associated BDF. And especially, in some cases one range may be shared by 
multiple devices...

So anyway, let me be clear something here before we step next. Firstly 
I'm wondering if you will refine that patch to achieve our requirement 
by yourself since looks you'd like to maintain that patch, or I should 
do this? And of course we can walk another way, like xenstore as Yang 
suggested previously.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 05:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 05:49:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlAVo-0006fZ-6z; Mon, 03 Nov 2014 05:49:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlAVn-0006fR-8c
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 05:49:07 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F5/73-17958-25717545; Mon, 03 Nov 2014 05:49:06 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1414993744!11167419!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 916 invoked from network); 3 Nov 2014 05:49:05 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 05:49:05 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 02 Nov 2014 21:49:03 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="625267247"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga002.fm.intel.com with ESMTP; 02 Nov 2014 21:49:00 -0800
Message-ID: <5457174C.8020400@intel.com>
Date: Mon, 03 Nov 2014 13:49:00 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Kevin Tian <kevin.tian@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
In-Reply-To: <545354500200007800043D94@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/31 16:20, Jan Beulich wrote:
>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>   From: Chen, Tiejun
>>> Sent: Friday, October 31, 2014 1:41 PM
>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>> Thinking about this some more, this odd universal hole punching in
>>>> the E820 is very likely to end up causing problems. Hence I think
>>>> this really should be optional behavior, with pass through of devices
>>>> associated with RMRRs failing if not used. (This ought to include
>>>> punching holes for _just_ the devices passed through to a guest
>>>> upon creation when the option is not enabled.)
>>>
>>> Yeah, we had a similar discussion internal to add a parameter to force
>>> reserving RMRR. In this case we can't create a VM if these ranges
>>> conflict with anything. So what about this idea?
>>>
>>
>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>> approach. When the parameter is on, RMRR check/hole punch is
>> activated at VM creation. Otherwise we just keep existing behavior.
>>
>> If user configures device pass-through at creation time, this parameter
>> will be set by default. If user wants the VM capable of device hot-plug,
>> an explicit parameter can be added in the config file to enforce RMRR
>> check at creation time.
>
> Not exactly, I specifically described it slightly differently above. When
> devices get passed through and the option is absent, holes should be
> punched only for the RMRRs associated with those devices (i.e.
> ideally none). Of course this means we'll need a way to associate
> RMRRs with devices in the tool stack and hvmloader, i.e. the current
> XENMEM_reserved_device_memory_map alone won't suffice.

Yeah, current hypercall just provide RMRR entries without that 
associated BDF. And especially, in some cases one range may be shared by 
multiple devices...

So anyway, let me be clear something here before we step next. Firstly 
I'm wondering if you will refine that patch to achieve our requirement 
by yourself since looks you'd like to maintain that patch, or I should 
do this? And of course we can walk another way, like xenstore as Yang 
suggested previously.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:13:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlAtM-0007AX-L9; Mon, 03 Nov 2014 06:13:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XlAtK-0007AC-Df
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 06:13:26 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	3B/E0-02954-50D17545; Mon, 03 Nov 2014 06:13:25 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1414995202!12121200!1
X-Originating-IP: [209.85.192.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18417 invoked from network); 3 Nov 2014 06:13:24 -0000
Received: from mail-pd0-f176.google.com (HELO mail-pd0-f176.google.com)
	(209.85.192.176)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 06:13:24 -0000
Received: by mail-pd0-f176.google.com with SMTP id ft15so10897367pdb.35
	for <xen-devel@lists.xen.org>; Sun, 02 Nov 2014 22:13:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=n1bpsL1/5C+7GS4YcoELSpkR+1WY6xmlxbqGPrm6dBY=;
	b=IArYGm3jTCgwMfTzctmFoAXNOQ+KAeBkTXB+RcpLSPIA6Ooylaqlz6fw9M+f3PKhmc
	aa16asBCci6D7xNLoXdPIyZ7mCoVmggEh6LgTBsEbyWit7BkoVlN7UzCTm5PxIr11bf0
	9Zk/egB65iSKlSw+NuDv4cNaPfpnTtQQm1QyGKwMHSlrt9w34MUcI77i1X/8gK1VLyt1
	SX+jQE+iUS0eq3Xlim48KrE7br7hMSFSqMUlwW1rfH6mH1OQBlW4u+e80AOjTo8Qqqlr
	9qzZDyQsHQ3vjxOwHKkKZOLSPY/2CuizzyJ2De2LWVJt9QuzQYCjw+jh4ujPRYMAFBcd
	wIOg==
X-Gm-Message-State: ALoCoQl6rbOkBubcG+soKuUcActt3gZ7SSZCWyNDyKe156bt1lAJ/LiFbaQ+2LlT8sqRWQUQHvCe
X-Received: by 10.70.36.132 with SMTP id q4mr19519994pdj.8.1414995202521;
	Sun, 02 Nov 2014 22:13:22 -0800 (PST)
Received: from rfranz-i7.local (c-24-10-97-91.hsd1.ca.comcast.net.
	[24.10.97.91]) by mx.google.com with ESMTPSA id
	kp2sm16112637pdb.30.2014.11.02.22.13.20 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 02 Nov 2014 22:13:21 -0800 (PST)
From: Roy Franz <roy.franz@linaro.org>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com, tim@xen.org, jbeulich@suse.com
Date: Sun,  2 Nov 2014 22:13:10 -0800
Message-Id: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
X-Mailer: git-send-email 1.9.1
Cc: Roy Franz <roy.franz@linaro.org>, daniel.kiper@oracle.com,
	fu.wei@linaro.org
Subject: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
	skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 EFI code to completely ignore the EFI comnandline when booted from GRUB.
Previusly it was parsed of EFI boot specific options, but these aren't used
when booted from GRUB.

Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
code does some console and video initialization to support native EFI boot from
the EFI boot manager or EFI shell.  This initlization should not be done when
booted using GRUB.

Update EFI documentation to indicate that it describes EFI native boot, and
does not apply at all when Xen is booted using GRUB.

Signed-off-by: Roy Franz <roy.franz@linaro.org>
---
This patch implements what I understand to be the desired behavior when booting
an EFI Xen image via GRUB based on the thread last week.  The EFI command line
is not used, and the Xen commandline comes via the multiboot protocol (and
in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
GRUB EFI boot cases into alignment in not using the EFI commandline.

The current state of the arm64 code takes the Xen commandline from the FDT,
but still looks in the EFI commandline for EFI boot specific options.  If
unexpected options are passed in the EFI commandline, it will generate
"unrecognized option" ouput for all unexpected options.

I think this should be considered for 4.5.


 docs/misc/efi.markdown |   5 ++
 xen/common/efi/boot.c  | 237 +++++++++++++++++++++++++------------------------
 2 files changed, 125 insertions(+), 117 deletions(-)

diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
index 5e48aa3..f435ec7 100644
--- a/docs/misc/efi.markdown
+++ b/docs/misc/efi.markdown
@@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
 (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
 try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
 order.) One can override this with a command line option (`-cfg=<filename>`).
+This configuration file and EFI commandline are only used for booting directly
+from EFI firmware, or when using an EFI loader that does not support
+the multiboot2 protocol.  When booting using GRUB or another multiboot aware
+loader the EFI commandline is ignored and all information is passed from
+the loader to Xen using the multiboot protocol.
 
 The configuration file consists of one or more sections headed by a section
 name enclosed in square brackets, with individual values specified in each
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 4257341..26e3cc8 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -705,6 +705,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     union string section = { NULL }, name;
     bool_t base_video = 0;
     char *option_str;
+    bool_t use_cfg_file;
 
     efi_ih = ImageHandle;
     efi_bs = SystemTable->BootServices;
@@ -717,6 +718,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     StdOut = SystemTable->ConOut;
     StdErr = SystemTable->StdErr ?: StdOut;
+    use_cfg_file = efi_arch_use_config_file(SystemTable);
 
     status = efi_bs->HandleProtocol(ImageHandle, &loaded_image_guid,
                                     (void **)&loaded_image);
@@ -725,67 +727,70 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_load_addr_check(loaded_image);
 
-    argc = get_argv(0, NULL, loaded_image->LoadOptions,
-                    loaded_image->LoadOptionsSize, NULL);
-    if ( argc > 0 &&
-         efi_bs->AllocatePool(EfiLoaderData,
-                              (argc + 1) * sizeof(*argv) +
-                                  loaded_image->LoadOptionsSize,
-                              (void **)&argv) == EFI_SUCCESS )
-        get_argv(argc, argv, loaded_image->LoadOptions,
-                 loaded_image->LoadOptionsSize, &options);
-    else
-        argc = 0;
-    for ( i = 1; i < argc; ++i )
+    if ( use_cfg_file )
     {
-        CHAR16 *ptr = argv[i];
-
-        if ( !ptr )
-            break;
-        if ( *ptr == L'/' || *ptr == L'-' )
+        argc = get_argv(0, NULL, loaded_image->LoadOptions,
+                        loaded_image->LoadOptionsSize, NULL);
+        if ( argc > 0 &&
+             efi_bs->AllocatePool(EfiLoaderData,
+                                  (argc + 1) * sizeof(*argv) +
+                                      loaded_image->LoadOptionsSize,
+                                  (void **)&argv) == EFI_SUCCESS )
+            get_argv(argc, argv, loaded_image->LoadOptions,
+                     loaded_image->LoadOptionsSize, &options);
+        else
+            argc = 0;
+        for ( i = 1; i < argc; ++i )
         {
-            if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
-                base_video = 1;
-            else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
-                cfg_file_name = ptr + 5;
-            else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
-                cfg_file_name = argv[++i];
-            else if ( wstrcmp(ptr + 1, L"help") == 0 ||
-                      (ptr[1] == L'?' && !ptr[2]) )
+            CHAR16 *ptr = argv[i];
+
+            if ( !ptr )
+                break;
+            if ( *ptr == L'/' || *ptr == L'-' )
             {
-                PrintStr(L"Xen EFI Loader options:\r\n");
-                PrintStr(L"-basevideo   retain current video mode\r\n");
-                PrintStr(L"-cfg=<file>  specify configuration file\r\n");
-                PrintStr(L"-help, -?    display this help\r\n");
-                blexit(NULL);
+                if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
+                    base_video = 1;
+                else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
+                    cfg_file_name = ptr + 5;
+                else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
+                    cfg_file_name = argv[++i];
+                else if ( wstrcmp(ptr + 1, L"help") == 0 ||
+                          (ptr[1] == L'?' && !ptr[2]) )
+                {
+                    PrintStr(L"Xen EFI Loader options:\r\n");
+                    PrintStr(L"-basevideo   retain current video mode\r\n");
+                    PrintStr(L"-cfg=<file>  specify configuration file\r\n");
+                    PrintStr(L"-help, -?    display this help\r\n");
+                    blexit(NULL);
+                }
+                else
+                {
+                    PrintStr(L"WARNING: Unknown command line option '");
+                    PrintStr(ptr);
+                    PrintStr(L"' ignored\r\n");
+                }
             }
             else
-            {
-                PrintStr(L"WARNING: Unknown command line option '");
-                PrintStr(ptr);
-                PrintStr(L"' ignored\r\n");
-            }
+                section.w = ptr;
         }
-        else
-            section.w = ptr;
-    }
 
-    if ( !base_video )
-    {
-        unsigned int best;
-
-        for ( i = 0, size = 0, best = StdOut->Mode->Mode;
-              i < StdOut->Mode->MaxMode; ++i )
+        if ( !base_video )
         {
-            if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
-                 cols * rows > size )
+            unsigned int best;
+
+            for ( i = 0, size = 0, best = StdOut->Mode->Mode;
+                  i < StdOut->Mode->MaxMode; ++i )
             {
-                size = cols * rows;
-                best = i;
+                if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
+                     cols * rows > size )
+                {
+                    size = cols * rows;
+                    best = i;
+                }
             }
+            if ( best != StdOut->Mode->Mode )
+                StdOut->SetMode(StdOut, best);
         }
-        if ( best != StdOut->Mode->Mode )
-            StdOut->SetMode(StdOut, best);
     }
 
     PrintStr(L"Xen " __stringify(XEN_VERSION) "." __stringify(XEN_SUBVERSION)
@@ -793,37 +798,37 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_relocate_image(0);
 
-    if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
-                           &cols, &rows) == EFI_SUCCESS )
-        efi_arch_console_init(cols, rows);
-
-    size = 0;
-    status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
-    if ( status == EFI_BUFFER_TOO_SMALL )
-        status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
-    if ( !EFI_ERROR(status) )
-        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
-                                      handles);
-    if ( EFI_ERROR(status) )
-        size = 0;
-    for ( i = 0; i < size / sizeof(*handles); ++i )
-    {
-        status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
-        if ( EFI_ERROR(status) )
-            continue;
-        status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
-        if ( !EFI_ERROR(status) )
-            break;
-    }
-    if ( handles )
-        efi_bs->FreePool(handles);
-    if ( EFI_ERROR(status) )
-        gop = NULL;
-
-    cols = rows = depth = 0;
-    if ( efi_arch_use_config_file(SystemTable) )
+    if ( use_cfg_file )
     {
         EFI_FILE_HANDLE dir_handle;
+        size = 0;
+        cols = rows = depth = 0;
+
+        if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
+                               &cols, &rows) == EFI_SUCCESS )
+            efi_arch_console_init(cols, rows);
+
+        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
+        if ( status == EFI_BUFFER_TOO_SMALL )
+            status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
+        if ( !EFI_ERROR(status) )
+            status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
+                                          handles);
+        if ( EFI_ERROR(status) )
+            size = 0;
+        for ( i = 0; i < size / sizeof(*handles); ++i )
+        {
+            status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
+            if ( EFI_ERROR(status) )
+                continue;
+            status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
+            if ( !EFI_ERROR(status) )
+                break;
+        }
+        if ( handles )
+            efi_bs->FreePool(handles);
+        if ( EFI_ERROR(status) )
+            gop = NULL;
 
         /* Get the file system interface. */
         dir_handle = get_parent_handle(loaded_image, &file_name);
@@ -931,49 +936,47 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
         dir_handle->Close(dir_handle);
 
-    }
-
-    if ( gop && !base_video )
-    {
-        for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
+        if ( gop && !base_video )
         {
-            unsigned int bpp = 0;
-
-            status = gop->QueryMode(gop, i, &info_size, &mode_info);
-            if ( EFI_ERROR(status) )
-                continue;
-            switch ( mode_info->PixelFormat )
+            for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
             {
-            case PixelBitMask:
-                bpp = hweight32(mode_info->PixelInformation.RedMask |
-                                mode_info->PixelInformation.GreenMask |
-                                mode_info->PixelInformation.BlueMask);
-                break;
-            case PixelRedGreenBlueReserved8BitPerColor:
-            case PixelBlueGreenRedReserved8BitPerColor:
-                bpp = 24;
-                break;
-            default:
-                continue;
-            }
-            if ( cols == mode_info->HorizontalResolution &&
-                 rows == mode_info->VerticalResolution &&
-                 (!depth || bpp == depth) )
-            {
-                gop_mode = i;
-                break;
-            }
-            if ( !cols && !rows &&
-                 mode_info->HorizontalResolution *
-                 mode_info->VerticalResolution > size )
-            {
-                size = mode_info->HorizontalResolution *
-                       mode_info->VerticalResolution;
-                gop_mode = i;
+                unsigned int bpp = 0;
+
+                status = gop->QueryMode(gop, i, &info_size, &mode_info);
+                if ( EFI_ERROR(status) )
+                    continue;
+                switch ( mode_info->PixelFormat )
+                {
+                case PixelBitMask:
+                    bpp = hweight32(mode_info->PixelInformation.RedMask |
+                                    mode_info->PixelInformation.GreenMask |
+                                    mode_info->PixelInformation.BlueMask);
+                    break;
+                case PixelRedGreenBlueReserved8BitPerColor:
+                case PixelBlueGreenRedReserved8BitPerColor:
+                    bpp = 24;
+                    break;
+                default:
+                    continue;
+                }
+                if ( cols == mode_info->HorizontalResolution &&
+                     rows == mode_info->VerticalResolution &&
+                     (!depth || bpp == depth) )
+                {
+                    gop_mode = i;
+                    break;
+                }
+                if ( !cols && !rows &&
+                     mode_info->HorizontalResolution *
+                     mode_info->VerticalResolution > size )
+                {
+                    size = mode_info->HorizontalResolution *
+                           mode_info->VerticalResolution;
+                    gop_mode = i;
+                }
             }
         }
     }
-
     efi_arch_edd();
 
     /* XXX Collect EDID info. */
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:13:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlAtM-0007AX-L9; Mon, 03 Nov 2014 06:13:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XlAtK-0007AC-Df
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 06:13:26 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	3B/E0-02954-50D17545; Mon, 03 Nov 2014 06:13:25 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1414995202!12121200!1
X-Originating-IP: [209.85.192.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18417 invoked from network); 3 Nov 2014 06:13:24 -0000
Received: from mail-pd0-f176.google.com (HELO mail-pd0-f176.google.com)
	(209.85.192.176)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 06:13:24 -0000
Received: by mail-pd0-f176.google.com with SMTP id ft15so10897367pdb.35
	for <xen-devel@lists.xen.org>; Sun, 02 Nov 2014 22:13:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=n1bpsL1/5C+7GS4YcoELSpkR+1WY6xmlxbqGPrm6dBY=;
	b=IArYGm3jTCgwMfTzctmFoAXNOQ+KAeBkTXB+RcpLSPIA6Ooylaqlz6fw9M+f3PKhmc
	aa16asBCci6D7xNLoXdPIyZ7mCoVmggEh6LgTBsEbyWit7BkoVlN7UzCTm5PxIr11bf0
	9Zk/egB65iSKlSw+NuDv4cNaPfpnTtQQm1QyGKwMHSlrt9w34MUcI77i1X/8gK1VLyt1
	SX+jQE+iUS0eq3Xlim48KrE7br7hMSFSqMUlwW1rfH6mH1OQBlW4u+e80AOjTo8Qqqlr
	9qzZDyQsHQ3vjxOwHKkKZOLSPY/2CuizzyJ2De2LWVJt9QuzQYCjw+jh4ujPRYMAFBcd
	wIOg==
X-Gm-Message-State: ALoCoQl6rbOkBubcG+soKuUcActt3gZ7SSZCWyNDyKe156bt1lAJ/LiFbaQ+2LlT8sqRWQUQHvCe
X-Received: by 10.70.36.132 with SMTP id q4mr19519994pdj.8.1414995202521;
	Sun, 02 Nov 2014 22:13:22 -0800 (PST)
Received: from rfranz-i7.local (c-24-10-97-91.hsd1.ca.comcast.net.
	[24.10.97.91]) by mx.google.com with ESMTPSA id
	kp2sm16112637pdb.30.2014.11.02.22.13.20 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 02 Nov 2014 22:13:21 -0800 (PST)
From: Roy Franz <roy.franz@linaro.org>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com, tim@xen.org, jbeulich@suse.com
Date: Sun,  2 Nov 2014 22:13:10 -0800
Message-Id: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
X-Mailer: git-send-email 1.9.1
Cc: Roy Franz <roy.franz@linaro.org>, daniel.kiper@oracle.com,
	fu.wei@linaro.org
Subject: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
	skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 EFI code to completely ignore the EFI comnandline when booted from GRUB.
Previusly it was parsed of EFI boot specific options, but these aren't used
when booted from GRUB.

Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
code does some console and video initialization to support native EFI boot from
the EFI boot manager or EFI shell.  This initlization should not be done when
booted using GRUB.

Update EFI documentation to indicate that it describes EFI native boot, and
does not apply at all when Xen is booted using GRUB.

Signed-off-by: Roy Franz <roy.franz@linaro.org>
---
This patch implements what I understand to be the desired behavior when booting
an EFI Xen image via GRUB based on the thread last week.  The EFI command line
is not used, and the Xen commandline comes via the multiboot protocol (and
in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
GRUB EFI boot cases into alignment in not using the EFI commandline.

The current state of the arm64 code takes the Xen commandline from the FDT,
but still looks in the EFI commandline for EFI boot specific options.  If
unexpected options are passed in the EFI commandline, it will generate
"unrecognized option" ouput for all unexpected options.

I think this should be considered for 4.5.


 docs/misc/efi.markdown |   5 ++
 xen/common/efi/boot.c  | 237 +++++++++++++++++++++++++------------------------
 2 files changed, 125 insertions(+), 117 deletions(-)

diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
index 5e48aa3..f435ec7 100644
--- a/docs/misc/efi.markdown
+++ b/docs/misc/efi.markdown
@@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
 (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
 try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
 order.) One can override this with a command line option (`-cfg=<filename>`).
+This configuration file and EFI commandline are only used for booting directly
+from EFI firmware, or when using an EFI loader that does not support
+the multiboot2 protocol.  When booting using GRUB or another multiboot aware
+loader the EFI commandline is ignored and all information is passed from
+the loader to Xen using the multiboot protocol.
 
 The configuration file consists of one or more sections headed by a section
 name enclosed in square brackets, with individual values specified in each
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 4257341..26e3cc8 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -705,6 +705,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     union string section = { NULL }, name;
     bool_t base_video = 0;
     char *option_str;
+    bool_t use_cfg_file;
 
     efi_ih = ImageHandle;
     efi_bs = SystemTable->BootServices;
@@ -717,6 +718,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     StdOut = SystemTable->ConOut;
     StdErr = SystemTable->StdErr ?: StdOut;
+    use_cfg_file = efi_arch_use_config_file(SystemTable);
 
     status = efi_bs->HandleProtocol(ImageHandle, &loaded_image_guid,
                                     (void **)&loaded_image);
@@ -725,67 +727,70 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_load_addr_check(loaded_image);
 
-    argc = get_argv(0, NULL, loaded_image->LoadOptions,
-                    loaded_image->LoadOptionsSize, NULL);
-    if ( argc > 0 &&
-         efi_bs->AllocatePool(EfiLoaderData,
-                              (argc + 1) * sizeof(*argv) +
-                                  loaded_image->LoadOptionsSize,
-                              (void **)&argv) == EFI_SUCCESS )
-        get_argv(argc, argv, loaded_image->LoadOptions,
-                 loaded_image->LoadOptionsSize, &options);
-    else
-        argc = 0;
-    for ( i = 1; i < argc; ++i )
+    if ( use_cfg_file )
     {
-        CHAR16 *ptr = argv[i];
-
-        if ( !ptr )
-            break;
-        if ( *ptr == L'/' || *ptr == L'-' )
+        argc = get_argv(0, NULL, loaded_image->LoadOptions,
+                        loaded_image->LoadOptionsSize, NULL);
+        if ( argc > 0 &&
+             efi_bs->AllocatePool(EfiLoaderData,
+                                  (argc + 1) * sizeof(*argv) +
+                                      loaded_image->LoadOptionsSize,
+                                  (void **)&argv) == EFI_SUCCESS )
+            get_argv(argc, argv, loaded_image->LoadOptions,
+                     loaded_image->LoadOptionsSize, &options);
+        else
+            argc = 0;
+        for ( i = 1; i < argc; ++i )
         {
-            if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
-                base_video = 1;
-            else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
-                cfg_file_name = ptr + 5;
-            else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
-                cfg_file_name = argv[++i];
-            else if ( wstrcmp(ptr + 1, L"help") == 0 ||
-                      (ptr[1] == L'?' && !ptr[2]) )
+            CHAR16 *ptr = argv[i];
+
+            if ( !ptr )
+                break;
+            if ( *ptr == L'/' || *ptr == L'-' )
             {
-                PrintStr(L"Xen EFI Loader options:\r\n");
-                PrintStr(L"-basevideo   retain current video mode\r\n");
-                PrintStr(L"-cfg=<file>  specify configuration file\r\n");
-                PrintStr(L"-help, -?    display this help\r\n");
-                blexit(NULL);
+                if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
+                    base_video = 1;
+                else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
+                    cfg_file_name = ptr + 5;
+                else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
+                    cfg_file_name = argv[++i];
+                else if ( wstrcmp(ptr + 1, L"help") == 0 ||
+                          (ptr[1] == L'?' && !ptr[2]) )
+                {
+                    PrintStr(L"Xen EFI Loader options:\r\n");
+                    PrintStr(L"-basevideo   retain current video mode\r\n");
+                    PrintStr(L"-cfg=<file>  specify configuration file\r\n");
+                    PrintStr(L"-help, -?    display this help\r\n");
+                    blexit(NULL);
+                }
+                else
+                {
+                    PrintStr(L"WARNING: Unknown command line option '");
+                    PrintStr(ptr);
+                    PrintStr(L"' ignored\r\n");
+                }
             }
             else
-            {
-                PrintStr(L"WARNING: Unknown command line option '");
-                PrintStr(ptr);
-                PrintStr(L"' ignored\r\n");
-            }
+                section.w = ptr;
         }
-        else
-            section.w = ptr;
-    }
 
-    if ( !base_video )
-    {
-        unsigned int best;
-
-        for ( i = 0, size = 0, best = StdOut->Mode->Mode;
-              i < StdOut->Mode->MaxMode; ++i )
+        if ( !base_video )
         {
-            if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
-                 cols * rows > size )
+            unsigned int best;
+
+            for ( i = 0, size = 0, best = StdOut->Mode->Mode;
+                  i < StdOut->Mode->MaxMode; ++i )
             {
-                size = cols * rows;
-                best = i;
+                if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
+                     cols * rows > size )
+                {
+                    size = cols * rows;
+                    best = i;
+                }
             }
+            if ( best != StdOut->Mode->Mode )
+                StdOut->SetMode(StdOut, best);
         }
-        if ( best != StdOut->Mode->Mode )
-            StdOut->SetMode(StdOut, best);
     }
 
     PrintStr(L"Xen " __stringify(XEN_VERSION) "." __stringify(XEN_SUBVERSION)
@@ -793,37 +798,37 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_relocate_image(0);
 
-    if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
-                           &cols, &rows) == EFI_SUCCESS )
-        efi_arch_console_init(cols, rows);
-
-    size = 0;
-    status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
-    if ( status == EFI_BUFFER_TOO_SMALL )
-        status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
-    if ( !EFI_ERROR(status) )
-        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
-                                      handles);
-    if ( EFI_ERROR(status) )
-        size = 0;
-    for ( i = 0; i < size / sizeof(*handles); ++i )
-    {
-        status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
-        if ( EFI_ERROR(status) )
-            continue;
-        status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
-        if ( !EFI_ERROR(status) )
-            break;
-    }
-    if ( handles )
-        efi_bs->FreePool(handles);
-    if ( EFI_ERROR(status) )
-        gop = NULL;
-
-    cols = rows = depth = 0;
-    if ( efi_arch_use_config_file(SystemTable) )
+    if ( use_cfg_file )
     {
         EFI_FILE_HANDLE dir_handle;
+        size = 0;
+        cols = rows = depth = 0;
+
+        if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
+                               &cols, &rows) == EFI_SUCCESS )
+            efi_arch_console_init(cols, rows);
+
+        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
+        if ( status == EFI_BUFFER_TOO_SMALL )
+            status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
+        if ( !EFI_ERROR(status) )
+            status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
+                                          handles);
+        if ( EFI_ERROR(status) )
+            size = 0;
+        for ( i = 0; i < size / sizeof(*handles); ++i )
+        {
+            status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
+            if ( EFI_ERROR(status) )
+                continue;
+            status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
+            if ( !EFI_ERROR(status) )
+                break;
+        }
+        if ( handles )
+            efi_bs->FreePool(handles);
+        if ( EFI_ERROR(status) )
+            gop = NULL;
 
         /* Get the file system interface. */
         dir_handle = get_parent_handle(loaded_image, &file_name);
@@ -931,49 +936,47 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
         dir_handle->Close(dir_handle);
 
-    }
-
-    if ( gop && !base_video )
-    {
-        for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
+        if ( gop && !base_video )
         {
-            unsigned int bpp = 0;
-
-            status = gop->QueryMode(gop, i, &info_size, &mode_info);
-            if ( EFI_ERROR(status) )
-                continue;
-            switch ( mode_info->PixelFormat )
+            for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
             {
-            case PixelBitMask:
-                bpp = hweight32(mode_info->PixelInformation.RedMask |
-                                mode_info->PixelInformation.GreenMask |
-                                mode_info->PixelInformation.BlueMask);
-                break;
-            case PixelRedGreenBlueReserved8BitPerColor:
-            case PixelBlueGreenRedReserved8BitPerColor:
-                bpp = 24;
-                break;
-            default:
-                continue;
-            }
-            if ( cols == mode_info->HorizontalResolution &&
-                 rows == mode_info->VerticalResolution &&
-                 (!depth || bpp == depth) )
-            {
-                gop_mode = i;
-                break;
-            }
-            if ( !cols && !rows &&
-                 mode_info->HorizontalResolution *
-                 mode_info->VerticalResolution > size )
-            {
-                size = mode_info->HorizontalResolution *
-                       mode_info->VerticalResolution;
-                gop_mode = i;
+                unsigned int bpp = 0;
+
+                status = gop->QueryMode(gop, i, &info_size, &mode_info);
+                if ( EFI_ERROR(status) )
+                    continue;
+                switch ( mode_info->PixelFormat )
+                {
+                case PixelBitMask:
+                    bpp = hweight32(mode_info->PixelInformation.RedMask |
+                                    mode_info->PixelInformation.GreenMask |
+                                    mode_info->PixelInformation.BlueMask);
+                    break;
+                case PixelRedGreenBlueReserved8BitPerColor:
+                case PixelBlueGreenRedReserved8BitPerColor:
+                    bpp = 24;
+                    break;
+                default:
+                    continue;
+                }
+                if ( cols == mode_info->HorizontalResolution &&
+                     rows == mode_info->VerticalResolution &&
+                     (!depth || bpp == depth) )
+                {
+                    gop_mode = i;
+                    break;
+                }
+                if ( !cols && !rows &&
+                     mode_info->HorizontalResolution *
+                     mode_info->VerticalResolution > size )
+                {
+                    size = mode_info->HorizontalResolution *
+                           mode_info->VerticalResolution;
+                    gop_mode = i;
+                }
             }
         }
     }
-
     efi_arch_edd();
 
     /* XXX Collect EDID info. */
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:20:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlAzp-0007Ms-KN; Mon, 03 Nov 2014 06:20:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlAzo-0007Mn-DW
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 06:20:08 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	D2/F6-17958-79E17545; Mon, 03 Nov 2014 06:20:07 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1414995604!11117507!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11883 invoked from network); 3 Nov 2014 06:20:06 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-12.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 06:20:06 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 02 Nov 2014 22:18:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="630128904"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by orsmga002.jf.intel.com with ESMTP; 02 Nov 2014 22:20:02 -0800
Message-ID: <54571E91.4030903@intel.com>
Date: Mon, 03 Nov 2014 14:20:01 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, tim@xen.org
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
In-Reply-To: <545355720200007800043D97@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/31 16:25, Jan Beulich wrote:
>>>> On 31.10.14 at 03:50, <tiejun.chen@intel.com> wrote:
>> On 2014/10/30 17:24, Jan Beulich wrote:
>>>>>> On 30.10.14 at 08:39, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/29 17:20, Jan Beulich wrote:
>>>>> Getting closer. Just set a to p2m->default_access before the if(),
>>>>> and overwrite it when rc == 1 inside the if(). And properly handle
>>>>> the error case (just logging a message - which btw lacks a proper
>>>>> XENLOG_G_* prefix - doesn't seem enough to me).
>>>>
>>>> Please check the follows:
>>>>
>>>> @@ -686,8 +686,22 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>>>         /* Now, actually do the two-way mapping */
>>>>         if ( mfn_valid(_mfn(mfn)) )
>>>>         {
>>>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>>>> -                           p2m->default_access);
>>>> +        rc = 0;
>>>> +        a =  p2m->default_access;
>>>> +        if ( !is_hardware_domain(d) )
>>>> +        {
>>>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>>>> +                                                  &gfn);
>>>> +            /* We need to set reserved device memory as p2m_access_n. */
>>>> +            if ( rc == 1 )
>>>> +                a = p2m_access_n;
>>>> +            else if ( rc < 0 )
>>>> +                printk(XENLOG_WARNING
>>>> +                       "Domain %d can't check reserved device memory.\n",
>>>> +                       d->domain_id);
>>>> +        }
>>>> +
>>>> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
>>>>             if ( rc )
>>>>                 goto out; /* Failed to update p2m, bail without updating m2p.
>> */
>>>
>>> The handling of "a" looks good now, but the error handling and
>>> logging is still as broken as it was before.
>>
>> Do you mean I'm missing some necessary info? Like gfn and mfn, so domain
>> id, gfn and mfn can show enough message.
>>
>> Sorry I'm poor to understand what you expect.
>
> But I explained it already, and that explanation is still visible in
> the quotes above. But to avoid any doubt, I'll repeat: "And

I tried to understand what you said but felt a confusion so ask if you 
show me directly.

> properly handle the error case (just logging a message - which
> btw lacks a proper XENLOG_G_* prefix - doesn't seem enough
> to me)."

Looks there are two problems:

#1: the error message

If current line is not fine,
	printk(XENLOG_G_WARNING "Domain %d can't check reserved device 
memory.\n", d->domain_id);

I mean could you change this directly.

#2 the error handling

In an error case what should I do? Currently we still create these 
mapping as normal. This means these mfns will be valid so later we can't 
set them again then device can't be assigned as passthrough. I think 
this makes sense. Or we should just stop them from setting 1:1 mapping?

>
>>>>> But then again this code may change altogether if you avoid
>>>>> populating the reserved regions in the first place.
>>>>
>>>> Are you saying this scenario?
>>>>
>>>> #1 Here we first set these ranges as p2m_access_n
>>>> #2 We reset them as 1:1 RMRR mapping with p2m_access_rw somewhere
>>>> #3 Someone may try to populate these ranges again
>>>
>>> No. I pointed at the fact that if you avoid populating the holes,
>>> there's no need to force them to p2m_access_n. Any attempts
>>> to map other than the 1:1 thing there could then simply be
>>> rejected.
>>
>> I think any population should be rejected totally, because 1:1 mapping
>> means guest can access these RMRR ranges in case of no any device
>> assignment with RMRR, right? Any access to these range corrupt the real
>> device usage.
>
> Oh yes, of course I implied that the 1:1 mapping would be
> permitted only for those ranges where the RMRR corresponds
> to a device the guest got assigned.
>

Yeah.

Tim,

Please take a look at this, and I hope this can make sure we'll be the 
same page finally :)

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:20:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlAzp-0007Ms-KN; Mon, 03 Nov 2014 06:20:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlAzo-0007Mn-DW
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 06:20:08 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	D2/F6-17958-79E17545; Mon, 03 Nov 2014 06:20:07 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1414995604!11117507!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11883 invoked from network); 3 Nov 2014 06:20:06 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-12.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 06:20:06 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 02 Nov 2014 22:18:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="630128904"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by orsmga002.jf.intel.com with ESMTP; 02 Nov 2014 22:20:02 -0800
Message-ID: <54571E91.4030903@intel.com>
Date: Mon, 03 Nov 2014 14:20:01 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, tim@xen.org
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
In-Reply-To: <545355720200007800043D97@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/31 16:25, Jan Beulich wrote:
>>>> On 31.10.14 at 03:50, <tiejun.chen@intel.com> wrote:
>> On 2014/10/30 17:24, Jan Beulich wrote:
>>>>>> On 30.10.14 at 08:39, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/29 17:20, Jan Beulich wrote:
>>>>> Getting closer. Just set a to p2m->default_access before the if(),
>>>>> and overwrite it when rc == 1 inside the if(). And properly handle
>>>>> the error case (just logging a message - which btw lacks a proper
>>>>> XENLOG_G_* prefix - doesn't seem enough to me).
>>>>
>>>> Please check the follows:
>>>>
>>>> @@ -686,8 +686,22 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>>>         /* Now, actually do the two-way mapping */
>>>>         if ( mfn_valid(_mfn(mfn)) )
>>>>         {
>>>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>>>> -                           p2m->default_access);
>>>> +        rc = 0;
>>>> +        a =  p2m->default_access;
>>>> +        if ( !is_hardware_domain(d) )
>>>> +        {
>>>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>>>> +                                                  &gfn);
>>>> +            /* We need to set reserved device memory as p2m_access_n. */
>>>> +            if ( rc == 1 )
>>>> +                a = p2m_access_n;
>>>> +            else if ( rc < 0 )
>>>> +                printk(XENLOG_WARNING
>>>> +                       "Domain %d can't check reserved device memory.\n",
>>>> +                       d->domain_id);
>>>> +        }
>>>> +
>>>> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
>>>>             if ( rc )
>>>>                 goto out; /* Failed to update p2m, bail without updating m2p.
>> */
>>>
>>> The handling of "a" looks good now, but the error handling and
>>> logging is still as broken as it was before.
>>
>> Do you mean I'm missing some necessary info? Like gfn and mfn, so domain
>> id, gfn and mfn can show enough message.
>>
>> Sorry I'm poor to understand what you expect.
>
> But I explained it already, and that explanation is still visible in
> the quotes above. But to avoid any doubt, I'll repeat: "And

I tried to understand what you said but felt a confusion so ask if you 
show me directly.

> properly handle the error case (just logging a message - which
> btw lacks a proper XENLOG_G_* prefix - doesn't seem enough
> to me)."

Looks there are two problems:

#1: the error message

If current line is not fine,
	printk(XENLOG_G_WARNING "Domain %d can't check reserved device 
memory.\n", d->domain_id);

I mean could you change this directly.

#2 the error handling

In an error case what should I do? Currently we still create these 
mapping as normal. This means these mfns will be valid so later we can't 
set them again then device can't be assigned as passthrough. I think 
this makes sense. Or we should just stop them from setting 1:1 mapping?

>
>>>>> But then again this code may change altogether if you avoid
>>>>> populating the reserved regions in the first place.
>>>>
>>>> Are you saying this scenario?
>>>>
>>>> #1 Here we first set these ranges as p2m_access_n
>>>> #2 We reset them as 1:1 RMRR mapping with p2m_access_rw somewhere
>>>> #3 Someone may try to populate these ranges again
>>>
>>> No. I pointed at the fact that if you avoid populating the holes,
>>> there's no need to force them to p2m_access_n. Any attempts
>>> to map other than the 1:1 thing there could then simply be
>>> rejected.
>>
>> I think any population should be rejected totally, because 1:1 mapping
>> means guest can access these RMRR ranges in case of no any device
>> assignment with RMRR, right? Any access to these range corrupt the real
>> device usage.
>
> Oh yes, of course I implied that the 1:1 mapping would be
> permitted only for those ranges where the RMRR corresponds
> to a device the guest got assigned.
>

Yeah.

Tim,

Please take a look at this, and I hope this can make sure we'll be the 
same page finally :)

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:32:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlBBz-0007fW-9w; Mon, 03 Nov 2014 06:32:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlBBx-0007fK-Ep
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 06:32:41 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	2F/EA-20825-88127545; Mon, 03 Nov 2014 06:32:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1414996359!10825103!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2844 invoked from network); 3 Nov 2014 06:32:39 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 06:32:39 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0D09FAC01;
	Mon,  3 Nov 2014 06:32:37 +0000 (UTC)
Message-ID: <54572182.8080005@suse.com>
Date: Mon, 03 Nov 2014 07:32:34 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>
References: <1414764033-30011-1-git-send-email-jgross@suse.com>
	<1414764033-30011-11-git-send-email-jgross@suse.com>
	<alpine.DEB.2.11.1410311617260.5308@nanos>
In-Reply-To: <alpine.DEB.2.11.1410311617260.5308@nanos>
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH 10/17] x86: Use new cache mode type in
	setting page attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/31/2014 04:34 PM, Thomas Gleixner wrote:
> On Fri, 31 Oct 2014, Juergen Gross wrote:
>> --- a/arch/x86/mm/pageattr.c
>> +++ b/arch/x86/mm/pageattr.c
>> @@ -1304,12 +1304,6 @@ static int __change_page_attr_set_clr(struct cpa_data *cpa, int checkalias)
>>   	return 0;
>>   }
>>
>> -static inline int cache_attr(pgprot_t attr)
>> -{
>> -	return pgprot_val(attr) &
>> -		(_PAGE_PAT | _PAGE_PAT_LARGE | _PAGE_PWT | _PAGE_PCD);
>> -}
>> -
>>   static int change_page_attr_set_clr(unsigned long *addr, int numpages,
>>   				    pgprot_t mask_set, pgprot_t mask_clr,
>>   				    int force_split, int in_flag,
>> @@ -1390,7 +1384,7 @@ static int change_page_attr_set_clr(unsigned long *addr, int numpages,
>>   	 * No need to flush, when we did not set any of the caching
>>   	 * attributes:
>>   	 */
>> -	cache = cache_attr(mask_set);
>> +	cache = !!pgprot2cachemode(mask_set);
>
> So this loses _PAGE_PAT_LARGE, right ?

change_page_attr_set_clr() is never called with _PAGE_PAT_LARGE set in
mask, so this is no problem.

BTW: correct handling of the PAT bit for large pages is added in
patch 15. There have been places in the kernel respecting
_PAGE_PAT_LARGE, but handling has never been complete up to now.

>
>>   int set_memory_uc(unsigned long addr, int numpages)
>> @@ -1456,7 +1451,7 @@ int set_memory_uc(unsigned long addr, int numpages)
>>   	 * for now UC MINUS. see comments in ioremap_nocache()
>>   	 */
>>   	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
>> -			    _PAGE_CACHE_UC_MINUS, NULL);
>> +			      _PAGE_CACHE_UC_MINUS, NULL);
>
> That should be in the patch which added the _PAGE_CACHE_UC_MINUS
>
>>   int _set_memory_wb(unsigned long addr, int numpages)
>>   {
>> +	/* WB cache mode is hard wired to all cache attribute bits being 0 */
>
> I like the comment, but shouldn't we compile time check that
> assumption somewhere?

There is a comment in patch 1 where the page_cache_mode enum is set up.
The translation functions between page_cache_mode and protection values
have a special check for "0" built in. Isn't this enough?

BTW: How would you check this assumption at compile time? The
translation between WB cache mode and protection values is done only
dynamically...


Thanks for the review,

Juergen

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:32:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlBBz-0007fW-9w; Mon, 03 Nov 2014 06:32:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlBBx-0007fK-Ep
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 06:32:41 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	2F/EA-20825-88127545; Mon, 03 Nov 2014 06:32:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1414996359!10825103!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2844 invoked from network); 3 Nov 2014 06:32:39 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 06:32:39 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0D09FAC01;
	Mon,  3 Nov 2014 06:32:37 +0000 (UTC)
Message-ID: <54572182.8080005@suse.com>
Date: Mon, 03 Nov 2014 07:32:34 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>
References: <1414764033-30011-1-git-send-email-jgross@suse.com>
	<1414764033-30011-11-git-send-email-jgross@suse.com>
	<alpine.DEB.2.11.1410311617260.5308@nanos>
In-Reply-To: <alpine.DEB.2.11.1410311617260.5308@nanos>
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH 10/17] x86: Use new cache mode type in
	setting page attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/31/2014 04:34 PM, Thomas Gleixner wrote:
> On Fri, 31 Oct 2014, Juergen Gross wrote:
>> --- a/arch/x86/mm/pageattr.c
>> +++ b/arch/x86/mm/pageattr.c
>> @@ -1304,12 +1304,6 @@ static int __change_page_attr_set_clr(struct cpa_data *cpa, int checkalias)
>>   	return 0;
>>   }
>>
>> -static inline int cache_attr(pgprot_t attr)
>> -{
>> -	return pgprot_val(attr) &
>> -		(_PAGE_PAT | _PAGE_PAT_LARGE | _PAGE_PWT | _PAGE_PCD);
>> -}
>> -
>>   static int change_page_attr_set_clr(unsigned long *addr, int numpages,
>>   				    pgprot_t mask_set, pgprot_t mask_clr,
>>   				    int force_split, int in_flag,
>> @@ -1390,7 +1384,7 @@ static int change_page_attr_set_clr(unsigned long *addr, int numpages,
>>   	 * No need to flush, when we did not set any of the caching
>>   	 * attributes:
>>   	 */
>> -	cache = cache_attr(mask_set);
>> +	cache = !!pgprot2cachemode(mask_set);
>
> So this loses _PAGE_PAT_LARGE, right ?

change_page_attr_set_clr() is never called with _PAGE_PAT_LARGE set in
mask, so this is no problem.

BTW: correct handling of the PAT bit for large pages is added in
patch 15. There have been places in the kernel respecting
_PAGE_PAT_LARGE, but handling has never been complete up to now.

>
>>   int set_memory_uc(unsigned long addr, int numpages)
>> @@ -1456,7 +1451,7 @@ int set_memory_uc(unsigned long addr, int numpages)
>>   	 * for now UC MINUS. see comments in ioremap_nocache()
>>   	 */
>>   	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
>> -			    _PAGE_CACHE_UC_MINUS, NULL);
>> +			      _PAGE_CACHE_UC_MINUS, NULL);
>
> That should be in the patch which added the _PAGE_CACHE_UC_MINUS
>
>>   int _set_memory_wb(unsigned long addr, int numpages)
>>   {
>> +	/* WB cache mode is hard wired to all cache attribute bits being 0 */
>
> I like the comment, but shouldn't we compile time check that
> assumption somewhere?

There is a comment in patch 1 where the page_cache_mode enum is set up.
The translation functions between page_cache_mode and protection values
have a special check for "0" built in. Isn't this enough?

BTW: How would you check this assumption at compile time? The
translation between WB cache mode and protection values is done only
dynamically...


Thanks for the review,

Juergen

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:36:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlBFK-0007t4-5h; Mon, 03 Nov 2014 06:36:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlBFI-0007sy-SQ
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 06:36:08 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C6/A3-29352-85227545; Mon, 03 Nov 2014 06:36:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1414996567!10761349!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20337 invoked from network); 3 Nov 2014 06:36:07 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 06:36:07 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 71A30AC01;
	Mon,  3 Nov 2014 06:36:07 +0000 (UTC)
Message-ID: <54572256.5050707@suse.com>
Date: Mon, 03 Nov 2014 07:36:06 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414764033-30011-1-git-send-email-jgross@suse.com>
	<1414764033-30011-2-git-send-email-jgross@suse.com>
	<20141031194207.GA15367@pd.tnic>
	<20141031202322.GB15935@laptop.dumpdata.com>
	<20141031203554.GA15363@pd.tnic>
In-Reply-To: <20141031203554.GA15363@pd.tnic>
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, tglx@linutronix.de, plagnioj@jcrosoft.com,
	ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH 01/17] x86: Make page cache mode a real 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/31/2014 09:35 PM, Borislav Petkov wrote:
> On Fri, Oct 31, 2014 at 04:23:22PM -0400, Konrad Rzeszutek Wilk wrote:
>>>> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>
>>> Just a clarification question: how is one to understand this attribution
>>> here? Is Stefan the original author, was he a reviewer, or? Because this
>>> SOB chain is misleading...
>>
>> He was the first then Juergen took over. Should the SOB order be inversed?
>
> Well, I'd say:
>
> Originally-by: Stefan...
>
> or
>
> Based-on-patch-by: Stefan...

I think this would fit best.

Shall I respin another version modifying the SOB to above?


Juergen


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:36:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlBFK-0007t4-5h; Mon, 03 Nov 2014 06:36:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlBFI-0007sy-SQ
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 06:36:08 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C6/A3-29352-85227545; Mon, 03 Nov 2014 06:36:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1414996567!10761349!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20337 invoked from network); 3 Nov 2014 06:36:07 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 06:36:07 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 71A30AC01;
	Mon,  3 Nov 2014 06:36:07 +0000 (UTC)
Message-ID: <54572256.5050707@suse.com>
Date: Mon, 03 Nov 2014 07:36:06 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414764033-30011-1-git-send-email-jgross@suse.com>
	<1414764033-30011-2-git-send-email-jgross@suse.com>
	<20141031194207.GA15367@pd.tnic>
	<20141031202322.GB15935@laptop.dumpdata.com>
	<20141031203554.GA15363@pd.tnic>
In-Reply-To: <20141031203554.GA15363@pd.tnic>
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, tglx@linutronix.de, plagnioj@jcrosoft.com,
	ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH 01/17] x86: Make page cache mode a real 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/31/2014 09:35 PM, Borislav Petkov wrote:
> On Fri, Oct 31, 2014 at 04:23:22PM -0400, Konrad Rzeszutek Wilk wrote:
>>>> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>
>>> Just a clarification question: how is one to understand this attribution
>>> here? Is Stefan the original author, was he a reviewer, or? Because this
>>> SOB chain is misleading...
>>
>> He was the first then Juergen took over. Should the SOB order be inversed?
>
> Well, I'd say:
>
> Originally-by: Stefan...
>
> or
>
> Based-on-patch-by: Stefan...

I think this would fit best.

Shall I respin another version modifying the SOB to above?


Juergen


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:44:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlBNb-00089i-A8; Mon, 03 Nov 2014 06:44:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlBNZ-00089a-Qk
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 06:44:41 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	C2/66-02712-95427545; Mon, 03 Nov 2014 06:44:41 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1414997080!12086723!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9492 invoked from network); 3 Nov 2014 06:44:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 06:44:40 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 26211AC01;
	Mon,  3 Nov 2014 06:44:39 +0000 (UTC)
Message-ID: <54572455.60102@suse.com>
Date: Mon, 03 Nov 2014 07:44:37 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
References: <1414764033-30011-1-git-send-email-jgross@suse.com>
	<20141031140600.GA31014@gmail.com>
	<alpine.DEB.2.11.1410311951230.5308@nanos>
In-Reply-To: <alpine.DEB.2.11.1410311951230.5308@nanos>
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH 00/17] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/31/2014 07:53 PM, Thomas Gleixner wrote:
> On Fri, 31 Oct 2014, Ingo Molnar wrote:
>>
>> * Juergen Gross <jgross@suse.com> wrote:
>>
>>> Changes in V5:
>>> - split up first patch as requested by Ingo Molnar and Thomas Gleixner
>>> - add a helper function in pat_init_cache_modes() as requested by Ingo Molnar
>>
>> The structure of this series looks great to me now.
>
> And it actually was a pleasure to review.

You're welcome.

>
>> Just to make sure: the series is fully bisectable, it is supposed
>> to build and boot at every patch in the series, right?
>>
>> If nobody objects then I'll start applying this series in a
>> couple of days.
>
> I did not find anything except the question about losing the large pat
> bit. If that's resolved its good to go.
>
> Please add
>
>    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
>
> to the whole series.

Thank you,

Juergen

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:44:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlBNb-00089i-A8; Mon, 03 Nov 2014 06:44:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlBNZ-00089a-Qk
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 06:44:41 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	C2/66-02712-95427545; Mon, 03 Nov 2014 06:44:41 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1414997080!12086723!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9492 invoked from network); 3 Nov 2014 06:44:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 06:44:40 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 26211AC01;
	Mon,  3 Nov 2014 06:44:39 +0000 (UTC)
Message-ID: <54572455.60102@suse.com>
Date: Mon, 03 Nov 2014 07:44:37 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
References: <1414764033-30011-1-git-send-email-jgross@suse.com>
	<20141031140600.GA31014@gmail.com>
	<alpine.DEB.2.11.1410311951230.5308@nanos>
In-Reply-To: <alpine.DEB.2.11.1410311951230.5308@nanos>
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH 00/17] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/31/2014 07:53 PM, Thomas Gleixner wrote:
> On Fri, 31 Oct 2014, Ingo Molnar wrote:
>>
>> * Juergen Gross <jgross@suse.com> wrote:
>>
>>> Changes in V5:
>>> - split up first patch as requested by Ingo Molnar and Thomas Gleixner
>>> - add a helper function in pat_init_cache_modes() as requested by Ingo Molnar
>>
>> The structure of this series looks great to me now.
>
> And it actually was a pleasure to review.

You're welcome.

>
>> Just to make sure: the series is fully bisectable, it is supposed
>> to build and boot at every patch in the series, right?
>>
>> If nobody objects then I'll start applying this series in a
>> couple of days.
>
> I did not find anything except the question about losing the large pat
> bit. If that's resolved its good to go.
>
> Please add
>
>    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
>
> to the whole series.

Thank you,

Juergen

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:49:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:49:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlBRg-0008I4-6F; Mon, 03 Nov 2014 06:48:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlBRf-0008Hz-0o
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 06:48:55 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	43/0C-09936-65527545; Mon, 03 Nov 2014 06:48:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1414997332!12299440!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32236 invoked from network); 3 Nov 2014 06:48:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 06:48:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="187417024"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 01:48:50 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlBRa-0005nW-KY;
	Mon, 03 Nov 2014 06:48:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlBRa-0002CZ-Bb;
	Mon, 03 Nov 2014 06:48:50 +0000
Date: Mon, 3 Nov 2014 06:48:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31329-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9785
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6363563234210734997=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6363563234210734997==
Content-Type: text/plain
Content-Length: 9509
Content-Transfer-Encoding: quoted-printable

flight 31329 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31329/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass

version targeted for testing:
 qemuu                ee29498e4f0f3eff90eeeb7f5fa1703abedd2fb6
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Walle <michael@walle.cc> (for lm32)
  Mikhail Ilyin <m.ilin@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============6363563234210734997==--

From xen-devel-bounces@lists.xen.org Mon Nov 03 06:49:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 06:49:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlBRg-0008I4-6F; Mon, 03 Nov 2014 06:48:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlBRf-0008Hz-0o
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 06:48:55 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	43/0C-09936-65527545; Mon, 03 Nov 2014 06:48:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1414997332!12299440!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32236 invoked from network); 3 Nov 2014 06:48:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 06:48:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="187417024"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 01:48:50 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlBRa-0005nW-KY;
	Mon, 03 Nov 2014 06:48:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlBRa-0002CZ-Bb;
	Mon, 03 Nov 2014 06:48:50 +0000
Date: Mon, 3 Nov 2014 06:48:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31329-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9785
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6363563234210734997=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6363563234210734997==
Content-Type: text/plain
Content-Length: 9509
Content-Transfer-Encoding: quoted-printable

flight 31329 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31329/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass

version targeted for testing:
 qemuu                ee29498e4f0f3eff90eeeb7f5fa1703abedd2fb6
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Walle <michael@walle.cc> (for lm32)
  Mikhail Ilyin <m.ilin@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============6363563234210734997==--

From xen-devel-bounces@lists.xen.org Mon Nov 03 07:38:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 07:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlCCr-0000nA-Gv; Mon, 03 Nov 2014 07:37:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XlCCp-0000n5-TW
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 07:37:40 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	15/78-02954-3C037545; Mon, 03 Nov 2014 07:37:39 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415000256!12037434!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23947 invoked from network); 3 Nov 2014 07:37:38 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 07:37:38 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 00:37:36 -0700
Message-Id: <5457A1390200006600075B0C@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 00:37:29 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1412930928-14309-1-git-send-email-cyliu@suse.com>
	<1412930928-14309-3-git-send-email-cyliu@suse.com>
	<1413821501.29506.13.camel@citrix.com>
	<54479C3302000066000712E6@soto.provo.novell.com>
	<1414578409.29975.9.camel@citrix.com>
In-Reply-To: <1414578409.29975.9.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jim Fehlig <JFEHLIG@suse.com>, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V7 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 10/29/2014 at 06:26 PM, in message <1414578409.29975.9.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-10-21 at 21:59 -0600, Chun Yan Liu wrote: 
> > > Is this operation any different to destroying the domain and using  
> > > libxl_domain_restore to start a new domain based on the snapshot? Is  
> > > this operation just a convenience layer over that operation?  
> >  
> > It depends on implementation. It's a simple way to destroy the domain 
> > first, then start new domain based on snapshot. But destroying the 
> > domain may be not good to user (after xl snapshot-revert, domid is 
> > changed.)  and may cause some problem in libvirt (may affect its 
> > event handling ?). 
>  
> I would hope that as part of the implementation libvirt would learn to 
> cope with this if it can't already, but it can surely already cope with 
> migration and reverting to a snapshot is not so very different. 

See. If implemented in this way (destroy domain and restore based on snapshot),
it's better not supply a libxl API. Let xl and libvirt handle that by themselves.
(Libxl destroys the domain and starts a new domain will cause problem in libvirt,
libvirt has no idea of the new domain created by libxl internally.)

Thanks Ian. I'll update the doc.

- Chunyan

>  
> > Or another way is: not destroying the domain, but through a process 
> > like pause domain, reload memory, reload disk snapshot, reload config 
> > file, resume domain. Complex but maybe better. 
>  
> I don't think the complexity of resetting an already existing domain's 
> memory and i/o state to an earlier incarnation rather than starting from 
> a clean slate should be underestimated either (TBH it never occurred to 
> me that you might try this). AFAICT you'd need to effectively tear 
> everything down to a blank slate and then do all the same things that 
> you would do in the destroy case. 
>  
> Ian. 
>  
>  
>  



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 07:38:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 07:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlCCr-0000nA-Gv; Mon, 03 Nov 2014 07:37:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XlCCp-0000n5-TW
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 07:37:40 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	15/78-02954-3C037545; Mon, 03 Nov 2014 07:37:39 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415000256!12037434!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23947 invoked from network); 3 Nov 2014 07:37:38 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 07:37:38 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 00:37:36 -0700
Message-Id: <5457A1390200006600075B0C@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 00:37:29 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1412930928-14309-1-git-send-email-cyliu@suse.com>
	<1412930928-14309-3-git-send-email-cyliu@suse.com>
	<1413821501.29506.13.camel@citrix.com>
	<54479C3302000066000712E6@soto.provo.novell.com>
	<1414578409.29975.9.camel@citrix.com>
In-Reply-To: <1414578409.29975.9.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jim Fehlig <JFEHLIG@suse.com>, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V7 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 10/29/2014 at 06:26 PM, in message <1414578409.29975.9.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-10-21 at 21:59 -0600, Chun Yan Liu wrote: 
> > > Is this operation any different to destroying the domain and using  
> > > libxl_domain_restore to start a new domain based on the snapshot? Is  
> > > this operation just a convenience layer over that operation?  
> >  
> > It depends on implementation. It's a simple way to destroy the domain 
> > first, then start new domain based on snapshot. But destroying the 
> > domain may be not good to user (after xl snapshot-revert, domid is 
> > changed.)  and may cause some problem in libvirt (may affect its 
> > event handling ?). 
>  
> I would hope that as part of the implementation libvirt would learn to 
> cope with this if it can't already, but it can surely already cope with 
> migration and reverting to a snapshot is not so very different. 

See. If implemented in this way (destroy domain and restore based on snapshot),
it's better not supply a libxl API. Let xl and libvirt handle that by themselves.
(Libxl destroys the domain and starts a new domain will cause problem in libvirt,
libvirt has no idea of the new domain created by libxl internally.)

Thanks Ian. I'll update the doc.

- Chunyan

>  
> > Or another way is: not destroying the domain, but through a process 
> > like pause domain, reload memory, reload disk snapshot, reload config 
> > file, resume domain. Complex but maybe better. 
>  
> I don't think the complexity of resetting an already existing domain's 
> memory and i/o state to an earlier incarnation rather than starting from 
> a clean slate should be underestimated either (TBH it never occurred to 
> me that you might try this). AFAICT you'd need to effectively tear 
> everything down to a blank slate and then do all the same things that 
> you would do in the destroy case. 
>  
> Ian. 
>  
>  
>  



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 07:48:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 07: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 1XlCNd-00012u-RJ; Mon, 03 Nov 2014 07:48:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlCNc-00012p-Nb
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 07:48:48 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	7A/1D-29352-F5337545; Mon, 03 Nov 2014 07:48:47 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415000926!10791297!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32193 invoked from network); 3 Nov 2014 07:48:46 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 07:48:46 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 02 Nov 2014 23:48:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="600933488"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by orsmga001.jf.intel.com with ESMTP; 02 Nov 2014 23:48:43 -0800
Message-ID: <5457335B.1000308@intel.com>
Date: Mon, 03 Nov 2014 15:48:43 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
References: <20140901060506.GA20186@redhat.com>	<54042514.6090206@intel.com>	<003AAFE53969E14CB1F09B6FD68C3CD478F16D2A@ORSMSX101.amr.corp.intel.com>	<54277979.7070408@intel.com>	<20140929100111.GA32459@redhat.com>	<542A18BD.2060008@intel.com>	<20141007072653.GB2424@redhat.com>	<543622CC.6050807@intel.com>	<20141012095021.GC9567@redhat.com>	<544A0174.7000003@intel.com>	<20141024134747.GA6024@redhat.com>
	<5451ED1E.1000300@intel.com>
In-Reply-To: <5451ED1E.1000300@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xen:i386:pc_piix: create
 isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/30 15:47, Chen, Tiejun wrote:
> Sorry some urgent things always procrastinate on my response.
>
> On 2014/10/24 21:47, Michael S. Tsirkin wrote:
>> On Fri, Oct 24, 2014 at 03:36:20PM +0800, Chen, Tiejun wrote:
>>>> I think the point was mostly to reserve 1f to prevent
>>>> devices from using it.
>>>> As we populate slots in order it doesn't seem to important ...
>>>
>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>
>> Right, but I mean if no special options are used, 1f will typically
>> stay free without any effort on our side.
>
> Yeah.
>
> Actually based on current info we know, seems 1f is just specific to our
> scenario :) So I always think we can occupy that. But Paolo and you can
> really determine this point.

Paolo,

What's your idea?

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 07:48:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 07: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 1XlCNd-00012u-RJ; Mon, 03 Nov 2014 07:48:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlCNc-00012p-Nb
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 07:48:48 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	7A/1D-29352-F5337545; Mon, 03 Nov 2014 07:48:47 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415000926!10791297!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32193 invoked from network); 3 Nov 2014 07:48:46 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 07:48:46 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 02 Nov 2014 23:48:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="600933488"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by orsmga001.jf.intel.com with ESMTP; 02 Nov 2014 23:48:43 -0800
Message-ID: <5457335B.1000308@intel.com>
Date: Mon, 03 Nov 2014 15:48:43 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
References: <20140901060506.GA20186@redhat.com>	<54042514.6090206@intel.com>	<003AAFE53969E14CB1F09B6FD68C3CD478F16D2A@ORSMSX101.amr.corp.intel.com>	<54277979.7070408@intel.com>	<20140929100111.GA32459@redhat.com>	<542A18BD.2060008@intel.com>	<20141007072653.GB2424@redhat.com>	<543622CC.6050807@intel.com>	<20141012095021.GC9567@redhat.com>	<544A0174.7000003@intel.com>	<20141024134747.GA6024@redhat.com>
	<5451ED1E.1000300@intel.com>
In-Reply-To: <5451ED1E.1000300@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xen:i386:pc_piix: create
 isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/10/30 15:47, Chen, Tiejun wrote:
> Sorry some urgent things always procrastinate on my response.
>
> On 2014/10/24 21:47, Michael S. Tsirkin wrote:
>> On Fri, Oct 24, 2014 at 03:36:20PM +0800, Chen, Tiejun wrote:
>>>> I think the point was mostly to reserve 1f to prevent
>>>> devices from using it.
>>>> As we populate slots in order it doesn't seem to important ...
>>>
>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>
>> Right, but I mean if no special options are used, 1f will typically
>> stay free without any effort on our side.
>
> Yeah.
>
> Actually based on current info we know, seems 1f is just specific to our
> scenario :) So I always think we can occupy that. But Paolo and you can
> really determine this point.

Paolo,

What's your idea?

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 07:51:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 07:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlCPr-000191-DW; Mon, 03 Nov 2014 07:51:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XlCPq-00018v-3m
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 07:51:06 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	6C/82-02699-9E337545; Mon, 03 Nov 2014 07:51:05 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415001063!12120305!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6894 invoked from network); 3 Nov 2014 07:51:04 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-2.tower-27.messagelabs.com with SMTP;
	3 Nov 2014 07:51:04 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 02 Nov 2014 23:44:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="410236356"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 02 Nov 2014 23:42:38 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 22:47:35 -0500
Message-Id: <1414986455-12795-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com,
	armbru@redhat.com, lcapitulino@redhat.com, aliguori@amazon.com,
	pbonzini@redhat.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for
	HVM virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series are only the Qemu part to enable Xen stubdom vTPM for HVM virtual 
machine. it will work w/ Xen patch series and seaBios patch series.

Signed-off-by: Quan Xu <quan.xu@intel.com>

..
Build it with --enable-tpm and --enable-xen options and link with Xen, or change 
QEMU_STUBDOM_VTPM compile option from 'n' to 'y' in <Xen>/Config.mk, when the Qemu/
SeaBios patch series are merged.

..
Run Xen virtual mahcine with below QEMU command line options:
  "-tpmdev xenstubdoms,id=xenvtpm0 -device tpm-tis,tpmdev=xenvtpm0" 

or Xen xl tool adds this options when virtual machine cfg includes:

  ** 
  vtpm=["backend=vtpmN"]
  **

..
qemu-system-* --tpmdev help
Supported TPM types (choose only one):
 passthrough   Passthrough TPM backend driver
 xenstubdoms   Xenstubdoms TPM backend driver

 configure                    |  13 ++++
 hmp.c                        |   7 ++
 hw/tpm/Makefile.objs         |   1 +
 hw/tpm/tpm_xenstubdoms.c     | 238 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen/Makefile.objs         |   1 +
 hw/xen/xen_backend.c         | 181 ++++++++++++++++++++++++++++++++++++++++++++++-
 hw/xen/xen_stubdom_vtpm.c    | 323 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  11 +++
 include/hw/xen/xen_common.h  |   7 ++
 qapi-schema.json             |  17 ++++-
 qemu-options.hx              |  13 +++-
 tpm.c                        |   7 +-
 vl.c                         |  16 +++--
 xen-hvm.c                    |  13 ++++
 14 files changed, 835 insertions(+), 13 deletions(-)


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 07:51:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 07:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlCPr-000191-DW; Mon, 03 Nov 2014 07:51:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XlCPq-00018v-3m
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 07:51:06 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	6C/82-02699-9E337545; Mon, 03 Nov 2014 07:51:05 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415001063!12120305!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6894 invoked from network); 3 Nov 2014 07:51:04 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-2.tower-27.messagelabs.com with SMTP;
	3 Nov 2014 07:51:04 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 02 Nov 2014 23:44:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="410236356"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 02 Nov 2014 23:42:38 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun,  2 Nov 2014 22:47:35 -0500
Message-Id: <1414986455-12795-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com,
	armbru@redhat.com, lcapitulino@redhat.com, aliguori@amazon.com,
	pbonzini@redhat.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for
	HVM virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series are only the Qemu part to enable Xen stubdom vTPM for HVM virtual 
machine. it will work w/ Xen patch series and seaBios patch series.

Signed-off-by: Quan Xu <quan.xu@intel.com>

..
Build it with --enable-tpm and --enable-xen options and link with Xen, or change 
QEMU_STUBDOM_VTPM compile option from 'n' to 'y' in <Xen>/Config.mk, when the Qemu/
SeaBios patch series are merged.

..
Run Xen virtual mahcine with below QEMU command line options:
  "-tpmdev xenstubdoms,id=xenvtpm0 -device tpm-tis,tpmdev=xenvtpm0" 

or Xen xl tool adds this options when virtual machine cfg includes:

  ** 
  vtpm=["backend=vtpmN"]
  **

..
qemu-system-* --tpmdev help
Supported TPM types (choose only one):
 passthrough   Passthrough TPM backend driver
 xenstubdoms   Xenstubdoms TPM backend driver

 configure                    |  13 ++++
 hmp.c                        |   7 ++
 hw/tpm/Makefile.objs         |   1 +
 hw/tpm/tpm_xenstubdoms.c     | 238 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen/Makefile.objs         |   1 +
 hw/xen/xen_backend.c         | 181 ++++++++++++++++++++++++++++++++++++++++++++++-
 hw/xen/xen_stubdom_vtpm.c    | 323 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  11 +++
 include/hw/xen/xen_common.h  |   7 ++
 qapi-schema.json             |  17 ++++-
 qemu-options.hx              |  13 +++-
 tpm.c                        |   7 +-
 vl.c                         |  16 +++--
 xen-hvm.c                    |  13 ++++
 14 files changed, 835 insertions(+), 13 deletions(-)


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:09:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlChh-00021n-S7; Mon, 03 Nov 2014 08:09:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elfring@users.sourceforge.net>) id 1Xkwpg-0005ep-3u
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 15:12:44 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	78/15-24124-BE946545; Sun, 02 Nov 2014 15:12:43 +0000
X-Env-Sender: elfring@users.sourceforge.net
X-Msg-Ref: server-9.tower-206.messagelabs.com!1414941162!11478316!1
X-Originating-IP: [212.227.15.3]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE1LjMgPT4gMTUyNjI=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE1LjMgPT4gMTUyNjI=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13651 invoked from network); 2 Nov 2014 15:12:42 -0000
Received: from mout.web.de (HELO mout.web.de) (212.227.15.3)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 15:12:42 -0000
Received: from [192.168.1.2] ([78.48.104.118]) by smtp.web.de (mrweb002) with
	ESMTPSA (Nemesis) id 0MJlGW-1Xjqtw0ige-0016KX;
	Sun, 02 Nov 2014 16:12:32 +0100
Message-ID: <545649DE.80304@users.sourceforge.net>
Date: Sun, 02 Nov 2014 16:12:30 +0100
From: SF Markus Elfring <elfring@users.sourceforge.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Bjorn Helgaas <bhelgaas@google.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Len Brown <lenb@kernel.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, 
	linux-pci@vger.kernel.org
References: <5307CAA2.8060406@users.sourceforge.net>
	<alpine.DEB.2.02.1402212321410.2043@localhost6.localdomain6>
	<530A086E.8010901@users.sourceforge.net>
	<alpine.DEB.2.02.1402231635510.1985@localhost6.localdomain6>
	<530A72AA.3000601@users.sourceforge.net>
	<alpine.DEB.2.02.1402240658210.2090@localhost6.localdomain6>
	<530B5FB6.6010207@users.sourceforge.net>
	<alpine.DEB.2.10.1402241710370.2074@hadrien>
	<530C5E18.1020800@users.sourceforge.net>
	<alpine.DEB.2.10.1402251014170.2080@hadrien>
	<530CD2C4.4050903@users.sourceforge.net>
	<alpine.DEB.2.10.1402251840450.7035@hadrien>
	<530CF8FF.8080600@users.sourceforge.net>
	<alpine.DEB.2.02.1402252117150.2047@localhost6.localdomain6>
	<530DD06F.4090703@users.sourceforge.net>
	<alpine.DEB.2.02.1402262129250.2221@localhost6.localdomain6>
	<5317A59D.4@users.sourceforge.net>
In-Reply-To: <5317A59D.4@users.sourceforge.net>
X-Provags-ID: V03:K0:mmme/5mISXoTEOLR5mJV8zfK9+Vqh3VWA48bt8TnfGMcAYin+QQ
	1sOT+J1jGL6szQtmy+SmvVLSZDUKnOOqeeHjmPJoBzbqF1IqjRpymxQg75z2vLYBxmFmd1m
	r7uEzd7DksTk+ruu5PLvZ+nzSW3KXFtqX3KQgRXoaa4qBST/LhgAHHuFyOT2KQftRAmSPd0
	bxee34RUvwDhsfZf1X9pA==
X-UI-Out-Filterresults: notjunk:1;
X-Mailman-Approved-At: Mon, 03 Nov 2014 08:09:32 +0000
Cc: trivial@kernel.org, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org, Coccinelle <cocci@systeme.lip6.fr>
Subject: [Xen-devel] [PATCH 1/1] PCI: Deletion of unnecessary checks before
 three function calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The functions pci_dev_put(), pci_pme_wakeup_bus() and put_device() test
whether their argument is NULL and then return immediately. Thus the test
around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/pci/pci-acpi.c     | 3 +--
 drivers/pci/probe.c        | 3 +--
 drivers/pci/search.c       | 3 +--
 drivers/pci/xen-pcifront.c | 3 +--
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 37263b0..a8fe5de 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -60,8 +60,7 @@ static void pci_acpi_wake_dev(struct work_struct *work)
 	pci_wakeup_event(pci_dev);
 	pm_runtime_resume(&pci_dev->dev);

-	if (pci_dev->subordinate)
-		pci_pme_wakeup_bus(pci_dev->subordinate);
+	pci_pme_wakeup_bus(pci_dev->subordinate);
 }

 /**
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 4170113..e93f16e 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -86,8 +86,7 @@ static void release_pcibus_dev(struct device *dev)
 {
 	struct pci_bus *pci_bus = to_pci_bus(dev);

-	if (pci_bus->bridge)
-		put_device(pci_bus->bridge);
+	put_device(pci_bus->bridge);
 	pci_bus_remove_resources(pci_bus);
 	pci_release_bus_of_node(pci_bus);
 	kfree(pci_bus);
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 827ad83..2d806bd 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -305,8 +305,7 @@ static struct pci_dev *pci_get_dev_by_id(const struct
pci_device_id *id,
 			      match_pci_dev_by_id);
 	if (dev)
 		pdev = to_pci_dev(dev);
-	if (from)
-		pci_dev_put(from);
+	pci_dev_put(from);
 	return pdev;
 }

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 53df39a..46664cc 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -596,8 +596,7 @@ static pci_ers_result_t pcifront_common_process(int cmd,
 	pcidev = pci_get_bus_and_slot(bus, devfn);
 	if (!pcidev || !pcidev->driver) {
 		dev_err(&pdev->xdev->dev, "device or AER driver is NULL\n");
-		if (pcidev)
-			pci_dev_put(pcidev);
+		pci_dev_put(pcidev);
 		return result;
 	}
 	pdrv = pcidev->driver;
-- 
2.1.3



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:09:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlChh-00021g-H4; Mon, 03 Nov 2014 08:09:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <egtvedt@samfundet.no>) id 1XkVkJ-0002rT-SJ
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 10:17:23 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	38/A9-23358-333B4545; Sat, 01 Nov 2014 10:17:23 +0000
X-Env-Sender: egtvedt@samfundet.no
X-Msg-Ref: server-13.tower-206.messagelabs.com!1414837042!12328956!1
X-Originating-IP: [193.35.52.29]
X-SpamReason: No, hits=2.2 required=7.0 tests=SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1233 invoked from network); 1 Nov 2014 10:17:22 -0000
Received: from cassarossa.samfundet.no (HELO cassarossa.samfundet.no)
	(193.35.52.29)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 1 Nov 2014 10:17:22 -0000
Received: from egtvedt by cassarossa.samfundet.no with local (Exim 4.80)
	(envelope-from <egtvedt@samfundet.no>)
	id 1XkVjZ-0003c6-QA; Sat, 01 Nov 2014 11:16:37 +0100
Date: Sat, 1 Nov 2014 11:16:37 +0100
From: Hans-Christian Egtvedt <egtvedt@samfundet.no>
To: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20141101101637.GA5765@samfundet.no>
References: <1412659726-29957-1-git-send-email-linux@roeck-us.net>
	<1412659726-29957-34-git-send-email-linux@roeck-us.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1412659726-29957-34-git-send-email-linux@roeck-us.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Mon, 03 Nov 2014 08:09:32 +0000
Cc: linux-m32r-ja@ml.linux-m32r.org, linux-mips@linux-mips.org,
	linux-efi@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-xtensa@linux-xtensa.org, devel@driverdev.osuosl.org,
	linux-s390@vger.kernel.org, lguest@lists.ozlabs.org,
	linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org,
	linux-sh@vger.kernel.org, linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org, Haavard Skinnemoen <hskinnemoen@gmail.com>,
	devicetree@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net,
	linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net,
	linux-m68k@lists.linux-m68k.org, linux-am33-list@redhat.com,
	linux-tegra@vger.kernel.org, openipmi-developer@lists.sourceforge.net,
	linux-metag@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
	linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [Xen-devel] [PATCH 33/44] avr32: atngw100: Register with kernel
 poweroff handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Around Mon 06 Oct 2014 22:28:35 -0700 or thereabout, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly.
> 
> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>

> ---
>  arch/avr32/boards/atngw100/mrmt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/avr32/boards/atngw100/mrmt.c b/arch/avr32/boards/atngw100/mrmt.c
> index 91146b4..54d0c27 100644
> --- a/arch/avr32/boards/atngw100/mrmt.c
> +++ b/arch/avr32/boards/atngw100/mrmt.c
> @@ -274,7 +274,7 @@ static int __init mrmt1_init(void)
>  {
>  	gpio_set_value( PIN_PWR_ON, 1 );	/* Ensure PWR_ON is enabled */
>  
> -	pm_power_off = mrmt_power_off;
> +	register_poweroff_handler_simple(mrmt_power_off, 128);
>  
>  	/* Setup USARTS (other than console) */
>  	at32_map_usart(2, 1, 0);	/* USART 2: /dev/ttyS1, RMT1:DB9M */
-- 
mvh
Hans-Christian Egtvedt

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:09:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlChh-00021n-S7; Mon, 03 Nov 2014 08:09:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elfring@users.sourceforge.net>) id 1Xkwpg-0005ep-3u
	for xen-devel@lists.xenproject.org; Sun, 02 Nov 2014 15:12:44 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	78/15-24124-BE946545; Sun, 02 Nov 2014 15:12:43 +0000
X-Env-Sender: elfring@users.sourceforge.net
X-Msg-Ref: server-9.tower-206.messagelabs.com!1414941162!11478316!1
X-Originating-IP: [212.227.15.3]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE1LjMgPT4gMTUyNjI=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE1LjMgPT4gMTUyNjI=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13651 invoked from network); 2 Nov 2014 15:12:42 -0000
Received: from mout.web.de (HELO mout.web.de) (212.227.15.3)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Nov 2014 15:12:42 -0000
Received: from [192.168.1.2] ([78.48.104.118]) by smtp.web.de (mrweb002) with
	ESMTPSA (Nemesis) id 0MJlGW-1Xjqtw0ige-0016KX;
	Sun, 02 Nov 2014 16:12:32 +0100
Message-ID: <545649DE.80304@users.sourceforge.net>
Date: Sun, 02 Nov 2014 16:12:30 +0100
From: SF Markus Elfring <elfring@users.sourceforge.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Bjorn Helgaas <bhelgaas@google.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Len Brown <lenb@kernel.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, 
	linux-pci@vger.kernel.org
References: <5307CAA2.8060406@users.sourceforge.net>
	<alpine.DEB.2.02.1402212321410.2043@localhost6.localdomain6>
	<530A086E.8010901@users.sourceforge.net>
	<alpine.DEB.2.02.1402231635510.1985@localhost6.localdomain6>
	<530A72AA.3000601@users.sourceforge.net>
	<alpine.DEB.2.02.1402240658210.2090@localhost6.localdomain6>
	<530B5FB6.6010207@users.sourceforge.net>
	<alpine.DEB.2.10.1402241710370.2074@hadrien>
	<530C5E18.1020800@users.sourceforge.net>
	<alpine.DEB.2.10.1402251014170.2080@hadrien>
	<530CD2C4.4050903@users.sourceforge.net>
	<alpine.DEB.2.10.1402251840450.7035@hadrien>
	<530CF8FF.8080600@users.sourceforge.net>
	<alpine.DEB.2.02.1402252117150.2047@localhost6.localdomain6>
	<530DD06F.4090703@users.sourceforge.net>
	<alpine.DEB.2.02.1402262129250.2221@localhost6.localdomain6>
	<5317A59D.4@users.sourceforge.net>
In-Reply-To: <5317A59D.4@users.sourceforge.net>
X-Provags-ID: V03:K0:mmme/5mISXoTEOLR5mJV8zfK9+Vqh3VWA48bt8TnfGMcAYin+QQ
	1sOT+J1jGL6szQtmy+SmvVLSZDUKnOOqeeHjmPJoBzbqF1IqjRpymxQg75z2vLYBxmFmd1m
	r7uEzd7DksTk+ruu5PLvZ+nzSW3KXFtqX3KQgRXoaa4qBST/LhgAHHuFyOT2KQftRAmSPd0
	bxee34RUvwDhsfZf1X9pA==
X-UI-Out-Filterresults: notjunk:1;
X-Mailman-Approved-At: Mon, 03 Nov 2014 08:09:32 +0000
Cc: trivial@kernel.org, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org, Coccinelle <cocci@systeme.lip6.fr>
Subject: [Xen-devel] [PATCH 1/1] PCI: Deletion of unnecessary checks before
 three function calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The functions pci_dev_put(), pci_pme_wakeup_bus() and put_device() test
whether their argument is NULL and then return immediately. Thus the test
around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/pci/pci-acpi.c     | 3 +--
 drivers/pci/probe.c        | 3 +--
 drivers/pci/search.c       | 3 +--
 drivers/pci/xen-pcifront.c | 3 +--
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 37263b0..a8fe5de 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -60,8 +60,7 @@ static void pci_acpi_wake_dev(struct work_struct *work)
 	pci_wakeup_event(pci_dev);
 	pm_runtime_resume(&pci_dev->dev);

-	if (pci_dev->subordinate)
-		pci_pme_wakeup_bus(pci_dev->subordinate);
+	pci_pme_wakeup_bus(pci_dev->subordinate);
 }

 /**
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 4170113..e93f16e 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -86,8 +86,7 @@ static void release_pcibus_dev(struct device *dev)
 {
 	struct pci_bus *pci_bus = to_pci_bus(dev);

-	if (pci_bus->bridge)
-		put_device(pci_bus->bridge);
+	put_device(pci_bus->bridge);
 	pci_bus_remove_resources(pci_bus);
 	pci_release_bus_of_node(pci_bus);
 	kfree(pci_bus);
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 827ad83..2d806bd 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -305,8 +305,7 @@ static struct pci_dev *pci_get_dev_by_id(const struct
pci_device_id *id,
 			      match_pci_dev_by_id);
 	if (dev)
 		pdev = to_pci_dev(dev);
-	if (from)
-		pci_dev_put(from);
+	pci_dev_put(from);
 	return pdev;
 }

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 53df39a..46664cc 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -596,8 +596,7 @@ static pci_ers_result_t pcifront_common_process(int cmd,
 	pcidev = pci_get_bus_and_slot(bus, devfn);
 	if (!pcidev || !pcidev->driver) {
 		dev_err(&pdev->xdev->dev, "device or AER driver is NULL\n");
-		if (pcidev)
-			pci_dev_put(pcidev);
+		pci_dev_put(pcidev);
 		return result;
 	}
 	pdrv = pcidev->driver;
-- 
2.1.3



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:09:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlChh-00021g-H4; Mon, 03 Nov 2014 08:09:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <egtvedt@samfundet.no>) id 1XkVkJ-0002rT-SJ
	for xen-devel@lists.xenproject.org; Sat, 01 Nov 2014 10:17:23 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	38/A9-23358-333B4545; Sat, 01 Nov 2014 10:17:23 +0000
X-Env-Sender: egtvedt@samfundet.no
X-Msg-Ref: server-13.tower-206.messagelabs.com!1414837042!12328956!1
X-Originating-IP: [193.35.52.29]
X-SpamReason: No, hits=2.2 required=7.0 tests=SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1233 invoked from network); 1 Nov 2014 10:17:22 -0000
Received: from cassarossa.samfundet.no (HELO cassarossa.samfundet.no)
	(193.35.52.29)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 1 Nov 2014 10:17:22 -0000
Received: from egtvedt by cassarossa.samfundet.no with local (Exim 4.80)
	(envelope-from <egtvedt@samfundet.no>)
	id 1XkVjZ-0003c6-QA; Sat, 01 Nov 2014 11:16:37 +0100
Date: Sat, 1 Nov 2014 11:16:37 +0100
From: Hans-Christian Egtvedt <egtvedt@samfundet.no>
To: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20141101101637.GA5765@samfundet.no>
References: <1412659726-29957-1-git-send-email-linux@roeck-us.net>
	<1412659726-29957-34-git-send-email-linux@roeck-us.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1412659726-29957-34-git-send-email-linux@roeck-us.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Mon, 03 Nov 2014 08:09:32 +0000
Cc: linux-m32r-ja@ml.linux-m32r.org, linux-mips@linux-mips.org,
	linux-efi@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-xtensa@linux-xtensa.org, devel@driverdev.osuosl.org,
	linux-s390@vger.kernel.org, lguest@lists.ozlabs.org,
	linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org,
	linux-sh@vger.kernel.org, linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org, Haavard Skinnemoen <hskinnemoen@gmail.com>,
	devicetree@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net,
	linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net,
	linux-m68k@lists.linux-m68k.org, linux-am33-list@redhat.com,
	linux-tegra@vger.kernel.org, openipmi-developer@lists.sourceforge.net,
	linux-metag@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
	linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [Xen-devel] [PATCH 33/44] avr32: atngw100: Register with kernel
 poweroff handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Around Mon 06 Oct 2014 22:28:35 -0700 or thereabout, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly.
> 
> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>

> ---
>  arch/avr32/boards/atngw100/mrmt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/avr32/boards/atngw100/mrmt.c b/arch/avr32/boards/atngw100/mrmt.c
> index 91146b4..54d0c27 100644
> --- a/arch/avr32/boards/atngw100/mrmt.c
> +++ b/arch/avr32/boards/atngw100/mrmt.c
> @@ -274,7 +274,7 @@ static int __init mrmt1_init(void)
>  {
>  	gpio_set_value( PIN_PWR_ON, 1 );	/* Ensure PWR_ON is enabled */
>  
> -	pm_power_off = mrmt_power_off;
> +	register_poweroff_handler_simple(mrmt_power_off, 128);
>  
>  	/* Setup USARTS (other than console) */
>  	at32_map_usart(2, 1, 0);	/* USART 2: /dev/ttyS1, RMT1:DB9M */
-- 
mvh
Hans-Christian Egtvedt

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:47:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08:47:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlDHY-0002q4-3m; Mon, 03 Nov 2014 08:46:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlDHW-0002pz-VY
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 08:46:35 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	1E/EA-02699-AE047545; Mon, 03 Nov 2014 08:46:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415004393!12148011!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14323 invoked from network); 3 Nov 2014 08:46:33 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 08:46:33 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 08:46:32 +0000
Message-Id: <54574EF40200007800044392@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 08:46:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
References: <544E397F0200007800042651@mail.emea.novell.com>
	<20141027170115.GC11893@laptop.dumpdata.com>
	<544E8283.1030907@citrix.com>
	<20141027180010.GB12989@laptop.dumpdata.com>
	<20141027211338.GA17750@laptop.dumpdata.com>
	<544F81640200007800042BE5@mail.emea.novell.com>
	<20141028200734.GA31298@laptop.dumpdata.com>
	<5450B32E0200007800042FC8@mail.emea.novell.com>
	<20141029211125.GA7967@laptop.dumpdata.com>
	<54520D3202000078000435FA@mail.emea.novell.com>
	<20141102200945.GA31191@andromeda.dapyr.net>
In-Reply-To: <20141102200945.GA31191@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, tim@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v8 for-xen-4.5 2/2] dpci: Replace tasklet
 with an softirq (v8)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 21:09, <konrad@darnok.org> wrote:
> 2). Or remove the various 'return -EINVAL' in the  pci_clean_dpci_irqs
>    for the causes where IOMMU is off or there are no PCI passthrough
>    devices - and just make them return 0.

This one I would say - it seems quite natural for these not to fail
but succeed when there's nothing to do.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:47:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08:47:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlDHY-0002q4-3m; Mon, 03 Nov 2014 08:46:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlDHW-0002pz-VY
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 08:46:35 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	1E/EA-02699-AE047545; Mon, 03 Nov 2014 08:46:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415004393!12148011!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14323 invoked from network); 3 Nov 2014 08:46:33 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 08:46:33 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 08:46:32 +0000
Message-Id: <54574EF40200007800044392@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 08:46:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
References: <544E397F0200007800042651@mail.emea.novell.com>
	<20141027170115.GC11893@laptop.dumpdata.com>
	<544E8283.1030907@citrix.com>
	<20141027180010.GB12989@laptop.dumpdata.com>
	<20141027211338.GA17750@laptop.dumpdata.com>
	<544F81640200007800042BE5@mail.emea.novell.com>
	<20141028200734.GA31298@laptop.dumpdata.com>
	<5450B32E0200007800042FC8@mail.emea.novell.com>
	<20141029211125.GA7967@laptop.dumpdata.com>
	<54520D3202000078000435FA@mail.emea.novell.com>
	<20141102200945.GA31191@andromeda.dapyr.net>
In-Reply-To: <20141102200945.GA31191@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, tim@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v8 for-xen-4.5 2/2] dpci: Replace tasklet
 with an softirq (v8)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 21:09, <konrad@darnok.org> wrote:
> 2). Or remove the various 'return -EINVAL' in the  pci_clean_dpci_irqs
>    for the causes where IOMMU is off or there are no PCI passthrough
>    devices - and just make them return 0.

This one I would say - it seems quite natural for these not to fail
but succeed when there's nothing to do.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:50:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08: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 1XlDLS-0002xV-Rr; Mon, 03 Nov 2014 08:50: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 1XlDLR-0002xP-BK
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 08:50:37 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A0/41-26652-CD147545; Mon, 03 Nov 2014 08:50:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415004635!7925603!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9809 invoked from network); 3 Nov 2014 08:50:35 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 08:50:35 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 08:50:35 +0000
Message-Id: <54574FE8020000780004439C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 08:50:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414721915-11186-1-git-send-email-tiejun.chen@intel.com>
	<545361450200007800043DBC@mail.emea.novell.com>
	<5456E26B.9040106@intel.com>
In-Reply-To: <5456E26B.9040106@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: link errno.h from xen
	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 03.11.14 at 03:03, <tiejun.chen@intel.com> wrote:
> On 2014/10/31 17:15, Jan Beulich wrote:
>>>>> On 31.10.14 at 03:18, <tiejun.chen@intel.com> wrote:
>>
>> (You omitted half of the tools maintainers; Cc-ing them now.)
> 
> I think I already pick all relevant maintainers to review this patch,
> 
> $ ./scripts/get_maintainer.pl 
> 0004-tools-hvmloader-link-errno.h-from-xen-internal.patch
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Wei Liu <wei.liu2@citrix.com>
> xen-devel@lists.xen.org 
> 
> So please tell me whom should be included specifically.

It's not clear to me why the script doesn't name the others. Just
go the ./MAINTAINERS and look at the relevant section.

>>> --- a/tools/firmware/hvmloader/Makefile
>>> +++ b/tools/firmware/hvmloader/Makefile
>>> @@ -84,9 +84,13 @@ ROMS += $(SEABIOS_ROM)
>>>   endif
>>>
>>>   .PHONY: all
>>> -all: subdirs-all
>>> +all: subdirs-all .dir
>>>   	$(MAKE) hvmloader
>>>
>>> +.dir:
>>> +	@rm -rf errno.h
>>
>> Why?
> 
> We should make sure we are linking to create a non-existing file, 
> otherwise you may see this,
> 
> ln: failed to create symbolic link '...': File exists

But you know of ln's -f option, don't you?

>>> --- a/tools/firmware/hvmloader/util.h
>>> +++ b/tools/firmware/hvmloader/util.h
>>> @@ -6,6 +6,7 @@
>>>   #include <stddef.h>
>>>   #include <xen/xen.h>
>>>   #include <xen/hvm/hvm_info_table.h>
>>> +#include "errno.h"
>>
>> Does this allow xenbus.c to still build? I think this either should go into
> 
> I did a test as follows:
> 1: make clean
> 2: make xen
> 3: make tools
> 4: make clean
> 5: make tools
> 
> Is this covering xenbus?

Yes, but it's still surprising that including both works. Presumably this is
because the definitions are in fact identical when you build on Linux.
Building elsewhere might then be a problem, so this should be avoid in
any event.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:50:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08: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 1XlDLS-0002xV-Rr; Mon, 03 Nov 2014 08:50: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 1XlDLR-0002xP-BK
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 08:50:37 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A0/41-26652-CD147545; Mon, 03 Nov 2014 08:50:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415004635!7925603!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9809 invoked from network); 3 Nov 2014 08:50:35 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 08:50:35 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 08:50:35 +0000
Message-Id: <54574FE8020000780004439C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 08:50:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414721915-11186-1-git-send-email-tiejun.chen@intel.com>
	<545361450200007800043DBC@mail.emea.novell.com>
	<5456E26B.9040106@intel.com>
In-Reply-To: <5456E26B.9040106@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: link errno.h from xen
	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 03.11.14 at 03:03, <tiejun.chen@intel.com> wrote:
> On 2014/10/31 17:15, Jan Beulich wrote:
>>>>> On 31.10.14 at 03:18, <tiejun.chen@intel.com> wrote:
>>
>> (You omitted half of the tools maintainers; Cc-ing them now.)
> 
> I think I already pick all relevant maintainers to review this patch,
> 
> $ ./scripts/get_maintainer.pl 
> 0004-tools-hvmloader-link-errno.h-from-xen-internal.patch
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Wei Liu <wei.liu2@citrix.com>
> xen-devel@lists.xen.org 
> 
> So please tell me whom should be included specifically.

It's not clear to me why the script doesn't name the others. Just
go the ./MAINTAINERS and look at the relevant section.

>>> --- a/tools/firmware/hvmloader/Makefile
>>> +++ b/tools/firmware/hvmloader/Makefile
>>> @@ -84,9 +84,13 @@ ROMS += $(SEABIOS_ROM)
>>>   endif
>>>
>>>   .PHONY: all
>>> -all: subdirs-all
>>> +all: subdirs-all .dir
>>>   	$(MAKE) hvmloader
>>>
>>> +.dir:
>>> +	@rm -rf errno.h
>>
>> Why?
> 
> We should make sure we are linking to create a non-existing file, 
> otherwise you may see this,
> 
> ln: failed to create symbolic link '...': File exists

But you know of ln's -f option, don't you?

>>> --- a/tools/firmware/hvmloader/util.h
>>> +++ b/tools/firmware/hvmloader/util.h
>>> @@ -6,6 +6,7 @@
>>>   #include <stddef.h>
>>>   #include <xen/xen.h>
>>>   #include <xen/hvm/hvm_info_table.h>
>>> +#include "errno.h"
>>
>> Does this allow xenbus.c to still build? I think this either should go into
> 
> I did a test as follows:
> 1: make clean
> 2: make xen
> 3: make tools
> 4: make clean
> 5: make tools
> 
> Is this covering xenbus?

Yes, but it's still surprising that including both works. Presumably this is
because the definitions are in fact identical when you build on Linux.
Building elsewhere might then be a problem, so this should be avoid in
any event.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:53:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlDOa-0003Ah-H1; Mon, 03 Nov 2014 08:53:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlDOZ-0003AT-8p
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 08:53:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4F/1A-24532-E9247545; Mon, 03 Nov 2014 08:53:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415004829!12327144!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22831 invoked from network); 3 Nov 2014 08:53:49 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 08:53:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 08:53:49 +0000
Message-Id: <545750AA02000078000443AD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 08:53:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
In-Reply-To: <5456E6E9.1080104@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>> when we really need them.
>>>>>>
>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>> include that header (making sure declaration and definition are and
>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>> (and certain other code system components) the consequences of
>>>>>> being lax are much more severe.
>>>>>
>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>> '<xen/memory.h>,
>>>>>
>>>>> #include "util.h"
>>>>> ...
>>>>> #include <xen/memory.h>
>>>>>
>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>
>>>> Redefine? I said forward declare.
>>>
>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>> the head file, tools/firmware/hvmloader/util.h,
>>>
>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>
>> To me this looks very much like poor programming style, even if in
>> the context of hvmloader communicating information via global
>> variables rather than function arguments and return values is
> 
> Do you mean you don't like a global variable? But it can be use to get 
> RDM without more hypercall or function call in the context of hvmloader.

This argument which you brought up before, and which we commented
on before, is pretty pointless. We don't really care much about doing
one or two more hypercalls from hvmloader, unless these would be
long-running ones.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:53:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlDOa-0003Ah-H1; Mon, 03 Nov 2014 08:53:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlDOZ-0003AT-8p
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 08:53:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4F/1A-24532-E9247545; Mon, 03 Nov 2014 08:53:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415004829!12327144!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22831 invoked from network); 3 Nov 2014 08:53:49 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 08:53:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 08:53:49 +0000
Message-Id: <545750AA02000078000443AD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 08:53:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
In-Reply-To: <5456E6E9.1080104@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>> when we really need them.
>>>>>>
>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>> include that header (making sure declaration and definition are and
>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>> (and certain other code system components) the consequences of
>>>>>> being lax are much more severe.
>>>>>
>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>> '<xen/memory.h>,
>>>>>
>>>>> #include "util.h"
>>>>> ...
>>>>> #include <xen/memory.h>
>>>>>
>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>
>>>> Redefine? I said forward declare.
>>>
>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>> the head file, tools/firmware/hvmloader/util.h,
>>>
>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>
>> To me this looks very much like poor programming style, even if in
>> the context of hvmloader communicating information via global
>> variables rather than function arguments and return values is
> 
> Do you mean you don't like a global variable? But it can be use to get 
> RDM without more hypercall or function call in the context of hvmloader.

This argument which you brought up before, and which we commented
on before, is pretty pointless. We don't really care much about doing
one or two more hypercalls from hvmloader, unless these would be
long-running ones.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:56:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlDRH-0003KY-4X; Mon, 03 Nov 2014 08:56:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlDRF-0003KP-Pa
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 08:56:37 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	CD/0D-23865-44347545; Mon, 03 Nov 2014 08:56:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415004996!11156268!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26395 invoked from network); 3 Nov 2014 08:56:36 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 08:56:36 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 08:56:35 +0000
Message-Id: <5457515102000078000443B0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 08:56:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
In-Reply-To: <5457174C.8020400@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>   From: Chen, Tiejun
>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>> Thinking about this some more, this odd universal hole punching in
>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>> this really should be optional behavior, with pass through of devices
>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>> punching holes for _just_ the devices passed through to a guest
>>>>> upon creation when the option is not enabled.)
>>>>
>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>> conflict with anything. So what about this idea?
>>>>
>>>
>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>> approach. When the parameter is on, RMRR check/hole punch is
>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>
>>> If user configures device pass-through at creation time, this parameter
>>> will be set by default. If user wants the VM capable of device hot-plug,
>>> an explicit parameter can be added in the config file to enforce RMRR
>>> check at creation time.
>>
>> Not exactly, I specifically described it slightly differently above. When
>> devices get passed through and the option is absent, holes should be
>> punched only for the RMRRs associated with those devices (i.e.
>> ideally none). Of course this means we'll need a way to associate
>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>> XENMEM_reserved_device_memory_map alone won't suffice.
> 
> Yeah, current hypercall just provide RMRR entries without that 
> associated BDF. And especially, in some cases one range may be shared by 
> multiple devices...

Before we decide who's going to do an eventual change we need to
determine what behavior we want, and whether this hypercall is
really the right one. Quite possibly we'd need a per-domain view
along with the global view, and hence rather than modifying this one
we may need to introduce e.g. a new domctl.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 08:56:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 08:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlDRH-0003KY-4X; Mon, 03 Nov 2014 08:56:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlDRF-0003KP-Pa
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 08:56:37 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	CD/0D-23865-44347545; Mon, 03 Nov 2014 08:56:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415004996!11156268!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26395 invoked from network); 3 Nov 2014 08:56:36 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 08:56:36 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 08:56:35 +0000
Message-Id: <5457515102000078000443B0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 08:56:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
In-Reply-To: <5457174C.8020400@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>   From: Chen, Tiejun
>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>> Thinking about this some more, this odd universal hole punching in
>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>> this really should be optional behavior, with pass through of devices
>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>> punching holes for _just_ the devices passed through to a guest
>>>>> upon creation when the option is not enabled.)
>>>>
>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>> conflict with anything. So what about this idea?
>>>>
>>>
>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>> approach. When the parameter is on, RMRR check/hole punch is
>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>
>>> If user configures device pass-through at creation time, this parameter
>>> will be set by default. If user wants the VM capable of device hot-plug,
>>> an explicit parameter can be added in the config file to enforce RMRR
>>> check at creation time.
>>
>> Not exactly, I specifically described it slightly differently above. When
>> devices get passed through and the option is absent, holes should be
>> punched only for the RMRRs associated with those devices (i.e.
>> ideally none). Of course this means we'll need a way to associate
>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>> XENMEM_reserved_device_memory_map alone won't suffice.
> 
> Yeah, current hypercall just provide RMRR entries without that 
> associated BDF. And especially, in some cases one range may be shared by 
> multiple devices...

Before we decide who's going to do an eventual change we need to
determine what behavior we want, and whether this hypercall is
really the right one. Quite possibly we'd need a per-domain view
along with the global view, and hence rather than modifying this one
we may need to introduce e.g. a new domctl.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:00:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlDV1-0003WN-Td; Mon, 03 Nov 2014 09:00:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlDV0-0003WH-NM
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:00:30 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F2/D9-09842-E2447545; Mon, 03 Nov 2014 09:00:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415005229!12324829!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17784 invoked from network); 3 Nov 2014 09:00:29 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:00:29 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:00:29 +0000
Message-Id: <5457523A02000078000443C7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:00:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
In-Reply-To: <54571E91.4030903@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
> On 2014/10/31 16:25, Jan Beulich wrote:
>>>>> On 31.10.14 at 03:50, <tiejun.chen@intel.com> wrote:
>>> On 2014/10/30 17:24, Jan Beulich wrote:
>>>>>>> On 30.10.14 at 08:39, <tiejun.chen@intel.com> wrote:
>>>>> @@ -686,8 +686,22 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>>>>         /* Now, actually do the two-way mapping */
>>>>>         if ( mfn_valid(_mfn(mfn)) )
>>>>>         {
>>>>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>>>>> -                           p2m->default_access);
>>>>> +        rc = 0;
>>>>> +        a =  p2m->default_access;
>>>>> +        if ( !is_hardware_domain(d) )
>>>>> +        {
>>>>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>>>>> +                                                  &gfn);
>>>>> +            /* We need to set reserved device memory as p2m_access_n. */
>>>>> +            if ( rc == 1 )
>>>>> +                a = p2m_access_n;
>>>>> +            else if ( rc < 0 )
>>>>> +                printk(XENLOG_WARNING
>>>>> +                       "Domain %d can't check reserved device memory.\n",
>>>>> +                       d->domain_id);
>>>>> +        }
>>>>> +
>>>>> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
>>>>>             if ( rc )
>>>>>                 goto out; /* Failed to update p2m, bail without updating m2p.
>>> */
>>>>
>>>> The handling of "a" looks good now, but the error handling and
>>>> logging is still as broken as it was before.
>>>
>>> Do you mean I'm missing some necessary info? Like gfn and mfn, so domain
>>> id, gfn and mfn can show enough message.
>>>
>>> Sorry I'm poor to understand what you expect.
>>
>> But I explained it already, and that explanation is still visible in
>> the quotes above. But to avoid any doubt, I'll repeat: "And
> 
> I tried to understand what you said but felt a confusion so ask if you 
> show me directly.
> 
>> properly handle the error case (just logging a message - which
>> btw lacks a proper XENLOG_G_* prefix - doesn't seem enough
>> to me)."
> 
> Looks there are two problems:
> 
> #1: the error message
> 
> If current line is not fine,
> 	printk(XENLOG_G_WARNING "Domain %d can't check reserved device 
> memory.\n", d->domain_id);
> 
> I mean could you change this directly.

This looks reasonable, albeit we generally prefer Dom%d or dom%d
so that messages are somewhat grep-able.

> #2 the error handling
> 
> In an error case what should I do? Currently we still create these 
> mapping as normal. This means these mfns will be valid so later we can't 
> set them again then device can't be assigned as passthrough. I think 
> this makes sense. Or we should just stop them from setting 1:1 mapping?

You should, with very few exceptions, not ignore errors (which
includes "handling" them by just logging a message. Instead, you
should propagate the error back up the call chain.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:00:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlDV1-0003WN-Td; Mon, 03 Nov 2014 09:00:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlDV0-0003WH-NM
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:00:30 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F2/D9-09842-E2447545; Mon, 03 Nov 2014 09:00:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415005229!12324829!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17784 invoked from network); 3 Nov 2014 09:00:29 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:00:29 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:00:29 +0000
Message-Id: <5457523A02000078000443C7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:00:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
In-Reply-To: <54571E91.4030903@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
> On 2014/10/31 16:25, Jan Beulich wrote:
>>>>> On 31.10.14 at 03:50, <tiejun.chen@intel.com> wrote:
>>> On 2014/10/30 17:24, Jan Beulich wrote:
>>>>>>> On 30.10.14 at 08:39, <tiejun.chen@intel.com> wrote:
>>>>> @@ -686,8 +686,22 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>>>>         /* Now, actually do the two-way mapping */
>>>>>         if ( mfn_valid(_mfn(mfn)) )
>>>>>         {
>>>>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>>>>> -                           p2m->default_access);
>>>>> +        rc = 0;
>>>>> +        a =  p2m->default_access;
>>>>> +        if ( !is_hardware_domain(d) )
>>>>> +        {
>>>>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>>>>> +                                                  &gfn);
>>>>> +            /* We need to set reserved device memory as p2m_access_n. */
>>>>> +            if ( rc == 1 )
>>>>> +                a = p2m_access_n;
>>>>> +            else if ( rc < 0 )
>>>>> +                printk(XENLOG_WARNING
>>>>> +                       "Domain %d can't check reserved device memory.\n",
>>>>> +                       d->domain_id);
>>>>> +        }
>>>>> +
>>>>> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
>>>>>             if ( rc )
>>>>>                 goto out; /* Failed to update p2m, bail without updating m2p.
>>> */
>>>>
>>>> The handling of "a" looks good now, but the error handling and
>>>> logging is still as broken as it was before.
>>>
>>> Do you mean I'm missing some necessary info? Like gfn and mfn, so domain
>>> id, gfn and mfn can show enough message.
>>>
>>> Sorry I'm poor to understand what you expect.
>>
>> But I explained it already, and that explanation is still visible in
>> the quotes above. But to avoid any doubt, I'll repeat: "And
> 
> I tried to understand what you said but felt a confusion so ask if you 
> show me directly.
> 
>> properly handle the error case (just logging a message - which
>> btw lacks a proper XENLOG_G_* prefix - doesn't seem enough
>> to me)."
> 
> Looks there are two problems:
> 
> #1: the error message
> 
> If current line is not fine,
> 	printk(XENLOG_G_WARNING "Domain %d can't check reserved device 
> memory.\n", d->domain_id);
> 
> I mean could you change this directly.

This looks reasonable, albeit we generally prefer Dom%d or dom%d
so that messages are somewhat grep-able.

> #2 the error handling
> 
> In an error case what should I do? Currently we still create these 
> mapping as normal. This means these mfns will be valid so later we can't 
> set them again then device can't be assigned as passthrough. I think 
> this makes sense. Or we should just stop them from setting 1:1 mapping?

You should, with very few exceptions, not ignore errors (which
includes "handling" them by just logging a message. Instead, you
should propagate the error back up the call chain.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:07:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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 1XlDc2-0003n4-UR; Mon, 03 Nov 2014 09:07:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlDc1-0003mz-00
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:07:45 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	98/5F-11581-0E547545; Mon, 03 Nov 2014 09:07:44 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415005661!5406441!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 920 invoked from network); 3 Nov 2014 09:07:43 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-14.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 09:07:43 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 03 Nov 2014 01:01:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="615898275"
Received: from tchen0-linux.bj.intel.com ([10.238.154.56])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 01:05:43 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: Ian.Jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Campbell@eu.citrix.com, wei.liu2@citrix.com
Date: Mon,  3 Nov 2014 17:00:48 +0800
Message-Id: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: JBeulich@suse.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
	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>
MIME-Version: 1.0
Content-Type: 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 act on some specific hypercall error numbers, so
require the hypervisor view on the errno.h value rather than
just the build environment's number. So here link this headfile
from xen.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
v2:

* CCed more tools MAINTAINERS
* Rephrase long log
* Remove this line '@rm -rf errno.h' since we always force link
* Drop including this head file in util.c directly

 .gitignore                        | 1 +
 tools/firmware/hvmloader/Makefile | 7 +++++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index b24e905..52c3038 100644
--- a/.gitignore
+++ b/.gitignore
@@ -127,6 +127,7 @@ tools/firmware/hvmloader/acpi/ssdt_*.h
 tools/firmware/hvmloader/hvmloader
 tools/firmware/hvmloader/roms.h
 tools/firmware/hvmloader/roms.inc
+tools/firmware/hvmloader/errno.h
 tools/firmware/rombios/BIOS-bochs-[^/]*
 tools/firmware/rombios/_rombios[^/]*_.c
 tools/firmware/rombios/rombios[^/]*.s
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 46a79c5..333350b 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -84,9 +84,12 @@ ROMS += $(SEABIOS_ROM)
 endif
 
 .PHONY: all
-all: subdirs-all
+all: subdirs-all .dir
 	$(MAKE) hvmloader
 
+.dir:
+	ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
+
 ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
 
@@ -136,7 +139,7 @@ endif
 
 .PHONY: clean
 clean: subdirs-clean
-	rm -f roms.inc roms.inc.new acpi.h
+	rm -f roms.inc roms.inc.new acpi.h errno.h
 	rm -f hvmloader hvmloader.tmp *.o $(DEPS)
 
 -include $(DEPS)
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:07:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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 1XlDc2-0003n4-UR; Mon, 03 Nov 2014 09:07:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlDc1-0003mz-00
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:07:45 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	98/5F-11581-0E547545; Mon, 03 Nov 2014 09:07:44 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415005661!5406441!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 920 invoked from network); 3 Nov 2014 09:07:43 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-14.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 09:07:43 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 03 Nov 2014 01:01:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="615898275"
Received: from tchen0-linux.bj.intel.com ([10.238.154.56])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 01:05:43 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: Ian.Jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Campbell@eu.citrix.com, wei.liu2@citrix.com
Date: Mon,  3 Nov 2014 17:00:48 +0800
Message-Id: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: JBeulich@suse.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
	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>
MIME-Version: 1.0
Content-Type: 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 act on some specific hypercall error numbers, so
require the hypervisor view on the errno.h value rather than
just the build environment's number. So here link this headfile
from xen.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
v2:

* CCed more tools MAINTAINERS
* Rephrase long log
* Remove this line '@rm -rf errno.h' since we always force link
* Drop including this head file in util.c directly

 .gitignore                        | 1 +
 tools/firmware/hvmloader/Makefile | 7 +++++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index b24e905..52c3038 100644
--- a/.gitignore
+++ b/.gitignore
@@ -127,6 +127,7 @@ tools/firmware/hvmloader/acpi/ssdt_*.h
 tools/firmware/hvmloader/hvmloader
 tools/firmware/hvmloader/roms.h
 tools/firmware/hvmloader/roms.inc
+tools/firmware/hvmloader/errno.h
 tools/firmware/rombios/BIOS-bochs-[^/]*
 tools/firmware/rombios/_rombios[^/]*_.c
 tools/firmware/rombios/rombios[^/]*.s
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 46a79c5..333350b 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -84,9 +84,12 @@ ROMS += $(SEABIOS_ROM)
 endif
 
 .PHONY: all
-all: subdirs-all
+all: subdirs-all .dir
 	$(MAKE) hvmloader
 
+.dir:
+	ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
+
 ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
 
@@ -136,7 +139,7 @@ endif
 
 .PHONY: clean
 clean: subdirs-clean
-	rm -f roms.inc roms.inc.new acpi.h
+	rm -f roms.inc roms.inc.new acpi.h errno.h
 	rm -f hvmloader hvmloader.tmp *.o $(DEPS)
 
 -include $(DEPS)
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:32:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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 1XlDzT-0004GX-Po; Mon, 03 Nov 2014 09:31:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlDzS-0004GQ-MF
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 09:31:58 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	D3/66-16982-D8B47545; Mon, 03 Nov 2014 09:31:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415007115!11211404!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3482 invoked from network); 3 Nov 2014 09:31:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 09:31:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="187444075"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 04:31:54 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlDzL-0006Zv-P7;
	Mon, 03 Nov 2014 09:31:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlDzL-0004Ys-CM;
	Mon, 03 Nov 2014 09:31:51 +0000
Date: Mon, 3 Nov 2014 09:31:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31331-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31331: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 03 09:32:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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 1XlDzT-0004GX-Po; Mon, 03 Nov 2014 09:31:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlDzS-0004GQ-MF
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 09:31:58 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	D3/66-16982-D8B47545; Mon, 03 Nov 2014 09:31:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415007115!11211404!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3482 invoked from network); 3 Nov 2014 09:31:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 09:31:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="187444075"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 04:31:54 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlDzL-0006Zv-P7;
	Mon, 03 Nov 2014 09:31:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlDzL-0004Ys-CM;
	Mon, 03 Nov 2014 09:31:51 +0000
Date: Mon, 3 Nov 2014 09:31:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31331-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31331: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 03 09:33:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:33:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlE0X-0004Lg-7n; Mon, 03 Nov 2014 09:33:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlE0V-0004LQ-7D
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:33:03 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	71/AA-22777-ECB47545; Mon, 03 Nov 2014 09:33:02 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415007181!10839795!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14701 invoked from network); 3 Nov 2014 09:33:01 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 09:33:01 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 01:33:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="625354994"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga002.fm.intel.com with ESMTP; 03 Nov 2014 01:32:49 -0800
Message-ID: <54574BC0.7000709@intel.com>
Date: Mon, 03 Nov 2014 17:32:48 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
In-Reply-To: <545750AA02000078000443AD@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 16:53, Jan Beulich wrote:
>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>>> when we really need them.
>>>>>>>
>>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>> include that header (making sure declaration and definition are and
>>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>>> (and certain other code system components) the consequences of
>>>>>>> being lax are much more severe.
>>>>>>
>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>> '<xen/memory.h>,
>>>>>>
>>>>>> #include "util.h"
>>>>>> ...
>>>>>> #include <xen/memory.h>
>>>>>>
>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>
>>>>> Redefine? I said forward declare.
>>>>
>>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>
>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>
>>> To me this looks very much like poor programming style, even if in
>>> the context of hvmloader communicating information via global
>>> variables rather than function arguments and return values is
>>
>> Do you mean you don't like a global variable? But it can be use to get
>> RDM without more hypercall or function call in the context of hvmloader.
>
> This argument which you brought up before, and which we commented
> on before, is pretty pointless. We don't really care much about doing
> one or two more hypercalls from hvmloader, unless these would be
> long-running ones.
>

Another benefit to use a global variable is that we wouldn't allocate 
xen_reserved_device_memory * N each time, and reduce some duplicated 
codes, unless you mean I should define that as static inside in local.

Thanks
Tiejun


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:33:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:33:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlE0X-0004Lg-7n; Mon, 03 Nov 2014 09:33:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlE0V-0004LQ-7D
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:33:03 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	71/AA-22777-ECB47545; Mon, 03 Nov 2014 09:33:02 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415007181!10839795!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14701 invoked from network); 3 Nov 2014 09:33:01 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 09:33:01 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 01:33:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="625354994"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga002.fm.intel.com with ESMTP; 03 Nov 2014 01:32:49 -0800
Message-ID: <54574BC0.7000709@intel.com>
Date: Mon, 03 Nov 2014 17:32:48 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
In-Reply-To: <545750AA02000078000443AD@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 16:53, Jan Beulich wrote:
>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>>> when we really need them.
>>>>>>>
>>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>> include that header (making sure declaration and definition are and
>>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>>> (and certain other code system components) the consequences of
>>>>>>> being lax are much more severe.
>>>>>>
>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>> '<xen/memory.h>,
>>>>>>
>>>>>> #include "util.h"
>>>>>> ...
>>>>>> #include <xen/memory.h>
>>>>>>
>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>
>>>>> Redefine? I said forward declare.
>>>>
>>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>
>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>
>>> To me this looks very much like poor programming style, even if in
>>> the context of hvmloader communicating information via global
>>> variables rather than function arguments and return values is
>>
>> Do you mean you don't like a global variable? But it can be use to get
>> RDM without more hypercall or function call in the context of hvmloader.
>
> This argument which you brought up before, and which we commented
> on before, is pretty pointless. We don't really care much about doing
> one or two more hypercalls from hvmloader, unless these would be
> long-running ones.
>

Another benefit to use a global variable is that we wouldn't allocate 
xen_reserved_device_memory * N each time, and reduce some duplicated 
codes, unless you mean I should define that as static inside in local.

Thanks
Tiejun


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:33:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:33:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlE14-0004R4-Lp; Mon, 03 Nov 2014 09:33: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 1XlE13-0004Qf-Eh
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:33:37 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	FA/81-18267-0FB47545; Mon, 03 Nov 2014 09:33:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415007216!6785073!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23512 invoked from network); 3 Nov 2014 09:33:36 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:33:36 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:33:35 +0000
Message-Id: <545759FB02000078000443F2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:33:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roy Franz" <roy.franz@linaro.org>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
In-Reply-To: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, daniel.kiper@oracle.com, tim@xen.org,
	xen-devel@lists.xen.org, stefano.stabellini@citrix.com, fu.wei@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
> This patch implements what I understand to be the desired behavior when 
> booting
> an EFI Xen image via GRUB based on the thread last week.  The EFI command 
> line
> is not used, and the Xen commandline comes via the multiboot protocol (and
> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
> GRUB EFI boot cases into alignment in not using the EFI commandline.

Right, but ...

> The current state of the arm64 code takes the Xen commandline from the FDT,
> but still looks in the EFI commandline for EFI boot specific options.  If
> unexpected options are passed in the EFI commandline, it will generate
> "unrecognized option" ouput for all unexpected options.

... why is this?

> +    if ( use_cfg_file )
>      {
>          EFI_FILE_HANDLE dir_handle;
> +        size = 0;

Coding style (missing blank line between declaration(s) and
statement(s). Plus - did you check whether some of the so far
function wide variables (e.g. gop) could be moved into this more
narrow scope?

>              }
>          }
>      }
> -
>      efi_arch_edd();
>  
>      /* XXX Collect EDID info. */

Please don't.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:33:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:33:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlE14-0004R4-Lp; Mon, 03 Nov 2014 09:33: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 1XlE13-0004Qf-Eh
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:33:37 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	FA/81-18267-0FB47545; Mon, 03 Nov 2014 09:33:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415007216!6785073!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23512 invoked from network); 3 Nov 2014 09:33:36 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:33:36 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:33:35 +0000
Message-Id: <545759FB02000078000443F2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:33:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roy Franz" <roy.franz@linaro.org>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
In-Reply-To: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, daniel.kiper@oracle.com, tim@xen.org,
	xen-devel@lists.xen.org, stefano.stabellini@citrix.com, fu.wei@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
> This patch implements what I understand to be the desired behavior when 
> booting
> an EFI Xen image via GRUB based on the thread last week.  The EFI command 
> line
> is not used, and the Xen commandline comes via the multiboot protocol (and
> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
> GRUB EFI boot cases into alignment in not using the EFI commandline.

Right, but ...

> The current state of the arm64 code takes the Xen commandline from the FDT,
> but still looks in the EFI commandline for EFI boot specific options.  If
> unexpected options are passed in the EFI commandline, it will generate
> "unrecognized option" ouput for all unexpected options.

... why is this?

> +    if ( use_cfg_file )
>      {
>          EFI_FILE_HANDLE dir_handle;
> +        size = 0;

Coding style (missing blank line between declaration(s) and
statement(s). Plus - did you check whether some of the so far
function wide variables (e.g. gop) could be moved into this more
narrow scope?

>              }
>          }
>      }
> -
>      efi_arch_edd();
>  
>      /* XXX Collect EDID info. */

Please don't.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:40:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlE7O-0004mP-Lc; Mon, 03 Nov 2014 09:40:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XlE7M-0004mK-Tx
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:40:09 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	1F/19-09284-87D47545; Mon, 03 Nov 2014 09:40:08 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415007607!11168926!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10691 invoked from network); 3 Nov 2014 09:40:07 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:40:07 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=SXiaUgVSKCDYhfMyrBekZjIqiSjD5obesEqc5WB0l3WWIrYQwlhVALXDnLhO7DGIa9phOXfgl/cMPkC1XaMqSnmQ9M0xzS6np+Mz7PSsMZZGoVCYeSan9aHtwBGgiel+PlyP/M6LFGX8an/cqKFsPDUnoBjof/cw34Vz/0j4J/ieSOECwhWDoiCkNS9BsH5EBJpA+XqCwxi50gjgv3rsZTmeUWh56cO46bE3rna6wNBc6fbDYnp1XX9t8hID04O4EM36TQL4LR9amPj54gJHxzUB7CLKh3NBLs7mBLqYIv4oclcPQi8e4lBLNnfw6gnDs1PPp58w5pcSo69eOsKC9A==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=from:to
	:cc:subject:date:message-id; s=default; bh=VShbc8j+1PSFmQ15+9idY
	URPH0o=; b=brPn6MmxepMofKrzLBQceHkYvpv5qO+CZE9aLzMjJ4Bksmywa8hO+
	aW8pwBQnuJ3s33lpSKpJ2gy7nyV9xKbE5joEQk7iUQpeZK+BDjjWL5hLVNani/gp
	3pEp/XjROUazAfc3z2nUlq7QNir1QfExILdE0ykYTljpud0JWzgmja7OkMjUpQUd
	h2ATLZ9ZrlQu0Uzv67jgfRY33s4l5FEjyxSFWjJsZ5rXRKzI8w6Kj2aIRfSN/cSW
	aZPhOrvxNgo/QKy2RfJ0BF8A+/nsqNEhaQiO7o8C9+vUcYs2es8aPP76BSGGNcNL
	TAj8z/cmm7oAg7LEOZFnAwubkt8WPIfJQ==
Received: (qmail 2328 invoked from network); 3 Nov 2014 11:40:02 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	3 Nov 2014 11:40:02 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id DBB638017F
	for <xen-devel@lists.xen.org>; Mon,  3 Nov 2014 11:40:01 +0200 (EET)
Received: (qmail 10287 invoked from network); 3 Nov 2014 11:40:01 +0200
Received: from xen.dsd.ro (HELO xen.dsd.bitdefender.biz)
	(rcojocaru@bitdefender.com@10.10.14.109)
	by smtp02.buh.bitdefender.net with AES256-SHA encrypted SMTP;
	3 Nov 2014 11:39:55 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: xen-devel@lists.xen.org
Date: Mon,  3 Nov 2014 11:39:38 +0200
Message-Id: <1415007578-7584-1-git-send-email-rcojocaru@bitdefender.com>
X-Mailer: git-send-email 1.7.9.5
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.57529
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.520, Dats: 371241,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_LARGER;
	NN_NO_CONTENT_TYPE; NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER;
	NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled],
	URL: [Enabled], RTDA: [Enabled, Hit: No, Details: v1.9.3; Id:
	2m1ghdn.1957q4tco.23jliv], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: keir@xen.org, Razvan Cojocaru <rcojocaru@bitdefender.com>,
	jbeulich@suse.com
Subject: [Xen-devel] [PATCH] xen: Disable emulate.c REP optimization if
	introspection is active
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Emulation for REP instructions is optimized to perform a single
write for all repeats in the current page if possible. However,
this interferes with a memory introspection application's ability
to detect suspect behaviour, since it will cause only one
mem_event to be sent per page touched.
This patch disables the optimization, gated on introspection
being active for the domain.

Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
---
 xen/arch/x86/hvm/emulate.c |   16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index c0f47d2..e53f390 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -395,6 +395,7 @@ static int hvmemul_virtual_to_linear(
 {
     struct segment_register *reg;
     int okay;
+    struct domain *currd = current->domain;
 
     if ( seg == x86_seg_none )
     {
@@ -402,12 +403,15 @@ static int hvmemul_virtual_to_linear(
         return X86EMUL_OKAY;
     }
 
-    /*
-     * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
-     * The chosen maximum is very conservative but it's what we use in
-     * hvmemul_linear_to_phys() so there is no point in using a larger value.
-     */
-    *reps = min_t(unsigned long, *reps, 4096);
+    if ( currd->arch.hvm_domain.introspection_enabled )
+        *reps = 1;
+    else
+        /*
+         * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
+         * The chosen maximum is very conservative but it's what we use in
+         * hvmemul_linear_to_phys() so there is no point in using a larger value.
+         */
+        *reps = min_t(unsigned long, *reps, 4096);
 
     reg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
 
-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:40:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlE7O-0004mP-Lc; Mon, 03 Nov 2014 09:40:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XlE7M-0004mK-Tx
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:40:09 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	1F/19-09284-87D47545; Mon, 03 Nov 2014 09:40:08 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415007607!11168926!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10691 invoked from network); 3 Nov 2014 09:40:07 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:40:07 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=SXiaUgVSKCDYhfMyrBekZjIqiSjD5obesEqc5WB0l3WWIrYQwlhVALXDnLhO7DGIa9phOXfgl/cMPkC1XaMqSnmQ9M0xzS6np+Mz7PSsMZZGoVCYeSan9aHtwBGgiel+PlyP/M6LFGX8an/cqKFsPDUnoBjof/cw34Vz/0j4J/ieSOECwhWDoiCkNS9BsH5EBJpA+XqCwxi50gjgv3rsZTmeUWh56cO46bE3rna6wNBc6fbDYnp1XX9t8hID04O4EM36TQL4LR9amPj54gJHxzUB7CLKh3NBLs7mBLqYIv4oclcPQi8e4lBLNnfw6gnDs1PPp58w5pcSo69eOsKC9A==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=from:to
	:cc:subject:date:message-id; s=default; bh=VShbc8j+1PSFmQ15+9idY
	URPH0o=; b=brPn6MmxepMofKrzLBQceHkYvpv5qO+CZE9aLzMjJ4Bksmywa8hO+
	aW8pwBQnuJ3s33lpSKpJ2gy7nyV9xKbE5joEQk7iUQpeZK+BDjjWL5hLVNani/gp
	3pEp/XjROUazAfc3z2nUlq7QNir1QfExILdE0ykYTljpud0JWzgmja7OkMjUpQUd
	h2ATLZ9ZrlQu0Uzv67jgfRY33s4l5FEjyxSFWjJsZ5rXRKzI8w6Kj2aIRfSN/cSW
	aZPhOrvxNgo/QKy2RfJ0BF8A+/nsqNEhaQiO7o8C9+vUcYs2es8aPP76BSGGNcNL
	TAj8z/cmm7oAg7LEOZFnAwubkt8WPIfJQ==
Received: (qmail 2328 invoked from network); 3 Nov 2014 11:40:02 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	3 Nov 2014 11:40:02 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id DBB638017F
	for <xen-devel@lists.xen.org>; Mon,  3 Nov 2014 11:40:01 +0200 (EET)
Received: (qmail 10287 invoked from network); 3 Nov 2014 11:40:01 +0200
Received: from xen.dsd.ro (HELO xen.dsd.bitdefender.biz)
	(rcojocaru@bitdefender.com@10.10.14.109)
	by smtp02.buh.bitdefender.net with AES256-SHA encrypted SMTP;
	3 Nov 2014 11:39:55 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: xen-devel@lists.xen.org
Date: Mon,  3 Nov 2014 11:39:38 +0200
Message-Id: <1415007578-7584-1-git-send-email-rcojocaru@bitdefender.com>
X-Mailer: git-send-email 1.7.9.5
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.57529
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.520, Dats: 371241,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_LARGER;
	NN_NO_CONTENT_TYPE; NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER;
	NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled],
	URL: [Enabled], RTDA: [Enabled, Hit: No, Details: v1.9.3; Id:
	2m1ghdn.1957q4tco.23jliv], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: keir@xen.org, Razvan Cojocaru <rcojocaru@bitdefender.com>,
	jbeulich@suse.com
Subject: [Xen-devel] [PATCH] xen: Disable emulate.c REP optimization if
	introspection is active
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Emulation for REP instructions is optimized to perform a single
write for all repeats in the current page if possible. However,
this interferes with a memory introspection application's ability
to detect suspect behaviour, since it will cause only one
mem_event to be sent per page touched.
This patch disables the optimization, gated on introspection
being active for the domain.

Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
---
 xen/arch/x86/hvm/emulate.c |   16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index c0f47d2..e53f390 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -395,6 +395,7 @@ static int hvmemul_virtual_to_linear(
 {
     struct segment_register *reg;
     int okay;
+    struct domain *currd = current->domain;
 
     if ( seg == x86_seg_none )
     {
@@ -402,12 +403,15 @@ static int hvmemul_virtual_to_linear(
         return X86EMUL_OKAY;
     }
 
-    /*
-     * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
-     * The chosen maximum is very conservative but it's what we use in
-     * hvmemul_linear_to_phys() so there is no point in using a larger value.
-     */
-    *reps = min_t(unsigned long, *reps, 4096);
+    if ( currd->arch.hvm_domain.introspection_enabled )
+        *reps = 1;
+    else
+        /*
+         * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
+         * The chosen maximum is very conservative but it's what we use in
+         * hvmemul_linear_to_phys() so there is no point in using a larger value.
+         */
+        *reps = min_t(unsigned long, *reps, 4096);
 
     reg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
 
-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:40:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlE7r-0004oY-3v; Mon, 03 Nov 2014 09:40:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlE7o-0004oF-UP
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:40:37 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	3A/20-14214-49D47545; Mon, 03 Nov 2014 09:40:36 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415007635!10839982!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10870 invoked from network); 3 Nov 2014 09:40:35 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-4.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 09:40:35 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 01:40:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="625358019"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga002.fm.intel.com with ESMTP; 03 Nov 2014 01:40:32 -0800
Message-ID: <54574D8F.8060407@intel.com>
Date: Mon, 03 Nov 2014 17:40:31 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
In-Reply-To: <5457515102000078000443B0@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 16:56, Jan Beulich wrote:
>>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
>> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>>    From: Chen, Tiejun
>>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>>> Thinking about this some more, this odd universal hole punching in
>>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>>> this really should be optional behavior, with pass through of devices
>>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>>> punching holes for _just_ the devices passed through to a guest
>>>>>> upon creation when the option is not enabled.)
>>>>>
>>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>>> conflict with anything. So what about this idea?
>>>>>
>>>>
>>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>>> approach. When the parameter is on, RMRR check/hole punch is
>>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>>
>>>> If user configures device pass-through at creation time, this parameter
>>>> will be set by default. If user wants the VM capable of device hot-plug,
>>>> an explicit parameter can be added in the config file to enforce RMRR
>>>> check at creation time.
>>>
>>> Not exactly, I specifically described it slightly differently above. When
>>> devices get passed through and the option is absent, holes should be
>>> punched only for the RMRRs associated with those devices (i.e.
>>> ideally none). Of course this means we'll need a way to associate
>>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>>> XENMEM_reserved_device_memory_map alone won't suffice.
>>
>> Yeah, current hypercall just provide RMRR entries without that
>> associated BDF. And especially, in some cases one range may be shared by
>> multiple devices...
>
> Before we decide who's going to do an eventual change we need to
> determine what behavior we want, and whether this hypercall is
> really the right one. Quite possibly we'd need a per-domain view
> along with the global view, and hence rather than modifying this one
> we may need to introduce e.g. a new domctl.
>

If we really need to work with a hypercall, maybe we can introduce a 
little bit to construct that to callback with multiple entries like 
this, for instance,

RMRR entry0 have three devices, and entry1 have two devices,

[start0, nr_pages0, bdf0],
[start0, nr_pages0, bdf1],
[start0, nr_pages0, bdf2],
[start1, nr_pages1, bdf3],
[start1, nr_pages1, bdf4],

Although its cost more buffers, actually as you know this actual case is 
really rare. So maybe this way can be feasible. Then we don't need 
additional hypercall or xenstore.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:40:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlE7r-0004oY-3v; Mon, 03 Nov 2014 09:40:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlE7o-0004oF-UP
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:40:37 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	3A/20-14214-49D47545; Mon, 03 Nov 2014 09:40:36 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415007635!10839982!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10870 invoked from network); 3 Nov 2014 09:40:35 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-4.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 09:40:35 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 01:40:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="625358019"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga002.fm.intel.com with ESMTP; 03 Nov 2014 01:40:32 -0800
Message-ID: <54574D8F.8060407@intel.com>
Date: Mon, 03 Nov 2014 17:40:31 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
In-Reply-To: <5457515102000078000443B0@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 16:56, Jan Beulich wrote:
>>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
>> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>>    From: Chen, Tiejun
>>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>>> Thinking about this some more, this odd universal hole punching in
>>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>>> this really should be optional behavior, with pass through of devices
>>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>>> punching holes for _just_ the devices passed through to a guest
>>>>>> upon creation when the option is not enabled.)
>>>>>
>>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>>> conflict with anything. So what about this idea?
>>>>>
>>>>
>>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>>> approach. When the parameter is on, RMRR check/hole punch is
>>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>>
>>>> If user configures device pass-through at creation time, this parameter
>>>> will be set by default. If user wants the VM capable of device hot-plug,
>>>> an explicit parameter can be added in the config file to enforce RMRR
>>>> check at creation time.
>>>
>>> Not exactly, I specifically described it slightly differently above. When
>>> devices get passed through and the option is absent, holes should be
>>> punched only for the RMRRs associated with those devices (i.e.
>>> ideally none). Of course this means we'll need a way to associate
>>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>>> XENMEM_reserved_device_memory_map alone won't suffice.
>>
>> Yeah, current hypercall just provide RMRR entries without that
>> associated BDF. And especially, in some cases one range may be shared by
>> multiple devices...
>
> Before we decide who's going to do an eventual change we need to
> determine what behavior we want, and whether this hypercall is
> really the right one. Quite possibly we'd need a per-domain view
> along with the global view, and hence rather than modifying this one
> we may need to introduce e.g. a new domctl.
>

If we really need to work with a hypercall, maybe we can introduce a 
little bit to construct that to callback with multiple entries like 
this, for instance,

RMRR entry0 have three devices, and entry1 have two devices,

[start0, nr_pages0, bdf0],
[start0, nr_pages0, bdf1],
[start0, nr_pages0, bdf2],
[start1, nr_pages1, bdf3],
[start1, nr_pages1, bdf4],

Although its cost more buffers, actually as you know this actual case is 
really rare. So maybe this way can be feasible. Then we don't need 
additional hypercall or xenstore.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:43:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEAO-00055W-Si; Mon, 03 Nov 2014 09:43:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlEAN-00055O-QD
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:43:15 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	3C/DE-09284-33E47545; Mon, 03 Nov 2014 09:43:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415007794!11188753!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31174 invoked from network); 3 Nov 2014 09:43:14 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:43:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:43:14 +0000
Message-Id: <54575C3E020000780004440F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:43:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
 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 03.11.14 at 10:00, <tiejun.chen@intel.com> wrote:
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -84,9 +84,12 @@ ROMS += $(SEABIOS_ROM)
>  endif
>  
>  .PHONY: all
> -all: subdirs-all
> +all: subdirs-all .dir

Considering uses going forward, I think subdirs-all should depend on
.dir (which is being misnamed anyway, presumably due to blindly
taking what is in tools/include/Makefile, where a directory _is_ being
created). Considering that it's an individual file, the file name would
seem quite right to be used as dependency 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 Nov 03 09:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:43:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEAO-00055W-Si; Mon, 03 Nov 2014 09:43:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlEAN-00055O-QD
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:43:15 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	3C/DE-09284-33E47545; Mon, 03 Nov 2014 09:43:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415007794!11188753!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31174 invoked from network); 3 Nov 2014 09:43:14 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:43:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:43:14 +0000
Message-Id: <54575C3E020000780004440F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:43:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
 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 03.11.14 at 10:00, <tiejun.chen@intel.com> wrote:
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -84,9 +84,12 @@ ROMS += $(SEABIOS_ROM)
>  endif
>  
>  .PHONY: all
> -all: subdirs-all
> +all: subdirs-all .dir

Considering uses going forward, I think subdirs-all should depend on
.dir (which is being misnamed anyway, presumably due to blindly
taking what is in tools/include/Makefile, where a directory _is_ being
created). Considering that it's an individual file, the file name would
seem quite right to be used as dependency 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 Nov 03 09:43:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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 1XlEAi-00058b-8u; Mon, 03 Nov 2014 09:43:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlEAg-000588-Rz
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 09:43:35 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	6E/EE-02699-64E47545; Mon, 03 Nov 2014 09:43:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415007812!12148459!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31426 invoked from network); 3 Nov 2014 09:43:33 -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;
	3 Nov 2014 09:43:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="187446271"
Message-ID: <1415007810.9994.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <Ian.Jackson@eu.citrix.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>, Anthony Perard
	<anthony.perard@citrix.com>
Date: Mon, 3 Nov 2014 09:43:30 +0000
In-Reply-To: <osstest-31329-mainreport@xen.org>
References: <osstest-31329-mainreport@xen.org>
Organization: Citrix Systems, Inc.
Content-Length: 14124
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TG9va3MgbGlrZSB0aGlzIHRlc3QgaGFzbid0IHN1Y2NlZWRlZCBzaW5jZSA2IE9jdG9iZXIgKGZs
aWdodCAzMDYwMykuCgpMb29raW5nIG92ZXIgdGhlIHZhcmlvdXMgZmFpbHVyZXMgc2luY2UgdGhl
biB0aGUgCiB0ZXN0LWFtZDY0LWkzODYtcGFpciAgIDE3IGd1ZXN0LW1pZ3JhdGUvc3JjX2hvc3Qv
ZHN0X2hvc3QgZmFpbCBSRUdSLiB2cy4gMzA2MDMKb25lIGhhcyBiZWVuIGNvbnNpc3RlbnRseSBm
YWlsaW5nLgoKVGhlcmUgYXJlIGEgcmFuZG9tIHNtYXR0ZXJpbmcgb2Ygb3RoZXIgZmFpbHVyZXMs
IHRoZSBhcm1oZiBndWVzdC1zdGFydApvbmUgYmVsb3cgYW5kIGFsc28gc29tZSBvZiB0aGUgdXN1
YWwgaGVpc2VuYnVncy4KCkNvdWxkIHNvbWVvbmUgaGF2ZSBhIGxvb2sgcGxlYXNlLgoKSWFuLCBk
b2Vzbid0IGxvb2sgbGlrZSB0aGUgYmlzZWN0b3IgaGFzIGhhZCBhIGdvIGF0IHRoaXMsIGFueSBp
ZGVhIHdoeT8KCk9uIE1vbiwgMjAxNC0xMS0wMyBhdCAwNjo0OCArMDAwMCwgeGVuLm9yZyB3cm90
ZToKPiBmbGlnaHQgMzEzMjkgcWVtdS1tYWlubGluZSByZWFsIFtyZWFsXQo+IGh0dHA6Ly93d3cu
Y2hpYXJrLmdyZWVuZW5kLm9yZy51ay9+eGVuc3JjdHMvbG9ncy8zMTMyOS8KPiAKPiBSZWdyZXNz
aW9ucyA6LSgKPiAKPiBUZXN0cyB3aGljaCBkaWQgbm90IHN1Y2NlZWQgYW5kIGFyZSBibG9ja2lu
ZywKPiBpbmNsdWRpbmcgdGVzdHMgd2hpY2ggY291bGQgbm90IGJlIHJ1bjoKPiAgdGVzdC1hcm1o
Zi1hcm1oZi14bCAgICAgICAgICAgOSBndWVzdC1zdGFydCAgICAgICAgICAgICAgIGZhaWwgUkVH
Ui4gdnMuIDMwNjAzCj4gIHRlc3QtYW1kNjQtaTM4Ni1wYWlyICAgMTcgZ3Vlc3QtbWlncmF0ZS9z
cmNfaG9zdC9kc3RfaG9zdCBmYWlsIFJFR1IuIHZzLiAzMDYwMwo+IAo+IFRlc3RzIHdoaWNoIGRp
ZCBub3Qgc3VjY2VlZCwgYnV0IGFyZSBub3QgYmxvY2tpbmc6Cj4gIHRlc3QtYXJtaGYtYXJtaGYt
bGlidmlydCAgICAgIDkgZ3Vlc3Qtc3RhcnQgICAgICAgICAgICAgICAgICBmYWlsICAgbmV2ZXIg
cGFzcwo+ICB0ZXN0LWFtZDY0LWkzODYtbGlidmlydCAgICAgICA5IGd1ZXN0LXN0YXJ0ICAgICAg
ICAgICAgICAgICAgZmFpbCAgIG5ldmVyIHBhc3MKPiAgdGVzdC1hbWQ2NC1hbWQ2NC14bC1wY2lw
dC1pbnRlbCAgOSBndWVzdC1zdGFydCAgICAgICAgICAgICAgICAgZmFpbCBuZXZlciBwYXNzCj4g
IHRlc3QtYW1kNjQtYW1kNjQtbGlidmlydCAgICAgIDkgZ3Vlc3Qtc3RhcnQgICAgICAgICAgICAg
ICAgICBmYWlsICAgbmV2ZXIgcGFzcwo+ICB0ZXN0LWFtZDY0LWFtZDY0LXhsLXdpbnhwc3AzIDE0
IGd1ZXN0LXN0b3AgICAgICAgICAgICAgICAgICAgZmFpbCAgIG5ldmVyIHBhc3MKPiAgdGVzdC1h
bWQ2NC1pMzg2LXhsLXFlbXV1LXdpbnhwc3AzLXZjcHVzMSAxNCBndWVzdC1zdG9wICAgICAgICAg
ZmFpbCBuZXZlciBwYXNzCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC13aW43LWFtZDY0IDE0IGd1ZXN0
LXN0b3AgICAgICAgICAgICAgICAgICAgZmFpbCAgbmV2ZXIgcGFzcwo+ICB0ZXN0LWFtZDY0LWkz
ODYteGwtcWVtdXQtd2luNy1hbWQ2NCAxNCBndWVzdC1zdG9wICAgICAgICAgICAgICBmYWlsIG5l
dmVyIHBhc3MKPiAgdGVzdC1hbWQ2NC1pMzg2LXhsLXFlbXV0LXdpbnhwc3AzLXZjcHVzMSAxNCBn
dWVzdC1zdG9wICAgICAgICAgZmFpbCBuZXZlciBwYXNzCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC1x
ZW11dS13aW43LWFtZDY0IDE0IGd1ZXN0LXN0b3AgICAgICAgICAgICAgIGZhaWwgbmV2ZXIgcGFz
cwo+ICB0ZXN0LWFtZDY0LWkzODYteGwtcWVtdXUtd2lueHBzcDMgMTQgZ3Vlc3Qtc3RvcCAgICAg
ICAgICAgICAgICBmYWlsIG5ldmVyIHBhc3MKPiAgdGVzdC1hbWQ2NC1pMzg2LXhsLXdpbnhwc3Az
LXZjcHVzMSAxNCBndWVzdC1zdG9wICAgICAgICAgICAgICAgZmFpbCBuZXZlciBwYXNzCj4gIHRl
c3QtYW1kNjQtYW1kNjQteGwtcWVtdXQtd2lueHBzcDMgMTQgZ3Vlc3Qtc3RvcCAgICAgICAgICAg
ICAgIGZhaWwgbmV2ZXIgcGFzcwo+ICB0ZXN0LWFtZDY0LWFtZDY0LXhsLXFlbXV0LXdpbjctYW1k
NjQgMTQgZ3Vlc3Qtc3RvcCAgICAgICAgICAgICBmYWlsIG5ldmVyIHBhc3MKPiAgdGVzdC1hbWQ2
NC1hbWQ2NC14bC1xZW11dS13aW54cHNwMyAxNCBndWVzdC1zdG9wICAgICAgICAgICAgICAgZmFp
bCBuZXZlciBwYXNzCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC13aW54cHNwMyAgMTQgZ3Vlc3Qtc3Rv
cCAgICAgICAgICAgICAgICAgICBmYWlsICAgbmV2ZXIgcGFzcwo+ICB0ZXN0LWFtZDY0LWkzODYt
eGwtcWVtdXQtd2lueHBzcDMgMTQgZ3Vlc3Qtc3RvcCAgICAgICAgICAgICAgICBmYWlsIG5ldmVy
IHBhc3MKPiAgdGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11dS13aW43LWFtZDY0IDE0IGd1ZXN0LXN0
b3AgICAgICAgICAgICAgZmFpbCBuZXZlciBwYXNzCj4gIHRlc3QtYW1kNjQtYW1kNjQteGwtd2lu
Ny1hbWQ2NCAxNCBndWVzdC1zdG9wICAgICAgICAgICAgICAgICAgIGZhaWwgbmV2ZXIgcGFzcwo+
IAo+IHZlcnNpb24gdGFyZ2V0ZWQgZm9yIHRlc3Rpbmc6Cj4gIHFlbXV1ICAgICAgICAgICAgICAg
IGVlMjk0OThlNGYwZjNlZmY5MGVlZWI3ZjVmYTE3MDNhYmVkZDJmYjYKPiBiYXNlbGluZSB2ZXJz
aW9uOgo+ICBxZW11dSAgICAgICAgICAgICAgICBiMDBhMGRkYjMxYTM5M2I4Mzg2ZDMwYTliZWY0
ZDliYmIyNDllN2VjCj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gUGVvcGxlIHdobyB0b3VjaGVkIHJldmlzaW9ucyB1bmRl
ciB0ZXN0Ogo+ICAgQWxleGFuZGVyIEdyYWYgPGFncmFmQHN1c2UuZGU+Cj4gICBBbGV4ZXkgS2Fy
ZGFzaGV2c2tpeSA8YWlrQG96bGFicy5ydT4KPiAgIEFuZHJlYXMgRsOkcmJlciA8YWZhZXJiZXJA
c3VzZS5kZT4KPiAgIEFyZCBCaWVzaGV1dmVsIDxhcmQuYmllc2hldXZlbEBsaW5hcm8ub3JnPgo+
ICAgQXVyZWxpZW4gSmFybm8gPGF1cmVsaWVuQGF1cmVsMzIubmV0Pgo+ICAgQmFzdGlhbiBLb3Bw
ZWxtYW5uIDxrYmFzdGlhbkBtYWlsLnVuaS1wYWRlcmJvcm4uZGU+Cj4gICBCaW4gV3UgPHd1Lnd1
YmluQGh1YXdlaS5jb20+Cj4gICBDaGFvIFBlbmcgPGNoYW8ucC5wZW5nQGxpbnV4LmludGVsLmNv
bT4KPiAgIENoZW4gRmFuIDxjaGVuLmZhbi5mbnN0QGNuLmZ1aml0c3UuY29tPgo+ICAgQ2hlbiBH
YW5nIDxnYW5nLmNoZW4uNWk1akBnbWFpbC5jb20+Cj4gICBDaGVubGlhbmcgPGNoZW5saWFuZzg4
QGh1YXdlaS5jb20+Cj4gICBDaHJpc3RpYW4gQm9ybnRyYWVnZXIgPGJvcm50cmFlZ2VyQGRlLmli
bS5jb20+Cj4gICBDbGF1ZGlvIEZvbnRhbmEgPGNsYXVkaW8uZm9udGFuYUBodWF3ZWkuY29tPgo+
ICAgQ29yZXkgTWlueWFyZCA8Y21pbnlhcmRAbXZpc3RhLmNvbT4KPiAgIENvcm5lbGlhIEh1Y2sg
PGNvcm5lbGlhLmh1Y2tAZGUuaWJtLmNvbT4KPiAgIERhdmlkIEhpbGRlbmJyYW5kIDxkYWhpQGxp
bnV4LnZuZXQuaWJtLmNvbT4KPiAgIERvbiBTbHV0eiA8ZHNsdXR6QHZlcml6b24uY29tPgo+ICAg
RG9uZ3h1ZSBaaGFuZyA8ZWx0YS5lcmFAZ21haWwuY29tPgo+ICAgRHIuIERhdmlkIEFsYW4gR2ls
YmVydCA8ZGdpbGJlcnRAcmVkaGF0LmNvbT4KPiAgIEVkZ2FyIEUuIElnbGVzaWFzIDxlZGdhci5p
Z2xlc2lhc0B4aWxpbnguY29tPgo+ICAgRWR1YXJkbyBIYWJrb3N0IDxlaGFia29zdEByZWRoYXQu
Y29tPgo+ICAgRmFiaWFuIEFnZ2VsZXIgPGFnZ2VsZXJmQGV0aHouY2g+Cj4gICBGYW0gWmhlbmcg
PGZhbXpAcmVkaGF0LmNvbT4KPiAgIEdlcmQgSG9mZm1hbm4gPGtyYXhlbEByZWRoYXQuY29tPgo+
ICAgR29uZ2xlaSA8YXJlaS5nb25nbGVpQGh1YXdlaS5jb20+Cj4gICBHcmVnIEJlbGxvd3MgPGdy
ZWcuYmVsbG93c0BsaW5hcm8ub3JnPgo+ICAgSWdvciBNYW1tZWRvdiA8aW1hbW1lZG9AcmVkaGF0
LmNvbT4KPiAgIEphbWVzIEhhcnBlciA8amFtZXMuaGFycGVyQGVqYmRpZ2l0YWwuY29tLmF1Pgo+
ICAgSmFtZXMgSGFycGVyIDxqYW1lc0BlamJkaWdpdGFsLmNvbS5hdT4KPiAgIEphbiBLaXN6a2Eg
PGphbi5raXN6a2FAc2llbWVucy5jb20+Cj4gICBKYW4gVmVzZWx5IDxqYW5vLnZlc2VseUBnbWFp
bC5jb20+Cj4gICBKZW5zIEZyZWltYW5uIDxqZnJlaUBsaW51eC52bmV0LmlibS5jb20+Cj4gICBK
b2VsIFNjaG9wcCA8anNjaG9wcEBsaW51eC52bmV0LmlibS5jb20+Cj4gICBKb2huIFNub3cgPGpz
bm93QHJlZGhhdC5jb20+Cj4gICBKb25hcyBHb3Jza2kgPGpvZ29Ab3BlbndydC5vcmc+Cj4gICBK
dWFuIFF1aW50ZWxhIDxxdWludGVsYUByZWRoYXQuY29tPgo+ICAgSnVuIExpIDxqdW5tdXppQGdt
YWlsLmNvbT4KPiAgIEtldmluIFdvbGYgPGt3b2xmQHJlZGhhdC5jb20+Cj4gICBLT05SQUQgRnJl
ZGVyaWMgPGZyZWQua29ucmFkQGdyZWVuc29jcy5jb20+Cj4gICBMZW9uIEFscmFlIDxsZW9uLmFs
cmFlQGltZ3RlYy5jb20+Cj4gICBMaSBMaXUgPGpvaG4ubGl1bGlAaHVhd2VpLmNvbT4KPiAgIEx1
aXogQ2FwaXR1bGlubyA8bGNhcGl0dWxpbm9AcmVkaGF0LmNvbT4KPiAgIE1hcmMtQW5kcsOpIEx1
cmVhdSA8bWFyY2FuZHJlLmx1cmVhdUBnbWFpbC5jb20+Cj4gICBNYXJrdXMgQXJtYnJ1c3RlciA8
YXJtYnJ1QHJlZGhhdC5jb20+Cj4gICBNYXJ0aW4gRGVja3kgPG1hcnRpbkBkZWNreS5jej4KPiAg
IE1heCBGaWxpcHBvdiA8amNtdmJrYmNAZ21haWwuY29tPgo+ICAgTWF4IFJlaXR6IDxtcmVpdHpA
cmVkaGF0LmNvbT4KPiAgIE1pY2hhZWwgUm90aCA8bWRyb3RoQGxpbnV4LnZuZXQuaWJtLmNvbT4K
PiAgIE1pY2hhZWwgUy4gVHNpcmtpbiA8bXN0QHJlZGhhdC5jb20+Cj4gICBNaWNoYWVsIFdhbGxl
IDxtaWNoYWVsQHdhbGxlLmNjPiAoZm9yIGxtMzIpCj4gICBNaWtoYWlsIElseWluIDxtLmlsaW5A
c2Ftc3VuZy5jb20+Cj4gICBQYW9sbyBCb256aW5pIDxwYm9uemluaUByZWRoYXQuY29tPgo+ICAg
UGV0ZXIgQ3Jvc3Rod2FpdGUgPHBldGVyLmNyb3N0aHdhaXRlQHhpbGlueC5jb20+Cj4gICBQZXRl
ciBMaWV2ZW4gPHBsQGthbXAuZGU+Cj4gICBQZXRlciBNYXlkZWxsIDxwZXRlci5tYXlkZWxsQGxp
bmFyby5vcmc+Cj4gICBQZXRyIE1hdG91c2VrIDxwbWF0b3VzZUByZWRoYXQuY29tPgo+ICAgUmF5
IFN0cm9kZSA8cnN0cm9kZUByZWRoYXQuY29tPgo+ICAgUmljaGFyZCBKb25lcyA8cmpvbmVzQHJl
ZGhhdC5jb20+Cj4gICBSaWNoYXJkIFcuTS4gSm9uZXMgPHJqb25lc0ByZWRoYXQuY29tPgo+ICAg
UmlrdSBWb2lwaW8gPHJpa3Uudm9pcGlvQGxpbmFyby5vcmc+Cj4gICBSb2IgSGVycmluZyA8cm9i
LmhlcnJpbmdAbGluYXJvLm9yZz4KPiAgIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGNpdHJp
eC5jb20+Cj4gICBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPiAgIFNl
cmdleSBGZWRvcm92IDxzLmZlZG9yb3ZAc2Ftc3VuZy5jb20+Cj4gICBTdGVmYW4gQmVyZ2VyIDxz
dGVmYW5iQGxpbnV4LnZuZXQuaWJtLmNvbT4KPiAgIFN0ZWZhbiBIYWpub2N6aSA8c3RlZmFuaGFA
cmVkaGF0LmNvbT4KPiAgIFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1
LmNpdHJpeC5jb20+Cj4gICBUaG9tYXMgSHV0aCA8dGh1dGhAbGludXgudm5ldC5pYm0uY29tPgo+
ICAgVGluZyBXYW5nIDxrYXRoeS53YW5ndGluZ0BodWF3ZWkuY29tPgo+ICAgVG9ueSBCcmVlZHMg
PHRvbnlAYmFrZXlvdXJub29kbGUuY29tPgo+ICAgV2VpIEh1YW5nIDx3ZWlAcmVkaGF0LmNvbT4K
PiAgIFlvbmdib2sgS2ltIDx5b25nYm9rLmtpbUBpbWd0ZWMuY29tPgo+ICAgWmhhbmcgSGFveXUg
PHpoYW5naHlAc2FuZ2Zvci5jb20+Cj4gICB6aGFuZ2hhaWxpYW5nIDx6aGFuZy56aGFuZ2hhaWxp
YW5nQGh1YXdlaS5jb20+Cj4gICBaaHUgR3VpaHVhIDx6aHVnaC5mbnN0QGNuLmZ1aml0c3UuY29t
Pgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQo+IAo+IGpvYnM6Cj4gIGJ1aWxkLWFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICBidWlsZC1hcm1oZiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAgYnVp
bGQtaTM4NiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHBhc3MgICAgCj4gIGJ1aWxkLWFtZDY0LWxpYnZpcnQgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICBidWlsZC1hcm1oZi1saWJ2aXJ0ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAgYnVpbGQtaTM4Ni1s
aWJ2aXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAg
Cj4gIGJ1aWxkLWFtZDY0LXB2b3BzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBwYXNzICAgIAo+ICBidWlsZC1hcm1oZi1wdm9wcyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAgYnVpbGQtaTM4Ni1wdm9wcyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3Qt
YW1kNjQtYW1kNjQteGwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBw
YXNzICAgIAo+ICB0ZXN0LWFybWhmLWFybWhmLXhsICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2LXhsICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4
Ni1yaGVsNmh2bS1hbWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+
ICB0ZXN0LWFtZDY0LWkzODYtcWVtdXQtcmhlbDZodm0tYW1kICAgICAgICAgICAgICAgICAgICAg
ICAgICAgcGFzcyAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2LXFlbXV1LXJoZWw2aHZtLWFtZCAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtYW1kNjQteGwtcWVt
dXQtZGViaWFuaHZtLWFtZDY0ICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICB0ZXN0LWFt
ZDY0LWkzODYteGwtcWVtdXQtZGViaWFuaHZtLWFtZDY0ICAgICAgICAgICAgICAgICAgICAgcGFz
cyAgICAKPiAgdGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11dS1kZWJpYW5odm0tYW1kNjQgICAgICAg
ICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC1xZW11dS1kZWJpYW5o
dm0tYW1kNjQgICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICB0ZXN0LWFtZDY0LWkzODYt
ZnJlZWJzZDEwLWFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAg
dGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11dS1vdm1mLWFtZDY0ICAgICAgICAgICAgICAgICAgICAg
ICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC1xZW11dS1vdm1mLWFtZDY0ICAgICAg
ICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICB0ZXN0LWFtZDY0LWFtZDY0LXhsLXFlbXV0
LXdpbjctYW1kNjQgICAgICAgICAgICAgICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2
NC1pMzg2LXhsLXFlbXV0LXdpbjctYW1kNjQgICAgICAgICAgICAgICAgICAgICAgICAgIGZhaWwg
ICAgCj4gIHRlc3QtYW1kNjQtYW1kNjQteGwtcWVtdXUtd2luNy1hbWQ2NCAgICAgICAgICAgICAg
ICAgICAgICAgICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWkzODYteGwtcWVtdXUtd2luNy1hbWQ2
NCAgICAgICAgICAgICAgICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2NC1hbWQ2NC14
bC13aW43LWFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZhaWwgICAgCj4gIHRl
c3QtYW1kNjQtaTM4Ni14bC13aW43LWFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWkzODYteGwtY3JlZGl0MiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2LWZyZWVic2QxMC1p
Mzg2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQt
YW1kNjQteGwtcGNpcHQtaW50ZWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmYWlsICAg
IAo+ICB0ZXN0LWFtZDY0LWkzODYtcmhlbDZodm0taW50ZWwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgcGFzcyAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2LXFlbXV0LXJoZWw2aHZtLWludGVs
ICAgICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni1xZW11
dS1yaGVsNmh2bS1pbnRlbCAgICAgICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICB0ZXN0
LWFtZDY0LWFtZDY0LWxpYnZpcnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ZmFpbCAgICAKPiAgdGVzdC1hcm1oZi1hcm1oZi1saWJ2aXJ0ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGZhaWwgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni1saWJ2aXJ0ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWkz
ODYteGwtbXVsdGl2Y3B1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAK
PiAgdGVzdC1hbWQ2NC1hbWQ2NC1wYWlyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni1wYWlyICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWFtZDY0LXhsLXNl
ZGYtcGluICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAgdGVzdC1h
bWQ2NC1hbWQ2NC14bC1zZWRmICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBh
c3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC1xZW11dC13aW54cHNwMy12Y3B1czEgICAgICAg
ICAgICAgICAgICAgICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWkzODYteGwtcWVtdXUtd2lueHBz
cDMtdmNwdXMxICAgICAgICAgICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2
LXhsLXdpbnhwc3AzLXZjcHVzMSAgICAgICAgICAgICAgICAgICAgICAgICAgIGZhaWwgICAgCj4g
IHRlc3QtYW1kNjQtYW1kNjQteGwtcWVtdXQtd2lueHBzcDMgICAgICAgICAgICAgICAgICAgICAg
ICAgICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWkzODYteGwtcWVtdXQtd2lueHBzcDMgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11
dS13aW54cHNwMyAgICAgICAgICAgICAgICAgICAgICAgICAgIGZhaWwgICAgCj4gIHRlc3QtYW1k
NjQtaTM4Ni14bC1xZW11dS13aW54cHNwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICBmYWls
ICAgIAo+ICB0ZXN0LWFtZDY0LWFtZDY0LXhsLXdpbnhwc3AzICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2LXhsLXdpbnhwc3AzICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZhaWwgICAgCj4gCj4gCj4gLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gc2ctcmVw
b3J0LWZsaWdodCBvbiBvc3N0ZXN0LmNhbS54Y2ktdGVzdC5jb20KPiBsb2dzOiAvaG9tZS94Y19v
c3N0ZXN0L2xvZ3MKPiBpbWFnZXM6IC9ob21lL3hjX29zc3Rlc3QvaW1hZ2VzCj4gCj4gTG9ncywg
Y29uZmlnIGZpbGVzLCBldGMuIGFyZSBhdmFpbGFibGUgYXQKPiAgICAgaHR0cDovL3d3dy5jaGlh
cmsuZ3JlZW5lbmQub3JnLnVrL354ZW5zcmN0cy9sb2dzCj4gCj4gVGVzdCBoYXJuZXNzIGNvZGUg
Y2FuIGJlIGZvdW5kIGF0Cj4gICAgIGh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vZ2l0d2Vi
P3A9b3NzdGVzdC5naXQ7YT1zdW1tYXJ5Cj4gCj4gCj4gTm90IHB1c2hpbmcuCj4gCj4gKE5vIHJl
dmlzaW9uIGxvZzsgaXQgd291bGQgYmUgNjMyMCBsaW5lcyBsb25nLikKPiAKPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:43:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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 1XlEAi-00058b-8u; Mon, 03 Nov 2014 09:43:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlEAg-000588-Rz
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 09:43:35 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	6E/EE-02699-64E47545; Mon, 03 Nov 2014 09:43:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415007812!12148459!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31426 invoked from network); 3 Nov 2014 09:43:33 -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;
	3 Nov 2014 09:43:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="187446271"
Message-ID: <1415007810.9994.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <Ian.Jackson@eu.citrix.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>, Anthony Perard
	<anthony.perard@citrix.com>
Date: Mon, 3 Nov 2014 09:43:30 +0000
In-Reply-To: <osstest-31329-mainreport@xen.org>
References: <osstest-31329-mainreport@xen.org>
Organization: Citrix Systems, Inc.
Content-Length: 14124
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TG9va3MgbGlrZSB0aGlzIHRlc3QgaGFzbid0IHN1Y2NlZWRlZCBzaW5jZSA2IE9jdG9iZXIgKGZs
aWdodCAzMDYwMykuCgpMb29raW5nIG92ZXIgdGhlIHZhcmlvdXMgZmFpbHVyZXMgc2luY2UgdGhl
biB0aGUgCiB0ZXN0LWFtZDY0LWkzODYtcGFpciAgIDE3IGd1ZXN0LW1pZ3JhdGUvc3JjX2hvc3Qv
ZHN0X2hvc3QgZmFpbCBSRUdSLiB2cy4gMzA2MDMKb25lIGhhcyBiZWVuIGNvbnNpc3RlbnRseSBm
YWlsaW5nLgoKVGhlcmUgYXJlIGEgcmFuZG9tIHNtYXR0ZXJpbmcgb2Ygb3RoZXIgZmFpbHVyZXMs
IHRoZSBhcm1oZiBndWVzdC1zdGFydApvbmUgYmVsb3cgYW5kIGFsc28gc29tZSBvZiB0aGUgdXN1
YWwgaGVpc2VuYnVncy4KCkNvdWxkIHNvbWVvbmUgaGF2ZSBhIGxvb2sgcGxlYXNlLgoKSWFuLCBk
b2Vzbid0IGxvb2sgbGlrZSB0aGUgYmlzZWN0b3IgaGFzIGhhZCBhIGdvIGF0IHRoaXMsIGFueSBp
ZGVhIHdoeT8KCk9uIE1vbiwgMjAxNC0xMS0wMyBhdCAwNjo0OCArMDAwMCwgeGVuLm9yZyB3cm90
ZToKPiBmbGlnaHQgMzEzMjkgcWVtdS1tYWlubGluZSByZWFsIFtyZWFsXQo+IGh0dHA6Ly93d3cu
Y2hpYXJrLmdyZWVuZW5kLm9yZy51ay9+eGVuc3JjdHMvbG9ncy8zMTMyOS8KPiAKPiBSZWdyZXNz
aW9ucyA6LSgKPiAKPiBUZXN0cyB3aGljaCBkaWQgbm90IHN1Y2NlZWQgYW5kIGFyZSBibG9ja2lu
ZywKPiBpbmNsdWRpbmcgdGVzdHMgd2hpY2ggY291bGQgbm90IGJlIHJ1bjoKPiAgdGVzdC1hcm1o
Zi1hcm1oZi14bCAgICAgICAgICAgOSBndWVzdC1zdGFydCAgICAgICAgICAgICAgIGZhaWwgUkVH
Ui4gdnMuIDMwNjAzCj4gIHRlc3QtYW1kNjQtaTM4Ni1wYWlyICAgMTcgZ3Vlc3QtbWlncmF0ZS9z
cmNfaG9zdC9kc3RfaG9zdCBmYWlsIFJFR1IuIHZzLiAzMDYwMwo+IAo+IFRlc3RzIHdoaWNoIGRp
ZCBub3Qgc3VjY2VlZCwgYnV0IGFyZSBub3QgYmxvY2tpbmc6Cj4gIHRlc3QtYXJtaGYtYXJtaGYt
bGlidmlydCAgICAgIDkgZ3Vlc3Qtc3RhcnQgICAgICAgICAgICAgICAgICBmYWlsICAgbmV2ZXIg
cGFzcwo+ICB0ZXN0LWFtZDY0LWkzODYtbGlidmlydCAgICAgICA5IGd1ZXN0LXN0YXJ0ICAgICAg
ICAgICAgICAgICAgZmFpbCAgIG5ldmVyIHBhc3MKPiAgdGVzdC1hbWQ2NC1hbWQ2NC14bC1wY2lw
dC1pbnRlbCAgOSBndWVzdC1zdGFydCAgICAgICAgICAgICAgICAgZmFpbCBuZXZlciBwYXNzCj4g
IHRlc3QtYW1kNjQtYW1kNjQtbGlidmlydCAgICAgIDkgZ3Vlc3Qtc3RhcnQgICAgICAgICAgICAg
ICAgICBmYWlsICAgbmV2ZXIgcGFzcwo+ICB0ZXN0LWFtZDY0LWFtZDY0LXhsLXdpbnhwc3AzIDE0
IGd1ZXN0LXN0b3AgICAgICAgICAgICAgICAgICAgZmFpbCAgIG5ldmVyIHBhc3MKPiAgdGVzdC1h
bWQ2NC1pMzg2LXhsLXFlbXV1LXdpbnhwc3AzLXZjcHVzMSAxNCBndWVzdC1zdG9wICAgICAgICAg
ZmFpbCBuZXZlciBwYXNzCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC13aW43LWFtZDY0IDE0IGd1ZXN0
LXN0b3AgICAgICAgICAgICAgICAgICAgZmFpbCAgbmV2ZXIgcGFzcwo+ICB0ZXN0LWFtZDY0LWkz
ODYteGwtcWVtdXQtd2luNy1hbWQ2NCAxNCBndWVzdC1zdG9wICAgICAgICAgICAgICBmYWlsIG5l
dmVyIHBhc3MKPiAgdGVzdC1hbWQ2NC1pMzg2LXhsLXFlbXV0LXdpbnhwc3AzLXZjcHVzMSAxNCBn
dWVzdC1zdG9wICAgICAgICAgZmFpbCBuZXZlciBwYXNzCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC1x
ZW11dS13aW43LWFtZDY0IDE0IGd1ZXN0LXN0b3AgICAgICAgICAgICAgIGZhaWwgbmV2ZXIgcGFz
cwo+ICB0ZXN0LWFtZDY0LWkzODYteGwtcWVtdXUtd2lueHBzcDMgMTQgZ3Vlc3Qtc3RvcCAgICAg
ICAgICAgICAgICBmYWlsIG5ldmVyIHBhc3MKPiAgdGVzdC1hbWQ2NC1pMzg2LXhsLXdpbnhwc3Az
LXZjcHVzMSAxNCBndWVzdC1zdG9wICAgICAgICAgICAgICAgZmFpbCBuZXZlciBwYXNzCj4gIHRl
c3QtYW1kNjQtYW1kNjQteGwtcWVtdXQtd2lueHBzcDMgMTQgZ3Vlc3Qtc3RvcCAgICAgICAgICAg
ICAgIGZhaWwgbmV2ZXIgcGFzcwo+ICB0ZXN0LWFtZDY0LWFtZDY0LXhsLXFlbXV0LXdpbjctYW1k
NjQgMTQgZ3Vlc3Qtc3RvcCAgICAgICAgICAgICBmYWlsIG5ldmVyIHBhc3MKPiAgdGVzdC1hbWQ2
NC1hbWQ2NC14bC1xZW11dS13aW54cHNwMyAxNCBndWVzdC1zdG9wICAgICAgICAgICAgICAgZmFp
bCBuZXZlciBwYXNzCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC13aW54cHNwMyAgMTQgZ3Vlc3Qtc3Rv
cCAgICAgICAgICAgICAgICAgICBmYWlsICAgbmV2ZXIgcGFzcwo+ICB0ZXN0LWFtZDY0LWkzODYt
eGwtcWVtdXQtd2lueHBzcDMgMTQgZ3Vlc3Qtc3RvcCAgICAgICAgICAgICAgICBmYWlsIG5ldmVy
IHBhc3MKPiAgdGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11dS13aW43LWFtZDY0IDE0IGd1ZXN0LXN0
b3AgICAgICAgICAgICAgZmFpbCBuZXZlciBwYXNzCj4gIHRlc3QtYW1kNjQtYW1kNjQteGwtd2lu
Ny1hbWQ2NCAxNCBndWVzdC1zdG9wICAgICAgICAgICAgICAgICAgIGZhaWwgbmV2ZXIgcGFzcwo+
IAo+IHZlcnNpb24gdGFyZ2V0ZWQgZm9yIHRlc3Rpbmc6Cj4gIHFlbXV1ICAgICAgICAgICAgICAg
IGVlMjk0OThlNGYwZjNlZmY5MGVlZWI3ZjVmYTE3MDNhYmVkZDJmYjYKPiBiYXNlbGluZSB2ZXJz
aW9uOgo+ICBxZW11dSAgICAgICAgICAgICAgICBiMDBhMGRkYjMxYTM5M2I4Mzg2ZDMwYTliZWY0
ZDliYmIyNDllN2VjCj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gUGVvcGxlIHdobyB0b3VjaGVkIHJldmlzaW9ucyB1bmRl
ciB0ZXN0Ogo+ICAgQWxleGFuZGVyIEdyYWYgPGFncmFmQHN1c2UuZGU+Cj4gICBBbGV4ZXkgS2Fy
ZGFzaGV2c2tpeSA8YWlrQG96bGFicy5ydT4KPiAgIEFuZHJlYXMgRsOkcmJlciA8YWZhZXJiZXJA
c3VzZS5kZT4KPiAgIEFyZCBCaWVzaGV1dmVsIDxhcmQuYmllc2hldXZlbEBsaW5hcm8ub3JnPgo+
ICAgQXVyZWxpZW4gSmFybm8gPGF1cmVsaWVuQGF1cmVsMzIubmV0Pgo+ICAgQmFzdGlhbiBLb3Bw
ZWxtYW5uIDxrYmFzdGlhbkBtYWlsLnVuaS1wYWRlcmJvcm4uZGU+Cj4gICBCaW4gV3UgPHd1Lnd1
YmluQGh1YXdlaS5jb20+Cj4gICBDaGFvIFBlbmcgPGNoYW8ucC5wZW5nQGxpbnV4LmludGVsLmNv
bT4KPiAgIENoZW4gRmFuIDxjaGVuLmZhbi5mbnN0QGNuLmZ1aml0c3UuY29tPgo+ICAgQ2hlbiBH
YW5nIDxnYW5nLmNoZW4uNWk1akBnbWFpbC5jb20+Cj4gICBDaGVubGlhbmcgPGNoZW5saWFuZzg4
QGh1YXdlaS5jb20+Cj4gICBDaHJpc3RpYW4gQm9ybnRyYWVnZXIgPGJvcm50cmFlZ2VyQGRlLmli
bS5jb20+Cj4gICBDbGF1ZGlvIEZvbnRhbmEgPGNsYXVkaW8uZm9udGFuYUBodWF3ZWkuY29tPgo+
ICAgQ29yZXkgTWlueWFyZCA8Y21pbnlhcmRAbXZpc3RhLmNvbT4KPiAgIENvcm5lbGlhIEh1Y2sg
PGNvcm5lbGlhLmh1Y2tAZGUuaWJtLmNvbT4KPiAgIERhdmlkIEhpbGRlbmJyYW5kIDxkYWhpQGxp
bnV4LnZuZXQuaWJtLmNvbT4KPiAgIERvbiBTbHV0eiA8ZHNsdXR6QHZlcml6b24uY29tPgo+ICAg
RG9uZ3h1ZSBaaGFuZyA8ZWx0YS5lcmFAZ21haWwuY29tPgo+ICAgRHIuIERhdmlkIEFsYW4gR2ls
YmVydCA8ZGdpbGJlcnRAcmVkaGF0LmNvbT4KPiAgIEVkZ2FyIEUuIElnbGVzaWFzIDxlZGdhci5p
Z2xlc2lhc0B4aWxpbnguY29tPgo+ICAgRWR1YXJkbyBIYWJrb3N0IDxlaGFia29zdEByZWRoYXQu
Y29tPgo+ICAgRmFiaWFuIEFnZ2VsZXIgPGFnZ2VsZXJmQGV0aHouY2g+Cj4gICBGYW0gWmhlbmcg
PGZhbXpAcmVkaGF0LmNvbT4KPiAgIEdlcmQgSG9mZm1hbm4gPGtyYXhlbEByZWRoYXQuY29tPgo+
ICAgR29uZ2xlaSA8YXJlaS5nb25nbGVpQGh1YXdlaS5jb20+Cj4gICBHcmVnIEJlbGxvd3MgPGdy
ZWcuYmVsbG93c0BsaW5hcm8ub3JnPgo+ICAgSWdvciBNYW1tZWRvdiA8aW1hbW1lZG9AcmVkaGF0
LmNvbT4KPiAgIEphbWVzIEhhcnBlciA8amFtZXMuaGFycGVyQGVqYmRpZ2l0YWwuY29tLmF1Pgo+
ICAgSmFtZXMgSGFycGVyIDxqYW1lc0BlamJkaWdpdGFsLmNvbS5hdT4KPiAgIEphbiBLaXN6a2Eg
PGphbi5raXN6a2FAc2llbWVucy5jb20+Cj4gICBKYW4gVmVzZWx5IDxqYW5vLnZlc2VseUBnbWFp
bC5jb20+Cj4gICBKZW5zIEZyZWltYW5uIDxqZnJlaUBsaW51eC52bmV0LmlibS5jb20+Cj4gICBK
b2VsIFNjaG9wcCA8anNjaG9wcEBsaW51eC52bmV0LmlibS5jb20+Cj4gICBKb2huIFNub3cgPGpz
bm93QHJlZGhhdC5jb20+Cj4gICBKb25hcyBHb3Jza2kgPGpvZ29Ab3BlbndydC5vcmc+Cj4gICBK
dWFuIFF1aW50ZWxhIDxxdWludGVsYUByZWRoYXQuY29tPgo+ICAgSnVuIExpIDxqdW5tdXppQGdt
YWlsLmNvbT4KPiAgIEtldmluIFdvbGYgPGt3b2xmQHJlZGhhdC5jb20+Cj4gICBLT05SQUQgRnJl
ZGVyaWMgPGZyZWQua29ucmFkQGdyZWVuc29jcy5jb20+Cj4gICBMZW9uIEFscmFlIDxsZW9uLmFs
cmFlQGltZ3RlYy5jb20+Cj4gICBMaSBMaXUgPGpvaG4ubGl1bGlAaHVhd2VpLmNvbT4KPiAgIEx1
aXogQ2FwaXR1bGlubyA8bGNhcGl0dWxpbm9AcmVkaGF0LmNvbT4KPiAgIE1hcmMtQW5kcsOpIEx1
cmVhdSA8bWFyY2FuZHJlLmx1cmVhdUBnbWFpbC5jb20+Cj4gICBNYXJrdXMgQXJtYnJ1c3RlciA8
YXJtYnJ1QHJlZGhhdC5jb20+Cj4gICBNYXJ0aW4gRGVja3kgPG1hcnRpbkBkZWNreS5jej4KPiAg
IE1heCBGaWxpcHBvdiA8amNtdmJrYmNAZ21haWwuY29tPgo+ICAgTWF4IFJlaXR6IDxtcmVpdHpA
cmVkaGF0LmNvbT4KPiAgIE1pY2hhZWwgUm90aCA8bWRyb3RoQGxpbnV4LnZuZXQuaWJtLmNvbT4K
PiAgIE1pY2hhZWwgUy4gVHNpcmtpbiA8bXN0QHJlZGhhdC5jb20+Cj4gICBNaWNoYWVsIFdhbGxl
IDxtaWNoYWVsQHdhbGxlLmNjPiAoZm9yIGxtMzIpCj4gICBNaWtoYWlsIElseWluIDxtLmlsaW5A
c2Ftc3VuZy5jb20+Cj4gICBQYW9sbyBCb256aW5pIDxwYm9uemluaUByZWRoYXQuY29tPgo+ICAg
UGV0ZXIgQ3Jvc3Rod2FpdGUgPHBldGVyLmNyb3N0aHdhaXRlQHhpbGlueC5jb20+Cj4gICBQZXRl
ciBMaWV2ZW4gPHBsQGthbXAuZGU+Cj4gICBQZXRlciBNYXlkZWxsIDxwZXRlci5tYXlkZWxsQGxp
bmFyby5vcmc+Cj4gICBQZXRyIE1hdG91c2VrIDxwbWF0b3VzZUByZWRoYXQuY29tPgo+ICAgUmF5
IFN0cm9kZSA8cnN0cm9kZUByZWRoYXQuY29tPgo+ICAgUmljaGFyZCBKb25lcyA8cmpvbmVzQHJl
ZGhhdC5jb20+Cj4gICBSaWNoYXJkIFcuTS4gSm9uZXMgPHJqb25lc0ByZWRoYXQuY29tPgo+ICAg
UmlrdSBWb2lwaW8gPHJpa3Uudm9pcGlvQGxpbmFyby5vcmc+Cj4gICBSb2IgSGVycmluZyA8cm9i
LmhlcnJpbmdAbGluYXJvLm9yZz4KPiAgIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGNpdHJp
eC5jb20+Cj4gICBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPiAgIFNl
cmdleSBGZWRvcm92IDxzLmZlZG9yb3ZAc2Ftc3VuZy5jb20+Cj4gICBTdGVmYW4gQmVyZ2VyIDxz
dGVmYW5iQGxpbnV4LnZuZXQuaWJtLmNvbT4KPiAgIFN0ZWZhbiBIYWpub2N6aSA8c3RlZmFuaGFA
cmVkaGF0LmNvbT4KPiAgIFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1
LmNpdHJpeC5jb20+Cj4gICBUaG9tYXMgSHV0aCA8dGh1dGhAbGludXgudm5ldC5pYm0uY29tPgo+
ICAgVGluZyBXYW5nIDxrYXRoeS53YW5ndGluZ0BodWF3ZWkuY29tPgo+ICAgVG9ueSBCcmVlZHMg
PHRvbnlAYmFrZXlvdXJub29kbGUuY29tPgo+ICAgV2VpIEh1YW5nIDx3ZWlAcmVkaGF0LmNvbT4K
PiAgIFlvbmdib2sgS2ltIDx5b25nYm9rLmtpbUBpbWd0ZWMuY29tPgo+ICAgWmhhbmcgSGFveXUg
PHpoYW5naHlAc2FuZ2Zvci5jb20+Cj4gICB6aGFuZ2hhaWxpYW5nIDx6aGFuZy56aGFuZ2hhaWxp
YW5nQGh1YXdlaS5jb20+Cj4gICBaaHUgR3VpaHVhIDx6aHVnaC5mbnN0QGNuLmZ1aml0c3UuY29t
Pgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQo+IAo+IGpvYnM6Cj4gIGJ1aWxkLWFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICBidWlsZC1hcm1oZiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAgYnVp
bGQtaTM4NiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHBhc3MgICAgCj4gIGJ1aWxkLWFtZDY0LWxpYnZpcnQgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICBidWlsZC1hcm1oZi1saWJ2aXJ0ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAgYnVpbGQtaTM4Ni1s
aWJ2aXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAg
Cj4gIGJ1aWxkLWFtZDY0LXB2b3BzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBwYXNzICAgIAo+ICBidWlsZC1hcm1oZi1wdm9wcyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAgYnVpbGQtaTM4Ni1wdm9wcyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3Qt
YW1kNjQtYW1kNjQteGwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBw
YXNzICAgIAo+ICB0ZXN0LWFybWhmLWFybWhmLXhsICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2LXhsICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4
Ni1yaGVsNmh2bS1hbWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+
ICB0ZXN0LWFtZDY0LWkzODYtcWVtdXQtcmhlbDZodm0tYW1kICAgICAgICAgICAgICAgICAgICAg
ICAgICAgcGFzcyAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2LXFlbXV1LXJoZWw2aHZtLWFtZCAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtYW1kNjQteGwtcWVt
dXQtZGViaWFuaHZtLWFtZDY0ICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICB0ZXN0LWFt
ZDY0LWkzODYteGwtcWVtdXQtZGViaWFuaHZtLWFtZDY0ICAgICAgICAgICAgICAgICAgICAgcGFz
cyAgICAKPiAgdGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11dS1kZWJpYW5odm0tYW1kNjQgICAgICAg
ICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC1xZW11dS1kZWJpYW5o
dm0tYW1kNjQgICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICB0ZXN0LWFtZDY0LWkzODYt
ZnJlZWJzZDEwLWFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAg
dGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11dS1vdm1mLWFtZDY0ICAgICAgICAgICAgICAgICAgICAg
ICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC1xZW11dS1vdm1mLWFtZDY0ICAgICAg
ICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICB0ZXN0LWFtZDY0LWFtZDY0LXhsLXFlbXV0
LXdpbjctYW1kNjQgICAgICAgICAgICAgICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2
NC1pMzg2LXhsLXFlbXV0LXdpbjctYW1kNjQgICAgICAgICAgICAgICAgICAgICAgICAgIGZhaWwg
ICAgCj4gIHRlc3QtYW1kNjQtYW1kNjQteGwtcWVtdXUtd2luNy1hbWQ2NCAgICAgICAgICAgICAg
ICAgICAgICAgICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWkzODYteGwtcWVtdXUtd2luNy1hbWQ2
NCAgICAgICAgICAgICAgICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2NC1hbWQ2NC14
bC13aW43LWFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZhaWwgICAgCj4gIHRl
c3QtYW1kNjQtaTM4Ni14bC13aW43LWFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWkzODYteGwtY3JlZGl0MiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2LWZyZWVic2QxMC1p
Mzg2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQt
YW1kNjQteGwtcGNpcHQtaW50ZWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmYWlsICAg
IAo+ICB0ZXN0LWFtZDY0LWkzODYtcmhlbDZodm0taW50ZWwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgcGFzcyAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2LXFlbXV0LXJoZWw2aHZtLWludGVs
ICAgICAgICAgICAgICAgICAgICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni1xZW11
dS1yaGVsNmh2bS1pbnRlbCAgICAgICAgICAgICAgICAgICAgICAgICBwYXNzICAgIAo+ICB0ZXN0
LWFtZDY0LWFtZDY0LWxpYnZpcnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ZmFpbCAgICAKPiAgdGVzdC1hcm1oZi1hcm1oZi1saWJ2aXJ0ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGZhaWwgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni1saWJ2aXJ0ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWkz
ODYteGwtbXVsdGl2Y3B1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAK
PiAgdGVzdC1hbWQ2NC1hbWQ2NC1wYWlyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHBhc3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni1wYWlyICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWFtZDY0LXhsLXNl
ZGYtcGluICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFzcyAgICAKPiAgdGVzdC1h
bWQ2NC1hbWQ2NC14bC1zZWRmICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBh
c3MgICAgCj4gIHRlc3QtYW1kNjQtaTM4Ni14bC1xZW11dC13aW54cHNwMy12Y3B1czEgICAgICAg
ICAgICAgICAgICAgICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWkzODYteGwtcWVtdXUtd2lueHBz
cDMtdmNwdXMxICAgICAgICAgICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2
LXhsLXdpbnhwc3AzLXZjcHVzMSAgICAgICAgICAgICAgICAgICAgICAgICAgIGZhaWwgICAgCj4g
IHRlc3QtYW1kNjQtYW1kNjQteGwtcWVtdXQtd2lueHBzcDMgICAgICAgICAgICAgICAgICAgICAg
ICAgICBmYWlsICAgIAo+ICB0ZXN0LWFtZDY0LWkzODYteGwtcWVtdXQtd2lueHBzcDMgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11
dS13aW54cHNwMyAgICAgICAgICAgICAgICAgICAgICAgICAgIGZhaWwgICAgCj4gIHRlc3QtYW1k
NjQtaTM4Ni14bC1xZW11dS13aW54cHNwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICBmYWls
ICAgIAo+ICB0ZXN0LWFtZDY0LWFtZDY0LXhsLXdpbnhwc3AzICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZmFpbCAgICAKPiAgdGVzdC1hbWQ2NC1pMzg2LXhsLXdpbnhwc3AzICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZhaWwgICAgCj4gCj4gCj4gLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gc2ctcmVw
b3J0LWZsaWdodCBvbiBvc3N0ZXN0LmNhbS54Y2ktdGVzdC5jb20KPiBsb2dzOiAvaG9tZS94Y19v
c3N0ZXN0L2xvZ3MKPiBpbWFnZXM6IC9ob21lL3hjX29zc3Rlc3QvaW1hZ2VzCj4gCj4gTG9ncywg
Y29uZmlnIGZpbGVzLCBldGMuIGFyZSBhdmFpbGFibGUgYXQKPiAgICAgaHR0cDovL3d3dy5jaGlh
cmsuZ3JlZW5lbmQub3JnLnVrL354ZW5zcmN0cy9sb2dzCj4gCj4gVGVzdCBoYXJuZXNzIGNvZGUg
Y2FuIGJlIGZvdW5kIGF0Cj4gICAgIGh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vZ2l0d2Vi
P3A9b3NzdGVzdC5naXQ7YT1zdW1tYXJ5Cj4gCj4gCj4gTm90IHB1c2hpbmcuCj4gCj4gKE5vIHJl
dmlzaW9uIGxvZzsgaXQgd291bGQgYmUgNjMyMCBsaW5lcyBsb25nLikKPiAKPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:45:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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 1XlECB-0005Mi-Pw; Mon, 03 Nov 2014 09:45:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XlECA-0005MU-Fc
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:45:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9C/61-09936-1AE47545; Mon, 03 Nov 2014 09:45:05 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415007905!12343752!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6311 invoked from network); 3 Nov 2014 09:45:05 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-7.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 09:45:05 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>) id 1XlEC9-0000ID-58
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:45:05 +0000
Message-ID: <54574EA0.5070101@canonical.com>
Date: Mon, 03 Nov 2014 10:45:04 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
	ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2832209043405747859=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--cQ69W14HbP5Lg69N41p23H5UMufnN6rre
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

I see the message from the subject on my Intel box whenever a guest (iirc=
 even
dom0) starts up. It is not fatal and everything seems ok. I am just curio=
us
about what might trigger this. The addresses look to be inside the hyperv=
isor
code. I was wondering whether there is a simple way to figure out what th=
is
relates to (likely need to look at the objdump of the unstripped hv modul=
e).

Or has someone already looked into this and knows what likely is the caus=
e?

-Stefan


--cQ69W14HbP5Lg69N41p23H5UMufnN6rre
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

iQIcBAEBCgAGBQJUV06gAAoJEOhnXe7L7s6jR+gP/RKx76b6HSxJhfoY5bopinh2
Ey4C63qcHT7vf40c6FwfVU4RhMR1Rykws3vhOYYy0BqNAl/DYb+EJ1vdVVt7gFac
rQ/JafbvUkuWgZLlsnmuluGnV5HLxbKXqO+0VcUD4A+mRE94bHqYnhaUQLKhkuoN
/djM+8Hw3ycdamW69W2aShvGNoGfQ4cl5fFGLgTJHarTDiW/HuiHnthmy2kOVTsU
fdVKrzncUGX5lIIaRCkPvP2n9qz1mVNQqmUhbAfKYtu9VyQvBhJX7M6mWUfS6brt
baiBtuN91ooitSqlgBKKxRiT0WJL8Pd4Am1AzdURINyYAo8mj4knvcEhWwOrIHwy
iO3Jyl1EvrNlXsfQmU08EUupFMIObh7OCGZK2FeBKMObdmiK6Y0KBE/fQrT6g+WA
qfETcL7LgVRASogiXJV+c2460+2El0sqZcD2z0GEQfwghxfkCt5U2KABQmh2Oj/L
EWvYKM614jmKj15B6sPJEDrsKAEkmd1Jq1fNdMGmYxVRBofpkWJl0sKLuwkDzWgO
64nE/bYo4m/bG8q/nzVr01+r1j3pn1KK+abddZZZlvqGBFa76fAiWlCMr7WJTIde
e08Mq5ufOBOZAYxOs4YBJjoriug3nxq9ozZkj+0d4xgfvAxNWRgAEdhXz1nGcdz7
3ZOshwcXi4RHyyAYJg6u
=J3r/
-----END PGP SIGNATURE-----

--cQ69W14HbP5Lg69N41p23H5UMufnN6rre--


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

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

--===============2832209043405747859==--


From xen-devel-bounces@lists.xen.org Mon Nov 03 09:45:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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 1XlECB-0005Mi-Pw; Mon, 03 Nov 2014 09:45:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XlECA-0005MU-Fc
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:45:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9C/61-09936-1AE47545; Mon, 03 Nov 2014 09:45:05 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415007905!12343752!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6311 invoked from network); 3 Nov 2014 09:45:05 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-7.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 09:45:05 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>) id 1XlEC9-0000ID-58
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:45:05 +0000
Message-ID: <54574EA0.5070101@canonical.com>
Date: Mon, 03 Nov 2014 10:45:04 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
	ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2832209043405747859=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--cQ69W14HbP5Lg69N41p23H5UMufnN6rre
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

I see the message from the subject on my Intel box whenever a guest (iirc=
 even
dom0) starts up. It is not fatal and everything seems ok. I am just curio=
us
about what might trigger this. The addresses look to be inside the hyperv=
isor
code. I was wondering whether there is a simple way to figure out what th=
is
relates to (likely need to look at the objdump of the unstripped hv modul=
e).

Or has someone already looked into this and knows what likely is the caus=
e?

-Stefan


--cQ69W14HbP5Lg69N41p23H5UMufnN6rre
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

iQIcBAEBCgAGBQJUV06gAAoJEOhnXe7L7s6jR+gP/RKx76b6HSxJhfoY5bopinh2
Ey4C63qcHT7vf40c6FwfVU4RhMR1Rykws3vhOYYy0BqNAl/DYb+EJ1vdVVt7gFac
rQ/JafbvUkuWgZLlsnmuluGnV5HLxbKXqO+0VcUD4A+mRE94bHqYnhaUQLKhkuoN
/djM+8Hw3ycdamW69W2aShvGNoGfQ4cl5fFGLgTJHarTDiW/HuiHnthmy2kOVTsU
fdVKrzncUGX5lIIaRCkPvP2n9qz1mVNQqmUhbAfKYtu9VyQvBhJX7M6mWUfS6brt
baiBtuN91ooitSqlgBKKxRiT0WJL8Pd4Am1AzdURINyYAo8mj4knvcEhWwOrIHwy
iO3Jyl1EvrNlXsfQmU08EUupFMIObh7OCGZK2FeBKMObdmiK6Y0KBE/fQrT6g+WA
qfETcL7LgVRASogiXJV+c2460+2El0sqZcD2z0GEQfwghxfkCt5U2KABQmh2Oj/L
EWvYKM614jmKj15B6sPJEDrsKAEkmd1Jq1fNdMGmYxVRBofpkWJl0sKLuwkDzWgO
64nE/bYo4m/bG8q/nzVr01+r1j3pn1KK+abddZZZlvqGBFa76fAiWlCMr7WJTIde
e08Mq5ufOBOZAYxOs4YBJjoriug3nxq9ozZkj+0d4xgfvAxNWRgAEdhXz1nGcdz7
3ZOshwcXi4RHyyAYJg6u
=J3r/
-----END PGP SIGNATURE-----

--cQ69W14HbP5Lg69N41p23H5UMufnN6rre--


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

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

--===============2832209043405747859==--


From xen-devel-bounces@lists.xen.org Mon Nov 03 09:45:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlECs-0005SA-A1; Mon, 03 Nov 2014 09:45:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlECr-0005Rv-8o
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:45:49 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	36/A8-14727-CCE47545; Mon, 03 Nov 2014 09:45:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415007947!10819574!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23783 invoked from network); 3 Nov 2014 09:45:48 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:45:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:45:47 +0000
Message-Id: <54575CD60200007800044426@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:45:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
In-Reply-To: <54574BC0.7000709@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 16:53, Jan Beulich wrote:
>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>>>> when we really need them.
>>>>>>>>
>>>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>>> include that header (making sure declaration and definition are and
>>>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>>>> (and certain other code system components) the consequences of
>>>>>>>> being lax are much more severe.
>>>>>>>
>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>>> '<xen/memory.h>,
>>>>>>>
>>>>>>> #include "util.h"
>>>>>>> ...
>>>>>>> #include <xen/memory.h>
>>>>>>>
>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>>
>>>>>> Redefine? I said forward declare.
>>>>>
>>>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>>
>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>>
>>>> To me this looks very much like poor programming style, even if in
>>>> the context of hvmloader communicating information via global
>>>> variables rather than function arguments and return values is
>>>
>>> Do you mean you don't like a global variable? But it can be use to get
>>> RDM without more hypercall or function call in the context of hvmloader.
>>
>> This argument which you brought up before, and which we commented
>> on before, is pretty pointless. We don't really care much about doing
>> one or two more hypercalls from hvmloader, unless these would be
>> long-running ones.
>>
> 
> Another benefit to use a global variable is that we wouldn't allocate 
> xen_reserved_device_memory * N each time, and reduce some duplicated 
> codes, unless you mean I should define that as static inside in local.

Now this reason is indeed worth a consideration. How many times is
the data being needed/retrieved?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:45:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlECs-0005SA-A1; Mon, 03 Nov 2014 09:45:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlECr-0005Rv-8o
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:45:49 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	36/A8-14727-CCE47545; Mon, 03 Nov 2014 09:45:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415007947!10819574!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23783 invoked from network); 3 Nov 2014 09:45:48 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:45:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:45:47 +0000
Message-Id: <54575CD60200007800044426@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:45:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
In-Reply-To: <54574BC0.7000709@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 16:53, Jan Beulich wrote:
>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>>>> when we really need them.
>>>>>>>>
>>>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>>> include that header (making sure declaration and definition are and
>>>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>>>> (and certain other code system components) the consequences of
>>>>>>>> being lax are much more severe.
>>>>>>>
>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>>> '<xen/memory.h>,
>>>>>>>
>>>>>>> #include "util.h"
>>>>>>> ...
>>>>>>> #include <xen/memory.h>
>>>>>>>
>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>>
>>>>>> Redefine? I said forward declare.
>>>>>
>>>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>>
>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>>
>>>> To me this looks very much like poor programming style, even if in
>>>> the context of hvmloader communicating information via global
>>>> variables rather than function arguments and return values is
>>>
>>> Do you mean you don't like a global variable? But it can be use to get
>>> RDM without more hypercall or function call in the context of hvmloader.
>>
>> This argument which you brought up before, and which we commented
>> on before, is pretty pointless. We don't really care much about doing
>> one or two more hypercalls from hvmloader, unless these would be
>> long-running ones.
>>
> 
> Another benefit to use a global variable is that we wouldn't allocate 
> xen_reserved_device_memory * N each time, and reduce some duplicated 
> codes, unless you mean I should define that as static inside in local.

Now this reason is indeed worth a consideration. How many times is
the data being needed/retrieved?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:51:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEIM-0005n0-TB; Mon, 03 Nov 2014 09:51:30 +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 1XlEIL-0005mt-W4
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:51:30 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	84/E0-03148-12057545; Mon, 03 Nov 2014 09:51:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415008288!12168315!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25224 invoked from network); 3 Nov 2014 09:51:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:51:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:51:28 +0000
Message-Id: <54575E2D0200007800044443@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:51:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
In-Reply-To: <54574D8F.8060407@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 10:40, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 16:56, Jan Beulich wrote:
>>>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
>>> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>>>    From: Chen, Tiejun
>>>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>>>> Thinking about this some more, this odd universal hole punching in
>>>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>>>> this really should be optional behavior, with pass through of devices
>>>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>>>> punching holes for _just_ the devices passed through to a guest
>>>>>>> upon creation when the option is not enabled.)
>>>>>>
>>>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>>>> conflict with anything. So what about this idea?
>>>>>>
>>>>>
>>>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>>>> approach. When the parameter is on, RMRR check/hole punch is
>>>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>>>
>>>>> If user configures device pass-through at creation time, this parameter
>>>>> will be set by default. If user wants the VM capable of device hot-plug,
>>>>> an explicit parameter can be added in the config file to enforce RMRR
>>>>> check at creation time.
>>>>
>>>> Not exactly, I specifically described it slightly differently above. When
>>>> devices get passed through and the option is absent, holes should be
>>>> punched only for the RMRRs associated with those devices (i.e.
>>>> ideally none). Of course this means we'll need a way to associate
>>>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>>>> XENMEM_reserved_device_memory_map alone won't suffice.
>>>
>>> Yeah, current hypercall just provide RMRR entries without that
>>> associated BDF. And especially, in some cases one range may be shared by
>>> multiple devices...
>>
>> Before we decide who's going to do an eventual change we need to
>> determine what behavior we want, and whether this hypercall is
>> really the right one. Quite possibly we'd need a per-domain view
>> along with the global view, and hence rather than modifying this one
>> we may need to introduce e.g. a new domctl.
>>
> 
> If we really need to work with a hypercall, maybe we can introduce a 
> little bit to construct that to callback with multiple entries like 
> this, for instance,
> 
> RMRR entry0 have three devices, and entry1 have two devices,
> 
> [start0, nr_pages0, bdf0],
> [start0, nr_pages0, bdf1],
> [start0, nr_pages0, bdf2],
> [start1, nr_pages1, bdf3],
> [start1, nr_pages1, bdf4],
> 
> Although its cost more buffers, actually as you know this actual case is 
> really rare. So maybe this way can be feasible. Then we don't need 
> additional hypercall or xenstore.

Conceptually, as a MEMOP, it has no business reporting BDFs. And
then rather than returning the same address range more than once,
having the caller supply a handle to an array and storing all of the
SBDFs (or perhaps a single segment would suffice along with all the
BDFs) there would seem to be an approach more consistent with
what we do elsewhere.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:51:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEID-0005m0-Ap; Mon, 03 Nov 2014 09:51:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlEIB-0005lv-Tr
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:51:20 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	EB/CB-02699-71057545; Mon, 03 Nov 2014 09:51:19 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415008277!12150738!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29810 invoked from network); 3 Nov 2014 09:51:18 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-27.messagelabs.com with SMTP;
	3 Nov 2014 09:51:18 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 01:51:17 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="615917687"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 01:51:15 -0800
Message-ID: <54575013.50702@intel.com>
Date: Mon, 03 Nov 2014 17:51:15 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
In-Reply-To: <5457523A02000078000443C7@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 17:00, Jan Beulich wrote:
>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>> On 2014/10/31 16:25, Jan Beulich wrote:
>>>>>> On 31.10.14 at 03:50, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/30 17:24, Jan Beulich wrote:
>>>>>>>> On 30.10.14 at 08:39, <tiejun.chen@intel.com> wrote:
>>>>>> @@ -686,8 +686,22 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>>>>>          /* Now, actually do the two-way mapping */
>>>>>>          if ( mfn_valid(_mfn(mfn)) )
>>>>>>          {
>>>>>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>>>>>> -                           p2m->default_access);
>>>>>> +        rc = 0;
>>>>>> +        a =  p2m->default_access;
>>>>>> +        if ( !is_hardware_domain(d) )
>>>>>> +        {
>>>>>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>>>>>> +                                                  &gfn);
>>>>>> +            /* We need to set reserved device memory as p2m_access_n. */
>>>>>> +            if ( rc == 1 )
>>>>>> +                a = p2m_access_n;
>>>>>> +            else if ( rc < 0 )
>>>>>> +                printk(XENLOG_WARNING
>>>>>> +                       "Domain %d can't check reserved device memory.\n",
>>>>>> +                       d->domain_id);
>>>>>> +        }
>>>>>> +
>>>>>> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
>>>>>>              if ( rc )
>>>>>>                  goto out; /* Failed to update p2m, bail without updating m2p.
>>>> */
>>>>>
>>>>> The handling of "a" looks good now, but the error handling and
>>>>> logging is still as broken as it was before.
>>>>
>>>> Do you mean I'm missing some necessary info? Like gfn and mfn, so domain
>>>> id, gfn and mfn can show enough message.
>>>>
>>>> Sorry I'm poor to understand what you expect.
>>>
>>> But I explained it already, and that explanation is still visible in
>>> the quotes above. But to avoid any doubt, I'll repeat: "And
>>
>> I tried to understand what you said but felt a confusion so ask if you
>> show me directly.
>>
>>> properly handle the error case (just logging a message - which
>>> btw lacks a proper XENLOG_G_* prefix - doesn't seem enough
>>> to me)."
>>
>> Looks there are two problems:
>>
>> #1: the error message
>>
>> If current line is not fine,
>> 	printk(XENLOG_G_WARNING "Domain %d can't check reserved device
>> memory.\n", d->domain_id);
>>
>> I mean could you change this directly.
>
> This looks reasonable, albeit we generally prefer Dom%d or dom%d
> so that messages are somewhat grep-able.

Fixed.

>
>> #2 the error handling
>>
>> In an error case what should I do? Currently we still create these
>> mapping as normal. This means these mfns will be valid so later we can't
>> set them again then device can't be assigned as passthrough. I think
>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>
> You should, with very few exceptions, not ignore errors (which
> includes "handling" them by just logging a message. Instead, you
> should propagate the error back up the call chain.
>

Do you mean in your patch,

+int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
+{
+    const struct iommu_ops *ops = iommu_get_ops();
+
+    if ( !iommu_enabled || !ops->get_reserved_device_memory )
+        return 0;
+
+    return ops->get_reserved_device_memory(func, ctxt);
+}
+

I shouldn't return that directly. Then instead, we should handle all 
error scenarios here?

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:51:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEIM-0005n0-TB; Mon, 03 Nov 2014 09:51:30 +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 1XlEIL-0005mt-W4
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:51:30 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	84/E0-03148-12057545; Mon, 03 Nov 2014 09:51:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415008288!12168315!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25224 invoked from network); 3 Nov 2014 09:51:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:51:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:51:28 +0000
Message-Id: <54575E2D0200007800044443@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:51:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
In-Reply-To: <54574D8F.8060407@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 10:40, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 16:56, Jan Beulich wrote:
>>>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
>>> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>>>    From: Chen, Tiejun
>>>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>>>> Thinking about this some more, this odd universal hole punching in
>>>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>>>> this really should be optional behavior, with pass through of devices
>>>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>>>> punching holes for _just_ the devices passed through to a guest
>>>>>>> upon creation when the option is not enabled.)
>>>>>>
>>>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>>>> conflict with anything. So what about this idea?
>>>>>>
>>>>>
>>>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>>>> approach. When the parameter is on, RMRR check/hole punch is
>>>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>>>
>>>>> If user configures device pass-through at creation time, this parameter
>>>>> will be set by default. If user wants the VM capable of device hot-plug,
>>>>> an explicit parameter can be added in the config file to enforce RMRR
>>>>> check at creation time.
>>>>
>>>> Not exactly, I specifically described it slightly differently above. When
>>>> devices get passed through and the option is absent, holes should be
>>>> punched only for the RMRRs associated with those devices (i.e.
>>>> ideally none). Of course this means we'll need a way to associate
>>>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>>>> XENMEM_reserved_device_memory_map alone won't suffice.
>>>
>>> Yeah, current hypercall just provide RMRR entries without that
>>> associated BDF. And especially, in some cases one range may be shared by
>>> multiple devices...
>>
>> Before we decide who's going to do an eventual change we need to
>> determine what behavior we want, and whether this hypercall is
>> really the right one. Quite possibly we'd need a per-domain view
>> along with the global view, and hence rather than modifying this one
>> we may need to introduce e.g. a new domctl.
>>
> 
> If we really need to work with a hypercall, maybe we can introduce a 
> little bit to construct that to callback with multiple entries like 
> this, for instance,
> 
> RMRR entry0 have three devices, and entry1 have two devices,
> 
> [start0, nr_pages0, bdf0],
> [start0, nr_pages0, bdf1],
> [start0, nr_pages0, bdf2],
> [start1, nr_pages1, bdf3],
> [start1, nr_pages1, bdf4],
> 
> Although its cost more buffers, actually as you know this actual case is 
> really rare. So maybe this way can be feasible. Then we don't need 
> additional hypercall or xenstore.

Conceptually, as a MEMOP, it has no business reporting BDFs. And
then rather than returning the same address range more than once,
having the caller supply a handle to an array and storing all of the
SBDFs (or perhaps a single segment would suffice along with all the
BDFs) there would seem to be an approach more consistent with
what we do elsewhere.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:51:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEID-0005m0-Ap; Mon, 03 Nov 2014 09:51:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlEIB-0005lv-Tr
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:51:20 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	EB/CB-02699-71057545; Mon, 03 Nov 2014 09:51:19 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415008277!12150738!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29810 invoked from network); 3 Nov 2014 09:51:18 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-27.messagelabs.com with SMTP;
	3 Nov 2014 09:51:18 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 01:51:17 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="615917687"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 01:51:15 -0800
Message-ID: <54575013.50702@intel.com>
Date: Mon, 03 Nov 2014 17:51:15 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
In-Reply-To: <5457523A02000078000443C7@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 17:00, Jan Beulich wrote:
>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>> On 2014/10/31 16:25, Jan Beulich wrote:
>>>>>> On 31.10.14 at 03:50, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/30 17:24, Jan Beulich wrote:
>>>>>>>> On 30.10.14 at 08:39, <tiejun.chen@intel.com> wrote:
>>>>>> @@ -686,8 +686,22 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>>>>>          /* Now, actually do the two-way mapping */
>>>>>>          if ( mfn_valid(_mfn(mfn)) )
>>>>>>          {
>>>>>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>>>>>> -                           p2m->default_access);
>>>>>> +        rc = 0;
>>>>>> +        a =  p2m->default_access;
>>>>>> +        if ( !is_hardware_domain(d) )
>>>>>> +        {
>>>>>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>>>>>> +                                                  &gfn);
>>>>>> +            /* We need to set reserved device memory as p2m_access_n. */
>>>>>> +            if ( rc == 1 )
>>>>>> +                a = p2m_access_n;
>>>>>> +            else if ( rc < 0 )
>>>>>> +                printk(XENLOG_WARNING
>>>>>> +                       "Domain %d can't check reserved device memory.\n",
>>>>>> +                       d->domain_id);
>>>>>> +        }
>>>>>> +
>>>>>> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
>>>>>>              if ( rc )
>>>>>>                  goto out; /* Failed to update p2m, bail without updating m2p.
>>>> */
>>>>>
>>>>> The handling of "a" looks good now, but the error handling and
>>>>> logging is still as broken as it was before.
>>>>
>>>> Do you mean I'm missing some necessary info? Like gfn and mfn, so domain
>>>> id, gfn and mfn can show enough message.
>>>>
>>>> Sorry I'm poor to understand what you expect.
>>>
>>> But I explained it already, and that explanation is still visible in
>>> the quotes above. But to avoid any doubt, I'll repeat: "And
>>
>> I tried to understand what you said but felt a confusion so ask if you
>> show me directly.
>>
>>> properly handle the error case (just logging a message - which
>>> btw lacks a proper XENLOG_G_* prefix - doesn't seem enough
>>> to me)."
>>
>> Looks there are two problems:
>>
>> #1: the error message
>>
>> If current line is not fine,
>> 	printk(XENLOG_G_WARNING "Domain %d can't check reserved device
>> memory.\n", d->domain_id);
>>
>> I mean could you change this directly.
>
> This looks reasonable, albeit we generally prefer Dom%d or dom%d
> so that messages are somewhat grep-able.

Fixed.

>
>> #2 the error handling
>>
>> In an error case what should I do? Currently we still create these
>> mapping as normal. This means these mfns will be valid so later we can't
>> set them again then device can't be assigned as passthrough. I think
>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>
> You should, with very few exceptions, not ignore errors (which
> includes "handling" them by just logging a message. Instead, you
> should propagate the error back up the call chain.
>

Do you mean in your patch,

+int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
+{
+    const struct iommu_ops *ops = iommu_get_ops();
+
+    if ( !iommu_enabled || !ops->get_reserved_device_memory )
+        return 0;
+
+    return ops->get_reserved_device_memory(func, ctxt);
+}
+

I shouldn't return that directly. Then instead, we should handle all 
error scenarios here?

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:52:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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.xen.org>)
	id 1XlEJL-0005yJ-C4; Mon, 03 Nov 2014 09:52:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlEJJ-0005xZ-G1
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 09:52:29 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	55/43-03148-C5057545; Mon, 03 Nov 2014 09:52:28 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415008347!12168658!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2646 invoked from network); 3 Nov 2014 09:52:28 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 09:52:28 -0000
Received: by mail-wi0-f179.google.com with SMTP id h11so5847855wiw.0
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 01:52:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=cvN3Dr6M5+m5SpwKJaNtO0SS/ItZoHBmGK6YT4uczbc=;
	b=mBc+2kYGy/KJS42KkPGPnpU5stVlN6BSKTW/3oAq9fFIOMMaQw4ktyt6SgOm8Ikp2v
	HUSOxFBkxYPybolP1iOcDCstIDObzAaP7UDPNMEvaA0HCkgTEEIXIWlYGcVjl7+j3POf
	JxVWEFYPOLEGwHDoWHdkCqPsJzb4Ny3XYGuWzIe0A4T0IOOYRzOT6R6ktRhgYmjY+TK0
	3t1Ocgjqyllnn4ZbeMN7SDqfIksvu4C9YlPureUm09kEE5wSXD+tjv9/mmRrLWjf0s2W
	MsbgURJ4LNeDF8gJk9qA0MMGEWqNxjR1xjprsZnFV+mDjHTWf4QgrukfoYWa3+PaZkXA
	njWQ==
X-Gm-Message-State: ALoCoQlzr16jSB3v/lm9gIgjcZ15VFA8jgjjwHDtY4HAIA+9qYaYZqfk+K5XE9zqE8IHjkamR5U5
X-Received: by 10.180.208.101 with SMTP id md5mr15292824wic.9.1415008347716;
	Mon, 03 Nov 2014 01:52:27 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id l4sm18171869wjx.14.2014.11.03.01.52.26
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 01:52:26 -0800 (PST)
Message-ID: <54575059.8080905@linaro.org>
Date: Mon, 03 Nov 2014 09:52:25 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>	<CAAiw7J=Mbb1YGYj=XQv6TmqyAMvcctUs7AvHQN_1O27xCRSp_Q@mail.gmail.com>	<20141031142403.GA6913@laptop.dumpdata.com>	<54539D4D.1040108@linaro.org>	<20141031210156.GA20039@laptop.dumpdata.com>	<54551BDD.5080800@linaro.org>	<CAAiw7J=0RbBwTJUS8AP9V88r7D+iKGjMpfF4rH_EOKi1GwBWMw@mail.gmail.com>	<545604CF.60905@linaro.org>
	<CAAiw7J=PvYq6s_DQ0gyaZx8gs_Xw2Z-X1BpKe6a3KwhNTkd+Uw@mail.gmail.com>
In-Reply-To: <CAAiw7J=PvYq6s_DQ0gyaZx8gs_Xw2Z-X1BpKe6a3KwhNTkd+Uw@mail.gmail.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, manish.jaggi@caviumnetworks.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ARM] SMMU and PCI passthrough Was: Re: Xen 4.5-rc1
 update (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 03/11/2014 05:08, manish jaggi wrote:
> On 2 November 2014 15:47, Julien Grall <julien.grall@linaro.org> wrote:
>> (Renaming the subject of the thread).
>>
>> On 02/11/2014 06:03, manish jaggi wrote:
>>>
>>> On 1 November 2014 23:13, Julien Grall <julien.grall@linaro.org> wrote:
>>>>
>>>> Hi Konrad,
>>>>
>>>>
>>>> On 31/10/2014 21:01, Konrad Rzeszutek Wilk wrote:
>>>>>
>>>>>
>>>>> On Fri, Oct 31, 2014 at 02:31:41PM +0000, Julien Grall wrote:
>>>>>>
>>>>>>
>>>>>> On 10/31/2014 02:24 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *  PVH - PCI passthrough for DomU.
>>>>>>>>
>>>>>>>>
>>>>>>>> I am working on Cavium Thunder (ARM64) on this feature.
>>>>>>>> [Xen SMMU driver changes + PCI passthrough changes in Xen and Linux]
>>>>>>
>>>>>>
>>>>>>
>>>>>> FYI, I'm currently reworking the SMMU drivers to resync with Linux.
>>>>>> With
>>>>>> thoses changes, you should not need to modify the SMMU code.
>>>>>
>>>>>
>>>>>
>>>>> Thank you for the update. Put your name behind that for 4.6.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Ok, replaced Julien's name with yours. Please make sure
>>>>>>> that for the Linux patches you CC xen-devel and the
>>>>>>> maintainers (David, Stefano, Boris and me).
>>>>>>
>>>>>>
>>>>>>
>>>>>> There is 2 distinct passthrough: platform (i.e non-PCI) and PCI one.
>>>>>>
>>>>>> While Manish is working on PCI passthrough, I'm still working the
>>>>>> non-PCI one. Please don't drop my name.
>>>>>
>>>>>
>>>>>
>>>>> I thought that Arianna's patches had taken care of that (the MMIO
>>>>> part?). Or does each platform need a different implementation of
>>>>> that?
>>>>
>>>>
>>>>
>>>> To passthrough a platform device you need to be able to assign the device
>>>> to
>>>> the guest via the IOMMU and map MMIOs (done by Arianna's series) and
>>>> interrupts.
>>>>
>>> For a PCI passthrough SMMU ops are to be added. The way the smmu for a
>>> pci device is found needs to be updated in the smmu.c, so there are
>>> some substantial changes to smmu.c for pci passthrough.
>>
>>
>> The SMMU drivers in Linux already supports PCI. As I'm currently resync our
>> driver with this version PCI assignment in the SMMU should come freely.
>>
>> I expect the only plumbing for the Xen callback and few bugs fixes will be
>> necessary.
>>
> we can discuss more on design level. There are changes

What kind of changes? Do you have a tree with them?

>>> Also MMIO mapping code the same pci device to be added.
>>
>>
>> Hmmm? What do you mean? MMIO mapping code is definitely not part of the SMMU
>> drivers.
>>
>> IIRC, this should be done by either the toolstack or PCI back in Linux.
>>
>>> So in short there changes, and as they are in the same files and
>>> features are also similar,  is it possible that we work together may
>>> be julien can provide a design document (simple txt file would do).
>>
>>
>> There is no need of design document for the SMMU drivers. Everything for DT
>> passthrough is already there.
>>
> It would be helpful if you can provide a basic flow.

http://lists.xen.org/archives/html/xen-devel/2014-07/msg04090.html

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:52:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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.xen.org>)
	id 1XlEJL-0005yJ-C4; Mon, 03 Nov 2014 09:52:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlEJJ-0005xZ-G1
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 09:52:29 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	55/43-03148-C5057545; Mon, 03 Nov 2014 09:52:28 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415008347!12168658!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2646 invoked from network); 3 Nov 2014 09:52:28 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 09:52:28 -0000
Received: by mail-wi0-f179.google.com with SMTP id h11so5847855wiw.0
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 01:52:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=cvN3Dr6M5+m5SpwKJaNtO0SS/ItZoHBmGK6YT4uczbc=;
	b=mBc+2kYGy/KJS42KkPGPnpU5stVlN6BSKTW/3oAq9fFIOMMaQw4ktyt6SgOm8Ikp2v
	HUSOxFBkxYPybolP1iOcDCstIDObzAaP7UDPNMEvaA0HCkgTEEIXIWlYGcVjl7+j3POf
	JxVWEFYPOLEGwHDoWHdkCqPsJzb4Ny3XYGuWzIe0A4T0IOOYRzOT6R6ktRhgYmjY+TK0
	3t1Ocgjqyllnn4ZbeMN7SDqfIksvu4C9YlPureUm09kEE5wSXD+tjv9/mmRrLWjf0s2W
	MsbgURJ4LNeDF8gJk9qA0MMGEWqNxjR1xjprsZnFV+mDjHTWf4QgrukfoYWa3+PaZkXA
	njWQ==
X-Gm-Message-State: ALoCoQlzr16jSB3v/lm9gIgjcZ15VFA8jgjjwHDtY4HAIA+9qYaYZqfk+K5XE9zqE8IHjkamR5U5
X-Received: by 10.180.208.101 with SMTP id md5mr15292824wic.9.1415008347716;
	Mon, 03 Nov 2014 01:52:27 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id l4sm18171869wjx.14.2014.11.03.01.52.26
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 01:52:26 -0800 (PST)
Message-ID: <54575059.8080905@linaro.org>
Date: Mon, 03 Nov 2014 09:52:25 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>	<CAAiw7J=Mbb1YGYj=XQv6TmqyAMvcctUs7AvHQN_1O27xCRSp_Q@mail.gmail.com>	<20141031142403.GA6913@laptop.dumpdata.com>	<54539D4D.1040108@linaro.org>	<20141031210156.GA20039@laptop.dumpdata.com>	<54551BDD.5080800@linaro.org>	<CAAiw7J=0RbBwTJUS8AP9V88r7D+iKGjMpfF4rH_EOKi1GwBWMw@mail.gmail.com>	<545604CF.60905@linaro.org>
	<CAAiw7J=PvYq6s_DQ0gyaZx8gs_Xw2Z-X1BpKe6a3KwhNTkd+Uw@mail.gmail.com>
In-Reply-To: <CAAiw7J=PvYq6s_DQ0gyaZx8gs_Xw2Z-X1BpKe6a3KwhNTkd+Uw@mail.gmail.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, manish.jaggi@caviumnetworks.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ARM] SMMU and PCI passthrough Was: Re: Xen 4.5-rc1
 update (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 03/11/2014 05:08, manish jaggi wrote:
> On 2 November 2014 15:47, Julien Grall <julien.grall@linaro.org> wrote:
>> (Renaming the subject of the thread).
>>
>> On 02/11/2014 06:03, manish jaggi wrote:
>>>
>>> On 1 November 2014 23:13, Julien Grall <julien.grall@linaro.org> wrote:
>>>>
>>>> Hi Konrad,
>>>>
>>>>
>>>> On 31/10/2014 21:01, Konrad Rzeszutek Wilk wrote:
>>>>>
>>>>>
>>>>> On Fri, Oct 31, 2014 at 02:31:41PM +0000, Julien Grall wrote:
>>>>>>
>>>>>>
>>>>>> On 10/31/2014 02:24 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *  PVH - PCI passthrough for DomU.
>>>>>>>>
>>>>>>>>
>>>>>>>> I am working on Cavium Thunder (ARM64) on this feature.
>>>>>>>> [Xen SMMU driver changes + PCI passthrough changes in Xen and Linux]
>>>>>>
>>>>>>
>>>>>>
>>>>>> FYI, I'm currently reworking the SMMU drivers to resync with Linux.
>>>>>> With
>>>>>> thoses changes, you should not need to modify the SMMU code.
>>>>>
>>>>>
>>>>>
>>>>> Thank you for the update. Put your name behind that for 4.6.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Ok, replaced Julien's name with yours. Please make sure
>>>>>>> that for the Linux patches you CC xen-devel and the
>>>>>>> maintainers (David, Stefano, Boris and me).
>>>>>>
>>>>>>
>>>>>>
>>>>>> There is 2 distinct passthrough: platform (i.e non-PCI) and PCI one.
>>>>>>
>>>>>> While Manish is working on PCI passthrough, I'm still working the
>>>>>> non-PCI one. Please don't drop my name.
>>>>>
>>>>>
>>>>>
>>>>> I thought that Arianna's patches had taken care of that (the MMIO
>>>>> part?). Or does each platform need a different implementation of
>>>>> that?
>>>>
>>>>
>>>>
>>>> To passthrough a platform device you need to be able to assign the device
>>>> to
>>>> the guest via the IOMMU and map MMIOs (done by Arianna's series) and
>>>> interrupts.
>>>>
>>> For a PCI passthrough SMMU ops are to be added. The way the smmu for a
>>> pci device is found needs to be updated in the smmu.c, so there are
>>> some substantial changes to smmu.c for pci passthrough.
>>
>>
>> The SMMU drivers in Linux already supports PCI. As I'm currently resync our
>> driver with this version PCI assignment in the SMMU should come freely.
>>
>> I expect the only plumbing for the Xen callback and few bugs fixes will be
>> necessary.
>>
> we can discuss more on design level. There are changes

What kind of changes? Do you have a tree with them?

>>> Also MMIO mapping code the same pci device to be added.
>>
>>
>> Hmmm? What do you mean? MMIO mapping code is definitely not part of the SMMU
>> drivers.
>>
>> IIRC, this should be done by either the toolstack or PCI back in Linux.
>>
>>> So in short there changes, and as they are in the same files and
>>> features are also similar,  is it possible that we work together may
>>> be julien can provide a design document (simple txt file would do).
>>
>>
>> There is no need of design document for the SMMU drivers. Everything for DT
>> passthrough is already there.
>>
> It would be helpful if you can provide a basic flow.

http://lists.xen.org/archives/html/xen-devel/2014-07/msg04090.html

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:53:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEJs-00064Y-RS; Mon, 03 Nov 2014 09:53:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlEJp-00063q-SV
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:53:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	22/F1-09936-D7057545; Mon, 03 Nov 2014 09:53:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415008380!12341465!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25068 invoked from network); 3 Nov 2014 09:53:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:53:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:53:00 +0000
Message-Id: <54575E890200007800044446@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:52:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <54574EA0.5070101@canonical.com>
In-Reply-To: <54574EA0.5070101@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 10:45, <stefan.bader@canonical.com> wrote:
> I see the message from the subject on my Intel box whenever a guest (iirc 
> even
> dom0) starts up. It is not fatal and everything seems ok. I am just curious
> about what might trigger this. The addresses look to be inside the 
> hypervisor
> code. I was wondering whether there is a simple way to figure out what this
> relates to (likely need to look at the objdump of the unstripped hv module).
> 
> Or has someone already looked into this and knows what likely is the cause?

Often guest MSR accesses cause this. addr2line on the corresponding
xen-syms should tell you.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:53:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEJs-00064Y-RS; Mon, 03 Nov 2014 09:53:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlEJp-00063q-SV
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:53:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	22/F1-09936-D7057545; Mon, 03 Nov 2014 09:53:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415008380!12341465!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25068 invoked from network); 3 Nov 2014 09:53:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 09:53:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 09:53:00 +0000
Message-Id: <54575E890200007800044446@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 09:52:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <54574EA0.5070101@canonical.com>
In-Reply-To: <54574EA0.5070101@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 10:45, <stefan.bader@canonical.com> wrote:
> I see the message from the subject on my Intel box whenever a guest (iirc 
> even
> dom0) starts up. It is not fatal and everything seems ok. I am just curious
> about what might trigger this. The addresses look to be inside the 
> hypervisor
> code. I was wondering whether there is a simple way to figure out what this
> relates to (likely need to look at the objdump of the unstripped hv module).
> 
> Or has someone already looked into this and knows what likely is the cause?

Often guest MSR accesses cause this. addr2line on the corresponding
xen-syms should tell you.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:55:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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 1XlEM7-0006OX-Dp; Mon, 03 Nov 2014 09:55:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlEM6-0006ON-L9
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:55:22 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	A1/9B-11608-90157545; Mon, 03 Nov 2014 09:55:21 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415008518!11243507!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28660 invoked from network); 3 Nov 2014 09:55:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 09:55:21 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 01:55:09 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="615918861"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 01:55:07 -0800
Message-ID: <545750FA.9090001@intel.com>
Date: Mon, 03 Nov 2014 17:55:06 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
In-Reply-To: <54575CD60200007800044426@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 17:45, Jan Beulich wrote:
>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 16:53, Jan Beulich wrote:
>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>>>>> when we really need them.
>>>>>>>>>
>>>>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>>>> include that header (making sure declaration and definition are and
>>>>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>>>>> (and certain other code system components) the consequences of
>>>>>>>>> being lax are much more severe.
>>>>>>>>
>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>>>> '<xen/memory.h>,
>>>>>>>>
>>>>>>>> #include "util.h"
>>>>>>>> ...
>>>>>>>> #include <xen/memory.h>
>>>>>>>>
>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>>>
>>>>>>> Redefine? I said forward declare.
>>>>>>
>>>>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>>>
>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>>>
>>>>> To me this looks very much like poor programming style, even if in
>>>>> the context of hvmloader communicating information via global
>>>>> variables rather than function arguments and return values is
>>>>
>>>> Do you mean you don't like a global variable? But it can be use to get
>>>> RDM without more hypercall or function call in the context of hvmloader.
>>>
>>> This argument which you brought up before, and which we commented
>>> on before, is pretty pointless. We don't really care much about doing
>>> one or two more hypercalls from hvmloader, unless these would be
>>> long-running ones.
>>>
>>
>> Another benefit to use a global variable is that we wouldn't allocate
>> xen_reserved_device_memory * N each time, and reduce some duplicated
>> codes, unless you mean I should define that as static inside in local.
>
> Now this reason is indeed worth a consideration. How many times is
> the data being needed/retrieved?

Currently there are two cases in tools/hvmloader, setup pci and build 
e820 table. Each time, as you know we don't know how may entries we 
should require, so we always allocate one instance then according to the 
return value to allocate the proper instances to get that.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:55:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09: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 1XlEM7-0006OX-Dp; Mon, 03 Nov 2014 09:55:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlEM6-0006ON-L9
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:55:22 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	A1/9B-11608-90157545; Mon, 03 Nov 2014 09:55:21 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415008518!11243507!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28660 invoked from network); 3 Nov 2014 09:55:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 09:55:21 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 01:55:09 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="615918861"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 01:55:07 -0800
Message-ID: <545750FA.9090001@intel.com>
Date: Mon, 03 Nov 2014 17:55:06 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
In-Reply-To: <54575CD60200007800044426@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 17:45, Jan Beulich wrote:
>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 16:53, Jan Beulich wrote:
>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>>>>> when we really need them.
>>>>>>>>>
>>>>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>>>> include that header (making sure declaration and definition are and
>>>>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>>>>> (and certain other code system components) the consequences of
>>>>>>>>> being lax are much more severe.
>>>>>>>>
>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>>>> '<xen/memory.h>,
>>>>>>>>
>>>>>>>> #include "util.h"
>>>>>>>> ...
>>>>>>>> #include <xen/memory.h>
>>>>>>>>
>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>>>
>>>>>>> Redefine? I said forward declare.
>>>>>>
>>>>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>>>
>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>>>
>>>>> To me this looks very much like poor programming style, even if in
>>>>> the context of hvmloader communicating information via global
>>>>> variables rather than function arguments and return values is
>>>>
>>>> Do you mean you don't like a global variable? But it can be use to get
>>>> RDM without more hypercall or function call in the context of hvmloader.
>>>
>>> This argument which you brought up before, and which we commented
>>> on before, is pretty pointless. We don't really care much about doing
>>> one or two more hypercalls from hvmloader, unless these would be
>>> long-running ones.
>>>
>>
>> Another benefit to use a global variable is that we wouldn't allocate
>> xen_reserved_device_memory * N each time, and reduce some duplicated
>> codes, unless you mean I should define that as static inside in local.
>
> Now this reason is indeed worth a consideration. How many times is
> the data being needed/retrieved?

Currently there are two cases in tools/hvmloader, setup pci and build 
e820 table. Each time, as you know we don't know how may entries we 
should require, so we always allocate one instance then according to the 
return value to allocate the proper instances to get that.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:58:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:58:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEPD-0006Zh-2n; Mon, 03 Nov 2014 09:58:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XlEPB-0006Zb-Cn
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:58:33 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	33/44-01660-8C157545; Mon, 03 Nov 2014 09:58:32 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415008710!10822808!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24780 invoked from network); 3 Nov 2014 09:58:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 09:58:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="187448803"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 04:58:28 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XlEP6-0005xW-1W;
	Mon, 03 Nov 2014 09:58:28 +0000
Message-ID: <545751B0.4010503@eu.citrix.com>
Date: Mon, 3 Nov 2014 09:58:08 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Wen Congyang <wency@cn.fujitsu.com>
References: <1413252845-23433-1-git-send-email-wency@cn.fujitsu.com>	<21565.17844.525542.420665@mariner.uk.xensource.com>	<543DC859.1080207@cn.fujitsu.com>
	<CAFLBxZZ+EpHNkcQ2NYC3vspZg-v7uKQsuKX=hW=0KWJXuvDQvA@mail.gmail.com>
	<54507FFB.6090800@cn.fujitsu.com>
In-Reply-To: <54507FFB.6090800@cn.fujitsu.com>
X-DLP: MIA1
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 00/17] blktap2 related bugfix patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/29/2014 05:49 AM, Wen Congyang wrote:
> On 10/20/2014 10:25 PM, George Dunlap wrote:
>> On Wed, Oct 15, 2014 at 2:05 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
>>> On 10/14/2014 11:48 PM, Ian Jackson wrote:
>>>> Wen Congyang writes ("[PATCH 00/17] blktap2 related bugfix patches"):
>>>>> These bugs are found when we implement COLO, or rebase
>>>>> COLO to upstream xen. They are independent patches, so
>>>>> post them in separate series.
>>>> blktap2 is unmaintained AFAICT.
>>>>
>>>> In the last year there has been only one commit which shows evidence
>>>> of someone caring even slightly about tools/blktap2/.  The last
>>>> substantial attention was in March 2013.
>>>>
>>>> (I'm disregarding commits which touch tools/blktap2/ to fix up compile
>>>> problems with new compilers, sort out build system and file
>>>> rearrangements, etc.)
>>>>
>>>> The file you are touching in your 01/17 was last edited (by anyone, at
>>>> all) in January 2010.
>>>>
>>>> Under the circumstances, we should probably take all these changes
>>>> without looking for anyone to ack them.
>>>>
>>>> Perhaps you would like to become the maintainers of blktap2 ? :-)
>>> Hmm, I don't have any knowledge about disk format, but blktap2 have
>>> such codes(For example: block-vhd.c, block-qcow.c...). I think I can
>>> maintain the rest codes.
>> Congyang, were you aware that XenServer has a fork of blktap is
>> actually still under active development and maintainership outside of
>> the main Xen tree?
>>
>> git://github.com/xen-org/blktap.git
>>
>> Both CentOS and Fedora are actually using snapshots of the "blktap2"
>> branch in that tree for their Xen RPMs.  (I'm sure CentOS is, I
>> believe Fedora is.)  It's not unlikely that the bugs you're fixing
>> here have already been fixed in the XenServer fork.
> I have another question:
> Why we don't merge the "blktap2' branch into xen upstream periodically?

I take it you've found blktap "2.5" useful? :-)

I've been meaning to write an e-mail about this.

The basic reason is that it's normally up to the people doing the 
development to submit changes upstream.  Some years ago XenServer forked 
the blktap2 codebase but got behind in upstreaming things; at this point 
there are far too many changes to simply push them upstream.  
Furthermore, even XenServer isn't 100% sure what they're going to do in 
the future; as of a year ago they were planning to get rid of blktap 
entirely in favor of another solution.

One of the ideas I'm going to discuss in my e-mail is the idea of 
treating blktap2.5 (and/or blktap3) as an external upstream project, 
similar to the way that we treat qemu, seabios, ipxe, and ovmf. That 
would have a similar effect to what you describe.

  -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:58:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:58:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEPD-0006Zh-2n; Mon, 03 Nov 2014 09:58:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XlEPB-0006Zb-Cn
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:58:33 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	33/44-01660-8C157545; Mon, 03 Nov 2014 09:58:32 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415008710!10822808!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24780 invoked from network); 3 Nov 2014 09:58:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 09:58:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="187448803"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 04:58:28 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XlEP6-0005xW-1W;
	Mon, 03 Nov 2014 09:58:28 +0000
Message-ID: <545751B0.4010503@eu.citrix.com>
Date: Mon, 3 Nov 2014 09:58:08 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Wen Congyang <wency@cn.fujitsu.com>
References: <1413252845-23433-1-git-send-email-wency@cn.fujitsu.com>	<21565.17844.525542.420665@mariner.uk.xensource.com>	<543DC859.1080207@cn.fujitsu.com>
	<CAFLBxZZ+EpHNkcQ2NYC3vspZg-v7uKQsuKX=hW=0KWJXuvDQvA@mail.gmail.com>
	<54507FFB.6090800@cn.fujitsu.com>
In-Reply-To: <54507FFB.6090800@cn.fujitsu.com>
X-DLP: MIA1
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 00/17] blktap2 related bugfix patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/29/2014 05:49 AM, Wen Congyang wrote:
> On 10/20/2014 10:25 PM, George Dunlap wrote:
>> On Wed, Oct 15, 2014 at 2:05 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
>>> On 10/14/2014 11:48 PM, Ian Jackson wrote:
>>>> Wen Congyang writes ("[PATCH 00/17] blktap2 related bugfix patches"):
>>>>> These bugs are found when we implement COLO, or rebase
>>>>> COLO to upstream xen. They are independent patches, so
>>>>> post them in separate series.
>>>> blktap2 is unmaintained AFAICT.
>>>>
>>>> In the last year there has been only one commit which shows evidence
>>>> of someone caring even slightly about tools/blktap2/.  The last
>>>> substantial attention was in March 2013.
>>>>
>>>> (I'm disregarding commits which touch tools/blktap2/ to fix up compile
>>>> problems with new compilers, sort out build system and file
>>>> rearrangements, etc.)
>>>>
>>>> The file you are touching in your 01/17 was last edited (by anyone, at
>>>> all) in January 2010.
>>>>
>>>> Under the circumstances, we should probably take all these changes
>>>> without looking for anyone to ack them.
>>>>
>>>> Perhaps you would like to become the maintainers of blktap2 ? :-)
>>> Hmm, I don't have any knowledge about disk format, but blktap2 have
>>> such codes(For example: block-vhd.c, block-qcow.c...). I think I can
>>> maintain the rest codes.
>> Congyang, were you aware that XenServer has a fork of blktap is
>> actually still under active development and maintainership outside of
>> the main Xen tree?
>>
>> git://github.com/xen-org/blktap.git
>>
>> Both CentOS and Fedora are actually using snapshots of the "blktap2"
>> branch in that tree for their Xen RPMs.  (I'm sure CentOS is, I
>> believe Fedora is.)  It's not unlikely that the bugs you're fixing
>> here have already been fixed in the XenServer fork.
> I have another question:
> Why we don't merge the "blktap2' branch into xen upstream periodically?

I take it you've found blktap "2.5" useful? :-)

I've been meaning to write an e-mail about this.

The basic reason is that it's normally up to the people doing the 
development to submit changes upstream.  Some years ago XenServer forked 
the blktap2 codebase but got behind in upstreaming things; at this point 
there are far too many changes to simply push them upstream.  
Furthermore, even XenServer isn't 100% sure what they're going to do in 
the future; as of a year ago they were planning to get rid of blktap 
entirely in favor of another solution.

One of the ideas I'm going to discuss in my e-mail is the idea of 
treating blktap2.5 (and/or blktap3) as an external upstream project, 
similar to the way that we treat qemu, seabios, ipxe, and ovmf. That 
would have a similar effect to what you describe.

  -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:59:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:59:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEQC-0006eL-Gy; Mon, 03 Nov 2014 09:59:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlEQB-0006eD-6Z
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:59:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E6/21-09842-60257545; Mon, 03 Nov 2014 09:59:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415008772!12334896!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27920 invoked from network); 3 Nov 2014 09:59:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 09:59:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="187449010"
Message-ID: <1415008770.9994.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <seabios@seabios.org>
Date: Mon, 3 Nov 2014 09:59:30 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Regression booting winxp under Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xen's automated test system is reporting[1] that something between
bfb7b58b3068 and 136d4ec190af (for reference the previous pass is[2])
has broken booting winxp under Xen with Seabios.

Logs for one of the failures can be found at[3] (reached by following
the email's link to [4] and clicking the header of a failing column).
The VNC screenshot of the guest shows "Setup is inspecting your hardware
configuration..." (at least for those which have such a screenshot, not
sure why some don't).

I've not investigated more thoroughly yes, just posting in case
something obvious leaps out at someone. The automated test is currently
bisecting the issue, once it is done I'll let you know the result.

[1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg03543.html
[2] http://lists.xen.org/archives/html/xen-devel/2014-10/msg01993.html
[3] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/test-amd64-i386-xl-qemuu-winxpsp3-vcpus1/info.html
[4] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 09:59:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 09:59:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEQC-0006eL-Gy; Mon, 03 Nov 2014 09:59:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlEQB-0006eD-6Z
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 09:59:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E6/21-09842-60257545; Mon, 03 Nov 2014 09:59:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415008772!12334896!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27920 invoked from network); 3 Nov 2014 09:59:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 09:59:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="187449010"
Message-ID: <1415008770.9994.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <seabios@seabios.org>
Date: Mon, 3 Nov 2014 09:59:30 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Regression booting winxp under Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xen's automated test system is reporting[1] that something between
bfb7b58b3068 and 136d4ec190af (for reference the previous pass is[2])
has broken booting winxp under Xen with Seabios.

Logs for one of the failures can be found at[3] (reached by following
the email's link to [4] and clicking the header of a failing column).
The VNC screenshot of the guest shows "Setup is inspecting your hardware
configuration..." (at least for those which have such a screenshot, not
sure why some don't).

I've not investigated more thoroughly yes, just posting in case
something obvious leaps out at someone. The automated test is currently
bisecting the issue, once it is done I'll let you know the result.

[1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg03543.html
[2] http://lists.xen.org/archives/html/xen-devel/2014-10/msg01993.html
[3] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/test-amd64-i386-xl-qemuu-winxpsp3-vcpus1/info.html
[4] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:00:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlER7-0006oz-5o; Mon, 03 Nov 2014 10:00:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlER6-0006on-46
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:00:32 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	0E/9A-03145-F3257545; Mon, 03 Nov 2014 10:00:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415008830!12167138!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24160 invoked from network); 3 Nov 2014 10:00:30 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 10:00:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 10:00:30 +0000
Message-Id: <54576049020000780004446E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 10:00:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Razvan Cojocaru" <rcojocaru@bitdefender.com>
References: <1415007578-7584-1-git-send-email-rcojocaru@bitdefender.com>
In-Reply-To: <1415007578-7584-1-git-send-email-rcojocaru@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: Disable emulate.c REP optimization if
 introspection is active
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 10:39, <rcojocaru@bitdefender.com> wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -395,6 +395,7 @@ static int hvmemul_virtual_to_linear(
>  {
>      struct segment_register *reg;
>      int okay;
> +    struct domain *currd = current->domain;

This is being used just once and hence not really worthwhile.

> @@ -402,12 +403,15 @@ static int hvmemul_virtual_to_linear(
>          return X86EMUL_OKAY;
>      }
>  
> -    /*
> -     * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
> -     * The chosen maximum is very conservative but it's what we use in
> -     * hvmemul_linear_to_phys() so there is no point in using a larger value.
> -     */
> -    *reps = min_t(unsigned long, *reps, 4096);
> +    if ( currd->arch.hvm_domain.introspection_enabled )
> +        *reps = 1;
> +    else
> +        /*
> +         * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
> +         * The chosen maximum is very conservative but it's what we use in
> +         * hvmemul_linear_to_phys() so there is no point in using a larger value.
> +         */
> +        *reps = min_t(unsigned long, *reps, 4096);

With introspection_enabled supposedly being the unusual case (at
least for the majority of current users), a likely()/unlikely() annotation
should be used here. Further, with it being unclear (at least from
patch description and context alone) whether *reps could legally be
zero when getting here, I'd prefer

    *reps = min_t(unsigned long, *reps,
                  unlikely(current->domain->arch.hvm_domain.introspection_enabled)
                           ? 1 : 4096);

Perhaps with an adjustment to the comment explaining why.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:00:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlER7-0006oz-5o; Mon, 03 Nov 2014 10:00:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlER6-0006on-46
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:00:32 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	0E/9A-03145-F3257545; Mon, 03 Nov 2014 10:00:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415008830!12167138!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24160 invoked from network); 3 Nov 2014 10:00:30 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 10:00:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 10:00:30 +0000
Message-Id: <54576049020000780004446E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 10:00:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Razvan Cojocaru" <rcojocaru@bitdefender.com>
References: <1415007578-7584-1-git-send-email-rcojocaru@bitdefender.com>
In-Reply-To: <1415007578-7584-1-git-send-email-rcojocaru@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: Disable emulate.c REP optimization if
 introspection is active
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 10:39, <rcojocaru@bitdefender.com> wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -395,6 +395,7 @@ static int hvmemul_virtual_to_linear(
>  {
>      struct segment_register *reg;
>      int okay;
> +    struct domain *currd = current->domain;

This is being used just once and hence not really worthwhile.

> @@ -402,12 +403,15 @@ static int hvmemul_virtual_to_linear(
>          return X86EMUL_OKAY;
>      }
>  
> -    /*
> -     * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
> -     * The chosen maximum is very conservative but it's what we use in
> -     * hvmemul_linear_to_phys() so there is no point in using a larger value.
> -     */
> -    *reps = min_t(unsigned long, *reps, 4096);
> +    if ( currd->arch.hvm_domain.introspection_enabled )
> +        *reps = 1;
> +    else
> +        /*
> +         * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
> +         * The chosen maximum is very conservative but it's what we use in
> +         * hvmemul_linear_to_phys() so there is no point in using a larger value.
> +         */
> +        *reps = min_t(unsigned long, *reps, 4096);

With introspection_enabled supposedly being the unusual case (at
least for the majority of current users), a likely()/unlikely() annotation
should be used here. Further, with it being unclear (at least from
patch description and context alone) whether *reps could legally be
zero when getting here, I'd prefer

    *reps = min_t(unsigned long, *reps,
                  unlikely(current->domain->arch.hvm_domain.introspection_enabled)
                           ? 1 : 4096);

Perhaps with an adjustment to the comment explaining why.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:00:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlERW-0006tO-Lx; Mon, 03 Nov 2014 10:00:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XlERU-0006t2-UF
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:00:57 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	DF/45-02559-85257545; Mon, 03 Nov 2014 10:00:56 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415008855!12147848!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17189 invoked from network); 3 Nov 2014 10:00:55 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 10:00:55 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XlERR-0000pp-7H; Mon, 03 Nov 2014 10:00:53 +0000
Message-ID: <54575252.4060408@canonical.com>
Date: Mon, 03 Nov 2014 11:00:50 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54574EA0.5070101@canonical.com>
	<54575E890200007800044446@mail.emea.novell.com>
In-Reply-To: <54575E890200007800044446@mail.emea.novell.com>
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5900877013486113007=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

On 03.11.2014 10:52, Jan Beulich wrote:
>>>> On 03.11.14 at 10:45, <stefan.bader@canonical.com> wrote:
>> I see the message from the subject on my Intel box whenever a guest (i=
irc=20
>> even
>> dom0) starts up. It is not fatal and everything seems ok. I am just cu=
rious
>> about what might trigger this. The addresses look to be inside the=20
>> hypervisor
>> code. I was wondering whether there is a simple way to figure out what=
 this
>> relates to (likely need to look at the objdump of the unstripped hv mo=
dule).
>>
>> Or has someone already looked into this and knows what likely is the c=
ause?
>=20
> Often guest MSR accesses cause this. addr2line on the corresponding
> xen-syms should tell you.
>=20
> Jan
>=20
Ah, yes. There are usually messages about MSR access as well. Thanks for =
the
pointer about addr2line. I'll try that.

-Stefan


--Cgs3lHdR0ptlopGLbdUgrwHtS4hAWlovr
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

iQIcBAEBCgAGBQJUV1JSAAoJEOhnXe7L7s6jqjsP/2lFUnP7BUN6E8N5G9Ir8217
tMmlWDWwen84QUrPb9HtZOb/xpbkD1P5ArpzWjThaLCSx9MNFj8qzn9+x07SGIeP
fKli3mTL9acMSPhTud7SADhZ15tcqFoch28vvWZmRnmbZC5P+1Bc8Gbkr+NPfadb
LJibeUoANzkGN7xHGUwAZQj0NmcqBFqItw5Y4zkaLHkBmYTlw4w1cowJmRG2SV/w
7A4YJeRKkXK44sGAXRmRCurh/RVsn6ybsYVX6LgHnTiyJt4So6tvnd+w3QKV50pg
HQO/B9g20IQW4uawuHMjMD7S2X+uEJoIoNwN9MBhmvf5efYMVW77paXKXWeq+f1T
DczxUUVjVpUPypdJuUy2T8LjIb7VR4OFeYVqOlk5jQigOzOaQhK4HoBifumJrjZG
O3yuq/pMyOD/TSQiJQYPBj7cA5TtRIARBgeFDD+/HS0PuuK6ejD5mrRiEWakIjEx
N0/MsdApsI2MFiEQwxnxSTJIwXVShY1kJNdkP+1KaAwc5fLZeCD0W1QfpY6a2Yga
TcieWnCWUUrQ4nys8WzQRCMgECfX88+G7eeEkCO99VUJyNgxciqg46zZUqE/4LBk
dqTWDBVdJ6n2nq25QmtWUc0BzMs9TtRMUMtrvELYVuUiVbXOplr2NCwyCcxBnV1a
NARwz5Un+t442VBElLzC
=7Zps
-----END PGP SIGNATURE-----

--Cgs3lHdR0ptlopGLbdUgrwHtS4hAWlovr--


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

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

--===============5900877013486113007==--


From xen-devel-bounces@lists.xen.org Mon Nov 03 10:00:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlERW-0006tO-Lx; Mon, 03 Nov 2014 10:00:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XlERU-0006t2-UF
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:00:57 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	DF/45-02559-85257545; Mon, 03 Nov 2014 10:00:56 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415008855!12147848!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17189 invoked from network); 3 Nov 2014 10:00:55 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 10:00:55 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XlERR-0000pp-7H; Mon, 03 Nov 2014 10:00:53 +0000
Message-ID: <54575252.4060408@canonical.com>
Date: Mon, 03 Nov 2014 11:00:50 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54574EA0.5070101@canonical.com>
	<54575E890200007800044446@mail.emea.novell.com>
In-Reply-To: <54575E890200007800044446@mail.emea.novell.com>
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5900877013486113007=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

On 03.11.2014 10:52, Jan Beulich wrote:
>>>> On 03.11.14 at 10:45, <stefan.bader@canonical.com> wrote:
>> I see the message from the subject on my Intel box whenever a guest (i=
irc=20
>> even
>> dom0) starts up. It is not fatal and everything seems ok. I am just cu=
rious
>> about what might trigger this. The addresses look to be inside the=20
>> hypervisor
>> code. I was wondering whether there is a simple way to figure out what=
 this
>> relates to (likely need to look at the objdump of the unstripped hv mo=
dule).
>>
>> Or has someone already looked into this and knows what likely is the c=
ause?
>=20
> Often guest MSR accesses cause this. addr2line on the corresponding
> xen-syms should tell you.
>=20
> Jan
>=20
Ah, yes. There are usually messages about MSR access as well. Thanks for =
the
pointer about addr2line. I'll try that.

-Stefan


--Cgs3lHdR0ptlopGLbdUgrwHtS4hAWlovr
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

iQIcBAEBCgAGBQJUV1JSAAoJEOhnXe7L7s6jqjsP/2lFUnP7BUN6E8N5G9Ir8217
tMmlWDWwen84QUrPb9HtZOb/xpbkD1P5ArpzWjThaLCSx9MNFj8qzn9+x07SGIeP
fKli3mTL9acMSPhTud7SADhZ15tcqFoch28vvWZmRnmbZC5P+1Bc8Gbkr+NPfadb
LJibeUoANzkGN7xHGUwAZQj0NmcqBFqItw5Y4zkaLHkBmYTlw4w1cowJmRG2SV/w
7A4YJeRKkXK44sGAXRmRCurh/RVsn6ybsYVX6LgHnTiyJt4So6tvnd+w3QKV50pg
HQO/B9g20IQW4uawuHMjMD7S2X+uEJoIoNwN9MBhmvf5efYMVW77paXKXWeq+f1T
DczxUUVjVpUPypdJuUy2T8LjIb7VR4OFeYVqOlk5jQigOzOaQhK4HoBifumJrjZG
O3yuq/pMyOD/TSQiJQYPBj7cA5TtRIARBgeFDD+/HS0PuuK6ejD5mrRiEWakIjEx
N0/MsdApsI2MFiEQwxnxSTJIwXVShY1kJNdkP+1KaAwc5fLZeCD0W1QfpY6a2Yga
TcieWnCWUUrQ4nys8WzQRCMgECfX88+G7eeEkCO99VUJyNgxciqg46zZUqE/4LBk
dqTWDBVdJ6n2nq25QmtWUc0BzMs9TtRMUMtrvELYVuUiVbXOplr2NCwyCcxBnV1a
NARwz5Un+t442VBElLzC
=7Zps
-----END PGP SIGNATURE-----

--Cgs3lHdR0ptlopGLbdUgrwHtS4hAWlovr--


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

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

--===============5900877013486113007==--


From xen-devel-bounces@lists.xen.org Mon Nov 03 10:02:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:02:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlESs-00076N-6g; Mon, 03 Nov 2014 10:02:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlESq-00075y-Gw
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:02:20 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	86/44-07724-BA257545; Mon, 03 Nov 2014 10:02:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415008939!11166387!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20788 invoked from network); 3 Nov 2014 10:02:19 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 10:02:19 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 10:02:18 +0000
Message-Id: <545760B60200007800044471@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 10:02:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
	<545750FA.9090001@intel.com>
In-Reply-To: <545750FA.9090001@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 17:45, Jan Beulich wrote:
>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
>>> On 2014/11/3 16:53, Jan Beulich wrote:
>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>>>>>> when we really need them.
>>>>>>>>>>
>>>>>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>>>>> include that header (making sure declaration and definition are and
>>>>>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>>>>>> (and certain other code system components) the consequences of
>>>>>>>>>> being lax are much more severe.
>>>>>>>>>
>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>>>>> '<xen/memory.h>,
>>>>>>>>>
>>>>>>>>> #include "util.h"
>>>>>>>>> ...
>>>>>>>>> #include <xen/memory.h>
>>>>>>>>>
>>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>>>>
>>>>>>>> Redefine? I said forward declare.
>>>>>>>
>>>>>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>>>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>>>>
>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>>>>
>>>>>> To me this looks very much like poor programming style, even if in
>>>>>> the context of hvmloader communicating information via global
>>>>>> variables rather than function arguments and return values is
>>>>>
>>>>> Do you mean you don't like a global variable? But it can be use to get
>>>>> RDM without more hypercall or function call in the context of hvmloader.
>>>>
>>>> This argument which you brought up before, and which we commented
>>>> on before, is pretty pointless. We don't really care much about doing
>>>> one or two more hypercalls from hvmloader, unless these would be
>>>> long-running ones.
>>>>
>>>
>>> Another benefit to use a global variable is that we wouldn't allocate
>>> xen_reserved_device_memory * N each time, and reduce some duplicated
>>> codes, unless you mean I should define that as static inside in local.
>>
>> Now this reason is indeed worth a consideration. How many times is
>> the data being needed/retrieved?
> 
> Currently there are two cases in tools/hvmloader, setup pci and build 
> e820 table. Each time, as you know we don't know how may entries we 
> should require, so we always allocate one instance then according to the 
> return value to allocate the proper instances to get that.

Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
a more "normal" interface.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:02:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:02:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlESs-00076N-6g; Mon, 03 Nov 2014 10:02:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlESq-00075y-Gw
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:02:20 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	86/44-07724-BA257545; Mon, 03 Nov 2014 10:02:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415008939!11166387!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20788 invoked from network); 3 Nov 2014 10:02:19 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 10:02:19 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 10:02:18 +0000
Message-Id: <545760B60200007800044471@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 10:02:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
	<545750FA.9090001@intel.com>
In-Reply-To: <545750FA.9090001@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 17:45, Jan Beulich wrote:
>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
>>> On 2014/11/3 16:53, Jan Beulich wrote:
>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>>>>>> when we really need them.
>>>>>>>>>>
>>>>>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>>>>> include that header (making sure declaration and definition are and
>>>>>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>>>>>> (and certain other code system components) the consequences of
>>>>>>>>>> being lax are much more severe.
>>>>>>>>>
>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>>>>> '<xen/memory.h>,
>>>>>>>>>
>>>>>>>>> #include "util.h"
>>>>>>>>> ...
>>>>>>>>> #include <xen/memory.h>
>>>>>>>>>
>>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>>>>
>>>>>>>> Redefine? I said forward declare.
>>>>>>>
>>>>>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>>>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>>>>
>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>>>>
>>>>>> To me this looks very much like poor programming style, even if in
>>>>>> the context of hvmloader communicating information via global
>>>>>> variables rather than function arguments and return values is
>>>>>
>>>>> Do you mean you don't like a global variable? But it can be use to get
>>>>> RDM without more hypercall or function call in the context of hvmloader.
>>>>
>>>> This argument which you brought up before, and which we commented
>>>> on before, is pretty pointless. We don't really care much about doing
>>>> one or two more hypercalls from hvmloader, unless these would be
>>>> long-running ones.
>>>>
>>>
>>> Another benefit to use a global variable is that we wouldn't allocate
>>> xen_reserved_device_memory * N each time, and reduce some duplicated
>>> codes, unless you mean I should define that as static inside in local.
>>
>> Now this reason is indeed worth a consideration. How many times is
>> the data being needed/retrieved?
> 
> Currently there are two cases in tools/hvmloader, setup pci and build 
> e820 table. Each time, as you know we don't know how may entries we 
> should require, so we always allocate one instance then according to the 
> return value to allocate the proper instances to get that.

Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
a more "normal" interface.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:03:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlETy-0007I3-NH; Mon, 03 Nov 2014 10:03:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlETx-0007Hc-Se
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:03:29 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	26/9B-09936-0F257545; Mon, 03 Nov 2014 10:03:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415009008!12336574!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12099 invoked from network); 3 Nov 2014 10:03:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 10:03:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 10:03:27 +0000
Message-Id: <545760FD0200007800044474@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 10:03:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
In-Reply-To: <54575013.50702@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>> #2 the error handling
>>>
>>> In an error case what should I do? Currently we still create these
>>> mapping as normal. This means these mfns will be valid so later we can't
>>> set them again then device can't be assigned as passthrough. I think
>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>
>> You should, with very few exceptions, not ignore errors (which
>> includes "handling" them by just logging a message. Instead, you
>> should propagate the error back up the call chain.
>>
> 
> Do you mean in your patch,
> 
> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
> +{
> +    const struct iommu_ops *ops = iommu_get_ops();
> +
> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
> +        return 0;
> +
> +    return ops->get_reserved_device_memory(func, ctxt);
> +}
> +
> 
> I shouldn't return that directly. Then instead, we should handle all 
> error scenarios here?

No. All error scenarios are already being handled here (by
propagating the error code to the caller).

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:03:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlETy-0007I3-NH; Mon, 03 Nov 2014 10:03:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlETx-0007Hc-Se
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:03:29 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	26/9B-09936-0F257545; Mon, 03 Nov 2014 10:03:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415009008!12336574!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12099 invoked from network); 3 Nov 2014 10:03:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 10:03:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 10:03:27 +0000
Message-Id: <545760FD0200007800044474@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 10:03:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
In-Reply-To: <54575013.50702@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>> #2 the error handling
>>>
>>> In an error case what should I do? Currently we still create these
>>> mapping as normal. This means these mfns will be valid so later we can't
>>> set them again then device can't be assigned as passthrough. I think
>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>
>> You should, with very few exceptions, not ignore errors (which
>> includes "handling" them by just logging a message. Instead, you
>> should propagate the error back up the call chain.
>>
> 
> Do you mean in your patch,
> 
> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
> +{
> +    const struct iommu_ops *ops = iommu_get_ops();
> +
> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
> +        return 0;
> +
> +    return ops->get_reserved_device_memory(func, ctxt);
> +}
> +
> 
> I shouldn't return that directly. Then instead, we should handle all 
> error scenarios here?

No. All error scenarios are already being handled here (by
propagating the error code to the caller).

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:05:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:05:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEVc-0007W2-9P; Mon, 03 Nov 2014 10:05:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlEVa-0007Vo-JE
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:05:10 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	FD/C5-02699-55357545; Mon, 03 Nov 2014 10:05:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415009107!6755753!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18832 invoked from network); 3 Nov 2014 10:05:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:05:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="188829298"
Message-ID: <1415009105.9994.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <seabios@seabios.org>
Date: Mon, 3 Nov 2014 10:05:05 +0000
In-Reply-To: <1415008770.9994.6.camel@citrix.com>
References: <1415008770.9994.6.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression booting winxp under Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:

> I've not investigated more thoroughly yes, just posting in case
> something obvious leaps out at someone. The automated test is currently
> bisecting the issue, once it is done I'll let you know the result.

If I'd read a bit further through my Monday morning INBOX I'd have
found:
        http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
        
which indicates that the bisector has fingered:

  commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Author: Kevin O'Connor <kevin@xxxxxxxxxxxx>
  Date:   Tue Oct 21 14:34:06 2014 -0400
  
      Do full BREGS backup/restore for pmm, pnp, and irqentry_extrastack
      
      Although these entry points only require backup and restore of the
      registers that the C code clobbers, there is no harm in backing up
      some additional registers.  This allows the BREGS macros to be used
      which makes the code a little more readable.
      
      Signed-off-by: Kevin O'Connor <kevin@xxxxxxxxxxxx>

Ian.

> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg03543.html
> [2] http://lists.xen.org/archives/html/xen-devel/2014-10/msg01993.html
> [3] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/test-amd64-i386-xl-qemuu-winxpsp3-vcpus1/info.html
> [4] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 03 10:05:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:05:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEVc-0007W2-9P; Mon, 03 Nov 2014 10:05:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlEVa-0007Vo-JE
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:05:10 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	FD/C5-02699-55357545; Mon, 03 Nov 2014 10:05:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415009107!6755753!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18832 invoked from network); 3 Nov 2014 10:05:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:05:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208";a="188829298"
Message-ID: <1415009105.9994.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <seabios@seabios.org>
Date: Mon, 3 Nov 2014 10:05:05 +0000
In-Reply-To: <1415008770.9994.6.camel@citrix.com>
References: <1415008770.9994.6.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression booting winxp under Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:

> I've not investigated more thoroughly yes, just posting in case
> something obvious leaps out at someone. The automated test is currently
> bisecting the issue, once it is done I'll let you know the result.

If I'd read a bit further through my Monday morning INBOX I'd have
found:
        http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
        
which indicates that the bisector has fingered:

  commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Author: Kevin O'Connor <kevin@xxxxxxxxxxxx>
  Date:   Tue Oct 21 14:34:06 2014 -0400
  
      Do full BREGS backup/restore for pmm, pnp, and irqentry_extrastack
      
      Although these entry points only require backup and restore of the
      registers that the C code clobbers, there is no harm in backing up
      some additional registers.  This allows the BREGS macros to be used
      which makes the code a little more readable.
      
      Signed-off-by: Kevin O'Connor <kevin@xxxxxxxxxxxx>

Ian.

> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg03543.html
> [2] http://lists.xen.org/archives/html/xen-devel/2014-10/msg01993.html
> [3] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/test-amd64-i386-xl-qemuu-winxpsp3-vcpus1/info.html
> [4] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 03 10:05:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEVt-0007Yc-Mb; Mon, 03 Nov 2014 10:05:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1XlEVr-0007YN-MM
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:05:27 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	06/C5-27623-66357545; Mon, 03 Nov 2014 10:05:26 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415009124!11267454!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32624 invoked from network); 3 Nov 2014 10:05:26 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-3.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 10:05:26 -0000
X-IronPort-AV: E=Sophos;i="5.04,839,1406563200"; d="scan'208";a="42753623"
Received: from localhost (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 03 Nov 2014 18:02:13 +0800
Received: from G08CNEXCHPEKD03.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sA3A5DuQ016134;
	Mon, 3 Nov 2014 18:05:13 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 3 Nov 2014 18:05:24 +0800
Message-ID: <545753CA.9080804@cn.fujitsu.com>
Date: Mon, 3 Nov 2014 18:07:06 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <1413252845-23433-1-git-send-email-wency@cn.fujitsu.com>	<21565.17844.525542.420665@mariner.uk.xensource.com>	<543DC859.1080207@cn.fujitsu.com>
	<CAFLBxZZ+EpHNkcQ2NYC3vspZg-v7uKQsuKX=hW=0KWJXuvDQvA@mail.gmail.com>
	<54507FFB.6090800@cn.fujitsu.com> <545751B0.4010503@eu.citrix.com>
In-Reply-To: <545751B0.4010503@eu.citrix.com>
X-Originating-IP: [10.167.226.91]
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 00/17] blktap2 related bugfix patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/2014 05:58 PM, George Dunlap wrote:
> On 10/29/2014 05:49 AM, Wen Congyang wrote:
>> On 10/20/2014 10:25 PM, George Dunlap wrote:
>>> On Wed, Oct 15, 2014 at 2:05 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
>>>> On 10/14/2014 11:48 PM, Ian Jackson wrote:
>>>>> Wen Congyang writes ("[PATCH 00/17] blktap2 related bugfix patches"):
>>>>>> These bugs are found when we implement COLO, or rebase
>>>>>> COLO to upstream xen. They are independent patches, so
>>>>>> post them in separate series.
>>>>> blktap2 is unmaintained AFAICT.
>>>>>
>>>>> In the last year there has been only one commit which shows evidence
>>>>> of someone caring even slightly about tools/blktap2/.  The last
>>>>> substantial attention was in March 2013.
>>>>>
>>>>> (I'm disregarding commits which touch tools/blktap2/ to fix up compile
>>>>> problems with new compilers, sort out build system and file
>>>>> rearrangements, etc.)
>>>>>
>>>>> The file you are touching in your 01/17 was last edited (by anyone, at
>>>>> all) in January 2010.
>>>>>
>>>>> Under the circumstances, we should probably take all these changes
>>>>> without looking for anyone to ack them.
>>>>>
>>>>> Perhaps you would like to become the maintainers of blktap2 ? :-)
>>>> Hmm, I don't have any knowledge about disk format, but blktap2 have
>>>> such codes(For example: block-vhd.c, block-qcow.c...). I think I can
>>>> maintain the rest codes.
>>> Congyang, were you aware that XenServer has a fork of blktap is
>>> actually still under active development and maintainership outside of
>>> the main Xen tree?
>>>
>>> git://github.com/xen-org/blktap.git
>>>
>>> Both CentOS and Fedora are actually using snapshots of the "blktap2"
>>> branch in that tree for their Xen RPMs.  (I'm sure CentOS is, I
>>> believe Fedora is.)  It's not unlikely that the bugs you're fixing
>>> here have already been fixed in the XenServer fork.
>> I have another question:
>> Why we don't merge the "blktap2' branch into xen upstream periodically?
> 
> I take it you've found blktap "2.5" useful? :-)
> 
> I've been meaning to write an e-mail about this.
> 
> The basic reason is that it's normally up to the people doing the development to submit changes upstream.  Some years ago XenServer forked the blktap2 codebase but got behind in upstreaming things; at this point there are far too many changes to simply push them upstream.  Furthermore, even XenServer isn't 100% sure what they're going to do in the future; as of a year ago they were planning to get rid of blktap entirely in favor of another solution.
> 
> One of the ideas I'm going to discuss in my e-mail is the idea of treating blktap2.5 (and/or blktap3) as an external upstream project, similar to the way that we treat qemu, seabios, ipxe, and ovmf. That would have a similar effect to what you describe.

I agree with this. Currently, we have blktap2 and blktap2.5. I don't know my work should be for which
version...

Thanks
Wen Congyang

> 
>  -George
> .
> 


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:05:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEVt-0007Yc-Mb; Mon, 03 Nov 2014 10:05:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1XlEVr-0007YN-MM
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:05:27 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	06/C5-27623-66357545; Mon, 03 Nov 2014 10:05:26 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415009124!11267454!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32624 invoked from network); 3 Nov 2014 10:05:26 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-3.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 10:05:26 -0000
X-IronPort-AV: E=Sophos;i="5.04,839,1406563200"; d="scan'208";a="42753623"
Received: from localhost (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 03 Nov 2014 18:02:13 +0800
Received: from G08CNEXCHPEKD03.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sA3A5DuQ016134;
	Mon, 3 Nov 2014 18:05:13 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 3 Nov 2014 18:05:24 +0800
Message-ID: <545753CA.9080804@cn.fujitsu.com>
Date: Mon, 3 Nov 2014 18:07:06 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <1413252845-23433-1-git-send-email-wency@cn.fujitsu.com>	<21565.17844.525542.420665@mariner.uk.xensource.com>	<543DC859.1080207@cn.fujitsu.com>
	<CAFLBxZZ+EpHNkcQ2NYC3vspZg-v7uKQsuKX=hW=0KWJXuvDQvA@mail.gmail.com>
	<54507FFB.6090800@cn.fujitsu.com> <545751B0.4010503@eu.citrix.com>
In-Reply-To: <545751B0.4010503@eu.citrix.com>
X-Originating-IP: [10.167.226.91]
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 00/17] blktap2 related bugfix patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/2014 05:58 PM, George Dunlap wrote:
> On 10/29/2014 05:49 AM, Wen Congyang wrote:
>> On 10/20/2014 10:25 PM, George Dunlap wrote:
>>> On Wed, Oct 15, 2014 at 2:05 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
>>>> On 10/14/2014 11:48 PM, Ian Jackson wrote:
>>>>> Wen Congyang writes ("[PATCH 00/17] blktap2 related bugfix patches"):
>>>>>> These bugs are found when we implement COLO, or rebase
>>>>>> COLO to upstream xen. They are independent patches, so
>>>>>> post them in separate series.
>>>>> blktap2 is unmaintained AFAICT.
>>>>>
>>>>> In the last year there has been only one commit which shows evidence
>>>>> of someone caring even slightly about tools/blktap2/.  The last
>>>>> substantial attention was in March 2013.
>>>>>
>>>>> (I'm disregarding commits which touch tools/blktap2/ to fix up compile
>>>>> problems with new compilers, sort out build system and file
>>>>> rearrangements, etc.)
>>>>>
>>>>> The file you are touching in your 01/17 was last edited (by anyone, at
>>>>> all) in January 2010.
>>>>>
>>>>> Under the circumstances, we should probably take all these changes
>>>>> without looking for anyone to ack them.
>>>>>
>>>>> Perhaps you would like to become the maintainers of blktap2 ? :-)
>>>> Hmm, I don't have any knowledge about disk format, but blktap2 have
>>>> such codes(For example: block-vhd.c, block-qcow.c...). I think I can
>>>> maintain the rest codes.
>>> Congyang, were you aware that XenServer has a fork of blktap is
>>> actually still under active development and maintainership outside of
>>> the main Xen tree?
>>>
>>> git://github.com/xen-org/blktap.git
>>>
>>> Both CentOS and Fedora are actually using snapshots of the "blktap2"
>>> branch in that tree for their Xen RPMs.  (I'm sure CentOS is, I
>>> believe Fedora is.)  It's not unlikely that the bugs you're fixing
>>> here have already been fixed in the XenServer fork.
>> I have another question:
>> Why we don't merge the "blktap2' branch into xen upstream periodically?
> 
> I take it you've found blktap "2.5" useful? :-)
> 
> I've been meaning to write an e-mail about this.
> 
> The basic reason is that it's normally up to the people doing the development to submit changes upstream.  Some years ago XenServer forked the blktap2 codebase but got behind in upstreaming things; at this point there are far too many changes to simply push them upstream.  Furthermore, even XenServer isn't 100% sure what they're going to do in the future; as of a year ago they were planning to get rid of blktap entirely in favor of another solution.
> 
> One of the ideas I'm going to discuss in my e-mail is the idea of treating blktap2.5 (and/or blktap3) as an external upstream project, similar to the way that we treat qemu, seabios, ipxe, and ovmf. That would have a similar effect to what you describe.

I agree with this. Currently, we have blktap2 and blktap2.5. I don't know my work should be for which
version...

Thanks
Wen Congyang

> 
>  -George
> .
> 


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:05:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEWE-0007dx-3m; Mon, 03 Nov 2014 10:05:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlEWC-0007dU-JJ
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:05:48 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	3D/38-31453-B7357545; Mon, 03 Nov 2014 10:05:47 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415009145!3241470!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10664 invoked from network); 3 Nov 2014 10:05:46 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-3.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 10:05:46 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 03 Nov 2014 01:59:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="615923412"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 02:05:39 -0800
Message-ID: <54575372.7020406@intel.com>
Date: Mon, 03 Nov 2014 18:05:38 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
	<54575C3E020000780004440F@mail.emea.novell.com>
In-Reply-To: <54575C3E020000780004440F@mail.emea.novell.com>
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 17:43, Jan Beulich wrote:
>>>> On 03.11.14 at 10:00, <tiejun.chen@intel.com> wrote:
>> --- a/tools/firmware/hvmloader/Makefile
>> +++ b/tools/firmware/hvmloader/Makefile
>> @@ -84,9 +84,12 @@ ROMS += $(SEABIOS_ROM)
>>   endif
>>
>>   .PHONY: all
>> -all: subdirs-all
>> +all: subdirs-all .dir
>
> Considering uses going forward, I think subdirs-all should depend on
> .dir (which is being misnamed anyway, presumably due to blindly
> taking what is in tools/include/Makefile, where a directory _is_ being
> created). Considering that it's an individual file, the file name would

You're right.

> seem quite right to be used as dependency here.

So what about this?

.PHONY: all
all: subdirs-all errno
     $(MAKE) hvmloader

errno:
     ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:05:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEWE-0007dx-3m; Mon, 03 Nov 2014 10:05:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlEWC-0007dU-JJ
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:05:48 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	3D/38-31453-B7357545; Mon, 03 Nov 2014 10:05:47 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415009145!3241470!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10664 invoked from network); 3 Nov 2014 10:05:46 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-3.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 10:05:46 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 03 Nov 2014 01:59:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,305,1413270000"; d="scan'208";a="615923412"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 02:05:39 -0800
Message-ID: <54575372.7020406@intel.com>
Date: Mon, 03 Nov 2014 18:05:38 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
	<54575C3E020000780004440F@mail.emea.novell.com>
In-Reply-To: <54575C3E020000780004440F@mail.emea.novell.com>
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 17:43, Jan Beulich wrote:
>>>> On 03.11.14 at 10:00, <tiejun.chen@intel.com> wrote:
>> --- a/tools/firmware/hvmloader/Makefile
>> +++ b/tools/firmware/hvmloader/Makefile
>> @@ -84,9 +84,12 @@ ROMS += $(SEABIOS_ROM)
>>   endif
>>
>>   .PHONY: all
>> -all: subdirs-all
>> +all: subdirs-all .dir
>
> Considering uses going forward, I think subdirs-all should depend on
> .dir (which is being misnamed anyway, presumably due to blindly
> taking what is in tools/include/Makefile, where a directory _is_ being
> created). Considering that it's an individual file, the file name would

You're right.

> seem quite right to be used as dependency here.

So what about this?

.PHONY: all
all: subdirs-all errno
     $(MAKE) hvmloader

errno:
     ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEgt-0008E9-Lo; Mon, 03 Nov 2014 10:16: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 1XlEgs-0008E4-HH
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 10:16:50 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	79/60-27584-11657545; Mon, 03 Nov 2014 10:16:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415009809!10810600!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9484 invoked from network); 3 Nov 2014 10:16:49 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 10:16:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 10:16:48 +0000
Message-Id: <5457641C02000078000444BA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 10:16:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-31315-mainreport@xen.org>
In-Reply-To: <osstest-31315-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 18:43, <Ian.Jackson@eu.citrix.com> wrote:
> flight 31315 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31315/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 31285

Looking at fire-frog's serial log I see that booting started 09:34:37
and debug output was forced at 09:35:47; the login prompt
appeared at 09:36:11. The gap between the NTP server getting
started and the login prompt appearing seems pretty large, but
is that really an indication of something being wrong in the being
tested software? The 3 commits under test don't really look like
being candidate for a boot time (performance) regression.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEgt-0008E9-Lo; Mon, 03 Nov 2014 10:16: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 1XlEgs-0008E4-HH
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 10:16:50 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	79/60-27584-11657545; Mon, 03 Nov 2014 10:16:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415009809!10810600!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9484 invoked from network); 3 Nov 2014 10:16:49 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 10:16:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 10:16:48 +0000
Message-Id: <5457641C02000078000444BA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 10:16:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-31315-mainreport@xen.org>
In-Reply-To: <osstest-31315-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 18:43, <Ian.Jackson@eu.citrix.com> wrote:
> flight 31315 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31315/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 31285

Looking at fire-frog's serial log I see that booting started 09:34:37
and debug output was forced at 09:35:47; the login prompt
appeared at 09:36:11. The gap between the NTP server getting
started and the login prompt appearing seems pretty large, but
is that really an indication of something being wrong in the being
tested software? The 3 commits under test don't really look like
being candidate for a boot time (performance) regression.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlEhq-0008IO-Fq; Mon, 03 Nov 2014 10:17:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdN-00086p-2Q
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5E/39-09936-83557545; Mon, 03 Nov 2014 10:13:12 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415009587!12278067!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19509 invoked from network); 3 Nov 2014 10:13:11 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:11 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38046; Mon, 03 Nov 2014 18:13:05 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:12:51 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:53 +0000
Message-ID: <1415009522-6344-2-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 01/10] xen/arm: Implement hip04-d01 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

Add this new platform to Xen.
This platform require specific code to initialize CPUs.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/hip04.c  | 258 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 259 insertions(+)
 create mode 100644 xen/arch/arm/platforms/hip04.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8f47c16..d0b2d99 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_64) += seattle.o
+obj-$(CONFIG_ARM_32) += hip04.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
new file mode 100644
index 0000000..bf38c23
--- /dev/null
+++ b/xen/arch/arm/platforms/hip04.c
@@ -0,0 +1,258 @@
+/*
+ * xen/arch/arm/platforms/hip04.c
+ *
+ * HiSilicon HIP-04 D01 board
+ *
+ * Copyright (c) 2012-2013 Hisilicon Ltd.
+ * Copyright (c) 2012-2013 Linaro Ltd.
+ * Copyright (c) 2014 Huawei Tech. Co., Ltd.
+ *
+ * Author: Frediano Ziglio <frediano.ziglio@huawei.com>
+ *
+ * Original code from Linux kernel arch/arm/mach-hisi/hisilicon.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/platform.h>
+#include <xen/mm.h>
+#include <xen/vmap.h>
+#include <asm/io.h>
+#include <asm/gic.h>
+
+#define CORE_RESET_BIT(x)            (1 << x)
+#define NEON_RESET_BIT(x)            (1 << (x + 4))
+#define CORE_DEBUG_RESET_BIT(x)      (1 << (x + 9))
+#define CLUSTER_L2_RESET_BIT         (1 << 8)
+#define CLUSTER_DEBUG_RESET_BIT      (1 << 13)
+
+#define CLUSTER_L2_RESET_STATUS      (1 << 8)
+#define CLUSTER_DEBUG_RESET_STATUS   (1 << 13)
+
+#define SC_CPU_RESET_DREQ(x)         (0x524 + (x << 3))    /* unreset */
+#define SC_CPU_RESET_STATUS(x)       (0x1520 + (x << 3))
+
+#define FAB_SF_MODE                  0x0c
+
+#define HIP04_MAX_CLUSTERS           4
+#define HIP04_MAX_CPUS_PER_CLUSTER   4
+
+struct hip04_secondary_cpu_data {
+    u32 bootwrapper_phys;
+    u32 bootwrapper_size;
+    u32 bootwrapper_magic;
+    u32 relocation_entry;
+    u32 relocation_size;
+};
+
+static void __iomem *relocation, *sysctrl, *fabric;
+static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
+static struct hip04_secondary_cpu_data hip04_boot;
+
+static void hip04_reset(void)
+{
+    /* TODO */
+}
+
+static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
+{
+    unsigned long data;
+
+    if (!fabric)
+        return;
+    data = readl_relaxed(fabric + FAB_SF_MODE);
+    if (on)
+        data |= 1 << cluster;
+    else
+        data &= ~(1 << cluster);
+    writel_relaxed(data, fabric + FAB_SF_MODE);
+    while (1) {
+        if (data == readl_relaxed(fabric + FAB_SF_MODE))
+            break;
+    }
+}
+
+static bool __init hip04_cpu_table_init(void)
+{
+    unsigned int mpidr, cpu, cluster;
+
+    mpidr = cpu_logical_map(smp_processor_id());
+    cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+    cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+    if (cluster >= HIP04_MAX_CLUSTERS ||
+        cpu >= HIP04_MAX_CPUS_PER_CLUSTER) {
+        printk(XENLOG_ERR "%s: boot CPU is out of bound!\n", __func__);
+        return false;
+    }
+    hip04_set_snoop_filter(cluster, 1);
+    hip04_cpu_table[cluster][cpu] = 1;
+    return true;
+}
+
+static bool hip04_cluster_down(unsigned int cluster)
+{
+    int i;
+
+    for (i = 0; i < HIP04_MAX_CPUS_PER_CLUSTER; i++)
+        if (hip04_cpu_table[cluster][i])
+            return false;
+    return true;
+}
+
+static void hip04_cluster_up(unsigned int cluster)
+{
+    unsigned long data, mask;
+
+    if ( hip04_cluster_down(cluster) ) {
+        data = CLUSTER_L2_RESET_BIT | CLUSTER_DEBUG_RESET_BIT;
+        writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+        do {
+            mask = CLUSTER_L2_RESET_STATUS | \
+                   CLUSTER_DEBUG_RESET_STATUS;
+            data = readl_relaxed(sysctrl + \
+                         SC_CPU_RESET_STATUS(cluster));
+        } while (data & mask);
+        hip04_set_snoop_filter(cluster, 1);
+    }
+}
+
+static int __init hip04_smp_init(void)
+{
+    struct dt_device_node *np, *np_fab;
+    const char *msg;
+    u64 addr, size;
+
+    np = dt_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
+    msg = "hisilicon,sysctrl missing in DT\n";
+    if ( !np )
+        goto err;
+
+    np_fab = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-fabric");
+    msg = "hisilicon,hip04-fabric missing in DT\n";
+    if ( !np_fab )
+        goto err;
+
+    msg = "failed to get bootwrapper-phys\n";
+    if ( !dt_property_read_u32(np, "bootwrapper-phys",
+                               &hip04_boot.bootwrapper_phys) )
+        goto err;
+
+    msg = "failed to get bootwrapper-size\n";
+    if ( !dt_property_read_u32(np, "bootwrapper-size",
+                               &hip04_boot.bootwrapper_size) )
+        goto err;
+
+    msg = "failed to get bootwrapper-magic\n";
+    if ( !dt_property_read_u32(np, "bootwrapper-magic",
+                               &hip04_boot.bootwrapper_magic) )
+        goto err;
+
+    msg = "failed to get relocation-entry\n";
+    if ( !dt_property_read_u32(np, "relocation-entry",
+                               &hip04_boot.relocation_entry) )
+        goto err;
+
+    msg = "failed to get relocation-size\n";
+    if ( !dt_property_read_u32(np, "relocation-size",
+                 &hip04_boot.relocation_size) )
+        goto err;
+
+    relocation = ioremap_nocache(hip04_boot.relocation_entry,
+                                 hip04_boot.relocation_size);
+    msg = "failed to map relocation space\n";
+    if ( !relocation )
+        goto err;
+
+    msg = "Error in \"hisilicon,sysctrl\"\n";
+    if ( dt_device_get_address(np, 0, &addr, &size) )
+        goto err;
+    sysctrl = ioremap_nocache(addr, size);
+    if ( !sysctrl )
+        goto err;
+
+    msg = "Error in \"hisilicon,hip04-fabric\"\n";
+    if ( dt_device_get_address(np_fab, 0, &addr, &size) )
+        goto err;
+    fabric = ioremap_nocache(addr, size);
+    if ( !fabric )
+        goto err;
+
+    msg = "Error initializing SMP table\n";
+    if ( !hip04_cpu_table_init() )
+        goto err;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    return 0;
+
+err:
+    printk("%s", msg);
+    return -ENXIO;
+}
+
+static int hip04_cpu_up(int cpu)
+{
+    unsigned int cluster = cpu / 4;
+    unsigned long data;
+    cpu %= 4;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    hip04_cluster_up(cluster);
+
+    hip04_cpu_table[cluster][cpu]++;
+
+    data = CORE_RESET_BIT(cpu) | NEON_RESET_BIT(cpu) | \
+           CORE_DEBUG_RESET_BIT(cpu);
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+
+    return cpu_up_send_sgi(cpu);
+}
+
+
+static const char * const hip04_dt_compat[] __initconst =
+{
+    "hisilicon,hip04-d01",
+    NULL
+};
+
+static const struct dt_device_match hip04_blacklist_dev[] __initconst =
+{
+    /* Hardware power management */
+    DT_MATCH_COMPATIBLE("hisilicon,sysctrl"),
+    DT_MATCH_COMPATIBLE("hisilicon,hip04-fabric"),
+    { /* sentinel */ },
+};
+
+
+PLATFORM_START(hip04, "HISILICON HIP04")
+    .compatible = hip04_dt_compat,
+    .smp_init = hip04_smp_init,
+    .cpu_up = hip04_cpu_up,
+    .reset = hip04_reset,
+    .blacklist_dev = hip04_blacklist_dev,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlEhq-0008ID-4J; Mon, 03 Nov 2014 10:17:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdF-00085q-Mu
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:05 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D9/0F-24532-13557545; Mon, 03 Nov 2014 10:13:05 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415009580!11771468!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16109 invoked from network); 3 Nov 2014 10:13:04 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:04 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWO17412; Mon, 03 Nov 2014 18:12:59 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:12:47 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:52 +0000
Message-ID: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020203.5457552C.0068, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a91f6ebb7e165ba228d50687a5c561c3
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] xen/arm: Add support for Huawei hip04-d01 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details).

The patch "xen/arm: Move vGIC registers on Hip04 platform" is actually a workaround and should have in the future a proper implementation in Xen (unfortunately not straightforward to do it).




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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlEhq-0008IO-Fq; Mon, 03 Nov 2014 10:17:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdN-00086p-2Q
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5E/39-09936-83557545; Mon, 03 Nov 2014 10:13:12 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415009587!12278067!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19509 invoked from network); 3 Nov 2014 10:13:11 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:11 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38046; Mon, 03 Nov 2014 18:13:05 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:12:51 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:53 +0000
Message-ID: <1415009522-6344-2-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 01/10] xen/arm: Implement hip04-d01 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

Add this new platform to Xen.
This platform require specific code to initialize CPUs.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/hip04.c  | 258 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 259 insertions(+)
 create mode 100644 xen/arch/arm/platforms/hip04.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8f47c16..d0b2d99 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_64) += seattle.o
+obj-$(CONFIG_ARM_32) += hip04.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
new file mode 100644
index 0000000..bf38c23
--- /dev/null
+++ b/xen/arch/arm/platforms/hip04.c
@@ -0,0 +1,258 @@
+/*
+ * xen/arch/arm/platforms/hip04.c
+ *
+ * HiSilicon HIP-04 D01 board
+ *
+ * Copyright (c) 2012-2013 Hisilicon Ltd.
+ * Copyright (c) 2012-2013 Linaro Ltd.
+ * Copyright (c) 2014 Huawei Tech. Co., Ltd.
+ *
+ * Author: Frediano Ziglio <frediano.ziglio@huawei.com>
+ *
+ * Original code from Linux kernel arch/arm/mach-hisi/hisilicon.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/platform.h>
+#include <xen/mm.h>
+#include <xen/vmap.h>
+#include <asm/io.h>
+#include <asm/gic.h>
+
+#define CORE_RESET_BIT(x)            (1 << x)
+#define NEON_RESET_BIT(x)            (1 << (x + 4))
+#define CORE_DEBUG_RESET_BIT(x)      (1 << (x + 9))
+#define CLUSTER_L2_RESET_BIT         (1 << 8)
+#define CLUSTER_DEBUG_RESET_BIT      (1 << 13)
+
+#define CLUSTER_L2_RESET_STATUS      (1 << 8)
+#define CLUSTER_DEBUG_RESET_STATUS   (1 << 13)
+
+#define SC_CPU_RESET_DREQ(x)         (0x524 + (x << 3))    /* unreset */
+#define SC_CPU_RESET_STATUS(x)       (0x1520 + (x << 3))
+
+#define FAB_SF_MODE                  0x0c
+
+#define HIP04_MAX_CLUSTERS           4
+#define HIP04_MAX_CPUS_PER_CLUSTER   4
+
+struct hip04_secondary_cpu_data {
+    u32 bootwrapper_phys;
+    u32 bootwrapper_size;
+    u32 bootwrapper_magic;
+    u32 relocation_entry;
+    u32 relocation_size;
+};
+
+static void __iomem *relocation, *sysctrl, *fabric;
+static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
+static struct hip04_secondary_cpu_data hip04_boot;
+
+static void hip04_reset(void)
+{
+    /* TODO */
+}
+
+static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
+{
+    unsigned long data;
+
+    if (!fabric)
+        return;
+    data = readl_relaxed(fabric + FAB_SF_MODE);
+    if (on)
+        data |= 1 << cluster;
+    else
+        data &= ~(1 << cluster);
+    writel_relaxed(data, fabric + FAB_SF_MODE);
+    while (1) {
+        if (data == readl_relaxed(fabric + FAB_SF_MODE))
+            break;
+    }
+}
+
+static bool __init hip04_cpu_table_init(void)
+{
+    unsigned int mpidr, cpu, cluster;
+
+    mpidr = cpu_logical_map(smp_processor_id());
+    cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+    cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+    if (cluster >= HIP04_MAX_CLUSTERS ||
+        cpu >= HIP04_MAX_CPUS_PER_CLUSTER) {
+        printk(XENLOG_ERR "%s: boot CPU is out of bound!\n", __func__);
+        return false;
+    }
+    hip04_set_snoop_filter(cluster, 1);
+    hip04_cpu_table[cluster][cpu] = 1;
+    return true;
+}
+
+static bool hip04_cluster_down(unsigned int cluster)
+{
+    int i;
+
+    for (i = 0; i < HIP04_MAX_CPUS_PER_CLUSTER; i++)
+        if (hip04_cpu_table[cluster][i])
+            return false;
+    return true;
+}
+
+static void hip04_cluster_up(unsigned int cluster)
+{
+    unsigned long data, mask;
+
+    if ( hip04_cluster_down(cluster) ) {
+        data = CLUSTER_L2_RESET_BIT | CLUSTER_DEBUG_RESET_BIT;
+        writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+        do {
+            mask = CLUSTER_L2_RESET_STATUS | \
+                   CLUSTER_DEBUG_RESET_STATUS;
+            data = readl_relaxed(sysctrl + \
+                         SC_CPU_RESET_STATUS(cluster));
+        } while (data & mask);
+        hip04_set_snoop_filter(cluster, 1);
+    }
+}
+
+static int __init hip04_smp_init(void)
+{
+    struct dt_device_node *np, *np_fab;
+    const char *msg;
+    u64 addr, size;
+
+    np = dt_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
+    msg = "hisilicon,sysctrl missing in DT\n";
+    if ( !np )
+        goto err;
+
+    np_fab = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-fabric");
+    msg = "hisilicon,hip04-fabric missing in DT\n";
+    if ( !np_fab )
+        goto err;
+
+    msg = "failed to get bootwrapper-phys\n";
+    if ( !dt_property_read_u32(np, "bootwrapper-phys",
+                               &hip04_boot.bootwrapper_phys) )
+        goto err;
+
+    msg = "failed to get bootwrapper-size\n";
+    if ( !dt_property_read_u32(np, "bootwrapper-size",
+                               &hip04_boot.bootwrapper_size) )
+        goto err;
+
+    msg = "failed to get bootwrapper-magic\n";
+    if ( !dt_property_read_u32(np, "bootwrapper-magic",
+                               &hip04_boot.bootwrapper_magic) )
+        goto err;
+
+    msg = "failed to get relocation-entry\n";
+    if ( !dt_property_read_u32(np, "relocation-entry",
+                               &hip04_boot.relocation_entry) )
+        goto err;
+
+    msg = "failed to get relocation-size\n";
+    if ( !dt_property_read_u32(np, "relocation-size",
+                 &hip04_boot.relocation_size) )
+        goto err;
+
+    relocation = ioremap_nocache(hip04_boot.relocation_entry,
+                                 hip04_boot.relocation_size);
+    msg = "failed to map relocation space\n";
+    if ( !relocation )
+        goto err;
+
+    msg = "Error in \"hisilicon,sysctrl\"\n";
+    if ( dt_device_get_address(np, 0, &addr, &size) )
+        goto err;
+    sysctrl = ioremap_nocache(addr, size);
+    if ( !sysctrl )
+        goto err;
+
+    msg = "Error in \"hisilicon,hip04-fabric\"\n";
+    if ( dt_device_get_address(np_fab, 0, &addr, &size) )
+        goto err;
+    fabric = ioremap_nocache(addr, size);
+    if ( !fabric )
+        goto err;
+
+    msg = "Error initializing SMP table\n";
+    if ( !hip04_cpu_table_init() )
+        goto err;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    return 0;
+
+err:
+    printk("%s", msg);
+    return -ENXIO;
+}
+
+static int hip04_cpu_up(int cpu)
+{
+    unsigned int cluster = cpu / 4;
+    unsigned long data;
+    cpu %= 4;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    hip04_cluster_up(cluster);
+
+    hip04_cpu_table[cluster][cpu]++;
+
+    data = CORE_RESET_BIT(cpu) | NEON_RESET_BIT(cpu) | \
+           CORE_DEBUG_RESET_BIT(cpu);
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+
+    return cpu_up_send_sgi(cpu);
+}
+
+
+static const char * const hip04_dt_compat[] __initconst =
+{
+    "hisilicon,hip04-d01",
+    NULL
+};
+
+static const struct dt_device_match hip04_blacklist_dev[] __initconst =
+{
+    /* Hardware power management */
+    DT_MATCH_COMPATIBLE("hisilicon,sysctrl"),
+    DT_MATCH_COMPATIBLE("hisilicon,hip04-fabric"),
+    { /* sentinel */ },
+};
+
+
+PLATFORM_START(hip04, "HISILICON HIP04")
+    .compatible = hip04_dt_compat,
+    .smp_init = hip04_smp_init,
+    .cpu_up = hip04_cpu_up,
+    .reset = hip04_reset,
+    .blacklist_dev = hip04_blacklist_dev,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlEhq-0008ID-4J; Mon, 03 Nov 2014 10:17:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdF-00085q-Mu
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:05 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D9/0F-24532-13557545; Mon, 03 Nov 2014 10:13:05 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415009580!11771468!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16109 invoked from network); 3 Nov 2014 10:13:04 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:04 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWO17412; Mon, 03 Nov 2014 18:12:59 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:12:47 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:52 +0000
Message-ID: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020203.5457552C.0068, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a91f6ebb7e165ba228d50687a5c561c3
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] xen/arm: Add support for Huawei hip04-d01 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details).

The patch "xen/arm: Move vGIC registers on Hip04 platform" is actually a workaround and should have in the future a proper implementation in Xen (unfortunately not straightforward to do it).




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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEhq-0008Ix-Sp; Mon, 03 Nov 2014 10:17:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdN-00086q-76
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:13 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	8B/50-31453-83557545; Mon, 03 Nov 2014 10:13:12 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415009587!10874792!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13448 invoked from network); 3 Nov 2014 10:13:11 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:11 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38039; Mon, 03 Nov 2014 18:13:05 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:12:56 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:54 +0000
Message-ID: <1415009522-6344-3-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 02/10] xen/arm: Implement hip04-d01 board 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

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/platforms/hip04.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
index bf38c23..62d2034 100644
--- a/xen/arch/arm/platforms/hip04.c
+++ b/xen/arch/arm/platforms/hip04.c
@@ -27,6 +27,7 @@
 #include <xen/vmap.h>
 #include <asm/io.h>
 #include <asm/gic.h>
+#include <xen/delay.h>
 
 #define CORE_RESET_BIT(x)            (1 << x)
 #define NEON_RESET_BIT(x)            (1 << (x + 4))
@@ -53,13 +54,21 @@ struct hip04_secondary_cpu_data {
     u32 relocation_size;
 };
 
-static void __iomem *relocation, *sysctrl, *fabric;
+static void __iomem *relocation, *sysctrl, *fabric, *gb2;
 static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
 static struct hip04_secondary_cpu_data hip04_boot;
 
 static void hip04_reset(void)
 {
-    /* TODO */
+    unsigned long data;
+
+    if ( !gb2 )
+        return;
+
+    data = readl_relaxed(gb2);
+    writel_relaxed(data & ~0x4000000u, gb2);
+
+    mdelay(10);
 }
 
 static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
@@ -186,6 +195,11 @@ static int __init hip04_smp_init(void)
     if ( !fabric )
         goto err;
 
+    msg = "Error mapping GB2\n";
+    gb2 = ioremap_nocache(0xe4002000, 0x1000);
+    if ( !gb2 )
+        goto err;
+
     msg = "Error initializing SMP table\n";
     if ( !hip04_cpu_table_init() )
         goto err;
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEhq-0008Ix-Sp; Mon, 03 Nov 2014 10:17:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdN-00086q-76
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:13 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	8B/50-31453-83557545; Mon, 03 Nov 2014 10:13:12 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415009587!10874792!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13448 invoked from network); 3 Nov 2014 10:13:11 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:11 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38039; Mon, 03 Nov 2014 18:13:05 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:12:56 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:54 +0000
Message-ID: <1415009522-6344-3-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 02/10] xen/arm: Implement hip04-d01 board 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

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/platforms/hip04.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
index bf38c23..62d2034 100644
--- a/xen/arch/arm/platforms/hip04.c
+++ b/xen/arch/arm/platforms/hip04.c
@@ -27,6 +27,7 @@
 #include <xen/vmap.h>
 #include <asm/io.h>
 #include <asm/gic.h>
+#include <xen/delay.h>
 
 #define CORE_RESET_BIT(x)            (1 << x)
 #define NEON_RESET_BIT(x)            (1 << (x + 4))
@@ -53,13 +54,21 @@ struct hip04_secondary_cpu_data {
     u32 relocation_size;
 };
 
-static void __iomem *relocation, *sysctrl, *fabric;
+static void __iomem *relocation, *sysctrl, *fabric, *gb2;
 static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
 static struct hip04_secondary_cpu_data hip04_boot;
 
 static void hip04_reset(void)
 {
-    /* TODO */
+    unsigned long data;
+
+    if ( !gb2 )
+        return;
+
+    data = readl_relaxed(gb2);
+    writel_relaxed(data & ~0x4000000u, gb2);
+
+    mdelay(10);
 }
 
 static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
@@ -186,6 +195,11 @@ static int __init hip04_smp_init(void)
     if ( !fabric )
         goto err;
 
+    msg = "Error mapping GB2\n";
+    gb2 = ioremap_nocache(0xe4002000, 0x1000);
+    if ( !gb2 )
+        goto err;
+
     msg = "Error initializing SMP table\n";
     if ( !hip04_cpu_table_init() )
         goto err;
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEhr-0008Jc-Am; Mon, 03 Nov 2014 10:17:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdP-00087B-7E
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:15 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	2F/3C-11581-A3557545; Mon, 03 Nov 2014 10:13:14 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415009589!5539123!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23026 invoked from network); 3 Nov 2014 10:13:13 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:13 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWO17437; Mon, 03 Nov 2014 18:13:08 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:00 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:55 +0000
Message-ID: <1415009522-6344-4-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020203.54575534.0235, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 0fb581657d1b1913b36cf6db2606ed43
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 03/10] xen/arm: Define quirk for Hip04 GICv2
	divergence
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@huawei.com>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/hip04.c | 6 ++++++
 xen/include/asm-arm/platform.h | 5 +++++
 2 files changed, 11 insertions(+)

diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
index 62d2034..024c8a0 100644
--- a/xen/arch/arm/platforms/hip04.c
+++ b/xen/arch/arm/platforms/hip04.c
@@ -253,12 +253,18 @@ static const struct dt_device_match hip04_blacklist_dev[] __initconst =
     { /* sentinel */ },
 };
 
+static uint32_t hip04_quirks(void)
+{
+    return PLATFORM_QUIRK_GICV2_16_CPU;
+}
+
 
 PLATFORM_START(hip04, "HISILICON HIP04")
     .compatible = hip04_dt_compat,
     .smp_init = hip04_smp_init,
     .cpu_up = hip04_cpu_up,
     .reset = hip04_reset,
+    .quirks = hip04_quirks,
     .blacklist_dev = hip04_blacklist_dev,
 PLATFORM_END
 
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index eefaca6..537fba5 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -60,6 +60,11 @@ struct platform_desc {
  */
 #define PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI       (1 << 1)
 
+/*
+ * Quirk for platforms where GICv2 has to handle 16 CPUs
+ */
+#define PLATFORM_QUIRK_GICV2_16_CPU       (1 << 2)
+
 void __init platform_init(void);
 int __init platform_init_time(void);
 int __init platform_specific_mapping(struct domain *d);
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEhr-0008Jc-Am; Mon, 03 Nov 2014 10:17:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdP-00087B-7E
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:15 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	2F/3C-11581-A3557545; Mon, 03 Nov 2014 10:13:14 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415009589!5539123!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23026 invoked from network); 3 Nov 2014 10:13:13 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:13 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWO17437; Mon, 03 Nov 2014 18:13:08 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:00 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:55 +0000
Message-ID: <1415009522-6344-4-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020203.54575534.0235, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 0fb581657d1b1913b36cf6db2606ed43
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 03/10] xen/arm: Define quirk for Hip04 GICv2
	divergence
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@huawei.com>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/hip04.c | 6 ++++++
 xen/include/asm-arm/platform.h | 5 +++++
 2 files changed, 11 insertions(+)

diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
index 62d2034..024c8a0 100644
--- a/xen/arch/arm/platforms/hip04.c
+++ b/xen/arch/arm/platforms/hip04.c
@@ -253,12 +253,18 @@ static const struct dt_device_match hip04_blacklist_dev[] __initconst =
     { /* sentinel */ },
 };
 
+static uint32_t hip04_quirks(void)
+{
+    return PLATFORM_QUIRK_GICV2_16_CPU;
+}
+
 
 PLATFORM_START(hip04, "HISILICON HIP04")
     .compatible = hip04_dt_compat,
     .smp_init = hip04_smp_init,
     .cpu_up = hip04_cpu_up,
     .reset = hip04_reset,
+    .quirks = hip04_quirks,
     .blacklist_dev = hip04_blacklist_dev,
 PLATFORM_END
 
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index eefaca6..537fba5 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -60,6 +60,11 @@ struct platform_desc {
  */
 #define PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI       (1 << 1)
 
+/*
+ * Quirk for platforms where GICv2 has to handle 16 CPUs
+ */
+#define PLATFORM_QUIRK_GICV2_16_CPU       (1 << 2)
+
 void __init platform_init(void);
 int __init platform_init_time(void);
 int __init platform_specific_mapping(struct domain *d);
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEhr-0008K9-NM; Mon, 03 Nov 2014 10:17:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdV-00088C-G3
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3F/9F-24532-04557545; Mon, 03 Nov 2014 10:13:20 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415009594!8898651!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22126 invoked from network); 3 Nov 2014 10:13:17 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:17 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38062; Mon, 03 Nov 2014 18:13:13 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:05 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:56 +0000
Message-ID: <1415009522-6344-5-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 04/10] xen/arm: Make gic-v2 code handle
	hip04-d01 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

The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 70 ++++++++++++++++++++++++++++++++++++++---------
 xen/arch/arm/gic.c        |  5 +++-
 xen/include/asm-arm/gic.h |  4 ++-
 3 files changed, 64 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..eef55ed 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -79,16 +79,22 @@ static struct gic_info gicv2_info;
  * logical CPU numbering. Let's use mapping as returned by the GIC
  * itself
  */
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
 
 /* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+static unsigned int nr_gic_cpu_if = 8;
+static unsigned int gic_cpu_mask = 0xff;
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
     writeb_relaxed(val, gicv2.map_dbase + offset);
 }
 
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+    writew_relaxed(val, gicv2.map_dbase + offset);
+}
+
 static inline void writel_gicd(uint32_t val, unsigned int offset)
 {
     writel_relaxed(val, gicv2.map_dbase + offset);
@@ -132,7 +138,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
     cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
     for_each_cpu( cpu, &possible_mask )
     {
-        ASSERT(cpu < NR_GIC_CPU_IF);
+        ASSERT(cpu < nr_gic_cpu_if);
         mask |= per_cpu(gic_cpu_id, cpu);
     }
 
@@ -203,6 +209,15 @@ static unsigned int gicv2_read_irq(void)
     return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
+/* Set target CPU mask (RAZ/WI on uniprocessor) */
+static void gicv2_set_irq_mask(int irq, unsigned int mask)
+{
+    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
+        writew_gicd(mask, GICD_ITARGETSR + irq * 2);
+    else
+        writeb_gicd(mask, GICD_ITARGETSR + irq);
+}
+
 /*
  * needs to be called with a valid cpu_mask, ie each cpu in the mask has
  * already called gic_cpu_init
@@ -230,7 +245,7 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
     writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + irq);
+    gicv2_set_irq_mask(irq, mask);
     /* Set priority */
     writeb_gicd(priority, GICD_IPRIORITYR + irq);
 
@@ -244,16 +259,22 @@ static void __init gicv2_dist_init(void)
     uint32_t gic_cpus;
     int i;
 
-    cpumask = readl_gicd(GICD_ITARGETSR) & 0xff;
-    cpumask |= cpumask << 8;
-    cpumask |= cpumask << 16;
+    cpumask = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* Disable the distributor */
     writel_gicd(0, GICD_CTLR);
 
     type = readl_gicd(GICD_TYPER);
     gicv2_info.nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
-    gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
+    {
+        gic_cpus = 16;
+        BUG_ON( gicv2_info.nr_lines > 510 );
+    }
+    else
+    {
+        gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    }
     printk("GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n",
            gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
            (type & GICD_TYPE_SEC) ? ", secure" : "",
@@ -264,8 +285,19 @@ static void __init gicv2_dist_init(void)
         writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
 
     /* Route all global IRQs to this CPU */
-    for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
-        writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
+    {
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 2 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 2) * 4);
+    }
+    else
+    {
+        cpumask |= cpumask << 8;
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    }
 
     /* Default priority for global interrupts */
     for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
@@ -285,7 +317,7 @@ static void __cpuinit gicv2_cpu_init(void)
 {
     int i;
 
-    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & 0xff;
+    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
      * even though they are controlled with GICD registers, they must
@@ -348,6 +380,11 @@ static int gicv2_secondary_cpu_init(void)
     return 0;
 }
 
+static inline unsigned gicd_sgi_target_shift(void)
+{
+    return 8 + 16 - nr_gic_cpu_if;
+}
+
 static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
                            const cpumask_t *cpu_mask)
 {
@@ -366,7 +403,7 @@ static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
         cpumask_and(&online_mask, cpu_mask, &cpu_online_map);
         mask = gicv2_cpu_mask(&online_mask);
         writel_gicd(GICD_SGI_TARGET_LIST |
-                    (mask << GICD_SGI_TARGET_SHIFT) | sgi,
+                    (mask << gicd_sgi_target_shift()) | sgi,
                     GICD_SGIR);
         break;
     default:
@@ -581,7 +618,7 @@ static void gicv2_irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_m
     mask = gicv2_cpu_mask(cpu_mask);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + desc->irq);
+    gicv2_set_irq_mask(desc->irq, mask);
 
     spin_unlock(&gicv2.lock);
 }
@@ -690,6 +727,12 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
 
     dt_device_set_used_by(node, DOMID_XEN);
 
+    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
+    {
+        nr_gic_cpu_if = 16;
+        gic_cpu_mask = 0xffff;
+    }
+
     res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
     if ( res || !gicv2.dbase || (gicv2.dbase & ~PAGE_MASK) )
         panic("GICv2: Cannot find a valid address for the distributor");
@@ -769,6 +812,7 @@ static const char * const gicv2_dt_compat[] __initconst =
     DT_COMPAT_GIC_CORTEX_A15,
     DT_COMPAT_GIC_CORTEX_A7,
     DT_COMPAT_GIC_400,
+    DT_COMPAT_GIC_HIP04,
     NULL
 };
 
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..cd934cf 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -563,12 +563,15 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
 void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 {
     unsigned int irq;
+    unsigned int max_irq = platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) ?
+                           510 :
+                           1021;
 
     do  {
         /* Reading IRQ will ACK it */
         irq = gic_hw_ops->read_irq();
 
-        if ( likely(irq >= 16 && irq < 1021) )
+        if ( likely(irq >= 16 && irq < max_irq) )
         {
             local_irq_enable();
             do_IRQ(regs, irq, is_fiq);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..5adb628 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -155,10 +155,12 @@
 #define DT_COMPAT_GIC_400            "arm,gic-400"
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
+#define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEhr-0008K9-NM; Mon, 03 Nov 2014 10:17:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdV-00088C-G3
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3F/9F-24532-04557545; Mon, 03 Nov 2014 10:13:20 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415009594!8898651!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22126 invoked from network); 3 Nov 2014 10:13:17 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:17 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38062; Mon, 03 Nov 2014 18:13:13 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:05 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:56 +0000
Message-ID: <1415009522-6344-5-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 04/10] xen/arm: Make gic-v2 code handle
	hip04-d01 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

The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 70 ++++++++++++++++++++++++++++++++++++++---------
 xen/arch/arm/gic.c        |  5 +++-
 xen/include/asm-arm/gic.h |  4 ++-
 3 files changed, 64 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..eef55ed 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -79,16 +79,22 @@ static struct gic_info gicv2_info;
  * logical CPU numbering. Let's use mapping as returned by the GIC
  * itself
  */
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
 
 /* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+static unsigned int nr_gic_cpu_if = 8;
+static unsigned int gic_cpu_mask = 0xff;
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
     writeb_relaxed(val, gicv2.map_dbase + offset);
 }
 
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+    writew_relaxed(val, gicv2.map_dbase + offset);
+}
+
 static inline void writel_gicd(uint32_t val, unsigned int offset)
 {
     writel_relaxed(val, gicv2.map_dbase + offset);
@@ -132,7 +138,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
     cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
     for_each_cpu( cpu, &possible_mask )
     {
-        ASSERT(cpu < NR_GIC_CPU_IF);
+        ASSERT(cpu < nr_gic_cpu_if);
         mask |= per_cpu(gic_cpu_id, cpu);
     }
 
@@ -203,6 +209,15 @@ static unsigned int gicv2_read_irq(void)
     return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
+/* Set target CPU mask (RAZ/WI on uniprocessor) */
+static void gicv2_set_irq_mask(int irq, unsigned int mask)
+{
+    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
+        writew_gicd(mask, GICD_ITARGETSR + irq * 2);
+    else
+        writeb_gicd(mask, GICD_ITARGETSR + irq);
+}
+
 /*
  * needs to be called with a valid cpu_mask, ie each cpu in the mask has
  * already called gic_cpu_init
@@ -230,7 +245,7 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
     writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + irq);
+    gicv2_set_irq_mask(irq, mask);
     /* Set priority */
     writeb_gicd(priority, GICD_IPRIORITYR + irq);
 
@@ -244,16 +259,22 @@ static void __init gicv2_dist_init(void)
     uint32_t gic_cpus;
     int i;
 
-    cpumask = readl_gicd(GICD_ITARGETSR) & 0xff;
-    cpumask |= cpumask << 8;
-    cpumask |= cpumask << 16;
+    cpumask = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* Disable the distributor */
     writel_gicd(0, GICD_CTLR);
 
     type = readl_gicd(GICD_TYPER);
     gicv2_info.nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
-    gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
+    {
+        gic_cpus = 16;
+        BUG_ON( gicv2_info.nr_lines > 510 );
+    }
+    else
+    {
+        gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    }
     printk("GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n",
            gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
            (type & GICD_TYPE_SEC) ? ", secure" : "",
@@ -264,8 +285,19 @@ static void __init gicv2_dist_init(void)
         writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
 
     /* Route all global IRQs to this CPU */
-    for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
-        writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
+    {
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 2 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 2) * 4);
+    }
+    else
+    {
+        cpumask |= cpumask << 8;
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    }
 
     /* Default priority for global interrupts */
     for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
@@ -285,7 +317,7 @@ static void __cpuinit gicv2_cpu_init(void)
 {
     int i;
 
-    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & 0xff;
+    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
      * even though they are controlled with GICD registers, they must
@@ -348,6 +380,11 @@ static int gicv2_secondary_cpu_init(void)
     return 0;
 }
 
+static inline unsigned gicd_sgi_target_shift(void)
+{
+    return 8 + 16 - nr_gic_cpu_if;
+}
+
 static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
                            const cpumask_t *cpu_mask)
 {
@@ -366,7 +403,7 @@ static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
         cpumask_and(&online_mask, cpu_mask, &cpu_online_map);
         mask = gicv2_cpu_mask(&online_mask);
         writel_gicd(GICD_SGI_TARGET_LIST |
-                    (mask << GICD_SGI_TARGET_SHIFT) | sgi,
+                    (mask << gicd_sgi_target_shift()) | sgi,
                     GICD_SGIR);
         break;
     default:
@@ -581,7 +618,7 @@ static void gicv2_irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_m
     mask = gicv2_cpu_mask(cpu_mask);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + desc->irq);
+    gicv2_set_irq_mask(desc->irq, mask);
 
     spin_unlock(&gicv2.lock);
 }
@@ -690,6 +727,12 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
 
     dt_device_set_used_by(node, DOMID_XEN);
 
+    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
+    {
+        nr_gic_cpu_if = 16;
+        gic_cpu_mask = 0xffff;
+    }
+
     res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
     if ( res || !gicv2.dbase || (gicv2.dbase & ~PAGE_MASK) )
         panic("GICv2: Cannot find a valid address for the distributor");
@@ -769,6 +812,7 @@ static const char * const gicv2_dt_compat[] __initconst =
     DT_COMPAT_GIC_CORTEX_A15,
     DT_COMPAT_GIC_CORTEX_A7,
     DT_COMPAT_GIC_400,
+    DT_COMPAT_GIC_HIP04,
     NULL
 };
 
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..cd934cf 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -563,12 +563,15 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
 void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 {
     unsigned int irq;
+    unsigned int max_irq = platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) ?
+                           510 :
+                           1021;
 
     do  {
         /* Reading IRQ will ACK it */
         irq = gic_hw_ops->read_irq();
 
-        if ( likely(irq >= 16 && irq < 1021) )
+        if ( likely(irq >= 16 && irq < max_irq) )
         {
             local_irq_enable();
             do_IRQ(regs, irq, is_fiq);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..5adb628 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -155,10 +155,12 @@
 #define DT_COMPAT_GIC_400            "arm,gic-400"
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
+#define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlEhs-0008Kp-34; Mon, 03 Nov 2014 10:17:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEda-00088X-4E
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:26 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	9C/44-17735-54557545; Mon, 03 Nov 2014 10:13:25 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415009600!11246050!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28893 invoked from network); 3 Nov 2014 10:13:24 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:24 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBU13759; Mon, 03 Nov 2014 18:13:19 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:10 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:57 +0000
Message-ID: <1415009522-6344-6-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 05/10] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@huawei.com>

This name can appear in some Linux kernel repos. Not very fortunate,
but to avoid others spending an hour to spot that few characters
difference it worth to work around it.

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 1 +
 xen/include/asm-arm/gic.h | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index eef55ed..85c7f11 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -813,6 +813,7 @@ static const char * const gicv2_dt_compat[] __initconst =
     DT_COMPAT_GIC_CORTEX_A7,
     DT_COMPAT_GIC_400,
     DT_COMPAT_GIC_HIP04,
+    DT_COMPAT_GIC_HIP04_2,
     NULL
 };
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 5adb628..3d2b3db 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -156,11 +156,13 @@
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
 #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
+#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlEhs-0008Kp-34; Mon, 03 Nov 2014 10:17:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEda-00088X-4E
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:26 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	9C/44-17735-54557545; Mon, 03 Nov 2014 10:13:25 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415009600!11246050!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28893 invoked from network); 3 Nov 2014 10:13:24 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:24 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBU13759; Mon, 03 Nov 2014 18:13:19 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:10 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:57 +0000
Message-ID: <1415009522-6344-6-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 05/10] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@huawei.com>

This name can appear in some Linux kernel repos. Not very fortunate,
but to avoid others spending an hour to spot that few characters
difference it worth to work around it.

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 1 +
 xen/include/asm-arm/gic.h | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index eef55ed..85c7f11 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -813,6 +813,7 @@ static const char * const gicv2_dt_compat[] __initconst =
     DT_COMPAT_GIC_CORTEX_A7,
     DT_COMPAT_GIC_400,
     DT_COMPAT_GIC_HIP04,
+    DT_COMPAT_GIC_HIP04_2,
     NULL
 };
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 5adb628..3d2b3db 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -156,11 +156,13 @@
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
 #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
+#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlEhs-0008LY-Jn; Mon, 03 Nov 2014 10:17:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEde-000891-8D
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:30 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C0/DF-02696-94557545; Mon, 03 Nov 2014 10:13:29 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415009604!12170961!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 989 invoked from network); 3 Nov 2014 10:13:28 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:28 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38087; Mon, 03 Nov 2014 18:13:23 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:14 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:58 +0000
Message-ID: <1415009522-6344-7-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 06/10] xen/arm: handle GICH register changes for
	hip04-d01 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

The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 24 ++++++++++++++----------
 xen/include/asm-arm/gic.h |  2 ++
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 85c7f11..e7bf331 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -84,6 +84,8 @@ static DEFINE_PER_CPU(u16, gic_cpu_id);
 /* Maximum cpu interface per GIC */
 static unsigned int nr_gic_cpu_if = 8;
 static unsigned int gic_cpu_mask = 0xff;
+static unsigned int gich_apr = GICH_APR;
+static unsigned int gich_lr = GICH_LR;
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
@@ -154,9 +156,9 @@ static void gicv2_save_state(struct vcpu *v)
      * accessed simultaneously by another pCPU.
      */
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        v->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+        v->arch.gic.v2.lr[i] = readl_gich(gich_lr + i * 4);
 
-    v->arch.gic.v2.apr = readl_gich(GICH_APR);
+    v->arch.gic.v2.apr = readl_gich(gich_apr);
     v->arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
     /* Disable until next VCPU scheduled */
     writel_gich(0, GICH_HCR);
@@ -167,9 +169,9 @@ static void gicv2_restore_state(const struct vcpu *v)
     int i;
 
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        writel_gich(v->arch.gic.v2.lr[i], GICH_LR + i * 4);
+        writel_gich(v->arch.gic.v2.lr[i], gich_lr + i * 4);
 
-    writel_gich(v->arch.gic.v2.apr, GICH_APR);
+    writel_gich(v->arch.gic.v2.apr, gich_apr);
     writel_gich(v->arch.gic.v2.vmcr, GICH_VMCR);
     writel_gich(GICH_HCR_EN, GICH_HCR);
 }
@@ -182,7 +184,7 @@ static void gicv2_dump_state(const struct vcpu *v)
     {
         for ( i = 0; i < gicv2_info.nr_lrs; i++ )
             printk("   HW_LR[%d]=%x\n", i,
-                   readl_gich(GICH_LR + i * 4));
+                   readl_gich(gich_lr + i * 4));
     }
     else
     {
@@ -442,12 +444,12 @@ static void gicv2_update_lr(int lr, const struct pending_irq *p,
                             << GICH_V2_LR_PHYSICAL_SHIFT);
     }
 
-    writel_gich(lr_reg, GICH_LR + lr * 4);
+    writel_gich(lr_reg, gich_lr + lr * 4);
 }
 
 static void gicv2_clear_lr(int lr)
 {
-    writel_gich(0, GICH_LR + lr * 4);
+    writel_gich(0, gich_lr + lr * 4);
 }
 
 static int gicv2v_setup(struct domain *d)
@@ -497,7 +499,7 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 {
     uint32_t lrv;
 
-    lrv          = readl_gich(GICH_LR + lr * 4);
+    lrv          = readl_gich(gich_lr + lr * 4);
     lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) & GICH_V2_LR_PHYSICAL_MASK;
     lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
     lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & GICH_V2_LR_PRIORITY_MASK;
@@ -520,7 +522,7 @@ static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
                                        << GICH_V2_LR_HW_SHIFT)  |
           ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) << GICH_V2_LR_GRP_SHIFT) );
 
-    writel_gich(lrv, GICH_LR + lr * 4);
+    writel_gich(lrv, gich_lr + lr * 4);
 }
 
 static void gicv2_hcr_status(uint32_t flag, bool_t status)
@@ -543,7 +545,7 @@ static unsigned int gicv2_read_vmcr_priority(void)
 
 static unsigned int gicv2_read_apr(int apr_reg)
 {
-   return readl_gich(GICH_APR);
+   return readl_gich(gich_apr);
 }
 
 static void gicv2_irq_enable(struct irq_desc *desc)
@@ -731,6 +733,8 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
     {
         nr_gic_cpu_if = 16;
         gic_cpu_mask = 0xffff;
+        gich_apr = HIP04_GICH_APR;
+        gich_lr = HIP04_GICH_LR;
     }
 
     res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 3d2b3db..804bf24 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -88,6 +88,8 @@
 #define GICH_ELSR1      (0x34)
 #define GICH_APR        (0xF0)
 #define GICH_LR         (0x100)
+#define HIP04_GICH_APR  (0x70)
+#define HIP04_GICH_LR   (0x80)
 
 /* Register bits */
 #define GICD_CTL_ENABLE 0x1
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlEhs-0008LY-Jn; Mon, 03 Nov 2014 10:17:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEde-000891-8D
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:30 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C0/DF-02696-94557545; Mon, 03 Nov 2014 10:13:29 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415009604!12170961!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 989 invoked from network); 3 Nov 2014 10:13:28 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:28 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38087; Mon, 03 Nov 2014 18:13:23 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:14 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:58 +0000
Message-ID: <1415009522-6344-7-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 06/10] xen/arm: handle GICH register changes for
	hip04-d01 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

The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 24 ++++++++++++++----------
 xen/include/asm-arm/gic.h |  2 ++
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 85c7f11..e7bf331 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -84,6 +84,8 @@ static DEFINE_PER_CPU(u16, gic_cpu_id);
 /* Maximum cpu interface per GIC */
 static unsigned int nr_gic_cpu_if = 8;
 static unsigned int gic_cpu_mask = 0xff;
+static unsigned int gich_apr = GICH_APR;
+static unsigned int gich_lr = GICH_LR;
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
@@ -154,9 +156,9 @@ static void gicv2_save_state(struct vcpu *v)
      * accessed simultaneously by another pCPU.
      */
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        v->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+        v->arch.gic.v2.lr[i] = readl_gich(gich_lr + i * 4);
 
-    v->arch.gic.v2.apr = readl_gich(GICH_APR);
+    v->arch.gic.v2.apr = readl_gich(gich_apr);
     v->arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
     /* Disable until next VCPU scheduled */
     writel_gich(0, GICH_HCR);
@@ -167,9 +169,9 @@ static void gicv2_restore_state(const struct vcpu *v)
     int i;
 
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        writel_gich(v->arch.gic.v2.lr[i], GICH_LR + i * 4);
+        writel_gich(v->arch.gic.v2.lr[i], gich_lr + i * 4);
 
-    writel_gich(v->arch.gic.v2.apr, GICH_APR);
+    writel_gich(v->arch.gic.v2.apr, gich_apr);
     writel_gich(v->arch.gic.v2.vmcr, GICH_VMCR);
     writel_gich(GICH_HCR_EN, GICH_HCR);
 }
@@ -182,7 +184,7 @@ static void gicv2_dump_state(const struct vcpu *v)
     {
         for ( i = 0; i < gicv2_info.nr_lrs; i++ )
             printk("   HW_LR[%d]=%x\n", i,
-                   readl_gich(GICH_LR + i * 4));
+                   readl_gich(gich_lr + i * 4));
     }
     else
     {
@@ -442,12 +444,12 @@ static void gicv2_update_lr(int lr, const struct pending_irq *p,
                             << GICH_V2_LR_PHYSICAL_SHIFT);
     }
 
-    writel_gich(lr_reg, GICH_LR + lr * 4);
+    writel_gich(lr_reg, gich_lr + lr * 4);
 }
 
 static void gicv2_clear_lr(int lr)
 {
-    writel_gich(0, GICH_LR + lr * 4);
+    writel_gich(0, gich_lr + lr * 4);
 }
 
 static int gicv2v_setup(struct domain *d)
@@ -497,7 +499,7 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 {
     uint32_t lrv;
 
-    lrv          = readl_gich(GICH_LR + lr * 4);
+    lrv          = readl_gich(gich_lr + lr * 4);
     lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) & GICH_V2_LR_PHYSICAL_MASK;
     lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
     lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & GICH_V2_LR_PRIORITY_MASK;
@@ -520,7 +522,7 @@ static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
                                        << GICH_V2_LR_HW_SHIFT)  |
           ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) << GICH_V2_LR_GRP_SHIFT) );
 
-    writel_gich(lrv, GICH_LR + lr * 4);
+    writel_gich(lrv, gich_lr + lr * 4);
 }
 
 static void gicv2_hcr_status(uint32_t flag, bool_t status)
@@ -543,7 +545,7 @@ static unsigned int gicv2_read_vmcr_priority(void)
 
 static unsigned int gicv2_read_apr(int apr_reg)
 {
-   return readl_gich(GICH_APR);
+   return readl_gich(gich_apr);
 }
 
 static void gicv2_irq_enable(struct irq_desc *desc)
@@ -731,6 +733,8 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
     {
         nr_gic_cpu_if = 16;
         gic_cpu_mask = 0xffff;
+        gich_apr = HIP04_GICH_APR;
+        gich_lr = HIP04_GICH_LR;
     }
 
     res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 3d2b3db..804bf24 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -88,6 +88,8 @@
 #define GICH_ELSR1      (0x34)
 #define GICH_APR        (0xF0)
 #define GICH_LR         (0x100)
+#define HIP04_GICH_APR  (0x70)
+#define HIP04_GICH_LR   (0x80)
 
 /* Register bits */
 #define GICD_CTL_ENABLE 0x1
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEht-0008MG-1k; Mon, 03 Nov 2014 10:17:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdi-00089X-HS
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:34 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	A2/AC-17694-D4557545; Mon, 03 Nov 2014 10:13:33 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415009609!11180600!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19036 invoked from network); 3 Nov 2014 10:13:33 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:33 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38098; Mon, 03 Nov 2014 18:13:28 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:18 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:59 +0000
Message-ID: <1415009522-6344-8-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 07/10] xen/arm: Force domains to use normal
	GICv2 driver on Hip04 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

Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index e7bf331..d92e2c0 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -641,6 +641,12 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOENT);
     }
 
+    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
+    {
+        compatible = DT_COMPAT_GIC_CORTEX_A15;
+        len = strlen((char*) compatible) + 1;
+    }
+
     res = fdt_begin_node(fdt, "interrupt-controller");
     if ( res )
         return res;
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEht-0008MG-1k; Mon, 03 Nov 2014 10:17:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdi-00089X-HS
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:34 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	A2/AC-17694-D4557545; Mon, 03 Nov 2014 10:13:33 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415009609!11180600!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19036 invoked from network); 3 Nov 2014 10:13:33 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:33 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38098; Mon, 03 Nov 2014 18:13:28 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:18 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:11:59 +0000
Message-ID: <1415009522-6344-8-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 07/10] xen/arm: Force domains to use normal
	GICv2 driver on Hip04 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

Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index e7bf331..d92e2c0 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -641,6 +641,12 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOENT);
     }
 
+    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
+    {
+        compatible = DT_COMPAT_GIC_CORTEX_A15;
+        len = strlen((char*) compatible) + 1;
+    }
+
     res = fdt_begin_node(fdt, "interrupt-controller");
     if ( res )
         return res;
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEht-0008NA-IW; Mon, 03 Nov 2014 10:17:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdj-00089c-7n
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:35 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	14/A6-02576-E4557545; Mon, 03 Nov 2014 10:13:34 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415009609!12166461!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30087 invoked from network); 3 Nov 2014 10:13:33 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:33 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38099; Mon, 03 Nov 2014 18:13:29 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:22 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:12:00 +0000
Message-ID: <1415009522-6344-9-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 08/10] xen/arm: Move vGIC registers on Hip04
	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

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
 xen/include/asm-arm/gic.h |  2 ++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index d92e2c0..330157b 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -671,8 +671,19 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOMEM);
 
     tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+
+    if (platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU))
+    {
+        dt_set_range(&tmp, node, d->arch.vgic.dbase - HIP04_VGIC_REG_OFFSET,
+                     PAGE_SIZE);
+        dt_set_range(&tmp, node, d->arch.vgic.cbase - HIP04_VGIC_REG_OFFSET,
+                     PAGE_SIZE * 2);
+    }
+    else
+    {
+        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
+        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+    }
 
     res = fdt_property(fdt, "reg", new_cells, len);
     xfree(new_cells);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 804bf24..c748791 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -149,6 +149,8 @@
 #define GICH_LR_PENDING         1
 #define GICH_LR_ACTIVE          2
 
+#define HIP04_VGIC_REG_OFFSET   0xe0000000
+
 #ifndef __ASSEMBLY__
 #include <xen/device_tree.h>
 #include <xen/irq.h>
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEht-0008NA-IW; Mon, 03 Nov 2014 10:17:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdj-00089c-7n
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:35 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	14/A6-02576-E4557545; Mon, 03 Nov 2014 10:13:34 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415009609!12166461!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30087 invoked from network); 3 Nov 2014 10:13:33 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:33 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38099; Mon, 03 Nov 2014 18:13:29 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:22 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:12:00 +0000
Message-ID: <1415009522-6344-9-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 08/10] xen/arm: Move vGIC registers on Hip04
	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

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
 xen/include/asm-arm/gic.h |  2 ++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index d92e2c0..330157b 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -671,8 +671,19 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOMEM);
 
     tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+
+    if (platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU))
+    {
+        dt_set_range(&tmp, node, d->arch.vgic.dbase - HIP04_VGIC_REG_OFFSET,
+                     PAGE_SIZE);
+        dt_set_range(&tmp, node, d->arch.vgic.cbase - HIP04_VGIC_REG_OFFSET,
+                     PAGE_SIZE * 2);
+    }
+    else
+    {
+        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
+        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+    }
 
     res = fdt_property(fdt, "reg", new_cells, len);
     xfree(new_cells);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 804bf24..c748791 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -149,6 +149,8 @@
 #define GICH_LR_PENDING         1
 #define GICH_LR_ACTIVE          2
 
+#define HIP04_VGIC_REG_OFFSET   0xe0000000
+
 #ifndef __ASSEMBLY__
 #include <xen/device_tree.h>
 #include <xen/irq.h>
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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 1XlEhu-0008O6-1H; Mon, 03 Nov 2014 10:17:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdo-0008AF-9A
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:40 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	16/F3-23865-35557545; Mon, 03 Nov 2014 10:13:39 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415009614!11249432!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3946 invoked from network); 3 Nov 2014 10:13:38 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:38 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWO17482; Mon, 03 Nov 2014 18:13:33 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:27 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:12:01 +0000
Message-ID: <1415009522-6344-10-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020202.5457554E.003E, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: fc3fc13d539b46014e9369b4c5746efa
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 09/10] xen/device_tree: Add new helper to read
	arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@linaro.org>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/common/device_tree.c      | 14 ++++++++++----
 xen/include/xen/device_tree.h | 11 +++++++++++
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..e97c28b 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -160,19 +160,25 @@ const void *dt_get_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                          const char *name, u32 *out_value)
 {
-    u32 len;
+    return dt_property_read_u32_array(np, name, out_value, 1);
+}
+
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len)
+{
+    u32 len, i;
     const __be32 *val;
 
     val = dt_get_property(np, name, &len);
-    if ( !val || len < sizeof(*out_value) )
+    if ( !val || len < sizeof(*out_value) * out_len )
         return 0;
 
-    *out_value = be32_to_cpup(val);
+    for ( i = 0; i < out_len; i++, val++ )
+        out_value[i] = be32_to_cpup(val);
 
     return 1;
 }
 
-
 bool_t dt_property_read_u64(const struct dt_device_node *np,
                          const char *name, u64 *out_value)
 {
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..5fcd9c4 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                             const char *name, u32 *out_value);
 /**
+ * dt_property_read_u32_array - Helper to read a u32 array property.
+ * @np: node to get the value
+ * @name: name of the property
+ * @out_value: pointer to return value
+ * @out_len: lenght of the array
+ *
+ * Return true if get the desired value.
+ */
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len);
+/**
  * dt_property_read_u64 - Helper to read a u64 property.
  * @np: node to get the value
  * @name: name of the property
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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 1XlEhu-0008O6-1H; Mon, 03 Nov 2014 10:17:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdo-0008AF-9A
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:40 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	16/F3-23865-35557545; Mon, 03 Nov 2014 10:13:39 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415009614!11249432!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3946 invoked from network); 3 Nov 2014 10:13:38 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:38 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWO17482; Mon, 03 Nov 2014 18:13:33 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:27 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:12:01 +0000
Message-ID: <1415009522-6344-10-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020202.5457554E.003E, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: fc3fc13d539b46014e9369b4c5746efa
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 09/10] xen/device_tree: Add new helper to read
	arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@linaro.org>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/common/device_tree.c      | 14 ++++++++++----
 xen/include/xen/device_tree.h | 11 +++++++++++
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..e97c28b 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -160,19 +160,25 @@ const void *dt_get_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                          const char *name, u32 *out_value)
 {
-    u32 len;
+    return dt_property_read_u32_array(np, name, out_value, 1);
+}
+
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len)
+{
+    u32 len, i;
     const __be32 *val;
 
     val = dt_get_property(np, name, &len);
-    if ( !val || len < sizeof(*out_value) )
+    if ( !val || len < sizeof(*out_value) * out_len )
         return 0;
 
-    *out_value = be32_to_cpup(val);
+    for ( i = 0; i < out_len; i++, val++ )
+        out_value[i] = be32_to_cpup(val);
 
     return 1;
 }
 
-
 bool_t dt_property_read_u64(const struct dt_device_node *np,
                          const char *name, u64 *out_value)
 {
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..5fcd9c4 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                             const char *name, u32 *out_value);
 /**
+ * dt_property_read_u32_array - Helper to read a u32 array property.
+ * @np: node to get the value
+ * @name: name of the property
+ * @out_value: pointer to return value
+ * @out_len: lenght of the array
+ *
+ * Return true if get the desired value.
+ */
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len);
+/**
  * dt_property_read_u64 - Helper to read a u64 property.
  * @np: node to get the value
  * @name: name of the property
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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 1XlEhu-0008Oq-GS; Mon, 03 Nov 2014 10:17:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdt-0008Ag-7q
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:45 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	E2/27-26858-85557545; Mon, 03 Nov 2014 10:13:44 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415009619!11224654!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6504 invoked from network); 3 Nov 2014 10:13:43 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:43 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38112; Mon, 03 Nov 2014 18:13:39 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:31 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:12:02 +0000
Message-ID: <1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
	locations for Hip04 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

From: Zoltan Kiss <zoltan.kiss@linaro.org>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/hip04.c | 63 ++++++++++++++++++++++++++----------------
 1 file changed, 39 insertions(+), 24 deletions(-)

diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
index 024c8a0..dec4984 100644
--- a/xen/arch/arm/platforms/hip04.c
+++ b/xen/arch/arm/platforms/hip04.c
@@ -136,7 +136,7 @@ static void hip04_cluster_up(unsigned int cluster)
 
 static int __init hip04_smp_init(void)
 {
-    struct dt_device_node *np, *np_fab;
+    struct dt_device_node *np, *np_fab, *bw;
     const char *msg;
     u64 addr, size;
 
@@ -150,30 +150,45 @@ static int __init hip04_smp_init(void)
     if ( !np_fab )
         goto err;
 
-    msg = "failed to get bootwrapper-phys\n";
     if ( !dt_property_read_u32(np, "bootwrapper-phys",
-                               &hip04_boot.bootwrapper_phys) )
-        goto err;
-
-    msg = "failed to get bootwrapper-size\n";
-    if ( !dt_property_read_u32(np, "bootwrapper-size",
-                               &hip04_boot.bootwrapper_size) )
-        goto err;
-
-    msg = "failed to get bootwrapper-magic\n";
-    if ( !dt_property_read_u32(np, "bootwrapper-magic",
-                               &hip04_boot.bootwrapper_magic) )
-        goto err;
-
-    msg = "failed to get relocation-entry\n";
-    if ( !dt_property_read_u32(np, "relocation-entry",
-                               &hip04_boot.relocation_entry) )
-        goto err;
-
-    msg = "failed to get relocation-size\n";
-    if ( !dt_property_read_u32(np, "relocation-size",
-                 &hip04_boot.relocation_size) )
-        goto err;
+                               &hip04_boot.bootwrapper_phys) ) {
+        u32 boot_method[4];
+        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-bootwrapper");
+        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
+        if ( !bw )
+            goto err;
+
+        msg = "failed to get boot-method\n";
+        if ( !dt_property_read_u32_array(bw, "boot-method", boot_method, 4) )
+            goto err;
+        hip04_boot.bootwrapper_phys = boot_method[0];
+        hip04_boot.bootwrapper_size = boot_method[1];
+        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
+        hip04_boot.relocation_entry = boot_method[2];
+        hip04_boot.relocation_size = boot_method[3];
+    }
+    else
+    {
+        msg = "failed to get bootwrapper-size\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-size",
+                                   &hip04_boot.bootwrapper_size) )
+            goto err;
+
+        msg = "failed to get bootwrapper-magic\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-magic",
+                                   &hip04_boot.bootwrapper_magic) )
+            goto err;
+
+        msg = "failed to get relocation-entry\n";
+        if ( !dt_property_read_u32(np, "relocation-entry",
+                                   &hip04_boot.relocation_entry) )
+            goto err;
+
+        msg = "failed to get relocation-size\n";
+        if ( !dt_property_read_u32(np, "relocation-size",
+                                   &hip04_boot.relocation_size) )
+            goto err;
+    }
 
     relocation = ioremap_nocache(hip04_boot.relocation_entry,
                                  hip04_boot.relocation_size);
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:17:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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 1XlEhu-0008Oq-GS; Mon, 03 Nov 2014 10:17:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlEdt-0008Ag-7q
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:13:45 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	E2/27-26858-85557545; Mon, 03 Nov 2014 10:13:44 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415009619!11224654!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6504 invoked from network); 3 Nov 2014 10:13:43 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:13:43 -0000
Received: from 172.24.2.119 (EHLO szxeml403-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW38112; Mon, 03 Nov 2014 18:13:39 +0800 (CST)
Received: from localhost.localdomain (10.47.73.48) by
	szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server
	id 14.3.158.1; Mon, 3 Nov 2014 18:13:31 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 10:12:02 +0000
Message-ID: <1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.73.48]
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Nov 2014 10:17:48 +0000
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
	locations for Hip04 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

From: Zoltan Kiss <zoltan.kiss@linaro.org>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/hip04.c | 63 ++++++++++++++++++++++++++----------------
 1 file changed, 39 insertions(+), 24 deletions(-)

diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
index 024c8a0..dec4984 100644
--- a/xen/arch/arm/platforms/hip04.c
+++ b/xen/arch/arm/platforms/hip04.c
@@ -136,7 +136,7 @@ static void hip04_cluster_up(unsigned int cluster)
 
 static int __init hip04_smp_init(void)
 {
-    struct dt_device_node *np, *np_fab;
+    struct dt_device_node *np, *np_fab, *bw;
     const char *msg;
     u64 addr, size;
 
@@ -150,30 +150,45 @@ static int __init hip04_smp_init(void)
     if ( !np_fab )
         goto err;
 
-    msg = "failed to get bootwrapper-phys\n";
     if ( !dt_property_read_u32(np, "bootwrapper-phys",
-                               &hip04_boot.bootwrapper_phys) )
-        goto err;
-
-    msg = "failed to get bootwrapper-size\n";
-    if ( !dt_property_read_u32(np, "bootwrapper-size",
-                               &hip04_boot.bootwrapper_size) )
-        goto err;
-
-    msg = "failed to get bootwrapper-magic\n";
-    if ( !dt_property_read_u32(np, "bootwrapper-magic",
-                               &hip04_boot.bootwrapper_magic) )
-        goto err;
-
-    msg = "failed to get relocation-entry\n";
-    if ( !dt_property_read_u32(np, "relocation-entry",
-                               &hip04_boot.relocation_entry) )
-        goto err;
-
-    msg = "failed to get relocation-size\n";
-    if ( !dt_property_read_u32(np, "relocation-size",
-                 &hip04_boot.relocation_size) )
-        goto err;
+                               &hip04_boot.bootwrapper_phys) ) {
+        u32 boot_method[4];
+        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-bootwrapper");
+        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
+        if ( !bw )
+            goto err;
+
+        msg = "failed to get boot-method\n";
+        if ( !dt_property_read_u32_array(bw, "boot-method", boot_method, 4) )
+            goto err;
+        hip04_boot.bootwrapper_phys = boot_method[0];
+        hip04_boot.bootwrapper_size = boot_method[1];
+        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
+        hip04_boot.relocation_entry = boot_method[2];
+        hip04_boot.relocation_size = boot_method[3];
+    }
+    else
+    {
+        msg = "failed to get bootwrapper-size\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-size",
+                                   &hip04_boot.bootwrapper_size) )
+            goto err;
+
+        msg = "failed to get bootwrapper-magic\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-magic",
+                                   &hip04_boot.bootwrapper_magic) )
+            goto err;
+
+        msg = "failed to get relocation-entry\n";
+        if ( !dt_property_read_u32(np, "relocation-entry",
+                                   &hip04_boot.relocation_entry) )
+            goto err;
+
+        msg = "failed to get relocation-size\n";
+        if ( !dt_property_read_u32(np, "relocation-size",
+                                   &hip04_boot.relocation_size) )
+            goto err;
+    }
 
     relocation = ioremap_nocache(hip04_boot.relocation_entry,
                                  hip04_boot.relocation_size);
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:19:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEjp-00013l-M0; Mon, 03 Nov 2014 10:19:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlEjn-00013G-On
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:19:51 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	3E/3C-19763-7C657545; Mon, 03 Nov 2014 10:19:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415009989!7479181!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12980 invoked from network); 3 Nov 2014 10:19:49 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 10:19:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 10:19:48 +0000
Message-Id: <545764D102000078000444F0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 10:19:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
	<54575C3E020000780004440F@mail.emea.novell.com>
	<54575372.7020406@intel.com>
In-Reply-To: <54575372.7020406@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
 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 03.11.14 at 11:05, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 17:43, Jan Beulich wrote:
>>>>> On 03.11.14 at 10:00, <tiejun.chen@intel.com> wrote:
>>> --- a/tools/firmware/hvmloader/Makefile
>>> +++ b/tools/firmware/hvmloader/Makefile
>>> @@ -84,9 +84,12 @@ ROMS += $(SEABIOS_ROM)
>>>   endif
>>>
>>>   .PHONY: all
>>> -all: subdirs-all
>>> +all: subdirs-all .dir
>>
>> Considering uses going forward, I think subdirs-all should depend on
>> .dir (which is being misnamed anyway, presumably due to blindly
>> taking what is in tools/include/Makefile, where a directory _is_ being
>> created). Considering that it's an individual file, the file name would
> 
> You're right.
> 
>> seem quite right to be used as dependency here.
> 
> So what about this?
> 
> .PHONY: all
> all: subdirs-all errno
>      $(MAKE) hvmloader
> 
> errno:
>      ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .

This addresses just one of the points I made.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:19:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEjp-00013l-M0; Mon, 03 Nov 2014 10:19:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlEjn-00013G-On
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:19:51 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	3E/3C-19763-7C657545; Mon, 03 Nov 2014 10:19:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415009989!7479181!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12980 invoked from network); 3 Nov 2014 10:19:49 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 10:19:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 10:19:48 +0000
Message-Id: <545764D102000078000444F0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 10:19:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
	<54575C3E020000780004440F@mail.emea.novell.com>
	<54575372.7020406@intel.com>
In-Reply-To: <54575372.7020406@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
 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 03.11.14 at 11:05, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 17:43, Jan Beulich wrote:
>>>>> On 03.11.14 at 10:00, <tiejun.chen@intel.com> wrote:
>>> --- a/tools/firmware/hvmloader/Makefile
>>> +++ b/tools/firmware/hvmloader/Makefile
>>> @@ -84,9 +84,12 @@ ROMS += $(SEABIOS_ROM)
>>>   endif
>>>
>>>   .PHONY: all
>>> -all: subdirs-all
>>> +all: subdirs-all .dir
>>
>> Considering uses going forward, I think subdirs-all should depend on
>> .dir (which is being misnamed anyway, presumably due to blindly
>> taking what is in tools/include/Makefile, where a directory _is_ being
>> created). Considering that it's an individual file, the file name would
> 
> You're right.
> 
>> seem quite right to be used as dependency here.
> 
> So what about this?
> 
> .PHONY: all
> all: subdirs-all errno
>      $(MAKE) hvmloader
> 
> errno:
>      ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .

This addresses just one of the points I made.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:24:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlEnn-0001bs-QM; Mon, 03 Nov 2014 10:23:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlEnm-0001bn-3Y
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:23:58 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	91/F7-24124-DB757545; Mon, 03 Nov 2014 10:23:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415010234!7480409!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16401 invoked from network); 3 Nov 2014 10:23:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:23:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188833345"
Message-ID: <1415010232.9994.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 3 Nov 2014 10:23:52 +0000
In-Reply-To: <1414602948.2064.11.camel@citrix.com>
References: <1414579268.29975.13.camel@citrix.com>
	<1414601464.2064.9.camel@citrix.com>
	<21585.8227.12267.818642@mariner.uk.xensource.com>
	<1414602948.2064.11.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH OSSTEST v2 00/20] support for ARM32 arndale
 and cubietruck 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

On Wed, 2014-10-29 at 17:15 +0000, Ian Campbell wrote:
> On Wed, 2014-10-29 at 17:13 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH OSSTEST v2 00/20] support for ARM32 arndale and cubietruck platforms"):
> > > Once this set has passed osstest's own push gate I intend to followup
> > > with a mass rerun of ./mg-debian-installer-update and an update to
> > > production-config.
> > 
> > Jolly good.  Assuming the config update is what I expect (just a
> > change to the d-i generation date) you have my (pre-emptive) ack for
> > it.
> 
> Yes, it will be exactly that, thanks.

i.e. the below which I've just now pushed.

> BTW, is there some helper which will call mg-debian-installer-update the
> appropriate number of times with the right args for each arch for a
> production system update?
> 
> AFAIK there is only a helper for standalone mode.

I stuck this helper in there too.

Ian.


commit 4eed3c718ac02dd81dfbee09e8c779fb9f32ec52
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Mon Nov 3 10:20:55 2014 +0000

    TftpDiVersion 2014-11-03
    
    Picks up changes on armhf to include dtbs and more modules in the initrd
    overlay.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

diff --git a/production-config b/production-config
index 2b3ec10..8b2c3e1 100644
--- a/production-config
+++ b/production-config
@@ -68,7 +68,7 @@ TftpPxeDir /
 TftpPxeTemplates %ipaddrhex%/pxelinux.cfg
 
 TftpPxeGroup osstest
-TftpDiVersion 2014-10-20
+TftpDiVersion 2014-11-03
 
 XenUsePath /usr/groups/xencore/systems/bin/xenuse
 XenUseUser osstest



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:24:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlEnn-0001bs-QM; Mon, 03 Nov 2014 10:23:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlEnm-0001bn-3Y
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:23:58 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	91/F7-24124-DB757545; Mon, 03 Nov 2014 10:23:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415010234!7480409!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16401 invoked from network); 3 Nov 2014 10:23:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:23:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188833345"
Message-ID: <1415010232.9994.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 3 Nov 2014 10:23:52 +0000
In-Reply-To: <1414602948.2064.11.camel@citrix.com>
References: <1414579268.29975.13.camel@citrix.com>
	<1414601464.2064.9.camel@citrix.com>
	<21585.8227.12267.818642@mariner.uk.xensource.com>
	<1414602948.2064.11.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH OSSTEST v2 00/20] support for ARM32 arndale
 and cubietruck 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

On Wed, 2014-10-29 at 17:15 +0000, Ian Campbell wrote:
> On Wed, 2014-10-29 at 17:13 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH OSSTEST v2 00/20] support for ARM32 arndale and cubietruck platforms"):
> > > Once this set has passed osstest's own push gate I intend to followup
> > > with a mass rerun of ./mg-debian-installer-update and an update to
> > > production-config.
> > 
> > Jolly good.  Assuming the config update is what I expect (just a
> > change to the d-i generation date) you have my (pre-emptive) ack for
> > it.
> 
> Yes, it will be exactly that, thanks.

i.e. the below which I've just now pushed.

> BTW, is there some helper which will call mg-debian-installer-update the
> appropriate number of times with the right args for each arch for a
> production system update?
> 
> AFAIK there is only a helper for standalone mode.

I stuck this helper in there too.

Ian.


commit 4eed3c718ac02dd81dfbee09e8c779fb9f32ec52
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Mon Nov 3 10:20:55 2014 +0000

    TftpDiVersion 2014-11-03
    
    Picks up changes on armhf to include dtbs and more modules in the initrd
    overlay.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

diff --git a/production-config b/production-config
index 2b3ec10..8b2c3e1 100644
--- a/production-config
+++ b/production-config
@@ -68,7 +68,7 @@ TftpPxeDir /
 TftpPxeTemplates %ipaddrhex%/pxelinux.cfg
 
 TftpPxeGroup osstest
-TftpDiVersion 2014-10-20
+TftpDiVersion 2014-11-03
 
 XenUsePath /usr/groups/xencore/systems/bin/xenuse
 XenUseUser osstest



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:28:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:28:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlErz-0001ts-OE; Mon, 03 Nov 2014 10:28:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlEry-0001tl-9a
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:28:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3D/33-24532-1C857545; Mon, 03 Nov 2014 10:28:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415010494!12373371!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20848 invoked from network); 3 Nov 2014 10:28:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:28:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188834055"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 05:27:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlErL-0006qL-Sr;
	Mon, 03 Nov 2014 10:27:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlErJ-00088e-KZ;
	Mon, 03 Nov 2014 10:27:37 +0000
Date: Mon, 3 Nov 2014 10:27:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31334-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 19449
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31334: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1828384532645399456=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1828384532645399456==
Content-Type: text/plain
Content-Length: 19404
Content-Transfer-Encoding: quoted-printable

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                12d7aacab56e9ef185c3a5512e867bfd3a9504e4
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
People who touched revisions under test:
  Aaron Brown "aaron.f.brown@intel.com"
  Aaron Brown <aaron.f.brown@intel.com>
  Adel Gadllah <adel.gadllah@gmail.com>
  Alan Cox <alan@linux.intel.com>
  Alex Gartrell <agartrell@fb.com>
  Alexander Duyck <alexander.h.duyck@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexandre Belloni <alexandre.belloni@free-electrons.com>
  Alexandre Courbot <acourbot@nvidia.com>
  Alexei Starovoitov <ast@plumgrid.com>
  Andrew Lunn <andrew@lunn.ch>
  Andrew Morton <akpm@linux-foundation.org>
  Andriy Skulysh <askulysh@gmail.com>
  Andr=C3=A1s Mur=C3=A1nyi <muranyia@gmail.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
  Anish Bhatt <anish@chelsio.com>
  Arnaldo Carvalho de Melo <acme@redhat.com>
  Arnd Bergmann <arnd@arndb.de>
  Arturo Borrero <arturo.borrero.glez@gmail.com>
  Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
  Avinash Patil <patila@marvell.com>
  Ben Hutchings <ben@decadent.org.uk>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bjorn Helgaas <bhelgaas@google.com>
  Borislav Petkov <bp@suse.de>
  Brian Silverman <bsilver16384@gmail.com>
  Casey Leedom <leedom@chelsio.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Cathy Luo <cluo@marvell.com>
  Charles Manning <cdhmanning@gmail.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Chin-Ran Lo <crlo@marvell.com>
  Chris Mason <clm@fb.com>
  Christian Vogel <vogelchr@vogel.cx>
  Christoph Lameter <cl@linux.com>
  Christophe Leroy <christophe.leroy@c-s.fr>
  Clemens Ladisch <clemens@ladisch.de>
  Cong Wang <cwang@twopensource.com>
  Cong Wang <xiyou.wangcong@gmail.com>
  Cyril Brulebois <kibi@debian.org>
  Dan Carpenter <dan.carpenter@oracle.com>
  Dan Streetman <ddstreet@ieee.org>
  Dan Williams <dcbw@redhat.com>
  Daniel Borkmann <dborkman@redhat.com>
  Daniel Gl=C3=B6ckner <dg@emlix.com>
  Daniel Lezcano <daniel.lezcano@linaro.org>
  Daniel Mack <daniel@zonque.org>
  Daniel Wagner <daniel.wagner@bmw-carit.de>
  Daniele Palmas <dnlplm@gmail.com>
  Darrick J. Wong <darrick.wong@oracle.com>
  Dave Jones <davej@redhat.com>
  David Cohen <david.a.cohen@linux.intel.com>
  David Rientjes <rientjes@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  David Vrabel <david.vrabel@citrix.com>
  Davidlohr Bueso <dave@stgolabs.net>
  Davidlohr Bueso <dbueso@suse.de>
  Denis Ciocca <denis.ciocca@st.com>
  Dexuan Cui <decui@microsoft.com>
  Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
  Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Dmitry Monakhov <dmonakhov@openvz.org>
  Dmitry Torokhov <dmitry.torokhov@gmail.com>
  Dwight Engen <dwight.engen@oracle.com>
  Edward Cree <ecree@solarflare.com>
  Eli Cohen <eli@dev.mellanox.co.il>
  Eli Cohen <eli@mellanox.com>
  Emil Tantilov <emil.s.tantilov@intel.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Eric B Munson <emunson@akamai.com>
  Eric Dumazet <edumazet@google.com>
  Eric Paris <eparis@redhat.com>
  Eric Rannaud <e@nanocritical.com>
  Fabian Frederick <fabf@skynet.be>
  Fabio Estevam <fabio.estevam@freescale.com>
  Felipe Balbi <balbi@ti.com>
  Felix Fietkau <nbd@openwrt.org>
  Filipe Manana <fdmanana@suse.com>
  Florian Fainelli <f.fainelli@gmail.com>
  Florian Westphal <fw@strlen.de>
  Francesco Ruggeri <fruggeri@arista.com>
  Francesco Ruggeri <fruggeri@aristanetworks.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert+renesas@glider.be>
  Geert Uytterhoeven <geert@linux-m68k.org>
  George Cherian <george.cherian@ti.com>
  Govindarajulu Varadarajan <_govind@gmx.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Guenter Roeck <linux@roeck-us.net>
  H. Nikolaus Schaller <hns@goldelico.com>
  H. Peter Anvin <hpa@linux.intel.com>
  Haim Dreyfuss <haim.dreyfuss@intel.com>
  Haiyang Zhang <haiyangz@microsoft.com>
  Hannes Frederic Sowa <hannes@stressinduktion.org>
  Hans de Goede <hdegoede@redhat.com>
  Hariprasad Shenai <hariprasad@chelsio.com>
  Hauke Mehrtens <hauke@hauke-m.de>
  Hayes Wang <hayeswang@realtek.com>
  hayeswang <hayeswang@realtek.com>
  Heikki Krogerus <heikki.krogerus@linux.intel.com>
  Heiko Schocher <hs@denx.de>
  Herbert Xu <herbert@gondor.apana.org.au>
  Houcheng Lin <houcheng@gmail.com>
  Ian Abbott <abbotti@mev.co.uk>
  Ian Morgan <imorgan@primordial.ca>
  Ian Munsie <imunsie@au1.ibm.com>
  Imre Deak <imre.deak@intel.com>
  Ingo Molnar <mingo@kernel.org>
  Jack Pham <jackp@codeaurora.org>
  James Morris <james.l.morris@oracle.com>
  Jan Kara <jack@suse.cz>
  Jan-Benedict Glaw <jbglaw@lug-owl.de>
  Jason Gerecke <jason.gerecke@wacom.com>
  Jason Gerecke <killertofu@gmail.com>
  Javier Martinez Canillas <javier.martinez@collabora.co.uk>
  Jay Vosburgh <jay.vosburgh@canonical.com>
  Jean Pihet <jean.pihet@linaro.org>
  Jeff Epler <jepler@unpythonic.net>	# on v3.14-rt
  Jeff Kirsher <jeffrey.t.kirsher@intel.com>
  Jeff Mahoney <jeffm@suse.com>
  Jens Axboe <axboe@fb.com>
  Jeremy Kerr <jk@ozlabs.org>
  Jerry Hoemann <jerry.hoemann@hp.com>
  Jes Sorensen <Jes.Sorensen@redhat.com>
  Jiang Liu <jiang.liu@linux.intel.com>
  Jim Davis <jim.epost@gmail.com>
  Jim Young <jamesx.m.young@intel.com>
  Jiri Kosina <jkosina@suse.cz>
  Jiri Olsa <jolsa@kernel.org>
  Joe Perches <joe@perches.com>
  Johan Hovold <johan@kernel.org>
  Johannes Berg <johannes.berg@intel.com>
  Johannes Weiner <hannes@cmpxchg.org>
  John W. Linville <linville@tuxdriver.com>
  Jon Cooper <jcooper@solarflare.com>
  Jon Maloy <jon.maloy@ericsson.com>
  Jonathan Cameron <jic23@kernel.org>
  Jonathan Corbet <corbet@lwn.net>
  Joonsoo Kim <iamjoonsoo.kim@lge.com>
  Josef Bacik <jbacik@fb.com>
  Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
  Junwei Zhang <linggao.zjw@alibaba-inc.com>
  Juri Lelli <juri.lelli@arm.com>
  Kailang Yang <kailang@realtek.com>
  Kamal Mostafa <kamal@canonical.com>
  Kan Liang <kan.liang@intel.com>
  Karl Beldan <karl.beldan@rivierawaves.com>
  Karsten Wiese <fzuuzf@googlemail.com>
  Kees Cook <keescook@chromium.org>
  Ken Chen <kenchen@google.com>
  Kevin Fenzi <kevin@scrye.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Kirill Smelkov <kirr@nexedi.com>
  Kirill Tkhai <ktkhai@parallels.com>
  Konstantin Khlebnikov <k.khlebnikov@samsung.com>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lars-Peter Clausen <lars@metafoo.de>
  Laurent Pinchart <laurent.pinchart@ideasonboard.com>
  Len Sorensen <lsorense@csclub.uwaterloo.ca>
  Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  LEROY Christophe <christophe.leroy@c-s.fr>
  Li RongQing <roy.qing.li@gmail.com>
  Liad Kaufman <liad.kaufman@intel.com>
  Liam Girdwood <liam.r.girdwood@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Linus Walleij <linus.walleij@linaro.org>
  Lubomir Rintel <lkundrak@v3.sk>
  Lucas Stach <l.stach@pengutronix.de>
  Luciano Coelho <luciano.coelho@intel.com>
  Lv Zheng <lv.zheng@intel.com>
  Maarten ter Huurne <maarten@treewalker.org>
  Maciej W. Rozycki <macro@linux-mips.org>
  Marc Yang <yangyang@marvell.com>
  Marc Zyngier <marc.zyngier@arm.com>
  Marcelo Leitner <mleitner@redhat.com>
  Marcelo Ricardo Leitner <mleitner@redhat.com>
  Marek Belisko <marek@goldelico.com>
  Marek Szyprowski <m.szyprowski@samsung.com>
  Mark Brown <broonie@kernel.org>
  Mark Rustad <mark.d.rustad@intel.com>
  Mark Rutland <mark.rutland@arm.com>
  Martin K. Petersen <martin.petersen@oracle.com>
  Martin Schwidefsky <schwidefsky@de.ibm.com>
  Martin Zhang <martinbj2008@gmail.com>
  Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
  Masanari Iida <standby24x7@gmail.com>
  Mathias Krause <minipli@googlemail.com>
  Matti Gottlieb <matti.gottlieb@intel.com>
  Mauro Carvalho Chehab <mchehab@osg.samsung.com>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael L. Semon <mlsemon35@gmail.com>
  Michal Hocko <mhocko@suse.cz>
  Michal Nazarewicz <mina86@mina86.com>
  Michal Simek <michal.simek@xilinx.com>
  Mika Westerberg <mika.westerberg@linux.intel.com>
  Mikulas Patocka <mpatocka@redhat.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Minchan Kim <minchan@kernel.org>
  Ming Lei <tom.leiming@gmail.com>
  Mugunthan V N <mugunthanvnm@ti.com>
  Namhyung Kim <namhyung@kernel.org>
  Nathan Fontenot <nfont@linux.vnet.ibm.com>
  Nathaniel Ting <nathaniel.ting@silabs.com>
  Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Nikolay Aleksandrov <nikolay@redhat.com>
  Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
  Oleg Nesterov <oleg@redhat.com>
  Oliver Neukum <oneukum@suse.de>
  Olivier Blin <olivier.blin@softathome.com>
  Olivier Gay <ogay@logitech.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Pablo Neira Ayuso <pablo@netfilter.org>
  Patrick McLean <chutzpah@gentoo.org>
  Paul Cercueil <paul@crapouillou.net>
  Paul E. McKenney <paulmck@linux.vnet.ibm.com>
  Paul Zimmerman <paulz@synopsys.com>
  Pavel Machek <pavel@denx.de>
  Pavel Machek <pavel@ucw.cz>
  Pavitrakumar Managutte <pavitra1729@gmail.com>
  Perry Hung <iperry@gmail.com>
  Peter Chen <peter.chen@freescale.com>
  Peter Foley <pefoley2@pefoley.com>
  Peter Hurley <peter@hurleysoftware.com>
  Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Peter Zijlstra <peterz@infradead.org>
  Phil Schmitt <phillip.j.schmitt@intel.com>
  Philipp Zabel <p.zabel@pengutronix.de>
  Plus Chen <pchen@marvell.com>
  Pranith Kumar <bobby.prani@gmail.com>
  Pravin B Shelar <pshelar@nicira.com>
  Qiuxu Zhuo <qiuxu.zhuo@intel.com>
  Rabin Vincent <rabin@rab.in>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
  Randy Dunlap <rdunlap@infradead.org>
  Richard Cochran <richardcochran@gmail.com>
  Richard Weinberger <richard@nod.at>
  Richard Zhu <r65037@freescale.com>
  Richard Zhu <richard.zhu@freescale.com>
  Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
  Riku Voipio <riku.voipio@linaro.org>
  Robert Baldyga <r.baldyga@samsung.com>
  Robert Elliott <elliott@hp.com>
  Robin van der Gracht <robin@protonic.nl>
  Roger Quadros <rogerq@ti.com>
  Roman Gushchin <klamm@yandex-team.ru>
  Sabrina Dubroca <sd@queasysnail.net>
  Sasha Levin <sasha.levin@oracle.com>
  Sathya Perla <sathya.perla@emulex.com>
  Sebastian Andrzej Siewior <bigeasy@linutronix.de>
  Serge E. Hallyn <serge.hallyn@ubuntu.com>
  Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
  Simon Horman <horms@verge.net.au>
  Simon Horman <simon.horman@netronome.com>
  Stanimir Varbanov <svarbanov@mm-sol.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Steven Noonan <steven@uplinklabs.net>
  Steven Rostedt <rostedt@goodmis.org>
  Sudeep Holla <sudeep.holla@arm.com>
  Sudip Mukherjee <sudip@vectorindia.org>
  Sudip Mukherjee <sudipm.mukherjee@gmail.com>
  Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Takashi Iwai <tiwai@suse.de>
  Takashi Sakamoto <o-takashi@sakamocchi.jp>
  Tej Parkash <tej.parkash@qlogic.com>
  Theodore Ts'o <tytso@mit.edu>
  Thomas Gleixner <tglx@linutronix.de>
  Thomas Graf <tgraf@suug.ch>
  Tobias Klauser <tklauser@distanz.ch>
  Tom Herbert <therbert@google.com>
  Tom Lendacky <thomas.lendacky@amd.com>
  Tomi Valkeinen <tomi.valkeinen@ti.com>
  Tony Battersby <tonyb@cybernetics.com>
  Tony Lindgren <tony@atomide.com>
  Torsten Fleischer <to-fleischer@t-online.de>
  Vince Bridgers <vbridger@opensource.altera.com>
  Viresh Kumar <viresh.kumar@linaro.org>
  Vlastimil Babka <vbabka@suse.cz>
  WANG Chao <chaowang@redhat.com>
  WANG Cong <xiyou.wangcong@gmail.com>
  Wang Nan <wangnan0@huawei.com>
  Wei Liu <wei.liu2@citrix.com>
  Weijie Yang <weijie.yang@samsung.com>
  Yanko Kaneti <yaneti@declera.com>
  Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
  Ying Xue <ying.xue@windriver.com>
  Yu Zhao <yuzhao@google.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============1828384532645399456==--

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:28:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:28:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlErz-0001ts-OE; Mon, 03 Nov 2014 10:28:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlEry-0001tl-9a
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:28:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3D/33-24532-1C857545; Mon, 03 Nov 2014 10:28:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415010494!12373371!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20848 invoked from network); 3 Nov 2014 10:28:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:28:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188834055"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 05:27:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlErL-0006qL-Sr;
	Mon, 03 Nov 2014 10:27:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlErJ-00088e-KZ;
	Mon, 03 Nov 2014 10:27:37 +0000
Date: Mon, 3 Nov 2014 10:27:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31334-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 19449
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31334: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1828384532645399456=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1828384532645399456==
Content-Type: text/plain
Content-Length: 19404
Content-Transfer-Encoding: quoted-printable

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                12d7aacab56e9ef185c3a5512e867bfd3a9504e4
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
People who touched revisions under test:
  Aaron Brown "aaron.f.brown@intel.com"
  Aaron Brown <aaron.f.brown@intel.com>
  Adel Gadllah <adel.gadllah@gmail.com>
  Alan Cox <alan@linux.intel.com>
  Alex Gartrell <agartrell@fb.com>
  Alexander Duyck <alexander.h.duyck@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexandre Belloni <alexandre.belloni@free-electrons.com>
  Alexandre Courbot <acourbot@nvidia.com>
  Alexei Starovoitov <ast@plumgrid.com>
  Andrew Lunn <andrew@lunn.ch>
  Andrew Morton <akpm@linux-foundation.org>
  Andriy Skulysh <askulysh@gmail.com>
  Andr=C3=A1s Mur=C3=A1nyi <muranyia@gmail.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
  Anish Bhatt <anish@chelsio.com>
  Arnaldo Carvalho de Melo <acme@redhat.com>
  Arnd Bergmann <arnd@arndb.de>
  Arturo Borrero <arturo.borrero.glez@gmail.com>
  Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
  Avinash Patil <patila@marvell.com>
  Ben Hutchings <ben@decadent.org.uk>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bjorn Helgaas <bhelgaas@google.com>
  Borislav Petkov <bp@suse.de>
  Brian Silverman <bsilver16384@gmail.com>
  Casey Leedom <leedom@chelsio.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Cathy Luo <cluo@marvell.com>
  Charles Manning <cdhmanning@gmail.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Chin-Ran Lo <crlo@marvell.com>
  Chris Mason <clm@fb.com>
  Christian Vogel <vogelchr@vogel.cx>
  Christoph Lameter <cl@linux.com>
  Christophe Leroy <christophe.leroy@c-s.fr>
  Clemens Ladisch <clemens@ladisch.de>
  Cong Wang <cwang@twopensource.com>
  Cong Wang <xiyou.wangcong@gmail.com>
  Cyril Brulebois <kibi@debian.org>
  Dan Carpenter <dan.carpenter@oracle.com>
  Dan Streetman <ddstreet@ieee.org>
  Dan Williams <dcbw@redhat.com>
  Daniel Borkmann <dborkman@redhat.com>
  Daniel Gl=C3=B6ckner <dg@emlix.com>
  Daniel Lezcano <daniel.lezcano@linaro.org>
  Daniel Mack <daniel@zonque.org>
  Daniel Wagner <daniel.wagner@bmw-carit.de>
  Daniele Palmas <dnlplm@gmail.com>
  Darrick J. Wong <darrick.wong@oracle.com>
  Dave Jones <davej@redhat.com>
  David Cohen <david.a.cohen@linux.intel.com>
  David Rientjes <rientjes@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  David Vrabel <david.vrabel@citrix.com>
  Davidlohr Bueso <dave@stgolabs.net>
  Davidlohr Bueso <dbueso@suse.de>
  Denis Ciocca <denis.ciocca@st.com>
  Dexuan Cui <decui@microsoft.com>
  Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
  Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Dmitry Monakhov <dmonakhov@openvz.org>
  Dmitry Torokhov <dmitry.torokhov@gmail.com>
  Dwight Engen <dwight.engen@oracle.com>
  Edward Cree <ecree@solarflare.com>
  Eli Cohen <eli@dev.mellanox.co.il>
  Eli Cohen <eli@mellanox.com>
  Emil Tantilov <emil.s.tantilov@intel.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Eric B Munson <emunson@akamai.com>
  Eric Dumazet <edumazet@google.com>
  Eric Paris <eparis@redhat.com>
  Eric Rannaud <e@nanocritical.com>
  Fabian Frederick <fabf@skynet.be>
  Fabio Estevam <fabio.estevam@freescale.com>
  Felipe Balbi <balbi@ti.com>
  Felix Fietkau <nbd@openwrt.org>
  Filipe Manana <fdmanana@suse.com>
  Florian Fainelli <f.fainelli@gmail.com>
  Florian Westphal <fw@strlen.de>
  Francesco Ruggeri <fruggeri@arista.com>
  Francesco Ruggeri <fruggeri@aristanetworks.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert+renesas@glider.be>
  Geert Uytterhoeven <geert@linux-m68k.org>
  George Cherian <george.cherian@ti.com>
  Govindarajulu Varadarajan <_govind@gmx.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Guenter Roeck <linux@roeck-us.net>
  H. Nikolaus Schaller <hns@goldelico.com>
  H. Peter Anvin <hpa@linux.intel.com>
  Haim Dreyfuss <haim.dreyfuss@intel.com>
  Haiyang Zhang <haiyangz@microsoft.com>
  Hannes Frederic Sowa <hannes@stressinduktion.org>
  Hans de Goede <hdegoede@redhat.com>
  Hariprasad Shenai <hariprasad@chelsio.com>
  Hauke Mehrtens <hauke@hauke-m.de>
  Hayes Wang <hayeswang@realtek.com>
  hayeswang <hayeswang@realtek.com>
  Heikki Krogerus <heikki.krogerus@linux.intel.com>
  Heiko Schocher <hs@denx.de>
  Herbert Xu <herbert@gondor.apana.org.au>
  Houcheng Lin <houcheng@gmail.com>
  Ian Abbott <abbotti@mev.co.uk>
  Ian Morgan <imorgan@primordial.ca>
  Ian Munsie <imunsie@au1.ibm.com>
  Imre Deak <imre.deak@intel.com>
  Ingo Molnar <mingo@kernel.org>
  Jack Pham <jackp@codeaurora.org>
  James Morris <james.l.morris@oracle.com>
  Jan Kara <jack@suse.cz>
  Jan-Benedict Glaw <jbglaw@lug-owl.de>
  Jason Gerecke <jason.gerecke@wacom.com>
  Jason Gerecke <killertofu@gmail.com>
  Javier Martinez Canillas <javier.martinez@collabora.co.uk>
  Jay Vosburgh <jay.vosburgh@canonical.com>
  Jean Pihet <jean.pihet@linaro.org>
  Jeff Epler <jepler@unpythonic.net>	# on v3.14-rt
  Jeff Kirsher <jeffrey.t.kirsher@intel.com>
  Jeff Mahoney <jeffm@suse.com>
  Jens Axboe <axboe@fb.com>
  Jeremy Kerr <jk@ozlabs.org>
  Jerry Hoemann <jerry.hoemann@hp.com>
  Jes Sorensen <Jes.Sorensen@redhat.com>
  Jiang Liu <jiang.liu@linux.intel.com>
  Jim Davis <jim.epost@gmail.com>
  Jim Young <jamesx.m.young@intel.com>
  Jiri Kosina <jkosina@suse.cz>
  Jiri Olsa <jolsa@kernel.org>
  Joe Perches <joe@perches.com>
  Johan Hovold <johan@kernel.org>
  Johannes Berg <johannes.berg@intel.com>
  Johannes Weiner <hannes@cmpxchg.org>
  John W. Linville <linville@tuxdriver.com>
  Jon Cooper <jcooper@solarflare.com>
  Jon Maloy <jon.maloy@ericsson.com>
  Jonathan Cameron <jic23@kernel.org>
  Jonathan Corbet <corbet@lwn.net>
  Joonsoo Kim <iamjoonsoo.kim@lge.com>
  Josef Bacik <jbacik@fb.com>
  Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
  Junwei Zhang <linggao.zjw@alibaba-inc.com>
  Juri Lelli <juri.lelli@arm.com>
  Kailang Yang <kailang@realtek.com>
  Kamal Mostafa <kamal@canonical.com>
  Kan Liang <kan.liang@intel.com>
  Karl Beldan <karl.beldan@rivierawaves.com>
  Karsten Wiese <fzuuzf@googlemail.com>
  Kees Cook <keescook@chromium.org>
  Ken Chen <kenchen@google.com>
  Kevin Fenzi <kevin@scrye.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Kirill Smelkov <kirr@nexedi.com>
  Kirill Tkhai <ktkhai@parallels.com>
  Konstantin Khlebnikov <k.khlebnikov@samsung.com>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lars-Peter Clausen <lars@metafoo.de>
  Laurent Pinchart <laurent.pinchart@ideasonboard.com>
  Len Sorensen <lsorense@csclub.uwaterloo.ca>
  Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  LEROY Christophe <christophe.leroy@c-s.fr>
  Li RongQing <roy.qing.li@gmail.com>
  Liad Kaufman <liad.kaufman@intel.com>
  Liam Girdwood <liam.r.girdwood@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Linus Walleij <linus.walleij@linaro.org>
  Lubomir Rintel <lkundrak@v3.sk>
  Lucas Stach <l.stach@pengutronix.de>
  Luciano Coelho <luciano.coelho@intel.com>
  Lv Zheng <lv.zheng@intel.com>
  Maarten ter Huurne <maarten@treewalker.org>
  Maciej W. Rozycki <macro@linux-mips.org>
  Marc Yang <yangyang@marvell.com>
  Marc Zyngier <marc.zyngier@arm.com>
  Marcelo Leitner <mleitner@redhat.com>
  Marcelo Ricardo Leitner <mleitner@redhat.com>
  Marek Belisko <marek@goldelico.com>
  Marek Szyprowski <m.szyprowski@samsung.com>
  Mark Brown <broonie@kernel.org>
  Mark Rustad <mark.d.rustad@intel.com>
  Mark Rutland <mark.rutland@arm.com>
  Martin K. Petersen <martin.petersen@oracle.com>
  Martin Schwidefsky <schwidefsky@de.ibm.com>
  Martin Zhang <martinbj2008@gmail.com>
  Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
  Masanari Iida <standby24x7@gmail.com>
  Mathias Krause <minipli@googlemail.com>
  Matti Gottlieb <matti.gottlieb@intel.com>
  Mauro Carvalho Chehab <mchehab@osg.samsung.com>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael L. Semon <mlsemon35@gmail.com>
  Michal Hocko <mhocko@suse.cz>
  Michal Nazarewicz <mina86@mina86.com>
  Michal Simek <michal.simek@xilinx.com>
  Mika Westerberg <mika.westerberg@linux.intel.com>
  Mikulas Patocka <mpatocka@redhat.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Minchan Kim <minchan@kernel.org>
  Ming Lei <tom.leiming@gmail.com>
  Mugunthan V N <mugunthanvnm@ti.com>
  Namhyung Kim <namhyung@kernel.org>
  Nathan Fontenot <nfont@linux.vnet.ibm.com>
  Nathaniel Ting <nathaniel.ting@silabs.com>
  Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Nikolay Aleksandrov <nikolay@redhat.com>
  Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
  Oleg Nesterov <oleg@redhat.com>
  Oliver Neukum <oneukum@suse.de>
  Olivier Blin <olivier.blin@softathome.com>
  Olivier Gay <ogay@logitech.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Pablo Neira Ayuso <pablo@netfilter.org>
  Patrick McLean <chutzpah@gentoo.org>
  Paul Cercueil <paul@crapouillou.net>
  Paul E. McKenney <paulmck@linux.vnet.ibm.com>
  Paul Zimmerman <paulz@synopsys.com>
  Pavel Machek <pavel@denx.de>
  Pavel Machek <pavel@ucw.cz>
  Pavitrakumar Managutte <pavitra1729@gmail.com>
  Perry Hung <iperry@gmail.com>
  Peter Chen <peter.chen@freescale.com>
  Peter Foley <pefoley2@pefoley.com>
  Peter Hurley <peter@hurleysoftware.com>
  Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Peter Zijlstra <peterz@infradead.org>
  Phil Schmitt <phillip.j.schmitt@intel.com>
  Philipp Zabel <p.zabel@pengutronix.de>
  Plus Chen <pchen@marvell.com>
  Pranith Kumar <bobby.prani@gmail.com>
  Pravin B Shelar <pshelar@nicira.com>
  Qiuxu Zhuo <qiuxu.zhuo@intel.com>
  Rabin Vincent <rabin@rab.in>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
  Randy Dunlap <rdunlap@infradead.org>
  Richard Cochran <richardcochran@gmail.com>
  Richard Weinberger <richard@nod.at>
  Richard Zhu <r65037@freescale.com>
  Richard Zhu <richard.zhu@freescale.com>
  Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
  Riku Voipio <riku.voipio@linaro.org>
  Robert Baldyga <r.baldyga@samsung.com>
  Robert Elliott <elliott@hp.com>
  Robin van der Gracht <robin@protonic.nl>
  Roger Quadros <rogerq@ti.com>
  Roman Gushchin <klamm@yandex-team.ru>
  Sabrina Dubroca <sd@queasysnail.net>
  Sasha Levin <sasha.levin@oracle.com>
  Sathya Perla <sathya.perla@emulex.com>
  Sebastian Andrzej Siewior <bigeasy@linutronix.de>
  Serge E. Hallyn <serge.hallyn@ubuntu.com>
  Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
  Simon Horman <horms@verge.net.au>
  Simon Horman <simon.horman@netronome.com>
  Stanimir Varbanov <svarbanov@mm-sol.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Steven Noonan <steven@uplinklabs.net>
  Steven Rostedt <rostedt@goodmis.org>
  Sudeep Holla <sudeep.holla@arm.com>
  Sudip Mukherjee <sudip@vectorindia.org>
  Sudip Mukherjee <sudipm.mukherjee@gmail.com>
  Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Takashi Iwai <tiwai@suse.de>
  Takashi Sakamoto <o-takashi@sakamocchi.jp>
  Tej Parkash <tej.parkash@qlogic.com>
  Theodore Ts'o <tytso@mit.edu>
  Thomas Gleixner <tglx@linutronix.de>
  Thomas Graf <tgraf@suug.ch>
  Tobias Klauser <tklauser@distanz.ch>
  Tom Herbert <therbert@google.com>
  Tom Lendacky <thomas.lendacky@amd.com>
  Tomi Valkeinen <tomi.valkeinen@ti.com>
  Tony Battersby <tonyb@cybernetics.com>
  Tony Lindgren <tony@atomide.com>
  Torsten Fleischer <to-fleischer@t-online.de>
  Vince Bridgers <vbridger@opensource.altera.com>
  Viresh Kumar <viresh.kumar@linaro.org>
  Vlastimil Babka <vbabka@suse.cz>
  WANG Chao <chaowang@redhat.com>
  WANG Cong <xiyou.wangcong@gmail.com>
  Wang Nan <wangnan0@huawei.com>
  Wei Liu <wei.liu2@citrix.com>
  Weijie Yang <weijie.yang@samsung.com>
  Yanko Kaneti <yaneti@declera.com>
  Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
  Ying Xue <ying.xue@windriver.com>
  Yu Zhao <yuzhao@google.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============1828384532645399456==--

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:31:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:31:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEuw-00023T-Eh; Mon, 03 Nov 2014 10:31:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1XlEuv-00023N-4m
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:31:21 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	D8/22-29352-87957545; Mon, 03 Nov 2014 10:31:20 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415010679!10853958!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19491 invoked from network); 3 Nov 2014 10:31:19 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 3 Nov 2014 10:31:19 -0000
Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80)
	(envelope-from <tglx@linutronix.de>)
	id 1XlEug-0004QE-7A; Mon, 03 Nov 2014 11:31:06 +0100
Date: Mon, 3 Nov 2014 11:31:04 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Juergen Gross <jgross@suse.com>
In-Reply-To: <54572182.8080005@suse.com>
Message-ID: <alpine.DEB.2.11.1411031122150.5308@nanos>
References: <1414764033-30011-1-git-send-email-jgross@suse.com>
	<1414764033-30011-11-git-send-email-jgross@suse.com>
	<alpine.DEB.2.11.1410311617260.5308@nanos>
	<54572182.8080005@suse.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH 10/17] x86: Use new cache mode type in
 setting page attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 3 Nov 2014, Juergen Gross wrote:
> On 10/31/2014 04:34 PM, Thomas Gleixner wrote:
> > On Fri, 31 Oct 2014, Juergen Gross wrote:
> > > --- a/arch/x86/mm/pageattr.c
> > > +++ b/arch/x86/mm/pageattr.c
> > > @@ -1304,12 +1304,6 @@ static int __change_page_attr_set_clr(struct
> > > cpa_data *cpa, int checkalias)
> > >   	return 0;
> > >   }
> > > 
> > > -static inline int cache_attr(pgprot_t attr)
> > > -{
> > > -	return pgprot_val(attr) &
> > > -		(_PAGE_PAT | _PAGE_PAT_LARGE | _PAGE_PWT | _PAGE_PCD);
> > > -}
> > > -
> > >   static int change_page_attr_set_clr(unsigned long *addr, int numpages,
> > >   				    pgprot_t mask_set, pgprot_t mask_clr,
> > >   				    int force_split, int in_flag,
> > > @@ -1390,7 +1384,7 @@ static int change_page_attr_set_clr(unsigned long
> > > *addr, int numpages,
> > >   	 * No need to flush, when we did not set any of the caching
> > >   	 * attributes:
> > >   	 */
> > > -	cache = cache_attr(mask_set);
> > > +	cache = !!pgprot2cachemode(mask_set);
> > 
> > So this loses _PAGE_PAT_LARGE, right ?
> 
> change_page_attr_set_clr() is never called with _PAGE_PAT_LARGE set in
> mask, so this is no problem.

Ok. The we should have a separate patch which removes it first with a
proper explanation and then the one which uses pgprot2cachemode().

> BTW: correct handling of the PAT bit for large pages is added in
> patch 15. There have been places in the kernel respecting
> _PAGE_PAT_LARGE, but handling has never been complete up to now.

Yes. I've seen that.
 
> > >   int _set_memory_wb(unsigned long addr, int numpages)
> > >   {
> > > +	/* WB cache mode is hard wired to all cache attribute bits being 0 */
> > 
> > I like the comment, but shouldn't we compile time check that
> > assumption somewhere?
> 
> There is a comment in patch 1 where the page_cache_mode enum is set up.
> The translation functions between page_cache_mode and protection values
> have a special check for "0" built in. Isn't this enough?
> 
> BTW: How would you check this assumption at compile time? The
> translation between WB cache mode and protection values is done only
> dynamically...

Indeed.

Thanks,

	tglx

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:31:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:31:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEuw-00023T-Eh; Mon, 03 Nov 2014 10:31:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1XlEuv-00023N-4m
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:31:21 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	D8/22-29352-87957545; Mon, 03 Nov 2014 10:31:20 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415010679!10853958!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19491 invoked from network); 3 Nov 2014 10:31:19 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 3 Nov 2014 10:31:19 -0000
Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80)
	(envelope-from <tglx@linutronix.de>)
	id 1XlEug-0004QE-7A; Mon, 03 Nov 2014 11:31:06 +0100
Date: Mon, 3 Nov 2014 11:31:04 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Juergen Gross <jgross@suse.com>
In-Reply-To: <54572182.8080005@suse.com>
Message-ID: <alpine.DEB.2.11.1411031122150.5308@nanos>
References: <1414764033-30011-1-git-send-email-jgross@suse.com>
	<1414764033-30011-11-git-send-email-jgross@suse.com>
	<alpine.DEB.2.11.1410311617260.5308@nanos>
	<54572182.8080005@suse.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH 10/17] x86: Use new cache mode type in
 setting page attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 3 Nov 2014, Juergen Gross wrote:
> On 10/31/2014 04:34 PM, Thomas Gleixner wrote:
> > On Fri, 31 Oct 2014, Juergen Gross wrote:
> > > --- a/arch/x86/mm/pageattr.c
> > > +++ b/arch/x86/mm/pageattr.c
> > > @@ -1304,12 +1304,6 @@ static int __change_page_attr_set_clr(struct
> > > cpa_data *cpa, int checkalias)
> > >   	return 0;
> > >   }
> > > 
> > > -static inline int cache_attr(pgprot_t attr)
> > > -{
> > > -	return pgprot_val(attr) &
> > > -		(_PAGE_PAT | _PAGE_PAT_LARGE | _PAGE_PWT | _PAGE_PCD);
> > > -}
> > > -
> > >   static int change_page_attr_set_clr(unsigned long *addr, int numpages,
> > >   				    pgprot_t mask_set, pgprot_t mask_clr,
> > >   				    int force_split, int in_flag,
> > > @@ -1390,7 +1384,7 @@ static int change_page_attr_set_clr(unsigned long
> > > *addr, int numpages,
> > >   	 * No need to flush, when we did not set any of the caching
> > >   	 * attributes:
> > >   	 */
> > > -	cache = cache_attr(mask_set);
> > > +	cache = !!pgprot2cachemode(mask_set);
> > 
> > So this loses _PAGE_PAT_LARGE, right ?
> 
> change_page_attr_set_clr() is never called with _PAGE_PAT_LARGE set in
> mask, so this is no problem.

Ok. The we should have a separate patch which removes it first with a
proper explanation and then the one which uses pgprot2cachemode().

> BTW: correct handling of the PAT bit for large pages is added in
> patch 15. There have been places in the kernel respecting
> _PAGE_PAT_LARGE, but handling has never been complete up to now.

Yes. I've seen that.
 
> > >   int _set_memory_wb(unsigned long addr, int numpages)
> > >   {
> > > +	/* WB cache mode is hard wired to all cache attribute bits being 0 */
> > 
> > I like the comment, but shouldn't we compile time check that
> > assumption somewhere?
> 
> There is a comment in patch 1 where the page_cache_mode enum is set up.
> The translation functions between page_cache_mode and protection values
> have a special check for "0" built in. Isn't this enough?
> 
> BTW: How would you check this assumption at compile time? The
> translation between WB cache mode and protection values is done only
> dynamically...

Indeed.

Thanks,

	tglx

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:31:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:31:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEvT-000287-1m; Mon, 03 Nov 2014 10:31:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1XlEvR-00027k-DN
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:31:53 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	29/76-02699-89957545; Mon, 03 Nov 2014 10:31:52 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415010711!12181768!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20325 invoked from network); 3 Nov 2014 10:31:52 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 3 Nov 2014 10:31:52 -0000
Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80)
	(envelope-from <tglx@linutronix.de>)
	id 1XlEvC-0004RO-LH; Mon, 03 Nov 2014 11:31:38 +0100
Date: Mon, 3 Nov 2014 11:31:37 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Juergen Gross <jgross@suse.com>
In-Reply-To: <54572256.5050707@suse.com>
Message-ID: <alpine.DEB.2.11.1411031131190.5308@nanos>
References: <1414764033-30011-1-git-send-email-jgross@suse.com>
	<1414764033-30011-2-git-send-email-jgross@suse.com>
	<20141031194207.GA15367@pd.tnic>
	<20141031202322.GB15935@laptop.dumpdata.com>
	<20141031203554.GA15363@pd.tnic> <54572256.5050707@suse.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	Borislav Petkov <bp@alien8.de>, david.vrabel@citrix.com,
	jbeulich@suse.com, hpa@zytor.com, bhelgaas@google.com,
	plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH 01/17] x86: Make page cache mode a real 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, 3 Nov 2014, Juergen Gross wrote:
> On 10/31/2014 09:35 PM, Borislav Petkov wrote:
> > On Fri, Oct 31, 2014 at 04:23:22PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> > > > > Signed-off-by: Juergen Gross <jgross@suse.com>
> > > > 
> > > > Just a clarification question: how is one to understand this attribution
> > > > here? Is Stefan the original author, was he a reviewer, or? Because this
> > > > SOB chain is misleading...
> > > 
> > > He was the first then Juergen took over. Should the SOB order be inversed?
> > 
> > Well, I'd say:
> > 
> > Originally-by: Stefan...
> > 
> > or
> > 
> > Based-on-patch-by: Stefan...
> 
> I think this would fit best.
> 
> Shall I respin another version modifying the SOB to above?

That would be appreciated.

Thanks,

	tglx

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:31:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:31:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEvT-000287-1m; Mon, 03 Nov 2014 10:31:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1XlEvR-00027k-DN
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:31:53 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	29/76-02699-89957545; Mon, 03 Nov 2014 10:31:52 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415010711!12181768!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20325 invoked from network); 3 Nov 2014 10:31:52 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 3 Nov 2014 10:31:52 -0000
Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80)
	(envelope-from <tglx@linutronix.de>)
	id 1XlEvC-0004RO-LH; Mon, 03 Nov 2014 11:31:38 +0100
Date: Mon, 3 Nov 2014 11:31:37 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Juergen Gross <jgross@suse.com>
In-Reply-To: <54572256.5050707@suse.com>
Message-ID: <alpine.DEB.2.11.1411031131190.5308@nanos>
References: <1414764033-30011-1-git-send-email-jgross@suse.com>
	<1414764033-30011-2-git-send-email-jgross@suse.com>
	<20141031194207.GA15367@pd.tnic>
	<20141031202322.GB15935@laptop.dumpdata.com>
	<20141031203554.GA15363@pd.tnic> <54572256.5050707@suse.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	Borislav Petkov <bp@alien8.de>, david.vrabel@citrix.com,
	jbeulich@suse.com, hpa@zytor.com, bhelgaas@google.com,
	plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH 01/17] x86: Make page cache mode a real 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, 3 Nov 2014, Juergen Gross wrote:
> On 10/31/2014 09:35 PM, Borislav Petkov wrote:
> > On Fri, Oct 31, 2014 at 04:23:22PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> > > > > Signed-off-by: Juergen Gross <jgross@suse.com>
> > > > 
> > > > Just a clarification question: how is one to understand this attribution
> > > > here? Is Stefan the original author, was he a reviewer, or? Because this
> > > > SOB chain is misleading...
> > > 
> > > He was the first then Juergen took over. Should the SOB order be inversed?
> > 
> > Well, I'd say:
> > 
> > Originally-by: Stefan...
> > 
> > or
> > 
> > Based-on-patch-by: Stefan...
> 
> I think this would fit best.
> 
> Shall I respin another version modifying the SOB to above?

That would be appreciated.

Thanks,

	tglx

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:34:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:34:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEy6-0002SZ-MO; Mon, 03 Nov 2014 10:34:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlEy6-0002SU-0y
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 10:34:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	59/A4-09842-D3A57545; Mon, 03 Nov 2014 10:34:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415010875!5049076!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24113 invoked from network); 3 Nov 2014 10:34:36 -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;
	3 Nov 2014 10:34:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187458036"
Message-ID: <1415010873.9994.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Nov 2014 10:34:33 +0000
In-Reply-To: <5457641C02000078000444BA@mail.emea.novell.com>
References: <osstest-31315-mainreport@xen.org>
	<5457641C02000078000444BA@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 10:16 +0000, Jan Beulich wrote:
> >>> On 02.11.14 at 18:43, <Ian.Jackson@eu.citrix.com> wrote:
> > flight 31315 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/31315/ 
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 31285
> 
> Looking at fire-frog's serial log I see that booting started 09:34:37
> and debug output was forced at 09:35:47; the login prompt
> appeared at 09:36:11. The gap between the NTP server getting
> started and the login prompt appearing seems pretty large,

There is also a login prompt at 09:35:25. I think the one at 09:36 is
because something appeared (probably the log collection process) to
press Enter.

It's a shame /etc/init.d/osstest-confirm-booted isn't more verbose on
the console, since this is what appears to have failed (i.e. the ssh bit
seems to have worked, so I don't think it was networking/dns/etc).

>  but
> is that really an indication of something being wrong in the being
> tested software? The 3 commits under test don't really look like
> being candidate for a boot time (performance) regression.

It does seem somewhat unlikely.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:34:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:34:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlEy6-0002SZ-MO; Mon, 03 Nov 2014 10:34:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlEy6-0002SU-0y
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 10:34:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	59/A4-09842-D3A57545; Mon, 03 Nov 2014 10:34:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415010875!5049076!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24113 invoked from network); 3 Nov 2014 10:34:36 -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;
	3 Nov 2014 10:34:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187458036"
Message-ID: <1415010873.9994.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Nov 2014 10:34:33 +0000
In-Reply-To: <5457641C02000078000444BA@mail.emea.novell.com>
References: <osstest-31315-mainreport@xen.org>
	<5457641C02000078000444BA@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 10:16 +0000, Jan Beulich wrote:
> >>> On 02.11.14 at 18:43, <Ian.Jackson@eu.citrix.com> wrote:
> > flight 31315 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/31315/ 
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 31285
> 
> Looking at fire-frog's serial log I see that booting started 09:34:37
> and debug output was forced at 09:35:47; the login prompt
> appeared at 09:36:11. The gap between the NTP server getting
> started and the login prompt appearing seems pretty large,

There is also a login prompt at 09:35:25. I think the one at 09:36 is
because something appeared (probably the log collection process) to
press Enter.

It's a shame /etc/init.d/osstest-confirm-booted isn't more verbose on
the console, since this is what appears to have failed (i.e. the ssh bit
seems to have worked, so I don't think it was networking/dns/etc).

>  but
> is that really an indication of something being wrong in the being
> tested software? The 3 commits under test don't really look like
> being candidate for a boot time (performance) regression.

It does seem somewhat unlikely.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:35:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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 1XlEyj-0002Y3-3Z; Mon, 03 Nov 2014 10:35:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peterz@infradead.org>) id 1XlEyh-0002Xs-VI
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 10:35:16 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	E6/9C-02699-36A57545; Mon, 03 Nov 2014 10:35:15 +0000
X-Env-Sender: peterz@infradead.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415010914!12176728!1
X-Originating-IP: [85.118.1.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7745 invoked from network); 3 Nov 2014 10:35:14 -0000
Received: from casper.infradead.org (HELO casper.infradead.org) (85.118.1.10)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 10:35:14 -0000
Received: from 178-85-85-44.dynamic.upc.nl ([178.85.85.44] helo=worktop)
	by casper.infradead.org with esmtpsa (Exim 4.80.1 #2 (Red Hat Linux))
	id 1XlEya-00033o-Lg; Mon, 03 Nov 2014 10:35:08 +0000
Received: by worktop (Postfix, from userid 1000)
	id 952846E0870; Mon,  3 Nov 2014 11:35:05 +0100 (CET)
Date: Mon, 3 Nov 2014 11:35:05 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Waiman Long <Waiman.Long@hp.com>
Message-ID: <20141103103505.GZ23531@worktop.programming.kicks-ass.net>
References: <1414613951-32532-1-git-send-email-Waiman.Long@hp.com>
	<1414613951-32532-10-git-send-email-Waiman.Long@hp.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1414613951-32532-10-git-send-email-Waiman.Long@hp.com>
User-Agent: Mutt/1.5.22.1 (2013-10-16)
Cc: linux-arch@vger.kernel.org,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Oleg Nesterov <oleg@redhat.com>, kvm@vger.kernel.org,
	Scott J Norton <scott.norton@hp.com>, x86@kernel.org,
	Paolo Bonzini <paolo.bonzini@gmail.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Douglas Hatch <doug.hatch@hp.com>
Subject: Re: [Xen-devel] [PATCH v13 09/11] pvqspinlock,
 x86: Add para-virtualization support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 29, 2014 at 04:19:09PM -0400, Waiman Long wrote:
>  arch/x86/include/asm/pvqspinlock.h    |  411 +++++++++++++++++++++++++++++++++

I do wonder why all this needs to live in x86..

>  
> +#ifdef CONFIG_QUEUE_SPINLOCK
> +
> +static __always_inline void pv_kick_cpu(int cpu)
> +{
> +	PVOP_VCALLEE1(pv_lock_ops.kick_cpu, cpu);
> +}
> +
> +static __always_inline void pv_lockwait(u8 *lockbyte)
> +{
> +	PVOP_VCALLEE1(pv_lock_ops.lockwait, lockbyte);
> +}
> +
> +static __always_inline void pv_lockstat(enum pv_lock_stats type)
> +{
> +	PVOP_VCALLEE1(pv_lock_ops.lockstat, type);
> +}

Why are any of these PV ops? they're only called from other pv_*()
functions. What's the point of pv ops you only call from pv code?

> +/*
> + *	Queue Spinlock Para-Virtualization (PV) Support
> + *
> + * The PV support code for queue spinlock is roughly the same as that
> + * of the ticket spinlock.

Relative comments are bad, esp. since we'll make the ticket code go away
if this works, at which point this is a reference into a black hole.

>                             Each CPU waiting for the lock will spin until it
> + * reaches a threshold. When that happens, it will put itself to a halt state
> + * so that the hypervisor can reuse the CPU cycles in some other guests as
> + * well as returning other hold-up CPUs faster.




> +/**
> + * queue_spin_lock - acquire a queue spinlock
> + * @lock: Pointer to queue spinlock structure
> + *
> + * N.B. INLINE_SPIN_LOCK should not be enabled when PARAVIRT_SPINLOCK is on.

One should write a compile time fail for that, not a comment.

> + */
> +static __always_inline void queue_spin_lock(struct qspinlock *lock)
> +{
> +	u32 val;
> +
> +	val = atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL);
> +	if (likely(val == 0))
> +		return;
> +	if (static_key_false(&paravirt_spinlocks_enabled))
> +		pv_queue_spin_lock_slowpath(lock, val);
> +	else
> +		queue_spin_lock_slowpath(lock, val);
> +}

No, this is just vile.. _that_ is what we have PV ops for. And at that
point its the same function it was before the PV stuff, so that whole
inline thing is then gone.

> +extern void queue_spin_unlock_slowpath(struct qspinlock *lock);
> +
>  /**
>   * queue_spin_unlock - release a queue spinlock
>   * @lock : Pointer to queue spinlock structure
>   *
>   * An effective smp_store_release() on the least-significant byte.
> + *
> + * Inlining of the unlock function is disabled when CONFIG_PARAVIRT_SPINLOCKS
> + * is defined. So _raw_spin_unlock() will be the only call site that will
> + * have to be patched.

again if you hard rely on the not inlining make a build fail not a
comment.

>   */
>  static inline void queue_spin_unlock(struct qspinlock *lock)
>  {
>  	barrier();
> +	if (!static_key_false(&paravirt_spinlocks_enabled)) {
> +		native_spin_unlock(lock);
> +		return;
> +	}
>  
> +	/*
> +	 * Need to atomically clear the lock byte to avoid racing with
> +	 * queue head waiter trying to set _QLOCK_LOCKED_SLOWPATH.
> +	 */
> +	if (unlikely(cmpxchg((u8 *)lock, _Q_LOCKED_VAL, 0) != _Q_LOCKED_VAL))
> +		queue_spin_unlock_slowpath(lock);
> +}

Idem, that static key stuff is wrong, use PV ops to switch between
unlock paths.

> @@ -354,7 +394,7 @@ queue:
>  	 * if there was a previous node; link it and wait until reaching the
>  	 * head of the waitqueue.
>  	 */
> -	if (old & _Q_TAIL_MASK) {
> +	if (!pv_link_and_wait_node(old, node) && (old & _Q_TAIL_MASK)) {
>  		prev = decode_tail(old);
>  		ACCESS_ONCE(prev->next) = node;
> @@ -369,9 +409,11 @@ queue:
>  	 *
>  	 * *,x,y -> *,0,0
>  	 */
> -	while ((val = smp_load_acquire(&lock->val.counter)) &
> -			_Q_LOCKED_PENDING_MASK)
> +	val = pv_wait_head(lock, node);
> +	while (val & _Q_LOCKED_PENDING_MASK) {
>  		cpu_relax();
> +		val = smp_load_acquire(&lock->val.counter);
> +	}
>  
>  	/*
>  	 * claim the lock:

Please make the pv_*() calls return void and reduce to NOPs. This keeps
the logic invariant of the pv stuff.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:35:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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 1XlEyj-0002Y3-3Z; Mon, 03 Nov 2014 10:35:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peterz@infradead.org>) id 1XlEyh-0002Xs-VI
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 10:35:16 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	E6/9C-02699-36A57545; Mon, 03 Nov 2014 10:35:15 +0000
X-Env-Sender: peterz@infradead.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415010914!12176728!1
X-Originating-IP: [85.118.1.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7745 invoked from network); 3 Nov 2014 10:35:14 -0000
Received: from casper.infradead.org (HELO casper.infradead.org) (85.118.1.10)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 10:35:14 -0000
Received: from 178-85-85-44.dynamic.upc.nl ([178.85.85.44] helo=worktop)
	by casper.infradead.org with esmtpsa (Exim 4.80.1 #2 (Red Hat Linux))
	id 1XlEya-00033o-Lg; Mon, 03 Nov 2014 10:35:08 +0000
Received: by worktop (Postfix, from userid 1000)
	id 952846E0870; Mon,  3 Nov 2014 11:35:05 +0100 (CET)
Date: Mon, 3 Nov 2014 11:35:05 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Waiman Long <Waiman.Long@hp.com>
Message-ID: <20141103103505.GZ23531@worktop.programming.kicks-ass.net>
References: <1414613951-32532-1-git-send-email-Waiman.Long@hp.com>
	<1414613951-32532-10-git-send-email-Waiman.Long@hp.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1414613951-32532-10-git-send-email-Waiman.Long@hp.com>
User-Agent: Mutt/1.5.22.1 (2013-10-16)
Cc: linux-arch@vger.kernel.org,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Oleg Nesterov <oleg@redhat.com>, kvm@vger.kernel.org,
	Scott J Norton <scott.norton@hp.com>, x86@kernel.org,
	Paolo Bonzini <paolo.bonzini@gmail.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Douglas Hatch <doug.hatch@hp.com>
Subject: Re: [Xen-devel] [PATCH v13 09/11] pvqspinlock,
 x86: Add para-virtualization support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 29, 2014 at 04:19:09PM -0400, Waiman Long wrote:
>  arch/x86/include/asm/pvqspinlock.h    |  411 +++++++++++++++++++++++++++++++++

I do wonder why all this needs to live in x86..

>  
> +#ifdef CONFIG_QUEUE_SPINLOCK
> +
> +static __always_inline void pv_kick_cpu(int cpu)
> +{
> +	PVOP_VCALLEE1(pv_lock_ops.kick_cpu, cpu);
> +}
> +
> +static __always_inline void pv_lockwait(u8 *lockbyte)
> +{
> +	PVOP_VCALLEE1(pv_lock_ops.lockwait, lockbyte);
> +}
> +
> +static __always_inline void pv_lockstat(enum pv_lock_stats type)
> +{
> +	PVOP_VCALLEE1(pv_lock_ops.lockstat, type);
> +}

Why are any of these PV ops? they're only called from other pv_*()
functions. What's the point of pv ops you only call from pv code?

> +/*
> + *	Queue Spinlock Para-Virtualization (PV) Support
> + *
> + * The PV support code for queue spinlock is roughly the same as that
> + * of the ticket spinlock.

Relative comments are bad, esp. since we'll make the ticket code go away
if this works, at which point this is a reference into a black hole.

>                             Each CPU waiting for the lock will spin until it
> + * reaches a threshold. When that happens, it will put itself to a halt state
> + * so that the hypervisor can reuse the CPU cycles in some other guests as
> + * well as returning other hold-up CPUs faster.




> +/**
> + * queue_spin_lock - acquire a queue spinlock
> + * @lock: Pointer to queue spinlock structure
> + *
> + * N.B. INLINE_SPIN_LOCK should not be enabled when PARAVIRT_SPINLOCK is on.

One should write a compile time fail for that, not a comment.

> + */
> +static __always_inline void queue_spin_lock(struct qspinlock *lock)
> +{
> +	u32 val;
> +
> +	val = atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL);
> +	if (likely(val == 0))
> +		return;
> +	if (static_key_false(&paravirt_spinlocks_enabled))
> +		pv_queue_spin_lock_slowpath(lock, val);
> +	else
> +		queue_spin_lock_slowpath(lock, val);
> +}

No, this is just vile.. _that_ is what we have PV ops for. And at that
point its the same function it was before the PV stuff, so that whole
inline thing is then gone.

> +extern void queue_spin_unlock_slowpath(struct qspinlock *lock);
> +
>  /**
>   * queue_spin_unlock - release a queue spinlock
>   * @lock : Pointer to queue spinlock structure
>   *
>   * An effective smp_store_release() on the least-significant byte.
> + *
> + * Inlining of the unlock function is disabled when CONFIG_PARAVIRT_SPINLOCKS
> + * is defined. So _raw_spin_unlock() will be the only call site that will
> + * have to be patched.

again if you hard rely on the not inlining make a build fail not a
comment.

>   */
>  static inline void queue_spin_unlock(struct qspinlock *lock)
>  {
>  	barrier();
> +	if (!static_key_false(&paravirt_spinlocks_enabled)) {
> +		native_spin_unlock(lock);
> +		return;
> +	}
>  
> +	/*
> +	 * Need to atomically clear the lock byte to avoid racing with
> +	 * queue head waiter trying to set _QLOCK_LOCKED_SLOWPATH.
> +	 */
> +	if (unlikely(cmpxchg((u8 *)lock, _Q_LOCKED_VAL, 0) != _Q_LOCKED_VAL))
> +		queue_spin_unlock_slowpath(lock);
> +}

Idem, that static key stuff is wrong, use PV ops to switch between
unlock paths.

> @@ -354,7 +394,7 @@ queue:
>  	 * if there was a previous node; link it and wait until reaching the
>  	 * head of the waitqueue.
>  	 */
> -	if (old & _Q_TAIL_MASK) {
> +	if (!pv_link_and_wait_node(old, node) && (old & _Q_TAIL_MASK)) {
>  		prev = decode_tail(old);
>  		ACCESS_ONCE(prev->next) = node;
> @@ -369,9 +409,11 @@ queue:
>  	 *
>  	 * *,x,y -> *,0,0
>  	 */
> -	while ((val = smp_load_acquire(&lock->val.counter)) &
> -			_Q_LOCKED_PENDING_MASK)
> +	val = pv_wait_head(lock, node);
> +	while (val & _Q_LOCKED_PENDING_MASK) {
>  		cpu_relax();
> +		val = smp_load_acquire(&lock->val.counter);
> +	}
>  
>  	/*
>  	 * claim the lock:

Please make the pv_*() calls return void and reduce to NOPs. This keeps
the logic invariant of the pv stuff.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:41:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:41:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlF4F-0002ma-0q; Mon, 03 Nov 2014 10:40:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlF4D-0002mV-Rp
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 10:40:57 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B1/C3-22737-9BB57545; Mon, 03 Nov 2014 10:40:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415011255!7485076!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13676 invoked from network); 3 Nov 2014 10:40:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:40:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187460131"
Message-ID: <1415011253.9994.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 3 Nov 2014 10:40:53 +0000
In-Reply-To: <1414754490-30355-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1414754490-30355-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH] DhcpWatch::leases: Check 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 Fri, 2014-10-31 at 11:21 +0000, Ian Jackson wrote:
> Check error returns from connect() et al (which present as an undef
> return from IO::Socket::INET), and from read() (which can be detected
> via IO::Handle::error).
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Looks like you have a mixture of tabs and spaces in the second hunk, but
otherwise:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  Osstest/DhcpWatch/leases.pm |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Osstest/DhcpWatch/leases.pm b/Osstest/DhcpWatch/leases.pm
> index 6f142e7..9a74c40 100644
> --- a/Osstest/DhcpWatch/leases.pm
> +++ b/Osstest/DhcpWatch/leases.pm
> @@ -58,6 +58,7 @@ sub check_ip ($$) {
>  	if (!defined $leases) { return "open $leasesfn: $!"; }
>      } else {
>  	$leases= new IO::Socket::INET(PeerAddr => $leasesfn);
> +	if (!defined $leases) { return "connect to $leasesfn: $!"; }
>      }
>  
>      my $lstash= "dhcpleases-$gho->{Guest}";
> @@ -163,6 +164,9 @@ sub check_ip ($$) {
>  
>      if (!$best) {
>          $saveas->("$lstash.nolease", 3);
> +	if ($leases->error) {
> +	    return "error reading $leasesfn";
> +	}
>          return "no active lease";
>      }
>      $gho->{Ip}= $best->{' addr'};



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:41:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:41:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlF4F-0002ma-0q; Mon, 03 Nov 2014 10:40:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlF4D-0002mV-Rp
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 10:40:57 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B1/C3-22737-9BB57545; Mon, 03 Nov 2014 10:40:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415011255!7485076!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13676 invoked from network); 3 Nov 2014 10:40:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:40:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187460131"
Message-ID: <1415011253.9994.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 3 Nov 2014 10:40:53 +0000
In-Reply-To: <1414754490-30355-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1414754490-30355-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH] DhcpWatch::leases: Check 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 Fri, 2014-10-31 at 11:21 +0000, Ian Jackson wrote:
> Check error returns from connect() et al (which present as an undef
> return from IO::Socket::INET), and from read() (which can be detected
> via IO::Handle::error).
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Looks like you have a mixture of tabs and spaces in the second hunk, but
otherwise:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  Osstest/DhcpWatch/leases.pm |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Osstest/DhcpWatch/leases.pm b/Osstest/DhcpWatch/leases.pm
> index 6f142e7..9a74c40 100644
> --- a/Osstest/DhcpWatch/leases.pm
> +++ b/Osstest/DhcpWatch/leases.pm
> @@ -58,6 +58,7 @@ sub check_ip ($$) {
>  	if (!defined $leases) { return "open $leasesfn: $!"; }
>      } else {
>  	$leases= new IO::Socket::INET(PeerAddr => $leasesfn);
> +	if (!defined $leases) { return "connect to $leasesfn: $!"; }
>      }
>  
>      my $lstash= "dhcpleases-$gho->{Guest}";
> @@ -163,6 +164,9 @@ sub check_ip ($$) {
>  
>      if (!$best) {
>          $saveas->("$lstash.nolease", 3);
> +	if ($leases->error) {
> +	    return "error reading $leasesfn";
> +	}
>          return "no active lease";
>      }
>      $gho->{Ip}= $best->{' addr'};



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:47:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:47:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFAf-00033c-VF; Mon, 03 Nov 2014 10:47:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlFAe-00033X-GK
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:47:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	51/6F-09936-74D57545; Mon, 03 Nov 2014 10:47:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415011654!12380196!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6142 invoked from network); 3 Nov 2014 10:47:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:47:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187462358"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 05:47:33 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlFAa-0006wR-LL;
	Mon, 03 Nov 2014 10:47:32 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlFAa-0006sn-Bv;
	Mon, 03 Nov 2014 10:47:32 +0000
Date: Mon, 3 Nov 2014 10:47:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31335-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31335: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                fail pass in 31310
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31335
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31310
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31335

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop        fail in 31310 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:47:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:47:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFAf-00033c-VF; Mon, 03 Nov 2014 10:47:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlFAe-00033X-GK
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:47:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	51/6F-09936-74D57545; Mon, 03 Nov 2014 10:47:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415011654!12380196!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6142 invoked from network); 3 Nov 2014 10:47:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:47:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187462358"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 05:47:33 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlFAa-0006wR-LL;
	Mon, 03 Nov 2014 10:47:32 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlFAa-0006sn-Bv;
	Mon, 03 Nov 2014 10:47:32 +0000
Date: Mon, 3 Nov 2014 10:47:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31335-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31335: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                fail pass in 31310
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31335
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31310
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31335

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop        fail in 31310 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:51:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:51:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFEW-0003EH-PY; Mon, 03 Nov 2014 10:51:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XlFEV-0003EB-F6
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:51:35 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	41/D8-03145-63E57545; Mon, 03 Nov 2014 10:51:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415011892!12163553!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25567 invoked from network); 3 Nov 2014 10:51:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:51:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187464058"
Message-ID: <54575E32.6040603@citrix.com>
Date: Mon, 3 Nov 2014 10:51:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>, <Xen-devel@lists.xen.org>
References: <54574EA0.5070101@canonical.com>
In-Reply-To: <54574EA0.5070101@canonical.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/11/14 09:45, Stefan Bader wrote:
> I see the message from the subject on my Intel box whenever a guest (iirc even
> dom0) starts up. It is not fatal and everything seems ok. I am just curious
> about what might trigger this. The addresses look to be inside the hypervisor
> code. I was wondering whether there is a simple way to figure out what this
> relates to (likely need to look at the objdump of the unstripped hv module).
>
> Or has someone already looked into this and knows what likely is the cause?
>
> -Stefan

Specifically, the message indicates <type of fault>: faulting address ->
fixup address

It is probably a wrmsr, and a higher logging level will indicate this. 
My gut feeling is that it is dom0 attempting to load microcode using the
native method.

~Andrew

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:51:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:51:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFEW-0003EH-PY; Mon, 03 Nov 2014 10:51:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XlFEV-0003EB-F6
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 10:51:35 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	41/D8-03145-63E57545; Mon, 03 Nov 2014 10:51:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415011892!12163553!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25567 invoked from network); 3 Nov 2014 10:51:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:51:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187464058"
Message-ID: <54575E32.6040603@citrix.com>
Date: Mon, 3 Nov 2014 10:51:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>, <Xen-devel@lists.xen.org>
References: <54574EA0.5070101@canonical.com>
In-Reply-To: <54574EA0.5070101@canonical.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/11/14 09:45, Stefan Bader wrote:
> I see the message from the subject on my Intel box whenever a guest (iirc even
> dom0) starts up. It is not fatal and everything seems ok. I am just curious
> about what might trigger this. The addresses look to be inside the hypervisor
> code. I was wondering whether there is a simple way to figure out what this
> relates to (likely need to look at the objdump of the unstripped hv module).
>
> Or has someone already looked into this and knows what likely is the cause?
>
> -Stefan

Specifically, the message indicates <type of fault>: faulting address ->
fixup address

It is probably a wrmsr, and a higher logging level will indicate this. 
My gut feeling is that it is dom0 attempting to load microcode using the
native method.

~Andrew

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:54:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:54:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFHP-0003OA-Ug; Mon, 03 Nov 2014 10:54:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFHO-0003Nq-VE
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:54:35 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	2B/55-09284-AEE57545; Mon, 03 Nov 2014 10:54:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415012069!11278199!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26114 invoked from network); 3 Nov 2014 10:54:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:54:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187465322"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 05:54:20 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlF9E-0006vU-AD;
	Mon, 03 Nov 2014 10:46:08 +0000
Date: Mon, 3 Nov 2014 10:46:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Catalin Marinas <catalin.marinas@arm.com>, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> Introduce a boolean flag and an accessor function to check whether a
> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> CC: will.deacon@arm.com

Will, Catalin,
are you OK with this patch?


>  arch/arm64/include/asm/device.h      |    1 +
>  arch/arm64/include/asm/dma-mapping.h |    6 ++++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
> index cf98b36..243ef25 100644
> --- a/arch/arm64/include/asm/device.h
> +++ b/arch/arm64/include/asm/device.h
> @@ -21,6 +21,7 @@ struct dev_archdata {
>  #ifdef CONFIG_IOMMU_API
>  	void *iommu;			/* private IOMMU data */
>  #endif
> +	bool dma_coherent;
>  };
>  
>  struct pdev_archdata {
> diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
> index adeae3f..e213dc4 100644
> --- a/arch/arm64/include/asm/dma-mapping.h
> +++ b/arch/arm64/include/asm/dma-mapping.h
> @@ -54,11 +54,17 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
>  
>  static inline int set_arch_dma_coherent_ops(struct device *dev)
>  {
> +	dev->archdata.dma_coherent = true;
>  	set_dma_ops(dev, &coherent_swiotlb_dma_ops);
>  	return 0;
>  }
>  #define set_arch_dma_coherent_ops	set_arch_dma_coherent_ops
>  
> +static inline bool is_device_dma_coherent(struct device *dev)
> +{
> +	return dev->archdata.dma_coherent;
> +}
> +
>  #include <asm-generic/dma-mapping-common.h>
>  
>  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:54:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:54:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFHO-0003Nr-Ie; Mon, 03 Nov 2014 10:54:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFHM-0003Nh-Oj
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:54:32 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	ED/DB-25727-8EE57545; Mon, 03 Nov 2014 10:54:32 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415012069!11278199!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25982 invoked from network); 3 Nov 2014 10:54:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:54:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187465308"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 05:54:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlF8R-0006uk-T0;
	Mon, 03 Nov 2014 10:45:19 +0000
Date: Mon, 3 Nov 2014 10:45:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1414422568-19103-7-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1411031044480.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-7-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v7 7/8] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Oct 2014, Stefano Stabellini wrote:
> Introduce an arch specific function to find out whether a particular dma
> mapping operation needs to bounce on the swiotlb buffer.
> 
> On ARM and ARM64, if the page involved is a foreign page and the device
> is not coherent, we need to bounce because at unmap time we cannot
> execute any required cache maintenance operations (we don't know how to
> find the pfn from the mfn).
> 
> No change of behaviour for x86.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Konrad, David, are you OK with the swiotlb-xen changes?


 
> Changes in v6:
> - fix ts.
> 
> Changes in v5:
> - fix indentation.
> ---
>  arch/arm/include/asm/xen/page.h |    4 ++++
>  arch/arm/xen/mm.c               |    7 +++++++
>  arch/x86/include/asm/xen/page.h |    7 +++++++
>  drivers/xen/swiotlb-xen.c       |    5 ++++-
>  4 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 135c24a..68c739b 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn);
> +
>  #endif /* _ASM_ARM_XEN_PAGE_H */
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index ff413a8..28396aa 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -139,6 +139,13 @@ void xen_dma_sync_single_for_device(struct device *hwdev,
>  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
>  }
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn)
> +{
> +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> +}
> +
>  int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
>  				 unsigned int address_bits,
>  				 dma_addr_t *dma_handle)
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index c949923..f58ef6c 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
>  #define xen_remap(cookie, size) ioremap((cookie), (size));
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +static inline bool xen_arch_need_swiotlb(struct device *dev,
> +					 unsigned long pfn,
> +					 unsigned long mfn)
> +{
> +	return false;
> +}
> +
>  #endif /* _ASM_X86_XEN_PAGE_H */
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ebd8f21..ac5d41b 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
>  	 * buffering it.
>  	 */
>  	if (dma_capable(dev, dev_addr, size) &&
> -	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
> +	    !range_straddles_page_boundary(phys, size) &&
> +		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
> +		!swiotlb_force) {
>  		/* we are not interested in the dma_addr returned by
>  		 * xen_dma_map_page, only in the potential cache flushes executed
>  		 * by the function. */
> @@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>  		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
>  
>  		if (swiotlb_force ||
> +		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
>  		    !dma_capable(hwdev, dev_addr, sg->length) ||
>  		    range_straddles_page_boundary(paddr, sg->length)) {
>  			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:54:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:54:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFHP-0003OA-Ug; Mon, 03 Nov 2014 10:54:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFHO-0003Nq-VE
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:54:35 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	2B/55-09284-AEE57545; Mon, 03 Nov 2014 10:54:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415012069!11278199!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26114 invoked from network); 3 Nov 2014 10:54:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:54:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187465322"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 05:54:20 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlF9E-0006vU-AD;
	Mon, 03 Nov 2014 10:46:08 +0000
Date: Mon, 3 Nov 2014 10:46:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Catalin Marinas <catalin.marinas@arm.com>, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> Introduce a boolean flag and an accessor function to check whether a
> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> CC: will.deacon@arm.com

Will, Catalin,
are you OK with this patch?


>  arch/arm64/include/asm/device.h      |    1 +
>  arch/arm64/include/asm/dma-mapping.h |    6 ++++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
> index cf98b36..243ef25 100644
> --- a/arch/arm64/include/asm/device.h
> +++ b/arch/arm64/include/asm/device.h
> @@ -21,6 +21,7 @@ struct dev_archdata {
>  #ifdef CONFIG_IOMMU_API
>  	void *iommu;			/* private IOMMU data */
>  #endif
> +	bool dma_coherent;
>  };
>  
>  struct pdev_archdata {
> diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
> index adeae3f..e213dc4 100644
> --- a/arch/arm64/include/asm/dma-mapping.h
> +++ b/arch/arm64/include/asm/dma-mapping.h
> @@ -54,11 +54,17 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
>  
>  static inline int set_arch_dma_coherent_ops(struct device *dev)
>  {
> +	dev->archdata.dma_coherent = true;
>  	set_dma_ops(dev, &coherent_swiotlb_dma_ops);
>  	return 0;
>  }
>  #define set_arch_dma_coherent_ops	set_arch_dma_coherent_ops
>  
> +static inline bool is_device_dma_coherent(struct device *dev)
> +{
> +	return dev->archdata.dma_coherent;
> +}
> +
>  #include <asm-generic/dma-mapping-common.h>
>  
>  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:54:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:54:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFHO-0003Nr-Ie; Mon, 03 Nov 2014 10:54:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFHM-0003Nh-Oj
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:54:32 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	ED/DB-25727-8EE57545; Mon, 03 Nov 2014 10:54:32 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415012069!11278199!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25982 invoked from network); 3 Nov 2014 10:54:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:54:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187465308"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 05:54:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlF8R-0006uk-T0;
	Mon, 03 Nov 2014 10:45:19 +0000
Date: Mon, 3 Nov 2014 10:45:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1414422568-19103-7-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1411031044480.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-7-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v7 7/8] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Oct 2014, Stefano Stabellini wrote:
> Introduce an arch specific function to find out whether a particular dma
> mapping operation needs to bounce on the swiotlb buffer.
> 
> On ARM and ARM64, if the page involved is a foreign page and the device
> is not coherent, we need to bounce because at unmap time we cannot
> execute any required cache maintenance operations (we don't know how to
> find the pfn from the mfn).
> 
> No change of behaviour for x86.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Konrad, David, are you OK with the swiotlb-xen changes?


 
> Changes in v6:
> - fix ts.
> 
> Changes in v5:
> - fix indentation.
> ---
>  arch/arm/include/asm/xen/page.h |    4 ++++
>  arch/arm/xen/mm.c               |    7 +++++++
>  arch/x86/include/asm/xen/page.h |    7 +++++++
>  drivers/xen/swiotlb-xen.c       |    5 ++++-
>  4 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 135c24a..68c739b 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn);
> +
>  #endif /* _ASM_ARM_XEN_PAGE_H */
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index ff413a8..28396aa 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -139,6 +139,13 @@ void xen_dma_sync_single_for_device(struct device *hwdev,
>  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
>  }
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn)
> +{
> +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> +}
> +
>  int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
>  				 unsigned int address_bits,
>  				 dma_addr_t *dma_handle)
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index c949923..f58ef6c 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
>  #define xen_remap(cookie, size) ioremap((cookie), (size));
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +static inline bool xen_arch_need_swiotlb(struct device *dev,
> +					 unsigned long pfn,
> +					 unsigned long mfn)
> +{
> +	return false;
> +}
> +
>  #endif /* _ASM_X86_XEN_PAGE_H */
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ebd8f21..ac5d41b 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
>  	 * buffering it.
>  	 */
>  	if (dma_capable(dev, dev_addr, size) &&
> -	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
> +	    !range_straddles_page_boundary(phys, size) &&
> +		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
> +		!swiotlb_force) {
>  		/* we are not interested in the dma_addr returned by
>  		 * xen_dma_map_page, only in the potential cache flushes executed
>  		 * by the function. */
> @@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>  		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
>  
>  		if (swiotlb_force ||
> +		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
>  		    !dma_capable(hwdev, dev_addr, sg->length) ||
>  		    range_straddles_page_boundary(paddr, sg->length)) {
>  			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:55:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlFIT-0003Zb-E3; Mon, 03 Nov 2014 10:55:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFIS-0003ZP-I7
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:55:40 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B9/4E-09842-B2F57545; Mon, 03 Nov 2014 10:55:39 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415012138!4327074!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15942 invoked from network); 3 Nov 2014 10:55:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:55:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188843297"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 05:55:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlFIP-00079w-Bk;
	Mon, 03 Nov 2014 10:55:37 +0000
Date: Mon, 3 Nov 2014 10:55:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1414422568-19103-4-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1411031054400.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-4-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, linux@arm.linux.org.uk,
	Ian.Campbell@citrix.com,
	Catalin Marinas <catalin.marinas@arm.com>, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v7 4/8] arm: introduce is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> Introduce a boolean flag and an accessor function to check whether a
> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> CC: linux@arm.linux.org.uk
> CC: will.deacon@arm.com

Any opinions on this?
FYI I have just submitted the patch to Russell's patch tracking system.


>  arch/arm/include/asm/device.h      |    1 +
>  arch/arm/include/asm/dma-mapping.h |    6 ++++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index dc662fc..4111592 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -17,6 +17,7 @@ struct dev_archdata {
>  #ifdef CONFIG_ARM_DMA_USE_IOMMU
>  	struct dma_iommu_mapping	*mapping;
>  #endif
> +	bool dma_coherent;
>  };
>  
>  struct omap_device;
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index 85738b2..8c3b616 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -123,11 +123,17 @@ static inline unsigned long dma_max_pfn(struct device *dev)
>  
>  static inline int set_arch_dma_coherent_ops(struct device *dev)
>  {
> +	dev->archdata.dma_coherent = true;
>  	set_dma_ops(dev, &arm_coherent_dma_ops);
>  	return 0;
>  }
>  #define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
>  
> +static inline bool is_device_dma_coherent(struct device *dev)
> +{
> +	return dev->archdata.dma_coherent;
> +}
> +
>  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
>  {
>  	unsigned int offset = paddr & ~PAGE_MASK;
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:55:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10: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 1XlFIT-0003Zb-E3; Mon, 03 Nov 2014 10:55:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFIS-0003ZP-I7
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:55:40 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B9/4E-09842-B2F57545; Mon, 03 Nov 2014 10:55:39 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415012138!4327074!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15942 invoked from network); 3 Nov 2014 10:55:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 10:55:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188843297"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 05:55:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlFIP-00079w-Bk;
	Mon, 03 Nov 2014 10:55:37 +0000
Date: Mon, 3 Nov 2014 10:55:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1414422568-19103-4-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1411031054400.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-4-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, linux@arm.linux.org.uk,
	Ian.Campbell@citrix.com,
	Catalin Marinas <catalin.marinas@arm.com>, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v7 4/8] arm: introduce is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> Introduce a boolean flag and an accessor function to check whether a
> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> CC: linux@arm.linux.org.uk
> CC: will.deacon@arm.com

Any opinions on this?
FYI I have just submitted the patch to Russell's patch tracking system.


>  arch/arm/include/asm/device.h      |    1 +
>  arch/arm/include/asm/dma-mapping.h |    6 ++++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index dc662fc..4111592 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -17,6 +17,7 @@ struct dev_archdata {
>  #ifdef CONFIG_ARM_DMA_USE_IOMMU
>  	struct dma_iommu_mapping	*mapping;
>  #endif
> +	bool dma_coherent;
>  };
>  
>  struct omap_device;
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index 85738b2..8c3b616 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -123,11 +123,17 @@ static inline unsigned long dma_max_pfn(struct device *dev)
>  
>  static inline int set_arch_dma_coherent_ops(struct device *dev)
>  {
> +	dev->archdata.dma_coherent = true;
>  	set_dma_ops(dev, &arm_coherent_dma_ops);
>  	return 0;
>  }
>  #define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
>  
> +static inline bool is_device_dma_coherent(struct device *dev)
> +{
> +	return dev->archdata.dma_coherent;
> +}
> +
>  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
>  {
>  	unsigned int offset = paddr & ~PAGE_MASK;
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:57:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFKC-0003kv-Vz; Mon, 03 Nov 2014 10:57:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <will.deacon@arm.com>) id 1XlFKB-0003kf-2v
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:57:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	04/1F-24532-69F57545; Mon, 03 Nov 2014 10:57:26 +0000
X-Env-Sender: will.deacon@arm.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415012245!12369036!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24909 invoked from network); 3 Nov 2014 10:57:25 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-7.tower-21.messagelabs.com with SMTP;
	3 Nov 2014 10:57:25 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id B683D66;
	Mon,  3 Nov 2014 04:57:16 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 7222A5FAD7;
	Mon,  3 Nov 2014 04:57:14 -0600 (CST)
Received: from arm.com (edgewater-inn.cambridge.arm.com [10.1.203.204])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 3579213F61D;
	Mon,  3 Nov 2014 04:57:13 -0600 (CST)
Date: Mon, 3 Nov 2014 10:57:16 +0000
From: Will Deacon <will.deacon@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141103105716.GC23162@arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > Introduce a boolean flag and an accessor function to check whether a
> > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > CC: will.deacon@arm.com
> 
> Will, Catalin,
> are you OK with this patch?

It would be nicer if the dma_coherent flag didn't have to be duplicated by
each architecture in dev_archdata. Is there any reason not to put it in the
core code?

Will

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 10:57:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 10:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFKC-0003kv-Vz; Mon, 03 Nov 2014 10:57:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <will.deacon@arm.com>) id 1XlFKB-0003kf-2v
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 10:57:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	04/1F-24532-69F57545; Mon, 03 Nov 2014 10:57:26 +0000
X-Env-Sender: will.deacon@arm.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415012245!12369036!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24909 invoked from network); 3 Nov 2014 10:57:25 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-7.tower-21.messagelabs.com with SMTP;
	3 Nov 2014 10:57:25 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id B683D66;
	Mon,  3 Nov 2014 04:57:16 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 7222A5FAD7;
	Mon,  3 Nov 2014 04:57:14 -0600 (CST)
Received: from arm.com (edgewater-inn.cambridge.arm.com [10.1.203.204])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 3579213F61D;
	Mon,  3 Nov 2014 04:57:13 -0600 (CST)
Date: Mon, 3 Nov 2014 10:57:16 +0000
From: Will Deacon <will.deacon@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141103105716.GC23162@arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > Introduce a boolean flag and an accessor function to check whether a
> > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > CC: will.deacon@arm.com
> 
> Will, Catalin,
> are you OK with this patch?

It would be nicer if the dma_coherent flag didn't have to be duplicated by
each architecture in dev_archdata. Is there any reason not to put it in the
core code?

Will

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:00:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:00:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFNP-0003yq-L9; Mon, 03 Nov 2014 11:00:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlFNO-0003yk-T0
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:00:47 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B8/BF-17958-E5067545; Mon, 03 Nov 2014 11:00:46 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415012445!11280470!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1326 invoked from network); 3 Nov 2014 11:00:45 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:00:45 -0000
Received: by mail-wi0-f179.google.com with SMTP id h11so6013940wiw.0
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 03:00:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=iCUGL7wQLQlxkuyHcoBVzZOG8Z0ZbfVe34gF0tafT1A=;
	b=KBlHB2+PkNmFnJbNQaam6vS59zBIT6ApKaGER1RmFC8wDB+X7JSyV3jf0vbE6Ugf+6
	t7d0JFkTqlyqFz8mz7hxLHC7peLhCukCWqngaqpuvuMdWdIk2hiCskycqweoeZRDBtay
	y5/x0nCXwyN7hpOYkoRRN/sfgChPK6TaCOvwojU7Tt8lO73z3oQ5THS+n6F9so/F+pm1
	S34u1W8fjWrDtWxa59iDOEd4UqtRcZxdzuTCn1QxHuBYg+IktHqVW0wpzv4giWH6+5Hg
	EP/SHSJAM6evPIzPb4oi7/Hr+nwRT3CIK/p1dCkOSGAFSeDMS6bGC+kTNMXzW+TTEoAw
	XQZw==
MIME-Version: 1.0
X-Received: by 10.180.81.134 with SMTP id a6mr15003485wiy.11.1415012445460;
	Mon, 03 Nov 2014 03:00:45 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 3 Nov 2014 03:00:45 -0800 (PST)
In-Reply-To: <20141029081738.GA23095@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<20141029081738.GA23095@aepfle.de>
Date: Mon, 3 Nov 2014 11:00:45 +0000
X-Google-Sender-Auth: awwPlrln5UgJ5cZiYiDh9Sn1zUo
Message-ID: <CAFLBxZZxkdBK_gUHNf9TSuL5MjfN82p-a2wWFr0x8v3uU_c-pw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 29, 2014 at 8:17 AM, Olaf Hering <olaf@aepfle.de> wrote:
> Ping?

Sorry, I thought you had found an error and were going to resubmit.
:-)  I'll take a look at it today.

 -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:00:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:00:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFNP-0003yq-L9; Mon, 03 Nov 2014 11:00:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlFNO-0003yk-T0
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:00:47 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B8/BF-17958-E5067545; Mon, 03 Nov 2014 11:00:46 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415012445!11280470!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1326 invoked from network); 3 Nov 2014 11:00:45 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:00:45 -0000
Received: by mail-wi0-f179.google.com with SMTP id h11so6013940wiw.0
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 03:00:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=iCUGL7wQLQlxkuyHcoBVzZOG8Z0ZbfVe34gF0tafT1A=;
	b=KBlHB2+PkNmFnJbNQaam6vS59zBIT6ApKaGER1RmFC8wDB+X7JSyV3jf0vbE6Ugf+6
	t7d0JFkTqlyqFz8mz7hxLHC7peLhCukCWqngaqpuvuMdWdIk2hiCskycqweoeZRDBtay
	y5/x0nCXwyN7hpOYkoRRN/sfgChPK6TaCOvwojU7Tt8lO73z3oQ5THS+n6F9so/F+pm1
	S34u1W8fjWrDtWxa59iDOEd4UqtRcZxdzuTCn1QxHuBYg+IktHqVW0wpzv4giWH6+5Hg
	EP/SHSJAM6evPIzPb4oi7/Hr+nwRT3CIK/p1dCkOSGAFSeDMS6bGC+kTNMXzW+TTEoAw
	XQZw==
MIME-Version: 1.0
X-Received: by 10.180.81.134 with SMTP id a6mr15003485wiy.11.1415012445460;
	Mon, 03 Nov 2014 03:00:45 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 3 Nov 2014 03:00:45 -0800 (PST)
In-Reply-To: <20141029081738.GA23095@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<20141029081738.GA23095@aepfle.de>
Date: Mon, 3 Nov 2014 11:00:45 +0000
X-Google-Sender-Auth: awwPlrln5UgJ5cZiYiDh9Sn1zUo
Message-ID: <CAFLBxZZxkdBK_gUHNf9TSuL5MjfN82p-a2wWFr0x8v3uU_c-pw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 29, 2014 at 8:17 AM, Olaf Hering <olaf@aepfle.de> wrote:
> Ping?

Sorry, I thought you had found an error and were going to resubmit.
:-)  I'll take a look at it today.

 -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:01:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11: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 1XlFO5-00042I-2j; Mon, 03 Nov 2014 11:01:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFO3-00041z-E8
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 11:01:27 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B3/34-09936-68067545; Mon, 03 Nov 2014 11:01:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415012484!8915764!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20911 invoked from network); 3 Nov 2014 11:01:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:01:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188844468"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 06:01:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlFNz-0007GE-DU;
	Mon, 03 Nov 2014 11:01:23 +0000
Date: Mon, 3 Nov 2014 11:01:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 1 Nov 2014, Julien Grall wrote:
> The vGIC will emulate the same version as the hardware. The toolstack has
> to retrieve the version of the vGIC in order to be able to create the
> corresponding device tree node.
> 
> A new DOMCTL has been introduced for ARM to configure the domain. For now
> it only allow the toolstack to retrieve the version of vGIC.
> This DOMCTL will be extend later to let the user choose the version of the
> emulated GIC.
> 
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Wei Liu <wei.liu2@citrix.com>

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>     Changes in v2:
>         - Use memcpu in xc_domain_configure
>         - Rename the DOMCTL into domctl_arm_configuredomain
>         - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>         and fold the code in arch_domain_init_hw_description
>         - Return -EOPNOTSUPP when the value of gic_version is not
>         supported
> 
> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> defer the initialization of the vGIC [2].
> 
> Xen 4.5 has already support for the hardware GICv3. While it's possible to
> boot and use DOM0, there is no guest support. The first version of this patch
> has been sent a couple of months ago, but has never reached unstable for
> various reasons (based on deferred series, lake of review at that time...).
> Without it, platform with GICv3 support won't be able to boot any guest.
> 
> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
> 
> Features such as adding a new config option to let the user choose the GIC
> version are deferred to Xen 4.6.
> 
> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> [2] https://patches.linaro.org/34664/
> ---
>  tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>  tools/libxc/include/xenctrl.h                |    6 ++
>  tools/libxc/xc_domain.c                      |   20 ++++++
>  tools/libxl/libxl_arm.c                      |   97 ++++++++++++++++++++++++--
>  xen/arch/arm/domctl.c                        |   35 ++++++++++
>  xen/arch/arm/gic-v3.c                        |   16 ++++-
>  xen/include/public/arch-arm.h                |   16 +++++
>  xen/include/public/domctl.h                  |   17 +++++
>  xen/xsm/flask/hooks.c                        |    3 +
>  xen/xsm/flask/policy/access_vectors          |    2 +
>  10 files changed, 206 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> index 641c797..fa69c9d 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>  			getdomaininfo hypercall setvcpucontext setextvcpucontext
>  			getscheduler getvcpuinfo getvcpuextstate getaddrsize
>  			getaffinity setaffinity };
> -	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>  	allow $1 $2:security check_context;
>  	allow $1 $2:shadow enable;
>  	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 564e187..45e282c 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>                       uint32_t flags,
>                       uint32_t *pdomid);
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> +
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config);
> +#endif
>  
>  /* Functions to produce a dump of a given domain
>   *  xc_domain_dumpcore - produces a dump to a specified file
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index a9bcd4a..1aa1f45 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>      return 0;
>  }
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config)
> +{
> +    int rc;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> +    domctl.domain = (domid_t)domid;
> +    /* xc_domain_configure_t is an alias to xen_domctl_arm_configuredomain */
> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
> +
> +    rc = do_domctl(xch, &domctl);
> +    if ( !rc )
> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> +
> +    return rc;
> +}
> +#endif
> +
>  int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
>                           xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
>  {
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index a122e4a..3dd6e7c 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -23,6 +23,18 @@
>  #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
>  #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
>  
> +static const char *gicv_to_string(uint8_t gic_version)
> +{
> +    switch (gic_version) {
> +    case XEN_DOMCTL_CONFIG_GIC_V2:
> +        return "V2";
> +    case XEN_DOMCTL_CONFIG_GIC_V3:
> +        return "V3";
> +    default:
> +        return "unknown";
> +    }
> +}
> +
>  int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>                                uint32_t domid)
>  {
> @@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
>      return 0;
>  }
>  
> -static int make_intc_node(libxl__gc *gc, void *fdt,
> -                          uint64_t gicd_base, uint64_t gicd_size,
> -                          uint64_t gicc_base, uint64_t gicc_size)
> +static int make_gicv2_node(libxl__gc *gc, void *fdt,
> +                           uint64_t gicd_base, uint64_t gicd_size,
> +                           uint64_t gicc_base, uint64_t gicc_size)
>  {
>      int res;
>      const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> @@ -350,6 +362,57 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
>      return 0;
>  }
>  
> +static int make_gicv3_node(libxl__gc *gc, void *fdt)
> +{
> +    int res;
> +    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
> +    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
> +    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
> +    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
> +    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> +
> +    res = fdt_begin_node(fdt, name);
> +    if (res) return res;
> +
> +    res = fdt_property_compat(gc, fdt, 1,
> +                              "arm,gic-v3");
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#address-cells", 0);
> +    if (res) return res;
> +
> +    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "redistributor-stride",
> +                            GUEST_GICV3_RDIST_STRIDE);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#redistributor-regions",
> +                            GUEST_GICV3_RDIST_REGIONS);
> +    if (res) return res;
> +
> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> +                            2,
> +                            gicd_base, gicd_size,
> +                            gicr0_base, gicr0_size);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_end_node(fdt);
> +    if (res) return res;
> +
> +    return 0;
> +}
> +
>  static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
>  {
>      int res;
> @@ -456,6 +519,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>                                             libxl_domain_build_info *info,
>                                             struct xc_dom_image *dom)
>  {
> +    xc_domain_configuration_t config;
>      void *fdt = NULL;
>      int rc, res;
>      size_t fdt_size = 0;
> @@ -471,8 +535,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>      ainfo = get_arch_info(gc, dom);
>      if (ainfo == NULL) return ERROR_FAIL;
>  
> +    LOG(DEBUG, "configure the domain");
> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> +        LOG(ERROR, "counldn't configure the domain");
> +        return ERROR_FAIL;
> +    }
> +
>      LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
>          vers->xen_version_major, vers->xen_version_minor);
> +    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
>  
>  /*
>   * Call "call" handling FDR_ERR_*. Will either:
> @@ -520,9 +592,22 @@ next_resize:
>          FDT( make_psci_node(gc, fdt) );
>  
>          FDT( make_memory_nodes(gc, fdt, dom) );
> -        FDT( make_intc_node(gc, fdt,
> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> +
> +        switch (config.gic_version) {
> +        case XEN_DOMCTL_CONFIG_GIC_V2:
> +            FDT( make_gicv2_node(gc, fdt,
> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> +            break;
> +        case XEN_DOMCTL_CONFIG_GIC_V3:
> +            FDT( make_gicv3_node(gc, fdt) );
> +            break;
> +        default:
> +            LOG(ERROR, "Unknown how to create the DT node for gic_version = %d",
> +                config.gic_version);
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
>  
>          FDT( make_timer_node(gc, fdt, ainfo) );
>          FDT( make_hypervisor_node(gc, fdt, vers) );
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 45974e7..5b8ff57 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -10,6 +10,8 @@
>  #include <xen/errno.h>
>  #include <xen/sched.h>
>  #include <xen/hypercall.h>
> +#include <asm/gic.h>
> +#include <xen/guest_access.h>
>  #include <public/domctl.h>
>  
>  long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>  
>          return p2m_cache_flush(d, s, e);
>      }
> +    case XEN_DOMCTL_arm_configure_domain:
> +    {
> +        uint8_t gic_version;
> +
> +        /*
> +         * Xen 4.5: The vGIC is emulating the same version of the
> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> +         * is allowed. The DOMCTL will return the actual version of the
> +         * GIC.
> +         */
> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> +            return -EOPNOTSUPP;
> +
> +        switch ( gic_hw_version() )
> +        {
> +        case GIC_V3:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> +            break;
> +        case GIC_V2:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> +            break;
> +        default:
> +            BUG();
> +        }
> +
> +        domctl->u.configuredomain.gic_version = gic_version;
> +
> +        /* TODO: Make the copy generic for all ARCH domctl */
> +        if ( __copy_to_guest(u_domctl, domctl, 1) )
> +            return -EFAULT;
> +
> +        return 0;
> +    }
>  
>      default:
>          return subarch_do_domctl(domctl, d, u_domctl);
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 91161a2..076aa62 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
>          d->arch.vgic.rdist_count = gicv3.rdist_count;
>      }
>      else
> -        d->arch.vgic.dbase = GUEST_GICD_BASE;
> +    {
> +        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
> +        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
> +
> +        /* XXX: Only one Re-distributor region mapped for the guest */
> +        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
> +
> +        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
> +        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
> +
> +        /* The first redistributor should contain enough space for all CPUs */
> +        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
> +        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
> +        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
> +    }
>  
>      d->arch.vgic.nr_lines = 0;
>  
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index eecc561..d7df274 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
>   */
>  
>  /* Physical Address Space */
> +
> +/* vGIC mappings: Only one set of mapping is used by the guest.
> + * Therefore they can overlap.
> + */
> +
> +/* vGIC v2 mappings */
>  #define GUEST_GICD_BASE   0x03001000ULL
>  #define GUEST_GICD_SIZE   0x00001000ULL
>  #define GUEST_GICC_BASE   0x03002000ULL
>  #define GUEST_GICC_SIZE   0x00000100ULL
>  
> +/* vGIC v3 mappings */
> +#define GUEST_GICV3_GICD_BASE      0x03001000ULL
> +#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
> +
> +#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
> +#define GUEST_GICV3_RDIST_REGIONS  1
> +
> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */
> +#define GUEST_GICV3_GICR0_SIZE     0x00200000ULL
> +
>  /* 16MB == 4096 pages reserved for guest to use as a region to map its
>   * grant table in.
>   */
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 58b19e7..8da204e 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
>  typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
> +/* XEN_DOMCTL_configure_domain */
> +struct xen_domctl_arm_configuredomain {
> +    /* IN/OUT parameters */
> +    uint8_t gic_version;
> +};
> +typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
> +#endif
> +
>  /* XEN_DOMCTL_getdomaininfo */
>  struct xen_domctl_getdomaininfo {
>      /* OUT variables. */
> @@ -1056,6 +1069,7 @@ struct xen_domctl {
>  #define XEN_DOMCTL_set_vcpu_msrs                 73
>  #define XEN_DOMCTL_setvnumainfo                  74
>  #define XEN_DOMCTL_psr_cmt_op                    75
> +#define XEN_DOMCTL_arm_configure_domain          76
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -1064,6 +1078,9 @@ struct xen_domctl {
>      domid_t  domain;
>      union {
>          struct xen_domctl_createdomain      createdomain;
> +#if defined(__arm__) || defined(__aarch64__)
> +        struct xen_domctl_arm_configuredomain configuredomain;
> +#endif
>          struct xen_domctl_getdomaininfo     getdomaininfo;
>          struct xen_domctl_getmemlist        getmemlist;
>          struct xen_domctl_getpageframeinfo  getpageframeinfo;
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 6d0fe72..846cf88 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
>      case XEN_DOMCTL_psr_cmt_op:
>          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
>  
> +    case XEN_DOMCTL_configure_domain:
> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
> +
>      default:
>          printk("flask_domctl: Unknown op %d\n", cmd);
>          return -EPERM;
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index de0c707..bfe2fa5 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -216,6 +216,8 @@ class domain2
>      get_vnumainfo
>  # XEN_DOMCTL_psr_cmt_op
>      psr_cmt_op
> +# XEN_DOMCTL_configure_domain
> +    configure_domain
>  }
>  
>  # Similar to class domain, but primarily contains domctls related to HVM domains
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:01:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11: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 1XlFO5-00042I-2j; Mon, 03 Nov 2014 11:01:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFO3-00041z-E8
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 11:01:27 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B3/34-09936-68067545; Mon, 03 Nov 2014 11:01:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415012484!8915764!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20911 invoked from network); 3 Nov 2014 11:01:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:01:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188844468"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 06:01:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlFNz-0007GE-DU;
	Mon, 03 Nov 2014 11:01:23 +0000
Date: Mon, 3 Nov 2014 11:01:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 1 Nov 2014, Julien Grall wrote:
> The vGIC will emulate the same version as the hardware. The toolstack has
> to retrieve the version of the vGIC in order to be able to create the
> corresponding device tree node.
> 
> A new DOMCTL has been introduced for ARM to configure the domain. For now
> it only allow the toolstack to retrieve the version of vGIC.
> This DOMCTL will be extend later to let the user choose the version of the
> emulated GIC.
> 
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Wei Liu <wei.liu2@citrix.com>

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>     Changes in v2:
>         - Use memcpu in xc_domain_configure
>         - Rename the DOMCTL into domctl_arm_configuredomain
>         - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>         and fold the code in arch_domain_init_hw_description
>         - Return -EOPNOTSUPP when the value of gic_version is not
>         supported
> 
> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> defer the initialization of the vGIC [2].
> 
> Xen 4.5 has already support for the hardware GICv3. While it's possible to
> boot and use DOM0, there is no guest support. The first version of this patch
> has been sent a couple of months ago, but has never reached unstable for
> various reasons (based on deferred series, lake of review at that time...).
> Without it, platform with GICv3 support won't be able to boot any guest.
> 
> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
> 
> Features such as adding a new config option to let the user choose the GIC
> version are deferred to Xen 4.6.
> 
> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> [2] https://patches.linaro.org/34664/
> ---
>  tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>  tools/libxc/include/xenctrl.h                |    6 ++
>  tools/libxc/xc_domain.c                      |   20 ++++++
>  tools/libxl/libxl_arm.c                      |   97 ++++++++++++++++++++++++--
>  xen/arch/arm/domctl.c                        |   35 ++++++++++
>  xen/arch/arm/gic-v3.c                        |   16 ++++-
>  xen/include/public/arch-arm.h                |   16 +++++
>  xen/include/public/domctl.h                  |   17 +++++
>  xen/xsm/flask/hooks.c                        |    3 +
>  xen/xsm/flask/policy/access_vectors          |    2 +
>  10 files changed, 206 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> index 641c797..fa69c9d 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>  			getdomaininfo hypercall setvcpucontext setextvcpucontext
>  			getscheduler getvcpuinfo getvcpuextstate getaddrsize
>  			getaffinity setaffinity };
> -	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>  	allow $1 $2:security check_context;
>  	allow $1 $2:shadow enable;
>  	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 564e187..45e282c 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>                       uint32_t flags,
>                       uint32_t *pdomid);
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> +
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config);
> +#endif
>  
>  /* Functions to produce a dump of a given domain
>   *  xc_domain_dumpcore - produces a dump to a specified file
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index a9bcd4a..1aa1f45 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>      return 0;
>  }
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config)
> +{
> +    int rc;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> +    domctl.domain = (domid_t)domid;
> +    /* xc_domain_configure_t is an alias to xen_domctl_arm_configuredomain */
> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
> +
> +    rc = do_domctl(xch, &domctl);
> +    if ( !rc )
> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> +
> +    return rc;
> +}
> +#endif
> +
>  int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
>                           xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
>  {
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index a122e4a..3dd6e7c 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -23,6 +23,18 @@
>  #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
>  #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
>  
> +static const char *gicv_to_string(uint8_t gic_version)
> +{
> +    switch (gic_version) {
> +    case XEN_DOMCTL_CONFIG_GIC_V2:
> +        return "V2";
> +    case XEN_DOMCTL_CONFIG_GIC_V3:
> +        return "V3";
> +    default:
> +        return "unknown";
> +    }
> +}
> +
>  int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>                                uint32_t domid)
>  {
> @@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
>      return 0;
>  }
>  
> -static int make_intc_node(libxl__gc *gc, void *fdt,
> -                          uint64_t gicd_base, uint64_t gicd_size,
> -                          uint64_t gicc_base, uint64_t gicc_size)
> +static int make_gicv2_node(libxl__gc *gc, void *fdt,
> +                           uint64_t gicd_base, uint64_t gicd_size,
> +                           uint64_t gicc_base, uint64_t gicc_size)
>  {
>      int res;
>      const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> @@ -350,6 +362,57 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
>      return 0;
>  }
>  
> +static int make_gicv3_node(libxl__gc *gc, void *fdt)
> +{
> +    int res;
> +    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
> +    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
> +    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
> +    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
> +    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> +
> +    res = fdt_begin_node(fdt, name);
> +    if (res) return res;
> +
> +    res = fdt_property_compat(gc, fdt, 1,
> +                              "arm,gic-v3");
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#address-cells", 0);
> +    if (res) return res;
> +
> +    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "redistributor-stride",
> +                            GUEST_GICV3_RDIST_STRIDE);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#redistributor-regions",
> +                            GUEST_GICV3_RDIST_REGIONS);
> +    if (res) return res;
> +
> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> +                            2,
> +                            gicd_base, gicd_size,
> +                            gicr0_base, gicr0_size);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_end_node(fdt);
> +    if (res) return res;
> +
> +    return 0;
> +}
> +
>  static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
>  {
>      int res;
> @@ -456,6 +519,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>                                             libxl_domain_build_info *info,
>                                             struct xc_dom_image *dom)
>  {
> +    xc_domain_configuration_t config;
>      void *fdt = NULL;
>      int rc, res;
>      size_t fdt_size = 0;
> @@ -471,8 +535,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>      ainfo = get_arch_info(gc, dom);
>      if (ainfo == NULL) return ERROR_FAIL;
>  
> +    LOG(DEBUG, "configure the domain");
> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> +        LOG(ERROR, "counldn't configure the domain");
> +        return ERROR_FAIL;
> +    }
> +
>      LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
>          vers->xen_version_major, vers->xen_version_minor);
> +    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
>  
>  /*
>   * Call "call" handling FDR_ERR_*. Will either:
> @@ -520,9 +592,22 @@ next_resize:
>          FDT( make_psci_node(gc, fdt) );
>  
>          FDT( make_memory_nodes(gc, fdt, dom) );
> -        FDT( make_intc_node(gc, fdt,
> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> +
> +        switch (config.gic_version) {
> +        case XEN_DOMCTL_CONFIG_GIC_V2:
> +            FDT( make_gicv2_node(gc, fdt,
> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> +            break;
> +        case XEN_DOMCTL_CONFIG_GIC_V3:
> +            FDT( make_gicv3_node(gc, fdt) );
> +            break;
> +        default:
> +            LOG(ERROR, "Unknown how to create the DT node for gic_version = %d",
> +                config.gic_version);
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
>  
>          FDT( make_timer_node(gc, fdt, ainfo) );
>          FDT( make_hypervisor_node(gc, fdt, vers) );
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 45974e7..5b8ff57 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -10,6 +10,8 @@
>  #include <xen/errno.h>
>  #include <xen/sched.h>
>  #include <xen/hypercall.h>
> +#include <asm/gic.h>
> +#include <xen/guest_access.h>
>  #include <public/domctl.h>
>  
>  long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>  
>          return p2m_cache_flush(d, s, e);
>      }
> +    case XEN_DOMCTL_arm_configure_domain:
> +    {
> +        uint8_t gic_version;
> +
> +        /*
> +         * Xen 4.5: The vGIC is emulating the same version of the
> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> +         * is allowed. The DOMCTL will return the actual version of the
> +         * GIC.
> +         */
> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> +            return -EOPNOTSUPP;
> +
> +        switch ( gic_hw_version() )
> +        {
> +        case GIC_V3:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> +            break;
> +        case GIC_V2:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> +            break;
> +        default:
> +            BUG();
> +        }
> +
> +        domctl->u.configuredomain.gic_version = gic_version;
> +
> +        /* TODO: Make the copy generic for all ARCH domctl */
> +        if ( __copy_to_guest(u_domctl, domctl, 1) )
> +            return -EFAULT;
> +
> +        return 0;
> +    }
>  
>      default:
>          return subarch_do_domctl(domctl, d, u_domctl);
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 91161a2..076aa62 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
>          d->arch.vgic.rdist_count = gicv3.rdist_count;
>      }
>      else
> -        d->arch.vgic.dbase = GUEST_GICD_BASE;
> +    {
> +        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
> +        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
> +
> +        /* XXX: Only one Re-distributor region mapped for the guest */
> +        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
> +
> +        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
> +        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
> +
> +        /* The first redistributor should contain enough space for all CPUs */
> +        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
> +        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
> +        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
> +    }
>  
>      d->arch.vgic.nr_lines = 0;
>  
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index eecc561..d7df274 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
>   */
>  
>  /* Physical Address Space */
> +
> +/* vGIC mappings: Only one set of mapping is used by the guest.
> + * Therefore they can overlap.
> + */
> +
> +/* vGIC v2 mappings */
>  #define GUEST_GICD_BASE   0x03001000ULL
>  #define GUEST_GICD_SIZE   0x00001000ULL
>  #define GUEST_GICC_BASE   0x03002000ULL
>  #define GUEST_GICC_SIZE   0x00000100ULL
>  
> +/* vGIC v3 mappings */
> +#define GUEST_GICV3_GICD_BASE      0x03001000ULL
> +#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
> +
> +#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
> +#define GUEST_GICV3_RDIST_REGIONS  1
> +
> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */
> +#define GUEST_GICV3_GICR0_SIZE     0x00200000ULL
> +
>  /* 16MB == 4096 pages reserved for guest to use as a region to map its
>   * grant table in.
>   */
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 58b19e7..8da204e 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
>  typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
> +/* XEN_DOMCTL_configure_domain */
> +struct xen_domctl_arm_configuredomain {
> +    /* IN/OUT parameters */
> +    uint8_t gic_version;
> +};
> +typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
> +#endif
> +
>  /* XEN_DOMCTL_getdomaininfo */
>  struct xen_domctl_getdomaininfo {
>      /* OUT variables. */
> @@ -1056,6 +1069,7 @@ struct xen_domctl {
>  #define XEN_DOMCTL_set_vcpu_msrs                 73
>  #define XEN_DOMCTL_setvnumainfo                  74
>  #define XEN_DOMCTL_psr_cmt_op                    75
> +#define XEN_DOMCTL_arm_configure_domain          76
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -1064,6 +1078,9 @@ struct xen_domctl {
>      domid_t  domain;
>      union {
>          struct xen_domctl_createdomain      createdomain;
> +#if defined(__arm__) || defined(__aarch64__)
> +        struct xen_domctl_arm_configuredomain configuredomain;
> +#endif
>          struct xen_domctl_getdomaininfo     getdomaininfo;
>          struct xen_domctl_getmemlist        getmemlist;
>          struct xen_domctl_getpageframeinfo  getpageframeinfo;
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 6d0fe72..846cf88 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
>      case XEN_DOMCTL_psr_cmt_op:
>          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
>  
> +    case XEN_DOMCTL_configure_domain:
> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
> +
>      default:
>          printk("flask_domctl: Unknown op %d\n", cmd);
>          return -EPERM;
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index de0c707..bfe2fa5 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -216,6 +216,8 @@ class domain2
>      get_vnumainfo
>  # XEN_DOMCTL_psr_cmt_op
>      psr_cmt_op
> +# XEN_DOMCTL_configure_domain
> +    configure_domain
>  }
>  
>  # Similar to class domain, but primarily contains domctls related to HVM domains
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:02:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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 1XlFOW-00047e-Mr; Mon, 03 Nov 2014 11:01: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 1XlFOU-00047K-Re
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 11:01:54 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	21/4C-24124-2A067545; Mon, 03 Nov 2014 11:01:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415012512!7491658!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20452 invoked from network); 3 Nov 2014 11:01:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:01:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187467322"
Message-ID: <5457609D.2000200@citrix.com>
Date: Mon, 3 Nov 2014 11:01:49 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>	<1414422568-19103-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031044480.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411031044480.22875@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: david.vrabel@citrix.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v7 7/8] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/11/14 10:45, Stefano Stabellini wrote:
> On Mon, 27 Oct 2014, Stefano Stabellini wrote:
>> Introduce an arch specific function to find out whether a particular dma
>> mapping operation needs to bounce on the swiotlb buffer.
>>
>> On ARM and ARM64, if the page involved is a foreign page and the device
>> is not coherent, we need to bounce because at unmap time we cannot
>> execute any required cache maintenance operations (we don't know how to
>> find the pfn from the mfn).
>>
>> No change of behaviour for x86.
>>
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Konrad, David, are you OK with the swiotlb-xen changes?

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

But swiotlb is Konrad's responsibility.

David

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:02:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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 1XlFOW-00047e-Mr; Mon, 03 Nov 2014 11:01: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 1XlFOU-00047K-Re
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 11:01:54 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	21/4C-24124-2A067545; Mon, 03 Nov 2014 11:01:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415012512!7491658!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20452 invoked from network); 3 Nov 2014 11:01:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:01:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187467322"
Message-ID: <5457609D.2000200@citrix.com>
Date: Mon, 3 Nov 2014 11:01:49 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>	<1414422568-19103-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031044480.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411031044480.22875@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: david.vrabel@citrix.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v7 7/8] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/11/14 10:45, Stefano Stabellini wrote:
> On Mon, 27 Oct 2014, Stefano Stabellini wrote:
>> Introduce an arch specific function to find out whether a particular dma
>> mapping operation needs to bounce on the swiotlb buffer.
>>
>> On ARM and ARM64, if the page involved is a foreign page and the device
>> is not coherent, we need to bounce because at unmap time we cannot
>> execute any required cache maintenance operations (we don't know how to
>> find the pfn from the mfn).
>>
>> No change of behaviour for x86.
>>
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Konrad, David, are you OK with the swiotlb-xen changes?

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

But swiotlb is Konrad's responsibility.

David

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:05:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFSJ-0004WB-Fv; Mon, 03 Nov 2014 11:05:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XlFSI-0004W5-Gp
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 11:05:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D6/10-09936-D8167545; Mon, 03 Nov 2014 11:05:49 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415012748!11790375!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15809 invoked from network); 3 Nov 2014 11:05:48 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:05:48 -0000
Received: by mail-wg0-f47.google.com with SMTP id a1so10793495wgh.34
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 03:05:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=+TAsHUHOPAmPGqLcqRlFmePdfL2PthtRFmf05VRgQDE=;
	b=I2VynY5DbrbL2v0CPRzfSjX/WI7B9OgBY7CWyW4lmVyqPujNzxzHFYu/dtT2W8jIyA
	Dg9dIEsEOv1wD1XBU181pDXBBjFtQpjbI86rT4MHQZ/cOuGtJSLlxFqTcjnW/kVicTwg
	pU2+BdI38xy4/SZ//v0aTmjmzBWmnAEL2bGTNI0FpxdD3LjQJJHTBL0LSYYBGgY6laMF
	T36QjMridCUhEajLZ8Mw8t2Iu5z3prwigTz6SQsx4b99tnk2j9eV11CfKEYwOvl5zSaC
	Blb2FPDFc4vl7FwujvJ4I1Zc8ry193VHfihW7kCUtme7jp+6o6NDn5POoyVgI+1CG40h
	cQtQ==
X-Gm-Message-State: ALoCoQkYuEsdTAedjXr2MEm3QtsjV26VXNpxbDMf4/inPEH+RoEmjAhQLkN1UoVhET8xoukAvn9g
X-Received: by 10.180.79.169 with SMTP id k9mr15741861wix.34.1415012748086;
	Mon, 03 Nov 2014 03:05:48 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	wx3sm21795424wjc.19.2014.11.03.03.05.26 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 03:05:47 -0800 (PST)
Message-ID: <54576188.9050500@m2r.biz>
Date: Mon, 03 Nov 2014 12:05:44 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<544B5AF5.7050103@m2r.biz>
	<20141027161542.GK4050@laptop.dumpdata.com>
	<544F987E.5060508@m2r.biz>
	<20141028171811.GA27336@laptop.dumpdata.com>
	<CABMPFziN9eM6_0_mfQcamOqyQBXVOOD5amom+7JTv=LorbbTeQ@mail.gmail.com>
	<20141031143338.GB6913@laptop.dumpdata.com>
In-Reply-To: <20141031143338.GB6913@laptop.dumpdata.com>
Cc: Artem Mygaiev <artem.mygaiev@globallogic.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, mengxu@cis.upenn.edu,
	M A Young <m.a.young@durham.ac.uk>, chao.p.peng@linux.intel.com,
	zhigang.x.wang@oracle.com, Parth Dixit <parth.dixit@linaro.org>,
	davi.d.vrabel@citrix.com, Paul.Skentzos@dornerworks.com,
	wency@cn.fujitsu.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, Daniel Kiper <daniel.kiper@oracle.com>,
	josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	yjhyun.yoo@samsung.com, Olaf Hering <olaf@aepfle.de>,
	Ian Campbell <ian.campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mcgrof@suse.com, Julien Grall <julien.grall@linaro.org>,
	Dave Scott <dave.scott@citrix.com>, robert.vanvossen@dornerworks.com,
	Roy Franz <roy.franz@linaro.org>, Yang Z Zhang <yang.z.zhang@intel.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Matt Wilson <msw@amazon.com>, boris.ostrovsky@oracle.com,
	andrii.tseglytskyi@globallogic.com, Juergen Gross <jgross@suse.com>,
	Thomas Leonard <talex5@gmail.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, aravindp@cisco.com,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Suriyan Ramasami <suriyan.r@gmail.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Steve.VanderLeest@dornerworks.com, Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	Don Slutz <dslutz@verizon.com>, tklengyel@sec.in.tum.de,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Suravee.Suthikulpanit@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tiejun Chen <tiejun.chen@intel.com>, malcolm.crossley@citrix.com,
	yanghy@cn.fujitsu.com, Vijaya.Kumar@caviumnetworks.com,
	feng.wu@intel.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Is: QXL in Xen (busted) Was :Re: Xen 4.5-rc1 update
 (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 31/10/2014 15:33, Konrad Rzeszutek Wilk ha scritto:
>> I always posted all versions of the patch in xen-devel, the latest was long
>> time ago.
> Sometimes you need to poke the maintainers. They (at least
> I do) have mailboxes so packed that sometimes emails end up
> going missing. But I think their arguments is going to be:
> lets figure out what is broken before putting this in the source.
>
> .. snip..
>>> Does SPICE always have to be enabled to use QXL?
>>>
> .. snip ..
>> Xen with spice full working on both windows and linux (including
>> save/restore) used for both vkvm and thin client I think would be perfect.
> Right. But there is some work needed in that area (figure out what
> is happening on Linux).
>
> ..snip..
>>> OK, looking at how the driver is setup - it seems that there is an QXL
>>> KMS driver. If you boot without Xorg running but just with in the console
>>> can
>>> you use 'fbset' or any other framebuffer tools (linux-fb-tools)?
>>> That is I am curious to see whether the 'FB' is working properly first
>>> before figuring out whether Xorg is working.
>>>
>> Some tests ago I tried without xorg to see if kernel parts is ok (advice of
>> other developer) and seems was ok.
> What did you test? There is an 'drm-test' tool that was floating around?
> (http://cgit.freedesktop.org/mesa/drm/)
>
> It allows you to run most (if not all) of the Xorg functionality - but
> using an tool from user-space - and with much more exposure of what
> went wrong.
>
> Could you try the following (without having Xorg in either guest):
>   1). Boot up your KVM guest, install said tool - run it. Record what
>      works and what does not.
>
>   2). Boot up your Xen guest, and do the same thing.
>
> That should narrow down which of the hundreds' of DRM ioctls is failing
> when using spice under Xen. And that ought to help narrow down this further.
>
> I can help you a bit by sending you some debug patches, thought I do
> have to warn you that I am under a lot of time-pressure so my response
> is not as fast as I would want it to be.
>

I tested only without xorg, just console with drm without particular tests.

I can't find the drm-test tool you mentioned, is it available in debian 
and/or fedora repositories an what is it called?
I also did a quick google search and found only something about wayland 
and not about X.org.

Thanks for any reply and sorry for my bad english.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:05:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFSJ-0004WB-Fv; Mon, 03 Nov 2014 11:05:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XlFSI-0004W5-Gp
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 11:05:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D6/10-09936-D8167545; Mon, 03 Nov 2014 11:05:49 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415012748!11790375!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15809 invoked from network); 3 Nov 2014 11:05:48 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:05:48 -0000
Received: by mail-wg0-f47.google.com with SMTP id a1so10793495wgh.34
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 03:05:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=+TAsHUHOPAmPGqLcqRlFmePdfL2PthtRFmf05VRgQDE=;
	b=I2VynY5DbrbL2v0CPRzfSjX/WI7B9OgBY7CWyW4lmVyqPujNzxzHFYu/dtT2W8jIyA
	Dg9dIEsEOv1wD1XBU181pDXBBjFtQpjbI86rT4MHQZ/cOuGtJSLlxFqTcjnW/kVicTwg
	pU2+BdI38xy4/SZ//v0aTmjmzBWmnAEL2bGTNI0FpxdD3LjQJJHTBL0LSYYBGgY6laMF
	T36QjMridCUhEajLZ8Mw8t2Iu5z3prwigTz6SQsx4b99tnk2j9eV11CfKEYwOvl5zSaC
	Blb2FPDFc4vl7FwujvJ4I1Zc8ry193VHfihW7kCUtme7jp+6o6NDn5POoyVgI+1CG40h
	cQtQ==
X-Gm-Message-State: ALoCoQkYuEsdTAedjXr2MEm3QtsjV26VXNpxbDMf4/inPEH+RoEmjAhQLkN1UoVhET8xoukAvn9g
X-Received: by 10.180.79.169 with SMTP id k9mr15741861wix.34.1415012748086;
	Mon, 03 Nov 2014 03:05:48 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	wx3sm21795424wjc.19.2014.11.03.03.05.26 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 03:05:47 -0800 (PST)
Message-ID: <54576188.9050500@m2r.biz>
Date: Mon, 03 Nov 2014 12:05:44 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<544B5AF5.7050103@m2r.biz>
	<20141027161542.GK4050@laptop.dumpdata.com>
	<544F987E.5060508@m2r.biz>
	<20141028171811.GA27336@laptop.dumpdata.com>
	<CABMPFziN9eM6_0_mfQcamOqyQBXVOOD5amom+7JTv=LorbbTeQ@mail.gmail.com>
	<20141031143338.GB6913@laptop.dumpdata.com>
In-Reply-To: <20141031143338.GB6913@laptop.dumpdata.com>
Cc: Artem Mygaiev <artem.mygaiev@globallogic.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, mengxu@cis.upenn.edu,
	M A Young <m.a.young@durham.ac.uk>, chao.p.peng@linux.intel.com,
	zhigang.x.wang@oracle.com, Parth Dixit <parth.dixit@linaro.org>,
	davi.d.vrabel@citrix.com, Paul.Skentzos@dornerworks.com,
	wency@cn.fujitsu.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, Daniel Kiper <daniel.kiper@oracle.com>,
	josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	yjhyun.yoo@samsung.com, Olaf Hering <olaf@aepfle.de>,
	Ian Campbell <ian.campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mcgrof@suse.com, Julien Grall <julien.grall@linaro.org>,
	Dave Scott <dave.scott@citrix.com>, robert.vanvossen@dornerworks.com,
	Roy Franz <roy.franz@linaro.org>, Yang Z Zhang <yang.z.zhang@intel.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Matt Wilson <msw@amazon.com>, boris.ostrovsky@oracle.com,
	andrii.tseglytskyi@globallogic.com, Juergen Gross <jgross@suse.com>,
	Thomas Leonard <talex5@gmail.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, aravindp@cisco.com,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Suriyan Ramasami <suriyan.r@gmail.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Steve.VanderLeest@dornerworks.com, Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	Don Slutz <dslutz@verizon.com>, tklengyel@sec.in.tum.de,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Suravee.Suthikulpanit@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tiejun Chen <tiejun.chen@intel.com>, malcolm.crossley@citrix.com,
	yanghy@cn.fujitsu.com, Vijaya.Kumar@caviumnetworks.com,
	feng.wu@intel.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Is: QXL in Xen (busted) Was :Re: Xen 4.5-rc1 update
 (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 31/10/2014 15:33, Konrad Rzeszutek Wilk ha scritto:
>> I always posted all versions of the patch in xen-devel, the latest was long
>> time ago.
> Sometimes you need to poke the maintainers. They (at least
> I do) have mailboxes so packed that sometimes emails end up
> going missing. But I think their arguments is going to be:
> lets figure out what is broken before putting this in the source.
>
> .. snip..
>>> Does SPICE always have to be enabled to use QXL?
>>>
> .. snip ..
>> Xen with spice full working on both windows and linux (including
>> save/restore) used for both vkvm and thin client I think would be perfect.
> Right. But there is some work needed in that area (figure out what
> is happening on Linux).
>
> ..snip..
>>> OK, looking at how the driver is setup - it seems that there is an QXL
>>> KMS driver. If you boot without Xorg running but just with in the console
>>> can
>>> you use 'fbset' or any other framebuffer tools (linux-fb-tools)?
>>> That is I am curious to see whether the 'FB' is working properly first
>>> before figuring out whether Xorg is working.
>>>
>> Some tests ago I tried without xorg to see if kernel parts is ok (advice of
>> other developer) and seems was ok.
> What did you test? There is an 'drm-test' tool that was floating around?
> (http://cgit.freedesktop.org/mesa/drm/)
>
> It allows you to run most (if not all) of the Xorg functionality - but
> using an tool from user-space - and with much more exposure of what
> went wrong.
>
> Could you try the following (without having Xorg in either guest):
>   1). Boot up your KVM guest, install said tool - run it. Record what
>      works and what does not.
>
>   2). Boot up your Xen guest, and do the same thing.
>
> That should narrow down which of the hundreds' of DRM ioctls is failing
> when using spice under Xen. And that ought to help narrow down this further.
>
> I can help you a bit by sending you some debug patches, thought I do
> have to warn you that I am under a lot of time-pressure so my response
> is not as fast as I would want it to be.
>

I tested only without xorg, just console with drm without particular tests.

I can't find the drm-test tool you mentioned, is it available in debian 
and/or fedora repositories an what is it called?
I also did a quick google search and found only something about wayland 
and not about X.org.

Thanks for any reply and sorry for my bad english.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:16:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:16:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFcH-00050U-Oo; Mon, 03 Nov 2014 11:16:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlFcF-000505-Sj
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:16:08 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	1E/9F-09284-7F367545; Mon, 03 Nov 2014 11:16:07 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415013366!11269558!1
X-Originating-IP: [74.125.82.52]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15637 invoked from network); 3 Nov 2014 11:16:06 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:16:06 -0000
Received: by mail-wg0-f52.google.com with SMTP id b13so10156373wgh.25
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 03:16:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=FX/+9ANe9Y0r9bex8djCmB/wNXB3cYuXVO277Sh2kM4=;
	b=hi3sc9M+qnFGDGUkc7Qxr10iuDnJemgWKcTaShUMk+Oo5Ove35eLDN5PCw0Muwg7S7
	kXX6lUkqWI5OTypnJynj88hsuo/pGbwIru99qYmBshUpVJBVUdwJmnszb/QKEIb9FApX
	HUkCS9ep3g+cCm1Np0w+yh5PhHnvDAOp6fOCA4B5lIF420PAUsVCbjMq5i5Y2eYFKB+v
	4LmchJ09iZI9YciTkwYbv/3ewecOAgfCdjuBhPMM3QxkfVcJ1ZuDyjuO934ZKN1KaSuU
	wFi/MIVLsWS73KI4MLHk6htADf1+tM2hnCumliybjsmQFA1Rn+++2/Rb2JvI8coJnAuK
	lE4g==
MIME-Version: 1.0
X-Received: by 10.180.104.229 with SMTP id gh5mr15170314wib.42.1415013366495; 
	Mon, 03 Nov 2014 03:16:06 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 3 Nov 2014 03:16:06 -0800 (PST)
In-Reply-To: <545127160200007800043328@mail.emea.novell.com>
References: <542AD266.5030803@grosc.com>
	<5433B94E020000780003CBF0@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260A4A7B@SHSMSX101.ccr.corp.intel.com>
	<5437B593.80702@grosc.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABAF528@SHSMSX104.ccr.corp.intel.com>
	<543F84CD020000780003F02A@mail.emea.novell.com>
	<5450F6E2.6050807@grosc.com>
	<545127160200007800043328@mail.emea.novell.com>
Date: Mon, 3 Nov 2014 11:16:06 +0000
X-Google-Sender-Auth: amf3eF8dEWBWAoe6F4PLMnxfJjQ
Message-ID: <CAFLBxZZ5itYWTDsnkGHzy0_4SWU6QMXnVpkYAFMOH+wG+5MKJQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jeroen Groenewegen van der Weyden <groen692@grosc.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] Crash of guest with nested vmx with Unknown nested
 vmexit reason 80000021.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 29, 2014 at 4:42 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 29.10.14 at 15:17, <groen692@grosc.com> wrote:
>> Is there any test I can do on changed code?
>
> Strange question with there not being any changed code yet.

I think what Jan means is, sorry, we haven't had a chance to actually
work on this yet, but thanks for the ping. :-)

 -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:16:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:16:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFcH-00050U-Oo; Mon, 03 Nov 2014 11:16:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlFcF-000505-Sj
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:16:08 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	1E/9F-09284-7F367545; Mon, 03 Nov 2014 11:16:07 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415013366!11269558!1
X-Originating-IP: [74.125.82.52]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15637 invoked from network); 3 Nov 2014 11:16:06 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:16:06 -0000
Received: by mail-wg0-f52.google.com with SMTP id b13so10156373wgh.25
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 03:16:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=FX/+9ANe9Y0r9bex8djCmB/wNXB3cYuXVO277Sh2kM4=;
	b=hi3sc9M+qnFGDGUkc7Qxr10iuDnJemgWKcTaShUMk+Oo5Ove35eLDN5PCw0Muwg7S7
	kXX6lUkqWI5OTypnJynj88hsuo/pGbwIru99qYmBshUpVJBVUdwJmnszb/QKEIb9FApX
	HUkCS9ep3g+cCm1Np0w+yh5PhHnvDAOp6fOCA4B5lIF420PAUsVCbjMq5i5Y2eYFKB+v
	4LmchJ09iZI9YciTkwYbv/3ewecOAgfCdjuBhPMM3QxkfVcJ1ZuDyjuO934ZKN1KaSuU
	wFi/MIVLsWS73KI4MLHk6htADf1+tM2hnCumliybjsmQFA1Rn+++2/Rb2JvI8coJnAuK
	lE4g==
MIME-Version: 1.0
X-Received: by 10.180.104.229 with SMTP id gh5mr15170314wib.42.1415013366495; 
	Mon, 03 Nov 2014 03:16:06 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 3 Nov 2014 03:16:06 -0800 (PST)
In-Reply-To: <545127160200007800043328@mail.emea.novell.com>
References: <542AD266.5030803@grosc.com>
	<5433B94E020000780003CBF0@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260A4A7B@SHSMSX101.ccr.corp.intel.com>
	<5437B593.80702@grosc.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABAF528@SHSMSX104.ccr.corp.intel.com>
	<543F84CD020000780003F02A@mail.emea.novell.com>
	<5450F6E2.6050807@grosc.com>
	<545127160200007800043328@mail.emea.novell.com>
Date: Mon, 3 Nov 2014 11:16:06 +0000
X-Google-Sender-Auth: amf3eF8dEWBWAoe6F4PLMnxfJjQ
Message-ID: <CAFLBxZZ5itYWTDsnkGHzy0_4SWU6QMXnVpkYAFMOH+wG+5MKJQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jeroen Groenewegen van der Weyden <groen692@grosc.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] Crash of guest with nested vmx with Unknown nested
 vmexit reason 80000021.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 29, 2014 at 4:42 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 29.10.14 at 15:17, <groen692@grosc.com> wrote:
>> Is there any test I can do on changed code?
>
> Strange question with there not being any changed code yet.

I think what Jan means is, sorry, we haven't had a chance to actually
work on this yet, but thanks for the ping. :-)

 -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:19:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFfe-0005AF-D4; Mon, 03 Nov 2014 11:19:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XlFfc-0005A7-Bc
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:19:36 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	5D/C6-24859-7C467545; Mon, 03 Nov 2014 11:19:35 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415013572!11192313!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1019 invoked from network); 3 Nov 2014 11:19:34 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-12.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 11:19:34 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XlFfR-0003hn-Np; Mon, 03 Nov 2014 11:19:25 +0000
Message-ID: <545764BB.7080005@canonical.com>
Date: Mon, 03 Nov 2014 12:19:23 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel@lists.xen.org
References: <54574EA0.5070101@canonical.com> <54575E32.6040603@citrix.com>
In-Reply-To: <54575E32.6040603@citrix.com>
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9181217695175149410=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

On 03.11.2014 11:51, Andrew Cooper wrote:
> On 03/11/14 09:45, Stefan Bader wrote:
>> I see the message from the subject on my Intel box whenever a guest (i=
irc even
>> dom0) starts up. It is not fatal and everything seems ok. I am just cu=
rious
>> about what might trigger this. The addresses look to be inside the hyp=
ervisor
>> code. I was wondering whether there is a simple way to figure out what=
 this
>> relates to (likely need to look at the objdump of the unstripped hv mo=
dule).
>>
>> Or has someone already looked into this and knows what likely is the c=
ause?
>>
>> -Stefan
>=20
> Specifically, the message indicates <type of fault>: faulting address -=
>
> fixup address
>=20
> It is probably a wrmsr, and a higher logging level will indicate this. =

> My gut feeling is that it is dom0 attempting to load microcode using th=
e
> native method.
>=20
> ~Andrew
>=20

The faulting address in my case seems to be rdmsr_save (xen-4.4.1 base), =
the
fixup address somewhere unspecific in hvm.c (not sure whether that makes =
sense
coming from a dom0 startup). I will have to re-compile this with the gdpr=
intk
enabled to see which MSR that was.

rdmsr_normal:
            /* Everyone can read the MSR space. */
            /* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR %p.\n",
                        _p(regs->ecx));*/
            if ( rdmsr_safe(regs->ecx, msr_content) )
                goto fail;

Though likely related to the following WRMSRs following (the addresses di=
ffer
from the subject I wasn't sure from where exactly I took the others and t=
hese
are with 4.4.1 and directly after boot):

(XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
(XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
(XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
(XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
(XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0042=
81c2001
a8168 to 0x004281c200148168.
(XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0042=
81c2001
a8168 to 0x004281c2001a0168.
(XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0042=
81c2001
a8168 to 0x004201c2001a8168.
(XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
(XEN) traps.c:2514:d0 Domain attempted WRMSR 00000000000001b2 from 0x0000=
0000000
00000 to 0x0000000000009600.

The 0x1b2 seems to be thermal interrupt control. Cannot find the 0x610 ri=
ght now
(need to refresh my docs)...


--BchM8ImO3sxrdQ3htAxS3AfwGCVWA06xw
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

iQIcBAEBCgAGBQJUV2S7AAoJEOhnXe7L7s6j0bAQAOLtvcL3AggShGYgw/ZXlQUV
VTAB5nyW6NaN6jR+XwftJXLIKn5lAOTIBO/+EUEflWuxlCqQxPqRKjyYtVRzNhWR
XHktp1HvcBWk4+DkaCqCmH0Ml5aZVp2zTLGLxKTiQgE27nStXmWqSZIJz1Jkym+M
rQmk7pTwnpsglF2bBvuIjcMYcICSl5kZrbD0efRcSOT1YUSC0xnqceCPE3nn/e+D
7qBxCiuKRk+T81DrG8EfBwj7PboADgEePocKOwq4bUBNKktbmklGWHO59uImE164
gxuJqEj2xQLyxDtL0h3IUMglzAQdCRnrjoA5b63eJdJwMFr5QlulVPJGY0ddCSZA
uULEqxVmWsWMIO98RCy+yLrCkRNsFc82S16oAPVmx0usCnk+C+mK0VUNPRPlhPbJ
4nThZZBwrS9RGZAFnmjRHuPpRQsOobeL2uIC0tda1IvrXXRXvXz5MlBi/eaig1gv
NntAM2D0WYSRsla2qpi9V80gOOVMd2NzD8FWW6S5tFkF2L153vAbLfG/V3p23G/a
Z0ldVvGY+KhoRk40VBfTbDp+XgyZwQO6N94A6yPiA9SatU4n8lGWIs/n+MmDrmQY
60Ddtw7tZyM7WHsSHJRr4WUP97E9UNj/4/q1GBaW1Y/8xAvKHC31QAw+blMSxSJR
+/sWwkteBESqwr2mS2Um
=C5B9
-----END PGP SIGNATURE-----

--BchM8ImO3sxrdQ3htAxS3AfwGCVWA06xw--


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

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

--===============9181217695175149410==--


From xen-devel-bounces@lists.xen.org Mon Nov 03 11:19:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFfe-0005AF-D4; Mon, 03 Nov 2014 11:19:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XlFfc-0005A7-Bc
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:19:36 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	5D/C6-24859-7C467545; Mon, 03 Nov 2014 11:19:35 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415013572!11192313!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1019 invoked from network); 3 Nov 2014 11:19:34 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-12.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 11:19:34 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XlFfR-0003hn-Np; Mon, 03 Nov 2014 11:19:25 +0000
Message-ID: <545764BB.7080005@canonical.com>
Date: Mon, 03 Nov 2014 12:19:23 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel@lists.xen.org
References: <54574EA0.5070101@canonical.com> <54575E32.6040603@citrix.com>
In-Reply-To: <54575E32.6040603@citrix.com>
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9181217695175149410=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

On 03.11.2014 11:51, Andrew Cooper wrote:
> On 03/11/14 09:45, Stefan Bader wrote:
>> I see the message from the subject on my Intel box whenever a guest (i=
irc even
>> dom0) starts up. It is not fatal and everything seems ok. I am just cu=
rious
>> about what might trigger this. The addresses look to be inside the hyp=
ervisor
>> code. I was wondering whether there is a simple way to figure out what=
 this
>> relates to (likely need to look at the objdump of the unstripped hv mo=
dule).
>>
>> Or has someone already looked into this and knows what likely is the c=
ause?
>>
>> -Stefan
>=20
> Specifically, the message indicates <type of fault>: faulting address -=
>
> fixup address
>=20
> It is probably a wrmsr, and a higher logging level will indicate this. =

> My gut feeling is that it is dom0 attempting to load microcode using th=
e
> native method.
>=20
> ~Andrew
>=20

The faulting address in my case seems to be rdmsr_save (xen-4.4.1 base), =
the
fixup address somewhere unspecific in hvm.c (not sure whether that makes =
sense
coming from a dom0 startup). I will have to re-compile this with the gdpr=
intk
enabled to see which MSR that was.

rdmsr_normal:
            /* Everyone can read the MSR space. */
            /* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR %p.\n",
                        _p(regs->ecx));*/
            if ( rdmsr_safe(regs->ecx, msr_content) )
                goto fail;

Though likely related to the following WRMSRs following (the addresses di=
ffer
from the subject I wasn't sure from where exactly I took the others and t=
hese
are with 4.4.1 and directly after boot):

(XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
(XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
(XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
(XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
(XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0042=
81c2001
a8168 to 0x004281c200148168.
(XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0042=
81c2001
a8168 to 0x004281c2001a0168.
(XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0042=
81c2001
a8168 to 0x004201c2001a8168.
(XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
(XEN) traps.c:2514:d0 Domain attempted WRMSR 00000000000001b2 from 0x0000=
0000000
00000 to 0x0000000000009600.

The 0x1b2 seems to be thermal interrupt control. Cannot find the 0x610 ri=
ght now
(need to refresh my docs)...


--BchM8ImO3sxrdQ3htAxS3AfwGCVWA06xw
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

iQIcBAEBCgAGBQJUV2S7AAoJEOhnXe7L7s6j0bAQAOLtvcL3AggShGYgw/ZXlQUV
VTAB5nyW6NaN6jR+XwftJXLIKn5lAOTIBO/+EUEflWuxlCqQxPqRKjyYtVRzNhWR
XHktp1HvcBWk4+DkaCqCmH0Ml5aZVp2zTLGLxKTiQgE27nStXmWqSZIJz1Jkym+M
rQmk7pTwnpsglF2bBvuIjcMYcICSl5kZrbD0efRcSOT1YUSC0xnqceCPE3nn/e+D
7qBxCiuKRk+T81DrG8EfBwj7PboADgEePocKOwq4bUBNKktbmklGWHO59uImE164
gxuJqEj2xQLyxDtL0h3IUMglzAQdCRnrjoA5b63eJdJwMFr5QlulVPJGY0ddCSZA
uULEqxVmWsWMIO98RCy+yLrCkRNsFc82S16oAPVmx0usCnk+C+mK0VUNPRPlhPbJ
4nThZZBwrS9RGZAFnmjRHuPpRQsOobeL2uIC0tda1IvrXXRXvXz5MlBi/eaig1gv
NntAM2D0WYSRsla2qpi9V80gOOVMd2NzD8FWW6S5tFkF2L153vAbLfG/V3p23G/a
Z0ldVvGY+KhoRk40VBfTbDp+XgyZwQO6N94A6yPiA9SatU4n8lGWIs/n+MmDrmQY
60Ddtw7tZyM7WHsSHJRr4WUP97E9UNj/4/q1GBaW1Y/8xAvKHC31QAw+blMSxSJR
+/sWwkteBESqwr2mS2Um
=C5B9
-----END PGP SIGNATURE-----

--BchM8ImO3sxrdQ3htAxS3AfwGCVWA06xw--


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

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

--===============9181217695175149410==--


From xen-devel-bounces@lists.xen.org Mon Nov 03 11:22:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:22:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFiP-0005LO-1G; Mon, 03 Nov 2014 11:22:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlFiN-0005LC-Fn
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:22:27 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	D7/9A-24124-27567545; Mon, 03 Nov 2014 11:22:26 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415013745!7497625!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6996 invoked from network); 3 Nov 2014 11:22:26 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 11:22:26 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 03:22:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="410317372"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by FMSMGA003.fm.intel.com with ESMTP; 03 Nov 2014 03:14:00 -0800
Message-ID: <5457656E.9040604@intel.com>
Date: Mon, 03 Nov 2014 19:22:22 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
	<54575C3E020000780004440F@mail.emea.novell.com>
	<54575372.7020406@intel.com>
	<545764D102000078000444F0@mail.emea.novell.com>
In-Reply-To: <545764D102000078000444F0@mail.emea.novell.com>
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 18:19, Jan Beulich wrote:
>>>> On 03.11.14 at 11:05, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 17:43, Jan Beulich wrote:
>>>>>> On 03.11.14 at 10:00, <tiejun.chen@intel.com> wrote:
>>>> --- a/tools/firmware/hvmloader/Makefile
>>>> +++ b/tools/firmware/hvmloader/Makefile
>>>> @@ -84,9 +84,12 @@ ROMS += $(SEABIOS_ROM)
>>>>    endif
>>>>
>>>>    .PHONY: all
>>>> -all: subdirs-all
>>>> +all: subdirs-all .dir
>>>
>>> Considering uses going forward, I think subdirs-all should depend on
>>> .dir (which is being misnamed anyway, presumably due to blindly
>>> taking what is in tools/include/Makefile, where a directory _is_ being
>>> created). Considering that it's an individual file, the file name would
>>
>> You're right.
>>
>>> seem quite right to be used as dependency here.
>>
>> So what about this?
>>
>> .PHONY: all
>> all: subdirs-all errno
>>       $(MAKE) hvmloader
>>
>> errno:
>>       ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
>
> This addresses just one of the points I made.

Are you saying that dependency?

@@ -87,6 +87,11 @@ endif
  all: subdirs-all
         $(MAKE) hvmloader

+subdirs-all: errno
+
+errno:
+       ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
+
  ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
  smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:22:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:22:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFiP-0005LO-1G; Mon, 03 Nov 2014 11:22:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlFiN-0005LC-Fn
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:22:27 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	D7/9A-24124-27567545; Mon, 03 Nov 2014 11:22:26 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415013745!7497625!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6996 invoked from network); 3 Nov 2014 11:22:26 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 11:22:26 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 03:22:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="410317372"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by FMSMGA003.fm.intel.com with ESMTP; 03 Nov 2014 03:14:00 -0800
Message-ID: <5457656E.9040604@intel.com>
Date: Mon, 03 Nov 2014 19:22:22 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
	<54575C3E020000780004440F@mail.emea.novell.com>
	<54575372.7020406@intel.com>
	<545764D102000078000444F0@mail.emea.novell.com>
In-Reply-To: <545764D102000078000444F0@mail.emea.novell.com>
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 18:19, Jan Beulich wrote:
>>>> On 03.11.14 at 11:05, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 17:43, Jan Beulich wrote:
>>>>>> On 03.11.14 at 10:00, <tiejun.chen@intel.com> wrote:
>>>> --- a/tools/firmware/hvmloader/Makefile
>>>> +++ b/tools/firmware/hvmloader/Makefile
>>>> @@ -84,9 +84,12 @@ ROMS += $(SEABIOS_ROM)
>>>>    endif
>>>>
>>>>    .PHONY: all
>>>> -all: subdirs-all
>>>> +all: subdirs-all .dir
>>>
>>> Considering uses going forward, I think subdirs-all should depend on
>>> .dir (which is being misnamed anyway, presumably due to blindly
>>> taking what is in tools/include/Makefile, where a directory _is_ being
>>> created). Considering that it's an individual file, the file name would
>>
>> You're right.
>>
>>> seem quite right to be used as dependency here.
>>
>> So what about this?
>>
>> .PHONY: all
>> all: subdirs-all errno
>>       $(MAKE) hvmloader
>>
>> errno:
>>       ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
>
> This addresses just one of the points I made.

Are you saying that dependency?

@@ -87,6 +87,11 @@ endif
  all: subdirs-all
         $(MAKE) hvmloader

+subdirs-all: errno
+
+errno:
+       ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
+
  ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
  smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:28:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFoA-0005bz-Vl; Mon, 03 Nov 2014 11:28:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFo9-0005bt-1u
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 11:28:25 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	D6/D9-16982-8D667545; Mon, 03 Nov 2014 11:28:24 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415014102!11273411!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11646 invoked from network); 3 Nov 2014 11:28:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:28:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187472573"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 06:28:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlFWh-0007Oh-HZ;
	Mon, 03 Nov 2014 11:10:23 +0000
Date: Mon, 3 Nov 2014 11:10:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Will Deacon <will.deacon@arm.com>
In-Reply-To: <20141103105716.GC23162@arm.com>
Message-ID: <alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 3 Nov 2014, Will Deacon wrote:
> On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> > On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > > Introduce a boolean flag and an accessor function to check whether a
> > > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > CC: will.deacon@arm.com
> > 
> > Will, Catalin,
> > are you OK with this patch?
> 
> It would be nicer if the dma_coherent flag didn't have to be duplicated by
> each architecture in dev_archdata. Is there any reason not to put it in the
> core code?

Yes, there is a reason for it: if I added a boolean dma_coherent flag in
struct device as Catalin initially suggested, what would be the default
for each architecture? Where would I set it for arch that don't use
device tree? It is not easy.

I thought it would be better to introduce is_device_dma_coherent only on
the architectures where it certainly makes sense to have it. In fact I
checked and arm and arm64 are the only architectures to define
set_arch_dma_coherent_ops at the moment. At that point if
is_device_dma_coherent becomes arch-specific, it makes sense to store
the flag in dev_archdata instead of struct device.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:28:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFoA-0005bz-Vl; Mon, 03 Nov 2014 11:28:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFo9-0005bt-1u
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 11:28:25 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	D6/D9-16982-8D667545; Mon, 03 Nov 2014 11:28:24 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415014102!11273411!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11646 invoked from network); 3 Nov 2014 11:28:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:28:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187472573"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 06:28:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlFWh-0007Oh-HZ;
	Mon, 03 Nov 2014 11:10:23 +0000
Date: Mon, 3 Nov 2014 11:10:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Will Deacon <will.deacon@arm.com>
In-Reply-To: <20141103105716.GC23162@arm.com>
Message-ID: <alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 3 Nov 2014, Will Deacon wrote:
> On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> > On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > > Introduce a boolean flag and an accessor function to check whether a
> > > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > CC: will.deacon@arm.com
> > 
> > Will, Catalin,
> > are you OK with this patch?
> 
> It would be nicer if the dma_coherent flag didn't have to be duplicated by
> each architecture in dev_archdata. Is there any reason not to put it in the
> core code?

Yes, there is a reason for it: if I added a boolean dma_coherent flag in
struct device as Catalin initially suggested, what would be the default
for each architecture? Where would I set it for arch that don't use
device tree? It is not easy.

I thought it would be better to introduce is_device_dma_coherent only on
the architectures where it certainly makes sense to have it. In fact I
checked and arm and arm64 are the only architectures to define
set_arch_dma_coherent_ops at the moment. At that point if
is_device_dma_coherent becomes arch-specific, it makes sense to store
the flag in dev_archdata instead of struct device.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:30:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFq6-0005i9-Hl; Mon, 03 Nov 2014 11:30:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFq5-0005i4-5Z
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:30:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	42/D9-09936-05767545; Mon, 03 Nov 2014 11:30:24 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415014222!12330402!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29656 invoked from network); 3 Nov 2014 11:30:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:30:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188850172"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 06:30:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlFq1-0007ty-Hk;
	Mon, 03 Nov 2014 11:30:21 +0000
Date: Mon, 3 Nov 2014 11:30:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Quan Xu <quan.xu@intel.com>
In-Reply-To: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
Message-ID: <alpine.DEB.2.02.1411031126170.22875@kaball.uk.xensource.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
 machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 30 Oct 2014, Quan Xu wrote:
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> 
> This patch series are only the Xen part to enable stubdom vTPM for HVM virtual machine.
> it will work w/ Qemu patch series and seaBios patch series. Change QEMU_STUBDOM_VTPM 
> compile option from 'n' to 'y', when the Qemu/SeaBios patch series are merged.

Please, could you add more detailed commit messages in your patches?
Also spending a few more words here to explain why are you doing this
and how would help.

It looks like you are trying to introduce vTPM stubdomains. The QEMU
changes have been posted against upstream QEMU, that is good, however as
far as I know upstream QEMU doesn't build or work as a stubdomain yet.
Where are the changes to make upstream QEMU based stubdoms work?
I don't see them neither here nor in the QEMU series.

How are you testing this work?


>  Config.mk                             |  4 ++++
>  extras/mini-os/include/tpmback.h      |  3 +++
>  extras/mini-os/tpmback.c              | 20 +++++++++++++++++---
>  tools/Makefile                        |  7 +++++++
>  tools/firmware/hvmloader/acpi/build.c |  5 +++--
>  tools/libxl/libxl.c                   | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_create.c            | 16 +++++++++++++---
>  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
>  tools/libxl/libxl_dom.c               |  2 ++
>  tools/libxl/libxl_internal.h          |  3 +++
>  tools/libxl/libxl_types.idl           |  1 +
>  tools/libxl/xl_cmdimpl.c              |  2 ++
>  xen/arch/x86/hvm/hvm.c                |  3 +++
>  xen/include/public/hvm/params.h       |  1 +
> 
> I've tried to break it down to smaller patches:
> 
>  *(Patch 1/6)*  event channel bind interdomain with para/hvm virtual machine
> 
>  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> 
>  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual machine
> 
>  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine when vTPM is added
> 
>  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> 
>  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:30:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFq6-0005i9-Hl; Mon, 03 Nov 2014 11:30:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlFq5-0005i4-5Z
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:30:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	42/D9-09936-05767545; Mon, 03 Nov 2014 11:30:24 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415014222!12330402!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29656 invoked from network); 3 Nov 2014 11:30:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:30:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188850172"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 06:30:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlFq1-0007ty-Hk;
	Mon, 03 Nov 2014 11:30:21 +0000
Date: Mon, 3 Nov 2014 11:30:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Quan Xu <quan.xu@intel.com>
In-Reply-To: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
Message-ID: <alpine.DEB.2.02.1411031126170.22875@kaball.uk.xensource.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
 machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 30 Oct 2014, Quan Xu wrote:
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> 
> This patch series are only the Xen part to enable stubdom vTPM for HVM virtual machine.
> it will work w/ Qemu patch series and seaBios patch series. Change QEMU_STUBDOM_VTPM 
> compile option from 'n' to 'y', when the Qemu/SeaBios patch series are merged.

Please, could you add more detailed commit messages in your patches?
Also spending a few more words here to explain why are you doing this
and how would help.

It looks like you are trying to introduce vTPM stubdomains. The QEMU
changes have been posted against upstream QEMU, that is good, however as
far as I know upstream QEMU doesn't build or work as a stubdomain yet.
Where are the changes to make upstream QEMU based stubdoms work?
I don't see them neither here nor in the QEMU series.

How are you testing this work?


>  Config.mk                             |  4 ++++
>  extras/mini-os/include/tpmback.h      |  3 +++
>  extras/mini-os/tpmback.c              | 20 +++++++++++++++++---
>  tools/Makefile                        |  7 +++++++
>  tools/firmware/hvmloader/acpi/build.c |  5 +++--
>  tools/libxl/libxl.c                   | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_create.c            | 16 +++++++++++++---
>  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
>  tools/libxl/libxl_dom.c               |  2 ++
>  tools/libxl/libxl_internal.h          |  3 +++
>  tools/libxl/libxl_types.idl           |  1 +
>  tools/libxl/xl_cmdimpl.c              |  2 ++
>  xen/arch/x86/hvm/hvm.c                |  3 +++
>  xen/include/public/hvm/params.h       |  1 +
> 
> I've tried to break it down to smaller patches:
> 
>  *(Patch 1/6)*  event channel bind interdomain with para/hvm virtual machine
> 
>  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> 
>  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual machine
> 
>  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine when vTPM is added
> 
>  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> 
>  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:32:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:32:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFs7-0005uK-80; Mon, 03 Nov 2014 11:32:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlFs6-0005uE-EL
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:32:30 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	40/FB-09284-DC767545; Mon, 03 Nov 2014 11:32:29 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415014347!11290841!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10564 invoked from network); 3 Nov 2014 11:32:28 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 11:32:28 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 03 Nov 2014 03:32:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="410320471"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by FMSMGA003.fm.intel.com with ESMTP; 03 Nov 2014 03:23:57 -0800
Message-ID: <545767C4.7070806@intel.com>
Date: Mon, 03 Nov 2014 19:32:20 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
In-Reply-To: <54575E2D0200007800044443@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 17:51, Jan Beulich wrote:
>>>> On 03.11.14 at 10:40, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 16:56, Jan Beulich wrote:
>>>>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>>>>     From: Chen, Tiejun
>>>>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>>>>> Thinking about this some more, this odd universal hole punching in
>>>>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>>>>> this really should be optional behavior, with pass through of devices
>>>>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>>>>> punching holes for _just_ the devices passed through to a guest
>>>>>>>> upon creation when the option is not enabled.)
>>>>>>>
>>>>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>>>>> conflict with anything. So what about this idea?
>>>>>>>
>>>>>>
>>>>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>>>>> approach. When the parameter is on, RMRR check/hole punch is
>>>>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>>>>
>>>>>> If user configures device pass-through at creation time, this parameter
>>>>>> will be set by default. If user wants the VM capable of device hot-plug,
>>>>>> an explicit parameter can be added in the config file to enforce RMRR
>>>>>> check at creation time.
>>>>>
>>>>> Not exactly, I specifically described it slightly differently above. When
>>>>> devices get passed through and the option is absent, holes should be
>>>>> punched only for the RMRRs associated with those devices (i.e.
>>>>> ideally none). Of course this means we'll need a way to associate
>>>>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>>>>> XENMEM_reserved_device_memory_map alone won't suffice.
>>>>
>>>> Yeah, current hypercall just provide RMRR entries without that
>>>> associated BDF. And especially, in some cases one range may be shared by
>>>> multiple devices...
>>>
>>> Before we decide who's going to do an eventual change we need to
>>> determine what behavior we want, and whether this hypercall is
>>> really the right one. Quite possibly we'd need a per-domain view
>>> along with the global view, and hence rather than modifying this one
>>> we may need to introduce e.g. a new domctl.
>>>
>>
>> If we really need to work with a hypercall, maybe we can introduce a
>> little bit to construct that to callback with multiple entries like
>> this, for instance,
>>
>> RMRR entry0 have three devices, and entry1 have two devices,
>>
>> [start0, nr_pages0, bdf0],
>> [start0, nr_pages0, bdf1],
>> [start0, nr_pages0, bdf2],
>> [start1, nr_pages1, bdf3],
>> [start1, nr_pages1, bdf4],
>>
>> Although its cost more buffers, actually as you know this actual case is
>> really rare. So maybe this way can be feasible. Then we don't need
>> additional hypercall or xenstore.
>
> Conceptually, as a MEMOP, it has no business reporting BDFs. And
> then rather than returning the same address range more than once,
> having the caller supply a handle to an array and storing all of the
> SBDFs (or perhaps a single segment would suffice along with all the
> BDFs) there would seem to be an approach more consistent with
> what we do elsewhere.

Here I'm wondering if we really need to expose BDFs to tools. Actually 
tools just want to know those range no matter who owns these entries. I 
mean we can do this in Xen.

When we try to assign device as passthrough, Xen can get that bdf so Xen 
can pre-check everything inside that hypercall, and Xen can return 
something like this,

#1 If this device has RMRR, we return that rmrr buffer. This is similar 
with our current implementation.
#2 If not, we return 'nr_entries' as '0' to notify hvmloader it has 
nothing to do.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:32:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:32:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFs7-0005uK-80; Mon, 03 Nov 2014 11:32:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlFs6-0005uE-EL
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:32:30 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	40/FB-09284-DC767545; Mon, 03 Nov 2014 11:32:29 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415014347!11290841!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10564 invoked from network); 3 Nov 2014 11:32:28 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 11:32:28 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 03 Nov 2014 03:32:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="410320471"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by FMSMGA003.fm.intel.com with ESMTP; 03 Nov 2014 03:23:57 -0800
Message-ID: <545767C4.7070806@intel.com>
Date: Mon, 03 Nov 2014 19:32:20 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
In-Reply-To: <54575E2D0200007800044443@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 17:51, Jan Beulich wrote:
>>>> On 03.11.14 at 10:40, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 16:56, Jan Beulich wrote:
>>>>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>>>>     From: Chen, Tiejun
>>>>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>>>>> Thinking about this some more, this odd universal hole punching in
>>>>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>>>>> this really should be optional behavior, with pass through of devices
>>>>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>>>>> punching holes for _just_ the devices passed through to a guest
>>>>>>>> upon creation when the option is not enabled.)
>>>>>>>
>>>>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>>>>> conflict with anything. So what about this idea?
>>>>>>>
>>>>>>
>>>>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>>>>> approach. When the parameter is on, RMRR check/hole punch is
>>>>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>>>>
>>>>>> If user configures device pass-through at creation time, this parameter
>>>>>> will be set by default. If user wants the VM capable of device hot-plug,
>>>>>> an explicit parameter can be added in the config file to enforce RMRR
>>>>>> check at creation time.
>>>>>
>>>>> Not exactly, I specifically described it slightly differently above. When
>>>>> devices get passed through and the option is absent, holes should be
>>>>> punched only for the RMRRs associated with those devices (i.e.
>>>>> ideally none). Of course this means we'll need a way to associate
>>>>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>>>>> XENMEM_reserved_device_memory_map alone won't suffice.
>>>>
>>>> Yeah, current hypercall just provide RMRR entries without that
>>>> associated BDF. And especially, in some cases one range may be shared by
>>>> multiple devices...
>>>
>>> Before we decide who's going to do an eventual change we need to
>>> determine what behavior we want, and whether this hypercall is
>>> really the right one. Quite possibly we'd need a per-domain view
>>> along with the global view, and hence rather than modifying this one
>>> we may need to introduce e.g. a new domctl.
>>>
>>
>> If we really need to work with a hypercall, maybe we can introduce a
>> little bit to construct that to callback with multiple entries like
>> this, for instance,
>>
>> RMRR entry0 have three devices, and entry1 have two devices,
>>
>> [start0, nr_pages0, bdf0],
>> [start0, nr_pages0, bdf1],
>> [start0, nr_pages0, bdf2],
>> [start1, nr_pages1, bdf3],
>> [start1, nr_pages1, bdf4],
>>
>> Although its cost more buffers, actually as you know this actual case is
>> really rare. So maybe this way can be feasible. Then we don't need
>> additional hypercall or xenstore.
>
> Conceptually, as a MEMOP, it has no business reporting BDFs. And
> then rather than returning the same address range more than once,
> having the caller supply a handle to an array and storing all of the
> SBDFs (or perhaps a single segment would suffice along with all the
> BDFs) there would seem to be an approach more consistent with
> what we do elsewhere.

Here I'm wondering if we really need to expose BDFs to tools. Actually 
tools just want to know those range no matter who owns these entries. I 
mean we can do this in Xen.

When we try to assign device as passthrough, Xen can get that bdf so Xen 
can pre-check everything inside that hypercall, and Xen can return 
something like this,

#1 If this device has RMRR, we return that rmrr buffer. This is similar 
with our current implementation.
#2 If not, we return 'nr_entries' as '0' to notify hvmloader it has 
nothing to do.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:35:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11: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 1XlFuq-0006Au-U8; Mon, 03 Nov 2014 11:35:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1XlFup-0006Am-2n
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 11:35:19 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A2/FB-24532-67867545; Mon, 03 Nov 2014 11:35:18 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415014516!5069750!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21728 invoked from network); 3 Nov 2014 11:35:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 11:35:17 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA3BZE06025455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 3 Nov 2014 06:35:14 -0500
Received: from [10.36.112.55] (ovpn-112-55.ams2.redhat.com [10.36.112.55])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sA3BZBQA022861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 3 Nov 2014 06:35:13 -0500
Message-ID: <5457686E.7020601@redhat.com>
Date: Mon, 03 Nov 2014 12:35:10 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Chen, Tiejun" <tiejun.chen@intel.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
References: <20140901060506.GA20186@redhat.com>	<54042514.6090206@intel.com>	<003AAFE53969E14CB1F09B6FD68C3CD478F16D2A@ORSMSX101.amr.corp.intel.com>	<54277979.7070408@intel.com>	<20140929100111.GA32459@redhat.com>	<542A18BD.2060008@intel.com>	<20141007072653.GB2424@redhat.com>	<543622CC.6050807@intel.com>	<20141012095021.GC9567@redhat.com>	<544A0174.7000003@intel.com>	<20141024134747.GA6024@redhat.com>
	<5451ED1E.1000300@intel.com> <5457335B.1000308@intel.com>
In-Reply-To: <5457335B.1000308@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xen:i386:pc_piix: create
 isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/11/2014 08:48, Chen, Tiejun wrote:
>>>>> I think the point was mostly to reserve 1f to prevent
>>>>> devices from using it.
>>>>> As we populate slots in order it doesn't seem to important ...
>>>>
>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>>
>>> Right, but I mean if no special options are used, 1f will typically
>>> stay free without any effort on our side.
>>
>> Yeah.
>>
>> Actually based on current info we know, seems 1f is just specific to our
>> scenario :) So I always think we can occupy that. But Paolo and you can
>> really determine this point.
> 
> What's your idea?

I do not have any objection to always occupying 1f for Xen IGD passthrough.

Paolo

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:35:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11: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 1XlFuq-0006Au-U8; Mon, 03 Nov 2014 11:35:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1XlFup-0006Am-2n
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 11:35:19 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A2/FB-24532-67867545; Mon, 03 Nov 2014 11:35:18 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415014516!5069750!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21728 invoked from network); 3 Nov 2014 11:35:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 11:35:17 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA3BZE06025455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 3 Nov 2014 06:35:14 -0500
Received: from [10.36.112.55] (ovpn-112-55.ams2.redhat.com [10.36.112.55])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sA3BZBQA022861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 3 Nov 2014 06:35:13 -0500
Message-ID: <5457686E.7020601@redhat.com>
Date: Mon, 03 Nov 2014 12:35:10 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Chen, Tiejun" <tiejun.chen@intel.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
References: <20140901060506.GA20186@redhat.com>	<54042514.6090206@intel.com>	<003AAFE53969E14CB1F09B6FD68C3CD478F16D2A@ORSMSX101.amr.corp.intel.com>	<54277979.7070408@intel.com>	<20140929100111.GA32459@redhat.com>	<542A18BD.2060008@intel.com>	<20141007072653.GB2424@redhat.com>	<543622CC.6050807@intel.com>	<20141012095021.GC9567@redhat.com>	<544A0174.7000003@intel.com>	<20141024134747.GA6024@redhat.com>
	<5451ED1E.1000300@intel.com> <5457335B.1000308@intel.com>
In-Reply-To: <5457335B.1000308@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xen:i386:pc_piix: create
 isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/11/2014 08:48, Chen, Tiejun wrote:
>>>>> I think the point was mostly to reserve 1f to prevent
>>>>> devices from using it.
>>>>> As we populate slots in order it doesn't seem to important ...
>>>>
>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>>
>>> Right, but I mean if no special options are used, 1f will typically
>>> stay free without any effort on our side.
>>
>> Yeah.
>>
>> Actually based on current info we know, seems 1f is just specific to our
>> scenario :) So I always think we can occupy that. But Paolo and you can
>> really determine this point.
> 
> What's your idea?

I do not have any objection to always occupying 1f for Xen IGD passthrough.

Paolo

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:36:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:36:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFwI-0006I2-EH; Mon, 03 Nov 2014 11:36:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlFwG-0006Hs-AB
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 11:36:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	63/9F-24532-FC867545; Mon, 03 Nov 2014 11:36:47 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415014606!8927503!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24161 invoked from network); 3 Nov 2014 11:36:46 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-21.messagelabs.com with SMTP;
	3 Nov 2014 11:36:46 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 03 Nov 2014 03:36:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="410321991"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by FMSMGA003.fm.intel.com with ESMTP; 03 Nov 2014 03:28:21 -0800
Message-ID: <545768CC.3000903@intel.com>
Date: Mon, 03 Nov 2014 19:36:44 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Paolo Bonzini <pbonzini@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>
References: <20140901060506.GA20186@redhat.com>	<54042514.6090206@intel.com>	<003AAFE53969E14CB1F09B6FD68C3CD478F16D2A@ORSMSX101.amr.corp.intel.com>	<54277979.7070408@intel.com>	<20140929100111.GA32459@redhat.com>	<542A18BD.2060008@intel.com>	<20141007072653.GB2424@redhat.com>	<543622CC.6050807@intel.com>	<20141012095021.GC9567@redhat.com>	<544A0174.7000003@intel.com>	<20141024134747.GA6024@redhat.com>
	<5451ED1E.1000300@intel.com> <5457335B.1000308@intel.com>
	<5457686E.7020601@redhat.com>
In-Reply-To: <5457686E.7020601@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xen:i386:pc_piix: create
 isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 19:35, Paolo Bonzini wrote:
> On 03/11/2014 08:48, Chen, Tiejun wrote:
>>>>>> I think the point was mostly to reserve 1f to prevent
>>>>>> devices from using it.
>>>>>> As we populate slots in order it doesn't seem to important ...
>>>>>
>>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>>>
>>>> Right, but I mean if no special options are used, 1f will typically
>>>> stay free without any effort on our side.
>>>
>>> Yeah.
>>>
>>> Actually based on current info we know, seems 1f is just specific to our
>>> scenario :) So I always think we can occupy that. But Paolo and you can
>>> really determine this point.
>>
>> What's your idea?
>
> I do not have any objection to always occupying 1f for Xen IGD passthrough.
>

Cool ;-)

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:36:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:36:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFwI-0006I2-EH; Mon, 03 Nov 2014 11:36:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlFwG-0006Hs-AB
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 11:36:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	63/9F-24532-FC867545; Mon, 03 Nov 2014 11:36:47 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415014606!8927503!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24161 invoked from network); 3 Nov 2014 11:36:46 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-21.messagelabs.com with SMTP;
	3 Nov 2014 11:36:46 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 03 Nov 2014 03:36:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="410321991"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by FMSMGA003.fm.intel.com with ESMTP; 03 Nov 2014 03:28:21 -0800
Message-ID: <545768CC.3000903@intel.com>
Date: Mon, 03 Nov 2014 19:36:44 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Paolo Bonzini <pbonzini@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>
References: <20140901060506.GA20186@redhat.com>	<54042514.6090206@intel.com>	<003AAFE53969E14CB1F09B6FD68C3CD478F16D2A@ORSMSX101.amr.corp.intel.com>	<54277979.7070408@intel.com>	<20140929100111.GA32459@redhat.com>	<542A18BD.2060008@intel.com>	<20141007072653.GB2424@redhat.com>	<543622CC.6050807@intel.com>	<20141012095021.GC9567@redhat.com>	<544A0174.7000003@intel.com>	<20141024134747.GA6024@redhat.com>
	<5451ED1E.1000300@intel.com> <5457335B.1000308@intel.com>
	<5457686E.7020601@redhat.com>
In-Reply-To: <5457686E.7020601@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xen:i386:pc_piix: create
 isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 19:35, Paolo Bonzini wrote:
> On 03/11/2014 08:48, Chen, Tiejun wrote:
>>>>>> I think the point was mostly to reserve 1f to prevent
>>>>>> devices from using it.
>>>>>> As we populate slots in order it doesn't seem to important ...
>>>>>
>>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>>>
>>>> Right, but I mean if no special options are used, 1f will typically
>>>> stay free without any effort on our side.
>>>
>>> Yeah.
>>>
>>> Actually based on current info we know, seems 1f is just specific to our
>>> scenario :) So I always think we can occupy that. But Paolo and you can
>>> really determine this point.
>>
>> What's your idea?
>
> I do not have any objection to always occupying 1f for Xen IGD passthrough.
>

Cool ;-)

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:37:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:37:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFwo-0006MF-Si; Mon, 03 Nov 2014 11:37:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XlFwn-0006Ly-Gt
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:37:21 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C3/13-02696-0F867545; Mon, 03 Nov 2014 11:37:20 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415014639!12190919!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26734 invoked from network); 3 Nov 2014 11:37:19 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 11:37:19 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XlFwl-0004Is-A2; Mon, 03 Nov 2014 11:37:19 +0000
Message-ID: <545768EE.7040903@canonical.com>
Date: Mon, 03 Nov 2014 12:37:18 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel@lists.xen.org
References: <54574EA0.5070101@canonical.com> <54575E32.6040603@citrix.com>
	<545764BB.7080005@canonical.com>
In-Reply-To: <545764BB.7080005@canonical.com>
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3310601849231891591=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

On 03.11.2014 12:19, Stefan Bader wrote:
> On 03.11.2014 11:51, Andrew Cooper wrote:
>> On 03/11/14 09:45, Stefan Bader wrote:
>>> I see the message from the subject on my Intel box whenever a guest (=
iirc even
>>> dom0) starts up. It is not fatal and everything seems ok. I am just c=
urious
>>> about what might trigger this. The addresses look to be inside the hy=
pervisor
>>> code. I was wondering whether there is a simple way to figure out wha=
t this
>>> relates to (likely need to look at the objdump of the unstripped hv m=
odule).
>>>
>>> Or has someone already looked into this and knows what likely is the =
cause?
>>>
>>> -Stefan
>>
>> Specifically, the message indicates <type of fault>: faulting address =
->
>> fixup address
>>
>> It is probably a wrmsr, and a higher logging level will indicate this.=
=20
>> My gut feeling is that it is dom0 attempting to load microcode using t=
he
>> native method.
>>
>> ~Andrew
>>
>=20
> The faulting address in my case seems to be rdmsr_save (xen-4.4.1 base)=
, the
> fixup address somewhere unspecific in hvm.c (not sure whether that make=
s sense
> coming from a dom0 startup). I will have to re-compile this with the gd=
printk
> enabled to see which MSR that was.
>=20
> rdmsr_normal:
>             /* Everyone can read the MSR space. */
>             /* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR %p.\n",
>                         _p(regs->ecx));*/
>             if ( rdmsr_safe(regs->ecx, msr_content) )
>                 goto fail;
>=20
> Though likely related to the following WRMSRs following (the addresses =
differ
> from the subject I wasn't sure from where exactly I took the others and=
 these
> are with 4.4.1 and directly after boot):
>=20
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x00=
4281c2001
> a8168 to 0x004281c200148168.
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x00=
4281c2001
> a8168 to 0x004281c2001a0168.
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x00=
4281c2001
> a8168 to 0x004201c2001a8168.

Ok, 0x610 -> Running Average Power Limit (RAPL) control (MSR_PKG_POWER_LI=
MIT)
vol3 35.8

> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 00000000000001b2 from 0x00=
000000000
> 00000 to 0x0000000000009600.
>=20
> The 0x1b2 seems to be thermal interrupt control. Cannot find the 0x610 =
right now
> (need to refresh my docs)...
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--npH1It52Itj6LDrfQgG02R1GuVgQgt73w
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

iQIcBAEBCgAGBQJUV2juAAoJEOhnXe7L7s6jSo8QAMCEELGf0AT7znGYikpZvwQ6
6Mp8OJhgXa9ZqjmVJPzVmtUfMTyhkY/BBJJs3EXYs08mMLRaEJA6ChAKiZ6E/7ng
oN4xYGxh4NkmbYpUx15K2ySOjAW2aGrvmQbHJb7KtbKzdTS9Ps6ni7k1mvGWshl/
N4O3Q/WG5qqjYkOt6o4ZaUzVNyQ6S2ds4X340c69yX2f3www31K56gKrN7KM3vuf
XLd8N+Fd1NBuysRsNhLUlQPSAdSCl/39phvcnculwPUNDlsvcHg2e+5xFrkgZuFS
3MFrieT9socNUoohOJEb0gFY+SVUntn96TRmJhJwy7jif0xVhEvexy4FfGPrMCW9
0Ye++X1gYxsh0OTd0JQFOFARkTssugwIKr+QhpUV0SgjgYmKMCvF+fKefni3nYt3
EYPu7tTRuyfgxGpvYU5sBKU5jYakfc8jmnmL+qGOgOhgVq0otJ5ujD06082bTgNm
eOx2J7ufI6Nt4WbZW0V9ZWvBLDhnCH6i6RdcRrfNEGnox0eIbFzIMdy8nxAvoIxa
Fxek+jfCmJEClo3IyHS6jq++jgnSTBBBvhsuZO4uWul7diKTezHNovljjAsPBXWD
sKhjueoXKEl8EpvpB8bHESTP1OolD0j20gNJJW7FDdx6R86BSTigiA4IrFjX+asq
AP1gMzu6YgiHX4gFh3OG
=X7zx
-----END PGP SIGNATURE-----

--npH1It52Itj6LDrfQgG02R1GuVgQgt73w--


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

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

--===============3310601849231891591==--


From xen-devel-bounces@lists.xen.org Mon Nov 03 11:37:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:37:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFwo-0006MF-Si; Mon, 03 Nov 2014 11:37:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XlFwn-0006Ly-Gt
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:37:21 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C3/13-02696-0F867545; Mon, 03 Nov 2014 11:37:20 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415014639!12190919!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26734 invoked from network); 3 Nov 2014 11:37:19 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 11:37:19 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XlFwl-0004Is-A2; Mon, 03 Nov 2014 11:37:19 +0000
Message-ID: <545768EE.7040903@canonical.com>
Date: Mon, 03 Nov 2014 12:37:18 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel@lists.xen.org
References: <54574EA0.5070101@canonical.com> <54575E32.6040603@citrix.com>
	<545764BB.7080005@canonical.com>
In-Reply-To: <545764BB.7080005@canonical.com>
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3310601849231891591=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

On 03.11.2014 12:19, Stefan Bader wrote:
> On 03.11.2014 11:51, Andrew Cooper wrote:
>> On 03/11/14 09:45, Stefan Bader wrote:
>>> I see the message from the subject on my Intel box whenever a guest (=
iirc even
>>> dom0) starts up. It is not fatal and everything seems ok. I am just c=
urious
>>> about what might trigger this. The addresses look to be inside the hy=
pervisor
>>> code. I was wondering whether there is a simple way to figure out wha=
t this
>>> relates to (likely need to look at the objdump of the unstripped hv m=
odule).
>>>
>>> Or has someone already looked into this and knows what likely is the =
cause?
>>>
>>> -Stefan
>>
>> Specifically, the message indicates <type of fault>: faulting address =
->
>> fixup address
>>
>> It is probably a wrmsr, and a higher logging level will indicate this.=
=20
>> My gut feeling is that it is dom0 attempting to load microcode using t=
he
>> native method.
>>
>> ~Andrew
>>
>=20
> The faulting address in my case seems to be rdmsr_save (xen-4.4.1 base)=
, the
> fixup address somewhere unspecific in hvm.c (not sure whether that make=
s sense
> coming from a dom0 startup). I will have to re-compile this with the gd=
printk
> enabled to see which MSR that was.
>=20
> rdmsr_normal:
>             /* Everyone can read the MSR space. */
>             /* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR %p.\n",
>                         _p(regs->ecx));*/
>             if ( rdmsr_safe(regs->ecx, msr_content) )
>                 goto fail;
>=20
> Though likely related to the following WRMSRs following (the addresses =
differ
> from the subject I wasn't sure from where exactly I took the others and=
 these
> are with 4.4.1 and directly after boot):
>=20
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x00=
4281c2001
> a8168 to 0x004281c200148168.
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x00=
4281c2001
> a8168 to 0x004281c2001a0168.
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x00=
4281c2001
> a8168 to 0x004201c2001a8168.

Ok, 0x610 -> Running Average Power Limit (RAPL) control (MSR_PKG_POWER_LI=
MIT)
vol3 35.8

> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 00000000000001b2 from 0x00=
000000000
> 00000 to 0x0000000000009600.
>=20
> The 0x1b2 seems to be thermal interrupt control. Cannot find the 0x610 =
right now
> (need to refresh my docs)...
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--npH1It52Itj6LDrfQgG02R1GuVgQgt73w
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

iQIcBAEBCgAGBQJUV2juAAoJEOhnXe7L7s6jSo8QAMCEELGf0AT7znGYikpZvwQ6
6Mp8OJhgXa9ZqjmVJPzVmtUfMTyhkY/BBJJs3EXYs08mMLRaEJA6ChAKiZ6E/7ng
oN4xYGxh4NkmbYpUx15K2ySOjAW2aGrvmQbHJb7KtbKzdTS9Ps6ni7k1mvGWshl/
N4O3Q/WG5qqjYkOt6o4ZaUzVNyQ6S2ds4X340c69yX2f3www31K56gKrN7KM3vuf
XLd8N+Fd1NBuysRsNhLUlQPSAdSCl/39phvcnculwPUNDlsvcHg2e+5xFrkgZuFS
3MFrieT9socNUoohOJEb0gFY+SVUntn96TRmJhJwy7jif0xVhEvexy4FfGPrMCW9
0Ye++X1gYxsh0OTd0JQFOFARkTssugwIKr+QhpUV0SgjgYmKMCvF+fKefni3nYt3
EYPu7tTRuyfgxGpvYU5sBKU5jYakfc8jmnmL+qGOgOhgVq0otJ5ujD06082bTgNm
eOx2J7ufI6Nt4WbZW0V9ZWvBLDhnCH6i6RdcRrfNEGnox0eIbFzIMdy8nxAvoIxa
Fxek+jfCmJEClo3IyHS6jq++jgnSTBBBvhsuZO4uWul7diKTezHNovljjAsPBXWD
sKhjueoXKEl8EpvpB8bHESTP1OolD0j20gNJJW7FDdx6R86BSTigiA4IrFjX+asq
AP1gMzu6YgiHX4gFh3OG
=X7zx
-----END PGP SIGNATURE-----

--npH1It52Itj6LDrfQgG02R1GuVgQgt73w--


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

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

--===============3310601849231891591==--


From xen-devel-bounces@lists.xen.org Mon Nov 03 11:37:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:37:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFwt-0006Nb-A1; Mon, 03 Nov 2014 11:37:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlFwr-0006N5-S7
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 11:37:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/21-24532-5F867545; Mon, 03 Nov 2014 11:37:25 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415014644!12306758!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8818 invoked from network); 3 Nov 2014 11:37:24 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:37:24 -0000
Received: by mail-wi0-f181.google.com with SMTP id n3so6106970wiv.8
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 03:37:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=Qd2qX8yO2inEWFvRJMQLkOgRZcKZ6L9fcPmlnR0fflk=;
	b=RI78qzzjhFPMh+M5YXZOMLmkZ201yIXTwaueseIKHCluHEEibY9TqKgK64Ez5+Uo1P
	hbT/JtYXR8fJFvNPXuWpdn2tLiibC9vtQCTeuzwfaTCaLcXnSV0BQcGJk0kncOWwvbJX
	xw2wJcX+4n/x/YlcA0UhhVKjIp7aK7HiOnvkDTglrSYIMQz56B6X9JmUzjfbZjzcXbky
	PUyQDIVZjObwyn9CiH3IJtR3R3EouCTzxoBXZQwaqmpDw9s4L3B53TMCxafARURqjouf
	8CEsbV9M+GjyO7dXAv9wBjUkE1M0SA03L3sQJ/AZ9OvuM08uOivIWETtGkhMJ2KEVJdq
	PeiQ==
MIME-Version: 1.0
X-Received: by 10.180.82.4 with SMTP id e4mr15312158wiy.42.1415014644020; Mon,
	03 Nov 2014 03:37:24 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 3 Nov 2014 03:37:23 -0800 (PST)
In-Reply-To: <20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<21586.10214.683512.296628@chiark.greenend.org.uk>
	<20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
Date: Mon, 3 Nov 2014 11:37:23 +0000
X-Google-Sender-Auth: HJ9qlEVKKpZ6fulBwmZfnUuF820
Message-ID: <CAFLBxZYOaMTDGg38x-TB+OgjH+-hXNTq0c+kHJ7Mu9sEXAcseA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matt Wilson <msw@linux.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <ijackson@chiark.greenend.org.uk>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 31, 2014 at 10:40 PM, Matt Wilson <msw@linux.com> wrote:
> On Thu, Oct 30, 2014 at 11:58:30AM +0000, Ian Jackson wrote:
>
> [...]
>
>> I think that people who want to be on the predisclosure list should
>> make matters easy for the security team.  I think it therefore is only
>> fair to say that an application might be delayed if the team member
>> who happens to deal with the application can't conveniently access the
>> evidence that the applicant is supposed to provide.
>
> I think that we should reduce any burden on the security team by
> making this a community decision that is discussed in public, rather
> than something that is handled exclusively in a closed manner as it is
> today. This way others who are active community participants can help
> with the decision making process can do the investigation and weigh in
> on the risk/benefit tradeoff to the security process and the
> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> or [1] if you are willing to visit a URL. ;-)
>
> There's been a bit of talk about "delay" and so on. I'd rather not set
> expectations on how long the processing a petition to be added to the
> predisclosure list should take. Building community consensus takes
> time, just as it does for other activities like getting a patch
> applied. I don't think that this process needs to be different.

We might remove some of the (potential) pressure to rush things by
saying that once approved, new members will not receive information
about *currently embargoed* disclosures, but only about *future*
disclosures.

I.e., the rush of people for XSA-108 wouldn't be in a rush because (by
policy) they wouldn't have been eligible to receive XSA-108 anyway.

But perhaps that would be too unpopular to actually implement...

 -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:37:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:37:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFwt-0006Nb-A1; Mon, 03 Nov 2014 11:37:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlFwr-0006N5-S7
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 11:37:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/21-24532-5F867545; Mon, 03 Nov 2014 11:37:25 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415014644!12306758!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8818 invoked from network); 3 Nov 2014 11:37:24 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:37:24 -0000
Received: by mail-wi0-f181.google.com with SMTP id n3so6106970wiv.8
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 03:37:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=Qd2qX8yO2inEWFvRJMQLkOgRZcKZ6L9fcPmlnR0fflk=;
	b=RI78qzzjhFPMh+M5YXZOMLmkZ201yIXTwaueseIKHCluHEEibY9TqKgK64Ez5+Uo1P
	hbT/JtYXR8fJFvNPXuWpdn2tLiibC9vtQCTeuzwfaTCaLcXnSV0BQcGJk0kncOWwvbJX
	xw2wJcX+4n/x/YlcA0UhhVKjIp7aK7HiOnvkDTglrSYIMQz56B6X9JmUzjfbZjzcXbky
	PUyQDIVZjObwyn9CiH3IJtR3R3EouCTzxoBXZQwaqmpDw9s4L3B53TMCxafARURqjouf
	8CEsbV9M+GjyO7dXAv9wBjUkE1M0SA03L3sQJ/AZ9OvuM08uOivIWETtGkhMJ2KEVJdq
	PeiQ==
MIME-Version: 1.0
X-Received: by 10.180.82.4 with SMTP id e4mr15312158wiy.42.1415014644020; Mon,
	03 Nov 2014 03:37:24 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 3 Nov 2014 03:37:23 -0800 (PST)
In-Reply-To: <20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<21586.10214.683512.296628@chiark.greenend.org.uk>
	<20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
Date: Mon, 3 Nov 2014 11:37:23 +0000
X-Google-Sender-Auth: HJ9qlEVKKpZ6fulBwmZfnUuF820
Message-ID: <CAFLBxZYOaMTDGg38x-TB+OgjH+-hXNTq0c+kHJ7Mu9sEXAcseA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matt Wilson <msw@linux.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <ijackson@chiark.greenend.org.uk>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 31, 2014 at 10:40 PM, Matt Wilson <msw@linux.com> wrote:
> On Thu, Oct 30, 2014 at 11:58:30AM +0000, Ian Jackson wrote:
>
> [...]
>
>> I think that people who want to be on the predisclosure list should
>> make matters easy for the security team.  I think it therefore is only
>> fair to say that an application might be delayed if the team member
>> who happens to deal with the application can't conveniently access the
>> evidence that the applicant is supposed to provide.
>
> I think that we should reduce any burden on the security team by
> making this a community decision that is discussed in public, rather
> than something that is handled exclusively in a closed manner as it is
> today. This way others who are active community participants can help
> with the decision making process can do the investigation and weigh in
> on the risk/benefit tradeoff to the security process and the
> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> or [1] if you are willing to visit a URL. ;-)
>
> There's been a bit of talk about "delay" and so on. I'd rather not set
> expectations on how long the processing a petition to be added to the
> predisclosure list should take. Building community consensus takes
> time, just as it does for other activities like getting a patch
> applied. I don't think that this process needs to be different.

We might remove some of the (potential) pressure to rush things by
saying that once approved, new members will not receive information
about *currently embargoed* disclosures, but only about *future*
disclosures.

I.e., the rush of people for XSA-108 wouldn't be in a rush because (by
policy) they wouldn't have been eligible to receive XSA-108 anyway.

But perhaps that would be too unpopular to actually implement...

 -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:37:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11: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 1XlFwu-0006OS-MK; Mon, 03 Nov 2014 11:37:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlFws-0006ND-It
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:37:26 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	29/08-03145-5F867545; Mon, 03 Nov 2014 11:37:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415014645!8857885!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22594 invoked from network); 3 Nov 2014 11:37:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 11:37:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 11:37:24 +0000
Message-Id: <5457770102000078000445A5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 11:37:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
	<54575C3E020000780004440F@mail.emea.novell.com>
	<54575372.7020406@intel.com>
	<545764D102000078000444F0@mail.emea.novell.com>
	<5457656E.9040604@intel.com>
In-Reply-To: <5457656E.9040604@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
 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 03.11.14 at 12:22, <tiejun.chen@intel.com> wrote:
> Are you saying that dependency?
> 
> @@ -87,6 +87,11 @@ endif
>   all: subdirs-all
>          $(MAKE) hvmloader
> 
> +subdirs-all: errno
> +
> +errno:
> +       ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
> +
>   ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
>   smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""

Another step in the right direction. If now you also change the target
to be "errno.h" instead of "errno", we'll have what we want.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:37:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11: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 1XlFwu-0006OS-MK; Mon, 03 Nov 2014 11:37:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlFws-0006ND-It
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:37:26 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	29/08-03145-5F867545; Mon, 03 Nov 2014 11:37:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415014645!8857885!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22594 invoked from network); 3 Nov 2014 11:37:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 11:37:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 11:37:24 +0000
Message-Id: <5457770102000078000445A5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 11:37:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
	<54575C3E020000780004440F@mail.emea.novell.com>
	<54575372.7020406@intel.com>
	<545764D102000078000444F0@mail.emea.novell.com>
	<5457656E.9040604@intel.com>
In-Reply-To: <5457656E.9040604@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
 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 03.11.14 at 12:22, <tiejun.chen@intel.com> wrote:
> Are you saying that dependency?
> 
> @@ -87,6 +87,11 @@ endif
>   all: subdirs-all
>          $(MAKE) hvmloader
> 
> +subdirs-all: errno
> +
> +errno:
> +       ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
> +
>   ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
>   smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""

Another step in the right direction. If now you also change the target
to be "errno.h" instead of "errno", we'll have what we want.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:38:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFxx-0006fB-6v; Mon, 03 Nov 2014 11:38:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XlFxw-0006eu-Ak
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:38:32 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	72/C2-02702-73967545; Mon, 03 Nov 2014 11:38:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415014709!8858188!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18416 invoked from network); 3 Nov 2014 11:38:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:38:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188852084"
Message-ID: <54576932.9030803@citrix.com>
Date: Mon, 3 Nov 2014 11:38:26 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>, <Xen-devel@lists.xen.org>
References: <54574EA0.5070101@canonical.com> <54575E32.6040603@citrix.com>
	<545764BB.7080005@canonical.com>
In-Reply-To: <545764BB.7080005@canonical.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/11/14 11:19, Stefan Bader wrote:
> On 03.11.2014 11:51, Andrew Cooper wrote:
>> On 03/11/14 09:45, Stefan Bader wrote:
>>> I see the message from the subject on my Intel box whenever a guest (iirc even
>>> dom0) starts up. It is not fatal and everything seems ok. I am just curious
>>> about what might trigger this. The addresses look to be inside the hypervisor
>>> code. I was wondering whether there is a simple way to figure out what this
>>> relates to (likely need to look at the objdump of the unstripped hv module).
>>>
>>> Or has someone already looked into this and knows what likely is the cause?
>>>
>>> -Stefan
>> Specifically, the message indicates <type of fault>: faulting address ->
>> fixup address
>>
>> It is probably a wrmsr, and a higher logging level will indicate this. 
>> My gut feeling is that it is dom0 attempting to load microcode using the
>> native method.
>>
>> ~Andrew
>>
> The faulting address in my case seems to be rdmsr_save (xen-4.4.1 base), the
> fixup address somewhere unspecific in hvm.c (not sure whether that makes sense
> coming from a dom0 startup). I will have to re-compile this with the gdprintk
> enabled to see which MSR that was.

The fixup address lives in the .fixup section which is generally linked
elsewhere.  See the definition of rdmsr_safe() which does
section-jumping in the asm statement.

>
> rdmsr_normal:
>             /* Everyone can read the MSR space. */
>             /* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR %p.\n",
>                         _p(regs->ecx));*/
>             if ( rdmsr_safe(regs->ecx, msr_content) )
>                 goto fail;
>
> Though likely related to the following WRMSRs following (the addresses differ
> from the subject I wasn't sure from where exactly I took the others and these
> are with 4.4.1 and directly after boot):

These will most likely be in wrmsr_safe()

>
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x004281c2001
> a8168 to 0x004281c200148168.
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x004281c2001
> a8168 to 0x004281c2001a0168.
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x004281c2001
> a8168 to 0x004201c2001a8168.
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 00000000000001b2 from 0x00000000000
> 00000 to 0x0000000000009600.
>
> The 0x1b2 seems to be thermal interrupt control. Cannot find the 0x610 right now
> (need to refresh my docs)...
>

MSR 0x610 is MSR_PKG_POWER_LIMIT on SandyBridge and later.

~Andrew


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:38:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlFxx-0006fB-6v; Mon, 03 Nov 2014 11:38:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XlFxw-0006eu-Ak
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:38:32 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	72/C2-02702-73967545; Mon, 03 Nov 2014 11:38:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415014709!8858188!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18416 invoked from network); 3 Nov 2014 11:38:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:38:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188852084"
Message-ID: <54576932.9030803@citrix.com>
Date: Mon, 3 Nov 2014 11:38:26 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>, <Xen-devel@lists.xen.org>
References: <54574EA0.5070101@canonical.com> <54575E32.6040603@citrix.com>
	<545764BB.7080005@canonical.com>
In-Reply-To: <545764BB.7080005@canonical.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/11/14 11:19, Stefan Bader wrote:
> On 03.11.2014 11:51, Andrew Cooper wrote:
>> On 03/11/14 09:45, Stefan Bader wrote:
>>> I see the message from the subject on my Intel box whenever a guest (iirc even
>>> dom0) starts up. It is not fatal and everything seems ok. I am just curious
>>> about what might trigger this. The addresses look to be inside the hypervisor
>>> code. I was wondering whether there is a simple way to figure out what this
>>> relates to (likely need to look at the objdump of the unstripped hv module).
>>>
>>> Or has someone already looked into this and knows what likely is the cause?
>>>
>>> -Stefan
>> Specifically, the message indicates <type of fault>: faulting address ->
>> fixup address
>>
>> It is probably a wrmsr, and a higher logging level will indicate this. 
>> My gut feeling is that it is dom0 attempting to load microcode using the
>> native method.
>>
>> ~Andrew
>>
> The faulting address in my case seems to be rdmsr_save (xen-4.4.1 base), the
> fixup address somewhere unspecific in hvm.c (not sure whether that makes sense
> coming from a dom0 startup). I will have to re-compile this with the gdprintk
> enabled to see which MSR that was.

The fixup address lives in the .fixup section which is generally linked
elsewhere.  See the definition of rdmsr_safe() which does
section-jumping in the asm statement.

>
> rdmsr_normal:
>             /* Everyone can read the MSR space. */
>             /* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR %p.\n",
>                         _p(regs->ecx));*/
>             if ( rdmsr_safe(regs->ecx, msr_content) )
>                 goto fail;
>
> Though likely related to the following WRMSRs following (the addresses differ
> from the subject I wasn't sure from where exactly I took the others and these
> are with 4.4.1 and directly after boot):

These will most likely be in wrmsr_safe()

>
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x004281c2001
> a8168 to 0x004281c200148168.
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x004281c2001
> a8168 to 0x004281c2001a0168.
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x004281c2001
> a8168 to 0x004201c2001a8168.
> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
> (XEN) traps.c:2514:d0 Domain attempted WRMSR 00000000000001b2 from 0x00000000000
> 00000 to 0x0000000000009600.
>
> The 0x1b2 seems to be thermal interrupt control. Cannot find the 0x610 right now
> (need to refresh my docs)...
>

MSR 0x610 is MSR_PKG_POWER_LIMIT on SandyBridge and later.

~Andrew


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:43:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlG2p-00076e-HH; Mon, 03 Nov 2014 11:43:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlG2o-00076T-6f
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:43:34 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	64/13-23865-56A67545; Mon, 03 Nov 2014 11:43:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415015012!11274741!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26177 invoked from network); 3 Nov 2014 11:43:32 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 11:43:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 11:43:32 +0000
Message-Id: <5457787002000078000445C7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 11:43:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
In-Reply-To: <545767C4.7070806@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 12:32, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 17:51, Jan Beulich wrote:
>>>>> On 03.11.14 at 10:40, <tiejun.chen@intel.com> wrote:
>>> On 2014/11/3 16:56, Jan Beulich wrote:
>>>>>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>>>>>     From: Chen, Tiejun
>>>>>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>>>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>>>>>> Thinking about this some more, this odd universal hole punching in
>>>>>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>>>>>> this really should be optional behavior, with pass through of devices
>>>>>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>>>>>> punching holes for _just_ the devices passed through to a guest
>>>>>>>>> upon creation when the option is not enabled.)
>>>>>>>>
>>>>>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>>>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>>>>>> conflict with anything. So what about this idea?
>>>>>>>>
>>>>>>>
>>>>>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>>>>>> approach. When the parameter is on, RMRR check/hole punch is
>>>>>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>>>>>
>>>>>>> If user configures device pass-through at creation time, this parameter
>>>>>>> will be set by default. If user wants the VM capable of device hot-plug,
>>>>>>> an explicit parameter can be added in the config file to enforce RMRR
>>>>>>> check at creation time.
>>>>>>
>>>>>> Not exactly, I specifically described it slightly differently above. When
>>>>>> devices get passed through and the option is absent, holes should be
>>>>>> punched only for the RMRRs associated with those devices (i.e.
>>>>>> ideally none). Of course this means we'll need a way to associate
>>>>>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>>>>>> XENMEM_reserved_device_memory_map alone won't suffice.
>>>>>
>>>>> Yeah, current hypercall just provide RMRR entries without that
>>>>> associated BDF. And especially, in some cases one range may be shared by
>>>>> multiple devices...
>>>>
>>>> Before we decide who's going to do an eventual change we need to
>>>> determine what behavior we want, and whether this hypercall is
>>>> really the right one. Quite possibly we'd need a per-domain view
>>>> along with the global view, and hence rather than modifying this one
>>>> we may need to introduce e.g. a new domctl.
>>>>
>>>
>>> If we really need to work with a hypercall, maybe we can introduce a
>>> little bit to construct that to callback with multiple entries like
>>> this, for instance,
>>>
>>> RMRR entry0 have three devices, and entry1 have two devices,
>>>
>>> [start0, nr_pages0, bdf0],
>>> [start0, nr_pages0, bdf1],
>>> [start0, nr_pages0, bdf2],
>>> [start1, nr_pages1, bdf3],
>>> [start1, nr_pages1, bdf4],
>>>
>>> Although its cost more buffers, actually as you know this actual case is
>>> really rare. So maybe this way can be feasible. Then we don't need
>>> additional hypercall or xenstore.
>>
>> Conceptually, as a MEMOP, it has no business reporting BDFs. And
>> then rather than returning the same address range more than once,
>> having the caller supply a handle to an array and storing all of the
>> SBDFs (or perhaps a single segment would suffice along with all the
>> BDFs) there would seem to be an approach more consistent with
>> what we do elsewhere.
> 
> Here I'm wondering if we really need to expose BDFs to tools. Actually 
> tools just want to know those range no matter who owns these entries. I 
> mean we can do this in Xen.

As pointed out before, in order for the tools to (a) avoid punching
_all possible_ holes when not asked to but (b) punch holes for all
devices assigned right at guest boot time, I don't think the tools
can get away without having some way of identifying the _specific_
reserved memory regions a guest needs. Whether this works via
SBDF or some other means is tbd.

> When we try to assign device as passthrough, Xen can get that bdf so Xen 
> can pre-check everything inside that hypercall, and Xen can return 
> something like this,
> 
> #1 If this device has RMRR, we return that rmrr buffer. This is similar 
> with our current implementation.

"That rmrr buffer" being which? Remember that there may be
multiple devices associated with RMRRs and multiple devices
assigned to a guest.

> #2 If not, we return 'nr_entries' as '0' to notify hvmloader it has 
> nothing to do.

This (as vague as it is) hints in the same domain-specific reserved
region determination that I was already hinting at.

Jan

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:43:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlG2p-00076e-HH; Mon, 03 Nov 2014 11:43:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlG2o-00076T-6f
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:43:34 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	64/13-23865-56A67545; Mon, 03 Nov 2014 11:43:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415015012!11274741!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26177 invoked from network); 3 Nov 2014 11:43:32 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 11:43:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 11:43:32 +0000
Message-Id: <5457787002000078000445C7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 11:43:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
In-Reply-To: <545767C4.7070806@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 12:32, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 17:51, Jan Beulich wrote:
>>>>> On 03.11.14 at 10:40, <tiejun.chen@intel.com> wrote:
>>> On 2014/11/3 16:56, Jan Beulich wrote:
>>>>>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>>>>>     From: Chen, Tiejun
>>>>>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>>>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>>>>>> Thinking about this some more, this odd universal hole punching in
>>>>>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>>>>>> this really should be optional behavior, with pass through of devices
>>>>>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>>>>>> punching holes for _just_ the devices passed through to a guest
>>>>>>>>> upon creation when the option is not enabled.)
>>>>>>>>
>>>>>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>>>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>>>>>> conflict with anything. So what about this idea?
>>>>>>>>
>>>>>>>
>>>>>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>>>>>> approach. When the parameter is on, RMRR check/hole punch is
>>>>>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>>>>>
>>>>>>> If user configures device pass-through at creation time, this parameter
>>>>>>> will be set by default. If user wants the VM capable of device hot-plug,
>>>>>>> an explicit parameter can be added in the config file to enforce RMRR
>>>>>>> check at creation time.
>>>>>>
>>>>>> Not exactly, I specifically described it slightly differently above. When
>>>>>> devices get passed through and the option is absent, holes should be
>>>>>> punched only for the RMRRs associated with those devices (i.e.
>>>>>> ideally none). Of course this means we'll need a way to associate
>>>>>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>>>>>> XENMEM_reserved_device_memory_map alone won't suffice.
>>>>>
>>>>> Yeah, current hypercall just provide RMRR entries without that
>>>>> associated BDF. And especially, in some cases one range may be shared by
>>>>> multiple devices...
>>>>
>>>> Before we decide who's going to do an eventual change we need to
>>>> determine what behavior we want, and whether this hypercall is
>>>> really the right one. Quite possibly we'd need a per-domain view
>>>> along with the global view, and hence rather than modifying this one
>>>> we may need to introduce e.g. a new domctl.
>>>>
>>>
>>> If we really need to work with a hypercall, maybe we can introduce a
>>> little bit to construct that to callback with multiple entries like
>>> this, for instance,
>>>
>>> RMRR entry0 have three devices, and entry1 have two devices,
>>>
>>> [start0, nr_pages0, bdf0],
>>> [start0, nr_pages0, bdf1],
>>> [start0, nr_pages0, bdf2],
>>> [start1, nr_pages1, bdf3],
>>> [start1, nr_pages1, bdf4],
>>>
>>> Although its cost more buffers, actually as you know this actual case is
>>> really rare. So maybe this way can be feasible. Then we don't need
>>> additional hypercall or xenstore.
>>
>> Conceptually, as a MEMOP, it has no business reporting BDFs. And
>> then rather than returning the same address range more than once,
>> having the caller supply a handle to an array and storing all of the
>> SBDFs (or perhaps a single segment would suffice along with all the
>> BDFs) there would seem to be an approach more consistent with
>> what we do elsewhere.
> 
> Here I'm wondering if we really need to expose BDFs to tools. Actually 
> tools just want to know those range no matter who owns these entries. I 
> mean we can do this in Xen.

As pointed out before, in order for the tools to (a) avoid punching
_all possible_ holes when not asked to but (b) punch holes for all
devices assigned right at guest boot time, I don't think the tools
can get away without having some way of identifying the _specific_
reserved memory regions a guest needs. Whether this works via
SBDF or some other means is tbd.

> When we try to assign device as passthrough, Xen can get that bdf so Xen 
> can pre-check everything inside that hypercall, and Xen can return 
> something like this,
> 
> #1 If this device has RMRR, we return that rmrr buffer. This is similar 
> with our current implementation.

"That rmrr buffer" being which? Remember that there may be
multiple devices associated with RMRRs and multiple devices
assigned to a guest.

> #2 If not, we return 'nr_entries' as '0' to notify hvmloader it has 
> nothing to do.

This (as vague as it is) hints in the same domain-specific reserved
region determination that I was already hinting at.

Jan

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:47:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlG70-0007JX-9N; Mon, 03 Nov 2014 11:47:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlG6y-0007JS-NR
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 11:47:52 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	39/C4-02696-86B67545; Mon, 03 Nov 2014 11:47:52 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415015270!12194205!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21476 invoked from network); 3 Nov 2014 11:47:50 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-14.tower-27.messagelabs.com with SMTP;
	3 Nov 2014 11:47:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 03 Nov 2014 03:41:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,307,1413270000"; d="scan'208";a="615958729"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 03:47:39 -0800
Message-ID: <54576B5A.50005@intel.com>
Date: Mon, 03 Nov 2014 19:47:38 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Paolo Bonzini <pbonzini@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>
References: <20140901060506.GA20186@redhat.com>	<54042514.6090206@intel.com>	<003AAFE53969E14CB1F09B6FD68C3CD478F16D2A@ORSMSX101.amr.corp.intel.com>	<54277979.7070408@intel.com>	<20140929100111.GA32459@redhat.com>	<542A18BD.2060008@intel.com>	<20141007072653.GB2424@redhat.com>	<543622CC.6050807@intel.com>	<20141012095021.GC9567@redhat.com>	<544A0174.7000003@intel.com>	<20141024134747.GA6024@redhat.com>	<5451ED1E.1000300@intel.com>
	<5457335B.1000308@intel.com>	<5457686E.7020601@redhat.com>
	<545768CC.3000903@intel.com>
In-Reply-To: <545768CC.3000903@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xen:i386:pc_piix: create
 isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 19:36, Chen, Tiejun wrote:
> On 2014/11/3 19:35, Paolo Bonzini wrote:
>> On 03/11/2014 08:48, Chen, Tiejun wrote:
>>>>>>> I think the point was mostly to reserve 1f to prevent
>>>>>>> devices from using it.
>>>>>>> As we populate slots in order it doesn't seem to important ...
>>>>>>
>>>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>>>>
>>>>> Right, but I mean if no special options are used, 1f will typically
>>>>> stay free without any effort on our side.
>>>>
>>>> Yeah.
>>>>
>>>> Actually based on current info we know, seems 1f is just specific to
>>>> our
>>>> scenario :) So I always think we can occupy that. But Paolo and you can
>>>> really determine this point.
>>>
>>> What's your idea?
>>
>> I do not have any objection to always occupying 1f for Xen IGD
>> passthrough.

After I go back to look at this again, I hope you don't misunderstand 
what Michael mean now. He was saying we don't need to create a new 
separate machine specific to IGD passthrough. But that idea is just from 
you :)

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:47:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlG70-0007JX-9N; Mon, 03 Nov 2014 11:47:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlG6y-0007JS-NR
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 11:47:52 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	39/C4-02696-86B67545; Mon, 03 Nov 2014 11:47:52 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415015270!12194205!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21476 invoked from network); 3 Nov 2014 11:47:50 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-14.tower-27.messagelabs.com with SMTP;
	3 Nov 2014 11:47:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 03 Nov 2014 03:41:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,307,1413270000"; d="scan'208";a="615958729"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 03:47:39 -0800
Message-ID: <54576B5A.50005@intel.com>
Date: Mon, 03 Nov 2014 19:47:38 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Paolo Bonzini <pbonzini@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>
References: <20140901060506.GA20186@redhat.com>	<54042514.6090206@intel.com>	<003AAFE53969E14CB1F09B6FD68C3CD478F16D2A@ORSMSX101.amr.corp.intel.com>	<54277979.7070408@intel.com>	<20140929100111.GA32459@redhat.com>	<542A18BD.2060008@intel.com>	<20141007072653.GB2424@redhat.com>	<543622CC.6050807@intel.com>	<20141012095021.GC9567@redhat.com>	<544A0174.7000003@intel.com>	<20141024134747.GA6024@redhat.com>	<5451ED1E.1000300@intel.com>
	<5457335B.1000308@intel.com>	<5457686E.7020601@redhat.com>
	<545768CC.3000903@intel.com>
In-Reply-To: <545768CC.3000903@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xen:i386:pc_piix: create
 isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 19:36, Chen, Tiejun wrote:
> On 2014/11/3 19:35, Paolo Bonzini wrote:
>> On 03/11/2014 08:48, Chen, Tiejun wrote:
>>>>>>> I think the point was mostly to reserve 1f to prevent
>>>>>>> devices from using it.
>>>>>>> As we populate slots in order it doesn't seem to important ...
>>>>>>
>>>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>>>>
>>>>> Right, but I mean if no special options are used, 1f will typically
>>>>> stay free without any effort on our side.
>>>>
>>>> Yeah.
>>>>
>>>> Actually based on current info we know, seems 1f is just specific to
>>>> our
>>>> scenario :) So I always think we can occupy that. But Paolo and you can
>>>> really determine this point.
>>>
>>> What's your idea?
>>
>> I do not have any objection to always occupying 1f for Xen IGD
>> passthrough.

After I go back to look at this again, I hope you don't misunderstand 
what Michael mean now. He was saying we don't need to create a new 
separate machine specific to IGD passthrough. But that idea is just from 
you :)

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:48:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11: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 1XlG7F-0007LW-M5; Mon, 03 Nov 2014 11:48:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlG7D-0007LJ-P5
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:48:07 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	53/54-07724-77B67545; Mon, 03 Nov 2014 11:48:07 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415015286!11228515!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12344 invoked from network); 3 Nov 2014 11:48:06 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 11:48:06 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 03:48:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,307,1413270000"; d="scan'208";a="615958890"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 03:47:54 -0800
Message-ID: <54576B69.2060705@intel.com>
Date: Mon, 03 Nov 2014 19:47:53 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
	<54575C3E020000780004440F@mail.emea.novell.com>
	<54575372.7020406@intel.com>
	<545764D102000078000444F0@mail.emea.novell.com>
	<5457656E.9040604@intel.com>
	<5457770102000078000445A5@mail.emea.novell.com>
In-Reply-To: <5457770102000078000445A5@mail.emea.novell.com>
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 19:37, Jan Beulich wrote:
>>>> On 03.11.14 at 12:22, <tiejun.chen@intel.com> wrote:
>> Are you saying that dependency?
>>
>> @@ -87,6 +87,11 @@ endif
>>    all: subdirs-all
>>           $(MAKE) hvmloader
>>
>> +subdirs-all: errno
>> +
>> +errno:
>> +       ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
>> +
>>    ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
>>    smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
>
> Another step in the right direction. If now you also change the target
> to be "errno.h" instead of "errno", we'll have what we want.
>

Okay,

  all: subdirs-all
         $(MAKE) hvmloader

+subdirs-all: errno.h
+
+errno.h:
+       ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
+
  ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
  smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""

If this is fine I will send next revision once some tools maintainer can 
give an acknowledge.

Thanks
Tiejun


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:48:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11: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 1XlG7F-0007LW-M5; Mon, 03 Nov 2014 11:48:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlG7D-0007LJ-P5
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:48:07 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	53/54-07724-77B67545; Mon, 03 Nov 2014 11:48:07 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415015286!11228515!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12344 invoked from network); 3 Nov 2014 11:48:06 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-31.messagelabs.com with SMTP;
	3 Nov 2014 11:48:06 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 03:48:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,307,1413270000"; d="scan'208";a="615958890"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 03:47:54 -0800
Message-ID: <54576B69.2060705@intel.com>
Date: Mon, 03 Nov 2014 19:47:53 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415005248-25620-1-git-send-email-tiejun.chen@intel.com>
	<54575C3E020000780004440F@mail.emea.novell.com>
	<54575372.7020406@intel.com>
	<545764D102000078000444F0@mail.emea.novell.com>
	<5457656E.9040604@intel.com>
	<5457770102000078000445A5@mail.emea.novell.com>
In-Reply-To: <5457770102000078000445A5@mail.emea.novell.com>
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v2][PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 19:37, Jan Beulich wrote:
>>>> On 03.11.14 at 12:22, <tiejun.chen@intel.com> wrote:
>> Are you saying that dependency?
>>
>> @@ -87,6 +87,11 @@ endif
>>    all: subdirs-all
>>           $(MAKE) hvmloader
>>
>> +subdirs-all: errno
>> +
>> +errno:
>> +       ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
>> +
>>    ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
>>    smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
>
> Another step in the right direction. If now you also change the target
> to be "errno.h" instead of "errno", we'll have what we want.
>

Okay,

  all: subdirs-all
         $(MAKE) hvmloader

+subdirs-all: errno.h
+
+errno.h:
+       ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
+
  ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
  smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""

If this is fine I will send next revision once some tools maintainer can 
give an acknowledge.

Thanks
Tiejun


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:48:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlG7t-0007SA-4P; Mon, 03 Nov 2014 11:48:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlG7r-0007Rx-T8
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:48:47 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	99/AF-27785-F9B67545; Mon, 03 Nov 2014 11:48:47 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415015325!12194464!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27762 invoked from network); 3 Nov 2014 11:48:46 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-14.tower-27.messagelabs.com with SMTP;
	3 Nov 2014 11:48:46 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 03 Nov 2014 03:48:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,307,1413270000"; d="scan'208";a="615959136"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 03:48:43 -0800
Message-ID: <54576B9B.1060601@intel.com>
Date: Mon, 03 Nov 2014 19:48:43 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
In-Reply-To: <545760FD0200007800044474@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 18:03, Jan Beulich wrote:
>>>> On 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>>> #2 the error handling
>>>>
>>>> In an error case what should I do? Currently we still create these
>>>> mapping as normal. This means these mfns will be valid so later we can't
>>>> set them again then device can't be assigned as passthrough. I think
>>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>>
>>> You should, with very few exceptions, not ignore errors (which
>>> includes "handling" them by just logging a message. Instead, you
>>> should propagate the error back up the call chain.
>>>
>>
>> Do you mean in your patch,
>>
>> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>> +{
>> +    const struct iommu_ops *ops = iommu_get_ops();
>> +
>> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
>> +        return 0;
>> +
>> +    return ops->get_reserved_device_memory(func, ctxt);
>> +}
>> +
>>
>> I shouldn't return that directly. Then instead, we should handle all
>> error scenarios here?
>
> No. All error scenarios are already being handled here (by
> propagating the error code to the caller).

Sorry, how to propagate the error code?

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:48:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlG7t-0007SA-4P; Mon, 03 Nov 2014 11:48:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlG7r-0007Rx-T8
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:48:47 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	99/AF-27785-F9B67545; Mon, 03 Nov 2014 11:48:47 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415015325!12194464!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27762 invoked from network); 3 Nov 2014 11:48:46 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-14.tower-27.messagelabs.com with SMTP;
	3 Nov 2014 11:48:46 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 03 Nov 2014 03:48:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,307,1413270000"; d="scan'208";a="615959136"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 03:48:43 -0800
Message-ID: <54576B9B.1060601@intel.com>
Date: Mon, 03 Nov 2014 19:48:43 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
In-Reply-To: <545760FD0200007800044474@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 18:03, Jan Beulich wrote:
>>>> On 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>>> #2 the error handling
>>>>
>>>> In an error case what should I do? Currently we still create these
>>>> mapping as normal. This means these mfns will be valid so later we can't
>>>> set them again then device can't be assigned as passthrough. I think
>>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>>
>>> You should, with very few exceptions, not ignore errors (which
>>> includes "handling" them by just logging a message. Instead, you
>>> should propagate the error back up the call chain.
>>>
>>
>> Do you mean in your patch,
>>
>> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>> +{
>> +    const struct iommu_ops *ops = iommu_get_ops();
>> +
>> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
>> +        return 0;
>> +
>> +    return ops->get_reserved_device_memory(func, ctxt);
>> +}
>> +
>>
>> I shouldn't return that directly. Then instead, we should handle all
>> error scenarios here?
>
> No. All error scenarios are already being handled here (by
> propagating the error code to the caller).

Sorry, how to propagate the error code?

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:53:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:53:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGCd-0007nz-Ui; Mon, 03 Nov 2014 11:53:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlGCc-0007ns-AG
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:53:42 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	10/56-09842-5CC67545; Mon, 03 Nov 2014 11:53:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415015621!12405591!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18700 invoked from network); 3 Nov 2014 11:53:41 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 11:53:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 11:53:40 +0000
Message-Id: <54577AD302000078000445EB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 11:53:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
In-Reply-To: <54576B9B.1060601@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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 03.11.14 at 12:48, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 18:03, Jan Beulich wrote:
>>>>> On 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
>>> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>>>> #2 the error handling
>>>>>
>>>>> In an error case what should I do? Currently we still create these
>>>>> mapping as normal. This means these mfns will be valid so later we can't
>>>>> set them again then device can't be assigned as passthrough. I think
>>>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>>>
>>>> You should, with very few exceptions, not ignore errors (which
>>>> includes "handling" them by just logging a message. Instead, you
>>>> should propagate the error back up the call chain.
>>>>
>>>
>>> Do you mean in your patch,
>>>
>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>> +{
>>> +    const struct iommu_ops *ops = iommu_get_ops();
>>> +
>>> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
>>> +        return 0;
>>> +
>>> +    return ops->get_reserved_device_memory(func, ctxt);
>>> +}
>>> +
>>>
>>> I shouldn't return that directly. Then instead, we should handle all
>>> error scenarios here?
>>
>> No. All error scenarios are already being handled here (by
>> propagating the error code to the caller).
> 
> Sorry, how to propagate the error code?

Return it to the caller (and it will do so onwards, until it reaches
[presumably] the entity having invoked a hypercall).

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:53:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:53:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGCd-0007nz-Ui; Mon, 03 Nov 2014 11:53:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlGCc-0007ns-AG
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:53:42 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	10/56-09842-5CC67545; Mon, 03 Nov 2014 11:53:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415015621!12405591!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18700 invoked from network); 3 Nov 2014 11:53:41 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 11:53:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 11:53:40 +0000
Message-Id: <54577AD302000078000445EB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 11:53:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
In-Reply-To: <54576B9B.1060601@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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 03.11.14 at 12:48, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 18:03, Jan Beulich wrote:
>>>>> On 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
>>> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>>>> #2 the error handling
>>>>>
>>>>> In an error case what should I do? Currently we still create these
>>>>> mapping as normal. This means these mfns will be valid so later we can't
>>>>> set them again then device can't be assigned as passthrough. I think
>>>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>>>
>>>> You should, with very few exceptions, not ignore errors (which
>>>> includes "handling" them by just logging a message. Instead, you
>>>> should propagate the error back up the call chain.
>>>>
>>>
>>> Do you mean in your patch,
>>>
>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>> +{
>>> +    const struct iommu_ops *ops = iommu_get_ops();
>>> +
>>> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
>>> +        return 0;
>>> +
>>> +    return ops->get_reserved_device_memory(func, ctxt);
>>> +}
>>> +
>>>
>>> I shouldn't return that directly. Then instead, we should handle all
>>> error scenarios here?
>>
>> No. All error scenarios are already being handled here (by
>> propagating the error code to the caller).
> 
> Sorry, how to propagate the error code?

Return it to the caller (and it will do so onwards, until it reaches
[presumably] the entity having invoked a hypercall).

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:54:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11: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.xen.org>)
	id 1XlGCq-0007pq-Aq; Mon, 03 Nov 2014 11:53: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@citrix.com>) id 1XlGCo-0007pJ-I0
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:53:54 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	1A/91-01660-1DC67545; Mon, 03 Nov 2014 11:53:53 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415015626!10848774!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3685 invoked from network); 3 Nov 2014 11:53:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:53:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187477239"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 06:53:45 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlGCe-0008LX-NK;
	Mon, 03 Nov 2014 11:53:44 +0000
Date: Mon, 3 Nov 2014 11:53:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Quan Xu <quan.xu@intel.com>
In-Reply-To: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
Message-ID: <alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2 Nov 2014, Quan Xu wrote:
> This drvier transfers any request/repond between TPM xenstubdoms
> driver and Xen vTPM stubdom, and facilitates communications between
> Xen vTPM stubdom domain and vTPM xenstubdoms driver
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>

Please describe what changes did make to xen_backend.c and why.
The commit message should contains info on all the changes made by the
patch below.

Please also describe what is the "Xen vTPM stubdom", what is the
"vTPM xenstubdoms driver" and how the communicate with each others.

Where does the vTPM backend lives?


>  hw/xen/Makefile.objs         |   1 +
>  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
>  hw/xen/xen_stubdom_vtpm.c    | 333 +++++++++++++++++++++++++++++++++++++++++++
>  include/hw/xen/xen_backend.h |  11 ++
>  include/hw/xen/xen_common.h  |   6 +
>  xen-hvm.c                    |  13 ++
>  6 files changed, 544 insertions(+), 2 deletions(-)
>  create mode 100644 hw/xen/xen_stubdom_vtpm.c
> 
> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> index a0ca0aa..724df8d 100644
> --- a/hw/xen/Makefile.objs
> +++ b/hw/xen/Makefile.objs
> @@ -1,5 +1,6 @@
>  # xen backend driver support
>  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
> +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
>  
>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index b2cb22b..45a5778 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state)
>      return 0;
>  }
>  
> +/*get stubdom backend*/
> +static char *xen_stubdom_be(const char *type, int dom, int dev)
> +{
> +    char *val, *domu;
> +    char path[XEN_BUFSIZE];
> +    unsigned int len, ival;
> +
> +    /*front domu*/
> +    domu = xs_get_domain_path(xenstore, dom);
> +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> +             domu, type, dev);
> +    g_free(domu);
> +
> +    val = xs_read(xenstore, 0, path, &len);
> +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> +        g_free(val);
> +        return NULL;
> +    }
> +    g_free(val);
> +
> +    /*backend domu*/
> +    domu = xs_get_domain_path(xenstore, ival);
> +
> +    return domu;
> +}
> +
>  /* ------------------------------------------------------------- */
>  
>  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
> @@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
>                                             struct XenDevOps *ops)
>  {
>      struct XenDevice *xendev;
> +    char *stub;
>  
>      xendev = xen_be_find_xendev(type, dom, dev);
>      if (xendev) {
> @@ -235,8 +262,15 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
>      xendev->dev   = dev;
>      xendev->ops   = ops;
>  
> -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> -             xendev->type, xendev->dom, xendev->dev);
> +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> +        stub = xen_stubdom_be(xendev->type, xendev->dom, xendev->dev);
> +        snprintf(xendev->be, sizeof(xendev->be), "%s/backend/%s/%d/%d",
> +                 stub, xendev->type, xendev->dom, xendev->dev);
> +        g_free(stub);
> +    } else {
> +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> +                 xendev->type, xendev->dom, xendev->dev);
> +    }
>      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
>               xendev->type, xendev->dev);
>  
> @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int dom, struct XenDevOps *ops)
>      return 0;
>  }
>  
> +static void stubdom_update_be(char *watch, char *type, int dom,
> +                              struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE];
> +    char *ptr, *bepath;
> +    unsigned int len, dev;
> +
> +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> +        return;
> +    }
> +
> +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> +    ptr = strstr(watch, path);
> +    if (ptr == NULL) {
> +        return;
> +    }
> +
> +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> +        strcpy(path, "");
> +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> +            dev = -1;
> +        }
> +    }
> +
> +    if (dev == -1) {
> +        return;
> +    }
> +
> +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> +    if (xendev != NULL) {
> +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> +        if (bepath == NULL) {
> +            xen_be_del_xendev(dom, dev);
> +        } else {
> +            free(bepath);
> +            xen_be_backend_changed(xendev, path);
> +        }
> +    }
> +}
> +
>  static void xenstore_update_be(char *watch, char *type, int dom,
>                                 struct XenDevOps *ops)
>  {
> @@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
>      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
>          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
>      }
> +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%" PRIxPTR,
> +               &type, &dom, &ops) == 3) {
> +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
> +    }
>  
>  cleanup:
>      free(vec);
> @@ -732,11 +811,74 @@ err:
>      return -1;
>  }
>  
> +int xen_vtpm_register(struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> +    char *domu;
> +    unsigned int cdev, j, rc;
> +    const char *type = "vtpm";
> +    char **dev = NULL;
> +
> +    /*front domu*/
> +    domu = xs_get_domain_path(xenstore, xen_domid);
> +    snprintf(path, sizeof(path), "%s/device/%s",
> +             domu, type);
> +    free(domu);
> +    dev = xs_directory(xenstore, 0, path, &cdev);
> +    if (dev == NULL) {
> +        return 0;
> +    }
> +
> +    for (j = 0; j < cdev; j++) {
> +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]), ops);
> +        if (xendev == NULL) {
> +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is NULL.\n");
> +            continue;
> +        }
> +
> +        if (xendev->ops->initialise) {
> +            rc = xendev->ops->initialise(xendev);
> +
> +            /*if initialise failed, delete it*/
> +            if (rc != 0) {
> +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> +                continue;
> +            }
> +        }
> +
> +        /*setup watch*/
> +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> +                 type, xen_domid, xendev->ops);
> +        if (!xs_watch(xenstore, xendev->be, token)) {
> +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch failed.\n");
> +            return -1;
> +        }
> +    }
> +
> +    free(dev);
> +    return 0;
> +}

What does this function do? I sholdn't need  to guess from the code, I
should be able to tell from the patch description.


>  int xen_be_register(const char *type, struct XenDevOps *ops)
>  {
>      return xenstore_scan(type, xen_domid, ops);
>  }
>  
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom)
> +{
> +    xendev->local_port = xc_evtchn_bind_unbound_port(xendev->evtchndev,
> +                                                     remote_dom);
> +    if (xendev->local_port == -1) {
> +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> +        return -1;
> +    }
> +    xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
> +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> +                        xen_be_evtchn_event, NULL, xendev);
> +    return 0;
> +}
> +
>  int xen_be_bind_evtchn(struct XenDevice *xendev)
>  {
>      if (xendev->local_port != -1) {
> @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice *xendev)
>      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
>  }
>  
> +int xen_vtpm_send(unsigned char *buf, size_t count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->send) {
> +        rc = xendev->ops->send(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}
> +
> +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->recv) {
> +        xendev->ops->recv(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}

xen_backend.c is supposed to be generic, so stubdom functions might be
OK but vtpm specific functions should not be here.


>  /*
>   * msg_level:
>   *  0 == errors (stderr + logfile).
> diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> new file mode 100644
> index 0000000..0d740c1
> --- /dev/null
> +++ b/hw/xen/xen_stubdom_vtpm.c
> @@ -0,0 +1,333 @@
> +/*
> + * Connect to Xen vTPM stubdom domain
> + *
> + *  Copyright (c) 2014 Intel Corporation
> + *  Authors:
> + *    Quan Xu <quan.xu@intel.com>
> + *
> + * 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 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, see <http://www.gnu.org/licenses/>
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <stdarg.h>
> +#include <string.h>
> +#include <unistd.h>
> +#include <signal.h>
> +#include <inttypes.h>
> +#include <time.h>
> +#include <fcntl.h>
> +#include <errno.h>
> +#include <sys/ioctl.h>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <sys/mman.h>
> +#include <sys/uio.h>
> +
> +#include "hw/hw.h"
> +#include "block/aio.h"
> +#include "hw/xen/xen_backend.h"
> +
> +enum tpmif_state {
> +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel complete */
> +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> +};
> +
> +static AioContext *vtpm_aio_ctx;
> +
> +enum status_bits {
> +    VTPM_STATUS_RUNNING  = 0x1,
> +    VTPM_STATUS_IDLE     = 0x2,
> +    VTPM_STATUS_RESULT   = 0x4,
> +    VTPM_STATUS_CANCELED = 0x8,
> +};
> +
> +struct tpmif_shared_page {
> +    uint32_t length;         /* request/response length in bytes */
> +
> +    uint8_t  state;           /* enum tpmif_state */
> +    uint8_t  locality;        /* for the current request */
> +    uint8_t  pad;             /* should be zero */
> +
> +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be zero */
> +    uint32_t extra_pages[0]; /* grant IDs; length is actually nr_extra_pages */
> +};
> +
> +struct QEMUBH {
> +    AioContext *ctx;
> +    QEMUBHFunc *cb;
> +    void *opaque;
> +    QEMUBH *next;
> +    bool scheduled;
> +    bool idle;
> +    bool deleted;
> +};
> +
> +struct XenVtpmDev {
> +    struct XenDevice xendev;  /* must be first */
> +    struct           tpmif_shared_page *shr;
> +    xc_gntshr        *xen_xcs;
> +    int              ring_ref;
> +    int              bedomid;
> +    QEMUBH           *sr_bh;
> +};
> +
> +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> +{
> +    switch (vtpmdev->shr->state) {
> +    case TPMIF_STATE_IDLE:
> +    case TPMIF_STATE_FINISH:
> +        return VTPM_STATUS_IDLE;
> +    case TPMIF_STATE_SUBMIT:
> +    case TPMIF_STATE_CANCEL:
> +        return VTPM_STATUS_RUNNING;
> +    default:
> +        return 0;
> +    }
> +}
> +
> +static int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)
> +{
> +    xs_transaction_t xbt = XBT_NULL;
> +
> +    if (xendev->fe_state == xbus) {
> +        return 0;
> +    }
> +
> +    xendev->fe_state = xbus;
> +
> +retry_transaction:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto retry_transaction;
> +        }
> +    }
> +
> +    return 0;
> +
> +abort_transaction:
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}
> +
> +static int vtpm_aio_wait(QEMUBH *qbh)
> +{
> +    return aio_poll(qbh->ctx, true);
> +}
> +
> +static void sr_bh_handler(void *opaque)
> +{
> +}
> +
> +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset;
> +
> +    if (shr->state == TPMIF_STATE_IDLE) {
> +        return -ECANCELED;
> +    }
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> +    *count = shr->length;
> +
> +    return 0;
> +}
> +
> +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    memcpy(offset + (uint8_t *)shr, buf, count);
> +    shr->length = count;
> +    barrier();
> +    shr->state = TPMIF_STATE_SUBMIT;
> +    xen_wmb();
> +    xen_be_send_notify(&vtpmdev->xendev);
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    return count;
> +}
> +
> +static int vtpm_initialise(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    xs_transaction_t xbt = XBT_NULL;
> +    unsigned int ring_ref;
> +
> +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev, "frontend");
> +    if (vtpmdev->xendev.fe == NULL) {
> +        return -1;
> +    }
> +
> +    /* Get backend domid */
> +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> +                             &vtpmdev->bedomid)) {
> +        return -1;
> +    }
> +
> +    /*alloc share page*/
> +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs, vtpmdev->bedomid, 1,
> +                                         &ring_ref, PROT_READ|PROT_WRITE);
> +    vtpmdev->ring_ref = ring_ref;
> +    if (vtpmdev->shr == NULL) {
> +        return -1;
> +    }
> +
> +    /*Create event channel */
> +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0, vtpmdev->bedomid)) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +        return -1;
> +    }
> +
> +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> +                     vtpmdev->xendev.local_port);
> +
> +again:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> +                           vtpmdev->ring_ref)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> +                           vtpmdev->xendev.local_port)) {
> +        goto abort_transaction;
> +    }
> +
> +    /* Publish protocol v2 feature */
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto again;
> +        }
> +    }
> +    /* Tell vtpm backend that we are ready */
> +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> +
> +    return 0;
> +
> +abort_transaction:
> +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}
> +
> +static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    int be_state;
> +
> +    if (strcmp(node, "state") == 0) {
> +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> +        switch (be_state) {
> +        case XenbusStateConnected:
> +            /*TODO*/
> +            break;
> +        case XenbusStateClosing:
> +        case XenbusStateClosed:
> +            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
> +            break;
> +        default:
> +            break;
> +        }
> +    }
> +}
> +
> +static int vtpm_free(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    QEMUBH *qbh = vtpmdev->sr_bh;
> +
> +    aio_poll(qbh->ctx, false);
> +    qemu_bh_delete(vtpmdev->sr_bh);
> +    if (vtpmdev->shr) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    }
> +    xc_interface_close(vtpmdev->xen_xcs);
> +    return 0;
> +}
> +
> +static void vtpm_alloc(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    vtpm_aio_ctx = aio_context_new(NULL);
> +    if (vtpm_aio_ctx == NULL) {
> +        return;
> +    }
> +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler, vtpmdev);
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> +}
> +
> +static void vtpm_event(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +}
> +
> +struct XenDevOps xen_vtpmdev_ops = {
> +    .size             = sizeof(struct XenVtpmDev),
> +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> +                        DEVOPS_FLAG_STUBDOM_BE,
> +    .event            = vtpm_event,
> +    .free             = vtpm_free,
> +    .alloc            = vtpm_alloc,
> +    .initialise       = vtpm_initialise,
> +    .backend_changed  = vtpm_backend_changed,
> +    .recv             = vtpm_recv,
> +    .send             = vtpm_send,
> +};

Is this the frontend, like the subject line would seem to imply?
If so, XenDevOps are made for backends, while this is a frontend. In
fact this is the first PV frontend in QEMU. We need to introduce
something generic and similar to struct XenDevOps and xen_backend.c but
for frontends.


> diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
> index 3b4125e..45fd6d3 100644
> --- a/include/hw/xen/xen_backend.h
> +++ b/include/hw/xen/xen_backend.h
> @@ -15,6 +15,8 @@ struct XenDevice;
>  #define DEVOPS_FLAG_NEED_GNTDEV   1
>  /* don't expect frontend doing correct state transitions (aka console quirk) */
>  #define DEVOPS_FLAG_IGNORE_STATE  2
> +/*dev backend is stubdom*/
> +#define DEVOPS_FLAG_STUBDOM_BE    4
>  
>  struct XenDevOps {
>      size_t    size;
> @@ -26,6 +28,8 @@ struct XenDevOps {
>      void      (*event)(struct XenDevice *xendev);
>      void      (*disconnect)(struct XenDevice *xendev);
>      int       (*free)(struct XenDevice *xendev);
> +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t count);
> +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t *count);
>      void      (*backend_changed)(struct XenDevice *xendev, const char *node);
>      void      (*frontend_changed)(struct XenDevice *xendev, const char *node);
>  };
> @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice *xendev);
>  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...)
>      GCC_FMT_ATTR(3, 4);
>  
> +/*Xen stubdom vtpm*/
> +int xen_vtpm_register(struct XenDevOps *ops);
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
> +int xen_vtpm_send(unsigned char *buf, size_t count);
> +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> +
>  /* actual backend drivers */
>  extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
>  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c */
>  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
>  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c        */
>  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c         */
> +extern struct XenDevOps xen_vtpmdev_ops;      /* xen_stubdom_vtpm.c*/
>  
>  void xen_init_display(int domid);
>  
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 95612a4..fb43084 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
>      return xc_interface_open(logger, dombuild_logger, open_flags);
>  }
>  
> +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> +                                           unsigned int open_flags)
> +{
> +    return xc_gntshr_open(logger, open_flags);
> +}
> +
>  /* FIXME There is now way to have the xen fd */
>  static inline int xc_fd(xc_interface *xen_xc)
>  {
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 21f1cbb..c99ace8 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>      int i, rc;
>      unsigned long ioreq_pfn;
>      unsigned long bufioreq_evtchn;
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    unsigned long stubdom_vtpm = 0;
> +#endif
> +
>      XenIOState *state;
>  
>      state = g_malloc0(sizeof (XenIOState));
> @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>          fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
>          return -1;
>      }
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> +    if (stubdom_vtpm) {
> +        xen_vtpm_register(&xen_vtpmdev_ops);
> +    }
> +#endif

Given that vtpm is just a PV frontend, can't you just detect whether is
present on xenstore and initialize it based on that? Like all the
backend below?


>      xen_be_register("console", &xen_console_ops);
>      xen_be_register("vkbd", &xen_kbdmouse_ops);
>      xen_be_register("qdisk", &xen_blkdev_ops);
> -- 
> 1.8.3.2
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:54:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11: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.xen.org>)
	id 1XlGCq-0007pq-Aq; Mon, 03 Nov 2014 11:53: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@citrix.com>) id 1XlGCo-0007pJ-I0
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:53:54 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	1A/91-01660-1DC67545; Mon, 03 Nov 2014 11:53:53 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415015626!10848774!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3685 invoked from network); 3 Nov 2014 11:53:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 11:53:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="187477239"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 06:53:45 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlGCe-0008LX-NK;
	Mon, 03 Nov 2014 11:53:44 +0000
Date: Mon, 3 Nov 2014 11:53:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Quan Xu <quan.xu@intel.com>
In-Reply-To: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
Message-ID: <alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2 Nov 2014, Quan Xu wrote:
> This drvier transfers any request/repond between TPM xenstubdoms
> driver and Xen vTPM stubdom, and facilitates communications between
> Xen vTPM stubdom domain and vTPM xenstubdoms driver
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>

Please describe what changes did make to xen_backend.c and why.
The commit message should contains info on all the changes made by the
patch below.

Please also describe what is the "Xen vTPM stubdom", what is the
"vTPM xenstubdoms driver" and how the communicate with each others.

Where does the vTPM backend lives?


>  hw/xen/Makefile.objs         |   1 +
>  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
>  hw/xen/xen_stubdom_vtpm.c    | 333 +++++++++++++++++++++++++++++++++++++++++++
>  include/hw/xen/xen_backend.h |  11 ++
>  include/hw/xen/xen_common.h  |   6 +
>  xen-hvm.c                    |  13 ++
>  6 files changed, 544 insertions(+), 2 deletions(-)
>  create mode 100644 hw/xen/xen_stubdom_vtpm.c
> 
> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> index a0ca0aa..724df8d 100644
> --- a/hw/xen/Makefile.objs
> +++ b/hw/xen/Makefile.objs
> @@ -1,5 +1,6 @@
>  # xen backend driver support
>  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
> +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
>  
>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index b2cb22b..45a5778 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state)
>      return 0;
>  }
>  
> +/*get stubdom backend*/
> +static char *xen_stubdom_be(const char *type, int dom, int dev)
> +{
> +    char *val, *domu;
> +    char path[XEN_BUFSIZE];
> +    unsigned int len, ival;
> +
> +    /*front domu*/
> +    domu = xs_get_domain_path(xenstore, dom);
> +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> +             domu, type, dev);
> +    g_free(domu);
> +
> +    val = xs_read(xenstore, 0, path, &len);
> +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> +        g_free(val);
> +        return NULL;
> +    }
> +    g_free(val);
> +
> +    /*backend domu*/
> +    domu = xs_get_domain_path(xenstore, ival);
> +
> +    return domu;
> +}
> +
>  /* ------------------------------------------------------------- */
>  
>  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
> @@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
>                                             struct XenDevOps *ops)
>  {
>      struct XenDevice *xendev;
> +    char *stub;
>  
>      xendev = xen_be_find_xendev(type, dom, dev);
>      if (xendev) {
> @@ -235,8 +262,15 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
>      xendev->dev   = dev;
>      xendev->ops   = ops;
>  
> -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> -             xendev->type, xendev->dom, xendev->dev);
> +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> +        stub = xen_stubdom_be(xendev->type, xendev->dom, xendev->dev);
> +        snprintf(xendev->be, sizeof(xendev->be), "%s/backend/%s/%d/%d",
> +                 stub, xendev->type, xendev->dom, xendev->dev);
> +        g_free(stub);
> +    } else {
> +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> +                 xendev->type, xendev->dom, xendev->dev);
> +    }
>      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
>               xendev->type, xendev->dev);
>  
> @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int dom, struct XenDevOps *ops)
>      return 0;
>  }
>  
> +static void stubdom_update_be(char *watch, char *type, int dom,
> +                              struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE];
> +    char *ptr, *bepath;
> +    unsigned int len, dev;
> +
> +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> +        return;
> +    }
> +
> +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> +    ptr = strstr(watch, path);
> +    if (ptr == NULL) {
> +        return;
> +    }
> +
> +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> +        strcpy(path, "");
> +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> +            dev = -1;
> +        }
> +    }
> +
> +    if (dev == -1) {
> +        return;
> +    }
> +
> +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> +    if (xendev != NULL) {
> +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> +        if (bepath == NULL) {
> +            xen_be_del_xendev(dom, dev);
> +        } else {
> +            free(bepath);
> +            xen_be_backend_changed(xendev, path);
> +        }
> +    }
> +}
> +
>  static void xenstore_update_be(char *watch, char *type, int dom,
>                                 struct XenDevOps *ops)
>  {
> @@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
>      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
>          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
>      }
> +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%" PRIxPTR,
> +               &type, &dom, &ops) == 3) {
> +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
> +    }
>  
>  cleanup:
>      free(vec);
> @@ -732,11 +811,74 @@ err:
>      return -1;
>  }
>  
> +int xen_vtpm_register(struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> +    char *domu;
> +    unsigned int cdev, j, rc;
> +    const char *type = "vtpm";
> +    char **dev = NULL;
> +
> +    /*front domu*/
> +    domu = xs_get_domain_path(xenstore, xen_domid);
> +    snprintf(path, sizeof(path), "%s/device/%s",
> +             domu, type);
> +    free(domu);
> +    dev = xs_directory(xenstore, 0, path, &cdev);
> +    if (dev == NULL) {
> +        return 0;
> +    }
> +
> +    for (j = 0; j < cdev; j++) {
> +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]), ops);
> +        if (xendev == NULL) {
> +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is NULL.\n");
> +            continue;
> +        }
> +
> +        if (xendev->ops->initialise) {
> +            rc = xendev->ops->initialise(xendev);
> +
> +            /*if initialise failed, delete it*/
> +            if (rc != 0) {
> +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> +                continue;
> +            }
> +        }
> +
> +        /*setup watch*/
> +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> +                 type, xen_domid, xendev->ops);
> +        if (!xs_watch(xenstore, xendev->be, token)) {
> +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch failed.\n");
> +            return -1;
> +        }
> +    }
> +
> +    free(dev);
> +    return 0;
> +}

What does this function do? I sholdn't need  to guess from the code, I
should be able to tell from the patch description.


>  int xen_be_register(const char *type, struct XenDevOps *ops)
>  {
>      return xenstore_scan(type, xen_domid, ops);
>  }
>  
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom)
> +{
> +    xendev->local_port = xc_evtchn_bind_unbound_port(xendev->evtchndev,
> +                                                     remote_dom);
> +    if (xendev->local_port == -1) {
> +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> +        return -1;
> +    }
> +    xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
> +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> +                        xen_be_evtchn_event, NULL, xendev);
> +    return 0;
> +}
> +
>  int xen_be_bind_evtchn(struct XenDevice *xendev)
>  {
>      if (xendev->local_port != -1) {
> @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice *xendev)
>      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
>  }
>  
> +int xen_vtpm_send(unsigned char *buf, size_t count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->send) {
> +        rc = xendev->ops->send(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}
> +
> +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->recv) {
> +        xendev->ops->recv(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}

xen_backend.c is supposed to be generic, so stubdom functions might be
OK but vtpm specific functions should not be here.


>  /*
>   * msg_level:
>   *  0 == errors (stderr + logfile).
> diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> new file mode 100644
> index 0000000..0d740c1
> --- /dev/null
> +++ b/hw/xen/xen_stubdom_vtpm.c
> @@ -0,0 +1,333 @@
> +/*
> + * Connect to Xen vTPM stubdom domain
> + *
> + *  Copyright (c) 2014 Intel Corporation
> + *  Authors:
> + *    Quan Xu <quan.xu@intel.com>
> + *
> + * 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 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, see <http://www.gnu.org/licenses/>
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <stdarg.h>
> +#include <string.h>
> +#include <unistd.h>
> +#include <signal.h>
> +#include <inttypes.h>
> +#include <time.h>
> +#include <fcntl.h>
> +#include <errno.h>
> +#include <sys/ioctl.h>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <sys/mman.h>
> +#include <sys/uio.h>
> +
> +#include "hw/hw.h"
> +#include "block/aio.h"
> +#include "hw/xen/xen_backend.h"
> +
> +enum tpmif_state {
> +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel complete */
> +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> +};
> +
> +static AioContext *vtpm_aio_ctx;
> +
> +enum status_bits {
> +    VTPM_STATUS_RUNNING  = 0x1,
> +    VTPM_STATUS_IDLE     = 0x2,
> +    VTPM_STATUS_RESULT   = 0x4,
> +    VTPM_STATUS_CANCELED = 0x8,
> +};
> +
> +struct tpmif_shared_page {
> +    uint32_t length;         /* request/response length in bytes */
> +
> +    uint8_t  state;           /* enum tpmif_state */
> +    uint8_t  locality;        /* for the current request */
> +    uint8_t  pad;             /* should be zero */
> +
> +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be zero */
> +    uint32_t extra_pages[0]; /* grant IDs; length is actually nr_extra_pages */
> +};
> +
> +struct QEMUBH {
> +    AioContext *ctx;
> +    QEMUBHFunc *cb;
> +    void *opaque;
> +    QEMUBH *next;
> +    bool scheduled;
> +    bool idle;
> +    bool deleted;
> +};
> +
> +struct XenVtpmDev {
> +    struct XenDevice xendev;  /* must be first */
> +    struct           tpmif_shared_page *shr;
> +    xc_gntshr        *xen_xcs;
> +    int              ring_ref;
> +    int              bedomid;
> +    QEMUBH           *sr_bh;
> +};
> +
> +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> +{
> +    switch (vtpmdev->shr->state) {
> +    case TPMIF_STATE_IDLE:
> +    case TPMIF_STATE_FINISH:
> +        return VTPM_STATUS_IDLE;
> +    case TPMIF_STATE_SUBMIT:
> +    case TPMIF_STATE_CANCEL:
> +        return VTPM_STATUS_RUNNING;
> +    default:
> +        return 0;
> +    }
> +}
> +
> +static int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)
> +{
> +    xs_transaction_t xbt = XBT_NULL;
> +
> +    if (xendev->fe_state == xbus) {
> +        return 0;
> +    }
> +
> +    xendev->fe_state = xbus;
> +
> +retry_transaction:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto retry_transaction;
> +        }
> +    }
> +
> +    return 0;
> +
> +abort_transaction:
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}
> +
> +static int vtpm_aio_wait(QEMUBH *qbh)
> +{
> +    return aio_poll(qbh->ctx, true);
> +}
> +
> +static void sr_bh_handler(void *opaque)
> +{
> +}
> +
> +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset;
> +
> +    if (shr->state == TPMIF_STATE_IDLE) {
> +        return -ECANCELED;
> +    }
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> +    *count = shr->length;
> +
> +    return 0;
> +}
> +
> +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    memcpy(offset + (uint8_t *)shr, buf, count);
> +    shr->length = count;
> +    barrier();
> +    shr->state = TPMIF_STATE_SUBMIT;
> +    xen_wmb();
> +    xen_be_send_notify(&vtpmdev->xendev);
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    return count;
> +}
> +
> +static int vtpm_initialise(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    xs_transaction_t xbt = XBT_NULL;
> +    unsigned int ring_ref;
> +
> +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev, "frontend");
> +    if (vtpmdev->xendev.fe == NULL) {
> +        return -1;
> +    }
> +
> +    /* Get backend domid */
> +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> +                             &vtpmdev->bedomid)) {
> +        return -1;
> +    }
> +
> +    /*alloc share page*/
> +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs, vtpmdev->bedomid, 1,
> +                                         &ring_ref, PROT_READ|PROT_WRITE);
> +    vtpmdev->ring_ref = ring_ref;
> +    if (vtpmdev->shr == NULL) {
> +        return -1;
> +    }
> +
> +    /*Create event channel */
> +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0, vtpmdev->bedomid)) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +        return -1;
> +    }
> +
> +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> +                     vtpmdev->xendev.local_port);
> +
> +again:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> +                           vtpmdev->ring_ref)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> +                           vtpmdev->xendev.local_port)) {
> +        goto abort_transaction;
> +    }
> +
> +    /* Publish protocol v2 feature */
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto again;
> +        }
> +    }
> +    /* Tell vtpm backend that we are ready */
> +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> +
> +    return 0;
> +
> +abort_transaction:
> +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}
> +
> +static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    int be_state;
> +
> +    if (strcmp(node, "state") == 0) {
> +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> +        switch (be_state) {
> +        case XenbusStateConnected:
> +            /*TODO*/
> +            break;
> +        case XenbusStateClosing:
> +        case XenbusStateClosed:
> +            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
> +            break;
> +        default:
> +            break;
> +        }
> +    }
> +}
> +
> +static int vtpm_free(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    QEMUBH *qbh = vtpmdev->sr_bh;
> +
> +    aio_poll(qbh->ctx, false);
> +    qemu_bh_delete(vtpmdev->sr_bh);
> +    if (vtpmdev->shr) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    }
> +    xc_interface_close(vtpmdev->xen_xcs);
> +    return 0;
> +}
> +
> +static void vtpm_alloc(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    vtpm_aio_ctx = aio_context_new(NULL);
> +    if (vtpm_aio_ctx == NULL) {
> +        return;
> +    }
> +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler, vtpmdev);
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> +}
> +
> +static void vtpm_event(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +}
> +
> +struct XenDevOps xen_vtpmdev_ops = {
> +    .size             = sizeof(struct XenVtpmDev),
> +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> +                        DEVOPS_FLAG_STUBDOM_BE,
> +    .event            = vtpm_event,
> +    .free             = vtpm_free,
> +    .alloc            = vtpm_alloc,
> +    .initialise       = vtpm_initialise,
> +    .backend_changed  = vtpm_backend_changed,
> +    .recv             = vtpm_recv,
> +    .send             = vtpm_send,
> +};

Is this the frontend, like the subject line would seem to imply?
If so, XenDevOps are made for backends, while this is a frontend. In
fact this is the first PV frontend in QEMU. We need to introduce
something generic and similar to struct XenDevOps and xen_backend.c but
for frontends.


> diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
> index 3b4125e..45fd6d3 100644
> --- a/include/hw/xen/xen_backend.h
> +++ b/include/hw/xen/xen_backend.h
> @@ -15,6 +15,8 @@ struct XenDevice;
>  #define DEVOPS_FLAG_NEED_GNTDEV   1
>  /* don't expect frontend doing correct state transitions (aka console quirk) */
>  #define DEVOPS_FLAG_IGNORE_STATE  2
> +/*dev backend is stubdom*/
> +#define DEVOPS_FLAG_STUBDOM_BE    4
>  
>  struct XenDevOps {
>      size_t    size;
> @@ -26,6 +28,8 @@ struct XenDevOps {
>      void      (*event)(struct XenDevice *xendev);
>      void      (*disconnect)(struct XenDevice *xendev);
>      int       (*free)(struct XenDevice *xendev);
> +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t count);
> +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t *count);
>      void      (*backend_changed)(struct XenDevice *xendev, const char *node);
>      void      (*frontend_changed)(struct XenDevice *xendev, const char *node);
>  };
> @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice *xendev);
>  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...)
>      GCC_FMT_ATTR(3, 4);
>  
> +/*Xen stubdom vtpm*/
> +int xen_vtpm_register(struct XenDevOps *ops);
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
> +int xen_vtpm_send(unsigned char *buf, size_t count);
> +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> +
>  /* actual backend drivers */
>  extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
>  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c */
>  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
>  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c        */
>  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c         */
> +extern struct XenDevOps xen_vtpmdev_ops;      /* xen_stubdom_vtpm.c*/
>  
>  void xen_init_display(int domid);
>  
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 95612a4..fb43084 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
>      return xc_interface_open(logger, dombuild_logger, open_flags);
>  }
>  
> +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> +                                           unsigned int open_flags)
> +{
> +    return xc_gntshr_open(logger, open_flags);
> +}
> +
>  /* FIXME There is now way to have the xen fd */
>  static inline int xc_fd(xc_interface *xen_xc)
>  {
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 21f1cbb..c99ace8 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>      int i, rc;
>      unsigned long ioreq_pfn;
>      unsigned long bufioreq_evtchn;
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    unsigned long stubdom_vtpm = 0;
> +#endif
> +
>      XenIOState *state;
>  
>      state = g_malloc0(sizeof (XenIOState));
> @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>          fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
>          return -1;
>      }
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> +    if (stubdom_vtpm) {
> +        xen_vtpm_register(&xen_vtpmdev_ops);
> +    }
> +#endif

Given that vtpm is just a PV frontend, can't you just detect whether is
present on xenstore and initialize it based on that? Like all the
backend below?


>      xen_be_register("console", &xen_console_ops);
>      xen_be_register("vkbd", &xen_kbdmouse_ops);
>      xen_be_register("qdisk", &xen_blkdev_ops);
> -- 
> 1.8.3.2
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:59:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGHf-0008Ac-CY; Mon, 03 Nov 2014 11:58:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlGHd-0008AX-Nh
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:58:53 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	68/A1-31453-CFD67545; Mon, 03 Nov 2014 11:58:52 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415015931!10903947!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14927 invoked from network); 3 Nov 2014 11:58:51 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 11:58:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 03:58:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,307,1413270000"; d="scan'208";a="615962206"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 03:58:48 -0800
Message-ID: <54576DF7.8060408@intel.com>
Date: Mon, 03 Nov 2014 19:58:47 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
In-Reply-To: <5457787002000078000445C7@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 19:43, Jan Beulich wrote:
>>>> On 03.11.14 at 12:32, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 17:51, Jan Beulich wrote:
>>>>>> On 03.11.14 at 10:40, <tiejun.chen@intel.com> wrote:
>>>> On 2014/11/3 16:56, Jan Beulich wrote:
>>>>>>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
>>>>>> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>>>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>>>>>>      From: Chen, Tiejun
>>>>>>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>>>>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>>>>>>> Thinking about this some more, this odd universal hole punching in
>>>>>>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>>>>>>> this really should be optional behavior, with pass through of devices
>>>>>>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>>>>>>> punching holes for _just_ the devices passed through to a guest
>>>>>>>>>> upon creation when the option is not enabled.)
>>>>>>>>>
>>>>>>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>>>>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>>>>>>> conflict with anything. So what about this idea?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>>>>>>> approach. When the parameter is on, RMRR check/hole punch is
>>>>>>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>>>>>>
>>>>>>>> If user configures device pass-through at creation time, this parameter
>>>>>>>> will be set by default. If user wants the VM capable of device hot-plug,
>>>>>>>> an explicit parameter can be added in the config file to enforce RMRR
>>>>>>>> check at creation time.
>>>>>>>
>>>>>>> Not exactly, I specifically described it slightly differently above. When
>>>>>>> devices get passed through and the option is absent, holes should be
>>>>>>> punched only for the RMRRs associated with those devices (i.e.
>>>>>>> ideally none). Of course this means we'll need a way to associate
>>>>>>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>>>>>>> XENMEM_reserved_device_memory_map alone won't suffice.
>>>>>>
>>>>>> Yeah, current hypercall just provide RMRR entries without that
>>>>>> associated BDF. And especially, in some cases one range may be shared by
>>>>>> multiple devices...
>>>>>
>>>>> Before we decide who's going to do an eventual change we need to
>>>>> determine what behavior we want, and whether this hypercall is
>>>>> really the right one. Quite possibly we'd need a per-domain view
>>>>> along with the global view, and hence rather than modifying this one
>>>>> we may need to introduce e.g. a new domctl.
>>>>>
>>>>
>>>> If we really need to work with a hypercall, maybe we can introduce a
>>>> little bit to construct that to callback with multiple entries like
>>>> this, for instance,
>>>>
>>>> RMRR entry0 have three devices, and entry1 have two devices,
>>>>
>>>> [start0, nr_pages0, bdf0],
>>>> [start0, nr_pages0, bdf1],
>>>> [start0, nr_pages0, bdf2],
>>>> [start1, nr_pages1, bdf3],
>>>> [start1, nr_pages1, bdf4],
>>>>
>>>> Although its cost more buffers, actually as you know this actual case is
>>>> really rare. So maybe this way can be feasible. Then we don't need
>>>> additional hypercall or xenstore.
>>>
>>> Conceptually, as a MEMOP, it has no business reporting BDFs. And
>>> then rather than returning the same address range more than once,
>>> having the caller supply a handle to an array and storing all of the
>>> SBDFs (or perhaps a single segment would suffice along with all the
>>> BDFs) there would seem to be an approach more consistent with
>>> what we do elsewhere.
>>
>> Here I'm wondering if we really need to expose BDFs to tools. Actually
>> tools just want to know those range no matter who owns these entries. I
>> mean we can do this in Xen.
>
> As pointed out before, in order for the tools to (a) avoid punching
> _all possible_ holes when not asked to but (b) punch holes for all
> devices assigned right at guest boot time, I don't think the tools
> can get away without having some way of identifying the _specific_
> reserved memory regions a guest needs. Whether this works via
> SBDF or some other means is tbd.
>
>> When we try to assign device as passthrough, Xen can get that bdf so Xen
>> can pre-check everything inside that hypercall, and Xen can return
>> something like this,
>>
>> #1 If this device has RMRR, we return that rmrr buffer. This is similar
>> with our current implementation.
>
> "That rmrr buffer" being which? Remember that there may be
> multiple devices associated with RMRRs and multiple devices
> assigned to a guest.

Maybe I don't describe what I want to do.

I know there are multiple device associated one RMRR, and multiple 
device can be assigned one guest.

Firstly we have a rule that we just allow all devices associated one 
RMRR to be assign same VM, right? So I mean while we create VM, we 
always call current hypercall but inside hypercall, Xen can know which 
devices will be assigned to this VM. So Xen still lookup that RMRR list 
but now Xen would check if these RMRR belongs to that device we want to 
assign this domain. If yes, we just let that callback go through these 
RMRR info from that list but exclude other unrelated RMRR. If not, we 
don't go through any RMRR info so that 'nr_entries' is also zero.

Thanks
Tiejun

>
>> #2 If not, we return 'nr_entries' as '0' to notify hvmloader it has
>> nothing to do.
>
> This (as vague as it is) hints in the same domain-specific reserved
> region determination that I was already hinting at.
>
> Jan
>
>

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 11:59:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 11:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGHf-0008Ac-CY; Mon, 03 Nov 2014 11:58:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlGHd-0008AX-Nh
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 11:58:53 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	68/A1-31453-CFD67545; Mon, 03 Nov 2014 11:58:52 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415015931!10903947!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14927 invoked from network); 3 Nov 2014 11:58:51 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 11:58:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 03:58:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,307,1413270000"; d="scan'208";a="615962206"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.128])
	([10.238.128.128])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 03:58:48 -0800
Message-ID: <54576DF7.8060408@intel.com>
Date: Mon, 03 Nov 2014 19:58:47 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
In-Reply-To: <5457787002000078000445C7@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 19:43, Jan Beulich wrote:
>>>> On 03.11.14 at 12:32, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 17:51, Jan Beulich wrote:
>>>>>> On 03.11.14 at 10:40, <tiejun.chen@intel.com> wrote:
>>>> On 2014/11/3 16:56, Jan Beulich wrote:
>>>>>>>> On 03.11.14 at 06:49, <tiejun.chen@intel.com> wrote:
>>>>>> On 2014/10/31 16:20, Jan Beulich wrote:
>>>>>>>>>> On 31.10.14 at 07:21, <kevin.tian@intel.com> wrote:
>>>>>>>>>      From: Chen, Tiejun
>>>>>>>>> Sent: Friday, October 31, 2014 1:41 PM
>>>>>>>>> On 2014/10/30 17:20, Jan Beulich wrote:
>>>>>>>>>> Thinking about this some more, this odd universal hole punching in
>>>>>>>>>> the E820 is very likely to end up causing problems. Hence I think
>>>>>>>>>> this really should be optional behavior, with pass through of devices
>>>>>>>>>> associated with RMRRs failing if not used. (This ought to include
>>>>>>>>>> punching holes for _just_ the devices passed through to a guest
>>>>>>>>>> upon creation when the option is not enabled.)
>>>>>>>>>
>>>>>>>>> Yeah, we had a similar discussion internal to add a parameter to force
>>>>>>>>> reserving RMRR. In this case we can't create a VM if these ranges
>>>>>>>>> conflict with anything. So what about this idea?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Adding a new parameter (e.g. 'check-passthrough') looks the right
>>>>>>>> approach. When the parameter is on, RMRR check/hole punch is
>>>>>>>> activated at VM creation. Otherwise we just keep existing behavior.
>>>>>>>>
>>>>>>>> If user configures device pass-through at creation time, this parameter
>>>>>>>> will be set by default. If user wants the VM capable of device hot-plug,
>>>>>>>> an explicit parameter can be added in the config file to enforce RMRR
>>>>>>>> check at creation time.
>>>>>>>
>>>>>>> Not exactly, I specifically described it slightly differently above. When
>>>>>>> devices get passed through and the option is absent, holes should be
>>>>>>> punched only for the RMRRs associated with those devices (i.e.
>>>>>>> ideally none). Of course this means we'll need a way to associate
>>>>>>> RMRRs with devices in the tool stack and hvmloader, i.e. the current
>>>>>>> XENMEM_reserved_device_memory_map alone won't suffice.
>>>>>>
>>>>>> Yeah, current hypercall just provide RMRR entries without that
>>>>>> associated BDF. And especially, in some cases one range may be shared by
>>>>>> multiple devices...
>>>>>
>>>>> Before we decide who's going to do an eventual change we need to
>>>>> determine what behavior we want, and whether this hypercall is
>>>>> really the right one. Quite possibly we'd need a per-domain view
>>>>> along with the global view, and hence rather than modifying this one
>>>>> we may need to introduce e.g. a new domctl.
>>>>>
>>>>
>>>> If we really need to work with a hypercall, maybe we can introduce a
>>>> little bit to construct that to callback with multiple entries like
>>>> this, for instance,
>>>>
>>>> RMRR entry0 have three devices, and entry1 have two devices,
>>>>
>>>> [start0, nr_pages0, bdf0],
>>>> [start0, nr_pages0, bdf1],
>>>> [start0, nr_pages0, bdf2],
>>>> [start1, nr_pages1, bdf3],
>>>> [start1, nr_pages1, bdf4],
>>>>
>>>> Although its cost more buffers, actually as you know this actual case is
>>>> really rare. So maybe this way can be feasible. Then we don't need
>>>> additional hypercall or xenstore.
>>>
>>> Conceptually, as a MEMOP, it has no business reporting BDFs. And
>>> then rather than returning the same address range more than once,
>>> having the caller supply a handle to an array and storing all of the
>>> SBDFs (or perhaps a single segment would suffice along with all the
>>> BDFs) there would seem to be an approach more consistent with
>>> what we do elsewhere.
>>
>> Here I'm wondering if we really need to expose BDFs to tools. Actually
>> tools just want to know those range no matter who owns these entries. I
>> mean we can do this in Xen.
>
> As pointed out before, in order for the tools to (a) avoid punching
> _all possible_ holes when not asked to but (b) punch holes for all
> devices assigned right at guest boot time, I don't think the tools
> can get away without having some way of identifying the _specific_
> reserved memory regions a guest needs. Whether this works via
> SBDF or some other means is tbd.
>
>> When we try to assign device as passthrough, Xen can get that bdf so Xen
>> can pre-check everything inside that hypercall, and Xen can return
>> something like this,
>>
>> #1 If this device has RMRR, we return that rmrr buffer. This is similar
>> with our current implementation.
>
> "That rmrr buffer" being which? Remember that there may be
> multiple devices associated with RMRRs and multiple devices
> assigned to a guest.

Maybe I don't describe what I want to do.

I know there are multiple device associated one RMRR, and multiple 
device can be assigned one guest.

Firstly we have a rule that we just allow all devices associated one 
RMRR to be assign same VM, right? So I mean while we create VM, we 
always call current hypercall but inside hypercall, Xen can know which 
devices will be assigned to this VM. So Xen still lookup that RMRR list 
but now Xen would check if these RMRR belongs to that device we want to 
assign this domain. If yes, we just let that callback go through these 
RMRR info from that list but exclude other unrelated RMRR. If not, we 
don't go through any RMRR info so that 'nr_entries' is also zero.

Thanks
Tiejun

>
>> #2 If not, we return 'nr_entries' as '0' to notify hvmloader it has
>> nothing to do.
>
> This (as vague as it is) hints in the same domain-specific reserved
> region determination that I was already hinting at.
>
> Jan
>
>

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:01:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:01:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGJq-0008NA-Jy; Mon, 03 Nov 2014 12:01:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1XlGJq-0008N2-0P
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 12:01:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1C/03-09936-58E67545; Mon, 03 Nov 2014 12:01:09 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415016068!12353351!1
X-Originating-IP: [209.85.215.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4879 invoked from network); 3 Nov 2014 12:01:08 -0000
Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com)
	(209.85.215.49)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 12:01:08 -0000
Received: by mail-la0-f49.google.com with SMTP id ge10so9037191lab.8
	for <xen-devel@lists.xensource.com>;
	Mon, 03 Nov 2014 04:01:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=vacX5sJFwwpXVJ5FWKFT+DL5xQazaZswyt6yuxL6YCI=;
	b=VdNxMgkI30amvpADmVbhAnpsWsJtDabyEPcjlggwF+h3S4TNo+kBDJnQ8XEBm1Ykkx
	JqV1d20W+xmp9FwASzv5Uil/uo2HSuUKQPfxqr+XJC4m2q1bVklqGgtNPLyx+W8pdzJA
	4Do+Hpo2Pp9KVNf6uW6GVE2cIzsbzKWncQnm3b5UALp8GrSV0QFSAM+DQUql9M5Ztu5C
	Kge82g1cFs/ibY9atPNus0ImM3ymzULrIfrpL2zZ7ncm+IO3AEW9tQJPTFbhi/G1SPw6
	VTzYG+H1ozUzVRBoB/RG6+qXnQfJsrb9Gb35TKrlvd+QPiiNy5AT4eCMEDgXa4HmMGtn
	xdKQ==
X-Received: by 10.152.3.168 with SMTP id d8mr50458839lad.34.1415016068138;
	Mon, 03 Nov 2014 04:01:08 -0800 (PST)
Received: from [192.168.10.150] (net-37-117-142-149.cust.vodafonedsl.it.
	[37.117.142.149])
	by mx.google.com with ESMTPSA id rb2sm7861368lbb.17.2014.11.03.04.01.05
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 04:01:06 -0800 (PST)
Message-ID: <54576E7F.3000901@redhat.com>
Date: Mon, 03 Nov 2014 13:01:03 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.qemu,gmane.comp.emulators.xen.devel
To: "Chen, Tiejun" <tiejun.chen@intel.com>, 
	"Michael S. Tsirkin" <mst@redhat.com>
References: <20140901060506.GA20186@redhat.com>	<54042514.6090206@intel.com>	<003AAFE53969E14CB1F09B6FD68C3CD478F16D2A@ORSMSX101.amr.corp.intel.com>	<54277979.7070408@intel.com>	<20140929100111.GA32459@redhat.com>	<542A18BD.2060008@intel.com>	<20141007072653.GB2424@redhat.com>	<543622CC.6050807@intel.com>	<20141012095021.GC9567@redhat.com>	<544A0174.7000003@intel.com>	<20141024134747.GA6024@redhat.com>	<5451ED1E.1000300@intel.com>	<5457335B.1000308@intel.com>	<5457686E.7020601@redhat.com>	<545768CC.3000903@intel.com>
	<54576B5A.50005@intel.com>
In-Reply-To: <54576B5A.50005@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create isa bridge
 specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 03/11/2014 12:47, Chen, Tiejun wrote:
> On 2014/11/3 19:36, Chen, Tiejun wrote:
>> On 2014/11/3 19:35, Paolo Bonzini wrote:
>>> On 03/11/2014 08:48, Chen, Tiejun wrote:
>>>>>>>> I think the point was mostly to reserve 1f to prevent
>>>>>>>> devices from using it.
>>>>>>>> As we populate slots in order it doesn't seem to important ...
>>>>>>>
>>>>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>>>>>
>>>>>> Right, but I mean if no special options are used, 1f will typically
>>>>>> stay free without any effort on our side.
>>>>>
>>>>> Yeah.
>>>>>
>>>>> Actually based on current info we know, seems 1f is just specific to
>>>>> our
>>>>> scenario :) So I always think we can occupy that. But Paolo and you
>>>>> can
>>>>> really determine this point.
>>>>
>>>> What's your idea?
>>>
>>> I do not have any objection to always occupying 1f for Xen IGD
>>> passthrough.
> 
> After I go back to look at this again, I hope you don't misunderstand
> what Michael mean now. He was saying we don't need to create a new
> separate machine specific to IGD passthrough. But that idea is just from
> you :)

It's difficult for me to follow, because xen_igd_passthrough_pc_hvm_init
does not exist in the current tree.

The patches seem good to me; I was assuming that the new machine type
would call xen_igd_passthrough_pc_hvm_init, but apparently I'm wrong?
Paolo

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:01:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:01:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGJq-0008NA-Jy; Mon, 03 Nov 2014 12:01:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1XlGJq-0008N2-0P
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 12:01:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1C/03-09936-58E67545; Mon, 03 Nov 2014 12:01:09 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415016068!12353351!1
X-Originating-IP: [209.85.215.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4879 invoked from network); 3 Nov 2014 12:01:08 -0000
Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com)
	(209.85.215.49)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 12:01:08 -0000
Received: by mail-la0-f49.google.com with SMTP id ge10so9037191lab.8
	for <xen-devel@lists.xensource.com>;
	Mon, 03 Nov 2014 04:01:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=vacX5sJFwwpXVJ5FWKFT+DL5xQazaZswyt6yuxL6YCI=;
	b=VdNxMgkI30amvpADmVbhAnpsWsJtDabyEPcjlggwF+h3S4TNo+kBDJnQ8XEBm1Ykkx
	JqV1d20W+xmp9FwASzv5Uil/uo2HSuUKQPfxqr+XJC4m2q1bVklqGgtNPLyx+W8pdzJA
	4Do+Hpo2Pp9KVNf6uW6GVE2cIzsbzKWncQnm3b5UALp8GrSV0QFSAM+DQUql9M5Ztu5C
	Kge82g1cFs/ibY9atPNus0ImM3ymzULrIfrpL2zZ7ncm+IO3AEW9tQJPTFbhi/G1SPw6
	VTzYG+H1ozUzVRBoB/RG6+qXnQfJsrb9Gb35TKrlvd+QPiiNy5AT4eCMEDgXa4HmMGtn
	xdKQ==
X-Received: by 10.152.3.168 with SMTP id d8mr50458839lad.34.1415016068138;
	Mon, 03 Nov 2014 04:01:08 -0800 (PST)
Received: from [192.168.10.150] (net-37-117-142-149.cust.vodafonedsl.it.
	[37.117.142.149])
	by mx.google.com with ESMTPSA id rb2sm7861368lbb.17.2014.11.03.04.01.05
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 04:01:06 -0800 (PST)
Message-ID: <54576E7F.3000901@redhat.com>
Date: Mon, 03 Nov 2014 13:01:03 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.qemu,gmane.comp.emulators.xen.devel
To: "Chen, Tiejun" <tiejun.chen@intel.com>, 
	"Michael S. Tsirkin" <mst@redhat.com>
References: <20140901060506.GA20186@redhat.com>	<54042514.6090206@intel.com>	<003AAFE53969E14CB1F09B6FD68C3CD478F16D2A@ORSMSX101.amr.corp.intel.com>	<54277979.7070408@intel.com>	<20140929100111.GA32459@redhat.com>	<542A18BD.2060008@intel.com>	<20141007072653.GB2424@redhat.com>	<543622CC.6050807@intel.com>	<20141012095021.GC9567@redhat.com>	<544A0174.7000003@intel.com>	<20141024134747.GA6024@redhat.com>	<5451ED1E.1000300@intel.com>	<5457335B.1000308@intel.com>	<5457686E.7020601@redhat.com>	<545768CC.3000903@intel.com>
	<54576B5A.50005@intel.com>
In-Reply-To: <54576B5A.50005@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create isa bridge
 specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 03/11/2014 12:47, Chen, Tiejun wrote:
> On 2014/11/3 19:36, Chen, Tiejun wrote:
>> On 2014/11/3 19:35, Paolo Bonzini wrote:
>>> On 03/11/2014 08:48, Chen, Tiejun wrote:
>>>>>>>> I think the point was mostly to reserve 1f to prevent
>>>>>>>> devices from using it.
>>>>>>>> As we populate slots in order it doesn't seem to important ...
>>>>>>>
>>>>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>>>>>
>>>>>> Right, but I mean if no special options are used, 1f will typically
>>>>>> stay free without any effort on our side.
>>>>>
>>>>> Yeah.
>>>>>
>>>>> Actually based on current info we know, seems 1f is just specific to
>>>>> our
>>>>> scenario :) So I always think we can occupy that. But Paolo and you
>>>>> can
>>>>> really determine this point.
>>>>
>>>> What's your idea?
>>>
>>> I do not have any objection to always occupying 1f for Xen IGD
>>> passthrough.
> 
> After I go back to look at this again, I hope you don't misunderstand
> what Michael mean now. He was saying we don't need to create a new
> separate machine specific to IGD passthrough. But that idea is just from
> you :)

It's difficult for me to follow, because xen_igd_passthrough_pc_hvm_init
does not exist in the current tree.

The patches seem good to me; I was assuming that the new machine type
would call xen_igd_passthrough_pc_hvm_init, but apparently I'm wrong?
Paolo

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:13:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGVM-0000PC-42; Mon, 03 Nov 2014 12:13:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1XlGVK-0000P1-Ur
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 12:13:03 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	87/5D-02559-E4177545; Mon, 03 Nov 2014 12:13:02 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415016777!12204878!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21429 invoked from network); 3 Nov 2014 12:13:00 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 12:13:00 -0000
Received: by mail-lb0-f171.google.com with SMTP id b6so1151190lbj.2
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 04:12:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=dj6pRKfzq61qNpkip1tg5xM897D/kMnSKX89q9wZWFQ=;
	b=b4zDa9aAXqjTNY+56eVJEwPWHvN1ttZvA2+b8tKNOQetaAodCPSvby3tDz9QxOSbqT
	GmPx+vPDRCmmMpKCZEaxfY2ZDRs87ku2+EVk3K/n/8/VMQgc1FNkRG/oHTkq3eJQAtUw
	JvPNu9Bk21O39UJdDKFqGEpqV/eHZ6Bt+CezpyNY3TBRf7hKwvCl0M+irl1xEksXn7Gn
	Fj4Or1pUa7wCFT44fcwatFZ0PR8chXtr00clpmJWb7k0axDBR6jKwjs2ULLo0jv8Lz1X
	F1HBCsx6Lj6uWJAuNt6ZFeHGFYUOoJxHBTkqnt8py4pwRhls4Abvr7de0YmHpOX7Z5Xb
	Lwow==
X-Received: by 10.152.18.166 with SMTP id x6mr49442406lad.18.1415016777181;
	Mon, 03 Nov 2014 04:12:57 -0800 (PST)
Received: from [192.168.10.150] (net-37-117-142-149.cust.vodafonedsl.it.
	[37.117.142.149])
	by mx.google.com with ESMTPSA id kl8sm7879484lac.49.2014.11.03.04.12.54
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 04:12:56 -0800 (PST)
Message-ID: <54577143.7040909@redhat.com>
Date: Mon, 03 Nov 2014 13:12:51 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.qemu
To: Quan Xu <quan.xu@intel.com>, qemu-devel@nongnu.org
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
Cc: xen-devel@lists.xen.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 02/11/2014 07:39, Quan Xu wrote:
> This drvier transfers any request/repond between TPM xenstubdoms
> driver and Xen vTPM stubdom, and facilitates communications between
> Xen vTPM stubdom domain and vTPM xenstubdoms driver
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  hw/xen/Makefile.objs         |   1 +
>  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
>  hw/xen/xen_stubdom_vtpm.c    | 333 +++++++++++++++++++++++++++++++++++++++++++
>  include/hw/xen/xen_backend.h |  11 ++
>  include/hw/xen/xen_common.h  |   6 +
>  xen-hvm.c                    |  13 ++
>  6 files changed, 544 insertions(+), 2 deletions(-)
>  create mode 100644 hw/xen/xen_stubdom_vtpm.c
> 
> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> index a0ca0aa..724df8d 100644
> --- a/hw/xen/Makefile.objs
> +++ b/hw/xen/Makefile.objs
> @@ -1,5 +1,6 @@
>  # xen backend driver support
>  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
> +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
>  
>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index b2cb22b..45a5778 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state)
>      return 0;
>  }
>  
> +/*get stubdom backend*/
> +static char *xen_stubdom_be(const char *type, int dom, int dev)
> +{
> +    char *val, *domu;
> +    char path[XEN_BUFSIZE];
> +    unsigned int len, ival;
> +
> +    /*front domu*/
> +    domu = xs_get_domain_path(xenstore, dom);
> +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> +             domu, type, dev);
> +    g_free(domu);
> +
> +    val = xs_read(xenstore, 0, path, &len);
> +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> +        g_free(val);
> +        return NULL;
> +    }
> +    g_free(val);
> +
> +    /*backend domu*/
> +    domu = xs_get_domain_path(xenstore, ival);
> +
> +    return domu;
> +}
> +
>  /* ------------------------------------------------------------- */
>  
>  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
> @@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
>                                             struct XenDevOps *ops)
>  {
>      struct XenDevice *xendev;
> +    char *stub;
>  
>      xendev = xen_be_find_xendev(type, dom, dev);
>      if (xendev) {
> @@ -235,8 +262,15 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
>      xendev->dev   = dev;
>      xendev->ops   = ops;
>  
> -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> -             xendev->type, xendev->dom, xendev->dev);
> +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> +        stub = xen_stubdom_be(xendev->type, xendev->dom, xendev->dev);
> +        snprintf(xendev->be, sizeof(xendev->be), "%s/backend/%s/%d/%d",
> +                 stub, xendev->type, xendev->dom, xendev->dev);
> +        g_free(stub);
> +    } else {
> +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> +                 xendev->type, xendev->dom, xendev->dev);
> +    }
>      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
>               xendev->type, xendev->dev);
>  
> @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int dom, struct XenDevOps *ops)
>      return 0;
>  }
>  
> +static void stubdom_update_be(char *watch, char *type, int dom,
> +                              struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE];
> +    char *ptr, *bepath;
> +    unsigned int len, dev;
> +
> +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> +        return;
> +    }
> +
> +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> +    ptr = strstr(watch, path);
> +    if (ptr == NULL) {
> +        return;
> +    }
> +
> +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> +        strcpy(path, "");
> +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> +            dev = -1;
> +        }
> +    }
> +
> +    if (dev == -1) {
> +        return;
> +    }
> +
> +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> +    if (xendev != NULL) {
> +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> +        if (bepath == NULL) {
> +            xen_be_del_xendev(dom, dev);
> +        } else {
> +            free(bepath);
> +            xen_be_backend_changed(xendev, path);
> +        }
> +    }
> +}
> +
>  static void xenstore_update_be(char *watch, char *type, int dom,
>                                 struct XenDevOps *ops)
>  {
> @@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
>      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
>          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
>      }
> +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%" PRIxPTR,
> +               &type, &dom, &ops) == 3) {
> +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
> +    }
>  
>  cleanup:
>      free(vec);
> @@ -732,11 +811,74 @@ err:
>      return -1;
>  }
>  
> +int xen_vtpm_register(struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> +    char *domu;
> +    unsigned int cdev, j, rc;
> +    const char *type = "vtpm";
> +    char **dev = NULL;
> +
> +    /*front domu*/
> +    domu = xs_get_domain_path(xenstore, xen_domid);
> +    snprintf(path, sizeof(path), "%s/device/%s",
> +             domu, type);
> +    free(domu);
> +    dev = xs_directory(xenstore, 0, path, &cdev);
> +    if (dev == NULL) {
> +        return 0;
> +    }
> +
> +    for (j = 0; j < cdev; j++) {
> +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]), ops);
> +        if (xendev == NULL) {
> +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is NULL.\n");
> +            continue;
> +        }
> +
> +        if (xendev->ops->initialise) {
> +            rc = xendev->ops->initialise(xendev);
> +
> +            /*if initialise failed, delete it*/
> +            if (rc != 0) {
> +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> +                continue;
> +            }
> +        }
> +
> +        /*setup watch*/
> +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> +                 type, xen_domid, xendev->ops);
> +        if (!xs_watch(xenstore, xendev->be, token)) {
> +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch failed.\n");
> +            return -1;
> +        }
> +    }
> +
> +    free(dev);
> +    return 0;
> +}
> +
>  int xen_be_register(const char *type, struct XenDevOps *ops)
>  {
>      return xenstore_scan(type, xen_domid, ops);
>  }
>  
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom)
> +{
> +    xendev->local_port = xc_evtchn_bind_unbound_port(xendev->evtchndev,
> +                                                     remote_dom);
> +    if (xendev->local_port == -1) {
> +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> +        return -1;
> +    }
> +    xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
> +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> +                        xen_be_evtchn_event, NULL, xendev);
> +    return 0;
> +}
> +
>  int xen_be_bind_evtchn(struct XenDevice *xendev)
>  {
>      if (xendev->local_port != -1) {
> @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice *xendev)
>      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
>  }
>  
> +int xen_vtpm_send(unsigned char *buf, size_t count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->send) {
> +        rc = xendev->ops->send(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}
> +
> +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->recv) {
> +        xendev->ops->recv(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}
> +
>  /*
>   * msg_level:
>   *  0 == errors (stderr + logfile).
> diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> new file mode 100644
> index 0000000..0d740c1
> --- /dev/null
> +++ b/hw/xen/xen_stubdom_vtpm.c
> @@ -0,0 +1,333 @@
> +/*
> + * Connect to Xen vTPM stubdom domain
> + *
> + *  Copyright (c) 2014 Intel Corporation
> + *  Authors:
> + *    Quan Xu <quan.xu@intel.com>
> + *
> + * 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 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, see <http://www.gnu.org/licenses/>
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <stdarg.h>
> +#include <string.h>
> +#include <unistd.h>
> +#include <signal.h>
> +#include <inttypes.h>
> +#include <time.h>
> +#include <fcntl.h>
> +#include <errno.h>
> +#include <sys/ioctl.h>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <sys/mman.h>
> +#include <sys/uio.h>
> +
> +#include "hw/hw.h"
> +#include "block/aio.h"
> +#include "hw/xen/xen_backend.h"
> +
> +enum tpmif_state {
> +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel complete */
> +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> +};
> +
> +static AioContext *vtpm_aio_ctx;
> +
> +enum status_bits {
> +    VTPM_STATUS_RUNNING  = 0x1,
> +    VTPM_STATUS_IDLE     = 0x2,
> +    VTPM_STATUS_RESULT   = 0x4,
> +    VTPM_STATUS_CANCELED = 0x8,
> +};
> +
> +struct tpmif_shared_page {
> +    uint32_t length;         /* request/response length in bytes */
> +
> +    uint8_t  state;           /* enum tpmif_state */
> +    uint8_t  locality;        /* for the current request */
> +    uint8_t  pad;             /* should be zero */
> +
> +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be zero */
> +    uint32_t extra_pages[0]; /* grant IDs; length is actually nr_extra_pages */
> +};
> +
> +struct QEMUBH {
> +    AioContext *ctx;
> +    QEMUBHFunc *cb;
> +    void *opaque;
> +    QEMUBH *next;
> +    bool scheduled;
> +    bool idle;
> +    bool deleted;
> +};

This is a private structure, you cannot just copy the definition here.

You do not even need it in fact, since sr_bh->ctx is always vtpm_aio_ctx.

Paolo


> +struct XenVtpmDev {
> +    struct XenDevice xendev;  /* must be first */
> +    struct           tpmif_shared_page *shr;
> +    xc_gntshr        *xen_xcs;
> +    int              ring_ref;
> +    int              bedomid;
> +    QEMUBH           *sr_bh;
> +};
> +
> +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> +{
> +    switch (vtpmdev->shr->state) {
> +    case TPMIF_STATE_IDLE:
> +    case TPMIF_STATE_FINISH:
> +        return VTPM_STATUS_IDLE;
> +    case TPMIF_STATE_SUBMIT:
> +    case TPMIF_STATE_CANCEL:
> +        return VTPM_STATUS_RUNNING;
> +    default:
> +        return 0;
> +    }
> +}
> +
> +static int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)
> +{
> +    xs_transaction_t xbt = XBT_NULL;
> +
> +    if (xendev->fe_state == xbus) {
> +        return 0;
> +    }
> +
> +    xendev->fe_state = xbus;
> +
> +retry_transaction:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto retry_transaction;
> +        }
> +    }
> +
> +    return 0;
> +
> +abort_transaction:
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}
> +
> +static int vtpm_aio_wait(QEMUBH *qbh)
> +{
> +    return aio_poll(qbh->ctx, true);
> +}
> +
> +static void sr_bh_handler(void *opaque)
> +{
> +}
> +
> +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset;
> +
> +    if (shr->state == TPMIF_STATE_IDLE) {
> +        return -ECANCELED;
> +    }
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> +    *count = shr->length;
> +
> +    return 0;
> +}
> +
> +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    memcpy(offset + (uint8_t *)shr, buf, count);
> +    shr->length = count;
> +    barrier();
> +    shr->state = TPMIF_STATE_SUBMIT;
> +    xen_wmb();
> +    xen_be_send_notify(&vtpmdev->xendev);
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    return count;
> +}
> +
> +static int vtpm_initialise(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    xs_transaction_t xbt = XBT_NULL;
> +    unsigned int ring_ref;
> +
> +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev, "frontend");
> +    if (vtpmdev->xendev.fe == NULL) {
> +        return -1;
> +    }
> +
> +    /* Get backend domid */
> +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> +                             &vtpmdev->bedomid)) {
> +        return -1;
> +    }
> +
> +    /*alloc share page*/
> +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs, vtpmdev->bedomid, 1,
> +                                         &ring_ref, PROT_READ|PROT_WRITE);
> +    vtpmdev->ring_ref = ring_ref;
> +    if (vtpmdev->shr == NULL) {
> +        return -1;
> +    }
> +
> +    /*Create event channel */
> +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0, vtpmdev->bedomid)) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +        return -1;
> +    }
> +
> +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> +                     vtpmdev->xendev.local_port);
> +
> +again:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> +                           vtpmdev->ring_ref)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> +                           vtpmdev->xendev.local_port)) {
> +        goto abort_transaction;
> +    }
> +
> +    /* Publish protocol v2 feature */
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto again;
> +        }
> +    }
> +    /* Tell vtpm backend that we are ready */
> +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> +
> +    return 0;
> +
> +abort_transaction:
> +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}
> +
> +static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    int be_state;
> +
> +    if (strcmp(node, "state") == 0) {
> +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> +        switch (be_state) {
> +        case XenbusStateConnected:
> +            /*TODO*/
> +            break;
> +        case XenbusStateClosing:
> +        case XenbusStateClosed:
> +            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
> +            break;
> +        default:
> +            break;
> +        }
> +    }
> +}
> +
> +static int vtpm_free(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    QEMUBH *qbh = vtpmdev->sr_bh;
> +
> +    aio_poll(qbh->ctx, false);
> +    qemu_bh_delete(vtpmdev->sr_bh);
> +    if (vtpmdev->shr) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    }
> +    xc_interface_close(vtpmdev->xen_xcs);
> +    return 0;
> +}
> +
> +static void vtpm_alloc(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    vtpm_aio_ctx = aio_context_new(NULL);
> +    if (vtpm_aio_ctx == NULL) {
> +        return;
> +    }
> +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler, vtpmdev);
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> +}
> +
> +static void vtpm_event(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +}
> +
> +struct XenDevOps xen_vtpmdev_ops = {
> +    .size             = sizeof(struct XenVtpmDev),
> +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> +                        DEVOPS_FLAG_STUBDOM_BE,
> +    .event            = vtpm_event,
> +    .free             = vtpm_free,
> +    .alloc            = vtpm_alloc,
> +    .initialise       = vtpm_initialise,
> +    .backend_changed  = vtpm_backend_changed,
> +    .recv             = vtpm_recv,
> +    .send             = vtpm_send,
> +};
> diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
> index 3b4125e..45fd6d3 100644
> --- a/include/hw/xen/xen_backend.h
> +++ b/include/hw/xen/xen_backend.h
> @@ -15,6 +15,8 @@ struct XenDevice;
>  #define DEVOPS_FLAG_NEED_GNTDEV   1
>  /* don't expect frontend doing correct state transitions (aka console quirk) */
>  #define DEVOPS_FLAG_IGNORE_STATE  2
> +/*dev backend is stubdom*/
> +#define DEVOPS_FLAG_STUBDOM_BE    4
>  
>  struct XenDevOps {
>      size_t    size;
> @@ -26,6 +28,8 @@ struct XenDevOps {
>      void      (*event)(struct XenDevice *xendev);
>      void      (*disconnect)(struct XenDevice *xendev);
>      int       (*free)(struct XenDevice *xendev);
> +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t count);
> +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t *count);
>      void      (*backend_changed)(struct XenDevice *xendev, const char *node);
>      void      (*frontend_changed)(struct XenDevice *xendev, const char *node);
>  };
> @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice *xendev);
>  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...)
>      GCC_FMT_ATTR(3, 4);
>  
> +/*Xen stubdom vtpm*/
> +int xen_vtpm_register(struct XenDevOps *ops);
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
> +int xen_vtpm_send(unsigned char *buf, size_t count);
> +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> +
>  /* actual backend drivers */
>  extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
>  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c */
>  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
>  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c        */
>  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c         */
> +extern struct XenDevOps xen_vtpmdev_ops;      /* xen_stubdom_vtpm.c*/
>  
>  void xen_init_display(int domid);
>  
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 95612a4..fb43084 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
>      return xc_interface_open(logger, dombuild_logger, open_flags);
>  }
>  
> +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> +                                           unsigned int open_flags)
> +{
> +    return xc_gntshr_open(logger, open_flags);
> +}
> +
>  /* FIXME There is now way to have the xen fd */
>  static inline int xc_fd(xc_interface *xen_xc)
>  {
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 21f1cbb..c99ace8 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>      int i, rc;
>      unsigned long ioreq_pfn;
>      unsigned long bufioreq_evtchn;
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    unsigned long stubdom_vtpm = 0;
> +#endif
> +
>      XenIOState *state;
>  
>      state = g_malloc0(sizeof (XenIOState));
> @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>          fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
>          return -1;
>      }
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> +    if (stubdom_vtpm) {
> +        xen_vtpm_register(&xen_vtpmdev_ops);
> +    }
> +#endif
> +
>      xen_be_register("console", &xen_console_ops);
>      xen_be_register("vkbd", &xen_kbdmouse_ops);
>      xen_be_register("qdisk", &xen_blkdev_ops);
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:13:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGVM-0000PC-42; Mon, 03 Nov 2014 12:13:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1XlGVK-0000P1-Ur
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 12:13:03 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	87/5D-02559-E4177545; Mon, 03 Nov 2014 12:13:02 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415016777!12204878!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21429 invoked from network); 3 Nov 2014 12:13:00 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 12:13:00 -0000
Received: by mail-lb0-f171.google.com with SMTP id b6so1151190lbj.2
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 04:12:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=dj6pRKfzq61qNpkip1tg5xM897D/kMnSKX89q9wZWFQ=;
	b=b4zDa9aAXqjTNY+56eVJEwPWHvN1ttZvA2+b8tKNOQetaAodCPSvby3tDz9QxOSbqT
	GmPx+vPDRCmmMpKCZEaxfY2ZDRs87ku2+EVk3K/n/8/VMQgc1FNkRG/oHTkq3eJQAtUw
	JvPNu9Bk21O39UJdDKFqGEpqV/eHZ6Bt+CezpyNY3TBRf7hKwvCl0M+irl1xEksXn7Gn
	Fj4Or1pUa7wCFT44fcwatFZ0PR8chXtr00clpmJWb7k0axDBR6jKwjs2ULLo0jv8Lz1X
	F1HBCsx6Lj6uWJAuNt6ZFeHGFYUOoJxHBTkqnt8py4pwRhls4Abvr7de0YmHpOX7Z5Xb
	Lwow==
X-Received: by 10.152.18.166 with SMTP id x6mr49442406lad.18.1415016777181;
	Mon, 03 Nov 2014 04:12:57 -0800 (PST)
Received: from [192.168.10.150] (net-37-117-142-149.cust.vodafonedsl.it.
	[37.117.142.149])
	by mx.google.com with ESMTPSA id kl8sm7879484lac.49.2014.11.03.04.12.54
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 04:12:56 -0800 (PST)
Message-ID: <54577143.7040909@redhat.com>
Date: Mon, 03 Nov 2014 13:12:51 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.qemu
To: Quan Xu <quan.xu@intel.com>, qemu-devel@nongnu.org
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
Cc: xen-devel@lists.xen.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 02/11/2014 07:39, Quan Xu wrote:
> This drvier transfers any request/repond between TPM xenstubdoms
> driver and Xen vTPM stubdom, and facilitates communications between
> Xen vTPM stubdom domain and vTPM xenstubdoms driver
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  hw/xen/Makefile.objs         |   1 +
>  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
>  hw/xen/xen_stubdom_vtpm.c    | 333 +++++++++++++++++++++++++++++++++++++++++++
>  include/hw/xen/xen_backend.h |  11 ++
>  include/hw/xen/xen_common.h  |   6 +
>  xen-hvm.c                    |  13 ++
>  6 files changed, 544 insertions(+), 2 deletions(-)
>  create mode 100644 hw/xen/xen_stubdom_vtpm.c
> 
> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> index a0ca0aa..724df8d 100644
> --- a/hw/xen/Makefile.objs
> +++ b/hw/xen/Makefile.objs
> @@ -1,5 +1,6 @@
>  # xen backend driver support
>  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
> +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
>  
>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index b2cb22b..45a5778 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state)
>      return 0;
>  }
>  
> +/*get stubdom backend*/
> +static char *xen_stubdom_be(const char *type, int dom, int dev)
> +{
> +    char *val, *domu;
> +    char path[XEN_BUFSIZE];
> +    unsigned int len, ival;
> +
> +    /*front domu*/
> +    domu = xs_get_domain_path(xenstore, dom);
> +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> +             domu, type, dev);
> +    g_free(domu);
> +
> +    val = xs_read(xenstore, 0, path, &len);
> +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> +        g_free(val);
> +        return NULL;
> +    }
> +    g_free(val);
> +
> +    /*backend domu*/
> +    domu = xs_get_domain_path(xenstore, ival);
> +
> +    return domu;
> +}
> +
>  /* ------------------------------------------------------------- */
>  
>  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
> @@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
>                                             struct XenDevOps *ops)
>  {
>      struct XenDevice *xendev;
> +    char *stub;
>  
>      xendev = xen_be_find_xendev(type, dom, dev);
>      if (xendev) {
> @@ -235,8 +262,15 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
>      xendev->dev   = dev;
>      xendev->ops   = ops;
>  
> -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> -             xendev->type, xendev->dom, xendev->dev);
> +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> +        stub = xen_stubdom_be(xendev->type, xendev->dom, xendev->dev);
> +        snprintf(xendev->be, sizeof(xendev->be), "%s/backend/%s/%d/%d",
> +                 stub, xendev->type, xendev->dom, xendev->dev);
> +        g_free(stub);
> +    } else {
> +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> +                 xendev->type, xendev->dom, xendev->dev);
> +    }
>      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
>               xendev->type, xendev->dev);
>  
> @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int dom, struct XenDevOps *ops)
>      return 0;
>  }
>  
> +static void stubdom_update_be(char *watch, char *type, int dom,
> +                              struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE];
> +    char *ptr, *bepath;
> +    unsigned int len, dev;
> +
> +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> +        return;
> +    }
> +
> +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> +    ptr = strstr(watch, path);
> +    if (ptr == NULL) {
> +        return;
> +    }
> +
> +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> +        strcpy(path, "");
> +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> +            dev = -1;
> +        }
> +    }
> +
> +    if (dev == -1) {
> +        return;
> +    }
> +
> +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> +    if (xendev != NULL) {
> +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> +        if (bepath == NULL) {
> +            xen_be_del_xendev(dom, dev);
> +        } else {
> +            free(bepath);
> +            xen_be_backend_changed(xendev, path);
> +        }
> +    }
> +}
> +
>  static void xenstore_update_be(char *watch, char *type, int dom,
>                                 struct XenDevOps *ops)
>  {
> @@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
>      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
>          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
>      }
> +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%" PRIxPTR,
> +               &type, &dom, &ops) == 3) {
> +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
> +    }
>  
>  cleanup:
>      free(vec);
> @@ -732,11 +811,74 @@ err:
>      return -1;
>  }
>  
> +int xen_vtpm_register(struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> +    char *domu;
> +    unsigned int cdev, j, rc;
> +    const char *type = "vtpm";
> +    char **dev = NULL;
> +
> +    /*front domu*/
> +    domu = xs_get_domain_path(xenstore, xen_domid);
> +    snprintf(path, sizeof(path), "%s/device/%s",
> +             domu, type);
> +    free(domu);
> +    dev = xs_directory(xenstore, 0, path, &cdev);
> +    if (dev == NULL) {
> +        return 0;
> +    }
> +
> +    for (j = 0; j < cdev; j++) {
> +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]), ops);
> +        if (xendev == NULL) {
> +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is NULL.\n");
> +            continue;
> +        }
> +
> +        if (xendev->ops->initialise) {
> +            rc = xendev->ops->initialise(xendev);
> +
> +            /*if initialise failed, delete it*/
> +            if (rc != 0) {
> +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> +                continue;
> +            }
> +        }
> +
> +        /*setup watch*/
> +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> +                 type, xen_domid, xendev->ops);
> +        if (!xs_watch(xenstore, xendev->be, token)) {
> +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch failed.\n");
> +            return -1;
> +        }
> +    }
> +
> +    free(dev);
> +    return 0;
> +}
> +
>  int xen_be_register(const char *type, struct XenDevOps *ops)
>  {
>      return xenstore_scan(type, xen_domid, ops);
>  }
>  
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom)
> +{
> +    xendev->local_port = xc_evtchn_bind_unbound_port(xendev->evtchndev,
> +                                                     remote_dom);
> +    if (xendev->local_port == -1) {
> +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> +        return -1;
> +    }
> +    xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
> +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> +                        xen_be_evtchn_event, NULL, xendev);
> +    return 0;
> +}
> +
>  int xen_be_bind_evtchn(struct XenDevice *xendev)
>  {
>      if (xendev->local_port != -1) {
> @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice *xendev)
>      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
>  }
>  
> +int xen_vtpm_send(unsigned char *buf, size_t count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->send) {
> +        rc = xendev->ops->send(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}
> +
> +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->recv) {
> +        xendev->ops->recv(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}
> +
>  /*
>   * msg_level:
>   *  0 == errors (stderr + logfile).
> diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> new file mode 100644
> index 0000000..0d740c1
> --- /dev/null
> +++ b/hw/xen/xen_stubdom_vtpm.c
> @@ -0,0 +1,333 @@
> +/*
> + * Connect to Xen vTPM stubdom domain
> + *
> + *  Copyright (c) 2014 Intel Corporation
> + *  Authors:
> + *    Quan Xu <quan.xu@intel.com>
> + *
> + * 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 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, see <http://www.gnu.org/licenses/>
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <stdarg.h>
> +#include <string.h>
> +#include <unistd.h>
> +#include <signal.h>
> +#include <inttypes.h>
> +#include <time.h>
> +#include <fcntl.h>
> +#include <errno.h>
> +#include <sys/ioctl.h>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <sys/mman.h>
> +#include <sys/uio.h>
> +
> +#include "hw/hw.h"
> +#include "block/aio.h"
> +#include "hw/xen/xen_backend.h"
> +
> +enum tpmif_state {
> +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel complete */
> +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> +};
> +
> +static AioContext *vtpm_aio_ctx;
> +
> +enum status_bits {
> +    VTPM_STATUS_RUNNING  = 0x1,
> +    VTPM_STATUS_IDLE     = 0x2,
> +    VTPM_STATUS_RESULT   = 0x4,
> +    VTPM_STATUS_CANCELED = 0x8,
> +};
> +
> +struct tpmif_shared_page {
> +    uint32_t length;         /* request/response length in bytes */
> +
> +    uint8_t  state;           /* enum tpmif_state */
> +    uint8_t  locality;        /* for the current request */
> +    uint8_t  pad;             /* should be zero */
> +
> +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be zero */
> +    uint32_t extra_pages[0]; /* grant IDs; length is actually nr_extra_pages */
> +};
> +
> +struct QEMUBH {
> +    AioContext *ctx;
> +    QEMUBHFunc *cb;
> +    void *opaque;
> +    QEMUBH *next;
> +    bool scheduled;
> +    bool idle;
> +    bool deleted;
> +};

This is a private structure, you cannot just copy the definition here.

You do not even need it in fact, since sr_bh->ctx is always vtpm_aio_ctx.

Paolo


> +struct XenVtpmDev {
> +    struct XenDevice xendev;  /* must be first */
> +    struct           tpmif_shared_page *shr;
> +    xc_gntshr        *xen_xcs;
> +    int              ring_ref;
> +    int              bedomid;
> +    QEMUBH           *sr_bh;
> +};
> +
> +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> +{
> +    switch (vtpmdev->shr->state) {
> +    case TPMIF_STATE_IDLE:
> +    case TPMIF_STATE_FINISH:
> +        return VTPM_STATUS_IDLE;
> +    case TPMIF_STATE_SUBMIT:
> +    case TPMIF_STATE_CANCEL:
> +        return VTPM_STATUS_RUNNING;
> +    default:
> +        return 0;
> +    }
> +}
> +
> +static int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)
> +{
> +    xs_transaction_t xbt = XBT_NULL;
> +
> +    if (xendev->fe_state == xbus) {
> +        return 0;
> +    }
> +
> +    xendev->fe_state = xbus;
> +
> +retry_transaction:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto retry_transaction;
> +        }
> +    }
> +
> +    return 0;
> +
> +abort_transaction:
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}
> +
> +static int vtpm_aio_wait(QEMUBH *qbh)
> +{
> +    return aio_poll(qbh->ctx, true);
> +}
> +
> +static void sr_bh_handler(void *opaque)
> +{
> +}
> +
> +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset;
> +
> +    if (shr->state == TPMIF_STATE_IDLE) {
> +        return -ECANCELED;
> +    }
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> +    *count = shr->length;
> +
> +    return 0;
> +}
> +
> +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    memcpy(offset + (uint8_t *)shr, buf, count);
> +    shr->length = count;
> +    barrier();
> +    shr->state = TPMIF_STATE_SUBMIT;
> +    xen_wmb();
> +    xen_be_send_notify(&vtpmdev->xendev);
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpmdev->sr_bh);
> +    }
> +
> +    return count;
> +}
> +
> +static int vtpm_initialise(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    xs_transaction_t xbt = XBT_NULL;
> +    unsigned int ring_ref;
> +
> +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev, "frontend");
> +    if (vtpmdev->xendev.fe == NULL) {
> +        return -1;
> +    }
> +
> +    /* Get backend domid */
> +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> +                             &vtpmdev->bedomid)) {
> +        return -1;
> +    }
> +
> +    /*alloc share page*/
> +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs, vtpmdev->bedomid, 1,
> +                                         &ring_ref, PROT_READ|PROT_WRITE);
> +    vtpmdev->ring_ref = ring_ref;
> +    if (vtpmdev->shr == NULL) {
> +        return -1;
> +    }
> +
> +    /*Create event channel */
> +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0, vtpmdev->bedomid)) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +        return -1;
> +    }
> +
> +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> +                     vtpmdev->xendev.local_port);
> +
> +again:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> +                           vtpmdev->ring_ref)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> +                           vtpmdev->xendev.local_port)) {
> +        goto abort_transaction;
> +    }
> +
> +    /* Publish protocol v2 feature */
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto again;
> +        }
> +    }
> +    /* Tell vtpm backend that we are ready */
> +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> +
> +    return 0;
> +
> +abort_transaction:
> +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}
> +
> +static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    int be_state;
> +
> +    if (strcmp(node, "state") == 0) {
> +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> +        switch (be_state) {
> +        case XenbusStateConnected:
> +            /*TODO*/
> +            break;
> +        case XenbusStateClosing:
> +        case XenbusStateClosed:
> +            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
> +            break;
> +        default:
> +            break;
> +        }
> +    }
> +}
> +
> +static int vtpm_free(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    QEMUBH *qbh = vtpmdev->sr_bh;
> +
> +    aio_poll(qbh->ctx, false);
> +    qemu_bh_delete(vtpmdev->sr_bh);
> +    if (vtpmdev->shr) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    }
> +    xc_interface_close(vtpmdev->xen_xcs);
> +    return 0;
> +}
> +
> +static void vtpm_alloc(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    vtpm_aio_ctx = aio_context_new(NULL);
> +    if (vtpm_aio_ctx == NULL) {
> +        return;
> +    }
> +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler, vtpmdev);
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> +}
> +
> +static void vtpm_event(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +}
> +
> +struct XenDevOps xen_vtpmdev_ops = {
> +    .size             = sizeof(struct XenVtpmDev),
> +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> +                        DEVOPS_FLAG_STUBDOM_BE,
> +    .event            = vtpm_event,
> +    .free             = vtpm_free,
> +    .alloc            = vtpm_alloc,
> +    .initialise       = vtpm_initialise,
> +    .backend_changed  = vtpm_backend_changed,
> +    .recv             = vtpm_recv,
> +    .send             = vtpm_send,
> +};
> diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
> index 3b4125e..45fd6d3 100644
> --- a/include/hw/xen/xen_backend.h
> +++ b/include/hw/xen/xen_backend.h
> @@ -15,6 +15,8 @@ struct XenDevice;
>  #define DEVOPS_FLAG_NEED_GNTDEV   1
>  /* don't expect frontend doing correct state transitions (aka console quirk) */
>  #define DEVOPS_FLAG_IGNORE_STATE  2
> +/*dev backend is stubdom*/
> +#define DEVOPS_FLAG_STUBDOM_BE    4
>  
>  struct XenDevOps {
>      size_t    size;
> @@ -26,6 +28,8 @@ struct XenDevOps {
>      void      (*event)(struct XenDevice *xendev);
>      void      (*disconnect)(struct XenDevice *xendev);
>      int       (*free)(struct XenDevice *xendev);
> +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t count);
> +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t *count);
>      void      (*backend_changed)(struct XenDevice *xendev, const char *node);
>      void      (*frontend_changed)(struct XenDevice *xendev, const char *node);
>  };
> @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice *xendev);
>  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...)
>      GCC_FMT_ATTR(3, 4);
>  
> +/*Xen stubdom vtpm*/
> +int xen_vtpm_register(struct XenDevOps *ops);
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
> +int xen_vtpm_send(unsigned char *buf, size_t count);
> +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> +
>  /* actual backend drivers */
>  extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
>  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c */
>  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
>  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c        */
>  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c         */
> +extern struct XenDevOps xen_vtpmdev_ops;      /* xen_stubdom_vtpm.c*/
>  
>  void xen_init_display(int domid);
>  
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 95612a4..fb43084 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
>      return xc_interface_open(logger, dombuild_logger, open_flags);
>  }
>  
> +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> +                                           unsigned int open_flags)
> +{
> +    return xc_gntshr_open(logger, open_flags);
> +}
> +
>  /* FIXME There is now way to have the xen fd */
>  static inline int xc_fd(xc_interface *xen_xc)
>  {
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 21f1cbb..c99ace8 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>      int i, rc;
>      unsigned long ioreq_pfn;
>      unsigned long bufioreq_evtchn;
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    unsigned long stubdom_vtpm = 0;
> +#endif
> +
>      XenIOState *state;
>  
>      state = g_malloc0(sizeof (XenIOState));
> @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>          fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
>          return -1;
>      }
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> +    if (stubdom_vtpm) {
> +        xen_vtpm_register(&xen_vtpmdev_ops);
> +    }
> +#endif
> +
>      xen_be_register("console", &xen_console_ops);
>      xen_be_register("vkbd", &xen_kbdmouse_ops);
>      xen_be_register("qdisk", &xen_blkdev_ops);
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:15:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12: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 1XlGXW-0000ci-Nu; Mon, 03 Nov 2014 12:15:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlGXU-0000cN-8E
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 12:15:16 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	65/FF-27623-3D177545; Mon, 03 Nov 2014 12:15:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415016913!8821913!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1538 invoked from network); 3 Nov 2014 12:15:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 12:15:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188859871"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 07:15:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlGHA-0008Re-5L;
	Mon, 03 Nov 2014 11:58:24 +0000
Date: Mon, 3 Nov 2014 11:58:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Quan Xu <quan.xu@intel.com>
In-Reply-To: <1414910368-27757-1-git-send-email-quan.xu@intel.com>
Message-ID: <alpine.DEB.2.02.1411031154490.22875@kaball.uk.xensource.com>
References: <1414910368-27757-1-git-send-email-quan.xu@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@eu.citrix.com, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms
	driver.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2 Nov 2014, Quan Xu wrote:
> This driver provides vTPM initialization and sending data and TPM
> commends to a Xen stubdom vTPM domain.
    ^ commands

Driver for what? QEMU usually doesn't have drivers, QEMU has emulated
devices. Is this an emulated device? Is it supposed to be run inside the
stubdom?

Please add more description to the commit message. I should be able to
understand what you are doing before reading the patch. Reading code
changes is to make sure that the implementation details are correct. In
this case, I really don't know what you are trying to achieve yet.


> Signed-off-by: Quan Xu <quan.xu@intel.com>
>
>  hw/tpm/Makefile.objs     |   1 +
>  hw/tpm/tpm_xenstubdoms.c | 238 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 239 insertions(+)
>  create mode 100644 hw/tpm/tpm_xenstubdoms.c
> 
> diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
> index 99f5983..39fc0f9 100644
> --- a/hw/tpm/Makefile.objs
> +++ b/hw/tpm/Makefile.objs
> @@ -1,2 +1,3 @@
>  common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
>  common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
> +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o
> diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
> new file mode 100644
> index 0000000..845df18
> --- /dev/null
> +++ b/hw/tpm/tpm_xenstubdoms.c
> @@ -0,0 +1,238 @@
> +/*
> + * Xen Stubdom vTPM driver
> + *
> + *  Copyright (c) 2014 Intel Corporation
> + *  Authors:
> + *    Quan Xu <quan.xu@intel.com>
> + *
> + * 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 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, see <http://www.gnu.org/licenses/>
> + */
> +
> +#include <dirent.h>
> +#include "qemu-common.h"
> +#include "qapi/error.h"
> +#include "qemu/sockets.h"
> +#include "qemu/log.h"
> +#include "sysemu/tpm_backend.h"
> +#include "tpm_int.h"
> +#include "hw/hw.h"
> +#include "hw/i386/pc.h"
> +#include "hw/xen/xen_backend.h"
> +#include "sysemu/tpm_backend_int.h"
> +#include "tpm_tis.h"
> +
> +#ifdef DEBUG_TPM
> +#define DPRINTF(fmt, ...) \
> +    do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTF(fmt, ...) \
> +    do { } while (0)
> +#endif
> +
> +#define TYPE_TPM_XENSTUBDOMS "tpm-xenstubdoms"
> +#define TPM_XENSTUBDOMS(obj) \
> +    OBJECT_CHECK(TPMXenstubdomsState, (obj), TYPE_TPM_XENSTUBDOMS)
> +
> +static const TPMDriverOps tpm_xenstubdoms_driver;
> +
> +/* data structures */
> +typedef struct TPMXenstubdomsThreadParams {
> +    TPMState *tpm_state;
> +    TPMRecvDataCB *recv_data_callback;
> +    TPMBackend *tb;
> +} TPMXenstubdomsThreadParams;
> +
> +struct TPMXenstubdomsState {
> +    TPMBackend parent;
> +    TPMBackendThread tbt;
> +    TPMXenstubdomsThreadParams tpm_thread_params;
> +    bool had_startup_error;
> +};
> +
> +typedef struct TPMXenstubdomsState TPMXenstubdomsState;
> +
> +/* functions */
> +
> +static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb);
> +
> +static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
> +{
> +    size_t rlen;
> +    xen_vtpm_send(locty_data->w_buffer.buffer, locty_data->w_offset);
> +    xen_vtpm_recv(locty_data->r_buffer.buffer, &rlen);
> +    return 0;
> +}
> +
> +static void tpm_xenstubdoms_worker_thread(gpointer data,
> +                                          gpointer user_data)
> +{
> +    TPMXenstubdomsThreadParams *thr_parms = user_data;
> +    TPMBackendCmd cmd = (TPMBackendCmd)data;
> +
> +    switch (cmd) {
> +    case TPM_BACKEND_CMD_PROCESS_CMD:
> +        /* here need a the cmd process function */
> +        tpm_xenstubdoms_unix_transfer(thr_parms->tpm_state->locty_data);
> +        thr_parms->recv_data_callback(thr_parms->tpm_state,
> +                                      thr_parms->tpm_state->locty_number);
> +        break;
> +    case TPM_BACKEND_CMD_INIT:
> +    case TPM_BACKEND_CMD_END:
> +    case TPM_BACKEND_CMD_TPM_RESET:
> +        /* nothing to do */
> +        break;
> +    }
> +}
> +
> +/*
> + *  * Start the TPM (thread). If it had been started before, then terminate
> + *   * and start it again.
> + *    */
> +static int tpm_xenstubdoms_startup_tpm(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_backend_thread_tpm_reset(&tpm_xs->tbt, tpm_xenstubdoms_worker_thread,
> +                                 &tpm_xs->tpm_thread_params);
> +
> +    return 0;
> +}
> +
> +static void tpm_xenstubdoms_reset(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_backend_thread_end(&tpm_xs->tbt);
> +    tpm_xs->had_startup_error = false;
> +}
> +
> +static int tpm_xenstubdoms_init(TPMBackend *tb, TPMState *s,
> +                                TPMRecvDataCB *recv_data_cb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_xs->tpm_thread_params.tpm_state = s;
> +    tpm_xs->tpm_thread_params.recv_data_callback = recv_data_cb;
> +    tpm_xs->tpm_thread_params.tb = tb;
> +    return 0;
> +}
> +
> +static bool tpm_xenstubdoms_get_tpm_established_flag(TPMBackend *tb)
> +{
> +    return false;
> +}
> +
> +static bool tpm_xenstubdoms_get_startup_error(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    return tpm_xs->had_startup_error;
> +}
> +
> +static size_t tpm_xenstubdoms_realloc_buffer(TPMSizedBuffer *sb)
> +{
> +    size_t wanted_size = 4096; /* Linux tpm.c buffer size */
> +
> +    if (sb->size != wanted_size) {
> +        sb->buffer = g_realloc(sb->buffer, wanted_size);
> +        sb->size = wanted_size;
> +    }
> +    return sb->size;
> +}
> +
> +static void tpm_xenstubdoms_deliver_request(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +    tpm_backend_thread_deliver_request(&tpm_xs->tbt);
> +}
> +
> +static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb)
> +{
> +}
> +
> +static const char *tpm_xenstubdoms_create_desc(void)
> +{
> +    return "Xenstubdoms TPM backend driver";
> +}
> +
> +static TPMBackend *tpm_xenstubdoms_create(QemuOpts *opts, const char *id)
> +{
> +    Object *obj = object_new(TYPE_TPM_XENSTUBDOMS);
> +    TPMBackend *tb = TPM_BACKEND(obj);
> +
> +    tb->id = g_strdup(id);
> +    tb->fe_model = -1;
> +    tb->ops = &tpm_xenstubdoms_driver;
> +    return tb;
> +}
> +
> +static void tpm_xenstubdoms_destroy(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xh = TPM_XENSTUBDOMS(tb);
> +    tpm_backend_thread_end(&tpm_xh->tbt);
> +
> +    g_free(tb->id);
> +}
> +
> +static const QemuOptDesc tpm_xenstubdoms_cmdline_opts[] = {
> +    TPM_STANDARD_CMDLINE_OPTS,
> +    {},
> +};
> +
> +static const TPMDriverOps tpm_xenstubdoms_driver = {
> +    .type                     = TPM_TYPE_XENSTUBDOMS,
> +    .opts                     = tpm_xenstubdoms_cmdline_opts,
> +    .desc                     = tpm_xenstubdoms_create_desc,
> +    .create                   = tpm_xenstubdoms_create,
> +    .destroy                  = tpm_xenstubdoms_destroy,
> +    .init                     = tpm_xenstubdoms_init,
> +    .startup_tpm              = tpm_xenstubdoms_startup_tpm,
> +    .realloc_buffer           = tpm_xenstubdoms_realloc_buffer,
> +    .reset                    = tpm_xenstubdoms_reset,
> +    .had_startup_error        = tpm_xenstubdoms_get_startup_error,
> +    .deliver_request          = tpm_xenstubdoms_deliver_request,
> +    .cancel_cmd               = tpm_xenstubdoms_cancel_cmd,
> +    .get_tpm_established_flag = tpm_xenstubdoms_get_tpm_established_flag,
> +};
> +
> +static void tpm_xenstubdoms_inst_init(Object *obj)
> +{
> +}
> +
> +static void tpm_xenstubdoms_inst_finalize(Object *obj)
> +{
> +}
> +
> +static void tpm_xenstubdoms_class_init(ObjectClass *klass, void *data)
> +{
> +    TPMBackendClass *tbc = TPM_BACKEND_CLASS(klass);
> +    tbc->ops = &tpm_xenstubdoms_driver;
> +}
> +
> +static const TypeInfo tpm_xenstubdoms_info = {
> +    .name = TYPE_TPM_XENSTUBDOMS,
> +    .parent = TYPE_TPM_BACKEND,
> +    .instance_size = sizeof(TPMXenstubdomsState),
> +    .class_init = tpm_xenstubdoms_class_init,
> +    .instance_init = tpm_xenstubdoms_inst_init,
> +    .instance_finalize = tpm_xenstubdoms_inst_finalize,
> +};
> +
> +static void tpm_xenstubdoms_register(void)
> +{
> +    type_register_static(&tpm_xenstubdoms_info);
> +    tpm_register_driver(&tpm_xenstubdoms_driver);
> +}
> +
> +type_init(tpm_xenstubdoms_register)
> -- 
> 1.8.3.2
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:15:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12: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 1XlGXW-0000ci-Nu; Mon, 03 Nov 2014 12:15:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlGXU-0000cN-8E
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 12:15:16 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	65/FF-27623-3D177545; Mon, 03 Nov 2014 12:15:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415016913!8821913!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1538 invoked from network); 3 Nov 2014 12:15:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 12:15:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="188859871"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 07:15:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlGHA-0008Re-5L;
	Mon, 03 Nov 2014 11:58:24 +0000
Date: Mon, 3 Nov 2014 11:58:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Quan Xu <quan.xu@intel.com>
In-Reply-To: <1414910368-27757-1-git-send-email-quan.xu@intel.com>
Message-ID: <alpine.DEB.2.02.1411031154490.22875@kaball.uk.xensource.com>
References: <1414910368-27757-1-git-send-email-quan.xu@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@eu.citrix.com, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms
	driver.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2 Nov 2014, Quan Xu wrote:
> This driver provides vTPM initialization and sending data and TPM
> commends to a Xen stubdom vTPM domain.
    ^ commands

Driver for what? QEMU usually doesn't have drivers, QEMU has emulated
devices. Is this an emulated device? Is it supposed to be run inside the
stubdom?

Please add more description to the commit message. I should be able to
understand what you are doing before reading the patch. Reading code
changes is to make sure that the implementation details are correct. In
this case, I really don't know what you are trying to achieve yet.


> Signed-off-by: Quan Xu <quan.xu@intel.com>
>
>  hw/tpm/Makefile.objs     |   1 +
>  hw/tpm/tpm_xenstubdoms.c | 238 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 239 insertions(+)
>  create mode 100644 hw/tpm/tpm_xenstubdoms.c
> 
> diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
> index 99f5983..39fc0f9 100644
> --- a/hw/tpm/Makefile.objs
> +++ b/hw/tpm/Makefile.objs
> @@ -1,2 +1,3 @@
>  common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
>  common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
> +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o
> diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
> new file mode 100644
> index 0000000..845df18
> --- /dev/null
> +++ b/hw/tpm/tpm_xenstubdoms.c
> @@ -0,0 +1,238 @@
> +/*
> + * Xen Stubdom vTPM driver
> + *
> + *  Copyright (c) 2014 Intel Corporation
> + *  Authors:
> + *    Quan Xu <quan.xu@intel.com>
> + *
> + * 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 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, see <http://www.gnu.org/licenses/>
> + */
> +
> +#include <dirent.h>
> +#include "qemu-common.h"
> +#include "qapi/error.h"
> +#include "qemu/sockets.h"
> +#include "qemu/log.h"
> +#include "sysemu/tpm_backend.h"
> +#include "tpm_int.h"
> +#include "hw/hw.h"
> +#include "hw/i386/pc.h"
> +#include "hw/xen/xen_backend.h"
> +#include "sysemu/tpm_backend_int.h"
> +#include "tpm_tis.h"
> +
> +#ifdef DEBUG_TPM
> +#define DPRINTF(fmt, ...) \
> +    do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTF(fmt, ...) \
> +    do { } while (0)
> +#endif
> +
> +#define TYPE_TPM_XENSTUBDOMS "tpm-xenstubdoms"
> +#define TPM_XENSTUBDOMS(obj) \
> +    OBJECT_CHECK(TPMXenstubdomsState, (obj), TYPE_TPM_XENSTUBDOMS)
> +
> +static const TPMDriverOps tpm_xenstubdoms_driver;
> +
> +/* data structures */
> +typedef struct TPMXenstubdomsThreadParams {
> +    TPMState *tpm_state;
> +    TPMRecvDataCB *recv_data_callback;
> +    TPMBackend *tb;
> +} TPMXenstubdomsThreadParams;
> +
> +struct TPMXenstubdomsState {
> +    TPMBackend parent;
> +    TPMBackendThread tbt;
> +    TPMXenstubdomsThreadParams tpm_thread_params;
> +    bool had_startup_error;
> +};
> +
> +typedef struct TPMXenstubdomsState TPMXenstubdomsState;
> +
> +/* functions */
> +
> +static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb);
> +
> +static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
> +{
> +    size_t rlen;
> +    xen_vtpm_send(locty_data->w_buffer.buffer, locty_data->w_offset);
> +    xen_vtpm_recv(locty_data->r_buffer.buffer, &rlen);
> +    return 0;
> +}
> +
> +static void tpm_xenstubdoms_worker_thread(gpointer data,
> +                                          gpointer user_data)
> +{
> +    TPMXenstubdomsThreadParams *thr_parms = user_data;
> +    TPMBackendCmd cmd = (TPMBackendCmd)data;
> +
> +    switch (cmd) {
> +    case TPM_BACKEND_CMD_PROCESS_CMD:
> +        /* here need a the cmd process function */
> +        tpm_xenstubdoms_unix_transfer(thr_parms->tpm_state->locty_data);
> +        thr_parms->recv_data_callback(thr_parms->tpm_state,
> +                                      thr_parms->tpm_state->locty_number);
> +        break;
> +    case TPM_BACKEND_CMD_INIT:
> +    case TPM_BACKEND_CMD_END:
> +    case TPM_BACKEND_CMD_TPM_RESET:
> +        /* nothing to do */
> +        break;
> +    }
> +}
> +
> +/*
> + *  * Start the TPM (thread). If it had been started before, then terminate
> + *   * and start it again.
> + *    */
> +static int tpm_xenstubdoms_startup_tpm(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_backend_thread_tpm_reset(&tpm_xs->tbt, tpm_xenstubdoms_worker_thread,
> +                                 &tpm_xs->tpm_thread_params);
> +
> +    return 0;
> +}
> +
> +static void tpm_xenstubdoms_reset(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_backend_thread_end(&tpm_xs->tbt);
> +    tpm_xs->had_startup_error = false;
> +}
> +
> +static int tpm_xenstubdoms_init(TPMBackend *tb, TPMState *s,
> +                                TPMRecvDataCB *recv_data_cb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_xs->tpm_thread_params.tpm_state = s;
> +    tpm_xs->tpm_thread_params.recv_data_callback = recv_data_cb;
> +    tpm_xs->tpm_thread_params.tb = tb;
> +    return 0;
> +}
> +
> +static bool tpm_xenstubdoms_get_tpm_established_flag(TPMBackend *tb)
> +{
> +    return false;
> +}
> +
> +static bool tpm_xenstubdoms_get_startup_error(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    return tpm_xs->had_startup_error;
> +}
> +
> +static size_t tpm_xenstubdoms_realloc_buffer(TPMSizedBuffer *sb)
> +{
> +    size_t wanted_size = 4096; /* Linux tpm.c buffer size */
> +
> +    if (sb->size != wanted_size) {
> +        sb->buffer = g_realloc(sb->buffer, wanted_size);
> +        sb->size = wanted_size;
> +    }
> +    return sb->size;
> +}
> +
> +static void tpm_xenstubdoms_deliver_request(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +    tpm_backend_thread_deliver_request(&tpm_xs->tbt);
> +}
> +
> +static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb)
> +{
> +}
> +
> +static const char *tpm_xenstubdoms_create_desc(void)
> +{
> +    return "Xenstubdoms TPM backend driver";
> +}
> +
> +static TPMBackend *tpm_xenstubdoms_create(QemuOpts *opts, const char *id)
> +{
> +    Object *obj = object_new(TYPE_TPM_XENSTUBDOMS);
> +    TPMBackend *tb = TPM_BACKEND(obj);
> +
> +    tb->id = g_strdup(id);
> +    tb->fe_model = -1;
> +    tb->ops = &tpm_xenstubdoms_driver;
> +    return tb;
> +}
> +
> +static void tpm_xenstubdoms_destroy(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xh = TPM_XENSTUBDOMS(tb);
> +    tpm_backend_thread_end(&tpm_xh->tbt);
> +
> +    g_free(tb->id);
> +}
> +
> +static const QemuOptDesc tpm_xenstubdoms_cmdline_opts[] = {
> +    TPM_STANDARD_CMDLINE_OPTS,
> +    {},
> +};
> +
> +static const TPMDriverOps tpm_xenstubdoms_driver = {
> +    .type                     = TPM_TYPE_XENSTUBDOMS,
> +    .opts                     = tpm_xenstubdoms_cmdline_opts,
> +    .desc                     = tpm_xenstubdoms_create_desc,
> +    .create                   = tpm_xenstubdoms_create,
> +    .destroy                  = tpm_xenstubdoms_destroy,
> +    .init                     = tpm_xenstubdoms_init,
> +    .startup_tpm              = tpm_xenstubdoms_startup_tpm,
> +    .realloc_buffer           = tpm_xenstubdoms_realloc_buffer,
> +    .reset                    = tpm_xenstubdoms_reset,
> +    .had_startup_error        = tpm_xenstubdoms_get_startup_error,
> +    .deliver_request          = tpm_xenstubdoms_deliver_request,
> +    .cancel_cmd               = tpm_xenstubdoms_cancel_cmd,
> +    .get_tpm_established_flag = tpm_xenstubdoms_get_tpm_established_flag,
> +};
> +
> +static void tpm_xenstubdoms_inst_init(Object *obj)
> +{
> +}
> +
> +static void tpm_xenstubdoms_inst_finalize(Object *obj)
> +{
> +}
> +
> +static void tpm_xenstubdoms_class_init(ObjectClass *klass, void *data)
> +{
> +    TPMBackendClass *tbc = TPM_BACKEND_CLASS(klass);
> +    tbc->ops = &tpm_xenstubdoms_driver;
> +}
> +
> +static const TypeInfo tpm_xenstubdoms_info = {
> +    .name = TYPE_TPM_XENSTUBDOMS,
> +    .parent = TYPE_TPM_BACKEND,
> +    .instance_size = sizeof(TPMXenstubdomsState),
> +    .class_init = tpm_xenstubdoms_class_init,
> +    .instance_init = tpm_xenstubdoms_inst_init,
> +    .instance_finalize = tpm_xenstubdoms_inst_finalize,
> +};
> +
> +static void tpm_xenstubdoms_register(void)
> +{
> +    type_register_static(&tpm_xenstubdoms_info);
> +    tpm_register_driver(&tpm_xenstubdoms_driver);
> +}
> +
> +type_init(tpm_xenstubdoms_register)
> -- 
> 1.8.3.2
> 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:22:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12: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 1XlGeD-0000qg-NQ; Mon, 03 Nov 2014 12:22:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1XlGeC-0000qb-Vz
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 12:22:13 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	15/30-31453-47377545; Mon, 03 Nov 2014 12:22:12 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415017329!5460972!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16754 invoked from network); 3 Nov 2014 12:22:11 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 12:22:11 -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 sA3CM6RL028364
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 3 Nov 2014 07:22:06 -0500
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-83.ams2.redhat.com
	[10.36.116.83])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sA3CM1x3020822; Mon, 3 Nov 2014 07:22:02 -0500
Message-ID: <54577368.9060000@redhat.com>
Date: Mon, 03 Nov 2014 13:22:00 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, linux-kernel@vger.kernel.org,
	Jeff Moyer <jmoyer@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: improve protection against
 issuing unsupported REQ_FUA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/27/14 14:44, Vitaly Kuznetsov wrote:
> Guard against issuing unsupported REQ_FUA and REQ_FLUSH was introduced
> in d11e61583 and was factored out into blkif_request_flush_valid() in
> 0f1ca65ee. However:
> 1) This check in incomplete. In case we negotiated to feature_flush = REQ_FLUSH
>    and flush_op = BLKIF_OP_FLUSH_DISKCACHE (so FUA is unsupported) FUA request
>    will still pass the check.
> 2) blkif_request_flush_valid() is misnamed. It is bool but returns true when
>    the request is invalid.
> 3) When blkif_request_flush_valid() fails -EIO is being returned. It seems that
>    -EOPNOTSUPP is more appropriate here.
> Fix all of the above issues.
> 
> This patch is based on the original patch by Laszlo Ersek and a comment by
> Jeff Moyer.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
>  drivers/block/xen-blkfront.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 5ac312f..2e6c103 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -582,12 +582,14 @@ static inline void flush_requests(struct blkfront_info *info)
>  		notify_remote_via_irq(info->irq);
>  }
>  
> -static inline bool blkif_request_flush_valid(struct request *req,
> -					     struct blkfront_info *info)
> +static inline bool blkif_request_flush_invalid(struct request *req,
> +					       struct blkfront_info *info)
>  {
>  	return ((req->cmd_type != REQ_TYPE_FS) ||
> -		((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
> -		!info->flush_op));
> +		((req->cmd_flags & REQ_FLUSH) &&
> +		 !(info->feature_flush & REQ_FLUSH)) ||
> +		((req->cmd_flags & REQ_FUA) &&
> +		 !(info->feature_flush & REQ_FUA)));
>  }
>  
>  /*
> @@ -612,8 +614,8 @@ static void do_blkif_request(struct request_queue *rq)
>  
>  		blk_start_request(req);
>  
> -		if (blkif_request_flush_valid(req, info)) {
> -			__blk_end_request_all(req, -EIO);
> +		if (blkif_request_flush_invalid(req, info)) {
> +			__blk_end_request_all(req, -EOPNOTSUPP);
>  			continue;
>  		}
>  
> 

Not sure if there has been some feedback yet (I can't see anything
threaded with this message in my inbox).

FWIW I consulted "Documentation/block/writeback_cache_control.txt" for
this review. Apparently, REQ_FLUSH forces out "previously completed
write requests", whereas REQ_FUA delays the IO completion signal for
*this* request until "the data has been committed to non-volatile
storage". So, indeed, support for REQ_FLUSH only does not guarantee that
REQ_FUA can be served.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Thanks
Laszlo

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:22:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12: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 1XlGeD-0000qg-NQ; Mon, 03 Nov 2014 12:22:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1XlGeC-0000qb-Vz
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 12:22:13 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	15/30-31453-47377545; Mon, 03 Nov 2014 12:22:12 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415017329!5460972!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16754 invoked from network); 3 Nov 2014 12:22:11 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 12:22:11 -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 sA3CM6RL028364
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 3 Nov 2014 07:22:06 -0500
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-83.ams2.redhat.com
	[10.36.116.83])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sA3CM1x3020822; Mon, 3 Nov 2014 07:22:02 -0500
Message-ID: <54577368.9060000@redhat.com>
Date: Mon, 03 Nov 2014 13:22:00 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, linux-kernel@vger.kernel.org,
	Jeff Moyer <jmoyer@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: improve protection against
 issuing unsupported REQ_FUA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/27/14 14:44, Vitaly Kuznetsov wrote:
> Guard against issuing unsupported REQ_FUA and REQ_FLUSH was introduced
> in d11e61583 and was factored out into blkif_request_flush_valid() in
> 0f1ca65ee. However:
> 1) This check in incomplete. In case we negotiated to feature_flush = REQ_FLUSH
>    and flush_op = BLKIF_OP_FLUSH_DISKCACHE (so FUA is unsupported) FUA request
>    will still pass the check.
> 2) blkif_request_flush_valid() is misnamed. It is bool but returns true when
>    the request is invalid.
> 3) When blkif_request_flush_valid() fails -EIO is being returned. It seems that
>    -EOPNOTSUPP is more appropriate here.
> Fix all of the above issues.
> 
> This patch is based on the original patch by Laszlo Ersek and a comment by
> Jeff Moyer.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
>  drivers/block/xen-blkfront.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 5ac312f..2e6c103 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -582,12 +582,14 @@ static inline void flush_requests(struct blkfront_info *info)
>  		notify_remote_via_irq(info->irq);
>  }
>  
> -static inline bool blkif_request_flush_valid(struct request *req,
> -					     struct blkfront_info *info)
> +static inline bool blkif_request_flush_invalid(struct request *req,
> +					       struct blkfront_info *info)
>  {
>  	return ((req->cmd_type != REQ_TYPE_FS) ||
> -		((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
> -		!info->flush_op));
> +		((req->cmd_flags & REQ_FLUSH) &&
> +		 !(info->feature_flush & REQ_FLUSH)) ||
> +		((req->cmd_flags & REQ_FUA) &&
> +		 !(info->feature_flush & REQ_FUA)));
>  }
>  
>  /*
> @@ -612,8 +614,8 @@ static void do_blkif_request(struct request_queue *rq)
>  
>  		blk_start_request(req);
>  
> -		if (blkif_request_flush_valid(req, info)) {
> -			__blk_end_request_all(req, -EIO);
> +		if (blkif_request_flush_invalid(req, info)) {
> +			__blk_end_request_all(req, -EOPNOTSUPP);
>  			continue;
>  		}
>  
> 

Not sure if there has been some feedback yet (I can't see anything
threaded with this message in my inbox).

FWIW I consulted "Documentation/block/writeback_cache_control.txt" for
this review. Apparently, REQ_FLUSH forces out "previously completed
write requests", whereas REQ_FUA delays the IO completion signal for
*this* request until "the data has been committed to non-volatile
storage". So, indeed, support for REQ_FLUSH only does not guarantee that
REQ_FUA can be served.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Thanks
Laszlo

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:22:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:22:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGeQ-0000sK-4N; Mon, 03 Nov 2014 12:22:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1XlGeO-0000rn-8K
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 12:22:24 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E8/7D-27584-F7377545; Mon, 03 Nov 2014 12:22:23 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415017341!10845115!1
X-Originating-IP: [209.85.217.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12093 invoked from network); 3 Nov 2014 12:22:22 -0000
Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com)
	(209.85.217.178)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 12:22:22 -0000
Received: by mail-lb0-f178.google.com with SMTP id f15so10117544lbj.23
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 04:22:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=D/hQsp9rIvlzP4jidGmkzFwCCDlJ3F7qNvBjmHxapXc=;
	b=usW2kxACESceeVVE3bYXd88l1ng7gAFeWNgkWqWMH2pGakDJmCxQQWDP0VlASbuWxs
	w6CfCwKM4wzM2Oo95O4m2/lZRGSffi0KN+lu6f7JONJNOFLpg7wzvpB/i+5cj9tmFoPe
	cZSYqE5ce+ocR7bCQhMLrSDwmolFMRB27fILYqvGTp4cfb4If5r2kKWFAQ2wv9F21+sg
	Co4/vnbMw7wEJo50v+A1E7v1xPGyUI1TKYH5KBnZDdA+VhnhLQpbQttoGCa05CPNNtEi
	hjEoGT8xi+9LrPrSkLkMuq1JfunW8Vjd2/KzXIX4ACBENaNuGwK7yyp8LO1STHvveHLN
	WFeQ==
X-Received: by 10.152.43.229 with SMTP id z5mr50179206lal.86.1415017341587;
	Mon, 03 Nov 2014 04:22:21 -0800 (PST)
Received: from [192.168.10.150] (net-37-117-142-149.cust.vodafonedsl.it.
	[37.117.142.149])
	by mx.google.com with ESMTPSA id f2sm3329672lbk.20.2014.11.03.04.22.19
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 04:22:20 -0800 (PST)
Message-ID: <54577379.3060009@redhat.com>
Date: Mon, 03 Nov 2014 13:22:17 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.xen.devel,gmane.comp.emulators.qemu
To: Quan Xu <quan.xu@intel.com>, qemu-devel@nongnu.org
References: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
Cc: aliguori@amazon.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is
 initialized before tpm_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 02/11/2014 07:39, Quan Xu wrote:
> make sure QEMU machine class is initialized and QEMU has registered
> Xen stubdom vTPM driver when call tpm_init() [vl.c]
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  vl.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/vl.c b/vl.c
> index f6b3546..dd437e1 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4114,12 +4114,6 @@ int main(int argc, char **argv, char **envp)
>          exit(1);
>      }
>  
> -#ifdef CONFIG_TPM
> -    if (tpm_init() < 0) {
> -        exit(1);
> -    }
> -#endif
> -
>      /* init the bluetooth world */
>      if (foreach_device_config(DEV_BT, bt_parse))
>          exit(1);
> @@ -4225,6 +4219,16 @@ int main(int argc, char **argv, char **envp)
>              exit(1);
>      }
>  
> +    /* For compatible with Xen stubdom vTPM driver, make
> +     * sure QEMU machine class is initialized and QEMU has
> +     * registered Xen stubdom vTPM driver ..
> +    */
> +#ifdef CONFIG_TPM
> +    if (tpm_init() < 0) {
> +        exit(1);
> +    }
> +#endif
> +
>      /* init generic devices */
>      if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func, NULL, 1) != 0)
>          exit(1);
> 

Assuming you tested the non-Xen TPM backend, this is okay.

Paolo

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:22:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:22:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGeQ-0000sK-4N; Mon, 03 Nov 2014 12:22:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1XlGeO-0000rn-8K
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 12:22:24 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E8/7D-27584-F7377545; Mon, 03 Nov 2014 12:22:23 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415017341!10845115!1
X-Originating-IP: [209.85.217.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12093 invoked from network); 3 Nov 2014 12:22:22 -0000
Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com)
	(209.85.217.178)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 12:22:22 -0000
Received: by mail-lb0-f178.google.com with SMTP id f15so10117544lbj.23
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 04:22:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=D/hQsp9rIvlzP4jidGmkzFwCCDlJ3F7qNvBjmHxapXc=;
	b=usW2kxACESceeVVE3bYXd88l1ng7gAFeWNgkWqWMH2pGakDJmCxQQWDP0VlASbuWxs
	w6CfCwKM4wzM2Oo95O4m2/lZRGSffi0KN+lu6f7JONJNOFLpg7wzvpB/i+5cj9tmFoPe
	cZSYqE5ce+ocR7bCQhMLrSDwmolFMRB27fILYqvGTp4cfb4If5r2kKWFAQ2wv9F21+sg
	Co4/vnbMw7wEJo50v+A1E7v1xPGyUI1TKYH5KBnZDdA+VhnhLQpbQttoGCa05CPNNtEi
	hjEoGT8xi+9LrPrSkLkMuq1JfunW8Vjd2/KzXIX4ACBENaNuGwK7yyp8LO1STHvveHLN
	WFeQ==
X-Received: by 10.152.43.229 with SMTP id z5mr50179206lal.86.1415017341587;
	Mon, 03 Nov 2014 04:22:21 -0800 (PST)
Received: from [192.168.10.150] (net-37-117-142-149.cust.vodafonedsl.it.
	[37.117.142.149])
	by mx.google.com with ESMTPSA id f2sm3329672lbk.20.2014.11.03.04.22.19
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 04:22:20 -0800 (PST)
Message-ID: <54577379.3060009@redhat.com>
Date: Mon, 03 Nov 2014 13:22:17 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.xen.devel,gmane.comp.emulators.qemu
To: Quan Xu <quan.xu@intel.com>, qemu-devel@nongnu.org
References: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
Cc: aliguori@amazon.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is
 initialized before tpm_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 02/11/2014 07:39, Quan Xu wrote:
> make sure QEMU machine class is initialized and QEMU has registered
> Xen stubdom vTPM driver when call tpm_init() [vl.c]
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  vl.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/vl.c b/vl.c
> index f6b3546..dd437e1 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4114,12 +4114,6 @@ int main(int argc, char **argv, char **envp)
>          exit(1);
>      }
>  
> -#ifdef CONFIG_TPM
> -    if (tpm_init() < 0) {
> -        exit(1);
> -    }
> -#endif
> -
>      /* init the bluetooth world */
>      if (foreach_device_config(DEV_BT, bt_parse))
>          exit(1);
> @@ -4225,6 +4219,16 @@ int main(int argc, char **argv, char **envp)
>              exit(1);
>      }
>  
> +    /* For compatible with Xen stubdom vTPM driver, make
> +     * sure QEMU machine class is initialized and QEMU has
> +     * registered Xen stubdom vTPM driver ..
> +    */
> +#ifdef CONFIG_TPM
> +    if (tpm_init() < 0) {
> +        exit(1);
> +    }
> +#endif
> +
>      /* init generic devices */
>      if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func, NULL, 1) != 0)
>          exit(1);
> 

Assuming you tested the non-Xen TPM backend, this is okay.

Paolo

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:22:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:22:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGeZ-0000up-HB; Mon, 03 Nov 2014 12:22:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1XlGeX-0000uH-DZ
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 12:22:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B7/9F-09842-88377545; Mon, 03 Nov 2014 12:22:32 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415017351!12347698!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14729 invoked from network); 3 Nov 2014 12:22:32 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 12:22:32 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1XlGeU-0003iv-8E
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:22:30 +0100
Received: from net-37-117-142-149.cust.vodafonedsl.it ([37.117.142.149])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 03 Nov 2014 13:22:30 +0100
Received: from pbonzini by net-37-117-142-149.cust.vodafonedsl.it with local
	(Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 03 Nov 2014 13:22:30 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Mon, 03 Nov 2014 13:22:17 +0100
Lines: 48
Message-ID: <54577379.3060009@redhat.com>
References: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
Mime-Version: 1.0
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: net-37-117-142-149.cust.vodafonedsl.it
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
In-Reply-To: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is
 initialized before tpm_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 02/11/2014 07:39, Quan Xu wrote:
> make sure QEMU machine class is initialized and QEMU has registered
> Xen stubdom vTPM driver when call tpm_init() [vl.c]
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  vl.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/vl.c b/vl.c
> index f6b3546..dd437e1 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4114,12 +4114,6 @@ int main(int argc, char **argv, char **envp)
>          exit(1);
>      }
>  
> -#ifdef CONFIG_TPM
> -    if (tpm_init() < 0) {
> -        exit(1);
> -    }
> -#endif
> -
>      /* init the bluetooth world */
>      if (foreach_device_config(DEV_BT, bt_parse))
>          exit(1);
> @@ -4225,6 +4219,16 @@ int main(int argc, char **argv, char **envp)
>              exit(1);
>      }
>  
> +    /* For compatible with Xen stubdom vTPM driver, make
> +     * sure QEMU machine class is initialized and QEMU has
> +     * registered Xen stubdom vTPM driver ..
> +    */
> +#ifdef CONFIG_TPM
> +    if (tpm_init() < 0) {
> +        exit(1);
> +    }
> +#endif
> +
>      /* init generic devices */
>      if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func, NULL, 1) != 0)
>          exit(1);
> 

Assuming you tested the non-Xen TPM backend, this is okay.

Paolo


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:22:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:22:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGeZ-0000up-HB; Mon, 03 Nov 2014 12:22:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1XlGeX-0000uH-DZ
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 12:22:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B7/9F-09842-88377545; Mon, 03 Nov 2014 12:22:32 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415017351!12347698!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14729 invoked from network); 3 Nov 2014 12:22:32 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 12:22:32 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1XlGeU-0003iv-8E
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:22:30 +0100
Received: from net-37-117-142-149.cust.vodafonedsl.it ([37.117.142.149])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 03 Nov 2014 13:22:30 +0100
Received: from pbonzini by net-37-117-142-149.cust.vodafonedsl.it with local
	(Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 03 Nov 2014 13:22:30 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Mon, 03 Nov 2014 13:22:17 +0100
Lines: 48
Message-ID: <54577379.3060009@redhat.com>
References: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
Mime-Version: 1.0
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: net-37-117-142-149.cust.vodafonedsl.it
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
In-Reply-To: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is
 initialized before tpm_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 02/11/2014 07:39, Quan Xu wrote:
> make sure QEMU machine class is initialized and QEMU has registered
> Xen stubdom vTPM driver when call tpm_init() [vl.c]
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  vl.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/vl.c b/vl.c
> index f6b3546..dd437e1 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4114,12 +4114,6 @@ int main(int argc, char **argv, char **envp)
>          exit(1);
>      }
>  
> -#ifdef CONFIG_TPM
> -    if (tpm_init() < 0) {
> -        exit(1);
> -    }
> -#endif
> -
>      /* init the bluetooth world */
>      if (foreach_device_config(DEV_BT, bt_parse))
>          exit(1);
> @@ -4225,6 +4219,16 @@ int main(int argc, char **argv, char **envp)
>              exit(1);
>      }
>  
> +    /* For compatible with Xen stubdom vTPM driver, make
> +     * sure QEMU machine class is initialized and QEMU has
> +     * registered Xen stubdom vTPM driver ..
> +    */
> +#ifdef CONFIG_TPM
> +    if (tpm_init() < 0) {
> +        exit(1);
> +    }
> +#endif
> +
>      /* init generic devices */
>      if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func, NULL, 1) != 0)
>          exit(1);
> 

Assuming you tested the non-Xen TPM backend, this is okay.

Paolo


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:35:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12: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 1XlGqg-0001Yl-4u; Mon, 03 Nov 2014 12:35:06 +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 1XlGqe-0001Yg-Og
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 12:35:04 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	E7/3D-02559-87677545; Mon, 03 Nov 2014 12:35:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415018103!12210705!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23281 invoked from network); 3 Nov 2014 12:35:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 12:35:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 12:35:02 +0000
Message-Id: <545784830200007800044627@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 12:34:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
In-Reply-To: <54576DF7.8060408@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 12:58, <tiejun.chen@intel.com> wrote:
> Firstly we have a rule that we just allow all devices associated one 
> RMRR to be assign same VM, right? So I mean while we create VM, we 
> always call current hypercall but inside hypercall, Xen can know which 
> devices will be assigned to this VM.

I.e. the hypercall (at least optionally) becomes per-domain rather
than global. And you imply that device assignment happens
before memory getting populated (which likely can be arranged
for in the tool stack if that's not already the case, but which isn't
currently mandated by the hypervisor).

Jan

> So Xen still lookup that RMRR list 
> but now Xen would check if these RMRR belongs to that device we want to 
> assign this domain. If yes, we just let that callback go through these 
> RMRR info from that list but exclude other unrelated RMRR. If not, we 
> don't go through any RMRR info so that 'nr_entries' is also zero.
> 
> Thanks
> Tiejun



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:35:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12: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 1XlGqg-0001Yl-4u; Mon, 03 Nov 2014 12:35:06 +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 1XlGqe-0001Yg-Og
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 12:35:04 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	E7/3D-02559-87677545; Mon, 03 Nov 2014 12:35:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415018103!12210705!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23281 invoked from network); 3 Nov 2014 12:35:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 12:35:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 12:35:02 +0000
Message-Id: <545784830200007800044627@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 12:34:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
In-Reply-To: <54576DF7.8060408@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 12:58, <tiejun.chen@intel.com> wrote:
> Firstly we have a rule that we just allow all devices associated one 
> RMRR to be assign same VM, right? So I mean while we create VM, we 
> always call current hypercall but inside hypercall, Xen can know which 
> devices will be assigned to this VM.

I.e. the hypercall (at least optionally) becomes per-domain rather
than global. And you imply that device assignment happens
before memory getting populated (which likely can be arranged
for in the tool stack if that's not already the case, but which isn't
currently mandated by the hypervisor).

Jan

> So Xen still lookup that RMRR list 
> but now Xen would check if these RMRR belongs to that device we want to 
> assign this domain. If yes, we just let that callback go through these 
> RMRR info from that list but exclude other unrelated RMRR. If not, we 
> don't go through any RMRR info so that 'nr_entries' is also zero.
> 
> Thanks
> Tiejun



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:37:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:37:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGt9-0001fQ-OO; Mon, 03 Nov 2014 12:37:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1XlGt7-0001fI-SH
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 12:37:38 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	6D/35-29352-11777545; Mon, 03 Nov 2014 12:37:37 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415018254!3284628!1
X-Originating-IP: [209.85.213.178]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11116 invoked from network); 3 Nov 2014 12:37:35 -0000
Received: from mail-ig0-f178.google.com (HELO mail-ig0-f178.google.com)
	(209.85.213.178)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 12:37:35 -0000
Received: by mail-ig0-f178.google.com with SMTP id a13so4466541igq.11
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 04:37:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=7DtYnVVk6O6yQQIIhdFUlVhXFhRoQKo4tNmljfXOPgU=;
	b=hn78CD5nDbrvGJgBd2tnbeMYuI+rANIdhsucRTI1kB8AzkbgkKvFXbLoPp38Xg3tnn
	nTKUnW86AELlUH0agsYtDPvB/gb+mYCx7LhK2577pQm/CeQEkWc4kKH8WrFX7ZCyWo0x
	a55ru0Aveyp0Mm26pTJVsFcLibzDAXW/r0bsQB4vwTsVi1IXn55V+FVRSvfaAtCvpuAE
	pBGZqsqkOfg+sbMSBkDkDyMAlVuR4c+rYFxO+WEihq3cLIXQ2WfZVVbyvnh1KokhKs4P
	VG/eGBg7p4ixuSLwjo1U4+Zgv12hF77zi9R/O4XKuciHfeyZmnF3sSsi6KGJEPTWYYPI
	q57Q==
MIME-Version: 1.0
X-Received: by 10.42.167.1 with SMTP id q1mr39548306icy.48.1415018253749; Mon,
	03 Nov 2014 04:37:33 -0800 (PST)
Received: by 10.64.121.194 with HTTP; Mon, 3 Nov 2014 04:37:33 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
Date: Mon, 3 Nov 2014 18:07:33 +0530
Message-ID: <CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
From: Vijay Kilari <vijay.kilari@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 3, 2014 at 4:31 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Sat, 1 Nov 2014, Julien Grall wrote:
>> The vGIC will emulate the same version as the hardware. The toolstack has
>> to retrieve the version of the vGIC in order to be able to create the
>> corresponding device tree node.
>>
>> A new DOMCTL has been introduced for ARM to configure the domain. For now
>> it only allow the toolstack to retrieve the version of vGIC.
>> This DOMCTL will be extend later to let the user choose the version of the
>> emulated GIC.
>>
>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Jan Beulich <jbeulich@suse.com>
>> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Cc: Wei Liu <wei.liu2@citrix.com>
>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Tested with GICv3 platform.

>
>
>>     Changes in v2:
>>         - Use memcpu in xc_domain_configure
>>         - Rename the DOMCTL into domctl_arm_configuredomain
>>         - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>>         and fold the code in arch_domain_init_hw_description
>>         - Return -EOPNOTSUPP when the value of gic_version is not
>>         supported
>>
>> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
>> defer the initialization of the vGIC [2].
>>
>> Xen 4.5 has already support for the hardware GICv3. While it's possible to
>> boot and use DOM0, there is no guest support. The first version of this patch
>> has been sent a couple of months ago, but has never reached unstable for
>> various reasons (based on deferred series, lake of review at that time...).
>> Without it, platform with GICv3 support won't be able to boot any guest.
>>
>> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
>> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
>>
>> Features such as adding a new config option to let the user choose the GIC
>> version are deferred to Xen 4.6.
>>
>> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
>>
>> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
>> [2] https://patches.linaro.org/34664/
>> ---
>>  tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>>  tools/libxc/include/xenctrl.h                |    6 ++
>>  tools/libxc/xc_domain.c                      |   20 ++++++
>>  tools/libxl/libxl_arm.c                      |   97 ++++++++++++++++++++++++--
>>  xen/arch/arm/domctl.c                        |   35 ++++++++++
>>  xen/arch/arm/gic-v3.c                        |   16 ++++-
>>  xen/include/public/arch-arm.h                |   16 +++++
>>  xen/include/public/domctl.h                  |   17 +++++
>>  xen/xsm/flask/hooks.c                        |    3 +
>>  xen/xsm/flask/policy/access_vectors          |    2 +
>>  10 files changed, 206 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
>> index 641c797..fa69c9d 100644
>> --- a/tools/flask/policy/policy/modules/xen/xen.if
>> +++ b/tools/flask/policy/policy/modules/xen/xen.if
>> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>>                       getdomaininfo hypercall setvcpucontext setextvcpucontext
>>                       getscheduler getvcpuinfo getvcpuextstate getaddrsize
>>                       getaffinity setaffinity };
>> -     allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
>> +     allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>>       allow $1 $2:security check_context;
>>       allow $1 $2:shadow enable;
>>       allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 564e187..45e282c 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>>                       uint32_t flags,
>>                       uint32_t *pdomid);
>>
>> +#if defined(__arm__) || defined(__aarch64__)
>> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
>> +
>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>> +                        xc_domain_configuration_t *config);
>> +#endif
>>
>>  /* Functions to produce a dump of a given domain
>>   *  xc_domain_dumpcore - produces a dump to a specified file
>> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
>> index a9bcd4a..1aa1f45 100644
>> --- a/tools/libxc/xc_domain.c
>> +++ b/tools/libxc/xc_domain.c
>> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>>      return 0;
>>  }
>>
>> +#if defined(__arm__) || defined(__aarch64__)
>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>> +                        xc_domain_configuration_t *config)
>> +{
>> +    int rc;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
>> +    domctl.domain = (domid_t)domid;
>> +    /* xc_domain_configure_t is an alias to xen_domctl_arm_configuredomain */
>> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
>> +
>> +    rc = do_domctl(xch, &domctl);
>> +    if ( !rc )
>> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
>> +
>> +    return rc;
>> +}
>> +#endif
>> +
>>  int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
>>                           xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
>>  {
>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> index a122e4a..3dd6e7c 100644
>> --- a/tools/libxl/libxl_arm.c
>> +++ b/tools/libxl/libxl_arm.c
>> @@ -23,6 +23,18 @@
>>  #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
>>  #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
>>
>> +static const char *gicv_to_string(uint8_t gic_version)
>> +{
>> +    switch (gic_version) {
>> +    case XEN_DOMCTL_CONFIG_GIC_V2:
>> +        return "V2";
>> +    case XEN_DOMCTL_CONFIG_GIC_V3:
>> +        return "V3";
>> +    default:
>> +        return "unknown";
>> +    }
>> +}
>> +
>>  int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>>                                uint32_t domid)
>>  {
>> @@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
>>      return 0;
>>  }
>>
>> -static int make_intc_node(libxl__gc *gc, void *fdt,
>> -                          uint64_t gicd_base, uint64_t gicd_size,
>> -                          uint64_t gicc_base, uint64_t gicc_size)
>> +static int make_gicv2_node(libxl__gc *gc, void *fdt,
>> +                           uint64_t gicd_base, uint64_t gicd_size,
>> +                           uint64_t gicc_base, uint64_t gicc_size)
>>  {
>>      int res;
>>      const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
>> @@ -350,6 +362,57 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
>>      return 0;
>>  }
>>
>> +static int make_gicv3_node(libxl__gc *gc, void *fdt)
>> +{
>> +    int res;
>> +    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
>> +    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
>> +    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
>> +    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
>> +    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
>> +
>> +    res = fdt_begin_node(fdt, name);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_compat(gc, fdt, 1,
>> +                              "arm,gic-v3");
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "#address-cells", 0);
>> +    if (res) return res;
>> +
>> +    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "redistributor-stride",
>> +                            GUEST_GICV3_RDIST_STRIDE);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "#redistributor-regions",
>> +                            GUEST_GICV3_RDIST_REGIONS);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
>> +                            2,
>> +                            gicd_base, gicd_size,
>> +                            gicr0_base, gicr0_size);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
>> +    if (res) return res;
>> +
>> +    res = fdt_end_node(fdt);
>> +    if (res) return res;
>> +
>> +    return 0;
>> +}
>> +
>>  static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
>>  {
>>      int res;
>> @@ -456,6 +519,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>>                                             libxl_domain_build_info *info,
>>                                             struct xc_dom_image *dom)
>>  {
>> +    xc_domain_configuration_t config;
>>      void *fdt = NULL;
>>      int rc, res;
>>      size_t fdt_size = 0;
>> @@ -471,8 +535,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>>      ainfo = get_arch_info(gc, dom);
>>      if (ainfo == NULL) return ERROR_FAIL;
>>
>> +    LOG(DEBUG, "configure the domain");
>> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
>> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
>> +        LOG(ERROR, "counldn't configure the domain");
>> +        return ERROR_FAIL;
>> +    }
>> +
>>      LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
>>          vers->xen_version_major, vers->xen_version_minor);
>> +    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
>>
>>  /*
>>   * Call "call" handling FDR_ERR_*. Will either:
>> @@ -520,9 +592,22 @@ next_resize:
>>          FDT( make_psci_node(gc, fdt) );
>>
>>          FDT( make_memory_nodes(gc, fdt, dom) );
>> -        FDT( make_intc_node(gc, fdt,
>> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
>> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
>> +
>> +        switch (config.gic_version) {
>> +        case XEN_DOMCTL_CONFIG_GIC_V2:
>> +            FDT( make_gicv2_node(gc, fdt,
>> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
>> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
>> +            break;
>> +        case XEN_DOMCTL_CONFIG_GIC_V3:
>> +            FDT( make_gicv3_node(gc, fdt) );
>> +            break;
>> +        default:
>> +            LOG(ERROR, "Unknown how to create the DT node for gic_version = %d",
>> +                config.gic_version);
>> +            rc = ERROR_FAIL;
>> +            goto out;
>> +        }
>>
>>          FDT( make_timer_node(gc, fdt, ainfo) );
>>          FDT( make_hypervisor_node(gc, fdt, vers) );
>> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
>> index 45974e7..5b8ff57 100644
>> --- a/xen/arch/arm/domctl.c
>> +++ b/xen/arch/arm/domctl.c
>> @@ -10,6 +10,8 @@
>>  #include <xen/errno.h>
>>  #include <xen/sched.h>
>>  #include <xen/hypercall.h>
>> +#include <asm/gic.h>
>> +#include <xen/guest_access.h>
>>  #include <public/domctl.h>
>>
>>  long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>
>>          return p2m_cache_flush(d, s, e);
>>      }
>> +    case XEN_DOMCTL_arm_configure_domain:
>> +    {
>> +        uint8_t gic_version;
>> +
>> +        /*
>> +         * Xen 4.5: The vGIC is emulating the same version of the
>> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
>> +         * is allowed. The DOMCTL will return the actual version of the
>> +         * GIC.
>> +         */
>> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
>> +            return -EOPNOTSUPP;
>> +
>> +        switch ( gic_hw_version() )
>> +        {
>> +        case GIC_V3:
>> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
>> +            break;
>> +        case GIC_V2:
>> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
>> +            break;
>> +        default:
>> +            BUG();
>> +        }
>> +
>> +        domctl->u.configuredomain.gic_version = gic_version;
>> +
>> +        /* TODO: Make the copy generic for all ARCH domctl */
>> +        if ( __copy_to_guest(u_domctl, domctl, 1) )
>> +            return -EFAULT;
>> +
>> +        return 0;
>> +    }
>>
>>      default:
>>          return subarch_do_domctl(domctl, d, u_domctl);
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index 91161a2..076aa62 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
>>          d->arch.vgic.rdist_count = gicv3.rdist_count;
>>      }
>>      else
>> -        d->arch.vgic.dbase = GUEST_GICD_BASE;
>> +    {
>> +        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
>> +        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
>> +
>> +        /* XXX: Only one Re-distributor region mapped for the guest */
>> +        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
>> +
>> +        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
>> +        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
>> +
>> +        /* The first redistributor should contain enough space for all CPUs */
>> +        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
>> +        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
>> +        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
>> +    }
>>
>>      d->arch.vgic.nr_lines = 0;
>>
>> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>> index eecc561..d7df274 100644
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
>>   */
>>
>>  /* Physical Address Space */
>> +
>> +/* vGIC mappings: Only one set of mapping is used by the guest.
>> + * Therefore they can overlap.
>> + */
>> +
>> +/* vGIC v2 mappings */
>>  #define GUEST_GICD_BASE   0x03001000ULL
>>  #define GUEST_GICD_SIZE   0x00001000ULL
>>  #define GUEST_GICC_BASE   0x03002000ULL
>>  #define GUEST_GICC_SIZE   0x00000100ULL
>>
>> +/* vGIC v3 mappings */
>> +#define GUEST_GICV3_GICD_BASE      0x03001000ULL
>> +#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
>> +
>> +#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
>> +#define GUEST_GICV3_RDIST_REGIONS  1
>> +
>> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */
>> +#define GUEST_GICV3_GICR0_SIZE     0x00200000ULL
>> +
>>  /* 16MB == 4096 pages reserved for guest to use as a region to map its
>>   * grant table in.
>>   */
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index 58b19e7..8da204e 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
>>  typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
>>
>> +#if defined(__arm__) || defined(__aarch64__)
>> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
>> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
>> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
>> +/* XEN_DOMCTL_configure_domain */
>> +struct xen_domctl_arm_configuredomain {
>> +    /* IN/OUT parameters */
>> +    uint8_t gic_version;
>> +};
>> +typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
>> +#endif
>> +
>>  /* XEN_DOMCTL_getdomaininfo */
>>  struct xen_domctl_getdomaininfo {
>>      /* OUT variables. */
>> @@ -1056,6 +1069,7 @@ struct xen_domctl {
>>  #define XEN_DOMCTL_set_vcpu_msrs                 73
>>  #define XEN_DOMCTL_setvnumainfo                  74
>>  #define XEN_DOMCTL_psr_cmt_op                    75
>> +#define XEN_DOMCTL_arm_configure_domain          76
>>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
>> @@ -1064,6 +1078,9 @@ struct xen_domctl {
>>      domid_t  domain;
>>      union {
>>          struct xen_domctl_createdomain      createdomain;
>> +#if defined(__arm__) || defined(__aarch64__)
>> +        struct xen_domctl_arm_configuredomain configuredomain;
>> +#endif
>>          struct xen_domctl_getdomaininfo     getdomaininfo;
>>          struct xen_domctl_getmemlist        getmemlist;
>>          struct xen_domctl_getpageframeinfo  getpageframeinfo;
>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>> index 6d0fe72..846cf88 100644
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
>>      case XEN_DOMCTL_psr_cmt_op:
>>          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
>>
>> +    case XEN_DOMCTL_configure_domain:
>> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
>> +
>>      default:
>>          printk("flask_domctl: Unknown op %d\n", cmd);
>>          return -EPERM;
>> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
>> index de0c707..bfe2fa5 100644
>> --- a/xen/xsm/flask/policy/access_vectors
>> +++ b/xen/xsm/flask/policy/access_vectors
>> @@ -216,6 +216,8 @@ class domain2
>>      get_vnumainfo
>>  # XEN_DOMCTL_psr_cmt_op
>>      psr_cmt_op
>> +# XEN_DOMCTL_configure_domain
>> +    configure_domain
>>  }
>>
>>  # Similar to class domain, but primarily contains domctls related to HVM domains
>> --
>> 1.7.10.4
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:37:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:37:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlGt9-0001fQ-OO; Mon, 03 Nov 2014 12:37:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1XlGt7-0001fI-SH
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 12:37:38 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	6D/35-29352-11777545; Mon, 03 Nov 2014 12:37:37 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415018254!3284628!1
X-Originating-IP: [209.85.213.178]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11116 invoked from network); 3 Nov 2014 12:37:35 -0000
Received: from mail-ig0-f178.google.com (HELO mail-ig0-f178.google.com)
	(209.85.213.178)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 12:37:35 -0000
Received: by mail-ig0-f178.google.com with SMTP id a13so4466541igq.11
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 04:37:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=7DtYnVVk6O6yQQIIhdFUlVhXFhRoQKo4tNmljfXOPgU=;
	b=hn78CD5nDbrvGJgBd2tnbeMYuI+rANIdhsucRTI1kB8AzkbgkKvFXbLoPp38Xg3tnn
	nTKUnW86AELlUH0agsYtDPvB/gb+mYCx7LhK2577pQm/CeQEkWc4kKH8WrFX7ZCyWo0x
	a55ru0Aveyp0Mm26pTJVsFcLibzDAXW/r0bsQB4vwTsVi1IXn55V+FVRSvfaAtCvpuAE
	pBGZqsqkOfg+sbMSBkDkDyMAlVuR4c+rYFxO+WEihq3cLIXQ2WfZVVbyvnh1KokhKs4P
	VG/eGBg7p4ixuSLwjo1U4+Zgv12hF77zi9R/O4XKuciHfeyZmnF3sSsi6KGJEPTWYYPI
	q57Q==
MIME-Version: 1.0
X-Received: by 10.42.167.1 with SMTP id q1mr39548306icy.48.1415018253749; Mon,
	03 Nov 2014 04:37:33 -0800 (PST)
Received: by 10.64.121.194 with HTTP; Mon, 3 Nov 2014 04:37:33 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
Date: Mon, 3 Nov 2014 18:07:33 +0530
Message-ID: <CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
From: Vijay Kilari <vijay.kilari@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 3, 2014 at 4:31 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Sat, 1 Nov 2014, Julien Grall wrote:
>> The vGIC will emulate the same version as the hardware. The toolstack has
>> to retrieve the version of the vGIC in order to be able to create the
>> corresponding device tree node.
>>
>> A new DOMCTL has been introduced for ARM to configure the domain. For now
>> it only allow the toolstack to retrieve the version of vGIC.
>> This DOMCTL will be extend later to let the user choose the version of the
>> emulated GIC.
>>
>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Jan Beulich <jbeulich@suse.com>
>> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Cc: Wei Liu <wei.liu2@citrix.com>
>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Tested with GICv3 platform.

>
>
>>     Changes in v2:
>>         - Use memcpu in xc_domain_configure
>>         - Rename the DOMCTL into domctl_arm_configuredomain
>>         - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>>         and fold the code in arch_domain_init_hw_description
>>         - Return -EOPNOTSUPP when the value of gic_version is not
>>         supported
>>
>> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
>> defer the initialization of the vGIC [2].
>>
>> Xen 4.5 has already support for the hardware GICv3. While it's possible to
>> boot and use DOM0, there is no guest support. The first version of this patch
>> has been sent a couple of months ago, but has never reached unstable for
>> various reasons (based on deferred series, lake of review at that time...).
>> Without it, platform with GICv3 support won't be able to boot any guest.
>>
>> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
>> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
>>
>> Features such as adding a new config option to let the user choose the GIC
>> version are deferred to Xen 4.6.
>>
>> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
>>
>> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
>> [2] https://patches.linaro.org/34664/
>> ---
>>  tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>>  tools/libxc/include/xenctrl.h                |    6 ++
>>  tools/libxc/xc_domain.c                      |   20 ++++++
>>  tools/libxl/libxl_arm.c                      |   97 ++++++++++++++++++++++++--
>>  xen/arch/arm/domctl.c                        |   35 ++++++++++
>>  xen/arch/arm/gic-v3.c                        |   16 ++++-
>>  xen/include/public/arch-arm.h                |   16 +++++
>>  xen/include/public/domctl.h                  |   17 +++++
>>  xen/xsm/flask/hooks.c                        |    3 +
>>  xen/xsm/flask/policy/access_vectors          |    2 +
>>  10 files changed, 206 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
>> index 641c797..fa69c9d 100644
>> --- a/tools/flask/policy/policy/modules/xen/xen.if
>> +++ b/tools/flask/policy/policy/modules/xen/xen.if
>> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>>                       getdomaininfo hypercall setvcpucontext setextvcpucontext
>>                       getscheduler getvcpuinfo getvcpuextstate getaddrsize
>>                       getaffinity setaffinity };
>> -     allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
>> +     allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>>       allow $1 $2:security check_context;
>>       allow $1 $2:shadow enable;
>>       allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 564e187..45e282c 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>>                       uint32_t flags,
>>                       uint32_t *pdomid);
>>
>> +#if defined(__arm__) || defined(__aarch64__)
>> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
>> +
>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>> +                        xc_domain_configuration_t *config);
>> +#endif
>>
>>  /* Functions to produce a dump of a given domain
>>   *  xc_domain_dumpcore - produces a dump to a specified file
>> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
>> index a9bcd4a..1aa1f45 100644
>> --- a/tools/libxc/xc_domain.c
>> +++ b/tools/libxc/xc_domain.c
>> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>>      return 0;
>>  }
>>
>> +#if defined(__arm__) || defined(__aarch64__)
>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>> +                        xc_domain_configuration_t *config)
>> +{
>> +    int rc;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
>> +    domctl.domain = (domid_t)domid;
>> +    /* xc_domain_configure_t is an alias to xen_domctl_arm_configuredomain */
>> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
>> +
>> +    rc = do_domctl(xch, &domctl);
>> +    if ( !rc )
>> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
>> +
>> +    return rc;
>> +}
>> +#endif
>> +
>>  int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
>>                           xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
>>  {
>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> index a122e4a..3dd6e7c 100644
>> --- a/tools/libxl/libxl_arm.c
>> +++ b/tools/libxl/libxl_arm.c
>> @@ -23,6 +23,18 @@
>>  #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
>>  #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
>>
>> +static const char *gicv_to_string(uint8_t gic_version)
>> +{
>> +    switch (gic_version) {
>> +    case XEN_DOMCTL_CONFIG_GIC_V2:
>> +        return "V2";
>> +    case XEN_DOMCTL_CONFIG_GIC_V3:
>> +        return "V3";
>> +    default:
>> +        return "unknown";
>> +    }
>> +}
>> +
>>  int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>>                                uint32_t domid)
>>  {
>> @@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
>>      return 0;
>>  }
>>
>> -static int make_intc_node(libxl__gc *gc, void *fdt,
>> -                          uint64_t gicd_base, uint64_t gicd_size,
>> -                          uint64_t gicc_base, uint64_t gicc_size)
>> +static int make_gicv2_node(libxl__gc *gc, void *fdt,
>> +                           uint64_t gicd_base, uint64_t gicd_size,
>> +                           uint64_t gicc_base, uint64_t gicc_size)
>>  {
>>      int res;
>>      const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
>> @@ -350,6 +362,57 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
>>      return 0;
>>  }
>>
>> +static int make_gicv3_node(libxl__gc *gc, void *fdt)
>> +{
>> +    int res;
>> +    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
>> +    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
>> +    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
>> +    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
>> +    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
>> +
>> +    res = fdt_begin_node(fdt, name);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_compat(gc, fdt, 1,
>> +                              "arm,gic-v3");
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "#address-cells", 0);
>> +    if (res) return res;
>> +
>> +    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "redistributor-stride",
>> +                            GUEST_GICV3_RDIST_STRIDE);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "#redistributor-regions",
>> +                            GUEST_GICV3_RDIST_REGIONS);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
>> +                            2,
>> +                            gicd_base, gicd_size,
>> +                            gicr0_base, gicr0_size);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
>> +    if (res) return res;
>> +
>> +    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
>> +    if (res) return res;
>> +
>> +    res = fdt_end_node(fdt);
>> +    if (res) return res;
>> +
>> +    return 0;
>> +}
>> +
>>  static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
>>  {
>>      int res;
>> @@ -456,6 +519,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>>                                             libxl_domain_build_info *info,
>>                                             struct xc_dom_image *dom)
>>  {
>> +    xc_domain_configuration_t config;
>>      void *fdt = NULL;
>>      int rc, res;
>>      size_t fdt_size = 0;
>> @@ -471,8 +535,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>>      ainfo = get_arch_info(gc, dom);
>>      if (ainfo == NULL) return ERROR_FAIL;
>>
>> +    LOG(DEBUG, "configure the domain");
>> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
>> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
>> +        LOG(ERROR, "counldn't configure the domain");
>> +        return ERROR_FAIL;
>> +    }
>> +
>>      LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
>>          vers->xen_version_major, vers->xen_version_minor);
>> +    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
>>
>>  /*
>>   * Call "call" handling FDR_ERR_*. Will either:
>> @@ -520,9 +592,22 @@ next_resize:
>>          FDT( make_psci_node(gc, fdt) );
>>
>>          FDT( make_memory_nodes(gc, fdt, dom) );
>> -        FDT( make_intc_node(gc, fdt,
>> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
>> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
>> +
>> +        switch (config.gic_version) {
>> +        case XEN_DOMCTL_CONFIG_GIC_V2:
>> +            FDT( make_gicv2_node(gc, fdt,
>> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
>> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
>> +            break;
>> +        case XEN_DOMCTL_CONFIG_GIC_V3:
>> +            FDT( make_gicv3_node(gc, fdt) );
>> +            break;
>> +        default:
>> +            LOG(ERROR, "Unknown how to create the DT node for gic_version = %d",
>> +                config.gic_version);
>> +            rc = ERROR_FAIL;
>> +            goto out;
>> +        }
>>
>>          FDT( make_timer_node(gc, fdt, ainfo) );
>>          FDT( make_hypervisor_node(gc, fdt, vers) );
>> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
>> index 45974e7..5b8ff57 100644
>> --- a/xen/arch/arm/domctl.c
>> +++ b/xen/arch/arm/domctl.c
>> @@ -10,6 +10,8 @@
>>  #include <xen/errno.h>
>>  #include <xen/sched.h>
>>  #include <xen/hypercall.h>
>> +#include <asm/gic.h>
>> +#include <xen/guest_access.h>
>>  #include <public/domctl.h>
>>
>>  long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>
>>          return p2m_cache_flush(d, s, e);
>>      }
>> +    case XEN_DOMCTL_arm_configure_domain:
>> +    {
>> +        uint8_t gic_version;
>> +
>> +        /*
>> +         * Xen 4.5: The vGIC is emulating the same version of the
>> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
>> +         * is allowed. The DOMCTL will return the actual version of the
>> +         * GIC.
>> +         */
>> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
>> +            return -EOPNOTSUPP;
>> +
>> +        switch ( gic_hw_version() )
>> +        {
>> +        case GIC_V3:
>> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
>> +            break;
>> +        case GIC_V2:
>> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
>> +            break;
>> +        default:
>> +            BUG();
>> +        }
>> +
>> +        domctl->u.configuredomain.gic_version = gic_version;
>> +
>> +        /* TODO: Make the copy generic for all ARCH domctl */
>> +        if ( __copy_to_guest(u_domctl, domctl, 1) )
>> +            return -EFAULT;
>> +
>> +        return 0;
>> +    }
>>
>>      default:
>>          return subarch_do_domctl(domctl, d, u_domctl);
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index 91161a2..076aa62 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
>>          d->arch.vgic.rdist_count = gicv3.rdist_count;
>>      }
>>      else
>> -        d->arch.vgic.dbase = GUEST_GICD_BASE;
>> +    {
>> +        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
>> +        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
>> +
>> +        /* XXX: Only one Re-distributor region mapped for the guest */
>> +        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
>> +
>> +        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
>> +        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
>> +
>> +        /* The first redistributor should contain enough space for all CPUs */
>> +        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
>> +        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
>> +        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
>> +    }
>>
>>      d->arch.vgic.nr_lines = 0;
>>
>> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>> index eecc561..d7df274 100644
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
>>   */
>>
>>  /* Physical Address Space */
>> +
>> +/* vGIC mappings: Only one set of mapping is used by the guest.
>> + * Therefore they can overlap.
>> + */
>> +
>> +/* vGIC v2 mappings */
>>  #define GUEST_GICD_BASE   0x03001000ULL
>>  #define GUEST_GICD_SIZE   0x00001000ULL
>>  #define GUEST_GICC_BASE   0x03002000ULL
>>  #define GUEST_GICC_SIZE   0x00000100ULL
>>
>> +/* vGIC v3 mappings */
>> +#define GUEST_GICV3_GICD_BASE      0x03001000ULL
>> +#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
>> +
>> +#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
>> +#define GUEST_GICV3_RDIST_REGIONS  1
>> +
>> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */
>> +#define GUEST_GICV3_GICR0_SIZE     0x00200000ULL
>> +
>>  /* 16MB == 4096 pages reserved for guest to use as a region to map its
>>   * grant table in.
>>   */
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index 58b19e7..8da204e 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
>>  typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
>>
>> +#if defined(__arm__) || defined(__aarch64__)
>> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
>> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
>> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
>> +/* XEN_DOMCTL_configure_domain */
>> +struct xen_domctl_arm_configuredomain {
>> +    /* IN/OUT parameters */
>> +    uint8_t gic_version;
>> +};
>> +typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
>> +#endif
>> +
>>  /* XEN_DOMCTL_getdomaininfo */
>>  struct xen_domctl_getdomaininfo {
>>      /* OUT variables. */
>> @@ -1056,6 +1069,7 @@ struct xen_domctl {
>>  #define XEN_DOMCTL_set_vcpu_msrs                 73
>>  #define XEN_DOMCTL_setvnumainfo                  74
>>  #define XEN_DOMCTL_psr_cmt_op                    75
>> +#define XEN_DOMCTL_arm_configure_domain          76
>>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
>> @@ -1064,6 +1078,9 @@ struct xen_domctl {
>>      domid_t  domain;
>>      union {
>>          struct xen_domctl_createdomain      createdomain;
>> +#if defined(__arm__) || defined(__aarch64__)
>> +        struct xen_domctl_arm_configuredomain configuredomain;
>> +#endif
>>          struct xen_domctl_getdomaininfo     getdomaininfo;
>>          struct xen_domctl_getmemlist        getmemlist;
>>          struct xen_domctl_getpageframeinfo  getpageframeinfo;
>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>> index 6d0fe72..846cf88 100644
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
>>      case XEN_DOMCTL_psr_cmt_op:
>>          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
>>
>> +    case XEN_DOMCTL_configure_domain:
>> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
>> +
>>      default:
>>          printk("flask_domctl: Unknown op %d\n", cmd);
>>          return -EPERM;
>> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
>> index de0c707..bfe2fa5 100644
>> --- a/xen/xsm/flask/policy/access_vectors
>> +++ b/xen/xsm/flask/policy/access_vectors
>> @@ -216,6 +216,8 @@ class domain2
>>      get_vnumainfo
>>  # XEN_DOMCTL_psr_cmt_op
>>      psr_cmt_op
>> +# XEN_DOMCTL_configure_domain
>> +    configure_domain
>>  }
>>
>>  # Similar to class domain, but primarily contains domctls related to HVM domains
>> --
>> 1.7.10.4
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 12:50:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:50:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlH5E-00022j-ER; Mon, 03 Nov 2014 12:50:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XlH5C-00022b-Pe
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 12:50:06 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	9E/6B-02559-EF977545; Mon, 03 Nov 2014 12:50:06 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415019005!6805226!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22661 invoked from network); 3 Nov 2014 12:50:05 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-16.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 12:50:05 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XlH5A-0006wP-Aa; Mon, 03 Nov 2014 12:50:04 +0000
Message-ID: <545779FB.7060602@canonical.com>
Date: Mon, 03 Nov 2014 13:50:03 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel@lists.xen.org
References: <54574EA0.5070101@canonical.com>
	<54575E32.6040603@citrix.com>	<545764BB.7080005@canonical.com>
	<54576932.9030803@citrix.com>
In-Reply-To: <54576932.9030803@citrix.com>
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5146011419674642202=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

On 03.11.2014 12:38, Andrew Cooper wrote:
> On 03/11/14 11:19, Stefan Bader wrote:
>> On 03.11.2014 11:51, Andrew Cooper wrote:
>>> On 03/11/14 09:45, Stefan Bader wrote:
>>>> I see the message from the subject on my Intel box whenever a guest =
(iirc even
>>>> dom0) starts up. It is not fatal and everything seems ok. I am just =
curious
>>>> about what might trigger this. The addresses look to be inside the h=
ypervisor
>>>> code. I was wondering whether there is a simple way to figure out wh=
at this
>>>> relates to (likely need to look at the objdump of the unstripped hv =
module).
>>>>
>>>> Or has someone already looked into this and knows what likely is the=
 cause?
>>>>
>>>> -Stefan
>>> Specifically, the message indicates <type of fault>: faulting address=
 ->
>>> fixup address
>>>
>>> It is probably a wrmsr, and a higher logging level will indicate this=
=2E=20
>>> My gut feeling is that it is dom0 attempting to load microcode using =
the
>>> native method.
>>>
>>> ~Andrew
>>>
>> The faulting address in my case seems to be rdmsr_save (xen-4.4.1 base=
), the
>> fixup address somewhere unspecific in hvm.c (not sure whether that mak=
es sense
>> coming from a dom0 startup). I will have to re-compile this with the g=
dprintk
>> enabled to see which MSR that was.
>=20
> The fixup address lives in the .fixup section which is generally linked=

> elsewhere.  See the definition of rdmsr_safe() which does
> section-jumping in the asm statement.
>=20
>>
>> rdmsr_normal:
>>             /* Everyone can read the MSR space. */
>>             /* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR %p.\n",=

>>                         _p(regs->ecx));*/
>>             if ( rdmsr_safe(regs->ecx, msr_content) )
>>                 goto fail;
>>
>> Though likely related to the following WRMSRs following (the addresses=
 differ
>> from the subject I wasn't sure from where exactly I took the others an=
d these
>> are with 4.4.1 and directly after boot):
>=20
> These will most likely be in wrmsr_safe()
>=20
>>
>> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
>> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
>> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
>> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
>> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0=
04281c2001
>> a8168 to 0x004281c200148168.
>> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0=
04281c2001
>> a8168 to 0x004281c2001a0168.
>> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0=
04281c2001
>> a8168 to 0x004201c2001a8168.
>> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
>> (XEN) traps.c:2514:d0 Domain attempted WRMSR 00000000000001b2 from 0x0=
0000000000
>> 00000 to 0x0000000000009600.
>>
>> The 0x1b2 seems to be thermal interrupt control. Cannot find the 0x610=
 right now
>> (need to refresh my docs)...
>>
>=20
> MSR 0x610 is MSR_PKG_POWER_LIMIT on SandyBridge and later.
>=20

After enabling the output for REDMSR as well it looks like the GPF messag=
e is
associated with RDMSR 0x61c (MSR_DRAM_POWER_INFO).

(XEN) traps.c:2606:d0 Domain attempted RDMSR 000000000000061c.
(XEN) traps.c:3071: GPF (0000): ffff82d08018ef37 -> ffff82d080222685




--L8kKQa9TP3MWoCC0kccNHPM3NH9EGtr1N
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

iQIcBAEBCgAGBQJUV3n7AAoJEOhnXe7L7s6jGPwQAKVj6gLb3Fs9CFRvo6H4xW1W
nCI+Wnd7pKP0Whph8n0Vh0VCvOODxfdb5BIr/A7rldhO3yosuXNlju9/kbk++ZJI
t2z0J8xPZgqRtKlQYf1S+w6Th1LnF/2Fd/uADM0GXdBbHXqUiqO35P056JZlwJxI
gsVG33nu+H5npr4YKwElM2/igD1xMm2+qrBrF8OLE2r/iiT3cTmMYFxG08A41s6p
6H1TEqQdBwJXNKxoqhQTGnYxWGuQGYumar/uedwCCo7aoxQvqDzG7xYrqcr8gVI9
5say7ABp7wcYt32849tkWn2NpMmjtbH27YanUaG+Qze1NE2FtL0dJcI+Szgb72cI
ikpYRlTH05YgCq7ICnp7evZrESIjcB/gReG1Ijx6FCvlFT+SXTo5K5ms3R5/dPsF
Fp9naVt6a+xQyNBp00MbWa2PRvV4mPDE+2Sz5VaHxqLZ66oiPuPmpRqGUxowjqGO
1wOWLJQFtKo0T971QgfUVHVaVXG1ZV+BVKB/xJATQeMb6tNKbob44bgWNh/4lxfd
tLDWPCJfHxtuFiJAFaJnOJ1QB1qdPd7DcjniEVMmmmVzsYXNlYG0K8Q+5/JdXEqy
Iv7Rs1zcdMh5R6oEDCUDIJmhFoGDN6dJWgAtxvIgf7nOMPUs+uOjXJmfleRGgsNb
VUkJscFKgKoo9ivRfnMP
=lZdb
-----END PGP SIGNATURE-----

--L8kKQa9TP3MWoCC0kccNHPM3NH9EGtr1N--


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

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

--===============5146011419674642202==--


From xen-devel-bounces@lists.xen.org Mon Nov 03 12:50:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 12:50:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlH5E-00022j-ER; Mon, 03 Nov 2014 12:50:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XlH5C-00022b-Pe
	for Xen-devel@lists.xen.org; Mon, 03 Nov 2014 12:50:06 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	9E/6B-02559-EF977545; Mon, 03 Nov 2014 12:50:06 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415019005!6805226!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22661 invoked from network); 3 Nov 2014 12:50:05 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-16.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Nov 2014 12:50:05 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XlH5A-0006wP-Aa; Mon, 03 Nov 2014 12:50:04 +0000
Message-ID: <545779FB.7060602@canonical.com>
Date: Mon, 03 Nov 2014 13:50:03 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel@lists.xen.org
References: <54574EA0.5070101@canonical.com>
	<54575E32.6040603@citrix.com>	<545764BB.7080005@canonical.com>
	<54576932.9030803@citrix.com>
In-Reply-To: <54576932.9030803@citrix.com>
Subject: Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 ->
 ffff82d080222806
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5146011419674642202=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

On 03.11.2014 12:38, Andrew Cooper wrote:
> On 03/11/14 11:19, Stefan Bader wrote:
>> On 03.11.2014 11:51, Andrew Cooper wrote:
>>> On 03/11/14 09:45, Stefan Bader wrote:
>>>> I see the message from the subject on my Intel box whenever a guest =
(iirc even
>>>> dom0) starts up. It is not fatal and everything seems ok. I am just =
curious
>>>> about what might trigger this. The addresses look to be inside the h=
ypervisor
>>>> code. I was wondering whether there is a simple way to figure out wh=
at this
>>>> relates to (likely need to look at the objdump of the unstripped hv =
module).
>>>>
>>>> Or has someone already looked into this and knows what likely is the=
 cause?
>>>>
>>>> -Stefan
>>> Specifically, the message indicates <type of fault>: faulting address=
 ->
>>> fixup address
>>>
>>> It is probably a wrmsr, and a higher logging level will indicate this=
=2E=20
>>> My gut feeling is that it is dom0 attempting to load microcode using =
the
>>> native method.
>>>
>>> ~Andrew
>>>
>> The faulting address in my case seems to be rdmsr_save (xen-4.4.1 base=
), the
>> fixup address somewhere unspecific in hvm.c (not sure whether that mak=
es sense
>> coming from a dom0 startup). I will have to re-compile this with the g=
dprintk
>> enabled to see which MSR that was.
>=20
> The fixup address lives in the .fixup section which is generally linked=

> elsewhere.  See the definition of rdmsr_safe() which does
> section-jumping in the asm statement.
>=20
>>
>> rdmsr_normal:
>>             /* Everyone can read the MSR space. */
>>             /* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR %p.\n",=

>>                         _p(regs->ecx));*/
>>             if ( rdmsr_safe(regs->ecx, msr_content) )
>>                 goto fail;
>>
>> Though likely related to the following WRMSRs following (the addresses=
 differ
>> from the subject I wasn't sure from where exactly I took the others an=
d these
>> are with 4.4.1 and directly after boot):
>=20
> These will most likely be in wrmsr_safe()
>=20
>>
>> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
>> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
>> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
>> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
>> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0=
04281c2001
>> a8168 to 0x004281c200148168.
>> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0=
04281c2001
>> a8168 to 0x004281c2001a0168.
>> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0=
04281c2001
>> a8168 to 0x004201c2001a8168.
>> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685
>> (XEN) traps.c:2514:d0 Domain attempted WRMSR 00000000000001b2 from 0x0=
0000000000
>> 00000 to 0x0000000000009600.
>>
>> The 0x1b2 seems to be thermal interrupt control. Cannot find the 0x610=
 right now
>> (need to refresh my docs)...
>>
>=20
> MSR 0x610 is MSR_PKG_POWER_LIMIT on SandyBridge and later.
>=20

After enabling the output for REDMSR as well it looks like the GPF messag=
e is
associated with RDMSR 0x61c (MSR_DRAM_POWER_INFO).

(XEN) traps.c:2606:d0 Domain attempted RDMSR 000000000000061c.
(XEN) traps.c:3071: GPF (0000): ffff82d08018ef37 -> ffff82d080222685




--L8kKQa9TP3MWoCC0kccNHPM3NH9EGtr1N
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

iQIcBAEBCgAGBQJUV3n7AAoJEOhnXe7L7s6jGPwQAKVj6gLb3Fs9CFRvo6H4xW1W
nCI+Wnd7pKP0Whph8n0Vh0VCvOODxfdb5BIr/A7rldhO3yosuXNlju9/kbk++ZJI
t2z0J8xPZgqRtKlQYf1S+w6Th1LnF/2Fd/uADM0GXdBbHXqUiqO35P056JZlwJxI
gsVG33nu+H5npr4YKwElM2/igD1xMm2+qrBrF8OLE2r/iiT3cTmMYFxG08A41s6p
6H1TEqQdBwJXNKxoqhQTGnYxWGuQGYumar/uedwCCo7aoxQvqDzG7xYrqcr8gVI9
5say7ABp7wcYt32849tkWn2NpMmjtbH27YanUaG+Qze1NE2FtL0dJcI+Szgb72cI
ikpYRlTH05YgCq7ICnp7evZrESIjcB/gReG1Ijx6FCvlFT+SXTo5K5ms3R5/dPsF
Fp9naVt6a+xQyNBp00MbWa2PRvV4mPDE+2Sz5VaHxqLZ66oiPuPmpRqGUxowjqGO
1wOWLJQFtKo0T971QgfUVHVaVXG1ZV+BVKB/xJATQeMb6tNKbob44bgWNh/4lxfd
tLDWPCJfHxtuFiJAFaJnOJ1QB1qdPd7DcjniEVMmmmVzsYXNlYG0K8Q+5/JdXEqy
Iv7Rs1zcdMh5R6oEDCUDIJmhFoGDN6dJWgAtxvIgf7nOMPUs+uOjXJmfleRGgsNb
VUkJscFKgKoo9ivRfnMP
=lZdb
-----END PGP SIGNATURE-----

--L8kKQa9TP3MWoCC0kccNHPM3NH9EGtr1N--


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

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

--===============5146011419674642202==--


From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHGy-0002RI-If; Mon, 03 Nov 2014 13:02:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGw-0002QK-S1
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4A/60-09936-5DC77545; Mon, 03 Nov 2014 13:02:13 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415019732!12409928!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7918 invoked from network); 3 Nov 2014 13:02:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:12 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 63AC6ACFC;
	Mon,  3 Nov 2014 13:02:12 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:52 +0100
Message-Id: <1415019724-4317-7-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 06/18] x86: Use new cache mode type in
	arch/x86/mm/init_64.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/mm/init_64.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 4cb8763..5390a5f 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -338,12 +338,15 @@ pte_t * __init populate_extra_pte(unsigned long vaddr)
  * Create large page table mappings for a range of physical addresses.
  */
 static void __init __init_extra_mapping(unsigned long phys, unsigned long size,
-						pgprot_t prot)
+					enum page_cache_mode cache)
 {
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
+	pgprot_t prot;
 
+	pgprot_val(prot) = pgprot_val(PAGE_KERNEL_LARGE) |
+		pgprot_val(pgprot_4k_2_large(cachemode2pgprot(cache)));
 	BUG_ON((phys & ~PMD_MASK) || (size & ~PMD_MASK));
 	for (; size; phys += PMD_SIZE, size -= PMD_SIZE) {
 		pgd = pgd_offset_k((unsigned long)__va(phys));
@@ -366,12 +369,12 @@ static void __init __init_extra_mapping(unsigned long phys, unsigned long size,
 
 void __init init_extra_mapping_wb(unsigned long phys, unsigned long size)
 {
-	__init_extra_mapping(phys, size, PAGE_KERNEL_LARGE);
+	__init_extra_mapping(phys, size, _PAGE_CACHE_MODE_WB);
 }
 
 void __init init_extra_mapping_uc(unsigned long phys, unsigned long size)
 {
-	__init_extra_mapping(phys, size, PAGE_KERNEL_LARGE_NOCACHE);
+	__init_extra_mapping(phys, size, _PAGE_CACHE_MODE_UC);
 }
 
 /*
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHH1-0002U5-Dh; Mon, 03 Nov 2014 13:02:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGz-0002RO-GZ
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	77/70-09936-6DC77545; Mon, 03 Nov 2014 13:02:14 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415019733!8954724!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20343 invoked from network); 3 Nov 2014 13:02:13 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:13 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 54F07AD35;
	Mon,  3 Nov 2014 13:02:13 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:54 +0100
Message-Id: <1415019724-4317-9-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 08/18] x86: Use new cache mode type in
	mm/iomap_32.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type. This requires to change
io_reserve_memtype() as well.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pat.h |  2 +-
 arch/x86/mm/iomap_32.c     | 12 +++++++-----
 arch/x86/mm/pat.c          | 18 ++++++++++--------
 3 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index e2c1668..a8438bc 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -20,7 +20,7 @@ extern int kernel_map_sync_memtype(u64 base, unsigned long size,
 		unsigned long flag);
 
 int io_reserve_memtype(resource_size_t start, resource_size_t end,
-			unsigned long *type);
+			enum page_cache_mode *pcm);
 
 void io_free_memtype(resource_size_t start, resource_size_t end);
 
diff --git a/arch/x86/mm/iomap_32.c b/arch/x86/mm/iomap_32.c
index 7b179b49..9ca35fc 100644
--- a/arch/x86/mm/iomap_32.c
+++ b/arch/x86/mm/iomap_32.c
@@ -33,17 +33,17 @@ static int is_io_mapping_possible(resource_size_t base, unsigned long size)
 
 int iomap_create_wc(resource_size_t base, unsigned long size, pgprot_t *prot)
 {
-	unsigned long flag = _PAGE_CACHE_WC;
+	enum page_cache_mode pcm = _PAGE_CACHE_MODE_WC;
 	int ret;
 
 	if (!is_io_mapping_possible(base, size))
 		return -EINVAL;
 
-	ret = io_reserve_memtype(base, base + size, &flag);
+	ret = io_reserve_memtype(base, base + size, &pcm);
 	if (ret)
 		return ret;
 
-	*prot = __pgprot(__PAGE_KERNEL | flag);
+	*prot = __pgprot(__PAGE_KERNEL | cachemode2protval(pcm));
 	return 0;
 }
 EXPORT_SYMBOL_GPL(iomap_create_wc);
@@ -82,8 +82,10 @@ iomap_atomic_prot_pfn(unsigned long pfn, pgprot_t prot)
 	 * MTRR is UC or WC.  UC_MINUS gets the real intention, of the
 	 * user, which is "WC if the MTRR is WC, UC if you can't do that."
 	 */
-	if (!pat_enabled && pgprot_val(prot) == pgprot_val(PAGE_KERNEL_WC))
-		prot = PAGE_KERNEL_UC_MINUS;
+	if (!pat_enabled && pgprot_val(prot) ==
+	    (__PAGE_KERNEL | cachemode2protval(_PAGE_CACHE_MODE_WC)))
+		prot = __pgprot(__PAGE_KERNEL |
+				cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS));
 
 	return (void __force __iomem *) kmap_atomic_prot_pfn(pfn, prot);
 }
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 47282c2..6d5a8e3 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -442,25 +442,27 @@ static unsigned long lookup_memtype(u64 paddr)
  * On failure, returns non-zero
  */
 int io_reserve_memtype(resource_size_t start, resource_size_t end,
-			unsigned long *type)
+			enum page_cache_mode *type)
 {
 	resource_size_t size = end - start;
-	unsigned long req_type = *type;
-	unsigned long new_type;
+	enum page_cache_mode req_type = *type;
+	enum page_cache_mode new_type;
+	unsigned long new_prot;
 	int ret;
 
 	WARN_ON_ONCE(iomem_map_sanity_check(start, size));
 
-	ret = reserve_memtype(start, end, req_type, &new_type);
+	ret = reserve_memtype(start, end, cachemode2protval(req_type),
+				&new_prot);
 	if (ret)
 		goto out_err;
 
-	if (!is_new_memtype_allowed(start, size,
-				    pgprot2cachemode(__pgprot(req_type)),
-				    pgprot2cachemode(__pgprot(new_type))))
+	new_type = pgprot2cachemode(__pgprot(new_prot));
+
+	if (!is_new_memtype_allowed(start, size, req_type, new_type))
 		goto out_free;
 
-	if (kernel_map_sync_memtype(start, size, new_type) < 0)
+	if (kernel_map_sync_memtype(start, size, new_prot) < 0)
 		goto out_free;
 
 	*type = new_type;
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHGx-0002Qu-RA; Mon, 03 Nov 2014 13:02:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGv-0002Ps-Dd
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F3/2B-24532-4DC77545; Mon, 03 Nov 2014 13:02:12 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415019731!5097758!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20962 invoked from network); 3 Nov 2014 13:02:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B5A6BACDE;
	Mon,  3 Nov 2014 13:02:10 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:48 +0100
Message-Id: <1415019724-4317-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 02/18] x86: Use new cache mode type in
	include/asm/fb.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using cache mode bits in the pte switch to usage of
the new cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/fb.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/fb.h b/arch/x86/include/asm/fb.h
index 2519d06..c3dd5e7 100644
--- a/arch/x86/include/asm/fb.h
+++ b/arch/x86/include/asm/fb.h
@@ -8,8 +8,12 @@
 static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
 				unsigned long off)
 {
+	unsigned long prot;
+
+	prot = pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK;
 	if (boot_cpu_data.x86 > 3)
-		pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
+		pgprot_val(vma->vm_page_prot) =
+			prot | cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS);
 }
 
 extern int fb_is_primary_device(struct fb_info *info);
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHH2-0002VN-Ax; Mon, 03 Nov 2014 13:02:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH0-0002Rm-60
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	01/54-09842-8DC77545; Mon, 03 Nov 2014 13:02:16 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415019735!12396088!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3326 invoked from network); 3 Nov 2014 13:02:15 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:15 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 258A2AD68;
	Mon,  3 Nov 2014 13:02:15 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:58 +0100
Message-Id: <1415019724-4317-13-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 12/18] x86: Use new cache mode type in
	mm/ioremap.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/io.h  |  2 +-
 arch/x86/include/asm/pat.h |  2 +-
 arch/x86/mm/ioremap.c      | 65 +++++++++++++++++++++++++---------------------
 arch/x86/mm/pat.c          | 12 +++++----
 4 files changed, 44 insertions(+), 37 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index b8237d8..71b9e65 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -314,7 +314,7 @@ extern void *xlate_dev_mem_ptr(unsigned long phys);
 extern void unxlate_dev_mem_ptr(unsigned long phys, void *addr);
 
 extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
-				unsigned long prot_val);
+				enum page_cache_mode pcm);
 extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
 
 extern bool is_early_ioremap_ptep(pte_t *ptep);
diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index a8438bc..d35ee2d 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -17,7 +17,7 @@ extern int reserve_memtype(u64 start, u64 end,
 extern int free_memtype(u64 start, u64 end);
 
 extern int kernel_map_sync_memtype(u64 base, unsigned long size,
-		unsigned long flag);
+		enum page_cache_mode pcm);
 
 int io_reserve_memtype(resource_size_t start, resource_size_t end,
 			enum page_cache_mode *pcm);
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 3a81eb9..f31507f 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -29,20 +29,20 @@
  * conflicts.
  */
 int ioremap_change_attr(unsigned long vaddr, unsigned long size,
-			       unsigned long prot_val)
+			enum page_cache_mode pcm)
 {
 	unsigned long nrpages = size >> PAGE_SHIFT;
 	int err;
 
-	switch (prot_val) {
-	case _PAGE_CACHE_UC:
+	switch (pcm) {
+	case _PAGE_CACHE_MODE_UC:
 	default:
 		err = _set_memory_uc(vaddr, nrpages);
 		break;
-	case _PAGE_CACHE_WC:
+	case _PAGE_CACHE_MODE_WC:
 		err = _set_memory_wc(vaddr, nrpages);
 		break;
-	case _PAGE_CACHE_WB:
+	case _PAGE_CACHE_MODE_WB:
 		err = _set_memory_wb(vaddr, nrpages);
 		break;
 	}
@@ -75,13 +75,14 @@ static int __ioremap_check_ram(unsigned long start_pfn, unsigned long nr_pages,
  * caller shouldn't need to know that small detail.
  */
 static void __iomem *__ioremap_caller(resource_size_t phys_addr,
-		unsigned long size, unsigned long prot_val, void *caller)
+		unsigned long size, enum page_cache_mode pcm, void *caller)
 {
 	unsigned long offset, vaddr;
 	resource_size_t pfn, last_pfn, last_addr;
 	const resource_size_t unaligned_phys_addr = phys_addr;
 	const unsigned long unaligned_size = size;
 	struct vm_struct *area;
+	enum page_cache_mode new_pcm;
 	unsigned long new_prot_val;
 	pgprot_t prot;
 	int retval;
@@ -134,39 +135,42 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 	size = PAGE_ALIGN(last_addr+1) - phys_addr;
 
 	retval = reserve_memtype(phys_addr, (u64)phys_addr + size,
-						prot_val, &new_prot_val);
+				 cachemode2protval(pcm), &new_prot_val);
 	if (retval) {
 		printk(KERN_ERR "ioremap reserve_memtype failed %d\n", retval);
 		return NULL;
 	}
 
-	if (prot_val != new_prot_val) {
-		if (!is_new_memtype_allowed(phys_addr, size,
-				pgprot2cachemode(__pgprot(prot_val)),
-				pgprot2cachemode(__pgprot(new_prot_val)))) {
+	new_pcm = pgprot2cachemode(__pgprot(new_prot_val));
+
+	if (pcm != new_pcm) {
+		if (!is_new_memtype_allowed(phys_addr, size, pcm, new_pcm)) {
 			printk(KERN_ERR
-		"ioremap error for 0x%llx-0x%llx, requested 0x%lx, got 0x%lx\n",
+		"ioremap error for 0x%llx-0x%llx, requested 0x%x, got 0x%x\n",
 				(unsigned long long)phys_addr,
 				(unsigned long long)(phys_addr + size),
-				prot_val, new_prot_val);
+				pcm, new_pcm);
 			goto err_free_memtype;
 		}
-		prot_val = new_prot_val;
+		pcm = new_pcm;
 	}
 
-	switch (prot_val) {
-	case _PAGE_CACHE_UC:
+	prot = PAGE_KERNEL_IO;
+	switch (pcm) {
+	case _PAGE_CACHE_MODE_UC:
 	default:
-		prot = PAGE_KERNEL_IO_NOCACHE;
+		prot = __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_UC));
 		break;
-	case _PAGE_CACHE_UC_MINUS:
-		prot = PAGE_KERNEL_IO_UC_MINUS;
+	case _PAGE_CACHE_MODE_UC_MINUS:
+		prot = __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS));
 		break;
-	case _PAGE_CACHE_WC:
-		prot = PAGE_KERNEL_IO_WC;
+	case _PAGE_CACHE_MODE_WC:
+		prot = __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_WC));
 		break;
-	case _PAGE_CACHE_WB:
-		prot = PAGE_KERNEL_IO;
+	case _PAGE_CACHE_MODE_WB:
 		break;
 	}
 
@@ -179,7 +183,7 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 	area->phys_addr = phys_addr;
 	vaddr = (unsigned long) area->addr;
 
-	if (kernel_map_sync_memtype(phys_addr, size, prot_val))
+	if (kernel_map_sync_memtype(phys_addr, size, pcm))
 		goto err_free_area;
 
 	if (ioremap_page_range(vaddr, vaddr + size, phys_addr, prot))
@@ -228,14 +232,14 @@ void __iomem *ioremap_nocache(resource_size_t phys_addr, unsigned long size)
 {
 	/*
 	 * Ideally, this should be:
-	 *	pat_enabled ? _PAGE_CACHE_UC : _PAGE_CACHE_UC_MINUS;
+	 *	pat_enabled ? _PAGE_CACHE_MODE_UC : _PAGE_CACHE_MODE_UC_MINUS;
 	 *
 	 * Till we fix all X drivers to use ioremap_wc(), we will use
 	 * UC MINUS.
 	 */
-	unsigned long val = _PAGE_CACHE_UC_MINUS;
+	enum page_cache_mode pcm = _PAGE_CACHE_MODE_UC_MINUS;
 
-	return __ioremap_caller(phys_addr, size, val,
+	return __ioremap_caller(phys_addr, size, pcm,
 				__builtin_return_address(0));
 }
 EXPORT_SYMBOL(ioremap_nocache);
@@ -253,7 +257,7 @@ EXPORT_SYMBOL(ioremap_nocache);
 void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
 {
 	if (pat_enabled)
-		return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WC,
+		return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WC,
 					__builtin_return_address(0));
 	else
 		return ioremap_nocache(phys_addr, size);
@@ -262,7 +266,7 @@ EXPORT_SYMBOL(ioremap_wc);
 
 void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size)
 {
-	return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WB,
+	return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WB,
 				__builtin_return_address(0));
 }
 EXPORT_SYMBOL(ioremap_cache);
@@ -270,7 +274,8 @@ EXPORT_SYMBOL(ioremap_cache);
 void __iomem *ioremap_prot(resource_size_t phys_addr, unsigned long size,
 				unsigned long prot_val)
 {
-	return __ioremap_caller(phys_addr, size, (prot_val & _PAGE_CACHE_MASK),
+	return __ioremap_caller(phys_addr, size,
+				pgprot2cachemode(__pgprot(prot_val)),
 				__builtin_return_address(0));
 }
 EXPORT_SYMBOL(ioremap_prot);
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 2f3744f..8f68a83 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -462,7 +462,7 @@ int io_reserve_memtype(resource_size_t start, resource_size_t end,
 	if (!is_new_memtype_allowed(start, size, req_type, new_type))
 		goto out_free;
 
-	if (kernel_map_sync_memtype(start, size, new_prot) < 0)
+	if (kernel_map_sync_memtype(start, size, new_type) < 0)
 		goto out_free;
 
 	*type = new_type;
@@ -560,7 +560,8 @@ int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
  * Change the memory type for the physial address range in kernel identity
  * mapping space if that range is a part of identity map.
  */
-int kernel_map_sync_memtype(u64 base, unsigned long size, unsigned long flags)
+int kernel_map_sync_memtype(u64 base, unsigned long size,
+			    enum page_cache_mode pcm)
 {
 	unsigned long id_sz;
 
@@ -578,11 +579,11 @@ int kernel_map_sync_memtype(u64 base, unsigned long size, unsigned long flags)
 				__pa(high_memory) - base :
 				size;
 
-	if (ioremap_change_attr((unsigned long)__va(base), id_sz, flags) < 0) {
+	if (ioremap_change_attr((unsigned long)__va(base), id_sz, pcm) < 0) {
 		printk(KERN_INFO "%s:%d ioremap_change_attr failed %s "
 			"for [mem %#010Lx-%#010Lx]\n",
 			current->comm, current->pid,
-			cattr_name(flags),
+			cattr_name(cachemode2protval(pcm)),
 			base, (unsigned long long)(base + size-1));
 		return -EINVAL;
 	}
@@ -656,7 +657,8 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 				     flags);
 	}
 
-	if (kernel_map_sync_memtype(paddr, size, flags) < 0) {
+	if (kernel_map_sync_memtype(paddr, size,
+				    pgprot2cachemode(__pgprot(flags))) < 0) {
 		free_memtype(paddr, paddr + size);
 		return -EINVAL;
 	}
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHGx-0002Qn-Ei; Mon, 03 Nov 2014 13:02:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGv-0002Pr-9e
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:13 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	C6/19-26652-4DC77545; Mon, 03 Nov 2014 13:02:12 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415019731!5471306!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7498 invoked from network); 3 Nov 2014 13:02:11 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 13:02:11 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 49BD7AC9F;
	Mon,  3 Nov 2014 13:02:10 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:47 +0100
Message-Id: <1415019724-4317-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 01/18] x86: Make page cache mode a real 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At the moment there are a lot of places that handle setting or getting
the page cache mode by treating the pgprot bits equal to the cache mode.
This is only true because there are a lot of assumptions about the setup
of the PAT MSR. Otherwise the cache type needs to get translated into
pgprot bits and vice versa.

This patch tries to prepare for that by introducing a separate type
for the cache mode and adding functions to translate between those and
pgprot values.

To avoid too much performance penalty the translation between cache mode
and pgprot values is done via tables which contain the relevant
information.  Write-back cache mode is hard-wired to be 0, all other
modes are configurable via those tables. For large pages there are
translation functions as the PAT bit is located at different positions
in the ptes of 4k and large pages.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h | 73 +++++++++++++++++++++++++++++++++++-
 arch/x86/mm/init.c                   | 29 ++++++++++++++
 2 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0778964..5124642 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -128,12 +128,34 @@
 			 _PAGE_SOFT_DIRTY | _PAGE_NUMA)
 #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE | _PAGE_NUMA)
 
-#define _PAGE_CACHE_MASK	(_PAGE_PCD | _PAGE_PWT)
 #define _PAGE_CACHE_WB		(0)
 #define _PAGE_CACHE_WC		(_PAGE_PWT)
 #define _PAGE_CACHE_UC_MINUS	(_PAGE_PCD)
 #define _PAGE_CACHE_UC		(_PAGE_PCD | _PAGE_PWT)
 
+/*
+ * The cache modes defined here are used to translate between pure SW usage
+ * and the HW defined cache mode bits and/or PAT entries.
+ *
+ * The resulting bits for PWT, PCD and PAT should be chosen in a way
+ * to have the WB mode at index 0 (all bits clear). This is the default
+ * right now and likely would break too much if changed.
+ */
+#ifndef __ASSEMBLY__
+enum page_cache_mode {
+	_PAGE_CACHE_MODE_WB = 0,
+	_PAGE_CACHE_MODE_WC = 1,
+	_PAGE_CACHE_MODE_UC_MINUS = 2,
+	_PAGE_CACHE_MODE_UC = 3,
+	_PAGE_CACHE_MODE_WT = 4,
+	_PAGE_CACHE_MODE_WP = 5,
+	_PAGE_CACHE_MODE_NUM = 8
+};
+#endif
+
+#define _PAGE_CACHE_MASK	(_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)
+#define _PAGE_NOCACHE		(cachemode2protval(_PAGE_CACHE_MODE_UC))
+
 #define PAGE_NONE	__pgprot(_PAGE_PROTNONE | _PAGE_ACCESSED)
 #define PAGE_SHARED	__pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | \
 				 _PAGE_ACCESSED | _PAGE_NX)
@@ -341,6 +363,55 @@ static inline pmdval_t pmdnuma_flags(pmd_t pmd)
 #define pgprot_val(x)	((x).pgprot)
 #define __pgprot(x)	((pgprot_t) { (x) } )
 
+extern uint16_t __cachemode2pte_tbl[_PAGE_CACHE_MODE_NUM];
+extern uint8_t __pte2cachemode_tbl[8];
+
+#define __pte2cm_idx(cb)				\
+	((((cb) >> (_PAGE_BIT_PAT - 2)) & 4) |		\
+	 (((cb) >> (_PAGE_BIT_PCD - 1)) & 2) |		\
+	 (((cb) >> _PAGE_BIT_PWT) & 1))
+
+static inline unsigned long cachemode2protval(enum page_cache_mode pcm)
+{
+	if (likely(pcm == 0))
+		return 0;
+	return __cachemode2pte_tbl[pcm];
+}
+static inline pgprot_t cachemode2pgprot(enum page_cache_mode pcm)
+{
+	return __pgprot(cachemode2protval(pcm));
+}
+static inline enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)
+{
+	unsigned long masked;
+
+	masked = pgprot_val(pgprot) & _PAGE_CACHE_MASK;
+	if (likely(masked == 0))
+		return 0;
+	return __pte2cachemode_tbl[__pte2cm_idx(masked)];
+}
+static inline pgprot_t pgprot_4k_2_large(pgprot_t pgprot)
+{
+	pgprot_t new;
+	unsigned long val;
+
+	val = pgprot_val(pgprot);
+	pgprot_val(new) = (val & ~(_PAGE_PAT | _PAGE_PAT_LARGE)) |
+		((val & _PAGE_PAT) << (_PAGE_BIT_PAT_LARGE - _PAGE_BIT_PAT));
+	return new;
+}
+static inline pgprot_t pgprot_large_2_4k(pgprot_t pgprot)
+{
+	pgprot_t new;
+	unsigned long val;
+
+	val = pgprot_val(pgprot);
+	pgprot_val(new) = (val & ~(_PAGE_PAT | _PAGE_PAT_LARGE)) |
+			  ((val & _PAGE_PAT_LARGE) >>
+			   (_PAGE_BIT_PAT_LARGE - _PAGE_BIT_PAT));
+	return new;
+}
+
 
 typedef struct page *pgtable_t;
 
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 66dba36..a9776ba 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -27,6 +27,35 @@
 
 #include "mm_internal.h"
 
+/*
+ * Tables translating between page_cache_type_t and pte encoding.
+ * Minimal supported modes are defined statically, modified if more supported
+ * cache modes are available.
+ * Index into __cachemode2pte_tbl is the cachemode.
+ * Index into __pte2cachemode_tbl are the caching attribute bits of the pte
+ * (_PAGE_PWT, _PAGE_PCD, _PAGE_PAT) at index bit positions 0, 1, 2.
+ */
+uint16_t __cachemode2pte_tbl[_PAGE_CACHE_MODE_NUM] = {
+	[_PAGE_CACHE_MODE_WB]		= 0,
+	[_PAGE_CACHE_MODE_WC]		= _PAGE_PWT,
+	[_PAGE_CACHE_MODE_UC_MINUS]	= _PAGE_PCD,
+	[_PAGE_CACHE_MODE_UC]		= _PAGE_PCD | _PAGE_PWT,
+	[_PAGE_CACHE_MODE_WT]		= _PAGE_PCD,
+	[_PAGE_CACHE_MODE_WP]		= _PAGE_PCD,
+};
+EXPORT_SYMBOL_GPL(__cachemode2pte_tbl);
+uint8_t __pte2cachemode_tbl[8] = {
+	[__pte2cm_idx(0)] = _PAGE_CACHE_MODE_WB,
+	[__pte2cm_idx(_PAGE_PWT)] = _PAGE_CACHE_MODE_WC,
+	[__pte2cm_idx(_PAGE_PCD)] = _PAGE_CACHE_MODE_UC_MINUS,
+	[__pte2cm_idx(_PAGE_PWT | _PAGE_PCD)] = _PAGE_CACHE_MODE_UC,
+	[__pte2cm_idx(_PAGE_PAT)] = _PAGE_CACHE_MODE_WB,
+	[__pte2cm_idx(_PAGE_PWT | _PAGE_PAT)] = _PAGE_CACHE_MODE_WC,
+	[__pte2cm_idx(_PAGE_PCD | _PAGE_PAT)] = _PAGE_CACHE_MODE_UC_MINUS,
+	[__pte2cm_idx(_PAGE_PWT | _PAGE_PCD | _PAGE_PAT)] = _PAGE_CACHE_MODE_UC,
+};
+EXPORT_SYMBOL_GPL(__pte2cachemode_tbl);
+
 static unsigned long __initdata pgt_buf_start;
 static unsigned long __initdata pgt_buf_end;
 static unsigned long __initdata pgt_buf_top;
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHH1-0002Ua-Rp; Mon, 03 Nov 2014 13:02:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH0-0002Rk-1T
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	94/6B-24532-9DC77545; Mon, 03 Nov 2014 13:02:17 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415019735!12396092!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3377 invoked from network); 3 Nov 2014 13:02:16 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:16 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8E14CAD7F;
	Mon,  3 Nov 2014 13:02:15 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:59 +0100
Message-Id: <1415019724-4317-14-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 13/18] x86: Use new cache mode type in
	memtype related functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/cacheflush.h |  38 ++++++++------
 arch/x86/include/asm/pat.h        |   2 +-
 arch/x86/mm/ioremap.c             |   5 +-
 arch/x86/mm/pageattr.c            |   9 ++--
 arch/x86/mm/pat.c                 | 102 ++++++++++++++++++--------------------
 arch/x86/mm/pat_internal.h        |  22 ++++----
 arch/x86/mm/pat_rbtree.c          |   8 +--
 7 files changed, 96 insertions(+), 90 deletions(-)

diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
index 9863ee3..157644b 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -9,10 +9,10 @@
 /*
  * X86 PAT uses page flags WC and Uncached together to keep track of
  * memory type of pages that have backing page struct. X86 PAT supports 3
- * different memory types, _PAGE_CACHE_WB, _PAGE_CACHE_WC and
- * _PAGE_CACHE_UC_MINUS and fourth state where page's memory type has not
+ * different memory types, _PAGE_CACHE_MODE_WB, _PAGE_CACHE_MODE_WC and
+ * _PAGE_CACHE_MODE_UC_MINUS and fourth state where page's memory type has not
  * been changed from its default (value of -1 used to denote this).
- * Note we do not support _PAGE_CACHE_UC here.
+ * Note we do not support _PAGE_CACHE_MODE_UC here.
  */
 
 #define _PGMT_DEFAULT		0
@@ -22,36 +22,40 @@
 #define _PGMT_MASK		(1UL << PG_uncached | 1UL << PG_arch_1)
 #define _PGMT_CLEAR_MASK	(~_PGMT_MASK)
 
-static inline unsigned long get_page_memtype(struct page *pg)
+static inline enum page_cache_mode get_page_memtype(struct page *pg)
 {
 	unsigned long pg_flags = pg->flags & _PGMT_MASK;
 
 	if (pg_flags == _PGMT_DEFAULT)
 		return -1;
 	else if (pg_flags == _PGMT_WC)
-		return _PAGE_CACHE_WC;
+		return _PAGE_CACHE_MODE_WC;
 	else if (pg_flags == _PGMT_UC_MINUS)
-		return _PAGE_CACHE_UC_MINUS;
+		return _PAGE_CACHE_MODE_UC_MINUS;
 	else
-		return _PAGE_CACHE_WB;
+		return _PAGE_CACHE_MODE_WB;
 }
 
-static inline void set_page_memtype(struct page *pg, unsigned long memtype)
+static inline void set_page_memtype(struct page *pg,
+				    enum page_cache_mode memtype)
 {
-	unsigned long memtype_flags = _PGMT_DEFAULT;
+	unsigned long memtype_flags;
 	unsigned long old_flags;
 	unsigned long new_flags;
 
 	switch (memtype) {
-	case _PAGE_CACHE_WC:
+	case _PAGE_CACHE_MODE_WC:
 		memtype_flags = _PGMT_WC;
 		break;
-	case _PAGE_CACHE_UC_MINUS:
+	case _PAGE_CACHE_MODE_UC_MINUS:
 		memtype_flags = _PGMT_UC_MINUS;
 		break;
-	case _PAGE_CACHE_WB:
+	case _PAGE_CACHE_MODE_WB:
 		memtype_flags = _PGMT_WB;
 		break;
+	default:
+		memtype_flags = _PGMT_DEFAULT;
+		break;
 	}
 
 	do {
@@ -60,8 +64,14 @@ static inline void set_page_memtype(struct page *pg, unsigned long memtype)
 	} while (cmpxchg(&pg->flags, old_flags, new_flags) != old_flags);
 }
 #else
-static inline unsigned long get_page_memtype(struct page *pg) { return -1; }
-static inline void set_page_memtype(struct page *pg, unsigned long memtype) { }
+static inline enum page_cache_mode get_page_memtype(struct page *pg)
+{
+	return -1;
+}
+static inline void set_page_memtype(struct page *pg,
+				    enum page_cache_mode memtype)
+{
+}
 #endif
 
 /*
diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index d35ee2d..150407a 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -13,7 +13,7 @@ static const int pat_enabled;
 extern void pat_init(void);
 
 extern int reserve_memtype(u64 start, u64 end,
-		unsigned long req_type, unsigned long *ret_type);
+		enum page_cache_mode req_pcm, enum page_cache_mode *ret_pcm);
 extern int free_memtype(u64 start, u64 end);
 
 extern int kernel_map_sync_memtype(u64 base, unsigned long size,
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index f31507f..8832e51 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -83,7 +83,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 	const unsigned long unaligned_size = size;
 	struct vm_struct *area;
 	enum page_cache_mode new_pcm;
-	unsigned long new_prot_val;
 	pgprot_t prot;
 	int retval;
 	void __iomem *ret_addr;
@@ -135,14 +134,12 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 	size = PAGE_ALIGN(last_addr+1) - phys_addr;
 
 	retval = reserve_memtype(phys_addr, (u64)phys_addr + size,
-				 cachemode2protval(pcm), &new_prot_val);
+						pcm, &new_pcm);
 	if (retval) {
 		printk(KERN_ERR "ioremap reserve_memtype failed %d\n", retval);
 		return NULL;
 	}
 
-	new_pcm = pgprot2cachemode(__pgprot(new_prot_val));
-
 	if (pcm != new_pcm) {
 		if (!is_new_memtype_allowed(phys_addr, size, pcm, new_pcm)) {
 			printk(KERN_ERR
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 9f7e1b4..de807c9 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1451,7 +1451,7 @@ int set_memory_uc(unsigned long addr, int numpages)
 	 * for now UC MINUS. see comments in ioremap_nocache()
 	 */
 	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
-			    _PAGE_CACHE_UC_MINUS, NULL);
+			      _PAGE_CACHE_MODE_UC_MINUS, NULL);
 	if (ret)
 		goto out_err;
 
@@ -1479,7 +1479,7 @@ static int _set_memory_array(unsigned long *addr, int addrinarray,
 	 */
 	for (i = 0; i < addrinarray; i++) {
 		ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE,
-					cachemode2protval(new_type), NULL);
+					new_type, NULL);
 		if (ret)
 			goto out_free;
 	}
@@ -1544,7 +1544,7 @@ int set_memory_wc(unsigned long addr, int numpages)
 		return set_memory_uc(addr, numpages);
 
 	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
-		_PAGE_CACHE_WC, NULL);
+		_PAGE_CACHE_MODE_WC, NULL);
 	if (ret)
 		goto out_err;
 
@@ -1662,8 +1662,7 @@ static int _set_pages_array(struct page **pages, int addrinarray,
 			continue;
 		start = page_to_pfn(pages[i]) << PAGE_SHIFT;
 		end = start + PAGE_SIZE;
-		if (reserve_memtype(start, end, cachemode2protval(new_type),
-				    NULL))
+		if (reserve_memtype(start, end, new_type, NULL))
 			goto err_out;
 	}
 
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 8f68a83..ef75f3f 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -139,20 +139,21 @@ static DEFINE_SPINLOCK(memtype_lock);	/* protects memtype accesses */
  * The intersection is based on "Effective Memory Type" tables in IA-32
  * SDM vol 3a
  */
-static unsigned long pat_x_mtrr_type(u64 start, u64 end, unsigned long req_type)
+static unsigned long pat_x_mtrr_type(u64 start, u64 end,
+				     enum page_cache_mode req_type)
 {
 	/*
 	 * Look for MTRR hint to get the effective type in case where PAT
 	 * request is for WB.
 	 */
-	if (req_type == _PAGE_CACHE_WB) {
+	if (req_type == _PAGE_CACHE_MODE_WB) {
 		u8 mtrr_type;
 
 		mtrr_type = mtrr_type_lookup(start, end);
 		if (mtrr_type != MTRR_TYPE_WRBACK)
-			return _PAGE_CACHE_UC_MINUS;
+			return _PAGE_CACHE_MODE_UC_MINUS;
 
-		return _PAGE_CACHE_WB;
+		return _PAGE_CACHE_MODE_WB;
 	}
 
 	return req_type;
@@ -207,25 +208,26 @@ static int pat_pagerange_is_ram(resource_size_t start, resource_size_t end)
  * - Find the memtype of all the pages in the range, look for any conflicts
  * - In case of no conflicts, set the new memtype for pages in the range
  */
-static int reserve_ram_pages_type(u64 start, u64 end, unsigned long req_type,
-				  unsigned long *new_type)
+static int reserve_ram_pages_type(u64 start, u64 end,
+				  enum page_cache_mode req_type,
+				  enum page_cache_mode *new_type)
 {
 	struct page *page;
 	u64 pfn;
 
-	if (req_type == _PAGE_CACHE_UC) {
+	if (req_type == _PAGE_CACHE_MODE_UC) {
 		/* We do not support strong UC */
 		WARN_ON_ONCE(1);
-		req_type = _PAGE_CACHE_UC_MINUS;
+		req_type = _PAGE_CACHE_MODE_UC_MINUS;
 	}
 
 	for (pfn = (start >> PAGE_SHIFT); pfn < (end >> PAGE_SHIFT); ++pfn) {
-		unsigned long type;
+		enum page_cache_mode type;
 
 		page = pfn_to_page(pfn);
 		type = get_page_memtype(page);
 		if (type != -1) {
-			printk(KERN_INFO "reserve_ram_pages_type failed [mem %#010Lx-%#010Lx], track 0x%lx, req 0x%lx\n",
+			pr_info("reserve_ram_pages_type failed [mem %#010Lx-%#010Lx], track 0x%x, req 0x%x\n",
 				start, end - 1, type, req_type);
 			if (new_type)
 				*new_type = type;
@@ -258,21 +260,21 @@ static int free_ram_pages_type(u64 start, u64 end)
 
 /*
  * req_type typically has one of the:
- * - _PAGE_CACHE_WB
- * - _PAGE_CACHE_WC
- * - _PAGE_CACHE_UC_MINUS
- * - _PAGE_CACHE_UC
+ * - _PAGE_CACHE_MODE_WB
+ * - _PAGE_CACHE_MODE_WC
+ * - _PAGE_CACHE_MODE_UC_MINUS
+ * - _PAGE_CACHE_MODE_UC
  *
  * If new_type is NULL, function will return an error if it cannot reserve the
  * region with req_type. If new_type is non-NULL, function will return
  * available type in new_type in case of no error. In case of any error
  * it will return a negative return value.
  */
-int reserve_memtype(u64 start, u64 end, unsigned long req_type,
-		    unsigned long *new_type)
+int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type,
+		    enum page_cache_mode *new_type)
 {
 	struct memtype *new;
-	unsigned long actual_type;
+	enum page_cache_mode actual_type;
 	int is_range_ram;
 	int err = 0;
 
@@ -281,10 +283,10 @@ int reserve_memtype(u64 start, u64 end, unsigned long req_type,
 	if (!pat_enabled) {
 		/* This is identical to page table setting without PAT */
 		if (new_type) {
-			if (req_type == _PAGE_CACHE_WC)
-				*new_type = _PAGE_CACHE_UC_MINUS;
+			if (req_type == _PAGE_CACHE_MODE_WC)
+				*new_type = _PAGE_CACHE_MODE_UC_MINUS;
 			else
-				*new_type = req_type & _PAGE_CACHE_MASK;
+				*new_type = req_type;
 		}
 		return 0;
 	}
@@ -292,7 +294,7 @@ int reserve_memtype(u64 start, u64 end, unsigned long req_type,
 	/* Low ISA region is always mapped WB in page table. No need to track */
 	if (x86_platform.is_untracked_pat_range(start, end)) {
 		if (new_type)
-			*new_type = _PAGE_CACHE_WB;
+			*new_type = _PAGE_CACHE_MODE_WB;
 		return 0;
 	}
 
@@ -302,7 +304,7 @@ int reserve_memtype(u64 start, u64 end, unsigned long req_type,
 	 * tools and ACPI tools). Use WB request for WB memory and use
 	 * UC_MINUS otherwise.
 	 */
-	actual_type = pat_x_mtrr_type(start, end, req_type & _PAGE_CACHE_MASK);
+	actual_type = pat_x_mtrr_type(start, end, req_type);
 
 	if (new_type)
 		*new_type = actual_type;
@@ -408,7 +410,7 @@ static enum page_cache_mode lookup_memtype(u64 paddr)
 	if (pat_pagerange_is_ram(paddr, paddr + PAGE_SIZE)) {
 		struct page *page;
 		page = pfn_to_page(paddr >> PAGE_SHIFT);
-		rettype = pgprot2cachemode(__pgprot(get_page_memtype(page)));
+		rettype = get_page_memtype(page);
 		/*
 		 * -1 from get_page_memtype() implies RAM page is in its
 		 * default state and not reserved, and hence of type WB
@@ -423,7 +425,7 @@ static enum page_cache_mode lookup_memtype(u64 paddr)
 
 	entry = rbt_memtype_lookup(paddr);
 	if (entry != NULL)
-		rettype = pgprot2cachemode(__pgprot(entry->type));
+		rettype = entry->type;
 	else
 		rettype = _PAGE_CACHE_MODE_UC_MINUS;
 
@@ -447,18 +449,14 @@ int io_reserve_memtype(resource_size_t start, resource_size_t end,
 	resource_size_t size = end - start;
 	enum page_cache_mode req_type = *type;
 	enum page_cache_mode new_type;
-	unsigned long new_prot;
 	int ret;
 
 	WARN_ON_ONCE(iomem_map_sanity_check(start, size));
 
-	ret = reserve_memtype(start, end, cachemode2protval(req_type),
-				&new_prot);
+	ret = reserve_memtype(start, end, req_type, &new_type);
 	if (ret)
 		goto out_err;
 
-	new_type = pgprot2cachemode(__pgprot(new_prot));
-
 	if (!is_new_memtype_allowed(start, size, req_type, new_type))
 		goto out_free;
 
@@ -524,13 +522,13 @@ static inline int range_is_allowed(unsigned long pfn, unsigned long size)
 int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
 				unsigned long size, pgprot_t *vma_prot)
 {
-	unsigned long flags = _PAGE_CACHE_WB;
+	enum page_cache_mode pcm = _PAGE_CACHE_MODE_WB;
 
 	if (!range_is_allowed(pfn, size))
 		return 0;
 
 	if (file->f_flags & O_DSYNC)
-		flags = _PAGE_CACHE_UC_MINUS;
+		pcm = _PAGE_CACHE_MODE_UC_MINUS;
 
 #ifdef CONFIG_X86_32
 	/*
@@ -547,12 +545,12 @@ int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
 	      boot_cpu_has(X86_FEATURE_CYRIX_ARR) ||
 	      boot_cpu_has(X86_FEATURE_CENTAUR_MCR)) &&
 	    (pfn << PAGE_SHIFT) >= __pa(high_memory)) {
-		flags = _PAGE_CACHE_UC;
+		pcm = _PAGE_CACHE_MODE_UC;
 	}
 #endif
 
 	*vma_prot = __pgprot((pgprot_val(*vma_prot) & ~_PAGE_CACHE_MASK) |
-			     flags);
+			     cachemode2protval(pcm));
 	return 1;
 }
 
@@ -583,7 +581,7 @@ int kernel_map_sync_memtype(u64 base, unsigned long size,
 		printk(KERN_INFO "%s:%d ioremap_change_attr failed %s "
 			"for [mem %#010Lx-%#010Lx]\n",
 			current->comm, current->pid,
-			cattr_name(cachemode2protval(pcm)),
+			cattr_name(pcm),
 			base, (unsigned long long)(base + size-1));
 		return -EINVAL;
 	}
@@ -600,8 +598,8 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 {
 	int is_ram = 0;
 	int ret;
-	unsigned long want_flags = (pgprot_val(*vma_prot) & _PAGE_CACHE_MASK);
-	unsigned long flags = want_flags;
+	enum page_cache_mode want_pcm = pgprot2cachemode(*vma_prot);
+	enum page_cache_mode pcm = want_pcm;
 
 	is_ram = pat_pagerange_is_ram(paddr, paddr + size);
 
@@ -614,38 +612,36 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 		if (!pat_enabled)
 			return 0;
 
-		flags = cachemode2protval(lookup_memtype(paddr));
-		if (want_flags != flags) {
+		pcm = lookup_memtype(paddr);
+		if (want_pcm != pcm) {
 			printk(KERN_WARNING "%s:%d map pfn RAM range req %s for [mem %#010Lx-%#010Lx], got %s\n",
 				current->comm, current->pid,
-				cattr_name(want_flags),
+				cattr_name(want_pcm),
 				(unsigned long long)paddr,
 				(unsigned long long)(paddr + size - 1),
-				cattr_name(flags));
+				cattr_name(pcm));
 			*vma_prot = __pgprot((pgprot_val(*vma_prot) &
-					      (~_PAGE_CACHE_MASK)) |
-					     flags);
+					     (~_PAGE_CACHE_MASK)) |
+					     cachemode2protval(pcm));
 		}
 		return 0;
 	}
 
-	ret = reserve_memtype(paddr, paddr + size, want_flags, &flags);
+	ret = reserve_memtype(paddr, paddr + size, want_pcm, &pcm);
 	if (ret)
 		return ret;
 
-	if (flags != want_flags) {
+	if (pcm != want_pcm) {
 		if (strict_prot ||
-		    !is_new_memtype_allowed(paddr, size,
-				pgprot2cachemode(__pgprot(want_flags)),
-				pgprot2cachemode(__pgprot(flags)))) {
+		    !is_new_memtype_allowed(paddr, size, want_pcm, pcm)) {
 			free_memtype(paddr, paddr + size);
 			printk(KERN_ERR "%s:%d map pfn expected mapping type %s"
 				" for [mem %#010Lx-%#010Lx], got %s\n",
 				current->comm, current->pid,
-				cattr_name(want_flags),
+				cattr_name(want_pcm),
 				(unsigned long long)paddr,
 				(unsigned long long)(paddr + size - 1),
-				cattr_name(flags));
+				cattr_name(pcm));
 			return -EINVAL;
 		}
 		/*
@@ -654,11 +650,10 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 		 */
 		*vma_prot = __pgprot((pgprot_val(*vma_prot) &
 				      (~_PAGE_CACHE_MASK)) |
-				     flags);
+				     cachemode2protval(pcm));
 	}
 
-	if (kernel_map_sync_memtype(paddr, size,
-				    pgprot2cachemode(__pgprot(flags))) < 0) {
+	if (kernel_map_sync_memtype(paddr, size, pcm) < 0) {
 		free_memtype(paddr, paddr + size);
 		return -EINVAL;
 	}
@@ -799,7 +794,8 @@ void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
 pgprot_t pgprot_writecombine(pgprot_t prot)
 {
 	if (pat_enabled)
-		return __pgprot(pgprot_val(prot) | _PAGE_CACHE_WC);
+		return __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_WC));
 	else
 		return pgprot_noncached(prot);
 }
diff --git a/arch/x86/mm/pat_internal.h b/arch/x86/mm/pat_internal.h
index 77e5ba1..f641162 100644
--- a/arch/x86/mm/pat_internal.h
+++ b/arch/x86/mm/pat_internal.h
@@ -10,30 +10,32 @@ struct memtype {
 	u64			start;
 	u64			end;
 	u64			subtree_max_end;
-	unsigned long		type;
+	enum page_cache_mode	type;
 	struct rb_node		rb;
 };
 
-static inline char *cattr_name(unsigned long flags)
+static inline char *cattr_name(enum page_cache_mode pcm)
 {
-	switch (flags & _PAGE_CACHE_MASK) {
-	case _PAGE_CACHE_UC:		return "uncached";
-	case _PAGE_CACHE_UC_MINUS:	return "uncached-minus";
-	case _PAGE_CACHE_WB:		return "write-back";
-	case _PAGE_CACHE_WC:		return "write-combining";
-	default:			return "broken";
+	switch (pcm) {
+	case _PAGE_CACHE_MODE_UC:		return "uncached";
+	case _PAGE_CACHE_MODE_UC_MINUS:		return "uncached-minus";
+	case _PAGE_CACHE_MODE_WB:		return "write-back";
+	case _PAGE_CACHE_MODE_WC:		return "write-combining";
+	case _PAGE_CACHE_MODE_WT:		return "write-through";
+	case _PAGE_CACHE_MODE_WP:		return "write-protected";
+	default:				return "broken";
 	}
 }
 
 #ifdef CONFIG_X86_PAT
 extern int rbt_memtype_check_insert(struct memtype *new,
-					unsigned long *new_type);
+					enum page_cache_mode *new_type);
 extern struct memtype *rbt_memtype_erase(u64 start, u64 end);
 extern struct memtype *rbt_memtype_lookup(u64 addr);
 extern int rbt_memtype_copy_nth_element(struct memtype *out, loff_t pos);
 #else
 static inline int rbt_memtype_check_insert(struct memtype *new,
-					unsigned long *new_type)
+					enum page_cache_mode *new_type)
 { return 0; }
 static inline struct memtype *rbt_memtype_erase(u64 start, u64 end)
 { return NULL; }
diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
index 415f6c4..6582adc 100644
--- a/arch/x86/mm/pat_rbtree.c
+++ b/arch/x86/mm/pat_rbtree.c
@@ -122,11 +122,12 @@ static struct memtype *memtype_rb_exact_match(struct rb_root *root,
 
 static int memtype_rb_check_conflict(struct rb_root *root,
 				u64 start, u64 end,
-				unsigned long reqtype, unsigned long *newtype)
+				enum page_cache_mode reqtype,
+				enum page_cache_mode *newtype)
 {
 	struct rb_node *node;
 	struct memtype *match;
-	int found_type = reqtype;
+	enum page_cache_mode found_type = reqtype;
 
 	match = memtype_rb_lowest_match(&memtype_rbroot, start, end);
 	if (match == NULL)
@@ -187,7 +188,8 @@ static void memtype_rb_insert(struct rb_root *root, struct memtype *newdata)
 	rb_insert_augmented(&newdata->rb, root, &memtype_rb_augment_cb);
 }
 
-int rbt_memtype_check_insert(struct memtype *new, unsigned long *ret_type)
+int rbt_memtype_check_insert(struct memtype *new,
+			     enum page_cache_mode *ret_type)
 {
 	int err = 0;
 
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHH1-0002U5-Dh; Mon, 03 Nov 2014 13:02:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGz-0002RO-GZ
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	77/70-09936-6DC77545; Mon, 03 Nov 2014 13:02:14 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415019733!8954724!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20343 invoked from network); 3 Nov 2014 13:02:13 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:13 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 54F07AD35;
	Mon,  3 Nov 2014 13:02:13 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:54 +0100
Message-Id: <1415019724-4317-9-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 08/18] x86: Use new cache mode type in
	mm/iomap_32.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type. This requires to change
io_reserve_memtype() as well.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pat.h |  2 +-
 arch/x86/mm/iomap_32.c     | 12 +++++++-----
 arch/x86/mm/pat.c          | 18 ++++++++++--------
 3 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index e2c1668..a8438bc 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -20,7 +20,7 @@ extern int kernel_map_sync_memtype(u64 base, unsigned long size,
 		unsigned long flag);
 
 int io_reserve_memtype(resource_size_t start, resource_size_t end,
-			unsigned long *type);
+			enum page_cache_mode *pcm);
 
 void io_free_memtype(resource_size_t start, resource_size_t end);
 
diff --git a/arch/x86/mm/iomap_32.c b/arch/x86/mm/iomap_32.c
index 7b179b49..9ca35fc 100644
--- a/arch/x86/mm/iomap_32.c
+++ b/arch/x86/mm/iomap_32.c
@@ -33,17 +33,17 @@ static int is_io_mapping_possible(resource_size_t base, unsigned long size)
 
 int iomap_create_wc(resource_size_t base, unsigned long size, pgprot_t *prot)
 {
-	unsigned long flag = _PAGE_CACHE_WC;
+	enum page_cache_mode pcm = _PAGE_CACHE_MODE_WC;
 	int ret;
 
 	if (!is_io_mapping_possible(base, size))
 		return -EINVAL;
 
-	ret = io_reserve_memtype(base, base + size, &flag);
+	ret = io_reserve_memtype(base, base + size, &pcm);
 	if (ret)
 		return ret;
 
-	*prot = __pgprot(__PAGE_KERNEL | flag);
+	*prot = __pgprot(__PAGE_KERNEL | cachemode2protval(pcm));
 	return 0;
 }
 EXPORT_SYMBOL_GPL(iomap_create_wc);
@@ -82,8 +82,10 @@ iomap_atomic_prot_pfn(unsigned long pfn, pgprot_t prot)
 	 * MTRR is UC or WC.  UC_MINUS gets the real intention, of the
 	 * user, which is "WC if the MTRR is WC, UC if you can't do that."
 	 */
-	if (!pat_enabled && pgprot_val(prot) == pgprot_val(PAGE_KERNEL_WC))
-		prot = PAGE_KERNEL_UC_MINUS;
+	if (!pat_enabled && pgprot_val(prot) ==
+	    (__PAGE_KERNEL | cachemode2protval(_PAGE_CACHE_MODE_WC)))
+		prot = __pgprot(__PAGE_KERNEL |
+				cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS));
 
 	return (void __force __iomem *) kmap_atomic_prot_pfn(pfn, prot);
 }
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 47282c2..6d5a8e3 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -442,25 +442,27 @@ static unsigned long lookup_memtype(u64 paddr)
  * On failure, returns non-zero
  */
 int io_reserve_memtype(resource_size_t start, resource_size_t end,
-			unsigned long *type)
+			enum page_cache_mode *type)
 {
 	resource_size_t size = end - start;
-	unsigned long req_type = *type;
-	unsigned long new_type;
+	enum page_cache_mode req_type = *type;
+	enum page_cache_mode new_type;
+	unsigned long new_prot;
 	int ret;
 
 	WARN_ON_ONCE(iomem_map_sanity_check(start, size));
 
-	ret = reserve_memtype(start, end, req_type, &new_type);
+	ret = reserve_memtype(start, end, cachemode2protval(req_type),
+				&new_prot);
 	if (ret)
 		goto out_err;
 
-	if (!is_new_memtype_allowed(start, size,
-				    pgprot2cachemode(__pgprot(req_type)),
-				    pgprot2cachemode(__pgprot(new_type))))
+	new_type = pgprot2cachemode(__pgprot(new_prot));
+
+	if (!is_new_memtype_allowed(start, size, req_type, new_type))
 		goto out_free;
 
-	if (kernel_map_sync_memtype(start, size, new_type) < 0)
+	if (kernel_map_sync_memtype(start, size, new_prot) < 0)
 		goto out_free;
 
 	*type = new_type;
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHGx-0002Qn-Ei; Mon, 03 Nov 2014 13:02:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGv-0002Pr-9e
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:13 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	C6/19-26652-4DC77545; Mon, 03 Nov 2014 13:02:12 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415019731!5471306!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7498 invoked from network); 3 Nov 2014 13:02:11 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 13:02:11 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 49BD7AC9F;
	Mon,  3 Nov 2014 13:02:10 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:47 +0100
Message-Id: <1415019724-4317-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 01/18] x86: Make page cache mode a real 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At the moment there are a lot of places that handle setting or getting
the page cache mode by treating the pgprot bits equal to the cache mode.
This is only true because there are a lot of assumptions about the setup
of the PAT MSR. Otherwise the cache type needs to get translated into
pgprot bits and vice versa.

This patch tries to prepare for that by introducing a separate type
for the cache mode and adding functions to translate between those and
pgprot values.

To avoid too much performance penalty the translation between cache mode
and pgprot values is done via tables which contain the relevant
information.  Write-back cache mode is hard-wired to be 0, all other
modes are configurable via those tables. For large pages there are
translation functions as the PAT bit is located at different positions
in the ptes of 4k and large pages.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h | 73 +++++++++++++++++++++++++++++++++++-
 arch/x86/mm/init.c                   | 29 ++++++++++++++
 2 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0778964..5124642 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -128,12 +128,34 @@
 			 _PAGE_SOFT_DIRTY | _PAGE_NUMA)
 #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE | _PAGE_NUMA)
 
-#define _PAGE_CACHE_MASK	(_PAGE_PCD | _PAGE_PWT)
 #define _PAGE_CACHE_WB		(0)
 #define _PAGE_CACHE_WC		(_PAGE_PWT)
 #define _PAGE_CACHE_UC_MINUS	(_PAGE_PCD)
 #define _PAGE_CACHE_UC		(_PAGE_PCD | _PAGE_PWT)
 
+/*
+ * The cache modes defined here are used to translate between pure SW usage
+ * and the HW defined cache mode bits and/or PAT entries.
+ *
+ * The resulting bits for PWT, PCD and PAT should be chosen in a way
+ * to have the WB mode at index 0 (all bits clear). This is the default
+ * right now and likely would break too much if changed.
+ */
+#ifndef __ASSEMBLY__
+enum page_cache_mode {
+	_PAGE_CACHE_MODE_WB = 0,
+	_PAGE_CACHE_MODE_WC = 1,
+	_PAGE_CACHE_MODE_UC_MINUS = 2,
+	_PAGE_CACHE_MODE_UC = 3,
+	_PAGE_CACHE_MODE_WT = 4,
+	_PAGE_CACHE_MODE_WP = 5,
+	_PAGE_CACHE_MODE_NUM = 8
+};
+#endif
+
+#define _PAGE_CACHE_MASK	(_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)
+#define _PAGE_NOCACHE		(cachemode2protval(_PAGE_CACHE_MODE_UC))
+
 #define PAGE_NONE	__pgprot(_PAGE_PROTNONE | _PAGE_ACCESSED)
 #define PAGE_SHARED	__pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | \
 				 _PAGE_ACCESSED | _PAGE_NX)
@@ -341,6 +363,55 @@ static inline pmdval_t pmdnuma_flags(pmd_t pmd)
 #define pgprot_val(x)	((x).pgprot)
 #define __pgprot(x)	((pgprot_t) { (x) } )
 
+extern uint16_t __cachemode2pte_tbl[_PAGE_CACHE_MODE_NUM];
+extern uint8_t __pte2cachemode_tbl[8];
+
+#define __pte2cm_idx(cb)				\
+	((((cb) >> (_PAGE_BIT_PAT - 2)) & 4) |		\
+	 (((cb) >> (_PAGE_BIT_PCD - 1)) & 2) |		\
+	 (((cb) >> _PAGE_BIT_PWT) & 1))
+
+static inline unsigned long cachemode2protval(enum page_cache_mode pcm)
+{
+	if (likely(pcm == 0))
+		return 0;
+	return __cachemode2pte_tbl[pcm];
+}
+static inline pgprot_t cachemode2pgprot(enum page_cache_mode pcm)
+{
+	return __pgprot(cachemode2protval(pcm));
+}
+static inline enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)
+{
+	unsigned long masked;
+
+	masked = pgprot_val(pgprot) & _PAGE_CACHE_MASK;
+	if (likely(masked == 0))
+		return 0;
+	return __pte2cachemode_tbl[__pte2cm_idx(masked)];
+}
+static inline pgprot_t pgprot_4k_2_large(pgprot_t pgprot)
+{
+	pgprot_t new;
+	unsigned long val;
+
+	val = pgprot_val(pgprot);
+	pgprot_val(new) = (val & ~(_PAGE_PAT | _PAGE_PAT_LARGE)) |
+		((val & _PAGE_PAT) << (_PAGE_BIT_PAT_LARGE - _PAGE_BIT_PAT));
+	return new;
+}
+static inline pgprot_t pgprot_large_2_4k(pgprot_t pgprot)
+{
+	pgprot_t new;
+	unsigned long val;
+
+	val = pgprot_val(pgprot);
+	pgprot_val(new) = (val & ~(_PAGE_PAT | _PAGE_PAT_LARGE)) |
+			  ((val & _PAGE_PAT_LARGE) >>
+			   (_PAGE_BIT_PAT_LARGE - _PAGE_BIT_PAT));
+	return new;
+}
+
 
 typedef struct page *pgtable_t;
 
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 66dba36..a9776ba 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -27,6 +27,35 @@
 
 #include "mm_internal.h"
 
+/*
+ * Tables translating between page_cache_type_t and pte encoding.
+ * Minimal supported modes are defined statically, modified if more supported
+ * cache modes are available.
+ * Index into __cachemode2pte_tbl is the cachemode.
+ * Index into __pte2cachemode_tbl are the caching attribute bits of the pte
+ * (_PAGE_PWT, _PAGE_PCD, _PAGE_PAT) at index bit positions 0, 1, 2.
+ */
+uint16_t __cachemode2pte_tbl[_PAGE_CACHE_MODE_NUM] = {
+	[_PAGE_CACHE_MODE_WB]		= 0,
+	[_PAGE_CACHE_MODE_WC]		= _PAGE_PWT,
+	[_PAGE_CACHE_MODE_UC_MINUS]	= _PAGE_PCD,
+	[_PAGE_CACHE_MODE_UC]		= _PAGE_PCD | _PAGE_PWT,
+	[_PAGE_CACHE_MODE_WT]		= _PAGE_PCD,
+	[_PAGE_CACHE_MODE_WP]		= _PAGE_PCD,
+};
+EXPORT_SYMBOL_GPL(__cachemode2pte_tbl);
+uint8_t __pte2cachemode_tbl[8] = {
+	[__pte2cm_idx(0)] = _PAGE_CACHE_MODE_WB,
+	[__pte2cm_idx(_PAGE_PWT)] = _PAGE_CACHE_MODE_WC,
+	[__pte2cm_idx(_PAGE_PCD)] = _PAGE_CACHE_MODE_UC_MINUS,
+	[__pte2cm_idx(_PAGE_PWT | _PAGE_PCD)] = _PAGE_CACHE_MODE_UC,
+	[__pte2cm_idx(_PAGE_PAT)] = _PAGE_CACHE_MODE_WB,
+	[__pte2cm_idx(_PAGE_PWT | _PAGE_PAT)] = _PAGE_CACHE_MODE_WC,
+	[__pte2cm_idx(_PAGE_PCD | _PAGE_PAT)] = _PAGE_CACHE_MODE_UC_MINUS,
+	[__pte2cm_idx(_PAGE_PWT | _PAGE_PCD | _PAGE_PAT)] = _PAGE_CACHE_MODE_UC,
+};
+EXPORT_SYMBOL_GPL(__pte2cachemode_tbl);
+
 static unsigned long __initdata pgt_buf_start;
 static unsigned long __initdata pgt_buf_end;
 static unsigned long __initdata pgt_buf_top;
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHGx-0002Qu-RA; Mon, 03 Nov 2014 13:02:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGv-0002Ps-Dd
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F3/2B-24532-4DC77545; Mon, 03 Nov 2014 13:02:12 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415019731!5097758!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20962 invoked from network); 3 Nov 2014 13:02:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B5A6BACDE;
	Mon,  3 Nov 2014 13:02:10 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:48 +0100
Message-Id: <1415019724-4317-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 02/18] x86: Use new cache mode type in
	include/asm/fb.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using cache mode bits in the pte switch to usage of
the new cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/fb.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/fb.h b/arch/x86/include/asm/fb.h
index 2519d06..c3dd5e7 100644
--- a/arch/x86/include/asm/fb.h
+++ b/arch/x86/include/asm/fb.h
@@ -8,8 +8,12 @@
 static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
 				unsigned long off)
 {
+	unsigned long prot;
+
+	prot = pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK;
 	if (boot_cpu_data.x86 > 3)
-		pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
+		pgprot_val(vma->vm_page_prot) =
+			prot | cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS);
 }
 
 extern int fb_is_primary_device(struct fb_info *info);
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHH2-0002VN-Ax; Mon, 03 Nov 2014 13:02:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH0-0002Rm-60
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	01/54-09842-8DC77545; Mon, 03 Nov 2014 13:02:16 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415019735!12396088!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3326 invoked from network); 3 Nov 2014 13:02:15 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:15 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 258A2AD68;
	Mon,  3 Nov 2014 13:02:15 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:58 +0100
Message-Id: <1415019724-4317-13-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 12/18] x86: Use new cache mode type in
	mm/ioremap.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/io.h  |  2 +-
 arch/x86/include/asm/pat.h |  2 +-
 arch/x86/mm/ioremap.c      | 65 +++++++++++++++++++++++++---------------------
 arch/x86/mm/pat.c          | 12 +++++----
 4 files changed, 44 insertions(+), 37 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index b8237d8..71b9e65 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -314,7 +314,7 @@ extern void *xlate_dev_mem_ptr(unsigned long phys);
 extern void unxlate_dev_mem_ptr(unsigned long phys, void *addr);
 
 extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
-				unsigned long prot_val);
+				enum page_cache_mode pcm);
 extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
 
 extern bool is_early_ioremap_ptep(pte_t *ptep);
diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index a8438bc..d35ee2d 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -17,7 +17,7 @@ extern int reserve_memtype(u64 start, u64 end,
 extern int free_memtype(u64 start, u64 end);
 
 extern int kernel_map_sync_memtype(u64 base, unsigned long size,
-		unsigned long flag);
+		enum page_cache_mode pcm);
 
 int io_reserve_memtype(resource_size_t start, resource_size_t end,
 			enum page_cache_mode *pcm);
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 3a81eb9..f31507f 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -29,20 +29,20 @@
  * conflicts.
  */
 int ioremap_change_attr(unsigned long vaddr, unsigned long size,
-			       unsigned long prot_val)
+			enum page_cache_mode pcm)
 {
 	unsigned long nrpages = size >> PAGE_SHIFT;
 	int err;
 
-	switch (prot_val) {
-	case _PAGE_CACHE_UC:
+	switch (pcm) {
+	case _PAGE_CACHE_MODE_UC:
 	default:
 		err = _set_memory_uc(vaddr, nrpages);
 		break;
-	case _PAGE_CACHE_WC:
+	case _PAGE_CACHE_MODE_WC:
 		err = _set_memory_wc(vaddr, nrpages);
 		break;
-	case _PAGE_CACHE_WB:
+	case _PAGE_CACHE_MODE_WB:
 		err = _set_memory_wb(vaddr, nrpages);
 		break;
 	}
@@ -75,13 +75,14 @@ static int __ioremap_check_ram(unsigned long start_pfn, unsigned long nr_pages,
  * caller shouldn't need to know that small detail.
  */
 static void __iomem *__ioremap_caller(resource_size_t phys_addr,
-		unsigned long size, unsigned long prot_val, void *caller)
+		unsigned long size, enum page_cache_mode pcm, void *caller)
 {
 	unsigned long offset, vaddr;
 	resource_size_t pfn, last_pfn, last_addr;
 	const resource_size_t unaligned_phys_addr = phys_addr;
 	const unsigned long unaligned_size = size;
 	struct vm_struct *area;
+	enum page_cache_mode new_pcm;
 	unsigned long new_prot_val;
 	pgprot_t prot;
 	int retval;
@@ -134,39 +135,42 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 	size = PAGE_ALIGN(last_addr+1) - phys_addr;
 
 	retval = reserve_memtype(phys_addr, (u64)phys_addr + size,
-						prot_val, &new_prot_val);
+				 cachemode2protval(pcm), &new_prot_val);
 	if (retval) {
 		printk(KERN_ERR "ioremap reserve_memtype failed %d\n", retval);
 		return NULL;
 	}
 
-	if (prot_val != new_prot_val) {
-		if (!is_new_memtype_allowed(phys_addr, size,
-				pgprot2cachemode(__pgprot(prot_val)),
-				pgprot2cachemode(__pgprot(new_prot_val)))) {
+	new_pcm = pgprot2cachemode(__pgprot(new_prot_val));
+
+	if (pcm != new_pcm) {
+		if (!is_new_memtype_allowed(phys_addr, size, pcm, new_pcm)) {
 			printk(KERN_ERR
-		"ioremap error for 0x%llx-0x%llx, requested 0x%lx, got 0x%lx\n",
+		"ioremap error for 0x%llx-0x%llx, requested 0x%x, got 0x%x\n",
 				(unsigned long long)phys_addr,
 				(unsigned long long)(phys_addr + size),
-				prot_val, new_prot_val);
+				pcm, new_pcm);
 			goto err_free_memtype;
 		}
-		prot_val = new_prot_val;
+		pcm = new_pcm;
 	}
 
-	switch (prot_val) {
-	case _PAGE_CACHE_UC:
+	prot = PAGE_KERNEL_IO;
+	switch (pcm) {
+	case _PAGE_CACHE_MODE_UC:
 	default:
-		prot = PAGE_KERNEL_IO_NOCACHE;
+		prot = __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_UC));
 		break;
-	case _PAGE_CACHE_UC_MINUS:
-		prot = PAGE_KERNEL_IO_UC_MINUS;
+	case _PAGE_CACHE_MODE_UC_MINUS:
+		prot = __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS));
 		break;
-	case _PAGE_CACHE_WC:
-		prot = PAGE_KERNEL_IO_WC;
+	case _PAGE_CACHE_MODE_WC:
+		prot = __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_WC));
 		break;
-	case _PAGE_CACHE_WB:
-		prot = PAGE_KERNEL_IO;
+	case _PAGE_CACHE_MODE_WB:
 		break;
 	}
 
@@ -179,7 +183,7 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 	area->phys_addr = phys_addr;
 	vaddr = (unsigned long) area->addr;
 
-	if (kernel_map_sync_memtype(phys_addr, size, prot_val))
+	if (kernel_map_sync_memtype(phys_addr, size, pcm))
 		goto err_free_area;
 
 	if (ioremap_page_range(vaddr, vaddr + size, phys_addr, prot))
@@ -228,14 +232,14 @@ void __iomem *ioremap_nocache(resource_size_t phys_addr, unsigned long size)
 {
 	/*
 	 * Ideally, this should be:
-	 *	pat_enabled ? _PAGE_CACHE_UC : _PAGE_CACHE_UC_MINUS;
+	 *	pat_enabled ? _PAGE_CACHE_MODE_UC : _PAGE_CACHE_MODE_UC_MINUS;
 	 *
 	 * Till we fix all X drivers to use ioremap_wc(), we will use
 	 * UC MINUS.
 	 */
-	unsigned long val = _PAGE_CACHE_UC_MINUS;
+	enum page_cache_mode pcm = _PAGE_CACHE_MODE_UC_MINUS;
 
-	return __ioremap_caller(phys_addr, size, val,
+	return __ioremap_caller(phys_addr, size, pcm,
 				__builtin_return_address(0));
 }
 EXPORT_SYMBOL(ioremap_nocache);
@@ -253,7 +257,7 @@ EXPORT_SYMBOL(ioremap_nocache);
 void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
 {
 	if (pat_enabled)
-		return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WC,
+		return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WC,
 					__builtin_return_address(0));
 	else
 		return ioremap_nocache(phys_addr, size);
@@ -262,7 +266,7 @@ EXPORT_SYMBOL(ioremap_wc);
 
 void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size)
 {
-	return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WB,
+	return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WB,
 				__builtin_return_address(0));
 }
 EXPORT_SYMBOL(ioremap_cache);
@@ -270,7 +274,8 @@ EXPORT_SYMBOL(ioremap_cache);
 void __iomem *ioremap_prot(resource_size_t phys_addr, unsigned long size,
 				unsigned long prot_val)
 {
-	return __ioremap_caller(phys_addr, size, (prot_val & _PAGE_CACHE_MASK),
+	return __ioremap_caller(phys_addr, size,
+				pgprot2cachemode(__pgprot(prot_val)),
 				__builtin_return_address(0));
 }
 EXPORT_SYMBOL(ioremap_prot);
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 2f3744f..8f68a83 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -462,7 +462,7 @@ int io_reserve_memtype(resource_size_t start, resource_size_t end,
 	if (!is_new_memtype_allowed(start, size, req_type, new_type))
 		goto out_free;
 
-	if (kernel_map_sync_memtype(start, size, new_prot) < 0)
+	if (kernel_map_sync_memtype(start, size, new_type) < 0)
 		goto out_free;
 
 	*type = new_type;
@@ -560,7 +560,8 @@ int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
  * Change the memory type for the physial address range in kernel identity
  * mapping space if that range is a part of identity map.
  */
-int kernel_map_sync_memtype(u64 base, unsigned long size, unsigned long flags)
+int kernel_map_sync_memtype(u64 base, unsigned long size,
+			    enum page_cache_mode pcm)
 {
 	unsigned long id_sz;
 
@@ -578,11 +579,11 @@ int kernel_map_sync_memtype(u64 base, unsigned long size, unsigned long flags)
 				__pa(high_memory) - base :
 				size;
 
-	if (ioremap_change_attr((unsigned long)__va(base), id_sz, flags) < 0) {
+	if (ioremap_change_attr((unsigned long)__va(base), id_sz, pcm) < 0) {
 		printk(KERN_INFO "%s:%d ioremap_change_attr failed %s "
 			"for [mem %#010Lx-%#010Lx]\n",
 			current->comm, current->pid,
-			cattr_name(flags),
+			cattr_name(cachemode2protval(pcm)),
 			base, (unsigned long long)(base + size-1));
 		return -EINVAL;
 	}
@@ -656,7 +657,8 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 				     flags);
 	}
 
-	if (kernel_map_sync_memtype(paddr, size, flags) < 0) {
+	if (kernel_map_sync_memtype(paddr, size,
+				    pgprot2cachemode(__pgprot(flags))) < 0) {
 		free_memtype(paddr, paddr + size);
 		return -EINVAL;
 	}
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHGy-0002RI-If; Mon, 03 Nov 2014 13:02:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGw-0002QK-S1
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4A/60-09936-5DC77545; Mon, 03 Nov 2014 13:02:13 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415019732!12409928!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7918 invoked from network); 3 Nov 2014 13:02:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:12 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 63AC6ACFC;
	Mon,  3 Nov 2014 13:02:12 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:52 +0100
Message-Id: <1415019724-4317-7-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 06/18] x86: Use new cache mode type in
	arch/x86/mm/init_64.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/mm/init_64.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 4cb8763..5390a5f 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -338,12 +338,15 @@ pte_t * __init populate_extra_pte(unsigned long vaddr)
  * Create large page table mappings for a range of physical addresses.
  */
 static void __init __init_extra_mapping(unsigned long phys, unsigned long size,
-						pgprot_t prot)
+					enum page_cache_mode cache)
 {
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
+	pgprot_t prot;
 
+	pgprot_val(prot) = pgprot_val(PAGE_KERNEL_LARGE) |
+		pgprot_val(pgprot_4k_2_large(cachemode2pgprot(cache)));
 	BUG_ON((phys & ~PMD_MASK) || (size & ~PMD_MASK));
 	for (; size; phys += PMD_SIZE, size -= PMD_SIZE) {
 		pgd = pgd_offset_k((unsigned long)__va(phys));
@@ -366,12 +369,12 @@ static void __init __init_extra_mapping(unsigned long phys, unsigned long size,
 
 void __init init_extra_mapping_wb(unsigned long phys, unsigned long size)
 {
-	__init_extra_mapping(phys, size, PAGE_KERNEL_LARGE);
+	__init_extra_mapping(phys, size, _PAGE_CACHE_MODE_WB);
 }
 
 void __init init_extra_mapping_uc(unsigned long phys, unsigned long size)
 {
-	__init_extra_mapping(phys, size, PAGE_KERNEL_LARGE_NOCACHE);
+	__init_extra_mapping(phys, size, _PAGE_CACHE_MODE_UC);
 }
 
 /*
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHH1-0002Ua-Rp; Mon, 03 Nov 2014 13:02:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH0-0002Rk-1T
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	94/6B-24532-9DC77545; Mon, 03 Nov 2014 13:02:17 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415019735!12396092!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3377 invoked from network); 3 Nov 2014 13:02:16 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:16 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8E14CAD7F;
	Mon,  3 Nov 2014 13:02:15 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:59 +0100
Message-Id: <1415019724-4317-14-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 13/18] x86: Use new cache mode type in
	memtype related functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/cacheflush.h |  38 ++++++++------
 arch/x86/include/asm/pat.h        |   2 +-
 arch/x86/mm/ioremap.c             |   5 +-
 arch/x86/mm/pageattr.c            |   9 ++--
 arch/x86/mm/pat.c                 | 102 ++++++++++++++++++--------------------
 arch/x86/mm/pat_internal.h        |  22 ++++----
 arch/x86/mm/pat_rbtree.c          |   8 +--
 7 files changed, 96 insertions(+), 90 deletions(-)

diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
index 9863ee3..157644b 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -9,10 +9,10 @@
 /*
  * X86 PAT uses page flags WC and Uncached together to keep track of
  * memory type of pages that have backing page struct. X86 PAT supports 3
- * different memory types, _PAGE_CACHE_WB, _PAGE_CACHE_WC and
- * _PAGE_CACHE_UC_MINUS and fourth state where page's memory type has not
+ * different memory types, _PAGE_CACHE_MODE_WB, _PAGE_CACHE_MODE_WC and
+ * _PAGE_CACHE_MODE_UC_MINUS and fourth state where page's memory type has not
  * been changed from its default (value of -1 used to denote this).
- * Note we do not support _PAGE_CACHE_UC here.
+ * Note we do not support _PAGE_CACHE_MODE_UC here.
  */
 
 #define _PGMT_DEFAULT		0
@@ -22,36 +22,40 @@
 #define _PGMT_MASK		(1UL << PG_uncached | 1UL << PG_arch_1)
 #define _PGMT_CLEAR_MASK	(~_PGMT_MASK)
 
-static inline unsigned long get_page_memtype(struct page *pg)
+static inline enum page_cache_mode get_page_memtype(struct page *pg)
 {
 	unsigned long pg_flags = pg->flags & _PGMT_MASK;
 
 	if (pg_flags == _PGMT_DEFAULT)
 		return -1;
 	else if (pg_flags == _PGMT_WC)
-		return _PAGE_CACHE_WC;
+		return _PAGE_CACHE_MODE_WC;
 	else if (pg_flags == _PGMT_UC_MINUS)
-		return _PAGE_CACHE_UC_MINUS;
+		return _PAGE_CACHE_MODE_UC_MINUS;
 	else
-		return _PAGE_CACHE_WB;
+		return _PAGE_CACHE_MODE_WB;
 }
 
-static inline void set_page_memtype(struct page *pg, unsigned long memtype)
+static inline void set_page_memtype(struct page *pg,
+				    enum page_cache_mode memtype)
 {
-	unsigned long memtype_flags = _PGMT_DEFAULT;
+	unsigned long memtype_flags;
 	unsigned long old_flags;
 	unsigned long new_flags;
 
 	switch (memtype) {
-	case _PAGE_CACHE_WC:
+	case _PAGE_CACHE_MODE_WC:
 		memtype_flags = _PGMT_WC;
 		break;
-	case _PAGE_CACHE_UC_MINUS:
+	case _PAGE_CACHE_MODE_UC_MINUS:
 		memtype_flags = _PGMT_UC_MINUS;
 		break;
-	case _PAGE_CACHE_WB:
+	case _PAGE_CACHE_MODE_WB:
 		memtype_flags = _PGMT_WB;
 		break;
+	default:
+		memtype_flags = _PGMT_DEFAULT;
+		break;
 	}
 
 	do {
@@ -60,8 +64,14 @@ static inline void set_page_memtype(struct page *pg, unsigned long memtype)
 	} while (cmpxchg(&pg->flags, old_flags, new_flags) != old_flags);
 }
 #else
-static inline unsigned long get_page_memtype(struct page *pg) { return -1; }
-static inline void set_page_memtype(struct page *pg, unsigned long memtype) { }
+static inline enum page_cache_mode get_page_memtype(struct page *pg)
+{
+	return -1;
+}
+static inline void set_page_memtype(struct page *pg,
+				    enum page_cache_mode memtype)
+{
+}
 #endif
 
 /*
diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index d35ee2d..150407a 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -13,7 +13,7 @@ static const int pat_enabled;
 extern void pat_init(void);
 
 extern int reserve_memtype(u64 start, u64 end,
-		unsigned long req_type, unsigned long *ret_type);
+		enum page_cache_mode req_pcm, enum page_cache_mode *ret_pcm);
 extern int free_memtype(u64 start, u64 end);
 
 extern int kernel_map_sync_memtype(u64 base, unsigned long size,
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index f31507f..8832e51 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -83,7 +83,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 	const unsigned long unaligned_size = size;
 	struct vm_struct *area;
 	enum page_cache_mode new_pcm;
-	unsigned long new_prot_val;
 	pgprot_t prot;
 	int retval;
 	void __iomem *ret_addr;
@@ -135,14 +134,12 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 	size = PAGE_ALIGN(last_addr+1) - phys_addr;
 
 	retval = reserve_memtype(phys_addr, (u64)phys_addr + size,
-				 cachemode2protval(pcm), &new_prot_val);
+						pcm, &new_pcm);
 	if (retval) {
 		printk(KERN_ERR "ioremap reserve_memtype failed %d\n", retval);
 		return NULL;
 	}
 
-	new_pcm = pgprot2cachemode(__pgprot(new_prot_val));
-
 	if (pcm != new_pcm) {
 		if (!is_new_memtype_allowed(phys_addr, size, pcm, new_pcm)) {
 			printk(KERN_ERR
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 9f7e1b4..de807c9 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1451,7 +1451,7 @@ int set_memory_uc(unsigned long addr, int numpages)
 	 * for now UC MINUS. see comments in ioremap_nocache()
 	 */
 	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
-			    _PAGE_CACHE_UC_MINUS, NULL);
+			      _PAGE_CACHE_MODE_UC_MINUS, NULL);
 	if (ret)
 		goto out_err;
 
@@ -1479,7 +1479,7 @@ static int _set_memory_array(unsigned long *addr, int addrinarray,
 	 */
 	for (i = 0; i < addrinarray; i++) {
 		ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE,
-					cachemode2protval(new_type), NULL);
+					new_type, NULL);
 		if (ret)
 			goto out_free;
 	}
@@ -1544,7 +1544,7 @@ int set_memory_wc(unsigned long addr, int numpages)
 		return set_memory_uc(addr, numpages);
 
 	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
-		_PAGE_CACHE_WC, NULL);
+		_PAGE_CACHE_MODE_WC, NULL);
 	if (ret)
 		goto out_err;
 
@@ -1662,8 +1662,7 @@ static int _set_pages_array(struct page **pages, int addrinarray,
 			continue;
 		start = page_to_pfn(pages[i]) << PAGE_SHIFT;
 		end = start + PAGE_SIZE;
-		if (reserve_memtype(start, end, cachemode2protval(new_type),
-				    NULL))
+		if (reserve_memtype(start, end, new_type, NULL))
 			goto err_out;
 	}
 
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 8f68a83..ef75f3f 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -139,20 +139,21 @@ static DEFINE_SPINLOCK(memtype_lock);	/* protects memtype accesses */
  * The intersection is based on "Effective Memory Type" tables in IA-32
  * SDM vol 3a
  */
-static unsigned long pat_x_mtrr_type(u64 start, u64 end, unsigned long req_type)
+static unsigned long pat_x_mtrr_type(u64 start, u64 end,
+				     enum page_cache_mode req_type)
 {
 	/*
 	 * Look for MTRR hint to get the effective type in case where PAT
 	 * request is for WB.
 	 */
-	if (req_type == _PAGE_CACHE_WB) {
+	if (req_type == _PAGE_CACHE_MODE_WB) {
 		u8 mtrr_type;
 
 		mtrr_type = mtrr_type_lookup(start, end);
 		if (mtrr_type != MTRR_TYPE_WRBACK)
-			return _PAGE_CACHE_UC_MINUS;
+			return _PAGE_CACHE_MODE_UC_MINUS;
 
-		return _PAGE_CACHE_WB;
+		return _PAGE_CACHE_MODE_WB;
 	}
 
 	return req_type;
@@ -207,25 +208,26 @@ static int pat_pagerange_is_ram(resource_size_t start, resource_size_t end)
  * - Find the memtype of all the pages in the range, look for any conflicts
  * - In case of no conflicts, set the new memtype for pages in the range
  */
-static int reserve_ram_pages_type(u64 start, u64 end, unsigned long req_type,
-				  unsigned long *new_type)
+static int reserve_ram_pages_type(u64 start, u64 end,
+				  enum page_cache_mode req_type,
+				  enum page_cache_mode *new_type)
 {
 	struct page *page;
 	u64 pfn;
 
-	if (req_type == _PAGE_CACHE_UC) {
+	if (req_type == _PAGE_CACHE_MODE_UC) {
 		/* We do not support strong UC */
 		WARN_ON_ONCE(1);
-		req_type = _PAGE_CACHE_UC_MINUS;
+		req_type = _PAGE_CACHE_MODE_UC_MINUS;
 	}
 
 	for (pfn = (start >> PAGE_SHIFT); pfn < (end >> PAGE_SHIFT); ++pfn) {
-		unsigned long type;
+		enum page_cache_mode type;
 
 		page = pfn_to_page(pfn);
 		type = get_page_memtype(page);
 		if (type != -1) {
-			printk(KERN_INFO "reserve_ram_pages_type failed [mem %#010Lx-%#010Lx], track 0x%lx, req 0x%lx\n",
+			pr_info("reserve_ram_pages_type failed [mem %#010Lx-%#010Lx], track 0x%x, req 0x%x\n",
 				start, end - 1, type, req_type);
 			if (new_type)
 				*new_type = type;
@@ -258,21 +260,21 @@ static int free_ram_pages_type(u64 start, u64 end)
 
 /*
  * req_type typically has one of the:
- * - _PAGE_CACHE_WB
- * - _PAGE_CACHE_WC
- * - _PAGE_CACHE_UC_MINUS
- * - _PAGE_CACHE_UC
+ * - _PAGE_CACHE_MODE_WB
+ * - _PAGE_CACHE_MODE_WC
+ * - _PAGE_CACHE_MODE_UC_MINUS
+ * - _PAGE_CACHE_MODE_UC
  *
  * If new_type is NULL, function will return an error if it cannot reserve the
  * region with req_type. If new_type is non-NULL, function will return
  * available type in new_type in case of no error. In case of any error
  * it will return a negative return value.
  */
-int reserve_memtype(u64 start, u64 end, unsigned long req_type,
-		    unsigned long *new_type)
+int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type,
+		    enum page_cache_mode *new_type)
 {
 	struct memtype *new;
-	unsigned long actual_type;
+	enum page_cache_mode actual_type;
 	int is_range_ram;
 	int err = 0;
 
@@ -281,10 +283,10 @@ int reserve_memtype(u64 start, u64 end, unsigned long req_type,
 	if (!pat_enabled) {
 		/* This is identical to page table setting without PAT */
 		if (new_type) {
-			if (req_type == _PAGE_CACHE_WC)
-				*new_type = _PAGE_CACHE_UC_MINUS;
+			if (req_type == _PAGE_CACHE_MODE_WC)
+				*new_type = _PAGE_CACHE_MODE_UC_MINUS;
 			else
-				*new_type = req_type & _PAGE_CACHE_MASK;
+				*new_type = req_type;
 		}
 		return 0;
 	}
@@ -292,7 +294,7 @@ int reserve_memtype(u64 start, u64 end, unsigned long req_type,
 	/* Low ISA region is always mapped WB in page table. No need to track */
 	if (x86_platform.is_untracked_pat_range(start, end)) {
 		if (new_type)
-			*new_type = _PAGE_CACHE_WB;
+			*new_type = _PAGE_CACHE_MODE_WB;
 		return 0;
 	}
 
@@ -302,7 +304,7 @@ int reserve_memtype(u64 start, u64 end, unsigned long req_type,
 	 * tools and ACPI tools). Use WB request for WB memory and use
 	 * UC_MINUS otherwise.
 	 */
-	actual_type = pat_x_mtrr_type(start, end, req_type & _PAGE_CACHE_MASK);
+	actual_type = pat_x_mtrr_type(start, end, req_type);
 
 	if (new_type)
 		*new_type = actual_type;
@@ -408,7 +410,7 @@ static enum page_cache_mode lookup_memtype(u64 paddr)
 	if (pat_pagerange_is_ram(paddr, paddr + PAGE_SIZE)) {
 		struct page *page;
 		page = pfn_to_page(paddr >> PAGE_SHIFT);
-		rettype = pgprot2cachemode(__pgprot(get_page_memtype(page)));
+		rettype = get_page_memtype(page);
 		/*
 		 * -1 from get_page_memtype() implies RAM page is in its
 		 * default state and not reserved, and hence of type WB
@@ -423,7 +425,7 @@ static enum page_cache_mode lookup_memtype(u64 paddr)
 
 	entry = rbt_memtype_lookup(paddr);
 	if (entry != NULL)
-		rettype = pgprot2cachemode(__pgprot(entry->type));
+		rettype = entry->type;
 	else
 		rettype = _PAGE_CACHE_MODE_UC_MINUS;
 
@@ -447,18 +449,14 @@ int io_reserve_memtype(resource_size_t start, resource_size_t end,
 	resource_size_t size = end - start;
 	enum page_cache_mode req_type = *type;
 	enum page_cache_mode new_type;
-	unsigned long new_prot;
 	int ret;
 
 	WARN_ON_ONCE(iomem_map_sanity_check(start, size));
 
-	ret = reserve_memtype(start, end, cachemode2protval(req_type),
-				&new_prot);
+	ret = reserve_memtype(start, end, req_type, &new_type);
 	if (ret)
 		goto out_err;
 
-	new_type = pgprot2cachemode(__pgprot(new_prot));
-
 	if (!is_new_memtype_allowed(start, size, req_type, new_type))
 		goto out_free;
 
@@ -524,13 +522,13 @@ static inline int range_is_allowed(unsigned long pfn, unsigned long size)
 int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
 				unsigned long size, pgprot_t *vma_prot)
 {
-	unsigned long flags = _PAGE_CACHE_WB;
+	enum page_cache_mode pcm = _PAGE_CACHE_MODE_WB;
 
 	if (!range_is_allowed(pfn, size))
 		return 0;
 
 	if (file->f_flags & O_DSYNC)
-		flags = _PAGE_CACHE_UC_MINUS;
+		pcm = _PAGE_CACHE_MODE_UC_MINUS;
 
 #ifdef CONFIG_X86_32
 	/*
@@ -547,12 +545,12 @@ int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
 	      boot_cpu_has(X86_FEATURE_CYRIX_ARR) ||
 	      boot_cpu_has(X86_FEATURE_CENTAUR_MCR)) &&
 	    (pfn << PAGE_SHIFT) >= __pa(high_memory)) {
-		flags = _PAGE_CACHE_UC;
+		pcm = _PAGE_CACHE_MODE_UC;
 	}
 #endif
 
 	*vma_prot = __pgprot((pgprot_val(*vma_prot) & ~_PAGE_CACHE_MASK) |
-			     flags);
+			     cachemode2protval(pcm));
 	return 1;
 }
 
@@ -583,7 +581,7 @@ int kernel_map_sync_memtype(u64 base, unsigned long size,
 		printk(KERN_INFO "%s:%d ioremap_change_attr failed %s "
 			"for [mem %#010Lx-%#010Lx]\n",
 			current->comm, current->pid,
-			cattr_name(cachemode2protval(pcm)),
+			cattr_name(pcm),
 			base, (unsigned long long)(base + size-1));
 		return -EINVAL;
 	}
@@ -600,8 +598,8 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 {
 	int is_ram = 0;
 	int ret;
-	unsigned long want_flags = (pgprot_val(*vma_prot) & _PAGE_CACHE_MASK);
-	unsigned long flags = want_flags;
+	enum page_cache_mode want_pcm = pgprot2cachemode(*vma_prot);
+	enum page_cache_mode pcm = want_pcm;
 
 	is_ram = pat_pagerange_is_ram(paddr, paddr + size);
 
@@ -614,38 +612,36 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 		if (!pat_enabled)
 			return 0;
 
-		flags = cachemode2protval(lookup_memtype(paddr));
-		if (want_flags != flags) {
+		pcm = lookup_memtype(paddr);
+		if (want_pcm != pcm) {
 			printk(KERN_WARNING "%s:%d map pfn RAM range req %s for [mem %#010Lx-%#010Lx], got %s\n",
 				current->comm, current->pid,
-				cattr_name(want_flags),
+				cattr_name(want_pcm),
 				(unsigned long long)paddr,
 				(unsigned long long)(paddr + size - 1),
-				cattr_name(flags));
+				cattr_name(pcm));
 			*vma_prot = __pgprot((pgprot_val(*vma_prot) &
-					      (~_PAGE_CACHE_MASK)) |
-					     flags);
+					     (~_PAGE_CACHE_MASK)) |
+					     cachemode2protval(pcm));
 		}
 		return 0;
 	}
 
-	ret = reserve_memtype(paddr, paddr + size, want_flags, &flags);
+	ret = reserve_memtype(paddr, paddr + size, want_pcm, &pcm);
 	if (ret)
 		return ret;
 
-	if (flags != want_flags) {
+	if (pcm != want_pcm) {
 		if (strict_prot ||
-		    !is_new_memtype_allowed(paddr, size,
-				pgprot2cachemode(__pgprot(want_flags)),
-				pgprot2cachemode(__pgprot(flags)))) {
+		    !is_new_memtype_allowed(paddr, size, want_pcm, pcm)) {
 			free_memtype(paddr, paddr + size);
 			printk(KERN_ERR "%s:%d map pfn expected mapping type %s"
 				" for [mem %#010Lx-%#010Lx], got %s\n",
 				current->comm, current->pid,
-				cattr_name(want_flags),
+				cattr_name(want_pcm),
 				(unsigned long long)paddr,
 				(unsigned long long)(paddr + size - 1),
-				cattr_name(flags));
+				cattr_name(pcm));
 			return -EINVAL;
 		}
 		/*
@@ -654,11 +650,10 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 		 */
 		*vma_prot = __pgprot((pgprot_val(*vma_prot) &
 				      (~_PAGE_CACHE_MASK)) |
-				     flags);
+				     cachemode2protval(pcm));
 	}
 
-	if (kernel_map_sync_memtype(paddr, size,
-				    pgprot2cachemode(__pgprot(flags))) < 0) {
+	if (kernel_map_sync_memtype(paddr, size, pcm) < 0) {
 		free_memtype(paddr, paddr + size);
 		return -EINVAL;
 	}
@@ -799,7 +794,8 @@ void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
 pgprot_t pgprot_writecombine(pgprot_t prot)
 {
 	if (pat_enabled)
-		return __pgprot(pgprot_val(prot) | _PAGE_CACHE_WC);
+		return __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_WC));
 	else
 		return pgprot_noncached(prot);
 }
diff --git a/arch/x86/mm/pat_internal.h b/arch/x86/mm/pat_internal.h
index 77e5ba1..f641162 100644
--- a/arch/x86/mm/pat_internal.h
+++ b/arch/x86/mm/pat_internal.h
@@ -10,30 +10,32 @@ struct memtype {
 	u64			start;
 	u64			end;
 	u64			subtree_max_end;
-	unsigned long		type;
+	enum page_cache_mode	type;
 	struct rb_node		rb;
 };
 
-static inline char *cattr_name(unsigned long flags)
+static inline char *cattr_name(enum page_cache_mode pcm)
 {
-	switch (flags & _PAGE_CACHE_MASK) {
-	case _PAGE_CACHE_UC:		return "uncached";
-	case _PAGE_CACHE_UC_MINUS:	return "uncached-minus";
-	case _PAGE_CACHE_WB:		return "write-back";
-	case _PAGE_CACHE_WC:		return "write-combining";
-	default:			return "broken";
+	switch (pcm) {
+	case _PAGE_CACHE_MODE_UC:		return "uncached";
+	case _PAGE_CACHE_MODE_UC_MINUS:		return "uncached-minus";
+	case _PAGE_CACHE_MODE_WB:		return "write-back";
+	case _PAGE_CACHE_MODE_WC:		return "write-combining";
+	case _PAGE_CACHE_MODE_WT:		return "write-through";
+	case _PAGE_CACHE_MODE_WP:		return "write-protected";
+	default:				return "broken";
 	}
 }
 
 #ifdef CONFIG_X86_PAT
 extern int rbt_memtype_check_insert(struct memtype *new,
-					unsigned long *new_type);
+					enum page_cache_mode *new_type);
 extern struct memtype *rbt_memtype_erase(u64 start, u64 end);
 extern struct memtype *rbt_memtype_lookup(u64 addr);
 extern int rbt_memtype_copy_nth_element(struct memtype *out, loff_t pos);
 #else
 static inline int rbt_memtype_check_insert(struct memtype *new,
-					unsigned long *new_type)
+					enum page_cache_mode *new_type)
 { return 0; }
 static inline struct memtype *rbt_memtype_erase(u64 start, u64 end)
 { return NULL; }
diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
index 415f6c4..6582adc 100644
--- a/arch/x86/mm/pat_rbtree.c
+++ b/arch/x86/mm/pat_rbtree.c
@@ -122,11 +122,12 @@ static struct memtype *memtype_rb_exact_match(struct rb_root *root,
 
 static int memtype_rb_check_conflict(struct rb_root *root,
 				u64 start, u64 end,
-				unsigned long reqtype, unsigned long *newtype)
+				enum page_cache_mode reqtype,
+				enum page_cache_mode *newtype)
 {
 	struct rb_node *node;
 	struct memtype *match;
-	int found_type = reqtype;
+	enum page_cache_mode found_type = reqtype;
 
 	match = memtype_rb_lowest_match(&memtype_rbroot, start, end);
 	if (match == NULL)
@@ -187,7 +188,8 @@ static void memtype_rb_insert(struct rb_root *root, struct memtype *newdata)
 	rb_insert_augmented(&newdata->rb, root, &memtype_rb_augment_cb);
 }
 
-int rbt_memtype_check_insert(struct memtype *new, unsigned long *ret_type)
+int rbt_memtype_check_insert(struct memtype *new,
+			     enum page_cache_mode *ret_type)
 {
 	int err = 0;
 
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHH4-0002XC-D5; Mon, 03 Nov 2014 13:02:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH2-0002UU-90
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B3/64-09842-9DC77545; Mon, 03 Nov 2014 13:02:17 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415019737!8954755!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21077 invoked from network); 3 Nov 2014 13:02:17 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:17 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DDD6AAD6F;
	Mon,  3 Nov 2014 13:02:16 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:02:02 +0100
Message-Id: <1415019724-4317-17-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 16/18] x86: Respect PAT bit when copying pte
	values between large and normal pages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 PAT bit in the ptes is not moved to the correct position when
copying page protection attributes between entries of different sized
pages. Translate the ptes according to their page size.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/mm/pageattr.c | 33 +++++++++++++++++++++++----------
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index de807c9..6c8e3fd 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -485,14 +485,23 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 
 	/*
 	 * We are safe now. Check whether the new pgprot is the same:
+	 * Convert protection attributes to 4k-format, as cpa->mask* are set
+	 * up accordingly.
 	 */
 	old_pte = *kpte;
-	old_prot = req_prot = pte_pgprot(old_pte);
+	old_prot = req_prot = pgprot_large_2_4k(pte_pgprot(old_pte));
 
 	pgprot_val(req_prot) &= ~pgprot_val(cpa->mask_clr);
 	pgprot_val(req_prot) |= pgprot_val(cpa->mask_set);
 
 	/*
+	 * req_prot is in format of 4k pages. It must be converted to large
+	 * page format: the caching mode includes the PAT bit located at
+	 * different bit positions in the two formats.
+	 */
+	req_prot = pgprot_4k_2_large(req_prot);
+
+	/*
 	 * Set the PSE and GLOBAL flags only if the PRESENT flag is
 	 * set otherwise pmd_present/pmd_huge will return true even on
 	 * a non present pmd. The canon_pgprot will clear _PAGE_GLOBAL
@@ -585,13 +594,10 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
 
 	paravirt_alloc_pte(&init_mm, page_to_pfn(base));
 	ref_prot = pte_pgprot(pte_clrhuge(*kpte));
-	/*
-	 * If we ever want to utilize the PAT bit, we need to
-	 * update this function to make sure it's converted from
-	 * bit 12 to bit 7 when we cross from the 2MB level to
-	 * the 4K level:
-	 */
-	WARN_ON_ONCE(pgprot_val(ref_prot) & _PAGE_PAT_LARGE);
+
+	/* promote PAT bit to correct position */
+	if (level == PG_LEVEL_2M)
+		ref_prot = pgprot_large_2_4k(ref_prot);
 
 #ifdef CONFIG_X86_64
 	if (level == PG_LEVEL_1G) {
@@ -879,6 +885,7 @@ static int populate_pmd(struct cpa_data *cpa,
 {
 	unsigned int cur_pages = 0;
 	pmd_t *pmd;
+	pgprot_t pmd_pgprot;
 
 	/*
 	 * Not on a 2M boundary?
@@ -910,6 +917,8 @@ static int populate_pmd(struct cpa_data *cpa,
 	if (num_pages == cur_pages)
 		return cur_pages;
 
+	pmd_pgprot = pgprot_4k_2_large(pgprot);
+
 	while (end - start >= PMD_SIZE) {
 
 		/*
@@ -921,7 +930,8 @@ static int populate_pmd(struct cpa_data *cpa,
 
 		pmd = pmd_offset(pud, start);
 
-		set_pmd(pmd, __pmd(cpa->pfn | _PAGE_PSE | massage_pgprot(pgprot)));
+		set_pmd(pmd, __pmd(cpa->pfn | _PAGE_PSE |
+				   massage_pgprot(pmd_pgprot)));
 
 		start	  += PMD_SIZE;
 		cpa->pfn  += PMD_SIZE;
@@ -949,6 +959,7 @@ static int populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd,
 	pud_t *pud;
 	unsigned long end;
 	int cur_pages = 0;
+	pgprot_t pud_pgprot;
 
 	end = start + (cpa->numpages << PAGE_SHIFT);
 
@@ -986,12 +997,14 @@ static int populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd,
 		return cur_pages;
 
 	pud = pud_offset(pgd, start);
+	pud_pgprot = pgprot_4k_2_large(pgprot);
 
 	/*
 	 * Map everything starting from the Gb boundary, possibly with 1G pages
 	 */
 	while (end - start >= PUD_SIZE) {
-		set_pud(pud, __pud(cpa->pfn | _PAGE_PSE | massage_pgprot(pgprot)));
+		set_pud(pud, __pud(cpa->pfn | _PAGE_PSE |
+				   massage_pgprot(pud_pgprot)));
 
 		start	  += PUD_SIZE;
 		cpa->pfn  += PUD_SIZE;
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHH4-0002XC-D5; Mon, 03 Nov 2014 13:02:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH2-0002UU-90
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B3/64-09842-9DC77545; Mon, 03 Nov 2014 13:02:17 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415019737!8954755!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21077 invoked from network); 3 Nov 2014 13:02:17 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:17 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DDD6AAD6F;
	Mon,  3 Nov 2014 13:02:16 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:02:02 +0100
Message-Id: <1415019724-4317-17-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 16/18] x86: Respect PAT bit when copying pte
	values between large and normal pages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 PAT bit in the ptes is not moved to the correct position when
copying page protection attributes between entries of different sized
pages. Translate the ptes according to their page size.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/mm/pageattr.c | 33 +++++++++++++++++++++++----------
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index de807c9..6c8e3fd 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -485,14 +485,23 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 
 	/*
 	 * We are safe now. Check whether the new pgprot is the same:
+	 * Convert protection attributes to 4k-format, as cpa->mask* are set
+	 * up accordingly.
 	 */
 	old_pte = *kpte;
-	old_prot = req_prot = pte_pgprot(old_pte);
+	old_prot = req_prot = pgprot_large_2_4k(pte_pgprot(old_pte));
 
 	pgprot_val(req_prot) &= ~pgprot_val(cpa->mask_clr);
 	pgprot_val(req_prot) |= pgprot_val(cpa->mask_set);
 
 	/*
+	 * req_prot is in format of 4k pages. It must be converted to large
+	 * page format: the caching mode includes the PAT bit located at
+	 * different bit positions in the two formats.
+	 */
+	req_prot = pgprot_4k_2_large(req_prot);
+
+	/*
 	 * Set the PSE and GLOBAL flags only if the PRESENT flag is
 	 * set otherwise pmd_present/pmd_huge will return true even on
 	 * a non present pmd. The canon_pgprot will clear _PAGE_GLOBAL
@@ -585,13 +594,10 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
 
 	paravirt_alloc_pte(&init_mm, page_to_pfn(base));
 	ref_prot = pte_pgprot(pte_clrhuge(*kpte));
-	/*
-	 * If we ever want to utilize the PAT bit, we need to
-	 * update this function to make sure it's converted from
-	 * bit 12 to bit 7 when we cross from the 2MB level to
-	 * the 4K level:
-	 */
-	WARN_ON_ONCE(pgprot_val(ref_prot) & _PAGE_PAT_LARGE);
+
+	/* promote PAT bit to correct position */
+	if (level == PG_LEVEL_2M)
+		ref_prot = pgprot_large_2_4k(ref_prot);
 
 #ifdef CONFIG_X86_64
 	if (level == PG_LEVEL_1G) {
@@ -879,6 +885,7 @@ static int populate_pmd(struct cpa_data *cpa,
 {
 	unsigned int cur_pages = 0;
 	pmd_t *pmd;
+	pgprot_t pmd_pgprot;
 
 	/*
 	 * Not on a 2M boundary?
@@ -910,6 +917,8 @@ static int populate_pmd(struct cpa_data *cpa,
 	if (num_pages == cur_pages)
 		return cur_pages;
 
+	pmd_pgprot = pgprot_4k_2_large(pgprot);
+
 	while (end - start >= PMD_SIZE) {
 
 		/*
@@ -921,7 +930,8 @@ static int populate_pmd(struct cpa_data *cpa,
 
 		pmd = pmd_offset(pud, start);
 
-		set_pmd(pmd, __pmd(cpa->pfn | _PAGE_PSE | massage_pgprot(pgprot)));
+		set_pmd(pmd, __pmd(cpa->pfn | _PAGE_PSE |
+				   massage_pgprot(pmd_pgprot)));
 
 		start	  += PMD_SIZE;
 		cpa->pfn  += PMD_SIZE;
@@ -949,6 +959,7 @@ static int populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd,
 	pud_t *pud;
 	unsigned long end;
 	int cur_pages = 0;
+	pgprot_t pud_pgprot;
 
 	end = start + (cpa->numpages << PAGE_SHIFT);
 
@@ -986,12 +997,14 @@ static int populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd,
 		return cur_pages;
 
 	pud = pud_offset(pgd, start);
+	pud_pgprot = pgprot_4k_2_large(pgprot);
 
 	/*
 	 * Map everything starting from the Gb boundary, possibly with 1G pages
 	 */
 	while (end - start >= PUD_SIZE) {
-		set_pud(pud, __pud(cpa->pfn | _PAGE_PSE | massage_pgprot(pgprot)));
+		set_pud(pud, __pud(cpa->pfn | _PAGE_PSE |
+				   massage_pgprot(pud_pgprot)));
 
 		start	  += PUD_SIZE;
 		cpa->pfn  += PUD_SIZE;
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHH2-0002Vu-Pb; Mon, 03 Nov 2014 13:02:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH0-0002SL-CA
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	06/90-09936-9DC77545; Mon, 03 Nov 2014 13:02:17 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415019736!12370016!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14579 invoked from network); 3 Nov 2014 13:02:16 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:16 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 6EA0CAD66;
	Mon,  3 Nov 2014 13:02:16 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:02:01 +0100
Message-Id: <1415019724-4317-16-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 15/18] x86: Support PAT bit in pagetable dump
	for lower levels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dumping page table protection bits is not correct for entries on levels
2 and 3 regarding the PAT bit, which is at a different position as on
level 4.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/mm/dump_pagetables.c | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 95a427e..6c2ca03 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -126,7 +126,7 @@ static void printk_prot(struct seq_file *m, pgprot_t prot, int level, bool dmsg)
 
 	if (!pgprot_val(prot)) {
 		/* Not present */
-		pt_dump_cont_printf(m, dmsg, "                          ");
+		pt_dump_cont_printf(m, dmsg, "                              ");
 	} else {
 		if (pr & _PAGE_USER)
 			pt_dump_cont_printf(m, dmsg, "USR ");
@@ -145,18 +145,16 @@ static void printk_prot(struct seq_file *m, pgprot_t prot, int level, bool dmsg)
 		else
 			pt_dump_cont_printf(m, dmsg, "    ");
 
-		/* Bit 9 has a different meaning on level 3 vs 4 */
-		if (level <= 3) {
-			if (pr & _PAGE_PSE)
-				pt_dump_cont_printf(m, dmsg, "PSE ");
-			else
-				pt_dump_cont_printf(m, dmsg, "    ");
-		} else {
-			if (pr & _PAGE_PAT)
-				pt_dump_cont_printf(m, dmsg, "pat ");
-			else
-				pt_dump_cont_printf(m, dmsg, "    ");
-		}
+		/* Bit 7 has a different meaning on level 3 vs 4 */
+		if (level <= 3 && pr & _PAGE_PSE)
+			pt_dump_cont_printf(m, dmsg, "PSE ");
+		else
+			pt_dump_cont_printf(m, dmsg, "    ");
+		if ((level == 4 && pr & _PAGE_PAT) ||
+		    ((level == 3 || level == 2) && pr & _PAGE_PAT_LARGE))
+			pt_dump_cont_printf(m, dmsg, "pat ");
+		else
+			pt_dump_cont_printf(m, dmsg, "    ");
 		if (pr & _PAGE_GLOBAL)
 			pt_dump_cont_printf(m, dmsg, "GLB ");
 		else
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHH2-0002Vu-Pb; Mon, 03 Nov 2014 13:02:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH0-0002SL-CA
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	06/90-09936-9DC77545; Mon, 03 Nov 2014 13:02:17 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415019736!12370016!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14579 invoked from network); 3 Nov 2014 13:02:16 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:16 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 6EA0CAD66;
	Mon,  3 Nov 2014 13:02:16 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:02:01 +0100
Message-Id: <1415019724-4317-16-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 15/18] x86: Support PAT bit in pagetable dump
	for lower levels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dumping page table protection bits is not correct for entries on levels
2 and 3 regarding the PAT bit, which is at a different position as on
level 4.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/mm/dump_pagetables.c | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 95a427e..6c2ca03 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -126,7 +126,7 @@ static void printk_prot(struct seq_file *m, pgprot_t prot, int level, bool dmsg)
 
 	if (!pgprot_val(prot)) {
 		/* Not present */
-		pt_dump_cont_printf(m, dmsg, "                          ");
+		pt_dump_cont_printf(m, dmsg, "                              ");
 	} else {
 		if (pr & _PAGE_USER)
 			pt_dump_cont_printf(m, dmsg, "USR ");
@@ -145,18 +145,16 @@ static void printk_prot(struct seq_file *m, pgprot_t prot, int level, bool dmsg)
 		else
 			pt_dump_cont_printf(m, dmsg, "    ");
 
-		/* Bit 9 has a different meaning on level 3 vs 4 */
-		if (level <= 3) {
-			if (pr & _PAGE_PSE)
-				pt_dump_cont_printf(m, dmsg, "PSE ");
-			else
-				pt_dump_cont_printf(m, dmsg, "    ");
-		} else {
-			if (pr & _PAGE_PAT)
-				pt_dump_cont_printf(m, dmsg, "pat ");
-			else
-				pt_dump_cont_printf(m, dmsg, "    ");
-		}
+		/* Bit 7 has a different meaning on level 3 vs 4 */
+		if (level <= 3 && pr & _PAGE_PSE)
+			pt_dump_cont_printf(m, dmsg, "PSE ");
+		else
+			pt_dump_cont_printf(m, dmsg, "    ");
+		if ((level == 4 && pr & _PAGE_PAT) ||
+		    ((level == 3 || level == 2) && pr & _PAGE_PAT_LARGE))
+			pt_dump_cont_printf(m, dmsg, "pat ");
+		else
+			pt_dump_cont_printf(m, dmsg, "    ");
 		if (pr & _PAGE_GLOBAL)
 			pt_dump_cont_printf(m, dmsg, "GLB ");
 		else
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHGw-0002QS-W5; Mon, 03 Nov 2014 13:02:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGv-0002Pq-8S
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:13 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	90/48-02712-4DC77545; Mon, 03 Nov 2014 13:02:12 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415019731!12184742!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22424 invoked from network); 3 Nov 2014 13:02:11 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:11 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 25D27ACEE;
	Mon,  3 Nov 2014 13:02:11 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:49 +0100
Message-Id: <1415019724-4317-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 03/18] x86: Use new cache mode type in
	drivers/video/fbdev/gbefb.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/video/fbdev/gbefb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 4aa56ba..6d9ef39 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -54,7 +54,8 @@ struct gbefb_par {
 #endif
 #endif
 #ifdef CONFIG_X86
-#define pgprot_fb(_prot) ((_prot) | _PAGE_PCD)
+#define pgprot_fb(_prot) (((_prot) & ~_PAGE_CACHE_MASK) |	\
+			  cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS))
 #endif
 
 /*
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHGw-0002QS-W5; Mon, 03 Nov 2014 13:02:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGv-0002Pq-8S
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:13 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	90/48-02712-4DC77545; Mon, 03 Nov 2014 13:02:12 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415019731!12184742!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22424 invoked from network); 3 Nov 2014 13:02:11 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:11 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 25D27ACEE;
	Mon,  3 Nov 2014 13:02:11 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:49 +0100
Message-Id: <1415019724-4317-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 03/18] x86: Use new cache mode type in
	drivers/video/fbdev/gbefb.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/video/fbdev/gbefb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 4aa56ba..6d9ef39 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -54,7 +54,8 @@ struct gbefb_par {
 #endif
 #endif
 #ifdef CONFIG_X86
-#define pgprot_fb(_prot) ((_prot) | _PAGE_PCD)
+#define pgprot_fb(_prot) (((_prot) & ~_PAGE_CACHE_MASK) |	\
+			  cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS))
 #endif
 
 /*
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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.xen.org>)
	id 1XlHH4-0002Xg-QZ; Mon, 03 Nov 2014 13:02:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH3-0002Vm-3B
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:21 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	01/74-09842-ADC77545; Mon, 03 Nov 2014 13:02:18 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415019737!11827986!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32761 invoked from network); 3 Nov 2014 13:02:17 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:17 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4C9B6AD8A;
	Mon,  3 Nov 2014 13:02:17 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:02:03 +0100
Message-Id: <1415019724-4317-18-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 17/18] x86: Enable PAT to use cache mode
	translation tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the translation tables from cache mode to pgprot values
according to the PAT settings. This enables changing the cache
attributes of a PAT index in just one place without having to change
at the users side.

With this change it is possible to use the same kernel with different
PAT configurations, e.g. supporting Xen.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pat.h           |  1 +
 arch/x86/include/asm/pgtable_types.h |  4 +++
 arch/x86/mm/init.c                   |  8 ++++++
 arch/x86/mm/mm_internal.h            |  2 ++
 arch/x86/mm/pat.c                    | 50 ++++++++++++++++++++++++++++++++++--
 5 files changed, 63 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index 150407a..91bc4ba 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -11,6 +11,7 @@ static const int pat_enabled;
 #endif
 
 extern void pat_init(void);
+void pat_init_cache_modes(void);
 
 extern int reserve_memtype(u64 start, u64 end,
 		enum page_cache_mode req_pcm, enum page_cache_mode *ret_pcm);
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 6d5f6d1..af447f9 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -351,6 +351,10 @@ extern uint8_t __pte2cachemode_tbl[8];
 	((((cb) >> (_PAGE_BIT_PAT - 2)) & 4) |		\
 	 (((cb) >> (_PAGE_BIT_PCD - 1)) & 2) |		\
 	 (((cb) >> _PAGE_BIT_PWT) & 1))
+#define __cm_idx2pte(i)					\
+	((((i) & 4) << (_PAGE_BIT_PAT - 2)) |		\
+	 (((i) & 2) << (_PAGE_BIT_PCD - 1)) |		\
+	 (((i) & 1) << _PAGE_BIT_PWT))
 
 static inline unsigned long cachemode2protval(enum page_cache_mode pcm)
 {
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index a9776ba..82b41d5 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -716,3 +716,11 @@ void __init zone_sizes_init(void)
 	free_area_init_nodes(max_zone_pfns);
 }
 
+void update_cache_mode_entry(unsigned entry, enum page_cache_mode cache)
+{
+	/* entry 0 MUST be WB (hardwired to speed up translations) */
+	BUG_ON(!entry && cache != _PAGE_CACHE_MODE_WB);
+
+	__cachemode2pte_tbl[cache] = __cm_idx2pte(entry);
+	__pte2cachemode_tbl[entry] = cache;
+}
diff --git a/arch/x86/mm/mm_internal.h b/arch/x86/mm/mm_internal.h
index 6b563a1..62474ba 100644
--- a/arch/x86/mm/mm_internal.h
+++ b/arch/x86/mm/mm_internal.h
@@ -16,4 +16,6 @@ void zone_sizes_init(void);
 
 extern int after_bootmem;
 
+void update_cache_mode_entry(unsigned entry, enum page_cache_mode cache);
+
 #endif	/* __X86_MM_INTERNAL_H */
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index ef75f3f..4c60127 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -31,6 +31,7 @@
 #include <asm/io.h>
 
 #include "pat_internal.h"
+#include "mm_internal.h"
 
 #ifdef CONFIG_X86_PAT
 int __read_mostly pat_enabled = 1;
@@ -75,6 +76,52 @@ enum {
 	PAT_UC_MINUS = 7,	/* UC, but can be overriden by MTRR */
 };
 
+#define CM(c) (_PAGE_CACHE_MODE_ ## c)
+
+static enum page_cache_mode pat_get_cache_mode(unsigned pat_val, char *msg)
+{
+	enum page_cache_mode cache;
+	char *cache_mode;
+
+	switch (pat_val) {
+	case PAT_UC:       cache = CM(UC);       cache_mode = "UC  "; break;
+	case PAT_WC:       cache = CM(WC);       cache_mode = "WC  "; break;
+	case PAT_WT:       cache = CM(WT);       cache_mode = "WT  "; break;
+	case PAT_WP:       cache = CM(WP);       cache_mode = "WP  "; break;
+	case PAT_WB:       cache = CM(WB);       cache_mode = "WB  "; break;
+	case PAT_UC_MINUS: cache = CM(UC_MINUS); cache_mode = "UC- "; break;
+	default:           cache = CM(WB);       cache_mode = "WB  "; break;
+	}
+
+	memcpy(msg, cache_mode, 4);
+
+	return cache;
+}
+
+#undef CM
+
+/*
+ * Update the cache mode to pgprot translation tables according to PAT
+ * configuration.
+ * Using lower indices is preferred, so we start with highest index.
+ */
+void pat_init_cache_modes(void)
+{
+	int i;
+	enum page_cache_mode cache;
+	char pat_msg[33];
+	u64 pat;
+
+	rdmsrl(MSR_IA32_CR_PAT, pat);
+	pat_msg[32] = 0;
+	for (i = 7; i >= 0; i--) {
+		cache = pat_get_cache_mode((pat >> (i * 8)) & 7,
+					   pat_msg + 4 * i);
+		update_cache_mode_entry(i, cache);
+	}
+	pr_info("PAT configuration [0-7]: %s\n", pat_msg);
+}
+
 #define PAT(x, y)	((u64)PAT_ ## y << ((x)*8))
 
 void pat_init(void)
@@ -124,8 +171,7 @@ void pat_init(void)
 	wrmsrl(MSR_IA32_CR_PAT, pat);
 
 	if (boot_cpu)
-		printk(KERN_INFO "x86 PAT enabled: cpu %d, old 0x%Lx, new 0x%Lx\n",
-		       smp_processor_id(), boot_pat_state, pat);
+		pat_init_cache_modes();
 }
 
 #undef PAT
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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.xen.org>)
	id 1XlHH4-0002Xg-QZ; Mon, 03 Nov 2014 13:02:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH3-0002Vm-3B
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:21 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	01/74-09842-ADC77545; Mon, 03 Nov 2014 13:02:18 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415019737!11827986!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32761 invoked from network); 3 Nov 2014 13:02:17 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:17 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4C9B6AD8A;
	Mon,  3 Nov 2014 13:02:17 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:02:03 +0100
Message-Id: <1415019724-4317-18-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 17/18] x86: Enable PAT to use cache mode
	translation tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the translation tables from cache mode to pgprot values
according to the PAT settings. This enables changing the cache
attributes of a PAT index in just one place without having to change
at the users side.

With this change it is possible to use the same kernel with different
PAT configurations, e.g. supporting Xen.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pat.h           |  1 +
 arch/x86/include/asm/pgtable_types.h |  4 +++
 arch/x86/mm/init.c                   |  8 ++++++
 arch/x86/mm/mm_internal.h            |  2 ++
 arch/x86/mm/pat.c                    | 50 ++++++++++++++++++++++++++++++++++--
 5 files changed, 63 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index 150407a..91bc4ba 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -11,6 +11,7 @@ static const int pat_enabled;
 #endif
 
 extern void pat_init(void);
+void pat_init_cache_modes(void);
 
 extern int reserve_memtype(u64 start, u64 end,
 		enum page_cache_mode req_pcm, enum page_cache_mode *ret_pcm);
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 6d5f6d1..af447f9 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -351,6 +351,10 @@ extern uint8_t __pte2cachemode_tbl[8];
 	((((cb) >> (_PAGE_BIT_PAT - 2)) & 4) |		\
 	 (((cb) >> (_PAGE_BIT_PCD - 1)) & 2) |		\
 	 (((cb) >> _PAGE_BIT_PWT) & 1))
+#define __cm_idx2pte(i)					\
+	((((i) & 4) << (_PAGE_BIT_PAT - 2)) |		\
+	 (((i) & 2) << (_PAGE_BIT_PCD - 1)) |		\
+	 (((i) & 1) << _PAGE_BIT_PWT))
 
 static inline unsigned long cachemode2protval(enum page_cache_mode pcm)
 {
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index a9776ba..82b41d5 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -716,3 +716,11 @@ void __init zone_sizes_init(void)
 	free_area_init_nodes(max_zone_pfns);
 }
 
+void update_cache_mode_entry(unsigned entry, enum page_cache_mode cache)
+{
+	/* entry 0 MUST be WB (hardwired to speed up translations) */
+	BUG_ON(!entry && cache != _PAGE_CACHE_MODE_WB);
+
+	__cachemode2pte_tbl[cache] = __cm_idx2pte(entry);
+	__pte2cachemode_tbl[entry] = cache;
+}
diff --git a/arch/x86/mm/mm_internal.h b/arch/x86/mm/mm_internal.h
index 6b563a1..62474ba 100644
--- a/arch/x86/mm/mm_internal.h
+++ b/arch/x86/mm/mm_internal.h
@@ -16,4 +16,6 @@ void zone_sizes_init(void);
 
 extern int after_bootmem;
 
+void update_cache_mode_entry(unsigned entry, enum page_cache_mode cache);
+
 #endif	/* __X86_MM_INTERNAL_H */
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index ef75f3f..4c60127 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -31,6 +31,7 @@
 #include <asm/io.h>
 
 #include "pat_internal.h"
+#include "mm_internal.h"
 
 #ifdef CONFIG_X86_PAT
 int __read_mostly pat_enabled = 1;
@@ -75,6 +76,52 @@ enum {
 	PAT_UC_MINUS = 7,	/* UC, but can be overriden by MTRR */
 };
 
+#define CM(c) (_PAGE_CACHE_MODE_ ## c)
+
+static enum page_cache_mode pat_get_cache_mode(unsigned pat_val, char *msg)
+{
+	enum page_cache_mode cache;
+	char *cache_mode;
+
+	switch (pat_val) {
+	case PAT_UC:       cache = CM(UC);       cache_mode = "UC  "; break;
+	case PAT_WC:       cache = CM(WC);       cache_mode = "WC  "; break;
+	case PAT_WT:       cache = CM(WT);       cache_mode = "WT  "; break;
+	case PAT_WP:       cache = CM(WP);       cache_mode = "WP  "; break;
+	case PAT_WB:       cache = CM(WB);       cache_mode = "WB  "; break;
+	case PAT_UC_MINUS: cache = CM(UC_MINUS); cache_mode = "UC- "; break;
+	default:           cache = CM(WB);       cache_mode = "WB  "; break;
+	}
+
+	memcpy(msg, cache_mode, 4);
+
+	return cache;
+}
+
+#undef CM
+
+/*
+ * Update the cache mode to pgprot translation tables according to PAT
+ * configuration.
+ * Using lower indices is preferred, so we start with highest index.
+ */
+void pat_init_cache_modes(void)
+{
+	int i;
+	enum page_cache_mode cache;
+	char pat_msg[33];
+	u64 pat;
+
+	rdmsrl(MSR_IA32_CR_PAT, pat);
+	pat_msg[32] = 0;
+	for (i = 7; i >= 0; i--) {
+		cache = pat_get_cache_mode((pat >> (i * 8)) & 7,
+					   pat_msg + 4 * i);
+		update_cache_mode_entry(i, cache);
+	}
+	pr_info("PAT configuration [0-7]: %s\n", pat_msg);
+}
+
 #define PAT(x, y)	((u64)PAT_ ## y << ((x)*8))
 
 void pat_init(void)
@@ -124,8 +171,7 @@ void pat_init(void)
 	wrmsrl(MSR_IA32_CR_PAT, pat);
 
 	if (boot_cpu)
-		printk(KERN_INFO "x86 PAT enabled: cpu %d, old 0x%Lx, new 0x%Lx\n",
-		       smp_processor_id(), boot_pat_state, pat);
+		pat_init_cache_modes();
 }
 
 #undef PAT
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHH3-0002W5-6a; Mon, 03 Nov 2014 13:02:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH1-0002T1-Ax
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:19 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F8/54-09842-8DC77545; Mon, 03 Nov 2014 13:02:16 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415019736!5097796!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.2 required=7.0 tests=UPPERCASE_50_75
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21838 invoked from network); 3 Nov 2014 13:02:16 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:16 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 04EE4AD5D;
	Mon,  3 Nov 2014 13:02:16 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:02:00 +0100
Message-Id: <1415019724-4317-15-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 14/18] x86: Clean up pgtable_types.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 no longer used defines from pgtable_types.h as they are not
used any longer.

Switch __PAGE_KERNEL_NOCACHE to use cache mode type instead of pte
bits.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h | 21 +--------------------
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 5124642..6d5f6d1 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -128,11 +128,6 @@
 			 _PAGE_SOFT_DIRTY | _PAGE_NUMA)
 #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE | _PAGE_NUMA)
 
-#define _PAGE_CACHE_WB		(0)
-#define _PAGE_CACHE_WC		(_PAGE_PWT)
-#define _PAGE_CACHE_UC_MINUS	(_PAGE_PCD)
-#define _PAGE_CACHE_UC		(_PAGE_PCD | _PAGE_PWT)
-
 /*
  * The cache modes defined here are used to translate between pure SW usage
  * and the HW defined cache mode bits and/or PAT entries.
@@ -178,41 +173,27 @@ enum page_cache_mode {
 
 #define __PAGE_KERNEL_RO		(__PAGE_KERNEL & ~_PAGE_RW)
 #define __PAGE_KERNEL_RX		(__PAGE_KERNEL_EXEC & ~_PAGE_RW)
-#define __PAGE_KERNEL_EXEC_NOCACHE	(__PAGE_KERNEL_EXEC | _PAGE_PCD | _PAGE_PWT)
-#define __PAGE_KERNEL_WC		(__PAGE_KERNEL | _PAGE_CACHE_WC)
-#define __PAGE_KERNEL_NOCACHE		(__PAGE_KERNEL | _PAGE_PCD | _PAGE_PWT)
-#define __PAGE_KERNEL_UC_MINUS		(__PAGE_KERNEL | _PAGE_PCD)
+#define __PAGE_KERNEL_NOCACHE		(__PAGE_KERNEL | _PAGE_NOCACHE)
 #define __PAGE_KERNEL_VSYSCALL		(__PAGE_KERNEL_RX | _PAGE_USER)
 #define __PAGE_KERNEL_VVAR		(__PAGE_KERNEL_RO | _PAGE_USER)
-#define __PAGE_KERNEL_VVAR_NOCACHE	(__PAGE_KERNEL_VVAR | _PAGE_PCD | _PAGE_PWT)
 #define __PAGE_KERNEL_LARGE		(__PAGE_KERNEL | _PAGE_PSE)
-#define __PAGE_KERNEL_LARGE_NOCACHE	(__PAGE_KERNEL | _PAGE_CACHE_UC | _PAGE_PSE)
 #define __PAGE_KERNEL_LARGE_EXEC	(__PAGE_KERNEL_EXEC | _PAGE_PSE)
 
 #define __PAGE_KERNEL_IO		(__PAGE_KERNEL)
 #define __PAGE_KERNEL_IO_NOCACHE	(__PAGE_KERNEL_NOCACHE)
-#define __PAGE_KERNEL_IO_UC_MINUS	(__PAGE_KERNEL_UC_MINUS)
-#define __PAGE_KERNEL_IO_WC		(__PAGE_KERNEL_WC)
 
 #define PAGE_KERNEL			__pgprot(__PAGE_KERNEL)
 #define PAGE_KERNEL_RO			__pgprot(__PAGE_KERNEL_RO)
 #define PAGE_KERNEL_EXEC		__pgprot(__PAGE_KERNEL_EXEC)
 #define PAGE_KERNEL_RX			__pgprot(__PAGE_KERNEL_RX)
-#define PAGE_KERNEL_WC			__pgprot(__PAGE_KERNEL_WC)
 #define PAGE_KERNEL_NOCACHE		__pgprot(__PAGE_KERNEL_NOCACHE)
-#define PAGE_KERNEL_UC_MINUS		__pgprot(__PAGE_KERNEL_UC_MINUS)
-#define PAGE_KERNEL_EXEC_NOCACHE	__pgprot(__PAGE_KERNEL_EXEC_NOCACHE)
 #define PAGE_KERNEL_LARGE		__pgprot(__PAGE_KERNEL_LARGE)
-#define PAGE_KERNEL_LARGE_NOCACHE	__pgprot(__PAGE_KERNEL_LARGE_NOCACHE)
 #define PAGE_KERNEL_LARGE_EXEC		__pgprot(__PAGE_KERNEL_LARGE_EXEC)
 #define PAGE_KERNEL_VSYSCALL		__pgprot(__PAGE_KERNEL_VSYSCALL)
 #define PAGE_KERNEL_VVAR		__pgprot(__PAGE_KERNEL_VVAR)
-#define PAGE_KERNEL_VVAR_NOCACHE	__pgprot(__PAGE_KERNEL_VVAR_NOCACHE)
 
 #define PAGE_KERNEL_IO			__pgprot(__PAGE_KERNEL_IO)
 #define PAGE_KERNEL_IO_NOCACHE		__pgprot(__PAGE_KERNEL_IO_NOCACHE)
-#define PAGE_KERNEL_IO_UC_MINUS		__pgprot(__PAGE_KERNEL_IO_UC_MINUS)
-#define PAGE_KERNEL_IO_WC		__pgprot(__PAGE_KERNEL_IO_WC)
 
 /*         xwr */
 #define __P000	PAGE_NONE
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHH3-0002W5-6a; Mon, 03 Nov 2014 13:02:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH1-0002T1-Ax
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:19 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F8/54-09842-8DC77545; Mon, 03 Nov 2014 13:02:16 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415019736!5097796!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.2 required=7.0 tests=UPPERCASE_50_75
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21838 invoked from network); 3 Nov 2014 13:02:16 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:16 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 04EE4AD5D;
	Mon,  3 Nov 2014 13:02:16 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:02:00 +0100
Message-Id: <1415019724-4317-15-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 14/18] x86: Clean up pgtable_types.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 no longer used defines from pgtable_types.h as they are not
used any longer.

Switch __PAGE_KERNEL_NOCACHE to use cache mode type instead of pte
bits.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h | 21 +--------------------
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 5124642..6d5f6d1 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -128,11 +128,6 @@
 			 _PAGE_SOFT_DIRTY | _PAGE_NUMA)
 #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE | _PAGE_NUMA)
 
-#define _PAGE_CACHE_WB		(0)
-#define _PAGE_CACHE_WC		(_PAGE_PWT)
-#define _PAGE_CACHE_UC_MINUS	(_PAGE_PCD)
-#define _PAGE_CACHE_UC		(_PAGE_PCD | _PAGE_PWT)
-
 /*
  * The cache modes defined here are used to translate between pure SW usage
  * and the HW defined cache mode bits and/or PAT entries.
@@ -178,41 +173,27 @@ enum page_cache_mode {
 
 #define __PAGE_KERNEL_RO		(__PAGE_KERNEL & ~_PAGE_RW)
 #define __PAGE_KERNEL_RX		(__PAGE_KERNEL_EXEC & ~_PAGE_RW)
-#define __PAGE_KERNEL_EXEC_NOCACHE	(__PAGE_KERNEL_EXEC | _PAGE_PCD | _PAGE_PWT)
-#define __PAGE_KERNEL_WC		(__PAGE_KERNEL | _PAGE_CACHE_WC)
-#define __PAGE_KERNEL_NOCACHE		(__PAGE_KERNEL | _PAGE_PCD | _PAGE_PWT)
-#define __PAGE_KERNEL_UC_MINUS		(__PAGE_KERNEL | _PAGE_PCD)
+#define __PAGE_KERNEL_NOCACHE		(__PAGE_KERNEL | _PAGE_NOCACHE)
 #define __PAGE_KERNEL_VSYSCALL		(__PAGE_KERNEL_RX | _PAGE_USER)
 #define __PAGE_KERNEL_VVAR		(__PAGE_KERNEL_RO | _PAGE_USER)
-#define __PAGE_KERNEL_VVAR_NOCACHE	(__PAGE_KERNEL_VVAR | _PAGE_PCD | _PAGE_PWT)
 #define __PAGE_KERNEL_LARGE		(__PAGE_KERNEL | _PAGE_PSE)
-#define __PAGE_KERNEL_LARGE_NOCACHE	(__PAGE_KERNEL | _PAGE_CACHE_UC | _PAGE_PSE)
 #define __PAGE_KERNEL_LARGE_EXEC	(__PAGE_KERNEL_EXEC | _PAGE_PSE)
 
 #define __PAGE_KERNEL_IO		(__PAGE_KERNEL)
 #define __PAGE_KERNEL_IO_NOCACHE	(__PAGE_KERNEL_NOCACHE)
-#define __PAGE_KERNEL_IO_UC_MINUS	(__PAGE_KERNEL_UC_MINUS)
-#define __PAGE_KERNEL_IO_WC		(__PAGE_KERNEL_WC)
 
 #define PAGE_KERNEL			__pgprot(__PAGE_KERNEL)
 #define PAGE_KERNEL_RO			__pgprot(__PAGE_KERNEL_RO)
 #define PAGE_KERNEL_EXEC		__pgprot(__PAGE_KERNEL_EXEC)
 #define PAGE_KERNEL_RX			__pgprot(__PAGE_KERNEL_RX)
-#define PAGE_KERNEL_WC			__pgprot(__PAGE_KERNEL_WC)
 #define PAGE_KERNEL_NOCACHE		__pgprot(__PAGE_KERNEL_NOCACHE)
-#define PAGE_KERNEL_UC_MINUS		__pgprot(__PAGE_KERNEL_UC_MINUS)
-#define PAGE_KERNEL_EXEC_NOCACHE	__pgprot(__PAGE_KERNEL_EXEC_NOCACHE)
 #define PAGE_KERNEL_LARGE		__pgprot(__PAGE_KERNEL_LARGE)
-#define PAGE_KERNEL_LARGE_NOCACHE	__pgprot(__PAGE_KERNEL_LARGE_NOCACHE)
 #define PAGE_KERNEL_LARGE_EXEC		__pgprot(__PAGE_KERNEL_LARGE_EXEC)
 #define PAGE_KERNEL_VSYSCALL		__pgprot(__PAGE_KERNEL_VSYSCALL)
 #define PAGE_KERNEL_VVAR		__pgprot(__PAGE_KERNEL_VVAR)
-#define PAGE_KERNEL_VVAR_NOCACHE	__pgprot(__PAGE_KERNEL_VVAR_NOCACHE)
 
 #define PAGE_KERNEL_IO			__pgprot(__PAGE_KERNEL_IO)
 #define PAGE_KERNEL_IO_NOCACHE		__pgprot(__PAGE_KERNEL_IO_NOCACHE)
-#define PAGE_KERNEL_IO_UC_MINUS		__pgprot(__PAGE_KERNEL_IO_UC_MINUS)
-#define PAGE_KERNEL_IO_WC		__pgprot(__PAGE_KERNEL_IO_WC)
 
 /*         xwr */
 #define __P000	PAGE_NONE
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHH0-0002SU-6e; Mon, 03 Nov 2014 13:02:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGx-0002Ql-TR
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	42/4B-24532-6DC77545; Mon, 03 Nov 2014 13:02:14 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415019733!12396081!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3112 invoked from network); 3 Nov 2014 13:02:14 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:14 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id AF896AD53;
	Mon,  3 Nov 2014 13:02:13 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:55 +0100
Message-Id: <1415019724-4317-10-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 09/18] x86: Use new cache mode type in
	track_pfn_remap() and track_pfn_insert()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type. As those are the main callers of
lookup_memtype(), change this as well.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/mm/pat.c | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 6d5a8e3..2f3744f 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -394,12 +394,12 @@ int free_memtype(u64 start, u64 end)
  *
  * Only to be called when PAT is enabled
  *
- * Returns _PAGE_CACHE_WB, _PAGE_CACHE_WC, _PAGE_CACHE_UC_MINUS or
- * _PAGE_CACHE_UC
+ * Returns _PAGE_CACHE_MODE_WB, _PAGE_CACHE_MODE_WC, _PAGE_CACHE_MODE_UC_MINUS
+ * or _PAGE_CACHE_MODE_UC
  */
-static unsigned long lookup_memtype(u64 paddr)
+static enum page_cache_mode lookup_memtype(u64 paddr)
 {
-	int rettype = _PAGE_CACHE_WB;
+	enum page_cache_mode rettype = _PAGE_CACHE_MODE_WB;
 	struct memtype *entry;
 
 	if (x86_platform.is_untracked_pat_range(paddr, paddr + PAGE_SIZE))
@@ -408,13 +408,13 @@ static unsigned long lookup_memtype(u64 paddr)
 	if (pat_pagerange_is_ram(paddr, paddr + PAGE_SIZE)) {
 		struct page *page;
 		page = pfn_to_page(paddr >> PAGE_SHIFT);
-		rettype = get_page_memtype(page);
+		rettype = pgprot2cachemode(__pgprot(get_page_memtype(page)));
 		/*
 		 * -1 from get_page_memtype() implies RAM page is in its
 		 * default state and not reserved, and hence of type WB
 		 */
 		if (rettype == -1)
-			rettype = _PAGE_CACHE_WB;
+			rettype = _PAGE_CACHE_MODE_WB;
 
 		return rettype;
 	}
@@ -423,9 +423,9 @@ static unsigned long lookup_memtype(u64 paddr)
 
 	entry = rbt_memtype_lookup(paddr);
 	if (entry != NULL)
-		rettype = entry->type;
+		rettype = pgprot2cachemode(__pgprot(entry->type));
 	else
-		rettype = _PAGE_CACHE_UC_MINUS;
+		rettype = _PAGE_CACHE_MODE_UC_MINUS;
 
 	spin_unlock(&memtype_lock);
 	return rettype;
@@ -613,7 +613,7 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 		if (!pat_enabled)
 			return 0;
 
-		flags = lookup_memtype(paddr);
+		flags = cachemode2protval(lookup_memtype(paddr));
 		if (want_flags != flags) {
 			printk(KERN_WARNING "%s:%d map pfn RAM range req %s for [mem %#010Lx-%#010Lx], got %s\n",
 				current->comm, current->pid,
@@ -715,7 +715,7 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t *prot,
 		    unsigned long pfn, unsigned long addr, unsigned long size)
 {
 	resource_size_t paddr = (resource_size_t)pfn << PAGE_SHIFT;
-	unsigned long flags;
+	enum page_cache_mode pcm;
 
 	/* reserve the whole chunk starting from paddr */
 	if (addr == vma->vm_start && size == (vma->vm_end - vma->vm_start)) {
@@ -734,18 +734,18 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t *prot,
 	 * For anything smaller than the vma size we set prot based on the
 	 * lookup.
 	 */
-	flags = lookup_memtype(paddr);
+	pcm = lookup_memtype(paddr);
 
 	/* Check memtype for the remaining pages */
 	while (size > PAGE_SIZE) {
 		size -= PAGE_SIZE;
 		paddr += PAGE_SIZE;
-		if (flags != lookup_memtype(paddr))
+		if (pcm != lookup_memtype(paddr))
 			return -EINVAL;
 	}
 
 	*prot = __pgprot((pgprot_val(vma->vm_page_prot) & (~_PAGE_CACHE_MASK)) |
-			 flags);
+			 cachemode2protval(pcm));
 
 	return 0;
 }
@@ -753,15 +753,15 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t *prot,
 int track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot,
 		     unsigned long pfn)
 {
-	unsigned long flags;
+	enum page_cache_mode pcm;
 
 	if (!pat_enabled)
 		return 0;
 
 	/* Set prot based on lookup */
-	flags = lookup_memtype((resource_size_t)pfn << PAGE_SHIFT);
+	pcm = lookup_memtype((resource_size_t)pfn << PAGE_SHIFT);
 	*prot = __pgprot((pgprot_val(vma->vm_page_prot) & (~_PAGE_CACHE_MASK)) |
-			 flags);
+			 cachemode2protval(pcm));
 
 	return 0;
 }
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHH0-0002SU-6e; Mon, 03 Nov 2014 13:02:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGx-0002Ql-TR
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	42/4B-24532-6DC77545; Mon, 03 Nov 2014 13:02:14 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415019733!12396081!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3112 invoked from network); 3 Nov 2014 13:02:14 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:14 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id AF896AD53;
	Mon,  3 Nov 2014 13:02:13 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:55 +0100
Message-Id: <1415019724-4317-10-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 09/18] x86: Use new cache mode type in
	track_pfn_remap() and track_pfn_insert()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type. As those are the main callers of
lookup_memtype(), change this as well.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/mm/pat.c | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 6d5a8e3..2f3744f 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -394,12 +394,12 @@ int free_memtype(u64 start, u64 end)
  *
  * Only to be called when PAT is enabled
  *
- * Returns _PAGE_CACHE_WB, _PAGE_CACHE_WC, _PAGE_CACHE_UC_MINUS or
- * _PAGE_CACHE_UC
+ * Returns _PAGE_CACHE_MODE_WB, _PAGE_CACHE_MODE_WC, _PAGE_CACHE_MODE_UC_MINUS
+ * or _PAGE_CACHE_MODE_UC
  */
-static unsigned long lookup_memtype(u64 paddr)
+static enum page_cache_mode lookup_memtype(u64 paddr)
 {
-	int rettype = _PAGE_CACHE_WB;
+	enum page_cache_mode rettype = _PAGE_CACHE_MODE_WB;
 	struct memtype *entry;
 
 	if (x86_platform.is_untracked_pat_range(paddr, paddr + PAGE_SIZE))
@@ -408,13 +408,13 @@ static unsigned long lookup_memtype(u64 paddr)
 	if (pat_pagerange_is_ram(paddr, paddr + PAGE_SIZE)) {
 		struct page *page;
 		page = pfn_to_page(paddr >> PAGE_SHIFT);
-		rettype = get_page_memtype(page);
+		rettype = pgprot2cachemode(__pgprot(get_page_memtype(page)));
 		/*
 		 * -1 from get_page_memtype() implies RAM page is in its
 		 * default state and not reserved, and hence of type WB
 		 */
 		if (rettype == -1)
-			rettype = _PAGE_CACHE_WB;
+			rettype = _PAGE_CACHE_MODE_WB;
 
 		return rettype;
 	}
@@ -423,9 +423,9 @@ static unsigned long lookup_memtype(u64 paddr)
 
 	entry = rbt_memtype_lookup(paddr);
 	if (entry != NULL)
-		rettype = entry->type;
+		rettype = pgprot2cachemode(__pgprot(entry->type));
 	else
-		rettype = _PAGE_CACHE_UC_MINUS;
+		rettype = _PAGE_CACHE_MODE_UC_MINUS;
 
 	spin_unlock(&memtype_lock);
 	return rettype;
@@ -613,7 +613,7 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 		if (!pat_enabled)
 			return 0;
 
-		flags = lookup_memtype(paddr);
+		flags = cachemode2protval(lookup_memtype(paddr));
 		if (want_flags != flags) {
 			printk(KERN_WARNING "%s:%d map pfn RAM range req %s for [mem %#010Lx-%#010Lx], got %s\n",
 				current->comm, current->pid,
@@ -715,7 +715,7 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t *prot,
 		    unsigned long pfn, unsigned long addr, unsigned long size)
 {
 	resource_size_t paddr = (resource_size_t)pfn << PAGE_SHIFT;
-	unsigned long flags;
+	enum page_cache_mode pcm;
 
 	/* reserve the whole chunk starting from paddr */
 	if (addr == vma->vm_start && size == (vma->vm_end - vma->vm_start)) {
@@ -734,18 +734,18 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t *prot,
 	 * For anything smaller than the vma size we set prot based on the
 	 * lookup.
 	 */
-	flags = lookup_memtype(paddr);
+	pcm = lookup_memtype(paddr);
 
 	/* Check memtype for the remaining pages */
 	while (size > PAGE_SIZE) {
 		size -= PAGE_SIZE;
 		paddr += PAGE_SIZE;
-		if (flags != lookup_memtype(paddr))
+		if (pcm != lookup_memtype(paddr))
 			return -EINVAL;
 	}
 
 	*prot = __pgprot((pgprot_val(vma->vm_page_prot) & (~_PAGE_CACHE_MASK)) |
-			 flags);
+			 cachemode2protval(pcm));
 
 	return 0;
 }
@@ -753,15 +753,15 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t *prot,
 int track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot,
 		     unsigned long pfn)
 {
-	unsigned long flags;
+	enum page_cache_mode pcm;
 
 	if (!pat_enabled)
 		return 0;
 
 	/* Set prot based on lookup */
-	flags = lookup_memtype((resource_size_t)pfn << PAGE_SHIFT);
+	pcm = lookup_memtype((resource_size_t)pfn << PAGE_SHIFT);
 	*prot = __pgprot((pgprot_val(vma->vm_page_prot) & (~_PAGE_CACHE_MASK)) |
-			 flags);
+			 cachemode2protval(pcm));
 
 	return 0;
 }
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHH0-0002St-Kl; Mon, 03 Nov 2014 13:02:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGy-0002RD-Rk
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E4/4B-24532-7DC77545; Mon, 03 Nov 2014 13:02:15 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415019734!12372953!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18853 invoked from network); 3 Nov 2014 13:02:14 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:14 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 20332AD54;
	Mon,  3 Nov 2014 13:02:14 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:56 +0100
Message-Id: <1415019724-4317-11-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 10/18] x86: Remove looking for setting of
	_PAGE_PAT_LARGE in pageattr.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>
MIME-Version: 1.0
Content-Type: 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 modifying page attributes via change_page_attr_set_clr() don't
test for setting _PAGE_PAT_LARGE, as this is
- never done
- PAT support for large pages is not included in the kernel up to now

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/mm/pageattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index ae242a7..87c0d36 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1307,7 +1307,7 @@ static int __change_page_attr_set_clr(struct cpa_data *cpa, int checkalias)
 static inline int cache_attr(pgprot_t attr)
 {
 	return pgprot_val(attr) &
-		(_PAGE_PAT | _PAGE_PAT_LARGE | _PAGE_PWT | _PAGE_PCD);
+		(_PAGE_PAT | _PAGE_PWT | _PAGE_PCD);
 }
 
 static int change_page_attr_set_clr(unsigned long *addr, int numpages,
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHH0-0002St-Kl; Mon, 03 Nov 2014 13:02:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGy-0002RD-Rk
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E4/4B-24532-7DC77545; Mon, 03 Nov 2014 13:02:15 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415019734!12372953!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18853 invoked from network); 3 Nov 2014 13:02:14 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:14 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 20332AD54;
	Mon,  3 Nov 2014 13:02:14 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:56 +0100
Message-Id: <1415019724-4317-11-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 10/18] x86: Remove looking for setting of
	_PAGE_PAT_LARGE in pageattr.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>
MIME-Version: 1.0
Content-Type: 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 modifying page attributes via change_page_attr_set_clr() don't
test for setting _PAGE_PAT_LARGE, as this is
- never done
- PAT support for large pages is not included in the kernel up to now

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/mm/pageattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index ae242a7..87c0d36 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1307,7 +1307,7 @@ static int __change_page_attr_set_clr(struct cpa_data *cpa, int checkalias)
 static inline int cache_attr(pgprot_t attr)
 {
 	return pgprot_val(attr) &
-		(_PAGE_PAT | _PAGE_PAT_LARGE | _PAGE_PWT | _PAGE_PCD);
+		(_PAGE_PAT | _PAGE_PWT | _PAGE_PCD);
 }
 
 static int change_page_attr_set_clr(unsigned long *addr, int numpages,
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHGz-0002Rb-A5; Mon, 03 Nov 2014 13:02:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGx-0002QL-5x
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:15 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	BC/AB-11608-6DC77545; Mon, 03 Nov 2014 13:02:14 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415019733!11223816!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15944 invoked from network); 3 Nov 2014 13:02:13 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:13 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id D9E1BAD04;
	Mon,  3 Nov 2014 13:02:12 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:53 +0100
Message-Id: <1415019724-4317-8-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 07/18] x86: Use new cache mode type in
	asm/pgtable.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type. This requires changing some callers of
is_new_memtype_allowed() to be changed as well.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable.h | 19 ++++++++++---------
 arch/x86/mm/ioremap.c          |  3 ++-
 arch/x86/mm/pat.c              |  8 ++++++--
 3 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index aa97a07..c112ea6 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -9,9 +9,10 @@
 /*
  * Macro to mark a page protection value as UC-
  */
-#define pgprot_noncached(prot)					\
-	((boot_cpu_data.x86 > 3)				\
-	 ? (__pgprot(pgprot_val(prot) | _PAGE_CACHE_UC_MINUS))	\
+#define pgprot_noncached(prot)						\
+	((boot_cpu_data.x86 > 3)					\
+	 ? (__pgprot(pgprot_val(prot) |					\
+		     cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS)))	\
 	 : (prot))
 
 #ifndef __ASSEMBLY__
@@ -404,8 +405,8 @@ static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
 #define canon_pgprot(p) __pgprot(massage_pgprot(p))
 
 static inline int is_new_memtype_allowed(u64 paddr, unsigned long size,
-					 unsigned long flags,
-					 unsigned long new_flags)
+					 enum page_cache_mode pcm,
+					 enum page_cache_mode new_pcm)
 {
 	/*
 	 * PAT type is always WB for untracked ranges, so no need to check.
@@ -419,10 +420,10 @@ static inline int is_new_memtype_allowed(u64 paddr, unsigned long size,
 	 * - request is uncached, return cannot be write-back
 	 * - request is write-combine, return cannot be write-back
 	 */
-	if ((flags == _PAGE_CACHE_UC_MINUS &&
-	     new_flags == _PAGE_CACHE_WB) ||
-	    (flags == _PAGE_CACHE_WC &&
-	     new_flags == _PAGE_CACHE_WB)) {
+	if ((pcm == _PAGE_CACHE_MODE_UC_MINUS &&
+	     new_pcm == _PAGE_CACHE_MODE_WB) ||
+	    (pcm == _PAGE_CACHE_MODE_WC &&
+	     new_pcm == _PAGE_CACHE_MODE_WB)) {
 		return 0;
 	}
 
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index af78e50..3a81eb9 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -142,7 +142,8 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 
 	if (prot_val != new_prot_val) {
 		if (!is_new_memtype_allowed(phys_addr, size,
-					    prot_val, new_prot_val)) {
+				pgprot2cachemode(__pgprot(prot_val)),
+				pgprot2cachemode(__pgprot(new_prot_val)))) {
 			printk(KERN_ERR
 		"ioremap error for 0x%llx-0x%llx, requested 0x%lx, got 0x%lx\n",
 				(unsigned long long)phys_addr,
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 6574388..47282c2 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -455,7 +455,9 @@ int io_reserve_memtype(resource_size_t start, resource_size_t end,
 	if (ret)
 		goto out_err;
 
-	if (!is_new_memtype_allowed(start, size, req_type, new_type))
+	if (!is_new_memtype_allowed(start, size,
+				    pgprot2cachemode(__pgprot(req_type)),
+				    pgprot2cachemode(__pgprot(new_type))))
 		goto out_free;
 
 	if (kernel_map_sync_memtype(start, size, new_type) < 0)
@@ -630,7 +632,9 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 
 	if (flags != want_flags) {
 		if (strict_prot ||
-		    !is_new_memtype_allowed(paddr, size, want_flags, flags)) {
+		    !is_new_memtype_allowed(paddr, size,
+				pgprot2cachemode(__pgprot(want_flags)),
+				pgprot2cachemode(__pgprot(flags)))) {
 			free_memtype(paddr, paddr + size);
 			printk(KERN_ERR "%s:%d map pfn expected mapping type %s"
 				" for [mem %#010Lx-%#010Lx], got %s\n",
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHGz-0002Rb-A5; Mon, 03 Nov 2014 13:02:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGx-0002QL-5x
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:15 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	BC/AB-11608-6DC77545; Mon, 03 Nov 2014 13:02:14 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415019733!11223816!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15944 invoked from network); 3 Nov 2014 13:02:13 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:13 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id D9E1BAD04;
	Mon,  3 Nov 2014 13:02:12 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:53 +0100
Message-Id: <1415019724-4317-8-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 07/18] x86: Use new cache mode type in
	asm/pgtable.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type. This requires changing some callers of
is_new_memtype_allowed() to be changed as well.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable.h | 19 ++++++++++---------
 arch/x86/mm/ioremap.c          |  3 ++-
 arch/x86/mm/pat.c              |  8 ++++++--
 3 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index aa97a07..c112ea6 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -9,9 +9,10 @@
 /*
  * Macro to mark a page protection value as UC-
  */
-#define pgprot_noncached(prot)					\
-	((boot_cpu_data.x86 > 3)				\
-	 ? (__pgprot(pgprot_val(prot) | _PAGE_CACHE_UC_MINUS))	\
+#define pgprot_noncached(prot)						\
+	((boot_cpu_data.x86 > 3)					\
+	 ? (__pgprot(pgprot_val(prot) |					\
+		     cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS)))	\
 	 : (prot))
 
 #ifndef __ASSEMBLY__
@@ -404,8 +405,8 @@ static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
 #define canon_pgprot(p) __pgprot(massage_pgprot(p))
 
 static inline int is_new_memtype_allowed(u64 paddr, unsigned long size,
-					 unsigned long flags,
-					 unsigned long new_flags)
+					 enum page_cache_mode pcm,
+					 enum page_cache_mode new_pcm)
 {
 	/*
 	 * PAT type is always WB for untracked ranges, so no need to check.
@@ -419,10 +420,10 @@ static inline int is_new_memtype_allowed(u64 paddr, unsigned long size,
 	 * - request is uncached, return cannot be write-back
 	 * - request is write-combine, return cannot be write-back
 	 */
-	if ((flags == _PAGE_CACHE_UC_MINUS &&
-	     new_flags == _PAGE_CACHE_WB) ||
-	    (flags == _PAGE_CACHE_WC &&
-	     new_flags == _PAGE_CACHE_WB)) {
+	if ((pcm == _PAGE_CACHE_MODE_UC_MINUS &&
+	     new_pcm == _PAGE_CACHE_MODE_WB) ||
+	    (pcm == _PAGE_CACHE_MODE_WC &&
+	     new_pcm == _PAGE_CACHE_MODE_WB)) {
 		return 0;
 	}
 
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index af78e50..3a81eb9 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -142,7 +142,8 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 
 	if (prot_val != new_prot_val) {
 		if (!is_new_memtype_allowed(phys_addr, size,
-					    prot_val, new_prot_val)) {
+				pgprot2cachemode(__pgprot(prot_val)),
+				pgprot2cachemode(__pgprot(new_prot_val)))) {
 			printk(KERN_ERR
 		"ioremap error for 0x%llx-0x%llx, requested 0x%lx, got 0x%lx\n",
 				(unsigned long long)phys_addr,
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 6574388..47282c2 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -455,7 +455,9 @@ int io_reserve_memtype(resource_size_t start, resource_size_t end,
 	if (ret)
 		goto out_err;
 
-	if (!is_new_memtype_allowed(start, size, req_type, new_type))
+	if (!is_new_memtype_allowed(start, size,
+				    pgprot2cachemode(__pgprot(req_type)),
+				    pgprot2cachemode(__pgprot(new_type))))
 		goto out_free;
 
 	if (kernel_map_sync_memtype(start, size, new_type) < 0)
@@ -630,7 +632,9 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,
 
 	if (flags != want_flags) {
 		if (strict_prot ||
-		    !is_new_memtype_allowed(paddr, size, want_flags, flags)) {
+		    !is_new_memtype_allowed(paddr, size,
+				pgprot2cachemode(__pgprot(want_flags)),
+				pgprot2cachemode(__pgprot(flags)))) {
 			free_memtype(paddr, paddr + size);
 			printk(KERN_ERR "%s:%d map pfn expected mapping type %s"
 				" for [mem %#010Lx-%#010Lx], got %s\n",
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHGy-0002R9-6q; Mon, 03 Nov 2014 13:02:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGv-0002Pt-R2
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A6/60-09936-5DC77545; Mon, 03 Nov 2014 13:02:13 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415019731!12369985!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13645 invoked from network); 3 Nov 2014 13:02:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:12 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 89D9EACF4;
	Mon,  3 Nov 2014 13:02:11 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:50 +0100
Message-Id: <1415019724-4317-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 04/18] x86: Use new cache mode type in
	drivers/video/fbdev/vermilion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/video/fbdev/vermilion/vermilion.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/vermilion/vermilion.c b/drivers/video/fbdev/vermilion/vermilion.c
index 5f930ae..6b70d7f 100644
--- a/drivers/video/fbdev/vermilion/vermilion.c
+++ b/drivers/video/fbdev/vermilion/vermilion.c
@@ -1003,13 +1003,15 @@ static int vmlfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
 	struct vml_info *vinfo = container_of(info, struct vml_info, info);
 	unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
 	int ret;
+	unsigned long prot;
 
 	ret = vmlfb_vram_offset(vinfo, offset);
 	if (ret)
 		return -EINVAL;
 
-	pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
-	pgprot_val(vma->vm_page_prot) &= ~_PAGE_PWT;
+	prot = pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK;
+	pgprot_val(vma->vm_page_prot) =
+		prot | cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS);
 
 	return vm_iomap_memory(vma, vinfo->vram_start,
 			vinfo->vram_contig_size);
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHGy-0002R9-6q; Mon, 03 Nov 2014 13:02:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGv-0002Pt-R2
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A6/60-09936-5DC77545; Mon, 03 Nov 2014 13:02:13 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415019731!12369985!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13645 invoked from network); 3 Nov 2014 13:02:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:12 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 89D9EACF4;
	Mon,  3 Nov 2014 13:02:11 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:50 +0100
Message-Id: <1415019724-4317-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 04/18] x86: Use new cache mode type in
	drivers/video/fbdev/vermilion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/video/fbdev/vermilion/vermilion.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/vermilion/vermilion.c b/drivers/video/fbdev/vermilion/vermilion.c
index 5f930ae..6b70d7f 100644
--- a/drivers/video/fbdev/vermilion/vermilion.c
+++ b/drivers/video/fbdev/vermilion/vermilion.c
@@ -1003,13 +1003,15 @@ static int vmlfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
 	struct vml_info *vinfo = container_of(info, struct vml_info, info);
 	unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
 	int ret;
+	unsigned long prot;
 
 	ret = vmlfb_vram_offset(vinfo, offset);
 	if (ret)
 		return -EINVAL;
 
-	pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
-	pgprot_val(vma->vm_page_prot) &= ~_PAGE_PWT;
+	prot = pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK;
+	pgprot_val(vma->vm_page_prot) =
+		prot | cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS);
 
 	return vm_iomap_memory(vma, vinfo->vram_start,
 			vinfo->vram_contig_size);
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHGy-0002RQ-Tq; Mon, 03 Nov 2014 13:02:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGx-0002QM-1y
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9C/3B-24532-6DC77545; Mon, 03 Nov 2014 13:02:14 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415019732!12378351!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30975 invoked from network); 3 Nov 2014 13:02:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id F3FC8ACF9;
	Mon,  3 Nov 2014 13:02:11 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:51 +0100
Message-Id: <1415019724-4317-6-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 05/18] x86: Use new cache mode type in
	arch/x86/pci
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/pci/i386.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 37c1435..9b18ef3 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -433,14 +433,14 @@ int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
 		return -EINVAL;
 
 	if (pat_enabled && write_combine)
-		prot |= _PAGE_CACHE_WC;
+		prot |= cachemode2protval(_PAGE_CACHE_MODE_WC);
 	else if (pat_enabled || boot_cpu_data.x86 > 3)
 		/*
 		 * ioremap() and ioremap_nocache() defaults to UC MINUS for now.
 		 * To avoid attribute conflicts, request UC MINUS here
 		 * as well.
 		 */
-		prot |= _PAGE_CACHE_UC_MINUS;
+		prot |= cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS);
 
 	vma->vm_page_prot = __pgprot(prot);
 
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHGy-0002RQ-Tq; Mon, 03 Nov 2014 13:02:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGx-0002QM-1y
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9C/3B-24532-6DC77545; Mon, 03 Nov 2014 13:02:14 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415019732!12378351!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30975 invoked from network); 3 Nov 2014 13:02:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id F3FC8ACF9;
	Mon,  3 Nov 2014 13:02:11 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:51 +0100
Message-Id: <1415019724-4317-6-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 05/18] x86: Use new cache mode type in
	arch/x86/pci
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/pci/i386.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 37c1435..9b18ef3 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -433,14 +433,14 @@ int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
 		return -EINVAL;
 
 	if (pat_enabled && write_combine)
-		prot |= _PAGE_CACHE_WC;
+		prot |= cachemode2protval(_PAGE_CACHE_MODE_WC);
 	else if (pat_enabled || boot_cpu_data.x86 > 3)
 		/*
 		 * ioremap() and ioremap_nocache() defaults to UC MINUS for now.
 		 * To avoid attribute conflicts, request UC MINUS here
 		 * as well.
 		 */
-		prot |= _PAGE_CACHE_UC_MINUS;
+		prot |= cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS);
 
 	vma->vm_page_prot = __pgprot(prot);
 
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHGz-0002S3-Qn; Mon, 03 Nov 2014 13:02:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGx-0002Qa-NE
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FC/60-09936-5DC77545; Mon, 03 Nov 2014 13:02:13 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415019731!4368574!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25458 invoked from network); 3 Nov 2014 13:02:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id D4BA1AC38;
	Mon,  3 Nov 2014 13:02:09 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:46 +0100
Message-Id: <1415019724-4317-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 x86 architecture offers via the PAT (Page Attribute Table) a way to
specify different caching modes in page table entries. The PAT MSR contains
8 entries each specifying one of 6 possible cache modes. A pte references one
of those entries via 3 bits: _PAGE_PAT, _PAGE_PWT and _PAGE_PCD.

The Linux kernel currently supports only 4 different cache modes. The PAT MSR
is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the
top 4 entries in the PAT MSR are the same as the 4 lower entries.

This results in the kernel not supporting e.g. write-through mode. Especially
this cache mode would speed up drivers of video cards which now have to use
uncached accesses.

OTOH some old processors (Pentium) don't support PAT correctly and the Xen
hypervisor has been using a different PAT MSR configuration for some time now
and can't change that as this setting is part of the ABI.

This patch set abstracts the cache mode from the pte and introduces tables to
translate between cache mode and pte bits (the default cache mode "write back"
is hard-wired to PAT entry 0). The tables are statically initialized with
values being compatible to old processors and current usage. As soon as the
PAT MSR is changed (or - in case of Xen - is read at boot time) the tables are
changed accordingly. Requests of mappings with special cache modes are always
possible now, in case they are not supported there will be a fallback to a
compatible but slower mode.

Summing it up, this patch set adds the following features:
- capability to support WT and WP cache modes on processors with full PAT
  support
- processors with no or uncorrect PAT support are still working as today, even
  if WT or WP cache mode are selected by drivers for some pages
- reduction of Xen special handling regarding cache mode

Changes in V6:
- add new patch 10 (x86: Remove looking for setting of _PAGE_PAT_LARGE in
  pageattr.c) as suggested by Thomas Gleixner
- replaced SOB of Stefan Bader by "Based-on-patch-by:" as suggested by
  Borislav Petkov

Changes in V5:
- split up first patch as requested by Ingo Molnar and Thomas Gleixner
- add a helper function in pat_init_cache_modes() as requested by Ingo Molnar

Changes in V4:
- rebased to 3.18-rc2

Changes in V3:
- corrected two minor nits (UC_MINUS, again) detected by Toshi Kani

Changes in V2:
- simplified handling of PAT MSR write under Xen as suggested by David Vrabel
- removed resetting of pat_enabled under Xen
- two small corrections requested by Toshi Kani (UC_MINUS cache mode in
  vermilion driver, fix 32 bit kernel build failure)
- correct build error on non-x86 arch by moving definition of
  update_cache_mode_entry() to x86 specific header

Changes since RFC:
- renamed functions and variables as suggested by Toshi Kani
- corrected cache mode bits for WT and WP
- modified handling of PAT MSR write under Xen as suggested by Jan Beulich


Juergen Gross (18):
  x86: Make page cache mode a real type
  x86: Use new cache mode type in include/asm/fb.h
  x86: Use new cache mode type in drivers/video/fbdev/gbefb.c
  x86: Use new cache mode type in drivers/video/fbdev/vermilion
  x86: Use new cache mode type in arch/x86/pci
  x86: Use new cache mode type in arch/x86/mm/init_64.c
  x86: Use new cache mode type in asm/pgtable.h
  x86: Use new cache mode type in mm/iomap_32.c
  x86: Use new cache mode type in track_pfn_remap() and
    track_pfn_insert()
  x86: Remove looking for setting of _PAGE_PAT_LARGE in pageattr.c
  x86: Use new cache mode type in setting page attributes
  x86: Use new cache mode type in mm/ioremap.c
  x86: Use new cache mode type in memtype related functions
  x86: Clean up pgtable_types.h
  x86: Support PAT bit in pagetable dump for lower levels
  x86: Respect PAT bit when copying pte values between large and normal
    pages
  x86: Enable PAT to use cache mode translation tables
  xen: Support Xen pv-domains using PAT

 arch/x86/include/asm/cacheflush.h         |  38 ++++---
 arch/x86/include/asm/fb.h                 |   6 +-
 arch/x86/include/asm/io.h                 |   2 +-
 arch/x86/include/asm/pat.h                |   7 +-
 arch/x86/include/asm/pgtable.h            |  19 ++--
 arch/x86/include/asm/pgtable_types.h      |  96 ++++++++++++----
 arch/x86/mm/dump_pagetables.c             |  24 ++--
 arch/x86/mm/init.c                        |  37 +++++++
 arch/x86/mm/init_64.c                     |   9 +-
 arch/x86/mm/iomap_32.c                    |  12 +-
 arch/x86/mm/ioremap.c                     |  63 ++++++-----
 arch/x86/mm/mm_internal.h                 |   2 +
 arch/x86/mm/pageattr.c                    |  84 ++++++++------
 arch/x86/mm/pat.c                         | 176 +++++++++++++++++++-----------
 arch/x86/mm/pat_internal.h                |  22 ++--
 arch/x86/mm/pat_rbtree.c                  |   8 +-
 arch/x86/pci/i386.c                       |   4 +-
 arch/x86/xen/enlighten.c                  |  25 ++---
 arch/x86/xen/mmu.c                        |  47 +-------
 arch/x86/xen/xen-ops.h                    |   1 -
 drivers/video/fbdev/gbefb.c               |   3 +-
 drivers/video/fbdev/vermilion/vermilion.c |   6 +-
 22 files changed, 412 insertions(+), 279 deletions(-)

-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHGz-0002S3-Qn; Mon, 03 Nov 2014 13:02:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGx-0002Qa-NE
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FC/60-09936-5DC77545; Mon, 03 Nov 2014 13:02:13 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415019731!4368574!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25458 invoked from network); 3 Nov 2014 13:02:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id D4BA1AC38;
	Mon,  3 Nov 2014 13:02:09 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:46 +0100
Message-Id: <1415019724-4317-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 x86 architecture offers via the PAT (Page Attribute Table) a way to
specify different caching modes in page table entries. The PAT MSR contains
8 entries each specifying one of 6 possible cache modes. A pte references one
of those entries via 3 bits: _PAGE_PAT, _PAGE_PWT and _PAGE_PCD.

The Linux kernel currently supports only 4 different cache modes. The PAT MSR
is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the
top 4 entries in the PAT MSR are the same as the 4 lower entries.

This results in the kernel not supporting e.g. write-through mode. Especially
this cache mode would speed up drivers of video cards which now have to use
uncached accesses.

OTOH some old processors (Pentium) don't support PAT correctly and the Xen
hypervisor has been using a different PAT MSR configuration for some time now
and can't change that as this setting is part of the ABI.

This patch set abstracts the cache mode from the pte and introduces tables to
translate between cache mode and pte bits (the default cache mode "write back"
is hard-wired to PAT entry 0). The tables are statically initialized with
values being compatible to old processors and current usage. As soon as the
PAT MSR is changed (or - in case of Xen - is read at boot time) the tables are
changed accordingly. Requests of mappings with special cache modes are always
possible now, in case they are not supported there will be a fallback to a
compatible but slower mode.

Summing it up, this patch set adds the following features:
- capability to support WT and WP cache modes on processors with full PAT
  support
- processors with no or uncorrect PAT support are still working as today, even
  if WT or WP cache mode are selected by drivers for some pages
- reduction of Xen special handling regarding cache mode

Changes in V6:
- add new patch 10 (x86: Remove looking for setting of _PAGE_PAT_LARGE in
  pageattr.c) as suggested by Thomas Gleixner
- replaced SOB of Stefan Bader by "Based-on-patch-by:" as suggested by
  Borislav Petkov

Changes in V5:
- split up first patch as requested by Ingo Molnar and Thomas Gleixner
- add a helper function in pat_init_cache_modes() as requested by Ingo Molnar

Changes in V4:
- rebased to 3.18-rc2

Changes in V3:
- corrected two minor nits (UC_MINUS, again) detected by Toshi Kani

Changes in V2:
- simplified handling of PAT MSR write under Xen as suggested by David Vrabel
- removed resetting of pat_enabled under Xen
- two small corrections requested by Toshi Kani (UC_MINUS cache mode in
  vermilion driver, fix 32 bit kernel build failure)
- correct build error on non-x86 arch by moving definition of
  update_cache_mode_entry() to x86 specific header

Changes since RFC:
- renamed functions and variables as suggested by Toshi Kani
- corrected cache mode bits for WT and WP
- modified handling of PAT MSR write under Xen as suggested by Jan Beulich


Juergen Gross (18):
  x86: Make page cache mode a real type
  x86: Use new cache mode type in include/asm/fb.h
  x86: Use new cache mode type in drivers/video/fbdev/gbefb.c
  x86: Use new cache mode type in drivers/video/fbdev/vermilion
  x86: Use new cache mode type in arch/x86/pci
  x86: Use new cache mode type in arch/x86/mm/init_64.c
  x86: Use new cache mode type in asm/pgtable.h
  x86: Use new cache mode type in mm/iomap_32.c
  x86: Use new cache mode type in track_pfn_remap() and
    track_pfn_insert()
  x86: Remove looking for setting of _PAGE_PAT_LARGE in pageattr.c
  x86: Use new cache mode type in setting page attributes
  x86: Use new cache mode type in mm/ioremap.c
  x86: Use new cache mode type in memtype related functions
  x86: Clean up pgtable_types.h
  x86: Support PAT bit in pagetable dump for lower levels
  x86: Respect PAT bit when copying pte values between large and normal
    pages
  x86: Enable PAT to use cache mode translation tables
  xen: Support Xen pv-domains using PAT

 arch/x86/include/asm/cacheflush.h         |  38 ++++---
 arch/x86/include/asm/fb.h                 |   6 +-
 arch/x86/include/asm/io.h                 |   2 +-
 arch/x86/include/asm/pat.h                |   7 +-
 arch/x86/include/asm/pgtable.h            |  19 ++--
 arch/x86/include/asm/pgtable_types.h      |  96 ++++++++++++----
 arch/x86/mm/dump_pagetables.c             |  24 ++--
 arch/x86/mm/init.c                        |  37 +++++++
 arch/x86/mm/init_64.c                     |   9 +-
 arch/x86/mm/iomap_32.c                    |  12 +-
 arch/x86/mm/ioremap.c                     |  63 ++++++-----
 arch/x86/mm/mm_internal.h                 |   2 +
 arch/x86/mm/pageattr.c                    |  84 ++++++++------
 arch/x86/mm/pat.c                         | 176 +++++++++++++++++++-----------
 arch/x86/mm/pat_internal.h                |  22 ++--
 arch/x86/mm/pat_rbtree.c                  |   8 +-
 arch/x86/pci/i386.c                       |   4 +-
 arch/x86/xen/enlighten.c                  |  25 ++---
 arch/x86/xen/mmu.c                        |  47 +-------
 arch/x86/xen/xen-ops.h                    |   1 -
 drivers/video/fbdev/gbefb.c               |   3 +-
 drivers/video/fbdev/vermilion/vermilion.c |   6 +-
 22 files changed, 412 insertions(+), 279 deletions(-)

-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHH3-0002WK-Jg; Mon, 03 Nov 2014 13:02:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH1-0002TP-F3
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	65/A0-09936-ADC77545; Mon, 03 Nov 2014 13:02:18 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415019737!12424231!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20362 invoked from network); 3 Nov 2014 13:02:18 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:18 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id BDD5AAD85;
	Mon,  3 Nov 2014 13:02:17 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:02:04 +0100
Message-Id: <1415019724-4317-19-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 18/18] xen: Support Xen pv-domains using PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 dynamical mapping between cache modes and pgprot values it is
now possible to use all cache modes via the Xen hypervisor PAT settings
in a pv domain.

All to be done is to read the PAT configuration MSR and set up the
translation tables accordingly.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/xen/enlighten.c | 25 +++++++------------------
 arch/x86/xen/mmu.c       | 47 +----------------------------------------------
 arch/x86/xen/xen-ops.h   |  1 -
 3 files changed, 8 insertions(+), 65 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index fac5e4f..6bf3a13 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1100,12 +1100,6 @@ static int xen_write_msr_safe(unsigned int msr, unsigned low, unsigned high)
 		/* Fast syscall setup is all done in hypercalls, so
 		   these are all ignored.  Stub them out here to stop
 		   Xen console noise. */
-		break;
-
-	case MSR_IA32_CR_PAT:
-		if (smp_processor_id() == 0)
-			xen_set_pat(((u64)high << 32) | low);
-		break;
 
 	default:
 		ret = native_write_msr_safe(msr, low, high);
@@ -1561,10 +1555,6 @@ asmlinkage __visible 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);
 
 	/*
 	 * Prevent page tables from being allocated in highmem, even
@@ -1618,14 +1608,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
 	 */
 	acpi_numa = -1;
 #endif
-#ifdef CONFIG_X86_PAT
-	/*
-	 * For right now disable the PAT. We should remove this once
-	 * git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
-	 * (xen/pat: Disable PAT support for now) is reverted.
-	 */
-	pat_enabled = 0;
-#endif
 	/* Don't do the full vcpu_info placement stuff until we have a
 	   possible map and a non-dummy shared_info. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
@@ -1636,6 +1618,13 @@ asmlinkage __visible void __init xen_start_kernel(void)
 	xen_raw_console_write("mapping kernel into physical memory\n");
 	xen_setup_kernel_pagetable((pgd_t *)xen_start_info->pt_base, xen_start_info->nr_pages);
 
+	/*
+	 * Modify the cache mode translation tables to match Xen's PAT
+	 * configuration.
+	 */
+
+	pat_init_cache_modes();
+
 	/* keep using Xen gdt for now; no urgent need to change it */
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a8a1a3d..9855eb8 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -410,13 +410,7 @@ static pteval_t pte_pfn_to_mfn(pteval_t val)
 __visible 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
+
 	return pte_mfn_to_pfn(pteval);
 }
 PV_CALLEE_SAVE_REGS_THUNK(xen_pte_val);
@@ -427,47 +421,8 @@ __visible pgdval_t xen_pgd_val(pgd_t pgd)
 }
 PV_CALLEE_SAVE_REGS_THUNK(xen_pgd_val);
 
-/*
- * Xen's PAT setup is part of its ABI, though I assume entries 6 & 7
- * are reserved for now, to correspond to the Intel-reserved PAT
- * types.
- *
- * We expect Linux's PAT set as follows:
- *
- * Idx  PTE flags        Linux    Xen    Default
- * 0                     WB       WB     WB
- * 1            PWT      WC       WT     WT
- * 2        PCD          UC-      UC-    UC-
- * 3        PCD PWT      UC       UC     UC
- * 4    PAT              WB       WC     WB
- * 5    PAT     PWT      WC       WP     WT
- * 6    PAT PCD          UC-      rsv    UC-
- * 7    PAT PCD PWT      UC       rsv    UC
- */
-
-void xen_set_pat(u64 pat)
-{
-	/* We expect Linux to use a PAT setting of
-	 * UC UC- WC WB (ignoring the PAT flag) */
-	WARN_ON(pat != 0x0007010600070106ull);
-}
-
 __visible pte_t xen_make_pte(pteval_t pte)
 {
-#if 0
-	/* If Linux is trying to set a WC pte, then map to the Xen WC.
-	 * If _PAGE_PAT is set, then it probably means it is really
-	 * _PAGE_PSE, so avoid fiddling with the PAT mapping and hope
-	 * things work out OK...
-	 *
-	 * (We should never see kernel mappings with _PAGE_PSE set,
-	 * but we could see hugetlbfs mappings, I think.).
-	 */
-	if (pat_enabled && !WARN_ON(pte & _PAGE_PAT)) {
-		if ((pte & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
-			pte = (pte & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
-	}
-#endif
 	pte = pte_pfn_to_mfn(pte);
 
 	return native_make_pte(pte);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 28c7e0b..4ab9298 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -33,7 +33,6 @@ extern unsigned long xen_max_p2m_pfn;
 
 void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
-void xen_set_pat(u64);
 
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:02:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHH3-0002WK-Jg; Mon, 03 Nov 2014 13:02:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHH1-0002TP-F3
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	65/A0-09936-ADC77545; Mon, 03 Nov 2014 13:02:18 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415019737!12424231!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20362 invoked from network); 3 Nov 2014 13:02:18 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:18 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id BDD5AAD85;
	Mon,  3 Nov 2014 13:02:17 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:02:04 +0100
Message-Id: <1415019724-4317-19-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 18/18] xen: Support Xen pv-domains using PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 dynamical mapping between cache modes and pgprot values it is
now possible to use all cache modes via the Xen hypervisor PAT settings
in a pv domain.

All to be done is to read the PAT configuration MSR and set up the
translation tables accordingly.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/xen/enlighten.c | 25 +++++++------------------
 arch/x86/xen/mmu.c       | 47 +----------------------------------------------
 arch/x86/xen/xen-ops.h   |  1 -
 3 files changed, 8 insertions(+), 65 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index fac5e4f..6bf3a13 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1100,12 +1100,6 @@ static int xen_write_msr_safe(unsigned int msr, unsigned low, unsigned high)
 		/* Fast syscall setup is all done in hypercalls, so
 		   these are all ignored.  Stub them out here to stop
 		   Xen console noise. */
-		break;
-
-	case MSR_IA32_CR_PAT:
-		if (smp_processor_id() == 0)
-			xen_set_pat(((u64)high << 32) | low);
-		break;
 
 	default:
 		ret = native_write_msr_safe(msr, low, high);
@@ -1561,10 +1555,6 @@ asmlinkage __visible 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);
 
 	/*
 	 * Prevent page tables from being allocated in highmem, even
@@ -1618,14 +1608,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
 	 */
 	acpi_numa = -1;
 #endif
-#ifdef CONFIG_X86_PAT
-	/*
-	 * For right now disable the PAT. We should remove this once
-	 * git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
-	 * (xen/pat: Disable PAT support for now) is reverted.
-	 */
-	pat_enabled = 0;
-#endif
 	/* Don't do the full vcpu_info placement stuff until we have a
 	   possible map and a non-dummy shared_info. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
@@ -1636,6 +1618,13 @@ asmlinkage __visible void __init xen_start_kernel(void)
 	xen_raw_console_write("mapping kernel into physical memory\n");
 	xen_setup_kernel_pagetable((pgd_t *)xen_start_info->pt_base, xen_start_info->nr_pages);
 
+	/*
+	 * Modify the cache mode translation tables to match Xen's PAT
+	 * configuration.
+	 */
+
+	pat_init_cache_modes();
+
 	/* keep using Xen gdt for now; no urgent need to change it */
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a8a1a3d..9855eb8 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -410,13 +410,7 @@ static pteval_t pte_pfn_to_mfn(pteval_t val)
 __visible 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
+
 	return pte_mfn_to_pfn(pteval);
 }
 PV_CALLEE_SAVE_REGS_THUNK(xen_pte_val);
@@ -427,47 +421,8 @@ __visible pgdval_t xen_pgd_val(pgd_t pgd)
 }
 PV_CALLEE_SAVE_REGS_THUNK(xen_pgd_val);
 
-/*
- * Xen's PAT setup is part of its ABI, though I assume entries 6 & 7
- * are reserved for now, to correspond to the Intel-reserved PAT
- * types.
- *
- * We expect Linux's PAT set as follows:
- *
- * Idx  PTE flags        Linux    Xen    Default
- * 0                     WB       WB     WB
- * 1            PWT      WC       WT     WT
- * 2        PCD          UC-      UC-    UC-
- * 3        PCD PWT      UC       UC     UC
- * 4    PAT              WB       WC     WB
- * 5    PAT     PWT      WC       WP     WT
- * 6    PAT PCD          UC-      rsv    UC-
- * 7    PAT PCD PWT      UC       rsv    UC
- */
-
-void xen_set_pat(u64 pat)
-{
-	/* We expect Linux to use a PAT setting of
-	 * UC UC- WC WB (ignoring the PAT flag) */
-	WARN_ON(pat != 0x0007010600070106ull);
-}
-
 __visible pte_t xen_make_pte(pteval_t pte)
 {
-#if 0
-	/* If Linux is trying to set a WC pte, then map to the Xen WC.
-	 * If _PAGE_PAT is set, then it probably means it is really
-	 * _PAGE_PSE, so avoid fiddling with the PAT mapping and hope
-	 * things work out OK...
-	 *
-	 * (We should never see kernel mappings with _PAGE_PSE set,
-	 * but we could see hugetlbfs mappings, I think.).
-	 */
-	if (pat_enabled && !WARN_ON(pte & _PAGE_PAT)) {
-		if ((pte & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
-			pte = (pte & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
-	}
-#endif
 	pte = pte_pfn_to_mfn(pte);
 
 	return native_make_pte(pte);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 28c7e0b..4ab9298 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -33,7 +33,6 @@ extern unsigned long xen_max_p2m_pfn;
 
 void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
-void xen_set_pat(u64);
 
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHH1-0002TQ-0r; Mon, 03 Nov 2014 13:02:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGz-0002RG-3Y
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CD/44-09842-8DC77545; Mon, 03 Nov 2014 13:02:16 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415019734!11827962!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32171 invoked from network); 3 Nov 2014 13:02:15 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:15 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9E511AD55;
	Mon,  3 Nov 2014 13:02:14 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:57 +0100
Message-Id: <1415019724-4317-12-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 11/18] x86: Use new cache mode type in
	setting page attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type in the functions for modifying page
attributes.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/mm/pageattr.c | 52 +++++++++++++++++++++++++++-----------------------
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 87c0d36..9f7e1b4 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1304,12 +1304,6 @@ static int __change_page_attr_set_clr(struct cpa_data *cpa, int checkalias)
 	return 0;
 }
 
-static inline int cache_attr(pgprot_t attr)
-{
-	return pgprot_val(attr) &
-		(_PAGE_PAT | _PAGE_PWT | _PAGE_PCD);
-}
-
 static int change_page_attr_set_clr(unsigned long *addr, int numpages,
 				    pgprot_t mask_set, pgprot_t mask_clr,
 				    int force_split, int in_flag,
@@ -1390,7 +1384,7 @@ static int change_page_attr_set_clr(unsigned long *addr, int numpages,
 	 * No need to flush, when we did not set any of the caching
 	 * attributes:
 	 */
-	cache = cache_attr(mask_set);
+	cache = !!pgprot2cachemode(mask_set);
 
 	/*
 	 * On success we use CLFLUSH, when the CPU supports it to
@@ -1445,7 +1439,8 @@ int _set_memory_uc(unsigned long addr, int numpages)
 	 * for now UC MINUS. see comments in ioremap_nocache()
 	 */
 	return change_page_attr_set(&addr, numpages,
-				    __pgprot(_PAGE_CACHE_UC_MINUS), 0);
+				    cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
+				    0);
 }
 
 int set_memory_uc(unsigned long addr, int numpages)
@@ -1474,7 +1469,7 @@ out_err:
 EXPORT_SYMBOL(set_memory_uc);
 
 static int _set_memory_array(unsigned long *addr, int addrinarray,
-		unsigned long new_type)
+		enum page_cache_mode new_type)
 {
 	int i, j;
 	int ret;
@@ -1484,17 +1479,19 @@ static int _set_memory_array(unsigned long *addr, int addrinarray,
 	 */
 	for (i = 0; i < addrinarray; i++) {
 		ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE,
-					new_type, NULL);
+					cachemode2protval(new_type), NULL);
 		if (ret)
 			goto out_free;
 	}
 
 	ret = change_page_attr_set(addr, addrinarray,
-				    __pgprot(_PAGE_CACHE_UC_MINUS), 1);
+				   cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
+				   1);
 
-	if (!ret && new_type == _PAGE_CACHE_WC)
+	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
 		ret = change_page_attr_set_clr(addr, addrinarray,
-					       __pgprot(_PAGE_CACHE_WC),
+					       cachemode2pgprot(
+						_PAGE_CACHE_MODE_WC),
 					       __pgprot(_PAGE_CACHE_MASK),
 					       0, CPA_ARRAY, NULL);
 	if (ret)
@@ -1511,13 +1508,13 @@ out_free:
 
 int set_memory_array_uc(unsigned long *addr, int addrinarray)
 {
-	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_UC_MINUS);
+	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_UC_MINUS);
 }
 EXPORT_SYMBOL(set_memory_array_uc);
 
 int set_memory_array_wc(unsigned long *addr, int addrinarray)
 {
-	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_WC);
+	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WC);
 }
 EXPORT_SYMBOL(set_memory_array_wc);
 
@@ -1527,10 +1524,12 @@ int _set_memory_wc(unsigned long addr, int numpages)
 	unsigned long addr_copy = addr;
 
 	ret = change_page_attr_set(&addr, numpages,
-				    __pgprot(_PAGE_CACHE_UC_MINUS), 0);
+				   cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
+				   0);
 	if (!ret) {
 		ret = change_page_attr_set_clr(&addr_copy, numpages,
-					       __pgprot(_PAGE_CACHE_WC),
+					       cachemode2pgprot(
+						_PAGE_CACHE_MODE_WC),
 					       __pgprot(_PAGE_CACHE_MASK),
 					       0, 0, NULL);
 	}
@@ -1564,6 +1563,7 @@ EXPORT_SYMBOL(set_memory_wc);
 
 int _set_memory_wb(unsigned long addr, int numpages)
 {
+	/* WB cache mode is hard wired to all cache attribute bits being 0 */
 	return change_page_attr_clear(&addr, numpages,
 				      __pgprot(_PAGE_CACHE_MASK), 0);
 }
@@ -1586,6 +1586,7 @@ int set_memory_array_wb(unsigned long *addr, int addrinarray)
 	int i;
 	int ret;
 
+	/* WB cache mode is hard wired to all cache attribute bits being 0 */
 	ret = change_page_attr_clear(addr, addrinarray,
 				      __pgprot(_PAGE_CACHE_MASK), 1);
 	if (ret)
@@ -1648,7 +1649,7 @@ int set_pages_uc(struct page *page, int numpages)
 EXPORT_SYMBOL(set_pages_uc);
 
 static int _set_pages_array(struct page **pages, int addrinarray,
-		unsigned long new_type)
+		enum page_cache_mode new_type)
 {
 	unsigned long start;
 	unsigned long end;
@@ -1661,15 +1662,17 @@ static int _set_pages_array(struct page **pages, int addrinarray,
 			continue;
 		start = page_to_pfn(pages[i]) << PAGE_SHIFT;
 		end = start + PAGE_SIZE;
-		if (reserve_memtype(start, end, new_type, NULL))
+		if (reserve_memtype(start, end, cachemode2protval(new_type),
+				    NULL))
 			goto err_out;
 	}
 
 	ret = cpa_set_pages_array(pages, addrinarray,
-			__pgprot(_PAGE_CACHE_UC_MINUS));
-	if (!ret && new_type == _PAGE_CACHE_WC)
+			cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS));
+	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
 		ret = change_page_attr_set_clr(NULL, addrinarray,
-					       __pgprot(_PAGE_CACHE_WC),
+					       cachemode2pgprot(
+						_PAGE_CACHE_MODE_WC),
 					       __pgprot(_PAGE_CACHE_MASK),
 					       0, CPA_PAGES_ARRAY, pages);
 	if (ret)
@@ -1689,13 +1692,13 @@ err_out:
 
 int set_pages_array_uc(struct page **pages, int addrinarray)
 {
-	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_UC_MINUS);
+	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_UC_MINUS);
 }
 EXPORT_SYMBOL(set_pages_array_uc);
 
 int set_pages_array_wc(struct page **pages, int addrinarray)
 {
-	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_WC);
+	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WC);
 }
 EXPORT_SYMBOL(set_pages_array_wc);
 
@@ -1714,6 +1717,7 @@ int set_pages_array_wb(struct page **pages, int addrinarray)
 	unsigned long end;
 	int i;
 
+	/* WB cache mode is hard wired to all cache attribute bits being 0 */
 	retval = cpa_clear_pages_array(pages, addrinarray,
 			__pgprot(_PAGE_CACHE_MASK));
 	if (retval)
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:02:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHH1-0002TQ-0r; Mon, 03 Nov 2014 13:02:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XlHGz-0002RG-3Y
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:02:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CD/44-09842-8DC77545; Mon, 03 Nov 2014 13:02:16 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415019734!11827962!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32171 invoked from network); 3 Nov 2014 13:02:15 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:02:15 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9E511AD55;
	Mon,  3 Nov 2014 13:02:14 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	toshi.kani@hp.com, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	bhelgaas@google.com
Date: Mon,  3 Nov 2014 14:01:57 +0100
Message-Id: <1415019724-4317-12-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V6 11/18] x86: Use new cache mode type in
	setting page attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of directly using the cache mode bits in the pte switch to
using the cache mode type in the functions for modifying page
attributes.

Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/mm/pageattr.c | 52 +++++++++++++++++++++++++++-----------------------
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 87c0d36..9f7e1b4 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1304,12 +1304,6 @@ static int __change_page_attr_set_clr(struct cpa_data *cpa, int checkalias)
 	return 0;
 }
 
-static inline int cache_attr(pgprot_t attr)
-{
-	return pgprot_val(attr) &
-		(_PAGE_PAT | _PAGE_PWT | _PAGE_PCD);
-}
-
 static int change_page_attr_set_clr(unsigned long *addr, int numpages,
 				    pgprot_t mask_set, pgprot_t mask_clr,
 				    int force_split, int in_flag,
@@ -1390,7 +1384,7 @@ static int change_page_attr_set_clr(unsigned long *addr, int numpages,
 	 * No need to flush, when we did not set any of the caching
 	 * attributes:
 	 */
-	cache = cache_attr(mask_set);
+	cache = !!pgprot2cachemode(mask_set);
 
 	/*
 	 * On success we use CLFLUSH, when the CPU supports it to
@@ -1445,7 +1439,8 @@ int _set_memory_uc(unsigned long addr, int numpages)
 	 * for now UC MINUS. see comments in ioremap_nocache()
 	 */
 	return change_page_attr_set(&addr, numpages,
-				    __pgprot(_PAGE_CACHE_UC_MINUS), 0);
+				    cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
+				    0);
 }
 
 int set_memory_uc(unsigned long addr, int numpages)
@@ -1474,7 +1469,7 @@ out_err:
 EXPORT_SYMBOL(set_memory_uc);
 
 static int _set_memory_array(unsigned long *addr, int addrinarray,
-		unsigned long new_type)
+		enum page_cache_mode new_type)
 {
 	int i, j;
 	int ret;
@@ -1484,17 +1479,19 @@ static int _set_memory_array(unsigned long *addr, int addrinarray,
 	 */
 	for (i = 0; i < addrinarray; i++) {
 		ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE,
-					new_type, NULL);
+					cachemode2protval(new_type), NULL);
 		if (ret)
 			goto out_free;
 	}
 
 	ret = change_page_attr_set(addr, addrinarray,
-				    __pgprot(_PAGE_CACHE_UC_MINUS), 1);
+				   cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
+				   1);
 
-	if (!ret && new_type == _PAGE_CACHE_WC)
+	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
 		ret = change_page_attr_set_clr(addr, addrinarray,
-					       __pgprot(_PAGE_CACHE_WC),
+					       cachemode2pgprot(
+						_PAGE_CACHE_MODE_WC),
 					       __pgprot(_PAGE_CACHE_MASK),
 					       0, CPA_ARRAY, NULL);
 	if (ret)
@@ -1511,13 +1508,13 @@ out_free:
 
 int set_memory_array_uc(unsigned long *addr, int addrinarray)
 {
-	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_UC_MINUS);
+	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_UC_MINUS);
 }
 EXPORT_SYMBOL(set_memory_array_uc);
 
 int set_memory_array_wc(unsigned long *addr, int addrinarray)
 {
-	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_WC);
+	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WC);
 }
 EXPORT_SYMBOL(set_memory_array_wc);
 
@@ -1527,10 +1524,12 @@ int _set_memory_wc(unsigned long addr, int numpages)
 	unsigned long addr_copy = addr;
 
 	ret = change_page_attr_set(&addr, numpages,
-				    __pgprot(_PAGE_CACHE_UC_MINUS), 0);
+				   cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
+				   0);
 	if (!ret) {
 		ret = change_page_attr_set_clr(&addr_copy, numpages,
-					       __pgprot(_PAGE_CACHE_WC),
+					       cachemode2pgprot(
+						_PAGE_CACHE_MODE_WC),
 					       __pgprot(_PAGE_CACHE_MASK),
 					       0, 0, NULL);
 	}
@@ -1564,6 +1563,7 @@ EXPORT_SYMBOL(set_memory_wc);
 
 int _set_memory_wb(unsigned long addr, int numpages)
 {
+	/* WB cache mode is hard wired to all cache attribute bits being 0 */
 	return change_page_attr_clear(&addr, numpages,
 				      __pgprot(_PAGE_CACHE_MASK), 0);
 }
@@ -1586,6 +1586,7 @@ int set_memory_array_wb(unsigned long *addr, int addrinarray)
 	int i;
 	int ret;
 
+	/* WB cache mode is hard wired to all cache attribute bits being 0 */
 	ret = change_page_attr_clear(addr, addrinarray,
 				      __pgprot(_PAGE_CACHE_MASK), 1);
 	if (ret)
@@ -1648,7 +1649,7 @@ int set_pages_uc(struct page *page, int numpages)
 EXPORT_SYMBOL(set_pages_uc);
 
 static int _set_pages_array(struct page **pages, int addrinarray,
-		unsigned long new_type)
+		enum page_cache_mode new_type)
 {
 	unsigned long start;
 	unsigned long end;
@@ -1661,15 +1662,17 @@ static int _set_pages_array(struct page **pages, int addrinarray,
 			continue;
 		start = page_to_pfn(pages[i]) << PAGE_SHIFT;
 		end = start + PAGE_SIZE;
-		if (reserve_memtype(start, end, new_type, NULL))
+		if (reserve_memtype(start, end, cachemode2protval(new_type),
+				    NULL))
 			goto err_out;
 	}
 
 	ret = cpa_set_pages_array(pages, addrinarray,
-			__pgprot(_PAGE_CACHE_UC_MINUS));
-	if (!ret && new_type == _PAGE_CACHE_WC)
+			cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS));
+	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
 		ret = change_page_attr_set_clr(NULL, addrinarray,
-					       __pgprot(_PAGE_CACHE_WC),
+					       cachemode2pgprot(
+						_PAGE_CACHE_MODE_WC),
 					       __pgprot(_PAGE_CACHE_MASK),
 					       0, CPA_PAGES_ARRAY, pages);
 	if (ret)
@@ -1689,13 +1692,13 @@ err_out:
 
 int set_pages_array_uc(struct page **pages, int addrinarray)
 {
-	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_UC_MINUS);
+	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_UC_MINUS);
 }
 EXPORT_SYMBOL(set_pages_array_uc);
 
 int set_pages_array_wc(struct page **pages, int addrinarray)
 {
-	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_WC);
+	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WC);
 }
 EXPORT_SYMBOL(set_pages_array_wc);
 
@@ -1714,6 +1717,7 @@ int set_pages_array_wb(struct page **pages, int addrinarray)
 	unsigned long end;
 	int i;
 
+	/* WB cache mode is hard wired to all cache attribute bits being 0 */
 	retval = cpa_clear_pages_array(pages, addrinarray,
 			__pgprot(_PAGE_CACHE_MASK));
 	if (retval)
-- 
1.8.4.5


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:10:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:10:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHP0-0005Zx-CP; Mon, 03 Nov 2014 13:10:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1XlHOy-0005Zq-Iz
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:10:32 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	B9/4E-18267-7CE77545; Mon, 03 Nov 2014 13:10:31 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415020229!11278779!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19302 invoked from network); 3 Nov 2014 13:10:31 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:10:31 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA3DAPWS014944
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 3 Nov 2014 08:10:25 -0500
Received: from redhat.com (ovpn-116-73.ams2.redhat.com [10.36.116.73])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sA3DANTG018174; Mon, 3 Nov 2014 08:10:23 -0500
Date: Mon, 3 Nov 2014 15:10:22 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20141103131022.GB16423@redhat.com>
References: <543622CC.6050807@intel.com> <20141012095021.GC9567@redhat.com>
	<544A0174.7000003@intel.com> <20141024134747.GA6024@redhat.com>
	<5451ED1E.1000300@intel.com> <5457335B.1000308@intel.com>
	<5457686E.7020601@redhat.com> <545768CC.3000903@intel.com>
	<54576B5A.50005@intel.com> <54576E7F.3000901@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54576E7F.3000901@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: "Chen, Tiejun" <tiejun.chen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create isa bridge
 specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 01:01:03PM +0100, Paolo Bonzini wrote:
> 
> 
> On 03/11/2014 12:47, Chen, Tiejun wrote:
> > On 2014/11/3 19:36, Chen, Tiejun wrote:
> >> On 2014/11/3 19:35, Paolo Bonzini wrote:
> >>> On 03/11/2014 08:48, Chen, Tiejun wrote:
> >>>>>>>> I think the point was mostly to reserve 1f to prevent
> >>>>>>>> devices from using it.
> >>>>>>>> As we populate slots in order it doesn't seem to important ...
> >>>>>>>
> >>>>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
> >>>>>>
> >>>>>> Right, but I mean if no special options are used, 1f will typically
> >>>>>> stay free without any effort on our side.
> >>>>>
> >>>>> Yeah.
> >>>>>
> >>>>> Actually based on current info we know, seems 1f is just specific to
> >>>>> our
> >>>>> scenario :) So I always think we can occupy that. But Paolo and you
> >>>>> can
> >>>>> really determine this point.
> >>>>
> >>>> What's your idea?
> >>>
> >>> I do not have any objection to always occupying 1f for Xen IGD
> >>> passthrough.
> > 
> > After I go back to look at this again, I hope you don't misunderstand
> > what Michael mean now. He was saying we don't need to create a new
> > separate machine specific to IGD passthrough. But that idea is just from
> > you :)
> 
> It's difficult for me to follow, because xen_igd_passthrough_pc_hvm_init
> does not exist in the current tree.
> 
> The patches seem good to me; I was assuming that the new machine type
> would call xen_igd_passthrough_pc_hvm_init, but apparently I'm wrong?
> Paolo

Discussed on irc, Paolo said
<bonzini> so i don't really care how the ISA bridge is created

-- 
MST

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:10:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:10:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHP0-0005Zx-CP; Mon, 03 Nov 2014 13:10:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1XlHOy-0005Zq-Iz
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 13:10:32 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	B9/4E-18267-7CE77545; Mon, 03 Nov 2014 13:10:31 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415020229!11278779!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19302 invoked from network); 3 Nov 2014 13:10:31 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:10:31 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA3DAPWS014944
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 3 Nov 2014 08:10:25 -0500
Received: from redhat.com (ovpn-116-73.ams2.redhat.com [10.36.116.73])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sA3DANTG018174; Mon, 3 Nov 2014 08:10:23 -0500
Date: Mon, 3 Nov 2014 15:10:22 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20141103131022.GB16423@redhat.com>
References: <543622CC.6050807@intel.com> <20141012095021.GC9567@redhat.com>
	<544A0174.7000003@intel.com> <20141024134747.GA6024@redhat.com>
	<5451ED1E.1000300@intel.com> <5457335B.1000308@intel.com>
	<5457686E.7020601@redhat.com> <545768CC.3000903@intel.com>
	<54576B5A.50005@intel.com> <54576E7F.3000901@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54576E7F.3000901@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: "Chen, Tiejun" <tiejun.chen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create isa bridge
 specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 01:01:03PM +0100, Paolo Bonzini wrote:
> 
> 
> On 03/11/2014 12:47, Chen, Tiejun wrote:
> > On 2014/11/3 19:36, Chen, Tiejun wrote:
> >> On 2014/11/3 19:35, Paolo Bonzini wrote:
> >>> On 03/11/2014 08:48, Chen, Tiejun wrote:
> >>>>>>>> I think the point was mostly to reserve 1f to prevent
> >>>>>>>> devices from using it.
> >>>>>>>> As we populate slots in order it doesn't seem to important ...
> >>>>>>>
> >>>>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
> >>>>>>
> >>>>>> Right, but I mean if no special options are used, 1f will typically
> >>>>>> stay free without any effort on our side.
> >>>>>
> >>>>> Yeah.
> >>>>>
> >>>>> Actually based on current info we know, seems 1f is just specific to
> >>>>> our
> >>>>> scenario :) So I always think we can occupy that. But Paolo and you
> >>>>> can
> >>>>> really determine this point.
> >>>>
> >>>> What's your idea?
> >>>
> >>> I do not have any objection to always occupying 1f for Xen IGD
> >>> passthrough.
> > 
> > After I go back to look at this again, I hope you don't misunderstand
> > what Michael mean now. He was saying we don't need to create a new
> > separate machine specific to IGD passthrough. But that idea is just from
> > you :)
> 
> It's difficult for me to follow, because xen_igd_passthrough_pc_hvm_init
> does not exist in the current tree.
> 
> The patches seem good to me; I was assuming that the new machine type
> would call xen_igd_passthrough_pc_hvm_init, but apparently I'm wrong?
> Paolo

Discussed on irc, Paolo said
<bonzini> so i don't really care how the ISA bridge is created

-- 
MST

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:21:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:21:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHZP-0006F1-S6; Mon, 03 Nov 2014 13:21:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1XlHZO-0006Et-FG
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 13:21:18 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	CE/B3-27785-D4187545; Mon, 03 Nov 2014 13:21:17 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415020873!8887534!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25528 invoked from network); 3 Nov 2014 13:21:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:21:16 -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 sA3DL6FU015146
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 3 Nov 2014 08:21:07 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sA3DL2hD016346
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Mon, 3 Nov 2014 08:21:03 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
Date: Mon, 03 Nov 2014 14:21:01 +0100
In-Reply-To: <1412687413-22818-1-git-send-email-vkuznets@redhat.com> (Vitaly
	Kuznetsov's message of "Tue, 7 Oct 2014 15:10:05 +0200")
Message-ID: <87zjc8a08y.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFCv3 0/8] toolstack-based approach to pvhvm
	guest kexec
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Vitaly Kuznetsov <vkuznets@redhat.com> writes:

> Changes from RFC/WIPv2:
>
> Here is a slightly different approach to memory reassignment. Instead of
> introducing new (and very doubtful) XENMEM_transfer operation introduce
> simple XEN_DOMCTL_set_recipient operation and do everything in free_domheap_pages()
> handler utilizing normal domain destroy path. This is better because:
> - The approach is general-enough
> - All memory pages are usually being freed when the domain is destroyed
> - No special grants handling required
> - Better supportability
>
> With regards to PV:
> Though XEN_DOMCTL_set_recipient works for both PV and HVM this patchset does not
> bring PV kexec/kdump support. xc_domain_soft_reset() is limited to work with HVM
> domains only. The main reason for that is: it is (in theory) possible to save p2m
> and rebuild them with the new domain but that would only allow us to resume execution
> from where we stopped. If we want to execute new kernel we need to build the same
> kernel/initrd/bootstrap_pagetables/... structure we build to boot PV domain initially.
> That however would destroy the original domain's memory thus making kdump impossible.
> To make everything work additional support from kexec userspace/linux kernel is
> required and I'm not sure it makes sense to implement all this stuff in the light of
> PVH.

I don't want to create noise but I didn't get many comments on this RFC
(the only one belongs to David). In case there are no comments on RFC
(design) level I can rebase and send first non-RFC.

I understand 4.5 release is the main focus atm though I would greatly
appreciate some feedback.

Thanks,

>
> Original description:
>
> When a PVHVM linux guest performs kexec there are lots of things which
> require taking care of:
> - shared info, vcpu_info
> - grants
> - event channels
> - ...
> Instead of taking care of all these things we can rebuild the domain
> performing kexec from scratch doing so-called soft-reboot.
>
> The idea was suggested by David Vrabel, Jan Beulich, and Konrad Rzeszutek Wilk.
>
> P.S. The patch series can be tested with PVHVM Linux guest with the following
> modifications:
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index c0cb11f..33c5cdd 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -33,6 +33,10 @@
>  #include <linux/memblock.h>
>  #include <linux/edd.h>
>
> +#ifdef CONFIG_KEXEC
> +#include <linux/kexec.h>
> +#endif
> +
>  #include <xen/xen.h>
>  #include <xen/events.h>
>  #include <xen/interface/xen.h>
> @@ -1810,6 +1814,22 @@ static struct notifier_block xen_hvm_cpu_notifier = {
>    .notifier_call   = xen_hvm_cpu_notify,
>  };
>
> +#ifdef CONFIG_KEXEC
> +static void xen_pvhvm_kexec_shutdown(void)
> +{
> +	native_machine_shutdown();
> +	if (kexec_in_progress) {
> +	   xen_reboot(SHUTDOWN_soft_reset);
> +	   }
> +}
> +
> +static void xen_pvhvm_crash_shutdown(struct pt_regs *regs)
> +{
> +	native_machine_crash_shutdown(regs);
> +	xen_reboot(SHUTDOWN_soft_reset);
> +}
> +#endif
> +
>  static void __init xen_hvm_guest_init(void)
>  {
> 	init_hvm_pv_info();
> @@ -1826,6 +1846,10 @@ static void __init xen_hvm_guest_init(void)
>    x86_init.irqs.intr_init = xen_init_IRQ;
>    xen_hvm_init_time_ops();
>    xen_hvm_init_mmu_ops();
> +#ifdef CONFIG_KEXEC
> +	machine_ops.shutdown = xen_pvhvm_kexec_shutdown;
> +	machine_ops.crash_shutdown = xen_pvhvm_crash_shutdown;
> +#endif
>  }
>
>  static bool xen_nopv = false;
> diff --git a/include/xen/interface/sched.h b/include/xen/interface/sched.h
> index 9ce0839..b5942a8 100644
> --- a/include/xen/interface/sched.h
> +++ b/include/xen/interface/sched.h
> @@ -107,5 +107,6 @@ struct sched_watchdog {
>  #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.         */
>  #define SHUTDOWN_crash      3  /* Tell controller we've crashed.             */
>  #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.     */
> +#define SHUTDOWN_soft_reset 5  /* Soft-reset for kexec.                      */
>
>  #endif /* __XEN_PUBLIC_SCHED_H__ */
>
> Vitaly Kuznetsov (8):
>   xen: introduce SHUTDOWN_soft_reset shutdown reason
>   libxl: support SHUTDOWN_soft_reset shutdown reason
>   xen: introduce XEN_DOMCTL_set_recipient
>   libxc: support XEN_DOMCTL_set_recipient
>   libxl: add libxl__domain_soft_reset_destroy_old()
>   libxc: introduce soft reset for HVM domains
>   libxl: soft reset support
>   xsm: add XEN_DOMCTL_set_recipient support
>
>  tools/libxc/Makefile                |   1 +
>  tools/libxc/xc_domain.c             |  10 +
>  tools/libxc/xc_domain_soft_reset.c  | 394 ++++++++++++++++++++++++++++++++++++
>  tools/libxc/xenctrl.h               |  14 ++
>  tools/libxc/xenguest.h              |  20 ++
>  tools/libxl/libxl.c                 |  32 ++-
>  tools/libxl/libxl.h                 |   6 +
>  tools/libxl/libxl_create.c          | 103 +++++++++-
>  tools/libxl/libxl_internal.h        |   8 +
>  tools/libxl/libxl_types.idl         |   1 +
>  tools/libxl/xl_cmdimpl.c            |  24 ++-
>  tools/python/xen/lowlevel/xl/xl.c   |   1 +
>  xen/common/domain.c                 |   3 +
>  xen/common/domctl.c                 |  35 ++++
>  xen/common/page_alloc.c             |  26 ++-
>  xen/common/shutdown.c               |   7 +
>  xen/include/public/domctl.h         |  19 ++
>  xen/include/public/sched.h          |   3 +-
>  xen/include/xen/sched.h             |   1 +
>  xen/include/xsm/dummy.h             |   6 +
>  xen/include/xsm/xsm.h               |   6 +
>  xen/xsm/dummy.c                     |   1 +
>  xen/xsm/flask/hooks.c               |  17 ++
>  xen/xsm/flask/policy/access_vectors |  10 +
>  24 files changed, 726 insertions(+), 22 deletions(-)
>  create mode 100644 tools/libxc/xc_domain_soft_reset.c

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:21:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:21:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHZP-0006F1-S6; Mon, 03 Nov 2014 13:21:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1XlHZO-0006Et-FG
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 13:21:18 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	CE/B3-27785-D4187545; Mon, 03 Nov 2014 13:21:17 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415020873!8887534!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25528 invoked from network); 3 Nov 2014 13:21:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:21:16 -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 sA3DL6FU015146
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 3 Nov 2014 08:21:07 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sA3DL2hD016346
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Mon, 3 Nov 2014 08:21:03 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
Date: Mon, 03 Nov 2014 14:21:01 +0100
In-Reply-To: <1412687413-22818-1-git-send-email-vkuznets@redhat.com> (Vitaly
	Kuznetsov's message of "Tue, 7 Oct 2014 15:10:05 +0200")
Message-ID: <87zjc8a08y.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFCv3 0/8] toolstack-based approach to pvhvm
	guest kexec
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Vitaly Kuznetsov <vkuznets@redhat.com> writes:

> Changes from RFC/WIPv2:
>
> Here is a slightly different approach to memory reassignment. Instead of
> introducing new (and very doubtful) XENMEM_transfer operation introduce
> simple XEN_DOMCTL_set_recipient operation and do everything in free_domheap_pages()
> handler utilizing normal domain destroy path. This is better because:
> - The approach is general-enough
> - All memory pages are usually being freed when the domain is destroyed
> - No special grants handling required
> - Better supportability
>
> With regards to PV:
> Though XEN_DOMCTL_set_recipient works for both PV and HVM this patchset does not
> bring PV kexec/kdump support. xc_domain_soft_reset() is limited to work with HVM
> domains only. The main reason for that is: it is (in theory) possible to save p2m
> and rebuild them with the new domain but that would only allow us to resume execution
> from where we stopped. If we want to execute new kernel we need to build the same
> kernel/initrd/bootstrap_pagetables/... structure we build to boot PV domain initially.
> That however would destroy the original domain's memory thus making kdump impossible.
> To make everything work additional support from kexec userspace/linux kernel is
> required and I'm not sure it makes sense to implement all this stuff in the light of
> PVH.

I don't want to create noise but I didn't get many comments on this RFC
(the only one belongs to David). In case there are no comments on RFC
(design) level I can rebase and send first non-RFC.

I understand 4.5 release is the main focus atm though I would greatly
appreciate some feedback.

Thanks,

>
> Original description:
>
> When a PVHVM linux guest performs kexec there are lots of things which
> require taking care of:
> - shared info, vcpu_info
> - grants
> - event channels
> - ...
> Instead of taking care of all these things we can rebuild the domain
> performing kexec from scratch doing so-called soft-reboot.
>
> The idea was suggested by David Vrabel, Jan Beulich, and Konrad Rzeszutek Wilk.
>
> P.S. The patch series can be tested with PVHVM Linux guest with the following
> modifications:
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index c0cb11f..33c5cdd 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -33,6 +33,10 @@
>  #include <linux/memblock.h>
>  #include <linux/edd.h>
>
> +#ifdef CONFIG_KEXEC
> +#include <linux/kexec.h>
> +#endif
> +
>  #include <xen/xen.h>
>  #include <xen/events.h>
>  #include <xen/interface/xen.h>
> @@ -1810,6 +1814,22 @@ static struct notifier_block xen_hvm_cpu_notifier = {
>    .notifier_call   = xen_hvm_cpu_notify,
>  };
>
> +#ifdef CONFIG_KEXEC
> +static void xen_pvhvm_kexec_shutdown(void)
> +{
> +	native_machine_shutdown();
> +	if (kexec_in_progress) {
> +	   xen_reboot(SHUTDOWN_soft_reset);
> +	   }
> +}
> +
> +static void xen_pvhvm_crash_shutdown(struct pt_regs *regs)
> +{
> +	native_machine_crash_shutdown(regs);
> +	xen_reboot(SHUTDOWN_soft_reset);
> +}
> +#endif
> +
>  static void __init xen_hvm_guest_init(void)
>  {
> 	init_hvm_pv_info();
> @@ -1826,6 +1846,10 @@ static void __init xen_hvm_guest_init(void)
>    x86_init.irqs.intr_init = xen_init_IRQ;
>    xen_hvm_init_time_ops();
>    xen_hvm_init_mmu_ops();
> +#ifdef CONFIG_KEXEC
> +	machine_ops.shutdown = xen_pvhvm_kexec_shutdown;
> +	machine_ops.crash_shutdown = xen_pvhvm_crash_shutdown;
> +#endif
>  }
>
>  static bool xen_nopv = false;
> diff --git a/include/xen/interface/sched.h b/include/xen/interface/sched.h
> index 9ce0839..b5942a8 100644
> --- a/include/xen/interface/sched.h
> +++ b/include/xen/interface/sched.h
> @@ -107,5 +107,6 @@ struct sched_watchdog {
>  #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.         */
>  #define SHUTDOWN_crash      3  /* Tell controller we've crashed.             */
>  #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.     */
> +#define SHUTDOWN_soft_reset 5  /* Soft-reset for kexec.                      */
>
>  #endif /* __XEN_PUBLIC_SCHED_H__ */
>
> Vitaly Kuznetsov (8):
>   xen: introduce SHUTDOWN_soft_reset shutdown reason
>   libxl: support SHUTDOWN_soft_reset shutdown reason
>   xen: introduce XEN_DOMCTL_set_recipient
>   libxc: support XEN_DOMCTL_set_recipient
>   libxl: add libxl__domain_soft_reset_destroy_old()
>   libxc: introduce soft reset for HVM domains
>   libxl: soft reset support
>   xsm: add XEN_DOMCTL_set_recipient support
>
>  tools/libxc/Makefile                |   1 +
>  tools/libxc/xc_domain.c             |  10 +
>  tools/libxc/xc_domain_soft_reset.c  | 394 ++++++++++++++++++++++++++++++++++++
>  tools/libxc/xenctrl.h               |  14 ++
>  tools/libxc/xenguest.h              |  20 ++
>  tools/libxl/libxl.c                 |  32 ++-
>  tools/libxl/libxl.h                 |   6 +
>  tools/libxl/libxl_create.c          | 103 +++++++++-
>  tools/libxl/libxl_internal.h        |   8 +
>  tools/libxl/libxl_types.idl         |   1 +
>  tools/libxl/xl_cmdimpl.c            |  24 ++-
>  tools/python/xen/lowlevel/xl/xl.c   |   1 +
>  xen/common/domain.c                 |   3 +
>  xen/common/domctl.c                 |  35 ++++
>  xen/common/page_alloc.c             |  26 ++-
>  xen/common/shutdown.c               |   7 +
>  xen/include/public/domctl.h         |  19 ++
>  xen/include/public/sched.h          |   3 +-
>  xen/include/xen/sched.h             |   1 +
>  xen/include/xsm/dummy.h             |   6 +
>  xen/include/xsm/xsm.h               |   6 +
>  xen/xsm/dummy.c                     |   1 +
>  xen/xsm/flask/hooks.c               |  17 ++
>  xen/xsm/flask/policy/access_vectors |  10 +
>  24 files changed, 726 insertions(+), 22 deletions(-)
>  create mode 100644 tools/libxc/xc_domain_soft_reset.c

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:32:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHjv-0006eI-6n; Mon, 03 Nov 2014 13:32:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlHjt-0006e6-HW
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 13:32:09 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	71/47-02984-8D387545; Mon, 03 Nov 2014 13:32:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415021525!12239365!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30077 invoked from network); 3 Nov 2014 13:32:06 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:32:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 13:32:05 +0000
Message-Id: <545791E20200007800044717@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 13:32:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com><1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	(Vitaly Kuznetsov's message of "Tue, 7 Oct 2014 15:10:05 +0200")
	<87zjc8a08y.fsf@vitty.brq.redhat.com>
In-Reply-To: <87zjc8a08y.fsf@vitty.brq.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 0/8] toolstack-based approach to pvhvm
 guest kexec
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 14:21, <vkuznets@redhat.com> wrote:
> I don't want to create noise but I didn't get many comments on this RFC
> (the only one belongs to David). In case there are no comments on RFC
> (design) level I can rebase and send first non-RFC.

Afaic, I will likely have time to look at the hypervisor parts of this
only when 4.5 has (at least mostly) settled.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:32:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHjv-0006eI-6n; Mon, 03 Nov 2014 13:32:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlHjt-0006e6-HW
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 13:32:09 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	71/47-02984-8D387545; Mon, 03 Nov 2014 13:32:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415021525!12239365!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30077 invoked from network); 3 Nov 2014 13:32:06 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 13:32:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 13:32:05 +0000
Message-Id: <545791E20200007800044717@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 13:32:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com><1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	(Vitaly Kuznetsov's message of "Tue, 7 Oct 2014 15:10:05 +0200")
	<87zjc8a08y.fsf@vitty.brq.redhat.com>
In-Reply-To: <87zjc8a08y.fsf@vitty.brq.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 0/8] toolstack-based approach to pvhvm
 guest kexec
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 14:21, <vkuznets@redhat.com> wrote:
> I don't want to create noise but I didn't get many comments on this RFC
> (the only one belongs to David). In case there are no comments on RFC
> (design) level I can rebase and send first non-RFC.

Afaic, I will likely have time to look at the hypervisor parts of this
only when 4.5 has (at least mostly) settled.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:39:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHql-000762-Bj; Mon, 03 Nov 2014 13:39:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlHqj-00075x-UQ
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 13:39:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	03/F9-09936-18587545; Mon, 03 Nov 2014 13:39:13 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415021952!12417334!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24053 invoked from network); 3 Nov 2014 13:39:12 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 13:39:12 -0000
Received: by mail-wi0-f169.google.com with SMTP id n3so6072328wiv.4
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 05:39:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=zPNc9KjaW0Qg8ctlqvEjw6Ez2OwUSYwB54LiiNhQyak=;
	b=X/s5qbF6q96RII463zcfTPZL2BGKc739NfmaurJtHFCYUVngv3LwRmsuENFUl41jv5
	iWdueL5pEyfuN/BZ2qj4T06X+94yRiQrrgmlsBHGIEEHx7GogQZDVpqcUgKcMSh1w/Y3
	vV+cCYueRZHEvcB27UmvdNKnp1W3ys46X4eK5TWaLW6e/cXvmyCKrNqOZGHfLhhs8F95
	Kiaww0kYCXpwPt1z2tcPXazjDrjtUzP0vPuQtNWMezZgNKt3+Yys2JNzJx2tyaoFpp4e
	IrAFnMcJw5jIs+/ZUUO2Q3f0zbgTxn5gGAblOoZiks86yBbVykKoE+Ix/XIe49yzWza7
	2kXQ==
X-Gm-Message-State: ALoCoQlG15++qjlEz6nyf7P6jnJ5Ls9R6/wwgRR1hTTOpYgAnA7/2tEB2ivGih5nrGPiHoyaUXWl
X-Received: by 10.194.60.109 with SMTP id g13mr3242990wjr.109.1415021952468;
	Mon, 03 Nov 2014 05:39:12 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id cx9sm6249381wjc.25.2014.11.03.05.39.11
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 05:39:11 -0800 (PST)
Message-ID: <54578578.5050801@linaro.org>
Date: Mon, 03 Nov 2014 13:39:04 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-2-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-2-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 01/10] xen/arm: Implement hip04-d01 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

Hi Frediano,

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
> Add this new platform to Xen.
> This platform require specific code to initialize CPUs.

s/require/requires/

I guess your platform doesn't support PSCI?

> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---

[..]

> diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
> new file mode 100644
> index 0000000..bf38c23
> --- /dev/null
> +++ b/xen/arch/arm/platforms/hip04.c
> @@ -0,0 +1,258 @@

[..]

> +
> +struct hip04_secondary_cpu_data {

coding style:

struct hip04_secondary_cpu_data
{

> +    u32 bootwrapper_phys;
> +    u32 bootwrapper_size;
> +    u32 bootwrapper_magic;
> +    u32 relocation_entry;
> +    u32 relocation_size;
> +};
> +
> +static void __iomem *relocation, *sysctrl, *fabric;
> +static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
> +static struct hip04_secondary_cpu_data hip04_boot;
> +
> +static void hip04_reset(void)
> +{
> +    /* TODO */

Why did you implement the reset in a separate patch rather than here?

> +}
> +
> +static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
> +{
> +    unsigned long data;
> +
> +    if (!fabric)

Coding style:

if ( !fabric )

> +        return;
> +    data = readl_relaxed(fabric + FAB_SF_MODE);
> +    if (on)

if ( on )

> +        data |= 1 << cluster;
> +    else
> +        data &= ~(1 << cluster);
> +    writel_relaxed(data, fabric + FAB_SF_MODE);
> +    while (1) {

while ( 1 )
{

> +        if (data == readl_relaxed(fabric + FAB_SF_MODE))

if ( ... )

> +            break;
> +    }

The loop is turning in an infinite loop if the reading value is never
correct.

> +}
> +
> +static bool __init hip04_cpu_table_init(void)
> +{
> +    unsigned int mpidr, cpu, cluster;
> +
> +    mpidr = cpu_logical_map(smp_processor_id());
> +    cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +    cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +
> +    if (cluster >= HIP04_MAX_CLUSTERS ||
> +        cpu >= HIP04_MAX_CPUS_PER_CLUSTER) {

if ( ...
     ... )
{

> +        printk(XENLOG_ERR "%s: boot CPU is out of bound!\n", __func__);
> +        return false;
> +    }
> +    hip04_set_snoop_filter(cluster, 1);
> +    hip04_cpu_table[cluster][cpu] = 1;

Missing blank line

> +    return true;
> +}
> +
> +static bool hip04_cluster_down(unsigned int cluster)
> +{
> +    int i;
> +
> +    for (i = 0; i < HIP04_MAX_CPUS_PER_CLUSTER; i++)

for ( ... )

> +        if (hip04_cpu_table[cluster][i])

if ( ... )

> +            return false;
> +    return true;
> +}
> +
> +static void hip04_cluster_up(unsigned int cluster)
> +{
> +    unsigned long data, mask;
> +
> +    if ( hip04_cluster_down(cluster) ) {

Wouldn't it be easier to return if the cluster is up? It will one layer
of indentation.

> +        data = CLUSTER_L2_RESET_BIT | CLUSTER_DEBUG_RESET_BIT;
> +        writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
> +        do {
> +            mask = CLUSTER_L2_RESET_STATUS | \
> +                   CLUSTER_DEBUG_RESET_STATUS;
> +            data = readl_relaxed(sysctrl + \
> +                         SC_CPU_RESET_STATUS(cluster));
> +        } while (data & mask);
> +        hip04_set_snoop_filter(cluster, 1);
> +    }
> +}
> +
> +static int __init hip04_smp_init(void)
> +{
> +    struct dt_device_node *np, *np_fab;

The device node are not modified so:

const struct

[..]

> +    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
> +    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
> +    writel_relaxed(__pa(init_secondary), relocation + 8);
> +    writel_relaxed(0, relocation + 12);
> +
> +    return 0;
> +
> +err:

For consistence, you should unmap everything you mapped with ioremap_*

> +    printk("%s", msg);
> +    return -ENXIO;
> +}
> +
> +static int hip04_cpu_up(int cpu)
> +{
> +    unsigned int cluster = cpu / 4;

The number 4 is confusing here, why not using the define you've created
above? Such as  HIP04_MAX_CPUS_PER_CLUSTER

> +    unsigned long data;

The coding style requires a blank line after the declarations block.

> +    cpu %= 4;

Ditto for the number 4.

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:39:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlHql-000762-Bj; Mon, 03 Nov 2014 13:39:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlHqj-00075x-UQ
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 13:39:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	03/F9-09936-18587545; Mon, 03 Nov 2014 13:39:13 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415021952!12417334!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24053 invoked from network); 3 Nov 2014 13:39:12 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 13:39:12 -0000
Received: by mail-wi0-f169.google.com with SMTP id n3so6072328wiv.4
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 05:39:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=zPNc9KjaW0Qg8ctlqvEjw6Ez2OwUSYwB54LiiNhQyak=;
	b=X/s5qbF6q96RII463zcfTPZL2BGKc739NfmaurJtHFCYUVngv3LwRmsuENFUl41jv5
	iWdueL5pEyfuN/BZ2qj4T06X+94yRiQrrgmlsBHGIEEHx7GogQZDVpqcUgKcMSh1w/Y3
	vV+cCYueRZHEvcB27UmvdNKnp1W3ys46X4eK5TWaLW6e/cXvmyCKrNqOZGHfLhhs8F95
	Kiaww0kYCXpwPt1z2tcPXazjDrjtUzP0vPuQtNWMezZgNKt3+Yys2JNzJx2tyaoFpp4e
	IrAFnMcJw5jIs+/ZUUO2Q3f0zbgTxn5gGAblOoZiks86yBbVykKoE+Ix/XIe49yzWza7
	2kXQ==
X-Gm-Message-State: ALoCoQlG15++qjlEz6nyf7P6jnJ5Ls9R6/wwgRR1hTTOpYgAnA7/2tEB2ivGih5nrGPiHoyaUXWl
X-Received: by 10.194.60.109 with SMTP id g13mr3242990wjr.109.1415021952468;
	Mon, 03 Nov 2014 05:39:12 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id cx9sm6249381wjc.25.2014.11.03.05.39.11
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 05:39:11 -0800 (PST)
Message-ID: <54578578.5050801@linaro.org>
Date: Mon, 03 Nov 2014 13:39:04 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-2-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-2-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 01/10] xen/arm: Implement hip04-d01 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

Hi Frediano,

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
> Add this new platform to Xen.
> This platform require specific code to initialize CPUs.

s/require/requires/

I guess your platform doesn't support PSCI?

> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---

[..]

> diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
> new file mode 100644
> index 0000000..bf38c23
> --- /dev/null
> +++ b/xen/arch/arm/platforms/hip04.c
> @@ -0,0 +1,258 @@

[..]

> +
> +struct hip04_secondary_cpu_data {

coding style:

struct hip04_secondary_cpu_data
{

> +    u32 bootwrapper_phys;
> +    u32 bootwrapper_size;
> +    u32 bootwrapper_magic;
> +    u32 relocation_entry;
> +    u32 relocation_size;
> +};
> +
> +static void __iomem *relocation, *sysctrl, *fabric;
> +static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
> +static struct hip04_secondary_cpu_data hip04_boot;
> +
> +static void hip04_reset(void)
> +{
> +    /* TODO */

Why did you implement the reset in a separate patch rather than here?

> +}
> +
> +static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
> +{
> +    unsigned long data;
> +
> +    if (!fabric)

Coding style:

if ( !fabric )

> +        return;
> +    data = readl_relaxed(fabric + FAB_SF_MODE);
> +    if (on)

if ( on )

> +        data |= 1 << cluster;
> +    else
> +        data &= ~(1 << cluster);
> +    writel_relaxed(data, fabric + FAB_SF_MODE);
> +    while (1) {

while ( 1 )
{

> +        if (data == readl_relaxed(fabric + FAB_SF_MODE))

if ( ... )

> +            break;
> +    }

The loop is turning in an infinite loop if the reading value is never
correct.

> +}
> +
> +static bool __init hip04_cpu_table_init(void)
> +{
> +    unsigned int mpidr, cpu, cluster;
> +
> +    mpidr = cpu_logical_map(smp_processor_id());
> +    cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +    cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +
> +    if (cluster >= HIP04_MAX_CLUSTERS ||
> +        cpu >= HIP04_MAX_CPUS_PER_CLUSTER) {

if ( ...
     ... )
{

> +        printk(XENLOG_ERR "%s: boot CPU is out of bound!\n", __func__);
> +        return false;
> +    }
> +    hip04_set_snoop_filter(cluster, 1);
> +    hip04_cpu_table[cluster][cpu] = 1;

Missing blank line

> +    return true;
> +}
> +
> +static bool hip04_cluster_down(unsigned int cluster)
> +{
> +    int i;
> +
> +    for (i = 0; i < HIP04_MAX_CPUS_PER_CLUSTER; i++)

for ( ... )

> +        if (hip04_cpu_table[cluster][i])

if ( ... )

> +            return false;
> +    return true;
> +}
> +
> +static void hip04_cluster_up(unsigned int cluster)
> +{
> +    unsigned long data, mask;
> +
> +    if ( hip04_cluster_down(cluster) ) {

Wouldn't it be easier to return if the cluster is up? It will one layer
of indentation.

> +        data = CLUSTER_L2_RESET_BIT | CLUSTER_DEBUG_RESET_BIT;
> +        writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
> +        do {
> +            mask = CLUSTER_L2_RESET_STATUS | \
> +                   CLUSTER_DEBUG_RESET_STATUS;
> +            data = readl_relaxed(sysctrl + \
> +                         SC_CPU_RESET_STATUS(cluster));
> +        } while (data & mask);
> +        hip04_set_snoop_filter(cluster, 1);
> +    }
> +}
> +
> +static int __init hip04_smp_init(void)
> +{
> +    struct dt_device_node *np, *np_fab;

The device node are not modified so:

const struct

[..]

> +    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
> +    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
> +    writel_relaxed(__pa(init_secondary), relocation + 8);
> +    writel_relaxed(0, relocation + 12);
> +
> +    return 0;
> +
> +err:

For consistence, you should unmap everything you mapped with ioremap_*

> +    printk("%s", msg);
> +    return -ENXIO;
> +}
> +
> +static int hip04_cpu_up(int cpu)
> +{
> +    unsigned int cluster = cpu / 4;

The number 4 is confusing here, why not using the define you've created
above? Such as  HIP04_MAX_CPUS_PER_CLUSTER

> +    unsigned long data;

The coding style requires a blank line after the declarations block.

> +    cpu %= 4;

Ditto for the number 4.

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:40:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHrh-0007AB-Q3; Mon, 03 Nov 2014 13:40:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlHrg-0007A3-FS
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 13:40:12 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	F0/A4-17735-BB587545; Mon, 03 Nov 2014 13:40:11 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415022010!6856845!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19054 invoked from network); 3 Nov 2014 13:40:10 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 13:40:10 -0000
Received: by mail-wg0-f47.google.com with SMTP id a1so11106389wgh.20
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 05:40:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=1TmqYBiEr5BjXoWL4svVChE+jmbl/sEGfT6LrrA/2HM=;
	b=kzOrtxPC69uFIcVjFhn9/Dr4ek2FoBTtltVGpUkz1SctbaX0pAuJ7tPxpn0fh8MK2k
	Y2i0nUQKHLgFl11Z1zWXXKw9H1ep79S7v9gqAnUpiql001XRqQltxZ2qoTIQqbQVhqZm
	9SeVr6ZBZwfuySiFt+lW4G4904jF0lS0uZQDoJp//F6q/uxNHyvTxaLs5TrXLNTx2Ywe
	o/x8XOjVRu5UwaZbuRkBxIG67yp6sD1dhokMsZLYv+Z83dA5PcT8aL47pWM2/etkrpQ7
	3rb7zz2knpk0WGqXt++JhpTqkgYQTE0D349ZBpeMxz3VtsMrhWJNe00XVi2iNZ8l1HzZ
	v1og==
X-Gm-Message-State: ALoCoQnj2ZtPPt+3Gy6gfHC0kaBVJ4l8qEfeoY2R3DeAON8pzSWs3QEVxZXUDIIoYVTqzV/SuUz9
X-Received: by 10.194.203.201 with SMTP id ks9mr3137314wjc.105.1415022010482; 
	Mon, 03 Nov 2014 05:40:10 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	cz3sm22231065wjb.23.2014.11.03.05.40.09 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 05:40:09 -0800 (PST)
Message-ID: <545785B3.2020502@linaro.org>
Date: Mon, 03 Nov 2014 13:40:03 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-3-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-3-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/10] xen/arm: Implement hip04-d01 board
	reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

I would fold this patch in #1.

Regards,

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> ---
>  xen/arch/arm/platforms/hip04.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
> index bf38c23..62d2034 100644
> --- a/xen/arch/arm/platforms/hip04.c
> +++ b/xen/arch/arm/platforms/hip04.c
> @@ -27,6 +27,7 @@
>  #include <xen/vmap.h>
>  #include <asm/io.h>
>  #include <asm/gic.h>
> +#include <xen/delay.h>
>  
>  #define CORE_RESET_BIT(x)            (1 << x)
>  #define NEON_RESET_BIT(x)            (1 << (x + 4))
> @@ -53,13 +54,21 @@ struct hip04_secondary_cpu_data {
>      u32 relocation_size;
>  };
>  
> -static void __iomem *relocation, *sysctrl, *fabric;
> +static void __iomem *relocation, *sysctrl, *fabric, *gb2;
>  static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
>  static struct hip04_secondary_cpu_data hip04_boot;
>  
>  static void hip04_reset(void)
>  {
> -    /* TODO */
> +    unsigned long data;
> +
> +    if ( !gb2 )
> +        return;
> +
> +    data = readl_relaxed(gb2);
> +    writel_relaxed(data & ~0x4000000u, gb2);
> +
> +    mdelay(10);
>  }
>  
>  static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
> @@ -186,6 +195,11 @@ static int __init hip04_smp_init(void)
>      if ( !fabric )
>          goto err;
>  
> +    msg = "Error mapping GB2\n";
> +    gb2 = ioremap_nocache(0xe4002000, 0x1000);
> +    if ( !gb2 )
> +        goto err;
> +
>      msg = "Error initializing SMP table\n";
>      if ( !hip04_cpu_table_init() )
>          goto err;
> 


-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:40:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13: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 1XlHrh-0007AB-Q3; Mon, 03 Nov 2014 13:40:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlHrg-0007A3-FS
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 13:40:12 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	F0/A4-17735-BB587545; Mon, 03 Nov 2014 13:40:11 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415022010!6856845!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19054 invoked from network); 3 Nov 2014 13:40:10 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 13:40:10 -0000
Received: by mail-wg0-f47.google.com with SMTP id a1so11106389wgh.20
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 05:40:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=1TmqYBiEr5BjXoWL4svVChE+jmbl/sEGfT6LrrA/2HM=;
	b=kzOrtxPC69uFIcVjFhn9/Dr4ek2FoBTtltVGpUkz1SctbaX0pAuJ7tPxpn0fh8MK2k
	Y2i0nUQKHLgFl11Z1zWXXKw9H1ep79S7v9gqAnUpiql001XRqQltxZ2qoTIQqbQVhqZm
	9SeVr6ZBZwfuySiFt+lW4G4904jF0lS0uZQDoJp//F6q/uxNHyvTxaLs5TrXLNTx2Ywe
	o/x8XOjVRu5UwaZbuRkBxIG67yp6sD1dhokMsZLYv+Z83dA5PcT8aL47pWM2/etkrpQ7
	3rb7zz2knpk0WGqXt++JhpTqkgYQTE0D349ZBpeMxz3VtsMrhWJNe00XVi2iNZ8l1HzZ
	v1og==
X-Gm-Message-State: ALoCoQnj2ZtPPt+3Gy6gfHC0kaBVJ4l8qEfeoY2R3DeAON8pzSWs3QEVxZXUDIIoYVTqzV/SuUz9
X-Received: by 10.194.203.201 with SMTP id ks9mr3137314wjc.105.1415022010482; 
	Mon, 03 Nov 2014 05:40:10 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	cz3sm22231065wjb.23.2014.11.03.05.40.09 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 05:40:09 -0800 (PST)
Message-ID: <545785B3.2020502@linaro.org>
Date: Mon, 03 Nov 2014 13:40:03 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-3-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-3-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/10] xen/arm: Implement hip04-d01 board
	reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

I would fold this patch in #1.

Regards,

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> ---
>  xen/arch/arm/platforms/hip04.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
> index bf38c23..62d2034 100644
> --- a/xen/arch/arm/platforms/hip04.c
> +++ b/xen/arch/arm/platforms/hip04.c
> @@ -27,6 +27,7 @@
>  #include <xen/vmap.h>
>  #include <asm/io.h>
>  #include <asm/gic.h>
> +#include <xen/delay.h>
>  
>  #define CORE_RESET_BIT(x)            (1 << x)
>  #define NEON_RESET_BIT(x)            (1 << (x + 4))
> @@ -53,13 +54,21 @@ struct hip04_secondary_cpu_data {
>      u32 relocation_size;
>  };
>  
> -static void __iomem *relocation, *sysctrl, *fabric;
> +static void __iomem *relocation, *sysctrl, *fabric, *gb2;
>  static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
>  static struct hip04_secondary_cpu_data hip04_boot;
>  
>  static void hip04_reset(void)
>  {
> -    /* TODO */
> +    unsigned long data;
> +
> +    if ( !gb2 )
> +        return;
> +
> +    data = readl_relaxed(gb2);
> +    writel_relaxed(data & ~0x4000000u, gb2);
> +
> +    mdelay(10);
>  }
>  
>  static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
> @@ -186,6 +195,11 @@ static int __init hip04_smp_init(void)
>      if ( !fabric )
>          goto err;
>  
> +    msg = "Error mapping GB2\n";
> +    gb2 = ioremap_nocache(0xe4002000, 0x1000);
> +    if ( !gb2 )
> +        goto err;
> +
>      msg = "Error initializing SMP table\n";
>      if ( !hip04_cpu_table_init() )
>          goto err;
> 


-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:50:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:50:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlI1W-0007aV-4X; Mon, 03 Nov 2014 13:50:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlI1U-0007aQ-Ux
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 13:50:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1E/EE-09936-C1887545; Mon, 03 Nov 2014 13:50:20 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415022619!12393717!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 524 invoked from network); 3 Nov 2014 13:50:19 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 13:50:19 -0000
Received: by mail-wi0-f181.google.com with SMTP id n3so6443242wiv.14
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 05:50:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=i1N/gnQ/pF3Cf9iGzWUq7US+kRAKKBl317LWWKmOhHA=;
	b=QWEM+lfWvmmGXeP9xn7818FOE7KgK3evqCebD4eXzOMr/SnRu7T8y3pjOdBAM9wEzd
	3L66sZIuJDnBgJT+wEp0/R/VK2VM3XAI1FeSfCPKiBCnJPabzxEArHnZCDctzOIEf9c+
	kC/gn4Mznggcafdz7s6ApFzjhbvS3Z2oK491OQwQ0KkhOmRmvMNjPpcHfnWpztyrTp3+
	bvp272utTwOF2GuEzdE2SsGjQ7SWJZ/eUkIPYylVZuzq1MJ3Vz9h52f4e0H7TFeP6e+u
	qnlvFOsYD+iFeqpMg+IHobhLY7/OnzeLZrKfE3lidmQCmHa2BaC8EXIhq6gsnND0e+Ub
	Na2g==
X-Gm-Message-State: ALoCoQl6+jSizsy2T5mPQeuTB1kbSlovOyU3Runyfy7VpTs2okjXjQUm4HLcnax5HEOwZglW/Vkw
X-Received: by 10.180.90.241 with SMTP id bz17mr3341141wib.75.1415022619638;
	Mon, 03 Nov 2014 05:50:19 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id x3sm1825812wiy.4.2014.11.03.05.50.18
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 05:50:18 -0800 (PST)
Message-ID: <54578814.3060605@linaro.org>
Date: Mon, 03 Nov 2014 13:50:12 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-4-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-4-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/10] xen/arm: Define quirk for Hip04 GICv2
	divergence
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

This could be fold in #4.

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
> From: Zoltan Kiss <zoltan.kiss@huawei.com>
> 
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/arch/arm/platforms/hip04.c | 6 ++++++
>  xen/include/asm-arm/platform.h | 5 +++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
> index 62d2034..024c8a0 100644
> --- a/xen/arch/arm/platforms/hip04.c
> +++ b/xen/arch/arm/platforms/hip04.c
> @@ -253,12 +253,18 @@ static const struct dt_device_match hip04_blacklist_dev[] __initconst =
>      { /* sentinel */ },
>  };
>  
> +static uint32_t hip04_quirks(void)
> +{
> +    return PLATFORM_QUIRK_GICV2_16_CPU;
> +}
> +
>  
>  PLATFORM_START(hip04, "HISILICON HIP04")
>      .compatible = hip04_dt_compat,
>      .smp_init = hip04_smp_init,
>      .cpu_up = hip04_cpu_up,
>      .reset = hip04_reset,
> +    .quirks = hip04_quirks,
>      .blacklist_dev = hip04_blacklist_dev,
>  PLATFORM_END
>  
> diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
> index eefaca6..537fba5 100644
> --- a/xen/include/asm-arm/platform.h
> +++ b/xen/include/asm-arm/platform.h
> @@ -60,6 +60,11 @@ struct platform_desc {
>   */
>  #define PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI       (1 << 1)
>  
> +/*
> + * Quirk for platforms where GICv2 has to handle 16 CPUs
> + */
> +#define PLATFORM_QUIRK_GICV2_16_CPU       (1 << 2)
> +

Actually you use the quirk to do hisilicon specific (mostly in patch
#6). I would rename the quirk to show it's platform specific, something
like:

PLATFORM_QUIRK_HISILICON_GICV2 or PLATFROM_QUIRK_HISILICON_GICV2_16_CPU.

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:50:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:50:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlI1W-0007aV-4X; Mon, 03 Nov 2014 13:50:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlI1U-0007aQ-Ux
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 13:50:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1E/EE-09936-C1887545; Mon, 03 Nov 2014 13:50:20 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415022619!12393717!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 524 invoked from network); 3 Nov 2014 13:50:19 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 13:50:19 -0000
Received: by mail-wi0-f181.google.com with SMTP id n3so6443242wiv.14
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 05:50:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=i1N/gnQ/pF3Cf9iGzWUq7US+kRAKKBl317LWWKmOhHA=;
	b=QWEM+lfWvmmGXeP9xn7818FOE7KgK3evqCebD4eXzOMr/SnRu7T8y3pjOdBAM9wEzd
	3L66sZIuJDnBgJT+wEp0/R/VK2VM3XAI1FeSfCPKiBCnJPabzxEArHnZCDctzOIEf9c+
	kC/gn4Mznggcafdz7s6ApFzjhbvS3Z2oK491OQwQ0KkhOmRmvMNjPpcHfnWpztyrTp3+
	bvp272utTwOF2GuEzdE2SsGjQ7SWJZ/eUkIPYylVZuzq1MJ3Vz9h52f4e0H7TFeP6e+u
	qnlvFOsYD+iFeqpMg+IHobhLY7/OnzeLZrKfE3lidmQCmHa2BaC8EXIhq6gsnND0e+Ub
	Na2g==
X-Gm-Message-State: ALoCoQl6+jSizsy2T5mPQeuTB1kbSlovOyU3Runyfy7VpTs2okjXjQUm4HLcnax5HEOwZglW/Vkw
X-Received: by 10.180.90.241 with SMTP id bz17mr3341141wib.75.1415022619638;
	Mon, 03 Nov 2014 05:50:19 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id x3sm1825812wiy.4.2014.11.03.05.50.18
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 05:50:18 -0800 (PST)
Message-ID: <54578814.3060605@linaro.org>
Date: Mon, 03 Nov 2014 13:50:12 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-4-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-4-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/10] xen/arm: Define quirk for Hip04 GICv2
	divergence
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

This could be fold in #4.

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
> From: Zoltan Kiss <zoltan.kiss@huawei.com>
> 
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/arch/arm/platforms/hip04.c | 6 ++++++
>  xen/include/asm-arm/platform.h | 5 +++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
> index 62d2034..024c8a0 100644
> --- a/xen/arch/arm/platforms/hip04.c
> +++ b/xen/arch/arm/platforms/hip04.c
> @@ -253,12 +253,18 @@ static const struct dt_device_match hip04_blacklist_dev[] __initconst =
>      { /* sentinel */ },
>  };
>  
> +static uint32_t hip04_quirks(void)
> +{
> +    return PLATFORM_QUIRK_GICV2_16_CPU;
> +}
> +
>  
>  PLATFORM_START(hip04, "HISILICON HIP04")
>      .compatible = hip04_dt_compat,
>      .smp_init = hip04_smp_init,
>      .cpu_up = hip04_cpu_up,
>      .reset = hip04_reset,
> +    .quirks = hip04_quirks,
>      .blacklist_dev = hip04_blacklist_dev,
>  PLATFORM_END
>  
> diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
> index eefaca6..537fba5 100644
> --- a/xen/include/asm-arm/platform.h
> +++ b/xen/include/asm-arm/platform.h
> @@ -60,6 +60,11 @@ struct platform_desc {
>   */
>  #define PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI       (1 << 1)
>  
> +/*
> + * Quirk for platforms where GICv2 has to handle 16 CPUs
> + */
> +#define PLATFORM_QUIRK_GICV2_16_CPU       (1 << 2)
> +

Actually you use the quirk to do hisilicon specific (mostly in patch
#6). I would rename the quirk to show it's platform specific, something
like:

PLATFORM_QUIRK_HISILICON_GICV2 or PLATFROM_QUIRK_HISILICON_GICV2_16_CPU.

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:55:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlI5x-0007lX-TS; Mon, 03 Nov 2014 13:54:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlI5x-0007lR-1S
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 13:54:57 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	7E/32-11608-03987545; Mon, 03 Nov 2014 13:54:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415022894!7569874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11485 invoked from network); 3 Nov 2014 13:54:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 13:54:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188888620"
Message-ID: <1415022891.24785.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Mon, 3 Nov 2014 13:54:51 +0000
In-Reply-To: <54578814.3060605@linaro.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-4-git-send-email-frediano.ziglio@huawei.com>
	<54578814.3060605@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Frediano Ziglio <frediano.ziglio@huawei.com>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/10] xen/arm: Define quirk for Hip04 GICv2
	divergence
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 13:50 +0000, Julien Grall wrote:
> Actually you use the quirk to do hisilicon specific (mostly in patch
> #6). I would rename the quirk to show it's platform specific, something
> like:
> 
> PLATFORM_QUIRK_HISILICON_GICV2 or PLATFROM_QUIRK_HISILICON_GICV2_16_CPU.

I think this should be keyed of the DT compatible string, since there is
one, it's not really a quirk, it's essentially implementing a different
hardware spec.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 13:55:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 13:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlI5x-0007lX-TS; Mon, 03 Nov 2014 13:54:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlI5x-0007lR-1S
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 13:54:57 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	7E/32-11608-03987545; Mon, 03 Nov 2014 13:54:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415022894!7569874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11485 invoked from network); 3 Nov 2014 13:54:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 13:54:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188888620"
Message-ID: <1415022891.24785.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Mon, 3 Nov 2014 13:54:51 +0000
In-Reply-To: <54578814.3060605@linaro.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-4-git-send-email-frediano.ziglio@huawei.com>
	<54578814.3060605@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Frediano Ziglio <frediano.ziglio@huawei.com>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/10] xen/arm: Define quirk for Hip04 GICv2
	divergence
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 13:50 +0000, Julien Grall wrote:
> Actually you use the quirk to do hisilicon specific (mostly in patch
> #6). I would rename the quirk to show it's platform specific, something
> like:
> 
> PLATFORM_QUIRK_HISILICON_GICV2 or PLATFROM_QUIRK_HISILICON_GICV2_16_CPU.

I think this should be keyed of the DT compatible string, since there is
one, it's not really a quirk, it's essentially implementing a different
hardware spec.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:10:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:10:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIKu-0008P4-0m; Mon, 03 Nov 2014 14:10:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIKt-0008Oz-Fe
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:10:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	86/B8-09842-ECC87545; Mon, 03 Nov 2014 14:10:22 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415023820!12432039!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 327 invoked from network); 3 Nov 2014 14:10:20 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:10:20 -0000
Received: by mail-wi0-f182.google.com with SMTP id d1so6487613wiv.9
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:10:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=b9neo3OEwBvBj6uxwA0a2SlZTLZJLxug1ERI+C5ybnM=;
	b=fNKKy3KDYWJ+xLxql2tubEOcxi/yKaz/esCyY+DrXKSUKY9dLYaOd37JpZFtNYNYz4
	X0NFFvg8cGyiKXwN/uzz8UVVG3Jn2jAM8ESlY8UOasBdjnpxL/pybYy+efrf9Pg4vmPk
	7Qz1B91UL70v5hr/QyHlMoBPZKeeco2wGr7ujfhkZo9OVXSFf6zuOQD47vYXKbBAXyFN
	ckIUTD5GJc5+TbqwjLE3nltbqufZPAdFhP9/SvFDipxtRgFKmDdddAPAoO9YNcWoCe5b
	7y4VLTgKtiAH2TANX8nL/9QvwK/DIlQIUQSKetG7Ci1ip/cO0LEeDbxDTOnJUsMuB30u
	4Z7Q==
X-Gm-Message-State: ALoCoQkPMgzcTzpo2BwABA7NUGeio+79Ue6sQHGkkDSbtftoVKqshdJou7XjTOKPiq7V3yLoLmoL
X-Received: by 10.180.103.233 with SMTP id fz9mr16154432wib.80.1415023820000; 
	Mon, 03 Nov 2014 06:10:20 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id h8sm22296907wjs.43.2014.11.03.06.10.18
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:10:19 -0800 (PST)
Message-ID: <54578CC4.1030102@linaro.org>
Date: Mon, 03 Nov 2014 14:10:12 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-5-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-5-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 04/10] xen/arm: Make gic-v2 code handle
	hip04-d01 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

Hi Frediano,

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
>  /*
>   * needs to be called with a valid cpu_mask, ie each cpu in the mask has
>   * already called gic_cpu_init
> @@ -230,7 +245,7 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
>      writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
>  
>      /* Set target CPU mask (RAZ/WI on uniprocessor) */
> -    writeb_gicd(mask, GICD_ITARGETSR + irq);
> +    gicv2_set_irq_mask(irq, mask);
>      /* Set priority */
>      writeb_gicd(priority, GICD_IPRIORITYR + irq);
>  
> @@ -244,16 +259,22 @@ static void __init gicv2_dist_init(void)
>      uint32_t gic_cpus;
>      int i;
>  
> -    cpumask = readl_gicd(GICD_ITARGETSR) & 0xff;
> -    cpumask |= cpumask << 8;
> -    cpumask |= cpumask << 16;
> +    cpumask = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
>  
>      /* Disable the distributor */
>      writel_gicd(0, GICD_CTLR);
>  
>      type = readl_gicd(GICD_TYPER);
>      gicv2_info.nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
> -    gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
> +    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
> +    {
> +        gic_cpus = 16;
> +        BUG_ON( gicv2_info.nr_lines > 510 );

Could you add a define for this value and add a comment. It would avoid
to scratch his head trying to understand why 510.

[..]

> +static inline unsigned gicd_sgi_target_shift(void)
> +{
> +    return 8 + 16 - nr_gic_cpu_if;
> +}
> +
>  static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
>                             const cpumask_t *cpu_mask)
>  {
> @@ -366,7 +403,7 @@ static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
>          cpumask_and(&online_mask, cpu_mask, &cpu_online_map);
>          mask = gicv2_cpu_mask(&online_mask);
>          writel_gicd(GICD_SGI_TARGET_LIST |
> -                    (mask << GICD_SGI_TARGET_SHIFT) | sgi,
> +                    (mask << gicd_sgi_target_shift()) | sgi,

gicv2_send_SGI is heavily used, it's not acceptable to compute the value
of the shift every time. Hence this always give you the same value. You
should define a static and initialize it during the initialization.

> @@ -690,6 +727,12 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
>  
>      dt_device_set_used_by(node, DOMID_XEN);
>  
> +    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
> +    {
> +        nr_gic_cpu_if = 16;
> +        gic_cpu_mask = 0xffff;
> +    }
> +
>      res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
>      if ( res || !gicv2.dbase || (gicv2.dbase & ~PAGE_MASK) )
>          panic("GICv2: Cannot find a valid address for the distributor");
> @@ -769,6 +812,7 @@ static const char * const gicv2_dt_compat[] __initconst =
>      DT_COMPAT_GIC_CORTEX_A15,
>      DT_COMPAT_GIC_CORTEX_A7,
>      DT_COMPAT_GIC_400,
> +    DT_COMPAT_GIC_HIP04,
>      NULL
>  };
>  
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..cd934cf 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -563,12 +563,15 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>  void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>  {
>      unsigned int irq;
> +    unsigned int max_irq = platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) ?
> +                           510 :

Ditto for the 510.

> +                           1021;

gic_interrupt is called thousand time per second, anything that never
changes should define only once during initialization.

Rather than using hardcoding the max number, I would use
gicv2_info.nr_lines which contains the maximum number of IRQ used by
this GIC. Any value above this value is already an error.

That would require either a separate patch or adding a comment in the
commit message.

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:10:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:10:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIKu-0008P4-0m; Mon, 03 Nov 2014 14:10:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIKt-0008Oz-Fe
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:10:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	86/B8-09842-ECC87545; Mon, 03 Nov 2014 14:10:22 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415023820!12432039!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 327 invoked from network); 3 Nov 2014 14:10:20 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:10:20 -0000
Received: by mail-wi0-f182.google.com with SMTP id d1so6487613wiv.9
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:10:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=b9neo3OEwBvBj6uxwA0a2SlZTLZJLxug1ERI+C5ybnM=;
	b=fNKKy3KDYWJ+xLxql2tubEOcxi/yKaz/esCyY+DrXKSUKY9dLYaOd37JpZFtNYNYz4
	X0NFFvg8cGyiKXwN/uzz8UVVG3Jn2jAM8ESlY8UOasBdjnpxL/pybYy+efrf9Pg4vmPk
	7Qz1B91UL70v5hr/QyHlMoBPZKeeco2wGr7ujfhkZo9OVXSFf6zuOQD47vYXKbBAXyFN
	ckIUTD5GJc5+TbqwjLE3nltbqufZPAdFhP9/SvFDipxtRgFKmDdddAPAoO9YNcWoCe5b
	7y4VLTgKtiAH2TANX8nL/9QvwK/DIlQIUQSKetG7Ci1ip/cO0LEeDbxDTOnJUsMuB30u
	4Z7Q==
X-Gm-Message-State: ALoCoQkPMgzcTzpo2BwABA7NUGeio+79Ue6sQHGkkDSbtftoVKqshdJou7XjTOKPiq7V3yLoLmoL
X-Received: by 10.180.103.233 with SMTP id fz9mr16154432wib.80.1415023820000; 
	Mon, 03 Nov 2014 06:10:20 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id h8sm22296907wjs.43.2014.11.03.06.10.18
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:10:19 -0800 (PST)
Message-ID: <54578CC4.1030102@linaro.org>
Date: Mon, 03 Nov 2014 14:10:12 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-5-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-5-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 04/10] xen/arm: Make gic-v2 code handle
	hip04-d01 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

Hi Frediano,

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
>  /*
>   * needs to be called with a valid cpu_mask, ie each cpu in the mask has
>   * already called gic_cpu_init
> @@ -230,7 +245,7 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
>      writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
>  
>      /* Set target CPU mask (RAZ/WI on uniprocessor) */
> -    writeb_gicd(mask, GICD_ITARGETSR + irq);
> +    gicv2_set_irq_mask(irq, mask);
>      /* Set priority */
>      writeb_gicd(priority, GICD_IPRIORITYR + irq);
>  
> @@ -244,16 +259,22 @@ static void __init gicv2_dist_init(void)
>      uint32_t gic_cpus;
>      int i;
>  
> -    cpumask = readl_gicd(GICD_ITARGETSR) & 0xff;
> -    cpumask |= cpumask << 8;
> -    cpumask |= cpumask << 16;
> +    cpumask = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
>  
>      /* Disable the distributor */
>      writel_gicd(0, GICD_CTLR);
>  
>      type = readl_gicd(GICD_TYPER);
>      gicv2_info.nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
> -    gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
> +    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
> +    {
> +        gic_cpus = 16;
> +        BUG_ON( gicv2_info.nr_lines > 510 );

Could you add a define for this value and add a comment. It would avoid
to scratch his head trying to understand why 510.

[..]

> +static inline unsigned gicd_sgi_target_shift(void)
> +{
> +    return 8 + 16 - nr_gic_cpu_if;
> +}
> +
>  static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
>                             const cpumask_t *cpu_mask)
>  {
> @@ -366,7 +403,7 @@ static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
>          cpumask_and(&online_mask, cpu_mask, &cpu_online_map);
>          mask = gicv2_cpu_mask(&online_mask);
>          writel_gicd(GICD_SGI_TARGET_LIST |
> -                    (mask << GICD_SGI_TARGET_SHIFT) | sgi,
> +                    (mask << gicd_sgi_target_shift()) | sgi,

gicv2_send_SGI is heavily used, it's not acceptable to compute the value
of the shift every time. Hence this always give you the same value. You
should define a static and initialize it during the initialization.

> @@ -690,6 +727,12 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
>  
>      dt_device_set_used_by(node, DOMID_XEN);
>  
> +    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
> +    {
> +        nr_gic_cpu_if = 16;
> +        gic_cpu_mask = 0xffff;
> +    }
> +
>      res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
>      if ( res || !gicv2.dbase || (gicv2.dbase & ~PAGE_MASK) )
>          panic("GICv2: Cannot find a valid address for the distributor");
> @@ -769,6 +812,7 @@ static const char * const gicv2_dt_compat[] __initconst =
>      DT_COMPAT_GIC_CORTEX_A15,
>      DT_COMPAT_GIC_CORTEX_A7,
>      DT_COMPAT_GIC_400,
> +    DT_COMPAT_GIC_HIP04,
>      NULL
>  };
>  
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..cd934cf 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -563,12 +563,15 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>  void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>  {
>      unsigned int irq;
> +    unsigned int max_irq = platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) ?
> +                           510 :

Ditto for the 510.

> +                           1021;

gic_interrupt is called thousand time per second, anything that never
changes should define only once during initialization.

Rather than using hardcoding the max number, I would use
gicv2_info.nr_lines which contains the maximum number of IRQ used by
this GIC. Any value above this value is already an error.

That would require either a separate patch or adding a comment in the
commit message.

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:12:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:12:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIMj-0008WI-IW; Mon, 03 Nov 2014 14:12:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIMi-0008Vq-3j
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:12:16 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F4/00-01660-F3D87545; Mon, 03 Nov 2014 14:12:15 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415023934!10873937!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8132 invoked from network); 3 Nov 2014 14:12:15 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:12:15 -0000
Received: by mail-wi0-f182.google.com with SMTP id d1so6505607wiv.3
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:12:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=jF7yNB4Ld4Ecjd0TO5xeEV4SASYV9oDVSA/Qip6L+c4=;
	b=EN3KA1XYlzYC+C0qIIm/SoxycpbjUu+4u9iQhWTm+4MxWU6nIRn2gvs1KpdVNeM/y9
	L/1svjwe0rPDYXw25WdYfdmV9fW9fLVXULfMDGHw3vLVEPOLAYTCuib6tt3UJHPruUZo
	Onl8q5TCtEB40RKgZzEgXVy7A3LQNaozU0pEztY/+oM3laGg8MXMD1b/xVQaQDiOJbLB
	rsmnxi3JsBTqBJcltjH4wDXcEDwaxksytoY1oLhxFyt2+oFeCh6d8ul+N5DrTuyOTyXE
	54R1Qn8BefF0xT9ZiaaQT3obKwIAbhbQqlAlo0rk9WQRDcNIF3JXmDlppIdJVH7jxyJ/
	Rhmw==
X-Gm-Message-State: ALoCoQkmRV4I8uiHjErEZuNP/TwUL50UBaAEW3PPEMRfWjsP4Acq+yuDluKhxiaPGvfI8a025hW1
X-Received: by 10.180.91.104 with SMTP id cd8mr2460442wib.46.1415023934663;
	Mon, 03 Nov 2014 06:12:14 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id j8sm8866620wib.10.2014.11.03.06.12.13
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:12:14 -0800 (PST)
Message-ID: <54578D37.3090806@linaro.org>
Date: Mon, 03 Nov 2014 14:12:07 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-7-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-7-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 06/10] xen/arm: handle GICH register changes
 for hip04-d01 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

Hi Frediano,

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
>  static void gicv2_irq_enable(struct irq_desc *desc)
> @@ -731,6 +733,8 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
>      {
>          nr_gic_cpu_if = 16;
>          gic_cpu_mask = 0xffff;
> +        gich_apr = HIP04_GICH_APR;
> +        gich_lr = HIP04_GICH_LR;
>      }
>  
>      res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 3d2b3db..804bf24 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -88,6 +88,8 @@
>  #define GICH_ELSR1      (0x34)
>  #define GICH_APR        (0xF0)
>  #define GICH_LR         (0x100)
> +#define HIP04_GICH_APR  (0x70)
> +#define HIP04_GICH_LR   (0x80)

Please move thoses define in gic-v2.c. The header gic.h should only
contains value that needs to be shared with the vgic and/or the other
GIC drivers.

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:12:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:12:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIMj-0008WI-IW; Mon, 03 Nov 2014 14:12:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIMi-0008Vq-3j
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:12:16 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F4/00-01660-F3D87545; Mon, 03 Nov 2014 14:12:15 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415023934!10873937!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8132 invoked from network); 3 Nov 2014 14:12:15 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:12:15 -0000
Received: by mail-wi0-f182.google.com with SMTP id d1so6505607wiv.3
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:12:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=jF7yNB4Ld4Ecjd0TO5xeEV4SASYV9oDVSA/Qip6L+c4=;
	b=EN3KA1XYlzYC+C0qIIm/SoxycpbjUu+4u9iQhWTm+4MxWU6nIRn2gvs1KpdVNeM/y9
	L/1svjwe0rPDYXw25WdYfdmV9fW9fLVXULfMDGHw3vLVEPOLAYTCuib6tt3UJHPruUZo
	Onl8q5TCtEB40RKgZzEgXVy7A3LQNaozU0pEztY/+oM3laGg8MXMD1b/xVQaQDiOJbLB
	rsmnxi3JsBTqBJcltjH4wDXcEDwaxksytoY1oLhxFyt2+oFeCh6d8ul+N5DrTuyOTyXE
	54R1Qn8BefF0xT9ZiaaQT3obKwIAbhbQqlAlo0rk9WQRDcNIF3JXmDlppIdJVH7jxyJ/
	Rhmw==
X-Gm-Message-State: ALoCoQkmRV4I8uiHjErEZuNP/TwUL50UBaAEW3PPEMRfWjsP4Acq+yuDluKhxiaPGvfI8a025hW1
X-Received: by 10.180.91.104 with SMTP id cd8mr2460442wib.46.1415023934663;
	Mon, 03 Nov 2014 06:12:14 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id j8sm8866620wib.10.2014.11.03.06.12.13
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:12:14 -0800 (PST)
Message-ID: <54578D37.3090806@linaro.org>
Date: Mon, 03 Nov 2014 14:12:07 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-7-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-7-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 06/10] xen/arm: handle GICH register changes
 for hip04-d01 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

Hi Frediano,

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
>  static void gicv2_irq_enable(struct irq_desc *desc)
> @@ -731,6 +733,8 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
>      {
>          nr_gic_cpu_if = 16;
>          gic_cpu_mask = 0xffff;
> +        gich_apr = HIP04_GICH_APR;
> +        gich_lr = HIP04_GICH_LR;
>      }
>  
>      res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 3d2b3db..804bf24 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -88,6 +88,8 @@
>  #define GICH_ELSR1      (0x34)
>  #define GICH_APR        (0xF0)
>  #define GICH_LR         (0x100)
> +#define HIP04_GICH_APR  (0x70)
> +#define HIP04_GICH_LR   (0x80)

Please move thoses define in gic-v2.c. The header gic.h should only
contains value that needs to be shared with the vgic and/or the other
GIC drivers.

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:14:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14: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 1XlIOY-0000Jv-3J; Mon, 03 Nov 2014 14:14:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIOW-0000JM-Fz
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:14:08 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	52/19-02559-FAD87545; Mon, 03 Nov 2014 14:14:07 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415024046!7600589!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20152 invoked from network); 3 Nov 2014 14:14:07 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:14:07 -0000
Received: by mail-wg0-f51.google.com with SMTP id l18so11083510wgh.38
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:14:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=+HG/jn3vrV8iAUtSWTzqoYtiK2yWRNQvoWN9elOh6+A=;
	b=eAU8Op6jo30BQJeH+fY62WsagxjJG1OOIu9JlaL9Ik7OWdrbDslHlP5TIbcfsf4sXq
	J+t9agYCpiIXqeUl9qkZkQCWg2EYVn5++tWksmENjqwF62yTME9RuIpqjzz3CZXoXzJ5
	6GMZBpe2yQcLD6uN0ixg5tElZo6kPX5TXL5kAppur9OpDwLBrkM2OIfCAKc/tmlDmPvY
	WxN38XXanOszQQ9Q+/uzzbyCt1/1hCMX+6BYYG9vCufS1A6JoCpy5g6XgJksrf8hVQpT
	DtMKe10KFogduVALH2AvlcS70c+Rao83RS2TJs1w3rKEK6d/ptDkO+AE2DAGq2MCg8rh
	8ksw==
X-Gm-Message-State: ALoCoQl/yGdzV65u/YKtE/JJ0jgDM8BMIYGjiGOiXQ1zI6vJKINw4Nxu3JpOqHVO4suhemdh7sp8
X-Received: by 10.180.182.195 with SMTP id eg3mr16771592wic.31.1415024046823; 
	Mon, 03 Nov 2014 06:14:06 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id dw9sm8894728wib.0.2014.11.03.06.14.05
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:14:06 -0800 (PST)
Message-ID: <54578DA7.9080505@linaro.org>
Date: Mon, 03 Nov 2014 14:13:59 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
 locations for Hip04 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

Hi Frediano,

This could be merged in #1.

Regards,

On 11/03/2014 10:12 AM, Frediano Ziglio wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> 
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/arch/arm/platforms/hip04.c | 63 ++++++++++++++++++++++++++----------------
>  1 file changed, 39 insertions(+), 24 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
> index 024c8a0..dec4984 100644
> --- a/xen/arch/arm/platforms/hip04.c
> +++ b/xen/arch/arm/platforms/hip04.c
> @@ -136,7 +136,7 @@ static void hip04_cluster_up(unsigned int cluster)
>  
>  static int __init hip04_smp_init(void)
>  {
> -    struct dt_device_node *np, *np_fab;
> +    struct dt_device_node *np, *np_fab, *bw;
>      const char *msg;
>      u64 addr, size;
>  
> @@ -150,30 +150,45 @@ static int __init hip04_smp_init(void)
>      if ( !np_fab )
>          goto err;
>  
> -    msg = "failed to get bootwrapper-phys\n";
>      if ( !dt_property_read_u32(np, "bootwrapper-phys",
> -                               &hip04_boot.bootwrapper_phys) )
> -        goto err;
> -
> -    msg = "failed to get bootwrapper-size\n";
> -    if ( !dt_property_read_u32(np, "bootwrapper-size",
> -                               &hip04_boot.bootwrapper_size) )
> -        goto err;
> -
> -    msg = "failed to get bootwrapper-magic\n";
> -    if ( !dt_property_read_u32(np, "bootwrapper-magic",
> -                               &hip04_boot.bootwrapper_magic) )
> -        goto err;
> -
> -    msg = "failed to get relocation-entry\n";
> -    if ( !dt_property_read_u32(np, "relocation-entry",
> -                               &hip04_boot.relocation_entry) )
> -        goto err;
> -
> -    msg = "failed to get relocation-size\n";
> -    if ( !dt_property_read_u32(np, "relocation-size",
> -                 &hip04_boot.relocation_size) )
> -        goto err;
> +                               &hip04_boot.bootwrapper_phys) ) {
> +        u32 boot_method[4];
> +        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-bootwrapper");
> +        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
> +        if ( !bw )
> +            goto err;
> +
> +        msg = "failed to get boot-method\n";
> +        if ( !dt_property_read_u32_array(bw, "boot-method", boot_method, 4) )
> +            goto err;
> +        hip04_boot.bootwrapper_phys = boot_method[0];
> +        hip04_boot.bootwrapper_size = boot_method[1];
> +        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
> +        hip04_boot.relocation_entry = boot_method[2];
> +        hip04_boot.relocation_size = boot_method[3];
> +    }
> +    else
> +    {
> +        msg = "failed to get bootwrapper-size\n";
> +        if ( !dt_property_read_u32(np, "bootwrapper-size",
> +                                   &hip04_boot.bootwrapper_size) )
> +            goto err;
> +
> +        msg = "failed to get bootwrapper-magic\n";
> +        if ( !dt_property_read_u32(np, "bootwrapper-magic",
> +                                   &hip04_boot.bootwrapper_magic) )
> +            goto err;
> +
> +        msg = "failed to get relocation-entry\n";
> +        if ( !dt_property_read_u32(np, "relocation-entry",
> +                                   &hip04_boot.relocation_entry) )
> +            goto err;
> +
> +        msg = "failed to get relocation-size\n";
> +        if ( !dt_property_read_u32(np, "relocation-size",
> +                                   &hip04_boot.relocation_size) )
> +            goto err;
> +    }
>  
>      relocation = ioremap_nocache(hip04_boot.relocation_entry,
>                                   hip04_boot.relocation_size);
> 


-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:14:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14: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 1XlIOY-0000Jv-3J; Mon, 03 Nov 2014 14:14:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIOW-0000JM-Fz
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:14:08 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	52/19-02559-FAD87545; Mon, 03 Nov 2014 14:14:07 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415024046!7600589!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20152 invoked from network); 3 Nov 2014 14:14:07 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:14:07 -0000
Received: by mail-wg0-f51.google.com with SMTP id l18so11083510wgh.38
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:14:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=+HG/jn3vrV8iAUtSWTzqoYtiK2yWRNQvoWN9elOh6+A=;
	b=eAU8Op6jo30BQJeH+fY62WsagxjJG1OOIu9JlaL9Ik7OWdrbDslHlP5TIbcfsf4sXq
	J+t9agYCpiIXqeUl9qkZkQCWg2EYVn5++tWksmENjqwF62yTME9RuIpqjzz3CZXoXzJ5
	6GMZBpe2yQcLD6uN0ixg5tElZo6kPX5TXL5kAppur9OpDwLBrkM2OIfCAKc/tmlDmPvY
	WxN38XXanOszQQ9Q+/uzzbyCt1/1hCMX+6BYYG9vCufS1A6JoCpy5g6XgJksrf8hVQpT
	DtMKe10KFogduVALH2AvlcS70c+Rao83RS2TJs1w3rKEK6d/ptDkO+AE2DAGq2MCg8rh
	8ksw==
X-Gm-Message-State: ALoCoQl/yGdzV65u/YKtE/JJ0jgDM8BMIYGjiGOiXQ1zI6vJKINw4Nxu3JpOqHVO4suhemdh7sp8
X-Received: by 10.180.182.195 with SMTP id eg3mr16771592wic.31.1415024046823; 
	Mon, 03 Nov 2014 06:14:06 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id dw9sm8894728wib.0.2014.11.03.06.14.05
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:14:06 -0800 (PST)
Message-ID: <54578DA7.9080505@linaro.org>
Date: Mon, 03 Nov 2014 14:13:59 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
 locations for Hip04 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

Hi Frediano,

This could be merged in #1.

Regards,

On 11/03/2014 10:12 AM, Frediano Ziglio wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> 
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/arch/arm/platforms/hip04.c | 63 ++++++++++++++++++++++++++----------------
>  1 file changed, 39 insertions(+), 24 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
> index 024c8a0..dec4984 100644
> --- a/xen/arch/arm/platforms/hip04.c
> +++ b/xen/arch/arm/platforms/hip04.c
> @@ -136,7 +136,7 @@ static void hip04_cluster_up(unsigned int cluster)
>  
>  static int __init hip04_smp_init(void)
>  {
> -    struct dt_device_node *np, *np_fab;
> +    struct dt_device_node *np, *np_fab, *bw;
>      const char *msg;
>      u64 addr, size;
>  
> @@ -150,30 +150,45 @@ static int __init hip04_smp_init(void)
>      if ( !np_fab )
>          goto err;
>  
> -    msg = "failed to get bootwrapper-phys\n";
>      if ( !dt_property_read_u32(np, "bootwrapper-phys",
> -                               &hip04_boot.bootwrapper_phys) )
> -        goto err;
> -
> -    msg = "failed to get bootwrapper-size\n";
> -    if ( !dt_property_read_u32(np, "bootwrapper-size",
> -                               &hip04_boot.bootwrapper_size) )
> -        goto err;
> -
> -    msg = "failed to get bootwrapper-magic\n";
> -    if ( !dt_property_read_u32(np, "bootwrapper-magic",
> -                               &hip04_boot.bootwrapper_magic) )
> -        goto err;
> -
> -    msg = "failed to get relocation-entry\n";
> -    if ( !dt_property_read_u32(np, "relocation-entry",
> -                               &hip04_boot.relocation_entry) )
> -        goto err;
> -
> -    msg = "failed to get relocation-size\n";
> -    if ( !dt_property_read_u32(np, "relocation-size",
> -                 &hip04_boot.relocation_size) )
> -        goto err;
> +                               &hip04_boot.bootwrapper_phys) ) {
> +        u32 boot_method[4];
> +        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-bootwrapper");
> +        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
> +        if ( !bw )
> +            goto err;
> +
> +        msg = "failed to get boot-method\n";
> +        if ( !dt_property_read_u32_array(bw, "boot-method", boot_method, 4) )
> +            goto err;
> +        hip04_boot.bootwrapper_phys = boot_method[0];
> +        hip04_boot.bootwrapper_size = boot_method[1];
> +        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
> +        hip04_boot.relocation_entry = boot_method[2];
> +        hip04_boot.relocation_size = boot_method[3];
> +    }
> +    else
> +    {
> +        msg = "failed to get bootwrapper-size\n";
> +        if ( !dt_property_read_u32(np, "bootwrapper-size",
> +                                   &hip04_boot.bootwrapper_size) )
> +            goto err;
> +
> +        msg = "failed to get bootwrapper-magic\n";
> +        if ( !dt_property_read_u32(np, "bootwrapper-magic",
> +                                   &hip04_boot.bootwrapper_magic) )
> +            goto err;
> +
> +        msg = "failed to get relocation-entry\n";
> +        if ( !dt_property_read_u32(np, "relocation-entry",
> +                                   &hip04_boot.relocation_entry) )
> +            goto err;
> +
> +        msg = "failed to get relocation-size\n";
> +        if ( !dt_property_read_u32(np, "relocation-size",
> +                                   &hip04_boot.relocation_size) )
> +            goto err;
> +    }
>  
>      relocation = ioremap_nocache(hip04_boot.relocation_entry,
>                                   hip04_boot.relocation_size);
> 


-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:14:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:14:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIOu-0000OQ-Gb; Mon, 03 Nov 2014 14:14:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIOs-0000O1-JD
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:14:30 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	80/81-09842-5CD87545; Mon, 03 Nov 2014 14:14:29 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415024069!12396616!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23439 invoked from network); 3 Nov 2014 14:14:29 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:14:29 -0000
Received: by mail-wi0-f172.google.com with SMTP id bs8so6561846wib.17
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:14:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=NILlftdRzc3kS0aSVG9r/ammwaPJuk0phWEEXnigIkk=;
	b=FJHIydBwYpuXkL6FcWzdkfQ316ZosgE0EDCMCkfaKAFvR2ZCOPHDRyzliN83P4PacI
	+HOHNLNEbq/zEB6yVU2IxAKhT3t7FTao6vPjCYt4Azu84/Ep4ztf/8z5Th6HJZkHwtzd
	Q7lNyklZ+s/LlbDkJOVA1TSwgSYTfWzX9C7WAyZo6b91ruNlWLJqcmBSLf4bb+fn2NYN
	oQciWAZ3eHwTmVI6FzhqE1X+GLI6ROdIe6nU5OyuE0T4gO5k3mHpoJSLZianQqdxq7Ys
	m+WOiPLKwpSZ4U0d7JlG7d4RLVi6hIJdTwG/sv8v7yjAu6RPDCQ9BdN57VfeYs3z1QHg
	UEqw==
X-Gm-Message-State: ALoCoQn8FYo1PpNSbCBXz0llGaigkPTR3DSi5mriVtTNRJtCzQQiYeFzkTF/usuNpPfWSzKmJP7d
X-Received: by 10.180.12.136 with SMTP id y8mr16644328wib.73.1415024069028;
	Mon, 03 Nov 2014 06:14:29 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id p3sm22302486wjf.49.2014.11.03.06.14.27
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:14:28 -0800 (PST)
Message-ID: <54578DBD.2040002@linaro.org>
Date: Mon, 03 Nov 2014 14:14:21 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-10-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-10-git-send-email-frediano.ziglio@huawei.com>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/10] xen/device_tree: Add new helper to
 read arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

On 11/03/2014 10:12 AM, Frediano Ziglio wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> 
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

> ---
>  xen/common/device_tree.c      | 14 ++++++++++----
>  xen/include/xen/device_tree.h | 11 +++++++++++
>  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index f72b2e9..e97c28b 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -160,19 +160,25 @@ const void *dt_get_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                           const char *name, u32 *out_value)
>  {
> -    u32 len;
> +    return dt_property_read_u32_array(np, name, out_value, 1);
> +}
> +
> +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> +                                  const char *name, u32 *out_value, u16 out_len)
> +{
> +    u32 len, i;
>      const __be32 *val;
>  
>      val = dt_get_property(np, name, &len);
> -    if ( !val || len < sizeof(*out_value) )
> +    if ( !val || len < sizeof(*out_value) * out_len )
>          return 0;
>  
> -    *out_value = be32_to_cpup(val);
> +    for ( i = 0; i < out_len; i++, val++ )
> +        out_value[i] = be32_to_cpup(val);
>  
>      return 1;
>  }
>  
> -
>  bool_t dt_property_read_u64(const struct dt_device_node *np,
>                           const char *name, u64 *out_value)
>  {
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 08db8bc..5fcd9c4 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                              const char *name, u32 *out_value);
>  /**
> + * dt_property_read_u32_array - Helper to read a u32 array property.
> + * @np: node to get the value
> + * @name: name of the property
> + * @out_value: pointer to return value
> + * @out_len: lenght of the array
> + *
> + * Return true if get the desired value.
> + */
> +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> +                                  const char *name, u32 *out_value, u16 out_len);
> +/**
>   * dt_property_read_u64 - Helper to read a u64 property.
>   * @np: node to get the value
>   * @name: name of the property
> 


-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:14:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:14:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIOu-0000OQ-Gb; Mon, 03 Nov 2014 14:14:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIOs-0000O1-JD
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:14:30 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	80/81-09842-5CD87545; Mon, 03 Nov 2014 14:14:29 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415024069!12396616!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23439 invoked from network); 3 Nov 2014 14:14:29 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:14:29 -0000
Received: by mail-wi0-f172.google.com with SMTP id bs8so6561846wib.17
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:14:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=NILlftdRzc3kS0aSVG9r/ammwaPJuk0phWEEXnigIkk=;
	b=FJHIydBwYpuXkL6FcWzdkfQ316ZosgE0EDCMCkfaKAFvR2ZCOPHDRyzliN83P4PacI
	+HOHNLNEbq/zEB6yVU2IxAKhT3t7FTao6vPjCYt4Azu84/Ep4ztf/8z5Th6HJZkHwtzd
	Q7lNyklZ+s/LlbDkJOVA1TSwgSYTfWzX9C7WAyZo6b91ruNlWLJqcmBSLf4bb+fn2NYN
	oQciWAZ3eHwTmVI6FzhqE1X+GLI6ROdIe6nU5OyuE0T4gO5k3mHpoJSLZianQqdxq7Ys
	m+WOiPLKwpSZ4U0d7JlG7d4RLVi6hIJdTwG/sv8v7yjAu6RPDCQ9BdN57VfeYs3z1QHg
	UEqw==
X-Gm-Message-State: ALoCoQn8FYo1PpNSbCBXz0llGaigkPTR3DSi5mriVtTNRJtCzQQiYeFzkTF/usuNpPfWSzKmJP7d
X-Received: by 10.180.12.136 with SMTP id y8mr16644328wib.73.1415024069028;
	Mon, 03 Nov 2014 06:14:29 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id p3sm22302486wjf.49.2014.11.03.06.14.27
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:14:28 -0800 (PST)
Message-ID: <54578DBD.2040002@linaro.org>
Date: Mon, 03 Nov 2014 14:14:21 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-10-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-10-git-send-email-frediano.ziglio@huawei.com>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/10] xen/device_tree: Add new helper to
 read arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

On 11/03/2014 10:12 AM, Frediano Ziglio wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> 
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

> ---
>  xen/common/device_tree.c      | 14 ++++++++++----
>  xen/include/xen/device_tree.h | 11 +++++++++++
>  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index f72b2e9..e97c28b 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -160,19 +160,25 @@ const void *dt_get_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                           const char *name, u32 *out_value)
>  {
> -    u32 len;
> +    return dt_property_read_u32_array(np, name, out_value, 1);
> +}
> +
> +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> +                                  const char *name, u32 *out_value, u16 out_len)
> +{
> +    u32 len, i;
>      const __be32 *val;
>  
>      val = dt_get_property(np, name, &len);
> -    if ( !val || len < sizeof(*out_value) )
> +    if ( !val || len < sizeof(*out_value) * out_len )
>          return 0;
>  
> -    *out_value = be32_to_cpup(val);
> +    for ( i = 0; i < out_len; i++, val++ )
> +        out_value[i] = be32_to_cpup(val);
>  
>      return 1;
>  }
>  
> -
>  bool_t dt_property_read_u64(const struct dt_device_node *np,
>                           const char *name, u64 *out_value)
>  {
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 08db8bc..5fcd9c4 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                              const char *name, u32 *out_value);
>  /**
> + * dt_property_read_u32_array - Helper to read a u32 array property.
> + * @np: node to get the value
> + * @name: name of the property
> + * @out_value: pointer to return value
> + * @out_len: lenght of the array
> + *
> + * Return true if get the desired value.
> + */
> +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> +                                  const char *name, u32 *out_value, u16 out_len);
> +/**
>   * dt_property_read_u64 - Helper to read a u64 property.
>   * @np: node to get the value
>   * @name: name of the property
> 


-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:15:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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 1XlIPq-0000YZ-V1; Mon, 03 Nov 2014 14:15:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIPp-0000YO-Ug
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:15:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FF/01-24532-10E87545; Mon, 03 Nov 2014 14:15:29 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415024128!8978775!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10287 invoked from network); 3 Nov 2014 14:15:28 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:15:28 -0000
Received: by mail-wi0-f176.google.com with SMTP id h11so6581552wiw.9
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:15:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=air/MR6GjIm2s8HKZHDbtjUG8S+peGKWj1ruMGcQwDs=;
	b=fGPR38oD1Vv60vEKv4Ricj63G2XvURhZJl7ugSfekobTkEgq66xelLLR5SR99z7aP8
	rQneWM8zOUA9S/h7D2mfTcEBK64IAhHsgrVvi2yE1YItNM5nFKD4O0nm3qvpgSAaKJqv
	tJSvRjwdfQlSlNznjEzjkZ/5R+uLRMyzwU1wySqFrxvpHGLBf/xQLGxBPgLBCCj9c1vq
	P8zZXOE+MSgmA48hm2aGyt3itvRW8+glg5tscywpErswxxF93T33xef+G5WXWk/MEwhg
	r7ak+KInynwqfkKXirKVhHbwrzU5ugdMZgAaT6OmJ9StbLL+avW9Xy1reWJqeWQaZQm6
	0hiA==
X-Gm-Message-State: ALoCoQnqcfoADOZ+N9UOlPUw8eY8Go4M1Vy/HINMtA2G6tH+0eB5EyQKn+uJLZSAQBgG8ST+O6JU
X-Received: by 10.194.59.17 with SMTP id v17mr2777906wjq.130.1415024128503;
	Mon, 03 Nov 2014 06:15:28 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id vq1sm2405017wjc.29.2014.11.03.06.15.27
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:15:27 -0800 (PST)
Message-ID: <54578DF8.1050404@linaro.org>
Date: Mon, 03 Nov 2014 14:15:20 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-10-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-10-git-send-email-frediano.ziglio@huawei.com>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/10] xen/device_tree: Add new helper to
 read arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Sorry I forgot the 2 NITs (see below)

On 11/03/2014 10:12 AM, Frediano Ziglio wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> 
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/common/device_tree.c      | 14 ++++++++++----
>  xen/include/xen/device_tree.h | 11 +++++++++++
>  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index f72b2e9..e97c28b 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -160,19 +160,25 @@ const void *dt_get_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                           const char *name, u32 *out_value)
>  {
> -    u32 len;
> +    return dt_property_read_u32_array(np, name, out_value, 1);
> +}
> +
> +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> +                                  const char *name, u32 *out_value, u16 out_len)
> +{
> +    u32 len, i;
>      const __be32 *val;
>  
>      val = dt_get_property(np, name, &len);
> -    if ( !val || len < sizeof(*out_value) )
> +    if ( !val || len < sizeof(*out_value) * out_len )
>          return 0;
>  
> -    *out_value = be32_to_cpup(val);
> +    for ( i = 0; i < out_len; i++, val++ )
> +        out_value[i] = be32_to_cpup(val);
>  
>      return 1;
>  }
>  
> -

Spurious change.

>  bool_t dt_property_read_u64(const struct dt_device_node *np,
>                           const char *name, u64 *out_value)
>  {
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 08db8bc..5fcd9c4 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                              const char *name, u32 *out_value);
>  /**
> + * dt_property_read_u32_array - Helper to read a u32 array property.
> + * @np: node to get the value
> + * @name: name of the property
> + * @out_value: pointer to return value
> + * @out_len: lenght of the array

s/lenght/length/

Regards,


-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:15:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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 1XlIPq-0000YZ-V1; Mon, 03 Nov 2014 14:15:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIPp-0000YO-Ug
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:15:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FF/01-24532-10E87545; Mon, 03 Nov 2014 14:15:29 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415024128!8978775!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10287 invoked from network); 3 Nov 2014 14:15:28 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:15:28 -0000
Received: by mail-wi0-f176.google.com with SMTP id h11so6581552wiw.9
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:15:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=air/MR6GjIm2s8HKZHDbtjUG8S+peGKWj1ruMGcQwDs=;
	b=fGPR38oD1Vv60vEKv4Ricj63G2XvURhZJl7ugSfekobTkEgq66xelLLR5SR99z7aP8
	rQneWM8zOUA9S/h7D2mfTcEBK64IAhHsgrVvi2yE1YItNM5nFKD4O0nm3qvpgSAaKJqv
	tJSvRjwdfQlSlNznjEzjkZ/5R+uLRMyzwU1wySqFrxvpHGLBf/xQLGxBPgLBCCj9c1vq
	P8zZXOE+MSgmA48hm2aGyt3itvRW8+glg5tscywpErswxxF93T33xef+G5WXWk/MEwhg
	r7ak+KInynwqfkKXirKVhHbwrzU5ugdMZgAaT6OmJ9StbLL+avW9Xy1reWJqeWQaZQm6
	0hiA==
X-Gm-Message-State: ALoCoQnqcfoADOZ+N9UOlPUw8eY8Go4M1Vy/HINMtA2G6tH+0eB5EyQKn+uJLZSAQBgG8ST+O6JU
X-Received: by 10.194.59.17 with SMTP id v17mr2777906wjq.130.1415024128503;
	Mon, 03 Nov 2014 06:15:28 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id vq1sm2405017wjc.29.2014.11.03.06.15.27
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:15:27 -0800 (PST)
Message-ID: <54578DF8.1050404@linaro.org>
Date: Mon, 03 Nov 2014 14:15:20 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-10-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-10-git-send-email-frediano.ziglio@huawei.com>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/10] xen/device_tree: Add new helper to
 read arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Sorry I forgot the 2 NITs (see below)

On 11/03/2014 10:12 AM, Frediano Ziglio wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> 
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/common/device_tree.c      | 14 ++++++++++----
>  xen/include/xen/device_tree.h | 11 +++++++++++
>  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index f72b2e9..e97c28b 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -160,19 +160,25 @@ const void *dt_get_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                           const char *name, u32 *out_value)
>  {
> -    u32 len;
> +    return dt_property_read_u32_array(np, name, out_value, 1);
> +}
> +
> +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> +                                  const char *name, u32 *out_value, u16 out_len)
> +{
> +    u32 len, i;
>      const __be32 *val;
>  
>      val = dt_get_property(np, name, &len);
> -    if ( !val || len < sizeof(*out_value) )
> +    if ( !val || len < sizeof(*out_value) * out_len )
>          return 0;
>  
> -    *out_value = be32_to_cpup(val);
> +    for ( i = 0; i < out_len; i++, val++ )
> +        out_value[i] = be32_to_cpup(val);
>  
>      return 1;
>  }
>  
> -

Spurious change.

>  bool_t dt_property_read_u64(const struct dt_device_node *np,
>                           const char *name, u64 *out_value)
>  {
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 08db8bc..5fcd9c4 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                              const char *name, u32 *out_value);
>  /**
> + * dt_property_read_u32_array - Helper to read a u32 array property.
> + * @np: node to get the value
> + * @name: name of the property
> + * @out_value: pointer to return value
> + * @out_len: lenght of the array

s/lenght/length/

Regards,


-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:16:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIRB-0000jM-Kz; Mon, 03 Nov 2014 14:16:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIRA-0000iz-6F
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:16:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5E/66-09842-35E87545; Mon, 03 Nov 2014 14:16:51 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415024210!12397359!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23377 invoked from network); 3 Nov 2014 14:16:50 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:16:50 -0000
Received: by mail-wi0-f172.google.com with SMTP id bs8so6578167wib.11
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:16:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=lsEwBd6TPUg95NVnWVR8JY4gxCONOwwgKMh8l1PGkgU=;
	b=M/5enAmkYMuOjUqxbC0sjWWk2TaJs5pL9NfUq1iO7sEO7hL/jO3I2oyeeABw89/W0/
	UhC0YfpkU4VLREOGT3uGvwvrD+IhHPjqqKkmkgjn+N+U/eTpSwGtggOo6Phhu7quw8ko
	N+CvYWBxVCw8WFVTBDq21WCIQMVMUmksIKUbWt7WiSyLRd9U2e12Q5ZoAHewQClgbh0q
	Lv9B8BV+8UAoACt2H7jHTcXxwZKcy03Dll11X3q1RG2P0+exXGebyDkOI9B6b7SAyN6P
	xGsSlxFgKS2Kka5fHSYy/sNwW9zWi+WVFvJpapNepSJ0GDkg2AKg32rSUcTLyAcwkxHU
	E/UQ==
X-Gm-Message-State: ALoCoQm03628oSSllD38XTAMK0KoLFDKDMKGpvxuGe9xUo/M0OluSKLiFhu5jIzHSstBPJsFO8lh
X-Received: by 10.194.120.1 with SMTP id ky1mr10729126wjb.86.1415024210611;
	Mon, 03 Nov 2014 06:16:50 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id j8sm8879184wib.10.2014.11.03.06.16.49
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:16:49 -0800 (PST)
Message-ID: <54578E4A.4020907@linaro.org>
Date: Mon, 03 Nov 2014 14:16:42 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-8-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-8-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 07/10] xen/arm: Force domains to use normal
 GICv2 driver on Hip04 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

Hi Frediano,

FYI, this is only force DOM0 to use the normal GICv2 drivers.

Do you have any plan to support hi-silicon vGIC in Xen? This would allow
guest running with more than 8 cores.

Regards,

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
> Until vGIC support is not implemented and tested, this will prevent
> guest kernels to use their Hip04 driver, or crash when they don't
> have any.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index e7bf331..d92e2c0 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -641,6 +641,12 @@ static int gicv2_make_dt_node(const struct domain *d,
>          return -FDT_ERR_XEN(ENOENT);
>      }
>  
> +    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
> +    {
> +        compatible = DT_COMPAT_GIC_CORTEX_A15;
> +        len = strlen((char*) compatible) + 1;
> +    }
> +
>      res = fdt_begin_node(fdt, "interrupt-controller");
>      if ( res )
>          return res;
> 


-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:16:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIRB-0000jM-Kz; Mon, 03 Nov 2014 14:16:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlIRA-0000iz-6F
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:16:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5E/66-09842-35E87545; Mon, 03 Nov 2014 14:16:51 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415024210!12397359!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23377 invoked from network); 3 Nov 2014 14:16:50 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:16:50 -0000
Received: by mail-wi0-f172.google.com with SMTP id bs8so6578167wib.11
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:16:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=lsEwBd6TPUg95NVnWVR8JY4gxCONOwwgKMh8l1PGkgU=;
	b=M/5enAmkYMuOjUqxbC0sjWWk2TaJs5pL9NfUq1iO7sEO7hL/jO3I2oyeeABw89/W0/
	UhC0YfpkU4VLREOGT3uGvwvrD+IhHPjqqKkmkgjn+N+U/eTpSwGtggOo6Phhu7quw8ko
	N+CvYWBxVCw8WFVTBDq21WCIQMVMUmksIKUbWt7WiSyLRd9U2e12Q5ZoAHewQClgbh0q
	Lv9B8BV+8UAoACt2H7jHTcXxwZKcy03Dll11X3q1RG2P0+exXGebyDkOI9B6b7SAyN6P
	xGsSlxFgKS2Kka5fHSYy/sNwW9zWi+WVFvJpapNepSJ0GDkg2AKg32rSUcTLyAcwkxHU
	E/UQ==
X-Gm-Message-State: ALoCoQm03628oSSllD38XTAMK0KoLFDKDMKGpvxuGe9xUo/M0OluSKLiFhu5jIzHSstBPJsFO8lh
X-Received: by 10.194.120.1 with SMTP id ky1mr10729126wjb.86.1415024210611;
	Mon, 03 Nov 2014 06:16:50 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id j8sm8879184wib.10.2014.11.03.06.16.49
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 06:16:49 -0800 (PST)
Message-ID: <54578E4A.4020907@linaro.org>
Date: Mon, 03 Nov 2014 14:16:42 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-8-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415009522-6344-8-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 07/10] xen/arm: Force domains to use normal
 GICv2 driver on Hip04 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

Hi Frediano,

FYI, this is only force DOM0 to use the normal GICv2 drivers.

Do you have any plan to support hi-silicon vGIC in Xen? This would allow
guest running with more than 8 cores.

Regards,

On 11/03/2014 10:11 AM, Frediano Ziglio wrote:
> Until vGIC support is not implemented and tested, this will prevent
> guest kernels to use their Hip04 driver, or crash when they don't
> have any.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index e7bf331..d92e2c0 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -641,6 +641,12 @@ static int gicv2_make_dt_node(const struct domain *d,
>          return -FDT_ERR_XEN(ENOENT);
>      }
>  
> +    if ( platform_has_quirk(PLATFORM_QUIRK_GICV2_16_CPU) )
> +    {
> +        compatible = DT_COMPAT_GIC_CORTEX_A15;
> +        len = strlen((char*) compatible) + 1;
> +    }
> +
>      res = fdt_begin_node(fdt, "interrupt-controller");
>      if ( res )
>          return res;
> 


-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:17:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIRK-0000lK-1X; Mon, 03 Nov 2014 14:17:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlIRI-0000kk-4w
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:17:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	23/B6-09842-B5E87545; Mon, 03 Nov 2014 14:16:59 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415024218!12448659!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14798 invoked from network); 3 Nov 2014 14:16:58 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:16:58 -0000
Received: by mail-wg0-f51.google.com with SMTP id l18so11088762wgh.24
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:16:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=Q6HDCfaLFjdyIDv5W2GtkNmHNP42srtl1Ees2XxKRzM=;
	b=DlLanAqw5gc4Oqb6eOSlW51ad429UAj6XkB2ThfhlhJcSAbxAO5GsMkZOmFtFvzzjA
	599vvmD9RlNflR7DEGAdW+YNvymDZCd5mnbJCX6jVpP/9/lMaFED+6kyU9GdmQEezMp6
	qs+w89BRomRposGmnYFJae6RbC0sT3MEgFa+2LKCcXmmJc+LA4YaAXp/D+0uo0NZUjeH
	NnU5IHHZvZtGuDw09QqCaQ/4wWfBso15KxaSl/R21tNV+tQqIzME9tXRIS/bms9pCzhO
	wcxLy5ck67PH2ws0WzJLuAsaaIKwrlb1WzKdmKat2j+4opZC2E+Vd+LkK+4QcG0SBsl/
	yqfg==
MIME-Version: 1.0
X-Received: by 10.194.250.41 with SMTP id yz9mr758776wjc.34.1415024218485;
	Mon, 03 Nov 2014 06:16:58 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 3 Nov 2014 06:16:58 -0800 (PST)
In-Reply-To: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
Date: Mon, 3 Nov 2014 14:16:58 +0000
X-Google-Sender-Auth: yvr-eXhJ1acQ0At-H6meXz8gbjM
Message-ID: <CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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, Oct 7, 2014 at 4:01 PM, Olaf Hering <olaf@aepfle.de> wrote:
> An increasing version and/or release number helps to update existing
> packages without --force as in "rpm Uvh --force xen.rpm". Instead its
> possible to do "rpm -Fvh *.rpm" to update only already installed
> packages.
>
> With the current way of calculating version-release it is difficult to
> get an increasing release number into the spec file. The release is
> always zero unless "make make XEN_VENDORVERSION=`date +.%s`" is used,
> which has the bad side effect that xen.gz always gets a different
> filename every time.
>
> Since the value of release has no meaning its fine to have an ever
> increasing number. This could be either the number of seconds (+%s), or
> some representation which could mean something to a human. The change
> uses a representation of date+time.
>
> With this change my xen$PKG_SUFFIX.rpm gets as version-release
> 4.5_unstable-20141007161858, instead of 4.5-unstable$XEN_VENDORVERSION.
>
> Note: to maintain the functionality that "rpm -F xen.rpm" works its also
> required that the alphanumerical chars increase. Unfortunately thats not
> the case for 4.5-rcN because "r" is smaller than "u"nstable. And going
> from 4.5-rcN to 4.5 (or 4.5.N-pre to 4.5.N) may break as well. But there
> is nothing we can do about this part.
> Once 4.6 opens I suggest to set XEN_EXTRAVERSION to -devel because "d"
> is smaller than "r" in 4.6-rcN. But thats a different discussion.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  tools/misc/mkrpm | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/tools/misc/mkrpm b/tools/misc/mkrpm
> index 9b8c6d9..b54de24 100644
> --- a/tools/misc/mkrpm
> +++ b/tools/misc/mkrpm
> @@ -13,13 +13,11 @@ fi
>
>  xenroot="$1"
>
> -# rpmbuild doesn't like dashes in the version; break it down into
> -# version and release.  Default to "0" if there isn't a release.
> -v=(${2/-/ })
> -version=${v[0]}
> -release=${v[1]}
> -
> -[[ -n "$release" ]] || release="0"
> +# rpmbuild doesn't support dashes in the version;
> +version=${2//-/_}
> +# Use an ever increasing release number for this devel pkg.
> +# This makes sure rpm -Fvh xen$PKG_SUFFIX.rpm can be updated wihtout --force.
> +release="`date +%Y%m%d%H%M%S`"

Hrm, I can see how this might be useful, but I'm not really a fan of
the uniquifier being based on the date the build was actually kicked
off.

How difficult would it be to have this be something sensible like,
"changesets since last tag"?

This information can be found, for instance, in "git describe"; for example:

$ git describe
4.5.0-rc1-44-g82587ce

(i.e., 44 commits pas 4.5.0-rc1)

$ git checkout 91086d0
$ git describe
4.5-unstable-1495-g91086d0

(i.e., 1495 commits past 4.5-unstable)

If git isn't present, then it's probably a source tarball, in which
case "0" is probably a suitable value.

Thoughts?

 -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:17:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIRK-0000lK-1X; Mon, 03 Nov 2014 14:17:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlIRI-0000kk-4w
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:17:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	23/B6-09842-B5E87545; Mon, 03 Nov 2014 14:16:59 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415024218!12448659!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14798 invoked from network); 3 Nov 2014 14:16:58 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:16:58 -0000
Received: by mail-wg0-f51.google.com with SMTP id l18so11088762wgh.24
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:16:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=Q6HDCfaLFjdyIDv5W2GtkNmHNP42srtl1Ees2XxKRzM=;
	b=DlLanAqw5gc4Oqb6eOSlW51ad429UAj6XkB2ThfhlhJcSAbxAO5GsMkZOmFtFvzzjA
	599vvmD9RlNflR7DEGAdW+YNvymDZCd5mnbJCX6jVpP/9/lMaFED+6kyU9GdmQEezMp6
	qs+w89BRomRposGmnYFJae6RbC0sT3MEgFa+2LKCcXmmJc+LA4YaAXp/D+0uo0NZUjeH
	NnU5IHHZvZtGuDw09QqCaQ/4wWfBso15KxaSl/R21tNV+tQqIzME9tXRIS/bms9pCzhO
	wcxLy5ck67PH2ws0WzJLuAsaaIKwrlb1WzKdmKat2j+4opZC2E+Vd+LkK+4QcG0SBsl/
	yqfg==
MIME-Version: 1.0
X-Received: by 10.194.250.41 with SMTP id yz9mr758776wjc.34.1415024218485;
	Mon, 03 Nov 2014 06:16:58 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 3 Nov 2014 06:16:58 -0800 (PST)
In-Reply-To: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
Date: Mon, 3 Nov 2014 14:16:58 +0000
X-Google-Sender-Auth: yvr-eXhJ1acQ0At-H6meXz8gbjM
Message-ID: <CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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, Oct 7, 2014 at 4:01 PM, Olaf Hering <olaf@aepfle.de> wrote:
> An increasing version and/or release number helps to update existing
> packages without --force as in "rpm Uvh --force xen.rpm". Instead its
> possible to do "rpm -Fvh *.rpm" to update only already installed
> packages.
>
> With the current way of calculating version-release it is difficult to
> get an increasing release number into the spec file. The release is
> always zero unless "make make XEN_VENDORVERSION=`date +.%s`" is used,
> which has the bad side effect that xen.gz always gets a different
> filename every time.
>
> Since the value of release has no meaning its fine to have an ever
> increasing number. This could be either the number of seconds (+%s), or
> some representation which could mean something to a human. The change
> uses a representation of date+time.
>
> With this change my xen$PKG_SUFFIX.rpm gets as version-release
> 4.5_unstable-20141007161858, instead of 4.5-unstable$XEN_VENDORVERSION.
>
> Note: to maintain the functionality that "rpm -F xen.rpm" works its also
> required that the alphanumerical chars increase. Unfortunately thats not
> the case for 4.5-rcN because "r" is smaller than "u"nstable. And going
> from 4.5-rcN to 4.5 (or 4.5.N-pre to 4.5.N) may break as well. But there
> is nothing we can do about this part.
> Once 4.6 opens I suggest to set XEN_EXTRAVERSION to -devel because "d"
> is smaller than "r" in 4.6-rcN. But thats a different discussion.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  tools/misc/mkrpm | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/tools/misc/mkrpm b/tools/misc/mkrpm
> index 9b8c6d9..b54de24 100644
> --- a/tools/misc/mkrpm
> +++ b/tools/misc/mkrpm
> @@ -13,13 +13,11 @@ fi
>
>  xenroot="$1"
>
> -# rpmbuild doesn't like dashes in the version; break it down into
> -# version and release.  Default to "0" if there isn't a release.
> -v=(${2/-/ })
> -version=${v[0]}
> -release=${v[1]}
> -
> -[[ -n "$release" ]] || release="0"
> +# rpmbuild doesn't support dashes in the version;
> +version=${2//-/_}
> +# Use an ever increasing release number for this devel pkg.
> +# This makes sure rpm -Fvh xen$PKG_SUFFIX.rpm can be updated wihtout --force.
> +release="`date +%Y%m%d%H%M%S`"

Hrm, I can see how this might be useful, but I'm not really a fan of
the uniquifier being based on the date the build was actually kicked
off.

How difficult would it be to have this be something sensible like,
"changesets since last tag"?

This information can be found, for instance, in "git describe"; for example:

$ git describe
4.5.0-rc1-44-g82587ce

(i.e., 44 commits pas 4.5.0-rc1)

$ git checkout 91086d0
$ git describe
4.5-unstable-1495-g91086d0

(i.e., 1495 commits past 4.5-unstable)

If git isn't present, then it's probably a source tarball, in which
case "0" is probably a suitable value.

Thoughts?

 -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:19:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlITl-00012n-Lb; Mon, 03 Nov 2014 14:19:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlITk-00012g-A5
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:19:32 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	61/3F-09936-3FE87545; Mon, 03 Nov 2014 14:19:31 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415024370!12435129!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15527 invoked from network); 3 Nov 2014 14:19:31 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:19:31 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so6505410wib.13
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:19:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=7U4ADmpswsCCGT8WhgaUqTGNzf7nGX7RRu64nTnMHqA=;
	b=diHm6UIfBiDo3LFTdJOtdNetZRpp/uErddb5+VPj9wGZa2rrUSf3RiuqNoxbn9FK6a
	qvs6yuzNA01W4vYekGvgUjxXqMoJWZMQnR4+zr/9rmyQ8mLnEu3/9+hWpy8Z9+Q44LsD
	Oe5tBUVw2/2vxRF3x+YHdaPFrM+U9ziZMqOrBd+I/I7G+G8FULWy7Oa1wfu8XXjK2k09
	UeVm+I+NRnv30eDFAUjRJ5deLRJdRyxoBlWg32qJfNs+Gzn9Nl9z7ttVpw14btpbK8ea
	1qEhJ2XawM9ywhK5ZYkvA6G25nyZioU8FC7j/Xc/P+jgxj/u4AO/agzIAs8T9KK5ysda
	bwHg==
MIME-Version: 1.0
X-Received: by 10.180.36.205 with SMTP id s13mr16194443wij.11.1415024370210;
	Mon, 03 Nov 2014 06:19:30 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 3 Nov 2014 06:19:30 -0800 (PST)
In-Reply-To: <CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
Date: Mon, 3 Nov 2014 14:19:30 +0000
X-Google-Sender-Auth: Q3019P_4hgSHPOUMH1kRh8Kb_vE
Message-ID: <CAFLBxZaqXCUb+5E_y7p-B+fpasggqEAnJY_zotTvoLsQQezoYQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, Nov 3, 2014 at 2:16 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> On Tue, Oct 7, 2014 at 4:01 PM, Olaf Hering <olaf@aepfle.de> wrote:
>> An increasing version and/or release number helps to update existing
>> packages without --force as in "rpm Uvh --force xen.rpm". Instead its
>> possible to do "rpm -Fvh *.rpm" to update only already installed
>> packages.
>>
>> With the current way of calculating version-release it is difficult to
>> get an increasing release number into the spec file. The release is
>> always zero unless "make make XEN_VENDORVERSION=`date +.%s`" is used,
>> which has the bad side effect that xen.gz always gets a different
>> filename every time.
>>
>> Since the value of release has no meaning its fine to have an ever
>> increasing number. This could be either the number of seconds (+%s), or
>> some representation which could mean something to a human. The change
>> uses a representation of date+time.
>>
>> With this change my xen$PKG_SUFFIX.rpm gets as version-release
>> 4.5_unstable-20141007161858, instead of 4.5-unstable$XEN_VENDORVERSION.
>>
>> Note: to maintain the functionality that "rpm -F xen.rpm" works its also
>> required that the alphanumerical chars increase. Unfortunately thats not
>> the case for 4.5-rcN because "r" is smaller than "u"nstable. And going
>> from 4.5-rcN to 4.5 (or 4.5.N-pre to 4.5.N) may break as well. But there
>> is nothing we can do about this part.
>> Once 4.6 opens I suggest to set XEN_EXTRAVERSION to -devel because "d"
>> is smaller than "r" in 4.6-rcN. But thats a different discussion.
>>
>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Wei Liu <wei.liu2@citrix.com>
>> Cc: George Dunlap <george.dunlap@eu.citrix.com>
>> ---
>>  tools/misc/mkrpm | 12 +++++-------
>>  1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/misc/mkrpm b/tools/misc/mkrpm
>> index 9b8c6d9..b54de24 100644
>> --- a/tools/misc/mkrpm
>> +++ b/tools/misc/mkrpm
>> @@ -13,13 +13,11 @@ fi
>>
>>  xenroot="$1"
>>
>> -# rpmbuild doesn't like dashes in the version; break it down into
>> -# version and release.  Default to "0" if there isn't a release.
>> -v=(${2/-/ })
>> -version=${v[0]}
>> -release=${v[1]}
>> -
>> -[[ -n "$release" ]] || release="0"
>> +# rpmbuild doesn't support dashes in the version;
>> +version=${2//-/_}
>> +# Use an ever increasing release number for this devel pkg.
>> +# This makes sure rpm -Fvh xen$PKG_SUFFIX.rpm can be updated wihtout --force.
>> +release="`date +%Y%m%d%H%M%S`"
>
> Hrm, I can see how this might be useful, but I'm not really a fan of
> the uniquifier being based on the date the build was actually kicked
> off.

Given that these are also just supposed to be used by developers,
requiring you to do "rpm -e xen" first doesn't seem like *that* much
of a big deal.  It's easy enough to put into a script.

 -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:19:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlITl-00012n-Lb; Mon, 03 Nov 2014 14:19:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlITk-00012g-A5
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:19:32 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	61/3F-09936-3FE87545; Mon, 03 Nov 2014 14:19:31 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415024370!12435129!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15527 invoked from network); 3 Nov 2014 14:19:31 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:19:31 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so6505410wib.13
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 06:19:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=7U4ADmpswsCCGT8WhgaUqTGNzf7nGX7RRu64nTnMHqA=;
	b=diHm6UIfBiDo3LFTdJOtdNetZRpp/uErddb5+VPj9wGZa2rrUSf3RiuqNoxbn9FK6a
	qvs6yuzNA01W4vYekGvgUjxXqMoJWZMQnR4+zr/9rmyQ8mLnEu3/9+hWpy8Z9+Q44LsD
	Oe5tBUVw2/2vxRF3x+YHdaPFrM+U9ziZMqOrBd+I/I7G+G8FULWy7Oa1wfu8XXjK2k09
	UeVm+I+NRnv30eDFAUjRJ5deLRJdRyxoBlWg32qJfNs+Gzn9Nl9z7ttVpw14btpbK8ea
	1qEhJ2XawM9ywhK5ZYkvA6G25nyZioU8FC7j/Xc/P+jgxj/u4AO/agzIAs8T9KK5ysda
	bwHg==
MIME-Version: 1.0
X-Received: by 10.180.36.205 with SMTP id s13mr16194443wij.11.1415024370210;
	Mon, 03 Nov 2014 06:19:30 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 3 Nov 2014 06:19:30 -0800 (PST)
In-Reply-To: <CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
Date: Mon, 3 Nov 2014 14:19:30 +0000
X-Google-Sender-Auth: Q3019P_4hgSHPOUMH1kRh8Kb_vE
Message-ID: <CAFLBxZaqXCUb+5E_y7p-B+fpasggqEAnJY_zotTvoLsQQezoYQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, Nov 3, 2014 at 2:16 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> On Tue, Oct 7, 2014 at 4:01 PM, Olaf Hering <olaf@aepfle.de> wrote:
>> An increasing version and/or release number helps to update existing
>> packages without --force as in "rpm Uvh --force xen.rpm". Instead its
>> possible to do "rpm -Fvh *.rpm" to update only already installed
>> packages.
>>
>> With the current way of calculating version-release it is difficult to
>> get an increasing release number into the spec file. The release is
>> always zero unless "make make XEN_VENDORVERSION=`date +.%s`" is used,
>> which has the bad side effect that xen.gz always gets a different
>> filename every time.
>>
>> Since the value of release has no meaning its fine to have an ever
>> increasing number. This could be either the number of seconds (+%s), or
>> some representation which could mean something to a human. The change
>> uses a representation of date+time.
>>
>> With this change my xen$PKG_SUFFIX.rpm gets as version-release
>> 4.5_unstable-20141007161858, instead of 4.5-unstable$XEN_VENDORVERSION.
>>
>> Note: to maintain the functionality that "rpm -F xen.rpm" works its also
>> required that the alphanumerical chars increase. Unfortunately thats not
>> the case for 4.5-rcN because "r" is smaller than "u"nstable. And going
>> from 4.5-rcN to 4.5 (or 4.5.N-pre to 4.5.N) may break as well. But there
>> is nothing we can do about this part.
>> Once 4.6 opens I suggest to set XEN_EXTRAVERSION to -devel because "d"
>> is smaller than "r" in 4.6-rcN. But thats a different discussion.
>>
>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Wei Liu <wei.liu2@citrix.com>
>> Cc: George Dunlap <george.dunlap@eu.citrix.com>
>> ---
>>  tools/misc/mkrpm | 12 +++++-------
>>  1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/misc/mkrpm b/tools/misc/mkrpm
>> index 9b8c6d9..b54de24 100644
>> --- a/tools/misc/mkrpm
>> +++ b/tools/misc/mkrpm
>> @@ -13,13 +13,11 @@ fi
>>
>>  xenroot="$1"
>>
>> -# rpmbuild doesn't like dashes in the version; break it down into
>> -# version and release.  Default to "0" if there isn't a release.
>> -v=(${2/-/ })
>> -version=${v[0]}
>> -release=${v[1]}
>> -
>> -[[ -n "$release" ]] || release="0"
>> +# rpmbuild doesn't support dashes in the version;
>> +version=${2//-/_}
>> +# Use an ever increasing release number for this devel pkg.
>> +# This makes sure rpm -Fvh xen$PKG_SUFFIX.rpm can be updated wihtout --force.
>> +release="`date +%Y%m%d%H%M%S`"
>
> Hrm, I can see how this might be useful, but I'm not really a fan of
> the uniquifier being based on the date the build was actually kicked
> off.

Given that these are also just supposed to be used by developers,
requiring you to do "rpm -e xen" first doesn't seem like *that* much
of a big deal.  It's easy enough to put into a script.

 -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:24:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:24:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIYj-0001OV-Kc; Mon, 03 Nov 2014 14:24:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XlIYh-0001OO-ME
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:24:40 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	96/80-18267-62097545; Mon, 03 Nov 2014 14:24:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415024678!7579384!1
X-Originating-IP: [81.169.146.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5128 invoked from network); 3 Nov 2014 14:24:38 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 14:24:38 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415024678; l=284;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=rTHaOTl/N9zjvKneWZSmjIUOVXs=;
	b=vOUO9ic+iQzqOkFGbf5bqdlrD4dgoiFQOSu8ATU8B6KC1Di6NttL45FtyqwQudMJnNj
	Nuk+GBlzSESKPfsmbJyxh+bqm8t32F+Lw7yWeCmPo85iG756CQ0lc9EKo552qyhTYTQbr
	0YzLclZJ/2IMzVYdi/ABEykT8kyWv9OZtns=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id J07de7qA3EOcWqn
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 3 Nov 2014 15:24:38 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 377CC50172; Mon,  3 Nov 2014 15:24:36 +0100 (CET)
Date: Mon, 3 Nov 2014 15:24:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141103142436.GA23458@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, Nov 03, George Dunlap wrote:

> How difficult would it be to have this be something sensible like,
> "changesets since last tag"?

Very difficult, because one does changes without commit, runs 'make
rpmball' and expects that rpm -Fvh *.rpm continues to work.


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:24:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:24:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIYj-0001OV-Kc; Mon, 03 Nov 2014 14:24:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XlIYh-0001OO-ME
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:24:40 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	96/80-18267-62097545; Mon, 03 Nov 2014 14:24:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415024678!7579384!1
X-Originating-IP: [81.169.146.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5128 invoked from network); 3 Nov 2014 14:24:38 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 14:24:38 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415024678; l=284;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=rTHaOTl/N9zjvKneWZSmjIUOVXs=;
	b=vOUO9ic+iQzqOkFGbf5bqdlrD4dgoiFQOSu8ATU8B6KC1Di6NttL45FtyqwQudMJnNj
	Nuk+GBlzSESKPfsmbJyxh+bqm8t32F+Lw7yWeCmPo85iG756CQ0lc9EKo552qyhTYTQbr
	0YzLclZJ/2IMzVYdi/ABEykT8kyWv9OZtns=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id J07de7qA3EOcWqn
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 3 Nov 2014 15:24:38 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 377CC50172; Mon,  3 Nov 2014 15:24:36 +0100 (CET)
Date: Mon, 3 Nov 2014 15:24:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141103142436.GA23458@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, Nov 03, George Dunlap wrote:

> How difficult would it be to have this be something sensible like,
> "changesets since last tag"?

Very difficult, because one does changes without commit, runs 'make
rpmball' and expects that rpm -Fvh *.rpm continues to work.


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:25:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIZE-0001Re-1X; Mon, 03 Nov 2014 14:25:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlIZD-0001RU-Gs
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 14:25:11 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	FE/84-19763-64097545; Mon, 03 Nov 2014 14:25:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415024708!5494163!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30418 invoked from network); 3 Nov 2014 14:25:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:25:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="187521807"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 09:25:07 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlIZ9-0002hr-QQ;
	Mon, 03 Nov 2014 14:25:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlIZ9-0006WI-GN;
	Mon, 03 Nov 2014 14:25:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21591.36931.244519.373451@mariner.uk.xensource.com>
Date: Mon, 3 Nov 2014 14:25:07 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415007810.9994.3.camel@citrix.com>
References: <osstest-31329-mainreport@xen.org>
	<1415007810.9994.3.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	"xen.org" <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL"):
> Looks like this test hasn't succeeded since 6 October (flight 30603).
> 
> Looking over the various failures since then the 
>  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
> one has been consistently failing.

This is the longstanding mptsas swiotlb bug.

In this particular test case, the migration test source host reports
lots of swiotlb full messages, first from bnx2 and then from mptsas.

The first such message is from bnx2 in the middle of guest boot
(32-bit PV Debian guest).  The guest is booting on the source host,
and the guest's filesystem is provided via nbd.  The source host has
the nbd client and the destination host the nbd server.

I have added `swiotlb=26422' to the host property `install-append
wheezy' for these two machines.  Hopefully this will either work
around the problem, or at least provide more information.

Ian.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:25:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIZE-0001Re-1X; Mon, 03 Nov 2014 14:25:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlIZD-0001RU-Gs
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 14:25:11 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	FE/84-19763-64097545; Mon, 03 Nov 2014 14:25:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415024708!5494163!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30418 invoked from network); 3 Nov 2014 14:25:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:25:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="187521807"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 09:25:07 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlIZ9-0002hr-QQ;
	Mon, 03 Nov 2014 14:25:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlIZ9-0006WI-GN;
	Mon, 03 Nov 2014 14:25:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21591.36931.244519.373451@mariner.uk.xensource.com>
Date: Mon, 3 Nov 2014 14:25:07 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415007810.9994.3.camel@citrix.com>
References: <osstest-31329-mainreport@xen.org>
	<1415007810.9994.3.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	"xen.org" <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL"):
> Looks like this test hasn't succeeded since 6 October (flight 30603).
> 
> Looking over the various failures since then the 
>  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
> one has been consistently failing.

This is the longstanding mptsas swiotlb bug.

In this particular test case, the migration test source host reports
lots of swiotlb full messages, first from bnx2 and then from mptsas.

The first such message is from bnx2 in the middle of guest boot
(32-bit PV Debian guest).  The guest is booting on the source host,
and the guest's filesystem is provided via nbd.  The source host has
the nbd client and the destination host the nbd server.

I have added `swiotlb=26422' to the host property `install-append
wheezy' for these two machines.  Hopefully this will either work
around the problem, or at least provide more information.

Ian.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:30:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:30:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIdo-0001jg-Sv; Mon, 03 Nov 2014 14:29:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlIdn-0001jb-Mk
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:29:55 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	46/ED-11608-26197545; Mon, 03 Nov 2014 14:29:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415024991!11348421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27969 invoked from network); 3 Nov 2014 14:29:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:29:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="187523488"
Message-ID: <1415024987.24785.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 3 Nov 2014 14:29:47 +0000
In-Reply-To: <20141103142436.GA23458@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, 2014-11-03 at 15:24 +0100, Olaf Hering wrote:
> On Mon, Nov 03, George Dunlap wrote:
> 
> > How difficult would it be to have this be something sensible like,
> > "changesets since last tag"?
> 
> Very difficult, because one does changes without commit, runs 'make
> rpmball' and expects that rpm -Fvh *.rpm continues to work.

Isn't that what "rpm -Uvh" is for?


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:30:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:30:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIdo-0001jg-Sv; Mon, 03 Nov 2014 14:29:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlIdn-0001jb-Mk
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:29:55 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	46/ED-11608-26197545; Mon, 03 Nov 2014 14:29:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415024991!11348421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27969 invoked from network); 3 Nov 2014 14:29:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:29:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="187523488"
Message-ID: <1415024987.24785.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 3 Nov 2014 14:29:47 +0000
In-Reply-To: <20141103142436.GA23458@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, 2014-11-03 at 15:24 +0100, Olaf Hering wrote:
> On Mon, Nov 03, George Dunlap wrote:
> 
> > How difficult would it be to have this be something sensible like,
> > "changesets since last tag"?
> 
> Very difficult, because one does changes without commit, runs 'make
> rpmball' and expects that rpm -Fvh *.rpm continues to work.

Isn't that what "rpm -Uvh" is for?


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:32:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIge-0001t3-Fo; Mon, 03 Nov 2014 14:32: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@citrix.com>) id 1XlIgc-0001sv-Qh
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:32:50 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	36/1A-26652-21297545; Mon, 03 Nov 2014 14:32:50 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415025167!10898477!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4896 invoked from network); 3 Nov 2014 14:32:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:32:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="187524582"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 09:32:42 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XlIgU-0002oH-EP;
	Mon, 03 Nov 2014 14:32:42 +0000
Message-ID: <545791F6.2080809@eu.citrix.com>
Date: Mon, 3 Nov 2014 14:32:22 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de>
In-Reply-To: <20141103142436.GA23458@aepfle.de>
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/2014 02:24 PM, Olaf Hering wrote:
> On Mon, Nov 03, George Dunlap wrote:
>
>> How difficult would it be to have this be something sensible like,
>> "changesets since last tag"?
> Very difficult, because one does changes without commit, runs 'make
> rpmball' and expects that rpm -Fvh *.rpm continues to work.

Right.  Personally, I think trying to make "rpm -Fvh" work for all the 
use cases a developer might want is more hassle than it's worth; as I 
said, I have scripts that just do "rpm -e" in such cases.  I wouldn't 
oppose it, but I don't really support it either.

Ian / Ian / Wei, any thoughts?

  -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:32:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIge-0001t3-Fo; Mon, 03 Nov 2014 14:32: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@citrix.com>) id 1XlIgc-0001sv-Qh
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:32:50 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	36/1A-26652-21297545; Mon, 03 Nov 2014 14:32:50 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415025167!10898477!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4896 invoked from network); 3 Nov 2014 14:32:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:32:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="187524582"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 09:32:42 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XlIgU-0002oH-EP;
	Mon, 03 Nov 2014 14:32:42 +0000
Message-ID: <545791F6.2080809@eu.citrix.com>
Date: Mon, 3 Nov 2014 14:32:22 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de>
In-Reply-To: <20141103142436.GA23458@aepfle.de>
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/2014 02:24 PM, Olaf Hering wrote:
> On Mon, Nov 03, George Dunlap wrote:
>
>> How difficult would it be to have this be something sensible like,
>> "changesets since last tag"?
> Very difficult, because one does changes without commit, runs 'make
> rpmball' and expects that rpm -Fvh *.rpm continues to work.

Right.  Personally, I think trying to make "rpm -Fvh" work for all the 
use cases a developer might want is more hassle than it's worth; as I 
said, I have scripts that just do "rpm -e" in such cases.  I wouldn't 
oppose it, but I don't really support it either.

Ian / Ian / Wei, any thoughts?

  -George

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:48:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIvM-0002VH-VQ; Mon, 03 Nov 2014 14:48:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlIvL-0002V6-14
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 14:48:03 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	BD/70-23865-2A597545; Mon, 03 Nov 2014 14:48:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415026081!11261811!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15402 invoked from network); 3 Nov 2014 14:48:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 14:48:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 14:48:01 +0000
Message-Id: <5457A3AD020000780004478B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 14:47:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH 0/2] lzo: refine overrun checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The original fix we inherited from Linux go re-done. Let's do so too.

1: Revert "lzo: properly check for overruns"
2: lzo: check for length overrun in variable length encoding

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


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:48:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIvH-0002Ux-Iz; Mon, 03 Nov 2014 14:47:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XlIvF-0002Us-W5
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:47:58 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	32/F7-26740-D9597545; Mon, 03 Nov 2014 14:47:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415026076!11261797!1
X-Originating-IP: [81.169.146.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15076 invoked from network); 3 Nov 2014 14:47:56 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 14:47:56 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415026076; l=510;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=03MzGTN6mK/xPruz6wW2MWk1JZY=;
	b=SYZTAD2qHlBXTQ2qImGlVFzM8DWM4FJlwLT8YJpf0AgU1hsxZmwRGHY6N8tZdxbDJ4S
	mRLaOLMYvotIvMyKJ7O+ggs1+Bx+ceIejUaq3vofk0TQ2MRNu0SLBVDb+OPCqW0nbwSlt
	iGZJjRG/fdp/oBK/ABzbYDcaTchkfcfNTpE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id Y0158dqA3ElutBL
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 3 Nov 2014 15:47:56 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 1D5EE50172; Mon,  3 Nov 2014 15:47:56 +0100 (CET)
Date: Mon, 3 Nov 2014 15:47:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141103144755.GA28870@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de>
	<1415024987.24785.13.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415024987.24785.13.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, Nov 03, Ian Campbell wrote:

> On Mon, 2014-11-03 at 15:24 +0100, Olaf Hering wrote:
> > On Mon, Nov 03, George Dunlap wrote:
> > 
> > > How difficult would it be to have this be something sensible like,
> > > "changesets since last tag"?
> > 
> > Very difficult, because one does changes without commit, runs 'make
> > rpmball' and expects that rpm -Fvh *.rpm continues to work.
> 
> Isn't that what "rpm -Uvh" is for?

No, thats for fresh install. -F installs whats already there.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:48:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIvM-0002VH-VQ; Mon, 03 Nov 2014 14:48:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlIvL-0002V6-14
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 14:48:03 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	BD/70-23865-2A597545; Mon, 03 Nov 2014 14:48:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415026081!11261811!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15402 invoked from network); 3 Nov 2014 14:48:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 14:48:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 14:48:01 +0000
Message-Id: <5457A3AD020000780004478B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 14:47:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH 0/2] lzo: refine overrun checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The original fix we inherited from Linux go re-done. Let's do so too.

1: Revert "lzo: properly check for overruns"
2: lzo: check for length overrun in variable length encoding

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


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:48:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIvH-0002Ux-Iz; Mon, 03 Nov 2014 14:47:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XlIvF-0002Us-W5
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:47:58 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	32/F7-26740-D9597545; Mon, 03 Nov 2014 14:47:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415026076!11261797!1
X-Originating-IP: [81.169.146.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15076 invoked from network); 3 Nov 2014 14:47:56 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 14:47:56 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415026076; l=510;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=03MzGTN6mK/xPruz6wW2MWk1JZY=;
	b=SYZTAD2qHlBXTQ2qImGlVFzM8DWM4FJlwLT8YJpf0AgU1hsxZmwRGHY6N8tZdxbDJ4S
	mRLaOLMYvotIvMyKJ7O+ggs1+Bx+ceIejUaq3vofk0TQ2MRNu0SLBVDb+OPCqW0nbwSlt
	iGZJjRG/fdp/oBK/ABzbYDcaTchkfcfNTpE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id Y0158dqA3ElutBL
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 3 Nov 2014 15:47:56 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 1D5EE50172; Mon,  3 Nov 2014 15:47:56 +0100 (CET)
Date: Mon, 3 Nov 2014 15:47:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141103144755.GA28870@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de>
	<1415024987.24785.13.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415024987.24785.13.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, Nov 03, Ian Campbell wrote:

> On Mon, 2014-11-03 at 15:24 +0100, Olaf Hering wrote:
> > On Mon, Nov 03, George Dunlap wrote:
> > 
> > > How difficult would it be to have this be something sensible like,
> > > "changesets since last tag"?
> > 
> > Very difficult, because one does changes without commit, runs 'make
> > rpmball' and expects that rpm -Fvh *.rpm continues to work.
> 
> Isn't that what "rpm -Uvh" is for?

No, thats for fresh install. -F installs whats already there.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:48:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIvr-0002Zo-BT; Mon, 03 Nov 2014 14:48:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlIvq-0002ZR-Ka
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 14:48:34 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	9E/39-19763-1C597545; Mon, 03 Nov 2014 14:48:33 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415026111!10886568!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32748 invoked from network); 3 Nov 2014 14:48:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:48:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188909184"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 09:48:30 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlIvm-0002zr-9x;
	Mon, 03 Nov 2014 14:48:30 +0000
Date: Mon, 3 Nov 2014 14:48:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <21591.36931.244519.373451@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411031447090.22875@kaball.uk.xensource.com>
References: <osstest-31329-mainreport@xen.org>
	<1415007810.9994.3.camel@citrix.com>
	<21591.36931.244519.373451@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CC'ing Konrad and David as this is most probably a problem with Linux.

On Mon, 3 Nov 2014, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL"):
> > Looks like this test hasn't succeeded since 6 October (flight 30603).
> > 
> > Looking over the various failures since then the 
> >  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
> > one has been consistently failing.
> 
> This is the longstanding mptsas swiotlb bug.
> 
> In this particular test case, the migration test source host reports
> lots of swiotlb full messages, first from bnx2 and then from mptsas.
> 
> The first such message is from bnx2 in the middle of guest boot
> (32-bit PV Debian guest).  The guest is booting on the source host,
> and the guest's filesystem is provided via nbd.  The source host has
> the nbd client and the destination host the nbd server.
> 
> I have added `swiotlb=26422' to the host property `install-append
> wheezy' for these two machines.  Hopefully this will either work
> around the problem, or at least provide more information.
 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:48:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIvr-0002Zo-BT; Mon, 03 Nov 2014 14:48:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlIvq-0002ZR-Ka
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 14:48:34 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	9E/39-19763-1C597545; Mon, 03 Nov 2014 14:48:33 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415026111!10886568!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32748 invoked from network); 3 Nov 2014 14:48:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 14:48:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188909184"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 09:48:30 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlIvm-0002zr-9x;
	Mon, 03 Nov 2014 14:48:30 +0000
Date: Mon, 3 Nov 2014 14:48:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <21591.36931.244519.373451@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411031447090.22875@kaball.uk.xensource.com>
References: <osstest-31329-mainreport@xen.org>
	<1415007810.9994.3.camel@citrix.com>
	<21591.36931.244519.373451@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CC'ing Konrad and David as this is most probably a problem with Linux.

On Mon, 3 Nov 2014, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL"):
> > Looks like this test hasn't succeeded since 6 October (flight 30603).
> > 
> > Looking over the various failures since then the 
> >  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
> > one has been consistently failing.
> 
> This is the longstanding mptsas swiotlb bug.
> 
> In this particular test case, the migration test source host reports
> lots of swiotlb full messages, first from bnx2 and then from mptsas.
> 
> The first such message is from bnx2 in the middle of guest boot
> (32-bit PV Debian guest).  The guest is booting on the source host,
> and the guest's filesystem is provided via nbd.  The source host has
> the nbd client and the destination host the nbd server.
> 
> I have added `swiotlb=26422' to the host property `install-append
> wheezy' for these two machines.  Hopefully this will either work
> around the problem, or at least provide more information.
 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:48:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIw8-0002dq-Q0; Mon, 03 Nov 2014 14:48:52 +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 1XlIw7-0002dQ-AI
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:48:51 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	75/B1-29352-2D597545; Mon, 03 Nov 2014 14:48:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415026128!10948586!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTc3MTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTc3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9864 invoked from network); 3 Nov 2014 14:48:49 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 14:48:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415026128; l=735;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=7JcoCaedkHBSZ9TitQFyV1apAsI=;
	b=xgLqDEdpGqh/wsOE+E8ChNdTmiyBdy0wedRJ/MjePSYBEcdy1LYevgVH4AI6EXts5Qr
	hL+hIt92SYGQkEUYqM+sU/YEyA1BblFWkUTvSHFctp3Nmn1+KoxZmMm47ONmKl2QeBGuK
	/zMFbl7UFhPE72jmBTL5IGaVS7y4NMt0Bik=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id i05b2cqA3EmmYme
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 3 Nov 2014 15:48:48 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 884F350172; Mon,  3 Nov 2014 15:48:48 +0100 (CET)
Date: Mon, 3 Nov 2014 15:48:48 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141103144848.GB28870@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545791F6.2080809@eu.citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, Nov 03, George Dunlap wrote:

> On 11/03/2014 02:24 PM, Olaf Hering wrote:
> >On Mon, Nov 03, George Dunlap wrote:
> >
> >>How difficult would it be to have this be something sensible like,
> >>"changesets since last tag"?
> >Very difficult, because one does changes without commit, runs 'make
> >rpmball' and expects that rpm -Fvh *.rpm continues to work.
> 
> Right.  Personally, I think trying to make "rpm -Fvh" work for all the use
> cases a developer might want is more hassle than it's worth; as I said, I
> have scripts that just do "rpm -e" in such cases.  I wouldn't oppose it, but
> I don't really support it either.

What exactly is the hassle here?! Its just some number for the sake of
rpm.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:48:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlIw8-0002dq-Q0; Mon, 03 Nov 2014 14:48:52 +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 1XlIw7-0002dQ-AI
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 14:48:51 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	75/B1-29352-2D597545; Mon, 03 Nov 2014 14:48:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415026128!10948586!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTc3MTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTc3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9864 invoked from network); 3 Nov 2014 14:48:49 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 14:48:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415026128; l=735;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=7JcoCaedkHBSZ9TitQFyV1apAsI=;
	b=xgLqDEdpGqh/wsOE+E8ChNdTmiyBdy0wedRJ/MjePSYBEcdy1LYevgVH4AI6EXts5Qr
	hL+hIt92SYGQkEUYqM+sU/YEyA1BblFWkUTvSHFctp3Nmn1+KoxZmMm47ONmKl2QeBGuK
	/zMFbl7UFhPE72jmBTL5IGaVS7y4NMt0Bik=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id i05b2cqA3EmmYme
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 3 Nov 2014 15:48:48 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 884F350172; Mon,  3 Nov 2014 15:48:48 +0100 (CET)
Date: Mon, 3 Nov 2014 15:48:48 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141103144848.GB28870@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545791F6.2080809@eu.citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, Nov 03, George Dunlap wrote:

> On 11/03/2014 02:24 PM, Olaf Hering wrote:
> >On Mon, Nov 03, George Dunlap wrote:
> >
> >>How difficult would it be to have this be something sensible like,
> >>"changesets since last tag"?
> >Very difficult, because one does changes without commit, runs 'make
> >rpmball' and expects that rpm -Fvh *.rpm continues to work.
> 
> Right.  Personally, I think trying to make "rpm -Fvh" work for all the use
> cases a developer might want is more hassle than it's worth; as I said, I
> have scripts that just do "rpm -e" in such cases.  I wouldn't oppose it, but
> I don't really support it either.

What exactly is the hassle here?! Its just some number for the sake of
rpm.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:58:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:58:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJ5C-0003Q6-Jg; Mon, 03 Nov 2014 14:58:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlJ5C-0003Pt-2Y
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 14:58:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	80/44-24532-50897545; Mon, 03 Nov 2014 14:58:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415026691!12441896!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14671 invoked from network); 3 Nov 2014 14:58:12 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 14:58:12 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3Ew3Rn019118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 14:58:04 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Ew2wY005554
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 14:58:03 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Ew2Dp008608; Mon, 3 Nov 2014 14:58:02 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 06:58:02 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0AF0410FE54; Mon,  3 Nov 2014 09:58:00 -0500 (EST)
Date: Mon, 3 Nov 2014 09:57:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141103145759.GB31846@laptop.dumpdata.com>
References: <osstest-31329-mainreport@xen.org>
	<1415007810.9994.3.camel@citrix.com>
	<21591.36931.244519.373451@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1411031447090.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411031447090.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 02:48:25PM +0000, Stefano Stabellini wrote:
> CC'ing Konrad and David as this is most probably a problem with Linux.

Yeah. And David posted a patch for this - but it hasn't been reposted
(it needs a compile fix).
> 
> On Mon, 3 Nov 2014, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL"):
> > > Looks like this test hasn't succeeded since 6 October (flight 30603).
> > > 
> > > Looking over the various failures since then the 
> > >  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
> > > one has been consistently failing.
> > 
> > This is the longstanding mptsas swiotlb bug.
> > 
> > In this particular test case, the migration test source host reports
> > lots of swiotlb full messages, first from bnx2 and then from mptsas.
> > 
> > The first such message is from bnx2 in the middle of guest boot
> > (32-bit PV Debian guest).  The guest is booting on the source host,
> > and the guest's filesystem is provided via nbd.  The source host has
> > the nbd client and the destination host the nbd server.
> > 
> > I have added `swiotlb=26422' to the host property `install-append
> > wheezy' for these two machines.  Hopefully this will either work
> > around the problem, or at least provide more information.
>  

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 14:58:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 14:58:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJ5C-0003Q6-Jg; Mon, 03 Nov 2014 14:58:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlJ5C-0003Pt-2Y
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 14:58:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	80/44-24532-50897545; Mon, 03 Nov 2014 14:58:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415026691!12441896!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14671 invoked from network); 3 Nov 2014 14:58:12 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 14:58:12 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3Ew3Rn019118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 14:58:04 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Ew2wY005554
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 14:58:03 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Ew2Dp008608; Mon, 3 Nov 2014 14:58:02 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 06:58:02 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0AF0410FE54; Mon,  3 Nov 2014 09:58:00 -0500 (EST)
Date: Mon, 3 Nov 2014 09:57:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141103145759.GB31846@laptop.dumpdata.com>
References: <osstest-31329-mainreport@xen.org>
	<1415007810.9994.3.camel@citrix.com>
	<21591.36931.244519.373451@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1411031447090.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411031447090.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 02:48:25PM +0000, Stefano Stabellini wrote:
> CC'ing Konrad and David as this is most probably a problem with Linux.

Yeah. And David posted a patch for this - but it hasn't been reposted
(it needs a compile fix).
> 
> On Mon, 3 Nov 2014, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL"):
> > > Looks like this test hasn't succeeded since 6 October (flight 30603).
> > > 
> > > Looking over the various failures since then the 
> > >  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
> > > one has been consistently failing.
> > 
> > This is the longstanding mptsas swiotlb bug.
> > 
> > In this particular test case, the migration test source host reports
> > lots of swiotlb full messages, first from bnx2 and then from mptsas.
> > 
> > The first such message is from bnx2 in the middle of guest boot
> > (32-bit PV Debian guest).  The guest is booting on the source host,
> > and the guest's filesystem is provided via nbd.  The source host has
> > the nbd client and the destination host the nbd server.
> > 
> > I have added `swiotlb=26422' to the host property `install-append
> > wheezy' for these two machines.  Hopefully this will either work
> > around the problem, or at least provide more information.
>  

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:00:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJ70-0003Yq-4i; Mon, 03 Nov 2014 15:00:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1XlJ6y-0003Yc-Ck
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:00:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	54/CD-09936-37897545; Mon, 03 Nov 2014 15:00:03 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415026802!12410231!1
X-Originating-IP: [209.85.216.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3973 invoked from network); 3 Nov 2014 15:00:03 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:00:03 -0000
Received: by mail-qc0-f169.google.com with SMTP id i17so9315598qcy.14
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 07:00:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=SIfBWGjeXl8Wa+EHPJ029/wlvST9WMtjcoHwin2W7bY=;
	b=I28myR5rJyIGERl9WdivLnwyXvLYGMTjXFZxQy/L6Ti5TLOZOCa0dSK/9jIVW5zCrn
	CKk6fm8eUA/N5/ZvsGuXGaGKKRKmH8rgxPYxTXkq5h+WwktXu5ow266Ls5w22a30pZFa
	IM4ke1QzKVt9cmeYqRo0K+LP7f3oUnp44XsaF0bw8gm2FY2R0oFKPBidrK7MiGPXHj4k
	SQkwsAZUTuXU4DnIuaxmdMeYzvtz8tjJpS/RacQe56+cyU/mc3a9KKjjXUrbTOajppOM
	pxaXqCWJrFDt3LwYGG+MYJqmGlaQKsxXIPdEqVm1ZS9OWE5C7UMsErxKFu2ky2NpIUyR
	EfPw==
X-Gm-Message-State: ALoCoQmhAkJaZNHSAzD/WokL2mfubh8CUJcXCpgeR/K9ojxcWirPD0nrO9dOq0ExGHPuuwySKdbW
X-Received: by 10.224.65.133 with SMTP id j5mr47997520qai.96.1415026801970;
	Mon, 03 Nov 2014 07:00:01 -0800 (PST)
Received: from localhost
	(207-172-170-53.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.170.53])
	by mx.google.com with ESMTPSA id w8sm17062015qag.2.2014.11.03.06.59.59
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 07:00:00 -0800 (PST)
Date: Mon, 3 Nov 2014 09:59:59 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141103145958.GA27850@morn.localdomain>
References: <1415008770.9994.6.camel@citrix.com>
	<1415009105.9994.8.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415009105.9994.8.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: seabios@seabios.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS]  Regression booting winxp under Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 10:05:05AM +0000, Ian Campbell wrote:
> On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:
> 
> > I've not investigated more thoroughly yes, just posting in case
> > something obvious leaps out at someone. The automated test is currently
> > bisecting the issue, once it is done I'll let you know the result.
> 
> If I'd read a bit further through my Monday morning INBOX I'd have
> found:
>         http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
>         
> which indicates that the bisector has fingered:
> 
>   commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f

Sorry about that - I missed one of the stack offset conversions in the
PNP part of that change.  The fix is below and I just pushed it to
the main repo.

Thanks for catching it.
-Kevin


--- a/src/romlayout.S
+++ b/src/romlayout.S
@@ -286,7 +286,7 @@ entry_pnp_real:
         movw %cx, %ds
         leal BREGS_size-6+12(%esp), %eax  // %eax points to start of u16 args
         calll handle_pnp
-        movw %ax, 12(%esp)      // Modify %eax to return %ax
+        movw %ax, BREGS_eax(%esp)   // Modify %eax to return %ax
         POPBREGS
         popfl
         popl %esp

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:00:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJ70-0003Yq-4i; Mon, 03 Nov 2014 15:00:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1XlJ6y-0003Yc-Ck
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:00:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	54/CD-09936-37897545; Mon, 03 Nov 2014 15:00:03 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415026802!12410231!1
X-Originating-IP: [209.85.216.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3973 invoked from network); 3 Nov 2014 15:00:03 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:00:03 -0000
Received: by mail-qc0-f169.google.com with SMTP id i17so9315598qcy.14
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 07:00:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=SIfBWGjeXl8Wa+EHPJ029/wlvST9WMtjcoHwin2W7bY=;
	b=I28myR5rJyIGERl9WdivLnwyXvLYGMTjXFZxQy/L6Ti5TLOZOCa0dSK/9jIVW5zCrn
	CKk6fm8eUA/N5/ZvsGuXGaGKKRKmH8rgxPYxTXkq5h+WwktXu5ow266Ls5w22a30pZFa
	IM4ke1QzKVt9cmeYqRo0K+LP7f3oUnp44XsaF0bw8gm2FY2R0oFKPBidrK7MiGPXHj4k
	SQkwsAZUTuXU4DnIuaxmdMeYzvtz8tjJpS/RacQe56+cyU/mc3a9KKjjXUrbTOajppOM
	pxaXqCWJrFDt3LwYGG+MYJqmGlaQKsxXIPdEqVm1ZS9OWE5C7UMsErxKFu2ky2NpIUyR
	EfPw==
X-Gm-Message-State: ALoCoQmhAkJaZNHSAzD/WokL2mfubh8CUJcXCpgeR/K9ojxcWirPD0nrO9dOq0ExGHPuuwySKdbW
X-Received: by 10.224.65.133 with SMTP id j5mr47997520qai.96.1415026801970;
	Mon, 03 Nov 2014 07:00:01 -0800 (PST)
Received: from localhost
	(207-172-170-53.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.170.53])
	by mx.google.com with ESMTPSA id w8sm17062015qag.2.2014.11.03.06.59.59
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 07:00:00 -0800 (PST)
Date: Mon, 3 Nov 2014 09:59:59 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141103145958.GA27850@morn.localdomain>
References: <1415008770.9994.6.camel@citrix.com>
	<1415009105.9994.8.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415009105.9994.8.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: seabios@seabios.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS]  Regression booting winxp under Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 10:05:05AM +0000, Ian Campbell wrote:
> On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:
> 
> > I've not investigated more thoroughly yes, just posting in case
> > something obvious leaps out at someone. The automated test is currently
> > bisecting the issue, once it is done I'll let you know the result.
> 
> If I'd read a bit further through my Monday morning INBOX I'd have
> found:
>         http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
>         
> which indicates that the bisector has fingered:
> 
>   commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f

Sorry about that - I missed one of the stack offset conversions in the
PNP part of that change.  The fix is below and I just pushed it to
the main repo.

Thanks for catching it.
-Kevin


--- a/src/romlayout.S
+++ b/src/romlayout.S
@@ -286,7 +286,7 @@ entry_pnp_real:
         movw %cx, %ds
         leal BREGS_size-6+12(%esp), %eax  // %eax points to start of u16 args
         calll handle_pnp
-        movw %ax, 12(%esp)      // Modify %eax to return %ax
+        movw %ax, BREGS_eax(%esp)   // Modify %eax to return %ax
         POPBREGS
         popfl
         popl %esp

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:01:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:01:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJ83-0003ej-Ks; Mon, 03 Nov 2014 15:01:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlJ81-0003eY-TM
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 15:01:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A8/B3-09842-5B897545; Mon, 03 Nov 2014 15:01:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415026868!12397543!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26021 invoked from network); 3 Nov 2014 15:01:08 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 15:01:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 15:01:08 +0000
Message-Id: <5457A6C002000078000447A2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 15:01:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen.org" <Ian.Jackson@eu.citrix.com>
References: <osstest-31329-mainreport@xen.org>
	<1415007810.9994.3.camel@citrix.com>
	<21591.36931.244519.373451@mariner.uk.xensource.com>
In-Reply-To: <21591.36931.244519.373451@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 15:25, <Ian.Jackson@eu.citrix.com> wrote:
> Ian Campbell writes ("Re: [Xen-devel] [qemu-mainline test] 31329: regressions - 
> FAIL"):
>> Looks like this test hasn't succeeded since 6 October (flight 30603).
>> 
>> Looking over the various failures since then the 
>>  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
>> one has been consistently failing.
> 
> This is the longstanding mptsas swiotlb bug.

And this is also - as I realized when reading this reply of yours - the
reason for the recent failures of the same test in the 4.2 tree.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:01:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:01:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJ83-0003ej-Ks; Mon, 03 Nov 2014 15:01:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlJ81-0003eY-TM
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 15:01:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A8/B3-09842-5B897545; Mon, 03 Nov 2014 15:01:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415026868!12397543!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26021 invoked from network); 3 Nov 2014 15:01:08 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 15:01:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 15:01:08 +0000
Message-Id: <5457A6C002000078000447A2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 15:01:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen.org" <Ian.Jackson@eu.citrix.com>
References: <osstest-31329-mainreport@xen.org>
	<1415007810.9994.3.camel@citrix.com>
	<21591.36931.244519.373451@mariner.uk.xensource.com>
In-Reply-To: <21591.36931.244519.373451@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline test] 31329: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 15:25, <Ian.Jackson@eu.citrix.com> wrote:
> Ian Campbell writes ("Re: [Xen-devel] [qemu-mainline test] 31329: regressions - 
> FAIL"):
>> Looks like this test hasn't succeeded since 6 October (flight 30603).
>> 
>> Looking over the various failures since then the 
>>  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
>> one has been consistently failing.
> 
> This is the longstanding mptsas swiotlb bug.

And this is also - as I realized when reading this reply of yours - the
reason for the recent failures of the same test in the 4.2 tree.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:02:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJ8w-0003li-3W; Mon, 03 Nov 2014 15:02:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlJ8v-0003lW-0h
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 15:02:05 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	CF/21-31453-CE897545; Mon, 03 Nov 2014 15:02:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415026921!10899909!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19267 invoked from network); 3 Nov 2014 15:02:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 15:02:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 15:02:01 +0000
Message-Id: <5457A6F702000078000447A6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 15:01:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <5457A3AD020000780004478B@mail.emea.novell.com>
In-Reply-To: <5457A3AD020000780004478B@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part04310AF7.1__="
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH 1/2] Revert "lzo: properly check for overruns"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

This reverts commit 504f70b6 ("lzo: properly check for overruns").

As analysed by Willem Pinckaers, this fix is still incomplete on
certain rare corner cases, and it is easier to restart from the
original code.

Reported-by: Willem Pinckaers <willem@lekkertech.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
[original Linux commit: af958a38]
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/lzo.c
+++ b/xen/common/lzo.c
@@ -375,31 +375,11 @@ int lzo1x_1_compress(const unsigned char
  *  Richard Purdie <rpurdie@openedhand.com>
  */
=20
-#define HAVE_IP(t, x)                              \
-    (((size_t)(ip_end - ip) >=3D (size_t)(t + x)) && \
-     (((t + x) >=3D t) && ((t + x) >=3D x)))
-
-#define HAVE_OP(t, x)                              \
-    (((size_t)(op_end - op) >=3D (size_t)(t + x)) && \
-     (((t + x) >=3D t) && ((t + x) >=3D x)))
-
-#define NEED_IP(t, x)                \
-    do {                             \
-        if (!HAVE_IP(t, x))          \
-            goto input_overrun;      \
-    } while (0)
-
-#define NEED_OP(t, x)                \
-    do {                             \
-        if (!HAVE_OP(t, x))          \
-            goto output_overrun;     \
-    } while (0)
-
-#define TEST_LB(m_pos)               \
-    do {                             \
-        if ((m_pos) < out)           \
-            goto lookbehind_overrun; \
-    } while (0)
+#define HAVE_IP(x)     ((size_t)(ip_end - ip) >=3D (size_t)(x))
+#define HAVE_OP(x)     ((size_t)(op_end - op) >=3D (size_t)(x))
+#define NEED_IP(x)     if (!HAVE_IP(x)) goto input_overrun
+#define NEED_OP(x)     if (!HAVE_OP(x)) goto output_overrun
+#define TEST_LB(m_pos) if ((m_pos) < out) goto lookbehind_overrun
=20
 int lzo1x_decompress_safe(const unsigned char *in, size_t in_len,
                           unsigned char *out, size_t *out_len)
@@ -434,14 +414,14 @@ int lzo1x_decompress_safe(const unsigned
                     while (unlikely(*ip =3D=3D 0)) {
                         t +=3D 255;
                         ip++;
-                        NEED_IP(1, 0);
+                        NEED_IP(1);
                     }
                     t +=3D 15 + *ip++;
                 }
                 t +=3D 3;
  copy_literal_run:
 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
-                if (likely(HAVE_IP(t, 15) && HAVE_OP(t, 15))) {
+                if (likely(HAVE_IP(t + 15) && HAVE_OP(t + 15))) {
                     const unsigned char *ie =3D ip + t;
                     unsigned char *oe =3D op + t;
                     do {
@@ -457,8 +437,8 @@ int lzo1x_decompress_safe(const unsigned
                 } else
 #endif
                 {
-                    NEED_OP(t, 0);
-                    NEED_IP(t, 3);
+                    NEED_OP(t);
+                    NEED_IP(t + 3);
                     do {
                         *op++ =3D *ip++;
                     } while (--t > 0);
@@ -471,7 +451,7 @@ int lzo1x_decompress_safe(const unsigned
                 m_pos -=3D t >> 2;
                 m_pos -=3D *ip++ << 2;
                 TEST_LB(m_pos);
-                NEED_OP(2, 0);
+                NEED_OP(2);
                 op[0] =3D m_pos[0];
                 op[1] =3D m_pos[1];
                 op +=3D 2;
@@ -495,10 +475,10 @@ int lzo1x_decompress_safe(const unsigned
                 while (unlikely(*ip =3D=3D 0)) {
                     t +=3D 255;
                     ip++;
-                    NEED_IP(1, 0);
+                    NEED_IP(1);
                 }
                 t +=3D 31 + *ip++;
-                NEED_IP(2, 0);
+                NEED_IP(2);
             }
             m_pos =3D op - 1;
             next =3D get_unaligned_le16(ip);
@@ -513,10 +493,10 @@ int lzo1x_decompress_safe(const unsigned
                 while (unlikely(*ip =3D=3D 0)) {
                     t +=3D 255;
                     ip++;
-                    NEED_IP(1, 0);
+                    NEED_IP(1);
                 }
                 t +=3D 7 + *ip++;
-                NEED_IP(2, 0);
+                NEED_IP(2);
             }
             next =3D get_unaligned_le16(ip);
             ip +=3D 2;
@@ -530,7 +510,7 @@ int lzo1x_decompress_safe(const unsigned
 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
         if (op - m_pos >=3D 8) {
             unsigned char *oe =3D op + t;
-            if (likely(HAVE_OP(t, 15))) {
+            if (likely(HAVE_OP(t + 15))) {
                 do {
                     COPY8(op, m_pos);
                     op +=3D 8;
@@ -540,7 +520,7 @@ int lzo1x_decompress_safe(const unsigned
                     m_pos +=3D 8;
                 } while (op < oe);
                 op =3D oe;
-                if (HAVE_IP(6, 0)) {
+                if (HAVE_IP(6)) {
                     state =3D next;
                     COPY4(op, ip);
                     op +=3D next;
@@ -548,7 +528,7 @@ int lzo1x_decompress_safe(const unsigned
                     continue;
                 }
             } else {
-                NEED_OP(t, 0);
+                NEED_OP(t);
                 do {
                     *op++ =3D *m_pos++;
                 } while (op < oe);
@@ -557,7 +537,7 @@ int lzo1x_decompress_safe(const unsigned
 #endif
         {
             unsigned char *oe =3D op + t;
-            NEED_OP(t, 0);
+            NEED_OP(t);
             op[0] =3D m_pos[0];
             op[1] =3D m_pos[1];
             op +=3D 2;
@@ -570,15 +550,15 @@ int lzo1x_decompress_safe(const unsigned
         state =3D next;
         t =3D next;
 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
-        if (likely(HAVE_IP(6, 0) && HAVE_OP(4, 0))) {
+        if (likely(HAVE_IP(6) && HAVE_OP(4))) {
             COPY4(op, ip);
             op +=3D t;
             ip +=3D t;
         } else
 #endif
         {
-            NEED_IP(t, 3);
-            NEED_OP(t, 0);
+            NEED_IP(t + 3);
+            NEED_OP(t);
             while (t > 0) {
                 *op++ =3D *ip++;
                 t--;



--=__Part04310AF7.1__=
Content-Type: text/plain; name="lzo-revert-504f70b6.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="lzo-revert-504f70b6.patch"

Revert "lzo: properly check for overruns"=0A=0AThis reverts commit =
504f70b6 ("lzo: properly check for overruns").=0A=0AAs analysed by Willem =
Pinckaers, this fix is still incomplete on=0Acertain rare corner cases, =
and it is easier to restart from the=0Aoriginal code.=0A=0AReported-by: =
Willem Pinckaers <willem@lekkertech.net>=0ASigned-off-by: Willy Tarreau =
<w@1wt.eu>=0A[original Linux commit: af958a38]=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/lzo.c=0A+++ b/xen/common/=
lzo.c=0A@@ -375,31 +375,11 @@ int lzo1x_1_compress(const unsigned char=0A  =
*  Richard Purdie <rpurdie@openedhand.com>=0A  */=0A =0A-#define HAVE_IP(t,=
 x)                              \=0A-    (((size_t)(ip_end - ip) >=3D =
(size_t)(t + x)) && \=0A-     (((t + x) >=3D t) && ((t + x) >=3D =
x)))=0A-=0A-#define HAVE_OP(t, x)                              \=0A-    =
(((size_t)(op_end - op) >=3D (size_t)(t + x)) && \=0A-     (((t + x) >=3D =
t) && ((t + x) >=3D x)))=0A-=0A-#define NEED_IP(t, x)                \=0A- =
   do {                             \=0A-        if (!HAVE_IP(t, x))       =
   \=0A-            goto input_overrun;      \=0A-    } while (0)=0A-=0A-#d=
efine NEED_OP(t, x)                \=0A-    do {                           =
  \=0A-        if (!HAVE_OP(t, x))          \=0A-            goto =
output_overrun;     \=0A-    } while (0)=0A-=0A-#define TEST_LB(m_pos)     =
          \=0A-    do {                             \=0A-        if =
((m_pos) < out)           \=0A-            goto lookbehind_overrun; \=0A-  =
  } while (0)=0A+#define HAVE_IP(x)     ((size_t)(ip_end - ip) >=3D =
(size_t)(x))=0A+#define HAVE_OP(x)     ((size_t)(op_end - op) >=3D =
(size_t)(x))=0A+#define NEED_IP(x)     if (!HAVE_IP(x)) goto input_overrun=
=0A+#define NEED_OP(x)     if (!HAVE_OP(x)) goto output_overrun=0A+#define =
TEST_LB(m_pos) if ((m_pos) < out) goto lookbehind_overrun=0A =0A int =
lzo1x_decompress_safe(const unsigned char *in, size_t in_len,=0A           =
                unsigned char *out, size_t *out_len)=0A@@ -434,14 +414,14 =
@@ int lzo1x_decompress_safe(const unsigned=0A                     while =
(unlikely(*ip =3D=3D 0)) {=0A                         t +=3D 255;=0A       =
                  ip++;=0A-                        NEED_IP(1, 0);=0A+      =
                  NEED_IP(1);=0A                     }=0A                  =
   t +=3D 15 + *ip++;=0A                 }=0A                 t +=3D 3;=0A =
 copy_literal_run:=0A #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)=
=0A-                if (likely(HAVE_IP(t, 15) && HAVE_OP(t, 15))) {=0A+    =
            if (likely(HAVE_IP(t + 15) && HAVE_OP(t + 15))) {=0A           =
          const unsigned char *ie =3D ip + t;=0A                     =
unsigned char *oe =3D op + t;=0A                     do {=0A@@ -457,8 =
+437,8 @@ int lzo1x_decompress_safe(const unsigned=0A                 } =
else=0A #endif=0A                 {=0A-                    NEED_OP(t, =
0);=0A-                    NEED_IP(t, 3);=0A+                    NEED_OP(t)=
;=0A+                    NEED_IP(t + 3);=0A                     do {=0A    =
                     *op++ =3D *ip++;=0A                     } while (--t =
> 0);=0A@@ -471,7 +451,7 @@ int lzo1x_decompress_safe(const unsigned=0A    =
             m_pos -=3D t >> 2;=0A                 m_pos -=3D *ip++ << =
2;=0A                 TEST_LB(m_pos);=0A-                NEED_OP(2, =
0);=0A+                NEED_OP(2);=0A                 op[0] =3D =
m_pos[0];=0A                 op[1] =3D m_pos[1];=0A                 op =
+=3D 2;=0A@@ -495,10 +475,10 @@ int lzo1x_decompress_safe(const unsigned=0A=
                 while (unlikely(*ip =3D=3D 0)) {=0A                     t =
+=3D 255;=0A                     ip++;=0A-                    NEED_IP(1, =
0);=0A+                    NEED_IP(1);=0A                 }=0A             =
    t +=3D 31 + *ip++;=0A-                NEED_IP(2, 0);=0A+               =
 NEED_IP(2);=0A             }=0A             m_pos =3D op - 1;=0A          =
   next =3D get_unaligned_le16(ip);=0A@@ -513,10 +493,10 @@ int lzo1x_decom=
press_safe(const unsigned=0A                 while (unlikely(*ip =3D=3D =
0)) {=0A                     t +=3D 255;=0A                     ip++;=0A-  =
                  NEED_IP(1, 0);=0A+                    NEED_IP(1);=0A     =
            }=0A                 t +=3D 7 + *ip++;=0A-                =
NEED_IP(2, 0);=0A+                NEED_IP(2);=0A             }=0A          =
   next =3D get_unaligned_le16(ip);=0A             ip +=3D 2;=0A@@ -530,7 =
+510,7 @@ int lzo1x_decompress_safe(const unsigned=0A #if defined(CONFIG_HA=
VE_EFFICIENT_UNALIGNED_ACCESS)=0A         if (op - m_pos >=3D 8) {=0A      =
       unsigned char *oe =3D op + t;=0A-            if (likely(HAVE_OP(t, =
15))) {=0A+            if (likely(HAVE_OP(t + 15))) {=0A                 =
do {=0A                     COPY8(op, m_pos);=0A                     op =
+=3D 8;=0A@@ -540,7 +520,7 @@ int lzo1x_decompress_safe(const unsigned=0A  =
                   m_pos +=3D 8;=0A                 } while (op < oe);=0A  =
               op =3D oe;=0A-                if (HAVE_IP(6, 0)) {=0A+      =
          if (HAVE_IP(6)) {=0A                     state =3D next;=0A      =
               COPY4(op, ip);=0A                     op +=3D next;=0A@@ =
-548,7 +528,7 @@ int lzo1x_decompress_safe(const unsigned=0A               =
      continue;=0A                 }=0A             } else {=0A-           =
     NEED_OP(t, 0);=0A+                NEED_OP(t);=0A                 do =
{=0A                     *op++ =3D *m_pos++;=0A                 } while =
(op < oe);=0A@@ -557,7 +537,7 @@ int lzo1x_decompress_safe(const =
unsigned=0A #endif=0A         {=0A             unsigned char *oe =3D op + =
t;=0A-            NEED_OP(t, 0);=0A+            NEED_OP(t);=0A             =
op[0] =3D m_pos[0];=0A             op[1] =3D m_pos[1];=0A             op =
+=3D 2;=0A@@ -570,15 +550,15 @@ int lzo1x_decompress_safe(const unsigned=0A=
         state =3D next;=0A         t =3D next;=0A #if defined(CONFIG_HAVE_=
EFFICIENT_UNALIGNED_ACCESS)=0A-        if (likely(HAVE_IP(6, 0) && =
HAVE_OP(4, 0))) {=0A+        if (likely(HAVE_IP(6) && HAVE_OP(4))) {=0A    =
         COPY4(op, ip);=0A             op +=3D t;=0A             ip +=3D =
t;=0A         } else=0A #endif=0A         {=0A-            NEED_IP(t, =
3);=0A-            NEED_OP(t, 0);=0A+            NEED_IP(t + 3);=0A+       =
     NEED_OP(t);=0A             while (t > 0) {=0A                 *op++ =
=3D *ip++;=0A                 t--;=0A
--=__Part04310AF7.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

--=__Part04310AF7.1__=--


From xen-devel-bounces@lists.xen.org Mon Nov 03 15:02:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJ8w-0003li-3W; Mon, 03 Nov 2014 15:02:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlJ8v-0003lW-0h
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 15:02:05 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	CF/21-31453-CE897545; Mon, 03 Nov 2014 15:02:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415026921!10899909!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19267 invoked from network); 3 Nov 2014 15:02:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 15:02:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 15:02:01 +0000
Message-Id: <5457A6F702000078000447A6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 15:01:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <5457A3AD020000780004478B@mail.emea.novell.com>
In-Reply-To: <5457A3AD020000780004478B@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part04310AF7.1__="
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH 1/2] Revert "lzo: properly check for overruns"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

This reverts commit 504f70b6 ("lzo: properly check for overruns").

As analysed by Willem Pinckaers, this fix is still incomplete on
certain rare corner cases, and it is easier to restart from the
original code.

Reported-by: Willem Pinckaers <willem@lekkertech.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
[original Linux commit: af958a38]
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/lzo.c
+++ b/xen/common/lzo.c
@@ -375,31 +375,11 @@ int lzo1x_1_compress(const unsigned char
  *  Richard Purdie <rpurdie@openedhand.com>
  */
=20
-#define HAVE_IP(t, x)                              \
-    (((size_t)(ip_end - ip) >=3D (size_t)(t + x)) && \
-     (((t + x) >=3D t) && ((t + x) >=3D x)))
-
-#define HAVE_OP(t, x)                              \
-    (((size_t)(op_end - op) >=3D (size_t)(t + x)) && \
-     (((t + x) >=3D t) && ((t + x) >=3D x)))
-
-#define NEED_IP(t, x)                \
-    do {                             \
-        if (!HAVE_IP(t, x))          \
-            goto input_overrun;      \
-    } while (0)
-
-#define NEED_OP(t, x)                \
-    do {                             \
-        if (!HAVE_OP(t, x))          \
-            goto output_overrun;     \
-    } while (0)
-
-#define TEST_LB(m_pos)               \
-    do {                             \
-        if ((m_pos) < out)           \
-            goto lookbehind_overrun; \
-    } while (0)
+#define HAVE_IP(x)     ((size_t)(ip_end - ip) >=3D (size_t)(x))
+#define HAVE_OP(x)     ((size_t)(op_end - op) >=3D (size_t)(x))
+#define NEED_IP(x)     if (!HAVE_IP(x)) goto input_overrun
+#define NEED_OP(x)     if (!HAVE_OP(x)) goto output_overrun
+#define TEST_LB(m_pos) if ((m_pos) < out) goto lookbehind_overrun
=20
 int lzo1x_decompress_safe(const unsigned char *in, size_t in_len,
                           unsigned char *out, size_t *out_len)
@@ -434,14 +414,14 @@ int lzo1x_decompress_safe(const unsigned
                     while (unlikely(*ip =3D=3D 0)) {
                         t +=3D 255;
                         ip++;
-                        NEED_IP(1, 0);
+                        NEED_IP(1);
                     }
                     t +=3D 15 + *ip++;
                 }
                 t +=3D 3;
  copy_literal_run:
 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
-                if (likely(HAVE_IP(t, 15) && HAVE_OP(t, 15))) {
+                if (likely(HAVE_IP(t + 15) && HAVE_OP(t + 15))) {
                     const unsigned char *ie =3D ip + t;
                     unsigned char *oe =3D op + t;
                     do {
@@ -457,8 +437,8 @@ int lzo1x_decompress_safe(const unsigned
                 } else
 #endif
                 {
-                    NEED_OP(t, 0);
-                    NEED_IP(t, 3);
+                    NEED_OP(t);
+                    NEED_IP(t + 3);
                     do {
                         *op++ =3D *ip++;
                     } while (--t > 0);
@@ -471,7 +451,7 @@ int lzo1x_decompress_safe(const unsigned
                 m_pos -=3D t >> 2;
                 m_pos -=3D *ip++ << 2;
                 TEST_LB(m_pos);
-                NEED_OP(2, 0);
+                NEED_OP(2);
                 op[0] =3D m_pos[0];
                 op[1] =3D m_pos[1];
                 op +=3D 2;
@@ -495,10 +475,10 @@ int lzo1x_decompress_safe(const unsigned
                 while (unlikely(*ip =3D=3D 0)) {
                     t +=3D 255;
                     ip++;
-                    NEED_IP(1, 0);
+                    NEED_IP(1);
                 }
                 t +=3D 31 + *ip++;
-                NEED_IP(2, 0);
+                NEED_IP(2);
             }
             m_pos =3D op - 1;
             next =3D get_unaligned_le16(ip);
@@ -513,10 +493,10 @@ int lzo1x_decompress_safe(const unsigned
                 while (unlikely(*ip =3D=3D 0)) {
                     t +=3D 255;
                     ip++;
-                    NEED_IP(1, 0);
+                    NEED_IP(1);
                 }
                 t +=3D 7 + *ip++;
-                NEED_IP(2, 0);
+                NEED_IP(2);
             }
             next =3D get_unaligned_le16(ip);
             ip +=3D 2;
@@ -530,7 +510,7 @@ int lzo1x_decompress_safe(const unsigned
 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
         if (op - m_pos >=3D 8) {
             unsigned char *oe =3D op + t;
-            if (likely(HAVE_OP(t, 15))) {
+            if (likely(HAVE_OP(t + 15))) {
                 do {
                     COPY8(op, m_pos);
                     op +=3D 8;
@@ -540,7 +520,7 @@ int lzo1x_decompress_safe(const unsigned
                     m_pos +=3D 8;
                 } while (op < oe);
                 op =3D oe;
-                if (HAVE_IP(6, 0)) {
+                if (HAVE_IP(6)) {
                     state =3D next;
                     COPY4(op, ip);
                     op +=3D next;
@@ -548,7 +528,7 @@ int lzo1x_decompress_safe(const unsigned
                     continue;
                 }
             } else {
-                NEED_OP(t, 0);
+                NEED_OP(t);
                 do {
                     *op++ =3D *m_pos++;
                 } while (op < oe);
@@ -557,7 +537,7 @@ int lzo1x_decompress_safe(const unsigned
 #endif
         {
             unsigned char *oe =3D op + t;
-            NEED_OP(t, 0);
+            NEED_OP(t);
             op[0] =3D m_pos[0];
             op[1] =3D m_pos[1];
             op +=3D 2;
@@ -570,15 +550,15 @@ int lzo1x_decompress_safe(const unsigned
         state =3D next;
         t =3D next;
 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
-        if (likely(HAVE_IP(6, 0) && HAVE_OP(4, 0))) {
+        if (likely(HAVE_IP(6) && HAVE_OP(4))) {
             COPY4(op, ip);
             op +=3D t;
             ip +=3D t;
         } else
 #endif
         {
-            NEED_IP(t, 3);
-            NEED_OP(t, 0);
+            NEED_IP(t + 3);
+            NEED_OP(t);
             while (t > 0) {
                 *op++ =3D *ip++;
                 t--;



--=__Part04310AF7.1__=
Content-Type: text/plain; name="lzo-revert-504f70b6.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="lzo-revert-504f70b6.patch"

Revert "lzo: properly check for overruns"=0A=0AThis reverts commit =
504f70b6 ("lzo: properly check for overruns").=0A=0AAs analysed by Willem =
Pinckaers, this fix is still incomplete on=0Acertain rare corner cases, =
and it is easier to restart from the=0Aoriginal code.=0A=0AReported-by: =
Willem Pinckaers <willem@lekkertech.net>=0ASigned-off-by: Willy Tarreau =
<w@1wt.eu>=0A[original Linux commit: af958a38]=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/lzo.c=0A+++ b/xen/common/=
lzo.c=0A@@ -375,31 +375,11 @@ int lzo1x_1_compress(const unsigned char=0A  =
*  Richard Purdie <rpurdie@openedhand.com>=0A  */=0A =0A-#define HAVE_IP(t,=
 x)                              \=0A-    (((size_t)(ip_end - ip) >=3D =
(size_t)(t + x)) && \=0A-     (((t + x) >=3D t) && ((t + x) >=3D =
x)))=0A-=0A-#define HAVE_OP(t, x)                              \=0A-    =
(((size_t)(op_end - op) >=3D (size_t)(t + x)) && \=0A-     (((t + x) >=3D =
t) && ((t + x) >=3D x)))=0A-=0A-#define NEED_IP(t, x)                \=0A- =
   do {                             \=0A-        if (!HAVE_IP(t, x))       =
   \=0A-            goto input_overrun;      \=0A-    } while (0)=0A-=0A-#d=
efine NEED_OP(t, x)                \=0A-    do {                           =
  \=0A-        if (!HAVE_OP(t, x))          \=0A-            goto =
output_overrun;     \=0A-    } while (0)=0A-=0A-#define TEST_LB(m_pos)     =
          \=0A-    do {                             \=0A-        if =
((m_pos) < out)           \=0A-            goto lookbehind_overrun; \=0A-  =
  } while (0)=0A+#define HAVE_IP(x)     ((size_t)(ip_end - ip) >=3D =
(size_t)(x))=0A+#define HAVE_OP(x)     ((size_t)(op_end - op) >=3D =
(size_t)(x))=0A+#define NEED_IP(x)     if (!HAVE_IP(x)) goto input_overrun=
=0A+#define NEED_OP(x)     if (!HAVE_OP(x)) goto output_overrun=0A+#define =
TEST_LB(m_pos) if ((m_pos) < out) goto lookbehind_overrun=0A =0A int =
lzo1x_decompress_safe(const unsigned char *in, size_t in_len,=0A           =
                unsigned char *out, size_t *out_len)=0A@@ -434,14 +414,14 =
@@ int lzo1x_decompress_safe(const unsigned=0A                     while =
(unlikely(*ip =3D=3D 0)) {=0A                         t +=3D 255;=0A       =
                  ip++;=0A-                        NEED_IP(1, 0);=0A+      =
                  NEED_IP(1);=0A                     }=0A                  =
   t +=3D 15 + *ip++;=0A                 }=0A                 t +=3D 3;=0A =
 copy_literal_run:=0A #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)=
=0A-                if (likely(HAVE_IP(t, 15) && HAVE_OP(t, 15))) {=0A+    =
            if (likely(HAVE_IP(t + 15) && HAVE_OP(t + 15))) {=0A           =
          const unsigned char *ie =3D ip + t;=0A                     =
unsigned char *oe =3D op + t;=0A                     do {=0A@@ -457,8 =
+437,8 @@ int lzo1x_decompress_safe(const unsigned=0A                 } =
else=0A #endif=0A                 {=0A-                    NEED_OP(t, =
0);=0A-                    NEED_IP(t, 3);=0A+                    NEED_OP(t)=
;=0A+                    NEED_IP(t + 3);=0A                     do {=0A    =
                     *op++ =3D *ip++;=0A                     } while (--t =
> 0);=0A@@ -471,7 +451,7 @@ int lzo1x_decompress_safe(const unsigned=0A    =
             m_pos -=3D t >> 2;=0A                 m_pos -=3D *ip++ << =
2;=0A                 TEST_LB(m_pos);=0A-                NEED_OP(2, =
0);=0A+                NEED_OP(2);=0A                 op[0] =3D =
m_pos[0];=0A                 op[1] =3D m_pos[1];=0A                 op =
+=3D 2;=0A@@ -495,10 +475,10 @@ int lzo1x_decompress_safe(const unsigned=0A=
                 while (unlikely(*ip =3D=3D 0)) {=0A                     t =
+=3D 255;=0A                     ip++;=0A-                    NEED_IP(1, =
0);=0A+                    NEED_IP(1);=0A                 }=0A             =
    t +=3D 31 + *ip++;=0A-                NEED_IP(2, 0);=0A+               =
 NEED_IP(2);=0A             }=0A             m_pos =3D op - 1;=0A          =
   next =3D get_unaligned_le16(ip);=0A@@ -513,10 +493,10 @@ int lzo1x_decom=
press_safe(const unsigned=0A                 while (unlikely(*ip =3D=3D =
0)) {=0A                     t +=3D 255;=0A                     ip++;=0A-  =
                  NEED_IP(1, 0);=0A+                    NEED_IP(1);=0A     =
            }=0A                 t +=3D 7 + *ip++;=0A-                =
NEED_IP(2, 0);=0A+                NEED_IP(2);=0A             }=0A          =
   next =3D get_unaligned_le16(ip);=0A             ip +=3D 2;=0A@@ -530,7 =
+510,7 @@ int lzo1x_decompress_safe(const unsigned=0A #if defined(CONFIG_HA=
VE_EFFICIENT_UNALIGNED_ACCESS)=0A         if (op - m_pos >=3D 8) {=0A      =
       unsigned char *oe =3D op + t;=0A-            if (likely(HAVE_OP(t, =
15))) {=0A+            if (likely(HAVE_OP(t + 15))) {=0A                 =
do {=0A                     COPY8(op, m_pos);=0A                     op =
+=3D 8;=0A@@ -540,7 +520,7 @@ int lzo1x_decompress_safe(const unsigned=0A  =
                   m_pos +=3D 8;=0A                 } while (op < oe);=0A  =
               op =3D oe;=0A-                if (HAVE_IP(6, 0)) {=0A+      =
          if (HAVE_IP(6)) {=0A                     state =3D next;=0A      =
               COPY4(op, ip);=0A                     op +=3D next;=0A@@ =
-548,7 +528,7 @@ int lzo1x_decompress_safe(const unsigned=0A               =
      continue;=0A                 }=0A             } else {=0A-           =
     NEED_OP(t, 0);=0A+                NEED_OP(t);=0A                 do =
{=0A                     *op++ =3D *m_pos++;=0A                 } while =
(op < oe);=0A@@ -557,7 +537,7 @@ int lzo1x_decompress_safe(const =
unsigned=0A #endif=0A         {=0A             unsigned char *oe =3D op + =
t;=0A-            NEED_OP(t, 0);=0A+            NEED_OP(t);=0A             =
op[0] =3D m_pos[0];=0A             op[1] =3D m_pos[1];=0A             op =
+=3D 2;=0A@@ -570,15 +550,15 @@ int lzo1x_decompress_safe(const unsigned=0A=
         state =3D next;=0A         t =3D next;=0A #if defined(CONFIG_HAVE_=
EFFICIENT_UNALIGNED_ACCESS)=0A-        if (likely(HAVE_IP(6, 0) && =
HAVE_OP(4, 0))) {=0A+        if (likely(HAVE_IP(6) && HAVE_OP(4))) {=0A    =
         COPY4(op, ip);=0A             op +=3D t;=0A             ip +=3D =
t;=0A         } else=0A #endif=0A         {=0A-            NEED_IP(t, =
3);=0A-            NEED_OP(t, 0);=0A+            NEED_IP(t + 3);=0A+       =
     NEED_OP(t);=0A             while (t > 0) {=0A                 *op++ =
=3D *ip++;=0A                 t--;=0A
--=__Part04310AF7.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

--=__Part04310AF7.1__=--


From xen-devel-bounces@lists.xen.org Mon Nov 03 15:02:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJ9R-0003t5-ND; Mon, 03 Nov 2014 15:02:37 +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 1XlJ9Q-0003sR-Ou
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 15:02:36 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	35/BF-02702-C0997545; Mon, 03 Nov 2014 15:02:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415026955!12263885!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15671 invoked from network); 3 Nov 2014 15:02:35 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 15:02:35 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 15:02:34 +0000
Message-Id: <5457A71802000078000447AA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 15:02:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <5457A3AD020000780004478B@mail.emea.novell.com>
In-Reply-To: <5457A3AD020000780004478B@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEADFE418.1__="
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH 2/2] lzo: check for length overrun in variable
 length encoding
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

This fix ensures that we never meet an integer overflow while adding
255 while parsing a variable length encoding. It works differently from
commit 504f70b6 ("lzo: properly check for overruns") because instead of
ensuring that we don't overrun the input, which is tricky to guarantee
due to many assumptions in the code, it simply checks that the cumulated
number of 255 read cannot overflow by bounding this number.

The MAX_255_COUNT is the maximum number of times we can add 255 to a base
count without overflowing an integer. The multiply will overflow when
multiplying 255 by more than MAXINT/255. The sum will overflow earlier
depending on the base count. Since the base count is taken from a u8
and a few bits, it is safe to assume that it will always be lower than
or equal to 2*255, thus we can always prevent any overflow by accepting
two less 255 steps.

This patch also reduces the CPU overhead and actually increases performance=

by 1.1% compared to the initial code, while the previous fix costs 3.1%
(measured on x86_64).

The fix needs to be backported to all currently supported stable kernels.

Reported-by: Willem Pinckaers <willem@lekkertech.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
[original Linux commit: 72cf9012]
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/lzo.c
+++ b/xen/common/lzo.c
@@ -381,6 +381,16 @@ int lzo1x_1_compress(const unsigned char
 #define NEED_OP(x)     if (!HAVE_OP(x)) goto output_overrun
 #define TEST_LB(m_pos) if ((m_pos) < out) goto lookbehind_overrun
=20
+/* This MAX_255_COUNT is the maximum number of times we can add 255 to a =
base
+ * count without overflowing an integer. The multiply will overflow when
+ * multiplying 255 by more than MAXINT/255. The sum will overflow earlier
+ * depending on the base count. Since the base count is taken from a u8
+ * and a few bits, it is safe to assume that it will always be lower than
+ * or equal to 2*255, thus we can always prevent any overflow by =
accepting
+ * two less 255 steps. See Documentation/lzo.txt for more information.
+ */
+#define MAX_255_COUNT      ((((size_t)~0) / 255) - 2)
+
 int lzo1x_decompress_safe(const unsigned char *in, size_t in_len,
                           unsigned char *out, size_t *out_len)
 {
@@ -411,12 +421,19 @@ int lzo1x_decompress_safe(const unsigned
         if (t < 16) {
             if (likely(state =3D=3D 0)) {
                 if (unlikely(t =3D=3D 0)) {
+                    size_t offset;
+                    const unsigned char *ip_last =3D ip;
+
                     while (unlikely(*ip =3D=3D 0)) {
-                        t +=3D 255;
                         ip++;
                         NEED_IP(1);
                     }
-                    t +=3D 15 + *ip++;
+                    offset =3D ip - ip_last;
+                    if (unlikely(offset > MAX_255_COUNT))
+                        return LZO_E_ERROR;
+
+                    offset =3D (offset << 8) - offset;
+                    t +=3D offset + 15 + *ip++;
                 }
                 t +=3D 3;
  copy_literal_run:
@@ -472,12 +489,19 @@ int lzo1x_decompress_safe(const unsigned
         } else if (t >=3D 32) {
             t =3D (t & 31) + (3 - 1);
             if (unlikely(t =3D=3D 2)) {
+                size_t offset;
+                const unsigned char *ip_last =3D ip;
+
                 while (unlikely(*ip =3D=3D 0)) {
-                    t +=3D 255;
                     ip++;
                     NEED_IP(1);
                 }
-                t +=3D 31 + *ip++;
+                offset =3D ip - ip_last;
+                if (unlikely(offset > MAX_255_COUNT))
+                    return LZO_E_ERROR;
+
+                offset =3D (offset << 8) - offset;
+                t +=3D offset + 31 + *ip++;
                 NEED_IP(2);
             }
             m_pos =3D op - 1;
@@ -490,12 +514,19 @@ int lzo1x_decompress_safe(const unsigned
             m_pos -=3D (t & 8) << 11;
             t =3D (t & 7) + (3 - 1);
             if (unlikely(t =3D=3D 2)) {
+                size_t offset;
+                const unsigned char *ip_last =3D ip;
+
                 while (unlikely(*ip =3D=3D 0)) {
-                    t +=3D 255;
                     ip++;
                     NEED_IP(1);
                 }
-                t +=3D 7 + *ip++;
+                offset =3D ip - ip_last;
+                if (unlikely(offset > MAX_255_COUNT))
+                    return LZO_E_ERROR;
+
+                offset =3D (offset << 8) - offset;
+                t +=3D offset + 7 + *ip++;
                 NEED_IP(2);
             }
             next =3D get_unaligned_le16(ip);



--=__PartEADFE418.1__=
Content-Type: text/plain; name="lzo-check-length-overrun.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="lzo-check-length-overrun.patch"

lzo: check for length overrun in variable length encoding=0A=0AThis fix =
ensures that we never meet an integer overflow while adding=0A255 while =
parsing a variable length encoding. It works differently from=0Acommit =
504f70b6 ("lzo: properly check for overruns") because instead of=0Aensuring=
 that we don't overrun the input, which is tricky to guarantee=0Adue to =
many assumptions in the code, it simply checks that the cumulated=0Anumber =
of 255 read cannot overflow by bounding this number.=0A=0AThe MAX_255_COUNT=
 is the maximum number of times we can add 255 to a base=0Acount without =
overflowing an integer. The multiply will overflow when=0Amultiplying 255 =
by more than MAXINT/255. The sum will overflow earlier=0Adepending on the =
base count. Since the base count is taken from a u8=0Aand a few bits, it =
is safe to assume that it will always be lower than=0Aor equal to 2*255, =
thus we can always prevent any overflow by accepting=0Atwo less 255 =
steps.=0A=0AThis patch also reduces the CPU overhead and actually =
increases performance=0Aby 1.1% compared to the initial code, while the =
previous fix costs 3.1%=0A(measured on x86_64).=0A=0AThe fix needs to be =
backported to all currently supported stable kernels.=0A=0AReported-by: =
Willem Pinckaers <willem@lekkertech.net>=0ASigned-off-by: Willy Tarreau =
<w@1wt.eu>=0A[original Linux commit: 72cf9012]=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/lzo.c=0A+++ b/xen/common/=
lzo.c=0A@@ -381,6 +381,16 @@ int lzo1x_1_compress(const unsigned char=0A =
#define NEED_OP(x)     if (!HAVE_OP(x)) goto output_overrun=0A #define =
TEST_LB(m_pos) if ((m_pos) < out) goto lookbehind_overrun=0A =0A+/* This =
MAX_255_COUNT is the maximum number of times we can add 255 to a base=0A+ =
* count without overflowing an integer. The multiply will overflow =
when=0A+ * multiplying 255 by more than MAXINT/255. The sum will overflow =
earlier=0A+ * depending on the base count. Since the base count is taken =
from a u8=0A+ * and a few bits, it is safe to assume that it will always =
be lower than=0A+ * or equal to 2*255, thus we can always prevent any =
overflow by accepting=0A+ * two less 255 steps. See Documentation/lzo.txt =
for more information.=0A+ */=0A+#define MAX_255_COUNT      ((((size_t)~0) =
/ 255) - 2)=0A+=0A int lzo1x_decompress_safe(const unsigned char *in, =
size_t in_len,=0A                           unsigned char *out, size_t =
*out_len)=0A {=0A@@ -411,12 +421,19 @@ int lzo1x_decompress_safe(const =
unsigned=0A         if (t < 16) {=0A             if (likely(state =3D=3D =
0)) {=0A                 if (unlikely(t =3D=3D 0)) {=0A+                   =
 size_t offset;=0A+                    const unsigned char *ip_last =3D =
ip;=0A+=0A                     while (unlikely(*ip =3D=3D 0)) {=0A-        =
                t +=3D 255;=0A                         ip++;=0A            =
             NEED_IP(1);=0A                     }=0A-                    t =
+=3D 15 + *ip++;=0A+                    offset =3D ip - ip_last;=0A+       =
             if (unlikely(offset > MAX_255_COUNT))=0A+                     =
   return LZO_E_ERROR;=0A+=0A+                    offset =3D (offset << 8) =
- offset;=0A+                    t +=3D offset + 15 + *ip++;=0A            =
     }=0A                 t +=3D 3;=0A  copy_literal_run:=0A@@ -472,12 =
+489,19 @@ int lzo1x_decompress_safe(const unsigned=0A         } else if =
(t >=3D 32) {=0A             t =3D (t & 31) + (3 - 1);=0A             if =
(unlikely(t =3D=3D 2)) {=0A+                size_t offset;=0A+             =
   const unsigned char *ip_last =3D ip;=0A+=0A                 while =
(unlikely(*ip =3D=3D 0)) {=0A-                    t +=3D 255;=0A           =
          ip++;=0A                     NEED_IP(1);=0A                 =
}=0A-                t +=3D 31 + *ip++;=0A+                offset =3D ip - =
ip_last;=0A+                if (unlikely(offset > MAX_255_COUNT))=0A+      =
              return LZO_E_ERROR;=0A+=0A+                offset =3D =
(offset << 8) - offset;=0A+                t +=3D offset + 31 + *ip++;=0A  =
               NEED_IP(2);=0A             }=0A             m_pos =3D op - =
1;=0A@@ -490,12 +514,19 @@ int lzo1x_decompress_safe(const unsigned=0A     =
        m_pos -=3D (t & 8) << 11;=0A             t =3D (t & 7) + (3 - =
1);=0A             if (unlikely(t =3D=3D 2)) {=0A+                size_t =
offset;=0A+                const unsigned char *ip_last =3D ip;=0A+=0A     =
            while (unlikely(*ip =3D=3D 0)) {=0A-                    t +=3D =
255;=0A                     ip++;=0A                     NEED_IP(1);=0A    =
             }=0A-                t +=3D 7 + *ip++;=0A+                =
offset =3D ip - ip_last;=0A+                if (unlikely(offset > =
MAX_255_COUNT))=0A+                    return LZO_E_ERROR;=0A+=0A+         =
       offset =3D (offset << 8) - offset;=0A+                t +=3D offset =
+ 7 + *ip++;=0A                 NEED_IP(2);=0A             }=0A            =
 next =3D get_unaligned_le16(ip);=0A
--=__PartEADFE418.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

--=__PartEADFE418.1__=--


From xen-devel-bounces@lists.xen.org Mon Nov 03 15:02:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJ9R-0003t5-ND; Mon, 03 Nov 2014 15:02:37 +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 1XlJ9Q-0003sR-Ou
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 15:02:36 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	35/BF-02702-C0997545; Mon, 03 Nov 2014 15:02:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415026955!12263885!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15671 invoked from network); 3 Nov 2014 15:02:35 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 15:02:35 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 15:02:34 +0000
Message-Id: <5457A71802000078000447AA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 15:02:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <5457A3AD020000780004478B@mail.emea.novell.com>
In-Reply-To: <5457A3AD020000780004478B@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEADFE418.1__="
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH 2/2] lzo: check for length overrun in variable
 length encoding
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

This fix ensures that we never meet an integer overflow while adding
255 while parsing a variable length encoding. It works differently from
commit 504f70b6 ("lzo: properly check for overruns") because instead of
ensuring that we don't overrun the input, which is tricky to guarantee
due to many assumptions in the code, it simply checks that the cumulated
number of 255 read cannot overflow by bounding this number.

The MAX_255_COUNT is the maximum number of times we can add 255 to a base
count without overflowing an integer. The multiply will overflow when
multiplying 255 by more than MAXINT/255. The sum will overflow earlier
depending on the base count. Since the base count is taken from a u8
and a few bits, it is safe to assume that it will always be lower than
or equal to 2*255, thus we can always prevent any overflow by accepting
two less 255 steps.

This patch also reduces the CPU overhead and actually increases performance=

by 1.1% compared to the initial code, while the previous fix costs 3.1%
(measured on x86_64).

The fix needs to be backported to all currently supported stable kernels.

Reported-by: Willem Pinckaers <willem@lekkertech.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
[original Linux commit: 72cf9012]
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/lzo.c
+++ b/xen/common/lzo.c
@@ -381,6 +381,16 @@ int lzo1x_1_compress(const unsigned char
 #define NEED_OP(x)     if (!HAVE_OP(x)) goto output_overrun
 #define TEST_LB(m_pos) if ((m_pos) < out) goto lookbehind_overrun
=20
+/* This MAX_255_COUNT is the maximum number of times we can add 255 to a =
base
+ * count without overflowing an integer. The multiply will overflow when
+ * multiplying 255 by more than MAXINT/255. The sum will overflow earlier
+ * depending on the base count. Since the base count is taken from a u8
+ * and a few bits, it is safe to assume that it will always be lower than
+ * or equal to 2*255, thus we can always prevent any overflow by =
accepting
+ * two less 255 steps. See Documentation/lzo.txt for more information.
+ */
+#define MAX_255_COUNT      ((((size_t)~0) / 255) - 2)
+
 int lzo1x_decompress_safe(const unsigned char *in, size_t in_len,
                           unsigned char *out, size_t *out_len)
 {
@@ -411,12 +421,19 @@ int lzo1x_decompress_safe(const unsigned
         if (t < 16) {
             if (likely(state =3D=3D 0)) {
                 if (unlikely(t =3D=3D 0)) {
+                    size_t offset;
+                    const unsigned char *ip_last =3D ip;
+
                     while (unlikely(*ip =3D=3D 0)) {
-                        t +=3D 255;
                         ip++;
                         NEED_IP(1);
                     }
-                    t +=3D 15 + *ip++;
+                    offset =3D ip - ip_last;
+                    if (unlikely(offset > MAX_255_COUNT))
+                        return LZO_E_ERROR;
+
+                    offset =3D (offset << 8) - offset;
+                    t +=3D offset + 15 + *ip++;
                 }
                 t +=3D 3;
  copy_literal_run:
@@ -472,12 +489,19 @@ int lzo1x_decompress_safe(const unsigned
         } else if (t >=3D 32) {
             t =3D (t & 31) + (3 - 1);
             if (unlikely(t =3D=3D 2)) {
+                size_t offset;
+                const unsigned char *ip_last =3D ip;
+
                 while (unlikely(*ip =3D=3D 0)) {
-                    t +=3D 255;
                     ip++;
                     NEED_IP(1);
                 }
-                t +=3D 31 + *ip++;
+                offset =3D ip - ip_last;
+                if (unlikely(offset > MAX_255_COUNT))
+                    return LZO_E_ERROR;
+
+                offset =3D (offset << 8) - offset;
+                t +=3D offset + 31 + *ip++;
                 NEED_IP(2);
             }
             m_pos =3D op - 1;
@@ -490,12 +514,19 @@ int lzo1x_decompress_safe(const unsigned
             m_pos -=3D (t & 8) << 11;
             t =3D (t & 7) + (3 - 1);
             if (unlikely(t =3D=3D 2)) {
+                size_t offset;
+                const unsigned char *ip_last =3D ip;
+
                 while (unlikely(*ip =3D=3D 0)) {
-                    t +=3D 255;
                     ip++;
                     NEED_IP(1);
                 }
-                t +=3D 7 + *ip++;
+                offset =3D ip - ip_last;
+                if (unlikely(offset > MAX_255_COUNT))
+                    return LZO_E_ERROR;
+
+                offset =3D (offset << 8) - offset;
+                t +=3D offset + 7 + *ip++;
                 NEED_IP(2);
             }
             next =3D get_unaligned_le16(ip);



--=__PartEADFE418.1__=
Content-Type: text/plain; name="lzo-check-length-overrun.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="lzo-check-length-overrun.patch"

lzo: check for length overrun in variable length encoding=0A=0AThis fix =
ensures that we never meet an integer overflow while adding=0A255 while =
parsing a variable length encoding. It works differently from=0Acommit =
504f70b6 ("lzo: properly check for overruns") because instead of=0Aensuring=
 that we don't overrun the input, which is tricky to guarantee=0Adue to =
many assumptions in the code, it simply checks that the cumulated=0Anumber =
of 255 read cannot overflow by bounding this number.=0A=0AThe MAX_255_COUNT=
 is the maximum number of times we can add 255 to a base=0Acount without =
overflowing an integer. The multiply will overflow when=0Amultiplying 255 =
by more than MAXINT/255. The sum will overflow earlier=0Adepending on the =
base count. Since the base count is taken from a u8=0Aand a few bits, it =
is safe to assume that it will always be lower than=0Aor equal to 2*255, =
thus we can always prevent any overflow by accepting=0Atwo less 255 =
steps.=0A=0AThis patch also reduces the CPU overhead and actually =
increases performance=0Aby 1.1% compared to the initial code, while the =
previous fix costs 3.1%=0A(measured on x86_64).=0A=0AThe fix needs to be =
backported to all currently supported stable kernels.=0A=0AReported-by: =
Willem Pinckaers <willem@lekkertech.net>=0ASigned-off-by: Willy Tarreau =
<w@1wt.eu>=0A[original Linux commit: 72cf9012]=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/lzo.c=0A+++ b/xen/common/=
lzo.c=0A@@ -381,6 +381,16 @@ int lzo1x_1_compress(const unsigned char=0A =
#define NEED_OP(x)     if (!HAVE_OP(x)) goto output_overrun=0A #define =
TEST_LB(m_pos) if ((m_pos) < out) goto lookbehind_overrun=0A =0A+/* This =
MAX_255_COUNT is the maximum number of times we can add 255 to a base=0A+ =
* count without overflowing an integer. The multiply will overflow =
when=0A+ * multiplying 255 by more than MAXINT/255. The sum will overflow =
earlier=0A+ * depending on the base count. Since the base count is taken =
from a u8=0A+ * and a few bits, it is safe to assume that it will always =
be lower than=0A+ * or equal to 2*255, thus we can always prevent any =
overflow by accepting=0A+ * two less 255 steps. See Documentation/lzo.txt =
for more information.=0A+ */=0A+#define MAX_255_COUNT      ((((size_t)~0) =
/ 255) - 2)=0A+=0A int lzo1x_decompress_safe(const unsigned char *in, =
size_t in_len,=0A                           unsigned char *out, size_t =
*out_len)=0A {=0A@@ -411,12 +421,19 @@ int lzo1x_decompress_safe(const =
unsigned=0A         if (t < 16) {=0A             if (likely(state =3D=3D =
0)) {=0A                 if (unlikely(t =3D=3D 0)) {=0A+                   =
 size_t offset;=0A+                    const unsigned char *ip_last =3D =
ip;=0A+=0A                     while (unlikely(*ip =3D=3D 0)) {=0A-        =
                t +=3D 255;=0A                         ip++;=0A            =
             NEED_IP(1);=0A                     }=0A-                    t =
+=3D 15 + *ip++;=0A+                    offset =3D ip - ip_last;=0A+       =
             if (unlikely(offset > MAX_255_COUNT))=0A+                     =
   return LZO_E_ERROR;=0A+=0A+                    offset =3D (offset << 8) =
- offset;=0A+                    t +=3D offset + 15 + *ip++;=0A            =
     }=0A                 t +=3D 3;=0A  copy_literal_run:=0A@@ -472,12 =
+489,19 @@ int lzo1x_decompress_safe(const unsigned=0A         } else if =
(t >=3D 32) {=0A             t =3D (t & 31) + (3 - 1);=0A             if =
(unlikely(t =3D=3D 2)) {=0A+                size_t offset;=0A+             =
   const unsigned char *ip_last =3D ip;=0A+=0A                 while =
(unlikely(*ip =3D=3D 0)) {=0A-                    t +=3D 255;=0A           =
          ip++;=0A                     NEED_IP(1);=0A                 =
}=0A-                t +=3D 31 + *ip++;=0A+                offset =3D ip - =
ip_last;=0A+                if (unlikely(offset > MAX_255_COUNT))=0A+      =
              return LZO_E_ERROR;=0A+=0A+                offset =3D =
(offset << 8) - offset;=0A+                t +=3D offset + 31 + *ip++;=0A  =
               NEED_IP(2);=0A             }=0A             m_pos =3D op - =
1;=0A@@ -490,12 +514,19 @@ int lzo1x_decompress_safe(const unsigned=0A     =
        m_pos -=3D (t & 8) << 11;=0A             t =3D (t & 7) + (3 - =
1);=0A             if (unlikely(t =3D=3D 2)) {=0A+                size_t =
offset;=0A+                const unsigned char *ip_last =3D ip;=0A+=0A     =
            while (unlikely(*ip =3D=3D 0)) {=0A-                    t +=3D =
255;=0A                     ip++;=0A                     NEED_IP(1);=0A    =
             }=0A-                t +=3D 7 + *ip++;=0A+                =
offset =3D ip - ip_last;=0A+                if (unlikely(offset > =
MAX_255_COUNT))=0A+                    return LZO_E_ERROR;=0A+=0A+         =
       offset =3D (offset << 8) - offset;=0A+                t +=3D offset =
+ 7 + *ip++;=0A                 NEED_IP(2);=0A             }=0A            =
 next =3D get_unaligned_le16(ip);=0A
--=__PartEADFE418.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

--=__PartEADFE418.1__=--


From xen-devel-bounces@lists.xen.org Mon Nov 03 15:29:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:29:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJZI-0004wo-Ko; Mon, 03 Nov 2014 15:29:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlJZH-0004wj-4r
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:29:19 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	70/FB-22777-E4F97545; Mon, 03 Nov 2014 15:29:18 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415028557!10894803!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16192 invoked from network); 3 Nov 2014 15:29:17 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:29:17 -0000
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BOJ14167; Mon, 03 Nov 2014 15:29:10 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id
	14.03.0158.001; Mon, 3 Nov 2014 15:28:12 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH 10/10] xen/arm: Handle different bootwrapper locations
	for Hip04 platform
Thread-Index: AQHP907X6cH18Hjd2Ey5HiwKWUwR25xO8jSAgAAUkOA=
Date: Mon, 3 Nov 2014 15:28:11 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17AF29@lhreml509-mbb>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
	<54578DA7.9080505@linaro.org>
In-Reply-To: <54578DA7.9080505@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.77.41]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
 locations for Hip04 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

> 
> Hi Frediano,
> 
> This could be merged in #1.
> 
> Regards,
> 

No, as it require the patch just before it so merging to #1 cause a commit that does not compile

Frediano

> On 11/03/2014 10:12 AM, Frediano Ziglio wrote:
> > From: Zoltan Kiss <zoltan.kiss@linaro.org>
> >
> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > ---
> >  xen/arch/arm/platforms/hip04.c | 63
> > ++++++++++++++++++++++++++----------------
> >  1 file changed, 39 insertions(+), 24 deletions(-)
> >
> > diff --git a/xen/arch/arm/platforms/hip04.c
> > b/xen/arch/arm/platforms/hip04.c index 024c8a0..dec4984 100644
> > --- a/xen/arch/arm/platforms/hip04.c
> > +++ b/xen/arch/arm/platforms/hip04.c
> > @@ -136,7 +136,7 @@ static void hip04_cluster_up(unsigned int cluster)
> >
> >  static int __init hip04_smp_init(void)  {
> > -    struct dt_device_node *np, *np_fab;
> > +    struct dt_device_node *np, *np_fab, *bw;
> >      const char *msg;
> >      u64 addr, size;
> >
> > @@ -150,30 +150,45 @@ static int __init hip04_smp_init(void)
> >      if ( !np_fab )
> >          goto err;
> >
> > -    msg = "failed to get bootwrapper-phys\n";
> >      if ( !dt_property_read_u32(np, "bootwrapper-phys",
> > -                               &hip04_boot.bootwrapper_phys) )
> > -        goto err;
> > -
> > -    msg = "failed to get bootwrapper-size\n";
> > -    if ( !dt_property_read_u32(np, "bootwrapper-size",
> > -                               &hip04_boot.bootwrapper_size) )
> > -        goto err;
> > -
> > -    msg = "failed to get bootwrapper-magic\n";
> > -    if ( !dt_property_read_u32(np, "bootwrapper-magic",
> > -                               &hip04_boot.bootwrapper_magic) )
> > -        goto err;
> > -
> > -    msg = "failed to get relocation-entry\n";
> > -    if ( !dt_property_read_u32(np, "relocation-entry",
> > -                               &hip04_boot.relocation_entry) )
> > -        goto err;
> > -
> > -    msg = "failed to get relocation-size\n";
> > -    if ( !dt_property_read_u32(np, "relocation-size",
> > -                 &hip04_boot.relocation_size) )
> > -        goto err;
> > +                               &hip04_boot.bootwrapper_phys) ) {
> > +        u32 boot_method[4];
> > +        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-
> bootwrapper");
> > +        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
> > +        if ( !bw )
> > +            goto err;
> > +
> > +        msg = "failed to get boot-method\n";
> > +        if ( !dt_property_read_u32_array(bw, "boot-method",
> boot_method, 4) )
> > +            goto err;
> > +        hip04_boot.bootwrapper_phys = boot_method[0];
> > +        hip04_boot.bootwrapper_size = boot_method[1];
> > +        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
> > +        hip04_boot.relocation_entry = boot_method[2];
> > +        hip04_boot.relocation_size = boot_method[3];
> > +    }
> > +    else
> > +    {
> > +        msg = "failed to get bootwrapper-size\n";
> > +        if ( !dt_property_read_u32(np, "bootwrapper-size",
> > +                                   &hip04_boot.bootwrapper_size) )
> > +            goto err;
> > +
> > +        msg = "failed to get bootwrapper-magic\n";
> > +        if ( !dt_property_read_u32(np, "bootwrapper-magic",
> > +                                   &hip04_boot.bootwrapper_magic) )
> > +            goto err;
> > +
> > +        msg = "failed to get relocation-entry\n";
> > +        if ( !dt_property_read_u32(np, "relocation-entry",
> > +                                   &hip04_boot.relocation_entry) )
> > +            goto err;
> > +
> > +        msg = "failed to get relocation-size\n";
> > +        if ( !dt_property_read_u32(np, "relocation-size",
> > +                                   &hip04_boot.relocation_size) )
> > +            goto err;
> > +    }
> >
> >      relocation = ioremap_nocache(hip04_boot.relocation_entry,
> >                                   hip04_boot.relocation_size);
> >
> 
> 
> --
> Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:29:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:29:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJZI-0004wo-Ko; Mon, 03 Nov 2014 15:29:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlJZH-0004wj-4r
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:29:19 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	70/FB-22777-E4F97545; Mon, 03 Nov 2014 15:29:18 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415028557!10894803!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16192 invoked from network); 3 Nov 2014 15:29:17 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:29:17 -0000
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BOJ14167; Mon, 03 Nov 2014 15:29:10 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id
	14.03.0158.001; Mon, 3 Nov 2014 15:28:12 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH 10/10] xen/arm: Handle different bootwrapper locations
	for Hip04 platform
Thread-Index: AQHP907X6cH18Hjd2Ey5HiwKWUwR25xO8jSAgAAUkOA=
Date: Mon, 3 Nov 2014 15:28:11 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17AF29@lhreml509-mbb>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
	<54578DA7.9080505@linaro.org>
In-Reply-To: <54578DA7.9080505@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.77.41]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
 locations for Hip04 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

> 
> Hi Frediano,
> 
> This could be merged in #1.
> 
> Regards,
> 

No, as it require the patch just before it so merging to #1 cause a commit that does not compile

Frediano

> On 11/03/2014 10:12 AM, Frediano Ziglio wrote:
> > From: Zoltan Kiss <zoltan.kiss@linaro.org>
> >
> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > ---
> >  xen/arch/arm/platforms/hip04.c | 63
> > ++++++++++++++++++++++++++----------------
> >  1 file changed, 39 insertions(+), 24 deletions(-)
> >
> > diff --git a/xen/arch/arm/platforms/hip04.c
> > b/xen/arch/arm/platforms/hip04.c index 024c8a0..dec4984 100644
> > --- a/xen/arch/arm/platforms/hip04.c
> > +++ b/xen/arch/arm/platforms/hip04.c
> > @@ -136,7 +136,7 @@ static void hip04_cluster_up(unsigned int cluster)
> >
> >  static int __init hip04_smp_init(void)  {
> > -    struct dt_device_node *np, *np_fab;
> > +    struct dt_device_node *np, *np_fab, *bw;
> >      const char *msg;
> >      u64 addr, size;
> >
> > @@ -150,30 +150,45 @@ static int __init hip04_smp_init(void)
> >      if ( !np_fab )
> >          goto err;
> >
> > -    msg = "failed to get bootwrapper-phys\n";
> >      if ( !dt_property_read_u32(np, "bootwrapper-phys",
> > -                               &hip04_boot.bootwrapper_phys) )
> > -        goto err;
> > -
> > -    msg = "failed to get bootwrapper-size\n";
> > -    if ( !dt_property_read_u32(np, "bootwrapper-size",
> > -                               &hip04_boot.bootwrapper_size) )
> > -        goto err;
> > -
> > -    msg = "failed to get bootwrapper-magic\n";
> > -    if ( !dt_property_read_u32(np, "bootwrapper-magic",
> > -                               &hip04_boot.bootwrapper_magic) )
> > -        goto err;
> > -
> > -    msg = "failed to get relocation-entry\n";
> > -    if ( !dt_property_read_u32(np, "relocation-entry",
> > -                               &hip04_boot.relocation_entry) )
> > -        goto err;
> > -
> > -    msg = "failed to get relocation-size\n";
> > -    if ( !dt_property_read_u32(np, "relocation-size",
> > -                 &hip04_boot.relocation_size) )
> > -        goto err;
> > +                               &hip04_boot.bootwrapper_phys) ) {
> > +        u32 boot_method[4];
> > +        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-
> bootwrapper");
> > +        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
> > +        if ( !bw )
> > +            goto err;
> > +
> > +        msg = "failed to get boot-method\n";
> > +        if ( !dt_property_read_u32_array(bw, "boot-method",
> boot_method, 4) )
> > +            goto err;
> > +        hip04_boot.bootwrapper_phys = boot_method[0];
> > +        hip04_boot.bootwrapper_size = boot_method[1];
> > +        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
> > +        hip04_boot.relocation_entry = boot_method[2];
> > +        hip04_boot.relocation_size = boot_method[3];
> > +    }
> > +    else
> > +    {
> > +        msg = "failed to get bootwrapper-size\n";
> > +        if ( !dt_property_read_u32(np, "bootwrapper-size",
> > +                                   &hip04_boot.bootwrapper_size) )
> > +            goto err;
> > +
> > +        msg = "failed to get bootwrapper-magic\n";
> > +        if ( !dt_property_read_u32(np, "bootwrapper-magic",
> > +                                   &hip04_boot.bootwrapper_magic) )
> > +            goto err;
> > +
> > +        msg = "failed to get relocation-entry\n";
> > +        if ( !dt_property_read_u32(np, "relocation-entry",
> > +                                   &hip04_boot.relocation_entry) )
> > +            goto err;
> > +
> > +        msg = "failed to get relocation-size\n";
> > +        if ( !dt_property_read_u32(np, "relocation-size",
> > +                                   &hip04_boot.relocation_size) )
> > +            goto err;
> > +    }
> >
> >      relocation = ioremap_nocache(hip04_boot.relocation_entry,
> >                                   hip04_boot.relocation_size);
> >
> 
> 
> --
> Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:33:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15: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 1XlJd9-00057W-BK; Mon, 03 Nov 2014 15:33:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlJd7-000577-Lh
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:33:17 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	17/BF-27785-D30A7545; Mon, 03 Nov 2014 15:33:17 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415028796!12241662!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32212 invoked from network); 3 Nov 2014 15:33:16 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:33:16 -0000
Received: by mail-wg0-f54.google.com with SMTP id n12so5961275wgh.41
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 07:33:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=SLe8IYKeqNjSfF9Ok9g9MuvNBXNv29GJVbXj2qXUVqE=;
	b=b16FXu35IX7Hqoxcdsqgt0xQ+qvxJgHIXaIC2bZZ2c75Wd5nJQN5z+/00+PBtzgOG3
	ZAHcgte3PK6VP2otmXJ3G9pOCcztP1r9AOX84+GrMnC4DdC53pRKNQmrDm/pEyK2f/PN
	dn5De346a4X5koSPcmqrE4q7KB/QG5FOOl7Uqv4sXGAtlZT0iZQOi0rab9YCsf01i+Rc
	P8DbLsK23BWAndKspLNwACH/sKUQPzBrvmTSJYGnqdgMpnauvXY8SLjLZ8Ifn5Ke6Dox
	2JC99+N37qkvMr2iq2w8bQqNbf52NoOVne04xev4ip7dS8gT+kTUmit5SjWsbE5FkOxD
	vY9w==
X-Gm-Message-State: ALoCoQk9OPA1EVPE8pEhlbNR2qejCEMi8cPuSvixmsKj4PdcdNhsMaImjI7c29irUafkQLJIk3ZZ
X-Received: by 10.180.20.8 with SMTP id j8mr17229053wie.60.1415028796270;
	Mon, 03 Nov 2014 07:33:16 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fv2sm9110431wib.2.2014.11.03.07.33.14
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 07:33:15 -0800 (PST)
Message-ID: <5457A034.1030008@linaro.org>
Date: Mon, 03 Nov 2014 15:33:08 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
	<54578DA7.9080505@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17AF29@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17AF29@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
 locations for Hip04 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 11/03/2014 03:28 PM, Frediano Ziglio wrote:
>>
>> Hi Frediano,
>>
>> This could be merged in #1.
>>
>> Regards,
>>
> 
> No, as it require the patch just before it so merging to #1 cause a commit that does not compile

Why don't you move the patch #9 earlier in the patch series too?

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:33:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15: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 1XlJd9-00057W-BK; Mon, 03 Nov 2014 15:33:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlJd7-000577-Lh
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:33:17 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	17/BF-27785-D30A7545; Mon, 03 Nov 2014 15:33:17 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415028796!12241662!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32212 invoked from network); 3 Nov 2014 15:33:16 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:33:16 -0000
Received: by mail-wg0-f54.google.com with SMTP id n12so5961275wgh.41
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 07:33:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=SLe8IYKeqNjSfF9Ok9g9MuvNBXNv29GJVbXj2qXUVqE=;
	b=b16FXu35IX7Hqoxcdsqgt0xQ+qvxJgHIXaIC2bZZ2c75Wd5nJQN5z+/00+PBtzgOG3
	ZAHcgte3PK6VP2otmXJ3G9pOCcztP1r9AOX84+GrMnC4DdC53pRKNQmrDm/pEyK2f/PN
	dn5De346a4X5koSPcmqrE4q7KB/QG5FOOl7Uqv4sXGAtlZT0iZQOi0rab9YCsf01i+Rc
	P8DbLsK23BWAndKspLNwACH/sKUQPzBrvmTSJYGnqdgMpnauvXY8SLjLZ8Ifn5Ke6Dox
	2JC99+N37qkvMr2iq2w8bQqNbf52NoOVne04xev4ip7dS8gT+kTUmit5SjWsbE5FkOxD
	vY9w==
X-Gm-Message-State: ALoCoQk9OPA1EVPE8pEhlbNR2qejCEMi8cPuSvixmsKj4PdcdNhsMaImjI7c29irUafkQLJIk3ZZ
X-Received: by 10.180.20.8 with SMTP id j8mr17229053wie.60.1415028796270;
	Mon, 03 Nov 2014 07:33:16 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fv2sm9110431wib.2.2014.11.03.07.33.14
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 07:33:15 -0800 (PST)
Message-ID: <5457A034.1030008@linaro.org>
Date: Mon, 03 Nov 2014 15:33:08 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
	<54578DA7.9080505@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17AF29@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17AF29@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
 locations for Hip04 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 11/03/2014 03:28 PM, Frediano Ziglio wrote:
>>
>> Hi Frediano,
>>
>> This could be merged in #1.
>>
>> Regards,
>>
> 
> No, as it require the patch just before it so merging to #1 cause a commit that does not compile

Why don't you move the patch #9 earlier in the patch series too?

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:37:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:37:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJgx-0005OR-9m; Mon, 03 Nov 2014 15:37:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlJgv-0005OM-WE
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:37:14 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	96/72-02559-921A7545; Mon, 03 Nov 2014 15:37:13 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415029032!6851241!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11187 invoked from network); 3 Nov 2014 15:37:12 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:37:12 -0000
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BOJ15246; Mon, 03 Nov 2014 15:37:07 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Mon, 3 Nov 2014 15:36:15 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH 10/10] xen/arm: Handle different bootwrapper locations
	for Hip04 platform
Thread-Index: AQHP907X6cH18Hjd2Ey5HiwKWUwR25xO8jSAgAAUkOCAAAGNAIAAAFrA
Date: Mon, 3 Nov 2014 15:36:15 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17AF5A@lhreml509-mbb>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
	<54578DA7.9080505@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17AF29@lhreml509-mbb>
	<5457A034.1030008@linaro.org>
In-Reply-To: <5457A034.1030008@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.77.41]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
 locations for Hip04 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 11/03/2014 03:28 PM, Frediano Ziglio wrote:
> >>
> >> Hi Frediano,
> >>
> >> This could be merged in #1.
> >>
> >> Regards,
> >>
> >
> > No, as it require the patch just before it so merging to #1 cause a
> commit that does not compile
> 
> Why don't you move the patch #9 earlier in the patch series too?
> 
> Regards,
> 

So move patch #9 and #10 in another position? Looks ok, which position?

I did most of changes you requested. I was thinking to post another version with this last change.

The change suggested by Ian (do not use a quirk) is still in my TODO list as could be quite big.

I don't know which constant I should use for the 510 number.

Frediano


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:37:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:37:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJgx-0005OR-9m; Mon, 03 Nov 2014 15:37:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlJgv-0005OM-WE
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:37:14 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	96/72-02559-921A7545; Mon, 03 Nov 2014 15:37:13 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415029032!6851241!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11187 invoked from network); 3 Nov 2014 15:37:12 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:37:12 -0000
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BOJ15246; Mon, 03 Nov 2014 15:37:07 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Mon, 3 Nov 2014 15:36:15 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH 10/10] xen/arm: Handle different bootwrapper locations
	for Hip04 platform
Thread-Index: AQHP907X6cH18Hjd2Ey5HiwKWUwR25xO8jSAgAAUkOCAAAGNAIAAAFrA
Date: Mon, 3 Nov 2014 15:36:15 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17AF5A@lhreml509-mbb>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
	<54578DA7.9080505@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17AF29@lhreml509-mbb>
	<5457A034.1030008@linaro.org>
In-Reply-To: <5457A034.1030008@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.77.41]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
 locations for Hip04 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 11/03/2014 03:28 PM, Frediano Ziglio wrote:
> >>
> >> Hi Frediano,
> >>
> >> This could be merged in #1.
> >>
> >> Regards,
> >>
> >
> > No, as it require the patch just before it so merging to #1 cause a
> commit that does not compile
> 
> Why don't you move the patch #9 earlier in the patch series too?
> 
> Regards,
> 

So move patch #9 and #10 in another position? Looks ok, which position?

I did most of changes you requested. I was thinking to post another version with this last change.

The change suggested by Ian (do not use a quirk) is still in my TODO list as could be quite big.

I don't know which constant I should use for the 510 number.

Frediano


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:40:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:40:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJk0-0005WT-V2; Mon, 03 Nov 2014 15:40:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlJjz-0005WM-Kc
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:40:23 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	65/A5-14214-6E1A7545; Mon, 03 Nov 2014 15:40:22 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415029222!10918444!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2722 invoked from network); 3 Nov 2014 15:40:22 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:40:22 -0000
Received: by mail-wi0-f174.google.com with SMTP id d1so6839087wiv.13
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 07:40:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=KgEGrwgOKOZD8ZvcWur2tbUiHw5+W/stsVB7o6Yx6ZA=;
	b=VSUqqIALDIhc9dxvw2qsIdsKlL/hvKLRakKoTc8Kt/SJXxFwiGPMnmX7o18EB+Nb/2
	FQdWJ9cN6vlpf8VKFZ3W+EhDcIyH79F+MzwmRI00GqWLQh02Ct11Iq3G1LTUORqi/m6s
	huFkGq4+R8noDYZn7s99cotrbqT1yS4q29uwoY764tXgl9L1Z0OR/JwhAGd7Uw20nOW9
	/FK36vK9dyilNR2sgoAiv0z0hO2MuuQWnc9RqoPFf9sQLbuKSyWfb4xwJyNymv1SNMW5
	7ibWjDwqzulj6TZKySh05WYvp2vxJRA5piB2h0DVoszI8a7VIEnpnzqEfLVe9xnGaKmQ
	6m6g==
X-Gm-Message-State: ALoCoQmgeRMMywi8zwaH5AKZOAHZkdpqNqC4R+VI2PNc7erd8ZIsDnllHUNfsnQmO0/JB9KM/ehC
X-Received: by 10.180.100.129 with SMTP id ey1mr17645088wib.28.1415029222232; 
	Mon, 03 Nov 2014 07:40:22 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id u2sm22574659wjz.11.2014.11.03.07.40.20
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 07:40:21 -0800 (PST)
Message-ID: <5457A1DE.3030104@linaro.org>
Date: Mon, 03 Nov 2014 15:40:14 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
	<54578DA7.9080505@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17AF29@lhreml509-mbb>
	<5457A034.1030008@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17AF5A@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17AF5A@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
 locations for Hip04 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 11/03/2014 03:36 PM, Frediano Ziglio wrote:
>> On 11/03/2014 03:28 PM, Frediano Ziglio wrote:
>>>>
>>>> Hi Frediano,
>>>>
>>>> This could be merged in #1.
>>>>
>>>> Regards,
>>>>
>>>
>>> No, as it require the patch just before it so merging to #1 cause a
>> commit that does not compile
>>
>> Why don't you move the patch #9 earlier in the patch series too?
>>
>> Regards,
>>
> 
> So move patch #9 and #10 in another position? Looks ok, which position?

I would move #9 to the top of the list and merge #10 in the current #1.

> I did most of changes you requested. I was thinking to post another version with this last change.
> 
> The change suggested by Ian (do not use a quirk) is still in my TODO list as could be quite big.
> 
> I don't know which constant I should use for the 510 number.

The first one is not useful as it will catch buggy hardware, the second
could be replace by nr_lines.

So you could even drop the 2 510.

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:40:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:40:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJk0-0005WT-V2; Mon, 03 Nov 2014 15:40:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlJjz-0005WM-Kc
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:40:23 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	65/A5-14214-6E1A7545; Mon, 03 Nov 2014 15:40:22 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415029222!10918444!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2722 invoked from network); 3 Nov 2014 15:40:22 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:40:22 -0000
Received: by mail-wi0-f174.google.com with SMTP id d1so6839087wiv.13
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 07:40:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=KgEGrwgOKOZD8ZvcWur2tbUiHw5+W/stsVB7o6Yx6ZA=;
	b=VSUqqIALDIhc9dxvw2qsIdsKlL/hvKLRakKoTc8Kt/SJXxFwiGPMnmX7o18EB+Nb/2
	FQdWJ9cN6vlpf8VKFZ3W+EhDcIyH79F+MzwmRI00GqWLQh02Ct11Iq3G1LTUORqi/m6s
	huFkGq4+R8noDYZn7s99cotrbqT1yS4q29uwoY764tXgl9L1Z0OR/JwhAGd7Uw20nOW9
	/FK36vK9dyilNR2sgoAiv0z0hO2MuuQWnc9RqoPFf9sQLbuKSyWfb4xwJyNymv1SNMW5
	7ibWjDwqzulj6TZKySh05WYvp2vxJRA5piB2h0DVoszI8a7VIEnpnzqEfLVe9xnGaKmQ
	6m6g==
X-Gm-Message-State: ALoCoQmgeRMMywi8zwaH5AKZOAHZkdpqNqC4R+VI2PNc7erd8ZIsDnllHUNfsnQmO0/JB9KM/ehC
X-Received: by 10.180.100.129 with SMTP id ey1mr17645088wib.28.1415029222232; 
	Mon, 03 Nov 2014 07:40:22 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id u2sm22574659wjz.11.2014.11.03.07.40.20
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 07:40:21 -0800 (PST)
Message-ID: <5457A1DE.3030104@linaro.org>
Date: Mon, 03 Nov 2014 15:40:14 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415009522-6344-1-git-send-email-frediano.ziglio@huawei.com>
	<1415009522-6344-11-git-send-email-frediano.ziglio@huawei.com>
	<54578DA7.9080505@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17AF29@lhreml509-mbb>
	<5457A034.1030008@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17AF5A@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17AF5A@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/arm: Handle different bootwrapper
 locations for Hip04 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 11/03/2014 03:36 PM, Frediano Ziglio wrote:
>> On 11/03/2014 03:28 PM, Frediano Ziglio wrote:
>>>>
>>>> Hi Frediano,
>>>>
>>>> This could be merged in #1.
>>>>
>>>> Regards,
>>>>
>>>
>>> No, as it require the patch just before it so merging to #1 cause a
>> commit that does not compile
>>
>> Why don't you move the patch #9 earlier in the patch series too?
>>
>> Regards,
>>
> 
> So move patch #9 and #10 in another position? Looks ok, which position?

I would move #9 to the top of the list and merge #10 in the current #1.

> I did most of changes you requested. I was thinking to post another version with this last change.
> 
> The change suggested by Ian (do not use a quirk) is still in my TODO list as could be quite big.
> 
> I don't know which constant I should use for the 510 number.

The first one is not useful as it will catch buggy hardware, the second
could be replace by nr_lines.

So you could even drop the 2 510.

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:41:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:41:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJlB-0005c9-My; Mon, 03 Nov 2014 15:41:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XlJl9-0005c3-M1
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 15:41:35 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6B/85-24532-F22A7545; Mon, 03 Nov 2014 15:41:35 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415029294!12473182!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9645 invoked from network); 3 Nov 2014 15:41:34 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:41:34 -0000
Received: by mail-wg0-f53.google.com with SMTP id b13so11189005wgh.26
	for <xen-devel@lists.xensource.com>;
	Mon, 03 Nov 2014 07:41:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:content-type:content-transfer-encoding;
	bh=zVG+bUpgSeVCeWkl86MIrjwEz4WN4ePDiJgBo3sEJWU=;
	b=XRp11Y/2G8NidovpqRIR3jgkjlaZ9EqQMr5im2ROepC3Ya2nRuw5u6mM4DWC/daXUH
	BgLU8tyQxHLd5u2U0JFVpZDQEKVp6jWk3l6TvGEG5mT2YSiOFANuLxzTIGp2Hzu0Rn0B
	CGUxnZ1jLpTVoTj2bDZpN3bjUQg2U66ec8+ccaCTvbyr1n7VUmK3ckL1TpqUrqCPBMQR
	kFE1neiYbI06yBjxGPcVR80UDR3n5A7TQ4/DPH1UIbkAlnemlUvOUsZgVXt4mLZyZhzg
	vkfnNIngr+MCPuWBoYZ12B55qns/zQfrCwkAOpbJG0t4moQjcLiqx7x/Ngm4Y7yzTHYM
	mFmg==
X-Gm-Message-State: ALoCoQm/QXcaSIH3m1M0mcS0yDCm3U0RBcdZk7VOFYlXRb86COudQ91KWmErEhhrOv3hGVhovciw
X-Received: by 10.194.109.226 with SMTP id hv2mr48785626wjb.45.1415029293947; 
	Mon, 03 Nov 2014 07:41:33 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	iz14sm9091887wic.23.2014.11.03.07.41.32 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 07:41:33 -0800 (PST)
Message-ID: <5457A240.3020808@m2r.biz>
Date: Mon, 03 Nov 2014 16:41:52 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Cc: jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Regression: Windows 7 unable to boot with latest
	xen-unstable staging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I tested now latest xen-unstable staging branch of git (commit 
5283b310e14884341f51be35253cdd59c4cb034c) and there is a regression that 
make unable to boot windows 7 pro 64 bit that on build of some days ago 
was working, I not found warning/errors in qemu log and xl dmesg.
I tested also Fedora 20 hvm domU that instead still boot correctly.
I also tried disabling some features (viridian, hdaudiocard, usb 
redirection, vdagent, qxl) but still not boot, remain at initial black 
screen that says "starting windows", in xl list vcpu still remain 1 even 
if 2 setted and time continue small increase.
Probably the regression is caused by one of these commits for now not 
checked with automatic test system:
x86/HVM: only kill guest when unknown VM exit occurred...
VMX: values written to MSR_IA32_SYSENTER_E[IS]P should...
process softirqs while dumping domains

If you need more informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:41:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:41:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJlB-0005c9-My; Mon, 03 Nov 2014 15:41:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XlJl9-0005c3-M1
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 15:41:35 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6B/85-24532-F22A7545; Mon, 03 Nov 2014 15:41:35 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415029294!12473182!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9645 invoked from network); 3 Nov 2014 15:41:34 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:41:34 -0000
Received: by mail-wg0-f53.google.com with SMTP id b13so11189005wgh.26
	for <xen-devel@lists.xensource.com>;
	Mon, 03 Nov 2014 07:41:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:content-type:content-transfer-encoding;
	bh=zVG+bUpgSeVCeWkl86MIrjwEz4WN4ePDiJgBo3sEJWU=;
	b=XRp11Y/2G8NidovpqRIR3jgkjlaZ9EqQMr5im2ROepC3Ya2nRuw5u6mM4DWC/daXUH
	BgLU8tyQxHLd5u2U0JFVpZDQEKVp6jWk3l6TvGEG5mT2YSiOFANuLxzTIGp2Hzu0Rn0B
	CGUxnZ1jLpTVoTj2bDZpN3bjUQg2U66ec8+ccaCTvbyr1n7VUmK3ckL1TpqUrqCPBMQR
	kFE1neiYbI06yBjxGPcVR80UDR3n5A7TQ4/DPH1UIbkAlnemlUvOUsZgVXt4mLZyZhzg
	vkfnNIngr+MCPuWBoYZ12B55qns/zQfrCwkAOpbJG0t4moQjcLiqx7x/Ngm4Y7yzTHYM
	mFmg==
X-Gm-Message-State: ALoCoQm/QXcaSIH3m1M0mcS0yDCm3U0RBcdZk7VOFYlXRb86COudQ91KWmErEhhrOv3hGVhovciw
X-Received: by 10.194.109.226 with SMTP id hv2mr48785626wjb.45.1415029293947; 
	Mon, 03 Nov 2014 07:41:33 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	iz14sm9091887wic.23.2014.11.03.07.41.32 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 07:41:33 -0800 (PST)
Message-ID: <5457A240.3020808@m2r.biz>
Date: Mon, 03 Nov 2014 16:41:52 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Cc: jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Regression: Windows 7 unable to boot with latest
	xen-unstable staging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I tested now latest xen-unstable staging branch of git (commit 
5283b310e14884341f51be35253cdd59c4cb034c) and there is a regression that 
make unable to boot windows 7 pro 64 bit that on build of some days ago 
was working, I not found warning/errors in qemu log and xl dmesg.
I tested also Fedora 20 hvm domU that instead still boot correctly.
I also tried disabling some features (viridian, hdaudiocard, usb 
redirection, vdagent, qxl) but still not boot, remain at initial black 
screen that says "starting windows", in xl list vcpu still remain 1 even 
if 2 setted and time continue small increase.
Probably the regression is caused by one of these commits for now not 
checked with automatic test system:
x86/HVM: only kill guest when unknown VM exit occurred...
VMX: values written to MSR_IA32_SYSENTER_E[IS]P should...
process softirqs while dumping domains

If you need more informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:43:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:43:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJmZ-0005oD-6i; Mon, 03 Nov 2014 15:43:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlJmX-0005o2-Sx
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:43:02 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	BD/2D-09284-582A7545; Mon, 03 Nov 2014 15:43:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415029374!11360855!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18092 invoked from network); 3 Nov 2014 15:43:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:43:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188933799"
Message-ID: <1415029377.24785.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kevin O'Connor <kevin@koconnor.net>
Date: Mon, 3 Nov 2014 15:42:57 +0000
In-Reply-To: <20141103145958.GA27850@morn.localdomain>
References: <1415008770.9994.6.camel@citrix.com>
	<1415009105.9994.8.camel@citrix.com>
	<20141103145958.GA27850@morn.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: seabios@seabios.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS]  Regression booting winxp under Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 09:59 -0500, Kevin O'Connor wrote:
> On Mon, Nov 03, 2014 at 10:05:05AM +0000, Ian Campbell wrote:
> > On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:
> > 
> > > I've not investigated more thoroughly yes, just posting in case
> > > something obvious leaps out at someone. The automated test is currently
> > > bisecting the issue, once it is done I'll let you know the result.
> > 
> > If I'd read a bit further through my Monday morning INBOX I'd have
> > found:
> >         http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
> >         
> > which indicates that the bisector has fingered:
> > 
> >   commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
> 
> Sorry about that - I missed one of the stack offset conversions in the
> PNP part of that change.  The fix is below and I just pushed it to
> the main repo.
> 
> Thanks for catching it.

Thanks for the quick fix!

> -Kevin
> 
> 
> --- a/src/romlayout.S
> +++ b/src/romlayout.S
> @@ -286,7 +286,7 @@ entry_pnp_real:
>          movw %cx, %ds
>          leal BREGS_size-6+12(%esp), %eax  // %eax points to start of u16 args
>          calll handle_pnp
> -        movw %ax, 12(%esp)      // Modify %eax to return %ax
> +        movw %ax, BREGS_eax(%esp)   // Modify %eax to return %ax
>          POPBREGS
>          popfl
>          popl %esp



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:43:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:43:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJmZ-0005oD-6i; Mon, 03 Nov 2014 15:43:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlJmX-0005o2-Sx
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 15:43:02 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	BD/2D-09284-582A7545; Mon, 03 Nov 2014 15:43:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415029374!11360855!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18092 invoked from network); 3 Nov 2014 15:43:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 15:43:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188933799"
Message-ID: <1415029377.24785.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kevin O'Connor <kevin@koconnor.net>
Date: Mon, 3 Nov 2014 15:42:57 +0000
In-Reply-To: <20141103145958.GA27850@morn.localdomain>
References: <1415008770.9994.6.camel@citrix.com>
	<1415009105.9994.8.camel@citrix.com>
	<20141103145958.GA27850@morn.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: seabios@seabios.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS]  Regression booting winxp under Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 09:59 -0500, Kevin O'Connor wrote:
> On Mon, Nov 03, 2014 at 10:05:05AM +0000, Ian Campbell wrote:
> > On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:
> > 
> > > I've not investigated more thoroughly yes, just posting in case
> > > something obvious leaps out at someone. The automated test is currently
> > > bisecting the issue, once it is done I'll let you know the result.
> > 
> > If I'd read a bit further through my Monday morning INBOX I'd have
> > found:
> >         http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
> >         
> > which indicates that the bisector has fingered:
> > 
> >   commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
> 
> Sorry about that - I missed one of the stack offset conversions in the
> PNP part of that change.  The fix is below and I just pushed it to
> the main repo.
> 
> Thanks for catching it.

Thanks for the quick fix!

> -Kevin
> 
> 
> --- a/src/romlayout.S
> +++ b/src/romlayout.S
> @@ -286,7 +286,7 @@ entry_pnp_real:
>          movw %cx, %ds
>          leal BREGS_size-6+12(%esp), %eax  // %eax points to start of u16 args
>          calll handle_pnp
> -        movw %ax, 12(%esp)      // Modify %eax to return %ax
> +        movw %ax, BREGS_eax(%esp)   // Modify %eax to return %ax
>          POPBREGS
>          popfl
>          popl %esp



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:47:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:47:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJqe-0006AO-UY; Mon, 03 Nov 2014 15:47:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XlJqd-0006AJ-A8
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 15:47:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	01/DB-09842-283A7545; Mon, 03 Nov 2014 15:47:14 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415029632!12410385!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5759 invoked from network); 3 Nov 2014 15:47:14 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 15:47:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3Fl6l1026728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 15:47:07 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Fl5TJ028550
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 15:47:06 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Fl5pW028534; Mon, 3 Nov 2014 15:47:05 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 07:47:05 -0800
Message-ID: <5457A401.5040908@oracle.com>
Date: Mon, 03 Nov 2014 10:49:21 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Laszlo Ersek <lersek@redhat.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
	<54577368.9060000@redhat.com>
In-Reply-To: <54577368.9060000@redhat.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xenproject.org, Jeff Moyer <jmoyer@redhat.com>,
	Andrew Jones <drjones@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: improve protection against
 issuing unsupported REQ_FUA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/2014 07:22 AM, Laszlo Ersek wrote:
> On 10/27/14 14:44, Vitaly Kuznetsov wrote:
>> Guard against issuing unsupported REQ_FUA and REQ_FLUSH was introduced
>> in d11e61583 and was factored out into blkif_request_flush_valid() in
>> 0f1ca65ee. However:
>> 1) This check in incomplete. In case we negotiated to feature_flush = REQ_FLUSH
>>     and flush_op = BLKIF_OP_FLUSH_DISKCACHE (so FUA is unsupported) FUA request
>>     will still pass the check.
>> 2) blkif_request_flush_valid() is misnamed. It is bool but returns true when
>>     the request is invalid.
>> 3) When blkif_request_flush_valid() fails -EIO is being returned. It seems that
>>     -EOPNOTSUPP is more appropriate here.
>> Fix all of the above issues.
>>
>> This patch is based on the original patch by Laszlo Ersek and a comment by
>> Jeff Moyer.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>>   drivers/block/xen-blkfront.c | 14 ++++++++------
>>   1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 5ac312f..2e6c103 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -582,12 +582,14 @@ static inline void flush_requests(struct blkfront_info *info)
>>   		notify_remote_via_irq(info->irq);
>>   }
>>   
>> -static inline bool blkif_request_flush_valid(struct request *req,
>> -					     struct blkfront_info *info)
>> +static inline bool blkif_request_flush_invalid(struct request *req,
>> +					       struct blkfront_info *info)
>>   {
>>   	return ((req->cmd_type != REQ_TYPE_FS) ||
>> -		((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
>> -		!info->flush_op));
>> +		((req->cmd_flags & REQ_FLUSH) &&
>> +		 !(info->feature_flush & REQ_FLUSH)) ||
>> +		((req->cmd_flags & REQ_FUA) &&
>> +		 !(info->feature_flush & REQ_FUA)));

Somewhat unrelated to the patch, but I am wondering whether we actually 
need flush_op field at all as it seems that it is unambiguously defined 
by REQ_FLUSH/REQ_FUA.

-boris

>>   }
>>   
>>   /*
>> @@ -612,8 +614,8 @@ static void do_blkif_request(struct request_queue *rq)
>>   
>>   		blk_start_request(req);
>>   
>> -		if (blkif_request_flush_valid(req, info)) {
>> -			__blk_end_request_all(req, -EIO);
>> +		if (blkif_request_flush_invalid(req, info)) {
>> +			__blk_end_request_all(req, -EOPNOTSUPP);
>>   			continue;
>>   		}
>>   
>>
> Not sure if there has been some feedback yet (I can't see anything
> threaded with this message in my inbox).
>
> FWIW I consulted "Documentation/block/writeback_cache_control.txt" for
> this review. Apparently, REQ_FLUSH forces out "previously completed
> write requests", whereas REQ_FUA delays the IO completion signal for
> *this* request until "the data has been committed to non-volatile
> storage". So, indeed, support for REQ_FLUSH only does not guarantee that
> REQ_FUA can be served.
>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
>
> Thanks
> Laszlo


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:47:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:47:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlJqe-0006AO-UY; Mon, 03 Nov 2014 15:47:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XlJqd-0006AJ-A8
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 15:47:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	01/DB-09842-283A7545; Mon, 03 Nov 2014 15:47:14 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415029632!12410385!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5759 invoked from network); 3 Nov 2014 15:47:14 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 15:47:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3Fl6l1026728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 15:47:07 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Fl5TJ028550
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 15:47:06 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Fl5pW028534; Mon, 3 Nov 2014 15:47:05 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 07:47:05 -0800
Message-ID: <5457A401.5040908@oracle.com>
Date: Mon, 03 Nov 2014 10:49:21 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Laszlo Ersek <lersek@redhat.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
	<54577368.9060000@redhat.com>
In-Reply-To: <54577368.9060000@redhat.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xenproject.org, Jeff Moyer <jmoyer@redhat.com>,
	Andrew Jones <drjones@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: improve protection against
 issuing unsupported REQ_FUA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/2014 07:22 AM, Laszlo Ersek wrote:
> On 10/27/14 14:44, Vitaly Kuznetsov wrote:
>> Guard against issuing unsupported REQ_FUA and REQ_FLUSH was introduced
>> in d11e61583 and was factored out into blkif_request_flush_valid() in
>> 0f1ca65ee. However:
>> 1) This check in incomplete. In case we negotiated to feature_flush = REQ_FLUSH
>>     and flush_op = BLKIF_OP_FLUSH_DISKCACHE (so FUA is unsupported) FUA request
>>     will still pass the check.
>> 2) blkif_request_flush_valid() is misnamed. It is bool but returns true when
>>     the request is invalid.
>> 3) When blkif_request_flush_valid() fails -EIO is being returned. It seems that
>>     -EOPNOTSUPP is more appropriate here.
>> Fix all of the above issues.
>>
>> This patch is based on the original patch by Laszlo Ersek and a comment by
>> Jeff Moyer.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>>   drivers/block/xen-blkfront.c | 14 ++++++++------
>>   1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 5ac312f..2e6c103 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -582,12 +582,14 @@ static inline void flush_requests(struct blkfront_info *info)
>>   		notify_remote_via_irq(info->irq);
>>   }
>>   
>> -static inline bool blkif_request_flush_valid(struct request *req,
>> -					     struct blkfront_info *info)
>> +static inline bool blkif_request_flush_invalid(struct request *req,
>> +					       struct blkfront_info *info)
>>   {
>>   	return ((req->cmd_type != REQ_TYPE_FS) ||
>> -		((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
>> -		!info->flush_op));
>> +		((req->cmd_flags & REQ_FLUSH) &&
>> +		 !(info->feature_flush & REQ_FLUSH)) ||
>> +		((req->cmd_flags & REQ_FUA) &&
>> +		 !(info->feature_flush & REQ_FUA)));

Somewhat unrelated to the patch, but I am wondering whether we actually 
need flush_op field at all as it seems that it is unambiguously defined 
by REQ_FLUSH/REQ_FUA.

-boris

>>   }
>>   
>>   /*
>> @@ -612,8 +614,8 @@ static void do_blkif_request(struct request_queue *rq)
>>   
>>   		blk_start_request(req);
>>   
>> -		if (blkif_request_flush_valid(req, info)) {
>> -			__blk_end_request_all(req, -EIO);
>> +		if (blkif_request_flush_invalid(req, info)) {
>> +			__blk_end_request_all(req, -EOPNOTSUPP);
>>   			continue;
>>   		}
>>   
>>
> Not sure if there has been some feedback yet (I can't see anything
> threaded with this message in my inbox).
>
> FWIW I consulted "Documentation/block/writeback_cache_control.txt" for
> this review. Apparently, REQ_FLUSH forces out "previously completed
> write requests", whereas REQ_FUA delays the IO completion signal for
> *this* request until "the data has been committed to non-volatile
> storage". So, indeed, support for REQ_FLUSH only does not guarantee that
> REQ_FUA can be served.
>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
>
> Thanks
> Laszlo


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:59:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:59:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlK2U-0006XA-EF; Mon, 03 Nov 2014 15:59:30 +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 1XlK2S-0006X5-Ry
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 15:59:28 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	FC/85-03148-066A7545; Mon, 03 Nov 2014 15:59:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415030367!8929514!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=2.2 required=7.0 tests=BIZ_TLD,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1630 invoked from network); 3 Nov 2014 15:59:27 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 15:59:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 15:59:27 +0000
Message-Id: <5457B46C0200007800044812@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 15:59:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Fabio Fantoni" <fabio.fantoni@m2r.biz>
References: <5457A240.3020808@m2r.biz>
In-Reply-To: <5457A240.3020808@m2r.biz>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Regression: Windows 7 unable to boot with latest
 xen-unstable staging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 16:41, <fabio.fantoni@m2r.biz> wrote:
> I tested now latest xen-unstable staging branch of git (commit 
> 5283b310e14884341f51be35253cdd59c4cb034c) and there is a regression that 
> make unable to boot windows 7 pro 64 bit that on build of some days ago 
> was working, I not found warning/errors in qemu log and xl dmesg.
> I tested also Fedora 20 hvm domU that instead still boot correctly.
> I also tried disabling some features (viridian, hdaudiocard, usb 
> redirection, vdagent, qxl) but still not boot, remain at initial black 
> screen that says "starting windows", in xl list vcpu still remain 1 even 
> if 2 setted and time continue small increase.
> Probably the regression is caused by one of these commits for now not 
> checked with automatic test system:
> x86/HVM: only kill guest when unknown VM exit occurred...
> VMX: values written to MSR_IA32_SYSENTER_E[IS]P should...
> process softirqs while dumping domains
> 
> If you need more informations/tests tell me and I'll post them.

This doesn't match up with the most recent osstest flight (31315),
which didn't show any booting problems with Win7 guests. Hence
narrowing to one of the three commits as well as telling us any
specifics your guest (or host) configuration may differ from
osstest's (e.g. pass-through being used) would be rather helpful.

Also, just to make sure - you're not using the upstream SeaBIOS
tree, and hence aren't suffering from the regression recently
introduced there (tentative fix was already posted)?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 15:59:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 15:59:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlK2U-0006XA-EF; Mon, 03 Nov 2014 15:59:30 +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 1XlK2S-0006X5-Ry
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 15:59:28 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	FC/85-03148-066A7545; Mon, 03 Nov 2014 15:59:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415030367!8929514!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=2.2 required=7.0 tests=BIZ_TLD,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1630 invoked from network); 3 Nov 2014 15:59:27 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 15:59:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 03 Nov 2014 15:59:27 +0000
Message-Id: <5457B46C0200007800044812@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 03 Nov 2014 15:59:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Fabio Fantoni" <fabio.fantoni@m2r.biz>
References: <5457A240.3020808@m2r.biz>
In-Reply-To: <5457A240.3020808@m2r.biz>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Regression: Windows 7 unable to boot with latest
 xen-unstable staging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 16:41, <fabio.fantoni@m2r.biz> wrote:
> I tested now latest xen-unstable staging branch of git (commit 
> 5283b310e14884341f51be35253cdd59c4cb034c) and there is a regression that 
> make unable to boot windows 7 pro 64 bit that on build of some days ago 
> was working, I not found warning/errors in qemu log and xl dmesg.
> I tested also Fedora 20 hvm domU that instead still boot correctly.
> I also tried disabling some features (viridian, hdaudiocard, usb 
> redirection, vdagent, qxl) but still not boot, remain at initial black 
> screen that says "starting windows", in xl list vcpu still remain 1 even 
> if 2 setted and time continue small increase.
> Probably the regression is caused by one of these commits for now not 
> checked with automatic test system:
> x86/HVM: only kill guest when unknown VM exit occurred...
> VMX: values written to MSR_IA32_SYSENTER_E[IS]P should...
> process softirqs while dumping domains
> 
> If you need more informations/tests tell me and I'll post them.

This doesn't match up with the most recent osstest flight (31315),
which didn't show any booting problems with Win7 guests. Hence
narrowing to one of the three commits as well as telling us any
specifics your guest (or host) configuration may differ from
osstest's (e.g. pass-through being used) would be rather helpful.

Also, just to make sure - you're not using the upstream SeaBIOS
tree, and hence aren't suffering from the regression recently
introduced there (tentative fix was already posted)?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:05:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:05:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlK7z-00079K-Ez; Mon, 03 Nov 2014 16:05:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlK7y-00079F-Mr
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 16:05:10 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	43/9A-22819-5B7A7545; Mon, 03 Nov 2014 16:05:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415030707!10966020!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29603 invoked from network); 3 Nov 2014 16:05:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 16:05:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3G4Z3X025991
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 16:04:36 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA3FGNxJ005961
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 15:16:25 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3G4XjA010625; Mon, 3 Nov 2014 16:04:33 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 08:04:32 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2028D10FEFD; Mon,  3 Nov 2014 11:04:31 -0500 (EST)
Date: Mon, 3 Nov 2014 11:04:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141103160431.GE1638@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031044480.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411031044480.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, linux-arm-kernel@lists.infradead.org,
	david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH v7 7/8] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 10:45:14AM +0000, Stefano Stabellini wrote:
> On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > Introduce an arch specific function to find out whether a particular dma
> > mapping operation needs to bounce on the swiotlb buffer.
> > 
> > On ARM and ARM64, if the page involved is a foreign page and the device
> > is not coherent, we need to bounce because at unmap time we cannot
> > execute any required cache maintenance operations (we don't know how to
> > find the pfn from the mfn).
> > 
> > No change of behaviour for x86.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Konrad, David, are you OK with the swiotlb-xen changes?

I am OK.
> 
> 
>  
> > Changes in v6:
> > - fix ts.
> > 
> > Changes in v5:
> > - fix indentation.
> > ---
> >  arch/arm/include/asm/xen/page.h |    4 ++++
> >  arch/arm/xen/mm.c               |    7 +++++++
> >  arch/x86/include/asm/xen/page.h |    7 +++++++
> >  drivers/xen/swiotlb-xen.c       |    5 ++++-
> >  4 files changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> > index 135c24a..68c739b 100644
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> >  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
> >  #define xen_unmap(cookie) iounmap((cookie))
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn);
> > +
> >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> > index ff413a8..28396aa 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -139,6 +139,13 @@ void xen_dma_sync_single_for_device(struct device *hwdev,
> >  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
> >  }
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn)
> > +{
> > +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> > +}
> > +
> >  int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
> >  				 unsigned int address_bits,
> >  				 dma_addr_t *dma_handle)
> > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > index c949923..f58ef6c 100644
> > --- a/arch/x86/include/asm/xen/page.h
> > +++ b/arch/x86/include/asm/xen/page.h
> > @@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
> >  #define xen_remap(cookie, size) ioremap((cookie), (size));
> >  #define xen_unmap(cookie) iounmap((cookie))
> >  
> > +static inline bool xen_arch_need_swiotlb(struct device *dev,
> > +					 unsigned long pfn,
> > +					 unsigned long mfn)
> > +{
> > +	return false;
> > +}
> > +
> >  #endif /* _ASM_X86_XEN_PAGE_H */
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ebd8f21..ac5d41b 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
> >  	 * buffering it.
> >  	 */
> >  	if (dma_capable(dev, dev_addr, size) &&
> > -	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
> > +	    !range_straddles_page_boundary(phys, size) &&
> > +		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
> > +		!swiotlb_force) {
> >  		/* we are not interested in the dma_addr returned by
> >  		 * xen_dma_map_page, only in the potential cache flushes executed
> >  		 * by the function. */
> > @@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
> >  		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
> >  
> >  		if (swiotlb_force ||
> > +		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
> >  		    !dma_capable(hwdev, dev_addr, sg->length) ||
> >  		    range_straddles_page_boundary(paddr, sg->length)) {
> >  			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
> > -- 
> > 1.7.10.4
> > 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:05:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:05:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlK7z-00079K-Ez; Mon, 03 Nov 2014 16:05:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlK7y-00079F-Mr
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 16:05:10 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	43/9A-22819-5B7A7545; Mon, 03 Nov 2014 16:05:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415030707!10966020!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29603 invoked from network); 3 Nov 2014 16:05:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 16:05:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3G4Z3X025991
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 16:04:36 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA3FGNxJ005961
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 15:16:25 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3G4XjA010625; Mon, 3 Nov 2014 16:04:33 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 08:04:32 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2028D10FEFD; Mon,  3 Nov 2014 11:04:31 -0500 (EST)
Date: Mon, 3 Nov 2014 11:04:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141103160431.GE1638@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031044480.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411031044480.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, linux-arm-kernel@lists.infradead.org,
	david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH v7 7/8] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 10:45:14AM +0000, Stefano Stabellini wrote:
> On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > Introduce an arch specific function to find out whether a particular dma
> > mapping operation needs to bounce on the swiotlb buffer.
> > 
> > On ARM and ARM64, if the page involved is a foreign page and the device
> > is not coherent, we need to bounce because at unmap time we cannot
> > execute any required cache maintenance operations (we don't know how to
> > find the pfn from the mfn).
> > 
> > No change of behaviour for x86.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Konrad, David, are you OK with the swiotlb-xen changes?

I am OK.
> 
> 
>  
> > Changes in v6:
> > - fix ts.
> > 
> > Changes in v5:
> > - fix indentation.
> > ---
> >  arch/arm/include/asm/xen/page.h |    4 ++++
> >  arch/arm/xen/mm.c               |    7 +++++++
> >  arch/x86/include/asm/xen/page.h |    7 +++++++
> >  drivers/xen/swiotlb-xen.c       |    5 ++++-
> >  4 files changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> > index 135c24a..68c739b 100644
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> >  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
> >  #define xen_unmap(cookie) iounmap((cookie))
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn);
> > +
> >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> > index ff413a8..28396aa 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -139,6 +139,13 @@ void xen_dma_sync_single_for_device(struct device *hwdev,
> >  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
> >  }
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn)
> > +{
> > +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> > +}
> > +
> >  int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
> >  				 unsigned int address_bits,
> >  				 dma_addr_t *dma_handle)
> > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > index c949923..f58ef6c 100644
> > --- a/arch/x86/include/asm/xen/page.h
> > +++ b/arch/x86/include/asm/xen/page.h
> > @@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
> >  #define xen_remap(cookie, size) ioremap((cookie), (size));
> >  #define xen_unmap(cookie) iounmap((cookie))
> >  
> > +static inline bool xen_arch_need_swiotlb(struct device *dev,
> > +					 unsigned long pfn,
> > +					 unsigned long mfn)
> > +{
> > +	return false;
> > +}
> > +
> >  #endif /* _ASM_X86_XEN_PAGE_H */
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ebd8f21..ac5d41b 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
> >  	 * buffering it.
> >  	 */
> >  	if (dma_capable(dev, dev_addr, size) &&
> > -	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
> > +	    !range_straddles_page_boundary(phys, size) &&
> > +		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
> > +		!swiotlb_force) {
> >  		/* we are not interested in the dma_addr returned by
> >  		 * xen_dma_map_page, only in the potential cache flushes executed
> >  		 * by the function. */
> > @@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
> >  		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
> >  
> >  		if (swiotlb_force ||
> > +		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
> >  		    !dma_capable(hwdev, dev_addr, sg->length) ||
> >  		    range_straddles_page_boundary(paddr, sg->length)) {
> >  			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
> > -- 
> > 1.7.10.4
> > 

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:06:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16: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.xen.org>)
	id 1XlK90-0007Fy-WF; Mon, 03 Nov 2014 16:06:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlK8z-0007Fj-2q
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 16:06:13 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	2E/6A-14214-4F7A7545; Mon, 03 Nov 2014 16:06:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415030768!10966291!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3900 invoked from network); 3 Nov 2014 16:06:10 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 16:06:10 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3G3v6w025095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 16:03:58 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3G3r5v008390
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 16:03:54 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3G3pht008272; Mon, 3 Nov 2014 16:03:51 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 08:03:50 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2461910FEFB; Mon,  3 Nov 2014 11:03:47 -0500 (EST)
Date: Mon, 3 Nov 2014 11:03:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Message-ID: <20141103160347.GD1638@laptop.dumpdata.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<544B5AF5.7050103@m2r.biz>
	<20141027161542.GK4050@laptop.dumpdata.com>
	<544F987E.5060508@m2r.biz>
	<20141028171811.GA27336@laptop.dumpdata.com>
	<CABMPFziN9eM6_0_mfQcamOqyQBXVOOD5amom+7JTv=LorbbTeQ@mail.gmail.com>
	<20141031143338.GB6913@laptop.dumpdata.com>
	<54576188.9050500@m2r.biz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54576188.9050500@m2r.biz>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Artem Mygaiev <artem.mygaiev@globallogic.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, mengxu@cis.upenn.edu,
	M A Young <m.a.young@durham.ac.uk>, chao.p.peng@linux.intel.com,
	zhigang.x.wang@oracle.com, Parth Dixit <parth.dixit@linaro.org>,
	davi.d.vrabel@citrix.com, Paul.Skentzos@dornerworks.com,
	wency@cn.fujitsu.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, Daniel Kiper <daniel.kiper@oracle.com>,
	josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	yjhyun.yoo@samsung.com, Olaf Hering <olaf@aepfle.de>,
	Ian Campbell <ian.campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mcgrof@suse.com, Julien Grall <julien.grall@linaro.org>,
	Dave Scott <dave.scott@citrix.com>, robert.vanvossen@dornerworks.com,
	Roy Franz <roy.franz@linaro.org>, Yang Z Zhang <yang.z.zhang@intel.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Matt Wilson <msw@amazon.com>, boris.ostrovsky@oracle.com,
	andrii.tseglytskyi@globallogic.com, Juergen Gross <jgross@suse.com>,
	Thomas Leonard <talex5@gmail.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, aravindp@cisco.com,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Suriyan Ramasami <suriyan.r@gmail.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Steve.VanderLeest@dornerworks.com, Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	Don Slutz <dslutz@verizon.com>, tklengyel@sec.in.tum.de,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Suravee.Suthikulpanit@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tiejun Chen <tiejun.chen@intel.com>, malcolm.crossley@citrix.com,
	yanghy@cn.fujitsu.com, Vijaya.Kumar@caviumnetworks.com,
	feng.wu@intel.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Is: QXL in Xen (busted) Was :Re: Xen 4.5-rc1 update
 (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 12:05:44PM +0100, Fabio Fantoni wrote:
> Il 31/10/2014 15:33, Konrad Rzeszutek Wilk ha scritto:
> >>I always posted all versions of the patch in xen-devel, the latest was long
> >>time ago.
> >Sometimes you need to poke the maintainers. They (at least
> >I do) have mailboxes so packed that sometimes emails end up
> >going missing. But I think their arguments is going to be:
> >lets figure out what is broken before putting this in the source.
> >
> >.. snip..
> >>>Does SPICE always have to be enabled to use QXL?
> >>>
> >.. snip ..
> >>Xen with spice full working on both windows and linux (including
> >>save/restore) used for both vkvm and thin client I think would be perfect.
> >Right. But there is some work needed in that area (figure out what
> >is happening on Linux).
> >
> >..snip..
> >>>OK, looking at how the driver is setup - it seems that there is an QXL
> >>>KMS driver. If you boot without Xorg running but just with in the console
> >>>can
> >>>you use 'fbset' or any other framebuffer tools (linux-fb-tools)?
> >>>That is I am curious to see whether the 'FB' is working properly first
> >>>before figuring out whether Xorg is working.
> >>>
> >>Some tests ago I tried without xorg to see if kernel parts is ok (advice of
> >>other developer) and seems was ok.
> >What did you test? There is an 'drm-test' tool that was floating around?
> >(http://cgit.freedesktop.org/mesa/drm/)
> >
> >It allows you to run most (if not all) of the Xorg functionality - but
> >using an tool from user-space - and with much more exposure of what
> >went wrong.
> >
> >Could you try the following (without having Xorg in either guest):
> >  1). Boot up your KVM guest, install said tool - run it. Record what
> >     works and what does not.
> >
> >  2). Boot up your Xen guest, and do the same thing.
> >
> >That should narrow down which of the hundreds' of DRM ioctls is failing
> >when using spice under Xen. And that ought to help narrow down this further.
> >
> >I can help you a bit by sending you some debug patches, thought I do
> >have to warn you that I am under a lot of time-pressure so my response
> >is not as fast as I would want it to be.
> >
> 
> I tested only without xorg, just console with drm without particular tests.
> 
> I can't find the drm-test tool you mentioned, is it available in debian
> and/or fedora repositories an what is it called?
> I also did a quick google search and found only something about wayland and
> not about X.org.

I mentioned the URL in the email, but here it is again:

http://cgit.freedesktop.org/mesa/drm/

You will need to compile it, etc.
> 
> Thanks for any reply and sorry for my bad english.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:06:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16: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.xen.org>)
	id 1XlK90-0007Fy-WF; Mon, 03 Nov 2014 16:06:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlK8z-0007Fj-2q
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 16:06:13 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	2E/6A-14214-4F7A7545; Mon, 03 Nov 2014 16:06:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415030768!10966291!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3900 invoked from network); 3 Nov 2014 16:06:10 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 16:06:10 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3G3v6w025095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 16:03:58 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3G3r5v008390
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 16:03:54 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3G3pht008272; Mon, 3 Nov 2014 16:03:51 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 08:03:50 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2461910FEFB; Mon,  3 Nov 2014 11:03:47 -0500 (EST)
Date: Mon, 3 Nov 2014 11:03:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Message-ID: <20141103160347.GD1638@laptop.dumpdata.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<544B5AF5.7050103@m2r.biz>
	<20141027161542.GK4050@laptop.dumpdata.com>
	<544F987E.5060508@m2r.biz>
	<20141028171811.GA27336@laptop.dumpdata.com>
	<CABMPFziN9eM6_0_mfQcamOqyQBXVOOD5amom+7JTv=LorbbTeQ@mail.gmail.com>
	<20141031143338.GB6913@laptop.dumpdata.com>
	<54576188.9050500@m2r.biz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54576188.9050500@m2r.biz>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Artem Mygaiev <artem.mygaiev@globallogic.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, mengxu@cis.upenn.edu,
	M A Young <m.a.young@durham.ac.uk>, chao.p.peng@linux.intel.com,
	zhigang.x.wang@oracle.com, Parth Dixit <parth.dixit@linaro.org>,
	davi.d.vrabel@citrix.com, Paul.Skentzos@dornerworks.com,
	wency@cn.fujitsu.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, Daniel Kiper <daniel.kiper@oracle.com>,
	josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	yjhyun.yoo@samsung.com, Olaf Hering <olaf@aepfle.de>,
	Ian Campbell <ian.campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mcgrof@suse.com, Julien Grall <julien.grall@linaro.org>,
	Dave Scott <dave.scott@citrix.com>, robert.vanvossen@dornerworks.com,
	Roy Franz <roy.franz@linaro.org>, Yang Z Zhang <yang.z.zhang@intel.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Matt Wilson <msw@amazon.com>, boris.ostrovsky@oracle.com,
	andrii.tseglytskyi@globallogic.com, Juergen Gross <jgross@suse.com>,
	Thomas Leonard <talex5@gmail.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, aravindp@cisco.com,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Suriyan Ramasami <suriyan.r@gmail.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Steve.VanderLeest@dornerworks.com, Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	Don Slutz <dslutz@verizon.com>, tklengyel@sec.in.tum.de,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Suravee.Suthikulpanit@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tiejun Chen <tiejun.chen@intel.com>, malcolm.crossley@citrix.com,
	yanghy@cn.fujitsu.com, Vijaya.Kumar@caviumnetworks.com,
	feng.wu@intel.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Is: QXL in Xen (busted) Was :Re: Xen 4.5-rc1 update
 (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 12:05:44PM +0100, Fabio Fantoni wrote:
> Il 31/10/2014 15:33, Konrad Rzeszutek Wilk ha scritto:
> >>I always posted all versions of the patch in xen-devel, the latest was long
> >>time ago.
> >Sometimes you need to poke the maintainers. They (at least
> >I do) have mailboxes so packed that sometimes emails end up
> >going missing. But I think their arguments is going to be:
> >lets figure out what is broken before putting this in the source.
> >
> >.. snip..
> >>>Does SPICE always have to be enabled to use QXL?
> >>>
> >.. snip ..
> >>Xen with spice full working on both windows and linux (including
> >>save/restore) used for both vkvm and thin client I think would be perfect.
> >Right. But there is some work needed in that area (figure out what
> >is happening on Linux).
> >
> >..snip..
> >>>OK, looking at how the driver is setup - it seems that there is an QXL
> >>>KMS driver. If you boot without Xorg running but just with in the console
> >>>can
> >>>you use 'fbset' or any other framebuffer tools (linux-fb-tools)?
> >>>That is I am curious to see whether the 'FB' is working properly first
> >>>before figuring out whether Xorg is working.
> >>>
> >>Some tests ago I tried without xorg to see if kernel parts is ok (advice of
> >>other developer) and seems was ok.
> >What did you test? There is an 'drm-test' tool that was floating around?
> >(http://cgit.freedesktop.org/mesa/drm/)
> >
> >It allows you to run most (if not all) of the Xorg functionality - but
> >using an tool from user-space - and with much more exposure of what
> >went wrong.
> >
> >Could you try the following (without having Xorg in either guest):
> >  1). Boot up your KVM guest, install said tool - run it. Record what
> >     works and what does not.
> >
> >  2). Boot up your Xen guest, and do the same thing.
> >
> >That should narrow down which of the hundreds' of DRM ioctls is failing
> >when using spice under Xen. And that ought to help narrow down this further.
> >
> >I can help you a bit by sending you some debug patches, thought I do
> >have to warn you that I am under a lot of time-pressure so my response
> >is not as fast as I would want it to be.
> >
> 
> I tested only without xorg, just console with drm without particular tests.
> 
> I can't find the drm-test tool you mentioned, is it available in debian
> and/or fedora repositories an what is it called?
> I also did a quick google search and found only something about wayland and
> not about X.org.

I mentioned the URL in the email, but here it is again:

http://cgit.freedesktop.org/mesa/drm/

You will need to compile it, etc.
> 
> Thanks for any reply and sorry for my bad english.

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:07:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlK9x-0007Os-JV; Mon, 03 Nov 2014 16:07:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XlK9w-0007Of-Aw
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 16:07:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8B/A4-09936-F28A7545; Mon, 03 Nov 2014 16:07:11 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415030823!12428591!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=2.2 required=7.0 tests=BIZ_TLD,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14928 invoked from network); 3 Nov 2014 16:07:06 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:07:06 -0000
Received: by mail-wi0-f170.google.com with SMTP id q5so6458639wiv.1
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 08:07:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=AZ5ZqFTzWexdWUrBzNaqbzCEEnJ+FbykV4rTIsvjqOk=;
	b=IXmtPHNaiFgDwQhvVTkI/M/aef2KcDPbsYBs9hwG+6TDdwZ1A63SbgQ9koiqEX73gC
	96GM8IcWrYoiT87PH3G5yhd4kmYv8ylflK1769ZyT8EsUPdBHD1E4yUnnJnHx1XCwuU9
	z12I/yvHBRXNhrsxcqLmaMP2S6lfwPdF8Tnln4l+tcgHUqjfMIyenIvDtKWwkchKikah
	vaK1LiYDGSzeWwIqDD1UcgCshnqgAxd96a/xIdK8cDCmj7CcOAb2JeftVQF2eHe7nMfF
	Us+fcdhi6plqo2z9RCPhWxPwvNvniCB630wEYdY88zAOCmSWfLPdZRzirpwRlu9kyv3I
	XvIw==
X-Gm-Message-State: ALoCoQkcbwU0IQq0Q7En64icuoBgI/MJViuclhIpYSNXidB6UTD8o4NiDbeKfz3Akll+CwpIS/MS
X-Received: by 10.194.239.164 with SMTP id vt4mr3524547wjc.131.1415030823568; 
	Mon, 03 Nov 2014 08:07:03 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id s8sm22654717wjx.9.2014.11.03.08.07.02
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 08:07:03 -0800 (PST)
Message-ID: <5457A83A.9090004@m2r.biz>
Date: Mon, 03 Nov 2014 17:07:22 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5457A240.3020808@m2r.biz>
	<5457B46C0200007800044812@mail.emea.novell.com>
In-Reply-To: <5457B46C0200007800044812@mail.emea.novell.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Regression: Windows 7 unable to boot with latest
 xen-unstable staging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 03/11/2014 16:59, Jan Beulich ha scritto:
>>>> On 03.11.14 at 16:41, <fabio.fantoni@m2r.biz> wrote:
>> I tested now latest xen-unstable staging branch of git (commit
>> 5283b310e14884341f51be35253cdd59c4cb034c) and there is a regression that
>> make unable to boot windows 7 pro 64 bit that on build of some days ago
>> was working, I not found warning/errors in qemu log and xl dmesg.
>> I tested also Fedora 20 hvm domU that instead still boot correctly.
>> I also tried disabling some features (viridian, hdaudiocard, usb
>> redirection, vdagent, qxl) but still not boot, remain at initial black
>> screen that says "starting windows", in xl list vcpu still remain 1 even
>> if 2 setted and time continue small increase.
>> Probably the regression is caused by one of these commits for now not
>> checked with automatic test system:
>> x86/HVM: only kill guest when unknown VM exit occurred...
>> VMX: values written to MSR_IA32_SYSENTER_E[IS]P should...
>> process softirqs while dumping domains
>>
>> If you need more informations/tests tell me and I'll post them.
> This doesn't match up with the most recent osstest flight (31315),
> which didn't show any booting problems with Win7 guests. Hence
> narrowing to one of the three commits as well as telling us any
> specifics your guest (or host) configuration may differ from
> osstest's (e.g. pass-through being used) would be rather helpful.
>
> Also, just to make sure - you're not using the upstream SeaBIOS
> tree, and hence aren't suffering from the regression recently
> introduced there (tentative fix was already posted)?
>
> Jan
>

Thanks for your reply.

I use seabios from debian package 1.7.5-1, same of the previous build 
working, upstream qemu 2.0 from xen-unstable git (same also that).

domU's xl cfg of my latest tests disabling some features (that still not 
booting):
> name='W7-02'
> builder="hvm"
> memory=2048
> vcpus=2
> acpi_s3=0
> acpi_s4=0
> vif=['bridge=xenbr0,mac=00:16:3e:42:a2:5f']
> disk=['/mnt/vm/disks/W7-02.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
> boot='dc'
> device_model_version="qemu-xen"
> #viridian=1
> vnc=0
> keymap="it"
> on_crash="destroy"
> vga="stdvga"
> spice=1
> spicehost='0.0.0.0'
> spiceport=6003
> spicedisable_ticketing=1
> #spicevdagent=1
> spice_clipboard_sharing=0
> #spiceusbredirection=4
> #soundhw="hda"
> localtime=1

If you need more informations/tests tell me and I'll post them.



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:07:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlK9x-0007Os-JV; Mon, 03 Nov 2014 16:07:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XlK9w-0007Of-Aw
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 16:07:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8B/A4-09936-F28A7545; Mon, 03 Nov 2014 16:07:11 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415030823!12428591!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=2.2 required=7.0 tests=BIZ_TLD,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14928 invoked from network); 3 Nov 2014 16:07:06 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:07:06 -0000
Received: by mail-wi0-f170.google.com with SMTP id q5so6458639wiv.1
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 08:07:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=AZ5ZqFTzWexdWUrBzNaqbzCEEnJ+FbykV4rTIsvjqOk=;
	b=IXmtPHNaiFgDwQhvVTkI/M/aef2KcDPbsYBs9hwG+6TDdwZ1A63SbgQ9koiqEX73gC
	96GM8IcWrYoiT87PH3G5yhd4kmYv8ylflK1769ZyT8EsUPdBHD1E4yUnnJnHx1XCwuU9
	z12I/yvHBRXNhrsxcqLmaMP2S6lfwPdF8Tnln4l+tcgHUqjfMIyenIvDtKWwkchKikah
	vaK1LiYDGSzeWwIqDD1UcgCshnqgAxd96a/xIdK8cDCmj7CcOAb2JeftVQF2eHe7nMfF
	Us+fcdhi6plqo2z9RCPhWxPwvNvniCB630wEYdY88zAOCmSWfLPdZRzirpwRlu9kyv3I
	XvIw==
X-Gm-Message-State: ALoCoQkcbwU0IQq0Q7En64icuoBgI/MJViuclhIpYSNXidB6UTD8o4NiDbeKfz3Akll+CwpIS/MS
X-Received: by 10.194.239.164 with SMTP id vt4mr3524547wjc.131.1415030823568; 
	Mon, 03 Nov 2014 08:07:03 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id s8sm22654717wjx.9.2014.11.03.08.07.02
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 08:07:03 -0800 (PST)
Message-ID: <5457A83A.9090004@m2r.biz>
Date: Mon, 03 Nov 2014 17:07:22 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5457A240.3020808@m2r.biz>
	<5457B46C0200007800044812@mail.emea.novell.com>
In-Reply-To: <5457B46C0200007800044812@mail.emea.novell.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Regression: Windows 7 unable to boot with latest
 xen-unstable staging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 03/11/2014 16:59, Jan Beulich ha scritto:
>>>> On 03.11.14 at 16:41, <fabio.fantoni@m2r.biz> wrote:
>> I tested now latest xen-unstable staging branch of git (commit
>> 5283b310e14884341f51be35253cdd59c4cb034c) and there is a regression that
>> make unable to boot windows 7 pro 64 bit that on build of some days ago
>> was working, I not found warning/errors in qemu log and xl dmesg.
>> I tested also Fedora 20 hvm domU that instead still boot correctly.
>> I also tried disabling some features (viridian, hdaudiocard, usb
>> redirection, vdagent, qxl) but still not boot, remain at initial black
>> screen that says "starting windows", in xl list vcpu still remain 1 even
>> if 2 setted and time continue small increase.
>> Probably the regression is caused by one of these commits for now not
>> checked with automatic test system:
>> x86/HVM: only kill guest when unknown VM exit occurred...
>> VMX: values written to MSR_IA32_SYSENTER_E[IS]P should...
>> process softirqs while dumping domains
>>
>> If you need more informations/tests tell me and I'll post them.
> This doesn't match up with the most recent osstest flight (31315),
> which didn't show any booting problems with Win7 guests. Hence
> narrowing to one of the three commits as well as telling us any
> specifics your guest (or host) configuration may differ from
> osstest's (e.g. pass-through being used) would be rather helpful.
>
> Also, just to make sure - you're not using the upstream SeaBIOS
> tree, and hence aren't suffering from the regression recently
> introduced there (tentative fix was already posted)?
>
> Jan
>

Thanks for your reply.

I use seabios from debian package 1.7.5-1, same of the previous build 
working, upstream qemu 2.0 from xen-unstable git (same also that).

domU's xl cfg of my latest tests disabling some features (that still not 
booting):
> name='W7-02'
> builder="hvm"
> memory=2048
> vcpus=2
> acpi_s3=0
> acpi_s4=0
> vif=['bridge=xenbr0,mac=00:16:3e:42:a2:5f']
> disk=['/mnt/vm/disks/W7-02.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
> boot='dc'
> device_model_version="qemu-xen"
> #viridian=1
> vnc=0
> keymap="it"
> on_crash="destroy"
> vga="stdvga"
> spice=1
> spicehost='0.0.0.0'
> spiceport=6003
> spicedisable_ticketing=1
> #spicevdagent=1
> spice_clipboard_sharing=0
> #spiceusbredirection=4
> #soundhw="hda"
> localtime=1

If you need more informations/tests tell me and I'll post them.



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:40:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlKg5-0008OI-LO; Mon, 03 Nov 2014 16:40:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlKg4-0008OD-Kx
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 16:40:24 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	A9/A6-26740-7FFA7545; Mon, 03 Nov 2014 16:40:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415032821!11383065!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5056 invoked from network); 3 Nov 2014 16:40:22 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 16:40:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3Gd8u6006388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 16:39:08 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Gd6VZ014152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 16:39:06 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Gd65q014141; Mon, 3 Nov 2014 16:39:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 08:39:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 42A2210FF36; Mon,  3 Nov 2014 11:39:04 -0500 (EST)
Date: Mon, 3 Nov 2014 11:39:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Vijay Kilari <vijay.kilari@gmail.com>
Message-ID: <20141103163904.GF1638@laptop.dumpdata.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 06:07:33PM +0530, Vijay Kilari wrote:
> On Mon, Nov 3, 2014 at 4:31 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Sat, 1 Nov 2014, Julien Grall wrote:
> >> The vGIC will emulate the same version as the hardware. The toolstack has
> >> to retrieve the version of the vGIC in order to be able to create the
> >> corresponding device tree node.
> >>
> >> A new DOMCTL has been introduced for ARM to configure the domain. For now
> >> it only allow the toolstack to retrieve the version of vGIC.
> >> This DOMCTL will be extend later to let the user choose the version of the
> >> emulated GIC.
> >>
> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> >> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >> Cc: Jan Beulich <jbeulich@suse.com>
> >> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >> Cc: Wei Liu <wei.liu2@citrix.com>
> >
> > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Tested with GICv3 platform.

Thank you for doing that.

It also needs Acks from Daniel and Jan.

> 
> >
> >
> >>     Changes in v2:
> >>         - Use memcpu in xc_domain_configure
> >>         - Rename the DOMCTL into domctl_arm_configuredomain
> >>         - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
> >>         and fold the code in arch_domain_init_hw_description
> >>         - Return -EOPNOTSUPP when the value of gic_version is not
> >>         supported
> >>
> >> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> >> defer the initialization of the vGIC [2].
> >>
> >> Xen 4.5 has already support for the hardware GICv3. While it's possible to
> >> boot and use DOM0, there is no guest support. The first version of this patch
> >> has been sent a couple of months ago, but has never reached unstable for
> >> various reasons (based on deferred series, lake of review at that time...).
> >> Without it, platform with GICv3 support won't be able to boot any guest.
> >>
> >> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> >> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
> >>
> >> Features such as adding a new config option to let the user choose the GIC
> >> version are deferred to Xen 4.6.
> >>
> >> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
> >>
> >> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> >> [2] https://patches.linaro.org/34664/
> >> ---
> >>  tools/flask/policy/policy/modules/xen/xen.if |    2 +-
> >>  tools/libxc/include/xenctrl.h                |    6 ++
> >>  tools/libxc/xc_domain.c                      |   20 ++++++
> >>  tools/libxl/libxl_arm.c                      |   97 ++++++++++++++++++++++++--
> >>  xen/arch/arm/domctl.c                        |   35 ++++++++++
> >>  xen/arch/arm/gic-v3.c                        |   16 ++++-
> >>  xen/include/public/arch-arm.h                |   16 +++++
> >>  xen/include/public/domctl.h                  |   17 +++++
> >>  xen/xsm/flask/hooks.c                        |    3 +
> >>  xen/xsm/flask/policy/access_vectors          |    2 +
> >>  10 files changed, 206 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> >> index 641c797..fa69c9d 100644
> >> --- a/tools/flask/policy/policy/modules/xen/xen.if
> >> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> >> @@ -49,7 +49,7 @@ define(`create_domain_common', `
> >>                       getdomaininfo hypercall setvcpucontext setextvcpucontext
> >>                       getscheduler getvcpuinfo getvcpuextstate getaddrsize
> >>                       getaffinity setaffinity };
> >> -     allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> >> +     allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
> >>       allow $1 $2:security check_context;
> >>       allow $1 $2:shadow enable;
> >>       allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> >> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> >> index 564e187..45e282c 100644
> >> --- a/tools/libxc/include/xenctrl.h
> >> +++ b/tools/libxc/include/xenctrl.h
> >> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
> >>                       uint32_t flags,
> >>                       uint32_t *pdomid);
> >>
> >> +#if defined(__arm__) || defined(__aarch64__)
> >> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> >> +
> >> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> >> +                        xc_domain_configuration_t *config);
> >> +#endif
> >>
> >>  /* Functions to produce a dump of a given domain
> >>   *  xc_domain_dumpcore - produces a dump to a specified file
> >> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> >> index a9bcd4a..1aa1f45 100644
> >> --- a/tools/libxc/xc_domain.c
> >> +++ b/tools/libxc/xc_domain.c
> >> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
> >>      return 0;
> >>  }
> >>
> >> +#if defined(__arm__) || defined(__aarch64__)
> >> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> >> +                        xc_domain_configuration_t *config)
> >> +{
> >> +    int rc;
> >> +    DECLARE_DOMCTL;
> >> +
> >> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> >> +    domctl.domain = (domid_t)domid;
> >> +    /* xc_domain_configure_t is an alias to xen_domctl_arm_configuredomain */
> >> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
> >> +
> >> +    rc = do_domctl(xch, &domctl);
> >> +    if ( !rc )
> >> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> >> +
> >> +    return rc;
> >> +}
> >> +#endif
> >> +
> >>  int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
> >>                           xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
> >>  {
> >> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> >> index a122e4a..3dd6e7c 100644
> >> --- a/tools/libxl/libxl_arm.c
> >> +++ b/tools/libxl/libxl_arm.c
> >> @@ -23,6 +23,18 @@
> >>  #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
> >>  #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
> >>
> >> +static const char *gicv_to_string(uint8_t gic_version)
> >> +{
> >> +    switch (gic_version) {
> >> +    case XEN_DOMCTL_CONFIG_GIC_V2:
> >> +        return "V2";
> >> +    case XEN_DOMCTL_CONFIG_GIC_V3:
> >> +        return "V3";
> >> +    default:
> >> +        return "unknown";
> >> +    }
> >> +}
> >> +
> >>  int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> >>                                uint32_t domid)
> >>  {
> >> @@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
> >>      return 0;
> >>  }
> >>
> >> -static int make_intc_node(libxl__gc *gc, void *fdt,
> >> -                          uint64_t gicd_base, uint64_t gicd_size,
> >> -                          uint64_t gicc_base, uint64_t gicc_size)
> >> +static int make_gicv2_node(libxl__gc *gc, void *fdt,
> >> +                           uint64_t gicd_base, uint64_t gicd_size,
> >> +                           uint64_t gicc_base, uint64_t gicc_size)
> >>  {
> >>      int res;
> >>      const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> >> @@ -350,6 +362,57 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
> >>      return 0;
> >>  }
> >>
> >> +static int make_gicv3_node(libxl__gc *gc, void *fdt)
> >> +{
> >> +    int res;
> >> +    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
> >> +    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
> >> +    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
> >> +    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
> >> +    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> >> +
> >> +    res = fdt_begin_node(fdt, name);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_compat(gc, fdt, 1,
> >> +                              "arm,gic-v3");
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "#address-cells", 0);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "redistributor-stride",
> >> +                            GUEST_GICV3_RDIST_STRIDE);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "#redistributor-regions",
> >> +                            GUEST_GICV3_RDIST_REGIONS);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> >> +                            2,
> >> +                            gicd_base, gicd_size,
> >> +                            gicr0_base, gicr0_size);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_end_node(fdt);
> >> +    if (res) return res;
> >> +
> >> +    return 0;
> >> +}
> >> +
> >>  static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
> >>  {
> >>      int res;
> >> @@ -456,6 +519,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> >>                                             libxl_domain_build_info *info,
> >>                                             struct xc_dom_image *dom)
> >>  {
> >> +    xc_domain_configuration_t config;
> >>      void *fdt = NULL;
> >>      int rc, res;
> >>      size_t fdt_size = 0;
> >> @@ -471,8 +535,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> >>      ainfo = get_arch_info(gc, dom);
> >>      if (ainfo == NULL) return ERROR_FAIL;
> >>
> >> +    LOG(DEBUG, "configure the domain");
> >> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> >> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> >> +        LOG(ERROR, "counldn't configure the domain");
> >> +        return ERROR_FAIL;
> >> +    }
> >> +
> >>      LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
> >>          vers->xen_version_major, vers->xen_version_minor);
> >> +    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
> >>
> >>  /*
> >>   * Call "call" handling FDR_ERR_*. Will either:
> >> @@ -520,9 +592,22 @@ next_resize:
> >>          FDT( make_psci_node(gc, fdt) );
> >>
> >>          FDT( make_memory_nodes(gc, fdt, dom) );
> >> -        FDT( make_intc_node(gc, fdt,
> >> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> >> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> >> +
> >> +        switch (config.gic_version) {
> >> +        case XEN_DOMCTL_CONFIG_GIC_V2:
> >> +            FDT( make_gicv2_node(gc, fdt,
> >> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> >> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> >> +            break;
> >> +        case XEN_DOMCTL_CONFIG_GIC_V3:
> >> +            FDT( make_gicv3_node(gc, fdt) );
> >> +            break;
> >> +        default:
> >> +            LOG(ERROR, "Unknown how to create the DT node for gic_version = %d",
> >> +                config.gic_version);
> >> +            rc = ERROR_FAIL;
> >> +            goto out;
> >> +        }
> >>
> >>          FDT( make_timer_node(gc, fdt, ainfo) );
> >>          FDT( make_hypervisor_node(gc, fdt, vers) );
> >> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> >> index 45974e7..5b8ff57 100644
> >> --- a/xen/arch/arm/domctl.c
> >> +++ b/xen/arch/arm/domctl.c
> >> @@ -10,6 +10,8 @@
> >>  #include <xen/errno.h>
> >>  #include <xen/sched.h>
> >>  #include <xen/hypercall.h>
> >> +#include <asm/gic.h>
> >> +#include <xen/guest_access.h>
> >>  #include <public/domctl.h>
> >>
> >>  long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >>
> >>          return p2m_cache_flush(d, s, e);
> >>      }
> >> +    case XEN_DOMCTL_arm_configure_domain:
> >> +    {
> >> +        uint8_t gic_version;
> >> +
> >> +        /*
> >> +         * Xen 4.5: The vGIC is emulating the same version of the
> >> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> >> +         * is allowed. The DOMCTL will return the actual version of the
> >> +         * GIC.
> >> +         */
> >> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> >> +            return -EOPNOTSUPP;
> >> +
> >> +        switch ( gic_hw_version() )
> >> +        {
> >> +        case GIC_V3:
> >> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> >> +            break;
> >> +        case GIC_V2:
> >> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> >> +            break;
> >> +        default:
> >> +            BUG();
> >> +        }
> >> +
> >> +        domctl->u.configuredomain.gic_version = gic_version;
> >> +
> >> +        /* TODO: Make the copy generic for all ARCH domctl */
> >> +        if ( __copy_to_guest(u_domctl, domctl, 1) )
> >> +            return -EFAULT;
> >> +
> >> +        return 0;
> >> +    }
> >>
> >>      default:
> >>          return subarch_do_domctl(domctl, d, u_domctl);
> >> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> >> index 91161a2..076aa62 100644
> >> --- a/xen/arch/arm/gic-v3.c
> >> +++ b/xen/arch/arm/gic-v3.c
> >> @@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
> >>          d->arch.vgic.rdist_count = gicv3.rdist_count;
> >>      }
> >>      else
> >> -        d->arch.vgic.dbase = GUEST_GICD_BASE;
> >> +    {
> >> +        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
> >> +        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
> >> +
> >> +        /* XXX: Only one Re-distributor region mapped for the guest */
> >> +        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
> >> +
> >> +        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
> >> +        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
> >> +
> >> +        /* The first redistributor should contain enough space for all CPUs */
> >> +        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
> >> +        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
> >> +        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
> >> +    }
> >>
> >>      d->arch.vgic.nr_lines = 0;
> >>
> >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> >> index eecc561..d7df274 100644
> >> --- a/xen/include/public/arch-arm.h
> >> +++ b/xen/include/public/arch-arm.h
> >> @@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
> >>   */
> >>
> >>  /* Physical Address Space */
> >> +
> >> +/* vGIC mappings: Only one set of mapping is used by the guest.
> >> + * Therefore they can overlap.
> >> + */
> >> +
> >> +/* vGIC v2 mappings */
> >>  #define GUEST_GICD_BASE   0x03001000ULL
> >>  #define GUEST_GICD_SIZE   0x00001000ULL
> >>  #define GUEST_GICC_BASE   0x03002000ULL
> >>  #define GUEST_GICC_SIZE   0x00000100ULL
> >>
> >> +/* vGIC v3 mappings */
> >> +#define GUEST_GICV3_GICD_BASE      0x03001000ULL
> >> +#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
> >> +
> >> +#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
> >> +#define GUEST_GICV3_RDIST_REGIONS  1
> >> +
> >> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */
> >> +#define GUEST_GICV3_GICR0_SIZE     0x00200000ULL
> >> +
> >>  /* 16MB == 4096 pages reserved for guest to use as a region to map its
> >>   * grant table in.
> >>   */
> >> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> >> index 58b19e7..8da204e 100644
> >> --- a/xen/include/public/domctl.h
> >> +++ b/xen/include/public/domctl.h
> >> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
> >>  typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
> >>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
> >>
> >> +#if defined(__arm__) || defined(__aarch64__)
> >> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
> >> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
> >> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
> >> +/* XEN_DOMCTL_configure_domain */
> >> +struct xen_domctl_arm_configuredomain {
> >> +    /* IN/OUT parameters */
> >> +    uint8_t gic_version;
> >> +};
> >> +typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
> >> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
> >> +#endif
> >> +
> >>  /* XEN_DOMCTL_getdomaininfo */
> >>  struct xen_domctl_getdomaininfo {
> >>      /* OUT variables. */
> >> @@ -1056,6 +1069,7 @@ struct xen_domctl {
> >>  #define XEN_DOMCTL_set_vcpu_msrs                 73
> >>  #define XEN_DOMCTL_setvnumainfo                  74
> >>  #define XEN_DOMCTL_psr_cmt_op                    75
> >> +#define XEN_DOMCTL_arm_configure_domain          76
> >>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
> >>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
> >>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> >> @@ -1064,6 +1078,9 @@ struct xen_domctl {
> >>      domid_t  domain;
> >>      union {
> >>          struct xen_domctl_createdomain      createdomain;
> >> +#if defined(__arm__) || defined(__aarch64__)
> >> +        struct xen_domctl_arm_configuredomain configuredomain;
> >> +#endif
> >>          struct xen_domctl_getdomaininfo     getdomaininfo;
> >>          struct xen_domctl_getmemlist        getmemlist;
> >>          struct xen_domctl_getpageframeinfo  getpageframeinfo;
> >> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> >> index 6d0fe72..846cf88 100644
> >> --- a/xen/xsm/flask/hooks.c
> >> +++ b/xen/xsm/flask/hooks.c
> >> @@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
> >>      case XEN_DOMCTL_psr_cmt_op:
> >>          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
> >>
> >> +    case XEN_DOMCTL_configure_domain:
> >> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
> >> +
> >>      default:
> >>          printk("flask_domctl: Unknown op %d\n", cmd);
> >>          return -EPERM;
> >> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> >> index de0c707..bfe2fa5 100644
> >> --- a/xen/xsm/flask/policy/access_vectors
> >> +++ b/xen/xsm/flask/policy/access_vectors
> >> @@ -216,6 +216,8 @@ class domain2
> >>      get_vnumainfo
> >>  # XEN_DOMCTL_psr_cmt_op
> >>      psr_cmt_op
> >> +# XEN_DOMCTL_configure_domain
> >> +    configure_domain
> >>  }
> >>
> >>  # Similar to class domain, but primarily contains domctls related to HVM domains
> >> --
> >> 1.7.10.4
> >>
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:40:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlKg5-0008OI-LO; Mon, 03 Nov 2014 16:40:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlKg4-0008OD-Kx
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 16:40:24 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	A9/A6-26740-7FFA7545; Mon, 03 Nov 2014 16:40:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415032821!11383065!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5056 invoked from network); 3 Nov 2014 16:40:22 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 16:40:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3Gd8u6006388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 16:39:08 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Gd6VZ014152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 16:39:06 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3Gd65q014141; Mon, 3 Nov 2014 16:39:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 08:39:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 42A2210FF36; Mon,  3 Nov 2014 11:39:04 -0500 (EST)
Date: Mon, 3 Nov 2014 11:39:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Vijay Kilari <vijay.kilari@gmail.com>
Message-ID: <20141103163904.GF1638@laptop.dumpdata.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 06:07:33PM +0530, Vijay Kilari wrote:
> On Mon, Nov 3, 2014 at 4:31 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Sat, 1 Nov 2014, Julien Grall wrote:
> >> The vGIC will emulate the same version as the hardware. The toolstack has
> >> to retrieve the version of the vGIC in order to be able to create the
> >> corresponding device tree node.
> >>
> >> A new DOMCTL has been introduced for ARM to configure the domain. For now
> >> it only allow the toolstack to retrieve the version of vGIC.
> >> This DOMCTL will be extend later to let the user choose the version of the
> >> emulated GIC.
> >>
> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> >> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >> Cc: Jan Beulich <jbeulich@suse.com>
> >> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >> Cc: Wei Liu <wei.liu2@citrix.com>
> >
> > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Tested with GICv3 platform.

Thank you for doing that.

It also needs Acks from Daniel and Jan.

> 
> >
> >
> >>     Changes in v2:
> >>         - Use memcpu in xc_domain_configure
> >>         - Rename the DOMCTL into domctl_arm_configuredomain
> >>         - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
> >>         and fold the code in arch_domain_init_hw_description
> >>         - Return -EOPNOTSUPP when the value of gic_version is not
> >>         supported
> >>
> >> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> >> defer the initialization of the vGIC [2].
> >>
> >> Xen 4.5 has already support for the hardware GICv3. While it's possible to
> >> boot and use DOM0, there is no guest support. The first version of this patch
> >> has been sent a couple of months ago, but has never reached unstable for
> >> various reasons (based on deferred series, lake of review at that time...).
> >> Without it, platform with GICv3 support won't be able to boot any guest.
> >>
> >> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> >> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
> >>
> >> Features such as adding a new config option to let the user choose the GIC
> >> version are deferred to Xen 4.6.
> >>
> >> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
> >>
> >> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> >> [2] https://patches.linaro.org/34664/
> >> ---
> >>  tools/flask/policy/policy/modules/xen/xen.if |    2 +-
> >>  tools/libxc/include/xenctrl.h                |    6 ++
> >>  tools/libxc/xc_domain.c                      |   20 ++++++
> >>  tools/libxl/libxl_arm.c                      |   97 ++++++++++++++++++++++++--
> >>  xen/arch/arm/domctl.c                        |   35 ++++++++++
> >>  xen/arch/arm/gic-v3.c                        |   16 ++++-
> >>  xen/include/public/arch-arm.h                |   16 +++++
> >>  xen/include/public/domctl.h                  |   17 +++++
> >>  xen/xsm/flask/hooks.c                        |    3 +
> >>  xen/xsm/flask/policy/access_vectors          |    2 +
> >>  10 files changed, 206 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> >> index 641c797..fa69c9d 100644
> >> --- a/tools/flask/policy/policy/modules/xen/xen.if
> >> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> >> @@ -49,7 +49,7 @@ define(`create_domain_common', `
> >>                       getdomaininfo hypercall setvcpucontext setextvcpucontext
> >>                       getscheduler getvcpuinfo getvcpuextstate getaddrsize
> >>                       getaffinity setaffinity };
> >> -     allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> >> +     allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
> >>       allow $1 $2:security check_context;
> >>       allow $1 $2:shadow enable;
> >>       allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> >> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> >> index 564e187..45e282c 100644
> >> --- a/tools/libxc/include/xenctrl.h
> >> +++ b/tools/libxc/include/xenctrl.h
> >> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
> >>                       uint32_t flags,
> >>                       uint32_t *pdomid);
> >>
> >> +#if defined(__arm__) || defined(__aarch64__)
> >> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> >> +
> >> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> >> +                        xc_domain_configuration_t *config);
> >> +#endif
> >>
> >>  /* Functions to produce a dump of a given domain
> >>   *  xc_domain_dumpcore - produces a dump to a specified file
> >> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> >> index a9bcd4a..1aa1f45 100644
> >> --- a/tools/libxc/xc_domain.c
> >> +++ b/tools/libxc/xc_domain.c
> >> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
> >>      return 0;
> >>  }
> >>
> >> +#if defined(__arm__) || defined(__aarch64__)
> >> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> >> +                        xc_domain_configuration_t *config)
> >> +{
> >> +    int rc;
> >> +    DECLARE_DOMCTL;
> >> +
> >> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> >> +    domctl.domain = (domid_t)domid;
> >> +    /* xc_domain_configure_t is an alias to xen_domctl_arm_configuredomain */
> >> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
> >> +
> >> +    rc = do_domctl(xch, &domctl);
> >> +    if ( !rc )
> >> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> >> +
> >> +    return rc;
> >> +}
> >> +#endif
> >> +
> >>  int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
> >>                           xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
> >>  {
> >> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> >> index a122e4a..3dd6e7c 100644
> >> --- a/tools/libxl/libxl_arm.c
> >> +++ b/tools/libxl/libxl_arm.c
> >> @@ -23,6 +23,18 @@
> >>  #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
> >>  #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
> >>
> >> +static const char *gicv_to_string(uint8_t gic_version)
> >> +{
> >> +    switch (gic_version) {
> >> +    case XEN_DOMCTL_CONFIG_GIC_V2:
> >> +        return "V2";
> >> +    case XEN_DOMCTL_CONFIG_GIC_V3:
> >> +        return "V3";
> >> +    default:
> >> +        return "unknown";
> >> +    }
> >> +}
> >> +
> >>  int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> >>                                uint32_t domid)
> >>  {
> >> @@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
> >>      return 0;
> >>  }
> >>
> >> -static int make_intc_node(libxl__gc *gc, void *fdt,
> >> -                          uint64_t gicd_base, uint64_t gicd_size,
> >> -                          uint64_t gicc_base, uint64_t gicc_size)
> >> +static int make_gicv2_node(libxl__gc *gc, void *fdt,
> >> +                           uint64_t gicd_base, uint64_t gicd_size,
> >> +                           uint64_t gicc_base, uint64_t gicc_size)
> >>  {
> >>      int res;
> >>      const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> >> @@ -350,6 +362,57 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
> >>      return 0;
> >>  }
> >>
> >> +static int make_gicv3_node(libxl__gc *gc, void *fdt)
> >> +{
> >> +    int res;
> >> +    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
> >> +    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
> >> +    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
> >> +    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
> >> +    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> >> +
> >> +    res = fdt_begin_node(fdt, name);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_compat(gc, fdt, 1,
> >> +                              "arm,gic-v3");
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "#address-cells", 0);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "redistributor-stride",
> >> +                            GUEST_GICV3_RDIST_STRIDE);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "#redistributor-regions",
> >> +                            GUEST_GICV3_RDIST_REGIONS);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> >> +                            2,
> >> +                            gicd_base, gicd_size,
> >> +                            gicr0_base, gicr0_size);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
> >> +    if (res) return res;
> >> +
> >> +    res = fdt_end_node(fdt);
> >> +    if (res) return res;
> >> +
> >> +    return 0;
> >> +}
> >> +
> >>  static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
> >>  {
> >>      int res;
> >> @@ -456,6 +519,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> >>                                             libxl_domain_build_info *info,
> >>                                             struct xc_dom_image *dom)
> >>  {
> >> +    xc_domain_configuration_t config;
> >>      void *fdt = NULL;
> >>      int rc, res;
> >>      size_t fdt_size = 0;
> >> @@ -471,8 +535,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> >>      ainfo = get_arch_info(gc, dom);
> >>      if (ainfo == NULL) return ERROR_FAIL;
> >>
> >> +    LOG(DEBUG, "configure the domain");
> >> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> >> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> >> +        LOG(ERROR, "counldn't configure the domain");
> >> +        return ERROR_FAIL;
> >> +    }
> >> +
> >>      LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
> >>          vers->xen_version_major, vers->xen_version_minor);
> >> +    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
> >>
> >>  /*
> >>   * Call "call" handling FDR_ERR_*. Will either:
> >> @@ -520,9 +592,22 @@ next_resize:
> >>          FDT( make_psci_node(gc, fdt) );
> >>
> >>          FDT( make_memory_nodes(gc, fdt, dom) );
> >> -        FDT( make_intc_node(gc, fdt,
> >> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> >> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> >> +
> >> +        switch (config.gic_version) {
> >> +        case XEN_DOMCTL_CONFIG_GIC_V2:
> >> +            FDT( make_gicv2_node(gc, fdt,
> >> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> >> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> >> +            break;
> >> +        case XEN_DOMCTL_CONFIG_GIC_V3:
> >> +            FDT( make_gicv3_node(gc, fdt) );
> >> +            break;
> >> +        default:
> >> +            LOG(ERROR, "Unknown how to create the DT node for gic_version = %d",
> >> +                config.gic_version);
> >> +            rc = ERROR_FAIL;
> >> +            goto out;
> >> +        }
> >>
> >>          FDT( make_timer_node(gc, fdt, ainfo) );
> >>          FDT( make_hypervisor_node(gc, fdt, vers) );
> >> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> >> index 45974e7..5b8ff57 100644
> >> --- a/xen/arch/arm/domctl.c
> >> +++ b/xen/arch/arm/domctl.c
> >> @@ -10,6 +10,8 @@
> >>  #include <xen/errno.h>
> >>  #include <xen/sched.h>
> >>  #include <xen/hypercall.h>
> >> +#include <asm/gic.h>
> >> +#include <xen/guest_access.h>
> >>  #include <public/domctl.h>
> >>
> >>  long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >>
> >>          return p2m_cache_flush(d, s, e);
> >>      }
> >> +    case XEN_DOMCTL_arm_configure_domain:
> >> +    {
> >> +        uint8_t gic_version;
> >> +
> >> +        /*
> >> +         * Xen 4.5: The vGIC is emulating the same version of the
> >> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> >> +         * is allowed. The DOMCTL will return the actual version of the
> >> +         * GIC.
> >> +         */
> >> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> >> +            return -EOPNOTSUPP;
> >> +
> >> +        switch ( gic_hw_version() )
> >> +        {
> >> +        case GIC_V3:
> >> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> >> +            break;
> >> +        case GIC_V2:
> >> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> >> +            break;
> >> +        default:
> >> +            BUG();
> >> +        }
> >> +
> >> +        domctl->u.configuredomain.gic_version = gic_version;
> >> +
> >> +        /* TODO: Make the copy generic for all ARCH domctl */
> >> +        if ( __copy_to_guest(u_domctl, domctl, 1) )
> >> +            return -EFAULT;
> >> +
> >> +        return 0;
> >> +    }
> >>
> >>      default:
> >>          return subarch_do_domctl(domctl, d, u_domctl);
> >> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> >> index 91161a2..076aa62 100644
> >> --- a/xen/arch/arm/gic-v3.c
> >> +++ b/xen/arch/arm/gic-v3.c
> >> @@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
> >>          d->arch.vgic.rdist_count = gicv3.rdist_count;
> >>      }
> >>      else
> >> -        d->arch.vgic.dbase = GUEST_GICD_BASE;
> >> +    {
> >> +        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
> >> +        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
> >> +
> >> +        /* XXX: Only one Re-distributor region mapped for the guest */
> >> +        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
> >> +
> >> +        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
> >> +        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
> >> +
> >> +        /* The first redistributor should contain enough space for all CPUs */
> >> +        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
> >> +        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
> >> +        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
> >> +    }
> >>
> >>      d->arch.vgic.nr_lines = 0;
> >>
> >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> >> index eecc561..d7df274 100644
> >> --- a/xen/include/public/arch-arm.h
> >> +++ b/xen/include/public/arch-arm.h
> >> @@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
> >>   */
> >>
> >>  /* Physical Address Space */
> >> +
> >> +/* vGIC mappings: Only one set of mapping is used by the guest.
> >> + * Therefore they can overlap.
> >> + */
> >> +
> >> +/* vGIC v2 mappings */
> >>  #define GUEST_GICD_BASE   0x03001000ULL
> >>  #define GUEST_GICD_SIZE   0x00001000ULL
> >>  #define GUEST_GICC_BASE   0x03002000ULL
> >>  #define GUEST_GICC_SIZE   0x00000100ULL
> >>
> >> +/* vGIC v3 mappings */
> >> +#define GUEST_GICV3_GICD_BASE      0x03001000ULL
> >> +#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
> >> +
> >> +#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
> >> +#define GUEST_GICV3_RDIST_REGIONS  1
> >> +
> >> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */
> >> +#define GUEST_GICV3_GICR0_SIZE     0x00200000ULL
> >> +
> >>  /* 16MB == 4096 pages reserved for guest to use as a region to map its
> >>   * grant table in.
> >>   */
> >> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> >> index 58b19e7..8da204e 100644
> >> --- a/xen/include/public/domctl.h
> >> +++ b/xen/include/public/domctl.h
> >> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
> >>  typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
> >>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
> >>
> >> +#if defined(__arm__) || defined(__aarch64__)
> >> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
> >> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
> >> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
> >> +/* XEN_DOMCTL_configure_domain */
> >> +struct xen_domctl_arm_configuredomain {
> >> +    /* IN/OUT parameters */
> >> +    uint8_t gic_version;
> >> +};
> >> +typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
> >> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
> >> +#endif
> >> +
> >>  /* XEN_DOMCTL_getdomaininfo */
> >>  struct xen_domctl_getdomaininfo {
> >>      /* OUT variables. */
> >> @@ -1056,6 +1069,7 @@ struct xen_domctl {
> >>  #define XEN_DOMCTL_set_vcpu_msrs                 73
> >>  #define XEN_DOMCTL_setvnumainfo                  74
> >>  #define XEN_DOMCTL_psr_cmt_op                    75
> >> +#define XEN_DOMCTL_arm_configure_domain          76
> >>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
> >>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
> >>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> >> @@ -1064,6 +1078,9 @@ struct xen_domctl {
> >>      domid_t  domain;
> >>      union {
> >>          struct xen_domctl_createdomain      createdomain;
> >> +#if defined(__arm__) || defined(__aarch64__)
> >> +        struct xen_domctl_arm_configuredomain configuredomain;
> >> +#endif
> >>          struct xen_domctl_getdomaininfo     getdomaininfo;
> >>          struct xen_domctl_getmemlist        getmemlist;
> >>          struct xen_domctl_getpageframeinfo  getpageframeinfo;
> >> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> >> index 6d0fe72..846cf88 100644
> >> --- a/xen/xsm/flask/hooks.c
> >> +++ b/xen/xsm/flask/hooks.c
> >> @@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
> >>      case XEN_DOMCTL_psr_cmt_op:
> >>          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
> >>
> >> +    case XEN_DOMCTL_configure_domain:
> >> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
> >> +
> >>      default:
> >>          printk("flask_domctl: Unknown op %d\n", cmd);
> >>          return -EPERM;
> >> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> >> index de0c707..bfe2fa5 100644
> >> --- a/xen/xsm/flask/policy/access_vectors
> >> +++ b/xen/xsm/flask/policy/access_vectors
> >> @@ -216,6 +216,8 @@ class domain2
> >>      get_vnumainfo
> >>  # XEN_DOMCTL_psr_cmt_op
> >>      psr_cmt_op
> >> +# XEN_DOMCTL_configure_domain
> >> +    configure_domain
> >>  }
> >>
> >>  # Similar to class domain, but primarily contains domctls related to HVM domains
> >> --
> >> 1.7.10.4
> >>
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:44:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlKkT-0000C8-FY; Mon, 03 Nov 2014 16:44:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1XlKkS-0000By-00
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 16:44:56 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	AD/F4-02696-701B7545; Mon, 03 Nov 2014 16:44:55 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415033094!12273073!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26028 invoked from network); 3 Nov 2014 16:44:54 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 3 Nov 2014 16:44:54 -0000
Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80)
	(envelope-from <tglx@linutronix.de>)
	id 1XlKkE-0000JO-B0; Mon, 03 Nov 2014 17:44:42 +0100
Date: Mon, 3 Nov 2014 17:44:40 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Juergen Gross <jgross@suse.com>
In-Reply-To: <1415019724-4317-11-git-send-email-jgross@suse.com>
Message-ID: <alpine.DEB.2.11.1411031744280.5308@nanos>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
	<1415019724-4317-11-git-send-email-jgross@suse.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH V6 10/18] x86: Remove looking for setting of
 _PAGE_PAT_LARGE in pageattr.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 3 Nov 2014, Juergen Gross wrote:

> When modifying page attributes via change_page_attr_set_clr() don't
> test for setting _PAGE_PAT_LARGE, as this is
> - never done
> - PAT support for large pages is not included in the kernel up to now
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:44:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlKkT-0000C8-FY; Mon, 03 Nov 2014 16:44:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1XlKkS-0000By-00
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 16:44:56 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	AD/F4-02696-701B7545; Mon, 03 Nov 2014 16:44:55 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415033094!12273073!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26028 invoked from network); 3 Nov 2014 16:44:54 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 3 Nov 2014 16:44:54 -0000
Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80)
	(envelope-from <tglx@linutronix.de>)
	id 1XlKkE-0000JO-B0; Mon, 03 Nov 2014 17:44:42 +0100
Date: Mon, 3 Nov 2014 17:44:40 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Juergen Gross <jgross@suse.com>
In-Reply-To: <1415019724-4317-11-git-send-email-jgross@suse.com>
Message-ID: <alpine.DEB.2.11.1411031744280.5308@nanos>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
	<1415019724-4317-11-git-send-email-jgross@suse.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH V6 10/18] x86: Remove looking for setting of
 _PAGE_PAT_LARGE in pageattr.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 3 Nov 2014, Juergen Gross wrote:

> When modifying page attributes via change_page_attr_set_clr() don't
> test for setting _PAGE_PAT_LARGE, as this is
> - never done
> - PAT support for large pages is not included in the kernel up to now
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKms-0000Px-M4; Mon, 03 Nov 2014 16:47:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKmr-0000Pf-K7
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:25 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	30/64-02984-C91B7545; Mon, 03 Nov 2014 16:47:24 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415033239!12282247!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11151 invoked from network); 3 Nov 2014 16:47:23 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:23 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW69175; Tue, 04 Nov 2014 00:47:17 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:10 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:30 +0000
Message-ID: <1415033196-30529-2-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 1/7] xen/device_tree: Add new helper to read
	arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@linaro.org>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/common/device_tree.c      | 13 ++++++++++---
 xen/include/xen/device_tree.h | 11 +++++++++++
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..1a886c0 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -160,14 +160,21 @@ const void *dt_get_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                          const char *name, u32 *out_value)
 {
-    u32 len;
+    return dt_property_read_u32_array(np, name, out_value, 1);
+}
+
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len)
+{
+    u32 len, i;
     const __be32 *val;
 
     val = dt_get_property(np, name, &len);
-    if ( !val || len < sizeof(*out_value) )
+    if ( !val || len < sizeof(*out_value) * out_len )
         return 0;
 
-    *out_value = be32_to_cpup(val);
+    for ( i = 0; i < out_len; i++, val++ )
+        out_value[i] = be32_to_cpup(val);
 
     return 1;
 }
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..629bfb2 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                             const char *name, u32 *out_value);
 /**
+ * dt_property_read_u32_array - Helper to read a u32 array property.
+ * @np: node to get the value
+ * @name: name of the property
+ * @out_value: pointer to return value
+ * @out_len: length of the array
+ *
+ * Return true if get the desired value.
+ */
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len);
+/**
  * dt_property_read_u64 - Helper to read a u64 property.
  * @np: node to get the value
  * @name: name of the property
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKms-0000Pl-AY; Mon, 03 Nov 2014 16:47:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKmq-0000PZ-V3
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:25 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	62/C5-09284-C91B7545; Mon, 03 Nov 2014 16:47:24 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415033239!11292174!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9973 invoked from network); 3 Nov 2014 16:47:23 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:23 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW69179; Tue, 04 Nov 2014 00:47:18 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:06 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:29 +0000
Message-ID: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] xen/arm: Add support for Huawei hip04-d01 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details).

The patch "xen/arm: Move vGIC registers on Hip04 platform" is actually a workaround and should have in the future a proper implementation in Xen (unfortunately not straightforward to do it).

Changes from v1:
- style (Julien Grall);
- make gicv2_send_SGI faster (Julien Grall);
- cleanup correctly if hip04_smp_init fails (Julien Grall);
- remove quirks using compatibility (Ian Campbell);
- other minor suggestions by Julien Grall.



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKms-0000Px-M4; Mon, 03 Nov 2014 16:47:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKmr-0000Pf-K7
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:25 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	30/64-02984-C91B7545; Mon, 03 Nov 2014 16:47:24 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415033239!12282247!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11151 invoked from network); 3 Nov 2014 16:47:23 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:23 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW69175; Tue, 04 Nov 2014 00:47:17 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:10 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:30 +0000
Message-ID: <1415033196-30529-2-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 1/7] xen/device_tree: Add new helper to read
	arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@linaro.org>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/common/device_tree.c      | 13 ++++++++++---
 xen/include/xen/device_tree.h | 11 +++++++++++
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..1a886c0 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -160,14 +160,21 @@ const void *dt_get_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                          const char *name, u32 *out_value)
 {
-    u32 len;
+    return dt_property_read_u32_array(np, name, out_value, 1);
+}
+
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len)
+{
+    u32 len, i;
     const __be32 *val;
 
     val = dt_get_property(np, name, &len);
-    if ( !val || len < sizeof(*out_value) )
+    if ( !val || len < sizeof(*out_value) * out_len )
         return 0;
 
-    *out_value = be32_to_cpup(val);
+    for ( i = 0; i < out_len; i++, val++ )
+        out_value[i] = be32_to_cpup(val);
 
     return 1;
 }
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..629bfb2 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                             const char *name, u32 *out_value);
 /**
+ * dt_property_read_u32_array - Helper to read a u32 array property.
+ * @np: node to get the value
+ * @name: name of the property
+ * @out_value: pointer to return value
+ * @out_len: length of the array
+ *
+ * Return true if get the desired value.
+ */
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len);
+/**
  * dt_property_read_u64 - Helper to read a u64 property.
  * @np: node to get the value
  * @name: name of the property
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKms-0000Pl-AY; Mon, 03 Nov 2014 16:47:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKmq-0000PZ-V3
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:25 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	62/C5-09284-C91B7545; Mon, 03 Nov 2014 16:47:24 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415033239!11292174!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9973 invoked from network); 3 Nov 2014 16:47:23 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:23 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW69179; Tue, 04 Nov 2014 00:47:18 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:06 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:29 +0000
Message-ID: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] xen/arm: Add support for Huawei hip04-d01 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details).

The patch "xen/arm: Move vGIC registers on Hip04 platform" is actually a workaround and should have in the future a proper implementation in Xen (unfortunately not straightforward to do it).

Changes from v1:
- style (Julien Grall);
- make gicv2_send_SGI faster (Julien Grall);
- cleanup correctly if hip04_smp_init fails (Julien Grall);
- remove quirks using compatibility (Ian Campbell);
- other minor suggestions by Julien Grall.



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKmz-0000RJ-2g; Mon, 03 Nov 2014 16:47:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKmx-0000QU-9u
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:31 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	40/E9-26652-2A1B7545; Mon, 03 Nov 2014 16:47:30 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415033245!10974426!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27110 invoked from network); 3 Nov 2014 16:47:29 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:29 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBU45081; Tue, 04 Nov 2014 00:47:22 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:13 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:31 +0000
Message-ID: <1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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

Add this new platform to Xen.
This platform requires specific code to initialize CPUs.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/hip04.c  | 308 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 309 insertions(+)
 create mode 100644 xen/arch/arm/platforms/hip04.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8f47c16..d0b2d99 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_64) += seattle.o
+obj-$(CONFIG_ARM_32) += hip04.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
new file mode 100644
index 0000000..799b5b3
--- /dev/null
+++ b/xen/arch/arm/platforms/hip04.c
@@ -0,0 +1,308 @@
+/*
+ * xen/arch/arm/platforms/hip04.c
+ *
+ * HiSilicon HIP-04 D01 board
+ *
+ * Copyright (c) 2012-2013 Hisilicon Ltd.
+ * Copyright (c) 2012-2013 Linaro Ltd.
+ * Copyright (c) 2014 Huawei Tech. Co., Ltd.
+ *
+ * Author: Frediano Ziglio <frediano.ziglio@huawei.com>
+ *
+ * Original code from Linux kernel arch/arm/mach-hisi/hisilicon.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/platform.h>
+#include <xen/mm.h>
+#include <xen/vmap.h>
+#include <asm/io.h>
+#include <asm/gic.h>
+#include <xen/delay.h>
+
+#define CORE_RESET_BIT(x)            (1 << x)
+#define NEON_RESET_BIT(x)            (1 << (x + 4))
+#define CORE_DEBUG_RESET_BIT(x)      (1 << (x + 9))
+#define CLUSTER_L2_RESET_BIT         (1 << 8)
+#define CLUSTER_DEBUG_RESET_BIT      (1 << 13)
+
+#define CLUSTER_L2_RESET_STATUS      (1 << 8)
+#define CLUSTER_DEBUG_RESET_STATUS   (1 << 13)
+
+#define SC_CPU_RESET_DREQ(x)         (0x524 + (x << 3))    /* unreset */
+#define SC_CPU_RESET_STATUS(x)       (0x1520 + (x << 3))
+
+#define FAB_SF_MODE                  0x0c
+
+#define HIP04_MAX_CLUSTERS           4
+#define HIP04_MAX_CPUS_PER_CLUSTER   4
+
+struct hip04_secondary_cpu_data
+{
+    u32 bootwrapper_phys;
+    u32 bootwrapper_size;
+    u32 bootwrapper_magic;
+    u32 relocation_entry;
+    u32 relocation_size;
+};
+
+static void __iomem *relocation, *sysctrl, *fabric, *gb2;
+static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
+static struct hip04_secondary_cpu_data hip04_boot;
+
+static void hip04_reset(void)
+{
+    unsigned long data;
+
+    if ( !gb2 )
+        return;
+
+    data = readl_relaxed(gb2);
+    writel_relaxed(data & ~0x4000000u, gb2);
+
+    mdelay(10);
+}
+
+static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
+{
+    unsigned long data;
+
+    if ( !fabric )
+        return;
+    data = readl_relaxed(fabric + FAB_SF_MODE);
+    if ( on )
+        data |= 1 << cluster;
+    else
+        data &= ~(1 << cluster);
+    writel_relaxed(data, fabric + FAB_SF_MODE);
+    while ( 1 )
+    {
+        if ( data == readl_relaxed(fabric + FAB_SF_MODE) )
+            break;
+    }
+}
+
+static bool __init hip04_cpu_table_init(void)
+{
+    unsigned int mpidr, cpu, cluster;
+
+    mpidr = cpu_logical_map(smp_processor_id());
+    cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+    cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+    if ( cluster >= HIP04_MAX_CLUSTERS ||
+        cpu >= HIP04_MAX_CPUS_PER_CLUSTER )
+    {
+        printk(XENLOG_ERR "%s: boot CPU is out of bound!\n", __func__);
+        return false;
+    }
+
+    hip04_set_snoop_filter(cluster, 1);
+    hip04_cpu_table[cluster][cpu] = 1;
+    return true;
+}
+
+static bool hip04_cluster_down(unsigned int cluster)
+{
+    int i;
+
+    for ( i = 0; i < HIP04_MAX_CPUS_PER_CLUSTER; i++ )
+        if ( hip04_cpu_table[cluster][i] )
+            return false;
+    return true;
+}
+
+static void hip04_cluster_up(unsigned int cluster)
+{
+    unsigned long data, mask;
+
+    if ( !hip04_cluster_down(cluster) )
+        return;
+
+    data = CLUSTER_L2_RESET_BIT | CLUSTER_DEBUG_RESET_BIT;
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+    do {
+        mask = CLUSTER_L2_RESET_STATUS | \
+               CLUSTER_DEBUG_RESET_STATUS;
+        data = readl_relaxed(sysctrl + \
+                     SC_CPU_RESET_STATUS(cluster));
+    } while ( data & mask );
+    hip04_set_snoop_filter(cluster, 1);
+}
+
+static void __init hip04_iounmap(void __iomem **p)
+{
+    if ( *p )
+    {
+        iounmap(*p);
+        *p = NULL;
+    }
+}
+
+static int __init hip04_smp_init(void)
+{
+    const struct dt_device_node *np, *np_fab, *bw;
+    const char *msg;
+    u64 addr, size;
+
+    np = dt_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
+    msg = "hisilicon,sysctrl missing in DT\n";
+    if ( !np )
+        goto err;
+
+    np_fab = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-fabric");
+    msg = "hisilicon,hip04-fabric missing in DT\n";
+    if ( !np_fab )
+        goto err;
+
+    if ( !dt_property_read_u32(np, "bootwrapper-phys",
+                               &hip04_boot.bootwrapper_phys) ) {
+        u32 boot_method[4];
+        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-bootwrapper");
+        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
+        if ( !bw )
+            goto err;
+
+        msg = "failed to get boot-method\n";
+        if ( !dt_property_read_u32_array(bw, "boot-method", boot_method, 4) )
+            goto err;
+        hip04_boot.bootwrapper_phys = boot_method[0];
+        hip04_boot.bootwrapper_size = boot_method[1];
+        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
+        hip04_boot.relocation_entry = boot_method[2];
+        hip04_boot.relocation_size = boot_method[3];
+    }
+    else
+    {
+        msg = "failed to get bootwrapper-size\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-size",
+                                   &hip04_boot.bootwrapper_size) )
+            goto err;
+
+        msg = "failed to get bootwrapper-magic\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-magic",
+                                   &hip04_boot.bootwrapper_magic) )
+            goto err;
+
+        msg = "failed to get relocation-entry\n";
+        if ( !dt_property_read_u32(np, "relocation-entry",
+                                   &hip04_boot.relocation_entry) )
+            goto err;
+
+        msg = "failed to get relocation-size\n";
+        if ( !dt_property_read_u32(np, "relocation-size",
+                                   &hip04_boot.relocation_size) )
+            goto err;
+    }
+
+    relocation = ioremap_nocache(hip04_boot.relocation_entry,
+                                 hip04_boot.relocation_size);
+    msg = "failed to map relocation space\n";
+    if ( !relocation )
+        goto err;
+
+    msg = "Error in \"hisilicon,sysctrl\"\n";
+    if ( dt_device_get_address(np, 0, &addr, &size) )
+        goto err;
+    sysctrl = ioremap_nocache(addr, size);
+    if ( !sysctrl )
+        goto err;
+
+    msg = "Error in \"hisilicon,hip04-fabric\"\n";
+    if ( dt_device_get_address(np_fab, 0, &addr, &size) )
+        goto err;
+    fabric = ioremap_nocache(addr, size);
+    if ( !fabric )
+        goto err;
+
+    msg = "Error mapping GB2\n";
+    gb2 = ioremap_nocache(0xe4002000, 0x1000);
+    if ( !gb2 )
+        goto err;
+
+    msg = "Error initializing SMP table\n";
+    if ( !hip04_cpu_table_init() )
+        goto err;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    return 0;
+
+err:
+    hip04_iounmap(&relocation);
+    hip04_iounmap(&sysctrl);
+    hip04_iounmap(&fabric);
+    hip04_iounmap(&gb2);
+
+    printk("%s", msg);
+    return -ENXIO;
+}
+
+static int hip04_cpu_up(int cpu)
+{
+    unsigned int cluster;
+    unsigned long data;
+
+    cluster = cpu / HIP04_MAX_CPUS_PER_CLUSTER;
+    cpu %= HIP04_MAX_CPUS_PER_CLUSTER;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    hip04_cluster_up(cluster);
+
+    hip04_cpu_table[cluster][cpu]++;
+
+    data = CORE_RESET_BIT(cpu) | NEON_RESET_BIT(cpu) | \
+           CORE_DEBUG_RESET_BIT(cpu);
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+
+    return cpu_up_send_sgi(cpu);
+}
+
+
+static const char * const hip04_dt_compat[] __initconst =
+{
+    "hisilicon,hip04-d01",
+    NULL
+};
+
+static const struct dt_device_match hip04_blacklist_dev[] __initconst =
+{
+    /* Hardware power management */
+    DT_MATCH_COMPATIBLE("hisilicon,sysctrl"),
+    DT_MATCH_COMPATIBLE("hisilicon,hip04-fabric"),
+    { /* sentinel */ },
+};
+
+
+PLATFORM_START(hip04, "HISILICON HIP04")
+    .compatible = hip04_dt_compat,
+    .smp_init = hip04_smp_init,
+    .cpu_up = hip04_cpu_up,
+    .reset = hip04_reset,
+    .blacklist_dev = hip04_blacklist_dev,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKmz-0000RJ-2g; Mon, 03 Nov 2014 16:47:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKmx-0000QU-9u
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:31 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	40/E9-26652-2A1B7545; Mon, 03 Nov 2014 16:47:30 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415033245!10974426!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27110 invoked from network); 3 Nov 2014 16:47:29 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:29 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBU45081; Tue, 04 Nov 2014 00:47:22 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:13 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:31 +0000
Message-ID: <1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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

Add this new platform to Xen.
This platform requires specific code to initialize CPUs.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/hip04.c  | 308 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 309 insertions(+)
 create mode 100644 xen/arch/arm/platforms/hip04.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8f47c16..d0b2d99 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_64) += seattle.o
+obj-$(CONFIG_ARM_32) += hip04.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
new file mode 100644
index 0000000..799b5b3
--- /dev/null
+++ b/xen/arch/arm/platforms/hip04.c
@@ -0,0 +1,308 @@
+/*
+ * xen/arch/arm/platforms/hip04.c
+ *
+ * HiSilicon HIP-04 D01 board
+ *
+ * Copyright (c) 2012-2013 Hisilicon Ltd.
+ * Copyright (c) 2012-2013 Linaro Ltd.
+ * Copyright (c) 2014 Huawei Tech. Co., Ltd.
+ *
+ * Author: Frediano Ziglio <frediano.ziglio@huawei.com>
+ *
+ * Original code from Linux kernel arch/arm/mach-hisi/hisilicon.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/platform.h>
+#include <xen/mm.h>
+#include <xen/vmap.h>
+#include <asm/io.h>
+#include <asm/gic.h>
+#include <xen/delay.h>
+
+#define CORE_RESET_BIT(x)            (1 << x)
+#define NEON_RESET_BIT(x)            (1 << (x + 4))
+#define CORE_DEBUG_RESET_BIT(x)      (1 << (x + 9))
+#define CLUSTER_L2_RESET_BIT         (1 << 8)
+#define CLUSTER_DEBUG_RESET_BIT      (1 << 13)
+
+#define CLUSTER_L2_RESET_STATUS      (1 << 8)
+#define CLUSTER_DEBUG_RESET_STATUS   (1 << 13)
+
+#define SC_CPU_RESET_DREQ(x)         (0x524 + (x << 3))    /* unreset */
+#define SC_CPU_RESET_STATUS(x)       (0x1520 + (x << 3))
+
+#define FAB_SF_MODE                  0x0c
+
+#define HIP04_MAX_CLUSTERS           4
+#define HIP04_MAX_CPUS_PER_CLUSTER   4
+
+struct hip04_secondary_cpu_data
+{
+    u32 bootwrapper_phys;
+    u32 bootwrapper_size;
+    u32 bootwrapper_magic;
+    u32 relocation_entry;
+    u32 relocation_size;
+};
+
+static void __iomem *relocation, *sysctrl, *fabric, *gb2;
+static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
+static struct hip04_secondary_cpu_data hip04_boot;
+
+static void hip04_reset(void)
+{
+    unsigned long data;
+
+    if ( !gb2 )
+        return;
+
+    data = readl_relaxed(gb2);
+    writel_relaxed(data & ~0x4000000u, gb2);
+
+    mdelay(10);
+}
+
+static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
+{
+    unsigned long data;
+
+    if ( !fabric )
+        return;
+    data = readl_relaxed(fabric + FAB_SF_MODE);
+    if ( on )
+        data |= 1 << cluster;
+    else
+        data &= ~(1 << cluster);
+    writel_relaxed(data, fabric + FAB_SF_MODE);
+    while ( 1 )
+    {
+        if ( data == readl_relaxed(fabric + FAB_SF_MODE) )
+            break;
+    }
+}
+
+static bool __init hip04_cpu_table_init(void)
+{
+    unsigned int mpidr, cpu, cluster;
+
+    mpidr = cpu_logical_map(smp_processor_id());
+    cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+    cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+    if ( cluster >= HIP04_MAX_CLUSTERS ||
+        cpu >= HIP04_MAX_CPUS_PER_CLUSTER )
+    {
+        printk(XENLOG_ERR "%s: boot CPU is out of bound!\n", __func__);
+        return false;
+    }
+
+    hip04_set_snoop_filter(cluster, 1);
+    hip04_cpu_table[cluster][cpu] = 1;
+    return true;
+}
+
+static bool hip04_cluster_down(unsigned int cluster)
+{
+    int i;
+
+    for ( i = 0; i < HIP04_MAX_CPUS_PER_CLUSTER; i++ )
+        if ( hip04_cpu_table[cluster][i] )
+            return false;
+    return true;
+}
+
+static void hip04_cluster_up(unsigned int cluster)
+{
+    unsigned long data, mask;
+
+    if ( !hip04_cluster_down(cluster) )
+        return;
+
+    data = CLUSTER_L2_RESET_BIT | CLUSTER_DEBUG_RESET_BIT;
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+    do {
+        mask = CLUSTER_L2_RESET_STATUS | \
+               CLUSTER_DEBUG_RESET_STATUS;
+        data = readl_relaxed(sysctrl + \
+                     SC_CPU_RESET_STATUS(cluster));
+    } while ( data & mask );
+    hip04_set_snoop_filter(cluster, 1);
+}
+
+static void __init hip04_iounmap(void __iomem **p)
+{
+    if ( *p )
+    {
+        iounmap(*p);
+        *p = NULL;
+    }
+}
+
+static int __init hip04_smp_init(void)
+{
+    const struct dt_device_node *np, *np_fab, *bw;
+    const char *msg;
+    u64 addr, size;
+
+    np = dt_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
+    msg = "hisilicon,sysctrl missing in DT\n";
+    if ( !np )
+        goto err;
+
+    np_fab = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-fabric");
+    msg = "hisilicon,hip04-fabric missing in DT\n";
+    if ( !np_fab )
+        goto err;
+
+    if ( !dt_property_read_u32(np, "bootwrapper-phys",
+                               &hip04_boot.bootwrapper_phys) ) {
+        u32 boot_method[4];
+        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-bootwrapper");
+        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
+        if ( !bw )
+            goto err;
+
+        msg = "failed to get boot-method\n";
+        if ( !dt_property_read_u32_array(bw, "boot-method", boot_method, 4) )
+            goto err;
+        hip04_boot.bootwrapper_phys = boot_method[0];
+        hip04_boot.bootwrapper_size = boot_method[1];
+        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
+        hip04_boot.relocation_entry = boot_method[2];
+        hip04_boot.relocation_size = boot_method[3];
+    }
+    else
+    {
+        msg = "failed to get bootwrapper-size\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-size",
+                                   &hip04_boot.bootwrapper_size) )
+            goto err;
+
+        msg = "failed to get bootwrapper-magic\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-magic",
+                                   &hip04_boot.bootwrapper_magic) )
+            goto err;
+
+        msg = "failed to get relocation-entry\n";
+        if ( !dt_property_read_u32(np, "relocation-entry",
+                                   &hip04_boot.relocation_entry) )
+            goto err;
+
+        msg = "failed to get relocation-size\n";
+        if ( !dt_property_read_u32(np, "relocation-size",
+                                   &hip04_boot.relocation_size) )
+            goto err;
+    }
+
+    relocation = ioremap_nocache(hip04_boot.relocation_entry,
+                                 hip04_boot.relocation_size);
+    msg = "failed to map relocation space\n";
+    if ( !relocation )
+        goto err;
+
+    msg = "Error in \"hisilicon,sysctrl\"\n";
+    if ( dt_device_get_address(np, 0, &addr, &size) )
+        goto err;
+    sysctrl = ioremap_nocache(addr, size);
+    if ( !sysctrl )
+        goto err;
+
+    msg = "Error in \"hisilicon,hip04-fabric\"\n";
+    if ( dt_device_get_address(np_fab, 0, &addr, &size) )
+        goto err;
+    fabric = ioremap_nocache(addr, size);
+    if ( !fabric )
+        goto err;
+
+    msg = "Error mapping GB2\n";
+    gb2 = ioremap_nocache(0xe4002000, 0x1000);
+    if ( !gb2 )
+        goto err;
+
+    msg = "Error initializing SMP table\n";
+    if ( !hip04_cpu_table_init() )
+        goto err;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    return 0;
+
+err:
+    hip04_iounmap(&relocation);
+    hip04_iounmap(&sysctrl);
+    hip04_iounmap(&fabric);
+    hip04_iounmap(&gb2);
+
+    printk("%s", msg);
+    return -ENXIO;
+}
+
+static int hip04_cpu_up(int cpu)
+{
+    unsigned int cluster;
+    unsigned long data;
+
+    cluster = cpu / HIP04_MAX_CPUS_PER_CLUSTER;
+    cpu %= HIP04_MAX_CPUS_PER_CLUSTER;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    hip04_cluster_up(cluster);
+
+    hip04_cpu_table[cluster][cpu]++;
+
+    data = CORE_RESET_BIT(cpu) | NEON_RESET_BIT(cpu) | \
+           CORE_DEBUG_RESET_BIT(cpu);
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+
+    return cpu_up_send_sgi(cpu);
+}
+
+
+static const char * const hip04_dt_compat[] __initconst =
+{
+    "hisilicon,hip04-d01",
+    NULL
+};
+
+static const struct dt_device_match hip04_blacklist_dev[] __initconst =
+{
+    /* Hardware power management */
+    DT_MATCH_COMPATIBLE("hisilicon,sysctrl"),
+    DT_MATCH_COMPATIBLE("hisilicon,hip04-fabric"),
+    { /* sentinel */ },
+};
+
+
+PLATFORM_START(hip04, "HISILICON HIP04")
+    .compatible = hip04_dt_compat,
+    .smp_init = hip04_smp_init,
+    .cpu_up = hip04_cpu_up,
+    .reset = hip04_reset,
+    .blacklist_dev = hip04_blacklist_dev,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKn0-0000S8-Hh; Mon, 03 Nov 2014 16:47:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKmz-0000Ra-OP
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:33 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	EA/31-24859-5A1B7545; Mon, 03 Nov 2014 16:47:33 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415033248!11339312!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10824 invoked from network); 3 Nov 2014 16:47:32 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:32 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWO48423; Tue, 04 Nov 2014 00:47:27 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:20 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:33 +0000
Message-ID: <1415033196-30529-5-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020208.5457B19F.0369, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 47021c4164a1ad619f6f38c52f9197ca
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 4/7] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This name can appear in some Linux kernel repos. Not very fortunate,
but to avoid others spending an hour to spot that few characters
difference it worth to work around it.

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 1 +
 xen/include/asm-arm/gic.h | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 9461fe3..04e1850 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -829,6 +829,7 @@ DT_DEVICE_END
 static const char * const hip04_gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_HIP04,
+    DT_COMPAT_GIC_HIP04_2,
     NULL
 };
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 5adb628..3d2b3db 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -156,11 +156,13 @@
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
 #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
+#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKn0-0000S8-Hh; Mon, 03 Nov 2014 16:47:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKmz-0000Ra-OP
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:33 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	EA/31-24859-5A1B7545; Mon, 03 Nov 2014 16:47:33 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415033248!11339312!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10824 invoked from network); 3 Nov 2014 16:47:32 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:32 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWO48423; Tue, 04 Nov 2014 00:47:27 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:20 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:33 +0000
Message-ID: <1415033196-30529-5-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020208.5457B19F.0369, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 47021c4164a1ad619f6f38c52f9197ca
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 4/7] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This name can appear in some Linux kernel repos. Not very fortunate,
but to avoid others spending an hour to spot that few characters
difference it worth to work around it.

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 1 +
 xen/include/asm-arm/gic.h | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 9461fe3..04e1850 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -829,6 +829,7 @@ DT_DEVICE_END
 static const char * const hip04_gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_HIP04,
+    DT_COMPAT_GIC_HIP04_2,
     NULL
 };
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 5adb628..3d2b3db 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -156,11 +156,13 @@
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
 #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
+#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKn2-0000TI-0Q; Mon, 03 Nov 2014 16:47:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKn0-0000Rq-7a
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:34 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	5E/11-08051-5A1B7545; Mon, 03 Nov 2014 16:47:33 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415033248!12289172!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3377 invoked from network); 3 Nov 2014 16:47:32 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:32 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWO48421; Tue, 04 Nov 2014 00:47:27 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:17 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:32 +0000
Message-ID: <1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A02020A.5457B19F.02CB, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6e285cda9b082c24c7709211b7dfa722
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 3/7] xen/arm: Make gic-v2 code handle
	hip04-d01 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

The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 89 +++++++++++++++++++++++++++++++++++++++--------
 xen/arch/arm/gic.c        |  3 +-
 xen/include/asm-arm/gic.h |  4 ++-
 3 files changed, 80 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..9461fe3 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -79,16 +79,23 @@ static struct gic_info gicv2_info;
  * logical CPU numbering. Let's use mapping as returned by the GIC
  * itself
  */
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
 
 /* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+static unsigned int nr_gic_cpu_if = 8;
+static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
+static unsigned int gic_cpu_mask = 0xff;
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
     writeb_relaxed(val, gicv2.map_dbase + offset);
 }
 
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+    writew_relaxed(val, gicv2.map_dbase + offset);
+}
+
 static inline void writel_gicd(uint32_t val, unsigned int offset)
 {
     writel_relaxed(val, gicv2.map_dbase + offset);
@@ -132,7 +139,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
     cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
     for_each_cpu( cpu, &possible_mask )
     {
-        ASSERT(cpu < NR_GIC_CPU_IF);
+        ASSERT(cpu < nr_gic_cpu_if);
         mask |= per_cpu(gic_cpu_id, cpu);
     }
 
@@ -203,6 +210,15 @@ static unsigned int gicv2_read_irq(void)
     return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
+/* Set target CPU mask (RAZ/WI on uniprocessor) */
+static void gicv2_set_irq_mask(int irq, unsigned int mask)
+{
+    if ( nr_gic_cpu_if == 16 )
+        writew_gicd(mask, GICD_ITARGETSR + irq * 2);
+    else
+        writeb_gicd(mask, GICD_ITARGETSR + irq);
+}
+
 /*
  * needs to be called with a valid cpu_mask, ie each cpu in the mask has
  * already called gic_cpu_init
@@ -230,7 +246,7 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
     writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + irq);
+    gicv2_set_irq_mask(irq, mask);
     /* Set priority */
     writeb_gicd(priority, GICD_IPRIORITYR + irq);
 
@@ -244,16 +260,21 @@ static void __init gicv2_dist_init(void)
     uint32_t gic_cpus;
     int i;
 
-    cpumask = readl_gicd(GICD_ITARGETSR) & 0xff;
-    cpumask |= cpumask << 8;
-    cpumask |= cpumask << 16;
+    cpumask = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* Disable the distributor */
     writel_gicd(0, GICD_CTLR);
 
     type = readl_gicd(GICD_TYPER);
     gicv2_info.nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
-    gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    if ( nr_gic_cpu_if == 16 )
+    {
+        gic_cpus = 16;
+    }
+    else
+    {
+        gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    }
     printk("GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n",
            gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
            (type & GICD_TYPE_SEC) ? ", secure" : "",
@@ -264,8 +285,19 @@ static void __init gicv2_dist_init(void)
         writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
 
     /* Route all global IRQs to this CPU */
-    for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
-        writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    if ( nr_gic_cpu_if == 16 )
+    {
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 2 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 2) * 4);
+    }
+    else
+    {
+        cpumask |= cpumask << 8;
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    }
 
     /* Default priority for global interrupts */
     for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
@@ -285,7 +317,7 @@ static void __cpuinit gicv2_cpu_init(void)
 {
     int i;
 
-    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & 0xff;
+    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
      * even though they are controlled with GICD registers, they must
@@ -366,7 +398,7 @@ static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
         cpumask_and(&online_mask, cpu_mask, &cpu_online_map);
         mask = gicv2_cpu_mask(&online_mask);
         writel_gicd(GICD_SGI_TARGET_LIST |
-                    (mask << GICD_SGI_TARGET_SHIFT) | sgi,
+                    (mask << gicd_sgi_target_shift) | sgi,
                     GICD_SGIR);
         break;
     default:
@@ -581,7 +613,7 @@ static void gicv2_irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_m
     mask = gicv2_cpu_mask(cpu_mask);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + desc->irq);
+    gicv2_set_irq_mask(desc->irq, mask);
 
     spin_unlock(&gicv2.lock);
 }
@@ -684,12 +716,19 @@ const static struct gic_hw_operations gicv2_ops = {
 };
 
 /* Set up the GIC */
-static int __init gicv2_init(struct dt_device_node *node, const void *data)
+static int __init gicv2_init_common(struct dt_device_node *node, const void *data, bool hip04)
 {
     int res;
 
     dt_device_set_used_by(node, DOMID_XEN);
 
+    if ( hip04 )
+    {
+        nr_gic_cpu_if = 16;
+        gicd_sgi_target_shift = 8;
+        gic_cpu_mask = 0xffff;
+    }
+
     res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
     if ( res || !gicv2.dbase || (gicv2.dbase & ~PAGE_MASK) )
         panic("GICv2: Cannot find a valid address for the distributor");
@@ -764,6 +803,16 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
     return 0;
 }
 
+static int __init gicv2_init(struct dt_device_node *node, const void *data)
+{
+    return gicv2_init_common(node, data, false);
+}
+
+static int __init hip04_gicv2_init(struct dt_device_node *node, const void *data)
+{
+    return gicv2_init_common(node, data, true);
+}
+
 static const char * const gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_CORTEX_A15,
@@ -777,6 +826,18 @@ DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
         .init = gicv2_init,
 DT_DEVICE_END
 
+static const char * const hip04_gicv2_dt_compat[] __initconst =
+{
+    DT_COMPAT_GIC_HIP04,
+    NULL
+};
+
+DT_DEVICE_START(hip04_gicv2, "GICv2:", DEVICE_GIC)
+        .compatible = hip04_gicv2_dt_compat,
+        .init = hip04_gicv2_init,
+DT_DEVICE_END
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..8050a65 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
 void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 {
     unsigned int irq;
+    unsigned int max_irq = gic_hw_ops->info->nr_lines;
 
     do  {
         /* Reading IRQ will ACK it */
         irq = gic_hw_ops->read_irq();
 
-        if ( likely(irq >= 16 && irq < 1021) )
+        if ( likely(irq >= 16 && irq < max_irq) )
         {
             local_irq_enable();
             do_IRQ(regs, irq, is_fiq);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..5adb628 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -155,10 +155,12 @@
 #define DT_COMPAT_GIC_400            "arm,gic-400"
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
+#define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKn2-0000TI-0Q; Mon, 03 Nov 2014 16:47:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKn0-0000Rq-7a
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:34 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	5E/11-08051-5A1B7545; Mon, 03 Nov 2014 16:47:33 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415033248!12289172!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3377 invoked from network); 3 Nov 2014 16:47:32 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:32 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWO48421; Tue, 04 Nov 2014 00:47:27 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:17 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:32 +0000
Message-ID: <1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A02020A.5457B19F.02CB, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6e285cda9b082c24c7709211b7dfa722
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 3/7] xen/arm: Make gic-v2 code handle
	hip04-d01 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

The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 89 +++++++++++++++++++++++++++++++++++++++--------
 xen/arch/arm/gic.c        |  3 +-
 xen/include/asm-arm/gic.h |  4 ++-
 3 files changed, 80 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..9461fe3 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -79,16 +79,23 @@ static struct gic_info gicv2_info;
  * logical CPU numbering. Let's use mapping as returned by the GIC
  * itself
  */
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
 
 /* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+static unsigned int nr_gic_cpu_if = 8;
+static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
+static unsigned int gic_cpu_mask = 0xff;
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
     writeb_relaxed(val, gicv2.map_dbase + offset);
 }
 
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+    writew_relaxed(val, gicv2.map_dbase + offset);
+}
+
 static inline void writel_gicd(uint32_t val, unsigned int offset)
 {
     writel_relaxed(val, gicv2.map_dbase + offset);
@@ -132,7 +139,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
     cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
     for_each_cpu( cpu, &possible_mask )
     {
-        ASSERT(cpu < NR_GIC_CPU_IF);
+        ASSERT(cpu < nr_gic_cpu_if);
         mask |= per_cpu(gic_cpu_id, cpu);
     }
 
@@ -203,6 +210,15 @@ static unsigned int gicv2_read_irq(void)
     return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
+/* Set target CPU mask (RAZ/WI on uniprocessor) */
+static void gicv2_set_irq_mask(int irq, unsigned int mask)
+{
+    if ( nr_gic_cpu_if == 16 )
+        writew_gicd(mask, GICD_ITARGETSR + irq * 2);
+    else
+        writeb_gicd(mask, GICD_ITARGETSR + irq);
+}
+
 /*
  * needs to be called with a valid cpu_mask, ie each cpu in the mask has
  * already called gic_cpu_init
@@ -230,7 +246,7 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
     writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + irq);
+    gicv2_set_irq_mask(irq, mask);
     /* Set priority */
     writeb_gicd(priority, GICD_IPRIORITYR + irq);
 
@@ -244,16 +260,21 @@ static void __init gicv2_dist_init(void)
     uint32_t gic_cpus;
     int i;
 
-    cpumask = readl_gicd(GICD_ITARGETSR) & 0xff;
-    cpumask |= cpumask << 8;
-    cpumask |= cpumask << 16;
+    cpumask = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* Disable the distributor */
     writel_gicd(0, GICD_CTLR);
 
     type = readl_gicd(GICD_TYPER);
     gicv2_info.nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
-    gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    if ( nr_gic_cpu_if == 16 )
+    {
+        gic_cpus = 16;
+    }
+    else
+    {
+        gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    }
     printk("GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n",
            gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
            (type & GICD_TYPE_SEC) ? ", secure" : "",
@@ -264,8 +285,19 @@ static void __init gicv2_dist_init(void)
         writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
 
     /* Route all global IRQs to this CPU */
-    for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
-        writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    if ( nr_gic_cpu_if == 16 )
+    {
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 2 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 2) * 4);
+    }
+    else
+    {
+        cpumask |= cpumask << 8;
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    }
 
     /* Default priority for global interrupts */
     for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
@@ -285,7 +317,7 @@ static void __cpuinit gicv2_cpu_init(void)
 {
     int i;
 
-    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & 0xff;
+    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
      * even though they are controlled with GICD registers, they must
@@ -366,7 +398,7 @@ static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
         cpumask_and(&online_mask, cpu_mask, &cpu_online_map);
         mask = gicv2_cpu_mask(&online_mask);
         writel_gicd(GICD_SGI_TARGET_LIST |
-                    (mask << GICD_SGI_TARGET_SHIFT) | sgi,
+                    (mask << gicd_sgi_target_shift) | sgi,
                     GICD_SGIR);
         break;
     default:
@@ -581,7 +613,7 @@ static void gicv2_irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_m
     mask = gicv2_cpu_mask(cpu_mask);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + desc->irq);
+    gicv2_set_irq_mask(desc->irq, mask);
 
     spin_unlock(&gicv2.lock);
 }
@@ -684,12 +716,19 @@ const static struct gic_hw_operations gicv2_ops = {
 };
 
 /* Set up the GIC */
-static int __init gicv2_init(struct dt_device_node *node, const void *data)
+static int __init gicv2_init_common(struct dt_device_node *node, const void *data, bool hip04)
 {
     int res;
 
     dt_device_set_used_by(node, DOMID_XEN);
 
+    if ( hip04 )
+    {
+        nr_gic_cpu_if = 16;
+        gicd_sgi_target_shift = 8;
+        gic_cpu_mask = 0xffff;
+    }
+
     res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
     if ( res || !gicv2.dbase || (gicv2.dbase & ~PAGE_MASK) )
         panic("GICv2: Cannot find a valid address for the distributor");
@@ -764,6 +803,16 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
     return 0;
 }
 
+static int __init gicv2_init(struct dt_device_node *node, const void *data)
+{
+    return gicv2_init_common(node, data, false);
+}
+
+static int __init hip04_gicv2_init(struct dt_device_node *node, const void *data)
+{
+    return gicv2_init_common(node, data, true);
+}
+
 static const char * const gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_CORTEX_A15,
@@ -777,6 +826,18 @@ DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
         .init = gicv2_init,
 DT_DEVICE_END
 
+static const char * const hip04_gicv2_dt_compat[] __initconst =
+{
+    DT_COMPAT_GIC_HIP04,
+    NULL
+};
+
+DT_DEVICE_START(hip04_gicv2, "GICv2:", DEVICE_GIC)
+        .compatible = hip04_gicv2_dt_compat,
+        .init = hip04_gicv2_init,
+DT_DEVICE_END
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..8050a65 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
 void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 {
     unsigned int irq;
+    unsigned int max_irq = gic_hw_ops->info->nr_lines;
 
     do  {
         /* Reading IRQ will ACK it */
         irq = gic_hw_ops->read_irq();
 
-        if ( likely(irq >= 16 && irq < 1021) )
+        if ( likely(irq >= 16 && irq < max_irq) )
         {
             local_irq_enable();
             do_IRQ(regs, irq, is_fiq);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..5adb628 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -155,10 +155,12 @@
 #define DT_COMPAT_GIC_400            "arm,gic-400"
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
+#define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKn6-0000Wo-Qf; Mon, 03 Nov 2014 16:47:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKn4-0000V5-Ge
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:38 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	95/7A-25547-9A1B7545; Mon, 03 Nov 2014 16:47:37 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415033253!11360328!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31763 invoked from network); 3 Nov 2014 16:47:36 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:36 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW69203; Tue, 04 Nov 2014 00:47:32 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:24 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:34 +0000
Message-ID: <1415033196-30529-6-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 5/7] xen/arm: handle GICH register changes
	for hip04-d01 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

The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 04e1850..411b104 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -61,6 +61,9 @@
 #define GICH_V2_VMCR_PRIORITY_MASK   0x1f
 #define GICH_V2_VMCR_PRIORITY_SHIFT  27
 
+#define HIP04_GICH_APR  0x70
+#define HIP04_GICH_LR   0x80
+
 /* Global state */
 static struct {
     paddr_t dbase;            /* Address of distributor registers */
@@ -85,6 +88,8 @@ static DEFINE_PER_CPU(u16, gic_cpu_id);
 static unsigned int nr_gic_cpu_if = 8;
 static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
 static unsigned int gic_cpu_mask = 0xff;
+static unsigned int gich_apr = GICH_APR;
+static unsigned int gich_lr = GICH_LR;
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
@@ -155,9 +160,9 @@ static void gicv2_save_state(struct vcpu *v)
      * accessed simultaneously by another pCPU.
      */
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        v->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+        v->arch.gic.v2.lr[i] = readl_gich(gich_lr + i * 4);
 
-    v->arch.gic.v2.apr = readl_gich(GICH_APR);
+    v->arch.gic.v2.apr = readl_gich(gich_apr);
     v->arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
     /* Disable until next VCPU scheduled */
     writel_gich(0, GICH_HCR);
@@ -168,9 +173,9 @@ static void gicv2_restore_state(const struct vcpu *v)
     int i;
 
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        writel_gich(v->arch.gic.v2.lr[i], GICH_LR + i * 4);
+        writel_gich(v->arch.gic.v2.lr[i], gich_lr + i * 4);
 
-    writel_gich(v->arch.gic.v2.apr, GICH_APR);
+    writel_gich(v->arch.gic.v2.apr, gich_apr);
     writel_gich(v->arch.gic.v2.vmcr, GICH_VMCR);
     writel_gich(GICH_HCR_EN, GICH_HCR);
 }
@@ -183,7 +188,7 @@ static void gicv2_dump_state(const struct vcpu *v)
     {
         for ( i = 0; i < gicv2_info.nr_lrs; i++ )
             printk("   HW_LR[%d]=%x\n", i,
-                   readl_gich(GICH_LR + i * 4));
+                   readl_gich(gich_lr + i * 4));
     }
     else
     {
@@ -437,12 +442,12 @@ static void gicv2_update_lr(int lr, const struct pending_irq *p,
                             << GICH_V2_LR_PHYSICAL_SHIFT);
     }
 
-    writel_gich(lr_reg, GICH_LR + lr * 4);
+    writel_gich(lr_reg, gich_lr + lr * 4);
 }
 
 static void gicv2_clear_lr(int lr)
 {
-    writel_gich(0, GICH_LR + lr * 4);
+    writel_gich(0, gich_lr + lr * 4);
 }
 
 static int gicv2v_setup(struct domain *d)
@@ -492,7 +497,7 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 {
     uint32_t lrv;
 
-    lrv          = readl_gich(GICH_LR + lr * 4);
+    lrv          = readl_gich(gich_lr + lr * 4);
     lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) & GICH_V2_LR_PHYSICAL_MASK;
     lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
     lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & GICH_V2_LR_PRIORITY_MASK;
@@ -515,7 +520,7 @@ static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
                                        << GICH_V2_LR_HW_SHIFT)  |
           ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) << GICH_V2_LR_GRP_SHIFT) );
 
-    writel_gich(lrv, GICH_LR + lr * 4);
+    writel_gich(lrv, gich_lr + lr * 4);
 }
 
 static void gicv2_hcr_status(uint32_t flag, bool_t status)
@@ -538,7 +543,7 @@ static unsigned int gicv2_read_vmcr_priority(void)
 
 static unsigned int gicv2_read_apr(int apr_reg)
 {
-   return readl_gich(GICH_APR);
+   return readl_gich(gich_apr);
 }
 
 static void gicv2_irq_enable(struct irq_desc *desc)
@@ -727,6 +732,8 @@ static int __init gicv2_init_common(struct dt_device_node *node, const void *dat
         nr_gic_cpu_if = 16;
         gicd_sgi_target_shift = 8;
         gic_cpu_mask = 0xffff;
+        gich_apr = HIP04_GICH_APR;
+        gich_lr = HIP04_GICH_LR;
     }
 
     res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKn6-0000Wo-Qf; Mon, 03 Nov 2014 16:47:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKn4-0000V5-Ge
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:38 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	95/7A-25547-9A1B7545; Mon, 03 Nov 2014 16:47:37 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415033253!11360328!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31763 invoked from network); 3 Nov 2014 16:47:36 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:36 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW69203; Tue, 04 Nov 2014 00:47:32 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:24 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:34 +0000
Message-ID: <1415033196-30529-6-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 5/7] xen/arm: handle GICH register changes
	for hip04-d01 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

The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 04e1850..411b104 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -61,6 +61,9 @@
 #define GICH_V2_VMCR_PRIORITY_MASK   0x1f
 #define GICH_V2_VMCR_PRIORITY_SHIFT  27
 
+#define HIP04_GICH_APR  0x70
+#define HIP04_GICH_LR   0x80
+
 /* Global state */
 static struct {
     paddr_t dbase;            /* Address of distributor registers */
@@ -85,6 +88,8 @@ static DEFINE_PER_CPU(u16, gic_cpu_id);
 static unsigned int nr_gic_cpu_if = 8;
 static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
 static unsigned int gic_cpu_mask = 0xff;
+static unsigned int gich_apr = GICH_APR;
+static unsigned int gich_lr = GICH_LR;
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
@@ -155,9 +160,9 @@ static void gicv2_save_state(struct vcpu *v)
      * accessed simultaneously by another pCPU.
      */
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        v->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+        v->arch.gic.v2.lr[i] = readl_gich(gich_lr + i * 4);
 
-    v->arch.gic.v2.apr = readl_gich(GICH_APR);
+    v->arch.gic.v2.apr = readl_gich(gich_apr);
     v->arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
     /* Disable until next VCPU scheduled */
     writel_gich(0, GICH_HCR);
@@ -168,9 +173,9 @@ static void gicv2_restore_state(const struct vcpu *v)
     int i;
 
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        writel_gich(v->arch.gic.v2.lr[i], GICH_LR + i * 4);
+        writel_gich(v->arch.gic.v2.lr[i], gich_lr + i * 4);
 
-    writel_gich(v->arch.gic.v2.apr, GICH_APR);
+    writel_gich(v->arch.gic.v2.apr, gich_apr);
     writel_gich(v->arch.gic.v2.vmcr, GICH_VMCR);
     writel_gich(GICH_HCR_EN, GICH_HCR);
 }
@@ -183,7 +188,7 @@ static void gicv2_dump_state(const struct vcpu *v)
     {
         for ( i = 0; i < gicv2_info.nr_lrs; i++ )
             printk("   HW_LR[%d]=%x\n", i,
-                   readl_gich(GICH_LR + i * 4));
+                   readl_gich(gich_lr + i * 4));
     }
     else
     {
@@ -437,12 +442,12 @@ static void gicv2_update_lr(int lr, const struct pending_irq *p,
                             << GICH_V2_LR_PHYSICAL_SHIFT);
     }
 
-    writel_gich(lr_reg, GICH_LR + lr * 4);
+    writel_gich(lr_reg, gich_lr + lr * 4);
 }
 
 static void gicv2_clear_lr(int lr)
 {
-    writel_gich(0, GICH_LR + lr * 4);
+    writel_gich(0, gich_lr + lr * 4);
 }
 
 static int gicv2v_setup(struct domain *d)
@@ -492,7 +497,7 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 {
     uint32_t lrv;
 
-    lrv          = readl_gich(GICH_LR + lr * 4);
+    lrv          = readl_gich(gich_lr + lr * 4);
     lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) & GICH_V2_LR_PHYSICAL_MASK;
     lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
     lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & GICH_V2_LR_PRIORITY_MASK;
@@ -515,7 +520,7 @@ static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
                                        << GICH_V2_LR_HW_SHIFT)  |
           ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) << GICH_V2_LR_GRP_SHIFT) );
 
-    writel_gich(lrv, GICH_LR + lr * 4);
+    writel_gich(lrv, gich_lr + lr * 4);
 }
 
 static void gicv2_hcr_status(uint32_t flag, bool_t status)
@@ -538,7 +543,7 @@ static unsigned int gicv2_read_vmcr_priority(void)
 
 static unsigned int gicv2_read_apr(int apr_reg)
 {
-   return readl_gich(GICH_APR);
+   return readl_gich(gich_apr);
 }
 
 static void gicv2_irq_enable(struct irq_desc *desc)
@@ -727,6 +732,8 @@ static int __init gicv2_init_common(struct dt_device_node *node, const void *dat
         nr_gic_cpu_if = 16;
         gicd_sgi_target_shift = 8;
         gic_cpu_mask = 0xffff;
+        gich_apr = HIP04_GICH_APR;
+        gich_lr = HIP04_GICH_LR;
     }
 
     res = dt_device_get_address(node, 0, &gicv2.dbase, NULL);
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKnA-0000Zj-Eb; Mon, 03 Nov 2014 16:47:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKn9-0000YL-3I
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:43 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	F2/FE-24124-EA1B7545; Mon, 03 Nov 2014 16:47:42 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415033258!10953183!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23383 invoked from network); 3 Nov 2014 16:47:41 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:41 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW69205; Tue, 04 Nov 2014 00:47:37 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:27 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:35 +0000
Message-ID: <1415033196-30529-7-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 6/7] xen/arm: Force domains to use normal
	GICv2 driver on Hip04 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

Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 411b104..cea9edc 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -639,6 +639,12 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOENT);
     }
 
+    if ( nr_gic_cpu_if == 16 )
+    {
+        compatible = DT_COMPAT_GIC_CORTEX_A15;
+        len = strlen((char*) compatible) + 1;
+    }
+
     res = fdt_begin_node(fdt, "interrupt-controller");
     if ( res )
         return res;
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKnA-0000Zj-Eb; Mon, 03 Nov 2014 16:47:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKn9-0000YL-3I
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:43 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	F2/FE-24124-EA1B7545; Mon, 03 Nov 2014 16:47:42 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415033258!10953183!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23383 invoked from network); 3 Nov 2014 16:47:41 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:41 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW69205; Tue, 04 Nov 2014 00:47:37 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:27 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:35 +0000
Message-ID: <1415033196-30529-7-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 6/7] xen/arm: Force domains to use normal
	GICv2 driver on Hip04 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

Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 411b104..cea9edc 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -639,6 +639,12 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOENT);
     }
 
+    if ( nr_gic_cpu_if == 16 )
+    {
+        compatible = DT_COMPAT_GIC_CORTEX_A15;
+        len = strlen((char*) compatible) + 1;
+    }
+
     res = fdt_begin_node(fdt, "interrupt-controller");
     if ( res )
         return res;
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKnA-0000aL-SB; Mon, 03 Nov 2014 16:47:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKn9-0000Yf-M4
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:43 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	04/E3-17735-EA1B7545; Mon, 03 Nov 2014 16:47:42 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415033258!11339363!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11672 invoked from network); 3 Nov 2014 16:47:42 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:42 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW69208; Tue, 04 Nov 2014 00:47:37 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:31 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:36 +0000
Message-ID: <1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 7/7] xen/arm: Move vGIC registers on Hip04
	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

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
 xen/include/asm-arm/gic.h |  2 ++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index cea9edc..eb8cc19 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -669,8 +669,19 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOMEM);
 
     tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+
+    if ( nr_gic_cpu_if == 16 )
+    {
+        dt_set_range(&tmp, node, d->arch.vgic.dbase - HIP04_VGIC_REG_OFFSET,
+                     PAGE_SIZE);
+        dt_set_range(&tmp, node, d->arch.vgic.cbase - HIP04_VGIC_REG_OFFSET,
+                     PAGE_SIZE * 2);
+    }
+    else
+    {
+        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
+        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+    }
 
     res = fdt_property(fdt, "reg", new_cells, len);
     xfree(new_cells);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 3d2b3db..5af8201 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -147,6 +147,8 @@
 #define GICH_LR_PENDING         1
 #define GICH_LR_ACTIVE          2
 
+#define HIP04_VGIC_REG_OFFSET   0xe0000000
+
 #ifndef __ASSEMBLY__
 #include <xen/device_tree.h>
 #include <xen/irq.h>
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:47:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16:47:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlKnA-0000aL-SB; Mon, 03 Nov 2014 16:47:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlKn9-0000Yf-M4
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 16:47:43 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	04/E3-17735-EA1B7545; Mon, 03 Nov 2014 16:47:42 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415033258!11339363!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11672 invoked from network); 3 Nov 2014 16:47:42 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 16:47:42 -0000
Received: from 172.24.2.119 (EHLO szxeml424-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDW69208; Tue, 04 Nov 2014 00:47:37 +0800 (CST)
Received: from localhost.localdomain (10.47.77.41) by
	szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP
	Server id 14.3.158.1; Tue, 4 Nov 2014 00:47:31 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Mon, 3 Nov 2014 16:46:36 +0000
Message-ID: <1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.77.41]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 7/7] xen/arm: Move vGIC registers on Hip04
	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

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
 xen/include/asm-arm/gic.h |  2 ++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index cea9edc..eb8cc19 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -669,8 +669,19 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOMEM);
 
     tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+
+    if ( nr_gic_cpu_if == 16 )
+    {
+        dt_set_range(&tmp, node, d->arch.vgic.dbase - HIP04_VGIC_REG_OFFSET,
+                     PAGE_SIZE);
+        dt_set_range(&tmp, node, d->arch.vgic.cbase - HIP04_VGIC_REG_OFFSET,
+                     PAGE_SIZE * 2);
+    }
+    else
+    {
+        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
+        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+    }
 
     res = fdt_property(fdt, "reg", new_cells, len);
     xfree(new_cells);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 3d2b3db..5af8201 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -147,6 +147,8 @@
 #define GICH_LR_PENDING         1
 #define GICH_LR_ACTIVE          2
 
+#define HIP04_VGIC_REG_OFFSET   0xe0000000
+
 #ifndef __ASSEMBLY__
 #include <xen/device_tree.h>
 #include <xen/irq.h>
-- 
1.9.1



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:58:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16: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 1XlKx0-0001n3-LD; Mon, 03 Nov 2014 16:57:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <toshi.kani@hp.com>) id 1XlKwz-0001my-Lj
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 16:57:53 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	5D/44-09284-014B7545; Mon, 03 Nov 2014 16:57:52 +0000
X-Env-Sender: toshi.kani@hp.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415033871!11340436!1
X-Originating-IP: [15.201.208.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32504 invoked from network); 3 Nov 2014 16:57:52 -0000
Received: from g4t3426.houston.hp.com (HELO g4t3426.houston.hp.com)
	(15.201.208.54)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 16:57:52 -0000
Received: from g9t2301.houston.hp.com (g9t2301.houston.hp.com [16.216.185.78])
	by g4t3426.houston.hp.com (Postfix) with ESMTP id 1CD6E82;
	Mon,  3 Nov 2014 16:57:50 +0000 (UTC)
Received: from [16.78.168.61] (misato.fc.hp.com [16.78.168.61])
	by g9t2301.houston.hp.com (Postfix) with ESMTP id 8FAEF74;
	Mon,  3 Nov 2014 16:57:48 +0000 (UTC)
Message-ID: <1415033030.29109.13.camel@misato.fc.hp.com>
From: Toshi Kani <toshi.kani@hp.com>
To: Juergen Gross <jgross@suse.com>
Date: Mon, 03 Nov 2014 09:43:50 -0700
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, tomi.valkeinen@ti.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	mingo@redhat.com, david.vrabel@citrix.com, jbeulich@suse.com,
	hpa@zytor.com, bhelgaas@google.com, tglx@linutronix.de,
	plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 14:01 +0100, Juergen Gross wrote:
> The x86 architecture offers via the PAT (Page Attribute Table) a way to
> specify different caching modes in page table entries. The PAT MSR contains
> 8 entries each specifying one of 6 possible cache modes. A pte references one
> of those entries via 3 bits: _PAGE_PAT, _PAGE_PWT and _PAGE_PCD.
> 
> The Linux kernel currently supports only 4 different cache modes. The PAT MSR
> is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the
> top 4 entries in the PAT MSR are the same as the 4 lower entries.
> 
> This results in the kernel not supporting e.g. write-through mode. Especially
> this cache mode would speed up drivers of video cards which now have to use
> uncached accesses.
> 
> OTOH some old processors (Pentium) don't support PAT correctly and the Xen
> hypervisor has been using a different PAT MSR configuration for some time now
> and can't change that as this setting is part of the ABI.
> 
> This patch set abstracts the cache mode from the pte and introduces tables to
> translate between cache mode and pte bits (the default cache mode "write back"
> is hard-wired to PAT entry 0). The tables are statically initialized with
> values being compatible to old processors and current usage. As soon as the
> PAT MSR is changed (or - in case of Xen - is read at boot time) the tables are
> changed accordingly. Requests of mappings with special cache modes are always
> possible now, in case they are not supported there will be a fallback to a
> compatible but slower mode.
> 
> Summing it up, this patch set adds the following features:
> - capability to support WT and WP cache modes on processors with full PAT
>   support
> - processors with no or uncorrect PAT support are still working as today, even
>   if WT or WP cache mode are selected by drivers for some pages
> - reduction of Xen special handling regarding cache mode
> 
> Changes in V6:
> - add new patch 10 (x86: Remove looking for setting of _PAGE_PAT_LARGE in
>   pageattr.c) as suggested by Thomas Gleixner
> - replaced SOB of Stefan Bader by "Based-on-patch-by:" as suggested by
>   Borislav Petkov

For patch 01/18 to 16/18:

Reviewed-by: Toshi Kani <toshi.kani@hp.com>

Thanks,
-Toshi



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 16:58:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 16: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 1XlKx0-0001n3-LD; Mon, 03 Nov 2014 16:57:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <toshi.kani@hp.com>) id 1XlKwz-0001my-Lj
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 16:57:53 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	5D/44-09284-014B7545; Mon, 03 Nov 2014 16:57:52 +0000
X-Env-Sender: toshi.kani@hp.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415033871!11340436!1
X-Originating-IP: [15.201.208.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32504 invoked from network); 3 Nov 2014 16:57:52 -0000
Received: from g4t3426.houston.hp.com (HELO g4t3426.houston.hp.com)
	(15.201.208.54)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 16:57:52 -0000
Received: from g9t2301.houston.hp.com (g9t2301.houston.hp.com [16.216.185.78])
	by g4t3426.houston.hp.com (Postfix) with ESMTP id 1CD6E82;
	Mon,  3 Nov 2014 16:57:50 +0000 (UTC)
Received: from [16.78.168.61] (misato.fc.hp.com [16.78.168.61])
	by g9t2301.houston.hp.com (Postfix) with ESMTP id 8FAEF74;
	Mon,  3 Nov 2014 16:57:48 +0000 (UTC)
Message-ID: <1415033030.29109.13.camel@misato.fc.hp.com>
From: Toshi Kani <toshi.kani@hp.com>
To: Juergen Gross <jgross@suse.com>
Date: Mon, 03 Nov 2014 09:43:50 -0700
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, tomi.valkeinen@ti.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	mingo@redhat.com, david.vrabel@citrix.com, jbeulich@suse.com,
	hpa@zytor.com, bhelgaas@google.com, tglx@linutronix.de,
	plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 14:01 +0100, Juergen Gross wrote:
> The x86 architecture offers via the PAT (Page Attribute Table) a way to
> specify different caching modes in page table entries. The PAT MSR contains
> 8 entries each specifying one of 6 possible cache modes. A pte references one
> of those entries via 3 bits: _PAGE_PAT, _PAGE_PWT and _PAGE_PCD.
> 
> The Linux kernel currently supports only 4 different cache modes. The PAT MSR
> is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the
> top 4 entries in the PAT MSR are the same as the 4 lower entries.
> 
> This results in the kernel not supporting e.g. write-through mode. Especially
> this cache mode would speed up drivers of video cards which now have to use
> uncached accesses.
> 
> OTOH some old processors (Pentium) don't support PAT correctly and the Xen
> hypervisor has been using a different PAT MSR configuration for some time now
> and can't change that as this setting is part of the ABI.
> 
> This patch set abstracts the cache mode from the pte and introduces tables to
> translate between cache mode and pte bits (the default cache mode "write back"
> is hard-wired to PAT entry 0). The tables are statically initialized with
> values being compatible to old processors and current usage. As soon as the
> PAT MSR is changed (or - in case of Xen - is read at boot time) the tables are
> changed accordingly. Requests of mappings with special cache modes are always
> possible now, in case they are not supported there will be a fallback to a
> compatible but slower mode.
> 
> Summing it up, this patch set adds the following features:
> - capability to support WT and WP cache modes on processors with full PAT
>   support
> - processors with no or uncorrect PAT support are still working as today, even
>   if WT or WP cache mode are selected by drivers for some pages
> - reduction of Xen special handling regarding cache mode
> 
> Changes in V6:
> - add new patch 10 (x86: Remove looking for setting of _PAGE_PAT_LARGE in
>   pageattr.c) as suggested by Thomas Gleixner
> - replaced SOB of Stefan Bader by "Based-on-patch-by:" as suggested by
>   Borislav Petkov

For patch 01/18 to 16/18:

Reviewed-by: Toshi Kani <toshi.kani@hp.com>

Thanks,
-Toshi



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 17:12:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 17:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlLAT-00028g-1R; Mon, 03 Nov 2014 17:11:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1XlLAR-00028a-BD
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 17:11:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/57-09936-257B7545; Mon, 03 Nov 2014 17:11:46 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415034704!12444244!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22425 invoked from network); 3 Nov 2014 17:11:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 17:11:45 -0000
Received: from int-mx13.intmail.prod.int.phx2.redhat.com
	(int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA3HBcTJ006691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 3 Nov 2014 12:11:38 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sA3HBYcd004862
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Mon, 3 Nov 2014 12:11:35 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
	<54577368.9060000@redhat.com> <5457A401.5040908@oracle.com>
Date: Mon, 03 Nov 2014 18:11:34 +0100
In-Reply-To: <5457A401.5040908@oracle.com> (Boris Ostrovsky's message of "Mon, 
	03 Nov 2014 10:49:21 -0500")
Message-ID: <87vbmw9pkp.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Cc: Andrew Jones <drjones@redhat.com>, linux-kernel@vger.kernel.org,
	Jeff Moyer <jmoyer@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: improve protection against
	issuing unsupported REQ_FUA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky <boris.ostrovsky@oracle.com> writes:

> On 11/03/2014 07:22 AM, Laszlo Ersek wrote:
>> On 10/27/14 14:44, Vitaly Kuznetsov wrote:
>>> Guard against issuing unsupported REQ_FUA and REQ_FLUSH was introduced
>>> in d11e61583 and was factored out into blkif_request_flush_valid() in
>>> 0f1ca65ee. However:
>>> 1) This check in incomplete. In case we negotiated to feature_flush = REQ_FLUSH
>>>     and flush_op = BLKIF_OP_FLUSH_DISKCACHE (so FUA is unsupported) FUA request
>>>     will still pass the check.
>>> 2) blkif_request_flush_valid() is misnamed. It is bool but returns true when
>>>     the request is invalid.
>>> 3) When blkif_request_flush_valid() fails -EIO is being returned. It seems that
>>>     -EOPNOTSUPP is more appropriate here.
>>> Fix all of the above issues.
>>>
>>> This patch is based on the original patch by Laszlo Ersek and a comment by
>>> Jeff Moyer.
>>>
>>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>>> ---
>>>   drivers/block/xen-blkfront.c | 14 ++++++++------
>>>   1 file changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>>> index 5ac312f..2e6c103 100644
>>> --- a/drivers/block/xen-blkfront.c
>>> +++ b/drivers/block/xen-blkfront.c
>>> @@ -582,12 +582,14 @@ static inline void flush_requests(struct blkfront_info *info)
>>>   		notify_remote_via_irq(info->irq);
>>>   }
>>>   -static inline bool blkif_request_flush_valid(struct request
>>> *req,
>>> -					     struct blkfront_info *info)
>>> +static inline bool blkif_request_flush_invalid(struct request *req,
>>> +					       struct blkfront_info *info)
>>>   {
>>>   	return ((req->cmd_type != REQ_TYPE_FS) ||
>>> -		((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
>>> -		!info->flush_op));
>>> +		((req->cmd_flags & REQ_FLUSH) &&
>>> +		 !(info->feature_flush & REQ_FLUSH)) ||
>>> +		((req->cmd_flags & REQ_FUA) &&
>>> +		 !(info->feature_flush & REQ_FUA)));
>
> Somewhat unrelated to the patch, but I am wondering whether we
> actually need flush_op field at all as it seems that it is
> unambiguously defined by REQ_FLUSH/REQ_FUA.

I was under an impression it was added for readability sake but we
definitely can remove it. If noone objects I'll send separate cleanup
patch (don't want to mix these two).

>
> -boris
>
>>>   }
>>>     /*
>>> @@ -612,8 +614,8 @@ static void do_blkif_request(struct request_queue *rq)
>>>     		blk_start_request(req);
>>>   -		if (blkif_request_flush_valid(req, info)) {
>>> -			__blk_end_request_all(req, -EIO);
>>> +		if (blkif_request_flush_invalid(req, info)) {
>>> +			__blk_end_request_all(req, -EOPNOTSUPP);
>>>   			continue;
>>>   		}
>>>   
>>>
>> Not sure if there has been some feedback yet (I can't see anything
>> threaded with this message in my inbox).
>>
>> FWIW I consulted "Documentation/block/writeback_cache_control.txt" for
>> this review. Apparently, REQ_FLUSH forces out "previously completed
>> write requests", whereas REQ_FUA delays the IO completion signal for
>> *this* request until "the data has been committed to non-volatile
>> storage". So, indeed, support for REQ_FLUSH only does not guarantee that
>> REQ_FUA can be served.
>>
>> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
>>
>> Thanks
>> Laszlo

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 17:12:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 17:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlLAT-00028g-1R; Mon, 03 Nov 2014 17:11:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1XlLAR-00028a-BD
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 17:11:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/57-09936-257B7545; Mon, 03 Nov 2014 17:11:46 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415034704!12444244!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22425 invoked from network); 3 Nov 2014 17:11:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 17:11:45 -0000
Received: from int-mx13.intmail.prod.int.phx2.redhat.com
	(int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA3HBcTJ006691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 3 Nov 2014 12:11:38 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sA3HBYcd004862
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Mon, 3 Nov 2014 12:11:35 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
	<54577368.9060000@redhat.com> <5457A401.5040908@oracle.com>
Date: Mon, 03 Nov 2014 18:11:34 +0100
In-Reply-To: <5457A401.5040908@oracle.com> (Boris Ostrovsky's message of "Mon, 
	03 Nov 2014 10:49:21 -0500")
Message-ID: <87vbmw9pkp.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Cc: Andrew Jones <drjones@redhat.com>, linux-kernel@vger.kernel.org,
	Jeff Moyer <jmoyer@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: improve protection against
	issuing unsupported REQ_FUA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky <boris.ostrovsky@oracle.com> writes:

> On 11/03/2014 07:22 AM, Laszlo Ersek wrote:
>> On 10/27/14 14:44, Vitaly Kuznetsov wrote:
>>> Guard against issuing unsupported REQ_FUA and REQ_FLUSH was introduced
>>> in d11e61583 and was factored out into blkif_request_flush_valid() in
>>> 0f1ca65ee. However:
>>> 1) This check in incomplete. In case we negotiated to feature_flush = REQ_FLUSH
>>>     and flush_op = BLKIF_OP_FLUSH_DISKCACHE (so FUA is unsupported) FUA request
>>>     will still pass the check.
>>> 2) blkif_request_flush_valid() is misnamed. It is bool but returns true when
>>>     the request is invalid.
>>> 3) When blkif_request_flush_valid() fails -EIO is being returned. It seems that
>>>     -EOPNOTSUPP is more appropriate here.
>>> Fix all of the above issues.
>>>
>>> This patch is based on the original patch by Laszlo Ersek and a comment by
>>> Jeff Moyer.
>>>
>>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>>> ---
>>>   drivers/block/xen-blkfront.c | 14 ++++++++------
>>>   1 file changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>>> index 5ac312f..2e6c103 100644
>>> --- a/drivers/block/xen-blkfront.c
>>> +++ b/drivers/block/xen-blkfront.c
>>> @@ -582,12 +582,14 @@ static inline void flush_requests(struct blkfront_info *info)
>>>   		notify_remote_via_irq(info->irq);
>>>   }
>>>   -static inline bool blkif_request_flush_valid(struct request
>>> *req,
>>> -					     struct blkfront_info *info)
>>> +static inline bool blkif_request_flush_invalid(struct request *req,
>>> +					       struct blkfront_info *info)
>>>   {
>>>   	return ((req->cmd_type != REQ_TYPE_FS) ||
>>> -		((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
>>> -		!info->flush_op));
>>> +		((req->cmd_flags & REQ_FLUSH) &&
>>> +		 !(info->feature_flush & REQ_FLUSH)) ||
>>> +		((req->cmd_flags & REQ_FUA) &&
>>> +		 !(info->feature_flush & REQ_FUA)));
>
> Somewhat unrelated to the patch, but I am wondering whether we
> actually need flush_op field at all as it seems that it is
> unambiguously defined by REQ_FLUSH/REQ_FUA.

I was under an impression it was added for readability sake but we
definitely can remove it. If noone objects I'll send separate cleanup
patch (don't want to mix these two).

>
> -boris
>
>>>   }
>>>     /*
>>> @@ -612,8 +614,8 @@ static void do_blkif_request(struct request_queue *rq)
>>>     		blk_start_request(req);
>>>   -		if (blkif_request_flush_valid(req, info)) {
>>> -			__blk_end_request_all(req, -EIO);
>>> +		if (blkif_request_flush_invalid(req, info)) {
>>> +			__blk_end_request_all(req, -EOPNOTSUPP);
>>>   			continue;
>>>   		}
>>>   
>>>
>> Not sure if there has been some feedback yet (I can't see anything
>> threaded with this message in my inbox).
>>
>> FWIW I consulted "Documentation/block/writeback_cache_control.txt" for
>> this review. Apparently, REQ_FLUSH forces out "previously completed
>> write requests", whereas REQ_FUA delays the IO completion signal for
>> *this* request until "the data has been committed to non-volatile
>> storage". So, indeed, support for REQ_FLUSH only does not guarantee that
>> REQ_FUA can be served.
>>
>> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
>>
>> Thanks
>> Laszlo

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 17:23:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 17:23:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlLLo-0002av-Ns; Mon, 03 Nov 2014 17:23:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mswilson@gmail.com>) id 1XlLLo-0002ao-BP
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 17:23:32 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	24/68-08051-31AB7545; Mon, 03 Nov 2014 17:23:31 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415035409!12283306!1
X-Originating-IP: [209.85.192.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30391 invoked from network); 3 Nov 2014 17:23:31 -0000
Received: from mail-pd0-f181.google.com (HELO mail-pd0-f181.google.com)
	(209.85.192.181)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 17:23:31 -0000
Received: by mail-pd0-f181.google.com with SMTP id y10so11902377pdj.12
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 09:23:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=CTrXqRsEPwJsk2dhdDm1hMypnlWKH0y3qVkMTxILpYI=;
	b=mMv1wrgdLgQu5kilXU3LePlzX+g2DmZFYwUsS7xnGI76LITnn+dcsOpj6Es9/XHvhs
	n1F9hlWxJmhr4l1IUZOGXtqXC810suSbkbfRNZ9azJ+jNjFMJlRYNRSlvc6P0+VHPNTW
	5tAWFllL6BzaCUP30/rXYZcEaopU4bp6Q1449JMQcTEBGzI5QSyfaV4Ejhn3mwmcbjh/
	xstAoM+/rWiOuU596vx7GGWuX3zUxB9mMcRd61MWGIzudh3fTaayCbhHHfkCJeR1Y3ww
	Ui9RpJgTidTkZmYKRxfjPLUSnkL8C8e0XpZMh47uj9I8WCZqAe2AkuIQZuT0taMn7vRa
	31KQ==
X-Received: by 10.68.227.104 with SMTP id rz8mr44527851pbc.4.1415035409198;
	Mon, 03 Nov 2014 09:23:29 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-169.amazon.com. [54.240.196.169])
	by mx.google.com with ESMTPSA id o6sm13220766pdl.3.2014.11.03.09.23.26
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 09:23:28 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Mon, 03 Nov 2014 09:23:25 -0800
Date: Mon, 3 Nov 2014 09:23:25 -0800
From: Matt Wilson <msw@linux.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141103172319.GA21654@u109add4315675089e695.ant.amazon.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<21586.10214.683512.296628@chiark.greenend.org.uk>
	<20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
	<CAFLBxZYOaMTDGg38x-TB+OgjH+-hXNTq0c+kHJ7Mu9sEXAcseA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZYOaMTDGg38x-TB+OgjH+-hXNTq0c+kHJ7Mu9sEXAcseA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <ijackson@chiark.greenend.org.uk>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 11:37:23AM +0000, George Dunlap wrote:
> On Fri, Oct 31, 2014 at 10:40 PM, Matt Wilson <msw@linux.com> wrote:
[...]
> > There's been a bit of talk about "delay" and so on. I'd rather not set
> > expectations on how long the processing a petition to be added to the
> > predisclosure list should take. Building community consensus takes
> > time, just as it does for other activities like getting a patch
> > applied. I don't think that this process needs to be different.
> 
> We might remove some of the (potential) pressure to rush things by
> saying that once approved, new members will not receive information
> about *currently embargoed* disclosures, but only about *future*
> disclosures.
> 
> I.e., the rush of people for XSA-108 wouldn't be in a rush because (by
> policy) they wouldn't have been eligible to receive XSA-108 anyway.
> 
> But perhaps that would be too unpopular to actually implement...

The decision making mechanics aside, that makes sense to me.

--msw

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 17:23:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 17:23:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlLLo-0002av-Ns; Mon, 03 Nov 2014 17:23:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mswilson@gmail.com>) id 1XlLLo-0002ao-BP
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 17:23:32 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	24/68-08051-31AB7545; Mon, 03 Nov 2014 17:23:31 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415035409!12283306!1
X-Originating-IP: [209.85.192.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30391 invoked from network); 3 Nov 2014 17:23:31 -0000
Received: from mail-pd0-f181.google.com (HELO mail-pd0-f181.google.com)
	(209.85.192.181)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 17:23:31 -0000
Received: by mail-pd0-f181.google.com with SMTP id y10so11902377pdj.12
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 09:23:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=CTrXqRsEPwJsk2dhdDm1hMypnlWKH0y3qVkMTxILpYI=;
	b=mMv1wrgdLgQu5kilXU3LePlzX+g2DmZFYwUsS7xnGI76LITnn+dcsOpj6Es9/XHvhs
	n1F9hlWxJmhr4l1IUZOGXtqXC810suSbkbfRNZ9azJ+jNjFMJlRYNRSlvc6P0+VHPNTW
	5tAWFllL6BzaCUP30/rXYZcEaopU4bp6Q1449JMQcTEBGzI5QSyfaV4Ejhn3mwmcbjh/
	xstAoM+/rWiOuU596vx7GGWuX3zUxB9mMcRd61MWGIzudh3fTaayCbhHHfkCJeR1Y3ww
	Ui9RpJgTidTkZmYKRxfjPLUSnkL8C8e0XpZMh47uj9I8WCZqAe2AkuIQZuT0taMn7vRa
	31KQ==
X-Received: by 10.68.227.104 with SMTP id rz8mr44527851pbc.4.1415035409198;
	Mon, 03 Nov 2014 09:23:29 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-169.amazon.com. [54.240.196.169])
	by mx.google.com with ESMTPSA id o6sm13220766pdl.3.2014.11.03.09.23.26
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 03 Nov 2014 09:23:28 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Mon, 03 Nov 2014 09:23:25 -0800
Date: Mon, 3 Nov 2014 09:23:25 -0800
From: Matt Wilson <msw@linux.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141103172319.GA21654@u109add4315675089e695.ant.amazon.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<21586.10214.683512.296628@chiark.greenend.org.uk>
	<20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
	<CAFLBxZYOaMTDGg38x-TB+OgjH+-hXNTq0c+kHJ7Mu9sEXAcseA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZYOaMTDGg38x-TB+OgjH+-hXNTq0c+kHJ7Mu9sEXAcseA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <ijackson@chiark.greenend.org.uk>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 11:37:23AM +0000, George Dunlap wrote:
> On Fri, Oct 31, 2014 at 10:40 PM, Matt Wilson <msw@linux.com> wrote:
[...]
> > There's been a bit of talk about "delay" and so on. I'd rather not set
> > expectations on how long the processing a petition to be added to the
> > predisclosure list should take. Building community consensus takes
> > time, just as it does for other activities like getting a patch
> > applied. I don't think that this process needs to be different.
> 
> We might remove some of the (potential) pressure to rush things by
> saying that once approved, new members will not receive information
> about *currently embargoed* disclosures, but only about *future*
> disclosures.
> 
> I.e., the rush of people for XSA-108 wouldn't be in a rush because (by
> policy) they wouldn't have been eligible to receive XSA-108 anyway.
> 
> But perhaps that would be too unpopular to actually implement...

The decision making mechanics aside, that makes sense to me.

--msw

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 17:24:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlLML-0002e8-5E; Mon, 03 Nov 2014 17:24:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XlLMJ-0002dw-Oa
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 17:24:03 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	0F/6D-01660-33AB7545; Mon, 03 Nov 2014 17:24:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415035440!10939639!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9572 invoked from network); 3 Nov 2014 17:24:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 17:24:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188979214"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 12:23:58 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XlLME-00062T-Hk;
	Mon, 03 Nov 2014 17:23:58 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <netdev@vger.kernel.org>
Date: Mon, 3 Nov 2014 17:23:51 +0000
Message-ID: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCHv1 net-next] xen-netback: remove unconditional
	pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Malcolm Crossley <malcolm.crossley@citrix.com>

Unconditionally pulling 128 bytes into the linear buffer is not
required. Netback has already grant copied up-to 128 bytes from the
first slot of a packet into the linear buffer. The first slot normally
contain all the IPv4/IPv6 and TCP/UDP headers.

The unconditional pull would often copy frag data unnecessarily.  This
is a performance problem when running on a version of Xen where grant
unmap avoids TLB flushes for pages which are not accessed.  TLB
flushes can now be avoided for > 99% of unmaps (it was 0% before).

Grant unmap TLB flush avoidance will be available in a future version
of Xen (probably 4.6).

Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/netback.c |   26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 730252c..14e18bb 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -82,6 +82,16 @@ MODULE_PARM_DESC(max_queues,
 static unsigned int fatal_skb_slots = FATAL_SKB_SLOTS_DEFAULT;
 module_param(fatal_skb_slots, uint, 0444);
 
+/* The amount to copy out of the first guest Tx slot into the skb's
+ * linear area.  If the first slot has more data, it will be mapped
+ * and put into the first frag.
+ *
+ * This is sized to avoid pulling headers from the frags for most
+ * TCP/IP packets.
+ */
+#define XEN_NETBACK_TX_COPY_LEN 128
+
+
 static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx,
 			       u8 status);
 
@@ -125,13 +135,6 @@ static inline struct xenvif_queue *ubuf_to_queue(const struct ubuf_info *ubuf)
 			    pending_tx_info[0]);
 }
 
-/* This is a miniumum size for the linear area to avoid lots of
- * calls to __pskb_pull_tail() as we set up checksum offsets. The
- * value 128 was chosen as it covers all IPv4 and most likely
- * IPv6 headers.
- */
-#define PKT_PROT_LEN 128
-
 static u16 frag_get_pending_idx(skb_frag_t *frag)
 {
 	return (u16)frag->page_offset;
@@ -1446,9 +1449,9 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
 		index = pending_index(queue->pending_cons);
 		pending_idx = queue->pending_ring[index];
 
-		data_len = (txreq.size > PKT_PROT_LEN &&
+		data_len = (txreq.size > XEN_NETBACK_TX_COPY_LEN &&
 			    ret < XEN_NETBK_LEGACY_SLOTS_MAX) ?
-			PKT_PROT_LEN : txreq.size;
+			XEN_NETBACK_TX_COPY_LEN : txreq.size;
 
 		skb = xenvif_alloc_skb(data_len);
 		if (unlikely(skb == NULL)) {
@@ -1653,11 +1656,6 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
 			}
 		}
 
-		if (skb_is_nonlinear(skb) && skb_headlen(skb) < PKT_PROT_LEN) {
-			int target = min_t(int, skb->len, PKT_PROT_LEN);
-			__pskb_pull_tail(skb, target - skb_headlen(skb));
-		}
-
 		skb->dev      = queue->vif->dev;
 		skb->protocol = eth_type_trans(skb, skb->dev);
 		skb_reset_network_header(skb);
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 17:24:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlLML-0002e8-5E; Mon, 03 Nov 2014 17:24:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XlLMJ-0002dw-Oa
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 17:24:03 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	0F/6D-01660-33AB7545; Mon, 03 Nov 2014 17:24:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415035440!10939639!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9572 invoked from network); 3 Nov 2014 17:24:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 17:24:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188979214"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 3 Nov 2014 12:23:58 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XlLME-00062T-Hk;
	Mon, 03 Nov 2014 17:23:58 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <netdev@vger.kernel.org>
Date: Mon, 3 Nov 2014 17:23:51 +0000
Message-ID: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCHv1 net-next] xen-netback: remove unconditional
	pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Malcolm Crossley <malcolm.crossley@citrix.com>

Unconditionally pulling 128 bytes into the linear buffer is not
required. Netback has already grant copied up-to 128 bytes from the
first slot of a packet into the linear buffer. The first slot normally
contain all the IPv4/IPv6 and TCP/UDP headers.

The unconditional pull would often copy frag data unnecessarily.  This
is a performance problem when running on a version of Xen where grant
unmap avoids TLB flushes for pages which are not accessed.  TLB
flushes can now be avoided for > 99% of unmaps (it was 0% before).

Grant unmap TLB flush avoidance will be available in a future version
of Xen (probably 4.6).

Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/netback.c |   26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 730252c..14e18bb 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -82,6 +82,16 @@ MODULE_PARM_DESC(max_queues,
 static unsigned int fatal_skb_slots = FATAL_SKB_SLOTS_DEFAULT;
 module_param(fatal_skb_slots, uint, 0444);
 
+/* The amount to copy out of the first guest Tx slot into the skb's
+ * linear area.  If the first slot has more data, it will be mapped
+ * and put into the first frag.
+ *
+ * This is sized to avoid pulling headers from the frags for most
+ * TCP/IP packets.
+ */
+#define XEN_NETBACK_TX_COPY_LEN 128
+
+
 static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx,
 			       u8 status);
 
@@ -125,13 +135,6 @@ static inline struct xenvif_queue *ubuf_to_queue(const struct ubuf_info *ubuf)
 			    pending_tx_info[0]);
 }
 
-/* This is a miniumum size for the linear area to avoid lots of
- * calls to __pskb_pull_tail() as we set up checksum offsets. The
- * value 128 was chosen as it covers all IPv4 and most likely
- * IPv6 headers.
- */
-#define PKT_PROT_LEN 128
-
 static u16 frag_get_pending_idx(skb_frag_t *frag)
 {
 	return (u16)frag->page_offset;
@@ -1446,9 +1449,9 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
 		index = pending_index(queue->pending_cons);
 		pending_idx = queue->pending_ring[index];
 
-		data_len = (txreq.size > PKT_PROT_LEN &&
+		data_len = (txreq.size > XEN_NETBACK_TX_COPY_LEN &&
 			    ret < XEN_NETBK_LEGACY_SLOTS_MAX) ?
-			PKT_PROT_LEN : txreq.size;
+			XEN_NETBACK_TX_COPY_LEN : txreq.size;
 
 		skb = xenvif_alloc_skb(data_len);
 		if (unlikely(skb == NULL)) {
@@ -1653,11 +1656,6 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
 			}
 		}
 
-		if (skb_is_nonlinear(skb) && skb_headlen(skb) < PKT_PROT_LEN) {
-			int target = min_t(int, skb->len, PKT_PROT_LEN);
-			__pskb_pull_tail(skb, target - skb_headlen(skb));
-		}
-
 		skb->dev      = queue->vif->dev;
 		skb->protocol = eth_type_trans(skb, skb->dev);
 		skb_reset_network_header(skb);
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 17:42:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlLdP-0003FG-Dm; Mon, 03 Nov 2014 17:41:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlLdO-0003FB-7z
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 17:41:42 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	D2/59-17694-45EB7545; Mon, 03 Nov 2014 17:41:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415036497!6918923!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26426 invoked from network); 3 Nov 2014 17:41:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 17:41:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188986481"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 12:41:33 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlLdF-0000UM-GC;
	Mon, 03 Nov 2014 17:41:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlLdF-0006IU-Ac;
	Mon, 03 Nov 2014 17:41:33 +0000
Date: Mon, 3 Nov 2014 17:41:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31341-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31341: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10      fail pass in 31318
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 31318 pass in 31341
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate/x10 fail in 31318 pass in 31341

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           4 xen-install                  fail   like 30750

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 03 17:42:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 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.xen.org>)
	id 1XlLdP-0003FG-Dm; Mon, 03 Nov 2014 17:41:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlLdO-0003FB-7z
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 17:41:42 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	D2/59-17694-45EB7545; Mon, 03 Nov 2014 17:41:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415036497!6918923!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26426 invoked from network); 3 Nov 2014 17:41:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 17:41:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188986481"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 12:41:33 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlLdF-0000UM-GC;
	Mon, 03 Nov 2014 17:41:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlLdF-0006IU-Ac;
	Mon, 03 Nov 2014 17:41:33 +0000
Date: Mon, 3 Nov 2014 17:41:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31341-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31341: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10      fail pass in 31318
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 31318 pass in 31341
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate/x10 fail in 31318 pass in 31341

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           4 xen-install                  fail   like 30750

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 03 17:46:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 17:46:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlLiJ-0003Ze-8Y; Mon, 03 Nov 2014 17:46:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XlLiH-0003ZY-Ri
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 17:46:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	98/3C-09842-58FB7545; Mon, 03 Nov 2014 17:46:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415036803!12487597!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24375 invoked from network); 3 Nov 2014 17:46:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 17:46:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188989265"
Message-ID: <5457BF80.2000205@citrix.com>
Date: Mon, 3 Nov 2014 17:46:40 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
	<1415036346.1411.3.camel@citrix.com>
In-Reply-To: <1415036346.1411.3.camel@citrix.com>
X-DLP: MIA1
Cc: netdev@vger.kernel.org, Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/11/14 17:39, Ian Campbell wrote:
> On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
>> From: Malcolm Crossley <malcolm.crossley@citrix.com>
>>
>> Unconditionally pulling 128 bytes into the linear buffer is not
>> required. Netback has already grant copied up-to 128 bytes from the
>> first slot of a packet into the linear buffer. The first slot normally
>> contain all the IPv4/IPv6 and TCP/UDP headers.
> 
> What about when it doesn't? It sounds as if we now won't pull up, which
> would be bad.

The network stack will always pull any headers it needs to inspect (the
frag may be a userspace page which has the same security issues as a
frag with a foreign page).

e.g., see skb_checksum_setup() called slightly later on in netback.

> To avoid the pull up the code would need to grant copy up-to 128 bytes
> from as many slots as needed, not only the first.
> 
> Also, if the grant copy has already placed 128 bytes in the linear area,
> why is the pull up touching anything in the first place? Shouldn't it be
> a nop in that case?

The grant copy only copies from the first frag which may be less than
128 bytes in length.

David

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 17:46:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 17:46:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlLiJ-0003Ze-8Y; Mon, 03 Nov 2014 17:46:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XlLiH-0003ZY-Ri
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 17:46:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	98/3C-09842-58FB7545; Mon, 03 Nov 2014 17:46:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415036803!12487597!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24375 invoked from network); 3 Nov 2014 17:46:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 17:46:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188989265"
Message-ID: <5457BF80.2000205@citrix.com>
Date: Mon, 3 Nov 2014 17:46:40 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
	<1415036346.1411.3.camel@citrix.com>
In-Reply-To: <1415036346.1411.3.camel@citrix.com>
X-DLP: MIA1
Cc: netdev@vger.kernel.org, Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/11/14 17:39, Ian Campbell wrote:
> On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
>> From: Malcolm Crossley <malcolm.crossley@citrix.com>
>>
>> Unconditionally pulling 128 bytes into the linear buffer is not
>> required. Netback has already grant copied up-to 128 bytes from the
>> first slot of a packet into the linear buffer. The first slot normally
>> contain all the IPv4/IPv6 and TCP/UDP headers.
> 
> What about when it doesn't? It sounds as if we now won't pull up, which
> would be bad.

The network stack will always pull any headers it needs to inspect (the
frag may be a userspace page which has the same security issues as a
frag with a foreign page).

e.g., see skb_checksum_setup() called slightly later on in netback.

> To avoid the pull up the code would need to grant copy up-to 128 bytes
> from as many slots as needed, not only the first.
> 
> Also, if the grant copy has already placed 128 bytes in the linear area,
> why is the pull up touching anything in the first place? Shouldn't it be
> a nop in that case?

The grant copy only copies from the first frag which may be less than
128 bytes in length.

David

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 17:56:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 17:56:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlLrV-0003vJ-GN; Mon, 03 Nov 2014 17:56:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlLrT-0003vE-BA
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 17:56:15 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	A8/1D-11608-EB1C7545; Mon, 03 Nov 2014 17:56:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415037371!11324234!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4715 invoked from network); 3 Nov 2014 17:56:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 17:56:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="187603595"
Message-ID: <1415036346.1411.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 3 Nov 2014 17:39:06 +0000
In-Reply-To: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: netdev@vger.kernel.org, Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> 
> Unconditionally pulling 128 bytes into the linear buffer is not
> required. Netback has already grant copied up-to 128 bytes from the
> first slot of a packet into the linear buffer. The first slot normally
> contain all the IPv4/IPv6 and TCP/UDP headers.

What about when it doesn't? It sounds as if we now won't pull up, which
would be bad.

To avoid the pull up the code would need to grant copy up-to 128 bytes
from as many slots as needed, not only the first.

Also, if the grant copy has already placed 128 bytes in the linear area,
why is the pull up touching anything in the first place? Shouldn't it be
a nop in that case?

> The unconditional pull would often copy frag data unnecessarily.  This
> is a performance problem when running on a version of Xen where grant
> unmap avoids TLB flushes for pages which are not accessed.  TLB
> flushes can now be avoided for > 99% of unmaps (it was 0% before).
> 
> Grant unmap TLB flush avoidance will be available in a future version
> of Xen (probably 4.6).
> 
> Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  drivers/net/xen-netback/netback.c |   26 ++++++++++++--------------
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 730252c..14e18bb 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -82,6 +82,16 @@ MODULE_PARM_DESC(max_queues,
>  static unsigned int fatal_skb_slots = FATAL_SKB_SLOTS_DEFAULT;
>  module_param(fatal_skb_slots, uint, 0444);
>  
> +/* The amount to copy out of the first guest Tx slot into the skb's
> + * linear area.  If the first slot has more data, it will be mapped
> + * and put into the first frag.
> + *
> + * This is sized to avoid pulling headers from the frags for most
> + * TCP/IP packets.
> + */
> +#define XEN_NETBACK_TX_COPY_LEN 128

Was it strictly necessary to both move and rename this? I can see why
the comment needed to change.

>  static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx,
>  			       u8 status);
>  
> @@ -125,13 +135,6 @@ static inline struct xenvif_queue *ubuf_to_queue(const struct ubuf_info *ubuf)
>  			    pending_tx_info[0]);
>  }
>  
> -/* This is a miniumum size for the linear area to avoid lots of
> - * calls to __pskb_pull_tail() as we set up checksum offsets. The
> - * value 128 was chosen as it covers all IPv4 and most likely
> - * IPv6 headers.
> - */
> -#define PKT_PROT_LEN 128
> -
>  static u16 frag_get_pending_idx(skb_frag_t *frag)
>  {
>  	return (u16)frag->page_offset;
> @@ -1446,9 +1449,9 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
>  		index = pending_index(queue->pending_cons);
>  		pending_idx = queue->pending_ring[index];
>  
> -		data_len = (txreq.size > PKT_PROT_LEN &&
> +		data_len = (txreq.size > XEN_NETBACK_TX_COPY_LEN &&
>  			    ret < XEN_NETBK_LEGACY_SLOTS_MAX) ?
> -			PKT_PROT_LEN : txreq.size;
> +			XEN_NETBACK_TX_COPY_LEN : txreq.size;
>  
>  		skb = xenvif_alloc_skb(data_len);
>  		if (unlikely(skb == NULL)) {
> @@ -1653,11 +1656,6 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
>  			}
>  		}
>  
> -		if (skb_is_nonlinear(skb) && skb_headlen(skb) < PKT_PROT_LEN) {
> -			int target = min_t(int, skb->len, PKT_PROT_LEN);
> -			__pskb_pull_tail(skb, target - skb_headlen(skb));
> -		}
> -
>  		skb->dev      = queue->vif->dev;
>  		skb->protocol = eth_type_trans(skb, skb->dev);
>  		skb_reset_network_header(skb);



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 17:56:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 17:56:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlLrV-0003vJ-GN; Mon, 03 Nov 2014 17:56:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlLrT-0003vE-BA
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 17:56:15 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	A8/1D-11608-EB1C7545; Mon, 03 Nov 2014 17:56:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415037371!11324234!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4715 invoked from network); 3 Nov 2014 17:56:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 17:56:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="187603595"
Message-ID: <1415036346.1411.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 3 Nov 2014 17:39:06 +0000
In-Reply-To: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: netdev@vger.kernel.org, Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> 
> Unconditionally pulling 128 bytes into the linear buffer is not
> required. Netback has already grant copied up-to 128 bytes from the
> first slot of a packet into the linear buffer. The first slot normally
> contain all the IPv4/IPv6 and TCP/UDP headers.

What about when it doesn't? It sounds as if we now won't pull up, which
would be bad.

To avoid the pull up the code would need to grant copy up-to 128 bytes
from as many slots as needed, not only the first.

Also, if the grant copy has already placed 128 bytes in the linear area,
why is the pull up touching anything in the first place? Shouldn't it be
a nop in that case?

> The unconditional pull would often copy frag data unnecessarily.  This
> is a performance problem when running on a version of Xen where grant
> unmap avoids TLB flushes for pages which are not accessed.  TLB
> flushes can now be avoided for > 99% of unmaps (it was 0% before).
> 
> Grant unmap TLB flush avoidance will be available in a future version
> of Xen (probably 4.6).
> 
> Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  drivers/net/xen-netback/netback.c |   26 ++++++++++++--------------
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 730252c..14e18bb 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -82,6 +82,16 @@ MODULE_PARM_DESC(max_queues,
>  static unsigned int fatal_skb_slots = FATAL_SKB_SLOTS_DEFAULT;
>  module_param(fatal_skb_slots, uint, 0444);
>  
> +/* The amount to copy out of the first guest Tx slot into the skb's
> + * linear area.  If the first slot has more data, it will be mapped
> + * and put into the first frag.
> + *
> + * This is sized to avoid pulling headers from the frags for most
> + * TCP/IP packets.
> + */
> +#define XEN_NETBACK_TX_COPY_LEN 128

Was it strictly necessary to both move and rename this? I can see why
the comment needed to change.

>  static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx,
>  			       u8 status);
>  
> @@ -125,13 +135,6 @@ static inline struct xenvif_queue *ubuf_to_queue(const struct ubuf_info *ubuf)
>  			    pending_tx_info[0]);
>  }
>  
> -/* This is a miniumum size for the linear area to avoid lots of
> - * calls to __pskb_pull_tail() as we set up checksum offsets. The
> - * value 128 was chosen as it covers all IPv4 and most likely
> - * IPv6 headers.
> - */
> -#define PKT_PROT_LEN 128
> -
>  static u16 frag_get_pending_idx(skb_frag_t *frag)
>  {
>  	return (u16)frag->page_offset;
> @@ -1446,9 +1449,9 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
>  		index = pending_index(queue->pending_cons);
>  		pending_idx = queue->pending_ring[index];
>  
> -		data_len = (txreq.size > PKT_PROT_LEN &&
> +		data_len = (txreq.size > XEN_NETBACK_TX_COPY_LEN &&
>  			    ret < XEN_NETBK_LEGACY_SLOTS_MAX) ?
> -			PKT_PROT_LEN : txreq.size;
> +			XEN_NETBACK_TX_COPY_LEN : txreq.size;
>  
>  		skb = xenvif_alloc_skb(data_len);
>  		if (unlikely(skb == NULL)) {
> @@ -1653,11 +1656,6 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
>  			}
>  		}
>  
> -		if (skb_is_nonlinear(skb) && skb_headlen(skb) < PKT_PROT_LEN) {
> -			int target = min_t(int, skb->len, PKT_PROT_LEN);
> -			__pskb_pull_tail(skb, target - skb_headlen(skb));
> -		}
> -
>  		skb->dev      = queue->vif->dev;
>  		skb->protocol = eth_type_trans(skb, skb->dev);
>  		skb_reset_network_header(skb);



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 18:03:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 18:03:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlLyg-0004DX-IT; Mon, 03 Nov 2014 18:03:42 +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 1XlLyf-0004DM-Iq
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 18:03:41 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	FF/89-25714-C73C7545; Mon, 03 Nov 2014 18:03:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415037818!10945874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17626 invoked from network); 3 Nov 2014 18:03:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 18:03:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188998157"
Message-ID: <5457C35F.50504@citrix.com>
Date: Mon, 3 Nov 2014 18:03:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Thanos Makatos <thanos.makatos@citrix.com>,
	<xen-devel@lists.xenproject.org>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
In-Reply-To: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
X-DLP: MIA1
Cc: boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/10/14 16:15, Thanos Makatos wrote:
> This patch introduces the interface to allow user-space applications
> execute grant-copy operations. This is done by sending an ioctl to the
> grant device. The number of grant-copy segments is currently limited to
> 16 in order to simplify the implementation, however the ABI allows an
> arbitrary number of operations.

Sorry for not responding earlier.  If I haven't responded to a patch in
a week, a reminder ping is appreciated.

The arbitrary limitations in number of ops and page alignment should be
removed.  I think both can be removed relatively easily by consuming
page aligned chunks of segments and doign the hypercall when a batch of
ops is filled.

> +struct gntdev_grant_copy_segment {
> +	/*
> +	 * source address and length
> +	 */
> +	struct iovec iov;
> +
> +	/* the granted page */
> +	uint32_t ref;
> +
> +	/* offset in the granted page */
> +	uint16_t offset;
> +
> +	/* grant copy result (GNTST_XXX) */
> +	int16_t status;
> +};
> +
> +#define IOCTL_GNTDEV_GRANT_COPY \
> +_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
> +struct ioctl_gntdev_grant_copy {
> +	/*
> +	 * copy direction: 0 to copy to guest, 1 to copy from guest
> +	 */
> +	int dir;

I think this dir should be per-segment and use the GNTCPY_source_gref
and GNTCOPY_dest_gref flags, since per-op direction is what the
hypercall provides.

> +
> +	/* domain ID */
> +	uint32_t domid;
> +
> +	unsigned int count;
> +
> +	struct gntdev_grant_copy_segment __user *segments;
> +};

David

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 18:03:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 18:03:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlLyg-0004DX-IT; Mon, 03 Nov 2014 18:03:42 +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 1XlLyf-0004DM-Iq
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 18:03:41 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	FF/89-25714-C73C7545; Mon, 03 Nov 2014 18:03:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415037818!10945874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17626 invoked from network); 3 Nov 2014 18:03:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 18:03:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="188998157"
Message-ID: <5457C35F.50504@citrix.com>
Date: Mon, 3 Nov 2014 18:03:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Thanos Makatos <thanos.makatos@citrix.com>,
	<xen-devel@lists.xenproject.org>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
In-Reply-To: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
X-DLP: MIA1
Cc: boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/10/14 16:15, Thanos Makatos wrote:
> This patch introduces the interface to allow user-space applications
> execute grant-copy operations. This is done by sending an ioctl to the
> grant device. The number of grant-copy segments is currently limited to
> 16 in order to simplify the implementation, however the ABI allows an
> arbitrary number of operations.

Sorry for not responding earlier.  If I haven't responded to a patch in
a week, a reminder ping is appreciated.

The arbitrary limitations in number of ops and page alignment should be
removed.  I think both can be removed relatively easily by consuming
page aligned chunks of segments and doign the hypercall when a batch of
ops is filled.

> +struct gntdev_grant_copy_segment {
> +	/*
> +	 * source address and length
> +	 */
> +	struct iovec iov;
> +
> +	/* the granted page */
> +	uint32_t ref;
> +
> +	/* offset in the granted page */
> +	uint16_t offset;
> +
> +	/* grant copy result (GNTST_XXX) */
> +	int16_t status;
> +};
> +
> +#define IOCTL_GNTDEV_GRANT_COPY \
> +_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
> +struct ioctl_gntdev_grant_copy {
> +	/*
> +	 * copy direction: 0 to copy to guest, 1 to copy from guest
> +	 */
> +	int dir;

I think this dir should be per-segment and use the GNTCPY_source_gref
and GNTCOPY_dest_gref flags, since per-op direction is what the
hypercall provides.

> +
> +	/* domain ID */
> +	uint32_t domid;
> +
> +	unsigned int count;
> +
> +	struct gntdev_grant_copy_segment __user *segments;
> +};

David

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 18:06:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 18: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.xen.org>)
	id 1XlM1N-0004Q4-73; Mon, 03 Nov 2014 18:06:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlM1L-0004Pw-EZ
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 18:06:27 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	1C/F7-02984-224C7545; Mon, 03 Nov 2014 18:06:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415037984!12297022!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 571 invoked from network); 3 Nov 2014 18:06:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 18:06:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3I6Gml029790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 18:06:17 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3I6FuX006385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 18:06:16 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3I6E94006370; Mon, 3 Nov 2014 18:06:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 10:06:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8CEAE10FFEA; Mon,  3 Nov 2014 13:06:13 -0500 (EST)
Date: Mon, 3 Nov 2014 13:06:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, pranavkumar@linaro.org
Message-ID: <20141103180613.GA5379@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: ian.campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [ARM APM Mustang-X. Xen 4.5-rc1 and staging] Booting
 issues, last meesage: (XEN) P2M: 3 levels with order-1 root, VTCR 0x80033558
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey,

I've been following: http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/APMXGeneMustang#Preparing_all_the_Images
with a couple of changes:

1) The latest Linux tree in https://github.com/AppliedMicro/ENGLinuxLatest
looks to have already Xen support in the default config. So used that instead
of 3.15.


2). The 'run xen_run' does not execute properly, but if I run each
 operation by itself it does get me to boot Xen.


However I am not sure if the reason I am getting stuck is because I should be
using 3.15-rc8 instead of the latest? Or perhaps there is another issue?

And here is the serial console


Mustang# run xen_dtb xen_dom0 xen_load;
Using eth0 device
TFTP from server 192.168.105.1; our IP address is 192.168.105.51
Filename 'lab/tst051/apm-mustang-xen.dtb's: 0x4003000000
Loading: *##
	 2.1 MiB/s
done
Bytes transferred = 15716 (3d64 hex)
Using eth0 device
TFTP from server 192.168.105.1; our IP address i#################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ####################
	 4.2 MiB/s
done
Bytes transferred = 7925472 (78eee0 hex)
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt ND
Mustang# run xen_dtb
Using eth0 device
TFTP from server 192.168.105.1; our IP address is 192.168.105.51
Filename 'lab/tst051/apm-mustang-xen.dtb'.
Load address: 0x4003000000
Loading: *##
	 2.1 MiB/s
done
Bytes transferred = 15716 (3d64 hex)
Mustang# run xen_dom0
Using eth0 device
TFTP from server 192.168.105.1; our IP address is 192.168.105.51
Filename 'lab/tst051/Image'.
Load address: 0x400200000
Loading: *#################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ####################
	 4.1 MiB/s
done
Bytes transferred = 7925472 (78eee0 hex)
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
Mustang# run xen_load
Using eth0 device
TFTP from server 192.168.105.1; our IP address is 192.168.105.51
Filename 'lab/tst051/uXen'.
Load address: 0x4000080000
Loading: *####################################################
	 4.1 MiB/s
done
Bytes transferred = 755600 (b8790 hex)
Mustang# fdt print /chosen
chosen {
};
Mustang# run xen_boot
## Booting kernel from Legacy Image at 4000080000 ...
   Image Name:   Xen
   Image Type:   ARM Linux Kernel Image (uncompree:    755536 Bytes = 737.8 KiB
   Load Address: 00200000
   Entry Point:  00200000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4003000000
   Booting using the fdt blob at 0x0000004003000000
   Loading Kernel Image ..OK
OK
   reserving fdt memory region: addr=4003000000 size=4000
   Loading Device Tree to 0000004000ff9000, end 0000004000fff
Starting kernel ...

L3C: 8MB
- UART enabled -
- CPU 00000000 booting -
- Current EL 00000008 -
- Xen starting at EL2 -RAM: 0000004000000000 - 00000043ffffffff
(XEN) 
(XEN) MODULE[0]: 0000004000ff9000 - 0000004001000000 Device Tree  
(XEN)  RESVD[0]: 0000004003000000 - 0000004003004000
(XEN)  RESVD[1]: 0000004000000000 - 0000004000010000
(XEN) 
(XEN) Command line: <NULL>
(XEN) Placing Xen at 0x00000043ffe00000-0x0000004400000000
(XEN) Update BOOTMOD_XEN from 0000004000200000-000000400030ad81 => 00000043ffe00000-00000043fff0ad81
(XEN) Domain heap initialised
(XEN) No console
(XEN) Bad console= option 'dtuart'
 Xen 4.5.0-rc
(XEN) Xen version 4.5.0-rc ((XEN) 64-bit Execution:
(XEN)   Processor Features: 0000000000000122 0000000000000000
(XEN)     Exception Levels: EL3:No EL2:64 EL1:64+32 EL0:64+32
(XEN)     Extensions: FloatingPoint AdvancedSIMD
(XEN)   Debug Features: 0000000010303106 0000000000000000
(XEN)   Auxiliary Features: 0000000000000000 0000000000000000
(XEN)   Memory Model Features: 0000000000000123 0000000000000000
(XEN)   ISA Features:  0000000000000000 0000000000000000
(XEN) 32-bit Execution:
(XEN)   Processor Features: 00000131:00111001
(XEN)     Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN)     Extensions: GenericTimer
(XEN)   Debug Features: 03010006
(XEN)   Auxiliary Features: 00000000
(XEN)   Memory Model Features: 00100105 40000000 01260000 02102111
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00010142 00000001
(XEN) Platform: APM X-GENE STORM
(XEN) Generic Timer IRQ: phys=29 hyp=31 virt=30
(XEN) Using generic timer at 50000 KHz
(XEN) GICv2 initialization:
(XEN)         gic_dist_addr=0000000078090000
(XEN)         gic_cpu_addr=00000000780a0000
(XEN)         gic_hyp_addr=00000000780c0000
(XEN)         gic_vcpu_addr=00000000780e0000
(XEN)         gic_maintenance_irq=25
(XEN) GICv2: 256 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) I/O virtualisation disabled
(XEN) Allocated console ring of 64 KiB.
(XEN) Bringing up CPU1
- CPU 00000001 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 00000100 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 00000101 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 3 booted.
(XEN) Bringing up CPU4
- CPU 00000200 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 4 booted.
(XEN) Bringing up CPU5
- CPU 00000201 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 5 booted.
(XEN) Bringing up CPU6
- CPU 00000300 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 6 booted.
(XEN) Bringing up CPU7
- CPU 00000301 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 7 booted.
(XEN) Brought up 8 CPUs
(XEN) P2M: 40-bit IPA with 42-bit PA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80033558

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 18:06:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 18: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.xen.org>)
	id 1XlM1N-0004Q4-73; Mon, 03 Nov 2014 18:06:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlM1L-0004Pw-EZ
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 18:06:27 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	1C/F7-02984-224C7545; Mon, 03 Nov 2014 18:06:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415037984!12297022!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 571 invoked from network); 3 Nov 2014 18:06:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 18:06:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3I6Gml029790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 18:06:17 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3I6FuX006385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 18:06:16 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3I6E94006370; Mon, 3 Nov 2014 18:06:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 10:06:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8CEAE10FFEA; Mon,  3 Nov 2014 13:06:13 -0500 (EST)
Date: Mon, 3 Nov 2014 13:06:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, pranavkumar@linaro.org
Message-ID: <20141103180613.GA5379@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: ian.campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [ARM APM Mustang-X. Xen 4.5-rc1 and staging] Booting
 issues, last meesage: (XEN) P2M: 3 levels with order-1 root, VTCR 0x80033558
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey,

I've been following: http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/APMXGeneMustang#Preparing_all_the_Images
with a couple of changes:

1) The latest Linux tree in https://github.com/AppliedMicro/ENGLinuxLatest
looks to have already Xen support in the default config. So used that instead
of 3.15.


2). The 'run xen_run' does not execute properly, but if I run each
 operation by itself it does get me to boot Xen.


However I am not sure if the reason I am getting stuck is because I should be
using 3.15-rc8 instead of the latest? Or perhaps there is another issue?

And here is the serial console


Mustang# run xen_dtb xen_dom0 xen_load;
Using eth0 device
TFTP from server 192.168.105.1; our IP address is 192.168.105.51
Filename 'lab/tst051/apm-mustang-xen.dtb's: 0x4003000000
Loading: *##
	 2.1 MiB/s
done
Bytes transferred = 15716 (3d64 hex)
Using eth0 device
TFTP from server 192.168.105.1; our IP address i#################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ####################
	 4.2 MiB/s
done
Bytes transferred = 7925472 (78eee0 hex)
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt ND
Mustang# run xen_dtb
Using eth0 device
TFTP from server 192.168.105.1; our IP address is 192.168.105.51
Filename 'lab/tst051/apm-mustang-xen.dtb'.
Load address: 0x4003000000
Loading: *##
	 2.1 MiB/s
done
Bytes transferred = 15716 (3d64 hex)
Mustang# run xen_dom0
Using eth0 device
TFTP from server 192.168.105.1; our IP address is 192.168.105.51
Filename 'lab/tst051/Image'.
Load address: 0x400200000
Loading: *#################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ####################
	 4.1 MiB/s
done
Bytes transferred = 7925472 (78eee0 hex)
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
Mustang# run xen_load
Using eth0 device
TFTP from server 192.168.105.1; our IP address is 192.168.105.51
Filename 'lab/tst051/uXen'.
Load address: 0x4000080000
Loading: *####################################################
	 4.1 MiB/s
done
Bytes transferred = 755600 (b8790 hex)
Mustang# fdt print /chosen
chosen {
};
Mustang# run xen_boot
## Booting kernel from Legacy Image at 4000080000 ...
   Image Name:   Xen
   Image Type:   ARM Linux Kernel Image (uncompree:    755536 Bytes = 737.8 KiB
   Load Address: 00200000
   Entry Point:  00200000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4003000000
   Booting using the fdt blob at 0x0000004003000000
   Loading Kernel Image ..OK
OK
   reserving fdt memory region: addr=4003000000 size=4000
   Loading Device Tree to 0000004000ff9000, end 0000004000fff
Starting kernel ...

L3C: 8MB
- UART enabled -
- CPU 00000000 booting -
- Current EL 00000008 -
- Xen starting at EL2 -RAM: 0000004000000000 - 00000043ffffffff
(XEN) 
(XEN) MODULE[0]: 0000004000ff9000 - 0000004001000000 Device Tree  
(XEN)  RESVD[0]: 0000004003000000 - 0000004003004000
(XEN)  RESVD[1]: 0000004000000000 - 0000004000010000
(XEN) 
(XEN) Command line: <NULL>
(XEN) Placing Xen at 0x00000043ffe00000-0x0000004400000000
(XEN) Update BOOTMOD_XEN from 0000004000200000-000000400030ad81 => 00000043ffe00000-00000043fff0ad81
(XEN) Domain heap initialised
(XEN) No console
(XEN) Bad console= option 'dtuart'
 Xen 4.5.0-rc
(XEN) Xen version 4.5.0-rc ((XEN) 64-bit Execution:
(XEN)   Processor Features: 0000000000000122 0000000000000000
(XEN)     Exception Levels: EL3:No EL2:64 EL1:64+32 EL0:64+32
(XEN)     Extensions: FloatingPoint AdvancedSIMD
(XEN)   Debug Features: 0000000010303106 0000000000000000
(XEN)   Auxiliary Features: 0000000000000000 0000000000000000
(XEN)   Memory Model Features: 0000000000000123 0000000000000000
(XEN)   ISA Features:  0000000000000000 0000000000000000
(XEN) 32-bit Execution:
(XEN)   Processor Features: 00000131:00111001
(XEN)     Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN)     Extensions: GenericTimer
(XEN)   Debug Features: 03010006
(XEN)   Auxiliary Features: 00000000
(XEN)   Memory Model Features: 00100105 40000000 01260000 02102111
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00010142 00000001
(XEN) Platform: APM X-GENE STORM
(XEN) Generic Timer IRQ: phys=29 hyp=31 virt=30
(XEN) Using generic timer at 50000 KHz
(XEN) GICv2 initialization:
(XEN)         gic_dist_addr=0000000078090000
(XEN)         gic_cpu_addr=00000000780a0000
(XEN)         gic_hyp_addr=00000000780c0000
(XEN)         gic_vcpu_addr=00000000780e0000
(XEN)         gic_maintenance_irq=25
(XEN) GICv2: 256 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) I/O virtualisation disabled
(XEN) Allocated console ring of 64 KiB.
(XEN) Bringing up CPU1
- CPU 00000001 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 00000100 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 00000101 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 3 booted.
(XEN) Bringing up CPU4
- CPU 00000200 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 4 booted.
(XEN) Bringing up CPU5
- CPU 00000201 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 5 booted.
(XEN) Bringing up CPU6
- CPU 00000300 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 6 booted.
(XEN) Bringing up CPU7
- CPU 00000301 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 7 booted.
(XEN) Brought up 8 CPUs
(XEN) P2M: 40-bit IPA with 42-bit PA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80033558

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 18:06:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 18: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 1XlM1i-0004T2-TI; Mon, 03 Nov 2014 18:06:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlM1h-0004Sn-GV
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 18:06:49 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	F0/75-27623-834C7545; Mon, 03 Nov 2014 18:06:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415038006!11374618!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10870 invoked from network); 3 Nov 2014 18:06:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 18:06:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="187612598"
Message-ID: <1415037337.1411.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 3 Nov 2014 17:55:37 +0000
In-Reply-To: <5457BF80.2000205@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
	<1415036346.1411.3.camel@citrix.com> <5457BF80.2000205@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: netdev@vger.kernel.org, Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 17:46 +0000, David Vrabel wrote:
> On 03/11/14 17:39, Ian Campbell wrote:
> > On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
> >> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> >>
> >> Unconditionally pulling 128 bytes into the linear buffer is not
> >> required. Netback has already grant copied up-to 128 bytes from the
> >> first slot of a packet into the linear buffer. The first slot normally
> >> contain all the IPv4/IPv6 and TCP/UDP headers.
> > 
> > What about when it doesn't? It sounds as if we now won't pull up, which
> > would be bad.
> 
> The network stack will always pull any headers it needs to inspect (the
> frag may be a userspace page which has the same security issues as a
> frag with a foreign page).

I don't believe it will, unless something changed since I last looked.
The kernel assumes that it has been sensible enough to put the headers
in the linear area, since it is the one which generates them in most
cases. In other cases its up to the relevant driver to make sure this is
true.

> e.g., see skb_checksum_setup() called slightly later on in netback.

This however is what will make things safe for us (note that this is
only used by xen-net* in practice), it is this which should be mentioned
in the commit message I think.

> > To avoid the pull up the code would need to grant copy up-to 128 bytes
> > from as many slots as needed, not only the first.
> > 
> > Also, if the grant copy has already placed 128 bytes in the linear area,
> > why is the pull up touching anything in the first place? Shouldn't it be
> > a nop in that case?
> 
> The grant copy only copies from the first frag which may be less than
> 128 bytes in length.
> 
> David



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 18:06:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 18: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 1XlM1i-0004T2-TI; Mon, 03 Nov 2014 18:06:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlM1h-0004Sn-GV
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 18:06:49 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	F0/75-27623-834C7545; Mon, 03 Nov 2014 18:06:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415038006!11374618!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10870 invoked from network); 3 Nov 2014 18:06:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 18:06:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="187612598"
Message-ID: <1415037337.1411.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 3 Nov 2014 17:55:37 +0000
In-Reply-To: <5457BF80.2000205@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
	<1415036346.1411.3.camel@citrix.com> <5457BF80.2000205@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: netdev@vger.kernel.org, Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 17:46 +0000, David Vrabel wrote:
> On 03/11/14 17:39, Ian Campbell wrote:
> > On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
> >> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> >>
> >> Unconditionally pulling 128 bytes into the linear buffer is not
> >> required. Netback has already grant copied up-to 128 bytes from the
> >> first slot of a packet into the linear buffer. The first slot normally
> >> contain all the IPv4/IPv6 and TCP/UDP headers.
> > 
> > What about when it doesn't? It sounds as if we now won't pull up, which
> > would be bad.
> 
> The network stack will always pull any headers it needs to inspect (the
> frag may be a userspace page which has the same security issues as a
> frag with a foreign page).

I don't believe it will, unless something changed since I last looked.
The kernel assumes that it has been sensible enough to put the headers
in the linear area, since it is the one which generates them in most
cases. In other cases its up to the relevant driver to make sure this is
true.

> e.g., see skb_checksum_setup() called slightly later on in netback.

This however is what will make things safe for us (note that this is
only used by xen-net* in practice), it is this which should be mentioned
in the commit message I think.

> > To avoid the pull up the code would need to grant copy up-to 128 bytes
> > from as many slots as needed, not only the first.
> > 
> > Also, if the grant copy has already placed 128 bytes in the linear area,
> > why is the pull up touching anything in the first place? Shouldn't it be
> > a nop in that case?
> 
> The grant copy only copies from the first frag which may be less than
> 128 bytes in length.
> 
> David



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

From xen-devel-bounces@lists.xen.org Mon Nov 03 18:23:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 18: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 1XlMHV-000529-Nf; Mon, 03 Nov 2014 18:23:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XlMHT-000521-RM
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 18:23:07 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	EC/8B-28296-B08C7545; Mon, 03 Nov 2014 18:23:07 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415038986!11236570!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13095 invoked from network); 3 Nov 2014 18:23:06 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 18:23:06 -0000
Received: by mail-wg0-f41.google.com with SMTP id k14so13214101wgh.0
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 10:23:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=H62QqhhzmBIuCTvrgQWwb5UnBlWrvSxBvHAPJ4iVo6M=;
	b=Tkn0E9gWCiW1hgn8xydff+okwUpkA2vRvXfFmWURzVHn0s7TJdVkJKcgCGkz4L5sie
	rQgXFipnWiq1niIQshj6uiClTnjbmLUOm5hn2mHOxrd1Y2nJzXyuaTsnatx6V267+b6O
	FEhsj3RPn5gah6uJfZ2UNTaJFCoTF/jst4A0Po+3VdbM7iQLAy38KRQ4hGeIo3J11LvF
	dqGObCWRFIpQCa9oKrmPV05R4lHpFg1hcFqwK9DOC1aO64ac3mLgRhOxKOEnVaFtiKYR
	wDJm36ljDoR4oQgHJoXdzgh8iBYctFsyNWj39az0eM0ty46T1SmAcUXxqgDfhAG/NHcU
	UJ/A==
X-Gm-Message-State: ALoCoQnwE/WRgEIM3E0hBneAGKM8dxFkKlPP+BFLZm4KYAygRnbLuqskJtqkBgc0iwXrnhEWg05B
X-Received: by 10.180.19.234 with SMTP id i10mr18638869wie.28.1415038986033;
	Mon, 03 Nov 2014 10:23:06 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id gy4sm9586586wib.11.2014.11.03.10.23.04
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 10:23:05 -0800 (PST)
Message-ID: <5457C807.5080509@linaro.org>
Date: Mon, 03 Nov 2014 18:23:03 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>	<1415036346.1411.3.camel@citrix.com>
	<5457BF80.2000205@citrix.com>
In-Reply-To: <5457BF80.2000205@citrix.com>
Cc: netdev@vger.kernel.org, Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 03/11/14 17:46, David Vrabel wrote:
> On 03/11/14 17:39, Ian Campbell wrote:
>> On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
>>> From: Malcolm Crossley <malcolm.crossley@citrix.com>
>>>
>>> Unconditionally pulling 128 bytes into the linear buffer is not
>>> required. Netback has already grant copied up-to 128 bytes from the
>>> first slot of a packet into the linear buffer. The first slot normally
>>> contain all the IPv4/IPv6 and TCP/UDP headers.
>>
>> What about when it doesn't? It sounds as if we now won't pull up, which
>> would be bad.
>
> The network stack will always pull any headers it needs to inspect (the
> frag may be a userspace page which has the same security issues as a
> frag with a foreign page).
I wouldn't bet my life on this, but indeed it should always happen.

>
> e.g., see skb_checksum_setup() called slightly later on in netback.
Fortunately the call to checksum_setup a bit later makes sure that at 
least the TCP/UDP headers are in the linear area, which is quite the 
same as blindly pulling 128 bytes. With any other protocol we rely on 
the network stack that it will enforce packet header in the linear buffer.

Regards,

Zoli

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 18:23:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 18: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 1XlMHV-000529-Nf; Mon, 03 Nov 2014 18:23:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XlMHT-000521-RM
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 18:23:07 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	EC/8B-28296-B08C7545; Mon, 03 Nov 2014 18:23:07 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415038986!11236570!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13095 invoked from network); 3 Nov 2014 18:23:06 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Nov 2014 18:23:06 -0000
Received: by mail-wg0-f41.google.com with SMTP id k14so13214101wgh.0
	for <xen-devel@lists.xenproject.org>;
	Mon, 03 Nov 2014 10:23:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=H62QqhhzmBIuCTvrgQWwb5UnBlWrvSxBvHAPJ4iVo6M=;
	b=Tkn0E9gWCiW1hgn8xydff+okwUpkA2vRvXfFmWURzVHn0s7TJdVkJKcgCGkz4L5sie
	rQgXFipnWiq1niIQshj6uiClTnjbmLUOm5hn2mHOxrd1Y2nJzXyuaTsnatx6V267+b6O
	FEhsj3RPn5gah6uJfZ2UNTaJFCoTF/jst4A0Po+3VdbM7iQLAy38KRQ4hGeIo3J11LvF
	dqGObCWRFIpQCa9oKrmPV05R4lHpFg1hcFqwK9DOC1aO64ac3mLgRhOxKOEnVaFtiKYR
	wDJm36ljDoR4oQgHJoXdzgh8iBYctFsyNWj39az0eM0ty46T1SmAcUXxqgDfhAG/NHcU
	UJ/A==
X-Gm-Message-State: ALoCoQnwE/WRgEIM3E0hBneAGKM8dxFkKlPP+BFLZm4KYAygRnbLuqskJtqkBgc0iwXrnhEWg05B
X-Received: by 10.180.19.234 with SMTP id i10mr18638869wie.28.1415038986033;
	Mon, 03 Nov 2014 10:23:06 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id gy4sm9586586wib.11.2014.11.03.10.23.04
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 10:23:05 -0800 (PST)
Message-ID: <5457C807.5080509@linaro.org>
Date: Mon, 03 Nov 2014 18:23:03 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>	<1415036346.1411.3.camel@citrix.com>
	<5457BF80.2000205@citrix.com>
In-Reply-To: <5457BF80.2000205@citrix.com>
Cc: netdev@vger.kernel.org, Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 03/11/14 17:46, David Vrabel wrote:
> On 03/11/14 17:39, Ian Campbell wrote:
>> On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
>>> From: Malcolm Crossley <malcolm.crossley@citrix.com>
>>>
>>> Unconditionally pulling 128 bytes into the linear buffer is not
>>> required. Netback has already grant copied up-to 128 bytes from the
>>> first slot of a packet into the linear buffer. The first slot normally
>>> contain all the IPv4/IPv6 and TCP/UDP headers.
>>
>> What about when it doesn't? It sounds as if we now won't pull up, which
>> would be bad.
>
> The network stack will always pull any headers it needs to inspect (the
> frag may be a userspace page which has the same security issues as a
> frag with a foreign page).
I wouldn't bet my life on this, but indeed it should always happen.

>
> e.g., see skb_checksum_setup() called slightly later on in netback.
Fortunately the call to checksum_setup a bit later makes sure that at 
least the TCP/UDP headers are in the linear area, which is quite the 
same as blindly pulling 128 bytes. With any other protocol we rely on 
the network stack that it will enforce packet header in the linear buffer.

Regards,

Zoli

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 19:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 19: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 1XlN5f-00067F-PG; Mon, 03 Nov 2014 19:14:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlN5e-000671-8r
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 19:14:58 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	F8/51-24859-134D7545; Mon, 03 Nov 2014 19:14:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415042095!11384734!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16938 invoked from network); 3 Nov 2014 19:14:56 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 19:14:56 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3JEhSP021966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 19:14:45 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3JEfvl024095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 19:14:42 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3JEeXC015390; Mon, 3 Nov 2014 19:14:41 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 11:14:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5EF791100EA; Mon,  3 Nov 2014 14:14:39 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Mon,  3 Nov 2014 14:14:37 -0500
Message-Id: <1415042078-8337-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
References: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [for-xen-4.5 v9 1/2] dpci: Move from an hvm_irq_dpci
	(and struct domain) to an hvm_dirq_dpci model.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 an interrupt for an PCI (or PCIe) passthrough device
is to be sent to a guest, we find the appropiate
'hvm_dirq_dpci' structure for the interrupt (PIRQ), set
a bit (masked), and schedule an tasklet.

Then the 'hvm_dirq_assist' tasklet gets called with the 'struct
domain' from where it iterates over the the radix-tree of
'hvm_dirq_dpci' (from zero to the number of PIRQs allocated)
which are masked to the guest and calls each 'hvm_pirq_assist'.
If the PIRQ has a bit set (masked) it figures out how to
inject the PIRQ to the guest.

This is inefficient and not fair as:
 - We iterate starting at PIRQ 0 and up every time. That means
   the PCIe devices that have lower PIRQs get to be called
   first.
 - If we have many PCIe devices passed in with many PIRQs and
   if most of the time only the highest numbered PIRQ get an
   interrupt (as the initial ones are for control) we end up
   iterating over many PIRQs.

But we could do beter - the 'hvm_dirq_dpci' has the field for
'struct domain', which we can use instead of having to pass in the
'struct domain'.

As such this patch moves the tasklet to the 'struct hvm_dirq_dpci'
and sets the 'dom' field to the domain. We also double-check
that the '->dom' is not reset before using it.

We have to be careful with this as that means we MUST have
'dom' set before pirq_guest_bind() is called. As such
we add the 'pirq_dpci->dom = d;' to cover for such
cases.

The mechanism to tear it down is more complex as there
are two ways it can be executed:

 a) pci_clean_dpci_irq. This gets called when the guest is
    being destroyed. We end up calling 'tasklet_kill'.

    The scenarios in which the 'struct pirq' (and subsequently
    the 'hvm_pirq_dpci') gets destroyed is when:

    - guest did not use the pirq at all after setup.
    - guest did use pirq, but decided to mask and left it in that
      state.
    - guest did use pirq, but crashed.

    In all of those scenarios we end up calling 'tasklet_kill'
    which will spin on the tasklet if it is running.

 b) pt_irq_destroy_bind (guest disables the MSI). We double-check
    that the softirq has run by piggy-backing on the existing
    'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
    We add the extra call to 'pt_pirq_softirq_active' in
    'pt_pirq_cleanup_check'.

    NOTE: Guests that use event channels unbind first the
    event channel from PIRQs, so the 'pt_pirq_cleanup_check'
    won't be called as event is set to zero. In that case
    we either clean it up via the a) mechanism. It is OK
    to re-use the tasklet when 'pt_irq_create_bind' is called
    afterwards.

    There is an extra scenario regardless of event being
    set or not: the guest did 'pt_irq_destroy_bind' while an
    interrupt was triggered and tasklet was scheduled (but had not
    been run). It is OK to still run the tasklet as
    hvm_dirq_assist won't do anything (as the flags are
    set to zero). As such we can exit out of hvm_dirq_assist
    without doing anything.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c  | 75 ++++++++++++++++++++++++++++++-------------
 xen/drivers/passthrough/pci.c |  4 +--
 xen/include/xen/hvm/irq.h     |  2 +-
 3 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 4cd32b5..dceb17e 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -27,7 +27,7 @@
 #include <xen/hvm/irq.h>
 #include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long _d);
+static void hvm_dirq_assist(unsigned long arg);
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -114,9 +114,6 @@ int pt_irq_create_bind(
             spin_unlock(&d->event_lock);
             return -ENOMEM;
         }
-        softirq_tasklet_init(
-            &hvm_irq_dpci->dirq_tasklet,
-            hvm_dirq_assist, (unsigned long)d);
         for ( i = 0; i < NR_HVM_IRQS; i++ )
             INIT_LIST_HEAD(&hvm_irq_dpci->girq[i]);
 
@@ -144,6 +141,18 @@ int pt_irq_create_bind(
                                HVM_IRQ_DPCI_GUEST_MSI;
             pirq_dpci->gmsi.gvec = pt_irq_bind->u.msi.gvec;
             pirq_dpci->gmsi.gflags = pt_irq_bind->u.msi.gflags;
+            /*
+             * 'pt_irq_create_bind' can be called after 'pt_irq_destroy_bind'.
+             * The 'pirq_cleanup_check' which would free the structure is only
+             * called if the event channel for the PIRQ is active. However
+             * OS-es that use event channels usually bind PIRQs to eventds
+             * and unbind them before calling 'pt_irq_destroy_bind' - with the
+             * result that we re-use the 'dpci' structure. This can be
+             * reproduced with unloading and loading the driver for a device.
+             *
+             * As such on every 'pt_irq_create_bind' call we MUST set it.
+             */
+            pirq_dpci->dom = d;
             /* bind after hvm_irq_dpci is setup to avoid race with irq handler*/
             rc = pirq_guest_bind(d->vcpu[0], info, 0);
             if ( rc == 0 && pt_irq_bind->u.msi.gtable )
@@ -156,6 +165,7 @@ int pt_irq_create_bind(
             {
                 pirq_dpci->gmsi.gflags = 0;
                 pirq_dpci->gmsi.gvec = 0;
+                pirq_dpci->dom = NULL;
                 pirq_dpci->flags = 0;
                 pirq_cleanup_check(info, d);
                 spin_unlock(&d->event_lock);
@@ -232,6 +242,7 @@ int pt_irq_create_bind(
         {
             unsigned int share;
 
+            /* MUST be set, as the pirq_dpci can be re-used. */
             pirq_dpci->dom = d;
             if ( pt_irq_bind->irq_type == PT_IRQ_TYPE_MSI_TRANSLATE )
             {
@@ -415,11 +426,18 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
+    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    return !dpci->flags;
+    if ( !dpci->flags )
+    {
+        tasklet_kill(&dpci->tasklet);
+        dpci->dom = NULL;
+        return 1;
+    }
+    return 0;
 }
 
 int pt_pirq_iterate(struct domain *d,
@@ -459,7 +477,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
         return 0;
 
     pirq_dpci->masked = 1;
-    tasklet_schedule(&dpci->dirq_tasklet);
+    tasklet_schedule(&pirq_dpci->tasklet);
     return 1;
 }
 
@@ -513,9 +531,27 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
-                            void *arg)
+static void hvm_dirq_assist(unsigned long arg)
 {
+    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
+    struct domain *d = pirq_dpci->dom;
+
+    /*
+     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
+     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
+     *
+     * And '->dom' gets cleared later in the destroy path. We exit and clear
+     * 'masked' - which is OK as later in this code we would
+     * do nothing except clear the ->masked field anyhow.
+     */
+    if ( !d )
+    {
+        pirq_dpci->masked = 0;
+        return;
+    }
+    ASSERT(d->arch.hvm_domain.irq.dpci);
+
+    spin_lock(&d->event_lock);
     if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
@@ -526,13 +562,17 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
             send_guest_pirq(d, pirq);
 
             if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
-                return 0;
+            {
+                spin_unlock(&d->event_lock);
+                return;
+            }
         }
 
         if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
         {
             vmsi_deliver_pirq(d, pirq_dpci);
-            return 0;
+            spin_unlock(&d->event_lock);
+            return;
         }
 
         list_for_each_entry ( digl, &pirq_dpci->digl_list, list )
@@ -545,7 +585,8 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
         {
             /* for translated MSI to INTx interrupt, eoi as early as possible */
             __msi_pirq_eoi(pirq_dpci);
-            return 0;
+            spin_unlock(&d->event_lock);
+            return;
         }
 
         /*
@@ -558,18 +599,6 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
         ASSERT(pt_irq_need_timer(pirq_dpci->flags));
         set_timer(&pirq_dpci->timer, NOW() + PT_IRQ_TIME_OUT);
     }
-
-    return 0;
-}
-
-static void hvm_dirq_assist(unsigned long _d)
-{
-    struct domain *d = (struct domain *)_d;
-
-    ASSERT(d->arch.hvm_domain.irq.dpci);
-
-    spin_lock(&d->event_lock);
-    pt_pirq_iterate(d, _hvm_dirq_assist, NULL);
     spin_unlock(&d->event_lock);
 }
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1eba833..81e8a3a 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,6 +767,8 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
+    tasklet_kill(&pirq_dpci->tasklet);
+
     return 0;
 }
 
@@ -784,8 +786,6 @@ static void pci_clean_dpci_irqs(struct domain *d)
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        tasklet_kill(&hvm_irq_dpci->dirq_tasklet);
-
         pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
 
         d->arch.hvm_domain.irq.dpci = NULL;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index c89f4b1..94a550a 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -88,7 +88,6 @@ struct hvm_irq_dpci {
     DECLARE_BITMAP(isairq_map, NR_ISAIRQS);
     /* Record of mapped Links */
     uint8_t link_cnt[NR_LINK];
-    struct tasklet dirq_tasklet;
 };
 
 /* Machine IRQ to guest device/intx mapping. */
@@ -100,6 +99,7 @@ struct hvm_pirq_dpci {
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
+    struct tasklet tasklet;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 19:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 19: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 1XlN5a-00066Z-Qa; Mon, 03 Nov 2014 19:14:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlN5Y-00066P-Hv
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 19:14:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	30/74-09936-B24D7545; Mon, 03 Nov 2014 19:14:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415042089!12425499!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18948 invoked from network); 3 Nov 2014 19:14:50 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 19:14:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3JEipK022156
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 19:14:45 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3JEgqp015482
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 3 Nov 2014 19:14:43 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA3IQVo6026725; Mon, 3 Nov 2014 18:26:31 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 11:14:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 565E61100E8; Mon,  3 Nov 2014 14:14:39 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Mon,  3 Nov 2014 14:14:36 -0500
Message-Id: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH v9 for-xen-4.5] Fix interrupt latency of HVM
	PCIpassthrough 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Changelog:
since v8 (http://lists.xen.org/archives/html/xen-devel/2014-10/msg02564.html)
 - Went back-n-forth on remote softirq, fixed styleguide violations.
 - Moved call to pt_pirq_softirq_reset in pt_irq_create_bind
 - Removed 'case default'
 - Streamlined 'pci_clean_dpci_irqs' return usage.

since v7 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg04385.html)
 - Put ref-counting back, added two bits to allow ref-counting from other places.
since v6 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg03208.html)
 - Squashed #1 + #2.
 - Added more comments, redid it based on Jan's feedback.
since v5 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg02868.html)
 - Redid the series based on Jan's feedback
since v4
(http://lists.xen.org/archives/html/xen-devel/2014-09/msg01676.html):
 - Ditch the domain centric mechansim.
 - Fix issues raised by Jan.


The patches are an performance bug-fixes for PCI passthrough for machines
with many sockets. On those machines we have observed awful latency issues
with interrupts and with high steal time on idle guests. The root cause
was that the tasklet lock which was shared across all sockets. Each interrupt
that was to be delivered to a guest took the tasket lock - and with many
guests and many PCI passthrough devices - the performance and latency were
atrocious. These two patches fix the outstanding issues.

 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 282 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  29 +++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 283 insertions(+), 42 deletions(-)

Konrad Rzeszutek Wilk (2):
      dpci: Move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model.
      dpci: Replace tasklet with an softirq (v12)


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 19:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 19: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 1XlN5b-00066g-63; Mon, 03 Nov 2014 19:14: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 1XlN5a-00066U-4E
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 19:14:54 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	A3/7B-22737-D24D7545; Mon, 03 Nov 2014 19:14:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415042090!10947576!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16213 invoked from network); 3 Nov 2014 19:14:52 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 19:14:52 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3JEhu1022147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 19:14:44 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3JEgIP028287
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 19:14:43 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3JEg0S015444; Mon, 3 Nov 2014 19:14:42 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 11:14:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6DD391100EC; Mon,  3 Nov 2014 14:14:39 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Mon,  3 Nov 2014 14:14:38 -0500
Message-Id: <1415042078-8337-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
References: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [for-xen-4.5 v9 2/2] dpci: Replace tasklet with an
	softirq (v12)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The existing tasklet mechanism has a single global
spinlock that is taken every-time the global list
is touched. And we use this lock quite a lot - when
we call do_tasklet_work which is called via an softirq
and from the idle loop. We take the lock on any
operation on the tasklet_list.

The problem we are facing is that there are quite a lot of
tasklets scheduled. The most common one that is invoked is
the one injecting the VIRQ_TIMER in the guest. Guests
are not insane and don't set the one-shot or periodic
clocks to be in sub 1ms intervals (causing said tasklet
to be scheduled for such small intervalls).

The problem appears when PCI passthrough devices are used
over many sockets and we have an mix of heavy-interrupt
guests and idle guests. The idle guests end up seeing
1/10 of its RUNNING timeslice eaten by the hypervisor
(and 40% steal time).

The mechanism by which we inject PCI interrupts is by
hvm_do_IRQ_dpci which schedules the hvm_dirq_assist
tasklet every time an interrupt is received.
The callchain is:

_asm_vmexit_handler
 -> vmx_vmexit_handler
    ->vmx_do_extint
        -> do_IRQ
            -> __do_IRQ_guest
                -> hvm_do_IRQ_dpci
                   tasklet_schedule(&dpci->dirq_tasklet);
                   [takes lock to put the tasklet on]

[later on the schedule_tail is invoked which is 'vmx_do_resume']

vmx_do_resume
 -> vmx_asm_do_vmentry
        -> call vmx_intr_assist
          -> vmx_process_softirqs
            -> do_softirq
              [executes the tasklet function, takes the
               lock again]

While on other CPUs they might be sitting in a idle loop
and invoked to deliver an VIRQ_TIMER, which also ends
up taking the lock twice: first to schedule the
v->arch.hvm_vcpu.assert_evtchn_irq_tasklet (accounted to
the guests' BLOCKED_state); then to execute it - which is
accounted for in the guest's RUNTIME_state.

The end result is that on a 8 socket machine with
PCI passthrough, where four sockets are busy with interrupts,
and the other sockets have idle guests - we end up with
the idle guests having around 40% steal time and 1/10
of its timeslice (3ms out of 30 ms) being tied up
taking the lock. The latency of the PCI interrupts delieved
to guest is also hindered.

With this patch the problem disappears completly.
That is removing the lock for the PCI passthrough use-case
(the 'hvm_dirq_assist' case) by not using tasklets at all.

The patch is simple - instead of scheduling an tasklet
we schedule our own softirq - HVM_DPCI_SOFTIRQ, which will
take care of running 'hvm_dirq_assist'. The information we need
on each CPU is which 'struct hvm_pirq_dpci' structure the
'hvm_dirq_assist' needs to run on. That is simple solved by
threading the 'struct hvm_pirq_dpci' through a linked list.
The rule of only running one 'hvm_dirq_assist' for only
one 'hvm_pirq_dpci' is also preserved by having
'schedule_dpci_for' ignore any subsequent calls for an domain
which has already been scheduled.

== Code details ==

Most of the code complexity comes from the '->dom' field
in the 'hvm_pirq_dpci' structure. We use it for ref-counting
and as such it MUST be valid as long as STATE_SCHED bit is
set. Whoever clears the STATE_SCHED bit does the ref-counting
and can also reset the '->dom' field.

To compound the complexity, there are multiple points where the
'hvm_pirq_dpci' structure is reset or re-used. Initially
(first time the domain uses the pirq), the 'hvm_pirq_dpci->dom'
field is set to NULL as it is allocated. On subsequent calls
in to 'pt_irq_create_bind' the ->dom is whatever it had last time.

As this is the initial call (which QEMU ends up calling when the
guest writes an vector value in the MSI field) we MUST set the
'->dom' to a the proper structure (otherwise we cannot do
proper ref-counting).

The mechanism to tear it down is more complex as there
are three ways it can be executed. To make it simpler
everything revolves around 'pt_pirq_softirq_active'. If it
returns -EAGAIN that means there is an outstanding softirq
that needs to finish running before we can continue tearing
down. With that in mind:

a) pci_clean_dpci_irq. This gets called when the guest is
   being destroyed. We end up calling 'pt_pirq_softirq_active'
   to see if it is OK to continue the destruction.

   The scenarios in which the 'struct pirq' (and subsequently
   the 'hvm_pirq_dpci') gets destroyed is when:

   - guest did not use the pirq at all after setup.
   - guest did use pirq, but decided to mask and left it in that
     state.
   - guest did use pirq, but crashed.

   In all of those scenarios we end up calling
   'pt_pirq_softirq_active' to check if the softirq is still
   active. Read below on the 'pt_pirq_softirq_active' loop.

b) pt_irq_destroy_bind (guest disables the MSI). We double-check
   that the softirq has run by piggy-backing on the existing
   'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
   We add the extra call to 'pt_pirq_softirq_active' in
   'pt_pirq_cleanup_check'.

   NOTE: Guests that use event channels unbind first the
   event channel from PIRQs, so the 'pt_pirq_cleanup_check'
   won't be called as 'event' is set to zero. In that case
   we either clean it up via the a) or c) mechanism.

   There is an extra scenario regardless of 'event' being
   set or not: the guest did 'pt_irq_destroy_bind' while an
   interrupt was triggered and softirq was scheduled (but had not
   been run). It is OK to still run the softirq as
   hvm_dirq_assist won't do anything (as the flags are
   set to zero). However we will try to deschedule the
   softirq if we can (by clearing the STATE_SCHED bit and us
   doing the ref-counting).

c) pt_irq_create_bind (not a typo). The scenarios are:

     - guest disables the MSI and then enables it
       (rmmod and modprobe in a loop). We call 'pt_pirq_reset'
       which checks to see if the softirq has been scheduled.
       Imagine the 'b)' with interrupts in flight and c) getting
       called in a loop.

We will spin up on 'pt_pirq_is_active' (at the start of the
'pt_irq_create_bind') with the event_lock spinlock dropped and
waiting (cpu_relax). We cannot call 'process_pending_softirqs' as it
might result in a dead-lock. hvm_dirq_assist will be executed
and then the softirq will clear 'state' which signals that that we
can re-use the 'hvm_pirq_dpci' structure. In case this softirq
is scheduled on a remote CPU the softirq will run on it as the
semantics behind an softirq is that it will execute within the
guest interruption.

     - we hit once the error paths in 'pt_irq_create_bind' while
       an interrupt was triggered and softirq was scheduled.

If the softirq is in STATE_RUN that means it is executing and we should
let it continue on. We can clear the '->dom' field as the softirq
has stashed it beforehand. If the softirq is STATE_SCHED and
we are successful in clearing it, we do the ref-counting and
clear the '->dom' field. Otherwise we let the softirq continue
on and the '->dom' field is left intact. The clearing of
the '->dom' is left to a), b) or again c) case.

Note that in both cases the 'flags' variable is cleared so
hvm_dirq_assist won't actually do anything.

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

---
v2: On top of ref-cnts also have wait loop for the outstanding
    'struct domain' that need to be processed.
v3: Add -ERETRY, fix up StyleGuide issues
v4: Clean it up mode, redo per_cpu, this_cpu logic
v5: Instead of threading struct domain, use hvm_pirq_dpci.
v6: Ditch the 'state' bit, expand description, simplify
    softirq and teardown sequence.
v7: Flesh out the comments. Drop the use of domain refcounts
v8: Add two bits (STATE_[SCHED|RUN]) to allow refcounts.
v9: Use cmpxchg, ASSSERT, fix up comments per Jan.
v10: Fix up issues spotted by Jan.
v11: IPI the remote CPU (once) if it it has the softirq scheduled.
v12: Remove the IPI for the remote CPU as the sofitrq mechanism does that.
---
 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 251 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  31 ++++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 254 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..73d01bb 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1965,7 +1965,9 @@ int domain_relinquish_resources(struct domain *d)
     switch ( d->arch.relmem )
     {
     case RELMEM_not_started:
-        pci_release_devices(d);
+        ret = pci_release_devices(d);
+        if ( ret )
+            return ret;
 
         /* Tear down paging-assistance stuff. */
         ret = paging_teardown(d);
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index dceb17e..8dcb254 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -20,14 +20,120 @@
 
 #include <xen/event.h>
 #include <xen/iommu.h>
+#include <xen/cpu.h>
 #include <xen/irq.h>
 #include <asm/hvm/irq.h>
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
-#include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long arg);
+static DEFINE_PER_CPU(struct list_head, dpci_list);
+
+/*
+ * These two bit states help to safely schedule, deschedule, and wait until
+ * the softirq has finished.
+ *
+ * The semantics behind these two bits is as follow:
+ *  - STATE_SCHED - whoever modifies it has to ref-count the domain (->dom).
+ *  - STATE_RUN - only softirq is allowed to set and clear it. If it has
+ *      been set hvm_dirq_assist will RUN with a saved value of the
+ *      'struct domain' copied from 'pirq_dpci->dom' before STATE_RUN was set.
+ *
+ * The usual states are: STATE_SCHED(set) -> STATE_RUN(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(unset).
+ *
+ * However the states can also diverge such as: STATE_SCHED(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(set) -> STATE_RUN(unset). That means
+ * the 'hvm_dirq_assist' never run and that the softirq did not do any
+ * ref-counting.
+ */
+
+enum {
+    STATE_SCHED,
+    STATE_RUN
+};
+
+/*
+ * Should only be called from hvm_do_IRQ_dpci. We use the
+ * 'state' as a gate to thwart multiple interrupts being scheduled.
+ * The 'state' is cleared by 'softirq_dpci' when it has
+ * completed executing 'hvm_dirq_assist' or by 'pt_pirq_softirq_reset'
+ * if we want to try to unschedule the softirq before it runs.
+ *
+ */
+static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
+{
+    unsigned long flags;
+
+    if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+        return;
+
+    get_knownalive_domain(pirq_dpci->dom);
+
+    local_irq_save(flags);
+    list_add_tail(&pirq_dpci->softirq_list, &this_cpu(dpci_list));
+    local_irq_restore(flags);
+
+    raise_softirq(HVM_DPCI_SOFTIRQ);
+}
+
+/*
+ * If we are racing with softirq_dpci (state is still set) we return
+ * true. Otherwise we return false.
+ *
+ *  If it is false, it is the callers responsibility to make sure
+ *  that the softirq (with the event_lock dropped) has ran. We need
+ *  to flush out the outstanding 'dpci_softirq' (no more of them
+ *  will be added for this pirq as the IRQ action handler has been
+ *  reset in pt_irq_destroy_bind).
+ */
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
+{
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+        return 1;
+
+    /*
+     * If in the future we would call 'raise_softirq_for' right away
+     * after 'pt_pirq_softirq_active' we MUST reset the list (otherwise it
+     * might have stale data).
+     */
+    return 0;
+}
+
+/*
+ * Reset the pirq_dpci->dom parameter to NULL.
+ *
+ * This function checks the different states to make sure it can do
+ * at the right time and if unschedules the softirq before it has
+ * run it also refcounts (which is what the softirq would have done).
+ */
+static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+{
+    struct domain *d = pirq_dpci->dom;
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    {
+    case (1 << STATE_SCHED):
+        /*
+         * We are going to try to de-schedule the softirq before it goes in
+         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
+         */
+        put_domain(d);
+        /* fallthrough. */
+    case (1 << STATE_RUN):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED):
+        /*
+         * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
+         * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
+         * in local variable before it sets STATE_RUN - and therefore will not
+         * dereference '->dom' which would crash.
+         */
+        pirq_dpci->dom = NULL;
+        break;
+    }
+}
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -40,7 +146,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->masked = 0;
+        pirq_dpci->state = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -101,6 +207,7 @@ int pt_irq_create_bind(
     if ( pirq < 0 || pirq >= d->nr_pirqs )
         return -EINVAL;
 
+ restart:
     spin_lock(&d->event_lock);
 
     hvm_irq_dpci = domain_get_irq_dpci(d);
@@ -127,7 +234,20 @@ int pt_irq_create_bind(
         return -ENOMEM;
     }
     pirq_dpci = pirq_dpci(info);
-
+    /*
+     * A crude 'while' loop with us dropping the spinlock and giving
+     * the softirq_dpci a chance to run.
+     * We MUST check for this condition as the softirq could be scheduled
+     * and hasn't run yet. Note that this code replaced tasklet_kill which
+     * would have spun forever and would do the same thing (wait to flush out
+     * outstanding hvm_dirq_assist calls.
+     */
+    if ( pt_pirq_softirq_active(pirq_dpci) )
+    {
+        spin_unlock(&d->event_lock);
+        cpu_relax();
+        goto restart;
+    }
     switch ( pt_irq_bind->irq_type )
     {
     case PT_IRQ_TYPE_MSI:
@@ -159,7 +279,16 @@ int pt_irq_create_bind(
             {
                 rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
                 if ( unlikely(rc) )
+                {
                     pirq_guest_unbind(d, info);
+                    /*
+                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
+                     * an interrupt can be scheduled. No more of them are going
+                     * to be scheduled but we must deal with the one that is in
+                     * the queue.
+                     */
+                    pt_pirq_softirq_reset(pirq_dpci);
+                }
             }
             if ( unlikely(rc) )
             {
@@ -269,6 +398,10 @@ int pt_irq_create_bind(
             {
                 if ( pt_irq_need_timer(pirq_dpci->flags) )
                     kill_timer(&pirq_dpci->timer);
+                /*
+                 * There is no path for __do_IRQ to schedule softirq as
+                 * IRQ_GUEST is not set. As such we can reset 'dom' right away.
+                 */
                 pirq_dpci->dom = NULL;
                 list_del(&girq->list);
                 list_del(&digl->list);
@@ -402,8 +535,13 @@ int pt_irq_destroy_bind(
         msixtbl_pt_unregister(d, pirq);
         if ( pt_irq_need_timer(pirq_dpci->flags) )
             kill_timer(&pirq_dpci->timer);
-        pirq_dpci->dom   = NULL;
         pirq_dpci->flags = 0;
+        /*
+         * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
+         * call to pt_pirq_softirq_reset.
+         */
+        pt_pirq_softirq_reset(pirq_dpci);
+
         pirq_cleanup_check(pirq, d);
     }
 
@@ -426,14 +564,12 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
-    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    if ( !dpci->flags )
+    if ( !dpci->flags && !pt_pirq_softirq_active(dpci) )
     {
-        tasklet_kill(&dpci->tasklet);
         dpci->dom = NULL;
         return 1;
     }
@@ -476,8 +612,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
-    pirq_dpci->masked = 1;
-    tasklet_schedule(&pirq_dpci->tasklet);
+    raise_softirq_for(pirq_dpci);
     return 1;
 }
 
@@ -531,28 +666,12 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static void hvm_dirq_assist(unsigned long arg)
+static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
 {
-    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
-    struct domain *d = pirq_dpci->dom;
-
-    /*
-     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
-     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
-     *
-     * And '->dom' gets cleared later in the destroy path. We exit and clear
-     * 'masked' - which is OK as later in this code we would
-     * do nothing except clear the ->masked field anyhow.
-     */
-    if ( !d )
-    {
-        pirq_dpci->masked = 0;
-        return;
-    }
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( test_and_clear_bool(pirq_dpci->masked) )
+    if ( pirq_dpci->state )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
@@ -654,3 +773,79 @@ void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
 unlock:
     spin_unlock(&d->event_lock);
 }
+
+static void dpci_softirq(void)
+{
+    unsigned int cpu = smp_processor_id();
+    LIST_HEAD(our_list);
+
+    local_irq_disable();
+    list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
+    local_irq_enable();
+
+    while ( !list_empty(&our_list) )
+    {
+        struct hvm_pirq_dpci *pirq_dpci;
+        struct domain *d;
+
+        pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
+        list_del(&pirq_dpci->softirq_list);
+
+        d = pirq_dpci->dom;
+        smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
+        if ( test_and_set_bit(STATE_RUN, &pirq_dpci->state) )
+            BUG();
+        /*
+         * The one who clears STATE_SCHED MUST refcount the domain.
+         */
+        if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )
+        {
+            hvm_dirq_assist(d, pirq_dpci);
+            put_domain(d);
+        }
+        clear_bit(STATE_RUN, &pirq_dpci->state);
+    }
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        /*
+         * On CPU_DYING this callback is called (on the CPU that is dying)
+         * with an possible HVM_DPIC_SOFTIRQ pending - at which point we can
+         * clear out any outstanding domains (by the virtue of the idle loop
+         * calling the softirq later). In CPU_DEAD case the CPU is deaf and
+         * there are no pending softirqs for us to handle so we can chill.
+         */
+        ASSERT(list_empty(&per_cpu(dpci_list, cpu)));
+        break;
+    }
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback,
+};
+
+static int __init setup_dpci_softirq(void)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu(cpu)
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+
+    open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+__initcall(setup_dpci_softirq);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 81e8a3a..78c6977 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,40 +767,51 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
-    tasklet_kill(&pirq_dpci->tasklet);
-
-    return 0;
+    return pt_pirq_softirq_active(pirq_dpci) ? -ERESTART : 0;
 }
 
-static void pci_clean_dpci_irqs(struct domain *d)
+static int pci_clean_dpci_irqs(struct domain *d)
 {
     struct hvm_irq_dpci *hvm_irq_dpci = NULL;
 
     if ( !iommu_enabled )
-        return;
+        return 0;
 
     if ( !is_hvm_domain(d) )
-        return;
+        return 0;
 
     spin_lock(&d->event_lock);
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+        int ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+
+        if ( ret )
+        {
+            spin_unlock(&d->event_lock);
+            return ret;
+        }
 
         d->arch.hvm_domain.irq.dpci = NULL;
         free_hvm_irq_dpci(hvm_irq_dpci);
     }
     spin_unlock(&d->event_lock);
+    return 0;
 }
 
-void pci_release_devices(struct domain *d)
+int pci_release_devices(struct domain *d)
 {
     struct pci_dev *pdev;
     u8 bus, devfn;
+    int ret;
 
     spin_lock(&pcidevs_lock);
-    pci_clean_dpci_irqs(d);
+    ret = pci_clean_dpci_irqs(d);
+    if ( ret )
+    {
+        spin_unlock(&pcidevs_lock);
+        return ret;
+    }
     while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
     {
         bus = pdev->bus;
@@ -811,6 +822,8 @@ void pci_release_devices(struct domain *d)
                    PCI_SLOT(devfn), PCI_FUNC(devfn));
     }
     spin_unlock(&pcidevs_lock);
+
+    return 0;
 }
 
 #define PCI_CLASS_BRIDGE_HOST    0x0600
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 7225dea..ec787d6 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -7,7 +7,8 @@
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
-#define NR_ARCH_SOFTIRQS       5
+#define HVM_DPCI_SOFTIRQ       (NR_COMMON_SOFTIRQS + 5)
+#define NR_ARCH_SOFTIRQS       6
 
 bool_t arch_skip_send_event_check(unsigned int cpu);
 
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 94a550a..9709397 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -93,13 +93,13 @@ struct hvm_irq_dpci {
 /* Machine IRQ to guest device/intx mapping. */
 struct hvm_pirq_dpci {
     uint32_t flags;
-    bool_t masked;
+    unsigned int state;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
-    struct tasklet tasklet;
+    struct list_head softirq_list;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
@@ -109,6 +109,7 @@ int pt_pirq_iterate(struct domain *d,
                               struct hvm_pirq_dpci *, void *arg),
                     void *arg);
 
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *);
 /* Modify state of a PCI INTx wire. */
 void hvm_pci_intx_assert(
     struct domain *d, unsigned int device, unsigned int intx);
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 91520bc..5f295f3 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -99,7 +99,7 @@ struct pci_dev *pci_lock_domain_pdev(
 
 void setup_hwdom_pci_devices(struct domain *,
                             int (*)(u8 devfn, struct pci_dev *));
-void pci_release_devices(struct domain *d);
+int pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
 const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
-- 
1.9.3


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 19:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 19: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 1XlN5a-00066Z-Qa; Mon, 03 Nov 2014 19:14:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlN5Y-00066P-Hv
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 19:14:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	30/74-09936-B24D7545; Mon, 03 Nov 2014 19:14:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415042089!12425499!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18948 invoked from network); 3 Nov 2014 19:14:50 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 19:14:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3JEipK022156
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 19:14:45 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3JEgqp015482
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 3 Nov 2014 19:14:43 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA3IQVo6026725; Mon, 3 Nov 2014 18:26:31 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 11:14:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 565E61100E8; Mon,  3 Nov 2014 14:14:39 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Mon,  3 Nov 2014 14:14:36 -0500
Message-Id: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH v9 for-xen-4.5] Fix interrupt latency of HVM
	PCIpassthrough 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Changelog:
since v8 (http://lists.xen.org/archives/html/xen-devel/2014-10/msg02564.html)
 - Went back-n-forth on remote softirq, fixed styleguide violations.
 - Moved call to pt_pirq_softirq_reset in pt_irq_create_bind
 - Removed 'case default'
 - Streamlined 'pci_clean_dpci_irqs' return usage.

since v7 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg04385.html)
 - Put ref-counting back, added two bits to allow ref-counting from other places.
since v6 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg03208.html)
 - Squashed #1 + #2.
 - Added more comments, redid it based on Jan's feedback.
since v5 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg02868.html)
 - Redid the series based on Jan's feedback
since v4
(http://lists.xen.org/archives/html/xen-devel/2014-09/msg01676.html):
 - Ditch the domain centric mechansim.
 - Fix issues raised by Jan.


The patches are an performance bug-fixes for PCI passthrough for machines
with many sockets. On those machines we have observed awful latency issues
with interrupts and with high steal time on idle guests. The root cause
was that the tasklet lock which was shared across all sockets. Each interrupt
that was to be delivered to a guest took the tasket lock - and with many
guests and many PCI passthrough devices - the performance and latency were
atrocious. These two patches fix the outstanding issues.

 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 282 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  29 +++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 283 insertions(+), 42 deletions(-)

Konrad Rzeszutek Wilk (2):
      dpci: Move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model.
      dpci: Replace tasklet with an softirq (v12)


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 19:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 19: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 1XlN5f-00067F-PG; Mon, 03 Nov 2014 19:14:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlN5e-000671-8r
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 19:14:58 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	F8/51-24859-134D7545; Mon, 03 Nov 2014 19:14:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415042095!11384734!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16938 invoked from network); 3 Nov 2014 19:14:56 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 19:14:56 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3JEhSP021966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 19:14:45 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3JEfvl024095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 19:14:42 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3JEeXC015390; Mon, 3 Nov 2014 19:14:41 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 11:14:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5EF791100EA; Mon,  3 Nov 2014 14:14:39 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Mon,  3 Nov 2014 14:14:37 -0500
Message-Id: <1415042078-8337-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
References: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [for-xen-4.5 v9 1/2] dpci: Move from an hvm_irq_dpci
	(and struct domain) to an hvm_dirq_dpci model.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 an interrupt for an PCI (or PCIe) passthrough device
is to be sent to a guest, we find the appropiate
'hvm_dirq_dpci' structure for the interrupt (PIRQ), set
a bit (masked), and schedule an tasklet.

Then the 'hvm_dirq_assist' tasklet gets called with the 'struct
domain' from where it iterates over the the radix-tree of
'hvm_dirq_dpci' (from zero to the number of PIRQs allocated)
which are masked to the guest and calls each 'hvm_pirq_assist'.
If the PIRQ has a bit set (masked) it figures out how to
inject the PIRQ to the guest.

This is inefficient and not fair as:
 - We iterate starting at PIRQ 0 and up every time. That means
   the PCIe devices that have lower PIRQs get to be called
   first.
 - If we have many PCIe devices passed in with many PIRQs and
   if most of the time only the highest numbered PIRQ get an
   interrupt (as the initial ones are for control) we end up
   iterating over many PIRQs.

But we could do beter - the 'hvm_dirq_dpci' has the field for
'struct domain', which we can use instead of having to pass in the
'struct domain'.

As such this patch moves the tasklet to the 'struct hvm_dirq_dpci'
and sets the 'dom' field to the domain. We also double-check
that the '->dom' is not reset before using it.

We have to be careful with this as that means we MUST have
'dom' set before pirq_guest_bind() is called. As such
we add the 'pirq_dpci->dom = d;' to cover for such
cases.

The mechanism to tear it down is more complex as there
are two ways it can be executed:

 a) pci_clean_dpci_irq. This gets called when the guest is
    being destroyed. We end up calling 'tasklet_kill'.

    The scenarios in which the 'struct pirq' (and subsequently
    the 'hvm_pirq_dpci') gets destroyed is when:

    - guest did not use the pirq at all after setup.
    - guest did use pirq, but decided to mask and left it in that
      state.
    - guest did use pirq, but crashed.

    In all of those scenarios we end up calling 'tasklet_kill'
    which will spin on the tasklet if it is running.

 b) pt_irq_destroy_bind (guest disables the MSI). We double-check
    that the softirq has run by piggy-backing on the existing
    'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
    We add the extra call to 'pt_pirq_softirq_active' in
    'pt_pirq_cleanup_check'.

    NOTE: Guests that use event channels unbind first the
    event channel from PIRQs, so the 'pt_pirq_cleanup_check'
    won't be called as event is set to zero. In that case
    we either clean it up via the a) mechanism. It is OK
    to re-use the tasklet when 'pt_irq_create_bind' is called
    afterwards.

    There is an extra scenario regardless of event being
    set or not: the guest did 'pt_irq_destroy_bind' while an
    interrupt was triggered and tasklet was scheduled (but had not
    been run). It is OK to still run the tasklet as
    hvm_dirq_assist won't do anything (as the flags are
    set to zero). As such we can exit out of hvm_dirq_assist
    without doing anything.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c  | 75 ++++++++++++++++++++++++++++++-------------
 xen/drivers/passthrough/pci.c |  4 +--
 xen/include/xen/hvm/irq.h     |  2 +-
 3 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 4cd32b5..dceb17e 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -27,7 +27,7 @@
 #include <xen/hvm/irq.h>
 #include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long _d);
+static void hvm_dirq_assist(unsigned long arg);
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -114,9 +114,6 @@ int pt_irq_create_bind(
             spin_unlock(&d->event_lock);
             return -ENOMEM;
         }
-        softirq_tasklet_init(
-            &hvm_irq_dpci->dirq_tasklet,
-            hvm_dirq_assist, (unsigned long)d);
         for ( i = 0; i < NR_HVM_IRQS; i++ )
             INIT_LIST_HEAD(&hvm_irq_dpci->girq[i]);
 
@@ -144,6 +141,18 @@ int pt_irq_create_bind(
                                HVM_IRQ_DPCI_GUEST_MSI;
             pirq_dpci->gmsi.gvec = pt_irq_bind->u.msi.gvec;
             pirq_dpci->gmsi.gflags = pt_irq_bind->u.msi.gflags;
+            /*
+             * 'pt_irq_create_bind' can be called after 'pt_irq_destroy_bind'.
+             * The 'pirq_cleanup_check' which would free the structure is only
+             * called if the event channel for the PIRQ is active. However
+             * OS-es that use event channels usually bind PIRQs to eventds
+             * and unbind them before calling 'pt_irq_destroy_bind' - with the
+             * result that we re-use the 'dpci' structure. This can be
+             * reproduced with unloading and loading the driver for a device.
+             *
+             * As such on every 'pt_irq_create_bind' call we MUST set it.
+             */
+            pirq_dpci->dom = d;
             /* bind after hvm_irq_dpci is setup to avoid race with irq handler*/
             rc = pirq_guest_bind(d->vcpu[0], info, 0);
             if ( rc == 0 && pt_irq_bind->u.msi.gtable )
@@ -156,6 +165,7 @@ int pt_irq_create_bind(
             {
                 pirq_dpci->gmsi.gflags = 0;
                 pirq_dpci->gmsi.gvec = 0;
+                pirq_dpci->dom = NULL;
                 pirq_dpci->flags = 0;
                 pirq_cleanup_check(info, d);
                 spin_unlock(&d->event_lock);
@@ -232,6 +242,7 @@ int pt_irq_create_bind(
         {
             unsigned int share;
 
+            /* MUST be set, as the pirq_dpci can be re-used. */
             pirq_dpci->dom = d;
             if ( pt_irq_bind->irq_type == PT_IRQ_TYPE_MSI_TRANSLATE )
             {
@@ -415,11 +426,18 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
+    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    return !dpci->flags;
+    if ( !dpci->flags )
+    {
+        tasklet_kill(&dpci->tasklet);
+        dpci->dom = NULL;
+        return 1;
+    }
+    return 0;
 }
 
 int pt_pirq_iterate(struct domain *d,
@@ -459,7 +477,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
         return 0;
 
     pirq_dpci->masked = 1;
-    tasklet_schedule(&dpci->dirq_tasklet);
+    tasklet_schedule(&pirq_dpci->tasklet);
     return 1;
 }
 
@@ -513,9 +531,27 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
-                            void *arg)
+static void hvm_dirq_assist(unsigned long arg)
 {
+    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
+    struct domain *d = pirq_dpci->dom;
+
+    /*
+     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
+     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
+     *
+     * And '->dom' gets cleared later in the destroy path. We exit and clear
+     * 'masked' - which is OK as later in this code we would
+     * do nothing except clear the ->masked field anyhow.
+     */
+    if ( !d )
+    {
+        pirq_dpci->masked = 0;
+        return;
+    }
+    ASSERT(d->arch.hvm_domain.irq.dpci);
+
+    spin_lock(&d->event_lock);
     if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
@@ -526,13 +562,17 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
             send_guest_pirq(d, pirq);
 
             if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
-                return 0;
+            {
+                spin_unlock(&d->event_lock);
+                return;
+            }
         }
 
         if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
         {
             vmsi_deliver_pirq(d, pirq_dpci);
-            return 0;
+            spin_unlock(&d->event_lock);
+            return;
         }
 
         list_for_each_entry ( digl, &pirq_dpci->digl_list, list )
@@ -545,7 +585,8 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
         {
             /* for translated MSI to INTx interrupt, eoi as early as possible */
             __msi_pirq_eoi(pirq_dpci);
-            return 0;
+            spin_unlock(&d->event_lock);
+            return;
         }
 
         /*
@@ -558,18 +599,6 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
         ASSERT(pt_irq_need_timer(pirq_dpci->flags));
         set_timer(&pirq_dpci->timer, NOW() + PT_IRQ_TIME_OUT);
     }
-
-    return 0;
-}
-
-static void hvm_dirq_assist(unsigned long _d)
-{
-    struct domain *d = (struct domain *)_d;
-
-    ASSERT(d->arch.hvm_domain.irq.dpci);
-
-    spin_lock(&d->event_lock);
-    pt_pirq_iterate(d, _hvm_dirq_assist, NULL);
     spin_unlock(&d->event_lock);
 }
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1eba833..81e8a3a 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,6 +767,8 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
+    tasklet_kill(&pirq_dpci->tasklet);
+
     return 0;
 }
 
@@ -784,8 +786,6 @@ static void pci_clean_dpci_irqs(struct domain *d)
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        tasklet_kill(&hvm_irq_dpci->dirq_tasklet);
-
         pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
 
         d->arch.hvm_domain.irq.dpci = NULL;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index c89f4b1..94a550a 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -88,7 +88,6 @@ struct hvm_irq_dpci {
     DECLARE_BITMAP(isairq_map, NR_ISAIRQS);
     /* Record of mapped Links */
     uint8_t link_cnt[NR_LINK];
-    struct tasklet dirq_tasklet;
 };
 
 /* Machine IRQ to guest device/intx mapping. */
@@ -100,6 +99,7 @@ struct hvm_pirq_dpci {
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
+    struct tasklet tasklet;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 19:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 19: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 1XlN5b-00066g-63; Mon, 03 Nov 2014 19:14: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 1XlN5a-00066U-4E
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 19:14:54 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	A3/7B-22737-D24D7545; Mon, 03 Nov 2014 19:14:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415042090!10947576!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16213 invoked from network); 3 Nov 2014 19:14:52 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 19:14:52 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA3JEhu1022147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Nov 2014 19:14:44 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3JEgIP028287
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 3 Nov 2014 19:14:43 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA3JEg0S015444; Mon, 3 Nov 2014 19:14:42 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Nov 2014 11:14:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6DD391100EC; Mon,  3 Nov 2014 14:14:39 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Mon,  3 Nov 2014 14:14:38 -0500
Message-Id: <1415042078-8337-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
References: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [for-xen-4.5 v9 2/2] dpci: Replace tasklet with an
	softirq (v12)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The existing tasklet mechanism has a single global
spinlock that is taken every-time the global list
is touched. And we use this lock quite a lot - when
we call do_tasklet_work which is called via an softirq
and from the idle loop. We take the lock on any
operation on the tasklet_list.

The problem we are facing is that there are quite a lot of
tasklets scheduled. The most common one that is invoked is
the one injecting the VIRQ_TIMER in the guest. Guests
are not insane and don't set the one-shot or periodic
clocks to be in sub 1ms intervals (causing said tasklet
to be scheduled for such small intervalls).

The problem appears when PCI passthrough devices are used
over many sockets and we have an mix of heavy-interrupt
guests and idle guests. The idle guests end up seeing
1/10 of its RUNNING timeslice eaten by the hypervisor
(and 40% steal time).

The mechanism by which we inject PCI interrupts is by
hvm_do_IRQ_dpci which schedules the hvm_dirq_assist
tasklet every time an interrupt is received.
The callchain is:

_asm_vmexit_handler
 -> vmx_vmexit_handler
    ->vmx_do_extint
        -> do_IRQ
            -> __do_IRQ_guest
                -> hvm_do_IRQ_dpci
                   tasklet_schedule(&dpci->dirq_tasklet);
                   [takes lock to put the tasklet on]

[later on the schedule_tail is invoked which is 'vmx_do_resume']

vmx_do_resume
 -> vmx_asm_do_vmentry
        -> call vmx_intr_assist
          -> vmx_process_softirqs
            -> do_softirq
              [executes the tasklet function, takes the
               lock again]

While on other CPUs they might be sitting in a idle loop
and invoked to deliver an VIRQ_TIMER, which also ends
up taking the lock twice: first to schedule the
v->arch.hvm_vcpu.assert_evtchn_irq_tasklet (accounted to
the guests' BLOCKED_state); then to execute it - which is
accounted for in the guest's RUNTIME_state.

The end result is that on a 8 socket machine with
PCI passthrough, where four sockets are busy with interrupts,
and the other sockets have idle guests - we end up with
the idle guests having around 40% steal time and 1/10
of its timeslice (3ms out of 30 ms) being tied up
taking the lock. The latency of the PCI interrupts delieved
to guest is also hindered.

With this patch the problem disappears completly.
That is removing the lock for the PCI passthrough use-case
(the 'hvm_dirq_assist' case) by not using tasklets at all.

The patch is simple - instead of scheduling an tasklet
we schedule our own softirq - HVM_DPCI_SOFTIRQ, which will
take care of running 'hvm_dirq_assist'. The information we need
on each CPU is which 'struct hvm_pirq_dpci' structure the
'hvm_dirq_assist' needs to run on. That is simple solved by
threading the 'struct hvm_pirq_dpci' through a linked list.
The rule of only running one 'hvm_dirq_assist' for only
one 'hvm_pirq_dpci' is also preserved by having
'schedule_dpci_for' ignore any subsequent calls for an domain
which has already been scheduled.

== Code details ==

Most of the code complexity comes from the '->dom' field
in the 'hvm_pirq_dpci' structure. We use it for ref-counting
and as such it MUST be valid as long as STATE_SCHED bit is
set. Whoever clears the STATE_SCHED bit does the ref-counting
and can also reset the '->dom' field.

To compound the complexity, there are multiple points where the
'hvm_pirq_dpci' structure is reset or re-used. Initially
(first time the domain uses the pirq), the 'hvm_pirq_dpci->dom'
field is set to NULL as it is allocated. On subsequent calls
in to 'pt_irq_create_bind' the ->dom is whatever it had last time.

As this is the initial call (which QEMU ends up calling when the
guest writes an vector value in the MSI field) we MUST set the
'->dom' to a the proper structure (otherwise we cannot do
proper ref-counting).

The mechanism to tear it down is more complex as there
are three ways it can be executed. To make it simpler
everything revolves around 'pt_pirq_softirq_active'. If it
returns -EAGAIN that means there is an outstanding softirq
that needs to finish running before we can continue tearing
down. With that in mind:

a) pci_clean_dpci_irq. This gets called when the guest is
   being destroyed. We end up calling 'pt_pirq_softirq_active'
   to see if it is OK to continue the destruction.

   The scenarios in which the 'struct pirq' (and subsequently
   the 'hvm_pirq_dpci') gets destroyed is when:

   - guest did not use the pirq at all after setup.
   - guest did use pirq, but decided to mask and left it in that
     state.
   - guest did use pirq, but crashed.

   In all of those scenarios we end up calling
   'pt_pirq_softirq_active' to check if the softirq is still
   active. Read below on the 'pt_pirq_softirq_active' loop.

b) pt_irq_destroy_bind (guest disables the MSI). We double-check
   that the softirq has run by piggy-backing on the existing
   'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
   We add the extra call to 'pt_pirq_softirq_active' in
   'pt_pirq_cleanup_check'.

   NOTE: Guests that use event channels unbind first the
   event channel from PIRQs, so the 'pt_pirq_cleanup_check'
   won't be called as 'event' is set to zero. In that case
   we either clean it up via the a) or c) mechanism.

   There is an extra scenario regardless of 'event' being
   set or not: the guest did 'pt_irq_destroy_bind' while an
   interrupt was triggered and softirq was scheduled (but had not
   been run). It is OK to still run the softirq as
   hvm_dirq_assist won't do anything (as the flags are
   set to zero). However we will try to deschedule the
   softirq if we can (by clearing the STATE_SCHED bit and us
   doing the ref-counting).

c) pt_irq_create_bind (not a typo). The scenarios are:

     - guest disables the MSI and then enables it
       (rmmod and modprobe in a loop). We call 'pt_pirq_reset'
       which checks to see if the softirq has been scheduled.
       Imagine the 'b)' with interrupts in flight and c) getting
       called in a loop.

We will spin up on 'pt_pirq_is_active' (at the start of the
'pt_irq_create_bind') with the event_lock spinlock dropped and
waiting (cpu_relax). We cannot call 'process_pending_softirqs' as it
might result in a dead-lock. hvm_dirq_assist will be executed
and then the softirq will clear 'state' which signals that that we
can re-use the 'hvm_pirq_dpci' structure. In case this softirq
is scheduled on a remote CPU the softirq will run on it as the
semantics behind an softirq is that it will execute within the
guest interruption.

     - we hit once the error paths in 'pt_irq_create_bind' while
       an interrupt was triggered and softirq was scheduled.

If the softirq is in STATE_RUN that means it is executing and we should
let it continue on. We can clear the '->dom' field as the softirq
has stashed it beforehand. If the softirq is STATE_SCHED and
we are successful in clearing it, we do the ref-counting and
clear the '->dom' field. Otherwise we let the softirq continue
on and the '->dom' field is left intact. The clearing of
the '->dom' is left to a), b) or again c) case.

Note that in both cases the 'flags' variable is cleared so
hvm_dirq_assist won't actually do anything.

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

---
v2: On top of ref-cnts also have wait loop for the outstanding
    'struct domain' that need to be processed.
v3: Add -ERETRY, fix up StyleGuide issues
v4: Clean it up mode, redo per_cpu, this_cpu logic
v5: Instead of threading struct domain, use hvm_pirq_dpci.
v6: Ditch the 'state' bit, expand description, simplify
    softirq and teardown sequence.
v7: Flesh out the comments. Drop the use of domain refcounts
v8: Add two bits (STATE_[SCHED|RUN]) to allow refcounts.
v9: Use cmpxchg, ASSSERT, fix up comments per Jan.
v10: Fix up issues spotted by Jan.
v11: IPI the remote CPU (once) if it it has the softirq scheduled.
v12: Remove the IPI for the remote CPU as the sofitrq mechanism does that.
---
 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 251 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  31 ++++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 254 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..73d01bb 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1965,7 +1965,9 @@ int domain_relinquish_resources(struct domain *d)
     switch ( d->arch.relmem )
     {
     case RELMEM_not_started:
-        pci_release_devices(d);
+        ret = pci_release_devices(d);
+        if ( ret )
+            return ret;
 
         /* Tear down paging-assistance stuff. */
         ret = paging_teardown(d);
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index dceb17e..8dcb254 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -20,14 +20,120 @@
 
 #include <xen/event.h>
 #include <xen/iommu.h>
+#include <xen/cpu.h>
 #include <xen/irq.h>
 #include <asm/hvm/irq.h>
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
-#include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long arg);
+static DEFINE_PER_CPU(struct list_head, dpci_list);
+
+/*
+ * These two bit states help to safely schedule, deschedule, and wait until
+ * the softirq has finished.
+ *
+ * The semantics behind these two bits is as follow:
+ *  - STATE_SCHED - whoever modifies it has to ref-count the domain (->dom).
+ *  - STATE_RUN - only softirq is allowed to set and clear it. If it has
+ *      been set hvm_dirq_assist will RUN with a saved value of the
+ *      'struct domain' copied from 'pirq_dpci->dom' before STATE_RUN was set.
+ *
+ * The usual states are: STATE_SCHED(set) -> STATE_RUN(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(unset).
+ *
+ * However the states can also diverge such as: STATE_SCHED(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(set) -> STATE_RUN(unset). That means
+ * the 'hvm_dirq_assist' never run and that the softirq did not do any
+ * ref-counting.
+ */
+
+enum {
+    STATE_SCHED,
+    STATE_RUN
+};
+
+/*
+ * Should only be called from hvm_do_IRQ_dpci. We use the
+ * 'state' as a gate to thwart multiple interrupts being scheduled.
+ * The 'state' is cleared by 'softirq_dpci' when it has
+ * completed executing 'hvm_dirq_assist' or by 'pt_pirq_softirq_reset'
+ * if we want to try to unschedule the softirq before it runs.
+ *
+ */
+static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
+{
+    unsigned long flags;
+
+    if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+        return;
+
+    get_knownalive_domain(pirq_dpci->dom);
+
+    local_irq_save(flags);
+    list_add_tail(&pirq_dpci->softirq_list, &this_cpu(dpci_list));
+    local_irq_restore(flags);
+
+    raise_softirq(HVM_DPCI_SOFTIRQ);
+}
+
+/*
+ * If we are racing with softirq_dpci (state is still set) we return
+ * true. Otherwise we return false.
+ *
+ *  If it is false, it is the callers responsibility to make sure
+ *  that the softirq (with the event_lock dropped) has ran. We need
+ *  to flush out the outstanding 'dpci_softirq' (no more of them
+ *  will be added for this pirq as the IRQ action handler has been
+ *  reset in pt_irq_destroy_bind).
+ */
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
+{
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+        return 1;
+
+    /*
+     * If in the future we would call 'raise_softirq_for' right away
+     * after 'pt_pirq_softirq_active' we MUST reset the list (otherwise it
+     * might have stale data).
+     */
+    return 0;
+}
+
+/*
+ * Reset the pirq_dpci->dom parameter to NULL.
+ *
+ * This function checks the different states to make sure it can do
+ * at the right time and if unschedules the softirq before it has
+ * run it also refcounts (which is what the softirq would have done).
+ */
+static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+{
+    struct domain *d = pirq_dpci->dom;
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    {
+    case (1 << STATE_SCHED):
+        /*
+         * We are going to try to de-schedule the softirq before it goes in
+         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
+         */
+        put_domain(d);
+        /* fallthrough. */
+    case (1 << STATE_RUN):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED):
+        /*
+         * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
+         * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
+         * in local variable before it sets STATE_RUN - and therefore will not
+         * dereference '->dom' which would crash.
+         */
+        pirq_dpci->dom = NULL;
+        break;
+    }
+}
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -40,7 +146,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->masked = 0;
+        pirq_dpci->state = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -101,6 +207,7 @@ int pt_irq_create_bind(
     if ( pirq < 0 || pirq >= d->nr_pirqs )
         return -EINVAL;
 
+ restart:
     spin_lock(&d->event_lock);
 
     hvm_irq_dpci = domain_get_irq_dpci(d);
@@ -127,7 +234,20 @@ int pt_irq_create_bind(
         return -ENOMEM;
     }
     pirq_dpci = pirq_dpci(info);
-
+    /*
+     * A crude 'while' loop with us dropping the spinlock and giving
+     * the softirq_dpci a chance to run.
+     * We MUST check for this condition as the softirq could be scheduled
+     * and hasn't run yet. Note that this code replaced tasklet_kill which
+     * would have spun forever and would do the same thing (wait to flush out
+     * outstanding hvm_dirq_assist calls.
+     */
+    if ( pt_pirq_softirq_active(pirq_dpci) )
+    {
+        spin_unlock(&d->event_lock);
+        cpu_relax();
+        goto restart;
+    }
     switch ( pt_irq_bind->irq_type )
     {
     case PT_IRQ_TYPE_MSI:
@@ -159,7 +279,16 @@ int pt_irq_create_bind(
             {
                 rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
                 if ( unlikely(rc) )
+                {
                     pirq_guest_unbind(d, info);
+                    /*
+                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
+                     * an interrupt can be scheduled. No more of them are going
+                     * to be scheduled but we must deal with the one that is in
+                     * the queue.
+                     */
+                    pt_pirq_softirq_reset(pirq_dpci);
+                }
             }
             if ( unlikely(rc) )
             {
@@ -269,6 +398,10 @@ int pt_irq_create_bind(
             {
                 if ( pt_irq_need_timer(pirq_dpci->flags) )
                     kill_timer(&pirq_dpci->timer);
+                /*
+                 * There is no path for __do_IRQ to schedule softirq as
+                 * IRQ_GUEST is not set. As such we can reset 'dom' right away.
+                 */
                 pirq_dpci->dom = NULL;
                 list_del(&girq->list);
                 list_del(&digl->list);
@@ -402,8 +535,13 @@ int pt_irq_destroy_bind(
         msixtbl_pt_unregister(d, pirq);
         if ( pt_irq_need_timer(pirq_dpci->flags) )
             kill_timer(&pirq_dpci->timer);
-        pirq_dpci->dom   = NULL;
         pirq_dpci->flags = 0;
+        /*
+         * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
+         * call to pt_pirq_softirq_reset.
+         */
+        pt_pirq_softirq_reset(pirq_dpci);
+
         pirq_cleanup_check(pirq, d);
     }
 
@@ -426,14 +564,12 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
-    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    if ( !dpci->flags )
+    if ( !dpci->flags && !pt_pirq_softirq_active(dpci) )
     {
-        tasklet_kill(&dpci->tasklet);
         dpci->dom = NULL;
         return 1;
     }
@@ -476,8 +612,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
-    pirq_dpci->masked = 1;
-    tasklet_schedule(&pirq_dpci->tasklet);
+    raise_softirq_for(pirq_dpci);
     return 1;
 }
 
@@ -531,28 +666,12 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static void hvm_dirq_assist(unsigned long arg)
+static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
 {
-    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
-    struct domain *d = pirq_dpci->dom;
-
-    /*
-     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
-     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
-     *
-     * And '->dom' gets cleared later in the destroy path. We exit and clear
-     * 'masked' - which is OK as later in this code we would
-     * do nothing except clear the ->masked field anyhow.
-     */
-    if ( !d )
-    {
-        pirq_dpci->masked = 0;
-        return;
-    }
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( test_and_clear_bool(pirq_dpci->masked) )
+    if ( pirq_dpci->state )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
@@ -654,3 +773,79 @@ void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
 unlock:
     spin_unlock(&d->event_lock);
 }
+
+static void dpci_softirq(void)
+{
+    unsigned int cpu = smp_processor_id();
+    LIST_HEAD(our_list);
+
+    local_irq_disable();
+    list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
+    local_irq_enable();
+
+    while ( !list_empty(&our_list) )
+    {
+        struct hvm_pirq_dpci *pirq_dpci;
+        struct domain *d;
+
+        pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
+        list_del(&pirq_dpci->softirq_list);
+
+        d = pirq_dpci->dom;
+        smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
+        if ( test_and_set_bit(STATE_RUN, &pirq_dpci->state) )
+            BUG();
+        /*
+         * The one who clears STATE_SCHED MUST refcount the domain.
+         */
+        if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )
+        {
+            hvm_dirq_assist(d, pirq_dpci);
+            put_domain(d);
+        }
+        clear_bit(STATE_RUN, &pirq_dpci->state);
+    }
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        /*
+         * On CPU_DYING this callback is called (on the CPU that is dying)
+         * with an possible HVM_DPIC_SOFTIRQ pending - at which point we can
+         * clear out any outstanding domains (by the virtue of the idle loop
+         * calling the softirq later). In CPU_DEAD case the CPU is deaf and
+         * there are no pending softirqs for us to handle so we can chill.
+         */
+        ASSERT(list_empty(&per_cpu(dpci_list, cpu)));
+        break;
+    }
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback,
+};
+
+static int __init setup_dpci_softirq(void)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu(cpu)
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+
+    open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+__initcall(setup_dpci_softirq);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 81e8a3a..78c6977 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,40 +767,51 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
-    tasklet_kill(&pirq_dpci->tasklet);
-
-    return 0;
+    return pt_pirq_softirq_active(pirq_dpci) ? -ERESTART : 0;
 }
 
-static void pci_clean_dpci_irqs(struct domain *d)
+static int pci_clean_dpci_irqs(struct domain *d)
 {
     struct hvm_irq_dpci *hvm_irq_dpci = NULL;
 
     if ( !iommu_enabled )
-        return;
+        return 0;
 
     if ( !is_hvm_domain(d) )
-        return;
+        return 0;
 
     spin_lock(&d->event_lock);
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+        int ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+
+        if ( ret )
+        {
+            spin_unlock(&d->event_lock);
+            return ret;
+        }
 
         d->arch.hvm_domain.irq.dpci = NULL;
         free_hvm_irq_dpci(hvm_irq_dpci);
     }
     spin_unlock(&d->event_lock);
+    return 0;
 }
 
-void pci_release_devices(struct domain *d)
+int pci_release_devices(struct domain *d)
 {
     struct pci_dev *pdev;
     u8 bus, devfn;
+    int ret;
 
     spin_lock(&pcidevs_lock);
-    pci_clean_dpci_irqs(d);
+    ret = pci_clean_dpci_irqs(d);
+    if ( ret )
+    {
+        spin_unlock(&pcidevs_lock);
+        return ret;
+    }
     while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
     {
         bus = pdev->bus;
@@ -811,6 +822,8 @@ void pci_release_devices(struct domain *d)
                    PCI_SLOT(devfn), PCI_FUNC(devfn));
     }
     spin_unlock(&pcidevs_lock);
+
+    return 0;
 }
 
 #define PCI_CLASS_BRIDGE_HOST    0x0600
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 7225dea..ec787d6 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -7,7 +7,8 @@
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
-#define NR_ARCH_SOFTIRQS       5
+#define HVM_DPCI_SOFTIRQ       (NR_COMMON_SOFTIRQS + 5)
+#define NR_ARCH_SOFTIRQS       6
 
 bool_t arch_skip_send_event_check(unsigned int cpu);
 
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 94a550a..9709397 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -93,13 +93,13 @@ struct hvm_irq_dpci {
 /* Machine IRQ to guest device/intx mapping. */
 struct hvm_pirq_dpci {
     uint32_t flags;
-    bool_t masked;
+    unsigned int state;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
-    struct tasklet tasklet;
+    struct list_head softirq_list;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
@@ -109,6 +109,7 @@ int pt_pirq_iterate(struct domain *d,
                               struct hvm_pirq_dpci *, void *arg),
                     void *arg);
 
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *);
 /* Modify state of a PCI INTx wire. */
 void hvm_pci_intx_assert(
     struct domain *d, unsigned int device, unsigned int intx);
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 91520bc..5f295f3 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -99,7 +99,7 @@ struct pci_dev *pci_lock_domain_pdev(
 
 void setup_hwdom_pci_devices(struct domain *,
                             int (*)(u8 devfn, struct pci_dev *));
-void pci_release_devices(struct domain *d);
+int pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
 const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
-- 
1.9.3


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 21:18:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 21:18:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlP0Z-0008Og-Gb; Mon, 03 Nov 2014 21:17:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waiman.long@hp.com>) id 1XlP0X-0008Ob-JD
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 21:17:49 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	75/E3-02698-CF0F7545; Mon, 03 Nov 2014 21:17:48 +0000
X-Env-Sender: waiman.long@hp.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415049466!12318039!1
X-Originating-IP: [15.192.137.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25180 invoked from network); 3 Nov 2014 21:17:47 -0000
Received: from g5t1626.atlanta.hp.com (HELO g5t1626.atlanta.hp.com)
	(15.192.137.9)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 21:17:47 -0000
Received: from g5t1633.atlanta.hp.com (g5t1633.atlanta.hp.com [16.201.144.132])
	by g5t1626.atlanta.hp.com (Postfix) with ESMTP id A0C2A61;
	Mon,  3 Nov 2014 21:17:45 +0000 (UTC)
Received: from [10.152.32.102] (ospra1.fc.hp.com [16.79.38.118])
	by g5t1633.atlanta.hp.com (Postfix) with ESMTP id EE57690;
	Mon,  3 Nov 2014 21:17:40 +0000 (UTC)
Message-ID: <5457F0F3.5080008@hp.com>
Date: Mon, 03 Nov 2014 16:17:39 -0500
From: Waiman Long <waiman.long@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12
MIME-Version: 1.0
To: Peter Zijlstra <peterz@infradead.org>
References: <1414613951-32532-1-git-send-email-Waiman.Long@hp.com>
	<1414613951-32532-10-git-send-email-Waiman.Long@hp.com>
	<20141103103505.GZ23531@worktop.programming.kicks-ass.net>
In-Reply-To: <20141103103505.GZ23531@worktop.programming.kicks-ass.net>
Cc: linux-arch@vger.kernel.org,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Oleg Nesterov <oleg@redhat.com>, kvm@vger.kernel.org,
	Scott J Norton <scott.norton@hp.com>, x86@kernel.org,
	Paolo Bonzini <paolo.bonzini@gmail.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Douglas Hatch <doug.hatch@hp.com>
Subject: Re: [Xen-devel] [PATCH v13 09/11] pvqspinlock,
	x86: Add para-virtualization support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/2014 05:35 AM, Peter Zijlstra wrote:
> On Wed, Oct 29, 2014 at 04:19:09PM -0400, Waiman Long wrote:
>>   arch/x86/include/asm/pvqspinlock.h    |  411 +++++++++++++++++++++++++++++++++
> I do wonder why all this needs to live in x86..
>

I haven't looked into the para-virtualization code in other 
architectures to see if my PV code is equally applicable there. That is 
why I put it under the x86 directory. If other architectures decide to 
use qspinlock with paravirtualization, we may need to pull out some 
common code, if any, back to kernel/locking.

>>
>> +#ifdef CONFIG_QUEUE_SPINLOCK
>> +
>> +static __always_inline void pv_kick_cpu(int cpu)
>> +{
>> +	PVOP_VCALLEE1(pv_lock_ops.kick_cpu, cpu);
>> +}
>> +
>> +static __always_inline void pv_lockwait(u8 *lockbyte)
>> +{
>> +	PVOP_VCALLEE1(pv_lock_ops.lockwait, lockbyte);
>> +}
>> +
>> +static __always_inline void pv_lockstat(enum pv_lock_stats type)
>> +{
>> +	PVOP_VCALLEE1(pv_lock_ops.lockstat, type);
>> +}
> Why are any of these PV ops? they're only called from other pv_*()
> functions. What's the point of pv ops you only call from pv code?

It is the same reason that you made them PV ops in your patch. Even when 
PV is on, the code won't need to call any of the PV ops most of the 
time. So it is just a matter of optimizing the most common case at the 
expense of performance in the rare case that the CPU need to be halt and 
woken up which will be bad performance-wise anyway However, if you think 
they should be regular function pointers, I am fine with that too.

>> +/*
>> + *	Queue Spinlock Para-Virtualization (PV) Support
>> + *
>> + * The PV support code for queue spinlock is roughly the same as that
>> + * of the ticket spinlock.
> Relative comments are bad, esp. since we'll make the ticket code go away
> if this works, at which point this is a reference into a black hole.

Thank for the suggestion, I will remove that when I need to revise the 
patch.

>>                              Each CPU waiting for the lock will spin until it
>> + * reaches a threshold. When that happens, it will put itself to a halt state
>> + * so that the hypervisor can reuse the CPU cycles in some other guests as
>> + * well as returning other hold-up CPUs faster.
>
>
>
>> +/**
>> + * queue_spin_lock - acquire a queue spinlock
>> + * @lock: Pointer to queue spinlock structure
>> + *
>> + * N.B. INLINE_SPIN_LOCK should not be enabled when PARAVIRT_SPINLOCK is on.
> One should write a compile time fail for that, not a comment.

Will do that.

>> + */
>> +static __always_inline void queue_spin_lock(struct qspinlock *lock)
>> +{
>> +	u32 val;
>> +
>> +	val = atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL);
>> +	if (likely(val == 0))
>> +		return;
>> +	if (static_key_false(&paravirt_spinlocks_enabled))
>> +		pv_queue_spin_lock_slowpath(lock, val);
>> +	else
>> +		queue_spin_lock_slowpath(lock, val);
>> +}
> No, this is just vile.. _that_ is what we have PV ops for. And at that
> point its the same function it was before the PV stuff, so that whole
> inline thing is then gone.

I did that because in all the architectures except s390, the lock 
functions are not inlined. They live in the _raw_spin_lock* defined in 
kernel/locking/spinlock.c. The unlock functions, on the other hand, are 
all inlined except when PV spinlock is enabled. So adding a check for 
the jump label won't change any of the status quo.

>> +extern void queue_spin_unlock_slowpath(struct qspinlock *lock);
>> +
>>   /**
>>    * queue_spin_unlock - release a queue spinlock
>>    * @lock : Pointer to queue spinlock structure
>>    *
>>    * An effective smp_store_release() on the least-significant byte.
>> + *
>> + * Inlining of the unlock function is disabled when CONFIG_PARAVIRT_SPINLOCKS
>> + * is defined. So _raw_spin_unlock() will be the only call site that will
>> + * have to be patched.
> again if you hard rely on the not inlining make a build fail not a
> comment.

Will do that.

>>    */
>>   static inline void queue_spin_unlock(struct qspinlock *lock)
>>   {
>>   	barrier();
>> +	if (!static_key_false(&paravirt_spinlocks_enabled)) {
>> +		native_spin_unlock(lock);
>> +		return;
>> +	}
>>
>> +	/*
>> +	 * Need to atomically clear the lock byte to avoid racing with
>> +	 * queue head waiter trying to set _QLOCK_LOCKED_SLOWPATH.
>> +	 */
>> +	if (unlikely(cmpxchg((u8 *)lock, _Q_LOCKED_VAL, 0) != _Q_LOCKED_VAL))
>> +		queue_spin_unlock_slowpath(lock);
>> +}
> Idem, that static key stuff is wrong, use PV ops to switch between
> unlock paths.

As said in my previous emails, the PV ops call site patching code 
doesn't work well with locking. First of all, the native_patch() 
function was called even in a KVM PV guest. Some unlock calls happened 
before the paravirt_spinlocks_enabled jump label was set up. It occurs 
to me that call site patching is done the first time the call site is 
used. At least for those early unlock calls, there is no way to figure 
out if it should use the native fast path or the PV slow path. The only 
possible workaround that I can think of is to use a variable (if 
available) that signal the end of the bootup init phase, we can then 
defer the call site patching until the init phase has passed.

This is a rather complicated solution which may not worth the slight 
benefit of a faster unlock call in the native case.

>> @@ -354,7 +394,7 @@ queue:
>>   	 * if there was a previous node; link it and wait until reaching the
>>   	 * head of the waitqueue.
>>   	 */
>> -	if (old&  _Q_TAIL_MASK) {
>> +	if (!pv_link_and_wait_node(old, node)&&  (old&  _Q_TAIL_MASK)) {
>>   		prev = decode_tail(old);
>>   		ACCESS_ONCE(prev->next) = node;
>> @@ -369,9 +409,11 @@ queue:
>>   	 *
>>   	 * *,x,y ->  *,0,0
>>   	 */
>> -	while ((val = smp_load_acquire(&lock->val.counter))&
>> -			_Q_LOCKED_PENDING_MASK)
>> +	val = pv_wait_head(lock, node);
>> +	while (val&  _Q_LOCKED_PENDING_MASK) {
>>   		cpu_relax();
>> +		val = smp_load_acquire(&lock->val.counter);
>> +	}
>>
>>   	/*
>>   	 * claim the lock:
> Please make the pv_*() calls return void and reduce to NOPs. This keeps
> the logic invariant of the pv stuff.

In my patch, the two pv_*() calls above serve as replacements of the 
waiting code. Making them return void and reduce to NOPs will cause what 
Konrad said doing the same operation twice which is not ideal from a 
performance point of view for the PV version. Is putting the pre-PV code 
in the comment help to clarify what the code should be before the PV stuff?

-Longman


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 21:18:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 21:18:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlP0Z-0008Og-Gb; Mon, 03 Nov 2014 21:17:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waiman.long@hp.com>) id 1XlP0X-0008Ob-JD
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 21:17:49 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	75/E3-02698-CF0F7545; Mon, 03 Nov 2014 21:17:48 +0000
X-Env-Sender: waiman.long@hp.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415049466!12318039!1
X-Originating-IP: [15.192.137.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25180 invoked from network); 3 Nov 2014 21:17:47 -0000
Received: from g5t1626.atlanta.hp.com (HELO g5t1626.atlanta.hp.com)
	(15.192.137.9)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 21:17:47 -0000
Received: from g5t1633.atlanta.hp.com (g5t1633.atlanta.hp.com [16.201.144.132])
	by g5t1626.atlanta.hp.com (Postfix) with ESMTP id A0C2A61;
	Mon,  3 Nov 2014 21:17:45 +0000 (UTC)
Received: from [10.152.32.102] (ospra1.fc.hp.com [16.79.38.118])
	by g5t1633.atlanta.hp.com (Postfix) with ESMTP id EE57690;
	Mon,  3 Nov 2014 21:17:40 +0000 (UTC)
Message-ID: <5457F0F3.5080008@hp.com>
Date: Mon, 03 Nov 2014 16:17:39 -0500
From: Waiman Long <waiman.long@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12
MIME-Version: 1.0
To: Peter Zijlstra <peterz@infradead.org>
References: <1414613951-32532-1-git-send-email-Waiman.Long@hp.com>
	<1414613951-32532-10-git-send-email-Waiman.Long@hp.com>
	<20141103103505.GZ23531@worktop.programming.kicks-ass.net>
In-Reply-To: <20141103103505.GZ23531@worktop.programming.kicks-ass.net>
Cc: linux-arch@vger.kernel.org,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Oleg Nesterov <oleg@redhat.com>, kvm@vger.kernel.org,
	Scott J Norton <scott.norton@hp.com>, x86@kernel.org,
	Paolo Bonzini <paolo.bonzini@gmail.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Douglas Hatch <doug.hatch@hp.com>
Subject: Re: [Xen-devel] [PATCH v13 09/11] pvqspinlock,
	x86: Add para-virtualization support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/2014 05:35 AM, Peter Zijlstra wrote:
> On Wed, Oct 29, 2014 at 04:19:09PM -0400, Waiman Long wrote:
>>   arch/x86/include/asm/pvqspinlock.h    |  411 +++++++++++++++++++++++++++++++++
> I do wonder why all this needs to live in x86..
>

I haven't looked into the para-virtualization code in other 
architectures to see if my PV code is equally applicable there. That is 
why I put it under the x86 directory. If other architectures decide to 
use qspinlock with paravirtualization, we may need to pull out some 
common code, if any, back to kernel/locking.

>>
>> +#ifdef CONFIG_QUEUE_SPINLOCK
>> +
>> +static __always_inline void pv_kick_cpu(int cpu)
>> +{
>> +	PVOP_VCALLEE1(pv_lock_ops.kick_cpu, cpu);
>> +}
>> +
>> +static __always_inline void pv_lockwait(u8 *lockbyte)
>> +{
>> +	PVOP_VCALLEE1(pv_lock_ops.lockwait, lockbyte);
>> +}
>> +
>> +static __always_inline void pv_lockstat(enum pv_lock_stats type)
>> +{
>> +	PVOP_VCALLEE1(pv_lock_ops.lockstat, type);
>> +}
> Why are any of these PV ops? they're only called from other pv_*()
> functions. What's the point of pv ops you only call from pv code?

It is the same reason that you made them PV ops in your patch. Even when 
PV is on, the code won't need to call any of the PV ops most of the 
time. So it is just a matter of optimizing the most common case at the 
expense of performance in the rare case that the CPU need to be halt and 
woken up which will be bad performance-wise anyway However, if you think 
they should be regular function pointers, I am fine with that too.

>> +/*
>> + *	Queue Spinlock Para-Virtualization (PV) Support
>> + *
>> + * The PV support code for queue spinlock is roughly the same as that
>> + * of the ticket spinlock.
> Relative comments are bad, esp. since we'll make the ticket code go away
> if this works, at which point this is a reference into a black hole.

Thank for the suggestion, I will remove that when I need to revise the 
patch.

>>                              Each CPU waiting for the lock will spin until it
>> + * reaches a threshold. When that happens, it will put itself to a halt state
>> + * so that the hypervisor can reuse the CPU cycles in some other guests as
>> + * well as returning other hold-up CPUs faster.
>
>
>
>> +/**
>> + * queue_spin_lock - acquire a queue spinlock
>> + * @lock: Pointer to queue spinlock structure
>> + *
>> + * N.B. INLINE_SPIN_LOCK should not be enabled when PARAVIRT_SPINLOCK is on.
> One should write a compile time fail for that, not a comment.

Will do that.

>> + */
>> +static __always_inline void queue_spin_lock(struct qspinlock *lock)
>> +{
>> +	u32 val;
>> +
>> +	val = atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL);
>> +	if (likely(val == 0))
>> +		return;
>> +	if (static_key_false(&paravirt_spinlocks_enabled))
>> +		pv_queue_spin_lock_slowpath(lock, val);
>> +	else
>> +		queue_spin_lock_slowpath(lock, val);
>> +}
> No, this is just vile.. _that_ is what we have PV ops for. And at that
> point its the same function it was before the PV stuff, so that whole
> inline thing is then gone.

I did that because in all the architectures except s390, the lock 
functions are not inlined. They live in the _raw_spin_lock* defined in 
kernel/locking/spinlock.c. The unlock functions, on the other hand, are 
all inlined except when PV spinlock is enabled. So adding a check for 
the jump label won't change any of the status quo.

>> +extern void queue_spin_unlock_slowpath(struct qspinlock *lock);
>> +
>>   /**
>>    * queue_spin_unlock - release a queue spinlock
>>    * @lock : Pointer to queue spinlock structure
>>    *
>>    * An effective smp_store_release() on the least-significant byte.
>> + *
>> + * Inlining of the unlock function is disabled when CONFIG_PARAVIRT_SPINLOCKS
>> + * is defined. So _raw_spin_unlock() will be the only call site that will
>> + * have to be patched.
> again if you hard rely on the not inlining make a build fail not a
> comment.

Will do that.

>>    */
>>   static inline void queue_spin_unlock(struct qspinlock *lock)
>>   {
>>   	barrier();
>> +	if (!static_key_false(&paravirt_spinlocks_enabled)) {
>> +		native_spin_unlock(lock);
>> +		return;
>> +	}
>>
>> +	/*
>> +	 * Need to atomically clear the lock byte to avoid racing with
>> +	 * queue head waiter trying to set _QLOCK_LOCKED_SLOWPATH.
>> +	 */
>> +	if (unlikely(cmpxchg((u8 *)lock, _Q_LOCKED_VAL, 0) != _Q_LOCKED_VAL))
>> +		queue_spin_unlock_slowpath(lock);
>> +}
> Idem, that static key stuff is wrong, use PV ops to switch between
> unlock paths.

As said in my previous emails, the PV ops call site patching code 
doesn't work well with locking. First of all, the native_patch() 
function was called even in a KVM PV guest. Some unlock calls happened 
before the paravirt_spinlocks_enabled jump label was set up. It occurs 
to me that call site patching is done the first time the call site is 
used. At least for those early unlock calls, there is no way to figure 
out if it should use the native fast path or the PV slow path. The only 
possible workaround that I can think of is to use a variable (if 
available) that signal the end of the bootup init phase, we can then 
defer the call site patching until the init phase has passed.

This is a rather complicated solution which may not worth the slight 
benefit of a faster unlock call in the native case.

>> @@ -354,7 +394,7 @@ queue:
>>   	 * if there was a previous node; link it and wait until reaching the
>>   	 * head of the waitqueue.
>>   	 */
>> -	if (old&  _Q_TAIL_MASK) {
>> +	if (!pv_link_and_wait_node(old, node)&&  (old&  _Q_TAIL_MASK)) {
>>   		prev = decode_tail(old);
>>   		ACCESS_ONCE(prev->next) = node;
>> @@ -369,9 +409,11 @@ queue:
>>   	 *
>>   	 * *,x,y ->  *,0,0
>>   	 */
>> -	while ((val = smp_load_acquire(&lock->val.counter))&
>> -			_Q_LOCKED_PENDING_MASK)
>> +	val = pv_wait_head(lock, node);
>> +	while (val&  _Q_LOCKED_PENDING_MASK) {
>>   		cpu_relax();
>> +		val = smp_load_acquire(&lock->val.counter);
>> +	}
>>
>>   	/*
>>   	 * claim the lock:
> Please make the pv_*() calls return void and reduce to NOPs. This keeps
> the logic invariant of the pv stuff.

In my patch, the two pv_*() calls above serve as replacements of the 
waiting code. Making them return void and reduce to NOPs will cause what 
Konrad said doing the same operation twice which is not ideal from a 
performance point of view for the PV version. Is putting the pre-PV code 
in the comment help to clarify what the code should be before the PV stuff?

-Longman


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 21:47:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 21:47:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlPSV-0000RI-FT; Mon, 03 Nov 2014 21:46:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XlPST-0000RD-LR
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 21:46:42 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	68/74-09842-1C7F7545; Mon, 03 Nov 2014 21:46:41 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415051197!12506361!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10722 invoked from network); 3 Nov 2014 21:46:38 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 21:46:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415051196; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : Subject :
	Content-Type : Content-Transfer-Encoding;
	bh=ZSGHHqwB2QH/GciVnHKnVA22UyuXf8876T5yo4SjSKA=;
	b=sJEr0coAyQUdE0WqeLXbM3+nCWJiFsvXes+Vmq+Pfr4ViKr1Y+0YgzB1ewXV15SX05ypkNbzNptXrC9aSa1uY9PNC4JO+xrPn3yqEDdqdEy0NnmfNz8U26WKxXMO95fFfqWlxQLv6DbL0miWV5dTpNT/7fwU8USWRE1SxskqOIM=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 03 Nov 2014 13:46:36 -0800
	id 00000000000305F3.5457F7BC.00004DE9
Message-ID: <5457F79B.2020300@ihonk.com>
Date: Mon, 03 Nov 2014 13:46:03 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

I've got a Windows 7 x64 VM that is stable on 4.4.1 but crashes the host 
after a few hours on 4.5rc1. The machine is a ThinkStation D20, an X5660 
with 5500-series chipset with an Nvidia Quadro FX4800 (genuine) passed 
through. Distro is Debian Jessie running stock distro kernel and 
seabios. Both 4.4.1 and 4.5rc1 were built from source. Apologies if this 
issue has already been spotted but I can't keep up with the traffic on 
this list! :-)

It looks as if something is stepping on PCI devices when the crash 
happens. In the log included below, it's the SATA system that's 
complaining but I've seen it hit the ethernet chip first, then SATA 
after that. I'm happy to troubleshoot, apply patches, give more 
information, etc.

I've seen the crash when running Windows Update, when running the 
Unigine graphics benchmark, when running an Avast anti-virus scan. 
Haven't found a common thread.

Don, one curious thing I noted which may be of no value whatsoever: 
Under 4.4.1, I can't give the VM > 3.5 gigs of RAM without breaking VGA 
passthrough. Under 4.5rc1 I can give the VM more than 3.5 gigs, yet I 
*don't* need to use the "mmio_hole" settings in the VM config. Not sure 
why or what that might signify, if anything.

Possibly useful information follows.

Thanks,

Steve

===================

windows_vm.cfg:

builder='hvm'
memory = 3584
vcpus = 6
shadow_memory = 64
name = "clippy2"
vif = [ 'bridge=br0, mac=00:16:3f:7a:d0:85' ]
acpi = 1
apic = 1
disk = [ 'phy:/dev/vg_g2/wintest,hda,w', 
'file:/home/steve/X17-59465.iso,hdc:cdrom,r' ]
gfx_passthru=0
pci = ['02:00.0']
viridian = 1
localtime=1
boot="cd"
usb=1
usbdevice=['tablet', 'host:17ef:6009']
vnc=1
vnclisten="10.0.0.21"
vncconsole=0
vncpasswd=''
serial='pty'

root@g2:~# xl info
host                   : g2
release                : 3.16-3-amd64
version                : #1 SMP Debian 3.16.5-1 (2014-10-10)
machine                : x86_64
nr_cpus                : 6
max_cpu_id             : 5
nr_nodes               : 1
cores_per_socket       : 6
threads_per_core       : 1
cpu_mhz                : 2800
hw_caps                : 
bfebfbff:2c100800:00000000:00003f00:029ee3ff:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 49143
free_memory            : 754
sharing_freed_memory   : 0
sharing_used_memory    : 0
outstanding_claims     : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 5
xen_extra              : -rc1
xen_version            : 4.5-rc1
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          : Fri Oct 24 10:22:40 2014 -0400 git:1b068a5
xen_commandline        : placeholder cpufreq=xen:ondemand cpuidle 
clocksource=hpet log_lvl=all guest_loglvl=all xen-pciback.hide=(02:00.0) 
iommu=no-intremap
cc_compiler            : gcc (Debian 4.9.1-16) 4.9.1
cc_compile_by          : steve
cc_compile_domain      :
cc_compile_date        : Thu Oct 30 15:43:54 PDT 2014
xend_config_format     : 4

(Note that the hide command in the xen_commandline is a no-op because 
xen is compiled in this kernel as modules.)

root@g2:~# xl dmesg
  Xen 4.5-rc1
(XEN) Xen version 4.5-rc1 (steve@) (gcc (Debian 4.9.1-16) 4.9.1) debug=y 
Thu Oct 30 15:43:54 PDT 2014
(XEN) Latest ChangeSet: Fri Oct 24 10:22:40 2014 -0400 git:1b068a5
(XEN) Bootloader: GRUB 2.02~beta2-15
(XEN) Command line: placeholder cpufreq=xen:ondemand cpuidle 
clocksource=hpet log_lvl=all guest_loglvl=all xen-pciback.hide=(02:00.0) 
iommu=no-intremap
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 2 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009a800 (usable)
(XEN)  000000000009a800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf7a0000 (usable)
(XEN)  00000000bf7a0000 - 00000000bf7ca000 (ACPI data)
(XEN)  00000000bf7ca000 - 00000000bf7cc000 (ACPI NVS)
(XEN)  00000000bf7cc000 - 00000000c0000000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000F6A40, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT BF7BF38F, 0084 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: FACP BF7C98D1, 00F4 (r3 LENOVO TC-61     60400D0 PTL         2)
(XEN) ACPI: DSDT BF7BF413, A43A (r1 LENOVO TC-61     60400D0 MSFT 100000E)
(XEN) ACPI: FACS BF7CBFC0, 0040
(XEN) ACPI: SSDT BF7AF33B, 2694 (r1  INTEL PPM RCM  80000001 INTL 20061109)
(XEN) ACPI: SLIT BF7C99E9, 0030 (r1 Intel  TYLERBRG  60400D0 LOHR       5A)
(XEN) ACPI: TCPA BF7C9A19, 0032 (r1 LENOVO TC-61     60400D0 PTL         0)
(XEN) ACPI: SLIC BF7C9A4B, 0176 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: SRAT BF7C9BC1, 00E0 (r1 Intel  Tylerbrg  60400D0 PHX.        1)
(XEN) ACPI: DMAR BF7C9CA1, 01C0 (r1 Intel  OEMDMAR   60400D0 LOHR        1)
(XEN) ACPI: APIC BF7C9E61, 00A0 (r1 PTLTD       APIC    60400D0 
LTP        0)
(XEN) ACPI: MCFG BF7C9F01, 003C (r1 PTLTD    MCFG    60400D0 LTP        0)
(XEN) ACPI: HPET BF7C9F3D, 0038 (r1 PTLTD  HPETTBL   60400D0 LTP        1)
(XEN) ACPI: BOOT BF7C9F75, 0028 (r1 PTLTD  $SBFTBL$  60400D0 LTP        1)
(XEN) ACPI: ASF! BF7C9F9D, 0063 (r32 LENOVO TC-61     60400D0 PTL         1)
(XEN) System RAM: 49143MB (50322664kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: Node 0 PXM 0 0-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-c40000000
(XEN) NUMA: Using 20 for the hash shift.
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000f6a70
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1008
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1004,1:0], pm1x_evt[1:1000,1:0]
(XEN) ACPI:             wakeup_vec[bf7cbfcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(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: 0x8086a301 base: 0xfed00000
(XEN) ERST table was not found
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 6 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 1144 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2800.195 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) alt table ffff82d0802d5e90 -> ffff82d0802d6eb0
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 09
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-09
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB.
(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 not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping disabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 64 KiB.
(XEN) mwait-idle: MWAIT substates: 0x1120
(XEN) mwait-idle: v0.4 model 0x2c
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 6 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x7c8000
(XEN) elf_parse_binary: phdr: paddr=0x1800000 memsz=0xed000
(XEN) elf_parse_binary: phdr: paddr=0x18ed000 memsz=0x14f40
(XEN) elf_parse_binary: phdr: paddr=0x1902000 memsz=0x614000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x1f16000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff819021f0
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = 
"!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
(XEN) elf_xen_parse_note: SUPPORTED_FEATURES = 0x90d
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff81f16000
(XEN)     virt_entry       = 0xffffffff819021f0
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f16000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c00000000->0000000c10000000 (12316671 pages 
to be allocated)
(XEN)  Init. ramdisk: 0000000c3f0da000->0000000c3ffff86e
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81f16000
(XEN)  Init. ramdisk: ffffffff81f16000->ffffffff82e3b86e
(XEN)  Phys-Mach map: ffffffff82e3c000->ffffffff88cbb928
(XEN)  Start info:    ffffffff88cbc000->ffffffff88cbc4b4
(XEN)  Page tables:   ffffffff88cbd000->ffffffff88d08000
(XEN)  Boot stack:    ffffffff88d08000->ffffffff88d09000
(XEN)  TOTAL:         ffffffff80000000->ffffffff89000000
(XEN)  ENTRY ADDRESS: ffffffff819021f0
(XEN) Dom0 has maximum 6 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff817c8000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81800000 -> 0xffffffff818ed000
(XEN) elf_load_binary: phdr 2 at 0xffffffff818ed000 -> 0xffffffff81901f40
(XEN) elf_load_binary: phdr 3 at 0xffffffff81902000 -> 0xffffffff81a1f000
(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) Scrubbing Free RAM on 1 nodes using 6 CPUs
(XEN) 
..................................................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch 
input to Xen)
(XEN) Freed 304kB init memory.
(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) PCI add device 0000:00:00.0
(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) PCI add device 0000:00:01.0
(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) PCI add device 0000:00:03.0
(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) PCI add device 0000:00:07.0
(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:14.1
(XEN) PCI add device 0000:00:14.2
(XEN) PCI add device 0000:00:16.0
(XEN) PCI add device 0000:00:16.1
(XEN) PCI add device 0000:00:16.2
(XEN) PCI add device 0000:00:16.3
(XEN) PCI add device 0000:00:16.4
(XEN) PCI add device 0000:00:16.5
(XEN) PCI add device 0000:00:16.6
(XEN) PCI add device 0000:00:16.7
(XEN) PCI add device 0000:00:1a.0
(XEN) PCI add device 0000:00:1a.1
(XEN) PCI add device 0000:00:1a.7
(XEN) PCI add device 0000:00:1b.0
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.4
(XEN) PCI add device 0000:00:1c.5
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN) PCI add device 0000:00:1d.2
(XEN) PCI add device 0000:00:1d.3
(XEN) PCI add device 0000:00:1d.7
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:01:00.0
(XEN) PCI add device 0000:02:00.0
(XEN) PCI add device 0000:05:00.0
(XEN) PCI add device 0000:06:00.0
(XEN) PCI add device 0000:07:02.0
(XEN) PCI add device 0000:07:03.0
(XEN) PCI add device 0000:09:00.0
(XEN) PCI add device 0000:0a:0e.0
(d1) HVM Loader
(d1) Detected Xen v4.5-rc1
(d1) Xenbus rings @0xfeffc000, event channel 1
(d1) System requested SeaBIOS
(d1) CPU speed is 2800 MHz
(d1) Relocating guest memory for lowmem MMIO space disabled
(XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5
(d1) PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10
(d1) PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11
(d1) PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5
(d1) PCI-ISA link 3 routed to IRQ5
(d1) pci dev 01:2 INTD->IRQ5
(d1) pci dev 01:3 INTA->IRQ10
(d1) pci dev 02:0 INTA->IRQ11
(d1) pci dev 04:0 INTA->IRQ5
(d1) pci dev 05:0 INTA->IRQ10
(d1) No RAM in high memory; setting high_mem resource base to 100000000
(d1) pci dev 05:0 bar 14 size 010000000: 0e000000c
(XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000
(d1) pci dev 03:0 bar 10 size 002000000: 0f0000008
(XEN) memory_map:add: dom1 gfn=f2000 mfn=e8000 nr=2000
(d1) pci dev 05:0 bar 1c size 002000000: 0f2000004
(d1) pci dev 02:0 bar 14 size 001000000: 0f4000008
(XEN) memory_map:add: dom1 gfn=f5000 mfn=ea000 nr=1000
(d1) pci dev 05:0 bar 10 size 001000000: 0f5000000
(d1) pci dev 05:0 bar 30 size 000080000: 0f6000000
(d1) pci dev 04:0 bar 30 size 000040000: 0f6080000
(d1) pci dev 03:0 bar 30 size 000010000: 0f60c0000
(d1) pci dev 03:0 bar 14 size 000001000: 0f60d0000
(d1) pci dev 02:0 bar 10 size 000000100: 00000c001
(d1) pci dev 04:0 bar 10 size 000000100: 00000c101
(d1) pci dev 04:0 bar 14 size 000000100: 0f60d1000
(d1) pci dev 05:0 bar 24 size 000000080: 00000c201
(XEN) ioport_map:add: dom1 gport=c200 mport=3000 nr=80
(d1) pci dev 01:2 bar 20 size 000000020: 00000c281
(d1) pci dev 01:1 bar 20 size 000000010: 00000c2a1
(d1) Multiprocessor initialisation:
(d1)  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1)  - CPU1 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1)  - CPU2 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1)  - CPU3 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1)  - CPU4 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1)  - CPU5 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1) Testing HVM environment:
(d1)  - REP INSB across page boundaries ... passed
(d1)  - GS base MSRs and SWAPGS ... passed
(d1) Passed 2 of 2 tests
(d1) Writing SMBIOS tables ...
(d1) Loading SeaBIOS ...
(d1) Creating MP tables ...
(d1) Loading ACPI ...
(d1) vm86 TSS at fc00a280
(d1) BIOS map:
(d1)  10000-100d3: Scratch space
(d1)  c0000-fffff: Main BIOS
(d1) E820 table:
(d1)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
(d1)  HOLE: 00000000:000a0000 - 00000000:000c0000
(d1)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
(d1)  [02]: 00000000:00100000 - 00000000:df800000: RAM
(d1)  HOLE: 00000000:df800000 - 00000000:fc000000
(d1)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
(d1) Invoking SeaBIOS ...
(d1) SeaBIOS (version rel-1.7.5-0-ge51488c-20141030_133131-g2)
(d1)
(d1) Found Xen hypervisor signature at 40000100
(d1) Running on QEMU (i440fx)
(d1) xen: copy e820...
(d1) Relocating init from 0x000e05e9 to 0xdf7af370 (size 68548)
(d1) CPU Mhz=2801
(d1) Found 9 PCI devices (max PCI bus is 00)
(d1) Allocated Xen hypercall page at df7ff000
(d1) Detected Xen v4.5-rc1
(d1) xen: copy BIOS tables...
(d1) Copying SMBIOS entry point from 0x00010010 to 0x000f1190
(d1) Copying MPTABLE from 0xfc001200/fc001210 to 0x000f1040
(d1) Copying PIR from 0x00010030 to 0x000f0fc0
(d1) Copying ACPI RSDP from 0x000100b0 to 0x000f0f90
(d1) Using pmtimer, ioport 0xb008
(d1) Scan for VGA option rom
(d1) Running option rom at c000:0003
(XEN) stdvga.c:147:d1v0 entering stdvga and caching modes
(d1) pmm call arg1=0
(d1) Turning on vga text mode console
(d1) SeaBIOS (version rel-1.7.5-0-ge51488c-20141030_133131-g2)
(d1) Machine UUID aa695d3e-9592-4139-929c-5d2857702fa9
(d1) UHCI init on dev 00:01.2 (io=c280)
(d1) Found 0 lpt ports
(d1) Found 1 serial ports
(d1) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
(d1) ATA controller 2 at 170/374/0 (irq 15 dev 9)
(d1) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (61440 MiBytes)
(d1) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
(d1) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
(d1) Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
(d1) PS2 keyboard initialized
(d1) USB keyboard initialized
(d1) Initialized USB HUB (1 ports used)
(d1) All threads complete.
(d1) Scan for option roms
(d1) Running option rom at c980:0003
(d1) pmm call arg1=1
(d1) pmm call arg1=0
(d1) pmm call arg1=1
(d1) pmm call arg1=0
(d1) Searching bootorder for: /pci@i0cf8/*@4
(d1)
(d1) Press F12 for boot menu.
(d1)
(d1) Searching bootorder for: HALT
(d1) drive 0x000f0f40: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 
s=125829120
(d1)
(d1) Space available for UMB: ca800-ee800, f0000-f0ee0
(d1) Returned 249856 bytes of ZoneHigh
(d1) e820 map has 6 items:
(d1)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
(d1)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
(d1)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
(d1)   3: 0000000000100000 - 00000000df7fd000 = 1 RAM
(d1)   4: 00000000df7fd000 - 00000000df800000 = 2 RESERVED
(d1)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
(d1) enter handle_19:
(d1)   NULL
(d1) Booting from Hard Disk...
(d1) Booting from 0000:7c00
(XEN) stdvga.c:151:d1v0 leaving stdvga
(XEN) d1: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 1 
build: 1db1
(XEN) d1: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
(XEN) d1v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
(XEN) d1v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
(XEN) d1v2: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffc
(XEN) d1v3: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffb
(XEN) d1v4: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffa
(XEN) d1v5: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fff9
(XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0
(XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0
(XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0
(XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0
(XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:remove: dom1 gfn=f2000 mfn=e8000 nr=2000
(XEN) memory_map:remove: dom1 gfn=f5000 mfn=ea000 nr=1000
(XEN) ioport_map:remove: dom1 gport=c200 mport=3000 nr=80
(XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:add: dom1 gfn=f2000 mfn=e8000 nr=2000
(XEN) memory_map:add: dom1 gfn=f5000 mfn=ea000 nr=1000
(XEN) ioport_map:add: dom1 gport=c200 mport=3000 nr=80
(XEN) grant_table.c:1272:d1v2 Expanding dom (1) grant table from (4) to 
(32) frames.
(XEN) irq.c:380: Dom1 callback via changed to GSI 24
(XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:remove: dom1 gfn=f2000 mfn=e8000 nr=2000
(XEN) memory_map:remove: dom1 gfn=f5000 mfn=ea000 nr=1000
(XEN) ioport_map:remove: dom1 gport=c200 mport=3000 nr=80
(XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:add: dom1 gfn=f2000 mfn=e8000 nr=2000
(XEN) memory_map:add: dom1 gfn=f5000 mfn=ea000 nr=1000
(XEN) ioport_map:add: dom1 gport=c200 mport=3000 nr=80
(XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:remove: dom1 gfn=f2000 mfn=e8000 nr=2000
(XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:add: dom1 gfn=f2000 mfn=e8000 nr=2000

root@g2:~# tail -f /var/log/syslog

Nov  2 21:48:38 g2 kernel: [  203.011898] ip_tables: (C) 2000-2006 
Netfilter Core Team
Nov  2 21:48:38 g2 root: /etc/xen/scripts/vif-bridge: Successful 
vif-bridge online for vif1.0, bridge br0.
Nov  2 21:48:38 g2 root: /etc/xen/scripts/vif-bridge: Writing 
backend/vif/1/0/hotplug-status connected to xenstore.
Nov  2 21:48:38 g2 root: /etc/xen/scripts/vif-bridge: add type_if=tap 
XENBUS_PATH=backend/vif/1/0
Nov  2 21:48:38 g2 kernel: [  203.233482] device vif1.0-emu entered 
promiscuous mode
Nov  2 21:48:38 g2 kernel: [  203.236671] br0: port 3(vif1.0-emu) 
entered forwarding state
Nov  2 21:48:38 g2 kernel: [  203.236677] br0: port 3(vif1.0-emu) 
entered forwarding state
Nov  2 21:48:38 g2 root: /etc/xen/scripts/vif-bridge: Successful 
vif-bridge add for vif1.0-emu, bridge br0.
Nov  2 21:48:39 g2 kernel: [  204.651250] xen_pciback: vpci: 
0000:02:00.0: assign to virtual slot 0
Nov  2 21:48:40 g2 kernel: [  205.533377] usb 7-1: reset low-speed USB 
device number 2 using uhci_hcd
Nov  2 21:48:53 g2 kernel: [  218.261360] br0: port 3(vif1.0-emu) 
entered forwarding state
Nov  2 21:49:20 g2 kernel: [  245.379901] xen-blkback:ring-ref 16383, 
event-channel 11, protocol 1 (x86_64-abi)
Nov  2 21:49:26 g2 kernel: [  250.836687] IPv6: ADDRCONF(NETDEV_CHANGE): 
vif1.0: link becomes ready
Nov  2 21:49:26 g2 kernel: [  250.836726] br0: port 2(vif1.0) entered 
forwarding state
Nov  2 21:49:26 g2 kernel: [  250.836732] br0: port 2(vif1.0) entered 
forwarding state
Nov  2 21:49:28 g2 kernel: [  253.485368] usb 7-1: reset low-speed USB 
device number 2 using uhci_hcd
Nov  2 21:49:29 g2 kernel: [  254.101376] usb 7-1: reset low-speed USB 
device number 2 using uhci_hcd
Nov  2 21:49:41 g2 kernel: [  265.845376] br0: port 2(vif1.0) entered 
forwarding state
Nov  2 22:17:01 g2 /USR/SBIN/CRON[2361]: (root) CMD (   cd / && 
run-parts --report /etc/cron.hourly)
Nov  2 23:17:01 g2 /USR/SBIN/CRON[2373]: (root) CMD (   cd / && 
run-parts --report /etc/cron.hourly)
Nov  3 00:00:01 g2 /USR/SBIN/CRON[2387]: (root) CMD (invoke-rc.d atop _cron)
Nov  3 00:17:01 g2 /USR/SBIN/CRON[2423]: (root) CMD (   cd / && 
run-parts --report /etc/cron.hourly)
Nov  3 00:52:02 g2 kernel: [11207.677448] ata3.00: exception Emask 0x0 
SAct 0x1ffc000 SErr 0x0 action 0x6 frozen
Nov  3 00:52:02 g2 kernel: [11207.677512] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.677568] ata3.00: cmd 
61/58:70:90:57:23/00:00:04:00:00/40 tag 14 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.677568]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.677637] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.677686] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.677740] ata3.00: cmd 
61/58:78:e8:57:23/00:00:04:00:00/40 tag 15 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.677740]          res 
40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.677809] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.677857] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.677912] ata3.00: cmd 
61/58:80:40:58:23/00:00:04:00:00/40 tag 16 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.677912]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.677980] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.678029] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.678099] ata3.00: cmd 
61/58:88:98:58:23/00:00:04:00:00/40 tag 17 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.678099]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.678231] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.678295] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.678365] ata3.00: cmd 
61/58:90:f0:58:23/00:00:04:00:00/40 tag 18 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.678365]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.678496] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.678560] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.678631] ata3.00: cmd 
61/58:98:48:59:23/00:00:04:00:00/40 tag 19 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.678631]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.678761] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.678826] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.678896] ata3.00: cmd 
61/58:a0:a0:59:23/00:00:04:00:00/40 tag 20 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.678896]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.679026] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.679090] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.679160] ata3.00: cmd 
61/58:a8:f8:59:23/00:00:04:00:00/40 tag 21 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.679160]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.679291] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.679355] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.679425] ata3.00: cmd 
61/58:b0:50:5a:23/00:00:04:00:00/40 tag 22 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.679425]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.679556] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.679620] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.679690] ata3.00: cmd 
61/58:b8:a8:5a:23/00:00:04:00:00/40 tag 23 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.679690]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.679821] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.679886] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.679955] ata3.00: cmd 
61/18:c0:00:5b:23/00:00:04:00:00/40 tag 24 ncq 12288 out
Nov  3 00:52:02 g2 kernel: [11207.679955]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.680090] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.680157] ata3: hard resetting link
Nov  3 00:52:02 g2 kernel: [11207.680170] ata1.00: exception Emask 0x0 
SAct 0x3ff800 SErr 0x0 action 0x6 frozen
Nov  3 00:52:02 g2 kernel: [11207.680262] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.680333] ata1.00: cmd 
61/58:58:90:57:23/00:00:04:00:00/40 tag 11 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.680333]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.680465] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.680530] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.680600] ata1.00: cmd 
61/58:60:e8:57:23/00:00:04:00:00/40 tag 12 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.680600]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.680732] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.680796] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.680866] ata1.00: cmd 
61/58:68:40:58:23/00:00:04:00:00/40 tag 13 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.680866]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.680998] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.681062] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.681132] ata1.00: cmd 
61/58:70:98:58:23/00:00:04:00:00/40 tag 14 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.681132]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.681264] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.681353] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.681428] ata1.00: cmd 
61/58:78:f0:58:23/00:00:04:00:00/40 tag 15 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.681428]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.681562] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.681627] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.681698] ata1.00: cmd 
61/58:80:48:59:23/00:00:04:00:00/40 tag 16 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.681698]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.681830] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.681895] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.681965] ata1.00: cmd 
61/58:88:a0:59:23/00:00:04:00:00/40 tag 17 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.681965]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.682096] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.682161] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.682232] ata1.00: cmd 
61/58:90:f8:59:23/00:00:04:00:00/40 tag 18 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.682232]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.682363] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.682428] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.682498] ata1.00: cmd 
61/58:98:50:5a:23/00:00:04:00:00/40 tag 19 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.682498]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.682630] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.682695] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.682765] ata1.00: cmd 
61/58:a0:a8:5a:23/00:00:04:00:00/40 tag 20 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.682765]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.682897] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.682961] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.683032] ata1.00: cmd 
61/18:a8:00:5b:23/00:00:04:00:00/40 tag 21 ncq 12288 out
Nov  3 00:52:02 g2 kernel: [11207.683032]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.683163] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.683229] ata1: hard resetting link
Write failed: Broken pipe

(I was monitoring syslog over a network connection since nothing of 
value can be saved to disk under the circumstances.)

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 21:47:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 21:47:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlPSV-0000RI-FT; Mon, 03 Nov 2014 21:46:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XlPST-0000RD-LR
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 21:46:42 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	68/74-09842-1C7F7545; Mon, 03 Nov 2014 21:46:41 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415051197!12506361!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10722 invoked from network); 3 Nov 2014 21:46:38 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Nov 2014 21:46:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415051196; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : Subject :
	Content-Type : Content-Transfer-Encoding;
	bh=ZSGHHqwB2QH/GciVnHKnVA22UyuXf8876T5yo4SjSKA=;
	b=sJEr0coAyQUdE0WqeLXbM3+nCWJiFsvXes+Vmq+Pfr4ViKr1Y+0YgzB1ewXV15SX05ypkNbzNptXrC9aSa1uY9PNC4JO+xrPn3yqEDdqdEy0NnmfNz8U26WKxXMO95fFfqWlxQLv6DbL0miWV5dTpNT/7fwU8USWRE1SxskqOIM=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 03 Nov 2014 13:46:36 -0800
	id 00000000000305F3.5457F7BC.00004DE9
Message-ID: <5457F79B.2020300@ihonk.com>
Date: Mon, 03 Nov 2014 13:46:03 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

I've got a Windows 7 x64 VM that is stable on 4.4.1 but crashes the host 
after a few hours on 4.5rc1. The machine is a ThinkStation D20, an X5660 
with 5500-series chipset with an Nvidia Quadro FX4800 (genuine) passed 
through. Distro is Debian Jessie running stock distro kernel and 
seabios. Both 4.4.1 and 4.5rc1 were built from source. Apologies if this 
issue has already been spotted but I can't keep up with the traffic on 
this list! :-)

It looks as if something is stepping on PCI devices when the crash 
happens. In the log included below, it's the SATA system that's 
complaining but I've seen it hit the ethernet chip first, then SATA 
after that. I'm happy to troubleshoot, apply patches, give more 
information, etc.

I've seen the crash when running Windows Update, when running the 
Unigine graphics benchmark, when running an Avast anti-virus scan. 
Haven't found a common thread.

Don, one curious thing I noted which may be of no value whatsoever: 
Under 4.4.1, I can't give the VM > 3.5 gigs of RAM without breaking VGA 
passthrough. Under 4.5rc1 I can give the VM more than 3.5 gigs, yet I 
*don't* need to use the "mmio_hole" settings in the VM config. Not sure 
why or what that might signify, if anything.

Possibly useful information follows.

Thanks,

Steve

===================

windows_vm.cfg:

builder='hvm'
memory = 3584
vcpus = 6
shadow_memory = 64
name = "clippy2"
vif = [ 'bridge=br0, mac=00:16:3f:7a:d0:85' ]
acpi = 1
apic = 1
disk = [ 'phy:/dev/vg_g2/wintest,hda,w', 
'file:/home/steve/X17-59465.iso,hdc:cdrom,r' ]
gfx_passthru=0
pci = ['02:00.0']
viridian = 1
localtime=1
boot="cd"
usb=1
usbdevice=['tablet', 'host:17ef:6009']
vnc=1
vnclisten="10.0.0.21"
vncconsole=0
vncpasswd=''
serial='pty'

root@g2:~# xl info
host                   : g2
release                : 3.16-3-amd64
version                : #1 SMP Debian 3.16.5-1 (2014-10-10)
machine                : x86_64
nr_cpus                : 6
max_cpu_id             : 5
nr_nodes               : 1
cores_per_socket       : 6
threads_per_core       : 1
cpu_mhz                : 2800
hw_caps                : 
bfebfbff:2c100800:00000000:00003f00:029ee3ff:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 49143
free_memory            : 754
sharing_freed_memory   : 0
sharing_used_memory    : 0
outstanding_claims     : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 5
xen_extra              : -rc1
xen_version            : 4.5-rc1
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          : Fri Oct 24 10:22:40 2014 -0400 git:1b068a5
xen_commandline        : placeholder cpufreq=xen:ondemand cpuidle 
clocksource=hpet log_lvl=all guest_loglvl=all xen-pciback.hide=(02:00.0) 
iommu=no-intremap
cc_compiler            : gcc (Debian 4.9.1-16) 4.9.1
cc_compile_by          : steve
cc_compile_domain      :
cc_compile_date        : Thu Oct 30 15:43:54 PDT 2014
xend_config_format     : 4

(Note that the hide command in the xen_commandline is a no-op because 
xen is compiled in this kernel as modules.)

root@g2:~# xl dmesg
  Xen 4.5-rc1
(XEN) Xen version 4.5-rc1 (steve@) (gcc (Debian 4.9.1-16) 4.9.1) debug=y 
Thu Oct 30 15:43:54 PDT 2014
(XEN) Latest ChangeSet: Fri Oct 24 10:22:40 2014 -0400 git:1b068a5
(XEN) Bootloader: GRUB 2.02~beta2-15
(XEN) Command line: placeholder cpufreq=xen:ondemand cpuidle 
clocksource=hpet log_lvl=all guest_loglvl=all xen-pciback.hide=(02:00.0) 
iommu=no-intremap
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 2 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009a800 (usable)
(XEN)  000000000009a800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf7a0000 (usable)
(XEN)  00000000bf7a0000 - 00000000bf7ca000 (ACPI data)
(XEN)  00000000bf7ca000 - 00000000bf7cc000 (ACPI NVS)
(XEN)  00000000bf7cc000 - 00000000c0000000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000F6A40, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT BF7BF38F, 0084 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: FACP BF7C98D1, 00F4 (r3 LENOVO TC-61     60400D0 PTL         2)
(XEN) ACPI: DSDT BF7BF413, A43A (r1 LENOVO TC-61     60400D0 MSFT 100000E)
(XEN) ACPI: FACS BF7CBFC0, 0040
(XEN) ACPI: SSDT BF7AF33B, 2694 (r1  INTEL PPM RCM  80000001 INTL 20061109)
(XEN) ACPI: SLIT BF7C99E9, 0030 (r1 Intel  TYLERBRG  60400D0 LOHR       5A)
(XEN) ACPI: TCPA BF7C9A19, 0032 (r1 LENOVO TC-61     60400D0 PTL         0)
(XEN) ACPI: SLIC BF7C9A4B, 0176 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: SRAT BF7C9BC1, 00E0 (r1 Intel  Tylerbrg  60400D0 PHX.        1)
(XEN) ACPI: DMAR BF7C9CA1, 01C0 (r1 Intel  OEMDMAR   60400D0 LOHR        1)
(XEN) ACPI: APIC BF7C9E61, 00A0 (r1 PTLTD       APIC    60400D0 
LTP        0)
(XEN) ACPI: MCFG BF7C9F01, 003C (r1 PTLTD    MCFG    60400D0 LTP        0)
(XEN) ACPI: HPET BF7C9F3D, 0038 (r1 PTLTD  HPETTBL   60400D0 LTP        1)
(XEN) ACPI: BOOT BF7C9F75, 0028 (r1 PTLTD  $SBFTBL$  60400D0 LTP        1)
(XEN) ACPI: ASF! BF7C9F9D, 0063 (r32 LENOVO TC-61     60400D0 PTL         1)
(XEN) System RAM: 49143MB (50322664kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: Node 0 PXM 0 0-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-c40000000
(XEN) NUMA: Using 20 for the hash shift.
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000f6a70
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1008
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1004,1:0], pm1x_evt[1:1000,1:0]
(XEN) ACPI:             wakeup_vec[bf7cbfcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(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: 0x8086a301 base: 0xfed00000
(XEN) ERST table was not found
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 6 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 1144 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2800.195 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) alt table ffff82d0802d5e90 -> ffff82d0802d6eb0
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 09
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-09
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB.
(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 not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping disabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 64 KiB.
(XEN) mwait-idle: MWAIT substates: 0x1120
(XEN) mwait-idle: v0.4 model 0x2c
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 6 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x7c8000
(XEN) elf_parse_binary: phdr: paddr=0x1800000 memsz=0xed000
(XEN) elf_parse_binary: phdr: paddr=0x18ed000 memsz=0x14f40
(XEN) elf_parse_binary: phdr: paddr=0x1902000 memsz=0x614000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x1f16000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff819021f0
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = 
"!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
(XEN) elf_xen_parse_note: SUPPORTED_FEATURES = 0x90d
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff81f16000
(XEN)     virt_entry       = 0xffffffff819021f0
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f16000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c00000000->0000000c10000000 (12316671 pages 
to be allocated)
(XEN)  Init. ramdisk: 0000000c3f0da000->0000000c3ffff86e
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81f16000
(XEN)  Init. ramdisk: ffffffff81f16000->ffffffff82e3b86e
(XEN)  Phys-Mach map: ffffffff82e3c000->ffffffff88cbb928
(XEN)  Start info:    ffffffff88cbc000->ffffffff88cbc4b4
(XEN)  Page tables:   ffffffff88cbd000->ffffffff88d08000
(XEN)  Boot stack:    ffffffff88d08000->ffffffff88d09000
(XEN)  TOTAL:         ffffffff80000000->ffffffff89000000
(XEN)  ENTRY ADDRESS: ffffffff819021f0
(XEN) Dom0 has maximum 6 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff817c8000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81800000 -> 0xffffffff818ed000
(XEN) elf_load_binary: phdr 2 at 0xffffffff818ed000 -> 0xffffffff81901f40
(XEN) elf_load_binary: phdr 3 at 0xffffffff81902000 -> 0xffffffff81a1f000
(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) Scrubbing Free RAM on 1 nodes using 6 CPUs
(XEN) 
..................................................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch 
input to Xen)
(XEN) Freed 304kB init memory.
(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) PCI add device 0000:00:00.0
(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) PCI add device 0000:00:01.0
(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) PCI add device 0000:00:03.0
(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) PCI add device 0000:00:07.0
(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:14.1
(XEN) PCI add device 0000:00:14.2
(XEN) PCI add device 0000:00:16.0
(XEN) PCI add device 0000:00:16.1
(XEN) PCI add device 0000:00:16.2
(XEN) PCI add device 0000:00:16.3
(XEN) PCI add device 0000:00:16.4
(XEN) PCI add device 0000:00:16.5
(XEN) PCI add device 0000:00:16.6
(XEN) PCI add device 0000:00:16.7
(XEN) PCI add device 0000:00:1a.0
(XEN) PCI add device 0000:00:1a.1
(XEN) PCI add device 0000:00:1a.7
(XEN) PCI add device 0000:00:1b.0
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.4
(XEN) PCI add device 0000:00:1c.5
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN) PCI add device 0000:00:1d.2
(XEN) PCI add device 0000:00:1d.3
(XEN) PCI add device 0000:00:1d.7
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:01:00.0
(XEN) PCI add device 0000:02:00.0
(XEN) PCI add device 0000:05:00.0
(XEN) PCI add device 0000:06:00.0
(XEN) PCI add device 0000:07:02.0
(XEN) PCI add device 0000:07:03.0
(XEN) PCI add device 0000:09:00.0
(XEN) PCI add device 0000:0a:0e.0
(d1) HVM Loader
(d1) Detected Xen v4.5-rc1
(d1) Xenbus rings @0xfeffc000, event channel 1
(d1) System requested SeaBIOS
(d1) CPU speed is 2800 MHz
(d1) Relocating guest memory for lowmem MMIO space disabled
(XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5
(d1) PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10
(d1) PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11
(d1) PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5
(d1) PCI-ISA link 3 routed to IRQ5
(d1) pci dev 01:2 INTD->IRQ5
(d1) pci dev 01:3 INTA->IRQ10
(d1) pci dev 02:0 INTA->IRQ11
(d1) pci dev 04:0 INTA->IRQ5
(d1) pci dev 05:0 INTA->IRQ10
(d1) No RAM in high memory; setting high_mem resource base to 100000000
(d1) pci dev 05:0 bar 14 size 010000000: 0e000000c
(XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000
(d1) pci dev 03:0 bar 10 size 002000000: 0f0000008
(XEN) memory_map:add: dom1 gfn=f2000 mfn=e8000 nr=2000
(d1) pci dev 05:0 bar 1c size 002000000: 0f2000004
(d1) pci dev 02:0 bar 14 size 001000000: 0f4000008
(XEN) memory_map:add: dom1 gfn=f5000 mfn=ea000 nr=1000
(d1) pci dev 05:0 bar 10 size 001000000: 0f5000000
(d1) pci dev 05:0 bar 30 size 000080000: 0f6000000
(d1) pci dev 04:0 bar 30 size 000040000: 0f6080000
(d1) pci dev 03:0 bar 30 size 000010000: 0f60c0000
(d1) pci dev 03:0 bar 14 size 000001000: 0f60d0000
(d1) pci dev 02:0 bar 10 size 000000100: 00000c001
(d1) pci dev 04:0 bar 10 size 000000100: 00000c101
(d1) pci dev 04:0 bar 14 size 000000100: 0f60d1000
(d1) pci dev 05:0 bar 24 size 000000080: 00000c201
(XEN) ioport_map:add: dom1 gport=c200 mport=3000 nr=80
(d1) pci dev 01:2 bar 20 size 000000020: 00000c281
(d1) pci dev 01:1 bar 20 size 000000010: 00000c2a1
(d1) Multiprocessor initialisation:
(d1)  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1)  - CPU1 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1)  - CPU2 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1)  - CPU3 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1)  - CPU4 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1)  - CPU5 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1) Testing HVM environment:
(d1)  - REP INSB across page boundaries ... passed
(d1)  - GS base MSRs and SWAPGS ... passed
(d1) Passed 2 of 2 tests
(d1) Writing SMBIOS tables ...
(d1) Loading SeaBIOS ...
(d1) Creating MP tables ...
(d1) Loading ACPI ...
(d1) vm86 TSS at fc00a280
(d1) BIOS map:
(d1)  10000-100d3: Scratch space
(d1)  c0000-fffff: Main BIOS
(d1) E820 table:
(d1)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
(d1)  HOLE: 00000000:000a0000 - 00000000:000c0000
(d1)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
(d1)  [02]: 00000000:00100000 - 00000000:df800000: RAM
(d1)  HOLE: 00000000:df800000 - 00000000:fc000000
(d1)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
(d1) Invoking SeaBIOS ...
(d1) SeaBIOS (version rel-1.7.5-0-ge51488c-20141030_133131-g2)
(d1)
(d1) Found Xen hypervisor signature at 40000100
(d1) Running on QEMU (i440fx)
(d1) xen: copy e820...
(d1) Relocating init from 0x000e05e9 to 0xdf7af370 (size 68548)
(d1) CPU Mhz=2801
(d1) Found 9 PCI devices (max PCI bus is 00)
(d1) Allocated Xen hypercall page at df7ff000
(d1) Detected Xen v4.5-rc1
(d1) xen: copy BIOS tables...
(d1) Copying SMBIOS entry point from 0x00010010 to 0x000f1190
(d1) Copying MPTABLE from 0xfc001200/fc001210 to 0x000f1040
(d1) Copying PIR from 0x00010030 to 0x000f0fc0
(d1) Copying ACPI RSDP from 0x000100b0 to 0x000f0f90
(d1) Using pmtimer, ioport 0xb008
(d1) Scan for VGA option rom
(d1) Running option rom at c000:0003
(XEN) stdvga.c:147:d1v0 entering stdvga and caching modes
(d1) pmm call arg1=0
(d1) Turning on vga text mode console
(d1) SeaBIOS (version rel-1.7.5-0-ge51488c-20141030_133131-g2)
(d1) Machine UUID aa695d3e-9592-4139-929c-5d2857702fa9
(d1) UHCI init on dev 00:01.2 (io=c280)
(d1) Found 0 lpt ports
(d1) Found 1 serial ports
(d1) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
(d1) ATA controller 2 at 170/374/0 (irq 15 dev 9)
(d1) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (61440 MiBytes)
(d1) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
(d1) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
(d1) Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
(d1) PS2 keyboard initialized
(d1) USB keyboard initialized
(d1) Initialized USB HUB (1 ports used)
(d1) All threads complete.
(d1) Scan for option roms
(d1) Running option rom at c980:0003
(d1) pmm call arg1=1
(d1) pmm call arg1=0
(d1) pmm call arg1=1
(d1) pmm call arg1=0
(d1) Searching bootorder for: /pci@i0cf8/*@4
(d1)
(d1) Press F12 for boot menu.
(d1)
(d1) Searching bootorder for: HALT
(d1) drive 0x000f0f40: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 
s=125829120
(d1)
(d1) Space available for UMB: ca800-ee800, f0000-f0ee0
(d1) Returned 249856 bytes of ZoneHigh
(d1) e820 map has 6 items:
(d1)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
(d1)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
(d1)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
(d1)   3: 0000000000100000 - 00000000df7fd000 = 1 RAM
(d1)   4: 00000000df7fd000 - 00000000df800000 = 2 RESERVED
(d1)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
(d1) enter handle_19:
(d1)   NULL
(d1) Booting from Hard Disk...
(d1) Booting from 0000:7c00
(XEN) stdvga.c:151:d1v0 leaving stdvga
(XEN) d1: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 1 
build: 1db1
(XEN) d1: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
(XEN) d1v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
(XEN) d1v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
(XEN) d1v2: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffc
(XEN) d1v3: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffb
(XEN) d1v4: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffa
(XEN) d1v5: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fff9
(XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0
(XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0
(XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0
(XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0
(XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:remove: dom1 gfn=f2000 mfn=e8000 nr=2000
(XEN) memory_map:remove: dom1 gfn=f5000 mfn=ea000 nr=1000
(XEN) ioport_map:remove: dom1 gport=c200 mport=3000 nr=80
(XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:add: dom1 gfn=f2000 mfn=e8000 nr=2000
(XEN) memory_map:add: dom1 gfn=f5000 mfn=ea000 nr=1000
(XEN) ioport_map:add: dom1 gport=c200 mport=3000 nr=80
(XEN) grant_table.c:1272:d1v2 Expanding dom (1) grant table from (4) to 
(32) frames.
(XEN) irq.c:380: Dom1 callback via changed to GSI 24
(XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:remove: dom1 gfn=f2000 mfn=e8000 nr=2000
(XEN) memory_map:remove: dom1 gfn=f5000 mfn=ea000 nr=1000
(XEN) ioport_map:remove: dom1 gport=c200 mport=3000 nr=80
(XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:add: dom1 gfn=f2000 mfn=e8000 nr=2000
(XEN) memory_map:add: dom1 gfn=f5000 mfn=ea000 nr=1000
(XEN) ioport_map:add: dom1 gport=c200 mport=3000 nr=80
(XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:remove: dom1 gfn=f2000 mfn=e8000 nr=2000
(XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000
(XEN) memory_map:add: dom1 gfn=f2000 mfn=e8000 nr=2000

root@g2:~# tail -f /var/log/syslog

Nov  2 21:48:38 g2 kernel: [  203.011898] ip_tables: (C) 2000-2006 
Netfilter Core Team
Nov  2 21:48:38 g2 root: /etc/xen/scripts/vif-bridge: Successful 
vif-bridge online for vif1.0, bridge br0.
Nov  2 21:48:38 g2 root: /etc/xen/scripts/vif-bridge: Writing 
backend/vif/1/0/hotplug-status connected to xenstore.
Nov  2 21:48:38 g2 root: /etc/xen/scripts/vif-bridge: add type_if=tap 
XENBUS_PATH=backend/vif/1/0
Nov  2 21:48:38 g2 kernel: [  203.233482] device vif1.0-emu entered 
promiscuous mode
Nov  2 21:48:38 g2 kernel: [  203.236671] br0: port 3(vif1.0-emu) 
entered forwarding state
Nov  2 21:48:38 g2 kernel: [  203.236677] br0: port 3(vif1.0-emu) 
entered forwarding state
Nov  2 21:48:38 g2 root: /etc/xen/scripts/vif-bridge: Successful 
vif-bridge add for vif1.0-emu, bridge br0.
Nov  2 21:48:39 g2 kernel: [  204.651250] xen_pciback: vpci: 
0000:02:00.0: assign to virtual slot 0
Nov  2 21:48:40 g2 kernel: [  205.533377] usb 7-1: reset low-speed USB 
device number 2 using uhci_hcd
Nov  2 21:48:53 g2 kernel: [  218.261360] br0: port 3(vif1.0-emu) 
entered forwarding state
Nov  2 21:49:20 g2 kernel: [  245.379901] xen-blkback:ring-ref 16383, 
event-channel 11, protocol 1 (x86_64-abi)
Nov  2 21:49:26 g2 kernel: [  250.836687] IPv6: ADDRCONF(NETDEV_CHANGE): 
vif1.0: link becomes ready
Nov  2 21:49:26 g2 kernel: [  250.836726] br0: port 2(vif1.0) entered 
forwarding state
Nov  2 21:49:26 g2 kernel: [  250.836732] br0: port 2(vif1.0) entered 
forwarding state
Nov  2 21:49:28 g2 kernel: [  253.485368] usb 7-1: reset low-speed USB 
device number 2 using uhci_hcd
Nov  2 21:49:29 g2 kernel: [  254.101376] usb 7-1: reset low-speed USB 
device number 2 using uhci_hcd
Nov  2 21:49:41 g2 kernel: [  265.845376] br0: port 2(vif1.0) entered 
forwarding state
Nov  2 22:17:01 g2 /USR/SBIN/CRON[2361]: (root) CMD (   cd / && 
run-parts --report /etc/cron.hourly)
Nov  2 23:17:01 g2 /USR/SBIN/CRON[2373]: (root) CMD (   cd / && 
run-parts --report /etc/cron.hourly)
Nov  3 00:00:01 g2 /USR/SBIN/CRON[2387]: (root) CMD (invoke-rc.d atop _cron)
Nov  3 00:17:01 g2 /USR/SBIN/CRON[2423]: (root) CMD (   cd / && 
run-parts --report /etc/cron.hourly)
Nov  3 00:52:02 g2 kernel: [11207.677448] ata3.00: exception Emask 0x0 
SAct 0x1ffc000 SErr 0x0 action 0x6 frozen
Nov  3 00:52:02 g2 kernel: [11207.677512] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.677568] ata3.00: cmd 
61/58:70:90:57:23/00:00:04:00:00/40 tag 14 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.677568]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.677637] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.677686] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.677740] ata3.00: cmd 
61/58:78:e8:57:23/00:00:04:00:00/40 tag 15 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.677740]          res 
40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.677809] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.677857] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.677912] ata3.00: cmd 
61/58:80:40:58:23/00:00:04:00:00/40 tag 16 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.677912]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.677980] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.678029] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.678099] ata3.00: cmd 
61/58:88:98:58:23/00:00:04:00:00/40 tag 17 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.678099]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.678231] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.678295] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.678365] ata3.00: cmd 
61/58:90:f0:58:23/00:00:04:00:00/40 tag 18 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.678365]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.678496] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.678560] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.678631] ata3.00: cmd 
61/58:98:48:59:23/00:00:04:00:00/40 tag 19 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.678631]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.678761] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.678826] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.678896] ata3.00: cmd 
61/58:a0:a0:59:23/00:00:04:00:00/40 tag 20 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.678896]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.679026] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.679090] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.679160] ata3.00: cmd 
61/58:a8:f8:59:23/00:00:04:00:00/40 tag 21 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.679160]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.679291] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.679355] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.679425] ata3.00: cmd 
61/58:b0:50:5a:23/00:00:04:00:00/40 tag 22 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.679425]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.679556] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.679620] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.679690] ata3.00: cmd 
61/58:b8:a8:5a:23/00:00:04:00:00/40 tag 23 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.679690]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.679821] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.679886] ata3.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.679955] ata3.00: cmd 
61/18:c0:00:5b:23/00:00:04:00:00/40 tag 24 ncq 12288 out
Nov  3 00:52:02 g2 kernel: [11207.679955]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.680090] ata3.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.680157] ata3: hard resetting link
Nov  3 00:52:02 g2 kernel: [11207.680170] ata1.00: exception Emask 0x0 
SAct 0x3ff800 SErr 0x0 action 0x6 frozen
Nov  3 00:52:02 g2 kernel: [11207.680262] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.680333] ata1.00: cmd 
61/58:58:90:57:23/00:00:04:00:00/40 tag 11 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.680333]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.680465] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.680530] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.680600] ata1.00: cmd 
61/58:60:e8:57:23/00:00:04:00:00/40 tag 12 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.680600]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.680732] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.680796] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.680866] ata1.00: cmd 
61/58:68:40:58:23/00:00:04:00:00/40 tag 13 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.680866]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.680998] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.681062] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.681132] ata1.00: cmd 
61/58:70:98:58:23/00:00:04:00:00/40 tag 14 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.681132]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.681264] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.681353] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.681428] ata1.00: cmd 
61/58:78:f0:58:23/00:00:04:00:00/40 tag 15 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.681428]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.681562] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.681627] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.681698] ata1.00: cmd 
61/58:80:48:59:23/00:00:04:00:00/40 tag 16 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.681698]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.681830] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.681895] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.681965] ata1.00: cmd 
61/58:88:a0:59:23/00:00:04:00:00/40 tag 17 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.681965]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.682096] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.682161] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.682232] ata1.00: cmd 
61/58:90:f8:59:23/00:00:04:00:00/40 tag 18 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.682232]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.682363] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.682428] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.682498] ata1.00: cmd 
61/58:98:50:5a:23/00:00:04:00:00/40 tag 19 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.682498]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.682630] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.682695] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.682765] ata1.00: cmd 
61/58:a0:a8:5a:23/00:00:04:00:00/40 tag 20 ncq 45056 out
Nov  3 00:52:02 g2 kernel: [11207.682765]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.682897] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.682961] ata1.00: failed command: WRITE 
FPDMA QUEUED
Nov  3 00:52:02 g2 kernel: [11207.683032] ata1.00: cmd 
61/18:a8:00:5b:23/00:00:04:00:00/40 tag 21 ncq 12288 out
Nov  3 00:52:02 g2 kernel: [11207.683032]          res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  3 00:52:02 g2 kernel: [11207.683163] ata1.00: status: { DRDY }
Nov  3 00:52:02 g2 kernel: [11207.683229] ata1: hard resetting link
Write failed: Broken pipe

(I was monitoring syslog over a network connection since nothing of 
value can be saved to disk under the circumstances.)

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 21:53:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 21: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 1XlPZ5-0000i0-Kl; Mon, 03 Nov 2014 21:53:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XlPZ4-0000hv-Jr
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 21:53:30 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	8C/3A-26652-959F7545; Mon, 03 Nov 2014 21:53:29 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415051607!6847757!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29027 invoked from network); 3 Nov 2014 21:53:29 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 21:53:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415051606; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : Subject :
	References : In-Reply-To : Content-Type : Content-Transfer-Encoding;
	bh=tlFAFyEzaf5LQ0UV2c7oyw9AdYYM9eumYPXqX+OOHuY=;
	b=WewKdeJ8HEPb/roIre53XbFQjIuyBXvyixg1YUQZPZ4GEzcFVwLJ7lUE5Ljehr2RBCvJyYAs1YVnd8zcrtPJt9MPJHQeJv8T8b6hUekHfbmHI1riwyVPdZS0d4sUJWjs8/vvE3zs0bYQwapojNS/eHulmiy2oyHXv5Hba1KaRao=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 03 Nov 2014 13:53:26 -0800
	id 00000000000305F3.5457F956.00004F91
Message-ID: <5457F935.8040806@ihonk.com>
Date: Mon, 03 Nov 2014 13:52:53 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
References: <5457F79B.2020300@ihonk.com>
In-Reply-To: <5457F79B.2020300@ihonk.com>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/3/2014 13:46, Steve Freitas wrote:
> Hi all,
>
> I've got a Windows 7 x64 VM that is stable on 4.4.1 but crashes the 
> host after a few hours on 4.5rc1.

Whoops, neglected to include the following log which, I expect, is useless:

root@g2:/var/log/xen# cat qemu-dm-clippy2.log
char device redirected to /dev/pts/2 (label serial0)


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 21:53:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 21: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 1XlPZ5-0000i0-Kl; Mon, 03 Nov 2014 21:53:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XlPZ4-0000hv-Jr
	for xen-devel@lists.xen.org; Mon, 03 Nov 2014 21:53:30 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	8C/3A-26652-959F7545; Mon, 03 Nov 2014 21:53:29 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415051607!6847757!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29027 invoked from network); 3 Nov 2014 21:53:29 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Nov 2014 21:53:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415051606; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : Subject :
	References : In-Reply-To : Content-Type : Content-Transfer-Encoding;
	bh=tlFAFyEzaf5LQ0UV2c7oyw9AdYYM9eumYPXqX+OOHuY=;
	b=WewKdeJ8HEPb/roIre53XbFQjIuyBXvyixg1YUQZPZ4GEzcFVwLJ7lUE5Ljehr2RBCvJyYAs1YVnd8zcrtPJt9MPJHQeJv8T8b6hUekHfbmHI1riwyVPdZS0d4sUJWjs8/vvE3zs0bYQwapojNS/eHulmiy2oyHXv5Hba1KaRao=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 03 Nov 2014 13:53:26 -0800
	id 00000000000305F3.5457F956.00004F91
Message-ID: <5457F935.8040806@ihonk.com>
Date: Mon, 03 Nov 2014 13:52:53 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
References: <5457F79B.2020300@ihonk.com>
In-Reply-To: <5457F79B.2020300@ihonk.com>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/3/2014 13:46, Steve Freitas wrote:
> Hi all,
>
> I've got a Windows 7 x64 VM that is stable on 4.4.1 but crashes the 
> host after a few hours on 4.5rc1.

Whoops, neglected to include the following log which, I expect, is useless:

root@g2:/var/log/xen# cat qemu-dm-clippy2.log
char device redirected to /dev/pts/2 (label serial0)


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

From xen-devel-bounces@lists.xen.org Mon Nov 03 22:52:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 22: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 1XlQTr-0001aB-FP; Mon, 03 Nov 2014 22:52:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XlQTp-0001a6-Da
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 22:52:09 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	7B/B1-01660-81708545; Mon, 03 Nov 2014 22:52:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415055127!10970789!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26145 invoked from network); 3 Nov 2014 22:52:07 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-2.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 22:52:07 -0000
X-TM-IMSS-Message-ID: <b835995d0004ed2c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 b835995d0004ed2c ;
	Mon, 3 Nov 2014 17:52:24 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA3Mpg64007794; 
	Mon, 3 Nov 2014 17:51:52 -0500
Message-ID: <545806FE.4010702@tycho.nsa.gov>
Date: Mon, 03 Nov 2014 17:51:42 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Julien Grall <julien.grall@linaro.org>, xen-devel@lists.xenproject.org
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/01/2014 04:10 PM, Julien Grall wrote:
> The vGIC will emulate the same version as the hardware. The toolstack has
> to retrieve the version of the vGIC in order to be able to create the
> corresponding device tree node.
>
> A new DOMCTL has been introduced for ARM to configure the domain. For now
> it only allow the toolstack to retrieve the version of vGIC.
> This DOMCTL will be extend later to let the user choose the version of the
> emulated GIC.
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Wei Liu <wei.liu2@citrix.com>

Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 22:52:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 22: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 1XlQTr-0001aB-FP; Mon, 03 Nov 2014 22:52:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XlQTp-0001a6-Da
	for xen-devel@lists.xenproject.org; Mon, 03 Nov 2014 22:52:09 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	7B/B1-01660-81708545; Mon, 03 Nov 2014 22:52:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415055127!10970789!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26145 invoked from network); 3 Nov 2014 22:52:07 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-2.tower-206.messagelabs.com with SMTP;
	3 Nov 2014 22:52:07 -0000
X-TM-IMSS-Message-ID: <b835995d0004ed2c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 b835995d0004ed2c ;
	Mon, 3 Nov 2014 17:52:24 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA3Mpg64007794; 
	Mon, 3 Nov 2014 17:51:52 -0500
Message-ID: <545806FE.4010702@tycho.nsa.gov>
Date: Mon, 03 Nov 2014 17:51:42 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Julien Grall <julien.grall@linaro.org>, xen-devel@lists.xenproject.org
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/01/2014 04:10 PM, Julien Grall wrote:
> The vGIC will emulate the same version as the hardware. The toolstack has
> to retrieve the version of the vGIC in order to be able to create the
> corresponding device tree node.
>
> A new DOMCTL has been introduced for ARM to configure the domain. For now
> it only allow the toolstack to retrieve the version of vGIC.
> This DOMCTL will be extend later to let the user choose the version of the
> emulated GIC.
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Wei Liu <wei.liu2@citrix.com>

Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

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

From xen-devel-bounces@lists.xen.org Mon Nov 03 23:56:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 23:56:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlRTm-0002RW-Pk; Mon, 03 Nov 2014 23:56:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlRTl-0002RR-GN
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 23:56:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7C/25-09842-81618545; Mon, 03 Nov 2014 23:56:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415058966!12458060!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15815 invoked from network); 3 Nov 2014 23:56:07 -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;
	3 Nov 2014 23:56:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,310,1413244800"; d="scan'208";a="187742822"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 18:56:04 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlRTg-0002HD-Dd;
	Mon, 03 Nov 2014 23:56:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlRTg-0007JJ-8x;
	Mon, 03 Nov 2014 23:56:04 +0000
Date: Mon, 3 Nov 2014 23:56:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31343-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31343: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31253
 test-amd64-i386-rhel6hvm-amd 10 guest-destroy      fail in 31253 pass in 31343
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 12 guest-localmigrate.2 fail in 31253 pass in 31343

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              136d4ec190af616bb4fa8624dd9c648e5c9e0d2a
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 311 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 Nov 03 23:56:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Nov 2014 23:56:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlRTm-0002RW-Pk; Mon, 03 Nov 2014 23:56:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlRTl-0002RR-GN
	for xen-devel@lists.xensource.com; Mon, 03 Nov 2014 23:56:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7C/25-09842-81618545; Mon, 03 Nov 2014 23:56:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415058966!12458060!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15815 invoked from network); 3 Nov 2014 23:56:07 -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;
	3 Nov 2014 23:56:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,310,1413244800"; d="scan'208";a="187742822"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 18:56:04 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlRTg-0002HD-Dd;
	Mon, 03 Nov 2014 23:56:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlRTg-0007JJ-8x;
	Mon, 03 Nov 2014 23:56:04 +0000
Date: Mon, 3 Nov 2014 23:56:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31343-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31343: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31253
 test-amd64-i386-rhel6hvm-amd 10 guest-destroy      fail in 31253 pass in 31343
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 12 guest-localmigrate.2 fail in 31253 pass in 31343

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              136d4ec190af616bb4fa8624dd9c648e5c9e0d2a
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 311 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 Nov 04 01:05:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 01:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlSYo-00086V-Us; Tue, 04 Nov 2014 01:05:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlSYn-00086Q-UT
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 01:05:26 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	8A/26-02696-55628545; Tue, 04 Nov 2014 01:05:25 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415063122!12317393!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23800 invoked from network); 4 Nov 2014 01:05:22 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-9.tower-27.messagelabs.com with SMTP;
	4 Nov 2014 01:05:22 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 03 Nov 2014 16:59:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,310,1413270000"; d="scan'208";a="616487148"
Received: from tchen0-linux.bj.intel.com ([10.238.154.56])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 17:05:14 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: Ian.Jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Campbell@eu.citrix.com, wei.liu2@citrix.com
Date: Tue,  4 Nov 2014 09:00:17 +0800
Message-Id: <1415062817-3584-1-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: JBeulich@suse.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [v3][PATCH] tools/hvmloader: link errno.h from xen
	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>
MIME-Version: 1.0
Content-Type: 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 act on some specific hypercall error numbers, so
require the hypervisor view on the errno.h value rather than
just the build environment's number. So here link this headfile
from xen.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
v3:

* Address Jan's two comments
  The file name would seem quite right to be used as dependency here.
  subdirs-all should depend on errno.h

v2:

* CCed more tools MAINTAINERS
* Rephrase long log
* Remove this line '@rm -rf errno.h' since we always force link
* Drop including this head file in util.h directly

 .gitignore                        | 1 +
 tools/firmware/hvmloader/Makefile | 7 ++++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index b24e905..52c3038 100644
--- a/.gitignore
+++ b/.gitignore
@@ -127,6 +127,7 @@ tools/firmware/hvmloader/acpi/ssdt_*.h
 tools/firmware/hvmloader/hvmloader
 tools/firmware/hvmloader/roms.h
 tools/firmware/hvmloader/roms.inc
+tools/firmware/hvmloader/errno.h
 tools/firmware/rombios/BIOS-bochs-[^/]*
 tools/firmware/rombios/_rombios[^/]*_.c
 tools/firmware/rombios/rombios[^/]*.s
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 46a79c5..ef2337b 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -87,6 +87,11 @@ endif
 all: subdirs-all
 	$(MAKE) hvmloader
 
+subdirs-all: errno.h
+
+errno.h:
+	ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
+
 ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
 
@@ -136,7 +141,7 @@ endif
 
 .PHONY: clean
 clean: subdirs-clean
-	rm -f roms.inc roms.inc.new acpi.h
+	rm -f roms.inc roms.inc.new acpi.h errno.h
 	rm -f hvmloader hvmloader.tmp *.o $(DEPS)
 
 -include $(DEPS)
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 01:05:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 01:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlSYo-00086V-Us; Tue, 04 Nov 2014 01:05:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlSYn-00086Q-UT
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 01:05:26 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	8A/26-02696-55628545; Tue, 04 Nov 2014 01:05:25 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415063122!12317393!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23800 invoked from network); 4 Nov 2014 01:05:22 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-9.tower-27.messagelabs.com with SMTP;
	4 Nov 2014 01:05:22 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 03 Nov 2014 16:59:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,310,1413270000"; d="scan'208";a="616487148"
Received: from tchen0-linux.bj.intel.com ([10.238.154.56])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 17:05:14 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: Ian.Jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Campbell@eu.citrix.com, wei.liu2@citrix.com
Date: Tue,  4 Nov 2014 09:00:17 +0800
Message-Id: <1415062817-3584-1-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: JBeulich@suse.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [v3][PATCH] tools/hvmloader: link errno.h from xen
	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>
MIME-Version: 1.0
Content-Type: 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 act on some specific hypercall error numbers, so
require the hypervisor view on the errno.h value rather than
just the build environment's number. So here link this headfile
from xen.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
v3:

* Address Jan's two comments
  The file name would seem quite right to be used as dependency here.
  subdirs-all should depend on errno.h

v2:

* CCed more tools MAINTAINERS
* Rephrase long log
* Remove this line '@rm -rf errno.h' since we always force link
* Drop including this head file in util.h directly

 .gitignore                        | 1 +
 tools/firmware/hvmloader/Makefile | 7 ++++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index b24e905..52c3038 100644
--- a/.gitignore
+++ b/.gitignore
@@ -127,6 +127,7 @@ tools/firmware/hvmloader/acpi/ssdt_*.h
 tools/firmware/hvmloader/hvmloader
 tools/firmware/hvmloader/roms.h
 tools/firmware/hvmloader/roms.inc
+tools/firmware/hvmloader/errno.h
 tools/firmware/rombios/BIOS-bochs-[^/]*
 tools/firmware/rombios/_rombios[^/]*_.c
 tools/firmware/rombios/rombios[^/]*.s
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 46a79c5..ef2337b 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -87,6 +87,11 @@ endif
 all: subdirs-all
 	$(MAKE) hvmloader
 
+subdirs-all: errno.h
+
+errno.h:
+	ln -sf $(XEN_ROOT)/xen/include/xen/errno.h .
+
 ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
 
@@ -136,7 +141,7 @@ endif
 
 .PHONY: clean
 clean: subdirs-clean
-	rm -f roms.inc roms.inc.new acpi.h
+	rm -f roms.inc roms.inc.new acpi.h errno.h
 	rm -f hvmloader hvmloader.tmp *.o $(DEPS)
 
 -include $(DEPS)
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 01:35:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 01: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 1XlT1r-0000F8-VQ; Tue, 04 Nov 2014 01:35:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlT1q-0000F3-SA
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 01:35:26 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	3C/23-23865-D5D28545; Tue, 04 Nov 2014 01:35:25 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415064924!11449397!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11034 invoked from network); 4 Nov 2014 01:35:25 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-31.messagelabs.com with SMTP;
	4 Nov 2014 01:35:25 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 17:35:23 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,311,1413270000"; d="scan'208";a="616501900"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.157])
	([10.238.128.157])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 17:35:22 -0800
Message-ID: <54582D59.4020201@intel.com>
Date: Tue, 04 Nov 2014 09:35:21 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
	<54577AD302000078000445EB@mail.emea.novell.com>
In-Reply-To: <54577AD302000078000445EB@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 19:53, Jan Beulich wrote:
>>>> On 03.11.14 at 12:48, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 18:03, Jan Beulich wrote:
>>>>>> On 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
>>>> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>>>>> #2 the error handling
>>>>>>
>>>>>> In an error case what should I do? Currently we still create these
>>>>>> mapping as normal. This means these mfns will be valid so later we can't
>>>>>> set them again then device can't be assigned as passthrough. I think
>>>>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>>>>
>>>>> You should, with very few exceptions, not ignore errors (which
>>>>> includes "handling" them by just logging a message. Instead, you
>>>>> should propagate the error back up the call chain.
>>>>>
>>>>
>>>> Do you mean in your patch,
>>>>
>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>> +{
>>>> +    const struct iommu_ops *ops = iommu_get_ops();
>>>> +
>>>> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
>>>> +        return 0;
>>>> +
>>>> +    return ops->get_reserved_device_memory(func, ctxt);
>>>> +}
>>>> +
>>>>
>>>> I shouldn't return that directly. Then instead, we should handle all
>>>> error scenarios here?
>>>
>>> No. All error scenarios are already being handled here (by
>>> propagating the error code to the caller).
>>
>> Sorry, how to propagate the error code?
>
> Return it to the caller (and it will do so onwards, until it reaches
> [presumably] the entity having invoked a hypercall).

I guess you mean we should return out in this error case,

@@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned 
long gfn,
      /* Now, actually do the two-way mapping */
      if ( mfn_valid(_mfn(mfn)) )
      {
-        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
-                           p2m->default_access);
+        rc = 0;
+        a =  p2m->default_access;
+        if ( !is_hardware_domain(d) )
+        {
+            rc = 
iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                                  &gfn);
+            /* We always avoid populating reserved device memory. */
+            if ( rc == 1 )
+                goto out;
+            else if ( rc < 0 )
+            {
+                printk(XENLOG_G_WARNING
+                       "Dom%d can't check reserved device memory.\n",
+                       d->domain_id);
+                goto out;
+            }
+        }
+
+        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
          if ( rc )
              goto out; /* Failed to update p2m, bail without updating 
m2p. */

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 01:35:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 01: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 1XlT1r-0000F8-VQ; Tue, 04 Nov 2014 01:35:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlT1q-0000F3-SA
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 01:35:26 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	3C/23-23865-D5D28545; Tue, 04 Nov 2014 01:35:25 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415064924!11449397!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11034 invoked from network); 4 Nov 2014 01:35:25 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-31.messagelabs.com with SMTP;
	4 Nov 2014 01:35:25 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 17:35:23 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,311,1413270000"; d="scan'208";a="616501900"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.157])
	([10.238.128.157])
	by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2014 17:35:22 -0800
Message-ID: <54582D59.4020201@intel.com>
Date: Tue, 04 Nov 2014 09:35:21 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
	<54577AD302000078000445EB@mail.emea.novell.com>
In-Reply-To: <54577AD302000078000445EB@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 19:53, Jan Beulich wrote:
>>>> On 03.11.14 at 12:48, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 18:03, Jan Beulich wrote:
>>>>>> On 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
>>>> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>>>>> #2 the error handling
>>>>>>
>>>>>> In an error case what should I do? Currently we still create these
>>>>>> mapping as normal. This means these mfns will be valid so later we can't
>>>>>> set them again then device can't be assigned as passthrough. I think
>>>>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>>>>
>>>>> You should, with very few exceptions, not ignore errors (which
>>>>> includes "handling" them by just logging a message. Instead, you
>>>>> should propagate the error back up the call chain.
>>>>>
>>>>
>>>> Do you mean in your patch,
>>>>
>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>> +{
>>>> +    const struct iommu_ops *ops = iommu_get_ops();
>>>> +
>>>> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
>>>> +        return 0;
>>>> +
>>>> +    return ops->get_reserved_device_memory(func, ctxt);
>>>> +}
>>>> +
>>>>
>>>> I shouldn't return that directly. Then instead, we should handle all
>>>> error scenarios here?
>>>
>>> No. All error scenarios are already being handled here (by
>>> propagating the error code to the caller).
>>
>> Sorry, how to propagate the error code?
>
> Return it to the caller (and it will do so onwards, until it reaches
> [presumably] the entity having invoked a hypercall).

I guess you mean we should return out in this error case,

@@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned 
long gfn,
      /* Now, actually do the two-way mapping */
      if ( mfn_valid(_mfn(mfn)) )
      {
-        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
-                           p2m->default_access);
+        rc = 0;
+        a =  p2m->default_access;
+        if ( !is_hardware_domain(d) )
+        {
+            rc = 
iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                                  &gfn);
+            /* We always avoid populating reserved device memory. */
+            if ( rc == 1 )
+                goto out;
+            else if ( rc < 0 )
+            {
+                printk(XENLOG_G_WARNING
+                       "Dom%d can't check reserved device memory.\n",
+                       d->domain_id);
+                goto out;
+            }
+        }
+
+        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
          if ( rc )
              goto out; /* Failed to update p2m, bail without updating 
m2p. */

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 04:32:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 04:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlVmY-0003Yw-PC; Tue, 04 Nov 2014 04:31:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XlVmX-0003Yr-AM
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 04:31:49 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C0/F8-29352-4B658545; Tue, 04 Nov 2014 04:31:48 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415075506!11004653!1
X-Originating-IP: [209.85.220.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16166 invoked from network); 4 Nov 2014 04:31:47 -0000
Received: from mail-vc0-f170.google.com (HELO mail-vc0-f170.google.com)
	(209.85.220.170)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 04:31:47 -0000
Received: by mail-vc0-f170.google.com with SMTP id la4so5406237vcb.15
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 20:31:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=MvqxZ/6wThVHfwDZrEQJTkVzUc41zFvpNezJ7osbanw=;
	b=bTor20+MakTGrvs31zKXX+C1cYdFJyRjGzGLWHm/KWoLpo9Uz+vWqQk/TKxSxzEN65
	3iMXmLthhQbog9qfZxOwoAv11hoGPnxuqLky1tVEDoRLBu9IYiY1hAd/JytXQ6L2rPp+
	pYZPwmdTuTnetR/9iudd2m1/ga/n8Bnhw1dDWhjRZQN80laziiQj3ZHuANB8JVBmBi/x
	S4anqUT5Gl8u+NJJXgfvUhvzBPOgZXCX2EUOIibOwMYWmOt4PxuJsBBsnYzUzbn1pOAh
	FzbzRfNkjTL2ugqnK8UYklCAfuxS0LQCFJoV0uZ/lM7ONUUONO173/c3WkSatKEq5I63
	g26w==
X-Gm-Message-State: ALoCoQmppnxVKkjYOJP/aYgNl3fX+J+wqox5+T+6BdKtF2ziULhEhtQUV9+1NuLFy35wTLLSEDZj
MIME-Version: 1.0
X-Received: by 10.220.162.196 with SMTP id w4mr42151085vcx.30.1415075506455;
	Mon, 03 Nov 2014 20:31:46 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Mon, 3 Nov 2014 20:31:46 -0800 (PST)
In-Reply-To: <545759FB02000078000443F2@mail.emea.novell.com>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
Date: Mon, 3 Nov 2014 20:31:46 -0800
Message-ID: <CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 3, 2014 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
>> This patch implements what I understand to be the desired behavior when
>> booting
>> an EFI Xen image via GRUB based on the thread last week.  The EFI command
>> line
>> is not used, and the Xen commandline comes via the multiboot protocol (and
>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
>> GRUB EFI boot cases into alignment in not using the EFI commandline.
>
> Right, but ...
>
>> The current state of the arm64 code takes the Xen commandline from the FDT,
>> but still looks in the EFI commandline for EFI boot specific options.  If
>> unexpected options are passed in the EFI commandline, it will generate
>> "unrecognized option" ouput for all unexpected options.
>
> ... why is this?

The EFI boot code did this before any of the arm64 changes, and that
behavior is unchanged.
The actual message is "WARNING: Unknown command line option"

I was simply trying to explain the current behavior regarding the EFI
commandline.

>
>> +    if ( use_cfg_file )
>>      {
>>          EFI_FILE_HANDLE dir_handle;
>> +        size = 0;
>
> Coding style (missing blank line between declaration(s) and
> statement(s). Plus - did you check whether some of the so far
> function wide variables (e.g. gop) could be moved into this more
> narrow scope?

I'll fix the style.  I had not reviewed scope, but now have.  There
are only a few
variables I can reduce in scope, which I have done in V2 of the patch
which I will post shortly.
The gop variable and a few others cannot be moved without further code
reorganization.  The graphics
mode is set later in efi_start() if gop is !null (line 1035)
I don't see any reason this code couldn't be moved to be in the if (
use_cfg_file ) block, but given that
this patch is very late in the release cycle, I'm opting to try to
keep this patch minimal.  If you would prefer
me to move this code and variables, I am happy to do a v3 with these changes.

>
>>              }
>>          }
>>      }
>> -
>>      efi_arch_edd();
>>
>>      /* XXX Collect EDID info. */
>
> Please don't.

removed.
>
> Jan
>

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 04:32:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 04:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlVmY-0003Yw-PC; Tue, 04 Nov 2014 04:31:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XlVmX-0003Yr-AM
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 04:31:49 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C0/F8-29352-4B658545; Tue, 04 Nov 2014 04:31:48 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415075506!11004653!1
X-Originating-IP: [209.85.220.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16166 invoked from network); 4 Nov 2014 04:31:47 -0000
Received: from mail-vc0-f170.google.com (HELO mail-vc0-f170.google.com)
	(209.85.220.170)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 04:31:47 -0000
Received: by mail-vc0-f170.google.com with SMTP id la4so5406237vcb.15
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 20:31:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=MvqxZ/6wThVHfwDZrEQJTkVzUc41zFvpNezJ7osbanw=;
	b=bTor20+MakTGrvs31zKXX+C1cYdFJyRjGzGLWHm/KWoLpo9Uz+vWqQk/TKxSxzEN65
	3iMXmLthhQbog9qfZxOwoAv11hoGPnxuqLky1tVEDoRLBu9IYiY1hAd/JytXQ6L2rPp+
	pYZPwmdTuTnetR/9iudd2m1/ga/n8Bnhw1dDWhjRZQN80laziiQj3ZHuANB8JVBmBi/x
	S4anqUT5Gl8u+NJJXgfvUhvzBPOgZXCX2EUOIibOwMYWmOt4PxuJsBBsnYzUzbn1pOAh
	FzbzRfNkjTL2ugqnK8UYklCAfuxS0LQCFJoV0uZ/lM7ONUUONO173/c3WkSatKEq5I63
	g26w==
X-Gm-Message-State: ALoCoQmppnxVKkjYOJP/aYgNl3fX+J+wqox5+T+6BdKtF2ziULhEhtQUV9+1NuLFy35wTLLSEDZj
MIME-Version: 1.0
X-Received: by 10.220.162.196 with SMTP id w4mr42151085vcx.30.1415075506455;
	Mon, 03 Nov 2014 20:31:46 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Mon, 3 Nov 2014 20:31:46 -0800 (PST)
In-Reply-To: <545759FB02000078000443F2@mail.emea.novell.com>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
Date: Mon, 3 Nov 2014 20:31:46 -0800
Message-ID: <CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 3, 2014 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
>> This patch implements what I understand to be the desired behavior when
>> booting
>> an EFI Xen image via GRUB based on the thread last week.  The EFI command
>> line
>> is not used, and the Xen commandline comes via the multiboot protocol (and
>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
>> GRUB EFI boot cases into alignment in not using the EFI commandline.
>
> Right, but ...
>
>> The current state of the arm64 code takes the Xen commandline from the FDT,
>> but still looks in the EFI commandline for EFI boot specific options.  If
>> unexpected options are passed in the EFI commandline, it will generate
>> "unrecognized option" ouput for all unexpected options.
>
> ... why is this?

The EFI boot code did this before any of the arm64 changes, and that
behavior is unchanged.
The actual message is "WARNING: Unknown command line option"

I was simply trying to explain the current behavior regarding the EFI
commandline.

>
>> +    if ( use_cfg_file )
>>      {
>>          EFI_FILE_HANDLE dir_handle;
>> +        size = 0;
>
> Coding style (missing blank line between declaration(s) and
> statement(s). Plus - did you check whether some of the so far
> function wide variables (e.g. gop) could be moved into this more
> narrow scope?

I'll fix the style.  I had not reviewed scope, but now have.  There
are only a few
variables I can reduce in scope, which I have done in V2 of the patch
which I will post shortly.
The gop variable and a few others cannot be moved without further code
reorganization.  The graphics
mode is set later in efi_start() if gop is !null (line 1035)
I don't see any reason this code couldn't be moved to be in the if (
use_cfg_file ) block, but given that
this patch is very late in the release cycle, I'm opting to try to
keep this patch minimal.  If you would prefer
me to move this code and variables, I am happy to do a v3 with these changes.

>
>>              }
>>          }
>>      }
>> -
>>      efi_arch_edd();
>>
>>      /* XXX Collect EDID info. */
>
> Please don't.

removed.
>
> Jan
>

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 04:37:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 04:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlVsF-0003pI-Nk; Tue, 04 Nov 2014 04:37:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XlVsD-0003p6-G8
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 04:37:41 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	6C/C7-17958-41858545; Tue, 04 Nov 2014 04:37:40 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415075858!11362326!1
X-Originating-IP: [209.85.223.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25751 invoked from network); 4 Nov 2014 04:37:39 -0000
Received: from mail-ie0-f181.google.com (HELO mail-ie0-f181.google.com)
	(209.85.223.181)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 04:37:39 -0000
Received: by mail-ie0-f181.google.com with SMTP id rp18so6802539iec.12
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 20:37:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=2QmkzHkmD4W3d1wYjMcJmANXXJ1sB/nCYrzAgBvtHEE=;
	b=QzpaWaZqladb75fVvQUKEGs0DOKuvGPYsGSUBoEcwfRM3FIrbNjnl71/bNdgHXqF3m
	Tb1bMNEQXsbpeB56YTgTHj4n2g1W+C+Rfi3qb/aMgNXl28SjeS/g99F4uvMjve6CuSlw
	0hxt4HaqnJ9m8gD2HHSw0Crbi5OCp1MJR8bSBXPM5qwmKlo2QiYR5QdTUHiQw9CxccpP
	qkmUbgGb0RHNit9v0HitJjLo0VMdnft4e8TJVCfFUlalLcYtYBckj9qe1Ke84uO8wuZz
	BmGM9alEZgI1t6WpS/9BvhP/ZgX34qgMsZ9elPKNfoHl6MeFyttMQGDRpoRVT9xNeZTU
	NYRA==
X-Gm-Message-State: ALoCoQkI47W+x203qUxZra7yN5Q0PUSPM48XWZV6osfnCcuelVesP+HgSLzyrK0EcIRJoGSHoPr2
X-Received: by 10.50.20.130 with SMTP id n2mr21172789ige.44.1415075857716;
	Mon, 03 Nov 2014 20:37:37 -0800 (PST)
Received: from rfranz-v430.caveonetworks.com (64.2.3.194.ptr.us.xo.net.
	[64.2.3.194])
	by mx.google.com with ESMTPSA id 137sm7568783iof.2.2014.11.03.20.37.36
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 20:37:37 -0800 (PST)
From: Roy Franz <roy.franz@linaro.org>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com, tim@xen.org, jbeulich@suse.com
Date: Mon,  3 Nov 2014 20:37:31 -0800
Message-Id: <1415075851-8987-1-git-send-email-roy.franz@linaro.org>
X-Mailer: git-send-email 1.9.1
Cc: Roy Franz <roy.franz@linaro.org>, daniel.kiper@oracle.com,
	fu.wei@linaro.org
Subject: [Xen-devel] [PATCH for-4.5 V2] EFI: Ignore EFI commandline,
	skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 EFI code to completely ignore the EFI comnandline when booted from GRUB.
Previusly it was parsed of EFI boot specific options, but these aren't used
when booted from GRUB.

Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
code does some console and video initialization to support native EFI boot from
the EFI boot manager or EFI shell.  This initlization should not be done when
booted using GRUB.

Update EFI documentation to indicate that it describes EFI native boot, and
does not apply at all when Xen is booted using GRUB.

Signed-off-by: Roy Franz <roy.franz@linaro.org>
---
This patch implements what I understand to be the desired behavior when booting
an EFI Xen image via GRUB based on the thread last week.  The EFI command line
is not used, and the Xen commandline comes via the multiboot protocol (and
in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
GRUB EFI boot cases into alignment in not using the EFI commandline.

The current state of the arm64 code takes the Xen commandline from the FDT,
but still looks in the EFI commandline for EFI boot specific options.  If
unexpected options are passed in the EFI commandline, it will generate
"unrecognized option" ouput for all unexpected options.

I think this should be considered for 4.5.

Changes from v1:
* Fixed style, and removed blank line changes
* Reviewed scope of variables now that more code is in if ( use_cfg_file ) block
  

 docs/misc/efi.markdown |   5 ++
 xen/common/efi/boot.c  | 240 +++++++++++++++++++++++++------------------------
 2 files changed, 128 insertions(+), 117 deletions(-)

diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
index 5e48aa3..f435ec7 100644
--- a/docs/misc/efi.markdown
+++ b/docs/misc/efi.markdown
@@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
 (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
 try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
 order.) One can override this with a command line option (`-cfg=<filename>`).
+This configuration file and EFI commandline are only used for booting directly
+from EFI firmware, or when using an EFI loader that does not support
+the multiboot2 protocol.  When booting using GRUB or another multiboot aware
+loader the EFI commandline is ignored and all information is passed from
+the loader to Xen using the multiboot protocol.
 
 The configuration file consists of one or more sections headed by a section
 name enclosed in square brackets, with individual values specified in each
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 4257341..471dff7 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -697,7 +697,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     EFI_STATUS status;
     unsigned int i, argc;
     CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
-    UINTN cols, rows, depth, size, map_key, info_size, gop_mode = ~0;
+    UINTN map_key, info_size, gop_mode = ~0;
     EFI_HANDLE *handles = NULL;
     EFI_SHIM_LOCK_PROTOCOL *shim_lock;
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
@@ -705,6 +705,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     union string section = { NULL }, name;
     bool_t base_video = 0;
     char *option_str;
+    bool_t use_cfg_file;
 
     efi_ih = ImageHandle;
     efi_bs = SystemTable->BootServices;
@@ -717,6 +718,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     StdOut = SystemTable->ConOut;
     StdErr = SystemTable->StdErr ?: StdOut;
+    use_cfg_file = efi_arch_use_config_file(SystemTable);
 
     status = efi_bs->HandleProtocol(ImageHandle, &loaded_image_guid,
                                     (void **)&loaded_image);
@@ -725,67 +727,71 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_load_addr_check(loaded_image);
 
-    argc = get_argv(0, NULL, loaded_image->LoadOptions,
-                    loaded_image->LoadOptionsSize, NULL);
-    if ( argc > 0 &&
-         efi_bs->AllocatePool(EfiLoaderData,
-                              (argc + 1) * sizeof(*argv) +
-                                  loaded_image->LoadOptionsSize,
-                              (void **)&argv) == EFI_SUCCESS )
-        get_argv(argc, argv, loaded_image->LoadOptions,
-                 loaded_image->LoadOptionsSize, &options);
-    else
-        argc = 0;
-    for ( i = 1; i < argc; ++i )
+    if ( use_cfg_file )
     {
-        CHAR16 *ptr = argv[i];
-
-        if ( !ptr )
-            break;
-        if ( *ptr == L'/' || *ptr == L'-' )
+        argc = get_argv(0, NULL, loaded_image->LoadOptions,
+                        loaded_image->LoadOptionsSize, NULL);
+        if ( argc > 0 &&
+             efi_bs->AllocatePool(EfiLoaderData,
+                                  (argc + 1) * sizeof(*argv) +
+                                      loaded_image->LoadOptionsSize,
+                                  (void **)&argv) == EFI_SUCCESS )
+            get_argv(argc, argv, loaded_image->LoadOptions,
+                     loaded_image->LoadOptionsSize, &options);
+        else
+            argc = 0;
+        for ( i = 1; i < argc; ++i )
         {
-            if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
-                base_video = 1;
-            else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
-                cfg_file_name = ptr + 5;
-            else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
-                cfg_file_name = argv[++i];
-            else if ( wstrcmp(ptr + 1, L"help") == 0 ||
-                      (ptr[1] == L'?' && !ptr[2]) )
+            CHAR16 *ptr = argv[i];
+
+            if ( !ptr )
+                break;
+            if ( *ptr == L'/' || *ptr == L'-' )
             {
-                PrintStr(L"Xen EFI Loader options:\r\n");
-                PrintStr(L"-basevideo   retain current video mode\r\n");
-                PrintStr(L"-cfg=<file>  specify configuration file\r\n");
-                PrintStr(L"-help, -?    display this help\r\n");
-                blexit(NULL);
+                if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
+                    base_video = 1;
+                else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
+                    cfg_file_name = ptr + 5;
+                else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
+                    cfg_file_name = argv[++i];
+                else if ( wstrcmp(ptr + 1, L"help") == 0 ||
+                          (ptr[1] == L'?' && !ptr[2]) )
+                {
+                    PrintStr(L"Xen EFI Loader options:\r\n");
+                    PrintStr(L"-basevideo   retain current video mode\r\n");
+                    PrintStr(L"-cfg=<file>  specify configuration file\r\n");
+                    PrintStr(L"-help, -?    display this help\r\n");
+                    blexit(NULL);
+                }
+                else
+                {
+                    PrintStr(L"WARNING: Unknown command line option '");
+                    PrintStr(ptr);
+                    PrintStr(L"' ignored\r\n");
+                }
             }
             else
-            {
-                PrintStr(L"WARNING: Unknown command line option '");
-                PrintStr(ptr);
-                PrintStr(L"' ignored\r\n");
-            }
+                section.w = ptr;
         }
-        else
-            section.w = ptr;
-    }
 
-    if ( !base_video )
-    {
-        unsigned int best;
-
-        for ( i = 0, size = 0, best = StdOut->Mode->Mode;
-              i < StdOut->Mode->MaxMode; ++i )
+        if ( !base_video )
         {
-            if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
-                 cols * rows > size )
+            unsigned int best;
+            UINTN cols, rows, size;
+
+            for ( i = 0, size = 0, best = StdOut->Mode->Mode;
+                  i < StdOut->Mode->MaxMode; ++i )
             {
-                size = cols * rows;
-                best = i;
+                if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
+                     cols * rows > size )
+                {
+                    size = cols * rows;
+                    best = i;
+                }
             }
+            if ( best != StdOut->Mode->Mode )
+                StdOut->SetMode(StdOut, best);
         }
-        if ( best != StdOut->Mode->Mode )
-            StdOut->SetMode(StdOut, best);
     }
 
     PrintStr(L"Xen " __stringify(XEN_VERSION) "." __stringify(XEN_SUBVERSION)
@@ -793,37 +799,38 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_relocate_image(0);
 
-    if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
-                           &cols, &rows) == EFI_SUCCESS )
-        efi_arch_console_init(cols, rows);
-
-    size = 0;
-    status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
-    if ( status == EFI_BUFFER_TOO_SMALL )
-        status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
-    if ( !EFI_ERROR(status) )
-        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
-                                      handles);
-    if ( EFI_ERROR(status) )
-        size = 0;
-    for ( i = 0; i < size / sizeof(*handles); ++i )
-    {
-        status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
-        if ( EFI_ERROR(status) )
-            continue;
-        status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
-        if ( !EFI_ERROR(status) )
-            break;
-    }
-    if ( handles )
-        efi_bs->FreePool(handles);
-    if ( EFI_ERROR(status) )
-        gop = NULL;
-
-    cols = rows = depth = 0;
-    if ( efi_arch_use_config_file(SystemTable) )
+    if ( use_cfg_file )
     {
         EFI_FILE_HANDLE dir_handle;
+        UINTN depth, cols, rows, size;
+
+        size = cols = rows = depth = 0;
+
+        if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
+                               &cols, &rows) == EFI_SUCCESS )
+            efi_arch_console_init(cols, rows);
+
+        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
+        if ( status == EFI_BUFFER_TOO_SMALL )
+            status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
+        if ( !EFI_ERROR(status) )
+            status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
+                                          handles);
+        if ( EFI_ERROR(status) )
+            size = 0;
+        for ( i = 0; i < size / sizeof(*handles); ++i )
+        {
+            status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
+            if ( EFI_ERROR(status) )
+                continue;
+            status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
+            if ( !EFI_ERROR(status) )
+                break;
+        }
+        if ( handles )
+            efi_bs->FreePool(handles);
+        if ( EFI_ERROR(status) )
+            gop = NULL;
 
         /* Get the file system interface. */
         dir_handle = get_parent_handle(loaded_image, &file_name);
@@ -931,45 +938,44 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
         dir_handle->Close(dir_handle);
 
-    }
-
-    if ( gop && !base_video )
-    {
-        for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
+        if ( gop && !base_video )
         {
-            unsigned int bpp = 0;
-
-            status = gop->QueryMode(gop, i, &info_size, &mode_info);
-            if ( EFI_ERROR(status) )
-                continue;
-            switch ( mode_info->PixelFormat )
-            {
-            case PixelBitMask:
-                bpp = hweight32(mode_info->PixelInformation.RedMask |
-                                mode_info->PixelInformation.GreenMask |
-                                mode_info->PixelInformation.BlueMask);
-                break;
-            case PixelRedGreenBlueReserved8BitPerColor:
-            case PixelBlueGreenRedReserved8BitPerColor:
-                bpp = 24;
-                break;
-            default:
-                continue;
-            }
-            if ( cols == mode_info->HorizontalResolution &&
-                 rows == mode_info->VerticalResolution &&
-                 (!depth || bpp == depth) )
+            for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
             {
-                gop_mode = i;
-                break;
-            }
-            if ( !cols && !rows &&
-                 mode_info->HorizontalResolution *
-                 mode_info->VerticalResolution > size )
-            {
-                size = mode_info->HorizontalResolution *
-                       mode_info->VerticalResolution;
-                gop_mode = i;
+                unsigned int bpp = 0;
+
+                status = gop->QueryMode(gop, i, &info_size, &mode_info);
+                if ( EFI_ERROR(status) )
+                    continue;
+                switch ( mode_info->PixelFormat )
+                {
+                case PixelBitMask:
+                    bpp = hweight32(mode_info->PixelInformation.RedMask |
+                                    mode_info->PixelInformation.GreenMask |
+                                    mode_info->PixelInformation.BlueMask);
+                    break;
+                case PixelRedGreenBlueReserved8BitPerColor:
+                case PixelBlueGreenRedReserved8BitPerColor:
+                    bpp = 24;
+                    break;
+                default:
+                    continue;
+                }
+                if ( cols == mode_info->HorizontalResolution &&
+                     rows == mode_info->VerticalResolution &&
+                     (!depth || bpp == depth) )
+                {
+                    gop_mode = i;
+                    break;
+                }
+                if ( !cols && !rows &&
+                     mode_info->HorizontalResolution *
+                     mode_info->VerticalResolution > size )
+                {
+                    size = mode_info->HorizontalResolution *
+                           mode_info->VerticalResolution;
+                    gop_mode = i;
+                }
             }
         }
     }
-- 
2.1.0


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 04:37:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 04:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlVsF-0003pI-Nk; Tue, 04 Nov 2014 04:37:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XlVsD-0003p6-G8
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 04:37:41 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	6C/C7-17958-41858545; Tue, 04 Nov 2014 04:37:40 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415075858!11362326!1
X-Originating-IP: [209.85.223.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25751 invoked from network); 4 Nov 2014 04:37:39 -0000
Received: from mail-ie0-f181.google.com (HELO mail-ie0-f181.google.com)
	(209.85.223.181)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 04:37:39 -0000
Received: by mail-ie0-f181.google.com with SMTP id rp18so6802539iec.12
	for <xen-devel@lists.xen.org>; Mon, 03 Nov 2014 20:37:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=2QmkzHkmD4W3d1wYjMcJmANXXJ1sB/nCYrzAgBvtHEE=;
	b=QzpaWaZqladb75fVvQUKEGs0DOKuvGPYsGSUBoEcwfRM3FIrbNjnl71/bNdgHXqF3m
	Tb1bMNEQXsbpeB56YTgTHj4n2g1W+C+Rfi3qb/aMgNXl28SjeS/g99F4uvMjve6CuSlw
	0hxt4HaqnJ9m8gD2HHSw0Crbi5OCp1MJR8bSBXPM5qwmKlo2QiYR5QdTUHiQw9CxccpP
	qkmUbgGb0RHNit9v0HitJjLo0VMdnft4e8TJVCfFUlalLcYtYBckj9qe1Ke84uO8wuZz
	BmGM9alEZgI1t6WpS/9BvhP/ZgX34qgMsZ9elPKNfoHl6MeFyttMQGDRpoRVT9xNeZTU
	NYRA==
X-Gm-Message-State: ALoCoQkI47W+x203qUxZra7yN5Q0PUSPM48XWZV6osfnCcuelVesP+HgSLzyrK0EcIRJoGSHoPr2
X-Received: by 10.50.20.130 with SMTP id n2mr21172789ige.44.1415075857716;
	Mon, 03 Nov 2014 20:37:37 -0800 (PST)
Received: from rfranz-v430.caveonetworks.com (64.2.3.194.ptr.us.xo.net.
	[64.2.3.194])
	by mx.google.com with ESMTPSA id 137sm7568783iof.2.2014.11.03.20.37.36
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 03 Nov 2014 20:37:37 -0800 (PST)
From: Roy Franz <roy.franz@linaro.org>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com, tim@xen.org, jbeulich@suse.com
Date: Mon,  3 Nov 2014 20:37:31 -0800
Message-Id: <1415075851-8987-1-git-send-email-roy.franz@linaro.org>
X-Mailer: git-send-email 1.9.1
Cc: Roy Franz <roy.franz@linaro.org>, daniel.kiper@oracle.com,
	fu.wei@linaro.org
Subject: [Xen-devel] [PATCH for-4.5 V2] EFI: Ignore EFI commandline,
	skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 EFI code to completely ignore the EFI comnandline when booted from GRUB.
Previusly it was parsed of EFI boot specific options, but these aren't used
when booted from GRUB.

Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
code does some console and video initialization to support native EFI boot from
the EFI boot manager or EFI shell.  This initlization should not be done when
booted using GRUB.

Update EFI documentation to indicate that it describes EFI native boot, and
does not apply at all when Xen is booted using GRUB.

Signed-off-by: Roy Franz <roy.franz@linaro.org>
---
This patch implements what I understand to be the desired behavior when booting
an EFI Xen image via GRUB based on the thread last week.  The EFI command line
is not used, and the Xen commandline comes via the multiboot protocol (and
in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
GRUB EFI boot cases into alignment in not using the EFI commandline.

The current state of the arm64 code takes the Xen commandline from the FDT,
but still looks in the EFI commandline for EFI boot specific options.  If
unexpected options are passed in the EFI commandline, it will generate
"unrecognized option" ouput for all unexpected options.

I think this should be considered for 4.5.

Changes from v1:
* Fixed style, and removed blank line changes
* Reviewed scope of variables now that more code is in if ( use_cfg_file ) block
  

 docs/misc/efi.markdown |   5 ++
 xen/common/efi/boot.c  | 240 +++++++++++++++++++++++++------------------------
 2 files changed, 128 insertions(+), 117 deletions(-)

diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
index 5e48aa3..f435ec7 100644
--- a/docs/misc/efi.markdown
+++ b/docs/misc/efi.markdown
@@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
 (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
 try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
 order.) One can override this with a command line option (`-cfg=<filename>`).
+This configuration file and EFI commandline are only used for booting directly
+from EFI firmware, or when using an EFI loader that does not support
+the multiboot2 protocol.  When booting using GRUB or another multiboot aware
+loader the EFI commandline is ignored and all information is passed from
+the loader to Xen using the multiboot protocol.
 
 The configuration file consists of one or more sections headed by a section
 name enclosed in square brackets, with individual values specified in each
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 4257341..471dff7 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -697,7 +697,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     EFI_STATUS status;
     unsigned int i, argc;
     CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
-    UINTN cols, rows, depth, size, map_key, info_size, gop_mode = ~0;
+    UINTN map_key, info_size, gop_mode = ~0;
     EFI_HANDLE *handles = NULL;
     EFI_SHIM_LOCK_PROTOCOL *shim_lock;
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
@@ -705,6 +705,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     union string section = { NULL }, name;
     bool_t base_video = 0;
     char *option_str;
+    bool_t use_cfg_file;
 
     efi_ih = ImageHandle;
     efi_bs = SystemTable->BootServices;
@@ -717,6 +718,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     StdOut = SystemTable->ConOut;
     StdErr = SystemTable->StdErr ?: StdOut;
+    use_cfg_file = efi_arch_use_config_file(SystemTable);
 
     status = efi_bs->HandleProtocol(ImageHandle, &loaded_image_guid,
                                     (void **)&loaded_image);
@@ -725,67 +727,71 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_load_addr_check(loaded_image);
 
-    argc = get_argv(0, NULL, loaded_image->LoadOptions,
-                    loaded_image->LoadOptionsSize, NULL);
-    if ( argc > 0 &&
-         efi_bs->AllocatePool(EfiLoaderData,
-                              (argc + 1) * sizeof(*argv) +
-                                  loaded_image->LoadOptionsSize,
-                              (void **)&argv) == EFI_SUCCESS )
-        get_argv(argc, argv, loaded_image->LoadOptions,
-                 loaded_image->LoadOptionsSize, &options);
-    else
-        argc = 0;
-    for ( i = 1; i < argc; ++i )
+    if ( use_cfg_file )
     {
-        CHAR16 *ptr = argv[i];
-
-        if ( !ptr )
-            break;
-        if ( *ptr == L'/' || *ptr == L'-' )
+        argc = get_argv(0, NULL, loaded_image->LoadOptions,
+                        loaded_image->LoadOptionsSize, NULL);
+        if ( argc > 0 &&
+             efi_bs->AllocatePool(EfiLoaderData,
+                                  (argc + 1) * sizeof(*argv) +
+                                      loaded_image->LoadOptionsSize,
+                                  (void **)&argv) == EFI_SUCCESS )
+            get_argv(argc, argv, loaded_image->LoadOptions,
+                     loaded_image->LoadOptionsSize, &options);
+        else
+            argc = 0;
+        for ( i = 1; i < argc; ++i )
         {
-            if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
-                base_video = 1;
-            else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
-                cfg_file_name = ptr + 5;
-            else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
-                cfg_file_name = argv[++i];
-            else if ( wstrcmp(ptr + 1, L"help") == 0 ||
-                      (ptr[1] == L'?' && !ptr[2]) )
+            CHAR16 *ptr = argv[i];
+
+            if ( !ptr )
+                break;
+            if ( *ptr == L'/' || *ptr == L'-' )
             {
-                PrintStr(L"Xen EFI Loader options:\r\n");
-                PrintStr(L"-basevideo   retain current video mode\r\n");
-                PrintStr(L"-cfg=<file>  specify configuration file\r\n");
-                PrintStr(L"-help, -?    display this help\r\n");
-                blexit(NULL);
+                if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
+                    base_video = 1;
+                else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
+                    cfg_file_name = ptr + 5;
+                else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
+                    cfg_file_name = argv[++i];
+                else if ( wstrcmp(ptr + 1, L"help") == 0 ||
+                          (ptr[1] == L'?' && !ptr[2]) )
+                {
+                    PrintStr(L"Xen EFI Loader options:\r\n");
+                    PrintStr(L"-basevideo   retain current video mode\r\n");
+                    PrintStr(L"-cfg=<file>  specify configuration file\r\n");
+                    PrintStr(L"-help, -?    display this help\r\n");
+                    blexit(NULL);
+                }
+                else
+                {
+                    PrintStr(L"WARNING: Unknown command line option '");
+                    PrintStr(ptr);
+                    PrintStr(L"' ignored\r\n");
+                }
             }
             else
-            {
-                PrintStr(L"WARNING: Unknown command line option '");
-                PrintStr(ptr);
-                PrintStr(L"' ignored\r\n");
-            }
+                section.w = ptr;
         }
-        else
-            section.w = ptr;
-    }
 
-    if ( !base_video )
-    {
-        unsigned int best;
-
-        for ( i = 0, size = 0, best = StdOut->Mode->Mode;
-              i < StdOut->Mode->MaxMode; ++i )
+        if ( !base_video )
         {
-            if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
-                 cols * rows > size )
+            unsigned int best;
+            UINTN cols, rows, size;
+
+            for ( i = 0, size = 0, best = StdOut->Mode->Mode;
+                  i < StdOut->Mode->MaxMode; ++i )
             {
-                size = cols * rows;
-                best = i;
+                if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
+                     cols * rows > size )
+                {
+                    size = cols * rows;
+                    best = i;
+                }
             }
+            if ( best != StdOut->Mode->Mode )
+                StdOut->SetMode(StdOut, best);
         }
-        if ( best != StdOut->Mode->Mode )
-            StdOut->SetMode(StdOut, best);
     }
 
     PrintStr(L"Xen " __stringify(XEN_VERSION) "." __stringify(XEN_SUBVERSION)
@@ -793,37 +799,38 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_relocate_image(0);
 
-    if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
-                           &cols, &rows) == EFI_SUCCESS )
-        efi_arch_console_init(cols, rows);
-
-    size = 0;
-    status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
-    if ( status == EFI_BUFFER_TOO_SMALL )
-        status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
-    if ( !EFI_ERROR(status) )
-        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
-                                      handles);
-    if ( EFI_ERROR(status) )
-        size = 0;
-    for ( i = 0; i < size / sizeof(*handles); ++i )
-    {
-        status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
-        if ( EFI_ERROR(status) )
-            continue;
-        status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
-        if ( !EFI_ERROR(status) )
-            break;
-    }
-    if ( handles )
-        efi_bs->FreePool(handles);
-    if ( EFI_ERROR(status) )
-        gop = NULL;
-
-    cols = rows = depth = 0;
-    if ( efi_arch_use_config_file(SystemTable) )
+    if ( use_cfg_file )
     {
         EFI_FILE_HANDLE dir_handle;
+        UINTN depth, cols, rows, size;
+
+        size = cols = rows = depth = 0;
+
+        if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
+                               &cols, &rows) == EFI_SUCCESS )
+            efi_arch_console_init(cols, rows);
+
+        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
+        if ( status == EFI_BUFFER_TOO_SMALL )
+            status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
+        if ( !EFI_ERROR(status) )
+            status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
+                                          handles);
+        if ( EFI_ERROR(status) )
+            size = 0;
+        for ( i = 0; i < size / sizeof(*handles); ++i )
+        {
+            status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
+            if ( EFI_ERROR(status) )
+                continue;
+            status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
+            if ( !EFI_ERROR(status) )
+                break;
+        }
+        if ( handles )
+            efi_bs->FreePool(handles);
+        if ( EFI_ERROR(status) )
+            gop = NULL;
 
         /* Get the file system interface. */
         dir_handle = get_parent_handle(loaded_image, &file_name);
@@ -931,45 +938,44 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
         dir_handle->Close(dir_handle);
 
-    }
-
-    if ( gop && !base_video )
-    {
-        for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
+        if ( gop && !base_video )
         {
-            unsigned int bpp = 0;
-
-            status = gop->QueryMode(gop, i, &info_size, &mode_info);
-            if ( EFI_ERROR(status) )
-                continue;
-            switch ( mode_info->PixelFormat )
-            {
-            case PixelBitMask:
-                bpp = hweight32(mode_info->PixelInformation.RedMask |
-                                mode_info->PixelInformation.GreenMask |
-                                mode_info->PixelInformation.BlueMask);
-                break;
-            case PixelRedGreenBlueReserved8BitPerColor:
-            case PixelBlueGreenRedReserved8BitPerColor:
-                bpp = 24;
-                break;
-            default:
-                continue;
-            }
-            if ( cols == mode_info->HorizontalResolution &&
-                 rows == mode_info->VerticalResolution &&
-                 (!depth || bpp == depth) )
+            for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
             {
-                gop_mode = i;
-                break;
-            }
-            if ( !cols && !rows &&
-                 mode_info->HorizontalResolution *
-                 mode_info->VerticalResolution > size )
-            {
-                size = mode_info->HorizontalResolution *
-                       mode_info->VerticalResolution;
-                gop_mode = i;
+                unsigned int bpp = 0;
+
+                status = gop->QueryMode(gop, i, &info_size, &mode_info);
+                if ( EFI_ERROR(status) )
+                    continue;
+                switch ( mode_info->PixelFormat )
+                {
+                case PixelBitMask:
+                    bpp = hweight32(mode_info->PixelInformation.RedMask |
+                                    mode_info->PixelInformation.GreenMask |
+                                    mode_info->PixelInformation.BlueMask);
+                    break;
+                case PixelRedGreenBlueReserved8BitPerColor:
+                case PixelBlueGreenRedReserved8BitPerColor:
+                    bpp = 24;
+                    break;
+                default:
+                    continue;
+                }
+                if ( cols == mode_info->HorizontalResolution &&
+                     rows == mode_info->VerticalResolution &&
+                     (!depth || bpp == depth) )
+                {
+                    gop_mode = i;
+                    break;
+                }
+                if ( !cols && !rows &&
+                     mode_info->HorizontalResolution *
+                     mode_info->VerticalResolution > size )
+                {
+                    size = mode_info->HorizontalResolution *
+                           mode_info->VerticalResolution;
+                    gop_mode = i;
+                }
             }
         }
     }
-- 
2.1.0


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 04:46:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 04:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlW0W-00048G-AP; Tue, 04 Nov 2014 04:46:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlW0U-00048B-Es
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 04:46:14 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	72/1D-02954-51A58545; Tue, 04 Nov 2014 04:46:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415076371!12335556!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19779 invoked from network); 4 Nov 2014 04:46:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 04:46:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,311,1413244800"; d="scan'208";a="187789028"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 23:46:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlW0Q-0003fo-11;
	Tue, 04 Nov 2014 04:46:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlW0P-0006WH-On;
	Tue, 04 Nov 2014 04:46:09 +0000
Date: Tue, 4 Nov 2014 04:46:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31346-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9785
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31346: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7949873392116334143=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7949873392116334143==
Content-Type: text/plain
Content-Length: 9509
Content-Transfer-Encoding: quoted-printable

flight 31346 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31346/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass

version targeted for testing:
 qemuu                0a2923f8488498000eec54871456aa64a4391da4
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Walle <michael@walle.cc> (for lm32)
  Mikhail Ilyin <m.ilin@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============7949873392116334143==--

From xen-devel-bounces@lists.xen.org Tue Nov 04 04:46:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 04:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlW0W-00048G-AP; Tue, 04 Nov 2014 04:46:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlW0U-00048B-Es
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 04:46:14 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	72/1D-02954-51A58545; Tue, 04 Nov 2014 04:46:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415076371!12335556!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19779 invoked from network); 4 Nov 2014 04:46:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 04:46:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,311,1413244800"; d="scan'208";a="187789028"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 3 Nov 2014 23:46:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlW0Q-0003fo-11;
	Tue, 04 Nov 2014 04:46:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlW0P-0006WH-On;
	Tue, 04 Nov 2014 04:46:09 +0000
Date: Tue, 4 Nov 2014 04:46:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31346-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9785
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31346: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7949873392116334143=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7949873392116334143==
Content-Type: text/plain
Content-Length: 9509
Content-Transfer-Encoding: quoted-printable

flight 31346 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31346/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass

version targeted for testing:
 qemuu                0a2923f8488498000eec54871456aa64a4391da4
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Walle <michael@walle.cc> (for lm32)
  Mikhail Ilyin <m.ilin@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============7949873392116334143==--

From xen-devel-bounces@lists.xen.org Tue Nov 04 05:06:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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.xen.org>)
	id 1XlWJW-0004ky-Dj; Tue, 04 Nov 2014 05:05:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlWJV-0004kt-0N
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 05:05:53 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	2A/59-22819-0BE58545; Tue, 04 Nov 2014 05:05:52 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415077551!11050164!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6139 invoked from network); 4 Nov 2014 05:05:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-7.tower-206.messagelabs.com with SMTP;
	4 Nov 2014 05:05:51 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 03 Nov 2014 21:03:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,311,1413270000"; d="scan'208";a="601736432"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.157])
	([10.238.128.157])
	by orsmga001.jf.intel.com with ESMTP; 03 Nov 2014 21:05:47 -0800
Message-ID: <54585EAA.20904@intel.com>
Date: Tue, 04 Nov 2014 13:05:46 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
In-Reply-To: <545784830200007800044627@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 20:34, Jan Beulich wrote:
>>>> On 03.11.14 at 12:58, <tiejun.chen@intel.com> wrote:
>> Firstly we have a rule that we just allow all devices associated one
>> RMRR to be assign same VM, right? So I mean while we create VM, we
>> always call current hypercall but inside hypercall, Xen can know which
>> devices will be assigned to this VM.
>
> I.e. the hypercall (at least optionally) becomes per-domain rather
> than global. And you imply that device assignment happens
> before memory getting populated (which likely can be arranged

I tried to find a clue about this point but unfortunately I can't trace 
when we assign device exactly. But in theory, based on your hint I 
prefer the device assignment should follow memory getting populated. 
Because when we add a device, we need to create iommu map so this means 
at this moment the guest should already finish populating memory, right?

Thanks
Tiejun

> for in the tool stack if that's not already the case, but which isn't
> currently mandated by the hypervisor).
>
> Jan
>
>> So Xen still lookup that RMRR list
>> but now Xen would check if these RMRR belongs to that device we want to
>> assign this domain. If yes, we just let that callback go through these
>> RMRR info from that list but exclude other unrelated RMRR. If not, we
>> don't go through any RMRR info so that 'nr_entries' is also zero.
>>
>> Thanks
>> Tiejun
>
>
>

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 05:06:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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.xen.org>)
	id 1XlWJW-0004ky-Dj; Tue, 04 Nov 2014 05:05:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlWJV-0004kt-0N
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 05:05:53 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	2A/59-22819-0BE58545; Tue, 04 Nov 2014 05:05:52 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415077551!11050164!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6139 invoked from network); 4 Nov 2014 05:05:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-7.tower-206.messagelabs.com with SMTP;
	4 Nov 2014 05:05:51 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 03 Nov 2014 21:03:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,311,1413270000"; d="scan'208";a="601736432"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.157])
	([10.238.128.157])
	by orsmga001.jf.intel.com with ESMTP; 03 Nov 2014 21:05:47 -0800
Message-ID: <54585EAA.20904@intel.com>
Date: Tue, 04 Nov 2014 13:05:46 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
In-Reply-To: <545784830200007800044627@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 20:34, Jan Beulich wrote:
>>>> On 03.11.14 at 12:58, <tiejun.chen@intel.com> wrote:
>> Firstly we have a rule that we just allow all devices associated one
>> RMRR to be assign same VM, right? So I mean while we create VM, we
>> always call current hypercall but inside hypercall, Xen can know which
>> devices will be assigned to this VM.
>
> I.e. the hypercall (at least optionally) becomes per-domain rather
> than global. And you imply that device assignment happens
> before memory getting populated (which likely can be arranged

I tried to find a clue about this point but unfortunately I can't trace 
when we assign device exactly. But in theory, based on your hint I 
prefer the device assignment should follow memory getting populated. 
Because when we add a device, we need to create iommu map so this means 
at this moment the guest should already finish populating memory, right?

Thanks
Tiejun

> for in the tool stack if that's not already the case, but which isn't
> currently mandated by the hypervisor).
>
> Jan
>
>> So Xen still lookup that RMRR list
>> but now Xen would check if these RMRR belongs to that device we want to
>> assign this domain. If yes, we just let that callback go through these
>> RMRR info from that list but exclude other unrelated RMRR. If not, we
>> don't go through any RMRR info so that 'nr_entries' is also zero.
>>
>> Thanks
>> Tiejun
>
>
>

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 07:50:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 07: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 1XlYsI-0007X2-HA; Tue, 04 Nov 2014 07:49:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlYsH-0007Wx-1h
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 07:49:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AC/5D-09842-32588545; Tue, 04 Nov 2014 07:49:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415087395!12584750!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6707 invoked from network); 4 Nov 2014 07:49:55 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 07:49:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 07:49:54 +0000
Message-Id: <5458932F0200007800044A4E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 07:49:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roy Franz" <roy.franz@linaro.org>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
	<CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
In-Reply-To: <CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 05:31, <roy.franz@linaro.org> wrote:
> On Mon, Nov 3, 2014 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
>>> This patch implements what I understand to be the desired behavior when
>>> booting
>>> an EFI Xen image via GRUB based on the thread last week.  The EFI command
>>> line
>>> is not used, and the Xen commandline comes via the multiboot protocol (and
>>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
>>> GRUB EFI boot cases into alignment in not using the EFI commandline.
>>
>> Right, but ...
>>
>>> The current state of the arm64 code takes the Xen commandline from the FDT,
>>> but still looks in the EFI commandline for EFI boot specific options.  If
>>> unexpected options are passed in the EFI commandline, it will generate
>>> "unrecognized option" ouput for all unexpected options.
>>
>> ... why is this?
> 
> The EFI boot code did this before any of the arm64 changes, and that
> behavior is unchanged.
> The actual message is "WARNING: Unknown command line option"
> 
> I was simply trying to explain the current behavior regarding the EFI
> commandline.

Argh, I should have stripped that second sentence from the quoted
context, as the question was regarding the apparently special ARM64
behavior you describe.

>>> +    if ( use_cfg_file )
>>>      {
>>>          EFI_FILE_HANDLE dir_handle;
>>> +        size = 0;
>>
>> Coding style (missing blank line between declaration(s) and
>> statement(s). Plus - did you check whether some of the so far
>> function wide variables (e.g. gop) could be moved into this more
>> narrow scope?
> 
> I'll fix the style.  I had not reviewed scope, but now have.  There
> are only a few
> variables I can reduce in scope, which I have done in V2 of the patch
> which I will post shortly.
> The gop variable and a few others cannot be moved without further code
> reorganization.  The graphics
> mode is set later in efi_start() if gop is !null (line 1035)
> I don't see any reason this code couldn't be moved to be in the if (
> use_cfg_file ) block, but given that
> this patch is very late in the release cycle, I'm opting to try to
> keep this patch minimal.  If you would prefer
> me to move this code and variables, I am happy to do a v3 with these 
> changes.

No, I'm perfectly fine with your decision not to do a larger re-org.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 07:50:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 07: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 1XlYsI-0007X2-HA; Tue, 04 Nov 2014 07:49:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlYsH-0007Wx-1h
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 07:49:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AC/5D-09842-32588545; Tue, 04 Nov 2014 07:49:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415087395!12584750!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6707 invoked from network); 4 Nov 2014 07:49:55 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 07:49:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 07:49:54 +0000
Message-Id: <5458932F0200007800044A4E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 07:49:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roy Franz" <roy.franz@linaro.org>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
	<CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
In-Reply-To: <CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 05:31, <roy.franz@linaro.org> wrote:
> On Mon, Nov 3, 2014 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
>>> This patch implements what I understand to be the desired behavior when
>>> booting
>>> an EFI Xen image via GRUB based on the thread last week.  The EFI command
>>> line
>>> is not used, and the Xen commandline comes via the multiboot protocol (and
>>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
>>> GRUB EFI boot cases into alignment in not using the EFI commandline.
>>
>> Right, but ...
>>
>>> The current state of the arm64 code takes the Xen commandline from the FDT,
>>> but still looks in the EFI commandline for EFI boot specific options.  If
>>> unexpected options are passed in the EFI commandline, it will generate
>>> "unrecognized option" ouput for all unexpected options.
>>
>> ... why is this?
> 
> The EFI boot code did this before any of the arm64 changes, and that
> behavior is unchanged.
> The actual message is "WARNING: Unknown command line option"
> 
> I was simply trying to explain the current behavior regarding the EFI
> commandline.

Argh, I should have stripped that second sentence from the quoted
context, as the question was regarding the apparently special ARM64
behavior you describe.

>>> +    if ( use_cfg_file )
>>>      {
>>>          EFI_FILE_HANDLE dir_handle;
>>> +        size = 0;
>>
>> Coding style (missing blank line between declaration(s) and
>> statement(s). Plus - did you check whether some of the so far
>> function wide variables (e.g. gop) could be moved into this more
>> narrow scope?
> 
> I'll fix the style.  I had not reviewed scope, but now have.  There
> are only a few
> variables I can reduce in scope, which I have done in V2 of the patch
> which I will post shortly.
> The gop variable and a few others cannot be moved without further code
> reorganization.  The graphics
> mode is set later in efi_start() if gop is !null (line 1035)
> I don't see any reason this code couldn't be moved to be in the if (
> use_cfg_file ) block, but given that
> this patch is very late in the release cycle, I'm opting to try to
> keep this patch minimal.  If you would prefer
> me to move this code and variables, I am happy to do a v3 with these 
> changes.

No, I'm perfectly fine with your decision not to do a larger re-org.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 07:55:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 07:55:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlYxE-0007nb-CN; Tue, 04 Nov 2014 07:55:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlYxD-0007nU-4T
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 07:55:03 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	97/65-25547-65688545; Tue, 04 Nov 2014 07:55:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415087701!9001518!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25005 invoked from network); 4 Nov 2014 07:55:01 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 07:55:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 07:55:00 +0000
Message-Id: <545894610200007800044A5B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 07:54:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
In-Reply-To: <54585EAA.20904@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 06:05, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 20:34, Jan Beulich wrote:
>>>>> On 03.11.14 at 12:58, <tiejun.chen@intel.com> wrote:
>>> Firstly we have a rule that we just allow all devices associated one
>>> RMRR to be assign same VM, right? So I mean while we create VM, we
>>> always call current hypercall but inside hypercall, Xen can know which
>>> devices will be assigned to this VM.
>>
>> I.e. the hypercall (at least optionally) becomes per-domain rather
>> than global. And you imply that device assignment happens
>> before memory getting populated (which likely can be arranged
> 
> I tried to find a clue about this point but unfortunately I can't trace 
> when we assign device exactly. But in theory, based on your hint I 
> prefer the device assignment should follow memory getting populated. 
> Because when we add a device, we need to create iommu map so this means 
> at this moment the guest should already finish populating memory, right?

There's no such strong connection: When a device gets assigned,
IOMMU mappings get created for all memory the guest already has
assigned (which at least in theory can include the "none" case).
When (more) memory gets assigned after a device was already
assigned to the guest, the IOMMU mappings would simply get
updated.

While I think you're right in that memory assignment happens
before device assignment, for your specific purpose it might have
been easier the other way around, since when memory gets
populated first you'll need special peeking into which devices will
get assigned later in order to avoid the respective RMRR areas,
or you'll need to modify device assignment code to move the
RAM populated there out of the way.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 07:55:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 07:55:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlYxE-0007nb-CN; Tue, 04 Nov 2014 07:55:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlYxD-0007nU-4T
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 07:55:03 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	97/65-25547-65688545; Tue, 04 Nov 2014 07:55:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415087701!9001518!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25005 invoked from network); 4 Nov 2014 07:55:01 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 07:55:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 07:55:00 +0000
Message-Id: <545894610200007800044A5B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 07:54:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-7-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
In-Reply-To: <54585EAA.20904@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 06:05, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 20:34, Jan Beulich wrote:
>>>>> On 03.11.14 at 12:58, <tiejun.chen@intel.com> wrote:
>>> Firstly we have a rule that we just allow all devices associated one
>>> RMRR to be assign same VM, right? So I mean while we create VM, we
>>> always call current hypercall but inside hypercall, Xen can know which
>>> devices will be assigned to this VM.
>>
>> I.e. the hypercall (at least optionally) becomes per-domain rather
>> than global. And you imply that device assignment happens
>> before memory getting populated (which likely can be arranged
> 
> I tried to find a clue about this point but unfortunately I can't trace 
> when we assign device exactly. But in theory, based on your hint I 
> prefer the device assignment should follow memory getting populated. 
> Because when we add a device, we need to create iommu map so this means 
> at this moment the guest should already finish populating memory, right?

There's no such strong connection: When a device gets assigned,
IOMMU mappings get created for all memory the guest already has
assigned (which at least in theory can include the "none" case).
When (more) memory gets assigned after a device was already
assigned to the guest, the IOMMU mappings would simply get
updated.

While I think you're right in that memory assignment happens
before device assignment, for your specific purpose it might have
been easier the other way around, since when memory gets
populated first you'll need special peeking into which devices will
get assigned later in order to avoid the respective RMRR areas,
or you'll need to modify device assignment code to move the
RAM populated there out of the way.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 08:02:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 08:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlZ41-0008T5-1Q; Tue, 04 Nov 2014 08:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlZ3z-0008Sk-SF
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 08:02:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	23/2A-24532-BF788545; Tue, 04 Nov 2014 08:02:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415088122!5280856!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31136 invoked from network); 4 Nov 2014 08:02:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 08:02:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 08:02:02 +0000
Message-Id: <545896080200007800044A67@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 08:02:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
	<54577AD302000078000445EB@mail.emea.novell.com>
	<54582D59.4020201@intel.com>
In-Reply-To: <54582D59.4020201@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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 04.11.14 at 02:35, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 19:53, Jan Beulich wrote:
>>>>> On 03.11.14 at 12:48, <tiejun.chen@intel.com> wrote:
>>> On 2014/11/3 18:03, Jan Beulich wrote:
>>>>>>> On 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>>>>>> #2 the error handling
>>>>>>>
>>>>>>> In an error case what should I do? Currently we still create these
>>>>>>> mapping as normal. This means these mfns will be valid so later we can't
>>>>>>> set them again then device can't be assigned as passthrough. I think
>>>>>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>>>>>
>>>>>> You should, with very few exceptions, not ignore errors (which
>>>>>> includes "handling" them by just logging a message. Instead, you
>>>>>> should propagate the error back up the call chain.
>>>>>>
>>>>>
>>>>> Do you mean in your patch,
>>>>>
>>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>>> +{
>>>>> +    const struct iommu_ops *ops = iommu_get_ops();
>>>>> +
>>>>> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
>>>>> +        return 0;
>>>>> +
>>>>> +    return ops->get_reserved_device_memory(func, ctxt);
>>>>> +}
>>>>> +
>>>>>
>>>>> I shouldn't return that directly. Then instead, we should handle all
>>>>> error scenarios here?
>>>>
>>>> No. All error scenarios are already being handled here (by
>>>> propagating the error code to the caller).
>>>
>>> Sorry, how to propagate the error code?
>>
>> Return it to the caller (and it will do so onwards, until it reaches
>> [presumably] the entity having invoked a hypercall).
> 
> I guess you mean we should return out in this error case,

Yes!

> @@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>       /* Now, actually do the two-way mapping */
>       if ( mfn_valid(_mfn(mfn)) )
>       {
> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
> -                           p2m->default_access);
> +        rc = 0;
> +        a =  p2m->default_access;
> +        if ( !is_hardware_domain(d) )
> +        {
> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &gfn);
> +            /* We always avoid populating reserved device memory. */
> +            if ( rc == 1 )
> +                goto out;

But you'll need to make sure that you don't return 1 to the callers:
They expect 0 or negative error codes. But with the model of
not even populating these regions (or relocating the memory
before [at boot time] assigning a device associated with an RMRR)
I think this needs to become an error anyway.

> +            else if ( rc < 0 )
> +            {
> +                printk(XENLOG_G_WARNING
> +                       "Dom%d can't check reserved device memory.\n",

Actually, d being the subject domain, please make this more like
"Can't check reserved device memory for Dom%d\n".

Jan

> +                       d->domain_id);
> +                goto out;
> +            }
> +        }
> +
> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
>           if ( rc )
>               goto out; /* Failed to update p2m, bail without updating m2p. */
> 
> Thanks
> Tiejun




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

From xen-devel-bounces@lists.xen.org Tue Nov 04 08:02:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 08:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlZ41-0008T5-1Q; Tue, 04 Nov 2014 08:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlZ3z-0008Sk-SF
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 08:02:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	23/2A-24532-BF788545; Tue, 04 Nov 2014 08:02:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415088122!5280856!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31136 invoked from network); 4 Nov 2014 08:02:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 08:02:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 08:02:02 +0000
Message-Id: <545896080200007800044A67@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 08:02:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
	<54577AD302000078000445EB@mail.emea.novell.com>
	<54582D59.4020201@intel.com>
In-Reply-To: <54582D59.4020201@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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 04.11.14 at 02:35, <tiejun.chen@intel.com> wrote:
> On 2014/11/3 19:53, Jan Beulich wrote:
>>>>> On 03.11.14 at 12:48, <tiejun.chen@intel.com> wrote:
>>> On 2014/11/3 18:03, Jan Beulich wrote:
>>>>>>> On 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>>>>>> #2 the error handling
>>>>>>>
>>>>>>> In an error case what should I do? Currently we still create these
>>>>>>> mapping as normal. This means these mfns will be valid so later we can't
>>>>>>> set them again then device can't be assigned as passthrough. I think
>>>>>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>>>>>
>>>>>> You should, with very few exceptions, not ignore errors (which
>>>>>> includes "handling" them by just logging a message. Instead, you
>>>>>> should propagate the error back up the call chain.
>>>>>>
>>>>>
>>>>> Do you mean in your patch,
>>>>>
>>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>>> +{
>>>>> +    const struct iommu_ops *ops = iommu_get_ops();
>>>>> +
>>>>> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
>>>>> +        return 0;
>>>>> +
>>>>> +    return ops->get_reserved_device_memory(func, ctxt);
>>>>> +}
>>>>> +
>>>>>
>>>>> I shouldn't return that directly. Then instead, we should handle all
>>>>> error scenarios here?
>>>>
>>>> No. All error scenarios are already being handled here (by
>>>> propagating the error code to the caller).
>>>
>>> Sorry, how to propagate the error code?
>>
>> Return it to the caller (and it will do so onwards, until it reaches
>> [presumably] the entity having invoked a hypercall).
> 
> I guess you mean we should return out in this error case,

Yes!

> @@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>       /* Now, actually do the two-way mapping */
>       if ( mfn_valid(_mfn(mfn)) )
>       {
> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
> -                           p2m->default_access);
> +        rc = 0;
> +        a =  p2m->default_access;
> +        if ( !is_hardware_domain(d) )
> +        {
> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &gfn);
> +            /* We always avoid populating reserved device memory. */
> +            if ( rc == 1 )
> +                goto out;

But you'll need to make sure that you don't return 1 to the callers:
They expect 0 or negative error codes. But with the model of
not even populating these regions (or relocating the memory
before [at boot time] assigning a device associated with an RMRR)
I think this needs to become an error anyway.

> +            else if ( rc < 0 )
> +            {
> +                printk(XENLOG_G_WARNING
> +                       "Dom%d can't check reserved device memory.\n",

Actually, d being the subject domain, please make this more like
"Can't check reserved device memory for Dom%d\n".

Jan

> +                       d->domain_id);
> +                goto out;
> +            }
> +        }
> +
> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
>           if ( rc )
>               goto out; /* Failed to update p2m, bail without updating m2p. */
> 
> Thanks
> Tiejun




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

From xen-devel-bounces@lists.xen.org Tue Nov 04 08:16:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 08:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlZHi-0000UD-T0; Tue, 04 Nov 2014 08:16:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlZHh-0000U8-Cj
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 08:16:13 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	8D/3E-01660-C4B88545; Tue, 04 Nov 2014 08:16:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415088970!11029681!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10976 invoked from network); 4 Nov 2014 08:16:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 08:16:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189204219"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 03:16:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlZHc-0004iN-O1;
	Tue, 04 Nov 2014 08:16:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlZHc-0007ec-I3;
	Tue, 04 Nov 2014 08:16:08 +0000
Date: Tue, 4 Nov 2014 08:16:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31348-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31348: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt      7 debian-install          fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-i386-xl-credit2    9 guest-start             fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf      9 guest-start             fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl            3 host-install(3)       broken baseline untested
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate/x10 fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                a641d0e16b552f986e8c4a8735e66a1443a769cf
baseline version:
 linux                9f935675d41aa51ebf929fc977cf530ff7d1a7fc

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         broken  
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

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


Push not applicable.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 08:16:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 08:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlZHi-0000UD-T0; Tue, 04 Nov 2014 08:16:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlZHh-0000U8-Cj
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 08:16:13 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	8D/3E-01660-C4B88545; Tue, 04 Nov 2014 08:16:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415088970!11029681!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10976 invoked from network); 4 Nov 2014 08:16:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 08:16:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189204219"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 03:16:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlZHc-0004iN-O1;
	Tue, 04 Nov 2014 08:16:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlZHc-0007ec-I3;
	Tue, 04 Nov 2014 08:16:08 +0000
Date: Tue, 4 Nov 2014 08:16:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31348-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31348: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt      7 debian-install          fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-i386-xl-credit2    9 guest-start             fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf      9 guest-start             fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl            3 host-install(3)       broken baseline untested
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate/x10 fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                a641d0e16b552f986e8c4a8735e66a1443a769cf
baseline version:
 linux                9f935675d41aa51ebf929fc977cf530ff7d1a7fc

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         broken  
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

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


Push not applicable.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 08:20:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 08:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlZLd-0000cA-Jm; Tue, 04 Nov 2014 08:20:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1XlZLb-0000c4-QG
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 08:20:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C0/1E-09936-F3C88545; Tue, 04 Nov 2014 08:20:15 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415089214!5285638!1
X-Originating-IP: [62.142.5.110]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTEwID0+IDkyMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7599 invoked from network); 4 Nov 2014 08:20:14 -0000
Received: from emh04.mail.saunalahti.fi (HELO emh04.mail.saunalahti.fi)
	(62.142.5.110)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 08:20:14 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 238331A2650;
	Tue,  4 Nov 2014 10:20:12 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 67D4D36C01F; Tue,  4 Nov 2014 10:20:12 +0200 (EET)
Date: Tue, 4 Nov 2014 10:20:12 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Steve Freitas <sflist@ihonk.com>
Message-ID: <20141104082012.GY12451@reaktio.net>
References: <5457F79B.2020300@ihonk.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5457F79B.2020300@ihonk.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 01:46:03PM -0800, Steve Freitas wrote:
> Hi all,
> 

Hello,

> I've got a Windows 7 x64 VM that is stable on 4.4.1 but crashes the
> host after a few hours on 4.5rc1. The machine is a ThinkStation D20,
> an X5660 with 5500-series chipset with an Nvidia Quadro FX4800
> (genuine) passed through. Distro is Debian Jessie running stock
> distro kernel and seabios. Both 4.4.1 and 4.5rc1 were built from
> source. Apologies if this issue has already been spotted but I can't
> keep up with the traffic on this list! :-)
> 
> It looks as if something is stepping on PCI devices when the crash
> happens. In the log included below, it's the SATA system that's
> complaining but I've seen it hit the ethernet chip first, then SATA
> after that. I'm happy to troubleshoot, apply patches, give more
> information, etc.
> 
> I've seen the crash when running Windows Update, when running the
> Unigine graphics benchmark, when running an Avast anti-virus scan.
> Haven't found a common thread.
> 
> Don, one curious thing I noted which may be of no value whatsoever:
> Under 4.4.1, I can't give the VM > 3.5 gigs of RAM without breaking
> VGA passthrough. Under 4.5rc1 I can give the VM more than 3.5 gigs,
> yet I *don't* need to use the "mmio_hole" settings in the VM config.
> Not sure why or what that might signify, if anything.
> 

Does it run stable with Xen 4.5 without PCI/GPU passthru? 


> Possibly useful information follows.
> 
> Thanks,
> 
> Steve
> 
> 
> (I was monitoring syslog over a network connection since nothing of
> value can be saved to disk under the circumstances.)
> 

It'd be very helpful if you could set up a serial console to log all the Xen and dom0 Linux kernel messages,
so we could see where it actually crashes..


-- Pasi


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 08:20:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 08:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlZLd-0000cA-Jm; Tue, 04 Nov 2014 08:20:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1XlZLb-0000c4-QG
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 08:20:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C0/1E-09936-F3C88545; Tue, 04 Nov 2014 08:20:15 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415089214!5285638!1
X-Originating-IP: [62.142.5.110]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTEwID0+IDkyMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7599 invoked from network); 4 Nov 2014 08:20:14 -0000
Received: from emh04.mail.saunalahti.fi (HELO emh04.mail.saunalahti.fi)
	(62.142.5.110)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 08:20:14 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 238331A2650;
	Tue,  4 Nov 2014 10:20:12 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 67D4D36C01F; Tue,  4 Nov 2014 10:20:12 +0200 (EET)
Date: Tue, 4 Nov 2014 10:20:12 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Steve Freitas <sflist@ihonk.com>
Message-ID: <20141104082012.GY12451@reaktio.net>
References: <5457F79B.2020300@ihonk.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5457F79B.2020300@ihonk.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 01:46:03PM -0800, Steve Freitas wrote:
> Hi all,
> 

Hello,

> I've got a Windows 7 x64 VM that is stable on 4.4.1 but crashes the
> host after a few hours on 4.5rc1. The machine is a ThinkStation D20,
> an X5660 with 5500-series chipset with an Nvidia Quadro FX4800
> (genuine) passed through. Distro is Debian Jessie running stock
> distro kernel and seabios. Both 4.4.1 and 4.5rc1 were built from
> source. Apologies if this issue has already been spotted but I can't
> keep up with the traffic on this list! :-)
> 
> It looks as if something is stepping on PCI devices when the crash
> happens. In the log included below, it's the SATA system that's
> complaining but I've seen it hit the ethernet chip first, then SATA
> after that. I'm happy to troubleshoot, apply patches, give more
> information, etc.
> 
> I've seen the crash when running Windows Update, when running the
> Unigine graphics benchmark, when running an Avast anti-virus scan.
> Haven't found a common thread.
> 
> Don, one curious thing I noted which may be of no value whatsoever:
> Under 4.4.1, I can't give the VM > 3.5 gigs of RAM without breaking
> VGA passthrough. Under 4.5rc1 I can give the VM more than 3.5 gigs,
> yet I *don't* need to use the "mmio_hole" settings in the VM config.
> Not sure why or what that might signify, if anything.
> 

Does it run stable with Xen 4.5 without PCI/GPU passthru? 


> Possibly useful information follows.
> 
> Thanks,
> 
> Steve
> 
> 
> (I was monitoring syslog over a network connection since nothing of
> value can be saved to disk under the circumstances.)
> 

It'd be very helpful if you could set up a serial console to log all the Xen and dom0 Linux kernel messages,
so we could see where it actually crashes..


-- Pasi


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 08:57:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 08:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlZum-0001Nm-Hg; Tue, 04 Nov 2014 08:56:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XlZul-0001Nh-1C
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 08:56:35 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	D0/D9-31453-2C498545; Tue, 04 Nov 2014 08:56:34 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415091392!11087985!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13368 invoked from network); 4 Nov 2014 08:56:33 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 08:56:33 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=2yc3eDz21DDf9I1FMFgkcymE10EWCc3YazMEPSqZad0LixJXnepHdbiYdFZ9Eg4LJOeleFU3jWbGfHKT/C9FRlehdVZ1ZjMH0kgdfqlXD/iXMbvHReKRnRN6kDzqI/4F7jht8oRY5cZS/BPtqsVoWlvayYeRsFlCv9vXZFM9U+l0BlW8I61VKMbK+CAP8pPaEaF/Oqt3q4CVdomQkFILXVpcWcUwjFHGxQYKLOR1qtlVlo1ehWM3lIEaneguLq5FSYF/73+F39h+CUvo9OhA3XkZibYp6iv1jTZvloHDp1TL8ud9zY55RG4zZF6c4sYs084gi+TNFVW51EaYugFQMw==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=from:to
	:cc:subject:date:message-id; s=default; bh=IFyAFyHLVUkLOusX5Er3g
	LPyFr4=; b=1mPwVL2KaLUqyw7M0QQTgjEvqVwaqceJ0bsMNoOd1933brVJaIzSY
	V9mHyi1tO/SkGOdk/JqS4eIcUss/WBSHg2a8S2ZEp2ifsa1/yjdOjhuZbw2jqWqA
	xkzel7qDDhOIS/Mva0945egjLClJN0CRWiVdn78B1jVBSHPWTGB+yr7YbI/lZbId
	InXWASQ/6ueBPeRAxHsdIR43+lcBmECU+3c4hnHgrDmqmsUC9/5bDjvaT8tYIlK8
	IFH1Mkk17fDdNoHL6Icgql0/qqWxIaunI6mRZqmWCy+N0UYIdPRzG/W/ylksyeUY
	ggzejsFg5ySu+h91YlYZ39xrh46E2QoKw==
Received: (qmail 28105 invoked from network); 4 Nov 2014 10:56:04 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	4 Nov 2014 10:56:04 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 5F72A80343
	for <xen-devel@lists.xen.org>; Tue,  4 Nov 2014 10:56:04 +0200 (EET)
Received: (qmail 15495 invoked from network); 4 Nov 2014 10:56:04 +0200
Received: from xen.dsd.ro (HELO xen.dsd.bitdefender.biz)
	(rcojocaru@bitdefender.com@10.10.14.109)
	by smtp03.buh.bitdefender.org with AES256-SHA encrypted SMTP;
	4 Nov 2014 10:56:04 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 10:55:47 +0200
Message-Id: <1415091347-3898-1-git-send-email-rcojocaru@bitdefender.com>
X-Mailer: git-send-email 1.7.9.5
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.57548
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.520, Dats: 371409,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_LARGER;
	NN_NO_CONTENT_TYPE; NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER;
	NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled],
	URL: [Enabled], RTDA: [Enabled, Hit: No, Details: v1.9.3; Id:
	2m1ghdn.1957q4tco.2bmskb], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: keir@xen.org, Razvan Cojocaru <rcojocaru@bitdefender.com>,
	jbeulich@suse.com
Subject: [Xen-devel] [PATCH V2] xen: Disable emulate.c REP optimization if
	introspection is active
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Emulation for REP instructions is optimized to perform a single
write for all repeats in the current page if possible. However,
this interferes with a memory introspection application's ability
to detect suspect behaviour, since it will cause only one
mem_event to be sent per page touched.
This patch disables the optimization, gated on introspection
being active for the domain.

Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

---
Changes since V1:
 - Modified comment to explain why introspection_enabled is a
   special case.
 - Removed the struct domain *currd = current->domain intermediary
   variable.
 - Changed the if statement into a ternary operator line.
 - Wrapped the introspection_enabled test in an unlikely().
---
 xen/arch/x86/hvm/emulate.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index c0f47d2..14c1847 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -406,8 +406,13 @@ static int hvmemul_virtual_to_linear(
      * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
      * The chosen maximum is very conservative but it's what we use in
      * hvmemul_linear_to_phys() so there is no point in using a larger value.
+     * If introspection has been enabled for this domain, *reps should be
+     * at most 1, since optimization might otherwise cause a single mem_event
+     * being triggered for repeated writes to a whole page.
      */
-    *reps = min_t(unsigned long, *reps, 4096);
+    *reps = min_t(unsigned long, *reps,
+                  unlikely(current->domain->arch.hvm_domain.introspection_enabled)
+                           ? 1 : 4096);
 
     reg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
 
-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 08:57:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 08:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlZum-0001Nm-Hg; Tue, 04 Nov 2014 08:56:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XlZul-0001Nh-1C
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 08:56:35 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	D0/D9-31453-2C498545; Tue, 04 Nov 2014 08:56:34 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415091392!11087985!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13368 invoked from network); 4 Nov 2014 08:56:33 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 08:56:33 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=2yc3eDz21DDf9I1FMFgkcymE10EWCc3YazMEPSqZad0LixJXnepHdbiYdFZ9Eg4LJOeleFU3jWbGfHKT/C9FRlehdVZ1ZjMH0kgdfqlXD/iXMbvHReKRnRN6kDzqI/4F7jht8oRY5cZS/BPtqsVoWlvayYeRsFlCv9vXZFM9U+l0BlW8I61VKMbK+CAP8pPaEaF/Oqt3q4CVdomQkFILXVpcWcUwjFHGxQYKLOR1qtlVlo1ehWM3lIEaneguLq5FSYF/73+F39h+CUvo9OhA3XkZibYp6iv1jTZvloHDp1TL8ud9zY55RG4zZF6c4sYs084gi+TNFVW51EaYugFQMw==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=from:to
	:cc:subject:date:message-id; s=default; bh=IFyAFyHLVUkLOusX5Er3g
	LPyFr4=; b=1mPwVL2KaLUqyw7M0QQTgjEvqVwaqceJ0bsMNoOd1933brVJaIzSY
	V9mHyi1tO/SkGOdk/JqS4eIcUss/WBSHg2a8S2ZEp2ifsa1/yjdOjhuZbw2jqWqA
	xkzel7qDDhOIS/Mva0945egjLClJN0CRWiVdn78B1jVBSHPWTGB+yr7YbI/lZbId
	InXWASQ/6ueBPeRAxHsdIR43+lcBmECU+3c4hnHgrDmqmsUC9/5bDjvaT8tYIlK8
	IFH1Mkk17fDdNoHL6Icgql0/qqWxIaunI6mRZqmWCy+N0UYIdPRzG/W/ylksyeUY
	ggzejsFg5ySu+h91YlYZ39xrh46E2QoKw==
Received: (qmail 28105 invoked from network); 4 Nov 2014 10:56:04 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	4 Nov 2014 10:56:04 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 5F72A80343
	for <xen-devel@lists.xen.org>; Tue,  4 Nov 2014 10:56:04 +0200 (EET)
Received: (qmail 15495 invoked from network); 4 Nov 2014 10:56:04 +0200
Received: from xen.dsd.ro (HELO xen.dsd.bitdefender.biz)
	(rcojocaru@bitdefender.com@10.10.14.109)
	by smtp03.buh.bitdefender.org with AES256-SHA encrypted SMTP;
	4 Nov 2014 10:56:04 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 10:55:47 +0200
Message-Id: <1415091347-3898-1-git-send-email-rcojocaru@bitdefender.com>
X-Mailer: git-send-email 1.7.9.5
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.57548
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.520, Dats: 371409,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_LARGER;
	NN_NO_CONTENT_TYPE; NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER;
	NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled],
	URL: [Enabled], RTDA: [Enabled, Hit: No, Details: v1.9.3; Id:
	2m1ghdn.1957q4tco.2bmskb], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: keir@xen.org, Razvan Cojocaru <rcojocaru@bitdefender.com>,
	jbeulich@suse.com
Subject: [Xen-devel] [PATCH V2] xen: Disable emulate.c REP optimization if
	introspection is active
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Emulation for REP instructions is optimized to perform a single
write for all repeats in the current page if possible. However,
this interferes with a memory introspection application's ability
to detect suspect behaviour, since it will cause only one
mem_event to be sent per page touched.
This patch disables the optimization, gated on introspection
being active for the domain.

Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

---
Changes since V1:
 - Modified comment to explain why introspection_enabled is a
   special case.
 - Removed the struct domain *currd = current->domain intermediary
   variable.
 - Changed the if statement into a ternary operator line.
 - Wrapped the introspection_enabled test in an unlikely().
---
 xen/arch/x86/hvm/emulate.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index c0f47d2..14c1847 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -406,8 +406,13 @@ static int hvmemul_virtual_to_linear(
      * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
      * The chosen maximum is very conservative but it's what we use in
      * hvmemul_linear_to_phys() so there is no point in using a larger value.
+     * If introspection has been enabled for this domain, *reps should be
+     * at most 1, since optimization might otherwise cause a single mem_event
+     * being triggered for repeated writes to a whole page.
      */
-    *reps = min_t(unsigned long, *reps, 4096);
+    *reps = min_t(unsigned long, *reps,
+                  unlikely(current->domain->arch.hvm_domain.introspection_enabled)
+                           ? 1 : 4096);
 
     reg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
 
-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 09:34:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 09:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlaUu-000238-Id; Tue, 04 Nov 2014 09:33:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlaUt-000233-9c
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 09:33:55 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D9/1C-02696-28D98545; Tue, 04 Nov 2014 09:33:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415093632!12385861!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11637 invoked from network); 4 Nov 2014 09:33:52 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 09:33:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 09:33:51 +0000
Message-Id: <5458AB8C0200007800044AFE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 09:33:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1415062817-3584-1-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1415062817-3584-1-git-send-email-tiejun.chen@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v3][PATCH] tools/hvmloader: link errno.h from xen
 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 04.11.14 at 02:00, <tiejun.chen@intel.com> wrote:
> We need to act on some specific hypercall error numbers, so
> require the hypervisor view on the errno.h value rather than
> just the build environment's number. So here link this headfile
> from xen.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>

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

but only if this goes in
- together with code actually using it
- ahead (i.e. still for 4.5) of the planned changes to make error
  indicator values properly part of the hypercall ABI (4.6)

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 09:34:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 09:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlaUu-000238-Id; Tue, 04 Nov 2014 09:33:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlaUt-000233-9c
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 09:33:55 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D9/1C-02696-28D98545; Tue, 04 Nov 2014 09:33:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415093632!12385861!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11637 invoked from network); 4 Nov 2014 09:33:52 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 09:33:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 09:33:51 +0000
Message-Id: <5458AB8C0200007800044AFE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 09:33:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1415062817-3584-1-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1415062817-3584-1-git-send-email-tiejun.chen@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v3][PATCH] tools/hvmloader: link errno.h from xen
 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 04.11.14 at 02:00, <tiejun.chen@intel.com> wrote:
> We need to act on some specific hypercall error numbers, so
> require the hypervisor view on the errno.h value rather than
> just the build environment's number. So here link this headfile
> from xen.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>

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

but only if this goes in
- together with code actually using it
- ahead (i.e. still for 4.5) of the planned changes to make error
  indicator values properly part of the hypercall ABI (4.6)

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 09:37:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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.xen.org>)
	id 1XlaY2-0002AL-68; Tue, 04 Nov 2014 09:37:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlaY0-0002AE-RU
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 09:37:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D9/72-09936-44E98545; Tue, 04 Nov 2014 09:37:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415093826!12570089!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8417 invoked from network); 4 Nov 2014 09:37:07 -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;
	4 Nov 2014 09:37:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187840956"
Message-ID: <1415093823.1411.10.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 4 Nov 2014 09:37:03 +0000
In-Reply-To: <5457A3AD020000780004478B@mail.emea.novell.com>
References: <5457A3AD020000780004478B@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] lzo: refine overrun checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 14:47 +0000, Jan Beulich wrote:
> The original fix we inherited from Linux go re-done. Let's do so too.

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

Mainly on the basis that it was reviewed by Linux maintainers and then
by you rather than because I've looked at it closely myself.

Ian.

> 
> 1: Revert "lzo: properly check for overruns"
> 2: lzo: check for length overrun in variable length encoding
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 09:37:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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.xen.org>)
	id 1XlaY2-0002AL-68; Tue, 04 Nov 2014 09:37:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlaY0-0002AE-RU
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 09:37:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D9/72-09936-44E98545; Tue, 04 Nov 2014 09:37:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415093826!12570089!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8417 invoked from network); 4 Nov 2014 09:37:07 -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;
	4 Nov 2014 09:37:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187840956"
Message-ID: <1415093823.1411.10.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 4 Nov 2014 09:37:03 +0000
In-Reply-To: <5457A3AD020000780004478B@mail.emea.novell.com>
References: <5457A3AD020000780004478B@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] lzo: refine overrun checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 14:47 +0000, Jan Beulich wrote:
> The original fix we inherited from Linux go re-done. Let's do so too.

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

Mainly on the basis that it was reviewed by Linux maintainers and then
by you rather than because I've looked at it closely myself.

Ian.

> 
> 1: Revert "lzo: properly check for overruns"
> 2: lzo: check for length overrun in variable length encoding
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 09:54:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 09:54:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlaoN-0002iv-2F; Tue, 04 Nov 2014 09:54:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlaoM-0002iq-34
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 09:54:02 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	6D/23-03145-932A8545; Tue, 04 Nov 2014 09:54:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415094839!12311978!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21812 invoked from network); 4 Nov 2014 09:54:00 -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;
	4 Nov 2014 09:54:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187844014"
Message-ID: <1415094837.11486.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 09:53:57 +0000
In-Reply-To: <20141103180613.GA5379@laptop.dumpdata.com>
References: <20141103180613.GA5379@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>, pranavkumar@linaro.org
Subject: Re: [Xen-devel] [ARM APM Mustang-X. Xen 4.5-rc1 and staging]
 Booting issues, last meesage: (XEN) P2M: 3 levels with order-1 root,
 VTCR 0x80033558
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 13:06 -0500, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> I've been following: http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/APMXGeneMustang#Preparing_all_the_Images
> with a couple of changes:
> 
> 1) The latest Linux tree in https://github.com/AppliedMicro/ENGLinuxLatest
> looks to have already Xen support in the default config. So used that instead
> of 3.15.
> 
> 
> 2). The 'run xen_run' does not execute properly, but if I run each
>  operation by itself it does get me to boot Xen.
> 
> 
> However I am not sure if the reason I am getting stuck is because I should be
> using 3.15-rc8 instead of the latest? Or perhaps there is another issue?

Looking at the logs it seems like the fdt chosen node isn't actually
getting filled in with the dom0 kernel.

[...]
> libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
> libfdt ND
[...]
> libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
> libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND

These are something failing to manipulate the DTB.

Perhaps you need a "fdt mknod /chosen module@0" somewhere after the "fdt
addr" but before any write to a property under /chosen/module@0?


> Mustang# run xen_load
> Using eth0 device
> TFTP from server 192.168.105.1; our IP address is 192.168.105.51
> Filename 'lab/tst051/uXen'.
> Load address: 0x4000080000
> Loading: *####################################################
> 	 4.1 MiB/s
> done
> Bytes transferred = 755600 (b8790 hex)
> Mustang# fdt print /chosen
> chosen {
> };

No kernel referenced here.
[...]
> (XEN) MODULE[0]: 0000004000ff9000 - 0000004001000000 Device Tree  
> (XEN)  RESVD[0]: 0000004003000000 - 0000004003004000
> (XEN)  RESVD[1]: 0000004000000000 - 0000004000010000

Nor here.

> (XEN) Command line: <NULL>

Also you don't seem to have a Xen command line (which should come from
setenv bootargs, not sure why it doesn't).
[...]
> (XEN) CPU 7 booted.
> (XEN) Brought up 8 CPUs
> (XEN) P2M: 40-bit IPA with 42-bit PA
> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80033558

I expect this cuts off here because we turn off early console around now
and the missing Xen command line means you haven't got a real one.

FWIW my boot script is below, put it in a file boot.txt then run
        mkimage -T script -A arm -d boot.txt boot.scr
to make boot.scr, then load and run it with (from memory):
        tftp $scriptaddr /ianc/pony/boot.scr; source $scriptaddr.
        
Ian.
-----

# Mustang Xen Boot Script

tftp ${fdt_addr_r} /ianc/pony/apm-mustang.dtb

fdt addr ${fdt_addr_r} 0x100000

setenv xen_addr_r 0x4000080000
#  kernel_addr_r= 0x4002000000
# ramdisk_addr_r= 0x4004000000

tftp ${xen_addr_r} /ianc/pony/uXen
setenv bootargs "conswitch=x console=dtuart dtuart=/soc/serial@1c020000"
setenv bootargs "${bootargs} no-bootscrub"
setenv bootargs "${bootargs} noreboot"
setenv bootargs "${bootargs} dom0_mem=256M"

fdt set /chosen bootargs "${bootargs}"
fdt set /chosen \#address-cells <2>
fdt set /chosen \#size-cells <1>

tftp ${kernel_addr_r} /ianc/pony/vmlinuz

fdt mknod /chosen module@4002000000
fdt set /chosen/module@4002000000 compatible "multiboot,module" # "multiboot,kernel"
# kernel_addr_r spans two cells...
fdt set /chosen/module@4002000000 reg <0x40 0x02000000 0x${filesize} >
fdt set /chosen/module@4002000000 bootargs "console=hvc0 root=/dev/sda2 rw earlycon=uart8250,mmio32,0x1c020000 maxcpus=8 swiotlb=4096 kernel.sysrq=1"

fdt resize

fdt print /chosen

bootm ${xen_addr_r} - ${fdt_addr_r}



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 09:54:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 09:54:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlaoN-0002iv-2F; Tue, 04 Nov 2014 09:54:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlaoM-0002iq-34
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 09:54:02 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	6D/23-03145-932A8545; Tue, 04 Nov 2014 09:54:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415094839!12311978!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21812 invoked from network); 4 Nov 2014 09:54:00 -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;
	4 Nov 2014 09:54:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187844014"
Message-ID: <1415094837.11486.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 09:53:57 +0000
In-Reply-To: <20141103180613.GA5379@laptop.dumpdata.com>
References: <20141103180613.GA5379@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>, pranavkumar@linaro.org
Subject: Re: [Xen-devel] [ARM APM Mustang-X. Xen 4.5-rc1 and staging]
 Booting issues, last meesage: (XEN) P2M: 3 levels with order-1 root,
 VTCR 0x80033558
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 13:06 -0500, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> I've been following: http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/APMXGeneMustang#Preparing_all_the_Images
> with a couple of changes:
> 
> 1) The latest Linux tree in https://github.com/AppliedMicro/ENGLinuxLatest
> looks to have already Xen support in the default config. So used that instead
> of 3.15.
> 
> 
> 2). The 'run xen_run' does not execute properly, but if I run each
>  operation by itself it does get me to boot Xen.
> 
> 
> However I am not sure if the reason I am getting stuck is because I should be
> using 3.15-rc8 instead of the latest? Or perhaps there is another issue?

Looking at the logs it seems like the fdt chosen node isn't actually
getting filled in with the dom0 kernel.

[...]
> libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
> libfdt ND
[...]
> libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
> libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND

These are something failing to manipulate the DTB.

Perhaps you need a "fdt mknod /chosen module@0" somewhere after the "fdt
addr" but before any write to a property under /chosen/module@0?


> Mustang# run xen_load
> Using eth0 device
> TFTP from server 192.168.105.1; our IP address is 192.168.105.51
> Filename 'lab/tst051/uXen'.
> Load address: 0x4000080000
> Loading: *####################################################
> 	 4.1 MiB/s
> done
> Bytes transferred = 755600 (b8790 hex)
> Mustang# fdt print /chosen
> chosen {
> };

No kernel referenced here.
[...]
> (XEN) MODULE[0]: 0000004000ff9000 - 0000004001000000 Device Tree  
> (XEN)  RESVD[0]: 0000004003000000 - 0000004003004000
> (XEN)  RESVD[1]: 0000004000000000 - 0000004000010000

Nor here.

> (XEN) Command line: <NULL>

Also you don't seem to have a Xen command line (which should come from
setenv bootargs, not sure why it doesn't).
[...]
> (XEN) CPU 7 booted.
> (XEN) Brought up 8 CPUs
> (XEN) P2M: 40-bit IPA with 42-bit PA
> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80033558

I expect this cuts off here because we turn off early console around now
and the missing Xen command line means you haven't got a real one.

FWIW my boot script is below, put it in a file boot.txt then run
        mkimage -T script -A arm -d boot.txt boot.scr
to make boot.scr, then load and run it with (from memory):
        tftp $scriptaddr /ianc/pony/boot.scr; source $scriptaddr.
        
Ian.
-----

# Mustang Xen Boot Script

tftp ${fdt_addr_r} /ianc/pony/apm-mustang.dtb

fdt addr ${fdt_addr_r} 0x100000

setenv xen_addr_r 0x4000080000
#  kernel_addr_r= 0x4002000000
# ramdisk_addr_r= 0x4004000000

tftp ${xen_addr_r} /ianc/pony/uXen
setenv bootargs "conswitch=x console=dtuart dtuart=/soc/serial@1c020000"
setenv bootargs "${bootargs} no-bootscrub"
setenv bootargs "${bootargs} noreboot"
setenv bootargs "${bootargs} dom0_mem=256M"

fdt set /chosen bootargs "${bootargs}"
fdt set /chosen \#address-cells <2>
fdt set /chosen \#size-cells <1>

tftp ${kernel_addr_r} /ianc/pony/vmlinuz

fdt mknod /chosen module@4002000000
fdt set /chosen/module@4002000000 compatible "multiboot,module" # "multiboot,kernel"
# kernel_addr_r spans two cells...
fdt set /chosen/module@4002000000 reg <0x40 0x02000000 0x${filesize} >
fdt set /chosen/module@4002000000 bootargs "console=hvc0 root=/dev/sda2 rw earlycon=uart8250,mmio32,0x1c020000 maxcpus=8 swiotlb=4096 kernel.sysrq=1"

fdt resize

fdt print /chosen

bootm ${xen_addr_r} - ${fdt_addr_r}



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:09:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:09:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlb2s-00036m-0R; Tue, 04 Nov 2014 10:09:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlb2q-00036h-KF
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:09:00 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	E8/94-25547-BB5A8545; Tue, 04 Nov 2014 10:08:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415095737!11504049!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30579 invoked from network); 4 Nov 2014 10:08:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:08:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187847249"
Message-ID: <1415095735.11486.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>, "Konrad
	Rzeszutek Wilk" <konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 10:08:55 +0000
In-Reply-To: <5450DC800200000200017669@gwsmtp1.uni-regensburg.de>
References: <5450DC800200000200017669@gwsmtp1.uni-regensburg.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xentop: Dynamically expand some columns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-10-29 at 12:24 +0100, Markus Hauschild wrote:
> Allow certain xentop columns to automatically expand as the amount
> of data reported gets larger.  The columns allowed to auto expand are:
> 
> NETTX(k), NETRX(k), VBD_RD, VBD_WR, VBD_RSECT, VBD_WSECT
> 
> If the -f option is used to allow full length VM names, those names will
> also be aligned based on the longest name in the NAME column.
> 
> The default minimum width of all columns remains unchanged.
> 
> Signed-off-by: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>
> Signed-off-by: Charles Arnold <carnold@suse.com>

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

Konrad, I think you were previously intending this to go in for 4.5, is
that still the case?

> 
> diff --git a/tools/xenstat/xentop/Makefile b/tools/xenstat/xentop/Makefile
> index 18bccb6..076e44c 100644
> --- a/tools/xenstat/xentop/Makefile
> +++ b/tools/xenstat/xentop/Makefile
> @@ -19,7 +19,7 @@ all install xentop:
>  else
>  
>  CFLAGS += -DGCC_PRINTF -Werror $(CFLAGS_libxenstat)
> -LDLIBS += $(LDLIBS_libxenstat) $(CURSES_LIBS) $(SOCKET_LIBS)
> +LDLIBS += $(LDLIBS_libxenstat) $(CURSES_LIBS) $(SOCKET_LIBS) -lm
>  CFLAGS += -DHOST_$(XEN_OS)
>  
>  # Include configure output (config.h) to headers search path
> diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c
> index dd11927..3062cb5 100644
> --- a/tools/xenstat/xentop/xentop.c
> +++ b/tools/xenstat/xentop/xentop.c
> @@ -27,6 +27,7 @@
>  
>  #include <ctype.h>
>  #include <errno.h>
> +#include <math.h>
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <stdarg.h>
> @@ -70,6 +71,8 @@
>  #define curses_str_t const char *
>  #endif
>  
> +#define INT_FIELD_WIDTH(n) ((unsigned int)(log10(n) + 1))
> +
>  /*
>   * Function prototypes
>   */
> @@ -127,7 +130,8 @@ static int compare_vbd_rsect(xenstat_domain *domain1, xenstat_domain *domain2);
>  static void print_vbd_rsect(xenstat_domain *domain);
>  static int compare_vbd_wsect(xenstat_domain *domain1, xenstat_domain *domain2);
>  static void print_vbd_wsect(xenstat_domain *domain);
> -
> +static void reset_field_widths(void);
> +static void adjust_field_widths(xenstat_domain *domain);
>  
>  /* Section printing functions */
>  static void do_summary(void);
> @@ -444,7 +448,7 @@ int compare_name(xenstat_domain *domain1, xenstat_domain *domain2)
>  void print_name(xenstat_domain *domain)
>  {
>  	if(show_full_name)
> -		print("%10s", xenstat_domain_name(domain));
> +		print("%*s", fields[FIELD_NAME-1].default_width, xenstat_domain_name(domain));
>  	else
>  		print("%10.10s", xenstat_domain_name(domain));
>  }
> @@ -623,7 +627,7 @@ static int compare_net_tx(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total network tx bytes statistic */
>  static void print_net_tx(xenstat_domain *domain)
>  {
> -	print("%8llu", tot_net_bytes(domain, FALSE)/1024);
> +	print("%*llu", fields[FIELD_NET_TX-1].default_width, tot_net_bytes(domain, FALSE)/1024);
>  }
>  
>  /* Compares number of total network rx bytes of two domains, returning -1,0,1
> @@ -637,7 +641,7 @@ static int compare_net_rx(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total network rx bytes statistic */
>  static void print_net_rx(xenstat_domain *domain)
>  {
> -	print("%8llu", tot_net_bytes(domain, TRUE)/1024);
> +	print("%*llu", fields[FIELD_NET_RX-1].default_width, tot_net_bytes(domain, TRUE)/1024);
>  }
>  
>  /* Gets number of total network bytes statistic, if rx true, then rx bytes
> @@ -705,7 +709,7 @@ static int compare_vbd_rd(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total VBD READ requests statistic */
>  static void print_vbd_rd(xenstat_domain *domain)
>  {
> -	print("%8llu", tot_vbd_reqs(domain, FIELD_VBD_RD));
> +	print("%*llu", fields[FIELD_VBD_RD-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_RD));
>  }
>  
>  /* Compares number of total VBD WRITE requests of two domains,
> @@ -719,7 +723,7 @@ static int compare_vbd_wr(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total VBD WRITE requests statistic */
>  static void print_vbd_wr(xenstat_domain *domain)
>  {
> -	print("%8llu", tot_vbd_reqs(domain, FIELD_VBD_WR));
> +	print("%*llu", fields[FIELD_VBD_WR-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_WR));
>  }
>  
>  /* Compares number of total VBD READ sectors of two domains,
> @@ -733,7 +737,7 @@ static int compare_vbd_rsect(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total VBD READ sectors statistic */
>  static void print_vbd_rsect(xenstat_domain *domain)
>  {
> -	print("%10llu", tot_vbd_reqs(domain, FIELD_VBD_RSECT));
> +	print("%*llu", fields[FIELD_VBD_RSECT-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_RSECT));
>  }
>  
>  /* Compares number of total VBD WRITE sectors of two domains,
> @@ -747,7 +751,7 @@ static int compare_vbd_wsect(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total VBD WRITE sectors statistic */
>  static void print_vbd_wsect(xenstat_domain *domain)
>  {
> -	print("%10llu", tot_vbd_reqs(domain, FIELD_VBD_WSECT));
> +	print("%*llu", fields[FIELD_VBD_WSECT-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_WSECT));
>  }
>  
> 
> @@ -806,6 +810,54 @@ static void print_ssid(xenstat_domain *domain)
>  	print("%4u", xenstat_domain_ssid(domain));
>  }
>  
> +/* Resets default_width for fields with potentially large numbers */
> +void reset_field_widths(void)
> +{
> +	fields[FIELD_NET_TX-1].default_width = 8;
> +	fields[FIELD_NET_RX-1].default_width = 8;
> +	fields[FIELD_VBD_RD-1].default_width = 8;
> +	fields[FIELD_VBD_WR-1].default_width = 8;
> +	fields[FIELD_VBD_RSECT-1].default_width = 10;
> +	fields[FIELD_VBD_WSECT-1].default_width = 10;
> +}
> +
> +/* Adjusts default_width for fields with potentially large numbers */
> +void adjust_field_widths(xenstat_domain *domain)
> +{
> +	unsigned int length;
> +
> +	if (show_full_name) {
> +		length = strlen(xenstat_domain_name(domain));
> +		if (length > fields[FIELD_NAME-1].default_width)
> +			fields[FIELD_NAME-1].default_width = length;
> +	}
> +
> +	length = INT_FIELD_WIDTH((tot_net_bytes(domain, FALSE)/1024) + 1);
> +	if (length > fields[FIELD_NET_TX-1].default_width)
> +		fields[FIELD_NET_TX-1].default_width = length;
> +
> +	length = INT_FIELD_WIDTH((tot_net_bytes(domain, TRUE)/1024) + 1);
> +	if (length > fields[FIELD_NET_RX-1].default_width)
> +		fields[FIELD_NET_RX-1].default_width = length;
> +
> +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_RD)) + 1);
> +	if (length > fields[FIELD_VBD_RD-1].default_width)
> +		fields[FIELD_VBD_RD-1].default_width = length;
> +
> +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_WR)) + 1);
> +	if (length > fields[FIELD_VBD_WR-1].default_width)
> +		fields[FIELD_VBD_WR-1].default_width = length;
> +
> +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_RSECT)) + 1);
> +	if (length > fields[FIELD_VBD_RSECT-1].default_width)
> +		fields[FIELD_VBD_RSECT-1].default_width = length;
> +
> +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_WSECT)) + 1);
> +	if (length > fields[FIELD_VBD_WSECT-1].default_width)
> +		fields[FIELD_VBD_WSECT-1].default_width = length;
> +}
> +
> +
>  /* Section printing functions */
>  /* Prints the top summary, above the domain table */
>  void do_summary(void)
> @@ -1088,6 +1140,12 @@ static void top(void)
>  	if(first_domain_index >= num_domains)
>  		first_domain_index = num_domains-1;
>  
> +	/* Adjust default_width for fields with potentially large numbers */
> +	reset_field_widths();
> +	for (i = first_domain_index; i < num_domains; i++) {
> +		adjust_field_widths(domains[i]);
> +	}
> +
>  	for (i = first_domain_index; i < num_domains; i++) {
>  		if(!batch && current_row() == lines()-1)
>  			break;
> 



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:09:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:09:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlb2s-00036m-0R; Tue, 04 Nov 2014 10:09:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlb2q-00036h-KF
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:09:00 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	E8/94-25547-BB5A8545; Tue, 04 Nov 2014 10:08:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415095737!11504049!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30579 invoked from network); 4 Nov 2014 10:08:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:08:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187847249"
Message-ID: <1415095735.11486.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>, "Konrad
	Rzeszutek Wilk" <konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 10:08:55 +0000
In-Reply-To: <5450DC800200000200017669@gwsmtp1.uni-regensburg.de>
References: <5450DC800200000200017669@gwsmtp1.uni-regensburg.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xentop: Dynamically expand some columns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-10-29 at 12:24 +0100, Markus Hauschild wrote:
> Allow certain xentop columns to automatically expand as the amount
> of data reported gets larger.  The columns allowed to auto expand are:
> 
> NETTX(k), NETRX(k), VBD_RD, VBD_WR, VBD_RSECT, VBD_WSECT
> 
> If the -f option is used to allow full length VM names, those names will
> also be aligned based on the longest name in the NAME column.
> 
> The default minimum width of all columns remains unchanged.
> 
> Signed-off-by: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>
> Signed-off-by: Charles Arnold <carnold@suse.com>

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

Konrad, I think you were previously intending this to go in for 4.5, is
that still the case?

> 
> diff --git a/tools/xenstat/xentop/Makefile b/tools/xenstat/xentop/Makefile
> index 18bccb6..076e44c 100644
> --- a/tools/xenstat/xentop/Makefile
> +++ b/tools/xenstat/xentop/Makefile
> @@ -19,7 +19,7 @@ all install xentop:
>  else
>  
>  CFLAGS += -DGCC_PRINTF -Werror $(CFLAGS_libxenstat)
> -LDLIBS += $(LDLIBS_libxenstat) $(CURSES_LIBS) $(SOCKET_LIBS)
> +LDLIBS += $(LDLIBS_libxenstat) $(CURSES_LIBS) $(SOCKET_LIBS) -lm
>  CFLAGS += -DHOST_$(XEN_OS)
>  
>  # Include configure output (config.h) to headers search path
> diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c
> index dd11927..3062cb5 100644
> --- a/tools/xenstat/xentop/xentop.c
> +++ b/tools/xenstat/xentop/xentop.c
> @@ -27,6 +27,7 @@
>  
>  #include <ctype.h>
>  #include <errno.h>
> +#include <math.h>
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <stdarg.h>
> @@ -70,6 +71,8 @@
>  #define curses_str_t const char *
>  #endif
>  
> +#define INT_FIELD_WIDTH(n) ((unsigned int)(log10(n) + 1))
> +
>  /*
>   * Function prototypes
>   */
> @@ -127,7 +130,8 @@ static int compare_vbd_rsect(xenstat_domain *domain1, xenstat_domain *domain2);
>  static void print_vbd_rsect(xenstat_domain *domain);
>  static int compare_vbd_wsect(xenstat_domain *domain1, xenstat_domain *domain2);
>  static void print_vbd_wsect(xenstat_domain *domain);
> -
> +static void reset_field_widths(void);
> +static void adjust_field_widths(xenstat_domain *domain);
>  
>  /* Section printing functions */
>  static void do_summary(void);
> @@ -444,7 +448,7 @@ int compare_name(xenstat_domain *domain1, xenstat_domain *domain2)
>  void print_name(xenstat_domain *domain)
>  {
>  	if(show_full_name)
> -		print("%10s", xenstat_domain_name(domain));
> +		print("%*s", fields[FIELD_NAME-1].default_width, xenstat_domain_name(domain));
>  	else
>  		print("%10.10s", xenstat_domain_name(domain));
>  }
> @@ -623,7 +627,7 @@ static int compare_net_tx(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total network tx bytes statistic */
>  static void print_net_tx(xenstat_domain *domain)
>  {
> -	print("%8llu", tot_net_bytes(domain, FALSE)/1024);
> +	print("%*llu", fields[FIELD_NET_TX-1].default_width, tot_net_bytes(domain, FALSE)/1024);
>  }
>  
>  /* Compares number of total network rx bytes of two domains, returning -1,0,1
> @@ -637,7 +641,7 @@ static int compare_net_rx(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total network rx bytes statistic */
>  static void print_net_rx(xenstat_domain *domain)
>  {
> -	print("%8llu", tot_net_bytes(domain, TRUE)/1024);
> +	print("%*llu", fields[FIELD_NET_RX-1].default_width, tot_net_bytes(domain, TRUE)/1024);
>  }
>  
>  /* Gets number of total network bytes statistic, if rx true, then rx bytes
> @@ -705,7 +709,7 @@ static int compare_vbd_rd(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total VBD READ requests statistic */
>  static void print_vbd_rd(xenstat_domain *domain)
>  {
> -	print("%8llu", tot_vbd_reqs(domain, FIELD_VBD_RD));
> +	print("%*llu", fields[FIELD_VBD_RD-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_RD));
>  }
>  
>  /* Compares number of total VBD WRITE requests of two domains,
> @@ -719,7 +723,7 @@ static int compare_vbd_wr(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total VBD WRITE requests statistic */
>  static void print_vbd_wr(xenstat_domain *domain)
>  {
> -	print("%8llu", tot_vbd_reqs(domain, FIELD_VBD_WR));
> +	print("%*llu", fields[FIELD_VBD_WR-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_WR));
>  }
>  
>  /* Compares number of total VBD READ sectors of two domains,
> @@ -733,7 +737,7 @@ static int compare_vbd_rsect(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total VBD READ sectors statistic */
>  static void print_vbd_rsect(xenstat_domain *domain)
>  {
> -	print("%10llu", tot_vbd_reqs(domain, FIELD_VBD_RSECT));
> +	print("%*llu", fields[FIELD_VBD_RSECT-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_RSECT));
>  }
>  
>  /* Compares number of total VBD WRITE sectors of two domains,
> @@ -747,7 +751,7 @@ static int compare_vbd_wsect(xenstat_domain *domain1, xenstat_domain *domain2)
>  /* Prints number of total VBD WRITE sectors statistic */
>  static void print_vbd_wsect(xenstat_domain *domain)
>  {
> -	print("%10llu", tot_vbd_reqs(domain, FIELD_VBD_WSECT));
> +	print("%*llu", fields[FIELD_VBD_WSECT-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_WSECT));
>  }
>  
> 
> @@ -806,6 +810,54 @@ static void print_ssid(xenstat_domain *domain)
>  	print("%4u", xenstat_domain_ssid(domain));
>  }
>  
> +/* Resets default_width for fields with potentially large numbers */
> +void reset_field_widths(void)
> +{
> +	fields[FIELD_NET_TX-1].default_width = 8;
> +	fields[FIELD_NET_RX-1].default_width = 8;
> +	fields[FIELD_VBD_RD-1].default_width = 8;
> +	fields[FIELD_VBD_WR-1].default_width = 8;
> +	fields[FIELD_VBD_RSECT-1].default_width = 10;
> +	fields[FIELD_VBD_WSECT-1].default_width = 10;
> +}
> +
> +/* Adjusts default_width for fields with potentially large numbers */
> +void adjust_field_widths(xenstat_domain *domain)
> +{
> +	unsigned int length;
> +
> +	if (show_full_name) {
> +		length = strlen(xenstat_domain_name(domain));
> +		if (length > fields[FIELD_NAME-1].default_width)
> +			fields[FIELD_NAME-1].default_width = length;
> +	}
> +
> +	length = INT_FIELD_WIDTH((tot_net_bytes(domain, FALSE)/1024) + 1);
> +	if (length > fields[FIELD_NET_TX-1].default_width)
> +		fields[FIELD_NET_TX-1].default_width = length;
> +
> +	length = INT_FIELD_WIDTH((tot_net_bytes(domain, TRUE)/1024) + 1);
> +	if (length > fields[FIELD_NET_RX-1].default_width)
> +		fields[FIELD_NET_RX-1].default_width = length;
> +
> +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_RD)) + 1);
> +	if (length > fields[FIELD_VBD_RD-1].default_width)
> +		fields[FIELD_VBD_RD-1].default_width = length;
> +
> +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_WR)) + 1);
> +	if (length > fields[FIELD_VBD_WR-1].default_width)
> +		fields[FIELD_VBD_WR-1].default_width = length;
> +
> +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_RSECT)) + 1);
> +	if (length > fields[FIELD_VBD_RSECT-1].default_width)
> +		fields[FIELD_VBD_RSECT-1].default_width = length;
> +
> +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_WSECT)) + 1);
> +	if (length > fields[FIELD_VBD_WSECT-1].default_width)
> +		fields[FIELD_VBD_WSECT-1].default_width = length;
> +}
> +
> +
>  /* Section printing functions */
>  /* Prints the top summary, above the domain table */
>  void do_summary(void)
> @@ -1088,6 +1140,12 @@ static void top(void)
>  	if(first_domain_index >= num_domains)
>  		first_domain_index = num_domains-1;
>  
> +	/* Adjust default_width for fields with potentially large numbers */
> +	reset_field_widths();
> +	for (i = first_domain_index; i < num_domains; i++) {
> +		adjust_field_widths(domains[i]);
> +	}
> +
>  	for (i = first_domain_index; i < num_domains; i++) {
>  		if(!batch && current_row() == lines()-1)
>  			break;
> 



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:11:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlb5Y-0003F7-K9; Tue, 04 Nov 2014 10:11:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlb5X-0003EI-SY
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:11:47 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E5/17-09284-366A8545; Tue, 04 Nov 2014 10:11:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415095905!11498505!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19214 invoked from network); 4 Nov 2014 10:11:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:11:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189227833"
Message-ID: <1415095903.11486.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 4 Nov 2014 10:11:43 +0000
In-Reply-To: <20141103144755.GA28870@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de>
	<1415024987.24785.13.camel@citrix.com>
	<20141103144755.GA28870@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, 2014-11-03 at 15:47 +0100, Olaf Hering wrote:
> On Mon, Nov 03, Ian Campbell wrote:
> 
> > On Mon, 2014-11-03 at 15:24 +0100, Olaf Hering wrote:
> > > On Mon, Nov 03, George Dunlap wrote:
> > > 
> > > > How difficult would it be to have this be something sensible like,
> > > > "changesets since last tag"?
> > > 
> > > Very difficult, because one does changes without commit, runs 'make
> > > rpmball' and expects that rpm -Fvh *.rpm continues to work.
> > 
> > Isn't that what "rpm -Uvh" is for?
> 
> No, thats for fresh install.

Isn't that -ivh?

>  -F installs whats already there.

Does rpm --force -Fvh not work?

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:11:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlb5Y-0003F7-K9; Tue, 04 Nov 2014 10:11:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlb5X-0003EI-SY
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:11:47 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E5/17-09284-366A8545; Tue, 04 Nov 2014 10:11:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415095905!11498505!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19214 invoked from network); 4 Nov 2014 10:11:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:11:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189227833"
Message-ID: <1415095903.11486.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 4 Nov 2014 10:11:43 +0000
In-Reply-To: <20141103144755.GA28870@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de>
	<1415024987.24785.13.camel@citrix.com>
	<20141103144755.GA28870@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, 2014-11-03 at 15:47 +0100, Olaf Hering wrote:
> On Mon, Nov 03, Ian Campbell wrote:
> 
> > On Mon, 2014-11-03 at 15:24 +0100, Olaf Hering wrote:
> > > On Mon, Nov 03, George Dunlap wrote:
> > > 
> > > > How difficult would it be to have this be something sensible like,
> > > > "changesets since last tag"?
> > > 
> > > Very difficult, because one does changes without commit, runs 'make
> > > rpmball' and expects that rpm -Fvh *.rpm continues to work.
> > 
> > Isn't that what "rpm -Uvh" is for?
> 
> No, thats for fresh install.

Isn't that -ivh?

>  -F installs whats already there.

Does rpm --force -Fvh not work?

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:15:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlb9P-0003Vj-C7; Tue, 04 Nov 2014 10:15:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xlb9O-0003Vd-12
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:15:46 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	21/35-17694-157A8545; Tue, 04 Nov 2014 10:15:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415096144!11530315!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24460 invoked from network); 4 Nov 2014 10:15:44 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 10:15:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 10:15:44 +0000
Message-Id: <5458B55C0200007800044B33@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 10:15:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>,
	"=?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?=" <pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
In-Reply-To: <20141104082012.GY12451@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 09:20, <pasik@iki.fi> wrote:
> On Mon, Nov 03, 2014 at 01:46:03PM -0800, Steve Freitas wrote:
>> (I was monitoring syslog over a network connection since nothing of
>> value can be saved to disk under the circumstances.)
>> 
> 
> It'd be very helpful if you could set up a serial console to log all the Xen 
> and dom0 Linux kernel messages,
> so we could see where it actually crashes..

In fact this would not just be nice, but is strictly needed, and (as
with any pass-through related problems) additionally requires
running with "iommu=debug" alongside the usual need of setting
the log levels to the maximum.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:15:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlb9P-0003Vj-C7; Tue, 04 Nov 2014 10:15:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xlb9O-0003Vd-12
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:15:46 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	21/35-17694-157A8545; Tue, 04 Nov 2014 10:15:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415096144!11530315!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24460 invoked from network); 4 Nov 2014 10:15:44 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 10:15:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 10:15:44 +0000
Message-Id: <5458B55C0200007800044B33@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 10:15:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>,
	"=?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?=" <pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
In-Reply-To: <20141104082012.GY12451@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 09:20, <pasik@iki.fi> wrote:
> On Mon, Nov 03, 2014 at 01:46:03PM -0800, Steve Freitas wrote:
>> (I was monitoring syslog over a network connection since nothing of
>> value can be saved to disk under the circumstances.)
>> 
> 
> It'd be very helpful if you could set up a serial console to log all the Xen 
> and dom0 Linux kernel messages,
> so we could see where it actually crashes..

In fact this would not just be nice, but is strictly needed, and (as
with any pass-through related problems) additionally requires
running with "iommu=debug" alongside the usual need of setting
the log levels to the maximum.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:15:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:15:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlb9Y-0003Wj-OL; Tue, 04 Nov 2014 10:15:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlb9W-0003WF-VX
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:15:55 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	FA/53-17958-A57A8545; Tue, 04 Nov 2014 10:15:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415096151!11365440!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5080 invoked from network); 4 Nov 2014 10:15:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:15:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189229402"
Message-ID: <1415096148.11486.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Emil Condrea <emilcondrea@gmail.com>
Date: Tue, 4 Nov 2014 10:15:48 +0000
In-Reply-To: <CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>
	<545235EE.4040000@citrix.com>
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, dgdegra@tycho.nsa.gov,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
> Of course we can use max, but I thought that it might be useful to
> have a prink to inform the user that the timeout was adjusted.
> In init_tpm_tis the default timeouts are set using:
> /* Set default timeouts */ tpm->timeout_a =
> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
> MILLISECS(TIS_SHORT_TIMEOUT);
> 
> 
> 
> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
> So if we want to integrate kernel changes I think we should use
> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
> Also in kernel the default timeouts are initialized using
> msecs_to_jiffies which is different from MILLISECS
> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
> Is there a certain reason for not using msecs_to_jiffies ?

jiffies are a Linux specific concept which mini-os doesn't share.

Daniel, do you have any opinion on this patch?

It seems like the Linux fix is made only for the specifically broken
platform. That seems to make sense to me since presumably other systems
report short timeouts which they can indeed cope with. It's only Atmel
which brokenly reports something it cannot handle.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:15:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:15:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlb9Y-0003Wj-OL; Tue, 04 Nov 2014 10:15:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlb9W-0003WF-VX
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:15:55 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	FA/53-17958-A57A8545; Tue, 04 Nov 2014 10:15:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415096151!11365440!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5080 invoked from network); 4 Nov 2014 10:15:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:15:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189229402"
Message-ID: <1415096148.11486.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Emil Condrea <emilcondrea@gmail.com>
Date: Tue, 4 Nov 2014 10:15:48 +0000
In-Reply-To: <CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>
	<545235EE.4040000@citrix.com>
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, dgdegra@tycho.nsa.gov,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
> Of course we can use max, but I thought that it might be useful to
> have a prink to inform the user that the timeout was adjusted.
> In init_tpm_tis the default timeouts are set using:
> /* Set default timeouts */ tpm->timeout_a =
> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
> MILLISECS(TIS_SHORT_TIMEOUT);
> 
> 
> 
> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
> So if we want to integrate kernel changes I think we should use
> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
> Also in kernel the default timeouts are initialized using
> msecs_to_jiffies which is different from MILLISECS
> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
> Is there a certain reason for not using msecs_to_jiffies ?

jiffies are a Linux specific concept which mini-os doesn't share.

Daniel, do you have any opinion on this patch?

It seems like the Linux fix is made only for the specifically broken
platform. That seems to make sense to me since presumably other systems
report short timeouts which they can indeed cope with. It's only Atmel
which brokenly reports something it cannot handle.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:16:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:16:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbAS-0003eK-6X; Tue, 04 Nov 2014 10:16:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XlbAR-0003e2-1C
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:16:51 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	7E/3D-11608-297A8545; Tue, 04 Nov 2014 10:16:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415096209!9043824!1
X-Originating-IP: [81.169.146.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21891 invoked from network); 4 Nov 2014 10:16:49 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 10:16:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415096209; l=446;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=wuRpQgl3m3K5ufBniDPqmw7e8JU=;
	b=FyWKSTXyM8y7EaUovVBx0aYNB0cmMtJRgaU4gKKbsm6+9RzChhOJeGtjd0mtld8lKRO
	hZyu+qjRmeWhQ/TDD46zw9qjooHtdDIJvRpgKQZTvCgVNvFpqCYs9g9vRFbR5T1rlU1Ci
	avSe7vkggdKUfpmBUoCcbFPsT+RzbrTqDjE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id g062f4qA4AGnXb4
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 4 Nov 2014 11:16:49 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id D0B1950172; Tue,  4 Nov 2014 11:16:48 +0100 (CET)
Date: Tue, 4 Nov 2014 11:16:48 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141104101648.GA2296@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de>
	<1415024987.24785.13.camel@citrix.com>
	<20141103144755.GA28870@aepfle.de>
	<1415095903.11486.9.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415095903.11486.9.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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, Nov 04, Ian Campbell wrote:

> On Mon, 2014-11-03 at 15:47 +0100, Olaf Hering wrote:

> Isn't that -ivh?

-i installs multiple packages, if they have no overlapping files. -U
replaces every installed version with the new one.

> >  -F installs whats already there.
> Does rpm --force -Fvh not work?

-F behaves different. I think it would not take --force into account. At
least --oldpackage does not work with -F.


Olaf

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:16:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:16:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbAS-0003eK-6X; Tue, 04 Nov 2014 10:16:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XlbAR-0003e2-1C
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:16:51 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	7E/3D-11608-297A8545; Tue, 04 Nov 2014 10:16:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415096209!9043824!1
X-Originating-IP: [81.169.146.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21891 invoked from network); 4 Nov 2014 10:16:49 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 10:16:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415096209; l=446;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=wuRpQgl3m3K5ufBniDPqmw7e8JU=;
	b=FyWKSTXyM8y7EaUovVBx0aYNB0cmMtJRgaU4gKKbsm6+9RzChhOJeGtjd0mtld8lKRO
	hZyu+qjRmeWhQ/TDD46zw9qjooHtdDIJvRpgKQZTvCgVNvFpqCYs9g9vRFbR5T1rlU1Ci
	avSe7vkggdKUfpmBUoCcbFPsT+RzbrTqDjE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id g062f4qA4AGnXb4
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 4 Nov 2014 11:16:49 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id D0B1950172; Tue,  4 Nov 2014 11:16:48 +0100 (CET)
Date: Tue, 4 Nov 2014 11:16:48 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141104101648.GA2296@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de>
	<1415024987.24785.13.camel@citrix.com>
	<20141103144755.GA28870@aepfle.de>
	<1415095903.11486.9.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415095903.11486.9.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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, Nov 04, Ian Campbell wrote:

> On Mon, 2014-11-03 at 15:47 +0100, Olaf Hering wrote:

> Isn't that -ivh?

-i installs multiple packages, if they have no overlapping files. -U
replaces every installed version with the new one.

> >  -F installs whats already there.
> Does rpm --force -Fvh not work?

-F behaves different. I think it would not take --force into account. At
least --oldpackage does not work with -F.


Olaf

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:17:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10: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 1XlbB7-0003kV-Ku; Tue, 04 Nov 2014 10:17:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlbB6-0003kJ-KI
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:17:32 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	60/7F-09936-CB7A8545; Tue, 04 Nov 2014 10:17:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415096244!12647902!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11017 invoked from network); 4 Nov 2014 10:17:31 -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;
	4 Nov 2014 10:17:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189229650"
Message-ID: <1415096249.11486.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 10:17:29 +0000
In-Reply-To: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: julien.grall@linaro.org, tim@xen.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:

I think we should apply this workaround for 4.5 and do things properly
for 4.6. Any thoughts?

> Vexpress is currently failing to boot for me with:
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x118/0x1a4()
> CPU: 0 PID: 1 Comm: swapper Tainted: G        W     3.16.0-arm-native+ #276
> [<c0011e9c>] (unwind_backtrace) from [<c0010758>] (show_stack+0x10/0x14)
> [<c0010758>] (show_stack) from [<c001a3ec>] (warn_slowpath_common+0x5c/0x7c)
> [<c001a3ec>] (warn_slowpath_common) from [<c001a4c8>] (warn_slowpath_null+0x18/0x20)
> [<c001a4c8>] (warn_slowpath_null) from [<c001488c>] (__arm_ioremap_pfn_caller+0x118/0x1a4)
> [<c001488c>] (__arm_ioremap_pfn_caller) from [<c00149a0>] (__arm_ioremap+0x14/0x20)
> [<c00149a0>] (__arm_ioremap) from [<c01d103c>] (gnttab_setup_auto_xlat_frames+0x30/0xdc)
> [<c01d103c>] (gnttab_setup_auto_xlat_frames) from [<c0495324>] (xen_guest_init+0x19c/0x2d4)
> [<c0495324>] (xen_guest_init) from [<c0492c6c>] (do_one_initcall+0xfc/0x1a4)
> [<c0492c6c>] (do_one_initcall) from [<c0492d6c>] (kernel_init_freeable+0x58/0x1b4)
> [<c0492d6c>] (kernel_init_freeable) from [<c039611c>] (kernel_init+0x8/0xe4)
> [<c039611c>] (kernel_init) from [<c000de58>] (ret_from_fork+0x14/0x3c)
> ---[ end trace 3406ff24bd97382f ]---
> xen:grant_table: Failed to ioremap gnttab share frames (addr=0x00000000b0000000)!
> 
> which is:
>         /*
>          * Don't allow RAM to be mapped - this causes problems with ARMv6+
>          */
>         if (WARN_ON(pfn_valid(pfn)))
>                 return NULL;
> 
> This makes sense since the gnttab defaults to 0xb000000 and my dom0
> is being allocated a 1:1 mapping at 0xa0000000-0xc0000000.
> 
> I suspect this broke around the time we stopped forcing dom0 memory to be
> allocated as low as possible which happened to prevent the default dom0_gnttab
> region overlapping RAM.
> 
> This patch specifies an explicit dom0_gnttab base which is explicitly unused
> according to the FVP model docs (although it correpsonds to CS5 this isn't
> wired up to anything).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> This just fixes vexpress, I wonder if a followup patch should either remove the
> default dom0_gnttab (forcing all platforms to specify one explicitly) or make
> the default something less arbitrary than 0xb0000000, e.g. 0x0-0x20000 or
> 0xfffe0000-0x100000000 (very start or very end of RAM). Perhaps with a command
> line option to override for new platform hacking.
> 
> Or maybe we should search for an unused hole in the dom0 RAM space?
> ---
>  xen/arch/arm/platforms/vexpress.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
> index 8e6a4ea..ce66935 100644
> --- a/xen/arch/arm/platforms/vexpress.c
> +++ b/xen/arch/arm/platforms/vexpress.c
> @@ -176,6 +176,8 @@ PLATFORM_START(vexpress, "VERSATILE EXPRESS")
>  #endif
>      .reset = vexpress_reset,
>      .blacklist_dev = vexpress_blacklist_dev,
> +    .dom0_gnttab_start = 0x10000000,
> +    .dom0_gnttab_size = 0x20000,
>  PLATFORM_END
>  
>  /*



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:17:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10: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 1XlbB7-0003kV-Ku; Tue, 04 Nov 2014 10:17:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlbB6-0003kJ-KI
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:17:32 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	60/7F-09936-CB7A8545; Tue, 04 Nov 2014 10:17:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415096244!12647902!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11017 invoked from network); 4 Nov 2014 10:17:31 -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;
	4 Nov 2014 10:17:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189229650"
Message-ID: <1415096249.11486.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 10:17:29 +0000
In-Reply-To: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: julien.grall@linaro.org, tim@xen.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:

I think we should apply this workaround for 4.5 and do things properly
for 4.6. Any thoughts?

> Vexpress is currently failing to boot for me with:
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x118/0x1a4()
> CPU: 0 PID: 1 Comm: swapper Tainted: G        W     3.16.0-arm-native+ #276
> [<c0011e9c>] (unwind_backtrace) from [<c0010758>] (show_stack+0x10/0x14)
> [<c0010758>] (show_stack) from [<c001a3ec>] (warn_slowpath_common+0x5c/0x7c)
> [<c001a3ec>] (warn_slowpath_common) from [<c001a4c8>] (warn_slowpath_null+0x18/0x20)
> [<c001a4c8>] (warn_slowpath_null) from [<c001488c>] (__arm_ioremap_pfn_caller+0x118/0x1a4)
> [<c001488c>] (__arm_ioremap_pfn_caller) from [<c00149a0>] (__arm_ioremap+0x14/0x20)
> [<c00149a0>] (__arm_ioremap) from [<c01d103c>] (gnttab_setup_auto_xlat_frames+0x30/0xdc)
> [<c01d103c>] (gnttab_setup_auto_xlat_frames) from [<c0495324>] (xen_guest_init+0x19c/0x2d4)
> [<c0495324>] (xen_guest_init) from [<c0492c6c>] (do_one_initcall+0xfc/0x1a4)
> [<c0492c6c>] (do_one_initcall) from [<c0492d6c>] (kernel_init_freeable+0x58/0x1b4)
> [<c0492d6c>] (kernel_init_freeable) from [<c039611c>] (kernel_init+0x8/0xe4)
> [<c039611c>] (kernel_init) from [<c000de58>] (ret_from_fork+0x14/0x3c)
> ---[ end trace 3406ff24bd97382f ]---
> xen:grant_table: Failed to ioremap gnttab share frames (addr=0x00000000b0000000)!
> 
> which is:
>         /*
>          * Don't allow RAM to be mapped - this causes problems with ARMv6+
>          */
>         if (WARN_ON(pfn_valid(pfn)))
>                 return NULL;
> 
> This makes sense since the gnttab defaults to 0xb000000 and my dom0
> is being allocated a 1:1 mapping at 0xa0000000-0xc0000000.
> 
> I suspect this broke around the time we stopped forcing dom0 memory to be
> allocated as low as possible which happened to prevent the default dom0_gnttab
> region overlapping RAM.
> 
> This patch specifies an explicit dom0_gnttab base which is explicitly unused
> according to the FVP model docs (although it correpsonds to CS5 this isn't
> wired up to anything).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> This just fixes vexpress, I wonder if a followup patch should either remove the
> default dom0_gnttab (forcing all platforms to specify one explicitly) or make
> the default something less arbitrary than 0xb0000000, e.g. 0x0-0x20000 or
> 0xfffe0000-0x100000000 (very start or very end of RAM). Perhaps with a command
> line option to override for new platform hacking.
> 
> Or maybe we should search for an unused hole in the dom0 RAM space?
> ---
>  xen/arch/arm/platforms/vexpress.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
> index 8e6a4ea..ce66935 100644
> --- a/xen/arch/arm/platforms/vexpress.c
> +++ b/xen/arch/arm/platforms/vexpress.c
> @@ -176,6 +176,8 @@ PLATFORM_START(vexpress, "VERSATILE EXPRESS")
>  #endif
>      .reset = vexpress_reset,
>      .blacklist_dev = vexpress_blacklist_dev,
> +    .dom0_gnttab_start = 0x10000000,
> +    .dom0_gnttab_size = 0x20000,
>  PLATFORM_END
>  
>  /*



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:21:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbEe-00042U-Ap; Tue, 04 Nov 2014 10:21:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlbEc-00042P-AI
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:21:10 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	56/B1-02712-598A8545; Tue, 04 Nov 2014 10:21:09 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415096467!12421188!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12506 invoked from network); 4 Nov 2014 10:21:08 -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;
	4 Nov 2014 10:21:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187850058"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 05:20:30 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlbDy-0002A8-68;
	Tue, 04 Nov 2014 10:20:30 +0000
Date: Tue, 4 Nov 2014 10:20:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415096249.11486.12.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411041019300.22875@kaball.uk.xensource.com>
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
	<1415096249.11486.12.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: julien.grall@linaro.org, tim@xen.org, stefano.stabellini@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Ian Campbell wrote:
> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
> 
> I think we should apply this workaround for 4.5 and do things properly
> for 4.6. Any thoughts?
 
I agree with you


> > Vexpress is currently failing to boot for me with:
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x118/0x1a4()
> > CPU: 0 PID: 1 Comm: swapper Tainted: G        W     3.16.0-arm-native+ #276
> > [<c0011e9c>] (unwind_backtrace) from [<c0010758>] (show_stack+0x10/0x14)
> > [<c0010758>] (show_stack) from [<c001a3ec>] (warn_slowpath_common+0x5c/0x7c)
> > [<c001a3ec>] (warn_slowpath_common) from [<c001a4c8>] (warn_slowpath_null+0x18/0x20)
> > [<c001a4c8>] (warn_slowpath_null) from [<c001488c>] (__arm_ioremap_pfn_caller+0x118/0x1a4)
> > [<c001488c>] (__arm_ioremap_pfn_caller) from [<c00149a0>] (__arm_ioremap+0x14/0x20)
> > [<c00149a0>] (__arm_ioremap) from [<c01d103c>] (gnttab_setup_auto_xlat_frames+0x30/0xdc)
> > [<c01d103c>] (gnttab_setup_auto_xlat_frames) from [<c0495324>] (xen_guest_init+0x19c/0x2d4)
> > [<c0495324>] (xen_guest_init) from [<c0492c6c>] (do_one_initcall+0xfc/0x1a4)
> > [<c0492c6c>] (do_one_initcall) from [<c0492d6c>] (kernel_init_freeable+0x58/0x1b4)
> > [<c0492d6c>] (kernel_init_freeable) from [<c039611c>] (kernel_init+0x8/0xe4)
> > [<c039611c>] (kernel_init) from [<c000de58>] (ret_from_fork+0x14/0x3c)
> > ---[ end trace 3406ff24bd97382f ]---
> > xen:grant_table: Failed to ioremap gnttab share frames (addr=0x00000000b0000000)!
> > 
> > which is:
> >         /*
> >          * Don't allow RAM to be mapped - this causes problems with ARMv6+
> >          */
> >         if (WARN_ON(pfn_valid(pfn)))
> >                 return NULL;
> > 
> > This makes sense since the gnttab defaults to 0xb000000 and my dom0
> > is being allocated a 1:1 mapping at 0xa0000000-0xc0000000.
> > 
> > I suspect this broke around the time we stopped forcing dom0 memory to be
> > allocated as low as possible which happened to prevent the default dom0_gnttab
> > region overlapping RAM.
> > 
> > This patch specifies an explicit dom0_gnttab base which is explicitly unused
> > according to the FVP model docs (although it correpsonds to CS5 this isn't
> > wired up to anything).
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> > This just fixes vexpress, I wonder if a followup patch should either remove the
> > default dom0_gnttab (forcing all platforms to specify one explicitly) or make
> > the default something less arbitrary than 0xb0000000, e.g. 0x0-0x20000 or
> > 0xfffe0000-0x100000000 (very start or very end of RAM). Perhaps with a command
> > line option to override for new platform hacking.
> > 
> > Or maybe we should search for an unused hole in the dom0 RAM space?
> > ---
> >  xen/arch/arm/platforms/vexpress.c |    2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
> > index 8e6a4ea..ce66935 100644
> > --- a/xen/arch/arm/platforms/vexpress.c
> > +++ b/xen/arch/arm/platforms/vexpress.c
> > @@ -176,6 +176,8 @@ PLATFORM_START(vexpress, "VERSATILE EXPRESS")
> >  #endif
> >      .reset = vexpress_reset,
> >      .blacklist_dev = vexpress_blacklist_dev,
> > +    .dom0_gnttab_start = 0x10000000,
> > +    .dom0_gnttab_size = 0x20000,
> >  PLATFORM_END
> >  
> >  /*
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:21:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbEe-00042U-Ap; Tue, 04 Nov 2014 10:21:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlbEc-00042P-AI
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:21:10 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	56/B1-02712-598A8545; Tue, 04 Nov 2014 10:21:09 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415096467!12421188!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12506 invoked from network); 4 Nov 2014 10:21:08 -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;
	4 Nov 2014 10:21:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187850058"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 05:20:30 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlbDy-0002A8-68;
	Tue, 04 Nov 2014 10:20:30 +0000
Date: Tue, 4 Nov 2014 10:20:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415096249.11486.12.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411041019300.22875@kaball.uk.xensource.com>
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
	<1415096249.11486.12.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: julien.grall@linaro.org, tim@xen.org, stefano.stabellini@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Ian Campbell wrote:
> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
> 
> I think we should apply this workaround for 4.5 and do things properly
> for 4.6. Any thoughts?
 
I agree with you


> > Vexpress is currently failing to boot for me with:
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x118/0x1a4()
> > CPU: 0 PID: 1 Comm: swapper Tainted: G        W     3.16.0-arm-native+ #276
> > [<c0011e9c>] (unwind_backtrace) from [<c0010758>] (show_stack+0x10/0x14)
> > [<c0010758>] (show_stack) from [<c001a3ec>] (warn_slowpath_common+0x5c/0x7c)
> > [<c001a3ec>] (warn_slowpath_common) from [<c001a4c8>] (warn_slowpath_null+0x18/0x20)
> > [<c001a4c8>] (warn_slowpath_null) from [<c001488c>] (__arm_ioremap_pfn_caller+0x118/0x1a4)
> > [<c001488c>] (__arm_ioremap_pfn_caller) from [<c00149a0>] (__arm_ioremap+0x14/0x20)
> > [<c00149a0>] (__arm_ioremap) from [<c01d103c>] (gnttab_setup_auto_xlat_frames+0x30/0xdc)
> > [<c01d103c>] (gnttab_setup_auto_xlat_frames) from [<c0495324>] (xen_guest_init+0x19c/0x2d4)
> > [<c0495324>] (xen_guest_init) from [<c0492c6c>] (do_one_initcall+0xfc/0x1a4)
> > [<c0492c6c>] (do_one_initcall) from [<c0492d6c>] (kernel_init_freeable+0x58/0x1b4)
> > [<c0492d6c>] (kernel_init_freeable) from [<c039611c>] (kernel_init+0x8/0xe4)
> > [<c039611c>] (kernel_init) from [<c000de58>] (ret_from_fork+0x14/0x3c)
> > ---[ end trace 3406ff24bd97382f ]---
> > xen:grant_table: Failed to ioremap gnttab share frames (addr=0x00000000b0000000)!
> > 
> > which is:
> >         /*
> >          * Don't allow RAM to be mapped - this causes problems with ARMv6+
> >          */
> >         if (WARN_ON(pfn_valid(pfn)))
> >                 return NULL;
> > 
> > This makes sense since the gnttab defaults to 0xb000000 and my dom0
> > is being allocated a 1:1 mapping at 0xa0000000-0xc0000000.
> > 
> > I suspect this broke around the time we stopped forcing dom0 memory to be
> > allocated as low as possible which happened to prevent the default dom0_gnttab
> > region overlapping RAM.
> > 
> > This patch specifies an explicit dom0_gnttab base which is explicitly unused
> > according to the FVP model docs (although it correpsonds to CS5 this isn't
> > wired up to anything).
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> > This just fixes vexpress, I wonder if a followup patch should either remove the
> > default dom0_gnttab (forcing all platforms to specify one explicitly) or make
> > the default something less arbitrary than 0xb0000000, e.g. 0x0-0x20000 or
> > 0xfffe0000-0x100000000 (very start or very end of RAM). Perhaps with a command
> > line option to override for new platform hacking.
> > 
> > Or maybe we should search for an unused hole in the dom0 RAM space?
> > ---
> >  xen/arch/arm/platforms/vexpress.c |    2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
> > index 8e6a4ea..ce66935 100644
> > --- a/xen/arch/arm/platforms/vexpress.c
> > +++ b/xen/arch/arm/platforms/vexpress.c
> > @@ -176,6 +176,8 @@ PLATFORM_START(vexpress, "VERSATILE EXPRESS")
> >  #endif
> >      .reset = vexpress_reset,
> >      .blacklist_dev = vexpress_blacklist_dev,
> > +    .dom0_gnttab_start = 0x10000000,
> > +    .dom0_gnttab_size = 0x20000,
> >  PLATFORM_END
> >  
> >  /*
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:24:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:24:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbHr-0004Kc-4R; Tue, 04 Nov 2014 10:24:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlbHq-0004KW-DD
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:24:30 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	B9/1D-17735-D59A8545; Tue, 04 Nov 2014 10:24:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415096667!7766925!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15306 invoked from network); 4 Nov 2014 10:24:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:24:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189230630"
Message-ID: <1415096635.11486.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 10:23:55 +0000
In-Reply-To: <54513A08.3000908@linaro.org>
References: <1414144694.15687.31.camel@citrix.com>
	<1414144717-32328-1-git-send-email-ian.campbell@citrix.com>
	<54513A08.3000908@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] xen: arm: propagate gic's
 #address-cells property 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 Wed, 2014-10-29 at 19:03 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 24/10/2014 10:58, Ian Campbell wrote:
> > The interrupt-map property requires that the interrupt-parent node
> > must have both #address-cells and #interrupt-cells properties (see
> > ePAPR 2.4.3.1). Therefore propagate the property if it is present.
> >
> > We must propagate (rather than invent our own value) since this value
> > is used to size fields within other properties within the tree.
> >
> > ePAPR strictly speaking requires that the interrupt-parent node
> > always has these properties. However reality has diverged from this
> > and implementations will recursively search parents for #*-cells
> > properties. Hence we only copy if it is present.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Reviewed-by: Julien Grall <julien.grall@linaro.org>
> 
> Without this patch I can't boot Xen on the Foundation model with GIC-v3. 
> Is it possible to push this patch for Xen 4.5 rc1?

Konrad, I think this is needed for 4.5 since without it dom0 can fail to
parse certain other constructs within the DT (in bits which we don't
generate and can't easily/don't want to rewrite as we pass them
through).

The risk is that some bit of DT which we do generate relies on this
value being absent (as it was before this patch). I don't believe we
generate any such nodes. The consumers are typically nodes representing
devices which we pass through rather than messing with them.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:24:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:24:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbHr-0004Kc-4R; Tue, 04 Nov 2014 10:24:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlbHq-0004KW-DD
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:24:30 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	B9/1D-17735-D59A8545; Tue, 04 Nov 2014 10:24:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415096667!7766925!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15306 invoked from network); 4 Nov 2014 10:24:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:24:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189230630"
Message-ID: <1415096635.11486.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 10:23:55 +0000
In-Reply-To: <54513A08.3000908@linaro.org>
References: <1414144694.15687.31.camel@citrix.com>
	<1414144717-32328-1-git-send-email-ian.campbell@citrix.com>
	<54513A08.3000908@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] xen: arm: propagate gic's
 #address-cells property 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 Wed, 2014-10-29 at 19:03 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 24/10/2014 10:58, Ian Campbell wrote:
> > The interrupt-map property requires that the interrupt-parent node
> > must have both #address-cells and #interrupt-cells properties (see
> > ePAPR 2.4.3.1). Therefore propagate the property if it is present.
> >
> > We must propagate (rather than invent our own value) since this value
> > is used to size fields within other properties within the tree.
> >
> > ePAPR strictly speaking requires that the interrupt-parent node
> > always has these properties. However reality has diverged from this
> > and implementations will recursively search parents for #*-cells
> > properties. Hence we only copy if it is present.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Reviewed-by: Julien Grall <julien.grall@linaro.org>
> 
> Without this patch I can't boot Xen on the Foundation model with GIC-v3. 
> Is it possible to push this patch for Xen 4.5 rc1?

Konrad, I think this is needed for 4.5 since without it dom0 can fail to
parse certain other constructs within the DT (in bits which we don't
generate and can't easily/don't want to rewrite as we pass them
through).

The risk is that some bit of DT which we do generate relies on this
value being absent (as it was before this patch). I don't believe we
generate any such nodes. The consumers are typically nodes representing
devices which we pass through rather than messing with them.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:37:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:37:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbUW-0004db-P2; Tue, 04 Nov 2014 10:37: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 1XlbUV-0004dV-32
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:37:35 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	09/82-31453-E6CA8545; Tue, 04 Nov 2014 10:37:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415097453!5669725!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6754 invoked from network); 4 Nov 2014 10:37:33 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Nov 2014 10:37:33 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 10:37:33 +0000
Message-Id: <5458BA790200007800044B58@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 10:37:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
	<1415042078-8337-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1415042078-8337-3-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [for-xen-4.5 v9 2/2] dpci: Replace tasklet with an
 softirq (v12)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 20:14, <konrad.wilk@oracle.com> wrote:
> +/*
> + * Should only be called from hvm_do_IRQ_dpci. We use the

This statement together with the comment in pt_pirq_softirq_active()
is at least confusing: If the function is to be called in only one place,
there shouldn't be a second place where its use is being suggested.
Plus, a function with such required limited use would very likely better
not be a separate function at all.

> @@ -159,7 +279,16 @@ int pt_irq_create_bind(
>              {
>                  rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
>                  if ( unlikely(rc) )
> +                {
>                      pirq_guest_unbind(d, info);
> +                    /*
> +                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
> +                     * an interrupt can be scheduled. No more of them are going
> +                     * to be scheduled but we must deal with the one that is in

s/ is / may be /?

> @@ -269,6 +398,10 @@ int pt_irq_create_bind(
>              {
>                  if ( pt_irq_need_timer(pirq_dpci->flags) )
>                      kill_timer(&pirq_dpci->timer);
> +                /*
> +                 * There is no path for __do_IRQ to schedule softirq as
> +                 * IRQ_GUEST is not set. As such we can reset 'dom' right away.

"right away" suggests the alternative handling defers it in any way.
Maybe better "directly"?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:37:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:37:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbUW-0004db-P2; Tue, 04 Nov 2014 10:37: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 1XlbUV-0004dV-32
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:37:35 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	09/82-31453-E6CA8545; Tue, 04 Nov 2014 10:37:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415097453!5669725!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6754 invoked from network); 4 Nov 2014 10:37:33 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Nov 2014 10:37:33 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 10:37:33 +0000
Message-Id: <5458BA790200007800044B58@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 10:37:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
	<1415042078-8337-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1415042078-8337-3-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [for-xen-4.5 v9 2/2] dpci: Replace tasklet with an
 softirq (v12)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.11.14 at 20:14, <konrad.wilk@oracle.com> wrote:
> +/*
> + * Should only be called from hvm_do_IRQ_dpci. We use the

This statement together with the comment in pt_pirq_softirq_active()
is at least confusing: If the function is to be called in only one place,
there shouldn't be a second place where its use is being suggested.
Plus, a function with such required limited use would very likely better
not be a separate function at all.

> @@ -159,7 +279,16 @@ int pt_irq_create_bind(
>              {
>                  rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
>                  if ( unlikely(rc) )
> +                {
>                      pirq_guest_unbind(d, info);
> +                    /*
> +                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
> +                     * an interrupt can be scheduled. No more of them are going
> +                     * to be scheduled but we must deal with the one that is in

s/ is / may be /?

> @@ -269,6 +398,10 @@ int pt_irq_create_bind(
>              {
>                  if ( pt_irq_need_timer(pirq_dpci->flags) )
>                      kill_timer(&pirq_dpci->timer);
> +                /*
> +                 * There is no path for __do_IRQ to schedule softirq as
> +                 * IRQ_GUEST is not set. As such we can reset 'dom' right away.

"right away" suggests the alternative handling defers it in any way.
Maybe better "directly"?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:37:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:37:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbUl-0004ei-6P; Tue, 04 Nov 2014 10:37:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlbUj-0004eR-Tu
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:37:50 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	B5/EB-25547-D7CA8545; Tue, 04 Nov 2014 10:37:49 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415097459!11465508!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10926 invoked from network); 4 Nov 2014 10:37:41 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:37:41 -0000
Received: by mail-qa0-f50.google.com with SMTP id bm13so8028463qab.9
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 02:37:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=d5P+YLlWKJrlp0W/ZpyhnmDd1+cjRBocThySH1j6wzo=;
	b=ELpf6VRUNt3oiNWtpMsAKe+hNb6PinvPKpgcIcx5UYYKYxFsnhXub/h7yYftHaYreF
	2NV7gKGP9MF2m3HffZJxgVW+wvrJt4YAAKtN5Fg0pv5uAM87mwjDeR9G+BYXOROwSazo
	h6yeb6V3pTLDY9R5bH/PBujaylLrpqNThzeMb4V94Y3ANoyxl8g5iKCqgBvkxO+duPnS
	jE8KXmeDIHX7K2+tls+owPQHU+BQ47HLCqLk0pNjufiKmSRK3mwP6dvIeh8oKZ9i2ME7
	Tj0KMcy3D5Fxrpg8i1xvdmceQ3t0Uj6M2dp+eO9AhzVUS3SCP7wjEqkrU/Zr2ucwaf7f
	6o4g==
MIME-Version: 1.0
X-Received: by 10.224.66.70 with SMTP id m6mr75772079qai.45.1415097459608;
	Tue, 04 Nov 2014 02:37:39 -0800 (PST)
Received: by 10.96.105.199 with HTTP; Tue, 4 Nov 2014 02:37:39 -0800 (PST)
In-Reply-To: <20141103144848.GB28870@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
Date: Tue, 4 Nov 2014 10:37:39 +0000
X-Google-Sender-Auth: hoy_eqLnvQwN0eEo6gLfZw_T2c8
Message-ID: <CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Wei Liu <wei.liu2@citrix.com>,
	"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 for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, Nov 3, 2014 at 2:48 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Nov 03, George Dunlap wrote:
>
>> On 11/03/2014 02:24 PM, Olaf Hering wrote:
>> >On Mon, Nov 03, George Dunlap wrote:
>> >
>> >>How difficult would it be to have this be something sensible like,
>> >>"changesets since last tag"?
>> >Very difficult, because one does changes without commit, runs 'make
>> >rpmball' and expects that rpm -Fvh *.rpm continues to work.
>>
>> Right.  Personally, I think trying to make "rpm -Fvh" work for all the use
>> cases a developer might want is more hassle than it's worth; as I said, I
>> have scripts that just do "rpm -e" in such cases.  I wouldn't oppose it, but
>> I don't really support it either.
>
> What exactly is the hassle here?! Its just some number for the sake of
> rpm.

A number based on the time you happened to create the RPM, not based
on something intrinsic about the content of the RPM; that just seems
kind of hacky to me.  It happens to work well for your common
workflow, but you can certainly imagine other workflows or other
situations where you'd have to more manually override things anyway
(for instance, doing bisections, or comparing functionality in
different releases).  It seems like rather than having to remember
when you can skip the manual override bits, and when you can't, it
would be better to just use them all the time.

Anyway, like I said, I won't argue against it.  I have no technical
objections to the patch; it seems to do what it says on the tin.  I'll
leave it for the maintainers to decide what they think about the
functionality.

 -George

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:37:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:37:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbUl-0004ei-6P; Tue, 04 Nov 2014 10:37:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XlbUj-0004eR-Tu
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:37:50 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	B5/EB-25547-D7CA8545; Tue, 04 Nov 2014 10:37:49 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415097459!11465508!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10926 invoked from network); 4 Nov 2014 10:37:41 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:37:41 -0000
Received: by mail-qa0-f50.google.com with SMTP id bm13so8028463qab.9
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 02:37:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=d5P+YLlWKJrlp0W/ZpyhnmDd1+cjRBocThySH1j6wzo=;
	b=ELpf6VRUNt3oiNWtpMsAKe+hNb6PinvPKpgcIcx5UYYKYxFsnhXub/h7yYftHaYreF
	2NV7gKGP9MF2m3HffZJxgVW+wvrJt4YAAKtN5Fg0pv5uAM87mwjDeR9G+BYXOROwSazo
	h6yeb6V3pTLDY9R5bH/PBujaylLrpqNThzeMb4V94Y3ANoyxl8g5iKCqgBvkxO+duPnS
	jE8KXmeDIHX7K2+tls+owPQHU+BQ47HLCqLk0pNjufiKmSRK3mwP6dvIeh8oKZ9i2ME7
	Tj0KMcy3D5Fxrpg8i1xvdmceQ3t0Uj6M2dp+eO9AhzVUS3SCP7wjEqkrU/Zr2ucwaf7f
	6o4g==
MIME-Version: 1.0
X-Received: by 10.224.66.70 with SMTP id m6mr75772079qai.45.1415097459608;
	Tue, 04 Nov 2014 02:37:39 -0800 (PST)
Received: by 10.96.105.199 with HTTP; Tue, 4 Nov 2014 02:37:39 -0800 (PST)
In-Reply-To: <20141103144848.GB28870@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
Date: Tue, 4 Nov 2014 10:37:39 +0000
X-Google-Sender-Auth: hoy_eqLnvQwN0eEo6gLfZw_T2c8
Message-ID: <CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Wei Liu <wei.liu2@citrix.com>,
	"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 for-xen-4.5] tools/mkrpm: improve
 version.release 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 Mon, Nov 3, 2014 at 2:48 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Nov 03, George Dunlap wrote:
>
>> On 11/03/2014 02:24 PM, Olaf Hering wrote:
>> >On Mon, Nov 03, George Dunlap wrote:
>> >
>> >>How difficult would it be to have this be something sensible like,
>> >>"changesets since last tag"?
>> >Very difficult, because one does changes without commit, runs 'make
>> >rpmball' and expects that rpm -Fvh *.rpm continues to work.
>>
>> Right.  Personally, I think trying to make "rpm -Fvh" work for all the use
>> cases a developer might want is more hassle than it's worth; as I said, I
>> have scripts that just do "rpm -e" in such cases.  I wouldn't oppose it, but
>> I don't really support it either.
>
> What exactly is the hassle here?! Its just some number for the sake of
> rpm.

A number based on the time you happened to create the RPM, not based
on something intrinsic about the content of the RPM; that just seems
kind of hacky to me.  It happens to work well for your common
workflow, but you can certainly imagine other workflows or other
situations where you'd have to more manually override things anyway
(for instance, doing bisections, or comparing functionality in
different releases).  It seems like rather than having to remember
when you can skip the manual override bits, and when you can't, it
would be better to just use them all the time.

Anyway, like I said, I won't argue against it.  I have no technical
objections to the patch; it seems to do what it says on the tin.  I'll
leave it for the maintainers to decide what they think about the
functionality.

 -George

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:41:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:41:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbYY-0004tW-UC; Tue, 04 Nov 2014 10:41:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlbYX-0004t2-Fq
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:41:45 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	60/86-22819-86DA8545; Tue, 04 Nov 2014 10:41:44 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415097702!11075301!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3301 invoked from network); 4 Nov 2014 10:41:43 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-206.messagelabs.com with SMTP;
	4 Nov 2014 10:41:43 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 04 Nov 2014 02:41:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,312,1413270000"; d="scan'208";a="626168104"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.157])
	([10.238.128.157])
	by fmsmga002.fm.intel.com with ESMTP; 04 Nov 2014 02:41:40 -0800
Message-ID: <5458AD63.4020301@intel.com>
Date: Tue, 04 Nov 2014 18:41:39 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
	<54577AD302000078000445EB@mail.emea.novell.com>
	<54582D59.4020201@intel.com>
	<545896080200007800044A67@mail.emea.novell.com>
In-Reply-To: <545896080200007800044A67@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/4 16:02, Jan Beulich wrote:
>>>> On 04.11.14 at 02:35, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 19:53, Jan Beulich wrote:
>>>>>> On 03.11.14 at 12:48, <tiejun.chen@intel.com> wrote:
>>>> On 2014/11/3 18:03, Jan Beulich wrote:
>>>>>>>> On 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
>>>>>> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>>>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>>>>>>> #2 the error handling
>>>>>>>>
>>>>>>>> In an error case what should I do? Currently we still create these
>>>>>>>> mapping as normal. This means these mfns will be valid so later we can't
>>>>>>>> set them again then device can't be assigned as passthrough. I think
>>>>>>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>>>>>>
>>>>>>> You should, with very few exceptions, not ignore errors (which
>>>>>>> includes "handling" them by just logging a message. Instead, you
>>>>>>> should propagate the error back up the call chain.
>>>>>>>
>>>>>>
>>>>>> Do you mean in your patch,
>>>>>>
>>>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>>>> +{
>>>>>> +    const struct iommu_ops *ops = iommu_get_ops();
>>>>>> +
>>>>>> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
>>>>>> +        return 0;
>>>>>> +
>>>>>> +    return ops->get_reserved_device_memory(func, ctxt);
>>>>>> +}
>>>>>> +
>>>>>>
>>>>>> I shouldn't return that directly. Then instead, we should handle all
>>>>>> error scenarios here?
>>>>>
>>>>> No. All error scenarios are already being handled here (by
>>>>> propagating the error code to the caller).
>>>>
>>>> Sorry, how to propagate the error code?
>>>
>>> Return it to the caller (and it will do so onwards, until it reaches
>>> [presumably] the entity having invoked a hypercall).
>>
>> I guess you mean we should return out in this error case,
>
> Yes!
>
>> @@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>        /* Now, actually do the two-way mapping */
>>        if ( mfn_valid(_mfn(mfn)) )
>>        {
>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>> -                           p2m->default_access);
>> +        rc = 0;
>> +        a =  p2m->default_access;
>> +        if ( !is_hardware_domain(d) )
>> +        {
>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>> +                                                  &gfn);
>> +            /* We always avoid populating reserved device memory. */
>> +            if ( rc == 1 )
>> +                goto out;
>
> But you'll need to make sure that you don't return 1 to the callers:

You're right.

> They expect 0 or negative error codes. But with the model of
> not even populating these regions (or relocating the memory
> before [at boot time] assigning a device associated with an RMRR)
> I think this needs to become an error anyway.

Looks -EINVAL might be used.

>
>> +            else if ( rc < 0 )
>> +            {
>> +                printk(XENLOG_G_WARNING
>> +                       "Dom%d can't check reserved device memory.\n",
>
> Actually, d being the subject domain, please make this more like
> "Can't check reserved device memory for Dom%d\n".

Fixed.

Thanks
Tiejun

>
> Jan
>
>> +                       d->domain_id);
>> +                goto out;
>> +            }
>> +        }
>> +
>> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
>>            if ( rc )
>>                goto out; /* Failed to update p2m, bail without updating m2p. */
>>
>> Thanks
>> Tiejun
>
>
>
>
>

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:41:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:41:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbYY-0004tW-UC; Tue, 04 Nov 2014 10:41:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlbYX-0004t2-Fq
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:41:45 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	60/86-22819-86DA8545; Tue, 04 Nov 2014 10:41:44 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415097702!11075301!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3301 invoked from network); 4 Nov 2014 10:41:43 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-206.messagelabs.com with SMTP;
	4 Nov 2014 10:41:43 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 04 Nov 2014 02:41:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,312,1413270000"; d="scan'208";a="626168104"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.157])
	([10.238.128.157])
	by fmsmga002.fm.intel.com with ESMTP; 04 Nov 2014 02:41:40 -0800
Message-ID: <5458AD63.4020301@intel.com>
Date: Tue, 04 Nov 2014 18:41:39 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
	<54577AD302000078000445EB@mail.emea.novell.com>
	<54582D59.4020201@intel.com>
	<545896080200007800044A67@mail.emea.novell.com>
In-Reply-To: <545896080200007800044A67@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/4 16:02, Jan Beulich wrote:
>>>> On 04.11.14 at 02:35, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 19:53, Jan Beulich wrote:
>>>>>> On 03.11.14 at 12:48, <tiejun.chen@intel.com> wrote:
>>>> On 2014/11/3 18:03, Jan Beulich wrote:
>>>>>>>> On 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
>>>>>> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>>>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>>>>>>> #2 the error handling
>>>>>>>>
>>>>>>>> In an error case what should I do? Currently we still create these
>>>>>>>> mapping as normal. This means these mfns will be valid so later we can't
>>>>>>>> set them again then device can't be assigned as passthrough. I think
>>>>>>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>>>>>>
>>>>>>> You should, with very few exceptions, not ignore errors (which
>>>>>>> includes "handling" them by just logging a message. Instead, you
>>>>>>> should propagate the error back up the call chain.
>>>>>>>
>>>>>>
>>>>>> Do you mean in your patch,
>>>>>>
>>>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>>>> +{
>>>>>> +    const struct iommu_ops *ops = iommu_get_ops();
>>>>>> +
>>>>>> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
>>>>>> +        return 0;
>>>>>> +
>>>>>> +    return ops->get_reserved_device_memory(func, ctxt);
>>>>>> +}
>>>>>> +
>>>>>>
>>>>>> I shouldn't return that directly. Then instead, we should handle all
>>>>>> error scenarios here?
>>>>>
>>>>> No. All error scenarios are already being handled here (by
>>>>> propagating the error code to the caller).
>>>>
>>>> Sorry, how to propagate the error code?
>>>
>>> Return it to the caller (and it will do so onwards, until it reaches
>>> [presumably] the entity having invoked a hypercall).
>>
>> I guess you mean we should return out in this error case,
>
> Yes!
>
>> @@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>        /* Now, actually do the two-way mapping */
>>        if ( mfn_valid(_mfn(mfn)) )
>>        {
>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>> -                           p2m->default_access);
>> +        rc = 0;
>> +        a =  p2m->default_access;
>> +        if ( !is_hardware_domain(d) )
>> +        {
>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>> +                                                  &gfn);
>> +            /* We always avoid populating reserved device memory. */
>> +            if ( rc == 1 )
>> +                goto out;
>
> But you'll need to make sure that you don't return 1 to the callers:

You're right.

> They expect 0 or negative error codes. But with the model of
> not even populating these regions (or relocating the memory
> before [at boot time] assigning a device associated with an RMRR)
> I think this needs to become an error anyway.

Looks -EINVAL might be used.

>
>> +            else if ( rc < 0 )
>> +            {
>> +                printk(XENLOG_G_WARNING
>> +                       "Dom%d can't check reserved device memory.\n",
>
> Actually, d being the subject domain, please make this more like
> "Can't check reserved device memory for Dom%d\n".

Fixed.

Thanks
Tiejun

>
> Jan
>
>> +                       d->domain_id);
>> +                goto out;
>> +            }
>> +        }
>> +
>> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, a);
>>            if ( rc )
>>                goto out; /* Failed to update p2m, bail without updating m2p. */
>>
>> Thanks
>> Tiejun
>
>
>
>
>

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:44:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10: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 1Xlbac-00058F-FQ; Tue, 04 Nov 2014 10:43:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xlbaa-000584-Gf
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:43:52 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	10/BE-17694-7EDA8545; Tue, 04 Nov 2014 10:43:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415097831!11508613!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24688 invoked from network); 4 Nov 2014 10:43:51 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 10:43:51 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 10:43:50 +0000
Message-Id: <5458BBF30200007800044B69@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 10:43:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH] MAINTAINERS: move hvmloader to x86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

... as being more like a hypervisor extension into the guest than a
part of the tool stack.

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

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -344,6 +344,7 @@ S:	Supported
 L:	xen-devel@lists.xen.org 
 F:	xen/arch/x86/
 F:	xen/include/asm-x86/
+F:	tools/firmware/hvmloader/
 
 X86 MEMORY MANAGEMENT
 M:	Tim Deegan <tim@xen.org>




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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:44:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10: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 1Xlbac-00058F-FQ; Tue, 04 Nov 2014 10:43:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xlbaa-000584-Gf
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:43:52 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	10/BE-17694-7EDA8545; Tue, 04 Nov 2014 10:43:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415097831!11508613!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24688 invoked from network); 4 Nov 2014 10:43:51 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 10:43:51 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 10:43:50 +0000
Message-Id: <5458BBF30200007800044B69@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 10:43:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH] MAINTAINERS: move hvmloader to x86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

... as being more like a hypervisor extension into the guest than a
part of the tool stack.

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

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -344,6 +344,7 @@ S:	Supported
 L:	xen-devel@lists.xen.org 
 F:	xen/arch/x86/
 F:	xen/include/asm-x86/
+F:	tools/firmware/hvmloader/
 
 X86 MEMORY MANAGEMENT
 M:	Tim Deegan <tim@xen.org>




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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:44:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:44:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbbT-0005Db-TO; Tue, 04 Nov 2014 10:44:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlbbT-0005DR-1R
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:44:47 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	75/0B-26858-E1EA8545; Tue, 04 Nov 2014 10:44:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415097884!7772721!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2869 invoked from network); 4 Nov 2014 10:44:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:44:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189234499"
Message-ID: <1415097882.11486.17.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 4 Nov 2014 10:44:42 +0000
In-Reply-To: <5458BBF30200007800044B69@mail.emea.novell.com>
References: <5458BBF30200007800044B69@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: move hvmloader to x86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 10:43 +0000, Jan Beulich wrote:
> ... as being more like a hypervisor extension into the guest than a
> part of the tool stack.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

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

/me goes to sweep out his QUEUE IMAP folder...

> 
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -344,6 +344,7 @@ S:	Supported
>  L:	xen-devel@lists.xen.org 
>  F:	xen/arch/x86/
>  F:	xen/include/asm-x86/
> +F:	tools/firmware/hvmloader/
>  
>  X86 MEMORY MANAGEMENT
>  M:	Tim Deegan <tim@xen.org>
> 
> 
> 



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:44:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:44:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbbT-0005Db-TO; Tue, 04 Nov 2014 10:44:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlbbT-0005DR-1R
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:44:47 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	75/0B-26858-E1EA8545; Tue, 04 Nov 2014 10:44:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415097884!7772721!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2869 invoked from network); 4 Nov 2014 10:44:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:44:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189234499"
Message-ID: <1415097882.11486.17.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 4 Nov 2014 10:44:42 +0000
In-Reply-To: <5458BBF30200007800044B69@mail.emea.novell.com>
References: <5458BBF30200007800044B69@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: move hvmloader to x86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 10:43 +0000, Jan Beulich wrote:
> ... as being more like a hypervisor extension into the guest than a
> part of the tool stack.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

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

/me goes to sweep out his QUEUE IMAP folder...

> 
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -344,6 +344,7 @@ S:	Supported
>  L:	xen-devel@lists.xen.org 
>  F:	xen/arch/x86/
>  F:	xen/include/asm-x86/
> +F:	tools/firmware/hvmloader/
>  
>  X86 MEMORY MANAGEMENT
>  M:	Tim Deegan <tim@xen.org>
> 
> 
> 



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:46:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:46:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbdL-0005OK-FM; Tue, 04 Nov 2014 10:46: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 1XlbdK-0005O9-G9
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:46:42 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	4F/5E-22737-19EA8545; Tue, 04 Nov 2014 10:46:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415097999!11068107!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15376 invoked from network); 4 Nov 2014 10:46:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:46:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187854506"
Message-ID: <1415097997.11486.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Tue, 4 Nov 2014 10:46:37 +0000
In-Reply-To: <544E7459.5070906@oracle.com>
References: <1414425614-43267-1-git-send-email-simon.rowe@eu.citrix.com>
	<544E7459.5070906@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Dave.Scott@citrix.com, Simon Rowe <simon.rowe@eu.citrix.com>,
	xen-devel@lists.xen.org, Stefano.Stabellini@citrix.com,
	Ian.Jackson@citrix.com
Subject: Re: [Xen-devel] [PATCH] pygrub: fix non-interactive parsing of
 grub1 config files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-10-27 at 12:35 -0400, Boris Ostrovsky wrote:
> On 10/27/2014 12:00 PM, Simon Rowe wrote:
> > Changes to handle non-numeric default attributes for grub2 caused run_grub()
> > to attempt to index into the images list using a string. Pull out the code
> > that handles submenus into a new function and use that to ensure sel is
> > numeric.
> >
> > Reported-by: David Scott <dave.scott@citrix.com>
> > Signed-off-by: Simon Rowe <simon.rowe@eu.citrix.com>
> 
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

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

And applied as a bug fix (I'm not sure if Konrad's response was intended
as a release-ack).

> 
> > ---
> >   tools/pygrub/src/pygrub |   23 ++++++++++++++---------
> >   1 file changed, 14 insertions(+), 9 deletions(-)
> >
> > diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> > index 1ae34a2..4cc846f 100644
> > --- a/tools/pygrub/src/pygrub
> > +++ b/tools/pygrub/src/pygrub
> > @@ -456,11 +456,9 @@ class Grub:
> >           del f
> >           self.cf.parse(buf)
> >   
> > -    def run(self):
> > -        timeout = int(self.cf.timeout)
> > -
> > +    def image_index(self):
> >           if self.cf.default.isdigit():
> > -            self.selected_image = int(self.cf.default)
> > +            sel = int(self.cf.default)
> >           else:
> >               # We don't fully support submenus. Look for the leaf value in
> >               # "submenu0>submenu1>...>menuentry" and hope that it's unique.
> > @@ -472,16 +470,23 @@ class Grub:
> >                       break
> >   
> >               # Map string to index in images array
> > -            self.selected_image = 0
> > +            sel = 0
> >               for i in range(len(self.cf.images)):
> >                   if self.cf.images[i].title == title:
> > -                    self.selected_image = i
> > +                    sel = i
> >                       break
> >   
> >           # If the selected (default) image doesn't exist we select the first entry
> > -        if self.selected_image > len(self.cf.images):
> > +        if sel > len(self.cf.images):
> >               logging.warning("Default image not found")
> > -            self.selected_image = 0
> > +            sel = 0
> > +
> > +        return sel
> > +
> > +    def run(self):
> > +        timeout = int(self.cf.timeout)
> > +        self.selected_image = self.image_index()
> > +
> >           self.isdone = False
> >           while not self.isdone:
> >               self.run_main(timeout)
> > @@ -626,7 +631,7 @@ def run_grub(file, entry, fs, cfg_args):
> >       if interactive and not list_entries:
> >           curses.wrapper(run_main)
> >       else:
> > -        sel = g.cf.default
> > +        sel = g.image_index()
> >   
> >       # set the entry to boot as requested
> >       if entry is not None:
> 



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:46:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:46:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbdL-0005OK-FM; Tue, 04 Nov 2014 10:46: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 1XlbdK-0005O9-G9
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:46:42 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	4F/5E-22737-19EA8545; Tue, 04 Nov 2014 10:46:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415097999!11068107!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15376 invoked from network); 4 Nov 2014 10:46:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:46:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187854506"
Message-ID: <1415097997.11486.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Tue, 4 Nov 2014 10:46:37 +0000
In-Reply-To: <544E7459.5070906@oracle.com>
References: <1414425614-43267-1-git-send-email-simon.rowe@eu.citrix.com>
	<544E7459.5070906@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Dave.Scott@citrix.com, Simon Rowe <simon.rowe@eu.citrix.com>,
	xen-devel@lists.xen.org, Stefano.Stabellini@citrix.com,
	Ian.Jackson@citrix.com
Subject: Re: [Xen-devel] [PATCH] pygrub: fix non-interactive parsing of
 grub1 config files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-10-27 at 12:35 -0400, Boris Ostrovsky wrote:
> On 10/27/2014 12:00 PM, Simon Rowe wrote:
> > Changes to handle non-numeric default attributes for grub2 caused run_grub()
> > to attempt to index into the images list using a string. Pull out the code
> > that handles submenus into a new function and use that to ensure sel is
> > numeric.
> >
> > Reported-by: David Scott <dave.scott@citrix.com>
> > Signed-off-by: Simon Rowe <simon.rowe@eu.citrix.com>
> 
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

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

And applied as a bug fix (I'm not sure if Konrad's response was intended
as a release-ack).

> 
> > ---
> >   tools/pygrub/src/pygrub |   23 ++++++++++++++---------
> >   1 file changed, 14 insertions(+), 9 deletions(-)
> >
> > diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> > index 1ae34a2..4cc846f 100644
> > --- a/tools/pygrub/src/pygrub
> > +++ b/tools/pygrub/src/pygrub
> > @@ -456,11 +456,9 @@ class Grub:
> >           del f
> >           self.cf.parse(buf)
> >   
> > -    def run(self):
> > -        timeout = int(self.cf.timeout)
> > -
> > +    def image_index(self):
> >           if self.cf.default.isdigit():
> > -            self.selected_image = int(self.cf.default)
> > +            sel = int(self.cf.default)
> >           else:
> >               # We don't fully support submenus. Look for the leaf value in
> >               # "submenu0>submenu1>...>menuentry" and hope that it's unique.
> > @@ -472,16 +470,23 @@ class Grub:
> >                       break
> >   
> >               # Map string to index in images array
> > -            self.selected_image = 0
> > +            sel = 0
> >               for i in range(len(self.cf.images)):
> >                   if self.cf.images[i].title == title:
> > -                    self.selected_image = i
> > +                    sel = i
> >                       break
> >   
> >           # If the selected (default) image doesn't exist we select the first entry
> > -        if self.selected_image > len(self.cf.images):
> > +        if sel > len(self.cf.images):
> >               logging.warning("Default image not found")
> > -            self.selected_image = 0
> > +            sel = 0
> > +
> > +        return sel
> > +
> > +    def run(self):
> > +        timeout = int(self.cf.timeout)
> > +        self.selected_image = self.image_index()
> > +
> >           self.isdone = False
> >           while not self.isdone:
> >               self.run_main(timeout)
> > @@ -626,7 +631,7 @@ def run_grub(file, entry, fs, cfg_args):
> >       if interactive and not list_entries:
> >           curses.wrapper(run_main)
> >       else:
> > -        sel = g.cf.default
> > +        sel = g.image_index()
> >   
> >       # set the entry to boot as requested
> >       if entry is not None:
> 



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:46:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbdW-0005Qr-Rh; Tue, 04 Nov 2014 10:46:54 +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 1XlbdU-0005QB-Ni
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:46:52 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	9B/B0-27785-B9EA8545; Tue, 04 Nov 2014 10:46:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415098010!12434570!1
X-Originating-IP: [81.169.146.219]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25282 invoked from network); 4 Nov 2014 10:46:50 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.219)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 10:46:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415098010; l=1076;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=XASIf6CQ0T6fdCH2QrnWk9S2ICE=;
	b=NJ+JtKRe6SvmZa4UcJIDpD1QPPHSMdYJLkPnQW626RzZ/3XXKqQ19UPuHsVHViClTw1
	lrYBMd0XfcgwJDCSTCfrDgTdSxIsqtnMn586GVay3/4LeoIN89zdYLMBEV4IYm8jq6On9
	TWqu74mJR5lZznr0tk63xd2sZfTuYmatASQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id g062f4qA4AkoYBz
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 4 Nov 2014 11:46:50 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 8F46150172; Tue,  4 Nov 2014 11:46:49 +0100 (CET)
Date: Tue, 4 Nov 2014 11:46:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141104104649.GA8479@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
	<CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>,
	"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 for-xen-4.5] tools/mkrpm: improve
 version.release 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, Nov 04, George Dunlap wrote:

> A number based on the time you happened to create the RPM, not based
> on something intrinsic about the content of the RPM; that just seems
> kind of hacky to me.  It happens to work well for your common
> workflow, but you can certainly imagine other workflows or other
> situations where you'd have to more manually override things anyway
> (for instance, doing bisections, or comparing functionality in
> different releases).  It seems like rather than having to remember
> when you can skip the manual override bits, and when you can't, it
> would be better to just use them all the time.

George, the release number is and was never meant to describe the
content of a package. It just means "its different". And it will even
work for bisect because the package is always "newer", even if the
content is different.

And after commit b8ebc6b9e07d3cc061fdded1a0530bd6b25d4634 ("tools/mkrpm:
allow custom rpm package name") and all the --prefix changes its easy to
have independent packages for every branch.

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:46:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbdW-0005Qr-Rh; Tue, 04 Nov 2014 10:46:54 +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 1XlbdU-0005QB-Ni
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:46:52 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	9B/B0-27785-B9EA8545; Tue, 04 Nov 2014 10:46:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415098010!12434570!1
X-Originating-IP: [81.169.146.219]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25282 invoked from network); 4 Nov 2014 10:46:50 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.219)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 10:46:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415098010; l=1076;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=XASIf6CQ0T6fdCH2QrnWk9S2ICE=;
	b=NJ+JtKRe6SvmZa4UcJIDpD1QPPHSMdYJLkPnQW626RzZ/3XXKqQ19UPuHsVHViClTw1
	lrYBMd0XfcgwJDCSTCfrDgTdSxIsqtnMn586GVay3/4LeoIN89zdYLMBEV4IYm8jq6On9
	TWqu74mJR5lZznr0tk63xd2sZfTuYmatASQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id g062f4qA4AkoYBz
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 4 Nov 2014 11:46:50 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 8F46150172; Tue,  4 Nov 2014 11:46:49 +0100 (CET)
Date: Tue, 4 Nov 2014 11:46:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141104104649.GA8479@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
	<CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>,
	"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 for-xen-4.5] tools/mkrpm: improve
 version.release 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, Nov 04, George Dunlap wrote:

> A number based on the time you happened to create the RPM, not based
> on something intrinsic about the content of the RPM; that just seems
> kind of hacky to me.  It happens to work well for your common
> workflow, but you can certainly imagine other workflows or other
> situations where you'd have to more manually override things anyway
> (for instance, doing bisections, or comparing functionality in
> different releases).  It seems like rather than having to remember
> when you can skip the manual override bits, and when you can't, it
> would be better to just use them all the time.

George, the release number is and was never meant to describe the
content of a package. It just means "its different". And it will even
work for bisect because the package is always "newer", even if the
content is different.

And after commit b8ebc6b9e07d3cc061fdded1a0530bd6b25d4634 ("tools/mkrpm:
allow custom rpm package name") and all the --prefix changes its easy to
have independent packages for every branch.

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:47:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlbds-0005WL-EK; Tue, 04 Nov 2014 10:47:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xlbdr-0005W1-K8
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:47:15 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	91/64-05632-2BEA8545; Tue, 04 Nov 2014 10:47:14 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415098033!7065720!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23483 invoked from network); 4 Nov 2014 10:47:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:47:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189234881"
Message-ID: <5458AEAE.9080804@citrix.com>
Date: Tue, 4 Nov 2014 10:47:10 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <5458BBF30200007800044B69@mail.emea.novell.com>
In-Reply-To: <5458BBF30200007800044B69@mail.emea.novell.com>
X-DLP: MIA1
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: move hvmloader to x86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/14 10:43, Jan Beulich wrote:
> ... as being more like a hypervisor extension into the guest than a
> part of the tool stack.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I think this is a very sensible idea, but...

>
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -344,6 +344,7 @@ S:	Supported
>  L:	xen-devel@lists.xen.org 
>  F:	xen/arch/x86/
>  F:	xen/include/asm-x86/
> +F:	tools/firmware/hvmloader/

hvmloader as a binary is linked together with other bits in
tools/firmware, which form part of the x86 HVM boot path.

As a result, I would recommend this path being "tools/firmware/" to
include these other bits in being part of the x86 architecture code.

~Andrew

>  
>  X86 MEMORY MANAGEMENT
>  M:	Tim Deegan <tim@xen.org>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:47:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlbds-0005WL-EK; Tue, 04 Nov 2014 10:47:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xlbdr-0005W1-K8
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:47:15 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	91/64-05632-2BEA8545; Tue, 04 Nov 2014 10:47:14 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415098033!7065720!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23483 invoked from network); 4 Nov 2014 10:47:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:47:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189234881"
Message-ID: <5458AEAE.9080804@citrix.com>
Date: Tue, 4 Nov 2014 10:47:10 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <5458BBF30200007800044B69@mail.emea.novell.com>
In-Reply-To: <5458BBF30200007800044B69@mail.emea.novell.com>
X-DLP: MIA1
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: move hvmloader to x86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/14 10:43, Jan Beulich wrote:
> ... as being more like a hypervisor extension into the guest than a
> part of the tool stack.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I think this is a very sensible idea, but...

>
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -344,6 +344,7 @@ S:	Supported
>  L:	xen-devel@lists.xen.org 
>  F:	xen/arch/x86/
>  F:	xen/include/asm-x86/
> +F:	tools/firmware/hvmloader/

hvmloader as a binary is linked together with other bits in
tools/firmware, which form part of the x86 HVM boot path.

As a result, I would recommend this path being "tools/firmware/" to
include these other bits in being part of the x86 architecture code.

~Andrew

>  
>  X86 MEMORY MANAGEMENT
>  M:	Tim Deegan <tim@xen.org>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:48:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlbei-0005hB-Sg; Tue, 04 Nov 2014 10:48:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlbeh-0005gs-Hq
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:48:07 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	EB/EF-03145-6EEA8545; Tue, 04 Nov 2014 10:48:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415098085!12391597!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10003 invoked from network); 4 Nov 2014 10:48:06 -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;
	4 Nov 2014 10:48:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189235017"
Message-ID: <1415098082.11486.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 4 Nov 2014 10:48:02 +0000
In-Reply-To: <1414591781-19376-1-git-send-email-andrew.cooper3@citrix.com>
References: <1414591781-19376-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/pygrub: Fix TOCTOU race
 introduced by c/s 63dcc68
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-10-29 at 14:09 +0000, Andrew Cooper wrote:
> In addition, use os.makedirs() which will also create intermediate directories
> if they don't exist.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: Olaf Hering <olaf@aepfle.de>

Acked and applied as a bug fix.

In the future when you include a "for-4.5" tag on a patch please
*always* state your reasoning (usually after the "---"). Don't make the
maintainer / release manager / committer guess why you think it should
be in 4.5. If you consider it "obviously a bug fix" then say so and then
say something about the impact of the bug and the risk associated with
the fix.

I'm a bit grumpy about the number of patches which don't do this, such
patches are mostly going to the back of my queue, alongside the 4.6
patches, since without any rationale that is effectively what I consider
them to be despite the use of the for-4.5 tag.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:48:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlbei-0005hB-Sg; Tue, 04 Nov 2014 10:48:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlbeh-0005gs-Hq
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:48:07 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	EB/EF-03145-6EEA8545; Tue, 04 Nov 2014 10:48:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415098085!12391597!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10003 invoked from network); 4 Nov 2014 10:48:06 -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;
	4 Nov 2014 10:48:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189235017"
Message-ID: <1415098082.11486.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 4 Nov 2014 10:48:02 +0000
In-Reply-To: <1414591781-19376-1-git-send-email-andrew.cooper3@citrix.com>
References: <1414591781-19376-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/pygrub: Fix TOCTOU race
 introduced by c/s 63dcc68
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-10-29 at 14:09 +0000, Andrew Cooper wrote:
> In addition, use os.makedirs() which will also create intermediate directories
> if they don't exist.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: Olaf Hering <olaf@aepfle.de>

Acked and applied as a bug fix.

In the future when you include a "for-4.5" tag on a patch please
*always* state your reasoning (usually after the "---"). Don't make the
maintainer / release manager / committer guess why you think it should
be in 4.5. If you consider it "obviously a bug fix" then say so and then
say something about the impact of the bug and the risk associated with
the fix.

I'm a bit grumpy about the number of patches which don't do this, such
patches are mostly going to the back of my queue, alongside the 4.6
patches, since without any rationale that is effectively what I consider
them to be despite the use of the for-4.5 tag.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:48:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:48:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlbf7-0005mw-Am; Tue, 04 Nov 2014 10:48: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 1Xlbf4-0005m8-8z
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:48:31 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	D4/34-22737-DFEA8545; Tue, 04 Nov 2014 10:48:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415098107!7721239!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10035 invoked from network); 4 Nov 2014 10:48:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:48:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187854981"
Message-ID: <1415098105.11486.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Martin Pohlack <mpohlack@amazon.de>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 10:48:25 +0000
In-Reply-To: <1414499721-1100-1-git-send-email-mpohlack@amazon.de>
References: <1414499721-1100-1-git-send-email-mpohlack@amazon.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] blktap: CONFIG_GCRYPT detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-10-28 at 13:35 +0100, Martin Pohlack wrote:
> Wrap make variable in () to allow correct evaluation.
> 
> This fixes broken CONFIG_GCRYPT detection which was introduced by
> commit 85896a7c4dc7b6b1dba2db79dfb0ca61738a92a4 in 2012.
> 
> Signed-off-by: Martin Pohlack <mpohlack@amazon.de>
> Reviewed-by: Uwe Dannowski <uwed@amazon.de>
> Reviewed-by: Anthony Liguori <aliguori@amazon.com>
> Reviewed-by: Matt Wilson <msw@amazon.com>

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

You didn't mention if you considered this 4.5 material, but I think it
is a pretty obvious/safe bugfix so I've applied it.

> ---
>  tools/blktap/drivers/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/blktap/drivers/Makefile b/tools/blktap/drivers/Makefile
> index 7461a95..cea8b3b 100644
> --- a/tools/blktap/drivers/Makefile
> +++ b/tools/blktap/drivers/Makefile
> @@ -11,7 +11,7 @@ CFLAGS   += $(CFLAGS_libxenctrl)
>  CFLAGS   += $(CFLAGS_libxenstore)
>  CFLAGS   += -D_GNU_SOURCE
>  
> -ifeq ($CONFIG_GCRYPT,y)
> +ifeq ($(CONFIG_GCRYPT),y)
>  CFLAGS += -DUSE_GCRYPT
>  CRYPT_LIB := -lgcrypt
>  else



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:48:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:48:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlbf7-0005mw-Am; Tue, 04 Nov 2014 10:48: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 1Xlbf4-0005m8-8z
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:48:31 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	D4/34-22737-DFEA8545; Tue, 04 Nov 2014 10:48:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415098107!7721239!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10035 invoked from network); 4 Nov 2014 10:48:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:48:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187854981"
Message-ID: <1415098105.11486.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Martin Pohlack <mpohlack@amazon.de>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 10:48:25 +0000
In-Reply-To: <1414499721-1100-1-git-send-email-mpohlack@amazon.de>
References: <1414499721-1100-1-git-send-email-mpohlack@amazon.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] blktap: CONFIG_GCRYPT detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-10-28 at 13:35 +0100, Martin Pohlack wrote:
> Wrap make variable in () to allow correct evaluation.
> 
> This fixes broken CONFIG_GCRYPT detection which was introduced by
> commit 85896a7c4dc7b6b1dba2db79dfb0ca61738a92a4 in 2012.
> 
> Signed-off-by: Martin Pohlack <mpohlack@amazon.de>
> Reviewed-by: Uwe Dannowski <uwed@amazon.de>
> Reviewed-by: Anthony Liguori <aliguori@amazon.com>
> Reviewed-by: Matt Wilson <msw@amazon.com>

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

You didn't mention if you considered this 4.5 material, but I think it
is a pretty obvious/safe bugfix so I've applied it.

> ---
>  tools/blktap/drivers/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/blktap/drivers/Makefile b/tools/blktap/drivers/Makefile
> index 7461a95..cea8b3b 100644
> --- a/tools/blktap/drivers/Makefile
> +++ b/tools/blktap/drivers/Makefile
> @@ -11,7 +11,7 @@ CFLAGS   += $(CFLAGS_libxenctrl)
>  CFLAGS   += $(CFLAGS_libxenstore)
>  CFLAGS   += -D_GNU_SOURCE
>  
> -ifeq ($CONFIG_GCRYPT,y)
> +ifeq ($(CONFIG_GCRYPT),y)
>  CFLAGS += -DUSE_GCRYPT
>  CRYPT_LIB := -lgcrypt
>  else



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:48:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:48:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbfN-0005rC-OJ; Tue, 04 Nov 2014 10:48:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlbfN-0005qv-69
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:48:49 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	E2/93-02953-01FA8545; Tue, 04 Nov 2014 10:48:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415098126!12411930!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10406 invoked from network); 4 Nov 2014 10:48:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:48:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189235144"
Message-ID: <1415098124.11486.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 10:48:44 +0000
In-Reply-To: <5448D1C2.9050700@citrix.com>
References: <1413985962-31909-1-git-send-email-dave.scott@citrix.com>
	<5447BA71.9030405@citrix.com> <1414057369.19198.28.camel@citrix.com>
	<5448D1C2.9050700@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: David Scott <dave.scott@citrix.com>, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	rob.hoes@citrix.com, euan.harris@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: a domain can be dying but not
 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, 2014-10-23 at 11:00 +0100, Andrew Cooper wrote:

> > Did you instead mean this from libxl_types.idl:
> >     # Valid iff (shutdown||dying).
> >     #
> >     # Otherwise set to a value guaranteed not to clash with any valid
> >     # LIBXL_SHUTDOWN_REASON_* constant.
> >     ("shutdown_reason", libxl_shutdown_reason),
> > ?
> 
> That is the primary comment I was on about.

This wasn't tagged for 4.5 but it is a bug fix and the commit log &
associated commentary were pretty convincing, so Acked + Applied with
the additional hunk below folded in.

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ca3f724..f7fc695 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -260,7 +260,7 @@ libxl_dominfo = Struct("dominfo",[
     ("shutdown",    bool),
     ("dying",       bool),
 
-    # Valid iff (shutdown||dying).
+    # Valid iff ->shutdown is true.
     #
     # Otherwise set to a value guaranteed not to clash with any valid
     # LIBXL_SHUTDOWN_REASON_* constant.



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:48:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:48:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlbfN-0005rC-OJ; Tue, 04 Nov 2014 10:48:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlbfN-0005qv-69
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 10:48:49 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	E2/93-02953-01FA8545; Tue, 04 Nov 2014 10:48:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415098126!12411930!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10406 invoked from network); 4 Nov 2014 10:48:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:48:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189235144"
Message-ID: <1415098124.11486.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Tue, 4 Nov 2014 10:48:44 +0000
In-Reply-To: <5448D1C2.9050700@citrix.com>
References: <1413985962-31909-1-git-send-email-dave.scott@citrix.com>
	<5447BA71.9030405@citrix.com> <1414057369.19198.28.camel@citrix.com>
	<5448D1C2.9050700@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: David Scott <dave.scott@citrix.com>, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	rob.hoes@citrix.com, euan.harris@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: a domain can be dying but not
 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, 2014-10-23 at 11:00 +0100, Andrew Cooper wrote:

> > Did you instead mean this from libxl_types.idl:
> >     # Valid iff (shutdown||dying).
> >     #
> >     # Otherwise set to a value guaranteed not to clash with any valid
> >     # LIBXL_SHUTDOWN_REASON_* constant.
> >     ("shutdown_reason", libxl_shutdown_reason),
> > ?
> 
> That is the primary comment I was on about.

This wasn't tagged for 4.5 but it is a bug fix and the commit log &
associated commentary were pretty convincing, so Acked + Applied with
the additional hunk below folded in.

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ca3f724..f7fc695 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -260,7 +260,7 @@ libxl_dominfo = Struct("dominfo",[
     ("shutdown",    bool),
     ("dying",       bool),
 
-    # Valid iff (shutdown||dying).
+    # Valid iff ->shutdown is true.
     #
     # Otherwise set to a value guaranteed not to clash with any valid
     # LIBXL_SHUTDOWN_REASON_* constant.



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:50:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlbgt-00068q-8c; Tue, 04 Nov 2014 10:50:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xlbgr-00068g-P3
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 10:50:21 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	83/2E-29352-D6FA8545; Tue, 04 Nov 2014 10:50:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415098217!7721632!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24932 invoked from network); 4 Nov 2014 10:50:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:50:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187855587"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 05:50:16 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xlbgm-0005S4-5v;
	Tue, 04 Nov 2014 10:50:16 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xlbgl-00038N-Nd;
	Tue, 04 Nov 2014 10:50:15 +0000
Date: Tue, 4 Nov 2014 10:50:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31349-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31349: 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 31349 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31349/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3)   broken pass in 31331

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3)  broken blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail in 31331 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31331 never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         broken  
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

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

broken-step test-amd64-amd64-rumpuserxen-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemut-win7-amd64 host-install(3)

Not pushing.

(No revision log; it would be 27231 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 Nov 04 10:50:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlbgt-00068q-8c; Tue, 04 Nov 2014 10:50:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xlbgr-00068g-P3
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 10:50:21 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	83/2E-29352-D6FA8545; Tue, 04 Nov 2014 10:50:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415098217!7721632!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24932 invoked from network); 4 Nov 2014 10:50:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:50:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187855587"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 05:50:16 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xlbgm-0005S4-5v;
	Tue, 04 Nov 2014 10:50:16 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xlbgl-00038N-Nd;
	Tue, 04 Nov 2014 10:50:15 +0000
Date: Tue, 4 Nov 2014 10:50:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31349-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31349: 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 31349 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31349/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3)   broken pass in 31331

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3)  broken blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail in 31331 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31331 never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         broken  
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

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

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

broken-step test-amd64-amd64-rumpuserxen-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemut-win7-amd64 host-install(3)

Not pushing.

(No revision log; it would be 27231 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 Nov 04 10:52:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10: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 1Xlbiu-0006M5-Pt; Tue, 04 Nov 2014 10:52:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlbit-0006Lx-B8
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:52:27 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	A9/8C-17958-AEFA8545; Tue, 04 Nov 2014 10:52:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415098344!11448654!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15160 invoked from network); 4 Nov 2014 10:52:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:52:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189235749"
Message-ID: <1415098342.11486.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 4 Nov 2014 10:52:22 +0000
In-Reply-To: <1415098082.11486.19.camel@citrix.com>
References: <1414591781-19376-1-git-send-email-andrew.cooper3@citrix.com>
	<1415098082.11486.19.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Wei Liu <wei.liu2@citrix.com>, Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: [Xen-devel] Please *justify* your use of the for-4.5 tag when
	posting patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 10:48 +0000, Ian Campbell wrote:

Reposting with a more eyecatching subject, since this was by far not the
only patch with this issue.

> In the future when you include a "for-4.5" tag on a patch please
> *always* state your reasoning (usually after the "---"). Don't make the
> maintainer / release manager / committer guess why you think it should
> be in 4.5. If you consider it "obviously a bug fix" then say so and then
> say something about the impact of the bug and the risk associated with
> the fix.
> 
> I'm a bit grumpy about the number of patches which don't do this, such
> patches are mostly going to the back of my queue, alongside the 4.6
> patches, since without any rationale that is effectively what I consider
> them to be despite the use of the for-4.5 tag.



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 10:52:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 10: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 1Xlbiu-0006M5-Pt; Tue, 04 Nov 2014 10:52:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlbit-0006Lx-B8
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 10:52:27 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	A9/8C-17958-AEFA8545; Tue, 04 Nov 2014 10:52:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415098344!11448654!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15160 invoked from network); 4 Nov 2014 10:52:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 10:52:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189235749"
Message-ID: <1415098342.11486.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 4 Nov 2014 10:52:22 +0000
In-Reply-To: <1415098082.11486.19.camel@citrix.com>
References: <1414591781-19376-1-git-send-email-andrew.cooper3@citrix.com>
	<1415098082.11486.19.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Wei Liu <wei.liu2@citrix.com>, Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: [Xen-devel] Please *justify* your use of the for-4.5 tag when
	posting patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 10:48 +0000, Ian Campbell wrote:

Reposting with a more eyecatching subject, since this was by far not the
only patch with this issue.

> In the future when you include a "for-4.5" tag on a patch please
> *always* state your reasoning (usually after the "---"). Don't make the
> maintainer / release manager / committer guess why you think it should
> be in 4.5. If you consider it "obviously a bug fix" then say so and then
> say something about the impact of the bug and the risk associated with
> the fix.
> 
> I'm a bit grumpy about the number of patches which don't do this, such
> patches are mostly going to the back of my queue, alongside the 4.6
> patches, since without any rationale that is effectively what I consider
> them to be despite the use of the for-4.5 tag.



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:00:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:00:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlbqe-0006ta-LL; Tue, 04 Nov 2014 11:00:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xlbqc-0006tU-PG
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:00:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	07/01-09936-AC1B8545; Tue, 04 Nov 2014 11:00:26 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415098824!12649192!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12175 invoked from network); 4 Nov 2014 11:00:25 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:00:25 -0000
Received: by mail-qa0-f50.google.com with SMTP id bm13so7801783qab.23
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 03:00:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=gpRqL2QI1on244we1UchJkBmti62k9iWYzIy+NyT1jI=;
	b=SV2p2veCgvM7pRqj2Cs/ltYQWFcBLHhTfJqqPCZo6QNDIaYRae3iFKBYNiChCiY62x
	XyT/vhPED0OznivIsyn1sqTaZIDQF3xvSZhIjaRHRUJxXrumJYlRVeVELpYJ5LPG6ia6
	3cW1yPnMK2aUFPXMXxgH4e5wDmKtjab+u8qStL2EsL9Azedo2Vbd+avIgdT3hLrK4WII
	H/8sAq2Wg2isK7b+uIqagIUx2V065fyESDGv9Xy/gbeKHtnqWsiyA03mzBZY4z6uOYXK
	1Ok0kKIRO3hWMQFEfqeQc6M09FVriW2Qib7F8Diy3ZUf8fAhTbKsXrpYxtrF364p4R25
	EhLA==
MIME-Version: 1.0
X-Received: by 10.224.136.130 with SMTP id r2mr75512343qat.80.1415098824405;
	Tue, 04 Nov 2014 03:00:24 -0800 (PST)
Received: by 10.96.105.199 with HTTP; Tue, 4 Nov 2014 03:00:24 -0800 (PST)
In-Reply-To: <20141104104649.GA8479@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
	<CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
	<20141104104649.GA8479@aepfle.de>
Date: Tue, 4 Nov 2014 11:00:24 +0000
X-Google-Sender-Auth: 0nrAGLPDqeIkMu9MwIdFvF88RmI
Message-ID: <CAFLBxZbm5sXPKM7312rjRojdhr9e8W5qGKuGjjH25_zoG1g+rg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, Nov 04, George Dunlap wrote:
>
>> A number based on the time you happened to create the RPM, not based
>> on something intrinsic about the content of the RPM; that just seems
>> kind of hacky to me.  It happens to work well for your common
>> workflow, but you can certainly imagine other workflows or other
>> situations where you'd have to more manually override things anyway
>> (for instance, doing bisections, or comparing functionality in
>> different releases).  It seems like rather than having to remember
>> when you can skip the manual override bits, and when you can't, it
>> would be better to just use them all the time.
>
> George, the release number is and was never meant to describe the
> content of a package. It just means "its different". And it will even
> work for bisect because the package is always "newer", even if the
> content is different.

Not if you end up going to a previously built package for some reason.

I can see how this makes more sense if you do have an independent
package installed for every branch; but most people are not going to
do that.

Anyway, if I were a maintainer, I might decide to accept it, even
though I didn't like it, on the grounds that it doesn't do much harm
and somebody finds it useful.

Since I'm not a maintainer, I'm free to be opinionated. :-)

 -George

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:00:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:00:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlbqe-0006ta-LL; Tue, 04 Nov 2014 11:00:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xlbqc-0006tU-PG
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:00:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	07/01-09936-AC1B8545; Tue, 04 Nov 2014 11:00:26 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415098824!12649192!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12175 invoked from network); 4 Nov 2014 11:00:25 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:00:25 -0000
Received: by mail-qa0-f50.google.com with SMTP id bm13so7801783qab.23
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 03:00:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=gpRqL2QI1on244we1UchJkBmti62k9iWYzIy+NyT1jI=;
	b=SV2p2veCgvM7pRqj2Cs/ltYQWFcBLHhTfJqqPCZo6QNDIaYRae3iFKBYNiChCiY62x
	XyT/vhPED0OznivIsyn1sqTaZIDQF3xvSZhIjaRHRUJxXrumJYlRVeVELpYJ5LPG6ia6
	3cW1yPnMK2aUFPXMXxgH4e5wDmKtjab+u8qStL2EsL9Azedo2Vbd+avIgdT3hLrK4WII
	H/8sAq2Wg2isK7b+uIqagIUx2V065fyESDGv9Xy/gbeKHtnqWsiyA03mzBZY4z6uOYXK
	1Ok0kKIRO3hWMQFEfqeQc6M09FVriW2Qib7F8Diy3ZUf8fAhTbKsXrpYxtrF364p4R25
	EhLA==
MIME-Version: 1.0
X-Received: by 10.224.136.130 with SMTP id r2mr75512343qat.80.1415098824405;
	Tue, 04 Nov 2014 03:00:24 -0800 (PST)
Received: by 10.96.105.199 with HTTP; Tue, 4 Nov 2014 03:00:24 -0800 (PST)
In-Reply-To: <20141104104649.GA8479@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
	<CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
	<20141104104649.GA8479@aepfle.de>
Date: Tue, 4 Nov 2014 11:00:24 +0000
X-Google-Sender-Auth: 0nrAGLPDqeIkMu9MwIdFvF88RmI
Message-ID: <CAFLBxZbm5sXPKM7312rjRojdhr9e8W5qGKuGjjH25_zoG1g+rg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, Nov 04, George Dunlap wrote:
>
>> A number based on the time you happened to create the RPM, not based
>> on something intrinsic about the content of the RPM; that just seems
>> kind of hacky to me.  It happens to work well for your common
>> workflow, but you can certainly imagine other workflows or other
>> situations where you'd have to more manually override things anyway
>> (for instance, doing bisections, or comparing functionality in
>> different releases).  It seems like rather than having to remember
>> when you can skip the manual override bits, and when you can't, it
>> would be better to just use them all the time.
>
> George, the release number is and was never meant to describe the
> content of a package. It just means "its different". And it will even
> work for bisect because the package is always "newer", even if the
> content is different.

Not if you end up going to a previously built package for some reason.

I can see how this makes more sense if you do have an independent
package installed for every branch; but most people are not going to
do that.

Anyway, if I were a maintainer, I might decide to accept it, even
though I didn't like it, on the grounds that it doesn't do much harm
and somebody finds it useful.

Since I'm not a maintainer, I'm free to be opinionated. :-)

 -George

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:05:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11: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 1XlbvF-0007GP-Ij; Tue, 04 Nov 2014 11:05: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 1XlbvE-0007GJ-A3
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:05:12 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	4E/1F-22819-7E2B8545; Tue, 04 Nov 2014 11:05:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415099108!11072845!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9111 invoked from network); 4 Nov 2014 11:05:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:05:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189238444"
Message-ID: <1415099037.11486.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 4 Nov 2014 11:03:57 +0000
In-Reply-To: <CAFLBxZbm5sXPKM7312rjRojdhr9e8W5qGKuGjjH25_zoG1g+rg@mail.gmail.com>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
	<CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
	<20141104104649.GA8479@aepfle.de>
	<CAFLBxZbm5sXPKM7312rjRojdhr9e8W5qGKuGjjH25_zoG1g+rg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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, 2014-11-04 at 11:00 +0000, George Dunlap wrote:
> On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Tue, Nov 04, George Dunlap wrote:
> >
> >> A number based on the time you happened to create the RPM, not based
> >> on something intrinsic about the content of the RPM; that just seems
> >> kind of hacky to me.  It happens to work well for your common
> >> workflow, but you can certainly imagine other workflows or other
> >> situations where you'd have to more manually override things anyway
> >> (for instance, doing bisections, or comparing functionality in
> >> different releases).  It seems like rather than having to remember
> >> when you can skip the manual override bits, and when you can't, it
> >> would be better to just use them all the time.
> >
> > George, the release number is and was never meant to describe the
> > content of a package. It just means "its different". And it will even
> > work for bisect because the package is always "newer", even if the
> > content is different.
> 
> Not if you end up going to a previously built package for some reason.
> 
> I can see how this makes more sense if you do have an independent
> package installed for every branch; but most people are not going to
> do that.
> 
> Anyway, if I were a maintainer, I might decide to accept it, even
> though I didn't like it, on the grounds that it doesn't do much harm
> and somebody finds it useful.
> 
> Since I'm not a maintainer, I'm free to be opinionated. :-)

I don't think any of the formal maintainers of this code use RPM[0], and
you are the original author of the tool... So I'm afraid I think you
might have a more relevant opinion than you might like.

Ian.

[0] At least half happen to be Debian Maintainers...


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:05:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11: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 1XlbvF-0007GP-Ij; Tue, 04 Nov 2014 11:05: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 1XlbvE-0007GJ-A3
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:05:12 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	4E/1F-22819-7E2B8545; Tue, 04 Nov 2014 11:05:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415099108!11072845!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9111 invoked from network); 4 Nov 2014 11:05:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:05:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189238444"
Message-ID: <1415099037.11486.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 4 Nov 2014 11:03:57 +0000
In-Reply-To: <CAFLBxZbm5sXPKM7312rjRojdhr9e8W5qGKuGjjH25_zoG1g+rg@mail.gmail.com>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
	<CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
	<20141104104649.GA8479@aepfle.de>
	<CAFLBxZbm5sXPKM7312rjRojdhr9e8W5qGKuGjjH25_zoG1g+rg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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, 2014-11-04 at 11:00 +0000, George Dunlap wrote:
> On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Tue, Nov 04, George Dunlap wrote:
> >
> >> A number based on the time you happened to create the RPM, not based
> >> on something intrinsic about the content of the RPM; that just seems
> >> kind of hacky to me.  It happens to work well for your common
> >> workflow, but you can certainly imagine other workflows or other
> >> situations where you'd have to more manually override things anyway
> >> (for instance, doing bisections, or comparing functionality in
> >> different releases).  It seems like rather than having to remember
> >> when you can skip the manual override bits, and when you can't, it
> >> would be better to just use them all the time.
> >
> > George, the release number is and was never meant to describe the
> > content of a package. It just means "its different". And it will even
> > work for bisect because the package is always "newer", even if the
> > content is different.
> 
> Not if you end up going to a previously built package for some reason.
> 
> I can see how this makes more sense if you do have an independent
> package installed for every branch; but most people are not going to
> do that.
> 
> Anyway, if I were a maintainer, I might decide to accept it, even
> though I didn't like it, on the grounds that it doesn't do much harm
> and somebody finds it useful.
> 
> Since I'm not a maintainer, I'm free to be opinionated. :-)

I don't think any of the formal maintainers of this code use RPM[0], and
you are the original author of the tool... So I'm afraid I think you
might have a more relevant opinion than you might like.

Ian.

[0] At least half happen to be Debian Maintainers...


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:12:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:12:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlc1b-0007SY-GJ; Tue, 04 Nov 2014 11:11: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@citrix.com>) id 1Xlc1a-0007ST-BH
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:11:46 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	7B/42-07724-174B8545; Tue, 04 Nov 2014 11:11:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415099503!11524727!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9764 invoked from network); 4 Nov 2014 11:11:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:11:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187860018"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 06:11:32 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xlc1N-0002yA-0a;
	Tue, 04 Nov 2014 11:11:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xlc1M-0000PN-OZ;
	Tue, 04 Nov 2014 11:11:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21592.46180.258610.396411@mariner.uk.xensource.com>
Date: Tue, 4 Nov 2014 11:11:32 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415011253.9994.15.camel@citrix.com>
References: <1414754490-30355-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415011253.9994.15.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH] DhcpWatch::leases: Check 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

Ian Campbell writes ("Re: [OSSTEST PATCH] DhcpWatch::leases: Check errors"):
> On Fri, 2014-10-31 at 11:21 +0000, Ian Jackson wrote:
> > Check error returns from connect() et al (which present as an undef
> > return from IO::Socket::INET), and from read() (which can be detected
> > via IO::Handle::error).
> 
> Looks like you have a mixture of tabs and spaces in the second hunk, but
> otherwise:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

osstest is full of a mixture of tabs and spaces.  It's not the kind of
thing I think is worth caring about.

Ian.

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:12:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:12:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlc1b-0007SY-GJ; Tue, 04 Nov 2014 11:11: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@citrix.com>) id 1Xlc1a-0007ST-BH
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:11:46 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	7B/42-07724-174B8545; Tue, 04 Nov 2014 11:11:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415099503!11524727!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9764 invoked from network); 4 Nov 2014 11:11:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:11:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187860018"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 06:11:32 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xlc1N-0002yA-0a;
	Tue, 04 Nov 2014 11:11:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xlc1M-0000PN-OZ;
	Tue, 04 Nov 2014 11:11:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21592.46180.258610.396411@mariner.uk.xensource.com>
Date: Tue, 4 Nov 2014 11:11:32 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415011253.9994.15.camel@citrix.com>
References: <1414754490-30355-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415011253.9994.15.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH] DhcpWatch::leases: Check 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

Ian Campbell writes ("Re: [OSSTEST PATCH] DhcpWatch::leases: Check errors"):
> On Fri, 2014-10-31 at 11:21 +0000, Ian Jackson wrote:
> > Check error returns from connect() et al (which present as an undef
> > return from IO::Socket::INET), and from read() (which can be detected
> > via IO::Handle::error).
> 
> Looks like you have a mixture of tabs and spaces in the second hunk, but
> otherwise:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

osstest is full of a mixture of tabs and spaces.  It's not the kind of
thing I think is worth caring about.

Ian.

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:20:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlc9x-0007mW-OZ; Tue, 04 Nov 2014 11:20:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xlc9w-0007mR-1V
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:20:24 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D8/42-24532-776B8545; Tue, 04 Nov 2014 11:20:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415100022!12624404!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6742 invoked from network); 4 Nov 2014 11:20:22 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 11:20:22 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 11:20:22 +0000
Message-Id: <5458C4830200007800044BB8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 11:20:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5458BBF30200007800044B69@mail.emea.novell.com>
	<5458AEAE.9080804@citrix.com>
In-Reply-To: <5458AEAE.9080804@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	IanJackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: move hvmloader to x86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 11:47, <andrew.cooper3@citrix.com> wrote:
> On 04/11/14 10:43, Jan Beulich wrote:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -344,6 +344,7 @@ S:	Supported
>>  L:	xen-devel@lists.xen.org 
>>  F:	xen/arch/x86/
>>  F:	xen/include/asm-x86/
>> +F:	tools/firmware/hvmloader/
> 
> hvmloader as a binary is linked together with other bits in
> tools/firmware, which form part of the x86 HVM boot path.
> 
> As a result, I would recommend this path being "tools/firmware/" to
> include these other bits in being part of the x86 architecture code.

No, not really. SeaBIOS should remain in Ian's realm, and I think
e.g. the old ROM BIOS also is much better known by the tool stack
maintainers.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:20:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlc9x-0007mW-OZ; Tue, 04 Nov 2014 11:20:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xlc9w-0007mR-1V
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:20:24 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D8/42-24532-776B8545; Tue, 04 Nov 2014 11:20:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415100022!12624404!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6742 invoked from network); 4 Nov 2014 11:20:22 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 11:20:22 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 11:20:22 +0000
Message-Id: <5458C4830200007800044BB8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 11:20:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5458BBF30200007800044B69@mail.emea.novell.com>
	<5458AEAE.9080804@citrix.com>
In-Reply-To: <5458AEAE.9080804@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	IanJackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: move hvmloader to x86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 11:47, <andrew.cooper3@citrix.com> wrote:
> On 04/11/14 10:43, Jan Beulich wrote:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -344,6 +344,7 @@ S:	Supported
>>  L:	xen-devel@lists.xen.org 
>>  F:	xen/arch/x86/
>>  F:	xen/include/asm-x86/
>> +F:	tools/firmware/hvmloader/
> 
> hvmloader as a binary is linked together with other bits in
> tools/firmware, which form part of the x86 HVM boot path.
> 
> As a result, I would recommend this path being "tools/firmware/" to
> include these other bits in being part of the x86 architecture code.

No, not really. SeaBIOS should remain in Ian's realm, and I think
e.g. the old ROM BIOS also is much better known by the tool stack
maintainers.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:24:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcEH-00083z-G1; Tue, 04 Nov 2014 11:24:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlcEG-00083s-Qb
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:24:52 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	67/6A-26858-487B8545; Tue, 04 Nov 2014 11:24:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415100290!7077474!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25769 invoked from network); 4 Nov 2014 11:24:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:24:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187862212"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 06:24:49 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlcED-0003Dg-D0;
	Tue, 04 Nov 2014 11:24:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlcED-0000RU-32;
	Tue, 04 Nov 2014 11:24:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21592.46976.780608.557136@mariner.uk.xensource.com>
Date: Tue, 4 Nov 2014 11:24:48 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <5457A71802000078000447AA@mail.emea.novell.com>
References: <5457A3AD020000780004478B@mail.emea.novell.com>
	<5457A71802000078000447AA@mail.emea.novell.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] lzo: check for length overrun in
 variable length encoding
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("[PATCH 2/2] lzo: check for length overrun in variable length encoding"):
> This fix ensures that we never meet an integer overflow while adding
> 255 while parsing a variable length encoding. It works differently from
> commit 504f70b6 ("lzo: properly check for overruns") because instead of
> ensuring that we don't overrun the input, which is tricky to guarantee
> due to many assumptions in the code, it simply checks that the cumulated
> number of 255 read cannot overflow by bounding this number.

AFAICT this decompressor is exposed to untrusted guest kernel images.

Ian.

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:24:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcEH-00083z-G1; Tue, 04 Nov 2014 11:24:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlcEG-00083s-Qb
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:24:52 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	67/6A-26858-487B8545; Tue, 04 Nov 2014 11:24:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415100290!7077474!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25769 invoked from network); 4 Nov 2014 11:24:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:24:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187862212"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 06:24:49 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlcED-0003Dg-D0;
	Tue, 04 Nov 2014 11:24:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlcED-0000RU-32;
	Tue, 04 Nov 2014 11:24:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21592.46976.780608.557136@mariner.uk.xensource.com>
Date: Tue, 4 Nov 2014 11:24:48 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <5457A71802000078000447AA@mail.emea.novell.com>
References: <5457A3AD020000780004478B@mail.emea.novell.com>
	<5457A71802000078000447AA@mail.emea.novell.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] lzo: check for length overrun in
 variable length encoding
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("[PATCH 2/2] lzo: check for length overrun in variable length encoding"):
> This fix ensures that we never meet an integer overflow while adding
> 255 while parsing a variable length encoding. It works differently from
> commit 504f70b6 ("lzo: properly check for overruns") because instead of
> ensuring that we don't overrun the input, which is tricky to guarantee
> due to many assumptions in the code, it simply checks that the cumulated
> number of 255 read cannot overflow by bounding this number.

AFAICT this decompressor is exposed to untrusted guest kernel images.

Ian.

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:29:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:29:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcIt-0008Cc-9G; Tue, 04 Nov 2014 11:29:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlcIr-0008CX-Vc
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:29:38 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	02/8B-25714-1A8B8545; Tue, 04 Nov 2014 11:29:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415100575!5683252!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26303 invoked from network); 4 Nov 2014 11:29:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:29:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189242927"
Message-ID: <1415100553.11486.29.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 4 Nov 2014 11:29:13 +0000
In-Reply-To: <5458C4830200007800044BB8@mail.emea.novell.com>
References: <5458BBF30200007800044B69@mail.emea.novell.com>
	<5458AEAE.9080804@citrix.com>
	<5458C4830200007800044BB8@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, IanJackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: move hvmloader to x86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 11:20 +0000, Jan Beulich wrote:
> >>> On 04.11.14 at 11:47, <andrew.cooper3@citrix.com> wrote:
> > On 04/11/14 10:43, Jan Beulich wrote:
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -344,6 +344,7 @@ S:	Supported
> >>  L:	xen-devel@lists.xen.org 
> >>  F:	xen/arch/x86/
> >>  F:	xen/include/asm-x86/
> >> +F:	tools/firmware/hvmloader/
> > 
> > hvmloader as a binary is linked together with other bits in
> > tools/firmware, which form part of the x86 HVM boot path.
> > 
> > As a result, I would recommend this path being "tools/firmware/" to
> > include these other bits in being part of the x86 architecture code.
> 
> No, not really. SeaBIOS should remain in Ian's realm, 

Agreed (well, I'd welcome a co-maintainer, not that it's much effort to
sync every now and then).

> and I think
> e.g. the old ROM BIOS also is much better known by the tool stack
> maintainers.

Not me, that's for sure ;-)

I think things under tools/firmware should, where appropriate, have
their own independent entry overridding the tools/* default, rather than
introducing a new umbrella entry one level further down.

IOW I think this patch for tools/firmware/hvmloader is appropriate and
correct in its own right. If someone wants to propose different
maintainership for other bits of tools/firmware/* then the default then
that should be done as a separate exercise IMHO.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:29:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:29:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcIt-0008Cc-9G; Tue, 04 Nov 2014 11:29:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlcIr-0008CX-Vc
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:29:38 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	02/8B-25714-1A8B8545; Tue, 04 Nov 2014 11:29:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415100575!5683252!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26303 invoked from network); 4 Nov 2014 11:29:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:29:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189242927"
Message-ID: <1415100553.11486.29.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 4 Nov 2014 11:29:13 +0000
In-Reply-To: <5458C4830200007800044BB8@mail.emea.novell.com>
References: <5458BBF30200007800044B69@mail.emea.novell.com>
	<5458AEAE.9080804@citrix.com>
	<5458C4830200007800044BB8@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, IanJackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: move hvmloader to x86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 11:20 +0000, Jan Beulich wrote:
> >>> On 04.11.14 at 11:47, <andrew.cooper3@citrix.com> wrote:
> > On 04/11/14 10:43, Jan Beulich wrote:
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -344,6 +344,7 @@ S:	Supported
> >>  L:	xen-devel@lists.xen.org 
> >>  F:	xen/arch/x86/
> >>  F:	xen/include/asm-x86/
> >> +F:	tools/firmware/hvmloader/
> > 
> > hvmloader as a binary is linked together with other bits in
> > tools/firmware, which form part of the x86 HVM boot path.
> > 
> > As a result, I would recommend this path being "tools/firmware/" to
> > include these other bits in being part of the x86 architecture code.
> 
> No, not really. SeaBIOS should remain in Ian's realm, 

Agreed (well, I'd welcome a co-maintainer, not that it's much effort to
sync every now and then).

> and I think
> e.g. the old ROM BIOS also is much better known by the tool stack
> maintainers.

Not me, that's for sure ;-)

I think things under tools/firmware should, where appropriate, have
their own independent entry overridding the tools/* default, rather than
introducing a new umbrella entry one level further down.

IOW I think this patch for tools/firmware/hvmloader is appropriate and
correct in its own right. If someone wants to propose different
maintainership for other bits of tools/firmware/* then the default then
that should be done as a separate exercise IMHO.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:34:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:34:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcNT-0008PN-4Z; Tue, 04 Nov 2014 11:34:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@citrix.com>) id 1XlcNQ-0008PI-Rv
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:34:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4C/7B-09936-CB9B8545; Tue, 04 Nov 2014 11:34:20 +0000
X-Env-Sender: Dave.Scott@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415100859!12655522!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12543 invoked from network); 4 Nov 2014 11:34:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:34:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="26500654"
From: Dave Scott <Dave.Scott@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: a domain can be dying but not shutdown
Thread-Index: AQHP7f96HvSsKMmsF0iRB8T/jmYtApw8BeCAgAFIA4CAAAT2AIAS+jMAgAAMuoA=
Date: Tue, 4 Nov 2014 11:34:17 +0000
Message-ID: <548CAAED-A0E4-43A9-81A5-398D906DFF7F@citrix.com>
References: <1413985962-31909-1-git-send-email-dave.scott@citrix.com>
	<5447BA71.9030405@citrix.com> <1414057369.19198.28.camel@citrix.com>
	<5448D1C2.9050700@citrix.com> <1415098124.11486.21.camel@citrix.com>
In-Reply-To: <1415098124.11486.21.camel@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-ID: <F31F25CAF7DFD2469EE43CBF10DDD53A@citrix.com>
MIME-Version: 1.0
X-DLP: AMS1
Cc: Wei Liu <wei.liu2@citrix.com>, Euan Harris <euan.harris@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Rob Hoes <Rob.Hoes@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: a domain can be dying but not
 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 4 Nov 2014, at 10:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> On Thu, 2014-10-23 at 11:00 +0100, Andrew Cooper wrote:
> 
>>> Did you instead mean this from libxl_types.idl:
>>>    # Valid iff (shutdown||dying).
>>>    #
>>>    # Otherwise set to a value guaranteed not to clash with any valid
>>>    # LIBXL_SHUTDOWN_REASON_* constant.
>>>    ("shutdown_reason", libxl_shutdown_reason),
>>> ?
>> 
>> That is the primary comment I was on about.
> 
> This wasn't tagged for 4.5 but it is a bug fix and the commit log &
> associated commentary were pretty convincing, so Acked + Applied with
> the additional hunk below folded in.
> 
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index ca3f724..f7fc695 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -260,7 +260,7 @@ libxl_dominfo = Struct("dominfo",[
>     ("shutdown",    bool),
>     ("dying",       bool),
> 
> -    # Valid iff (shutdown||dying).
> +    # Valid iff ->shutdown is true.

Great, thanks for doing this (after I forgot!)

Cheers,
Dave

>     #
>     # Otherwise set to a value guaranteed not to clash with any valid
>     # LIBXL_SHUTDOWN_REASON_* constant.
> 
> 


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:34:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:34:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcNT-0008PN-4Z; Tue, 04 Nov 2014 11:34:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@citrix.com>) id 1XlcNQ-0008PI-Rv
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:34:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4C/7B-09936-CB9B8545; Tue, 04 Nov 2014 11:34:20 +0000
X-Env-Sender: Dave.Scott@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415100859!12655522!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12543 invoked from network); 4 Nov 2014 11:34:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:34:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="26500654"
From: Dave Scott <Dave.Scott@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: a domain can be dying but not shutdown
Thread-Index: AQHP7f96HvSsKMmsF0iRB8T/jmYtApw8BeCAgAFIA4CAAAT2AIAS+jMAgAAMuoA=
Date: Tue, 4 Nov 2014 11:34:17 +0000
Message-ID: <548CAAED-A0E4-43A9-81A5-398D906DFF7F@citrix.com>
References: <1413985962-31909-1-git-send-email-dave.scott@citrix.com>
	<5447BA71.9030405@citrix.com> <1414057369.19198.28.camel@citrix.com>
	<5448D1C2.9050700@citrix.com> <1415098124.11486.21.camel@citrix.com>
In-Reply-To: <1415098124.11486.21.camel@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-ID: <F31F25CAF7DFD2469EE43CBF10DDD53A@citrix.com>
MIME-Version: 1.0
X-DLP: AMS1
Cc: Wei Liu <wei.liu2@citrix.com>, Euan Harris <euan.harris@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Rob Hoes <Rob.Hoes@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: a domain can be dying but not
 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 4 Nov 2014, at 10:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> On Thu, 2014-10-23 at 11:00 +0100, Andrew Cooper wrote:
> 
>>> Did you instead mean this from libxl_types.idl:
>>>    # Valid iff (shutdown||dying).
>>>    #
>>>    # Otherwise set to a value guaranteed not to clash with any valid
>>>    # LIBXL_SHUTDOWN_REASON_* constant.
>>>    ("shutdown_reason", libxl_shutdown_reason),
>>> ?
>> 
>> That is the primary comment I was on about.
> 
> This wasn't tagged for 4.5 but it is a bug fix and the commit log &
> associated commentary were pretty convincing, so Acked + Applied with
> the additional hunk below folded in.
> 
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index ca3f724..f7fc695 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -260,7 +260,7 @@ libxl_dominfo = Struct("dominfo",[
>     ("shutdown",    bool),
>     ("dying",       bool),
> 
> -    # Valid iff (shutdown||dying).
> +    # Valid iff ->shutdown is true.

Great, thanks for doing this (after I forgot!)

Cheers,
Dave

>     #
>     # Otherwise set to a value guaranteed not to clash with any valid
>     # LIBXL_SHUTDOWN_REASON_* constant.
> 
> 


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:35:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11: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 1XlcOO-0008WU-IX; Tue, 04 Nov 2014 11:35:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlcON-0008WL-4F
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:35:19 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	9D/8B-27584-6F9B8545; Tue, 04 Nov 2014 11:35:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415100915!11085467!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27406 invoked from network); 4 Nov 2014 11:35:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:35:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189243880"
Message-ID: <1415100913.11486.31.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 4 Nov 2014 11:35:13 +0000
In-Reply-To: <21592.46976.780608.557136@mariner.uk.xensource.com>
References: <5457A3AD020000780004478B@mail.emea.novell.com>
	<5457A71802000078000447AA@mail.emea.novell.com>
	<21592.46976.780608.557136@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] lzo: check for length overrun in
 variable length encoding
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 11:24 +0000, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH 2/2] lzo: check for length overrun in variable length encoding"):
> > This fix ensures that we never meet an integer overflow while adding
> > 255 while parsing a variable length encoding. It works differently from
> > commit 504f70b6 ("lzo: properly check for overruns") because instead of
> > ensuring that we don't overrun the input, which is tricky to guarantee
> > due to many assumptions in the code, it simply checks that the cumulated
> > number of 255 read cannot overflow by bounding this number.
> 
> AFAICT this decompressor is exposed to untrusted guest kernel images.

Only in mini-os context, I think. AIUI dom0 hosted libxc uses liblzo2.

Not 100% sure of that, but tools/libxc/Makefile's handling of
xc_dom_decompress_unsafe_lzo1x seems to confirm what I thought.

Aside from that, I presume you are trying to say that the description of
the fix suggests the code would be vulnerable to untrusted input? It
looks to me as if it is infact OK for untrusted input, but perhaps I've
misunderstood what it is doing.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:35:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11: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 1XlcOO-0008WU-IX; Tue, 04 Nov 2014 11:35:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlcON-0008WL-4F
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:35:19 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	9D/8B-27584-6F9B8545; Tue, 04 Nov 2014 11:35:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415100915!11085467!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27406 invoked from network); 4 Nov 2014 11:35:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:35:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189243880"
Message-ID: <1415100913.11486.31.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 4 Nov 2014 11:35:13 +0000
In-Reply-To: <21592.46976.780608.557136@mariner.uk.xensource.com>
References: <5457A3AD020000780004478B@mail.emea.novell.com>
	<5457A71802000078000447AA@mail.emea.novell.com>
	<21592.46976.780608.557136@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] lzo: check for length overrun in
 variable length encoding
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 11:24 +0000, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH 2/2] lzo: check for length overrun in variable length encoding"):
> > This fix ensures that we never meet an integer overflow while adding
> > 255 while parsing a variable length encoding. It works differently from
> > commit 504f70b6 ("lzo: properly check for overruns") because instead of
> > ensuring that we don't overrun the input, which is tricky to guarantee
> > due to many assumptions in the code, it simply checks that the cumulated
> > number of 255 read cannot overflow by bounding this number.
> 
> AFAICT this decompressor is exposed to untrusted guest kernel images.

Only in mini-os context, I think. AIUI dom0 hosted libxc uses liblzo2.

Not 100% sure of that, but tools/libxc/Makefile's handling of
xc_dom_decompress_unsafe_lzo1x seems to confirm what I thought.

Aside from that, I presume you are trying to say that the description of
the fix suggests the code would be vulnerable to untrusted input? It
looks to me as if it is infact OK for untrusted input, but perhaps I've
misunderstood what it is doing.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:36:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:36:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcPM-0000DX-4m; Tue, 04 Nov 2014 11:36:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlcPK-0000DN-Ge
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:36:18 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	AF/10-03148-13AB8545; Tue, 04 Nov 2014 11:36:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415100976!12438615!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11884 invoked from network); 4 Nov 2014 11:36:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:36:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187863908"
Message-ID: <1415100945.11486.32.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Scott <Dave.Scott@citrix.com>
Date: Tue, 4 Nov 2014 11:35:45 +0000
In-Reply-To: <548CAAED-A0E4-43A9-81A5-398D906DFF7F@citrix.com>
References: <1413985962-31909-1-git-send-email-dave.scott@citrix.com>
	<5447BA71.9030405@citrix.com> <1414057369.19198.28.camel@citrix.com>
	<5448D1C2.9050700@citrix.com> <1415098124.11486.21.camel@citrix.com>
	<548CAAED-A0E4-43A9-81A5-398D906DFF7F@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Euan Harris <euan.harris@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Rob Hoes <Rob.Hoes@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: a domain can be dying but not
 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 Tue, 2014-11-04 at 11:34 +0000, Dave Scott wrote:
> > On 4 Nov 2014, at 10:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > On Thu, 2014-10-23 at 11:00 +0100, Andrew Cooper wrote:
> > 
> >>> Did you instead mean this from libxl_types.idl:
> >>>    # Valid iff (shutdown||dying).
> >>>    #
> >>>    # Otherwise set to a value guaranteed not to clash with any valid
> >>>    # LIBXL_SHUTDOWN_REASON_* constant.
> >>>    ("shutdown_reason", libxl_shutdown_reason),
> >>> ?
> >> 
> >> That is the primary comment I was on about.
> > 
> > This wasn't tagged for 4.5 but it is a bug fix and the commit log &
> > associated commentary were pretty convincing, so Acked + Applied with
> > the additional hunk below folded in.
> > 
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index ca3f724..f7fc695 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -260,7 +260,7 @@ libxl_dominfo = Struct("dominfo",[
> >     ("shutdown",    bool),
> >     ("dying",       bool),
> > 
> > -    # Valid iff (shutdown||dying).
> > +    # Valid iff ->shutdown is true.
> 
> Great, thanks for doing this (after I forgot!)

It was easier than pinging ;-)



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:36:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:36:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcPM-0000DX-4m; Tue, 04 Nov 2014 11:36:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlcPK-0000DN-Ge
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:36:18 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	AF/10-03148-13AB8545; Tue, 04 Nov 2014 11:36:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415100976!12438615!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11884 invoked from network); 4 Nov 2014 11:36:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:36:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187863908"
Message-ID: <1415100945.11486.32.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Scott <Dave.Scott@citrix.com>
Date: Tue, 4 Nov 2014 11:35:45 +0000
In-Reply-To: <548CAAED-A0E4-43A9-81A5-398D906DFF7F@citrix.com>
References: <1413985962-31909-1-git-send-email-dave.scott@citrix.com>
	<5447BA71.9030405@citrix.com> <1414057369.19198.28.camel@citrix.com>
	<5448D1C2.9050700@citrix.com> <1415098124.11486.21.camel@citrix.com>
	<548CAAED-A0E4-43A9-81A5-398D906DFF7F@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Euan Harris <euan.harris@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Rob Hoes <Rob.Hoes@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: a domain can be dying but not
 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 Tue, 2014-11-04 at 11:34 +0000, Dave Scott wrote:
> > On 4 Nov 2014, at 10:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > On Thu, 2014-10-23 at 11:00 +0100, Andrew Cooper wrote:
> > 
> >>> Did you instead mean this from libxl_types.idl:
> >>>    # Valid iff (shutdown||dying).
> >>>    #
> >>>    # Otherwise set to a value guaranteed not to clash with any valid
> >>>    # LIBXL_SHUTDOWN_REASON_* constant.
> >>>    ("shutdown_reason", libxl_shutdown_reason),
> >>> ?
> >> 
> >> That is the primary comment I was on about.
> > 
> > This wasn't tagged for 4.5 but it is a bug fix and the commit log &
> > associated commentary were pretty convincing, so Acked + Applied with
> > the additional hunk below folded in.
> > 
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index ca3f724..f7fc695 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -260,7 +260,7 @@ libxl_dominfo = Struct("dominfo",[
> >     ("shutdown",    bool),
> >     ("dying",       bool),
> > 
> > -    # Valid iff (shutdown||dying).
> > +    # Valid iff ->shutdown is true.
> 
> Great, thanks for doing this (after I forgot!)

It was easier than pinging ;-)



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:38:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcRV-0000Pc-MO; Tue, 04 Nov 2014 11:38:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <grygorii.strashko@ti.com>) id 1XlcP8-0000C7-6h
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 11:36:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E5/FE-09936-52AB8545; Tue, 04 Nov 2014 11:36:05 +0000
X-Env-Sender: grygorii.strashko@ti.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415100963!12623423!1
X-Originating-IP: [198.47.26.153]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10768 invoked from network); 4 Nov 2014 11:36:04 -0000
Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 11:36:04 -0000
Received: from dflxv15.itg.ti.com ([128.247.5.124])
	by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id sA4BZSFc006658;
	Tue, 4 Nov 2014 05:35:29 -0600
Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113])
	by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id sA4BZS0F019172;
	Tue, 4 Nov 2014 05:35:28 -0600
Received: from dlep33.itg.ti.com (157.170.170.75) by DLEE70.ent.ti.com
	(157.170.170.113) with Microsoft SMTP Server id 14.3.174.1;
	Tue, 4 Nov 2014 05:35:28 -0600
Received: from [192.168.192.233] (ileax41-snat.itg.ti.com [10.172.224.153])	by
	dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id sA4BZQBp013732;
	Tue, 4 Nov 2014 05:35:26 -0600
Message-ID: <5458B9FC.3050309@ti.com>
Date: Tue, 4 Nov 2014 13:35:24 +0200
From: Grygorii Strashko <grygorii.strashko@ti.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Will Deacon
	<will.deacon@arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
X-Mailman-Approved-At: Tue, 04 Nov 2014 11:38:31 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On 11/03/2014 01:10 PM, Stefano Stabellini wrote:
> On Mon, 3 Nov 2014, Will Deacon wrote:
>> On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
>>> On Mon, 27 Oct 2014, Stefano Stabellini wrote:
>>>> Introduce a boolean flag and an accessor function to check whether a
>>>> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
>>>>
>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>>>> CC: will.deacon@arm.com
>>>
>>> Will, Catalin,
>>> are you OK with this patch?
>>
>> It would be nicer if the dma_coherent flag didn't have to be duplicated by
>> each architecture in dev_archdata. Is there any reason not to put it in the
>> core code?
> 
> Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> struct device as Catalin initially suggested, what would be the default
> for each architecture? Where would I set it for arch that don't use
> device tree? It is not easy.
> 
> I thought it would be better to introduce is_device_dma_coherent only on
> the architectures where it certainly makes sense to have it. In fact I
> checked and arm and arm64 are the only architectures to define
> set_arch_dma_coherent_ops at the moment. At that point if
> is_device_dma_coherent becomes arch-specific, it makes sense to store
> the flag in dev_archdata instead of struct device.

The proposition from Will looks reasonable for me too, because
there is "small" side-effect of adding such kind of properties to
arch-specific data or even to the core device structure. ;(

There are some sub-systems in kernel which do not create their devices
from DT and instead some host device populates its children devices manually.
 Now, I know at least two cases:
- usb: dwc3 core creates xhci device manually
- pci: adds its client devices

In such, case DMA configuration have to be propagated from host to
child (in our case host device's got DMA configuration from DT), like:
	dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask);

	xhci->dev.parent	= dwc->dev;
	xhci->dev.dma_mask	= dwc->dev->dma_mask;
	xhci->dev.dma_parms	= dwc->dev->dma_parms;

So, once new DMA property is added it has to be propagated from 
host to child device too.

Recently, the new property  dma_pfn_offset was introduced in struct device 
and such kind of problem was observed on keystone 2:
- for usb case it was fixed using Platform Bus notifier (xhci - platform device)
- for pci - the work is in progress, because solution with PCI Bus notifier
  was rejected https://lkml.org/lkml/2014/10/10/308.

In general, if dma_coherent will belong to struct device then
such problems will be possible to fix directly in drivers/subsystems:
xhci->dev.dma_coherent	= dwc->dev->dma_coherent;

But, if it will be arch-specific data then it will be impossible to
set it without introducing proper and arch-specific setters/getters functions.

Also, as an idea, we are thinking about introducing something like:
  void dma_apply_parent_cfg(struct device *dev, struct device *parent)
which will ensure that all DMA configuration properly copied from
parent to children device. Now it should be (as minimum for ARM):
 dma_mask
 coherent_dma_mask
 dma_parms
 dma_pfn_offset
 dev_archdata->dma_ops
 [dma_coherent]?

regards,
-grygorii 


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:38:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcRV-0000Pc-MO; Tue, 04 Nov 2014 11:38:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <grygorii.strashko@ti.com>) id 1XlcP8-0000C7-6h
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 11:36:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E5/FE-09936-52AB8545; Tue, 04 Nov 2014 11:36:05 +0000
X-Env-Sender: grygorii.strashko@ti.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415100963!12623423!1
X-Originating-IP: [198.47.26.153]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10768 invoked from network); 4 Nov 2014 11:36:04 -0000
Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 11:36:04 -0000
Received: from dflxv15.itg.ti.com ([128.247.5.124])
	by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id sA4BZSFc006658;
	Tue, 4 Nov 2014 05:35:29 -0600
Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113])
	by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id sA4BZS0F019172;
	Tue, 4 Nov 2014 05:35:28 -0600
Received: from dlep33.itg.ti.com (157.170.170.75) by DLEE70.ent.ti.com
	(157.170.170.113) with Microsoft SMTP Server id 14.3.174.1;
	Tue, 4 Nov 2014 05:35:28 -0600
Received: from [192.168.192.233] (ileax41-snat.itg.ti.com [10.172.224.153])	by
	dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id sA4BZQBp013732;
	Tue, 4 Nov 2014 05:35:26 -0600
Message-ID: <5458B9FC.3050309@ti.com>
Date: Tue, 4 Nov 2014 13:35:24 +0200
From: Grygorii Strashko <grygorii.strashko@ti.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Will Deacon
	<will.deacon@arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
X-Mailman-Approved-At: Tue, 04 Nov 2014 11:38:31 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On 11/03/2014 01:10 PM, Stefano Stabellini wrote:
> On Mon, 3 Nov 2014, Will Deacon wrote:
>> On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
>>> On Mon, 27 Oct 2014, Stefano Stabellini wrote:
>>>> Introduce a boolean flag and an accessor function to check whether a
>>>> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
>>>>
>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>>>> CC: will.deacon@arm.com
>>>
>>> Will, Catalin,
>>> are you OK with this patch?
>>
>> It would be nicer if the dma_coherent flag didn't have to be duplicated by
>> each architecture in dev_archdata. Is there any reason not to put it in the
>> core code?
> 
> Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> struct device as Catalin initially suggested, what would be the default
> for each architecture? Where would I set it for arch that don't use
> device tree? It is not easy.
> 
> I thought it would be better to introduce is_device_dma_coherent only on
> the architectures where it certainly makes sense to have it. In fact I
> checked and arm and arm64 are the only architectures to define
> set_arch_dma_coherent_ops at the moment. At that point if
> is_device_dma_coherent becomes arch-specific, it makes sense to store
> the flag in dev_archdata instead of struct device.

The proposition from Will looks reasonable for me too, because
there is "small" side-effect of adding such kind of properties to
arch-specific data or even to the core device structure. ;(

There are some sub-systems in kernel which do not create their devices
from DT and instead some host device populates its children devices manually.
 Now, I know at least two cases:
- usb: dwc3 core creates xhci device manually
- pci: adds its client devices

In such, case DMA configuration have to be propagated from host to
child (in our case host device's got DMA configuration from DT), like:
	dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask);

	xhci->dev.parent	= dwc->dev;
	xhci->dev.dma_mask	= dwc->dev->dma_mask;
	xhci->dev.dma_parms	= dwc->dev->dma_parms;

So, once new DMA property is added it has to be propagated from 
host to child device too.

Recently, the new property  dma_pfn_offset was introduced in struct device 
and such kind of problem was observed on keystone 2:
- for usb case it was fixed using Platform Bus notifier (xhci - platform device)
- for pci - the work is in progress, because solution with PCI Bus notifier
  was rejected https://lkml.org/lkml/2014/10/10/308.

In general, if dma_coherent will belong to struct device then
such problems will be possible to fix directly in drivers/subsystems:
xhci->dev.dma_coherent	= dwc->dev->dma_coherent;

But, if it will be arch-specific data then it will be impossible to
set it without introducing proper and arch-specific setters/getters functions.

Also, as an idea, we are thinking about introducing something like:
  void dma_apply_parent_cfg(struct device *dev, struct device *parent)
which will ensure that all DMA configuration properly copied from
parent to children device. Now it should be (as minimum for ARM):
 dma_mask
 coherent_dma_mask
 dma_parms
 dma_pfn_offset
 dev_archdata->dma_ops
 [dma_coherent]?

regards,
-grygorii 


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:41:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcUb-0000bZ-I3; Tue, 04 Nov 2014 11:41:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlcUa-0000bI-NO
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:41:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/DA-09936-87BB8545; Tue, 04 Nov 2014 11:41:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415101303!4621244!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16601 invoked from network); 4 Nov 2014 11:41:43 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 11:41:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 11:41:43 +0000
Message-Id: <5458C9850200007800044BF4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 11:41:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
	<54577AD302000078000445EB@mail.emea.novell.com>
	<54582D59.4020201@intel.com>
	<545896080200007800044A67@mail.emea.novell.com>
	<5458AD63.4020301@intel.com>
In-Reply-To: <5458AD63.4020301@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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 04.11.14 at 11:41, <tiejun.chen@intel.com> wrote:
> On 2014/11/4 16:02, Jan Beulich wrote:
>>>>> On 04.11.14 at 02:35, <tiejun.chen@intel.com> wrote:
>>> @@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>>        /* Now, actually do the two-way mapping */
>>>        if ( mfn_valid(_mfn(mfn)) )
>>>        {
>>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>>> -                           p2m->default_access);
>>> +        rc = 0;
>>> +        a =  p2m->default_access;
>>> +        if ( !is_hardware_domain(d) )
>>> +        {
>>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>>> +                                                  &gfn);
>>> +            /* We always avoid populating reserved device memory. */
>>> +            if ( rc == 1 )
>>> +                goto out;
>>
>> But you'll need to make sure that you don't return 1 to the callers:
> 
> You're right.
> 
>> They expect 0 or negative error codes. But with the model of
>> not even populating these regions (or relocating the memory
>> before [at boot time] assigning a device associated with an RMRR)
>> I think this needs to become an error anyway.
> 
> Looks -EINVAL might be used.

Hmm, -EINVAL is being used way too frequently already. -EBUSY
would make it at least a little bit more distinct.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:41:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcUb-0000bZ-I3; Tue, 04 Nov 2014 11:41:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XlcUa-0000bI-NO
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:41:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/DA-09936-87BB8545; Tue, 04 Nov 2014 11:41:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415101303!4621244!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16601 invoked from network); 4 Nov 2014 11:41:43 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 11:41:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 11:41:43 +0000
Message-Id: <5458C9850200007800044BF4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 11:41:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
	<54577AD302000078000445EB@mail.emea.novell.com>
	<54582D59.4020201@intel.com>
	<545896080200007800044A67@mail.emea.novell.com>
	<5458AD63.4020301@intel.com>
In-Reply-To: <5458AD63.4020301@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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 04.11.14 at 11:41, <tiejun.chen@intel.com> wrote:
> On 2014/11/4 16:02, Jan Beulich wrote:
>>>>> On 04.11.14 at 02:35, <tiejun.chen@intel.com> wrote:
>>> @@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>>        /* Now, actually do the two-way mapping */
>>>        if ( mfn_valid(_mfn(mfn)) )
>>>        {
>>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>>> -                           p2m->default_access);
>>> +        rc = 0;
>>> +        a =  p2m->default_access;
>>> +        if ( !is_hardware_domain(d) )
>>> +        {
>>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>>> +                                                  &gfn);
>>> +            /* We always avoid populating reserved device memory. */
>>> +            if ( rc == 1 )
>>> +                goto out;
>>
>> But you'll need to make sure that you don't return 1 to the callers:
> 
> You're right.
> 
>> They expect 0 or negative error codes. But with the model of
>> not even populating these regions (or relocating the memory
>> before [at boot time] assigning a device associated with an RMRR)
>> I think this needs to become an error anyway.
> 
> Looks -EINVAL might be used.

Hmm, -EINVAL is being used way too frequently already. -EBUSY
would make it at least a little bit more distinct.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:44:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:44:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcXY-0000st-5V; Tue, 04 Nov 2014 11:44:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XlcXW-0000sg-94
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:44:46 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	79/F9-24859-D2CB8545; Tue, 04 Nov 2014 11:44:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415101483!11486253!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6414 invoked from network); 4 Nov 2014 11:44:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:44:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189245689"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 06:44:42 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XlcXS-0003X8-Ov; Tue, 04 Nov 2014 11:44:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Tue, 4 Nov 2014 11:44:41 +0000
Message-ID: <1415101481-23913-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH for-4.5] xen: Bump several interface versions in
	preparation for Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
structures associated with xen_hvm_{get,set}_mem_access from the Xen public
API.

While these were toolstack hypercalls and documented as liable to change in
the future, it causes build issues for certain tools (valgrind, strace).

As HVM ops have no specific interface version, the main Xen interface version
needs to be bumped to compensate.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---
This is a bugfix with regards to API versioning.  There is no risk whatsoever
from taking it, but there is an outstanding API breakage which it fixes.
---
 xen/include/public/xen-compat.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
index 3eb80a0..c1d660d 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040400
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040500
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:44:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:44:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcXY-0000st-5V; Tue, 04 Nov 2014 11:44:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XlcXW-0000sg-94
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:44:46 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	79/F9-24859-D2CB8545; Tue, 04 Nov 2014 11:44:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415101483!11486253!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6414 invoked from network); 4 Nov 2014 11:44:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:44:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="189245689"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 06:44:42 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XlcXS-0003X8-Ov; Tue, 04 Nov 2014 11:44:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Tue, 4 Nov 2014 11:44:41 +0000
Message-ID: <1415101481-23913-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH for-4.5] xen: Bump several interface versions in
	preparation for Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
structures associated with xen_hvm_{get,set}_mem_access from the Xen public
API.

While these were toolstack hypercalls and documented as liable to change in
the future, it causes build issues for certain tools (valgrind, strace).

As HVM ops have no specific interface version, the main Xen interface version
needs to be bumped to compensate.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---
This is a bugfix with regards to API versioning.  There is no risk whatsoever
from taking it, but there is an outstanding API breakage which it fixes.
---
 xen/include/public/xen-compat.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
index 3eb80a0..c1d660d 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040400
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040500
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:47:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:47:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcZb-000106-N5; Tue, 04 Nov 2014 11:46:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XlcZa-000100-C4
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:46:54 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	E5/E9-02699-DACB8545; Tue, 04 Nov 2014 11:46:53 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415101611!12454859!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9084 invoked from network); 4 Nov 2014 11:46:52 -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;
	4 Nov 2014 11:46:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187865678"
Message-ID: <5458BCA9.3000304@citrix.com>
Date: Tue, 4 Nov 2014 11:46:49 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Xen-devel <xen-devel@lists.xen.org>
References: <1415101481-23913-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1415101481-23913-1-git-send-email-andrew.cooper3@citrix.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: Bump several interface
 versions in preparation for Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/14 11:44, Andrew Cooper wrote:

Apologies - the subject is wrong, but content is correct. (I think,
having now checked the other interface versions).

> c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> API.
>
> While these were toolstack hypercalls and documented as liable to change in
> the future, it causes build issues for certain tools (valgrind, strace).
>
> As HVM ops have no specific interface version, the main Xen interface version
> needs to be bumped to compensate.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Tim Deegan <tim@xen.org>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> ---
> This is a bugfix with regards to API versioning.  There is no risk whatsoever
> from taking it, but there is an outstanding API breakage which it fixes.
> ---
>  xen/include/public/xen-compat.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
> index 3eb80a0..c1d660d 100644
> --- a/xen/include/public/xen-compat.h
> +++ b/xen/include/public/xen-compat.h
> @@ -27,7 +27,7 @@
>  #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
>  #define __XEN_PUBLIC_XEN_COMPAT_H__
>  
> -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040400
> +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040500
>  
>  #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 Tue Nov 04 11:47:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:47:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcZb-000106-N5; Tue, 04 Nov 2014 11:46:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XlcZa-000100-C4
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:46:54 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	E5/E9-02699-DACB8545; Tue, 04 Nov 2014 11:46:53 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415101611!12454859!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9084 invoked from network); 4 Nov 2014 11:46:52 -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;
	4 Nov 2014 11:46:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187865678"
Message-ID: <5458BCA9.3000304@citrix.com>
Date: Tue, 4 Nov 2014 11:46:49 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Xen-devel <xen-devel@lists.xen.org>
References: <1415101481-23913-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1415101481-23913-1-git-send-email-andrew.cooper3@citrix.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: Bump several interface
 versions in preparation for Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/14 11:44, Andrew Cooper wrote:

Apologies - the subject is wrong, but content is correct. (I think,
having now checked the other interface versions).

> c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> API.
>
> While these were toolstack hypercalls and documented as liable to change in
> the future, it causes build issues for certain tools (valgrind, strace).
>
> As HVM ops have no specific interface version, the main Xen interface version
> needs to be bumped to compensate.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Tim Deegan <tim@xen.org>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> ---
> This is a bugfix with regards to API versioning.  There is no risk whatsoever
> from taking it, but there is an outstanding API breakage which it fixes.
> ---
>  xen/include/public/xen-compat.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
> index 3eb80a0..c1d660d 100644
> --- a/xen/include/public/xen-compat.h
> +++ b/xen/include/public/xen-compat.h
> @@ -27,7 +27,7 @@
>  #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
>  #define __XEN_PUBLIC_XEN_COMPAT_H__
>  
> -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040400
> +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040500
>  
>  #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 Tue Nov 04 11:50:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:50:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlcci-00019d-Bg; Tue, 04 Nov 2014 11:50:08 +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 1Xlccg-00019O-PO
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:50:06 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	D3/8F-01660-D6DB8545; Tue, 04 Nov 2014 11:50:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415101803!11114335!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20442 invoked from network); 4 Nov 2014 11:50:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:50:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187866172"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 06:50:03 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1Xlccc-0003d5-Ro; Tue, 04 Nov 2014 11:50:02 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Tue, 4 Nov 2014 11:50:02 +0000
Message-ID: <1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <5458BCA9.3000304@citrix.com>
References: <5458BCA9.3000304@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH v2 for-4.5] xen: Bump Xen interface for Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
structures associated with xen_hvm_{get,set}_mem_access from the Xen public
API.

While these were toolstack hypercalls and documented as liable to change in
the future, it causes build issues for certain tools (valgrind, strace).

As HVM ops have no specific interface version, the main Xen interface version
needs to be bumped to compensate.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---
This is a bugfix with regards to API versioning.  There is no risk whatsoever
from taking it, but there is an outstanding API breakage which it fixes.

v2:
 * Correct patch subject
---
 xen/include/public/xen-compat.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
index 3eb80a0..c1d660d 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040400
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040500
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:50:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:50:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlcci-00019d-Bg; Tue, 04 Nov 2014 11:50:08 +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 1Xlccg-00019O-PO
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:50:06 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	D3/8F-01660-D6DB8545; Tue, 04 Nov 2014 11:50:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415101803!11114335!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20442 invoked from network); 4 Nov 2014 11:50:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:50:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,312,1413244800"; d="scan'208";a="187866172"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 06:50:03 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1Xlccc-0003d5-Ro; Tue, 04 Nov 2014 11:50:02 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Tue, 4 Nov 2014 11:50:02 +0000
Message-ID: <1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <5458BCA9.3000304@citrix.com>
References: <5458BCA9.3000304@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH v2 for-4.5] xen: Bump Xen interface for Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
structures associated with xen_hvm_{get,set}_mem_access from the Xen public
API.

While these were toolstack hypercalls and documented as liable to change in
the future, it causes build issues for certain tools (valgrind, strace).

As HVM ops have no specific interface version, the main Xen interface version
needs to be bumped to compensate.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---
This is a bugfix with regards to API versioning.  There is no risk whatsoever
from taking it, but there is an outstanding API breakage which it fixes.

v2:
 * Correct patch subject
---
 xen/include/public/xen-compat.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
index 3eb80a0..c1d660d 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040400
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040500
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:51:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlceS-0001JL-SV; Tue, 04 Nov 2014 11:51:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlceR-0001JA-9r
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:51:55 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	09/45-14214-ADDB8545; Tue, 04 Nov 2014 11:51:54 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415101913!11114869!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26756 invoked from network); 4 Nov 2014 11:51:53 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-206.messagelabs.com with SMTP;
	4 Nov 2014 11:51:53 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 04 Nov 2014 03:51:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,313,1413270000"; d="scan'208";a="626192722"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.157])
	([10.238.128.157])
	by fmsmga002.fm.intel.com with ESMTP; 04 Nov 2014 03:51:50 -0800
Message-ID: <5458BDD5.8070800@intel.com>
Date: Tue, 04 Nov 2014 19:51:49 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
	<54577AD302000078000445EB@mail.emea.novell.com>
	<54582D59.4020201@intel.com>
	<545896080200007800044A67@mail.emea.novell.com>
	<5458AD63.4020301@intel.com>
	<5458C9850200007800044BF4@mail.emea.novell.com>
In-Reply-To: <5458C9850200007800044BF4@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/4 19:41, Jan Beulich wrote:
>>>> On 04.11.14 at 11:41, <tiejun.chen@intel.com> wrote:
>> On 2014/11/4 16:02, Jan Beulich wrote:
>>>>>> On 04.11.14 at 02:35, <tiejun.chen@intel.com> wrote:
>>>> @@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>>>         /* Now, actually do the two-way mapping */
>>>>         if ( mfn_valid(_mfn(mfn)) )
>>>>         {
>>>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>>>> -                           p2m->default_access);
>>>> +        rc = 0;
>>>> +        a =  p2m->default_access;
>>>> +        if ( !is_hardware_domain(d) )
>>>> +        {
>>>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>>>> +                                                  &gfn);
>>>> +            /* We always avoid populating reserved device memory. */
>>>> +            if ( rc == 1 )
>>>> +                goto out;
>>>
>>> But you'll need to make sure that you don't return 1 to the callers:
>>
>> You're right.
>>
>>> They expect 0 or negative error codes. But with the model of
>>> not even populating these regions (or relocating the memory
>>> before [at boot time] assigning a device associated with an RMRR)
>>> I think this needs to become an error anyway.
>>
>> Looks -EINVAL might be used.
>
> Hmm, -EINVAL is being used way too frequently already. -EBUSY
> would make it at least a little bit more distinct.

Yeah, this also makes sense.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:51:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlceS-0001JL-SV; Tue, 04 Nov 2014 11:51:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XlceR-0001JA-9r
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:51:55 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	09/45-14214-ADDB8545; Tue, 04 Nov 2014 11:51:54 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415101913!11114869!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26756 invoked from network); 4 Nov 2014 11:51:53 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-206.messagelabs.com with SMTP;
	4 Nov 2014 11:51:53 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 04 Nov 2014 03:51:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,313,1413270000"; d="scan'208";a="626192722"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.157])
	([10.238.128.157])
	by fmsmga002.fm.intel.com with ESMTP; 04 Nov 2014 03:51:50 -0800
Message-ID: <5458BDD5.8070800@intel.com>
Date: Tue, 04 Nov 2014 19:51:49 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
	<54576B9B.1060601@intel.com>
	<54577AD302000078000445EB@mail.emea.novell.com>
	<54582D59.4020201@intel.com>
	<545896080200007800044A67@mail.emea.novell.com>
	<5458AD63.4020301@intel.com>
	<5458C9850200007800044BF4@mail.emea.novell.com>
In-Reply-To: <5458C9850200007800044BF4@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/4 19:41, Jan Beulich wrote:
>>>> On 04.11.14 at 11:41, <tiejun.chen@intel.com> wrote:
>> On 2014/11/4 16:02, Jan Beulich wrote:
>>>>>> On 04.11.14 at 02:35, <tiejun.chen@intel.com> wrote:
>>>> @@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>>>>         /* Now, actually do the two-way mapping */
>>>>         if ( mfn_valid(_mfn(mfn)) )
>>>>         {
>>>> -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
>>>> -                           p2m->default_access);
>>>> +        rc = 0;
>>>> +        a =  p2m->default_access;
>>>> +        if ( !is_hardware_domain(d) )
>>>> +        {
>>>> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
>>>> +                                                  &gfn);
>>>> +            /* We always avoid populating reserved device memory. */
>>>> +            if ( rc == 1 )
>>>> +                goto out;
>>>
>>> But you'll need to make sure that you don't return 1 to the callers:
>>
>> You're right.
>>
>>> They expect 0 or negative error codes. But with the model of
>>> not even populating these regions (or relocating the memory
>>> before [at boot time] assigning a device associated with an RMRR)
>>> I think this needs to become an error anyway.
>>
>> Looks -EINVAL might be used.
>
> Hmm, -EINVAL is being used way too frequently already. -EBUSY
> would make it at least a little bit more distinct.

Yeah, this also makes sense.

Thanks
Tiejun

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:53:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcfS-0001UD-CH; Tue, 04 Nov 2014 11:52:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlcfQ-0001So-7N
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:52:57 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	90/AF-18267-71EB8545; Tue, 04 Nov 2014 11:52:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415101971!7086141!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18024 invoked from network); 4 Nov 2014 11:52:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:52:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187866685"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 06:52:48 -0500
Received: from cosworth.uk.xensource.com	([10.80.16.52]
	helo=localhost.localdomain ident=ianc)	by ukmail1.uk.xensource.com with
	smtp (Exim 4.69)	(envelope-from <ian.campbell@citrix.com>)	id
	1XlcfH-0003gC-3m; Tue, 04 Nov 2014 11:52:48 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Tue, 04 Nov
	2014 11:52:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, <ian.jackson@eu.citrix.com>,
	<wei.liu2@citrix.com>
Date: Tue, 4 Nov 2014 11:52:47 +0000
Message-ID: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This was disabled by default in Xen 4.4. Since xend has now been removed from
the tree I don't believe anything is using it.

We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xen-traditional otherwise
it defaults to y and doesn't build.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
I think this has probably missed the boat for 4.5 and there isn't much harm in
waiting for 4.6. I'm open to being told otherwise though ;-)
---
 .gitignore                               |    5 -
 .hgignore                                |    5 -
 INSTALL                                  |    1 -
 config/Tools.mk.in                       |    1 -
 tools/Makefile                           |    2 +-
 tools/blktap/Makefile                    |   13 -
 tools/blktap/README                      |  122 --
 tools/blktap/drivers/Makefile            |   73 --
 tools/blktap/drivers/aes.c               | 1319 -------------------
 tools/blktap/drivers/aes.h               |   28 -
 tools/blktap/drivers/blk.h               |    3 -
 tools/blktap/drivers/blk_linux.c         |   42 -
 tools/blktap/drivers/blktapctrl.c        |  937 -------------
 tools/blktap/drivers/blktapctrl.h        |   36 -
 tools/blktap/drivers/blktapctrl_linux.c  |   89 --
 tools/blktap/drivers/block-aio.c         |  259 ----
 tools/blktap/drivers/block-qcow.c        | 1434 --------------------
 tools/blktap/drivers/block-qcow2.c       | 2098 ------------------------------
 tools/blktap/drivers/block-ram.c         |  295 -----
 tools/blktap/drivers/block-sync.c        |  242 ----
 tools/blktap/drivers/block-vmdk.c        |  428 ------
 tools/blktap/drivers/bswap.h             |  178 ---
 tools/blktap/drivers/img2qcow.c          |  282 ----
 tools/blktap/drivers/qcow-create.c       |  130 --
 tools/blktap/drivers/qcow2raw.c          |  348 -----
 tools/blktap/drivers/tapaio.c            |  357 -----
 tools/blktap/drivers/tapaio.h            |  108 --
 tools/blktap/drivers/tapdisk.c           |  872 -------------
 tools/blktap/drivers/tapdisk.h           |  259 ----
 tools/blktap/lib/Makefile                |   60 -
 tools/blktap/lib/blkif.c                 |  185 ---
 tools/blktap/lib/blktaplib.h             |  240 ----
 tools/blktap/lib/list.h                  |   59 -
 tools/blktap/lib/xenbus.c                |  617 ---------
 tools/blktap/lib/xs_api.c                |  360 -----
 tools/blktap/lib/xs_api.h                |   50 -
 tools/configure                          |   29 +-
 tools/configure.ac                       |    4 +-
 tools/hotplug/Linux/Makefile             |    1 -
 tools/hotplug/Linux/blktap               |   94 --
 tools/hotplug/Linux/xen-backend.rules.in |    2 -
 41 files changed, 3 insertions(+), 11664 deletions(-)
 delete mode 100644 tools/blktap/Makefile
 delete mode 100644 tools/blktap/README
 delete mode 100644 tools/blktap/drivers/Makefile
 delete mode 100644 tools/blktap/drivers/aes.c
 delete mode 100644 tools/blktap/drivers/aes.h
 delete mode 100644 tools/blktap/drivers/blk.h
 delete mode 100644 tools/blktap/drivers/blk_linux.c
 delete mode 100644 tools/blktap/drivers/blktapctrl.c
 delete mode 100644 tools/blktap/drivers/blktapctrl.h
 delete mode 100644 tools/blktap/drivers/blktapctrl_linux.c
 delete mode 100644 tools/blktap/drivers/block-aio.c
 delete mode 100644 tools/blktap/drivers/block-qcow.c
 delete mode 100644 tools/blktap/drivers/block-qcow2.c
 delete mode 100644 tools/blktap/drivers/block-ram.c
 delete mode 100644 tools/blktap/drivers/block-sync.c
 delete mode 100644 tools/blktap/drivers/block-vmdk.c
 delete mode 100644 tools/blktap/drivers/bswap.h
 delete mode 100644 tools/blktap/drivers/img2qcow.c
 delete mode 100644 tools/blktap/drivers/qcow-create.c
 delete mode 100644 tools/blktap/drivers/qcow2raw.c
 delete mode 100644 tools/blktap/drivers/tapaio.c
 delete mode 100644 tools/blktap/drivers/tapaio.h
 delete mode 100644 tools/blktap/drivers/tapdisk.c
 delete mode 100644 tools/blktap/drivers/tapdisk.h
 delete mode 100644 tools/blktap/lib/Makefile
 delete mode 100644 tools/blktap/lib/blkif.c
 delete mode 100644 tools/blktap/lib/blktaplib.h
 delete mode 100644 tools/blktap/lib/list.h
 delete mode 100644 tools/blktap/lib/xenbus.c
 delete mode 100644 tools/blktap/lib/xs_api.c
 delete mode 100644 tools/blktap/lib/xs_api.h
 delete mode 100644 tools/hotplug/Linux/blktap

diff --git a/.gitignore b/.gitignore
index b24e905..6830a06 100644
--- a/.gitignore
+++ b/.gitignore
@@ -101,11 +101,6 @@ tools/blktap2/drivers/tapdisk2
 tools/blktap2/drivers/td-util
 tools/blktap2/vhd/vhd-update
 tools/blktap2/vhd/vhd-util
-tools/blktap/drivers/blktapctrl
-tools/blktap/drivers/img2qcow
-tools/blktap/drivers/qcow-create
-tools/blktap/drivers/qcow2raw
-tools/blktap/drivers/tapdisk
 tools/console/xenconsole
 tools/console/xenconsoled
 tools/debugger/gdb/gdb-6.2.1-linux-i386-xen/*
diff --git a/.hgignore b/.hgignore
index da27f80..0bd29a1 100644
--- a/.hgignore
+++ b/.hgignore
@@ -140,11 +140,6 @@
 ^tools/blktap2/drivers/td-util$
 ^tools/blktap2/vhd/vhd-update$
 ^tools/blktap2/vhd/vhd-util$
-^tools/blktap/drivers/blktapctrl$
-^tools/blktap/drivers/img2qcow$
-^tools/blktap/drivers/qcow-create$
-^tools/blktap/drivers/qcow2raw$
-^tools/blktap/drivers/tapdisk$
 ^tools/check/\..*$
 ^tools/console/xenconsole$
 ^tools/console/xenconsoled$
diff --git a/INSTALL b/INSTALL
index 6bb9d23..f0fc6f1 100644
--- a/INSTALL
+++ b/INSTALL
@@ -149,7 +149,6 @@ this detection and the sysv runlevel scripts have to be used.
 
 The old backend drivers are disabled because qdisk is now the default.
 This option can be used to build them anyway.
-  --enable-blktap1
   --enable-blktap2
 
 Build various stubom components, some are only example code. Its usually
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 89de5bd..30267fa 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -57,7 +57,6 @@ CONFIG_ROMBIOS      := @rombios@
 CONFIG_SEABIOS      := @seabios@
 CONFIG_QEMU_TRAD    := @qemu_traditional@
 CONFIG_QEMU_XEN     := @qemu_xen@
-CONFIG_BLKTAP1      := @blktap1@
 CONFIG_BLKTAP2      := @blktap2@
 CONFIG_QEMUU_EXTRA_ARGS:= @EXTRA_QEMUU_CONFIGURE_ARGS@
 CONFIG_REMUS_NETBUF := @remus_netbuf@
diff --git a/tools/Makefile b/tools/Makefile
index af9798a..1ad7a5d 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -16,7 +16,6 @@ SUBDIRS-y += console
 SUBDIRS-y += xenmon
 SUBDIRS-y += xenstat
 SUBDIRS-$(CONFIG_Linux) += memshr 
-SUBDIRS-$(CONFIG_BLKTAP1) += blktap
 SUBDIRS-$(CONFIG_BLKTAP2) += blktap2
 SUBDIRS-$(CONFIG_NetBSD) += xenbackendd
 SUBDIRS-y += libfsimage
@@ -169,6 +168,7 @@ subdir-all-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
 subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
 	set -e; \
 		$(buildmakevars2shellvars); \
+		export CONFIG_BLKTAP1=n; \
 		cd qemu-xen-traditional-dir; \
 		$(QEMU_ROOT)/xen-setup \
 		--extra-cflags="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
diff --git a/tools/blktap/Makefile b/tools/blktap/Makefile
deleted file mode 100644
index 4020566..0000000
--- a/tools/blktap/Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-XEN_ROOT = $(CURDIR)/../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-SUBDIRS-y :=
-SUBDIRS-y += lib
-SUBDIRS-y += drivers
-
-.PHONY: all clean install
-all clean install: %: subdirs-%
-
-install:
-	$(INSTALL_DIR) $(DESTDIR)$(DOCDIR)
-	$(INSTALL_DATA) README $(DESTDIR)$(DOCDIR)/README.blktap
diff --git a/tools/blktap/README b/tools/blktap/README
deleted file mode 100644
index 5e41080..0000000
--- a/tools/blktap/README
+++ /dev/null
@@ -1,122 +0,0 @@
-Blktap Userspace Tools + Library
-================================
-
-Andrew Warfield and Julian Chesterfield
-16th June 2006
-
-{firstname.lastname}@cl.cam.ac.uk
-
-The blktap userspace toolkit provides a user-level disk I/O
-interface. The blktap mechanism involves a kernel driver that acts
-similarly to the existing Xen/Linux blkback driver, and a set of
-associated user-level libraries.  Using these tools, blktap allows
-virtual block devices presented to VMs to be implemented in userspace
-and to be backed by raw partitions, files, network, etc.
-
-The key benefit of blktap is that it makes it easy and fast to write
-arbitrary block backends, and that these user-level backends actually
-perform very well.  Specifically:
-
-- Metadata disk formats such as Copy-on-Write, encrypted disks, sparse
-  formats and other compression features can be easily implemented.
-
-- Accessing file-based images from userspace avoids problems related
-  to flushing dirty pages which are present in the Linux loopback
-  driver.  (Specifically, doing a large number of writes to an
-  NFS-backed image don't result in the OOM killer going berserk.)
-
-- Per-disk handler processes enable easier userspace policing of block
-  resources, and process-granularity QoS techniques (disk scheduling
-  and related tools) may be trivially applied to block devices.
-
-- It's very easy to take advantage of userspace facilities such as
-  networking libraries, compression utilities, peer-to-peer
-  file-sharing systems and so on to build more complex block backends.
-
-- Crashes are contained -- incremental development/debugging is very
-  fast.
-
-How it works (in one paragraph):
-
-Working in conjunction with the kernel blktap driver, all disk I/O
-requests from VMs are passed to the userspace deamon (using a shared
-memory interface) through a character device. Each active disk is
-mapped to an individual device node, allowing per-disk processes to
-implement individual block devices where desired.  The userspace
-drivers are implemented using asynchronous (Linux libaio),
-O_DIRECT-based calls to preserve the unbuffered, batched and
-asynchronous request dispatch achieved with the existing blkback
-code.  We provide a simple, asynchronous virtual disk interface that
-makes it quite easy to add new disk implementations.
-
-As of June 2006 the current supported disk formats are:
-
- - Raw Images (both on partitions and in image files)
- - File-backed Qcow disks
- - Standalone sparse Qcow disks
- - Fast shareable RAM disk between VMs (requires some form of cluster-based 
-   filesystem support e.g. OCFS2 in the guest kernel)
- - Some VMDK images - your mileage may vary
-
-Raw and QCow images have asynchronous backends and so should perform
-fairly well.  VMDK is based directly on the qemu vmdk driver, which is
-synchronous (a.k.a. slow).
-
-Build and Installation Instructions
-===================================
-
-Make to configure the blktap backend driver in your dom0 kernel.  It
-will cooperate fine with the existing backend driver, so you can
-experiment with tap disks without breaking existing VM configs.
-
-To build the tools separately, "make && make install" in 
-tools/blktap.
-
-
-Using the Tools
-===============
-
-Prepare the image for booting. For qcow files use the qcow utilities
-installed earlier. e.g. qcow-create generates a blank standalone image
-or a file-backed CoW image. img2qcow takes an existing image or
-partition and creates a sparse, standalone qcow-based file.
-
-The userspace disk agent is configured to start automatically via xend
-(alternatively you can start it manually => 'blktapctrl')
-
-Customise the VM config file to use the 'tap' handler, followed by the
-driver type. e.g. for a raw image such as a file or partition:
-
-disk = ['tap:aio:<FILENAME>,sda1,w']
-
-e.g. for a qcow image:
-
-disk = ['tap:qcow:<FILENAME>,sda1,w']
-
-
-Mounting images in Dom0 using the blktap driver
-===============================================
-Tap (and blkback) disks are also mountable in Dom0 without requiring an
-active VM to attach. You will need to build a xenlinux Dom0 kernel that
-includes the blkfront driver (e.g. the default 'make world' or 
-'make kernels' build. Simply use the xm command-line tool to activate
-the backend disks, and blkfront will generate a virtual block device that
-can be accessed in the same way as a loop device or partition:
-
-e.g. for a raw image file <FILENAME> that would normally be mounted using
-the loopback driver (such as 'mount -o loop <FILENAME> /mnt/disk'), do the
-following:
-
-xm block-attach 0 tap:aio:<FILENAME> /dev/xvda1 w 0
-mount /dev/xvda1 /mnt/disk        <--- don't use loop driver
-
-In this way, you can use any of the userspace device-type drivers built
-with the blktap userspace toolkit to open and mount disks such as qcow
-or vmdk images:
-
-xm block-attach 0 tap:qcow:<FILENAME> /dev/xvda1 w 0
-mount /dev/xvda1 /mnt/disk
-
-
-
- 
diff --git a/tools/blktap/drivers/Makefile b/tools/blktap/drivers/Makefile
deleted file mode 100644
index 7461a95..0000000
--- a/tools/blktap/drivers/Makefile
+++ /dev/null
@@ -1,73 +0,0 @@
-XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-IBIN         = blktapctrl tapdisk
-QCOW_UTIL    = img2qcow qcow2raw qcow-create
-
-CFLAGS   += -Werror
-CFLAGS   += -Wno-unused
-CFLAGS   += -I../lib
-CFLAGS   += $(CFLAGS_libxenctrl)
-CFLAGS   += $(CFLAGS_libxenstore)
-CFLAGS   += -D_GNU_SOURCE
-
-ifeq ($CONFIG_GCRYPT,y)
-CFLAGS += -DUSE_GCRYPT
-CRYPT_LIB := -lgcrypt
-else
-CRYPT_LIB := -lcrypto
-$(warning === libgcrypt not installed: falling back to libcrypto ===)
-endif
-
-MEMSHRLIBS :=
-ifeq ($(CONFIG_Linux), y)
-MEMSHR_DIR   = ../../memshr
-CFLAGS += -DMEMSHR
-CFLAGS += -I $(MEMSHR_DIR)
-MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
-endif
-
-AIOLIBS     := -laio
-
-CFLAGS += $(PTHREAD_CFLAGS)
-LDFLAGS += $(PTHREAD_LDFLAGS)
-
-LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm $(PTHREAD_LIBS)
-LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) $(PTHREAD_LIBS) -lz
-
-BLK-OBJS-y  := block-aio.o
-BLK-OBJS-y  += block-sync.o
-BLK-OBJS-y  += block-vmdk.o
-BLK-OBJS-y  += block-ram.o
-BLK-OBJS-y  += block-qcow.o
-BLK-OBJS-y  += block-qcow2.o
-BLK-OBJS-y  += aes.o
-BLK-OBJS-y  += tapaio.o
-BLK-OBJS-$(CONFIG_Linux) += blk_linux.o
-
-BLKTAB-OBJS-y := blktapctrl.o
-BLKTAB-OBJS-$(CONFIG_Linux) += blktapctrl_linux.o
-
-all: $(IBIN) qcow-util
-
-blktapctrl: $(BLKTAB-OBJS-y)
-	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS_blktapctrl)
-
-tapdisk: tapdisk.o $(BLK-OBJS-y)
-	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS_img)
-
-.PHONY: qcow-util
-qcow-util: img2qcow qcow2raw qcow-create
-
-img2qcow qcow2raw qcow-create: %: %.o $(BLK-OBJS-y)
-	$(CC) $(LDFLAGS) -o $* $^ $(LDLIBS_img)
-
-install: all
-	$(INSTALL_PROG) $(IBIN) $(QCOW_UTIL) $(VHD_UTIL) $(DESTDIR)$(SBINDIR)
-
-clean:
-	rm -rf *.o *~ $(DEPS) xen TAGS $(IBIN) $(LIB) $(QCOW_UTIL) $(VHD_UTIL)
-
-.PHONY: clean install
-
--include $(DEPS)
diff --git a/tools/blktap/drivers/aes.c b/tools/blktap/drivers/aes.c
deleted file mode 100644
index 4d83fac..0000000
--- a/tools/blktap/drivers/aes.c
+++ /dev/null
@@ -1,1319 +0,0 @@
-/**
- * 
- * aes.c - integrated in QEMU by Fabrice Bellard from the OpenSSL project.
- */
-/*
- * rijndael-alg-fst.c
- *
- * @version 3.0 (December 2000)
- *
- * Optimised ANSI C code for the Rijndael cipher (now AES)
- *
- * @author Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>
- * @author Antoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be>
- * @author Paulo Barreto <paulo.barreto@terra.com.br>
- *
- * This code is hereby placed in the public domain.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''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 AUTHORS 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 "vl.h"
-#include <inttypes.h>
-#include <string.h>
-#include "aes.h"
-
-//#define NDEBUG
-#include <assert.h>
-
-typedef uint32_t u32;
-typedef uint16_t u16;
-typedef uint8_t u8;
-
-#define MAXKC   (256/32)
-#define MAXKB   (256/8)
-#define MAXNR   14
-
-/* This controls loop-unrolling in aes_core.c */
-#undef FULL_UNROLL
-# define GETU32(pt) (((u32)(pt)[0] << 24) ^ ((u32)(pt)[1] << 16) ^ ((u32)(pt)[2] <<  8) ^ ((u32)(pt)[3]))
-# define PUTU32(ct, st) { (ct)[0] = (u8)((st) >> 24); (ct)[1] = (u8)((st) >> 16); (ct)[2] = (u8)((st) >>  8); (ct)[3] = (u8)(st); }
-
-/*
-Te0[x] = S [x].[02, 01, 01, 03];
-Te1[x] = S [x].[03, 02, 01, 01];
-Te2[x] = S [x].[01, 03, 02, 01];
-Te3[x] = S [x].[01, 01, 03, 02];
-Te4[x] = S [x].[01, 01, 01, 01];
-
-Td0[x] = Si[x].[0e, 09, 0d, 0b];
-Td1[x] = Si[x].[0b, 0e, 09, 0d];
-Td2[x] = Si[x].[0d, 0b, 0e, 09];
-Td3[x] = Si[x].[09, 0d, 0b, 0e];
-Td4[x] = Si[x].[01, 01, 01, 01];
-*/
-
-static const u32 Te0[256] = {
-    0xc66363a5U, 0xf87c7c84U, 0xee777799U, 0xf67b7b8dU,
-    0xfff2f20dU, 0xd66b6bbdU, 0xde6f6fb1U, 0x91c5c554U,
-    0x60303050U, 0x02010103U, 0xce6767a9U, 0x562b2b7dU,
-    0xe7fefe19U, 0xb5d7d762U, 0x4dababe6U, 0xec76769aU,
-    0x8fcaca45U, 0x1f82829dU, 0x89c9c940U, 0xfa7d7d87U,
-    0xeffafa15U, 0xb25959ebU, 0x8e4747c9U, 0xfbf0f00bU,
-    0x41adadecU, 0xb3d4d467U, 0x5fa2a2fdU, 0x45afafeaU,
-    0x239c9cbfU, 0x53a4a4f7U, 0xe4727296U, 0x9bc0c05bU,
-    0x75b7b7c2U, 0xe1fdfd1cU, 0x3d9393aeU, 0x4c26266aU,
-    0x6c36365aU, 0x7e3f3f41U, 0xf5f7f702U, 0x83cccc4fU,
-    0x6834345cU, 0x51a5a5f4U, 0xd1e5e534U, 0xf9f1f108U,
-    0xe2717193U, 0xabd8d873U, 0x62313153U, 0x2a15153fU,
-    0x0804040cU, 0x95c7c752U, 0x46232365U, 0x9dc3c35eU,
-    0x30181828U, 0x379696a1U, 0x0a05050fU, 0x2f9a9ab5U,
-    0x0e070709U, 0x24121236U, 0x1b80809bU, 0xdfe2e23dU,
-    0xcdebeb26U, 0x4e272769U, 0x7fb2b2cdU, 0xea75759fU,
-    0x1209091bU, 0x1d83839eU, 0x582c2c74U, 0x341a1a2eU,
-    0x361b1b2dU, 0xdc6e6eb2U, 0xb45a5aeeU, 0x5ba0a0fbU,
-    0xa45252f6U, 0x763b3b4dU, 0xb7d6d661U, 0x7db3b3ceU,
-    0x5229297bU, 0xdde3e33eU, 0x5e2f2f71U, 0x13848497U,
-    0xa65353f5U, 0xb9d1d168U, 0x00000000U, 0xc1eded2cU,
-    0x40202060U, 0xe3fcfc1fU, 0x79b1b1c8U, 0xb65b5bedU,
-    0xd46a6abeU, 0x8dcbcb46U, 0x67bebed9U, 0x7239394bU,
-    0x944a4adeU, 0x984c4cd4U, 0xb05858e8U, 0x85cfcf4aU,
-    0xbbd0d06bU, 0xc5efef2aU, 0x4faaaae5U, 0xedfbfb16U,
-    0x864343c5U, 0x9a4d4dd7U, 0x66333355U, 0x11858594U,
-    0x8a4545cfU, 0xe9f9f910U, 0x04020206U, 0xfe7f7f81U,
-    0xa05050f0U, 0x783c3c44U, 0x259f9fbaU, 0x4ba8a8e3U,
-    0xa25151f3U, 0x5da3a3feU, 0x804040c0U, 0x058f8f8aU,
-    0x3f9292adU, 0x219d9dbcU, 0x70383848U, 0xf1f5f504U,
-    0x63bcbcdfU, 0x77b6b6c1U, 0xafdada75U, 0x42212163U,
-    0x20101030U, 0xe5ffff1aU, 0xfdf3f30eU, 0xbfd2d26dU,
-    0x81cdcd4cU, 0x180c0c14U, 0x26131335U, 0xc3ecec2fU,
-    0xbe5f5fe1U, 0x359797a2U, 0x884444ccU, 0x2e171739U,
-    0x93c4c457U, 0x55a7a7f2U, 0xfc7e7e82U, 0x7a3d3d47U,
-    0xc86464acU, 0xba5d5de7U, 0x3219192bU, 0xe6737395U,
-    0xc06060a0U, 0x19818198U, 0x9e4f4fd1U, 0xa3dcdc7fU,
-    0x44222266U, 0x542a2a7eU, 0x3b9090abU, 0x0b888883U,
-    0x8c4646caU, 0xc7eeee29U, 0x6bb8b8d3U, 0x2814143cU,
-    0xa7dede79U, 0xbc5e5ee2U, 0x160b0b1dU, 0xaddbdb76U,
-    0xdbe0e03bU, 0x64323256U, 0x743a3a4eU, 0x140a0a1eU,
-    0x924949dbU, 0x0c06060aU, 0x4824246cU, 0xb85c5ce4U,
-    0x9fc2c25dU, 0xbdd3d36eU, 0x43acacefU, 0xc46262a6U,
-    0x399191a8U, 0x319595a4U, 0xd3e4e437U, 0xf279798bU,
-    0xd5e7e732U, 0x8bc8c843U, 0x6e373759U, 0xda6d6db7U,
-    0x018d8d8cU, 0xb1d5d564U, 0x9c4e4ed2U, 0x49a9a9e0U,
-    0xd86c6cb4U, 0xac5656faU, 0xf3f4f407U, 0xcfeaea25U,
-    0xca6565afU, 0xf47a7a8eU, 0x47aeaee9U, 0x10080818U,
-    0x6fbabad5U, 0xf0787888U, 0x4a25256fU, 0x5c2e2e72U,
-    0x381c1c24U, 0x57a6a6f1U, 0x73b4b4c7U, 0x97c6c651U,
-    0xcbe8e823U, 0xa1dddd7cU, 0xe874749cU, 0x3e1f1f21U,
-    0x964b4bddU, 0x61bdbddcU, 0x0d8b8b86U, 0x0f8a8a85U,
-    0xe0707090U, 0x7c3e3e42U, 0x71b5b5c4U, 0xcc6666aaU,
-    0x904848d8U, 0x06030305U, 0xf7f6f601U, 0x1c0e0e12U,
-    0xc26161a3U, 0x6a35355fU, 0xae5757f9U, 0x69b9b9d0U,
-    0x17868691U, 0x99c1c158U, 0x3a1d1d27U, 0x279e9eb9U,
-    0xd9e1e138U, 0xebf8f813U, 0x2b9898b3U, 0x22111133U,
-    0xd26969bbU, 0xa9d9d970U, 0x078e8e89U, 0x339494a7U,
-    0x2d9b9bb6U, 0x3c1e1e22U, 0x15878792U, 0xc9e9e920U,
-    0x87cece49U, 0xaa5555ffU, 0x50282878U, 0xa5dfdf7aU,
-    0x038c8c8fU, 0x59a1a1f8U, 0x09898980U, 0x1a0d0d17U,
-    0x65bfbfdaU, 0xd7e6e631U, 0x844242c6U, 0xd06868b8U,
-    0x824141c3U, 0x299999b0U, 0x5a2d2d77U, 0x1e0f0f11U,
-    0x7bb0b0cbU, 0xa85454fcU, 0x6dbbbbd6U, 0x2c16163aU,
-};
-static const u32 Te1[256] = {
-    0xa5c66363U, 0x84f87c7cU, 0x99ee7777U, 0x8df67b7bU,
-    0x0dfff2f2U, 0xbdd66b6bU, 0xb1de6f6fU, 0x5491c5c5U,
-    0x50603030U, 0x03020101U, 0xa9ce6767U, 0x7d562b2bU,
-    0x19e7fefeU, 0x62b5d7d7U, 0xe64dababU, 0x9aec7676U,
-    0x458fcacaU, 0x9d1f8282U, 0x4089c9c9U, 0x87fa7d7dU,
-    0x15effafaU, 0xebb25959U, 0xc98e4747U, 0x0bfbf0f0U,
-    0xec41adadU, 0x67b3d4d4U, 0xfd5fa2a2U, 0xea45afafU,
-    0xbf239c9cU, 0xf753a4a4U, 0x96e47272U, 0x5b9bc0c0U,
-    0xc275b7b7U, 0x1ce1fdfdU, 0xae3d9393U, 0x6a4c2626U,
-    0x5a6c3636U, 0x417e3f3fU, 0x02f5f7f7U, 0x4f83ccccU,
-    0x5c683434U, 0xf451a5a5U, 0x34d1e5e5U, 0x08f9f1f1U,
-    0x93e27171U, 0x73abd8d8U, 0x53623131U, 0x3f2a1515U,
-    0x0c080404U, 0x5295c7c7U, 0x65462323U, 0x5e9dc3c3U,
-    0x28301818U, 0xa1379696U, 0x0f0a0505U, 0xb52f9a9aU,
-    0x090e0707U, 0x36241212U, 0x9b1b8080U, 0x3ddfe2e2U,
-    0x26cdebebU, 0x694e2727U, 0xcd7fb2b2U, 0x9fea7575U,
-    0x1b120909U, 0x9e1d8383U, 0x74582c2cU, 0x2e341a1aU,
-    0x2d361b1bU, 0xb2dc6e6eU, 0xeeb45a5aU, 0xfb5ba0a0U,
-    0xf6a45252U, 0x4d763b3bU, 0x61b7d6d6U, 0xce7db3b3U,
-    0x7b522929U, 0x3edde3e3U, 0x715e2f2fU, 0x97138484U,
-    0xf5a65353U, 0x68b9d1d1U, 0x00000000U, 0x2cc1ededU,
-    0x60402020U, 0x1fe3fcfcU, 0xc879b1b1U, 0xedb65b5bU,
-    0xbed46a6aU, 0x468dcbcbU, 0xd967bebeU, 0x4b723939U,
-    0xde944a4aU, 0xd4984c4cU, 0xe8b05858U, 0x4a85cfcfU,
-    0x6bbbd0d0U, 0x2ac5efefU, 0xe54faaaaU, 0x16edfbfbU,
-    0xc5864343U, 0xd79a4d4dU, 0x55663333U, 0x94118585U,
-    0xcf8a4545U, 0x10e9f9f9U, 0x06040202U, 0x81fe7f7fU,
-    0xf0a05050U, 0x44783c3cU, 0xba259f9fU, 0xe34ba8a8U,
-    0xf3a25151U, 0xfe5da3a3U, 0xc0804040U, 0x8a058f8fU,
-    0xad3f9292U, 0xbc219d9dU, 0x48703838U, 0x04f1f5f5U,
-    0xdf63bcbcU, 0xc177b6b6U, 0x75afdadaU, 0x63422121U,
-    0x30201010U, 0x1ae5ffffU, 0x0efdf3f3U, 0x6dbfd2d2U,
-    0x4c81cdcdU, 0x14180c0cU, 0x35261313U, 0x2fc3ececU,
-    0xe1be5f5fU, 0xa2359797U, 0xcc884444U, 0x392e1717U,
-    0x5793c4c4U, 0xf255a7a7U, 0x82fc7e7eU, 0x477a3d3dU,
-    0xacc86464U, 0xe7ba5d5dU, 0x2b321919U, 0x95e67373U,
-    0xa0c06060U, 0x98198181U, 0xd19e4f4fU, 0x7fa3dcdcU,
-    0x66442222U, 0x7e542a2aU, 0xab3b9090U, 0x830b8888U,
-    0xca8c4646U, 0x29c7eeeeU, 0xd36bb8b8U, 0x3c281414U,
-    0x79a7dedeU, 0xe2bc5e5eU, 0x1d160b0bU, 0x76addbdbU,
-    0x3bdbe0e0U, 0x56643232U, 0x4e743a3aU, 0x1e140a0aU,
-    0xdb924949U, 0x0a0c0606U, 0x6c482424U, 0xe4b85c5cU,
-    0x5d9fc2c2U, 0x6ebdd3d3U, 0xef43acacU, 0xa6c46262U,
-    0xa8399191U, 0xa4319595U, 0x37d3e4e4U, 0x8bf27979U,
-    0x32d5e7e7U, 0x438bc8c8U, 0x596e3737U, 0xb7da6d6dU,
-    0x8c018d8dU, 0x64b1d5d5U, 0xd29c4e4eU, 0xe049a9a9U,
-    0xb4d86c6cU, 0xfaac5656U, 0x07f3f4f4U, 0x25cfeaeaU,
-    0xafca6565U, 0x8ef47a7aU, 0xe947aeaeU, 0x18100808U,
-    0xd56fbabaU, 0x88f07878U, 0x6f4a2525U, 0x725c2e2eU,
-    0x24381c1cU, 0xf157a6a6U, 0xc773b4b4U, 0x5197c6c6U,
-    0x23cbe8e8U, 0x7ca1ddddU, 0x9ce87474U, 0x213e1f1fU,
-    0xdd964b4bU, 0xdc61bdbdU, 0x860d8b8bU, 0x850f8a8aU,
-    0x90e07070U, 0x427c3e3eU, 0xc471b5b5U, 0xaacc6666U,
-    0xd8904848U, 0x05060303U, 0x01f7f6f6U, 0x121c0e0eU,
-    0xa3c26161U, 0x5f6a3535U, 0xf9ae5757U, 0xd069b9b9U,
-    0x91178686U, 0x5899c1c1U, 0x273a1d1dU, 0xb9279e9eU,
-    0x38d9e1e1U, 0x13ebf8f8U, 0xb32b9898U, 0x33221111U,
-    0xbbd26969U, 0x70a9d9d9U, 0x89078e8eU, 0xa7339494U,
-    0xb62d9b9bU, 0x223c1e1eU, 0x92158787U, 0x20c9e9e9U,
-    0x4987ceceU, 0xffaa5555U, 0x78502828U, 0x7aa5dfdfU,
-    0x8f038c8cU, 0xf859a1a1U, 0x80098989U, 0x171a0d0dU,
-    0xda65bfbfU, 0x31d7e6e6U, 0xc6844242U, 0xb8d06868U,
-    0xc3824141U, 0xb0299999U, 0x775a2d2dU, 0x111e0f0fU,
-    0xcb7bb0b0U, 0xfca85454U, 0xd66dbbbbU, 0x3a2c1616U,
-};
-static const u32 Te2[256] = {
-    0x63a5c663U, 0x7c84f87cU, 0x7799ee77U, 0x7b8df67bU,
-    0xf20dfff2U, 0x6bbdd66bU, 0x6fb1de6fU, 0xc55491c5U,
-    0x30506030U, 0x01030201U, 0x67a9ce67U, 0x2b7d562bU,
-    0xfe19e7feU, 0xd762b5d7U, 0xabe64dabU, 0x769aec76U,
-    0xca458fcaU, 0x829d1f82U, 0xc94089c9U, 0x7d87fa7dU,
-    0xfa15effaU, 0x59ebb259U, 0x47c98e47U, 0xf00bfbf0U,
-    0xadec41adU, 0xd467b3d4U, 0xa2fd5fa2U, 0xafea45afU,
-    0x9cbf239cU, 0xa4f753a4U, 0x7296e472U, 0xc05b9bc0U,
-    0xb7c275b7U, 0xfd1ce1fdU, 0x93ae3d93U, 0x266a4c26U,
-    0x365a6c36U, 0x3f417e3fU, 0xf702f5f7U, 0xcc4f83ccU,
-    0x345c6834U, 0xa5f451a5U, 0xe534d1e5U, 0xf108f9f1U,
-    0x7193e271U, 0xd873abd8U, 0x31536231U, 0x153f2a15U,
-    0x040c0804U, 0xc75295c7U, 0x23654623U, 0xc35e9dc3U,
-    0x18283018U, 0x96a13796U, 0x050f0a05U, 0x9ab52f9aU,
-    0x07090e07U, 0x12362412U, 0x809b1b80U, 0xe23ddfe2U,
-    0xeb26cdebU, 0x27694e27U, 0xb2cd7fb2U, 0x759fea75U,
-    0x091b1209U, 0x839e1d83U, 0x2c74582cU, 0x1a2e341aU,
-    0x1b2d361bU, 0x6eb2dc6eU, 0x5aeeb45aU, 0xa0fb5ba0U,
-    0x52f6a452U, 0x3b4d763bU, 0xd661b7d6U, 0xb3ce7db3U,
-    0x297b5229U, 0xe33edde3U, 0x2f715e2fU, 0x84971384U,
-    0x53f5a653U, 0xd168b9d1U, 0x00000000U, 0xed2cc1edU,
-    0x20604020U, 0xfc1fe3fcU, 0xb1c879b1U, 0x5bedb65bU,
-    0x6abed46aU, 0xcb468dcbU, 0xbed967beU, 0x394b7239U,
-    0x4ade944aU, 0x4cd4984cU, 0x58e8b058U, 0xcf4a85cfU,
-    0xd06bbbd0U, 0xef2ac5efU, 0xaae54faaU, 0xfb16edfbU,
-    0x43c58643U, 0x4dd79a4dU, 0x33556633U, 0x85941185U,
-    0x45cf8a45U, 0xf910e9f9U, 0x02060402U, 0x7f81fe7fU,
-    0x50f0a050U, 0x3c44783cU, 0x9fba259fU, 0xa8e34ba8U,
-    0x51f3a251U, 0xa3fe5da3U, 0x40c08040U, 0x8f8a058fU,
-    0x92ad3f92U, 0x9dbc219dU, 0x38487038U, 0xf504f1f5U,
-    0xbcdf63bcU, 0xb6c177b6U, 0xda75afdaU, 0x21634221U,
-    0x10302010U, 0xff1ae5ffU, 0xf30efdf3U, 0xd26dbfd2U,
-    0xcd4c81cdU, 0x0c14180cU, 0x13352613U, 0xec2fc3ecU,
-    0x5fe1be5fU, 0x97a23597U, 0x44cc8844U, 0x17392e17U,
-    0xc45793c4U, 0xa7f255a7U, 0x7e82fc7eU, 0x3d477a3dU,
-    0x64acc864U, 0x5de7ba5dU, 0x192b3219U, 0x7395e673U,
-    0x60a0c060U, 0x81981981U, 0x4fd19e4fU, 0xdc7fa3dcU,
-    0x22664422U, 0x2a7e542aU, 0x90ab3b90U, 0x88830b88U,
-    0x46ca8c46U, 0xee29c7eeU, 0xb8d36bb8U, 0x143c2814U,
-    0xde79a7deU, 0x5ee2bc5eU, 0x0b1d160bU, 0xdb76addbU,
-    0xe03bdbe0U, 0x32566432U, 0x3a4e743aU, 0x0a1e140aU,
-    0x49db9249U, 0x060a0c06U, 0x246c4824U, 0x5ce4b85cU,
-    0xc25d9fc2U, 0xd36ebdd3U, 0xacef43acU, 0x62a6c462U,
-    0x91a83991U, 0x95a43195U, 0xe437d3e4U, 0x798bf279U,
-    0xe732d5e7U, 0xc8438bc8U, 0x37596e37U, 0x6db7da6dU,
-    0x8d8c018dU, 0xd564b1d5U, 0x4ed29c4eU, 0xa9e049a9U,
-    0x6cb4d86cU, 0x56faac56U, 0xf407f3f4U, 0xea25cfeaU,
-    0x65afca65U, 0x7a8ef47aU, 0xaee947aeU, 0x08181008U,
-    0xbad56fbaU, 0x7888f078U, 0x256f4a25U, 0x2e725c2eU,
-    0x1c24381cU, 0xa6f157a6U, 0xb4c773b4U, 0xc65197c6U,
-    0xe823cbe8U, 0xdd7ca1ddU, 0x749ce874U, 0x1f213e1fU,
-    0x4bdd964bU, 0xbddc61bdU, 0x8b860d8bU, 0x8a850f8aU,
-    0x7090e070U, 0x3e427c3eU, 0xb5c471b5U, 0x66aacc66U,
-    0x48d89048U, 0x03050603U, 0xf601f7f6U, 0x0e121c0eU,
-    0x61a3c261U, 0x355f6a35U, 0x57f9ae57U, 0xb9d069b9U,
-    0x86911786U, 0xc15899c1U, 0x1d273a1dU, 0x9eb9279eU,
-    0xe138d9e1U, 0xf813ebf8U, 0x98b32b98U, 0x11332211U,
-    0x69bbd269U, 0xd970a9d9U, 0x8e89078eU, 0x94a73394U,
-    0x9bb62d9bU, 0x1e223c1eU, 0x87921587U, 0xe920c9e9U,
-    0xce4987ceU, 0x55ffaa55U, 0x28785028U, 0xdf7aa5dfU,
-    0x8c8f038cU, 0xa1f859a1U, 0x89800989U, 0x0d171a0dU,
-    0xbfda65bfU, 0xe631d7e6U, 0x42c68442U, 0x68b8d068U,
-    0x41c38241U, 0x99b02999U, 0x2d775a2dU, 0x0f111e0fU,
-    0xb0cb7bb0U, 0x54fca854U, 0xbbd66dbbU, 0x163a2c16U,
-};
-static const u32 Te3[256] = {
-
-    0x6363a5c6U, 0x7c7c84f8U, 0x777799eeU, 0x7b7b8df6U,
-    0xf2f20dffU, 0x6b6bbdd6U, 0x6f6fb1deU, 0xc5c55491U,
-    0x30305060U, 0x01010302U, 0x6767a9ceU, 0x2b2b7d56U,
-    0xfefe19e7U, 0xd7d762b5U, 0xababe64dU, 0x76769aecU,
-    0xcaca458fU, 0x82829d1fU, 0xc9c94089U, 0x7d7d87faU,
-    0xfafa15efU, 0x5959ebb2U, 0x4747c98eU, 0xf0f00bfbU,
-    0xadadec41U, 0xd4d467b3U, 0xa2a2fd5fU, 0xafafea45U,
-    0x9c9cbf23U, 0xa4a4f753U, 0x727296e4U, 0xc0c05b9bU,
-    0xb7b7c275U, 0xfdfd1ce1U, 0x9393ae3dU, 0x26266a4cU,
-    0x36365a6cU, 0x3f3f417eU, 0xf7f702f5U, 0xcccc4f83U,
-    0x34345c68U, 0xa5a5f451U, 0xe5e534d1U, 0xf1f108f9U,
-    0x717193e2U, 0xd8d873abU, 0x31315362U, 0x15153f2aU,
-    0x04040c08U, 0xc7c75295U, 0x23236546U, 0xc3c35e9dU,
-    0x18182830U, 0x9696a137U, 0x05050f0aU, 0x9a9ab52fU,
-    0x0707090eU, 0x12123624U, 0x80809b1bU, 0xe2e23ddfU,
-    0xebeb26cdU, 0x2727694eU, 0xb2b2cd7fU, 0x75759feaU,
-    0x09091b12U, 0x83839e1dU, 0x2c2c7458U, 0x1a1a2e34U,
-    0x1b1b2d36U, 0x6e6eb2dcU, 0x5a5aeeb4U, 0xa0a0fb5bU,
-    0x5252f6a4U, 0x3b3b4d76U, 0xd6d661b7U, 0xb3b3ce7dU,
-    0x29297b52U, 0xe3e33eddU, 0x2f2f715eU, 0x84849713U,
-    0x5353f5a6U, 0xd1d168b9U, 0x00000000U, 0xeded2cc1U,
-    0x20206040U, 0xfcfc1fe3U, 0xb1b1c879U, 0x5b5bedb6U,
-    0x6a6abed4U, 0xcbcb468dU, 0xbebed967U, 0x39394b72U,
-    0x4a4ade94U, 0x4c4cd498U, 0x5858e8b0U, 0xcfcf4a85U,
-    0xd0d06bbbU, 0xefef2ac5U, 0xaaaae54fU, 0xfbfb16edU,
-    0x4343c586U, 0x4d4dd79aU, 0x33335566U, 0x85859411U,
-    0x4545cf8aU, 0xf9f910e9U, 0x02020604U, 0x7f7f81feU,
-    0x5050f0a0U, 0x3c3c4478U, 0x9f9fba25U, 0xa8a8e34bU,
-    0x5151f3a2U, 0xa3a3fe5dU, 0x4040c080U, 0x8f8f8a05U,
-    0x9292ad3fU, 0x9d9dbc21U, 0x38384870U, 0xf5f504f1U,
-    0xbcbcdf63U, 0xb6b6c177U, 0xdada75afU, 0x21216342U,
-    0x10103020U, 0xffff1ae5U, 0xf3f30efdU, 0xd2d26dbfU,
-    0xcdcd4c81U, 0x0c0c1418U, 0x13133526U, 0xecec2fc3U,
-    0x5f5fe1beU, 0x9797a235U, 0x4444cc88U, 0x1717392eU,
-    0xc4c45793U, 0xa7a7f255U, 0x7e7e82fcU, 0x3d3d477aU,
-    0x6464acc8U, 0x5d5de7baU, 0x19192b32U, 0x737395e6U,
-    0x6060a0c0U, 0x81819819U, 0x4f4fd19eU, 0xdcdc7fa3U,
-    0x22226644U, 0x2a2a7e54U, 0x9090ab3bU, 0x8888830bU,
-    0x4646ca8cU, 0xeeee29c7U, 0xb8b8d36bU, 0x14143c28U,
-    0xdede79a7U, 0x5e5ee2bcU, 0x0b0b1d16U, 0xdbdb76adU,
-    0xe0e03bdbU, 0x32325664U, 0x3a3a4e74U, 0x0a0a1e14U,
-    0x4949db92U, 0x06060a0cU, 0x24246c48U, 0x5c5ce4b8U,
-    0xc2c25d9fU, 0xd3d36ebdU, 0xacacef43U, 0x6262a6c4U,
-    0x9191a839U, 0x9595a431U, 0xe4e437d3U, 0x79798bf2U,
-    0xe7e732d5U, 0xc8c8438bU, 0x3737596eU, 0x6d6db7daU,
-    0x8d8d8c01U, 0xd5d564b1U, 0x4e4ed29cU, 0xa9a9e049U,
-    0x6c6cb4d8U, 0x5656faacU, 0xf4f407f3U, 0xeaea25cfU,
-    0x6565afcaU, 0x7a7a8ef4U, 0xaeaee947U, 0x08081810U,
-    0xbabad56fU, 0x787888f0U, 0x25256f4aU, 0x2e2e725cU,
-    0x1c1c2438U, 0xa6a6f157U, 0xb4b4c773U, 0xc6c65197U,
-    0xe8e823cbU, 0xdddd7ca1U, 0x74749ce8U, 0x1f1f213eU,
-    0x4b4bdd96U, 0xbdbddc61U, 0x8b8b860dU, 0x8a8a850fU,
-    0x707090e0U, 0x3e3e427cU, 0xb5b5c471U, 0x6666aaccU,
-    0x4848d890U, 0x03030506U, 0xf6f601f7U, 0x0e0e121cU,
-    0x6161a3c2U, 0x35355f6aU, 0x5757f9aeU, 0xb9b9d069U,
-    0x86869117U, 0xc1c15899U, 0x1d1d273aU, 0x9e9eb927U,
-    0xe1e138d9U, 0xf8f813ebU, 0x9898b32bU, 0x11113322U,
-    0x6969bbd2U, 0xd9d970a9U, 0x8e8e8907U, 0x9494a733U,
-    0x9b9bb62dU, 0x1e1e223cU, 0x87879215U, 0xe9e920c9U,
-    0xcece4987U, 0x5555ffaaU, 0x28287850U, 0xdfdf7aa5U,
-    0x8c8c8f03U, 0xa1a1f859U, 0x89898009U, 0x0d0d171aU,
-    0xbfbfda65U, 0xe6e631d7U, 0x4242c684U, 0x6868b8d0U,
-    0x4141c382U, 0x9999b029U, 0x2d2d775aU, 0x0f0f111eU,
-    0xb0b0cb7bU, 0x5454fca8U, 0xbbbbd66dU, 0x16163a2cU,
-};
-static const u32 Te4[256] = {
-    0x63636363U, 0x7c7c7c7cU, 0x77777777U, 0x7b7b7b7bU,
-    0xf2f2f2f2U, 0x6b6b6b6bU, 0x6f6f6f6fU, 0xc5c5c5c5U,
-    0x30303030U, 0x01010101U, 0x67676767U, 0x2b2b2b2bU,
-    0xfefefefeU, 0xd7d7d7d7U, 0xababababU, 0x76767676U,
-    0xcacacacaU, 0x82828282U, 0xc9c9c9c9U, 0x7d7d7d7dU,
-    0xfafafafaU, 0x59595959U, 0x47474747U, 0xf0f0f0f0U,
-    0xadadadadU, 0xd4d4d4d4U, 0xa2a2a2a2U, 0xafafafafU,
-    0x9c9c9c9cU, 0xa4a4a4a4U, 0x72727272U, 0xc0c0c0c0U,
-    0xb7b7b7b7U, 0xfdfdfdfdU, 0x93939393U, 0x26262626U,
-    0x36363636U, 0x3f3f3f3fU, 0xf7f7f7f7U, 0xccccccccU,
-    0x34343434U, 0xa5a5a5a5U, 0xe5e5e5e5U, 0xf1f1f1f1U,
-    0x71717171U, 0xd8d8d8d8U, 0x31313131U, 0x15151515U,
-    0x04040404U, 0xc7c7c7c7U, 0x23232323U, 0xc3c3c3c3U,
-    0x18181818U, 0x96969696U, 0x05050505U, 0x9a9a9a9aU,
-    0x07070707U, 0x12121212U, 0x80808080U, 0xe2e2e2e2U,
-    0xebebebebU, 0x27272727U, 0xb2b2b2b2U, 0x75757575U,
-    0x09090909U, 0x83838383U, 0x2c2c2c2cU, 0x1a1a1a1aU,
-    0x1b1b1b1bU, 0x6e6e6e6eU, 0x5a5a5a5aU, 0xa0a0a0a0U,
-    0x52525252U, 0x3b3b3b3bU, 0xd6d6d6d6U, 0xb3b3b3b3U,
-    0x29292929U, 0xe3e3e3e3U, 0x2f2f2f2fU, 0x84848484U,
-    0x53535353U, 0xd1d1d1d1U, 0x00000000U, 0xededededU,
-    0x20202020U, 0xfcfcfcfcU, 0xb1b1b1b1U, 0x5b5b5b5bU,
-    0x6a6a6a6aU, 0xcbcbcbcbU, 0xbebebebeU, 0x39393939U,
-    0x4a4a4a4aU, 0x4c4c4c4cU, 0x58585858U, 0xcfcfcfcfU,
-    0xd0d0d0d0U, 0xefefefefU, 0xaaaaaaaaU, 0xfbfbfbfbU,
-    0x43434343U, 0x4d4d4d4dU, 0x33333333U, 0x85858585U,
-    0x45454545U, 0xf9f9f9f9U, 0x02020202U, 0x7f7f7f7fU,
-    0x50505050U, 0x3c3c3c3cU, 0x9f9f9f9fU, 0xa8a8a8a8U,
-    0x51515151U, 0xa3a3a3a3U, 0x40404040U, 0x8f8f8f8fU,
-    0x92929292U, 0x9d9d9d9dU, 0x38383838U, 0xf5f5f5f5U,
-    0xbcbcbcbcU, 0xb6b6b6b6U, 0xdadadadaU, 0x21212121U,
-    0x10101010U, 0xffffffffU, 0xf3f3f3f3U, 0xd2d2d2d2U,
-    0xcdcdcdcdU, 0x0c0c0c0cU, 0x13131313U, 0xececececU,
-    0x5f5f5f5fU, 0x97979797U, 0x44444444U, 0x17171717U,
-    0xc4c4c4c4U, 0xa7a7a7a7U, 0x7e7e7e7eU, 0x3d3d3d3dU,
-    0x64646464U, 0x5d5d5d5dU, 0x19191919U, 0x73737373U,
-    0x60606060U, 0x81818181U, 0x4f4f4f4fU, 0xdcdcdcdcU,
-    0x22222222U, 0x2a2a2a2aU, 0x90909090U, 0x88888888U,
-    0x46464646U, 0xeeeeeeeeU, 0xb8b8b8b8U, 0x14141414U,
-    0xdedededeU, 0x5e5e5e5eU, 0x0b0b0b0bU, 0xdbdbdbdbU,
-    0xe0e0e0e0U, 0x32323232U, 0x3a3a3a3aU, 0x0a0a0a0aU,
-    0x49494949U, 0x06060606U, 0x24242424U, 0x5c5c5c5cU,
-    0xc2c2c2c2U, 0xd3d3d3d3U, 0xacacacacU, 0x62626262U,
-    0x91919191U, 0x95959595U, 0xe4e4e4e4U, 0x79797979U,
-    0xe7e7e7e7U, 0xc8c8c8c8U, 0x37373737U, 0x6d6d6d6dU,
-    0x8d8d8d8dU, 0xd5d5d5d5U, 0x4e4e4e4eU, 0xa9a9a9a9U,
-    0x6c6c6c6cU, 0x56565656U, 0xf4f4f4f4U, 0xeaeaeaeaU,
-    0x65656565U, 0x7a7a7a7aU, 0xaeaeaeaeU, 0x08080808U,
-    0xbabababaU, 0x78787878U, 0x25252525U, 0x2e2e2e2eU,
-    0x1c1c1c1cU, 0xa6a6a6a6U, 0xb4b4b4b4U, 0xc6c6c6c6U,
-    0xe8e8e8e8U, 0xddddddddU, 0x74747474U, 0x1f1f1f1fU,
-    0x4b4b4b4bU, 0xbdbdbdbdU, 0x8b8b8b8bU, 0x8a8a8a8aU,
-    0x70707070U, 0x3e3e3e3eU, 0xb5b5b5b5U, 0x66666666U,
-    0x48484848U, 0x03030303U, 0xf6f6f6f6U, 0x0e0e0e0eU,
-    0x61616161U, 0x35353535U, 0x57575757U, 0xb9b9b9b9U,
-    0x86868686U, 0xc1c1c1c1U, 0x1d1d1d1dU, 0x9e9e9e9eU,
-    0xe1e1e1e1U, 0xf8f8f8f8U, 0x98989898U, 0x11111111U,
-    0x69696969U, 0xd9d9d9d9U, 0x8e8e8e8eU, 0x94949494U,
-    0x9b9b9b9bU, 0x1e1e1e1eU, 0x87878787U, 0xe9e9e9e9U,
-    0xcecececeU, 0x55555555U, 0x28282828U, 0xdfdfdfdfU,
-    0x8c8c8c8cU, 0xa1a1a1a1U, 0x89898989U, 0x0d0d0d0dU,
-    0xbfbfbfbfU, 0xe6e6e6e6U, 0x42424242U, 0x68686868U,
-    0x41414141U, 0x99999999U, 0x2d2d2d2dU, 0x0f0f0f0fU,
-    0xb0b0b0b0U, 0x54545454U, 0xbbbbbbbbU, 0x16161616U,
-};
-static const u32 Td0[256] = {
-    0x51f4a750U, 0x7e416553U, 0x1a17a4c3U, 0x3a275e96U,
-    0x3bab6bcbU, 0x1f9d45f1U, 0xacfa58abU, 0x4be30393U,
-    0x2030fa55U, 0xad766df6U, 0x88cc7691U, 0xf5024c25U,
-    0x4fe5d7fcU, 0xc52acbd7U, 0x26354480U, 0xb562a38fU,
-    0xdeb15a49U, 0x25ba1b67U, 0x45ea0e98U, 0x5dfec0e1U,
-    0xc32f7502U, 0x814cf012U, 0x8d4697a3U, 0x6bd3f9c6U,
-    0x038f5fe7U, 0x15929c95U, 0xbf6d7aebU, 0x955259daU,
-    0xd4be832dU, 0x587421d3U, 0x49e06929U, 0x8ec9c844U,
-    0x75c2896aU, 0xf48e7978U, 0x99583e6bU, 0x27b971ddU,
-    0xbee14fb6U, 0xf088ad17U, 0xc920ac66U, 0x7dce3ab4U,
-    0x63df4a18U, 0xe51a3182U, 0x97513360U, 0x62537f45U,
-    0xb16477e0U, 0xbb6bae84U, 0xfe81a01cU, 0xf9082b94U,
-    0x70486858U, 0x8f45fd19U, 0x94de6c87U, 0x527bf8b7U,
-    0xab73d323U, 0x724b02e2U, 0xe31f8f57U, 0x6655ab2aU,
-    0xb2eb2807U, 0x2fb5c203U, 0x86c57b9aU, 0xd33708a5U,
-    0x302887f2U, 0x23bfa5b2U, 0x02036abaU, 0xed16825cU,
-    0x8acf1c2bU, 0xa779b492U, 0xf307f2f0U, 0x4e69e2a1U,
-    0x65daf4cdU, 0x0605bed5U, 0xd134621fU, 0xc4a6fe8aU,
-    0x342e539dU, 0xa2f355a0U, 0x058ae132U, 0xa4f6eb75U,
-    0x0b83ec39U, 0x4060efaaU, 0x5e719f06U, 0xbd6e1051U,
-    0x3e218af9U, 0x96dd063dU, 0xdd3e05aeU, 0x4de6bd46U,
-    0x91548db5U, 0x71c45d05U, 0x0406d46fU, 0x605015ffU,
-    0x1998fb24U, 0xd6bde997U, 0x894043ccU, 0x67d99e77U,
-    0xb0e842bdU, 0x07898b88U, 0xe7195b38U, 0x79c8eedbU,
-    0xa17c0a47U, 0x7c420fe9U, 0xf8841ec9U, 0x00000000U,
-    0x09808683U, 0x322bed48U, 0x1e1170acU, 0x6c5a724eU,
-    0xfd0efffbU, 0x0f853856U, 0x3daed51eU, 0x362d3927U,
-    0x0a0fd964U, 0x685ca621U, 0x9b5b54d1U, 0x24362e3aU,
-    0x0c0a67b1U, 0x9357e70fU, 0xb4ee96d2U, 0x1b9b919eU,
-    0x80c0c54fU, 0x61dc20a2U, 0x5a774b69U, 0x1c121a16U,
-    0xe293ba0aU, 0xc0a02ae5U, 0x3c22e043U, 0x121b171dU,
-    0x0e090d0bU, 0xf28bc7adU, 0x2db6a8b9U, 0x141ea9c8U,
-    0x57f11985U, 0xaf75074cU, 0xee99ddbbU, 0xa37f60fdU,
-    0xf701269fU, 0x5c72f5bcU, 0x44663bc5U, 0x5bfb7e34U,
-    0x8b432976U, 0xcb23c6dcU, 0xb6edfc68U, 0xb8e4f163U,
-    0xd731dccaU, 0x42638510U, 0x13972240U, 0x84c61120U,
-    0x854a247dU, 0xd2bb3df8U, 0xaef93211U, 0xc729a16dU,
-    0x1d9e2f4bU, 0xdcb230f3U, 0x0d8652ecU, 0x77c1e3d0U,
-    0x2bb3166cU, 0xa970b999U, 0x119448faU, 0x47e96422U,
-    0xa8fc8cc4U, 0xa0f03f1aU, 0x567d2cd8U, 0x223390efU,
-    0x87494ec7U, 0xd938d1c1U, 0x8ccaa2feU, 0x98d40b36U,
-    0xa6f581cfU, 0xa57ade28U, 0xdab78e26U, 0x3fadbfa4U,
-    0x2c3a9de4U, 0x5078920dU, 0x6a5fcc9bU, 0x547e4662U,
-    0xf68d13c2U, 0x90d8b8e8U, 0x2e39f75eU, 0x82c3aff5U,
-    0x9f5d80beU, 0x69d0937cU, 0x6fd52da9U, 0xcf2512b3U,
-    0xc8ac993bU, 0x10187da7U, 0xe89c636eU, 0xdb3bbb7bU,
-    0xcd267809U, 0x6e5918f4U, 0xec9ab701U, 0x834f9aa8U,
-    0xe6956e65U, 0xaaffe67eU, 0x21bccf08U, 0xef15e8e6U,
-    0xbae79bd9U, 0x4a6f36ceU, 0xea9f09d4U, 0x29b07cd6U,
-    0x31a4b2afU, 0x2a3f2331U, 0xc6a59430U, 0x35a266c0U,
-    0x744ebc37U, 0xfc82caa6U, 0xe090d0b0U, 0x33a7d815U,
-    0xf104984aU, 0x41ecdaf7U, 0x7fcd500eU, 0x1791f62fU,
-    0x764dd68dU, 0x43efb04dU, 0xccaa4d54U, 0xe49604dfU,
-    0x9ed1b5e3U, 0x4c6a881bU, 0xc12c1fb8U, 0x4665517fU,
-    0x9d5eea04U, 0x018c355dU, 0xfa877473U, 0xfb0b412eU,
-    0xb3671d5aU, 0x92dbd252U, 0xe9105633U, 0x6dd64713U,
-    0x9ad7618cU, 0x37a10c7aU, 0x59f8148eU, 0xeb133c89U,
-    0xcea927eeU, 0xb761c935U, 0xe11ce5edU, 0x7a47b13cU,
-    0x9cd2df59U, 0x55f2733fU, 0x1814ce79U, 0x73c737bfU,
-    0x53f7cdeaU, 0x5ffdaa5bU, 0xdf3d6f14U, 0x7844db86U,
-    0xcaaff381U, 0xb968c43eU, 0x3824342cU, 0xc2a3405fU,
-    0x161dc372U, 0xbce2250cU, 0x283c498bU, 0xff0d9541U,
-    0x39a80171U, 0x080cb3deU, 0xd8b4e49cU, 0x6456c190U,
-    0x7bcb8461U, 0xd532b670U, 0x486c5c74U, 0xd0b85742U,
-};
-static const u32 Td1[256] = {
-    0x5051f4a7U, 0x537e4165U, 0xc31a17a4U, 0x963a275eU,
-    0xcb3bab6bU, 0xf11f9d45U, 0xabacfa58U, 0x934be303U,
-    0x552030faU, 0xf6ad766dU, 0x9188cc76U, 0x25f5024cU,
-    0xfc4fe5d7U, 0xd7c52acbU, 0x80263544U, 0x8fb562a3U,
-    0x49deb15aU, 0x6725ba1bU, 0x9845ea0eU, 0xe15dfec0U,
-    0x02c32f75U, 0x12814cf0U, 0xa38d4697U, 0xc66bd3f9U,
-    0xe7038f5fU, 0x9515929cU, 0xebbf6d7aU, 0xda955259U,
-    0x2dd4be83U, 0xd3587421U, 0x2949e069U, 0x448ec9c8U,
-    0x6a75c289U, 0x78f48e79U, 0x6b99583eU, 0xdd27b971U,
-    0xb6bee14fU, 0x17f088adU, 0x66c920acU, 0xb47dce3aU,
-    0x1863df4aU, 0x82e51a31U, 0x60975133U, 0x4562537fU,
-    0xe0b16477U, 0x84bb6baeU, 0x1cfe81a0U, 0x94f9082bU,
-    0x58704868U, 0x198f45fdU, 0x8794de6cU, 0xb7527bf8U,
-    0x23ab73d3U, 0xe2724b02U, 0x57e31f8fU, 0x2a6655abU,
-    0x07b2eb28U, 0x032fb5c2U, 0x9a86c57bU, 0xa5d33708U,
-    0xf2302887U, 0xb223bfa5U, 0xba02036aU, 0x5ced1682U,
-    0x2b8acf1cU, 0x92a779b4U, 0xf0f307f2U, 0xa14e69e2U,
-    0xcd65daf4U, 0xd50605beU, 0x1fd13462U, 0x8ac4a6feU,
-    0x9d342e53U, 0xa0a2f355U, 0x32058ae1U, 0x75a4f6ebU,
-    0x390b83ecU, 0xaa4060efU, 0x065e719fU, 0x51bd6e10U,
-    0xf93e218aU, 0x3d96dd06U, 0xaedd3e05U, 0x464de6bdU,
-    0xb591548dU, 0x0571c45dU, 0x6f0406d4U, 0xff605015U,
-    0x241998fbU, 0x97d6bde9U, 0xcc894043U, 0x7767d99eU,
-    0xbdb0e842U, 0x8807898bU, 0x38e7195bU, 0xdb79c8eeU,
-    0x47a17c0aU, 0xe97c420fU, 0xc9f8841eU, 0x00000000U,
-    0x83098086U, 0x48322bedU, 0xac1e1170U, 0x4e6c5a72U,
-    0xfbfd0effU, 0x560f8538U, 0x1e3daed5U, 0x27362d39U,
-    0x640a0fd9U, 0x21685ca6U, 0xd19b5b54U, 0x3a24362eU,
-    0xb10c0a67U, 0x0f9357e7U, 0xd2b4ee96U, 0x9e1b9b91U,
-    0x4f80c0c5U, 0xa261dc20U, 0x695a774bU, 0x161c121aU,
-    0x0ae293baU, 0xe5c0a02aU, 0x433c22e0U, 0x1d121b17U,
-    0x0b0e090dU, 0xadf28bc7U, 0xb92db6a8U, 0xc8141ea9U,
-    0x8557f119U, 0x4caf7507U, 0xbbee99ddU, 0xfda37f60U,
-    0x9ff70126U, 0xbc5c72f5U, 0xc544663bU, 0x345bfb7eU,
-    0x768b4329U, 0xdccb23c6U, 0x68b6edfcU, 0x63b8e4f1U,
-    0xcad731dcU, 0x10426385U, 0x40139722U, 0x2084c611U,
-    0x7d854a24U, 0xf8d2bb3dU, 0x11aef932U, 0x6dc729a1U,
-    0x4b1d9e2fU, 0xf3dcb230U, 0xec0d8652U, 0xd077c1e3U,
-    0x6c2bb316U, 0x99a970b9U, 0xfa119448U, 0x2247e964U,
-    0xc4a8fc8cU, 0x1aa0f03fU, 0xd8567d2cU, 0xef223390U,
-    0xc787494eU, 0xc1d938d1U, 0xfe8ccaa2U, 0x3698d40bU,
-    0xcfa6f581U, 0x28a57adeU, 0x26dab78eU, 0xa43fadbfU,
-    0xe42c3a9dU, 0x0d507892U, 0x9b6a5fccU, 0x62547e46U,
-    0xc2f68d13U, 0xe890d8b8U, 0x5e2e39f7U, 0xf582c3afU,
-    0xbe9f5d80U, 0x7c69d093U, 0xa96fd52dU, 0xb3cf2512U,
-    0x3bc8ac99U, 0xa710187dU, 0x6ee89c63U, 0x7bdb3bbbU,
-    0x09cd2678U, 0xf46e5918U, 0x01ec9ab7U, 0xa8834f9aU,
-    0x65e6956eU, 0x7eaaffe6U, 0x0821bccfU, 0xe6ef15e8U,
-    0xd9bae79bU, 0xce4a6f36U, 0xd4ea9f09U, 0xd629b07cU,
-    0xaf31a4b2U, 0x312a3f23U, 0x30c6a594U, 0xc035a266U,
-    0x37744ebcU, 0xa6fc82caU, 0xb0e090d0U, 0x1533a7d8U,
-    0x4af10498U, 0xf741ecdaU, 0x0e7fcd50U, 0x2f1791f6U,
-    0x8d764dd6U, 0x4d43efb0U, 0x54ccaa4dU, 0xdfe49604U,
-    0xe39ed1b5U, 0x1b4c6a88U, 0xb8c12c1fU, 0x7f466551U,
-    0x049d5eeaU, 0x5d018c35U, 0x73fa8774U, 0x2efb0b41U,
-    0x5ab3671dU, 0x5292dbd2U, 0x33e91056U, 0x136dd647U,
-    0x8c9ad761U, 0x7a37a10cU, 0x8e59f814U, 0x89eb133cU,
-    0xeecea927U, 0x35b761c9U, 0xede11ce5U, 0x3c7a47b1U,
-    0x599cd2dfU, 0x3f55f273U, 0x791814ceU, 0xbf73c737U,
-    0xea53f7cdU, 0x5b5ffdaaU, 0x14df3d6fU, 0x867844dbU,
-    0x81caaff3U, 0x3eb968c4U, 0x2c382434U, 0x5fc2a340U,
-    0x72161dc3U, 0x0cbce225U, 0x8b283c49U, 0x41ff0d95U,
-    0x7139a801U, 0xde080cb3U, 0x9cd8b4e4U, 0x906456c1U,
-    0x617bcb84U, 0x70d532b6U, 0x74486c5cU, 0x42d0b857U,
-};
-static const u32 Td2[256] = {
-    0xa75051f4U, 0x65537e41U, 0xa4c31a17U, 0x5e963a27U,
-    0x6bcb3babU, 0x45f11f9dU, 0x58abacfaU, 0x03934be3U,
-    0xfa552030U, 0x6df6ad76U, 0x769188ccU, 0x4c25f502U,
-    0xd7fc4fe5U, 0xcbd7c52aU, 0x44802635U, 0xa38fb562U,
-    0x5a49deb1U, 0x1b6725baU, 0x0e9845eaU, 0xc0e15dfeU,
-    0x7502c32fU, 0xf012814cU, 0x97a38d46U, 0xf9c66bd3U,
-    0x5fe7038fU, 0x9c951592U, 0x7aebbf6dU, 0x59da9552U,
-    0x832dd4beU, 0x21d35874U, 0x692949e0U, 0xc8448ec9U,
-    0x896a75c2U, 0x7978f48eU, 0x3e6b9958U, 0x71dd27b9U,
-    0x4fb6bee1U, 0xad17f088U, 0xac66c920U, 0x3ab47dceU,
-    0x4a1863dfU, 0x3182e51aU, 0x33609751U, 0x7f456253U,
-    0x77e0b164U, 0xae84bb6bU, 0xa01cfe81U, 0x2b94f908U,
-    0x68587048U, 0xfd198f45U, 0x6c8794deU, 0xf8b7527bU,
-    0xd323ab73U, 0x02e2724bU, 0x8f57e31fU, 0xab2a6655U,
-    0x2807b2ebU, 0xc2032fb5U, 0x7b9a86c5U, 0x08a5d337U,
-    0x87f23028U, 0xa5b223bfU, 0x6aba0203U, 0x825ced16U,
-    0x1c2b8acfU, 0xb492a779U, 0xf2f0f307U, 0xe2a14e69U,
-    0xf4cd65daU, 0xbed50605U, 0x621fd134U, 0xfe8ac4a6U,
-    0x539d342eU, 0x55a0a2f3U, 0xe132058aU, 0xeb75a4f6U,
-    0xec390b83U, 0xefaa4060U, 0x9f065e71U, 0x1051bd6eU,
-
-    0x8af93e21U, 0x063d96ddU, 0x05aedd3eU, 0xbd464de6U,
-    0x8db59154U, 0x5d0571c4U, 0xd46f0406U, 0x15ff6050U,
-    0xfb241998U, 0xe997d6bdU, 0x43cc8940U, 0x9e7767d9U,
-    0x42bdb0e8U, 0x8b880789U, 0x5b38e719U, 0xeedb79c8U,
-    0x0a47a17cU, 0x0fe97c42U, 0x1ec9f884U, 0x00000000U,
-    0x86830980U, 0xed48322bU, 0x70ac1e11U, 0x724e6c5aU,
-    0xfffbfd0eU, 0x38560f85U, 0xd51e3daeU, 0x3927362dU,
-    0xd9640a0fU, 0xa621685cU, 0x54d19b5bU, 0x2e3a2436U,
-    0x67b10c0aU, 0xe70f9357U, 0x96d2b4eeU, 0x919e1b9bU,
-    0xc54f80c0U, 0x20a261dcU, 0x4b695a77U, 0x1a161c12U,
-    0xba0ae293U, 0x2ae5c0a0U, 0xe0433c22U, 0x171d121bU,
-    0x0d0b0e09U, 0xc7adf28bU, 0xa8b92db6U, 0xa9c8141eU,
-    0x198557f1U, 0x074caf75U, 0xddbbee99U, 0x60fda37fU,
-    0x269ff701U, 0xf5bc5c72U, 0x3bc54466U, 0x7e345bfbU,
-    0x29768b43U, 0xc6dccb23U, 0xfc68b6edU, 0xf163b8e4U,
-    0xdccad731U, 0x85104263U, 0x22401397U, 0x112084c6U,
-    0x247d854aU, 0x3df8d2bbU, 0x3211aef9U, 0xa16dc729U,
-    0x2f4b1d9eU, 0x30f3dcb2U, 0x52ec0d86U, 0xe3d077c1U,
-    0x166c2bb3U, 0xb999a970U, 0x48fa1194U, 0x642247e9U,
-    0x8cc4a8fcU, 0x3f1aa0f0U, 0x2cd8567dU, 0x90ef2233U,
-    0x4ec78749U, 0xd1c1d938U, 0xa2fe8ccaU, 0x0b3698d4U,
-    0x81cfa6f5U, 0xde28a57aU, 0x8e26dab7U, 0xbfa43fadU,
-    0x9de42c3aU, 0x920d5078U, 0xcc9b6a5fU, 0x4662547eU,
-    0x13c2f68dU, 0xb8e890d8U, 0xf75e2e39U, 0xaff582c3U,
-    0x80be9f5dU, 0x937c69d0U, 0x2da96fd5U, 0x12b3cf25U,
-    0x993bc8acU, 0x7da71018U, 0x636ee89cU, 0xbb7bdb3bU,
-    0x7809cd26U, 0x18f46e59U, 0xb701ec9aU, 0x9aa8834fU,
-    0x6e65e695U, 0xe67eaaffU, 0xcf0821bcU, 0xe8e6ef15U,
-    0x9bd9bae7U, 0x36ce4a6fU, 0x09d4ea9fU, 0x7cd629b0U,
-    0xb2af31a4U, 0x23312a3fU, 0x9430c6a5U, 0x66c035a2U,
-    0xbc37744eU, 0xcaa6fc82U, 0xd0b0e090U, 0xd81533a7U,
-    0x984af104U, 0xdaf741ecU, 0x500e7fcdU, 0xf62f1791U,
-    0xd68d764dU, 0xb04d43efU, 0x4d54ccaaU, 0x04dfe496U,
-    0xb5e39ed1U, 0x881b4c6aU, 0x1fb8c12cU, 0x517f4665U,
-    0xea049d5eU, 0x355d018cU, 0x7473fa87U, 0x412efb0bU,
-    0x1d5ab367U, 0xd25292dbU, 0x5633e910U, 0x47136dd6U,
-    0x618c9ad7U, 0x0c7a37a1U, 0x148e59f8U, 0x3c89eb13U,
-    0x27eecea9U, 0xc935b761U, 0xe5ede11cU, 0xb13c7a47U,
-    0xdf599cd2U, 0x733f55f2U, 0xce791814U, 0x37bf73c7U,
-    0xcdea53f7U, 0xaa5b5ffdU, 0x6f14df3dU, 0xdb867844U,
-    0xf381caafU, 0xc43eb968U, 0x342c3824U, 0x405fc2a3U,
-    0xc372161dU, 0x250cbce2U, 0x498b283cU, 0x9541ff0dU,
-    0x017139a8U, 0xb3de080cU, 0xe49cd8b4U, 0xc1906456U,
-    0x84617bcbU, 0xb670d532U, 0x5c74486cU, 0x5742d0b8U,
-};
-static const u32 Td3[256] = {
-    0xf4a75051U, 0x4165537eU, 0x17a4c31aU, 0x275e963aU,
-    0xab6bcb3bU, 0x9d45f11fU, 0xfa58abacU, 0xe303934bU,
-    0x30fa5520U, 0x766df6adU, 0xcc769188U, 0x024c25f5U,
-    0xe5d7fc4fU, 0x2acbd7c5U, 0x35448026U, 0x62a38fb5U,
-    0xb15a49deU, 0xba1b6725U, 0xea0e9845U, 0xfec0e15dU,
-    0x2f7502c3U, 0x4cf01281U, 0x4697a38dU, 0xd3f9c66bU,
-    0x8f5fe703U, 0x929c9515U, 0x6d7aebbfU, 0x5259da95U,
-    0xbe832dd4U, 0x7421d358U, 0xe0692949U, 0xc9c8448eU,
-    0xc2896a75U, 0x8e7978f4U, 0x583e6b99U, 0xb971dd27U,
-    0xe14fb6beU, 0x88ad17f0U, 0x20ac66c9U, 0xce3ab47dU,
-    0xdf4a1863U, 0x1a3182e5U, 0x51336097U, 0x537f4562U,
-    0x6477e0b1U, 0x6bae84bbU, 0x81a01cfeU, 0x082b94f9U,
-    0x48685870U, 0x45fd198fU, 0xde6c8794U, 0x7bf8b752U,
-    0x73d323abU, 0x4b02e272U, 0x1f8f57e3U, 0x55ab2a66U,
-    0xeb2807b2U, 0xb5c2032fU, 0xc57b9a86U, 0x3708a5d3U,
-    0x2887f230U, 0xbfa5b223U, 0x036aba02U, 0x16825cedU,
-    0xcf1c2b8aU, 0x79b492a7U, 0x07f2f0f3U, 0x69e2a14eU,
-    0xdaf4cd65U, 0x05bed506U, 0x34621fd1U, 0xa6fe8ac4U,
-    0x2e539d34U, 0xf355a0a2U, 0x8ae13205U, 0xf6eb75a4U,
-    0x83ec390bU, 0x60efaa40U, 0x719f065eU, 0x6e1051bdU,
-    0x218af93eU, 0xdd063d96U, 0x3e05aeddU, 0xe6bd464dU,
-    0x548db591U, 0xc45d0571U, 0x06d46f04U, 0x5015ff60U,
-    0x98fb2419U, 0xbde997d6U, 0x4043cc89U, 0xd99e7767U,
-    0xe842bdb0U, 0x898b8807U, 0x195b38e7U, 0xc8eedb79U,
-    0x7c0a47a1U, 0x420fe97cU, 0x841ec9f8U, 0x00000000U,
-    0x80868309U, 0x2bed4832U, 0x1170ac1eU, 0x5a724e6cU,
-    0x0efffbfdU, 0x8538560fU, 0xaed51e3dU, 0x2d392736U,
-    0x0fd9640aU, 0x5ca62168U, 0x5b54d19bU, 0x362e3a24U,
-    0x0a67b10cU, 0x57e70f93U, 0xee96d2b4U, 0x9b919e1bU,
-    0xc0c54f80U, 0xdc20a261U, 0x774b695aU, 0x121a161cU,
-    0x93ba0ae2U, 0xa02ae5c0U, 0x22e0433cU, 0x1b171d12U,
-    0x090d0b0eU, 0x8bc7adf2U, 0xb6a8b92dU, 0x1ea9c814U,
-    0xf1198557U, 0x75074cafU, 0x99ddbbeeU, 0x7f60fda3U,
-    0x01269ff7U, 0x72f5bc5cU, 0x663bc544U, 0xfb7e345bU,
-    0x4329768bU, 0x23c6dccbU, 0xedfc68b6U, 0xe4f163b8U,
-    0x31dccad7U, 0x63851042U, 0x97224013U, 0xc6112084U,
-    0x4a247d85U, 0xbb3df8d2U, 0xf93211aeU, 0x29a16dc7U,
-    0x9e2f4b1dU, 0xb230f3dcU, 0x8652ec0dU, 0xc1e3d077U,
-    0xb3166c2bU, 0x70b999a9U, 0x9448fa11U, 0xe9642247U,
-    0xfc8cc4a8U, 0xf03f1aa0U, 0x7d2cd856U, 0x3390ef22U,
-    0x494ec787U, 0x38d1c1d9U, 0xcaa2fe8cU, 0xd40b3698U,
-    0xf581cfa6U, 0x7ade28a5U, 0xb78e26daU, 0xadbfa43fU,
-    0x3a9de42cU, 0x78920d50U, 0x5fcc9b6aU, 0x7e466254U,
-    0x8d13c2f6U, 0xd8b8e890U, 0x39f75e2eU, 0xc3aff582U,
-    0x5d80be9fU, 0xd0937c69U, 0xd52da96fU, 0x2512b3cfU,
-    0xac993bc8U, 0x187da710U, 0x9c636ee8U, 0x3bbb7bdbU,
-    0x267809cdU, 0x5918f46eU, 0x9ab701ecU, 0x4f9aa883U,
-    0x956e65e6U, 0xffe67eaaU, 0xbccf0821U, 0x15e8e6efU,
-    0xe79bd9baU, 0x6f36ce4aU, 0x9f09d4eaU, 0xb07cd629U,
-    0xa4b2af31U, 0x3f23312aU, 0xa59430c6U, 0xa266c035U,
-    0x4ebc3774U, 0x82caa6fcU, 0x90d0b0e0U, 0xa7d81533U,
-    0x04984af1U, 0xecdaf741U, 0xcd500e7fU, 0x91f62f17U,
-    0x4dd68d76U, 0xefb04d43U, 0xaa4d54ccU, 0x9604dfe4U,
-    0xd1b5e39eU, 0x6a881b4cU, 0x2c1fb8c1U, 0x65517f46U,
-    0x5eea049dU, 0x8c355d01U, 0x877473faU, 0x0b412efbU,
-    0x671d5ab3U, 0xdbd25292U, 0x105633e9U, 0xd647136dU,
-    0xd7618c9aU, 0xa10c7a37U, 0xf8148e59U, 0x133c89ebU,
-    0xa927eeceU, 0x61c935b7U, 0x1ce5ede1U, 0x47b13c7aU,
-    0xd2df599cU, 0xf2733f55U, 0x14ce7918U, 0xc737bf73U,
-    0xf7cdea53U, 0xfdaa5b5fU, 0x3d6f14dfU, 0x44db8678U,
-    0xaff381caU, 0x68c43eb9U, 0x24342c38U, 0xa3405fc2U,
-    0x1dc37216U, 0xe2250cbcU, 0x3c498b28U, 0x0d9541ffU,
-    0xa8017139U, 0x0cb3de08U, 0xb4e49cd8U, 0x56c19064U,
-    0xcb84617bU, 0x32b670d5U, 0x6c5c7448U, 0xb85742d0U,
-};
-static const u32 Td4[256] = {
-    0x52525252U, 0x09090909U, 0x6a6a6a6aU, 0xd5d5d5d5U,
-    0x30303030U, 0x36363636U, 0xa5a5a5a5U, 0x38383838U,
-    0xbfbfbfbfU, 0x40404040U, 0xa3a3a3a3U, 0x9e9e9e9eU,
-    0x81818181U, 0xf3f3f3f3U, 0xd7d7d7d7U, 0xfbfbfbfbU,
-    0x7c7c7c7cU, 0xe3e3e3e3U, 0x39393939U, 0x82828282U,
-    0x9b9b9b9bU, 0x2f2f2f2fU, 0xffffffffU, 0x87878787U,
-    0x34343434U, 0x8e8e8e8eU, 0x43434343U, 0x44444444U,
-    0xc4c4c4c4U, 0xdedededeU, 0xe9e9e9e9U, 0xcbcbcbcbU,
-    0x54545454U, 0x7b7b7b7bU, 0x94949494U, 0x32323232U,
-    0xa6a6a6a6U, 0xc2c2c2c2U, 0x23232323U, 0x3d3d3d3dU,
-    0xeeeeeeeeU, 0x4c4c4c4cU, 0x95959595U, 0x0b0b0b0bU,
-    0x42424242U, 0xfafafafaU, 0xc3c3c3c3U, 0x4e4e4e4eU,
-    0x08080808U, 0x2e2e2e2eU, 0xa1a1a1a1U, 0x66666666U,
-    0x28282828U, 0xd9d9d9d9U, 0x24242424U, 0xb2b2b2b2U,
-    0x76767676U, 0x5b5b5b5bU, 0xa2a2a2a2U, 0x49494949U,
-    0x6d6d6d6dU, 0x8b8b8b8bU, 0xd1d1d1d1U, 0x25252525U,
-    0x72727272U, 0xf8f8f8f8U, 0xf6f6f6f6U, 0x64646464U,
-    0x86868686U, 0x68686868U, 0x98989898U, 0x16161616U,
-    0xd4d4d4d4U, 0xa4a4a4a4U, 0x5c5c5c5cU, 0xccccccccU,
-    0x5d5d5d5dU, 0x65656565U, 0xb6b6b6b6U, 0x92929292U,
-    0x6c6c6c6cU, 0x70707070U, 0x48484848U, 0x50505050U,
-    0xfdfdfdfdU, 0xededededU, 0xb9b9b9b9U, 0xdadadadaU,
-    0x5e5e5e5eU, 0x15151515U, 0x46464646U, 0x57575757U,
-    0xa7a7a7a7U, 0x8d8d8d8dU, 0x9d9d9d9dU, 0x84848484U,
-    0x90909090U, 0xd8d8d8d8U, 0xababababU, 0x00000000U,
-    0x8c8c8c8cU, 0xbcbcbcbcU, 0xd3d3d3d3U, 0x0a0a0a0aU,
-    0xf7f7f7f7U, 0xe4e4e4e4U, 0x58585858U, 0x05050505U,
-    0xb8b8b8b8U, 0xb3b3b3b3U, 0x45454545U, 0x06060606U,
-    0xd0d0d0d0U, 0x2c2c2c2cU, 0x1e1e1e1eU, 0x8f8f8f8fU,
-    0xcacacacaU, 0x3f3f3f3fU, 0x0f0f0f0fU, 0x02020202U,
-    0xc1c1c1c1U, 0xafafafafU, 0xbdbdbdbdU, 0x03030303U,
-    0x01010101U, 0x13131313U, 0x8a8a8a8aU, 0x6b6b6b6bU,
-    0x3a3a3a3aU, 0x91919191U, 0x11111111U, 0x41414141U,
-    0x4f4f4f4fU, 0x67676767U, 0xdcdcdcdcU, 0xeaeaeaeaU,
-    0x97979797U, 0xf2f2f2f2U, 0xcfcfcfcfU, 0xcecececeU,
-    0xf0f0f0f0U, 0xb4b4b4b4U, 0xe6e6e6e6U, 0x73737373U,
-    0x96969696U, 0xacacacacU, 0x74747474U, 0x22222222U,
-    0xe7e7e7e7U, 0xadadadadU, 0x35353535U, 0x85858585U,
-    0xe2e2e2e2U, 0xf9f9f9f9U, 0x37373737U, 0xe8e8e8e8U,
-    0x1c1c1c1cU, 0x75757575U, 0xdfdfdfdfU, 0x6e6e6e6eU,
-    0x47474747U, 0xf1f1f1f1U, 0x1a1a1a1aU, 0x71717171U,
-    0x1d1d1d1dU, 0x29292929U, 0xc5c5c5c5U, 0x89898989U,
-    0x6f6f6f6fU, 0xb7b7b7b7U, 0x62626262U, 0x0e0e0e0eU,
-    0xaaaaaaaaU, 0x18181818U, 0xbebebebeU, 0x1b1b1b1bU,
-    0xfcfcfcfcU, 0x56565656U, 0x3e3e3e3eU, 0x4b4b4b4bU,
-    0xc6c6c6c6U, 0xd2d2d2d2U, 0x79797979U, 0x20202020U,
-    0x9a9a9a9aU, 0xdbdbdbdbU, 0xc0c0c0c0U, 0xfefefefeU,
-    0x78787878U, 0xcdcdcdcdU, 0x5a5a5a5aU, 0xf4f4f4f4U,
-    0x1f1f1f1fU, 0xddddddddU, 0xa8a8a8a8U, 0x33333333U,
-    0x88888888U, 0x07070707U, 0xc7c7c7c7U, 0x31313131U,
-    0xb1b1b1b1U, 0x12121212U, 0x10101010U, 0x59595959U,
-    0x27272727U, 0x80808080U, 0xececececU, 0x5f5f5f5fU,
-    0x60606060U, 0x51515151U, 0x7f7f7f7fU, 0xa9a9a9a9U,
-    0x19191919U, 0xb5b5b5b5U, 0x4a4a4a4aU, 0x0d0d0d0dU,
-    0x2d2d2d2dU, 0xe5e5e5e5U, 0x7a7a7a7aU, 0x9f9f9f9fU,
-    0x93939393U, 0xc9c9c9c9U, 0x9c9c9c9cU, 0xefefefefU,
-    0xa0a0a0a0U, 0xe0e0e0e0U, 0x3b3b3b3bU, 0x4d4d4d4dU,
-    0xaeaeaeaeU, 0x2a2a2a2aU, 0xf5f5f5f5U, 0xb0b0b0b0U,
-    0xc8c8c8c8U, 0xebebebebU, 0xbbbbbbbbU, 0x3c3c3c3cU,
-    0x83838383U, 0x53535353U, 0x99999999U, 0x61616161U,
-    0x17171717U, 0x2b2b2b2bU, 0x04040404U, 0x7e7e7e7eU,
-    0xbabababaU, 0x77777777U, 0xd6d6d6d6U, 0x26262626U,
-    0xe1e1e1e1U, 0x69696969U, 0x14141414U, 0x63636363U,
-    0x55555555U, 0x21212121U, 0x0c0c0c0cU, 0x7d7d7d7dU,
-};
-static const u32 rcon[] = {
-	0x01000000, 0x02000000, 0x04000000, 0x08000000,
-	0x10000000, 0x20000000, 0x40000000, 0x80000000,
-	0x1B000000, 0x36000000, /* for 128-bit blocks, Rijndael never uses more than 10 rcon values */
-};
-
-/**
- * Expand the cipher key into the encryption key schedule.
- */
-int AES_set_encrypt_key(const unsigned char *userKey, const int bits,
-			AES_KEY *key) {
-
-	u32 *rk;
-   	int i = 0;
-	u32 temp;
-
-	if (!userKey || !key)
-		return -1;
-	if (bits != 128 && bits != 192 && bits != 256)
-		return -2;
-
-	rk = key->rd_key;
-
-	if (bits==128)
-		key->rounds = 10;
-	else if (bits==192)
-		key->rounds = 12;
-	else
-		key->rounds = 14;
-
-	rk[0] = GETU32(userKey     );
-	rk[1] = GETU32(userKey +  4);
-	rk[2] = GETU32(userKey +  8);
-	rk[3] = GETU32(userKey + 12);
-	if (bits == 128) {
-		while (1) {
-			temp  = rk[3];
-			rk[4] = rk[0] ^
-				(Te4[(temp >> 16) & 0xff] & 0xff000000) ^
-				(Te4[(temp >>  8) & 0xff] & 0x00ff0000) ^
-				(Te4[(temp      ) & 0xff] & 0x0000ff00) ^
-				(Te4[(temp >> 24)       ] & 0x000000ff) ^
-				rcon[i];
-			rk[5] = rk[1] ^ rk[4];
-			rk[6] = rk[2] ^ rk[5];
-			rk[7] = rk[3] ^ rk[6];
-			if (++i == 10) {
-				return 0;
-			}
-			rk += 4;
-		}
-	}
-	rk[4] = GETU32(userKey + 16);
-	rk[5] = GETU32(userKey + 20);
-	if (bits == 192) {
-		while (1) {
-			temp = rk[ 5];
-			rk[ 6] = rk[ 0] ^
-				(Te4[(temp >> 16) & 0xff] & 0xff000000) ^
-				(Te4[(temp >>  8) & 0xff] & 0x00ff0000) ^
-				(Te4[(temp      ) & 0xff] & 0x0000ff00) ^
-				(Te4[(temp >> 24)       ] & 0x000000ff) ^
-				rcon[i];
-			rk[ 7] = rk[ 1] ^ rk[ 6];
-			rk[ 8] = rk[ 2] ^ rk[ 7];
-			rk[ 9] = rk[ 3] ^ rk[ 8];
-			if (++i == 8) {
-				return 0;
-			}
-			rk[10] = rk[ 4] ^ rk[ 9];
-			rk[11] = rk[ 5] ^ rk[10];
-			rk += 6;
-		}
-	}
-	rk[6] = GETU32(userKey + 24);
-	rk[7] = GETU32(userKey + 28);
-	if (bits == 256) {
-		while (1) {
-			temp = rk[ 7];
-			rk[ 8] = rk[ 0] ^
-				(Te4[(temp >> 16) & 0xff] & 0xff000000) ^
-				(Te4[(temp >>  8) & 0xff] & 0x00ff0000) ^
-				(Te4[(temp      ) & 0xff] & 0x0000ff00) ^
-				(Te4[(temp >> 24)       ] & 0x000000ff) ^
-				rcon[i];
-			rk[ 9] = rk[ 1] ^ rk[ 8];
-			rk[10] = rk[ 2] ^ rk[ 9];
-			rk[11] = rk[ 3] ^ rk[10];
-			if (++i == 7) {
-				return 0;
-			}
-			temp = rk[11];
-			rk[12] = rk[ 4] ^
-				(Te4[(temp >> 24)       ] & 0xff000000) ^
-				(Te4[(temp >> 16) & 0xff] & 0x00ff0000) ^
-				(Te4[(temp >>  8) & 0xff] & 0x0000ff00) ^
-				(Te4[(temp      ) & 0xff] & 0x000000ff);
-			rk[13] = rk[ 5] ^ rk[12];
-			rk[14] = rk[ 6] ^ rk[13];
-			rk[15] = rk[ 7] ^ rk[14];
-
-			rk += 8;
-        	}
-	}
-	return 0;
-}
-
-/**
- * Expand the cipher key into the decryption key schedule.
- */
-int AES_set_decrypt_key(const unsigned char *userKey, const int bits,
-			 AES_KEY *key) {
-
-        u32 *rk;
-	int i, j, status;
-	u32 temp;
-
-	/* first, start with an encryption schedule */
-	status = AES_set_encrypt_key(userKey, bits, key);
-	if (status < 0)
-		return status;
-
-	rk = key->rd_key;
-
-	/* invert the order of the round keys: */
-	for (i = 0, j = 4*(key->rounds); i < j; i += 4, j -= 4) {
-		temp = rk[i    ]; rk[i    ] = rk[j    ]; rk[j    ] = temp;
-		temp = rk[i + 1]; rk[i + 1] = rk[j + 1]; rk[j + 1] = temp;
-		temp = rk[i + 2]; rk[i + 2] = rk[j + 2]; rk[j + 2] = temp;
-		temp = rk[i + 3]; rk[i + 3] = rk[j + 3]; rk[j + 3] = temp;
-	}
-	/* apply the inverse MixColumn transform to all round keys but the first and the last: */
-	for (i = 1; i < (key->rounds); i++) {
-		rk += 4;
-		rk[0] =
-			Td0[Te4[(rk[0] >> 24)       ] & 0xff] ^
-			Td1[Te4[(rk[0] >> 16) & 0xff] & 0xff] ^
-			Td2[Te4[(rk[0] >>  8) & 0xff] & 0xff] ^
-			Td3[Te4[(rk[0]      ) & 0xff] & 0xff];
-		rk[1] =
-			Td0[Te4[(rk[1] >> 24)       ] & 0xff] ^
-			Td1[Te4[(rk[1] >> 16) & 0xff] & 0xff] ^
-			Td2[Te4[(rk[1] >>  8) & 0xff] & 0xff] ^
-			Td3[Te4[(rk[1]      ) & 0xff] & 0xff];
-		rk[2] =
-			Td0[Te4[(rk[2] >> 24)       ] & 0xff] ^
-			Td1[Te4[(rk[2] >> 16) & 0xff] & 0xff] ^
-			Td2[Te4[(rk[2] >>  8) & 0xff] & 0xff] ^
-			Td3[Te4[(rk[2]      ) & 0xff] & 0xff];
-		rk[3] =
-			Td0[Te4[(rk[3] >> 24)       ] & 0xff] ^
-			Td1[Te4[(rk[3] >> 16) & 0xff] & 0xff] ^
-			Td2[Te4[(rk[3] >>  8) & 0xff] & 0xff] ^
-			Td3[Te4[(rk[3]      ) & 0xff] & 0xff];
-	}
-	return 0;
-}
-
-#ifndef AES_ASM
-/*
- * Encrypt a single block
- * in and out can overlap
- */
-void AES_encrypt(const unsigned char *in, unsigned char *out,
-		 const AES_KEY *key) {
-
-	const u32 *rk;
-	u32 s0, s1, s2, s3, t0, t1, t2, t3;
-#ifndef FULL_UNROLL
-	int r;
-#endif /* ?FULL_UNROLL */
-
-	assert(in && out && key);
-	rk = key->rd_key;
-
-	/*
-	 * map byte array block to cipher state
-	 * and add initial round key:
-	 */
-	s0 = GETU32(in     ) ^ rk[0];
-	s1 = GETU32(in +  4) ^ rk[1];
-	s2 = GETU32(in +  8) ^ rk[2];
-	s3 = GETU32(in + 12) ^ rk[3];
-#ifdef FULL_UNROLL
-	/* round 1: */
-   	t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[ 4];
-   	t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[ 5];
-   	t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[ 6];
-   	t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[ 7];
-   	/* round 2: */
-   	s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[ 8];
-   	s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[ 9];
-   	s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[10];
-   	s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[11];
-	/* round 3: */
-   	t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[12];
-   	t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[13];
-   	t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[14];
-   	t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[15];
-   	/* round 4: */
-   	s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[16];
-   	s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[17];
-   	s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[18];
-   	s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[19];
-	/* round 5: */
-   	t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[20];
-   	t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[21];
-   	t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[22];
-   	t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[23];
-   	/* round 6: */
-   	s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[24];
-   	s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[25];
-   	s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[26];
-   	s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[27];
-	/* round 7: */
-   	t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[28];
-   	t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[29];
-   	t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[30];
-   	t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[31];
-   	/* round 8: */
-   	s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[32];
-   	s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[33];
-   	s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[34];
-   	s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[35];
-	/* round 9: */
-   	t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[36];
-   	t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[37];
-   	t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[38];
-   	t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[39];
-    if (key->rounds > 10) {
-        /* round 10: */
-        s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[40];
-        s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[41];
-        s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[42];
-        s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[43];
-        /* round 11: */
-        t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[44];
-        t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[45];
-        t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[46];
-        t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[47];
-        if (key->rounds > 12) {
-            /* round 12: */
-            s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[48];
-            s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[49];
-            s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[50];
-            s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[51];
-            /* round 13: */
-            t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[52];
-            t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[53];
-            t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[54];
-            t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[55];
-        }
-    }
-    rk += key->rounds << 2;
-#else  /* !FULL_UNROLL */
-    /*
-     * Nr - 1 full rounds:
-     */
-    r = key->rounds >> 1;
-    for (;;) {
-        t0 =
-            Te0[(s0 >> 24)       ] ^
-            Te1[(s1 >> 16) & 0xff] ^
-            Te2[(s2 >>  8) & 0xff] ^
-            Te3[(s3      ) & 0xff] ^
-            rk[4];
-        t1 =
-            Te0[(s1 >> 24)       ] ^
-            Te1[(s2 >> 16) & 0xff] ^
-            Te2[(s3 >>  8) & 0xff] ^
-            Te3[(s0      ) & 0xff] ^
-            rk[5];
-        t2 =
-            Te0[(s2 >> 24)       ] ^
-            Te1[(s3 >> 16) & 0xff] ^
-            Te2[(s0 >>  8) & 0xff] ^
-            Te3[(s1      ) & 0xff] ^
-            rk[6];
-        t3 =
-            Te0[(s3 >> 24)       ] ^
-            Te1[(s0 >> 16) & 0xff] ^
-            Te2[(s1 >>  8) & 0xff] ^
-            Te3[(s2      ) & 0xff] ^
-            rk[7];
-
-        rk += 8;
-        if (--r == 0) {
-            break;
-        }
-
-        s0 =
-            Te0[(t0 >> 24)       ] ^
-            Te1[(t1 >> 16) & 0xff] ^
-            Te2[(t2 >>  8) & 0xff] ^
-            Te3[(t3      ) & 0xff] ^
-            rk[0];
-        s1 =
-            Te0[(t1 >> 24)       ] ^
-            Te1[(t2 >> 16) & 0xff] ^
-            Te2[(t3 >>  8) & 0xff] ^
-            Te3[(t0      ) & 0xff] ^
-            rk[1];
-        s2 =
-            Te0[(t2 >> 24)       ] ^
-            Te1[(t3 >> 16) & 0xff] ^
-            Te2[(t0 >>  8) & 0xff] ^
-            Te3[(t1      ) & 0xff] ^
-            rk[2];
-        s3 =
-            Te0[(t3 >> 24)       ] ^
-            Te1[(t0 >> 16) & 0xff] ^
-            Te2[(t1 >>  8) & 0xff] ^
-            Te3[(t2      ) & 0xff] ^
-            rk[3];
-    }
-#endif /* ?FULL_UNROLL */
-    /*
-	 * apply last round and
-	 * map cipher state to byte array block:
-	 */
-	s0 =
-		(Te4[(t0 >> 24)       ] & 0xff000000) ^
-		(Te4[(t1 >> 16) & 0xff] & 0x00ff0000) ^
-		(Te4[(t2 >>  8) & 0xff] & 0x0000ff00) ^
-		(Te4[(t3      ) & 0xff] & 0x000000ff) ^
-		rk[0];
-	PUTU32(out     , s0);
-	s1 =
-		(Te4[(t1 >> 24)       ] & 0xff000000) ^
-		(Te4[(t2 >> 16) & 0xff] & 0x00ff0000) ^
-		(Te4[(t3 >>  8) & 0xff] & 0x0000ff00) ^
-		(Te4[(t0      ) & 0xff] & 0x000000ff) ^
-		rk[1];
-	PUTU32(out +  4, s1);
-	s2 =
-		(Te4[(t2 >> 24)       ] & 0xff000000) ^
-		(Te4[(t3 >> 16) & 0xff] & 0x00ff0000) ^
-		(Te4[(t0 >>  8) & 0xff] & 0x0000ff00) ^
-		(Te4[(t1      ) & 0xff] & 0x000000ff) ^
-		rk[2];
-	PUTU32(out +  8, s2);
-	s3 =
-		(Te4[(t3 >> 24)       ] & 0xff000000) ^
-		(Te4[(t0 >> 16) & 0xff] & 0x00ff0000) ^
-		(Te4[(t1 >>  8) & 0xff] & 0x0000ff00) ^
-		(Te4[(t2      ) & 0xff] & 0x000000ff) ^
-		rk[3];
-	PUTU32(out + 12, s3);
-}
-
-/*
- * Decrypt a single block
- * in and out can overlap
- */
-void AES_decrypt(const unsigned char *in, unsigned char *out,
-		 const AES_KEY *key) {
-
-	const u32 *rk;
-	u32 s0, s1, s2, s3, t0, t1, t2, t3;
-#ifndef FULL_UNROLL
-	int r;
-#endif /* ?FULL_UNROLL */
-
-	assert(in && out && key);
-	rk = key->rd_key;
-
-	/*
-	 * map byte array block to cipher state
-	 * and add initial round key:
-	 */
-    s0 = GETU32(in     ) ^ rk[0];
-    s1 = GETU32(in +  4) ^ rk[1];
-    s2 = GETU32(in +  8) ^ rk[2];
-    s3 = GETU32(in + 12) ^ rk[3];
-#ifdef FULL_UNROLL
-    /* round 1: */
-    t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[ 4];
-    t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[ 5];
-    t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[ 6];
-    t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[ 7];
-    /* round 2: */
-    s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[ 8];
-    s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[ 9];
-    s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[10];
-    s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[11];
-    /* round 3: */
-    t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[12];
-    t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[13];
-    t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[14];
-    t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[15];
-    /* round 4: */
-    s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[16];
-    s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[17];
-    s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[18];
-    s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[19];
-    /* round 5: */
-    t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[20];
-    t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[21];
-    t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[22];
-    t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[23];
-    /* round 6: */
-    s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[24];
-    s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[25];
-    s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[26];
-    s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[27];
-    /* round 7: */
-    t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[28];
-    t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[29];
-    t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[30];
-    t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[31];
-    /* round 8: */
-    s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[32];
-    s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[33];
-    s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[34];
-    s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[35];
-    /* round 9: */
-    t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[36];
-    t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[37];
-    t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[38];
-    t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[39];
-    if (key->rounds > 10) {
-        /* round 10: */
-        s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[40];
-        s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[41];
-        s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[42];
-        s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[43];
-        /* round 11: */
-        t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[44];
-        t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[45];
-        t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[46];
-        t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[47];
-        if (key->rounds > 12) {
-            /* round 12: */
-            s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[48];
-            s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[49];
-            s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[50];
-            s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[51];
-            /* round 13: */
-            t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[52];
-            t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[53];
-            t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[54];
-            t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[55];
-        }
-    }
-	rk += key->rounds << 2;
-#else  /* !FULL_UNROLL */
-    /*
-     * Nr - 1 full rounds:
-     */
-    r = key->rounds >> 1;
-    for (;;) {
-        t0 =
-            Td0[(s0 >> 24)       ] ^
-            Td1[(s3 >> 16) & 0xff] ^
-            Td2[(s2 >>  8) & 0xff] ^
-            Td3[(s1      ) & 0xff] ^
-            rk[4];
-        t1 =
-            Td0[(s1 >> 24)       ] ^
-            Td1[(s0 >> 16) & 0xff] ^
-            Td2[(s3 >>  8) & 0xff] ^
-            Td3[(s2      ) & 0xff] ^
-            rk[5];
-        t2 =
-            Td0[(s2 >> 24)       ] ^
-            Td1[(s1 >> 16) & 0xff] ^
-            Td2[(s0 >>  8) & 0xff] ^
-            Td3[(s3      ) & 0xff] ^
-            rk[6];
-        t3 =
-            Td0[(s3 >> 24)       ] ^
-            Td1[(s2 >> 16) & 0xff] ^
-            Td2[(s1 >>  8) & 0xff] ^
-            Td3[(s0      ) & 0xff] ^
-            rk[7];
-
-        rk += 8;
-        if (--r == 0) {
-            break;
-        }
-
-        s0 =
-            Td0[(t0 >> 24)       ] ^
-            Td1[(t3 >> 16) & 0xff] ^
-            Td2[(t2 >>  8) & 0xff] ^
-            Td3[(t1      ) & 0xff] ^
-            rk[0];
-        s1 =
-            Td0[(t1 >> 24)       ] ^
-            Td1[(t0 >> 16) & 0xff] ^
-            Td2[(t3 >>  8) & 0xff] ^
-            Td3[(t2      ) & 0xff] ^
-            rk[1];
-        s2 =
-            Td0[(t2 >> 24)       ] ^
-            Td1[(t1 >> 16) & 0xff] ^
-            Td2[(t0 >>  8) & 0xff] ^
-            Td3[(t3      ) & 0xff] ^
-            rk[2];
-        s3 =
-            Td0[(t3 >> 24)       ] ^
-            Td1[(t2 >> 16) & 0xff] ^
-            Td2[(t1 >>  8) & 0xff] ^
-            Td3[(t0      ) & 0xff] ^
-            rk[3];
-    }
-#endif /* ?FULL_UNROLL */
-    /*
-	 * apply last round and
-	 * map cipher state to byte array block:
-	 */
-   	s0 =
-   		(Td4[(t0 >> 24)       ] & 0xff000000) ^
-   		(Td4[(t3 >> 16) & 0xff] & 0x00ff0000) ^
-   		(Td4[(t2 >>  8) & 0xff] & 0x0000ff00) ^
-   		(Td4[(t1      ) & 0xff] & 0x000000ff) ^
-   		rk[0];
-	PUTU32(out     , s0);
-   	s1 =
-   		(Td4[(t1 >> 24)       ] & 0xff000000) ^
-   		(Td4[(t0 >> 16) & 0xff] & 0x00ff0000) ^
-   		(Td4[(t3 >>  8) & 0xff] & 0x0000ff00) ^
-   		(Td4[(t2      ) & 0xff] & 0x000000ff) ^
-   		rk[1];
-	PUTU32(out +  4, s1);
-   	s2 =
-   		(Td4[(t2 >> 24)       ] & 0xff000000) ^
-   		(Td4[(t1 >> 16) & 0xff] & 0x00ff0000) ^
-   		(Td4[(t0 >>  8) & 0xff] & 0x0000ff00) ^
-   		(Td4[(t3      ) & 0xff] & 0x000000ff) ^
-   		rk[2];
-	PUTU32(out +  8, s2);
-   	s3 =
-   		(Td4[(t3 >> 24)       ] & 0xff000000) ^
-   		(Td4[(t2 >> 16) & 0xff] & 0x00ff0000) ^
-   		(Td4[(t1 >>  8) & 0xff] & 0x0000ff00) ^
-   		(Td4[(t0      ) & 0xff] & 0x000000ff) ^
-   		rk[3];
-	PUTU32(out + 12, s3);
-}
-
-#endif /* AES_ASM */
-
-void AES_cbc_encrypt(const unsigned char *in, unsigned char *out,
-		     const unsigned long length, const AES_KEY *key,
-		     unsigned char *ivec, const int enc) 
-{
-
-	unsigned long n;
-	unsigned long len = length;
-	unsigned char tmp[AES_BLOCK_SIZE];
-
-	assert(in && out && key && ivec);
-
-	if (enc) {
-		while (len >= AES_BLOCK_SIZE) {
-			for(n=0; n < AES_BLOCK_SIZE; ++n)
-				tmp[n] = in[n] ^ ivec[n];
-			AES_encrypt(tmp, out, key);
-			memcpy(ivec, out, AES_BLOCK_SIZE);
-			len -= AES_BLOCK_SIZE;
-			in += AES_BLOCK_SIZE;
-			out += AES_BLOCK_SIZE;
-		}
-		if (len) {
-			for(n=0; n < len; ++n)
-				tmp[n] = in[n] ^ ivec[n];
-			for(n=len; n < AES_BLOCK_SIZE; ++n)
-				tmp[n] = ivec[n];
-			AES_encrypt(tmp, tmp, key);
-			memcpy(out, tmp, AES_BLOCK_SIZE);
-			memcpy(ivec, tmp, AES_BLOCK_SIZE);
-		}			
-	} else {
-		while (len >= AES_BLOCK_SIZE) {
-			memcpy(tmp, in, AES_BLOCK_SIZE);
-			AES_decrypt(in, out, key);
-			for(n=0; n < AES_BLOCK_SIZE; ++n)
-				out[n] ^= ivec[n];
-			memcpy(ivec, tmp, AES_BLOCK_SIZE);
-			len -= AES_BLOCK_SIZE;
-			in += AES_BLOCK_SIZE;
-			out += AES_BLOCK_SIZE;
-		}
-		if (len) {
-			memcpy(tmp, in, AES_BLOCK_SIZE);
-			AES_decrypt(tmp, tmp, key);
-			for(n=0; n < len; ++n)
-				out[n] = tmp[n] ^ ivec[n];
-			memcpy(ivec, tmp, AES_BLOCK_SIZE);
-		}			
-	}
-}
diff --git a/tools/blktap/drivers/aes.h b/tools/blktap/drivers/aes.h
deleted file mode 100644
index 9fb54a9..0000000
--- a/tools/blktap/drivers/aes.h
+++ /dev/null
@@ -1,28 +0,0 @@
-#ifndef QEMU_AES_H
-#define QEMU_AES_H
-
-#include <stdint.h>
-
-#define AES_MAXNR 14
-#define AES_BLOCK_SIZE 16
-
-struct aes_key_st {
-    uint32_t rd_key[4 *(AES_MAXNR + 1)];
-    int rounds;
-};
-typedef struct aes_key_st AES_KEY;
-
-int AES_set_encrypt_key(const unsigned char *userKey, const int bits,
-	AES_KEY *key);
-int AES_set_decrypt_key(const unsigned char *userKey, const int bits,
-	AES_KEY *key);
-
-void AES_encrypt(const unsigned char *in, unsigned char *out,
-	const AES_KEY *key);
-void AES_decrypt(const unsigned char *in, unsigned char *out,
-	const AES_KEY *key);
-void AES_cbc_encrypt(const unsigned char *in, unsigned char *out,
-		     const unsigned long length, const AES_KEY *key,
-		     unsigned char *ivec, const int enc);
-
-#endif
diff --git a/tools/blktap/drivers/blk.h b/tools/blktap/drivers/blk.h
deleted file mode 100644
index 1cdc980..0000000
--- a/tools/blktap/drivers/blk.h
+++ /dev/null
@@ -1,3 +0,0 @@
-
-int blk_getimagesize(int fd, uint64_t *size);
-int blk_getsectorsize(int fd, uint64_t *sector_size);
diff --git a/tools/blktap/drivers/blk_linux.c b/tools/blktap/drivers/blk_linux.c
deleted file mode 100644
index bb52717..0000000
--- a/tools/blktap/drivers/blk_linux.c
+++ /dev/null
@@ -1,42 +0,0 @@
-#include <inttypes.h>
-#include <sys/ioctl.h>
-#include <sys/mount.h>
-#include "tapdisk.h"
-#include "blk.h"
-
-int blk_getimagesize(int fd, uint64_t *size)
-{
-	int rc;
-
-	*size = 0;
-	rc = ioctl(fd, BLKGETSIZE, size);
-	if (rc) {
-		DPRINTF("ERR: BLKGETSIZE failed, couldn't stat image");
-		return -EINVAL;
-	}
-
-	return 0;
-}
-
-int blk_getsectorsize(int fd, uint64_t *sector_size)
-{
-#if defined(BLKSSZGET)
-	int rc;
-
-	*sector_size = DEFAULT_SECTOR_SIZE;
-	rc = ioctl(fd, BLKSSZGET, sector_size);
-	if (rc) {
-		DPRINTF("ERR: BLKSSZGET failed. Falling back to use default sector size");
-		*sector_size = DEFAULT_SECTOR_SIZE;
-	}
-
-	if (*sector_size != DEFAULT_SECTOR_SIZE)
-		DPRINTF("Note: sector size is %"PRIu64" (not %u)\n",
-			*sector_size, DEFAULT_SECTOR_SIZE);
-#else
-	*sector_size = DEFAULT_SECTOR_SIZE;
-#endif
-
-	return 0;
-}
-
diff --git a/tools/blktap/drivers/blktapctrl.c b/tools/blktap/drivers/blktapctrl.c
deleted file mode 100644
index 0a8b880..0000000
--- a/tools/blktap/drivers/blktapctrl.c
+++ /dev/null
@@ -1,937 +0,0 @@
-/*
- * blktapctrl.c
- * 
- * userspace controller for the blktap disks.
- * As requests for new block devices arrive,
- * the controller spawns off a separate process
- * per-disk.
- *
- *
- * Copyright (c) 2005 Julian Chesterfield and Andrew Warfield.
- *
- * 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 <stdio.h>
-#include <stdlib.h>
-#include <sys/mman.h>
-#include <err.h>
-#include <errno.h>
-#include <sys/types.h>
-#include <sys/wait.h>
-#include <signal.h>
-#include <fcntl.h>
-#include <sys/poll.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include <unistd.h>
-#include <xenstore.h>
-#include <sys/time.h>
-#include <syslog.h>
-#ifdef MEMSHR
-#include <memshr.h>
-#endif
-#include <sys/stat.h>
-                                                                     
-#include "blktaplib.h"
-#include "blktapctrl.h"
-#include "tapdisk.h"
-#include "list.h"
-#include "xs_api.h" /* for xs_fire_next_watch() */
-
-#define PIDFILE "/var/run/blktapctrl.pid"
-
-#define NUM_POLL_FDS 2
-#define MSG_SIZE 4096
-#define MAX_TIMEOUT 10
-#define MAX_RAND_VAL 0xFFFF
-#define MAX_ATTEMPTS 10
-
-int run = 1;
-int max_timeout = MAX_TIMEOUT;
-int ctlfd = 0;
-
-int blktap_major;
-
-static int open_ctrl_socket(char *devname);
-static int write_msg(int fd, int msgtype, void *ptr, void *ptr2);
-static int read_msg(int fd, int msgtype, void *ptr);
-static driver_list_entry_t *active_disks[MAX_DISK_TYPES];
-
-
-static unsigned long long tapdisk_get_size(blkif_t *blkif)
-{
-	image_t *img = (image_t *)blkif->prv;
-	return img->size;
-}
-
-static unsigned long tapdisk_get_secsize(blkif_t *blkif)
-{
-	image_t *img = (image_t *)blkif->prv;
-	return img->secsize;
-}
-
-static unsigned int tapdisk_get_info(blkif_t *blkif)
-{
-	image_t *img = (image_t *)blkif->prv;
-	return img->info;
-}
-
-struct blkif_ops tapdisk_ops = {
-	.get_size = tapdisk_get_size,
-	.get_secsize = tapdisk_get_secsize,
-	.get_info = tapdisk_get_info,
-};
-
-
-static void init_driver_list(void)
-{
-	int i;
-
-	for (i = 0; i < MAX_DISK_TYPES; i++)
-		active_disks[i] = NULL;
-	return;
-}
-
-static void init_rng(void)
-{
-	static uint32_t seed;
-	struct timeval tv;
-
-	gettimeofday(&tv, NULL);
-	seed = tv.tv_usec;
-	srand48(seed);
-	return;
-}
-
-static int get_tapdisk_pid(blkif_t *blkif)
-{
-	int ret;
-
-	if ((ret = write_msg(blkif->fds[WRITE], CTLMSG_PID, blkif, NULL)) 
-	    <= 0) {
-		DPRINTF("Write_msg failed - CTLMSG_PID(%d)\n", ret);
-		return -EINVAL;
-	}
-
-	if ((ret = read_msg(blkif->fds[READ], CTLMSG_PID_RSP, blkif))
-	     <= 0) {
-		DPRINTF("Read_msg failure - CTLMSG_PID(%d)\n", ret);
-		return -EINVAL;
-	}	
-	return 1;
-}
-
-/* Look up the disk specified by path: 
- *   if found, dev points to the device string in the path
- *             type is the tapdisk driver type id
- *             blkif is the existing interface if this is a shared driver
- *             and NULL otherwise.
- *   return 0 on success, -1 on error.
- */
-
-static int test_path(char *path, char **dev, int *type, blkif_t **blkif,
-	int* use_ioemu)
-{
-	char *ptr, handle[10];
-	int i, size, found = 0;
-	size_t handle_len;
-
-	size = sizeof(dtypes)/sizeof(disk_info_t *);
-	*type = MAX_DISK_TYPES + 1;
-        *blkif = NULL;
-
-	if (!strncmp(path, "tapdisk:", strlen("tapdisk:"))) {
-		*use_ioemu = 0;
-		path += strlen("tapdisk:");
-	} else if (!strncmp(path, "ioemu:", strlen("ioemu:"))) {
-		*use_ioemu = 1;
-		path += strlen("ioemu:");
-	} else {
-		// Use the default for the image type
-		*use_ioemu = -1;
-	}
-
-	if ( (ptr = strstr(path, ":"))!=NULL) {
-		handle_len = (ptr - path);
-		memcpy(handle, path, handle_len);
-		*dev = ptr + 1;
-		ptr = handle + handle_len;
-		*ptr = '\0';
-		DPRINTF("Detected handle: [%s]\n",handle);
-
-		for (i = 0; i < size; i++) {
-			if ((strlen(dtypes[i]->handle) == handle_len) &&
-					strncmp(handle, dtypes[i]->handle,
-					handle_len) == 0) {
-                                found = 1;
-                        }
-
-			if (found) {
-				if (*use_ioemu == -1)
-					*use_ioemu = dtypes[i]->use_ioemu;
-				*type = dtypes[i]->idnum;
-                        
-                        if (dtypes[i]->single_handler == 1) {
-                                /* Check whether tapdisk process 
-                                   already exists */
-                                if (active_disks[dtypes[i]->idnum] == NULL) 
-                                        *blkif = NULL;
-                                else 
-                                        *blkif = active_disks[dtypes[i]
-                                                             ->idnum]->blkif;
-                        }
-
-                        return 0;
-                }
-            }
-        }
-
-        /* Fall-through case, we didn't find a disk driver. */
-        DPRINTF("Unknown blktap disk type [%s]!\n",handle);
-        *dev = NULL;
-        return -1;
-}
-
-
-static void add_disktype(blkif_t *blkif, int type)
-{
-	driver_list_entry_t *entry, **pprev;
-
-	if (type > MAX_DISK_TYPES)
-		return;
-
-	entry = malloc(sizeof(driver_list_entry_t));
-	entry->blkif = blkif;
-	entry->next  = NULL;
-
-	pprev = &active_disks[type];
-	while (*pprev != NULL)
-		pprev = &(*pprev)->next;
-
-	*pprev = entry;
-	entry->pprev = pprev;
-}
-
-static int qemu_instance_has_disks(pid_t pid)
-{
-	int i;
-	int count = 0;
-	driver_list_entry_t *entry;
-
-	for (i = 0; i < MAX_DISK_TYPES; i++) {
-		entry = active_disks[i];
-		while (entry) {
-			if ((entry->blkif->tappid == pid) && dtypes[i]->use_ioemu)
-				count++;
-			entry = entry->next;
-		}
-	}
-
-	return (count != 0);
-}
-
-static int del_disktype(blkif_t *blkif)
-{
-	driver_list_entry_t *entry, **pprev;
-	int type = blkif->drivertype, count = 0, close = 0;
-
-	if (type > MAX_DISK_TYPES)
-		return 1;
-
-	pprev = &active_disks[type];
-	while ((*pprev != NULL) && ((*pprev)->blkif != blkif))
-		pprev = &(*pprev)->next;
-
-	if ((entry = *pprev) == NULL) {
-		DPRINTF("DEL_DISKTYPE: No match\n");
-		return 1;
-	}
-
-	*pprev = entry->next;
-	if (entry->next)
-		entry->next->pprev = pprev;
-
-	DPRINTF("DEL_DISKTYPE: Freeing entry\n");
-	free(entry);
-
-	/*
-	 * When using ioemu, all disks of one VM are connected to the same
-	 * qemu-dm instance. We may close the file handle only if there is
-	 * no other disk left for this domain.
-	 */
-	if (dtypes[type]->use_ioemu)
-		return !qemu_instance_has_disks(blkif->tappid);
-
-	/* Caller should close() if no single controller, or list is empty. */
-	return (!dtypes[type]->single_handler || (active_disks[type] == NULL));
-}
-
-static int write_msg(int fd, int msgtype, void *ptr, void *ptr2)
-{
-	blkif_t *blkif;
-	blkif_info_t *blk;
-	msg_hdr_t *msg;
-	msg_newdev_t *msg_dev;
-	char *p, *buf, *path;
-	int msglen, len, ret;
-	fd_set writefds;
-	struct timeval timeout;
-	image_t *image, *img;
-	uint32_t seed;
-
-	blkif = (blkif_t *)ptr;
-	blk = blkif->info;
-	image = blkif->prv;
-	len = 0;
-
-	switch (msgtype)
-	{
-	case CTLMSG_PARAMS:
-		path = (char *)ptr2;
-		DPRINTF("Write_msg called: CTLMSG_PARAMS, sending [%s, %s]\n",
-			blk->params, path);
-
-		msglen = sizeof(msg_hdr_t) + strlen(path) + 1;
-		buf = malloc(msglen);
-
-		/*Assign header fields*/
-		msg = (msg_hdr_t *)buf;
-		msg->type = CTLMSG_PARAMS;
-		msg->len = msglen;
-		msg->drivertype = blkif->drivertype;
-		msg->readonly = blkif->readonly;
-
-		gettimeofday(&timeout, NULL);
-		msg->cookie = blkif->cookie;
-		DPRINTF("Generated cookie, %d\n",blkif->cookie);
-
-		/*Copy blk->params to msg*/
-		p = buf + sizeof(msg_hdr_t);
-		memcpy(p, path, strlen(path) + 1);
-
-		break;
-
-	case CTLMSG_NEWDEV:
-		DPRINTF("Write_msg called: CTLMSG_NEWDEV\n");
-
-		msglen = sizeof(msg_hdr_t) + sizeof(msg_newdev_t);
-		buf = malloc(msglen);
-		
-		/*Assign header fields*/
-		msg = (msg_hdr_t *)buf;
-		msg->type = CTLMSG_NEWDEV;
-		msg->len = msglen;
-		msg->drivertype = blkif->drivertype;
-		msg->cookie = blkif->cookie;
-		
-		msg_dev = (msg_newdev_t *)(buf + sizeof(msg_hdr_t));
-		msg_dev->devnum = blkif->minor;
-		msg_dev->domid = blkif->domid;
-
-		break;
-
-	case CTLMSG_CLOSE:
-		DPRINTF("Write_msg called: CTLMSG_CLOSE\n");
-
-		msglen = sizeof(msg_hdr_t);
-		buf = malloc(msglen);
-		
-		/*Assign header fields*/
-		msg = (msg_hdr_t *)buf;
-		msg->type = CTLMSG_CLOSE;
-		msg->len = msglen;
-		msg->drivertype = blkif->drivertype;
-		msg->cookie = blkif->cookie;
-		
-		break;
-
-	case CTLMSG_PID:
-		DPRINTF("Write_msg called: CTLMSG_PID\n");
-
-		msglen = sizeof(msg_hdr_t);
-		buf = malloc(msglen);
-		
-		/*Assign header fields*/
-		msg = (msg_hdr_t *)buf;
-		msg->type = CTLMSG_PID;
-		msg->len = msglen;
-		msg->drivertype = blkif->drivertype;
-		msg->cookie = blkif->cookie;
-		
-		break;
-		
-	default:
-		return -1;
-	}
-
-	/*Now send the message*/
-	ret = 0;
-	FD_ZERO(&writefds);
-	FD_SET(fd,&writefds);
-	timeout.tv_sec = max_timeout; /*Wait for up to max_timeout seconds*/
-	timeout.tv_usec = 0;
-	if (select(fd+1, (fd_set *) 0, &writefds, 
-		  (fd_set *) 0, &timeout) > 0) {
-		len = write(fd, buf, msglen);
-		if (len == -1) DPRINTF("Write failed: (%d)\n",errno);
-	}
-	free(buf);
-
-	return len;
-}
-
-static int read_msg(int fd, int msgtype, void *ptr)
-{
-	blkif_t *blkif;
-	blkif_info_t *blk;
-	msg_hdr_t *msg;
-	msg_pid_t *msg_pid;
-	char *p, *buf;
-	int msglen = MSG_SIZE, len, ret;
-	fd_set readfds;
-	struct timeval timeout;
-	image_t *image, *img;
-
-
-	blkif = (blkif_t *)ptr;
-	blk = blkif->info;
-	image = blkif->prv;
-
-	buf = malloc(MSG_SIZE);
-
-	ret = 0;
-	FD_ZERO(&readfds);
-	FD_SET(fd,&readfds);
-	timeout.tv_sec = max_timeout; /*Wait for up to max_timeout seconds*/ 
-	timeout.tv_usec = 0;
-	if (select(fd+1, &readfds,  (fd_set *) 0,
-		  (fd_set *) 0, &timeout) > 0) {
-		ret = read(fd, buf, msglen);
-	}			
-	if (ret > 0) {
-		msg = (msg_hdr_t *)buf;
-		switch (msg->type)
-		{
-		case CTLMSG_IMG:
-			img = (image_t *)(buf + sizeof(msg_hdr_t));
-			image->size = img->size;
-			image->secsize = img->secsize;
-			image->info = img->info;
-
-			DPRINTF("Received CTLMSG_IMG: %llu, %lu, %u\n",
-				image->size, image->secsize, image->info);
-			if(msgtype != CTLMSG_IMG) ret = 0;
-			break;
-			
-		case CTLMSG_IMG_FAIL:
-			DPRINTF("Received CTLMSG_IMG_FAIL, "
-				"unable to open image\n");
-			ret = 0;
-			break;
-				
-		case CTLMSG_NEWDEV_RSP:
-			DPRINTF("Received CTLMSG_NEWDEV_RSP\n");
-			if(msgtype != CTLMSG_NEWDEV_RSP) ret = 0;
-			break;
-			
-		case CTLMSG_NEWDEV_FAIL:
-			DPRINTF("Received CTLMSG_NEWDEV_FAIL\n");
-			ret = 0;
-			break;
-			
-		case CTLMSG_CLOSE_RSP:
-			DPRINTF("Received CTLMSG_CLOSE_RSP\n");
-			if (msgtype != CTLMSG_CLOSE_RSP) ret = 0;
-			break;
-
-		case CTLMSG_PID_RSP:
-			DPRINTF("Received CTLMSG_PID_RSP\n");
-			if (msgtype != CTLMSG_PID_RSP) ret = 0;
-			else {
-				msg_pid = (msg_pid_t *)
-					(buf + sizeof(msg_hdr_t));
-				blkif->tappid = msg_pid->pid;
-				DPRINTF("\tPID: [%d]\n",blkif->tappid);
-			}
-			break;
-		default:
-			DPRINTF("UNKNOWN MESSAGE TYPE RECEIVED\n");
-			ret = 0;
-			break;
-		}
-	} 
-	
-	free(buf);
-	
-	return ret;
-
-}
-
-static int launch_tapdisk_provider(char **argv)
-{
-	pid_t child;
-	
-	if ((child = fork()) < 0)
-		return -1;
-
-	if (!child) {
-		int i;
-		for (i = 0 ; i < sysconf(_SC_OPEN_MAX) ; i++)
-			if (i != STDIN_FILENO &&
-			    i != STDOUT_FILENO &&
-			    i != STDERR_FILENO)
-				close(i);
-
-		execvp(argv[0], argv);
-		DPRINTF("execvp failed: %d (%s)\n", errno, strerror(errno));
-		DPRINTF("PATH = %s\n", getenv("PATH"));
-		_exit(1);
-	} else {
-		pid_t got;
-		do {
-			got = waitpid(child, NULL, 0);
-		} while (got != child);
-	}
-	return child;
-}
-
-static int launch_tapdisk(char *wrctldev, char *rdctldev)
-{
-	char *argv[] = { "tapdisk", wrctldev, rdctldev, NULL };
-
-	if (launch_tapdisk_provider(argv) < 0)
-		return -1;
-
-	return 0;
-}
-
-static int launch_tapdisk_ioemu(void)
-{
-	char *argv[] = { "tapdisk-ioemu", NULL };
-	return launch_tapdisk_provider(argv);
-}
-
-/* 
- * Connect to an ioemu based disk provider (qemu-dm or tapdisk-ioemu)
- *
- * If the domain has a device model, connect to qemu-dm through the
- * domain specific pipe. Otherwise use a single tapdisk-ioemu instance
- * which is represented by domid 0 and provides access for Dom0 and
- * all DomUs without device model.
- */
-static int connect_qemu(blkif_t *blkif, int domid)
-{
-	char *rdctldev, *wrctldev;
-
-	static int tapdisk_ioemu_pid = 0;
-	static int dom0_readfd = 0;
-	static int dom0_writefd = 0;
-	int refresh_pid = 0;
-
-	if (asprintf(&rdctldev, BLKTAP_CTRL_DIR "/qemu-read-%d", domid) < 0)
-		return -1;
-
-	if (asprintf(&wrctldev, BLKTAP_CTRL_DIR "/qemu-write-%d", domid) < 0) {
-		free(rdctldev);
-		return -1;
-	}
-
-	DPRINTF("Using qemu blktap pipe: %s\n", rdctldev);
-	
-	if (domid == 0) {
-		/*
-		 * tapdisk-ioemu exits as soon as the last image is 
-		 * disconnected. Check if it is still running.
-		 */
-		if (tapdisk_ioemu_pid == 0 || kill(tapdisk_ioemu_pid, 0)) {
-			/* No device model and tapdisk-ioemu doesn't run yet */
-			DPRINTF("Launching tapdisk-ioemu\n");
-			launch_tapdisk_ioemu();
-			
-			dom0_readfd = open_ctrl_socket(wrctldev);
-			dom0_writefd = open_ctrl_socket(rdctldev);
-
-			refresh_pid = 1;
-		}
-
-		DPRINTF("Using tapdisk-ioemu connection\n");
-		blkif->fds[READ] = dom0_readfd;
-		blkif->fds[WRITE] = dom0_writefd;
-
-		if (refresh_pid) {
-			get_tapdisk_pid(blkif);
-			tapdisk_ioemu_pid = blkif->tappid;
-		}
-
-	} else if (access(rdctldev, R_OK | W_OK) == 0) {
-		/* Use existing pipe to the device model */
-		DPRINTF("Using qemu-dm connection\n");
-		blkif->fds[READ] = open_ctrl_socket(wrctldev);
-		blkif->fds[WRITE] = open_ctrl_socket(rdctldev);
-	} else {
-		/* No device model => try with tapdisk-ioemu */
-		DPRINTF("No device model\n");
-		connect_qemu(blkif, 0);
-	}
-	
-	free(rdctldev);
-	free(wrctldev);
-	
-	if (blkif->fds[READ] == -1 || blkif->fds[WRITE] == -1)
-		return -1;
-
-	DPRINTF("Attached to qemu blktap pipes\n");
-	return 0;
-}
-
-/* Launch tapdisk instance */
-static int connect_tapdisk(blkif_t *blkif, int minor)
-{
-	char *rdctldev = NULL, *wrctldev = NULL;
-	int ret = -1;
-
-	DPRINTF("tapdisk process does not exist:\n");
-
-	if (asprintf(&rdctldev,
-		     "%s/tapctrlread%d", BLKTAP_CTRL_DIR, minor) == -1)
-		goto fail;
-
-	if (asprintf(&wrctldev,
-		     "%s/tapctrlwrite%d", BLKTAP_CTRL_DIR, minor) == -1)
-		goto fail;
-	
-	blkif->fds[READ] = open_ctrl_socket(rdctldev);
-	blkif->fds[WRITE] = open_ctrl_socket(wrctldev);
-	
-	if (blkif->fds[READ] == -1 || blkif->fds[WRITE] == -1)
-		goto fail;
-
-	/*launch the new process*/
-	DPRINTF("Launching process, CMDLINE [tapdisk %s %s]\n",
-			wrctldev, rdctldev);
-
-	if (launch_tapdisk(wrctldev, rdctldev) == -1) {
-		DPRINTF("Unable to fork, cmdline: [tapdisk %s %s]\n",
-				wrctldev, rdctldev);
-		goto fail;
-	}
-
-	ret = 0;
-	
-fail:
-	if (rdctldev)
-		free(rdctldev);
-
-	if (wrctldev)
-		free(wrctldev);
-
-	return ret;
-}
-
-static int blktapctrl_new_blkif(blkif_t *blkif)
-{
-	blkif_info_t *blk;
-	int major, minor, fd_read, fd_write, type, new;
-	char *rdctldev, *wrctldev, *ptr;
-	image_t *image;
-	blkif_t *exist = NULL;
-	static uint16_t next_cookie = 0;
-	int use_ioemu;
-
-	DPRINTF("Received a poll for a new vbd\n");
-	if ( ((blk=blkif->info) != NULL) && (blk->params != NULL) ) {
-		if (blktap_interface_create(ctlfd, &major, &minor, blkif) < 0)
-			return -1;
-
-		if (test_path(blk->params, &ptr, &type, &exist, &use_ioemu) != 0) {
-                        DPRINTF("Error in blktap device string(%s).\n",
-                                blk->params);
-                        goto fail;
-                }
-		blkif->drivertype = type;
-		blkif->cookie = next_cookie++;
-
-		if (!exist) {
-			if (use_ioemu) {
-				if (connect_qemu(blkif, blkif->domid))
-					goto fail;
-			} else {
-				if (connect_tapdisk(blkif, minor))
-					goto fail;
-			}
-
-		} else {
-			DPRINTF("Process exists!\n");
-			blkif->fds[READ] = exist->fds[READ];
-			blkif->fds[WRITE] = exist->fds[WRITE];
-		}
-
-		add_disktype(blkif, type);
-		blkif->major = major;
-		blkif->minor = minor;
-
-		image = (image_t *)malloc(sizeof(image_t));
-		blkif->prv = (void *)image;
-		blkif->ops = &tapdisk_ops;
-
-		/*Retrieve the PID of the new process*/
-		if (get_tapdisk_pid(blkif) <= 0) {
-			DPRINTF("Unable to contact disk process\n");
-			goto fail;
-		}
-
-		/* Both of the following read and write calls will block up to 
-		 * max_timeout val*/
-		if (write_msg(blkif->fds[WRITE], CTLMSG_PARAMS, blkif, ptr) 
-		    <= 0) {
-			DPRINTF("Write_msg failed - CTLMSG_PARAMS\n");
-			goto fail;
-		}
-
-		if (read_msg(blkif->fds[READ], CTLMSG_IMG, blkif) <= 0) {
-			DPRINTF("Read_msg failure - CTLMSG_IMG\n");
-			goto fail;
-		}
-
-	} else return -1;
-
-	return 0;
-fail:
-	ioctl(ctlfd, BLKTAP_IOCTL_FREEINTF, minor);
-	return -EINVAL;
-}
-
-static int map_new_blktapctrl(blkif_t *blkif)
-{
-	DPRINTF("Received a poll for a new devmap\n");
-	if (write_msg(blkif->fds[WRITE], CTLMSG_NEWDEV, blkif, NULL) <= 0) {
-		DPRINTF("Write_msg failed - CTLMSG_NEWDEV\n");
-		return -EINVAL;
-	}
-
-	if (read_msg(blkif->fds[READ], CTLMSG_NEWDEV_RSP, blkif) <= 0) {
-		DPRINTF("Read_msg failed - CTLMSG_NEWDEV_RSP\n");
-		return -EINVAL;
-	}
-	DPRINTF("Exiting map_new_blktapctrl\n");
-
-	return blkif->minor - 1;
-}
-
-static int unmap_blktapctrl(blkif_t *blkif)
-{
-	DPRINTF("Unmapping vbd\n");
-
-	if (write_msg(blkif->fds[WRITE], CTLMSG_CLOSE, blkif, NULL) <= 0) {
-		DPRINTF("Write_msg failed - CTLMSG_CLOSE\n");
-		return -EINVAL;
-	}
-
-	if (del_disktype(blkif)) {
-		DPRINTF("Closing communication pipe to pid %d\n", blkif->tappid);
-		close(blkif->fds[WRITE]);
-		close(blkif->fds[READ]);
-	}
-
-	return 0;
-}
-
-int open_ctrl_socket(char *devname)
-{
-	int ret;
-	int ipc_fd;
-	fd_set socks;
-	struct timeval timeout;
-
-	if (mkdir(BLKTAP_CTRL_DIR, 0755) == 0)
-		DPRINTF("Created %s directory\n", BLKTAP_CTRL_DIR);
-	ret = mkfifo(devname,S_IRWXU|S_IRWXG|S_IRWXO);
-	if ( (ret != 0) && (errno != EEXIST) ) {
-		DPRINTF("ERROR: pipe failed (%d)\n", errno);
-		exit(0);
-	}
-
-	ipc_fd = open(devname,O_RDWR|O_NONBLOCK);
-
-	if (ipc_fd < 0) {
-		DPRINTF("FD open failed\n");
-		return -1;
-	}
-
-	return ipc_fd;
-}
-
-static void print_drivers(void)
-{
-	int i, size;
-
-	size = sizeof(dtypes)/sizeof(disk_info_t *);
-	DPRINTF("blktapctrl: v1.0.0\n");
-	for (i = 0; i < size; i++)
-		DPRINTF("Found driver: [%s]\n",dtypes[i]->name);
-} 
-
-static void write_pidfile(long pid)
-{
-	char buf[100];
-	int len;
-	int fd;
-	int flags;
-
-	fd = open(PIDFILE, O_RDWR | O_CREAT, 0600);
-	if (fd == -1) {
-		DPRINTF("Opening pid file failed (%d)\n", errno);
-		exit(1);
-	}
-
-	/* We exit silently if daemon already running. */
-	if (lockf(fd, F_TLOCK, 0) == -1)
-		exit(0);
-
-	/* Set FD_CLOEXEC, so that tapdisk doesn't get this file
-	   descriptor. */
-	if ((flags = fcntl(fd, F_GETFD)) == -1) {
-		DPRINTF("F_GETFD failed (%d)\n", errno);
-		exit(1);
-	}
-	flags |= FD_CLOEXEC;
-	if (fcntl(fd, F_SETFD, flags) == -1) {
-		DPRINTF("F_SETFD failed (%d)\n", errno);
-		exit(1);
-	}
-
-	len = snprintf(buf, sizeof(buf), "%ld\n", pid);
-	if (write(fd, buf, len) != len) {
-		DPRINTF("Writing pid file failed (%d)\n", errno);
-		exit(1);
-	}
-}
-
-int main(int argc, char *argv[])
-{
-	char *devname;
-	tapdev_info_t *ctlinfo;
-	int tap_pfd, store_pfd, xs_fd, ret, timeout, pfd_count, count=0;
-	struct xs_handle *h;
-	struct pollfd  pfd[NUM_POLL_FDS];
-	pid_t process;
-	char buf[128];
-
-	__init_blkif();
-	snprintf(buf, sizeof(buf), "BLKTAPCTRL[%d]", getpid());
-	openlog(buf, LOG_CONS|LOG_ODELAY, LOG_DAEMON);
-	if (daemon(0,0)) {
-		DPRINTF("daemon failed (%d)\n", errno);
-		goto open_failed;
-	}
-
-	print_drivers();
-	init_driver_list();
-	init_rng();
-
-	register_new_blkif_hook(blktapctrl_new_blkif);
-	register_new_devmap_hook(map_new_blktapctrl);
-	register_new_unmap_hook(unmap_blktapctrl);
-
-	ctlfd = blktap_interface_open();
-	if (ctlfd < 0) {
-		DPRINTF("couldn't open blktap interface\n");
-		goto open_failed;
-	}
-
-#ifdef MEMSHR
-	memshr_daemon_initialize();
-#endif
-
- retry:
-	/* Set up store connection and watch. */
-	h = xs_daemon_open();
-	if (h == NULL) {
-		DPRINTF("xs_daemon_open failed -- "
-			"is xenstore running?\n");
-                if (count < MAX_ATTEMPTS) {
-                        count++;
-                        sleep(2);
-                        goto retry;
-                } else goto open_failed;
-	}
-	
-	ret = setup_probe_watch(h);
-	if (ret != 0) {
-		DPRINTF("Failed adding device probewatch\n");
-		xs_daemon_close(h);
-		goto open_failed;
-	}
-
-	ioctl(ctlfd, BLKTAP_IOCTL_SETMODE, BLKTAP_MODE_INTERPOSE );
-
-	process = getpid();
-	write_pidfile(process);
-	ret = ioctl(ctlfd, BLKTAP_IOCTL_SENDPID, process );
-
-	/*Static pollhooks*/
-	pfd_count = 0;
-	tap_pfd = pfd_count++;
-	pfd[tap_pfd].fd = ctlfd;
-	pfd[tap_pfd].events = POLLIN;
-	
-	store_pfd = pfd_count++;
-	pfd[store_pfd].fd = xs_fileno(h);
-	pfd[store_pfd].events = POLLIN;
-
-	while (run) {
-		timeout = 1000; /*Milliseconds*/
-                ret = poll(pfd, pfd_count, timeout);
-
-		if (ret > 0) {
-			if (pfd[store_pfd].revents) {
-				ret = xs_fire_next_watch(h);
-			}
-		}
-	}
-
-	xs_daemon_close(h);
-	ioctl(ctlfd, BLKTAP_IOCTL_SETMODE, BLKTAP_MODE_PASSTHROUGH );
-	close(ctlfd);
-	closelog();
-
-	return 0;
-	
- open_failed:
-	DPRINTF("Unable to start blktapctrl\n");
-	closelog();
-	return -1;
-}
-
-/*
- * Local variables:
- *  c-file-style: "linux"
- *  indent-tabs-mode: t
- *  c-indent-level: 8
- *  c-basic-offset: 8
- *  tab-width: 8
- * End:
- */
diff --git a/tools/blktap/drivers/blktapctrl.h b/tools/blktap/drivers/blktapctrl.h
deleted file mode 100644
index 4512807..0000000
--- a/tools/blktap/drivers/blktapctrl.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/* blktapctrl.h
- *
- * controller image utils.
- * 
- * (c) 2004-6 Andrew Warfield and Julian Chesterfield
- *
- * 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.
- */
-
-
-int blktap_interface_open(void);
-
-int blktap_interface_create(int ctlfd, int *major, int *minor, blkif_t *blkif);
-
diff --git a/tools/blktap/drivers/blktapctrl_linux.c b/tools/blktap/drivers/blktapctrl_linux.c
deleted file mode 100644
index 6282fa6..0000000
--- a/tools/blktap/drivers/blktapctrl_linux.c
+++ /dev/null
@@ -1,89 +0,0 @@
-
-#include <stdio.h>
-#include <fcntl.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-
-#include "tapdisk.h"
-#include "blktaplib.h"
-#include "blktapctrl.h"
-
-static void make_blktap_dev(char *devname, int major, int minor)
-{
-	struct stat st;
- 
-	if (lstat(devname, &st) != 0) {
-		/*Need to create device*/
-		if (mkdir(BLKTAP_DEV_DIR, 0755) == 0)
-			DPRINTF("Created %s directory\n",BLKTAP_DEV_DIR);
-		if (mknod(devname, S_IFCHR|0600,
-			makedev(major, minor)) == 0)
-			DPRINTF("Created %s device\n",devname);
-	} else {
-		DPRINTF("%s device already exists\n",devname); 
-		/* it already exists, but is it the same major number */
-		if (((st.st_rdev>>8) & 0xff) != major) {
-			DPRINTF("%s has old major %d\n",
-				devname,
-				(unsigned int)((st.st_rdev >> 8) & 0xff));
-			/* only try again if we succed in deleting it */
-			if (!unlink(devname))
-				make_blktap_dev(devname, major, minor);
-		}
-	}
-}
-
-int blktap_interface_create(int ctlfd, int *major, int *minor, blkif_t *blkif)
-{       
-        domid_translate_t tr;
-        domid_translate_ext_t tr_ext;
-        int ret; 
-        char *devname;
-
-        if (blkif->be_id >= (1<<28)) {
-                /* new-style backend-id, so use the extended structure */
-                tr_ext.domid = blkif->domid;
-                tr_ext.busid = blkif->be_id;
-                ret = ioctl(ctlfd, BLKTAP_IOCTL_NEWINTF_EXT, &tr_ext);
-                DPRINTF("Sent domid %d and be_id %d\n", tr_ext.domid,
-                        tr_ext.busid);
-        }
-        else {
-                /* old-style backend-id; use the old structure */
-                tr.domid = blkif->domid;
-                tr.busid = (unsigned short)blkif->be_id;
-                ret = ioctl(ctlfd, BLKTAP_IOCTL_NEWINTF, tr);
-                DPRINTF("Sent domid %d and be_id %d\n", tr.domid, tr.busid);
-        }
-
-        if ( (ret <= 0)||(ret > MAX_TAP_DEV) ) {
-                DPRINTF("Incorrect Dev ID [%d]\n",ret);
-                return -1;
-        }
-
-        *minor = ret;
-        *major = ioctl(ctlfd, BLKTAP_IOCTL_MAJOR, ret );
-        if (*major < 0) {
-                DPRINTF("Incorrect Major ID [%d]\n",*major);
-                return -1;
-        }
-
-        if (asprintf(&devname,"%s/%s%d",BLKTAP_DEV_DIR, BLKTAP_DEV_NAME, *minor) == -1)
-                return -1;
-        make_blktap_dev(devname,*major,*minor);
-        DPRINTF("Received device id %d and major %d\n",
-                *minor, *major);
-        return 0;
-}
-
-
-int blktap_interface_open(void)
-{
-	int ctlfd;
-
-	ctlfd = open(BLKTAP_DEV_DIR "/" BLKTAP_DEV_NAME "0", O_RDWR);
-	if (ctlfd == -1)
-		DPRINTF("blktap0 open failed\n");
-
-	return ctlfd;
-}
diff --git a/tools/blktap/drivers/block-aio.c b/tools/blktap/drivers/block-aio.c
deleted file mode 100644
index 98727f4..0000000
--- a/tools/blktap/drivers/block-aio.c
+++ /dev/null
@@ -1,259 +0,0 @@
-/* block-aio.c
- *
- * libaio-based raw disk implementation.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- * NB: This code is not thread-safe.
- *
- * 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 <errno.h>
-#include <libaio.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include "tapdisk.h"
-#include "tapaio.h"
-#include "blk.h"
-
-#define MAX_AIO_REQS (MAX_REQUESTS * MAX_SEGMENTS_PER_REQ)
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-struct tdaio_state {
-	int fd;
-	tap_aio_context_t aio;
-};
-
-
-/*Get Image size, secsize*/
-static int get_image_info(struct td_state *s, int fd)
-{
-	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
-	struct stat stat;
-
-	ret = fstat(fd, &stat);
-	if (ret != 0) {
-		DPRINTF("ERROR: fstat failed, Couldn't stat image");
-		return -EINVAL;
-	}
-
-	if (S_ISBLK(stat.st_mode)) {
-		/*Accessing block device directly*/
-		if (blk_getimagesize(fd, &s->size) != 0)
-			return -EINVAL;
-
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-
-		/*Get the sector size*/
-		if (blk_getsectorsize(fd, &s->sector_size) != 0)
-			s->sector_size = DEFAULT_SECTOR_SIZE;
-
-	} else {
-		/*Local file? try fstat instead*/
-		s->size = (stat.st_size >> SECTOR_SHIFT);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-	}
-
-	if (s->size == 0) {		
-		s->size =((uint64_t) 16836057);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-	}
-	s->info = 0;
-
-	return 0;
-}
-
-static inline void init_fds(struct disk_driver *dd)
-{
-	int i;
-	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
-
-	for(i = 0; i < MAX_IOFD; i++) 
-		dd->io_fd[i] = 0;
-
-	dd->io_fd[0] = prv->aio.aio_ctx.pollfd;
-}
-
-/* Open the disk file and initialize aio state. */
-static int tdaio_open (struct disk_driver *dd, const char *name, td_flag_t flags)
-{
-	int i, fd, ret = 0, o_flags;
-	struct td_state    *s   = dd->td_state;
-	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
-
-	DPRINTF("block-aio open('%s')", name);
-
-	/* Initialize AIO */
-	ret = tap_aio_init(&prv->aio, 0, MAX_AIO_REQS);
-	if (ret != 0)
-		return ret;
-
-	/* Open the file */
-	o_flags = O_DIRECT | O_LARGEFILE | 
-		((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-        fd = open(name, o_flags);
-
-        if ( (fd == -1) && (errno == EINVAL) ) {
-
-                /* Maybe O_DIRECT isn't supported. */
-		o_flags &= ~O_DIRECT;
-                fd = open(name, o_flags);
-                if (fd != -1) DPRINTF("WARNING: Accessing image without"
-                                     "O_DIRECT! (%s)\n", name);
-
-        } else if (fd != -1) DPRINTF("open(%s) with O_DIRECT\n", name);
-	
-        if (fd == -1) {
-		DPRINTF("Unable to open [%s] (%d)!\n", name, 0 - errno);
-        	ret = 0 - errno;
-        	goto done;
-        }
-
-        prv->fd = fd;
-
-	init_fds(dd);
-	ret = get_image_info(s, fd);
-
-done:
-	return ret;	
-}
-
-static int tdaio_queue_read(struct disk_driver *dd, uint64_t sector,
-		     int nb_sectors, char *buf, td_callback_t cb,
-		     int id, void *private)
-{
-	struct   td_state    *s   = dd->td_state;
-	struct   tdaio_state *prv = (struct tdaio_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-
-	return tap_aio_read(&prv->aio, prv->fd, size, offset, buf, 
-		cb, id, sector, private);
-}
-			
-static int tdaio_queue_write(struct disk_driver *dd, uint64_t sector,
-		      int nb_sectors, char *buf, td_callback_t cb,
-		      int id, void *private)
-{
-	struct   td_state    *s   = dd->td_state;
-	struct   tdaio_state *prv = (struct tdaio_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-
-	return tap_aio_write(&prv->aio, prv->fd, size, offset, buf,
-		cb, id, sector, private);
-}
-
-static int tdaio_submit(struct disk_driver *dd)
-{
-	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
-
-	return tap_aio_submit(&prv->aio);
-}
-			
-static int tdaio_close(struct disk_driver *dd)
-{
-	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
-	
-	io_destroy(prv->aio.aio_ctx.aio_ctx);
-	close(prv->fd);
-
-	return 0;
-}
-
-static int tdaio_do_callbacks(struct disk_driver *dd, int sid)
-{
-	int i, nr_events, rsp = 0;
-	struct io_event *ep;
-	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
-
-	nr_events = tap_aio_get_events(&prv->aio.aio_ctx);
-repeat:
-	for (ep = prv->aio.aio_events, i = nr_events; i-- > 0; ep++) {
-		struct iocb        *io  = ep->obj;
-		struct pending_aio *pio;
-		
-		pio = &prv->aio.pending_aio[(long)io->data];
-		rsp += pio->cb(dd, ep->res == io->u.c.nbytes ? 0 : 1,
-			       pio->sector, io->u.c.nbytes >> 9, 
-			       pio->id, pio->private);
-
-		prv->aio.iocb_free[prv->aio.iocb_free_count++] = io;
-	}
-
-	if (nr_events) {
-		nr_events = tap_aio_more_events(&prv->aio.aio_ctx);
-		goto repeat;
-	}
-
-	tap_aio_continue(&prv->aio.aio_ctx);
-
-	return rsp;
-}
-
-static int tdaio_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	return TD_NO_PARENT;
-}
-
-static int tdaio_validate_parent(struct disk_driver *dd, 
-			  struct disk_driver *parent, td_flag_t flags)
-{
-	return -EINVAL;
-}
-
-struct tap_disk tapdisk_aio = {
-	.disk_type          = "tapdisk_aio",
-	.private_data_size  = sizeof(struct tdaio_state),
-	.td_open            = tdaio_open,
-	.td_queue_read      = tdaio_queue_read,
-	.td_queue_write     = tdaio_queue_write,
-	.td_submit          = tdaio_submit,
-	.td_close           = tdaio_close,
-	.td_do_callbacks    = tdaio_do_callbacks,
-	.td_get_parent_id   = tdaio_get_parent_id,
-	.td_validate_parent = tdaio_validate_parent
-};
diff --git a/tools/blktap/drivers/block-qcow.c b/tools/blktap/drivers/block-qcow.c
deleted file mode 100644
index 0e4e9cf..0000000
--- a/tools/blktap/drivers/block-qcow.c
+++ /dev/null
@@ -1,1434 +0,0 @@
-/* block-qcow.c
- *
- * Asynchronous Qemu copy-on-write disk implementation.
- * Code based on the Qemu implementation
- * (see copyright notice below)
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- */
-
-/*
- * Block driver for the QCOW format
- * 
- * Copyright (c) 2004 Fabrice Bellard
- * 
- * 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:
- */
-
-#include <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include <zlib.h>
-#include <inttypes.h>
-#include <libaio.h>
-#include "bswap.h"
-#include "aes.h"
-#include "tapdisk.h"
-#include "tapaio.h"
-#include "blk.h"
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-#if 1
-#define ASSERT(_p) \
-    if ( !(_p) ) { DPRINTF("Assertion '%s' failed, line %d, file %s", #_p , \
-    __LINE__, __FILE__); *(int*)0=0; }
-#else
-#define ASSERT(_p) ((void)0)
-#endif
-
-#define ROUNDUP(l, s) \
-({ \
-    (uint64_t)( \
-        ((l) + ((s) - 1)) - (((l) + ((s) - 1)) % (s))); \
-})
-
-#undef IOCB_IDX
-#define IOCB_IDX(_s, _io) ((_io) - (_s)->iocb_list)
-
-#define ZERO_TEST(_b) (_b | 0x00)
-
-/**************************************************************/
-/* QEMU COW block driver with compression and encryption support */
-
-#define QCOW_MAGIC (('Q' << 24) | ('F' << 16) | ('I' << 8) | 0xfb)
-#define XEN_MAGIC  (('X' << 24) | ('E' << 16) | ('N' << 8) | 0xfb)
-#define QCOW_VERSION 1
-
-#define QCOW_CRYPT_NONE 0x00
-#define QCOW_CRYPT_AES  0x01
-
-#define QCOW_OFLAG_COMPRESSED (1LL << 63)
-#define SPARSE_FILE 0x01
-#define EXTHDR_L1_BIG_ENDIAN 0x02
-
-#ifndef O_BINARY
-#define O_BINARY 0
-#endif
-
-typedef struct QCowHeader {
-	uint32_t magic;
-	uint32_t version;
-	uint64_t backing_file_offset;
-	uint32_t backing_file_size;
-	uint32_t mtime;
-	uint64_t size; /* in bytes */
-	uint8_t cluster_bits;
-	uint8_t l2_bits;
-	uint32_t crypt_method;
-	uint64_t l1_table_offset;
-} QCowHeader;
-
-/*Extended header for Xen enhancements*/
-typedef struct QCowHeader_ext {
-        uint32_t xmagic;
-        uint32_t cksum;
-        uint32_t min_cluster_alloc;
-        uint32_t flags;
-} QCowHeader_ext;
-
-#define L2_CACHE_SIZE 16  /*Fixed allocation in Qemu*/
-
-struct tdqcow_state {
-        int fd;                        /*Main Qcow file descriptor */
-	uint64_t fd_end;               /*Store a local record of file length */
-	char *name;                    /*Record of the filename*/
-	uint32_t backing_file_size;
-	uint64_t backing_file_offset;
-	int encrypted;                 /*File contents are encrypted or plain*/
-	int cluster_bits;              /*Determines length of cluster as 
-					*indicated by file hdr*/
-	int cluster_size;              /*Length of cluster*/
-	int cluster_sectors;           /*Number of sectors per cluster*/
-	int cluster_alloc;             /*Blktap fix for allocating full 
-					*extents*/
-	int min_cluster_alloc;         /*Blktap historical extent alloc*/
-	int sparse;                    /*Indicates whether to preserve sparseness*/
-	int l2_bits;                   /*Size of L2 table entry*/
-	int l2_size;                   /*Full table size*/
-	int l1_size;                   /*L1 table size*/
-	uint64_t cluster_offset_mask;    
-	uint64_t l1_table_offset;      /*L1 table offset from beginning of 
-					*file*/
-	uint64_t *l1_table;            /*L1 table entries*/
-	uint64_t *l2_cache;            /*We maintain a cache of size 
-					*L2_CACHE_SIZE of most read entries*/
-	uint64_t l2_cache_offsets[L2_CACHE_SIZE];     /*L2 cache entries*/
-	uint32_t l2_cache_counts[L2_CACHE_SIZE];      /*Cache access record*/
-	uint8_t *cluster_cache;          
-	uint8_t *cluster_data;
-	uint64_t cluster_cache_offset; /**/
-	uint32_t crypt_method;         /*current crypt method, 0 if no 
-					*key yet */
-	uint32_t crypt_method_header;  /**/
-	AES_KEY aes_encrypt_key;       /*AES key*/
-	AES_KEY aes_decrypt_key;       /*AES key*/
-        
-	/* libaio state */
-	tap_aio_context_t	aio;
-};
-
-static int decompress_cluster(struct tdqcow_state *s, uint64_t cluster_offset);
-
-#ifdef USE_GCRYPT
-
-#include <gcrypt.h>
-
-static uint32_t gen_cksum(char *ptr, int len)
-{
-	int i;
-	uint32_t md[4];
-
-	/* Convert L1 table to big endian */
-	for(i = 0; i < len / sizeof(uint64_t); i++) {
-		cpu_to_be64s(&((uint64_t*) ptr)[i]);
-	}
-
-	/* Generate checksum */
-	gcry_md_hash_buffer(GCRY_MD_MD5, md, ptr, len);
-
-	/* Convert L1 table back to native endianess */
-	for(i = 0; i < len / sizeof(uint64_t); i++) {
-		be64_to_cpus(&((uint64_t*) ptr)[i]);
-	}
-
-	return md[0];
-}
-
-#else /* use libcrypto */
-
-#include <openssl/md5.h>
-
-static uint32_t gen_cksum(char *ptr, int len)
-{
-	int i;
-	unsigned char *md;
-	uint32_t ret;
-
-	md = malloc(MD5_DIGEST_LENGTH);
-	if(!md) return 0;
-
-	/* Convert L1 table to big endian */
-	for(i = 0; i < len / sizeof(uint64_t); i++) {
-		cpu_to_be64s(&((uint64_t*) ptr)[i]);
-	}
-
-	/* Generate checksum */
-	if (MD5((unsigned char *)ptr, len, md) != md)
-		ret = 0;
-	else
-		memcpy(&ret, md, sizeof(uint32_t));
-
-	/* Convert L1 table back to native endianess */
-	for(i = 0; i < len / sizeof(uint64_t); i++) {
-		be64_to_cpus(&((uint64_t*) ptr)[i]);
-	}
-
-	free(md);
-	return ret;
-}
-
-#endif
-
-static int get_filesize(char *filename, uint64_t *size, struct stat *st)
-{
-	int fd;
-	QCowHeader header;
-
-	/*Set to the backing file size*/
-	fd = open(filename, O_RDONLY);
-	if (fd < 0)
-		return -1;
-	if (read(fd, &header, sizeof(header)) < sizeof(header)) {
-		close(fd);
-		return -1;
-	}
-	close(fd);
-	
-	be32_to_cpus(&header.magic);
-	be64_to_cpus(&header.size);
-	if (header.magic == QCOW_MAGIC) {
-		*size = header.size >> SECTOR_SHIFT;
-		return 0;
-	}
-
-	if(S_ISBLK(st->st_mode)) {
-		fd = open(filename, O_RDONLY);
-		if (fd < 0)
-			return -1;
-		if (blk_getimagesize(fd, size) != 0) {
-			close(fd);
-			return -1;
-		}
-		close(fd);
-	} else *size = (st->st_size >> SECTOR_SHIFT);	
-	return 0;
-}
-
-static int qcow_set_key(struct tdqcow_state *s, const char *key)
-{
-	uint8_t keybuf[16];
-	int len, i;
-	
-	memset(keybuf, 0, 16);
-	len = strlen(key);
-	if (len > 16)
-		len = 16;
-	/* XXX: we could compress the chars to 7 bits to increase
-	   entropy */
-	for (i = 0; i < len; i++) {
-		keybuf[i] = key[i];
-	}
-	s->crypt_method = s->crypt_method_header;
-	
-	if (AES_set_encrypt_key(keybuf, 128, &s->aes_encrypt_key) != 0)
-		return -1;
-	if (AES_set_decrypt_key(keybuf, 128, &s->aes_decrypt_key) != 0)
-		return -1;
-#if 0
-	/* test */
-	{
-		uint8_t in[16];
-		uint8_t out[16];
-		uint8_t tmp[16];
-		for (i=0; i<16; i++)
-			in[i] = i;
-		AES_encrypt(in, tmp, &s->aes_encrypt_key);
-		AES_decrypt(tmp, out, &s->aes_decrypt_key);
-		for (i = 0; i < 16; i++)
-			DPRINTF(" %02x", tmp[i]);
-		DPRINTF("\n");
-		for (i = 0; i < 16; i++)
-			DPRINTF(" %02x", out[i]);
-		DPRINTF("\n");
-	}
-#endif
-	return 0;
-}
-
-/* 
- * The crypt function is compatible with the linux cryptoloop
- * algorithm for < 4 GB images. NOTE: out_buf == in_buf is
- * supported .
- */
-static void encrypt_sectors(struct tdqcow_state *s, int64_t sector_num,
-                            uint8_t *out_buf, const uint8_t *in_buf,
-                            int nb_sectors, int enc,
-                            const AES_KEY *key)
-{
-	union {
-		uint64_t ll[2];
-		uint8_t b[16];
-	} ivec;
-	int i;
-	
-	for (i = 0; i < nb_sectors; i++) {
-		ivec.ll[0] = cpu_to_le64(sector_num);
-		ivec.ll[1] = 0;
-		AES_cbc_encrypt(in_buf, out_buf, 512, key, 
-				ivec.b, enc);
-		sector_num++;
-		in_buf += 512;
-		out_buf += 512;
-	}
-}
-
-static int qtruncate(int fd, off_t length, int sparse)
-{
-	int ret, i; 
-	int current = 0, rem = 0;
-	uint64_t sectors;
-	struct stat st;
-	char *buf;
-
-	/* If length is greater than the current file len
-	 * we synchronously write zeroes to the end of the 
-	 * file, otherwise we truncate the length down
-	 */
-	ret = fstat(fd, &st);
-	if (ret == -1) 
-		return -1;
-	if (S_ISBLK(st.st_mode))
-		return 0;
-
-	sectors = (length + DEFAULT_SECTOR_SIZE - 1)/DEFAULT_SECTOR_SIZE;
-	current = (st.st_size + DEFAULT_SECTOR_SIZE - 1)/DEFAULT_SECTOR_SIZE;
-	rem     = st.st_size % DEFAULT_SECTOR_SIZE;
-
-	/* If we are extending this file, we write zeros to the end --
-	 * this tries to ensure that the extents allocated wind up being
-	 * contiguous on disk.
-	 */
-	if(st.st_size < sectors * DEFAULT_SECTOR_SIZE) {
-		/*We are extending the file*/
-		if ((ret = posix_memalign((void **)&buf, 
-					  512, DEFAULT_SECTOR_SIZE))) {
-			DPRINTF("posix_memalign failed: %d\n", ret);
-			return -1;
-		}
-		memset(buf, 0x00, DEFAULT_SECTOR_SIZE);
-		if (lseek(fd, 0, SEEK_END)==-1) {
-			DPRINTF("Lseek EOF failed (%d), internal error\n",
-				errno);
-			free(buf);
-			return -1;
-		}
-		if (rem) {
-			ret = write(fd, buf, rem);
-			if (ret != rem) {
-				DPRINTF("write failed: ret = %d, err = %s\n",
-					ret, strerror(errno));
-				free(buf);
-				return -1;
-			}
-		}
-		for (i = current; i < sectors; i++ ) {
-			ret = write(fd, buf, DEFAULT_SECTOR_SIZE);
-			if (ret != DEFAULT_SECTOR_SIZE) {
-				DPRINTF("write failed: ret = %d, err = %s\n",
-					ret, strerror(errno));
-				free(buf);
-				return -1;
-			}
-		}
-		free(buf);
-	} else if(sparse && (st.st_size > sectors * DEFAULT_SECTOR_SIZE))
-		if (ftruncate(fd, (off_t)sectors * DEFAULT_SECTOR_SIZE)==-1) {
-			DPRINTF("Ftruncate failed (%s)\n", strerror(errno));
-			return -1;
-		}
-	return 0;
-}
-
-
-/* 'allocate' is:
- *
- * 0 to not allocate.
- *
- * 1 to allocate a normal cluster (for sector indexes 'n_start' to
- * 'n_end')
- *
- * 2 to allocate a compressed cluster of size
- * 'compressed_size'. 'compressed_size' must be > 0 and <
- * cluster_size 
- *
- * return 0 if not allocated.
- */
-static uint64_t get_cluster_offset(struct tdqcow_state *s,
-                                   uint64_t offset, int allocate,
-                                   int compressed_size,
-                                   int n_start, int n_end)
-{
-	int min_index, i, j, l1_index, l2_index, l2_sector, l1_sector;
-	char *tmp_ptr2, *l2_ptr, *l1_ptr;
-	uint64_t *tmp_ptr;
-	uint64_t l2_offset, *l2_table, cluster_offset, tmp;
-	uint32_t min_count;
-	int new_l2_table;
-
-	/*Check L1 table for the extent offset*/
-	l1_index = offset >> (s->l2_bits + s->cluster_bits);
-	l2_offset = s->l1_table[l1_index];
-	new_l2_table = 0;
-	if (!l2_offset) {
-		if (!allocate)
-			return 0;
-		/* 
-		 * allocating a new l2 entry + extent 
-		 * at the end of the file, we must also
-		 * update the L1 entry safely.
-		 */
-		l2_offset = s->fd_end;
-
-		/* round to cluster size */
-		l2_offset = (l2_offset + s->cluster_size - 1) 
-			& ~(s->cluster_size - 1);
-
-		/* update the L1 entry */
-		s->l1_table[l1_index] = l2_offset;
-		tmp = cpu_to_be64(l2_offset);
-		
-		/*Truncate file for L2 table 
-		 *(initialised to zero in case we crash)*/
-		if (qtruncate(s->fd, 
-			      l2_offset + (s->l2_size * sizeof(uint64_t)),
-			      s->sparse) != 0) {
-			DPRINTF("ERROR truncating file\n");
-			return 0;
-		}
-		s->fd_end = l2_offset + (s->l2_size * sizeof(uint64_t));
-
-		/*Update the L1 table entry on disk
-                 * (for O_DIRECT we write 4KByte blocks)*/
-		l1_sector = (l1_index * sizeof(uint64_t)) >> 12;
-		l1_ptr = (char *)s->l1_table + (l1_sector << 12);
-
-		if (posix_memalign((void **)&tmp_ptr, 4096, 4096) != 0) {
-			DPRINTF("ERROR allocating memory for L1 table\n");
-		}
-		memcpy(tmp_ptr, l1_ptr, 4096);
-
-		/* Convert block to write to big endian */
-		for(i = 0; i < 4096 / sizeof(uint64_t); i++) {
-			cpu_to_be64s(&tmp_ptr[i]);
-		}
-
-		/*
-		 * Issue non-asynchronous L1 write.
-		 * For safety, we must ensure that
-		 * entry is written before blocks.
-		 */
-		lseek(s->fd, s->l1_table_offset + (l1_sector << 12), SEEK_SET);
-		if (write(s->fd, tmp_ptr, 4096) != 4096) {
-			free(tmp_ptr);
-		 	return 0;
-		}
-		free(tmp_ptr);
-
-		new_l2_table = 1;
-		goto cache_miss;
-	} else if (s->min_cluster_alloc == s->l2_size) {
-		/*Fast-track the request*/
-		cluster_offset = l2_offset + (s->l2_size * sizeof(uint64_t));
-		l2_index = (offset >> s->cluster_bits) & (s->l2_size - 1);
-		return cluster_offset + (l2_index * s->cluster_size);
-	}
-
-	/*Check to see if L2 entry is already cached*/
-	for (i = 0; i < L2_CACHE_SIZE; i++) {
-		if (l2_offset == s->l2_cache_offsets[i]) {
-			/* increment the hit count */
-			if (++s->l2_cache_counts[i] == 0xffffffff) {
-				for (j = 0; j < L2_CACHE_SIZE; j++) {
-					s->l2_cache_counts[j] >>= 1;
-				}
-			}
-			l2_table = s->l2_cache + (i << s->l2_bits);
-			goto found;
-		}
-	}
-
-cache_miss:
-	/* not found: load a new entry in the least used one */
-	min_index = 0;
-	min_count = 0xffffffff;
-	for (i = 0; i < L2_CACHE_SIZE; i++) {
-		if (s->l2_cache_counts[i] < min_count) {
-			min_count = s->l2_cache_counts[i];
-			min_index = i;
-		}
-	}
-	l2_table = s->l2_cache + (min_index << s->l2_bits);
-
-	/*If extent pre-allocated, read table from disk, 
-	 *otherwise write new table to disk*/
-	if (new_l2_table) {
-		/*Should we allocate the whole extent? Adjustable parameter.*/
-		if (s->cluster_alloc == s->l2_size) {
-			cluster_offset = l2_offset + 
-				(s->l2_size * sizeof(uint64_t));
-			cluster_offset = (cluster_offset + s->cluster_size - 1)
-				& ~(s->cluster_size - 1);
-			if (qtruncate(s->fd, cluster_offset + 
-				  (s->cluster_size * s->l2_size), 
-				      s->sparse) != 0) {
-				DPRINTF("ERROR truncating file\n");
-				return 0;
-			}
-			s->fd_end = cluster_offset + 
-				(s->cluster_size * s->l2_size);
-			for (i = 0; i < s->l2_size; i++) {
-				l2_table[i] = cpu_to_be64(cluster_offset + 
-							  (i*s->cluster_size));
-			}  
-		} else memset(l2_table, 0, s->l2_size * sizeof(uint64_t));
-
-		lseek(s->fd, l2_offset, SEEK_SET);
-		if (write(s->fd, l2_table, s->l2_size * sizeof(uint64_t)) !=
-		   s->l2_size * sizeof(uint64_t))
-			return 0;
-	} else {
-		lseek(s->fd, l2_offset, SEEK_SET);
-		if (read(s->fd, l2_table, s->l2_size * sizeof(uint64_t)) != 
-		    s->l2_size * sizeof(uint64_t))
-			return 0;
-	}
-	
-	/*Update the cache entries*/ 
-	s->l2_cache_offsets[min_index] = l2_offset;
-	s->l2_cache_counts[min_index] = 1;
-
-found:
-	/*The extent is split into 's->l2_size' blocks of 
-	 *size 's->cluster_size'*/
-	l2_index = (offset >> s->cluster_bits) & (s->l2_size - 1);
-	cluster_offset = be64_to_cpu(l2_table[l2_index]);
-
-	if (!cluster_offset || 
-	    ((cluster_offset & QCOW_OFLAG_COMPRESSED) && allocate == 1) ) {
-		if (!allocate)
-			return 0;
-		
-		if ((cluster_offset & QCOW_OFLAG_COMPRESSED) &&
-		    (n_end - n_start) < s->cluster_sectors) {
-			/* cluster is already allocated but compressed, we must
-			   decompress it in the case it is not completely
-			   overwritten */
-			if (decompress_cluster(s, cluster_offset) < 0)
-				return 0;
-			cluster_offset = lseek(s->fd, s->fd_end, SEEK_SET);
-			cluster_offset = (cluster_offset + s->cluster_size - 1)
-				& ~(s->cluster_size - 1);
-			/* write the cluster content - not asynchronous */
-			lseek(s->fd, cluster_offset, SEEK_SET);
-			if (write(s->fd, s->cluster_cache, s->cluster_size) != 
-			    s->cluster_size)
-			    return -1;
-		} else {
-			/* allocate a new cluster */
-			cluster_offset = lseek(s->fd, s->fd_end, SEEK_SET);
-			if (allocate == 1) {
-				/* round to cluster size */
-				cluster_offset = 
-					(cluster_offset + s->cluster_size - 1) 
-					& ~(s->cluster_size - 1);
-				if (qtruncate(s->fd, cluster_offset + 
-					      s->cluster_size, s->sparse)!=0) {
-					DPRINTF("ERROR truncating file\n");
-					return 0;
-				}
-				s->fd_end = (cluster_offset + s->cluster_size);
-				/* if encrypted, we must initialize the cluster
-				   content which won't be written */
-				if (s->crypt_method && 
-				    (n_end - n_start) < s->cluster_sectors) {
-					uint64_t start_sect;
-					start_sect = (offset & 
-						      ~(s->cluster_size - 1)) 
-							      >> 9;
-					memset(s->cluster_data + 512, 
-					       0xaa, 512);
-					for (i = 0; i < s->cluster_sectors;i++)
-					{
-						if (i < n_start || i >= n_end) 
-						{
-							encrypt_sectors(s, start_sect + i, 
-									s->cluster_data, 
-									s->cluster_data + 512, 1, 1,
-									&s->aes_encrypt_key);
-							lseek(s->fd, cluster_offset + i * 512, SEEK_SET);
-							if (write(s->fd, s->cluster_data, 512) != 512)
-								return -1;
-						}
-					}
-				}
-			} else {
-				cluster_offset |= QCOW_OFLAG_COMPRESSED | 
-					(uint64_t)compressed_size 
-						<< (63 - s->cluster_bits);
-			}
-		}
-		/* update L2 table */
-		tmp = cpu_to_be64(cluster_offset);
-		l2_table[l2_index] = tmp;
-
-		/*For IO_DIRECT we write 4KByte blocks*/
-		l2_sector = (l2_index * sizeof(uint64_t)) >> 12;
-		l2_ptr = (char *)l2_table + (l2_sector << 12);
-		
-		if (posix_memalign((void **)&tmp_ptr2, 4096, 4096) != 0) {
-			DPRINTF("ERROR allocating memory for L1 table\n");
-		}
-		memcpy(tmp_ptr2, l2_ptr, 4096);
-		lseek(s->fd, l2_offset + (l2_sector << 12), SEEK_SET);
-		if (write(s->fd, tmp_ptr2, 4096) != 4096) {
-			free(tmp_ptr2);
-			return -1;
-		}
-		free(tmp_ptr2);
-	}
-	return cluster_offset;
-}
-
-static void init_cluster_cache(struct disk_driver *dd)
-{
-	struct td_state     *bs = dd->td_state;
-	struct tdqcow_state *s  = (struct tdqcow_state *)dd->private;
-	uint32_t count = 0;
-	int i, cluster_entries;
-
-	cluster_entries = s->cluster_size / 512;
-	DPRINTF("Initialising Cluster cache, %d sectors per cluster (%d cluster size)\n",
-		cluster_entries, s->cluster_size);
-
-	for (i = 0; i < bs->size; i += cluster_entries) {
-		if (get_cluster_offset(s, i << 9, 0, 0, 0, 1)) count++;
-		if (count >= L2_CACHE_SIZE) return;
-	}
-	DPRINTF("Finished cluster initialisation, added %d entries\n", count);
-	return;
-}
-
-static int qcow_is_allocated(struct tdqcow_state *s, int64_t sector_num,
-                             int nb_sectors, int *pnum)
-{
-	int index_in_cluster, n;
-	uint64_t cluster_offset;
-
-	cluster_offset = get_cluster_offset(s, sector_num << 9, 0, 0, 0, 0);
-	index_in_cluster = sector_num & (s->cluster_sectors - 1);
-	n = s->cluster_sectors - index_in_cluster;
-	if (n > nb_sectors)
-		n = nb_sectors;
-	*pnum = n;
-	return (cluster_offset != 0);
-}
-
-static int decompress_buffer(uint8_t *out_buf, int out_buf_size,
-                             const uint8_t *buf, int buf_size)
-{
-	z_stream strm1, *strm = &strm1;
-	int ret, out_len;
-	
-	memset(strm, 0, sizeof(*strm));
-	
-	strm->next_in = (uint8_t *)buf;
-	strm->avail_in = buf_size;
-	strm->next_out = out_buf;
-	strm->avail_out = out_buf_size;
-	
-	ret = inflateInit2(strm, -12);
-	if (ret != Z_OK)
-		return -1;
-	ret = inflate(strm, Z_FINISH);
-	out_len = strm->next_out - out_buf;
-	if ( (ret != Z_STREAM_END && ret != Z_BUF_ERROR) ||
-	    (out_len != out_buf_size) ) {
-		inflateEnd(strm);
-		return -1;
-	}
-	inflateEnd(strm);
-	return 0;
-}
-                              
-static int decompress_cluster(struct tdqcow_state *s, uint64_t cluster_offset)
-{
-	int ret, csize;
-	uint64_t coffset;
-
-	coffset = cluster_offset & s->cluster_offset_mask;
-	if (s->cluster_cache_offset != coffset) {
-		csize = cluster_offset >> (63 - s->cluster_bits);
-		csize &= (s->cluster_size - 1);
-		lseek(s->fd, coffset, SEEK_SET);
-		ret = read(s->fd, s->cluster_data, csize);
-		if (ret != csize) 
-			return -1;
-		if (decompress_buffer(s->cluster_cache, s->cluster_size,
-				      s->cluster_data, csize) < 0) {
-			return -1;
-		}
-		s->cluster_cache_offset = coffset;
-	}
-	return 0;
-}
-
-static inline void init_fds(struct disk_driver *dd)
-{
-	int i;
-	struct tdqcow_state *s = (struct tdqcow_state *)dd->private;
-
-	for(i = 0; i < MAX_IOFD; i++) 
-		dd->io_fd[i] = 0;
-
-	dd->io_fd[0] = s->aio.aio_ctx.pollfd;
-}
-
-/* Open the disk file and initialize qcow state. */
-static int tdqcow_open (struct disk_driver *dd, const char *name, td_flag_t flags)
-{
-	int fd, len, i, shift, ret, size, l1_table_size, o_flags, l1_table_block;
-	int max_aio_reqs;
-	struct td_state     *bs = dd->td_state;
-	struct tdqcow_state *s  = (struct tdqcow_state *)dd->private;
-	char *buf, *buf2;
-	QCowHeader *header;
-	QCowHeader_ext *exthdr;
-	uint32_t cksum;
-	uint64_t final_cluster = 0;
-
- 	DPRINTF("QCOW: Opening %s\n",name);
-
-	o_flags = O_DIRECT | O_LARGEFILE | 
-		((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-	fd = open(name, o_flags);
-	if (fd < 0) {
-		DPRINTF("Unable to open %s (%d)\n",name,0 - errno);
-		return -1;
-	}
-
-	s->fd = fd;
-	if (asprintf(&s->name,"%s", name) == -1) {
-		close(fd);
-		return -1;
-	}
-
-	ASSERT(sizeof(QCowHeader) + sizeof(QCowHeader_ext) < 512);
-
-	ret = posix_memalign((void **)&buf, 512, 512);
-	if (ret != 0) goto fail;
-
-	if (read(fd, buf, 512) != 512)
-		goto fail;
-
-	header = (QCowHeader *)buf;
-	be32_to_cpus(&header->magic);
-	be32_to_cpus(&header->version);
-	be64_to_cpus(&header->backing_file_offset);
-	be32_to_cpus(&header->backing_file_size);
-	be32_to_cpus(&header->mtime);
-	be64_to_cpus(&header->size);
-	be32_to_cpus(&header->crypt_method);
-	be64_to_cpus(&header->l1_table_offset);
-
-	if (header->magic != QCOW_MAGIC)
-		goto fail;
-
-	switch (header->version) {
-	case QCOW_VERSION:
-		break;
-	case 2:
-		close(fd);
-		dd->drv = &tapdisk_qcow2;
-		return dd->drv->td_open(dd, name, flags);
-	default:
-		goto fail;
-	}
-
-	if (header->size <= 1 || header->cluster_bits < 9)
-		goto fail;
-	if (header->crypt_method > QCOW_CRYPT_AES)
-		goto fail;
-	s->crypt_method_header = header->crypt_method;
-	if (s->crypt_method_header)
-		s->encrypted = 1;
-	s->cluster_bits = header->cluster_bits;
-	s->cluster_size = 1 << s->cluster_bits;
-	s->cluster_sectors = 1 << (s->cluster_bits - 9);
-	s->l2_bits = header->l2_bits;
-	s->l2_size = 1 << s->l2_bits;
-	s->cluster_alloc = s->l2_size;
-	bs->size = header->size / 512;
-	s->cluster_offset_mask = (1LL << (63 - s->cluster_bits)) - 1;
-	s->backing_file_offset = header->backing_file_offset;
-	s->backing_file_size   = header->backing_file_size;
-
-	/* read the level 1 table */
-	shift = s->cluster_bits + s->l2_bits;
-	s->l1_size = ROUNDUP(header->size, 1LL << shift);
-	
-	s->l1_table_offset = header->l1_table_offset;
-
-	/*allocate a 4Kbyte multiple of memory*/
-	l1_table_size = s->l1_size * sizeof(uint64_t);
-	if (l1_table_size % 4096 > 0) {
-		l1_table_size = ROUNDUP(l1_table_size, 4096);
-	}
-	ret = posix_memalign((void **)&s->l1_table, 4096, l1_table_size);
-	if (ret != 0) goto fail;
-
-	memset(s->l1_table, 0x00, l1_table_size);
-
-	DPRINTF("L1 Table offset detected: %llu, size %d (%d)\n",
-		(long long)s->l1_table_offset,
-		(int) (s->l1_size * sizeof(uint64_t)), 
-		l1_table_size);
-
-	lseek(fd, 0, SEEK_SET);
-	l1_table_block = l1_table_size + s->l1_table_offset;
-	l1_table_block = ROUNDUP(l1_table_block, 512);
-	ret = posix_memalign((void **)&buf2, 4096, l1_table_block);
-	if (ret != 0) goto fail;
-	if (read(fd, buf2, l1_table_block) < l1_table_size + s->l1_table_offset)
-		goto fail;
-	memcpy(s->l1_table, buf2 + s->l1_table_offset, l1_table_size);
-
-	for(i = 0; i < s->l1_size; i++) {
-		be64_to_cpus(&s->l1_table[i]);
-		//DPRINTF("L1[%d] => %llu\n", i, s->l1_table[i]);
-		if (s->l1_table[i] > final_cluster)
-			final_cluster = s->l1_table[i];
-	}
-
-	/* alloc L2 cache */
-	size = s->l2_size * L2_CACHE_SIZE * sizeof(uint64_t);
-	ret = posix_memalign((void **)&s->l2_cache, 4096, size);
-	if(ret != 0) goto fail;
-
-	size = s->cluster_size;
-	ret = posix_memalign((void **)&s->cluster_cache, 4096, size);
-	if(ret != 0) goto fail;
-
-	ret = posix_memalign((void **)&s->cluster_data, 4096, size);
-	if(ret != 0) goto fail;
-	s->cluster_cache_offset = -1;
-
-	if (s->backing_file_offset != 0)
-		s->cluster_alloc = 1; /*Cannot use pre-alloc*/
-
-        bs->sector_size = 512;
-        bs->info = 0;
-	
-	/*Detect min_cluster_alloc*/
-	s->min_cluster_alloc = 1; /*Default*/
-	if (s->backing_file_offset == 0 && s->l1_table_offset % 4096 == 0) {
-		/*We test to see if the xen magic # exists*/
-		exthdr = (QCowHeader_ext *)(buf + sizeof(QCowHeader));
-		be32_to_cpus(&exthdr->xmagic);
-		if(exthdr->xmagic != XEN_MAGIC) 
-			goto end_xenhdr;
-	
-		be32_to_cpus(&exthdr->flags);
-		/* Try to detect old tapdisk images. They have to be fixed because 
-		 * they don't use big endian but native endianess for the L1 table */
-		if ((exthdr->flags & EXTHDR_L1_BIG_ENDIAN) == 0) {
-			QCowHeader_ext *tmphdr = (QCowHeader_ext *)(buf2 + sizeof(QCowHeader));
-			/* 
-			   The image is broken. Fix it. The L1 table has already been 
-			   byte-swapped, so we can write it to the image file as it is
-			   currently in memory. Then swap it back to native endianess
-			   for operation.
-			 */
-
-			/* Change ENDIAN flag and copy it to store buffer */
-			exthdr->flags |= EXTHDR_L1_BIG_ENDIAN;
-			tmphdr->flags = cpu_to_be32(exthdr->flags);
-
-
-			DPRINTF("qcow: Converting image to big endian L1 table\n");
-
-			memcpy(buf2 + s->l1_table_offset, s->l1_table, l1_table_size);
-			lseek(fd, 0, SEEK_SET);
-			if (write(fd, buf2, l1_table_block) < 
-				l1_table_size + s->l1_table_offset) {
-				DPRINTF("qcow: Failed to write new L1 table\n");
-				goto fail;
-			}
-
-			for(i = 0;i < s->l1_size; i++) {
-				cpu_to_be64s(&s->l1_table[i]);
-			}
-
-		}
-
-		/*Finally check the L1 table cksum*/
-		be32_to_cpus(&exthdr->cksum);
-		cksum = gen_cksum((char *)s->l1_table, 
-				  s->l1_size * sizeof(uint64_t));
-		if(exthdr->cksum != cksum)
-			goto end_xenhdr;
-			
-		be32_to_cpus(&exthdr->min_cluster_alloc);
-		s->sparse = (exthdr->flags & SPARSE_FILE);
-		s->min_cluster_alloc = exthdr->min_cluster_alloc; 
-	}
-
- end_xenhdr:
- 	
-	/* A segment (i.e. a page) can span multiple clusters */
-	max_aio_reqs = ((getpagesize() / s->cluster_size) + 1) *
-		MAX_SEGMENTS_PER_REQ * MAX_REQUESTS;
-
-	if (tap_aio_init(&s->aio, bs->size, max_aio_reqs)!=0) {
-		DPRINTF("Unable to initialise AIO state\n");
-                tap_aio_free(&s->aio);
-		goto fail;
-	}
-	init_fds(dd);
-
-	if (!final_cluster)
-		s->fd_end = l1_table_block;
-	else {
-		s->fd_end = lseek(fd, 0, SEEK_END);
-		if (s->fd_end == (off_t)-1)
-			goto fail;
-	}
-
-	return 0;
-	
-fail:
-	DPRINTF("QCOW Open failed\n");
-	tap_aio_free(&s->aio);
-	free(s->l1_table);
-	free(s->l2_cache);
-	free(s->cluster_cache);
-	free(s->cluster_data);
-	close(fd);
-	return -1;
-}
-
-static int tdqcow_queue_read(struct disk_driver *dd, uint64_t sector,
-		      int nb_sectors, char *buf, td_callback_t cb,
-		      int id, void *private)
-{
-	struct tdqcow_state *s = (struct tdqcow_state *)dd->private;
-	int ret = 0, index_in_cluster, n, i, rsp = 0;
-	uint64_t cluster_offset, sec, nr_secs;
-
-	sec     = sector;
-	nr_secs = nb_sectors;
-
-	/*Check we can get a lock*/
-	for (i = 0; i < nb_sectors; i++) 
-		if (!tap_aio_can_lock(&s->aio, sector + i)) 
-			return cb(dd, -EBUSY, sector, nb_sectors, id, private);
-
-	/*We store a local record of the request*/
-	while (nb_sectors > 0) {
-		cluster_offset = 
-			get_cluster_offset(s, sector << 9, 0, 0, 0, 0);
-		index_in_cluster = sector & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-
-		if (s->aio.iocb_free_count == 0 || !tap_aio_lock(&s->aio, sector)) 
-			return cb(dd, -EBUSY, sector, nb_sectors, id, private);
-		
-		if(!cluster_offset) {
-			tap_aio_unlock(&s->aio, sector);
-			ret = cb(dd, BLK_NOT_ALLOCATED, 
-				 sector, n, id, private);
-			if (ret == -EBUSY) {
-				/* mark remainder of request
-				 * as busy and try again later */
-				return cb(dd, -EBUSY, sector + n,
-					  nb_sectors - n, id, private);
-			} else
-				rsp += ret;
-		} else if (cluster_offset & QCOW_OFLAG_COMPRESSED) {
-			tap_aio_unlock(&s->aio, sector);
-			if (decompress_cluster(s, cluster_offset) < 0) {
-				rsp += cb(dd, -EIO, sector, 
-					  nb_sectors, id, private);
-				goto done;
-			}
-			memcpy(buf, s->cluster_cache + index_in_cluster * 512, 
-			       512 * n);
-			rsp += cb(dd, 0, sector, n, id, private);
-		} else {
-			tap_aio_read(&s->aio, s->fd, n * 512, 
-				   (cluster_offset + index_in_cluster * 512),
-				   buf, cb, id, sector, private);
-		}
-		nb_sectors -= n;
-		sector += n;
-		buf += n * 512;
-	}
-done:
-	return rsp;
-}
-
-static int tdqcow_queue_write(struct disk_driver *dd, uint64_t sector,
-		       int nb_sectors, char *buf, td_callback_t cb,
-		       int id, void *private)
-{
-	struct tdqcow_state *s = (struct tdqcow_state *)dd->private;
-	int ret = 0, index_in_cluster, n, i;
-	uint64_t cluster_offset, sec, nr_secs;
-
-	sec     = sector;
-	nr_secs = nb_sectors;
-
-	/*Check we can get a lock*/
-	for (i = 0; i < nb_sectors; i++)
-		if (!tap_aio_can_lock(&s->aio, sector + i))  
-			return cb(dd, -EBUSY, sector, nb_sectors, id, private);
-		   
-	/*We store a local record of the request*/
-	while (nb_sectors > 0) {
-		index_in_cluster = sector & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-
-		if (s->aio.iocb_free_count == 0 || !tap_aio_lock(&s->aio, sector))
-			return cb(dd, -EBUSY, sector, nb_sectors, id, private);
-
-		cluster_offset = get_cluster_offset(s, sector << 9, 1, 0,
-						    index_in_cluster, 
-						    index_in_cluster+n);
-		if (!cluster_offset) {
-			DPRINTF("Ooops, no write cluster offset!\n");
-			tap_aio_unlock(&s->aio, sector);
-			return cb(dd, -EIO, sector, nb_sectors, id, private);
-		}
-
-		if (s->crypt_method) {
-			encrypt_sectors(s, sector, s->cluster_data, 
-					(unsigned char *)buf, n, 1,
-					&s->aes_encrypt_key);
-			tap_aio_write(&s->aio, s->fd, n * 512, 
-				    (cluster_offset + index_in_cluster*512),
-				    (char *)s->cluster_data, cb, id, sector, 
-				    private);
-		} else {
-			tap_aio_write(&s->aio, s->fd, n * 512, 
-				    (cluster_offset + index_in_cluster*512),
-				    buf, cb, id, sector, private);
-		}
-		
-		nb_sectors -= n;
-		sector += n;
-		buf += n * 512;
-	}
-	s->cluster_cache_offset = -1; /* disable compressed cache */
-
-	return 0;
-}
- 		
-static int tdqcow_submit(struct disk_driver *dd)
-{
-        struct tdqcow_state *prv = (struct tdqcow_state *)dd->private;
-
-	return tap_aio_submit(&prv->aio);
-}
-
-static int tdqcow_close(struct disk_driver *dd)
-{
-	struct tdqcow_state *s = (struct tdqcow_state *)dd->private;
-	uint32_t cksum, out;
-	int fd, offset;
-
-	/*Update the hdr cksum*/
-	if(s->min_cluster_alloc == s->l2_size) {
-		cksum = gen_cksum((char *)s->l1_table, s->l1_size * sizeof(uint64_t));
-		printf("Writing cksum: %d",cksum);
-		fd = open(s->name, O_WRONLY | O_LARGEFILE); /*Open without O_DIRECT*/
-		offset = sizeof(QCowHeader) + sizeof(uint32_t);
-		lseek(fd, offset, SEEK_SET);
-		out = cpu_to_be32(cksum);
-		if (write(fd, &out, sizeof(uint32_t))) ;
-		close(fd);
-	}
-
-	io_destroy(s->aio.aio_ctx.aio_ctx);
-	free(s->name);
-	free(s->l1_table);
-	free(s->l2_cache);
-	free(s->cluster_cache);
-	free(s->cluster_data);
-	close(s->fd);	
-	return 0;
-}
-
-static int tdqcow_do_callbacks(struct disk_driver *dd, int sid)
-{
-        int ret, i, nr_events, rsp = 0,*ptr;
-        struct io_event *ep;
-        struct tdqcow_state *prv = (struct tdqcow_state *)dd->private;
-
-        if (sid > MAX_IOFD) return 1;
-
-        nr_events = tap_aio_get_events(&prv->aio.aio_ctx);
-repeat:
-        for (ep = prv->aio.aio_events, i = nr_events; i-- > 0; ep++) {
-                struct iocb        *io  = ep->obj;
-                struct pending_aio *pio;
-
-                pio = &prv->aio.pending_aio[(long)io->data];
-
-		tap_aio_unlock(&prv->aio, pio->sector);
-
-		if (prv->crypt_method)
-			encrypt_sectors(prv, pio->sector, 
-					(unsigned char *)pio->buf, 
-					(unsigned char *)pio->buf, 
-					pio->nb_sectors, 0, 
-					&prv->aes_decrypt_key);
-
-		rsp += pio->cb(dd, ep->res == io->u.c.nbytes ? 0 : 1, 
-			       pio->sector, pio->nb_sectors,
-			       pio->id, pio->private);
-
-                prv->aio.iocb_free[prv->aio.iocb_free_count++] = io;
-        }
-
-        if (nr_events) {
-                nr_events = tap_aio_more_events(&prv->aio.aio_ctx);
-                goto repeat;
-        }
-
-        tap_aio_continue(&prv->aio.aio_ctx);
-
-        return rsp;
-}
-
-int qcow_create(const char *filename, uint64_t total_size,
-		const char *backing_file, int sparse)
-{
-	int fd, header_size, backing_filename_len, l1_size, i;
-	int shift, length, adjust, flags = 0, ret = 0;
-	QCowHeader header;
-	QCowHeader_ext exthdr;
-	char backing_filename[PATH_MAX], *ptr;
-	uint64_t tmp, size, total_length;
-	struct stat st;
-
-	DPRINTF("Qcow_create: size %llu\n",(long long unsigned)total_size);
-
-	fd = open(filename, 
-		  O_WRONLY | O_CREAT | O_TRUNC | O_BINARY | O_LARGEFILE,
-		  0644);
-	if (fd < 0)
-		return -1;
-
-	memset(&header, 0, sizeof(header));
-	header.magic = cpu_to_be32(QCOW_MAGIC);
-	header.version = cpu_to_be32(QCOW_VERSION);
-
-	/*Create extended header fields*/
-	exthdr.xmagic = cpu_to_be32(XEN_MAGIC);
-
-	header_size = sizeof(header) + sizeof(QCowHeader_ext);
-	backing_filename_len = 0;
-	size = (total_size >> SECTOR_SHIFT);
-	if (backing_file) {
-		if (strcmp(backing_file, "fat:")) {
-			const char *p;
-			/* XXX: this is a hack: we do not attempt to 
-			 *check for URL like syntax */
-			p = strchr(backing_file, ':');
-			if (p && (p - backing_file) >= 2) {
-				/* URL like but exclude "c:" like filenames */
-				strncpy(backing_filename, backing_file,
-					sizeof(backing_filename));
-			} else {
-				if (realpath(backing_file, backing_filename) == NULL ||
-				    stat(backing_filename, &st) != 0) {
-					return -1;
-				}
-			}
-			header.backing_file_offset = cpu_to_be64(header_size);
-			backing_filename_len = strlen(backing_filename);
-			header.backing_file_size = cpu_to_be32(
-				backing_filename_len);
-			header_size += backing_filename_len;
-			
-			/*Set to the backing file size*/
-			if(get_filesize(backing_filename, &size, &st)) {
-				return -1;
-			}
-			DPRINTF("Backing file size detected: %lld sectors" 
-				"(total %lld [%lld MB])\n", 
-				(long long)size, 
-				(long long)(size << SECTOR_SHIFT), 
-				(long long)(size >> 11));
-		} else {
-			backing_file = NULL;
-			DPRINTF("Setting file size: %lld (total %lld)\n", 
-				(long long) total_size, 
-				(long long) (total_size << SECTOR_SHIFT));
-		}
-		header.mtime = cpu_to_be32(st.st_mtime);
-		header.cluster_bits = 9; /* 512 byte cluster to avoid copying
-					    unmodifyed sectors */
-		header.l2_bits = 12; /* 32 KB L2 tables */
-		exthdr.min_cluster_alloc = cpu_to_be32(1);
-	} else {
-		DPRINTF("Setting file size: %lld sectors" 
-			"(total %lld [%lld MB])\n", 
-			(long long) size, 
-			(long long) (size << SECTOR_SHIFT), 
-			(long long) (size >> 11));
-		header.cluster_bits = 12; /* 4 KB clusters */
-		header.l2_bits = 9; /* 4 KB L2 tables */
-		exthdr.min_cluster_alloc = cpu_to_be32(1 << 9);
-	}
-	/*Set the header size value*/
-	header.size = cpu_to_be64(size * 512);
-	
-	header_size = (header_size + 7) & ~7;
-	if (header_size % 4096 > 0) {
-		header_size = ROUNDUP(header_size, 4096);
-	}
-
-	shift = header.cluster_bits + header.l2_bits;
-	l1_size = ROUNDUP(size * 512, 1LL << shift);
-
-	header.l1_table_offset = cpu_to_be64(header_size);
-	DPRINTF("L1 Table offset: %d, size %d\n",
-		header_size,
-		(int)(l1_size * sizeof(uint64_t)));
-	header.crypt_method = cpu_to_be32(QCOW_CRYPT_NONE);
-
-	ptr = calloc(1, l1_size * sizeof(uint64_t));
-	exthdr.cksum = cpu_to_be32(gen_cksum(ptr, l1_size * sizeof(uint64_t)));
-	printf("Created cksum: %d\n",exthdr.cksum);
-	free(ptr);
-
-	/*adjust file length to system page size boundary*/
-	length = ROUNDUP(header_size + (l1_size * sizeof(uint64_t)),
-		getpagesize());
-	if (qtruncate(fd, length, 0)!=0) {
-		DPRINTF("ERROR truncating file\n");
-		return -1;
-	}
-
-	if (sparse == 0) {
-		/*Filesize is length+l1_size*(1 << s->l2_bits)+(size*512)*/
-		total_length = length + (l1_size * (1 << 9)) + (size * 512);
-		if (qtruncate(fd, total_length, 0)!=0) {
-                        DPRINTF("ERROR truncating file\n");
-                        return -1;
-		}
-		printf("File truncated to length %"PRIu64"\n",total_length);
-	} else
-		flags = SPARSE_FILE;
-
-	flags |= EXTHDR_L1_BIG_ENDIAN;
-	exthdr.flags = cpu_to_be32(flags);
-	
-	/* write all the data */
-	lseek(fd, 0, SEEK_SET);
-	ret += write(fd, &header, sizeof(header));
-	ret += write(fd, &exthdr, sizeof(exthdr));
-	if (backing_file)
-		ret += write(fd, backing_filename, backing_filename_len);
-
-	lseek(fd, header_size, SEEK_SET);
-	tmp = 0;
-	for (i = 0;i < l1_size; i++) {
-		ret += write(fd, &tmp, sizeof(tmp));
-	}
-
-	close(fd);
-
-	return 0;
-}
-
-static int qcow_make_empty(struct tdqcow_state *s)
-{
-	uint32_t l1_length = s->l1_size * sizeof(uint64_t);
-
-	memset(s->l1_table, 0, l1_length);
-	lseek(s->fd, s->l1_table_offset, SEEK_SET);
-	if (write(s->fd, s->l1_table, l1_length) < 0)
-		return -1;
-	if (qtruncate(s->fd, s->l1_table_offset + l1_length, s->sparse)!=0) {
-		DPRINTF("ERROR truncating file\n");
-		return -1;
-	}
-
-	memset(s->l2_cache, 0, s->l2_size * L2_CACHE_SIZE * sizeof(uint64_t));
-	memset(s->l2_cache_offsets, 0, L2_CACHE_SIZE * sizeof(uint64_t));
-	memset(s->l2_cache_counts, 0, L2_CACHE_SIZE * sizeof(uint32_t));
-
-	return 0;
-}
-
-static int qcow_get_cluster_size(struct tdqcow_state *s)
-{
-	return s->cluster_size;
-}
-
-/* XXX: put compressed sectors first, then all the cluster aligned
-   tables to avoid losing bytes in alignment */
-static int qcow_compress_cluster(struct tdqcow_state *s, int64_t sector_num, 
-                          const uint8_t *buf)
-{
-	z_stream strm;
-	int ret, out_len;
-	uint8_t *out_buf;
-	uint64_t cluster_offset;
-
-	out_buf = malloc(s->cluster_size + (s->cluster_size / 1000) + 128);
-	if (!out_buf)
-		return -1;
-
-	/* best compression, small window, no zlib header */
-	memset(&strm, 0, sizeof(strm));
-	ret = deflateInit2(&strm, Z_DEFAULT_COMPRESSION,
-			   Z_DEFLATED, -12, 
-			   9, Z_DEFAULT_STRATEGY);
-	if (ret != 0) {
-		free(out_buf);
-		return -1;
-	}
-
-	strm.avail_in = s->cluster_size;
-	strm.next_in = (uint8_t *)buf;
-	strm.avail_out = s->cluster_size;
-	strm.next_out = out_buf;
-
-	ret = deflate(&strm, Z_FINISH);
-	if (ret != Z_STREAM_END && ret != Z_OK) {
-		free(out_buf);
-		deflateEnd(&strm);
-		return -1;
-	}
-	out_len = strm.next_out - out_buf;
-
-	deflateEnd(&strm);
-
-	if (ret != Z_STREAM_END || out_len >= s->cluster_size) {
-		/* could not compress: write normal cluster */
-		//tdqcow_queue_write(bs, sector_num, buf, s->cluster_sectors);
-	} else {
-		cluster_offset = get_cluster_offset(s, sector_num << 9, 2, 
-                                            out_len, 0, 0);
-		cluster_offset &= s->cluster_offset_mask;
-		lseek(s->fd, cluster_offset, SEEK_SET);
-		if (write(s->fd, out_buf, out_len) != out_len) {
-			free(out_buf);
-			return -1;
-		}
-	}
-	
-	free(out_buf);
-	return 0;
-}
-
-static int tdqcow_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	off_t off;
-	char *buf, *filename;
-	int len, secs, err = -EINVAL;
-	struct tdqcow_state *child  = (struct tdqcow_state *)dd->private;
-
-	if (!child->backing_file_offset)
-		return TD_NO_PARENT;
-
-	/* read the backing file name */
-	len  = child->backing_file_size;
-	off  = child->backing_file_offset - (child->backing_file_offset % 512);
-	secs = (len + (child->backing_file_offset - off) + 511) >> 9;
-
-	if (posix_memalign((void **)&buf, 512, secs << 9)) 
-		return -1;
-
-	if (lseek(child->fd, off, SEEK_SET) == (off_t)-1)
-		goto out;
-
-	if (read(child->fd, buf, secs << 9) != secs << 9)
-		goto out;
-	filename       = buf + (child->backing_file_offset - off);
-	filename[len]  = '\0';
-
-	id->name       = strdup(filename);
-	id->drivertype = DISK_TYPE_AIO;
-	err            = 0;
- out:
-	free(buf);
-	return err;
-}
-
-static int tdqcow_validate_parent(struct disk_driver *child,
-			   struct disk_driver *parent, td_flag_t flags)
-{
-	struct stat stats;
-	uint64_t psize, csize;
-	
-	if (stat(parent->name, &stats))
-		return -EINVAL;
-	if (get_filesize(parent->name, &psize, &stats))
-		return -EINVAL;
-
-	if (stat(child->name, &stats))
-		return -EINVAL;
-	if (get_filesize(child->name, &csize, &stats))
-		return -EINVAL;
-
-	if (csize != psize)
-		return -EINVAL;
-
-	return 0;
-}
-
-struct tap_disk tapdisk_qcow = {
-	.disk_type           = "tapdisk_qcow",
-	.private_data_size   = sizeof(struct tdqcow_state),
-	.td_open             = tdqcow_open,
-	.td_queue_read       = tdqcow_queue_read,
-	.td_queue_write      = tdqcow_queue_write,
-	.td_submit           = tdqcow_submit,
-	.td_close            = tdqcow_close,
-	.td_do_callbacks     = tdqcow_do_callbacks,
-	.td_get_parent_id    = tdqcow_get_parent_id,
-	.td_validate_parent  = tdqcow_validate_parent
-};
diff --git a/tools/blktap/drivers/block-qcow2.c b/tools/blktap/drivers/block-qcow2.c
deleted file mode 100644
index ceda4f0..0000000
--- a/tools/blktap/drivers/block-qcow2.c
+++ /dev/null
@@ -1,2098 +0,0 @@
-/*
- * Block driver for the QCOW version 2 format
- *
- * Copyright (c) 2004-2006 Fabrice Bellard
- *
- * 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.
- */
-
-#include <zlib.h>
-#include "aes.h"
-#include <assert.h>
-#include <stdint.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <sys/stat.h>
-
-#include "tapdisk.h"
-#include "tapaio.h"
-#include "bswap.h"
-#include "blk.h"
-
-#define USE_AIO
-
-#define qemu_malloc malloc
-#define qemu_mallocz(size) calloc(1, size)
-#define qemu_free free
-
-#ifndef O_BINARY
-#define O_BINARY 0
-#endif
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE     0 
-#endif
-
-#define BLOCK_FLAG_ENCRYPT 1
-
-/*
-  Differences with QCOW:
-
-  - Support for multiple incremental snapshots.
-  - Memory management by reference counts.
-  - Clusters which have a reference count of one have the bit
-	QCOW_OFLAG_COPIED to optimize write performance.
-  - Size of compressed clusters is stored in sectors to reduce bit usage
-	in the cluster offsets.
-  - Support for storing additional data (such as the VM state) in the
-	snapshots.
-  - If a backing store is used, the cluster size is not constrained
-	(could be backported to QCOW).
-  - L2 tables have always a size of one cluster.
-*/
-
-//#define DEBUG_ALLOC
-//#define DEBUG_ALLOC2
-
-#define QCOW_MAGIC (('Q' << 24) | ('F' << 16) | ('I' << 8) | 0xfb)
-#define QCOW_VERSION 2
-
-#define QCOW_CRYPT_NONE 0
-#define QCOW_CRYPT_AES	1
-
-/* indicate that the refcount of the referenced cluster is exactly one. */
-#define QCOW_OFLAG_COPIED	  (1LL << 63)
-/* indicate that the cluster is compressed (they never have the copied flag) */
-#define QCOW_OFLAG_COMPRESSED (1LL << 62)
-
-#define REFCOUNT_SHIFT 1 /* refcount size is 2 bytes */
-
-#ifndef offsetof
-#define offsetof(type, field) ((size_t) &((type *)0)->field)
-#endif
-
-typedef struct QCowHeader {
-	uint32_t magic;
-	uint32_t version;
-	uint64_t backing_file_offset;
-	uint32_t backing_file_size;
-	uint32_t cluster_bits;
-	uint64_t size; /* in bytes */
-
-	uint32_t crypt_method;
-	uint32_t l1_size; /* XXX: save number of clusters instead ? */
-	uint64_t l1_table_offset;
-	uint64_t refcount_table_offset;
-	uint32_t refcount_table_clusters;
-	uint32_t nb_snapshots;
-	uint64_t snapshots_offset;
-} QCowHeader;
-
-typedef struct __attribute__((packed)) QCowSnapshotHeader {
-	/* header is 8 byte aligned */
-	uint64_t l1_table_offset;
-
-	uint32_t l1_size;
-	uint16_t id_str_size;
-	uint16_t name_size;
-
-	uint32_t date_sec;
-	uint32_t date_nsec;
-
-	uint64_t vm_clock_nsec;
-
-	uint32_t vm_state_size;
-	uint32_t extra_data_size; /* for extension */
-	/* extra data follows */
-	/* id_str follows */
-	/* name follows  */
-} QCowSnapshotHeader;
-
-#define L2_CACHE_SIZE 16
-
-typedef struct QCowSnapshot {
-	uint64_t l1_table_offset;
-	uint32_t l1_size;
-	char *id_str;
-	char *name;
-	uint32_t vm_state_size;
-	uint32_t date_sec;
-	uint32_t date_nsec;
-	uint64_t vm_clock_nsec;
-} QCowSnapshot;
-
-typedef struct BDRVQcowState {
-
-	/* blktap additions */
-	int fd;
-	int poll_pipe[2]; /* dummy fd for polling on */
-	char* name;
-	int encrypted;
-	char backing_file[1024];
-	struct disk_driver* backing_hd;
-
-	int64_t total_sectors;
-
-	tap_aio_context_t async;
-
-	/* Original qemu variables */
-	int cluster_bits;
-	int cluster_size;
-	int cluster_sectors;
-	int l2_bits;
-	int l2_size;
-	int l1_size;
-	int l1_vm_state_index;
-	int csize_shift;
-	int csize_mask;
-	uint64_t cluster_offset_mask;
-	uint64_t l1_table_offset;
-	uint64_t *l1_table;
-	uint64_t *l2_cache;
-	uint64_t l2_cache_offsets[L2_CACHE_SIZE];
-	uint32_t l2_cache_counts[L2_CACHE_SIZE];
-	uint8_t *cluster_cache;
-	uint8_t *cluster_data;
-	uint64_t cluster_cache_offset;
-
-	uint64_t *refcount_table;
-	uint64_t refcount_table_offset;
-	uint32_t refcount_table_size;
-	uint64_t refcount_block_cache_offset;
-	uint16_t *refcount_block_cache;
-	int64_t free_cluster_index;
-	int64_t free_byte_offset;
-
-	uint32_t crypt_method; /* current crypt method, 0 if no key yet */
-	uint32_t crypt_method_header;
-	AES_KEY aes_encrypt_key;
-	AES_KEY aes_decrypt_key;
-	uint64_t snapshots_offset;
-	int snapshots_size;
-	int nb_snapshots;
-	QCowSnapshot *snapshots;
-} BDRVQcowState;
-
-static int decompress_cluster(BDRVQcowState *s, uint64_t cluster_offset);
-static int qcow_read(struct disk_driver *bs, uint64_t sector_num,
-		uint8_t *buf, int nb_sectors);
-
-static int qcow_read_snapshots(struct disk_driver *bs);
-static void qcow_free_snapshots(struct disk_driver *bs);
-
-static int refcount_init(struct disk_driver *bs);
-static void refcount_close(struct disk_driver *bs);
-static int get_refcount(struct disk_driver *bs, int64_t cluster_index);
-static int update_cluster_refcount(struct disk_driver *bs,
-		int64_t cluster_index,
-		int addend);
-static void update_refcount(struct disk_driver *bs,
-		int64_t offset, int64_t length,
-		int addend);
-static int64_t alloc_clusters(struct disk_driver *bs, int64_t size);
-static int64_t alloc_bytes(struct disk_driver *bs, int size);
-static void free_clusters(struct disk_driver *bs,
-		int64_t offset, int64_t size);
-#ifdef DEBUG_ALLOC
-static void check_refcounts(struct disk_driver *bs);
-#endif
-
-static int qcow_sync_read(struct disk_driver *dd, uint64_t sector,
-		int nb_sectors, char *buf, td_callback_t cb,
-		int id, void *prv);
-
-/**
- * Read with byte offsets
- */
-static int bdrv_pread(int fd, int64_t offset, void *buf, int count)
-{
-	int ret;
-
-	if (lseek(fd, offset, SEEK_SET) == -1) {
-		DPRINTF("bdrv_pread failed seek (%#"PRIx64").\n", offset);
-		return -1;
-	}
-
-	ret =  read(fd, buf, count);
-	if (ret < 0) {
-		if (lseek(fd, 0, SEEK_END) >= offset) {
-			DPRINTF("bdrv_pread read failed (%#"PRIx64", END = %#"PRIx64").\n", 
-					offset, lseek(fd, 0, SEEK_END));
-			return -1;
-		}
-
-		/* Read beyond end of file. Reading zeros. */
-		memset(buf, 0, count);
-		ret = count;
-	} else if (ret < count) {
-		/* Read beyond end of file. Filling up with zeros. */
-		memset(buf + ret, 0, count - ret);
-		ret = count;
-	}
-	return ret;
-}
-
-/**
- * Write with byte offsets
- */
-static int bdrv_pwrite(int fd, int64_t offset, const void *buf, int count)
-{
-	if (lseek(fd, offset, SEEK_SET) == -1) {
-		DPRINTF("bdrv_pwrite failed seek (%#"PRIx64").\n", offset);
-		return -1;
-	}
-
-	return write(fd, buf, count);
-}
-
-
-/**
- * Read with sector offsets
- */
-static int bdrv_read(int fd, int64_t offset, void *buf, int count)
-{
-	return bdrv_pread(fd, 512 * offset, buf, 512 * count);
-}
-
-/**
- * Write with sector offsets
- */
-static int bdrv_write(int fd, int64_t offset, const void *buf, int count)
-{
-	return bdrv_pwrite(fd, 512 * offset, buf, count);
-}
-
-
-static int qcow_probe(const uint8_t *buf, int buf_size, const char *filename)
-{
-	const QCowHeader *cow_header = (const void *)buf;
-
-	if (buf_size >= sizeof(QCowHeader) &&
-		be32_to_cpu(cow_header->magic) == QCOW_MAGIC &&
-		be32_to_cpu(cow_header->version) == QCOW_VERSION)
-		return 100;
-	else
-		return 0;
-}
-
-static int qcow_open(struct disk_driver *bs, const char *filename, td_flag_t flags)
-{
-	BDRVQcowState *s = bs->private;
-	int len, i, shift, ret, max_aio_reqs;
-	QCowHeader header;
-
-	int fd, o_flags;
-	
-	o_flags = O_LARGEFILE | ((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-
-	DPRINTF("Opening %s\n", filename);
-	fd = open(filename, o_flags);
-	if (fd < 0) {
-		DPRINTF("Unable to open %s (%d)\n", filename, 0 - errno);
-		return -1;
-	}
-
-	s->fd = fd;
-	if (asprintf(&s->name,"%s", filename) == -1) {
-		close(fd);
-		return -1;
-	}
-
-	ret = read(fd, &header, sizeof(header));
-	if (ret != sizeof(header)) {
-		DPRINTF("  ret = %d, errno = %d\n", ret, errno);
-		goto fail;
-	}
-
-	be32_to_cpus(&header.magic);
-	be32_to_cpus(&header.version);
-	be64_to_cpus(&header.backing_file_offset);
-	be32_to_cpus(&header.backing_file_size);
-	be64_to_cpus(&header.size);
-	be32_to_cpus(&header.cluster_bits);
-	be32_to_cpus(&header.crypt_method);
-	be64_to_cpus(&header.l1_table_offset);
-	be32_to_cpus(&header.l1_size);
-	be64_to_cpus(&header.refcount_table_offset);
-	be32_to_cpus(&header.refcount_table_clusters);
-	be64_to_cpus(&header.snapshots_offset);
-	be32_to_cpus(&header.nb_snapshots);
-
-	if (header.magic != QCOW_MAGIC || header.version != QCOW_VERSION)
-		goto fail;
-
-	if (header.size <= 1 ||
-		header.cluster_bits < 9 ||
-		header.cluster_bits > 16)
-		goto fail;
-	
-	s->crypt_method = 0;
-	if (header.crypt_method > QCOW_CRYPT_AES)
-		goto fail;
-	s->crypt_method_header = header.crypt_method;
-	if (s->crypt_method_header)
-		s->encrypted = 1;
-	s->cluster_bits = header.cluster_bits;
-	s->cluster_size = 1 << s->cluster_bits;
-	s->cluster_sectors = 1 << (s->cluster_bits - 9);
-	s->l2_bits = s->cluster_bits - 3; /* L2 is always one cluster */
-	s->l2_size = 1 << s->l2_bits;
-	s->total_sectors = header.size / 512;
-	s->csize_shift = (62 - (s->cluster_bits - 8));
-	s->csize_mask = (1 << (s->cluster_bits - 8)) - 1;
-	s->cluster_offset_mask = (1LL << s->csize_shift) - 1;
-	s->refcount_table_offset = header.refcount_table_offset;
-	s->refcount_table_size =
-		header.refcount_table_clusters << (s->cluster_bits - 3);
-
-	s->snapshots_offset = header.snapshots_offset;
-	s->nb_snapshots = header.nb_snapshots;
-
-//	  DPRINTF("-- cluster_bits/size/sectors = %d/%d/%d\n",
-//		  s->cluster_bits, s->cluster_size, s->cluster_sectors);
-//	  DPRINTF("-- l2_bits/sizes = %d/%d\n",
-//		  s->l2_bits, s->l2_size);
-
-	/* Set sector size and number */
-	bs->td_state->sector_size = 512;
-	bs->td_state->size = header.size / 512;
-	bs->td_state->info = 0;
-
-	/* read the level 1 table */
-	s->l1_size = header.l1_size;
-	shift = s->cluster_bits + s->l2_bits;
-	s->l1_vm_state_index = (header.size + (1LL << shift) - 1) >> shift;
-	/* the L1 table must contain at least enough entries to put
-	   header.size bytes */
-	if (s->l1_size < s->l1_vm_state_index) {
-		DPRINTF("L1 table tooo small\n");
-		goto fail;
-	}
-	s->l1_table_offset = header.l1_table_offset;
-
-	s->l1_table = qemu_malloc(s->l1_size * sizeof(uint64_t));
-	if (!s->l1_table)
-		goto fail;
-
-
-	if (lseek(fd, s->l1_table_offset, SEEK_SET) == -1)
-		goto fail;
-
-	if (read(fd, s->l1_table, s->l1_size * sizeof(uint64_t)) !=
-			s->l1_size * sizeof(uint64_t)) {
-
-		DPRINTF("Could not read L1 table\n");
-		goto fail;
-	}
-
-	for(i = 0;i < s->l1_size; i++) {
-		be64_to_cpus(&s->l1_table[i]);
-	}
-	/* alloc L2 cache */
-	s->l2_cache = qemu_malloc(s->l2_size * L2_CACHE_SIZE * sizeof(uint64_t));
-	if (!s->l2_cache)
-		goto fail;
-	s->cluster_cache = qemu_malloc(s->cluster_size);
-	if (!s->cluster_cache)
-		goto fail;
-	/* one more sector for decompressed data alignment */
-	s->cluster_data = qemu_malloc(s->cluster_size + 512);
-	if (!s->cluster_data)
-		goto fail;
-	s->cluster_cache_offset = -1;
-
-	if (refcount_init(bs) < 0)
-		goto fail;
-		
-	/* read the backing file name */
-	s->backing_file[0] = '\0';
-	if (header.backing_file_offset != 0) {
-		len = header.backing_file_size;
-		if (len > 1023)
-			len = 1023;
-
-		if (lseek(fd, header.backing_file_offset, SEEK_SET) == -1) {
-			DPRINTF("Could not lseek to %#"PRIx64"\n", header.backing_file_offset);
-			goto fail;
-		}
-
-		if (read(fd, s->backing_file, len) != len) {
-			DPRINTF("Could not read %#x bytes from %#"PRIx64": %s\n",
-				len, header.backing_file_offset,
-				strerror(errno));
-			goto fail;
-		}
-
-		s->backing_file[len] = '\0';
-	}
-
-#if 0
-	s->backing_hd = NULL;
-	if (qcow_read_snapshots(bs) < 0) {
-		DPRINTF("Could not read backing files\n");
-		goto fail;
-	}
-#endif
-
-#ifdef DEBUG_ALLOC
-	check_refcounts(bs);
-#endif
-	
-	/* Initialize fds */
-	for(i = 0; i < MAX_IOFD; i++)
-		bs->io_fd[i] = 0;
-
-#ifdef USE_AIO
-	/* Initialize AIO */
-
-	/* A segment (i.e. a page) can span multiple clusters */
-	max_aio_reqs = ((getpagesize() / s->cluster_size) + 1) *
-		MAX_SEGMENTS_PER_REQ * MAX_REQUESTS;
-
-	if (tap_aio_init(&s->async, bs->td_state->size, max_aio_reqs)) {
-		DPRINTF("Unable to initialise AIO state\n");
-		tap_aio_free(&s->async);
-		goto fail;
-	}
-
-	bs->io_fd[0] = s->async.aio_ctx.pollfd; 
-#else	
-	/* Synchronous IO */
-	if (pipe(s->poll_pipe)) 
-		goto fail;
-
-	bs->io_fd[0] = s->poll_pipe[0];
-#endif
-
-	return 0;
-
- fail:
-	DPRINTF("qcow_open failed\n");
-
-#ifdef USE_AIO	
-	tap_aio_free(&s->async);
-#endif
-
-	qcow_free_snapshots(bs);
-	refcount_close(bs);
-	qemu_free(s->l1_table);
-	qemu_free(s->l2_cache);
-	qemu_free(s->cluster_cache);
-	qemu_free(s->cluster_data);
-	close(fd);
-	return -1;
-}
-
-static int qcow_set_key(struct disk_driver *bs, const char *key)
-{
-	BDRVQcowState *s = bs->private;
-	uint8_t keybuf[16];
-	int len, i;
-
-	memset(keybuf, 0, 16);
-	len = strlen(key);
-	if (len > 16)
-		len = 16;
-	/* XXX: we could compress the chars to 7 bits to increase
-	   entropy */
-	for(i = 0;i < len;i++) {
-		keybuf[i] = key[i];
-	}
-	s->crypt_method = s->crypt_method_header;
-
-	if (AES_set_encrypt_key(keybuf, 128, &s->aes_encrypt_key) != 0)
-		return -1;
-	if (AES_set_decrypt_key(keybuf, 128, &s->aes_decrypt_key) != 0)
-		return -1;
-#if 0
-	/* test */
-	{
-		uint8_t in[16];
-		uint8_t out[16];
-		uint8_t tmp[16];
-		for(i=0;i<16;i++)
-			in[i] = i;
-		AES_encrypt(in, tmp, &s->aes_encrypt_key);
-		AES_decrypt(tmp, out, &s->aes_decrypt_key);
-		for(i = 0; i < 16; i++)
-			printf(" %02x", tmp[i]);
-		printf("\n");
-		for(i = 0; i < 16; i++)
-			printf(" %02x", out[i]);
-		printf("\n");
-	}
-#endif
-	return 0;
-}
-
-/* The crypt function is compatible with the linux cryptoloop
-   algorithm for < 4 GB images. NOTE: out_buf == in_buf is
-   supported */
-static void encrypt_sectors(BDRVQcowState *s, int64_t sector_num,
-		uint8_t *out_buf, const uint8_t *in_buf,
-		int nb_sectors, int enc,
-		const AES_KEY *key)
-{
-	union {
-		uint64_t ll[2];
-		uint8_t b[16];
-	} ivec;
-	int i;
-
-	for(i = 0; i < nb_sectors; i++) {
-		ivec.ll[0] = cpu_to_le64(sector_num);
-		ivec.ll[1] = 0;
-		AES_cbc_encrypt(in_buf, out_buf, 512, key,
-						ivec.b, enc);
-		sector_num++;
-		in_buf += 512;
-		out_buf += 512;
-	}
-}
-
-static int copy_sectors(struct disk_driver *bs, uint64_t start_sect,
-		uint64_t cluster_offset, int n_start, int n_end)
-{
-	BDRVQcowState *s = bs->private;
-	int n, ret;
-	
-	n = n_end - n_start;
-	if (n <= 0)
-		return 0;
-
-	ret = qcow_read(bs, start_sect + n_start, s->cluster_data, n);
-
-	if (ret < 0)
-		return ret;
-	if (s->crypt_method) {
-		encrypt_sectors(s, start_sect + n_start,
-				s->cluster_data,
-				s->cluster_data, n, 1,
-				&s->aes_encrypt_key);
-	}
-
-
-	ret = bdrv_pwrite(s->fd, cluster_offset + 512*n_start, s->cluster_data, n*512);
-
-	if (ret < 0)
-		return ret;
-	return 0;
-}
-
-static void l2_cache_reset(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-
-	memset(s->l2_cache, 0, s->l2_size * L2_CACHE_SIZE * sizeof(uint64_t));
-	memset(s->l2_cache_offsets, 0, L2_CACHE_SIZE * sizeof(uint64_t));
-	memset(s->l2_cache_counts, 0, L2_CACHE_SIZE * sizeof(uint32_t));
-}
-
-static inline int l2_cache_new_entry(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	uint32_t min_count;
-	int min_index, i;
-
-	/* find a new entry in the least used one */
-	min_index = 0;
-	min_count = 0xffffffff;
-	for(i = 0; i < L2_CACHE_SIZE; i++) {
-		if (s->l2_cache_counts[i] < min_count) {
-			min_count = s->l2_cache_counts[i];
-			min_index = i;
-		}
-	}
-	return min_index;
-}
-
-static int64_t align_offset(int64_t offset, int n)
-{
-	offset = (offset + n - 1) & ~(n - 1);
-	return offset;
-}
-
-static int grow_l1_table(struct disk_driver *bs, int min_size)
-{
-	BDRVQcowState *s = bs->private;
-	int new_l1_size, new_l1_size2, ret, i;
-	uint64_t *new_l1_table;
-	uint64_t new_l1_table_offset;
-	uint64_t data64;
-	uint32_t data32;
-
-	new_l1_size = s->l1_size;
-	if (min_size <= new_l1_size)
-		return 0;
-	while (min_size > new_l1_size) {
-		new_l1_size = (new_l1_size * 3 + 1) / 2;
-	}
-
-#ifdef DEBUG_ALLOC2
-	DPRINTF("grow l1_table from %d to %d\n", s->l1_size, new_l1_size);
-#endif
-
-	new_l1_size2 = sizeof(uint64_t) * new_l1_size;
-	new_l1_table = qemu_mallocz(new_l1_size2);
-	if (!new_l1_table)
-		return -ENOMEM;
-	memcpy(new_l1_table, s->l1_table, s->l1_size * sizeof(uint64_t));
-
-	/* write new table (align to cluster) */
-	new_l1_table_offset = alloc_clusters(bs, new_l1_size2);
-
-	for(i = 0; i < s->l1_size; i++)
-		new_l1_table[i] = cpu_to_be64(new_l1_table[i]);
-
-
-	if (lseek(s->fd, new_l1_table_offset, SEEK_SET) == -1)
-		goto fail;
-
-	ret = write(s->fd, new_l1_table, new_l1_size2);
-	if (ret != new_l1_size2)
-		goto fail;
-
-
-	for(i = 0; i < s->l1_size; i++)
-		new_l1_table[i] = be64_to_cpu(new_l1_table[i]);
-
-	/* set new table */
-	data64 = cpu_to_be64(new_l1_table_offset);
-
-	if (lseek(s->fd, offsetof(QCowHeader, l1_table_offset), SEEK_SET) == -1)
-		goto fail;
-
-	if (write(s->fd, &data64, sizeof(data64)) != sizeof(data64))
-		goto fail;
-
-	data32 = cpu_to_be32(new_l1_size);
-
-	if (bdrv_pwrite(s->fd, offsetof(QCowHeader, l1_size),
-					&data32, sizeof(data32)) != sizeof(data32))
-		goto fail;
-	qemu_free(s->l1_table);
-	free_clusters(bs, s->l1_table_offset, s->l1_size * sizeof(uint64_t));
-	s->l1_table_offset = new_l1_table_offset;
-	s->l1_table = new_l1_table;
-	s->l1_size = new_l1_size;
-	return 0;
- fail:
-	qemu_free(s->l1_table);
-	return -EIO;
-}
-
-/* 'allocate' is:
- *
- * 0 not to allocate.
- *
- * 1 to allocate a normal cluster (for sector indexes 'n_start' to
- * 'n_end')
- *
- * 2 to allocate a compressed cluster of size
- * 'compressed_size'. 'compressed_size' must be > 0 and <
- * cluster_size
- *
- * return 0 if not allocated.
- */
-static uint64_t get_cluster_offset(struct disk_driver *bs,
-		uint64_t offset, int allocate,
-		int compressed_size,
-		int n_start, int n_end)
-{
-	BDRVQcowState *s = bs->private;
-	int min_index, i, j, l1_index, l2_index, ret;
-	uint64_t l2_offset, *l2_table, cluster_offset, tmp, old_l2_offset;
-
-	l1_index = offset >> (s->l2_bits + s->cluster_bits);
-	if (l1_index >= s->l1_size) {
-		/* outside l1 table is allowed: we grow the table if needed */
-		if (!allocate)
-			return 0;
-
-		if (grow_l1_table(bs, l1_index + 1) < 0) {
-			DPRINTF("Could not grow L1 table");
-			return 0;
-		}
-	}
-
-	l2_offset = s->l1_table[l1_index];
-	if (!l2_offset) {
-		if (!allocate)
-			return 0;
-
-	l2_allocate:
-		old_l2_offset = l2_offset;
-		/* allocate a new l2 entry */
-		l2_offset = alloc_clusters(bs, s->l2_size * sizeof(uint64_t));
-		
-		/* update the L1 entry */
-		s->l1_table[l1_index] = l2_offset | QCOW_OFLAG_COPIED;
-		tmp = cpu_to_be64(l2_offset | QCOW_OFLAG_COPIED);
-		if (bdrv_pwrite(s->fd, s->l1_table_offset + l1_index * sizeof(tmp),
-						&tmp, sizeof(tmp)) != sizeof(tmp))
-			return 0;
-		min_index = l2_cache_new_entry(bs);
-		l2_table = s->l2_cache + (min_index << s->l2_bits);
-
-		if (old_l2_offset == 0) {
-			memset(l2_table, 0, s->l2_size * sizeof(uint64_t));
-		} else {
-			if (bdrv_pread(s->fd, old_l2_offset,
-						   l2_table, s->l2_size * sizeof(uint64_t)) !=
-				s->l2_size * sizeof(uint64_t))
-				return 0;
-		}
-		if (bdrv_pwrite(s->fd, l2_offset,
-						l2_table, s->l2_size * sizeof(uint64_t)) !=
-			s->l2_size * sizeof(uint64_t))
-			return 0;
-	} else {
-		if (!(l2_offset & QCOW_OFLAG_COPIED)) {
-			if (allocate) {
-				free_clusters(bs, l2_offset, s->l2_size * sizeof(uint64_t));
-				goto l2_allocate;
-			}
-		} else {
-			l2_offset &= ~QCOW_OFLAG_COPIED;
-		}
-		for(i = 0; i < L2_CACHE_SIZE; i++) {
-			if (l2_offset == s->l2_cache_offsets[i]) {
-				/* increment the hit count */
-				if (++s->l2_cache_counts[i] == 0xffffffff) {
-					for(j = 0; j < L2_CACHE_SIZE; j++) {
-						s->l2_cache_counts[j] >>= 1;
-					}
-				}
-				l2_table = s->l2_cache + (i << s->l2_bits);
-				goto found;
-			}
-		}
-		/* not found: load a new entry in the least used one */
-		min_index = l2_cache_new_entry(bs);
-		l2_table = s->l2_cache + (min_index << s->l2_bits);
-
-		if (bdrv_pread(s->fd, l2_offset, l2_table, s->l2_size * sizeof(uint64_t)) !=
-			s->l2_size * sizeof(uint64_t))
-		{
-			DPRINTF("Could not read L2 table");
-			return 0;
-		}
-	}
-	s->l2_cache_offsets[min_index] = l2_offset;
-	s->l2_cache_counts[min_index] = 1;
-found:
-	l2_index = (offset >> s->cluster_bits) & (s->l2_size - 1);
-
-	cluster_offset = be64_to_cpu(l2_table[l2_index]);
-	if (!cluster_offset) {
-		if (!allocate) {
-			return cluster_offset;
-		}
-	} else if (!(cluster_offset & QCOW_OFLAG_COPIED)) {
-		if (!allocate)
-			return cluster_offset;
-		/* free the cluster */
-		if (cluster_offset & QCOW_OFLAG_COMPRESSED) {
-			int nb_csectors;
-			nb_csectors = ((cluster_offset >> s->csize_shift) &
-					s->csize_mask) + 1;
-			free_clusters(bs, (cluster_offset & s->cluster_offset_mask) & ~511,
-					nb_csectors * 512);
-		} else {
-			free_clusters(bs, cluster_offset, s->cluster_size);
-		}
-	} else {
-		cluster_offset &= ~QCOW_OFLAG_COPIED;
-		return cluster_offset;
-	}
-	if (allocate == 1) {
-		/* allocate a new cluster */
-		cluster_offset = alloc_clusters(bs, s->cluster_size);
-
-		/* we must initialize the cluster content which won't be
-		   written */
-		if ((n_end - n_start) < s->cluster_sectors) {
-			uint64_t start_sect;
-
-			start_sect = (offset & ~(s->cluster_size - 1)) >> 9;
-			ret = copy_sectors(bs, start_sect,
-					cluster_offset, 0, n_start);
-			if (ret < 0)
-				return 0;
-			ret = copy_sectors(bs, start_sect,
-					cluster_offset, n_end, s->cluster_sectors);
-			if (ret < 0)
-				return 0;
-		}
-		tmp = cpu_to_be64(cluster_offset | QCOW_OFLAG_COPIED);
-	} else {
-		int nb_csectors;
-		cluster_offset = alloc_bytes(bs, compressed_size);
-		nb_csectors = ((cluster_offset + compressed_size - 1) >> 9) -
-			(cluster_offset >> 9);
-		cluster_offset |= QCOW_OFLAG_COMPRESSED |
-			((uint64_t)nb_csectors << s->csize_shift);
-		/* compressed clusters never have the copied flag */
-		tmp = cpu_to_be64(cluster_offset);
-	}
-	/* update L2 table */
-	l2_table[l2_index] = tmp;
-
-	if (bdrv_pwrite(s->fd, l2_offset + l2_index * sizeof(tmp), &tmp, sizeof(tmp)) != sizeof(tmp))
-		return 0;
-	return cluster_offset;
-}
-
-static int qcow_is_allocated(struct disk_driver *bs, int64_t sector_num,
-		int nb_sectors, int *pnum)
-{
-	BDRVQcowState *s = bs->private;
-	int index_in_cluster, n;
-	uint64_t cluster_offset;
-
-	cluster_offset = get_cluster_offset(bs, sector_num << 9, 0, 0, 0, 0);
-	index_in_cluster = sector_num & (s->cluster_sectors - 1);
-	n = s->cluster_sectors - index_in_cluster;
-	if (n > nb_sectors)
-		n = nb_sectors;
-	*pnum = n;
-	return (cluster_offset != 0);
-}
-
-static int decompress_buffer(uint8_t *out_buf, int out_buf_size,
-		const uint8_t *buf, int buf_size)
-{
-	z_stream strm1, *strm = &strm1;
-	int ret, out_len;
-
-	memset(strm, 0, sizeof(*strm));
-
-	strm->next_in = (uint8_t *)buf;
-	strm->avail_in = buf_size;
-	strm->next_out = out_buf;
-	strm->avail_out = out_buf_size;
-
-	ret = inflateInit2(strm, -12);
-	if (ret != Z_OK)
-		return -1;
-	ret = inflate(strm, Z_FINISH);
-	out_len = strm->next_out - out_buf;
-	if ((ret != Z_STREAM_END && ret != Z_BUF_ERROR) ||
-		out_len != out_buf_size) {
-		inflateEnd(strm);
-		return -1;
-	}
-	inflateEnd(strm);
-	return 0;
-}
-
-static int decompress_cluster(BDRVQcowState *s, uint64_t cluster_offset)
-{
-	int ret, csize, nb_csectors, sector_offset;
-	uint64_t coffset;
-
-	coffset = cluster_offset & s->cluster_offset_mask;
-	if (s->cluster_cache_offset != coffset) {
-		nb_csectors = ((cluster_offset >> s->csize_shift) & s->csize_mask) + 1;
-		sector_offset = coffset & 511;
-		csize = nb_csectors * 512 - sector_offset;
-		ret = bdrv_read(s->fd, coffset >> 9, s->cluster_data, nb_csectors);
-		if (ret < 0) {
-			return -1;
-		}
-		if (decompress_buffer(s->cluster_cache, s->cluster_size,
-							  s->cluster_data + sector_offset, csize) < 0) {
-			return -1;
-		}
-		s->cluster_cache_offset = coffset;
-	}
-	return 0;
-}
-
-/* handle reading after the end of the backing file */
-static int backing_read1(struct disk_driver *bs,
-		int64_t sector_num, uint8_t *buf, int nb_sectors)
-{
-	int n1;
-	BDRVQcowState* s = bs->private;
-
-	if ((sector_num + nb_sectors) <= s->total_sectors)
-		return nb_sectors;
-	if (sector_num >= s->total_sectors)
-		n1 = 0;
-	else
-		n1 = s->total_sectors - sector_num;
-	memset(buf + n1 * 512, 0, 512 * (nb_sectors - n1));
-	return n1;
-}
-
-/**
- * Reads a number of sectors from the image (synchronous)
- */
-static int qcow_read(struct disk_driver *bs, uint64_t sector_num,
-		uint8_t *buf, int nb_sectors)
-{
-	BDRVQcowState *s = bs->private;
-	int ret, index_in_cluster, n, n1;
-	uint64_t cluster_offset;
-
-	while (nb_sectors > 0) {
-		cluster_offset = get_cluster_offset(bs, sector_num << 9, 0, 0, 0, 0);
-		index_in_cluster = sector_num & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-		if (!cluster_offset) {
-
-			if (bs->next) {
-
-				/* Read from backing file */
-				struct disk_driver *parent = bs->next;
-
-				ret = qcow_sync_read(parent, sector_num, 
-						nb_sectors, (char*) buf, NULL, 0, NULL);
-
-#if 0		
-				/* read from the base image */
-				n1 = backing_read1(s->backing_hd, sector_num, buf, n);
-				if (n1 > 0) {
-					ret = bdrv_read(((BDRVQcowState*) s->backing_hd)->fd, sector_num, buf, n1);
-					if (ret < 0) {
-						DPRINTF("read from backing file failed: ret = %d; errno = %d\n", ret, errno);
-						return -1;
-					}
-				}
-#endif
-			} else {
-				memset(buf, 0, 512 * n);
-			}
-		} else if (cluster_offset & QCOW_OFLAG_COMPRESSED) {
-			if (decompress_cluster(s, cluster_offset) < 0) {
-				DPRINTF("read/decompression failed: errno = %d\n", errno);
-				return -1;
-			}
-			memcpy(buf, s->cluster_cache + index_in_cluster * 512, 512 * n);
-		} else {
-			ret = bdrv_pread(s->fd, cluster_offset + index_in_cluster * 512, buf, n * 512);
-			if (ret != n * 512) {
-				DPRINTF("read failed: ret = %d != n * 512 = %d; errno = %d\n", ret, n * 512, errno);
-				DPRINTF("  cluster_offset = %"PRIx64", index = %d; sector_num = %"PRId64"", cluster_offset, index_in_cluster, sector_num);
-				return -1;
-			}
-
-			if (s->crypt_method) {
-				encrypt_sectors(s, sector_num, buf, buf, n, 0,
-						&s->aes_decrypt_key);
-			}
-		}
-		nb_sectors -= n;
-		sector_num += n;
-		buf += n * 512;
-	}
-	return 0;
-}
-
-/**
- * Writes a number of sectors to the image (synchronous)
- */
-static int qcow_write(struct disk_driver *bs, uint64_t sector_num,
-		const uint8_t *buf, int nb_sectors)
-{
-	BDRVQcowState *s = bs->private;
-	int ret, index_in_cluster, n;
-	uint64_t cluster_offset;
-
-	while (nb_sectors > 0) {
-		index_in_cluster = sector_num & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-		cluster_offset = get_cluster_offset(bs, sector_num << 9, 1, 0,
-											index_in_cluster,
-											index_in_cluster + n);
-		if (!cluster_offset) {
-			DPRINTF("qcow_write: cluster_offset == 0\n");
-			DPRINTF("  index = %d; sector_num = %"PRId64"\n", 
-				index_in_cluster, sector_num);
-			return -1;
-		}
-
-		if (s->crypt_method) {
-			encrypt_sectors(s, sector_num, s->cluster_data, buf, n, 1,
-					&s->aes_encrypt_key);
-			ret = bdrv_pwrite(s->fd, cluster_offset + index_in_cluster * 512,
-					s->cluster_data, n * 512);
-		} else {
-			ret = bdrv_pwrite(s->fd, cluster_offset + index_in_cluster * 512, buf, n * 512);
-		}
-		if (ret != n * 512) {
-			DPRINTF("write failed: ret = %d != n * 512 = %d; errno = %d\n", ret, n * 512, errno);
-			DPRINTF("  cluster_offset = %"PRIx64", index = %d; sector_num = %"PRId64"\n", cluster_offset, index_in_cluster, sector_num);
-			return -1;
-		}
-
-		nb_sectors -= n;
-		sector_num += n;
-		buf += n * 512;
-	}
-	s->cluster_cache_offset = -1; /* disable compressed cache */
-	return 0;
-}
-
-
-
-#ifdef USE_AIO
-
-/*
- * QCOW2 specific AIO functions
- */
-
-static int qcow_queue_read(struct disk_driver *bs, uint64_t sector,
-		int nb_sectors, char *buf, td_callback_t cb,
-		int id, void *private)
-{
-	BDRVQcowState *s = bs->private;
-	int i, index_in_cluster, n, ret;
-	int rsp = 0;
-	uint64_t cluster_offset;
-
-	/*Check we can get a lock*/
-	for (i = 0; i < nb_sectors; i++) 
-		if (!tap_aio_can_lock(&s->async, sector + i)) 
-			return cb(bs, -EBUSY, sector, nb_sectors, id, private);
-
-	while (nb_sectors > 0) {
-		
-		cluster_offset = get_cluster_offset(bs, sector << 9, 0, 0, 0, 0);
-				
-		index_in_cluster = sector & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-
-		if (s->async.iocb_free_count == 0 || !tap_aio_lock(&s->async, sector)) 
-			return cb(bs, -EBUSY, sector, nb_sectors, id, private);
-
-		if (!cluster_offset) {
-
-			/* The requested sector is not allocated */
-			tap_aio_unlock(&s->async, sector);
-			ret = cb(bs, BLK_NOT_ALLOCATED, 
-					sector, n, id, private);
-			if (ret == -EBUSY) {
-				/* mark remainder of request
-				 * as busy and try again later */
-				return cb(bs, -EBUSY, sector + n,
-						nb_sectors - n, id, private);
-			} else {
-				rsp += ret;
-			}
-
-		} else if (cluster_offset & QCOW_OFLAG_COMPRESSED) {
-
-			/* sync read for compressed clusters */
-			tap_aio_unlock(&s->async, sector);
-			if (decompress_cluster(s, cluster_offset) < 0) {
-				rsp += cb(bs, -EIO, sector, nb_sectors, id, private);
-				goto done;
-			}
-			memcpy(buf, s->cluster_cache + index_in_cluster * 512, 
-					512 * n);
-			rsp += cb(bs, 0, sector, n, id, private);
-
-		} else {
-
-			/* async read */
-			tap_aio_read(&s->async, s->fd, n * 512, 
-					(cluster_offset + index_in_cluster * 512),
-					buf, cb, id, sector, private);
-		}
-
-		/* Prepare for next sector to read */
-		nb_sectors -= n;
-		sector += n;
-		buf += n * 512;
-	}
-
-done:
-	return rsp;
-
-}
-
-static int qcow_queue_write(struct disk_driver *bs, uint64_t sector,
-		int nb_sectors, char *buf, td_callback_t cb,
-		int id, void *private)
-{
-	BDRVQcowState *s = bs->private;
-	int i, n, index_in_cluster;
-	uint64_t cluster_offset;
-	const uint8_t *src_buf;
-		
-	
-	/*Check we can get a lock*/
-	for (i = 0; i < nb_sectors; i++) 
-		if (!tap_aio_can_lock(&s->async, sector + i)) 
-			return cb(bs, -EBUSY, sector, nb_sectors, id, private);
-
-
-	while (nb_sectors > 0) {
-				
-		index_in_cluster = sector & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-
-		if (s->async.iocb_free_count == 0 || !tap_aio_lock(&s->async, sector))
-			return cb(bs, -EBUSY, sector, nb_sectors, id, private);
-
-
-		cluster_offset = get_cluster_offset(bs, sector << 9, 1, 0,
-				index_in_cluster, 
-				index_in_cluster+n);
-
-		if (!cluster_offset) {
-			DPRINTF("Ooops, no write cluster offset!\n");
-			tap_aio_unlock(&s->async, sector);
-			return cb(bs, -EIO, sector, nb_sectors, id, private);
-		}
-
-
-		// TODO Encryption
-
-		tap_aio_write(&s->async, s->fd, n * 512, 
-				(cluster_offset + index_in_cluster*512),
-				buf, cb, id, sector, private);
-
-		/* Prepare for next sector to write */
-		nb_sectors -= n;
-		sector += n;
-		buf += n * 512;
-	}
-
-		
-	s->cluster_cache_offset = -1; /* disable compressed cache */
-
-	return 0;
-}
-
-
-#endif /* USE_AIO */
-
-
-static int qcow_close(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	
-#ifdef USE_AIO	
-	io_destroy(s->async.aio_ctx.aio_ctx);
-	tap_aio_free(&s->async);
-#else		
-	close(s->poll_pipe[0]);
-	close(s->poll_pipe[1]);
-#endif		
-
-	qemu_free(s->l1_table);
-	qemu_free(s->l2_cache);
-	qemu_free(s->cluster_cache);
-	qemu_free(s->cluster_data);
-	refcount_close(bs);
-	return close(s->fd);
-}
-
-/* XXX: use std qcow open function ? */
-typedef struct QCowCreateState {
-	int cluster_size;
-	int cluster_bits;
-	uint16_t *refcount_block;
-	uint64_t *refcount_table;
-	int64_t l1_table_offset;
-	int64_t refcount_table_offset;
-	int64_t refcount_block_offset;
-} QCowCreateState;
-
-static void create_refcount_update(QCowCreateState *s,
-		int64_t offset, int64_t size)
-{
-	int refcount;
-	int64_t start, last, cluster_offset;
-	uint16_t *p;
-
-	start = offset & ~(s->cluster_size - 1);
-	last = (offset + size - 1)	& ~(s->cluster_size - 1);
-	for(cluster_offset = start; cluster_offset <= last;
-		cluster_offset += s->cluster_size) {
-		p = &s->refcount_block[cluster_offset >> s->cluster_bits];
-		refcount = be16_to_cpu(*p);
-		refcount++;
-		*p = cpu_to_be16(refcount);
-	}
-}
-
-static int qcow_submit(struct disk_driver *bs)
-{
-	struct BDRVQcowState *s = (struct BDRVQcowState*) bs->private;
-
-	fsync(s->fd);
-	return tap_aio_submit(&s->async);
-}
-
-
-/*********************************************************/
-/* snapshot support */
-
-
-static void qcow_free_snapshots(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	int i;
-
-	for(i = 0; i < s->nb_snapshots; i++) {
-		qemu_free(s->snapshots[i].name);
-		qemu_free(s->snapshots[i].id_str);
-	}
-	qemu_free(s->snapshots);
-	s->snapshots = NULL;
-	s->nb_snapshots = 0;
-}
-
-static int qcow_read_snapshots(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	QCowSnapshotHeader h;
-	QCowSnapshot *sn;
-	int i, id_str_size, name_size;
-	int64_t offset;
-	uint32_t extra_data_size;
-
-	offset = s->snapshots_offset;
-	s->snapshots = qemu_mallocz(s->nb_snapshots * sizeof(QCowSnapshot));
-	if (!s->snapshots)
-		goto fail;
-	for(i = 0; i < s->nb_snapshots; i++) {
-		offset = align_offset(offset, 8);
-		if (bdrv_pread(s->fd, offset, &h, sizeof(h)) != sizeof(h))
-			goto fail;
-		offset += sizeof(h);
-		sn = s->snapshots + i;
-		sn->l1_table_offset = be64_to_cpu(h.l1_table_offset);
-		sn->l1_size = be32_to_cpu(h.l1_size);
-		sn->vm_state_size = be32_to_cpu(h.vm_state_size);
-		sn->date_sec = be32_to_cpu(h.date_sec);
-		sn->date_nsec = be32_to_cpu(h.date_nsec);
-		sn->vm_clock_nsec = be64_to_cpu(h.vm_clock_nsec);
-		extra_data_size = be32_to_cpu(h.extra_data_size);
-
-		id_str_size = be16_to_cpu(h.id_str_size);
-		name_size = be16_to_cpu(h.name_size);
-
-		offset += extra_data_size;
-
-		sn->id_str = qemu_malloc(id_str_size + 1);
-		if (!sn->id_str)
-			goto fail;
-		if (bdrv_pread(s->fd, offset, sn->id_str, id_str_size) != id_str_size)
-			goto fail;
-		offset += id_str_size;
-		sn->id_str[id_str_size] = '\0';
-
-		sn->name = qemu_malloc(name_size + 1);
-		if (!sn->name)
-			goto fail;
-		if (bdrv_pread(s->fd, offset, sn->name, name_size) != name_size)
-			goto fail;
-		offset += name_size;
-		sn->name[name_size] = '\0';
-	}
-	s->snapshots_size = offset - s->snapshots_offset;
-	return 0;
-fail:
-	qcow_free_snapshots(bs);
-	return -1;
-}
-
-
-/*********************************************************/
-/* refcount handling */
-
-static int refcount_init(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	int ret, refcount_table_size2, i;
-
-	s->refcount_block_cache = qemu_malloc(s->cluster_size);
-	if (!s->refcount_block_cache)
-		goto fail;
-	refcount_table_size2 = s->refcount_table_size * sizeof(uint64_t);
-	s->refcount_table = qemu_malloc(refcount_table_size2);
-	if (!s->refcount_table)
-		goto fail;
-	if (s->refcount_table_size > 0) {
-		ret = bdrv_pread(s->fd, s->refcount_table_offset,
-				s->refcount_table, refcount_table_size2);
-		if (ret != refcount_table_size2)
-			goto fail;
-		for(i = 0; i < s->refcount_table_size; i++)
-			be64_to_cpus(&s->refcount_table[i]);
-	}
-	return 0;
- fail:
-	return -ENOMEM;
-}
-
-static void refcount_close(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	qemu_free(s->refcount_block_cache);
-	qemu_free(s->refcount_table);
-}
-
-
-static int load_refcount_block(struct disk_driver *bs,
-		int64_t refcount_block_offset)
-{
-	BDRVQcowState *s = bs->private;
-	int ret;
-	ret = bdrv_pread(s->fd, refcount_block_offset, s->refcount_block_cache,
-			s->cluster_size);
-	if (ret != s->cluster_size)
-		return -EIO;
-	s->refcount_block_cache_offset = refcount_block_offset;
-	return 0;
-}
-
-static int get_refcount(struct disk_driver *bs, int64_t cluster_index)
-{
-	BDRVQcowState *s = bs->private;
-	int refcount_table_index, block_index;
-	int64_t refcount_block_offset;
-
-	refcount_table_index = cluster_index >> (s->cluster_bits - REFCOUNT_SHIFT);
-	if (refcount_table_index >= s->refcount_table_size)
-		return 0;
-	refcount_block_offset = s->refcount_table[refcount_table_index];
-	if (!refcount_block_offset)
-		return 0;
-	if (refcount_block_offset != s->refcount_block_cache_offset) {
-		/* better than nothing: return allocated if read error */
-		if (load_refcount_block(bs, refcount_block_offset) < 0)
-			return 1;
-	}
-	block_index = cluster_index &
-		((1 << (s->cluster_bits - REFCOUNT_SHIFT)) - 1);
-	return be16_to_cpu(s->refcount_block_cache[block_index]);
-}
-
-/* return < 0 if error */
-static int64_t alloc_clusters_noref(struct disk_driver *bs, int64_t size)
-{
-	BDRVQcowState *s = bs->private;
-	int i, nb_clusters;
-
-	nb_clusters = (size + s->cluster_size - 1) >> s->cluster_bits;
-	for(;;) {
-		if (get_refcount(bs, s->free_cluster_index) == 0) {
-			s->free_cluster_index++;
-			for(i = 1; i < nb_clusters; i++) {
-				if (get_refcount(bs, s->free_cluster_index) != 0)
-					goto not_found;
-				s->free_cluster_index++;
-			}
-
-#ifdef DEBUG_ALLOC2
-			DPRINTF("alloc_clusters: size=%ld -> %ld\n",
-				   size,
-				   (s->free_cluster_index - nb_clusters) << s->cluster_bits);
-#endif
-
-			return (s->free_cluster_index - nb_clusters) << s->cluster_bits;
-		} else {
-		not_found:
-			s->free_cluster_index++;
-		}
-	}
-}
-
-static int64_t alloc_clusters(struct disk_driver *bs, int64_t size)
-{
-	int64_t offset;
-
-	offset = alloc_clusters_noref(bs, size);
-	update_refcount(bs, offset, size, 1);
-	return offset;
-}
-
-/* only used to allocate compressed sectors. We try to allocate
-   contiguous sectors. size must be <= cluster_size */
-static int64_t alloc_bytes(struct disk_driver *bs, int size)
-{
-	BDRVQcowState *s = bs->private;
-	int64_t offset, cluster_offset;
-	int free_in_cluster;
-
-	assert(size > 0 && size <= s->cluster_size);
-	if (s->free_byte_offset == 0) {
-		s->free_byte_offset = alloc_clusters(bs, s->cluster_size);
-	}
-redo:
-	free_in_cluster = s->cluster_size -
-		(s->free_byte_offset & (s->cluster_size - 1));
-	if (size <= free_in_cluster) {
-		/* enough space in current cluster */
-		offset = s->free_byte_offset;
-		s->free_byte_offset += size;
-		free_in_cluster -= size;
-		if (free_in_cluster == 0)
-			s->free_byte_offset = 0;
-		if ((offset & (s->cluster_size - 1)) != 0)
-			update_cluster_refcount(bs, offset >> s->cluster_bits, 1);
-	} else {
-		offset = alloc_clusters(bs, s->cluster_size);
-		cluster_offset = s->free_byte_offset & ~(s->cluster_size - 1);
-		if ((cluster_offset + s->cluster_size) == offset) {
-			/* we are lucky: contiguous data */
-			offset = s->free_byte_offset;
-			update_cluster_refcount(bs, offset >> s->cluster_bits, 1);
-			s->free_byte_offset += size;
-		} else {
-			s->free_byte_offset = offset;
-			goto redo;
-		}
-	}
-	return offset;
-}
-
-static void free_clusters(struct disk_driver *bs,
-		int64_t offset, int64_t size)
-{
-	update_refcount(bs, offset, size, -1);
-}
-
-static int grow_refcount_table(struct disk_driver *bs, int min_size)
-{
-	BDRVQcowState *s = bs->private;
-	int new_table_size, new_table_size2, refcount_table_clusters, i, ret;
-	uint64_t *new_table;
-	int64_t table_offset;
-	uint64_t data64;
-	uint32_t data32;
-	int old_table_size;
-	int64_t old_table_offset;
-
-	if (min_size <= s->refcount_table_size)
-		return 0;
-	
-	/* compute new table size */
-	refcount_table_clusters = s->refcount_table_size >> (s->cluster_bits - 3);
-	for(;;) {
-		if (refcount_table_clusters == 0) {
-			refcount_table_clusters = 1;
-		} else {
-			refcount_table_clusters = (refcount_table_clusters * 3 + 1) / 2;
-		}
-		new_table_size = refcount_table_clusters << (s->cluster_bits - 3);
-		if (min_size <= new_table_size)
-			break;
-	}
-
-#ifdef DEBUG_ALLOC2
-	printf("grow_refcount_table from %d to %d\n",
-		   s->refcount_table_size,
-		   new_table_size);
-#endif
-	new_table_size2 = new_table_size * sizeof(uint64_t);
-	new_table = qemu_mallocz(new_table_size2);
-	if (!new_table)
-		return -ENOMEM;
-	memcpy(new_table, s->refcount_table,
-		   s->refcount_table_size * sizeof(uint64_t));
-	for(i = 0; i < s->refcount_table_size; i++)
-		cpu_to_be64s(&new_table[i]);
-	/* Note: we cannot update the refcount now to avoid recursion */
-	table_offset = alloc_clusters_noref(bs, new_table_size2);
-	ret = bdrv_pwrite(s->fd, table_offset, new_table, new_table_size2);
-	if (ret != new_table_size2)
-		goto fail;
-	for(i = 0; i < s->refcount_table_size; i++)
-		be64_to_cpus(&new_table[i]);
-
-	data64 = cpu_to_be64(table_offset);
-	if (bdrv_pwrite(s->fd, offsetof(QCowHeader, refcount_table_offset),
-					&data64, sizeof(data64)) != sizeof(data64))
-		goto fail;
-	data32 = cpu_to_be32(refcount_table_clusters);
-	if (bdrv_pwrite(s->fd, offsetof(QCowHeader, refcount_table_clusters),
-					&data32, sizeof(data32)) != sizeof(data32))
-		goto fail;
-	qemu_free(s->refcount_table);
-	old_table_offset = s->refcount_table_offset;
-	old_table_size = s->refcount_table_size;
-	s->refcount_table = new_table;
-	s->refcount_table_size = new_table_size;
-	s->refcount_table_offset = table_offset;
-
-	update_refcount(bs, table_offset, new_table_size2, 1);
-	free_clusters(bs, old_table_offset, old_table_size * sizeof(uint64_t));
-	return 0;
- fail:
-	free_clusters(bs, table_offset, new_table_size2);
-	qemu_free(new_table);
-	return -EIO;
-}
-
-/* addend must be 1 or -1 */
-/* XXX: cache several refcount block clusters ? */
-static int update_cluster_refcount(struct disk_driver *bs,
-		int64_t cluster_index,
-		int addend)
-{
-	BDRVQcowState *s = bs->private;
-	int64_t offset, refcount_block_offset;
-	int ret, refcount_table_index, block_index, refcount;
-	uint64_t data64;
-
-	refcount_table_index = cluster_index >> (s->cluster_bits - REFCOUNT_SHIFT);
-	if (refcount_table_index >= s->refcount_table_size) {
-		if (addend < 0)
-			return -EINVAL;
-		ret = grow_refcount_table(bs, refcount_table_index + 1);
-		if (ret < 0)
-			return ret;
-	}
-	refcount_block_offset = s->refcount_table[refcount_table_index];
-	if (!refcount_block_offset) {
-		if (addend < 0)
-			return -EINVAL;
-		/* create a new refcount block */
-		/* Note: we cannot update the refcount now to avoid recursion */
-		offset = alloc_clusters_noref(bs, s->cluster_size);
-		memset(s->refcount_block_cache, 0, s->cluster_size);
-		ret = bdrv_pwrite(s->fd, offset, s->refcount_block_cache, s->cluster_size);
-		if (ret != s->cluster_size)
-			return -EINVAL;
-		s->refcount_table[refcount_table_index] = offset;
-		data64 = cpu_to_be64(offset);
-		ret = bdrv_pwrite(s->fd, s->refcount_table_offset +
-						  refcount_table_index * sizeof(uint64_t),
-						  &data64, sizeof(data64));
-		if (ret != sizeof(data64))
-			return -EINVAL;
-
-		refcount_block_offset = offset;
-		s->refcount_block_cache_offset = offset;
-		update_refcount(bs, offset, s->cluster_size, 1);
-	} else {
-		if (refcount_block_offset != s->refcount_block_cache_offset) {
-			if (load_refcount_block(bs, refcount_block_offset) < 0)
-				return -EIO;
-		}
-	}
-	/* we can update the count and save it */
-	block_index = cluster_index &
-		((1 << (s->cluster_bits - REFCOUNT_SHIFT)) - 1);
-	refcount = be16_to_cpu(s->refcount_block_cache[block_index]);
-	refcount += addend;
-	if (refcount < 0 || refcount > 0xffff)
-		return -EINVAL;
-	if (refcount == 0 && cluster_index < s->free_cluster_index) {
-		s->free_cluster_index = cluster_index;
-	}
-	s->refcount_block_cache[block_index] = cpu_to_be16(refcount);
-	if (bdrv_pwrite(s->fd,
-					refcount_block_offset + (block_index << REFCOUNT_SHIFT),
-					&s->refcount_block_cache[block_index], 2) != 2)
-		return -EIO;
-	return refcount;
-}
-
-static void update_refcount(struct disk_driver *bs,
-		int64_t offset, int64_t length,
-		int addend)
-{
-	BDRVQcowState *s = bs->private;
-	int64_t start, last, cluster_offset;
-
-#ifdef DEBUG_ALLOC2
-	printf("update_refcount: offset=%lld size=%lld addend=%d\n",
-		   offset, length, addend);
-#endif
-	if (length <= 0)
-		return;
-	start = offset & ~(s->cluster_size - 1);
-	last = (offset + length - 1) & ~(s->cluster_size - 1);
-	for(cluster_offset = start; cluster_offset <= last;
-		cluster_offset += s->cluster_size) {
-		update_cluster_refcount(bs, cluster_offset >> s->cluster_bits, addend);
-	}
-}
-
-#ifdef DEBUG_ALLOC
-static void inc_refcounts(struct disk_driver *bs,
-		uint16_t *refcount_table,
-		int refcount_table_size,
-		int64_t offset, int64_t size)
-{
-	BDRVQcowState *s = bs->private;
-	int64_t start, last, cluster_offset;
-	int k;
-
-	if (size <= 0)
-		return;
-
-	start = offset & ~(s->cluster_size - 1);
-	last = (offset + size - 1) & ~(s->cluster_size - 1);
-	for(cluster_offset = start; cluster_offset <= last;
-		cluster_offset += s->cluster_size) {
-		k = cluster_offset >> s->cluster_bits;
-		if (k < 0 || k >= refcount_table_size) {
-			printf("ERROR: invalid cluster offset=0x%llx\n", cluster_offset);
-		} else {
-			if (++refcount_table[k] == 0) {
-				printf("ERROR: overflow cluster offset=0x%llx\n", cluster_offset);
-			}
-		}
-	}
-}
-
-static int check_refcounts_l1(struct disk_driver *bs,
-		uint16_t *refcount_table,
-		int refcount_table_size,
-		int64_t l1_table_offset, int l1_size,
-		int check_copied)
-{
-	BDRVQcowState *s = bs->private;
-	uint64_t *l1_table, *l2_table, l2_offset, offset, l1_size2;
-	int l2_size, i, j, nb_csectors, refcount;
-
-	l2_table = NULL;
-	l1_size2 = l1_size * sizeof(uint64_t);
-
-	inc_refcounts(bs, refcount_table, refcount_table_size,
-				  l1_table_offset, l1_size2);
-
-	l1_table = qemu_malloc(l1_size2);
-	if (!l1_table)
-		goto fail;
-	if (bdrv_pread(s->fd, l1_table_offset,
-				   l1_table, l1_size2) != l1_size2)
-		goto fail;
-	for(i = 0;i < l1_size; i++)
-		be64_to_cpus(&l1_table[i]);
-
-	l2_size = s->l2_size * sizeof(uint64_t);
-	l2_table = qemu_malloc(l2_size);
-	if (!l2_table)
-		goto fail;
-	for(i = 0; i < l1_size; i++) {
-		l2_offset = l1_table[i];
-		if (l2_offset) {
-			if (check_copied) {
-				refcount = get_refcount(bs, (l2_offset & ~QCOW_OFLAG_COPIED) >> s->cluster_bits);
-				if ((refcount == 1) != ((l2_offset & QCOW_OFLAG_COPIED) != 0)) {
-					printf("ERROR OFLAG_COPIED: l2_offset=%llx refcount=%d\n",
-						   l2_offset, refcount);
-				}
-			}
-			l2_offset &= ~QCOW_OFLAG_COPIED;
-			if (bdrv_pread(s->fd, l2_offset, l2_table, l2_size) != l2_size)
-				goto fail;
-			for(j = 0; j < s->l2_size; j++) {
-				offset = be64_to_cpu(l2_table[j]);
-				if (offset != 0) {
-					if (offset & QCOW_OFLAG_COMPRESSED) {
-						if (offset & QCOW_OFLAG_COPIED) {
-							printf("ERROR: cluster %lld: copied flag must never be set for compressed clusters\n",
-								   offset >> s->cluster_bits);
-							offset &= ~QCOW_OFLAG_COPIED;
-						}
-						nb_csectors = ((offset >> s->csize_shift) &
-									   s->csize_mask) + 1;
-						offset &= s->cluster_offset_mask;
-						inc_refcounts(bs, refcount_table,
-								refcount_table_size,
-								offset & ~511, nb_csectors * 512);
-					} else {
-						if (check_copied) {
-							refcount = get_refcount(bs, (offset & ~QCOW_OFLAG_COPIED) >> s->cluster_bits);
-							if ((refcount == 1) != ((offset & QCOW_OFLAG_COPIED) != 0)) {
-								printf("ERROR OFLAG_COPIED: offset=%llx refcount=%d\n",
-									   offset, refcount);
-							}
-						}
-						offset &= ~QCOW_OFLAG_COPIED;
-						inc_refcounts(bs, refcount_table,
-								refcount_table_size,
-								offset, s->cluster_size);
-					}
-				}
-			}
-			inc_refcounts(bs, refcount_table,
-					refcount_table_size,
-					l2_offset,
-					s->cluster_size);
-		}
-	}
-	qemu_free(l1_table);
-	qemu_free(l2_table);
-	return 0;
- fail:
-	printf("ERROR: I/O error in check_refcounts_l1\n");
-	qemu_free(l1_table);
-	qemu_free(l2_table);
-	return -EIO;
-}
-
-static void check_refcounts(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	int64_t size;
-	int nb_clusters, refcount1, refcount2, i;
-	QCowSnapshot *sn;
-	uint16_t *refcount_table;
-
-	size = bdrv_getlength(s->fd);
-	nb_clusters = (size + s->cluster_size - 1) >> s->cluster_bits;
-	refcount_table = qemu_mallocz(nb_clusters * sizeof(uint16_t));
-
-	/* header */
-	inc_refcounts(bs, refcount_table, nb_clusters,
-			0, s->cluster_size);
-
-	check_refcounts_l1(bs, refcount_table, nb_clusters,
-			s->l1_table_offset, s->l1_size, 1);
-
-	/* snapshots */
-	for(i = 0; i < s->nb_snapshots; i++) {
-		sn = s->snapshots + i;
-		check_refcounts_l1(bs, refcount_table, nb_clusters,
-						   sn->l1_table_offset, sn->l1_size, 0);
-	}
-	inc_refcounts(bs, refcount_table, nb_clusters,
-				  s->snapshots_offset, s->snapshots_size);
-
-	/* refcount data */
-	inc_refcounts(bs, refcount_table, nb_clusters,
-			s->refcount_table_offset,
-			s->refcount_table_size * sizeof(uint64_t));
-
-	for(i = 0; i < s->refcount_table_size; i++) {
-		int64_t offset;
-		offset = s->refcount_table[i];
-		if (offset != 0) {
-			inc_refcounts(bs, refcount_table, nb_clusters,
-					offset, s->cluster_size);
-		}
-	}
-
-	/* compare ref counts */
-	for(i = 0; i < nb_clusters; i++) {
-		refcount1 = get_refcount(bs, i);
-		refcount2 = refcount_table[i];
-		if (refcount1 != refcount2)
-			printf("ERROR cluster %d refcount=%d reference=%d\n",
-				   i, refcount1, refcount2);
-	}
-
-	qemu_free(refcount_table);
-}
-#endif
-
-
-/**
- * Wrapper for synchronous read.
- * This function is called when not using AIO at all (#undef USE_AIO) or
- * for accessing the backing file.
- */
-static int qcow_sync_read(struct disk_driver *dd, uint64_t sector,
-		int nb_sectors, char *buf, td_callback_t cb,
-		int id, void *prv)
-{
-	int ret = qcow_read(dd, sector, (uint8_t*) buf, nb_sectors);
-
-	if (cb != NULL) {
-		return cb(dd, (ret < 0) ? ret : 0, sector, nb_sectors, id, prv);
-	} else {
-		return ret;
-	}
-}
-
-#ifndef USE_AIO
-/**
- * Wrapper for synchronous write
- */
-static int qcow_sync_write(struct disk_driver *dd, uint64_t sector,
-		int nb_sectors, char *buf, td_callback_t cb,
-		int id, void *prv)
-{
-	int ret = qcow_write(dd, sector, (uint8_t*) buf, nb_sectors);
-	
-	return cb(dd, (ret < 0) ? ret : 0, sector, nb_sectors, id, prv);
-}
-#endif
-
-
-
-#ifndef USE_AIO
-
-static int qcow_do_callbacks(struct disk_driver *dd, int sid)
-{
-	return 1;
-}
-
-#else
-
-static int qcow_do_callbacks(struct disk_driver *dd, int sid)
-{
-	int ret, i, nr_events, rsp = 0,*ptr;
-	struct io_event *ep;
-	struct BDRVQcowState *prv = (struct BDRVQcowState*)dd->private;
-
-	if (sid > MAX_IOFD) return 1;
-
-	nr_events = tap_aio_get_events(&prv->async.aio_ctx);
-
-repeat:
-	for (ep = prv->async.aio_events, i = nr_events; i-- > 0; ep++) {
-		struct iocb		   *io	= ep->obj;
-		struct pending_aio *pio;
-
-		pio = &prv->async.pending_aio[(long)io->data];
-
-		tap_aio_unlock(&prv->async, pio->sector);
-
-		if (prv->crypt_method)
-			encrypt_sectors(prv, pio->sector, 
-					(unsigned char *)pio->buf, 
-					(unsigned char *)pio->buf, 
-					pio->nb_sectors, 0, 
-					&prv->aes_decrypt_key);
-
-		rsp += pio->cb(dd, ep->res == io->u.c.nbytes ? 0 : 1, 
-			pio->sector, pio->nb_sectors,
-			pio->id, pio->private);
-
-		prv->async.iocb_free[prv->async.iocb_free_count++] = io;
-	}
-
-	if (nr_events) {
-		nr_events = tap_aio_more_events(&prv->async.aio_ctx);
-		goto repeat;
-	}
-
-	tap_aio_continue(&prv->async.aio_ctx);
-
-	return rsp;
-}
-
-#endif	
-
-static int get_filesize(char *filename, uint64_t *size, struct stat *st)
-{
-	int fd;
-	QCowHeader header;
-
-	/*Set to the backing file size*/
-	fd = open(filename, O_RDONLY);
-	if (fd < 0)
-		return -1;
-	if (read(fd, &header, sizeof(header)) < sizeof(header)) {
-		close(fd);
-		return -1;
-	}
-	close(fd);
-	
-	be32_to_cpus(&header.magic);
-	be32_to_cpus(&header.version);
-	be64_to_cpus(&header.size);
-	if (header.magic == QCOW_MAGIC && header.version == QCOW_VERSION) {
-		*size = header.size >> SECTOR_SHIFT;
-		return 0;
-	}
-
-	if(S_ISBLK(st->st_mode)) {
-		fd = open(filename, O_RDONLY);
-		if (fd < 0)
-			return -1;
-		if (blk_getimagesize(fd, size) != 0) {
-			close(fd);
-			return -1;
-		}
-		close(fd);
-	} else *size = (st->st_size >> SECTOR_SHIFT);	
-	return 0;
-}
-
-/**
- * @return 
- *	   0 if parent id successfully retrieved;
- *	   TD_NO_PARENT if no parent exists;
- *	   -errno on error
- */
-static int qcow_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	struct BDRVQcowState* s = (struct BDRVQcowState*) dd->private;
-
-	if (s->backing_file[0] == '\0')
-		return TD_NO_PARENT;
-
-	id->name = strdup(s->backing_file);
-	id->drivertype = DISK_TYPE_AIO;
-
-	return 0;
-}
-
-static int qcow_validate_parent(struct disk_driver *child, 
-		struct disk_driver *parent, td_flag_t flags)
-{
-	struct stat stats;
-	uint64_t psize, csize;
-	
-	if (stat(parent->name, &stats))
-		return -EINVAL;
-	if (get_filesize(parent->name, &psize, &stats))
-		return -EINVAL;
-
-	if (stat(child->name, &stats))
-		return -EINVAL;
-	if (get_filesize(child->name, &csize, &stats))
-		return -EINVAL;
-
-	if (csize != psize)
-		return -EINVAL;
-
-	return 0;
-}
-
-int qcow2_create(const char *filename, uint64_t total_size,
-                      const char *backing_file, int flags)
-{
-    int fd, header_size, backing_filename_len, l1_size, i, shift, l2_bits;
-    int ret = 0;
-    QCowHeader header;
-    uint64_t tmp, offset;
-    QCowCreateState s1, *s = &s1;
-
-    memset(s, 0, sizeof(*s));
-
-    fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY, 0644);
-    if (fd < 0)
-        return -1;
-    memset(&header, 0, sizeof(header));
-    header.magic = cpu_to_be32(QCOW_MAGIC);
-    header.version = cpu_to_be32(QCOW_VERSION);
-    header.size = cpu_to_be64(total_size * 512);
-    header_size = sizeof(header);
-    backing_filename_len = 0;
-    if (backing_file) {
-        header.backing_file_offset = cpu_to_be64(header_size);
-        backing_filename_len = strlen(backing_file);
-        header.backing_file_size = cpu_to_be32(backing_filename_len);
-        header_size += backing_filename_len;
-    }
-    s->cluster_bits = 12;  /* 4 KB clusters */
-    s->cluster_size = 1 << s->cluster_bits;
-    header.cluster_bits = cpu_to_be32(s->cluster_bits);
-    header_size = (header_size + 7) & ~7;
-    if (flags & BLOCK_FLAG_ENCRYPT) {
-        header.crypt_method = cpu_to_be32(QCOW_CRYPT_AES);
-    } else {
-        header.crypt_method = cpu_to_be32(QCOW_CRYPT_NONE);
-    }
-    l2_bits = s->cluster_bits - 3;
-    shift = s->cluster_bits + l2_bits;
-    l1_size = (((total_size * 512) + (1LL << shift) - 1) >> shift);
-    offset = align_offset(header_size, s->cluster_size);
-    s->l1_table_offset = offset;
-    header.l1_table_offset = cpu_to_be64(s->l1_table_offset);
-    header.l1_size = cpu_to_be32(l1_size);
-    offset += align_offset(l1_size * sizeof(uint64_t), s->cluster_size);
-
-    s->refcount_table = qemu_mallocz(s->cluster_size);
-    s->refcount_block = qemu_mallocz(s->cluster_size);
-
-    s->refcount_table_offset = offset;
-    header.refcount_table_offset = cpu_to_be64(offset);
-    header.refcount_table_clusters = cpu_to_be32(1);
-    offset += s->cluster_size;
-
-    s->refcount_table[0] = cpu_to_be64(offset);
-    s->refcount_block_offset = offset;
-    offset += s->cluster_size;
-
-    /* update refcounts */
-    create_refcount_update(s, 0, header_size);
-    create_refcount_update(s, s->l1_table_offset, l1_size * sizeof(uint64_t));
-    create_refcount_update(s, s->refcount_table_offset, s->cluster_size);
-    create_refcount_update(s, s->refcount_block_offset, s->cluster_size);
-
-    /* write all the data */
-    ret = write(fd, &header, sizeof(header));
-    if (ret < 0)
-        goto out;
-    if (backing_file) {
-        ret = write(fd, backing_file, backing_filename_len);
-        if (ret < 0)
-            goto out;
-    }
-    lseek(fd, s->l1_table_offset, SEEK_SET);
-    tmp = 0;
-    for(i = 0;i < l1_size; i++) {
-        ret = write(fd, &tmp, sizeof(tmp));
-        if (ret < 0)
-            goto out;
-    }
-    lseek(fd, s->refcount_table_offset, SEEK_SET);
-    ret = write(fd, s->refcount_table, s->cluster_size);
-    if (ret < 0)
-        goto out;
-
-    lseek(fd, s->refcount_block_offset, SEEK_SET);
-    ret = write(fd, s->refcount_block, s->cluster_size);
-    if (ret < 0)
-        goto out;
-    ret = 0;
-
-  out:
-    qemu_free(s->refcount_table);
-    qemu_free(s->refcount_block);
-    close(fd);
-    return ret;
-}
-
-
-
-struct tap_disk tapdisk_qcow2 = {
-	"qcow2",
-	sizeof(BDRVQcowState),
-	qcow_open,
-#ifdef USE_AIO
-	qcow_queue_read,
-	qcow_queue_write,
-#else
-	qcow_sync_read,
-	qcow_sync_write,
-#endif
-	qcow_submit,
-	qcow_close,
-	qcow_do_callbacks,
-	qcow_get_parent_id,
-	qcow_validate_parent
-};
diff --git a/tools/blktap/drivers/block-ram.c b/tools/blktap/drivers/block-ram.c
deleted file mode 100644
index 836a68e..0000000
--- a/tools/blktap/drivers/block-ram.c
+++ /dev/null
@@ -1,295 +0,0 @@
-/* block-ram.c
- *
- * Fast Ramdisk implementation.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- * 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 <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <inttypes.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include "tapdisk.h"
-#include "blk.h"
-
-#define MAX_DISK_SIZE 1024000 /*500MB disk limit*/
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-char *img;
-long int   disksector_size;
-long int   disksize;
-long int   diskinfo;
-static int connections = 0;
-
-struct tdram_state {
-        int fd;
-	int poll_pipe[2]; /* dummy fd for polling on */
-};
-
-/*Get Image size, secsize*/
-static int get_image_info(struct td_state *s, int fd)
-{
-	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
-	struct stat stat;
-
-	ret = fstat(fd, &stat);
-	if (ret != 0) {
-		DPRINTF("ERROR: fstat failed, Couldn't stat image");
-		return -EINVAL;
-	}
-
-	if (S_ISBLK(stat.st_mode)) {
-		/*Accessing block device directly*/
-		if (blk_getimagesize(fd, &s->size) != 0)
-			return -EINVAL;
-
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-
-		/*Get the sector size*/
-		if (blk_getsectorsize(fd, &s->sector_size) != 0)
-			s->sector_size = DEFAULT_SECTOR_SIZE;
-
-	} else {
-		/*Local file? try fstat instead*/
-		s->size = (stat.st_size >> SECTOR_SHIFT);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-	}
-
-	if (s->size == 0) {		
-		s->size =((uint64_t) MAX_DISK_SIZE);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-	}
-	s->info = 0;
-
-        /*Store variables locally*/
-	disksector_size = s->sector_size;
-	disksize        = s->size;
-	diskinfo        = s->info;
-	DPRINTF("Image sector_size: \n\t[%"PRIu64"]\n",
-		s->sector_size);
-
-	return 0;
-}
-
-static inline void init_fds(struct disk_driver *dd)
-{
-        int i;
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
-
-        for(i =0 ; i < MAX_IOFD; i++)
-		dd->io_fd[i] = 0;
-
-        dd->io_fd[0] = prv->poll_pipe[0];
-}
-
-/* Open the disk file and initialize ram state. */
-static int tdram_open (struct disk_driver *dd, const char *name, td_flag_t flags)
-{
-	char *p;
-	uint64_t size;
-	int i, fd, ret = 0, count = 0, o_flags;
-	struct td_state    *s     = dd->td_state;
-	struct tdram_state *prv   = (struct tdram_state *)dd->private;
-
-	connections++;
-	
-	/* set up a pipe so that we can hand back a poll fd that won't fire.*/
-	ret = pipe(prv->poll_pipe);
-	if (ret != 0)
-		return (0 - errno);
-
-	if (connections > 1) {
-		s->sector_size = disksector_size;
-		s->size        = disksize;
-		s->info        = diskinfo; 
-		DPRINTF("Image already open, returning parameters:\n");
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-		DPRINTF("Image sector_size: \n\t[%"PRIu64"]\n",
-			s->sector_size);
-
-		prv->fd = -1;
-		goto done;
-	}
-
-	/* Open the file */
-	o_flags = O_DIRECT | O_LARGEFILE | 
-		((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-        fd = open(name, o_flags);
-
-        if ((fd == -1) && (errno == EINVAL)) {
-
-                /* Maybe O_DIRECT isn't supported. */
-		o_flags &= ~O_DIRECT;
-                fd = open(name, o_flags);
-                if (fd != -1) DPRINTF("WARNING: Accessing image without"
-                                     "O_DIRECT! (%s)\n", name);
-
-        } else if (fd != -1) DPRINTF("open(%s) with O_DIRECT\n", name);
-	
-        if (fd == -1) {
-		DPRINTF("Unable to open [%s]!\n",name);
-        	ret = 0 - errno;
-        	goto done;
-        }
-
-        prv->fd = fd;
-
-	ret = get_image_info(s, fd);
-	size = MAX_DISK_SIZE;
-
-	if (s->size > size) {
-		DPRINTF("Disk exceeds limit, must be less than [%d]MB",
-			(MAX_DISK_SIZE<<SECTOR_SHIFT)>>20);
-		return -ENOMEM;
-	}
-
-	/*Read the image into memory*/
-	p = img = malloc(s->size << SECTOR_SHIFT);
-	if (img == NULL) {
-		DPRINTF("Mem malloc failed\n");
-		return -1;
-	}
-	DPRINTF("Reading %llu bytes.......",(long long unsigned)s->size << SECTOR_SHIFT);
-
-	for (i = 0; i < s->size; i++) {
-		ret = read(prv->fd, p, s->sector_size);
-		if (ret != s->sector_size) {
-			ret = 0 - errno;
-			break;
-		} else {
-			count += ret;
-			p = img + count;
-		}
-	}
-	DPRINTF("[%d]\n",count);
-	if (count != s->size << SECTOR_SHIFT) {
-		ret = -1;
-	} else {
-		ret = 0;
-	} 
-
-	init_fds(dd);
-done:
-	return ret;
-}
-
-static int tdram_queue_read(struct disk_driver *dd, uint64_t sector,
-		      int nb_sectors, char *buf, td_callback_t cb,
-		      int id, void *private)
-{
-	struct td_state    *s   = dd->td_state;
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-
-	memcpy(buf, img + offset, size);
-
-	return cb(dd, 0, sector, nb_sectors, id, private);
-}
-
-static int tdram_queue_write(struct disk_driver *dd, uint64_t sector,
-		      int nb_sectors, char *buf, td_callback_t cb,
-		      int id, void *private)
-{
-	struct td_state    *s   = dd->td_state;
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-	
-	/* We assume that write access is controlled
-	 * at a higher level for multiple disks */
-	memcpy(img + offset, buf, size);
-
-	return cb(dd, 0, sector, nb_sectors, id, private);
-}
- 		
-static int tdram_submit(struct disk_driver *dd)
-{
-	return 0;	
-}
-
-static int tdram_close(struct disk_driver *dd)
-{
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
-	
-	connections--;
-	
-	return 0;
-}
-
-static int tdram_do_callbacks(struct disk_driver *dd, int sid)
-{
-	/* always ask for a kick */
-	return 1;
-}
-
-static int tdram_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	return TD_NO_PARENT;
-}
-
-static int tdram_validate_parent(struct disk_driver *dd, 
-			  struct disk_driver *parent, td_flag_t flags)
-{
-	return -EINVAL;
-}
-
-struct tap_disk tapdisk_ram = {
-	.disk_type          = "tapdisk_ram",
-	.private_data_size  = sizeof(struct tdram_state),
-	.td_open            = tdram_open,
-	.td_queue_read      = tdram_queue_read,
-	.td_queue_write     = tdram_queue_write,
-	.td_submit          = tdram_submit,
-	.td_close           = tdram_close,
-	.td_do_callbacks    = tdram_do_callbacks,
-	.td_get_parent_id   = tdram_get_parent_id,
-	.td_validate_parent = tdram_validate_parent
-};
diff --git a/tools/blktap/drivers/block-sync.c b/tools/blktap/drivers/block-sync.c
deleted file mode 100644
index dde4538..0000000
--- a/tools/blktap/drivers/block-sync.c
+++ /dev/null
@@ -1,242 +0,0 @@
-/* block-sync.c
- *
- * simple slow synchronous raw disk implementation.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- * 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 <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include "tapdisk.h"
-#include "blk.h"
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-struct tdsync_state {
-	int fd;
-	int poll_pipe[2]; /* dummy fd for polling on */
-};
-	
-/*Get Image size, secsize*/
-static int get_image_info(struct td_state *s, int fd)
-{
-	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
-	struct stat stat;
-
-	ret = fstat(fd, &stat);
-	if (ret != 0) {
-		DPRINTF("ERROR: fstat failed, Couldn't stat image");
-		return -EINVAL;
-	}
-
-	if (S_ISBLK(stat.st_mode)) {
-		/*Accessing block device directly*/
-		if (blk_getimagesize(fd, &s->size) != 0)
-			return -EINVAL;
-
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-
-		/*Get the sector size*/
-		if (blk_getsectorsize(fd, &s->sector_size) != 0)
-			s->sector_size = DEFAULT_SECTOR_SIZE;
-
-	} else {
-		/*Local file? try fstat instead*/
-		s->size = (stat.st_size >> SECTOR_SHIFT);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-		DPRINTF("Image size: \n\tpre sector_shift  [%lluu]\n\tpost "
-			"sector_shift [%lluu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-	}
-
-	if (s->size == 0)
-		return -EINVAL;
-
-	s->info = 0;
-
-	return 0;
-}
-
-static inline void init_fds(struct disk_driver *dd)
-{
-	int i;
-	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
-	
-	for(i = 0; i < MAX_IOFD; i++)
-		dd->io_fd[i] = 0;
-
-	dd->io_fd[0] = prv->poll_pipe[0];
-}
-
-/* Open the disk file and initialize aio state. */
-static int tdsync_open (struct disk_driver *dd, const char *name, td_flag_t flags)
-{
-	int i, fd, ret = 0, o_flags;
-	struct td_state     *s   = dd->td_state;
-	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
-	
-	/* set up a pipe so that we can hand back a poll fd that won't fire.*/
-	ret = pipe(prv->poll_pipe);
-	if (ret != 0)
-		return (0 - errno);
-	
-	/* Open the file */
-	o_flags = O_DIRECT | O_LARGEFILE | 
-		((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-        fd = open(name, o_flags);
-
-        if ( (fd == -1) && (errno == EINVAL) ) {
-
-                /* Maybe O_DIRECT isn't supported. */
-		o_flags &= ~O_DIRECT;
-                fd = open(name, o_flags);
-                if (fd != -1) DPRINTF("WARNING: Accessing image without"
-                                     "O_DIRECT! (%s)\n", name);
-
-        } else if (fd != -1) DPRINTF("open(%s) with O_DIRECT\n", name);
-	
-        if (fd == -1) {
-		DPRINTF("Unable to open [%s]!\n",name);
-        	ret = 0 - errno;
-        	goto done;
-        }
-
-        prv->fd = fd;
-
-	init_fds(dd);
-	ret = get_image_info(s, fd);
-done:
-	return ret;	
-}
-
-static int tdsync_queue_read(struct disk_driver *dd, uint64_t sector,
-			       int nb_sectors, char *buf, td_callback_t cb,
-			       int id, void *private)
-{
-	struct td_state     *s   = dd->td_state;
-	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-	int ret;
-	
-	ret = lseek(prv->fd, offset, SEEK_SET);
-	if (ret != (off_t)-1) {
-		ret = read(prv->fd, buf, size);
-		if (ret != size) {
-			ret = 0 - errno;
-		} else {
-			ret = 1;
-		} 
-	} else ret = 0 - errno;
-		
-	return cb(dd, (ret < 0) ? ret: 0, sector, nb_sectors, id, private);
-}
-
-static int tdsync_queue_write(struct disk_driver *dd, uint64_t sector,
-			       int nb_sectors, char *buf, td_callback_t cb,
-			       int id, void *private)
-{
-	struct td_state     *s   = dd->td_state;
-	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-	int ret = 0;
-	
-	ret = lseek(prv->fd, offset, SEEK_SET);
-	if (ret != (off_t)-1) {
-		ret = write(prv->fd, buf, size);
-		if (ret != size) {
-			ret = 0 - errno;
-		} else {
-			ret = 1;
-		}
-	} else ret = 0 - errno;
-		
-	return cb(dd, (ret < 0) ? ret : 0, sector, nb_sectors, id, private);
-}
- 		
-static int tdsync_submit(struct disk_driver *dd)
-{
-	return 0;	
-}
-
-static int tdsync_close(struct disk_driver *dd)
-{
-	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
-	
-	close(prv->fd);
-	close(prv->poll_pipe[0]);
-	close(prv->poll_pipe[1]);
-	
-	return 0;
-}
-
-static int tdsync_do_callbacks(struct disk_driver *dd, int sid)
-{
-	/* always ask for a kick */
-	return 1;
-}
-
-static int tdsync_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	return TD_NO_PARENT;
-}
-
-static int tdsync_validate_parent(struct disk_driver *dd, 
-			   struct disk_driver *parent, td_flag_t flags)
-{
-	return -EINVAL;
-}
-
-struct tap_disk tapdisk_sync = {
-	.disk_type           = "tapdisk_sync",
-	.private_data_size   = sizeof(struct tdsync_state),
-	.td_open             = tdsync_open,
-	.td_queue_read       = tdsync_queue_read,
-	.td_queue_write      = tdsync_queue_write,
-	.td_submit           = tdsync_submit,
-	.td_close            = tdsync_close,
-	.td_do_callbacks     = tdsync_do_callbacks,
-	.td_get_parent_id    = tdsync_get_parent_id,
-	.td_validate_parent  = tdsync_validate_parent
-};
diff --git a/tools/blktap/drivers/block-vmdk.c b/tools/blktap/drivers/block-vmdk.c
deleted file mode 100644
index 4d16965..0000000
--- a/tools/blktap/drivers/block-vmdk.c
+++ /dev/null
@@ -1,428 +0,0 @@
-/* block-vmdk.c
- *
- * VMware Disk format implementation.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- * This is largely the same as the vmdk driver in Qemu, I've just twisted it
- * to match our interfaces.  The original (BSDish) Copyright message appears 
- * below:
- */
- 
-/*
- * Block driver for the VMDK format
- * 
- * Copyright (c) 2004 Fabrice Bellard
- * Copyright (c) 2005 Filip Navara
- * 
- * 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.
- */
-
-#include <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include "tapdisk.h"
-#include "bswap.h"
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-#define safer_free(_x)       \
-  do {                       \
-  	if (NULL != _x) {    \
-  		free(_x);    \
-  		(_x) = NULL; \
-  	}                    \
-  } while (0) ;
-
-#define VMDK3_MAGIC (('C' << 24) | ('O' << 16) | ('W' << 8) | 'D')
-#define VMDK4_MAGIC (('K' << 24) | ('D' << 16) | ('M' << 8) | 'V')
-
-typedef struct {
-    uint32_t version;
-    uint32_t flags;
-    uint32_t disk_sectors;
-    uint32_t granularity;
-    uint32_t l1dir_offset;
-    uint32_t l1dir_size;
-    uint32_t file_sectors;
-    uint32_t cylinders;
-    uint32_t heads;
-    uint32_t sectors_per_track;
-} VMDK3Header;
-
-typedef struct {
-    uint32_t version;
-    uint32_t flags;
-    int64_t capacity;
-    int64_t granularity;
-    int64_t desc_offset;
-    int64_t desc_size;
-    int32_t num_gtes_per_gte;
-    int64_t rgd_offset;
-    int64_t gd_offset;
-    int64_t grain_offset;
-    char filler[1];
-    char check_bytes[4];
-} __attribute__((packed)) VMDK4Header;
-
-#define L2_CACHE_SIZE 16
-
-struct tdvmdk_state {
-        int fd;
-	int poll_pipe[2]; /* dummy fd for polling on */
-	
-    	unsigned int l1_size;
-    	int64_t l1_table_offset;
-    	int64_t l1_backup_table_offset;
-    	uint32_t l1_entry_sectors;
-    	unsigned int l2_size;
-	
-    	uint32_t *l1_table;
-    	uint32_t *l1_backup_table;
-    	uint32_t *l2_cache;
-    	uint32_t l2_cache_offsets[L2_CACHE_SIZE];
-    	uint32_t l2_cache_counts[L2_CACHE_SIZE];
-    	
-    	unsigned int cluster_sectors;
-};
-
-static inline void init_fds(struct disk_driver *dd)
-{
-        int i;
-	struct tdvmdk_state *prv = (struct tdvmdk_state *)dd->private;
-
-        for (i = 0; i < MAX_IOFD; i++)
-		dd->io_fd[i] = 0;
-
-        dd->io_fd[0] = prv->poll_pipe[0];
-}
-
-/* Open the disk file and initialize aio state. */
-static int tdvmdk_open (struct disk_driver *dd, 
-			const char *name, td_flag_t flags)
-{
-	int ret, fd;
-    	int l1_size, i, o_flags;
-    	uint32_t magic;
-	struct td_state     *s   = dd->td_state;
-	struct tdvmdk_state *prv = (struct tdvmdk_state *)dd->private;
-
-	/* set up a pipe so that we can hand back a poll fd that won't fire.*/
-	ret = pipe(prv->poll_pipe);
-	if (ret != 0)
-		return -1;
-	
-	/* Open the file */
-	o_flags = O_DIRECT | O_LARGEFILE | 
-		((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-        fd = open(name, o_flags); 
-
-        if ( (fd == -1) && (errno == EINVAL) ) {
-
-                /* Maybe O_DIRECT isn't supported. */
-		o_flags &= ~O_DIRECT;
-                fd = open(name, o_flags);
-                if (fd != -1) DPRINTF("WARNING: Accessing image without"
-                                     "O_DIRECT! (%s)\n", name);
-
-        } else if (fd != -1) DPRINTF("open(%s) with O_DIRECT\n", name);
-	
-        if (fd == -1) {
-		DPRINTF("Unable to open [%s]!\n",name);
-        	ret = 0 - errno;
-        	return -1;
-        }
-        
-        prv->fd = fd;
-        
-        /* Grok the vmdk header. */
-    	if ((ret = read(fd, &magic, sizeof(magic))) != sizeof(magic))
-        	goto fail;
-    	magic = be32_to_cpu(magic);
-    	if (magic == VMDK3_MAGIC) {
-        	VMDK3Header header;
-        	if (read(fd, &header, sizeof(header)) != 
-            		sizeof(header)) 
-            		goto fail;
-        	prv->cluster_sectors = le32_to_cpu(header.granularity);
-        	prv->l2_size = 1 << 9;
-        	prv->l1_size = 1 << 6;
-        	s->size = le32_to_cpu(header.disk_sectors);
-        	prv->l1_table_offset = le32_to_cpu(header.l1dir_offset) << 9;
-        	prv->l1_backup_table_offset = 0;
-        	prv->l1_entry_sectors = prv->l2_size * prv->cluster_sectors;
-    	} else if (magic == VMDK4_MAGIC) {
-        	VMDK4Header header;
-        
-        	if (read(fd, &header, sizeof(header)) != sizeof(header))
-            		goto fail;
-        	s->size = le32_to_cpu(header.capacity);
-        	prv->cluster_sectors = le32_to_cpu(header.granularity);
-        	prv->l2_size = le32_to_cpu(header.num_gtes_per_gte);
-        	prv->l1_entry_sectors = prv->l2_size * prv->cluster_sectors;
-        	if (prv->l1_entry_sectors <= 0)
-            		goto fail;
-        	prv->l1_size = (s->size + prv->l1_entry_sectors - 1) 
-            		       / prv->l1_entry_sectors;
-        	prv->l1_table_offset = le64_to_cpu(header.rgd_offset) << 9;
-        	prv->l1_backup_table_offset = 
-        		le64_to_cpu(header.gd_offset) << 9;
-    	} else {
-        	goto fail;
-    	}
-    	/* read the L1 table */
-    	l1_size = prv->l1_size * sizeof(uint32_t);
-    	prv->l1_table = malloc(l1_size);
-    	if (!prv->l1_table)
-        	goto fail;
-    	if (lseek(fd, prv->l1_table_offset, SEEK_SET) == -1)
-        	goto fail;
-    	if (read(fd, prv->l1_table, l1_size) != l1_size)
-        	goto fail;
-    	for (i = 0; i < prv->l1_size; i++) {
-        	le32_to_cpus(&prv->l1_table[i]);
-    	}
-
-    	if (prv->l1_backup_table_offset) {
-        	prv->l1_backup_table = malloc(l1_size);
-        	if (!prv->l1_backup_table)
-            		goto fail;
-        	if (lseek(fd, prv->l1_backup_table_offset, SEEK_SET) == -1)
-            		goto fail;
-        	if (read(fd, prv->l1_backup_table, l1_size) != l1_size)
-            		goto fail;
-        	for(i = 0; i < prv->l1_size; i++) {
-            		le32_to_cpus(&prv->l1_backup_table[i]);
-        	}
-    	}
-
-    	prv->l2_cache = malloc(prv->l2_size * L2_CACHE_SIZE *sizeof(uint32_t));
-    	if (!prv->l2_cache)
-        	goto fail;
-    	prv->fd = fd;
-	init_fds(dd);
-	DPRINTF("VMDK File opened successfully\n");
-    	return 0;
-	
-fail:
-	DPRINTF("VMDK File open failed.\n"); 
-   	safer_free(prv->l1_backup_table);
-    	free(prv->l1_table);
-    	free(prv->l2_cache);
-    	close(fd);
-	return -1;
-}
-
-static uint64_t get_cluster_offset(struct tdvmdk_state *prv, 
-                                   uint64_t offset, int allocate)
-{
-    	unsigned int l1_index, l2_offset, l2_index;
-    	int min_index, i, j;
-    	uint32_t min_count, *l2_table, tmp;
-    	uint64_t cluster_offset;
-    
-    	l1_index = (offset >> 9) / prv->l1_entry_sectors;
-    	if (l1_index >= prv->l1_size)
-        	return 0;
-    	l2_offset = prv->l1_table[l1_index];
-    	if (!l2_offset)
-        	return 0;
-    	for (i = 0; i < L2_CACHE_SIZE; i++) {
-        	if (l2_offset == prv->l2_cache_offsets[i]) {
-            		/* increment the hit count */
-            		if (++prv->l2_cache_counts[i] == 0xffffffff) {
-	                	for(j = 0; j < L2_CACHE_SIZE; j++) {
-	                    		prv->l2_cache_counts[j] >>= 1;
-	                	}
-            		}
-            		l2_table = prv->l2_cache + (i * prv->l2_size);
-            		goto found;
-        	}
-    	}
-    	/* not found: load a new entry in the least used one */
-    	min_index = 0;
-    	min_count = 0xffffffff;
-    	for (i = 0; i < L2_CACHE_SIZE; i++) {
-        	if (prv->l2_cache_counts[i] < min_count) {
-            		min_count = prv->l2_cache_counts[i];
-            		min_index = i;
-        	}
-    	}
-    	l2_table = prv->l2_cache + (min_index * prv->l2_size);
-    	lseek(prv->fd, (int64_t)l2_offset * 512, SEEK_SET);
-    	if (read(prv->fd, l2_table, prv->l2_size * sizeof(uint32_t)) != 
-        	 prv->l2_size * sizeof(uint32_t))
-        	return 0;
-    	prv->l2_cache_offsets[min_index] = l2_offset;
-    	prv->l2_cache_counts[min_index] = 1;
- found:
-    	l2_index = ((offset >> 9) / prv->cluster_sectors) % prv->l2_size;
-    	cluster_offset = le32_to_cpu(l2_table[l2_index]);
-    	if (!cluster_offset) {
-        	if (!allocate)
-            		return 0;
-        	cluster_offset = lseek(prv->fd, 0, SEEK_END);
-        	if (ftruncate(prv->fd, cluster_offset + 
-			      (prv->cluster_sectors << 9)))
-			return 0;
-        	cluster_offset >>= 9;
-        	/* update L2 table */
-        	tmp = cpu_to_le32(cluster_offset);
-        	l2_table[l2_index] = tmp;
-        	lseek(prv->fd, ((int64_t)l2_offset * 512) + 
-        	      (l2_index * sizeof(tmp)), SEEK_SET);
-        	if (write(prv->fd, &tmp, sizeof(tmp)) != sizeof(tmp))
-            		return 0;
-        	/* update backup L2 table */
-        	if (prv->l1_backup_table_offset != 0) {
-            		l2_offset = prv->l1_backup_table[l1_index];
-            	lseek(prv->fd, ((int64_t)l2_offset * 512) + 
-            		(l2_index * sizeof(tmp)), SEEK_SET);
-            	if (write(prv->fd, &tmp, sizeof(tmp)) != sizeof(tmp))
-                	return 0;
-        	}
-    	}
-    	cluster_offset <<= 9;
-    	return cluster_offset;
-}
-
-static int tdvmdk_queue_read(struct disk_driver *dd, uint64_t sector,
-			       int nb_sectors, char *buf, td_callback_t cb,
-			       int id, void *private)
-{
-	struct tdvmdk_state *prv = (struct tdvmdk_state *)dd->private;
-    	int index_in_cluster, n;
-    	uint64_t cluster_offset;
-    	int ret = 0;
-
-    	while (nb_sectors > 0) {
-        	cluster_offset = get_cluster_offset(prv, sector << 9, 0);
-        	index_in_cluster = sector % prv->cluster_sectors;
-        	n = prv->cluster_sectors - index_in_cluster;
-        	if (n > nb_sectors)
-            		n = nb_sectors;
-        	if (!cluster_offset) {
-            		memset(buf, 0, 512 * n);
-        	} else {
-            		lseek(prv->fd, cluster_offset + index_in_cluster * 512,
-            	      	      SEEK_SET);
-            		ret = read(prv->fd, buf, n * 512);
-            		if (ret != n * 512) {
-                		ret = -1;
-                		goto done;
-            		}
-        	}
-        	nb_sectors -= n;
-        	sector     += n;
-        	buf += n * 512;
-    	}
-done:
-	return cb(dd, ret == -1 ? -1 : 0, sector, nb_sectors, id, private);
-}
-
-static  int tdvmdk_queue_write(struct disk_driver *dd, uint64_t sector,
-			       int nb_sectors, char *buf, td_callback_t cb,
-			       int id, void *private)
-{
-	struct tdvmdk_state *prv = (struct tdvmdk_state *)dd->private;
-    	int index_in_cluster, n;
-    	uint64_t cluster_offset;
-    	int ret = 0;
-
-    	while (nb_sectors > 0) {
-        	index_in_cluster = sector & (prv->cluster_sectors - 1);
-        	n = prv->cluster_sectors - index_in_cluster;
-        	if (n > nb_sectors)
-            		n = nb_sectors;
-        	cluster_offset = get_cluster_offset(prv, sector << 9, 1);
-        	if (!cluster_offset) {
-            		ret = -1;
-            		goto done;
-        	}
-        	lseek(prv->fd, cluster_offset + index_in_cluster * 512, 
-        	      SEEK_SET);
-        	ret = write(prv->fd, buf, n * 512);
-        	if (ret != n * 512) {
-            		ret = -1;
-            		goto done;
-        	}
-        	nb_sectors -= n;
-        	sector     += n;
-        	buf += n * 512;
-    	}
-done:
-	return cb(dd, ret == -1 ? -1 : 0, sector, nb_sectors, id, private);
-}
- 		
-static int tdvmdk_submit(struct disk_driver *dd)
-{
-	return 0;	
-}
-
-static int tdvmdk_close(struct disk_driver *dd)
-{
-	struct tdvmdk_state *prv = (struct tdvmdk_state *)dd->private;
-	
-    	safer_free(prv->l1_table);
-    	safer_free(prv->l1_backup_table);
-    	safer_free(prv->l2_cache);
-    	close(prv->fd);
-	close(prv->poll_pipe[0]);
-	close(prv->poll_pipe[1]);
-	return 0;
-}
-
-static int tdvmdk_do_callbacks(struct disk_driver *dd, int sid)
-{
-	/* always ask for a kick */
-	return 1;
-}
-
-static int tdvmdk_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	return TD_NO_PARENT;
-}
-
-static int tdvmdk_validate_parent(struct disk_driver *dd, 
-				  struct disk_driver *parent, td_flag_t flags)
-{
-	return -EINVAL;
-}
-
-struct tap_disk tapdisk_vmdk = {
-	.disk_type           = "tapdisk_vmdk",
-	.private_data_size   = sizeof(struct tdvmdk_state),
-	.td_open             = tdvmdk_open,
-	.td_queue_read       = tdvmdk_queue_read,
-	.td_queue_write      = tdvmdk_queue_write,
-	.td_submit           = tdvmdk_submit,
-	.td_close            = tdvmdk_close,
-	.td_do_callbacks     = tdvmdk_do_callbacks,
-	.td_get_parent_id    = tdvmdk_get_parent_id,
-	.td_validate_parent  = tdvmdk_validate_parent
-};
diff --git a/tools/blktap/drivers/bswap.h b/tools/blktap/drivers/bswap.h
deleted file mode 100644
index 5578913..0000000
--- a/tools/blktap/drivers/bswap.h
+++ /dev/null
@@ -1,178 +0,0 @@
-#ifndef BSWAP_H
-#define BSWAP_H
-
-//#include "config-host.h"
-
-#include <inttypes.h>
-
-#if defined(__NetBSD__)
-#include <sys/endian.h>
-#include <sys/types.h>
-#elif defined(__OpenBSD__)
-#include <machine/endian.h>
-#define bswap_16(x) swap16(x)
-#define bswap_32(x) swap32(x)
-#define bswap_64(x) swap64(x)
-#elif defined(__linux__)
-
-#include <byteswap.h>
-
-static inline uint16_t bswap16(uint16_t x)
-{
-    return bswap_16(x);
-}
-
-static inline uint32_t bswap32(uint32_t x) 
-{
-    return bswap_32(x);
-}
-
-static inline uint64_t bswap64(uint64_t x) 
-{
-    return bswap_64(x);
-}
-
-static inline void bswap16s(uint16_t *s)
-{
-    *s = bswap16(*s);
-}
-
-static inline void bswap32s(uint32_t *s)
-{
-    *s = bswap32(*s);
-}
-
-static inline void bswap64s(uint64_t *s)
-{
-    *s = bswap64(*s);
-}
-
-#endif
-
-#if defined(WORDS_BIGENDIAN)
-#define be_bswap(v, size) (v)
-#define le_bswap(v, size) bswap ## size(v)
-#define be_bswaps(v, size)
-#define le_bswaps(p, size) *p = bswap ## size(*p);
-#else
-#define le_bswap(v, size) (v)
-#define be_bswap(v, size) bswap ## size(v)
-#define le_bswaps(v, size)
-#define be_bswaps(p, size) *p = bswap ## size(*p);
-#endif
-
-#define CPU_CONVERT(endian, size, type)\
-static inline type endian ## size ## _to_cpu(type v)\
-{\
-    return endian ## _bswap(v, size);\
-}\
-\
-static inline type cpu_to_ ## endian ## size(type v)\
-{\
-    return endian ## _bswap(v, size);\
-}\
-\
-static inline void endian ## size ## _to_cpus(type *p)\
-{\
-    endian ## _bswaps(p, size)\
-}\
-\
-static inline void cpu_to_ ## endian ## size ## s(type *p)\
-{\
-    endian ## _bswaps(p, size)\
-}\
-\
-static inline type endian ## size ## _to_cpup(const type *p)\
-{\
-    return endian ## size ## _to_cpu(*p);\
-}\
-\
-static inline void cpu_to_ ## endian ## size ## w(type *p, type v)\
-{\
-     *p = cpu_to_ ## endian ## size(v);\
-}
-
-CPU_CONVERT(be, 16, uint16_t)
-CPU_CONVERT(be, 32, uint32_t)
-CPU_CONVERT(be, 64, uint64_t)
-
-CPU_CONVERT(le, 16, uint16_t)
-CPU_CONVERT(le, 32, uint32_t)
-CPU_CONVERT(le, 64, uint64_t)
-
-/* unaligned versions (optimized for frequent unaligned accesses)*/
-
-#if defined(__i386__) || defined(__powerpc__)
-
-#define cpu_to_le16wu(p, v) cpu_to_le16w(p, v)
-#define cpu_to_le32wu(p, v) cpu_to_le32w(p, v)
-#define le16_to_cpupu(p) le16_to_cpup(p)
-#define le32_to_cpupu(p) le32_to_cpup(p)
-
-#define cpu_to_be16wu(p, v) cpu_to_be16w(p, v)
-#define cpu_to_be32wu(p, v) cpu_to_be32w(p, v)
-
-#else
-
-static inline void cpu_to_le16wu(uint16_t *p, uint16_t v)
-{
-    uint8_t *p1 = (uint8_t *)p;
-
-    p1[0] = v;
-    p1[1] = v >> 8;
-}
-
-static inline void cpu_to_le32wu(uint32_t *p, uint32_t v)
-{
-    uint8_t *p1 = (uint8_t *)p;
-
-    p1[0] = v;
-    p1[1] = v >> 8;
-    p1[2] = v >> 16;
-    p1[3] = v >> 24;
-}
-
-static inline uint16_t le16_to_cpupu(const uint16_t *p)
-{
-    const uint8_t *p1 = (const uint8_t *)p;
-    return p1[0] | (p1[1] << 8);
-}
-
-static inline uint32_t le32_to_cpupu(const uint32_t *p)
-{
-    const uint8_t *p1 = (const uint8_t *)p;
-    return p1[0] | (p1[1] << 8) | (p1[2] << 16) | (p1[3] << 24);
-}
-
-static inline void cpu_to_be16wu(uint16_t *p, uint16_t v)
-{
-    uint8_t *p1 = (uint8_t *)p;
-
-    p1[0] = v >> 8;
-    p1[1] = v;
-}
-
-static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
-{
-    uint8_t *p1 = (uint8_t *)p;
-
-    p1[0] = v >> 24;
-    p1[1] = v >> 16;
-    p1[2] = v >> 8;
-    p1[3] = v;
-}
-
-#endif
-
-#ifdef WORDS_BIGENDIAN
-#define cpu_to_32wu cpu_to_be32wu
-#else
-#define cpu_to_32wu cpu_to_le32wu
-#endif
-
-#undef le_bswap
-#undef be_bswap
-#undef le_bswaps
-#undef be_bswaps
-
-#endif /* BSWAP_H */
diff --git a/tools/blktap/drivers/img2qcow.c b/tools/blktap/drivers/img2qcow.c
deleted file mode 100644
index 6b4fa70..0000000
--- a/tools/blktap/drivers/img2qcow.c
+++ /dev/null
@@ -1,282 +0,0 @@
-/* img2qcow.c
- *
- * Generates a qcow format disk and fills it from an existing image.
- *
- * (c) 2006 Julian Chesterfield and Andrew Warfield
- *
- * 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 <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include "tapdisk.h"
-#include "blk.h"
-
-#if 1
-#define DFPRINTF(_f, _a...) fprintf ( stderr, _f , ## _a )
-#else
-#define DFPRINTF(_f, _a...) ((void)0)
-#endif
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-
-#define TAPDISK 1
-#define BLOCK_PROCESSSZ 4096
-
-static int maxfds, *io_fd, running = 1, complete = 0;
-static int returned_events = 0, submit_events = 0;
-static uint64_t prev = 0;
-static char output[25];
-
-static void print_bytes(void *ptr, int length)
-{
-  int i,k;
-  unsigned char *p = ptr;
-
-    DFPRINTF("Buf dump, length %d:\n",length);
-    for (k = 0; k < length; k++) {
-        DFPRINTF("%x",*p);
-        *p++;
-	if(k % 16 == 0) DFPRINTF("\n");
-        else if(k % 2 == 0) DFPRINTF(" ");	
-    }
-    DFPRINTF("\n");
-    return;
-}
-
-static void debug_output(uint64_t progress, uint64_t size)
-{
-	uint64_t blocks = size/20;
-
-	/*Output progress every 5% */	
-	if (progress/blocks > prev) {
-		memcpy(output+prev+1,"=>",2);
-		prev++;
-		DFPRINTF("\r%s     %llu%%", output, 
-			(long long)(prev-1)*5);
-	}
-	return;
-}
-
-static inline void LOCAL_FD_SET(fd_set *readfds) 
-{
-	FD_SET(io_fd[0], readfds);
-	maxfds = io_fd[0] + 1;
-	
-	return;
-}
-
-static int get_image_info(struct td_state *s, int fd)
-{
-	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
-	struct stat stat;
-
-	ret = fstat(fd, &stat);
-	if (ret != 0) {
-		DFPRINTF("ERROR: fstat failed, Couldn't stat image");
-		return -EINVAL;
-	}
-
-	if (S_ISBLK(stat.st_mode)) {
-		/*Accessing block device directly*/
-		if (blk_getimagesize(fd, &s->size) != 0)
-			return -EINVAL;
-
-		DFPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-
-		/*Get the sector size*/
-		if (blk_getsectorsize(fd, &s->sector_size) != 0)
-			s->sector_size = DEFAULT_SECTOR_SIZE;
-
-	} else {
-		/*Local file? try fstat instead*/
-		s->size = (stat.st_size >> SECTOR_SHIFT);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-		DFPRINTF("Image size: [%llu]\n",
-			(long long unsigned)s->size);
-	}
-
-	return 0;
-}
-
-static int send_responses(struct disk_driver *dd, int res, uint64_t sec, 
-			  int nr_secs, int idx, void *private)
-{
-	if (res < 0) DFPRINTF("AIO FAILURE: res [%d]!\n",res);
-	
-	returned_events++;
-	
-	free(private);
-	return 0;
-}
-
-int main(int argc, char *argv[])
-{
-	struct disk_driver dd;
-	struct td_state *s;
-	int ret = -1, fd, len;
-	fd_set readfds;
-	struct timeval timeout;
-	uint64_t i;
-	char *buf;
-
-	if (argc != 3) {
-		fprintf(stderr, "Qcow-utils: v1.0.0\n");
-		fprintf(stderr, "usage: %s <QCOW FILENAME> <SRC IMAGE>\n", 
-			argv[0]);
-		exit(-1);
-	}
-
-	s = malloc(sizeof(struct td_state));
-	
-	/*Open image*/
-	fd = open(argv[2], O_RDONLY | O_LARGEFILE);
-	
-        if (fd == -1) {
-                DFPRINTF("Unable to open [%s], (err %d)!\n",argv[2],0 - errno);
-                exit(-1);
-        }
-	
-	get_image_info(s, fd);
-	
-	/*Create qcow file*/
-	ret = qcow_create(argv[1],s->size<<SECTOR_SHIFT,NULL,0);
-	
-	if (ret < 0) {
-		DFPRINTF("Unable to create QCOW file\n");
-		exit(-1);
-	} else DFPRINTF("Qcow file created: size %llu sectors\n",
-			(long long unsigned)s->size);
-	
-	dd.td_state = s;
-	dd.drv      = &tapdisk_qcow;
-	dd.private  = malloc(dd.drv->private_data_size);
-
-        /*Open qcow file*/
-        if (dd.drv->td_open(&dd, argv[1], 0)!=0) {
-		DFPRINTF("Unable to open Qcow file [%s]\n",argv[1]);
-		exit(-1);
-	}
-
-	io_fd = dd.io_fd;
-
-	/*Initialise the output string*/
-	memset(output,0x20,25);
-	output[0] = '[';
-	output[22] = ']';
-	output[23] = '\0';
-	DFPRINTF("%s",output);
-
-	i = 0;
-	while (running) {
-		timeout.tv_sec = 0;
-		
-		if (!complete) {
-			/*Read sector from image*/
-			if (lseek(fd, i, SEEK_SET) == (off_t)-1) {
-				DFPRINTF("Unable to access file offset %llu\n",
-				       (long long)i);
-				exit(-1);
-			}
-			
-			if( (ret = posix_memalign((void **)&buf, 
-						  BLOCK_PROCESSSZ, 
-						  BLOCK_PROCESSSZ)) != 0) {
-				DFPRINTF("Unable to read memalign buf (%d)\n",ret);
-				exit(-1);				
-			}
-		
-			/*We attempt to read 4k sized blocks*/
-			len = read(fd, buf, BLOCK_PROCESSSZ);
-			if (len < 512) {
-				DFPRINTF("Unable to read sector %llu\n",
-				       (long long unsigned) (i >> 9));
-				complete = 1;
-				continue;
-			}
-			
-			if (len % 512) {
-				len = (len >> 9) << 9;
-			}
-
-			ret = dd.drv->td_queue_write(&dd, i >> 9,
-						     len >> 9, buf, 
-						     send_responses, 0, buf);
-				
-			if (!ret) submit_events++;
-				
-			if (ret < 0) {
-				DFPRINTF("UNABLE TO WRITE block [%llu]\n",
-				       (long long unsigned) (i >> 9));
-			} else i += len;
-			
-			if (i >> 9 == s->size) complete = 1;
-
-			debug_output(i,s->size << 9);
-			
-			if ((submit_events % 10 == 0) || complete) 
-				dd.drv->td_submit(&dd);
-			timeout.tv_usec = 0;
-			
-		} else {
-			timeout.tv_usec = 1000;
-			if (!submit_events) running = 0;
-		}
-		
-
-		/*Check AIO FD*/
-		LOCAL_FD_SET(&readfds);
-                ret = select(maxfds + 1, &readfds, (fd_set *) 0,
-                             (fd_set *) 0, &timeout);
-			     
-		if (ret > 0) dd.drv->td_do_callbacks(&dd, 0);
-		if (complete && (returned_events == submit_events)) 
-			running = 0;
-	}
-	memcpy(output+prev+1,"=",1);
-	DFPRINTF("\r%s     100%%\nTRANSFER COMPLETE\n\n", output);
-        dd.drv->td_close(&dd);
-        free(dd.private);
-        free(s);
-		
-	return 0;
-}
diff --git a/tools/blktap/drivers/qcow-create.c b/tools/blktap/drivers/qcow-create.c
deleted file mode 100644
index 25abfcd..0000000
--- a/tools/blktap/drivers/qcow-create.c
+++ /dev/null
@@ -1,130 +0,0 @@
-/* qcow-create.c
- *
- * Generates a qcow format disk.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- * 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 <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include "tapdisk.h"
-
-#if 1
-#define DFPRINTF(_f, _a...) fprintf ( stderr, _f , ## _a )
-#else
-#define DFPRINTF(_f, _a...) ((void)0)
-#endif
-
-#define MAX_NAME_LEN 1000
-
-static void help(void)
-{
-	fprintf(stderr, "Qcow-utils: v1.0.0\n");
-	fprintf(stderr, 
-		"usage: qcow-create [-h help] [-r reserve] [-f format] <SIZE(MB)> <FILENAME> "
-		"[<BACKING_FILENAME>]\n"); 
-	exit(-1);
-}
-
-int main(int argc, char *argv[])
-{
-	int ret = -1, c, backed = 0;
-	int sparse =  1;
-	char *fmt = "qcow";
-	uint64_t size;
-	char filename[MAX_NAME_LEN], bfilename[MAX_NAME_LEN];
-	char *tmpfile;
-
-        for(;;) {
-                c = getopt(argc, argv, "hrf");
-                if (c == -1)
-                        break;
-                switch(c) {
-                case 'h':
-                        help();
-                        exit(0);
-                        break;
-                case 'f':
-                        fmt = argv[optind++];
-                        break;
-                case 'r':
-			sparse = 0;
-			break;
-		default:
-			fprintf(stderr, "Unknown option\n");
-			help();
-		}
-	}
-
-	printf("Optind %d, argc %d\n", optind, argc);
-	if ( !(optind == (argc - 2) || optind == (argc - 3)) )
-		help();
-
-	size = atoi(argv[optind++]);
-	size = size << 20;
-
-	if (snprintf(filename, MAX_NAME_LEN, "%s",argv[optind++]) >=
-		MAX_NAME_LEN) {
-		fprintf(stderr,"Device name too long\n");
-		exit(-1);
-	}
-
-	if (optind != argc) {
-		/*Backing file argument*/
-		backed = 1;
-		if (snprintf(bfilename, MAX_NAME_LEN, "%s",argv[optind++]) >=
-			MAX_NAME_LEN) {
-			fprintf(stderr,"Device name too long\n");
-			exit(-1);
-		}
-	}
-
-    tmpfile = backed ? bfilename: NULL; 
-    if (!strcmp(fmt, "qcow")) {
-        ret = qcow_create(filename, size, tmpfile, sparse);
-    } else if(!strcmp(fmt, "qcow2")) {
-        ret = qcow2_create(filename, size, tmpfile, sparse);
-    } else {
-        fprintf(stderr,"Unsupport format:%s\n", fmt);
-        exit(-1);
-    } 
-    DFPRINTF("Creating file size %llu, name %s\n",(long long unsigned)size, filename);
-
-	if (ret < 0)
-		DPRINTF("Unable to create QCOW file\n");
-	else
-		DPRINTF("QCOW file successfully created\n");
-
-	return 0;
-}
diff --git a/tools/blktap/drivers/qcow2raw.c b/tools/blktap/drivers/qcow2raw.c
deleted file mode 100644
index 0fa88c1..0000000
--- a/tools/blktap/drivers/qcow2raw.c
+++ /dev/null
@@ -1,348 +0,0 @@
-/* qcow2raw.c
- *
- * Generates raw image data from an existing qcow image
- *
- * (c) 2006 Julian Chesterfield and Andrew Warfield
- *
- * 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 <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <inttypes.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include "tapdisk.h"
-#include "blk.h"
-
-#if 1
-#define DFPRINTF(_f, _a...) fprintf ( stderr, _f , ## _a )
-#else
-#define DFPRINTF(_f, _a...) ((void)0)
-#endif
-
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE 0
-#endif
-
-#define TAPDISK 1
-#define BLOCK_PROCESSSZ 4096
-
-static int maxfds, *qcowio_fd, *aio_fd, running = 1, complete = 0; 
-static int returned_read_events = 0, returned_write_events = 0;
-static int submit_events = 0;
-static uint32_t read_idx = 0, write_idx = 0;
-struct disk_driver ddqcow, ddaio;
-static uint64_t prev = 0, written = 0;
-static char output[25];
-
-static void print_bytes(void *ptr, int length)
-{
-  int i,k;
-  unsigned char *p = ptr;
-
-    DFPRINTF("Buf dump, length %d:\n",length);
-    for (k = 0; k < length; k++) {
-        DFPRINTF("%x",*p);
-        *p++;
-	if (k % 16 == 0) DFPRINTF("\n");
-        else if (k % 2 == 0) DFPRINTF(" ");	
-    }
-    DFPRINTF("\n");
-    return;
-}
-
-static void debug_output(uint64_t progress, uint64_t size)
-{
-	/*Output progress every 5% */	
-	uint64_t blocks = size/20;
-
-	if (progress/blocks > prev) {
-		memcpy(output+prev+1,"=>",2);
-		prev++;
-		DFPRINTF("\r%s     %llu%%", 
-			output, (long long)((prev-1)*5));
-	}
-	return;
-}
-
-static inline void LOCAL_FD_SET(fd_set *readfds) 
-{
-	FD_SET(qcowio_fd[0], readfds);
-	FD_SET(aio_fd[0], readfds);
-	
-	maxfds = (qcowio_fd[0] > aio_fd[0] ? qcowio_fd[0] : aio_fd[0]) + 1;
-	
-	return;
-}
-
-static int send_write_responses(struct disk_driver *dd, int res, uint64_t sec,
-				int nr_secs, int idx, void *private)
-{
-	if (res < 0) {
-		DFPRINTF("AIO FAILURE: res [%d]!\n",res);
-		return 0;
-	}
-	written += BLOCK_PROCESSSZ;
-	returned_write_events++;
-	write_idx = idx;
-
-	debug_output(written, dd->td_state->size << 9);
-	free(private);
-	return 0;
-}
-
-static int send_read_responses(struct disk_driver *dd, int res, uint64_t sec,
-			       int nr_secs, int idx, void *private)
-{
-	int ret;
-
-	if (res < 0) DFPRINTF("AIO FAILURE: res [%d]!\n",res);
-	
-	returned_read_events++;
-	read_idx = idx;
-	
-	ret = ddaio.drv->td_queue_write(&ddaio, idx, BLOCK_PROCESSSZ>>9, private, 
-					send_write_responses, idx, private);
-	if (ret != 0) {
-		DFPRINTF("ERROR in submitting queue write!\n");
-		return 0;
-	}
-
-	if ( (returned_read_events == submit_events) || 
-	     (returned_read_events % 10 == 0) ) {
-		ddaio.drv->td_submit(&ddaio);
-	}
-
-	return 0;
-}
-
-int main(int argc, char *argv[])
-{
-	int ret = -1, fd, len,input;
-	uint64_t size;
-	fd_set readfds;
-	struct timeval timeout;
-	uint64_t i;
-	char *buf;
-	struct stat finfo;
-
-	if (argc != 3) {
-		fprintf(stderr, "Qcow-utils: v1.0.0\n");
-		fprintf(stderr, "usage: %s <Dest File descriptor> "
-			"<Qcow SRC IMAGE>\n", 
-		       argv[0]);
-		exit(-1);
-	}
-
-	ddqcow.td_state = malloc(sizeof(struct td_state));
-	ddaio.td_state  = malloc(sizeof(struct td_state));
-	
-	/*Open qcow source file*/	
-	ddqcow.drv = &tapdisk_qcow;
-	ddqcow.private = malloc(ddqcow.drv->private_data_size);
-
-        if (ddqcow.drv->td_open(&ddqcow, argv[2], TD_RDONLY)!=0) {
-		DFPRINTF("Unable to open Qcow file [%s]\n",argv[2]);
-		exit(-1);
-	} else DFPRINTF("QCOW file opened, size %llu\n",
-		      (long long unsigned)ddqcow.td_state->size);
-
-	qcowio_fd = ddqcow.io_fd;
-
-        /*Setup aio destination file*/
-	ret = stat(argv[1],&finfo);
-	if (ret == -1) {
-		/*Check errno*/
-		switch(errno) {
-		case ENOENT:
-			/*File doesn't exist, create*/
-			fd = open(argv[1], 
-				  O_RDWR | O_LARGEFILE | O_CREAT, 0644);
-			if (fd < 0) {
-				DFPRINTF("ERROR creating file [%s] "
-					 "(errno %d)\n",
-				       argv[1], 0 - errno);
-				exit(-1);
-			}
-			if (ftruncate(fd, (off_t)ddqcow.td_state->size<<9) < 0) {
-				DFPRINTF("Unable to create file "
-					"[%s] of size %llu (errno %d). "
-					 "Exiting...\n",
-					argv[1], 
-					(long long unsigned)ddqcow.td_state->size<<9, 
-					0 - errno);
-				close(fd);
-				exit(-1);
-			}
-			close(fd);
-			break;
-		case  ENXIO:
-			DFPRINTF("ERROR Device [%s] does not exist\n",argv[1]);
-			exit(-1);
-		default: 
-			DFPRINTF("An error occurred opening Device [%s] "
-				 "(errno %d)\n",
-			       argv[1], 0 - errno);
-			exit(-1);
-		}
-	} else {		
-		fprintf(stderr, "WARNING: All existing data in "
-			"%s will be overwritten.\nDo you wish to continue? "
-			"(y or n)  ",
-			argv[1]);
-		if (getchar() != 'y') {
-			DFPRINTF("Exiting...\n");
-			exit(-1);
-		}
-		
-		/*TODO - Test the existing file or device for adequate space*/
-		fd = open(argv[1], O_RDWR | O_LARGEFILE);
-		if (fd < 0) {
-			DFPRINTF("ERROR: opening file [%s] (errno %d)\n",
-			       argv[1], 0 - errno);
-			exit(-1);
-		}
-
-		if (S_ISBLK(finfo.st_mode)) {
-			if (blk_getimagesize(fd, &size) != 0) {
-				close(fd);
-				return -1;
-			}
-
-			if (size < ddqcow.td_state->size<<9) {
-				DFPRINTF("ERROR: Not enough space on device "
-					"%s (%"PRIu64" bytes available, "
-					"%llu bytes required\n",
-					argv[1], size, 
-					(long long unsigned)ddqcow.td_state->size<<9);
-				close(fd);
-				exit(-1);				
-			}
-		} else {
-			if (ftruncate(fd, (off_t)ddqcow.td_state->size<<9) < 0) {
-				DFPRINTF("Unable to create file "
-					"[%s] of size %llu (errno %d). "
-					 "Exiting...\n",
-					argv[1], 
-					(long long unsigned)ddqcow.td_state->size<<9, 
-					 0 - errno);
-				close(fd);
-				exit(-1);
-			} else DFPRINTF("File [%s] truncated to length %llu "
-					"(%llu)\n", 
-				       argv[1], 
-				       (long long unsigned)ddqcow.td_state->size<<9, 
-				       (long long unsigned)ddqcow.td_state->size);
-		}
-		close(fd);
-	}
-
-	/*Open aio destination file*/	
-	ddaio.drv = &tapdisk_aio;
-	ddaio.private = malloc(ddaio.drv->private_data_size);
-
-        if (ddaio.drv->td_open(&ddaio, argv[1], 0)!=0) {
-		DFPRINTF("Unable to open Qcow file [%s]\n", argv[1]);
-		exit(-1);
-	}
-
-	aio_fd = ddaio.io_fd;
-
-	/*Initialise the output string*/
-	memset(output,0x20,25);
-	output[0] = '[';
-	output[22] = ']';
-	output[23] = '\0';
-	DFPRINTF("%s",output);
-
-	i = 0;
-	while (running) {
-		timeout.tv_sec = 0;
-		
-		if (!complete) {
-			/*Read Pages from qcow image*/
-			if ( (ret = posix_memalign((void **)&buf, 
-						   BLOCK_PROCESSSZ, 
-						   BLOCK_PROCESSSZ))
-			     != 0) {
-				DFPRINTF("Unable to alloc memory (%d)\n",ret);
-				exit(-1);				
-			}
-		
-			/*Attempt to read 4k sized blocks*/
-			submit_events++;
-			ret = ddqcow.drv->td_queue_read(&ddqcow, i>>9,
-							BLOCK_PROCESSSZ>>9, buf, 
-							send_read_responses, i>>9, buf);
-
-			if (ret < 0) {
-				DFPRINTF("UNABLE TO READ block [%llu]\n",
-				       (long long unsigned)i);
-				exit(-1);
-			} else {
-				i += BLOCK_PROCESSSZ;
-			}
-
-			if (i >= ddqcow.td_state->size<<9) {
-				complete = 1;
-			}
-			
-			if ((submit_events % 10 == 0) || complete) 
-				ddqcow.drv->td_submit(&ddqcow);
-			timeout.tv_usec = 0;
-			
-		} else {
-			timeout.tv_usec = 1000;
-			if (!submit_events) running = 0;
-		}
-		
-
-		/*Check AIO FD*/
-		LOCAL_FD_SET(&readfds);
-                ret = select(maxfds + 1, &readfds, (fd_set *) 0,
-                             (fd_set *) 0, &timeout);
-			     
-		if (ret > 0) {
-			if (FD_ISSET(qcowio_fd[0], &readfds)) 
-				ddqcow.drv->td_do_callbacks(&ddqcow, 0);
-			if (FD_ISSET(aio_fd[0], &readfds)) 
-				ddaio.drv->td_do_callbacks(&ddaio, 0);
-		}
-		if (complete && (returned_write_events == submit_events)) 
-			running = 0;
-	}
-	memcpy(output+prev+1,"=",1);
-	DFPRINTF("\r%s     100%%\nTRANSFER COMPLETE\n\n", output);
-		
-	return 0;
-}
diff --git a/tools/blktap/drivers/tapaio.c b/tools/blktap/drivers/tapaio.c
deleted file mode 100644
index 140c44a..0000000
--- a/tools/blktap/drivers/tapaio.c
+++ /dev/null
@@ -1,357 +0,0 @@
-/*
- * Copyright (c) 2006 Andrew Warfield and Julian Chesterfield
- * Copyright (c) 2007 Red Hat, 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; 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 "tapaio.h"
-#include "tapdisk.h"
-#include <unistd.h>
-#include <errno.h>
-#include <string.h>
-#include <stdlib.h>
-
-/**
- * We used a kernel patch to return an fd associated with the AIO context
- * so that we can concurrently poll on synchronous and async descriptors.
- * This is signalled by passing 1 as the io context to io_setup.
- */
-#define REQUEST_ASYNC_FD 1
-
-/*
- * If we don't have any way to do epoll on aio events in a normal kernel,
- * wait for aio events in a separate thread and return completion status
- * that via a pipe that can be waited on normally.
- *
- * To keep locking problems between the completion thread and the submit
- * thread to a minimum, there's a handshake which allows only one thread
- * to be doing work on the completion queue at a time:
- *
- * 1) main thread sends completion thread a command via the command pipe;
- * 2) completion thread waits for aio events and returns the number
- *    received on the completion pipe
- * 3) main thread processes the received ctx->aio_events events
- * 4) loop back to 1) to let the completion thread refill the aio_events
- *    buffer.
- *
- * This workaround needs to disappear once the kernel provides a single
- * mechanism for waiting on both aio and normal fd wakeups.
- */
-static void *
-tap_aio_completion_thread(void *arg)
-{
-	tap_aio_internal_context_t *ctx = (tap_aio_internal_context_t *) arg;
-	int command;
-	int nr_events;
-	int rc;
-
-	while (1) {
-		rc = read(ctx->command_fd[0], &command, sizeof(command));
-
-		do {
-			rc = io_getevents(ctx->aio_ctx, 1,
-					  ctx->max_aio_events, ctx->aio_events,
-					  NULL);
-			if (rc) {
-				nr_events = rc;
-				rc = write(ctx->completion_fd[1], &nr_events,
-					   sizeof(nr_events));
-			}
-		} while (!rc);
-	}
-	return NULL;
-}
-
-void
-tap_aio_continue(tap_aio_internal_context_t *ctx)
-{
-        int cmd = 0;
-
-        if (!ctx->poll_in_thread)
-                return;
-
-        if (write(ctx->command_fd[1], &cmd, sizeof(cmd)) < 0)
-                DPRINTF("Cannot write to command pipe\n");
-}
-
-static int
-tap_aio_setup(tap_aio_internal_context_t *ctx,
-              struct io_event *aio_events,
-              int max_aio_events)
-{
-        int ret;
-
-        ctx->aio_events = aio_events;
-        ctx->max_aio_events = max_aio_events;
-        ctx->poll_in_thread = 0;
-
-        ctx->aio_ctx = (io_context_t) REQUEST_ASYNC_FD;
-        ret = io_setup(ctx->max_aio_events, &ctx->aio_ctx);
-        if (ret < 0 && ret != -EINVAL)
-                return ret;
-        else if (ret > 0) {
-                ctx->pollfd = ret;
-                return ctx->pollfd;
-        }
-
-        ctx->aio_ctx = (io_context_t) 0;
-        ret = io_setup(ctx->max_aio_events, &ctx->aio_ctx);
-        if (ret < 0)
-                return ret;
-
-        if ((ret = pipe(ctx->command_fd)) < 0) {
-                DPRINTF("Unable to create command pipe\n");
-                return -1;
-        }
-        if ((ret = pipe(ctx->completion_fd)) < 0) {
-                DPRINTF("Unable to create completion pipe\n");
-                return -1;
-        }
-
-        if ((ret = pthread_create(&ctx->aio_thread, NULL,
-                                  tap_aio_completion_thread, ctx)) != 0) {
-                DPRINTF("Unable to create completion thread\n");
-                return -1;
-        }
-
-        ctx->pollfd = ctx->completion_fd[0];
-        ctx->poll_in_thread = 1;
-
-        tap_aio_continue(ctx);
-
-        return 0;
-}
-
-int
-tap_aio_get_events(tap_aio_internal_context_t *ctx)
-{
-        int nr_events = 0;
-
-        if (!ctx->poll_in_thread)
-                nr_events = io_getevents(ctx->aio_ctx, 1,
-                                         ctx->max_aio_events, ctx->aio_events, NULL);
-        else {
-		int r;
-		r = read(ctx->completion_fd[0], &nr_events, sizeof(nr_events));
-		if (r < 0) {
-			if (errno == EAGAIN || errno == EINTR)
-				return 0;
-			/* This is pretty bad, we'll probably spin */
-			DPRINTF("Aargh, read completion_fd failed: %s",
-				strerror(errno));
-		} else if (r != sizeof(nr_events)) {
-			/* Should never happen because sizeof(nr_events)
-			 * fits in the guaranteed atomic pipe write size.
-			 * Blundering on is slightly nicer than asserting */
-			DPRINTF("Aargh, read completion_fd short read %d", r);
-		}
-	}
-
-        return nr_events;
-}
-
-int tap_aio_more_events(tap_aio_internal_context_t *ctx)
-{
-        return io_getevents(ctx->aio_ctx, 0,
-                            ctx->max_aio_events, ctx->aio_events, NULL);
-}
-
-int tap_aio_init(tap_aio_context_t *ctx, uint64_t sectors,
-		int max_aio_reqs)
-{
-	int i, ret;
-	long ioidx;
-
-	ctx->iocb_list = NULL;
-	ctx->pending_aio = NULL;
-	ctx->aio_events = NULL;
-	ctx->iocb_free = NULL;
-	ctx->iocb_queue = NULL;
-
-	/*Initialize Locking bitmap*/
-	ctx->sector_lock = calloc(1, sectors);
-		
-	if (!ctx->sector_lock) {
-		DPRINTF("Failed to allocate sector lock\n");
-		goto fail;
-	}
-
-
-	/* Initialize AIO */
-	ctx->max_aio_reqs = max_aio_reqs;
-	ctx->iocb_free_count = ctx->max_aio_reqs;
-	ctx->iocb_queued	 = 0;
-
-	if (!(ctx->iocb_list = malloc(sizeof(struct iocb) * ctx->max_aio_reqs)) ||
-		!(ctx->pending_aio = malloc(sizeof(struct pending_aio) * ctx->max_aio_reqs)) ||
-		!(ctx->aio_events = malloc(sizeof(struct io_event) * ctx->max_aio_reqs)) ||
-		!(ctx->iocb_free = malloc(sizeof(struct iocb *) * ctx->max_aio_reqs)) ||
-		!(ctx->iocb_queue = malloc(sizeof(struct iocb *) * ctx->max_aio_reqs))) 
-	{
-		DPRINTF("Failed to allocate AIO structs (max_aio_reqs = %d)\n",
-				ctx->max_aio_reqs);
-		goto fail;
-	}
-
-	ret = tap_aio_setup(&ctx->aio_ctx, ctx->aio_events, ctx->max_aio_reqs);
-	if (ret < 0) {
-		if (ret == -EAGAIN) {
-			DPRINTF("Couldn't setup AIO context.  If you are "
-				"trying to concurrently use a large number "
-				"of blktap-based disks, you may need to "
-				"increase the system-wide aio request limit. "
-				"(e.g. 'echo echo 1048576 > /proc/sys/fs/"
-				"aio-max-nr')\n");
-		} else {
-			DPRINTF("Couldn't setup AIO context.\n");
-		}
-		goto fail;
-	}
-
-	for (i=0;i<ctx->max_aio_reqs;i++)
-		ctx->iocb_free[i] = &ctx->iocb_list[i];
-
-	DPRINTF("AIO state initialised\n");
-
-	return 0;
-
-fail:
-	return -1;
-}
-
-void tap_aio_free(tap_aio_context_t *ctx)
-{
-	if (ctx->sector_lock)
-		free(ctx->sector_lock);
-	if (ctx->iocb_list)
-		free(ctx->iocb_list);
-	if (ctx->pending_aio)
-		free(ctx->pending_aio);
-	if (ctx->aio_events)
-		free(ctx->aio_events);
-	if (ctx->iocb_free)
-		free(ctx->iocb_free);
-	if (ctx->iocb_queue)
-		free(ctx->iocb_queue);
-}
-
-/*TODO: Fix sector span!*/
-int tap_aio_can_lock(tap_aio_context_t *ctx, uint64_t sector)
-{
-	return (ctx->sector_lock[sector] ? 0 : 1);
-}
-
-int tap_aio_lock(tap_aio_context_t *ctx, uint64_t sector)
-{
-	return ++ctx->sector_lock[sector];
-}
-
-void tap_aio_unlock(tap_aio_context_t *ctx, uint64_t sector)
-{
-	if (!ctx->sector_lock[sector]) return;
-
-	--ctx->sector_lock[sector];
-	return;
-}
-
-
-int tap_aio_read(tap_aio_context_t *ctx, int fd, int size, 
-		uint64_t offset, char *buf, td_callback_t cb,
-		int id, uint64_t sector, void *private)
-{
-	struct	 iocb *io;
-	struct	 pending_aio *pio;
-	long	 ioidx;
-
-	if (ctx->iocb_free_count == 0)
-		return -ENOMEM;
-
-	io = ctx->iocb_free[--ctx->iocb_free_count];
-
-	ioidx = IOCB_IDX(ctx, io);
-	pio = &ctx->pending_aio[ioidx];
-	pio->cb = cb;
-	pio->id = id;
-	pio->private = private;
-	pio->nb_sectors = size/512;
-	pio->buf = buf;
-	pio->sector = sector;
-
-	io_prep_pread(io, fd, buf, size, offset);
-	io->data = (void *)ioidx;
-
-	ctx->iocb_queue[ctx->iocb_queued++] = io;
-
-	return 0;
-}
-
-int tap_aio_write(tap_aio_context_t *ctx, int fd, int size,
-		uint64_t offset, char *buf, td_callback_t cb,
-		int id, uint64_t sector, void *private)
-{
-	struct	 iocb *io;
-	struct	 pending_aio *pio;
-	long	 ioidx;
-
-	if (ctx->iocb_free_count == 0)
-		return -ENOMEM;
-
-	io = ctx->iocb_free[--ctx->iocb_free_count];
-
-	ioidx = IOCB_IDX(ctx, io);
-	pio = &ctx->pending_aio[ioidx];
-	pio->cb = cb;
-	pio->id = id;
-	pio->private = private;
-	pio->nb_sectors = size/512;
-	pio->buf = buf;
-	pio->sector = sector;
-
-	io_prep_pwrite(io, fd, buf, size, offset);
-	io->data = (void *)ioidx;
-
-	ctx->iocb_queue[ctx->iocb_queued++] = io;
-
-	return 0;
-}
-
-int tap_aio_submit(tap_aio_context_t *ctx)
-{
-	int ret;
-
-	if (!ctx->iocb_queued)
-		return 0;
-
-	ret = io_submit(ctx->aio_ctx.aio_ctx, ctx->iocb_queued, ctx->iocb_queue);
-
-	/* XXX: TODO: Handle error conditions here. */
-
-	/* Success case: */
-	ctx->iocb_queued = 0;
-
-	return 0;
-}
-
diff --git a/tools/blktap/drivers/tapaio.h b/tools/blktap/drivers/tapaio.h
deleted file mode 100644
index 27d3881..0000000
--- a/tools/blktap/drivers/tapaio.h
+++ /dev/null
@@ -1,108 +0,0 @@
-/*
- * Copyright (c) 2006 Andrew Warfield and Julian Chesterfield
- * Copyright (c) 2007 Red Hat, 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; 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 __TAPAIO_H__
-#define __TAPAIO_H__
-
-#include <pthread.h>
-#include <libaio.h>
-#include <stdint.h>
-
-#include "tapdisk.h"
-
-#define IOCB_IDX(_ctx, _io) ((_io) - (_ctx)->iocb_list)
-
-struct tap_aio_internal_context {
-        io_context_t     aio_ctx;
-
-        struct io_event *aio_events;
-        int              max_aio_events;
-
-        pthread_t        aio_thread;
-        int              command_fd[2];
-        int              completion_fd[2];
-        int              pollfd;
-        unsigned int     poll_in_thread : 1;
-};
-	
-
-typedef struct tap_aio_internal_context tap_aio_internal_context_t;
-
-
-struct pending_aio {
-	td_callback_t cb;
-	int id;
-	void *private;
-	int nb_sectors;
-	char *buf;
-	uint64_t sector;
-};
-
-	
-struct tap_aio_context {
-	tap_aio_internal_context_t    aio_ctx;
-
-	int                  max_aio_reqs;
-	struct iocb         *iocb_list;
-	struct iocb        **iocb_free;
-	struct pending_aio  *pending_aio;
-	int                  iocb_free_count;
-	struct iocb        **iocb_queue;
-	int	             iocb_queued;
-	struct io_event     *aio_events;
-
-	/* Locking bitmap for AIO reads/writes */
-	uint8_t *sector_lock;		   
-};
-
-typedef struct tap_aio_context tap_aio_context_t;
-
-void tap_aio_continue   (tap_aio_internal_context_t *ctx);
-int  tap_aio_get_events (tap_aio_internal_context_t *ctx);
-int  tap_aio_more_events(tap_aio_internal_context_t *ctx);
-
-
-int tap_aio_init(tap_aio_context_t *ctx, uint64_t sectors,
-		int max_aio_reqs);
-void tap_aio_free(tap_aio_context_t *ctx);
-
-int tap_aio_can_lock(tap_aio_context_t *ctx, uint64_t sector);
-int tap_aio_lock(tap_aio_context_t *ctx, uint64_t sector);
-void tap_aio_unlock(tap_aio_context_t *ctx, uint64_t sector);
-
-
-int tap_aio_read(tap_aio_context_t *ctx, int fd, int size, 
-		uint64_t offset, char *buf, td_callback_t cb,
-		int id, uint64_t sector, void *private);
-int tap_aio_write(tap_aio_context_t *ctx, int fd, int size,
-		uint64_t offset, char *buf, td_callback_t cb,
-		int id, uint64_t sector, void *private);
-int tap_aio_submit(tap_aio_context_t *ctx);
-
-#endif /* __TAPAIO_H__ */
diff --git a/tools/blktap/drivers/tapdisk.c b/tools/blktap/drivers/tapdisk.c
deleted file mode 100644
index 19cd777..0000000
--- a/tools/blktap/drivers/tapdisk.c
+++ /dev/null
@@ -1,872 +0,0 @@
-/* tapdisk.c
- *
- * separate disk process, spawned by blktapctrl. Inherits code from driver 
- * plugins
- * 
- * Copyright (c) 2005 Julian Chesterfield and Andrew Warfield.
- *
- */
-
-#define MSG_SIZE 4096
-#define TAPDISK
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <sys/mman.h>
-#include <fcntl.h>
-#include <string.h>
-#include <signal.h>
-#include <sys/stat.h>
-#include <sys/types.h>
-#include <sys/poll.h>
-#include <unistd.h>
-#include <errno.h>
-#include <pthread.h>
-#include <time.h>
-#include <err.h>
-#include <poll.h>
-#include <sys/statvfs.h>
-#include <sys/ioctl.h>
-#include "blktaplib.h"
-#include "tapdisk.h"
-
-#if 1                                                                        
-#define ASSERT(_p) \
-    if ( !(_p) ) { DPRINTF("Assertion '%s' failed, line %d, file %s", #_p , \
-    __LINE__, __FILE__); *(int*)0=0; }
-#else
-#define ASSERT(_p) ((void)0)
-#endif 
-
-#define INPUT 0
-#define OUTPUT 1
-
-static int maxfds, fds[2], run = 1;
-
-static pid_t process;
-int connected_disks = 0;
-fd_list_entry_t *fd_start = NULL;
-
-int do_cow_read(struct disk_driver *dd, blkif_request_t *req, 
-		int sidx, uint64_t sector, int nr_secs);
-
-#define td_for_each_disk(tds, drv) \
-        for (drv = tds->disks; drv != NULL; drv = drv->next)
-
-static void usage(void) 
-{
-	fprintf(stderr, "blktap-utils: v1.0.0\n");
-	fprintf(stderr, "usage: tapdisk <READ fifo> <WRITE fifo>\n");
-        exit(-1);
-}
-
-static void daemonize(void)
-{
-	int i;
-
-	if (getppid()==1) return; /* already a daemon */
-	if (fork() != 0) exit(0);
-
-#if 0
-	/*Set new program session ID and close all descriptors*/
-	setsid();
-	for (i = getdtablesize(); i >= 0; --i) close(i);
-
-	/*Send all I/O to /dev/null */
-	i = open("/dev/null",O_RDWR);
-	dup(i); 
-	dup(i);
-#endif
-	return;
-}
-
-static void free_driver(struct disk_driver *d)
-{
-	if (d->name)
-		free(d->name);
-	if (d->private)
-		free(d->private);
-	free(d);
-}
-
-static void unmap_disk(struct td_state *s)
-{
-	tapdev_info_t *info = s->ring_info;
-	struct disk_driver *dd, *tmp;
-	fd_list_entry_t *entry;
-
-	dd = s->disks;
-	while (dd) {
-		tmp = dd->next;
-		dd->drv->td_close(dd);
-		free_driver(dd);
-		dd = tmp;
-	}
-
-	if (info != NULL && info->mem > 0)
-	        munmap(info->mem, getpagesize() * BLKTAP_MMAP_REGION_SIZE);
-
-	entry = s->fd_entry;
-	*entry->pprev = entry->next;
-	if (entry->next)
-		entry->next->pprev = entry->pprev;
-
-	close(info->fd);
-
-	free(s->fd_entry);
-	free(s->blkif);
-	free(s->ring_info);
-	free(s);
-
-	return;
-}
-
-static void sig_handler(int sig)
-{
-	/*Received signal to close. If no disks are active, we close app.*/
-
-	if (connected_disks < 1) run = 0;	
-}
-
-static inline int LOCAL_FD_SET(fd_set *readfds)
-{
-	fd_list_entry_t *ptr;
-	struct disk_driver *dd;
-
-	ptr = fd_start;
-	while (ptr != NULL) {
-		if (ptr->tap_fd) {
-			FD_SET(ptr->tap_fd, readfds);
-			td_for_each_disk(ptr->s, dd) {
-				if (dd->io_fd[READ]) 
-					FD_SET(dd->io_fd[READ], readfds);
-				maxfds = (dd->io_fd[READ] > maxfds ? 
-					  dd->io_fd[READ] : maxfds);
-			}
-			maxfds = (ptr->tap_fd > maxfds ? ptr->tap_fd : maxfds);
-		}
-		ptr = ptr->next;
-	}
-
-	return 0;
-}
-
-static inline fd_list_entry_t *add_fd_entry(int tap_fd, struct td_state *s)
-{
-	fd_list_entry_t **pprev, *entry;
-	int i;
-
-	DPRINTF("Adding fd_list_entry\n");
-
-	/*Add to linked list*/
-	s->fd_entry   = entry = malloc(sizeof(fd_list_entry_t));
-	entry->tap_fd = tap_fd;
-	entry->s      = s;
-	entry->next   = NULL;
-
-	pprev = &fd_start;
-	while (*pprev != NULL)
-		pprev = &(*pprev)->next;
-
-	*pprev = entry;
-	entry->pprev = pprev;
-
-	return entry;
-}
-
-static inline struct td_state *get_state(int cookie)
-{
-	fd_list_entry_t *ptr;
-
-	ptr = fd_start;
-	while (ptr != NULL) {
-		if (ptr->cookie == cookie) return ptr->s;
-		ptr = ptr->next;
-	}
-	return NULL;
-}
-
-static struct tap_disk *get_driver(int drivertype)
-{
-	/* blktapctrl has passed us the driver type */
-
-	return dtypes[drivertype]->drv;
-}
-
-static struct td_state *state_init(void)
-{
-	int i;
-	struct td_state *s;
-	blkif_t *blkif;
-
-	s = malloc(sizeof(struct td_state));
-	blkif = s->blkif = malloc(sizeof(blkif_t));
-	s->ring_info = calloc(1, sizeof(tapdev_info_t));
-
-	for (i = 0; i < MAX_REQUESTS; i++) {
-		blkif->pending_list[i].secs_pending = 0;
-		blkif->pending_list[i].submitting = 0;
-	}
-
-	return s;
-}
-
-static int map_new_dev(struct td_state *s, int minor)
-{
-	int tap_fd;
-	tapdev_info_t *info = s->ring_info;
-	char *devname;
-	fd_list_entry_t *ptr;
-	int page_size;
-
-	if (asprintf(&devname,"%s/%s%d", BLKTAP_DEV_DIR, BLKTAP_DEV_NAME, minor) == -1)
-		return -1;
-	tap_fd = open(devname, O_RDWR);
-	if (tap_fd == -1) 
-	{
-		DPRINTF("open failed on dev %s!",devname);
-		goto fail;
-	} 
-	info->fd = tap_fd;
-
-	/*Map the shared memory*/
-	page_size = getpagesize();
-	info->mem = mmap(0, page_size * BLKTAP_MMAP_REGION_SIZE, 
-			  PROT_READ | PROT_WRITE, MAP_SHARED, info->fd, 0);
-	if ((long int)info->mem == -1) 
-	{
-		DPRINTF("mmap failed on dev %s!\n",devname);
-		goto fail;
-	}
-
-	/* assign the rings to the mapped memory */ 
-	info->sring = (blkif_sring_t *)((unsigned long)info->mem);
-	BACK_RING_INIT(&info->fe_ring, info->sring, page_size);
-	
-	info->vstart = 
-	        (unsigned long)info->mem + (BLKTAP_RING_PAGES * page_size);
-
-	ioctl(info->fd, BLKTAP_IOCTL_SENDPID, process );
-	ioctl(info->fd, BLKTAP_IOCTL_SETMODE, BLKTAP_MODE_INTERPOSE );
-	free(devname);
-
-	/*Update the fd entry*/
-	ptr = fd_start;
-	while (ptr != NULL) {
-		if (s == ptr->s) {
-			ptr->tap_fd = tap_fd;
-			break;
-		}
-		ptr = ptr->next;
-	}	
-
-	return minor;
-
- fail:
-	free(devname);
-	return -1;
-}
-
-static struct disk_driver *disk_init(struct td_state *s, 
-				     struct tap_disk *drv, 
-				     char *name, td_flag_t flags)
-{
-	struct disk_driver *dd;
-
-	dd = calloc(1, sizeof(struct disk_driver));
-	if (!dd)
-		return NULL;
-	
-	dd->private = malloc(drv->private_data_size);
-	if (!dd->private) {
-		free(dd);
-		return NULL;
-	}
-
-	dd->drv      = drv;
-	dd->td_state = s;
-	dd->name     = name;
-	dd->flags    = flags;
-
-	return dd;
-}
-
-static int open_disk(struct td_state *s, 
-		     struct tap_disk *drv, char *path, td_flag_t flags)
-{
-	int err;
-	char *dup;
-	td_flag_t pflags;
-	struct disk_id id;
-	struct disk_driver *d;
-
-	dup = strdup(path);
-	if (!dup)
-		return -ENOMEM;
-
-	memset(&id, 0, sizeof(struct disk_id));
-	s->disks = d = disk_init(s, drv, dup, flags);
-	if (!d)
-		return -ENOMEM;
-
-	err = drv->td_open(d, path, flags);
-	if (err) {
-		free_driver(d);
-		s->disks = NULL;
-		return -ENOMEM;
-	}
-	pflags = flags | TD_RDONLY;
-
-	/* load backing files as necessary */
-	while ((err = d->drv->td_get_parent_id(d, &id)) == 0) {
-		struct disk_driver *new;
-		
-		if (id.drivertype > MAX_DISK_TYPES || 
-		    !get_driver(id.drivertype) || !id.name)
-			goto fail;
-
-		dup = strdup(id.name);
-		if (!dup)
-			goto fail;
-
-		new = disk_init(s, get_driver(id.drivertype), dup, pflags);
-		if (!new)
-			goto fail;
-
-		err = new->drv->td_open(new, new->name, pflags);
-		if (err)
-			goto fail;
-
-		err = d->drv->td_validate_parent(d, new, 0);
-		if (err) {
-			d->next = new;
-			goto fail;
-		}
-
-		d = d->next = new;
-		free(id.name);
-	}
-
-	s->info |= ((flags & TD_RDONLY) ? VDISK_READONLY : 0);
-
-	if (err >= 0)
-		return 0;
-
- fail:
-	DPRINTF("failed opening disk\n");
-	if (id.name)
-		free(id.name);
-	d = s->disks;
-	while (d) {
-		struct disk_driver *tmp = d->next;
-		d->drv->td_close(d);
-		free_driver(d);
-		d = tmp;
-	}
-	s->disks = NULL;
-	return -1;
-}
-
-static int read_msg(char *buf)
-{
-	int length, len, msglen, tap_fd, *io_fd;
-	char *ptr, *path;
-	image_t *img;
-	msg_hdr_t *msg;
-	msg_newdev_t *msg_dev;
-	msg_pid_t *msg_pid;
-	struct tap_disk *drv;
-	int ret = -1;
-	struct td_state *s = NULL;
-	fd_list_entry_t *entry;
-
-	length = read(fds[READ], buf, MSG_SIZE);
-
-	if (length > 0 && length >= sizeof(msg_hdr_t)) 
-	{
-		msg = (msg_hdr_t *)buf;
-		DPRINTF("Tapdisk: Received msg, len %d, type %d, UID %d\n",
-			length,msg->type,msg->cookie);
-
-		switch (msg->type) {
-		case CTLMSG_PARAMS: 			
-			ptr = buf + sizeof(msg_hdr_t);
-			len = (length - sizeof(msg_hdr_t));
-			path = calloc(1, len);
-			
-			memcpy(path, ptr, len); 
-			DPRINTF("Received CTLMSG_PARAMS: [%s]\n", path);
-
-			/*Assign driver*/
-			drv = get_driver(msg->drivertype);
-			if (drv == NULL)
-				goto params_done;
-				
-			DPRINTF("Loaded driver: name [%s], type [%d]\n",
-				drv->disk_type, msg->drivertype);
-
-			/* Allocate the disk structs */
-			s = state_init();
-			if (s == NULL)
-				goto params_done;
-
-			/*Open file*/
-			ret = open_disk(s, drv, path, 
-					((msg->readonly) ? TD_RDONLY : 0));
-			if (ret)
-				goto params_done;
-
-			entry = add_fd_entry(0, s);
-			entry->cookie = msg->cookie;
-			DPRINTF("Entered cookie %d\n", entry->cookie);
-			
-			memset(buf, 0x00, MSG_SIZE); 
-			
-		params_done:
-			if (ret == 0) {
-				msglen = sizeof(msg_hdr_t) + sizeof(image_t);
-				msg->type = CTLMSG_IMG;
-				img = (image_t *)(buf + sizeof(msg_hdr_t));
-				img->size = s->size;
-				img->secsize = s->sector_size;
-				img->info = s->info;
-			} else {
-				msglen = sizeof(msg_hdr_t);
-				msg->type = CTLMSG_IMG_FAIL;
-				msg->len = msglen;
-			}
-			len = write(fds[WRITE], buf, msglen);
-			free(path);
-			return 1;
-			
-		case CTLMSG_NEWDEV:
-			msg_dev = (msg_newdev_t *)(buf + sizeof(msg_hdr_t));
-
-			s = get_state(msg->cookie);
-			DPRINTF("Retrieving state, cookie %d.....[%s]\n",
-				msg->cookie, (s == NULL ? "FAIL":"OK"));
-			if (s != NULL) {
-				ret = ((map_new_dev(s, msg_dev->devnum) 
-					== msg_dev->devnum ? 0: -1));
-				connected_disks++;
-			}	
-
-			memset(buf, 0x00, MSG_SIZE); 
-			msglen = sizeof(msg_hdr_t);
-			msg->type = (ret == 0 ? CTLMSG_NEWDEV_RSP 
-				              : CTLMSG_NEWDEV_FAIL);
-			msg->len = msglen;
-
-			len = write(fds[WRITE], buf, msglen);
-			return 1;
-
-		case CTLMSG_CLOSE:
-			s = get_state(msg->cookie);
-			if (s) unmap_disk(s);
-			
-			connected_disks--;
-			sig_handler(SIGINT);
-
-			return 1;			
-
-		case CTLMSG_PID:
-			memset(buf, 0x00, MSG_SIZE);
-			msglen = sizeof(msg_hdr_t) + sizeof(msg_pid_t);
-			msg->type = CTLMSG_PID_RSP;
-			msg->len = msglen;
-
-			msg_pid = (msg_pid_t *)(buf + sizeof(msg_hdr_t));
-			process = getpid();
-			msg_pid->pid = process;
-
-			len = write(fds[WRITE], buf, msglen);
-			return 1;
-
-		default:
-			return 0;
-		}
-	}
-	return 0;
-}
-
-static inline int write_rsp_to_ring(struct td_state *s, blkif_response_t *rsp)
-{
-	tapdev_info_t *info = s->ring_info;
-	blkif_response_t *rsp_d;
-	
-	rsp_d = RING_GET_RESPONSE(&info->fe_ring, info->fe_ring.rsp_prod_pvt);
-	memcpy(rsp_d, rsp, sizeof(blkif_response_t));
-	info->fe_ring.rsp_prod_pvt++;
-	
-	return 0;
-}
-
-static inline void kick_responses(struct td_state *s)
-{
-	tapdev_info_t *info = s->ring_info;
-
-	if (info->fe_ring.rsp_prod_pvt != info->fe_ring.sring->rsp_prod) 
-	{
-		RING_PUSH_RESPONSES(&info->fe_ring);
-		ioctl(info->fd, BLKTAP_IOCTL_KICK_FE);
-	}
-}
-
-static void io_done(struct disk_driver *dd, int sid)
-{
-	struct tap_disk *drv = dd->drv;
-
-	if (!run) return; /*We have received signal to close*/
-
-	if (sid > MAX_IOFD || drv->td_do_callbacks(dd, sid) > 0)
-		kick_responses(dd->td_state);
-
-	return;
-}
-
-static inline uint64_t
-segment_start(blkif_request_t *req, int sidx)
-{
-	int i;
-	uint64_t start = req->sector_number;
-
-	for (i = 0; i < sidx; i++) 
-		start += (req->seg[i].last_sect - req->seg[i].first_sect + 1);
-
-	return start;
-}
-
-uint64_t sends, responds;
-static int send_responses(struct disk_driver *dd, int res, 
-		   uint64_t sector, int nr_secs, int idx, void *private)
-{
-	pending_req_t   *preq;
-	blkif_request_t *req;
-	int responses_queued = 0;
-	struct td_state *s = dd->td_state;
-	blkif_t *blkif = s->blkif;
-	int sidx = (int)(long)private, secs_done = nr_secs;
-
-	if ( (idx > MAX_REQUESTS-1) )
-	{
-		DPRINTF("invalid index returned(%u)!\n", idx);
-		return 0;
-	}
-	preq = &blkif->pending_list[idx];
-	req  = &preq->req;
-
-	if (res == BLK_NOT_ALLOCATED) {
-		res = do_cow_read(dd, req, sidx, sector, nr_secs);
-		if (res >= 0) {
-			secs_done = res;
-			res = 0;
-		} else
-			secs_done = 0;
-	}
-
-	preq->secs_pending -= secs_done;
-
-	if (res == -EBUSY && preq->submitting) 
-		return -EBUSY;  /* propagate -EBUSY back to higher layers */
-	if (res) 
-		preq->status = BLKIF_RSP_ERROR;
-	
-	if (!preq->submitting && preq->secs_pending == 0) 
-	{
-		blkif_request_t tmp;
-		blkif_response_t *rsp;
-
-		tmp = preq->req;
-		rsp = (blkif_response_t *)req;
-		
-		rsp->id = tmp.id;
-		rsp->operation = tmp.operation;
-		rsp->status = preq->status;
-		
-		write_rsp_to_ring(s, rsp);
-		responses_queued++;
-	}
-	return responses_queued;
-}
-
-int do_cow_read(struct disk_driver *dd, blkif_request_t *req, 
-		int sidx, uint64_t sector, int nr_secs)
-{
-	char *page;
-	int ret, early;
-	uint64_t seg_start, seg_end;
-	struct td_state  *s = dd->td_state;
-	tapdev_info_t *info = s->ring_info;
-	struct disk_driver *parent = dd->next;
-	
-	seg_start = segment_start(req, sidx);
-	seg_end   = seg_start + req->seg[sidx].last_sect + 1;
-	
-	ASSERT(sector >= seg_start && sector + nr_secs <= seg_end);
-
-	page  = (char *)MMAP_VADDR(info->vstart, 
-				   (unsigned long)req->id, sidx);
-	page += (req->seg[sidx].first_sect << SECTOR_SHIFT);
-	page += ((sector - seg_start) << SECTOR_SHIFT);
-
-	if (!parent) {
-		memset(page, 0, nr_secs << SECTOR_SHIFT);
-		return nr_secs;
-	}
-
-	/* reissue request to backing file */
-	ret = parent->drv->td_queue_read(parent, sector, nr_secs,
-					 page, send_responses, 
-					 req->id, (void *)(long)sidx);
-	if (ret > 0)
-		parent->early += ret;
-
-	return ((ret >= 0) ? 0 : ret);
-}
-
-static void get_io_request(struct td_state *s)
-{
-	RING_IDX          rp, rc, j, i;
-	blkif_request_t  *req;
-	int idx, nsects, ret;
-	uint64_t sector_nr;
-	char *page;
-	int early = 0; /* count early completions */
-	struct disk_driver *dd = s->disks;
-	struct tap_disk *drv   = dd->drv;
-	blkif_t *blkif = s->blkif;
-	tapdev_info_t *info = s->ring_info;
-	int page_size = getpagesize();
-
-	if (!run) return; /*We have received signal to close*/
-
-	rp = info->fe_ring.sring->req_prod; 
-	xen_rmb();
-	for (j = info->fe_ring.req_cons; j != rp; j++)
-	{
-		int done = 0, start_seg = 0; 
-
-		req = NULL;
-		req = RING_GET_REQUEST(&info->fe_ring, j);
-		++info->fe_ring.req_cons;
-		
-		if (req == NULL) continue;
-
-		idx = req->id;
-
-		if (info->busy.req) {
-			/* continue where we left off last time */
-			ASSERT(info->busy.req == req);
-			start_seg = info->busy.seg_idx;
-			sector_nr = segment_start(req, start_seg);
-			info->busy.seg_idx = 0;
-			info->busy.req     = NULL;
-		} else {
-			ASSERT(blkif->pending_list[idx].secs_pending == 0);
-			memcpy(&blkif->pending_list[idx].req, 
-			       req, sizeof(*req));
-			blkif->pending_list[idx].status = BLKIF_RSP_OKAY;
-			blkif->pending_list[idx].submitting = 1;
-			sector_nr = req->sector_number;
-		}
-
-		if ((dd->flags & TD_RDONLY) && 
-		    (req->operation == BLKIF_OP_WRITE)) {
-			blkif->pending_list[idx].status = BLKIF_RSP_ERROR;
-			goto send_response;
-		}
-
-		for (i = start_seg; i < req->nr_segments; i++) {
-			nsects = req->seg[i].last_sect - 
-				 req->seg[i].first_sect + 1;
-	
-			if ((req->seg[i].last_sect >= page_size >> 9) ||
-			    (nsects <= 0))
-				continue;
-
-			page  = (char *)MMAP_VADDR(info->vstart, 
-						   (unsigned long)req->id, i);
-			page += (req->seg[i].first_sect << SECTOR_SHIFT);
-
-			if (sector_nr >= s->size) {
-				DPRINTF("Sector request failed:\n");
-				DPRINTF("%s request, idx [%d,%d] size [%llu], "
-					"sector [%llu,%llu]\n",
-					(req->operation == BLKIF_OP_WRITE ? 
-					 "WRITE" : "READ"),
-					idx,i,
-					(long long unsigned) 
-						nsects<<SECTOR_SHIFT,
-					(long long unsigned) 
-						sector_nr<<SECTOR_SHIFT,
-					(long long unsigned) sector_nr);
-				continue;
-			}
-
-			blkif->pending_list[idx].secs_pending += nsects;
-
-			switch (req->operation) 
-			{
-			case BLKIF_OP_WRITE:
-				ret = drv->td_queue_write(dd, sector_nr,
-							  nsects, page, 
-							  send_responses,
-							  idx, (void *)(long)i);
-				if (ret > 0) dd->early += ret;
-				else if (ret == -EBUSY) {
-					/* put req back on queue */
-					--info->fe_ring.req_cons;
-					info->busy.req     = req;
-					info->busy.seg_idx = i;
-					goto out;
-				}
-				break;
-			case BLKIF_OP_READ:
-				ret = drv->td_queue_read(dd, sector_nr,
-							 nsects, page, 
-							 send_responses,
-							 idx, (void *)(long)i);
-				if (ret > 0) dd->early += ret;
-				else if (ret == -EBUSY) {
-					/* put req back on queue */
-					--info->fe_ring.req_cons;
-					info->busy.req     = req;
-					info->busy.seg_idx = i;
-					goto out;
-				}
-				break;
-			default:
-				DPRINTF("Unknown block operation\n");
-				break;
-			}
-			sector_nr += nsects;
-		}
-	send_response:
-		blkif->pending_list[idx].submitting = 0;
-		/* force write_rsp_to_ring for synchronous case */
-		if (blkif->pending_list[idx].secs_pending == 0)
-			dd->early += send_responses(dd, 0, 0, 0, idx, 
-						    (void *)(long)0);
-	}
-
- out:
-	/*Batch done*/
-	td_for_each_disk(s, dd) {
-		dd->early += dd->drv->td_submit(dd);
-		if (dd->early > 0) {
-			io_done(dd, MAX_IOFD + 1);
-			dd->early = 0;
-		}
-	}
-
-	return;
-}
-
-int main(int argc, char *argv[])
-{
-	int len, msglen, ret;
-	char *p, *buf;
-	fd_set readfds, writefds;	
-	fd_list_entry_t *ptr;
-	struct td_state *s;
-	char openlogbuf[128];
-
-	if (argc != 3) usage();
-
-	daemonize();
-
-	snprintf(openlogbuf, sizeof(openlogbuf), "TAPDISK[%d]", getpid());
-	openlog(openlogbuf, LOG_CONS|LOG_ODELAY, LOG_DAEMON);
-	/*Setup signal handlers*/
-	signal (SIGBUS, sig_handler);
-	signal (SIGINT, sig_handler);
-
-	/*Open the control channel*/
-	fds[READ]  = open(argv[1],O_RDWR|O_NONBLOCK);
-	fds[WRITE] = open(argv[2],O_RDWR|O_NONBLOCK);
-
-	if ( (fds[READ] < 0) || (fds[WRITE] < 0) ) 
-	{
-		DPRINTF("FD open failed [%d,%d]\n", fds[READ], fds[WRITE]);
-		exit(-1);
-	}
-
-	buf = calloc(MSG_SIZE, 1);
-
-	if (buf == NULL) 
-        {
-		DPRINTF("ERROR: allocating memory.\n");
-		exit(-1);
-	}
-
-	while (run) 
-        {
-		ret = 0;
-		FD_ZERO(&readfds);
-		FD_SET(fds[READ], &readfds);
-		maxfds = fds[READ];
-
-		/*Set all tap fds*/
-		LOCAL_FD_SET(&readfds);
-
-		/*Wait for incoming messages*/
-		ret = select(maxfds + 1, &readfds, (fd_set *) 0, 
-			     (fd_set *) 0, NULL);
-
-		if (ret > 0) 
-		{
-			ptr = fd_start;
-			while (ptr != NULL) {
-				int progress_made = 0;
-				struct disk_driver *dd;
-				tapdev_info_t *info = ptr->s->ring_info;
-
-				td_for_each_disk(ptr->s, dd) {
-					if (dd->io_fd[READ] &&
-					    FD_ISSET(dd->io_fd[READ], 
-						     &readfds)) {
-						io_done(dd, READ);
-						progress_made = 1;
-					}
-				}
-
-				/* completed io from above may have 
-				 * queued new requests on chained disks */
-				if (progress_made) {
-					td_for_each_disk(ptr->s, dd) {
-						dd->early += 
-							dd->drv->td_submit(dd);
-						if (dd->early > 0) {
-							io_done(dd, 
-								MAX_IOFD + 1);
-							dd->early = 0;
-						}
-					}
-				}
-
-				if (FD_ISSET(ptr->tap_fd, &readfds) ||
-				    (info->busy.req && progress_made))
-					get_io_request(ptr->s);
-
-				ptr = ptr->next;
-			}
-
-			if (FD_ISSET(fds[READ], &readfds))
-				read_msg(buf);
-		}
-	}
-	free(buf);
-	close(fds[READ]);
-	close(fds[WRITE]);
-
-	ptr = fd_start;
-	while (ptr != NULL) {
-		s = ptr->s;
-		unmap_disk(s);
-		close(ptr->tap_fd);
-		ptr = ptr->next;
-	}
-	closelog();
-
-	return 0;
-}
diff --git a/tools/blktap/drivers/tapdisk.h b/tools/blktap/drivers/tapdisk.h
deleted file mode 100644
index f3e165a..0000000
--- a/tools/blktap/drivers/tapdisk.h
+++ /dev/null
@@ -1,259 +0,0 @@
-/* tapdisk.h
- *
- * Generic disk interface for blktap-based image adapters.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- * 
- * Some notes on the tap_disk interface:
- * 
- * tap_disk aims to provide a generic interface to easily implement new 
- * types of image accessors.  The structure-of-function-calls is similar
- * to disk interfaces used in qemu/denali/etc, with the significant 
- * difference being the expectation of asynchronous rather than synchronous 
- * I/O.  The asynchronous interface is intended to allow lots of requests to
- * be pipelined through a disk, without the disk requiring any of its own
- * threads of control.  As such, a batch of requests is delivered to the disk
- * using:
- * 
- *    td_queue_[read,write]()
- * 
- * and passing in a completion callback, which the disk is responsible for 
- * tracking.  The end of a back is marked with a call to:
- * 
- *    td_submit()
- * 
- * The disk implementation must provide a file handle, which is used to 
- * indicate that it needs to do work.  tapdisk will add this file handle 
- * (returned from td_get_fd()) to it's poll set, and will call into the disk
- * using td_do_callbacks() whenever there is data pending.
- * 
- * Two disk implementations demonstrate how this interface may be used to 
- * implement disks with both asynchronous and synchronous calls.  block-aio.c
- * maps this interface down onto the linux libaio calls, while block-sync uses 
- * normal posix read/write.
- * 
- * A few things to realize about the sync case, which doesn't need to defer 
- * io completions:
- * 
- *   - td_queue_[read,write]() call read/write directly, and then call the 
- *     callback immediately.  The MUST then return a value greater than 0
- *     in order to tell tapdisk that requests have finished early, and to 
- *     force responses to be kicked to the clents.
- * 
- *   - The fd used for poll is an otherwise unused pipe, which allows poll to 
- *     be safely called without ever returning anything.
- *
- * NOTE: tapdisk uses the number of sectors submitted per request as a 
- * ref count.  Plugins must use the callback function to communicate the
- * completion--or error--of every sector submitted to them.
- *
- * td_get_parent_id returns:
- *     0 if parent id successfully retrieved
- *     TD_NO_PARENT if no parent exists
- *     -errno on error
- */
-
-#ifndef TAPDISK_H_
-#define TAPDISK_H_
-
-#include <stdint.h>
-#include <syslog.h>
-#include <stdio.h>
-#include "blktaplib.h"
-
-/*If enabled, log all debug messages to syslog*/
-#if 1
-#define DPRINTF(_f, _a...) syslog( LOG_DEBUG, __FILE__ ":%d: " _f , __LINE__, ## _a )
-#else
-#define DPRINTF(_f, _a...) ((void)0)
-#endif
-
-/* Things disks need to know about, these should probably be in a higher-level
- * header. */
-#define MAX_SEGMENTS_PER_REQ    11
-#define SECTOR_SHIFT             9
-#define DEFAULT_SECTOR_SIZE    512
-
-#define MAX_IOFD                 2
-
-#define BLK_NOT_ALLOCATED       99
-#define TD_NO_PARENT             1
-
-typedef uint32_t td_flag_t;
-
-#define TD_RDONLY                1
-
-struct td_state;
-struct tap_disk;
-
-struct disk_id {
-	char *name;
-	int drivertype;
-};
-
-struct disk_driver {
-	int early;
-	char *name;
-	void *private;
-	td_flag_t flags;
-	int io_fd[MAX_IOFD];
-	struct tap_disk *drv;
-	struct td_state *td_state;
-	struct disk_driver *next;
-};
-
-/* This structure represents the state of an active virtual disk.           */
-struct td_state {
-	struct disk_driver *disks;
-	void *blkif;
-	void *image;
-	void *ring_info;
-	void *fd_entry;
-	uint64_t sector_size;
-	uint64_t size;
-	unsigned int       info;
-};
-
-/* Prototype of the callback to activate as requests complete.              */
-typedef int (*td_callback_t)(struct disk_driver *dd, int res, uint64_t sector,
-			     int nb_sectors, int id, void *private);
-
-/* Structure describing the interface to a virtual disk implementation.     */
-/* See note at the top of this file describing this interface.              */
-struct tap_disk {
-	const char *disk_type;
-	int private_data_size;
-	int (*td_open)           (struct disk_driver *dd, 
-				  const char *name, td_flag_t flags);
-	int (*td_queue_read)     (struct disk_driver *dd, uint64_t sector,
-				  int nb_sectors, char *buf, td_callback_t cb,
-				  int id, void *prv);
-	int (*td_queue_write)    (struct disk_driver *dd, uint64_t sector,
-				  int nb_sectors, char *buf, td_callback_t cb, 
-				  int id, void *prv);
-	int (*td_submit)         (struct disk_driver *dd);
-	int (*td_close)          (struct disk_driver *dd);
-	int (*td_do_callbacks)   (struct disk_driver *dd, int sid);
-	int (*td_get_parent_id)  (struct disk_driver *dd, struct disk_id *id);
-	int (*td_validate_parent)(struct disk_driver *dd, 
-				  struct disk_driver *p, td_flag_t flags);
-};
-
-typedef struct disk_info {
-	int  idnum;
-	char name[50];       /* e.g. "RAMDISK" */
-	char handle[10];     /* xend handle, e.g. 'ram' */
-	int  single_handler; /* is there a single controller for all */
-	                     /* instances of disk type? */
-	int  use_ioemu;      /* backend provider: 0 = tapdisk; 1 = ioemu */
-
-#ifdef TAPDISK
-	struct tap_disk *drv;	
-#endif
-} disk_info_t;
-
-void debug_fe_ring(struct td_state *s);
-
-extern struct tap_disk tapdisk_aio;
-extern struct tap_disk tapdisk_sync;
-extern struct tap_disk tapdisk_vmdk;
-extern struct tap_disk tapdisk_ram;
-extern struct tap_disk tapdisk_qcow;
-extern struct tap_disk tapdisk_qcow2;
-
-
-/*Define Individual Disk Parameters here */
-static disk_info_t aio_disk = {
-	DISK_TYPE_AIO,
-	"raw image (aio)",
-	"aio",
-	0,
-	0,
-#ifdef TAPDISK
-	&tapdisk_aio,
-#endif
-};
-
-static disk_info_t sync_disk = {
-	DISK_TYPE_SYNC,
-	"raw image (sync)",
-	"sync",
-	0,
-	0,
-#ifdef TAPDISK
-	&tapdisk_sync,
-#endif
-};
-
-static disk_info_t vmdk_disk = {
-	DISK_TYPE_VMDK,
-	"vmware image (vmdk)",
-	"vmdk",
-	1,
-	0,
-#ifdef TAPDISK
-	&tapdisk_vmdk,
-#endif
-};
-
-static disk_info_t ram_disk = {
-	DISK_TYPE_RAM,
-	"ramdisk image (ram)",
-	"ram",
-	1,
-	0,
-#ifdef TAPDISK
-	&tapdisk_ram,
-#endif
-};
-
-static disk_info_t qcow_disk = {
-	DISK_TYPE_QCOW,
-	"qcow disk (qcow)",
-	"qcow",
-	0,
-	0,
-#ifdef TAPDISK
-	&tapdisk_qcow,
-#endif
-};
-
-static disk_info_t qcow2_disk = {
-	DISK_TYPE_QCOW2,
-	"qcow2 disk (qcow2)",
-	"qcow2",
-	0,
-	0,
-#ifdef TAPDISK
-	&tapdisk_qcow2,
-#endif
-};
-
-/*Main disk info array */
-static disk_info_t *dtypes[] = {
-	&aio_disk,
-	&sync_disk,
-	&vmdk_disk,
-	&ram_disk,
-	&qcow_disk,
-	&qcow2_disk,
-};
-
-typedef struct driver_list_entry {
-	struct blkif *blkif;
-	struct driver_list_entry **pprev, *next;
-} driver_list_entry_t;
-
-typedef struct fd_list_entry {
-	int cookie;
-	int  tap_fd;
-	struct td_state *s;
-	struct fd_list_entry **pprev, *next;
-} fd_list_entry_t;
-
-int qcow_create(const char *filename, uint64_t total_size,
-		const char *backing_file, int flags);
-
-int qcow2_create(const char *filename, uint64_t total_size,
-		const char *backing_file, int flags);
-#endif /*TAPDISK_H_*/
diff --git a/tools/blktap/lib/Makefile b/tools/blktap/lib/Makefile
deleted file mode 100644
index 8852c46..0000000
--- a/tools/blktap/lib/Makefile
+++ /dev/null
@@ -1,60 +0,0 @@
-XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-MAJOR    = 3.0
-MINOR    = 0
-SONAME   = libblktap.so.$(MAJOR)
-
-CFLAGS   += -I.
-CFLAGS   += $(CFLAGS_libxenctrl)
-CFLAGS   += $(CFLAGS_libxenstore)
-LDLIBS   += $(LDLIBS_libxenstore)
-
-SRCS     :=
-SRCS     += xenbus.c blkif.c xs_api.c
-
-CFLAGS   += -Werror
-CFLAGS   += -Wno-unused
-CFLAGS   += -fPIC
-# get asprintf():
-CFLAGS   += -D _GNU_SOURCE
-
-OBJS     = $(SRCS:.c=.o)
-OBJS_PIC = $(SRCS:.c=.opic)
-IBINS   :=
-
-LIB      = libblktap.a
-LIB_SO   = libblktap.so.$(MAJOR).$(MINOR)
-
-.PHONY: all
-all: $(LIB) $(LIB_SO)
-
-.PHONY: install
-install: all
-	$(INSTALL_DIR) $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
-	$(INSTALL_PROG) $(LIB_SO) $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DATA) $(LIB) $(DESTDIR)$(LIBDIR)
-	ln -sf libblktap.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libblktap.so.$(MAJOR)
-	ln -sf libblktap.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libblktap.so
-	$(INSTALL_DATA) blktaplib.h $(DESTDIR)$(INCLUDEDIR)
-
-.PHONY: clean
-clean:
-	rm -rf *.a *.so* *.o *.opic *.rpm $(LIB) $(LIB_SO) *~ $(DEPS) xen TAGS
-
-libblktap.so.$(MAJOR).$(MINOR): $(OBJS_PIC) 
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,$(SONAME) $(SHLIB_LDFLAGS) \
-	      -o $@ $^ $(LDLIBS)
-	ln -sf libblktap.so.$(MAJOR).$(MINOR) libblktap.so.$(MAJOR)
-	ln -sf libblktap.so.$(MAJOR) libblktap.so
-
-libblktap.a: $(OBJS) 
-	$(AR) rc $@ $^
-
-.PHONY: TAGS
-TAGS:
-	etags -t $(SRCS) *.h
-
--include $(DEPS)
-
diff --git a/tools/blktap/lib/blkif.c b/tools/blktap/lib/blkif.c
deleted file mode 100644
index 9a19596..0000000
--- a/tools/blktap/lib/blkif.c
+++ /dev/null
@@ -1,185 +0,0 @@
-/*
- * tools/blktap_user/blkif.c
- * 
- * The blkif interface for blktap.  A blkif describes an in-use virtual disk.
- * (c) 2005 Andrew Warfield and Julian Chesterfield
- *
- * 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 <stdio.h>
-#include <stdlib.h>
-#include <errno.h>
-#include <string.h>
-#include <err.h>
-#include <unistd.h>
-
-#include "blktaplib.h"
-
-#if 0
-#define DPRINTF(_f, _a...) printf ( _f , ## _a )
-#else
-#define DPRINTF(_f, _a...) ((void)0)
-#endif
-
-#define BLKIF_HASHSZ 1024
-#define BLKIF_HASH(_d,_h) (((int)(_d)^(int)(_h))&(BLKIF_HASHSZ-1))
-
-static blkif_t      *blkif_hash[BLKIF_HASHSZ];
-
-blkif_t *blkif_find_by_handle(domid_t domid, unsigned int handle)
-{
-	blkif_t *blkif = blkif_hash[BLKIF_HASH(domid, handle)];
-	while ( (blkif != NULL) && 
-		((blkif->domid != domid) || (blkif->handle != handle)) )
-		blkif = blkif->hash_next;
-	return blkif;
-}
-
-blkif_t *alloc_blkif(domid_t domid)
-{
-	blkif_t *blkif;
-	DPRINTF("Alloc_blkif called [%d]\n",domid);
-	blkif = (blkif_t *)malloc(sizeof(blkif_t));
-	if (!blkif)
-		return NULL;
-	memset(blkif, 0, sizeof(*blkif));
-	blkif->domid = domid;
-	blkif->devnum = -1;
-	return blkif;
-}
-
-/*Controller callbacks*/
-static int (*new_devmap_hook)(blkif_t *blkif) = NULL;
-void register_new_devmap_hook(int (*fn)(blkif_t *blkif))
-{
-	new_devmap_hook = fn;
-}
-
-static int (*new_unmap_hook)(blkif_t *blkif) = NULL;
-void register_new_unmap_hook(int (*fn)(blkif_t *blkif))
-{
-	new_unmap_hook = fn;
-}
-
-static int (*new_blkif_hook)(blkif_t *blkif) = NULL;
-void register_new_blkif_hook(int (*fn)(blkif_t *blkif))
-{
-	new_blkif_hook = fn;
-}
-
-int blkif_init(blkif_t *blkif, long int handle, long int pdev, 
-               long int readonly)
-{
-	domid_t domid;
-	blkif_t **pblkif;
-	int devnum;
-	
-	if (blkif == NULL)
-		return -EINVAL;
-	
-	domid = blkif->domid;
-	blkif->handle   = handle;
-	blkif->pdev     = pdev;
-	blkif->readonly = readonly;
-	
-	/*
-	 * Call out to the new_blkif_hook. 
-	 * The tap application should define this,
-	 * and it should return having set blkif->ops
-	 * 
-	 */
-	if (new_blkif_hook == NULL)
-	{
-		DPRINTF("Probe detected a new blkif, but no new_blkif_hook!");
-		return -1;
-	}
-	if (new_blkif_hook(blkif)!=0) {
-		DPRINTF("BLKIF: Image open failed\n");
-		return -1;
-	}
-	
-	/* Now wire it in. */
-	pblkif = &blkif_hash[BLKIF_HASH(domid, handle)];
-	DPRINTF("Created hash entry: %d [%d,%ld]\n", 
-		BLKIF_HASH(domid, handle), domid, handle);
-	
-	while ( *pblkif != NULL )
-	{
-		if ( ((*pblkif)->domid == domid) && 
-		     ((*pblkif)->handle == handle) )
-		{
-			DPRINTF("Could not create blkif: already exists\n");
-			return -1;
-		}
-		pblkif = &(*pblkif)->hash_next;
-	}
-	blkif->hash_next = NULL;
-	*pblkif = blkif;
-	
-	if (new_devmap_hook == NULL)
-	{
-		DPRINTF("Probe setting up new blkif but no devmap hook!");
-		return -1;
-	}
-	
-	devnum = new_devmap_hook(blkif);
-	if (devnum == -1)
-		return -1;
-	blkif->devnum = devnum;
-	
-	return 0;
-}
-
-void free_blkif(blkif_t *blkif)
-{
-	blkif_t **pblkif, *curs;
-	image_t *image;
-	
-	pblkif = &blkif_hash[BLKIF_HASH(blkif->domid, blkif->handle)];
-	while ( (curs = *pblkif) != NULL )
-	{
-		if ( blkif == curs )
-		{
-			*pblkif = curs->hash_next;
-		}
-		pblkif = &curs->hash_next;
-	}
-	if (blkif != NULL) {
-		if ((image=(image_t *)blkif->prv)!=NULL) {
-			free(blkif->prv);
-		}
-		if (blkif->info!=NULL) {
-			free(blkif->info);
-		}
-		if (new_unmap_hook != NULL) new_unmap_hook(blkif);
-		free(blkif);
-	}
-}
-
-void __init_blkif(void)
-{    
-	memset(blkif_hash, 0, sizeof(blkif_hash));
-}
diff --git a/tools/blktap/lib/blktaplib.h b/tools/blktap/lib/blktaplib.h
deleted file mode 100644
index a80e518..0000000
--- a/tools/blktap/lib/blktaplib.h
+++ /dev/null
@@ -1,240 +0,0 @@
-/* blktaplib.h
- *
- * Blktap library userspace code.
- *
- * (c) 2005 Andrew Warfield and Julian Chesterfield
- *
- * 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 __BLKTAPLIB_H__
-#define __BLKTAPLIB_H__
-
-#include <xenctrl.h>
-#include <sys/param.h>
-#include <sys/user.h>
-#include <xen/xen.h>
-#include <xen/io/blkif.h>
-#include <xen/io/ring.h>
-#include <xenstore.h>
-#include <sys/types.h>
-#include <unistd.h>
-
-#define BLK_RING_SIZE __CONST_RING_SIZE(blkif, XC_PAGE_SIZE)
-
-/* size of the extra VMA area to map in attached pages. */
-#define BLKTAP_VMA_PAGES BLK_RING_SIZE
-
-/* blktap IOCTLs: These must correspond with the blktap driver ioctls*/
-#define BLKTAP_IOCTL_KICK_FE         1
-#define BLKTAP_IOCTL_KICK_BE         2
-#define BLKTAP_IOCTL_SETMODE         3
-#define BLKTAP_IOCTL_SENDPID	     4
-#define BLKTAP_IOCTL_NEWINTF	     5
-#define BLKTAP_IOCTL_MINOR	     6
-#define BLKTAP_IOCTL_MAJOR	     7
-#define BLKTAP_QUERY_ALLOC_REQS      8
-#define BLKTAP_IOCTL_FREEINTF	     9
-#define BLKTAP_IOCTL_NEWINTF_EXT     50
-#define BLKTAP_IOCTL_PRINT_IDXS      100   
-
-/* blktap switching modes: (Set with BLKTAP_IOCTL_SETMODE)             */
-#define BLKTAP_MODE_PASSTHROUGH      0x00000000  /* default            */
-#define BLKTAP_MODE_INTERCEPT_FE     0x00000001
-#define BLKTAP_MODE_INTERCEPT_BE     0x00000002
-
-#define BLKTAP_MODE_INTERPOSE \
-           (BLKTAP_MODE_INTERCEPT_FE | BLKTAP_MODE_INTERCEPT_BE)
-
-static inline int BLKTAP_MODE_VALID(unsigned long arg)
-{
-	return (
-		( arg == BLKTAP_MODE_PASSTHROUGH  ) ||
-		( arg == BLKTAP_MODE_INTERCEPT_FE ) ||
-		( arg == BLKTAP_MODE_INTERPOSE    ) );
-}
-
-#define MAX_REQUESTS            BLK_RING_SIZE
-
-#define BLKTAP_IOCTL_KICK 1
-#define MAX_PENDING_REQS	BLK_RING_SIZE
-#define BLKTAP_DEV_DIR   "/dev/xen"
-#define BLKTAP_DEV_NAME  "blktap"
-#define BLKTAP_DEV_MINOR 0
-#define BLKTAP_CTRL_DIR   "/var/run/tap"
-
-extern int blktap_major;
-
-#define BLKTAP_RING_PAGES       1 /* Front */
-#define BLKTAP_MMAP_REGION_SIZE (BLKTAP_RING_PAGES + MMAP_PAGES)
-
-struct blkif;
-
-typedef struct {
-	blkif_request_t  req;
-	struct blkif    *blkif;
-	int              submitting;
-	int              secs_pending;
-        int16_t          status;
-} pending_req_t;
-
-struct blkif_ops {
-	unsigned long long (*get_size)(struct blkif *blkif);
-	unsigned long (*get_secsize)(struct blkif *blkif);
-	unsigned int (*get_info)(struct blkif *blkif);
-};
-
-typedef struct blkif {
-	domid_t domid;
-	long int handle;
-	
-	long int pdev;
-	long int readonly;
-	
-	enum { DISCONNECTED, DISCONNECTING, CONNECTED } state;
-	
-	struct blkif_ops *ops;
-	struct blkif *hash_next;
-	
-	void *prv;  /* device-specific data */
-	void *info; /*Image parameter passing */
-	pending_req_t pending_list[MAX_REQUESTS];
-	int devnum;
-	int fds[2];
-	int be_id;
-	int major;
-	int minor;
-	pid_t tappid;
-	int drivertype;
-	uint16_t cookie;
-} blkif_t;
-
-typedef struct blkif_info {
-	char *params;
-} blkif_info_t;
-
-void register_new_devmap_hook(int (*fn)(blkif_t *blkif));
-void register_new_unmap_hook(int (*fn)(blkif_t *blkif));
-void register_new_blkif_hook(int (*fn)(blkif_t *blkif));
-blkif_t *blkif_find_by_handle(domid_t domid, unsigned int handle);
-blkif_t *alloc_blkif(domid_t domid);
-int blkif_init(blkif_t *blkif, long int handle, long int pdev, 
-               long int readonly);
-void free_blkif(blkif_t *blkif);
-void __init_blkif(void);
-
-typedef struct busy_state {
-	int seg_idx;
-	blkif_request_t *req;
-} busy_state_t;
-
-typedef struct tapdev_info {
-	int fd;
-	char *mem;
-	blkif_sring_t *sring;
-	blkif_back_ring_t  fe_ring;
-	unsigned long vstart;
-	blkif_t *blkif;
-	busy_state_t busy;
-} tapdev_info_t;
-
-typedef struct domid_translate {
-	unsigned short domid;
-	unsigned short busid;
-} domid_translate_t ;
-
-typedef struct domid_translate_ext {
-	unsigned short domid;
-	uint32_t busid;
-} domid_translate_ext_t ;
-
-typedef struct image {
-	unsigned long long size;
-	unsigned long secsize;
-	unsigned int info;
-} image_t;
-
-/* 16-byte message header, immediately followed by message payload. */
-typedef struct msg_hdr {
-	uint16_t   type;
-	uint16_t   len;
-	uint16_t   drivertype;
-	uint16_t   cookie;
-	uint8_t    readonly;
-	uint8_t    pad[7];
-} msg_hdr_t;
-
-typedef struct msg_newdev {
-	uint8_t     devnum;
-	uint16_t    domid;
-} msg_newdev_t;
-
-typedef struct msg_pid {
-	pid_t     pid;
-} msg_pid_t;
-
-#define READ 0
-#define WRITE 1
-
-/*Control Messages between manager and tapdev*/
-#define CTLMSG_PARAMS      1
-#define CTLMSG_IMG         2
-#define CTLMSG_IMG_FAIL    3
-#define CTLMSG_NEWDEV      4
-#define CTLMSG_NEWDEV_RSP  5
-#define CTLMSG_NEWDEV_FAIL 6
-#define CTLMSG_CLOSE       7
-#define CTLMSG_CLOSE_RSP   8
-#define CTLMSG_PID         9
-#define CTLMSG_PID_RSP     10
-
-/* disk driver types */
-#define MAX_DISK_TYPES     20
-
-#define DISK_TYPE_AIO      0
-#define DISK_TYPE_SYNC     1
-#define DISK_TYPE_VMDK     2
-#define DISK_TYPE_RAM      3
-#define DISK_TYPE_QCOW     4
-#define DISK_TYPE_QCOW2    5
-
-/* xenstore/xenbus: */
-#define DOMNAME "Domain-0"
-int setup_probe_watch(struct xs_handle *h);
-
-
-/* Abitrary values, must match the underlying driver... */
-#define MAX_TAP_DEV 100
-
-/* Accessing attached data page mappings */
-#define MMAP_PAGES                                              \
-    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
-#define MMAP_VADDR(_vstart,_req,_seg)                                   \
-    ((_vstart) +                                              \
-     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +    \
-     ((_seg) * getpagesize()))
-
-
-#endif /* __BLKTAPLIB_H__ */
diff --git a/tools/blktap/lib/list.h b/tools/blktap/lib/list.h
deleted file mode 100644
index c82242f..0000000
--- a/tools/blktap/lib/list.h
+++ /dev/null
@@ -1,59 +0,0 @@
-/*
- * list.h
- * 
- * This is a subset of linux's list.h intended to be used in user-space.
- * 
- */
-
-#ifndef __LIST_H__
-#define __LIST_H__
-
-#ifdef LIST_HEAD
-#undef LIST_HEAD
-#endif
-
-#define LIST_POISON1  ((void *) 0x00100100)
-#define LIST_POISON2  ((void *) 0x00200200)
-
-struct list_head {
-        struct list_head *next, *prev;
-};
- 
-#define LIST_HEAD_INIT(name) { &(name), &(name) }
- 
-#define LIST_HEAD(name) \
-        struct list_head name = LIST_HEAD_INIT(name)
-
-static inline void __list_add(struct list_head *new,
-                              struct list_head *prev,
-                              struct list_head *next)
-{
-        next->prev = new;
-        new->next = next;
-        new->prev = prev;
-        prev->next = new;
-}
-
-static inline void list_add(struct list_head *new, struct list_head *head)
-{
-        __list_add(new, head, head->next);
-}
-static inline void __list_del(struct list_head * prev, struct list_head * next)
-{
-        next->prev = prev;
-        prev->next = next;
-}
-static inline void list_del(struct list_head *entry)
-{
-        __list_del(entry->prev, entry->next);
-        entry->next = LIST_POISON1;
-        entry->prev = LIST_POISON2;
-}
-#define list_entry(ptr, type, member)                                   \
-        ((type *)((char *)(ptr)-(unsigned long)(&((type *)0)->member)))
-#define list_for_each_entry(pos, head, member)                          \
-        for (pos = list_entry((head)->next, typeof(*pos), member);      \
-             &pos->member != (head);                                    \
-             pos = list_entry(pos->member.next, typeof(*pos), member))
-
-#endif /* __LIST_H__ */
diff --git a/tools/blktap/lib/xenbus.c b/tools/blktap/lib/xenbus.c
deleted file mode 100644
index 948eb02..0000000
--- a/tools/blktap/lib/xenbus.c
+++ /dev/null
@@ -1,617 +0,0 @@
-/*
- * xenbus.c
- * 
- * xenbus interface to the blocktap.
- * 
- * this handles the top-half of integration with block devices through the
- * store -- the tap driver negotiates the device channel etc, while the
- * userland tap client needs to sort out the disk parameters etc.
- * 
- * (c) 2005 Andrew Warfield and Julian Chesterfield
- *
- *
- * 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 <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <err.h>
-#include <stdarg.h>
-#include <errno.h>
-#include <xenstore.h>
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#include <poll.h>
-#include <time.h>
-#include <sys/time.h>
-#include <unistd.h>
-#include "blktaplib.h"
-#include "list.h"
-#include "xs_api.h"
-
-#if 0
-#define DPRINTF(_f, _a...) printf ( _f , ## _a )
-#else
-#define DPRINTF(_f, _a...) ((void)0)
-#endif
-
-struct backend_info
-{
-	/* our communications channel */
-	blkif_t *blkif;
-	
-	long int frontend_id;
-	long int pdev;
-	long int readonly;
-	
-	char *backpath;
-	char *frontpath;
-	
-	struct list_head list;
-};
-
-static LIST_HEAD(belist);
-
-static int strsep_len(const char *str, char c, unsigned int len)
-{
-	unsigned int i;
-	
-	for (i = 0; str[i]; i++)
-		if (str[i] == c) {
-			if (len == 0)
-				return i;
-			len--;
-		}
-	return (len == 0) ? i : -ERANGE;
-}
-
-static int get_be_id(const char *str)
-{
-	int len,end;
-	const char *ptr;
-	char *tptr, num[10];
-	
-	len = strsep_len(str, '/', 6);
-	end = strlen(str);
-	if( (len < 0) || (end < 0) ) return -1;
-	
-	ptr = str + len + 1;
-	strncpy(num, ptr, end - len);
-	tptr = num + (end - (len + 1));
-	*tptr = '\0';
-
-	return atoi(num);
-}
-
-static int get_be_domid(const char *str)
-{
-	int len1, len2;
-	const char *ptr;
-	char *tptr, num[10];
-
-	len2 = strsep_len(str, '/', 3);
-	if ( len2 < 0 ) return -1;
-	len1 = strsep_len(str, '/', 2);
-
-	ptr = str + len1 + 1;
-	strncpy(num, ptr, len2 - len1 - 1);
-	tptr = num + (len2 - len1 - 1);
-	*tptr = '\0';
-
-	return atoi(num);
-}
-
-static struct backend_info *be_lookup_be(const char *bepath)
-{
-	struct backend_info *be;
-	
-	list_for_each_entry(be, &belist, list)
-		if (strcmp(bepath, be->backpath) == 0)
-			return be;
-	return (struct backend_info *)NULL;
-}
-
-static int be_exists_be(const char *bepath)
-{
-	return (be_lookup_be(bepath) != NULL);
-}
-
-static struct backend_info *be_lookup_fe(const char *fepath)
-{
-	struct backend_info *be;
-	
-	list_for_each_entry(be, &belist, list)
-		if (strcmp(fepath, be->frontpath) == 0)
-			return be;
-	return (struct backend_info *)NULL;
-}
-
-static int backend_remove(struct xs_handle *h, struct backend_info *be)
-{
-	/* Unhook from be list. */
-	list_del(&be->list);
-
-	/* Free everything else. */
-	if (be->blkif) {
-		DPRINTF("Freeing blkif dev [%d]\n",be->blkif->devnum);
-		free_blkif(be->blkif);
-	}
-	if (be->frontpath)
-		free(be->frontpath);
-	if (be->backpath)
-		free(be->backpath);
-	free(be);
-	return 0;
-}
-
-static const char *get_image_path(const char *path)
-{
-	const char *tmp;
-
-	/* Strip off the image type */
-	if (!strncmp(path, "tapdisk:", strlen("tapdisk:"))) {
-		path += strlen("tapdisk:");
-	} else if (!strncmp(path, "ioemu:", strlen("ioemu:"))) {
-		path += strlen("ioemu:");
-	}
-
-	tmp = strchr(path, ':');
-	if (tmp != NULL)
-		path = tmp + 1;
-
-	return path;
-}
-
-static int check_sharing(struct xs_handle *h, struct backend_info *be)
-{
-	char *dom_uuid;
-	char *cur_dom_uuid;
-	char *path;
-	char *mode;
-	char *params;
-	char **domains;
-	char **devices;
-	int i, j;
-	unsigned int num_dom, num_dev;
-	blkif_info_t *info = be->blkif->info;
-	int ret = 0;
-	const char *image_path[2];
-	int be_domid = get_be_domid(be->backpath);
-
-	image_path[0] = get_image_path(info->params);
-
-	/* If the mode contains '!' or doesn't contain 'w' don't check anything */
-	xs_gather(h, be->backpath, "mode", NULL, &mode, NULL);
-	if (strchr(mode, '!'))
-		goto out;
-	if (strchr(mode, 'w') == NULL)
-		goto out;
-
-	/* Get the UUID of the domain we want to attach to */
-	if (asprintf(&path, "/local/domain/%ld", be->frontend_id) == -1)
-		goto fail;
-	xs_gather(h, path, "vm", NULL, &dom_uuid, NULL);
-	free(path);
-
-	/* Iterate through the devices of all VMs */
-	if (asprintf(&path, "/local/domain/%d/backend/tap", be_domid) == -1)
-		goto fail;
-	domains = xs_directory(h, XBT_NULL, path, &num_dom);
-	free(path);
-	if (domains == NULL)
-		num_dom = 0;
-
-	for (i = 0; !ret && (i < num_dom); i++) {
-
-		/* If it's the same VM, no action needed */
-		if (asprintf(&path, "/local/domain/%s", domains[i]) == -1) {
-			ret = -1;
-			break;
-		}
-		cur_dom_uuid = NULL;
-		xs_gather(h, path, "vm", NULL, &cur_dom_uuid, NULL);
-		free(path);
-		if (!cur_dom_uuid)
-			continue;
-
-		if (!strcmp(cur_dom_uuid, dom_uuid)) {
-			free(cur_dom_uuid);
-			continue;
-		}
-
-		/* Check the devices */
-		if (asprintf(&path, "/local/domain/%d/backend/tap/%s", be_domid, domains[i]) == -1) {
-			ret = -1;
-			free(cur_dom_uuid);
-			break;
-		}
-		devices = xs_directory(h, XBT_NULL, path, &num_dev);
-		if (devices == NULL)
-			num_dev = 0;
-		free(path);
-
-		for (j = 0; !ret && (j < num_dev); j++) {
-			if (asprintf(&path, "/local/domain/%d/backend/tap/%s/%s", be_domid, domains[i], devices[j]) == -1) {
-				ret = -1;
-				break;
-			}
-			params = NULL;
-			xs_gather(h, path, "params", NULL, &params, NULL);
-			free(path);
-			if (!params)
-				continue;
-
-			image_path[1] = get_image_path(params);
-			if (!strcmp(image_path[0], image_path[1])) {
-				ret = -1;
-			}
-
-			free(params);
-		}
-
-		free(cur_dom_uuid);
-		free(devices);
-	}
-	free(domains);
-	free(dom_uuid);
-	goto out;
-
-fail:
-	ret = -1;
-out:
-	free(mode);
-	return ret;
-}
-
-static int check_image(struct xs_handle *h, struct backend_info *be,
-	const char** errmsg)
-{
-	const char *path;
-	int mode;
-	blkif_t *blkif = be->blkif;
-	blkif_info_t *info = blkif->info;
-
-	path = get_image_path(info->params);
-
-	/* Check if the image exists and access is permitted */
-	mode = R_OK;
-	if (!be->readonly)
-		mode |= W_OK;
-	if (access(path, mode)) {
-		if (errno == ENOENT)
-			*errmsg = "File not found.";
-		else
-			*errmsg = "Insufficient file permissions.";
-		return -1;
-	}
-
-	/* Check that the image is not attached to a different VM */
-	if (check_sharing(h, be)) {
-		*errmsg = "File already in use by other domain";
-		return -1;
-	}
-
-	return 0;
-}
-
-static void ueblktap_setup(struct xs_handle *h, char *bepath)
-{
-	struct backend_info *be;
-	char *path = NULL, *p,*dev;
-	int len, er, deverr;
-	long int pdev = 0, handle;
-	blkif_info_t *blk;
-	const char* errmsg = NULL;
-	
-	be = be_lookup_be(bepath);
-	if (be == NULL)
-	{
-		DPRINTF("ERROR: backend changed called for nonexistent "
-			"backend! (%s)\n", bepath);
-		goto fail;
-	}
-
-	deverr = xs_gather(h, bepath, "physical-device", "%li", &pdev, NULL);
-	if (!deverr) {
-		DPRINTF("pdev set to %ld\n",pdev);
-		if (be->pdev && be->pdev != pdev) {
-			DPRINTF("changing physical-device not supported");
-			goto fail;
-		}
-		be->pdev = pdev;
-	}
-
-	/* Check to see if device is to be opened read-only. */
-	deverr = xs_gather(h, bepath, "mode", NULL, &path, NULL);
-	if (deverr) {
-		DPRINTF("ERROR: could not find read/write mode\n");
-		goto fail;
-	} else if (path[0] == 'r')
-		be->readonly = 1;
-
-	if (be->blkif == NULL) {
-		/* Front end dir is a number, which is used as the handle. */
-		p = strrchr(be->frontpath, '/') + 1;
-		handle = strtoul(p, NULL, 0);
-
-		be->blkif = alloc_blkif(be->frontend_id);
-		if (be->blkif == NULL)
-			goto fail;
-
-		be->blkif->be_id = get_be_id(bepath);
-		
-		/* Insert device specific info, */
-		blk = malloc(sizeof(blkif_info_t));
-		if (!blk) {
-			DPRINTF("Out of memory - blkif_info_t\n");
-			goto fail;
-		}
-		er = xs_gather(h, bepath, "params", NULL, &blk->params, NULL);
-		if (er)
-			goto fail;
-		be->blkif->info = blk;
-		
-		if (deverr) {
-			/*Dev number was not available, try to set manually*/
-			pdev = convert_dev_name_to_num(blk->params);
-			be->pdev = pdev;
-		}
-
-		if (check_image(h, be, &errmsg))
-			goto fail;
-
-		er = blkif_init(be->blkif, handle, be->pdev, be->readonly);
-		if (er != 0) {
-			DPRINTF("Unable to open device %s\n",blk->params);
-			goto fail;
-		}
-
-		DPRINTF("[BECHG]: ADDED A NEW BLKIF (%s)\n", bepath);
-	}
-
-	/* Supply the information about the device to xenstore */
-	er = xs_printf(h, be->backpath, "sectors", "%llu",
-			be->blkif->ops->get_size(be->blkif));
-
-	if (er == 0) {
-		DPRINTF("ERROR: Failed writing sectors");
-		goto fail;
-	}
-
-	er = xs_printf(h, be->backpath, "sector-size", "%lu",
-			be->blkif->ops->get_secsize(be->blkif));
-
-	if (er == 0) {
-		DPRINTF("ERROR: Failed writing sector-size");
-		goto fail;
-	}
-
-	er = xs_printf(h, be->backpath, "info", "%u",
-			be->blkif->ops->get_info(be->blkif));
-
-	if (er == 0) {
-		DPRINTF("ERROR: Failed writing info");
-		goto fail;
-	}
-
-	be->blkif->state = CONNECTED;
-	xs_printf(h, be->backpath, "hotplug-status", "connected");
-
-	DPRINTF("[SETUP] Complete\n\n");
-	goto close;
-	
-fail:
-	if (be) {
-		if (errmsg == NULL)
-			errmsg = "Setting up the backend failed. See the log "
-				"files in /var/log/xen/ for details.";
-		xs_printf(h, be->backpath, "hotplug-error", errmsg);
-		xs_printf(h, be->backpath, "hotplug-status", "error");
-
-		backend_remove(h, be);
-	}
-close:
-	if (path)
-		free(path);
-	return;
-}
-
-/**
- * Xenstore watch callback entry point. This code replaces the hotplug scripts,
- * and as soon as the xenstore backend driver entries are created, this script
- * gets called.
- */
-static void ueblktap_probe(struct xs_handle *h, struct xenbus_watch *w, 
-			   const char *bepath_im)
-{
-	struct backend_info *be = NULL;
-	char *frontend = NULL, *bepath = NULL, *p;
-	int er, len;
-	blkif_t *blkif;
-	
-	
-	bepath = strdup(bepath_im);
-	
-	if (!bepath) {
-		DPRINTF("No path\n");
-		return;
-	}
-	
-	/*
-	 *asserts that xenstore structure is always 7 levels deep
-	 *e.g. /local/domain/0/backend/vbd/1/2049
-	 */
-	len = strsep_len(bepath, '/', 7);
-	if (len < 0) 
-		goto free_be;
-	if (bepath[len] != '\0')
-		goto free_be;
-	
-	be = malloc(sizeof(*be));
-	if (!be) {
-		DPRINTF("ERROR: allocating backend structure\n");
-		goto free_be;
-	}
-	memset(be, 0, sizeof(*be));
-	frontend = NULL;
-
-	er = xs_gather(h, bepath,
-		       "frontend-id", "%li", &be->frontend_id,
-		       "frontend", NULL, &frontend,
-		       NULL);
-
-	if (er) {
-		/*
-		 *Unable to find frontend entries, 
-		 *bus-id is no longer valid
-		 */
-		DPRINTF("ERROR: Frontend-id check failed, removing backend: "
-			"[%s]\n",bepath);
-
-		/**
-		 * BE info should already exist, 
-		 * free new mem and find old entry
-		 */
-		free(be);
-		be = be_lookup_be(bepath);
-		if ( (be != NULL) && (be->blkif != NULL) ) 
-			backend_remove(h, be);
-		else goto free_be;
-		if (bepath)
-			free(bepath);
-		return;
-	}
-	
-	/* Are we already tracking this device? */
-	if (be_exists_be(bepath))
-		goto free_be;
-	
-	be->backpath = bepath;
-	be->frontpath = frontend;
-	
-	list_add(&be->list, &belist);
-	
-	DPRINTF("[PROBE]\tADDED NEW DEVICE (%s)\n", bepath);
-	DPRINTF("\tFRONTEND (%s),(%ld)\n", frontend,be->frontend_id);
-	
-	ueblktap_setup(h, bepath);	
-	return;
-	
- free_be:
-	if (frontend)
-		free(frontend);
-	if (bepath)
-		free(bepath);
-	if (be) 
-		free(be);
-}
-
-/**
- *We set a general watch on the backend vbd directory
- *ueblktap_probe is called for every update
- *Our job is to monitor for new entries. As they 
- *are created, we initalise the state and attach a disk.
- */
-
-static int add_blockdevice_probe_watch(struct xs_handle *h, const char *domid)
-{
-	char *path;
-	struct xenbus_watch *vbd_watch;
-	
-	if (asprintf(&path, "/local/domain/%s/backend/tap", domid) == -1)
-		return -ENOMEM;
-	
-	vbd_watch = (struct xenbus_watch *)malloc(sizeof(struct xenbus_watch));
-	if (!vbd_watch) {
-		DPRINTF("ERROR: unable to malloc vbd_watch [%s]\n", path);
-		return -EINVAL;
-	}	
-	vbd_watch->node     = path;
-	vbd_watch->callback = ueblktap_probe;
-	if (register_xenbus_watch(h, vbd_watch) != 0) {
-		DPRINTF("ERROR: adding vbd probe watch %s\n", path);
-		return -EINVAL;
-	}
-	return 0;
-}
-
-/* Asynch callback to check for /local/domain/<DOMID>/name */
-static void check_dom(struct xs_handle *h, struct xenbus_watch *w, 
-	       const char *bepath_im)
-{
-	char *domid;
-
-	domid = get_dom_domid(h);
-	if (domid == NULL)
-		return;
-
-	add_blockdevice_probe_watch(h, domid);
-	free(domid);
-	unregister_xenbus_watch(h, w);
-}
-
-/* We must wait for xend to register /local/domain/<DOMID> */
-static int watch_for_domid(struct xs_handle *h)
-{
-	struct xenbus_watch *domid_watch;
-	char *path = NULL;
-
-	if (asprintf(&path, "/local/domain") == -1)
-		return -ENOMEM;
-
-	domid_watch = malloc(sizeof(struct xenbus_watch));
-	if (domid_watch == NULL) {
-		DPRINTF("ERROR: unable to malloc domid_watch [%s]\n", path);
-		return -EINVAL;
-	}	
-
-	domid_watch->node     = path;
-	domid_watch->callback = check_dom;
-
-	if (register_xenbus_watch(h, domid_watch) != 0) {
-		DPRINTF("ERROR: adding vbd probe watch %s\n", path);
-		return -EINVAL;
-	}
-
-	DPRINTF("Set async watch for /local/domain\n");
-
-	return 0;
-}
-
-int setup_probe_watch(struct xs_handle *h)
-{
-	char *domid;
-	int ret;
-	
-	domid = get_dom_domid(h);
-	if (domid == NULL)
-		return watch_for_domid(h);
-
-	ret = add_blockdevice_probe_watch(h, domid);
-	free(domid);
-	return ret;
-}
diff --git a/tools/blktap/lib/xs_api.c b/tools/blktap/lib/xs_api.c
deleted file mode 100644
index 4648432..0000000
--- a/tools/blktap/lib/xs_api.c
+++ /dev/null
@@ -1,360 +0,0 @@
-/*
- * xs_api.c
- * 
- * blocktap interface functions to xenstore
- *
- * (c) 2005 Andrew Warfield and Julian Chesterfield
- *
- *
- * 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 <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <err.h>
-#include <stdarg.h>
-#include <errno.h>
-#include <xenstore.h>
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#include <poll.h>
-#include "blktaplib.h"
-#include "list.h"
-#include "xs_api.h"
-
-#if 0
-#define DPRINTF(_f, _a...) printf ( _f , ## _a )
-#else
-#define DPRINTF(_f, _a...) ((void)0)
-#endif
-
-static LIST_HEAD(watches);
-#define BASE_DEV_VAL 2048
-
-int xs_gather(struct xs_handle *xs, const char *dir, ...)
-{
-	va_list ap;
-	const char *name;
-	char *path, **e;
-	int ret = 0, num,i;
-	unsigned int len;
-	xs_transaction_t xth;
-
-again:
-	if ( (xth = xs_transaction_start(xs)) == XBT_NULL) {
-		DPRINTF("unable to start xs trasanction\n");
-		ret = ENOMEM;
-		return ret;
-	}
-	
-	va_start(ap, dir);
-	while ( (ret == 0) && (name = va_arg(ap, char *)) != NULL) {
-		const char *fmt = va_arg(ap, char *);
-		void *result = va_arg(ap, void *);
-		char *p;
-		
-		if (asprintf(&path, "%s/%s", dir, name) == -1)
-		{
-			printf("allocation error in xs_gather!\n");
-			ret = ENOMEM;
-			break;
-		}
-		
-		p = xs_read(xs, xth, path, &len);
-		
-		
-		free(path);
-		if (p == NULL) {
-			ret = ENOENT;
-			break;
-		}
-		if (fmt) {
-			if (sscanf(p, fmt, result) == 0)
-				ret = EINVAL;
-			free(p);
-		} else
-			*(char **)result = p;
-	}
-	va_end(ap);
-
-	if (!xs_transaction_end(xs, xth, ret)) {
-		if (ret == 0 && errno == EAGAIN)
-			goto again;
-		else
-			ret = errno;
-	}
-
-	return ret;
-}
-
-
-/* Single printf and write: returns -errno or 0. */
-int xs_printf(struct xs_handle *h, const char *dir, const char *node, 
-	      const char *fmt, ...)
-{
-	char *buf, *path;
-	va_list ap;
-	int ret;
-	
-	va_start(ap, fmt);
-	ret = vasprintf(&buf, fmt, ap);
-	va_end(ap);
-	
-	if (ret == -1)
-		return ENOMEM;
-	if (asprintf(&path, "%s/%s", dir, node) == -1) {
-		free(buf);
-		return ENOMEM;
-	}
-
-	ret = xs_write(h, XBT_NULL, path, buf, strlen(buf));
-	
-	free(buf);
-	free(path);
-	
-	return ret;
-}
-
-
-int xs_exists(struct xs_handle *h, const char *path)
-{
-	char **d;
-	unsigned int num;
-	xs_transaction_t xth;
-	
-	if ( (xth = xs_transaction_start(h)) == XBT_NULL) {
-		printf("unable to start xs trasanction\n");
-		return 0;
-	}	
-	
-	d = xs_directory(h, xth, path, &num);
-	xs_transaction_end(h, xth, 0);
-	if (d == NULL)
-		return 0;
-	free(d);
-	return 1;
-}
-
-
-
-/**
- * This assumes that the domain name we are looking for is unique. 
- * Name parameter Domain-0 
- */
-char *get_dom_domid(struct xs_handle *h)
-{
-	char **e, *val, *domid = NULL;
-	unsigned int num, len;
-	int i;
-	char *path;
-	xs_transaction_t xth;
-	
-	if ( (xth = xs_transaction_start(h)) == XBT_NULL) {
-		warn("unable to start xs trasanction\n");
-		return NULL;
-	}
-	
-	e = xs_directory(h, xth, "/local/domain", &num);
-	if (e == NULL)
-		goto done;
-
-	for (i = 0; (i < num) && (domid == NULL); i++) {
-		if (asprintf(&path, "/local/domain/%s/name", e[i]) == -1)
-			break;
-		val = xs_read(h, xth, path, &len);
-		free(path);
-		if (val == NULL)
-			continue;
-		
-		if (strcmp(val, DOMNAME) == 0) {
-			/* match! */
-			if (asprintf(&path, "/local/domain/%s/domid", e[i]) == -1) {
-				free(val);
-				break;
-			}
-			domid = xs_read(h, xth, path, &len);
-			free(path);
-		}
-		free(val);
-	}
-done:
-	xs_transaction_end(h, xth, 0);
-	if (e)
-		free(e);
-	return domid;
-}
-
-int convert_dev_name_to_num(char *name) {
-	char *p, *ptr;
-	int majors[10] = {3,22,33,34,56,57,88,89,90,91};
-	int maj,i,ret = 0;
-	char *p_sd = "/dev/sd";
-	char *p_hd = "/dev/hd";
-	char *p_xvd = "/dev/xvd";
-	char *p_plx = "plx";
-	char *alpha = "abcdefghijklmnop";
-
-	if (strstr(name, p_sd) != NULL) {
-		p = name + strlen(p_sd);
-		for(i = 0, ptr = alpha; i < strlen(alpha); i++) {
-			if(*ptr == *p)
-				break;
-			*ptr++;
-		}
-		*p++;
-		ret = BASE_DEV_VAL + (16*i) + atoi(p);
-	} else if (strstr(name, p_hd) != NULL) {
-		p = name + strlen(p_hd);
-		for (i = 0, ptr = alpha; i < strlen(alpha); i++) {
-			if(*ptr == *p) break;
-			*ptr++;
-		}
-		*p++;
-		ret = (majors[i/2]*256) + atoi(p);
-
-	} else if (strstr(name, p_xvd) != NULL) {
-		p = name + strlen(p_xvd);
-		for(i = 0, ptr = alpha; i < strlen(alpha); i++) {
-			if(*ptr == *p) break;
-			*ptr++;
-		}
-		*p++;
-		ret = (202*256) + (16*i) + atoi(p);
-
-	} else if (strstr(name, p_plx) != NULL) {
-		p = name + strlen(p_plx);
-		ret = atoi(p);
-
-	} else {
-		DPRINTF("Unknown device type, setting to default.\n");
-		ret = BASE_DEV_VAL;
-	}
-
-	return ret;
-}
-
-/**
- * A little paranoia: we don't just trust token. 
- */
-static struct xenbus_watch *find_watch(const char *token)
-{
-	struct xenbus_watch *i, *cmp;
-	
-	cmp = (void *)strtoul(token, NULL, 16);
-	
-	list_for_each_entry(i, &watches, list)
-		if (i == cmp)
-			return i;
-	return NULL;
-}
-
-/**
- * Register callback to watch this node. 
- * like xs_watch, return 0 on failure 
- */
-int register_xenbus_watch(struct xs_handle *h, struct xenbus_watch *watch)
-{
-	/* Pointer in ascii is the token. */
-	char token[sizeof(watch) * 2 + 1];
-
-	snprintf(token, sizeof(token), "%lX", (long)watch);
-	if (find_watch(token)) {
-		DPRINTF("watch collision!\n");
-		return -EINVAL;
-	}
-	
-	if (!xs_watch(h, watch->node, token)) {
-		DPRINTF("unable to set watch!\n");
-		return -EINVAL;
-	}
-
-	list_add(&watch->list, &watches);
-
-	return 0;
-}
-
-int unregister_xenbus_watch(struct xs_handle *h, struct xenbus_watch *watch)
-{
-	char token[sizeof(watch) * 2 + 1];
-	
-	snprintf(token, sizeof(token), "%lX", (long)watch);
-	if (!find_watch(token)) {
-		DPRINTF("no such watch!\n");
-		return -EINVAL;
-	}
-
-	if (!xs_unwatch(h, watch->node, token))
-		DPRINTF("XENBUS Failed to release watch %s\n",
-			watch->node);
-
-	list_del(&watch->list);
-	
-	return 0;
-}
-
-/**
- * Re-register callbacks to all watches. 
- */
-void reregister_xenbus_watches(struct xs_handle *h)
-{
-	struct xenbus_watch *watch;
-	char token[sizeof(watch) * 2 + 1];
-	
-	list_for_each_entry(watch, &watches, list) {
-		snprintf(token, sizeof(token), "%lX", (long)watch);
-		xs_watch(h, watch->node, token);
-	}
-}
-
-/**
- * based on watch_thread() 
- */
-int xs_fire_next_watch(struct xs_handle *h)
-{
-	char **res;
-	char *token;
-	char *node = NULL;
-	struct xenbus_watch *w;
-	int er;
-	unsigned int num;
-	
-	res = xs_read_watch(h, &num);
-	if (res == NULL) 
-		return -EAGAIN; /* in O_NONBLOCK, read_watch returns 0... */
-	
-	node  = res[XS_WATCH_PATH];
-	token = res[XS_WATCH_TOKEN];
-
-	w = find_watch(token);
-	if (w) 
-		w->callback(h, w, node);
-
-	free(res);
-
-	return 1;
-}
diff --git a/tools/blktap/lib/xs_api.h b/tools/blktap/lib/xs_api.h
deleted file mode 100644
index 34430dc..0000000
--- a/tools/blktap/lib/xs_api.h
+++ /dev/null
@@ -1,50 +0,0 @@
-/*
- * xs_api.h
- *
- * (c) 2005 Andrew Warfield and Julian Chesterfield
- *
- *
- * 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.
- */
-
-struct xenbus_watch
-{
-        struct list_head list;
-        char *node;
-        void (*callback)(struct xs_handle *h, 
-                         struct xenbus_watch *, 
-                         const  char *node);
-};
-
-int xs_gather(struct xs_handle *xs, const char *dir, ...);
-int xs_printf(struct xs_handle *h, const char *dir, const char *node, 
-	      const char *fmt, ...);
-int xs_exists(struct xs_handle *h, const char *path);
-char *get_dom_domid(struct xs_handle *h);
-int convert_dev_name_to_num(char *name);
-int register_xenbus_watch(struct xs_handle *h, struct xenbus_watch *watch);
-int unregister_xenbus_watch(struct xs_handle *h, struct xenbus_watch *watch);
-void reregister_xenbus_watches(struct xs_handle *h);
-int xs_fire_next_watch(struct xs_handle *h);
diff --git a/tools/configure b/tools/configure
index c65ad3a..b1261a1 100755
--- a/tools/configure
+++ b/tools/configure
@@ -700,7 +700,6 @@ rombios
 qemu_traditional
 blktap2
 LINUX_BACKEND_MODULES
-blktap1
 debug
 seabios
 ovmf
@@ -790,7 +789,6 @@ enable_xsmpolicy
 enable_ovmf
 enable_seabios
 enable_debug
-enable_blktap1
 with_linux_backend_modules
 enable_blktap2
 enable_qemu_traditional
@@ -1463,7 +1461,6 @@ Optional Features:
   --enable-ovmf           Enable OVMF (default is DISABLED)
   --disable-seabios       Disable SeaBIOS (default is ENABLED)
   --disable-debug         Disable debug build of tools (default is ENABLED)
-  --enable-blktap1        Enable blktap1 tools (default is DISABLED)
   --enable-blktap2        Enable blktap2, (DEFAULT is on for Linux, otherwise
                           off)
   --enable-qemu-traditional
@@ -3991,29 +3988,6 @@ debug=$ax_cv_debug
 
 
 
-# Check whether --enable-blktap1 was given.
-if test "${enable_blktap1+set}" = set; then :
-  enableval=$enable_blktap1;
-fi
-
-
-if test "x$enable_blktap1" = "xno"; then :
-
-    ax_cv_blktap1="n"
-
-elif test "x$enable_blktap1" = "xyes"; then :
-
-    ax_cv_blktap1="y"
-
-elif test -z $ax_cv_blktap1; then :
-
-    ax_cv_blktap1="n"
-
-fi
-blktap1=$ax_cv_blktap1
-
-
-
 
 # Check whether --with-linux-backend-modules was given.
 if test "${with_linux_backend_modules+set}" = set; then :
@@ -4037,7 +4011,6 @@ usbbk
 pciback
 xen-acpi-processor
 blktap2
-blktap
 "
 ;;
 *)
@@ -7935,7 +7908,7 @@ fi
 
 
 
-if test "x$enable_blktap1" = "xyes" || test "x$enable_blktap2" = "xyes"; then :
+if test "x$enable_blktap2" = "xyes"]; then :
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for io_setup in -laio" >&5
 $as_echo_n "checking for io_setup in -laio... " >&6; }
diff --git a/tools/configure.ac b/tools/configure.ac
index 1ac63a3..72e2465 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -89,7 +89,6 @@ AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
 AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
 AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS])
 AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
-AX_ARG_DEFAULT_DISABLE([blktap1], [Enable blktap1 tools])
 
 AC_ARG_WITH([linux-backend-modules],
     AS_HELP_STRING([--with-linux-backend-modules="mod1 mod2"],
@@ -113,7 +112,6 @@ usbbk
 pciback
 xen-acpi-processor
 blktap2
-blktap
 "
 ;;
 *)
@@ -338,7 +336,7 @@ AC_CHECK_HEADER([lzo/lzo1x.h], [
 AC_CHECK_LIB([lzo2], [lzo1x_decompress], [zlib="$zlib -DHAVE_LZO1X -llzo2"])
 ])
 AC_SUBST(zlib)
-AS_IF([test "x$enable_blktap1" = "xyes" || test "x$enable_blktap2" = "xyes"], [
+AS_IF(test "x$enable_blktap2" = "xyes"], [
 AC_CHECK_LIB([aio], [io_setup], [], [AC_MSG_ERROR([Could not find libaio])])
 ])
 AC_SUBST(system_aio)
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 1706c05..b8490f9 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -19,7 +19,6 @@ XEN_SCRIPTS += vif-setup
 XEN_SCRIPTS-$(CONFIG_REMUS_NETBUF) += remus-netbuf-setup
 XEN_SCRIPTS += block
 XEN_SCRIPTS += block-enbd block-nbd
-XEN_SCRIPTS-$(CONFIG_BLKTAP1) += blktap
 XEN_SCRIPTS += xen-hotplug-cleanup
 XEN_SCRIPTS += external-device-migrate
 XEN_SCRIPTS += vscsi
diff --git a/tools/hotplug/Linux/blktap b/tools/hotplug/Linux/blktap
deleted file mode 100644
index cd30a38..0000000
--- a/tools/hotplug/Linux/blktap
+++ /dev/null
@@ -1,94 +0,0 @@
-#!/bin/bash
-
-# Copyright (c) 2005, XenSource Ltd.
-
-dir=$(dirname "$0")
-. "$dir/xen-hotplug-common.sh"
-. "$dir/block-common.sh"
-
-findCommand "$@"
-
-##
-# check_blktap_sharing file mode
-#
-# Perform the sharing check for the given blktap and mode.
-#
-check_blktap_sharing()
-{
-    local file="$1"
-    local mode="$2"
-
-    local base_path="$XENBUS_BASE_PATH/$XENBUS_TYPE"
-    for dom in $(xenstore-list "$base_path")
-    do
-        for dev in $(xenstore-list "$base_path/$dom")
-        do
-            params=$(xenstore_read_default "$base_path/$dom/$dev/params" "" | cut -d: -f2)
-            if [ "$file" = "$params" ]
-            then
-
-                if [ "$mode" = 'w' ]
-                then
-                    if ! same_vm "$dom" 
-                    then
-                        echo 'guest'
-                        return
-                    fi
-                else 
-                    local m=$(xenstore_read_default "$base_path/$dom/$dev/mode" "")
-                    m=$(canonicalise_mode "$m")
-
-                    if [ "$m" = 'w' ] 
-                    then
-                        if ! same_vm "$dom"
-                        then
-                            echo 'guest'
-                            return
-                        fi
-                    fi
-                fi
-            fi
-        done
-    done
-
-    echo 'ok'
-}
-
-
-t=$(xenstore_read_default "$XENBUS_PATH/type" 'MISSING')
-if [ -n "$t" ]
-then
-    p=$(xenstore_read "$XENBUS_PATH/params")
-    p=${p#tapdisk:}
-    # if we have a ':', chew from head including :
-    if echo $p | grep -q \:
-    then
-        p=${p#*:}
-    fi
-fi
-# some versions of readlink cannot be passed a regular file
-if [ -L "$p" ]; then
-    file=$(readlink -f "$p") || fatal "$p link does not exist."
-else
-    file="$p"
-fi
-
-if [ "$command" = 'add' ]
-then
-    [ -e "$file" ] || { fatal $file does not exist; }
-
-    FRONTEND_ID=$(xenstore_read "$XENBUS_PATH/frontend-id")
-    FRONTEND_UUID=$(xenstore_read "/local/domain/$FRONTEND_ID/vm")
-    mode=$(xenstore_read "$XENBUS_PATH/mode")
-    mode=$(canonicalise_mode "$mode")
-
-    if [ "$mode" != '!' ] 
-    then
-        result=$(check_blktap_sharing "$file" "$mode")
-        [ "$result" = 'ok' ] || ebusy "$file already in use by other domain"
-    fi
-
-    success
-fi
-
-exit 0
diff --git a/tools/hotplug/Linux/xen-backend.rules.in b/tools/hotplug/Linux/xen-backend.rules.in
index 7d2f914..ee107af 100644
--- a/tools/hotplug/Linux/xen-backend.rules.in
+++ b/tools/hotplug/Linux/xen-backend.rules.in
@@ -1,4 +1,3 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{UDEV_CALL}="1", RUN+="@XEN_SCRIPT_DIR@/blktap $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", RUN+="@XEN_SCRIPT_DIR@/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="@XEN_SCRIPT_DIR@/vif2 $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{UDEV_CALL}="1", ACTION=="online", RUN+="@XEN_SCRIPT_DIR@/vif-setup online type_if=vif"
@@ -6,7 +5,6 @@ SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{UDEV_CALL}="1", ACTION=="offline"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="@XEN_SCRIPT_DIR@/vscsi $env{ACTION}"
 SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{UDEV_CALL}="1", RUN+="@XEN_SCRIPT_DIR@/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"
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:53:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlcfS-0001UD-CH; Tue, 04 Nov 2014 11:52:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlcfQ-0001So-7N
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:52:57 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	90/AF-18267-71EB8545; Tue, 04 Nov 2014 11:52:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415101971!7086141!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18024 invoked from network); 4 Nov 2014 11:52:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:52:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187866685"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 06:52:48 -0500
Received: from cosworth.uk.xensource.com	([10.80.16.52]
	helo=localhost.localdomain ident=ianc)	by ukmail1.uk.xensource.com with
	smtp (Exim 4.69)	(envelope-from <ian.campbell@citrix.com>)	id
	1XlcfH-0003gC-3m; Tue, 04 Nov 2014 11:52:48 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Tue, 04 Nov
	2014 11:52:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, <ian.jackson@eu.citrix.com>,
	<wei.liu2@citrix.com>
Date: Tue, 4 Nov 2014 11:52:47 +0000
Message-ID: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This was disabled by default in Xen 4.4. Since xend has now been removed from
the tree I don't believe anything is using it.

We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xen-traditional otherwise
it defaults to y and doesn't build.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
I think this has probably missed the boat for 4.5 and there isn't much harm in
waiting for 4.6. I'm open to being told otherwise though ;-)
---
 .gitignore                               |    5 -
 .hgignore                                |    5 -
 INSTALL                                  |    1 -
 config/Tools.mk.in                       |    1 -
 tools/Makefile                           |    2 +-
 tools/blktap/Makefile                    |   13 -
 tools/blktap/README                      |  122 --
 tools/blktap/drivers/Makefile            |   73 --
 tools/blktap/drivers/aes.c               | 1319 -------------------
 tools/blktap/drivers/aes.h               |   28 -
 tools/blktap/drivers/blk.h               |    3 -
 tools/blktap/drivers/blk_linux.c         |   42 -
 tools/blktap/drivers/blktapctrl.c        |  937 -------------
 tools/blktap/drivers/blktapctrl.h        |   36 -
 tools/blktap/drivers/blktapctrl_linux.c  |   89 --
 tools/blktap/drivers/block-aio.c         |  259 ----
 tools/blktap/drivers/block-qcow.c        | 1434 --------------------
 tools/blktap/drivers/block-qcow2.c       | 2098 ------------------------------
 tools/blktap/drivers/block-ram.c         |  295 -----
 tools/blktap/drivers/block-sync.c        |  242 ----
 tools/blktap/drivers/block-vmdk.c        |  428 ------
 tools/blktap/drivers/bswap.h             |  178 ---
 tools/blktap/drivers/img2qcow.c          |  282 ----
 tools/blktap/drivers/qcow-create.c       |  130 --
 tools/blktap/drivers/qcow2raw.c          |  348 -----
 tools/blktap/drivers/tapaio.c            |  357 -----
 tools/blktap/drivers/tapaio.h            |  108 --
 tools/blktap/drivers/tapdisk.c           |  872 -------------
 tools/blktap/drivers/tapdisk.h           |  259 ----
 tools/blktap/lib/Makefile                |   60 -
 tools/blktap/lib/blkif.c                 |  185 ---
 tools/blktap/lib/blktaplib.h             |  240 ----
 tools/blktap/lib/list.h                  |   59 -
 tools/blktap/lib/xenbus.c                |  617 ---------
 tools/blktap/lib/xs_api.c                |  360 -----
 tools/blktap/lib/xs_api.h                |   50 -
 tools/configure                          |   29 +-
 tools/configure.ac                       |    4 +-
 tools/hotplug/Linux/Makefile             |    1 -
 tools/hotplug/Linux/blktap               |   94 --
 tools/hotplug/Linux/xen-backend.rules.in |    2 -
 41 files changed, 3 insertions(+), 11664 deletions(-)
 delete mode 100644 tools/blktap/Makefile
 delete mode 100644 tools/blktap/README
 delete mode 100644 tools/blktap/drivers/Makefile
 delete mode 100644 tools/blktap/drivers/aes.c
 delete mode 100644 tools/blktap/drivers/aes.h
 delete mode 100644 tools/blktap/drivers/blk.h
 delete mode 100644 tools/blktap/drivers/blk_linux.c
 delete mode 100644 tools/blktap/drivers/blktapctrl.c
 delete mode 100644 tools/blktap/drivers/blktapctrl.h
 delete mode 100644 tools/blktap/drivers/blktapctrl_linux.c
 delete mode 100644 tools/blktap/drivers/block-aio.c
 delete mode 100644 tools/blktap/drivers/block-qcow.c
 delete mode 100644 tools/blktap/drivers/block-qcow2.c
 delete mode 100644 tools/blktap/drivers/block-ram.c
 delete mode 100644 tools/blktap/drivers/block-sync.c
 delete mode 100644 tools/blktap/drivers/block-vmdk.c
 delete mode 100644 tools/blktap/drivers/bswap.h
 delete mode 100644 tools/blktap/drivers/img2qcow.c
 delete mode 100644 tools/blktap/drivers/qcow-create.c
 delete mode 100644 tools/blktap/drivers/qcow2raw.c
 delete mode 100644 tools/blktap/drivers/tapaio.c
 delete mode 100644 tools/blktap/drivers/tapaio.h
 delete mode 100644 tools/blktap/drivers/tapdisk.c
 delete mode 100644 tools/blktap/drivers/tapdisk.h
 delete mode 100644 tools/blktap/lib/Makefile
 delete mode 100644 tools/blktap/lib/blkif.c
 delete mode 100644 tools/blktap/lib/blktaplib.h
 delete mode 100644 tools/blktap/lib/list.h
 delete mode 100644 tools/blktap/lib/xenbus.c
 delete mode 100644 tools/blktap/lib/xs_api.c
 delete mode 100644 tools/blktap/lib/xs_api.h
 delete mode 100644 tools/hotplug/Linux/blktap

diff --git a/.gitignore b/.gitignore
index b24e905..6830a06 100644
--- a/.gitignore
+++ b/.gitignore
@@ -101,11 +101,6 @@ tools/blktap2/drivers/tapdisk2
 tools/blktap2/drivers/td-util
 tools/blktap2/vhd/vhd-update
 tools/blktap2/vhd/vhd-util
-tools/blktap/drivers/blktapctrl
-tools/blktap/drivers/img2qcow
-tools/blktap/drivers/qcow-create
-tools/blktap/drivers/qcow2raw
-tools/blktap/drivers/tapdisk
 tools/console/xenconsole
 tools/console/xenconsoled
 tools/debugger/gdb/gdb-6.2.1-linux-i386-xen/*
diff --git a/.hgignore b/.hgignore
index da27f80..0bd29a1 100644
--- a/.hgignore
+++ b/.hgignore
@@ -140,11 +140,6 @@
 ^tools/blktap2/drivers/td-util$
 ^tools/blktap2/vhd/vhd-update$
 ^tools/blktap2/vhd/vhd-util$
-^tools/blktap/drivers/blktapctrl$
-^tools/blktap/drivers/img2qcow$
-^tools/blktap/drivers/qcow-create$
-^tools/blktap/drivers/qcow2raw$
-^tools/blktap/drivers/tapdisk$
 ^tools/check/\..*$
 ^tools/console/xenconsole$
 ^tools/console/xenconsoled$
diff --git a/INSTALL b/INSTALL
index 6bb9d23..f0fc6f1 100644
--- a/INSTALL
+++ b/INSTALL
@@ -149,7 +149,6 @@ this detection and the sysv runlevel scripts have to be used.
 
 The old backend drivers are disabled because qdisk is now the default.
 This option can be used to build them anyway.
-  --enable-blktap1
   --enable-blktap2
 
 Build various stubom components, some are only example code. Its usually
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 89de5bd..30267fa 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -57,7 +57,6 @@ CONFIG_ROMBIOS      := @rombios@
 CONFIG_SEABIOS      := @seabios@
 CONFIG_QEMU_TRAD    := @qemu_traditional@
 CONFIG_QEMU_XEN     := @qemu_xen@
-CONFIG_BLKTAP1      := @blktap1@
 CONFIG_BLKTAP2      := @blktap2@
 CONFIG_QEMUU_EXTRA_ARGS:= @EXTRA_QEMUU_CONFIGURE_ARGS@
 CONFIG_REMUS_NETBUF := @remus_netbuf@
diff --git a/tools/Makefile b/tools/Makefile
index af9798a..1ad7a5d 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -16,7 +16,6 @@ SUBDIRS-y += console
 SUBDIRS-y += xenmon
 SUBDIRS-y += xenstat
 SUBDIRS-$(CONFIG_Linux) += memshr 
-SUBDIRS-$(CONFIG_BLKTAP1) += blktap
 SUBDIRS-$(CONFIG_BLKTAP2) += blktap2
 SUBDIRS-$(CONFIG_NetBSD) += xenbackendd
 SUBDIRS-y += libfsimage
@@ -169,6 +168,7 @@ subdir-all-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
 subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
 	set -e; \
 		$(buildmakevars2shellvars); \
+		export CONFIG_BLKTAP1=n; \
 		cd qemu-xen-traditional-dir; \
 		$(QEMU_ROOT)/xen-setup \
 		--extra-cflags="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
diff --git a/tools/blktap/Makefile b/tools/blktap/Makefile
deleted file mode 100644
index 4020566..0000000
--- a/tools/blktap/Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-XEN_ROOT = $(CURDIR)/../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-SUBDIRS-y :=
-SUBDIRS-y += lib
-SUBDIRS-y += drivers
-
-.PHONY: all clean install
-all clean install: %: subdirs-%
-
-install:
-	$(INSTALL_DIR) $(DESTDIR)$(DOCDIR)
-	$(INSTALL_DATA) README $(DESTDIR)$(DOCDIR)/README.blktap
diff --git a/tools/blktap/README b/tools/blktap/README
deleted file mode 100644
index 5e41080..0000000
--- a/tools/blktap/README
+++ /dev/null
@@ -1,122 +0,0 @@
-Blktap Userspace Tools + Library
-================================
-
-Andrew Warfield and Julian Chesterfield
-16th June 2006
-
-{firstname.lastname}@cl.cam.ac.uk
-
-The blktap userspace toolkit provides a user-level disk I/O
-interface. The blktap mechanism involves a kernel driver that acts
-similarly to the existing Xen/Linux blkback driver, and a set of
-associated user-level libraries.  Using these tools, blktap allows
-virtual block devices presented to VMs to be implemented in userspace
-and to be backed by raw partitions, files, network, etc.
-
-The key benefit of blktap is that it makes it easy and fast to write
-arbitrary block backends, and that these user-level backends actually
-perform very well.  Specifically:
-
-- Metadata disk formats such as Copy-on-Write, encrypted disks, sparse
-  formats and other compression features can be easily implemented.
-
-- Accessing file-based images from userspace avoids problems related
-  to flushing dirty pages which are present in the Linux loopback
-  driver.  (Specifically, doing a large number of writes to an
-  NFS-backed image don't result in the OOM killer going berserk.)
-
-- Per-disk handler processes enable easier userspace policing of block
-  resources, and process-granularity QoS techniques (disk scheduling
-  and related tools) may be trivially applied to block devices.
-
-- It's very easy to take advantage of userspace facilities such as
-  networking libraries, compression utilities, peer-to-peer
-  file-sharing systems and so on to build more complex block backends.
-
-- Crashes are contained -- incremental development/debugging is very
-  fast.
-
-How it works (in one paragraph):
-
-Working in conjunction with the kernel blktap driver, all disk I/O
-requests from VMs are passed to the userspace deamon (using a shared
-memory interface) through a character device. Each active disk is
-mapped to an individual device node, allowing per-disk processes to
-implement individual block devices where desired.  The userspace
-drivers are implemented using asynchronous (Linux libaio),
-O_DIRECT-based calls to preserve the unbuffered, batched and
-asynchronous request dispatch achieved with the existing blkback
-code.  We provide a simple, asynchronous virtual disk interface that
-makes it quite easy to add new disk implementations.
-
-As of June 2006 the current supported disk formats are:
-
- - Raw Images (both on partitions and in image files)
- - File-backed Qcow disks
- - Standalone sparse Qcow disks
- - Fast shareable RAM disk between VMs (requires some form of cluster-based 
-   filesystem support e.g. OCFS2 in the guest kernel)
- - Some VMDK images - your mileage may vary
-
-Raw and QCow images have asynchronous backends and so should perform
-fairly well.  VMDK is based directly on the qemu vmdk driver, which is
-synchronous (a.k.a. slow).
-
-Build and Installation Instructions
-===================================
-
-Make to configure the blktap backend driver in your dom0 kernel.  It
-will cooperate fine with the existing backend driver, so you can
-experiment with tap disks without breaking existing VM configs.
-
-To build the tools separately, "make && make install" in 
-tools/blktap.
-
-
-Using the Tools
-===============
-
-Prepare the image for booting. For qcow files use the qcow utilities
-installed earlier. e.g. qcow-create generates a blank standalone image
-or a file-backed CoW image. img2qcow takes an existing image or
-partition and creates a sparse, standalone qcow-based file.
-
-The userspace disk agent is configured to start automatically via xend
-(alternatively you can start it manually => 'blktapctrl')
-
-Customise the VM config file to use the 'tap' handler, followed by the
-driver type. e.g. for a raw image such as a file or partition:
-
-disk = ['tap:aio:<FILENAME>,sda1,w']
-
-e.g. for a qcow image:
-
-disk = ['tap:qcow:<FILENAME>,sda1,w']
-
-
-Mounting images in Dom0 using the blktap driver
-===============================================
-Tap (and blkback) disks are also mountable in Dom0 without requiring an
-active VM to attach. You will need to build a xenlinux Dom0 kernel that
-includes the blkfront driver (e.g. the default 'make world' or 
-'make kernels' build. Simply use the xm command-line tool to activate
-the backend disks, and blkfront will generate a virtual block device that
-can be accessed in the same way as a loop device or partition:
-
-e.g. for a raw image file <FILENAME> that would normally be mounted using
-the loopback driver (such as 'mount -o loop <FILENAME> /mnt/disk'), do the
-following:
-
-xm block-attach 0 tap:aio:<FILENAME> /dev/xvda1 w 0
-mount /dev/xvda1 /mnt/disk        <--- don't use loop driver
-
-In this way, you can use any of the userspace device-type drivers built
-with the blktap userspace toolkit to open and mount disks such as qcow
-or vmdk images:
-
-xm block-attach 0 tap:qcow:<FILENAME> /dev/xvda1 w 0
-mount /dev/xvda1 /mnt/disk
-
-
-
- 
diff --git a/tools/blktap/drivers/Makefile b/tools/blktap/drivers/Makefile
deleted file mode 100644
index 7461a95..0000000
--- a/tools/blktap/drivers/Makefile
+++ /dev/null
@@ -1,73 +0,0 @@
-XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-IBIN         = blktapctrl tapdisk
-QCOW_UTIL    = img2qcow qcow2raw qcow-create
-
-CFLAGS   += -Werror
-CFLAGS   += -Wno-unused
-CFLAGS   += -I../lib
-CFLAGS   += $(CFLAGS_libxenctrl)
-CFLAGS   += $(CFLAGS_libxenstore)
-CFLAGS   += -D_GNU_SOURCE
-
-ifeq ($CONFIG_GCRYPT,y)
-CFLAGS += -DUSE_GCRYPT
-CRYPT_LIB := -lgcrypt
-else
-CRYPT_LIB := -lcrypto
-$(warning === libgcrypt not installed: falling back to libcrypto ===)
-endif
-
-MEMSHRLIBS :=
-ifeq ($(CONFIG_Linux), y)
-MEMSHR_DIR   = ../../memshr
-CFLAGS += -DMEMSHR
-CFLAGS += -I $(MEMSHR_DIR)
-MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
-endif
-
-AIOLIBS     := -laio
-
-CFLAGS += $(PTHREAD_CFLAGS)
-LDFLAGS += $(PTHREAD_LDFLAGS)
-
-LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm $(PTHREAD_LIBS)
-LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) $(PTHREAD_LIBS) -lz
-
-BLK-OBJS-y  := block-aio.o
-BLK-OBJS-y  += block-sync.o
-BLK-OBJS-y  += block-vmdk.o
-BLK-OBJS-y  += block-ram.o
-BLK-OBJS-y  += block-qcow.o
-BLK-OBJS-y  += block-qcow2.o
-BLK-OBJS-y  += aes.o
-BLK-OBJS-y  += tapaio.o
-BLK-OBJS-$(CONFIG_Linux) += blk_linux.o
-
-BLKTAB-OBJS-y := blktapctrl.o
-BLKTAB-OBJS-$(CONFIG_Linux) += blktapctrl_linux.o
-
-all: $(IBIN) qcow-util
-
-blktapctrl: $(BLKTAB-OBJS-y)
-	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS_blktapctrl)
-
-tapdisk: tapdisk.o $(BLK-OBJS-y)
-	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS_img)
-
-.PHONY: qcow-util
-qcow-util: img2qcow qcow2raw qcow-create
-
-img2qcow qcow2raw qcow-create: %: %.o $(BLK-OBJS-y)
-	$(CC) $(LDFLAGS) -o $* $^ $(LDLIBS_img)
-
-install: all
-	$(INSTALL_PROG) $(IBIN) $(QCOW_UTIL) $(VHD_UTIL) $(DESTDIR)$(SBINDIR)
-
-clean:
-	rm -rf *.o *~ $(DEPS) xen TAGS $(IBIN) $(LIB) $(QCOW_UTIL) $(VHD_UTIL)
-
-.PHONY: clean install
-
--include $(DEPS)
diff --git a/tools/blktap/drivers/aes.c b/tools/blktap/drivers/aes.c
deleted file mode 100644
index 4d83fac..0000000
--- a/tools/blktap/drivers/aes.c
+++ /dev/null
@@ -1,1319 +0,0 @@
-/**
- * 
- * aes.c - integrated in QEMU by Fabrice Bellard from the OpenSSL project.
- */
-/*
- * rijndael-alg-fst.c
- *
- * @version 3.0 (December 2000)
- *
- * Optimised ANSI C code for the Rijndael cipher (now AES)
- *
- * @author Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>
- * @author Antoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be>
- * @author Paulo Barreto <paulo.barreto@terra.com.br>
- *
- * This code is hereby placed in the public domain.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''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 AUTHORS 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 "vl.h"
-#include <inttypes.h>
-#include <string.h>
-#include "aes.h"
-
-//#define NDEBUG
-#include <assert.h>
-
-typedef uint32_t u32;
-typedef uint16_t u16;
-typedef uint8_t u8;
-
-#define MAXKC   (256/32)
-#define MAXKB   (256/8)
-#define MAXNR   14
-
-/* This controls loop-unrolling in aes_core.c */
-#undef FULL_UNROLL
-# define GETU32(pt) (((u32)(pt)[0] << 24) ^ ((u32)(pt)[1] << 16) ^ ((u32)(pt)[2] <<  8) ^ ((u32)(pt)[3]))
-# define PUTU32(ct, st) { (ct)[0] = (u8)((st) >> 24); (ct)[1] = (u8)((st) >> 16); (ct)[2] = (u8)((st) >>  8); (ct)[3] = (u8)(st); }
-
-/*
-Te0[x] = S [x].[02, 01, 01, 03];
-Te1[x] = S [x].[03, 02, 01, 01];
-Te2[x] = S [x].[01, 03, 02, 01];
-Te3[x] = S [x].[01, 01, 03, 02];
-Te4[x] = S [x].[01, 01, 01, 01];
-
-Td0[x] = Si[x].[0e, 09, 0d, 0b];
-Td1[x] = Si[x].[0b, 0e, 09, 0d];
-Td2[x] = Si[x].[0d, 0b, 0e, 09];
-Td3[x] = Si[x].[09, 0d, 0b, 0e];
-Td4[x] = Si[x].[01, 01, 01, 01];
-*/
-
-static const u32 Te0[256] = {
-    0xc66363a5U, 0xf87c7c84U, 0xee777799U, 0xf67b7b8dU,
-    0xfff2f20dU, 0xd66b6bbdU, 0xde6f6fb1U, 0x91c5c554U,
-    0x60303050U, 0x02010103U, 0xce6767a9U, 0x562b2b7dU,
-    0xe7fefe19U, 0xb5d7d762U, 0x4dababe6U, 0xec76769aU,
-    0x8fcaca45U, 0x1f82829dU, 0x89c9c940U, 0xfa7d7d87U,
-    0xeffafa15U, 0xb25959ebU, 0x8e4747c9U, 0xfbf0f00bU,
-    0x41adadecU, 0xb3d4d467U, 0x5fa2a2fdU, 0x45afafeaU,
-    0x239c9cbfU, 0x53a4a4f7U, 0xe4727296U, 0x9bc0c05bU,
-    0x75b7b7c2U, 0xe1fdfd1cU, 0x3d9393aeU, 0x4c26266aU,
-    0x6c36365aU, 0x7e3f3f41U, 0xf5f7f702U, 0x83cccc4fU,
-    0x6834345cU, 0x51a5a5f4U, 0xd1e5e534U, 0xf9f1f108U,
-    0xe2717193U, 0xabd8d873U, 0x62313153U, 0x2a15153fU,
-    0x0804040cU, 0x95c7c752U, 0x46232365U, 0x9dc3c35eU,
-    0x30181828U, 0x379696a1U, 0x0a05050fU, 0x2f9a9ab5U,
-    0x0e070709U, 0x24121236U, 0x1b80809bU, 0xdfe2e23dU,
-    0xcdebeb26U, 0x4e272769U, 0x7fb2b2cdU, 0xea75759fU,
-    0x1209091bU, 0x1d83839eU, 0x582c2c74U, 0x341a1a2eU,
-    0x361b1b2dU, 0xdc6e6eb2U, 0xb45a5aeeU, 0x5ba0a0fbU,
-    0xa45252f6U, 0x763b3b4dU, 0xb7d6d661U, 0x7db3b3ceU,
-    0x5229297bU, 0xdde3e33eU, 0x5e2f2f71U, 0x13848497U,
-    0xa65353f5U, 0xb9d1d168U, 0x00000000U, 0xc1eded2cU,
-    0x40202060U, 0xe3fcfc1fU, 0x79b1b1c8U, 0xb65b5bedU,
-    0xd46a6abeU, 0x8dcbcb46U, 0x67bebed9U, 0x7239394bU,
-    0x944a4adeU, 0x984c4cd4U, 0xb05858e8U, 0x85cfcf4aU,
-    0xbbd0d06bU, 0xc5efef2aU, 0x4faaaae5U, 0xedfbfb16U,
-    0x864343c5U, 0x9a4d4dd7U, 0x66333355U, 0x11858594U,
-    0x8a4545cfU, 0xe9f9f910U, 0x04020206U, 0xfe7f7f81U,
-    0xa05050f0U, 0x783c3c44U, 0x259f9fbaU, 0x4ba8a8e3U,
-    0xa25151f3U, 0x5da3a3feU, 0x804040c0U, 0x058f8f8aU,
-    0x3f9292adU, 0x219d9dbcU, 0x70383848U, 0xf1f5f504U,
-    0x63bcbcdfU, 0x77b6b6c1U, 0xafdada75U, 0x42212163U,
-    0x20101030U, 0xe5ffff1aU, 0xfdf3f30eU, 0xbfd2d26dU,
-    0x81cdcd4cU, 0x180c0c14U, 0x26131335U, 0xc3ecec2fU,
-    0xbe5f5fe1U, 0x359797a2U, 0x884444ccU, 0x2e171739U,
-    0x93c4c457U, 0x55a7a7f2U, 0xfc7e7e82U, 0x7a3d3d47U,
-    0xc86464acU, 0xba5d5de7U, 0x3219192bU, 0xe6737395U,
-    0xc06060a0U, 0x19818198U, 0x9e4f4fd1U, 0xa3dcdc7fU,
-    0x44222266U, 0x542a2a7eU, 0x3b9090abU, 0x0b888883U,
-    0x8c4646caU, 0xc7eeee29U, 0x6bb8b8d3U, 0x2814143cU,
-    0xa7dede79U, 0xbc5e5ee2U, 0x160b0b1dU, 0xaddbdb76U,
-    0xdbe0e03bU, 0x64323256U, 0x743a3a4eU, 0x140a0a1eU,
-    0x924949dbU, 0x0c06060aU, 0x4824246cU, 0xb85c5ce4U,
-    0x9fc2c25dU, 0xbdd3d36eU, 0x43acacefU, 0xc46262a6U,
-    0x399191a8U, 0x319595a4U, 0xd3e4e437U, 0xf279798bU,
-    0xd5e7e732U, 0x8bc8c843U, 0x6e373759U, 0xda6d6db7U,
-    0x018d8d8cU, 0xb1d5d564U, 0x9c4e4ed2U, 0x49a9a9e0U,
-    0xd86c6cb4U, 0xac5656faU, 0xf3f4f407U, 0xcfeaea25U,
-    0xca6565afU, 0xf47a7a8eU, 0x47aeaee9U, 0x10080818U,
-    0x6fbabad5U, 0xf0787888U, 0x4a25256fU, 0x5c2e2e72U,
-    0x381c1c24U, 0x57a6a6f1U, 0x73b4b4c7U, 0x97c6c651U,
-    0xcbe8e823U, 0xa1dddd7cU, 0xe874749cU, 0x3e1f1f21U,
-    0x964b4bddU, 0x61bdbddcU, 0x0d8b8b86U, 0x0f8a8a85U,
-    0xe0707090U, 0x7c3e3e42U, 0x71b5b5c4U, 0xcc6666aaU,
-    0x904848d8U, 0x06030305U, 0xf7f6f601U, 0x1c0e0e12U,
-    0xc26161a3U, 0x6a35355fU, 0xae5757f9U, 0x69b9b9d0U,
-    0x17868691U, 0x99c1c158U, 0x3a1d1d27U, 0x279e9eb9U,
-    0xd9e1e138U, 0xebf8f813U, 0x2b9898b3U, 0x22111133U,
-    0xd26969bbU, 0xa9d9d970U, 0x078e8e89U, 0x339494a7U,
-    0x2d9b9bb6U, 0x3c1e1e22U, 0x15878792U, 0xc9e9e920U,
-    0x87cece49U, 0xaa5555ffU, 0x50282878U, 0xa5dfdf7aU,
-    0x038c8c8fU, 0x59a1a1f8U, 0x09898980U, 0x1a0d0d17U,
-    0x65bfbfdaU, 0xd7e6e631U, 0x844242c6U, 0xd06868b8U,
-    0x824141c3U, 0x299999b0U, 0x5a2d2d77U, 0x1e0f0f11U,
-    0x7bb0b0cbU, 0xa85454fcU, 0x6dbbbbd6U, 0x2c16163aU,
-};
-static const u32 Te1[256] = {
-    0xa5c66363U, 0x84f87c7cU, 0x99ee7777U, 0x8df67b7bU,
-    0x0dfff2f2U, 0xbdd66b6bU, 0xb1de6f6fU, 0x5491c5c5U,
-    0x50603030U, 0x03020101U, 0xa9ce6767U, 0x7d562b2bU,
-    0x19e7fefeU, 0x62b5d7d7U, 0xe64dababU, 0x9aec7676U,
-    0x458fcacaU, 0x9d1f8282U, 0x4089c9c9U, 0x87fa7d7dU,
-    0x15effafaU, 0xebb25959U, 0xc98e4747U, 0x0bfbf0f0U,
-    0xec41adadU, 0x67b3d4d4U, 0xfd5fa2a2U, 0xea45afafU,
-    0xbf239c9cU, 0xf753a4a4U, 0x96e47272U, 0x5b9bc0c0U,
-    0xc275b7b7U, 0x1ce1fdfdU, 0xae3d9393U, 0x6a4c2626U,
-    0x5a6c3636U, 0x417e3f3fU, 0x02f5f7f7U, 0x4f83ccccU,
-    0x5c683434U, 0xf451a5a5U, 0x34d1e5e5U, 0x08f9f1f1U,
-    0x93e27171U, 0x73abd8d8U, 0x53623131U, 0x3f2a1515U,
-    0x0c080404U, 0x5295c7c7U, 0x65462323U, 0x5e9dc3c3U,
-    0x28301818U, 0xa1379696U, 0x0f0a0505U, 0xb52f9a9aU,
-    0x090e0707U, 0x36241212U, 0x9b1b8080U, 0x3ddfe2e2U,
-    0x26cdebebU, 0x694e2727U, 0xcd7fb2b2U, 0x9fea7575U,
-    0x1b120909U, 0x9e1d8383U, 0x74582c2cU, 0x2e341a1aU,
-    0x2d361b1bU, 0xb2dc6e6eU, 0xeeb45a5aU, 0xfb5ba0a0U,
-    0xf6a45252U, 0x4d763b3bU, 0x61b7d6d6U, 0xce7db3b3U,
-    0x7b522929U, 0x3edde3e3U, 0x715e2f2fU, 0x97138484U,
-    0xf5a65353U, 0x68b9d1d1U, 0x00000000U, 0x2cc1ededU,
-    0x60402020U, 0x1fe3fcfcU, 0xc879b1b1U, 0xedb65b5bU,
-    0xbed46a6aU, 0x468dcbcbU, 0xd967bebeU, 0x4b723939U,
-    0xde944a4aU, 0xd4984c4cU, 0xe8b05858U, 0x4a85cfcfU,
-    0x6bbbd0d0U, 0x2ac5efefU, 0xe54faaaaU, 0x16edfbfbU,
-    0xc5864343U, 0xd79a4d4dU, 0x55663333U, 0x94118585U,
-    0xcf8a4545U, 0x10e9f9f9U, 0x06040202U, 0x81fe7f7fU,
-    0xf0a05050U, 0x44783c3cU, 0xba259f9fU, 0xe34ba8a8U,
-    0xf3a25151U, 0xfe5da3a3U, 0xc0804040U, 0x8a058f8fU,
-    0xad3f9292U, 0xbc219d9dU, 0x48703838U, 0x04f1f5f5U,
-    0xdf63bcbcU, 0xc177b6b6U, 0x75afdadaU, 0x63422121U,
-    0x30201010U, 0x1ae5ffffU, 0x0efdf3f3U, 0x6dbfd2d2U,
-    0x4c81cdcdU, 0x14180c0cU, 0x35261313U, 0x2fc3ececU,
-    0xe1be5f5fU, 0xa2359797U, 0xcc884444U, 0x392e1717U,
-    0x5793c4c4U, 0xf255a7a7U, 0x82fc7e7eU, 0x477a3d3dU,
-    0xacc86464U, 0xe7ba5d5dU, 0x2b321919U, 0x95e67373U,
-    0xa0c06060U, 0x98198181U, 0xd19e4f4fU, 0x7fa3dcdcU,
-    0x66442222U, 0x7e542a2aU, 0xab3b9090U, 0x830b8888U,
-    0xca8c4646U, 0x29c7eeeeU, 0xd36bb8b8U, 0x3c281414U,
-    0x79a7dedeU, 0xe2bc5e5eU, 0x1d160b0bU, 0x76addbdbU,
-    0x3bdbe0e0U, 0x56643232U, 0x4e743a3aU, 0x1e140a0aU,
-    0xdb924949U, 0x0a0c0606U, 0x6c482424U, 0xe4b85c5cU,
-    0x5d9fc2c2U, 0x6ebdd3d3U, 0xef43acacU, 0xa6c46262U,
-    0xa8399191U, 0xa4319595U, 0x37d3e4e4U, 0x8bf27979U,
-    0x32d5e7e7U, 0x438bc8c8U, 0x596e3737U, 0xb7da6d6dU,
-    0x8c018d8dU, 0x64b1d5d5U, 0xd29c4e4eU, 0xe049a9a9U,
-    0xb4d86c6cU, 0xfaac5656U, 0x07f3f4f4U, 0x25cfeaeaU,
-    0xafca6565U, 0x8ef47a7aU, 0xe947aeaeU, 0x18100808U,
-    0xd56fbabaU, 0x88f07878U, 0x6f4a2525U, 0x725c2e2eU,
-    0x24381c1cU, 0xf157a6a6U, 0xc773b4b4U, 0x5197c6c6U,
-    0x23cbe8e8U, 0x7ca1ddddU, 0x9ce87474U, 0x213e1f1fU,
-    0xdd964b4bU, 0xdc61bdbdU, 0x860d8b8bU, 0x850f8a8aU,
-    0x90e07070U, 0x427c3e3eU, 0xc471b5b5U, 0xaacc6666U,
-    0xd8904848U, 0x05060303U, 0x01f7f6f6U, 0x121c0e0eU,
-    0xa3c26161U, 0x5f6a3535U, 0xf9ae5757U, 0xd069b9b9U,
-    0x91178686U, 0x5899c1c1U, 0x273a1d1dU, 0xb9279e9eU,
-    0x38d9e1e1U, 0x13ebf8f8U, 0xb32b9898U, 0x33221111U,
-    0xbbd26969U, 0x70a9d9d9U, 0x89078e8eU, 0xa7339494U,
-    0xb62d9b9bU, 0x223c1e1eU, 0x92158787U, 0x20c9e9e9U,
-    0x4987ceceU, 0xffaa5555U, 0x78502828U, 0x7aa5dfdfU,
-    0x8f038c8cU, 0xf859a1a1U, 0x80098989U, 0x171a0d0dU,
-    0xda65bfbfU, 0x31d7e6e6U, 0xc6844242U, 0xb8d06868U,
-    0xc3824141U, 0xb0299999U, 0x775a2d2dU, 0x111e0f0fU,
-    0xcb7bb0b0U, 0xfca85454U, 0xd66dbbbbU, 0x3a2c1616U,
-};
-static const u32 Te2[256] = {
-    0x63a5c663U, 0x7c84f87cU, 0x7799ee77U, 0x7b8df67bU,
-    0xf20dfff2U, 0x6bbdd66bU, 0x6fb1de6fU, 0xc55491c5U,
-    0x30506030U, 0x01030201U, 0x67a9ce67U, 0x2b7d562bU,
-    0xfe19e7feU, 0xd762b5d7U, 0xabe64dabU, 0x769aec76U,
-    0xca458fcaU, 0x829d1f82U, 0xc94089c9U, 0x7d87fa7dU,
-    0xfa15effaU, 0x59ebb259U, 0x47c98e47U, 0xf00bfbf0U,
-    0xadec41adU, 0xd467b3d4U, 0xa2fd5fa2U, 0xafea45afU,
-    0x9cbf239cU, 0xa4f753a4U, 0x7296e472U, 0xc05b9bc0U,
-    0xb7c275b7U, 0xfd1ce1fdU, 0x93ae3d93U, 0x266a4c26U,
-    0x365a6c36U, 0x3f417e3fU, 0xf702f5f7U, 0xcc4f83ccU,
-    0x345c6834U, 0xa5f451a5U, 0xe534d1e5U, 0xf108f9f1U,
-    0x7193e271U, 0xd873abd8U, 0x31536231U, 0x153f2a15U,
-    0x040c0804U, 0xc75295c7U, 0x23654623U, 0xc35e9dc3U,
-    0x18283018U, 0x96a13796U, 0x050f0a05U, 0x9ab52f9aU,
-    0x07090e07U, 0x12362412U, 0x809b1b80U, 0xe23ddfe2U,
-    0xeb26cdebU, 0x27694e27U, 0xb2cd7fb2U, 0x759fea75U,
-    0x091b1209U, 0x839e1d83U, 0x2c74582cU, 0x1a2e341aU,
-    0x1b2d361bU, 0x6eb2dc6eU, 0x5aeeb45aU, 0xa0fb5ba0U,
-    0x52f6a452U, 0x3b4d763bU, 0xd661b7d6U, 0xb3ce7db3U,
-    0x297b5229U, 0xe33edde3U, 0x2f715e2fU, 0x84971384U,
-    0x53f5a653U, 0xd168b9d1U, 0x00000000U, 0xed2cc1edU,
-    0x20604020U, 0xfc1fe3fcU, 0xb1c879b1U, 0x5bedb65bU,
-    0x6abed46aU, 0xcb468dcbU, 0xbed967beU, 0x394b7239U,
-    0x4ade944aU, 0x4cd4984cU, 0x58e8b058U, 0xcf4a85cfU,
-    0xd06bbbd0U, 0xef2ac5efU, 0xaae54faaU, 0xfb16edfbU,
-    0x43c58643U, 0x4dd79a4dU, 0x33556633U, 0x85941185U,
-    0x45cf8a45U, 0xf910e9f9U, 0x02060402U, 0x7f81fe7fU,
-    0x50f0a050U, 0x3c44783cU, 0x9fba259fU, 0xa8e34ba8U,
-    0x51f3a251U, 0xa3fe5da3U, 0x40c08040U, 0x8f8a058fU,
-    0x92ad3f92U, 0x9dbc219dU, 0x38487038U, 0xf504f1f5U,
-    0xbcdf63bcU, 0xb6c177b6U, 0xda75afdaU, 0x21634221U,
-    0x10302010U, 0xff1ae5ffU, 0xf30efdf3U, 0xd26dbfd2U,
-    0xcd4c81cdU, 0x0c14180cU, 0x13352613U, 0xec2fc3ecU,
-    0x5fe1be5fU, 0x97a23597U, 0x44cc8844U, 0x17392e17U,
-    0xc45793c4U, 0xa7f255a7U, 0x7e82fc7eU, 0x3d477a3dU,
-    0x64acc864U, 0x5de7ba5dU, 0x192b3219U, 0x7395e673U,
-    0x60a0c060U, 0x81981981U, 0x4fd19e4fU, 0xdc7fa3dcU,
-    0x22664422U, 0x2a7e542aU, 0x90ab3b90U, 0x88830b88U,
-    0x46ca8c46U, 0xee29c7eeU, 0xb8d36bb8U, 0x143c2814U,
-    0xde79a7deU, 0x5ee2bc5eU, 0x0b1d160bU, 0xdb76addbU,
-    0xe03bdbe0U, 0x32566432U, 0x3a4e743aU, 0x0a1e140aU,
-    0x49db9249U, 0x060a0c06U, 0x246c4824U, 0x5ce4b85cU,
-    0xc25d9fc2U, 0xd36ebdd3U, 0xacef43acU, 0x62a6c462U,
-    0x91a83991U, 0x95a43195U, 0xe437d3e4U, 0x798bf279U,
-    0xe732d5e7U, 0xc8438bc8U, 0x37596e37U, 0x6db7da6dU,
-    0x8d8c018dU, 0xd564b1d5U, 0x4ed29c4eU, 0xa9e049a9U,
-    0x6cb4d86cU, 0x56faac56U, 0xf407f3f4U, 0xea25cfeaU,
-    0x65afca65U, 0x7a8ef47aU, 0xaee947aeU, 0x08181008U,
-    0xbad56fbaU, 0x7888f078U, 0x256f4a25U, 0x2e725c2eU,
-    0x1c24381cU, 0xa6f157a6U, 0xb4c773b4U, 0xc65197c6U,
-    0xe823cbe8U, 0xdd7ca1ddU, 0x749ce874U, 0x1f213e1fU,
-    0x4bdd964bU, 0xbddc61bdU, 0x8b860d8bU, 0x8a850f8aU,
-    0x7090e070U, 0x3e427c3eU, 0xb5c471b5U, 0x66aacc66U,
-    0x48d89048U, 0x03050603U, 0xf601f7f6U, 0x0e121c0eU,
-    0x61a3c261U, 0x355f6a35U, 0x57f9ae57U, 0xb9d069b9U,
-    0x86911786U, 0xc15899c1U, 0x1d273a1dU, 0x9eb9279eU,
-    0xe138d9e1U, 0xf813ebf8U, 0x98b32b98U, 0x11332211U,
-    0x69bbd269U, 0xd970a9d9U, 0x8e89078eU, 0x94a73394U,
-    0x9bb62d9bU, 0x1e223c1eU, 0x87921587U, 0xe920c9e9U,
-    0xce4987ceU, 0x55ffaa55U, 0x28785028U, 0xdf7aa5dfU,
-    0x8c8f038cU, 0xa1f859a1U, 0x89800989U, 0x0d171a0dU,
-    0xbfda65bfU, 0xe631d7e6U, 0x42c68442U, 0x68b8d068U,
-    0x41c38241U, 0x99b02999U, 0x2d775a2dU, 0x0f111e0fU,
-    0xb0cb7bb0U, 0x54fca854U, 0xbbd66dbbU, 0x163a2c16U,
-};
-static const u32 Te3[256] = {
-
-    0x6363a5c6U, 0x7c7c84f8U, 0x777799eeU, 0x7b7b8df6U,
-    0xf2f20dffU, 0x6b6bbdd6U, 0x6f6fb1deU, 0xc5c55491U,
-    0x30305060U, 0x01010302U, 0x6767a9ceU, 0x2b2b7d56U,
-    0xfefe19e7U, 0xd7d762b5U, 0xababe64dU, 0x76769aecU,
-    0xcaca458fU, 0x82829d1fU, 0xc9c94089U, 0x7d7d87faU,
-    0xfafa15efU, 0x5959ebb2U, 0x4747c98eU, 0xf0f00bfbU,
-    0xadadec41U, 0xd4d467b3U, 0xa2a2fd5fU, 0xafafea45U,
-    0x9c9cbf23U, 0xa4a4f753U, 0x727296e4U, 0xc0c05b9bU,
-    0xb7b7c275U, 0xfdfd1ce1U, 0x9393ae3dU, 0x26266a4cU,
-    0x36365a6cU, 0x3f3f417eU, 0xf7f702f5U, 0xcccc4f83U,
-    0x34345c68U, 0xa5a5f451U, 0xe5e534d1U, 0xf1f108f9U,
-    0x717193e2U, 0xd8d873abU, 0x31315362U, 0x15153f2aU,
-    0x04040c08U, 0xc7c75295U, 0x23236546U, 0xc3c35e9dU,
-    0x18182830U, 0x9696a137U, 0x05050f0aU, 0x9a9ab52fU,
-    0x0707090eU, 0x12123624U, 0x80809b1bU, 0xe2e23ddfU,
-    0xebeb26cdU, 0x2727694eU, 0xb2b2cd7fU, 0x75759feaU,
-    0x09091b12U, 0x83839e1dU, 0x2c2c7458U, 0x1a1a2e34U,
-    0x1b1b2d36U, 0x6e6eb2dcU, 0x5a5aeeb4U, 0xa0a0fb5bU,
-    0x5252f6a4U, 0x3b3b4d76U, 0xd6d661b7U, 0xb3b3ce7dU,
-    0x29297b52U, 0xe3e33eddU, 0x2f2f715eU, 0x84849713U,
-    0x5353f5a6U, 0xd1d168b9U, 0x00000000U, 0xeded2cc1U,
-    0x20206040U, 0xfcfc1fe3U, 0xb1b1c879U, 0x5b5bedb6U,
-    0x6a6abed4U, 0xcbcb468dU, 0xbebed967U, 0x39394b72U,
-    0x4a4ade94U, 0x4c4cd498U, 0x5858e8b0U, 0xcfcf4a85U,
-    0xd0d06bbbU, 0xefef2ac5U, 0xaaaae54fU, 0xfbfb16edU,
-    0x4343c586U, 0x4d4dd79aU, 0x33335566U, 0x85859411U,
-    0x4545cf8aU, 0xf9f910e9U, 0x02020604U, 0x7f7f81feU,
-    0x5050f0a0U, 0x3c3c4478U, 0x9f9fba25U, 0xa8a8e34bU,
-    0x5151f3a2U, 0xa3a3fe5dU, 0x4040c080U, 0x8f8f8a05U,
-    0x9292ad3fU, 0x9d9dbc21U, 0x38384870U, 0xf5f504f1U,
-    0xbcbcdf63U, 0xb6b6c177U, 0xdada75afU, 0x21216342U,
-    0x10103020U, 0xffff1ae5U, 0xf3f30efdU, 0xd2d26dbfU,
-    0xcdcd4c81U, 0x0c0c1418U, 0x13133526U, 0xecec2fc3U,
-    0x5f5fe1beU, 0x9797a235U, 0x4444cc88U, 0x1717392eU,
-    0xc4c45793U, 0xa7a7f255U, 0x7e7e82fcU, 0x3d3d477aU,
-    0x6464acc8U, 0x5d5de7baU, 0x19192b32U, 0x737395e6U,
-    0x6060a0c0U, 0x81819819U, 0x4f4fd19eU, 0xdcdc7fa3U,
-    0x22226644U, 0x2a2a7e54U, 0x9090ab3bU, 0x8888830bU,
-    0x4646ca8cU, 0xeeee29c7U, 0xb8b8d36bU, 0x14143c28U,
-    0xdede79a7U, 0x5e5ee2bcU, 0x0b0b1d16U, 0xdbdb76adU,
-    0xe0e03bdbU, 0x32325664U, 0x3a3a4e74U, 0x0a0a1e14U,
-    0x4949db92U, 0x06060a0cU, 0x24246c48U, 0x5c5ce4b8U,
-    0xc2c25d9fU, 0xd3d36ebdU, 0xacacef43U, 0x6262a6c4U,
-    0x9191a839U, 0x9595a431U, 0xe4e437d3U, 0x79798bf2U,
-    0xe7e732d5U, 0xc8c8438bU, 0x3737596eU, 0x6d6db7daU,
-    0x8d8d8c01U, 0xd5d564b1U, 0x4e4ed29cU, 0xa9a9e049U,
-    0x6c6cb4d8U, 0x5656faacU, 0xf4f407f3U, 0xeaea25cfU,
-    0x6565afcaU, 0x7a7a8ef4U, 0xaeaee947U, 0x08081810U,
-    0xbabad56fU, 0x787888f0U, 0x25256f4aU, 0x2e2e725cU,
-    0x1c1c2438U, 0xa6a6f157U, 0xb4b4c773U, 0xc6c65197U,
-    0xe8e823cbU, 0xdddd7ca1U, 0x74749ce8U, 0x1f1f213eU,
-    0x4b4bdd96U, 0xbdbddc61U, 0x8b8b860dU, 0x8a8a850fU,
-    0x707090e0U, 0x3e3e427cU, 0xb5b5c471U, 0x6666aaccU,
-    0x4848d890U, 0x03030506U, 0xf6f601f7U, 0x0e0e121cU,
-    0x6161a3c2U, 0x35355f6aU, 0x5757f9aeU, 0xb9b9d069U,
-    0x86869117U, 0xc1c15899U, 0x1d1d273aU, 0x9e9eb927U,
-    0xe1e138d9U, 0xf8f813ebU, 0x9898b32bU, 0x11113322U,
-    0x6969bbd2U, 0xd9d970a9U, 0x8e8e8907U, 0x9494a733U,
-    0x9b9bb62dU, 0x1e1e223cU, 0x87879215U, 0xe9e920c9U,
-    0xcece4987U, 0x5555ffaaU, 0x28287850U, 0xdfdf7aa5U,
-    0x8c8c8f03U, 0xa1a1f859U, 0x89898009U, 0x0d0d171aU,
-    0xbfbfda65U, 0xe6e631d7U, 0x4242c684U, 0x6868b8d0U,
-    0x4141c382U, 0x9999b029U, 0x2d2d775aU, 0x0f0f111eU,
-    0xb0b0cb7bU, 0x5454fca8U, 0xbbbbd66dU, 0x16163a2cU,
-};
-static const u32 Te4[256] = {
-    0x63636363U, 0x7c7c7c7cU, 0x77777777U, 0x7b7b7b7bU,
-    0xf2f2f2f2U, 0x6b6b6b6bU, 0x6f6f6f6fU, 0xc5c5c5c5U,
-    0x30303030U, 0x01010101U, 0x67676767U, 0x2b2b2b2bU,
-    0xfefefefeU, 0xd7d7d7d7U, 0xababababU, 0x76767676U,
-    0xcacacacaU, 0x82828282U, 0xc9c9c9c9U, 0x7d7d7d7dU,
-    0xfafafafaU, 0x59595959U, 0x47474747U, 0xf0f0f0f0U,
-    0xadadadadU, 0xd4d4d4d4U, 0xa2a2a2a2U, 0xafafafafU,
-    0x9c9c9c9cU, 0xa4a4a4a4U, 0x72727272U, 0xc0c0c0c0U,
-    0xb7b7b7b7U, 0xfdfdfdfdU, 0x93939393U, 0x26262626U,
-    0x36363636U, 0x3f3f3f3fU, 0xf7f7f7f7U, 0xccccccccU,
-    0x34343434U, 0xa5a5a5a5U, 0xe5e5e5e5U, 0xf1f1f1f1U,
-    0x71717171U, 0xd8d8d8d8U, 0x31313131U, 0x15151515U,
-    0x04040404U, 0xc7c7c7c7U, 0x23232323U, 0xc3c3c3c3U,
-    0x18181818U, 0x96969696U, 0x05050505U, 0x9a9a9a9aU,
-    0x07070707U, 0x12121212U, 0x80808080U, 0xe2e2e2e2U,
-    0xebebebebU, 0x27272727U, 0xb2b2b2b2U, 0x75757575U,
-    0x09090909U, 0x83838383U, 0x2c2c2c2cU, 0x1a1a1a1aU,
-    0x1b1b1b1bU, 0x6e6e6e6eU, 0x5a5a5a5aU, 0xa0a0a0a0U,
-    0x52525252U, 0x3b3b3b3bU, 0xd6d6d6d6U, 0xb3b3b3b3U,
-    0x29292929U, 0xe3e3e3e3U, 0x2f2f2f2fU, 0x84848484U,
-    0x53535353U, 0xd1d1d1d1U, 0x00000000U, 0xededededU,
-    0x20202020U, 0xfcfcfcfcU, 0xb1b1b1b1U, 0x5b5b5b5bU,
-    0x6a6a6a6aU, 0xcbcbcbcbU, 0xbebebebeU, 0x39393939U,
-    0x4a4a4a4aU, 0x4c4c4c4cU, 0x58585858U, 0xcfcfcfcfU,
-    0xd0d0d0d0U, 0xefefefefU, 0xaaaaaaaaU, 0xfbfbfbfbU,
-    0x43434343U, 0x4d4d4d4dU, 0x33333333U, 0x85858585U,
-    0x45454545U, 0xf9f9f9f9U, 0x02020202U, 0x7f7f7f7fU,
-    0x50505050U, 0x3c3c3c3cU, 0x9f9f9f9fU, 0xa8a8a8a8U,
-    0x51515151U, 0xa3a3a3a3U, 0x40404040U, 0x8f8f8f8fU,
-    0x92929292U, 0x9d9d9d9dU, 0x38383838U, 0xf5f5f5f5U,
-    0xbcbcbcbcU, 0xb6b6b6b6U, 0xdadadadaU, 0x21212121U,
-    0x10101010U, 0xffffffffU, 0xf3f3f3f3U, 0xd2d2d2d2U,
-    0xcdcdcdcdU, 0x0c0c0c0cU, 0x13131313U, 0xececececU,
-    0x5f5f5f5fU, 0x97979797U, 0x44444444U, 0x17171717U,
-    0xc4c4c4c4U, 0xa7a7a7a7U, 0x7e7e7e7eU, 0x3d3d3d3dU,
-    0x64646464U, 0x5d5d5d5dU, 0x19191919U, 0x73737373U,
-    0x60606060U, 0x81818181U, 0x4f4f4f4fU, 0xdcdcdcdcU,
-    0x22222222U, 0x2a2a2a2aU, 0x90909090U, 0x88888888U,
-    0x46464646U, 0xeeeeeeeeU, 0xb8b8b8b8U, 0x14141414U,
-    0xdedededeU, 0x5e5e5e5eU, 0x0b0b0b0bU, 0xdbdbdbdbU,
-    0xe0e0e0e0U, 0x32323232U, 0x3a3a3a3aU, 0x0a0a0a0aU,
-    0x49494949U, 0x06060606U, 0x24242424U, 0x5c5c5c5cU,
-    0xc2c2c2c2U, 0xd3d3d3d3U, 0xacacacacU, 0x62626262U,
-    0x91919191U, 0x95959595U, 0xe4e4e4e4U, 0x79797979U,
-    0xe7e7e7e7U, 0xc8c8c8c8U, 0x37373737U, 0x6d6d6d6dU,
-    0x8d8d8d8dU, 0xd5d5d5d5U, 0x4e4e4e4eU, 0xa9a9a9a9U,
-    0x6c6c6c6cU, 0x56565656U, 0xf4f4f4f4U, 0xeaeaeaeaU,
-    0x65656565U, 0x7a7a7a7aU, 0xaeaeaeaeU, 0x08080808U,
-    0xbabababaU, 0x78787878U, 0x25252525U, 0x2e2e2e2eU,
-    0x1c1c1c1cU, 0xa6a6a6a6U, 0xb4b4b4b4U, 0xc6c6c6c6U,
-    0xe8e8e8e8U, 0xddddddddU, 0x74747474U, 0x1f1f1f1fU,
-    0x4b4b4b4bU, 0xbdbdbdbdU, 0x8b8b8b8bU, 0x8a8a8a8aU,
-    0x70707070U, 0x3e3e3e3eU, 0xb5b5b5b5U, 0x66666666U,
-    0x48484848U, 0x03030303U, 0xf6f6f6f6U, 0x0e0e0e0eU,
-    0x61616161U, 0x35353535U, 0x57575757U, 0xb9b9b9b9U,
-    0x86868686U, 0xc1c1c1c1U, 0x1d1d1d1dU, 0x9e9e9e9eU,
-    0xe1e1e1e1U, 0xf8f8f8f8U, 0x98989898U, 0x11111111U,
-    0x69696969U, 0xd9d9d9d9U, 0x8e8e8e8eU, 0x94949494U,
-    0x9b9b9b9bU, 0x1e1e1e1eU, 0x87878787U, 0xe9e9e9e9U,
-    0xcecececeU, 0x55555555U, 0x28282828U, 0xdfdfdfdfU,
-    0x8c8c8c8cU, 0xa1a1a1a1U, 0x89898989U, 0x0d0d0d0dU,
-    0xbfbfbfbfU, 0xe6e6e6e6U, 0x42424242U, 0x68686868U,
-    0x41414141U, 0x99999999U, 0x2d2d2d2dU, 0x0f0f0f0fU,
-    0xb0b0b0b0U, 0x54545454U, 0xbbbbbbbbU, 0x16161616U,
-};
-static const u32 Td0[256] = {
-    0x51f4a750U, 0x7e416553U, 0x1a17a4c3U, 0x3a275e96U,
-    0x3bab6bcbU, 0x1f9d45f1U, 0xacfa58abU, 0x4be30393U,
-    0x2030fa55U, 0xad766df6U, 0x88cc7691U, 0xf5024c25U,
-    0x4fe5d7fcU, 0xc52acbd7U, 0x26354480U, 0xb562a38fU,
-    0xdeb15a49U, 0x25ba1b67U, 0x45ea0e98U, 0x5dfec0e1U,
-    0xc32f7502U, 0x814cf012U, 0x8d4697a3U, 0x6bd3f9c6U,
-    0x038f5fe7U, 0x15929c95U, 0xbf6d7aebU, 0x955259daU,
-    0xd4be832dU, 0x587421d3U, 0x49e06929U, 0x8ec9c844U,
-    0x75c2896aU, 0xf48e7978U, 0x99583e6bU, 0x27b971ddU,
-    0xbee14fb6U, 0xf088ad17U, 0xc920ac66U, 0x7dce3ab4U,
-    0x63df4a18U, 0xe51a3182U, 0x97513360U, 0x62537f45U,
-    0xb16477e0U, 0xbb6bae84U, 0xfe81a01cU, 0xf9082b94U,
-    0x70486858U, 0x8f45fd19U, 0x94de6c87U, 0x527bf8b7U,
-    0xab73d323U, 0x724b02e2U, 0xe31f8f57U, 0x6655ab2aU,
-    0xb2eb2807U, 0x2fb5c203U, 0x86c57b9aU, 0xd33708a5U,
-    0x302887f2U, 0x23bfa5b2U, 0x02036abaU, 0xed16825cU,
-    0x8acf1c2bU, 0xa779b492U, 0xf307f2f0U, 0x4e69e2a1U,
-    0x65daf4cdU, 0x0605bed5U, 0xd134621fU, 0xc4a6fe8aU,
-    0x342e539dU, 0xa2f355a0U, 0x058ae132U, 0xa4f6eb75U,
-    0x0b83ec39U, 0x4060efaaU, 0x5e719f06U, 0xbd6e1051U,
-    0x3e218af9U, 0x96dd063dU, 0xdd3e05aeU, 0x4de6bd46U,
-    0x91548db5U, 0x71c45d05U, 0x0406d46fU, 0x605015ffU,
-    0x1998fb24U, 0xd6bde997U, 0x894043ccU, 0x67d99e77U,
-    0xb0e842bdU, 0x07898b88U, 0xe7195b38U, 0x79c8eedbU,
-    0xa17c0a47U, 0x7c420fe9U, 0xf8841ec9U, 0x00000000U,
-    0x09808683U, 0x322bed48U, 0x1e1170acU, 0x6c5a724eU,
-    0xfd0efffbU, 0x0f853856U, 0x3daed51eU, 0x362d3927U,
-    0x0a0fd964U, 0x685ca621U, 0x9b5b54d1U, 0x24362e3aU,
-    0x0c0a67b1U, 0x9357e70fU, 0xb4ee96d2U, 0x1b9b919eU,
-    0x80c0c54fU, 0x61dc20a2U, 0x5a774b69U, 0x1c121a16U,
-    0xe293ba0aU, 0xc0a02ae5U, 0x3c22e043U, 0x121b171dU,
-    0x0e090d0bU, 0xf28bc7adU, 0x2db6a8b9U, 0x141ea9c8U,
-    0x57f11985U, 0xaf75074cU, 0xee99ddbbU, 0xa37f60fdU,
-    0xf701269fU, 0x5c72f5bcU, 0x44663bc5U, 0x5bfb7e34U,
-    0x8b432976U, 0xcb23c6dcU, 0xb6edfc68U, 0xb8e4f163U,
-    0xd731dccaU, 0x42638510U, 0x13972240U, 0x84c61120U,
-    0x854a247dU, 0xd2bb3df8U, 0xaef93211U, 0xc729a16dU,
-    0x1d9e2f4bU, 0xdcb230f3U, 0x0d8652ecU, 0x77c1e3d0U,
-    0x2bb3166cU, 0xa970b999U, 0x119448faU, 0x47e96422U,
-    0xa8fc8cc4U, 0xa0f03f1aU, 0x567d2cd8U, 0x223390efU,
-    0x87494ec7U, 0xd938d1c1U, 0x8ccaa2feU, 0x98d40b36U,
-    0xa6f581cfU, 0xa57ade28U, 0xdab78e26U, 0x3fadbfa4U,
-    0x2c3a9de4U, 0x5078920dU, 0x6a5fcc9bU, 0x547e4662U,
-    0xf68d13c2U, 0x90d8b8e8U, 0x2e39f75eU, 0x82c3aff5U,
-    0x9f5d80beU, 0x69d0937cU, 0x6fd52da9U, 0xcf2512b3U,
-    0xc8ac993bU, 0x10187da7U, 0xe89c636eU, 0xdb3bbb7bU,
-    0xcd267809U, 0x6e5918f4U, 0xec9ab701U, 0x834f9aa8U,
-    0xe6956e65U, 0xaaffe67eU, 0x21bccf08U, 0xef15e8e6U,
-    0xbae79bd9U, 0x4a6f36ceU, 0xea9f09d4U, 0x29b07cd6U,
-    0x31a4b2afU, 0x2a3f2331U, 0xc6a59430U, 0x35a266c0U,
-    0x744ebc37U, 0xfc82caa6U, 0xe090d0b0U, 0x33a7d815U,
-    0xf104984aU, 0x41ecdaf7U, 0x7fcd500eU, 0x1791f62fU,
-    0x764dd68dU, 0x43efb04dU, 0xccaa4d54U, 0xe49604dfU,
-    0x9ed1b5e3U, 0x4c6a881bU, 0xc12c1fb8U, 0x4665517fU,
-    0x9d5eea04U, 0x018c355dU, 0xfa877473U, 0xfb0b412eU,
-    0xb3671d5aU, 0x92dbd252U, 0xe9105633U, 0x6dd64713U,
-    0x9ad7618cU, 0x37a10c7aU, 0x59f8148eU, 0xeb133c89U,
-    0xcea927eeU, 0xb761c935U, 0xe11ce5edU, 0x7a47b13cU,
-    0x9cd2df59U, 0x55f2733fU, 0x1814ce79U, 0x73c737bfU,
-    0x53f7cdeaU, 0x5ffdaa5bU, 0xdf3d6f14U, 0x7844db86U,
-    0xcaaff381U, 0xb968c43eU, 0x3824342cU, 0xc2a3405fU,
-    0x161dc372U, 0xbce2250cU, 0x283c498bU, 0xff0d9541U,
-    0x39a80171U, 0x080cb3deU, 0xd8b4e49cU, 0x6456c190U,
-    0x7bcb8461U, 0xd532b670U, 0x486c5c74U, 0xd0b85742U,
-};
-static const u32 Td1[256] = {
-    0x5051f4a7U, 0x537e4165U, 0xc31a17a4U, 0x963a275eU,
-    0xcb3bab6bU, 0xf11f9d45U, 0xabacfa58U, 0x934be303U,
-    0x552030faU, 0xf6ad766dU, 0x9188cc76U, 0x25f5024cU,
-    0xfc4fe5d7U, 0xd7c52acbU, 0x80263544U, 0x8fb562a3U,
-    0x49deb15aU, 0x6725ba1bU, 0x9845ea0eU, 0xe15dfec0U,
-    0x02c32f75U, 0x12814cf0U, 0xa38d4697U, 0xc66bd3f9U,
-    0xe7038f5fU, 0x9515929cU, 0xebbf6d7aU, 0xda955259U,
-    0x2dd4be83U, 0xd3587421U, 0x2949e069U, 0x448ec9c8U,
-    0x6a75c289U, 0x78f48e79U, 0x6b99583eU, 0xdd27b971U,
-    0xb6bee14fU, 0x17f088adU, 0x66c920acU, 0xb47dce3aU,
-    0x1863df4aU, 0x82e51a31U, 0x60975133U, 0x4562537fU,
-    0xe0b16477U, 0x84bb6baeU, 0x1cfe81a0U, 0x94f9082bU,
-    0x58704868U, 0x198f45fdU, 0x8794de6cU, 0xb7527bf8U,
-    0x23ab73d3U, 0xe2724b02U, 0x57e31f8fU, 0x2a6655abU,
-    0x07b2eb28U, 0x032fb5c2U, 0x9a86c57bU, 0xa5d33708U,
-    0xf2302887U, 0xb223bfa5U, 0xba02036aU, 0x5ced1682U,
-    0x2b8acf1cU, 0x92a779b4U, 0xf0f307f2U, 0xa14e69e2U,
-    0xcd65daf4U, 0xd50605beU, 0x1fd13462U, 0x8ac4a6feU,
-    0x9d342e53U, 0xa0a2f355U, 0x32058ae1U, 0x75a4f6ebU,
-    0x390b83ecU, 0xaa4060efU, 0x065e719fU, 0x51bd6e10U,
-    0xf93e218aU, 0x3d96dd06U, 0xaedd3e05U, 0x464de6bdU,
-    0xb591548dU, 0x0571c45dU, 0x6f0406d4U, 0xff605015U,
-    0x241998fbU, 0x97d6bde9U, 0xcc894043U, 0x7767d99eU,
-    0xbdb0e842U, 0x8807898bU, 0x38e7195bU, 0xdb79c8eeU,
-    0x47a17c0aU, 0xe97c420fU, 0xc9f8841eU, 0x00000000U,
-    0x83098086U, 0x48322bedU, 0xac1e1170U, 0x4e6c5a72U,
-    0xfbfd0effU, 0x560f8538U, 0x1e3daed5U, 0x27362d39U,
-    0x640a0fd9U, 0x21685ca6U, 0xd19b5b54U, 0x3a24362eU,
-    0xb10c0a67U, 0x0f9357e7U, 0xd2b4ee96U, 0x9e1b9b91U,
-    0x4f80c0c5U, 0xa261dc20U, 0x695a774bU, 0x161c121aU,
-    0x0ae293baU, 0xe5c0a02aU, 0x433c22e0U, 0x1d121b17U,
-    0x0b0e090dU, 0xadf28bc7U, 0xb92db6a8U, 0xc8141ea9U,
-    0x8557f119U, 0x4caf7507U, 0xbbee99ddU, 0xfda37f60U,
-    0x9ff70126U, 0xbc5c72f5U, 0xc544663bU, 0x345bfb7eU,
-    0x768b4329U, 0xdccb23c6U, 0x68b6edfcU, 0x63b8e4f1U,
-    0xcad731dcU, 0x10426385U, 0x40139722U, 0x2084c611U,
-    0x7d854a24U, 0xf8d2bb3dU, 0x11aef932U, 0x6dc729a1U,
-    0x4b1d9e2fU, 0xf3dcb230U, 0xec0d8652U, 0xd077c1e3U,
-    0x6c2bb316U, 0x99a970b9U, 0xfa119448U, 0x2247e964U,
-    0xc4a8fc8cU, 0x1aa0f03fU, 0xd8567d2cU, 0xef223390U,
-    0xc787494eU, 0xc1d938d1U, 0xfe8ccaa2U, 0x3698d40bU,
-    0xcfa6f581U, 0x28a57adeU, 0x26dab78eU, 0xa43fadbfU,
-    0xe42c3a9dU, 0x0d507892U, 0x9b6a5fccU, 0x62547e46U,
-    0xc2f68d13U, 0xe890d8b8U, 0x5e2e39f7U, 0xf582c3afU,
-    0xbe9f5d80U, 0x7c69d093U, 0xa96fd52dU, 0xb3cf2512U,
-    0x3bc8ac99U, 0xa710187dU, 0x6ee89c63U, 0x7bdb3bbbU,
-    0x09cd2678U, 0xf46e5918U, 0x01ec9ab7U, 0xa8834f9aU,
-    0x65e6956eU, 0x7eaaffe6U, 0x0821bccfU, 0xe6ef15e8U,
-    0xd9bae79bU, 0xce4a6f36U, 0xd4ea9f09U, 0xd629b07cU,
-    0xaf31a4b2U, 0x312a3f23U, 0x30c6a594U, 0xc035a266U,
-    0x37744ebcU, 0xa6fc82caU, 0xb0e090d0U, 0x1533a7d8U,
-    0x4af10498U, 0xf741ecdaU, 0x0e7fcd50U, 0x2f1791f6U,
-    0x8d764dd6U, 0x4d43efb0U, 0x54ccaa4dU, 0xdfe49604U,
-    0xe39ed1b5U, 0x1b4c6a88U, 0xb8c12c1fU, 0x7f466551U,
-    0x049d5eeaU, 0x5d018c35U, 0x73fa8774U, 0x2efb0b41U,
-    0x5ab3671dU, 0x5292dbd2U, 0x33e91056U, 0x136dd647U,
-    0x8c9ad761U, 0x7a37a10cU, 0x8e59f814U, 0x89eb133cU,
-    0xeecea927U, 0x35b761c9U, 0xede11ce5U, 0x3c7a47b1U,
-    0x599cd2dfU, 0x3f55f273U, 0x791814ceU, 0xbf73c737U,
-    0xea53f7cdU, 0x5b5ffdaaU, 0x14df3d6fU, 0x867844dbU,
-    0x81caaff3U, 0x3eb968c4U, 0x2c382434U, 0x5fc2a340U,
-    0x72161dc3U, 0x0cbce225U, 0x8b283c49U, 0x41ff0d95U,
-    0x7139a801U, 0xde080cb3U, 0x9cd8b4e4U, 0x906456c1U,
-    0x617bcb84U, 0x70d532b6U, 0x74486c5cU, 0x42d0b857U,
-};
-static const u32 Td2[256] = {
-    0xa75051f4U, 0x65537e41U, 0xa4c31a17U, 0x5e963a27U,
-    0x6bcb3babU, 0x45f11f9dU, 0x58abacfaU, 0x03934be3U,
-    0xfa552030U, 0x6df6ad76U, 0x769188ccU, 0x4c25f502U,
-    0xd7fc4fe5U, 0xcbd7c52aU, 0x44802635U, 0xa38fb562U,
-    0x5a49deb1U, 0x1b6725baU, 0x0e9845eaU, 0xc0e15dfeU,
-    0x7502c32fU, 0xf012814cU, 0x97a38d46U, 0xf9c66bd3U,
-    0x5fe7038fU, 0x9c951592U, 0x7aebbf6dU, 0x59da9552U,
-    0x832dd4beU, 0x21d35874U, 0x692949e0U, 0xc8448ec9U,
-    0x896a75c2U, 0x7978f48eU, 0x3e6b9958U, 0x71dd27b9U,
-    0x4fb6bee1U, 0xad17f088U, 0xac66c920U, 0x3ab47dceU,
-    0x4a1863dfU, 0x3182e51aU, 0x33609751U, 0x7f456253U,
-    0x77e0b164U, 0xae84bb6bU, 0xa01cfe81U, 0x2b94f908U,
-    0x68587048U, 0xfd198f45U, 0x6c8794deU, 0xf8b7527bU,
-    0xd323ab73U, 0x02e2724bU, 0x8f57e31fU, 0xab2a6655U,
-    0x2807b2ebU, 0xc2032fb5U, 0x7b9a86c5U, 0x08a5d337U,
-    0x87f23028U, 0xa5b223bfU, 0x6aba0203U, 0x825ced16U,
-    0x1c2b8acfU, 0xb492a779U, 0xf2f0f307U, 0xe2a14e69U,
-    0xf4cd65daU, 0xbed50605U, 0x621fd134U, 0xfe8ac4a6U,
-    0x539d342eU, 0x55a0a2f3U, 0xe132058aU, 0xeb75a4f6U,
-    0xec390b83U, 0xefaa4060U, 0x9f065e71U, 0x1051bd6eU,
-
-    0x8af93e21U, 0x063d96ddU, 0x05aedd3eU, 0xbd464de6U,
-    0x8db59154U, 0x5d0571c4U, 0xd46f0406U, 0x15ff6050U,
-    0xfb241998U, 0xe997d6bdU, 0x43cc8940U, 0x9e7767d9U,
-    0x42bdb0e8U, 0x8b880789U, 0x5b38e719U, 0xeedb79c8U,
-    0x0a47a17cU, 0x0fe97c42U, 0x1ec9f884U, 0x00000000U,
-    0x86830980U, 0xed48322bU, 0x70ac1e11U, 0x724e6c5aU,
-    0xfffbfd0eU, 0x38560f85U, 0xd51e3daeU, 0x3927362dU,
-    0xd9640a0fU, 0xa621685cU, 0x54d19b5bU, 0x2e3a2436U,
-    0x67b10c0aU, 0xe70f9357U, 0x96d2b4eeU, 0x919e1b9bU,
-    0xc54f80c0U, 0x20a261dcU, 0x4b695a77U, 0x1a161c12U,
-    0xba0ae293U, 0x2ae5c0a0U, 0xe0433c22U, 0x171d121bU,
-    0x0d0b0e09U, 0xc7adf28bU, 0xa8b92db6U, 0xa9c8141eU,
-    0x198557f1U, 0x074caf75U, 0xddbbee99U, 0x60fda37fU,
-    0x269ff701U, 0xf5bc5c72U, 0x3bc54466U, 0x7e345bfbU,
-    0x29768b43U, 0xc6dccb23U, 0xfc68b6edU, 0xf163b8e4U,
-    0xdccad731U, 0x85104263U, 0x22401397U, 0x112084c6U,
-    0x247d854aU, 0x3df8d2bbU, 0x3211aef9U, 0xa16dc729U,
-    0x2f4b1d9eU, 0x30f3dcb2U, 0x52ec0d86U, 0xe3d077c1U,
-    0x166c2bb3U, 0xb999a970U, 0x48fa1194U, 0x642247e9U,
-    0x8cc4a8fcU, 0x3f1aa0f0U, 0x2cd8567dU, 0x90ef2233U,
-    0x4ec78749U, 0xd1c1d938U, 0xa2fe8ccaU, 0x0b3698d4U,
-    0x81cfa6f5U, 0xde28a57aU, 0x8e26dab7U, 0xbfa43fadU,
-    0x9de42c3aU, 0x920d5078U, 0xcc9b6a5fU, 0x4662547eU,
-    0x13c2f68dU, 0xb8e890d8U, 0xf75e2e39U, 0xaff582c3U,
-    0x80be9f5dU, 0x937c69d0U, 0x2da96fd5U, 0x12b3cf25U,
-    0x993bc8acU, 0x7da71018U, 0x636ee89cU, 0xbb7bdb3bU,
-    0x7809cd26U, 0x18f46e59U, 0xb701ec9aU, 0x9aa8834fU,
-    0x6e65e695U, 0xe67eaaffU, 0xcf0821bcU, 0xe8e6ef15U,
-    0x9bd9bae7U, 0x36ce4a6fU, 0x09d4ea9fU, 0x7cd629b0U,
-    0xb2af31a4U, 0x23312a3fU, 0x9430c6a5U, 0x66c035a2U,
-    0xbc37744eU, 0xcaa6fc82U, 0xd0b0e090U, 0xd81533a7U,
-    0x984af104U, 0xdaf741ecU, 0x500e7fcdU, 0xf62f1791U,
-    0xd68d764dU, 0xb04d43efU, 0x4d54ccaaU, 0x04dfe496U,
-    0xb5e39ed1U, 0x881b4c6aU, 0x1fb8c12cU, 0x517f4665U,
-    0xea049d5eU, 0x355d018cU, 0x7473fa87U, 0x412efb0bU,
-    0x1d5ab367U, 0xd25292dbU, 0x5633e910U, 0x47136dd6U,
-    0x618c9ad7U, 0x0c7a37a1U, 0x148e59f8U, 0x3c89eb13U,
-    0x27eecea9U, 0xc935b761U, 0xe5ede11cU, 0xb13c7a47U,
-    0xdf599cd2U, 0x733f55f2U, 0xce791814U, 0x37bf73c7U,
-    0xcdea53f7U, 0xaa5b5ffdU, 0x6f14df3dU, 0xdb867844U,
-    0xf381caafU, 0xc43eb968U, 0x342c3824U, 0x405fc2a3U,
-    0xc372161dU, 0x250cbce2U, 0x498b283cU, 0x9541ff0dU,
-    0x017139a8U, 0xb3de080cU, 0xe49cd8b4U, 0xc1906456U,
-    0x84617bcbU, 0xb670d532U, 0x5c74486cU, 0x5742d0b8U,
-};
-static const u32 Td3[256] = {
-    0xf4a75051U, 0x4165537eU, 0x17a4c31aU, 0x275e963aU,
-    0xab6bcb3bU, 0x9d45f11fU, 0xfa58abacU, 0xe303934bU,
-    0x30fa5520U, 0x766df6adU, 0xcc769188U, 0x024c25f5U,
-    0xe5d7fc4fU, 0x2acbd7c5U, 0x35448026U, 0x62a38fb5U,
-    0xb15a49deU, 0xba1b6725U, 0xea0e9845U, 0xfec0e15dU,
-    0x2f7502c3U, 0x4cf01281U, 0x4697a38dU, 0xd3f9c66bU,
-    0x8f5fe703U, 0x929c9515U, 0x6d7aebbfU, 0x5259da95U,
-    0xbe832dd4U, 0x7421d358U, 0xe0692949U, 0xc9c8448eU,
-    0xc2896a75U, 0x8e7978f4U, 0x583e6b99U, 0xb971dd27U,
-    0xe14fb6beU, 0x88ad17f0U, 0x20ac66c9U, 0xce3ab47dU,
-    0xdf4a1863U, 0x1a3182e5U, 0x51336097U, 0x537f4562U,
-    0x6477e0b1U, 0x6bae84bbU, 0x81a01cfeU, 0x082b94f9U,
-    0x48685870U, 0x45fd198fU, 0xde6c8794U, 0x7bf8b752U,
-    0x73d323abU, 0x4b02e272U, 0x1f8f57e3U, 0x55ab2a66U,
-    0xeb2807b2U, 0xb5c2032fU, 0xc57b9a86U, 0x3708a5d3U,
-    0x2887f230U, 0xbfa5b223U, 0x036aba02U, 0x16825cedU,
-    0xcf1c2b8aU, 0x79b492a7U, 0x07f2f0f3U, 0x69e2a14eU,
-    0xdaf4cd65U, 0x05bed506U, 0x34621fd1U, 0xa6fe8ac4U,
-    0x2e539d34U, 0xf355a0a2U, 0x8ae13205U, 0xf6eb75a4U,
-    0x83ec390bU, 0x60efaa40U, 0x719f065eU, 0x6e1051bdU,
-    0x218af93eU, 0xdd063d96U, 0x3e05aeddU, 0xe6bd464dU,
-    0x548db591U, 0xc45d0571U, 0x06d46f04U, 0x5015ff60U,
-    0x98fb2419U, 0xbde997d6U, 0x4043cc89U, 0xd99e7767U,
-    0xe842bdb0U, 0x898b8807U, 0x195b38e7U, 0xc8eedb79U,
-    0x7c0a47a1U, 0x420fe97cU, 0x841ec9f8U, 0x00000000U,
-    0x80868309U, 0x2bed4832U, 0x1170ac1eU, 0x5a724e6cU,
-    0x0efffbfdU, 0x8538560fU, 0xaed51e3dU, 0x2d392736U,
-    0x0fd9640aU, 0x5ca62168U, 0x5b54d19bU, 0x362e3a24U,
-    0x0a67b10cU, 0x57e70f93U, 0xee96d2b4U, 0x9b919e1bU,
-    0xc0c54f80U, 0xdc20a261U, 0x774b695aU, 0x121a161cU,
-    0x93ba0ae2U, 0xa02ae5c0U, 0x22e0433cU, 0x1b171d12U,
-    0x090d0b0eU, 0x8bc7adf2U, 0xb6a8b92dU, 0x1ea9c814U,
-    0xf1198557U, 0x75074cafU, 0x99ddbbeeU, 0x7f60fda3U,
-    0x01269ff7U, 0x72f5bc5cU, 0x663bc544U, 0xfb7e345bU,
-    0x4329768bU, 0x23c6dccbU, 0xedfc68b6U, 0xe4f163b8U,
-    0x31dccad7U, 0x63851042U, 0x97224013U, 0xc6112084U,
-    0x4a247d85U, 0xbb3df8d2U, 0xf93211aeU, 0x29a16dc7U,
-    0x9e2f4b1dU, 0xb230f3dcU, 0x8652ec0dU, 0xc1e3d077U,
-    0xb3166c2bU, 0x70b999a9U, 0x9448fa11U, 0xe9642247U,
-    0xfc8cc4a8U, 0xf03f1aa0U, 0x7d2cd856U, 0x3390ef22U,
-    0x494ec787U, 0x38d1c1d9U, 0xcaa2fe8cU, 0xd40b3698U,
-    0xf581cfa6U, 0x7ade28a5U, 0xb78e26daU, 0xadbfa43fU,
-    0x3a9de42cU, 0x78920d50U, 0x5fcc9b6aU, 0x7e466254U,
-    0x8d13c2f6U, 0xd8b8e890U, 0x39f75e2eU, 0xc3aff582U,
-    0x5d80be9fU, 0xd0937c69U, 0xd52da96fU, 0x2512b3cfU,
-    0xac993bc8U, 0x187da710U, 0x9c636ee8U, 0x3bbb7bdbU,
-    0x267809cdU, 0x5918f46eU, 0x9ab701ecU, 0x4f9aa883U,
-    0x956e65e6U, 0xffe67eaaU, 0xbccf0821U, 0x15e8e6efU,
-    0xe79bd9baU, 0x6f36ce4aU, 0x9f09d4eaU, 0xb07cd629U,
-    0xa4b2af31U, 0x3f23312aU, 0xa59430c6U, 0xa266c035U,
-    0x4ebc3774U, 0x82caa6fcU, 0x90d0b0e0U, 0xa7d81533U,
-    0x04984af1U, 0xecdaf741U, 0xcd500e7fU, 0x91f62f17U,
-    0x4dd68d76U, 0xefb04d43U, 0xaa4d54ccU, 0x9604dfe4U,
-    0xd1b5e39eU, 0x6a881b4cU, 0x2c1fb8c1U, 0x65517f46U,
-    0x5eea049dU, 0x8c355d01U, 0x877473faU, 0x0b412efbU,
-    0x671d5ab3U, 0xdbd25292U, 0x105633e9U, 0xd647136dU,
-    0xd7618c9aU, 0xa10c7a37U, 0xf8148e59U, 0x133c89ebU,
-    0xa927eeceU, 0x61c935b7U, 0x1ce5ede1U, 0x47b13c7aU,
-    0xd2df599cU, 0xf2733f55U, 0x14ce7918U, 0xc737bf73U,
-    0xf7cdea53U, 0xfdaa5b5fU, 0x3d6f14dfU, 0x44db8678U,
-    0xaff381caU, 0x68c43eb9U, 0x24342c38U, 0xa3405fc2U,
-    0x1dc37216U, 0xe2250cbcU, 0x3c498b28U, 0x0d9541ffU,
-    0xa8017139U, 0x0cb3de08U, 0xb4e49cd8U, 0x56c19064U,
-    0xcb84617bU, 0x32b670d5U, 0x6c5c7448U, 0xb85742d0U,
-};
-static const u32 Td4[256] = {
-    0x52525252U, 0x09090909U, 0x6a6a6a6aU, 0xd5d5d5d5U,
-    0x30303030U, 0x36363636U, 0xa5a5a5a5U, 0x38383838U,
-    0xbfbfbfbfU, 0x40404040U, 0xa3a3a3a3U, 0x9e9e9e9eU,
-    0x81818181U, 0xf3f3f3f3U, 0xd7d7d7d7U, 0xfbfbfbfbU,
-    0x7c7c7c7cU, 0xe3e3e3e3U, 0x39393939U, 0x82828282U,
-    0x9b9b9b9bU, 0x2f2f2f2fU, 0xffffffffU, 0x87878787U,
-    0x34343434U, 0x8e8e8e8eU, 0x43434343U, 0x44444444U,
-    0xc4c4c4c4U, 0xdedededeU, 0xe9e9e9e9U, 0xcbcbcbcbU,
-    0x54545454U, 0x7b7b7b7bU, 0x94949494U, 0x32323232U,
-    0xa6a6a6a6U, 0xc2c2c2c2U, 0x23232323U, 0x3d3d3d3dU,
-    0xeeeeeeeeU, 0x4c4c4c4cU, 0x95959595U, 0x0b0b0b0bU,
-    0x42424242U, 0xfafafafaU, 0xc3c3c3c3U, 0x4e4e4e4eU,
-    0x08080808U, 0x2e2e2e2eU, 0xa1a1a1a1U, 0x66666666U,
-    0x28282828U, 0xd9d9d9d9U, 0x24242424U, 0xb2b2b2b2U,
-    0x76767676U, 0x5b5b5b5bU, 0xa2a2a2a2U, 0x49494949U,
-    0x6d6d6d6dU, 0x8b8b8b8bU, 0xd1d1d1d1U, 0x25252525U,
-    0x72727272U, 0xf8f8f8f8U, 0xf6f6f6f6U, 0x64646464U,
-    0x86868686U, 0x68686868U, 0x98989898U, 0x16161616U,
-    0xd4d4d4d4U, 0xa4a4a4a4U, 0x5c5c5c5cU, 0xccccccccU,
-    0x5d5d5d5dU, 0x65656565U, 0xb6b6b6b6U, 0x92929292U,
-    0x6c6c6c6cU, 0x70707070U, 0x48484848U, 0x50505050U,
-    0xfdfdfdfdU, 0xededededU, 0xb9b9b9b9U, 0xdadadadaU,
-    0x5e5e5e5eU, 0x15151515U, 0x46464646U, 0x57575757U,
-    0xa7a7a7a7U, 0x8d8d8d8dU, 0x9d9d9d9dU, 0x84848484U,
-    0x90909090U, 0xd8d8d8d8U, 0xababababU, 0x00000000U,
-    0x8c8c8c8cU, 0xbcbcbcbcU, 0xd3d3d3d3U, 0x0a0a0a0aU,
-    0xf7f7f7f7U, 0xe4e4e4e4U, 0x58585858U, 0x05050505U,
-    0xb8b8b8b8U, 0xb3b3b3b3U, 0x45454545U, 0x06060606U,
-    0xd0d0d0d0U, 0x2c2c2c2cU, 0x1e1e1e1eU, 0x8f8f8f8fU,
-    0xcacacacaU, 0x3f3f3f3fU, 0x0f0f0f0fU, 0x02020202U,
-    0xc1c1c1c1U, 0xafafafafU, 0xbdbdbdbdU, 0x03030303U,
-    0x01010101U, 0x13131313U, 0x8a8a8a8aU, 0x6b6b6b6bU,
-    0x3a3a3a3aU, 0x91919191U, 0x11111111U, 0x41414141U,
-    0x4f4f4f4fU, 0x67676767U, 0xdcdcdcdcU, 0xeaeaeaeaU,
-    0x97979797U, 0xf2f2f2f2U, 0xcfcfcfcfU, 0xcecececeU,
-    0xf0f0f0f0U, 0xb4b4b4b4U, 0xe6e6e6e6U, 0x73737373U,
-    0x96969696U, 0xacacacacU, 0x74747474U, 0x22222222U,
-    0xe7e7e7e7U, 0xadadadadU, 0x35353535U, 0x85858585U,
-    0xe2e2e2e2U, 0xf9f9f9f9U, 0x37373737U, 0xe8e8e8e8U,
-    0x1c1c1c1cU, 0x75757575U, 0xdfdfdfdfU, 0x6e6e6e6eU,
-    0x47474747U, 0xf1f1f1f1U, 0x1a1a1a1aU, 0x71717171U,
-    0x1d1d1d1dU, 0x29292929U, 0xc5c5c5c5U, 0x89898989U,
-    0x6f6f6f6fU, 0xb7b7b7b7U, 0x62626262U, 0x0e0e0e0eU,
-    0xaaaaaaaaU, 0x18181818U, 0xbebebebeU, 0x1b1b1b1bU,
-    0xfcfcfcfcU, 0x56565656U, 0x3e3e3e3eU, 0x4b4b4b4bU,
-    0xc6c6c6c6U, 0xd2d2d2d2U, 0x79797979U, 0x20202020U,
-    0x9a9a9a9aU, 0xdbdbdbdbU, 0xc0c0c0c0U, 0xfefefefeU,
-    0x78787878U, 0xcdcdcdcdU, 0x5a5a5a5aU, 0xf4f4f4f4U,
-    0x1f1f1f1fU, 0xddddddddU, 0xa8a8a8a8U, 0x33333333U,
-    0x88888888U, 0x07070707U, 0xc7c7c7c7U, 0x31313131U,
-    0xb1b1b1b1U, 0x12121212U, 0x10101010U, 0x59595959U,
-    0x27272727U, 0x80808080U, 0xececececU, 0x5f5f5f5fU,
-    0x60606060U, 0x51515151U, 0x7f7f7f7fU, 0xa9a9a9a9U,
-    0x19191919U, 0xb5b5b5b5U, 0x4a4a4a4aU, 0x0d0d0d0dU,
-    0x2d2d2d2dU, 0xe5e5e5e5U, 0x7a7a7a7aU, 0x9f9f9f9fU,
-    0x93939393U, 0xc9c9c9c9U, 0x9c9c9c9cU, 0xefefefefU,
-    0xa0a0a0a0U, 0xe0e0e0e0U, 0x3b3b3b3bU, 0x4d4d4d4dU,
-    0xaeaeaeaeU, 0x2a2a2a2aU, 0xf5f5f5f5U, 0xb0b0b0b0U,
-    0xc8c8c8c8U, 0xebebebebU, 0xbbbbbbbbU, 0x3c3c3c3cU,
-    0x83838383U, 0x53535353U, 0x99999999U, 0x61616161U,
-    0x17171717U, 0x2b2b2b2bU, 0x04040404U, 0x7e7e7e7eU,
-    0xbabababaU, 0x77777777U, 0xd6d6d6d6U, 0x26262626U,
-    0xe1e1e1e1U, 0x69696969U, 0x14141414U, 0x63636363U,
-    0x55555555U, 0x21212121U, 0x0c0c0c0cU, 0x7d7d7d7dU,
-};
-static const u32 rcon[] = {
-	0x01000000, 0x02000000, 0x04000000, 0x08000000,
-	0x10000000, 0x20000000, 0x40000000, 0x80000000,
-	0x1B000000, 0x36000000, /* for 128-bit blocks, Rijndael never uses more than 10 rcon values */
-};
-
-/**
- * Expand the cipher key into the encryption key schedule.
- */
-int AES_set_encrypt_key(const unsigned char *userKey, const int bits,
-			AES_KEY *key) {
-
-	u32 *rk;
-   	int i = 0;
-	u32 temp;
-
-	if (!userKey || !key)
-		return -1;
-	if (bits != 128 && bits != 192 && bits != 256)
-		return -2;
-
-	rk = key->rd_key;
-
-	if (bits==128)
-		key->rounds = 10;
-	else if (bits==192)
-		key->rounds = 12;
-	else
-		key->rounds = 14;
-
-	rk[0] = GETU32(userKey     );
-	rk[1] = GETU32(userKey +  4);
-	rk[2] = GETU32(userKey +  8);
-	rk[3] = GETU32(userKey + 12);
-	if (bits == 128) {
-		while (1) {
-			temp  = rk[3];
-			rk[4] = rk[0] ^
-				(Te4[(temp >> 16) & 0xff] & 0xff000000) ^
-				(Te4[(temp >>  8) & 0xff] & 0x00ff0000) ^
-				(Te4[(temp      ) & 0xff] & 0x0000ff00) ^
-				(Te4[(temp >> 24)       ] & 0x000000ff) ^
-				rcon[i];
-			rk[5] = rk[1] ^ rk[4];
-			rk[6] = rk[2] ^ rk[5];
-			rk[7] = rk[3] ^ rk[6];
-			if (++i == 10) {
-				return 0;
-			}
-			rk += 4;
-		}
-	}
-	rk[4] = GETU32(userKey + 16);
-	rk[5] = GETU32(userKey + 20);
-	if (bits == 192) {
-		while (1) {
-			temp = rk[ 5];
-			rk[ 6] = rk[ 0] ^
-				(Te4[(temp >> 16) & 0xff] & 0xff000000) ^
-				(Te4[(temp >>  8) & 0xff] & 0x00ff0000) ^
-				(Te4[(temp      ) & 0xff] & 0x0000ff00) ^
-				(Te4[(temp >> 24)       ] & 0x000000ff) ^
-				rcon[i];
-			rk[ 7] = rk[ 1] ^ rk[ 6];
-			rk[ 8] = rk[ 2] ^ rk[ 7];
-			rk[ 9] = rk[ 3] ^ rk[ 8];
-			if (++i == 8) {
-				return 0;
-			}
-			rk[10] = rk[ 4] ^ rk[ 9];
-			rk[11] = rk[ 5] ^ rk[10];
-			rk += 6;
-		}
-	}
-	rk[6] = GETU32(userKey + 24);
-	rk[7] = GETU32(userKey + 28);
-	if (bits == 256) {
-		while (1) {
-			temp = rk[ 7];
-			rk[ 8] = rk[ 0] ^
-				(Te4[(temp >> 16) & 0xff] & 0xff000000) ^
-				(Te4[(temp >>  8) & 0xff] & 0x00ff0000) ^
-				(Te4[(temp      ) & 0xff] & 0x0000ff00) ^
-				(Te4[(temp >> 24)       ] & 0x000000ff) ^
-				rcon[i];
-			rk[ 9] = rk[ 1] ^ rk[ 8];
-			rk[10] = rk[ 2] ^ rk[ 9];
-			rk[11] = rk[ 3] ^ rk[10];
-			if (++i == 7) {
-				return 0;
-			}
-			temp = rk[11];
-			rk[12] = rk[ 4] ^
-				(Te4[(temp >> 24)       ] & 0xff000000) ^
-				(Te4[(temp >> 16) & 0xff] & 0x00ff0000) ^
-				(Te4[(temp >>  8) & 0xff] & 0x0000ff00) ^
-				(Te4[(temp      ) & 0xff] & 0x000000ff);
-			rk[13] = rk[ 5] ^ rk[12];
-			rk[14] = rk[ 6] ^ rk[13];
-			rk[15] = rk[ 7] ^ rk[14];
-
-			rk += 8;
-        	}
-	}
-	return 0;
-}
-
-/**
- * Expand the cipher key into the decryption key schedule.
- */
-int AES_set_decrypt_key(const unsigned char *userKey, const int bits,
-			 AES_KEY *key) {
-
-        u32 *rk;
-	int i, j, status;
-	u32 temp;
-
-	/* first, start with an encryption schedule */
-	status = AES_set_encrypt_key(userKey, bits, key);
-	if (status < 0)
-		return status;
-
-	rk = key->rd_key;
-
-	/* invert the order of the round keys: */
-	for (i = 0, j = 4*(key->rounds); i < j; i += 4, j -= 4) {
-		temp = rk[i    ]; rk[i    ] = rk[j    ]; rk[j    ] = temp;
-		temp = rk[i + 1]; rk[i + 1] = rk[j + 1]; rk[j + 1] = temp;
-		temp = rk[i + 2]; rk[i + 2] = rk[j + 2]; rk[j + 2] = temp;
-		temp = rk[i + 3]; rk[i + 3] = rk[j + 3]; rk[j + 3] = temp;
-	}
-	/* apply the inverse MixColumn transform to all round keys but the first and the last: */
-	for (i = 1; i < (key->rounds); i++) {
-		rk += 4;
-		rk[0] =
-			Td0[Te4[(rk[0] >> 24)       ] & 0xff] ^
-			Td1[Te4[(rk[0] >> 16) & 0xff] & 0xff] ^
-			Td2[Te4[(rk[0] >>  8) & 0xff] & 0xff] ^
-			Td3[Te4[(rk[0]      ) & 0xff] & 0xff];
-		rk[1] =
-			Td0[Te4[(rk[1] >> 24)       ] & 0xff] ^
-			Td1[Te4[(rk[1] >> 16) & 0xff] & 0xff] ^
-			Td2[Te4[(rk[1] >>  8) & 0xff] & 0xff] ^
-			Td3[Te4[(rk[1]      ) & 0xff] & 0xff];
-		rk[2] =
-			Td0[Te4[(rk[2] >> 24)       ] & 0xff] ^
-			Td1[Te4[(rk[2] >> 16) & 0xff] & 0xff] ^
-			Td2[Te4[(rk[2] >>  8) & 0xff] & 0xff] ^
-			Td3[Te4[(rk[2]      ) & 0xff] & 0xff];
-		rk[3] =
-			Td0[Te4[(rk[3] >> 24)       ] & 0xff] ^
-			Td1[Te4[(rk[3] >> 16) & 0xff] & 0xff] ^
-			Td2[Te4[(rk[3] >>  8) & 0xff] & 0xff] ^
-			Td3[Te4[(rk[3]      ) & 0xff] & 0xff];
-	}
-	return 0;
-}
-
-#ifndef AES_ASM
-/*
- * Encrypt a single block
- * in and out can overlap
- */
-void AES_encrypt(const unsigned char *in, unsigned char *out,
-		 const AES_KEY *key) {
-
-	const u32 *rk;
-	u32 s0, s1, s2, s3, t0, t1, t2, t3;
-#ifndef FULL_UNROLL
-	int r;
-#endif /* ?FULL_UNROLL */
-
-	assert(in && out && key);
-	rk = key->rd_key;
-
-	/*
-	 * map byte array block to cipher state
-	 * and add initial round key:
-	 */
-	s0 = GETU32(in     ) ^ rk[0];
-	s1 = GETU32(in +  4) ^ rk[1];
-	s2 = GETU32(in +  8) ^ rk[2];
-	s3 = GETU32(in + 12) ^ rk[3];
-#ifdef FULL_UNROLL
-	/* round 1: */
-   	t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[ 4];
-   	t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[ 5];
-   	t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[ 6];
-   	t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[ 7];
-   	/* round 2: */
-   	s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[ 8];
-   	s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[ 9];
-   	s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[10];
-   	s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[11];
-	/* round 3: */
-   	t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[12];
-   	t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[13];
-   	t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[14];
-   	t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[15];
-   	/* round 4: */
-   	s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[16];
-   	s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[17];
-   	s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[18];
-   	s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[19];
-	/* round 5: */
-   	t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[20];
-   	t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[21];
-   	t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[22];
-   	t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[23];
-   	/* round 6: */
-   	s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[24];
-   	s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[25];
-   	s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[26];
-   	s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[27];
-	/* round 7: */
-   	t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[28];
-   	t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[29];
-   	t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[30];
-   	t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[31];
-   	/* round 8: */
-   	s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[32];
-   	s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[33];
-   	s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[34];
-   	s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[35];
-	/* round 9: */
-   	t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[36];
-   	t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[37];
-   	t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[38];
-   	t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[39];
-    if (key->rounds > 10) {
-        /* round 10: */
-        s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[40];
-        s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[41];
-        s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[42];
-        s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[43];
-        /* round 11: */
-        t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[44];
-        t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[45];
-        t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[46];
-        t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[47];
-        if (key->rounds > 12) {
-            /* round 12: */
-            s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >>  8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[48];
-            s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >>  8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[49];
-            s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >>  8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[50];
-            s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >>  8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[51];
-            /* round 13: */
-            t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >>  8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[52];
-            t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >>  8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[53];
-            t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >>  8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[54];
-            t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >>  8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[55];
-        }
-    }
-    rk += key->rounds << 2;
-#else  /* !FULL_UNROLL */
-    /*
-     * Nr - 1 full rounds:
-     */
-    r = key->rounds >> 1;
-    for (;;) {
-        t0 =
-            Te0[(s0 >> 24)       ] ^
-            Te1[(s1 >> 16) & 0xff] ^
-            Te2[(s2 >>  8) & 0xff] ^
-            Te3[(s3      ) & 0xff] ^
-            rk[4];
-        t1 =
-            Te0[(s1 >> 24)       ] ^
-            Te1[(s2 >> 16) & 0xff] ^
-            Te2[(s3 >>  8) & 0xff] ^
-            Te3[(s0      ) & 0xff] ^
-            rk[5];
-        t2 =
-            Te0[(s2 >> 24)       ] ^
-            Te1[(s3 >> 16) & 0xff] ^
-            Te2[(s0 >>  8) & 0xff] ^
-            Te3[(s1      ) & 0xff] ^
-            rk[6];
-        t3 =
-            Te0[(s3 >> 24)       ] ^
-            Te1[(s0 >> 16) & 0xff] ^
-            Te2[(s1 >>  8) & 0xff] ^
-            Te3[(s2      ) & 0xff] ^
-            rk[7];
-
-        rk += 8;
-        if (--r == 0) {
-            break;
-        }
-
-        s0 =
-            Te0[(t0 >> 24)       ] ^
-            Te1[(t1 >> 16) & 0xff] ^
-            Te2[(t2 >>  8) & 0xff] ^
-            Te3[(t3      ) & 0xff] ^
-            rk[0];
-        s1 =
-            Te0[(t1 >> 24)       ] ^
-            Te1[(t2 >> 16) & 0xff] ^
-            Te2[(t3 >>  8) & 0xff] ^
-            Te3[(t0      ) & 0xff] ^
-            rk[1];
-        s2 =
-            Te0[(t2 >> 24)       ] ^
-            Te1[(t3 >> 16) & 0xff] ^
-            Te2[(t0 >>  8) & 0xff] ^
-            Te3[(t1      ) & 0xff] ^
-            rk[2];
-        s3 =
-            Te0[(t3 >> 24)       ] ^
-            Te1[(t0 >> 16) & 0xff] ^
-            Te2[(t1 >>  8) & 0xff] ^
-            Te3[(t2      ) & 0xff] ^
-            rk[3];
-    }
-#endif /* ?FULL_UNROLL */
-    /*
-	 * apply last round and
-	 * map cipher state to byte array block:
-	 */
-	s0 =
-		(Te4[(t0 >> 24)       ] & 0xff000000) ^
-		(Te4[(t1 >> 16) & 0xff] & 0x00ff0000) ^
-		(Te4[(t2 >>  8) & 0xff] & 0x0000ff00) ^
-		(Te4[(t3      ) & 0xff] & 0x000000ff) ^
-		rk[0];
-	PUTU32(out     , s0);
-	s1 =
-		(Te4[(t1 >> 24)       ] & 0xff000000) ^
-		(Te4[(t2 >> 16) & 0xff] & 0x00ff0000) ^
-		(Te4[(t3 >>  8) & 0xff] & 0x0000ff00) ^
-		(Te4[(t0      ) & 0xff] & 0x000000ff) ^
-		rk[1];
-	PUTU32(out +  4, s1);
-	s2 =
-		(Te4[(t2 >> 24)       ] & 0xff000000) ^
-		(Te4[(t3 >> 16) & 0xff] & 0x00ff0000) ^
-		(Te4[(t0 >>  8) & 0xff] & 0x0000ff00) ^
-		(Te4[(t1      ) & 0xff] & 0x000000ff) ^
-		rk[2];
-	PUTU32(out +  8, s2);
-	s3 =
-		(Te4[(t3 >> 24)       ] & 0xff000000) ^
-		(Te4[(t0 >> 16) & 0xff] & 0x00ff0000) ^
-		(Te4[(t1 >>  8) & 0xff] & 0x0000ff00) ^
-		(Te4[(t2      ) & 0xff] & 0x000000ff) ^
-		rk[3];
-	PUTU32(out + 12, s3);
-}
-
-/*
- * Decrypt a single block
- * in and out can overlap
- */
-void AES_decrypt(const unsigned char *in, unsigned char *out,
-		 const AES_KEY *key) {
-
-	const u32 *rk;
-	u32 s0, s1, s2, s3, t0, t1, t2, t3;
-#ifndef FULL_UNROLL
-	int r;
-#endif /* ?FULL_UNROLL */
-
-	assert(in && out && key);
-	rk = key->rd_key;
-
-	/*
-	 * map byte array block to cipher state
-	 * and add initial round key:
-	 */
-    s0 = GETU32(in     ) ^ rk[0];
-    s1 = GETU32(in +  4) ^ rk[1];
-    s2 = GETU32(in +  8) ^ rk[2];
-    s3 = GETU32(in + 12) ^ rk[3];
-#ifdef FULL_UNROLL
-    /* round 1: */
-    t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[ 4];
-    t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[ 5];
-    t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[ 6];
-    t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[ 7];
-    /* round 2: */
-    s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[ 8];
-    s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[ 9];
-    s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[10];
-    s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[11];
-    /* round 3: */
-    t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[12];
-    t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[13];
-    t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[14];
-    t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[15];
-    /* round 4: */
-    s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[16];
-    s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[17];
-    s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[18];
-    s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[19];
-    /* round 5: */
-    t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[20];
-    t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[21];
-    t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[22];
-    t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[23];
-    /* round 6: */
-    s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[24];
-    s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[25];
-    s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[26];
-    s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[27];
-    /* round 7: */
-    t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[28];
-    t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[29];
-    t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[30];
-    t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[31];
-    /* round 8: */
-    s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[32];
-    s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[33];
-    s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[34];
-    s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[35];
-    /* round 9: */
-    t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[36];
-    t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[37];
-    t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[38];
-    t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[39];
-    if (key->rounds > 10) {
-        /* round 10: */
-        s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[40];
-        s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[41];
-        s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[42];
-        s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[43];
-        /* round 11: */
-        t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[44];
-        t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[45];
-        t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[46];
-        t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[47];
-        if (key->rounds > 12) {
-            /* round 12: */
-            s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >>  8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[48];
-            s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >>  8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[49];
-            s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >>  8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[50];
-            s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >>  8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[51];
-            /* round 13: */
-            t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >>  8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[52];
-            t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >>  8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[53];
-            t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >>  8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[54];
-            t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >>  8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[55];
-        }
-    }
-	rk += key->rounds << 2;
-#else  /* !FULL_UNROLL */
-    /*
-     * Nr - 1 full rounds:
-     */
-    r = key->rounds >> 1;
-    for (;;) {
-        t0 =
-            Td0[(s0 >> 24)       ] ^
-            Td1[(s3 >> 16) & 0xff] ^
-            Td2[(s2 >>  8) & 0xff] ^
-            Td3[(s1      ) & 0xff] ^
-            rk[4];
-        t1 =
-            Td0[(s1 >> 24)       ] ^
-            Td1[(s0 >> 16) & 0xff] ^
-            Td2[(s3 >>  8) & 0xff] ^
-            Td3[(s2      ) & 0xff] ^
-            rk[5];
-        t2 =
-            Td0[(s2 >> 24)       ] ^
-            Td1[(s1 >> 16) & 0xff] ^
-            Td2[(s0 >>  8) & 0xff] ^
-            Td3[(s3      ) & 0xff] ^
-            rk[6];
-        t3 =
-            Td0[(s3 >> 24)       ] ^
-            Td1[(s2 >> 16) & 0xff] ^
-            Td2[(s1 >>  8) & 0xff] ^
-            Td3[(s0      ) & 0xff] ^
-            rk[7];
-
-        rk += 8;
-        if (--r == 0) {
-            break;
-        }
-
-        s0 =
-            Td0[(t0 >> 24)       ] ^
-            Td1[(t3 >> 16) & 0xff] ^
-            Td2[(t2 >>  8) & 0xff] ^
-            Td3[(t1      ) & 0xff] ^
-            rk[0];
-        s1 =
-            Td0[(t1 >> 24)       ] ^
-            Td1[(t0 >> 16) & 0xff] ^
-            Td2[(t3 >>  8) & 0xff] ^
-            Td3[(t2      ) & 0xff] ^
-            rk[1];
-        s2 =
-            Td0[(t2 >> 24)       ] ^
-            Td1[(t1 >> 16) & 0xff] ^
-            Td2[(t0 >>  8) & 0xff] ^
-            Td3[(t3      ) & 0xff] ^
-            rk[2];
-        s3 =
-            Td0[(t3 >> 24)       ] ^
-            Td1[(t2 >> 16) & 0xff] ^
-            Td2[(t1 >>  8) & 0xff] ^
-            Td3[(t0      ) & 0xff] ^
-            rk[3];
-    }
-#endif /* ?FULL_UNROLL */
-    /*
-	 * apply last round and
-	 * map cipher state to byte array block:
-	 */
-   	s0 =
-   		(Td4[(t0 >> 24)       ] & 0xff000000) ^
-   		(Td4[(t3 >> 16) & 0xff] & 0x00ff0000) ^
-   		(Td4[(t2 >>  8) & 0xff] & 0x0000ff00) ^
-   		(Td4[(t1      ) & 0xff] & 0x000000ff) ^
-   		rk[0];
-	PUTU32(out     , s0);
-   	s1 =
-   		(Td4[(t1 >> 24)       ] & 0xff000000) ^
-   		(Td4[(t0 >> 16) & 0xff] & 0x00ff0000) ^
-   		(Td4[(t3 >>  8) & 0xff] & 0x0000ff00) ^
-   		(Td4[(t2      ) & 0xff] & 0x000000ff) ^
-   		rk[1];
-	PUTU32(out +  4, s1);
-   	s2 =
-   		(Td4[(t2 >> 24)       ] & 0xff000000) ^
-   		(Td4[(t1 >> 16) & 0xff] & 0x00ff0000) ^
-   		(Td4[(t0 >>  8) & 0xff] & 0x0000ff00) ^
-   		(Td4[(t3      ) & 0xff] & 0x000000ff) ^
-   		rk[2];
-	PUTU32(out +  8, s2);
-   	s3 =
-   		(Td4[(t3 >> 24)       ] & 0xff000000) ^
-   		(Td4[(t2 >> 16) & 0xff] & 0x00ff0000) ^
-   		(Td4[(t1 >>  8) & 0xff] & 0x0000ff00) ^
-   		(Td4[(t0      ) & 0xff] & 0x000000ff) ^
-   		rk[3];
-	PUTU32(out + 12, s3);
-}
-
-#endif /* AES_ASM */
-
-void AES_cbc_encrypt(const unsigned char *in, unsigned char *out,
-		     const unsigned long length, const AES_KEY *key,
-		     unsigned char *ivec, const int enc) 
-{
-
-	unsigned long n;
-	unsigned long len = length;
-	unsigned char tmp[AES_BLOCK_SIZE];
-
-	assert(in && out && key && ivec);
-
-	if (enc) {
-		while (len >= AES_BLOCK_SIZE) {
-			for(n=0; n < AES_BLOCK_SIZE; ++n)
-				tmp[n] = in[n] ^ ivec[n];
-			AES_encrypt(tmp, out, key);
-			memcpy(ivec, out, AES_BLOCK_SIZE);
-			len -= AES_BLOCK_SIZE;
-			in += AES_BLOCK_SIZE;
-			out += AES_BLOCK_SIZE;
-		}
-		if (len) {
-			for(n=0; n < len; ++n)
-				tmp[n] = in[n] ^ ivec[n];
-			for(n=len; n < AES_BLOCK_SIZE; ++n)
-				tmp[n] = ivec[n];
-			AES_encrypt(tmp, tmp, key);
-			memcpy(out, tmp, AES_BLOCK_SIZE);
-			memcpy(ivec, tmp, AES_BLOCK_SIZE);
-		}			
-	} else {
-		while (len >= AES_BLOCK_SIZE) {
-			memcpy(tmp, in, AES_BLOCK_SIZE);
-			AES_decrypt(in, out, key);
-			for(n=0; n < AES_BLOCK_SIZE; ++n)
-				out[n] ^= ivec[n];
-			memcpy(ivec, tmp, AES_BLOCK_SIZE);
-			len -= AES_BLOCK_SIZE;
-			in += AES_BLOCK_SIZE;
-			out += AES_BLOCK_SIZE;
-		}
-		if (len) {
-			memcpy(tmp, in, AES_BLOCK_SIZE);
-			AES_decrypt(tmp, tmp, key);
-			for(n=0; n < len; ++n)
-				out[n] = tmp[n] ^ ivec[n];
-			memcpy(ivec, tmp, AES_BLOCK_SIZE);
-		}			
-	}
-}
diff --git a/tools/blktap/drivers/aes.h b/tools/blktap/drivers/aes.h
deleted file mode 100644
index 9fb54a9..0000000
--- a/tools/blktap/drivers/aes.h
+++ /dev/null
@@ -1,28 +0,0 @@
-#ifndef QEMU_AES_H
-#define QEMU_AES_H
-
-#include <stdint.h>
-
-#define AES_MAXNR 14
-#define AES_BLOCK_SIZE 16
-
-struct aes_key_st {
-    uint32_t rd_key[4 *(AES_MAXNR + 1)];
-    int rounds;
-};
-typedef struct aes_key_st AES_KEY;
-
-int AES_set_encrypt_key(const unsigned char *userKey, const int bits,
-	AES_KEY *key);
-int AES_set_decrypt_key(const unsigned char *userKey, const int bits,
-	AES_KEY *key);
-
-void AES_encrypt(const unsigned char *in, unsigned char *out,
-	const AES_KEY *key);
-void AES_decrypt(const unsigned char *in, unsigned char *out,
-	const AES_KEY *key);
-void AES_cbc_encrypt(const unsigned char *in, unsigned char *out,
-		     const unsigned long length, const AES_KEY *key,
-		     unsigned char *ivec, const int enc);
-
-#endif
diff --git a/tools/blktap/drivers/blk.h b/tools/blktap/drivers/blk.h
deleted file mode 100644
index 1cdc980..0000000
--- a/tools/blktap/drivers/blk.h
+++ /dev/null
@@ -1,3 +0,0 @@
-
-int blk_getimagesize(int fd, uint64_t *size);
-int blk_getsectorsize(int fd, uint64_t *sector_size);
diff --git a/tools/blktap/drivers/blk_linux.c b/tools/blktap/drivers/blk_linux.c
deleted file mode 100644
index bb52717..0000000
--- a/tools/blktap/drivers/blk_linux.c
+++ /dev/null
@@ -1,42 +0,0 @@
-#include <inttypes.h>
-#include <sys/ioctl.h>
-#include <sys/mount.h>
-#include "tapdisk.h"
-#include "blk.h"
-
-int blk_getimagesize(int fd, uint64_t *size)
-{
-	int rc;
-
-	*size = 0;
-	rc = ioctl(fd, BLKGETSIZE, size);
-	if (rc) {
-		DPRINTF("ERR: BLKGETSIZE failed, couldn't stat image");
-		return -EINVAL;
-	}
-
-	return 0;
-}
-
-int blk_getsectorsize(int fd, uint64_t *sector_size)
-{
-#if defined(BLKSSZGET)
-	int rc;
-
-	*sector_size = DEFAULT_SECTOR_SIZE;
-	rc = ioctl(fd, BLKSSZGET, sector_size);
-	if (rc) {
-		DPRINTF("ERR: BLKSSZGET failed. Falling back to use default sector size");
-		*sector_size = DEFAULT_SECTOR_SIZE;
-	}
-
-	if (*sector_size != DEFAULT_SECTOR_SIZE)
-		DPRINTF("Note: sector size is %"PRIu64" (not %u)\n",
-			*sector_size, DEFAULT_SECTOR_SIZE);
-#else
-	*sector_size = DEFAULT_SECTOR_SIZE;
-#endif
-
-	return 0;
-}
-
diff --git a/tools/blktap/drivers/blktapctrl.c b/tools/blktap/drivers/blktapctrl.c
deleted file mode 100644
index 0a8b880..0000000
--- a/tools/blktap/drivers/blktapctrl.c
+++ /dev/null
@@ -1,937 +0,0 @@
-/*
- * blktapctrl.c
- * 
- * userspace controller for the blktap disks.
- * As requests for new block devices arrive,
- * the controller spawns off a separate process
- * per-disk.
- *
- *
- * Copyright (c) 2005 Julian Chesterfield and Andrew Warfield.
- *
- * 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 <stdio.h>
-#include <stdlib.h>
-#include <sys/mman.h>
-#include <err.h>
-#include <errno.h>
-#include <sys/types.h>
-#include <sys/wait.h>
-#include <signal.h>
-#include <fcntl.h>
-#include <sys/poll.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include <unistd.h>
-#include <xenstore.h>
-#include <sys/time.h>
-#include <syslog.h>
-#ifdef MEMSHR
-#include <memshr.h>
-#endif
-#include <sys/stat.h>
-                                                                     
-#include "blktaplib.h"
-#include "blktapctrl.h"
-#include "tapdisk.h"
-#include "list.h"
-#include "xs_api.h" /* for xs_fire_next_watch() */
-
-#define PIDFILE "/var/run/blktapctrl.pid"
-
-#define NUM_POLL_FDS 2
-#define MSG_SIZE 4096
-#define MAX_TIMEOUT 10
-#define MAX_RAND_VAL 0xFFFF
-#define MAX_ATTEMPTS 10
-
-int run = 1;
-int max_timeout = MAX_TIMEOUT;
-int ctlfd = 0;
-
-int blktap_major;
-
-static int open_ctrl_socket(char *devname);
-static int write_msg(int fd, int msgtype, void *ptr, void *ptr2);
-static int read_msg(int fd, int msgtype, void *ptr);
-static driver_list_entry_t *active_disks[MAX_DISK_TYPES];
-
-
-static unsigned long long tapdisk_get_size(blkif_t *blkif)
-{
-	image_t *img = (image_t *)blkif->prv;
-	return img->size;
-}
-
-static unsigned long tapdisk_get_secsize(blkif_t *blkif)
-{
-	image_t *img = (image_t *)blkif->prv;
-	return img->secsize;
-}
-
-static unsigned int tapdisk_get_info(blkif_t *blkif)
-{
-	image_t *img = (image_t *)blkif->prv;
-	return img->info;
-}
-
-struct blkif_ops tapdisk_ops = {
-	.get_size = tapdisk_get_size,
-	.get_secsize = tapdisk_get_secsize,
-	.get_info = tapdisk_get_info,
-};
-
-
-static void init_driver_list(void)
-{
-	int i;
-
-	for (i = 0; i < MAX_DISK_TYPES; i++)
-		active_disks[i] = NULL;
-	return;
-}
-
-static void init_rng(void)
-{
-	static uint32_t seed;
-	struct timeval tv;
-
-	gettimeofday(&tv, NULL);
-	seed = tv.tv_usec;
-	srand48(seed);
-	return;
-}
-
-static int get_tapdisk_pid(blkif_t *blkif)
-{
-	int ret;
-
-	if ((ret = write_msg(blkif->fds[WRITE], CTLMSG_PID, blkif, NULL)) 
-	    <= 0) {
-		DPRINTF("Write_msg failed - CTLMSG_PID(%d)\n", ret);
-		return -EINVAL;
-	}
-
-	if ((ret = read_msg(blkif->fds[READ], CTLMSG_PID_RSP, blkif))
-	     <= 0) {
-		DPRINTF("Read_msg failure - CTLMSG_PID(%d)\n", ret);
-		return -EINVAL;
-	}	
-	return 1;
-}
-
-/* Look up the disk specified by path: 
- *   if found, dev points to the device string in the path
- *             type is the tapdisk driver type id
- *             blkif is the existing interface if this is a shared driver
- *             and NULL otherwise.
- *   return 0 on success, -1 on error.
- */
-
-static int test_path(char *path, char **dev, int *type, blkif_t **blkif,
-	int* use_ioemu)
-{
-	char *ptr, handle[10];
-	int i, size, found = 0;
-	size_t handle_len;
-
-	size = sizeof(dtypes)/sizeof(disk_info_t *);
-	*type = MAX_DISK_TYPES + 1;
-        *blkif = NULL;
-
-	if (!strncmp(path, "tapdisk:", strlen("tapdisk:"))) {
-		*use_ioemu = 0;
-		path += strlen("tapdisk:");
-	} else if (!strncmp(path, "ioemu:", strlen("ioemu:"))) {
-		*use_ioemu = 1;
-		path += strlen("ioemu:");
-	} else {
-		// Use the default for the image type
-		*use_ioemu = -1;
-	}
-
-	if ( (ptr = strstr(path, ":"))!=NULL) {
-		handle_len = (ptr - path);
-		memcpy(handle, path, handle_len);
-		*dev = ptr + 1;
-		ptr = handle + handle_len;
-		*ptr = '\0';
-		DPRINTF("Detected handle: [%s]\n",handle);
-
-		for (i = 0; i < size; i++) {
-			if ((strlen(dtypes[i]->handle) == handle_len) &&
-					strncmp(handle, dtypes[i]->handle,
-					handle_len) == 0) {
-                                found = 1;
-                        }
-
-			if (found) {
-				if (*use_ioemu == -1)
-					*use_ioemu = dtypes[i]->use_ioemu;
-				*type = dtypes[i]->idnum;
-                        
-                        if (dtypes[i]->single_handler == 1) {
-                                /* Check whether tapdisk process 
-                                   already exists */
-                                if (active_disks[dtypes[i]->idnum] == NULL) 
-                                        *blkif = NULL;
-                                else 
-                                        *blkif = active_disks[dtypes[i]
-                                                             ->idnum]->blkif;
-                        }
-
-                        return 0;
-                }
-            }
-        }
-
-        /* Fall-through case, we didn't find a disk driver. */
-        DPRINTF("Unknown blktap disk type [%s]!\n",handle);
-        *dev = NULL;
-        return -1;
-}
-
-
-static void add_disktype(blkif_t *blkif, int type)
-{
-	driver_list_entry_t *entry, **pprev;
-
-	if (type > MAX_DISK_TYPES)
-		return;
-
-	entry = malloc(sizeof(driver_list_entry_t));
-	entry->blkif = blkif;
-	entry->next  = NULL;
-
-	pprev = &active_disks[type];
-	while (*pprev != NULL)
-		pprev = &(*pprev)->next;
-
-	*pprev = entry;
-	entry->pprev = pprev;
-}
-
-static int qemu_instance_has_disks(pid_t pid)
-{
-	int i;
-	int count = 0;
-	driver_list_entry_t *entry;
-
-	for (i = 0; i < MAX_DISK_TYPES; i++) {
-		entry = active_disks[i];
-		while (entry) {
-			if ((entry->blkif->tappid == pid) && dtypes[i]->use_ioemu)
-				count++;
-			entry = entry->next;
-		}
-	}
-
-	return (count != 0);
-}
-
-static int del_disktype(blkif_t *blkif)
-{
-	driver_list_entry_t *entry, **pprev;
-	int type = blkif->drivertype, count = 0, close = 0;
-
-	if (type > MAX_DISK_TYPES)
-		return 1;
-
-	pprev = &active_disks[type];
-	while ((*pprev != NULL) && ((*pprev)->blkif != blkif))
-		pprev = &(*pprev)->next;
-
-	if ((entry = *pprev) == NULL) {
-		DPRINTF("DEL_DISKTYPE: No match\n");
-		return 1;
-	}
-
-	*pprev = entry->next;
-	if (entry->next)
-		entry->next->pprev = pprev;
-
-	DPRINTF("DEL_DISKTYPE: Freeing entry\n");
-	free(entry);
-
-	/*
-	 * When using ioemu, all disks of one VM are connected to the same
-	 * qemu-dm instance. We may close the file handle only if there is
-	 * no other disk left for this domain.
-	 */
-	if (dtypes[type]->use_ioemu)
-		return !qemu_instance_has_disks(blkif->tappid);
-
-	/* Caller should close() if no single controller, or list is empty. */
-	return (!dtypes[type]->single_handler || (active_disks[type] == NULL));
-}
-
-static int write_msg(int fd, int msgtype, void *ptr, void *ptr2)
-{
-	blkif_t *blkif;
-	blkif_info_t *blk;
-	msg_hdr_t *msg;
-	msg_newdev_t *msg_dev;
-	char *p, *buf, *path;
-	int msglen, len, ret;
-	fd_set writefds;
-	struct timeval timeout;
-	image_t *image, *img;
-	uint32_t seed;
-
-	blkif = (blkif_t *)ptr;
-	blk = blkif->info;
-	image = blkif->prv;
-	len = 0;
-
-	switch (msgtype)
-	{
-	case CTLMSG_PARAMS:
-		path = (char *)ptr2;
-		DPRINTF("Write_msg called: CTLMSG_PARAMS, sending [%s, %s]\n",
-			blk->params, path);
-
-		msglen = sizeof(msg_hdr_t) + strlen(path) + 1;
-		buf = malloc(msglen);
-
-		/*Assign header fields*/
-		msg = (msg_hdr_t *)buf;
-		msg->type = CTLMSG_PARAMS;
-		msg->len = msglen;
-		msg->drivertype = blkif->drivertype;
-		msg->readonly = blkif->readonly;
-
-		gettimeofday(&timeout, NULL);
-		msg->cookie = blkif->cookie;
-		DPRINTF("Generated cookie, %d\n",blkif->cookie);
-
-		/*Copy blk->params to msg*/
-		p = buf + sizeof(msg_hdr_t);
-		memcpy(p, path, strlen(path) + 1);
-
-		break;
-
-	case CTLMSG_NEWDEV:
-		DPRINTF("Write_msg called: CTLMSG_NEWDEV\n");
-
-		msglen = sizeof(msg_hdr_t) + sizeof(msg_newdev_t);
-		buf = malloc(msglen);
-		
-		/*Assign header fields*/
-		msg = (msg_hdr_t *)buf;
-		msg->type = CTLMSG_NEWDEV;
-		msg->len = msglen;
-		msg->drivertype = blkif->drivertype;
-		msg->cookie = blkif->cookie;
-		
-		msg_dev = (msg_newdev_t *)(buf + sizeof(msg_hdr_t));
-		msg_dev->devnum = blkif->minor;
-		msg_dev->domid = blkif->domid;
-
-		break;
-
-	case CTLMSG_CLOSE:
-		DPRINTF("Write_msg called: CTLMSG_CLOSE\n");
-
-		msglen = sizeof(msg_hdr_t);
-		buf = malloc(msglen);
-		
-		/*Assign header fields*/
-		msg = (msg_hdr_t *)buf;
-		msg->type = CTLMSG_CLOSE;
-		msg->len = msglen;
-		msg->drivertype = blkif->drivertype;
-		msg->cookie = blkif->cookie;
-		
-		break;
-
-	case CTLMSG_PID:
-		DPRINTF("Write_msg called: CTLMSG_PID\n");
-
-		msglen = sizeof(msg_hdr_t);
-		buf = malloc(msglen);
-		
-		/*Assign header fields*/
-		msg = (msg_hdr_t *)buf;
-		msg->type = CTLMSG_PID;
-		msg->len = msglen;
-		msg->drivertype = blkif->drivertype;
-		msg->cookie = blkif->cookie;
-		
-		break;
-		
-	default:
-		return -1;
-	}
-
-	/*Now send the message*/
-	ret = 0;
-	FD_ZERO(&writefds);
-	FD_SET(fd,&writefds);
-	timeout.tv_sec = max_timeout; /*Wait for up to max_timeout seconds*/
-	timeout.tv_usec = 0;
-	if (select(fd+1, (fd_set *) 0, &writefds, 
-		  (fd_set *) 0, &timeout) > 0) {
-		len = write(fd, buf, msglen);
-		if (len == -1) DPRINTF("Write failed: (%d)\n",errno);
-	}
-	free(buf);
-
-	return len;
-}
-
-static int read_msg(int fd, int msgtype, void *ptr)
-{
-	blkif_t *blkif;
-	blkif_info_t *blk;
-	msg_hdr_t *msg;
-	msg_pid_t *msg_pid;
-	char *p, *buf;
-	int msglen = MSG_SIZE, len, ret;
-	fd_set readfds;
-	struct timeval timeout;
-	image_t *image, *img;
-
-
-	blkif = (blkif_t *)ptr;
-	blk = blkif->info;
-	image = blkif->prv;
-
-	buf = malloc(MSG_SIZE);
-
-	ret = 0;
-	FD_ZERO(&readfds);
-	FD_SET(fd,&readfds);
-	timeout.tv_sec = max_timeout; /*Wait for up to max_timeout seconds*/ 
-	timeout.tv_usec = 0;
-	if (select(fd+1, &readfds,  (fd_set *) 0,
-		  (fd_set *) 0, &timeout) > 0) {
-		ret = read(fd, buf, msglen);
-	}			
-	if (ret > 0) {
-		msg = (msg_hdr_t *)buf;
-		switch (msg->type)
-		{
-		case CTLMSG_IMG:
-			img = (image_t *)(buf + sizeof(msg_hdr_t));
-			image->size = img->size;
-			image->secsize = img->secsize;
-			image->info = img->info;
-
-			DPRINTF("Received CTLMSG_IMG: %llu, %lu, %u\n",
-				image->size, image->secsize, image->info);
-			if(msgtype != CTLMSG_IMG) ret = 0;
-			break;
-			
-		case CTLMSG_IMG_FAIL:
-			DPRINTF("Received CTLMSG_IMG_FAIL, "
-				"unable to open image\n");
-			ret = 0;
-			break;
-				
-		case CTLMSG_NEWDEV_RSP:
-			DPRINTF("Received CTLMSG_NEWDEV_RSP\n");
-			if(msgtype != CTLMSG_NEWDEV_RSP) ret = 0;
-			break;
-			
-		case CTLMSG_NEWDEV_FAIL:
-			DPRINTF("Received CTLMSG_NEWDEV_FAIL\n");
-			ret = 0;
-			break;
-			
-		case CTLMSG_CLOSE_RSP:
-			DPRINTF("Received CTLMSG_CLOSE_RSP\n");
-			if (msgtype != CTLMSG_CLOSE_RSP) ret = 0;
-			break;
-
-		case CTLMSG_PID_RSP:
-			DPRINTF("Received CTLMSG_PID_RSP\n");
-			if (msgtype != CTLMSG_PID_RSP) ret = 0;
-			else {
-				msg_pid = (msg_pid_t *)
-					(buf + sizeof(msg_hdr_t));
-				blkif->tappid = msg_pid->pid;
-				DPRINTF("\tPID: [%d]\n",blkif->tappid);
-			}
-			break;
-		default:
-			DPRINTF("UNKNOWN MESSAGE TYPE RECEIVED\n");
-			ret = 0;
-			break;
-		}
-	} 
-	
-	free(buf);
-	
-	return ret;
-
-}
-
-static int launch_tapdisk_provider(char **argv)
-{
-	pid_t child;
-	
-	if ((child = fork()) < 0)
-		return -1;
-
-	if (!child) {
-		int i;
-		for (i = 0 ; i < sysconf(_SC_OPEN_MAX) ; i++)
-			if (i != STDIN_FILENO &&
-			    i != STDOUT_FILENO &&
-			    i != STDERR_FILENO)
-				close(i);
-
-		execvp(argv[0], argv);
-		DPRINTF("execvp failed: %d (%s)\n", errno, strerror(errno));
-		DPRINTF("PATH = %s\n", getenv("PATH"));
-		_exit(1);
-	} else {
-		pid_t got;
-		do {
-			got = waitpid(child, NULL, 0);
-		} while (got != child);
-	}
-	return child;
-}
-
-static int launch_tapdisk(char *wrctldev, char *rdctldev)
-{
-	char *argv[] = { "tapdisk", wrctldev, rdctldev, NULL };
-
-	if (launch_tapdisk_provider(argv) < 0)
-		return -1;
-
-	return 0;
-}
-
-static int launch_tapdisk_ioemu(void)
-{
-	char *argv[] = { "tapdisk-ioemu", NULL };
-	return launch_tapdisk_provider(argv);
-}
-
-/* 
- * Connect to an ioemu based disk provider (qemu-dm or tapdisk-ioemu)
- *
- * If the domain has a device model, connect to qemu-dm through the
- * domain specific pipe. Otherwise use a single tapdisk-ioemu instance
- * which is represented by domid 0 and provides access for Dom0 and
- * all DomUs without device model.
- */
-static int connect_qemu(blkif_t *blkif, int domid)
-{
-	char *rdctldev, *wrctldev;
-
-	static int tapdisk_ioemu_pid = 0;
-	static int dom0_readfd = 0;
-	static int dom0_writefd = 0;
-	int refresh_pid = 0;
-
-	if (asprintf(&rdctldev, BLKTAP_CTRL_DIR "/qemu-read-%d", domid) < 0)
-		return -1;
-
-	if (asprintf(&wrctldev, BLKTAP_CTRL_DIR "/qemu-write-%d", domid) < 0) {
-		free(rdctldev);
-		return -1;
-	}
-
-	DPRINTF("Using qemu blktap pipe: %s\n", rdctldev);
-	
-	if (domid == 0) {
-		/*
-		 * tapdisk-ioemu exits as soon as the last image is 
-		 * disconnected. Check if it is still running.
-		 */
-		if (tapdisk_ioemu_pid == 0 || kill(tapdisk_ioemu_pid, 0)) {
-			/* No device model and tapdisk-ioemu doesn't run yet */
-			DPRINTF("Launching tapdisk-ioemu\n");
-			launch_tapdisk_ioemu();
-			
-			dom0_readfd = open_ctrl_socket(wrctldev);
-			dom0_writefd = open_ctrl_socket(rdctldev);
-
-			refresh_pid = 1;
-		}
-
-		DPRINTF("Using tapdisk-ioemu connection\n");
-		blkif->fds[READ] = dom0_readfd;
-		blkif->fds[WRITE] = dom0_writefd;
-
-		if (refresh_pid) {
-			get_tapdisk_pid(blkif);
-			tapdisk_ioemu_pid = blkif->tappid;
-		}
-
-	} else if (access(rdctldev, R_OK | W_OK) == 0) {
-		/* Use existing pipe to the device model */
-		DPRINTF("Using qemu-dm connection\n");
-		blkif->fds[READ] = open_ctrl_socket(wrctldev);
-		blkif->fds[WRITE] = open_ctrl_socket(rdctldev);
-	} else {
-		/* No device model => try with tapdisk-ioemu */
-		DPRINTF("No device model\n");
-		connect_qemu(blkif, 0);
-	}
-	
-	free(rdctldev);
-	free(wrctldev);
-	
-	if (blkif->fds[READ] == -1 || blkif->fds[WRITE] == -1)
-		return -1;
-
-	DPRINTF("Attached to qemu blktap pipes\n");
-	return 0;
-}
-
-/* Launch tapdisk instance */
-static int connect_tapdisk(blkif_t *blkif, int minor)
-{
-	char *rdctldev = NULL, *wrctldev = NULL;
-	int ret = -1;
-
-	DPRINTF("tapdisk process does not exist:\n");
-
-	if (asprintf(&rdctldev,
-		     "%s/tapctrlread%d", BLKTAP_CTRL_DIR, minor) == -1)
-		goto fail;
-
-	if (asprintf(&wrctldev,
-		     "%s/tapctrlwrite%d", BLKTAP_CTRL_DIR, minor) == -1)
-		goto fail;
-	
-	blkif->fds[READ] = open_ctrl_socket(rdctldev);
-	blkif->fds[WRITE] = open_ctrl_socket(wrctldev);
-	
-	if (blkif->fds[READ] == -1 || blkif->fds[WRITE] == -1)
-		goto fail;
-
-	/*launch the new process*/
-	DPRINTF("Launching process, CMDLINE [tapdisk %s %s]\n",
-			wrctldev, rdctldev);
-
-	if (launch_tapdisk(wrctldev, rdctldev) == -1) {
-		DPRINTF("Unable to fork, cmdline: [tapdisk %s %s]\n",
-				wrctldev, rdctldev);
-		goto fail;
-	}
-
-	ret = 0;
-	
-fail:
-	if (rdctldev)
-		free(rdctldev);
-
-	if (wrctldev)
-		free(wrctldev);
-
-	return ret;
-}
-
-static int blktapctrl_new_blkif(blkif_t *blkif)
-{
-	blkif_info_t *blk;
-	int major, minor, fd_read, fd_write, type, new;
-	char *rdctldev, *wrctldev, *ptr;
-	image_t *image;
-	blkif_t *exist = NULL;
-	static uint16_t next_cookie = 0;
-	int use_ioemu;
-
-	DPRINTF("Received a poll for a new vbd\n");
-	if ( ((blk=blkif->info) != NULL) && (blk->params != NULL) ) {
-		if (blktap_interface_create(ctlfd, &major, &minor, blkif) < 0)
-			return -1;
-
-		if (test_path(blk->params, &ptr, &type, &exist, &use_ioemu) != 0) {
-                        DPRINTF("Error in blktap device string(%s).\n",
-                                blk->params);
-                        goto fail;
-                }
-		blkif->drivertype = type;
-		blkif->cookie = next_cookie++;
-
-		if (!exist) {
-			if (use_ioemu) {
-				if (connect_qemu(blkif, blkif->domid))
-					goto fail;
-			} else {
-				if (connect_tapdisk(blkif, minor))
-					goto fail;
-			}
-
-		} else {
-			DPRINTF("Process exists!\n");
-			blkif->fds[READ] = exist->fds[READ];
-			blkif->fds[WRITE] = exist->fds[WRITE];
-		}
-
-		add_disktype(blkif, type);
-		blkif->major = major;
-		blkif->minor = minor;
-
-		image = (image_t *)malloc(sizeof(image_t));
-		blkif->prv = (void *)image;
-		blkif->ops = &tapdisk_ops;
-
-		/*Retrieve the PID of the new process*/
-		if (get_tapdisk_pid(blkif) <= 0) {
-			DPRINTF("Unable to contact disk process\n");
-			goto fail;
-		}
-
-		/* Both of the following read and write calls will block up to 
-		 * max_timeout val*/
-		if (write_msg(blkif->fds[WRITE], CTLMSG_PARAMS, blkif, ptr) 
-		    <= 0) {
-			DPRINTF("Write_msg failed - CTLMSG_PARAMS\n");
-			goto fail;
-		}
-
-		if (read_msg(blkif->fds[READ], CTLMSG_IMG, blkif) <= 0) {
-			DPRINTF("Read_msg failure - CTLMSG_IMG\n");
-			goto fail;
-		}
-
-	} else return -1;
-
-	return 0;
-fail:
-	ioctl(ctlfd, BLKTAP_IOCTL_FREEINTF, minor);
-	return -EINVAL;
-}
-
-static int map_new_blktapctrl(blkif_t *blkif)
-{
-	DPRINTF("Received a poll for a new devmap\n");
-	if (write_msg(blkif->fds[WRITE], CTLMSG_NEWDEV, blkif, NULL) <= 0) {
-		DPRINTF("Write_msg failed - CTLMSG_NEWDEV\n");
-		return -EINVAL;
-	}
-
-	if (read_msg(blkif->fds[READ], CTLMSG_NEWDEV_RSP, blkif) <= 0) {
-		DPRINTF("Read_msg failed - CTLMSG_NEWDEV_RSP\n");
-		return -EINVAL;
-	}
-	DPRINTF("Exiting map_new_blktapctrl\n");
-
-	return blkif->minor - 1;
-}
-
-static int unmap_blktapctrl(blkif_t *blkif)
-{
-	DPRINTF("Unmapping vbd\n");
-
-	if (write_msg(blkif->fds[WRITE], CTLMSG_CLOSE, blkif, NULL) <= 0) {
-		DPRINTF("Write_msg failed - CTLMSG_CLOSE\n");
-		return -EINVAL;
-	}
-
-	if (del_disktype(blkif)) {
-		DPRINTF("Closing communication pipe to pid %d\n", blkif->tappid);
-		close(blkif->fds[WRITE]);
-		close(blkif->fds[READ]);
-	}
-
-	return 0;
-}
-
-int open_ctrl_socket(char *devname)
-{
-	int ret;
-	int ipc_fd;
-	fd_set socks;
-	struct timeval timeout;
-
-	if (mkdir(BLKTAP_CTRL_DIR, 0755) == 0)
-		DPRINTF("Created %s directory\n", BLKTAP_CTRL_DIR);
-	ret = mkfifo(devname,S_IRWXU|S_IRWXG|S_IRWXO);
-	if ( (ret != 0) && (errno != EEXIST) ) {
-		DPRINTF("ERROR: pipe failed (%d)\n", errno);
-		exit(0);
-	}
-
-	ipc_fd = open(devname,O_RDWR|O_NONBLOCK);
-
-	if (ipc_fd < 0) {
-		DPRINTF("FD open failed\n");
-		return -1;
-	}
-
-	return ipc_fd;
-}
-
-static void print_drivers(void)
-{
-	int i, size;
-
-	size = sizeof(dtypes)/sizeof(disk_info_t *);
-	DPRINTF("blktapctrl: v1.0.0\n");
-	for (i = 0; i < size; i++)
-		DPRINTF("Found driver: [%s]\n",dtypes[i]->name);
-} 
-
-static void write_pidfile(long pid)
-{
-	char buf[100];
-	int len;
-	int fd;
-	int flags;
-
-	fd = open(PIDFILE, O_RDWR | O_CREAT, 0600);
-	if (fd == -1) {
-		DPRINTF("Opening pid file failed (%d)\n", errno);
-		exit(1);
-	}
-
-	/* We exit silently if daemon already running. */
-	if (lockf(fd, F_TLOCK, 0) == -1)
-		exit(0);
-
-	/* Set FD_CLOEXEC, so that tapdisk doesn't get this file
-	   descriptor. */
-	if ((flags = fcntl(fd, F_GETFD)) == -1) {
-		DPRINTF("F_GETFD failed (%d)\n", errno);
-		exit(1);
-	}
-	flags |= FD_CLOEXEC;
-	if (fcntl(fd, F_SETFD, flags) == -1) {
-		DPRINTF("F_SETFD failed (%d)\n", errno);
-		exit(1);
-	}
-
-	len = snprintf(buf, sizeof(buf), "%ld\n", pid);
-	if (write(fd, buf, len) != len) {
-		DPRINTF("Writing pid file failed (%d)\n", errno);
-		exit(1);
-	}
-}
-
-int main(int argc, char *argv[])
-{
-	char *devname;
-	tapdev_info_t *ctlinfo;
-	int tap_pfd, store_pfd, xs_fd, ret, timeout, pfd_count, count=0;
-	struct xs_handle *h;
-	struct pollfd  pfd[NUM_POLL_FDS];
-	pid_t process;
-	char buf[128];
-
-	__init_blkif();
-	snprintf(buf, sizeof(buf), "BLKTAPCTRL[%d]", getpid());
-	openlog(buf, LOG_CONS|LOG_ODELAY, LOG_DAEMON);
-	if (daemon(0,0)) {
-		DPRINTF("daemon failed (%d)\n", errno);
-		goto open_failed;
-	}
-
-	print_drivers();
-	init_driver_list();
-	init_rng();
-
-	register_new_blkif_hook(blktapctrl_new_blkif);
-	register_new_devmap_hook(map_new_blktapctrl);
-	register_new_unmap_hook(unmap_blktapctrl);
-
-	ctlfd = blktap_interface_open();
-	if (ctlfd < 0) {
-		DPRINTF("couldn't open blktap interface\n");
-		goto open_failed;
-	}
-
-#ifdef MEMSHR
-	memshr_daemon_initialize();
-#endif
-
- retry:
-	/* Set up store connection and watch. */
-	h = xs_daemon_open();
-	if (h == NULL) {
-		DPRINTF("xs_daemon_open failed -- "
-			"is xenstore running?\n");
-                if (count < MAX_ATTEMPTS) {
-                        count++;
-                        sleep(2);
-                        goto retry;
-                } else goto open_failed;
-	}
-	
-	ret = setup_probe_watch(h);
-	if (ret != 0) {
-		DPRINTF("Failed adding device probewatch\n");
-		xs_daemon_close(h);
-		goto open_failed;
-	}
-
-	ioctl(ctlfd, BLKTAP_IOCTL_SETMODE, BLKTAP_MODE_INTERPOSE );
-
-	process = getpid();
-	write_pidfile(process);
-	ret = ioctl(ctlfd, BLKTAP_IOCTL_SENDPID, process );
-
-	/*Static pollhooks*/
-	pfd_count = 0;
-	tap_pfd = pfd_count++;
-	pfd[tap_pfd].fd = ctlfd;
-	pfd[tap_pfd].events = POLLIN;
-	
-	store_pfd = pfd_count++;
-	pfd[store_pfd].fd = xs_fileno(h);
-	pfd[store_pfd].events = POLLIN;
-
-	while (run) {
-		timeout = 1000; /*Milliseconds*/
-                ret = poll(pfd, pfd_count, timeout);
-
-		if (ret > 0) {
-			if (pfd[store_pfd].revents) {
-				ret = xs_fire_next_watch(h);
-			}
-		}
-	}
-
-	xs_daemon_close(h);
-	ioctl(ctlfd, BLKTAP_IOCTL_SETMODE, BLKTAP_MODE_PASSTHROUGH );
-	close(ctlfd);
-	closelog();
-
-	return 0;
-	
- open_failed:
-	DPRINTF("Unable to start blktapctrl\n");
-	closelog();
-	return -1;
-}
-
-/*
- * Local variables:
- *  c-file-style: "linux"
- *  indent-tabs-mode: t
- *  c-indent-level: 8
- *  c-basic-offset: 8
- *  tab-width: 8
- * End:
- */
diff --git a/tools/blktap/drivers/blktapctrl.h b/tools/blktap/drivers/blktapctrl.h
deleted file mode 100644
index 4512807..0000000
--- a/tools/blktap/drivers/blktapctrl.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/* blktapctrl.h
- *
- * controller image utils.
- * 
- * (c) 2004-6 Andrew Warfield and Julian Chesterfield
- *
- * 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.
- */
-
-
-int blktap_interface_open(void);
-
-int blktap_interface_create(int ctlfd, int *major, int *minor, blkif_t *blkif);
-
diff --git a/tools/blktap/drivers/blktapctrl_linux.c b/tools/blktap/drivers/blktapctrl_linux.c
deleted file mode 100644
index 6282fa6..0000000
--- a/tools/blktap/drivers/blktapctrl_linux.c
+++ /dev/null
@@ -1,89 +0,0 @@
-
-#include <stdio.h>
-#include <fcntl.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-
-#include "tapdisk.h"
-#include "blktaplib.h"
-#include "blktapctrl.h"
-
-static void make_blktap_dev(char *devname, int major, int minor)
-{
-	struct stat st;
- 
-	if (lstat(devname, &st) != 0) {
-		/*Need to create device*/
-		if (mkdir(BLKTAP_DEV_DIR, 0755) == 0)
-			DPRINTF("Created %s directory\n",BLKTAP_DEV_DIR);
-		if (mknod(devname, S_IFCHR|0600,
-			makedev(major, minor)) == 0)
-			DPRINTF("Created %s device\n",devname);
-	} else {
-		DPRINTF("%s device already exists\n",devname); 
-		/* it already exists, but is it the same major number */
-		if (((st.st_rdev>>8) & 0xff) != major) {
-			DPRINTF("%s has old major %d\n",
-				devname,
-				(unsigned int)((st.st_rdev >> 8) & 0xff));
-			/* only try again if we succed in deleting it */
-			if (!unlink(devname))
-				make_blktap_dev(devname, major, minor);
-		}
-	}
-}
-
-int blktap_interface_create(int ctlfd, int *major, int *minor, blkif_t *blkif)
-{       
-        domid_translate_t tr;
-        domid_translate_ext_t tr_ext;
-        int ret; 
-        char *devname;
-
-        if (blkif->be_id >= (1<<28)) {
-                /* new-style backend-id, so use the extended structure */
-                tr_ext.domid = blkif->domid;
-                tr_ext.busid = blkif->be_id;
-                ret = ioctl(ctlfd, BLKTAP_IOCTL_NEWINTF_EXT, &tr_ext);
-                DPRINTF("Sent domid %d and be_id %d\n", tr_ext.domid,
-                        tr_ext.busid);
-        }
-        else {
-                /* old-style backend-id; use the old structure */
-                tr.domid = blkif->domid;
-                tr.busid = (unsigned short)blkif->be_id;
-                ret = ioctl(ctlfd, BLKTAP_IOCTL_NEWINTF, tr);
-                DPRINTF("Sent domid %d and be_id %d\n", tr.domid, tr.busid);
-        }
-
-        if ( (ret <= 0)||(ret > MAX_TAP_DEV) ) {
-                DPRINTF("Incorrect Dev ID [%d]\n",ret);
-                return -1;
-        }
-
-        *minor = ret;
-        *major = ioctl(ctlfd, BLKTAP_IOCTL_MAJOR, ret );
-        if (*major < 0) {
-                DPRINTF("Incorrect Major ID [%d]\n",*major);
-                return -1;
-        }
-
-        if (asprintf(&devname,"%s/%s%d",BLKTAP_DEV_DIR, BLKTAP_DEV_NAME, *minor) == -1)
-                return -1;
-        make_blktap_dev(devname,*major,*minor);
-        DPRINTF("Received device id %d and major %d\n",
-                *minor, *major);
-        return 0;
-}
-
-
-int blktap_interface_open(void)
-{
-	int ctlfd;
-
-	ctlfd = open(BLKTAP_DEV_DIR "/" BLKTAP_DEV_NAME "0", O_RDWR);
-	if (ctlfd == -1)
-		DPRINTF("blktap0 open failed\n");
-
-	return ctlfd;
-}
diff --git a/tools/blktap/drivers/block-aio.c b/tools/blktap/drivers/block-aio.c
deleted file mode 100644
index 98727f4..0000000
--- a/tools/blktap/drivers/block-aio.c
+++ /dev/null
@@ -1,259 +0,0 @@
-/* block-aio.c
- *
- * libaio-based raw disk implementation.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- * NB: This code is not thread-safe.
- *
- * 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 <errno.h>
-#include <libaio.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include "tapdisk.h"
-#include "tapaio.h"
-#include "blk.h"
-
-#define MAX_AIO_REQS (MAX_REQUESTS * MAX_SEGMENTS_PER_REQ)
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-struct tdaio_state {
-	int fd;
-	tap_aio_context_t aio;
-};
-
-
-/*Get Image size, secsize*/
-static int get_image_info(struct td_state *s, int fd)
-{
-	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
-	struct stat stat;
-
-	ret = fstat(fd, &stat);
-	if (ret != 0) {
-		DPRINTF("ERROR: fstat failed, Couldn't stat image");
-		return -EINVAL;
-	}
-
-	if (S_ISBLK(stat.st_mode)) {
-		/*Accessing block device directly*/
-		if (blk_getimagesize(fd, &s->size) != 0)
-			return -EINVAL;
-
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-
-		/*Get the sector size*/
-		if (blk_getsectorsize(fd, &s->sector_size) != 0)
-			s->sector_size = DEFAULT_SECTOR_SIZE;
-
-	} else {
-		/*Local file? try fstat instead*/
-		s->size = (stat.st_size >> SECTOR_SHIFT);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-	}
-
-	if (s->size == 0) {		
-		s->size =((uint64_t) 16836057);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-	}
-	s->info = 0;
-
-	return 0;
-}
-
-static inline void init_fds(struct disk_driver *dd)
-{
-	int i;
-	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
-
-	for(i = 0; i < MAX_IOFD; i++) 
-		dd->io_fd[i] = 0;
-
-	dd->io_fd[0] = prv->aio.aio_ctx.pollfd;
-}
-
-/* Open the disk file and initialize aio state. */
-static int tdaio_open (struct disk_driver *dd, const char *name, td_flag_t flags)
-{
-	int i, fd, ret = 0, o_flags;
-	struct td_state    *s   = dd->td_state;
-	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
-
-	DPRINTF("block-aio open('%s')", name);
-
-	/* Initialize AIO */
-	ret = tap_aio_init(&prv->aio, 0, MAX_AIO_REQS);
-	if (ret != 0)
-		return ret;
-
-	/* Open the file */
-	o_flags = O_DIRECT | O_LARGEFILE | 
-		((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-        fd = open(name, o_flags);
-
-        if ( (fd == -1) && (errno == EINVAL) ) {
-
-                /* Maybe O_DIRECT isn't supported. */
-		o_flags &= ~O_DIRECT;
-                fd = open(name, o_flags);
-                if (fd != -1) DPRINTF("WARNING: Accessing image without"
-                                     "O_DIRECT! (%s)\n", name);
-
-        } else if (fd != -1) DPRINTF("open(%s) with O_DIRECT\n", name);
-	
-        if (fd == -1) {
-		DPRINTF("Unable to open [%s] (%d)!\n", name, 0 - errno);
-        	ret = 0 - errno;
-        	goto done;
-        }
-
-        prv->fd = fd;
-
-	init_fds(dd);
-	ret = get_image_info(s, fd);
-
-done:
-	return ret;	
-}
-
-static int tdaio_queue_read(struct disk_driver *dd, uint64_t sector,
-		     int nb_sectors, char *buf, td_callback_t cb,
-		     int id, void *private)
-{
-	struct   td_state    *s   = dd->td_state;
-	struct   tdaio_state *prv = (struct tdaio_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-
-	return tap_aio_read(&prv->aio, prv->fd, size, offset, buf, 
-		cb, id, sector, private);
-}
-			
-static int tdaio_queue_write(struct disk_driver *dd, uint64_t sector,
-		      int nb_sectors, char *buf, td_callback_t cb,
-		      int id, void *private)
-{
-	struct   td_state    *s   = dd->td_state;
-	struct   tdaio_state *prv = (struct tdaio_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-
-	return tap_aio_write(&prv->aio, prv->fd, size, offset, buf,
-		cb, id, sector, private);
-}
-
-static int tdaio_submit(struct disk_driver *dd)
-{
-	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
-
-	return tap_aio_submit(&prv->aio);
-}
-			
-static int tdaio_close(struct disk_driver *dd)
-{
-	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
-	
-	io_destroy(prv->aio.aio_ctx.aio_ctx);
-	close(prv->fd);
-
-	return 0;
-}
-
-static int tdaio_do_callbacks(struct disk_driver *dd, int sid)
-{
-	int i, nr_events, rsp = 0;
-	struct io_event *ep;
-	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
-
-	nr_events = tap_aio_get_events(&prv->aio.aio_ctx);
-repeat:
-	for (ep = prv->aio.aio_events, i = nr_events; i-- > 0; ep++) {
-		struct iocb        *io  = ep->obj;
-		struct pending_aio *pio;
-		
-		pio = &prv->aio.pending_aio[(long)io->data];
-		rsp += pio->cb(dd, ep->res == io->u.c.nbytes ? 0 : 1,
-			       pio->sector, io->u.c.nbytes >> 9, 
-			       pio->id, pio->private);
-
-		prv->aio.iocb_free[prv->aio.iocb_free_count++] = io;
-	}
-
-	if (nr_events) {
-		nr_events = tap_aio_more_events(&prv->aio.aio_ctx);
-		goto repeat;
-	}
-
-	tap_aio_continue(&prv->aio.aio_ctx);
-
-	return rsp;
-}
-
-static int tdaio_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	return TD_NO_PARENT;
-}
-
-static int tdaio_validate_parent(struct disk_driver *dd, 
-			  struct disk_driver *parent, td_flag_t flags)
-{
-	return -EINVAL;
-}
-
-struct tap_disk tapdisk_aio = {
-	.disk_type          = "tapdisk_aio",
-	.private_data_size  = sizeof(struct tdaio_state),
-	.td_open            = tdaio_open,
-	.td_queue_read      = tdaio_queue_read,
-	.td_queue_write     = tdaio_queue_write,
-	.td_submit          = tdaio_submit,
-	.td_close           = tdaio_close,
-	.td_do_callbacks    = tdaio_do_callbacks,
-	.td_get_parent_id   = tdaio_get_parent_id,
-	.td_validate_parent = tdaio_validate_parent
-};
diff --git a/tools/blktap/drivers/block-qcow.c b/tools/blktap/drivers/block-qcow.c
deleted file mode 100644
index 0e4e9cf..0000000
--- a/tools/blktap/drivers/block-qcow.c
+++ /dev/null
@@ -1,1434 +0,0 @@
-/* block-qcow.c
- *
- * Asynchronous Qemu copy-on-write disk implementation.
- * Code based on the Qemu implementation
- * (see copyright notice below)
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- */
-
-/*
- * Block driver for the QCOW format
- * 
- * Copyright (c) 2004 Fabrice Bellard
- * 
- * 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:
- */
-
-#include <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include <zlib.h>
-#include <inttypes.h>
-#include <libaio.h>
-#include "bswap.h"
-#include "aes.h"
-#include "tapdisk.h"
-#include "tapaio.h"
-#include "blk.h"
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-#if 1
-#define ASSERT(_p) \
-    if ( !(_p) ) { DPRINTF("Assertion '%s' failed, line %d, file %s", #_p , \
-    __LINE__, __FILE__); *(int*)0=0; }
-#else
-#define ASSERT(_p) ((void)0)
-#endif
-
-#define ROUNDUP(l, s) \
-({ \
-    (uint64_t)( \
-        ((l) + ((s) - 1)) - (((l) + ((s) - 1)) % (s))); \
-})
-
-#undef IOCB_IDX
-#define IOCB_IDX(_s, _io) ((_io) - (_s)->iocb_list)
-
-#define ZERO_TEST(_b) (_b | 0x00)
-
-/**************************************************************/
-/* QEMU COW block driver with compression and encryption support */
-
-#define QCOW_MAGIC (('Q' << 24) | ('F' << 16) | ('I' << 8) | 0xfb)
-#define XEN_MAGIC  (('X' << 24) | ('E' << 16) | ('N' << 8) | 0xfb)
-#define QCOW_VERSION 1
-
-#define QCOW_CRYPT_NONE 0x00
-#define QCOW_CRYPT_AES  0x01
-
-#define QCOW_OFLAG_COMPRESSED (1LL << 63)
-#define SPARSE_FILE 0x01
-#define EXTHDR_L1_BIG_ENDIAN 0x02
-
-#ifndef O_BINARY
-#define O_BINARY 0
-#endif
-
-typedef struct QCowHeader {
-	uint32_t magic;
-	uint32_t version;
-	uint64_t backing_file_offset;
-	uint32_t backing_file_size;
-	uint32_t mtime;
-	uint64_t size; /* in bytes */
-	uint8_t cluster_bits;
-	uint8_t l2_bits;
-	uint32_t crypt_method;
-	uint64_t l1_table_offset;
-} QCowHeader;
-
-/*Extended header for Xen enhancements*/
-typedef struct QCowHeader_ext {
-        uint32_t xmagic;
-        uint32_t cksum;
-        uint32_t min_cluster_alloc;
-        uint32_t flags;
-} QCowHeader_ext;
-
-#define L2_CACHE_SIZE 16  /*Fixed allocation in Qemu*/
-
-struct tdqcow_state {
-        int fd;                        /*Main Qcow file descriptor */
-	uint64_t fd_end;               /*Store a local record of file length */
-	char *name;                    /*Record of the filename*/
-	uint32_t backing_file_size;
-	uint64_t backing_file_offset;
-	int encrypted;                 /*File contents are encrypted or plain*/
-	int cluster_bits;              /*Determines length of cluster as 
-					*indicated by file hdr*/
-	int cluster_size;              /*Length of cluster*/
-	int cluster_sectors;           /*Number of sectors per cluster*/
-	int cluster_alloc;             /*Blktap fix for allocating full 
-					*extents*/
-	int min_cluster_alloc;         /*Blktap historical extent alloc*/
-	int sparse;                    /*Indicates whether to preserve sparseness*/
-	int l2_bits;                   /*Size of L2 table entry*/
-	int l2_size;                   /*Full table size*/
-	int l1_size;                   /*L1 table size*/
-	uint64_t cluster_offset_mask;    
-	uint64_t l1_table_offset;      /*L1 table offset from beginning of 
-					*file*/
-	uint64_t *l1_table;            /*L1 table entries*/
-	uint64_t *l2_cache;            /*We maintain a cache of size 
-					*L2_CACHE_SIZE of most read entries*/
-	uint64_t l2_cache_offsets[L2_CACHE_SIZE];     /*L2 cache entries*/
-	uint32_t l2_cache_counts[L2_CACHE_SIZE];      /*Cache access record*/
-	uint8_t *cluster_cache;          
-	uint8_t *cluster_data;
-	uint64_t cluster_cache_offset; /**/
-	uint32_t crypt_method;         /*current crypt method, 0 if no 
-					*key yet */
-	uint32_t crypt_method_header;  /**/
-	AES_KEY aes_encrypt_key;       /*AES key*/
-	AES_KEY aes_decrypt_key;       /*AES key*/
-        
-	/* libaio state */
-	tap_aio_context_t	aio;
-};
-
-static int decompress_cluster(struct tdqcow_state *s, uint64_t cluster_offset);
-
-#ifdef USE_GCRYPT
-
-#include <gcrypt.h>
-
-static uint32_t gen_cksum(char *ptr, int len)
-{
-	int i;
-	uint32_t md[4];
-
-	/* Convert L1 table to big endian */
-	for(i = 0; i < len / sizeof(uint64_t); i++) {
-		cpu_to_be64s(&((uint64_t*) ptr)[i]);
-	}
-
-	/* Generate checksum */
-	gcry_md_hash_buffer(GCRY_MD_MD5, md, ptr, len);
-
-	/* Convert L1 table back to native endianess */
-	for(i = 0; i < len / sizeof(uint64_t); i++) {
-		be64_to_cpus(&((uint64_t*) ptr)[i]);
-	}
-
-	return md[0];
-}
-
-#else /* use libcrypto */
-
-#include <openssl/md5.h>
-
-static uint32_t gen_cksum(char *ptr, int len)
-{
-	int i;
-	unsigned char *md;
-	uint32_t ret;
-
-	md = malloc(MD5_DIGEST_LENGTH);
-	if(!md) return 0;
-
-	/* Convert L1 table to big endian */
-	for(i = 0; i < len / sizeof(uint64_t); i++) {
-		cpu_to_be64s(&((uint64_t*) ptr)[i]);
-	}
-
-	/* Generate checksum */
-	if (MD5((unsigned char *)ptr, len, md) != md)
-		ret = 0;
-	else
-		memcpy(&ret, md, sizeof(uint32_t));
-
-	/* Convert L1 table back to native endianess */
-	for(i = 0; i < len / sizeof(uint64_t); i++) {
-		be64_to_cpus(&((uint64_t*) ptr)[i]);
-	}
-
-	free(md);
-	return ret;
-}
-
-#endif
-
-static int get_filesize(char *filename, uint64_t *size, struct stat *st)
-{
-	int fd;
-	QCowHeader header;
-
-	/*Set to the backing file size*/
-	fd = open(filename, O_RDONLY);
-	if (fd < 0)
-		return -1;
-	if (read(fd, &header, sizeof(header)) < sizeof(header)) {
-		close(fd);
-		return -1;
-	}
-	close(fd);
-	
-	be32_to_cpus(&header.magic);
-	be64_to_cpus(&header.size);
-	if (header.magic == QCOW_MAGIC) {
-		*size = header.size >> SECTOR_SHIFT;
-		return 0;
-	}
-
-	if(S_ISBLK(st->st_mode)) {
-		fd = open(filename, O_RDONLY);
-		if (fd < 0)
-			return -1;
-		if (blk_getimagesize(fd, size) != 0) {
-			close(fd);
-			return -1;
-		}
-		close(fd);
-	} else *size = (st->st_size >> SECTOR_SHIFT);	
-	return 0;
-}
-
-static int qcow_set_key(struct tdqcow_state *s, const char *key)
-{
-	uint8_t keybuf[16];
-	int len, i;
-	
-	memset(keybuf, 0, 16);
-	len = strlen(key);
-	if (len > 16)
-		len = 16;
-	/* XXX: we could compress the chars to 7 bits to increase
-	   entropy */
-	for (i = 0; i < len; i++) {
-		keybuf[i] = key[i];
-	}
-	s->crypt_method = s->crypt_method_header;
-	
-	if (AES_set_encrypt_key(keybuf, 128, &s->aes_encrypt_key) != 0)
-		return -1;
-	if (AES_set_decrypt_key(keybuf, 128, &s->aes_decrypt_key) != 0)
-		return -1;
-#if 0
-	/* test */
-	{
-		uint8_t in[16];
-		uint8_t out[16];
-		uint8_t tmp[16];
-		for (i=0; i<16; i++)
-			in[i] = i;
-		AES_encrypt(in, tmp, &s->aes_encrypt_key);
-		AES_decrypt(tmp, out, &s->aes_decrypt_key);
-		for (i = 0; i < 16; i++)
-			DPRINTF(" %02x", tmp[i]);
-		DPRINTF("\n");
-		for (i = 0; i < 16; i++)
-			DPRINTF(" %02x", out[i]);
-		DPRINTF("\n");
-	}
-#endif
-	return 0;
-}
-
-/* 
- * The crypt function is compatible with the linux cryptoloop
- * algorithm for < 4 GB images. NOTE: out_buf == in_buf is
- * supported .
- */
-static void encrypt_sectors(struct tdqcow_state *s, int64_t sector_num,
-                            uint8_t *out_buf, const uint8_t *in_buf,
-                            int nb_sectors, int enc,
-                            const AES_KEY *key)
-{
-	union {
-		uint64_t ll[2];
-		uint8_t b[16];
-	} ivec;
-	int i;
-	
-	for (i = 0; i < nb_sectors; i++) {
-		ivec.ll[0] = cpu_to_le64(sector_num);
-		ivec.ll[1] = 0;
-		AES_cbc_encrypt(in_buf, out_buf, 512, key, 
-				ivec.b, enc);
-		sector_num++;
-		in_buf += 512;
-		out_buf += 512;
-	}
-}
-
-static int qtruncate(int fd, off_t length, int sparse)
-{
-	int ret, i; 
-	int current = 0, rem = 0;
-	uint64_t sectors;
-	struct stat st;
-	char *buf;
-
-	/* If length is greater than the current file len
-	 * we synchronously write zeroes to the end of the 
-	 * file, otherwise we truncate the length down
-	 */
-	ret = fstat(fd, &st);
-	if (ret == -1) 
-		return -1;
-	if (S_ISBLK(st.st_mode))
-		return 0;
-
-	sectors = (length + DEFAULT_SECTOR_SIZE - 1)/DEFAULT_SECTOR_SIZE;
-	current = (st.st_size + DEFAULT_SECTOR_SIZE - 1)/DEFAULT_SECTOR_SIZE;
-	rem     = st.st_size % DEFAULT_SECTOR_SIZE;
-
-	/* If we are extending this file, we write zeros to the end --
-	 * this tries to ensure that the extents allocated wind up being
-	 * contiguous on disk.
-	 */
-	if(st.st_size < sectors * DEFAULT_SECTOR_SIZE) {
-		/*We are extending the file*/
-		if ((ret = posix_memalign((void **)&buf, 
-					  512, DEFAULT_SECTOR_SIZE))) {
-			DPRINTF("posix_memalign failed: %d\n", ret);
-			return -1;
-		}
-		memset(buf, 0x00, DEFAULT_SECTOR_SIZE);
-		if (lseek(fd, 0, SEEK_END)==-1) {
-			DPRINTF("Lseek EOF failed (%d), internal error\n",
-				errno);
-			free(buf);
-			return -1;
-		}
-		if (rem) {
-			ret = write(fd, buf, rem);
-			if (ret != rem) {
-				DPRINTF("write failed: ret = %d, err = %s\n",
-					ret, strerror(errno));
-				free(buf);
-				return -1;
-			}
-		}
-		for (i = current; i < sectors; i++ ) {
-			ret = write(fd, buf, DEFAULT_SECTOR_SIZE);
-			if (ret != DEFAULT_SECTOR_SIZE) {
-				DPRINTF("write failed: ret = %d, err = %s\n",
-					ret, strerror(errno));
-				free(buf);
-				return -1;
-			}
-		}
-		free(buf);
-	} else if(sparse && (st.st_size > sectors * DEFAULT_SECTOR_SIZE))
-		if (ftruncate(fd, (off_t)sectors * DEFAULT_SECTOR_SIZE)==-1) {
-			DPRINTF("Ftruncate failed (%s)\n", strerror(errno));
-			return -1;
-		}
-	return 0;
-}
-
-
-/* 'allocate' is:
- *
- * 0 to not allocate.
- *
- * 1 to allocate a normal cluster (for sector indexes 'n_start' to
- * 'n_end')
- *
- * 2 to allocate a compressed cluster of size
- * 'compressed_size'. 'compressed_size' must be > 0 and <
- * cluster_size 
- *
- * return 0 if not allocated.
- */
-static uint64_t get_cluster_offset(struct tdqcow_state *s,
-                                   uint64_t offset, int allocate,
-                                   int compressed_size,
-                                   int n_start, int n_end)
-{
-	int min_index, i, j, l1_index, l2_index, l2_sector, l1_sector;
-	char *tmp_ptr2, *l2_ptr, *l1_ptr;
-	uint64_t *tmp_ptr;
-	uint64_t l2_offset, *l2_table, cluster_offset, tmp;
-	uint32_t min_count;
-	int new_l2_table;
-
-	/*Check L1 table for the extent offset*/
-	l1_index = offset >> (s->l2_bits + s->cluster_bits);
-	l2_offset = s->l1_table[l1_index];
-	new_l2_table = 0;
-	if (!l2_offset) {
-		if (!allocate)
-			return 0;
-		/* 
-		 * allocating a new l2 entry + extent 
-		 * at the end of the file, we must also
-		 * update the L1 entry safely.
-		 */
-		l2_offset = s->fd_end;
-
-		/* round to cluster size */
-		l2_offset = (l2_offset + s->cluster_size - 1) 
-			& ~(s->cluster_size - 1);
-
-		/* update the L1 entry */
-		s->l1_table[l1_index] = l2_offset;
-		tmp = cpu_to_be64(l2_offset);
-		
-		/*Truncate file for L2 table 
-		 *(initialised to zero in case we crash)*/
-		if (qtruncate(s->fd, 
-			      l2_offset + (s->l2_size * sizeof(uint64_t)),
-			      s->sparse) != 0) {
-			DPRINTF("ERROR truncating file\n");
-			return 0;
-		}
-		s->fd_end = l2_offset + (s->l2_size * sizeof(uint64_t));
-
-		/*Update the L1 table entry on disk
-                 * (for O_DIRECT we write 4KByte blocks)*/
-		l1_sector = (l1_index * sizeof(uint64_t)) >> 12;
-		l1_ptr = (char *)s->l1_table + (l1_sector << 12);
-
-		if (posix_memalign((void **)&tmp_ptr, 4096, 4096) != 0) {
-			DPRINTF("ERROR allocating memory for L1 table\n");
-		}
-		memcpy(tmp_ptr, l1_ptr, 4096);
-
-		/* Convert block to write to big endian */
-		for(i = 0; i < 4096 / sizeof(uint64_t); i++) {
-			cpu_to_be64s(&tmp_ptr[i]);
-		}
-
-		/*
-		 * Issue non-asynchronous L1 write.
-		 * For safety, we must ensure that
-		 * entry is written before blocks.
-		 */
-		lseek(s->fd, s->l1_table_offset + (l1_sector << 12), SEEK_SET);
-		if (write(s->fd, tmp_ptr, 4096) != 4096) {
-			free(tmp_ptr);
-		 	return 0;
-		}
-		free(tmp_ptr);
-
-		new_l2_table = 1;
-		goto cache_miss;
-	} else if (s->min_cluster_alloc == s->l2_size) {
-		/*Fast-track the request*/
-		cluster_offset = l2_offset + (s->l2_size * sizeof(uint64_t));
-		l2_index = (offset >> s->cluster_bits) & (s->l2_size - 1);
-		return cluster_offset + (l2_index * s->cluster_size);
-	}
-
-	/*Check to see if L2 entry is already cached*/
-	for (i = 0; i < L2_CACHE_SIZE; i++) {
-		if (l2_offset == s->l2_cache_offsets[i]) {
-			/* increment the hit count */
-			if (++s->l2_cache_counts[i] == 0xffffffff) {
-				for (j = 0; j < L2_CACHE_SIZE; j++) {
-					s->l2_cache_counts[j] >>= 1;
-				}
-			}
-			l2_table = s->l2_cache + (i << s->l2_bits);
-			goto found;
-		}
-	}
-
-cache_miss:
-	/* not found: load a new entry in the least used one */
-	min_index = 0;
-	min_count = 0xffffffff;
-	for (i = 0; i < L2_CACHE_SIZE; i++) {
-		if (s->l2_cache_counts[i] < min_count) {
-			min_count = s->l2_cache_counts[i];
-			min_index = i;
-		}
-	}
-	l2_table = s->l2_cache + (min_index << s->l2_bits);
-
-	/*If extent pre-allocated, read table from disk, 
-	 *otherwise write new table to disk*/
-	if (new_l2_table) {
-		/*Should we allocate the whole extent? Adjustable parameter.*/
-		if (s->cluster_alloc == s->l2_size) {
-			cluster_offset = l2_offset + 
-				(s->l2_size * sizeof(uint64_t));
-			cluster_offset = (cluster_offset + s->cluster_size - 1)
-				& ~(s->cluster_size - 1);
-			if (qtruncate(s->fd, cluster_offset + 
-				  (s->cluster_size * s->l2_size), 
-				      s->sparse) != 0) {
-				DPRINTF("ERROR truncating file\n");
-				return 0;
-			}
-			s->fd_end = cluster_offset + 
-				(s->cluster_size * s->l2_size);
-			for (i = 0; i < s->l2_size; i++) {
-				l2_table[i] = cpu_to_be64(cluster_offset + 
-							  (i*s->cluster_size));
-			}  
-		} else memset(l2_table, 0, s->l2_size * sizeof(uint64_t));
-
-		lseek(s->fd, l2_offset, SEEK_SET);
-		if (write(s->fd, l2_table, s->l2_size * sizeof(uint64_t)) !=
-		   s->l2_size * sizeof(uint64_t))
-			return 0;
-	} else {
-		lseek(s->fd, l2_offset, SEEK_SET);
-		if (read(s->fd, l2_table, s->l2_size * sizeof(uint64_t)) != 
-		    s->l2_size * sizeof(uint64_t))
-			return 0;
-	}
-	
-	/*Update the cache entries*/ 
-	s->l2_cache_offsets[min_index] = l2_offset;
-	s->l2_cache_counts[min_index] = 1;
-
-found:
-	/*The extent is split into 's->l2_size' blocks of 
-	 *size 's->cluster_size'*/
-	l2_index = (offset >> s->cluster_bits) & (s->l2_size - 1);
-	cluster_offset = be64_to_cpu(l2_table[l2_index]);
-
-	if (!cluster_offset || 
-	    ((cluster_offset & QCOW_OFLAG_COMPRESSED) && allocate == 1) ) {
-		if (!allocate)
-			return 0;
-		
-		if ((cluster_offset & QCOW_OFLAG_COMPRESSED) &&
-		    (n_end - n_start) < s->cluster_sectors) {
-			/* cluster is already allocated but compressed, we must
-			   decompress it in the case it is not completely
-			   overwritten */
-			if (decompress_cluster(s, cluster_offset) < 0)
-				return 0;
-			cluster_offset = lseek(s->fd, s->fd_end, SEEK_SET);
-			cluster_offset = (cluster_offset + s->cluster_size - 1)
-				& ~(s->cluster_size - 1);
-			/* write the cluster content - not asynchronous */
-			lseek(s->fd, cluster_offset, SEEK_SET);
-			if (write(s->fd, s->cluster_cache, s->cluster_size) != 
-			    s->cluster_size)
-			    return -1;
-		} else {
-			/* allocate a new cluster */
-			cluster_offset = lseek(s->fd, s->fd_end, SEEK_SET);
-			if (allocate == 1) {
-				/* round to cluster size */
-				cluster_offset = 
-					(cluster_offset + s->cluster_size - 1) 
-					& ~(s->cluster_size - 1);
-				if (qtruncate(s->fd, cluster_offset + 
-					      s->cluster_size, s->sparse)!=0) {
-					DPRINTF("ERROR truncating file\n");
-					return 0;
-				}
-				s->fd_end = (cluster_offset + s->cluster_size);
-				/* if encrypted, we must initialize the cluster
-				   content which won't be written */
-				if (s->crypt_method && 
-				    (n_end - n_start) < s->cluster_sectors) {
-					uint64_t start_sect;
-					start_sect = (offset & 
-						      ~(s->cluster_size - 1)) 
-							      >> 9;
-					memset(s->cluster_data + 512, 
-					       0xaa, 512);
-					for (i = 0; i < s->cluster_sectors;i++)
-					{
-						if (i < n_start || i >= n_end) 
-						{
-							encrypt_sectors(s, start_sect + i, 
-									s->cluster_data, 
-									s->cluster_data + 512, 1, 1,
-									&s->aes_encrypt_key);
-							lseek(s->fd, cluster_offset + i * 512, SEEK_SET);
-							if (write(s->fd, s->cluster_data, 512) != 512)
-								return -1;
-						}
-					}
-				}
-			} else {
-				cluster_offset |= QCOW_OFLAG_COMPRESSED | 
-					(uint64_t)compressed_size 
-						<< (63 - s->cluster_bits);
-			}
-		}
-		/* update L2 table */
-		tmp = cpu_to_be64(cluster_offset);
-		l2_table[l2_index] = tmp;
-
-		/*For IO_DIRECT we write 4KByte blocks*/
-		l2_sector = (l2_index * sizeof(uint64_t)) >> 12;
-		l2_ptr = (char *)l2_table + (l2_sector << 12);
-		
-		if (posix_memalign((void **)&tmp_ptr2, 4096, 4096) != 0) {
-			DPRINTF("ERROR allocating memory for L1 table\n");
-		}
-		memcpy(tmp_ptr2, l2_ptr, 4096);
-		lseek(s->fd, l2_offset + (l2_sector << 12), SEEK_SET);
-		if (write(s->fd, tmp_ptr2, 4096) != 4096) {
-			free(tmp_ptr2);
-			return -1;
-		}
-		free(tmp_ptr2);
-	}
-	return cluster_offset;
-}
-
-static void init_cluster_cache(struct disk_driver *dd)
-{
-	struct td_state     *bs = dd->td_state;
-	struct tdqcow_state *s  = (struct tdqcow_state *)dd->private;
-	uint32_t count = 0;
-	int i, cluster_entries;
-
-	cluster_entries = s->cluster_size / 512;
-	DPRINTF("Initialising Cluster cache, %d sectors per cluster (%d cluster size)\n",
-		cluster_entries, s->cluster_size);
-
-	for (i = 0; i < bs->size; i += cluster_entries) {
-		if (get_cluster_offset(s, i << 9, 0, 0, 0, 1)) count++;
-		if (count >= L2_CACHE_SIZE) return;
-	}
-	DPRINTF("Finished cluster initialisation, added %d entries\n", count);
-	return;
-}
-
-static int qcow_is_allocated(struct tdqcow_state *s, int64_t sector_num,
-                             int nb_sectors, int *pnum)
-{
-	int index_in_cluster, n;
-	uint64_t cluster_offset;
-
-	cluster_offset = get_cluster_offset(s, sector_num << 9, 0, 0, 0, 0);
-	index_in_cluster = sector_num & (s->cluster_sectors - 1);
-	n = s->cluster_sectors - index_in_cluster;
-	if (n > nb_sectors)
-		n = nb_sectors;
-	*pnum = n;
-	return (cluster_offset != 0);
-}
-
-static int decompress_buffer(uint8_t *out_buf, int out_buf_size,
-                             const uint8_t *buf, int buf_size)
-{
-	z_stream strm1, *strm = &strm1;
-	int ret, out_len;
-	
-	memset(strm, 0, sizeof(*strm));
-	
-	strm->next_in = (uint8_t *)buf;
-	strm->avail_in = buf_size;
-	strm->next_out = out_buf;
-	strm->avail_out = out_buf_size;
-	
-	ret = inflateInit2(strm, -12);
-	if (ret != Z_OK)
-		return -1;
-	ret = inflate(strm, Z_FINISH);
-	out_len = strm->next_out - out_buf;
-	if ( (ret != Z_STREAM_END && ret != Z_BUF_ERROR) ||
-	    (out_len != out_buf_size) ) {
-		inflateEnd(strm);
-		return -1;
-	}
-	inflateEnd(strm);
-	return 0;
-}
-                              
-static int decompress_cluster(struct tdqcow_state *s, uint64_t cluster_offset)
-{
-	int ret, csize;
-	uint64_t coffset;
-
-	coffset = cluster_offset & s->cluster_offset_mask;
-	if (s->cluster_cache_offset != coffset) {
-		csize = cluster_offset >> (63 - s->cluster_bits);
-		csize &= (s->cluster_size - 1);
-		lseek(s->fd, coffset, SEEK_SET);
-		ret = read(s->fd, s->cluster_data, csize);
-		if (ret != csize) 
-			return -1;
-		if (decompress_buffer(s->cluster_cache, s->cluster_size,
-				      s->cluster_data, csize) < 0) {
-			return -1;
-		}
-		s->cluster_cache_offset = coffset;
-	}
-	return 0;
-}
-
-static inline void init_fds(struct disk_driver *dd)
-{
-	int i;
-	struct tdqcow_state *s = (struct tdqcow_state *)dd->private;
-
-	for(i = 0; i < MAX_IOFD; i++) 
-		dd->io_fd[i] = 0;
-
-	dd->io_fd[0] = s->aio.aio_ctx.pollfd;
-}
-
-/* Open the disk file and initialize qcow state. */
-static int tdqcow_open (struct disk_driver *dd, const char *name, td_flag_t flags)
-{
-	int fd, len, i, shift, ret, size, l1_table_size, o_flags, l1_table_block;
-	int max_aio_reqs;
-	struct td_state     *bs = dd->td_state;
-	struct tdqcow_state *s  = (struct tdqcow_state *)dd->private;
-	char *buf, *buf2;
-	QCowHeader *header;
-	QCowHeader_ext *exthdr;
-	uint32_t cksum;
-	uint64_t final_cluster = 0;
-
- 	DPRINTF("QCOW: Opening %s\n",name);
-
-	o_flags = O_DIRECT | O_LARGEFILE | 
-		((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-	fd = open(name, o_flags);
-	if (fd < 0) {
-		DPRINTF("Unable to open %s (%d)\n",name,0 - errno);
-		return -1;
-	}
-
-	s->fd = fd;
-	if (asprintf(&s->name,"%s", name) == -1) {
-		close(fd);
-		return -1;
-	}
-
-	ASSERT(sizeof(QCowHeader) + sizeof(QCowHeader_ext) < 512);
-
-	ret = posix_memalign((void **)&buf, 512, 512);
-	if (ret != 0) goto fail;
-
-	if (read(fd, buf, 512) != 512)
-		goto fail;
-
-	header = (QCowHeader *)buf;
-	be32_to_cpus(&header->magic);
-	be32_to_cpus(&header->version);
-	be64_to_cpus(&header->backing_file_offset);
-	be32_to_cpus(&header->backing_file_size);
-	be32_to_cpus(&header->mtime);
-	be64_to_cpus(&header->size);
-	be32_to_cpus(&header->crypt_method);
-	be64_to_cpus(&header->l1_table_offset);
-
-	if (header->magic != QCOW_MAGIC)
-		goto fail;
-
-	switch (header->version) {
-	case QCOW_VERSION:
-		break;
-	case 2:
-		close(fd);
-		dd->drv = &tapdisk_qcow2;
-		return dd->drv->td_open(dd, name, flags);
-	default:
-		goto fail;
-	}
-
-	if (header->size <= 1 || header->cluster_bits < 9)
-		goto fail;
-	if (header->crypt_method > QCOW_CRYPT_AES)
-		goto fail;
-	s->crypt_method_header = header->crypt_method;
-	if (s->crypt_method_header)
-		s->encrypted = 1;
-	s->cluster_bits = header->cluster_bits;
-	s->cluster_size = 1 << s->cluster_bits;
-	s->cluster_sectors = 1 << (s->cluster_bits - 9);
-	s->l2_bits = header->l2_bits;
-	s->l2_size = 1 << s->l2_bits;
-	s->cluster_alloc = s->l2_size;
-	bs->size = header->size / 512;
-	s->cluster_offset_mask = (1LL << (63 - s->cluster_bits)) - 1;
-	s->backing_file_offset = header->backing_file_offset;
-	s->backing_file_size   = header->backing_file_size;
-
-	/* read the level 1 table */
-	shift = s->cluster_bits + s->l2_bits;
-	s->l1_size = ROUNDUP(header->size, 1LL << shift);
-	
-	s->l1_table_offset = header->l1_table_offset;
-
-	/*allocate a 4Kbyte multiple of memory*/
-	l1_table_size = s->l1_size * sizeof(uint64_t);
-	if (l1_table_size % 4096 > 0) {
-		l1_table_size = ROUNDUP(l1_table_size, 4096);
-	}
-	ret = posix_memalign((void **)&s->l1_table, 4096, l1_table_size);
-	if (ret != 0) goto fail;
-
-	memset(s->l1_table, 0x00, l1_table_size);
-
-	DPRINTF("L1 Table offset detected: %llu, size %d (%d)\n",
-		(long long)s->l1_table_offset,
-		(int) (s->l1_size * sizeof(uint64_t)), 
-		l1_table_size);
-
-	lseek(fd, 0, SEEK_SET);
-	l1_table_block = l1_table_size + s->l1_table_offset;
-	l1_table_block = ROUNDUP(l1_table_block, 512);
-	ret = posix_memalign((void **)&buf2, 4096, l1_table_block);
-	if (ret != 0) goto fail;
-	if (read(fd, buf2, l1_table_block) < l1_table_size + s->l1_table_offset)
-		goto fail;
-	memcpy(s->l1_table, buf2 + s->l1_table_offset, l1_table_size);
-
-	for(i = 0; i < s->l1_size; i++) {
-		be64_to_cpus(&s->l1_table[i]);
-		//DPRINTF("L1[%d] => %llu\n", i, s->l1_table[i]);
-		if (s->l1_table[i] > final_cluster)
-			final_cluster = s->l1_table[i];
-	}
-
-	/* alloc L2 cache */
-	size = s->l2_size * L2_CACHE_SIZE * sizeof(uint64_t);
-	ret = posix_memalign((void **)&s->l2_cache, 4096, size);
-	if(ret != 0) goto fail;
-
-	size = s->cluster_size;
-	ret = posix_memalign((void **)&s->cluster_cache, 4096, size);
-	if(ret != 0) goto fail;
-
-	ret = posix_memalign((void **)&s->cluster_data, 4096, size);
-	if(ret != 0) goto fail;
-	s->cluster_cache_offset = -1;
-
-	if (s->backing_file_offset != 0)
-		s->cluster_alloc = 1; /*Cannot use pre-alloc*/
-
-        bs->sector_size = 512;
-        bs->info = 0;
-	
-	/*Detect min_cluster_alloc*/
-	s->min_cluster_alloc = 1; /*Default*/
-	if (s->backing_file_offset == 0 && s->l1_table_offset % 4096 == 0) {
-		/*We test to see if the xen magic # exists*/
-		exthdr = (QCowHeader_ext *)(buf + sizeof(QCowHeader));
-		be32_to_cpus(&exthdr->xmagic);
-		if(exthdr->xmagic != XEN_MAGIC) 
-			goto end_xenhdr;
-	
-		be32_to_cpus(&exthdr->flags);
-		/* Try to detect old tapdisk images. They have to be fixed because 
-		 * they don't use big endian but native endianess for the L1 table */
-		if ((exthdr->flags & EXTHDR_L1_BIG_ENDIAN) == 0) {
-			QCowHeader_ext *tmphdr = (QCowHeader_ext *)(buf2 + sizeof(QCowHeader));
-			/* 
-			   The image is broken. Fix it. The L1 table has already been 
-			   byte-swapped, so we can write it to the image file as it is
-			   currently in memory. Then swap it back to native endianess
-			   for operation.
-			 */
-
-			/* Change ENDIAN flag and copy it to store buffer */
-			exthdr->flags |= EXTHDR_L1_BIG_ENDIAN;
-			tmphdr->flags = cpu_to_be32(exthdr->flags);
-
-
-			DPRINTF("qcow: Converting image to big endian L1 table\n");
-
-			memcpy(buf2 + s->l1_table_offset, s->l1_table, l1_table_size);
-			lseek(fd, 0, SEEK_SET);
-			if (write(fd, buf2, l1_table_block) < 
-				l1_table_size + s->l1_table_offset) {
-				DPRINTF("qcow: Failed to write new L1 table\n");
-				goto fail;
-			}
-
-			for(i = 0;i < s->l1_size; i++) {
-				cpu_to_be64s(&s->l1_table[i]);
-			}
-
-		}
-
-		/*Finally check the L1 table cksum*/
-		be32_to_cpus(&exthdr->cksum);
-		cksum = gen_cksum((char *)s->l1_table, 
-				  s->l1_size * sizeof(uint64_t));
-		if(exthdr->cksum != cksum)
-			goto end_xenhdr;
-			
-		be32_to_cpus(&exthdr->min_cluster_alloc);
-		s->sparse = (exthdr->flags & SPARSE_FILE);
-		s->min_cluster_alloc = exthdr->min_cluster_alloc; 
-	}
-
- end_xenhdr:
- 	
-	/* A segment (i.e. a page) can span multiple clusters */
-	max_aio_reqs = ((getpagesize() / s->cluster_size) + 1) *
-		MAX_SEGMENTS_PER_REQ * MAX_REQUESTS;
-
-	if (tap_aio_init(&s->aio, bs->size, max_aio_reqs)!=0) {
-		DPRINTF("Unable to initialise AIO state\n");
-                tap_aio_free(&s->aio);
-		goto fail;
-	}
-	init_fds(dd);
-
-	if (!final_cluster)
-		s->fd_end = l1_table_block;
-	else {
-		s->fd_end = lseek(fd, 0, SEEK_END);
-		if (s->fd_end == (off_t)-1)
-			goto fail;
-	}
-
-	return 0;
-	
-fail:
-	DPRINTF("QCOW Open failed\n");
-	tap_aio_free(&s->aio);
-	free(s->l1_table);
-	free(s->l2_cache);
-	free(s->cluster_cache);
-	free(s->cluster_data);
-	close(fd);
-	return -1;
-}
-
-static int tdqcow_queue_read(struct disk_driver *dd, uint64_t sector,
-		      int nb_sectors, char *buf, td_callback_t cb,
-		      int id, void *private)
-{
-	struct tdqcow_state *s = (struct tdqcow_state *)dd->private;
-	int ret = 0, index_in_cluster, n, i, rsp = 0;
-	uint64_t cluster_offset, sec, nr_secs;
-
-	sec     = sector;
-	nr_secs = nb_sectors;
-
-	/*Check we can get a lock*/
-	for (i = 0; i < nb_sectors; i++) 
-		if (!tap_aio_can_lock(&s->aio, sector + i)) 
-			return cb(dd, -EBUSY, sector, nb_sectors, id, private);
-
-	/*We store a local record of the request*/
-	while (nb_sectors > 0) {
-		cluster_offset = 
-			get_cluster_offset(s, sector << 9, 0, 0, 0, 0);
-		index_in_cluster = sector & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-
-		if (s->aio.iocb_free_count == 0 || !tap_aio_lock(&s->aio, sector)) 
-			return cb(dd, -EBUSY, sector, nb_sectors, id, private);
-		
-		if(!cluster_offset) {
-			tap_aio_unlock(&s->aio, sector);
-			ret = cb(dd, BLK_NOT_ALLOCATED, 
-				 sector, n, id, private);
-			if (ret == -EBUSY) {
-				/* mark remainder of request
-				 * as busy and try again later */
-				return cb(dd, -EBUSY, sector + n,
-					  nb_sectors - n, id, private);
-			} else
-				rsp += ret;
-		} else if (cluster_offset & QCOW_OFLAG_COMPRESSED) {
-			tap_aio_unlock(&s->aio, sector);
-			if (decompress_cluster(s, cluster_offset) < 0) {
-				rsp += cb(dd, -EIO, sector, 
-					  nb_sectors, id, private);
-				goto done;
-			}
-			memcpy(buf, s->cluster_cache + index_in_cluster * 512, 
-			       512 * n);
-			rsp += cb(dd, 0, sector, n, id, private);
-		} else {
-			tap_aio_read(&s->aio, s->fd, n * 512, 
-				   (cluster_offset + index_in_cluster * 512),
-				   buf, cb, id, sector, private);
-		}
-		nb_sectors -= n;
-		sector += n;
-		buf += n * 512;
-	}
-done:
-	return rsp;
-}
-
-static int tdqcow_queue_write(struct disk_driver *dd, uint64_t sector,
-		       int nb_sectors, char *buf, td_callback_t cb,
-		       int id, void *private)
-{
-	struct tdqcow_state *s = (struct tdqcow_state *)dd->private;
-	int ret = 0, index_in_cluster, n, i;
-	uint64_t cluster_offset, sec, nr_secs;
-
-	sec     = sector;
-	nr_secs = nb_sectors;
-
-	/*Check we can get a lock*/
-	for (i = 0; i < nb_sectors; i++)
-		if (!tap_aio_can_lock(&s->aio, sector + i))  
-			return cb(dd, -EBUSY, sector, nb_sectors, id, private);
-		   
-	/*We store a local record of the request*/
-	while (nb_sectors > 0) {
-		index_in_cluster = sector & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-
-		if (s->aio.iocb_free_count == 0 || !tap_aio_lock(&s->aio, sector))
-			return cb(dd, -EBUSY, sector, nb_sectors, id, private);
-
-		cluster_offset = get_cluster_offset(s, sector << 9, 1, 0,
-						    index_in_cluster, 
-						    index_in_cluster+n);
-		if (!cluster_offset) {
-			DPRINTF("Ooops, no write cluster offset!\n");
-			tap_aio_unlock(&s->aio, sector);
-			return cb(dd, -EIO, sector, nb_sectors, id, private);
-		}
-
-		if (s->crypt_method) {
-			encrypt_sectors(s, sector, s->cluster_data, 
-					(unsigned char *)buf, n, 1,
-					&s->aes_encrypt_key);
-			tap_aio_write(&s->aio, s->fd, n * 512, 
-				    (cluster_offset + index_in_cluster*512),
-				    (char *)s->cluster_data, cb, id, sector, 
-				    private);
-		} else {
-			tap_aio_write(&s->aio, s->fd, n * 512, 
-				    (cluster_offset + index_in_cluster*512),
-				    buf, cb, id, sector, private);
-		}
-		
-		nb_sectors -= n;
-		sector += n;
-		buf += n * 512;
-	}
-	s->cluster_cache_offset = -1; /* disable compressed cache */
-
-	return 0;
-}
- 		
-static int tdqcow_submit(struct disk_driver *dd)
-{
-        struct tdqcow_state *prv = (struct tdqcow_state *)dd->private;
-
-	return tap_aio_submit(&prv->aio);
-}
-
-static int tdqcow_close(struct disk_driver *dd)
-{
-	struct tdqcow_state *s = (struct tdqcow_state *)dd->private;
-	uint32_t cksum, out;
-	int fd, offset;
-
-	/*Update the hdr cksum*/
-	if(s->min_cluster_alloc == s->l2_size) {
-		cksum = gen_cksum((char *)s->l1_table, s->l1_size * sizeof(uint64_t));
-		printf("Writing cksum: %d",cksum);
-		fd = open(s->name, O_WRONLY | O_LARGEFILE); /*Open without O_DIRECT*/
-		offset = sizeof(QCowHeader) + sizeof(uint32_t);
-		lseek(fd, offset, SEEK_SET);
-		out = cpu_to_be32(cksum);
-		if (write(fd, &out, sizeof(uint32_t))) ;
-		close(fd);
-	}
-
-	io_destroy(s->aio.aio_ctx.aio_ctx);
-	free(s->name);
-	free(s->l1_table);
-	free(s->l2_cache);
-	free(s->cluster_cache);
-	free(s->cluster_data);
-	close(s->fd);	
-	return 0;
-}
-
-static int tdqcow_do_callbacks(struct disk_driver *dd, int sid)
-{
-        int ret, i, nr_events, rsp = 0,*ptr;
-        struct io_event *ep;
-        struct tdqcow_state *prv = (struct tdqcow_state *)dd->private;
-
-        if (sid > MAX_IOFD) return 1;
-
-        nr_events = tap_aio_get_events(&prv->aio.aio_ctx);
-repeat:
-        for (ep = prv->aio.aio_events, i = nr_events; i-- > 0; ep++) {
-                struct iocb        *io  = ep->obj;
-                struct pending_aio *pio;
-
-                pio = &prv->aio.pending_aio[(long)io->data];
-
-		tap_aio_unlock(&prv->aio, pio->sector);
-
-		if (prv->crypt_method)
-			encrypt_sectors(prv, pio->sector, 
-					(unsigned char *)pio->buf, 
-					(unsigned char *)pio->buf, 
-					pio->nb_sectors, 0, 
-					&prv->aes_decrypt_key);
-
-		rsp += pio->cb(dd, ep->res == io->u.c.nbytes ? 0 : 1, 
-			       pio->sector, pio->nb_sectors,
-			       pio->id, pio->private);
-
-                prv->aio.iocb_free[prv->aio.iocb_free_count++] = io;
-        }
-
-        if (nr_events) {
-                nr_events = tap_aio_more_events(&prv->aio.aio_ctx);
-                goto repeat;
-        }
-
-        tap_aio_continue(&prv->aio.aio_ctx);
-
-        return rsp;
-}
-
-int qcow_create(const char *filename, uint64_t total_size,
-		const char *backing_file, int sparse)
-{
-	int fd, header_size, backing_filename_len, l1_size, i;
-	int shift, length, adjust, flags = 0, ret = 0;
-	QCowHeader header;
-	QCowHeader_ext exthdr;
-	char backing_filename[PATH_MAX], *ptr;
-	uint64_t tmp, size, total_length;
-	struct stat st;
-
-	DPRINTF("Qcow_create: size %llu\n",(long long unsigned)total_size);
-
-	fd = open(filename, 
-		  O_WRONLY | O_CREAT | O_TRUNC | O_BINARY | O_LARGEFILE,
-		  0644);
-	if (fd < 0)
-		return -1;
-
-	memset(&header, 0, sizeof(header));
-	header.magic = cpu_to_be32(QCOW_MAGIC);
-	header.version = cpu_to_be32(QCOW_VERSION);
-
-	/*Create extended header fields*/
-	exthdr.xmagic = cpu_to_be32(XEN_MAGIC);
-
-	header_size = sizeof(header) + sizeof(QCowHeader_ext);
-	backing_filename_len = 0;
-	size = (total_size >> SECTOR_SHIFT);
-	if (backing_file) {
-		if (strcmp(backing_file, "fat:")) {
-			const char *p;
-			/* XXX: this is a hack: we do not attempt to 
-			 *check for URL like syntax */
-			p = strchr(backing_file, ':');
-			if (p && (p - backing_file) >= 2) {
-				/* URL like but exclude "c:" like filenames */
-				strncpy(backing_filename, backing_file,
-					sizeof(backing_filename));
-			} else {
-				if (realpath(backing_file, backing_filename) == NULL ||
-				    stat(backing_filename, &st) != 0) {
-					return -1;
-				}
-			}
-			header.backing_file_offset = cpu_to_be64(header_size);
-			backing_filename_len = strlen(backing_filename);
-			header.backing_file_size = cpu_to_be32(
-				backing_filename_len);
-			header_size += backing_filename_len;
-			
-			/*Set to the backing file size*/
-			if(get_filesize(backing_filename, &size, &st)) {
-				return -1;
-			}
-			DPRINTF("Backing file size detected: %lld sectors" 
-				"(total %lld [%lld MB])\n", 
-				(long long)size, 
-				(long long)(size << SECTOR_SHIFT), 
-				(long long)(size >> 11));
-		} else {
-			backing_file = NULL;
-			DPRINTF("Setting file size: %lld (total %lld)\n", 
-				(long long) total_size, 
-				(long long) (total_size << SECTOR_SHIFT));
-		}
-		header.mtime = cpu_to_be32(st.st_mtime);
-		header.cluster_bits = 9; /* 512 byte cluster to avoid copying
-					    unmodifyed sectors */
-		header.l2_bits = 12; /* 32 KB L2 tables */
-		exthdr.min_cluster_alloc = cpu_to_be32(1);
-	} else {
-		DPRINTF("Setting file size: %lld sectors" 
-			"(total %lld [%lld MB])\n", 
-			(long long) size, 
-			(long long) (size << SECTOR_SHIFT), 
-			(long long) (size >> 11));
-		header.cluster_bits = 12; /* 4 KB clusters */
-		header.l2_bits = 9; /* 4 KB L2 tables */
-		exthdr.min_cluster_alloc = cpu_to_be32(1 << 9);
-	}
-	/*Set the header size value*/
-	header.size = cpu_to_be64(size * 512);
-	
-	header_size = (header_size + 7) & ~7;
-	if (header_size % 4096 > 0) {
-		header_size = ROUNDUP(header_size, 4096);
-	}
-
-	shift = header.cluster_bits + header.l2_bits;
-	l1_size = ROUNDUP(size * 512, 1LL << shift);
-
-	header.l1_table_offset = cpu_to_be64(header_size);
-	DPRINTF("L1 Table offset: %d, size %d\n",
-		header_size,
-		(int)(l1_size * sizeof(uint64_t)));
-	header.crypt_method = cpu_to_be32(QCOW_CRYPT_NONE);
-
-	ptr = calloc(1, l1_size * sizeof(uint64_t));
-	exthdr.cksum = cpu_to_be32(gen_cksum(ptr, l1_size * sizeof(uint64_t)));
-	printf("Created cksum: %d\n",exthdr.cksum);
-	free(ptr);
-
-	/*adjust file length to system page size boundary*/
-	length = ROUNDUP(header_size + (l1_size * sizeof(uint64_t)),
-		getpagesize());
-	if (qtruncate(fd, length, 0)!=0) {
-		DPRINTF("ERROR truncating file\n");
-		return -1;
-	}
-
-	if (sparse == 0) {
-		/*Filesize is length+l1_size*(1 << s->l2_bits)+(size*512)*/
-		total_length = length + (l1_size * (1 << 9)) + (size * 512);
-		if (qtruncate(fd, total_length, 0)!=0) {
-                        DPRINTF("ERROR truncating file\n");
-                        return -1;
-		}
-		printf("File truncated to length %"PRIu64"\n",total_length);
-	} else
-		flags = SPARSE_FILE;
-
-	flags |= EXTHDR_L1_BIG_ENDIAN;
-	exthdr.flags = cpu_to_be32(flags);
-	
-	/* write all the data */
-	lseek(fd, 0, SEEK_SET);
-	ret += write(fd, &header, sizeof(header));
-	ret += write(fd, &exthdr, sizeof(exthdr));
-	if (backing_file)
-		ret += write(fd, backing_filename, backing_filename_len);
-
-	lseek(fd, header_size, SEEK_SET);
-	tmp = 0;
-	for (i = 0;i < l1_size; i++) {
-		ret += write(fd, &tmp, sizeof(tmp));
-	}
-
-	close(fd);
-
-	return 0;
-}
-
-static int qcow_make_empty(struct tdqcow_state *s)
-{
-	uint32_t l1_length = s->l1_size * sizeof(uint64_t);
-
-	memset(s->l1_table, 0, l1_length);
-	lseek(s->fd, s->l1_table_offset, SEEK_SET);
-	if (write(s->fd, s->l1_table, l1_length) < 0)
-		return -1;
-	if (qtruncate(s->fd, s->l1_table_offset + l1_length, s->sparse)!=0) {
-		DPRINTF("ERROR truncating file\n");
-		return -1;
-	}
-
-	memset(s->l2_cache, 0, s->l2_size * L2_CACHE_SIZE * sizeof(uint64_t));
-	memset(s->l2_cache_offsets, 0, L2_CACHE_SIZE * sizeof(uint64_t));
-	memset(s->l2_cache_counts, 0, L2_CACHE_SIZE * sizeof(uint32_t));
-
-	return 0;
-}
-
-static int qcow_get_cluster_size(struct tdqcow_state *s)
-{
-	return s->cluster_size;
-}
-
-/* XXX: put compressed sectors first, then all the cluster aligned
-   tables to avoid losing bytes in alignment */
-static int qcow_compress_cluster(struct tdqcow_state *s, int64_t sector_num, 
-                          const uint8_t *buf)
-{
-	z_stream strm;
-	int ret, out_len;
-	uint8_t *out_buf;
-	uint64_t cluster_offset;
-
-	out_buf = malloc(s->cluster_size + (s->cluster_size / 1000) + 128);
-	if (!out_buf)
-		return -1;
-
-	/* best compression, small window, no zlib header */
-	memset(&strm, 0, sizeof(strm));
-	ret = deflateInit2(&strm, Z_DEFAULT_COMPRESSION,
-			   Z_DEFLATED, -12, 
-			   9, Z_DEFAULT_STRATEGY);
-	if (ret != 0) {
-		free(out_buf);
-		return -1;
-	}
-
-	strm.avail_in = s->cluster_size;
-	strm.next_in = (uint8_t *)buf;
-	strm.avail_out = s->cluster_size;
-	strm.next_out = out_buf;
-
-	ret = deflate(&strm, Z_FINISH);
-	if (ret != Z_STREAM_END && ret != Z_OK) {
-		free(out_buf);
-		deflateEnd(&strm);
-		return -1;
-	}
-	out_len = strm.next_out - out_buf;
-
-	deflateEnd(&strm);
-
-	if (ret != Z_STREAM_END || out_len >= s->cluster_size) {
-		/* could not compress: write normal cluster */
-		//tdqcow_queue_write(bs, sector_num, buf, s->cluster_sectors);
-	} else {
-		cluster_offset = get_cluster_offset(s, sector_num << 9, 2, 
-                                            out_len, 0, 0);
-		cluster_offset &= s->cluster_offset_mask;
-		lseek(s->fd, cluster_offset, SEEK_SET);
-		if (write(s->fd, out_buf, out_len) != out_len) {
-			free(out_buf);
-			return -1;
-		}
-	}
-	
-	free(out_buf);
-	return 0;
-}
-
-static int tdqcow_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	off_t off;
-	char *buf, *filename;
-	int len, secs, err = -EINVAL;
-	struct tdqcow_state *child  = (struct tdqcow_state *)dd->private;
-
-	if (!child->backing_file_offset)
-		return TD_NO_PARENT;
-
-	/* read the backing file name */
-	len  = child->backing_file_size;
-	off  = child->backing_file_offset - (child->backing_file_offset % 512);
-	secs = (len + (child->backing_file_offset - off) + 511) >> 9;
-
-	if (posix_memalign((void **)&buf, 512, secs << 9)) 
-		return -1;
-
-	if (lseek(child->fd, off, SEEK_SET) == (off_t)-1)
-		goto out;
-
-	if (read(child->fd, buf, secs << 9) != secs << 9)
-		goto out;
-	filename       = buf + (child->backing_file_offset - off);
-	filename[len]  = '\0';
-
-	id->name       = strdup(filename);
-	id->drivertype = DISK_TYPE_AIO;
-	err            = 0;
- out:
-	free(buf);
-	return err;
-}
-
-static int tdqcow_validate_parent(struct disk_driver *child,
-			   struct disk_driver *parent, td_flag_t flags)
-{
-	struct stat stats;
-	uint64_t psize, csize;
-	
-	if (stat(parent->name, &stats))
-		return -EINVAL;
-	if (get_filesize(parent->name, &psize, &stats))
-		return -EINVAL;
-
-	if (stat(child->name, &stats))
-		return -EINVAL;
-	if (get_filesize(child->name, &csize, &stats))
-		return -EINVAL;
-
-	if (csize != psize)
-		return -EINVAL;
-
-	return 0;
-}
-
-struct tap_disk tapdisk_qcow = {
-	.disk_type           = "tapdisk_qcow",
-	.private_data_size   = sizeof(struct tdqcow_state),
-	.td_open             = tdqcow_open,
-	.td_queue_read       = tdqcow_queue_read,
-	.td_queue_write      = tdqcow_queue_write,
-	.td_submit           = tdqcow_submit,
-	.td_close            = tdqcow_close,
-	.td_do_callbacks     = tdqcow_do_callbacks,
-	.td_get_parent_id    = tdqcow_get_parent_id,
-	.td_validate_parent  = tdqcow_validate_parent
-};
diff --git a/tools/blktap/drivers/block-qcow2.c b/tools/blktap/drivers/block-qcow2.c
deleted file mode 100644
index ceda4f0..0000000
--- a/tools/blktap/drivers/block-qcow2.c
+++ /dev/null
@@ -1,2098 +0,0 @@
-/*
- * Block driver for the QCOW version 2 format
- *
- * Copyright (c) 2004-2006 Fabrice Bellard
- *
- * 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.
- */
-
-#include <zlib.h>
-#include "aes.h"
-#include <assert.h>
-#include <stdint.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <sys/stat.h>
-
-#include "tapdisk.h"
-#include "tapaio.h"
-#include "bswap.h"
-#include "blk.h"
-
-#define USE_AIO
-
-#define qemu_malloc malloc
-#define qemu_mallocz(size) calloc(1, size)
-#define qemu_free free
-
-#ifndef O_BINARY
-#define O_BINARY 0
-#endif
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE     0 
-#endif
-
-#define BLOCK_FLAG_ENCRYPT 1
-
-/*
-  Differences with QCOW:
-
-  - Support for multiple incremental snapshots.
-  - Memory management by reference counts.
-  - Clusters which have a reference count of one have the bit
-	QCOW_OFLAG_COPIED to optimize write performance.
-  - Size of compressed clusters is stored in sectors to reduce bit usage
-	in the cluster offsets.
-  - Support for storing additional data (such as the VM state) in the
-	snapshots.
-  - If a backing store is used, the cluster size is not constrained
-	(could be backported to QCOW).
-  - L2 tables have always a size of one cluster.
-*/
-
-//#define DEBUG_ALLOC
-//#define DEBUG_ALLOC2
-
-#define QCOW_MAGIC (('Q' << 24) | ('F' << 16) | ('I' << 8) | 0xfb)
-#define QCOW_VERSION 2
-
-#define QCOW_CRYPT_NONE 0
-#define QCOW_CRYPT_AES	1
-
-/* indicate that the refcount of the referenced cluster is exactly one. */
-#define QCOW_OFLAG_COPIED	  (1LL << 63)
-/* indicate that the cluster is compressed (they never have the copied flag) */
-#define QCOW_OFLAG_COMPRESSED (1LL << 62)
-
-#define REFCOUNT_SHIFT 1 /* refcount size is 2 bytes */
-
-#ifndef offsetof
-#define offsetof(type, field) ((size_t) &((type *)0)->field)
-#endif
-
-typedef struct QCowHeader {
-	uint32_t magic;
-	uint32_t version;
-	uint64_t backing_file_offset;
-	uint32_t backing_file_size;
-	uint32_t cluster_bits;
-	uint64_t size; /* in bytes */
-
-	uint32_t crypt_method;
-	uint32_t l1_size; /* XXX: save number of clusters instead ? */
-	uint64_t l1_table_offset;
-	uint64_t refcount_table_offset;
-	uint32_t refcount_table_clusters;
-	uint32_t nb_snapshots;
-	uint64_t snapshots_offset;
-} QCowHeader;
-
-typedef struct __attribute__((packed)) QCowSnapshotHeader {
-	/* header is 8 byte aligned */
-	uint64_t l1_table_offset;
-
-	uint32_t l1_size;
-	uint16_t id_str_size;
-	uint16_t name_size;
-
-	uint32_t date_sec;
-	uint32_t date_nsec;
-
-	uint64_t vm_clock_nsec;
-
-	uint32_t vm_state_size;
-	uint32_t extra_data_size; /* for extension */
-	/* extra data follows */
-	/* id_str follows */
-	/* name follows  */
-} QCowSnapshotHeader;
-
-#define L2_CACHE_SIZE 16
-
-typedef struct QCowSnapshot {
-	uint64_t l1_table_offset;
-	uint32_t l1_size;
-	char *id_str;
-	char *name;
-	uint32_t vm_state_size;
-	uint32_t date_sec;
-	uint32_t date_nsec;
-	uint64_t vm_clock_nsec;
-} QCowSnapshot;
-
-typedef struct BDRVQcowState {
-
-	/* blktap additions */
-	int fd;
-	int poll_pipe[2]; /* dummy fd for polling on */
-	char* name;
-	int encrypted;
-	char backing_file[1024];
-	struct disk_driver* backing_hd;
-
-	int64_t total_sectors;
-
-	tap_aio_context_t async;
-
-	/* Original qemu variables */
-	int cluster_bits;
-	int cluster_size;
-	int cluster_sectors;
-	int l2_bits;
-	int l2_size;
-	int l1_size;
-	int l1_vm_state_index;
-	int csize_shift;
-	int csize_mask;
-	uint64_t cluster_offset_mask;
-	uint64_t l1_table_offset;
-	uint64_t *l1_table;
-	uint64_t *l2_cache;
-	uint64_t l2_cache_offsets[L2_CACHE_SIZE];
-	uint32_t l2_cache_counts[L2_CACHE_SIZE];
-	uint8_t *cluster_cache;
-	uint8_t *cluster_data;
-	uint64_t cluster_cache_offset;
-
-	uint64_t *refcount_table;
-	uint64_t refcount_table_offset;
-	uint32_t refcount_table_size;
-	uint64_t refcount_block_cache_offset;
-	uint16_t *refcount_block_cache;
-	int64_t free_cluster_index;
-	int64_t free_byte_offset;
-
-	uint32_t crypt_method; /* current crypt method, 0 if no key yet */
-	uint32_t crypt_method_header;
-	AES_KEY aes_encrypt_key;
-	AES_KEY aes_decrypt_key;
-	uint64_t snapshots_offset;
-	int snapshots_size;
-	int nb_snapshots;
-	QCowSnapshot *snapshots;
-} BDRVQcowState;
-
-static int decompress_cluster(BDRVQcowState *s, uint64_t cluster_offset);
-static int qcow_read(struct disk_driver *bs, uint64_t sector_num,
-		uint8_t *buf, int nb_sectors);
-
-static int qcow_read_snapshots(struct disk_driver *bs);
-static void qcow_free_snapshots(struct disk_driver *bs);
-
-static int refcount_init(struct disk_driver *bs);
-static void refcount_close(struct disk_driver *bs);
-static int get_refcount(struct disk_driver *bs, int64_t cluster_index);
-static int update_cluster_refcount(struct disk_driver *bs,
-		int64_t cluster_index,
-		int addend);
-static void update_refcount(struct disk_driver *bs,
-		int64_t offset, int64_t length,
-		int addend);
-static int64_t alloc_clusters(struct disk_driver *bs, int64_t size);
-static int64_t alloc_bytes(struct disk_driver *bs, int size);
-static void free_clusters(struct disk_driver *bs,
-		int64_t offset, int64_t size);
-#ifdef DEBUG_ALLOC
-static void check_refcounts(struct disk_driver *bs);
-#endif
-
-static int qcow_sync_read(struct disk_driver *dd, uint64_t sector,
-		int nb_sectors, char *buf, td_callback_t cb,
-		int id, void *prv);
-
-/**
- * Read with byte offsets
- */
-static int bdrv_pread(int fd, int64_t offset, void *buf, int count)
-{
-	int ret;
-
-	if (lseek(fd, offset, SEEK_SET) == -1) {
-		DPRINTF("bdrv_pread failed seek (%#"PRIx64").\n", offset);
-		return -1;
-	}
-
-	ret =  read(fd, buf, count);
-	if (ret < 0) {
-		if (lseek(fd, 0, SEEK_END) >= offset) {
-			DPRINTF("bdrv_pread read failed (%#"PRIx64", END = %#"PRIx64").\n", 
-					offset, lseek(fd, 0, SEEK_END));
-			return -1;
-		}
-
-		/* Read beyond end of file. Reading zeros. */
-		memset(buf, 0, count);
-		ret = count;
-	} else if (ret < count) {
-		/* Read beyond end of file. Filling up with zeros. */
-		memset(buf + ret, 0, count - ret);
-		ret = count;
-	}
-	return ret;
-}
-
-/**
- * Write with byte offsets
- */
-static int bdrv_pwrite(int fd, int64_t offset, const void *buf, int count)
-{
-	if (lseek(fd, offset, SEEK_SET) == -1) {
-		DPRINTF("bdrv_pwrite failed seek (%#"PRIx64").\n", offset);
-		return -1;
-	}
-
-	return write(fd, buf, count);
-}
-
-
-/**
- * Read with sector offsets
- */
-static int bdrv_read(int fd, int64_t offset, void *buf, int count)
-{
-	return bdrv_pread(fd, 512 * offset, buf, 512 * count);
-}
-
-/**
- * Write with sector offsets
- */
-static int bdrv_write(int fd, int64_t offset, const void *buf, int count)
-{
-	return bdrv_pwrite(fd, 512 * offset, buf, count);
-}
-
-
-static int qcow_probe(const uint8_t *buf, int buf_size, const char *filename)
-{
-	const QCowHeader *cow_header = (const void *)buf;
-
-	if (buf_size >= sizeof(QCowHeader) &&
-		be32_to_cpu(cow_header->magic) == QCOW_MAGIC &&
-		be32_to_cpu(cow_header->version) == QCOW_VERSION)
-		return 100;
-	else
-		return 0;
-}
-
-static int qcow_open(struct disk_driver *bs, const char *filename, td_flag_t flags)
-{
-	BDRVQcowState *s = bs->private;
-	int len, i, shift, ret, max_aio_reqs;
-	QCowHeader header;
-
-	int fd, o_flags;
-	
-	o_flags = O_LARGEFILE | ((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-
-	DPRINTF("Opening %s\n", filename);
-	fd = open(filename, o_flags);
-	if (fd < 0) {
-		DPRINTF("Unable to open %s (%d)\n", filename, 0 - errno);
-		return -1;
-	}
-
-	s->fd = fd;
-	if (asprintf(&s->name,"%s", filename) == -1) {
-		close(fd);
-		return -1;
-	}
-
-	ret = read(fd, &header, sizeof(header));
-	if (ret != sizeof(header)) {
-		DPRINTF("  ret = %d, errno = %d\n", ret, errno);
-		goto fail;
-	}
-
-	be32_to_cpus(&header.magic);
-	be32_to_cpus(&header.version);
-	be64_to_cpus(&header.backing_file_offset);
-	be32_to_cpus(&header.backing_file_size);
-	be64_to_cpus(&header.size);
-	be32_to_cpus(&header.cluster_bits);
-	be32_to_cpus(&header.crypt_method);
-	be64_to_cpus(&header.l1_table_offset);
-	be32_to_cpus(&header.l1_size);
-	be64_to_cpus(&header.refcount_table_offset);
-	be32_to_cpus(&header.refcount_table_clusters);
-	be64_to_cpus(&header.snapshots_offset);
-	be32_to_cpus(&header.nb_snapshots);
-
-	if (header.magic != QCOW_MAGIC || header.version != QCOW_VERSION)
-		goto fail;
-
-	if (header.size <= 1 ||
-		header.cluster_bits < 9 ||
-		header.cluster_bits > 16)
-		goto fail;
-	
-	s->crypt_method = 0;
-	if (header.crypt_method > QCOW_CRYPT_AES)
-		goto fail;
-	s->crypt_method_header = header.crypt_method;
-	if (s->crypt_method_header)
-		s->encrypted = 1;
-	s->cluster_bits = header.cluster_bits;
-	s->cluster_size = 1 << s->cluster_bits;
-	s->cluster_sectors = 1 << (s->cluster_bits - 9);
-	s->l2_bits = s->cluster_bits - 3; /* L2 is always one cluster */
-	s->l2_size = 1 << s->l2_bits;
-	s->total_sectors = header.size / 512;
-	s->csize_shift = (62 - (s->cluster_bits - 8));
-	s->csize_mask = (1 << (s->cluster_bits - 8)) - 1;
-	s->cluster_offset_mask = (1LL << s->csize_shift) - 1;
-	s->refcount_table_offset = header.refcount_table_offset;
-	s->refcount_table_size =
-		header.refcount_table_clusters << (s->cluster_bits - 3);
-
-	s->snapshots_offset = header.snapshots_offset;
-	s->nb_snapshots = header.nb_snapshots;
-
-//	  DPRINTF("-- cluster_bits/size/sectors = %d/%d/%d\n",
-//		  s->cluster_bits, s->cluster_size, s->cluster_sectors);
-//	  DPRINTF("-- l2_bits/sizes = %d/%d\n",
-//		  s->l2_bits, s->l2_size);
-
-	/* Set sector size and number */
-	bs->td_state->sector_size = 512;
-	bs->td_state->size = header.size / 512;
-	bs->td_state->info = 0;
-
-	/* read the level 1 table */
-	s->l1_size = header.l1_size;
-	shift = s->cluster_bits + s->l2_bits;
-	s->l1_vm_state_index = (header.size + (1LL << shift) - 1) >> shift;
-	/* the L1 table must contain at least enough entries to put
-	   header.size bytes */
-	if (s->l1_size < s->l1_vm_state_index) {
-		DPRINTF("L1 table tooo small\n");
-		goto fail;
-	}
-	s->l1_table_offset = header.l1_table_offset;
-
-	s->l1_table = qemu_malloc(s->l1_size * sizeof(uint64_t));
-	if (!s->l1_table)
-		goto fail;
-
-
-	if (lseek(fd, s->l1_table_offset, SEEK_SET) == -1)
-		goto fail;
-
-	if (read(fd, s->l1_table, s->l1_size * sizeof(uint64_t)) !=
-			s->l1_size * sizeof(uint64_t)) {
-
-		DPRINTF("Could not read L1 table\n");
-		goto fail;
-	}
-
-	for(i = 0;i < s->l1_size; i++) {
-		be64_to_cpus(&s->l1_table[i]);
-	}
-	/* alloc L2 cache */
-	s->l2_cache = qemu_malloc(s->l2_size * L2_CACHE_SIZE * sizeof(uint64_t));
-	if (!s->l2_cache)
-		goto fail;
-	s->cluster_cache = qemu_malloc(s->cluster_size);
-	if (!s->cluster_cache)
-		goto fail;
-	/* one more sector for decompressed data alignment */
-	s->cluster_data = qemu_malloc(s->cluster_size + 512);
-	if (!s->cluster_data)
-		goto fail;
-	s->cluster_cache_offset = -1;
-
-	if (refcount_init(bs) < 0)
-		goto fail;
-		
-	/* read the backing file name */
-	s->backing_file[0] = '\0';
-	if (header.backing_file_offset != 0) {
-		len = header.backing_file_size;
-		if (len > 1023)
-			len = 1023;
-
-		if (lseek(fd, header.backing_file_offset, SEEK_SET) == -1) {
-			DPRINTF("Could not lseek to %#"PRIx64"\n", header.backing_file_offset);
-			goto fail;
-		}
-
-		if (read(fd, s->backing_file, len) != len) {
-			DPRINTF("Could not read %#x bytes from %#"PRIx64": %s\n",
-				len, header.backing_file_offset,
-				strerror(errno));
-			goto fail;
-		}
-
-		s->backing_file[len] = '\0';
-	}
-
-#if 0
-	s->backing_hd = NULL;
-	if (qcow_read_snapshots(bs) < 0) {
-		DPRINTF("Could not read backing files\n");
-		goto fail;
-	}
-#endif
-
-#ifdef DEBUG_ALLOC
-	check_refcounts(bs);
-#endif
-	
-	/* Initialize fds */
-	for(i = 0; i < MAX_IOFD; i++)
-		bs->io_fd[i] = 0;
-
-#ifdef USE_AIO
-	/* Initialize AIO */
-
-	/* A segment (i.e. a page) can span multiple clusters */
-	max_aio_reqs = ((getpagesize() / s->cluster_size) + 1) *
-		MAX_SEGMENTS_PER_REQ * MAX_REQUESTS;
-
-	if (tap_aio_init(&s->async, bs->td_state->size, max_aio_reqs)) {
-		DPRINTF("Unable to initialise AIO state\n");
-		tap_aio_free(&s->async);
-		goto fail;
-	}
-
-	bs->io_fd[0] = s->async.aio_ctx.pollfd; 
-#else	
-	/* Synchronous IO */
-	if (pipe(s->poll_pipe)) 
-		goto fail;
-
-	bs->io_fd[0] = s->poll_pipe[0];
-#endif
-
-	return 0;
-
- fail:
-	DPRINTF("qcow_open failed\n");
-
-#ifdef USE_AIO	
-	tap_aio_free(&s->async);
-#endif
-
-	qcow_free_snapshots(bs);
-	refcount_close(bs);
-	qemu_free(s->l1_table);
-	qemu_free(s->l2_cache);
-	qemu_free(s->cluster_cache);
-	qemu_free(s->cluster_data);
-	close(fd);
-	return -1;
-}
-
-static int qcow_set_key(struct disk_driver *bs, const char *key)
-{
-	BDRVQcowState *s = bs->private;
-	uint8_t keybuf[16];
-	int len, i;
-
-	memset(keybuf, 0, 16);
-	len = strlen(key);
-	if (len > 16)
-		len = 16;
-	/* XXX: we could compress the chars to 7 bits to increase
-	   entropy */
-	for(i = 0;i < len;i++) {
-		keybuf[i] = key[i];
-	}
-	s->crypt_method = s->crypt_method_header;
-
-	if (AES_set_encrypt_key(keybuf, 128, &s->aes_encrypt_key) != 0)
-		return -1;
-	if (AES_set_decrypt_key(keybuf, 128, &s->aes_decrypt_key) != 0)
-		return -1;
-#if 0
-	/* test */
-	{
-		uint8_t in[16];
-		uint8_t out[16];
-		uint8_t tmp[16];
-		for(i=0;i<16;i++)
-			in[i] = i;
-		AES_encrypt(in, tmp, &s->aes_encrypt_key);
-		AES_decrypt(tmp, out, &s->aes_decrypt_key);
-		for(i = 0; i < 16; i++)
-			printf(" %02x", tmp[i]);
-		printf("\n");
-		for(i = 0; i < 16; i++)
-			printf(" %02x", out[i]);
-		printf("\n");
-	}
-#endif
-	return 0;
-}
-
-/* The crypt function is compatible with the linux cryptoloop
-   algorithm for < 4 GB images. NOTE: out_buf == in_buf is
-   supported */
-static void encrypt_sectors(BDRVQcowState *s, int64_t sector_num,
-		uint8_t *out_buf, const uint8_t *in_buf,
-		int nb_sectors, int enc,
-		const AES_KEY *key)
-{
-	union {
-		uint64_t ll[2];
-		uint8_t b[16];
-	} ivec;
-	int i;
-
-	for(i = 0; i < nb_sectors; i++) {
-		ivec.ll[0] = cpu_to_le64(sector_num);
-		ivec.ll[1] = 0;
-		AES_cbc_encrypt(in_buf, out_buf, 512, key,
-						ivec.b, enc);
-		sector_num++;
-		in_buf += 512;
-		out_buf += 512;
-	}
-}
-
-static int copy_sectors(struct disk_driver *bs, uint64_t start_sect,
-		uint64_t cluster_offset, int n_start, int n_end)
-{
-	BDRVQcowState *s = bs->private;
-	int n, ret;
-	
-	n = n_end - n_start;
-	if (n <= 0)
-		return 0;
-
-	ret = qcow_read(bs, start_sect + n_start, s->cluster_data, n);
-
-	if (ret < 0)
-		return ret;
-	if (s->crypt_method) {
-		encrypt_sectors(s, start_sect + n_start,
-				s->cluster_data,
-				s->cluster_data, n, 1,
-				&s->aes_encrypt_key);
-	}
-
-
-	ret = bdrv_pwrite(s->fd, cluster_offset + 512*n_start, s->cluster_data, n*512);
-
-	if (ret < 0)
-		return ret;
-	return 0;
-}
-
-static void l2_cache_reset(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-
-	memset(s->l2_cache, 0, s->l2_size * L2_CACHE_SIZE * sizeof(uint64_t));
-	memset(s->l2_cache_offsets, 0, L2_CACHE_SIZE * sizeof(uint64_t));
-	memset(s->l2_cache_counts, 0, L2_CACHE_SIZE * sizeof(uint32_t));
-}
-
-static inline int l2_cache_new_entry(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	uint32_t min_count;
-	int min_index, i;
-
-	/* find a new entry in the least used one */
-	min_index = 0;
-	min_count = 0xffffffff;
-	for(i = 0; i < L2_CACHE_SIZE; i++) {
-		if (s->l2_cache_counts[i] < min_count) {
-			min_count = s->l2_cache_counts[i];
-			min_index = i;
-		}
-	}
-	return min_index;
-}
-
-static int64_t align_offset(int64_t offset, int n)
-{
-	offset = (offset + n - 1) & ~(n - 1);
-	return offset;
-}
-
-static int grow_l1_table(struct disk_driver *bs, int min_size)
-{
-	BDRVQcowState *s = bs->private;
-	int new_l1_size, new_l1_size2, ret, i;
-	uint64_t *new_l1_table;
-	uint64_t new_l1_table_offset;
-	uint64_t data64;
-	uint32_t data32;
-
-	new_l1_size = s->l1_size;
-	if (min_size <= new_l1_size)
-		return 0;
-	while (min_size > new_l1_size) {
-		new_l1_size = (new_l1_size * 3 + 1) / 2;
-	}
-
-#ifdef DEBUG_ALLOC2
-	DPRINTF("grow l1_table from %d to %d\n", s->l1_size, new_l1_size);
-#endif
-
-	new_l1_size2 = sizeof(uint64_t) * new_l1_size;
-	new_l1_table = qemu_mallocz(new_l1_size2);
-	if (!new_l1_table)
-		return -ENOMEM;
-	memcpy(new_l1_table, s->l1_table, s->l1_size * sizeof(uint64_t));
-
-	/* write new table (align to cluster) */
-	new_l1_table_offset = alloc_clusters(bs, new_l1_size2);
-
-	for(i = 0; i < s->l1_size; i++)
-		new_l1_table[i] = cpu_to_be64(new_l1_table[i]);
-
-
-	if (lseek(s->fd, new_l1_table_offset, SEEK_SET) == -1)
-		goto fail;
-
-	ret = write(s->fd, new_l1_table, new_l1_size2);
-	if (ret != new_l1_size2)
-		goto fail;
-
-
-	for(i = 0; i < s->l1_size; i++)
-		new_l1_table[i] = be64_to_cpu(new_l1_table[i]);
-
-	/* set new table */
-	data64 = cpu_to_be64(new_l1_table_offset);
-
-	if (lseek(s->fd, offsetof(QCowHeader, l1_table_offset), SEEK_SET) == -1)
-		goto fail;
-
-	if (write(s->fd, &data64, sizeof(data64)) != sizeof(data64))
-		goto fail;
-
-	data32 = cpu_to_be32(new_l1_size);
-
-	if (bdrv_pwrite(s->fd, offsetof(QCowHeader, l1_size),
-					&data32, sizeof(data32)) != sizeof(data32))
-		goto fail;
-	qemu_free(s->l1_table);
-	free_clusters(bs, s->l1_table_offset, s->l1_size * sizeof(uint64_t));
-	s->l1_table_offset = new_l1_table_offset;
-	s->l1_table = new_l1_table;
-	s->l1_size = new_l1_size;
-	return 0;
- fail:
-	qemu_free(s->l1_table);
-	return -EIO;
-}
-
-/* 'allocate' is:
- *
- * 0 not to allocate.
- *
- * 1 to allocate a normal cluster (for sector indexes 'n_start' to
- * 'n_end')
- *
- * 2 to allocate a compressed cluster of size
- * 'compressed_size'. 'compressed_size' must be > 0 and <
- * cluster_size
- *
- * return 0 if not allocated.
- */
-static uint64_t get_cluster_offset(struct disk_driver *bs,
-		uint64_t offset, int allocate,
-		int compressed_size,
-		int n_start, int n_end)
-{
-	BDRVQcowState *s = bs->private;
-	int min_index, i, j, l1_index, l2_index, ret;
-	uint64_t l2_offset, *l2_table, cluster_offset, tmp, old_l2_offset;
-
-	l1_index = offset >> (s->l2_bits + s->cluster_bits);
-	if (l1_index >= s->l1_size) {
-		/* outside l1 table is allowed: we grow the table if needed */
-		if (!allocate)
-			return 0;
-
-		if (grow_l1_table(bs, l1_index + 1) < 0) {
-			DPRINTF("Could not grow L1 table");
-			return 0;
-		}
-	}
-
-	l2_offset = s->l1_table[l1_index];
-	if (!l2_offset) {
-		if (!allocate)
-			return 0;
-
-	l2_allocate:
-		old_l2_offset = l2_offset;
-		/* allocate a new l2 entry */
-		l2_offset = alloc_clusters(bs, s->l2_size * sizeof(uint64_t));
-		
-		/* update the L1 entry */
-		s->l1_table[l1_index] = l2_offset | QCOW_OFLAG_COPIED;
-		tmp = cpu_to_be64(l2_offset | QCOW_OFLAG_COPIED);
-		if (bdrv_pwrite(s->fd, s->l1_table_offset + l1_index * sizeof(tmp),
-						&tmp, sizeof(tmp)) != sizeof(tmp))
-			return 0;
-		min_index = l2_cache_new_entry(bs);
-		l2_table = s->l2_cache + (min_index << s->l2_bits);
-
-		if (old_l2_offset == 0) {
-			memset(l2_table, 0, s->l2_size * sizeof(uint64_t));
-		} else {
-			if (bdrv_pread(s->fd, old_l2_offset,
-						   l2_table, s->l2_size * sizeof(uint64_t)) !=
-				s->l2_size * sizeof(uint64_t))
-				return 0;
-		}
-		if (bdrv_pwrite(s->fd, l2_offset,
-						l2_table, s->l2_size * sizeof(uint64_t)) !=
-			s->l2_size * sizeof(uint64_t))
-			return 0;
-	} else {
-		if (!(l2_offset & QCOW_OFLAG_COPIED)) {
-			if (allocate) {
-				free_clusters(bs, l2_offset, s->l2_size * sizeof(uint64_t));
-				goto l2_allocate;
-			}
-		} else {
-			l2_offset &= ~QCOW_OFLAG_COPIED;
-		}
-		for(i = 0; i < L2_CACHE_SIZE; i++) {
-			if (l2_offset == s->l2_cache_offsets[i]) {
-				/* increment the hit count */
-				if (++s->l2_cache_counts[i] == 0xffffffff) {
-					for(j = 0; j < L2_CACHE_SIZE; j++) {
-						s->l2_cache_counts[j] >>= 1;
-					}
-				}
-				l2_table = s->l2_cache + (i << s->l2_bits);
-				goto found;
-			}
-		}
-		/* not found: load a new entry in the least used one */
-		min_index = l2_cache_new_entry(bs);
-		l2_table = s->l2_cache + (min_index << s->l2_bits);
-
-		if (bdrv_pread(s->fd, l2_offset, l2_table, s->l2_size * sizeof(uint64_t)) !=
-			s->l2_size * sizeof(uint64_t))
-		{
-			DPRINTF("Could not read L2 table");
-			return 0;
-		}
-	}
-	s->l2_cache_offsets[min_index] = l2_offset;
-	s->l2_cache_counts[min_index] = 1;
-found:
-	l2_index = (offset >> s->cluster_bits) & (s->l2_size - 1);
-
-	cluster_offset = be64_to_cpu(l2_table[l2_index]);
-	if (!cluster_offset) {
-		if (!allocate) {
-			return cluster_offset;
-		}
-	} else if (!(cluster_offset & QCOW_OFLAG_COPIED)) {
-		if (!allocate)
-			return cluster_offset;
-		/* free the cluster */
-		if (cluster_offset & QCOW_OFLAG_COMPRESSED) {
-			int nb_csectors;
-			nb_csectors = ((cluster_offset >> s->csize_shift) &
-					s->csize_mask) + 1;
-			free_clusters(bs, (cluster_offset & s->cluster_offset_mask) & ~511,
-					nb_csectors * 512);
-		} else {
-			free_clusters(bs, cluster_offset, s->cluster_size);
-		}
-	} else {
-		cluster_offset &= ~QCOW_OFLAG_COPIED;
-		return cluster_offset;
-	}
-	if (allocate == 1) {
-		/* allocate a new cluster */
-		cluster_offset = alloc_clusters(bs, s->cluster_size);
-
-		/* we must initialize the cluster content which won't be
-		   written */
-		if ((n_end - n_start) < s->cluster_sectors) {
-			uint64_t start_sect;
-
-			start_sect = (offset & ~(s->cluster_size - 1)) >> 9;
-			ret = copy_sectors(bs, start_sect,
-					cluster_offset, 0, n_start);
-			if (ret < 0)
-				return 0;
-			ret = copy_sectors(bs, start_sect,
-					cluster_offset, n_end, s->cluster_sectors);
-			if (ret < 0)
-				return 0;
-		}
-		tmp = cpu_to_be64(cluster_offset | QCOW_OFLAG_COPIED);
-	} else {
-		int nb_csectors;
-		cluster_offset = alloc_bytes(bs, compressed_size);
-		nb_csectors = ((cluster_offset + compressed_size - 1) >> 9) -
-			(cluster_offset >> 9);
-		cluster_offset |= QCOW_OFLAG_COMPRESSED |
-			((uint64_t)nb_csectors << s->csize_shift);
-		/* compressed clusters never have the copied flag */
-		tmp = cpu_to_be64(cluster_offset);
-	}
-	/* update L2 table */
-	l2_table[l2_index] = tmp;
-
-	if (bdrv_pwrite(s->fd, l2_offset + l2_index * sizeof(tmp), &tmp, sizeof(tmp)) != sizeof(tmp))
-		return 0;
-	return cluster_offset;
-}
-
-static int qcow_is_allocated(struct disk_driver *bs, int64_t sector_num,
-		int nb_sectors, int *pnum)
-{
-	BDRVQcowState *s = bs->private;
-	int index_in_cluster, n;
-	uint64_t cluster_offset;
-
-	cluster_offset = get_cluster_offset(bs, sector_num << 9, 0, 0, 0, 0);
-	index_in_cluster = sector_num & (s->cluster_sectors - 1);
-	n = s->cluster_sectors - index_in_cluster;
-	if (n > nb_sectors)
-		n = nb_sectors;
-	*pnum = n;
-	return (cluster_offset != 0);
-}
-
-static int decompress_buffer(uint8_t *out_buf, int out_buf_size,
-		const uint8_t *buf, int buf_size)
-{
-	z_stream strm1, *strm = &strm1;
-	int ret, out_len;
-
-	memset(strm, 0, sizeof(*strm));
-
-	strm->next_in = (uint8_t *)buf;
-	strm->avail_in = buf_size;
-	strm->next_out = out_buf;
-	strm->avail_out = out_buf_size;
-
-	ret = inflateInit2(strm, -12);
-	if (ret != Z_OK)
-		return -1;
-	ret = inflate(strm, Z_FINISH);
-	out_len = strm->next_out - out_buf;
-	if ((ret != Z_STREAM_END && ret != Z_BUF_ERROR) ||
-		out_len != out_buf_size) {
-		inflateEnd(strm);
-		return -1;
-	}
-	inflateEnd(strm);
-	return 0;
-}
-
-static int decompress_cluster(BDRVQcowState *s, uint64_t cluster_offset)
-{
-	int ret, csize, nb_csectors, sector_offset;
-	uint64_t coffset;
-
-	coffset = cluster_offset & s->cluster_offset_mask;
-	if (s->cluster_cache_offset != coffset) {
-		nb_csectors = ((cluster_offset >> s->csize_shift) & s->csize_mask) + 1;
-		sector_offset = coffset & 511;
-		csize = nb_csectors * 512 - sector_offset;
-		ret = bdrv_read(s->fd, coffset >> 9, s->cluster_data, nb_csectors);
-		if (ret < 0) {
-			return -1;
-		}
-		if (decompress_buffer(s->cluster_cache, s->cluster_size,
-							  s->cluster_data + sector_offset, csize) < 0) {
-			return -1;
-		}
-		s->cluster_cache_offset = coffset;
-	}
-	return 0;
-}
-
-/* handle reading after the end of the backing file */
-static int backing_read1(struct disk_driver *bs,
-		int64_t sector_num, uint8_t *buf, int nb_sectors)
-{
-	int n1;
-	BDRVQcowState* s = bs->private;
-
-	if ((sector_num + nb_sectors) <= s->total_sectors)
-		return nb_sectors;
-	if (sector_num >= s->total_sectors)
-		n1 = 0;
-	else
-		n1 = s->total_sectors - sector_num;
-	memset(buf + n1 * 512, 0, 512 * (nb_sectors - n1));
-	return n1;
-}
-
-/**
- * Reads a number of sectors from the image (synchronous)
- */
-static int qcow_read(struct disk_driver *bs, uint64_t sector_num,
-		uint8_t *buf, int nb_sectors)
-{
-	BDRVQcowState *s = bs->private;
-	int ret, index_in_cluster, n, n1;
-	uint64_t cluster_offset;
-
-	while (nb_sectors > 0) {
-		cluster_offset = get_cluster_offset(bs, sector_num << 9, 0, 0, 0, 0);
-		index_in_cluster = sector_num & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-		if (!cluster_offset) {
-
-			if (bs->next) {
-
-				/* Read from backing file */
-				struct disk_driver *parent = bs->next;
-
-				ret = qcow_sync_read(parent, sector_num, 
-						nb_sectors, (char*) buf, NULL, 0, NULL);
-
-#if 0		
-				/* read from the base image */
-				n1 = backing_read1(s->backing_hd, sector_num, buf, n);
-				if (n1 > 0) {
-					ret = bdrv_read(((BDRVQcowState*) s->backing_hd)->fd, sector_num, buf, n1);
-					if (ret < 0) {
-						DPRINTF("read from backing file failed: ret = %d; errno = %d\n", ret, errno);
-						return -1;
-					}
-				}
-#endif
-			} else {
-				memset(buf, 0, 512 * n);
-			}
-		} else if (cluster_offset & QCOW_OFLAG_COMPRESSED) {
-			if (decompress_cluster(s, cluster_offset) < 0) {
-				DPRINTF("read/decompression failed: errno = %d\n", errno);
-				return -1;
-			}
-			memcpy(buf, s->cluster_cache + index_in_cluster * 512, 512 * n);
-		} else {
-			ret = bdrv_pread(s->fd, cluster_offset + index_in_cluster * 512, buf, n * 512);
-			if (ret != n * 512) {
-				DPRINTF("read failed: ret = %d != n * 512 = %d; errno = %d\n", ret, n * 512, errno);
-				DPRINTF("  cluster_offset = %"PRIx64", index = %d; sector_num = %"PRId64"", cluster_offset, index_in_cluster, sector_num);
-				return -1;
-			}
-
-			if (s->crypt_method) {
-				encrypt_sectors(s, sector_num, buf, buf, n, 0,
-						&s->aes_decrypt_key);
-			}
-		}
-		nb_sectors -= n;
-		sector_num += n;
-		buf += n * 512;
-	}
-	return 0;
-}
-
-/**
- * Writes a number of sectors to the image (synchronous)
- */
-static int qcow_write(struct disk_driver *bs, uint64_t sector_num,
-		const uint8_t *buf, int nb_sectors)
-{
-	BDRVQcowState *s = bs->private;
-	int ret, index_in_cluster, n;
-	uint64_t cluster_offset;
-
-	while (nb_sectors > 0) {
-		index_in_cluster = sector_num & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-		cluster_offset = get_cluster_offset(bs, sector_num << 9, 1, 0,
-											index_in_cluster,
-											index_in_cluster + n);
-		if (!cluster_offset) {
-			DPRINTF("qcow_write: cluster_offset == 0\n");
-			DPRINTF("  index = %d; sector_num = %"PRId64"\n", 
-				index_in_cluster, sector_num);
-			return -1;
-		}
-
-		if (s->crypt_method) {
-			encrypt_sectors(s, sector_num, s->cluster_data, buf, n, 1,
-					&s->aes_encrypt_key);
-			ret = bdrv_pwrite(s->fd, cluster_offset + index_in_cluster * 512,
-					s->cluster_data, n * 512);
-		} else {
-			ret = bdrv_pwrite(s->fd, cluster_offset + index_in_cluster * 512, buf, n * 512);
-		}
-		if (ret != n * 512) {
-			DPRINTF("write failed: ret = %d != n * 512 = %d; errno = %d\n", ret, n * 512, errno);
-			DPRINTF("  cluster_offset = %"PRIx64", index = %d; sector_num = %"PRId64"\n", cluster_offset, index_in_cluster, sector_num);
-			return -1;
-		}
-
-		nb_sectors -= n;
-		sector_num += n;
-		buf += n * 512;
-	}
-	s->cluster_cache_offset = -1; /* disable compressed cache */
-	return 0;
-}
-
-
-
-#ifdef USE_AIO
-
-/*
- * QCOW2 specific AIO functions
- */
-
-static int qcow_queue_read(struct disk_driver *bs, uint64_t sector,
-		int nb_sectors, char *buf, td_callback_t cb,
-		int id, void *private)
-{
-	BDRVQcowState *s = bs->private;
-	int i, index_in_cluster, n, ret;
-	int rsp = 0;
-	uint64_t cluster_offset;
-
-	/*Check we can get a lock*/
-	for (i = 0; i < nb_sectors; i++) 
-		if (!tap_aio_can_lock(&s->async, sector + i)) 
-			return cb(bs, -EBUSY, sector, nb_sectors, id, private);
-
-	while (nb_sectors > 0) {
-		
-		cluster_offset = get_cluster_offset(bs, sector << 9, 0, 0, 0, 0);
-				
-		index_in_cluster = sector & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-
-		if (s->async.iocb_free_count == 0 || !tap_aio_lock(&s->async, sector)) 
-			return cb(bs, -EBUSY, sector, nb_sectors, id, private);
-
-		if (!cluster_offset) {
-
-			/* The requested sector is not allocated */
-			tap_aio_unlock(&s->async, sector);
-			ret = cb(bs, BLK_NOT_ALLOCATED, 
-					sector, n, id, private);
-			if (ret == -EBUSY) {
-				/* mark remainder of request
-				 * as busy and try again later */
-				return cb(bs, -EBUSY, sector + n,
-						nb_sectors - n, id, private);
-			} else {
-				rsp += ret;
-			}
-
-		} else if (cluster_offset & QCOW_OFLAG_COMPRESSED) {
-
-			/* sync read for compressed clusters */
-			tap_aio_unlock(&s->async, sector);
-			if (decompress_cluster(s, cluster_offset) < 0) {
-				rsp += cb(bs, -EIO, sector, nb_sectors, id, private);
-				goto done;
-			}
-			memcpy(buf, s->cluster_cache + index_in_cluster * 512, 
-					512 * n);
-			rsp += cb(bs, 0, sector, n, id, private);
-
-		} else {
-
-			/* async read */
-			tap_aio_read(&s->async, s->fd, n * 512, 
-					(cluster_offset + index_in_cluster * 512),
-					buf, cb, id, sector, private);
-		}
-
-		/* Prepare for next sector to read */
-		nb_sectors -= n;
-		sector += n;
-		buf += n * 512;
-	}
-
-done:
-	return rsp;
-
-}
-
-static int qcow_queue_write(struct disk_driver *bs, uint64_t sector,
-		int nb_sectors, char *buf, td_callback_t cb,
-		int id, void *private)
-{
-	BDRVQcowState *s = bs->private;
-	int i, n, index_in_cluster;
-	uint64_t cluster_offset;
-	const uint8_t *src_buf;
-		
-	
-	/*Check we can get a lock*/
-	for (i = 0; i < nb_sectors; i++) 
-		if (!tap_aio_can_lock(&s->async, sector + i)) 
-			return cb(bs, -EBUSY, sector, nb_sectors, id, private);
-
-
-	while (nb_sectors > 0) {
-				
-		index_in_cluster = sector & (s->cluster_sectors - 1);
-		n = s->cluster_sectors - index_in_cluster;
-		if (n > nb_sectors)
-			n = nb_sectors;
-
-		if (s->async.iocb_free_count == 0 || !tap_aio_lock(&s->async, sector))
-			return cb(bs, -EBUSY, sector, nb_sectors, id, private);
-
-
-		cluster_offset = get_cluster_offset(bs, sector << 9, 1, 0,
-				index_in_cluster, 
-				index_in_cluster+n);
-
-		if (!cluster_offset) {
-			DPRINTF("Ooops, no write cluster offset!\n");
-			tap_aio_unlock(&s->async, sector);
-			return cb(bs, -EIO, sector, nb_sectors, id, private);
-		}
-
-
-		// TODO Encryption
-
-		tap_aio_write(&s->async, s->fd, n * 512, 
-				(cluster_offset + index_in_cluster*512),
-				buf, cb, id, sector, private);
-
-		/* Prepare for next sector to write */
-		nb_sectors -= n;
-		sector += n;
-		buf += n * 512;
-	}
-
-		
-	s->cluster_cache_offset = -1; /* disable compressed cache */
-
-	return 0;
-}
-
-
-#endif /* USE_AIO */
-
-
-static int qcow_close(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	
-#ifdef USE_AIO	
-	io_destroy(s->async.aio_ctx.aio_ctx);
-	tap_aio_free(&s->async);
-#else		
-	close(s->poll_pipe[0]);
-	close(s->poll_pipe[1]);
-#endif		
-
-	qemu_free(s->l1_table);
-	qemu_free(s->l2_cache);
-	qemu_free(s->cluster_cache);
-	qemu_free(s->cluster_data);
-	refcount_close(bs);
-	return close(s->fd);
-}
-
-/* XXX: use std qcow open function ? */
-typedef struct QCowCreateState {
-	int cluster_size;
-	int cluster_bits;
-	uint16_t *refcount_block;
-	uint64_t *refcount_table;
-	int64_t l1_table_offset;
-	int64_t refcount_table_offset;
-	int64_t refcount_block_offset;
-} QCowCreateState;
-
-static void create_refcount_update(QCowCreateState *s,
-		int64_t offset, int64_t size)
-{
-	int refcount;
-	int64_t start, last, cluster_offset;
-	uint16_t *p;
-
-	start = offset & ~(s->cluster_size - 1);
-	last = (offset + size - 1)	& ~(s->cluster_size - 1);
-	for(cluster_offset = start; cluster_offset <= last;
-		cluster_offset += s->cluster_size) {
-		p = &s->refcount_block[cluster_offset >> s->cluster_bits];
-		refcount = be16_to_cpu(*p);
-		refcount++;
-		*p = cpu_to_be16(refcount);
-	}
-}
-
-static int qcow_submit(struct disk_driver *bs)
-{
-	struct BDRVQcowState *s = (struct BDRVQcowState*) bs->private;
-
-	fsync(s->fd);
-	return tap_aio_submit(&s->async);
-}
-
-
-/*********************************************************/
-/* snapshot support */
-
-
-static void qcow_free_snapshots(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	int i;
-
-	for(i = 0; i < s->nb_snapshots; i++) {
-		qemu_free(s->snapshots[i].name);
-		qemu_free(s->snapshots[i].id_str);
-	}
-	qemu_free(s->snapshots);
-	s->snapshots = NULL;
-	s->nb_snapshots = 0;
-}
-
-static int qcow_read_snapshots(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	QCowSnapshotHeader h;
-	QCowSnapshot *sn;
-	int i, id_str_size, name_size;
-	int64_t offset;
-	uint32_t extra_data_size;
-
-	offset = s->snapshots_offset;
-	s->snapshots = qemu_mallocz(s->nb_snapshots * sizeof(QCowSnapshot));
-	if (!s->snapshots)
-		goto fail;
-	for(i = 0; i < s->nb_snapshots; i++) {
-		offset = align_offset(offset, 8);
-		if (bdrv_pread(s->fd, offset, &h, sizeof(h)) != sizeof(h))
-			goto fail;
-		offset += sizeof(h);
-		sn = s->snapshots + i;
-		sn->l1_table_offset = be64_to_cpu(h.l1_table_offset);
-		sn->l1_size = be32_to_cpu(h.l1_size);
-		sn->vm_state_size = be32_to_cpu(h.vm_state_size);
-		sn->date_sec = be32_to_cpu(h.date_sec);
-		sn->date_nsec = be32_to_cpu(h.date_nsec);
-		sn->vm_clock_nsec = be64_to_cpu(h.vm_clock_nsec);
-		extra_data_size = be32_to_cpu(h.extra_data_size);
-
-		id_str_size = be16_to_cpu(h.id_str_size);
-		name_size = be16_to_cpu(h.name_size);
-
-		offset += extra_data_size;
-
-		sn->id_str = qemu_malloc(id_str_size + 1);
-		if (!sn->id_str)
-			goto fail;
-		if (bdrv_pread(s->fd, offset, sn->id_str, id_str_size) != id_str_size)
-			goto fail;
-		offset += id_str_size;
-		sn->id_str[id_str_size] = '\0';
-
-		sn->name = qemu_malloc(name_size + 1);
-		if (!sn->name)
-			goto fail;
-		if (bdrv_pread(s->fd, offset, sn->name, name_size) != name_size)
-			goto fail;
-		offset += name_size;
-		sn->name[name_size] = '\0';
-	}
-	s->snapshots_size = offset - s->snapshots_offset;
-	return 0;
-fail:
-	qcow_free_snapshots(bs);
-	return -1;
-}
-
-
-/*********************************************************/
-/* refcount handling */
-
-static int refcount_init(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	int ret, refcount_table_size2, i;
-
-	s->refcount_block_cache = qemu_malloc(s->cluster_size);
-	if (!s->refcount_block_cache)
-		goto fail;
-	refcount_table_size2 = s->refcount_table_size * sizeof(uint64_t);
-	s->refcount_table = qemu_malloc(refcount_table_size2);
-	if (!s->refcount_table)
-		goto fail;
-	if (s->refcount_table_size > 0) {
-		ret = bdrv_pread(s->fd, s->refcount_table_offset,
-				s->refcount_table, refcount_table_size2);
-		if (ret != refcount_table_size2)
-			goto fail;
-		for(i = 0; i < s->refcount_table_size; i++)
-			be64_to_cpus(&s->refcount_table[i]);
-	}
-	return 0;
- fail:
-	return -ENOMEM;
-}
-
-static void refcount_close(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	qemu_free(s->refcount_block_cache);
-	qemu_free(s->refcount_table);
-}
-
-
-static int load_refcount_block(struct disk_driver *bs,
-		int64_t refcount_block_offset)
-{
-	BDRVQcowState *s = bs->private;
-	int ret;
-	ret = bdrv_pread(s->fd, refcount_block_offset, s->refcount_block_cache,
-			s->cluster_size);
-	if (ret != s->cluster_size)
-		return -EIO;
-	s->refcount_block_cache_offset = refcount_block_offset;
-	return 0;
-}
-
-static int get_refcount(struct disk_driver *bs, int64_t cluster_index)
-{
-	BDRVQcowState *s = bs->private;
-	int refcount_table_index, block_index;
-	int64_t refcount_block_offset;
-
-	refcount_table_index = cluster_index >> (s->cluster_bits - REFCOUNT_SHIFT);
-	if (refcount_table_index >= s->refcount_table_size)
-		return 0;
-	refcount_block_offset = s->refcount_table[refcount_table_index];
-	if (!refcount_block_offset)
-		return 0;
-	if (refcount_block_offset != s->refcount_block_cache_offset) {
-		/* better than nothing: return allocated if read error */
-		if (load_refcount_block(bs, refcount_block_offset) < 0)
-			return 1;
-	}
-	block_index = cluster_index &
-		((1 << (s->cluster_bits - REFCOUNT_SHIFT)) - 1);
-	return be16_to_cpu(s->refcount_block_cache[block_index]);
-}
-
-/* return < 0 if error */
-static int64_t alloc_clusters_noref(struct disk_driver *bs, int64_t size)
-{
-	BDRVQcowState *s = bs->private;
-	int i, nb_clusters;
-
-	nb_clusters = (size + s->cluster_size - 1) >> s->cluster_bits;
-	for(;;) {
-		if (get_refcount(bs, s->free_cluster_index) == 0) {
-			s->free_cluster_index++;
-			for(i = 1; i < nb_clusters; i++) {
-				if (get_refcount(bs, s->free_cluster_index) != 0)
-					goto not_found;
-				s->free_cluster_index++;
-			}
-
-#ifdef DEBUG_ALLOC2
-			DPRINTF("alloc_clusters: size=%ld -> %ld\n",
-				   size,
-				   (s->free_cluster_index - nb_clusters) << s->cluster_bits);
-#endif
-
-			return (s->free_cluster_index - nb_clusters) << s->cluster_bits;
-		} else {
-		not_found:
-			s->free_cluster_index++;
-		}
-	}
-}
-
-static int64_t alloc_clusters(struct disk_driver *bs, int64_t size)
-{
-	int64_t offset;
-
-	offset = alloc_clusters_noref(bs, size);
-	update_refcount(bs, offset, size, 1);
-	return offset;
-}
-
-/* only used to allocate compressed sectors. We try to allocate
-   contiguous sectors. size must be <= cluster_size */
-static int64_t alloc_bytes(struct disk_driver *bs, int size)
-{
-	BDRVQcowState *s = bs->private;
-	int64_t offset, cluster_offset;
-	int free_in_cluster;
-
-	assert(size > 0 && size <= s->cluster_size);
-	if (s->free_byte_offset == 0) {
-		s->free_byte_offset = alloc_clusters(bs, s->cluster_size);
-	}
-redo:
-	free_in_cluster = s->cluster_size -
-		(s->free_byte_offset & (s->cluster_size - 1));
-	if (size <= free_in_cluster) {
-		/* enough space in current cluster */
-		offset = s->free_byte_offset;
-		s->free_byte_offset += size;
-		free_in_cluster -= size;
-		if (free_in_cluster == 0)
-			s->free_byte_offset = 0;
-		if ((offset & (s->cluster_size - 1)) != 0)
-			update_cluster_refcount(bs, offset >> s->cluster_bits, 1);
-	} else {
-		offset = alloc_clusters(bs, s->cluster_size);
-		cluster_offset = s->free_byte_offset & ~(s->cluster_size - 1);
-		if ((cluster_offset + s->cluster_size) == offset) {
-			/* we are lucky: contiguous data */
-			offset = s->free_byte_offset;
-			update_cluster_refcount(bs, offset >> s->cluster_bits, 1);
-			s->free_byte_offset += size;
-		} else {
-			s->free_byte_offset = offset;
-			goto redo;
-		}
-	}
-	return offset;
-}
-
-static void free_clusters(struct disk_driver *bs,
-		int64_t offset, int64_t size)
-{
-	update_refcount(bs, offset, size, -1);
-}
-
-static int grow_refcount_table(struct disk_driver *bs, int min_size)
-{
-	BDRVQcowState *s = bs->private;
-	int new_table_size, new_table_size2, refcount_table_clusters, i, ret;
-	uint64_t *new_table;
-	int64_t table_offset;
-	uint64_t data64;
-	uint32_t data32;
-	int old_table_size;
-	int64_t old_table_offset;
-
-	if (min_size <= s->refcount_table_size)
-		return 0;
-	
-	/* compute new table size */
-	refcount_table_clusters = s->refcount_table_size >> (s->cluster_bits - 3);
-	for(;;) {
-		if (refcount_table_clusters == 0) {
-			refcount_table_clusters = 1;
-		} else {
-			refcount_table_clusters = (refcount_table_clusters * 3 + 1) / 2;
-		}
-		new_table_size = refcount_table_clusters << (s->cluster_bits - 3);
-		if (min_size <= new_table_size)
-			break;
-	}
-
-#ifdef DEBUG_ALLOC2
-	printf("grow_refcount_table from %d to %d\n",
-		   s->refcount_table_size,
-		   new_table_size);
-#endif
-	new_table_size2 = new_table_size * sizeof(uint64_t);
-	new_table = qemu_mallocz(new_table_size2);
-	if (!new_table)
-		return -ENOMEM;
-	memcpy(new_table, s->refcount_table,
-		   s->refcount_table_size * sizeof(uint64_t));
-	for(i = 0; i < s->refcount_table_size; i++)
-		cpu_to_be64s(&new_table[i]);
-	/* Note: we cannot update the refcount now to avoid recursion */
-	table_offset = alloc_clusters_noref(bs, new_table_size2);
-	ret = bdrv_pwrite(s->fd, table_offset, new_table, new_table_size2);
-	if (ret != new_table_size2)
-		goto fail;
-	for(i = 0; i < s->refcount_table_size; i++)
-		be64_to_cpus(&new_table[i]);
-
-	data64 = cpu_to_be64(table_offset);
-	if (bdrv_pwrite(s->fd, offsetof(QCowHeader, refcount_table_offset),
-					&data64, sizeof(data64)) != sizeof(data64))
-		goto fail;
-	data32 = cpu_to_be32(refcount_table_clusters);
-	if (bdrv_pwrite(s->fd, offsetof(QCowHeader, refcount_table_clusters),
-					&data32, sizeof(data32)) != sizeof(data32))
-		goto fail;
-	qemu_free(s->refcount_table);
-	old_table_offset = s->refcount_table_offset;
-	old_table_size = s->refcount_table_size;
-	s->refcount_table = new_table;
-	s->refcount_table_size = new_table_size;
-	s->refcount_table_offset = table_offset;
-
-	update_refcount(bs, table_offset, new_table_size2, 1);
-	free_clusters(bs, old_table_offset, old_table_size * sizeof(uint64_t));
-	return 0;
- fail:
-	free_clusters(bs, table_offset, new_table_size2);
-	qemu_free(new_table);
-	return -EIO;
-}
-
-/* addend must be 1 or -1 */
-/* XXX: cache several refcount block clusters ? */
-static int update_cluster_refcount(struct disk_driver *bs,
-		int64_t cluster_index,
-		int addend)
-{
-	BDRVQcowState *s = bs->private;
-	int64_t offset, refcount_block_offset;
-	int ret, refcount_table_index, block_index, refcount;
-	uint64_t data64;
-
-	refcount_table_index = cluster_index >> (s->cluster_bits - REFCOUNT_SHIFT);
-	if (refcount_table_index >= s->refcount_table_size) {
-		if (addend < 0)
-			return -EINVAL;
-		ret = grow_refcount_table(bs, refcount_table_index + 1);
-		if (ret < 0)
-			return ret;
-	}
-	refcount_block_offset = s->refcount_table[refcount_table_index];
-	if (!refcount_block_offset) {
-		if (addend < 0)
-			return -EINVAL;
-		/* create a new refcount block */
-		/* Note: we cannot update the refcount now to avoid recursion */
-		offset = alloc_clusters_noref(bs, s->cluster_size);
-		memset(s->refcount_block_cache, 0, s->cluster_size);
-		ret = bdrv_pwrite(s->fd, offset, s->refcount_block_cache, s->cluster_size);
-		if (ret != s->cluster_size)
-			return -EINVAL;
-		s->refcount_table[refcount_table_index] = offset;
-		data64 = cpu_to_be64(offset);
-		ret = bdrv_pwrite(s->fd, s->refcount_table_offset +
-						  refcount_table_index * sizeof(uint64_t),
-						  &data64, sizeof(data64));
-		if (ret != sizeof(data64))
-			return -EINVAL;
-
-		refcount_block_offset = offset;
-		s->refcount_block_cache_offset = offset;
-		update_refcount(bs, offset, s->cluster_size, 1);
-	} else {
-		if (refcount_block_offset != s->refcount_block_cache_offset) {
-			if (load_refcount_block(bs, refcount_block_offset) < 0)
-				return -EIO;
-		}
-	}
-	/* we can update the count and save it */
-	block_index = cluster_index &
-		((1 << (s->cluster_bits - REFCOUNT_SHIFT)) - 1);
-	refcount = be16_to_cpu(s->refcount_block_cache[block_index]);
-	refcount += addend;
-	if (refcount < 0 || refcount > 0xffff)
-		return -EINVAL;
-	if (refcount == 0 && cluster_index < s->free_cluster_index) {
-		s->free_cluster_index = cluster_index;
-	}
-	s->refcount_block_cache[block_index] = cpu_to_be16(refcount);
-	if (bdrv_pwrite(s->fd,
-					refcount_block_offset + (block_index << REFCOUNT_SHIFT),
-					&s->refcount_block_cache[block_index], 2) != 2)
-		return -EIO;
-	return refcount;
-}
-
-static void update_refcount(struct disk_driver *bs,
-		int64_t offset, int64_t length,
-		int addend)
-{
-	BDRVQcowState *s = bs->private;
-	int64_t start, last, cluster_offset;
-
-#ifdef DEBUG_ALLOC2
-	printf("update_refcount: offset=%lld size=%lld addend=%d\n",
-		   offset, length, addend);
-#endif
-	if (length <= 0)
-		return;
-	start = offset & ~(s->cluster_size - 1);
-	last = (offset + length - 1) & ~(s->cluster_size - 1);
-	for(cluster_offset = start; cluster_offset <= last;
-		cluster_offset += s->cluster_size) {
-		update_cluster_refcount(bs, cluster_offset >> s->cluster_bits, addend);
-	}
-}
-
-#ifdef DEBUG_ALLOC
-static void inc_refcounts(struct disk_driver *bs,
-		uint16_t *refcount_table,
-		int refcount_table_size,
-		int64_t offset, int64_t size)
-{
-	BDRVQcowState *s = bs->private;
-	int64_t start, last, cluster_offset;
-	int k;
-
-	if (size <= 0)
-		return;
-
-	start = offset & ~(s->cluster_size - 1);
-	last = (offset + size - 1) & ~(s->cluster_size - 1);
-	for(cluster_offset = start; cluster_offset <= last;
-		cluster_offset += s->cluster_size) {
-		k = cluster_offset >> s->cluster_bits;
-		if (k < 0 || k >= refcount_table_size) {
-			printf("ERROR: invalid cluster offset=0x%llx\n", cluster_offset);
-		} else {
-			if (++refcount_table[k] == 0) {
-				printf("ERROR: overflow cluster offset=0x%llx\n", cluster_offset);
-			}
-		}
-	}
-}
-
-static int check_refcounts_l1(struct disk_driver *bs,
-		uint16_t *refcount_table,
-		int refcount_table_size,
-		int64_t l1_table_offset, int l1_size,
-		int check_copied)
-{
-	BDRVQcowState *s = bs->private;
-	uint64_t *l1_table, *l2_table, l2_offset, offset, l1_size2;
-	int l2_size, i, j, nb_csectors, refcount;
-
-	l2_table = NULL;
-	l1_size2 = l1_size * sizeof(uint64_t);
-
-	inc_refcounts(bs, refcount_table, refcount_table_size,
-				  l1_table_offset, l1_size2);
-
-	l1_table = qemu_malloc(l1_size2);
-	if (!l1_table)
-		goto fail;
-	if (bdrv_pread(s->fd, l1_table_offset,
-				   l1_table, l1_size2) != l1_size2)
-		goto fail;
-	for(i = 0;i < l1_size; i++)
-		be64_to_cpus(&l1_table[i]);
-
-	l2_size = s->l2_size * sizeof(uint64_t);
-	l2_table = qemu_malloc(l2_size);
-	if (!l2_table)
-		goto fail;
-	for(i = 0; i < l1_size; i++) {
-		l2_offset = l1_table[i];
-		if (l2_offset) {
-			if (check_copied) {
-				refcount = get_refcount(bs, (l2_offset & ~QCOW_OFLAG_COPIED) >> s->cluster_bits);
-				if ((refcount == 1) != ((l2_offset & QCOW_OFLAG_COPIED) != 0)) {
-					printf("ERROR OFLAG_COPIED: l2_offset=%llx refcount=%d\n",
-						   l2_offset, refcount);
-				}
-			}
-			l2_offset &= ~QCOW_OFLAG_COPIED;
-			if (bdrv_pread(s->fd, l2_offset, l2_table, l2_size) != l2_size)
-				goto fail;
-			for(j = 0; j < s->l2_size; j++) {
-				offset = be64_to_cpu(l2_table[j]);
-				if (offset != 0) {
-					if (offset & QCOW_OFLAG_COMPRESSED) {
-						if (offset & QCOW_OFLAG_COPIED) {
-							printf("ERROR: cluster %lld: copied flag must never be set for compressed clusters\n",
-								   offset >> s->cluster_bits);
-							offset &= ~QCOW_OFLAG_COPIED;
-						}
-						nb_csectors = ((offset >> s->csize_shift) &
-									   s->csize_mask) + 1;
-						offset &= s->cluster_offset_mask;
-						inc_refcounts(bs, refcount_table,
-								refcount_table_size,
-								offset & ~511, nb_csectors * 512);
-					} else {
-						if (check_copied) {
-							refcount = get_refcount(bs, (offset & ~QCOW_OFLAG_COPIED) >> s->cluster_bits);
-							if ((refcount == 1) != ((offset & QCOW_OFLAG_COPIED) != 0)) {
-								printf("ERROR OFLAG_COPIED: offset=%llx refcount=%d\n",
-									   offset, refcount);
-							}
-						}
-						offset &= ~QCOW_OFLAG_COPIED;
-						inc_refcounts(bs, refcount_table,
-								refcount_table_size,
-								offset, s->cluster_size);
-					}
-				}
-			}
-			inc_refcounts(bs, refcount_table,
-					refcount_table_size,
-					l2_offset,
-					s->cluster_size);
-		}
-	}
-	qemu_free(l1_table);
-	qemu_free(l2_table);
-	return 0;
- fail:
-	printf("ERROR: I/O error in check_refcounts_l1\n");
-	qemu_free(l1_table);
-	qemu_free(l2_table);
-	return -EIO;
-}
-
-static void check_refcounts(struct disk_driver *bs)
-{
-	BDRVQcowState *s = bs->private;
-	int64_t size;
-	int nb_clusters, refcount1, refcount2, i;
-	QCowSnapshot *sn;
-	uint16_t *refcount_table;
-
-	size = bdrv_getlength(s->fd);
-	nb_clusters = (size + s->cluster_size - 1) >> s->cluster_bits;
-	refcount_table = qemu_mallocz(nb_clusters * sizeof(uint16_t));
-
-	/* header */
-	inc_refcounts(bs, refcount_table, nb_clusters,
-			0, s->cluster_size);
-
-	check_refcounts_l1(bs, refcount_table, nb_clusters,
-			s->l1_table_offset, s->l1_size, 1);
-
-	/* snapshots */
-	for(i = 0; i < s->nb_snapshots; i++) {
-		sn = s->snapshots + i;
-		check_refcounts_l1(bs, refcount_table, nb_clusters,
-						   sn->l1_table_offset, sn->l1_size, 0);
-	}
-	inc_refcounts(bs, refcount_table, nb_clusters,
-				  s->snapshots_offset, s->snapshots_size);
-
-	/* refcount data */
-	inc_refcounts(bs, refcount_table, nb_clusters,
-			s->refcount_table_offset,
-			s->refcount_table_size * sizeof(uint64_t));
-
-	for(i = 0; i < s->refcount_table_size; i++) {
-		int64_t offset;
-		offset = s->refcount_table[i];
-		if (offset != 0) {
-			inc_refcounts(bs, refcount_table, nb_clusters,
-					offset, s->cluster_size);
-		}
-	}
-
-	/* compare ref counts */
-	for(i = 0; i < nb_clusters; i++) {
-		refcount1 = get_refcount(bs, i);
-		refcount2 = refcount_table[i];
-		if (refcount1 != refcount2)
-			printf("ERROR cluster %d refcount=%d reference=%d\n",
-				   i, refcount1, refcount2);
-	}
-
-	qemu_free(refcount_table);
-}
-#endif
-
-
-/**
- * Wrapper for synchronous read.
- * This function is called when not using AIO at all (#undef USE_AIO) or
- * for accessing the backing file.
- */
-static int qcow_sync_read(struct disk_driver *dd, uint64_t sector,
-		int nb_sectors, char *buf, td_callback_t cb,
-		int id, void *prv)
-{
-	int ret = qcow_read(dd, sector, (uint8_t*) buf, nb_sectors);
-
-	if (cb != NULL) {
-		return cb(dd, (ret < 0) ? ret : 0, sector, nb_sectors, id, prv);
-	} else {
-		return ret;
-	}
-}
-
-#ifndef USE_AIO
-/**
- * Wrapper for synchronous write
- */
-static int qcow_sync_write(struct disk_driver *dd, uint64_t sector,
-		int nb_sectors, char *buf, td_callback_t cb,
-		int id, void *prv)
-{
-	int ret = qcow_write(dd, sector, (uint8_t*) buf, nb_sectors);
-	
-	return cb(dd, (ret < 0) ? ret : 0, sector, nb_sectors, id, prv);
-}
-#endif
-
-
-
-#ifndef USE_AIO
-
-static int qcow_do_callbacks(struct disk_driver *dd, int sid)
-{
-	return 1;
-}
-
-#else
-
-static int qcow_do_callbacks(struct disk_driver *dd, int sid)
-{
-	int ret, i, nr_events, rsp = 0,*ptr;
-	struct io_event *ep;
-	struct BDRVQcowState *prv = (struct BDRVQcowState*)dd->private;
-
-	if (sid > MAX_IOFD) return 1;
-
-	nr_events = tap_aio_get_events(&prv->async.aio_ctx);
-
-repeat:
-	for (ep = prv->async.aio_events, i = nr_events; i-- > 0; ep++) {
-		struct iocb		   *io	= ep->obj;
-		struct pending_aio *pio;
-
-		pio = &prv->async.pending_aio[(long)io->data];
-
-		tap_aio_unlock(&prv->async, pio->sector);
-
-		if (prv->crypt_method)
-			encrypt_sectors(prv, pio->sector, 
-					(unsigned char *)pio->buf, 
-					(unsigned char *)pio->buf, 
-					pio->nb_sectors, 0, 
-					&prv->aes_decrypt_key);
-
-		rsp += pio->cb(dd, ep->res == io->u.c.nbytes ? 0 : 1, 
-			pio->sector, pio->nb_sectors,
-			pio->id, pio->private);
-
-		prv->async.iocb_free[prv->async.iocb_free_count++] = io;
-	}
-
-	if (nr_events) {
-		nr_events = tap_aio_more_events(&prv->async.aio_ctx);
-		goto repeat;
-	}
-
-	tap_aio_continue(&prv->async.aio_ctx);
-
-	return rsp;
-}
-
-#endif	
-
-static int get_filesize(char *filename, uint64_t *size, struct stat *st)
-{
-	int fd;
-	QCowHeader header;
-
-	/*Set to the backing file size*/
-	fd = open(filename, O_RDONLY);
-	if (fd < 0)
-		return -1;
-	if (read(fd, &header, sizeof(header)) < sizeof(header)) {
-		close(fd);
-		return -1;
-	}
-	close(fd);
-	
-	be32_to_cpus(&header.magic);
-	be32_to_cpus(&header.version);
-	be64_to_cpus(&header.size);
-	if (header.magic == QCOW_MAGIC && header.version == QCOW_VERSION) {
-		*size = header.size >> SECTOR_SHIFT;
-		return 0;
-	}
-
-	if(S_ISBLK(st->st_mode)) {
-		fd = open(filename, O_RDONLY);
-		if (fd < 0)
-			return -1;
-		if (blk_getimagesize(fd, size) != 0) {
-			close(fd);
-			return -1;
-		}
-		close(fd);
-	} else *size = (st->st_size >> SECTOR_SHIFT);	
-	return 0;
-}
-
-/**
- * @return 
- *	   0 if parent id successfully retrieved;
- *	   TD_NO_PARENT if no parent exists;
- *	   -errno on error
- */
-static int qcow_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	struct BDRVQcowState* s = (struct BDRVQcowState*) dd->private;
-
-	if (s->backing_file[0] == '\0')
-		return TD_NO_PARENT;
-
-	id->name = strdup(s->backing_file);
-	id->drivertype = DISK_TYPE_AIO;
-
-	return 0;
-}
-
-static int qcow_validate_parent(struct disk_driver *child, 
-		struct disk_driver *parent, td_flag_t flags)
-{
-	struct stat stats;
-	uint64_t psize, csize;
-	
-	if (stat(parent->name, &stats))
-		return -EINVAL;
-	if (get_filesize(parent->name, &psize, &stats))
-		return -EINVAL;
-
-	if (stat(child->name, &stats))
-		return -EINVAL;
-	if (get_filesize(child->name, &csize, &stats))
-		return -EINVAL;
-
-	if (csize != psize)
-		return -EINVAL;
-
-	return 0;
-}
-
-int qcow2_create(const char *filename, uint64_t total_size,
-                      const char *backing_file, int flags)
-{
-    int fd, header_size, backing_filename_len, l1_size, i, shift, l2_bits;
-    int ret = 0;
-    QCowHeader header;
-    uint64_t tmp, offset;
-    QCowCreateState s1, *s = &s1;
-
-    memset(s, 0, sizeof(*s));
-
-    fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY, 0644);
-    if (fd < 0)
-        return -1;
-    memset(&header, 0, sizeof(header));
-    header.magic = cpu_to_be32(QCOW_MAGIC);
-    header.version = cpu_to_be32(QCOW_VERSION);
-    header.size = cpu_to_be64(total_size * 512);
-    header_size = sizeof(header);
-    backing_filename_len = 0;
-    if (backing_file) {
-        header.backing_file_offset = cpu_to_be64(header_size);
-        backing_filename_len = strlen(backing_file);
-        header.backing_file_size = cpu_to_be32(backing_filename_len);
-        header_size += backing_filename_len;
-    }
-    s->cluster_bits = 12;  /* 4 KB clusters */
-    s->cluster_size = 1 << s->cluster_bits;
-    header.cluster_bits = cpu_to_be32(s->cluster_bits);
-    header_size = (header_size + 7) & ~7;
-    if (flags & BLOCK_FLAG_ENCRYPT) {
-        header.crypt_method = cpu_to_be32(QCOW_CRYPT_AES);
-    } else {
-        header.crypt_method = cpu_to_be32(QCOW_CRYPT_NONE);
-    }
-    l2_bits = s->cluster_bits - 3;
-    shift = s->cluster_bits + l2_bits;
-    l1_size = (((total_size * 512) + (1LL << shift) - 1) >> shift);
-    offset = align_offset(header_size, s->cluster_size);
-    s->l1_table_offset = offset;
-    header.l1_table_offset = cpu_to_be64(s->l1_table_offset);
-    header.l1_size = cpu_to_be32(l1_size);
-    offset += align_offset(l1_size * sizeof(uint64_t), s->cluster_size);
-
-    s->refcount_table = qemu_mallocz(s->cluster_size);
-    s->refcount_block = qemu_mallocz(s->cluster_size);
-
-    s->refcount_table_offset = offset;
-    header.refcount_table_offset = cpu_to_be64(offset);
-    header.refcount_table_clusters = cpu_to_be32(1);
-    offset += s->cluster_size;
-
-    s->refcount_table[0] = cpu_to_be64(offset);
-    s->refcount_block_offset = offset;
-    offset += s->cluster_size;
-
-    /* update refcounts */
-    create_refcount_update(s, 0, header_size);
-    create_refcount_update(s, s->l1_table_offset, l1_size * sizeof(uint64_t));
-    create_refcount_update(s, s->refcount_table_offset, s->cluster_size);
-    create_refcount_update(s, s->refcount_block_offset, s->cluster_size);
-
-    /* write all the data */
-    ret = write(fd, &header, sizeof(header));
-    if (ret < 0)
-        goto out;
-    if (backing_file) {
-        ret = write(fd, backing_file, backing_filename_len);
-        if (ret < 0)
-            goto out;
-    }
-    lseek(fd, s->l1_table_offset, SEEK_SET);
-    tmp = 0;
-    for(i = 0;i < l1_size; i++) {
-        ret = write(fd, &tmp, sizeof(tmp));
-        if (ret < 0)
-            goto out;
-    }
-    lseek(fd, s->refcount_table_offset, SEEK_SET);
-    ret = write(fd, s->refcount_table, s->cluster_size);
-    if (ret < 0)
-        goto out;
-
-    lseek(fd, s->refcount_block_offset, SEEK_SET);
-    ret = write(fd, s->refcount_block, s->cluster_size);
-    if (ret < 0)
-        goto out;
-    ret = 0;
-
-  out:
-    qemu_free(s->refcount_table);
-    qemu_free(s->refcount_block);
-    close(fd);
-    return ret;
-}
-
-
-
-struct tap_disk tapdisk_qcow2 = {
-	"qcow2",
-	sizeof(BDRVQcowState),
-	qcow_open,
-#ifdef USE_AIO
-	qcow_queue_read,
-	qcow_queue_write,
-#else
-	qcow_sync_read,
-	qcow_sync_write,
-#endif
-	qcow_submit,
-	qcow_close,
-	qcow_do_callbacks,
-	qcow_get_parent_id,
-	qcow_validate_parent
-};
diff --git a/tools/blktap/drivers/block-ram.c b/tools/blktap/drivers/block-ram.c
deleted file mode 100644
index 836a68e..0000000
--- a/tools/blktap/drivers/block-ram.c
+++ /dev/null
@@ -1,295 +0,0 @@
-/* block-ram.c
- *
- * Fast Ramdisk implementation.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- * 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 <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <inttypes.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include "tapdisk.h"
-#include "blk.h"
-
-#define MAX_DISK_SIZE 1024000 /*500MB disk limit*/
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-char *img;
-long int   disksector_size;
-long int   disksize;
-long int   diskinfo;
-static int connections = 0;
-
-struct tdram_state {
-        int fd;
-	int poll_pipe[2]; /* dummy fd for polling on */
-};
-
-/*Get Image size, secsize*/
-static int get_image_info(struct td_state *s, int fd)
-{
-	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
-	struct stat stat;
-
-	ret = fstat(fd, &stat);
-	if (ret != 0) {
-		DPRINTF("ERROR: fstat failed, Couldn't stat image");
-		return -EINVAL;
-	}
-
-	if (S_ISBLK(stat.st_mode)) {
-		/*Accessing block device directly*/
-		if (blk_getimagesize(fd, &s->size) != 0)
-			return -EINVAL;
-
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-
-		/*Get the sector size*/
-		if (blk_getsectorsize(fd, &s->sector_size) != 0)
-			s->sector_size = DEFAULT_SECTOR_SIZE;
-
-	} else {
-		/*Local file? try fstat instead*/
-		s->size = (stat.st_size >> SECTOR_SHIFT);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-	}
-
-	if (s->size == 0) {		
-		s->size =((uint64_t) MAX_DISK_SIZE);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-	}
-	s->info = 0;
-
-        /*Store variables locally*/
-	disksector_size = s->sector_size;
-	disksize        = s->size;
-	diskinfo        = s->info;
-	DPRINTF("Image sector_size: \n\t[%"PRIu64"]\n",
-		s->sector_size);
-
-	return 0;
-}
-
-static inline void init_fds(struct disk_driver *dd)
-{
-        int i;
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
-
-        for(i =0 ; i < MAX_IOFD; i++)
-		dd->io_fd[i] = 0;
-
-        dd->io_fd[0] = prv->poll_pipe[0];
-}
-
-/* Open the disk file and initialize ram state. */
-static int tdram_open (struct disk_driver *dd, const char *name, td_flag_t flags)
-{
-	char *p;
-	uint64_t size;
-	int i, fd, ret = 0, count = 0, o_flags;
-	struct td_state    *s     = dd->td_state;
-	struct tdram_state *prv   = (struct tdram_state *)dd->private;
-
-	connections++;
-	
-	/* set up a pipe so that we can hand back a poll fd that won't fire.*/
-	ret = pipe(prv->poll_pipe);
-	if (ret != 0)
-		return (0 - errno);
-
-	if (connections > 1) {
-		s->sector_size = disksector_size;
-		s->size        = disksize;
-		s->info        = diskinfo; 
-		DPRINTF("Image already open, returning parameters:\n");
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-		DPRINTF("Image sector_size: \n\t[%"PRIu64"]\n",
-			s->sector_size);
-
-		prv->fd = -1;
-		goto done;
-	}
-
-	/* Open the file */
-	o_flags = O_DIRECT | O_LARGEFILE | 
-		((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-        fd = open(name, o_flags);
-
-        if ((fd == -1) && (errno == EINVAL)) {
-
-                /* Maybe O_DIRECT isn't supported. */
-		o_flags &= ~O_DIRECT;
-                fd = open(name, o_flags);
-                if (fd != -1) DPRINTF("WARNING: Accessing image without"
-                                     "O_DIRECT! (%s)\n", name);
-
-        } else if (fd != -1) DPRINTF("open(%s) with O_DIRECT\n", name);
-	
-        if (fd == -1) {
-		DPRINTF("Unable to open [%s]!\n",name);
-        	ret = 0 - errno;
-        	goto done;
-        }
-
-        prv->fd = fd;
-
-	ret = get_image_info(s, fd);
-	size = MAX_DISK_SIZE;
-
-	if (s->size > size) {
-		DPRINTF("Disk exceeds limit, must be less than [%d]MB",
-			(MAX_DISK_SIZE<<SECTOR_SHIFT)>>20);
-		return -ENOMEM;
-	}
-
-	/*Read the image into memory*/
-	p = img = malloc(s->size << SECTOR_SHIFT);
-	if (img == NULL) {
-		DPRINTF("Mem malloc failed\n");
-		return -1;
-	}
-	DPRINTF("Reading %llu bytes.......",(long long unsigned)s->size << SECTOR_SHIFT);
-
-	for (i = 0; i < s->size; i++) {
-		ret = read(prv->fd, p, s->sector_size);
-		if (ret != s->sector_size) {
-			ret = 0 - errno;
-			break;
-		} else {
-			count += ret;
-			p = img + count;
-		}
-	}
-	DPRINTF("[%d]\n",count);
-	if (count != s->size << SECTOR_SHIFT) {
-		ret = -1;
-	} else {
-		ret = 0;
-	} 
-
-	init_fds(dd);
-done:
-	return ret;
-}
-
-static int tdram_queue_read(struct disk_driver *dd, uint64_t sector,
-		      int nb_sectors, char *buf, td_callback_t cb,
-		      int id, void *private)
-{
-	struct td_state    *s   = dd->td_state;
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-
-	memcpy(buf, img + offset, size);
-
-	return cb(dd, 0, sector, nb_sectors, id, private);
-}
-
-static int tdram_queue_write(struct disk_driver *dd, uint64_t sector,
-		      int nb_sectors, char *buf, td_callback_t cb,
-		      int id, void *private)
-{
-	struct td_state    *s   = dd->td_state;
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-	
-	/* We assume that write access is controlled
-	 * at a higher level for multiple disks */
-	memcpy(img + offset, buf, size);
-
-	return cb(dd, 0, sector, nb_sectors, id, private);
-}
- 		
-static int tdram_submit(struct disk_driver *dd)
-{
-	return 0;	
-}
-
-static int tdram_close(struct disk_driver *dd)
-{
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
-	
-	connections--;
-	
-	return 0;
-}
-
-static int tdram_do_callbacks(struct disk_driver *dd, int sid)
-{
-	/* always ask for a kick */
-	return 1;
-}
-
-static int tdram_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	return TD_NO_PARENT;
-}
-
-static int tdram_validate_parent(struct disk_driver *dd, 
-			  struct disk_driver *parent, td_flag_t flags)
-{
-	return -EINVAL;
-}
-
-struct tap_disk tapdisk_ram = {
-	.disk_type          = "tapdisk_ram",
-	.private_data_size  = sizeof(struct tdram_state),
-	.td_open            = tdram_open,
-	.td_queue_read      = tdram_queue_read,
-	.td_queue_write     = tdram_queue_write,
-	.td_submit          = tdram_submit,
-	.td_close           = tdram_close,
-	.td_do_callbacks    = tdram_do_callbacks,
-	.td_get_parent_id   = tdram_get_parent_id,
-	.td_validate_parent = tdram_validate_parent
-};
diff --git a/tools/blktap/drivers/block-sync.c b/tools/blktap/drivers/block-sync.c
deleted file mode 100644
index dde4538..0000000
--- a/tools/blktap/drivers/block-sync.c
+++ /dev/null
@@ -1,242 +0,0 @@
-/* block-sync.c
- *
- * simple slow synchronous raw disk implementation.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- * 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 <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include "tapdisk.h"
-#include "blk.h"
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-struct tdsync_state {
-	int fd;
-	int poll_pipe[2]; /* dummy fd for polling on */
-};
-	
-/*Get Image size, secsize*/
-static int get_image_info(struct td_state *s, int fd)
-{
-	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
-	struct stat stat;
-
-	ret = fstat(fd, &stat);
-	if (ret != 0) {
-		DPRINTF("ERROR: fstat failed, Couldn't stat image");
-		return -EINVAL;
-	}
-
-	if (S_ISBLK(stat.st_mode)) {
-		/*Accessing block device directly*/
-		if (blk_getimagesize(fd, &s->size) != 0)
-			return -EINVAL;
-
-		DPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-
-		/*Get the sector size*/
-		if (blk_getsectorsize(fd, &s->sector_size) != 0)
-			s->sector_size = DEFAULT_SECTOR_SIZE;
-
-	} else {
-		/*Local file? try fstat instead*/
-		s->size = (stat.st_size >> SECTOR_SHIFT);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-		DPRINTF("Image size: \n\tpre sector_shift  [%lluu]\n\tpost "
-			"sector_shift [%lluu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-	}
-
-	if (s->size == 0)
-		return -EINVAL;
-
-	s->info = 0;
-
-	return 0;
-}
-
-static inline void init_fds(struct disk_driver *dd)
-{
-	int i;
-	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
-	
-	for(i = 0; i < MAX_IOFD; i++)
-		dd->io_fd[i] = 0;
-
-	dd->io_fd[0] = prv->poll_pipe[0];
-}
-
-/* Open the disk file and initialize aio state. */
-static int tdsync_open (struct disk_driver *dd, const char *name, td_flag_t flags)
-{
-	int i, fd, ret = 0, o_flags;
-	struct td_state     *s   = dd->td_state;
-	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
-	
-	/* set up a pipe so that we can hand back a poll fd that won't fire.*/
-	ret = pipe(prv->poll_pipe);
-	if (ret != 0)
-		return (0 - errno);
-	
-	/* Open the file */
-	o_flags = O_DIRECT | O_LARGEFILE | 
-		((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-        fd = open(name, o_flags);
-
-        if ( (fd == -1) && (errno == EINVAL) ) {
-
-                /* Maybe O_DIRECT isn't supported. */
-		o_flags &= ~O_DIRECT;
-                fd = open(name, o_flags);
-                if (fd != -1) DPRINTF("WARNING: Accessing image without"
-                                     "O_DIRECT! (%s)\n", name);
-
-        } else if (fd != -1) DPRINTF("open(%s) with O_DIRECT\n", name);
-	
-        if (fd == -1) {
-		DPRINTF("Unable to open [%s]!\n",name);
-        	ret = 0 - errno;
-        	goto done;
-        }
-
-        prv->fd = fd;
-
-	init_fds(dd);
-	ret = get_image_info(s, fd);
-done:
-	return ret;	
-}
-
-static int tdsync_queue_read(struct disk_driver *dd, uint64_t sector,
-			       int nb_sectors, char *buf, td_callback_t cb,
-			       int id, void *private)
-{
-	struct td_state     *s   = dd->td_state;
-	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-	int ret;
-	
-	ret = lseek(prv->fd, offset, SEEK_SET);
-	if (ret != (off_t)-1) {
-		ret = read(prv->fd, buf, size);
-		if (ret != size) {
-			ret = 0 - errno;
-		} else {
-			ret = 1;
-		} 
-	} else ret = 0 - errno;
-		
-	return cb(dd, (ret < 0) ? ret: 0, sector, nb_sectors, id, private);
-}
-
-static int tdsync_queue_write(struct disk_driver *dd, uint64_t sector,
-			       int nb_sectors, char *buf, td_callback_t cb,
-			       int id, void *private)
-{
-	struct td_state     *s   = dd->td_state;
-	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
-	int      size    = nb_sectors * s->sector_size;
-	uint64_t offset  = sector * (uint64_t)s->sector_size;
-	int ret = 0;
-	
-	ret = lseek(prv->fd, offset, SEEK_SET);
-	if (ret != (off_t)-1) {
-		ret = write(prv->fd, buf, size);
-		if (ret != size) {
-			ret = 0 - errno;
-		} else {
-			ret = 1;
-		}
-	} else ret = 0 - errno;
-		
-	return cb(dd, (ret < 0) ? ret : 0, sector, nb_sectors, id, private);
-}
- 		
-static int tdsync_submit(struct disk_driver *dd)
-{
-	return 0;	
-}
-
-static int tdsync_close(struct disk_driver *dd)
-{
-	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
-	
-	close(prv->fd);
-	close(prv->poll_pipe[0]);
-	close(prv->poll_pipe[1]);
-	
-	return 0;
-}
-
-static int tdsync_do_callbacks(struct disk_driver *dd, int sid)
-{
-	/* always ask for a kick */
-	return 1;
-}
-
-static int tdsync_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	return TD_NO_PARENT;
-}
-
-static int tdsync_validate_parent(struct disk_driver *dd, 
-			   struct disk_driver *parent, td_flag_t flags)
-{
-	return -EINVAL;
-}
-
-struct tap_disk tapdisk_sync = {
-	.disk_type           = "tapdisk_sync",
-	.private_data_size   = sizeof(struct tdsync_state),
-	.td_open             = tdsync_open,
-	.td_queue_read       = tdsync_queue_read,
-	.td_queue_write      = tdsync_queue_write,
-	.td_submit           = tdsync_submit,
-	.td_close            = tdsync_close,
-	.td_do_callbacks     = tdsync_do_callbacks,
-	.td_get_parent_id    = tdsync_get_parent_id,
-	.td_validate_parent  = tdsync_validate_parent
-};
diff --git a/tools/blktap/drivers/block-vmdk.c b/tools/blktap/drivers/block-vmdk.c
deleted file mode 100644
index 4d16965..0000000
--- a/tools/blktap/drivers/block-vmdk.c
+++ /dev/null
@@ -1,428 +0,0 @@
-/* block-vmdk.c
- *
- * VMware Disk format implementation.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- * This is largely the same as the vmdk driver in Qemu, I've just twisted it
- * to match our interfaces.  The original (BSDish) Copyright message appears 
- * below:
- */
- 
-/*
- * Block driver for the VMDK format
- * 
- * Copyright (c) 2004 Fabrice Bellard
- * Copyright (c) 2005 Filip Navara
- * 
- * 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.
- */
-
-#include <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include "tapdisk.h"
-#include "bswap.h"
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-#define safer_free(_x)       \
-  do {                       \
-  	if (NULL != _x) {    \
-  		free(_x);    \
-  		(_x) = NULL; \
-  	}                    \
-  } while (0) ;
-
-#define VMDK3_MAGIC (('C' << 24) | ('O' << 16) | ('W' << 8) | 'D')
-#define VMDK4_MAGIC (('K' << 24) | ('D' << 16) | ('M' << 8) | 'V')
-
-typedef struct {
-    uint32_t version;
-    uint32_t flags;
-    uint32_t disk_sectors;
-    uint32_t granularity;
-    uint32_t l1dir_offset;
-    uint32_t l1dir_size;
-    uint32_t file_sectors;
-    uint32_t cylinders;
-    uint32_t heads;
-    uint32_t sectors_per_track;
-} VMDK3Header;
-
-typedef struct {
-    uint32_t version;
-    uint32_t flags;
-    int64_t capacity;
-    int64_t granularity;
-    int64_t desc_offset;
-    int64_t desc_size;
-    int32_t num_gtes_per_gte;
-    int64_t rgd_offset;
-    int64_t gd_offset;
-    int64_t grain_offset;
-    char filler[1];
-    char check_bytes[4];
-} __attribute__((packed)) VMDK4Header;
-
-#define L2_CACHE_SIZE 16
-
-struct tdvmdk_state {
-        int fd;
-	int poll_pipe[2]; /* dummy fd for polling on */
-	
-    	unsigned int l1_size;
-    	int64_t l1_table_offset;
-    	int64_t l1_backup_table_offset;
-    	uint32_t l1_entry_sectors;
-    	unsigned int l2_size;
-	
-    	uint32_t *l1_table;
-    	uint32_t *l1_backup_table;
-    	uint32_t *l2_cache;
-    	uint32_t l2_cache_offsets[L2_CACHE_SIZE];
-    	uint32_t l2_cache_counts[L2_CACHE_SIZE];
-    	
-    	unsigned int cluster_sectors;
-};
-
-static inline void init_fds(struct disk_driver *dd)
-{
-        int i;
-	struct tdvmdk_state *prv = (struct tdvmdk_state *)dd->private;
-
-        for (i = 0; i < MAX_IOFD; i++)
-		dd->io_fd[i] = 0;
-
-        dd->io_fd[0] = prv->poll_pipe[0];
-}
-
-/* Open the disk file and initialize aio state. */
-static int tdvmdk_open (struct disk_driver *dd, 
-			const char *name, td_flag_t flags)
-{
-	int ret, fd;
-    	int l1_size, i, o_flags;
-    	uint32_t magic;
-	struct td_state     *s   = dd->td_state;
-	struct tdvmdk_state *prv = (struct tdvmdk_state *)dd->private;
-
-	/* set up a pipe so that we can hand back a poll fd that won't fire.*/
-	ret = pipe(prv->poll_pipe);
-	if (ret != 0)
-		return -1;
-	
-	/* Open the file */
-	o_flags = O_DIRECT | O_LARGEFILE | 
-		((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
-        fd = open(name, o_flags); 
-
-        if ( (fd == -1) && (errno == EINVAL) ) {
-
-                /* Maybe O_DIRECT isn't supported. */
-		o_flags &= ~O_DIRECT;
-                fd = open(name, o_flags);
-                if (fd != -1) DPRINTF("WARNING: Accessing image without"
-                                     "O_DIRECT! (%s)\n", name);
-
-        } else if (fd != -1) DPRINTF("open(%s) with O_DIRECT\n", name);
-	
-        if (fd == -1) {
-		DPRINTF("Unable to open [%s]!\n",name);
-        	ret = 0 - errno;
-        	return -1;
-        }
-        
-        prv->fd = fd;
-        
-        /* Grok the vmdk header. */
-    	if ((ret = read(fd, &magic, sizeof(magic))) != sizeof(magic))
-        	goto fail;
-    	magic = be32_to_cpu(magic);
-    	if (magic == VMDK3_MAGIC) {
-        	VMDK3Header header;
-        	if (read(fd, &header, sizeof(header)) != 
-            		sizeof(header)) 
-            		goto fail;
-        	prv->cluster_sectors = le32_to_cpu(header.granularity);
-        	prv->l2_size = 1 << 9;
-        	prv->l1_size = 1 << 6;
-        	s->size = le32_to_cpu(header.disk_sectors);
-        	prv->l1_table_offset = le32_to_cpu(header.l1dir_offset) << 9;
-        	prv->l1_backup_table_offset = 0;
-        	prv->l1_entry_sectors = prv->l2_size * prv->cluster_sectors;
-    	} else if (magic == VMDK4_MAGIC) {
-        	VMDK4Header header;
-        
-        	if (read(fd, &header, sizeof(header)) != sizeof(header))
-            		goto fail;
-        	s->size = le32_to_cpu(header.capacity);
-        	prv->cluster_sectors = le32_to_cpu(header.granularity);
-        	prv->l2_size = le32_to_cpu(header.num_gtes_per_gte);
-        	prv->l1_entry_sectors = prv->l2_size * prv->cluster_sectors;
-        	if (prv->l1_entry_sectors <= 0)
-            		goto fail;
-        	prv->l1_size = (s->size + prv->l1_entry_sectors - 1) 
-            		       / prv->l1_entry_sectors;
-        	prv->l1_table_offset = le64_to_cpu(header.rgd_offset) << 9;
-        	prv->l1_backup_table_offset = 
-        		le64_to_cpu(header.gd_offset) << 9;
-    	} else {
-        	goto fail;
-    	}
-    	/* read the L1 table */
-    	l1_size = prv->l1_size * sizeof(uint32_t);
-    	prv->l1_table = malloc(l1_size);
-    	if (!prv->l1_table)
-        	goto fail;
-    	if (lseek(fd, prv->l1_table_offset, SEEK_SET) == -1)
-        	goto fail;
-    	if (read(fd, prv->l1_table, l1_size) != l1_size)
-        	goto fail;
-    	for (i = 0; i < prv->l1_size; i++) {
-        	le32_to_cpus(&prv->l1_table[i]);
-    	}
-
-    	if (prv->l1_backup_table_offset) {
-        	prv->l1_backup_table = malloc(l1_size);
-        	if (!prv->l1_backup_table)
-            		goto fail;
-        	if (lseek(fd, prv->l1_backup_table_offset, SEEK_SET) == -1)
-            		goto fail;
-        	if (read(fd, prv->l1_backup_table, l1_size) != l1_size)
-            		goto fail;
-        	for(i = 0; i < prv->l1_size; i++) {
-            		le32_to_cpus(&prv->l1_backup_table[i]);
-        	}
-    	}
-
-    	prv->l2_cache = malloc(prv->l2_size * L2_CACHE_SIZE *sizeof(uint32_t));
-    	if (!prv->l2_cache)
-        	goto fail;
-    	prv->fd = fd;
-	init_fds(dd);
-	DPRINTF("VMDK File opened successfully\n");
-    	return 0;
-	
-fail:
-	DPRINTF("VMDK File open failed.\n"); 
-   	safer_free(prv->l1_backup_table);
-    	free(prv->l1_table);
-    	free(prv->l2_cache);
-    	close(fd);
-	return -1;
-}
-
-static uint64_t get_cluster_offset(struct tdvmdk_state *prv, 
-                                   uint64_t offset, int allocate)
-{
-    	unsigned int l1_index, l2_offset, l2_index;
-    	int min_index, i, j;
-    	uint32_t min_count, *l2_table, tmp;
-    	uint64_t cluster_offset;
-    
-    	l1_index = (offset >> 9) / prv->l1_entry_sectors;
-    	if (l1_index >= prv->l1_size)
-        	return 0;
-    	l2_offset = prv->l1_table[l1_index];
-    	if (!l2_offset)
-        	return 0;
-    	for (i = 0; i < L2_CACHE_SIZE; i++) {
-        	if (l2_offset == prv->l2_cache_offsets[i]) {
-            		/* increment the hit count */
-            		if (++prv->l2_cache_counts[i] == 0xffffffff) {
-	                	for(j = 0; j < L2_CACHE_SIZE; j++) {
-	                    		prv->l2_cache_counts[j] >>= 1;
-	                	}
-            		}
-            		l2_table = prv->l2_cache + (i * prv->l2_size);
-            		goto found;
-        	}
-    	}
-    	/* not found: load a new entry in the least used one */
-    	min_index = 0;
-    	min_count = 0xffffffff;
-    	for (i = 0; i < L2_CACHE_SIZE; i++) {
-        	if (prv->l2_cache_counts[i] < min_count) {
-            		min_count = prv->l2_cache_counts[i];
-            		min_index = i;
-        	}
-    	}
-    	l2_table = prv->l2_cache + (min_index * prv->l2_size);
-    	lseek(prv->fd, (int64_t)l2_offset * 512, SEEK_SET);
-    	if (read(prv->fd, l2_table, prv->l2_size * sizeof(uint32_t)) != 
-        	 prv->l2_size * sizeof(uint32_t))
-        	return 0;
-    	prv->l2_cache_offsets[min_index] = l2_offset;
-    	prv->l2_cache_counts[min_index] = 1;
- found:
-    	l2_index = ((offset >> 9) / prv->cluster_sectors) % prv->l2_size;
-    	cluster_offset = le32_to_cpu(l2_table[l2_index]);
-    	if (!cluster_offset) {
-        	if (!allocate)
-            		return 0;
-        	cluster_offset = lseek(prv->fd, 0, SEEK_END);
-        	if (ftruncate(prv->fd, cluster_offset + 
-			      (prv->cluster_sectors << 9)))
-			return 0;
-        	cluster_offset >>= 9;
-        	/* update L2 table */
-        	tmp = cpu_to_le32(cluster_offset);
-        	l2_table[l2_index] = tmp;
-        	lseek(prv->fd, ((int64_t)l2_offset * 512) + 
-        	      (l2_index * sizeof(tmp)), SEEK_SET);
-        	if (write(prv->fd, &tmp, sizeof(tmp)) != sizeof(tmp))
-            		return 0;
-        	/* update backup L2 table */
-        	if (prv->l1_backup_table_offset != 0) {
-            		l2_offset = prv->l1_backup_table[l1_index];
-            	lseek(prv->fd, ((int64_t)l2_offset * 512) + 
-            		(l2_index * sizeof(tmp)), SEEK_SET);
-            	if (write(prv->fd, &tmp, sizeof(tmp)) != sizeof(tmp))
-                	return 0;
-        	}
-    	}
-    	cluster_offset <<= 9;
-    	return cluster_offset;
-}
-
-static int tdvmdk_queue_read(struct disk_driver *dd, uint64_t sector,
-			       int nb_sectors, char *buf, td_callback_t cb,
-			       int id, void *private)
-{
-	struct tdvmdk_state *prv = (struct tdvmdk_state *)dd->private;
-    	int index_in_cluster, n;
-    	uint64_t cluster_offset;
-    	int ret = 0;
-
-    	while (nb_sectors > 0) {
-        	cluster_offset = get_cluster_offset(prv, sector << 9, 0);
-        	index_in_cluster = sector % prv->cluster_sectors;
-        	n = prv->cluster_sectors - index_in_cluster;
-        	if (n > nb_sectors)
-            		n = nb_sectors;
-        	if (!cluster_offset) {
-            		memset(buf, 0, 512 * n);
-        	} else {
-            		lseek(prv->fd, cluster_offset + index_in_cluster * 512,
-            	      	      SEEK_SET);
-            		ret = read(prv->fd, buf, n * 512);
-            		if (ret != n * 512) {
-                		ret = -1;
-                		goto done;
-            		}
-        	}
-        	nb_sectors -= n;
-        	sector     += n;
-        	buf += n * 512;
-    	}
-done:
-	return cb(dd, ret == -1 ? -1 : 0, sector, nb_sectors, id, private);
-}
-
-static  int tdvmdk_queue_write(struct disk_driver *dd, uint64_t sector,
-			       int nb_sectors, char *buf, td_callback_t cb,
-			       int id, void *private)
-{
-	struct tdvmdk_state *prv = (struct tdvmdk_state *)dd->private;
-    	int index_in_cluster, n;
-    	uint64_t cluster_offset;
-    	int ret = 0;
-
-    	while (nb_sectors > 0) {
-        	index_in_cluster = sector & (prv->cluster_sectors - 1);
-        	n = prv->cluster_sectors - index_in_cluster;
-        	if (n > nb_sectors)
-            		n = nb_sectors;
-        	cluster_offset = get_cluster_offset(prv, sector << 9, 1);
-        	if (!cluster_offset) {
-            		ret = -1;
-            		goto done;
-        	}
-        	lseek(prv->fd, cluster_offset + index_in_cluster * 512, 
-        	      SEEK_SET);
-        	ret = write(prv->fd, buf, n * 512);
-        	if (ret != n * 512) {
-            		ret = -1;
-            		goto done;
-        	}
-        	nb_sectors -= n;
-        	sector     += n;
-        	buf += n * 512;
-    	}
-done:
-	return cb(dd, ret == -1 ? -1 : 0, sector, nb_sectors, id, private);
-}
- 		
-static int tdvmdk_submit(struct disk_driver *dd)
-{
-	return 0;	
-}
-
-static int tdvmdk_close(struct disk_driver *dd)
-{
-	struct tdvmdk_state *prv = (struct tdvmdk_state *)dd->private;
-	
-    	safer_free(prv->l1_table);
-    	safer_free(prv->l1_backup_table);
-    	safer_free(prv->l2_cache);
-    	close(prv->fd);
-	close(prv->poll_pipe[0]);
-	close(prv->poll_pipe[1]);
-	return 0;
-}
-
-static int tdvmdk_do_callbacks(struct disk_driver *dd, int sid)
-{
-	/* always ask for a kick */
-	return 1;
-}
-
-static int tdvmdk_get_parent_id(struct disk_driver *dd, struct disk_id *id)
-{
-	return TD_NO_PARENT;
-}
-
-static int tdvmdk_validate_parent(struct disk_driver *dd, 
-				  struct disk_driver *parent, td_flag_t flags)
-{
-	return -EINVAL;
-}
-
-struct tap_disk tapdisk_vmdk = {
-	.disk_type           = "tapdisk_vmdk",
-	.private_data_size   = sizeof(struct tdvmdk_state),
-	.td_open             = tdvmdk_open,
-	.td_queue_read       = tdvmdk_queue_read,
-	.td_queue_write      = tdvmdk_queue_write,
-	.td_submit           = tdvmdk_submit,
-	.td_close            = tdvmdk_close,
-	.td_do_callbacks     = tdvmdk_do_callbacks,
-	.td_get_parent_id    = tdvmdk_get_parent_id,
-	.td_validate_parent  = tdvmdk_validate_parent
-};
diff --git a/tools/blktap/drivers/bswap.h b/tools/blktap/drivers/bswap.h
deleted file mode 100644
index 5578913..0000000
--- a/tools/blktap/drivers/bswap.h
+++ /dev/null
@@ -1,178 +0,0 @@
-#ifndef BSWAP_H
-#define BSWAP_H
-
-//#include "config-host.h"
-
-#include <inttypes.h>
-
-#if defined(__NetBSD__)
-#include <sys/endian.h>
-#include <sys/types.h>
-#elif defined(__OpenBSD__)
-#include <machine/endian.h>
-#define bswap_16(x) swap16(x)
-#define bswap_32(x) swap32(x)
-#define bswap_64(x) swap64(x)
-#elif defined(__linux__)
-
-#include <byteswap.h>
-
-static inline uint16_t bswap16(uint16_t x)
-{
-    return bswap_16(x);
-}
-
-static inline uint32_t bswap32(uint32_t x) 
-{
-    return bswap_32(x);
-}
-
-static inline uint64_t bswap64(uint64_t x) 
-{
-    return bswap_64(x);
-}
-
-static inline void bswap16s(uint16_t *s)
-{
-    *s = bswap16(*s);
-}
-
-static inline void bswap32s(uint32_t *s)
-{
-    *s = bswap32(*s);
-}
-
-static inline void bswap64s(uint64_t *s)
-{
-    *s = bswap64(*s);
-}
-
-#endif
-
-#if defined(WORDS_BIGENDIAN)
-#define be_bswap(v, size) (v)
-#define le_bswap(v, size) bswap ## size(v)
-#define be_bswaps(v, size)
-#define le_bswaps(p, size) *p = bswap ## size(*p);
-#else
-#define le_bswap(v, size) (v)
-#define be_bswap(v, size) bswap ## size(v)
-#define le_bswaps(v, size)
-#define be_bswaps(p, size) *p = bswap ## size(*p);
-#endif
-
-#define CPU_CONVERT(endian, size, type)\
-static inline type endian ## size ## _to_cpu(type v)\
-{\
-    return endian ## _bswap(v, size);\
-}\
-\
-static inline type cpu_to_ ## endian ## size(type v)\
-{\
-    return endian ## _bswap(v, size);\
-}\
-\
-static inline void endian ## size ## _to_cpus(type *p)\
-{\
-    endian ## _bswaps(p, size)\
-}\
-\
-static inline void cpu_to_ ## endian ## size ## s(type *p)\
-{\
-    endian ## _bswaps(p, size)\
-}\
-\
-static inline type endian ## size ## _to_cpup(const type *p)\
-{\
-    return endian ## size ## _to_cpu(*p);\
-}\
-\
-static inline void cpu_to_ ## endian ## size ## w(type *p, type v)\
-{\
-     *p = cpu_to_ ## endian ## size(v);\
-}
-
-CPU_CONVERT(be, 16, uint16_t)
-CPU_CONVERT(be, 32, uint32_t)
-CPU_CONVERT(be, 64, uint64_t)
-
-CPU_CONVERT(le, 16, uint16_t)
-CPU_CONVERT(le, 32, uint32_t)
-CPU_CONVERT(le, 64, uint64_t)
-
-/* unaligned versions (optimized for frequent unaligned accesses)*/
-
-#if defined(__i386__) || defined(__powerpc__)
-
-#define cpu_to_le16wu(p, v) cpu_to_le16w(p, v)
-#define cpu_to_le32wu(p, v) cpu_to_le32w(p, v)
-#define le16_to_cpupu(p) le16_to_cpup(p)
-#define le32_to_cpupu(p) le32_to_cpup(p)
-
-#define cpu_to_be16wu(p, v) cpu_to_be16w(p, v)
-#define cpu_to_be32wu(p, v) cpu_to_be32w(p, v)
-
-#else
-
-static inline void cpu_to_le16wu(uint16_t *p, uint16_t v)
-{
-    uint8_t *p1 = (uint8_t *)p;
-
-    p1[0] = v;
-    p1[1] = v >> 8;
-}
-
-static inline void cpu_to_le32wu(uint32_t *p, uint32_t v)
-{
-    uint8_t *p1 = (uint8_t *)p;
-
-    p1[0] = v;
-    p1[1] = v >> 8;
-    p1[2] = v >> 16;
-    p1[3] = v >> 24;
-}
-
-static inline uint16_t le16_to_cpupu(const uint16_t *p)
-{
-    const uint8_t *p1 = (const uint8_t *)p;
-    return p1[0] | (p1[1] << 8);
-}
-
-static inline uint32_t le32_to_cpupu(const uint32_t *p)
-{
-    const uint8_t *p1 = (const uint8_t *)p;
-    return p1[0] | (p1[1] << 8) | (p1[2] << 16) | (p1[3] << 24);
-}
-
-static inline void cpu_to_be16wu(uint16_t *p, uint16_t v)
-{
-    uint8_t *p1 = (uint8_t *)p;
-
-    p1[0] = v >> 8;
-    p1[1] = v;
-}
-
-static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
-{
-    uint8_t *p1 = (uint8_t *)p;
-
-    p1[0] = v >> 24;
-    p1[1] = v >> 16;
-    p1[2] = v >> 8;
-    p1[3] = v;
-}
-
-#endif
-
-#ifdef WORDS_BIGENDIAN
-#define cpu_to_32wu cpu_to_be32wu
-#else
-#define cpu_to_32wu cpu_to_le32wu
-#endif
-
-#undef le_bswap
-#undef be_bswap
-#undef le_bswaps
-#undef be_bswaps
-
-#endif /* BSWAP_H */
diff --git a/tools/blktap/drivers/img2qcow.c b/tools/blktap/drivers/img2qcow.c
deleted file mode 100644
index 6b4fa70..0000000
--- a/tools/blktap/drivers/img2qcow.c
+++ /dev/null
@@ -1,282 +0,0 @@
-/* img2qcow.c
- *
- * Generates a qcow format disk and fills it from an existing image.
- *
- * (c) 2006 Julian Chesterfield and Andrew Warfield
- *
- * 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 <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include "tapdisk.h"
-#include "blk.h"
-
-#if 1
-#define DFPRINTF(_f, _a...) fprintf ( stderr, _f , ## _a )
-#else
-#define DFPRINTF(_f, _a...) ((void)0)
-#endif
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE	0
-#endif
-
-
-#define TAPDISK 1
-#define BLOCK_PROCESSSZ 4096
-
-static int maxfds, *io_fd, running = 1, complete = 0;
-static int returned_events = 0, submit_events = 0;
-static uint64_t prev = 0;
-static char output[25];
-
-static void print_bytes(void *ptr, int length)
-{
-  int i,k;
-  unsigned char *p = ptr;
-
-    DFPRINTF("Buf dump, length %d:\n",length);
-    for (k = 0; k < length; k++) {
-        DFPRINTF("%x",*p);
-        *p++;
-	if(k % 16 == 0) DFPRINTF("\n");
-        else if(k % 2 == 0) DFPRINTF(" ");	
-    }
-    DFPRINTF("\n");
-    return;
-}
-
-static void debug_output(uint64_t progress, uint64_t size)
-{
-	uint64_t blocks = size/20;
-
-	/*Output progress every 5% */	
-	if (progress/blocks > prev) {
-		memcpy(output+prev+1,"=>",2);
-		prev++;
-		DFPRINTF("\r%s     %llu%%", output, 
-			(long long)(prev-1)*5);
-	}
-	return;
-}
-
-static inline void LOCAL_FD_SET(fd_set *readfds) 
-{
-	FD_SET(io_fd[0], readfds);
-	maxfds = io_fd[0] + 1;
-	
-	return;
-}
-
-static int get_image_info(struct td_state *s, int fd)
-{
-	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
-	struct stat stat;
-
-	ret = fstat(fd, &stat);
-	if (ret != 0) {
-		DFPRINTF("ERROR: fstat failed, Couldn't stat image");
-		return -EINVAL;
-	}
-
-	if (S_ISBLK(stat.st_mode)) {
-		/*Accessing block device directly*/
-		if (blk_getimagesize(fd, &s->size) != 0)
-			return -EINVAL;
-
-		DFPRINTF("Image size: \n\tpre sector_shift  [%llu]\n\tpost "
-			"sector_shift [%llu]\n",
-			(long long unsigned)(s->size << SECTOR_SHIFT),
-			(long long unsigned)s->size);
-
-		/*Get the sector size*/
-		if (blk_getsectorsize(fd, &s->sector_size) != 0)
-			s->sector_size = DEFAULT_SECTOR_SIZE;
-
-	} else {
-		/*Local file? try fstat instead*/
-		s->size = (stat.st_size >> SECTOR_SHIFT);
-		s->sector_size = DEFAULT_SECTOR_SIZE;
-		DFPRINTF("Image size: [%llu]\n",
-			(long long unsigned)s->size);
-	}
-
-	return 0;
-}
-
-static int send_responses(struct disk_driver *dd, int res, uint64_t sec, 
-			  int nr_secs, int idx, void *private)
-{
-	if (res < 0) DFPRINTF("AIO FAILURE: res [%d]!\n",res);
-	
-	returned_events++;
-	
-	free(private);
-	return 0;
-}
-
-int main(int argc, char *argv[])
-{
-	struct disk_driver dd;
-	struct td_state *s;
-	int ret = -1, fd, len;
-	fd_set readfds;
-	struct timeval timeout;
-	uint64_t i;
-	char *buf;
-
-	if (argc != 3) {
-		fprintf(stderr, "Qcow-utils: v1.0.0\n");
-		fprintf(stderr, "usage: %s <QCOW FILENAME> <SRC IMAGE>\n", 
-			argv[0]);
-		exit(-1);
-	}
-
-	s = malloc(sizeof(struct td_state));
-	
-	/*Open image*/
-	fd = open(argv[2], O_RDONLY | O_LARGEFILE);
-	
-        if (fd == -1) {
-                DFPRINTF("Unable to open [%s], (err %d)!\n",argv[2],0 - errno);
-                exit(-1);
-        }
-	
-	get_image_info(s, fd);
-	
-	/*Create qcow file*/
-	ret = qcow_create(argv[1],s->size<<SECTOR_SHIFT,NULL,0);
-	
-	if (ret < 0) {
-		DFPRINTF("Unable to create QCOW file\n");
-		exit(-1);
-	} else DFPRINTF("Qcow file created: size %llu sectors\n",
-			(long long unsigned)s->size);
-	
-	dd.td_state = s;
-	dd.drv      = &tapdisk_qcow;
-	dd.private  = malloc(dd.drv->private_data_size);
-
-        /*Open qcow file*/
-        if (dd.drv->td_open(&dd, argv[1], 0)!=0) {
-		DFPRINTF("Unable to open Qcow file [%s]\n",argv[1]);
-		exit(-1);
-	}
-
-	io_fd = dd.io_fd;
-
-	/*Initialise the output string*/
-	memset(output,0x20,25);
-	output[0] = '[';
-	output[22] = ']';
-	output[23] = '\0';
-	DFPRINTF("%s",output);
-
-	i = 0;
-	while (running) {
-		timeout.tv_sec = 0;
-		
-		if (!complete) {
-			/*Read sector from image*/
-			if (lseek(fd, i, SEEK_SET) == (off_t)-1) {
-				DFPRINTF("Unable to access file offset %llu\n",
-				       (long long)i);
-				exit(-1);
-			}
-			
-			if( (ret = posix_memalign((void **)&buf, 
-						  BLOCK_PROCESSSZ, 
-						  BLOCK_PROCESSSZ)) != 0) {
-				DFPRINTF("Unable to read memalign buf (%d)\n",ret);
-				exit(-1);				
-			}
-		
-			/*We attempt to read 4k sized blocks*/
-			len = read(fd, buf, BLOCK_PROCESSSZ);
-			if (len < 512) {
-				DFPRINTF("Unable to read sector %llu\n",
-				       (long long unsigned) (i >> 9));
-				complete = 1;
-				continue;
-			}
-			
-			if (len % 512) {
-				len = (len >> 9) << 9;
-			}
-
-			ret = dd.drv->td_queue_write(&dd, i >> 9,
-						     len >> 9, buf, 
-						     send_responses, 0, buf);
-				
-			if (!ret) submit_events++;
-				
-			if (ret < 0) {
-				DFPRINTF("UNABLE TO WRITE block [%llu]\n",
-				       (long long unsigned) (i >> 9));
-			} else i += len;
-			
-			if (i >> 9 == s->size) complete = 1;
-
-			debug_output(i,s->size << 9);
-			
-			if ((submit_events % 10 == 0) || complete) 
-				dd.drv->td_submit(&dd);
-			timeout.tv_usec = 0;
-			
-		} else {
-			timeout.tv_usec = 1000;
-			if (!submit_events) running = 0;
-		}
-		
-
-		/*Check AIO FD*/
-		LOCAL_FD_SET(&readfds);
-                ret = select(maxfds + 1, &readfds, (fd_set *) 0,
-                             (fd_set *) 0, &timeout);
-			     
-		if (ret > 0) dd.drv->td_do_callbacks(&dd, 0);
-		if (complete && (returned_events == submit_events)) 
-			running = 0;
-	}
-	memcpy(output+prev+1,"=",1);
-	DFPRINTF("\r%s     100%%\nTRANSFER COMPLETE\n\n", output);
-        dd.drv->td_close(&dd);
-        free(dd.private);
-        free(s);
-		
-	return 0;
-}
diff --git a/tools/blktap/drivers/qcow-create.c b/tools/blktap/drivers/qcow-create.c
deleted file mode 100644
index 25abfcd..0000000
--- a/tools/blktap/drivers/qcow-create.c
+++ /dev/null
@@ -1,130 +0,0 @@
-/* qcow-create.c
- *
- * Generates a qcow format disk.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- *
- * 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 <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include "tapdisk.h"
-
-#if 1
-#define DFPRINTF(_f, _a...) fprintf ( stderr, _f , ## _a )
-#else
-#define DFPRINTF(_f, _a...) ((void)0)
-#endif
-
-#define MAX_NAME_LEN 1000
-
-static void help(void)
-{
-	fprintf(stderr, "Qcow-utils: v1.0.0\n");
-	fprintf(stderr, 
-		"usage: qcow-create [-h help] [-r reserve] [-f format] <SIZE(MB)> <FILENAME> "
-		"[<BACKING_FILENAME>]\n"); 
-	exit(-1);
-}
-
-int main(int argc, char *argv[])
-{
-	int ret = -1, c, backed = 0;
-	int sparse =  1;
-	char *fmt = "qcow";
-	uint64_t size;
-	char filename[MAX_NAME_LEN], bfilename[MAX_NAME_LEN];
-	char *tmpfile;
-
-        for(;;) {
-                c = getopt(argc, argv, "hrf");
-                if (c == -1)
-                        break;
-                switch(c) {
-                case 'h':
-                        help();
-                        exit(0);
-                        break;
-                case 'f':
-                        fmt = argv[optind++];
-                        break;
-                case 'r':
-			sparse = 0;
-			break;
-		default:
-			fprintf(stderr, "Unknown option\n");
-			help();
-		}
-	}
-
-	printf("Optind %d, argc %d\n", optind, argc);
-	if ( !(optind == (argc - 2) || optind == (argc - 3)) )
-		help();
-
-	size = atoi(argv[optind++]);
-	size = size << 20;
-
-	if (snprintf(filename, MAX_NAME_LEN, "%s",argv[optind++]) >=
-		MAX_NAME_LEN) {
-		fprintf(stderr,"Device name too long\n");
-		exit(-1);
-	}
-
-	if (optind != argc) {
-		/*Backing file argument*/
-		backed = 1;
-		if (snprintf(bfilename, MAX_NAME_LEN, "%s",argv[optind++]) >=
-			MAX_NAME_LEN) {
-			fprintf(stderr,"Device name too long\n");
-			exit(-1);
-		}
-	}
-
-    tmpfile = backed ? bfilename: NULL; 
-    if (!strcmp(fmt, "qcow")) {
-        ret = qcow_create(filename, size, tmpfile, sparse);
-    } else if(!strcmp(fmt, "qcow2")) {
-        ret = qcow2_create(filename, size, tmpfile, sparse);
-    } else {
-        fprintf(stderr,"Unsupport format:%s\n", fmt);
-        exit(-1);
-    } 
-    DFPRINTF("Creating file size %llu, name %s\n",(long long unsigned)size, filename);
-
-	if (ret < 0)
-		DPRINTF("Unable to create QCOW file\n");
-	else
-		DPRINTF("QCOW file successfully created\n");
-
-	return 0;
-}
diff --git a/tools/blktap/drivers/qcow2raw.c b/tools/blktap/drivers/qcow2raw.c
deleted file mode 100644
index 0fa88c1..0000000
--- a/tools/blktap/drivers/qcow2raw.c
+++ /dev/null
@@ -1,348 +0,0 @@
-/* qcow2raw.c
- *
- * Generates raw image data from an existing qcow image
- *
- * (c) 2006 Julian Chesterfield and Andrew Warfield
- *
- * 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 <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <inttypes.h>
-#include <unistd.h>
-#include <sys/statvfs.h>
-#include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <string.h>
-#include "tapdisk.h"
-#include "blk.h"
-
-#if 1
-#define DFPRINTF(_f, _a...) fprintf ( stderr, _f , ## _a )
-#else
-#define DFPRINTF(_f, _a...) ((void)0)
-#endif
-
-
-/* *BSD has no O_LARGEFILE */
-#ifndef O_LARGEFILE
-#define O_LARGEFILE 0
-#endif
-
-#define TAPDISK 1
-#define BLOCK_PROCESSSZ 4096
-
-static int maxfds, *qcowio_fd, *aio_fd, running = 1, complete = 0; 
-static int returned_read_events = 0, returned_write_events = 0;
-static int submit_events = 0;
-static uint32_t read_idx = 0, write_idx = 0;
-struct disk_driver ddqcow, ddaio;
-static uint64_t prev = 0, written = 0;
-static char output[25];
-
-static void print_bytes(void *ptr, int length)
-{
-  int i,k;
-  unsigned char *p = ptr;
-
-    DFPRINTF("Buf dump, length %d:\n",length);
-    for (k = 0; k < length; k++) {
-        DFPRINTF("%x",*p);
-        *p++;
-	if (k % 16 == 0) DFPRINTF("\n");
-        else if (k % 2 == 0) DFPRINTF(" ");	
-    }
-    DFPRINTF("\n");
-    return;
-}
-
-static void debug_output(uint64_t progress, uint64_t size)
-{
-	/*Output progress every 5% */	
-	uint64_t blocks = size/20;
-
-	if (progress/blocks > prev) {
-		memcpy(output+prev+1,"=>",2);
-		prev++;
-		DFPRINTF("\r%s     %llu%%", 
-			output, (long long)((prev-1)*5));
-	}
-	return;
-}
-
-static inline void LOCAL_FD_SET(fd_set *readfds) 
-{
-	FD_SET(qcowio_fd[0], readfds);
-	FD_SET(aio_fd[0], readfds);
-	
-	maxfds = (qcowio_fd[0] > aio_fd[0] ? qcowio_fd[0] : aio_fd[0]) + 1;
-	
-	return;
-}
-
-static int send_write_responses(struct disk_driver *dd, int res, uint64_t sec,
-				int nr_secs, int idx, void *private)
-{
-	if (res < 0) {
-		DFPRINTF("AIO FAILURE: res [%d]!\n",res);
-		return 0;
-	}
-	written += BLOCK_PROCESSSZ;
-	returned_write_events++;
-	write_idx = idx;
-
-	debug_output(written, dd->td_state->size << 9);
-	free(private);
-	return 0;
-}
-
-static int send_read_responses(struct disk_driver *dd, int res, uint64_t sec,
-			       int nr_secs, int idx, void *private)
-{
-	int ret;
-
-	if (res < 0) DFPRINTF("AIO FAILURE: res [%d]!\n",res);
-	
-	returned_read_events++;
-	read_idx = idx;
-	
-	ret = ddaio.drv->td_queue_write(&ddaio, idx, BLOCK_PROCESSSZ>>9, private, 
-					send_write_responses, idx, private);
-	if (ret != 0) {
-		DFPRINTF("ERROR in submitting queue write!\n");
-		return 0;
-	}
-
-	if ( (returned_read_events == submit_events) || 
-	     (returned_read_events % 10 == 0) ) {
-		ddaio.drv->td_submit(&ddaio);
-	}
-
-	return 0;
-}
-
-int main(int argc, char *argv[])
-{
-	int ret = -1, fd, len,input;
-	uint64_t size;
-	fd_set readfds;
-	struct timeval timeout;
-	uint64_t i;
-	char *buf;
-	struct stat finfo;
-
-	if (argc != 3) {
-		fprintf(stderr, "Qcow-utils: v1.0.0\n");
-		fprintf(stderr, "usage: %s <Dest File descriptor> "
-			"<Qcow SRC IMAGE>\n", 
-		       argv[0]);
-		exit(-1);
-	}
-
-	ddqcow.td_state = malloc(sizeof(struct td_state));
-	ddaio.td_state  = malloc(sizeof(struct td_state));
-	
-	/*Open qcow source file*/	
-	ddqcow.drv = &tapdisk_qcow;
-	ddqcow.private = malloc(ddqcow.drv->private_data_size);
-
-        if (ddqcow.drv->td_open(&ddqcow, argv[2], TD_RDONLY)!=0) {
-		DFPRINTF("Unable to open Qcow file [%s]\n",argv[2]);
-		exit(-1);
-	} else DFPRINTF("QCOW file opened, size %llu\n",
-		      (long long unsigned)ddqcow.td_state->size);
-
-	qcowio_fd = ddqcow.io_fd;
-
-        /*Setup aio destination file*/
-	ret = stat(argv[1],&finfo);
-	if (ret == -1) {
-		/*Check errno*/
-		switch(errno) {
-		case ENOENT:
-			/*File doesn't exist, create*/
-			fd = open(argv[1], 
-				  O_RDWR | O_LARGEFILE | O_CREAT, 0644);
-			if (fd < 0) {
-				DFPRINTF("ERROR creating file [%s] "
-					 "(errno %d)\n",
-				       argv[1], 0 - errno);
-				exit(-1);
-			}
-			if (ftruncate(fd, (off_t)ddqcow.td_state->size<<9) < 0) {
-				DFPRINTF("Unable to create file "
-					"[%s] of size %llu (errno %d). "
-					 "Exiting...\n",
-					argv[1], 
-					(long long unsigned)ddqcow.td_state->size<<9, 
-					0 - errno);
-				close(fd);
-				exit(-1);
-			}
-			close(fd);
-			break;
-		case  ENXIO:
-			DFPRINTF("ERROR Device [%s] does not exist\n",argv[1]);
-			exit(-1);
-		default: 
-			DFPRINTF("An error occurred opening Device [%s] "
-				 "(errno %d)\n",
-			       argv[1], 0 - errno);
-			exit(-1);
-		}
-	} else {		
-		fprintf(stderr, "WARNING: All existing data in "
-			"%s will be overwritten.\nDo you wish to continue? "
-			"(y or n)  ",
-			argv[1]);
-		if (getchar() != 'y') {
-			DFPRINTF("Exiting...\n");
-			exit(-1);
-		}
-		
-		/*TODO - Test the existing file or device for adequate space*/
-		fd = open(argv[1], O_RDWR | O_LARGEFILE);
-		if (fd < 0) {
-			DFPRINTF("ERROR: opening file [%s] (errno %d)\n",
-			       argv[1], 0 - errno);
-			exit(-1);
-		}
-
-		if (S_ISBLK(finfo.st_mode)) {
-			if (blk_getimagesize(fd, &size) != 0) {
-				close(fd);
-				return -1;
-			}
-
-			if (size < ddqcow.td_state->size<<9) {
-				DFPRINTF("ERROR: Not enough space on device "
-					"%s (%"PRIu64" bytes available, "
-					"%llu bytes required\n",
-					argv[1], size, 
-					(long long unsigned)ddqcow.td_state->size<<9);
-				close(fd);
-				exit(-1);				
-			}
-		} else {
-			if (ftruncate(fd, (off_t)ddqcow.td_state->size<<9) < 0) {
-				DFPRINTF("Unable to create file "
-					"[%s] of size %llu (errno %d). "
-					 "Exiting...\n",
-					argv[1], 
-					(long long unsigned)ddqcow.td_state->size<<9, 
-					 0 - errno);
-				close(fd);
-				exit(-1);
-			} else DFPRINTF("File [%s] truncated to length %llu "
-					"(%llu)\n", 
-				       argv[1], 
-				       (long long unsigned)ddqcow.td_state->size<<9, 
-				       (long long unsigned)ddqcow.td_state->size);
-		}
-		close(fd);
-	}
-
-	/*Open aio destination file*/	
-	ddaio.drv = &tapdisk_aio;
-	ddaio.private = malloc(ddaio.drv->private_data_size);
-
-        if (ddaio.drv->td_open(&ddaio, argv[1], 0)!=0) {
-		DFPRINTF("Unable to open Qcow file [%s]\n", argv[1]);
-		exit(-1);
-	}
-
-	aio_fd = ddaio.io_fd;
-
-	/*Initialise the output string*/
-	memset(output,0x20,25);
-	output[0] = '[';
-	output[22] = ']';
-	output[23] = '\0';
-	DFPRINTF("%s",output);
-
-	i = 0;
-	while (running) {
-		timeout.tv_sec = 0;
-		
-		if (!complete) {
-			/*Read Pages from qcow image*/
-			if ( (ret = posix_memalign((void **)&buf, 
-						   BLOCK_PROCESSSZ, 
-						   BLOCK_PROCESSSZ))
-			     != 0) {
-				DFPRINTF("Unable to alloc memory (%d)\n",ret);
-				exit(-1);				
-			}
-		
-			/*Attempt to read 4k sized blocks*/
-			submit_events++;
-			ret = ddqcow.drv->td_queue_read(&ddqcow, i>>9,
-							BLOCK_PROCESSSZ>>9, buf, 
-							send_read_responses, i>>9, buf);
-
-			if (ret < 0) {
-				DFPRINTF("UNABLE TO READ block [%llu]\n",
-				       (long long unsigned)i);
-				exit(-1);
-			} else {
-				i += BLOCK_PROCESSSZ;
-			}
-
-			if (i >= ddqcow.td_state->size<<9) {
-				complete = 1;
-			}
-			
-			if ((submit_events % 10 == 0) || complete) 
-				ddqcow.drv->td_submit(&ddqcow);
-			timeout.tv_usec = 0;
-			
-		} else {
-			timeout.tv_usec = 1000;
-			if (!submit_events) running = 0;
-		}
-		
-
-		/*Check AIO FD*/
-		LOCAL_FD_SET(&readfds);
-                ret = select(maxfds + 1, &readfds, (fd_set *) 0,
-                             (fd_set *) 0, &timeout);
-			     
-		if (ret > 0) {
-			if (FD_ISSET(qcowio_fd[0], &readfds)) 
-				ddqcow.drv->td_do_callbacks(&ddqcow, 0);
-			if (FD_ISSET(aio_fd[0], &readfds)) 
-				ddaio.drv->td_do_callbacks(&ddaio, 0);
-		}
-		if (complete && (returned_write_events == submit_events)) 
-			running = 0;
-	}
-	memcpy(output+prev+1,"=",1);
-	DFPRINTF("\r%s     100%%\nTRANSFER COMPLETE\n\n", output);
-		
-	return 0;
-}
diff --git a/tools/blktap/drivers/tapaio.c b/tools/blktap/drivers/tapaio.c
deleted file mode 100644
index 140c44a..0000000
--- a/tools/blktap/drivers/tapaio.c
+++ /dev/null
@@ -1,357 +0,0 @@
-/*
- * Copyright (c) 2006 Andrew Warfield and Julian Chesterfield
- * Copyright (c) 2007 Red Hat, 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; 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 "tapaio.h"
-#include "tapdisk.h"
-#include <unistd.h>
-#include <errno.h>
-#include <string.h>
-#include <stdlib.h>
-
-/**
- * We used a kernel patch to return an fd associated with the AIO context
- * so that we can concurrently poll on synchronous and async descriptors.
- * This is signalled by passing 1 as the io context to io_setup.
- */
-#define REQUEST_ASYNC_FD 1
-
-/*
- * If we don't have any way to do epoll on aio events in a normal kernel,
- * wait for aio events in a separate thread and return completion status
- * that via a pipe that can be waited on normally.
- *
- * To keep locking problems between the completion thread and the submit
- * thread to a minimum, there's a handshake which allows only one thread
- * to be doing work on the completion queue at a time:
- *
- * 1) main thread sends completion thread a command via the command pipe;
- * 2) completion thread waits for aio events and returns the number
- *    received on the completion pipe
- * 3) main thread processes the received ctx->aio_events events
- * 4) loop back to 1) to let the completion thread refill the aio_events
- *    buffer.
- *
- * This workaround needs to disappear once the kernel provides a single
- * mechanism for waiting on both aio and normal fd wakeups.
- */
-static void *
-tap_aio_completion_thread(void *arg)
-{
-	tap_aio_internal_context_t *ctx = (tap_aio_internal_context_t *) arg;
-	int command;
-	int nr_events;
-	int rc;
-
-	while (1) {
-		rc = read(ctx->command_fd[0], &command, sizeof(command));
-
-		do {
-			rc = io_getevents(ctx->aio_ctx, 1,
-					  ctx->max_aio_events, ctx->aio_events,
-					  NULL);
-			if (rc) {
-				nr_events = rc;
-				rc = write(ctx->completion_fd[1], &nr_events,
-					   sizeof(nr_events));
-			}
-		} while (!rc);
-	}
-	return NULL;
-}
-
-void
-tap_aio_continue(tap_aio_internal_context_t *ctx)
-{
-        int cmd = 0;
-
-        if (!ctx->poll_in_thread)
-                return;
-
-        if (write(ctx->command_fd[1], &cmd, sizeof(cmd)) < 0)
-                DPRINTF("Cannot write to command pipe\n");
-}
-
-static int
-tap_aio_setup(tap_aio_internal_context_t *ctx,
-              struct io_event *aio_events,
-              int max_aio_events)
-{
-        int ret;
-
-        ctx->aio_events = aio_events;
-        ctx->max_aio_events = max_aio_events;
-        ctx->poll_in_thread = 0;
-
-        ctx->aio_ctx = (io_context_t) REQUEST_ASYNC_FD;
-        ret = io_setup(ctx->max_aio_events, &ctx->aio_ctx);
-        if (ret < 0 && ret != -EINVAL)
-                return ret;
-        else if (ret > 0) {
-                ctx->pollfd = ret;
-                return ctx->pollfd;
-        }
-
-        ctx->aio_ctx = (io_context_t) 0;
-        ret = io_setup(ctx->max_aio_events, &ctx->aio_ctx);
-        if (ret < 0)
-                return ret;
-
-        if ((ret = pipe(ctx->command_fd)) < 0) {
-                DPRINTF("Unable to create command pipe\n");
-                return -1;
-        }
-        if ((ret = pipe(ctx->completion_fd)) < 0) {
-                DPRINTF("Unable to create completion pipe\n");
-                return -1;
-        }
-
-        if ((ret = pthread_create(&ctx->aio_thread, NULL,
-                                  tap_aio_completion_thread, ctx)) != 0) {
-                DPRINTF("Unable to create completion thread\n");
-                return -1;
-        }
-
-        ctx->pollfd = ctx->completion_fd[0];
-        ctx->poll_in_thread = 1;
-
-        tap_aio_continue(ctx);
-
-        return 0;
-}
-
-int
-tap_aio_get_events(tap_aio_internal_context_t *ctx)
-{
-        int nr_events = 0;
-
-        if (!ctx->poll_in_thread)
-                nr_events = io_getevents(ctx->aio_ctx, 1,
-                                         ctx->max_aio_events, ctx->aio_events, NULL);
-        else {
-		int r;
-		r = read(ctx->completion_fd[0], &nr_events, sizeof(nr_events));
-		if (r < 0) {
-			if (errno == EAGAIN || errno == EINTR)
-				return 0;
-			/* This is pretty bad, we'll probably spin */
-			DPRINTF("Aargh, read completion_fd failed: %s",
-				strerror(errno));
-		} else if (r != sizeof(nr_events)) {
-			/* Should never happen because sizeof(nr_events)
-			 * fits in the guaranteed atomic pipe write size.
-			 * Blundering on is slightly nicer than asserting */
-			DPRINTF("Aargh, read completion_fd short read %d", r);
-		}
-	}
-
-        return nr_events;
-}
-
-int tap_aio_more_events(tap_aio_internal_context_t *ctx)
-{
-        return io_getevents(ctx->aio_ctx, 0,
-                            ctx->max_aio_events, ctx->aio_events, NULL);
-}
-
-int tap_aio_init(tap_aio_context_t *ctx, uint64_t sectors,
-		int max_aio_reqs)
-{
-	int i, ret;
-	long ioidx;
-
-	ctx->iocb_list = NULL;
-	ctx->pending_aio = NULL;
-	ctx->aio_events = NULL;
-	ctx->iocb_free = NULL;
-	ctx->iocb_queue = NULL;
-
-	/*Initialize Locking bitmap*/
-	ctx->sector_lock = calloc(1, sectors);
-		
-	if (!ctx->sector_lock) {
-		DPRINTF("Failed to allocate sector lock\n");
-		goto fail;
-	}
-
-
-	/* Initialize AIO */
-	ctx->max_aio_reqs = max_aio_reqs;
-	ctx->iocb_free_count = ctx->max_aio_reqs;
-	ctx->iocb_queued	 = 0;
-
-	if (!(ctx->iocb_list = malloc(sizeof(struct iocb) * ctx->max_aio_reqs)) ||
-		!(ctx->pending_aio = malloc(sizeof(struct pending_aio) * ctx->max_aio_reqs)) ||
-		!(ctx->aio_events = malloc(sizeof(struct io_event) * ctx->max_aio_reqs)) ||
-		!(ctx->iocb_free = malloc(sizeof(struct iocb *) * ctx->max_aio_reqs)) ||
-		!(ctx->iocb_queue = malloc(sizeof(struct iocb *) * ctx->max_aio_reqs))) 
-	{
-		DPRINTF("Failed to allocate AIO structs (max_aio_reqs = %d)\n",
-				ctx->max_aio_reqs);
-		goto fail;
-	}
-
-	ret = tap_aio_setup(&ctx->aio_ctx, ctx->aio_events, ctx->max_aio_reqs);
-	if (ret < 0) {
-		if (ret == -EAGAIN) {
-			DPRINTF("Couldn't setup AIO context.  If you are "
-				"trying to concurrently use a large number "
-				"of blktap-based disks, you may need to "
-				"increase the system-wide aio request limit. "
-				"(e.g. 'echo echo 1048576 > /proc/sys/fs/"
-				"aio-max-nr')\n");
-		} else {
-			DPRINTF("Couldn't setup AIO context.\n");
-		}
-		goto fail;
-	}
-
-	for (i=0;i<ctx->max_aio_reqs;i++)
-		ctx->iocb_free[i] = &ctx->iocb_list[i];
-
-	DPRINTF("AIO state initialised\n");
-
-	return 0;
-
-fail:
-	return -1;
-}
-
-void tap_aio_free(tap_aio_context_t *ctx)
-{
-	if (ctx->sector_lock)
-		free(ctx->sector_lock);
-	if (ctx->iocb_list)
-		free(ctx->iocb_list);
-	if (ctx->pending_aio)
-		free(ctx->pending_aio);
-	if (ctx->aio_events)
-		free(ctx->aio_events);
-	if (ctx->iocb_free)
-		free(ctx->iocb_free);
-	if (ctx->iocb_queue)
-		free(ctx->iocb_queue);
-}
-
-/*TODO: Fix sector span!*/
-int tap_aio_can_lock(tap_aio_context_t *ctx, uint64_t sector)
-{
-	return (ctx->sector_lock[sector] ? 0 : 1);
-}
-
-int tap_aio_lock(tap_aio_context_t *ctx, uint64_t sector)
-{
-	return ++ctx->sector_lock[sector];
-}
-
-void tap_aio_unlock(tap_aio_context_t *ctx, uint64_t sector)
-{
-	if (!ctx->sector_lock[sector]) return;
-
-	--ctx->sector_lock[sector];
-	return;
-}
-
-
-int tap_aio_read(tap_aio_context_t *ctx, int fd, int size, 
-		uint64_t offset, char *buf, td_callback_t cb,
-		int id, uint64_t sector, void *private)
-{
-	struct	 iocb *io;
-	struct	 pending_aio *pio;
-	long	 ioidx;
-
-	if (ctx->iocb_free_count == 0)
-		return -ENOMEM;
-
-	io = ctx->iocb_free[--ctx->iocb_free_count];
-
-	ioidx = IOCB_IDX(ctx, io);
-	pio = &ctx->pending_aio[ioidx];
-	pio->cb = cb;
-	pio->id = id;
-	pio->private = private;
-	pio->nb_sectors = size/512;
-	pio->buf = buf;
-	pio->sector = sector;
-
-	io_prep_pread(io, fd, buf, size, offset);
-	io->data = (void *)ioidx;
-
-	ctx->iocb_queue[ctx->iocb_queued++] = io;
-
-	return 0;
-}
-
-int tap_aio_write(tap_aio_context_t *ctx, int fd, int size,
-		uint64_t offset, char *buf, td_callback_t cb,
-		int id, uint64_t sector, void *private)
-{
-	struct	 iocb *io;
-	struct	 pending_aio *pio;
-	long	 ioidx;
-
-	if (ctx->iocb_free_count == 0)
-		return -ENOMEM;
-
-	io = ctx->iocb_free[--ctx->iocb_free_count];
-
-	ioidx = IOCB_IDX(ctx, io);
-	pio = &ctx->pending_aio[ioidx];
-	pio->cb = cb;
-	pio->id = id;
-	pio->private = private;
-	pio->nb_sectors = size/512;
-	pio->buf = buf;
-	pio->sector = sector;
-
-	io_prep_pwrite(io, fd, buf, size, offset);
-	io->data = (void *)ioidx;
-
-	ctx->iocb_queue[ctx->iocb_queued++] = io;
-
-	return 0;
-}
-
-int tap_aio_submit(tap_aio_context_t *ctx)
-{
-	int ret;
-
-	if (!ctx->iocb_queued)
-		return 0;
-
-	ret = io_submit(ctx->aio_ctx.aio_ctx, ctx->iocb_queued, ctx->iocb_queue);
-
-	/* XXX: TODO: Handle error conditions here. */
-
-	/* Success case: */
-	ctx->iocb_queued = 0;
-
-	return 0;
-}
-
diff --git a/tools/blktap/drivers/tapaio.h b/tools/blktap/drivers/tapaio.h
deleted file mode 100644
index 27d3881..0000000
--- a/tools/blktap/drivers/tapaio.h
+++ /dev/null
@@ -1,108 +0,0 @@
-/*
- * Copyright (c) 2006 Andrew Warfield and Julian Chesterfield
- * Copyright (c) 2007 Red Hat, 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; 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 __TAPAIO_H__
-#define __TAPAIO_H__
-
-#include <pthread.h>
-#include <libaio.h>
-#include <stdint.h>
-
-#include "tapdisk.h"
-
-#define IOCB_IDX(_ctx, _io) ((_io) - (_ctx)->iocb_list)
-
-struct tap_aio_internal_context {
-        io_context_t     aio_ctx;
-
-        struct io_event *aio_events;
-        int              max_aio_events;
-
-        pthread_t        aio_thread;
-        int              command_fd[2];
-        int              completion_fd[2];
-        int              pollfd;
-        unsigned int     poll_in_thread : 1;
-};
-	
-
-typedef struct tap_aio_internal_context tap_aio_internal_context_t;
-
-
-struct pending_aio {
-	td_callback_t cb;
-	int id;
-	void *private;
-	int nb_sectors;
-	char *buf;
-	uint64_t sector;
-};
-
-	
-struct tap_aio_context {
-	tap_aio_internal_context_t    aio_ctx;
-
-	int                  max_aio_reqs;
-	struct iocb         *iocb_list;
-	struct iocb        **iocb_free;
-	struct pending_aio  *pending_aio;
-	int                  iocb_free_count;
-	struct iocb        **iocb_queue;
-	int	             iocb_queued;
-	struct io_event     *aio_events;
-
-	/* Locking bitmap for AIO reads/writes */
-	uint8_t *sector_lock;		   
-};
-
-typedef struct tap_aio_context tap_aio_context_t;
-
-void tap_aio_continue   (tap_aio_internal_context_t *ctx);
-int  tap_aio_get_events (tap_aio_internal_context_t *ctx);
-int  tap_aio_more_events(tap_aio_internal_context_t *ctx);
-
-
-int tap_aio_init(tap_aio_context_t *ctx, uint64_t sectors,
-		int max_aio_reqs);
-void tap_aio_free(tap_aio_context_t *ctx);
-
-int tap_aio_can_lock(tap_aio_context_t *ctx, uint64_t sector);
-int tap_aio_lock(tap_aio_context_t *ctx, uint64_t sector);
-void tap_aio_unlock(tap_aio_context_t *ctx, uint64_t sector);
-
-
-int tap_aio_read(tap_aio_context_t *ctx, int fd, int size, 
-		uint64_t offset, char *buf, td_callback_t cb,
-		int id, uint64_t sector, void *private);
-int tap_aio_write(tap_aio_context_t *ctx, int fd, int size,
-		uint64_t offset, char *buf, td_callback_t cb,
-		int id, uint64_t sector, void *private);
-int tap_aio_submit(tap_aio_context_t *ctx);
-
-#endif /* __TAPAIO_H__ */
diff --git a/tools/blktap/drivers/tapdisk.c b/tools/blktap/drivers/tapdisk.c
deleted file mode 100644
index 19cd777..0000000
--- a/tools/blktap/drivers/tapdisk.c
+++ /dev/null
@@ -1,872 +0,0 @@
-/* tapdisk.c
- *
- * separate disk process, spawned by blktapctrl. Inherits code from driver 
- * plugins
- * 
- * Copyright (c) 2005 Julian Chesterfield and Andrew Warfield.
- *
- */
-
-#define MSG_SIZE 4096
-#define TAPDISK
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <sys/mman.h>
-#include <fcntl.h>
-#include <string.h>
-#include <signal.h>
-#include <sys/stat.h>
-#include <sys/types.h>
-#include <sys/poll.h>
-#include <unistd.h>
-#include <errno.h>
-#include <pthread.h>
-#include <time.h>
-#include <err.h>
-#include <poll.h>
-#include <sys/statvfs.h>
-#include <sys/ioctl.h>
-#include "blktaplib.h"
-#include "tapdisk.h"
-
-#if 1                                                                        
-#define ASSERT(_p) \
-    if ( !(_p) ) { DPRINTF("Assertion '%s' failed, line %d, file %s", #_p , \
-    __LINE__, __FILE__); *(int*)0=0; }
-#else
-#define ASSERT(_p) ((void)0)
-#endif 
-
-#define INPUT 0
-#define OUTPUT 1
-
-static int maxfds, fds[2], run = 1;
-
-static pid_t process;
-int connected_disks = 0;
-fd_list_entry_t *fd_start = NULL;
-
-int do_cow_read(struct disk_driver *dd, blkif_request_t *req, 
-		int sidx, uint64_t sector, int nr_secs);
-
-#define td_for_each_disk(tds, drv) \
-        for (drv = tds->disks; drv != NULL; drv = drv->next)
-
-static void usage(void) 
-{
-	fprintf(stderr, "blktap-utils: v1.0.0\n");
-	fprintf(stderr, "usage: tapdisk <READ fifo> <WRITE fifo>\n");
-        exit(-1);
-}
-
-static void daemonize(void)
-{
-	int i;
-
-	if (getppid()==1) return; /* already a daemon */
-	if (fork() != 0) exit(0);
-
-#if 0
-	/*Set new program session ID and close all descriptors*/
-	setsid();
-	for (i = getdtablesize(); i >= 0; --i) close(i);
-
-	/*Send all I/O to /dev/null */
-	i = open("/dev/null",O_RDWR);
-	dup(i); 
-	dup(i);
-#endif
-	return;
-}
-
-static void free_driver(struct disk_driver *d)
-{
-	if (d->name)
-		free(d->name);
-	if (d->private)
-		free(d->private);
-	free(d);
-}
-
-static void unmap_disk(struct td_state *s)
-{
-	tapdev_info_t *info = s->ring_info;
-	struct disk_driver *dd, *tmp;
-	fd_list_entry_t *entry;
-
-	dd = s->disks;
-	while (dd) {
-		tmp = dd->next;
-		dd->drv->td_close(dd);
-		free_driver(dd);
-		dd = tmp;
-	}
-
-	if (info != NULL && info->mem > 0)
-	        munmap(info->mem, getpagesize() * BLKTAP_MMAP_REGION_SIZE);
-
-	entry = s->fd_entry;
-	*entry->pprev = entry->next;
-	if (entry->next)
-		entry->next->pprev = entry->pprev;
-
-	close(info->fd);
-
-	free(s->fd_entry);
-	free(s->blkif);
-	free(s->ring_info);
-	free(s);
-
-	return;
-}
-
-static void sig_handler(int sig)
-{
-	/*Received signal to close. If no disks are active, we close app.*/
-
-	if (connected_disks < 1) run = 0;	
-}
-
-static inline int LOCAL_FD_SET(fd_set *readfds)
-{
-	fd_list_entry_t *ptr;
-	struct disk_driver *dd;
-
-	ptr = fd_start;
-	while (ptr != NULL) {
-		if (ptr->tap_fd) {
-			FD_SET(ptr->tap_fd, readfds);
-			td_for_each_disk(ptr->s, dd) {
-				if (dd->io_fd[READ]) 
-					FD_SET(dd->io_fd[READ], readfds);
-				maxfds = (dd->io_fd[READ] > maxfds ? 
-					  dd->io_fd[READ] : maxfds);
-			}
-			maxfds = (ptr->tap_fd > maxfds ? ptr->tap_fd : maxfds);
-		}
-		ptr = ptr->next;
-	}
-
-	return 0;
-}
-
-static inline fd_list_entry_t *add_fd_entry(int tap_fd, struct td_state *s)
-{
-	fd_list_entry_t **pprev, *entry;
-	int i;
-
-	DPRINTF("Adding fd_list_entry\n");
-
-	/*Add to linked list*/
-	s->fd_entry   = entry = malloc(sizeof(fd_list_entry_t));
-	entry->tap_fd = tap_fd;
-	entry->s      = s;
-	entry->next   = NULL;
-
-	pprev = &fd_start;
-	while (*pprev != NULL)
-		pprev = &(*pprev)->next;
-
-	*pprev = entry;
-	entry->pprev = pprev;
-
-	return entry;
-}
-
-static inline struct td_state *get_state(int cookie)
-{
-	fd_list_entry_t *ptr;
-
-	ptr = fd_start;
-	while (ptr != NULL) {
-		if (ptr->cookie == cookie) return ptr->s;
-		ptr = ptr->next;
-	}
-	return NULL;
-}
-
-static struct tap_disk *get_driver(int drivertype)
-{
-	/* blktapctrl has passed us the driver type */
-
-	return dtypes[drivertype]->drv;
-}
-
-static struct td_state *state_init(void)
-{
-	int i;
-	struct td_state *s;
-	blkif_t *blkif;
-
-	s = malloc(sizeof(struct td_state));
-	blkif = s->blkif = malloc(sizeof(blkif_t));
-	s->ring_info = calloc(1, sizeof(tapdev_info_t));
-
-	for (i = 0; i < MAX_REQUESTS; i++) {
-		blkif->pending_list[i].secs_pending = 0;
-		blkif->pending_list[i].submitting = 0;
-	}
-
-	return s;
-}
-
-static int map_new_dev(struct td_state *s, int minor)
-{
-	int tap_fd;
-	tapdev_info_t *info = s->ring_info;
-	char *devname;
-	fd_list_entry_t *ptr;
-	int page_size;
-
-	if (asprintf(&devname,"%s/%s%d", BLKTAP_DEV_DIR, BLKTAP_DEV_NAME, minor) == -1)
-		return -1;
-	tap_fd = open(devname, O_RDWR);
-	if (tap_fd == -1) 
-	{
-		DPRINTF("open failed on dev %s!",devname);
-		goto fail;
-	} 
-	info->fd = tap_fd;
-
-	/*Map the shared memory*/
-	page_size = getpagesize();
-	info->mem = mmap(0, page_size * BLKTAP_MMAP_REGION_SIZE, 
-			  PROT_READ | PROT_WRITE, MAP_SHARED, info->fd, 0);
-	if ((long int)info->mem == -1) 
-	{
-		DPRINTF("mmap failed on dev %s!\n",devname);
-		goto fail;
-	}
-
-	/* assign the rings to the mapped memory */ 
-	info->sring = (blkif_sring_t *)((unsigned long)info->mem);
-	BACK_RING_INIT(&info->fe_ring, info->sring, page_size);
-	
-	info->vstart = 
-	        (unsigned long)info->mem + (BLKTAP_RING_PAGES * page_size);
-
-	ioctl(info->fd, BLKTAP_IOCTL_SENDPID, process );
-	ioctl(info->fd, BLKTAP_IOCTL_SETMODE, BLKTAP_MODE_INTERPOSE );
-	free(devname);
-
-	/*Update the fd entry*/
-	ptr = fd_start;
-	while (ptr != NULL) {
-		if (s == ptr->s) {
-			ptr->tap_fd = tap_fd;
-			break;
-		}
-		ptr = ptr->next;
-	}	
-
-	return minor;
-
- fail:
-	free(devname);
-	return -1;
-}
-
-static struct disk_driver *disk_init(struct td_state *s, 
-				     struct tap_disk *drv, 
-				     char *name, td_flag_t flags)
-{
-	struct disk_driver *dd;
-
-	dd = calloc(1, sizeof(struct disk_driver));
-	if (!dd)
-		return NULL;
-	
-	dd->private = malloc(drv->private_data_size);
-	if (!dd->private) {
-		free(dd);
-		return NULL;
-	}
-
-	dd->drv      = drv;
-	dd->td_state = s;
-	dd->name     = name;
-	dd->flags    = flags;
-
-	return dd;
-}
-
-static int open_disk(struct td_state *s, 
-		     struct tap_disk *drv, char *path, td_flag_t flags)
-{
-	int err;
-	char *dup;
-	td_flag_t pflags;
-	struct disk_id id;
-	struct disk_driver *d;
-
-	dup = strdup(path);
-	if (!dup)
-		return -ENOMEM;
-
-	memset(&id, 0, sizeof(struct disk_id));
-	s->disks = d = disk_init(s, drv, dup, flags);
-	if (!d)
-		return -ENOMEM;
-
-	err = drv->td_open(d, path, flags);
-	if (err) {
-		free_driver(d);
-		s->disks = NULL;
-		return -ENOMEM;
-	}
-	pflags = flags | TD_RDONLY;
-
-	/* load backing files as necessary */
-	while ((err = d->drv->td_get_parent_id(d, &id)) == 0) {
-		struct disk_driver *new;
-		
-		if (id.drivertype > MAX_DISK_TYPES || 
-		    !get_driver(id.drivertype) || !id.name)
-			goto fail;
-
-		dup = strdup(id.name);
-		if (!dup)
-			goto fail;
-
-		new = disk_init(s, get_driver(id.drivertype), dup, pflags);
-		if (!new)
-			goto fail;
-
-		err = new->drv->td_open(new, new->name, pflags);
-		if (err)
-			goto fail;
-
-		err = d->drv->td_validate_parent(d, new, 0);
-		if (err) {
-			d->next = new;
-			goto fail;
-		}
-
-		d = d->next = new;
-		free(id.name);
-	}
-
-	s->info |= ((flags & TD_RDONLY) ? VDISK_READONLY : 0);
-
-	if (err >= 0)
-		return 0;
-
- fail:
-	DPRINTF("failed opening disk\n");
-	if (id.name)
-		free(id.name);
-	d = s->disks;
-	while (d) {
-		struct disk_driver *tmp = d->next;
-		d->drv->td_close(d);
-		free_driver(d);
-		d = tmp;
-	}
-	s->disks = NULL;
-	return -1;
-}
-
-static int read_msg(char *buf)
-{
-	int length, len, msglen, tap_fd, *io_fd;
-	char *ptr, *path;
-	image_t *img;
-	msg_hdr_t *msg;
-	msg_newdev_t *msg_dev;
-	msg_pid_t *msg_pid;
-	struct tap_disk *drv;
-	int ret = -1;
-	struct td_state *s = NULL;
-	fd_list_entry_t *entry;
-
-	length = read(fds[READ], buf, MSG_SIZE);
-
-	if (length > 0 && length >= sizeof(msg_hdr_t)) 
-	{
-		msg = (msg_hdr_t *)buf;
-		DPRINTF("Tapdisk: Received msg, len %d, type %d, UID %d\n",
-			length,msg->type,msg->cookie);
-
-		switch (msg->type) {
-		case CTLMSG_PARAMS: 			
-			ptr = buf + sizeof(msg_hdr_t);
-			len = (length - sizeof(msg_hdr_t));
-			path = calloc(1, len);
-			
-			memcpy(path, ptr, len); 
-			DPRINTF("Received CTLMSG_PARAMS: [%s]\n", path);
-
-			/*Assign driver*/
-			drv = get_driver(msg->drivertype);
-			if (drv == NULL)
-				goto params_done;
-				
-			DPRINTF("Loaded driver: name [%s], type [%d]\n",
-				drv->disk_type, msg->drivertype);
-
-			/* Allocate the disk structs */
-			s = state_init();
-			if (s == NULL)
-				goto params_done;
-
-			/*Open file*/
-			ret = open_disk(s, drv, path, 
-					((msg->readonly) ? TD_RDONLY : 0));
-			if (ret)
-				goto params_done;
-
-			entry = add_fd_entry(0, s);
-			entry->cookie = msg->cookie;
-			DPRINTF("Entered cookie %d\n", entry->cookie);
-			
-			memset(buf, 0x00, MSG_SIZE); 
-			
-		params_done:
-			if (ret == 0) {
-				msglen = sizeof(msg_hdr_t) + sizeof(image_t);
-				msg->type = CTLMSG_IMG;
-				img = (image_t *)(buf + sizeof(msg_hdr_t));
-				img->size = s->size;
-				img->secsize = s->sector_size;
-				img->info = s->info;
-			} else {
-				msglen = sizeof(msg_hdr_t);
-				msg->type = CTLMSG_IMG_FAIL;
-				msg->len = msglen;
-			}
-			len = write(fds[WRITE], buf, msglen);
-			free(path);
-			return 1;
-			
-		case CTLMSG_NEWDEV:
-			msg_dev = (msg_newdev_t *)(buf + sizeof(msg_hdr_t));
-
-			s = get_state(msg->cookie);
-			DPRINTF("Retrieving state, cookie %d.....[%s]\n",
-				msg->cookie, (s == NULL ? "FAIL":"OK"));
-			if (s != NULL) {
-				ret = ((map_new_dev(s, msg_dev->devnum) 
-					== msg_dev->devnum ? 0: -1));
-				connected_disks++;
-			}	
-
-			memset(buf, 0x00, MSG_SIZE); 
-			msglen = sizeof(msg_hdr_t);
-			msg->type = (ret == 0 ? CTLMSG_NEWDEV_RSP 
-				              : CTLMSG_NEWDEV_FAIL);
-			msg->len = msglen;
-
-			len = write(fds[WRITE], buf, msglen);
-			return 1;
-
-		case CTLMSG_CLOSE:
-			s = get_state(msg->cookie);
-			if (s) unmap_disk(s);
-			
-			connected_disks--;
-			sig_handler(SIGINT);
-
-			return 1;			
-
-		case CTLMSG_PID:
-			memset(buf, 0x00, MSG_SIZE);
-			msglen = sizeof(msg_hdr_t) + sizeof(msg_pid_t);
-			msg->type = CTLMSG_PID_RSP;
-			msg->len = msglen;
-
-			msg_pid = (msg_pid_t *)(buf + sizeof(msg_hdr_t));
-			process = getpid();
-			msg_pid->pid = process;
-
-			len = write(fds[WRITE], buf, msglen);
-			return 1;
-
-		default:
-			return 0;
-		}
-	}
-	return 0;
-}
-
-static inline int write_rsp_to_ring(struct td_state *s, blkif_response_t *rsp)
-{
-	tapdev_info_t *info = s->ring_info;
-	blkif_response_t *rsp_d;
-	
-	rsp_d = RING_GET_RESPONSE(&info->fe_ring, info->fe_ring.rsp_prod_pvt);
-	memcpy(rsp_d, rsp, sizeof(blkif_response_t));
-	info->fe_ring.rsp_prod_pvt++;
-	
-	return 0;
-}
-
-static inline void kick_responses(struct td_state *s)
-{
-	tapdev_info_t *info = s->ring_info;
-
-	if (info->fe_ring.rsp_prod_pvt != info->fe_ring.sring->rsp_prod) 
-	{
-		RING_PUSH_RESPONSES(&info->fe_ring);
-		ioctl(info->fd, BLKTAP_IOCTL_KICK_FE);
-	}
-}
-
-static void io_done(struct disk_driver *dd, int sid)
-{
-	struct tap_disk *drv = dd->drv;
-
-	if (!run) return; /*We have received signal to close*/
-
-	if (sid > MAX_IOFD || drv->td_do_callbacks(dd, sid) > 0)
-		kick_responses(dd->td_state);
-
-	return;
-}
-
-static inline uint64_t
-segment_start(blkif_request_t *req, int sidx)
-{
-	int i;
-	uint64_t start = req->sector_number;
-
-	for (i = 0; i < sidx; i++) 
-		start += (req->seg[i].last_sect - req->seg[i].first_sect + 1);
-
-	return start;
-}
-
-uint64_t sends, responds;
-static int send_responses(struct disk_driver *dd, int res, 
-		   uint64_t sector, int nr_secs, int idx, void *private)
-{
-	pending_req_t   *preq;
-	blkif_request_t *req;
-	int responses_queued = 0;
-	struct td_state *s = dd->td_state;
-	blkif_t *blkif = s->blkif;
-	int sidx = (int)(long)private, secs_done = nr_secs;
-
-	if ( (idx > MAX_REQUESTS-1) )
-	{
-		DPRINTF("invalid index returned(%u)!\n", idx);
-		return 0;
-	}
-	preq = &blkif->pending_list[idx];
-	req  = &preq->req;
-
-	if (res == BLK_NOT_ALLOCATED) {
-		res = do_cow_read(dd, req, sidx, sector, nr_secs);
-		if (res >= 0) {
-			secs_done = res;
-			res = 0;
-		} else
-			secs_done = 0;
-	}
-
-	preq->secs_pending -= secs_done;
-
-	if (res == -EBUSY && preq->submitting) 
-		return -EBUSY;  /* propagate -EBUSY back to higher layers */
-	if (res) 
-		preq->status = BLKIF_RSP_ERROR;
-	
-	if (!preq->submitting && preq->secs_pending == 0) 
-	{
-		blkif_request_t tmp;
-		blkif_response_t *rsp;
-
-		tmp = preq->req;
-		rsp = (blkif_response_t *)req;
-		
-		rsp->id = tmp.id;
-		rsp->operation = tmp.operation;
-		rsp->status = preq->status;
-		
-		write_rsp_to_ring(s, rsp);
-		responses_queued++;
-	}
-	return responses_queued;
-}
-
-int do_cow_read(struct disk_driver *dd, blkif_request_t *req, 
-		int sidx, uint64_t sector, int nr_secs)
-{
-	char *page;
-	int ret, early;
-	uint64_t seg_start, seg_end;
-	struct td_state  *s = dd->td_state;
-	tapdev_info_t *info = s->ring_info;
-	struct disk_driver *parent = dd->next;
-	
-	seg_start = segment_start(req, sidx);
-	seg_end   = seg_start + req->seg[sidx].last_sect + 1;
-	
-	ASSERT(sector >= seg_start && sector + nr_secs <= seg_end);
-
-	page  = (char *)MMAP_VADDR(info->vstart, 
-				   (unsigned long)req->id, sidx);
-	page += (req->seg[sidx].first_sect << SECTOR_SHIFT);
-	page += ((sector - seg_start) << SECTOR_SHIFT);
-
-	if (!parent) {
-		memset(page, 0, nr_secs << SECTOR_SHIFT);
-		return nr_secs;
-	}
-
-	/* reissue request to backing file */
-	ret = parent->drv->td_queue_read(parent, sector, nr_secs,
-					 page, send_responses, 
-					 req->id, (void *)(long)sidx);
-	if (ret > 0)
-		parent->early += ret;
-
-	return ((ret >= 0) ? 0 : ret);
-}
-
-static void get_io_request(struct td_state *s)
-{
-	RING_IDX          rp, rc, j, i;
-	blkif_request_t  *req;
-	int idx, nsects, ret;
-	uint64_t sector_nr;
-	char *page;
-	int early = 0; /* count early completions */
-	struct disk_driver *dd = s->disks;
-	struct tap_disk *drv   = dd->drv;
-	blkif_t *blkif = s->blkif;
-	tapdev_info_t *info = s->ring_info;
-	int page_size = getpagesize();
-
-	if (!run) return; /*We have received signal to close*/
-
-	rp = info->fe_ring.sring->req_prod; 
-	xen_rmb();
-	for (j = info->fe_ring.req_cons; j != rp; j++)
-	{
-		int done = 0, start_seg = 0; 
-
-		req = NULL;
-		req = RING_GET_REQUEST(&info->fe_ring, j);
-		++info->fe_ring.req_cons;
-		
-		if (req == NULL) continue;
-
-		idx = req->id;
-
-		if (info->busy.req) {
-			/* continue where we left off last time */
-			ASSERT(info->busy.req == req);
-			start_seg = info->busy.seg_idx;
-			sector_nr = segment_start(req, start_seg);
-			info->busy.seg_idx = 0;
-			info->busy.req     = NULL;
-		} else {
-			ASSERT(blkif->pending_list[idx].secs_pending == 0);
-			memcpy(&blkif->pending_list[idx].req, 
-			       req, sizeof(*req));
-			blkif->pending_list[idx].status = BLKIF_RSP_OKAY;
-			blkif->pending_list[idx].submitting = 1;
-			sector_nr = req->sector_number;
-		}
-
-		if ((dd->flags & TD_RDONLY) && 
-		    (req->operation == BLKIF_OP_WRITE)) {
-			blkif->pending_list[idx].status = BLKIF_RSP_ERROR;
-			goto send_response;
-		}
-
-		for (i = start_seg; i < req->nr_segments; i++) {
-			nsects = req->seg[i].last_sect - 
-				 req->seg[i].first_sect + 1;
-	
-			if ((req->seg[i].last_sect >= page_size >> 9) ||
-			    (nsects <= 0))
-				continue;
-
-			page  = (char *)MMAP_VADDR(info->vstart, 
-						   (unsigned long)req->id, i);
-			page += (req->seg[i].first_sect << SECTOR_SHIFT);
-
-			if (sector_nr >= s->size) {
-				DPRINTF("Sector request failed:\n");
-				DPRINTF("%s request, idx [%d,%d] size [%llu], "
-					"sector [%llu,%llu]\n",
-					(req->operation == BLKIF_OP_WRITE ? 
-					 "WRITE" : "READ"),
-					idx,i,
-					(long long unsigned) 
-						nsects<<SECTOR_SHIFT,
-					(long long unsigned) 
-						sector_nr<<SECTOR_SHIFT,
-					(long long unsigned) sector_nr);
-				continue;
-			}
-
-			blkif->pending_list[idx].secs_pending += nsects;
-
-			switch (req->operation) 
-			{
-			case BLKIF_OP_WRITE:
-				ret = drv->td_queue_write(dd, sector_nr,
-							  nsects, page, 
-							  send_responses,
-							  idx, (void *)(long)i);
-				if (ret > 0) dd->early += ret;
-				else if (ret == -EBUSY) {
-					/* put req back on queue */
-					--info->fe_ring.req_cons;
-					info->busy.req     = req;
-					info->busy.seg_idx = i;
-					goto out;
-				}
-				break;
-			case BLKIF_OP_READ:
-				ret = drv->td_queue_read(dd, sector_nr,
-							 nsects, page, 
-							 send_responses,
-							 idx, (void *)(long)i);
-				if (ret > 0) dd->early += ret;
-				else if (ret == -EBUSY) {
-					/* put req back on queue */
-					--info->fe_ring.req_cons;
-					info->busy.req     = req;
-					info->busy.seg_idx = i;
-					goto out;
-				}
-				break;
-			default:
-				DPRINTF("Unknown block operation\n");
-				break;
-			}
-			sector_nr += nsects;
-		}
-	send_response:
-		blkif->pending_list[idx].submitting = 0;
-		/* force write_rsp_to_ring for synchronous case */
-		if (blkif->pending_list[idx].secs_pending == 0)
-			dd->early += send_responses(dd, 0, 0, 0, idx, 
-						    (void *)(long)0);
-	}
-
- out:
-	/*Batch done*/
-	td_for_each_disk(s, dd) {
-		dd->early += dd->drv->td_submit(dd);
-		if (dd->early > 0) {
-			io_done(dd, MAX_IOFD + 1);
-			dd->early = 0;
-		}
-	}
-
-	return;
-}
-
-int main(int argc, char *argv[])
-{
-	int len, msglen, ret;
-	char *p, *buf;
-	fd_set readfds, writefds;	
-	fd_list_entry_t *ptr;
-	struct td_state *s;
-	char openlogbuf[128];
-
-	if (argc != 3) usage();
-
-	daemonize();
-
-	snprintf(openlogbuf, sizeof(openlogbuf), "TAPDISK[%d]", getpid());
-	openlog(openlogbuf, LOG_CONS|LOG_ODELAY, LOG_DAEMON);
-	/*Setup signal handlers*/
-	signal (SIGBUS, sig_handler);
-	signal (SIGINT, sig_handler);
-
-	/*Open the control channel*/
-	fds[READ]  = open(argv[1],O_RDWR|O_NONBLOCK);
-	fds[WRITE] = open(argv[2],O_RDWR|O_NONBLOCK);
-
-	if ( (fds[READ] < 0) || (fds[WRITE] < 0) ) 
-	{
-		DPRINTF("FD open failed [%d,%d]\n", fds[READ], fds[WRITE]);
-		exit(-1);
-	}
-
-	buf = calloc(MSG_SIZE, 1);
-
-	if (buf == NULL) 
-        {
-		DPRINTF("ERROR: allocating memory.\n");
-		exit(-1);
-	}
-
-	while (run) 
-        {
-		ret = 0;
-		FD_ZERO(&readfds);
-		FD_SET(fds[READ], &readfds);
-		maxfds = fds[READ];
-
-		/*Set all tap fds*/
-		LOCAL_FD_SET(&readfds);
-
-		/*Wait for incoming messages*/
-		ret = select(maxfds + 1, &readfds, (fd_set *) 0, 
-			     (fd_set *) 0, NULL);
-
-		if (ret > 0) 
-		{
-			ptr = fd_start;
-			while (ptr != NULL) {
-				int progress_made = 0;
-				struct disk_driver *dd;
-				tapdev_info_t *info = ptr->s->ring_info;
-
-				td_for_each_disk(ptr->s, dd) {
-					if (dd->io_fd[READ] &&
-					    FD_ISSET(dd->io_fd[READ], 
-						     &readfds)) {
-						io_done(dd, READ);
-						progress_made = 1;
-					}
-				}
-
-				/* completed io from above may have 
-				 * queued new requests on chained disks */
-				if (progress_made) {
-					td_for_each_disk(ptr->s, dd) {
-						dd->early += 
-							dd->drv->td_submit(dd);
-						if (dd->early > 0) {
-							io_done(dd, 
-								MAX_IOFD + 1);
-							dd->early = 0;
-						}
-					}
-				}
-
-				if (FD_ISSET(ptr->tap_fd, &readfds) ||
-				    (info->busy.req && progress_made))
-					get_io_request(ptr->s);
-
-				ptr = ptr->next;
-			}
-
-			if (FD_ISSET(fds[READ], &readfds))
-				read_msg(buf);
-		}
-	}
-	free(buf);
-	close(fds[READ]);
-	close(fds[WRITE]);
-
-	ptr = fd_start;
-	while (ptr != NULL) {
-		s = ptr->s;
-		unmap_disk(s);
-		close(ptr->tap_fd);
-		ptr = ptr->next;
-	}
-	closelog();
-
-	return 0;
-}
diff --git a/tools/blktap/drivers/tapdisk.h b/tools/blktap/drivers/tapdisk.h
deleted file mode 100644
index f3e165a..0000000
--- a/tools/blktap/drivers/tapdisk.h
+++ /dev/null
@@ -1,259 +0,0 @@
-/* tapdisk.h
- *
- * Generic disk interface for blktap-based image adapters.
- *
- * (c) 2006 Andrew Warfield and Julian Chesterfield
- * 
- * Some notes on the tap_disk interface:
- * 
- * tap_disk aims to provide a generic interface to easily implement new 
- * types of image accessors.  The structure-of-function-calls is similar
- * to disk interfaces used in qemu/denali/etc, with the significant 
- * difference being the expectation of asynchronous rather than synchronous 
- * I/O.  The asynchronous interface is intended to allow lots of requests to
- * be pipelined through a disk, without the disk requiring any of its own
- * threads of control.  As such, a batch of requests is delivered to the disk
- * using:
- * 
- *    td_queue_[read,write]()
- * 
- * and passing in a completion callback, which the disk is responsible for 
- * tracking.  The end of a back is marked with a call to:
- * 
- *    td_submit()
- * 
- * The disk implementation must provide a file handle, which is used to 
- * indicate that it needs to do work.  tapdisk will add this file handle 
- * (returned from td_get_fd()) to it's poll set, and will call into the disk
- * using td_do_callbacks() whenever there is data pending.
- * 
- * Two disk implementations demonstrate how this interface may be used to 
- * implement disks with both asynchronous and synchronous calls.  block-aio.c
- * maps this interface down onto the linux libaio calls, while block-sync uses 
- * normal posix read/write.
- * 
- * A few things to realize about the sync case, which doesn't need to defer 
- * io completions:
- * 
- *   - td_queue_[read,write]() call read/write directly, and then call the 
- *     callback immediately.  The MUST then return a value greater than 0
- *     in order to tell tapdisk that requests have finished early, and to 
- *     force responses to be kicked to the clents.
- * 
- *   - The fd used for poll is an otherwise unused pipe, which allows poll to 
- *     be safely called without ever returning anything.
- *
- * NOTE: tapdisk uses the number of sectors submitted per request as a 
- * ref count.  Plugins must use the callback function to communicate the
- * completion--or error--of every sector submitted to them.
- *
- * td_get_parent_id returns:
- *     0 if parent id successfully retrieved
- *     TD_NO_PARENT if no parent exists
- *     -errno on error
- */
-
-#ifndef TAPDISK_H_
-#define TAPDISK_H_
-
-#include <stdint.h>
-#include <syslog.h>
-#include <stdio.h>
-#include "blktaplib.h"
-
-/*If enabled, log all debug messages to syslog*/
-#if 1
-#define DPRINTF(_f, _a...) syslog( LOG_DEBUG, __FILE__ ":%d: " _f , __LINE__, ## _a )
-#else
-#define DPRINTF(_f, _a...) ((void)0)
-#endif
-
-/* Things disks need to know about, these should probably be in a higher-level
- * header. */
-#define MAX_SEGMENTS_PER_REQ    11
-#define SECTOR_SHIFT             9
-#define DEFAULT_SECTOR_SIZE    512
-
-#define MAX_IOFD                 2
-
-#define BLK_NOT_ALLOCATED       99
-#define TD_NO_PARENT             1
-
-typedef uint32_t td_flag_t;
-
-#define TD_RDONLY                1
-
-struct td_state;
-struct tap_disk;
-
-struct disk_id {
-	char *name;
-	int drivertype;
-};
-
-struct disk_driver {
-	int early;
-	char *name;
-	void *private;
-	td_flag_t flags;
-	int io_fd[MAX_IOFD];
-	struct tap_disk *drv;
-	struct td_state *td_state;
-	struct disk_driver *next;
-};
-
-/* This structure represents the state of an active virtual disk.           */
-struct td_state {
-	struct disk_driver *disks;
-	void *blkif;
-	void *image;
-	void *ring_info;
-	void *fd_entry;
-	uint64_t sector_size;
-	uint64_t size;
-	unsigned int       info;
-};
-
-/* Prototype of the callback to activate as requests complete.              */
-typedef int (*td_callback_t)(struct disk_driver *dd, int res, uint64_t sector,
-			     int nb_sectors, int id, void *private);
-
-/* Structure describing the interface to a virtual disk implementation.     */
-/* See note at the top of this file describing this interface.              */
-struct tap_disk {
-	const char *disk_type;
-	int private_data_size;
-	int (*td_open)           (struct disk_driver *dd, 
-				  const char *name, td_flag_t flags);
-	int (*td_queue_read)     (struct disk_driver *dd, uint64_t sector,
-				  int nb_sectors, char *buf, td_callback_t cb,
-				  int id, void *prv);
-	int (*td_queue_write)    (struct disk_driver *dd, uint64_t sector,
-				  int nb_sectors, char *buf, td_callback_t cb, 
-				  int id, void *prv);
-	int (*td_submit)         (struct disk_driver *dd);
-	int (*td_close)          (struct disk_driver *dd);
-	int (*td_do_callbacks)   (struct disk_driver *dd, int sid);
-	int (*td_get_parent_id)  (struct disk_driver *dd, struct disk_id *id);
-	int (*td_validate_parent)(struct disk_driver *dd, 
-				  struct disk_driver *p, td_flag_t flags);
-};
-
-typedef struct disk_info {
-	int  idnum;
-	char name[50];       /* e.g. "RAMDISK" */
-	char handle[10];     /* xend handle, e.g. 'ram' */
-	int  single_handler; /* is there a single controller for all */
-	                     /* instances of disk type? */
-	int  use_ioemu;      /* backend provider: 0 = tapdisk; 1 = ioemu */
-
-#ifdef TAPDISK
-	struct tap_disk *drv;	
-#endif
-} disk_info_t;
-
-void debug_fe_ring(struct td_state *s);
-
-extern struct tap_disk tapdisk_aio;
-extern struct tap_disk tapdisk_sync;
-extern struct tap_disk tapdisk_vmdk;
-extern struct tap_disk tapdisk_ram;
-extern struct tap_disk tapdisk_qcow;
-extern struct tap_disk tapdisk_qcow2;
-
-
-/*Define Individual Disk Parameters here */
-static disk_info_t aio_disk = {
-	DISK_TYPE_AIO,
-	"raw image (aio)",
-	"aio",
-	0,
-	0,
-#ifdef TAPDISK
-	&tapdisk_aio,
-#endif
-};
-
-static disk_info_t sync_disk = {
-	DISK_TYPE_SYNC,
-	"raw image (sync)",
-	"sync",
-	0,
-	0,
-#ifdef TAPDISK
-	&tapdisk_sync,
-#endif
-};
-
-static disk_info_t vmdk_disk = {
-	DISK_TYPE_VMDK,
-	"vmware image (vmdk)",
-	"vmdk",
-	1,
-	0,
-#ifdef TAPDISK
-	&tapdisk_vmdk,
-#endif
-};
-
-static disk_info_t ram_disk = {
-	DISK_TYPE_RAM,
-	"ramdisk image (ram)",
-	"ram",
-	1,
-	0,
-#ifdef TAPDISK
-	&tapdisk_ram,
-#endif
-};
-
-static disk_info_t qcow_disk = {
-	DISK_TYPE_QCOW,
-	"qcow disk (qcow)",
-	"qcow",
-	0,
-	0,
-#ifdef TAPDISK
-	&tapdisk_qcow,
-#endif
-};
-
-static disk_info_t qcow2_disk = {
-	DISK_TYPE_QCOW2,
-	"qcow2 disk (qcow2)",
-	"qcow2",
-	0,
-	0,
-#ifdef TAPDISK
-	&tapdisk_qcow2,
-#endif
-};
-
-/*Main disk info array */
-static disk_info_t *dtypes[] = {
-	&aio_disk,
-	&sync_disk,
-	&vmdk_disk,
-	&ram_disk,
-	&qcow_disk,
-	&qcow2_disk,
-};
-
-typedef struct driver_list_entry {
-	struct blkif *blkif;
-	struct driver_list_entry **pprev, *next;
-} driver_list_entry_t;
-
-typedef struct fd_list_entry {
-	int cookie;
-	int  tap_fd;
-	struct td_state *s;
-	struct fd_list_entry **pprev, *next;
-} fd_list_entry_t;
-
-int qcow_create(const char *filename, uint64_t total_size,
-		const char *backing_file, int flags);
-
-int qcow2_create(const char *filename, uint64_t total_size,
-		const char *backing_file, int flags);
-#endif /*TAPDISK_H_*/
diff --git a/tools/blktap/lib/Makefile b/tools/blktap/lib/Makefile
deleted file mode 100644
index 8852c46..0000000
--- a/tools/blktap/lib/Makefile
+++ /dev/null
@@ -1,60 +0,0 @@
-XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-MAJOR    = 3.0
-MINOR    = 0
-SONAME   = libblktap.so.$(MAJOR)
-
-CFLAGS   += -I.
-CFLAGS   += $(CFLAGS_libxenctrl)
-CFLAGS   += $(CFLAGS_libxenstore)
-LDLIBS   += $(LDLIBS_libxenstore)
-
-SRCS     :=
-SRCS     += xenbus.c blkif.c xs_api.c
-
-CFLAGS   += -Werror
-CFLAGS   += -Wno-unused
-CFLAGS   += -fPIC
-# get asprintf():
-CFLAGS   += -D _GNU_SOURCE
-
-OBJS     = $(SRCS:.c=.o)
-OBJS_PIC = $(SRCS:.c=.opic)
-IBINS   :=
-
-LIB      = libblktap.a
-LIB_SO   = libblktap.so.$(MAJOR).$(MINOR)
-
-.PHONY: all
-all: $(LIB) $(LIB_SO)
-
-.PHONY: install
-install: all
-	$(INSTALL_DIR) $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
-	$(INSTALL_PROG) $(LIB_SO) $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DATA) $(LIB) $(DESTDIR)$(LIBDIR)
-	ln -sf libblktap.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libblktap.so.$(MAJOR)
-	ln -sf libblktap.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libblktap.so
-	$(INSTALL_DATA) blktaplib.h $(DESTDIR)$(INCLUDEDIR)
-
-.PHONY: clean
-clean:
-	rm -rf *.a *.so* *.o *.opic *.rpm $(LIB) $(LIB_SO) *~ $(DEPS) xen TAGS
-
-libblktap.so.$(MAJOR).$(MINOR): $(OBJS_PIC) 
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,$(SONAME) $(SHLIB_LDFLAGS) \
-	      -o $@ $^ $(LDLIBS)
-	ln -sf libblktap.so.$(MAJOR).$(MINOR) libblktap.so.$(MAJOR)
-	ln -sf libblktap.so.$(MAJOR) libblktap.so
-
-libblktap.a: $(OBJS) 
-	$(AR) rc $@ $^
-
-.PHONY: TAGS
-TAGS:
-	etags -t $(SRCS) *.h
-
--include $(DEPS)
-
diff --git a/tools/blktap/lib/blkif.c b/tools/blktap/lib/blkif.c
deleted file mode 100644
index 9a19596..0000000
--- a/tools/blktap/lib/blkif.c
+++ /dev/null
@@ -1,185 +0,0 @@
-/*
- * tools/blktap_user/blkif.c
- * 
- * The blkif interface for blktap.  A blkif describes an in-use virtual disk.
- * (c) 2005 Andrew Warfield and Julian Chesterfield
- *
- * 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 <stdio.h>
-#include <stdlib.h>
-#include <errno.h>
-#include <string.h>
-#include <err.h>
-#include <unistd.h>
-
-#include "blktaplib.h"
-
-#if 0
-#define DPRINTF(_f, _a...) printf ( _f , ## _a )
-#else
-#define DPRINTF(_f, _a...) ((void)0)
-#endif
-
-#define BLKIF_HASHSZ 1024
-#define BLKIF_HASH(_d,_h) (((int)(_d)^(int)(_h))&(BLKIF_HASHSZ-1))
-
-static blkif_t      *blkif_hash[BLKIF_HASHSZ];
-
-blkif_t *blkif_find_by_handle(domid_t domid, unsigned int handle)
-{
-	blkif_t *blkif = blkif_hash[BLKIF_HASH(domid, handle)];
-	while ( (blkif != NULL) && 
-		((blkif->domid != domid) || (blkif->handle != handle)) )
-		blkif = blkif->hash_next;
-	return blkif;
-}
-
-blkif_t *alloc_blkif(domid_t domid)
-{
-	blkif_t *blkif;
-	DPRINTF("Alloc_blkif called [%d]\n",domid);
-	blkif = (blkif_t *)malloc(sizeof(blkif_t));
-	if (!blkif)
-		return NULL;
-	memset(blkif, 0, sizeof(*blkif));
-	blkif->domid = domid;
-	blkif->devnum = -1;
-	return blkif;
-}
-
-/*Controller callbacks*/
-static int (*new_devmap_hook)(blkif_t *blkif) = NULL;
-void register_new_devmap_hook(int (*fn)(blkif_t *blkif))
-{
-	new_devmap_hook = fn;
-}
-
-static int (*new_unmap_hook)(blkif_t *blkif) = NULL;
-void register_new_unmap_hook(int (*fn)(blkif_t *blkif))
-{
-	new_unmap_hook = fn;
-}
-
-static int (*new_blkif_hook)(blkif_t *blkif) = NULL;
-void register_new_blkif_hook(int (*fn)(blkif_t *blkif))
-{
-	new_blkif_hook = fn;
-}
-
-int blkif_init(blkif_t *blkif, long int handle, long int pdev, 
-               long int readonly)
-{
-	domid_t domid;
-	blkif_t **pblkif;
-	int devnum;
-	
-	if (blkif == NULL)
-		return -EINVAL;
-	
-	domid = blkif->domid;
-	blkif->handle   = handle;
-	blkif->pdev     = pdev;
-	blkif->readonly = readonly;
-	
-	/*
-	 * Call out to the new_blkif_hook. 
-	 * The tap application should define this,
-	 * and it should return having set blkif->ops
-	 * 
-	 */
-	if (new_blkif_hook == NULL)
-	{
-		DPRINTF("Probe detected a new blkif, but no new_blkif_hook!");
-		return -1;
-	}
-	if (new_blkif_hook(blkif)!=0) {
-		DPRINTF("BLKIF: Image open failed\n");
-		return -1;
-	}
-	
-	/* Now wire it in. */
-	pblkif = &blkif_hash[BLKIF_HASH(domid, handle)];
-	DPRINTF("Created hash entry: %d [%d,%ld]\n", 
-		BLKIF_HASH(domid, handle), domid, handle);
-	
-	while ( *pblkif != NULL )
-	{
-		if ( ((*pblkif)->domid == domid) && 
-		     ((*pblkif)->handle == handle) )
-		{
-			DPRINTF("Could not create blkif: already exists\n");
-			return -1;
-		}
-		pblkif = &(*pblkif)->hash_next;
-	}
-	blkif->hash_next = NULL;
-	*pblkif = blkif;
-	
-	if (new_devmap_hook == NULL)
-	{
-		DPRINTF("Probe setting up new blkif but no devmap hook!");
-		return -1;
-	}
-	
-	devnum = new_devmap_hook(blkif);
-	if (devnum == -1)
-		return -1;
-	blkif->devnum = devnum;
-	
-	return 0;
-}
-
-void free_blkif(blkif_t *blkif)
-{
-	blkif_t **pblkif, *curs;
-	image_t *image;
-	
-	pblkif = &blkif_hash[BLKIF_HASH(blkif->domid, blkif->handle)];
-	while ( (curs = *pblkif) != NULL )
-	{
-		if ( blkif == curs )
-		{
-			*pblkif = curs->hash_next;
-		}
-		pblkif = &curs->hash_next;
-	}
-	if (blkif != NULL) {
-		if ((image=(image_t *)blkif->prv)!=NULL) {
-			free(blkif->prv);
-		}
-		if (blkif->info!=NULL) {
-			free(blkif->info);
-		}
-		if (new_unmap_hook != NULL) new_unmap_hook(blkif);
-		free(blkif);
-	}
-}
-
-void __init_blkif(void)
-{    
-	memset(blkif_hash, 0, sizeof(blkif_hash));
-}
diff --git a/tools/blktap/lib/blktaplib.h b/tools/blktap/lib/blktaplib.h
deleted file mode 100644
index a80e518..0000000
--- a/tools/blktap/lib/blktaplib.h
+++ /dev/null
@@ -1,240 +0,0 @@
-/* blktaplib.h
- *
- * Blktap library userspace code.
- *
- * (c) 2005 Andrew Warfield and Julian Chesterfield
- *
- * 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 __BLKTAPLIB_H__
-#define __BLKTAPLIB_H__
-
-#include <xenctrl.h>
-#include <sys/param.h>
-#include <sys/user.h>
-#include <xen/xen.h>
-#include <xen/io/blkif.h>
-#include <xen/io/ring.h>
-#include <xenstore.h>
-#include <sys/types.h>
-#include <unistd.h>
-
-#define BLK_RING_SIZE __CONST_RING_SIZE(blkif, XC_PAGE_SIZE)
-
-/* size of the extra VMA area to map in attached pages. */
-#define BLKTAP_VMA_PAGES BLK_RING_SIZE
-
-/* blktap IOCTLs: These must correspond with the blktap driver ioctls*/
-#define BLKTAP_IOCTL_KICK_FE         1
-#define BLKTAP_IOCTL_KICK_BE         2
-#define BLKTAP_IOCTL_SETMODE         3
-#define BLKTAP_IOCTL_SENDPID	     4
-#define BLKTAP_IOCTL_NEWINTF	     5
-#define BLKTAP_IOCTL_MINOR	     6
-#define BLKTAP_IOCTL_MAJOR	     7
-#define BLKTAP_QUERY_ALLOC_REQS      8
-#define BLKTAP_IOCTL_FREEINTF	     9
-#define BLKTAP_IOCTL_NEWINTF_EXT     50
-#define BLKTAP_IOCTL_PRINT_IDXS      100   
-
-/* blktap switching modes: (Set with BLKTAP_IOCTL_SETMODE)             */
-#define BLKTAP_MODE_PASSTHROUGH      0x00000000  /* default            */
-#define BLKTAP_MODE_INTERCEPT_FE     0x00000001
-#define BLKTAP_MODE_INTERCEPT_BE     0x00000002
-
-#define BLKTAP_MODE_INTERPOSE \
-           (BLKTAP_MODE_INTERCEPT_FE | BLKTAP_MODE_INTERCEPT_BE)
-
-static inline int BLKTAP_MODE_VALID(unsigned long arg)
-{
-	return (
-		( arg == BLKTAP_MODE_PASSTHROUGH  ) ||
-		( arg == BLKTAP_MODE_INTERCEPT_FE ) ||
-		( arg == BLKTAP_MODE_INTERPOSE    ) );
-}
-
-#define MAX_REQUESTS            BLK_RING_SIZE
-
-#define BLKTAP_IOCTL_KICK 1
-#define MAX_PENDING_REQS	BLK_RING_SIZE
-#define BLKTAP_DEV_DIR   "/dev/xen"
-#define BLKTAP_DEV_NAME  "blktap"
-#define BLKTAP_DEV_MINOR 0
-#define BLKTAP_CTRL_DIR   "/var/run/tap"
-
-extern int blktap_major;
-
-#define BLKTAP_RING_PAGES       1 /* Front */
-#define BLKTAP_MMAP_REGION_SIZE (BLKTAP_RING_PAGES + MMAP_PAGES)
-
-struct blkif;
-
-typedef struct {
-	blkif_request_t  req;
-	struct blkif    *blkif;
-	int              submitting;
-	int              secs_pending;
-        int16_t          status;
-} pending_req_t;
-
-struct blkif_ops {
-	unsigned long long (*get_size)(struct blkif *blkif);
-	unsigned long (*get_secsize)(struct blkif *blkif);
-	unsigned int (*get_info)(struct blkif *blkif);
-};
-
-typedef struct blkif {
-	domid_t domid;
-	long int handle;
-	
-	long int pdev;
-	long int readonly;
-	
-	enum { DISCONNECTED, DISCONNECTING, CONNECTED } state;
-	
-	struct blkif_ops *ops;
-	struct blkif *hash_next;
-	
-	void *prv;  /* device-specific data */
-	void *info; /*Image parameter passing */
-	pending_req_t pending_list[MAX_REQUESTS];
-	int devnum;
-	int fds[2];
-	int be_id;
-	int major;
-	int minor;
-	pid_t tappid;
-	int drivertype;
-	uint16_t cookie;
-} blkif_t;
-
-typedef struct blkif_info {
-	char *params;
-} blkif_info_t;
-
-void register_new_devmap_hook(int (*fn)(blkif_t *blkif));
-void register_new_unmap_hook(int (*fn)(blkif_t *blkif));
-void register_new_blkif_hook(int (*fn)(blkif_t *blkif));
-blkif_t *blkif_find_by_handle(domid_t domid, unsigned int handle);
-blkif_t *alloc_blkif(domid_t domid);
-int blkif_init(blkif_t *blkif, long int handle, long int pdev, 
-               long int readonly);
-void free_blkif(blkif_t *blkif);
-void __init_blkif(void);
-
-typedef struct busy_state {
-	int seg_idx;
-	blkif_request_t *req;
-} busy_state_t;
-
-typedef struct tapdev_info {
-	int fd;
-	char *mem;
-	blkif_sring_t *sring;
-	blkif_back_ring_t  fe_ring;
-	unsigned long vstart;
-	blkif_t *blkif;
-	busy_state_t busy;
-} tapdev_info_t;
-
-typedef struct domid_translate {
-	unsigned short domid;
-	unsigned short busid;
-} domid_translate_t ;
-
-typedef struct domid_translate_ext {
-	unsigned short domid;
-	uint32_t busid;
-} domid_translate_ext_t ;
-
-typedef struct image {
-	unsigned long long size;
-	unsigned long secsize;
-	unsigned int info;
-} image_t;
-
-/* 16-byte message header, immediately followed by message payload. */
-typedef struct msg_hdr {
-	uint16_t   type;
-	uint16_t   len;
-	uint16_t   drivertype;
-	uint16_t   cookie;
-	uint8_t    readonly;
-	uint8_t    pad[7];
-} msg_hdr_t;
-
-typedef struct msg_newdev {
-	uint8_t     devnum;
-	uint16_t    domid;
-} msg_newdev_t;
-
-typedef struct msg_pid {
-	pid_t     pid;
-} msg_pid_t;
-
-#define READ 0
-#define WRITE 1
-
-/*Control Messages between manager and tapdev*/
-#define CTLMSG_PARAMS      1
-#define CTLMSG_IMG         2
-#define CTLMSG_IMG_FAIL    3
-#define CTLMSG_NEWDEV      4
-#define CTLMSG_NEWDEV_RSP  5
-#define CTLMSG_NEWDEV_FAIL 6
-#define CTLMSG_CLOSE       7
-#define CTLMSG_CLOSE_RSP   8
-#define CTLMSG_PID         9
-#define CTLMSG_PID_RSP     10
-
-/* disk driver types */
-#define MAX_DISK_TYPES     20
-
-#define DISK_TYPE_AIO      0
-#define DISK_TYPE_SYNC     1
-#define DISK_TYPE_VMDK     2
-#define DISK_TYPE_RAM      3
-#define DISK_TYPE_QCOW     4
-#define DISK_TYPE_QCOW2    5
-
-/* xenstore/xenbus: */
-#define DOMNAME "Domain-0"
-int setup_probe_watch(struct xs_handle *h);
-
-
-/* Abitrary values, must match the underlying driver... */
-#define MAX_TAP_DEV 100
-
-/* Accessing attached data page mappings */
-#define MMAP_PAGES                                              \
-    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
-#define MMAP_VADDR(_vstart,_req,_seg)                                   \
-    ((_vstart) +                                              \
-     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +    \
-     ((_seg) * getpagesize()))
-
-
-#endif /* __BLKTAPLIB_H__ */
diff --git a/tools/blktap/lib/list.h b/tools/blktap/lib/list.h
deleted file mode 100644
index c82242f..0000000
--- a/tools/blktap/lib/list.h
+++ /dev/null
@@ -1,59 +0,0 @@
-/*
- * list.h
- * 
- * This is a subset of linux's list.h intended to be used in user-space.
- * 
- */
-
-#ifndef __LIST_H__
-#define __LIST_H__
-
-#ifdef LIST_HEAD
-#undef LIST_HEAD
-#endif
-
-#define LIST_POISON1  ((void *) 0x00100100)
-#define LIST_POISON2  ((void *) 0x00200200)
-
-struct list_head {
-        struct list_head *next, *prev;
-};
- 
-#define LIST_HEAD_INIT(name) { &(name), &(name) }
- 
-#define LIST_HEAD(name) \
-        struct list_head name = LIST_HEAD_INIT(name)
-
-static inline void __list_add(struct list_head *new,
-                              struct list_head *prev,
-                              struct list_head *next)
-{
-        next->prev = new;
-        new->next = next;
-        new->prev = prev;
-        prev->next = new;
-}
-
-static inline void list_add(struct list_head *new, struct list_head *head)
-{
-        __list_add(new, head, head->next);
-}
-static inline void __list_del(struct list_head * prev, struct list_head * next)
-{
-        next->prev = prev;
-        prev->next = next;
-}
-static inline void list_del(struct list_head *entry)
-{
-        __list_del(entry->prev, entry->next);
-        entry->next = LIST_POISON1;
-        entry->prev = LIST_POISON2;
-}
-#define list_entry(ptr, type, member)                                   \
-        ((type *)((char *)(ptr)-(unsigned long)(&((type *)0)->member)))
-#define list_for_each_entry(pos, head, member)                          \
-        for (pos = list_entry((head)->next, typeof(*pos), member);      \
-             &pos->member != (head);                                    \
-             pos = list_entry(pos->member.next, typeof(*pos), member))
-
-#endif /* __LIST_H__ */
diff --git a/tools/blktap/lib/xenbus.c b/tools/blktap/lib/xenbus.c
deleted file mode 100644
index 948eb02..0000000
--- a/tools/blktap/lib/xenbus.c
+++ /dev/null
@@ -1,617 +0,0 @@
-/*
- * xenbus.c
- * 
- * xenbus interface to the blocktap.
- * 
- * this handles the top-half of integration with block devices through the
- * store -- the tap driver negotiates the device channel etc, while the
- * userland tap client needs to sort out the disk parameters etc.
- * 
- * (c) 2005 Andrew Warfield and Julian Chesterfield
- *
- *
- * 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 <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <err.h>
-#include <stdarg.h>
-#include <errno.h>
-#include <xenstore.h>
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#include <poll.h>
-#include <time.h>
-#include <sys/time.h>
-#include <unistd.h>
-#include "blktaplib.h"
-#include "list.h"
-#include "xs_api.h"
-
-#if 0
-#define DPRINTF(_f, _a...) printf ( _f , ## _a )
-#else
-#define DPRINTF(_f, _a...) ((void)0)
-#endif
-
-struct backend_info
-{
-	/* our communications channel */
-	blkif_t *blkif;
-	
-	long int frontend_id;
-	long int pdev;
-	long int readonly;
-	
-	char *backpath;
-	char *frontpath;
-	
-	struct list_head list;
-};
-
-static LIST_HEAD(belist);
-
-static int strsep_len(const char *str, char c, unsigned int len)
-{
-	unsigned int i;
-	
-	for (i = 0; str[i]; i++)
-		if (str[i] == c) {
-			if (len == 0)
-				return i;
-			len--;
-		}
-	return (len == 0) ? i : -ERANGE;
-}
-
-static int get_be_id(const char *str)
-{
-	int len,end;
-	const char *ptr;
-	char *tptr, num[10];
-	
-	len = strsep_len(str, '/', 6);
-	end = strlen(str);
-	if( (len < 0) || (end < 0) ) return -1;
-	
-	ptr = str + len + 1;
-	strncpy(num, ptr, end - len);
-	tptr = num + (end - (len + 1));
-	*tptr = '\0';
-
-	return atoi(num);
-}
-
-static int get_be_domid(const char *str)
-{
-	int len1, len2;
-	const char *ptr;
-	char *tptr, num[10];
-
-	len2 = strsep_len(str, '/', 3);
-	if ( len2 < 0 ) return -1;
-	len1 = strsep_len(str, '/', 2);
-
-	ptr = str + len1 + 1;
-	strncpy(num, ptr, len2 - len1 - 1);
-	tptr = num + (len2 - len1 - 1);
-	*tptr = '\0';
-
-	return atoi(num);
-}
-
-static struct backend_info *be_lookup_be(const char *bepath)
-{
-	struct backend_info *be;
-	
-	list_for_each_entry(be, &belist, list)
-		if (strcmp(bepath, be->backpath) == 0)
-			return be;
-	return (struct backend_info *)NULL;
-}
-
-static int be_exists_be(const char *bepath)
-{
-	return (be_lookup_be(bepath) != NULL);
-}
-
-static struct backend_info *be_lookup_fe(const char *fepath)
-{
-	struct backend_info *be;
-	
-	list_for_each_entry(be, &belist, list)
-		if (strcmp(fepath, be->frontpath) == 0)
-			return be;
-	return (struct backend_info *)NULL;
-}
-
-static int backend_remove(struct xs_handle *h, struct backend_info *be)
-{
-	/* Unhook from be list. */
-	list_del(&be->list);
-
-	/* Free everything else. */
-	if (be->blkif) {
-		DPRINTF("Freeing blkif dev [%d]\n",be->blkif->devnum);
-		free_blkif(be->blkif);
-	}
-	if (be->frontpath)
-		free(be->frontpath);
-	if (be->backpath)
-		free(be->backpath);
-	free(be);
-	return 0;
-}
-
-static const char *get_image_path(const char *path)
-{
-	const char *tmp;
-
-	/* Strip off the image type */
-	if (!strncmp(path, "tapdisk:", strlen("tapdisk:"))) {
-		path += strlen("tapdisk:");
-	} else if (!strncmp(path, "ioemu:", strlen("ioemu:"))) {
-		path += strlen("ioemu:");
-	}
-
-	tmp = strchr(path, ':');
-	if (tmp != NULL)
-		path = tmp + 1;
-
-	return path;
-}
-
-static int check_sharing(struct xs_handle *h, struct backend_info *be)
-{
-	char *dom_uuid;
-	char *cur_dom_uuid;
-	char *path;
-	char *mode;
-	char *params;
-	char **domains;
-	char **devices;
-	int i, j;
-	unsigned int num_dom, num_dev;
-	blkif_info_t *info = be->blkif->info;
-	int ret = 0;
-	const char *image_path[2];
-	int be_domid = get_be_domid(be->backpath);
-
-	image_path[0] = get_image_path(info->params);
-
-	/* If the mode contains '!' or doesn't contain 'w' don't check anything */
-	xs_gather(h, be->backpath, "mode", NULL, &mode, NULL);
-	if (strchr(mode, '!'))
-		goto out;
-	if (strchr(mode, 'w') == NULL)
-		goto out;
-
-	/* Get the UUID of the domain we want to attach to */
-	if (asprintf(&path, "/local/domain/%ld", be->frontend_id) == -1)
-		goto fail;
-	xs_gather(h, path, "vm", NULL, &dom_uuid, NULL);
-	free(path);
-
-	/* Iterate through the devices of all VMs */
-	if (asprintf(&path, "/local/domain/%d/backend/tap", be_domid) == -1)
-		goto fail;
-	domains = xs_directory(h, XBT_NULL, path, &num_dom);
-	free(path);
-	if (domains == NULL)
-		num_dom = 0;
-
-	for (i = 0; !ret && (i < num_dom); i++) {
-
-		/* If it's the same VM, no action needed */
-		if (asprintf(&path, "/local/domain/%s", domains[i]) == -1) {
-			ret = -1;
-			break;
-		}
-		cur_dom_uuid = NULL;
-		xs_gather(h, path, "vm", NULL, &cur_dom_uuid, NULL);
-		free(path);
-		if (!cur_dom_uuid)
-			continue;
-
-		if (!strcmp(cur_dom_uuid, dom_uuid)) {
-			free(cur_dom_uuid);
-			continue;
-		}
-
-		/* Check the devices */
-		if (asprintf(&path, "/local/domain/%d/backend/tap/%s", be_domid, domains[i]) == -1) {
-			ret = -1;
-			free(cur_dom_uuid);
-			break;
-		}
-		devices = xs_directory(h, XBT_NULL, path, &num_dev);
-		if (devices == NULL)
-			num_dev = 0;
-		free(path);
-
-		for (j = 0; !ret && (j < num_dev); j++) {
-			if (asprintf(&path, "/local/domain/%d/backend/tap/%s/%s", be_domid, domains[i], devices[j]) == -1) {
-				ret = -1;
-				break;
-			}
-			params = NULL;
-			xs_gather(h, path, "params", NULL, &params, NULL);
-			free(path);
-			if (!params)
-				continue;
-
-			image_path[1] = get_image_path(params);
-			if (!strcmp(image_path[0], image_path[1])) {
-				ret = -1;
-			}
-
-			free(params);
-		}
-
-		free(cur_dom_uuid);
-		free(devices);
-	}
-	free(domains);
-	free(dom_uuid);
-	goto out;
-
-fail:
-	ret = -1;
-out:
-	free(mode);
-	return ret;
-}
-
-static int check_image(struct xs_handle *h, struct backend_info *be,
-	const char** errmsg)
-{
-	const char *path;
-	int mode;
-	blkif_t *blkif = be->blkif;
-	blkif_info_t *info = blkif->info;
-
-	path = get_image_path(info->params);
-
-	/* Check if the image exists and access is permitted */
-	mode = R_OK;
-	if (!be->readonly)
-		mode |= W_OK;
-	if (access(path, mode)) {
-		if (errno == ENOENT)
-			*errmsg = "File not found.";
-		else
-			*errmsg = "Insufficient file permissions.";
-		return -1;
-	}
-
-	/* Check that the image is not attached to a different VM */
-	if (check_sharing(h, be)) {
-		*errmsg = "File already in use by other domain";
-		return -1;
-	}
-
-	return 0;
-}
-
-static void ueblktap_setup(struct xs_handle *h, char *bepath)
-{
-	struct backend_info *be;
-	char *path = NULL, *p,*dev;
-	int len, er, deverr;
-	long int pdev = 0, handle;
-	blkif_info_t *blk;
-	const char* errmsg = NULL;
-	
-	be = be_lookup_be(bepath);
-	if (be == NULL)
-	{
-		DPRINTF("ERROR: backend changed called for nonexistent "
-			"backend! (%s)\n", bepath);
-		goto fail;
-	}
-
-	deverr = xs_gather(h, bepath, "physical-device", "%li", &pdev, NULL);
-	if (!deverr) {
-		DPRINTF("pdev set to %ld\n",pdev);
-		if (be->pdev && be->pdev != pdev) {
-			DPRINTF("changing physical-device not supported");
-			goto fail;
-		}
-		be->pdev = pdev;
-	}
-
-	/* Check to see if device is to be opened read-only. */
-	deverr = xs_gather(h, bepath, "mode", NULL, &path, NULL);
-	if (deverr) {
-		DPRINTF("ERROR: could not find read/write mode\n");
-		goto fail;
-	} else if (path[0] == 'r')
-		be->readonly = 1;
-
-	if (be->blkif == NULL) {
-		/* Front end dir is a number, which is used as the handle. */
-		p = strrchr(be->frontpath, '/') + 1;
-		handle = strtoul(p, NULL, 0);
-
-		be->blkif = alloc_blkif(be->frontend_id);
-		if (be->blkif == NULL)
-			goto fail;
-
-		be->blkif->be_id = get_be_id(bepath);
-		
-		/* Insert device specific info, */
-		blk = malloc(sizeof(blkif_info_t));
-		if (!blk) {
-			DPRINTF("Out of memory - blkif_info_t\n");
-			goto fail;
-		}
-		er = xs_gather(h, bepath, "params", NULL, &blk->params, NULL);
-		if (er)
-			goto fail;
-		be->blkif->info = blk;
-		
-		if (deverr) {
-			/*Dev number was not available, try to set manually*/
-			pdev = convert_dev_name_to_num(blk->params);
-			be->pdev = pdev;
-		}
-
-		if (check_image(h, be, &errmsg))
-			goto fail;
-
-		er = blkif_init(be->blkif, handle, be->pdev, be->readonly);
-		if (er != 0) {
-			DPRINTF("Unable to open device %s\n",blk->params);
-			goto fail;
-		}
-
-		DPRINTF("[BECHG]: ADDED A NEW BLKIF (%s)\n", bepath);
-	}
-
-	/* Supply the information about the device to xenstore */
-	er = xs_printf(h, be->backpath, "sectors", "%llu",
-			be->blkif->ops->get_size(be->blkif));
-
-	if (er == 0) {
-		DPRINTF("ERROR: Failed writing sectors");
-		goto fail;
-	}
-
-	er = xs_printf(h, be->backpath, "sector-size", "%lu",
-			be->blkif->ops->get_secsize(be->blkif));
-
-	if (er == 0) {
-		DPRINTF("ERROR: Failed writing sector-size");
-		goto fail;
-	}
-
-	er = xs_printf(h, be->backpath, "info", "%u",
-			be->blkif->ops->get_info(be->blkif));
-
-	if (er == 0) {
-		DPRINTF("ERROR: Failed writing info");
-		goto fail;
-	}
-
-	be->blkif->state = CONNECTED;
-	xs_printf(h, be->backpath, "hotplug-status", "connected");
-
-	DPRINTF("[SETUP] Complete\n\n");
-	goto close;
-	
-fail:
-	if (be) {
-		if (errmsg == NULL)
-			errmsg = "Setting up the backend failed. See the log "
-				"files in /var/log/xen/ for details.";
-		xs_printf(h, be->backpath, "hotplug-error", errmsg);
-		xs_printf(h, be->backpath, "hotplug-status", "error");
-
-		backend_remove(h, be);
-	}
-close:
-	if (path)
-		free(path);
-	return;
-}
-
-/**
- * Xenstore watch callback entry point. This code replaces the hotplug scripts,
- * and as soon as the xenstore backend driver entries are created, this script
- * gets called.
- */
-static void ueblktap_probe(struct xs_handle *h, struct xenbus_watch *w, 
-			   const char *bepath_im)
-{
-	struct backend_info *be = NULL;
-	char *frontend = NULL, *bepath = NULL, *p;
-	int er, len;
-	blkif_t *blkif;
-	
-	
-	bepath = strdup(bepath_im);
-	
-	if (!bepath) {
-		DPRINTF("No path\n");
-		return;
-	}
-	
-	/*
-	 *asserts that xenstore structure is always 7 levels deep
-	 *e.g. /local/domain/0/backend/vbd/1/2049
-	 */
-	len = strsep_len(bepath, '/', 7);
-	if (len < 0) 
-		goto free_be;
-	if (bepath[len] != '\0')
-		goto free_be;
-	
-	be = malloc(sizeof(*be));
-	if (!be) {
-		DPRINTF("ERROR: allocating backend structure\n");
-		goto free_be;
-	}
-	memset(be, 0, sizeof(*be));
-	frontend = NULL;
-
-	er = xs_gather(h, bepath,
-		       "frontend-id", "%li", &be->frontend_id,
-		       "frontend", NULL, &frontend,
-		       NULL);
-
-	if (er) {
-		/*
-		 *Unable to find frontend entries, 
-		 *bus-id is no longer valid
-		 */
-		DPRINTF("ERROR: Frontend-id check failed, removing backend: "
-			"[%s]\n",bepath);
-
-		/**
-		 * BE info should already exist, 
-		 * free new mem and find old entry
-		 */
-		free(be);
-		be = be_lookup_be(bepath);
-		if ( (be != NULL) && (be->blkif != NULL) ) 
-			backend_remove(h, be);
-		else goto free_be;
-		if (bepath)
-			free(bepath);
-		return;
-	}
-	
-	/* Are we already tracking this device? */
-	if (be_exists_be(bepath))
-		goto free_be;
-	
-	be->backpath = bepath;
-	be->frontpath = frontend;
-	
-	list_add(&be->list, &belist);
-	
-	DPRINTF("[PROBE]\tADDED NEW DEVICE (%s)\n", bepath);
-	DPRINTF("\tFRONTEND (%s),(%ld)\n", frontend,be->frontend_id);
-	
-	ueblktap_setup(h, bepath);	
-	return;
-	
- free_be:
-	if (frontend)
-		free(frontend);
-	if (bepath)
-		free(bepath);
-	if (be) 
-		free(be);
-}
-
-/**
- *We set a general watch on the backend vbd directory
- *ueblktap_probe is called for every update
- *Our job is to monitor for new entries. As they 
- *are created, we initalise the state and attach a disk.
- */
-
-static int add_blockdevice_probe_watch(struct xs_handle *h, const char *domid)
-{
-	char *path;
-	struct xenbus_watch *vbd_watch;
-	
-	if (asprintf(&path, "/local/domain/%s/backend/tap", domid) == -1)
-		return -ENOMEM;
-	
-	vbd_watch = (struct xenbus_watch *)malloc(sizeof(struct xenbus_watch));
-	if (!vbd_watch) {
-		DPRINTF("ERROR: unable to malloc vbd_watch [%s]\n", path);
-		return -EINVAL;
-	}	
-	vbd_watch->node     = path;
-	vbd_watch->callback = ueblktap_probe;
-	if (register_xenbus_watch(h, vbd_watch) != 0) {
-		DPRINTF("ERROR: adding vbd probe watch %s\n", path);
-		return -EINVAL;
-	}
-	return 0;
-}
-
-/* Asynch callback to check for /local/domain/<DOMID>/name */
-static void check_dom(struct xs_handle *h, struct xenbus_watch *w, 
-	       const char *bepath_im)
-{
-	char *domid;
-
-	domid = get_dom_domid(h);
-	if (domid == NULL)
-		return;
-
-	add_blockdevice_probe_watch(h, domid);
-	free(domid);
-	unregister_xenbus_watch(h, w);
-}
-
-/* We must wait for xend to register /local/domain/<DOMID> */
-static int watch_for_domid(struct xs_handle *h)
-{
-	struct xenbus_watch *domid_watch;
-	char *path = NULL;
-
-	if (asprintf(&path, "/local/domain") == -1)
-		return -ENOMEM;
-
-	domid_watch = malloc(sizeof(struct xenbus_watch));
-	if (domid_watch == NULL) {
-		DPRINTF("ERROR: unable to malloc domid_watch [%s]\n", path);
-		return -EINVAL;
-	}	
-
-	domid_watch->node     = path;
-	domid_watch->callback = check_dom;
-
-	if (register_xenbus_watch(h, domid_watch) != 0) {
-		DPRINTF("ERROR: adding vbd probe watch %s\n", path);
-		return -EINVAL;
-	}
-
-	DPRINTF("Set async watch for /local/domain\n");
-
-	return 0;
-}
-
-int setup_probe_watch(struct xs_handle *h)
-{
-	char *domid;
-	int ret;
-	
-	domid = get_dom_domid(h);
-	if (domid == NULL)
-		return watch_for_domid(h);
-
-	ret = add_blockdevice_probe_watch(h, domid);
-	free(domid);
-	return ret;
-}
diff --git a/tools/blktap/lib/xs_api.c b/tools/blktap/lib/xs_api.c
deleted file mode 100644
index 4648432..0000000
--- a/tools/blktap/lib/xs_api.c
+++ /dev/null
@@ -1,360 +0,0 @@
-/*
- * xs_api.c
- * 
- * blocktap interface functions to xenstore
- *
- * (c) 2005 Andrew Warfield and Julian Chesterfield
- *
- *
- * 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 <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <err.h>
-#include <stdarg.h>
-#include <errno.h>
-#include <xenstore.h>
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#include <poll.h>
-#include "blktaplib.h"
-#include "list.h"
-#include "xs_api.h"
-
-#if 0
-#define DPRINTF(_f, _a...) printf ( _f , ## _a )
-#else
-#define DPRINTF(_f, _a...) ((void)0)
-#endif
-
-static LIST_HEAD(watches);
-#define BASE_DEV_VAL 2048
-
-int xs_gather(struct xs_handle *xs, const char *dir, ...)
-{
-	va_list ap;
-	const char *name;
-	char *path, **e;
-	int ret = 0, num,i;
-	unsigned int len;
-	xs_transaction_t xth;
-
-again:
-	if ( (xth = xs_transaction_start(xs)) == XBT_NULL) {
-		DPRINTF("unable to start xs trasanction\n");
-		ret = ENOMEM;
-		return ret;
-	}
-	
-	va_start(ap, dir);
-	while ( (ret == 0) && (name = va_arg(ap, char *)) != NULL) {
-		const char *fmt = va_arg(ap, char *);
-		void *result = va_arg(ap, void *);
-		char *p;
-		
-		if (asprintf(&path, "%s/%s", dir, name) == -1)
-		{
-			printf("allocation error in xs_gather!\n");
-			ret = ENOMEM;
-			break;
-		}
-		
-		p = xs_read(xs, xth, path, &len);
-		
-		
-		free(path);
-		if (p == NULL) {
-			ret = ENOENT;
-			break;
-		}
-		if (fmt) {
-			if (sscanf(p, fmt, result) == 0)
-				ret = EINVAL;
-			free(p);
-		} else
-			*(char **)result = p;
-	}
-	va_end(ap);
-
-	if (!xs_transaction_end(xs, xth, ret)) {
-		if (ret == 0 && errno == EAGAIN)
-			goto again;
-		else
-			ret = errno;
-	}
-
-	return ret;
-}
-
-
-/* Single printf and write: returns -errno or 0. */
-int xs_printf(struct xs_handle *h, const char *dir, const char *node, 
-	      const char *fmt, ...)
-{
-	char *buf, *path;
-	va_list ap;
-	int ret;
-	
-	va_start(ap, fmt);
-	ret = vasprintf(&buf, fmt, ap);
-	va_end(ap);
-	
-	if (ret == -1)
-		return ENOMEM;
-	if (asprintf(&path, "%s/%s", dir, node) == -1) {
-		free(buf);
-		return ENOMEM;
-	}
-
-	ret = xs_write(h, XBT_NULL, path, buf, strlen(buf));
-	
-	free(buf);
-	free(path);
-	
-	return ret;
-}
-
-
-int xs_exists(struct xs_handle *h, const char *path)
-{
-	char **d;
-	unsigned int num;
-	xs_transaction_t xth;
-	
-	if ( (xth = xs_transaction_start(h)) == XBT_NULL) {
-		printf("unable to start xs trasanction\n");
-		return 0;
-	}	
-	
-	d = xs_directory(h, xth, path, &num);
-	xs_transaction_end(h, xth, 0);
-	if (d == NULL)
-		return 0;
-	free(d);
-	return 1;
-}
-
-
-
-/**
- * This assumes that the domain name we are looking for is unique. 
- * Name parameter Domain-0 
- */
-char *get_dom_domid(struct xs_handle *h)
-{
-	char **e, *val, *domid = NULL;
-	unsigned int num, len;
-	int i;
-	char *path;
-	xs_transaction_t xth;
-	
-	if ( (xth = xs_transaction_start(h)) == XBT_NULL) {
-		warn("unable to start xs trasanction\n");
-		return NULL;
-	}
-	
-	e = xs_directory(h, xth, "/local/domain", &num);
-	if (e == NULL)
-		goto done;
-
-	for (i = 0; (i < num) && (domid == NULL); i++) {
-		if (asprintf(&path, "/local/domain/%s/name", e[i]) == -1)
-			break;
-		val = xs_read(h, xth, path, &len);
-		free(path);
-		if (val == NULL)
-			continue;
-		
-		if (strcmp(val, DOMNAME) == 0) {
-			/* match! */
-			if (asprintf(&path, "/local/domain/%s/domid", e[i]) == -1) {
-				free(val);
-				break;
-			}
-			domid = xs_read(h, xth, path, &len);
-			free(path);
-		}
-		free(val);
-	}
-done:
-	xs_transaction_end(h, xth, 0);
-	if (e)
-		free(e);
-	return domid;
-}
-
-int convert_dev_name_to_num(char *name) {
-	char *p, *ptr;
-	int majors[10] = {3,22,33,34,56,57,88,89,90,91};
-	int maj,i,ret = 0;
-	char *p_sd = "/dev/sd";
-	char *p_hd = "/dev/hd";
-	char *p_xvd = "/dev/xvd";
-	char *p_plx = "plx";
-	char *alpha = "abcdefghijklmnop";
-
-	if (strstr(name, p_sd) != NULL) {
-		p = name + strlen(p_sd);
-		for(i = 0, ptr = alpha; i < strlen(alpha); i++) {
-			if(*ptr == *p)
-				break;
-			*ptr++;
-		}
-		*p++;
-		ret = BASE_DEV_VAL + (16*i) + atoi(p);
-	} else if (strstr(name, p_hd) != NULL) {
-		p = name + strlen(p_hd);
-		for (i = 0, ptr = alpha; i < strlen(alpha); i++) {
-			if(*ptr == *p) break;
-			*ptr++;
-		}
-		*p++;
-		ret = (majors[i/2]*256) + atoi(p);
-
-	} else if (strstr(name, p_xvd) != NULL) {
-		p = name + strlen(p_xvd);
-		for(i = 0, ptr = alpha; i < strlen(alpha); i++) {
-			if(*ptr == *p) break;
-			*ptr++;
-		}
-		*p++;
-		ret = (202*256) + (16*i) + atoi(p);
-
-	} else if (strstr(name, p_plx) != NULL) {
-		p = name + strlen(p_plx);
-		ret = atoi(p);
-
-	} else {
-		DPRINTF("Unknown device type, setting to default.\n");
-		ret = BASE_DEV_VAL;
-	}
-
-	return ret;
-}
-
-/**
- * A little paranoia: we don't just trust token. 
- */
-static struct xenbus_watch *find_watch(const char *token)
-{
-	struct xenbus_watch *i, *cmp;
-	
-	cmp = (void *)strtoul(token, NULL, 16);
-	
-	list_for_each_entry(i, &watches, list)
-		if (i == cmp)
-			return i;
-	return NULL;
-}
-
-/**
- * Register callback to watch this node. 
- * like xs_watch, return 0 on failure 
- */
-int register_xenbus_watch(struct xs_handle *h, struct xenbus_watch *watch)
-{
-	/* Pointer in ascii is the token. */
-	char token[sizeof(watch) * 2 + 1];
-
-	snprintf(token, sizeof(token), "%lX", (long)watch);
-	if (find_watch(token)) {
-		DPRINTF("watch collision!\n");
-		return -EINVAL;
-	}
-	
-	if (!xs_watch(h, watch->node, token)) {
-		DPRINTF("unable to set watch!\n");
-		return -EINVAL;
-	}
-
-	list_add(&watch->list, &watches);
-
-	return 0;
-}
-
-int unregister_xenbus_watch(struct xs_handle *h, struct xenbus_watch *watch)
-{
-	char token[sizeof(watch) * 2 + 1];
-	
-	snprintf(token, sizeof(token), "%lX", (long)watch);
-	if (!find_watch(token)) {
-		DPRINTF("no such watch!\n");
-		return -EINVAL;
-	}
-
-	if (!xs_unwatch(h, watch->node, token))
-		DPRINTF("XENBUS Failed to release watch %s\n",
-			watch->node);
-
-	list_del(&watch->list);
-	
-	return 0;
-}
-
-/**
- * Re-register callbacks to all watches. 
- */
-void reregister_xenbus_watches(struct xs_handle *h)
-{
-	struct xenbus_watch *watch;
-	char token[sizeof(watch) * 2 + 1];
-	
-	list_for_each_entry(watch, &watches, list) {
-		snprintf(token, sizeof(token), "%lX", (long)watch);
-		xs_watch(h, watch->node, token);
-	}
-}
-
-/**
- * based on watch_thread() 
- */
-int xs_fire_next_watch(struct xs_handle *h)
-{
-	char **res;
-	char *token;
-	char *node = NULL;
-	struct xenbus_watch *w;
-	int er;
-	unsigned int num;
-	
-	res = xs_read_watch(h, &num);
-	if (res == NULL) 
-		return -EAGAIN; /* in O_NONBLOCK, read_watch returns 0... */
-	
-	node  = res[XS_WATCH_PATH];
-	token = res[XS_WATCH_TOKEN];
-
-	w = find_watch(token);
-	if (w) 
-		w->callback(h, w, node);
-
-	free(res);
-
-	return 1;
-}
diff --git a/tools/blktap/lib/xs_api.h b/tools/blktap/lib/xs_api.h
deleted file mode 100644
index 34430dc..0000000
--- a/tools/blktap/lib/xs_api.h
+++ /dev/null
@@ -1,50 +0,0 @@
-/*
- * xs_api.h
- *
- * (c) 2005 Andrew Warfield and Julian Chesterfield
- *
- *
- * 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.
- */
-
-struct xenbus_watch
-{
-        struct list_head list;
-        char *node;
-        void (*callback)(struct xs_handle *h, 
-                         struct xenbus_watch *, 
-                         const  char *node);
-};
-
-int xs_gather(struct xs_handle *xs, const char *dir, ...);
-int xs_printf(struct xs_handle *h, const char *dir, const char *node, 
-	      const char *fmt, ...);
-int xs_exists(struct xs_handle *h, const char *path);
-char *get_dom_domid(struct xs_handle *h);
-int convert_dev_name_to_num(char *name);
-int register_xenbus_watch(struct xs_handle *h, struct xenbus_watch *watch);
-int unregister_xenbus_watch(struct xs_handle *h, struct xenbus_watch *watch);
-void reregister_xenbus_watches(struct xs_handle *h);
-int xs_fire_next_watch(struct xs_handle *h);
diff --git a/tools/configure b/tools/configure
index c65ad3a..b1261a1 100755
--- a/tools/configure
+++ b/tools/configure
@@ -700,7 +700,6 @@ rombios
 qemu_traditional
 blktap2
 LINUX_BACKEND_MODULES
-blktap1
 debug
 seabios
 ovmf
@@ -790,7 +789,6 @@ enable_xsmpolicy
 enable_ovmf
 enable_seabios
 enable_debug
-enable_blktap1
 with_linux_backend_modules
 enable_blktap2
 enable_qemu_traditional
@@ -1463,7 +1461,6 @@ Optional Features:
   --enable-ovmf           Enable OVMF (default is DISABLED)
   --disable-seabios       Disable SeaBIOS (default is ENABLED)
   --disable-debug         Disable debug build of tools (default is ENABLED)
-  --enable-blktap1        Enable blktap1 tools (default is DISABLED)
   --enable-blktap2        Enable blktap2, (DEFAULT is on for Linux, otherwise
                           off)
   --enable-qemu-traditional
@@ -3991,29 +3988,6 @@ debug=$ax_cv_debug
 
 
 
-# Check whether --enable-blktap1 was given.
-if test "${enable_blktap1+set}" = set; then :
-  enableval=$enable_blktap1;
-fi
-
-
-if test "x$enable_blktap1" = "xno"; then :
-
-    ax_cv_blktap1="n"
-
-elif test "x$enable_blktap1" = "xyes"; then :
-
-    ax_cv_blktap1="y"
-
-elif test -z $ax_cv_blktap1; then :
-
-    ax_cv_blktap1="n"
-
-fi
-blktap1=$ax_cv_blktap1
-
-
-
 
 # Check whether --with-linux-backend-modules was given.
 if test "${with_linux_backend_modules+set}" = set; then :
@@ -4037,7 +4011,6 @@ usbbk
 pciback
 xen-acpi-processor
 blktap2
-blktap
 "
 ;;
 *)
@@ -7935,7 +7908,7 @@ fi
 
 
 
-if test "x$enable_blktap1" = "xyes" || test "x$enable_blktap2" = "xyes"; then :
+if test "x$enable_blktap2" = "xyes"]; then :
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for io_setup in -laio" >&5
 $as_echo_n "checking for io_setup in -laio... " >&6; }
diff --git a/tools/configure.ac b/tools/configure.ac
index 1ac63a3..72e2465 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -89,7 +89,6 @@ AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
 AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
 AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS])
 AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
-AX_ARG_DEFAULT_DISABLE([blktap1], [Enable blktap1 tools])
 
 AC_ARG_WITH([linux-backend-modules],
     AS_HELP_STRING([--with-linux-backend-modules="mod1 mod2"],
@@ -113,7 +112,6 @@ usbbk
 pciback
 xen-acpi-processor
 blktap2
-blktap
 "
 ;;
 *)
@@ -338,7 +336,7 @@ AC_CHECK_HEADER([lzo/lzo1x.h], [
 AC_CHECK_LIB([lzo2], [lzo1x_decompress], [zlib="$zlib -DHAVE_LZO1X -llzo2"])
 ])
 AC_SUBST(zlib)
-AS_IF([test "x$enable_blktap1" = "xyes" || test "x$enable_blktap2" = "xyes"], [
+AS_IF(test "x$enable_blktap2" = "xyes"], [
 AC_CHECK_LIB([aio], [io_setup], [], [AC_MSG_ERROR([Could not find libaio])])
 ])
 AC_SUBST(system_aio)
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 1706c05..b8490f9 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -19,7 +19,6 @@ XEN_SCRIPTS += vif-setup
 XEN_SCRIPTS-$(CONFIG_REMUS_NETBUF) += remus-netbuf-setup
 XEN_SCRIPTS += block
 XEN_SCRIPTS += block-enbd block-nbd
-XEN_SCRIPTS-$(CONFIG_BLKTAP1) += blktap
 XEN_SCRIPTS += xen-hotplug-cleanup
 XEN_SCRIPTS += external-device-migrate
 XEN_SCRIPTS += vscsi
diff --git a/tools/hotplug/Linux/blktap b/tools/hotplug/Linux/blktap
deleted file mode 100644
index cd30a38..0000000
--- a/tools/hotplug/Linux/blktap
+++ /dev/null
@@ -1,94 +0,0 @@
-#!/bin/bash
-
-# Copyright (c) 2005, XenSource Ltd.
-
-dir=$(dirname "$0")
-. "$dir/xen-hotplug-common.sh"
-. "$dir/block-common.sh"
-
-findCommand "$@"
-
-##
-# check_blktap_sharing file mode
-#
-# Perform the sharing check for the given blktap and mode.
-#
-check_blktap_sharing()
-{
-    local file="$1"
-    local mode="$2"
-
-    local base_path="$XENBUS_BASE_PATH/$XENBUS_TYPE"
-    for dom in $(xenstore-list "$base_path")
-    do
-        for dev in $(xenstore-list "$base_path/$dom")
-        do
-            params=$(xenstore_read_default "$base_path/$dom/$dev/params" "" | cut -d: -f2)
-            if [ "$file" = "$params" ]
-            then
-
-                if [ "$mode" = 'w' ]
-                then
-                    if ! same_vm "$dom" 
-                    then
-                        echo 'guest'
-                        return
-                    fi
-                else 
-                    local m=$(xenstore_read_default "$base_path/$dom/$dev/mode" "")
-                    m=$(canonicalise_mode "$m")
-
-                    if [ "$m" = 'w' ] 
-                    then
-                        if ! same_vm "$dom"
-                        then
-                            echo 'guest'
-                            return
-                        fi
-                    fi
-                fi
-            fi
-        done
-    done
-
-    echo 'ok'
-}
-
-
-t=$(xenstore_read_default "$XENBUS_PATH/type" 'MISSING')
-if [ -n "$t" ]
-then
-    p=$(xenstore_read "$XENBUS_PATH/params")
-    p=${p#tapdisk:}
-    # if we have a ':', chew from head including :
-    if echo $p | grep -q \:
-    then
-        p=${p#*:}
-    fi
-fi
-# some versions of readlink cannot be passed a regular file
-if [ -L "$p" ]; then
-    file=$(readlink -f "$p") || fatal "$p link does not exist."
-else
-    file="$p"
-fi
-
-if [ "$command" = 'add' ]
-then
-    [ -e "$file" ] || { fatal $file does not exist; }
-
-    FRONTEND_ID=$(xenstore_read "$XENBUS_PATH/frontend-id")
-    FRONTEND_UUID=$(xenstore_read "/local/domain/$FRONTEND_ID/vm")
-    mode=$(xenstore_read "$XENBUS_PATH/mode")
-    mode=$(canonicalise_mode "$mode")
-
-    if [ "$mode" != '!' ] 
-    then
-        result=$(check_blktap_sharing "$file" "$mode")
-        [ "$result" = 'ok' ] || ebusy "$file already in use by other domain"
-    fi
-
-    success
-fi
-
-exit 0
diff --git a/tools/hotplug/Linux/xen-backend.rules.in b/tools/hotplug/Linux/xen-backend.rules.in
index 7d2f914..ee107af 100644
--- a/tools/hotplug/Linux/xen-backend.rules.in
+++ b/tools/hotplug/Linux/xen-backend.rules.in
@@ -1,4 +1,3 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{UDEV_CALL}="1", RUN+="@XEN_SCRIPT_DIR@/blktap $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", RUN+="@XEN_SCRIPT_DIR@/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="@XEN_SCRIPT_DIR@/vif2 $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{UDEV_CALL}="1", ACTION=="online", RUN+="@XEN_SCRIPT_DIR@/vif-setup online type_if=vif"
@@ -6,7 +5,6 @@ SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{UDEV_CALL}="1", ACTION=="offline"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="@XEN_SCRIPT_DIR@/vscsi $env{ACTION}"
 SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{UDEV_CALL}="1", RUN+="@XEN_SCRIPT_DIR@/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"
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:54:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:54:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlchA-0001f0-HZ; Tue, 04 Nov 2014 11:54:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlch9-0001em-2Z
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:54:43 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	51/8D-02576-28EB8545; Tue, 04 Nov 2014 11:54:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415102080!12443609!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5698 invoked from network); 4 Nov 2014 11:54:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:54:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189247399"
Message-ID: <1415102066.11486.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 4 Nov 2014 11:54:26 +0000
In-Reply-To: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 11:52 +0000, Ian Campbell wrote:
> This was disabled by default in Xen 4.4. Since xend has now been removed from
> the tree I don't believe anything is using it.
> 
> We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xen-traditional otherwise
> it defaults to y and doesn't build.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

I suspect this might be too large for the list so it also at
        git://xenbits.xen.org/people/ianc/xen.git remove-blktap1

I've trimmed everything but the diffstat from below.

> ---
> I think this has probably missed the boat for 4.5 and there isn't much harm in
> waiting for 4.6. I'm open to being told otherwise though ;-)
> ---
>  .gitignore                               |    5 -
>  .hgignore                                |    5 -
>  INSTALL                                  |    1 -
>  config/Tools.mk.in                       |    1 -
>  tools/Makefile                           |    2 +-
>  tools/blktap/Makefile                    |   13 -
>  tools/blktap/README                      |  122 --
>  tools/blktap/drivers/Makefile            |   73 --
>  tools/blktap/drivers/aes.c               | 1319 -------------------
>  tools/blktap/drivers/aes.h               |   28 -
>  tools/blktap/drivers/blk.h               |    3 -
>  tools/blktap/drivers/blk_linux.c         |   42 -
>  tools/blktap/drivers/blktapctrl.c        |  937 -------------
>  tools/blktap/drivers/blktapctrl.h        |   36 -
>  tools/blktap/drivers/blktapctrl_linux.c  |   89 --
>  tools/blktap/drivers/block-aio.c         |  259 ----
>  tools/blktap/drivers/block-qcow.c        | 1434 --------------------
>  tools/blktap/drivers/block-qcow2.c       | 2098 ------------------------------
>  tools/blktap/drivers/block-ram.c         |  295 -----
>  tools/blktap/drivers/block-sync.c        |  242 ----
>  tools/blktap/drivers/block-vmdk.c        |  428 ------
>  tools/blktap/drivers/bswap.h             |  178 ---
>  tools/blktap/drivers/img2qcow.c          |  282 ----
>  tools/blktap/drivers/qcow-create.c       |  130 --
>  tools/blktap/drivers/qcow2raw.c          |  348 -----
>  tools/blktap/drivers/tapaio.c            |  357 -----
>  tools/blktap/drivers/tapaio.h            |  108 --
>  tools/blktap/drivers/tapdisk.c           |  872 -------------
>  tools/blktap/drivers/tapdisk.h           |  259 ----
>  tools/blktap/lib/Makefile                |   60 -
>  tools/blktap/lib/blkif.c                 |  185 ---
>  tools/blktap/lib/blktaplib.h             |  240 ----
>  tools/blktap/lib/list.h                  |   59 -
>  tools/blktap/lib/xenbus.c                |  617 ---------
>  tools/blktap/lib/xs_api.c                |  360 -----
>  tools/blktap/lib/xs_api.h                |   50 -
>  tools/configure                          |   29 +-
>  tools/configure.ac                       |    4 +-
>  tools/hotplug/Linux/Makefile             |    1 -
>  tools/hotplug/Linux/blktap               |   94 --
>  tools/hotplug/Linux/xen-backend.rules.in |    2 -
>  41 files changed, 3 insertions(+), 11664 deletions(-)
>  delete mode 100644 tools/blktap/Makefile
>  delete mode 100644 tools/blktap/README
>  delete mode 100644 tools/blktap/drivers/Makefile
>  delete mode 100644 tools/blktap/drivers/aes.c
>  delete mode 100644 tools/blktap/drivers/aes.h
>  delete mode 100644 tools/blktap/drivers/blk.h
>  delete mode 100644 tools/blktap/drivers/blk_linux.c
>  delete mode 100644 tools/blktap/drivers/blktapctrl.c
>  delete mode 100644 tools/blktap/drivers/blktapctrl.h
>  delete mode 100644 tools/blktap/drivers/blktapctrl_linux.c
>  delete mode 100644 tools/blktap/drivers/block-aio.c
>  delete mode 100644 tools/blktap/drivers/block-qcow.c
>  delete mode 100644 tools/blktap/drivers/block-qcow2.c
>  delete mode 100644 tools/blktap/drivers/block-ram.c
>  delete mode 100644 tools/blktap/drivers/block-sync.c
>  delete mode 100644 tools/blktap/drivers/block-vmdk.c
>  delete mode 100644 tools/blktap/drivers/bswap.h
>  delete mode 100644 tools/blktap/drivers/img2qcow.c
>  delete mode 100644 tools/blktap/drivers/qcow-create.c
>  delete mode 100644 tools/blktap/drivers/qcow2raw.c
>  delete mode 100644 tools/blktap/drivers/tapaio.c
>  delete mode 100644 tools/blktap/drivers/tapaio.h
>  delete mode 100644 tools/blktap/drivers/tapdisk.c
>  delete mode 100644 tools/blktap/drivers/tapdisk.h
>  delete mode 100644 tools/blktap/lib/Makefile
>  delete mode 100644 tools/blktap/lib/blkif.c
>  delete mode 100644 tools/blktap/lib/blktaplib.h
>  delete mode 100644 tools/blktap/lib/list.h
>  delete mode 100644 tools/blktap/lib/xenbus.c
>  delete mode 100644 tools/blktap/lib/xs_api.c
>  delete mode 100644 tools/blktap/lib/xs_api.h
>  delete mode 100644 tools/hotplug/Linux/blktap



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:54:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:54:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlchA-0001f0-HZ; Tue, 04 Nov 2014 11:54:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlch9-0001em-2Z
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:54:43 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	51/8D-02576-28EB8545; Tue, 04 Nov 2014 11:54:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415102080!12443609!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5698 invoked from network); 4 Nov 2014 11:54:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 11:54:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189247399"
Message-ID: <1415102066.11486.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 4 Nov 2014 11:54:26 +0000
In-Reply-To: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 11:52 +0000, Ian Campbell wrote:
> This was disabled by default in Xen 4.4. Since xend has now been removed from
> the tree I don't believe anything is using it.
> 
> We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xen-traditional otherwise
> it defaults to y and doesn't build.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

I suspect this might be too large for the list so it also at
        git://xenbits.xen.org/people/ianc/xen.git remove-blktap1

I've trimmed everything but the diffstat from below.

> ---
> I think this has probably missed the boat for 4.5 and there isn't much harm in
> waiting for 4.6. I'm open to being told otherwise though ;-)
> ---
>  .gitignore                               |    5 -
>  .hgignore                                |    5 -
>  INSTALL                                  |    1 -
>  config/Tools.mk.in                       |    1 -
>  tools/Makefile                           |    2 +-
>  tools/blktap/Makefile                    |   13 -
>  tools/blktap/README                      |  122 --
>  tools/blktap/drivers/Makefile            |   73 --
>  tools/blktap/drivers/aes.c               | 1319 -------------------
>  tools/blktap/drivers/aes.h               |   28 -
>  tools/blktap/drivers/blk.h               |    3 -
>  tools/blktap/drivers/blk_linux.c         |   42 -
>  tools/blktap/drivers/blktapctrl.c        |  937 -------------
>  tools/blktap/drivers/blktapctrl.h        |   36 -
>  tools/blktap/drivers/blktapctrl_linux.c  |   89 --
>  tools/blktap/drivers/block-aio.c         |  259 ----
>  tools/blktap/drivers/block-qcow.c        | 1434 --------------------
>  tools/blktap/drivers/block-qcow2.c       | 2098 ------------------------------
>  tools/blktap/drivers/block-ram.c         |  295 -----
>  tools/blktap/drivers/block-sync.c        |  242 ----
>  tools/blktap/drivers/block-vmdk.c        |  428 ------
>  tools/blktap/drivers/bswap.h             |  178 ---
>  tools/blktap/drivers/img2qcow.c          |  282 ----
>  tools/blktap/drivers/qcow-create.c       |  130 --
>  tools/blktap/drivers/qcow2raw.c          |  348 -----
>  tools/blktap/drivers/tapaio.c            |  357 -----
>  tools/blktap/drivers/tapaio.h            |  108 --
>  tools/blktap/drivers/tapdisk.c           |  872 -------------
>  tools/blktap/drivers/tapdisk.h           |  259 ----
>  tools/blktap/lib/Makefile                |   60 -
>  tools/blktap/lib/blkif.c                 |  185 ---
>  tools/blktap/lib/blktaplib.h             |  240 ----
>  tools/blktap/lib/list.h                  |   59 -
>  tools/blktap/lib/xenbus.c                |  617 ---------
>  tools/blktap/lib/xs_api.c                |  360 -----
>  tools/blktap/lib/xs_api.h                |   50 -
>  tools/configure                          |   29 +-
>  tools/configure.ac                       |    4 +-
>  tools/hotplug/Linux/Makefile             |    1 -
>  tools/hotplug/Linux/blktap               |   94 --
>  tools/hotplug/Linux/xen-backend.rules.in |    2 -
>  41 files changed, 3 insertions(+), 11664 deletions(-)
>  delete mode 100644 tools/blktap/Makefile
>  delete mode 100644 tools/blktap/README
>  delete mode 100644 tools/blktap/drivers/Makefile
>  delete mode 100644 tools/blktap/drivers/aes.c
>  delete mode 100644 tools/blktap/drivers/aes.h
>  delete mode 100644 tools/blktap/drivers/blk.h
>  delete mode 100644 tools/blktap/drivers/blk_linux.c
>  delete mode 100644 tools/blktap/drivers/blktapctrl.c
>  delete mode 100644 tools/blktap/drivers/blktapctrl.h
>  delete mode 100644 tools/blktap/drivers/blktapctrl_linux.c
>  delete mode 100644 tools/blktap/drivers/block-aio.c
>  delete mode 100644 tools/blktap/drivers/block-qcow.c
>  delete mode 100644 tools/blktap/drivers/block-qcow2.c
>  delete mode 100644 tools/blktap/drivers/block-ram.c
>  delete mode 100644 tools/blktap/drivers/block-sync.c
>  delete mode 100644 tools/blktap/drivers/block-vmdk.c
>  delete mode 100644 tools/blktap/drivers/bswap.h
>  delete mode 100644 tools/blktap/drivers/img2qcow.c
>  delete mode 100644 tools/blktap/drivers/qcow-create.c
>  delete mode 100644 tools/blktap/drivers/qcow2raw.c
>  delete mode 100644 tools/blktap/drivers/tapaio.c
>  delete mode 100644 tools/blktap/drivers/tapaio.h
>  delete mode 100644 tools/blktap/drivers/tapdisk.c
>  delete mode 100644 tools/blktap/drivers/tapdisk.h
>  delete mode 100644 tools/blktap/lib/Makefile
>  delete mode 100644 tools/blktap/lib/blkif.c
>  delete mode 100644 tools/blktap/lib/blktaplib.h
>  delete mode 100644 tools/blktap/lib/list.h
>  delete mode 100644 tools/blktap/lib/xenbus.c
>  delete mode 100644 tools/blktap/lib/xs_api.c
>  delete mode 100644 tools/blktap/lib/xs_api.h
>  delete mode 100644 tools/hotplug/Linux/blktap



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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:57:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:57:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlck8-0001rJ-AL; Tue, 04 Nov 2014 11:57:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1Xlck7-0001r5-4K
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:57:47 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	83/08-25547-A3FB8545; Tue, 04 Nov 2014 11:57:46 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415102264!11562551!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4880 invoked from network); 4 Nov 2014 11:57:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 11:57:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4Bve7h020030
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 11:57:41 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4BvdEU027792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 11:57:40 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4BvdD3027768; Tue, 4 Nov 2014 11:57:39 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 03:57:38 -0800
Date: Tue, 4 Nov 2014 12:57:33 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141104115733.GG16923@olila.local.net-space.pl>
References: <1415075851-8987-1-git-send-email-roy.franz@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415075851-8987-1-git-send-email-roy.franz@linaro.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: ian.campbell@citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	stefano.stabellini@citrix.com, jbeulich@suse.com, fu.wei@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.5 V2] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 08:37:31PM -0800, Roy Franz wrote:
> Update EFI code to completely ignore the EFI comnandline when booted from GRUB.
> Previusly it was parsed of EFI boot specific options, but these aren't used
> when booted from GRUB.
>
> Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
> code does some console and video initialization to support native EFI boot from
> the EFI boot manager or EFI shell.  This initlization should not be done when
> booted using GRUB.
>
> Update EFI documentation to indicate that it describes EFI native boot, and
> does not apply at all when Xen is booted using GRUB.
>
> Signed-off-by: Roy Franz <roy.franz@linaro.org>

In general Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> but...

> ---
> This patch implements what I understand to be the desired behavior when booting
> an EFI Xen image via GRUB based on the thread last week.  The EFI command line
> is not used, and the Xen commandline comes via the multiboot protocol (and
> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
> GRUB EFI boot cases into alignment in not using the EFI commandline.
>
> The current state of the arm64 code takes the Xen commandline from the FDT,
> but still looks in the EFI commandline for EFI boot specific options.  If
> unexpected options are passed in the EFI commandline, it will generate
> "unrecognized option" ouput for all unexpected options.
>
> I think this should be considered for 4.5.
>
> Changes from v1:
> * Fixed style, and removed blank line changes
> * Reviewed scope of variables now that more code is in if ( use_cfg_file ) block
>
>
>  docs/misc/efi.markdown |   5 ++
>  xen/common/efi/boot.c  | 240 +++++++++++++++++++++++++------------------------
>  2 files changed, 128 insertions(+), 117 deletions(-)
>
> diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
> index 5e48aa3..f435ec7 100644
> --- a/docs/misc/efi.markdown
> +++ b/docs/misc/efi.markdown
> @@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
>  (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
>  try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
>  order.) One can override this with a command line option (`-cfg=<filename>`).
> +This configuration file and EFI commandline are only used for booting directly
> +from EFI firmware, or when using an EFI loader that does not support
> +the multiboot2 protocol.  When booting using GRUB or another multiboot aware
> +loader the EFI commandline is ignored and all information is passed from
> +the loader to Xen using the multiboot protocol.

First you are referring to multiboot2 and later you are talking about
multiboot. It makes some confusion. Could you put full stop after "...
using an EFI loader" or rephrase this sentences in another way to make
them clear?

Daniel

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 11:57:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 11:57:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlck8-0001rJ-AL; Tue, 04 Nov 2014 11:57:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1Xlck7-0001r5-4K
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 11:57:47 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	83/08-25547-A3FB8545; Tue, 04 Nov 2014 11:57:46 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415102264!11562551!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4880 invoked from network); 4 Nov 2014 11:57:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 11:57:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4Bve7h020030
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 11:57:41 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4BvdEU027792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 11:57:40 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4BvdD3027768; Tue, 4 Nov 2014 11:57:39 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 03:57:38 -0800
Date: Tue, 4 Nov 2014 12:57:33 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141104115733.GG16923@olila.local.net-space.pl>
References: <1415075851-8987-1-git-send-email-roy.franz@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415075851-8987-1-git-send-email-roy.franz@linaro.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: ian.campbell@citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	stefano.stabellini@citrix.com, jbeulich@suse.com, fu.wei@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.5 V2] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 08:37:31PM -0800, Roy Franz wrote:
> Update EFI code to completely ignore the EFI comnandline when booted from GRUB.
> Previusly it was parsed of EFI boot specific options, but these aren't used
> when booted from GRUB.
>
> Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
> code does some console and video initialization to support native EFI boot from
> the EFI boot manager or EFI shell.  This initlization should not be done when
> booted using GRUB.
>
> Update EFI documentation to indicate that it describes EFI native boot, and
> does not apply at all when Xen is booted using GRUB.
>
> Signed-off-by: Roy Franz <roy.franz@linaro.org>

In general Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> but...

> ---
> This patch implements what I understand to be the desired behavior when booting
> an EFI Xen image via GRUB based on the thread last week.  The EFI command line
> is not used, and the Xen commandline comes via the multiboot protocol (and
> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
> GRUB EFI boot cases into alignment in not using the EFI commandline.
>
> The current state of the arm64 code takes the Xen commandline from the FDT,
> but still looks in the EFI commandline for EFI boot specific options.  If
> unexpected options are passed in the EFI commandline, it will generate
> "unrecognized option" ouput for all unexpected options.
>
> I think this should be considered for 4.5.
>
> Changes from v1:
> * Fixed style, and removed blank line changes
> * Reviewed scope of variables now that more code is in if ( use_cfg_file ) block
>
>
>  docs/misc/efi.markdown |   5 ++
>  xen/common/efi/boot.c  | 240 +++++++++++++++++++++++++------------------------
>  2 files changed, 128 insertions(+), 117 deletions(-)
>
> diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
> index 5e48aa3..f435ec7 100644
> --- a/docs/misc/efi.markdown
> +++ b/docs/misc/efi.markdown
> @@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
>  (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
>  try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
>  order.) One can override this with a command line option (`-cfg=<filename>`).
> +This configuration file and EFI commandline are only used for booting directly
> +from EFI firmware, or when using an EFI loader that does not support
> +the multiboot2 protocol.  When booting using GRUB or another multiboot aware
> +loader the EFI commandline is ignored and all information is passed from
> +the loader to Xen using the multiboot protocol.

First you are referring to multiboot2 and later you are talking about
multiboot. It makes some confusion. Could you put full stop after "...
using an EFI loader" or rephrase this sentences in another way to make
them clear?

Daniel

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:00:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:00:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlcmy-00025L-IO; Tue, 04 Nov 2014 12:00:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xlcmx-000256-D4
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:00:43 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	FA/68-26740-AEFB8545; Tue, 04 Nov 2014 12:00:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415102441!11514232!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4698 invoked from network); 4 Nov 2014 12:00:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 12:00:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 12:00:41 +0000
Message-Id: <5458CDF70200007800044C30@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 12:00:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5458BCA9.3000304@citrix.com>
	<1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen: Bump Xen interface for
	Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 12:50, <andrew.cooper3@citrix.com> wrote:
> c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> API.
> 
> While these were toolstack hypercalls and documented as liable to change in
> the future, it causes build issues for certain tools (valgrind, strace).
> 
> As HVM ops have no specific interface version, the main Xen interface 
> version
> needs to be bumped to compensate.

Content-wise I don't really object to this patch, but I view it as
merely cosmetic rather than fixing anything: Tool stack interfaces
are declared to be volatile just because we want to avoid exactly
this need for bumping versions or anything when altering or
dropping them. If there are out of tree consumers of them, it is
their responsibility to keep up with our changes (or have their
own clones of the canonical headers).

Also we didn't bother incrementing the version just because of a
release on earlier occasions: 3.3 and 3.4 as well as 4.0 and 4.1
shared interface versions, yet especially in the case of 4.1 I'm
pretty certain even without explicitly checking that there were
tool stack interface changes.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:00:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:00:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlcmy-00025L-IO; Tue, 04 Nov 2014 12:00:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xlcmx-000256-D4
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:00:43 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	FA/68-26740-AEFB8545; Tue, 04 Nov 2014 12:00:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415102441!11514232!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4698 invoked from network); 4 Nov 2014 12:00:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 12:00:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 12:00:41 +0000
Message-Id: <5458CDF70200007800044C30@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 12:00:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5458BCA9.3000304@citrix.com>
	<1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen: Bump Xen interface for
	Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 12:50, <andrew.cooper3@citrix.com> wrote:
> c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> API.
> 
> While these were toolstack hypercalls and documented as liable to change in
> the future, it causes build issues for certain tools (valgrind, strace).
> 
> As HVM ops have no specific interface version, the main Xen interface 
> version
> needs to be bumped to compensate.

Content-wise I don't really object to this patch, but I view it as
merely cosmetic rather than fixing anything: Tool stack interfaces
are declared to be volatile just because we want to avoid exactly
this need for bumping versions or anything when altering or
dropping them. If there are out of tree consumers of them, it is
their responsibility to keep up with our changes (or have their
own clones of the canonical headers).

Also we didn't bother incrementing the version just because of a
release on earlier occasions: 3.3 and 3.4 as well as 4.0 and 4.1
shared interface versions, yet especially in the case of 4.1 I'm
pretty certain even without explicitly checking that there were
tool stack interface changes.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:07:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:07:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlctU-0002SO-H4; Tue, 04 Nov 2014 12:07:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlctT-0002SJ-Iz
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:07:27 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	D4/D1-24859-E71C8545; Tue, 04 Nov 2014 12:07:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415102844!11470931!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2567 invoked from network); 4 Nov 2014 12:07:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 12:07:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189250729"
Message-ID: <1415102839.11486.38.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 4 Nov 2014 12:07:19 +0000
In-Reply-To: <1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
References: <5458BCA9.3000304@citrix.com>
	<1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>, Jan
	Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen: Bump Xen interface for
	Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 11:50 +0000, Andrew Cooper wrote:
> c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> API.
> 
> While these were toolstack hypercalls and documented as liable to change in
> the future, it causes build issues for certain tools (valgrind, strace).

Valgrind has its own copy of the headers and needs to process old
hypercalls as well as new anyway, it will also DTRT with the ENOSYS
which results from a tool using an old interface on a new hypervisor.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:07:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:07:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlctU-0002SO-H4; Tue, 04 Nov 2014 12:07:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlctT-0002SJ-Iz
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:07:27 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	D4/D1-24859-E71C8545; Tue, 04 Nov 2014 12:07:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415102844!11470931!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2567 invoked from network); 4 Nov 2014 12:07:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 12:07:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189250729"
Message-ID: <1415102839.11486.38.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 4 Nov 2014 12:07:19 +0000
In-Reply-To: <1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
References: <5458BCA9.3000304@citrix.com>
	<1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>, Jan
	Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen: Bump Xen interface for
	Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 11:50 +0000, Andrew Cooper wrote:
> c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> API.
> 
> While these were toolstack hypercalls and documented as liable to change in
> the future, it causes build issues for certain tools (valgrind, strace).

Valgrind has its own copy of the headers and needs to process old
hypercalls as well as new anyway, it will also DTRT with the ENOSYS
which results from a tool using an old interface on a new hypervisor.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:09:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlcuu-0002X5-W5; Tue, 04 Nov 2014 12:08:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlcuu-0002Wx-3O
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:08:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	90/13-09842-7D1C8545; Tue, 04 Nov 2014 12:08:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415102933!12089682!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10013 invoked from network); 4 Nov 2014 12:08:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 12:08:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187871069"
Message-ID: <1415102930.11486.40.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 4 Nov 2014 12:08:50 +0000
In-Reply-To: <5458CDF70200007800044C30@mail.emea.novell.com>
References: <5458BCA9.3000304@citrix.com>
	<1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
	<5458CDF70200007800044C30@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen: Bump Xen interface for
	Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 12:00 +0000, Jan Beulich wrote:
> >>> On 04.11.14 at 12:50, <andrew.cooper3@citrix.com> wrote:
> > c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> > structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> > API.
> > 
> > While these were toolstack hypercalls and documented as liable to change in
> > the future, it causes build issues for certain tools (valgrind, strace).
> > 
> > As HVM ops have no specific interface version, the main Xen interface 
> > version
> > needs to be bumped to compensate.
> 
> Content-wise I don't really object to this patch, but I view it as
> merely cosmetic rather than fixing anything: Tool stack interfaces
> are declared to be volatile just because we want to avoid exactly
> this need for bumping versions or anything when altering or
> dropping them. If there are out of tree consumers of them, it is
> their responsibility to keep up with our changes (or have their
> own clones of the canonical headers).
> 
> Also we didn't bother incrementing the version just because of a
> release on earlier occasions: 3.3 and 3.4 as well as 4.0 and 4.1
> shared interface versions, yet especially in the case of 4.1 I'm
> pretty certain even without explicitly checking that there were
> tool stack interface changes.

I always thought __XEN_(LATEST_)INTERFACE_VERSION__ were more to do with
API rather than ABI, i.e. it gets used to revert
__HYPERVISOR_sched_op_compat into providing __HYPERVISOR_sched_op for
older consumers and things like that.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:09:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlcuu-0002X5-W5; Tue, 04 Nov 2014 12:08:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlcuu-0002Wx-3O
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:08:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	90/13-09842-7D1C8545; Tue, 04 Nov 2014 12:08:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415102933!12089682!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10013 invoked from network); 4 Nov 2014 12:08:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 12:08:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187871069"
Message-ID: <1415102930.11486.40.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 4 Nov 2014 12:08:50 +0000
In-Reply-To: <5458CDF70200007800044C30@mail.emea.novell.com>
References: <5458BCA9.3000304@citrix.com>
	<1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
	<5458CDF70200007800044C30@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen: Bump Xen interface for
	Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 12:00 +0000, Jan Beulich wrote:
> >>> On 04.11.14 at 12:50, <andrew.cooper3@citrix.com> wrote:
> > c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> > structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> > API.
> > 
> > While these were toolstack hypercalls and documented as liable to change in
> > the future, it causes build issues for certain tools (valgrind, strace).
> > 
> > As HVM ops have no specific interface version, the main Xen interface 
> > version
> > needs to be bumped to compensate.
> 
> Content-wise I don't really object to this patch, but I view it as
> merely cosmetic rather than fixing anything: Tool stack interfaces
> are declared to be volatile just because we want to avoid exactly
> this need for bumping versions or anything when altering or
> dropping them. If there are out of tree consumers of them, it is
> their responsibility to keep up with our changes (or have their
> own clones of the canonical headers).
> 
> Also we didn't bother incrementing the version just because of a
> release on earlier occasions: 3.3 and 3.4 as well as 4.0 and 4.1
> shared interface versions, yet especially in the case of 4.1 I'm
> pretty certain even without explicitly checking that there were
> tool stack interface changes.

I always thought __XEN_(LATEST_)INTERFACE_VERSION__ were more to do with
API rather than ABI, i.e. it gets used to revert
__HYPERVISOR_sched_op_compat into providing __HYPERVISOR_sched_op for
older consumers and things like that.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:24:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xld9c-00035I-UH; Tue, 04 Nov 2014 12:24:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xld9a-00035A-P5
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:24:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6F/B3-09842-665C8545; Tue, 04 Nov 2014 12:24:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415103845!12636057!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4420 invoked from network); 4 Nov 2014 12:24:05 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 12:24:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 12:24:04 +0000
Message-Id: <5458D3720200007800044C8B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 12:24:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <5458BCA9.3000304@citrix.com>
	<1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
	<5458CDF70200007800044C30@mail.emea.novell.com>
	<1415102930.11486.40.camel@citrix.com>
In-Reply-To: <1415102930.11486.40.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen: Bump Xen interface for
	Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 13:08, <Ian.Campbell@citrix.com> wrote:
> On Tue, 2014-11-04 at 12:00 +0000, Jan Beulich wrote:
>> >>> On 04.11.14 at 12:50, <andrew.cooper3@citrix.com> wrote:
>> > c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
>> > structures associated with xen_hvm_{get,set}_mem_access from the Xen public
>> > API.
>> > 
>> > While these were toolstack hypercalls and documented as liable to change in
>> > the future, it causes build issues for certain tools (valgrind, strace).
>> > 
>> > As HVM ops have no specific interface version, the main Xen interface 
>> > version
>> > needs to be bumped to compensate.
>> 
>> Content-wise I don't really object to this patch, but I view it as
>> merely cosmetic rather than fixing anything: Tool stack interfaces
>> are declared to be volatile just because we want to avoid exactly
>> this need for bumping versions or anything when altering or
>> dropping them. If there are out of tree consumers of them, it is
>> their responsibility to keep up with our changes (or have their
>> own clones of the canonical headers).
>> 
>> Also we didn't bother incrementing the version just because of a
>> release on earlier occasions: 3.3 and 3.4 as well as 4.0 and 4.1
>> shared interface versions, yet especially in the case of 4.1 I'm
>> pretty certain even without explicitly checking that there were
>> tool stack interface changes.
> 
> I always thought __XEN_(LATEST_)INTERFACE_VERSION__ were more to do with
> API rather than ABI, i.e. it gets used to revert
> __HYPERVISOR_sched_op_compat into providing __HYPERVISOR_sched_op for
> older consumers and things like that.

For __XEN_INTERFACE_VERSION__ - yes. But
__XEN_LATEST_INTERFACE_VERSION__ mainly announces
the version and is used to set the former if otherwise unset.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:24:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xld9c-00035I-UH; Tue, 04 Nov 2014 12:24:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xld9a-00035A-P5
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:24:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6F/B3-09842-665C8545; Tue, 04 Nov 2014 12:24:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415103845!12636057!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4420 invoked from network); 4 Nov 2014 12:24:05 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 12:24:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 04 Nov 2014 12:24:04 +0000
Message-Id: <5458D3720200007800044C8B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 04 Nov 2014 12:24:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <5458BCA9.3000304@citrix.com>
	<1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
	<5458CDF70200007800044C30@mail.emea.novell.com>
	<1415102930.11486.40.camel@citrix.com>
In-Reply-To: <1415102930.11486.40.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen: Bump Xen interface for
	Xen-4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.11.14 at 13:08, <Ian.Campbell@citrix.com> wrote:
> On Tue, 2014-11-04 at 12:00 +0000, Jan Beulich wrote:
>> >>> On 04.11.14 at 12:50, <andrew.cooper3@citrix.com> wrote:
>> > c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
>> > structures associated with xen_hvm_{get,set}_mem_access from the Xen public
>> > API.
>> > 
>> > While these were toolstack hypercalls and documented as liable to change in
>> > the future, it causes build issues for certain tools (valgrind, strace).
>> > 
>> > As HVM ops have no specific interface version, the main Xen interface 
>> > version
>> > needs to be bumped to compensate.
>> 
>> Content-wise I don't really object to this patch, but I view it as
>> merely cosmetic rather than fixing anything: Tool stack interfaces
>> are declared to be volatile just because we want to avoid exactly
>> this need for bumping versions or anything when altering or
>> dropping them. If there are out of tree consumers of them, it is
>> their responsibility to keep up with our changes (or have their
>> own clones of the canonical headers).
>> 
>> Also we didn't bother incrementing the version just because of a
>> release on earlier occasions: 3.3 and 3.4 as well as 4.0 and 4.1
>> shared interface versions, yet especially in the case of 4.1 I'm
>> pretty certain even without explicitly checking that there were
>> tool stack interface changes.
> 
> I always thought __XEN_(LATEST_)INTERFACE_VERSION__ were more to do with
> API rather than ABI, i.e. it gets used to revert
> __HYPERVISOR_sched_op_compat into providing __HYPERVISOR_sched_op for
> older consumers and things like that.

For __XEN_INTERFACE_VERSION__ - yes. But
__XEN_LATEST_INTERFACE_VERSION__ mainly announces
the version and is used to set the former if otherwise unset.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:47:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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 1XldVy-0003Ze-Ec; Tue, 04 Nov 2014 12:47:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XldVw-0003ZZ-Vd
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:47:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	7B/29-09936-0DAC8545; Tue, 04 Nov 2014 12:47:12 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415105231!12646742!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7706 invoked from network); 4 Nov 2014 12:47:11 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 12:47:11 -0000
Received: by mail-wi0-f177.google.com with SMTP id ex7so9177721wid.4
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 04:47:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=nC/xa7UHL9OKwqwNsqMFo+cIApFMoqRgqh4Mo0PSU68=;
	b=c0wdDHr4nWdLwa0ugEEctzpkTKckg8KAUImiwEw23pRF2cx6D7Jv7oz4EjH3mddHfU
	iyy3oatgfINasdCTuIpkVe/EgKO3wl9yDdtgas9QbaYP2WHUlI5zMuDFhKc5aV57Ezq8
	WUL203Mgr7XPKZSppSM6vGBeGvnNjGHmi+yBSLiGkmnZaPfJjaqAIcN/qmcTjl6X/1VZ
	HXuiZOZJH+WgUI+zRGit20GEFi9fqIPyi8JqOyDMLJtyhEhtmdJzmDhTHVXtMB3Gk8jF
	6zK2w45k0eO0tGO8OzEUv2/5jXh0xgr+lb0tevmMl02XA9lWuoG6mcFX3BzbFT3tFf3x
	gF0A==
X-Gm-Message-State: ALoCoQmHq9CVzIbjF6dVJmrLwAoBWNJv+upWc/vTMEkEdVO5GP6yif5GD6OalRso5x1f3TXU3qGr
X-Received: by 10.194.77.233 with SMTP id v9mr5442571wjw.24.1415105231419;
	Tue, 04 Nov 2014 04:47:11 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fr6sm955387wic.1.2014.11.04.04.46.59
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 04:47:10 -0800 (PST)
Message-ID: <5458CABC.9010607@linaro.org>
Date: Tue, 04 Nov 2014 12:46:52 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
Cc: tim@xen.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2014 04:21 PM, Ian Campbell wrote:
> Vexpress is currently failing to boot for me with:
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x118/0x1a4()
> CPU: 0 PID: 1 Comm: swapper Tainted: G        W     3.16.0-arm-native+ #276
> [<c0011e9c>] (unwind_backtrace) from [<c0010758>] (show_stack+0x10/0x14)
> [<c0010758>] (show_stack) from [<c001a3ec>] (warn_slowpath_common+0x5c/0x7c)
> [<c001a3ec>] (warn_slowpath_common) from [<c001a4c8>] (warn_slowpath_null+0x18/0x20)
> [<c001a4c8>] (warn_slowpath_null) from [<c001488c>] (__arm_ioremap_pfn_caller+0x118/0x1a4)
> [<c001488c>] (__arm_ioremap_pfn_caller) from [<c00149a0>] (__arm_ioremap+0x14/0x20)
> [<c00149a0>] (__arm_ioremap) from [<c01d103c>] (gnttab_setup_auto_xlat_frames+0x30/0xdc)
> [<c01d103c>] (gnttab_setup_auto_xlat_frames) from [<c0495324>] (xen_guest_init+0x19c/0x2d4)
> [<c0495324>] (xen_guest_init) from [<c0492c6c>] (do_one_initcall+0xfc/0x1a4)
> [<c0492c6c>] (do_one_initcall) from [<c0492d6c>] (kernel_init_freeable+0x58/0x1b4)
> [<c0492d6c>] (kernel_init_freeable) from [<c039611c>] (kernel_init+0x8/0xe4)
> [<c039611c>] (kernel_init) from [<c000de58>] (ret_from_fork+0x14/0x3c)
> ---[ end trace 3406ff24bd97382f ]---
> xen:grant_table: Failed to ioremap gnttab share frames (addr=0x00000000b0000000)!
> 
> which is:
>         /*
>          * Don't allow RAM to be mapped - this causes problems with ARMv6+
>          */
>         if (WARN_ON(pfn_valid(pfn)))
>                 return NULL;
> 
> This makes sense since the gnttab defaults to 0xb000000 and my dom0
> is being allocated a 1:1 mapping at 0xa0000000-0xc0000000.
> 
> I suspect this broke around the time we stopped forcing dom0 memory to be
> allocated as low as possible which happened to prevent the default dom0_gnttab
> region overlapping RAM.
> 
> This patch specifies an explicit dom0_gnttab base which is explicitly unused
> according to the FVP model docs (although it correpsonds to CS5 this isn't

NIT: corresponds

> wired up to anything).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:47:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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 1XldVy-0003Ze-Ec; Tue, 04 Nov 2014 12:47:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XldVw-0003ZZ-Vd
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:47:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	7B/29-09936-0DAC8545; Tue, 04 Nov 2014 12:47:12 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415105231!12646742!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7706 invoked from network); 4 Nov 2014 12:47:11 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 12:47:11 -0000
Received: by mail-wi0-f177.google.com with SMTP id ex7so9177721wid.4
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 04:47:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=nC/xa7UHL9OKwqwNsqMFo+cIApFMoqRgqh4Mo0PSU68=;
	b=c0wdDHr4nWdLwa0ugEEctzpkTKckg8KAUImiwEw23pRF2cx6D7Jv7oz4EjH3mddHfU
	iyy3oatgfINasdCTuIpkVe/EgKO3wl9yDdtgas9QbaYP2WHUlI5zMuDFhKc5aV57Ezq8
	WUL203Mgr7XPKZSppSM6vGBeGvnNjGHmi+yBSLiGkmnZaPfJjaqAIcN/qmcTjl6X/1VZ
	HXuiZOZJH+WgUI+zRGit20GEFi9fqIPyi8JqOyDMLJtyhEhtmdJzmDhTHVXtMB3Gk8jF
	6zK2w45k0eO0tGO8OzEUv2/5jXh0xgr+lb0tevmMl02XA9lWuoG6mcFX3BzbFT3tFf3x
	gF0A==
X-Gm-Message-State: ALoCoQmHq9CVzIbjF6dVJmrLwAoBWNJv+upWc/vTMEkEdVO5GP6yif5GD6OalRso5x1f3TXU3qGr
X-Received: by 10.194.77.233 with SMTP id v9mr5442571wjw.24.1415105231419;
	Tue, 04 Nov 2014 04:47:11 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fr6sm955387wic.1.2014.11.04.04.46.59
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 04:47:10 -0800 (PST)
Message-ID: <5458CABC.9010607@linaro.org>
Date: Tue, 04 Nov 2014 12:46:52 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
Cc: tim@xen.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2014 04:21 PM, Ian Campbell wrote:
> Vexpress is currently failing to boot for me with:
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x118/0x1a4()
> CPU: 0 PID: 1 Comm: swapper Tainted: G        W     3.16.0-arm-native+ #276
> [<c0011e9c>] (unwind_backtrace) from [<c0010758>] (show_stack+0x10/0x14)
> [<c0010758>] (show_stack) from [<c001a3ec>] (warn_slowpath_common+0x5c/0x7c)
> [<c001a3ec>] (warn_slowpath_common) from [<c001a4c8>] (warn_slowpath_null+0x18/0x20)
> [<c001a4c8>] (warn_slowpath_null) from [<c001488c>] (__arm_ioremap_pfn_caller+0x118/0x1a4)
> [<c001488c>] (__arm_ioremap_pfn_caller) from [<c00149a0>] (__arm_ioremap+0x14/0x20)
> [<c00149a0>] (__arm_ioremap) from [<c01d103c>] (gnttab_setup_auto_xlat_frames+0x30/0xdc)
> [<c01d103c>] (gnttab_setup_auto_xlat_frames) from [<c0495324>] (xen_guest_init+0x19c/0x2d4)
> [<c0495324>] (xen_guest_init) from [<c0492c6c>] (do_one_initcall+0xfc/0x1a4)
> [<c0492c6c>] (do_one_initcall) from [<c0492d6c>] (kernel_init_freeable+0x58/0x1b4)
> [<c0492d6c>] (kernel_init_freeable) from [<c039611c>] (kernel_init+0x8/0xe4)
> [<c039611c>] (kernel_init) from [<c000de58>] (ret_from_fork+0x14/0x3c)
> ---[ end trace 3406ff24bd97382f ]---
> xen:grant_table: Failed to ioremap gnttab share frames (addr=0x00000000b0000000)!
> 
> which is:
>         /*
>          * Don't allow RAM to be mapped - this causes problems with ARMv6+
>          */
>         if (WARN_ON(pfn_valid(pfn)))
>                 return NULL;
> 
> This makes sense since the gnttab defaults to 0xb000000 and my dom0
> is being allocated a 1:1 mapping at 0xa0000000-0xc0000000.
> 
> I suspect this broke around the time we stopped forcing dom0 memory to be
> allocated as low as possible which happened to prevent the default dom0_gnttab
> region overlapping RAM.
> 
> This patch specifies an explicit dom0_gnttab base which is explicitly unused
> according to the FVP model docs (although it correpsonds to CS5 this isn't

NIT: corresponds

> wired up to anything).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:48:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12: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.xen.org>)
	id 1XldX8-0003dn-Tt; Tue, 04 Nov 2014 12:48:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XldX6-0003dc-Tr
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:48:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	07/7B-24532-81BC8545; Tue, 04 Nov 2014 12:48:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415105303!12643699!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32000 invoked from network); 4 Nov 2014 12:48:23 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 12:48:23 -0000
Received: by mail-wi0-f177.google.com with SMTP id ex7so9165557wid.10
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 04:48:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=Iwg/BPrhm0nmjmi/fW5kWqM5mVfcKctRdq04yt5bWIw=;
	b=JfDdfe3ynyqIRo0zptbfF85PRix6rcfY1Wo+IxlJnazkvFOTdw6RXtTurwaxe6Eyz5
	T/435Q38ifFd8Rq5/y7jfwdkPUd9dYdmjbKFGnM82OaPrEMDNKv2JVbHsP0Pl4y6tE/x
	UNuvN1lpjsamt2omiZIeZ5vYHT6rxjZo0lbbCc8uehxUqJi0XtMpvXTPyK/3YA/n/e+u
	HNIDOWkSmCim+9ZtbY+bcc37TVegaQeZ4neZ7S6kqHv61QwiG8qxO/l3fSLAwafyWee9
	Ea/jjZnVurBKMG3AusJ43HG+D/jIvmSiwMChun+gCMssjfTkNY8xyNDAXSYIPV8Zt653
	sOrw==
X-Gm-Message-State: ALoCoQlfoGMEdJGeivGGu66k7C25ZG7Rk+Mta6ukYn0ABd7zTz6IYZNpNNPStgaXot0GAvC7MKPL
X-Received: by 10.194.63.229 with SMTP id j5mr56231341wjs.23.1415105303286;
	Tue, 04 Nov 2014 04:48:23 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id w10sm450467wje.10.2014.11.04.04.48.21
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 04:48:22 -0800 (PST)
Message-ID: <5458CB0F.7000600@linaro.org>
Date: Tue, 04 Nov 2014 12:48:15 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
	<1415096249.11486.12.camel@citrix.com>
	<alpine.DEB.2.02.1411041019300.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411041019300.22875@kaball.uk.xensource.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2014 10:20 AM, Stefano Stabellini wrote:
> On Tue, 4 Nov 2014, Ian Campbell wrote:
>> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
>>
>> I think we should apply this workaround for 4.5 and do things properly
>> for 4.6. Any thoughts?
>  
> I agree with you

+1

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:48:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12: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.xen.org>)
	id 1XldX8-0003dn-Tt; Tue, 04 Nov 2014 12:48:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XldX6-0003dc-Tr
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 12:48:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	07/7B-24532-81BC8545; Tue, 04 Nov 2014 12:48:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415105303!12643699!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32000 invoked from network); 4 Nov 2014 12:48:23 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 12:48:23 -0000
Received: by mail-wi0-f177.google.com with SMTP id ex7so9165557wid.10
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 04:48:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=Iwg/BPrhm0nmjmi/fW5kWqM5mVfcKctRdq04yt5bWIw=;
	b=JfDdfe3ynyqIRo0zptbfF85PRix6rcfY1Wo+IxlJnazkvFOTdw6RXtTurwaxe6Eyz5
	T/435Q38ifFd8Rq5/y7jfwdkPUd9dYdmjbKFGnM82OaPrEMDNKv2JVbHsP0Pl4y6tE/x
	UNuvN1lpjsamt2omiZIeZ5vYHT6rxjZo0lbbCc8uehxUqJi0XtMpvXTPyK/3YA/n/e+u
	HNIDOWkSmCim+9ZtbY+bcc37TVegaQeZ4neZ7S6kqHv61QwiG8qxO/l3fSLAwafyWee9
	Ea/jjZnVurBKMG3AusJ43HG+D/jIvmSiwMChun+gCMssjfTkNY8xyNDAXSYIPV8Zt653
	sOrw==
X-Gm-Message-State: ALoCoQlfoGMEdJGeivGGu66k7C25ZG7Rk+Mta6ukYn0ABd7zTz6IYZNpNNPStgaXot0GAvC7MKPL
X-Received: by 10.194.63.229 with SMTP id j5mr56231341wjs.23.1415105303286;
	Tue, 04 Nov 2014 04:48:23 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id w10sm450467wje.10.2014.11.04.04.48.21
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 04:48:22 -0800 (PST)
Message-ID: <5458CB0F.7000600@linaro.org>
Date: Tue, 04 Nov 2014 12:48:15 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
	<1415096249.11486.12.camel@citrix.com>
	<alpine.DEB.2.02.1411041019300.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411041019300.22875@kaball.uk.xensource.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2014 10:20 AM, Stefano Stabellini wrote:
> On Tue, 4 Nov 2014, Ian Campbell wrote:
>> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
>>
>> I think we should apply this workaround for 4.5 and do things properly
>> for 4.6. Any thoughts?
>  
> I agree with you

+1

Regards,

-- 
Julien Grall

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:56:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:56:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldf4-000409-W4; Tue, 04 Nov 2014 12:56:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xldf2-000404-U0
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 12:56:37 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	5F/DF-02576-10DC8545; Tue, 04 Nov 2014 12:56:33 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415105791!12476106!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21336 invoked from network); 4 Nov 2014 12:56:32 -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;
	4 Nov 2014 12:56:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187882484"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 07:56:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XldeX-00063a-62;
	Tue, 04 Nov 2014 12:56:05 +0000
Received: from iwj by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XldeU-0007Ka-R2;
	Tue, 04 Nov 2014 12:56:02 +0000
Date: Tue, 4 Nov 2014 12:56:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31338-mainreport@xen.org>
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31338: 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 31338 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31338/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 31315
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 31315 pass in 31338
 test-amd64-amd64-pair         8 xen-boot/dst_host  fail in 31315 pass in 31338

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31285
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31285

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31315 never pass

version targeted for testing:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c
baseline version:
 xen                  0f2bde078ace619fe8e26730495b6ef2c3a2e9bf

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=5283b310e14884341f51be35253cdd59c4cb034c
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 5283b310e14884341f51be35253cdd59c4cb034c
+ branch=xen-unstable
+ revision=5283b310e14884341f51be35253cdd59c4cb034c
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 5283b310e14884341f51be35253cdd59c4cb034c:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   0f2bde0..5283b31  5283b310e14884341f51be35253cdd59c4cb034c -> master

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:56:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:56:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldf4-000409-W4; Tue, 04 Nov 2014 12:56:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xldf2-000404-U0
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 12:56:37 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	5F/DF-02576-10DC8545; Tue, 04 Nov 2014 12:56:33 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415105791!12476106!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21336 invoked from network); 4 Nov 2014 12:56:32 -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;
	4 Nov 2014 12:56:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187882484"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 07:56:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XldeX-00063a-62;
	Tue, 04 Nov 2014 12:56:05 +0000
Received: from iwj by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XldeU-0007Ka-R2;
	Tue, 04 Nov 2014 12:56:02 +0000
Date: Tue, 4 Nov 2014 12:56:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31338-mainreport@xen.org>
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31338: 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 31338 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31338/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 31315
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 31315 pass in 31338
 test-amd64-amd64-pair         8 xen-boot/dst_host  fail in 31315 pass in 31338

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31285
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31285

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31315 never pass

version targeted for testing:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c
baseline version:
 xen                  0f2bde078ace619fe8e26730495b6ef2c3a2e9bf

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=5283b310e14884341f51be35253cdd59c4cb034c
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 5283b310e14884341f51be35253cdd59c4cb034c
+ branch=xen-unstable
+ revision=5283b310e14884341f51be35253cdd59c4cb034c
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 5283b310e14884341f51be35253cdd59c4cb034c:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   0f2bde0..5283b31  5283b310e14884341f51be35253cdd59c4cb034c -> master

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:59:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldhP-00047i-NH; Tue, 04 Nov 2014 12:59:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XldhN-00047c-WA
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 12:59:02 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	D0/C1-07724-59DC8545; Tue, 04 Nov 2014 12:59:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415105939!11479836!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23417 invoked from network); 4 Nov 2014 12:59:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 12:59:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189264068"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 07:58:58 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XldhK-0004jX-AA;
	Tue, 04 Nov 2014 12:58:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XldhJ-0000dA-RZ;
	Tue, 04 Nov 2014 12:58:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21592.52625.429757.553852@mariner.uk.xensource.com>
Date: Tue, 4 Nov 2014 12:58:57 +0000
To: <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-31338-mainreport@xen.org>
References: <osstest-31338-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 31338: 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 Jackson writes ("[xen-unstable test] 31338: tolerable FAIL - PUSHED"):
> flight 31338 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31338/

This email wasn't sent before because of a network problem publishing
the logs.  I have manually fished the email out of osstest's innards
and I'm transferring the logs now.

Thanks to Jan Beulich for noticing that something was wrong.

Ian.

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 12:59:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 12:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldhP-00047i-NH; Tue, 04 Nov 2014 12:59:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XldhN-00047c-WA
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 12:59:02 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	D0/C1-07724-59DC8545; Tue, 04 Nov 2014 12:59:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415105939!11479836!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23417 invoked from network); 4 Nov 2014 12:59:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 12:59:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189264068"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 07:58:58 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XldhK-0004jX-AA;
	Tue, 04 Nov 2014 12:58:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XldhJ-0000dA-RZ;
	Tue, 04 Nov 2014 12:58:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21592.52625.429757.553852@mariner.uk.xensource.com>
Date: Tue, 4 Nov 2014 12:58:57 +0000
To: <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-31338-mainreport@xen.org>
References: <osstest-31338-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 31338: 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 Jackson writes ("[xen-unstable test] 31338: tolerable FAIL - PUSHED"):
> flight 31338 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31338/

This email wasn't sent before because of a network problem publishing
the logs.  I have manually fished the email out of osstest's innards
and I'm transferring the logs now.

Thanks to Jan Beulich for noticing that something was wrong.

Ian.

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:08:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1Xldpu-0004Ul-Qa; Tue, 04 Nov 2014 13:07:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldpt-0004Ug-4m
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:07:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	93/C8-24532-4AFC8545; Tue, 04 Nov 2014 13:07:48 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415106465!9235830!1
X-Originating-IP: [64.18.0.198]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15340 invoked from network); 4 Nov 2014 13:07:47 -0000
Received: from exprod5og123.obsmtp.com (HELO exprod5og123.obsmtp.com)
	(64.18.0.198)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:07:47 -0000
Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by
	exprod5ob123.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjPoVszyTY89aLCCcchcUgP3EvGxG7N@postini.com;
	Tue, 04 Nov 2014 05:07:47 PST
Received: by mail-qa0-f45.google.com with SMTP id dc16so9799912qab.32
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:07:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=iHW45kyIAQtn8bJW5w3mR2zXnS3BTYdLkaUDz+DvKao=;
	b=LG83NfBFqWbnr2SN4M5nPbQQqQs3Xv9UUqRgxURLhRtAjPwN8TV9KDOzwWkvYH0faV
	D381V/R4290iFJzsjVItszDABD7Fx4R8asoSdjWkgJoSB+d1zkO1ivxKkKDwgb27F+gd
	1M5MlhEEXxkb+GDCSC5lRrdKzYnfKxIoXJPwg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=iHW45kyIAQtn8bJW5w3mR2zXnS3BTYdLkaUDz+DvKao=;
	b=BpLzhFRwE9BOjzuEWAtrtbhTdEKPk3SbK4DJN62dJnsVQK2EPSiNkcgzmx/jRZzm+C
	qOG/Xjzp7PTib3laukLjAAV3+GLaCeMndCUXIDpxpZtC3z12o5T1Yw0ubxmc+ww+EJeo
	0G7l5SDi02iLXfyZ5XmLk/rOv7fAj9A88ktv/YpJxS2Q5d5R+UP7CgZZJFIe7lOh+BZI
	8A/9voZpiHHoXLyuvi4dEyXvlGSCiYKiIroqzAAFxVnVtqTG+wX6D/AMIMS6/obnry49
	576Zewoqu5x6qR4zq/TTeFbRFe9JO5Ehzkg3BT6TuhQ5UngiIi7DWdSdtz9DHVWUmmnd
	PoLQ==
X-Gm-Message-State: ALoCoQkTELLPrRn8evW/Uh++ON+vubtVtqWbgcXpsXauqaGSAhLs5dqLOSe+Yuo349G3VZWCVlFoHysr+FDdyWZ/VCIbwwOlqGIDQOf187viZgJZ6LMgeCLsRYPhlz3WVUBNRvyfV+wOJqqq5UOPcOQIONh4XvJagw==
X-Received: by 10.224.112.66 with SMTP id v2mr2619611qap.22.1415106465126;
	Tue, 04 Nov 2014 05:07:45 -0800 (PST)
X-Received: by 10.224.112.66 with SMTP id v2mr2619577qap.22.1415106464892;
	Tue, 04 Nov 2014 05:07:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Tue, 4 Nov 2014 05:07:24 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1410261734220.22875@kaball.uk.xensource.com>
References: <1414076916-2231-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1410261734220.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Tue, 4 Nov 2014 15:07:24 +0200
Message-ID: <CAN58jivz9znW_k+YaSqzit1gt63L4terU=Rqj3Q4KuZWs_=ytg@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v3 0/8] xen_cpufreq implementation in
	kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Oct 26, 2014 at 7:38 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>
> On Thu, 23 Oct 2014, Oleksandr Dmytryshyn wrote:
> > Hi to all.
> >
> > Next series of patches implements xen-cpufreq driver in kernel.
> >
> > Cpufreq core and registered cpufreq governors are located in xen. Dom0 has CPU
> > driver which can only change frequency of the physical CPUs. In addition this
> > driver can change CPUs regulator voltage. At start time xen-cpufreq driver
> > in kernel uploads to Xen information about physical cpus.
> > Xen notifies Dom0 kernel using VIRQ_CPUFREQ interrupt. Then xen-cpufreq driver
> > in kernel uses XEN_SYSCTL_cpufreq_op operation from HYPERVISOR_sysctl hypercall
> > to get some parameters from Xen (frequency, relation and cpu number).
> > Then xen-cpufreq changes frequency on physical cpu and uses the same
> > XEN_SYSCTL_cpufreq_op operation ti give the result to Xen.
>
> This doesn't seem to be very efficient: many hypercalls for a single
> operation. I think it would be best to come up with an interface that
> doesn't require so many back and forth. Maybe we could have a shared
> struct somewhere in memory for Xen to export information.
>
> BTW we are still waiting for benchmarks :-)
I'll try to start benchmarks a bit later.

>
> > Next configs should be enabled to use xen-cpufreq driver:
> > CONFIG_GENERIC_CPUFREQ_CPU0
> > CONFIG_XEN_CPUFREQ
> >
> > Changed since v1:
> >  * added cpufreq_drv_ops which allows to use more than one high-level
> >    cpufreq driver
> >  * reworked xen-cpufreq and drivers so the same kernel is able to run
> >    on bare metal and within Xen.
> >
> > Changed since v2:
> >  * used VIRQ_CPUFREQ with number 14 instead of the 13
> >  * slightly reworked xen-cpufreq driver
> >
> > Oleksandr Dmytryshyn (8):
> >   PM / OPP: make cpufreq functions dependent on CONFIG_CPU_FREQ_TABLE
> >   xen/arm: implement HYPERVISOR_sysctl
> >   xen/arm: implement HYPERVISOR_dom0_op
> >   xen/arm: add XEN_SYSCTL_cpufreq_op definition
> >   cpufreq: cpufreq-cpu0: change cpus data path in devtree for Dom0
> >     kernel
> >   cpufreq: introduce cpufreq_drv_ops
> >   cpufreq: make cpufreq low-level drivers visible for CPUFREQ_DRV_OPS
> >     config
> >   xen/arm: cpufreq: add xen-cpufreq driver
> >
> >  arch/arm/include/asm/xen/hypercall.h |   2 +
> >  arch/arm/include/asm/xen/interface.h |   2 +
> >  arch/arm/xen/enlighten.c             |   2 +
> >  arch/arm/xen/hypercall.S             |   2 +
> >  drivers/Makefile                     |   2 +-
> >  drivers/base/power/opp.c             |   4 +-
> >  drivers/cpufreq/Kconfig              |  39 +-
> >  drivers/cpufreq/Makefile             |   2 +
> >  drivers/cpufreq/acpi-cpufreq.c       |   5 +-
> >  drivers/cpufreq/cpufreq-cpu0.c       |  10 +-
> >  drivers/cpufreq/cpufreq.c            | 116 +++--
> >  drivers/cpufreq/cpufreq_drv_ops.c    | 196 ++++++++
> >  drivers/cpufreq/cpufreq_drv_ops.h    |  54 +++
> >  drivers/cpufreq/cpufreq_governor.c   |   4 +-
> >  drivers/cpufreq/xen-cpufreq.c        | 889 +++++++++++++++++++++++++++++++++++
> >  include/linux/cpufreq.h              |   2 +-
> >  include/linux/opp.h                  |   2 +-
> >  include/xen/interface/platform.h     |   1 +
> >  include/xen/interface/sysctl.h       | 664 ++++++++++++++++++++++++++
> >  include/xen/interface/xen.h          |   7 +
> >  20 files changed, 1939 insertions(+), 66 deletions(-)
> >  create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
> >  create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h
> >  create mode 100644 drivers/cpufreq/xen-cpufreq.c
> >  create mode 100644 include/xen/interface/sysctl.h
> >
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:08:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1Xldpu-0004Ul-Qa; Tue, 04 Nov 2014 13:07:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldpt-0004Ug-4m
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:07:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	93/C8-24532-4AFC8545; Tue, 04 Nov 2014 13:07:48 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415106465!9235830!1
X-Originating-IP: [64.18.0.198]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15340 invoked from network); 4 Nov 2014 13:07:47 -0000
Received: from exprod5og123.obsmtp.com (HELO exprod5og123.obsmtp.com)
	(64.18.0.198)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:07:47 -0000
Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by
	exprod5ob123.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjPoVszyTY89aLCCcchcUgP3EvGxG7N@postini.com;
	Tue, 04 Nov 2014 05:07:47 PST
Received: by mail-qa0-f45.google.com with SMTP id dc16so9799912qab.32
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:07:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=iHW45kyIAQtn8bJW5w3mR2zXnS3BTYdLkaUDz+DvKao=;
	b=LG83NfBFqWbnr2SN4M5nPbQQqQs3Xv9UUqRgxURLhRtAjPwN8TV9KDOzwWkvYH0faV
	D381V/R4290iFJzsjVItszDABD7Fx4R8asoSdjWkgJoSB+d1zkO1ivxKkKDwgb27F+gd
	1M5MlhEEXxkb+GDCSC5lRrdKzYnfKxIoXJPwg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=iHW45kyIAQtn8bJW5w3mR2zXnS3BTYdLkaUDz+DvKao=;
	b=BpLzhFRwE9BOjzuEWAtrtbhTdEKPk3SbK4DJN62dJnsVQK2EPSiNkcgzmx/jRZzm+C
	qOG/Xjzp7PTib3laukLjAAV3+GLaCeMndCUXIDpxpZtC3z12o5T1Yw0ubxmc+ww+EJeo
	0G7l5SDi02iLXfyZ5XmLk/rOv7fAj9A88ktv/YpJxS2Q5d5R+UP7CgZZJFIe7lOh+BZI
	8A/9voZpiHHoXLyuvi4dEyXvlGSCiYKiIroqzAAFxVnVtqTG+wX6D/AMIMS6/obnry49
	576Zewoqu5x6qR4zq/TTeFbRFe9JO5Ehzkg3BT6TuhQ5UngiIi7DWdSdtz9DHVWUmmnd
	PoLQ==
X-Gm-Message-State: ALoCoQkTELLPrRn8evW/Uh++ON+vubtVtqWbgcXpsXauqaGSAhLs5dqLOSe+Yuo349G3VZWCVlFoHysr+FDdyWZ/VCIbwwOlqGIDQOf187viZgJZ6LMgeCLsRYPhlz3WVUBNRvyfV+wOJqqq5UOPcOQIONh4XvJagw==
X-Received: by 10.224.112.66 with SMTP id v2mr2619611qap.22.1415106465126;
	Tue, 04 Nov 2014 05:07:45 -0800 (PST)
X-Received: by 10.224.112.66 with SMTP id v2mr2619577qap.22.1415106464892;
	Tue, 04 Nov 2014 05:07:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Tue, 4 Nov 2014 05:07:24 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1410261734220.22875@kaball.uk.xensource.com>
References: <1414076916-2231-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1410261734220.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Tue, 4 Nov 2014 15:07:24 +0200
Message-ID: <CAN58jivz9znW_k+YaSqzit1gt63L4terU=Rqj3Q4KuZWs_=ytg@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v3 0/8] xen_cpufreq implementation in
	kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Oct 26, 2014 at 7:38 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>
> On Thu, 23 Oct 2014, Oleksandr Dmytryshyn wrote:
> > Hi to all.
> >
> > Next series of patches implements xen-cpufreq driver in kernel.
> >
> > Cpufreq core and registered cpufreq governors are located in xen. Dom0 has CPU
> > driver which can only change frequency of the physical CPUs. In addition this
> > driver can change CPUs regulator voltage. At start time xen-cpufreq driver
> > in kernel uploads to Xen information about physical cpus.
> > Xen notifies Dom0 kernel using VIRQ_CPUFREQ interrupt. Then xen-cpufreq driver
> > in kernel uses XEN_SYSCTL_cpufreq_op operation from HYPERVISOR_sysctl hypercall
> > to get some parameters from Xen (frequency, relation and cpu number).
> > Then xen-cpufreq changes frequency on physical cpu and uses the same
> > XEN_SYSCTL_cpufreq_op operation ti give the result to Xen.
>
> This doesn't seem to be very efficient: many hypercalls for a single
> operation. I think it would be best to come up with an interface that
> doesn't require so many back and forth. Maybe we could have a shared
> struct somewhere in memory for Xen to export information.
>
> BTW we are still waiting for benchmarks :-)
I'll try to start benchmarks a bit later.

>
> > Next configs should be enabled to use xen-cpufreq driver:
> > CONFIG_GENERIC_CPUFREQ_CPU0
> > CONFIG_XEN_CPUFREQ
> >
> > Changed since v1:
> >  * added cpufreq_drv_ops which allows to use more than one high-level
> >    cpufreq driver
> >  * reworked xen-cpufreq and drivers so the same kernel is able to run
> >    on bare metal and within Xen.
> >
> > Changed since v2:
> >  * used VIRQ_CPUFREQ with number 14 instead of the 13
> >  * slightly reworked xen-cpufreq driver
> >
> > Oleksandr Dmytryshyn (8):
> >   PM / OPP: make cpufreq functions dependent on CONFIG_CPU_FREQ_TABLE
> >   xen/arm: implement HYPERVISOR_sysctl
> >   xen/arm: implement HYPERVISOR_dom0_op
> >   xen/arm: add XEN_SYSCTL_cpufreq_op definition
> >   cpufreq: cpufreq-cpu0: change cpus data path in devtree for Dom0
> >     kernel
> >   cpufreq: introduce cpufreq_drv_ops
> >   cpufreq: make cpufreq low-level drivers visible for CPUFREQ_DRV_OPS
> >     config
> >   xen/arm: cpufreq: add xen-cpufreq driver
> >
> >  arch/arm/include/asm/xen/hypercall.h |   2 +
> >  arch/arm/include/asm/xen/interface.h |   2 +
> >  arch/arm/xen/enlighten.c             |   2 +
> >  arch/arm/xen/hypercall.S             |   2 +
> >  drivers/Makefile                     |   2 +-
> >  drivers/base/power/opp.c             |   4 +-
> >  drivers/cpufreq/Kconfig              |  39 +-
> >  drivers/cpufreq/Makefile             |   2 +
> >  drivers/cpufreq/acpi-cpufreq.c       |   5 +-
> >  drivers/cpufreq/cpufreq-cpu0.c       |  10 +-
> >  drivers/cpufreq/cpufreq.c            | 116 +++--
> >  drivers/cpufreq/cpufreq_drv_ops.c    | 196 ++++++++
> >  drivers/cpufreq/cpufreq_drv_ops.h    |  54 +++
> >  drivers/cpufreq/cpufreq_governor.c   |   4 +-
> >  drivers/cpufreq/xen-cpufreq.c        | 889 +++++++++++++++++++++++++++++++++++
> >  include/linux/cpufreq.h              |   2 +-
> >  include/linux/opp.h                  |   2 +-
> >  include/xen/interface/platform.h     |   1 +
> >  include/xen/interface/sysctl.h       | 664 ++++++++++++++++++++++++++
> >  include/xen/interface/xen.h          |   7 +
> >  20 files changed, 1939 insertions(+), 66 deletions(-)
> >  create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
> >  create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h
> >  create mode 100644 drivers/cpufreq/xen-cpufreq.c
> >  create mode 100644 include/xen/interface/sysctl.h
> >
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >

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

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:08:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:08:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldqu-0004Y0-90; Tue, 04 Nov 2014 13:08:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldqt-0004Xs-1B
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:08:51 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	FB/6A-08051-2EFC8545; Tue, 04 Nov 2014 13:08:50 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415106526!7827837!1
X-Originating-IP: [64.18.0.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31168 invoked from network); 4 Nov 2014 13:08:48 -0000
Received: from exprod5og120.obsmtp.com (HELO exprod5og120.obsmtp.com)
	(64.18.0.137)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:08:48 -0000
Received: from mail-lb0-f179.google.com ([209.85.217.179]) (using TLSv1) by
	exprod5ob120.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP3u5+PA6xslTzWXOZL4pCz5Z9hEdF@postini.com;
	Tue, 04 Nov 2014 05:08:48 PST
Received: by mail-lb0-f179.google.com with SMTP id l4so4390814lbv.38
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id;
	bh=9Nrkqbqh8wxeI4IEk4RGG/JO9VLKRiy7w99krOgceWg=;
	b=jb5C7AusBQgJIrH+Bn8mAuOGEDf4u7nTZimUYuzGmhTRr12oWI23KItLiBXPRlBVTZ
	o+D821wr3r/qcxm5dcdV/4e6y34Bm8cdNg4KF2RM5iw7PgEF8JEmNxjbUaRuq/CVh88p
	gY+n0bagP6V8oAgwbkUHMO4uvd8arUzmFj/u0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=9Nrkqbqh8wxeI4IEk4RGG/JO9VLKRiy7w99krOgceWg=;
	b=Mawo+8FKt+XDL5mu4aAisG336dpRgAwDF0WyAAiNrCIFEF9KmBeLDI5HtuWlzjSl/b
	Gp/OFnmnsjW05iSGyfexG7udamIx3ZEI74Z6AeNEW+vgszGGmpFtDzGMlLGbohN5kWId
	q0iPffUEoF7dSd95tvwrgse3xOU4rWvcv4O3NUsNLoXAy4dk3sbttcRkGJ1Ej3xDgDTD
	hDs6KCoKI5CbahIbPE3QW+PktbojWD2UZ+g2HJqSqedK940tqcvmdpTAAtS9yIztdOxh
	0CgpIApSDH+ewypDggtkQoKA0qMEAEXaAOwn9Mb5hTBgXwYxLXKBhteehTtjHLvbRGCX
	RCuw==
X-Gm-Message-State: ALoCoQmeG8Zb4xP61vSRe4BhDepdM8eIvpVatgXh8yuulJvXUQVGBRXUkwQdENFmo7MooAM9vQ1jZo/ioXfxrXcMLjyFDShLmXo6SYq6IiaysQjXahjDx0QKV5iKVaH6/pklyBV78NfjaFdlMXu9vxf49ZKvgs436g==
X-Received: by 10.153.11.133 with SMTP id ei5mr59499875lad.75.1415106524824;
	Tue, 04 Nov 2014 05:08:44 -0800 (PST)
X-Received: by 10.153.11.133 with SMTP id ei5mr59499864lad.75.1415106524749;
	Tue, 04 Nov 2014 05:08:44 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id w8sm137550lbp.46.2014.11.04.05.08.43
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:44 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:30 +0200
Message-Id: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 00/11] xen_cpufreq implementation in Xen
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi to all.

Next series of patches implements xen-cpufreq driver in Xen hypervisor.

Cpufreq core and registered cpufreq governors are located in xen. Dom0 has CPU
driver which can only change frequency of the physical CPUs. In addition this
driver can change CPUs regulator voltage. At start time xen-cpufreq driver
in kernel uploads to Xen information about physical cpus.
Xen notifies Dom0 kernel using VIRQ_CPUFREQ interrupt. Then xen-cpufreq driver
in kernel uses XEN_SYSCTL_cpufreq_op operation from HYPERVISOR_sysctl hypercall
to get some parameters from Xen (frequency, relation and cpu number).
Then xen-cpufreq changes frequency on physical cpu and uses the same
XEN_SYSCTL_cpufreq_op operation ti give the result to Xen.

Changed since v1:
 * use /xen/include/xen/ instead of the  /xen/include/cpufreq/
   for included files
 * move pmstat.c file to the xen/drivers/pm/stat.c instead of the
   xen/drivers/pm/pmstat.c
 * updated ./MAINTAINERS accordingly to new files location
 * introduce HAS_CPU_TURBO config and use it
 * move ACPI-specific pmstat functions under the CONFIG_ACPI config
   instead of the CONFIG_X86 config
 * correct info message in cpufreq_add_cpu() function (remove _PSD
   prefix for NON ACPI configuration)
 * dropped patch "[RFC PATCH 07/13] xen/arm: enable cpu hotplug"
 * dropped patch "[RFC PATCH 08/13] xen/dts: make the dt_find_property
   function to be global"
 * create PCPUs device tree node in /hypervisor/pcpus node instead
   of the /cpus/cpu@0/private_date/ node
 * reworked platform hypercall implementation (used XSM check
   for ARM architecture) and moved common code to the common
   place.
 * xen-cpufreq driver to the dom0-cpufreq

Changed since v2:
 * corrected comment in xen/drivers/pm/stat.c
 * restored blank line in xen/drivers/pm/stat.c
 * corrected #ifdef in xen/drivers/cpufreq/cpufreq.c
 * removed common file for platform_hypercall implementation
 * renamed dom0-cpufreq.c to hwdom-cpufreq.c
 * slightly reworked file hwdom-cpufreq.c
 * used VIRQ_CPUFREQ with number 14 instead of the 13
 
Changed since v3:
 * some fixes in creating device tree nodes for hwdom cpufreq cpu driver
 * some fixes in hwdom-cpufreq driver
 * removed XEN_SYSCTL_cpufreq_op implementation
 * added cpufreq shared info definition to send commands to the
   hwdom cpufreq driver

Oleksandr Dmytryshyn (11):
  cpufreq: move cpufreq.h file to the xen/include/xen location
  pm: move processor_perf.h file to the xen/include/xen location
  pmstat: move pmstat.c file to the xen/drivers/pm/stat.c location
  cpufreq: make turbo settings to be configurable
  pmstat: make pmstat functions more generalizable
  cpufreq: make cpufreq driver more generalizable
  arch/arm: create device tree nodes for hwdom cpufreq cpu driver
  xen: arm: implement platform hypercall
  xen: arm: add cpufreq shared info definition
  cpufreq: add hwdom-cpufreq driver
  xen/arm: enable cpufreq functionality for ARM

 MAINTAINERS                                        |   3 +-
 xen/Rules.mk                                       |   4 +
 xen/arch/arm/Makefile                              |   1 +
 xen/arch/arm/Rules.mk                              |   3 +
 xen/arch/arm/domain_build.c                        |  78 ++++++-
 xen/arch/arm/platform_hypercall.c                  |  84 +++++++
 xen/arch/arm/traps.c                               |   1 +
 xen/arch/x86/Rules.mk                              |   2 +
 xen/arch/x86/acpi/cpu_idle.c                       |   2 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c                |   2 +-
 xen/arch/x86/acpi/cpufreq/powernow.c               |   2 +-
 xen/arch/x86/acpi/power.c                          |   2 +-
 xen/arch/x86/cpu/mwait-idle.c                      |   2 +-
 xen/arch/x86/platform_hypercall.c                  |   2 +-
 xen/common/sysctl.c                                |   2 +-
 xen/drivers/Makefile                               |   1 +
 xen/drivers/acpi/Makefile                          |   1 -
 xen/drivers/cpufreq/Makefile                       |   1 +
 xen/drivers/cpufreq/cpufreq.c                      |  82 ++++++-
 xen/drivers/cpufreq/cpufreq_misc_governors.c       |   2 +-
 xen/drivers/cpufreq/cpufreq_ondemand.c             |   4 +-
 xen/drivers/cpufreq/hwdom-cpufreq.c                | 252 +++++++++++++++++++++
 xen/drivers/cpufreq/utility.c                      |  13 +-
 xen/drivers/pm/Makefile                            |   1 +
 xen/drivers/{acpi/pmstat.c => pm/stat.c}           |  16 +-
 xen/include/asm-arm/shared.h                       |  14 ++
 xen/include/public/arch-arm.h                      |   8 +
 xen/include/public/platform.h                      |   1 +
 xen/include/public/xen.h                           |   1 +
 xen/include/{acpi/cpufreq => xen}/cpufreq.h        |  13 +-
 xen/include/{acpi/cpufreq => xen}/processor_perf.h |   7 +
 xen/include/xsm/dummy.h                            |  12 +-
 xen/include/xsm/xsm.h                              |  10 +-
 xen/xsm/flask/hooks.c                              |   3 +-
 34 files changed, 587 insertions(+), 45 deletions(-)
 create mode 100644 xen/arch/arm/platform_hypercall.c
 create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c
 create mode 100644 xen/drivers/pm/Makefile
 rename xen/drivers/{acpi/pmstat.c => pm/stat.c} (97%)
 create mode 100644 xen/include/asm-arm/shared.h
 rename xen/include/{acpi/cpufreq => xen}/cpufreq.h (97%)
 rename xen/include/{acpi/cpufreq => xen}/processor_perf.h (95%)

-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:08:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:08:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldqu-0004Y0-90; Tue, 04 Nov 2014 13:08:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldqt-0004Xs-1B
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:08:51 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	FB/6A-08051-2EFC8545; Tue, 04 Nov 2014 13:08:50 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415106526!7827837!1
X-Originating-IP: [64.18.0.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31168 invoked from network); 4 Nov 2014 13:08:48 -0000
Received: from exprod5og120.obsmtp.com (HELO exprod5og120.obsmtp.com)
	(64.18.0.137)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:08:48 -0000
Received: from mail-lb0-f179.google.com ([209.85.217.179]) (using TLSv1) by
	exprod5ob120.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP3u5+PA6xslTzWXOZL4pCz5Z9hEdF@postini.com;
	Tue, 04 Nov 2014 05:08:48 PST
Received: by mail-lb0-f179.google.com with SMTP id l4so4390814lbv.38
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id;
	bh=9Nrkqbqh8wxeI4IEk4RGG/JO9VLKRiy7w99krOgceWg=;
	b=jb5C7AusBQgJIrH+Bn8mAuOGEDf4u7nTZimUYuzGmhTRr12oWI23KItLiBXPRlBVTZ
	o+D821wr3r/qcxm5dcdV/4e6y34Bm8cdNg4KF2RM5iw7PgEF8JEmNxjbUaRuq/CVh88p
	gY+n0bagP6V8oAgwbkUHMO4uvd8arUzmFj/u0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=9Nrkqbqh8wxeI4IEk4RGG/JO9VLKRiy7w99krOgceWg=;
	b=Mawo+8FKt+XDL5mu4aAisG336dpRgAwDF0WyAAiNrCIFEF9KmBeLDI5HtuWlzjSl/b
	Gp/OFnmnsjW05iSGyfexG7udamIx3ZEI74Z6AeNEW+vgszGGmpFtDzGMlLGbohN5kWId
	q0iPffUEoF7dSd95tvwrgse3xOU4rWvcv4O3NUsNLoXAy4dk3sbttcRkGJ1Ej3xDgDTD
	hDs6KCoKI5CbahIbPE3QW+PktbojWD2UZ+g2HJqSqedK940tqcvmdpTAAtS9yIztdOxh
	0CgpIApSDH+ewypDggtkQoKA0qMEAEXaAOwn9Mb5hTBgXwYxLXKBhteehTtjHLvbRGCX
	RCuw==
X-Gm-Message-State: ALoCoQmeG8Zb4xP61vSRe4BhDepdM8eIvpVatgXh8yuulJvXUQVGBRXUkwQdENFmo7MooAM9vQ1jZo/ioXfxrXcMLjyFDShLmXo6SYq6IiaysQjXahjDx0QKV5iKVaH6/pklyBV78NfjaFdlMXu9vxf49ZKvgs436g==
X-Received: by 10.153.11.133 with SMTP id ei5mr59499875lad.75.1415106524824;
	Tue, 04 Nov 2014 05:08:44 -0800 (PST)
X-Received: by 10.153.11.133 with SMTP id ei5mr59499864lad.75.1415106524749;
	Tue, 04 Nov 2014 05:08:44 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id w8sm137550lbp.46.2014.11.04.05.08.43
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:44 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:30 +0200
Message-Id: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 00/11] xen_cpufreq implementation in Xen
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi to all.

Next series of patches implements xen-cpufreq driver in Xen hypervisor.

Cpufreq core and registered cpufreq governors are located in xen. Dom0 has CPU
driver which can only change frequency of the physical CPUs. In addition this
driver can change CPUs regulator voltage. At start time xen-cpufreq driver
in kernel uploads to Xen information about physical cpus.
Xen notifies Dom0 kernel using VIRQ_CPUFREQ interrupt. Then xen-cpufreq driver
in kernel uses XEN_SYSCTL_cpufreq_op operation from HYPERVISOR_sysctl hypercall
to get some parameters from Xen (frequency, relation and cpu number).
Then xen-cpufreq changes frequency on physical cpu and uses the same
XEN_SYSCTL_cpufreq_op operation ti give the result to Xen.

Changed since v1:
 * use /xen/include/xen/ instead of the  /xen/include/cpufreq/
   for included files
 * move pmstat.c file to the xen/drivers/pm/stat.c instead of the
   xen/drivers/pm/pmstat.c
 * updated ./MAINTAINERS accordingly to new files location
 * introduce HAS_CPU_TURBO config and use it
 * move ACPI-specific pmstat functions under the CONFIG_ACPI config
   instead of the CONFIG_X86 config
 * correct info message in cpufreq_add_cpu() function (remove _PSD
   prefix for NON ACPI configuration)
 * dropped patch "[RFC PATCH 07/13] xen/arm: enable cpu hotplug"
 * dropped patch "[RFC PATCH 08/13] xen/dts: make the dt_find_property
   function to be global"
 * create PCPUs device tree node in /hypervisor/pcpus node instead
   of the /cpus/cpu@0/private_date/ node
 * reworked platform hypercall implementation (used XSM check
   for ARM architecture) and moved common code to the common
   place.
 * xen-cpufreq driver to the dom0-cpufreq

Changed since v2:
 * corrected comment in xen/drivers/pm/stat.c
 * restored blank line in xen/drivers/pm/stat.c
 * corrected #ifdef in xen/drivers/cpufreq/cpufreq.c
 * removed common file for platform_hypercall implementation
 * renamed dom0-cpufreq.c to hwdom-cpufreq.c
 * slightly reworked file hwdom-cpufreq.c
 * used VIRQ_CPUFREQ with number 14 instead of the 13
 
Changed since v3:
 * some fixes in creating device tree nodes for hwdom cpufreq cpu driver
 * some fixes in hwdom-cpufreq driver
 * removed XEN_SYSCTL_cpufreq_op implementation
 * added cpufreq shared info definition to send commands to the
   hwdom cpufreq driver

Oleksandr Dmytryshyn (11):
  cpufreq: move cpufreq.h file to the xen/include/xen location
  pm: move processor_perf.h file to the xen/include/xen location
  pmstat: move pmstat.c file to the xen/drivers/pm/stat.c location
  cpufreq: make turbo settings to be configurable
  pmstat: make pmstat functions more generalizable
  cpufreq: make cpufreq driver more generalizable
  arch/arm: create device tree nodes for hwdom cpufreq cpu driver
  xen: arm: implement platform hypercall
  xen: arm: add cpufreq shared info definition
  cpufreq: add hwdom-cpufreq driver
  xen/arm: enable cpufreq functionality for ARM

 MAINTAINERS                                        |   3 +-
 xen/Rules.mk                                       |   4 +
 xen/arch/arm/Makefile                              |   1 +
 xen/arch/arm/Rules.mk                              |   3 +
 xen/arch/arm/domain_build.c                        |  78 ++++++-
 xen/arch/arm/platform_hypercall.c                  |  84 +++++++
 xen/arch/arm/traps.c                               |   1 +
 xen/arch/x86/Rules.mk                              |   2 +
 xen/arch/x86/acpi/cpu_idle.c                       |   2 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c                |   2 +-
 xen/arch/x86/acpi/cpufreq/powernow.c               |   2 +-
 xen/arch/x86/acpi/power.c                          |   2 +-
 xen/arch/x86/cpu/mwait-idle.c                      |   2 +-
 xen/arch/x86/platform_hypercall.c                  |   2 +-
 xen/common/sysctl.c                                |   2 +-
 xen/drivers/Makefile                               |   1 +
 xen/drivers/acpi/Makefile                          |   1 -
 xen/drivers/cpufreq/Makefile                       |   1 +
 xen/drivers/cpufreq/cpufreq.c                      |  82 ++++++-
 xen/drivers/cpufreq/cpufreq_misc_governors.c       |   2 +-
 xen/drivers/cpufreq/cpufreq_ondemand.c             |   4 +-
 xen/drivers/cpufreq/hwdom-cpufreq.c                | 252 +++++++++++++++++++++
 xen/drivers/cpufreq/utility.c                      |  13 +-
 xen/drivers/pm/Makefile                            |   1 +
 xen/drivers/{acpi/pmstat.c => pm/stat.c}           |  16 +-
 xen/include/asm-arm/shared.h                       |  14 ++
 xen/include/public/arch-arm.h                      |   8 +
 xen/include/public/platform.h                      |   1 +
 xen/include/public/xen.h                           |   1 +
 xen/include/{acpi/cpufreq => xen}/cpufreq.h        |  13 +-
 xen/include/{acpi/cpufreq => xen}/processor_perf.h |   7 +
 xen/include/xsm/dummy.h                            |  12 +-
 xen/include/xsm/xsm.h                              |  10 +-
 xen/xsm/flask/hooks.c                              |   3 +-
 34 files changed, 587 insertions(+), 45 deletions(-)
 create mode 100644 xen/arch/arm/platform_hypercall.c
 create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c
 create mode 100644 xen/drivers/pm/Makefile
 rename xen/drivers/{acpi/pmstat.c => pm/stat.c} (97%)
 create mode 100644 xen/include/asm-arm/shared.h
 rename xen/include/{acpi/cpufreq => xen}/cpufreq.h (97%)
 rename xen/include/{acpi/cpufreq => xen}/processor_perf.h (95%)

-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:08:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1Xldqw-0004Yn-Kd; Tue, 04 Nov 2014 13:08:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldqu-0004Y6-UD
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:08:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	84/8F-09842-4EFC8545; Tue, 04 Nov 2014 13:08:52 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415106529!12709504!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32015 invoked from network); 4 Nov 2014 13:08:51 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:08:51 -0000
Received: from mail-la0-f45.google.com ([209.85.215.45]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP4LTvc9ftDVMb5GaWXlddSgNSWJh+@postini.com;
	Tue, 04 Nov 2014 05:08:50 PST
Received: by mail-la0-f45.google.com with SMTP id pn19so818866lab.32
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=yq+IZOoRvlhSfvUKFGvEYFfEBhiAIEO4mv3FB1acvV8=;
	b=g63/3lkyzRFxP623kvlF7sXZtOFHlfAPGKeasaFRka9iBC2cf4R0fIPfmgiJ9XP1JT
	7hC565GEKoVy8USgfv5wm6EBhlL7bCYZxJsb0BDZVOAP78qM1kTSTpK9W5w/iEiblZRa
	WFvBgDq+wwC04ia9PAGyAdKvprErT+wJImoMc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=yq+IZOoRvlhSfvUKFGvEYFfEBhiAIEO4mv3FB1acvV8=;
	b=gloh0hmXv+J6k7BI2PGDav8fc02OHg26UjP8jQgKx1eG7Q0hP3tcQEPylJZQ4gn7Ho
	d0AjscC6HWPaYcPI3T82QcTOgEtjGbLZfLSRZJLwkNH0MbBLet8g93ABy+uev6Vxr2tX
	QrnC8C/6braxVO2wDZn2GXZHEumm4THBDbDHiAbaL8K2xniDU7bBR1yUyA6otAdR9G0A
	7dRaChZX7HeF+MQGnFy/ZmpUIWiWDYP8BZDo1ZH//ue0d0TM1E3p8zO5gBKOgW4VyOiY
	wAwaZAtG/fqlW9rKT61hqon+VCZrU3/y8apMEZeRhE3o51YY5HntjY0HXBWU9yOn5+fw
	j5RQ==
X-Gm-Message-State: ALoCoQkMNyyYbBjU8qafzCx60DkngL89t9xxruJgZ4bwYxL1FxCVbcRRW9N+3/Fw6qkgat8j1QbGWtAFtYENup3N2Rbji81kBKMUQLgitaZUH0orRSX4+vpa31E0i55SmiSqYghamPZOxSwkR7r5ipl9bBPp+IyS+w==
X-Received: by 10.152.1.130 with SMTP id 2mr59297513lam.89.1415106527532;
	Tue, 04 Nov 2014 05:08:47 -0800 (PST)
X-Received: by 10.152.1.130 with SMTP id 2mr59297503lam.89.1415106527457;
	Tue, 04 Nov 2014 05:08:47 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id n10sm142114laf.38.2014.11.04.05.08.46
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:46 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:31 +0200
Message-Id: <1415106521-3115-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 01/11] cpufreq: move cpufreq.h file to
	the xen/include/xen location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 MAINTAINERS                                  | 1 +
 xen/arch/x86/acpi/cpu_idle.c                 | 2 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c          | 2 +-
 xen/arch/x86/acpi/cpufreq/powernow.c         | 2 +-
 xen/arch/x86/acpi/power.c                    | 2 +-
 xen/arch/x86/cpu/mwait-idle.c                | 2 +-
 xen/drivers/acpi/pmstat.c                    | 2 +-
 xen/drivers/cpufreq/cpufreq.c                | 2 +-
 xen/drivers/cpufreq/cpufreq_misc_governors.c | 2 +-
 xen/drivers/cpufreq/cpufreq_ondemand.c       | 4 ++--
 xen/drivers/cpufreq/utility.c                | 2 +-
 xen/include/{acpi/cpufreq => xen}/cpufreq.h  | 7 +++++--
 12 files changed, 17 insertions(+), 13 deletions(-)
 rename xen/include/{acpi/cpufreq => xen}/cpufreq.h (98%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7757cdd..49f56a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -235,6 +235,7 @@ X:	xen/arch/x86/acpi/boot.c
 X:	xen/arch/x86/acpi/lib.c
 F:	xen/drivers/cpufreq/
 F:	xen/include/acpi/cpufreq/
+F:	xen/include/xen/cpufreq.h
 
 QEMU-DM
 M:	Ian Jackson <ian.jackson@eu.citrix.com>
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 597befa..d773955 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -51,7 +51,7 @@
 #include <xen/softirq.h>
 #include <public/platform.h>
 #include <public/sysctl.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <asm/apic.h>
 #include <asm/cpuidle.h>
 #include <asm/mwait.h>
diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 4a6aeb3..5d22257 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -42,7 +42,7 @@
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 enum {
     UNDEFINED_CAPABLE = 0,
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c b/xen/arch/x86/acpi/cpufreq/powernow.c
index 2c9fea2..4961d55 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -36,7 +36,7 @@
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define CPUID_6_ECX_APERFMPERF_CAPABILITY       (0x1)
 #define CPUID_FREQ_VOLT_CAPABILITIES    0x80000007
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index f41f0de..f4a87e3 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -29,7 +29,7 @@
 #include <asm/tboot.h>
 #include <asm/apic.h>
 #include <asm/io_apic.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 uint32_t system_reset_counter = 1;
 
diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index 85179f2..c72219a 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -59,7 +59,7 @@
 #include <asm/hpet.h>
 #include <asm/mwait.h>
 #include <asm/msr.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define MWAIT_IDLE_VERSION "0.4"
 #undef PREFIX
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index daac2da..3486148 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -40,7 +40,7 @@
 #include <xen/acpi.h>
 
 #include <public/sysctl.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <xen/pmstat.h>
 
 DEFINE_PER_CPU_READ_MOSTLY(struct pm_px *, cpufreq_statistic_data);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index ab66884..f5f4d75 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -44,7 +44,7 @@
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 static unsigned int __read_mostly usr_min_freq;
 static unsigned int __read_mostly usr_max_freq;
diff --git a/xen/drivers/cpufreq/cpufreq_misc_governors.c b/xen/drivers/cpufreq/cpufreq_misc_governors.c
index 746bbcd..4a5510c 100644
--- a/xen/drivers/cpufreq/cpufreq_misc_governors.c
+++ b/xen/drivers/cpufreq/cpufreq_misc_governors.c
@@ -18,7 +18,7 @@
 #include <xen/init.h>
 #include <xen/percpu.h>
 #include <xen/sched.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 /*
  * cpufreq userspace governor
diff --git a/xen/drivers/cpufreq/cpufreq_ondemand.c b/xen/drivers/cpufreq/cpufreq_ondemand.c
index 7fdba03..d490c8a 100644
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
@@ -1,5 +1,5 @@
 /*
- *  xen/arch/x86/acpi/cpufreq/cpufreq_ondemand.c
+ *  xen/drivers/cpufreq/cpufreq_ondemand.c
  *
  *  Copyright (C)  2001 Russell King
  *            (C)  2003 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>.
@@ -18,7 +18,7 @@
 #include <xen/types.h>
 #include <xen/sched.h>
 #include <xen/timer.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define DEF_FREQUENCY_UP_THRESHOLD              (80)
 #define MIN_FREQUENCY_UP_THRESHOLD              (11)
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 519f862..3cb0b3e 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -28,7 +28,7 @@
 #include <xen/sched.h>
 #include <xen/timer.h>
 #include <xen/trace.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <public/sysctl.h>
 
 struct cpufreq_driver   *cpufreq_driver;
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/xen/cpufreq.h
similarity index 98%
rename from xen/include/acpi/cpufreq/cpufreq.h
rename to xen/include/xen/cpufreq.h
index f96c3e4..fa653ef 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -1,5 +1,5 @@
 /*
- *  xen/include/acpi/cpufreq/cpufreq.h
+ *  xen/include/xen/cpufreq.h
  *
  *  Copyright (C) 2001 Russell King
  *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
@@ -16,9 +16,12 @@
 
 #include <xen/types.h>
 #include <xen/list.h>
+#include <xen/percpu.h>
+#include <xen/spinlock.h>
+#include <xen/errno.h>
 #include <xen/cpumask.h>
 
-#include "processor_perf.h"
+#include <acpi/cpufreq/processor_perf.h>
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:08:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1Xldqw-0004Yn-Kd; Tue, 04 Nov 2014 13:08:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldqu-0004Y6-UD
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:08:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	84/8F-09842-4EFC8545; Tue, 04 Nov 2014 13:08:52 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415106529!12709504!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32015 invoked from network); 4 Nov 2014 13:08:51 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:08:51 -0000
Received: from mail-la0-f45.google.com ([209.85.215.45]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP4LTvc9ftDVMb5GaWXlddSgNSWJh+@postini.com;
	Tue, 04 Nov 2014 05:08:50 PST
Received: by mail-la0-f45.google.com with SMTP id pn19so818866lab.32
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=yq+IZOoRvlhSfvUKFGvEYFfEBhiAIEO4mv3FB1acvV8=;
	b=g63/3lkyzRFxP623kvlF7sXZtOFHlfAPGKeasaFRka9iBC2cf4R0fIPfmgiJ9XP1JT
	7hC565GEKoVy8USgfv5wm6EBhlL7bCYZxJsb0BDZVOAP78qM1kTSTpK9W5w/iEiblZRa
	WFvBgDq+wwC04ia9PAGyAdKvprErT+wJImoMc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=yq+IZOoRvlhSfvUKFGvEYFfEBhiAIEO4mv3FB1acvV8=;
	b=gloh0hmXv+J6k7BI2PGDav8fc02OHg26UjP8jQgKx1eG7Q0hP3tcQEPylJZQ4gn7Ho
	d0AjscC6HWPaYcPI3T82QcTOgEtjGbLZfLSRZJLwkNH0MbBLet8g93ABy+uev6Vxr2tX
	QrnC8C/6braxVO2wDZn2GXZHEumm4THBDbDHiAbaL8K2xniDU7bBR1yUyA6otAdR9G0A
	7dRaChZX7HeF+MQGnFy/ZmpUIWiWDYP8BZDo1ZH//ue0d0TM1E3p8zO5gBKOgW4VyOiY
	wAwaZAtG/fqlW9rKT61hqon+VCZrU3/y8apMEZeRhE3o51YY5HntjY0HXBWU9yOn5+fw
	j5RQ==
X-Gm-Message-State: ALoCoQkMNyyYbBjU8qafzCx60DkngL89t9xxruJgZ4bwYxL1FxCVbcRRW9N+3/Fw6qkgat8j1QbGWtAFtYENup3N2Rbji81kBKMUQLgitaZUH0orRSX4+vpa31E0i55SmiSqYghamPZOxSwkR7r5ipl9bBPp+IyS+w==
X-Received: by 10.152.1.130 with SMTP id 2mr59297513lam.89.1415106527532;
	Tue, 04 Nov 2014 05:08:47 -0800 (PST)
X-Received: by 10.152.1.130 with SMTP id 2mr59297503lam.89.1415106527457;
	Tue, 04 Nov 2014 05:08:47 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id n10sm142114laf.38.2014.11.04.05.08.46
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:46 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:31 +0200
Message-Id: <1415106521-3115-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 01/11] cpufreq: move cpufreq.h file to
	the xen/include/xen location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 MAINTAINERS                                  | 1 +
 xen/arch/x86/acpi/cpu_idle.c                 | 2 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c          | 2 +-
 xen/arch/x86/acpi/cpufreq/powernow.c         | 2 +-
 xen/arch/x86/acpi/power.c                    | 2 +-
 xen/arch/x86/cpu/mwait-idle.c                | 2 +-
 xen/drivers/acpi/pmstat.c                    | 2 +-
 xen/drivers/cpufreq/cpufreq.c                | 2 +-
 xen/drivers/cpufreq/cpufreq_misc_governors.c | 2 +-
 xen/drivers/cpufreq/cpufreq_ondemand.c       | 4 ++--
 xen/drivers/cpufreq/utility.c                | 2 +-
 xen/include/{acpi/cpufreq => xen}/cpufreq.h  | 7 +++++--
 12 files changed, 17 insertions(+), 13 deletions(-)
 rename xen/include/{acpi/cpufreq => xen}/cpufreq.h (98%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7757cdd..49f56a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -235,6 +235,7 @@ X:	xen/arch/x86/acpi/boot.c
 X:	xen/arch/x86/acpi/lib.c
 F:	xen/drivers/cpufreq/
 F:	xen/include/acpi/cpufreq/
+F:	xen/include/xen/cpufreq.h
 
 QEMU-DM
 M:	Ian Jackson <ian.jackson@eu.citrix.com>
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 597befa..d773955 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -51,7 +51,7 @@
 #include <xen/softirq.h>
 #include <public/platform.h>
 #include <public/sysctl.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <asm/apic.h>
 #include <asm/cpuidle.h>
 #include <asm/mwait.h>
diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 4a6aeb3..5d22257 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -42,7 +42,7 @@
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 enum {
     UNDEFINED_CAPABLE = 0,
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c b/xen/arch/x86/acpi/cpufreq/powernow.c
index 2c9fea2..4961d55 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -36,7 +36,7 @@
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define CPUID_6_ECX_APERFMPERF_CAPABILITY       (0x1)
 #define CPUID_FREQ_VOLT_CAPABILITIES    0x80000007
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index f41f0de..f4a87e3 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -29,7 +29,7 @@
 #include <asm/tboot.h>
 #include <asm/apic.h>
 #include <asm/io_apic.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 uint32_t system_reset_counter = 1;
 
diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index 85179f2..c72219a 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -59,7 +59,7 @@
 #include <asm/hpet.h>
 #include <asm/mwait.h>
 #include <asm/msr.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define MWAIT_IDLE_VERSION "0.4"
 #undef PREFIX
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index daac2da..3486148 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -40,7 +40,7 @@
 #include <xen/acpi.h>
 
 #include <public/sysctl.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <xen/pmstat.h>
 
 DEFINE_PER_CPU_READ_MOSTLY(struct pm_px *, cpufreq_statistic_data);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index ab66884..f5f4d75 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -44,7 +44,7 @@
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 static unsigned int __read_mostly usr_min_freq;
 static unsigned int __read_mostly usr_max_freq;
diff --git a/xen/drivers/cpufreq/cpufreq_misc_governors.c b/xen/drivers/cpufreq/cpufreq_misc_governors.c
index 746bbcd..4a5510c 100644
--- a/xen/drivers/cpufreq/cpufreq_misc_governors.c
+++ b/xen/drivers/cpufreq/cpufreq_misc_governors.c
@@ -18,7 +18,7 @@
 #include <xen/init.h>
 #include <xen/percpu.h>
 #include <xen/sched.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 /*
  * cpufreq userspace governor
diff --git a/xen/drivers/cpufreq/cpufreq_ondemand.c b/xen/drivers/cpufreq/cpufreq_ondemand.c
index 7fdba03..d490c8a 100644
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
@@ -1,5 +1,5 @@
 /*
- *  xen/arch/x86/acpi/cpufreq/cpufreq_ondemand.c
+ *  xen/drivers/cpufreq/cpufreq_ondemand.c
  *
  *  Copyright (C)  2001 Russell King
  *            (C)  2003 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>.
@@ -18,7 +18,7 @@
 #include <xen/types.h>
 #include <xen/sched.h>
 #include <xen/timer.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define DEF_FREQUENCY_UP_THRESHOLD              (80)
 #define MIN_FREQUENCY_UP_THRESHOLD              (11)
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 519f862..3cb0b3e 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -28,7 +28,7 @@
 #include <xen/sched.h>
 #include <xen/timer.h>
 #include <xen/trace.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <public/sysctl.h>
 
 struct cpufreq_driver   *cpufreq_driver;
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/xen/cpufreq.h
similarity index 98%
rename from xen/include/acpi/cpufreq/cpufreq.h
rename to xen/include/xen/cpufreq.h
index f96c3e4..fa653ef 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -1,5 +1,5 @@
 /*
- *  xen/include/acpi/cpufreq/cpufreq.h
+ *  xen/include/xen/cpufreq.h
  *
  *  Copyright (C) 2001 Russell King
  *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
@@ -16,9 +16,12 @@
 
 #include <xen/types.h>
 #include <xen/list.h>
+#include <xen/percpu.h>
+#include <xen/spinlock.h>
+#include <xen/errno.h>
 #include <xen/cpumask.h>
 
-#include "processor_perf.h"
+#include <acpi/cpufreq/processor_perf.h>
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:08:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldqz-0004aP-6q; Tue, 04 Nov 2014 13:08:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldqx-0004Zd-PA
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:08:55 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E1/FA-24532-7EFC8545; Tue, 04 Nov 2014 13:08:55 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415106532!9236216!1
X-Originating-IP: [64.18.0.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25942 invoked from network); 4 Nov 2014 13:08:54 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:08:54 -0000
Received: from mail-lb0-f171.google.com ([209.85.217.171]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP5K2MItkk9zNKbbNNLHblk85iYDHF@postini.com;
	Tue, 04 Nov 2014 05:08:54 PST
Received: by mail-lb0-f171.google.com with SMTP id b6so3063532lbj.2
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=D1leJIJzsTzTSyc0hUuYcZ38eLO7gkRqvj/NBqjScY8=;
	b=Cah/PRT4YLBR+weVZ03u1UgGnPTKeAiG6jxhr122l1z+NqBuf//c7B6FFB1VEN82a7
	uvvXo/Xvvz4vtfbc9NweK6r3RJTZNFR/+2T1ltdzvcddA5MhptJpmAmOygCH1UtaY5gP
	V9oAMrcOmARSv5tCtYroWR95f9KSZ9Yy7fNVg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=D1leJIJzsTzTSyc0hUuYcZ38eLO7gkRqvj/NBqjScY8=;
	b=k9aCL/MuUGslzZuhAGC1gZMWxXmUU40XuZVfdlMlIeh3/AS2tObTcJCuN62g3TIU31
	whXx3PbqK0z9Z/B/nP+VqmCV53ItxJdifCuzeWE5uIPxZJOlmX5BxoGMYo+9I2lSXWux
	vvEHK7kbfBO9Sm3WFYR2kQdU8sajwXV9gcHgx52RUOYOP4tsuDLVBVgW5XL7J115Jwt3
	MPP8LBh76l7aiG3+Va9kSIo+zX6bnDtoPDQ4bRpkcGSh2cQlZf5klKoZuy+wHCNwq8k4
	6v012CmvtM5288BxWODJKt+TBepoWg6cOM/SlL3j2cbcrOT4+/t2pPBaqdYj2Ni0A3CL
	aJ4A==
X-Gm-Message-State: ALoCoQlI8v5katxl0Hf/GUs41wYt0nOg/YoYtxh2rjAZIrgHIK4vpsVimgxSjIN1JAUK1upJdNuvhIaYISmNEYSaOPVpI6jif5cpGWeKpfxeianjwEbJvwG2pHna1o2vT4+cO7Rzq3c8jtP/CqvyuAGJfRN3PlSRNQ==
X-Received: by 10.112.85.138 with SMTP id h10mr59111177lbz.33.1415106530935;
	Tue, 04 Nov 2014 05:08:50 -0800 (PST)
X-Received: by 10.112.85.138 with SMTP id h10mr59111061lbz.33.1415106529982;
	Tue, 04 Nov 2014 05:08:49 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id ja9sm145236lbc.30.2014.11.04.05.08.48
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:49 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:32 +0200
Message-Id: <1415106521-3115-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 02/11] pm: move processor_perf.h file to
	the xen/include/xen location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 MAINTAINERS                                        | 2 +-
 xen/arch/x86/platform_hypercall.c                  | 2 +-
 xen/include/xen/cpufreq.h                          | 2 +-
 xen/include/{acpi/cpufreq => xen}/processor_perf.h | 0
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename xen/include/{acpi/cpufreq => xen}/processor_perf.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 49f56a1..f4d916e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -234,8 +234,8 @@ F:	xen/arch/x86/acpi/
 X:	xen/arch/x86/acpi/boot.c
 X:	xen/arch/x86/acpi/lib.c
 F:	xen/drivers/cpufreq/
-F:	xen/include/acpi/cpufreq/
 F:	xen/include/xen/cpufreq.h
+F:	xen/include/xen/processor_perf.h
 
 QEMU-DM
 M:	Ian Jackson <ian.jackson@eu.citrix.com>
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 2162811..7ce8592 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -25,7 +25,7 @@
 #include <xen/irq.h>
 #include <asm/current.h>
 #include <public/platform.h>
-#include <acpi/cpufreq/processor_perf.h>
+#include <xen/processor_perf.h>
 #include <asm/edd.h>
 #include <asm/mtrr.h>
 #include <asm/io_apic.h>
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index fa653ef..82dc4dc 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -21,7 +21,7 @@
 #include <xen/errno.h>
 #include <xen/cpumask.h>
 
-#include <acpi/cpufreq/processor_perf.h>
+#include <xen/processor_perf.h>
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
diff --git a/xen/include/acpi/cpufreq/processor_perf.h b/xen/include/xen/processor_perf.h
similarity index 100%
rename from xen/include/acpi/cpufreq/processor_perf.h
rename to xen/include/xen/processor_perf.h
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:08:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldqz-0004aP-6q; Tue, 04 Nov 2014 13:08:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldqx-0004Zd-PA
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:08:55 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E1/FA-24532-7EFC8545; Tue, 04 Nov 2014 13:08:55 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415106532!9236216!1
X-Originating-IP: [64.18.0.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25942 invoked from network); 4 Nov 2014 13:08:54 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:08:54 -0000
Received: from mail-lb0-f171.google.com ([209.85.217.171]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP5K2MItkk9zNKbbNNLHblk85iYDHF@postini.com;
	Tue, 04 Nov 2014 05:08:54 PST
Received: by mail-lb0-f171.google.com with SMTP id b6so3063532lbj.2
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=D1leJIJzsTzTSyc0hUuYcZ38eLO7gkRqvj/NBqjScY8=;
	b=Cah/PRT4YLBR+weVZ03u1UgGnPTKeAiG6jxhr122l1z+NqBuf//c7B6FFB1VEN82a7
	uvvXo/Xvvz4vtfbc9NweK6r3RJTZNFR/+2T1ltdzvcddA5MhptJpmAmOygCH1UtaY5gP
	V9oAMrcOmARSv5tCtYroWR95f9KSZ9Yy7fNVg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=D1leJIJzsTzTSyc0hUuYcZ38eLO7gkRqvj/NBqjScY8=;
	b=k9aCL/MuUGslzZuhAGC1gZMWxXmUU40XuZVfdlMlIeh3/AS2tObTcJCuN62g3TIU31
	whXx3PbqK0z9Z/B/nP+VqmCV53ItxJdifCuzeWE5uIPxZJOlmX5BxoGMYo+9I2lSXWux
	vvEHK7kbfBO9Sm3WFYR2kQdU8sajwXV9gcHgx52RUOYOP4tsuDLVBVgW5XL7J115Jwt3
	MPP8LBh76l7aiG3+Va9kSIo+zX6bnDtoPDQ4bRpkcGSh2cQlZf5klKoZuy+wHCNwq8k4
	6v012CmvtM5288BxWODJKt+TBepoWg6cOM/SlL3j2cbcrOT4+/t2pPBaqdYj2Ni0A3CL
	aJ4A==
X-Gm-Message-State: ALoCoQlI8v5katxl0Hf/GUs41wYt0nOg/YoYtxh2rjAZIrgHIK4vpsVimgxSjIN1JAUK1upJdNuvhIaYISmNEYSaOPVpI6jif5cpGWeKpfxeianjwEbJvwG2pHna1o2vT4+cO7Rzq3c8jtP/CqvyuAGJfRN3PlSRNQ==
X-Received: by 10.112.85.138 with SMTP id h10mr59111177lbz.33.1415106530935;
	Tue, 04 Nov 2014 05:08:50 -0800 (PST)
X-Received: by 10.112.85.138 with SMTP id h10mr59111061lbz.33.1415106529982;
	Tue, 04 Nov 2014 05:08:49 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id ja9sm145236lbc.30.2014.11.04.05.08.48
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:49 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:32 +0200
Message-Id: <1415106521-3115-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 02/11] pm: move processor_perf.h file to
	the xen/include/xen location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 MAINTAINERS                                        | 2 +-
 xen/arch/x86/platform_hypercall.c                  | 2 +-
 xen/include/xen/cpufreq.h                          | 2 +-
 xen/include/{acpi/cpufreq => xen}/processor_perf.h | 0
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename xen/include/{acpi/cpufreq => xen}/processor_perf.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 49f56a1..f4d916e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -234,8 +234,8 @@ F:	xen/arch/x86/acpi/
 X:	xen/arch/x86/acpi/boot.c
 X:	xen/arch/x86/acpi/lib.c
 F:	xen/drivers/cpufreq/
-F:	xen/include/acpi/cpufreq/
 F:	xen/include/xen/cpufreq.h
+F:	xen/include/xen/processor_perf.h
 
 QEMU-DM
 M:	Ian Jackson <ian.jackson@eu.citrix.com>
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 2162811..7ce8592 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -25,7 +25,7 @@
 #include <xen/irq.h>
 #include <asm/current.h>
 #include <public/platform.h>
-#include <acpi/cpufreq/processor_perf.h>
+#include <xen/processor_perf.h>
 #include <asm/edd.h>
 #include <asm/mtrr.h>
 #include <asm/io_apic.h>
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index fa653ef..82dc4dc 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -21,7 +21,7 @@
 #include <xen/errno.h>
 #include <xen/cpumask.h>
 
-#include <acpi/cpufreq/processor_perf.h>
+#include <xen/processor_perf.h>
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
diff --git a/xen/include/acpi/cpufreq/processor_perf.h b/xen/include/xen/processor_perf.h
similarity index 100%
rename from xen/include/acpi/cpufreq/processor_perf.h
rename to xen/include/xen/processor_perf.h
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:08:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:08:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldr1-0004c2-NN; Tue, 04 Nov 2014 13:08:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldr0-0004bE-Bx
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:08:58 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D5/7A-09936-9EFC8545; Tue, 04 Nov 2014 13:08:57 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415106534!12677547!1
X-Originating-IP: [64.18.0.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1456 invoked from network); 4 Nov 2014 13:08:56 -0000
Received: from exprod5og107.obsmtp.com (HELO exprod5og107.obsmtp.com)
	(64.18.0.184)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:08:56 -0000
Received: from mail-la0-f41.google.com ([209.85.215.41]) (using TLSv1) by
	exprod5ob107.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP5TwMqAMIVFBBv2mzj1Tqj4k1x5NB@postini.com;
	Tue, 04 Nov 2014 05:08:55 PST
Received: by mail-la0-f41.google.com with SMTP id s18so833098lam.14
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=mDypeJq6Xfd/WvShiqJmfitzjHxkYyoecdy+64EqB4U=;
	b=U7EMLHrpsOoHqEaRLBYddxlizUmUBV/OtraXO13W0xilW5MDBb41wCIyW0mBCeD9VQ
	tyV/5YV9N8xwW+Rs8hfTnFF/oTv/trL/Z0zLSMlTppRpr9bR3Q/It5jiAqK+m3uR37pa
	NOOrGoMO005iV5+mxbRVTY5YSVS0BGQnhtK4w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=mDypeJq6Xfd/WvShiqJmfitzjHxkYyoecdy+64EqB4U=;
	b=XkmI+X/BP6RtThbTRuDG9mfVgsiJJ0h+lpQrXGZob8wnilDtODQuIn2FtoCJELUc24
	BcJaKqUum5Sav+621LDFPsKWTVH4VRi9ut9tWXOBoPZAc+QuFEuj/8khoJoPx3Vkrckq
	X802CPQR9AhdgakX9NsVTBxs1BYOEY1OjhNclDphZBZrunqy5bk27CctytYVpvtdFDAC
	QxxO6hkmrhzClP2OXiSZ10kuWUNyJ/7GQ8vhZuSAC5NG6TxpANJV1+dMNZsMM5tk8Cns
	fYYHYF6xIvbA42qPblsob0qVBB00FRZZptnm+56Ebt8ppdCeQHbcfI60+cv0Ji7xSs2f
	FfjQ==
X-Gm-Message-State: ALoCoQlKBvcR3p01J6FkP1ZBpmtaVbzFFBT4JRo+i2NlVc8u18mQUtxSjZ0dEccbB/6TC7diNjWzRfjclwvRBmqwOVGuJScER7iwjrtdcCqsnUfSjHhmZr7WvGz4BBL2A1uFOqeaLVQJZAYkc2Cn0N9ch+jk0ndC2g==
X-Received: by 10.112.138.39 with SMTP id qn7mr45566849lbb.57.1415106532545;
	Tue, 04 Nov 2014 05:08:52 -0800 (PST)
X-Received: by 10.112.138.39 with SMTP id qn7mr45566823lbb.57.1415106532351;
	Tue, 04 Nov 2014 05:08:52 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id i6sm136661laf.47.2014.11.04.05.08.51
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:51 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:33 +0200
Message-Id: <1415106521-3115-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 03/11] pmstat: move pmstat.c file to the
	xen/drivers/pm/stat.c location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                             | 1 +
 xen/arch/x86/Rules.mk                    | 1 +
 xen/common/sysctl.c                      | 2 +-
 xen/drivers/Makefile                     | 1 +
 xen/drivers/acpi/Makefile                | 1 -
 xen/drivers/pm/Makefile                  | 1 +
 xen/drivers/{acpi/pmstat.c => pm/stat.c} | 0
 7 files changed, 5 insertions(+), 2 deletions(-)
 create mode 100644 xen/drivers/pm/Makefile
 rename xen/drivers/{acpi/pmstat.c => pm/stat.c} (100%)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3a6cec5..b7caab6 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -55,6 +55,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 576985e..9e9fbf1 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,7 @@
 
 HAS_IOPORTS := y
 HAS_ACPI := y
+HAS_PM := y
 HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0cb6ee1..0dcf06a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -170,7 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         op->u.availheap.avail_bytes <<= PAGE_SHIFT;
         break;
 
-#ifdef HAS_ACPI
+#ifdef HAS_PM
     case XEN_SYSCTL_get_pmstat:
         ret = do_get_pm_info(&op->u.get_pmstat);
         break;
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 9c70f20..ee4fd4d 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -4,3 +4,4 @@ subdir-$(HAS_PCI) += pci
 subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VIDEO) += video
+subdir-$(HAS_PM) += pm
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index bbb06a7..0505742 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -5,7 +5,6 @@ subdir-$(x86) += apei
 obj-bin-y += tables.init.o
 obj-y += numa.o
 obj-y += osl.o
-obj-y += pmstat.o
 
 obj-$(x86) += hwregs.o
 obj-$(x86) += reboot.o
diff --git a/xen/drivers/pm/Makefile b/xen/drivers/pm/Makefile
new file mode 100644
index 0000000..2073683
--- /dev/null
+++ b/xen/drivers/pm/Makefile
@@ -0,0 +1 @@
+obj-y += stat.o
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/pm/stat.c
similarity index 100%
rename from xen/drivers/acpi/pmstat.c
rename to xen/drivers/pm/stat.c
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:08:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:08:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldr1-0004c2-NN; Tue, 04 Nov 2014 13:08:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldr0-0004bE-Bx
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:08:58 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D5/7A-09936-9EFC8545; Tue, 04 Nov 2014 13:08:57 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415106534!12677547!1
X-Originating-IP: [64.18.0.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1456 invoked from network); 4 Nov 2014 13:08:56 -0000
Received: from exprod5og107.obsmtp.com (HELO exprod5og107.obsmtp.com)
	(64.18.0.184)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:08:56 -0000
Received: from mail-la0-f41.google.com ([209.85.215.41]) (using TLSv1) by
	exprod5ob107.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP5TwMqAMIVFBBv2mzj1Tqj4k1x5NB@postini.com;
	Tue, 04 Nov 2014 05:08:55 PST
Received: by mail-la0-f41.google.com with SMTP id s18so833098lam.14
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=mDypeJq6Xfd/WvShiqJmfitzjHxkYyoecdy+64EqB4U=;
	b=U7EMLHrpsOoHqEaRLBYddxlizUmUBV/OtraXO13W0xilW5MDBb41wCIyW0mBCeD9VQ
	tyV/5YV9N8xwW+Rs8hfTnFF/oTv/trL/Z0zLSMlTppRpr9bR3Q/It5jiAqK+m3uR37pa
	NOOrGoMO005iV5+mxbRVTY5YSVS0BGQnhtK4w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=mDypeJq6Xfd/WvShiqJmfitzjHxkYyoecdy+64EqB4U=;
	b=XkmI+X/BP6RtThbTRuDG9mfVgsiJJ0h+lpQrXGZob8wnilDtODQuIn2FtoCJELUc24
	BcJaKqUum5Sav+621LDFPsKWTVH4VRi9ut9tWXOBoPZAc+QuFEuj/8khoJoPx3Vkrckq
	X802CPQR9AhdgakX9NsVTBxs1BYOEY1OjhNclDphZBZrunqy5bk27CctytYVpvtdFDAC
	QxxO6hkmrhzClP2OXiSZ10kuWUNyJ/7GQ8vhZuSAC5NG6TxpANJV1+dMNZsMM5tk8Cns
	fYYHYF6xIvbA42qPblsob0qVBB00FRZZptnm+56Ebt8ppdCeQHbcfI60+cv0Ji7xSs2f
	FfjQ==
X-Gm-Message-State: ALoCoQlKBvcR3p01J6FkP1ZBpmtaVbzFFBT4JRo+i2NlVc8u18mQUtxSjZ0dEccbB/6TC7diNjWzRfjclwvRBmqwOVGuJScER7iwjrtdcCqsnUfSjHhmZr7WvGz4BBL2A1uFOqeaLVQJZAYkc2Cn0N9ch+jk0ndC2g==
X-Received: by 10.112.138.39 with SMTP id qn7mr45566849lbb.57.1415106532545;
	Tue, 04 Nov 2014 05:08:52 -0800 (PST)
X-Received: by 10.112.138.39 with SMTP id qn7mr45566823lbb.57.1415106532351;
	Tue, 04 Nov 2014 05:08:52 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id i6sm136661laf.47.2014.11.04.05.08.51
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:51 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:33 +0200
Message-Id: <1415106521-3115-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 03/11] pmstat: move pmstat.c file to the
	xen/drivers/pm/stat.c location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                             | 1 +
 xen/arch/x86/Rules.mk                    | 1 +
 xen/common/sysctl.c                      | 2 +-
 xen/drivers/Makefile                     | 1 +
 xen/drivers/acpi/Makefile                | 1 -
 xen/drivers/pm/Makefile                  | 1 +
 xen/drivers/{acpi/pmstat.c => pm/stat.c} | 0
 7 files changed, 5 insertions(+), 2 deletions(-)
 create mode 100644 xen/drivers/pm/Makefile
 rename xen/drivers/{acpi/pmstat.c => pm/stat.c} (100%)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3a6cec5..b7caab6 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -55,6 +55,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 576985e..9e9fbf1 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,7 @@
 
 HAS_IOPORTS := y
 HAS_ACPI := y
+HAS_PM := y
 HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0cb6ee1..0dcf06a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -170,7 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         op->u.availheap.avail_bytes <<= PAGE_SHIFT;
         break;
 
-#ifdef HAS_ACPI
+#ifdef HAS_PM
     case XEN_SYSCTL_get_pmstat:
         ret = do_get_pm_info(&op->u.get_pmstat);
         break;
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 9c70f20..ee4fd4d 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -4,3 +4,4 @@ subdir-$(HAS_PCI) += pci
 subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VIDEO) += video
+subdir-$(HAS_PM) += pm
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index bbb06a7..0505742 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -5,7 +5,6 @@ subdir-$(x86) += apei
 obj-bin-y += tables.init.o
 obj-y += numa.o
 obj-y += osl.o
-obj-y += pmstat.o
 
 obj-$(x86) += hwregs.o
 obj-$(x86) += reboot.o
diff --git a/xen/drivers/pm/Makefile b/xen/drivers/pm/Makefile
new file mode 100644
index 0000000..2073683
--- /dev/null
+++ b/xen/drivers/pm/Makefile
@@ -0,0 +1 @@
+obj-y += stat.o
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/pm/stat.c
similarity index 100%
rename from xen/drivers/acpi/pmstat.c
rename to xen/drivers/pm/stat.c
-- 
1.9.1


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

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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.xen.org>)
	id 1Xldr5-0004eB-4i; Tue, 04 Nov 2014 13:09:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldr3-0004cp-5M
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:01 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	E7/5D-25727-CEFC8545; Tue, 04 Nov 2014 13:09:00 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415106536!11535610!1
X-Originating-IP: [64.18.0.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2953 invoked from network); 4 Nov 2014 13:08:59 -0000
Received: from exprod5og110.obsmtp.com (HELO exprod5og110.obsmtp.com)
	(64.18.0.20)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:08:59 -0000
Received: from mail-la0-f52.google.com ([209.85.215.52]) (using TLSv1) by
	exprod5ob110.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP6LxeY5sMajQmkE4WxYMdKu6W/l7j@postini.com;
	Tue, 04 Nov 2014 05:08:58 PST
Received: by mail-la0-f52.google.com with SMTP id pv20so843464lab.11
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=713bit2g0RhvBKeHzo9XWlypOoemnEZ6Rrwf4CVZRDY=;
	b=PaTs4Hbj/YvhLZUp82ctEY2ck9HaOEI8fHBX15NEt2mPHbZT/9yNmM7rXJrPNzREwd
	37VltmVymKI5tFSpX4Y7H93Q62ASsBG+SpzcWMk+4ST2GiSYiJjwura8Kiu+j77kaC3x
	jnOUA3ZfFn33ufw2KMFG8tsDRQ9paPxkD+cZo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=713bit2g0RhvBKeHzo9XWlypOoemnEZ6Rrwf4CVZRDY=;
	b=YgvOe/OlEYmvSkG+OEHK8SpvF43VKeBoVAdhwAHkuuxdCyIr9suDCLGEsqdROFo3N6
	zwU8qZog7gL6ENOUKLBjLr7coV0adzPGK4IZ9y+3Osqcwj3DjJ9g467S3tUfbJK8Iwqy
	e7Cd9WHr2irEbtH8J67MhtYxXKf0AJTZqpjLHSbHEI+Isa1X1OMFTOgH2la0o7J73VPI
	WsFKcKtpBRm82bmTXdv49Z3dTAC+AGUZfXi9MhcM5ABuXlfDrO/hI6sjEj4WoDfEH/yy
	kz5YhZFMyoUJcyw2yDaKP2TBAE8tOoZS8+DxE1kcCLmJFwK8Hht5VNSiMWaiGB2Q6E4A
	TfQw==
X-Gm-Message-State: ALoCoQlLodgpGRHzHp52yAJSNey3FjkhJ3WWObcwRDcWf+jdblgC6I9IshQq8ZlxFigtvurgh3jIq4uepahs1WoCMLXvQSQujdoeHT8JmDjbjVUQ+lVXmJzRkv87S3+zsH8oe/UTQlrYj0OyW/RbSM5ODbKQPefXGg==
X-Received: by 10.112.199.40 with SMTP id jh8mr53487816lbc.5.1415106534722;
	Tue, 04 Nov 2014 05:08:54 -0800 (PST)
X-Received: by 10.112.199.40 with SMTP id jh8mr53487802lbc.5.1415106534636;
	Tue, 04 Nov 2014 05:08:54 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id i6sm136694laf.47.2014.11.04.05.08.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:53 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:34 +0200
Message-Id: <1415106521-3115-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 04/11] cpufreq: make turbo settings to be
	configurable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This settings is not needed for some architectures.
So make it to be configurable and use it for x86
architecture.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                  |  1 +
 xen/arch/x86/Rules.mk         |  1 +
 xen/drivers/cpufreq/utility.c | 11 ++++++++++-
 xen/drivers/pm/stat.c         |  6 ++++++
 xen/include/xen/cpufreq.h     |  6 ++++++
 5 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index b7caab6..5953152 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_PM)        += -DHAS_PM
+CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 9e9fbf1..cfe4f90 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -4,6 +4,7 @@
 HAS_IOPORTS := y
 HAS_ACPI := y
 HAS_PM := y
+HAS_CPU_TURBO := y
 HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 3cb0b3e..e92cf17 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -209,7 +209,9 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
 {
     unsigned int min_freq = ~0;
     unsigned int max_freq = 0;
+#ifdef HAS_CPU_TURBO
     unsigned int second_max_freq = 0;
+#endif
     unsigned int i;
 
     for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
@@ -221,6 +223,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
         if (freq > max_freq)
             max_freq = freq;
     }
+#ifdef HAS_CPU_TURBO
     for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
         unsigned int freq = table[i].frequency;
         if (freq == CPUFREQ_ENTRY_INVALID || freq == max_freq)
@@ -234,9 +237,13 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
         printk("max_freq: %u    second_max_freq: %u\n",
                max_freq, second_max_freq);
 
+    policy->cpuinfo.second_max_freq = second_max_freq;
+#else
+    if (cpufreq_verbose)
+        printk("max_freq: %u\n", max_freq);
+#endif
     policy->min = policy->cpuinfo.min_freq = min_freq;
     policy->max = policy->cpuinfo.max_freq = max_freq;
-    policy->cpuinfo.second_max_freq = second_max_freq;
 
     if (policy->min == ~0)
         return -EINVAL;
@@ -390,6 +397,7 @@ int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag)
     return policy->cur;
 }
 
+#ifdef HAS_CPU_TURBO
 int cpufreq_update_turbo(int cpuid, int new_state)
 {
     struct cpufreq_policy *policy;
@@ -430,6 +438,7 @@ int cpufreq_get_turbo_status(int cpuid)
     policy = per_cpu(cpufreq_cpu_policy, cpuid);
     return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
 }
+#endif /* HAS_CPU_TURBO */
 
 /*********************************************************************
  *                 POLICY                                            *
diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
index 3486148..3154051 100644
--- a/xen/drivers/pm/stat.c
+++ b/xen/drivers/pm/stat.c
@@ -292,7 +292,11 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
             &op->u.get_para.u.ondemand.sampling_rate,
             &op->u.get_para.u.ondemand.up_threshold);
     }
+#ifdef HAS_CPU_TURBO
     op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid);
+#else
+    op->u.get_para.turbo_enabled = 0;
+#endif
 
     return ret;
 }
@@ -475,6 +479,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         break;
     }
 
+#ifdef HAS_CPU_TURBO
     case XEN_SYSCTL_pm_op_enable_turbo:
     {
         ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
@@ -486,6 +491,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
         break;
     }
+#endif /* HAS_CPU_TURBO */
 
     default:
         printk("not defined sub-hypercall @ do_pm_op\n");
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index 82dc4dc..d7b6c34 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -39,7 +39,9 @@ extern struct acpi_cpufreq_data *cpufreq_drv_data[NR_CPUS];
 
 struct cpufreq_cpuinfo {
     unsigned int        max_freq;
+#ifdef HAS_CPU_TURBO
     unsigned int        second_max_freq;    /* P1 if Turbo Mode is on */
+#endif
     unsigned int        min_freq;
     unsigned int        transition_latency; /* in 10^(-9) s = nanoseconds */
 };
@@ -59,10 +61,12 @@ struct cpufreq_policy {
 
     bool_t              resume; /* flag for cpufreq 1st run
                                  * S3 wakeup, hotplug cpu, etc */
+#ifdef HAS_CPU_TURBO
     s8                  turbo;  /* tristate flag: 0 for unsupported
                                  * -1 for disable, 1 for enabled
                                  * See CPUFREQ_TURBO_* below for defines */
     bool_t              aperf_mperf; /* CPU has APERF/MPERF MSRs */
+#endif
 };
 DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy);
 
@@ -127,8 +131,10 @@ extern int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag);
 #define CPUFREQ_TURBO_UNSUPPORTED   0
 #define CPUFREQ_TURBO_ENABLED       1
 
+#ifdef HAS_CPU_TURBO
 extern int cpufreq_update_turbo(int cpuid, int new_state);
 extern int cpufreq_get_turbo_status(int cpuid);
+#endif
 
 static __inline__ int 
 __cpufreq_governor(struct cpufreq_policy *policy, unsigned int event)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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.xen.org>)
	id 1Xldr5-0004eB-4i; Tue, 04 Nov 2014 13:09:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldr3-0004cp-5M
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:01 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	E7/5D-25727-CEFC8545; Tue, 04 Nov 2014 13:09:00 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415106536!11535610!1
X-Originating-IP: [64.18.0.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2953 invoked from network); 4 Nov 2014 13:08:59 -0000
Received: from exprod5og110.obsmtp.com (HELO exprod5og110.obsmtp.com)
	(64.18.0.20)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:08:59 -0000
Received: from mail-la0-f52.google.com ([209.85.215.52]) (using TLSv1) by
	exprod5ob110.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP6LxeY5sMajQmkE4WxYMdKu6W/l7j@postini.com;
	Tue, 04 Nov 2014 05:08:58 PST
Received: by mail-la0-f52.google.com with SMTP id pv20so843464lab.11
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=713bit2g0RhvBKeHzo9XWlypOoemnEZ6Rrwf4CVZRDY=;
	b=PaTs4Hbj/YvhLZUp82ctEY2ck9HaOEI8fHBX15NEt2mPHbZT/9yNmM7rXJrPNzREwd
	37VltmVymKI5tFSpX4Y7H93Q62ASsBG+SpzcWMk+4ST2GiSYiJjwura8Kiu+j77kaC3x
	jnOUA3ZfFn33ufw2KMFG8tsDRQ9paPxkD+cZo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=713bit2g0RhvBKeHzo9XWlypOoemnEZ6Rrwf4CVZRDY=;
	b=YgvOe/OlEYmvSkG+OEHK8SpvF43VKeBoVAdhwAHkuuxdCyIr9suDCLGEsqdROFo3N6
	zwU8qZog7gL6ENOUKLBjLr7coV0adzPGK4IZ9y+3Osqcwj3DjJ9g467S3tUfbJK8Iwqy
	e7Cd9WHr2irEbtH8J67MhtYxXKf0AJTZqpjLHSbHEI+Isa1X1OMFTOgH2la0o7J73VPI
	WsFKcKtpBRm82bmTXdv49Z3dTAC+AGUZfXi9MhcM5ABuXlfDrO/hI6sjEj4WoDfEH/yy
	kz5YhZFMyoUJcyw2yDaKP2TBAE8tOoZS8+DxE1kcCLmJFwK8Hht5VNSiMWaiGB2Q6E4A
	TfQw==
X-Gm-Message-State: ALoCoQlLodgpGRHzHp52yAJSNey3FjkhJ3WWObcwRDcWf+jdblgC6I9IshQq8ZlxFigtvurgh3jIq4uepahs1WoCMLXvQSQujdoeHT8JmDjbjVUQ+lVXmJzRkv87S3+zsH8oe/UTQlrYj0OyW/RbSM5ODbKQPefXGg==
X-Received: by 10.112.199.40 with SMTP id jh8mr53487816lbc.5.1415106534722;
	Tue, 04 Nov 2014 05:08:54 -0800 (PST)
X-Received: by 10.112.199.40 with SMTP id jh8mr53487802lbc.5.1415106534636;
	Tue, 04 Nov 2014 05:08:54 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id i6sm136694laf.47.2014.11.04.05.08.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:53 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:34 +0200
Message-Id: <1415106521-3115-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 04/11] cpufreq: make turbo settings to be
	configurable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This settings is not needed for some architectures.
So make it to be configurable and use it for x86
architecture.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                  |  1 +
 xen/arch/x86/Rules.mk         |  1 +
 xen/drivers/cpufreq/utility.c | 11 ++++++++++-
 xen/drivers/pm/stat.c         |  6 ++++++
 xen/include/xen/cpufreq.h     |  6 ++++++
 5 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index b7caab6..5953152 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_PM)        += -DHAS_PM
+CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 9e9fbf1..cfe4f90 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -4,6 +4,7 @@
 HAS_IOPORTS := y
 HAS_ACPI := y
 HAS_PM := y
+HAS_CPU_TURBO := y
 HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 3cb0b3e..e92cf17 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -209,7 +209,9 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
 {
     unsigned int min_freq = ~0;
     unsigned int max_freq = 0;
+#ifdef HAS_CPU_TURBO
     unsigned int second_max_freq = 0;
+#endif
     unsigned int i;
 
     for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
@@ -221,6 +223,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
         if (freq > max_freq)
             max_freq = freq;
     }
+#ifdef HAS_CPU_TURBO
     for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
         unsigned int freq = table[i].frequency;
         if (freq == CPUFREQ_ENTRY_INVALID || freq == max_freq)
@@ -234,9 +237,13 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
         printk("max_freq: %u    second_max_freq: %u\n",
                max_freq, second_max_freq);
 
+    policy->cpuinfo.second_max_freq = second_max_freq;
+#else
+    if (cpufreq_verbose)
+        printk("max_freq: %u\n", max_freq);
+#endif
     policy->min = policy->cpuinfo.min_freq = min_freq;
     policy->max = policy->cpuinfo.max_freq = max_freq;
-    policy->cpuinfo.second_max_freq = second_max_freq;
 
     if (policy->min == ~0)
         return -EINVAL;
@@ -390,6 +397,7 @@ int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag)
     return policy->cur;
 }
 
+#ifdef HAS_CPU_TURBO
 int cpufreq_update_turbo(int cpuid, int new_state)
 {
     struct cpufreq_policy *policy;
@@ -430,6 +438,7 @@ int cpufreq_get_turbo_status(int cpuid)
     policy = per_cpu(cpufreq_cpu_policy, cpuid);
     return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
 }
+#endif /* HAS_CPU_TURBO */
 
 /*********************************************************************
  *                 POLICY                                            *
diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
index 3486148..3154051 100644
--- a/xen/drivers/pm/stat.c
+++ b/xen/drivers/pm/stat.c
@@ -292,7 +292,11 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
             &op->u.get_para.u.ondemand.sampling_rate,
             &op->u.get_para.u.ondemand.up_threshold);
     }
+#ifdef HAS_CPU_TURBO
     op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid);
+#else
+    op->u.get_para.turbo_enabled = 0;
+#endif
 
     return ret;
 }
@@ -475,6 +479,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         break;
     }
 
+#ifdef HAS_CPU_TURBO
     case XEN_SYSCTL_pm_op_enable_turbo:
     {
         ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
@@ -486,6 +491,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
         break;
     }
+#endif /* HAS_CPU_TURBO */
 
     default:
         printk("not defined sub-hypercall @ do_pm_op\n");
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index 82dc4dc..d7b6c34 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -39,7 +39,9 @@ extern struct acpi_cpufreq_data *cpufreq_drv_data[NR_CPUS];
 
 struct cpufreq_cpuinfo {
     unsigned int        max_freq;
+#ifdef HAS_CPU_TURBO
     unsigned int        second_max_freq;    /* P1 if Turbo Mode is on */
+#endif
     unsigned int        min_freq;
     unsigned int        transition_latency; /* in 10^(-9) s = nanoseconds */
 };
@@ -59,10 +61,12 @@ struct cpufreq_policy {
 
     bool_t              resume; /* flag for cpufreq 1st run
                                  * S3 wakeup, hotplug cpu, etc */
+#ifdef HAS_CPU_TURBO
     s8                  turbo;  /* tristate flag: 0 for unsupported
                                  * -1 for disable, 1 for enabled
                                  * See CPUFREQ_TURBO_* below for defines */
     bool_t              aperf_mperf; /* CPU has APERF/MPERF MSRs */
+#endif
 };
 DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy);
 
@@ -127,8 +131,10 @@ extern int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag);
 #define CPUFREQ_TURBO_UNSUPPORTED   0
 #define CPUFREQ_TURBO_ENABLED       1
 
+#ifdef HAS_CPU_TURBO
 extern int cpufreq_update_turbo(int cpuid, int new_state);
 extern int cpufreq_get_turbo_status(int cpuid);
+#endif
 
 static __inline__ int 
 __cpufreq_governor(struct cpufreq_policy *policy, unsigned int event)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1Xldr6-0004fZ-IO; Tue, 04 Nov 2014 13:09:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldr4-0004dV-Fe
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	16/DF-09842-DEFC8545; Tue, 04 Nov 2014 13:09:01 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415106539!12660345!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21903 invoked from network); 4 Nov 2014 13:09:01 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:01 -0000
Received: from mail-lb0-f177.google.com ([209.85.217.177]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP6mB2BV6KOKmZpuKESeUAy04OYrPd@postini.com;
	Tue, 04 Nov 2014 05:09:00 PST
Received: by mail-lb0-f177.google.com with SMTP id z12so2591351lbi.22
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=JgXU4x7QJOvEpUbbuKilOBLEpUATJDI4xA7NawUjB3k=;
	b=X9bGQJB3cVASh6M4Ncou1j6myY6JWbWSqymheHxoz8SH94Bf2wKgThCaVcZ2zGjE6V
	F+qBzqepqX4b8NJa5th52Q3xG+fC9RsJ9/3kzbuPmc9YxGAWhQ0Qf5E0qHDBHDnQvT8a
	tnh5L6sefzggGJH7k96Uav8/TSLjrUm8/vHMg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=JgXU4x7QJOvEpUbbuKilOBLEpUATJDI4xA7NawUjB3k=;
	b=f5myK3jGPfhqDkRDW8ii2Nc45cZYv5eabIy0su9vARTckjHs1CAS5oinhdHfbZa42u
	G41+DGF1UWaohp8+jjw0KN82vIGSsyP1dNV/Cb1x/fDTM9lzzYqu2LJws9UXapQZAnHc
	474KBy1MxtJmI0DLt5D0J4rW70oxGSIMK2iF2dIDmDN+mHlr4vbzKqTZUNtUKLVtyEua
	LDM+rAlCz/aAbHJxiWa56xJh6WROGiw7yt4ZOGTWwqKVjC4H+xKlf7UK6uejBehcJc2i
	PX0Ww6OGoGHaYyOxzsJ2i24f6aaJ05a7znNK9h2uSZswWRs0Tq/cTZYUiDaUq7o79Zeg
	wszA==
X-Gm-Message-State: ALoCoQlHPMgxqdwchG2ndFwNY7qSpIBIxPKbrlT3xySTxv92kG1uW/3QS1v/X/xlZO0Yz9QqpBo9xeEquXbmi1zcQYgB/8KRcbItGIa79omTvk8N7eqNKLkBrjUus0y7rF4fEKW0mw4yGvRbPLh7WRS/xrf1ZkwhQw==
X-Received: by 10.112.225.225 with SMTP id rn1mr21038114lbc.98.1415106537546; 
	Tue, 04 Nov 2014 05:08:57 -0800 (PST)
X-Received: by 10.112.225.225 with SMTP id rn1mr21038089lbc.98.1415106537384; 
	Tue, 04 Nov 2014 05:08:57 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id ql6sm146170lbb.31.2014.11.04.05.08.56
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:56 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:35 +0200
Message-Id: <1415106521-3115-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 05/11] pmstat: make pmstat functions more
	generalizable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ACPI-specific parts are moved under appropriate ifdefs.
Now pmstat functions can be used in ARM platform.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/drivers/pm/stat.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
index 3154051..1d13805 100644
--- a/xen/drivers/pm/stat.c
+++ b/xen/drivers/pm/stat.c
@@ -37,7 +37,6 @@
 #include <asm/processor.h>
 #include <xen/percpu.h>
 #include <xen/domain.h>
-#include <xen/acpi.h>
 
 #include <public/sysctl.h>
 #include <xen/cpufreq.h>
@@ -134,6 +133,8 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
         break;
     }
 
+/* For now those operations can be used only when ACPI is enabled */
+#ifdef CONFIG_ACPI
     case PMSTAT_get_max_cx:
     {
         op->u.getcx.nr = pmstat_get_cx_nr(op->cpuid);
@@ -152,6 +153,7 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
         ret = pmstat_reset_cx_stat(op->cpuid);
         break;
     }
+#endif /* CONFIG_ACPI */
 
     default:
         printk("not defined sub-hypercall @ do_get_pm_info\n");
@@ -467,6 +469,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         break;
     }
 
+#ifdef CONFIG_ACPI
     case XEN_SYSCTL_pm_op_get_max_cstate:
     {
         op->u.get_max_cstate = acpi_get_cstate_limit();
@@ -478,6 +481,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         acpi_set_cstate_limit(op->u.set_max_cstate);
         break;
     }
+#endif /* CONFIG_ACPI */
 
 #ifdef HAS_CPU_TURBO
     case XEN_SYSCTL_pm_op_enable_turbo:
@@ -502,6 +506,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
     return ret;
 }
 
+#ifdef CONFIG_ACPI
 int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 {
     u32 bits[3];
@@ -532,3 +537,4 @@ int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 
     return ret;
 }
+#endif /* CONFIG_ACPI */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1Xldr8-0004hH-WE; Tue, 04 Nov 2014 13:09:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldr8-0004ga-7G
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	21/5B-24532-1FFC8545; Tue, 04 Nov 2014 13:09:05 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415106542!12641308!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17329 invoked from network); 4 Nov 2014 13:09:04 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:04 -0000
Received: from mail-lb0-f182.google.com ([209.85.217.182]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP7ZIPeraj8J8sV5Sz7AUU1r9ApY7X@postini.com;
	Tue, 04 Nov 2014 05:09:03 PST
Received: by mail-lb0-f182.google.com with SMTP id f15so12328706lbj.27
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=TEp0XXM33rjuFXHRkECxmQNY/0lo/sUJ1ABQu6H7wAI=;
	b=eF5yAaYE/HxTfuGW/oG9u/44M0txRRacE9J1CJZRZih7c0rjuARFt0fGnxlCYdFGc0
	c1ee0iNOt3wLQPUASwVhn209Q93m6pGIdR8erYMsCSgXtE2ofkIgKpHXMBDgPP6bVFcp
	A8y043dHRi3ZJu0sWxcoH3plLFlOdt5094wUo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=TEp0XXM33rjuFXHRkECxmQNY/0lo/sUJ1ABQu6H7wAI=;
	b=VBWfIncP6mGT+wihnNxArG6qVVoO3VB1m1+uwEBv386KxGMeR0CH75eSYPNxAErWuj
	8gek7swRGYE9uCu7zSqDlsYJebIz0Vk3RoU72nBzdw2bDrLwfHJsBAD/+KY9teoVDf1a
	n8SE7AsOzsq6/oKG6cVJGAPjtJ1sv1eEAHScMOx27tAEDA2y1SDdhLu7Y9kAxHgn15In
	DTzTk26MJq8fIKXSxVgKrAncE3HqgV13y/sAxue6mqt0Iw9x+H4/ZFztyf/GV6vfdUPx
	ArlnVCaXhTofU2NbmZL8/UAx+ESuVtEII4Qw8uUYre4iRUccfFhcpc9wIJKrypjD9Z+F
	sx/A==
X-Gm-Message-State: ALoCoQmlmxSt9iyN2/+HpcEibfL9ubTdZBzA+MWkl0hp50HNapyMdu4qs11CCQ6jIzLOeg7TluvP8R3hDkEbtTL9RUQens5Vlb98hPsu7Cz7Gyno17jHrHX1+aOK0yTZUWq0vr+lP2Y/oBUcHQEfEja92gZKF5oqOw==
X-Received: by 10.153.7.170 with SMTP id dd10mr59606247lad.45.1415106540397;
	Tue, 04 Nov 2014 05:09:00 -0800 (PST)
X-Received: by 10.153.7.170 with SMTP id dd10mr59606239lad.45.1415106540321;
	Tue, 04 Nov 2014 05:09:00 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id d9sm135432lbp.49.2014.11.04.05.08.58
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:59 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:36 +0200
Message-Id: <1415106521-3115-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 06/11] cpufreq: make cpufreq driver more
	generalizable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

First implementation of the cpufreq driver has been
written with x86 in mind. This patch makes possible
the cpufreq driver be working on both x86 and arm
architectures.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                     |  1 +
 xen/drivers/cpufreq/cpufreq.c    | 80 +++++++++++++++++++++++++++++++++++++---
 xen/include/public/platform.h    |  1 +
 xen/include/xen/processor_perf.h |  7 ++++
 4 files changed, 83 insertions(+), 6 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 5953152..3b0b89b 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -55,6 +55,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
 CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index f5f4d75..1644096 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -43,7 +43,6 @@
 #include <asm/io.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
-#include <acpi/acpi.h>
 #include <xen/cpufreq.h>
 
 static unsigned int __read_mostly usr_min_freq;
@@ -192,6 +191,7 @@ int cpufreq_add_cpu(unsigned int cpu)
     } else {
         /* domain sanity check under whatever coordination type */
         firstcpu = cpumask_first(cpufreq_dom->map);
+#ifdef CONFIG_ACPI
         if ((perf->domain_info.coord_type !=
             processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
             (perf->domain_info.num_processors !=
@@ -207,6 +207,18 @@ int cpufreq_add_cpu(unsigned int cpu)
                 );
             return -EINVAL;
         }
+#else /* CONFIG_ACPI */
+        if ((perf->domain_info.num_processors !=
+            processor_pminfo[firstcpu]->perf.domain_info.num_processors)) {
+
+            printk(KERN_WARNING "cpufreq fail to add CPU%d:"
+                   "incorrect num processors (%"PRIu64"), expect(%"PRIu64")\n",
+                   cpu, perf->domain_info.num_processors,
+                   processor_pminfo[firstcpu]->perf.domain_info.num_processors
+                );
+            return -EINVAL;
+        }
+#endif /* CONFIG_ACPI */
     }
 
     if (!domexist || hw_all) {
@@ -363,6 +375,7 @@ int cpufreq_del_cpu(unsigned int cpu)
     return 0;
 }
 
+#ifdef CONFIG_ACPI
 static void print_PCT(struct xen_pct_register *ptr)
 {
     printk("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
@@ -370,12 +383,14 @@ static void print_PCT(struct xen_pct_register *ptr)
            ptr->descriptor, ptr->length, ptr->space_id, ptr->bit_width,
            ptr->bit_offset, ptr->reserved, ptr->address);
 }
+#endif
 
 static void print_PSS(struct xen_processor_px *ptr, int count)
 {
     int i;
     printk("\t_PSS: state_count=%d\n", count);
     for (i=0; i<count; i++){
+#ifdef CONFIG_ACPI
         printk("\tState%d: %"PRId64"MHz %"PRId64"mW %"PRId64"us "
                "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",
                i,
@@ -385,15 +400,26 @@ static void print_PSS(struct xen_processor_px *ptr, int count)
                ptr[i].bus_master_latency,
                ptr[i].control,
                ptr[i].status);
+#else /* CONFIG_ACPI */
+        printk("\tState%d: %"PRId64"MHz %"PRId64"us\n",
+               i,
+               ptr[i].core_frequency,
+               ptr[i].transition_latency);
+#endif /* CONFIG_ACPI */
     }
 }
 
 static void print_PSD( struct xen_psd_package *ptr)
 {
+#ifdef CONFIG_ACPI
     printk("\t_PSD: num_entries=%"PRId64" rev=%"PRId64
            " domain=%"PRId64" coord_type=%"PRId64" num_processors=%"PRId64"\n",
            ptr->num_entries, ptr->revision, ptr->domain, ptr->coord_type,
            ptr->num_processors);
+#else /* CONFIG_ACPI */
+    printk("\t_PSD:  domain=%"PRId64" num_processors=%"PRId64"\n",
+           ptr->domain, ptr->num_processors);
+#endif /* CONFIG_ACPI */
 }
 
 static void print_PPC(unsigned int platform_limit)
@@ -401,13 +427,53 @@ static void print_PPC(unsigned int platform_limit)
     printk("\t_PPC: %d\n", platform_limit);
 }
 
+static inline uint32_t is_pss_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PSS;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_psd_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PSD;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_ppc_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PPC;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_all_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags == ( XEN_PX_PCT | XEN_PX_PSS | XEN_PX_PSD | XEN_PX_PPC );
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
 int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_info)
 {
     int ret=0, cpuid;
     struct processor_pminfo *pmpt;
     struct processor_performance *pxpt;
 
+#ifdef CONFIG_ACPI
     cpuid = get_cpu_id(acpi_id);
+#else
+    cpuid = acpi_id;
+#endif
     if ( cpuid < 0 || !dom0_px_info)
     {
         ret = -EINVAL;
@@ -429,6 +495,8 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
         processor_pminfo[cpuid] = pmpt;
     }
     pxpt = &pmpt->perf;
+
+#ifdef CONFIG_ACPI
     pmpt->acpi_id = acpi_id;
     pmpt->id = cpuid;
 
@@ -455,8 +523,9 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PCT(&pxpt->status_register);
         }
     }
+#endif /* CONFIG_ACPI */
 
-    if ( dom0_px_info->flags & XEN_PX_PSS ) 
+    if ( is_pss_data(dom0_px_info) )
     {
         /* capability check */
         if (dom0_px_info->state_count <= 1)
@@ -483,7 +552,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PSS(pxpt->states,pxpt->state_count);
     }
 
-    if ( dom0_px_info->flags & XEN_PX_PSD )
+    if ( is_psd_data(dom0_px_info) )
     {
         /* check domain coordination */
         if (dom0_px_info->shared_type != CPUFREQ_SHARED_TYPE_ALL &&
@@ -503,7 +572,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PSD(&pxpt->domain_info);
     }
 
-    if ( dom0_px_info->flags & XEN_PX_PPC )
+    if ( is_ppc_data(dom0_px_info) )
     {
         pxpt->platform_limit = dom0_px_info->platform_limit;
 
@@ -517,8 +586,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
         }
     }
 
-    if ( dom0_px_info->flags == ( XEN_PX_PCT | XEN_PX_PSS |
-                XEN_PX_PSD | XEN_PX_PPC ) )
+    if ( is_all_data(dom0_px_info) )
     {
         pxpt->init = XEN_PX_INIT;
 
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 4341f54..ccb7969 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -358,6 +358,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t);
 #define XEN_PX_PSS   2
 #define XEN_PX_PPC   4
 #define XEN_PX_PSD   8
+#define XEN_PX_DATA  16
 
 struct xen_power_register {
     uint32_t     space_id;
diff --git a/xen/include/xen/processor_perf.h b/xen/include/xen/processor_perf.h
index d8a1ba6..6c1279d 100644
--- a/xen/include/xen/processor_perf.h
+++ b/xen/include/xen/processor_perf.h
@@ -3,7 +3,10 @@
 
 #include <public/platform.h>
 #include <public/sysctl.h>
+
+#ifdef CONFIG_ACPI
 #include <xen/acpi.h>
+#endif
 
 #define XEN_PX_INIT 0x80000000
 
@@ -24,8 +27,10 @@ int  cpufreq_del_cpu(unsigned int);
 struct processor_performance {
     uint32_t state;
     uint32_t platform_limit;
+#ifdef CONFIG_ACPI
     struct xen_pct_register control_register;
     struct xen_pct_register status_register;
+#endif
     uint32_t state_count;
     struct xen_processor_px *states;
     struct xen_psd_package domain_info;
@@ -35,8 +40,10 @@ struct processor_performance {
 };
 
 struct processor_pminfo {
+#ifdef CONFIG_ACPI
     uint32_t acpi_id;
     uint32_t id;
+#endif
     struct processor_performance    perf;
 };
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1Xldr6-0004fZ-IO; Tue, 04 Nov 2014 13:09:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldr4-0004dV-Fe
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	16/DF-09842-DEFC8545; Tue, 04 Nov 2014 13:09:01 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415106539!12660345!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21903 invoked from network); 4 Nov 2014 13:09:01 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:01 -0000
Received: from mail-lb0-f177.google.com ([209.85.217.177]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP6mB2BV6KOKmZpuKESeUAy04OYrPd@postini.com;
	Tue, 04 Nov 2014 05:09:00 PST
Received: by mail-lb0-f177.google.com with SMTP id z12so2591351lbi.22
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:08:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=JgXU4x7QJOvEpUbbuKilOBLEpUATJDI4xA7NawUjB3k=;
	b=X9bGQJB3cVASh6M4Ncou1j6myY6JWbWSqymheHxoz8SH94Bf2wKgThCaVcZ2zGjE6V
	F+qBzqepqX4b8NJa5th52Q3xG+fC9RsJ9/3kzbuPmc9YxGAWhQ0Qf5E0qHDBHDnQvT8a
	tnh5L6sefzggGJH7k96Uav8/TSLjrUm8/vHMg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=JgXU4x7QJOvEpUbbuKilOBLEpUATJDI4xA7NawUjB3k=;
	b=f5myK3jGPfhqDkRDW8ii2Nc45cZYv5eabIy0su9vARTckjHs1CAS5oinhdHfbZa42u
	G41+DGF1UWaohp8+jjw0KN82vIGSsyP1dNV/Cb1x/fDTM9lzzYqu2LJws9UXapQZAnHc
	474KBy1MxtJmI0DLt5D0J4rW70oxGSIMK2iF2dIDmDN+mHlr4vbzKqTZUNtUKLVtyEua
	LDM+rAlCz/aAbHJxiWa56xJh6WROGiw7yt4ZOGTWwqKVjC4H+xKlf7UK6uejBehcJc2i
	PX0Ww6OGoGHaYyOxzsJ2i24f6aaJ05a7znNK9h2uSZswWRs0Tq/cTZYUiDaUq7o79Zeg
	wszA==
X-Gm-Message-State: ALoCoQlHPMgxqdwchG2ndFwNY7qSpIBIxPKbrlT3xySTxv92kG1uW/3QS1v/X/xlZO0Yz9QqpBo9xeEquXbmi1zcQYgB/8KRcbItGIa79omTvk8N7eqNKLkBrjUus0y7rF4fEKW0mw4yGvRbPLh7WRS/xrf1ZkwhQw==
X-Received: by 10.112.225.225 with SMTP id rn1mr21038114lbc.98.1415106537546; 
	Tue, 04 Nov 2014 05:08:57 -0800 (PST)
X-Received: by 10.112.225.225 with SMTP id rn1mr21038089lbc.98.1415106537384; 
	Tue, 04 Nov 2014 05:08:57 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id ql6sm146170lbb.31.2014.11.04.05.08.56
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:56 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:35 +0200
Message-Id: <1415106521-3115-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 05/11] pmstat: make pmstat functions more
	generalizable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ACPI-specific parts are moved under appropriate ifdefs.
Now pmstat functions can be used in ARM platform.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/drivers/pm/stat.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
index 3154051..1d13805 100644
--- a/xen/drivers/pm/stat.c
+++ b/xen/drivers/pm/stat.c
@@ -37,7 +37,6 @@
 #include <asm/processor.h>
 #include <xen/percpu.h>
 #include <xen/domain.h>
-#include <xen/acpi.h>
 
 #include <public/sysctl.h>
 #include <xen/cpufreq.h>
@@ -134,6 +133,8 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
         break;
     }
 
+/* For now those operations can be used only when ACPI is enabled */
+#ifdef CONFIG_ACPI
     case PMSTAT_get_max_cx:
     {
         op->u.getcx.nr = pmstat_get_cx_nr(op->cpuid);
@@ -152,6 +153,7 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
         ret = pmstat_reset_cx_stat(op->cpuid);
         break;
     }
+#endif /* CONFIG_ACPI */
 
     default:
         printk("not defined sub-hypercall @ do_get_pm_info\n");
@@ -467,6 +469,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         break;
     }
 
+#ifdef CONFIG_ACPI
     case XEN_SYSCTL_pm_op_get_max_cstate:
     {
         op->u.get_max_cstate = acpi_get_cstate_limit();
@@ -478,6 +481,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         acpi_set_cstate_limit(op->u.set_max_cstate);
         break;
     }
+#endif /* CONFIG_ACPI */
 
 #ifdef HAS_CPU_TURBO
     case XEN_SYSCTL_pm_op_enable_turbo:
@@ -502,6 +506,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
     return ret;
 }
 
+#ifdef CONFIG_ACPI
 int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 {
     u32 bits[3];
@@ -532,3 +537,4 @@ int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 
     return ret;
 }
+#endif /* CONFIG_ACPI */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1Xldr8-0004hH-WE; Tue, 04 Nov 2014 13:09:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldr8-0004ga-7G
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	21/5B-24532-1FFC8545; Tue, 04 Nov 2014 13:09:05 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415106542!12641308!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17329 invoked from network); 4 Nov 2014 13:09:04 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:04 -0000
Received: from mail-lb0-f182.google.com ([209.85.217.182]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP7ZIPeraj8J8sV5Sz7AUU1r9ApY7X@postini.com;
	Tue, 04 Nov 2014 05:09:03 PST
Received: by mail-lb0-f182.google.com with SMTP id f15so12328706lbj.27
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=TEp0XXM33rjuFXHRkECxmQNY/0lo/sUJ1ABQu6H7wAI=;
	b=eF5yAaYE/HxTfuGW/oG9u/44M0txRRacE9J1CJZRZih7c0rjuARFt0fGnxlCYdFGc0
	c1ee0iNOt3wLQPUASwVhn209Q93m6pGIdR8erYMsCSgXtE2ofkIgKpHXMBDgPP6bVFcp
	A8y043dHRi3ZJu0sWxcoH3plLFlOdt5094wUo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=TEp0XXM33rjuFXHRkECxmQNY/0lo/sUJ1ABQu6H7wAI=;
	b=VBWfIncP6mGT+wihnNxArG6qVVoO3VB1m1+uwEBv386KxGMeR0CH75eSYPNxAErWuj
	8gek7swRGYE9uCu7zSqDlsYJebIz0Vk3RoU72nBzdw2bDrLwfHJsBAD/+KY9teoVDf1a
	n8SE7AsOzsq6/oKG6cVJGAPjtJ1sv1eEAHScMOx27tAEDA2y1SDdhLu7Y9kAxHgn15In
	DTzTk26MJq8fIKXSxVgKrAncE3HqgV13y/sAxue6mqt0Iw9x+H4/ZFztyf/GV6vfdUPx
	ArlnVCaXhTofU2NbmZL8/UAx+ESuVtEII4Qw8uUYre4iRUccfFhcpc9wIJKrypjD9Z+F
	sx/A==
X-Gm-Message-State: ALoCoQmlmxSt9iyN2/+HpcEibfL9ubTdZBzA+MWkl0hp50HNapyMdu4qs11CCQ6jIzLOeg7TluvP8R3hDkEbtTL9RUQens5Vlb98hPsu7Cz7Gyno17jHrHX1+aOK0yTZUWq0vr+lP2Y/oBUcHQEfEja92gZKF5oqOw==
X-Received: by 10.153.7.170 with SMTP id dd10mr59606247lad.45.1415106540397;
	Tue, 04 Nov 2014 05:09:00 -0800 (PST)
X-Received: by 10.153.7.170 with SMTP id dd10mr59606239lad.45.1415106540321;
	Tue, 04 Nov 2014 05:09:00 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id d9sm135432lbp.49.2014.11.04.05.08.58
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:08:59 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:36 +0200
Message-Id: <1415106521-3115-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 06/11] cpufreq: make cpufreq driver more
	generalizable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

First implementation of the cpufreq driver has been
written with x86 in mind. This patch makes possible
the cpufreq driver be working on both x86 and arm
architectures.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                     |  1 +
 xen/drivers/cpufreq/cpufreq.c    | 80 +++++++++++++++++++++++++++++++++++++---
 xen/include/public/platform.h    |  1 +
 xen/include/xen/processor_perf.h |  7 ++++
 4 files changed, 83 insertions(+), 6 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 5953152..3b0b89b 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -55,6 +55,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
 CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index f5f4d75..1644096 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -43,7 +43,6 @@
 #include <asm/io.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
-#include <acpi/acpi.h>
 #include <xen/cpufreq.h>
 
 static unsigned int __read_mostly usr_min_freq;
@@ -192,6 +191,7 @@ int cpufreq_add_cpu(unsigned int cpu)
     } else {
         /* domain sanity check under whatever coordination type */
         firstcpu = cpumask_first(cpufreq_dom->map);
+#ifdef CONFIG_ACPI
         if ((perf->domain_info.coord_type !=
             processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
             (perf->domain_info.num_processors !=
@@ -207,6 +207,18 @@ int cpufreq_add_cpu(unsigned int cpu)
                 );
             return -EINVAL;
         }
+#else /* CONFIG_ACPI */
+        if ((perf->domain_info.num_processors !=
+            processor_pminfo[firstcpu]->perf.domain_info.num_processors)) {
+
+            printk(KERN_WARNING "cpufreq fail to add CPU%d:"
+                   "incorrect num processors (%"PRIu64"), expect(%"PRIu64")\n",
+                   cpu, perf->domain_info.num_processors,
+                   processor_pminfo[firstcpu]->perf.domain_info.num_processors
+                );
+            return -EINVAL;
+        }
+#endif /* CONFIG_ACPI */
     }
 
     if (!domexist || hw_all) {
@@ -363,6 +375,7 @@ int cpufreq_del_cpu(unsigned int cpu)
     return 0;
 }
 
+#ifdef CONFIG_ACPI
 static void print_PCT(struct xen_pct_register *ptr)
 {
     printk("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
@@ -370,12 +383,14 @@ static void print_PCT(struct xen_pct_register *ptr)
            ptr->descriptor, ptr->length, ptr->space_id, ptr->bit_width,
            ptr->bit_offset, ptr->reserved, ptr->address);
 }
+#endif
 
 static void print_PSS(struct xen_processor_px *ptr, int count)
 {
     int i;
     printk("\t_PSS: state_count=%d\n", count);
     for (i=0; i<count; i++){
+#ifdef CONFIG_ACPI
         printk("\tState%d: %"PRId64"MHz %"PRId64"mW %"PRId64"us "
                "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",
                i,
@@ -385,15 +400,26 @@ static void print_PSS(struct xen_processor_px *ptr, int count)
                ptr[i].bus_master_latency,
                ptr[i].control,
                ptr[i].status);
+#else /* CONFIG_ACPI */
+        printk("\tState%d: %"PRId64"MHz %"PRId64"us\n",
+               i,
+               ptr[i].core_frequency,
+               ptr[i].transition_latency);
+#endif /* CONFIG_ACPI */
     }
 }
 
 static void print_PSD( struct xen_psd_package *ptr)
 {
+#ifdef CONFIG_ACPI
     printk("\t_PSD: num_entries=%"PRId64" rev=%"PRId64
            " domain=%"PRId64" coord_type=%"PRId64" num_processors=%"PRId64"\n",
            ptr->num_entries, ptr->revision, ptr->domain, ptr->coord_type,
            ptr->num_processors);
+#else /* CONFIG_ACPI */
+    printk("\t_PSD:  domain=%"PRId64" num_processors=%"PRId64"\n",
+           ptr->domain, ptr->num_processors);
+#endif /* CONFIG_ACPI */
 }
 
 static void print_PPC(unsigned int platform_limit)
@@ -401,13 +427,53 @@ static void print_PPC(unsigned int platform_limit)
     printk("\t_PPC: %d\n", platform_limit);
 }
 
+static inline uint32_t is_pss_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PSS;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_psd_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PSD;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_ppc_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PPC;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_all_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags == ( XEN_PX_PCT | XEN_PX_PSS | XEN_PX_PSD | XEN_PX_PPC );
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
 int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_info)
 {
     int ret=0, cpuid;
     struct processor_pminfo *pmpt;
     struct processor_performance *pxpt;
 
+#ifdef CONFIG_ACPI
     cpuid = get_cpu_id(acpi_id);
+#else
+    cpuid = acpi_id;
+#endif
     if ( cpuid < 0 || !dom0_px_info)
     {
         ret = -EINVAL;
@@ -429,6 +495,8 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
         processor_pminfo[cpuid] = pmpt;
     }
     pxpt = &pmpt->perf;
+
+#ifdef CONFIG_ACPI
     pmpt->acpi_id = acpi_id;
     pmpt->id = cpuid;
 
@@ -455,8 +523,9 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PCT(&pxpt->status_register);
         }
     }
+#endif /* CONFIG_ACPI */
 
-    if ( dom0_px_info->flags & XEN_PX_PSS ) 
+    if ( is_pss_data(dom0_px_info) )
     {
         /* capability check */
         if (dom0_px_info->state_count <= 1)
@@ -483,7 +552,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PSS(pxpt->states,pxpt->state_count);
     }
 
-    if ( dom0_px_info->flags & XEN_PX_PSD )
+    if ( is_psd_data(dom0_px_info) )
     {
         /* check domain coordination */
         if (dom0_px_info->shared_type != CPUFREQ_SHARED_TYPE_ALL &&
@@ -503,7 +572,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PSD(&pxpt->domain_info);
     }
 
-    if ( dom0_px_info->flags & XEN_PX_PPC )
+    if ( is_ppc_data(dom0_px_info) )
     {
         pxpt->platform_limit = dom0_px_info->platform_limit;
 
@@ -517,8 +586,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
         }
     }
 
-    if ( dom0_px_info->flags == ( XEN_PX_PCT | XEN_PX_PSS |
-                XEN_PX_PSD | XEN_PX_PPC ) )
+    if ( is_all_data(dom0_px_info) )
     {
         pxpt->init = XEN_PX_INIT;
 
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 4341f54..ccb7969 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -358,6 +358,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t);
 #define XEN_PX_PSS   2
 #define XEN_PX_PPC   4
 #define XEN_PX_PSD   8
+#define XEN_PX_DATA  16
 
 struct xen_power_register {
     uint32_t     space_id;
diff --git a/xen/include/xen/processor_perf.h b/xen/include/xen/processor_perf.h
index d8a1ba6..6c1279d 100644
--- a/xen/include/xen/processor_perf.h
+++ b/xen/include/xen/processor_perf.h
@@ -3,7 +3,10 @@
 
 #include <public/platform.h>
 #include <public/sysctl.h>
+
+#ifdef CONFIG_ACPI
 #include <xen/acpi.h>
+#endif
 
 #define XEN_PX_INIT 0x80000000
 
@@ -24,8 +27,10 @@ int  cpufreq_del_cpu(unsigned int);
 struct processor_performance {
     uint32_t state;
     uint32_t platform_limit;
+#ifdef CONFIG_ACPI
     struct xen_pct_register control_register;
     struct xen_pct_register status_register;
+#endif
     uint32_t state_count;
     struct xen_processor_px *states;
     struct xen_psd_package domain_info;
@@ -35,8 +40,10 @@ struct processor_performance {
 };
 
 struct processor_pminfo {
+#ifdef CONFIG_ACPI
     uint32_t acpi_id;
     uint32_t id;
+#endif
     struct processor_performance    perf;
 };
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldrC-0004kM-KN; Tue, 04 Nov 2014 13:09:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XldrA-0004iS-Ji
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A3/6B-24532-4FFC8545; Tue, 04 Nov 2014 13:09:08 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415106544!12615446!1
X-Originating-IP: [64.18.0.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16555 invoked from network); 4 Nov 2014 13:09:06 -0000
Received: from exprod5og104.obsmtp.com (HELO exprod5og104.obsmtp.com)
	(64.18.0.178)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:06 -0000
Received: from mail-la0-f47.google.com ([209.85.215.47]) (using TLSv1) by
	exprod5ob104.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP8LkHxC0iWDQfGFEjYb6QFivEr+hI@postini.com;
	Tue, 04 Nov 2014 05:09:06 PST
Received: by mail-la0-f47.google.com with SMTP id gd6so822648lab.6
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=+oiOKckGVDosptw1S7D6HF8HmwOpIZSsoFCNbEeDF1Y=;
	b=aTqyI4mL5oN6KInySUGk5qn3ptHlJqNIIEZfPXVbIQ+eyzhHRhTxNIXRRTNvZE5uXl
	Dqb1wRIABJfj00Ut0Q7f77GsR2aNeVFZHml9IY7WPEIUj7dkQH8gLTzhC+Vo+s09hfun
	ejrWJUQBPG1uklztBz/9otCYTcCS1XuoyZDdc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=+oiOKckGVDosptw1S7D6HF8HmwOpIZSsoFCNbEeDF1Y=;
	b=diqxMtRKgm++FjuzFUr4CH8Cv78/C3LCOni5aY1oPA1Uh4QvhBcS7vnDJHLe6aesbf
	xLQcl0syS7k9nYrc1UAw1cgg4qehMu+ejZmSg2Ncdl2vo78erOyzc7nQZUV/Vn/7m3mE
	SWRT9vTqaFhIudyeNqsCDfgFHlVby/JsFAERW0eXc3G5Dv5B694j3tH5S0rraQiYDKPv
	m83INjz/OR9wBI3tPnYx7uViHhn4NIZBa5x6eJsmQSMOdmNuBzEUIo0U1euCVVndufEX
	iSKhAJpFGH98mtIPnyYbH5r2FLqGlpyPOZjhFtYU0t5BOcfd3qV9ErAY5bC1nItsc/Fw
	AI1A==
X-Gm-Message-State: ALoCoQm2loT8vXnBcOpvgTt5FSv6xx+5QBqPEAmd+RMm9QCBwT8pFhRBOGl9sMHg0zn3IN11PON3ex0E1sCTy45o0HBHOnGMXKbXmASQ8UdJfKd8nE7Kp+R+lB4WkWktS3d/ozPUh2DHsVztPO6TvW97o1l4fw/Z8g==
X-Received: by 10.152.7.175 with SMTP id k15mr58713115laa.58.1415106542993;
	Tue, 04 Nov 2014 05:09:02 -0800 (PST)
X-Received: by 10.152.7.175 with SMTP id k15mr58713106laa.58.1415106542912;
	Tue, 04 Nov 2014 05:09:02 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id q7sm145703laq.32.2014.11.04.05.09.01
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:02 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:37 +0200
Message-Id: <1415106521-3115-8-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 07/11] arch/arm: create device tree nodes
	for hwdom cpufreq cpu driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch copies all cpu@0..cpu@N nodes (from input
device tree) with properties to /hypervisor/pcpus
node (device tree for hwdom). Thus we can give all
information about all physical CPUs in the pcpus node.
Driver in hwdom should parse /hypervisor/pcpus path
instead of the /cpus path in the device tree.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/domain_build.c | 78 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 70 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2db0236..87e05c7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -326,8 +326,64 @@ static int make_memory_node(const struct domain *d,
     return res;
 }
 
-static int make_hypervisor_node(struct domain *d,
-                                void *fdt, const struct dt_device_node *parent)
+#ifdef HAS_HWDOM_CPUFREQ
+static int fdt_copy_phys_cpus_nodes(struct domain *d, struct kernel_info *kinfo)
+{
+    int res;
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *npcpu;
+    char *node_name;
+
+    if ( !cpus )
+    {
+        dprintk(XENLOG_ERR, "Missing /cpus node in the device tree?\n");
+        return -ENOENT;
+    }
+
+    /*
+     * create pcpus node and copy to it
+     * original cpu@0..cpu@N nodes with its properties.
+     * This is needed for the cpufreq cpu driver in Dom0
+     */
+    DPRINT("Create pcpus node\n");
+
+    res = fdt_begin_node(kinfo->fdt, "pcpus");
+    if ( res )
+        return res;
+
+    dt_for_each_child_node( cpus, npcpu )
+    {
+        if ( dt_device_type_is_equal(npcpu, "cpu") )
+        {
+            node_name = strrchr(dt_node_full_name(npcpu), '/');
+            ASSERT(node_name);
+
+            node_name++;
+            ASSERT(*node_name);
+
+            DPRINT("Copy %s node to the pcpus\n", node_name);
+
+            res = fdt_begin_node(kinfo->fdt, node_name);
+            if ( res )
+                return res;
+
+            res = write_properties(d, kinfo, npcpu);
+            if ( res )
+                return res;
+
+            res = fdt_end_node(kinfo->fdt);
+            if ( res )
+                return res;
+        }
+    }
+
+    res = fdt_end_node(kinfo->fdt);
+    return res;
+}
+#endif /* HAS_HWDOM_CPUFREQ */
+
+static int make_hypervisor_node(struct domain *d, struct kernel_info *kinfo,
+                                const struct dt_device_node *parent)
 {
     const char compat[] =
         "xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
@@ -351,12 +407,12 @@ static int make_hypervisor_node(struct domain *d,
         panic("Cannot cope with this size");
 
     /* See linux Documentation/devicetree/bindings/arm/xen.txt */
-    res = fdt_begin_node(fdt, "hypervisor");
+    res = fdt_begin_node(kinfo->fdt, "hypervisor");
     if ( res )
         return res;
 
     /* Cannot use fdt_property_string due to embedded nulls */
-    res = fdt_property(fdt, "compatible", compat, sizeof(compat));
+    res = fdt_property(kinfo->fdt, "compatible", compat, sizeof(compat));
     if ( res )
         return res;
 
@@ -366,7 +422,7 @@ static int make_hypervisor_node(struct domain *d,
     /* reg 0 is grant table space */
     cells = &reg[0];
     dt_set_range(&cells, parent, gnttab_start, gnttab_size);
-    res = fdt_property(fdt, "reg", reg,
+    res = fdt_property(kinfo->fdt, "reg", reg,
                        dt_cells_to_size(addrcells + sizecells));
     if ( res )
         return res;
@@ -382,11 +438,17 @@ static int make_hypervisor_node(struct domain *d,
     set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf,
                    DT_IRQ_TYPE_LEVEL_LOW);
 
-    res = fdt_property_interrupts(fdt, &intr, 1);
+    res = fdt_property_interrupts(kinfo->fdt, &intr, 1);
     if ( res )
         return res;
 
-    res = fdt_end_node(fdt);
+    #ifdef HAS_HWDOM_CPUFREQ
+    res = fdt_copy_phys_cpus_nodes(d, kinfo);
+    if ( res )
+        return res;
+    #endif
+
+    res = fdt_end_node(kinfo->fdt);
 
     return res;
 }
@@ -863,7 +925,7 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo,
 
     if ( node == dt_host )
     {
-        res = make_hypervisor_node(d, kinfo->fdt, node);
+        res = make_hypervisor_node(d, kinfo, node);
         if ( res )
             return res;
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldrC-0004kM-KN; Tue, 04 Nov 2014 13:09:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XldrA-0004iS-Ji
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A3/6B-24532-4FFC8545; Tue, 04 Nov 2014 13:09:08 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415106544!12615446!1
X-Originating-IP: [64.18.0.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16555 invoked from network); 4 Nov 2014 13:09:06 -0000
Received: from exprod5og104.obsmtp.com (HELO exprod5og104.obsmtp.com)
	(64.18.0.178)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:06 -0000
Received: from mail-la0-f47.google.com ([209.85.215.47]) (using TLSv1) by
	exprod5ob104.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP8LkHxC0iWDQfGFEjYb6QFivEr+hI@postini.com;
	Tue, 04 Nov 2014 05:09:06 PST
Received: by mail-la0-f47.google.com with SMTP id gd6so822648lab.6
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=+oiOKckGVDosptw1S7D6HF8HmwOpIZSsoFCNbEeDF1Y=;
	b=aTqyI4mL5oN6KInySUGk5qn3ptHlJqNIIEZfPXVbIQ+eyzhHRhTxNIXRRTNvZE5uXl
	Dqb1wRIABJfj00Ut0Q7f77GsR2aNeVFZHml9IY7WPEIUj7dkQH8gLTzhC+Vo+s09hfun
	ejrWJUQBPG1uklztBz/9otCYTcCS1XuoyZDdc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=+oiOKckGVDosptw1S7D6HF8HmwOpIZSsoFCNbEeDF1Y=;
	b=diqxMtRKgm++FjuzFUr4CH8Cv78/C3LCOni5aY1oPA1Uh4QvhBcS7vnDJHLe6aesbf
	xLQcl0syS7k9nYrc1UAw1cgg4qehMu+ejZmSg2Ncdl2vo78erOyzc7nQZUV/Vn/7m3mE
	SWRT9vTqaFhIudyeNqsCDfgFHlVby/JsFAERW0eXc3G5Dv5B694j3tH5S0rraQiYDKPv
	m83INjz/OR9wBI3tPnYx7uViHhn4NIZBa5x6eJsmQSMOdmNuBzEUIo0U1euCVVndufEX
	iSKhAJpFGH98mtIPnyYbH5r2FLqGlpyPOZjhFtYU0t5BOcfd3qV9ErAY5bC1nItsc/Fw
	AI1A==
X-Gm-Message-State: ALoCoQm2loT8vXnBcOpvgTt5FSv6xx+5QBqPEAmd+RMm9QCBwT8pFhRBOGl9sMHg0zn3IN11PON3ex0E1sCTy45o0HBHOnGMXKbXmASQ8UdJfKd8nE7Kp+R+lB4WkWktS3d/ozPUh2DHsVztPO6TvW97o1l4fw/Z8g==
X-Received: by 10.152.7.175 with SMTP id k15mr58713115laa.58.1415106542993;
	Tue, 04 Nov 2014 05:09:02 -0800 (PST)
X-Received: by 10.152.7.175 with SMTP id k15mr58713106laa.58.1415106542912;
	Tue, 04 Nov 2014 05:09:02 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id q7sm145703laq.32.2014.11.04.05.09.01
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:02 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:37 +0200
Message-Id: <1415106521-3115-8-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 07/11] arch/arm: create device tree nodes
	for hwdom cpufreq cpu driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch copies all cpu@0..cpu@N nodes (from input
device tree) with properties to /hypervisor/pcpus
node (device tree for hwdom). Thus we can give all
information about all physical CPUs in the pcpus node.
Driver in hwdom should parse /hypervisor/pcpus path
instead of the /cpus path in the device tree.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/domain_build.c | 78 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 70 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2db0236..87e05c7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -326,8 +326,64 @@ static int make_memory_node(const struct domain *d,
     return res;
 }
 
-static int make_hypervisor_node(struct domain *d,
-                                void *fdt, const struct dt_device_node *parent)
+#ifdef HAS_HWDOM_CPUFREQ
+static int fdt_copy_phys_cpus_nodes(struct domain *d, struct kernel_info *kinfo)
+{
+    int res;
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *npcpu;
+    char *node_name;
+
+    if ( !cpus )
+    {
+        dprintk(XENLOG_ERR, "Missing /cpus node in the device tree?\n");
+        return -ENOENT;
+    }
+
+    /*
+     * create pcpus node and copy to it
+     * original cpu@0..cpu@N nodes with its properties.
+     * This is needed for the cpufreq cpu driver in Dom0
+     */
+    DPRINT("Create pcpus node\n");
+
+    res = fdt_begin_node(kinfo->fdt, "pcpus");
+    if ( res )
+        return res;
+
+    dt_for_each_child_node( cpus, npcpu )
+    {
+        if ( dt_device_type_is_equal(npcpu, "cpu") )
+        {
+            node_name = strrchr(dt_node_full_name(npcpu), '/');
+            ASSERT(node_name);
+
+            node_name++;
+            ASSERT(*node_name);
+
+            DPRINT("Copy %s node to the pcpus\n", node_name);
+
+            res = fdt_begin_node(kinfo->fdt, node_name);
+            if ( res )
+                return res;
+
+            res = write_properties(d, kinfo, npcpu);
+            if ( res )
+                return res;
+
+            res = fdt_end_node(kinfo->fdt);
+            if ( res )
+                return res;
+        }
+    }
+
+    res = fdt_end_node(kinfo->fdt);
+    return res;
+}
+#endif /* HAS_HWDOM_CPUFREQ */
+
+static int make_hypervisor_node(struct domain *d, struct kernel_info *kinfo,
+                                const struct dt_device_node *parent)
 {
     const char compat[] =
         "xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
@@ -351,12 +407,12 @@ static int make_hypervisor_node(struct domain *d,
         panic("Cannot cope with this size");
 
     /* See linux Documentation/devicetree/bindings/arm/xen.txt */
-    res = fdt_begin_node(fdt, "hypervisor");
+    res = fdt_begin_node(kinfo->fdt, "hypervisor");
     if ( res )
         return res;
 
     /* Cannot use fdt_property_string due to embedded nulls */
-    res = fdt_property(fdt, "compatible", compat, sizeof(compat));
+    res = fdt_property(kinfo->fdt, "compatible", compat, sizeof(compat));
     if ( res )
         return res;
 
@@ -366,7 +422,7 @@ static int make_hypervisor_node(struct domain *d,
     /* reg 0 is grant table space */
     cells = &reg[0];
     dt_set_range(&cells, parent, gnttab_start, gnttab_size);
-    res = fdt_property(fdt, "reg", reg,
+    res = fdt_property(kinfo->fdt, "reg", reg,
                        dt_cells_to_size(addrcells + sizecells));
     if ( res )
         return res;
@@ -382,11 +438,17 @@ static int make_hypervisor_node(struct domain *d,
     set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf,
                    DT_IRQ_TYPE_LEVEL_LOW);
 
-    res = fdt_property_interrupts(fdt, &intr, 1);
+    res = fdt_property_interrupts(kinfo->fdt, &intr, 1);
     if ( res )
         return res;
 
-    res = fdt_end_node(fdt);
+    #ifdef HAS_HWDOM_CPUFREQ
+    res = fdt_copy_phys_cpus_nodes(d, kinfo);
+    if ( res )
+        return res;
+    #endif
+
+    res = fdt_end_node(kinfo->fdt);
 
     return res;
 }
@@ -863,7 +925,7 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo,
 
     if ( node == dt_host )
     {
-        res = make_hypervisor_node(d, kinfo->fdt, node);
+        res = make_hypervisor_node(d, kinfo, node);
         if ( res )
             return res;
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldrE-0004m3-69; Tue, 04 Nov 2014 13:09:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XldrD-0004kd-9V
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:11 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	ED/DA-09936-6FFC8545; Tue, 04 Nov 2014 13:09:10 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415106547!12654556!1
X-Originating-IP: [64.18.0.189]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20140 invoked from network); 4 Nov 2014 13:09:09 -0000
Received: from exprod5og119.obsmtp.com (HELO exprod5og119.obsmtp.com)
	(64.18.0.189)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:09 -0000
Received: from mail-lb0-f169.google.com ([209.85.217.169]) (using TLSv1) by
	exprod5ob119.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP80RyXcJXIZY9SQ3inWo3OxqrFC+B@postini.com;
	Tue, 04 Nov 2014 05:09:09 PST
Received: by mail-lb0-f169.google.com with SMTP id 10so898971lbg.0
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=EFIS12KyxsCwv9kQH84nHK59oU6tRkfcIXPnJNzPRhA=;
	b=Mdo5LgI6WEOtyZXZGwIhRk3PJ9zYQb8oznPPaPmPFgi/NnLu5hCBM6uu/XU5AaVXgg
	UgUcNYpvxJ0KFqh5HzyzniMTqFJ8xh2Ay3oEdXLGvRnxDwpmBmGBairbuU7Lc05tiCJu
	4qRwTzS5UbI65QTyTDoEOsLJY13xZuyoOFVr0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=EFIS12KyxsCwv9kQH84nHK59oU6tRkfcIXPnJNzPRhA=;
	b=Jy3hTLTHvHBEs65F68y6dNzDPgFdf2Jk/1lBVcSW7QWfJU5RmFMy7RocrfUqQ0MKpT
	xj6o/oKlQ3plIzbrkBLiAxxS6Qy2gcDxTIXNL4sUDDARDB75sHE9YXsuYm1IFcS7Wxy1
	RhKL62jPX1Sc+I6AwRrOHR4Qj4suXEWqleD42oeLAqVqowFdYb4qaTYUuVjzpaGLrQCY
	722Y8W3rSC0V6kjrAygbRs8+VetIJguQrPIM4RYigtVuIf53xrVU5U+gq0saPnP+Cm5u
	rd03WnEroaEl13L6nl7aWQB8c3s22xSXcNgnkHk72FcFXytwIcI6ncDnJMKg5xYgym0u
	bbXg==
X-Gm-Message-State: ALoCoQlJHMuruJuj90Z1FSvLeeaPVRJx+JxUC+wA3Cg18t5ltCnfsaBg/t59hpZdFqae46+e03ZOWxZDgHv1rnqM92sGsCuevcvmthdp9IzEqSRMf/wemQziz/IiuO+Ry2l4bXd58nB6W7I+kzzBwFV34Tmg9y6ofA==
X-Received: by 10.152.20.199 with SMTP id p7mr59630212lae.49.1415106545897;
	Tue, 04 Nov 2014 05:09:05 -0800 (PST)
X-Received: by 10.152.20.199 with SMTP id p7mr59630201lae.49.1415106545824;
	Tue, 04 Nov 2014 05:09:05 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id q6sm155648lag.12.2014.11.04.05.09.04
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:05 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:38 +0200
Message-Id: <1415106521-3115-9-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 08/11] xen: arm: implement platform
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch enables xsm_platform_op hook for all architectures
and implements platform hypercall for ARM.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/Makefile             |  1 +
 xen/arch/arm/platform_hypercall.c | 84 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c              |  1 +
 xen/include/xsm/dummy.h           | 12 +++---
 xen/include/xsm/xsm.h             | 10 ++---
 xen/xsm/flask/hooks.c             |  3 +-
 6 files changed, 99 insertions(+), 12 deletions(-)
 create mode 100644 xen/arch/arm/platform_hypercall.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index d70f6d5..54d8258 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -32,6 +32,7 @@ obj-y += vuart.o
 obj-y += hvm.o
 obj-y += device.o
 obj-y += decode.o
+obj-y += platform_hypercall.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/platform_hypercall.c b/xen/arch/arm/platform_hypercall.c
new file mode 100644
index 0000000..f14641b
--- /dev/null
+++ b/xen/arch/arm/platform_hypercall.c
@@ -0,0 +1,84 @@
+/******************************************************************************
+ * platform_hypercall.c
+ *
+ * Hardware platform operations. Intended for use by domain-0 kernel.
+ *
+ * Copyright (c) 2014 GlobalLogic Inc.
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/sched.h>
+#include <xen/event.h>
+#include <xen/guest_access.h>
+#include <xen/pmstat.h>
+#include <xen/irq.h>
+#include <public/platform.h>
+#include <xsm/xsm.h>
+
+static DEFINE_SPINLOCK(xenpf_lock);
+
+long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
+{
+    long ret = 0;
+    struct xen_platform_op curop, *op = &curop;
+
+    if ( copy_from_guest(op, u_xenpf_op, 1) )
+        return -EFAULT;
+
+    if ( op->interface_version != XENPF_INTERFACE_VERSION )
+        return -EACCES;
+
+    ret = xsm_platform_op(XSM_PRIV, op->cmd);
+    if ( ret )
+        return ret;
+
+    /*
+     * Trylock here avoids deadlock with an existing platform critical section
+     * which might (for some current or future reason) want to synchronise
+     * with this vcpu.
+     */
+    while ( !spin_trylock(&xenpf_lock) )
+        if ( hypercall_preempt_check() )
+            return hypercall_create_continuation(
+                __HYPERVISOR_platform_op, "h", u_xenpf_op);
+
+    switch ( op->cmd )
+    {
+    case XENPF_set_processor_pminfo:
+        switch ( op->u.set_pminfo.type )
+        {
+        case XEN_PM_PX:
+            if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
+            {
+                ret = -ENOSYS;
+                break;
+           }
+#ifdef HAS_CPUFREQ
+            ret = set_px_pminfo(op->u.set_pminfo.id, &op->u.set_pminfo.u.perf);
+#else
+            ret = -EINVAL;
+#endif
+            break;
+
+        default:
+            ret = -EINVAL;
+            break;
+        }
+        break;
+    }
+
+    spin_unlock(&xenpf_lock);
+
+    return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 21c7b26..d1b0014 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1012,6 +1012,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
     HYPERCALL(hvm_op, 2),
     HYPERCALL(grant_table_op, 3),
     HYPERCALL_ARM(vcpu_op, 3),
+    HYPERCALL(platform_op, 1),
 };
 
 typedef int (*arm_psci_fn_t)(uint32_t, register_t);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index eb9e1a1..911fb5d 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -491,6 +491,12 @@ static XSM_INLINE int xsm_hvm_param_nested(XSM_DEFAULT_ARG struct domain *d)
     return xsm_default_action(action, current->domain, d);
 }
 
+static XSM_INLINE int xsm_platform_op(XSM_DEFAULT_ARG uint32_t op)
+{
+    XSM_ASSERT_ACTION(XSM_PRIV);
+    return xsm_default_action(action, current->domain, NULL);
+}
+
 #ifdef CONFIG_X86
 static XSM_INLINE int xsm_shadow_control(XSM_DEFAULT_ARG struct domain *d, uint32_t op)
 {
@@ -546,12 +552,6 @@ static XSM_INLINE int xsm_apic(XSM_DEFAULT_ARG struct domain *d, int cmd)
     return xsm_default_action(action, d, NULL);
 }
 
-static XSM_INLINE int xsm_platform_op(XSM_DEFAULT_ARG uint32_t op)
-{
-    XSM_ASSERT_ACTION(XSM_PRIV);
-    return xsm_default_action(action, current->domain, NULL);
-}
-
 static XSM_INLINE int xsm_machine_memory_map(XSM_DEFAULT_VOID)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 1939453..5cb1e0d 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -509,6 +509,11 @@ static inline int xsm_hvm_param_nested (xsm_default_t def, struct domain *d)
     return xsm_ops->hvm_param_nested(d);
 }
 
+static inline int xsm_platform_op (xsm_default_t def, uint32_t op)
+{
+    return xsm_ops->platform_op(op);
+}
+
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (xsm_default_t def, struct domain *d, uint32_t op)
 {
@@ -560,11 +565,6 @@ static inline int xsm_memtype (xsm_default_t def, uint32_t access)
     return xsm_ops->memtype(access);
 }
 
-static inline int xsm_platform_op (xsm_default_t def, uint32_t op)
-{
-    return xsm_ops->platform_op(op);
-}
-
 static inline int xsm_machine_memory_map(xsm_default_t def)
 {
     return xsm_ops->machine_memory_map();
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d94ab77..29126ec 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1542,6 +1542,8 @@ static struct xsm_operations flask_ops = {
     .add_to_physmap = flask_add_to_physmap,
     .remove_from_physmap = flask_remove_from_physmap,
 
+    .platform_op = flask_platform_op,
+
 #ifdef CONFIG_X86
     .shadow_control = flask_shadow_control,
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
@@ -1552,7 +1554,6 @@ static struct xsm_operations flask_ops = {
     .mem_event_op = flask_mem_event_op,
     .mem_sharing_op = flask_mem_sharing_op,
     .apic = flask_apic,
-    .platform_op = flask_platform_op,
     .machine_memory_map = flask_machine_memory_map,
     .domain_memory_map = flask_domain_memory_map,
     .mmu_update = flask_mmu_update,
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldrE-0004m3-69; Tue, 04 Nov 2014 13:09:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XldrD-0004kd-9V
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:11 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	ED/DA-09936-6FFC8545; Tue, 04 Nov 2014 13:09:10 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415106547!12654556!1
X-Originating-IP: [64.18.0.189]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20140 invoked from network); 4 Nov 2014 13:09:09 -0000
Received: from exprod5og119.obsmtp.com (HELO exprod5og119.obsmtp.com)
	(64.18.0.189)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:09 -0000
Received: from mail-lb0-f169.google.com ([209.85.217.169]) (using TLSv1) by
	exprod5ob119.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP80RyXcJXIZY9SQ3inWo3OxqrFC+B@postini.com;
	Tue, 04 Nov 2014 05:09:09 PST
Received: by mail-lb0-f169.google.com with SMTP id 10so898971lbg.0
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=EFIS12KyxsCwv9kQH84nHK59oU6tRkfcIXPnJNzPRhA=;
	b=Mdo5LgI6WEOtyZXZGwIhRk3PJ9zYQb8oznPPaPmPFgi/NnLu5hCBM6uu/XU5AaVXgg
	UgUcNYpvxJ0KFqh5HzyzniMTqFJ8xh2Ay3oEdXLGvRnxDwpmBmGBairbuU7Lc05tiCJu
	4qRwTzS5UbI65QTyTDoEOsLJY13xZuyoOFVr0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=EFIS12KyxsCwv9kQH84nHK59oU6tRkfcIXPnJNzPRhA=;
	b=Jy3hTLTHvHBEs65F68y6dNzDPgFdf2Jk/1lBVcSW7QWfJU5RmFMy7RocrfUqQ0MKpT
	xj6o/oKlQ3plIzbrkBLiAxxS6Qy2gcDxTIXNL4sUDDARDB75sHE9YXsuYm1IFcS7Wxy1
	RhKL62jPX1Sc+I6AwRrOHR4Qj4suXEWqleD42oeLAqVqowFdYb4qaTYUuVjzpaGLrQCY
	722Y8W3rSC0V6kjrAygbRs8+VetIJguQrPIM4RYigtVuIf53xrVU5U+gq0saPnP+Cm5u
	rd03WnEroaEl13L6nl7aWQB8c3s22xSXcNgnkHk72FcFXytwIcI6ncDnJMKg5xYgym0u
	bbXg==
X-Gm-Message-State: ALoCoQlJHMuruJuj90Z1FSvLeeaPVRJx+JxUC+wA3Cg18t5ltCnfsaBg/t59hpZdFqae46+e03ZOWxZDgHv1rnqM92sGsCuevcvmthdp9IzEqSRMf/wemQziz/IiuO+Ry2l4bXd58nB6W7I+kzzBwFV34Tmg9y6ofA==
X-Received: by 10.152.20.199 with SMTP id p7mr59630212lae.49.1415106545897;
	Tue, 04 Nov 2014 05:09:05 -0800 (PST)
X-Received: by 10.152.20.199 with SMTP id p7mr59630201lae.49.1415106545824;
	Tue, 04 Nov 2014 05:09:05 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id q6sm155648lag.12.2014.11.04.05.09.04
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:05 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:38 +0200
Message-Id: <1415106521-3115-9-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 08/11] xen: arm: implement platform
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch enables xsm_platform_op hook for all architectures
and implements platform hypercall for ARM.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/Makefile             |  1 +
 xen/arch/arm/platform_hypercall.c | 84 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c              |  1 +
 xen/include/xsm/dummy.h           | 12 +++---
 xen/include/xsm/xsm.h             | 10 ++---
 xen/xsm/flask/hooks.c             |  3 +-
 6 files changed, 99 insertions(+), 12 deletions(-)
 create mode 100644 xen/arch/arm/platform_hypercall.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index d70f6d5..54d8258 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -32,6 +32,7 @@ obj-y += vuart.o
 obj-y += hvm.o
 obj-y += device.o
 obj-y += decode.o
+obj-y += platform_hypercall.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/platform_hypercall.c b/xen/arch/arm/platform_hypercall.c
new file mode 100644
index 0000000..f14641b
--- /dev/null
+++ b/xen/arch/arm/platform_hypercall.c
@@ -0,0 +1,84 @@
+/******************************************************************************
+ * platform_hypercall.c
+ *
+ * Hardware platform operations. Intended for use by domain-0 kernel.
+ *
+ * Copyright (c) 2014 GlobalLogic Inc.
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/sched.h>
+#include <xen/event.h>
+#include <xen/guest_access.h>
+#include <xen/pmstat.h>
+#include <xen/irq.h>
+#include <public/platform.h>
+#include <xsm/xsm.h>
+
+static DEFINE_SPINLOCK(xenpf_lock);
+
+long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
+{
+    long ret = 0;
+    struct xen_platform_op curop, *op = &curop;
+
+    if ( copy_from_guest(op, u_xenpf_op, 1) )
+        return -EFAULT;
+
+    if ( op->interface_version != XENPF_INTERFACE_VERSION )
+        return -EACCES;
+
+    ret = xsm_platform_op(XSM_PRIV, op->cmd);
+    if ( ret )
+        return ret;
+
+    /*
+     * Trylock here avoids deadlock with an existing platform critical section
+     * which might (for some current or future reason) want to synchronise
+     * with this vcpu.
+     */
+    while ( !spin_trylock(&xenpf_lock) )
+        if ( hypercall_preempt_check() )
+            return hypercall_create_continuation(
+                __HYPERVISOR_platform_op, "h", u_xenpf_op);
+
+    switch ( op->cmd )
+    {
+    case XENPF_set_processor_pminfo:
+        switch ( op->u.set_pminfo.type )
+        {
+        case XEN_PM_PX:
+            if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
+            {
+                ret = -ENOSYS;
+                break;
+           }
+#ifdef HAS_CPUFREQ
+            ret = set_px_pminfo(op->u.set_pminfo.id, &op->u.set_pminfo.u.perf);
+#else
+            ret = -EINVAL;
+#endif
+            break;
+
+        default:
+            ret = -EINVAL;
+            break;
+        }
+        break;
+    }
+
+    spin_unlock(&xenpf_lock);
+
+    return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 21c7b26..d1b0014 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1012,6 +1012,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
     HYPERCALL(hvm_op, 2),
     HYPERCALL(grant_table_op, 3),
     HYPERCALL_ARM(vcpu_op, 3),
+    HYPERCALL(platform_op, 1),
 };
 
 typedef int (*arm_psci_fn_t)(uint32_t, register_t);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index eb9e1a1..911fb5d 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -491,6 +491,12 @@ static XSM_INLINE int xsm_hvm_param_nested(XSM_DEFAULT_ARG struct domain *d)
     return xsm_default_action(action, current->domain, d);
 }
 
+static XSM_INLINE int xsm_platform_op(XSM_DEFAULT_ARG uint32_t op)
+{
+    XSM_ASSERT_ACTION(XSM_PRIV);
+    return xsm_default_action(action, current->domain, NULL);
+}
+
 #ifdef CONFIG_X86
 static XSM_INLINE int xsm_shadow_control(XSM_DEFAULT_ARG struct domain *d, uint32_t op)
 {
@@ -546,12 +552,6 @@ static XSM_INLINE int xsm_apic(XSM_DEFAULT_ARG struct domain *d, int cmd)
     return xsm_default_action(action, d, NULL);
 }
 
-static XSM_INLINE int xsm_platform_op(XSM_DEFAULT_ARG uint32_t op)
-{
-    XSM_ASSERT_ACTION(XSM_PRIV);
-    return xsm_default_action(action, current->domain, NULL);
-}
-
 static XSM_INLINE int xsm_machine_memory_map(XSM_DEFAULT_VOID)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 1939453..5cb1e0d 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -509,6 +509,11 @@ static inline int xsm_hvm_param_nested (xsm_default_t def, struct domain *d)
     return xsm_ops->hvm_param_nested(d);
 }
 
+static inline int xsm_platform_op (xsm_default_t def, uint32_t op)
+{
+    return xsm_ops->platform_op(op);
+}
+
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (xsm_default_t def, struct domain *d, uint32_t op)
 {
@@ -560,11 +565,6 @@ static inline int xsm_memtype (xsm_default_t def, uint32_t access)
     return xsm_ops->memtype(access);
 }
 
-static inline int xsm_platform_op (xsm_default_t def, uint32_t op)
-{
-    return xsm_ops->platform_op(op);
-}
-
 static inline int xsm_machine_memory_map(xsm_default_t def)
 {
     return xsm_ops->machine_memory_map();
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d94ab77..29126ec 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1542,6 +1542,8 @@ static struct xsm_operations flask_ops = {
     .add_to_physmap = flask_add_to_physmap,
     .remove_from_physmap = flask_remove_from_physmap,
 
+    .platform_op = flask_platform_op,
+
 #ifdef CONFIG_X86
     .shadow_control = flask_shadow_control,
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
@@ -1552,7 +1554,6 @@ static struct xsm_operations flask_ops = {
     .mem_event_op = flask_mem_event_op,
     .mem_sharing_op = flask_mem_sharing_op,
     .apic = flask_apic,
-    .platform_op = flask_platform_op,
     .machine_memory_map = flask_machine_memory_map,
     .domain_memory_map = flask_domain_memory_map,
     .mmu_update = flask_mmu_update,
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldrG-0004oa-KI; Tue, 04 Nov 2014 13:09:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XldrF-0004mo-5m
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CF/EA-09936-8FFC8545; Tue, 04 Nov 2014 13:09:12 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415106549!12691266!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1953 invoked from network); 4 Nov 2014 13:09:11 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:11 -0000
Received: from mail-lb0-f173.google.com ([209.85.217.173]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP9UMLBfoiKDvDVCG4TVUVwbA/jUFw@postini.com;
	Tue, 04 Nov 2014 05:09:11 PST
Received: by mail-lb0-f173.google.com with SMTP id n15so888489lbi.32
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=WquRDHQbXobI0xctmf0B2WKgixh/YZoT9YcSRitlm00=;
	b=gX9e7tVnPIb4XF7DQjk3cNYeeOhALnvoN/LMwAYKqMAfS3pzcJhHl1X41voCe3XD+j
	0HEY1BE/+AVZlDWDTihd4r6fdpIdtKuNkQL8Q+v+Ak7XHFw8J/6+o+dqxMdKj20fX1YU
	OQXFgvMzSMdP1dYlzcUigOu4Fz645kaZnmFcc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=WquRDHQbXobI0xctmf0B2WKgixh/YZoT9YcSRitlm00=;
	b=W1Eg8eVZBuYeisi+0oolFzJx6JMNFh0+P0Dg3OWsc91vQAvywEUwLXgbWNynyETS6t
	xD5pombe/V7oot1NNLQIk6CdBL1v6X9c/o9IUe9H9Vb0VexMc2eEmVqdBqAmQz4BWZaG
	D5p0QIhkIG7MWOaabTCc7EGTpzmpbJhp/18rpSddbsIhx9rGPVIqG/Hm6//5zkzPCiGA
	af5hjb4KxpI1Cxy+iOZ0F14TNFvO9qgmZOgTR6kmTL1SN5mRkAR8SOQfWyXQLmLGyGOv
	zqsT3Q59gOZJ4vdp1OJaLE5+wd6obzZyvScBCetVAmbf/Pf2iqQ5u9XGaJ4zcqEFaejP
	lfuA==
X-Gm-Message-State: ALoCoQlBnn1x9AWFgN1fcWqVY/d35GaeCVTSZNKegEEbG8gTtsem3tfKP9AdNkeeVvu2LoCCPLEDkXLrysWYQZ16KKADxyeMt9BXKwtKma9iKidM2VvVW3qqrGkFOaanAogWomm+XQxY/eu8iVfNZr9mCc4w6JomPw==
X-Received: by 10.152.87.131 with SMTP id ay3mr20728411lab.97.1415106548124;
	Tue, 04 Nov 2014 05:09:08 -0800 (PST)
X-Received: by 10.152.87.131 with SMTP id ay3mr20728398lab.97.1415106548038;
	Tue, 04 Nov 2014 05:09:08 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id bv2sm150832lbd.22.2014.11.04.05.09.06
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:07 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:39 +0200
Message-Id: <1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared info
	definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This shared info will be used by hwdom-cpufreq driver
to send commands to the cpufreq driver in the hwdom.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/include/asm-arm/shared.h  | 14 ++++++++++++++
 xen/include/public/arch-arm.h |  8 ++++++++
 2 files changed, 22 insertions(+)
 create mode 100644 xen/include/asm-arm/shared.h

diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
new file mode 100644
index 0000000..4906f38
--- /dev/null
+++ b/xen/include/asm-arm/shared.h
@@ -0,0 +1,14 @@
+#ifndef __XEN_ARM_SHARED_H__
+#define __XEN_ARM_SHARED_H__
+
+#define GET_SET_SHARED(type, field)                                 \
+static inline type *arch_get_##field##_addr(const struct domain *d) \
+{                                                                   \
+   return &d->shared_info->arch.field;                              \
+}
+
+GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
+
+#undef GET_SET_SHARED
+
+#endif /* __XEN_ARM_SHARED_H__ */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 7496556..7eef6f7 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -309,7 +309,15 @@ struct arch_vcpu_info {
 };
 typedef struct arch_vcpu_info arch_vcpu_info_t;
 
+struct cpufreq_sh_info {
+    uint32_t cpu;       /* Physical CPU number */
+    uint32_t freq;      /* Frequency in KHz */
+    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
+    int32_t result;        /* Returned result of the operation */
+};
+
 struct arch_shared_info {
+    struct cpufreq_sh_info cpufreq;
 };
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldrG-0004oa-KI; Tue, 04 Nov 2014 13:09:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XldrF-0004mo-5m
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CF/EA-09936-8FFC8545; Tue, 04 Nov 2014 13:09:12 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415106549!12691266!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1953 invoked from network); 4 Nov 2014 13:09:11 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:11 -0000
Received: from mail-lb0-f173.google.com ([209.85.217.173]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP9UMLBfoiKDvDVCG4TVUVwbA/jUFw@postini.com;
	Tue, 04 Nov 2014 05:09:11 PST
Received: by mail-lb0-f173.google.com with SMTP id n15so888489lbi.32
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=WquRDHQbXobI0xctmf0B2WKgixh/YZoT9YcSRitlm00=;
	b=gX9e7tVnPIb4XF7DQjk3cNYeeOhALnvoN/LMwAYKqMAfS3pzcJhHl1X41voCe3XD+j
	0HEY1BE/+AVZlDWDTihd4r6fdpIdtKuNkQL8Q+v+Ak7XHFw8J/6+o+dqxMdKj20fX1YU
	OQXFgvMzSMdP1dYlzcUigOu4Fz645kaZnmFcc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=WquRDHQbXobI0xctmf0B2WKgixh/YZoT9YcSRitlm00=;
	b=W1Eg8eVZBuYeisi+0oolFzJx6JMNFh0+P0Dg3OWsc91vQAvywEUwLXgbWNynyETS6t
	xD5pombe/V7oot1NNLQIk6CdBL1v6X9c/o9IUe9H9Vb0VexMc2eEmVqdBqAmQz4BWZaG
	D5p0QIhkIG7MWOaabTCc7EGTpzmpbJhp/18rpSddbsIhx9rGPVIqG/Hm6//5zkzPCiGA
	af5hjb4KxpI1Cxy+iOZ0F14TNFvO9qgmZOgTR6kmTL1SN5mRkAR8SOQfWyXQLmLGyGOv
	zqsT3Q59gOZJ4vdp1OJaLE5+wd6obzZyvScBCetVAmbf/Pf2iqQ5u9XGaJ4zcqEFaejP
	lfuA==
X-Gm-Message-State: ALoCoQlBnn1x9AWFgN1fcWqVY/d35GaeCVTSZNKegEEbG8gTtsem3tfKP9AdNkeeVvu2LoCCPLEDkXLrysWYQZ16KKADxyeMt9BXKwtKma9iKidM2VvVW3qqrGkFOaanAogWomm+XQxY/eu8iVfNZr9mCc4w6JomPw==
X-Received: by 10.152.87.131 with SMTP id ay3mr20728411lab.97.1415106548124;
	Tue, 04 Nov 2014 05:09:08 -0800 (PST)
X-Received: by 10.152.87.131 with SMTP id ay3mr20728398lab.97.1415106548038;
	Tue, 04 Nov 2014 05:09:08 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id bv2sm150832lbd.22.2014.11.04.05.09.06
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:07 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:39 +0200
Message-Id: <1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared info
	definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This shared info will be used by hwdom-cpufreq driver
to send commands to the cpufreq driver in the hwdom.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/include/asm-arm/shared.h  | 14 ++++++++++++++
 xen/include/public/arch-arm.h |  8 ++++++++
 2 files changed, 22 insertions(+)
 create mode 100644 xen/include/asm-arm/shared.h

diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
new file mode 100644
index 0000000..4906f38
--- /dev/null
+++ b/xen/include/asm-arm/shared.h
@@ -0,0 +1,14 @@
+#ifndef __XEN_ARM_SHARED_H__
+#define __XEN_ARM_SHARED_H__
+
+#define GET_SET_SHARED(type, field)                                 \
+static inline type *arch_get_##field##_addr(const struct domain *d) \
+{                                                                   \
+   return &d->shared_info->arch.field;                              \
+}
+
+GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
+
+#undef GET_SET_SHARED
+
+#endif /* __XEN_ARM_SHARED_H__ */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 7496556..7eef6f7 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -309,7 +309,15 @@ struct arch_vcpu_info {
 };
 typedef struct arch_vcpu_info arch_vcpu_info_t;
 
+struct cpufreq_sh_info {
+    uint32_t cpu;       /* Physical CPU number */
+    uint32_t freq;      /* Frequency in KHz */
+    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
+    int32_t result;        /* Returned result of the operation */
+};
+
 struct arch_shared_info {
+    struct cpufreq_sh_info cpufreq;
 };
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldrK-0004rq-1t; Tue, 04 Nov 2014 13:09:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XldrI-0004px-BV
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D3/0B-09936-BFFC8545; Tue, 04 Nov 2014 13:09:15 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415106552!12654576!1
X-Originating-IP: [64.18.0.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20517 invoked from network); 4 Nov 2014 13:09:14 -0000
Received: from exprod5og126.obsmtp.com (HELO exprod5og126.obsmtp.com)
	(64.18.0.251)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:14 -0000
Received: from mail-lb0-f181.google.com ([209.85.217.181]) (using TLSv1) by
	exprod5ob126.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP9zoLdM5fec8S+h5mUKe8lVlfY9sp@postini.com;
	Tue, 04 Nov 2014 05:09:13 PST
Received: by mail-lb0-f181.google.com with SMTP id l4so4301948lbv.40
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=pH0+jMJciF8fjmEVLqUyuQJ/ElsqmExrY040KyWJg0k=;
	b=PvjBTcQ6JZtPEob4pWw2yIYzlx1Uu+53bFNAIPF9i5ZgErGkjNIhQWUQIWmIeik1Nf
	DQ+oti+4MKHAxk9P3oTGSL3yAzVmOrNExZrYbrSOWUJdRQC9EfBVnPrjFR9NQ5sdF8tO
	tqRfZ914FnKT2QQ70ssMD2174b9v6rK6Z4H+s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=pH0+jMJciF8fjmEVLqUyuQJ/ElsqmExrY040KyWJg0k=;
	b=d/KkPFXLfEXdB0Bio7q12NRf57Od7MNLfqcAvEt+uuE3O2SAzFOdb9ZhI7pP6acQnK
	AnKV8pH/JRbhA652wfjTYEA/2D4DrPIBWiQcItLyU90vVkrbBHBgK6rueBwwgYsWSuX6
	XBbwBY/K+zj/Pqx97vP5UgbA2TQSvBIZHBeJmH763i3e2RqzbnG+/NxJ1jZNLdAM6hBG
	f1rJjUSa+LcOtuKJ1HbXrqwr9xe5n/flyrxRToSAQGyFijlNHkrIkmmCTlL/xbPKZ/Jx
	CmhU62e0rGRb1rj3rdEEfU16WY2nqXRgPgOKIVizr7vhF3EInk6juoJ4rfqQYok/u5Hq
	v3bA==
X-Gm-Message-State: ALoCoQmcBq8lkKDPvYt6ipPJUNvov6h/hytbAvNz4cdoqb1Ej5308+tn82aXt/jGZ+lzIe1wXblWSnSRBQ2XetSrtEQcgN0KmhBU0d1tQt0p+kYzpaLcEMfWfqGL7N9NVNfWPWnhHgEGNfDHKEcEd74wmKGVVUx+Xw==
X-Received: by 10.112.199.40 with SMTP id jh8mr53489498lbc.5.1415106550427;
	Tue, 04 Nov 2014 05:09:10 -0800 (PST)
X-Received: by 10.112.199.40 with SMTP id jh8mr53489481lbc.5.1415106550346;
	Tue, 04 Nov 2014 05:09:10 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id rb2sm153717lbb.17.2014.11.04.05.09.09
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:09 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:40 +0200
Message-Id: <1415106521-3115-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 10/11] cpufreq: add hwdom-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This driver uses hwdom to change frequencies on CPUs
Workflow:
 * cpufreq governor driver in Xen wants to change the
   frequency of the physical CPU
 * hwdom-cpufreq driver sets parameters in the shared
   memory
 * hwdom-cpufreq driver sends an VIRQ_CPUFREQ interrupt
   to notify the hardware domain
 * cpufreq driver in the hardware domain reads parameters
   from the shared memory, changes frequency and copies
   the result of the operation to the shared memory

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                        |   1 +
 xen/drivers/cpufreq/Makefile        |   1 +
 xen/drivers/cpufreq/hwdom-cpufreq.c | 252 ++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h            |   1 +
 4 files changed, 255 insertions(+)
 create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3b0b89b..cccbc72 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
+CFLAGS-$(HAS_HWDOM_CPUFREQ) += -DHAS_HWDOM_CPUFREQ
 CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
diff --git a/xen/drivers/cpufreq/Makefile b/xen/drivers/cpufreq/Makefile
index b87d127..891997c 100644
--- a/xen/drivers/cpufreq/Makefile
+++ b/xen/drivers/cpufreq/Makefile
@@ -2,3 +2,4 @@ obj-y += cpufreq.o
 obj-y += cpufreq_ondemand.o
 obj-y += cpufreq_misc_governors.o
 obj-y += utility.o
+obj-$(HAS_HWDOM_CPUFREQ) += hwdom-cpufreq.o
diff --git a/xen/drivers/cpufreq/hwdom-cpufreq.c b/xen/drivers/cpufreq/hwdom-cpufreq.c
new file mode 100644
index 0000000..a39fc6c
--- /dev/null
+++ b/xen/drivers/cpufreq/hwdom-cpufreq.c
@@ -0,0 +1,252 @@
+/*
+ *  Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
+ *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
+ *  Copyright (C) 2002 - 2004 Dominik Brodowski <linux@brodo.de>
+ *  Copyright (C) 2006        Denis Sadykov <denis.m.sadykov@intel.com>
+ *
+ *  Feb 2008 - Liu Jinsong <jinsong.liu@intel.com>
+ *      porting acpi-cpufreq.c from Linux 2.6.23 to Xen hypervisor
+ *
+ *  Copyright (C) 2014 GlobalLogic Inc.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <xen/types.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/event.h>
+#include <xen/irq.h>
+#include <xen/spinlock.h>
+#include <xen/cpufreq.h>
+#include <xen/err.h>
+#include <asm/shared.h>
+#include <asm/current.h>
+#include <asm/system.h>
+
+struct hwdom_cpufreq_data {
+    struct processor_performance *perf_data;
+    struct cpufreq_frequency_table *freq_table;
+};
+
+static struct hwdom_cpufreq_data *hwdom_cpufreq_drv_data[NR_CPUS];
+
+int cpufreq_cpu_init(unsigned int cpuid)
+{
+    return cpufreq_add_cpu(cpuid);
+}
+
+static void notify_cpufreq_domain(void)
+{
+    send_global_virq(VIRQ_CPUFREQ);
+}
+
+static int hwdom_cpufreq_verify(struct cpufreq_policy *policy)
+{
+    struct hwdom_cpufreq_data *data;
+    struct processor_performance *perf;
+
+    if ( !policy || !(data = hwdom_cpufreq_drv_data[policy->cpu]) ||
+         !processor_pminfo[policy->cpu] )
+        return -EINVAL;
+
+    perf = &processor_pminfo[policy->cpu]->perf;
+
+    cpufreq_verify_within_limits(policy, 0,
+        perf->states[perf->platform_limit].core_frequency * 1000);
+
+    return cpufreq_frequency_table_verify(policy, data->freq_table);
+}
+
+static int hwdom_cpufreq_target(struct cpufreq_policy *policy,
+                               unsigned int target_freq, unsigned int relation)
+{
+    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
+    struct processor_performance *perf;
+    struct cpufreq_freqs freqs;
+    struct cpufreq_sh_info *cpufreq_info;
+    cpumask_t online_policy_cpus;
+    unsigned int next_state = 0; /* Index into freq_table */
+    unsigned int next_perf_state = 0; /* Index into perf table */
+    unsigned int j;
+    int ret = 0;
+
+    if ( unlikely(data == NULL ||
+         data->perf_data == NULL || data->freq_table == NULL) )
+        return -ENODEV;
+
+    perf = data->perf_data;
+    ret = cpufreq_frequency_table_target(policy,
+                                         data->freq_table,
+                                         target_freq,
+                                         relation, &next_state);
+    if ( unlikely(ret) )
+        return -ENODEV;
+
+    cpumask_and(&online_policy_cpus, &cpu_online_map, policy->cpus);
+
+    next_perf_state = data->freq_table[next_state].index;
+    if ( perf->state == next_perf_state )
+    {
+        if ( unlikely(policy->resume) )
+            policy->resume = 0;
+        else
+            return 0;
+    }
+
+    freqs.old = perf->states[perf->state].core_frequency * 1000;
+    freqs.new = data->freq_table[next_state].frequency;
+
+     /* Do send cmd for Hardware domain */
+    cpufreq_info = arch_get_cpufreq_addr(dom0);
+
+    /* Set previous result in the Hardware domain then read it */
+    smp_rmb();
+
+     /* return previous result */
+    ret = cpufreq_info->result;
+
+    cpufreq_info->cpu = policy->cpu;
+    cpufreq_info->freq = freqs.new;
+    cpufreq_info->relation = (uint32_t)relation;
+
+    smp_wmb(); /* above must be visible before notify_cpufreq_domain() */
+
+    notify_cpufreq_domain();
+
+    for_each_cpu( j, &online_policy_cpus )
+        cpufreq_statistic_update(j, perf->state, next_perf_state);
+
+    perf->state = next_perf_state;
+    policy->cur = freqs.new;
+
+    return ret;
+}
+
+static int
+hwdom_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+    struct processor_performance *perf;
+    struct hwdom_cpufreq_data *data;
+    unsigned int cpu = policy->cpu;
+    unsigned int valid_states = 0;
+    int i;
+    int ret = 0;
+
+    data = xzalloc(struct hwdom_cpufreq_data);
+    if ( !data )
+        return -ENOMEM;
+
+    hwdom_cpufreq_drv_data[cpu] = data;
+
+    data->perf_data = &processor_pminfo[cpu]->perf;
+
+    perf = data->perf_data;
+    policy->shared_type = perf->shared_type;
+
+    data->freq_table = xmalloc_array(struct cpufreq_frequency_table,
+                                     (perf->state_count+1));
+    if ( !data->freq_table )
+    {
+        ret = -ENOMEM;
+        goto err_unreg;
+    }
+
+    /* detect transition latency */
+    policy->cpuinfo.transition_latency = 0;
+    for ( i = 0; i < perf->state_count; i++ )
+    {
+        if ( (perf->states[i].transition_latency * 1000) >
+             policy->cpuinfo.transition_latency )
+            policy->cpuinfo.transition_latency =
+                perf->states[i].transition_latency * 1000;
+    }
+
+    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
+
+    /* table init */
+    for ( i = 0; i < perf->state_count; i++ )
+    {
+        if ( i > 0 && perf->states[i].core_frequency >=
+            data->freq_table[valid_states-1].frequency / 1000 )
+            continue;
+
+        data->freq_table[valid_states].index = i;
+        data->freq_table[valid_states].frequency =
+            perf->states[i].core_frequency * 1000;
+        valid_states++;
+    }
+    data->freq_table[valid_states].frequency = CPUFREQ_TABLE_END;
+    perf->state = 0;
+
+    ret = cpufreq_frequency_table_cpuinfo(policy, data->freq_table);
+    if ( ret )
+        goto err_freqfree;
+
+
+    /*
+     * the first call to ->target() should result in us actually
+     * send command to the Hardware domain to set frequency.
+     */
+    policy->resume = 1;
+
+    /* Set the minimal frequency */
+    return hwdom_cpufreq_target(policy, policy->min, CPUFREQ_RELATION_L);
+
+ err_freqfree:
+    xfree(data->freq_table);
+ err_unreg:
+    xfree(data);
+    hwdom_cpufreq_drv_data[cpu] = NULL;
+
+    return ret;
+}
+
+static int hwdom_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+{
+    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
+
+    if ( data )
+    {
+        hwdom_cpufreq_drv_data[policy->cpu] = NULL;
+        xfree(data->freq_table);
+        xfree(data);
+    }
+
+    return 0;
+}
+
+static struct cpufreq_driver hwdom_cpufreq_driver = {
+    .name   = "hwdom-cpufreq",
+    .verify = hwdom_cpufreq_verify,
+    .target = hwdom_cpufreq_target,
+    .init   = hwdom_cpufreq_cpu_init,
+    .exit   = hwdom_cpufreq_cpu_exit,
+};
+
+static int __init hwdom_cpufreq_driver_init(void)
+{
+    int ret = 0;
+
+    if ( cpufreq_controller == FREQCTL_xen )
+        ret = cpufreq_register_driver(&hwdom_cpufreq_driver);
+
+    return ret;
+}
+
+__initcall(hwdom_cpufreq_driver_init);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 8c5697e..abd8438 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -160,6 +160,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #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       */
+#define VIRQ_CPUFREQ    14 /* G. (DOM0) Notify cpufreq driver                */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldrK-0004rq-1t; Tue, 04 Nov 2014 13:09:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XldrI-0004px-BV
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D3/0B-09936-BFFC8545; Tue, 04 Nov 2014 13:09:15 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415106552!12654576!1
X-Originating-IP: [64.18.0.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20517 invoked from network); 4 Nov 2014 13:09:14 -0000
Received: from exprod5og126.obsmtp.com (HELO exprod5og126.obsmtp.com)
	(64.18.0.251)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:14 -0000
Received: from mail-lb0-f181.google.com ([209.85.217.181]) (using TLSv1) by
	exprod5ob126.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP9zoLdM5fec8S+h5mUKe8lVlfY9sp@postini.com;
	Tue, 04 Nov 2014 05:09:13 PST
Received: by mail-lb0-f181.google.com with SMTP id l4so4301948lbv.40
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=pH0+jMJciF8fjmEVLqUyuQJ/ElsqmExrY040KyWJg0k=;
	b=PvjBTcQ6JZtPEob4pWw2yIYzlx1Uu+53bFNAIPF9i5ZgErGkjNIhQWUQIWmIeik1Nf
	DQ+oti+4MKHAxk9P3oTGSL3yAzVmOrNExZrYbrSOWUJdRQC9EfBVnPrjFR9NQ5sdF8tO
	tqRfZ914FnKT2QQ70ssMD2174b9v6rK6Z4H+s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=pH0+jMJciF8fjmEVLqUyuQJ/ElsqmExrY040KyWJg0k=;
	b=d/KkPFXLfEXdB0Bio7q12NRf57Od7MNLfqcAvEt+uuE3O2SAzFOdb9ZhI7pP6acQnK
	AnKV8pH/JRbhA652wfjTYEA/2D4DrPIBWiQcItLyU90vVkrbBHBgK6rueBwwgYsWSuX6
	XBbwBY/K+zj/Pqx97vP5UgbA2TQSvBIZHBeJmH763i3e2RqzbnG+/NxJ1jZNLdAM6hBG
	f1rJjUSa+LcOtuKJ1HbXrqwr9xe5n/flyrxRToSAQGyFijlNHkrIkmmCTlL/xbPKZ/Jx
	CmhU62e0rGRb1rj3rdEEfU16WY2nqXRgPgOKIVizr7vhF3EInk6juoJ4rfqQYok/u5Hq
	v3bA==
X-Gm-Message-State: ALoCoQmcBq8lkKDPvYt6ipPJUNvov6h/hytbAvNz4cdoqb1Ej5308+tn82aXt/jGZ+lzIe1wXblWSnSRBQ2XetSrtEQcgN0KmhBU0d1tQt0p+kYzpaLcEMfWfqGL7N9NVNfWPWnhHgEGNfDHKEcEd74wmKGVVUx+Xw==
X-Received: by 10.112.199.40 with SMTP id jh8mr53489498lbc.5.1415106550427;
	Tue, 04 Nov 2014 05:09:10 -0800 (PST)
X-Received: by 10.112.199.40 with SMTP id jh8mr53489481lbc.5.1415106550346;
	Tue, 04 Nov 2014 05:09:10 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id rb2sm153717lbb.17.2014.11.04.05.09.09
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:09 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:40 +0200
Message-Id: <1415106521-3115-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 10/11] cpufreq: add hwdom-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This driver uses hwdom to change frequencies on CPUs
Workflow:
 * cpufreq governor driver in Xen wants to change the
   frequency of the physical CPU
 * hwdom-cpufreq driver sets parameters in the shared
   memory
 * hwdom-cpufreq driver sends an VIRQ_CPUFREQ interrupt
   to notify the hardware domain
 * cpufreq driver in the hardware domain reads parameters
   from the shared memory, changes frequency and copies
   the result of the operation to the shared memory

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                        |   1 +
 xen/drivers/cpufreq/Makefile        |   1 +
 xen/drivers/cpufreq/hwdom-cpufreq.c | 252 ++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h            |   1 +
 4 files changed, 255 insertions(+)
 create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3b0b89b..cccbc72 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
+CFLAGS-$(HAS_HWDOM_CPUFREQ) += -DHAS_HWDOM_CPUFREQ
 CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
diff --git a/xen/drivers/cpufreq/Makefile b/xen/drivers/cpufreq/Makefile
index b87d127..891997c 100644
--- a/xen/drivers/cpufreq/Makefile
+++ b/xen/drivers/cpufreq/Makefile
@@ -2,3 +2,4 @@ obj-y += cpufreq.o
 obj-y += cpufreq_ondemand.o
 obj-y += cpufreq_misc_governors.o
 obj-y += utility.o
+obj-$(HAS_HWDOM_CPUFREQ) += hwdom-cpufreq.o
diff --git a/xen/drivers/cpufreq/hwdom-cpufreq.c b/xen/drivers/cpufreq/hwdom-cpufreq.c
new file mode 100644
index 0000000..a39fc6c
--- /dev/null
+++ b/xen/drivers/cpufreq/hwdom-cpufreq.c
@@ -0,0 +1,252 @@
+/*
+ *  Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
+ *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
+ *  Copyright (C) 2002 - 2004 Dominik Brodowski <linux@brodo.de>
+ *  Copyright (C) 2006        Denis Sadykov <denis.m.sadykov@intel.com>
+ *
+ *  Feb 2008 - Liu Jinsong <jinsong.liu@intel.com>
+ *      porting acpi-cpufreq.c from Linux 2.6.23 to Xen hypervisor
+ *
+ *  Copyright (C) 2014 GlobalLogic Inc.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <xen/types.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/event.h>
+#include <xen/irq.h>
+#include <xen/spinlock.h>
+#include <xen/cpufreq.h>
+#include <xen/err.h>
+#include <asm/shared.h>
+#include <asm/current.h>
+#include <asm/system.h>
+
+struct hwdom_cpufreq_data {
+    struct processor_performance *perf_data;
+    struct cpufreq_frequency_table *freq_table;
+};
+
+static struct hwdom_cpufreq_data *hwdom_cpufreq_drv_data[NR_CPUS];
+
+int cpufreq_cpu_init(unsigned int cpuid)
+{
+    return cpufreq_add_cpu(cpuid);
+}
+
+static void notify_cpufreq_domain(void)
+{
+    send_global_virq(VIRQ_CPUFREQ);
+}
+
+static int hwdom_cpufreq_verify(struct cpufreq_policy *policy)
+{
+    struct hwdom_cpufreq_data *data;
+    struct processor_performance *perf;
+
+    if ( !policy || !(data = hwdom_cpufreq_drv_data[policy->cpu]) ||
+         !processor_pminfo[policy->cpu] )
+        return -EINVAL;
+
+    perf = &processor_pminfo[policy->cpu]->perf;
+
+    cpufreq_verify_within_limits(policy, 0,
+        perf->states[perf->platform_limit].core_frequency * 1000);
+
+    return cpufreq_frequency_table_verify(policy, data->freq_table);
+}
+
+static int hwdom_cpufreq_target(struct cpufreq_policy *policy,
+                               unsigned int target_freq, unsigned int relation)
+{
+    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
+    struct processor_performance *perf;
+    struct cpufreq_freqs freqs;
+    struct cpufreq_sh_info *cpufreq_info;
+    cpumask_t online_policy_cpus;
+    unsigned int next_state = 0; /* Index into freq_table */
+    unsigned int next_perf_state = 0; /* Index into perf table */
+    unsigned int j;
+    int ret = 0;
+
+    if ( unlikely(data == NULL ||
+         data->perf_data == NULL || data->freq_table == NULL) )
+        return -ENODEV;
+
+    perf = data->perf_data;
+    ret = cpufreq_frequency_table_target(policy,
+                                         data->freq_table,
+                                         target_freq,
+                                         relation, &next_state);
+    if ( unlikely(ret) )
+        return -ENODEV;
+
+    cpumask_and(&online_policy_cpus, &cpu_online_map, policy->cpus);
+
+    next_perf_state = data->freq_table[next_state].index;
+    if ( perf->state == next_perf_state )
+    {
+        if ( unlikely(policy->resume) )
+            policy->resume = 0;
+        else
+            return 0;
+    }
+
+    freqs.old = perf->states[perf->state].core_frequency * 1000;
+    freqs.new = data->freq_table[next_state].frequency;
+
+     /* Do send cmd for Hardware domain */
+    cpufreq_info = arch_get_cpufreq_addr(dom0);
+
+    /* Set previous result in the Hardware domain then read it */
+    smp_rmb();
+
+     /* return previous result */
+    ret = cpufreq_info->result;
+
+    cpufreq_info->cpu = policy->cpu;
+    cpufreq_info->freq = freqs.new;
+    cpufreq_info->relation = (uint32_t)relation;
+
+    smp_wmb(); /* above must be visible before notify_cpufreq_domain() */
+
+    notify_cpufreq_domain();
+
+    for_each_cpu( j, &online_policy_cpus )
+        cpufreq_statistic_update(j, perf->state, next_perf_state);
+
+    perf->state = next_perf_state;
+    policy->cur = freqs.new;
+
+    return ret;
+}
+
+static int
+hwdom_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+    struct processor_performance *perf;
+    struct hwdom_cpufreq_data *data;
+    unsigned int cpu = policy->cpu;
+    unsigned int valid_states = 0;
+    int i;
+    int ret = 0;
+
+    data = xzalloc(struct hwdom_cpufreq_data);
+    if ( !data )
+        return -ENOMEM;
+
+    hwdom_cpufreq_drv_data[cpu] = data;
+
+    data->perf_data = &processor_pminfo[cpu]->perf;
+
+    perf = data->perf_data;
+    policy->shared_type = perf->shared_type;
+
+    data->freq_table = xmalloc_array(struct cpufreq_frequency_table,
+                                     (perf->state_count+1));
+    if ( !data->freq_table )
+    {
+        ret = -ENOMEM;
+        goto err_unreg;
+    }
+
+    /* detect transition latency */
+    policy->cpuinfo.transition_latency = 0;
+    for ( i = 0; i < perf->state_count; i++ )
+    {
+        if ( (perf->states[i].transition_latency * 1000) >
+             policy->cpuinfo.transition_latency )
+            policy->cpuinfo.transition_latency =
+                perf->states[i].transition_latency * 1000;
+    }
+
+    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
+
+    /* table init */
+    for ( i = 0; i < perf->state_count; i++ )
+    {
+        if ( i > 0 && perf->states[i].core_frequency >=
+            data->freq_table[valid_states-1].frequency / 1000 )
+            continue;
+
+        data->freq_table[valid_states].index = i;
+        data->freq_table[valid_states].frequency =
+            perf->states[i].core_frequency * 1000;
+        valid_states++;
+    }
+    data->freq_table[valid_states].frequency = CPUFREQ_TABLE_END;
+    perf->state = 0;
+
+    ret = cpufreq_frequency_table_cpuinfo(policy, data->freq_table);
+    if ( ret )
+        goto err_freqfree;
+
+
+    /*
+     * the first call to ->target() should result in us actually
+     * send command to the Hardware domain to set frequency.
+     */
+    policy->resume = 1;
+
+    /* Set the minimal frequency */
+    return hwdom_cpufreq_target(policy, policy->min, CPUFREQ_RELATION_L);
+
+ err_freqfree:
+    xfree(data->freq_table);
+ err_unreg:
+    xfree(data);
+    hwdom_cpufreq_drv_data[cpu] = NULL;
+
+    return ret;
+}
+
+static int hwdom_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+{
+    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
+
+    if ( data )
+    {
+        hwdom_cpufreq_drv_data[policy->cpu] = NULL;
+        xfree(data->freq_table);
+        xfree(data);
+    }
+
+    return 0;
+}
+
+static struct cpufreq_driver hwdom_cpufreq_driver = {
+    .name   = "hwdom-cpufreq",
+    .verify = hwdom_cpufreq_verify,
+    .target = hwdom_cpufreq_target,
+    .init   = hwdom_cpufreq_cpu_init,
+    .exit   = hwdom_cpufreq_cpu_exit,
+};
+
+static int __init hwdom_cpufreq_driver_init(void)
+{
+    int ret = 0;
+
+    if ( cpufreq_controller == FREQCTL_xen )
+        ret = cpufreq_register_driver(&hwdom_cpufreq_driver);
+
+    return ret;
+}
+
+__initcall(hwdom_cpufreq_driver_init);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 8c5697e..abd8438 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -160,6 +160,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #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       */
+#define VIRQ_CPUFREQ    14 /* G. (DOM0) Notify cpufreq driver                */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldrL-0004tp-I2; Tue, 04 Nov 2014 13:09:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XldrK-0004rj-Em
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:18 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	05/EA-28296-DFFC8545; Tue, 04 Nov 2014 13:09:17 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415106554!11576886!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6157 invoked from network); 4 Nov 2014 13:09:16 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:16 -0000
Received: from mail-la0-f45.google.com ([209.85.215.45]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP+nlp6pEXzPeMETULnUDFQDJe008m@postini.com;
	Tue, 04 Nov 2014 05:09:16 PST
Received: by mail-la0-f45.google.com with SMTP id pn19so819468lab.32
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=yVYv1meKvPCY5NIU/Q6JtMaVTiuJj0WgDlvxj87tI2U=;
	b=NxP3i0iPlVesAassWQjf7ZSAopn6L5TtyT7HaclzWHA/s05y8pCHqXEguib0iRcs7k
	vrY6TaNKupFh3YtVsbTg5K2qnwrBGV9Qkfg8r/HrljUyjxjWbRVxS5vPlPHQvTMNWz5e
	1cHaL4cOBtYfv+nza3KeDk9E0hVj3b45dTssI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=yVYv1meKvPCY5NIU/Q6JtMaVTiuJj0WgDlvxj87tI2U=;
	b=T/4BPBPL4WBStzM0HJH4BpLcL5NM9gCv9IdRGy1wg/0/DjBMy+KzSgj+CTcFnQpeJF
	1t/82JXAliqUr2qHXBlPo6YIj4AebmkAXpRTLveUAUtQ5VpzzLQYHW5OQzkKEpHYEJUd
	7u3UlGo62PdZwmvGPUN24cqmDOtxAnzhNvRkwnkUdJudx7RaCqq4RBneWTHLYyqmhKQ9
	N7szDAIAK8+QyXsm8UYtkmQGkmN+zVG3TTF7cURicLQpiqUMtr7RmRq7S+maVPfVWctW
	ud0f8ueZecwOyOcnXOxqBSUOWp3+ASf7/HXHuqaCav5w3SzLsuR3GLvgcytXquLkVkwe
	gtig==
X-Gm-Message-State: ALoCoQkd8G+/8Zr984INWpu7GTgep+LC04PsNi4VNiV34UYYIR5jwVZ1jMQnjT6bwhPv51Mpuxpdudu99+9rCIM78QopQRFG1jkM+WHhVTejNvX1J612kjCJr2LUY9l8lh+Mw1PrmPGqtt0vkAngXET6V5no8DWfvg==
X-Received: by 10.152.216.167 with SMTP id or7mr20976893lac.93.1415106552983; 
	Tue, 04 Nov 2014 05:09:12 -0800 (PST)
X-Received: by 10.152.216.167 with SMTP id or7mr20976879lac.93.1415106552926; 
	Tue, 04 Nov 2014 05:09:12 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id ee6sm138365lad.45.2014.11.04.05.09.11
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:12 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:41 +0200
Message-Id: <1415106521-3115-12-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 11/11] xen/arm: enable cpufreq
	functionality for ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/Rules.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 718cd8a..1484b55 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -9,6 +9,9 @@
 HAS_DEVICE_TREE := y
 HAS_VIDEO := y
 HAS_ARM_HDLCD := y
+HAS_CPUFREQ := y
+HAS_HWDOM_CPUFREQ := y
+HAS_PM := y
 
 CFLAGS += -I$(BASEDIR)/include
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XldrL-0004tp-I2; Tue, 04 Nov 2014 13:09:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XldrK-0004rj-Em
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:18 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	05/EA-28296-DFFC8545; Tue, 04 Nov 2014 13:09:17 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415106554!11576886!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6157 invoked from network); 4 Nov 2014 13:09:16 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:16 -0000
Received: from mail-la0-f45.google.com ([209.85.215.45]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjP+nlp6pEXzPeMETULnUDFQDJe008m@postini.com;
	Tue, 04 Nov 2014 05:09:16 PST
Received: by mail-la0-f45.google.com with SMTP id pn19so819468lab.32
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=yVYv1meKvPCY5NIU/Q6JtMaVTiuJj0WgDlvxj87tI2U=;
	b=NxP3i0iPlVesAassWQjf7ZSAopn6L5TtyT7HaclzWHA/s05y8pCHqXEguib0iRcs7k
	vrY6TaNKupFh3YtVsbTg5K2qnwrBGV9Qkfg8r/HrljUyjxjWbRVxS5vPlPHQvTMNWz5e
	1cHaL4cOBtYfv+nza3KeDk9E0hVj3b45dTssI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=yVYv1meKvPCY5NIU/Q6JtMaVTiuJj0WgDlvxj87tI2U=;
	b=T/4BPBPL4WBStzM0HJH4BpLcL5NM9gCv9IdRGy1wg/0/DjBMy+KzSgj+CTcFnQpeJF
	1t/82JXAliqUr2qHXBlPo6YIj4AebmkAXpRTLveUAUtQ5VpzzLQYHW5OQzkKEpHYEJUd
	7u3UlGo62PdZwmvGPUN24cqmDOtxAnzhNvRkwnkUdJudx7RaCqq4RBneWTHLYyqmhKQ9
	N7szDAIAK8+QyXsm8UYtkmQGkmN+zVG3TTF7cURicLQpiqUMtr7RmRq7S+maVPfVWctW
	ud0f8ueZecwOyOcnXOxqBSUOWp3+ASf7/HXHuqaCav5w3SzLsuR3GLvgcytXquLkVkwe
	gtig==
X-Gm-Message-State: ALoCoQkd8G+/8Zr984INWpu7GTgep+LC04PsNi4VNiV34UYYIR5jwVZ1jMQnjT6bwhPv51Mpuxpdudu99+9rCIM78QopQRFG1jkM+WHhVTejNvX1J612kjCJr2LUY9l8lh+Mw1PrmPGqtt0vkAngXET6V5no8DWfvg==
X-Received: by 10.152.216.167 with SMTP id or7mr20976893lac.93.1415106552983; 
	Tue, 04 Nov 2014 05:09:12 -0800 (PST)
X-Received: by 10.152.216.167 with SMTP id or7mr20976879lac.93.1415106552926; 
	Tue, 04 Nov 2014 05:09:12 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id ee6sm138365lad.45.2014.11.04.05.09.11
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:12 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:08:41 +0200
Message-Id: <1415106521-3115-12-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 11/11] xen/arm: enable cpufreq
	functionality for ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/Rules.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 718cd8a..1484b55 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -9,6 +9,9 @@
 HAS_DEVICE_TREE := y
 HAS_VIDEO := y
 HAS_ARM_HDLCD := y
+HAS_CPUFREQ := y
+HAS_HWDOM_CPUFREQ := y
+HAS_PM := y
 
 CFLAGS += -I$(BASEDIR)/include
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldri-0005Cv-Ab; Tue, 04 Nov 2014 13:09:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldrg-0005BW-Qt
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:41 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	13/38-25714-410D8545; Tue, 04 Nov 2014 13:09:40 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415106577!11097026!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29495 invoked from network); 4 Nov 2014 13:09:39 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:39 -0000
Received: from mail-lb0-f179.google.com ([209.85.217.179]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQEEWioaZAf6NSWb6C9sbtUFWlPgSZ@postini.com;
	Tue, 04 Nov 2014 05:09:38 PST
Received: by mail-lb0-f179.google.com with SMTP id l4so4390060lbv.10
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id;
	bh=AM69TpO3lrFhXEmyecC20NaWp/IBbxGKapBPSsjIFC4=;
	b=hMEmorGF23AuCEzOHlyynpq6WCSlI7YAJPXSXtWwRBgPenYfGYS6lkWqaZiZLIdkXC
	xbyrppBZJRcN9ii0VQUHA6eP2y6R0ao4iH6AVfsj6/HAI2lL9xGEF8ooB6uoqvuVsVio
	HA/j43UE7C4TrLhWLRAXY/H9ILFaSMQW88zlA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=AM69TpO3lrFhXEmyecC20NaWp/IBbxGKapBPSsjIFC4=;
	b=Ng7h058LsLye2+Ap/bvqOZZiLNZdMiX0LHoDHrWywXjKKyEi74MevoD7cdRdz7VzuQ
	klOgMhVvKbogYMF+VlTh26j6TC8euxpq8VPEdBTk+rTmONyewhxNFYpuztFNPb/RZgAO
	5t5HzVVc99vG2Nk8hKYFEo+2xpZkXPQZLKVdySuabkyUjK9MU38Xn56f5YUU6fv7OKED
	xqsb8/dF6AzEvulSq72TbSghXU0vA/0xInTShdN/VZmr7epVDeIYmTBQLbeUgXjSlc+H
	YFjhcn5jBGkRkl6u6jUCboEgFnMOzOcfkCS+jkEj7T26A13U6Osvb+ZHuqpLtwVyPVi9
	qIhA==
X-Received: by 10.152.23.3 with SMTP id i3mr59801088laf.53.1415106575211;
	Tue, 04 Nov 2014 05:09:35 -0800 (PST)
X-Gm-Message-State: ALoCoQm2Wssz0G1VMOz408k4ilq9JvIHrCgdHDtSabxcM6zbyWVZ9QJghuMcnfm4UroXWx5JRPexirKQrPp6aZWLbrwzdW1Rubzu7QpGfIwd4EkNG0FPtgpNMMWo9TENpKkStpv4YHNp4PRy5CR04V5faAYf6sZDMA==
X-Received: by 10.152.23.3 with SMTP id i3mr59801076laf.53.1415106575137;
	Tue, 04 Nov 2014 05:09:35 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id f6sm157232lbh.10.2014.11.04.05.09.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:34 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:23 +0200
Message-Id: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 0/9] xen_cpufreq implementation in kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi to all.

Next series of patches implements xen-cpufreq driver in kernel.

Cpufreq core and registered cpufreq governors are located in xen. Dom0 has CPU
driver which can only change frequency of the physical CPUs. In addition this
driver can change CPUs regulator voltage. At start time xen-cpufreq driver
in kernel uploads to Xen information about physical cpus.
Xen notifies Dom0 kernel using VIRQ_CPUFREQ interrupt. Then xen-cpufreq driver
in kernel uses XEN_SYSCTL_cpufreq_op operation from HYPERVISOR_sysctl hypercall
to get some parameters from Xen (frequency, relation and cpu number).
Then xen-cpufreq changes frequency on physical cpu and uses the same
XEN_SYSCTL_cpufreq_op operation ti give the result to Xen.

Next configs should be enabled to use xen-cpufreq driver:
CONFIG_GENERIC_CPUFREQ_CPU0
CONFIG_XEN_CPUFREQ

Changed since v1:
 * added cpufreq_drv_ops which allows to use more than one high-level
   cpufreq driver
 * reworked xen-cpufreq and drivers so the same kernel is able to run
   on bare metal and within Xen.

Changed since v2:
 * used VIRQ_CPUFREQ with number 14 instead of the 13
 * slightly reworked xen-cpufreq driver

Changed since v3:
 * documented /hypervisor/pcpus/ node
 * added cpufreq shared info definition to receive commands from the
   Xen cpufreq driver
 * config CONFIG_CPUMASK_OFFSTACK now is checked in the Kconfig

Oleksandr Dmytryshyn (9):
  PM / OPP: make cpufreq functions dependent on CONFIG_CPU_FREQ_TABLE
  xen/arm: implement HYPERVISOR_sysctl
  xen/arm: implement HYPERVISOR_dom0_op
  docs: Xen ARM DT bindings: document pcpus property
  cpufreq: cpufreq-cpu0: change cpus data path in devtree for hwdom
    kernel
  cpufreq: introduce cpufreq_drv_ops
  cpufreq: make cpufreq low-level drivers visible for CPUFREQ_DRV_OPS
    config
  xen: arm: add cpufreq shared info definition
  xen/arm: cpufreq: add xen-cpufreq driver

 Documentation/devicetree/bindings/arm/xen.txt |  20 +-
 arch/arm/include/asm/xen/hypercall.h          |   2 +
 arch/arm/include/asm/xen/interface.h          |  13 +-
 arch/arm/xen/enlighten.c                      |   2 +
 arch/arm/xen/hypercall.S                      |   2 +
 drivers/Makefile                              |   2 +-
 drivers/base/power/opp.c                      |   4 +-
 drivers/cpufreq/Kconfig                       |  40 +-
 drivers/cpufreq/Makefile                      |   2 +
 drivers/cpufreq/acpi-cpufreq.c                |   5 +-
 drivers/cpufreq/cpufreq-cpu0.c                |  10 +-
 drivers/cpufreq/cpufreq.c                     | 116 ++--
 drivers/cpufreq/cpufreq_drv_ops.c             | 196 ++++++
 drivers/cpufreq/cpufreq_drv_ops.h             |  54 ++
 drivers/cpufreq/cpufreq_governor.c            |   4 +-
 drivers/cpufreq/xen-cpufreq.c                 | 869 ++++++++++++++++++++++++++
 include/linux/cpufreq.h                       |   2 +-
 include/linux/opp.h                           |   2 +-
 include/xen/interface/platform.h              |   1 +
 include/xen/interface/sysctl.h                | 646 +++++++++++++++++++
 include/xen/interface/xen.h                   |   7 +
 21 files changed, 1931 insertions(+), 68 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h
 create mode 100644 drivers/cpufreq/xen-cpufreq.c
 create mode 100644 include/xen/interface/sysctl.h

-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldri-0005Cv-Ab; Tue, 04 Nov 2014 13:09:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldrg-0005BW-Qt
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:41 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	13/38-25714-410D8545; Tue, 04 Nov 2014 13:09:40 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415106577!11097026!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29495 invoked from network); 4 Nov 2014 13:09:39 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:39 -0000
Received: from mail-lb0-f179.google.com ([209.85.217.179]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQEEWioaZAf6NSWb6C9sbtUFWlPgSZ@postini.com;
	Tue, 04 Nov 2014 05:09:38 PST
Received: by mail-lb0-f179.google.com with SMTP id l4so4390060lbv.10
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id;
	bh=AM69TpO3lrFhXEmyecC20NaWp/IBbxGKapBPSsjIFC4=;
	b=hMEmorGF23AuCEzOHlyynpq6WCSlI7YAJPXSXtWwRBgPenYfGYS6lkWqaZiZLIdkXC
	xbyrppBZJRcN9ii0VQUHA6eP2y6R0ao4iH6AVfsj6/HAI2lL9xGEF8ooB6uoqvuVsVio
	HA/j43UE7C4TrLhWLRAXY/H9ILFaSMQW88zlA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=AM69TpO3lrFhXEmyecC20NaWp/IBbxGKapBPSsjIFC4=;
	b=Ng7h058LsLye2+Ap/bvqOZZiLNZdMiX0LHoDHrWywXjKKyEi74MevoD7cdRdz7VzuQ
	klOgMhVvKbogYMF+VlTh26j6TC8euxpq8VPEdBTk+rTmONyewhxNFYpuztFNPb/RZgAO
	5t5HzVVc99vG2Nk8hKYFEo+2xpZkXPQZLKVdySuabkyUjK9MU38Xn56f5YUU6fv7OKED
	xqsb8/dF6AzEvulSq72TbSghXU0vA/0xInTShdN/VZmr7epVDeIYmTBQLbeUgXjSlc+H
	YFjhcn5jBGkRkl6u6jUCboEgFnMOzOcfkCS+jkEj7T26A13U6Osvb+ZHuqpLtwVyPVi9
	qIhA==
X-Received: by 10.152.23.3 with SMTP id i3mr59801088laf.53.1415106575211;
	Tue, 04 Nov 2014 05:09:35 -0800 (PST)
X-Gm-Message-State: ALoCoQm2Wssz0G1VMOz408k4ilq9JvIHrCgdHDtSabxcM6zbyWVZ9QJghuMcnfm4UroXWx5JRPexirKQrPp6aZWLbrwzdW1Rubzu7QpGfIwd4EkNG0FPtgpNMMWo9TENpKkStpv4YHNp4PRy5CR04V5faAYf6sZDMA==
X-Received: by 10.152.23.3 with SMTP id i3mr59801076laf.53.1415106575137;
	Tue, 04 Nov 2014 05:09:35 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id f6sm157232lbh.10.2014.11.04.05.09.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:34 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:23 +0200
Message-Id: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 0/9] xen_cpufreq implementation in kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi to all.

Next series of patches implements xen-cpufreq driver in kernel.

Cpufreq core and registered cpufreq governors are located in xen. Dom0 has CPU
driver which can only change frequency of the physical CPUs. In addition this
driver can change CPUs regulator voltage. At start time xen-cpufreq driver
in kernel uploads to Xen information about physical cpus.
Xen notifies Dom0 kernel using VIRQ_CPUFREQ interrupt. Then xen-cpufreq driver
in kernel uses XEN_SYSCTL_cpufreq_op operation from HYPERVISOR_sysctl hypercall
to get some parameters from Xen (frequency, relation and cpu number).
Then xen-cpufreq changes frequency on physical cpu and uses the same
XEN_SYSCTL_cpufreq_op operation ti give the result to Xen.

Next configs should be enabled to use xen-cpufreq driver:
CONFIG_GENERIC_CPUFREQ_CPU0
CONFIG_XEN_CPUFREQ

Changed since v1:
 * added cpufreq_drv_ops which allows to use more than one high-level
   cpufreq driver
 * reworked xen-cpufreq and drivers so the same kernel is able to run
   on bare metal and within Xen.

Changed since v2:
 * used VIRQ_CPUFREQ with number 14 instead of the 13
 * slightly reworked xen-cpufreq driver

Changed since v3:
 * documented /hypervisor/pcpus/ node
 * added cpufreq shared info definition to receive commands from the
   Xen cpufreq driver
 * config CONFIG_CPUMASK_OFFSTACK now is checked in the Kconfig

Oleksandr Dmytryshyn (9):
  PM / OPP: make cpufreq functions dependent on CONFIG_CPU_FREQ_TABLE
  xen/arm: implement HYPERVISOR_sysctl
  xen/arm: implement HYPERVISOR_dom0_op
  docs: Xen ARM DT bindings: document pcpus property
  cpufreq: cpufreq-cpu0: change cpus data path in devtree for hwdom
    kernel
  cpufreq: introduce cpufreq_drv_ops
  cpufreq: make cpufreq low-level drivers visible for CPUFREQ_DRV_OPS
    config
  xen: arm: add cpufreq shared info definition
  xen/arm: cpufreq: add xen-cpufreq driver

 Documentation/devicetree/bindings/arm/xen.txt |  20 +-
 arch/arm/include/asm/xen/hypercall.h          |   2 +
 arch/arm/include/asm/xen/interface.h          |  13 +-
 arch/arm/xen/enlighten.c                      |   2 +
 arch/arm/xen/hypercall.S                      |   2 +
 drivers/Makefile                              |   2 +-
 drivers/base/power/opp.c                      |   4 +-
 drivers/cpufreq/Kconfig                       |  40 +-
 drivers/cpufreq/Makefile                      |   2 +
 drivers/cpufreq/acpi-cpufreq.c                |   5 +-
 drivers/cpufreq/cpufreq-cpu0.c                |  10 +-
 drivers/cpufreq/cpufreq.c                     | 116 ++--
 drivers/cpufreq/cpufreq_drv_ops.c             | 196 ++++++
 drivers/cpufreq/cpufreq_drv_ops.h             |  54 ++
 drivers/cpufreq/cpufreq_governor.c            |   4 +-
 drivers/cpufreq/xen-cpufreq.c                 | 869 ++++++++++++++++++++++++++
 include/linux/cpufreq.h                       |   2 +-
 include/linux/opp.h                           |   2 +-
 include/xen/interface/platform.h              |   1 +
 include/xen/interface/sysctl.h                | 646 +++++++++++++++++++
 include/xen/interface/xen.h                   |   7 +
 21 files changed, 1931 insertions(+), 68 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h
 create mode 100644 drivers/cpufreq/xen-cpufreq.c
 create mode 100644 include/xen/interface/sysctl.h

-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldrl-0005G5-OQ; Tue, 04 Nov 2014 13:09:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldrl-0005FJ-7k
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:45 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	E4/5F-27785-810D8545; Tue, 04 Nov 2014 13:09:44 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415106580!12463141!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18536 invoked from network); 4 Nov 2014 13:09:41 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:41 -0000
Received: from mail-la0-f53.google.com ([209.85.215.53]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQE6ygV0krS/ypyOzdNLrOIvdtNt0D@postini.com;
	Tue, 04 Nov 2014 05:09:41 PST
Received: by mail-la0-f53.google.com with SMTP id mc6so801805lab.40
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=Tn9M0rWmNjsmwYZUdRC0mijqbiyYFAXMgaxiSTg3FH0=;
	b=WwATScQ1Cw9wn+iWofBzSuODraf8wAUcFFbSntZBV+HVKp0U78//d5ReCQh7PhxCSa
	YTJoy+xPrYvCaFJMX++NWERdDcuREyTpqY+eQsF+dqU7CxtMSC2VQW1ojCL4vEaHoZ0s
	4SD+SHEyGsJGl+yM5sOEDlUMF+fh5y8idf9gU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=Tn9M0rWmNjsmwYZUdRC0mijqbiyYFAXMgaxiSTg3FH0=;
	b=QfBHMehcUpUQ6fedPTC7ZixhHPSwtbOT5Vd/HgDo/GQRyLk/TpjTGKNkWUeeHX7JHQ
	YYqavJEwPrURPMATmaPmbqHOvs6+FB480VijqCVOg3YvHdxX7Bj0TxtCQzZxZ7lfK8ai
	yjcAnqTVFnFex7DyZBYQo4bOGIEXK/hSkVron35ZvxVRqvktEr7eDBzRZYnKp/RL87pD
	ur/7P2jQxzAp7Ld/ODm/gEBAQ4k4lvqNMiQ2jnz3fYniKc/wD3/p/hFISF3XkFBkqYbV
	+r9uhKLl7LpFUPIMdvi9UAyJ0WcsACbhfpIib258zUmxR0Bk4nZ6QnID48b/nFE7l83/
	z5Ug==
X-Gm-Message-State: ALoCoQlRkPGpxCH8SzKCklkNU5G1ndq42nO2VxMQwAkGc3lI83byrwxidioYr+/1FEQPOezctg3wmIn7xdtN46tI93mGazbTRCYVsHSwjCN1qZvbW2XXZ6e+5QscVfuPA0ZNBV+IIyD6sxBKkPpzVWV2QdZ9OTOBmQ==
X-Received: by 10.112.142.33 with SMTP id rt1mr59003419lbb.85.1415106578350;
	Tue, 04 Nov 2014 05:09:38 -0800 (PST)
X-Received: by 10.112.142.33 with SMTP id rt1mr59003403lbb.85.1415106578282;
	Tue, 04 Nov 2014 05:09:38 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id 3sm157926lay.8.2014.11.04.05.09.36
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:37 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:24 +0200
Message-Id: <1415106572-3178-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 1/9] PM / OPP: make cpufreq functions
	dependent on CONFIG_CPU_FREQ_TABLE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Those functions should be dependent on CONFIG_CPU_FREQ_TABLE
instead of the CONFIG_CPU_FREQ.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/base/power/opp.c | 4 ++--
 include/linux/opp.h      | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 32ee0fc..17c5bc5 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -592,7 +592,7 @@ int opp_disable(struct device *dev, unsigned long freq)
 }
 EXPORT_SYMBOL_GPL(opp_disable);
 
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_CPU_FREQ_TABLE
 /**
  * opp_init_cpufreq_table() - create a cpufreq table for a device
  * @dev:	device for which we do this operation
@@ -680,7 +680,7 @@ void opp_free_cpufreq_table(struct device *dev,
 	*table = NULL;
 }
 EXPORT_SYMBOL_GPL(opp_free_cpufreq_table);
-#endif		/* CONFIG_CPU_FREQ */
+#endif		/* CONFIG_CPU_FREQ_TABLE */
 
 /**
  * opp_get_notifier() - find notifier_head of the device with opp
diff --git a/include/linux/opp.h b/include/linux/opp.h
index 214e0ebc..35c98f3 100644
--- a/include/linux/opp.h
+++ b/include/linux/opp.h
@@ -112,7 +112,7 @@ static inline struct srcu_notifier_head *opp_get_notifier(struct device *dev)
 }
 #endif		/* CONFIG_PM_OPP */
 
-#if defined(CONFIG_CPU_FREQ) && defined(CONFIG_PM_OPP)
+#if defined(CONFIG_CPU_FREQ_TABLE) && defined(CONFIG_PM_OPP)
 int opp_init_cpufreq_table(struct device *dev,
 			    struct cpufreq_frequency_table **table);
 void opp_free_cpufreq_table(struct device *dev,
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldrl-0005G5-OQ; Tue, 04 Nov 2014 13:09:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldrl-0005FJ-7k
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:45 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	E4/5F-27785-810D8545; Tue, 04 Nov 2014 13:09:44 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415106580!12463141!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18536 invoked from network); 4 Nov 2014 13:09:41 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:41 -0000
Received: from mail-la0-f53.google.com ([209.85.215.53]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQE6ygV0krS/ypyOzdNLrOIvdtNt0D@postini.com;
	Tue, 04 Nov 2014 05:09:41 PST
Received: by mail-la0-f53.google.com with SMTP id mc6so801805lab.40
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=Tn9M0rWmNjsmwYZUdRC0mijqbiyYFAXMgaxiSTg3FH0=;
	b=WwATScQ1Cw9wn+iWofBzSuODraf8wAUcFFbSntZBV+HVKp0U78//d5ReCQh7PhxCSa
	YTJoy+xPrYvCaFJMX++NWERdDcuREyTpqY+eQsF+dqU7CxtMSC2VQW1ojCL4vEaHoZ0s
	4SD+SHEyGsJGl+yM5sOEDlUMF+fh5y8idf9gU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=Tn9M0rWmNjsmwYZUdRC0mijqbiyYFAXMgaxiSTg3FH0=;
	b=QfBHMehcUpUQ6fedPTC7ZixhHPSwtbOT5Vd/HgDo/GQRyLk/TpjTGKNkWUeeHX7JHQ
	YYqavJEwPrURPMATmaPmbqHOvs6+FB480VijqCVOg3YvHdxX7Bj0TxtCQzZxZ7lfK8ai
	yjcAnqTVFnFex7DyZBYQo4bOGIEXK/hSkVron35ZvxVRqvktEr7eDBzRZYnKp/RL87pD
	ur/7P2jQxzAp7Ld/ODm/gEBAQ4k4lvqNMiQ2jnz3fYniKc/wD3/p/hFISF3XkFBkqYbV
	+r9uhKLl7LpFUPIMdvi9UAyJ0WcsACbhfpIib258zUmxR0Bk4nZ6QnID48b/nFE7l83/
	z5Ug==
X-Gm-Message-State: ALoCoQlRkPGpxCH8SzKCklkNU5G1ndq42nO2VxMQwAkGc3lI83byrwxidioYr+/1FEQPOezctg3wmIn7xdtN46tI93mGazbTRCYVsHSwjCN1qZvbW2XXZ6e+5QscVfuPA0ZNBV+IIyD6sxBKkPpzVWV2QdZ9OTOBmQ==
X-Received: by 10.112.142.33 with SMTP id rt1mr59003419lbb.85.1415106578350;
	Tue, 04 Nov 2014 05:09:38 -0800 (PST)
X-Received: by 10.112.142.33 with SMTP id rt1mr59003403lbb.85.1415106578282;
	Tue, 04 Nov 2014 05:09:38 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id 3sm157926lay.8.2014.11.04.05.09.36
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:37 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:24 +0200
Message-Id: <1415106572-3178-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 1/9] PM / OPP: make cpufreq functions
	dependent on CONFIG_CPU_FREQ_TABLE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Those functions should be dependent on CONFIG_CPU_FREQ_TABLE
instead of the CONFIG_CPU_FREQ.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/base/power/opp.c | 4 ++--
 include/linux/opp.h      | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 32ee0fc..17c5bc5 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -592,7 +592,7 @@ int opp_disable(struct device *dev, unsigned long freq)
 }
 EXPORT_SYMBOL_GPL(opp_disable);
 
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_CPU_FREQ_TABLE
 /**
  * opp_init_cpufreq_table() - create a cpufreq table for a device
  * @dev:	device for which we do this operation
@@ -680,7 +680,7 @@ void opp_free_cpufreq_table(struct device *dev,
 	*table = NULL;
 }
 EXPORT_SYMBOL_GPL(opp_free_cpufreq_table);
-#endif		/* CONFIG_CPU_FREQ */
+#endif		/* CONFIG_CPU_FREQ_TABLE */
 
 /**
  * opp_get_notifier() - find notifier_head of the device with opp
diff --git a/include/linux/opp.h b/include/linux/opp.h
index 214e0ebc..35c98f3 100644
--- a/include/linux/opp.h
+++ b/include/linux/opp.h
@@ -112,7 +112,7 @@ static inline struct srcu_notifier_head *opp_get_notifier(struct device *dev)
 }
 #endif		/* CONFIG_PM_OPP */
 
-#if defined(CONFIG_CPU_FREQ) && defined(CONFIG_PM_OPP)
+#if defined(CONFIG_CPU_FREQ_TABLE) && defined(CONFIG_PM_OPP)
 int opp_init_cpufreq_table(struct device *dev,
 			    struct cpufreq_frequency_table **table);
 void opp_free_cpufreq_table(struct device *dev,
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldrq-0005Kk-BR; Tue, 04 Nov 2014 13:09:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldro-0005Is-Mz
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C6/61-09842-C10D8545; Tue, 04 Nov 2014 13:09:48 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415106582!12109881!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9618 invoked from network); 4 Nov 2014 13:09:45 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:45 -0000
Received: from mail-lb0-f172.google.com ([209.85.217.172]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQFuGxUeBXsczMQMlTUWtepdhzjMF2@postini.com;
	Tue, 04 Nov 2014 05:09:44 PST
Received: by mail-lb0-f172.google.com with SMTP id w7so3908883lbi.31
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=Bk1RVD6fijuQyhO/DHH9SfeA7X22ADDCyM4k1hNkoHM=;
	b=ga4Yy2BxKCx73X8/QgY2r+/+pdkDDTq8wACYDZF8eR3+ZamAWOXOSxHBiIoCgkZv1e
	JUXRJVKfs2E6gh5FlYgRpyUtgMX5ZLcTqA8hKme+o90BRRb26+3vX9gj0SEmjJTxbF66
	QGKZ5GsI4T8jBiLXls7JNrisJSUTINxWZdWT0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=Bk1RVD6fijuQyhO/DHH9SfeA7X22ADDCyM4k1hNkoHM=;
	b=WQYMBjwPKiUQ5IsCfVbjhaterWZpeMWhUIIZ7iG+AgyPMqdRkRBU0tLmRb+LxUj6wH
	Nven4ezpJjDdWEz5gclxvs2s3XYWtMMcdrlUGBBv/eqqWL1UxxBa/v/XHDPYnkdawyV9
	xROPe4s98Fy8FKh5i+B/BMNmNjvpW4udFQtsMkEKy5KglEqAfpfUhC2MFiAlNYEzfG3d
	BWW3znvE37fgXvS/BOO+jMOOpQjJUzMxCpFyq1e6VfKKgbeXCrBM8O0Up5Svwo7LeRkQ
	iUrLwuvYMyIrCLJL5DLmRbiVGf1XFm9GeFuDmi2GLRebRe0DzKnGLGrcEkY6M/Dyjp4o
	KBaQ==
X-Gm-Message-State: ALoCoQkTVPloL1pI0hxM1azuGzNjFrBrUmuDPDdCW7IFjSRvUe3hIrjhulJxCC3QF2ECFAb4imWqD2EZqsQeVLog+tC6X9QV/oq3dAD98hprualTaoN+9RpJEAb163NH3mqVevjrKtBpwI3pPATJQoNj3OU4KRa7Sw==
X-Received: by 10.152.27.38 with SMTP id q6mr21192967lag.92.1415106581105;
	Tue, 04 Nov 2014 05:09:41 -0800 (PST)
X-Received: by 10.152.27.38 with SMTP id q6mr21192953lag.92.1415106581019;
	Tue, 04 Nov 2014 05:09:41 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id l7sm148796lah.27.2014.11.04.05.09.39
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:40 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:25 +0200
Message-Id: <1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 arch/arm/include/asm/xen/hypercall.h |   1 +
 arch/arm/include/asm/xen/interface.h |   2 +
 arch/arm/xen/enlighten.c             |   1 +
 arch/arm/xen/hypercall.S             |   1 +
 include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
 include/xen/interface/xen.h          |   6 +
 6 files changed, 657 insertions(+)
 create mode 100644 include/xen/interface/sysctl.h

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index c817c56..751869eb 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_sysctl(void *arg);
 
 static inline void
 MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 1151188..acf4b7a 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -19,6 +19,7 @@
 	__DEFINE_GUEST_HANDLE(name, struct name)
 #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
 #define GUEST_HANDLE(name)        __guest_handle_ ## name
+#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
 
 #define set_xen_guest_handle(hnd, val)			\
 	do {						\
@@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(uint8_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 DEFINE_GUEST_HANDLE(xen_ulong_t);
 
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index eb0d851..675f17a 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index d1cf7b7..a1276df 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
+HYPERCALL1(sysctl);
 
 ENTRY(privcmd_call)
 	stmdb sp!, {r4}
diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
new file mode 100644
index 0000000..1a8cf7a
--- /dev/null
+++ b/include/xen/interface/sysctl.h
@@ -0,0 +1,646 @@
+/******************************************************************************
+ * sysctl.h
+ *
+ * System management operations. For use by node control stack.
+ *
+ * Reused from xen: xen/include/public/sysctl.h
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2002-2006, K Fraser
+ * Copyright (c) 2014, GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_SYSCTL_H__
+#define __XEN_PUBLIC_SYSCTL_H__
+
+#include <xen/interface/xen.h>
+
+#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
+
+/*
+ * Read console content from Xen buffer ring.
+ */
+/* XEN_SYSCTL_readconsole */
+struct xen_sysctl_readconsole {
+	/* IN: Non-zero -> clear after reading. */
+	uint8_t clear;
+	/* IN: Non-zero -> start index specified by @index field. */
+	uint8_t incremental;
+	uint8_t pad0, pad1;
+	/*
+	* IN:  Start index for consuming from ring buffer (if @incremental);
+	* OUT: End index after consuming from ring buffer.
+	*/
+	uint32_t index;
+	/* IN: Virtual address to write console data. */
+	GUEST_HANDLE_64(char) buffer;
+	/* IN: Size of buffer; OUT: Bytes written to buffer. */
+	uint32_t count;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
+
+/* Get trace buffers machine base address */
+/* XEN_SYSCTL_tbuf_op */
+struct xen_sysctl_tbuf_op {
+    /* IN variables */
+#define XEN_SYSCTL_TBUFOP_get_info     0
+#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
+#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
+#define XEN_SYSCTL_TBUFOP_set_size     3
+#define XEN_SYSCTL_TBUFOP_enable       4
+#define XEN_SYSCTL_TBUFOP_disable      5
+	uint32_t cmd;
+	/* IN/OUT variables */
+	struct xenctl_bitmap cpu_mask;
+	uint32_t             evt_mask;
+	/* OUT variables */
+	uint64_aligned_t buffer_mfn;
+	uint32_t size;  /* Also an IN variable! */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
+
+/*
+ * Get physical information about the host machine
+ */
+/* XEN_SYSCTL_physinfo */
+ /* (x86) The platform supports HVM guests. */
+#define _XEN_SYSCTL_PHYSCAP_hvm          0
+#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
+ /* (x86) The platform supports HVM-guest direct access to I/O devices. */
+#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
+#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
+struct xen_sysctl_physinfo {
+	uint32_t threads_per_core;
+	uint32_t cores_per_socket;
+	uint32_t nr_cpus;     /* # CPUs currently online */
+	uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
+	uint32_t nr_nodes;    /* # nodes currently online */
+	uint32_t max_node_id; /* Largest possible node ID on this host */
+	uint32_t cpu_khz;
+	uint64_aligned_t total_pages;
+	uint64_aligned_t free_pages;
+	uint64_aligned_t scrub_pages;
+	uint64_aligned_t outstanding_pages;
+	uint32_t hw_cap[8];
+
+	/* XEN_SYSCTL_PHYSCAP_??? */
+	uint32_t capabilities;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
+
+/*
+ * Get the ID of the current scheduler.
+ */
+/* XEN_SYSCTL_sched_id */
+struct xen_sysctl_sched_id {
+	/* OUT variable */
+	uint32_t sched_id;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
+
+/* Interface for controlling Xen software performance counters. */
+/* XEN_SYSCTL_perfc_op */
+/* Sub-operations: */
+#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
+#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
+struct xen_sysctl_perfc_desc {
+	char         name[80];           /* name of perf counter */
+	uint32_t     nr_vals;            /* number of values for this counter */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
+
+struct xen_sysctl_perfc_op {
+	/* IN variables. */
+	uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
+	/* OUT variables. */
+	uint32_t       nr_counters;       /*  number of counters description  */
+	uint32_t       nr_vals;           /*  number of values  */
+	/* counter information (or NULL) */
+	GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
+	/* counter values (or NULL) */
+	GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
+
+/* Inject debug keys into Xen. */
+/* XEN_SYSCTL_debug_keys */
+struct xen_sysctl_debug_keys {
+	/* IN variables. */
+	GUEST_HANDLE_64(char) keys;
+	uint32_t nr_keys;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
+
+/* Get physical CPU information. */
+/* XEN_SYSCTL_getcpuinfo */
+struct xen_sysctl_cpuinfo {
+	uint64_aligned_t idletime;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
+struct xen_sysctl_getcpuinfo {
+	/* IN variables. */
+	uint32_t max_cpus;
+	GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
+	/* OUT variables. */
+	uint32_t nr_cpus;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
+
+/* XEN_SYSCTL_availheap */
+struct xen_sysctl_availheap {
+	/* IN variables. */
+	uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
+	uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
+	int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
+	/* OUT variables. */
+	uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
+
+/* XEN_SYSCTL_get_pmstat */
+struct pm_px_val {
+	uint64_aligned_t freq;        /* Px core frequency */
+	uint64_aligned_t residency;   /* Px residency time */
+	uint64_aligned_t count;       /* Px transition count */
+};
+DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
+
+struct pm_px_stat {
+	uint8_t total;        /* total Px states */
+	uint8_t usable;       /* usable Px states */
+	uint8_t last;         /* last Px state */
+	uint8_t cur;          /* current Px state */
+	GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
+	GUEST_HANDLE_64(pm_px_val) pt;
+};
+DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
+
+struct pm_cx_stat {
+	uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
+	uint32_t last;  /* last Cx state */
+	uint64_aligned_t idle_time;                 /* idle time from boot */
+	GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
+	GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
+	uint64_aligned_t pc2;
+	uint64_aligned_t pc3;
+	uint64_aligned_t pc6;
+	uint64_aligned_t pc7;
+	uint64_aligned_t cc3;
+	uint64_aligned_t cc6;
+	uint64_aligned_t cc7;
+};
+
+struct xen_sysctl_get_pmstat {
+#define PMSTAT_CATEGORY_MASK 0xf0
+#define PMSTAT_PX            0x10
+#define PMSTAT_CX            0x20
+#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
+#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
+#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
+#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
+#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
+#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
+	uint32_t type;
+	uint32_t cpuid;
+	union {
+		struct pm_px_stat getpx;
+		struct pm_cx_stat getcx;
+		/* other struct for tx, etc */
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
+
+/* XEN_SYSCTL_cpu_hotplug */
+struct xen_sysctl_cpu_hotplug {
+	/* IN variables */
+	uint32_t cpu;   /* Physical cpu. */
+#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
+#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
+	uint32_t op;    /* hotplug opcode */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
+
+/*
+ * Get/set xen power management, include
+ * 1. cpufreq governors and related parameters
+ */
+/* XEN_SYSCTL_pm_op */
+struct xen_userspace {
+	uint32_t scaling_setspeed;
+};
+
+struct xen_ondemand {
+	uint32_t sampling_rate_max;
+	uint32_t sampling_rate_min;
+
+	uint32_t sampling_rate;
+	uint32_t up_threshold;
+};
+
+/*
+ * cpufreq para name of this structure named
+ * same as sysfs file name of native linux
+ */
+#define CPUFREQ_NAME_LEN 16
+struct xen_get_cpufreq_para {
+	/* IN/OUT variable */
+	uint32_t cpu_num;
+	uint32_t freq_num;
+	uint32_t gov_num;
+
+	/* for all governors */
+	/* OUT variable */
+	GUEST_HANDLE_64(uint32_t) affected_cpus;
+	GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
+	GUEST_HANDLE_64(char)   scaling_available_governors;
+	char scaling_driver[CPUFREQ_NAME_LEN];
+
+	uint32_t cpuinfo_cur_freq;
+	uint32_t cpuinfo_max_freq;
+	uint32_t cpuinfo_min_freq;
+	uint32_t scaling_cur_freq;
+
+	char scaling_governor[CPUFREQ_NAME_LEN];
+	uint32_t scaling_max_freq;
+	uint32_t scaling_min_freq;
+
+	/* for specific governor */
+	union {
+		struct  xen_userspace userspace;
+		struct  xen_ondemand ondemand;
+	} u;
+
+	int32_t turbo_enabled;
+};
+
+struct xen_set_cpufreq_gov {
+	char scaling_governor[CPUFREQ_NAME_LEN];
+};
+
+struct xen_set_cpufreq_para {
+	#define SCALING_MAX_FREQ           1
+	#define SCALING_MIN_FREQ           2
+	#define SCALING_SETSPEED           3
+	#define SAMPLING_RATE              4
+	#define UP_THRESHOLD               5
+
+	uint32_t ctrl_type;
+	uint32_t ctrl_value;
+};
+
+struct xen_sysctl_pm_op {
+	#define PM_PARA_CATEGORY_MASK      0xf0
+	#define CPUFREQ_PARA               0x10
+
+	/* cpufreq command type */
+	#define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
+	#define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
+	#define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
+	#define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
+
+	/* set/reset scheduler power saving option */
+	#define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
+
+	/* cpuidle max_cstate access command */
+	#define XEN_SYSCTL_pm_op_get_max_cstate       0x22
+	#define XEN_SYSCTL_pm_op_set_max_cstate       0x23
+
+	/* set scheduler migration cost value */
+	#define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
+	#define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
+
+	/* enable/disable turbo mode when in dbs governor */
+	#define XEN_SYSCTL_pm_op_enable_turbo               0x26
+	#define XEN_SYSCTL_pm_op_disable_turbo              0x27
+
+	uint32_t cmd;
+	uint32_t cpuid;
+	union {
+		struct xen_get_cpufreq_para get_para;
+		struct xen_set_cpufreq_gov  set_gov;
+		struct xen_set_cpufreq_para set_para;
+		uint64_aligned_t get_avgfreq;
+		uint32_t                    set_sched_opt_smt;
+		uint32_t                    get_max_cstate;
+		uint32_t                    set_max_cstate;
+		uint32_t                    get_vcpu_migration_delay;
+		uint32_t                    set_vcpu_migration_delay;
+	} u;
+};
+
+/* XEN_SYSCTL_page_offline_op */
+struct xen_sysctl_page_offline_op {
+	/* IN: range of page to be offlined */
+#define sysctl_page_offline     1
+#define sysctl_page_online      2
+#define sysctl_query_page_offline  3
+	uint32_t cmd;
+	uint32_t start;
+	uint32_t end;
+	/* OUT: result of page offline request */
+	/*
+	* bit 0~15: result flags
+	* bit 16~31: owner
+	*/
+	GUEST_HANDLE(uint32_t) status;
+};
+
+#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
+
+/* The result is invalid, i.e. HV does not handle it */
+#define PG_OFFLINE_INVALID   (0x1UL << 0)
+
+#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
+#define PG_OFFLINE_PENDING   (0x1UL << 2)
+#define PG_OFFLINE_FAILED    (0x1UL << 3)
+#define PG_OFFLINE_AGAIN     (0x1UL << 4)
+
+#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
+#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
+
+#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
+#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
+#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
+#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
+
+#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
+
+/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
+#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
+#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
+#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
+#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
+#define PG_OFFLINE_OWNED     (0x1UL << 12)
+
+#define PG_OFFLINE_BROKEN    (0x1UL << 13)
+#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
+
+#define PG_OFFLINE_OWNER_SHIFT 16
+
+/* XEN_SYSCTL_lockprof_op */
+/* Sub-operations: */
+#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
+#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
+/* Record-type: */
+#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
+#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
+#define LOCKPROF_TYPE_N           2   /* number of types */
+struct xen_sysctl_lockprof_data {
+	char     name[40];   /* lock name (may include up to 2 %d specifiers) */
+	int32_t  type;       /* LOCKPROF_TYPE_??? */
+	int32_t  idx;        /* index (e.g. domain id) */
+	uint64_aligned_t lock_cnt;     /* # of locking succeeded */
+	uint64_aligned_t block_cnt;    /* # of wait for lock */
+	uint64_aligned_t lock_time;    /* nsecs lock held */
+	uint64_aligned_t block_time;   /* nsecs waited for lock */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
+
+struct xen_sysctl_lockprof_op {
+	/* IN variables. */
+	uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
+	uint32_t       max_elem;          /* size of output buffer */
+	/* OUT variables (query only). */
+	uint32_t       nr_elem;           /* number of elements available */
+	uint64_aligned_t time;            /* nsecs of profile measurement */
+	/* profile information (or NULL) */
+	GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
+
+/* XEN_SYSCTL_topologyinfo */
+#define INVALID_TOPOLOGY_ID  (~0U)
+struct xen_sysctl_topologyinfo {
+	/*
+	 * IN: maximum addressable entry in the caller-provided arrays.
+	 * OUT: largest cpu identifier in the system.
+	 * If OUT is greater than IN then the arrays are truncated!
+	 * If OUT is leass than IN then the array tails are not written by
+	 * sysctl.
+	 */
+	uint32_t max_cpu_index;
+
+	/*
+	 * If not NULL, these arrays are filled with core/socket/node identifier
+	 * for each cpu.
+	 * If a cpu has no core/socket/node information (e.g., cpu not present)
+	 * then the sentinel value ~0u is written to each array.
+	 * The number of array elements written by the sysctl is:
+	 *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
+	 */
+	GUEST_HANDLE_64(uint32_t) cpu_to_core;
+	GUEST_HANDLE_64(uint32_t) cpu_to_socket;
+	GUEST_HANDLE_64(uint32_t) cpu_to_node;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
+
+/* XEN_SYSCTL_numainfo */
+#define INVALID_NUMAINFO_ID (~0U)
+struct xen_sysctl_numainfo {
+	/*
+	 * IN: maximum addressable entry in the caller-provided arrays.
+	 * OUT: largest node identifier in the system.
+	 * If OUT is greater than IN then the arrays are truncated!
+	 */
+	uint32_t max_node_index;
+
+	/* NB. Entries are 0 if node is not present. */
+	GUEST_HANDLE_64(uint64_t) node_to_memsize;
+	GUEST_HANDLE_64(uint64_t) node_to_memfree;
+
+	/*
+	 * Array, of size (max_node_index+1)^2, listing memory access distances
+	 * between nodes. If an entry has no node distance information (e.g., node
+	 * not present) then the value ~0u is written.
+	 *
+	 * Note that the array rows must be indexed by multiplying by the minimum
+	 * of the caller-provided max_node_index and the returned value of
+	 * max_node_index. That is, if the largest node index in the system is
+	 * smaller than the caller can handle, a smaller 2-d array is constructed
+	 * within the space provided by the caller. When this occurs, trailing
+	 * space provided by the caller is not modified. If the largest node index
+	 * in the system is larger than the caller can handle, then a 2-d array of
+	 * the maximum size handleable by the caller is constructed.
+	 */
+	GUEST_HANDLE_64(uint32_t) node_to_node_distance;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
+
+/* XEN_SYSCTL_cpupool_op */
+#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
+#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
+#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
+#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
+#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
+#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
+#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
+#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
+struct xen_sysctl_cpupool_op {
+	uint32_t op;          /* IN */
+	uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
+	uint32_t sched_id;    /* IN: C      OUT: I  */
+	uint32_t domid;       /* IN: M              */
+	uint32_t cpu;         /* IN: AR             */
+	uint32_t n_dom;       /*            OUT: I  */
+	struct xenctl_bitmap cpumap; /*     OUT: IF */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
+
+#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
+/*
+ * This structure is used to pass a new ARINC653 schedule from a
+ * privileged domain (ie dom0) to Xen.
+ */
+struct xen_sysctl_arinc653_schedule {
+	/* major_frame holds the time for the new schedule's major frame
+	* in nanoseconds. */
+	uint64_aligned_t     major_frame;
+	/* num_sched_entries holds how many of the entries in the
+	* sched_entries[] array are valid. */
+	uint8_t     num_sched_entries;
+	/* The sched_entries array holds the actual schedule entries. */
+	struct {
+		/* dom_handle must match a domain's UUID */
+		xen_domain_handle_t dom_handle;
+		/*
+		 * If a domain has multiple VCPUs, vcpu_id specifies which one
+		 * this schedule entry applies to. It should be set to 0 if
+		 * there is only one VCPU for the domain. */
+		unsigned int vcpu_id;
+		/*
+		 * runtime specifies the amount of time that should be allocated
+		 * to this VCPU per major frame. It is specified in nanoseconds
+		 */
+		uint64_aligned_t runtime;
+	} sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
+
+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;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
+
+/* XEN_SYSCTL_scheduler_op */
+/* Set or get info? */
+#define XEN_SYSCTL_SCHEDOP_putinfo 0
+#define XEN_SYSCTL_SCHEDOP_getinfo 1
+struct xen_sysctl_scheduler_op {
+	uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
+	uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
+	uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
+	union {
+		struct xen_sysctl_sched_arinc653 {
+			GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
+		} sched_arinc653;
+		struct xen_sysctl_credit_schedule sched_credit;
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
+
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 0
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them.
+ */
+#define XEN_SYSCTL_COVERAGE_read           1
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          2
+
+/*
+ * Like XEN_SYSCTL_COVERAGE_read but reset also
+ * counters to 0 in a single call.
+ */
+#define XEN_SYSCTL_COVERAGE_read_and_reset 3
+
+struct xen_sysctl_coverage_op {
+	uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+	union {
+		uint32_t total_size; /* OUT */
+		GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
+
+
+struct xen_sysctl {
+	uint32_t cmd;
+#define XEN_SYSCTL_readconsole                    1
+#define XEN_SYSCTL_tbuf_op                        2
+#define XEN_SYSCTL_physinfo                       3
+#define XEN_SYSCTL_sched_id                       4
+#define XEN_SYSCTL_perfc_op                       5
+#define XEN_SYSCTL_debug_keys                     7
+#define XEN_SYSCTL_getcpuinfo                     8
+#define XEN_SYSCTL_availheap                      9
+#define XEN_SYSCTL_get_pmstat                    10
+#define XEN_SYSCTL_cpu_hotplug                   11
+#define XEN_SYSCTL_pm_op                         12
+#define XEN_SYSCTL_page_offline_op               14
+#define XEN_SYSCTL_lockprof_op                   15
+#define XEN_SYSCTL_topologyinfo                  16
+#define XEN_SYSCTL_numainfo                      17
+#define XEN_SYSCTL_cpupool_op                    18
+#define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
+	uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
+	union {
+		struct xen_sysctl_readconsole       readconsole;
+		struct xen_sysctl_tbuf_op           tbuf_op;
+		struct xen_sysctl_physinfo          physinfo;
+		struct xen_sysctl_topologyinfo      topologyinfo;
+		struct xen_sysctl_numainfo          numainfo;
+		struct xen_sysctl_sched_id          sched_id;
+		struct xen_sysctl_perfc_op          perfc_op;
+		struct xen_sysctl_debug_keys        debug_keys;
+		struct xen_sysctl_getcpuinfo        getcpuinfo;
+		struct xen_sysctl_availheap         availheap;
+		struct xen_sysctl_get_pmstat        get_pmstat;
+		struct xen_sysctl_cpu_hotplug       cpu_hotplug;
+		struct xen_sysctl_pm_op             pm_op;
+		struct xen_sysctl_page_offline_op   page_offline;
+		struct xen_sysctl_lockprof_op       lockprof_op;
+		struct xen_sysctl_cpupool_op        cpupool_op;
+		struct xen_sysctl_scheduler_op      scheduler_op;
+		struct xen_sysctl_coverage_op       coverage_op;
+		uint8_t                             pad[128];
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
+
+#endif /* __XEN_PUBLIC_SYSCTL_H__ */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 53ec416..cf64566 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -57,6 +57,7 @@
 #define __HYPERVISOR_event_channel_op     32
 #define __HYPERVISOR_physdev_op           33
 #define __HYPERVISOR_hvm_op               34
+#define __HYPERVISOR_sysctl               35
 #define __HYPERVISOR_tmem_op              38
 
 /* Architecture-specific hypercall definitions. */
@@ -526,6 +527,11 @@ struct tmem_op {
 
 DEFINE_GUEST_HANDLE(u64);
 
+struct xenctl_bitmap {
+	GUEST_HANDLE_64(uint8_t) bitmap;
+	uint32_t nr_bits;
+};
+
 #else /* __ASSEMBLY__ */
 
 /* In assembly code we cannot use C numeric constant suffixes. */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldrq-0005Kk-BR; Tue, 04 Nov 2014 13:09:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldro-0005Is-Mz
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C6/61-09842-C10D8545; Tue, 04 Nov 2014 13:09:48 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415106582!12109881!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9618 invoked from network); 4 Nov 2014 13:09:45 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:45 -0000
Received: from mail-lb0-f172.google.com ([209.85.217.172]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQFuGxUeBXsczMQMlTUWtepdhzjMF2@postini.com;
	Tue, 04 Nov 2014 05:09:44 PST
Received: by mail-lb0-f172.google.com with SMTP id w7so3908883lbi.31
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=Bk1RVD6fijuQyhO/DHH9SfeA7X22ADDCyM4k1hNkoHM=;
	b=ga4Yy2BxKCx73X8/QgY2r+/+pdkDDTq8wACYDZF8eR3+ZamAWOXOSxHBiIoCgkZv1e
	JUXRJVKfs2E6gh5FlYgRpyUtgMX5ZLcTqA8hKme+o90BRRb26+3vX9gj0SEmjJTxbF66
	QGKZ5GsI4T8jBiLXls7JNrisJSUTINxWZdWT0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=Bk1RVD6fijuQyhO/DHH9SfeA7X22ADDCyM4k1hNkoHM=;
	b=WQYMBjwPKiUQ5IsCfVbjhaterWZpeMWhUIIZ7iG+AgyPMqdRkRBU0tLmRb+LxUj6wH
	Nven4ezpJjDdWEz5gclxvs2s3XYWtMMcdrlUGBBv/eqqWL1UxxBa/v/XHDPYnkdawyV9
	xROPe4s98Fy8FKh5i+B/BMNmNjvpW4udFQtsMkEKy5KglEqAfpfUhC2MFiAlNYEzfG3d
	BWW3znvE37fgXvS/BOO+jMOOpQjJUzMxCpFyq1e6VfKKgbeXCrBM8O0Up5Svwo7LeRkQ
	iUrLwuvYMyIrCLJL5DLmRbiVGf1XFm9GeFuDmi2GLRebRe0DzKnGLGrcEkY6M/Dyjp4o
	KBaQ==
X-Gm-Message-State: ALoCoQkTVPloL1pI0hxM1azuGzNjFrBrUmuDPDdCW7IFjSRvUe3hIrjhulJxCC3QF2ECFAb4imWqD2EZqsQeVLog+tC6X9QV/oq3dAD98hprualTaoN+9RpJEAb163NH3mqVevjrKtBpwI3pPATJQoNj3OU4KRa7Sw==
X-Received: by 10.152.27.38 with SMTP id q6mr21192967lag.92.1415106581105;
	Tue, 04 Nov 2014 05:09:41 -0800 (PST)
X-Received: by 10.152.27.38 with SMTP id q6mr21192953lag.92.1415106581019;
	Tue, 04 Nov 2014 05:09:41 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id l7sm148796lah.27.2014.11.04.05.09.39
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:40 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:25 +0200
Message-Id: <1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 arch/arm/include/asm/xen/hypercall.h |   1 +
 arch/arm/include/asm/xen/interface.h |   2 +
 arch/arm/xen/enlighten.c             |   1 +
 arch/arm/xen/hypercall.S             |   1 +
 include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
 include/xen/interface/xen.h          |   6 +
 6 files changed, 657 insertions(+)
 create mode 100644 include/xen/interface/sysctl.h

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index c817c56..751869eb 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_sysctl(void *arg);
 
 static inline void
 MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 1151188..acf4b7a 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -19,6 +19,7 @@
 	__DEFINE_GUEST_HANDLE(name, struct name)
 #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
 #define GUEST_HANDLE(name)        __guest_handle_ ## name
+#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
 
 #define set_xen_guest_handle(hnd, val)			\
 	do {						\
@@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(uint8_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 DEFINE_GUEST_HANDLE(xen_ulong_t);
 
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index eb0d851..675f17a 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index d1cf7b7..a1276df 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
+HYPERCALL1(sysctl);
 
 ENTRY(privcmd_call)
 	stmdb sp!, {r4}
diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
new file mode 100644
index 0000000..1a8cf7a
--- /dev/null
+++ b/include/xen/interface/sysctl.h
@@ -0,0 +1,646 @@
+/******************************************************************************
+ * sysctl.h
+ *
+ * System management operations. For use by node control stack.
+ *
+ * Reused from xen: xen/include/public/sysctl.h
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2002-2006, K Fraser
+ * Copyright (c) 2014, GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_SYSCTL_H__
+#define __XEN_PUBLIC_SYSCTL_H__
+
+#include <xen/interface/xen.h>
+
+#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
+
+/*
+ * Read console content from Xen buffer ring.
+ */
+/* XEN_SYSCTL_readconsole */
+struct xen_sysctl_readconsole {
+	/* IN: Non-zero -> clear after reading. */
+	uint8_t clear;
+	/* IN: Non-zero -> start index specified by @index field. */
+	uint8_t incremental;
+	uint8_t pad0, pad1;
+	/*
+	* IN:  Start index for consuming from ring buffer (if @incremental);
+	* OUT: End index after consuming from ring buffer.
+	*/
+	uint32_t index;
+	/* IN: Virtual address to write console data. */
+	GUEST_HANDLE_64(char) buffer;
+	/* IN: Size of buffer; OUT: Bytes written to buffer. */
+	uint32_t count;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
+
+/* Get trace buffers machine base address */
+/* XEN_SYSCTL_tbuf_op */
+struct xen_sysctl_tbuf_op {
+    /* IN variables */
+#define XEN_SYSCTL_TBUFOP_get_info     0
+#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
+#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
+#define XEN_SYSCTL_TBUFOP_set_size     3
+#define XEN_SYSCTL_TBUFOP_enable       4
+#define XEN_SYSCTL_TBUFOP_disable      5
+	uint32_t cmd;
+	/* IN/OUT variables */
+	struct xenctl_bitmap cpu_mask;
+	uint32_t             evt_mask;
+	/* OUT variables */
+	uint64_aligned_t buffer_mfn;
+	uint32_t size;  /* Also an IN variable! */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
+
+/*
+ * Get physical information about the host machine
+ */
+/* XEN_SYSCTL_physinfo */
+ /* (x86) The platform supports HVM guests. */
+#define _XEN_SYSCTL_PHYSCAP_hvm          0
+#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
+ /* (x86) The platform supports HVM-guest direct access to I/O devices. */
+#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
+#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
+struct xen_sysctl_physinfo {
+	uint32_t threads_per_core;
+	uint32_t cores_per_socket;
+	uint32_t nr_cpus;     /* # CPUs currently online */
+	uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
+	uint32_t nr_nodes;    /* # nodes currently online */
+	uint32_t max_node_id; /* Largest possible node ID on this host */
+	uint32_t cpu_khz;
+	uint64_aligned_t total_pages;
+	uint64_aligned_t free_pages;
+	uint64_aligned_t scrub_pages;
+	uint64_aligned_t outstanding_pages;
+	uint32_t hw_cap[8];
+
+	/* XEN_SYSCTL_PHYSCAP_??? */
+	uint32_t capabilities;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
+
+/*
+ * Get the ID of the current scheduler.
+ */
+/* XEN_SYSCTL_sched_id */
+struct xen_sysctl_sched_id {
+	/* OUT variable */
+	uint32_t sched_id;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
+
+/* Interface for controlling Xen software performance counters. */
+/* XEN_SYSCTL_perfc_op */
+/* Sub-operations: */
+#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
+#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
+struct xen_sysctl_perfc_desc {
+	char         name[80];           /* name of perf counter */
+	uint32_t     nr_vals;            /* number of values for this counter */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
+
+struct xen_sysctl_perfc_op {
+	/* IN variables. */
+	uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
+	/* OUT variables. */
+	uint32_t       nr_counters;       /*  number of counters description  */
+	uint32_t       nr_vals;           /*  number of values  */
+	/* counter information (or NULL) */
+	GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
+	/* counter values (or NULL) */
+	GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
+
+/* Inject debug keys into Xen. */
+/* XEN_SYSCTL_debug_keys */
+struct xen_sysctl_debug_keys {
+	/* IN variables. */
+	GUEST_HANDLE_64(char) keys;
+	uint32_t nr_keys;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
+
+/* Get physical CPU information. */
+/* XEN_SYSCTL_getcpuinfo */
+struct xen_sysctl_cpuinfo {
+	uint64_aligned_t idletime;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
+struct xen_sysctl_getcpuinfo {
+	/* IN variables. */
+	uint32_t max_cpus;
+	GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
+	/* OUT variables. */
+	uint32_t nr_cpus;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
+
+/* XEN_SYSCTL_availheap */
+struct xen_sysctl_availheap {
+	/* IN variables. */
+	uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
+	uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
+	int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
+	/* OUT variables. */
+	uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
+
+/* XEN_SYSCTL_get_pmstat */
+struct pm_px_val {
+	uint64_aligned_t freq;        /* Px core frequency */
+	uint64_aligned_t residency;   /* Px residency time */
+	uint64_aligned_t count;       /* Px transition count */
+};
+DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
+
+struct pm_px_stat {
+	uint8_t total;        /* total Px states */
+	uint8_t usable;       /* usable Px states */
+	uint8_t last;         /* last Px state */
+	uint8_t cur;          /* current Px state */
+	GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
+	GUEST_HANDLE_64(pm_px_val) pt;
+};
+DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
+
+struct pm_cx_stat {
+	uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
+	uint32_t last;  /* last Cx state */
+	uint64_aligned_t idle_time;                 /* idle time from boot */
+	GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
+	GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
+	uint64_aligned_t pc2;
+	uint64_aligned_t pc3;
+	uint64_aligned_t pc6;
+	uint64_aligned_t pc7;
+	uint64_aligned_t cc3;
+	uint64_aligned_t cc6;
+	uint64_aligned_t cc7;
+};
+
+struct xen_sysctl_get_pmstat {
+#define PMSTAT_CATEGORY_MASK 0xf0
+#define PMSTAT_PX            0x10
+#define PMSTAT_CX            0x20
+#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
+#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
+#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
+#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
+#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
+#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
+	uint32_t type;
+	uint32_t cpuid;
+	union {
+		struct pm_px_stat getpx;
+		struct pm_cx_stat getcx;
+		/* other struct for tx, etc */
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
+
+/* XEN_SYSCTL_cpu_hotplug */
+struct xen_sysctl_cpu_hotplug {
+	/* IN variables */
+	uint32_t cpu;   /* Physical cpu. */
+#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
+#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
+	uint32_t op;    /* hotplug opcode */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
+
+/*
+ * Get/set xen power management, include
+ * 1. cpufreq governors and related parameters
+ */
+/* XEN_SYSCTL_pm_op */
+struct xen_userspace {
+	uint32_t scaling_setspeed;
+};
+
+struct xen_ondemand {
+	uint32_t sampling_rate_max;
+	uint32_t sampling_rate_min;
+
+	uint32_t sampling_rate;
+	uint32_t up_threshold;
+};
+
+/*
+ * cpufreq para name of this structure named
+ * same as sysfs file name of native linux
+ */
+#define CPUFREQ_NAME_LEN 16
+struct xen_get_cpufreq_para {
+	/* IN/OUT variable */
+	uint32_t cpu_num;
+	uint32_t freq_num;
+	uint32_t gov_num;
+
+	/* for all governors */
+	/* OUT variable */
+	GUEST_HANDLE_64(uint32_t) affected_cpus;
+	GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
+	GUEST_HANDLE_64(char)   scaling_available_governors;
+	char scaling_driver[CPUFREQ_NAME_LEN];
+
+	uint32_t cpuinfo_cur_freq;
+	uint32_t cpuinfo_max_freq;
+	uint32_t cpuinfo_min_freq;
+	uint32_t scaling_cur_freq;
+
+	char scaling_governor[CPUFREQ_NAME_LEN];
+	uint32_t scaling_max_freq;
+	uint32_t scaling_min_freq;
+
+	/* for specific governor */
+	union {
+		struct  xen_userspace userspace;
+		struct  xen_ondemand ondemand;
+	} u;
+
+	int32_t turbo_enabled;
+};
+
+struct xen_set_cpufreq_gov {
+	char scaling_governor[CPUFREQ_NAME_LEN];
+};
+
+struct xen_set_cpufreq_para {
+	#define SCALING_MAX_FREQ           1
+	#define SCALING_MIN_FREQ           2
+	#define SCALING_SETSPEED           3
+	#define SAMPLING_RATE              4
+	#define UP_THRESHOLD               5
+
+	uint32_t ctrl_type;
+	uint32_t ctrl_value;
+};
+
+struct xen_sysctl_pm_op {
+	#define PM_PARA_CATEGORY_MASK      0xf0
+	#define CPUFREQ_PARA               0x10
+
+	/* cpufreq command type */
+	#define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
+	#define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
+	#define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
+	#define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
+
+	/* set/reset scheduler power saving option */
+	#define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
+
+	/* cpuidle max_cstate access command */
+	#define XEN_SYSCTL_pm_op_get_max_cstate       0x22
+	#define XEN_SYSCTL_pm_op_set_max_cstate       0x23
+
+	/* set scheduler migration cost value */
+	#define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
+	#define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
+
+	/* enable/disable turbo mode when in dbs governor */
+	#define XEN_SYSCTL_pm_op_enable_turbo               0x26
+	#define XEN_SYSCTL_pm_op_disable_turbo              0x27
+
+	uint32_t cmd;
+	uint32_t cpuid;
+	union {
+		struct xen_get_cpufreq_para get_para;
+		struct xen_set_cpufreq_gov  set_gov;
+		struct xen_set_cpufreq_para set_para;
+		uint64_aligned_t get_avgfreq;
+		uint32_t                    set_sched_opt_smt;
+		uint32_t                    get_max_cstate;
+		uint32_t                    set_max_cstate;
+		uint32_t                    get_vcpu_migration_delay;
+		uint32_t                    set_vcpu_migration_delay;
+	} u;
+};
+
+/* XEN_SYSCTL_page_offline_op */
+struct xen_sysctl_page_offline_op {
+	/* IN: range of page to be offlined */
+#define sysctl_page_offline     1
+#define sysctl_page_online      2
+#define sysctl_query_page_offline  3
+	uint32_t cmd;
+	uint32_t start;
+	uint32_t end;
+	/* OUT: result of page offline request */
+	/*
+	* bit 0~15: result flags
+	* bit 16~31: owner
+	*/
+	GUEST_HANDLE(uint32_t) status;
+};
+
+#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
+
+/* The result is invalid, i.e. HV does not handle it */
+#define PG_OFFLINE_INVALID   (0x1UL << 0)
+
+#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
+#define PG_OFFLINE_PENDING   (0x1UL << 2)
+#define PG_OFFLINE_FAILED    (0x1UL << 3)
+#define PG_OFFLINE_AGAIN     (0x1UL << 4)
+
+#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
+#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
+
+#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
+#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
+#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
+#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
+
+#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
+
+/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
+#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
+#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
+#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
+#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
+#define PG_OFFLINE_OWNED     (0x1UL << 12)
+
+#define PG_OFFLINE_BROKEN    (0x1UL << 13)
+#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
+
+#define PG_OFFLINE_OWNER_SHIFT 16
+
+/* XEN_SYSCTL_lockprof_op */
+/* Sub-operations: */
+#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
+#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
+/* Record-type: */
+#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
+#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
+#define LOCKPROF_TYPE_N           2   /* number of types */
+struct xen_sysctl_lockprof_data {
+	char     name[40];   /* lock name (may include up to 2 %d specifiers) */
+	int32_t  type;       /* LOCKPROF_TYPE_??? */
+	int32_t  idx;        /* index (e.g. domain id) */
+	uint64_aligned_t lock_cnt;     /* # of locking succeeded */
+	uint64_aligned_t block_cnt;    /* # of wait for lock */
+	uint64_aligned_t lock_time;    /* nsecs lock held */
+	uint64_aligned_t block_time;   /* nsecs waited for lock */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
+
+struct xen_sysctl_lockprof_op {
+	/* IN variables. */
+	uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
+	uint32_t       max_elem;          /* size of output buffer */
+	/* OUT variables (query only). */
+	uint32_t       nr_elem;           /* number of elements available */
+	uint64_aligned_t time;            /* nsecs of profile measurement */
+	/* profile information (or NULL) */
+	GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
+
+/* XEN_SYSCTL_topologyinfo */
+#define INVALID_TOPOLOGY_ID  (~0U)
+struct xen_sysctl_topologyinfo {
+	/*
+	 * IN: maximum addressable entry in the caller-provided arrays.
+	 * OUT: largest cpu identifier in the system.
+	 * If OUT is greater than IN then the arrays are truncated!
+	 * If OUT is leass than IN then the array tails are not written by
+	 * sysctl.
+	 */
+	uint32_t max_cpu_index;
+
+	/*
+	 * If not NULL, these arrays are filled with core/socket/node identifier
+	 * for each cpu.
+	 * If a cpu has no core/socket/node information (e.g., cpu not present)
+	 * then the sentinel value ~0u is written to each array.
+	 * The number of array elements written by the sysctl is:
+	 *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
+	 */
+	GUEST_HANDLE_64(uint32_t) cpu_to_core;
+	GUEST_HANDLE_64(uint32_t) cpu_to_socket;
+	GUEST_HANDLE_64(uint32_t) cpu_to_node;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
+
+/* XEN_SYSCTL_numainfo */
+#define INVALID_NUMAINFO_ID (~0U)
+struct xen_sysctl_numainfo {
+	/*
+	 * IN: maximum addressable entry in the caller-provided arrays.
+	 * OUT: largest node identifier in the system.
+	 * If OUT is greater than IN then the arrays are truncated!
+	 */
+	uint32_t max_node_index;
+
+	/* NB. Entries are 0 if node is not present. */
+	GUEST_HANDLE_64(uint64_t) node_to_memsize;
+	GUEST_HANDLE_64(uint64_t) node_to_memfree;
+
+	/*
+	 * Array, of size (max_node_index+1)^2, listing memory access distances
+	 * between nodes. If an entry has no node distance information (e.g., node
+	 * not present) then the value ~0u is written.
+	 *
+	 * Note that the array rows must be indexed by multiplying by the minimum
+	 * of the caller-provided max_node_index and the returned value of
+	 * max_node_index. That is, if the largest node index in the system is
+	 * smaller than the caller can handle, a smaller 2-d array is constructed
+	 * within the space provided by the caller. When this occurs, trailing
+	 * space provided by the caller is not modified. If the largest node index
+	 * in the system is larger than the caller can handle, then a 2-d array of
+	 * the maximum size handleable by the caller is constructed.
+	 */
+	GUEST_HANDLE_64(uint32_t) node_to_node_distance;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
+
+/* XEN_SYSCTL_cpupool_op */
+#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
+#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
+#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
+#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
+#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
+#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
+#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
+#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
+struct xen_sysctl_cpupool_op {
+	uint32_t op;          /* IN */
+	uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
+	uint32_t sched_id;    /* IN: C      OUT: I  */
+	uint32_t domid;       /* IN: M              */
+	uint32_t cpu;         /* IN: AR             */
+	uint32_t n_dom;       /*            OUT: I  */
+	struct xenctl_bitmap cpumap; /*     OUT: IF */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
+
+#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
+/*
+ * This structure is used to pass a new ARINC653 schedule from a
+ * privileged domain (ie dom0) to Xen.
+ */
+struct xen_sysctl_arinc653_schedule {
+	/* major_frame holds the time for the new schedule's major frame
+	* in nanoseconds. */
+	uint64_aligned_t     major_frame;
+	/* num_sched_entries holds how many of the entries in the
+	* sched_entries[] array are valid. */
+	uint8_t     num_sched_entries;
+	/* The sched_entries array holds the actual schedule entries. */
+	struct {
+		/* dom_handle must match a domain's UUID */
+		xen_domain_handle_t dom_handle;
+		/*
+		 * If a domain has multiple VCPUs, vcpu_id specifies which one
+		 * this schedule entry applies to. It should be set to 0 if
+		 * there is only one VCPU for the domain. */
+		unsigned int vcpu_id;
+		/*
+		 * runtime specifies the amount of time that should be allocated
+		 * to this VCPU per major frame. It is specified in nanoseconds
+		 */
+		uint64_aligned_t runtime;
+	} sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
+
+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;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
+
+/* XEN_SYSCTL_scheduler_op */
+/* Set or get info? */
+#define XEN_SYSCTL_SCHEDOP_putinfo 0
+#define XEN_SYSCTL_SCHEDOP_getinfo 1
+struct xen_sysctl_scheduler_op {
+	uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
+	uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
+	uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
+	union {
+		struct xen_sysctl_sched_arinc653 {
+			GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
+		} sched_arinc653;
+		struct xen_sysctl_credit_schedule sched_credit;
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
+
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 0
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them.
+ */
+#define XEN_SYSCTL_COVERAGE_read           1
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          2
+
+/*
+ * Like XEN_SYSCTL_COVERAGE_read but reset also
+ * counters to 0 in a single call.
+ */
+#define XEN_SYSCTL_COVERAGE_read_and_reset 3
+
+struct xen_sysctl_coverage_op {
+	uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+	union {
+		uint32_t total_size; /* OUT */
+		GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
+
+
+struct xen_sysctl {
+	uint32_t cmd;
+#define XEN_SYSCTL_readconsole                    1
+#define XEN_SYSCTL_tbuf_op                        2
+#define XEN_SYSCTL_physinfo                       3
+#define XEN_SYSCTL_sched_id                       4
+#define XEN_SYSCTL_perfc_op                       5
+#define XEN_SYSCTL_debug_keys                     7
+#define XEN_SYSCTL_getcpuinfo                     8
+#define XEN_SYSCTL_availheap                      9
+#define XEN_SYSCTL_get_pmstat                    10
+#define XEN_SYSCTL_cpu_hotplug                   11
+#define XEN_SYSCTL_pm_op                         12
+#define XEN_SYSCTL_page_offline_op               14
+#define XEN_SYSCTL_lockprof_op                   15
+#define XEN_SYSCTL_topologyinfo                  16
+#define XEN_SYSCTL_numainfo                      17
+#define XEN_SYSCTL_cpupool_op                    18
+#define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
+	uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
+	union {
+		struct xen_sysctl_readconsole       readconsole;
+		struct xen_sysctl_tbuf_op           tbuf_op;
+		struct xen_sysctl_physinfo          physinfo;
+		struct xen_sysctl_topologyinfo      topologyinfo;
+		struct xen_sysctl_numainfo          numainfo;
+		struct xen_sysctl_sched_id          sched_id;
+		struct xen_sysctl_perfc_op          perfc_op;
+		struct xen_sysctl_debug_keys        debug_keys;
+		struct xen_sysctl_getcpuinfo        getcpuinfo;
+		struct xen_sysctl_availheap         availheap;
+		struct xen_sysctl_get_pmstat        get_pmstat;
+		struct xen_sysctl_cpu_hotplug       cpu_hotplug;
+		struct xen_sysctl_pm_op             pm_op;
+		struct xen_sysctl_page_offline_op   page_offline;
+		struct xen_sysctl_lockprof_op       lockprof_op;
+		struct xen_sysctl_cpupool_op        cpupool_op;
+		struct xen_sysctl_scheduler_op      scheduler_op;
+		struct xen_sysctl_coverage_op       coverage_op;
+		uint8_t                             pad[128];
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
+
+#endif /* __XEN_PUBLIC_SYSCTL_H__ */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 53ec416..cf64566 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -57,6 +57,7 @@
 #define __HYPERVISOR_event_channel_op     32
 #define __HYPERVISOR_physdev_op           33
 #define __HYPERVISOR_hvm_op               34
+#define __HYPERVISOR_sysctl               35
 #define __HYPERVISOR_tmem_op              38
 
 /* Architecture-specific hypercall definitions. */
@@ -526,6 +527,11 @@ struct tmem_op {
 
 DEFINE_GUEST_HANDLE(u64);
 
+struct xenctl_bitmap {
+	GUEST_HANDLE_64(uint8_t) bitmap;
+	uint32_t nr_bits;
+};
+
 #else /* __ASSEMBLY__ */
 
 /* In assembly code we cannot use C numeric constant suffixes. */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldrr-0005MU-E9; Tue, 04 Nov 2014 13:09:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldrq-0005KI-A9
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	73/BC-24532-D10D8545; Tue, 04 Nov 2014 13:09:49 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415106585!12705473!1
X-Originating-IP: [64.18.0.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9044 invoked from network); 4 Nov 2014 13:09:47 -0000
Received: from exprod5og103.obsmtp.com (HELO exprod5og103.obsmtp.com)
	(64.18.0.145)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:47 -0000
Received: from mail-la0-f45.google.com ([209.85.215.45]) (using TLSv1) by
	exprod5ob103.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQGf6Iotic+wAfMhEcQc9DbvcBvdvd@postini.com;
	Tue, 04 Nov 2014 05:09:47 PST
Received: by mail-la0-f45.google.com with SMTP id pn19so830093lab.4
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=KNbIcswCcQH9MFn3dtbLkd+7P+UPEjD4+i0I4Eom4wg=;
	b=f7jTtCfWiXf7pFNJV5G91Evwk0H0tS8+HUn8jM1PGM7UR/0QT845z/jGpYLYvape2Z
	/Uou6niYLeVDfxMcKLjtq5sM7x3NbQkOg0K+bdZcTZiM3Yldy8eG2ayhnUpNb6txuNzO
	lKAs9RVfTvOO96MaWEYxrztoycZqLUsnWgxHE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=KNbIcswCcQH9MFn3dtbLkd+7P+UPEjD4+i0I4Eom4wg=;
	b=Vo6AAD0OD0J1cBvxckpie0gYX9+9NmHPGsVW3f51X1dvNGSqZqx2UPUsr4N425ewhQ
	1ugRweLIc6Qyccla3laDt7Yy90VFeNLkGv/al0KDYBL/STfP1j2xEBh0zTMiUo+cLVlu
	ri5B3DjNWmUxcQFJU16GgGCWPnRkLMj5EsJRpw34nwzygOjHjgZYEWNsKkimyU3OlB6u
	hRdJ6Dxme1WQQJKWSHVjfp/I+Pw54p0ROvzVYhshvha5rHTnZCxmkQ2kCeiesYtZ2sfz
	N+8fqNxCo9qnVi7OYN8/U6Udoh3GA9jOctOeUjl7s6lmkaTIbUlJX0B9dkAKc82MEr41
	+pTg==
X-Gm-Message-State: ALoCoQlvK2sy62aGaZ46KMnx0huJLR8PFcNL6y70FGNoWje8hYg0u5pLG0zNKTTBL+cVGykReHkxTNbfRxH2oZnqj7eC2NjQr8MF+CwTeRd4Cp99aj7SmEgddbw45FwMDSX2pM9Gvijqx5UV65H+hE2KILCjz2xstw==
X-Received: by 10.112.138.196 with SMTP id qs4mr59128202lbb.83.1415106583915; 
	Tue, 04 Nov 2014 05:09:43 -0800 (PST)
X-Received: by 10.112.138.196 with SMTP id qs4mr59128189lbb.83.1415106583853; 
	Tue, 04 Nov 2014 05:09:43 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id of1sm160775lbb.3.2014.11.04.05.09.42
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:43 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:26 +0200
Message-Id: <1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 arch/arm/include/asm/xen/hypercall.h | 1 +
 arch/arm/xen/enlighten.c             | 1 +
 arch/arm/xen/hypercall.S             | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 751869eb..383c174 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_dom0_op(void *arg);
 int HYPERVISOR_sysctl(void *arg);
 
 static inline void
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 675f17a..f757c57 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index a1276df..99e2254 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
+HYPERCALL1(dom0_op);
 HYPERCALL1(sysctl);
 
 ENTRY(privcmd_call)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldrr-0005MU-E9; Tue, 04 Nov 2014 13:09:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldrq-0005KI-A9
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	73/BC-24532-D10D8545; Tue, 04 Nov 2014 13:09:49 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415106585!12705473!1
X-Originating-IP: [64.18.0.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9044 invoked from network); 4 Nov 2014 13:09:47 -0000
Received: from exprod5og103.obsmtp.com (HELO exprod5og103.obsmtp.com)
	(64.18.0.145)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:47 -0000
Received: from mail-la0-f45.google.com ([209.85.215.45]) (using TLSv1) by
	exprod5ob103.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQGf6Iotic+wAfMhEcQc9DbvcBvdvd@postini.com;
	Tue, 04 Nov 2014 05:09:47 PST
Received: by mail-la0-f45.google.com with SMTP id pn19so830093lab.4
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=KNbIcswCcQH9MFn3dtbLkd+7P+UPEjD4+i0I4Eom4wg=;
	b=f7jTtCfWiXf7pFNJV5G91Evwk0H0tS8+HUn8jM1PGM7UR/0QT845z/jGpYLYvape2Z
	/Uou6niYLeVDfxMcKLjtq5sM7x3NbQkOg0K+bdZcTZiM3Yldy8eG2ayhnUpNb6txuNzO
	lKAs9RVfTvOO96MaWEYxrztoycZqLUsnWgxHE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=KNbIcswCcQH9MFn3dtbLkd+7P+UPEjD4+i0I4Eom4wg=;
	b=Vo6AAD0OD0J1cBvxckpie0gYX9+9NmHPGsVW3f51X1dvNGSqZqx2UPUsr4N425ewhQ
	1ugRweLIc6Qyccla3laDt7Yy90VFeNLkGv/al0KDYBL/STfP1j2xEBh0zTMiUo+cLVlu
	ri5B3DjNWmUxcQFJU16GgGCWPnRkLMj5EsJRpw34nwzygOjHjgZYEWNsKkimyU3OlB6u
	hRdJ6Dxme1WQQJKWSHVjfp/I+Pw54p0ROvzVYhshvha5rHTnZCxmkQ2kCeiesYtZ2sfz
	N+8fqNxCo9qnVi7OYN8/U6Udoh3GA9jOctOeUjl7s6lmkaTIbUlJX0B9dkAKc82MEr41
	+pTg==
X-Gm-Message-State: ALoCoQlvK2sy62aGaZ46KMnx0huJLR8PFcNL6y70FGNoWje8hYg0u5pLG0zNKTTBL+cVGykReHkxTNbfRxH2oZnqj7eC2NjQr8MF+CwTeRd4Cp99aj7SmEgddbw45FwMDSX2pM9Gvijqx5UV65H+hE2KILCjz2xstw==
X-Received: by 10.112.138.196 with SMTP id qs4mr59128202lbb.83.1415106583915; 
	Tue, 04 Nov 2014 05:09:43 -0800 (PST)
X-Received: by 10.112.138.196 with SMTP id qs4mr59128189lbb.83.1415106583853; 
	Tue, 04 Nov 2014 05:09:43 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id of1sm160775lbb.3.2014.11.04.05.09.42
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:43 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:26 +0200
Message-Id: <1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 arch/arm/include/asm/xen/hypercall.h | 1 +
 arch/arm/xen/enlighten.c             | 1 +
 arch/arm/xen/hypercall.S             | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 751869eb..383c174 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_dom0_op(void *arg);
 int HYPERVISOR_sysctl(void *arg);
 
 static inline void
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 675f17a..f757c57 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index a1276df..99e2254 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
+HYPERCALL1(dom0_op);
 HYPERCALL1(sysctl);
 
 ENTRY(privcmd_call)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldru-0005PZ-0o; Tue, 04 Nov 2014 13:09:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldrs-0005ND-8h
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:52 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	8D/08-27623-F10D8545; Tue, 04 Nov 2014 13:09:51 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415106588!11577152!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12445 invoked from network); 4 Nov 2014 13:09:50 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:50 -0000
Received: from mail-la0-f51.google.com ([209.85.215.51]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQHD16dSQn7TR8eEuh1qLZBXm9Wn+O@postini.com;
	Tue, 04 Nov 2014 05:09:50 PST
Received: by mail-la0-f51.google.com with SMTP id q1so827190lam.38
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=gKTFGR/vD2gQW4H3yYfKSHBCATxgsx2Eusf3gNw/PG4=;
	b=cfSi7LnT1LTQe428FF8BBK2AitOg1AaavoHnqDZvCQ5uoLO4quhJXmDOzTInJzHeg2
	a6/0w9T+Id5TIENEi3nWumjBw/ZZE3n/wof9SVPnwy0xHocaNVN1MKIMKcmGQnunRPHL
	tz1xOD1LSlIYan9K/IMmpY1xOxRTj2NCIu/Go=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=gKTFGR/vD2gQW4H3yYfKSHBCATxgsx2Eusf3gNw/PG4=;
	b=jxWObrOYiyxaAULWQaBvE7neN0MamxV0NMF83FiDRe0ja3Jda8ncSs8izTy9p5kj6E
	+qZbnfGdMKPxaBsxoCbb6t5I4CCYD8K6O21LeZCiJbPE4LKZdLKv7BaDc0RE61y1KHi2
	jRiYShij3l/PgvVx1rFfGGV/XCrBboA+zpvPG1fPGQCH6ZkKVEidCp1dOKGywLqCKWmW
	+ukBNUz7uKAlCnoDRiWDA3EqKC+QKfZfJGCfLgrEpfht+doIqHqWR+UW9IYyohyazPjy
	f5k2Saw4BAHrF9YiAQPgQ8HvBIyt01QcEYgmYiIA2rSiCQ0B0ca5xfsnUZF41g0jYV0T
	xSFQ==
X-Gm-Message-State: ALoCoQlXMNTifXs/fMv6YtScKnWb3xdb9crowQuM+2tUNOTWNDZ53M15e23041nqTwZE1V72T4dzTQdL0pHL2B6DxfqmxS+Ke3OIDj6ZihJXm4a8qfvXhEIVA0oGZuEXBQ+s3XnZ4Cd8pXK8cSVyOAl/EqjtsWOHdg==
X-Received: by 10.152.8.100 with SMTP id q4mr57747708laa.48.1415106586737;
	Tue, 04 Nov 2014 05:09:46 -0800 (PST)
X-Received: by 10.152.8.100 with SMTP id q4mr57747698laa.48.1415106586678;
	Tue, 04 Nov 2014 05:09:46 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id s8sm157907laa.9.2014.11.04.05.09.45
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:46 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:27 +0200
Message-Id: <1415106572-3178-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 4/9] docs: Xen ARM DT bindings: document
	pcpus property
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 Documentation/devicetree/bindings/arm/xen.txt | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..1d7aea3 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,11 +15,29 @@ the following properties:
 - interrupts: the interrupt used by Xen to inject event notifications.
   A GIC node is also required.
 
+- pcpus: this property is optional. It contains an information about physical
+  CPUs. This information is used by xen-cpufreq driver. The structure of
+  nodes which are inside of this property is the same as in the /cpus/ node.
 
-Example (assuming #address-cells = <2> and #size-cells = <2>):
+Xen also copies all properties from cpus/ node to the hypervisor/pcpus/ node
+in the device tree which is created for the hwdom in case if HAS_HWDOM_CPUFREQ
+config is defined.
+
+Example (assuming #address-cells = <2> and #size-cells = <2>) whith pcpus
+property:
 
 hypervisor {
 	compatible = "xen,xen-4.3", "xen,xen";
 	reg = <0 0xb0000000 0 0x20000>;
 	interrupts = <1 15 0xf08>;
+	pcpus {
+		cpu@0 {
+			device_type = "cpu";
+			reg = <0>;
+		};
+		cpu@1 {
+			device_type = "cpu";
+			reg = <1>;
+		};
+	};
 };
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldru-0005PZ-0o; Tue, 04 Nov 2014 13:09:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldrs-0005ND-8h
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:52 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	8D/08-27623-F10D8545; Tue, 04 Nov 2014 13:09:51 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415106588!11577152!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12445 invoked from network); 4 Nov 2014 13:09:50 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:50 -0000
Received: from mail-la0-f51.google.com ([209.85.215.51]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQHD16dSQn7TR8eEuh1qLZBXm9Wn+O@postini.com;
	Tue, 04 Nov 2014 05:09:50 PST
Received: by mail-la0-f51.google.com with SMTP id q1so827190lam.38
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=gKTFGR/vD2gQW4H3yYfKSHBCATxgsx2Eusf3gNw/PG4=;
	b=cfSi7LnT1LTQe428FF8BBK2AitOg1AaavoHnqDZvCQ5uoLO4quhJXmDOzTInJzHeg2
	a6/0w9T+Id5TIENEi3nWumjBw/ZZE3n/wof9SVPnwy0xHocaNVN1MKIMKcmGQnunRPHL
	tz1xOD1LSlIYan9K/IMmpY1xOxRTj2NCIu/Go=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=gKTFGR/vD2gQW4H3yYfKSHBCATxgsx2Eusf3gNw/PG4=;
	b=jxWObrOYiyxaAULWQaBvE7neN0MamxV0NMF83FiDRe0ja3Jda8ncSs8izTy9p5kj6E
	+qZbnfGdMKPxaBsxoCbb6t5I4CCYD8K6O21LeZCiJbPE4LKZdLKv7BaDc0RE61y1KHi2
	jRiYShij3l/PgvVx1rFfGGV/XCrBboA+zpvPG1fPGQCH6ZkKVEidCp1dOKGywLqCKWmW
	+ukBNUz7uKAlCnoDRiWDA3EqKC+QKfZfJGCfLgrEpfht+doIqHqWR+UW9IYyohyazPjy
	f5k2Saw4BAHrF9YiAQPgQ8HvBIyt01QcEYgmYiIA2rSiCQ0B0ca5xfsnUZF41g0jYV0T
	xSFQ==
X-Gm-Message-State: ALoCoQlXMNTifXs/fMv6YtScKnWb3xdb9crowQuM+2tUNOTWNDZ53M15e23041nqTwZE1V72T4dzTQdL0pHL2B6DxfqmxS+Ke3OIDj6ZihJXm4a8qfvXhEIVA0oGZuEXBQ+s3XnZ4Cd8pXK8cSVyOAl/EqjtsWOHdg==
X-Received: by 10.152.8.100 with SMTP id q4mr57747708laa.48.1415106586737;
	Tue, 04 Nov 2014 05:09:46 -0800 (PST)
X-Received: by 10.152.8.100 with SMTP id q4mr57747698laa.48.1415106586678;
	Tue, 04 Nov 2014 05:09:46 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id s8sm157907laa.9.2014.11.04.05.09.45
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:46 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:27 +0200
Message-Id: <1415106572-3178-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 4/9] docs: Xen ARM DT bindings: document
	pcpus property
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 Documentation/devicetree/bindings/arm/xen.txt | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..1d7aea3 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,11 +15,29 @@ the following properties:
 - interrupts: the interrupt used by Xen to inject event notifications.
   A GIC node is also required.
 
+- pcpus: this property is optional. It contains an information about physical
+  CPUs. This information is used by xen-cpufreq driver. The structure of
+  nodes which are inside of this property is the same as in the /cpus/ node.
 
-Example (assuming #address-cells = <2> and #size-cells = <2>):
+Xen also copies all properties from cpus/ node to the hypervisor/pcpus/ node
+in the device tree which is created for the hwdom in case if HAS_HWDOM_CPUFREQ
+config is defined.
+
+Example (assuming #address-cells = <2> and #size-cells = <2>) whith pcpus
+property:
 
 hypervisor {
 	compatible = "xen,xen-4.3", "xen,xen";
 	reg = <0 0xb0000000 0 0x20000>;
 	interrupts = <1 15 0xf08>;
+	pcpus {
+		cpu@0 {
+			device_type = "cpu";
+			reg = <0>;
+		};
+		cpu@1 {
+			device_type = "cpu";
+			reg = <1>;
+		};
+	};
 };
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldrv-0005Ri-Iy; Tue, 04 Nov 2014 13:09:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldru-0005Pu-PB
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:54 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	01/46-07724-220D8545; Tue, 04 Nov 2014 13:09:54 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415106590!11560639!1
X-Originating-IP: [64.18.0.198]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9492 invoked from network); 4 Nov 2014 13:09:53 -0000
Received: from exprod5og123.obsmtp.com (HELO exprod5og123.obsmtp.com)
	(64.18.0.198)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:53 -0000
Received: from mail-lb0-f177.google.com ([209.85.217.177]) (using TLSv1) by
	exprod5ob123.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQHrQMaw/7wli1Y2ATJ27H8UrewXJJ@postini.com;
	Tue, 04 Nov 2014 05:09:52 PST
Received: by mail-lb0-f177.google.com with SMTP id z12so2592659lbi.22
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=l02k0VbBuycAQpC6lsV21eSs8rvICA4r7aL5utBCj3U=;
	b=KnMl6siKcl0VR5u6FpQf3RyijOX91L5kMjb0MZNh4MJ8A+VncSLDvsQGz7bcSe7VcK
	hhCdBWPRFkhCJCTPBz9Rrjx9p32dcFpxuRIeTJjvTwxQEYs7Wf7ynpAtevZD9fRyptre
	7vFRgDCWuA7/L2laZOQiNjMX7zxtNZSilI9v4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=l02k0VbBuycAQpC6lsV21eSs8rvICA4r7aL5utBCj3U=;
	b=NH4DRlY2cSk5IaKvU8XCrLi8x5mhi/+kYwjWJZPe4PBSDObLV/ZNRl5WJkymhhXtZb
	RbtYda3ThFrjMiG+OoglbdofLfgsNvIM239xdm1ftkqbcj4fUyClJfzr8tXq+d4r2bqf
	LaVbsPUIcQ8B+bY+33lZEMNPSvGyEIFSRXcIvZIZwr2YtH/ZIimFzcr5l036rTmLKpkc
	2HO20ekdaai2TP6pTLHnD8CzdCFAeZcluBOcLkSD889E7alaVLAvilsDf7X8YMLyRHBH
	A7Osgskyx+SQscKr/iemz8CBC0EeTgfOxGy3jM7AjAPjZk0PGmvDrZPr+rLGSRrNdFIu
	mqlA==
X-Gm-Message-State: ALoCoQlY8Jwsg7uY3Fvbjtl9pVWZRIkJqLCrQf85rq/K2NzKq177PtXgco/gN9i4pFAs8uxXgKa+IV4m9D1Gw9JI3Skt2QDCmtzUci9sJzpnkXqcL2zieGSuaKOD8aNONuHCw4TVX/i8x65oioVdBJmCWqKPuJasfw==
X-Received: by 10.112.139.196 with SMTP id ra4mr21230135lbb.95.1415106589216; 
	Tue, 04 Nov 2014 05:09:49 -0800 (PST)
X-Received: by 10.112.139.196 with SMTP id ra4mr21230122lbb.95.1415106589146; 
	Tue, 04 Nov 2014 05:09:49 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id sd10sm158751lbb.8.2014.11.04.05.09.47
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:48 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:28 +0200
Message-Id: <1415106572-3178-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 5/9] cpufreq: cpufreq-cpu0: change cpus
	data path in devtree for hwdom kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hypervisor creates standard cpus nodes for virtual cpus.
All information needed for this driver about physical cpus
now located in /hypervisor/pcpus node instead of the
/cpus node in case if kernel is running as hardware domain.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/cpufreq-cpu0.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ef4fbc4..a83838b 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -21,6 +21,8 @@
 #include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 
+#include <xen/xen.h>
+
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
 
@@ -182,7 +184,13 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 	struct device_node *np;
 	int ret;
 
-	np = of_find_node_by_path("/cpus/cpu@0");
+#ifdef CONFIG_XEN_DOM0
+	if (xen_initial_domain())
+		np = of_find_node_by_path("/hypervisor/pcpus/cpu@0");
+	else
+#endif
+		np = of_find_node_by_path("/cpus/cpu@0");
+
 	if (!np) {
 		pr_err("failed to find cpu0 node\n");
 		return -ENOENT;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:09:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:09:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xldrv-0005Ri-Iy; Tue, 04 Nov 2014 13:09:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldru-0005Pu-PB
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:54 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	01/46-07724-220D8545; Tue, 04 Nov 2014 13:09:54 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415106590!11560639!1
X-Originating-IP: [64.18.0.198]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9492 invoked from network); 4 Nov 2014 13:09:53 -0000
Received: from exprod5og123.obsmtp.com (HELO exprod5og123.obsmtp.com)
	(64.18.0.198)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:53 -0000
Received: from mail-lb0-f177.google.com ([209.85.217.177]) (using TLSv1) by
	exprod5ob123.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQHrQMaw/7wli1Y2ATJ27H8UrewXJJ@postini.com;
	Tue, 04 Nov 2014 05:09:52 PST
Received: by mail-lb0-f177.google.com with SMTP id z12so2592659lbi.22
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=l02k0VbBuycAQpC6lsV21eSs8rvICA4r7aL5utBCj3U=;
	b=KnMl6siKcl0VR5u6FpQf3RyijOX91L5kMjb0MZNh4MJ8A+VncSLDvsQGz7bcSe7VcK
	hhCdBWPRFkhCJCTPBz9Rrjx9p32dcFpxuRIeTJjvTwxQEYs7Wf7ynpAtevZD9fRyptre
	7vFRgDCWuA7/L2laZOQiNjMX7zxtNZSilI9v4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=l02k0VbBuycAQpC6lsV21eSs8rvICA4r7aL5utBCj3U=;
	b=NH4DRlY2cSk5IaKvU8XCrLi8x5mhi/+kYwjWJZPe4PBSDObLV/ZNRl5WJkymhhXtZb
	RbtYda3ThFrjMiG+OoglbdofLfgsNvIM239xdm1ftkqbcj4fUyClJfzr8tXq+d4r2bqf
	LaVbsPUIcQ8B+bY+33lZEMNPSvGyEIFSRXcIvZIZwr2YtH/ZIimFzcr5l036rTmLKpkc
	2HO20ekdaai2TP6pTLHnD8CzdCFAeZcluBOcLkSD889E7alaVLAvilsDf7X8YMLyRHBH
	A7Osgskyx+SQscKr/iemz8CBC0EeTgfOxGy3jM7AjAPjZk0PGmvDrZPr+rLGSRrNdFIu
	mqlA==
X-Gm-Message-State: ALoCoQlY8Jwsg7uY3Fvbjtl9pVWZRIkJqLCrQf85rq/K2NzKq177PtXgco/gN9i4pFAs8uxXgKa+IV4m9D1Gw9JI3Skt2QDCmtzUci9sJzpnkXqcL2zieGSuaKOD8aNONuHCw4TVX/i8x65oioVdBJmCWqKPuJasfw==
X-Received: by 10.112.139.196 with SMTP id ra4mr21230135lbb.95.1415106589216; 
	Tue, 04 Nov 2014 05:09:49 -0800 (PST)
X-Received: by 10.112.139.196 with SMTP id ra4mr21230122lbb.95.1415106589146; 
	Tue, 04 Nov 2014 05:09:49 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id sd10sm158751lbb.8.2014.11.04.05.09.47
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:48 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:28 +0200
Message-Id: <1415106572-3178-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 5/9] cpufreq: cpufreq-cpu0: change cpus
	data path in devtree for hwdom kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hypervisor creates standard cpus nodes for virtual cpus.
All information needed for this driver about physical cpus
now located in /hypervisor/pcpus node instead of the
/cpus node in case if kernel is running as hardware domain.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/cpufreq-cpu0.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ef4fbc4..a83838b 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -21,6 +21,8 @@
 #include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 
+#include <xen/xen.h>
+
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
 
@@ -182,7 +184,13 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 	struct device_node *np;
 	int ret;
 
-	np = of_find_node_by_path("/cpus/cpu@0");
+#ifdef CONFIG_XEN_DOM0
+	if (xen_initial_domain())
+		np = of_find_node_by_path("/hypervisor/pcpus/cpu@0");
+	else
+#endif
+		np = of_find_node_by_path("/cpus/cpu@0");
+
 	if (!np) {
 		pr_err("failed to find cpu0 node\n");
 		return -ENOENT;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:10:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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.xen.org>)
	id 1Xlds0-0005Xm-73; Tue, 04 Nov 2014 13:10:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldry-0005Vp-UH
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:59 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9A/B1-09842-620D8545; Tue, 04 Nov 2014 13:09:58 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415106595!4650249!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23525 invoked from network); 4 Nov 2014 13:09:57 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:57 -0000
Received: from mail-lb0-f177.google.com ([209.85.217.177]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQI68yedAHWrwxrdK+OzChIBtzzUqj@postini.com;
	Tue, 04 Nov 2014 05:09:57 PST
Received: by mail-lb0-f177.google.com with SMTP id z12so2665425lbi.36
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=g3prLPODM12AnRCU2EXsG1/H2DA+fj+tOLcjTNgvWYg=;
	b=goe+KnSt/63tD/K98g3Y4Ij1uotoGDbC8t7xJMCK5e9YqPZyeAltglvFjv9MMPSbg8
	GWCxzE4RAdodkn++NqnyKPzjL5Fs2ww5cTWEzXKzYpgX4TA0tusya3qXnqaPM24ZksCQ
	5xA5XmrRUK2SxjPb+EcpURQmUHYlGC4i6EtSM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=g3prLPODM12AnRCU2EXsG1/H2DA+fj+tOLcjTNgvWYg=;
	b=Oizwsr8TxEHgB99CgJwaLTOSU6aCnrSDqcUKR0KmcC/fu94wuR7R6HTvFt2jRYCDIM
	K2UIBFfHPXCFiVzizz8k41JLsbUJbM61GzcAe2V0SEjPnS8n3M5Ql6aXNjCXT6bCVBDl
	ky7xMZfXADXnK+3L6PRhcSHhbkv3hvU29ICjUIYMmtmIqn5LdKCKSu5z4fp8r/9DqY5b
	aM0bMR9zLdqorJswbmxzGAflCHhiIXGB/H2L6cJkoupDnJ5pNj4bLHTPwXwXwNb4H0ep
	TZ3+qSbgrHE0mXXAT1zmvn94yYGAeWMxS1G3yIR5pmxRxnpSrCe2IY+Dqc374aeZFyGt
	bu9w==
X-Gm-Message-State: ALoCoQmCMYUpRUUmqpyUDVDSc0W2YFeUv39yLPj3gtLemsGtaA7MXGXMZgsSBjW7ybdv/OnHh6DTTwiogoIC4rUPO5AoNPbFA/l86l0rXWAf+3w3LyHrdeSLO4rrvO3hN/mAxqxr+Tfcx9SVKwBcrp81OoGZryeERA==
X-Received: by 10.152.36.5 with SMTP id m5mr59071740laj.51.1415106594119;
	Tue, 04 Nov 2014 05:09:54 -0800 (PST)
X-Received: by 10.152.36.5 with SMTP id m5mr59071731laj.51.1415106594059;
	Tue, 04 Nov 2014 05:09:54 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id pr7sm153403lbc.18.2014.11.04.05.09.52
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:53 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:30 +0200
Message-Id: <1415106572-3178-8-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 7/9] cpufreq: make cpufreq low-level
	drivers visible for CPUFREQ_DRV_OPS config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Low-level cpufreq drivers should depend from CPUFREQ_DRV_OPS
config instead of the CPU_FREQ config in case if we want
to use additional high-level cpufreq driver. This patch
is needed for implementation xen-based high-level cpufreq
driver.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/Makefile        |  2 +-
 drivers/cpufreq/Kconfig | 16 ++++++++++++----
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index f8c79ae..58ef715 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -107,7 +107,7 @@ obj-$(CONFIG_ISDN)		+= isdn/
 obj-$(CONFIG_EDAC)		+= edac/
 obj-$(CONFIG_EISA)		+= eisa/
 obj-y				+= lguest/
-obj-$(CONFIG_CPU_FREQ)		+= cpufreq/
+obj-$(CONFIG_CPUFREQ_DRV_OPS)	+= cpufreq/
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle/
 obj-y				+= mmc/
 obj-$(CONFIG_MEMSTICK)		+= memstick/
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 42a1aed..f5a8f84 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -19,14 +19,11 @@ config CPU_FREQ
 
 	  If in doubt, say N.
 
-if CPU_FREQ
+if CPUFREQ_DRV_OPS
 
 config CPU_FREQ_TABLE
 	tristate
 
-config CPU_FREQ_GOV_COMMON
-	bool
-
 config CPU_FREQ_STAT
 	tristate "CPU frequency translation statistics"
 	select CPU_FREQ_TABLE
@@ -49,6 +46,13 @@ config CPU_FREQ_STAT_DETAILS
 
 	  If in doubt, say N.
 
+endif
+
+if CPU_FREQ
+
+config CPU_FREQ_GOV_COMMON
+	bool
+
 choice
 	prompt "Default CPUFreq governor"
 	default CPU_FREQ_DEFAULT_GOV_USERSPACE if CPU_FREQ_SA1100 || CPU_FREQ_SA1110
@@ -188,6 +192,10 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 	  If in doubt, say N.
 
+endif
+
+if CPUFREQ_DRV_OPS
+
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
 	depends on HAVE_CLK && REGULATOR && PM_OPP && OF
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:10:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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.xen.org>)
	id 1Xlds0-0005Xm-73; Tue, 04 Nov 2014 13:10:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldry-0005Vp-UH
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:59 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9A/B1-09842-620D8545; Tue, 04 Nov 2014 13:09:58 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415106595!4650249!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23525 invoked from network); 4 Nov 2014 13:09:57 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:57 -0000
Received: from mail-lb0-f177.google.com ([209.85.217.177]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQI68yedAHWrwxrdK+OzChIBtzzUqj@postini.com;
	Tue, 04 Nov 2014 05:09:57 PST
Received: by mail-lb0-f177.google.com with SMTP id z12so2665425lbi.36
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=g3prLPODM12AnRCU2EXsG1/H2DA+fj+tOLcjTNgvWYg=;
	b=goe+KnSt/63tD/K98g3Y4Ij1uotoGDbC8t7xJMCK5e9YqPZyeAltglvFjv9MMPSbg8
	GWCxzE4RAdodkn++NqnyKPzjL5Fs2ww5cTWEzXKzYpgX4TA0tusya3qXnqaPM24ZksCQ
	5xA5XmrRUK2SxjPb+EcpURQmUHYlGC4i6EtSM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=g3prLPODM12AnRCU2EXsG1/H2DA+fj+tOLcjTNgvWYg=;
	b=Oizwsr8TxEHgB99CgJwaLTOSU6aCnrSDqcUKR0KmcC/fu94wuR7R6HTvFt2jRYCDIM
	K2UIBFfHPXCFiVzizz8k41JLsbUJbM61GzcAe2V0SEjPnS8n3M5Ql6aXNjCXT6bCVBDl
	ky7xMZfXADXnK+3L6PRhcSHhbkv3hvU29ICjUIYMmtmIqn5LdKCKSu5z4fp8r/9DqY5b
	aM0bMR9zLdqorJswbmxzGAflCHhiIXGB/H2L6cJkoupDnJ5pNj4bLHTPwXwXwNb4H0ep
	TZ3+qSbgrHE0mXXAT1zmvn94yYGAeWMxS1G3yIR5pmxRxnpSrCe2IY+Dqc374aeZFyGt
	bu9w==
X-Gm-Message-State: ALoCoQmCMYUpRUUmqpyUDVDSc0W2YFeUv39yLPj3gtLemsGtaA7MXGXMZgsSBjW7ybdv/OnHh6DTTwiogoIC4rUPO5AoNPbFA/l86l0rXWAf+3w3LyHrdeSLO4rrvO3hN/mAxqxr+Tfcx9SVKwBcrp81OoGZryeERA==
X-Received: by 10.152.36.5 with SMTP id m5mr59071740laj.51.1415106594119;
	Tue, 04 Nov 2014 05:09:54 -0800 (PST)
X-Received: by 10.152.36.5 with SMTP id m5mr59071731laj.51.1415106594059;
	Tue, 04 Nov 2014 05:09:54 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id pr7sm153403lbc.18.2014.11.04.05.09.52
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:53 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:30 +0200
Message-Id: <1415106572-3178-8-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 7/9] cpufreq: make cpufreq low-level
	drivers visible for CPUFREQ_DRV_OPS config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Low-level cpufreq drivers should depend from CPUFREQ_DRV_OPS
config instead of the CPU_FREQ config in case if we want
to use additional high-level cpufreq driver. This patch
is needed for implementation xen-based high-level cpufreq
driver.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/Makefile        |  2 +-
 drivers/cpufreq/Kconfig | 16 ++++++++++++----
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index f8c79ae..58ef715 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -107,7 +107,7 @@ obj-$(CONFIG_ISDN)		+= isdn/
 obj-$(CONFIG_EDAC)		+= edac/
 obj-$(CONFIG_EISA)		+= eisa/
 obj-y				+= lguest/
-obj-$(CONFIG_CPU_FREQ)		+= cpufreq/
+obj-$(CONFIG_CPUFREQ_DRV_OPS)	+= cpufreq/
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle/
 obj-y				+= mmc/
 obj-$(CONFIG_MEMSTICK)		+= memstick/
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 42a1aed..f5a8f84 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -19,14 +19,11 @@ config CPU_FREQ
 
 	  If in doubt, say N.
 
-if CPU_FREQ
+if CPUFREQ_DRV_OPS
 
 config CPU_FREQ_TABLE
 	tristate
 
-config CPU_FREQ_GOV_COMMON
-	bool
-
 config CPU_FREQ_STAT
 	tristate "CPU frequency translation statistics"
 	select CPU_FREQ_TABLE
@@ -49,6 +46,13 @@ config CPU_FREQ_STAT_DETAILS
 
 	  If in doubt, say N.
 
+endif
+
+if CPU_FREQ
+
+config CPU_FREQ_GOV_COMMON
+	bool
+
 choice
 	prompt "Default CPUFreq governor"
 	default CPU_FREQ_DEFAULT_GOV_USERSPACE if CPU_FREQ_SA1100 || CPU_FREQ_SA1110
@@ -188,6 +192,10 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 	  If in doubt, say N.
 
+endif
+
+if CPUFREQ_DRV_OPS
+
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
 	depends on HAVE_CLK && REGULATOR && PM_OPP && OF
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:10:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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.xen.org>)
	id 1Xlds0-0005YU-TB; Tue, 04 Nov 2014 13:10:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldrz-0005VZ-Ka
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:59 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C3/A0-29352-620D8545; Tue, 04 Nov 2014 13:09:58 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415106593!11137382!1
X-Originating-IP: [64.18.0.184]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30861 invoked from network); 4 Nov 2014 13:09:55 -0000
Received: from exprod5og107.obsmtp.com (HELO exprod5og107.obsmtp.com)
	(64.18.0.184)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Nov 2014 13:09:55 -0000
Received: from mail-la0-f42.google.com ([209.85.215.42]) (using TLSv1) by
	exprod5ob107.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQIVeJ+H/QXavUVZLdgeB60jHhNwZ2@postini.com;
	Tue, 04 Nov 2014 05:09:55 PST
Received: by mail-la0-f42.google.com with SMTP id gq15so850792lab.1
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=gVJwFOtiAwX5Z9Bpr0eyVz/DyuTpkwU8Hw+q47XTq+s=;
	b=OTDHhYrLYEBbdsgC3W51Uyyz5aI5un7SFtwxKpPumfmfUrecPq5JkfXbC0wQZ8JKHh
	0Ru/rp+laVSR7n4DrtYqY+vcSrc3JMWy0RM+vIu4g8Jo24TwR0ZaB5GxiJvEfjOTrzGK
	Hdr1Po9P7Tz5xooHnDuaj1b4cS877rPs9GA3A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=gVJwFOtiAwX5Z9Bpr0eyVz/DyuTpkwU8Hw+q47XTq+s=;
	b=IXqOqlP1ZRE72JAQPWqkLR0kaT3Iquln4FGSn9F5MbBcriOtyIB+8gyrPcfrU69pJt
	WKRgFZaPmKjbzBUbHkP3llXERb76orwW1V8QWUeJANGsLZ+4vWXoxNocK487G4U8Zqzi
	HcIfB7JkZKEA5ePs5YgO1OsAwUPAjOMGUlG+LK6vivTMV20PjF0FjdIuiY/eep1o+adI
	fAUQgSwK87C6FNBRXyT8tFx1SK7Gn+bkIxfCGCa5eUuhpbkuGobwbviQPmVBJGni18og
	xX41GH1oXn2P5V8I6N1QSBhl1F8RnUevl/31vBUZrrLm+P0gjzzMrQt4RAIBx7Czs26z
	UmQA==
X-Gm-Message-State: ALoCoQlTqRrZmn9zPtamkLnadqNnINURsfgCIXA0nYHtFp8lRP/AUmrowOcalsK7EMlgTmKSkyuZ6r5jMu9ZQadJdR5CKH5U5kAxsfPlHqx9FvTbs0RV/RMF3VYgGgtg3Dy+ZhlIuhmSYEd6JC6IUsh3DOm1Umd+Rw==
X-Received: by 10.152.21.135 with SMTP id v7mr60383432lae.65.1415106591742;
	Tue, 04 Nov 2014 05:09:51 -0800 (PST)
X-Received: by 10.152.21.135 with SMTP id v7mr60383421lae.65.1415106591677;
	Tue, 04 Nov 2014 05:09:51 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id w8sm153174lae.19.2014.11.04.05.09.50
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:50 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:29 +0200
Message-Id: <1415106572-3178-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 6/9] cpufreq: introduce cpufreq_drv_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch allows to use more than one high-level
cpufreq driver. This patch is needed for implementation
xen-based high-level cpufreq driver.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/Kconfig            |   4 +
 drivers/cpufreq/Makefile           |   1 +
 drivers/cpufreq/acpi-cpufreq.c     |   5 +-
 drivers/cpufreq/cpufreq.c          | 116 ++++++++++++-----------
 drivers/cpufreq/cpufreq_drv_ops.c  | 187 +++++++++++++++++++++++++++++++++++++
 drivers/cpufreq/cpufreq_drv_ops.h  |  50 ++++++++++
 drivers/cpufreq/cpufreq_governor.c |   4 +-
 include/linux/cpufreq.h            |   2 +-
 8 files changed, 312 insertions(+), 57 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index cbcb21e..42a1aed 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -1,7 +1,11 @@
 menu "CPU Frequency scaling"
 
+config CPUFREQ_DRV_OPS
+	bool
+
 config CPU_FREQ
 	bool "CPU Frequency scaling"
+	select CPUFREQ_DRV_OPS
 	help
 	  CPU Frequency scaling allows you to change the clock speed of 
 	  CPUs on the fly. This is a nice method to save power, because 
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index fadc4d4..f12a0d3 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -1,5 +1,6 @@
 # CPUfreq core
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
+obj-$(CONFIG_CPUFREQ_DRV_OPS)		+= cpufreq_drv_ops.o
 # CPUfreq stats
 obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
 
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 7b0d49d..2c2a33f 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -950,7 +950,8 @@ static void __init acpi_cpufreq_boost_init(void)
 	/* We create the boost file in any case, though for systems without
 	 * hardware support it will be read-only and hardwired to return 0.
 	 */
-	if (sysfs_create_file(cpufreq_global_kobject, &(global_boost.attr)))
+	if (sysfs_create_file(get_cpufreq_global_kobject(),
+			      &(global_boost.attr)))
 		pr_warn(PFX "could not register global boost sysfs file\n");
 	else
 		pr_debug("registered global boost sysfs file\n");
@@ -958,7 +959,7 @@ static void __init acpi_cpufreq_boost_init(void)
 
 static void __exit acpi_cpufreq_boost_exit(void)
 {
-	sysfs_remove_file(cpufreq_global_kobject, &(global_boost.attr));
+	sysfs_remove_file(get_cpufreq_global_kobject(), &(global_boost.attr));
 
 	if (msrs) {
 		unregister_cpu_notifier(&boost_nb);
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6ed3c13..1b24bc3e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -33,6 +33,7 @@
 #include <linux/syscore_ops.h>
 
 #include <trace/events/power.h>
+#include "cpufreq_drv_ops.h"
 
 /**
  * The "cpufreq driver" - the arch- or hardware-dependent low
@@ -178,11 +179,10 @@ err_out:
 	return NULL;
 }
 
-struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+struct cpufreq_policy *kern_cpufreq_cpu_get(unsigned int cpu)
 {
 	return __cpufreq_cpu_get(cpu, false);
 }
-EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
 
 static struct cpufreq_policy *cpufreq_cpu_get_sysfs(unsigned int cpu)
 {
@@ -196,11 +196,10 @@ static void __cpufreq_cpu_put(struct cpufreq_policy *data, bool sysfs)
 	module_put(cpufreq_driver->owner);
 }
 
-void cpufreq_cpu_put(struct cpufreq_policy *data)
+void kern_cpufreq_cpu_put(struct cpufreq_policy *data)
 {
 	__cpufreq_cpu_put(data, false);
 }
-EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
 
 static void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data)
 {
@@ -258,7 +257,8 @@ static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
  * function. It is called twice on all CPU frequency changes that have
  * external effects.
  */
-void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
+void kern_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
+				    unsigned int state)
 {
 	struct cpufreq_policy *policy;
 
@@ -303,9 +303,6 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
 		break;
 	}
 }
-EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
-
-
 
 /*********************************************************************
  *                          SYSFS INTERFACE                          *
@@ -628,7 +625,10 @@ static struct attribute *default_attrs[] = {
 };
 
 struct kobject *cpufreq_global_kobject;
-EXPORT_SYMBOL(cpufreq_global_kobject);
+struct kobject *get_kern_cpufreq_global_kobject(void)
+{
+	return cpufreq_global_kobject;
+}
 
 #define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
 #define to_attr(a) container_of(a, struct freq_attr, attr)
@@ -1214,7 +1214,7 @@ static void cpufreq_out_of_sync(unsigned int cpu, unsigned int old_freq,
  * This is the last known freq, without actually getting it from the driver.
  * Return value will be same as what is shown in scaling_cur_freq in sysfs.
  */
-unsigned int cpufreq_quick_get(unsigned int cpu)
+unsigned int kern_cpufreq_quick_get(unsigned int cpu)
 {
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
 	unsigned int ret_freq = 0;
@@ -1226,7 +1226,7 @@ unsigned int cpufreq_quick_get(unsigned int cpu)
 
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_quick_get);
+EXPORT_SYMBOL(kern_cpufreq_quick_get);
 
 /**
  * cpufreq_quick_get_max - get the max reported CPU frequency for this CPU
@@ -1234,7 +1234,7 @@ EXPORT_SYMBOL(cpufreq_quick_get);
  *
  * Just return the max possible frequency for a given CPU.
  */
-unsigned int cpufreq_quick_get_max(unsigned int cpu)
+unsigned int kern_cpufreq_quick_get_max(unsigned int cpu)
 {
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
 	unsigned int ret_freq = 0;
@@ -1246,7 +1246,7 @@ unsigned int cpufreq_quick_get_max(unsigned int cpu)
 
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_quick_get_max);
+EXPORT_SYMBOL(kern_cpufreq_quick_get_max);
 
 
 static unsigned int __cpufreq_get(unsigned int cpu)
@@ -1278,7 +1278,7 @@ static unsigned int __cpufreq_get(unsigned int cpu)
  *
  * Get the CPU current (static) CPU frequency
  */
-unsigned int cpufreq_get(unsigned int cpu)
+unsigned int kern_cpufreq_get(unsigned int cpu)
 {
 	unsigned int ret_freq = 0;
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
@@ -1298,7 +1298,7 @@ out_policy:
 out:
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_get);
+EXPORT_SYMBOL(kern_cpufreq_get);
 
 static struct subsys_interface cpufreq_interface = {
 	.name		= "cpufreq",
@@ -1387,26 +1387,25 @@ static struct syscore_ops cpufreq_syscore_ops = {
 };
 
 /**
- *	cpufreq_get_current_driver - return current driver's name
+ *	kern_cpufreq_get_current_driver - return current driver's name
  *
  *	Return the name string of the currently loaded cpufreq driver
  *	or NULL, if none.
  */
-const char *cpufreq_get_current_driver(void)
+const char *kern_cpufreq_get_current_driver(void)
 {
 	if (cpufreq_driver)
 		return cpufreq_driver->name;
 
 	return NULL;
 }
-EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
 
 /*********************************************************************
  *                     NOTIFIER LISTS INTERFACE                      *
  *********************************************************************/
 
 /**
- *	cpufreq_register_notifier - register a driver with cpufreq
+ *	kern_cpufreq_register_notifier - register a driver with cpufreq
  *	@nb: notifier function to register
  *      @list: CPUFREQ_TRANSITION_NOTIFIER or CPUFREQ_POLICY_NOTIFIER
  *
@@ -1418,7 +1417,7 @@ EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
  *	This function may sleep, and has the same return conditions as
  *	blocking_notifier_chain_register.
  */
-int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
+int kern_cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
 {
 	int ret;
 
@@ -1439,11 +1438,11 @@ int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_register_notifier);
+EXPORT_SYMBOL(kern_cpufreq_register_notifier);
 
 
 /**
- *	cpufreq_unregister_notifier - unregister a driver with cpufreq
+ *	kern_cpufreq_unregister_notifier - unregister a driver with cpufreq
  *	@nb: notifier block to be unregistered
  *      @list: CPUFREQ_TRANSITION_NOTIFIER or CPUFREQ_POLICY_NOTIFIER
  *
@@ -1452,7 +1451,8 @@ EXPORT_SYMBOL(cpufreq_register_notifier);
  *	This function may sleep, and has the same return conditions as
  *	blocking_notifier_chain_unregister.
  */
-int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
+int kern_cpufreq_unregister_notifier(struct notifier_block *nb,
+				     unsigned int list)
 {
 	int ret;
 
@@ -1471,7 +1471,7 @@ int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_unregister_notifier);
+EXPORT_SYMBOL(kern_cpufreq_unregister_notifier);
 
 
 /*********************************************************************
@@ -1479,7 +1479,7 @@ EXPORT_SYMBOL(cpufreq_unregister_notifier);
  *********************************************************************/
 
 
-int __cpufreq_driver_target(struct cpufreq_policy *policy,
+int __kern_cpufreq_driver_target(struct cpufreq_policy *policy,
 			    unsigned int target_freq,
 			    unsigned int relation)
 {
@@ -1506,9 +1506,8 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
 
 	return retval;
 }
-EXPORT_SYMBOL_GPL(__cpufreq_driver_target);
 
-int cpufreq_driver_target(struct cpufreq_policy *policy,
+int kern_cpufreq_driver_target(struct cpufreq_policy *policy,
 			  unsigned int target_freq,
 			  unsigned int relation)
 {
@@ -1530,9 +1529,9 @@ fail:
 no_policy:
 	return ret;
 }
-EXPORT_SYMBOL_GPL(cpufreq_driver_target);
 
-int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
+int __kern_cpufreq_driver_getavg(struct cpufreq_policy *policy,
+				 unsigned int cpu)
 {
 	int ret = 0;
 
@@ -1548,7 +1547,6 @@ int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
 	cpufreq_cpu_put(policy);
 	return ret;
 }
-EXPORT_SYMBOL_GPL(__cpufreq_driver_getavg);
 
 /*
  * when "event" is CPUFREQ_GOV_LIMITS
@@ -1602,7 +1600,7 @@ static int __cpufreq_governor(struct cpufreq_policy *policy,
 }
 
 
-int cpufreq_register_governor(struct cpufreq_governor *governor)
+int kern_cpufreq_register_governor(struct cpufreq_governor *governor)
 {
 	int err;
 
@@ -1623,10 +1621,8 @@ int cpufreq_register_governor(struct cpufreq_governor *governor)
 	mutex_unlock(&cpufreq_governor_mutex);
 	return err;
 }
-EXPORT_SYMBOL_GPL(cpufreq_register_governor);
-
 
-void cpufreq_unregister_governor(struct cpufreq_governor *governor)
+void kern_cpufreq_unregister_governor(struct cpufreq_governor *governor)
 {
 #ifdef CONFIG_HOTPLUG_CPU
 	int cpu;
@@ -1652,22 +1648,19 @@ void cpufreq_unregister_governor(struct cpufreq_governor *governor)
 	mutex_unlock(&cpufreq_governor_mutex);
 	return;
 }
-EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
-
-
 
 /*********************************************************************
  *                          POLICY INTERFACE                         *
  *********************************************************************/
 
 /**
- * cpufreq_get_policy - get the current cpufreq_policy
+ * kern_cpufreq_get_policy - get the current cpufreq_policy
  * @policy: struct cpufreq_policy into which the current cpufreq_policy
  *	is written
  *
  * Reads the current cpufreq policy.
  */
-int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
+int kern_cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
 {
 	struct cpufreq_policy *cpu_policy;
 	if (!policy)
@@ -1682,7 +1675,7 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
 	cpufreq_cpu_put(cpu_policy);
 	return 0;
 }
-EXPORT_SYMBOL(cpufreq_get_policy);
+EXPORT_SYMBOL(kern_cpufreq_get_policy);
 
 
 /*
@@ -1774,13 +1767,13 @@ error_out:
 }
 
 /**
- *	cpufreq_update_policy - re-evaluate an existing cpufreq policy
+ *	kern_cpufreq_update_policy - re-evaluate an existing cpufreq policy
  *	@cpu: CPU which shall be re-evaluated
  *
  *	Useful for policy notifiers which have different necessities
  *	at different times.
  */
-int cpufreq_update_policy(unsigned int cpu)
+int kern_cpufreq_update_policy(unsigned int cpu)
 {
 	struct cpufreq_policy *data = cpufreq_cpu_get(cpu);
 	struct cpufreq_policy policy;
@@ -1826,7 +1819,7 @@ fail:
 no_policy:
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_update_policy);
+EXPORT_SYMBOL(kern_cpufreq_update_policy);
 
 static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb,
 					unsigned long action, void *hcpu)
@@ -1866,7 +1859,7 @@ static struct notifier_block __refdata cpufreq_cpu_notifier = {
  *********************************************************************/
 
 /**
- * cpufreq_register_driver - register a CPU Frequency driver
+ * kern_cpufreq_register_driver - register a CPU Frequency driver
  * @driver_data: A struct cpufreq_driver containing the values#
  * submitted by the CPU Frequency driver.
  *
@@ -1875,7 +1868,7 @@ static struct notifier_block __refdata cpufreq_cpu_notifier = {
  * (and isn't unregistered in the meantime).
  *
  */
-int cpufreq_register_driver(struct cpufreq_driver *driver_data)
+int kern_cpufreq_register_driver(struct cpufreq_driver *driver_data)
 {
 	unsigned long flags;
 	int ret;
@@ -1935,18 +1928,16 @@ err_null_driver:
 	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
 	return ret;
 }
-EXPORT_SYMBOL_GPL(cpufreq_register_driver);
-
 
 /**
- * cpufreq_unregister_driver - unregister the current CPUFreq driver
+ * kern_cpufreq_unregister_driver - unregister the current CPUFreq driver
  *
  *    Unregister the current CPUFreq driver. Only call this if you have
  * the right to do so, i.e. if you have succeeded in initialising before!
  * Returns zero if successful, and -EINVAL if the cpufreq_driver is
  * currently not initialised.
  */
-int cpufreq_unregister_driver(struct cpufreq_driver *driver)
+int kern_cpufreq_unregister_driver(struct cpufreq_driver *driver)
 {
 	unsigned long flags;
 
@@ -1964,9 +1955,30 @@ int cpufreq_unregister_driver(struct cpufreq_driver *driver)
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
 
-static int __init cpufreq_core_init(void)
+struct cpufreq_drv_ops kern_cpufreq_drv_ops = {
+	.get_global_kobject = get_kern_cpufreq_global_kobject,
+	.cpu_get = kern_cpufreq_cpu_get,
+	.cpu_put = kern_cpufreq_cpu_put,
+	.notify_transition = kern_cpufreq_notify_transition,
+	.quick_get = kern_cpufreq_quick_get,
+	.quick_get_max = kern_cpufreq_quick_get_max,
+	.get = kern_cpufreq_get,
+	.register_notifier = kern_cpufreq_register_notifier,
+	.unregister_notifier = kern_cpufreq_unregister_notifier,
+	.get_current_driver = kern_cpufreq_get_current_driver,
+	.__driver_target = __kern_cpufreq_driver_target,
+	.driver_target = kern_cpufreq_driver_target,
+	.__driver_getavg = __kern_cpufreq_driver_getavg,
+	.register_governor = kern_cpufreq_register_governor,
+	.unregister_governor = kern_cpufreq_unregister_governor,
+	.get_policy = kern_cpufreq_get_policy,
+	.update_policy = kern_cpufreq_update_policy,
+	.register_driver = kern_cpufreq_register_driver,
+	.unregister_driver = kern_cpufreq_unregister_driver,
+};
+
+static int __init kern_cpufreq_core_init(void)
 {
 	int cpu;
 
@@ -1984,4 +1996,4 @@ static int __init cpufreq_core_init(void)
 
 	return 0;
 }
-core_initcall(cpufreq_core_init);
+core_initcall(kern_cpufreq_core_init);
diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
new file mode 100644
index 0000000..c971442
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_drv_ops.c
@@ -0,0 +1,187 @@
+/*
+ *  Copyright (C) 2014 GlobalLogic 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include "cpufreq_drv_ops.h"
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/export.h>
+
+static struct cpufreq_drv_ops *ops;
+
+struct kobject *get_cpufreq_global_kobject(void)
+{
+	if (ops && ops->get_global_kobject)
+		return ops->get_global_kobject();
+	return NULL;
+}
+EXPORT_SYMBOL(get_cpufreq_global_kobject);
+
+struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+{
+	if (ops && ops->cpu_get)
+		return ops->cpu_get(cpu);
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
+
+void cpufreq_cpu_put(struct cpufreq_policy *data)
+{
+	if (ops && ops->cpu_put)
+		ops->cpu_put(data);
+}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
+
+void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
+{
+	if (ops && ops->notify_transition)
+		ops->notify_transition(freqs, state);
+}
+EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
+
+#ifdef CONFIG_CPU_FREQ
+unsigned int cpufreq_quick_get(unsigned int cpu)
+{
+	if (ops && ops->quick_get)
+		return ops->quick_get(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_quick_get);
+
+unsigned int cpufreq_quick_get_max(unsigned int cpu)
+{
+	if (ops && ops->quick_get_max)
+		return ops->quick_get_max(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_quick_get_max);
+
+unsigned int cpufreq_get(unsigned int cpu)
+{
+	if (ops && ops->get)
+		return ops->get(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_get);
+
+int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
+{
+	if (ops && ops->register_notifier)
+		return ops->register_notifier(nb, list);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_register_notifier);
+
+int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
+{
+	if (ops && ops->unregister_notifier)
+		return ops->unregister_notifier(nb, list);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_unregister_notifier);
+#endif
+
+const char *cpufreq_get_current_driver(void)
+{
+	if (ops && ops->get_current_driver)
+		return ops->get_current_driver();
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
+
+int __cpufreq_driver_target(struct cpufreq_policy *policy,
+			    unsigned int target_freq,
+			    unsigned int relation)
+{
+	if (ops && ops->__driver_target)
+		return ops->__driver_target(policy, target_freq, relation);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(__cpufreq_driver_target);
+
+int cpufreq_driver_target(struct cpufreq_policy *policy,
+			  unsigned int target_freq,
+			  unsigned int relation)
+{
+	if (ops && ops->driver_target)
+		return ops->driver_target(policy, target_freq, relation);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_driver_target);
+
+int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
+{
+	if (ops && ops->__driver_getavg)
+		return ops->__driver_getavg(policy, cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(__cpufreq_driver_getavg);
+
+int cpufreq_register_governor(struct cpufreq_governor *governor)
+{
+	if (ops && ops->register_governor)
+		return ops->register_governor(governor);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_register_governor);
+
+void cpufreq_unregister_governor(struct cpufreq_governor *governor)
+{
+	if (ops && ops->unregister_governor)
+		ops->unregister_governor(governor);
+}
+EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
+
+int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
+{
+	if (ops && ops->get_policy)
+		return ops->get_policy(policy, cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_get_policy);
+
+int cpufreq_update_policy(unsigned int cpu)
+{
+	if (ops && ops->update_policy)
+		return ops->update_policy(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_update_policy);
+
+int cpufreq_register_driver(struct cpufreq_driver *driver_data)
+{
+	if (ops && ops->register_driver)
+		return ops->register_driver(driver_data);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_register_driver);
+
+int cpufreq_unregister_driver(struct cpufreq_driver *driver)
+{
+	if (ops && ops->unregister_driver)
+		return ops->unregister_driver(driver);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
+
+static int __init cpufreq_drv_ops_init(void)
+{
+#ifdef CONFIG_CPU_FREQ
+	ops = &kern_cpufreq_drv_ops;
+	pr_debug("using kern_cpufreq_drv_ops\n");
+#endif
+
+	return 0;
+}
+core_initcall(cpufreq_drv_ops_init);
diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
new file mode 100644
index 0000000..5cc8e05
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_drv_ops.h
@@ -0,0 +1,50 @@
+/*
+ *  Copyright (C) 2014 GlobalLogic 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.
+ */
+
+#ifndef _CPUFREQ_DRV_OPS_H
+#define _CPUFREQ_DRV_OPS_H
+
+#include <linux/types.h>
+#include <linux/cpufreq.h>
+
+struct cpufreq_drv_ops {
+	struct kobject *(*get_global_kobject)(void);
+	struct cpufreq_policy *(*cpu_get)(unsigned int);
+	void (*cpu_put)(struct cpufreq_policy *);
+	void (*notify_transition)(struct cpufreq_freqs *, unsigned int);
+#ifdef CONFIG_CPU_FREQ
+	unsigned int (*quick_get)(unsigned int);
+	unsigned int (*quick_get_max)(unsigned int);
+	unsigned int (*get)(unsigned int);
+	int (*register_notifier)(struct notifier_block *, unsigned int);
+	int (*unregister_notifier)(struct notifier_block *, unsigned int);
+#endif
+	const char *(*get_current_driver)(void);
+	int (*__driver_target)(struct cpufreq_policy *,
+			       unsigned int, unsigned int);
+	int (*driver_target)(struct cpufreq_policy *,
+			     unsigned int, unsigned int);
+	int (*__driver_getavg)(struct cpufreq_policy *, unsigned int);
+	int (*register_governor)(struct cpufreq_governor *);
+	void (*unregister_governor)(struct cpufreq_governor *);
+	int (*get_policy)(struct cpufreq_policy *, unsigned int);
+	int (*update_policy)(unsigned int);
+	int (*register_driver)(struct cpufreq_driver *);
+	int (*unregister_driver)(struct cpufreq_driver *);
+};
+
+#ifdef CONFIG_CPU_FREQ
+extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
+#endif
+
+#endif /* _CPUFREQ_DRV_OPS_H */
diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 6c5f1d3..731fa0d 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -226,7 +226,7 @@ int cpufreq_governor_dbs(struct dbs_data *dbs_data,
 		if (dbs_data->enable != 1)
 			goto second_time;
 
-		rc = sysfs_create_group(cpufreq_global_kobject,
+		rc = sysfs_create_group(get_cpufreq_global_kobject(),
 				dbs_data->attr_group);
 		if (rc) {
 			mutex_unlock(&dbs_data->mutex);
@@ -291,7 +291,7 @@ second_time:
 		if (!dbs_data->enable) {
 			struct cs_ops *ops = dbs_data->gov_ops;
 
-			sysfs_remove_group(cpufreq_global_kobject,
+			sysfs_remove_group(get_cpufreq_global_kobject(),
 					dbs_data->attr_group);
 			if (dbs_data->governor == GOV_CONSERVATIVE)
 				cpufreq_unregister_notifier(ops->notifier_block,
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 3d919ea..2852bb23 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -70,7 +70,7 @@ static inline void disable_cpufreq(void) { }
 struct cpufreq_governor;
 
 /* /sys/devices/system/cpu/cpufreq: entry point for global variables */
-extern struct kobject *cpufreq_global_kobject;
+struct kobject *get_cpufreq_global_kobject(void);
 
 #define CPUFREQ_ETERNAL			(-1)
 struct cpufreq_cpuinfo {
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:10:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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.xen.org>)
	id 1Xlds0-0005YU-TB; Tue, 04 Nov 2014 13:10:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xldrz-0005VZ-Ka
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:09:59 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C3/A0-29352-620D8545; Tue, 04 Nov 2014 13:09:58 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415106593!11137382!1
X-Originating-IP: [64.18.0.184]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30861 invoked from network); 4 Nov 2014 13:09:55 -0000
Received: from exprod5og107.obsmtp.com (HELO exprod5og107.obsmtp.com)
	(64.18.0.184)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Nov 2014 13:09:55 -0000
Received: from mail-la0-f42.google.com ([209.85.215.42]) (using TLSv1) by
	exprod5ob107.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQIVeJ+H/QXavUVZLdgeB60jHhNwZ2@postini.com;
	Tue, 04 Nov 2014 05:09:55 PST
Received: by mail-la0-f42.google.com with SMTP id gq15so850792lab.1
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=gVJwFOtiAwX5Z9Bpr0eyVz/DyuTpkwU8Hw+q47XTq+s=;
	b=OTDHhYrLYEBbdsgC3W51Uyyz5aI5un7SFtwxKpPumfmfUrecPq5JkfXbC0wQZ8JKHh
	0Ru/rp+laVSR7n4DrtYqY+vcSrc3JMWy0RM+vIu4g8Jo24TwR0ZaB5GxiJvEfjOTrzGK
	Hdr1Po9P7Tz5xooHnDuaj1b4cS877rPs9GA3A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=gVJwFOtiAwX5Z9Bpr0eyVz/DyuTpkwU8Hw+q47XTq+s=;
	b=IXqOqlP1ZRE72JAQPWqkLR0kaT3Iquln4FGSn9F5MbBcriOtyIB+8gyrPcfrU69pJt
	WKRgFZaPmKjbzBUbHkP3llXERb76orwW1V8QWUeJANGsLZ+4vWXoxNocK487G4U8Zqzi
	HcIfB7JkZKEA5ePs5YgO1OsAwUPAjOMGUlG+LK6vivTMV20PjF0FjdIuiY/eep1o+adI
	fAUQgSwK87C6FNBRXyT8tFx1SK7Gn+bkIxfCGCa5eUuhpbkuGobwbviQPmVBJGni18og
	xX41GH1oXn2P5V8I6N1QSBhl1F8RnUevl/31vBUZrrLm+P0gjzzMrQt4RAIBx7Czs26z
	UmQA==
X-Gm-Message-State: ALoCoQlTqRrZmn9zPtamkLnadqNnINURsfgCIXA0nYHtFp8lRP/AUmrowOcalsK7EMlgTmKSkyuZ6r5jMu9ZQadJdR5CKH5U5kAxsfPlHqx9FvTbs0RV/RMF3VYgGgtg3Dy+ZhlIuhmSYEd6JC6IUsh3DOm1Umd+Rw==
X-Received: by 10.152.21.135 with SMTP id v7mr60383432lae.65.1415106591742;
	Tue, 04 Nov 2014 05:09:51 -0800 (PST)
X-Received: by 10.152.21.135 with SMTP id v7mr60383421lae.65.1415106591677;
	Tue, 04 Nov 2014 05:09:51 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id w8sm153174lae.19.2014.11.04.05.09.50
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:50 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:29 +0200
Message-Id: <1415106572-3178-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 6/9] cpufreq: introduce cpufreq_drv_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch allows to use more than one high-level
cpufreq driver. This patch is needed for implementation
xen-based high-level cpufreq driver.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/Kconfig            |   4 +
 drivers/cpufreq/Makefile           |   1 +
 drivers/cpufreq/acpi-cpufreq.c     |   5 +-
 drivers/cpufreq/cpufreq.c          | 116 ++++++++++++-----------
 drivers/cpufreq/cpufreq_drv_ops.c  | 187 +++++++++++++++++++++++++++++++++++++
 drivers/cpufreq/cpufreq_drv_ops.h  |  50 ++++++++++
 drivers/cpufreq/cpufreq_governor.c |   4 +-
 include/linux/cpufreq.h            |   2 +-
 8 files changed, 312 insertions(+), 57 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index cbcb21e..42a1aed 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -1,7 +1,11 @@
 menu "CPU Frequency scaling"
 
+config CPUFREQ_DRV_OPS
+	bool
+
 config CPU_FREQ
 	bool "CPU Frequency scaling"
+	select CPUFREQ_DRV_OPS
 	help
 	  CPU Frequency scaling allows you to change the clock speed of 
 	  CPUs on the fly. This is a nice method to save power, because 
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index fadc4d4..f12a0d3 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -1,5 +1,6 @@
 # CPUfreq core
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
+obj-$(CONFIG_CPUFREQ_DRV_OPS)		+= cpufreq_drv_ops.o
 # CPUfreq stats
 obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
 
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 7b0d49d..2c2a33f 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -950,7 +950,8 @@ static void __init acpi_cpufreq_boost_init(void)
 	/* We create the boost file in any case, though for systems without
 	 * hardware support it will be read-only and hardwired to return 0.
 	 */
-	if (sysfs_create_file(cpufreq_global_kobject, &(global_boost.attr)))
+	if (sysfs_create_file(get_cpufreq_global_kobject(),
+			      &(global_boost.attr)))
 		pr_warn(PFX "could not register global boost sysfs file\n");
 	else
 		pr_debug("registered global boost sysfs file\n");
@@ -958,7 +959,7 @@ static void __init acpi_cpufreq_boost_init(void)
 
 static void __exit acpi_cpufreq_boost_exit(void)
 {
-	sysfs_remove_file(cpufreq_global_kobject, &(global_boost.attr));
+	sysfs_remove_file(get_cpufreq_global_kobject(), &(global_boost.attr));
 
 	if (msrs) {
 		unregister_cpu_notifier(&boost_nb);
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6ed3c13..1b24bc3e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -33,6 +33,7 @@
 #include <linux/syscore_ops.h>
 
 #include <trace/events/power.h>
+#include "cpufreq_drv_ops.h"
 
 /**
  * The "cpufreq driver" - the arch- or hardware-dependent low
@@ -178,11 +179,10 @@ err_out:
 	return NULL;
 }
 
-struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+struct cpufreq_policy *kern_cpufreq_cpu_get(unsigned int cpu)
 {
 	return __cpufreq_cpu_get(cpu, false);
 }
-EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
 
 static struct cpufreq_policy *cpufreq_cpu_get_sysfs(unsigned int cpu)
 {
@@ -196,11 +196,10 @@ static void __cpufreq_cpu_put(struct cpufreq_policy *data, bool sysfs)
 	module_put(cpufreq_driver->owner);
 }
 
-void cpufreq_cpu_put(struct cpufreq_policy *data)
+void kern_cpufreq_cpu_put(struct cpufreq_policy *data)
 {
 	__cpufreq_cpu_put(data, false);
 }
-EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
 
 static void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data)
 {
@@ -258,7 +257,8 @@ static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
  * function. It is called twice on all CPU frequency changes that have
  * external effects.
  */
-void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
+void kern_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
+				    unsigned int state)
 {
 	struct cpufreq_policy *policy;
 
@@ -303,9 +303,6 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
 		break;
 	}
 }
-EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
-
-
 
 /*********************************************************************
  *                          SYSFS INTERFACE                          *
@@ -628,7 +625,10 @@ static struct attribute *default_attrs[] = {
 };
 
 struct kobject *cpufreq_global_kobject;
-EXPORT_SYMBOL(cpufreq_global_kobject);
+struct kobject *get_kern_cpufreq_global_kobject(void)
+{
+	return cpufreq_global_kobject;
+}
 
 #define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
 #define to_attr(a) container_of(a, struct freq_attr, attr)
@@ -1214,7 +1214,7 @@ static void cpufreq_out_of_sync(unsigned int cpu, unsigned int old_freq,
  * This is the last known freq, without actually getting it from the driver.
  * Return value will be same as what is shown in scaling_cur_freq in sysfs.
  */
-unsigned int cpufreq_quick_get(unsigned int cpu)
+unsigned int kern_cpufreq_quick_get(unsigned int cpu)
 {
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
 	unsigned int ret_freq = 0;
@@ -1226,7 +1226,7 @@ unsigned int cpufreq_quick_get(unsigned int cpu)
 
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_quick_get);
+EXPORT_SYMBOL(kern_cpufreq_quick_get);
 
 /**
  * cpufreq_quick_get_max - get the max reported CPU frequency for this CPU
@@ -1234,7 +1234,7 @@ EXPORT_SYMBOL(cpufreq_quick_get);
  *
  * Just return the max possible frequency for a given CPU.
  */
-unsigned int cpufreq_quick_get_max(unsigned int cpu)
+unsigned int kern_cpufreq_quick_get_max(unsigned int cpu)
 {
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
 	unsigned int ret_freq = 0;
@@ -1246,7 +1246,7 @@ unsigned int cpufreq_quick_get_max(unsigned int cpu)
 
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_quick_get_max);
+EXPORT_SYMBOL(kern_cpufreq_quick_get_max);
 
 
 static unsigned int __cpufreq_get(unsigned int cpu)
@@ -1278,7 +1278,7 @@ static unsigned int __cpufreq_get(unsigned int cpu)
  *
  * Get the CPU current (static) CPU frequency
  */
-unsigned int cpufreq_get(unsigned int cpu)
+unsigned int kern_cpufreq_get(unsigned int cpu)
 {
 	unsigned int ret_freq = 0;
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
@@ -1298,7 +1298,7 @@ out_policy:
 out:
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_get);
+EXPORT_SYMBOL(kern_cpufreq_get);
 
 static struct subsys_interface cpufreq_interface = {
 	.name		= "cpufreq",
@@ -1387,26 +1387,25 @@ static struct syscore_ops cpufreq_syscore_ops = {
 };
 
 /**
- *	cpufreq_get_current_driver - return current driver's name
+ *	kern_cpufreq_get_current_driver - return current driver's name
  *
  *	Return the name string of the currently loaded cpufreq driver
  *	or NULL, if none.
  */
-const char *cpufreq_get_current_driver(void)
+const char *kern_cpufreq_get_current_driver(void)
 {
 	if (cpufreq_driver)
 		return cpufreq_driver->name;
 
 	return NULL;
 }
-EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
 
 /*********************************************************************
  *                     NOTIFIER LISTS INTERFACE                      *
  *********************************************************************/
 
 /**
- *	cpufreq_register_notifier - register a driver with cpufreq
+ *	kern_cpufreq_register_notifier - register a driver with cpufreq
  *	@nb: notifier function to register
  *      @list: CPUFREQ_TRANSITION_NOTIFIER or CPUFREQ_POLICY_NOTIFIER
  *
@@ -1418,7 +1417,7 @@ EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
  *	This function may sleep, and has the same return conditions as
  *	blocking_notifier_chain_register.
  */
-int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
+int kern_cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
 {
 	int ret;
 
@@ -1439,11 +1438,11 @@ int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_register_notifier);
+EXPORT_SYMBOL(kern_cpufreq_register_notifier);
 
 
 /**
- *	cpufreq_unregister_notifier - unregister a driver with cpufreq
+ *	kern_cpufreq_unregister_notifier - unregister a driver with cpufreq
  *	@nb: notifier block to be unregistered
  *      @list: CPUFREQ_TRANSITION_NOTIFIER or CPUFREQ_POLICY_NOTIFIER
  *
@@ -1452,7 +1451,8 @@ EXPORT_SYMBOL(cpufreq_register_notifier);
  *	This function may sleep, and has the same return conditions as
  *	blocking_notifier_chain_unregister.
  */
-int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
+int kern_cpufreq_unregister_notifier(struct notifier_block *nb,
+				     unsigned int list)
 {
 	int ret;
 
@@ -1471,7 +1471,7 @@ int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_unregister_notifier);
+EXPORT_SYMBOL(kern_cpufreq_unregister_notifier);
 
 
 /*********************************************************************
@@ -1479,7 +1479,7 @@ EXPORT_SYMBOL(cpufreq_unregister_notifier);
  *********************************************************************/
 
 
-int __cpufreq_driver_target(struct cpufreq_policy *policy,
+int __kern_cpufreq_driver_target(struct cpufreq_policy *policy,
 			    unsigned int target_freq,
 			    unsigned int relation)
 {
@@ -1506,9 +1506,8 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
 
 	return retval;
 }
-EXPORT_SYMBOL_GPL(__cpufreq_driver_target);
 
-int cpufreq_driver_target(struct cpufreq_policy *policy,
+int kern_cpufreq_driver_target(struct cpufreq_policy *policy,
 			  unsigned int target_freq,
 			  unsigned int relation)
 {
@@ -1530,9 +1529,9 @@ fail:
 no_policy:
 	return ret;
 }
-EXPORT_SYMBOL_GPL(cpufreq_driver_target);
 
-int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
+int __kern_cpufreq_driver_getavg(struct cpufreq_policy *policy,
+				 unsigned int cpu)
 {
 	int ret = 0;
 
@@ -1548,7 +1547,6 @@ int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
 	cpufreq_cpu_put(policy);
 	return ret;
 }
-EXPORT_SYMBOL_GPL(__cpufreq_driver_getavg);
 
 /*
  * when "event" is CPUFREQ_GOV_LIMITS
@@ -1602,7 +1600,7 @@ static int __cpufreq_governor(struct cpufreq_policy *policy,
 }
 
 
-int cpufreq_register_governor(struct cpufreq_governor *governor)
+int kern_cpufreq_register_governor(struct cpufreq_governor *governor)
 {
 	int err;
 
@@ -1623,10 +1621,8 @@ int cpufreq_register_governor(struct cpufreq_governor *governor)
 	mutex_unlock(&cpufreq_governor_mutex);
 	return err;
 }
-EXPORT_SYMBOL_GPL(cpufreq_register_governor);
-
 
-void cpufreq_unregister_governor(struct cpufreq_governor *governor)
+void kern_cpufreq_unregister_governor(struct cpufreq_governor *governor)
 {
 #ifdef CONFIG_HOTPLUG_CPU
 	int cpu;
@@ -1652,22 +1648,19 @@ void cpufreq_unregister_governor(struct cpufreq_governor *governor)
 	mutex_unlock(&cpufreq_governor_mutex);
 	return;
 }
-EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
-
-
 
 /*********************************************************************
  *                          POLICY INTERFACE                         *
  *********************************************************************/
 
 /**
- * cpufreq_get_policy - get the current cpufreq_policy
+ * kern_cpufreq_get_policy - get the current cpufreq_policy
  * @policy: struct cpufreq_policy into which the current cpufreq_policy
  *	is written
  *
  * Reads the current cpufreq policy.
  */
-int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
+int kern_cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
 {
 	struct cpufreq_policy *cpu_policy;
 	if (!policy)
@@ -1682,7 +1675,7 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
 	cpufreq_cpu_put(cpu_policy);
 	return 0;
 }
-EXPORT_SYMBOL(cpufreq_get_policy);
+EXPORT_SYMBOL(kern_cpufreq_get_policy);
 
 
 /*
@@ -1774,13 +1767,13 @@ error_out:
 }
 
 /**
- *	cpufreq_update_policy - re-evaluate an existing cpufreq policy
+ *	kern_cpufreq_update_policy - re-evaluate an existing cpufreq policy
  *	@cpu: CPU which shall be re-evaluated
  *
  *	Useful for policy notifiers which have different necessities
  *	at different times.
  */
-int cpufreq_update_policy(unsigned int cpu)
+int kern_cpufreq_update_policy(unsigned int cpu)
 {
 	struct cpufreq_policy *data = cpufreq_cpu_get(cpu);
 	struct cpufreq_policy policy;
@@ -1826,7 +1819,7 @@ fail:
 no_policy:
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_update_policy);
+EXPORT_SYMBOL(kern_cpufreq_update_policy);
 
 static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb,
 					unsigned long action, void *hcpu)
@@ -1866,7 +1859,7 @@ static struct notifier_block __refdata cpufreq_cpu_notifier = {
  *********************************************************************/
 
 /**
- * cpufreq_register_driver - register a CPU Frequency driver
+ * kern_cpufreq_register_driver - register a CPU Frequency driver
  * @driver_data: A struct cpufreq_driver containing the values#
  * submitted by the CPU Frequency driver.
  *
@@ -1875,7 +1868,7 @@ static struct notifier_block __refdata cpufreq_cpu_notifier = {
  * (and isn't unregistered in the meantime).
  *
  */
-int cpufreq_register_driver(struct cpufreq_driver *driver_data)
+int kern_cpufreq_register_driver(struct cpufreq_driver *driver_data)
 {
 	unsigned long flags;
 	int ret;
@@ -1935,18 +1928,16 @@ err_null_driver:
 	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
 	return ret;
 }
-EXPORT_SYMBOL_GPL(cpufreq_register_driver);
-
 
 /**
- * cpufreq_unregister_driver - unregister the current CPUFreq driver
+ * kern_cpufreq_unregister_driver - unregister the current CPUFreq driver
  *
  *    Unregister the current CPUFreq driver. Only call this if you have
  * the right to do so, i.e. if you have succeeded in initialising before!
  * Returns zero if successful, and -EINVAL if the cpufreq_driver is
  * currently not initialised.
  */
-int cpufreq_unregister_driver(struct cpufreq_driver *driver)
+int kern_cpufreq_unregister_driver(struct cpufreq_driver *driver)
 {
 	unsigned long flags;
 
@@ -1964,9 +1955,30 @@ int cpufreq_unregister_driver(struct cpufreq_driver *driver)
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
 
-static int __init cpufreq_core_init(void)
+struct cpufreq_drv_ops kern_cpufreq_drv_ops = {
+	.get_global_kobject = get_kern_cpufreq_global_kobject,
+	.cpu_get = kern_cpufreq_cpu_get,
+	.cpu_put = kern_cpufreq_cpu_put,
+	.notify_transition = kern_cpufreq_notify_transition,
+	.quick_get = kern_cpufreq_quick_get,
+	.quick_get_max = kern_cpufreq_quick_get_max,
+	.get = kern_cpufreq_get,
+	.register_notifier = kern_cpufreq_register_notifier,
+	.unregister_notifier = kern_cpufreq_unregister_notifier,
+	.get_current_driver = kern_cpufreq_get_current_driver,
+	.__driver_target = __kern_cpufreq_driver_target,
+	.driver_target = kern_cpufreq_driver_target,
+	.__driver_getavg = __kern_cpufreq_driver_getavg,
+	.register_governor = kern_cpufreq_register_governor,
+	.unregister_governor = kern_cpufreq_unregister_governor,
+	.get_policy = kern_cpufreq_get_policy,
+	.update_policy = kern_cpufreq_update_policy,
+	.register_driver = kern_cpufreq_register_driver,
+	.unregister_driver = kern_cpufreq_unregister_driver,
+};
+
+static int __init kern_cpufreq_core_init(void)
 {
 	int cpu;
 
@@ -1984,4 +1996,4 @@ static int __init cpufreq_core_init(void)
 
 	return 0;
 }
-core_initcall(cpufreq_core_init);
+core_initcall(kern_cpufreq_core_init);
diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
new file mode 100644
index 0000000..c971442
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_drv_ops.c
@@ -0,0 +1,187 @@
+/*
+ *  Copyright (C) 2014 GlobalLogic 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include "cpufreq_drv_ops.h"
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/export.h>
+
+static struct cpufreq_drv_ops *ops;
+
+struct kobject *get_cpufreq_global_kobject(void)
+{
+	if (ops && ops->get_global_kobject)
+		return ops->get_global_kobject();
+	return NULL;
+}
+EXPORT_SYMBOL(get_cpufreq_global_kobject);
+
+struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+{
+	if (ops && ops->cpu_get)
+		return ops->cpu_get(cpu);
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
+
+void cpufreq_cpu_put(struct cpufreq_policy *data)
+{
+	if (ops && ops->cpu_put)
+		ops->cpu_put(data);
+}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
+
+void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
+{
+	if (ops && ops->notify_transition)
+		ops->notify_transition(freqs, state);
+}
+EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
+
+#ifdef CONFIG_CPU_FREQ
+unsigned int cpufreq_quick_get(unsigned int cpu)
+{
+	if (ops && ops->quick_get)
+		return ops->quick_get(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_quick_get);
+
+unsigned int cpufreq_quick_get_max(unsigned int cpu)
+{
+	if (ops && ops->quick_get_max)
+		return ops->quick_get_max(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_quick_get_max);
+
+unsigned int cpufreq_get(unsigned int cpu)
+{
+	if (ops && ops->get)
+		return ops->get(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_get);
+
+int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
+{
+	if (ops && ops->register_notifier)
+		return ops->register_notifier(nb, list);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_register_notifier);
+
+int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
+{
+	if (ops && ops->unregister_notifier)
+		return ops->unregister_notifier(nb, list);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_unregister_notifier);
+#endif
+
+const char *cpufreq_get_current_driver(void)
+{
+	if (ops && ops->get_current_driver)
+		return ops->get_current_driver();
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
+
+int __cpufreq_driver_target(struct cpufreq_policy *policy,
+			    unsigned int target_freq,
+			    unsigned int relation)
+{
+	if (ops && ops->__driver_target)
+		return ops->__driver_target(policy, target_freq, relation);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(__cpufreq_driver_target);
+
+int cpufreq_driver_target(struct cpufreq_policy *policy,
+			  unsigned int target_freq,
+			  unsigned int relation)
+{
+	if (ops && ops->driver_target)
+		return ops->driver_target(policy, target_freq, relation);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_driver_target);
+
+int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
+{
+	if (ops && ops->__driver_getavg)
+		return ops->__driver_getavg(policy, cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(__cpufreq_driver_getavg);
+
+int cpufreq_register_governor(struct cpufreq_governor *governor)
+{
+	if (ops && ops->register_governor)
+		return ops->register_governor(governor);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_register_governor);
+
+void cpufreq_unregister_governor(struct cpufreq_governor *governor)
+{
+	if (ops && ops->unregister_governor)
+		ops->unregister_governor(governor);
+}
+EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
+
+int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
+{
+	if (ops && ops->get_policy)
+		return ops->get_policy(policy, cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_get_policy);
+
+int cpufreq_update_policy(unsigned int cpu)
+{
+	if (ops && ops->update_policy)
+		return ops->update_policy(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_update_policy);
+
+int cpufreq_register_driver(struct cpufreq_driver *driver_data)
+{
+	if (ops && ops->register_driver)
+		return ops->register_driver(driver_data);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_register_driver);
+
+int cpufreq_unregister_driver(struct cpufreq_driver *driver)
+{
+	if (ops && ops->unregister_driver)
+		return ops->unregister_driver(driver);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
+
+static int __init cpufreq_drv_ops_init(void)
+{
+#ifdef CONFIG_CPU_FREQ
+	ops = &kern_cpufreq_drv_ops;
+	pr_debug("using kern_cpufreq_drv_ops\n");
+#endif
+
+	return 0;
+}
+core_initcall(cpufreq_drv_ops_init);
diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
new file mode 100644
index 0000000..5cc8e05
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_drv_ops.h
@@ -0,0 +1,50 @@
+/*
+ *  Copyright (C) 2014 GlobalLogic 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.
+ */
+
+#ifndef _CPUFREQ_DRV_OPS_H
+#define _CPUFREQ_DRV_OPS_H
+
+#include <linux/types.h>
+#include <linux/cpufreq.h>
+
+struct cpufreq_drv_ops {
+	struct kobject *(*get_global_kobject)(void);
+	struct cpufreq_policy *(*cpu_get)(unsigned int);
+	void (*cpu_put)(struct cpufreq_policy *);
+	void (*notify_transition)(struct cpufreq_freqs *, unsigned int);
+#ifdef CONFIG_CPU_FREQ
+	unsigned int (*quick_get)(unsigned int);
+	unsigned int (*quick_get_max)(unsigned int);
+	unsigned int (*get)(unsigned int);
+	int (*register_notifier)(struct notifier_block *, unsigned int);
+	int (*unregister_notifier)(struct notifier_block *, unsigned int);
+#endif
+	const char *(*get_current_driver)(void);
+	int (*__driver_target)(struct cpufreq_policy *,
+			       unsigned int, unsigned int);
+	int (*driver_target)(struct cpufreq_policy *,
+			     unsigned int, unsigned int);
+	int (*__driver_getavg)(struct cpufreq_policy *, unsigned int);
+	int (*register_governor)(struct cpufreq_governor *);
+	void (*unregister_governor)(struct cpufreq_governor *);
+	int (*get_policy)(struct cpufreq_policy *, unsigned int);
+	int (*update_policy)(unsigned int);
+	int (*register_driver)(struct cpufreq_driver *);
+	int (*unregister_driver)(struct cpufreq_driver *);
+};
+
+#ifdef CONFIG_CPU_FREQ
+extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
+#endif
+
+#endif /* _CPUFREQ_DRV_OPS_H */
diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 6c5f1d3..731fa0d 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -226,7 +226,7 @@ int cpufreq_governor_dbs(struct dbs_data *dbs_data,
 		if (dbs_data->enable != 1)
 			goto second_time;
 
-		rc = sysfs_create_group(cpufreq_global_kobject,
+		rc = sysfs_create_group(get_cpufreq_global_kobject(),
 				dbs_data->attr_group);
 		if (rc) {
 			mutex_unlock(&dbs_data->mutex);
@@ -291,7 +291,7 @@ second_time:
 		if (!dbs_data->enable) {
 			struct cs_ops *ops = dbs_data->gov_ops;
 
-			sysfs_remove_group(cpufreq_global_kobject,
+			sysfs_remove_group(get_cpufreq_global_kobject(),
 					dbs_data->attr_group);
 			if (dbs_data->governor == GOV_CONSERVATIVE)
 				cpufreq_unregister_notifier(ops->notifier_block,
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 3d919ea..2852bb23 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -70,7 +70,7 @@ static inline void disable_cpufreq(void) { }
 struct cpufreq_governor;
 
 /* /sys/devices/system/cpu/cpufreq: entry point for global variables */
-extern struct kobject *cpufreq_global_kobject;
+struct kobject *get_cpufreq_global_kobject(void);
 
 #define CPUFREQ_ETERNAL			(-1)
 struct cpufreq_cpuinfo {
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:10:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlds4-0005cP-LS; Tue, 04 Nov 2014 13:10:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xlds1-0005Yt-GE
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:10:02 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	D3/D8-02698-820D8545; Tue, 04 Nov 2014 13:10:00 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415106598!12452407!1
X-Originating-IP: [64.18.0.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5262 invoked from network); 4 Nov 2014 13:09:59 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:59 -0000
Received: from mail-la0-f50.google.com ([209.85.215.50]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQJcdfUDN7Ln5czLBiWEPDzdyL43sW@postini.com;
	Tue, 04 Nov 2014 05:09:59 PST
Received: by mail-la0-f50.google.com with SMTP id hz20so837636lab.9
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=6ezRXJk9SW/BiO01XSgrlsUSUOMojb7mWrKH8I9XBLE=;
	b=JoyuW6pRomIT+pnH5bwpllqiqa+ZIdV3Lopi0FriCZ5GgPPenYEI/YN8o4NoDLtjrf
	dWYd1U8QHjAhE3UF/p1Ad0q07MQGXEegwr0mgVa7+erkYL/2NkHIyk33ZoESLzYBjlCP
	HCGo4QPKuaACm8hftWgagl/D1kKPHTLeZxLaw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=6ezRXJk9SW/BiO01XSgrlsUSUOMojb7mWrKH8I9XBLE=;
	b=TlD10iY4/Ylad/OziEUDOQbsC2/rpYLrvTCzeNUg8vp8zuh8QTy2HkIuI3GCkH5h6N
	LePQvULiKmP8aDaozDP4mCC1N8AJ9pTPVGIPSAisCa8uqnqYL4+2MKQWOlYkXz4/UwXG
	XTqC6z/wd5wvXtgYDnZo/vEynlEhfhvE3UA7bfP2+d/aWlhtpk248nmVvaQ6H/CsNAXM
	yf5ixCSCuex81K1MyErzBl76Hwx6hwI0SwKpQhAhipGGkPdNk1Cj+MXli/rQU0FNqit7
	kS8xQp7ugmSI8huG2QLHR/omGH69cbhLWP/1aVRRQLnTvlol5HMPfVLiGLzfmVHIvBBh
	lPdw==
X-Gm-Message-State: ALoCoQlQR4YUqwd23PVUgfJQEepAslKf1c1mLRu705jIQqOc/TNJcPYUxbPuopYQSpYQJyUQo6yG6s0sp5dMlZCnnMR8d2uJRtFsqxJWpnnfcAN2KzlNLR7aj9Pj6KacW+rAUjBSQmjIJeZEW0l+fj02gMW76mmFsw==
X-Received: by 10.152.42.172 with SMTP id p12mr59415255lal.11.1415106596264;
	Tue, 04 Nov 2014 05:09:56 -0800 (PST)
X-Received: by 10.152.42.172 with SMTP id p12mr59415244lal.11.1415106596204;
	Tue, 04 Nov 2014 05:09:56 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id w8sm138638lbp.46.2014.11.04.05.09.55
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:55 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:31 +0200
Message-Id: <1415106572-3178-9-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 8/9] xen: arm: add cpufreq shared info
	definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This shared info will be used by xen-cpufreq driver
to receive commands from the cpufreq driver in xen.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 arch/arm/include/asm/xen/interface.h | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index acf4b7a..7da71e1 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -56,8 +56,17 @@ DEFINE_GUEST_HANDLE(xen_ulong_t);
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
 
+struct cpufreq_sh_info {
+	uint32_t cpu;       /* Physical CPU number */
+	uint32_t freq;      /* Frequency in KHz */
+	uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
+	int32_t result;        /* Returned result of the operation */
+};
+
 struct arch_vcpu_info { };
-struct arch_shared_info { };
+struct arch_shared_info {
+	struct cpufreq_sh_info cpufreq;
+};
 
 /* TODO: Move pvclock definitions some place arch independent */
 struct pvclock_vcpu_time_info {
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:10:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlds4-0005cP-LS; Tue, 04 Nov 2014 13:10:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xlds1-0005Yt-GE
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:10:02 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	D3/D8-02698-820D8545; Tue, 04 Nov 2014 13:10:00 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415106598!12452407!1
X-Originating-IP: [64.18.0.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5262 invoked from network); 4 Nov 2014 13:09:59 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 13:09:59 -0000
Received: from mail-la0-f50.google.com ([209.85.215.50]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQJcdfUDN7Ln5czLBiWEPDzdyL43sW@postini.com;
	Tue, 04 Nov 2014 05:09:59 PST
Received: by mail-la0-f50.google.com with SMTP id hz20so837636lab.9
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=6ezRXJk9SW/BiO01XSgrlsUSUOMojb7mWrKH8I9XBLE=;
	b=JoyuW6pRomIT+pnH5bwpllqiqa+ZIdV3Lopi0FriCZ5GgPPenYEI/YN8o4NoDLtjrf
	dWYd1U8QHjAhE3UF/p1Ad0q07MQGXEegwr0mgVa7+erkYL/2NkHIyk33ZoESLzYBjlCP
	HCGo4QPKuaACm8hftWgagl/D1kKPHTLeZxLaw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=6ezRXJk9SW/BiO01XSgrlsUSUOMojb7mWrKH8I9XBLE=;
	b=TlD10iY4/Ylad/OziEUDOQbsC2/rpYLrvTCzeNUg8vp8zuh8QTy2HkIuI3GCkH5h6N
	LePQvULiKmP8aDaozDP4mCC1N8AJ9pTPVGIPSAisCa8uqnqYL4+2MKQWOlYkXz4/UwXG
	XTqC6z/wd5wvXtgYDnZo/vEynlEhfhvE3UA7bfP2+d/aWlhtpk248nmVvaQ6H/CsNAXM
	yf5ixCSCuex81K1MyErzBl76Hwx6hwI0SwKpQhAhipGGkPdNk1Cj+MXli/rQU0FNqit7
	kS8xQp7ugmSI8huG2QLHR/omGH69cbhLWP/1aVRRQLnTvlol5HMPfVLiGLzfmVHIvBBh
	lPdw==
X-Gm-Message-State: ALoCoQlQR4YUqwd23PVUgfJQEepAslKf1c1mLRu705jIQqOc/TNJcPYUxbPuopYQSpYQJyUQo6yG6s0sp5dMlZCnnMR8d2uJRtFsqxJWpnnfcAN2KzlNLR7aj9Pj6KacW+rAUjBSQmjIJeZEW0l+fj02gMW76mmFsw==
X-Received: by 10.152.42.172 with SMTP id p12mr59415255lal.11.1415106596264;
	Tue, 04 Nov 2014 05:09:56 -0800 (PST)
X-Received: by 10.152.42.172 with SMTP id p12mr59415244lal.11.1415106596204;
	Tue, 04 Nov 2014 05:09:56 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id w8sm138638lbp.46.2014.11.04.05.09.55
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:55 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:31 +0200
Message-Id: <1415106572-3178-9-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 8/9] xen: arm: add cpufreq shared info
	definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This shared info will be used by xen-cpufreq driver
to receive commands from the cpufreq driver in xen.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 arch/arm/include/asm/xen/interface.h | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index acf4b7a..7da71e1 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -56,8 +56,17 @@ DEFINE_GUEST_HANDLE(xen_ulong_t);
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
 
+struct cpufreq_sh_info {
+	uint32_t cpu;       /* Physical CPU number */
+	uint32_t freq;      /* Frequency in KHz */
+	uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
+	int32_t result;        /* Returned result of the operation */
+};
+
 struct arch_vcpu_info { };
-struct arch_shared_info { };
+struct arch_shared_info {
+	struct cpufreq_sh_info cpufreq;
+};
 
 /* TODO: Move pvclock definitions some place arch independent */
 struct pvclock_vcpu_time_info {
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:10:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:10:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlds8-0005gs-AA; Tue, 04 Nov 2014 13:10:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xlds6-0005dx-E3
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:10:06 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B4/2A-31453-D20D8545; Tue, 04 Nov 2014 13:10:05 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415106600!6987675!1
X-Originating-IP: [64.18.0.189]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19120 invoked from network); 4 Nov 2014 13:10:03 -0000
Received: from exprod5og119.obsmtp.com (HELO exprod5og119.obsmtp.com)
	(64.18.0.189)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Nov 2014 13:10:03 -0000
Received: from mail-la0-f50.google.com ([209.85.215.50]) (using TLSv1) by
	exprod5ob119.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQKE8FFMecS55bN50z0Hwrb8RiIqiF@postini.com;
	Tue, 04 Nov 2014 05:10:02 PST
Received: by mail-la0-f50.google.com with SMTP id hz20so837702lab.9
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=JD3XV9JmfV1DVBooOfYeZKdXV8oD92txVAMGN2XlIEM=;
	b=Wno3G0SocbSrFTQCgy8KDFoc+b0R8AeyxpxNmtaaISMhl4+Loenj9q4fAlbhUsQ3eq
	HhBhziQehkbGBH8SM9vIf8C7hSk63ePQ3LSybCgL86mF050aB+IukH8z3g0aUCwIum83
	Y4z7Jh0iq5CzWGKCM+Bttol1hcLH8QBuEnpzQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=JD3XV9JmfV1DVBooOfYeZKdXV8oD92txVAMGN2XlIEM=;
	b=N8UDRzrVoU9cimXd2WJwDTf/Ml1MOF5FpJEvpKBLjE0//Vfs2RN+aXhs6OTQgexRjK
	QxOykT6hfXLeEAJuf3T8/Ly+Rrbqr1mBFb3eLhYWt7O4XDlk5U5yXx3gEioyQ9tQmMYg
	LYuEE5GDuf5erUPkxx2/iEzfbL2WLBcAymf2nw7PEyPCxTQn214MlivJ/xTnR9HB0BBg
	Yrq4RHoBX3awIM9Cgd1i7VbOkTfJTScRqLZ3MCvLfRPtMg45457osxNRCtczP1CAIRNt
	QPgcERxMn53f0YgX5crqxFhQ8MIy1KT70rBGDvhooTI0TDuGRyjko/yFAFzI5Bc0qbTp
	c52w==
X-Gm-Message-State: ALoCoQkmEGsYws+CUMI1eIeXxIEHsmJHsCzgxrU5AoeQZ9HqspU/sTVcRCjOVuVHM72QPlgh1EV5iFPBCdmxmF/shZt0T2WqMaW1pGdh2JzZnHXWoLQggHt6mQgN9zx4Sf9sRMysYRiRJNUOtz3dvA9CG3KTaUioww==
X-Received: by 10.112.139.196 with SMTP id ra4mr21231135lbb.95.1415106598734; 
	Tue, 04 Nov 2014 05:09:58 -0800 (PST)
X-Received: by 10.112.139.196 with SMTP id ra4mr21231109lbb.95.1415106598616; 
	Tue, 04 Nov 2014 05:09:58 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id ee6sm139106lad.45.2014.11.04.05.09.57
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:57 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:32 +0200
Message-Id: <1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 9/9] xen/arm: cpufreq: add xen-cpufreq
	driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 changes frequencies on CPUs using this high-level
cpufreq driver.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/Kconfig           |  20 +
 drivers/cpufreq/Makefile          |   1 +
 drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
 drivers/cpufreq/cpufreq_drv_ops.h |   4 +
 drivers/cpufreq/xen-cpufreq.c     | 869 ++++++++++++++++++++++++++++++++++++++
 include/xen/interface/platform.h  |   1 +
 include/xen/interface/xen.h       |   1 +
 7 files changed, 907 insertions(+), 2 deletions(-)
 create mode 100644 drivers/cpufreq/xen-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index f5a8f84..4847d8a 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -19,6 +19,26 @@ config CPU_FREQ
 
 	  If in doubt, say N.
 
+config XEN_CPUFREQ
+	bool "Xen Cpufreq driver"
+	depends on XEN_DOM0
+	depends on !CPUMASK_OFFSTACK
+	default n
+	select CPUFREQ_DRV_OPS
+	help
+	  This driver uploads Power Management information to the Xen
+	  hypervisor and changes CPUs frequency using CPU Frequency scaling
+	  drivers.
+
+	  To do that the driver uses CPU Frequency scaling drivers to parse
+	  the Power Management data and uploads said information to the Xen
+	  hypervisor. Then the Xen hypervisor can select the proper Pxx states.
+
+	  Then the Xen hypervisor can change CPUs frequency by giving commands
+	  via this driver to the CPU Frequency scaling driver.
+
+	  If in doubt, say N.
+
 if CPUFREQ_DRV_OPS
 
 config CPU_FREQ_TABLE
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index f12a0d3..c8d5037 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -1,5 +1,6 @@
 # CPUfreq core
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
+obj-$(CONFIG_XEN_CPUFREQ)		+= xen-cpufreq.o
 obj-$(CONFIG_CPUFREQ_DRV_OPS)		+= cpufreq_drv_ops.o
 # CPUfreq stats
 obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
index c971442..71c3357 100644
--- a/drivers/cpufreq/cpufreq_drv_ops.c
+++ b/drivers/cpufreq/cpufreq_drv_ops.c
@@ -18,6 +18,8 @@
 #include <linux/init.h>
 #include <linux/export.h>
 
+#include <xen/xen.h>
+
 static struct cpufreq_drv_ops *ops;
 
 struct kobject *get_cpufreq_global_kobject(void)
@@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
 
 static int __init cpufreq_drv_ops_init(void)
 {
+	if (xen_initial_domain()) {
+#ifdef CONFIG_XEN_CPUFREQ
+		ops = &xen_cpufreq_drv_ops;
+		pr_debug("using xen_cpufreq_drv_ops\n");
+#endif
+	} else {
 #ifdef CONFIG_CPU_FREQ
-	ops = &kern_cpufreq_drv_ops;
-	pr_debug("using kern_cpufreq_drv_ops\n");
+		ops = &kern_cpufreq_drv_ops;
+		pr_debug("using kern_cpufreq_drv_ops\n");
 #endif
+	}
 
 	return 0;
 }
diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
index 5cc8e05..d02d509 100644
--- a/drivers/cpufreq/cpufreq_drv_ops.h
+++ b/drivers/cpufreq/cpufreq_drv_ops.h
@@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
 extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
 #endif
 
+#ifdef CONFIG_XEN_CPUFREQ
+extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
+#endif
+
 #endif /* _CPUFREQ_DRV_OPS_H */
diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
new file mode 100644
index 0000000..21062c7
--- /dev/null
+++ b/drivers/cpufreq/xen-cpufreq.c
@@ -0,0 +1,869 @@
+/*
+ *  Copyright (C) 2001 Russell King
+ *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
+ *
+ *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
+ *	Added handling for CPU hotplug
+ *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
+ *	Fix handling for CPU hotplug -- affected CPUs
+ *
+ *           (C) 2014 GlobalLogic Inc.
+ *
+ * Based on drivers/cpufreq/cpufreq.c
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/notifier.h>
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+#include <linux/irq.h>
+#include <linux/workqueue.h>
+#include <linux/cpufreq.h>
+
+#include <trace/events/power.h>
+
+#include <xen/xen.h>
+#include <xen/events.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/platform.h>
+#include <xen/interface/sysctl.h>
+#include <asm/xen/hypercall.h>
+#include <asm/xen/hypervisor.h>
+
+#include "cpufreq_drv_ops.h"
+
+static int xen_nr_cpus;
+static int xen_irq;
+
+#define for_each_xen_cpu(cpu, mask)			\
+	for ((cpu) = -1;				\
+		(cpu) = cpumask_next((cpu), (mask)),	\
+		(cpu) < xen_nr_cpus;)
+
+static struct cpufreq_driver *cpufreq_driver;
+static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
+
+static DEFINE_SPINLOCK(cpufreq_driver_lock);
+
+/*
+ * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
+ * all cpufreq/hotplug/workqueue/etc related lock issues.
+ *
+ * The rules for this semaphore:
+ * - Any routine that wants to read from the policy structure will
+ *   do a down_read on this semaphore.
+ * - Any routine that will write to the policy structure and/or may take away
+ *   the policy altogether (eg. CPU hotplug), will hold this lock in write
+ *   mode before doing so.
+ *
+ * Additional rules:
+ * - Governor routines that can be called in cpufreq hotplug path should not
+ *   take this sem as top level hotplug notifier handler takes this.
+ * - Lock should not be held across
+ *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
+ */
+static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
+static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
+
+#define lock_policy_rwsem(mode, cpu)				\
+static int lock_policy_rwsem_##mode				\
+(int cpu)							\
+{								\
+	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);	\
+	BUG_ON(policy_cpu == -1);				\
+	down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));	\
+								\
+	return 0;						\
+}
+
+lock_policy_rwsem(write, cpu);
+
+static void unlock_policy_rwsem_write(int cpu)
+{
+	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
+	BUG_ON(policy_cpu == -1);
+	up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
+}
+
+/**
+ * The "transition" notifier list for kernel code that needs to handle
+ * changes to devices when the CPU clock speed changes.
+ * The mutex locks this list.
+ */
+static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
+
+static bool init_cpufreq_transition_notifier_list_called;
+static int __init init_cpufreq_transition_notifier_list(void)
+{
+	srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
+	init_cpufreq_transition_notifier_list_called = true;
+	return 0;
+}
+pure_initcall(init_cpufreq_transition_notifier_list);
+
+static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
+{
+	struct cpufreq_policy *data = NULL;
+	unsigned long flags;
+
+	if (cpu >= xen_nr_cpus)
+		goto err_out;
+
+	/* get the cpufreq driver */
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+
+	if (!cpufreq_driver)
+		goto err_out_unlock;
+
+	/* get the CPU */
+	data = per_cpu(cpufreq_cpu_data, cpu);
+
+err_out_unlock:
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+err_out:
+	return data;
+}
+
+static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
+{
+	module_put(cpufreq_driver->owner);
+}
+
+static int push_data_to_hypervisor(struct cpufreq_policy *policy,
+				   struct cpufreq_frequency_table *table)
+{
+	int ret = 0;
+	unsigned int i;
+	unsigned int cpu;
+	uint32_t platform_limit = 0;
+	unsigned int max_freq = 0;
+	unsigned int state_count = 0;
+	unsigned int prev_freq = 0;
+	struct xen_processor_px *dst_states;
+	struct xen_processor_performance *dst_perf;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+
+	dst_perf = &op.u.set_pminfo.perf;
+
+	/* Check freq table and find max frequency */
+	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
+		unsigned int freq = table[i].frequency;
+		if (freq == CPUFREQ_ENTRY_INVALID)
+			continue;
+
+		if (table[i].index != state_count || freq <= prev_freq) {
+			pr_err("Frequency table format error\n");
+			return -EINVAL;
+		}
+
+		prev_freq = freq;
+		state_count++;
+		if (freq > max_freq)
+			max_freq = freq;
+	}
+
+	if (!state_count)
+		return -EINVAL;
+
+	dst_perf->state_count = state_count;
+
+	dst_states = kcalloc(state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+
+	if (!dst_states)
+		return -ENOMEM;
+
+	set_xen_guest_handle(dst_perf->states, dst_states);
+
+	/*
+	 * Freq table should start from lower values
+	 * dst_states should start from higer values
+	 */
+	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
+		unsigned int freq = table[i].frequency;
+		unsigned int tbl_index = state_count - 1 - table[i].index;
+		if (freq == CPUFREQ_ENTRY_INVALID)
+			continue;
+
+		if (freq == max_freq)
+			platform_limit = tbl_index;
+
+		dst_states[tbl_index].core_frequency = freq / 1000;
+		dst_states[tbl_index].transition_latency =
+				policy->cpuinfo.transition_latency / 1000;
+	}
+
+	dst_perf->shared_type = policy->shared_type;
+	dst_perf->platform_limit = platform_limit;
+	dst_perf->domain_info.domain = policy->cpu;
+	dst_perf->domain_info.num_processors = xen_nr_cpus;
+	dst_perf->flags = XEN_PX_DATA;
+
+	for_each_xen_cpu(cpu, policy->cpus) {
+		op.u.set_pminfo.id = cpu;
+		ret = HYPERVISOR_dom0_op(&op);
+		if (ret) {
+			pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
+			goto err_free_states;
+		}
+		pr_debug("CPU%u - P-states uploaded\n", cpu);
+
+		for (i = 0; i < dst_perf->state_count; i++) {
+			pr_debug("    state %d: %d MHz, %d uS\n",
+				 i, (u32) dst_states[i].core_frequency,
+				 (u32) dst_states[i].transition_latency);
+		}
+	}
+
+err_free_states:
+	kfree(dst_states);
+	return ret;
+}
+
+/*
+ * Returns:
+ *   Negative: Failure
+ *   0:        Success
+ *   Positive: When we have a managed CPU and the sysfs got symlinked
+ */
+static int xen_cpufreq_add_dev_policy(unsigned int cpu,
+				  struct cpufreq_policy *policy)
+{
+	int ret = 0;
+#ifdef CONFIG_SMP
+	unsigned long flags;
+	unsigned int j;
+
+	for_each_cpu(j, policy->cpus) {
+		struct cpufreq_policy *managed_policy;
+
+		if (cpu == j)
+			continue;
+
+		/* Check for existing affected CPUs.
+		 * They may not be aware of it due to CPU Hotplug.
+		 * cpufreq_cpu_put is called when the device is removed
+		 * in __cpufreq_remove_dev()
+		 */
+		managed_policy = xen_cpufreq_cpu_get(j);
+		if (unlikely(managed_policy)) {
+			/* Set proper policy_cpu */
+			unlock_policy_rwsem_write(cpu);
+			per_cpu(cpufreq_policy_cpu, cpu) =
+						managed_policy->cpu;
+
+			if (lock_policy_rwsem_write(cpu) < 0) {
+				/* Should not go through policy unlock path */
+				if (cpufreq_driver->exit)
+					cpufreq_driver->exit(policy);
+				xen_cpufreq_cpu_put(managed_policy);
+				return -EBUSY;
+			}
+
+			spin_lock_irqsave(&cpufreq_driver_lock, flags);
+			cpumask_copy(managed_policy->cpus, policy->cpus);
+			per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
+			spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+			pr_debug("CPU already managed, adding link\n");
+
+			/*
+			 * Success. We only needed to be added to the mask.
+			 * Call driver->exit() because only the cpu parent of
+			 * the kobj needed to call init().
+			 */
+			if (cpufreq_driver->exit)
+				cpufreq_driver->exit(policy);
+
+			return 1;
+		}
+	}
+#endif
+	return ret;
+}
+
+/**
+ * xen_cpufreq_add_dev - add a CPU device
+ *
+ * Adds the cpufreq interface for a CPU device.
+ */
+static int xen_cpufreq_add_dev(unsigned int cpu)
+{
+	int ret = 0;
+	struct cpufreq_policy *policy;
+	unsigned long flags;
+	unsigned int j;
+
+	pr_debug("adding CPU %u\n", cpu);
+
+#ifdef CONFIG_SMP
+	/* check whether a different CPU already registered this
+	 * CPU because it is in the same boat. */
+	policy = xen_cpufreq_cpu_get(cpu);
+	if (unlikely(policy)) {
+		xen_cpufreq_cpu_put(policy);
+		return 0;
+	}
+#endif
+
+	if (!try_module_get(cpufreq_driver->owner)) {
+		ret = -EINVAL;
+		goto module_out;
+	}
+
+	ret = -ENOMEM;
+	policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
+	if (!policy)
+		goto nomem_out;
+
+	if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
+		goto err_free_policy;
+
+	if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
+		goto err_free_cpumask;
+
+	policy->cpu = cpu;
+	cpumask_copy(policy->cpus, cpumask_of(cpu));
+
+	/* Initially set CPU itself as the policy_cpu */
+	per_cpu(cpufreq_policy_cpu, cpu) = cpu;
+	ret = (lock_policy_rwsem_write(cpu) < 0);
+	WARN_ON(ret);
+
+	/* call driver. From then on the cpufreq must be able
+	 * to accept all calls to ->verify and ->setpolicy for this CPU
+	 */
+	ret = cpufreq_driver->init(policy);
+	if (ret) {
+		pr_debug("initialization failed\n");
+		goto err_unlock_policy;
+	}
+	ret = xen_cpufreq_add_dev_policy(cpu, policy);
+	if (ret) {
+		if (ret > 0)
+			/* This is a managed cpu, symlink created,
+			   exit with 0 */
+			ret = 0;
+		goto err_unlock_policy;
+	}
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	for_each_cpu(j, policy->cpus) {
+		per_cpu(cpufreq_cpu_data, j) = policy;
+		per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
+	}
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	unlock_policy_rwsem_write(cpu);
+
+	module_put(cpufreq_driver->owner);
+	pr_debug("initialization complete\n");
+
+	return 0;
+
+err_unlock_policy:
+	unlock_policy_rwsem_write(cpu);
+	free_cpumask_var(policy->related_cpus);
+err_free_cpumask:
+	free_cpumask_var(policy->cpus);
+err_free_policy:
+	kfree(policy);
+nomem_out:
+	module_put(cpufreq_driver->owner);
+module_out:
+	return ret;
+}
+
+/**
+ * __cpufreq_remove_dev - remove a CPU device
+ *
+ * Removes the cpufreq interface for a CPU device.
+ * Caller should already have policy_rwsem in write mode for this CPU.
+ * This routine frees the rwsem before returning.
+ */
+static int __cpufreq_remove_dev(unsigned int cpu)
+{
+	unsigned long flags;
+	struct cpufreq_policy *data;
+#ifdef CONFIG_SMP
+	unsigned int j;
+#endif
+
+	pr_debug("unregistering CPU %u\n", cpu);
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	data = per_cpu(cpufreq_cpu_data, cpu);
+
+	if (!data) {
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		unlock_policy_rwsem_write(cpu);
+		return -EINVAL;
+	}
+	per_cpu(cpufreq_cpu_data, cpu) = NULL;
+
+
+#ifdef CONFIG_SMP
+	/* if this isn't the CPU which is the parent of the kobj, we
+	 * only need to unlink, put and exit
+	 */
+	if (unlikely(cpu != data->cpu)) {
+		pr_debug("removing link\n");
+		cpumask_clear_cpu(cpu, data->cpus);
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		xen_cpufreq_cpu_put(data);
+		unlock_policy_rwsem_write(cpu);
+		return 0;
+	}
+#endif
+
+#ifdef CONFIG_SMP
+
+	/* if we have other CPUs still registered, we need to unlink them,
+	 * or else wait_for_completion below will lock up. Clean the
+	 * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
+	 * the sysfs links afterwards.
+	 */
+	if (unlikely(cpumask_weight(data->cpus) > 1)) {
+		for_each_cpu(j, data->cpus) {
+			if (j == cpu)
+				continue;
+			per_cpu(cpufreq_cpu_data, j) = NULL;
+		}
+	}
+
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	if (unlikely(cpumask_weight(data->cpus) > 1)) {
+		for_each_cpu(j, data->cpus) {
+			if (j == cpu)
+				continue;
+			pr_debug("removing link for cpu %u\n", j);
+			unlock_policy_rwsem_write(cpu);
+			lock_policy_rwsem_write(cpu);
+			xen_cpufreq_cpu_put(data);
+		}
+	}
+#else
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+#endif
+
+	unlock_policy_rwsem_write(cpu);
+
+	lock_policy_rwsem_write(cpu);
+	if (cpufreq_driver->exit)
+		cpufreq_driver->exit(data);
+	unlock_policy_rwsem_write(cpu);
+
+	free_cpumask_var(data->related_cpus);
+	free_cpumask_var(data->cpus);
+	kfree(data);
+
+	return 0;
+}
+
+static int cpufreq_remove_dev(unsigned int cpu)
+{
+	int retval;
+
+	if (unlikely(lock_policy_rwsem_write(cpu)))
+		BUG();
+
+	retval = __cpufreq_remove_dev(cpu);
+	return retval;
+}
+
+/*********************************************************************
+ *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
+ *********************************************************************/
+
+/**
+ * adjust_jiffies - adjust the system "loops_per_jiffy"
+ *
+ * This function alters the system "loops_per_jiffy" for the clock
+ * speed change. Note that loops_per_jiffy cannot be updated on SMP
+ * systems as each CPU might be scaled differently. So, use the arch
+ * per-CPU loops_per_jiffy value wherever possible.
+ */
+#ifndef CONFIG_SMP
+static unsigned long l_p_j_ref;
+static unsigned int  l_p_j_ref_freq;
+
+static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
+{
+	if (ci->flags & CPUFREQ_CONST_LOOPS)
+		return;
+
+	if (!l_p_j_ref_freq) {
+		l_p_j_ref = loops_per_jiffy;
+		l_p_j_ref_freq = ci->old;
+		pr_debug("saving %lu as reference value for loops_per_jiffy; "
+			"freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
+	}
+	if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
+	    (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
+		loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
+								ci->new);
+		pr_debug("scaling loops_per_jiffy to %lu "
+			"for frequency %u kHz\n", loops_per_jiffy, ci->new);
+	}
+}
+#else
+static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
+{
+	return;
+}
+#endif
+
+
+/**
+ * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
+ * on frequency transition.
+ *
+ * This function calls the transition notifiers and the "adjust_jiffies"
+ * function. It is called twice on all CPU frequency changes that have
+ * external effects.
+ */
+void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
+				   unsigned int state)
+{
+	struct cpufreq_policy *policy;
+
+	BUG_ON(irqs_disabled());
+
+	freqs->flags = cpufreq_driver->flags;
+	pr_debug("notification %u of frequency transition to %u kHz\n",
+		 state, freqs->new);
+
+	policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
+	switch (state) {
+	case CPUFREQ_PRECHANGE:
+		/* detect if the driver reported a value as "old frequency"
+		 * which is not equal to what the cpufreq core thinks is
+		 * "old frequency".
+		 */
+		if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
+			if ((policy) && (policy->cpu == freqs->cpu) &&
+			    (policy->cur) && (policy->cur != freqs->old)) {
+				pr_debug("Warning: CPU frequency is"
+					 " %u, cpufreq assumed %u kHz.\n",
+					 freqs->old, policy->cur);
+				freqs->old = policy->cur;
+			}
+		}
+		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
+					 CPUFREQ_PRECHANGE, freqs);
+		adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
+		break;
+
+	case CPUFREQ_POSTCHANGE:
+		adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
+		pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
+			 (unsigned long)freqs->cpu);
+		trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
+		trace_cpu_frequency(freqs->new, freqs->cpu);
+		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
+					 CPUFREQ_POSTCHANGE, freqs);
+		if (likely(policy) && likely(policy->cpu == freqs->cpu))
+			policy->cur = freqs->new;
+		break;
+	}
+}
+
+/*********************************************************************
+ *                              GOVERNORS                            *
+ *********************************************************************/
+
+int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
+				unsigned int target_freq,
+				unsigned int relation)
+{
+	int retval = -EINVAL;
+	unsigned int old_target_freq = target_freq;
+
+	/* Make sure that target_freq is within supported range */
+	if (target_freq > policy->max)
+		target_freq = policy->max;
+	if (target_freq < policy->min)
+		target_freq = policy->min;
+
+	pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
+		 policy->cpu, target_freq, relation, old_target_freq);
+
+	if (target_freq == policy->cur)
+		return 0;
+
+	if (cpufreq_driver->target)
+		retval = cpufreq_driver->target(policy, target_freq,
+						    relation);
+
+	return retval;
+}
+
+int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
+			      unsigned int target_freq,
+			      unsigned int relation)
+{
+	int ret = -EINVAL;
+
+	if (!policy)
+		goto no_policy;
+
+	if (unlikely(lock_policy_rwsem_write(policy->cpu)))
+		goto fail;
+
+	ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
+
+	unlock_policy_rwsem_write(policy->cpu);
+
+fail:
+	xen_cpufreq_cpu_put(policy);
+no_policy:
+	return ret;
+}
+
+/*********************************************************************
+ *                    HANDLE COMMANDS FROM XEN                       *
+ *********************************************************************/
+static void cpufreq_work_hnd(struct work_struct *w);
+
+static struct workqueue_struct *cpufreq_wq;
+static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
+
+static void cpufreq_work_hnd(struct work_struct *w)
+{
+	int ret;
+	struct cpufreq_policy *policy;
+	struct cpufreq_sh_info *cpufreq_info;
+
+	cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
+
+	policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
+	ret = xen_cpufreq_driver_target(policy,
+					cpufreq_info->freq,
+					cpufreq_info->relation);
+
+	cpufreq_info->result = ret;
+}
+
+static irqreturn_t cpufreq_interrupt(int irq, void *data)
+{
+	queue_work(cpufreq_wq, &cpufreq_work);
+	return IRQ_HANDLED;
+}
+
+/*********************************************************************
+ *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
+ *********************************************************************/
+
+/**
+ * xen_cpufreq_register_driver - register a CPU Frequency driver
+ * @driver_data: A struct cpufreq_driver containing the values#
+ * submitted by the CPU Frequency driver.
+ *
+ *   Registers a CPU Frequency driver to this core code. This code
+ * returns zero on success, -EBUSY when another driver got here first
+ * (and isn't unregistered in the meantime).
+ *
+ */
+int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
+{
+	unsigned long flags;
+	int ret;
+	unsigned int cpu;
+	struct cpufreq_frequency_table *table;
+	struct cpufreq_policy *policy;
+	cpumask_var_t pushed_cpus;
+	int irq;
+
+	if (!xen_nr_cpus)
+		return -EPROBE_DEFER;
+
+	if (!driver_data || !driver_data->verify || !driver_data->init ||
+	    (!driver_data->target))
+		return -EINVAL;
+
+	pr_debug("trying to register driver %s\n", driver_data->name);
+
+	if (driver_data->setpolicy)
+		driver_data->flags |= CPUFREQ_CONST_LOOPS;
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+
+	if (cpufreq_driver) {
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		return -EBUSY;
+	}
+	cpufreq_driver = driver_data;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	irq = bind_virq_to_irq(VIRQ_CPUFREQ, 0);
+	if (irq < 0) {
+		pr_err("Bind virq (%d) error (%d)\n", VIRQ_CPUFREQ, irq);
+		ret = irq;
+		goto err_remove_drv;
+	}
+
+	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN|IRQ_NOPROBE);
+
+	ret = request_irq(irq, cpufreq_interrupt, 0,
+			   "xen_cpufreq", NULL);
+
+	if (ret < 0) {
+		pr_err("Request irq (%d) error (%d)\n", irq, ret);
+		goto err_unbind_from_irqhnd;
+	}
+
+	xen_irq = irq;
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
+		ret = xen_cpufreq_add_dev(cpu);
+		if (ret)
+			goto err_remove_cpu;
+	}
+
+	if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
+		goto err_remove_cpu;
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
+		if (cpumask_test_cpu(cpu, pushed_cpus))
+			continue;
+
+		policy = xen_cpufreq_cpu_get(cpu);
+		if (!policy) {
+			ret = -EINVAL;
+			goto err_free_cpumask;
+		}
+
+		cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
+		table = cpufreq_frequency_get_table(policy->cpu);
+		if (!table) {
+			ret = -EINVAL;
+			goto err_free_cpumask;
+		}
+
+		ret = push_data_to_hypervisor(policy, table);
+		if (ret)
+			goto err_free_cpumask;
+	}
+
+	free_cpumask_var(pushed_cpus);
+
+	pr_debug("driver %s up and running\n", driver_data->name);
+
+	return 0;
+
+err_free_cpumask:
+	free_cpumask_var(pushed_cpus);
+err_remove_cpu:
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
+		cpufreq_remove_dev(cpu);
+err_unbind_from_irqhnd:
+	unbind_from_irqhandler(irq, NULL);
+err_remove_drv:
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	cpufreq_driver = NULL;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+	return ret;
+}
+
+/**
+ * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
+ *
+ *    Unregister the current CPUFreq driver. Only call this if you have
+ * the right to do so, i.e. if you have succeeded in initialising before!
+ * Returns zero if successful, and -EINVAL if the cpufreq_driver is
+ * currently not initialised.
+ */
+int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
+{
+	unsigned long flags;
+	unsigned int cpu;
+
+	if (!cpufreq_driver || (driver != cpufreq_driver))
+		return -EINVAL;
+
+	pr_debug("unregistering driver %s\n", driver->name);
+
+	unbind_from_irqhandler(xen_irq, NULL);
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
+		cpufreq_remove_dev(cpu);
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	cpufreq_driver = NULL;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	return 0;
+}
+
+struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
+	.notify_transition = xen_cpufreq_notify_transition,
+	.register_driver = xen_cpufreq_register_driver,
+	.unregister_driver = xen_cpufreq_unregister_driver,
+};
+
+static int __init xen_cpufreq_init(void)
+{
+	int ret;
+	int i;
+
+	struct xen_sysctl op = {
+		.cmd			= XEN_SYSCTL_physinfo,
+		.interface_version	= XEN_SYSCTL_INTERFACE_VERSION,
+	};
+
+	ret = HYPERVISOR_sysctl(&op);
+	if (ret) {
+		pr_err("Hypervisor get physinfo error (%d)\n", ret);
+		return ret;
+	}
+
+	xen_nr_cpus = op.u.physinfo.nr_cpus;
+	if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
+		xen_nr_cpus = 0;
+		pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < xen_nr_cpus; i++) {
+		per_cpu(cpufreq_policy_cpu, i) = -1;
+		init_rwsem(&per_cpu(cpu_policy_rwsem, i));
+	}
+
+	cpufreq_wq = alloc_workqueue("xen_cpufreq", 0, 1);
+	if (!cpufreq_wq) {
+		pr_err("Create workqueue error\n");
+		ret = -ENOMEM;
+		goto err_create_wq;
+	}
+
+	return 0;
+
+err_create_wq:
+	xen_nr_cpus = 0;
+	return ret;
+}
+
+MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
+MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+core_initcall(xen_cpufreq_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c57d5f6..ee3b154 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
 #define XEN_PX_PSS   2
 #define XEN_PX_PPC   4
 #define XEN_PX_PSD   8
+#define XEN_PX_DATA  16
 
 struct xen_power_register {
 	uint32_t     space_id;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index cf64566..9133110 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -81,6 +81,7 @@
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
 #define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
+#define VIRQ_CPUFREQ    14 /* (DOM0) Notify cpufreq driver                */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:10:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:10:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlds8-0005gs-AA; Tue, 04 Nov 2014 13:10:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1Xlds6-0005dx-E3
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:10:06 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B4/2A-31453-D20D8545; Tue, 04 Nov 2014 13:10:05 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415106600!6987675!1
X-Originating-IP: [64.18.0.189]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19120 invoked from network); 4 Nov 2014 13:10:03 -0000
Received: from exprod5og119.obsmtp.com (HELO exprod5og119.obsmtp.com)
	(64.18.0.189)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Nov 2014 13:10:03 -0000
Received: from mail-la0-f50.google.com ([209.85.215.50]) (using TLSv1) by
	exprod5ob119.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFjQKE8FFMecS55bN50z0Hwrb8RiIqiF@postini.com;
	Tue, 04 Nov 2014 05:10:02 PST
Received: by mail-la0-f50.google.com with SMTP id hz20so837702lab.9
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:09:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=JD3XV9JmfV1DVBooOfYeZKdXV8oD92txVAMGN2XlIEM=;
	b=Wno3G0SocbSrFTQCgy8KDFoc+b0R8AeyxpxNmtaaISMhl4+Loenj9q4fAlbhUsQ3eq
	HhBhziQehkbGBH8SM9vIf8C7hSk63ePQ3LSybCgL86mF050aB+IukH8z3g0aUCwIum83
	Y4z7Jh0iq5CzWGKCM+Bttol1hcLH8QBuEnpzQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=JD3XV9JmfV1DVBooOfYeZKdXV8oD92txVAMGN2XlIEM=;
	b=N8UDRzrVoU9cimXd2WJwDTf/Ml1MOF5FpJEvpKBLjE0//Vfs2RN+aXhs6OTQgexRjK
	QxOykT6hfXLeEAJuf3T8/Ly+Rrbqr1mBFb3eLhYWt7O4XDlk5U5yXx3gEioyQ9tQmMYg
	LYuEE5GDuf5erUPkxx2/iEzfbL2WLBcAymf2nw7PEyPCxTQn214MlivJ/xTnR9HB0BBg
	Yrq4RHoBX3awIM9Cgd1i7VbOkTfJTScRqLZ3MCvLfRPtMg45457osxNRCtczP1CAIRNt
	QPgcERxMn53f0YgX5crqxFhQ8MIy1KT70rBGDvhooTI0TDuGRyjko/yFAFzI5Bc0qbTp
	c52w==
X-Gm-Message-State: ALoCoQkmEGsYws+CUMI1eIeXxIEHsmJHsCzgxrU5AoeQZ9HqspU/sTVcRCjOVuVHM72QPlgh1EV5iFPBCdmxmF/shZt0T2WqMaW1pGdh2JzZnHXWoLQggHt6mQgN9zx4Sf9sRMysYRiRJNUOtz3dvA9CG3KTaUioww==
X-Received: by 10.112.139.196 with SMTP id ra4mr21231135lbb.95.1415106598734; 
	Tue, 04 Nov 2014 05:09:58 -0800 (PST)
X-Received: by 10.112.139.196 with SMTP id ra4mr21231109lbb.95.1415106598616; 
	Tue, 04 Nov 2014 05:09:58 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id ee6sm139106lad.45.2014.11.04.05.09.57
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:09:57 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue,  4 Nov 2014 15:09:32 +0200
Message-Id: <1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v4 9/9] xen/arm: cpufreq: add xen-cpufreq
	driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 changes frequencies on CPUs using this high-level
cpufreq driver.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/Kconfig           |  20 +
 drivers/cpufreq/Makefile          |   1 +
 drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
 drivers/cpufreq/cpufreq_drv_ops.h |   4 +
 drivers/cpufreq/xen-cpufreq.c     | 869 ++++++++++++++++++++++++++++++++++++++
 include/xen/interface/platform.h  |   1 +
 include/xen/interface/xen.h       |   1 +
 7 files changed, 907 insertions(+), 2 deletions(-)
 create mode 100644 drivers/cpufreq/xen-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index f5a8f84..4847d8a 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -19,6 +19,26 @@ config CPU_FREQ
 
 	  If in doubt, say N.
 
+config XEN_CPUFREQ
+	bool "Xen Cpufreq driver"
+	depends on XEN_DOM0
+	depends on !CPUMASK_OFFSTACK
+	default n
+	select CPUFREQ_DRV_OPS
+	help
+	  This driver uploads Power Management information to the Xen
+	  hypervisor and changes CPUs frequency using CPU Frequency scaling
+	  drivers.
+
+	  To do that the driver uses CPU Frequency scaling drivers to parse
+	  the Power Management data and uploads said information to the Xen
+	  hypervisor. Then the Xen hypervisor can select the proper Pxx states.
+
+	  Then the Xen hypervisor can change CPUs frequency by giving commands
+	  via this driver to the CPU Frequency scaling driver.
+
+	  If in doubt, say N.
+
 if CPUFREQ_DRV_OPS
 
 config CPU_FREQ_TABLE
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index f12a0d3..c8d5037 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -1,5 +1,6 @@
 # CPUfreq core
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
+obj-$(CONFIG_XEN_CPUFREQ)		+= xen-cpufreq.o
 obj-$(CONFIG_CPUFREQ_DRV_OPS)		+= cpufreq_drv_ops.o
 # CPUfreq stats
 obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
index c971442..71c3357 100644
--- a/drivers/cpufreq/cpufreq_drv_ops.c
+++ b/drivers/cpufreq/cpufreq_drv_ops.c
@@ -18,6 +18,8 @@
 #include <linux/init.h>
 #include <linux/export.h>
 
+#include <xen/xen.h>
+
 static struct cpufreq_drv_ops *ops;
 
 struct kobject *get_cpufreq_global_kobject(void)
@@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
 
 static int __init cpufreq_drv_ops_init(void)
 {
+	if (xen_initial_domain()) {
+#ifdef CONFIG_XEN_CPUFREQ
+		ops = &xen_cpufreq_drv_ops;
+		pr_debug("using xen_cpufreq_drv_ops\n");
+#endif
+	} else {
 #ifdef CONFIG_CPU_FREQ
-	ops = &kern_cpufreq_drv_ops;
-	pr_debug("using kern_cpufreq_drv_ops\n");
+		ops = &kern_cpufreq_drv_ops;
+		pr_debug("using kern_cpufreq_drv_ops\n");
 #endif
+	}
 
 	return 0;
 }
diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
index 5cc8e05..d02d509 100644
--- a/drivers/cpufreq/cpufreq_drv_ops.h
+++ b/drivers/cpufreq/cpufreq_drv_ops.h
@@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
 extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
 #endif
 
+#ifdef CONFIG_XEN_CPUFREQ
+extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
+#endif
+
 #endif /* _CPUFREQ_DRV_OPS_H */
diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
new file mode 100644
index 0000000..21062c7
--- /dev/null
+++ b/drivers/cpufreq/xen-cpufreq.c
@@ -0,0 +1,869 @@
+/*
+ *  Copyright (C) 2001 Russell King
+ *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
+ *
+ *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
+ *	Added handling for CPU hotplug
+ *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
+ *	Fix handling for CPU hotplug -- affected CPUs
+ *
+ *           (C) 2014 GlobalLogic Inc.
+ *
+ * Based on drivers/cpufreq/cpufreq.c
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/notifier.h>
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+#include <linux/irq.h>
+#include <linux/workqueue.h>
+#include <linux/cpufreq.h>
+
+#include <trace/events/power.h>
+
+#include <xen/xen.h>
+#include <xen/events.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/platform.h>
+#include <xen/interface/sysctl.h>
+#include <asm/xen/hypercall.h>
+#include <asm/xen/hypervisor.h>
+
+#include "cpufreq_drv_ops.h"
+
+static int xen_nr_cpus;
+static int xen_irq;
+
+#define for_each_xen_cpu(cpu, mask)			\
+	for ((cpu) = -1;				\
+		(cpu) = cpumask_next((cpu), (mask)),	\
+		(cpu) < xen_nr_cpus;)
+
+static struct cpufreq_driver *cpufreq_driver;
+static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
+
+static DEFINE_SPINLOCK(cpufreq_driver_lock);
+
+/*
+ * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
+ * all cpufreq/hotplug/workqueue/etc related lock issues.
+ *
+ * The rules for this semaphore:
+ * - Any routine that wants to read from the policy structure will
+ *   do a down_read on this semaphore.
+ * - Any routine that will write to the policy structure and/or may take away
+ *   the policy altogether (eg. CPU hotplug), will hold this lock in write
+ *   mode before doing so.
+ *
+ * Additional rules:
+ * - Governor routines that can be called in cpufreq hotplug path should not
+ *   take this sem as top level hotplug notifier handler takes this.
+ * - Lock should not be held across
+ *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
+ */
+static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
+static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
+
+#define lock_policy_rwsem(mode, cpu)				\
+static int lock_policy_rwsem_##mode				\
+(int cpu)							\
+{								\
+	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);	\
+	BUG_ON(policy_cpu == -1);				\
+	down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));	\
+								\
+	return 0;						\
+}
+
+lock_policy_rwsem(write, cpu);
+
+static void unlock_policy_rwsem_write(int cpu)
+{
+	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
+	BUG_ON(policy_cpu == -1);
+	up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
+}
+
+/**
+ * The "transition" notifier list for kernel code that needs to handle
+ * changes to devices when the CPU clock speed changes.
+ * The mutex locks this list.
+ */
+static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
+
+static bool init_cpufreq_transition_notifier_list_called;
+static int __init init_cpufreq_transition_notifier_list(void)
+{
+	srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
+	init_cpufreq_transition_notifier_list_called = true;
+	return 0;
+}
+pure_initcall(init_cpufreq_transition_notifier_list);
+
+static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
+{
+	struct cpufreq_policy *data = NULL;
+	unsigned long flags;
+
+	if (cpu >= xen_nr_cpus)
+		goto err_out;
+
+	/* get the cpufreq driver */
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+
+	if (!cpufreq_driver)
+		goto err_out_unlock;
+
+	/* get the CPU */
+	data = per_cpu(cpufreq_cpu_data, cpu);
+
+err_out_unlock:
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+err_out:
+	return data;
+}
+
+static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
+{
+	module_put(cpufreq_driver->owner);
+}
+
+static int push_data_to_hypervisor(struct cpufreq_policy *policy,
+				   struct cpufreq_frequency_table *table)
+{
+	int ret = 0;
+	unsigned int i;
+	unsigned int cpu;
+	uint32_t platform_limit = 0;
+	unsigned int max_freq = 0;
+	unsigned int state_count = 0;
+	unsigned int prev_freq = 0;
+	struct xen_processor_px *dst_states;
+	struct xen_processor_performance *dst_perf;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+
+	dst_perf = &op.u.set_pminfo.perf;
+
+	/* Check freq table and find max frequency */
+	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
+		unsigned int freq = table[i].frequency;
+		if (freq == CPUFREQ_ENTRY_INVALID)
+			continue;
+
+		if (table[i].index != state_count || freq <= prev_freq) {
+			pr_err("Frequency table format error\n");
+			return -EINVAL;
+		}
+
+		prev_freq = freq;
+		state_count++;
+		if (freq > max_freq)
+			max_freq = freq;
+	}
+
+	if (!state_count)
+		return -EINVAL;
+
+	dst_perf->state_count = state_count;
+
+	dst_states = kcalloc(state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+
+	if (!dst_states)
+		return -ENOMEM;
+
+	set_xen_guest_handle(dst_perf->states, dst_states);
+
+	/*
+	 * Freq table should start from lower values
+	 * dst_states should start from higer values
+	 */
+	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
+		unsigned int freq = table[i].frequency;
+		unsigned int tbl_index = state_count - 1 - table[i].index;
+		if (freq == CPUFREQ_ENTRY_INVALID)
+			continue;
+
+		if (freq == max_freq)
+			platform_limit = tbl_index;
+
+		dst_states[tbl_index].core_frequency = freq / 1000;
+		dst_states[tbl_index].transition_latency =
+				policy->cpuinfo.transition_latency / 1000;
+	}
+
+	dst_perf->shared_type = policy->shared_type;
+	dst_perf->platform_limit = platform_limit;
+	dst_perf->domain_info.domain = policy->cpu;
+	dst_perf->domain_info.num_processors = xen_nr_cpus;
+	dst_perf->flags = XEN_PX_DATA;
+
+	for_each_xen_cpu(cpu, policy->cpus) {
+		op.u.set_pminfo.id = cpu;
+		ret = HYPERVISOR_dom0_op(&op);
+		if (ret) {
+			pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
+			goto err_free_states;
+		}
+		pr_debug("CPU%u - P-states uploaded\n", cpu);
+
+		for (i = 0; i < dst_perf->state_count; i++) {
+			pr_debug("    state %d: %d MHz, %d uS\n",
+				 i, (u32) dst_states[i].core_frequency,
+				 (u32) dst_states[i].transition_latency);
+		}
+	}
+
+err_free_states:
+	kfree(dst_states);
+	return ret;
+}
+
+/*
+ * Returns:
+ *   Negative: Failure
+ *   0:        Success
+ *   Positive: When we have a managed CPU and the sysfs got symlinked
+ */
+static int xen_cpufreq_add_dev_policy(unsigned int cpu,
+				  struct cpufreq_policy *policy)
+{
+	int ret = 0;
+#ifdef CONFIG_SMP
+	unsigned long flags;
+	unsigned int j;
+
+	for_each_cpu(j, policy->cpus) {
+		struct cpufreq_policy *managed_policy;
+
+		if (cpu == j)
+			continue;
+
+		/* Check for existing affected CPUs.
+		 * They may not be aware of it due to CPU Hotplug.
+		 * cpufreq_cpu_put is called when the device is removed
+		 * in __cpufreq_remove_dev()
+		 */
+		managed_policy = xen_cpufreq_cpu_get(j);
+		if (unlikely(managed_policy)) {
+			/* Set proper policy_cpu */
+			unlock_policy_rwsem_write(cpu);
+			per_cpu(cpufreq_policy_cpu, cpu) =
+						managed_policy->cpu;
+
+			if (lock_policy_rwsem_write(cpu) < 0) {
+				/* Should not go through policy unlock path */
+				if (cpufreq_driver->exit)
+					cpufreq_driver->exit(policy);
+				xen_cpufreq_cpu_put(managed_policy);
+				return -EBUSY;
+			}
+
+			spin_lock_irqsave(&cpufreq_driver_lock, flags);
+			cpumask_copy(managed_policy->cpus, policy->cpus);
+			per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
+			spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+			pr_debug("CPU already managed, adding link\n");
+
+			/*
+			 * Success. We only needed to be added to the mask.
+			 * Call driver->exit() because only the cpu parent of
+			 * the kobj needed to call init().
+			 */
+			if (cpufreq_driver->exit)
+				cpufreq_driver->exit(policy);
+
+			return 1;
+		}
+	}
+#endif
+	return ret;
+}
+
+/**
+ * xen_cpufreq_add_dev - add a CPU device
+ *
+ * Adds the cpufreq interface for a CPU device.
+ */
+static int xen_cpufreq_add_dev(unsigned int cpu)
+{
+	int ret = 0;
+	struct cpufreq_policy *policy;
+	unsigned long flags;
+	unsigned int j;
+
+	pr_debug("adding CPU %u\n", cpu);
+
+#ifdef CONFIG_SMP
+	/* check whether a different CPU already registered this
+	 * CPU because it is in the same boat. */
+	policy = xen_cpufreq_cpu_get(cpu);
+	if (unlikely(policy)) {
+		xen_cpufreq_cpu_put(policy);
+		return 0;
+	}
+#endif
+
+	if (!try_module_get(cpufreq_driver->owner)) {
+		ret = -EINVAL;
+		goto module_out;
+	}
+
+	ret = -ENOMEM;
+	policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
+	if (!policy)
+		goto nomem_out;
+
+	if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
+		goto err_free_policy;
+
+	if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
+		goto err_free_cpumask;
+
+	policy->cpu = cpu;
+	cpumask_copy(policy->cpus, cpumask_of(cpu));
+
+	/* Initially set CPU itself as the policy_cpu */
+	per_cpu(cpufreq_policy_cpu, cpu) = cpu;
+	ret = (lock_policy_rwsem_write(cpu) < 0);
+	WARN_ON(ret);
+
+	/* call driver. From then on the cpufreq must be able
+	 * to accept all calls to ->verify and ->setpolicy for this CPU
+	 */
+	ret = cpufreq_driver->init(policy);
+	if (ret) {
+		pr_debug("initialization failed\n");
+		goto err_unlock_policy;
+	}
+	ret = xen_cpufreq_add_dev_policy(cpu, policy);
+	if (ret) {
+		if (ret > 0)
+			/* This is a managed cpu, symlink created,
+			   exit with 0 */
+			ret = 0;
+		goto err_unlock_policy;
+	}
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	for_each_cpu(j, policy->cpus) {
+		per_cpu(cpufreq_cpu_data, j) = policy;
+		per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
+	}
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	unlock_policy_rwsem_write(cpu);
+
+	module_put(cpufreq_driver->owner);
+	pr_debug("initialization complete\n");
+
+	return 0;
+
+err_unlock_policy:
+	unlock_policy_rwsem_write(cpu);
+	free_cpumask_var(policy->related_cpus);
+err_free_cpumask:
+	free_cpumask_var(policy->cpus);
+err_free_policy:
+	kfree(policy);
+nomem_out:
+	module_put(cpufreq_driver->owner);
+module_out:
+	return ret;
+}
+
+/**
+ * __cpufreq_remove_dev - remove a CPU device
+ *
+ * Removes the cpufreq interface for a CPU device.
+ * Caller should already have policy_rwsem in write mode for this CPU.
+ * This routine frees the rwsem before returning.
+ */
+static int __cpufreq_remove_dev(unsigned int cpu)
+{
+	unsigned long flags;
+	struct cpufreq_policy *data;
+#ifdef CONFIG_SMP
+	unsigned int j;
+#endif
+
+	pr_debug("unregistering CPU %u\n", cpu);
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	data = per_cpu(cpufreq_cpu_data, cpu);
+
+	if (!data) {
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		unlock_policy_rwsem_write(cpu);
+		return -EINVAL;
+	}
+	per_cpu(cpufreq_cpu_data, cpu) = NULL;
+
+
+#ifdef CONFIG_SMP
+	/* if this isn't the CPU which is the parent of the kobj, we
+	 * only need to unlink, put and exit
+	 */
+	if (unlikely(cpu != data->cpu)) {
+		pr_debug("removing link\n");
+		cpumask_clear_cpu(cpu, data->cpus);
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		xen_cpufreq_cpu_put(data);
+		unlock_policy_rwsem_write(cpu);
+		return 0;
+	}
+#endif
+
+#ifdef CONFIG_SMP
+
+	/* if we have other CPUs still registered, we need to unlink them,
+	 * or else wait_for_completion below will lock up. Clean the
+	 * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
+	 * the sysfs links afterwards.
+	 */
+	if (unlikely(cpumask_weight(data->cpus) > 1)) {
+		for_each_cpu(j, data->cpus) {
+			if (j == cpu)
+				continue;
+			per_cpu(cpufreq_cpu_data, j) = NULL;
+		}
+	}
+
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	if (unlikely(cpumask_weight(data->cpus) > 1)) {
+		for_each_cpu(j, data->cpus) {
+			if (j == cpu)
+				continue;
+			pr_debug("removing link for cpu %u\n", j);
+			unlock_policy_rwsem_write(cpu);
+			lock_policy_rwsem_write(cpu);
+			xen_cpufreq_cpu_put(data);
+		}
+	}
+#else
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+#endif
+
+	unlock_policy_rwsem_write(cpu);
+
+	lock_policy_rwsem_write(cpu);
+	if (cpufreq_driver->exit)
+		cpufreq_driver->exit(data);
+	unlock_policy_rwsem_write(cpu);
+
+	free_cpumask_var(data->related_cpus);
+	free_cpumask_var(data->cpus);
+	kfree(data);
+
+	return 0;
+}
+
+static int cpufreq_remove_dev(unsigned int cpu)
+{
+	int retval;
+
+	if (unlikely(lock_policy_rwsem_write(cpu)))
+		BUG();
+
+	retval = __cpufreq_remove_dev(cpu);
+	return retval;
+}
+
+/*********************************************************************
+ *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
+ *********************************************************************/
+
+/**
+ * adjust_jiffies - adjust the system "loops_per_jiffy"
+ *
+ * This function alters the system "loops_per_jiffy" for the clock
+ * speed change. Note that loops_per_jiffy cannot be updated on SMP
+ * systems as each CPU might be scaled differently. So, use the arch
+ * per-CPU loops_per_jiffy value wherever possible.
+ */
+#ifndef CONFIG_SMP
+static unsigned long l_p_j_ref;
+static unsigned int  l_p_j_ref_freq;
+
+static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
+{
+	if (ci->flags & CPUFREQ_CONST_LOOPS)
+		return;
+
+	if (!l_p_j_ref_freq) {
+		l_p_j_ref = loops_per_jiffy;
+		l_p_j_ref_freq = ci->old;
+		pr_debug("saving %lu as reference value for loops_per_jiffy; "
+			"freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
+	}
+	if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
+	    (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
+		loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
+								ci->new);
+		pr_debug("scaling loops_per_jiffy to %lu "
+			"for frequency %u kHz\n", loops_per_jiffy, ci->new);
+	}
+}
+#else
+static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
+{
+	return;
+}
+#endif
+
+
+/**
+ * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
+ * on frequency transition.
+ *
+ * This function calls the transition notifiers and the "adjust_jiffies"
+ * function. It is called twice on all CPU frequency changes that have
+ * external effects.
+ */
+void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
+				   unsigned int state)
+{
+	struct cpufreq_policy *policy;
+
+	BUG_ON(irqs_disabled());
+
+	freqs->flags = cpufreq_driver->flags;
+	pr_debug("notification %u of frequency transition to %u kHz\n",
+		 state, freqs->new);
+
+	policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
+	switch (state) {
+	case CPUFREQ_PRECHANGE:
+		/* detect if the driver reported a value as "old frequency"
+		 * which is not equal to what the cpufreq core thinks is
+		 * "old frequency".
+		 */
+		if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
+			if ((policy) && (policy->cpu == freqs->cpu) &&
+			    (policy->cur) && (policy->cur != freqs->old)) {
+				pr_debug("Warning: CPU frequency is"
+					 " %u, cpufreq assumed %u kHz.\n",
+					 freqs->old, policy->cur);
+				freqs->old = policy->cur;
+			}
+		}
+		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
+					 CPUFREQ_PRECHANGE, freqs);
+		adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
+		break;
+
+	case CPUFREQ_POSTCHANGE:
+		adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
+		pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
+			 (unsigned long)freqs->cpu);
+		trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
+		trace_cpu_frequency(freqs->new, freqs->cpu);
+		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
+					 CPUFREQ_POSTCHANGE, freqs);
+		if (likely(policy) && likely(policy->cpu == freqs->cpu))
+			policy->cur = freqs->new;
+		break;
+	}
+}
+
+/*********************************************************************
+ *                              GOVERNORS                            *
+ *********************************************************************/
+
+int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
+				unsigned int target_freq,
+				unsigned int relation)
+{
+	int retval = -EINVAL;
+	unsigned int old_target_freq = target_freq;
+
+	/* Make sure that target_freq is within supported range */
+	if (target_freq > policy->max)
+		target_freq = policy->max;
+	if (target_freq < policy->min)
+		target_freq = policy->min;
+
+	pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
+		 policy->cpu, target_freq, relation, old_target_freq);
+
+	if (target_freq == policy->cur)
+		return 0;
+
+	if (cpufreq_driver->target)
+		retval = cpufreq_driver->target(policy, target_freq,
+						    relation);
+
+	return retval;
+}
+
+int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
+			      unsigned int target_freq,
+			      unsigned int relation)
+{
+	int ret = -EINVAL;
+
+	if (!policy)
+		goto no_policy;
+
+	if (unlikely(lock_policy_rwsem_write(policy->cpu)))
+		goto fail;
+
+	ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
+
+	unlock_policy_rwsem_write(policy->cpu);
+
+fail:
+	xen_cpufreq_cpu_put(policy);
+no_policy:
+	return ret;
+}
+
+/*********************************************************************
+ *                    HANDLE COMMANDS FROM XEN                       *
+ *********************************************************************/
+static void cpufreq_work_hnd(struct work_struct *w);
+
+static struct workqueue_struct *cpufreq_wq;
+static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
+
+static void cpufreq_work_hnd(struct work_struct *w)
+{
+	int ret;
+	struct cpufreq_policy *policy;
+	struct cpufreq_sh_info *cpufreq_info;
+
+	cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
+
+	policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
+	ret = xen_cpufreq_driver_target(policy,
+					cpufreq_info->freq,
+					cpufreq_info->relation);
+
+	cpufreq_info->result = ret;
+}
+
+static irqreturn_t cpufreq_interrupt(int irq, void *data)
+{
+	queue_work(cpufreq_wq, &cpufreq_work);
+	return IRQ_HANDLED;
+}
+
+/*********************************************************************
+ *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
+ *********************************************************************/
+
+/**
+ * xen_cpufreq_register_driver - register a CPU Frequency driver
+ * @driver_data: A struct cpufreq_driver containing the values#
+ * submitted by the CPU Frequency driver.
+ *
+ *   Registers a CPU Frequency driver to this core code. This code
+ * returns zero on success, -EBUSY when another driver got here first
+ * (and isn't unregistered in the meantime).
+ *
+ */
+int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
+{
+	unsigned long flags;
+	int ret;
+	unsigned int cpu;
+	struct cpufreq_frequency_table *table;
+	struct cpufreq_policy *policy;
+	cpumask_var_t pushed_cpus;
+	int irq;
+
+	if (!xen_nr_cpus)
+		return -EPROBE_DEFER;
+
+	if (!driver_data || !driver_data->verify || !driver_data->init ||
+	    (!driver_data->target))
+		return -EINVAL;
+
+	pr_debug("trying to register driver %s\n", driver_data->name);
+
+	if (driver_data->setpolicy)
+		driver_data->flags |= CPUFREQ_CONST_LOOPS;
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+
+	if (cpufreq_driver) {
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		return -EBUSY;
+	}
+	cpufreq_driver = driver_data;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	irq = bind_virq_to_irq(VIRQ_CPUFREQ, 0);
+	if (irq < 0) {
+		pr_err("Bind virq (%d) error (%d)\n", VIRQ_CPUFREQ, irq);
+		ret = irq;
+		goto err_remove_drv;
+	}
+
+	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN|IRQ_NOPROBE);
+
+	ret = request_irq(irq, cpufreq_interrupt, 0,
+			   "xen_cpufreq", NULL);
+
+	if (ret < 0) {
+		pr_err("Request irq (%d) error (%d)\n", irq, ret);
+		goto err_unbind_from_irqhnd;
+	}
+
+	xen_irq = irq;
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
+		ret = xen_cpufreq_add_dev(cpu);
+		if (ret)
+			goto err_remove_cpu;
+	}
+
+	if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
+		goto err_remove_cpu;
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
+		if (cpumask_test_cpu(cpu, pushed_cpus))
+			continue;
+
+		policy = xen_cpufreq_cpu_get(cpu);
+		if (!policy) {
+			ret = -EINVAL;
+			goto err_free_cpumask;
+		}
+
+		cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
+		table = cpufreq_frequency_get_table(policy->cpu);
+		if (!table) {
+			ret = -EINVAL;
+			goto err_free_cpumask;
+		}
+
+		ret = push_data_to_hypervisor(policy, table);
+		if (ret)
+			goto err_free_cpumask;
+	}
+
+	free_cpumask_var(pushed_cpus);
+
+	pr_debug("driver %s up and running\n", driver_data->name);
+
+	return 0;
+
+err_free_cpumask:
+	free_cpumask_var(pushed_cpus);
+err_remove_cpu:
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
+		cpufreq_remove_dev(cpu);
+err_unbind_from_irqhnd:
+	unbind_from_irqhandler(irq, NULL);
+err_remove_drv:
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	cpufreq_driver = NULL;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+	return ret;
+}
+
+/**
+ * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
+ *
+ *    Unregister the current CPUFreq driver. Only call this if you have
+ * the right to do so, i.e. if you have succeeded in initialising before!
+ * Returns zero if successful, and -EINVAL if the cpufreq_driver is
+ * currently not initialised.
+ */
+int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
+{
+	unsigned long flags;
+	unsigned int cpu;
+
+	if (!cpufreq_driver || (driver != cpufreq_driver))
+		return -EINVAL;
+
+	pr_debug("unregistering driver %s\n", driver->name);
+
+	unbind_from_irqhandler(xen_irq, NULL);
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
+		cpufreq_remove_dev(cpu);
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	cpufreq_driver = NULL;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	return 0;
+}
+
+struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
+	.notify_transition = xen_cpufreq_notify_transition,
+	.register_driver = xen_cpufreq_register_driver,
+	.unregister_driver = xen_cpufreq_unregister_driver,
+};
+
+static int __init xen_cpufreq_init(void)
+{
+	int ret;
+	int i;
+
+	struct xen_sysctl op = {
+		.cmd			= XEN_SYSCTL_physinfo,
+		.interface_version	= XEN_SYSCTL_INTERFACE_VERSION,
+	};
+
+	ret = HYPERVISOR_sysctl(&op);
+	if (ret) {
+		pr_err("Hypervisor get physinfo error (%d)\n", ret);
+		return ret;
+	}
+
+	xen_nr_cpus = op.u.physinfo.nr_cpus;
+	if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
+		xen_nr_cpus = 0;
+		pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < xen_nr_cpus; i++) {
+		per_cpu(cpufreq_policy_cpu, i) = -1;
+		init_rwsem(&per_cpu(cpu_policy_rwsem, i));
+	}
+
+	cpufreq_wq = alloc_workqueue("xen_cpufreq", 0, 1);
+	if (!cpufreq_wq) {
+		pr_err("Create workqueue error\n");
+		ret = -ENOMEM;
+		goto err_create_wq;
+	}
+
+	return 0;
+
+err_create_wq:
+	xen_nr_cpus = 0;
+	return ret;
+}
+
+MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
+MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+core_initcall(xen_cpufreq_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c57d5f6..ee3b154 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
 #define XEN_PX_PSS   2
 #define XEN_PX_PPC   4
 #define XEN_PX_PSD   8
+#define XEN_PX_DATA  16
 
 struct xen_power_register {
 	uint32_t     space_id;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index cf64566..9133110 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -81,6 +81,7 @@
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
 #define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
+#define VIRQ_CPUFREQ    14 /* (DOM0) Notify cpufreq driver                */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1XldwX-0007fC-E0; Tue, 04 Nov 2014 13:14:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XldwW-0007f7-P5
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:14:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BC/E5-24532-041D8545; Tue, 04 Nov 2014 13:14:40 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415106879!5381737!1
X-Originating-IP: [74.125.82.45]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21315 invoked from network); 4 Nov 2014 13:14:39 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:14:39 -0000
Received: by mail-wg0-f45.google.com with SMTP id x12so13516357wgg.32
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:14:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=L7Vd92uJ4G6vq5VkGYK5XaCDczovbPk5Io5tBwS1PpI=;
	b=jZ56GcEGWnsdt+rsds7omGK5u/NMttt1QuTW+g0OWVDFfn7skn+82SR7zK7cT9AFpt
	2YSKdBATcEJwnLukmihHizQTCUb8wXZGboH3DsqLf0zzERAXA3rXzk7oIVVTPeFwI0A6
	cI0hxpao0l8cDF2hpx9pfeGe/huljDmZW6T3mJpLYLrONYqXITDMy9AmTnCYQebppGfS
	KxOqKYi4VrIqevddhtWNLENIKFM5gaAbt3w9AgDW0Gs7AM3ZLv8WIzemdpzy6Tfd88YR
	nxO4GH5d99+BoQs7Sn6+SVa1VYyV4vQyTa9dlU5Ov/LteAc1SCPeRYUX/UOHs0xIigbs
	G4FA==
X-Gm-Message-State: ALoCoQl47XumV53E0LcbMqnafZbkzQ2sCYkpmBVLp84zLA7801RPT8H1/C8cNyt/O1KNQyPjmD3v
X-Received: by 10.180.149.242 with SMTP id ud18mr23752849wib.58.1415106879367; 
	Tue, 04 Nov 2014 05:14:39 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id bj7sm489457wjc.33.2014.11.04.05.14.37
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:14:38 -0800 (PST)
Message-ID: <5458D137.3030604@linaro.org>
Date: Tue, 04 Nov 2014 13:14:31 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-2-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-2-git-send-email-frediano.ziglio@huawei.com>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 1/7] xen/device_tree: Add new helper to
 read arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> 
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>

You forgot to keep my reviewed-by from the last version.

Regards,

> ---
>  xen/common/device_tree.c      | 13 ++++++++++---
>  xen/include/xen/device_tree.h | 11 +++++++++++
>  2 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index f72b2e9..1a886c0 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -160,14 +160,21 @@ const void *dt_get_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                           const char *name, u32 *out_value)
>  {
> -    u32 len;
> +    return dt_property_read_u32_array(np, name, out_value, 1);
> +}
> +
> +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> +                                  const char *name, u32 *out_value, u16 out_len)
> +{
> +    u32 len, i;
>      const __be32 *val;
>  
>      val = dt_get_property(np, name, &len);
> -    if ( !val || len < sizeof(*out_value) )
> +    if ( !val || len < sizeof(*out_value) * out_len )
>          return 0;
>  
> -    *out_value = be32_to_cpup(val);
> +    for ( i = 0; i < out_len; i++, val++ )
> +        out_value[i] = be32_to_cpup(val);
>  
>      return 1;
>  }
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 08db8bc..629bfb2 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                              const char *name, u32 *out_value);
>  /**
> + * dt_property_read_u32_array - Helper to read a u32 array property.
> + * @np: node to get the value
> + * @name: name of the property
> + * @out_value: pointer to return value
> + * @out_len: length of the array
> + *
> + * Return true if get the desired value.
> + */
> +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> +                                  const char *name, u32 *out_value, u16 out_len);
> +/**
>   * dt_property_read_u64 - Helper to read a u64 property.
>   * @np: node to get the value
>   * @name: name of the property
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1XldwX-0007fC-E0; Tue, 04 Nov 2014 13:14:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XldwW-0007f7-P5
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:14:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BC/E5-24532-041D8545; Tue, 04 Nov 2014 13:14:40 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415106879!5381737!1
X-Originating-IP: [74.125.82.45]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21315 invoked from network); 4 Nov 2014 13:14:39 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:14:39 -0000
Received: by mail-wg0-f45.google.com with SMTP id x12so13516357wgg.32
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:14:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=L7Vd92uJ4G6vq5VkGYK5XaCDczovbPk5Io5tBwS1PpI=;
	b=jZ56GcEGWnsdt+rsds7omGK5u/NMttt1QuTW+g0OWVDFfn7skn+82SR7zK7cT9AFpt
	2YSKdBATcEJwnLukmihHizQTCUb8wXZGboH3DsqLf0zzERAXA3rXzk7oIVVTPeFwI0A6
	cI0hxpao0l8cDF2hpx9pfeGe/huljDmZW6T3mJpLYLrONYqXITDMy9AmTnCYQebppGfS
	KxOqKYi4VrIqevddhtWNLENIKFM5gaAbt3w9AgDW0Gs7AM3ZLv8WIzemdpzy6Tfd88YR
	nxO4GH5d99+BoQs7Sn6+SVa1VYyV4vQyTa9dlU5Ov/LteAc1SCPeRYUX/UOHs0xIigbs
	G4FA==
X-Gm-Message-State: ALoCoQl47XumV53E0LcbMqnafZbkzQ2sCYkpmBVLp84zLA7801RPT8H1/C8cNyt/O1KNQyPjmD3v
X-Received: by 10.180.149.242 with SMTP id ud18mr23752849wib.58.1415106879367; 
	Tue, 04 Nov 2014 05:14:39 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id bj7sm489457wjc.33.2014.11.04.05.14.37
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:14:38 -0800 (PST)
Message-ID: <5458D137.3030604@linaro.org>
Date: Tue, 04 Nov 2014 13:14:31 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-2-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-2-git-send-email-frediano.ziglio@huawei.com>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 1/7] xen/device_tree: Add new helper to
 read arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> 
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>

You forgot to keep my reviewed-by from the last version.

Regards,

> ---
>  xen/common/device_tree.c      | 13 ++++++++++---
>  xen/include/xen/device_tree.h | 11 +++++++++++
>  2 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index f72b2e9..1a886c0 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -160,14 +160,21 @@ const void *dt_get_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                           const char *name, u32 *out_value)
>  {
> -    u32 len;
> +    return dt_property_read_u32_array(np, name, out_value, 1);
> +}
> +
> +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> +                                  const char *name, u32 *out_value, u16 out_len)
> +{
> +    u32 len, i;
>      const __be32 *val;
>  
>      val = dt_get_property(np, name, &len);
> -    if ( !val || len < sizeof(*out_value) )
> +    if ( !val || len < sizeof(*out_value) * out_len )
>          return 0;
>  
> -    *out_value = be32_to_cpup(val);
> +    for ( i = 0; i < out_len; i++, val++ )
> +        out_value[i] = be32_to_cpup(val);
>  
>      return 1;
>  }
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 08db8bc..629bfb2 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
>  bool_t dt_property_read_u32(const struct dt_device_node *np,
>                              const char *name, u32 *out_value);
>  /**
> + * dt_property_read_u32_array - Helper to read a u32 array property.
> + * @np: node to get the value
> + * @name: name of the property
> + * @out_value: pointer to return value
> + * @out_len: length of the array
> + *
> + * Return true if get the desired value.
> + */
> +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> +                                  const char *name, u32 *out_value, u16 out_len);
> +/**
>   * dt_property_read_u64 - Helper to read a u64 property.
>   * @np: node to get the value
>   * @name: name of the property
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:21:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xle2y-0007yg-Eu; Tue, 04 Nov 2014 13:21:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xle2x-0007yI-F6
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:21:19 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	8D/AB-27623-EC2D8545; Tue, 04 Nov 2014 13:21:18 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415107278!7112702!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15264 invoked from network); 4 Nov 2014 13:21:18 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:21:18 -0000
Received: by mail-wi0-f178.google.com with SMTP id q5so9258173wiv.5
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:21:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=fWBYH000wOb3uqfTukVoh0wWVTG7f/BYhf2E2xGRHOg=;
	b=WRSkHjCCmEoAdY4GZhOqKzZExa8z66aDvsoZ2Lx62ZyZFDDiyVTLk44GTgTdeTgVOK
	mdXj6O6/s7Vl4QiK5338wjQ3Ren0B9hRmL3kXzRUWT3vkLH+aAC7FQwoBTrVAT8EhIJx
	0EHj+RjVYpsRQ6tufUIfgRrUl4LosoMdaAvfLdKlzQI5U3HT/YKlJ/1ChgD5DXGlQBS5
	mhIotxlvMGLnQWz3Dcc/U79TfW6t9aDN1RS4U9DfQmU8L5wS/sFhPxANHXhVDRUjSXL5
	4L/bDQ8KbJOMOcungGw98rBSmq84j8tqa7f6gmi5t2Ppv6NW6/BpSw+pyQxKtDJ2g7yu
	dAeQ==
X-Gm-Message-State: ALoCoQnTwlm10+1aUBwUrdHmsOxa9b1ScTxEgwQjZCLdYCHw6M6S5TbuqqJ4HUletskAtp0clJq/
X-Received: by 10.194.237.162 with SMTP id vd2mr56514377wjc.52.1415107277960; 
	Tue, 04 Nov 2014 05:21:17 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	ji10sm12266942wid.7.2014.11.04.05.21.16 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:21:17 -0800 (PST)
Message-ID: <5458D2C5.7050900@linaro.org>
Date: Tue, 04 Nov 2014 13:21:09 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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

Hi Frediano,

On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> Add this new platform to Xen.
> This platform requires specific code to initialize CPUs.

I guess your platform doesn't support PSCI?

> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
> +static void hip04_reset(void)
> +{
> +    unsigned long data;
> +
> +    if ( !gb2 )
> +        return;

gb2 will never be NULL. Xen will panic if the initialization callback
failed.

> +
> +    data = readl_relaxed(gb2);
> +    writel_relaxed(data & ~0x4000000u, gb2);
> +
> +    mdelay(10);
> +}
> +
> +static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
> +{
> +    unsigned long data;
> +
> +    if ( !fabric )
> +        return;

Ditto.


[..]

> +static void __init hip04_iounmap(void __iomem **p)
> +{
> +    if ( *p )
> +    {
> +        iounmap(*p);
> +        *p = NULL;
> +    }
> +}

What is used for? Should not iounmap enough?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:21:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xle2y-0007yg-Eu; Tue, 04 Nov 2014 13:21:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xle2x-0007yI-F6
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:21:19 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	8D/AB-27623-EC2D8545; Tue, 04 Nov 2014 13:21:18 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415107278!7112702!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15264 invoked from network); 4 Nov 2014 13:21:18 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:21:18 -0000
Received: by mail-wi0-f178.google.com with SMTP id q5so9258173wiv.5
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:21:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=fWBYH000wOb3uqfTukVoh0wWVTG7f/BYhf2E2xGRHOg=;
	b=WRSkHjCCmEoAdY4GZhOqKzZExa8z66aDvsoZ2Lx62ZyZFDDiyVTLk44GTgTdeTgVOK
	mdXj6O6/s7Vl4QiK5338wjQ3Ren0B9hRmL3kXzRUWT3vkLH+aAC7FQwoBTrVAT8EhIJx
	0EHj+RjVYpsRQ6tufUIfgRrUl4LosoMdaAvfLdKlzQI5U3HT/YKlJ/1ChgD5DXGlQBS5
	mhIotxlvMGLnQWz3Dcc/U79TfW6t9aDN1RS4U9DfQmU8L5wS/sFhPxANHXhVDRUjSXL5
	4L/bDQ8KbJOMOcungGw98rBSmq84j8tqa7f6gmi5t2Ppv6NW6/BpSw+pyQxKtDJ2g7yu
	dAeQ==
X-Gm-Message-State: ALoCoQnTwlm10+1aUBwUrdHmsOxa9b1ScTxEgwQjZCLdYCHw6M6S5TbuqqJ4HUletskAtp0clJq/
X-Received: by 10.194.237.162 with SMTP id vd2mr56514377wjc.52.1415107277960; 
	Tue, 04 Nov 2014 05:21:17 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	ji10sm12266942wid.7.2014.11.04.05.21.16 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:21:17 -0800 (PST)
Message-ID: <5458D2C5.7050900@linaro.org>
Date: Tue, 04 Nov 2014 13:21:09 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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

Hi Frediano,

On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> Add this new platform to Xen.
> This platform requires specific code to initialize CPUs.

I guess your platform doesn't support PSCI?

> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
> +static void hip04_reset(void)
> +{
> +    unsigned long data;
> +
> +    if ( !gb2 )
> +        return;

gb2 will never be NULL. Xen will panic if the initialization callback
failed.

> +
> +    data = readl_relaxed(gb2);
> +    writel_relaxed(data & ~0x4000000u, gb2);
> +
> +    mdelay(10);
> +}
> +
> +static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
> +{
> +    unsigned long data;
> +
> +    if ( !fabric )
> +        return;

Ditto.


[..]

> +static void __init hip04_iounmap(void __iomem **p)
> +{
> +    if ( *p )
> +    {
> +        iounmap(*p);
> +        *p = NULL;
> +    }
> +}

What is used for? Should not iounmap enough?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:32:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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.xen.org>)
	id 1XleDT-0008NO-Sl; Tue, 04 Nov 2014 13:32:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleDS-0008NJ-Ib
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:32:10 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	EB/5F-14727-955D8545; Tue, 04 Nov 2014 13:32:09 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415107927!11118573!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10132 invoked from network); 4 Nov 2014 13:32:07 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:32:07 -0000
Received: by mail-wi0-f173.google.com with SMTP id n3so9398543wiv.6
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:32:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=16q7cpUDeg4GcO/6ExGUuGAB49ovj1bnZd8WzHELw74=;
	b=Ek43Hc/0JmSrC+W1kY7i2tsQqWOG9C9cYNR6WHkgJSRJyEW9KIPr9QsE5qtAkZ+/LZ
	fFzPisNfqJtSQikQuz9dpF2xVqsEsthw2kvCzbA91xH1S9UyQQduFYfbzoky/26LauLY
	UEq/onr3VkeeFlPvS73p/LAFf7NNdf41LcgYgrONtXslUozgCPm9iNp+SQq9CMzcKgHM
	YNbV9JMZZQCyvN4/k5+Px/jVDufOMrXHYzfyiEP+hq23hmI2fADHPvvKGdTiQlot8HAi
	KYgryKCaarIZEiqvqKRErCKy4rbbnHVFCAN/PDnMWHHXaVsc3lkJfCTFEJtirv9Ftbt7
	Tl+A==
X-Gm-Message-State: ALoCoQmDzkZGYlZb2hu7/3eDwq67xYGKvWmNDYalz0XULldU0UUVbd8fbYoLhrcVNyySvTsMM65g
X-Received: by 10.194.48.116 with SMTP id k20mr57476395wjn.7.1415107927525;
	Tue, 04 Nov 2014 05:32:07 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id f9sm541443wjw.31.2014.11.04.05.32.06
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:32:06 -0800 (PST)
Message-ID: <5458D54F.10007@linaro.org>
Date: Tue, 04 Nov 2014 13:31:59 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 3/7] xen/arm: Make gic-v2 code handle
	hip04-d01 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 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> The GIC in this platform is mainly compatible with the standard
> GICv2 beside:
> - ITARGET is extended to 16 bit to support 16 CPUs;
> - SGI mask is extended to support 16 CPUs;
> - maximum supported interrupt is 510.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c     | 89 +++++++++++++++++++++++++++++++++++++++--------
>  xen/arch/arm/gic.c        |  3 +-
>  xen/include/asm-arm/gic.h |  4 ++-
>  3 files changed, 80 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index faad1ff..9461fe3 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -79,16 +79,23 @@ static struct gic_info gicv2_info;
>   * logical CPU numbering. Let's use mapping as returned by the GIC
>   * itself
>   */
> -static DEFINE_PER_CPU(u8, gic_cpu_id);
> +static DEFINE_PER_CPU(u16, gic_cpu_id);
>  
>  /* Maximum cpu interface per GIC */
> -#define NR_GIC_CPU_IF 8
> +static unsigned int nr_gic_cpu_if = 8;
> +static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
> +static unsigned int gic_cpu_mask = 0xff;
>  
>  static inline void writeb_gicd(uint8_t val, unsigned int offset)
>  {
>      writeb_relaxed(val, gicv2.map_dbase + offset);
>  }
>  
> +static inline void writew_gicd(uint16_t val, unsigned int offset)
> +{
> +    writew_relaxed(val, gicv2.map_dbase + offset);
> +}
> +
>  static inline void writel_gicd(uint32_t val, unsigned int offset)
>  {
>      writel_relaxed(val, gicv2.map_dbase + offset);
> @@ -132,7 +139,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
>      cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
>      for_each_cpu( cpu, &possible_mask )
>      {
> -        ASSERT(cpu < NR_GIC_CPU_IF);
> +        ASSERT(cpu < nr_gic_cpu_if);
>          mask |= per_cpu(gic_cpu_id, cpu);
>      }
>  
> @@ -203,6 +210,15 @@ static unsigned int gicv2_read_irq(void)
>      return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
>  }
>  
> +/* Set target CPU mask (RAZ/WI on uniprocessor) */
> +static void gicv2_set_irq_mask(int irq, unsigned int mask)
> +{
> +    if ( nr_gic_cpu_if == 16 )

This check is very confusing, and even more in patch #5.

Code executed under this check describes your platform and not a generic
16-CPU support (actually there is no spec for it).

I would introduce a new boolean or hide this check in a macro.

> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..8050a65 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>  void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>  {
>      unsigned int irq;
> +    unsigned int max_irq = gic_hw_ops->info->nr_lines;
>  
>      do  {
>          /* Reading IRQ will ACK it */
>          irq = gic_hw_ops->read_irq();
>  
> -        if ( likely(irq >= 16 && irq < 1021) )
> +        if ( likely(irq >= 16 && irq < max_irq) )

On the previous version I've asked that need to explain in the commit
message why this change is valid.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:32:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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.xen.org>)
	id 1XleDT-0008NO-Sl; Tue, 04 Nov 2014 13:32:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleDS-0008NJ-Ib
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:32:10 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	EB/5F-14727-955D8545; Tue, 04 Nov 2014 13:32:09 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415107927!11118573!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10132 invoked from network); 4 Nov 2014 13:32:07 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:32:07 -0000
Received: by mail-wi0-f173.google.com with SMTP id n3so9398543wiv.6
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:32:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=16q7cpUDeg4GcO/6ExGUuGAB49ovj1bnZd8WzHELw74=;
	b=Ek43Hc/0JmSrC+W1kY7i2tsQqWOG9C9cYNR6WHkgJSRJyEW9KIPr9QsE5qtAkZ+/LZ
	fFzPisNfqJtSQikQuz9dpF2xVqsEsthw2kvCzbA91xH1S9UyQQduFYfbzoky/26LauLY
	UEq/onr3VkeeFlPvS73p/LAFf7NNdf41LcgYgrONtXslUozgCPm9iNp+SQq9CMzcKgHM
	YNbV9JMZZQCyvN4/k5+Px/jVDufOMrXHYzfyiEP+hq23hmI2fADHPvvKGdTiQlot8HAi
	KYgryKCaarIZEiqvqKRErCKy4rbbnHVFCAN/PDnMWHHXaVsc3lkJfCTFEJtirv9Ftbt7
	Tl+A==
X-Gm-Message-State: ALoCoQmDzkZGYlZb2hu7/3eDwq67xYGKvWmNDYalz0XULldU0UUVbd8fbYoLhrcVNyySvTsMM65g
X-Received: by 10.194.48.116 with SMTP id k20mr57476395wjn.7.1415107927525;
	Tue, 04 Nov 2014 05:32:07 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id f9sm541443wjw.31.2014.11.04.05.32.06
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:32:06 -0800 (PST)
Message-ID: <5458D54F.10007@linaro.org>
Date: Tue, 04 Nov 2014 13:31:59 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 3/7] xen/arm: Make gic-v2 code handle
	hip04-d01 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 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> The GIC in this platform is mainly compatible with the standard
> GICv2 beside:
> - ITARGET is extended to 16 bit to support 16 CPUs;
> - SGI mask is extended to support 16 CPUs;
> - maximum supported interrupt is 510.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c     | 89 +++++++++++++++++++++++++++++++++++++++--------
>  xen/arch/arm/gic.c        |  3 +-
>  xen/include/asm-arm/gic.h |  4 ++-
>  3 files changed, 80 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index faad1ff..9461fe3 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -79,16 +79,23 @@ static struct gic_info gicv2_info;
>   * logical CPU numbering. Let's use mapping as returned by the GIC
>   * itself
>   */
> -static DEFINE_PER_CPU(u8, gic_cpu_id);
> +static DEFINE_PER_CPU(u16, gic_cpu_id);
>  
>  /* Maximum cpu interface per GIC */
> -#define NR_GIC_CPU_IF 8
> +static unsigned int nr_gic_cpu_if = 8;
> +static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
> +static unsigned int gic_cpu_mask = 0xff;
>  
>  static inline void writeb_gicd(uint8_t val, unsigned int offset)
>  {
>      writeb_relaxed(val, gicv2.map_dbase + offset);
>  }
>  
> +static inline void writew_gicd(uint16_t val, unsigned int offset)
> +{
> +    writew_relaxed(val, gicv2.map_dbase + offset);
> +}
> +
>  static inline void writel_gicd(uint32_t val, unsigned int offset)
>  {
>      writel_relaxed(val, gicv2.map_dbase + offset);
> @@ -132,7 +139,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
>      cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
>      for_each_cpu( cpu, &possible_mask )
>      {
> -        ASSERT(cpu < NR_GIC_CPU_IF);
> +        ASSERT(cpu < nr_gic_cpu_if);
>          mask |= per_cpu(gic_cpu_id, cpu);
>      }
>  
> @@ -203,6 +210,15 @@ static unsigned int gicv2_read_irq(void)
>      return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
>  }
>  
> +/* Set target CPU mask (RAZ/WI on uniprocessor) */
> +static void gicv2_set_irq_mask(int irq, unsigned int mask)
> +{
> +    if ( nr_gic_cpu_if == 16 )

This check is very confusing, and even more in patch #5.

Code executed under this check describes your platform and not a generic
16-CPU support (actually there is no spec for it).

I would introduce a new boolean or hide this check in a macro.

> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..8050a65 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>  void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>  {
>      unsigned int irq;
> +    unsigned int max_irq = gic_hw_ops->info->nr_lines;
>  
>      do  {
>          /* Reading IRQ will ACK it */
>          irq = gic_hw_ops->read_irq();
>  
> -        if ( likely(irq >= 16 && irq < 1021) )
> +        if ( likely(irq >= 16 && irq < max_irq) )

On the previous version I've asked that need to explain in the commit
message why this change is valid.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:33:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:33:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleEb-0008RE-Az; Tue, 04 Nov 2014 13:33:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XleEZ-0008R7-8t
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:33:19 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	58/F6-03148-E95D8545; Tue, 04 Nov 2014 13:33:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415107996!12441785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29494 invoked from network); 4 Nov 2014 13:33:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:33:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187896755"
Message-ID: <5458D599.2050100@citrix.com>
Date: Tue, 4 Nov 2014 13:33:13 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, <xen-devel@lists.xen.org>,
	<ian.jackson@eu.citrix.com>, <wei.liu2@citrix.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/14 11:52, Ian Campbell wrote:
> This was disabled by default in Xen 4.4. Since xend has now been removed from
> the tree I don't believe anything is using it.
> 
> We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xen-traditional otherwise
> it defaults to y and doesn't build.

It's too hard to find the changes to the common files in this diff.  It
would be better to split this into two patches: remove blktap from
build; and delete blktap directory.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:33:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:33:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleEb-0008RE-Az; Tue, 04 Nov 2014 13:33:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XleEZ-0008R7-8t
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:33:19 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	58/F6-03148-E95D8545; Tue, 04 Nov 2014 13:33:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415107996!12441785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29494 invoked from network); 4 Nov 2014 13:33:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:33:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187896755"
Message-ID: <5458D599.2050100@citrix.com>
Date: Tue, 4 Nov 2014 13:33:13 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, <xen-devel@lists.xen.org>,
	<ian.jackson@eu.citrix.com>, <wei.liu2@citrix.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/14 11:52, Ian Campbell wrote:
> This was disabled by default in Xen 4.4. Since xend has now been removed from
> the tree I don't believe anything is using it.
> 
> We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xen-traditional otherwise
> it defaults to y and doesn't build.

It's too hard to find the changes to the common files in this diff.  It
would be better to split this into two patches: remove blktap from
build; and delete blktap directory.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:33:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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.xen.org>)
	id 1XleEj-0008Sh-N4; Tue, 04 Nov 2014 13:33:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleEi-0008SR-8a
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:33:28 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	82/D3-02696-7A5D8545; Tue, 04 Nov 2014 13:33:27 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415108006!12441833!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31577 invoked from network); 4 Nov 2014 13:33:26 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:33:26 -0000
Received: by mail-wg0-f48.google.com with SMTP id m15so8116592wgh.35
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:33:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=GLHVkepvvgTzuoZvDp1+wCFI7k03kDarANL0DWFRT3o=;
	b=T0n8ivQ3Y4GuwQbTUKPlmFk+RR7nzGqPNdFeF3Jzy/cax9VU/CK9xD4R+SJIpGbl6I
	gafws9Rg/ddAWi6NQhLUKjP4hs26kvGRPSSepW3ApZMxIL7BrXZ7TENg5lX7UcJQyPQJ
	PXamv+u9Pc3bKQkszjdL+0KHjn1M/yzB4gACqawfUn33xYE8IZqMDVJXZPew8uMvrM2O
	r2s3Bm0dWbWSeV9XBke5po9wudjnNCzuMaPnmI3sg1DhGOISRgf70Q/gQNalgibLX+Io
	O5StTIa4ttJyTNrMLZdEOv19rvXXQ3LdviN5oSBIXzinnIf3E1LhWVUCGX79CC/AuQvP
	ZIaQ==
X-Gm-Message-State: ALoCoQkDEGpSWf4Dl40wz9C0BoQiUQIW7JJNPAs33s40TUAm/djT6Pbnpp2Um5CAxqL1hzbmL3c5
X-Received: by 10.194.248.162 with SMTP id yn2mr2856874wjc.16.1415108006602;
	Tue, 04 Nov 2014 05:33:26 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ud9sm562840wjc.20.2014.11.04.05.33.25
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:33:25 -0800 (PST)
Message-ID: <5458D59E.9010703@linaro.org>
Date: Tue, 04 Nov 2014 13:33:18 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-7-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-7-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 6/7] xen/arm: Force domains to use normal
 GICv2 driver on Hip04 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

Hi Frediano,

FYI, this is only force DOM0 to use the normal GICv2 drivers. I.e the
title of this patch is wrong.

Do you have any plan to support hi-silicon vGIC in Xen? This would allow
guest running with more than 8 cores.

Regards,

On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> Until vGIC support is not implemented and tested, this will prevent
> guest kernels to use their Hip04 driver, or crash when they don't
> have any.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 411b104..cea9edc 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -639,6 +639,12 @@ static int gicv2_make_dt_node(const struct domain *d,
>          return -FDT_ERR_XEN(ENOENT);
>      }
>  
> +    if ( nr_gic_cpu_if == 16 )
> +    {
> +        compatible = DT_COMPAT_GIC_CORTEX_A15;
> +        len = strlen((char*) compatible) + 1;
> +    }
> +
>      res = fdt_begin_node(fdt, "interrupt-controller");
>      if ( res )
>          return res;
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:33:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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.xen.org>)
	id 1XleEj-0008Sh-N4; Tue, 04 Nov 2014 13:33:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleEi-0008SR-8a
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:33:28 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	82/D3-02696-7A5D8545; Tue, 04 Nov 2014 13:33:27 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415108006!12441833!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31577 invoked from network); 4 Nov 2014 13:33:26 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:33:26 -0000
Received: by mail-wg0-f48.google.com with SMTP id m15so8116592wgh.35
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:33:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=GLHVkepvvgTzuoZvDp1+wCFI7k03kDarANL0DWFRT3o=;
	b=T0n8ivQ3Y4GuwQbTUKPlmFk+RR7nzGqPNdFeF3Jzy/cax9VU/CK9xD4R+SJIpGbl6I
	gafws9Rg/ddAWi6NQhLUKjP4hs26kvGRPSSepW3ApZMxIL7BrXZ7TENg5lX7UcJQyPQJ
	PXamv+u9Pc3bKQkszjdL+0KHjn1M/yzB4gACqawfUn33xYE8IZqMDVJXZPew8uMvrM2O
	r2s3Bm0dWbWSeV9XBke5po9wudjnNCzuMaPnmI3sg1DhGOISRgf70Q/gQNalgibLX+Io
	O5StTIa4ttJyTNrMLZdEOv19rvXXQ3LdviN5oSBIXzinnIf3E1LhWVUCGX79CC/AuQvP
	ZIaQ==
X-Gm-Message-State: ALoCoQkDEGpSWf4Dl40wz9C0BoQiUQIW7JJNPAs33s40TUAm/djT6Pbnpp2Um5CAxqL1hzbmL3c5
X-Received: by 10.194.248.162 with SMTP id yn2mr2856874wjc.16.1415108006602;
	Tue, 04 Nov 2014 05:33:26 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ud9sm562840wjc.20.2014.11.04.05.33.25
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:33:25 -0800 (PST)
Message-ID: <5458D59E.9010703@linaro.org>
Date: Tue, 04 Nov 2014 13:33:18 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-7-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-7-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 6/7] xen/arm: Force domains to use normal
 GICv2 driver on Hip04 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

Hi Frediano,

FYI, this is only force DOM0 to use the normal GICv2 drivers. I.e the
title of this patch is wrong.

Do you have any plan to support hi-silicon vGIC in Xen? This would allow
guest running with more than 8 cores.

Regards,

On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> Until vGIC support is not implemented and tested, this will prevent
> guest kernels to use their Hip04 driver, or crash when they don't
> have any.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 411b104..cea9edc 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -639,6 +639,12 @@ static int gicv2_make_dt_node(const struct domain *d,
>          return -FDT_ERR_XEN(ENOENT);
>      }
>  
> +    if ( nr_gic_cpu_if == 16 )
> +    {
> +        compatible = DT_COMPAT_GIC_CORTEX_A15;
> +        len = strlen((char*) compatible) + 1;
> +    }
> +
>      res = fdt_begin_node(fdt, "interrupt-controller");
>      if ( res )
>          return res;
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:34:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:34:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleFf-0000BG-5w; Tue, 04 Nov 2014 13:34:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleFd-0000B2-LD
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:34:25 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	90/14-27785-0E5D8545; Tue, 04 Nov 2014 13:34:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415108064!7834929!1
X-Originating-IP: [74.125.82.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3925 invoked from network); 4 Nov 2014 13:34:24 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:34:24 -0000
Received: by mail-wg0-f45.google.com with SMTP id x12so13635667wgg.18
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:34:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=YReMeBLVJqExmF0rlm6tH3bYmCU1G2aTee5mD/ZZlqw=;
	b=Te+vbuB4quXYVNWormA4WsaKhOHOdlya0T6th5ja7/3CcqHtPPbH9mHgRCLCXYxSNZ
	NO/guw4djlp3hjRCM25UK6JpLCrjadoec1ab3AAkIDyaFtIfzs8Z79blRt53kCrLD/fQ
	fVmgqRxBt1OaT7xcyki1k7PHVxDKdOZFGYJqZ43Q4QFSprmKFAD4IIBr+7VCGHie16NR
	eCUpjIcdB48hP4IsQvLidJYSfRcnaco8isQY675bpGbdq8DjJogO4zLk79/eS+t06Gsc
	xZwAPGKsBBkgEpr9hx2YmfDrvtj1KyZGxidQwOULj/lyLfmf9H+kDLInAT74DN2SalSR
	dl2w==
X-Gm-Message-State: ALoCoQk+euL49WyoolRRbdWWGozT40yVXbUGgwEh9UP88d2EMqaNuN9PkGKyKLD5Hg69Li3aPGU9
X-Received: by 10.194.59.81 with SMTP id x17mr12256780wjq.91.1415108061669;
	Tue, 04 Nov 2014 05:34:21 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id pn4sm536402wjc.38.2014.11.04.05.34.20
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:34:20 -0800 (PST)
Message-ID: <5458D5D6.9090903@linaro.org>
Date: Tue, 04 Nov 2014 13:34:14 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
	<5458D54F.10007@linaro.org>
In-Reply-To: <5458D54F.10007@linaro.org>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 3/7] xen/arm: Make gic-v2 code handle
	hip04-d01 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 11/04/2014 01:31 PM, Julien Grall wrote:
> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
>> The GIC in this platform is mainly compatible with the standard
>> GICv2 beside:
>> - ITARGET is extended to 16 bit to support 16 CPUs;
>> - SGI mask is extended to support 16 CPUs;
>> - maximum supported interrupt is 510.
>>
>> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
>> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
>> ---
>>  xen/arch/arm/gic-v2.c     | 89 +++++++++++++++++++++++++++++++++++++++--------
>>  xen/arch/arm/gic.c        |  3 +-
>>  xen/include/asm-arm/gic.h |  4 ++-
>>  3 files changed, 80 insertions(+), 16 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index faad1ff..9461fe3 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -79,16 +79,23 @@ static struct gic_info gicv2_info;
>>   * logical CPU numbering. Let's use mapping as returned by the GIC
>>   * itself
>>   */
>> -static DEFINE_PER_CPU(u8, gic_cpu_id);
>> +static DEFINE_PER_CPU(u16, gic_cpu_id);
>>  
>>  /* Maximum cpu interface per GIC */
>> -#define NR_GIC_CPU_IF 8
>> +static unsigned int nr_gic_cpu_if = 8;
>> +static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
>> +static unsigned int gic_cpu_mask = 0xff;
>>  
>>  static inline void writeb_gicd(uint8_t val, unsigned int offset)
>>  {
>>      writeb_relaxed(val, gicv2.map_dbase + offset);
>>  }
>>  
>> +static inline void writew_gicd(uint16_t val, unsigned int offset)
>> +{
>> +    writew_relaxed(val, gicv2.map_dbase + offset);
>> +}
>> +
>>  static inline void writel_gicd(uint32_t val, unsigned int offset)
>>  {
>>      writel_relaxed(val, gicv2.map_dbase + offset);
>> @@ -132,7 +139,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
>>      cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
>>      for_each_cpu( cpu, &possible_mask )
>>      {
>> -        ASSERT(cpu < NR_GIC_CPU_IF);
>> +        ASSERT(cpu < nr_gic_cpu_if);
>>          mask |= per_cpu(gic_cpu_id, cpu);
>>      }
>>  
>> @@ -203,6 +210,15 @@ static unsigned int gicv2_read_irq(void)
>>      return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
>>  }
>>  
>> +/* Set target CPU mask (RAZ/WI on uniprocessor) */
>> +static void gicv2_set_irq_mask(int irq, unsigned int mask)
>> +{
>> +    if ( nr_gic_cpu_if == 16 )
> 
> This check is very confusing, and even more in patch #5.

Sorry, I meant #7.

> Code executed under this check describes your platform and not a generic
> 16-CPU support (actually there is no spec for it).
> 
> I would introduce a new boolean or hide this check in a macro.
> 
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 70d10d6..8050a65 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>>  void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>>  {
>>      unsigned int irq;
>> +    unsigned int max_irq = gic_hw_ops->info->nr_lines;
>>  
>>      do  {
>>          /* Reading IRQ will ACK it */
>>          irq = gic_hw_ops->read_irq();
>>  
>> -        if ( likely(irq >= 16 && irq < 1021) )
>> +        if ( likely(irq >= 16 && irq < max_irq) )
> 
> On the previous version I've asked that need to explain in the commit
> message why this change is valid.
> 
> Regards,
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:34:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:34:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleFf-0000BG-5w; Tue, 04 Nov 2014 13:34:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleFd-0000B2-LD
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:34:25 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	90/14-27785-0E5D8545; Tue, 04 Nov 2014 13:34:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415108064!7834929!1
X-Originating-IP: [74.125.82.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3925 invoked from network); 4 Nov 2014 13:34:24 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:34:24 -0000
Received: by mail-wg0-f45.google.com with SMTP id x12so13635667wgg.18
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:34:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=YReMeBLVJqExmF0rlm6tH3bYmCU1G2aTee5mD/ZZlqw=;
	b=Te+vbuB4quXYVNWormA4WsaKhOHOdlya0T6th5ja7/3CcqHtPPbH9mHgRCLCXYxSNZ
	NO/guw4djlp3hjRCM25UK6JpLCrjadoec1ab3AAkIDyaFtIfzs8Z79blRt53kCrLD/fQ
	fVmgqRxBt1OaT7xcyki1k7PHVxDKdOZFGYJqZ43Q4QFSprmKFAD4IIBr+7VCGHie16NR
	eCUpjIcdB48hP4IsQvLidJYSfRcnaco8isQY675bpGbdq8DjJogO4zLk79/eS+t06Gsc
	xZwAPGKsBBkgEpr9hx2YmfDrvtj1KyZGxidQwOULj/lyLfmf9H+kDLInAT74DN2SalSR
	dl2w==
X-Gm-Message-State: ALoCoQk+euL49WyoolRRbdWWGozT40yVXbUGgwEh9UP88d2EMqaNuN9PkGKyKLD5Hg69Li3aPGU9
X-Received: by 10.194.59.81 with SMTP id x17mr12256780wjq.91.1415108061669;
	Tue, 04 Nov 2014 05:34:21 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id pn4sm536402wjc.38.2014.11.04.05.34.20
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:34:20 -0800 (PST)
Message-ID: <5458D5D6.9090903@linaro.org>
Date: Tue, 04 Nov 2014 13:34:14 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
	<5458D54F.10007@linaro.org>
In-Reply-To: <5458D54F.10007@linaro.org>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 3/7] xen/arm: Make gic-v2 code handle
	hip04-d01 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 11/04/2014 01:31 PM, Julien Grall wrote:
> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
>> The GIC in this platform is mainly compatible with the standard
>> GICv2 beside:
>> - ITARGET is extended to 16 bit to support 16 CPUs;
>> - SGI mask is extended to support 16 CPUs;
>> - maximum supported interrupt is 510.
>>
>> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
>> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
>> ---
>>  xen/arch/arm/gic-v2.c     | 89 +++++++++++++++++++++++++++++++++++++++--------
>>  xen/arch/arm/gic.c        |  3 +-
>>  xen/include/asm-arm/gic.h |  4 ++-
>>  3 files changed, 80 insertions(+), 16 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index faad1ff..9461fe3 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -79,16 +79,23 @@ static struct gic_info gicv2_info;
>>   * logical CPU numbering. Let's use mapping as returned by the GIC
>>   * itself
>>   */
>> -static DEFINE_PER_CPU(u8, gic_cpu_id);
>> +static DEFINE_PER_CPU(u16, gic_cpu_id);
>>  
>>  /* Maximum cpu interface per GIC */
>> -#define NR_GIC_CPU_IF 8
>> +static unsigned int nr_gic_cpu_if = 8;
>> +static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
>> +static unsigned int gic_cpu_mask = 0xff;
>>  
>>  static inline void writeb_gicd(uint8_t val, unsigned int offset)
>>  {
>>      writeb_relaxed(val, gicv2.map_dbase + offset);
>>  }
>>  
>> +static inline void writew_gicd(uint16_t val, unsigned int offset)
>> +{
>> +    writew_relaxed(val, gicv2.map_dbase + offset);
>> +}
>> +
>>  static inline void writel_gicd(uint32_t val, unsigned int offset)
>>  {
>>      writel_relaxed(val, gicv2.map_dbase + offset);
>> @@ -132,7 +139,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
>>      cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
>>      for_each_cpu( cpu, &possible_mask )
>>      {
>> -        ASSERT(cpu < NR_GIC_CPU_IF);
>> +        ASSERT(cpu < nr_gic_cpu_if);
>>          mask |= per_cpu(gic_cpu_id, cpu);
>>      }
>>  
>> @@ -203,6 +210,15 @@ static unsigned int gicv2_read_irq(void)
>>      return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
>>  }
>>  
>> +/* Set target CPU mask (RAZ/WI on uniprocessor) */
>> +static void gicv2_set_irq_mask(int irq, unsigned int mask)
>> +{
>> +    if ( nr_gic_cpu_if == 16 )
> 
> This check is very confusing, and even more in patch #5.

Sorry, I meant #7.

> Code executed under this check describes your platform and not a generic
> 16-CPU support (actually there is no spec for it).
> 
> I would introduce a new boolean or hide this check in a macro.
> 
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 70d10d6..8050a65 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>>  void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>>  {
>>      unsigned int irq;
>> +    unsigned int max_irq = gic_hw_ops->info->nr_lines;
>>  
>>      do  {
>>          /* Reading IRQ will ACK it */
>>          irq = gic_hw_ops->read_irq();
>>  
>> -        if ( likely(irq >= 16 && irq < 1021) )
>> +        if ( likely(irq >= 16 && irq < max_irq) )
> 
> On the previous version I've asked that need to explain in the commit
> message why this change is valid.
> 
> Regards,
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:36:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleHf-0000To-ST; Tue, 04 Nov 2014 13:36:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleHe-0000TW-RS
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:36:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DE/BF-24532-E56D8545; Tue, 04 Nov 2014 13:36:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415108189!12700313!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17685 invoked from network); 4 Nov 2014 13:36:29 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:36:29 -0000
Received: by mail-wi0-f181.google.com with SMTP id n3so9299733wiv.14
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:36:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=Q2bxJbWhJ/Vp2tcsypnjL8QeClJgeKAdNmyN/J30jzc=;
	b=KUIiJJTu9ge6NwDzYMXaKGuxTjN0mju14cZxjRGv8Wa2MPhhWeR94SKnpHAEJ4HPat
	yuqjHPR0ZOh+DF9dTfkmJ6pt0FmorhzRK8HkadaX0K5WOiLonJAs+P6uH+gYzTV67AAf
	cC8+0tYmZ5YvZUbJoosIk0WW0OQ3hlLGxBBWxej7O+RG8N1WSVYUErKju8J7zlyqlyn3
	KzVHRZ4aB9APghwHahWjzhq6p5ereJv8ljz8CVoveF0Qvq94+CBDjEr4pFqdsTXubBAr
	TVDXzLlvF/nf8rKtay+DzGTsCl6Dl8ifi7KDOPbh7aOGFXVbSYKbsXZff/3LZWwf/rlL
	dI/A==
X-Gm-Message-State: ALoCoQnBRUh8aunuXiA3vL9Z0AzvmzoIJoP6qR60zdKKClCyTlOPO1qsnZ4BfekJtZmDsJ5XN7Q9
X-Received: by 10.180.80.39 with SMTP id o7mr23370943wix.37.1415108162105;
	Tue, 04 Nov 2014 05:36:02 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id f1sm1064799wiy.17.2014.11.04.05.36.00
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:36:01 -0800 (PST)
Message-ID: <5458D63A.7050407@linaro.org>
Date: Tue, 04 Nov 2014 13:35:54 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 3/7] xen/arm: Make gic-v2 code handle
	hip04-d01 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 11/03/2014 04:46 PM, Frediano Ziglio wrote:
>  /* Set up the GIC */
> -static int __init gicv2_init(struct dt_device_node *node, const void *data)
> +static int __init gicv2_init_common(struct dt_device_node *node, const void *data, bool hip04)
>  {
>      int res;
>  
>      dt_device_set_used_by(node, DOMID_XEN);
>  
> +    if ( hip04 )
> +    {
> +        nr_gic_cpu_if = 16;
> +        gicd_sgi_target_shift = 8;
> +        gic_cpu_mask = 0xffff;
> +    }
> +

And this could be moved in hip04_gicv2_init. So there is no need of
adding a boolean to the arguments.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:36:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleHf-0000To-ST; Tue, 04 Nov 2014 13:36:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleHe-0000TW-RS
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:36:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DE/BF-24532-E56D8545; Tue, 04 Nov 2014 13:36:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415108189!12700313!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17685 invoked from network); 4 Nov 2014 13:36:29 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:36:29 -0000
Received: by mail-wi0-f181.google.com with SMTP id n3so9299733wiv.14
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:36:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=Q2bxJbWhJ/Vp2tcsypnjL8QeClJgeKAdNmyN/J30jzc=;
	b=KUIiJJTu9ge6NwDzYMXaKGuxTjN0mju14cZxjRGv8Wa2MPhhWeR94SKnpHAEJ4HPat
	yuqjHPR0ZOh+DF9dTfkmJ6pt0FmorhzRK8HkadaX0K5WOiLonJAs+P6uH+gYzTV67AAf
	cC8+0tYmZ5YvZUbJoosIk0WW0OQ3hlLGxBBWxej7O+RG8N1WSVYUErKju8J7zlyqlyn3
	KzVHRZ4aB9APghwHahWjzhq6p5ereJv8ljz8CVoveF0Qvq94+CBDjEr4pFqdsTXubBAr
	TVDXzLlvF/nf8rKtay+DzGTsCl6Dl8ifi7KDOPbh7aOGFXVbSYKbsXZff/3LZWwf/rlL
	dI/A==
X-Gm-Message-State: ALoCoQnBRUh8aunuXiA3vL9Z0AzvmzoIJoP6qR60zdKKClCyTlOPO1qsnZ4BfekJtZmDsJ5XN7Q9
X-Received: by 10.180.80.39 with SMTP id o7mr23370943wix.37.1415108162105;
	Tue, 04 Nov 2014 05:36:02 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id f1sm1064799wiy.17.2014.11.04.05.36.00
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:36:01 -0800 (PST)
Message-ID: <5458D63A.7050407@linaro.org>
Date: Tue, 04 Nov 2014 13:35:54 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 3/7] xen/arm: Make gic-v2 code handle
	hip04-d01 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 11/03/2014 04:46 PM, Frediano Ziglio wrote:
>  /* Set up the GIC */
> -static int __init gicv2_init(struct dt_device_node *node, const void *data)
> +static int __init gicv2_init_common(struct dt_device_node *node, const void *data, bool hip04)
>  {
>      int res;
>  
>      dt_device_set_used_by(node, DOMID_XEN);
>  
> +    if ( hip04 )
> +    {
> +        nr_gic_cpu_if = 16;
> +        gicd_sgi_target_shift = 8;
> +        gic_cpu_mask = 0xffff;
> +    }
> +

And this could be moved in hip04_gicv2_init. So there is no need of
adding a boolean to the arguments.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:38:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleJV-0000eg-Do; Tue, 04 Nov 2014 13:38:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleJT-0000eP-Qs
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:38:23 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	18/03-24532-FC6D8545; Tue, 04 Nov 2014 13:38:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415108302!12660110!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32238 invoked from network); 4 Nov 2014 13:38:22 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:38:22 -0000
Received: by mail-wg0-f44.google.com with SMTP id x12so13070865wgg.31
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:38:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=wLdATMUoIiy7cb77lrQggOtiNOXd/4ZHh+LAaV+GXJ4=;
	b=SZymTldBoLEVehFD/5Vl/0dBVPd8g7Vqj2EmZdIfEUz/t9Nesnrb2TQ29Lp7A2LgtG
	hgIn6sOp7hnex+GWBGYUsvLfCfcg/vWAz8n6BOLAHLbn8NvusLsqqX2NDduyf/TqyEj+
	HnoqC/WOA8bg9YZFb5ZALT0mkZ8aEkqGICEZR8QT1l8MD5PQ6pChp6YfSFxjvos+e22A
	JZvAEhhwOT7uI+w/oveCJDsYSj5M2VQ/u/O8sHsoAEYdro4LJrZ2J92zTiT8SX595KZv
	IP+ErW4mdlj9Hp51/zN4p9Ey6Zj/9Wk/BB2Uaj2+nh4OJBbxmRJuihnS7gMUp64MKOTi
	qMnw==
X-Gm-Message-State: ALoCoQnquEC2a6dbUEuggv8rYqnHUFx/iH/E4HzA3vZpq73LcUOP5y7jbudTQjzcpjJlfaHDwWQI
X-Received: by 10.180.98.170 with SMTP id ej10mr14515877wib.74.1415108301337; 
	Tue, 04 Nov 2014 05:38:21 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id q9sm12316854wix.6.2014.11.04.05.38.20
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:38:20 -0800 (PST)
Message-ID: <5458D6C5.7010307@linaro.org>
Date: Tue, 04 Nov 2014 13:38:13 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 7/7] xen/arm: Move vGIC registers on
	Hip04 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

Hi Frediano,

On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
>  xen/include/asm-arm/gic.h |  2 ++
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index cea9edc..eb8cc19 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -669,8 +669,19 @@ static int gicv2_make_dt_node(const struct domain *d,
>          return -FDT_ERR_XEN(ENOMEM);
>  
>      tmp = new_cells;
> -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> +
> +    if ( nr_gic_cpu_if == 16 )
> +    {
> +        dt_set_range(&tmp, node, d->arch.vgic.dbase - HIP04_VGIC_REG_OFFSET,
> +                     PAGE_SIZE);
> +        dt_set_range(&tmp, node, d->arch.vgic.cbase - HIP04_VGIC_REG_OFFSET,
> +                     PAGE_SIZE * 2);
> +    }
> +    else
> +    {
> +        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> +        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> +    }
>  
>      res = fdt_property(fdt, "reg", new_cells, len);
>      xfree(new_cells);
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 3d2b3db..5af8201 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -147,6 +147,8 @@
>  #define GICH_LR_PENDING         1
>  #define GICH_LR_ACTIVE          2
>  
> +#define HIP04_VGIC_REG_OFFSET   0xe0000000
> +

Please move this define in gic-v2.c. The header gic.h should only
contains value that needs to be shared with the vgic and/or the other
GIC drivers.

Also, where does come from the offset? Any pointer to the documentation?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:38:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleJV-0000eg-Do; Tue, 04 Nov 2014 13:38:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleJT-0000eP-Qs
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:38:23 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	18/03-24532-FC6D8545; Tue, 04 Nov 2014 13:38:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415108302!12660110!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32238 invoked from network); 4 Nov 2014 13:38:22 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:38:22 -0000
Received: by mail-wg0-f44.google.com with SMTP id x12so13070865wgg.31
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 05:38:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=wLdATMUoIiy7cb77lrQggOtiNOXd/4ZHh+LAaV+GXJ4=;
	b=SZymTldBoLEVehFD/5Vl/0dBVPd8g7Vqj2EmZdIfEUz/t9Nesnrb2TQ29Lp7A2LgtG
	hgIn6sOp7hnex+GWBGYUsvLfCfcg/vWAz8n6BOLAHLbn8NvusLsqqX2NDduyf/TqyEj+
	HnoqC/WOA8bg9YZFb5ZALT0mkZ8aEkqGICEZR8QT1l8MD5PQ6pChp6YfSFxjvos+e22A
	JZvAEhhwOT7uI+w/oveCJDsYSj5M2VQ/u/O8sHsoAEYdro4LJrZ2J92zTiT8SX595KZv
	IP+ErW4mdlj9Hp51/zN4p9Ey6Zj/9Wk/BB2Uaj2+nh4OJBbxmRJuihnS7gMUp64MKOTi
	qMnw==
X-Gm-Message-State: ALoCoQnquEC2a6dbUEuggv8rYqnHUFx/iH/E4HzA3vZpq73LcUOP5y7jbudTQjzcpjJlfaHDwWQI
X-Received: by 10.180.98.170 with SMTP id ej10mr14515877wib.74.1415108301337; 
	Tue, 04 Nov 2014 05:38:21 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id q9sm12316854wix.6.2014.11.04.05.38.20
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 05:38:20 -0800 (PST)
Message-ID: <5458D6C5.7010307@linaro.org>
Date: Tue, 04 Nov 2014 13:38:13 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 7/7] xen/arm: Move vGIC registers on
	Hip04 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

Hi Frediano,

On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
>  xen/include/asm-arm/gic.h |  2 ++
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index cea9edc..eb8cc19 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -669,8 +669,19 @@ static int gicv2_make_dt_node(const struct domain *d,
>          return -FDT_ERR_XEN(ENOMEM);
>  
>      tmp = new_cells;
> -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> +
> +    if ( nr_gic_cpu_if == 16 )
> +    {
> +        dt_set_range(&tmp, node, d->arch.vgic.dbase - HIP04_VGIC_REG_OFFSET,
> +                     PAGE_SIZE);
> +        dt_set_range(&tmp, node, d->arch.vgic.cbase - HIP04_VGIC_REG_OFFSET,
> +                     PAGE_SIZE * 2);
> +    }
> +    else
> +    {
> +        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> +        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> +    }
>  
>      res = fdt_property(fdt, "reg", new_cells, len);
>      xfree(new_cells);
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 3d2b3db..5af8201 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -147,6 +147,8 @@
>  #define GICH_LR_PENDING         1
>  #define GICH_LR_ACTIVE          2
>  
> +#define HIP04_VGIC_REG_OFFSET   0xe0000000
> +

Please move this define in gic-v2.c. The header gic.h should only
contains value that needs to be shared with the vgic and/or the other
GIC drivers.

Also, where does come from the offset? Any pointer to the documentation?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:53:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleXS-00011K-DT; Tue, 04 Nov 2014 13:52:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XleXQ-00011F-NZ
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:52:48 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	5D/11-02953-03AD8545; Tue, 04 Nov 2014 13:52:48 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415109167!7840513!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31586 invoked from network); 4 Nov 2014 13:52:47 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:52:47 -0000
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLG85168; Tue, 04 Nov 2014 13:52:41 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Tue, 4 Nov 2014 13:52:31 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 2/7] xen/arm: Implement hip04-d01 platform
Thread-Index: AQHP94XYH2ELvkaz70C3Jc5+gA7MLpxQdViAgAAIRqA=
Date: Tue, 4 Nov 2014 13:52:30 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B11C@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
	<5458D2C5.7050900@linaro.org>
In-Reply-To: <5458D2C5.7050900@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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

> 
> Hi Frediano,
> 
> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > Add this new platform to Xen.
> > This platform requires specific code to initialize CPUs.
> 
> I guess your platform doesn't support PSCI?
> 

No, there is no PSCI support.

> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > ---
> > +static void hip04_reset(void)
> > +{
> > +    unsigned long data;
> > +
> > +    if ( !gb2 )
> > +        return;
> 
> gb2 will never be NULL. Xen will panic if the initialization callback
> failed.
> 
> > +
> > +    data = readl_relaxed(gb2);
> > +    writel_relaxed(data & ~0x4000000u, gb2);
> > +
> > +    mdelay(10);
> > +}
> > +
> > +static void hip04_set_snoop_filter(unsigned int cluster, unsigned
> int
> > +on) {
> > +    unsigned long data;
> > +
> > +    if ( !fabric )
> > +        return;
> 
> Ditto.
> 

Done

> 
> [..]
> 
> > +static void __init hip04_iounmap(void __iomem **p) {
> > +    if ( *p )
> > +    {
> > +        iounmap(*p);
> > +        *p = NULL;
> > +    }
> > +}
> 
> What is used for? Should not iounmap enough?
> 

I just like to clear pointers after freeing them.

Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:53:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleXS-00011K-DT; Tue, 04 Nov 2014 13:52:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XleXQ-00011F-NZ
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:52:48 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	5D/11-02953-03AD8545; Tue, 04 Nov 2014 13:52:48 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415109167!7840513!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31586 invoked from network); 4 Nov 2014 13:52:47 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:52:47 -0000
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLG85168; Tue, 04 Nov 2014 13:52:41 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Tue, 4 Nov 2014 13:52:31 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 2/7] xen/arm: Implement hip04-d01 platform
Thread-Index: AQHP94XYH2ELvkaz70C3Jc5+gA7MLpxQdViAgAAIRqA=
Date: Tue, 4 Nov 2014 13:52:30 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B11C@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
	<5458D2C5.7050900@linaro.org>
In-Reply-To: <5458D2C5.7050900@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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

> 
> Hi Frediano,
> 
> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > Add this new platform to Xen.
> > This platform requires specific code to initialize CPUs.
> 
> I guess your platform doesn't support PSCI?
> 

No, there is no PSCI support.

> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > ---
> > +static void hip04_reset(void)
> > +{
> > +    unsigned long data;
> > +
> > +    if ( !gb2 )
> > +        return;
> 
> gb2 will never be NULL. Xen will panic if the initialization callback
> failed.
> 
> > +
> > +    data = readl_relaxed(gb2);
> > +    writel_relaxed(data & ~0x4000000u, gb2);
> > +
> > +    mdelay(10);
> > +}
> > +
> > +static void hip04_set_snoop_filter(unsigned int cluster, unsigned
> int
> > +on) {
> > +    unsigned long data;
> > +
> > +    if ( !fabric )
> > +        return;
> 
> Ditto.
> 

Done

> 
> [..]
> 
> > +static void __init hip04_iounmap(void __iomem **p) {
> > +    if ( *p )
> > +    {
> > +        iounmap(*p);
> > +        *p = NULL;
> > +    }
> > +}
> 
> What is used for? Should not iounmap enough?
> 

I just like to clear pointers after freeing them.

Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:55:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1XleZx-0001Bg-9T; Tue, 04 Nov 2014 13:55:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XleZw-0001BY-Ix
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:55:24 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	5F/D6-02696-BCAD8545; Tue, 04 Nov 2014 13:55:23 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415109323!12493939!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 949 invoked from network); 4 Nov 2014 13:55:23 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:55:23 -0000
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLG85451; Tue, 04 Nov 2014 13:55:18 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Tue, 4 Nov 2014 13:55:10 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 1/7] xen/device_tree: Add new helper to read arrays
	from a DTB
Thread-Index: AQHP94XU99h2tjq4kUuHCJBfohoimpxQc36AgAALDjA=
Date: Tue, 4 Nov 2014 13:55:09 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B129@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-2-git-send-email-frediano.ziglio@huawei.com>
	<5458D137.3030604@linaro.org>
In-Reply-To: <5458D137.3030604@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 1/7] xen/device_tree: Add new helper to
 read arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> Hi Frediano,
> 
> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > From: Zoltan Kiss <zoltan.kiss@linaro.org>
> >
> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> 
> You forgot to keep my reviewed-by from the last version.
> 
> Regards,
> 

You sent two mails, on first you add your reviewed-by but on the next one you put some comments so I though your reviewed-by was not valid anymore

Frediano

> > ---
> >  xen/common/device_tree.c      | 13 ++++++++++---
> >  xen/include/xen/device_tree.h | 11 +++++++++++
> >  2 files changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index
> > f72b2e9..1a886c0 100644
> > --- a/xen/common/device_tree.c
> > +++ b/xen/common/device_tree.c
> > @@ -160,14 +160,21 @@ const void *dt_get_property(const struct
> > dt_device_node *np,  bool_t dt_property_read_u32(const struct
> dt_device_node *np,
> >                           const char *name, u32 *out_value)  {
> > -    u32 len;
> > +    return dt_property_read_u32_array(np, name, out_value, 1); }
> > +
> > +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> > +                                  const char *name, u32 *out_value,
> > +u16 out_len) {
> > +    u32 len, i;
> >      const __be32 *val;
> >
> >      val = dt_get_property(np, name, &len);
> > -    if ( !val || len < sizeof(*out_value) )
> > +    if ( !val || len < sizeof(*out_value) * out_len )
> >          return 0;
> >
> > -    *out_value = be32_to_cpup(val);
> > +    for ( i = 0; i < out_len; i++, val++ )
> > +        out_value[i] = be32_to_cpup(val);
> >
> >      return 1;
> >  }
> > diff --git a/xen/include/xen/device_tree.h
> > b/xen/include/xen/device_tree.h index 08db8bc..629bfb2 100644
> > --- a/xen/include/xen/device_tree.h
> > +++ b/xen/include/xen/device_tree.h
> > @@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const
> > struct dt_device_node *np,  bool_t dt_property_read_u32(const struct
> dt_device_node *np,
> >                              const char *name, u32 *out_value);
> >  /**
> > + * dt_property_read_u32_array - Helper to read a u32 array property.
> > + * @np: node to get the value
> > + * @name: name of the property
> > + * @out_value: pointer to return value
> > + * @out_len: length of the array
> > + *
> > + * Return true if get the desired value.
> > + */
> > +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> > +                                  const char *name, u32 *out_value,
> > +u16 out_len);
> > +/**
> >   * dt_property_read_u64 - Helper to read a u64 property.
> >   * @np: node to get the value
> >   * @name: name of the property
> >
> 
> 
> --
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 13:55:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 13: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 1XleZx-0001Bg-9T; Tue, 04 Nov 2014 13:55:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XleZw-0001BY-Ix
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 13:55:24 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	5F/D6-02696-BCAD8545; Tue, 04 Nov 2014 13:55:23 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415109323!12493939!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 949 invoked from network); 4 Nov 2014 13:55:23 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 13:55:23 -0000
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLG85451; Tue, 04 Nov 2014 13:55:18 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Tue, 4 Nov 2014 13:55:10 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 1/7] xen/device_tree: Add new helper to read arrays
	from a DTB
Thread-Index: AQHP94XU99h2tjq4kUuHCJBfohoimpxQc36AgAALDjA=
Date: Tue, 4 Nov 2014 13:55:09 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B129@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-2-git-send-email-frediano.ziglio@huawei.com>
	<5458D137.3030604@linaro.org>
In-Reply-To: <5458D137.3030604@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 1/7] xen/device_tree: Add new helper to
 read arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> Hi Frediano,
> 
> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > From: Zoltan Kiss <zoltan.kiss@linaro.org>
> >
> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> 
> You forgot to keep my reviewed-by from the last version.
> 
> Regards,
> 

You sent two mails, on first you add your reviewed-by but on the next one you put some comments so I though your reviewed-by was not valid anymore

Frediano

> > ---
> >  xen/common/device_tree.c      | 13 ++++++++++---
> >  xen/include/xen/device_tree.h | 11 +++++++++++
> >  2 files changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index
> > f72b2e9..1a886c0 100644
> > --- a/xen/common/device_tree.c
> > +++ b/xen/common/device_tree.c
> > @@ -160,14 +160,21 @@ const void *dt_get_property(const struct
> > dt_device_node *np,  bool_t dt_property_read_u32(const struct
> dt_device_node *np,
> >                           const char *name, u32 *out_value)  {
> > -    u32 len;
> > +    return dt_property_read_u32_array(np, name, out_value, 1); }
> > +
> > +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> > +                                  const char *name, u32 *out_value,
> > +u16 out_len) {
> > +    u32 len, i;
> >      const __be32 *val;
> >
> >      val = dt_get_property(np, name, &len);
> > -    if ( !val || len < sizeof(*out_value) )
> > +    if ( !val || len < sizeof(*out_value) * out_len )
> >          return 0;
> >
> > -    *out_value = be32_to_cpup(val);
> > +    for ( i = 0; i < out_len; i++, val++ )
> > +        out_value[i] = be32_to_cpup(val);
> >
> >      return 1;
> >  }
> > diff --git a/xen/include/xen/device_tree.h
> > b/xen/include/xen/device_tree.h index 08db8bc..629bfb2 100644
> > --- a/xen/include/xen/device_tree.h
> > +++ b/xen/include/xen/device_tree.h
> > @@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const
> > struct dt_device_node *np,  bool_t dt_property_read_u32(const struct
> dt_device_node *np,
> >                              const char *name, u32 *out_value);
> >  /**
> > + * dt_property_read_u32_array - Helper to read a u32 array property.
> > + * @np: node to get the value
> > + * @name: name of the property
> > + * @out_value: pointer to return value
> > + * @out_len: length of the array
> > + *
> > + * Return true if get the desired value.
> > + */
> > +bool_t dt_property_read_u32_array(const struct dt_device_node *np,
> > +                                  const char *name, u32 *out_value,
> > +u16 out_len);
> > +/**
> >   * dt_property_read_u64 - Helper to read a u64 property.
> >   * @np: node to get the value
> >   * @name: name of the property
> >
> 
> 
> --
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:00:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xleep-0001WP-3R; Tue, 04 Nov 2014 14:00:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xleen-0001WK-Lc
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:00:25 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	78/D2-11608-8FBD8545; Tue, 04 Nov 2014 14:00:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415109624!11435557!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26678 invoked from network); 4 Nov 2014 14:00:24 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:00:24 -0000
Received: by mail-wi0-f170.google.com with SMTP id q5so8762775wiv.5
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 06:00:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=5XB9NbcJvPOpSyWA5U19FyLfMJVhg5gz/QEHQ69Qq/A=;
	b=P59vwgvJhXxgC3dsptWuKZSbdBVkmd1irhkxyaDoLjlmOSjFBlROA/e9UpKSey7Yjv
	8IMhknIirH9vNQsrCcu7/xZfZItfqjOcCST5yYTUCiFQVWBe2+/f8IN4ZcgKj0lCKXZz
	z78eV+IpXswOwN7HyGfTvxE7DXxELLBEs3oc3O0t7mHE6dgRd8rkir6Ux/mKV3TvfSav
	3x374ca3dl2ysV/fqI+1smMjrAJtE75MWnYwFnUHff77faW0Kz+cecf4tr8I0z+5rhBn
	VUni/+Q0k4FZ97qQSnY72fqZZj8D+B2NmF8GPHDcZNNdnibZT8UkCWWS1rLImZ8OKmNS
	0rtg==
X-Gm-Message-State: ALoCoQk2HUk8zXn9V9q2xubyiwS86kLgIlvksOuKA4W/qyTxVbU0FCJywqimPHxaeTuDniqlvyHp
X-Received: by 10.194.81.70 with SMTP id y6mr10565573wjx.113.1415109624023;
	Tue, 04 Nov 2014 06:00:24 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id lm9sm597828wjc.45.2014.11.04.06.00.22
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 06:00:23 -0800 (PST)
Message-ID: <5458DBF0.1050504@linaro.org>
Date: Tue, 04 Nov 2014 14:00:16 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-2-git-send-email-frediano.ziglio@huawei.com>
	<5458D137.3030604@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B129@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B129@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 1/7] xen/device_tree: Add new helper to
 read arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2014 01:55 PM, Frediano Ziglio wrote:
>>
>> Hi Frediano,
>>
>> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
>>> From: Zoltan Kiss <zoltan.kiss@linaro.org>
>>>
>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
>>
>> You forgot to keep my reviewed-by from the last version.
>>
>> Regards,
>>
> 
> You sent two mails, on first you add your reviewed-by but on the next one you put some comments so I though your reviewed-by was not valid anymore

Fair enough. I tend to keep Reviewed-by/Acked-by for minors changes such
as coding style.

Anyway:

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,



-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:00:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xleep-0001WP-3R; Tue, 04 Nov 2014 14:00:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xleen-0001WK-Lc
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:00:25 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	78/D2-11608-8FBD8545; Tue, 04 Nov 2014 14:00:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415109624!11435557!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=1.8 required=7.0 tests=SORTED_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26678 invoked from network); 4 Nov 2014 14:00:24 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:00:24 -0000
Received: by mail-wi0-f170.google.com with SMTP id q5so8762775wiv.5
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 06:00:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=5XB9NbcJvPOpSyWA5U19FyLfMJVhg5gz/QEHQ69Qq/A=;
	b=P59vwgvJhXxgC3dsptWuKZSbdBVkmd1irhkxyaDoLjlmOSjFBlROA/e9UpKSey7Yjv
	8IMhknIirH9vNQsrCcu7/xZfZItfqjOcCST5yYTUCiFQVWBe2+/f8IN4ZcgKj0lCKXZz
	z78eV+IpXswOwN7HyGfTvxE7DXxELLBEs3oc3O0t7mHE6dgRd8rkir6Ux/mKV3TvfSav
	3x374ca3dl2ysV/fqI+1smMjrAJtE75MWnYwFnUHff77faW0Kz+cecf4tr8I0z+5rhBn
	VUni/+Q0k4FZ97qQSnY72fqZZj8D+B2NmF8GPHDcZNNdnibZT8UkCWWS1rLImZ8OKmNS
	0rtg==
X-Gm-Message-State: ALoCoQk2HUk8zXn9V9q2xubyiwS86kLgIlvksOuKA4W/qyTxVbU0FCJywqimPHxaeTuDniqlvyHp
X-Received: by 10.194.81.70 with SMTP id y6mr10565573wjx.113.1415109624023;
	Tue, 04 Nov 2014 06:00:24 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id lm9sm597828wjc.45.2014.11.04.06.00.22
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 06:00:23 -0800 (PST)
Message-ID: <5458DBF0.1050504@linaro.org>
Date: Tue, 04 Nov 2014 14:00:16 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-2-git-send-email-frediano.ziglio@huawei.com>
	<5458D137.3030604@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B129@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B129@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 1/7] xen/device_tree: Add new helper to
 read arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2014 01:55 PM, Frediano Ziglio wrote:
>>
>> Hi Frediano,
>>
>> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
>>> From: Zoltan Kiss <zoltan.kiss@linaro.org>
>>>
>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
>>
>> You forgot to keep my reviewed-by from the last version.
>>
>> Regards,
>>
> 
> You sent two mails, on first you add your reviewed-by but on the next one you put some comments so I though your reviewed-by was not valid anymore

Fair enough. I tend to keep Reviewed-by/Acked-by for minors changes such
as coding style.

Anyway:

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,



-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:01:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:01:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlefi-0001dO-Gr; Tue, 04 Nov 2014 14:01:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xlefh-0001dE-Ar
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:01:21 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	1F/03-17958-03CD8545; Tue, 04 Nov 2014 14:01:20 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415109678!11576086!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19674 invoked from network); 4 Nov 2014 14:01:19 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 14:01:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1415109679; x=1446645679;
	h=from:message-id:date:mime-version:to:subject:references:
	in-reply-to:content-transfer-encoding;
	bh=dBLQjDVeTGkPIBjxMDE4Axdmr8lmstpRwB+YlfPo3g0=;
	b=XlOnJYxW+g4JEe3e+yu2NhF7tbg5aq0+joc/esJHUMOH7IrlnwVbsw3/
	DlG844FcSNAXN+Y3Hn6CctTDbecKM4PzjhrzL72iN1myTLAiEVuhpjrBt
	teICGgaMZ+08b++1utsbfe17nBbgFOLzLTj4vWjgvTKh/XjZ7ayg1/rbJ Q=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 04 Nov 2014 14:01:17 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="895512666"
Received: from unknown (HELO don-760.CloudSwitch.com) ([162.47.5.116])
	by fldsmtpi01.verizon.com with ESMTP; 04 Nov 2014 14:01:16 +0000
Message-ID: <5458DC2C.7010209@terremark.com>
Date: Tue, 04 Nov 2014 09:01:16 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Steve Freitas <sflist@ihonk.com>, Don Slutz <dslutz@verizon.com>, 
	xen-devel@lists.xen.org
References: <5457F79B.2020300@ihonk.com> <5457F935.8040806@ihonk.com>
In-Reply-To: <5457F935.8040806@ihonk.com>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/14 16:52, Steve Freitas wrote:
> On 11/3/2014 13:46, Steve Freitas wrote:
>> Hi all,
>>
>> I've got a Windows 7 x64 VM that is stable on 4.4.1 but crashes the 
>> host after a few hours on 4.5rc1.
>
> Whoops, neglected to include the following log which, I expect, is 
> useless:
>
> root@g2:/var/log/xen# cat qemu-dm-clippy2.log
> char device redirected to /dev/pts/2 (label serial0)
>

Yup, However it would be good to know if QEMU is still running.

    -Don Slutz

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:01:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:01:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlefi-0001dO-Gr; Tue, 04 Nov 2014 14:01:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xlefh-0001dE-Ar
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:01:21 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	1F/03-17958-03CD8545; Tue, 04 Nov 2014 14:01:20 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415109678!11576086!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19674 invoked from network); 4 Nov 2014 14:01:19 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 14:01:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1415109679; x=1446645679;
	h=from:message-id:date:mime-version:to:subject:references:
	in-reply-to:content-transfer-encoding;
	bh=dBLQjDVeTGkPIBjxMDE4Axdmr8lmstpRwB+YlfPo3g0=;
	b=XlOnJYxW+g4JEe3e+yu2NhF7tbg5aq0+joc/esJHUMOH7IrlnwVbsw3/
	DlG844FcSNAXN+Y3Hn6CctTDbecKM4PzjhrzL72iN1myTLAiEVuhpjrBt
	teICGgaMZ+08b++1utsbfe17nBbgFOLzLTj4vWjgvTKh/XjZ7ayg1/rbJ Q=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 04 Nov 2014 14:01:17 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="895512666"
Received: from unknown (HELO don-760.CloudSwitch.com) ([162.47.5.116])
	by fldsmtpi01.verizon.com with ESMTP; 04 Nov 2014 14:01:16 +0000
Message-ID: <5458DC2C.7010209@terremark.com>
Date: Tue, 04 Nov 2014 09:01:16 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Steve Freitas <sflist@ihonk.com>, Don Slutz <dslutz@verizon.com>, 
	xen-devel@lists.xen.org
References: <5457F79B.2020300@ihonk.com> <5457F935.8040806@ihonk.com>
In-Reply-To: <5457F935.8040806@ihonk.com>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/14 16:52, Steve Freitas wrote:
> On 11/3/2014 13:46, Steve Freitas wrote:
>> Hi all,
>>
>> I've got a Windows 7 x64 VM that is stable on 4.4.1 but crashes the 
>> host after a few hours on 4.5rc1.
>
> Whoops, neglected to include the following log which, I expect, is 
> useless:
>
> root@g2:/var/log/xen# cat qemu-dm-clippy2.log
> char device redirected to /dev/pts/2 (label serial0)
>

Yup, However it would be good to know if QEMU is still running.

    -Don Slutz

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:02:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14: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.xen.org>)
	id 1XlegM-0001iV-VD; Tue, 04 Nov 2014 14:02: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@citrix.com>) id 1XlegK-0001hw-A6
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 14:02:00 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	A7/63-28865-75CD8545; Tue, 04 Nov 2014 14:01:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415109716!11115202!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30702 invoked from network); 4 Nov 2014 14:01:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:01:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189288035"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 09:01:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlefW-0006NR-3P;
	Tue, 04 Nov 2014 14:01:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlefV-0003mp-TU;
	Tue, 04 Nov 2014 14:01:09 +0000
Date: Tue, 4 Nov 2014 14:01:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31352-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31352: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31352 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31352/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                0df1f2487d2f0d04703f142813d53615d62a1da4
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
331 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 10700 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 Nov 04 14:02:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14: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.xen.org>)
	id 1XlegM-0001iV-VD; Tue, 04 Nov 2014 14:02: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@citrix.com>) id 1XlegK-0001hw-A6
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 14:02:00 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	A7/63-28865-75CD8545; Tue, 04 Nov 2014 14:01:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415109716!11115202!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30702 invoked from network); 4 Nov 2014 14:01:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:01:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189288035"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 09:01:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlefW-0006NR-3P;
	Tue, 04 Nov 2014 14:01:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlefV-0003mp-TU;
	Tue, 04 Nov 2014 14:01:09 +0000
Date: Tue, 4 Nov 2014 14:01:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31352-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31352: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31352 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31352/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                0df1f2487d2f0d04703f142813d53615d62a1da4
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
331 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 10700 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 Nov 04 14:04:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:04:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleiK-00023N-MZ; Tue, 04 Nov 2014 14:04:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleiI-000238-MX
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:04:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3D/68-24532-2DCD8545; Tue, 04 Nov 2014 14:04:02 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415109841!12727116!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31057 invoked from network); 4 Nov 2014 14:04:01 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:04:01 -0000
Received: by mail-wg0-f44.google.com with SMTP id x12so13131175wgg.31
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 06:04:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=U6DIrp+doBvhR0GwV0wEPgTsRmJsdClpWt2IM6n7nSw=;
	b=k/mqIJDqZ0MnyHZEqzL45rFNb1ZRjoLN8M7H4jW0DZMQIumu+ga2dYKJa1E4Z2sPxh
	NJGn6MLhcLA0Ht0LxaqJxtw7J/U+peEtQTq7JwceMecT09Fy32ZB8xgSi52gHq1YXcFs
	oFP4FUoQnyxEK1kBUf0r11OW/fkIK4KY4aG3ObcdiUYEDkMHt6T8LVoZtmUjMW53OnHg
	adLS9QdWM7FzGMtyOIvLitZQcPXUFPTPQpCAMDyjT/oIzsqUhF1P7YsAJN2EM49N3y2C
	h9pgG6HId08tDktVbH5WJWxIx9+kWv5MVuIbVAprLTQkZTSAgEsmFL1OkH8YD1JGi/F5
	vUXA==
X-Gm-Message-State: ALoCoQlsihCyPV18RolQ1GUrSVxtjbiyp16lQf7uZ2K05gh3ct8losWC6aE3oatyZkuArw/RhE+9
X-Received: by 10.180.198.145 with SMTP id jc17mr24311333wic.67.1415109840989; 
	Tue, 04 Nov 2014 06:04:00 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id s8sm664949wjx.9.2014.11.04.06.03.59
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 06:03:59 -0800 (PST)
Message-ID: <5458DCC9.9090406@linaro.org>
Date: Tue, 04 Nov 2014 14:03:53 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
	<5458D2C5.7050900@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B11C@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B11C@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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 11/04/2014 01:52 PM, Frediano Ziglio wrote:
>>
>> [..]
>>
>>> +static void __init hip04_iounmap(void __iomem **p) {
>>> +    if ( *p )
>>> +    {
>>> +        iounmap(*p);
>>> +        *p = NULL;
>>> +    }
>>> +}
>>
>> What is used for? Should not iounmap enough?
>>
> 
> I just like to clear pointers after freeing them.

It's not really useful :).

If you really want to keep the *p = NULL. This could be simplify into:

hip04_iounmap(....)
{
   iounmap(*p);
   *p = NULL;
}

This is because iounmap takes care of NULL pointer.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:04:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:04:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XleiK-00023N-MZ; Tue, 04 Nov 2014 14:04:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XleiI-000238-MX
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:04:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3D/68-24532-2DCD8545; Tue, 04 Nov 2014 14:04:02 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415109841!12727116!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31057 invoked from network); 4 Nov 2014 14:04:01 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:04:01 -0000
Received: by mail-wg0-f44.google.com with SMTP id x12so13131175wgg.31
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 06:04:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=U6DIrp+doBvhR0GwV0wEPgTsRmJsdClpWt2IM6n7nSw=;
	b=k/mqIJDqZ0MnyHZEqzL45rFNb1ZRjoLN8M7H4jW0DZMQIumu+ga2dYKJa1E4Z2sPxh
	NJGn6MLhcLA0Ht0LxaqJxtw7J/U+peEtQTq7JwceMecT09Fy32ZB8xgSi52gHq1YXcFs
	oFP4FUoQnyxEK1kBUf0r11OW/fkIK4KY4aG3ObcdiUYEDkMHt6T8LVoZtmUjMW53OnHg
	adLS9QdWM7FzGMtyOIvLitZQcPXUFPTPQpCAMDyjT/oIzsqUhF1P7YsAJN2EM49N3y2C
	h9pgG6HId08tDktVbH5WJWxIx9+kWv5MVuIbVAprLTQkZTSAgEsmFL1OkH8YD1JGi/F5
	vUXA==
X-Gm-Message-State: ALoCoQlsihCyPV18RolQ1GUrSVxtjbiyp16lQf7uZ2K05gh3ct8losWC6aE3oatyZkuArw/RhE+9
X-Received: by 10.180.198.145 with SMTP id jc17mr24311333wic.67.1415109840989; 
	Tue, 04 Nov 2014 06:04:00 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id s8sm664949wjx.9.2014.11.04.06.03.59
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 06:03:59 -0800 (PST)
Message-ID: <5458DCC9.9090406@linaro.org>
Date: Tue, 04 Nov 2014 14:03:53 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
	<5458D2C5.7050900@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B11C@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B11C@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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 11/04/2014 01:52 PM, Frediano Ziglio wrote:
>>
>> [..]
>>
>>> +static void __init hip04_iounmap(void __iomem **p) {
>>> +    if ( *p )
>>> +    {
>>> +        iounmap(*p);
>>> +        *p = NULL;
>>> +    }
>>> +}
>>
>> What is used for? Should not iounmap enough?
>>
> 
> I just like to clear pointers after freeing them.

It's not really useful :).

If you really want to keep the *p = NULL. This could be simplify into:

hip04_iounmap(....)
{
   iounmap(*p);
   *p = NULL;
}

This is because iounmap takes care of NULL pointer.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:10:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xleoc-0002VL-Ml; Tue, 04 Nov 2014 14:10:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xleob-0002VG-8d
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:10:33 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	64/BA-03148-85ED8545; Tue, 04 Nov 2014 14:10:32 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415110231!12468793!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11634 invoked from network); 4 Nov 2014 14:10:32 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:10:32 -0000
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BOK18626; Tue, 04 Nov 2014 14:10:25 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id
	14.03.0158.001; Tue, 4 Nov 2014 14:10:18 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 6/7] xen/arm: Force domains to use normal GICv2
	driver on Hip04 platform
Thread-Index: AQHP94XhIAV+2qGIo0S9SyWFytyYx5xQeL0AgAAKFwA=
Date: Tue, 4 Nov 2014 14:10:18 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B157@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-7-git-send-email-frediano.ziglio@huawei.com>
	<5458D59E.9010703@linaro.org>
In-Reply-To: <5458D59E.9010703@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 6/7] xen/arm: Force domains to use normal
 GICv2 driver on Hip04 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

> 
> Hi Frediano,
> 
> FYI, this is only force DOM0 to use the normal GICv2 drivers. I.e the
> title of this patch is wrong.
> 
> Do you have any plan to support hi-silicon vGIC in Xen? This would
> allow guest running with more than 8 cores.
> 
> Regards,
> 

Actually there's no plan to do it.

Frediano

> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > Until vGIC support is not implemented and tested, this will prevent
> > guest kernels to use their Hip04 driver, or crash when they don't
> have
> > any.
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > ---
> >  xen/arch/arm/gic-v2.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > 411b104..cea9edc 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -639,6 +639,12 @@ static int gicv2_make_dt_node(const struct
> domain *d,
> >          return -FDT_ERR_XEN(ENOENT);
> >      }
> >
> > +    if ( nr_gic_cpu_if == 16 )
> > +    {
> > +        compatible = DT_COMPAT_GIC_CORTEX_A15;
> > +        len = strlen((char*) compatible) + 1;
> > +    }
> > +
> >      res = fdt_begin_node(fdt, "interrupt-controller");
> >      if ( res )
> >          return res;
> >
> 
> 
> --
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:10:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xleoc-0002VL-Ml; Tue, 04 Nov 2014 14:10:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xleob-0002VG-8d
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:10:33 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	64/BA-03148-85ED8545; Tue, 04 Nov 2014 14:10:32 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415110231!12468793!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11634 invoked from network); 4 Nov 2014 14:10:32 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:10:32 -0000
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BOK18626; Tue, 04 Nov 2014 14:10:25 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id
	14.03.0158.001; Tue, 4 Nov 2014 14:10:18 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 6/7] xen/arm: Force domains to use normal GICv2
	driver on Hip04 platform
Thread-Index: AQHP94XhIAV+2qGIo0S9SyWFytyYx5xQeL0AgAAKFwA=
Date: Tue, 4 Nov 2014 14:10:18 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B157@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-7-git-send-email-frediano.ziglio@huawei.com>
	<5458D59E.9010703@linaro.org>
In-Reply-To: <5458D59E.9010703@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 6/7] xen/arm: Force domains to use normal
 GICv2 driver on Hip04 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

> 
> Hi Frediano,
> 
> FYI, this is only force DOM0 to use the normal GICv2 drivers. I.e the
> title of this patch is wrong.
> 
> Do you have any plan to support hi-silicon vGIC in Xen? This would
> allow guest running with more than 8 cores.
> 
> Regards,
> 

Actually there's no plan to do it.

Frediano

> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > Until vGIC support is not implemented and tested, this will prevent
> > guest kernels to use their Hip04 driver, or crash when they don't
> have
> > any.
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > ---
> >  xen/arch/arm/gic-v2.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > 411b104..cea9edc 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -639,6 +639,12 @@ static int gicv2_make_dt_node(const struct
> domain *d,
> >          return -FDT_ERR_XEN(ENOENT);
> >      }
> >
> > +    if ( nr_gic_cpu_if == 16 )
> > +    {
> > +        compatible = DT_COMPAT_GIC_CORTEX_A15;
> > +        len = strlen((char*) compatible) + 1;
> > +    }
> > +
> >      res = fdt_begin_node(fdt, "interrupt-controller");
> >      if ( res )
> >          return res;
> >
> 
> 
> --
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:17:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlevJ-0002mx-OW; Tue, 04 Nov 2014 14:17:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlevI-0002ms-2c
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:17:28 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	AC/17-31453-7FFD8545; Tue, 04 Nov 2014 14:17:27 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415110646!7007824!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27715 invoked from network); 4 Nov 2014 14:17:26 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:17:26 -0000
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLG87663; Tue, 04 Nov 2014 14:17:17 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id
	14.03.0158.001; Tue, 4 Nov 2014 14:17:09 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 2/7] xen/arm: Implement hip04-d01 platform
Thread-Index: AQHP94XYH2ELvkaz70C3Jc5+gA7MLpxQdViAgAAIRqCAAAOrgIAAAyOA
Date: Tue, 4 Nov 2014 14:17:08 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B168@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
	<5458D2C5.7050900@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B11C@lhreml509-mbb>
	<5458DCC9.9090406@linaro.org>
In-Reply-To: <5458DCC9.9090406@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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 11/04/2014 01:52 PM, Frediano Ziglio wrote:
> >>
> >> [..]
> >>
> >>> +static void __init hip04_iounmap(void __iomem **p) {
> >>> +    if ( *p )
> >>> +    {
> >>> +        iounmap(*p);
> >>> +        *p = NULL;
> >>> +    }
> >>> +}
> >>
> >> What is used for? Should not iounmap enough?
> >>
> >
> > I just like to clear pointers after freeing them.
> 
> It's not really useful :).
> 

Just paranoia :)
Never liked dandling pointers.

> If you really want to keep the *p = NULL. This could be simplify into:
> 
> hip04_iounmap(....)
> {
>    iounmap(*p);
>    *p = NULL;
> }
> 
> This is because iounmap takes care of NULL pointer.
> 

Are you sure? I looked at code and is not a simple vm_free call, it does some mapping even if address is NULL.

Regards,
  Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:17:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlevJ-0002mx-OW; Tue, 04 Nov 2014 14:17:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlevI-0002ms-2c
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:17:28 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	AC/17-31453-7FFD8545; Tue, 04 Nov 2014 14:17:27 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415110646!7007824!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27715 invoked from network); 4 Nov 2014 14:17:26 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:17:26 -0000
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLG87663; Tue, 04 Nov 2014 14:17:17 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id
	14.03.0158.001; Tue, 4 Nov 2014 14:17:09 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 2/7] xen/arm: Implement hip04-d01 platform
Thread-Index: AQHP94XYH2ELvkaz70C3Jc5+gA7MLpxQdViAgAAIRqCAAAOrgIAAAyOA
Date: Tue, 4 Nov 2014 14:17:08 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B168@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
	<5458D2C5.7050900@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B11C@lhreml509-mbb>
	<5458DCC9.9090406@linaro.org>
In-Reply-To: <5458DCC9.9090406@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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 11/04/2014 01:52 PM, Frediano Ziglio wrote:
> >>
> >> [..]
> >>
> >>> +static void __init hip04_iounmap(void __iomem **p) {
> >>> +    if ( *p )
> >>> +    {
> >>> +        iounmap(*p);
> >>> +        *p = NULL;
> >>> +    }
> >>> +}
> >>
> >> What is used for? Should not iounmap enough?
> >>
> >
> > I just like to clear pointers after freeing them.
> 
> It's not really useful :).
> 

Just paranoia :)
Never liked dandling pointers.

> If you really want to keep the *p = NULL. This could be simplify into:
> 
> hip04_iounmap(....)
> {
>    iounmap(*p);
>    *p = NULL;
> }
> 
> This is because iounmap takes care of NULL pointer.
> 

Are you sure? I looked at code and is not a simple vm_free call, it does some mapping even if address is NULL.

Regards,
  Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:24:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:24:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlf1d-0003BX-LY; Tue, 04 Nov 2014 14:24:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xlf1c-0003BS-Pg
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:24:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B6/52-09936-081E8545; Tue, 04 Nov 2014 14:24:00 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415111039!4674518!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7271 invoked from network); 4 Nov 2014 14:23:59 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:23:59 -0000
Received: by mail-wg0-f49.google.com with SMTP id x13so13560948wgg.22
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 06:23:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=DJk2E15sj7FOwuLVOwl9C5FXQpXQaww2jfOddnczNB4=;
	b=lwIuTfZ0dEFyLonqdwURcfTigiLG+5lcTzyR7DfPaidwWjde90F5eRxpJlq/tgLxL/
	hHM7KBoNkqwIc4cH3ksfkWuQmOnv2PG2iWydYpf2hJdBuLuUV08tUGexLwa8tTV5QNMe
	vd1Ap5IpJu2wpHBJIC8qIs+x3FpAsC+i7pza6nVH5lWI6frUOIFmhE/9oD1ZPI21Bnf1
	C13Ei34iYnAXJzfNgbbeJaG/vzPx0nwNJg/aGRfosq8dUwgdQ3Dtd7Fby/f04QwSDbDG
	HgsfTxm3kXvU8ux3KTKKQBAeDDhho0wdeH5FVPc/L5T1l0fhyvSOgzjnncERQcenqmRX
	b18A==
X-Gm-Message-State: ALoCoQlcGi6rcaCDJjJjq217Or2pZH+lVtpW2HBXyhfEpO5njRvElkZKsdXv8MJLQIaof/E5sqIz
X-Received: by 10.194.103.230 with SMTP id fz6mr55902450wjb.53.1415111039476; 
	Tue, 04 Nov 2014 06:23:59 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id bf6sm717036wjb.13.2014.11.04.06.23.55
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 06:23:56 -0800 (PST)
Message-ID: <5458E175.40409@linaro.org>
Date: Tue, 04 Nov 2014 14:23:49 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
	<5458D2C5.7050900@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B11C@lhreml509-mbb>
	<5458DCC9.9090406@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B168@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B168@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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 11/04/2014 02:17 PM, Frediano Ziglio wrote:
>> If you really want to keep the *p = NULL. This could be simplify into:
>>
>> hip04_iounmap(....)
>> {
>>    iounmap(*p);
>>    *p = NULL;
>> }
>>
>> This is because iounmap takes care of NULL pointer.
>>
> 
> Are you sure? I looked at code and is not a simple vm_free call, it does some mapping even if address is NULL.

Yes, vm_size(va) will return 0 and destroy_xen_mappings won't unmap
anything because start == end.

I agree that an explicit check in vunmap would be nice.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:24:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:24:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlf1d-0003BX-LY; Tue, 04 Nov 2014 14:24:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xlf1c-0003BS-Pg
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:24:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B6/52-09936-081E8545; Tue, 04 Nov 2014 14:24:00 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415111039!4674518!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7271 invoked from network); 4 Nov 2014 14:23:59 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:23:59 -0000
Received: by mail-wg0-f49.google.com with SMTP id x13so13560948wgg.22
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 06:23:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=DJk2E15sj7FOwuLVOwl9C5FXQpXQaww2jfOddnczNB4=;
	b=lwIuTfZ0dEFyLonqdwURcfTigiLG+5lcTzyR7DfPaidwWjde90F5eRxpJlq/tgLxL/
	hHM7KBoNkqwIc4cH3ksfkWuQmOnv2PG2iWydYpf2hJdBuLuUV08tUGexLwa8tTV5QNMe
	vd1Ap5IpJu2wpHBJIC8qIs+x3FpAsC+i7pza6nVH5lWI6frUOIFmhE/9oD1ZPI21Bnf1
	C13Ei34iYnAXJzfNgbbeJaG/vzPx0nwNJg/aGRfosq8dUwgdQ3Dtd7Fby/f04QwSDbDG
	HgsfTxm3kXvU8ux3KTKKQBAeDDhho0wdeH5FVPc/L5T1l0fhyvSOgzjnncERQcenqmRX
	b18A==
X-Gm-Message-State: ALoCoQlcGi6rcaCDJjJjq217Or2pZH+lVtpW2HBXyhfEpO5njRvElkZKsdXv8MJLQIaof/E5sqIz
X-Received: by 10.194.103.230 with SMTP id fz6mr55902450wjb.53.1415111039476; 
	Tue, 04 Nov 2014 06:23:59 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id bf6sm717036wjb.13.2014.11.04.06.23.55
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 06:23:56 -0800 (PST)
Message-ID: <5458E175.40409@linaro.org>
Date: Tue, 04 Nov 2014 14:23:49 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-3-git-send-email-frediano.ziglio@huawei.com>
	<5458D2C5.7050900@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B11C@lhreml509-mbb>
	<5458DCC9.9090406@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B168@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B168@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Implement hip04-d01 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 11/04/2014 02:17 PM, Frediano Ziglio wrote:
>> If you really want to keep the *p = NULL. This could be simplify into:
>>
>> hip04_iounmap(....)
>> {
>>    iounmap(*p);
>>    *p = NULL;
>> }
>>
>> This is because iounmap takes care of NULL pointer.
>>
> 
> Are you sure? I looked at code and is not a simple vm_free call, it does some mapping even if address is NULL.

Yes, vm_size(va) will return 0 and destroy_xen_mappings won't unmap
anything because start == end.

I agree that an explicit check in vunmap would be nice.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:39:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14: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 1XlfGg-0003Xk-FN; Tue, 04 Nov 2014 14:39:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XlfGf-0003Xf-EP
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:39:33 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F3/B4-24532-425E8545; Tue, 04 Nov 2014 14:39:32 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415111970!4679851!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17415 invoked from network); 4 Nov 2014 14:39:32 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 14:39:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1415111972; x=1446647972;
	h=from:message-id:date:mime-version:to:subject:references:
	in-reply-to:content-transfer-encoding;
	bh=4RrFhnv2RwKYxEllMTHptuQ4OLEgnFeEAg3CxSITl7E=;
	b=iPzE93OPR6Fi9LL7yvSq5suiUFb3DQQnVnN1BKBrSxctHaiJQTgir9NL
	1Q12bP0TzXdPH/tFoQJOk0cqf72sXabnYmPEPeGiyvBndmUi2HE8xyZF0
	dQOndLigiKvvcZn7DOoW+TAaj7U6sRNGZNfumnH2KNcwJGulS0vgmXOZP k=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 04 Nov 2014 14:39:30 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="862032885"
Received: from unknown (HELO don-760.CloudSwitch.com) ([162.47.3.76])
	by fldsmtpi03.verizon.com with ESMTP; 04 Nov 2014 14:39:29 +0000
Message-ID: <5458E521.2030002@terremark.com>
Date: Tue, 04 Nov 2014 09:39:29 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Steve Freitas <sflist@ihonk.com>, Don Slutz <dslutz@verizon.com>, 
	xen-devel@lists.xen.org
References: <5457F79B.2020300@ihonk.com>
In-Reply-To: <5457F79B.2020300@ihonk.com>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/14 16:46, Steve Freitas wrote:
> Hi all,
>
> I've got a Windows 7 x64 VM that is stable on 4.4.1 but crashes the 
> host after a few hours on 4.5rc1. The machine is a ThinkStation D20, 
> an X5660 with 5500-series chipset with an Nvidia Quadro FX4800 
> (genuine) passed through. Distro is Debian Jessie running stock distro 
> kernel and seabios. Both 4.4.1 and 4.5rc1 were built from source. 
> Apologies if this issue has already been spotted but I can't keep up 
> with the traffic on this list! :-)
>
> It looks as if something is stepping on PCI devices when the crash 
> happens. In the log included below, it's the SATA system that's 
> complaining but I've seen it hit the ethernet chip first, then SATA 
> after that. I'm happy to troubleshoot, apply patches, give more 
> information, etc.
>
> I've seen the crash when running Windows Update, when running the 
> Unigine graphics benchmark, when running an Avast anti-virus scan. 
> Haven't found a common thread.
>
> Don, one curious thing I noted which may be of no value whatsoever: 
> Under 4.4.1, I can't give the VM > 3.5 gigs of RAM without breaking 
> VGA passthrough. Under 4.5rc1 I can give the VM more than 3.5 gigs, 
> yet I *don't* need to use the "mmio_hole" settings in the VM config. 
> Not sure why or what that might signify, if anything.
>

First off, I do not know much about pci-passthru.  The fact that it now 
boots with
more then 3.5 GiB just tells me that things have changed (like what 
physical addresses
are used get changed).  Without a clear way to cause this issue, getting 
to the root
cause is much harder.  For example, there is no clear way to say that 
4.4.1 will never
have this issue (it just has not yet done so).

There are 3 mmio_size values that make sense to try.
1) mmio_hole = 1033
    This is what Konrad Wilk suggested (hole based on bare metal bios).  
This has been
     rounded up to the nearest MB.
2) mmio_hole = 1024
     This might be a good size (512 may be just a little too small).
3) mmio_size = 512
     This is the size that you think has worked in the past.

I would also see if less guest ram (like 3.0 GiB) can still reproduce 
the issue.

    -Don Slutz

> Possibly useful information follows.
>
> Thanks,
>
> Steve
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:39:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14: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 1XlfGg-0003Xk-FN; Tue, 04 Nov 2014 14:39:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XlfGf-0003Xf-EP
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:39:33 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F3/B4-24532-425E8545; Tue, 04 Nov 2014 14:39:32 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415111970!4679851!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17415 invoked from network); 4 Nov 2014 14:39:32 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 14:39:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1415111972; x=1446647972;
	h=from:message-id:date:mime-version:to:subject:references:
	in-reply-to:content-transfer-encoding;
	bh=4RrFhnv2RwKYxEllMTHptuQ4OLEgnFeEAg3CxSITl7E=;
	b=iPzE93OPR6Fi9LL7yvSq5suiUFb3DQQnVnN1BKBrSxctHaiJQTgir9NL
	1Q12bP0TzXdPH/tFoQJOk0cqf72sXabnYmPEPeGiyvBndmUi2HE8xyZF0
	dQOndLigiKvvcZn7DOoW+TAaj7U6sRNGZNfumnH2KNcwJGulS0vgmXOZP k=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 04 Nov 2014 14:39:30 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="862032885"
Received: from unknown (HELO don-760.CloudSwitch.com) ([162.47.3.76])
	by fldsmtpi03.verizon.com with ESMTP; 04 Nov 2014 14:39:29 +0000
Message-ID: <5458E521.2030002@terremark.com>
Date: Tue, 04 Nov 2014 09:39:29 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Steve Freitas <sflist@ihonk.com>, Don Slutz <dslutz@verizon.com>, 
	xen-devel@lists.xen.org
References: <5457F79B.2020300@ihonk.com>
In-Reply-To: <5457F79B.2020300@ihonk.com>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/03/14 16:46, Steve Freitas wrote:
> Hi all,
>
> I've got a Windows 7 x64 VM that is stable on 4.4.1 but crashes the 
> host after a few hours on 4.5rc1. The machine is a ThinkStation D20, 
> an X5660 with 5500-series chipset with an Nvidia Quadro FX4800 
> (genuine) passed through. Distro is Debian Jessie running stock distro 
> kernel and seabios. Both 4.4.1 and 4.5rc1 were built from source. 
> Apologies if this issue has already been spotted but I can't keep up 
> with the traffic on this list! :-)
>
> It looks as if something is stepping on PCI devices when the crash 
> happens. In the log included below, it's the SATA system that's 
> complaining but I've seen it hit the ethernet chip first, then SATA 
> after that. I'm happy to troubleshoot, apply patches, give more 
> information, etc.
>
> I've seen the crash when running Windows Update, when running the 
> Unigine graphics benchmark, when running an Avast anti-virus scan. 
> Haven't found a common thread.
>
> Don, one curious thing I noted which may be of no value whatsoever: 
> Under 4.4.1, I can't give the VM > 3.5 gigs of RAM without breaking 
> VGA passthrough. Under 4.5rc1 I can give the VM more than 3.5 gigs, 
> yet I *don't* need to use the "mmio_hole" settings in the VM config. 
> Not sure why or what that might signify, if anything.
>

First off, I do not know much about pci-passthru.  The fact that it now 
boots with
more then 3.5 GiB just tells me that things have changed (like what 
physical addresses
are used get changed).  Without a clear way to cause this issue, getting 
to the root
cause is much harder.  For example, there is no clear way to say that 
4.4.1 will never
have this issue (it just has not yet done so).

There are 3 mmio_size values that make sense to try.
1) mmio_hole = 1033
    This is what Konrad Wilk suggested (hole based on bare metal bios).  
This has been
     rounded up to the nearest MB.
2) mmio_hole = 1024
     This might be a good size (512 may be just a little too small).
3) mmio_size = 512
     This is the size that you think has worked in the past.

I would also see if less guest ram (like 3.0 GiB) can still reproduce 
the issue.

    -Don Slutz

> Possibly useful information follows.
>
> Thanks,
>
> Steve
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:43:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlfK0-0003jf-2W; Tue, 04 Nov 2014 14:43:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlfJy-0003jO-Q3
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:42:58 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	B3/74-02696-2F5E8545; Tue, 04 Nov 2014 14:42:58 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415112177!7855014!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22445 invoked from network); 4 Nov 2014 14:42:57 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:42:57 -0000
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLG90331; Tue, 04 Nov 2014 14:42:52 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Tue, 4 Nov 2014 14:42:43 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 7/7] xen/arm: Move vGIC registers on Hip04 platform
Thread-Index: AQHP94XhB6oL3dDu/UqzmHk5UboxZ5xQeh2AgAAOUpA=
Date: Tue, 4 Nov 2014 14:42:43 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B18B@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
	<5458D6C5.7010307@linaro.org>
In-Reply-To: <5458D6C5.7010307@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 7/7] xen/arm: Move vGIC registers on
	Hip04 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

> 
> Hi Frediano,
> 
> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > ---
> >  xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
> >  xen/include/asm-arm/gic.h |  2 ++
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > cea9edc..eb8cc19 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -669,8 +669,19 @@ static int gicv2_make_dt_node(const struct
> domain *d,
> >          return -FDT_ERR_XEN(ENOMEM);
> >
> >      tmp = new_cells;
> > -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > +
> > +    if ( nr_gic_cpu_if == 16 )
> > +    {
> > +        dt_set_range(&tmp, node, d->arch.vgic.dbase -
> HIP04_VGIC_REG_OFFSET,
> > +                     PAGE_SIZE);
> > +        dt_set_range(&tmp, node, d->arch.vgic.cbase -
> HIP04_VGIC_REG_OFFSET,
> > +                     PAGE_SIZE * 2);
> > +    }
> > +    else
> > +    {
> > +        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > +        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > +    }
> >
> >      res = fdt_property(fdt, "reg", new_cells, len);
> >      xfree(new_cells);
> > diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> > index 3d2b3db..5af8201 100644
> > --- a/xen/include/asm-arm/gic.h
> > +++ b/xen/include/asm-arm/gic.h
> > @@ -147,6 +147,8 @@
> >  #define GICH_LR_PENDING         1
> >  #define GICH_LR_ACTIVE          2
> >
> > +#define HIP04_VGIC_REG_OFFSET   0xe0000000
> > +
> 
> Please move this define in gic-v2.c. The header gic.h should only
> contains value that needs to be shared with the vgic and/or the other
> GIC drivers.
> 
> Also, where does come from the offset? Any pointer to the documentation?
> 

Well,
  I think I already sent a mail for this problem but got no reply (or I missed it).

The problem came from how the DTB is in Linux and how Xen override devices in the DTB.

On Linux I have

/ {
...
       soc {
                /* It's a 32-bit SoC. */
                #address-cells = <1>;
                #size-cells = <1>;
                compatible = "simple-bus";
                interrupt-parent = <&gic>;
                ranges = <0 0 0xe0000000 0x10000000>;

                gic: interrupt-controller@c01000 {
                        compatible = "hisilicon,hip04-intc";
                        #interrupt-cells = <3>;
                        #address-cells = <0>;
                        interrupt-controller;
                        interrupts = <1 9 0xf04>;

                        reg = <0xc01000 0x1000>, <0xc02000 0x1000>,
                              <0xc04000 0x2000>, <0xc06000 0x2000>;
                };
...

So the address of controller is 0xec01000 (see ranges in /soc and reg in /soc/interrupt-controller@c01000).

Now Xen compute address as 0xec01000 (which is fine) but then when it has to provide a virtual gic it just replace the gic entry with one with reg with 0xec01000 not taking into account the range is putting the reg into. This lead kernel to think the address is 0xe0000000+0xec01000 instead of 0xe00000000+0xc01000. Now... the DTB from Linux is perfectly legal but Xen does not handle it properly. I mostly consider this as a temporary workaround (I wrote a small comment on first version).

About solution to this there are different options:
- put gic always in the root to to have full range without any offset;
- fix reg according to range. This however could lead to extend the range;
- remove all ranges (and fix all devices' reg) to have always no offsets.

Regards,
  Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:43:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlfK0-0003jf-2W; Tue, 04 Nov 2014 14:43:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlfJy-0003jO-Q3
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:42:58 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	B3/74-02696-2F5E8545; Tue, 04 Nov 2014 14:42:58 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415112177!7855014!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22445 invoked from network); 4 Nov 2014 14:42:57 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:42:57 -0000
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLG90331; Tue, 04 Nov 2014 14:42:52 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Tue, 4 Nov 2014 14:42:43 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 7/7] xen/arm: Move vGIC registers on Hip04 platform
Thread-Index: AQHP94XhB6oL3dDu/UqzmHk5UboxZ5xQeh2AgAAOUpA=
Date: Tue, 4 Nov 2014 14:42:43 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B18B@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
	<5458D6C5.7010307@linaro.org>
In-Reply-To: <5458D6C5.7010307@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 7/7] xen/arm: Move vGIC registers on
	Hip04 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

> 
> Hi Frediano,
> 
> On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > ---
> >  xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
> >  xen/include/asm-arm/gic.h |  2 ++
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > cea9edc..eb8cc19 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -669,8 +669,19 @@ static int gicv2_make_dt_node(const struct
> domain *d,
> >          return -FDT_ERR_XEN(ENOMEM);
> >
> >      tmp = new_cells;
> > -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > +
> > +    if ( nr_gic_cpu_if == 16 )
> > +    {
> > +        dt_set_range(&tmp, node, d->arch.vgic.dbase -
> HIP04_VGIC_REG_OFFSET,
> > +                     PAGE_SIZE);
> > +        dt_set_range(&tmp, node, d->arch.vgic.cbase -
> HIP04_VGIC_REG_OFFSET,
> > +                     PAGE_SIZE * 2);
> > +    }
> > +    else
> > +    {
> > +        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > +        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > +    }
> >
> >      res = fdt_property(fdt, "reg", new_cells, len);
> >      xfree(new_cells);
> > diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> > index 3d2b3db..5af8201 100644
> > --- a/xen/include/asm-arm/gic.h
> > +++ b/xen/include/asm-arm/gic.h
> > @@ -147,6 +147,8 @@
> >  #define GICH_LR_PENDING         1
> >  #define GICH_LR_ACTIVE          2
> >
> > +#define HIP04_VGIC_REG_OFFSET   0xe0000000
> > +
> 
> Please move this define in gic-v2.c. The header gic.h should only
> contains value that needs to be shared with the vgic and/or the other
> GIC drivers.
> 
> Also, where does come from the offset? Any pointer to the documentation?
> 

Well,
  I think I already sent a mail for this problem but got no reply (or I missed it).

The problem came from how the DTB is in Linux and how Xen override devices in the DTB.

On Linux I have

/ {
...
       soc {
                /* It's a 32-bit SoC. */
                #address-cells = <1>;
                #size-cells = <1>;
                compatible = "simple-bus";
                interrupt-parent = <&gic>;
                ranges = <0 0 0xe0000000 0x10000000>;

                gic: interrupt-controller@c01000 {
                        compatible = "hisilicon,hip04-intc";
                        #interrupt-cells = <3>;
                        #address-cells = <0>;
                        interrupt-controller;
                        interrupts = <1 9 0xf04>;

                        reg = <0xc01000 0x1000>, <0xc02000 0x1000>,
                              <0xc04000 0x2000>, <0xc06000 0x2000>;
                };
...

So the address of controller is 0xec01000 (see ranges in /soc and reg in /soc/interrupt-controller@c01000).

Now Xen compute address as 0xec01000 (which is fine) but then when it has to provide a virtual gic it just replace the gic entry with one with reg with 0xec01000 not taking into account the range is putting the reg into. This lead kernel to think the address is 0xe0000000+0xec01000 instead of 0xe00000000+0xc01000. Now... the DTB from Linux is perfectly legal but Xen does not handle it properly. I mostly consider this as a temporary workaround (I wrote a small comment on first version).

About solution to this there are different options:
- put gic always in the root to to have full range without any offset;
- fix reg according to range. This however could lead to extend the range;
- remove all ranges (and fix all devices' reg) to have always no offsets.

Regards,
  Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:50:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:50:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlfQx-00040E-Ve; Tue, 04 Nov 2014 14:50:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlfQw-000409-1L
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:50:10 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	8D/13-17958-1A7E8545; Tue, 04 Nov 2014 14:50:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415112607!11450773!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5780 invoked from network); 4 Nov 2014 14:50:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:50:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187930415"
Message-ID: <1415112605.11486.45.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@huawei.com>
Date: Tue, 4 Nov 2014 14:50:05 +0000
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B18B@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
	<5458D6C5.7010307@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B18B@lhreml509-mbb>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 7/7] xen/arm: Move vGIC registers on
	Hip04 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, 2014-11-04 at 14:42 +0000, Frediano Ziglio wrote:
> > 
> > Hi Frediano,
> > 
> > On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > > ---
> > >  xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
> > >  xen/include/asm-arm/gic.h |  2 ++
> > >  2 files changed, 15 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > > cea9edc..eb8cc19 100644
> > > --- a/xen/arch/arm/gic-v2.c
> > > +++ b/xen/arch/arm/gic-v2.c
> > > @@ -669,8 +669,19 @@ static int gicv2_make_dt_node(const struct
> > domain *d,
> > >          return -FDT_ERR_XEN(ENOMEM);
> > >
> > >      tmp = new_cells;
> > > -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > > -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > > +
> > > +    if ( nr_gic_cpu_if == 16 )
> > > +    {
> > > +        dt_set_range(&tmp, node, d->arch.vgic.dbase -
> > HIP04_VGIC_REG_OFFSET,
> > > +                     PAGE_SIZE);
> > > +        dt_set_range(&tmp, node, d->arch.vgic.cbase -
> > HIP04_VGIC_REG_OFFSET,
> > > +                     PAGE_SIZE * 2);
> > > +    }
> > > +    else
> > > +    {
> > > +        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > > +        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > > +    }
> > >
> > >      res = fdt_property(fdt, "reg", new_cells, len);
> > >      xfree(new_cells);
> > > diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> > > index 3d2b3db..5af8201 100644
> > > --- a/xen/include/asm-arm/gic.h
> > > +++ b/xen/include/asm-arm/gic.h
> > > @@ -147,6 +147,8 @@
> > >  #define GICH_LR_PENDING         1
> > >  #define GICH_LR_ACTIVE          2
> > >
> > > +#define HIP04_VGIC_REG_OFFSET   0xe0000000
> > > +
> > 
> > Please move this define in gic-v2.c. The header gic.h should only
> > contains value that needs to be shared with the vgic and/or the other
> > GIC drivers.
> > 
> > Also, where does come from the offset? Any pointer to the documentation?
> > 
> 
> Well,
>   I think I already sent a mail for this problem but got no reply (or I missed it).
> 
> The problem came from how the DTB is in Linux and how Xen override devices in the DTB.
> 
> On Linux I have
> 
> / {
> ...
>        soc {
>                 /* It's a 32-bit SoC. */
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 compatible = "simple-bus";
>                 interrupt-parent = <&gic>;
>                 ranges = <0 0 0xe0000000 0x10000000>;
> 
>                 gic: interrupt-controller@c01000 {
>                         compatible = "hisilicon,hip04-intc";
>                         #interrupt-cells = <3>;
>                         #address-cells = <0>;
>                         interrupt-controller;
>                         interrupts = <1 9 0xf04>;
> 
>                         reg = <0xc01000 0x1000>, <0xc02000 0x1000>,
>                               <0xc04000 0x2000>, <0xc06000 0x2000>;
>                 };
> ...
> 
> So the address of controller is 0xec01000 (see ranges in /soc and reg in /soc/interrupt-controller@c01000).
> 
> Now Xen compute address as 0xec01000 (which is fine) but then when it has to provide a virtual gic it just replace the gic entry with one with reg with 0xec01000 not taking into account the range is putting the reg into. This lead kernel to think the address is 0xe0000000+0xec01000 instead of 0xe00000000+0xc01000. Now... the DTB from Linux is perfectly legal but Xen does not handle it properly. I mostly consider this as a temporary workaround (I wrote a small comment on first version).
> 
> About solution to this there are different options:
> - put gic always in the root to to have full range without any offset;
> - fix reg according to range. This however could lead to extend the range;
> - remove all ranges (and fix all devices' reg) to have always no offsets.

  - Propagate the host GICC register value literally over, having 
    mapping the GICV there. i.e. don't translate the value which is 
    written to the DT.

None of the other options sound very good to me.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 14:50:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 14:50:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlfQx-00040E-Ve; Tue, 04 Nov 2014 14:50:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlfQw-000409-1L
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 14:50:10 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	8D/13-17958-1A7E8545; Tue, 04 Nov 2014 14:50:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415112607!11450773!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5780 invoked from network); 4 Nov 2014 14:50:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 14:50:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187930415"
Message-ID: <1415112605.11486.45.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@huawei.com>
Date: Tue, 4 Nov 2014 14:50:05 +0000
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B18B@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
	<5458D6C5.7010307@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B18B@lhreml509-mbb>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 7/7] xen/arm: Move vGIC registers on
	Hip04 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, 2014-11-04 at 14:42 +0000, Frediano Ziglio wrote:
> > 
> > Hi Frediano,
> > 
> > On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > > ---
> > >  xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
> > >  xen/include/asm-arm/gic.h |  2 ++
> > >  2 files changed, 15 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > > cea9edc..eb8cc19 100644
> > > --- a/xen/arch/arm/gic-v2.c
> > > +++ b/xen/arch/arm/gic-v2.c
> > > @@ -669,8 +669,19 @@ static int gicv2_make_dt_node(const struct
> > domain *d,
> > >          return -FDT_ERR_XEN(ENOMEM);
> > >
> > >      tmp = new_cells;
> > > -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > > -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > > +
> > > +    if ( nr_gic_cpu_if == 16 )
> > > +    {
> > > +        dt_set_range(&tmp, node, d->arch.vgic.dbase -
> > HIP04_VGIC_REG_OFFSET,
> > > +                     PAGE_SIZE);
> > > +        dt_set_range(&tmp, node, d->arch.vgic.cbase -
> > HIP04_VGIC_REG_OFFSET,
> > > +                     PAGE_SIZE * 2);
> > > +    }
> > > +    else
> > > +    {
> > > +        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > > +        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > > +    }
> > >
> > >      res = fdt_property(fdt, "reg", new_cells, len);
> > >      xfree(new_cells);
> > > diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> > > index 3d2b3db..5af8201 100644
> > > --- a/xen/include/asm-arm/gic.h
> > > +++ b/xen/include/asm-arm/gic.h
> > > @@ -147,6 +147,8 @@
> > >  #define GICH_LR_PENDING         1
> > >  #define GICH_LR_ACTIVE          2
> > >
> > > +#define HIP04_VGIC_REG_OFFSET   0xe0000000
> > > +
> > 
> > Please move this define in gic-v2.c. The header gic.h should only
> > contains value that needs to be shared with the vgic and/or the other
> > GIC drivers.
> > 
> > Also, where does come from the offset? Any pointer to the documentation?
> > 
> 
> Well,
>   I think I already sent a mail for this problem but got no reply (or I missed it).
> 
> The problem came from how the DTB is in Linux and how Xen override devices in the DTB.
> 
> On Linux I have
> 
> / {
> ...
>        soc {
>                 /* It's a 32-bit SoC. */
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 compatible = "simple-bus";
>                 interrupt-parent = <&gic>;
>                 ranges = <0 0 0xe0000000 0x10000000>;
> 
>                 gic: interrupt-controller@c01000 {
>                         compatible = "hisilicon,hip04-intc";
>                         #interrupt-cells = <3>;
>                         #address-cells = <0>;
>                         interrupt-controller;
>                         interrupts = <1 9 0xf04>;
> 
>                         reg = <0xc01000 0x1000>, <0xc02000 0x1000>,
>                               <0xc04000 0x2000>, <0xc06000 0x2000>;
>                 };
> ...
> 
> So the address of controller is 0xec01000 (see ranges in /soc and reg in /soc/interrupt-controller@c01000).
> 
> Now Xen compute address as 0xec01000 (which is fine) but then when it has to provide a virtual gic it just replace the gic entry with one with reg with 0xec01000 not taking into account the range is putting the reg into. This lead kernel to think the address is 0xe0000000+0xec01000 instead of 0xe00000000+0xc01000. Now... the DTB from Linux is perfectly legal but Xen does not handle it properly. I mostly consider this as a temporary workaround (I wrote a small comment on first version).
> 
> About solution to this there are different options:
> - put gic always in the root to to have full range without any offset;
> - fix reg according to range. This however could lead to extend the range;
> - remove all ranges (and fix all devices' reg) to have always no offsets.

  - Propagate the host GICC register value literally over, having 
    mapping the GICV there. i.e. don't translate the value which is 
    written to the DT.

None of the other options sound very good to me.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:01:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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 1XlfbG-0004Il-9l; Tue, 04 Nov 2014 15:00:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlfbE-0004Ig-OV
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 15:00:48 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9E/C4-24859-F1AE8545; Tue, 04 Nov 2014 15:00:47 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415113244!11618670!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24918 invoked from network); 4 Nov 2014 15:00:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 15:00:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189316018"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 10:00:24 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlfaq-0006cR-AN;
	Tue, 04 Nov 2014 15:00:24 +0000
Date: Tue, 4 Nov 2014 15:00:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Grygorii Strashko <grygorii.strashko@ti.com>
In-Reply-To: <5458B9FC.3050309@ti.com>
Message-ID: <alpine.DEB.2.02.1411041419490.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<5458B9FC.3050309@ti.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Grygorii Strashko wrote:
> Hi Stefano,
> 
> On 11/03/2014 01:10 PM, Stefano Stabellini wrote:
> > On Mon, 3 Nov 2014, Will Deacon wrote:
> >> On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> >>> On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> >>>> Introduce a boolean flag and an accessor function to check whether a
> >>>> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> >>>>
> >>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>>> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> >>>> CC: will.deacon@arm.com
> >>>
> >>> Will, Catalin,
> >>> are you OK with this patch?
> >>
> >> It would be nicer if the dma_coherent flag didn't have to be duplicated by
> >> each architecture in dev_archdata. Is there any reason not to put it in the
> >> core code?
> > 
> > Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> > struct device as Catalin initially suggested, what would be the default
> > for each architecture? Where would I set it for arch that don't use
> > device tree? It is not easy.
> > 
> > I thought it would be better to introduce is_device_dma_coherent only on
> > the architectures where it certainly makes sense to have it. In fact I
> > checked and arm and arm64 are the only architectures to define
> > set_arch_dma_coherent_ops at the moment. At that point if
> > is_device_dma_coherent becomes arch-specific, it makes sense to store
> > the flag in dev_archdata instead of struct device.
> 
> The proposition from Will looks reasonable for me too, because
> there is "small" side-effect of adding such kind of properties to
> arch-specific data or even to the core device structure. ;(
> 
> There are some sub-systems in kernel which do not create their devices
> from DT and instead some host device populates its children devices manually.
>  Now, I know at least two cases:
> - usb: dwc3 core creates xhci device manually
> - pci: adds its client devices
> 
> In such, case DMA configuration have to be propagated from host to
> child (in our case host device's got DMA configuration from DT), like:
> 	dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask);
> 
> 	xhci->dev.parent	= dwc->dev;
> 	xhci->dev.dma_mask	= dwc->dev->dma_mask;
> 	xhci->dev.dma_parms	= dwc->dev->dma_parms;
> 
> So, once new DMA property is added it has to be propagated from 
> host to child device too.
> 
> Recently, the new property  dma_pfn_offset was introduced in struct device 
> and such kind of problem was observed on keystone 2:
> - for usb case it was fixed using Platform Bus notifier (xhci - platform device)
> - for pci - the work is in progress, because solution with PCI Bus notifier
>   was rejected https://lkml.org/lkml/2014/10/10/308.
> 
> In general, if dma_coherent will belong to struct device then
> such problems will be possible to fix directly in drivers/subsystems:
> xhci->dev.dma_coherent	= dwc->dev->dma_coherent;
> 
> But, if it will be arch-specific data then it will be impossible to
> set it without introducing proper and arch-specific setters/getters functions.
>
> Also, as an idea, we are thinking about introducing something like:
>   void dma_apply_parent_cfg(struct device *dev, struct device *parent)
> which will ensure that all DMA configuration properly copied from
> parent to children device. Now it should be (as minimum for ARM):
>  dma_mask
>  coherent_dma_mask
>  dma_parms
>  dma_pfn_offset
>  dev_archdata->dma_ops
>  [dma_coherent]?

I understand your concern but the problem you have goes far beyond a
simple dma_coherent flag: what about all the other dev_archdata fields?
Aside from dma_ops, on some other architectures there might be other
data structrures in dev_archdata that need to be properly initialized
from the parent.

Your idea of introducing something like dma_apply_parent_cfg is the only
solid solution I can see.  However I would consider naming it something
more generic like init_dev_from_parent to handle other possible
configurations (inside or outside dev_archdata) that might have to be
initialized from information on the parent device.


Regarding the dma_coherent flag, I still prefer this approach because
introducing the dma_coherent flag in dev_archdata wouldn't make this
issue any worse than already is, but would avoid other problems as
mentioned in my previous reply.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:01:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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 1XlfbG-0004Il-9l; Tue, 04 Nov 2014 15:00:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlfbE-0004Ig-OV
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 15:00:48 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9E/C4-24859-F1AE8545; Tue, 04 Nov 2014 15:00:47 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415113244!11618670!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24918 invoked from network); 4 Nov 2014 15:00:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 15:00:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189316018"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 10:00:24 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlfaq-0006cR-AN;
	Tue, 04 Nov 2014 15:00:24 +0000
Date: Tue, 4 Nov 2014 15:00:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Grygorii Strashko <grygorii.strashko@ti.com>
In-Reply-To: <5458B9FC.3050309@ti.com>
Message-ID: <alpine.DEB.2.02.1411041419490.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<5458B9FC.3050309@ti.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Grygorii Strashko wrote:
> Hi Stefano,
> 
> On 11/03/2014 01:10 PM, Stefano Stabellini wrote:
> > On Mon, 3 Nov 2014, Will Deacon wrote:
> >> On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> >>> On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> >>>> Introduce a boolean flag and an accessor function to check whether a
> >>>> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> >>>>
> >>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>>> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> >>>> CC: will.deacon@arm.com
> >>>
> >>> Will, Catalin,
> >>> are you OK with this patch?
> >>
> >> It would be nicer if the dma_coherent flag didn't have to be duplicated by
> >> each architecture in dev_archdata. Is there any reason not to put it in the
> >> core code?
> > 
> > Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> > struct device as Catalin initially suggested, what would be the default
> > for each architecture? Where would I set it for arch that don't use
> > device tree? It is not easy.
> > 
> > I thought it would be better to introduce is_device_dma_coherent only on
> > the architectures where it certainly makes sense to have it. In fact I
> > checked and arm and arm64 are the only architectures to define
> > set_arch_dma_coherent_ops at the moment. At that point if
> > is_device_dma_coherent becomes arch-specific, it makes sense to store
> > the flag in dev_archdata instead of struct device.
> 
> The proposition from Will looks reasonable for me too, because
> there is "small" side-effect of adding such kind of properties to
> arch-specific data or even to the core device structure. ;(
> 
> There are some sub-systems in kernel which do not create their devices
> from DT and instead some host device populates its children devices manually.
>  Now, I know at least two cases:
> - usb: dwc3 core creates xhci device manually
> - pci: adds its client devices
> 
> In such, case DMA configuration have to be propagated from host to
> child (in our case host device's got DMA configuration from DT), like:
> 	dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask);
> 
> 	xhci->dev.parent	= dwc->dev;
> 	xhci->dev.dma_mask	= dwc->dev->dma_mask;
> 	xhci->dev.dma_parms	= dwc->dev->dma_parms;
> 
> So, once new DMA property is added it has to be propagated from 
> host to child device too.
> 
> Recently, the new property  dma_pfn_offset was introduced in struct device 
> and such kind of problem was observed on keystone 2:
> - for usb case it was fixed using Platform Bus notifier (xhci - platform device)
> - for pci - the work is in progress, because solution with PCI Bus notifier
>   was rejected https://lkml.org/lkml/2014/10/10/308.
> 
> In general, if dma_coherent will belong to struct device then
> such problems will be possible to fix directly in drivers/subsystems:
> xhci->dev.dma_coherent	= dwc->dev->dma_coherent;
> 
> But, if it will be arch-specific data then it will be impossible to
> set it without introducing proper and arch-specific setters/getters functions.
>
> Also, as an idea, we are thinking about introducing something like:
>   void dma_apply_parent_cfg(struct device *dev, struct device *parent)
> which will ensure that all DMA configuration properly copied from
> parent to children device. Now it should be (as minimum for ARM):
>  dma_mask
>  coherent_dma_mask
>  dma_parms
>  dma_pfn_offset
>  dev_archdata->dma_ops
>  [dma_coherent]?

I understand your concern but the problem you have goes far beyond a
simple dma_coherent flag: what about all the other dev_archdata fields?
Aside from dma_ops, on some other architectures there might be other
data structrures in dev_archdata that need to be properly initialized
from the parent.

Your idea of introducing something like dma_apply_parent_cfg is the only
solid solution I can see.  However I would consider naming it something
more generic like init_dev_from_parent to handle other possible
configurations (inside or outside dev_archdata) that might have to be
initialized from information on the parent device.


Regarding the dma_coherent flag, I still prefer this approach because
introducing the dma_coherent flag in dev_archdata wouldn't make this
issue any worse than already is, but would avoid other problems as
mentioned in my previous reply.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:14:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15: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.xen.org>)
	id 1Xlfnn-0004uh-OD; Tue, 04 Nov 2014 15:13:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1Xlfnm-0004uc-4V
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:13:46 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	82/C5-02699-92DE8545; Tue, 04 Nov 2014 15:13:45 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415114024!12515012!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2014 invoked from network); 4 Nov 2014 15:13:44 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 15:13:44 -0000
Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1Xlfni-0007EG-EG; Tue, 04 Nov 2014 16:13:42 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.64])
	by justin.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1Xlfni-00008N-0Z; Tue, 04 Nov 2014 16:13:42 +0100
Message-ID: <5458ED27.8060502@web2web.at>
Date: Tue, 04 Nov 2014 16:13:43 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org, Ian Campbell <ian.campbell@citrix.com>
References: <544EB843.9060503@web2web.at>		<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at>
In-Reply-To: <5452C43C.6050800@web2web.at>
X-Univie-Virus-Scan: scanned by ClamAV on justin.univie.ac.at
Subject: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM with
	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

I assume it may be warranted to "upgrade" this issue to a bug status 
(obviously also in the hope that it attractes wider interest) by 
prefixing the subject line with a [BUG] prefix as per 
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project. I have 
exhausted all my options (including numerous IRC attempts), provided all 
the information I have been asked for but the issue persists and nobody 
seems to have an idea how to rectify the problem.

If you need any more information, I'll do my utmost to provide it asap.

I appologise if this is not the right approach, but at the moment, I'm 
just frustrated that a well working system under 4.3.1 simply stopped 
working after upgrading to 4.3.3 more than a week ago. I very much love 
XEN, it's a fabulous product, and I would simply like to get it working 
again.

Many thanks in advance for your support and your understanding

Atom2

Am 31.10.14 um 00:05 schrieb Atom2:
> Ian,
> apologies for pinging this, but I am not sure whether there's anything
> else over and above the answers in my last message (copied below) that
> you are expecting me to provide before being able to judge where and
> what the issue might be?
>
> Many thanks in advance, Atom2
>
> P.S. In case you again require the attachments to my last message,
> please let me know.
>
> Am 29.10.14 um 01:26 schrieb Atom2:
>> To keep the thread together I am again submitting the relevant parts of
>> my last answer (which due to an error on my part originally went out to
>> Ian only and I only forward it to the list afterwards which resulted in
>> an out-of-thread appeareance) together with the (new) results of my gdb
>> excercise. Sorry for any confusion this may(might have) cause(d).
>>
>> Am 28.10.14 um 17:04 schrieb Ian Campbell:
>> [...]
>>>> With regards to gdb: I can certainly run the command under gdb after
>>>> including debug support to the executables - that's no big deal.
>>>> I would, however, ask for your advice as to what I need to recompile
>>>> with debugger support? Is xen-tools (which includes xl) sufficient
>>>
>>> I think just the Xen bits would be sufficient, at least to start with.
>>>
>>>>   or
>>>> would you think that I also need to include debug support for gcc as
>>>> the
>>>> library that is mentioned in /var/log/messages (libgcc_s.so.1) seems to
>>>> belong to the gcc package? Or is this library a red herring that just
>>>> works as the catch-all code getting and finally handling the segfault?
>>>
>>> I'd recommend ignoring it for now, in the event that the backtrace from
>>> just the xen bits suggests a gcc issue that might change. My money right
>>> now is on it being a xen issue though.
>>>
>> After recompiling xen-tools with gdb debug support I started the
>> following command:
>> # gdb --args /usr/sbin/xl create pfsense -c
>>
>> Please find the command's screen output after its start up to the
>> segfault including the output of the bt command after the segfault in
>> the attached document named "create".
>>
>> Furthermore I did the same for the destroy command:
>> # gdb --args /usr/sbin/xl destroy pfsense
>>
>> The output of this command is in the attached document named "destroy".
>>
>> I haven't got much experience with gdb yet so I am unable to interpret
>> the outcome of either. Also if there's more/different stuff required,
>> please advise me what to do next. Tx.
>>
>>>>> [...]
>>>>>> pci          = [ '04:00.0', '0a:08.0', '0a:0b.0' ]
>>>>>
>>>>> You say in $subject that the failure is with PCI, is that because
>>>>> you've
>>>>> tried an HVM domain without and it is ok, or is it just that all your
>>>>> HVM domains happen to have passthrough enabled?
>>>> I haven't tried HVM domains without PCI passthrough (but PV domains w/o
>>>> PCI passthrough and they did not segfault) so far as all my HVM domains
>>>> require PCI devices (either at least a network card for pfsense - in
>>>> actual facts it's more than one that's being passed through - or a SATA
>>>> controller for my second HVM which is used as a storage VM).
>>>
>>> The VM doesn't need to be fully functional, it just needs to boot
>>> without crashing the toolstack. Just running your existing VM with the
>>> pci line commented out would be useful.
>> Before re-compiling the xen-tools I made a quick test as you suggested
>> and commented out the pci line from my config file ... and the boot menu
>> showed up (which it did not before when the segfault happened).
>> I did not boot the pfsense vm any further as this might lead to a change
>> in my configuration due to missing devices, but to me this at first
>> sight seemed to indicate that is has to do with the PCI passthrough
>> functionality.
>> Although as I did not want to boot the machine (and "xl shutdown" did
>> not work, not even with -F) I then decided to
>>      xl destroy pfsense
>> and that printed a segmentation fault message (in both the shell window
>> where I started the command from and the console window where the
>> boot-menu was shown) despite no PCI devices being passed through.
>>
>> To also check PCI passthrough with a PV domain: I added a pci device to
>> a config file for a PV domain and started that with
>>      xl create voip -c
>> The boot menu appeared without issues. I then also tried
>>      xl destroy voip
>> from another window and that issued the following error messages in the
>> shell window (without using any -vvv option):
>>
>> # xl destroy voip
>> libxl: error: libxl_pci.c:1247:do_pci_remove: xc_domain_irq_permission
>> irq=17
>> libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
>> /local/domain/0/backend/pci/4/0 not ready
>> libxl: error: libxl_pci.c:1247:do_pci_remove: xc_domain_irq_permission
>> irq=16
>> libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
>> /local/domain/0/backend/pci/4/0 not ready
>> libxl: error: libxl_pci.c:1247:do_pci_remove: xc_domain_irq_permission
>> irq=23
>> libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
>> /local/domain/0/backend/pci/4/0 not ready
>> Segmentation fault
>>
>> The "Segmentation fault" message also appeared in both the console
>> window for the domU and the shell window.
>>
>> This all seems a bit strange to me at the moement, but I am sure with
>> your help we will arrive at the grounds of this.
>>
>> Thanks and regards Atom

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:14:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15: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.xen.org>)
	id 1Xlfnn-0004uh-OD; Tue, 04 Nov 2014 15:13:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1Xlfnm-0004uc-4V
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:13:46 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	82/C5-02699-92DE8545; Tue, 04 Nov 2014 15:13:45 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415114024!12515012!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2014 invoked from network); 4 Nov 2014 15:13:44 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 15:13:44 -0000
Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1Xlfni-0007EG-EG; Tue, 04 Nov 2014 16:13:42 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.64])
	by justin.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1Xlfni-00008N-0Z; Tue, 04 Nov 2014 16:13:42 +0100
Message-ID: <5458ED27.8060502@web2web.at>
Date: Tue, 04 Nov 2014 16:13:43 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org, Ian Campbell <ian.campbell@citrix.com>
References: <544EB843.9060503@web2web.at>		<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at>
In-Reply-To: <5452C43C.6050800@web2web.at>
X-Univie-Virus-Scan: scanned by ClamAV on justin.univie.ac.at
Subject: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM with
	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

I assume it may be warranted to "upgrade" this issue to a bug status 
(obviously also in the hope that it attractes wider interest) by 
prefixing the subject line with a [BUG] prefix as per 
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project. I have 
exhausted all my options (including numerous IRC attempts), provided all 
the information I have been asked for but the issue persists and nobody 
seems to have an idea how to rectify the problem.

If you need any more information, I'll do my utmost to provide it asap.

I appologise if this is not the right approach, but at the moment, I'm 
just frustrated that a well working system under 4.3.1 simply stopped 
working after upgrading to 4.3.3 more than a week ago. I very much love 
XEN, it's a fabulous product, and I would simply like to get it working 
again.

Many thanks in advance for your support and your understanding

Atom2

Am 31.10.14 um 00:05 schrieb Atom2:
> Ian,
> apologies for pinging this, but I am not sure whether there's anything
> else over and above the answers in my last message (copied below) that
> you are expecting me to provide before being able to judge where and
> what the issue might be?
>
> Many thanks in advance, Atom2
>
> P.S. In case you again require the attachments to my last message,
> please let me know.
>
> Am 29.10.14 um 01:26 schrieb Atom2:
>> To keep the thread together I am again submitting the relevant parts of
>> my last answer (which due to an error on my part originally went out to
>> Ian only and I only forward it to the list afterwards which resulted in
>> an out-of-thread appeareance) together with the (new) results of my gdb
>> excercise. Sorry for any confusion this may(might have) cause(d).
>>
>> Am 28.10.14 um 17:04 schrieb Ian Campbell:
>> [...]
>>>> With regards to gdb: I can certainly run the command under gdb after
>>>> including debug support to the executables - that's no big deal.
>>>> I would, however, ask for your advice as to what I need to recompile
>>>> with debugger support? Is xen-tools (which includes xl) sufficient
>>>
>>> I think just the Xen bits would be sufficient, at least to start with.
>>>
>>>>   or
>>>> would you think that I also need to include debug support for gcc as
>>>> the
>>>> library that is mentioned in /var/log/messages (libgcc_s.so.1) seems to
>>>> belong to the gcc package? Or is this library a red herring that just
>>>> works as the catch-all code getting and finally handling the segfault?
>>>
>>> I'd recommend ignoring it for now, in the event that the backtrace from
>>> just the xen bits suggests a gcc issue that might change. My money right
>>> now is on it being a xen issue though.
>>>
>> After recompiling xen-tools with gdb debug support I started the
>> following command:
>> # gdb --args /usr/sbin/xl create pfsense -c
>>
>> Please find the command's screen output after its start up to the
>> segfault including the output of the bt command after the segfault in
>> the attached document named "create".
>>
>> Furthermore I did the same for the destroy command:
>> # gdb --args /usr/sbin/xl destroy pfsense
>>
>> The output of this command is in the attached document named "destroy".
>>
>> I haven't got much experience with gdb yet so I am unable to interpret
>> the outcome of either. Also if there's more/different stuff required,
>> please advise me what to do next. Tx.
>>
>>>>> [...]
>>>>>> pci          = [ '04:00.0', '0a:08.0', '0a:0b.0' ]
>>>>>
>>>>> You say in $subject that the failure is with PCI, is that because
>>>>> you've
>>>>> tried an HVM domain without and it is ok, or is it just that all your
>>>>> HVM domains happen to have passthrough enabled?
>>>> I haven't tried HVM domains without PCI passthrough (but PV domains w/o
>>>> PCI passthrough and they did not segfault) so far as all my HVM domains
>>>> require PCI devices (either at least a network card for pfsense - in
>>>> actual facts it's more than one that's being passed through - or a SATA
>>>> controller for my second HVM which is used as a storage VM).
>>>
>>> The VM doesn't need to be fully functional, it just needs to boot
>>> without crashing the toolstack. Just running your existing VM with the
>>> pci line commented out would be useful.
>> Before re-compiling the xen-tools I made a quick test as you suggested
>> and commented out the pci line from my config file ... and the boot menu
>> showed up (which it did not before when the segfault happened).
>> I did not boot the pfsense vm any further as this might lead to a change
>> in my configuration due to missing devices, but to me this at first
>> sight seemed to indicate that is has to do with the PCI passthrough
>> functionality.
>> Although as I did not want to boot the machine (and "xl shutdown" did
>> not work, not even with -F) I then decided to
>>      xl destroy pfsense
>> and that printed a segmentation fault message (in both the shell window
>> where I started the command from and the console window where the
>> boot-menu was shown) despite no PCI devices being passed through.
>>
>> To also check PCI passthrough with a PV domain: I added a pci device to
>> a config file for a PV domain and started that with
>>      xl create voip -c
>> The boot menu appeared without issues. I then also tried
>>      xl destroy voip
>> from another window and that issued the following error messages in the
>> shell window (without using any -vvv option):
>>
>> # xl destroy voip
>> libxl: error: libxl_pci.c:1247:do_pci_remove: xc_domain_irq_permission
>> irq=17
>> libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
>> /local/domain/0/backend/pci/4/0 not ready
>> libxl: error: libxl_pci.c:1247:do_pci_remove: xc_domain_irq_permission
>> irq=16
>> libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
>> /local/domain/0/backend/pci/4/0 not ready
>> libxl: error: libxl_pci.c:1247:do_pci_remove: xc_domain_irq_permission
>> irq=23
>> libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
>> /local/domain/0/backend/pci/4/0 not ready
>> Segmentation fault
>>
>> The "Segmentation fault" message also appeared in both the console
>> window for the domU and the shell window.
>>
>> This all seems a bit strange to me at the moement, but I am sure with
>> your help we will arrive at the grounds of this.
>>
>> Thanks and regards Atom

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:27:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15:27:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlg0L-00055w-3F; Tue, 04 Nov 2014 15:26:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xlg0K-00055p-0H
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:26:44 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E0/C2-24532-330F8545; Tue, 04 Nov 2014 15:26:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415114801!12736749!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11439 invoked from network); 4 Nov 2014 15:26:42 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 15:26:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4FQZdr000882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 15:26:35 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA4EcNhT008407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Nov 2014 14:38:23 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA4EcMfb008337; Tue, 4 Nov 2014 14:38:23 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 07:26:32 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C8AC91105B4; Tue,  4 Nov 2014 10:26:31 -0500 (EST)
Date: Tue, 4 Nov 2014 10:26:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141104152631.GD4510@laptop.dumpdata.com>
References: <1414425614-43267-1-git-send-email-simon.rowe@eu.citrix.com>
	<544E7459.5070906@oracle.com>
	<1415097997.11486.18.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415097997.11486.18.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Dave.Scott@citrix.com, Simon Rowe <simon.rowe@eu.citrix.com>,
	xen-devel@lists.xen.org, Stefano.Stabellini@citrix.com,
	Ian.Jackson@citrix.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] pygrub: fix non-interactive parsing of
	grub1 config files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 10:46:37AM +0000, Ian Campbell wrote:
> On Mon, 2014-10-27 at 12:35 -0400, Boris Ostrovsky wrote:
> > On 10/27/2014 12:00 PM, Simon Rowe wrote:
> > > Changes to handle non-numeric default attributes for grub2 caused run_grub()
> > > to attempt to index into the images list using a string. Pull out the code
> > > that handles submenus into a new function and use that to ensure sel is
> > > numeric.
> > >
> > > Reported-by: David Scott <dave.scott@citrix.com>
> > > Signed-off-by: Simon Rowe <simon.rowe@eu.citrix.com>
> > 
> > Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> And applied as a bug fix (I'm not sure if Konrad's response was intended
> as a release-ack).

Yes. Thank you for checking this patch in.
> 
> > 
> > > ---
> > >   tools/pygrub/src/pygrub |   23 ++++++++++++++---------
> > >   1 file changed, 14 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> > > index 1ae34a2..4cc846f 100644
> > > --- a/tools/pygrub/src/pygrub
> > > +++ b/tools/pygrub/src/pygrub
> > > @@ -456,11 +456,9 @@ class Grub:
> > >           del f
> > >           self.cf.parse(buf)
> > >   
> > > -    def run(self):
> > > -        timeout = int(self.cf.timeout)
> > > -
> > > +    def image_index(self):
> > >           if self.cf.default.isdigit():
> > > -            self.selected_image = int(self.cf.default)
> > > +            sel = int(self.cf.default)
> > >           else:
> > >               # We don't fully support submenus. Look for the leaf value in
> > >               # "submenu0>submenu1>...>menuentry" and hope that it's unique.
> > > @@ -472,16 +470,23 @@ class Grub:
> > >                       break
> > >   
> > >               # Map string to index in images array
> > > -            self.selected_image = 0
> > > +            sel = 0
> > >               for i in range(len(self.cf.images)):
> > >                   if self.cf.images[i].title == title:
> > > -                    self.selected_image = i
> > > +                    sel = i
> > >                       break
> > >   
> > >           # If the selected (default) image doesn't exist we select the first entry
> > > -        if self.selected_image > len(self.cf.images):
> > > +        if sel > len(self.cf.images):
> > >               logging.warning("Default image not found")
> > > -            self.selected_image = 0
> > > +            sel = 0
> > > +
> > > +        return sel
> > > +
> > > +    def run(self):
> > > +        timeout = int(self.cf.timeout)
> > > +        self.selected_image = self.image_index()
> > > +
> > >           self.isdone = False
> > >           while not self.isdone:
> > >               self.run_main(timeout)
> > > @@ -626,7 +631,7 @@ def run_grub(file, entry, fs, cfg_args):
> > >       if interactive and not list_entries:
> > >           curses.wrapper(run_main)
> > >       else:
> > > -        sel = g.cf.default
> > > +        sel = g.image_index()
> > >   
> > >       # set the entry to boot as requested
> > >       if entry is not None:
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:27:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15:27:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlg0L-00055w-3F; Tue, 04 Nov 2014 15:26:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xlg0K-00055p-0H
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:26:44 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E0/C2-24532-330F8545; Tue, 04 Nov 2014 15:26:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415114801!12736749!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11439 invoked from network); 4 Nov 2014 15:26:42 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 15:26:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4FQZdr000882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 15:26:35 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA4EcNhT008407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Nov 2014 14:38:23 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA4EcMfb008337; Tue, 4 Nov 2014 14:38:23 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 07:26:32 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C8AC91105B4; Tue,  4 Nov 2014 10:26:31 -0500 (EST)
Date: Tue, 4 Nov 2014 10:26:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141104152631.GD4510@laptop.dumpdata.com>
References: <1414425614-43267-1-git-send-email-simon.rowe@eu.citrix.com>
	<544E7459.5070906@oracle.com>
	<1415097997.11486.18.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415097997.11486.18.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Dave.Scott@citrix.com, Simon Rowe <simon.rowe@eu.citrix.com>,
	xen-devel@lists.xen.org, Stefano.Stabellini@citrix.com,
	Ian.Jackson@citrix.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] pygrub: fix non-interactive parsing of
	grub1 config files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 10:46:37AM +0000, Ian Campbell wrote:
> On Mon, 2014-10-27 at 12:35 -0400, Boris Ostrovsky wrote:
> > On 10/27/2014 12:00 PM, Simon Rowe wrote:
> > > Changes to handle non-numeric default attributes for grub2 caused run_grub()
> > > to attempt to index into the images list using a string. Pull out the code
> > > that handles submenus into a new function and use that to ensure sel is
> > > numeric.
> > >
> > > Reported-by: David Scott <dave.scott@citrix.com>
> > > Signed-off-by: Simon Rowe <simon.rowe@eu.citrix.com>
> > 
> > Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> And applied as a bug fix (I'm not sure if Konrad's response was intended
> as a release-ack).

Yes. Thank you for checking this patch in.
> 
> > 
> > > ---
> > >   tools/pygrub/src/pygrub |   23 ++++++++++++++---------
> > >   1 file changed, 14 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> > > index 1ae34a2..4cc846f 100644
> > > --- a/tools/pygrub/src/pygrub
> > > +++ b/tools/pygrub/src/pygrub
> > > @@ -456,11 +456,9 @@ class Grub:
> > >           del f
> > >           self.cf.parse(buf)
> > >   
> > > -    def run(self):
> > > -        timeout = int(self.cf.timeout)
> > > -
> > > +    def image_index(self):
> > >           if self.cf.default.isdigit():
> > > -            self.selected_image = int(self.cf.default)
> > > +            sel = int(self.cf.default)
> > >           else:
> > >               # We don't fully support submenus. Look for the leaf value in
> > >               # "submenu0>submenu1>...>menuentry" and hope that it's unique.
> > > @@ -472,16 +470,23 @@ class Grub:
> > >                       break
> > >   
> > >               # Map string to index in images array
> > > -            self.selected_image = 0
> > > +            sel = 0
> > >               for i in range(len(self.cf.images)):
> > >                   if self.cf.images[i].title == title:
> > > -                    self.selected_image = i
> > > +                    sel = i
> > >                       break
> > >   
> > >           # If the selected (default) image doesn't exist we select the first entry
> > > -        if self.selected_image > len(self.cf.images):
> > > +        if sel > len(self.cf.images):
> > >               logging.warning("Default image not found")
> > > -            self.selected_image = 0
> > > +            sel = 0
> > > +
> > > +        return sel
> > > +
> > > +    def run(self):
> > > +        timeout = int(self.cf.timeout)
> > > +        self.selected_image = self.image_index()
> > > +
> > >           self.isdone = False
> > >           while not self.isdone:
> > >               self.run_main(timeout)
> > > @@ -626,7 +631,7 @@ def run_grub(file, entry, fs, cfg_args):
> > >       if interactive and not list_entries:
> > >           curses.wrapper(run_main)
> > >       else:
> > > -        sel = g.cf.default
> > > +        sel = g.image_index()
> > >   
> > >       # set the entry to boot as requested
> > >       if entry is not None:
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:36:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15: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 1Xlg9P-0005Zr-Dl; Tue, 04 Nov 2014 15:36:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>)
	id 1Xlg9N-0005ZU-Lc; Tue, 04 Nov 2014 15:36:05 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	88/8D-17958-462F8545; Tue, 04 Nov 2014 15:36:04 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415115363!7864933!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP,
  SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3527 invoked from network); 4 Nov 2014 15:36:03 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 15:36:03 -0000
Received: by mail-la0-f43.google.com with SMTP id ge10so1099660lab.2
	for <multiple recipients>; Tue, 04 Nov 2014 07:36:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:message-id:subject:from:to:content-type;
	bh=n45cXSWgdtzFYxLDh4C4XaRL3MVfcPP7vVZrs1lPlX8=;
	b=fCDfwGRK1bGGIlZw5DLVsQh4bAC9LNR6HIgwwo8TX/qu7PfXbmeeJjKGQhylzt2XiH
	P+8JfGoT5YOC5EeUY2Z86FasfHQBDpYt6vZIELnZh+0rynkseAwPd2YHc65ACzb2odu6
	ZE3LRG+P2gNeOJ5lNdGAhtW/414737zA4H3NiVwmAsxBS4h6bdExeYEgq5oEiVzLvc66
	QPO3z+8Bu1jx+5GxUg6sd7DtC6lAiTqAMHUyyHCslT4CXP67M5irzTYePmvhMcodOZZB
	Mlbbd9wXJxPS+9JjzID28un2pVkyr7St8CXvFA87rkdVoHiKEW0F+gx3T1mjT4K7oEX5
	2Dgw==
MIME-Version: 1.0
X-Received: by 10.112.85.138 with SMTP id h10mr60111244lbz.33.1415115361773;
	Tue, 04 Nov 2014 07:36:01 -0800 (PST)
Received: by 10.112.225.11 with HTTP; Tue, 4 Nov 2014 07:36:01 -0800 (PST)
Date: Tue, 4 Nov 2014 10:36:01 -0500
X-Google-Sender-Auth: 0caK8n50LsjsEv1bxffaWgKGvSA
Message-ID: <CAHehzX3s0WWUFGeLT4NmGL80A7xzJQTPvSUUq-ZOoWxSQh3Q2A@mail.gmail.com>
From: Russ Pavlicek <russell.pavlicek@xenproject.org>
To: xen-devel@lists.xen.org, 
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-api@lists.xen.org, 
	xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org
Subject: [Xen-devel] Reminder: Tomorrow's Theme is 'Integration' for Xen
 Project Document Day on November 5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Folks,

A reminder that Xen Project Document Day was moved to tomorrow,
November 5, due to the Test Day schedule.

We want to pay special attention to integration topics (e.g., libvirt,
OpenStack, CloudStack, virt-manager, etc.) as well as any changes
needed for the upcoming 4.5 release.

Everyone is encouraged to lend a hand as your schedule permits.  Details below.

Thanks!


---------- Forwarded message ----------
From: Russ Pavlicek <russell.pavlicek@xenproject.org>
Date: Mon, Oct 20, 2014 at 10:20 PM
Subject: Integration is the theme for Xen Project Document Day on October 29


In the era of clouds, integration is the key to success for
hypervisors.  This month, I am suggesting that we focus on integration
for our Xen Project Document Day.

We have new pages for OpenStack, CloudStack, OpenNebula, Ceph,
GlusterFS, Cloud Operating Systems (aka unikernels like MirageOS) on
our wiki.  What we lack is more information on how Xen Project
integrates with these and other projects.

Also, we need more info on using Xen Project with libvirt.  Many
clouds are built using the libvirt interface, yet we have very little
libvirt-specific information on our Wiki,  We need more particulars on
using Xen Project with a libvirt interface.

We'd welcome links to external information, as well as new content
explaining how Xen Project can work with these (and other) projects.

All the information you need to participate in Document Day is here:

http://wiki.xenproject.org/wiki/Xen_Document_Days

If you get a few moments before Wednesday, please take a look at the
current TODO list to see other items which need attention:

http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO

So please think about how you can help out.  If you haven't requested
to be made a Wiki editor, save time and do it now so you are ready to
go on Document Day.  Just fill out the form below:

http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html

We hope to see you Wednesday in #xendocs!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:36:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15: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 1Xlg9P-0005Zr-Dl; Tue, 04 Nov 2014 15:36:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>)
	id 1Xlg9N-0005ZU-Lc; Tue, 04 Nov 2014 15:36:05 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	88/8D-17958-462F8545; Tue, 04 Nov 2014 15:36:04 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415115363!7864933!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP,
  SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3527 invoked from network); 4 Nov 2014 15:36:03 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 15:36:03 -0000
Received: by mail-la0-f43.google.com with SMTP id ge10so1099660lab.2
	for <multiple recipients>; Tue, 04 Nov 2014 07:36:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:message-id:subject:from:to:content-type;
	bh=n45cXSWgdtzFYxLDh4C4XaRL3MVfcPP7vVZrs1lPlX8=;
	b=fCDfwGRK1bGGIlZw5DLVsQh4bAC9LNR6HIgwwo8TX/qu7PfXbmeeJjKGQhylzt2XiH
	P+8JfGoT5YOC5EeUY2Z86FasfHQBDpYt6vZIELnZh+0rynkseAwPd2YHc65ACzb2odu6
	ZE3LRG+P2gNeOJ5lNdGAhtW/414737zA4H3NiVwmAsxBS4h6bdExeYEgq5oEiVzLvc66
	QPO3z+8Bu1jx+5GxUg6sd7DtC6lAiTqAMHUyyHCslT4CXP67M5irzTYePmvhMcodOZZB
	Mlbbd9wXJxPS+9JjzID28un2pVkyr7St8CXvFA87rkdVoHiKEW0F+gx3T1mjT4K7oEX5
	2Dgw==
MIME-Version: 1.0
X-Received: by 10.112.85.138 with SMTP id h10mr60111244lbz.33.1415115361773;
	Tue, 04 Nov 2014 07:36:01 -0800 (PST)
Received: by 10.112.225.11 with HTTP; Tue, 4 Nov 2014 07:36:01 -0800 (PST)
Date: Tue, 4 Nov 2014 10:36:01 -0500
X-Google-Sender-Auth: 0caK8n50LsjsEv1bxffaWgKGvSA
Message-ID: <CAHehzX3s0WWUFGeLT4NmGL80A7xzJQTPvSUUq-ZOoWxSQh3Q2A@mail.gmail.com>
From: Russ Pavlicek <russell.pavlicek@xenproject.org>
To: xen-devel@lists.xen.org, 
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-api@lists.xen.org, 
	xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org
Subject: [Xen-devel] Reminder: Tomorrow's Theme is 'Integration' for Xen
 Project Document Day on November 5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Folks,

A reminder that Xen Project Document Day was moved to tomorrow,
November 5, due to the Test Day schedule.

We want to pay special attention to integration topics (e.g., libvirt,
OpenStack, CloudStack, virt-manager, etc.) as well as any changes
needed for the upcoming 4.5 release.

Everyone is encouraged to lend a hand as your schedule permits.  Details below.

Thanks!


---------- Forwarded message ----------
From: Russ Pavlicek <russell.pavlicek@xenproject.org>
Date: Mon, Oct 20, 2014 at 10:20 PM
Subject: Integration is the theme for Xen Project Document Day on October 29


In the era of clouds, integration is the key to success for
hypervisors.  This month, I am suggesting that we focus on integration
for our Xen Project Document Day.

We have new pages for OpenStack, CloudStack, OpenNebula, Ceph,
GlusterFS, Cloud Operating Systems (aka unikernels like MirageOS) on
our wiki.  What we lack is more information on how Xen Project
integrates with these and other projects.

Also, we need more info on using Xen Project with libvirt.  Many
clouds are built using the libvirt interface, yet we have very little
libvirt-specific information on our Wiki,  We need more particulars on
using Xen Project with a libvirt interface.

We'd welcome links to external information, as well as new content
explaining how Xen Project can work with these (and other) projects.

All the information you need to participate in Document Day is here:

http://wiki.xenproject.org/wiki/Xen_Document_Days

If you get a few moments before Wednesday, please take a look at the
current TODO list to see other items which need attention:

http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO

So please think about how you can help out.  If you haven't requested
to be made a Wiki editor, save time and do it now so you are ready to
go on Document Day.  Just fill out the form below:

http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html

We hope to see you Wednesday in #xendocs!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:45:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15:45:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlgHs-0006CE-04; Tue, 04 Nov 2014 15:44:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlgHr-0006C9-Ah
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:44:51 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	56/89-07724-274F8545; Tue, 04 Nov 2014 15:44:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415115888!11539640!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30318 invoked from network); 4 Nov 2014 15:44:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 15:44:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189337905"
Message-ID: <1415115868.11486.49.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Tue, 4 Nov 2014 15:44:28 +0000
In-Reply-To: <5458ED27.8060502@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
> I assume it may be warranted to "upgrade" this issue to a bug status 
> (obviously also in the hope that it attractes wider interest) by 
> prefixing the subject line with a [BUG] prefix as per 
> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project. I have 
> exhausted all my options (including numerous IRC attempts), provided all 
> the information I have been asked for but the issue persists and nobody 
> seems to have an idea how to rectify the problem.

Sorry for the delay, the issue is quite perplexing so I was intending to
sleep on it, but didn't get any inspiration in doing so...

In the gdb traces you provided there is:
#10 read_all (fd=10, data=data@entry=0x7ffff0000a10, len=len@entry=16, nonblocking=nonblocking@entry=0) at xs.c:374

which seems to correspond to the 
        if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
in read_message (because the size and offset seem matches this call, so
I think it is more likely than the other one, but the logic below
applies in either case).

The thing we are reading into has literally just been allocated, so I
can't think of any reason accessing it should fault.

There is only one xenstore change between 4.3.1 and 4.3.3 which is 
        commit 014f9219f1dca3ee92948f0cfcda8d1befa6cbcd
        Author: Matthew Daley <mattd@bugfuzz.com>
        Date:   Sat Nov 30 13:20:04 2013 +1300
        
            xenstore: sanity check incoming message body lengths
            
            This is for the client-side receiving messages from xenstored, so there
            is no security impact, unlike XSA-72.
        
but I can't see any way that could possibly cause a segfault.

So, I'm afraid I'm completely mystified.

You could try running the xl command under valgrind, you may find "xl
create -F" (which keeps xl in the foreground) handy if you try this.
That might help catch any heap corruption etc.

A related thing to try might be to run "MALLOC_CHECK_=2 xl create ..."
which enables glib's heap consistency checks (described at the end of
http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html) which might give a clue.

Otherwise I think the next step would be to downgrade to 4.3.1 and see
if the problem persists, in order to rule out changes elsewhere in the
system. If the problem doesn't happen with a 4.3.1 rebuilt on your
current system then the next thing would probably be to bisect the
issue. There are only 31 toolstack changes in that range, so it ought to
only take 5-6 iterations.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:45:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15:45:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlgHs-0006CE-04; Tue, 04 Nov 2014 15:44:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlgHr-0006C9-Ah
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:44:51 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	56/89-07724-274F8545; Tue, 04 Nov 2014 15:44:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415115888!11539640!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30318 invoked from network); 4 Nov 2014 15:44:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 15:44:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189337905"
Message-ID: <1415115868.11486.49.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Tue, 4 Nov 2014 15:44:28 +0000
In-Reply-To: <5458ED27.8060502@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
> I assume it may be warranted to "upgrade" this issue to a bug status 
> (obviously also in the hope that it attractes wider interest) by 
> prefixing the subject line with a [BUG] prefix as per 
> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project. I have 
> exhausted all my options (including numerous IRC attempts), provided all 
> the information I have been asked for but the issue persists and nobody 
> seems to have an idea how to rectify the problem.

Sorry for the delay, the issue is quite perplexing so I was intending to
sleep on it, but didn't get any inspiration in doing so...

In the gdb traces you provided there is:
#10 read_all (fd=10, data=data@entry=0x7ffff0000a10, len=len@entry=16, nonblocking=nonblocking@entry=0) at xs.c:374

which seems to correspond to the 
        if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
in read_message (because the size and offset seem matches this call, so
I think it is more likely than the other one, but the logic below
applies in either case).

The thing we are reading into has literally just been allocated, so I
can't think of any reason accessing it should fault.

There is only one xenstore change between 4.3.1 and 4.3.3 which is 
        commit 014f9219f1dca3ee92948f0cfcda8d1befa6cbcd
        Author: Matthew Daley <mattd@bugfuzz.com>
        Date:   Sat Nov 30 13:20:04 2013 +1300
        
            xenstore: sanity check incoming message body lengths
            
            This is for the client-side receiving messages from xenstored, so there
            is no security impact, unlike XSA-72.
        
but I can't see any way that could possibly cause a segfault.

So, I'm afraid I'm completely mystified.

You could try running the xl command under valgrind, you may find "xl
create -F" (which keeps xl in the foreground) handy if you try this.
That might help catch any heap corruption etc.

A related thing to try might be to run "MALLOC_CHECK_=2 xl create ..."
which enables glib's heap consistency checks (described at the end of
http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html) which might give a clue.

Otherwise I think the next step would be to downgrade to 4.3.1 and see
if the problem persists, in order to rule out changes elsewhere in the
system. If the problem doesn't happen with a 4.3.1 rebuilt on your
current system then the next thing would probably be to bisect the
issue. There are only 31 toolstack changes in that range, so it ought to
only take 5-6 iterations.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:48:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15:48:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlgLd-0006O7-Tr; Tue, 04 Nov 2014 15:48:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlgLc-0006O1-EJ
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:48:44 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F4/D7-01660-B55F8545; Tue, 04 Nov 2014 15:48:43 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415116123!11153790!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7524 invoked from network); 4 Nov 2014 15:48:43 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 15:48:43 -0000
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLG96841; Tue, 04 Nov 2014 15:48:37 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Tue, 4 Nov 2014 15:48:31 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [PATCH v2 7/7] xen/arm: Move vGIC registers on Hip04 platform
Thread-Index: AQHP94XhB6oL3dDu/UqzmHk5UboxZ5xQeh2AgAAOUpCAAAXCgIAAEAKw
Date: Tue, 4 Nov 2014 15:48:30 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B1D0@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
	<5458D6C5.7010307@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B18B@lhreml509-mbb>
	<1415112605.11486.45.camel@citrix.com>
In-Reply-To: <1415112605.11486.45.camel@citrix.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 7/7] xen/arm: Move vGIC registers on
	Hip04 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, 2014-11-04 at 14:42 +0000, Frediano Ziglio wrote:
> > >
> > > Hi Frediano,
> > >
> > > On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > > > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > > > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > > > ---
> > > >  xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
> > > >  xen/include/asm-arm/gic.h |  2 ++
> > > >  2 files changed, 15 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > > > cea9edc..eb8cc19 100644
> > > > --- a/xen/arch/arm/gic-v2.c
> > > > +++ b/xen/arch/arm/gic-v2.c
> > > > @@ -669,8 +669,19 @@ static int gicv2_make_dt_node(const struct
> > > domain *d,
> > > >          return -FDT_ERR_XEN(ENOMEM);
> > > >
> > > >      tmp = new_cells;
> > > > -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > > > -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > > > +
> > > > +    if ( nr_gic_cpu_if == 16 )
> > > > +    {
> > > > +        dt_set_range(&tmp, node, d->arch.vgic.dbase -
> > > HIP04_VGIC_REG_OFFSET,
> > > > +                     PAGE_SIZE);
> > > > +        dt_set_range(&tmp, node, d->arch.vgic.cbase -
> > > HIP04_VGIC_REG_OFFSET,
> > > > +                     PAGE_SIZE * 2);
> > > > +    }
> > > > +    else
> > > > +    {
> > > > +        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > > > +        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE *
> 2);
> > > > +    }
> > > >
> > > >      res = fdt_property(fdt, "reg", new_cells, len);
> > > >      xfree(new_cells);
> > > > diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-
> arm/gic.h
> > > > index 3d2b3db..5af8201 100644
> > > > --- a/xen/include/asm-arm/gic.h
> > > > +++ b/xen/include/asm-arm/gic.h
> > > > @@ -147,6 +147,8 @@
> > > >  #define GICH_LR_PENDING         1
> > > >  #define GICH_LR_ACTIVE          2
> > > >
> > > > +#define HIP04_VGIC_REG_OFFSET   0xe0000000
> > > > +
> > >
> > > Please move this define in gic-v2.c. The header gic.h should only
> > > contains value that needs to be shared with the vgic and/or the
> > > other GIC drivers.
> > >
> > > Also, where does come from the offset? Any pointer to the
> documentation?
> > >
> >
> > Well,
> >   I think I already sent a mail for this problem but got no reply (or
> I missed it).
> >
> > The problem came from how the DTB is in Linux and how Xen override
> devices in the DTB.
> >
> > On Linux I have
> >
> > / {
> > ...
> >        soc {
> >                 /* It's a 32-bit SoC. */
> >                 #address-cells = <1>;
> >                 #size-cells = <1>;
> >                 compatible = "simple-bus";
> >                 interrupt-parent = <&gic>;
> >                 ranges = <0 0 0xe0000000 0x10000000>;
> >
> >                 gic: interrupt-controller@c01000 {
> >                         compatible = "hisilicon,hip04-intc";
> >                         #interrupt-cells = <3>;
> >                         #address-cells = <0>;
> >                         interrupt-controller;
> >                         interrupts = <1 9 0xf04>;
> >
> >                         reg = <0xc01000 0x1000>, <0xc02000 0x1000>,
> >                               <0xc04000 0x2000>, <0xc06000 0x2000>;
> >                 };
> > ...
> >
> > So the address of controller is 0xec01000 (see ranges in /soc and reg
> in /soc/interrupt-controller@c01000).
> >
> > Now Xen compute address as 0xec01000 (which is fine) but then when it
> has to provide a virtual gic it just replace the gic entry with one
> with reg with 0xec01000 not taking into account the range is putting
> the reg into. This lead kernel to think the address is
> 0xe0000000+0xec01000 instead of 0xe00000000+0xc01000. Now... the DTB
> from Linux is perfectly legal but Xen does not handle it properly. I
> mostly consider this as a temporary workaround (I wrote a small comment
> on first version).
> >
> > About solution to this there are different options:
> > - put gic always in the root to to have full range without any offset;
> > - fix reg according to range. This however could lead to extend the
> > range;
> > - remove all ranges (and fix all devices' reg) to have always no
> offsets.
> 
>   - Propagate the host GICC register value literally over, having
>     mapping the GICV there. i.e. don't translate the value which is
>     written to the DT.
> 
> None of the other options sound very good to me.
> 
> Ian.

Yes,
  You are right, KISS rule apply!

Implemented and working correctly.

Regards,
  Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:48:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15:48:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlgLd-0006O7-Tr; Tue, 04 Nov 2014 15:48:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlgLc-0006O1-EJ
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:48:44 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F4/D7-01660-B55F8545; Tue, 04 Nov 2014 15:48:43 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415116123!11153790!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7524 invoked from network); 4 Nov 2014 15:48:43 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 15:48:43 -0000
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLG96841; Tue, 04 Nov 2014 15:48:37 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Tue, 4 Nov 2014 15:48:31 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [PATCH v2 7/7] xen/arm: Move vGIC registers on Hip04 platform
Thread-Index: AQHP94XhB6oL3dDu/UqzmHk5UboxZ5xQeh2AgAAOUpCAAAXCgIAAEAKw
Date: Tue, 4 Nov 2014 15:48:30 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B1D0@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-8-git-send-email-frediano.ziglio@huawei.com>
	<5458D6C5.7010307@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B18B@lhreml509-mbb>
	<1415112605.11486.45.camel@citrix.com>
In-Reply-To: <1415112605.11486.45.camel@citrix.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 7/7] xen/arm: Move vGIC registers on
	Hip04 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, 2014-11-04 at 14:42 +0000, Frediano Ziglio wrote:
> > >
> > > Hi Frediano,
> > >
> > > On 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > > > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > > > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > > > ---
> > > >  xen/arch/arm/gic-v2.c     | 15 +++++++++++++--
> > > >  xen/include/asm-arm/gic.h |  2 ++
> > > >  2 files changed, 15 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > > > cea9edc..eb8cc19 100644
> > > > --- a/xen/arch/arm/gic-v2.c
> > > > +++ b/xen/arch/arm/gic-v2.c
> > > > @@ -669,8 +669,19 @@ static int gicv2_make_dt_node(const struct
> > > domain *d,
> > > >          return -FDT_ERR_XEN(ENOMEM);
> > > >
> > > >      tmp = new_cells;
> > > > -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > > > -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > > > +
> > > > +    if ( nr_gic_cpu_if == 16 )
> > > > +    {
> > > > +        dt_set_range(&tmp, node, d->arch.vgic.dbase -
> > > HIP04_VGIC_REG_OFFSET,
> > > > +                     PAGE_SIZE);
> > > > +        dt_set_range(&tmp, node, d->arch.vgic.cbase -
> > > HIP04_VGIC_REG_OFFSET,
> > > > +                     PAGE_SIZE * 2);
> > > > +    }
> > > > +    else
> > > > +    {
> > > > +        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > > > +        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE *
> 2);
> > > > +    }
> > > >
> > > >      res = fdt_property(fdt, "reg", new_cells, len);
> > > >      xfree(new_cells);
> > > > diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-
> arm/gic.h
> > > > index 3d2b3db..5af8201 100644
> > > > --- a/xen/include/asm-arm/gic.h
> > > > +++ b/xen/include/asm-arm/gic.h
> > > > @@ -147,6 +147,8 @@
> > > >  #define GICH_LR_PENDING         1
> > > >  #define GICH_LR_ACTIVE          2
> > > >
> > > > +#define HIP04_VGIC_REG_OFFSET   0xe0000000
> > > > +
> > >
> > > Please move this define in gic-v2.c. The header gic.h should only
> > > contains value that needs to be shared with the vgic and/or the
> > > other GIC drivers.
> > >
> > > Also, where does come from the offset? Any pointer to the
> documentation?
> > >
> >
> > Well,
> >   I think I already sent a mail for this problem but got no reply (or
> I missed it).
> >
> > The problem came from how the DTB is in Linux and how Xen override
> devices in the DTB.
> >
> > On Linux I have
> >
> > / {
> > ...
> >        soc {
> >                 /* It's a 32-bit SoC. */
> >                 #address-cells = <1>;
> >                 #size-cells = <1>;
> >                 compatible = "simple-bus";
> >                 interrupt-parent = <&gic>;
> >                 ranges = <0 0 0xe0000000 0x10000000>;
> >
> >                 gic: interrupt-controller@c01000 {
> >                         compatible = "hisilicon,hip04-intc";
> >                         #interrupt-cells = <3>;
> >                         #address-cells = <0>;
> >                         interrupt-controller;
> >                         interrupts = <1 9 0xf04>;
> >
> >                         reg = <0xc01000 0x1000>, <0xc02000 0x1000>,
> >                               <0xc04000 0x2000>, <0xc06000 0x2000>;
> >                 };
> > ...
> >
> > So the address of controller is 0xec01000 (see ranges in /soc and reg
> in /soc/interrupt-controller@c01000).
> >
> > Now Xen compute address as 0xec01000 (which is fine) but then when it
> has to provide a virtual gic it just replace the gic entry with one
> with reg with 0xec01000 not taking into account the range is putting
> the reg into. This lead kernel to think the address is
> 0xe0000000+0xec01000 instead of 0xe00000000+0xc01000. Now... the DTB
> from Linux is perfectly legal but Xen does not handle it properly. I
> mostly consider this as a temporary workaround (I wrote a small comment
> on first version).
> >
> > About solution to this there are different options:
> > - put gic always in the root to to have full range without any offset;
> > - fix reg according to range. This however could lead to extend the
> > range;
> > - remove all ranges (and fix all devices' reg) to have always no
> offsets.
> 
>   - Propagate the host GICC register value literally over, having
>     mapping the GICV there. i.e. don't translate the value which is
>     written to the DT.
> 
> None of the other options sound very good to me.
> 
> Ian.

Yes,
  You are right, KISS rule apply!

Implemented and working correctly.

Regards,
  Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:55:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15: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 1XlgRf-0006lJ-O7; Tue, 04 Nov 2014 15:54:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlgRd-0006lE-Gq
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:54:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	73/AF-09842-0D6F8545; Tue, 04 Nov 2014 15:54:56 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415116496!12713107!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13516 invoked from network); 4 Nov 2014 15:54:56 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 15:54:56 -0000
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BOK29399; Tue, 04 Nov 2014 15:54:49 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Tue, 4 Nov 2014 15:54:15 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 3/7] xen/arm: Make gic-v2 code handle hip04-d01
	platform
Thread-Index: AQHP94XbD/Eaci3JVE65/8tgo0Zpr5xQeF+AgAAm9GA=
Date: Tue, 4 Nov 2014 15:54:14 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B1DD@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
	<5458D54F.10007@linaro.org>
In-Reply-To: <5458D54F.10007@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 3/7] xen/arm: Make gic-v2 code handle
 hip04-d01 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 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > The GIC in this platform is mainly compatible with the standard
> > GICv2 beside:
> > - ITARGET is extended to 16 bit to support 16 CPUs;
> > - SGI mask is extended to support 16 CPUs;
> > - maximum supported interrupt is 510.
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > ---
> >  xen/arch/arm/gic-v2.c     | 89
> +++++++++++++++++++++++++++++++++++++++--------
> >  xen/arch/arm/gic.c        |  3 +-
> >  xen/include/asm-arm/gic.h |  4 ++-
> >  3 files changed, 80 insertions(+), 16 deletions(-)
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > faad1ff..9461fe3 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -79,16 +79,23 @@ static struct gic_info gicv2_info;
> >   * logical CPU numbering. Let's use mapping as returned by the GIC
> >   * itself
> >   */
> > -static DEFINE_PER_CPU(u8, gic_cpu_id);
> > +static DEFINE_PER_CPU(u16, gic_cpu_id);
> >
> >  /* Maximum cpu interface per GIC */
> > -#define NR_GIC_CPU_IF 8
> > +static unsigned int nr_gic_cpu_if = 8; static unsigned int
> > +gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT; static unsigned int
> > +gic_cpu_mask = 0xff;
> >
> >  static inline void writeb_gicd(uint8_t val, unsigned int offset)  {
> >      writeb_relaxed(val, gicv2.map_dbase + offset);  }
> >
> > +static inline void writew_gicd(uint16_t val, unsigned int offset) {
> > +    writew_relaxed(val, gicv2.map_dbase + offset); }
> > +
> >  static inline void writel_gicd(uint32_t val, unsigned int offset)  {
> >      writel_relaxed(val, gicv2.map_dbase + offset); @@ -132,7 +139,7
> > @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
> >      cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
> >      for_each_cpu( cpu, &possible_mask )
> >      {
> > -        ASSERT(cpu < NR_GIC_CPU_IF);
> > +        ASSERT(cpu < nr_gic_cpu_if);
> >          mask |= per_cpu(gic_cpu_id, cpu);
> >      }
> >
> > @@ -203,6 +210,15 @@ static unsigned int gicv2_read_irq(void)
> >      return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);  }
> >
> > +/* Set target CPU mask (RAZ/WI on uniprocessor) */ static void
> > +gicv2_set_irq_mask(int irq, unsigned int mask) {
> > +    if ( nr_gic_cpu_if == 16 )
> 
> This check is very confusing, and even more in patch #5.
> 
> Code executed under this check describes your platform and not a
> generic 16-CPU support (actually there is no spec for it).
> 
> I would introduce a new boolean or hide this check in a macro.
> 

In some cases is not so terrible, as it's the only 16-bit implementation and as it's assuming ITARGETSR is 16 bit instead of 8. In other cases (like the compatible cases) I fully agree.

I agree a macro should be enough. Something like is_hip04() sounds ok?

> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index
> > 70d10d6..8050a65 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs,
> > enum gic_sgi sgi)  void gic_interrupt(struct cpu_user_regs *regs, int
> > is_fiq)  {
> >      unsigned int irq;
> > +    unsigned int max_irq = gic_hw_ops->info->nr_lines;
> >
> >      do  {
> >          /* Reading IRQ will ACK it */
> >          irq = gic_hw_ops->read_irq();
> >
> > -        if ( likely(irq >= 16 && irq < 1021) )
> > +        if ( likely(irq >= 16 && irq < max_irq) )
> 
> On the previous version I've asked that need to explain in the commit
> message why this change is valid.
> 

Regards,
  Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:55:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15: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 1XlgRf-0006lJ-O7; Tue, 04 Nov 2014 15:54:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XlgRd-0006lE-Gq
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:54:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	73/AF-09842-0D6F8545; Tue, 04 Nov 2014 15:54:56 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415116496!12713107!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13516 invoked from network); 4 Nov 2014 15:54:56 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 15:54:56 -0000
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BOK29399; Tue, 04 Nov 2014 15:54:49 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Tue, 4 Nov 2014 15:54:15 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v2 3/7] xen/arm: Make gic-v2 code handle hip04-d01
	platform
Thread-Index: AQHP94XbD/Eaci3JVE65/8tgo0Zpr5xQeF+AgAAm9GA=
Date: Tue, 4 Nov 2014 15:54:14 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B1DD@lhreml509-mbb>
References: <1415033196-30529-1-git-send-email-frediano.ziglio@huawei.com>
	<1415033196-30529-4-git-send-email-frediano.ziglio@huawei.com>
	<5458D54F.10007@linaro.org>
In-Reply-To: <5458D54F.10007@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.23]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 3/7] xen/arm: Make gic-v2 code handle
 hip04-d01 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 11/03/2014 04:46 PM, Frediano Ziglio wrote:
> > The GIC in this platform is mainly compatible with the standard
> > GICv2 beside:
> > - ITARGET is extended to 16 bit to support 16 CPUs;
> > - SGI mask is extended to support 16 CPUs;
> > - maximum supported interrupt is 510.
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > ---
> >  xen/arch/arm/gic-v2.c     | 89
> +++++++++++++++++++++++++++++++++++++++--------
> >  xen/arch/arm/gic.c        |  3 +-
> >  xen/include/asm-arm/gic.h |  4 ++-
> >  3 files changed, 80 insertions(+), 16 deletions(-)
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > faad1ff..9461fe3 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -79,16 +79,23 @@ static struct gic_info gicv2_info;
> >   * logical CPU numbering. Let's use mapping as returned by the GIC
> >   * itself
> >   */
> > -static DEFINE_PER_CPU(u8, gic_cpu_id);
> > +static DEFINE_PER_CPU(u16, gic_cpu_id);
> >
> >  /* Maximum cpu interface per GIC */
> > -#define NR_GIC_CPU_IF 8
> > +static unsigned int nr_gic_cpu_if = 8; static unsigned int
> > +gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT; static unsigned int
> > +gic_cpu_mask = 0xff;
> >
> >  static inline void writeb_gicd(uint8_t val, unsigned int offset)  {
> >      writeb_relaxed(val, gicv2.map_dbase + offset);  }
> >
> > +static inline void writew_gicd(uint16_t val, unsigned int offset) {
> > +    writew_relaxed(val, gicv2.map_dbase + offset); }
> > +
> >  static inline void writel_gicd(uint32_t val, unsigned int offset)  {
> >      writel_relaxed(val, gicv2.map_dbase + offset); @@ -132,7 +139,7
> > @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
> >      cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
> >      for_each_cpu( cpu, &possible_mask )
> >      {
> > -        ASSERT(cpu < NR_GIC_CPU_IF);
> > +        ASSERT(cpu < nr_gic_cpu_if);
> >          mask |= per_cpu(gic_cpu_id, cpu);
> >      }
> >
> > @@ -203,6 +210,15 @@ static unsigned int gicv2_read_irq(void)
> >      return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);  }
> >
> > +/* Set target CPU mask (RAZ/WI on uniprocessor) */ static void
> > +gicv2_set_irq_mask(int irq, unsigned int mask) {
> > +    if ( nr_gic_cpu_if == 16 )
> 
> This check is very confusing, and even more in patch #5.
> 
> Code executed under this check describes your platform and not a
> generic 16-CPU support (actually there is no spec for it).
> 
> I would introduce a new boolean or hide this check in a macro.
> 

In some cases is not so terrible, as it's the only 16-bit implementation and as it's assuming ITARGETSR is 16 bit instead of 8. In other cases (like the compatible cases) I fully agree.

I agree a macro should be enough. Something like is_hip04() sounds ok?

> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index
> > 70d10d6..8050a65 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs,
> > enum gic_sgi sgi)  void gic_interrupt(struct cpu_user_regs *regs, int
> > is_fiq)  {
> >      unsigned int irq;
> > +    unsigned int max_irq = gic_hw_ops->info->nr_lines;
> >
> >      do  {
> >          /* Reading IRQ will ACK it */
> >          irq = gic_hw_ops->read_irq();
> >
> > -        if ( likely(irq >= 16 && irq < 1021) )
> > +        if ( likely(irq >= 16 && irq < max_irq) )
> 
> On the previous version I've asked that need to explain in the commit
> message why this change is valid.
> 

Regards,
  Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 15:55:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlgS8-0006nX-KD; Tue, 04 Nov 2014 15:55:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1XlgS7-0006nO-7l
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:55:27 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	4E/82-27785-EE6F8545; Tue, 04 Nov 2014 15:55:26 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415116523!12518657!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 691 invoked from network); 4 Nov 2014 15:55:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 15:55:25 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA4FtMwC028882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 4 Nov 2014 10:55:22 -0500
Received: from [10.3.113.108] (ovpn-113-108.phx2.redhat.com [10.3.113.108])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sA4FtKV8010655; Tue, 4 Nov 2014 10:55:21 -0500
Message-ID: <5458F6E7.5000606@redhat.com>
Date: Tue, 04 Nov 2014 16:55:19 +0100
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Quan Xu <quan.xu@intel.com>, qemu-devel@nongnu.org
References: <1414910361-27681-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1414910361-27681-1-git-send-email-quan.xu@intel.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: xen-devel@lists.xen.org, armbru@redhat.com, lcapitulino@redhat.com
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5469497994172704756=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============5469497994172704756==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="MVuv9BKUnnuIFLAvliCeKhEpa2hCC4gf1"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--MVuv9BKUnnuIFLAvliCeKhEpa2hCC4gf1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/02/2014 07:39 AM, Quan Xu wrote:

[meta-comment] This message appears to have a cover letter; but you
failed to properly set the 'In-Reply-To' header; when each patch of your
series appears as a top-level thread instead of a reply to the cover
letter, it is harder to review.

> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  configure        | 14 ++++++++++++++
>  hmp.c            |  7 +++++++
>  qapi-schema.json | 17 +++++++++++++++--
>  qemu-options.hx  | 13 +++++++++++--
>  tpm.c            |  7 ++++++-
>  5 files changed, 53 insertions(+), 5 deletions(-)
>=20

> +++ b/qapi-schema.json
> @@ -2853,10 +2853,11 @@
>  # An enumeration of TPM types
>  #
>  # @passthrough: TPM passthrough type
> +# @xenstubdoms: TPM xenstubdoms type

Missing a '(since 2.3)' designation.

>  #
>  # Since: 1.5
>  ##
> -{ 'enum': 'TpmType', 'data': [ 'passthrough' ] }
> +{ 'enum': 'TpmType', 'data': [ 'passthrough', 'xenstubdoms' ] }
> =20
>  ##
>  # @query-tpm-types:
> @@ -2884,6 +2885,16 @@
>  { 'type': 'TPMPassthroughOptions', 'data': { '*path' : 'str',
>                                               '*cancel-path' : 'str'} }=

> =20
> +# @TPMXenstubdomsOptions:
> +#
> +# Information about the TPM xenstubdoms type
> +#
> +# Since: > 2.1.0

2.1 is wrong; the earliest you can get this into the tree is 2.3
(because you've missed soft freeze for 2.2).

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--MVuv9BKUnnuIFLAvliCeKhEpa2hCC4gf1
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
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg

iQEcBAEBCAAGBQJUWPboAAoJEKeha0olJ0NqCdEIAINFasvoIVIK/sRHEQ2ge4Gd
0TwL5xwppyPrLQ1lXUMzHCvRxdfRlmBQCxM1KE0YffSnT0WXVUDI5jcdztoDDbj5
USQyyOnOylmpuw0bvTejV9e+50Wu6cwhO4I6AFvZXoE+aLmXcHeiDmCQdmsj7syh
rPhvxo2/lMoPUPaiW8BBk0Atn+BLz50q+uEFvJp5f38butyBTR8wi3lF8FxowbgT
0nTEFDThvlLm0F92FgjA9rqGxOpH1/8ndfuMkDeRko6Xo5FiMYi0yTAM2Mct0tmo
2GIcMQGZguEOYluySVi8QAPxovVflRp1rj5BSA2j/bw9HduJPLWoHKxWKM5B7aI=
=pdcr
-----END PGP SIGNATURE-----

--MVuv9BKUnnuIFLAvliCeKhEpa2hCC4gf1--


--===============5469497994172704756==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5469497994172704756==--


From xen-devel-bounces@lists.xen.org Tue Nov 04 15:55:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 15:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlgS8-0006nX-KD; Tue, 04 Nov 2014 15:55:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1XlgS7-0006nO-7l
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 15:55:27 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	4E/82-27785-EE6F8545; Tue, 04 Nov 2014 15:55:26 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415116523!12518657!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 691 invoked from network); 4 Nov 2014 15:55:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 15:55:25 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA4FtMwC028882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 4 Nov 2014 10:55:22 -0500
Received: from [10.3.113.108] (ovpn-113-108.phx2.redhat.com [10.3.113.108])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sA4FtKV8010655; Tue, 4 Nov 2014 10:55:21 -0500
Message-ID: <5458F6E7.5000606@redhat.com>
Date: Tue, 04 Nov 2014 16:55:19 +0100
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Quan Xu <quan.xu@intel.com>, qemu-devel@nongnu.org
References: <1414910361-27681-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1414910361-27681-1-git-send-email-quan.xu@intel.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: xen-devel@lists.xen.org, armbru@redhat.com, lcapitulino@redhat.com
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5469497994172704756=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============5469497994172704756==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="MVuv9BKUnnuIFLAvliCeKhEpa2hCC4gf1"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--MVuv9BKUnnuIFLAvliCeKhEpa2hCC4gf1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/02/2014 07:39 AM, Quan Xu wrote:

[meta-comment] This message appears to have a cover letter; but you
failed to properly set the 'In-Reply-To' header; when each patch of your
series appears as a top-level thread instead of a reply to the cover
letter, it is harder to review.

> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  configure        | 14 ++++++++++++++
>  hmp.c            |  7 +++++++
>  qapi-schema.json | 17 +++++++++++++++--
>  qemu-options.hx  | 13 +++++++++++--
>  tpm.c            |  7 ++++++-
>  5 files changed, 53 insertions(+), 5 deletions(-)
>=20

> +++ b/qapi-schema.json
> @@ -2853,10 +2853,11 @@
>  # An enumeration of TPM types
>  #
>  # @passthrough: TPM passthrough type
> +# @xenstubdoms: TPM xenstubdoms type

Missing a '(since 2.3)' designation.

>  #
>  # Since: 1.5
>  ##
> -{ 'enum': 'TpmType', 'data': [ 'passthrough' ] }
> +{ 'enum': 'TpmType', 'data': [ 'passthrough', 'xenstubdoms' ] }
> =20
>  ##
>  # @query-tpm-types:
> @@ -2884,6 +2885,16 @@
>  { 'type': 'TPMPassthroughOptions', 'data': { '*path' : 'str',
>                                               '*cancel-path' : 'str'} }=

> =20
> +# @TPMXenstubdomsOptions:
> +#
> +# Information about the TPM xenstubdoms type
> +#
> +# Since: > 2.1.0

2.1 is wrong; the earliest you can get this into the tree is 2.3
(because you've missed soft freeze for 2.2).

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--MVuv9BKUnnuIFLAvliCeKhEpa2hCC4gf1
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
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg

iQEcBAEBCAAGBQJUWPboAAoJEKeha0olJ0NqCdEIAINFasvoIVIK/sRHEQ2ge4Gd
0TwL5xwppyPrLQ1lXUMzHCvRxdfRlmBQCxM1KE0YffSnT0WXVUDI5jcdztoDDbj5
USQyyOnOylmpuw0bvTejV9e+50Wu6cwhO4I6AFvZXoE+aLmXcHeiDmCQdmsj7syh
rPhvxo2/lMoPUPaiW8BBk0Atn+BLz50q+uEFvJp5f38butyBTR8wi3lF8FxowbgT
0nTEFDThvlLm0F92FgjA9rqGxOpH1/8ndfuMkDeRko6Xo5FiMYi0yTAM2Mct0tmo
2GIcMQGZguEOYluySVi8QAPxovVflRp1rj5BSA2j/bw9HduJPLWoHKxWKM5B7aI=
=pdcr
-----END PGP SIGNATURE-----

--MVuv9BKUnnuIFLAvliCeKhEpa2hCC4gf1--


--===============5469497994172704756==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5469497994172704756==--


From xen-devel-bounces@lists.xen.org Tue Nov 04 16:14:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlgk8-0007sh-G6; Tue, 04 Nov 2014 16:14:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1Xlgk7-0007sc-KD
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:14:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AF/CF-24532-A4BF8545; Tue, 04 Nov 2014 16:14:02 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415117642!12718550!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1026 invoked from network); 4 Nov 2014 16:14:02 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 16:14:02 -0000
Received: from jarvis.univie.ac.at ([131.130.3.112] helo=jarvis.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1Xlgk4-0007HN-JZ; Tue, 04 Nov 2014 17:14:00 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.64])
	by jarvis.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1Xlgk4-0007AE-7u; Tue, 04 Nov 2014 17:14:00 +0100
Message-ID: <5458FB49.4040801@web2web.at>
Date: Tue, 04 Nov 2014 17:14:01 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>			<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>		<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>	
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com>
In-Reply-To: <1415115868.11486.49.camel@citrix.com>
X-Univie-Virus-Scan: scanned by ClamAV on jarvis.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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

Am 04.11.14 um 16:44 schrieb Ian Campbell:
> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
>> I assume it may be warranted to "upgrade" this issue to a bug status
>> (obviously also in the hope that it attractes wider interest) by
>> prefixing the subject line with a [BUG] prefix as per
>> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project. I have
>> exhausted all my options (including numerous IRC attempts), provided all
>> the information I have been asked for but the issue persists and nobody
>> seems to have an idea how to rectify the problem.
>
> Sorry for the delay, the issue is quite perplexing so I was intending to
> sleep on it, but didn't get any inspiration in doing so...
Thanks for getting back ... obviously sometimes sleep is not the right cure.
>
> In the gdb traces you provided there is:
> #10 read_all (fd=10, data=data@entry=0x7ffff0000a10, len=len@entry=16, nonblocking=nonblocking@entry=0) at xs.c:374
>
Just to be on the same page: That was for the destroy case. The 
corresponding line for the create case was:
#10 read_all (fd=18, data=data@entry=0x7fffe80008d0, len=len@entry=16, 
nonblocking=nonblocking@entry=0) at xs.c:374

I don't know whether that makes any difference though.
> which seems to correspond to the
>          if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
I did have a look at the file xs.c as well in the source and there are 3 
source code files named xs.c:
	tools/xenstore/xs.c
	tools/python/xen/lowlevel/xs/xs.c
	extras/mini-os/lib/xs.c
Out of these only the first two do have at least 374 lines and only the 
first one has a non empty source code line at line 374. That line 
however reads as follows in my source:
	done = read(fd, data, len)
and is located in function
	static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
starting at line 361

The line you referr to is located at line 1139 in the same file. I just 
wanted to bring this to your attention, but I might be on the wrong 
track here ...

> in read_message (because the size and offset seem matches this call, so
> I think it is more likely than the other one, but the logic below
> applies in either case).
>
> The thing we are reading into has literally just been allocated, so I
> can't think of any reason accessing it should fault.
>
> There is only one xenstore change between 4.3.1 and 4.3.3 which is
>          commit 014f9219f1dca3ee92948f0cfcda8d1befa6cbcd
>          Author: Matthew Daley <mattd@bugfuzz.com>
>          Date:   Sat Nov 30 13:20:04 2013 +1300
>
>              xenstore: sanity check incoming message body lengths
>
>              This is for the client-side receiving messages from xenstored, so there
>              is no security impact, unlike XSA-72.
>
> but I can't see any way that could possibly cause a segfault.
>
> So, I'm afraid I'm completely mystified.
>
> You could try running the xl command under valgrind, you may find "xl
> create -F" (which keeps xl in the foreground) handy if you try this.
> That might help catch any heap corruption etc.
I don't know what valgrind is, but I'll have a look and see how to deal 
with that ...
>
> A related thing to try might be to run "MALLOC_CHECK_=2 xl create ..."
> which enables glib's heap consistency checks (described at the end of
> http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html) which might give a clue.
I tried that, but the same segfault and no more messages on the screen - 
or should I have run this under gdb as well?
>
> Otherwise I think the next step would be to downgrade to 4.3.1 and see
> if the problem persists, in order to rule out changes elsewhere in the
> system. If the problem doesn't happen with a 4.3.1 rebuilt on your
> current system then the next thing would probably be to bisect the
> issue. There are only 31 toolstack changes in that range, so it ought to
> only take 5-6 iterations.
Unfortunately 4.3.1 is no longer available as an ebuild as 4.3.3 seemed 
to fix security issues and therefore 4.3.1 has been deleted from the 
repos. So it's not straightforward and I need to figure out how to get 
the old version back. But I am sure there's a way.

Thanks Atom2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:14:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlgk8-0007sh-G6; Tue, 04 Nov 2014 16:14:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1Xlgk7-0007sc-KD
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:14:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AF/CF-24532-A4BF8545; Tue, 04 Nov 2014 16:14:02 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415117642!12718550!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1026 invoked from network); 4 Nov 2014 16:14:02 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 16:14:02 -0000
Received: from jarvis.univie.ac.at ([131.130.3.112] helo=jarvis.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1Xlgk4-0007HN-JZ; Tue, 04 Nov 2014 17:14:00 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.64])
	by jarvis.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1Xlgk4-0007AE-7u; Tue, 04 Nov 2014 17:14:00 +0100
Message-ID: <5458FB49.4040801@web2web.at>
Date: Tue, 04 Nov 2014 17:14:01 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>			<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>		<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>	
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com>
In-Reply-To: <1415115868.11486.49.camel@citrix.com>
X-Univie-Virus-Scan: scanned by ClamAV on jarvis.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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

Am 04.11.14 um 16:44 schrieb Ian Campbell:
> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
>> I assume it may be warranted to "upgrade" this issue to a bug status
>> (obviously also in the hope that it attractes wider interest) by
>> prefixing the subject line with a [BUG] prefix as per
>> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project. I have
>> exhausted all my options (including numerous IRC attempts), provided all
>> the information I have been asked for but the issue persists and nobody
>> seems to have an idea how to rectify the problem.
>
> Sorry for the delay, the issue is quite perplexing so I was intending to
> sleep on it, but didn't get any inspiration in doing so...
Thanks for getting back ... obviously sometimes sleep is not the right cure.
>
> In the gdb traces you provided there is:
> #10 read_all (fd=10, data=data@entry=0x7ffff0000a10, len=len@entry=16, nonblocking=nonblocking@entry=0) at xs.c:374
>
Just to be on the same page: That was for the destroy case. The 
corresponding line for the create case was:
#10 read_all (fd=18, data=data@entry=0x7fffe80008d0, len=len@entry=16, 
nonblocking=nonblocking@entry=0) at xs.c:374

I don't know whether that makes any difference though.
> which seems to correspond to the
>          if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
I did have a look at the file xs.c as well in the source and there are 3 
source code files named xs.c:
	tools/xenstore/xs.c
	tools/python/xen/lowlevel/xs/xs.c
	extras/mini-os/lib/xs.c
Out of these only the first two do have at least 374 lines and only the 
first one has a non empty source code line at line 374. That line 
however reads as follows in my source:
	done = read(fd, data, len)
and is located in function
	static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
starting at line 361

The line you referr to is located at line 1139 in the same file. I just 
wanted to bring this to your attention, but I might be on the wrong 
track here ...

> in read_message (because the size and offset seem matches this call, so
> I think it is more likely than the other one, but the logic below
> applies in either case).
>
> The thing we are reading into has literally just been allocated, so I
> can't think of any reason accessing it should fault.
>
> There is only one xenstore change between 4.3.1 and 4.3.3 which is
>          commit 014f9219f1dca3ee92948f0cfcda8d1befa6cbcd
>          Author: Matthew Daley <mattd@bugfuzz.com>
>          Date:   Sat Nov 30 13:20:04 2013 +1300
>
>              xenstore: sanity check incoming message body lengths
>
>              This is for the client-side receiving messages from xenstored, so there
>              is no security impact, unlike XSA-72.
>
> but I can't see any way that could possibly cause a segfault.
>
> So, I'm afraid I'm completely mystified.
>
> You could try running the xl command under valgrind, you may find "xl
> create -F" (which keeps xl in the foreground) handy if you try this.
> That might help catch any heap corruption etc.
I don't know what valgrind is, but I'll have a look and see how to deal 
with that ...
>
> A related thing to try might be to run "MALLOC_CHECK_=2 xl create ..."
> which enables glib's heap consistency checks (described at the end of
> http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html) which might give a clue.
I tried that, but the same segfault and no more messages on the screen - 
or should I have run this under gdb as well?
>
> Otherwise I think the next step would be to downgrade to 4.3.1 and see
> if the problem persists, in order to rule out changes elsewhere in the
> system. If the problem doesn't happen with a 4.3.1 rebuilt on your
> current system then the next thing would probably be to bisect the
> issue. There are only 31 toolstack changes in that range, so it ought to
> only take 5-6 iterations.
Unfortunately 4.3.1 is no longer available as an ebuild as 4.3.3 seemed 
to fix security issues and therefore 4.3.1 has been deleted from the 
repos. So it's not straightforward and I need to figure out how to get 
the old version back. But I am sure there's a way.

Thanks Atom2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:19:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1Xlgpk-00082t-5Y; Tue, 04 Nov 2014 16:19: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@citrix.com>) id 1Xlgph-00082E-Qv
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:19:50 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	ED/69-09284-5ACF8545; Tue, 04 Nov 2014 16:19:49 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415117983!11635420!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4857 invoked from network); 4 Nov 2014 16:19:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 16:19:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187973454"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:17:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlgni-0001ys-Kw;
	Tue, 04 Nov 2014 16:17:46 +0000
Date: Tue, 4 Nov 2014 16:17:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>

Why?


>  arch/arm/include/asm/xen/hypercall.h |   1 +
>  arch/arm/include/asm/xen/interface.h |   2 +
>  arch/arm/xen/enlighten.c             |   1 +
>  arch/arm/xen/hypercall.S             |   1 +
>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
>  include/xen/interface/xen.h          |   6 +
>  6 files changed, 657 insertions(+)
>  create mode 100644 include/xen/interface/sysctl.h
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> index c817c56..751869eb 100644
> --- a/arch/arm/include/asm/xen/hypercall.h
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>  int HYPERVISOR_tmem_op(void *arg);
> +int HYPERVISOR_sysctl(void *arg);
>  
>  static inline void
>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 1151188..acf4b7a 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -19,6 +19,7 @@
>  	__DEFINE_GUEST_HANDLE(name, struct name)
>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
>  
>  #define set_xen_guest_handle(hnd, val)			\
>  	do {						\
> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
>  DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
> +DEFINE_GUEST_HANDLE(uint8_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>  
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index eb0d851..675f17a 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>  EXPORT_SYMBOL_GPL(privcmd_call);
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index d1cf7b7..a1276df 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>  HYPERCALL2(physdev_op);
>  HYPERCALL3(vcpu_op);
>  HYPERCALL1(tmem_op);
> +HYPERCALL1(sysctl);
>  
>  ENTRY(privcmd_call)
>  	stmdb sp!, {r4}
> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
> new file mode 100644
> index 0000000..1a8cf7a
> --- /dev/null
> +++ b/include/xen/interface/sysctl.h
> @@ -0,0 +1,646 @@
> +/******************************************************************************
> + * sysctl.h
> + *
> + * System management operations. For use by node control stack.
> + *
> + * Reused from xen: xen/include/public/sysctl.h
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (c) 2002-2006, K Fraser
> + * Copyright (c) 2014, GlobalLogic Inc.
> + */
> +
> +#ifndef __XEN_PUBLIC_SYSCTL_H__
> +#define __XEN_PUBLIC_SYSCTL_H__
> +
> +#include <xen/interface/xen.h>
> +
> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
> +
> +/*
> + * Read console content from Xen buffer ring.
> + */
> +/* XEN_SYSCTL_readconsole */
> +struct xen_sysctl_readconsole {
> +	/* IN: Non-zero -> clear after reading. */
> +	uint8_t clear;
> +	/* IN: Non-zero -> start index specified by @index field. */
> +	uint8_t incremental;
> +	uint8_t pad0, pad1;
> +	/*
> +	* IN:  Start index for consuming from ring buffer (if @incremental);
> +	* OUT: End index after consuming from ring buffer.
> +	*/
> +	uint32_t index;
> +	/* IN: Virtual address to write console data. */
> +	GUEST_HANDLE_64(char) buffer;
> +	/* IN: Size of buffer; OUT: Bytes written to buffer. */
> +	uint32_t count;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
> +
> +/* Get trace buffers machine base address */
> +/* XEN_SYSCTL_tbuf_op */
> +struct xen_sysctl_tbuf_op {
> +    /* IN variables */
> +#define XEN_SYSCTL_TBUFOP_get_info     0
> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
> +#define XEN_SYSCTL_TBUFOP_set_size     3
> +#define XEN_SYSCTL_TBUFOP_enable       4
> +#define XEN_SYSCTL_TBUFOP_disable      5
> +	uint32_t cmd;
> +	/* IN/OUT variables */
> +	struct xenctl_bitmap cpu_mask;
> +	uint32_t             evt_mask;
> +	/* OUT variables */
> +	uint64_aligned_t buffer_mfn;
> +	uint32_t size;  /* Also an IN variable! */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
> +
> +/*
> + * Get physical information about the host machine
> + */
> +/* XEN_SYSCTL_physinfo */
> + /* (x86) The platform supports HVM guests. */
> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
> +struct xen_sysctl_physinfo {
> +	uint32_t threads_per_core;
> +	uint32_t cores_per_socket;
> +	uint32_t nr_cpus;     /* # CPUs currently online */
> +	uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
> +	uint32_t nr_nodes;    /* # nodes currently online */
> +	uint32_t max_node_id; /* Largest possible node ID on this host */
> +	uint32_t cpu_khz;
> +	uint64_aligned_t total_pages;
> +	uint64_aligned_t free_pages;
> +	uint64_aligned_t scrub_pages;
> +	uint64_aligned_t outstanding_pages;
> +	uint32_t hw_cap[8];
> +
> +	/* XEN_SYSCTL_PHYSCAP_??? */
> +	uint32_t capabilities;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
> +
> +/*
> + * Get the ID of the current scheduler.
> + */
> +/* XEN_SYSCTL_sched_id */
> +struct xen_sysctl_sched_id {
> +	/* OUT variable */
> +	uint32_t sched_id;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
> +
> +/* Interface for controlling Xen software performance counters. */
> +/* XEN_SYSCTL_perfc_op */
> +/* Sub-operations: */
> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
> +struct xen_sysctl_perfc_desc {
> +	char         name[80];           /* name of perf counter */
> +	uint32_t     nr_vals;            /* number of values for this counter */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
> +
> +struct xen_sysctl_perfc_op {
> +	/* IN variables. */
> +	uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
> +	/* OUT variables. */
> +	uint32_t       nr_counters;       /*  number of counters description  */
> +	uint32_t       nr_vals;           /*  number of values  */
> +	/* counter information (or NULL) */
> +	GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
> +	/* counter values (or NULL) */
> +	GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
> +
> +/* Inject debug keys into Xen. */
> +/* XEN_SYSCTL_debug_keys */
> +struct xen_sysctl_debug_keys {
> +	/* IN variables. */
> +	GUEST_HANDLE_64(char) keys;
> +	uint32_t nr_keys;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
> +
> +/* Get physical CPU information. */
> +/* XEN_SYSCTL_getcpuinfo */
> +struct xen_sysctl_cpuinfo {
> +	uint64_aligned_t idletime;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
> +struct xen_sysctl_getcpuinfo {
> +	/* IN variables. */
> +	uint32_t max_cpus;
> +	GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
> +	/* OUT variables. */
> +	uint32_t nr_cpus;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
> +
> +/* XEN_SYSCTL_availheap */
> +struct xen_sysctl_availheap {
> +	/* IN variables. */
> +	uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
> +	uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
> +	int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
> +	/* OUT variables. */
> +	uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
> +
> +/* XEN_SYSCTL_get_pmstat */
> +struct pm_px_val {
> +	uint64_aligned_t freq;        /* Px core frequency */
> +	uint64_aligned_t residency;   /* Px residency time */
> +	uint64_aligned_t count;       /* Px transition count */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
> +
> +struct pm_px_stat {
> +	uint8_t total;        /* total Px states */
> +	uint8_t usable;       /* usable Px states */
> +	uint8_t last;         /* last Px state */
> +	uint8_t cur;          /* current Px state */
> +	GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
> +	GUEST_HANDLE_64(pm_px_val) pt;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
> +
> +struct pm_cx_stat {
> +	uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
> +	uint32_t last;  /* last Cx state */
> +	uint64_aligned_t idle_time;                 /* idle time from boot */
> +	GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
> +	GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
> +	uint64_aligned_t pc2;
> +	uint64_aligned_t pc3;
> +	uint64_aligned_t pc6;
> +	uint64_aligned_t pc7;
> +	uint64_aligned_t cc3;
> +	uint64_aligned_t cc6;
> +	uint64_aligned_t cc7;
> +};
> +
> +struct xen_sysctl_get_pmstat {
> +#define PMSTAT_CATEGORY_MASK 0xf0
> +#define PMSTAT_PX            0x10
> +#define PMSTAT_CX            0x20
> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
> +	uint32_t type;
> +	uint32_t cpuid;
> +	union {
> +		struct pm_px_stat getpx;
> +		struct pm_cx_stat getcx;
> +		/* other struct for tx, etc */
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
> +
> +/* XEN_SYSCTL_cpu_hotplug */
> +struct xen_sysctl_cpu_hotplug {
> +	/* IN variables */
> +	uint32_t cpu;   /* Physical cpu. */
> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
> +	uint32_t op;    /* hotplug opcode */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
> +
> +/*
> + * Get/set xen power management, include
> + * 1. cpufreq governors and related parameters
> + */
> +/* XEN_SYSCTL_pm_op */
> +struct xen_userspace {
> +	uint32_t scaling_setspeed;
> +};
> +
> +struct xen_ondemand {
> +	uint32_t sampling_rate_max;
> +	uint32_t sampling_rate_min;
> +
> +	uint32_t sampling_rate;
> +	uint32_t up_threshold;
> +};
> +
> +/*
> + * cpufreq para name of this structure named
> + * same as sysfs file name of native linux
> + */
> +#define CPUFREQ_NAME_LEN 16
> +struct xen_get_cpufreq_para {
> +	/* IN/OUT variable */
> +	uint32_t cpu_num;
> +	uint32_t freq_num;
> +	uint32_t gov_num;
> +
> +	/* for all governors */
> +	/* OUT variable */
> +	GUEST_HANDLE_64(uint32_t) affected_cpus;
> +	GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
> +	GUEST_HANDLE_64(char)   scaling_available_governors;
> +	char scaling_driver[CPUFREQ_NAME_LEN];
> +
> +	uint32_t cpuinfo_cur_freq;
> +	uint32_t cpuinfo_max_freq;
> +	uint32_t cpuinfo_min_freq;
> +	uint32_t scaling_cur_freq;
> +
> +	char scaling_governor[CPUFREQ_NAME_LEN];
> +	uint32_t scaling_max_freq;
> +	uint32_t scaling_min_freq;
> +
> +	/* for specific governor */
> +	union {
> +		struct  xen_userspace userspace;
> +		struct  xen_ondemand ondemand;
> +	} u;
> +
> +	int32_t turbo_enabled;
> +};
> +
> +struct xen_set_cpufreq_gov {
> +	char scaling_governor[CPUFREQ_NAME_LEN];
> +};
> +
> +struct xen_set_cpufreq_para {
> +	#define SCALING_MAX_FREQ           1
> +	#define SCALING_MIN_FREQ           2
> +	#define SCALING_SETSPEED           3
> +	#define SAMPLING_RATE              4
> +	#define UP_THRESHOLD               5
> +
> +	uint32_t ctrl_type;
> +	uint32_t ctrl_value;
> +};
> +
> +struct xen_sysctl_pm_op {
> +	#define PM_PARA_CATEGORY_MASK      0xf0
> +	#define CPUFREQ_PARA               0x10
> +
> +	/* cpufreq command type */
> +	#define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
> +	#define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
> +	#define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
> +	#define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
> +
> +	/* set/reset scheduler power saving option */
> +	#define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
> +
> +	/* cpuidle max_cstate access command */
> +	#define XEN_SYSCTL_pm_op_get_max_cstate       0x22
> +	#define XEN_SYSCTL_pm_op_set_max_cstate       0x23
> +
> +	/* set scheduler migration cost value */
> +	#define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
> +	#define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
> +
> +	/* enable/disable turbo mode when in dbs governor */
> +	#define XEN_SYSCTL_pm_op_enable_turbo               0x26
> +	#define XEN_SYSCTL_pm_op_disable_turbo              0x27
> +
> +	uint32_t cmd;
> +	uint32_t cpuid;
> +	union {
> +		struct xen_get_cpufreq_para get_para;
> +		struct xen_set_cpufreq_gov  set_gov;
> +		struct xen_set_cpufreq_para set_para;
> +		uint64_aligned_t get_avgfreq;
> +		uint32_t                    set_sched_opt_smt;
> +		uint32_t                    get_max_cstate;
> +		uint32_t                    set_max_cstate;
> +		uint32_t                    get_vcpu_migration_delay;
> +		uint32_t                    set_vcpu_migration_delay;
> +	} u;
> +};
> +
> +/* XEN_SYSCTL_page_offline_op */
> +struct xen_sysctl_page_offline_op {
> +	/* IN: range of page to be offlined */
> +#define sysctl_page_offline     1
> +#define sysctl_page_online      2
> +#define sysctl_query_page_offline  3
> +	uint32_t cmd;
> +	uint32_t start;
> +	uint32_t end;
> +	/* OUT: result of page offline request */
> +	/*
> +	* bit 0~15: result flags
> +	* bit 16~31: owner
> +	*/
> +	GUEST_HANDLE(uint32_t) status;
> +};
> +
> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
> +
> +/* The result is invalid, i.e. HV does not handle it */
> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
> +
> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
> +
> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
> +
> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
> +
> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
> +
> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
> +
> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
> +
> +#define PG_OFFLINE_OWNER_SHIFT 16
> +
> +/* XEN_SYSCTL_lockprof_op */
> +/* Sub-operations: */
> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
> +/* Record-type: */
> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
> +#define LOCKPROF_TYPE_N           2   /* number of types */
> +struct xen_sysctl_lockprof_data {
> +	char     name[40];   /* lock name (may include up to 2 %d specifiers) */
> +	int32_t  type;       /* LOCKPROF_TYPE_??? */
> +	int32_t  idx;        /* index (e.g. domain id) */
> +	uint64_aligned_t lock_cnt;     /* # of locking succeeded */
> +	uint64_aligned_t block_cnt;    /* # of wait for lock */
> +	uint64_aligned_t lock_time;    /* nsecs lock held */
> +	uint64_aligned_t block_time;   /* nsecs waited for lock */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
> +
> +struct xen_sysctl_lockprof_op {
> +	/* IN variables. */
> +	uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
> +	uint32_t       max_elem;          /* size of output buffer */
> +	/* OUT variables (query only). */
> +	uint32_t       nr_elem;           /* number of elements available */
> +	uint64_aligned_t time;            /* nsecs of profile measurement */
> +	/* profile information (or NULL) */
> +	GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
> +
> +/* XEN_SYSCTL_topologyinfo */
> +#define INVALID_TOPOLOGY_ID  (~0U)
> +struct xen_sysctl_topologyinfo {
> +	/*
> +	 * IN: maximum addressable entry in the caller-provided arrays.
> +	 * OUT: largest cpu identifier in the system.
> +	 * If OUT is greater than IN then the arrays are truncated!
> +	 * If OUT is leass than IN then the array tails are not written by
> +	 * sysctl.
> +	 */
> +	uint32_t max_cpu_index;
> +
> +	/*
> +	 * If not NULL, these arrays are filled with core/socket/node identifier
> +	 * for each cpu.
> +	 * If a cpu has no core/socket/node information (e.g., cpu not present)
> +	 * then the sentinel value ~0u is written to each array.
> +	 * The number of array elements written by the sysctl is:
> +	 *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
> +	 */
> +	GUEST_HANDLE_64(uint32_t) cpu_to_core;
> +	GUEST_HANDLE_64(uint32_t) cpu_to_socket;
> +	GUEST_HANDLE_64(uint32_t) cpu_to_node;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
> +
> +/* XEN_SYSCTL_numainfo */
> +#define INVALID_NUMAINFO_ID (~0U)
> +struct xen_sysctl_numainfo {
> +	/*
> +	 * IN: maximum addressable entry in the caller-provided arrays.
> +	 * OUT: largest node identifier in the system.
> +	 * If OUT is greater than IN then the arrays are truncated!
> +	 */
> +	uint32_t max_node_index;
> +
> +	/* NB. Entries are 0 if node is not present. */
> +	GUEST_HANDLE_64(uint64_t) node_to_memsize;
> +	GUEST_HANDLE_64(uint64_t) node_to_memfree;
> +
> +	/*
> +	 * Array, of size (max_node_index+1)^2, listing memory access distances
> +	 * between nodes. If an entry has no node distance information (e.g., node
> +	 * not present) then the value ~0u is written.
> +	 *
> +	 * Note that the array rows must be indexed by multiplying by the minimum
> +	 * of the caller-provided max_node_index and the returned value of
> +	 * max_node_index. That is, if the largest node index in the system is
> +	 * smaller than the caller can handle, a smaller 2-d array is constructed
> +	 * within the space provided by the caller. When this occurs, trailing
> +	 * space provided by the caller is not modified. If the largest node index
> +	 * in the system is larger than the caller can handle, then a 2-d array of
> +	 * the maximum size handleable by the caller is constructed.
> +	 */
> +	GUEST_HANDLE_64(uint32_t) node_to_node_distance;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
> +
> +/* XEN_SYSCTL_cpupool_op */
> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
> +struct xen_sysctl_cpupool_op {
> +	uint32_t op;          /* IN */
> +	uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
> +	uint32_t sched_id;    /* IN: C      OUT: I  */
> +	uint32_t domid;       /* IN: M              */
> +	uint32_t cpu;         /* IN: AR             */
> +	uint32_t n_dom;       /*            OUT: I  */
> +	struct xenctl_bitmap cpumap; /*     OUT: IF */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
> +
> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
> +/*
> + * This structure is used to pass a new ARINC653 schedule from a
> + * privileged domain (ie dom0) to Xen.
> + */
> +struct xen_sysctl_arinc653_schedule {
> +	/* major_frame holds the time for the new schedule's major frame
> +	* in nanoseconds. */
> +	uint64_aligned_t     major_frame;
> +	/* num_sched_entries holds how many of the entries in the
> +	* sched_entries[] array are valid. */
> +	uint8_t     num_sched_entries;
> +	/* The sched_entries array holds the actual schedule entries. */
> +	struct {
> +		/* dom_handle must match a domain's UUID */
> +		xen_domain_handle_t dom_handle;
> +		/*
> +		 * If a domain has multiple VCPUs, vcpu_id specifies which one
> +		 * this schedule entry applies to. It should be set to 0 if
> +		 * there is only one VCPU for the domain. */
> +		unsigned int vcpu_id;
> +		/*
> +		 * runtime specifies the amount of time that should be allocated
> +		 * to this VCPU per major frame. It is specified in nanoseconds
> +		 */
> +		uint64_aligned_t runtime;
> +	} sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
> +
> +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;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
> +
> +/* XEN_SYSCTL_scheduler_op */
> +/* Set or get info? */
> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
> +struct xen_sysctl_scheduler_op {
> +	uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
> +	uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
> +	uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
> +	union {
> +		struct xen_sysctl_sched_arinc653 {
> +			GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
> +		} sched_arinc653;
> +		struct xen_sysctl_credit_schedule sched_credit;
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
> +
> +/* XEN_SYSCTL_coverage_op */
> +/*
> + * Get total size of information, to help allocate
> + * the buffer. The pointer points to a 32 bit value.
> + */
> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
> +
> +/*
> + * Read coverage information in a single run
> + * You must use a tool to split them.
> + */
> +#define XEN_SYSCTL_COVERAGE_read           1
> +
> +/*
> + * Reset all the coverage counters to 0
> + * No parameters.
> + */
> +#define XEN_SYSCTL_COVERAGE_reset          2
> +
> +/*
> + * Like XEN_SYSCTL_COVERAGE_read but reset also
> + * counters to 0 in a single call.
> + */
> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
> +
> +struct xen_sysctl_coverage_op {
> +	uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
> +	union {
> +		uint32_t total_size; /* OUT */
> +		GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
> +
> +
> +struct xen_sysctl {
> +	uint32_t cmd;
> +#define XEN_SYSCTL_readconsole                    1
> +#define XEN_SYSCTL_tbuf_op                        2
> +#define XEN_SYSCTL_physinfo                       3
> +#define XEN_SYSCTL_sched_id                       4
> +#define XEN_SYSCTL_perfc_op                       5
> +#define XEN_SYSCTL_debug_keys                     7
> +#define XEN_SYSCTL_getcpuinfo                     8
> +#define XEN_SYSCTL_availheap                      9
> +#define XEN_SYSCTL_get_pmstat                    10
> +#define XEN_SYSCTL_cpu_hotplug                   11
> +#define XEN_SYSCTL_pm_op                         12
> +#define XEN_SYSCTL_page_offline_op               14
> +#define XEN_SYSCTL_lockprof_op                   15
> +#define XEN_SYSCTL_topologyinfo                  16
> +#define XEN_SYSCTL_numainfo                      17
> +#define XEN_SYSCTL_cpupool_op                    18
> +#define XEN_SYSCTL_scheduler_op                  19
> +#define XEN_SYSCTL_coverage_op                   20
> +	uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
> +	union {
> +		struct xen_sysctl_readconsole       readconsole;
> +		struct xen_sysctl_tbuf_op           tbuf_op;
> +		struct xen_sysctl_physinfo          physinfo;
> +		struct xen_sysctl_topologyinfo      topologyinfo;
> +		struct xen_sysctl_numainfo          numainfo;
> +		struct xen_sysctl_sched_id          sched_id;
> +		struct xen_sysctl_perfc_op          perfc_op;
> +		struct xen_sysctl_debug_keys        debug_keys;
> +		struct xen_sysctl_getcpuinfo        getcpuinfo;
> +		struct xen_sysctl_availheap         availheap;
> +		struct xen_sysctl_get_pmstat        get_pmstat;
> +		struct xen_sysctl_cpu_hotplug       cpu_hotplug;
> +		struct xen_sysctl_pm_op             pm_op;
> +		struct xen_sysctl_page_offline_op   page_offline;
> +		struct xen_sysctl_lockprof_op       lockprof_op;
> +		struct xen_sysctl_cpupool_op        cpupool_op;
> +		struct xen_sysctl_scheduler_op      scheduler_op;
> +		struct xen_sysctl_coverage_op       coverage_op;
> +		uint8_t                             pad[128];
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
> +
> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */

We usually only introduce what we need from Xen header files in Linux:
do not copy the entirety of sysctl.h, just introduce what you need.


> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 53ec416..cf64566 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -57,6 +57,7 @@
>  #define __HYPERVISOR_event_channel_op     32
>  #define __HYPERVISOR_physdev_op           33
>  #define __HYPERVISOR_hvm_op               34
> +#define __HYPERVISOR_sysctl               35
>  #define __HYPERVISOR_tmem_op              38
>  
>  /* Architecture-specific hypercall definitions. */
> @@ -526,6 +527,11 @@ struct tmem_op {
>  
>  DEFINE_GUEST_HANDLE(u64);
>  
> +struct xenctl_bitmap {
> +	GUEST_HANDLE_64(uint8_t) bitmap;
> +	uint32_t nr_bits;
> +};
> +
>  #else /* __ASSEMBLY__ */
>  
>  /* In assembly code we cannot use C numeric constant suffixes. */
> -- 
> 1.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:19:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1Xlgpe-00081b-Kr; Tue, 04 Nov 2014 16:19:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xlgpd-00081L-9e
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:19:45 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	67/D1-17735-0ACF8545; Tue, 04 Nov 2014 16:19:44 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415117979!11596677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19410 invoked from network); 4 Nov 2014 16:19:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 16:19:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189355271"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:17:38 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlgjJ-0001XF-8c;
	Tue, 04 Nov 2014 16:13:13 +0000
Date: Tue, 4 Nov 2014 16:13:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106521-3115-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041612330.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 10/11] cpufreq: add hwdom-cpufreq
	driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> This driver uses hwdom to change frequencies on CPUs
> Workflow:
>  * cpufreq governor driver in Xen wants to change the
>    frequency of the physical CPU
>  * hwdom-cpufreq driver sets parameters in the shared
>    memory
>  * hwdom-cpufreq driver sends an VIRQ_CPUFREQ interrupt
>    to notify the hardware domain
>  * cpufreq driver in the hardware domain reads parameters
>    from the shared memory, changes frequency and copies
>    the result of the operation to the shared memory
> 
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> ---
>  xen/Rules.mk                        |   1 +
>  xen/drivers/cpufreq/Makefile        |   1 +
>  xen/drivers/cpufreq/hwdom-cpufreq.c | 252 ++++++++++++++++++++++++++++++++++++
>  xen/include/public/xen.h            |   1 +
>  4 files changed, 255 insertions(+)
>  create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 3b0b89b..cccbc72 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>  CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
> +CFLAGS-$(HAS_HWDOM_CPUFREQ) += -DHAS_HWDOM_CPUFREQ
>  CFLAGS-$(HAS_PM)        += -DHAS_PM
>  CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
>  CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
> diff --git a/xen/drivers/cpufreq/Makefile b/xen/drivers/cpufreq/Makefile
> index b87d127..891997c 100644
> --- a/xen/drivers/cpufreq/Makefile
> +++ b/xen/drivers/cpufreq/Makefile
> @@ -2,3 +2,4 @@ obj-y += cpufreq.o
>  obj-y += cpufreq_ondemand.o
>  obj-y += cpufreq_misc_governors.o
>  obj-y += utility.o
> +obj-$(HAS_HWDOM_CPUFREQ) += hwdom-cpufreq.o
> diff --git a/xen/drivers/cpufreq/hwdom-cpufreq.c b/xen/drivers/cpufreq/hwdom-cpufreq.c
> new file mode 100644
> index 0000000..a39fc6c
> --- /dev/null
> +++ b/xen/drivers/cpufreq/hwdom-cpufreq.c
> @@ -0,0 +1,252 @@
> +/*
> + *  Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
> + *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
> + *  Copyright (C) 2002 - 2004 Dominik Brodowski <linux@brodo.de>
> + *  Copyright (C) 2006        Denis Sadykov <denis.m.sadykov@intel.com>
> + *
> + *  Feb 2008 - Liu Jinsong <jinsong.liu@intel.com>
> + *      porting acpi-cpufreq.c from Linux 2.6.23 to Xen hypervisor
> + *
> + *  Copyright (C) 2014 GlobalLogic Inc.
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or (at
> + *  your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful, but
> + *  WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + *  General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, write to the Free Software Foundation, Inc.,
> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +#include <xen/types.h>
> +#include <xen/errno.h>
> +#include <xen/sched.h>
> +#include <xen/event.h>
> +#include <xen/irq.h>
> +#include <xen/spinlock.h>
> +#include <xen/cpufreq.h>
> +#include <xen/err.h>
> +#include <asm/shared.h>
> +#include <asm/current.h>
> +#include <asm/system.h>
> +
> +struct hwdom_cpufreq_data {
> +    struct processor_performance *perf_data;
> +    struct cpufreq_frequency_table *freq_table;
> +};
> +
> +static struct hwdom_cpufreq_data *hwdom_cpufreq_drv_data[NR_CPUS];
> +
> +int cpufreq_cpu_init(unsigned int cpuid)
> +{
> +    return cpufreq_add_cpu(cpuid);
> +}
> +
> +static void notify_cpufreq_domain(void)
> +{
> +    send_global_virq(VIRQ_CPUFREQ);
> +}
> +
> +static int hwdom_cpufreq_verify(struct cpufreq_policy *policy)
> +{
> +    struct hwdom_cpufreq_data *data;
> +    struct processor_performance *perf;
> +
> +    if ( !policy || !(data = hwdom_cpufreq_drv_data[policy->cpu]) ||
> +         !processor_pminfo[policy->cpu] )
> +        return -EINVAL;
> +
> +    perf = &processor_pminfo[policy->cpu]->perf;
> +
> +    cpufreq_verify_within_limits(policy, 0,
> +        perf->states[perf->platform_limit].core_frequency * 1000);
> +
> +    return cpufreq_frequency_table_verify(policy, data->freq_table);
> +}
> +
> +static int hwdom_cpufreq_target(struct cpufreq_policy *policy,
> +                               unsigned int target_freq, unsigned int relation)
> +{
> +    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
> +    struct processor_performance *perf;
> +    struct cpufreq_freqs freqs;
> +    struct cpufreq_sh_info *cpufreq_info;
> +    cpumask_t online_policy_cpus;
> +    unsigned int next_state = 0; /* Index into freq_table */
> +    unsigned int next_perf_state = 0; /* Index into perf table */
> +    unsigned int j;
> +    int ret = 0;
> +
> +    if ( unlikely(data == NULL ||
> +         data->perf_data == NULL || data->freq_table == NULL) )
> +        return -ENODEV;
> +
> +    perf = data->perf_data;
> +    ret = cpufreq_frequency_table_target(policy,
> +                                         data->freq_table,
> +                                         target_freq,
> +                                         relation, &next_state);
> +    if ( unlikely(ret) )
> +        return -ENODEV;
> +
> +    cpumask_and(&online_policy_cpus, &cpu_online_map, policy->cpus);
> +
> +    next_perf_state = data->freq_table[next_state].index;
> +    if ( perf->state == next_perf_state )
> +    {
> +        if ( unlikely(policy->resume) )
> +            policy->resume = 0;
> +        else
> +            return 0;
> +    }
> +
> +    freqs.old = perf->states[perf->state].core_frequency * 1000;
> +    freqs.new = data->freq_table[next_state].frequency;
> +
> +     /* Do send cmd for Hardware domain */
> +    cpufreq_info = arch_get_cpufreq_addr(dom0);
> +
> +    /* Set previous result in the Hardware domain then read it */
> +    smp_rmb();
> +
> +     /* return previous result */
> +    ret = cpufreq_info->result;

What if the previous command hasn't completed yet?


> +    cpufreq_info->cpu = policy->cpu;
> +    cpufreq_info->freq = freqs.new;
> +    cpufreq_info->relation = (uint32_t)relation;
> +
> +    smp_wmb(); /* above must be visible before notify_cpufreq_domain() */
> +
> +    notify_cpufreq_domain();
> +
> +    for_each_cpu( j, &online_policy_cpus )
> +        cpufreq_statistic_update(j, perf->state, next_perf_state);
> +
> +    perf->state = next_perf_state;
> +    policy->cur = freqs.new;
> +
> +    return ret;
> +}
> +
> +static int
> +hwdom_cpufreq_cpu_init(struct cpufreq_policy *policy)
> +{
> +    struct processor_performance *perf;
> +    struct hwdom_cpufreq_data *data;
> +    unsigned int cpu = policy->cpu;
> +    unsigned int valid_states = 0;
> +    int i;
> +    int ret = 0;
> +
> +    data = xzalloc(struct hwdom_cpufreq_data);
> +    if ( !data )
> +        return -ENOMEM;
> +
> +    hwdom_cpufreq_drv_data[cpu] = data;
> +
> +    data->perf_data = &processor_pminfo[cpu]->perf;
> +
> +    perf = data->perf_data;
> +    policy->shared_type = perf->shared_type;
> +
> +    data->freq_table = xmalloc_array(struct cpufreq_frequency_table,
> +                                     (perf->state_count+1));
> +    if ( !data->freq_table )
> +    {
> +        ret = -ENOMEM;
> +        goto err_unreg;
> +    }
> +
> +    /* detect transition latency */
> +    policy->cpuinfo.transition_latency = 0;
> +    for ( i = 0; i < perf->state_count; i++ )
> +    {
> +        if ( (perf->states[i].transition_latency * 1000) >
> +             policy->cpuinfo.transition_latency )
> +            policy->cpuinfo.transition_latency =
> +                perf->states[i].transition_latency * 1000;
> +    }
> +
> +    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
> +
> +    /* table init */
> +    for ( i = 0; i < perf->state_count; i++ )
> +    {
> +        if ( i > 0 && perf->states[i].core_frequency >=
> +            data->freq_table[valid_states-1].frequency / 1000 )
> +            continue;
> +
> +        data->freq_table[valid_states].index = i;
> +        data->freq_table[valid_states].frequency =
> +            perf->states[i].core_frequency * 1000;
> +        valid_states++;
> +    }
> +    data->freq_table[valid_states].frequency = CPUFREQ_TABLE_END;
> +    perf->state = 0;
> +
> +    ret = cpufreq_frequency_table_cpuinfo(policy, data->freq_table);
> +    if ( ret )
> +        goto err_freqfree;
> +
> +
> +    /*
> +     * the first call to ->target() should result in us actually
> +     * send command to the Hardware domain to set frequency.
> +     */
> +    policy->resume = 1;
> +
> +    /* Set the minimal frequency */
> +    return hwdom_cpufreq_target(policy, policy->min, CPUFREQ_RELATION_L);
> +
> + err_freqfree:
> +    xfree(data->freq_table);
> + err_unreg:
> +    xfree(data);
> +    hwdom_cpufreq_drv_data[cpu] = NULL;
> +
> +    return ret;
> +}
> +
> +static int hwdom_cpufreq_cpu_exit(struct cpufreq_policy *policy)
> +{
> +    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
> +
> +    if ( data )
> +    {
> +        hwdom_cpufreq_drv_data[policy->cpu] = NULL;
> +        xfree(data->freq_table);
> +        xfree(data);
> +    }
> +
> +    return 0;
> +}
> +
> +static struct cpufreq_driver hwdom_cpufreq_driver = {
> +    .name   = "hwdom-cpufreq",
> +    .verify = hwdom_cpufreq_verify,
> +    .target = hwdom_cpufreq_target,
> +    .init   = hwdom_cpufreq_cpu_init,
> +    .exit   = hwdom_cpufreq_cpu_exit,
> +};
> +
> +static int __init hwdom_cpufreq_driver_init(void)
> +{
> +    int ret = 0;
> +
> +    if ( cpufreq_controller == FREQCTL_xen )
> +        ret = cpufreq_register_driver(&hwdom_cpufreq_driver);
> +
> +    return ret;
> +}
> +
> +__initcall(hwdom_cpufreq_driver_init);
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 8c5697e..abd8438 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -160,6 +160,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>  #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       */
> +#define VIRQ_CPUFREQ    14 /* G. (DOM0) Notify cpufreq driver                */
>  
>  /* Architecture-specific VIRQ definitions. */
>  #define VIRQ_ARCH_0    16
> -- 
> 1.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:19:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1Xlgpe-00081U-A4; Tue, 04 Nov 2014 16:19:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xlgpc-00081H-KL
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:19:44 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	42/07-26858-F9CF8545; Tue, 04 Nov 2014 16:19:43 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415117979!11596677!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19521 invoked from network); 4 Nov 2014 16:19:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 16:19:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189355358"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:17:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlgic-0001SK-W4;
	Tue, 04 Nov 2014 16:12:30 +0000
Date: Tue, 4 Nov 2014 16:12:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041609070.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared
 info definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> This shared info will be used by hwdom-cpufreq driver
> to send commands to the cpufreq driver in the hwdom.
> 
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> ---
>  xen/include/asm-arm/shared.h  | 14 ++++++++++++++
>  xen/include/public/arch-arm.h |  8 ++++++++
>  2 files changed, 22 insertions(+)
>  create mode 100644 xen/include/asm-arm/shared.h
> 
> diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
> new file mode 100644
> index 0000000..4906f38
> --- /dev/null
> +++ b/xen/include/asm-arm/shared.h
> @@ -0,0 +1,14 @@
> +#ifndef __XEN_ARM_SHARED_H__
> +#define __XEN_ARM_SHARED_H__
> +
> +#define GET_SET_SHARED(type, field)                                 \
> +static inline type *arch_get_##field##_addr(const struct domain *d) \
> +{                                                                   \
> +   return &d->shared_info->arch.field;                              \
> +}
> +
> +GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
> +
> +#undef GET_SET_SHARED
> +
> +#endif /* __XEN_ARM_SHARED_H__ */
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 7496556..7eef6f7 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -309,7 +309,15 @@ struct arch_vcpu_info {
>  };
>  typedef struct arch_vcpu_info arch_vcpu_info_t;
>  
> +struct cpufreq_sh_info {
> +    uint32_t cpu;       /* Physical CPU number */
> +    uint32_t freq;      /* Frequency in KHz */
> +    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
> +    int32_t result;        /* Returned result of the operation */
> +};
> +
>  struct arch_shared_info {
> +    struct cpufreq_sh_info cpufreq;
>  };
>  typedef struct arch_shared_info arch_shared_info_t;
>  typedef uint64_t xen_callback_t;

This introduces one global struct cpufreq_sh_info. Do we need to worry
about locking? Is it possible that we might want to send two commands
simultaneously? How does Xen get to know that Dom0 completed the
previous operation before starting a new one?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:19:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1Xlgpe-00081U-A4; Tue, 04 Nov 2014 16:19:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xlgpc-00081H-KL
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:19:44 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	42/07-26858-F9CF8545; Tue, 04 Nov 2014 16:19:43 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415117979!11596677!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19521 invoked from network); 4 Nov 2014 16:19:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 16:19:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189355358"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:17:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlgic-0001SK-W4;
	Tue, 04 Nov 2014 16:12:30 +0000
Date: Tue, 4 Nov 2014 16:12:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041609070.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared
 info definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> This shared info will be used by hwdom-cpufreq driver
> to send commands to the cpufreq driver in the hwdom.
> 
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> ---
>  xen/include/asm-arm/shared.h  | 14 ++++++++++++++
>  xen/include/public/arch-arm.h |  8 ++++++++
>  2 files changed, 22 insertions(+)
>  create mode 100644 xen/include/asm-arm/shared.h
> 
> diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
> new file mode 100644
> index 0000000..4906f38
> --- /dev/null
> +++ b/xen/include/asm-arm/shared.h
> @@ -0,0 +1,14 @@
> +#ifndef __XEN_ARM_SHARED_H__
> +#define __XEN_ARM_SHARED_H__
> +
> +#define GET_SET_SHARED(type, field)                                 \
> +static inline type *arch_get_##field##_addr(const struct domain *d) \
> +{                                                                   \
> +   return &d->shared_info->arch.field;                              \
> +}
> +
> +GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
> +
> +#undef GET_SET_SHARED
> +
> +#endif /* __XEN_ARM_SHARED_H__ */
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 7496556..7eef6f7 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -309,7 +309,15 @@ struct arch_vcpu_info {
>  };
>  typedef struct arch_vcpu_info arch_vcpu_info_t;
>  
> +struct cpufreq_sh_info {
> +    uint32_t cpu;       /* Physical CPU number */
> +    uint32_t freq;      /* Frequency in KHz */
> +    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
> +    int32_t result;        /* Returned result of the operation */
> +};
> +
>  struct arch_shared_info {
> +    struct cpufreq_sh_info cpufreq;
>  };
>  typedef struct arch_shared_info arch_shared_info_t;
>  typedef uint64_t xen_callback_t;

This introduces one global struct cpufreq_sh_info. Do we need to worry
about locking? Is it possible that we might want to send two commands
simultaneously? How does Xen get to know that Dom0 completed the
previous operation before starting a new one?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:19:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1Xlgpk-00082t-5Y; Tue, 04 Nov 2014 16:19: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@citrix.com>) id 1Xlgph-00082E-Qv
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:19:50 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	ED/69-09284-5ACF8545; Tue, 04 Nov 2014 16:19:49 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415117983!11635420!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4857 invoked from network); 4 Nov 2014 16:19:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 16:19:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187973454"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:17:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlgni-0001ys-Kw;
	Tue, 04 Nov 2014 16:17:46 +0000
Date: Tue, 4 Nov 2014 16:17:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>

Why?


>  arch/arm/include/asm/xen/hypercall.h |   1 +
>  arch/arm/include/asm/xen/interface.h |   2 +
>  arch/arm/xen/enlighten.c             |   1 +
>  arch/arm/xen/hypercall.S             |   1 +
>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
>  include/xen/interface/xen.h          |   6 +
>  6 files changed, 657 insertions(+)
>  create mode 100644 include/xen/interface/sysctl.h
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> index c817c56..751869eb 100644
> --- a/arch/arm/include/asm/xen/hypercall.h
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>  int HYPERVISOR_tmem_op(void *arg);
> +int HYPERVISOR_sysctl(void *arg);
>  
>  static inline void
>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 1151188..acf4b7a 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -19,6 +19,7 @@
>  	__DEFINE_GUEST_HANDLE(name, struct name)
>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
>  
>  #define set_xen_guest_handle(hnd, val)			\
>  	do {						\
> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
>  DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
> +DEFINE_GUEST_HANDLE(uint8_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>  
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index eb0d851..675f17a 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>  EXPORT_SYMBOL_GPL(privcmd_call);
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index d1cf7b7..a1276df 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>  HYPERCALL2(physdev_op);
>  HYPERCALL3(vcpu_op);
>  HYPERCALL1(tmem_op);
> +HYPERCALL1(sysctl);
>  
>  ENTRY(privcmd_call)
>  	stmdb sp!, {r4}
> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
> new file mode 100644
> index 0000000..1a8cf7a
> --- /dev/null
> +++ b/include/xen/interface/sysctl.h
> @@ -0,0 +1,646 @@
> +/******************************************************************************
> + * sysctl.h
> + *
> + * System management operations. For use by node control stack.
> + *
> + * Reused from xen: xen/include/public/sysctl.h
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (c) 2002-2006, K Fraser
> + * Copyright (c) 2014, GlobalLogic Inc.
> + */
> +
> +#ifndef __XEN_PUBLIC_SYSCTL_H__
> +#define __XEN_PUBLIC_SYSCTL_H__
> +
> +#include <xen/interface/xen.h>
> +
> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
> +
> +/*
> + * Read console content from Xen buffer ring.
> + */
> +/* XEN_SYSCTL_readconsole */
> +struct xen_sysctl_readconsole {
> +	/* IN: Non-zero -> clear after reading. */
> +	uint8_t clear;
> +	/* IN: Non-zero -> start index specified by @index field. */
> +	uint8_t incremental;
> +	uint8_t pad0, pad1;
> +	/*
> +	* IN:  Start index for consuming from ring buffer (if @incremental);
> +	* OUT: End index after consuming from ring buffer.
> +	*/
> +	uint32_t index;
> +	/* IN: Virtual address to write console data. */
> +	GUEST_HANDLE_64(char) buffer;
> +	/* IN: Size of buffer; OUT: Bytes written to buffer. */
> +	uint32_t count;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
> +
> +/* Get trace buffers machine base address */
> +/* XEN_SYSCTL_tbuf_op */
> +struct xen_sysctl_tbuf_op {
> +    /* IN variables */
> +#define XEN_SYSCTL_TBUFOP_get_info     0
> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
> +#define XEN_SYSCTL_TBUFOP_set_size     3
> +#define XEN_SYSCTL_TBUFOP_enable       4
> +#define XEN_SYSCTL_TBUFOP_disable      5
> +	uint32_t cmd;
> +	/* IN/OUT variables */
> +	struct xenctl_bitmap cpu_mask;
> +	uint32_t             evt_mask;
> +	/* OUT variables */
> +	uint64_aligned_t buffer_mfn;
> +	uint32_t size;  /* Also an IN variable! */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
> +
> +/*
> + * Get physical information about the host machine
> + */
> +/* XEN_SYSCTL_physinfo */
> + /* (x86) The platform supports HVM guests. */
> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
> +struct xen_sysctl_physinfo {
> +	uint32_t threads_per_core;
> +	uint32_t cores_per_socket;
> +	uint32_t nr_cpus;     /* # CPUs currently online */
> +	uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
> +	uint32_t nr_nodes;    /* # nodes currently online */
> +	uint32_t max_node_id; /* Largest possible node ID on this host */
> +	uint32_t cpu_khz;
> +	uint64_aligned_t total_pages;
> +	uint64_aligned_t free_pages;
> +	uint64_aligned_t scrub_pages;
> +	uint64_aligned_t outstanding_pages;
> +	uint32_t hw_cap[8];
> +
> +	/* XEN_SYSCTL_PHYSCAP_??? */
> +	uint32_t capabilities;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
> +
> +/*
> + * Get the ID of the current scheduler.
> + */
> +/* XEN_SYSCTL_sched_id */
> +struct xen_sysctl_sched_id {
> +	/* OUT variable */
> +	uint32_t sched_id;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
> +
> +/* Interface for controlling Xen software performance counters. */
> +/* XEN_SYSCTL_perfc_op */
> +/* Sub-operations: */
> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
> +struct xen_sysctl_perfc_desc {
> +	char         name[80];           /* name of perf counter */
> +	uint32_t     nr_vals;            /* number of values for this counter */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
> +
> +struct xen_sysctl_perfc_op {
> +	/* IN variables. */
> +	uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
> +	/* OUT variables. */
> +	uint32_t       nr_counters;       /*  number of counters description  */
> +	uint32_t       nr_vals;           /*  number of values  */
> +	/* counter information (or NULL) */
> +	GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
> +	/* counter values (or NULL) */
> +	GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
> +
> +/* Inject debug keys into Xen. */
> +/* XEN_SYSCTL_debug_keys */
> +struct xen_sysctl_debug_keys {
> +	/* IN variables. */
> +	GUEST_HANDLE_64(char) keys;
> +	uint32_t nr_keys;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
> +
> +/* Get physical CPU information. */
> +/* XEN_SYSCTL_getcpuinfo */
> +struct xen_sysctl_cpuinfo {
> +	uint64_aligned_t idletime;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
> +struct xen_sysctl_getcpuinfo {
> +	/* IN variables. */
> +	uint32_t max_cpus;
> +	GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
> +	/* OUT variables. */
> +	uint32_t nr_cpus;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
> +
> +/* XEN_SYSCTL_availheap */
> +struct xen_sysctl_availheap {
> +	/* IN variables. */
> +	uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
> +	uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
> +	int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
> +	/* OUT variables. */
> +	uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
> +
> +/* XEN_SYSCTL_get_pmstat */
> +struct pm_px_val {
> +	uint64_aligned_t freq;        /* Px core frequency */
> +	uint64_aligned_t residency;   /* Px residency time */
> +	uint64_aligned_t count;       /* Px transition count */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
> +
> +struct pm_px_stat {
> +	uint8_t total;        /* total Px states */
> +	uint8_t usable;       /* usable Px states */
> +	uint8_t last;         /* last Px state */
> +	uint8_t cur;          /* current Px state */
> +	GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
> +	GUEST_HANDLE_64(pm_px_val) pt;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
> +
> +struct pm_cx_stat {
> +	uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
> +	uint32_t last;  /* last Cx state */
> +	uint64_aligned_t idle_time;                 /* idle time from boot */
> +	GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
> +	GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
> +	uint64_aligned_t pc2;
> +	uint64_aligned_t pc3;
> +	uint64_aligned_t pc6;
> +	uint64_aligned_t pc7;
> +	uint64_aligned_t cc3;
> +	uint64_aligned_t cc6;
> +	uint64_aligned_t cc7;
> +};
> +
> +struct xen_sysctl_get_pmstat {
> +#define PMSTAT_CATEGORY_MASK 0xf0
> +#define PMSTAT_PX            0x10
> +#define PMSTAT_CX            0x20
> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
> +	uint32_t type;
> +	uint32_t cpuid;
> +	union {
> +		struct pm_px_stat getpx;
> +		struct pm_cx_stat getcx;
> +		/* other struct for tx, etc */
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
> +
> +/* XEN_SYSCTL_cpu_hotplug */
> +struct xen_sysctl_cpu_hotplug {
> +	/* IN variables */
> +	uint32_t cpu;   /* Physical cpu. */
> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
> +	uint32_t op;    /* hotplug opcode */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
> +
> +/*
> + * Get/set xen power management, include
> + * 1. cpufreq governors and related parameters
> + */
> +/* XEN_SYSCTL_pm_op */
> +struct xen_userspace {
> +	uint32_t scaling_setspeed;
> +};
> +
> +struct xen_ondemand {
> +	uint32_t sampling_rate_max;
> +	uint32_t sampling_rate_min;
> +
> +	uint32_t sampling_rate;
> +	uint32_t up_threshold;
> +};
> +
> +/*
> + * cpufreq para name of this structure named
> + * same as sysfs file name of native linux
> + */
> +#define CPUFREQ_NAME_LEN 16
> +struct xen_get_cpufreq_para {
> +	/* IN/OUT variable */
> +	uint32_t cpu_num;
> +	uint32_t freq_num;
> +	uint32_t gov_num;
> +
> +	/* for all governors */
> +	/* OUT variable */
> +	GUEST_HANDLE_64(uint32_t) affected_cpus;
> +	GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
> +	GUEST_HANDLE_64(char)   scaling_available_governors;
> +	char scaling_driver[CPUFREQ_NAME_LEN];
> +
> +	uint32_t cpuinfo_cur_freq;
> +	uint32_t cpuinfo_max_freq;
> +	uint32_t cpuinfo_min_freq;
> +	uint32_t scaling_cur_freq;
> +
> +	char scaling_governor[CPUFREQ_NAME_LEN];
> +	uint32_t scaling_max_freq;
> +	uint32_t scaling_min_freq;
> +
> +	/* for specific governor */
> +	union {
> +		struct  xen_userspace userspace;
> +		struct  xen_ondemand ondemand;
> +	} u;
> +
> +	int32_t turbo_enabled;
> +};
> +
> +struct xen_set_cpufreq_gov {
> +	char scaling_governor[CPUFREQ_NAME_LEN];
> +};
> +
> +struct xen_set_cpufreq_para {
> +	#define SCALING_MAX_FREQ           1
> +	#define SCALING_MIN_FREQ           2
> +	#define SCALING_SETSPEED           3
> +	#define SAMPLING_RATE              4
> +	#define UP_THRESHOLD               5
> +
> +	uint32_t ctrl_type;
> +	uint32_t ctrl_value;
> +};
> +
> +struct xen_sysctl_pm_op {
> +	#define PM_PARA_CATEGORY_MASK      0xf0
> +	#define CPUFREQ_PARA               0x10
> +
> +	/* cpufreq command type */
> +	#define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
> +	#define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
> +	#define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
> +	#define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
> +
> +	/* set/reset scheduler power saving option */
> +	#define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
> +
> +	/* cpuidle max_cstate access command */
> +	#define XEN_SYSCTL_pm_op_get_max_cstate       0x22
> +	#define XEN_SYSCTL_pm_op_set_max_cstate       0x23
> +
> +	/* set scheduler migration cost value */
> +	#define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
> +	#define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
> +
> +	/* enable/disable turbo mode when in dbs governor */
> +	#define XEN_SYSCTL_pm_op_enable_turbo               0x26
> +	#define XEN_SYSCTL_pm_op_disable_turbo              0x27
> +
> +	uint32_t cmd;
> +	uint32_t cpuid;
> +	union {
> +		struct xen_get_cpufreq_para get_para;
> +		struct xen_set_cpufreq_gov  set_gov;
> +		struct xen_set_cpufreq_para set_para;
> +		uint64_aligned_t get_avgfreq;
> +		uint32_t                    set_sched_opt_smt;
> +		uint32_t                    get_max_cstate;
> +		uint32_t                    set_max_cstate;
> +		uint32_t                    get_vcpu_migration_delay;
> +		uint32_t                    set_vcpu_migration_delay;
> +	} u;
> +};
> +
> +/* XEN_SYSCTL_page_offline_op */
> +struct xen_sysctl_page_offline_op {
> +	/* IN: range of page to be offlined */
> +#define sysctl_page_offline     1
> +#define sysctl_page_online      2
> +#define sysctl_query_page_offline  3
> +	uint32_t cmd;
> +	uint32_t start;
> +	uint32_t end;
> +	/* OUT: result of page offline request */
> +	/*
> +	* bit 0~15: result flags
> +	* bit 16~31: owner
> +	*/
> +	GUEST_HANDLE(uint32_t) status;
> +};
> +
> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
> +
> +/* The result is invalid, i.e. HV does not handle it */
> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
> +
> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
> +
> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
> +
> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
> +
> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
> +
> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
> +
> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
> +
> +#define PG_OFFLINE_OWNER_SHIFT 16
> +
> +/* XEN_SYSCTL_lockprof_op */
> +/* Sub-operations: */
> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
> +/* Record-type: */
> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
> +#define LOCKPROF_TYPE_N           2   /* number of types */
> +struct xen_sysctl_lockprof_data {
> +	char     name[40];   /* lock name (may include up to 2 %d specifiers) */
> +	int32_t  type;       /* LOCKPROF_TYPE_??? */
> +	int32_t  idx;        /* index (e.g. domain id) */
> +	uint64_aligned_t lock_cnt;     /* # of locking succeeded */
> +	uint64_aligned_t block_cnt;    /* # of wait for lock */
> +	uint64_aligned_t lock_time;    /* nsecs lock held */
> +	uint64_aligned_t block_time;   /* nsecs waited for lock */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
> +
> +struct xen_sysctl_lockprof_op {
> +	/* IN variables. */
> +	uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
> +	uint32_t       max_elem;          /* size of output buffer */
> +	/* OUT variables (query only). */
> +	uint32_t       nr_elem;           /* number of elements available */
> +	uint64_aligned_t time;            /* nsecs of profile measurement */
> +	/* profile information (or NULL) */
> +	GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
> +
> +/* XEN_SYSCTL_topologyinfo */
> +#define INVALID_TOPOLOGY_ID  (~0U)
> +struct xen_sysctl_topologyinfo {
> +	/*
> +	 * IN: maximum addressable entry in the caller-provided arrays.
> +	 * OUT: largest cpu identifier in the system.
> +	 * If OUT is greater than IN then the arrays are truncated!
> +	 * If OUT is leass than IN then the array tails are not written by
> +	 * sysctl.
> +	 */
> +	uint32_t max_cpu_index;
> +
> +	/*
> +	 * If not NULL, these arrays are filled with core/socket/node identifier
> +	 * for each cpu.
> +	 * If a cpu has no core/socket/node information (e.g., cpu not present)
> +	 * then the sentinel value ~0u is written to each array.
> +	 * The number of array elements written by the sysctl is:
> +	 *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
> +	 */
> +	GUEST_HANDLE_64(uint32_t) cpu_to_core;
> +	GUEST_HANDLE_64(uint32_t) cpu_to_socket;
> +	GUEST_HANDLE_64(uint32_t) cpu_to_node;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
> +
> +/* XEN_SYSCTL_numainfo */
> +#define INVALID_NUMAINFO_ID (~0U)
> +struct xen_sysctl_numainfo {
> +	/*
> +	 * IN: maximum addressable entry in the caller-provided arrays.
> +	 * OUT: largest node identifier in the system.
> +	 * If OUT is greater than IN then the arrays are truncated!
> +	 */
> +	uint32_t max_node_index;
> +
> +	/* NB. Entries are 0 if node is not present. */
> +	GUEST_HANDLE_64(uint64_t) node_to_memsize;
> +	GUEST_HANDLE_64(uint64_t) node_to_memfree;
> +
> +	/*
> +	 * Array, of size (max_node_index+1)^2, listing memory access distances
> +	 * between nodes. If an entry has no node distance information (e.g., node
> +	 * not present) then the value ~0u is written.
> +	 *
> +	 * Note that the array rows must be indexed by multiplying by the minimum
> +	 * of the caller-provided max_node_index and the returned value of
> +	 * max_node_index. That is, if the largest node index in the system is
> +	 * smaller than the caller can handle, a smaller 2-d array is constructed
> +	 * within the space provided by the caller. When this occurs, trailing
> +	 * space provided by the caller is not modified. If the largest node index
> +	 * in the system is larger than the caller can handle, then a 2-d array of
> +	 * the maximum size handleable by the caller is constructed.
> +	 */
> +	GUEST_HANDLE_64(uint32_t) node_to_node_distance;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
> +
> +/* XEN_SYSCTL_cpupool_op */
> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
> +struct xen_sysctl_cpupool_op {
> +	uint32_t op;          /* IN */
> +	uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
> +	uint32_t sched_id;    /* IN: C      OUT: I  */
> +	uint32_t domid;       /* IN: M              */
> +	uint32_t cpu;         /* IN: AR             */
> +	uint32_t n_dom;       /*            OUT: I  */
> +	struct xenctl_bitmap cpumap; /*     OUT: IF */
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
> +
> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
> +/*
> + * This structure is used to pass a new ARINC653 schedule from a
> + * privileged domain (ie dom0) to Xen.
> + */
> +struct xen_sysctl_arinc653_schedule {
> +	/* major_frame holds the time for the new schedule's major frame
> +	* in nanoseconds. */
> +	uint64_aligned_t     major_frame;
> +	/* num_sched_entries holds how many of the entries in the
> +	* sched_entries[] array are valid. */
> +	uint8_t     num_sched_entries;
> +	/* The sched_entries array holds the actual schedule entries. */
> +	struct {
> +		/* dom_handle must match a domain's UUID */
> +		xen_domain_handle_t dom_handle;
> +		/*
> +		 * If a domain has multiple VCPUs, vcpu_id specifies which one
> +		 * this schedule entry applies to. It should be set to 0 if
> +		 * there is only one VCPU for the domain. */
> +		unsigned int vcpu_id;
> +		/*
> +		 * runtime specifies the amount of time that should be allocated
> +		 * to this VCPU per major frame. It is specified in nanoseconds
> +		 */
> +		uint64_aligned_t runtime;
> +	} sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
> +
> +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;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
> +
> +/* XEN_SYSCTL_scheduler_op */
> +/* Set or get info? */
> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
> +struct xen_sysctl_scheduler_op {
> +	uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
> +	uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
> +	uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
> +	union {
> +		struct xen_sysctl_sched_arinc653 {
> +			GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
> +		} sched_arinc653;
> +		struct xen_sysctl_credit_schedule sched_credit;
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
> +
> +/* XEN_SYSCTL_coverage_op */
> +/*
> + * Get total size of information, to help allocate
> + * the buffer. The pointer points to a 32 bit value.
> + */
> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
> +
> +/*
> + * Read coverage information in a single run
> + * You must use a tool to split them.
> + */
> +#define XEN_SYSCTL_COVERAGE_read           1
> +
> +/*
> + * Reset all the coverage counters to 0
> + * No parameters.
> + */
> +#define XEN_SYSCTL_COVERAGE_reset          2
> +
> +/*
> + * Like XEN_SYSCTL_COVERAGE_read but reset also
> + * counters to 0 in a single call.
> + */
> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
> +
> +struct xen_sysctl_coverage_op {
> +	uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
> +	union {
> +		uint32_t total_size; /* OUT */
> +		GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
> +
> +
> +struct xen_sysctl {
> +	uint32_t cmd;
> +#define XEN_SYSCTL_readconsole                    1
> +#define XEN_SYSCTL_tbuf_op                        2
> +#define XEN_SYSCTL_physinfo                       3
> +#define XEN_SYSCTL_sched_id                       4
> +#define XEN_SYSCTL_perfc_op                       5
> +#define XEN_SYSCTL_debug_keys                     7
> +#define XEN_SYSCTL_getcpuinfo                     8
> +#define XEN_SYSCTL_availheap                      9
> +#define XEN_SYSCTL_get_pmstat                    10
> +#define XEN_SYSCTL_cpu_hotplug                   11
> +#define XEN_SYSCTL_pm_op                         12
> +#define XEN_SYSCTL_page_offline_op               14
> +#define XEN_SYSCTL_lockprof_op                   15
> +#define XEN_SYSCTL_topologyinfo                  16
> +#define XEN_SYSCTL_numainfo                      17
> +#define XEN_SYSCTL_cpupool_op                    18
> +#define XEN_SYSCTL_scheduler_op                  19
> +#define XEN_SYSCTL_coverage_op                   20
> +	uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
> +	union {
> +		struct xen_sysctl_readconsole       readconsole;
> +		struct xen_sysctl_tbuf_op           tbuf_op;
> +		struct xen_sysctl_physinfo          physinfo;
> +		struct xen_sysctl_topologyinfo      topologyinfo;
> +		struct xen_sysctl_numainfo          numainfo;
> +		struct xen_sysctl_sched_id          sched_id;
> +		struct xen_sysctl_perfc_op          perfc_op;
> +		struct xen_sysctl_debug_keys        debug_keys;
> +		struct xen_sysctl_getcpuinfo        getcpuinfo;
> +		struct xen_sysctl_availheap         availheap;
> +		struct xen_sysctl_get_pmstat        get_pmstat;
> +		struct xen_sysctl_cpu_hotplug       cpu_hotplug;
> +		struct xen_sysctl_pm_op             pm_op;
> +		struct xen_sysctl_page_offline_op   page_offline;
> +		struct xen_sysctl_lockprof_op       lockprof_op;
> +		struct xen_sysctl_cpupool_op        cpupool_op;
> +		struct xen_sysctl_scheduler_op      scheduler_op;
> +		struct xen_sysctl_coverage_op       coverage_op;
> +		uint8_t                             pad[128];
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
> +
> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */

We usually only introduce what we need from Xen header files in Linux:
do not copy the entirety of sysctl.h, just introduce what you need.


> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 53ec416..cf64566 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -57,6 +57,7 @@
>  #define __HYPERVISOR_event_channel_op     32
>  #define __HYPERVISOR_physdev_op           33
>  #define __HYPERVISOR_hvm_op               34
> +#define __HYPERVISOR_sysctl               35
>  #define __HYPERVISOR_tmem_op              38
>  
>  /* Architecture-specific hypercall definitions. */
> @@ -526,6 +527,11 @@ struct tmem_op {
>  
>  DEFINE_GUEST_HANDLE(u64);
>  
> +struct xenctl_bitmap {
> +	GUEST_HANDLE_64(uint8_t) bitmap;
> +	uint32_t nr_bits;
> +};
> +
>  #else /* __ASSEMBLY__ */
>  
>  /* In assembly code we cannot use C numeric constant suffixes. */
> -- 
> 1.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:19:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1Xlgpe-00081b-Kr; Tue, 04 Nov 2014 16:19:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xlgpd-00081L-9e
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:19:45 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	67/D1-17735-0ACF8545; Tue, 04 Nov 2014 16:19:44 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415117979!11596677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19410 invoked from network); 4 Nov 2014 16:19:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 16:19:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189355271"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:17:38 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlgjJ-0001XF-8c;
	Tue, 04 Nov 2014 16:13:13 +0000
Date: Tue, 4 Nov 2014 16:13:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106521-3115-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041612330.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 10/11] cpufreq: add hwdom-cpufreq
	driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> This driver uses hwdom to change frequencies on CPUs
> Workflow:
>  * cpufreq governor driver in Xen wants to change the
>    frequency of the physical CPU
>  * hwdom-cpufreq driver sets parameters in the shared
>    memory
>  * hwdom-cpufreq driver sends an VIRQ_CPUFREQ interrupt
>    to notify the hardware domain
>  * cpufreq driver in the hardware domain reads parameters
>    from the shared memory, changes frequency and copies
>    the result of the operation to the shared memory
> 
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> ---
>  xen/Rules.mk                        |   1 +
>  xen/drivers/cpufreq/Makefile        |   1 +
>  xen/drivers/cpufreq/hwdom-cpufreq.c | 252 ++++++++++++++++++++++++++++++++++++
>  xen/include/public/xen.h            |   1 +
>  4 files changed, 255 insertions(+)
>  create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 3b0b89b..cccbc72 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>  CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
> +CFLAGS-$(HAS_HWDOM_CPUFREQ) += -DHAS_HWDOM_CPUFREQ
>  CFLAGS-$(HAS_PM)        += -DHAS_PM
>  CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
>  CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
> diff --git a/xen/drivers/cpufreq/Makefile b/xen/drivers/cpufreq/Makefile
> index b87d127..891997c 100644
> --- a/xen/drivers/cpufreq/Makefile
> +++ b/xen/drivers/cpufreq/Makefile
> @@ -2,3 +2,4 @@ obj-y += cpufreq.o
>  obj-y += cpufreq_ondemand.o
>  obj-y += cpufreq_misc_governors.o
>  obj-y += utility.o
> +obj-$(HAS_HWDOM_CPUFREQ) += hwdom-cpufreq.o
> diff --git a/xen/drivers/cpufreq/hwdom-cpufreq.c b/xen/drivers/cpufreq/hwdom-cpufreq.c
> new file mode 100644
> index 0000000..a39fc6c
> --- /dev/null
> +++ b/xen/drivers/cpufreq/hwdom-cpufreq.c
> @@ -0,0 +1,252 @@
> +/*
> + *  Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
> + *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
> + *  Copyright (C) 2002 - 2004 Dominik Brodowski <linux@brodo.de>
> + *  Copyright (C) 2006        Denis Sadykov <denis.m.sadykov@intel.com>
> + *
> + *  Feb 2008 - Liu Jinsong <jinsong.liu@intel.com>
> + *      porting acpi-cpufreq.c from Linux 2.6.23 to Xen hypervisor
> + *
> + *  Copyright (C) 2014 GlobalLogic Inc.
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or (at
> + *  your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful, but
> + *  WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + *  General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, write to the Free Software Foundation, Inc.,
> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +#include <xen/types.h>
> +#include <xen/errno.h>
> +#include <xen/sched.h>
> +#include <xen/event.h>
> +#include <xen/irq.h>
> +#include <xen/spinlock.h>
> +#include <xen/cpufreq.h>
> +#include <xen/err.h>
> +#include <asm/shared.h>
> +#include <asm/current.h>
> +#include <asm/system.h>
> +
> +struct hwdom_cpufreq_data {
> +    struct processor_performance *perf_data;
> +    struct cpufreq_frequency_table *freq_table;
> +};
> +
> +static struct hwdom_cpufreq_data *hwdom_cpufreq_drv_data[NR_CPUS];
> +
> +int cpufreq_cpu_init(unsigned int cpuid)
> +{
> +    return cpufreq_add_cpu(cpuid);
> +}
> +
> +static void notify_cpufreq_domain(void)
> +{
> +    send_global_virq(VIRQ_CPUFREQ);
> +}
> +
> +static int hwdom_cpufreq_verify(struct cpufreq_policy *policy)
> +{
> +    struct hwdom_cpufreq_data *data;
> +    struct processor_performance *perf;
> +
> +    if ( !policy || !(data = hwdom_cpufreq_drv_data[policy->cpu]) ||
> +         !processor_pminfo[policy->cpu] )
> +        return -EINVAL;
> +
> +    perf = &processor_pminfo[policy->cpu]->perf;
> +
> +    cpufreq_verify_within_limits(policy, 0,
> +        perf->states[perf->platform_limit].core_frequency * 1000);
> +
> +    return cpufreq_frequency_table_verify(policy, data->freq_table);
> +}
> +
> +static int hwdom_cpufreq_target(struct cpufreq_policy *policy,
> +                               unsigned int target_freq, unsigned int relation)
> +{
> +    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
> +    struct processor_performance *perf;
> +    struct cpufreq_freqs freqs;
> +    struct cpufreq_sh_info *cpufreq_info;
> +    cpumask_t online_policy_cpus;
> +    unsigned int next_state = 0; /* Index into freq_table */
> +    unsigned int next_perf_state = 0; /* Index into perf table */
> +    unsigned int j;
> +    int ret = 0;
> +
> +    if ( unlikely(data == NULL ||
> +         data->perf_data == NULL || data->freq_table == NULL) )
> +        return -ENODEV;
> +
> +    perf = data->perf_data;
> +    ret = cpufreq_frequency_table_target(policy,
> +                                         data->freq_table,
> +                                         target_freq,
> +                                         relation, &next_state);
> +    if ( unlikely(ret) )
> +        return -ENODEV;
> +
> +    cpumask_and(&online_policy_cpus, &cpu_online_map, policy->cpus);
> +
> +    next_perf_state = data->freq_table[next_state].index;
> +    if ( perf->state == next_perf_state )
> +    {
> +        if ( unlikely(policy->resume) )
> +            policy->resume = 0;
> +        else
> +            return 0;
> +    }
> +
> +    freqs.old = perf->states[perf->state].core_frequency * 1000;
> +    freqs.new = data->freq_table[next_state].frequency;
> +
> +     /* Do send cmd for Hardware domain */
> +    cpufreq_info = arch_get_cpufreq_addr(dom0);
> +
> +    /* Set previous result in the Hardware domain then read it */
> +    smp_rmb();
> +
> +     /* return previous result */
> +    ret = cpufreq_info->result;

What if the previous command hasn't completed yet?


> +    cpufreq_info->cpu = policy->cpu;
> +    cpufreq_info->freq = freqs.new;
> +    cpufreq_info->relation = (uint32_t)relation;
> +
> +    smp_wmb(); /* above must be visible before notify_cpufreq_domain() */
> +
> +    notify_cpufreq_domain();
> +
> +    for_each_cpu( j, &online_policy_cpus )
> +        cpufreq_statistic_update(j, perf->state, next_perf_state);
> +
> +    perf->state = next_perf_state;
> +    policy->cur = freqs.new;
> +
> +    return ret;
> +}
> +
> +static int
> +hwdom_cpufreq_cpu_init(struct cpufreq_policy *policy)
> +{
> +    struct processor_performance *perf;
> +    struct hwdom_cpufreq_data *data;
> +    unsigned int cpu = policy->cpu;
> +    unsigned int valid_states = 0;
> +    int i;
> +    int ret = 0;
> +
> +    data = xzalloc(struct hwdom_cpufreq_data);
> +    if ( !data )
> +        return -ENOMEM;
> +
> +    hwdom_cpufreq_drv_data[cpu] = data;
> +
> +    data->perf_data = &processor_pminfo[cpu]->perf;
> +
> +    perf = data->perf_data;
> +    policy->shared_type = perf->shared_type;
> +
> +    data->freq_table = xmalloc_array(struct cpufreq_frequency_table,
> +                                     (perf->state_count+1));
> +    if ( !data->freq_table )
> +    {
> +        ret = -ENOMEM;
> +        goto err_unreg;
> +    }
> +
> +    /* detect transition latency */
> +    policy->cpuinfo.transition_latency = 0;
> +    for ( i = 0; i < perf->state_count; i++ )
> +    {
> +        if ( (perf->states[i].transition_latency * 1000) >
> +             policy->cpuinfo.transition_latency )
> +            policy->cpuinfo.transition_latency =
> +                perf->states[i].transition_latency * 1000;
> +    }
> +
> +    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
> +
> +    /* table init */
> +    for ( i = 0; i < perf->state_count; i++ )
> +    {
> +        if ( i > 0 && perf->states[i].core_frequency >=
> +            data->freq_table[valid_states-1].frequency / 1000 )
> +            continue;
> +
> +        data->freq_table[valid_states].index = i;
> +        data->freq_table[valid_states].frequency =
> +            perf->states[i].core_frequency * 1000;
> +        valid_states++;
> +    }
> +    data->freq_table[valid_states].frequency = CPUFREQ_TABLE_END;
> +    perf->state = 0;
> +
> +    ret = cpufreq_frequency_table_cpuinfo(policy, data->freq_table);
> +    if ( ret )
> +        goto err_freqfree;
> +
> +
> +    /*
> +     * the first call to ->target() should result in us actually
> +     * send command to the Hardware domain to set frequency.
> +     */
> +    policy->resume = 1;
> +
> +    /* Set the minimal frequency */
> +    return hwdom_cpufreq_target(policy, policy->min, CPUFREQ_RELATION_L);
> +
> + err_freqfree:
> +    xfree(data->freq_table);
> + err_unreg:
> +    xfree(data);
> +    hwdom_cpufreq_drv_data[cpu] = NULL;
> +
> +    return ret;
> +}
> +
> +static int hwdom_cpufreq_cpu_exit(struct cpufreq_policy *policy)
> +{
> +    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
> +
> +    if ( data )
> +    {
> +        hwdom_cpufreq_drv_data[policy->cpu] = NULL;
> +        xfree(data->freq_table);
> +        xfree(data);
> +    }
> +
> +    return 0;
> +}
> +
> +static struct cpufreq_driver hwdom_cpufreq_driver = {
> +    .name   = "hwdom-cpufreq",
> +    .verify = hwdom_cpufreq_verify,
> +    .target = hwdom_cpufreq_target,
> +    .init   = hwdom_cpufreq_cpu_init,
> +    .exit   = hwdom_cpufreq_cpu_exit,
> +};
> +
> +static int __init hwdom_cpufreq_driver_init(void)
> +{
> +    int ret = 0;
> +
> +    if ( cpufreq_controller == FREQCTL_xen )
> +        ret = cpufreq_register_driver(&hwdom_cpufreq_driver);
> +
> +    return ret;
> +}
> +
> +__initcall(hwdom_cpufreq_driver_init);
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 8c5697e..abd8438 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -160,6 +160,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>  #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       */
> +#define VIRQ_CPUFREQ    14 /* G. (DOM0) Notify cpufreq driver                */
>  
>  /* Architecture-specific VIRQ definitions. */
>  #define VIRQ_ARCH_0    16
> -- 
> 1.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:19:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:19:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlgpq-00086a-Oe; Tue, 04 Nov 2014 16:19:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xlgpo-00085Y-W0
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:19:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F7/B8-09936-CACF8545; Tue, 04 Nov 2014 16:19:56 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415117992!12169686!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4421 invoked from network); 4 Nov 2014 16:19:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 16:19:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189355500"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:18:03 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlgnz-00021L-Ne;
	Tue, 04 Nov 2014 16:18:03 +0000
Date: Tue, 4 Nov 2014 16:17:57 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>

Why?


>  arch/arm/include/asm/xen/hypercall.h | 1 +
>  arch/arm/xen/enlighten.c             | 1 +
>  arch/arm/xen/hypercall.S             | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> index 751869eb..383c174 100644
> --- a/arch/arm/include/asm/xen/hypercall.h
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>  int HYPERVISOR_tmem_op(void *arg);
> +int HYPERVISOR_dom0_op(void *arg);
>  int HYPERVISOR_sysctl(void *arg);
>  
>  static inline void
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 675f17a..f757c57 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>  EXPORT_SYMBOL_GPL(privcmd_call);
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index a1276df..99e2254 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>  HYPERCALL2(physdev_op);
>  HYPERCALL3(vcpu_op);
>  HYPERCALL1(tmem_op);
> +HYPERCALL1(dom0_op);
>  HYPERCALL1(sysctl);
>  
>  ENTRY(privcmd_call)
> -- 
> 1.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:19:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:19:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlgpq-00086a-Oe; Tue, 04 Nov 2014 16:19:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xlgpo-00085Y-W0
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:19:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F7/B8-09936-CACF8545; Tue, 04 Nov 2014 16:19:56 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415117992!12169686!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4421 invoked from network); 4 Nov 2014 16:19:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 16:19:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189355500"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:18:03 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlgnz-00021L-Ne;
	Tue, 04 Nov 2014 16:18:03 +0000
Date: Tue, 4 Nov 2014 16:17:57 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>

Why?


>  arch/arm/include/asm/xen/hypercall.h | 1 +
>  arch/arm/xen/enlighten.c             | 1 +
>  arch/arm/xen/hypercall.S             | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> index 751869eb..383c174 100644
> --- a/arch/arm/include/asm/xen/hypercall.h
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>  int HYPERVISOR_tmem_op(void *arg);
> +int HYPERVISOR_dom0_op(void *arg);
>  int HYPERVISOR_sysctl(void *arg);
>  
>  static inline void
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 675f17a..f757c57 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>  EXPORT_SYMBOL_GPL(privcmd_call);
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index a1276df..99e2254 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>  HYPERCALL2(physdev_op);
>  HYPERCALL3(vcpu_op);
>  HYPERCALL1(tmem_op);
> +HYPERCALL1(dom0_op);
>  HYPERCALL1(sysctl);
>  
>  ENTRY(privcmd_call)
> -- 
> 1.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:22:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:22:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlgs8-00009Q-FX; Tue, 04 Nov 2014 16:22:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xlgs6-000098-Uj
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:22:19 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	19/A8-08051-A3DF8545; Tue, 04 Nov 2014 16:22:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415118134!12535413!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29473 invoked from network); 4 Nov 2014 16:22:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 16:22:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189356872"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:20:15 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlgq6-000273-Vm;
	Tue, 04 Nov 2014 16:20:14 +0000
Date: Tue, 4 Nov 2014 16:20:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106572-3178-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041618420.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 5/9] cpufreq: cpufreq-cpu0: change
 cpus data path in devtree for hwdom kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> All information needed for this driver about physical cpus
> now located in /hypervisor/pcpus node instead of the
> /cpus node in case if kernel is running as hardware domain.
> 
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> ---
>  drivers/cpufreq/cpufreq-cpu0.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index ef4fbc4..a83838b 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -21,6 +21,8 @@
>  #include <linux/regulator/consumer.h>
>  #include <linux/slab.h>
>  
> +#include <xen/xen.h>
> +
>  static unsigned int transition_latency;
>  static unsigned int voltage_tolerance; /* in percentage */
>  
> @@ -182,7 +184,13 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
>  	struct device_node *np;
>  	int ret;
>  
> -	np = of_find_node_by_path("/cpus/cpu@0");
> +#ifdef CONFIG_XEN_DOM0

the #ifdef is not necessary, xen_initial_domain() is always properly
defined


> +	if (xen_initial_domain())
> +		np = of_find_node_by_path("/hypervisor/pcpus/cpu@0");
> +	else
> +#endif
> +		np = of_find_node_by_path("/cpus/cpu@0");
>  	if (!np) {
>  		pr_err("failed to find cpu0 node\n");
>  		return -ENOENT;
> -- 
> 1.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:22:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:22:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlgs8-00009Q-FX; Tue, 04 Nov 2014 16:22:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xlgs6-000098-Uj
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:22:19 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	19/A8-08051-A3DF8545; Tue, 04 Nov 2014 16:22:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415118134!12535413!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29473 invoked from network); 4 Nov 2014 16:22:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 16:22:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="189356872"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:20:15 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlgq6-000273-Vm;
	Tue, 04 Nov 2014 16:20:14 +0000
Date: Tue, 4 Nov 2014 16:20:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106572-3178-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041618420.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 5/9] cpufreq: cpufreq-cpu0: change
 cpus data path in devtree for hwdom kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> All information needed for this driver about physical cpus
> now located in /hypervisor/pcpus node instead of the
> /cpus node in case if kernel is running as hardware domain.
> 
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> ---
>  drivers/cpufreq/cpufreq-cpu0.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index ef4fbc4..a83838b 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -21,6 +21,8 @@
>  #include <linux/regulator/consumer.h>
>  #include <linux/slab.h>
>  
> +#include <xen/xen.h>
> +
>  static unsigned int transition_latency;
>  static unsigned int voltage_tolerance; /* in percentage */
>  
> @@ -182,7 +184,13 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
>  	struct device_node *np;
>  	int ret;
>  
> -	np = of_find_node_by_path("/cpus/cpu@0");
> +#ifdef CONFIG_XEN_DOM0

the #ifdef is not necessary, xen_initial_domain() is always properly
defined


> +	if (xen_initial_domain())
> +		np = of_find_node_by_path("/hypervisor/pcpus/cpu@0");
> +	else
> +#endif
> +		np = of_find_node_by_path("/cpus/cpu@0");
>  	if (!np) {
>  		pr_err("failed to find cpu0 node\n");
>  		return -ENOENT;
> -- 
> 1.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:32:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlh1j-0000gE-8u; Tue, 04 Nov 2014 16:32:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xlh1i-0000g7-7E
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:32:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	61/3E-09936-D8FF8545; Tue, 04 Nov 2014 16:32:13 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415118729!5443021!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15030 invoked from network); 4 Nov 2014 16:32:10 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-21.messagelabs.com with SMTP;
	4 Nov 2014 16:32:10 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 04 Nov 2014 08:29:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,313,1413270000"; d="scan'208";a="602077317"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 04 Nov 2014 08:31:48 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 00:31:47 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.13]) with mapi id
	14.03.0195.001; Wed, 5 Nov 2014 00:31:46 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP91zOKlhH4xypD06jTqC2+4O7eZxQng+g
Date: Tue, 4 Nov 2014 16:31:46 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Monday, November 03, 2014 7:54 PM
> To: Xu, Quan
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> stefano.stabellini@eu.citrix.com
> Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> On Sun, 2 Nov 2014, Quan Xu wrote:
> > This drvier transfers any request/repond between TPM xenstubdoms
> > driver and Xen vTPM stubdom, and facilitates communications between
> > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> 
> Please describe what changes did make to xen_backend.c and why.
> The commit message should contains info on all the changes made by the
> patch below.
> 
	
Thanks Stefano. 
one more day, I will explain in detail what changes did make to xen_backend.c 
and why. 
The following 2 sections are introduction and architecture. 

> Please also describe what is the "Xen vTPM stubdom", what is the
> "vTPM xenstubdoms driver" and how the communicate with each others.
> 


Add 2 parts for detailed descriptions, introduction and architecture.  

*INTRODUCTION*

The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality
to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to
interact with a TPM in a virtual machine the same way they interact with a TPM on the
physical system. Each virtual machine gets its own unique, emulated, software TPM.
Each major component of vTPM is implemented as a stubdom, providing secure separation
guaranteed by the hypervisor.
The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine
to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed
from mini-os TPM backend driver.
This patch series are only the Qemu part to enable Xen stubdom vTPM for HVM virtual
machine.
===========

*ARCHITECTURE*

The architecture of stubdom vTPM for HVM virtual machine:

            +--------------------+
            | Windows/Linux DomU | ...
            |        |  ^        |
            |        v  |        |
            |  Qemu tpm1.2 Tis   |
            |        |  ^        |
            |        v  |        |
            |        vTPM        |
            | XenStubdoms driver |  (new ..)
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |  xen_vtpmdev_ops   |  (new ..)
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |  mini-os/tpmback   |
            |        |  ^        |
            |        v  |        |
            |   vTPM stubdom     | ...
            |        |  ^        |
            |        v  |        |
            |  mini-os/tpmfront  |
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |  mini-os/tpmback   |
            |        |  ^        |
            |        v  |        |
            |  vtpmmgr stubdom   |
            |        |  ^        |
            |        v  |        |
            |  mini-os/tpm_tis   |
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |    Hardware TPM    |
            +--------------------+


* Windows/Linux DomU:
    The HVM based guest that wants to use a vTPM. There may be
    more than one of these.

 * Qemu tpm1.2 Tis:
    Implementation of the tpm1.2 Tis interface for HVM virtual
    machines. It is Qemu emulation device.

 * vTPM xenstubdoms driver:
    Similar to a TPM passthrough backend driver, it is a new TPM
    backend for emulated TPM TIS interface. This driver provides
    vTPM initialization and sending data and commends to a Xen
    vTPM stubdom.

 * xen_vtpmdev_ops:
    Register Xen stubdom vTPM backend, and transfer any request/
    repond between TPM xenstubdoms driver and Xen vTPM stubdom.
    Facilitate communications between Xen vTPM stubdom and vTPM
    xenstubdoms driver.

 * mini-os/tpmback:
    Mini-os TPM backend driver. The Linux frontend driver connects
    to this backend driver to facilitate communications between the
    Linux DomU and its vTPM. This driver is also used by vtpmmgr
    stubdom to communicate with vTPM stubdom.

 * vTPM stubdom:
    A mini-os stub domain that implements a vTPM. There is a
    one to one mapping between running vTPM stubdom instances and
    logical vTPMs on the system. The vTPM Platform Configuration
    Registers (PCRs) are all initialized to zero.

 * mini-os/tpmfront:
    Mini-os TPM frontend driver. The vTPM mini-os domain vTPM
    stubdom uses this driver to communicate with vtpmmgr-stubdom.
    This driver could also be used separately to implement a mini-os
    domain that wishes to use a vTPM of its own.

 * vtpmmgr stubdom:
    A mini-os domain that implements the vTPM manager. There is only
    one vTPM manager and it should be running during the entire lifetime
    of the machine. vtpmmgr domain securely stores encryption keys for
    each of the vTPMs and accesses to the hardware TPM to get the root of
    trust for the entire system.

 * mini-os/tpm_tis:
    Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
    This driver used by vtpmmgr-stubdom to talk directly to the hardware
    TPM. Communication is facilitated by mapping hardware memory pages
    into vtpmmgr stubdom.

 * Hardware TPM:
    The physical TPM 1.2 that is soldered onto the motherboard.

===========



> Where does the vTPM backend lives?
The vTPM backend lives in Xen vTPM stubdom (Xen Mini-os)

> 
> 
> >  hw/xen/Makefile.objs         |   1 +
> >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> >  hw/xen/xen_stubdom_vtpm.c    | 333
> +++++++++++++++++++++++++++++++++++++++++++
> >  include/hw/xen/xen_backend.h |  11 ++
> >  include/hw/xen/xen_common.h  |   6 +
> >  xen-hvm.c                    |  13 ++
> >  6 files changed, 544 insertions(+), 2 deletions(-)
> >  create mode 100644 hw/xen/xen_stubdom_vtpm.c
> >
> > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> > index a0ca0aa..724df8d 100644
> > --- a/hw/xen/Makefile.objs
> > +++ b/hw/xen/Makefile.objs
> > @@ -1,5 +1,6 @@
> >  # xen backend driver support
> >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> xen_devconfig.o
> > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> >
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> xen_pt_config_init.o xen_pt_msi.o
> > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> > index b2cb22b..45a5778 100644
> > --- a/hw/xen/xen_backend.c
> > +++ b/hw/xen/xen_backend.c
> > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev,
> enum xenbus_state state)
> >      return 0;
> >  }
> >
> > +/*get stubdom backend*/
> > +static char *xen_stubdom_be(const char *type, int dom, int dev)
> > +{
> > +    char *val, *domu;
> > +    char path[XEN_BUFSIZE];
> > +    unsigned int len, ival;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, dom);
> > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > +             domu, type, dev);
> > +    g_free(domu);
> > +
> > +    val = xs_read(xenstore, 0, path, &len);
> > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > +        g_free(val);
> > +        return NULL;
> > +    }
> > +    g_free(val);
> > +
> > +    /*backend domu*/
> > +    domu = xs_get_domain_path(xenstore, ival);
> > +
> > +    return domu;
> > +}
> > +
> >  /* ------------------------------------------------------------- */
> >
> >  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int
> dev)
> > @@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const
> char *type, int dom, int dev,
> >                                             struct XenDevOps *ops)
> >  {
> >      struct XenDevice *xendev;
> > +    char *stub;
> >
> >      xendev = xen_be_find_xendev(type, dom, dev);
> >      if (xendev) {
> > @@ -235,8 +262,15 @@ static struct XenDevice
> *xen_be_get_xendev(const char *type, int dom, int dev,
> >      xendev->dev   = dev;
> >      xendev->ops   = ops;
> >
> > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > -             xendev->type, xendev->dom, xendev->dev);
> > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> xendev->dev);
> > +        snprintf(xendev->be, sizeof(xendev->be),
> "%s/backend/%s/%d/%d",
> > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > +        g_free(stub);
> > +    } else {
> > +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > +                 xendev->type, xendev->dom, xendev->dev);
> > +    }
> >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> >               xendev->type, xendev->dev);
> >
> > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int
> dom, struct XenDevOps *ops)
> >      return 0;
> >  }
> >
> > +static void stubdom_update_be(char *watch, char *type, int dom,
> > +                              struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE];
> > +    char *ptr, *bepath;
> > +    unsigned int len, dev;
> > +
> > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > +        return;
> > +    }
> > +
> > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > +    ptr = strstr(watch, path);
> > +    if (ptr == NULL) {
> > +        return;
> > +    }
> > +
> > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > +        strcpy(path, "");
> > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > +            dev = -1;
> > +        }
> > +    }
> > +
> > +    if (dev == -1) {
> > +        return;
> > +    }
> > +
> > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > +    if (xendev != NULL) {
> > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > +        if (bepath == NULL) {
> > +            xen_be_del_xendev(dom, dev);
> > +        } else {
> > +            free(bepath);
> > +            xen_be_backend_changed(xendev, path);
> > +        }
> > +    }
> > +}
> > +
> >  static void xenstore_update_be(char *watch, char *type, int dom,
> >                                 struct XenDevOps *ops)
> >  {
> > @@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
> >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> >      }
> > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> PRIxPTR,
> > +               &type, &dom, &ops) == 3) {
> > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom,
> (void *)ops);
> > +    }
> >
> >  cleanup:
> >      free(vec);
> > @@ -732,11 +811,74 @@ err:
> >      return -1;
> >  }
> >
> > +int xen_vtpm_register(struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > +    char *domu;
> > +    unsigned int cdev, j, rc;
> > +    const char *type = "vtpm";
> > +    char **dev = NULL;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > +    snprintf(path, sizeof(path), "%s/device/%s",
> > +             domu, type);
> > +    free(domu);
> > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > +    if (dev == NULL) {
> > +        return 0;
> > +    }
> > +
> > +    for (j = 0; j < cdev; j++) {
> > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> ops);
> > +        if (xendev == NULL) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> NULL.\n");
> > +            continue;
> > +        }
> > +
> > +        if (xendev->ops->initialise) {
> > +            rc = xendev->ops->initialise(xendev);
> > +
> > +            /*if initialise failed, delete it*/
> > +            if (rc != 0) {
> > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > +                continue;
> > +            }
> > +        }
> > +
> > +        /*setup watch*/
> > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > +                 type, xen_domid, xendev->ops);
> > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> failed.\n");
> > +            return -1;
> > +        }
> > +    }
> > +
> > +    free(dev);
> > +    return 0;
> > +}
> 
> What does this function do? I sholdn't need  to guess from the code, I
> should be able to tell from the patch description.
> 
> 
> >  int xen_be_register(const char *type, struct XenDevOps *ops)
> >  {
> >      return xenstore_scan(type, xen_domid, ops);
> >  }
> >
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom)
> > +{
> > +    xendev->local_port =
> xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > +
> remote_dom);
> > +    if (xendev->local_port == -1) {
> > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> > +        return -1;
> > +    }
> > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> xendev->local_port);
> > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > +                        xen_be_evtchn_event, NULL, xendev);
> > +    return 0;
> > +}
> > +
> >  int xen_be_bind_evtchn(struct XenDevice *xendev)
> >  {
> >      if (xendev->local_port != -1) {
> > @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice
> *xendev)
> >      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
> >  }
> >
> > +int xen_vtpm_send(unsigned char *buf, size_t count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->send) {
> > +        rc = xendev->ops->send(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> > +
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->recv) {
> > +        xendev->ops->recv(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> 
> xen_backend.c is supposed to be generic, so stubdom functions might be
> OK but vtpm specific functions should not be here.
> 
> 
> >  /*
> >   * msg_level:
> >   *  0 == errors (stderr + logfile).
> > diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> > new file mode 100644
> > index 0000000..0d740c1
> > --- /dev/null
> > +++ b/hw/xen/xen_stubdom_vtpm.c
> > @@ -0,0 +1,333 @@
> > +/*
> > + * Connect to Xen vTPM stubdom domain
> > + *
> > + *  Copyright (c) 2014 Intel Corporation
> > + *  Authors:
> > + *    Quan Xu <quan.xu@intel.com>
> > + *
> > + * 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 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, see
> <http://www.gnu.org/licenses/>
> > + */
> > +
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <stdarg.h>
> > +#include <string.h>
> > +#include <unistd.h>
> > +#include <signal.h>
> > +#include <inttypes.h>
> > +#include <time.h>
> > +#include <fcntl.h>
> > +#include <errno.h>
> > +#include <sys/ioctl.h>
> > +#include <sys/types.h>
> > +#include <sys/stat.h>
> > +#include <sys/mman.h>
> > +#include <sys/uio.h>
> > +
> > +#include "hw/hw.h"
> > +#include "block/aio.h"
> > +#include "hw/xen/xen_backend.h"
> > +
> > +enum tpmif_state {
> > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> complete */
> > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> > +};
> > +
> > +static AioContext *vtpm_aio_ctx;
> > +
> > +enum status_bits {
> > +    VTPM_STATUS_RUNNING  = 0x1,
> > +    VTPM_STATUS_IDLE     = 0x2,
> > +    VTPM_STATUS_RESULT   = 0x4,
> > +    VTPM_STATUS_CANCELED = 0x8,
> > +};
> > +
> > +struct tpmif_shared_page {
> > +    uint32_t length;         /* request/response length in bytes */
> > +
> > +    uint8_t  state;           /* enum tpmif_state */
> > +    uint8_t  locality;        /* for the current request */
> > +    uint8_t  pad;             /* should be zero */
> > +
> > +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be
> zero */
> > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> nr_extra_pages */
> > +};
> > +
> > +struct QEMUBH {
> > +    AioContext *ctx;
> > +    QEMUBHFunc *cb;
> > +    void *opaque;
> > +    QEMUBH *next;
> > +    bool scheduled;
> > +    bool idle;
> > +    bool deleted;
> > +};
> > +
> > +struct XenVtpmDev {
> > +    struct XenDevice xendev;  /* must be first */
> > +    struct           tpmif_shared_page *shr;
> > +    xc_gntshr        *xen_xcs;
> > +    int              ring_ref;
> > +    int              bedomid;
> > +    QEMUBH           *sr_bh;
> > +};
> > +
> > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> > +{
> > +    switch (vtpmdev->shr->state) {
> > +    case TPMIF_STATE_IDLE:
> > +    case TPMIF_STATE_FINISH:
> > +        return VTPM_STATUS_IDLE;
> > +    case TPMIF_STATE_SUBMIT:
> > +    case TPMIF_STATE_CANCEL:
> > +        return VTPM_STATUS_RUNNING;
> > +    default:
> > +        return 0;
> > +    }
> > +}
> > +
> > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> xenbus_state xbus)
> > +{
> > +    xs_transaction_t xbt = XBT_NULL;
> > +
> > +    if (xendev->fe_state == xbus) {
> > +        return 0;
> > +    }
> > +
> > +    xendev->fe_state = xbus;
> > +
> > +retry_transaction:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto retry_transaction;
> > +        }
> > +    }
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static int vtpm_aio_wait(QEMUBH *qbh)
> > +{
> > +    return aio_poll(qbh->ctx, true);
> > +}
> > +
> > +static void sr_bh_handler(void *opaque)
> > +{
> > +}
> > +
> > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t
> *count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset;
> > +
> > +    if (shr->state == TPMIF_STATE_IDLE) {
> > +        return -ECANCELED;
> > +    }
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > +    *count = shr->length;
> > +
> > +    return 0;
> > +}
> > +
> > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t
> count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > +    shr->length = count;
> > +    barrier();
> > +    shr->state = TPMIF_STATE_SUBMIT;
> > +    xen_wmb();
> > +    xen_be_send_notify(&vtpmdev->xendev);
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    return count;
> > +}
> > +
> > +static int vtpm_initialise(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    xs_transaction_t xbt = XBT_NULL;
> > +    unsigned int ring_ref;
> > +
> > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> "frontend");
> > +    if (vtpmdev->xendev.fe == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /* Get backend domid */
> > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > +                             &vtpmdev->bedomid)) {
> > +        return -1;
> > +    }
> > +
> > +    /*alloc share page*/
> > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> vtpmdev->bedomid, 1,
> > +                                         &ring_ref,
> PROT_READ|PROT_WRITE);
> > +    vtpmdev->ring_ref = ring_ref;
> > +    if (vtpmdev->shr == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /*Create event channel */
> > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> vtpmdev->bedomid)) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +        return -1;
> > +    }
> > +
> > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > +                     vtpmdev->xendev.local_port);
> > +
> > +again:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > +                           vtpmdev->ring_ref)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > +                           vtpmdev->xendev.local_port)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    /* Publish protocol v2 feature */
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1))
> {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto again;
> > +        }
> > +    }
> > +    /* Tell vtpm backend that we are ready */
> > +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static void vtpm_backend_changed(struct XenDevice *xendev, const char
> *node)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    int be_state;
> > +
> > +    if (strcmp(node, "state") == 0) {
> > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > +        switch (be_state) {
> > +        case XenbusStateConnected:
> > +            /*TODO*/
> > +            break;
> > +        case XenbusStateClosing:
> > +        case XenbusStateClosed:
> > +            xenbus_switch_state(&vtpmdev->xendev,
> XenbusStateClosing);
> > +            break;
> > +        default:
> > +            break;
> > +        }
> > +    }
> > +}
> > +
> > +static int vtpm_free(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > +
> > +    aio_poll(qbh->ctx, false);
> > +    qemu_bh_delete(vtpmdev->sr_bh);
> > +    if (vtpmdev->shr) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    }
> > +    xc_interface_close(vtpmdev->xen_xcs);
> > +    return 0;
> > +}
> > +
> > +static void vtpm_alloc(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    vtpm_aio_ctx = aio_context_new(NULL);
> > +    if (vtpm_aio_ctx == NULL) {
> > +        return;
> > +    }
> > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> vtpmdev);
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> > +}
> > +
> > +static void vtpm_event(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +}
> > +
> > +struct XenDevOps xen_vtpmdev_ops = {
> > +    .size             = sizeof(struct XenVtpmDev),
> > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > +                        DEVOPS_FLAG_STUBDOM_BE,
> > +    .event            = vtpm_event,
> > +    .free             = vtpm_free,
> > +    .alloc            = vtpm_alloc,
> > +    .initialise       = vtpm_initialise,
> > +    .backend_changed  = vtpm_backend_changed,
> > +    .recv             = vtpm_recv,
> > +    .send             = vtpm_send,
> > +};
> 
> Is this the frontend, like the subject line would seem to imply?
> If so, XenDevOps are made for backends, while this is a frontend. In
> fact this is the first PV frontend in QEMU. We need to introduce
> something generic and similar to struct XenDevOps and xen_backend.c but
> for frontends.
> 
> 
> > diff --git a/include/hw/xen/xen_backend.h
> b/include/hw/xen/xen_backend.h
> > index 3b4125e..45fd6d3 100644
> > --- a/include/hw/xen/xen_backend.h
> > +++ b/include/hw/xen/xen_backend.h
> > @@ -15,6 +15,8 @@ struct XenDevice;
> >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> >  /* don't expect frontend doing correct state transitions (aka console
> quirk) */
> >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > +/*dev backend is stubdom*/
> > +#define DEVOPS_FLAG_STUBDOM_BE    4
> >
> >  struct XenDevOps {
> >      size_t    size;
> > @@ -26,6 +28,8 @@ struct XenDevOps {
> >      void      (*event)(struct XenDevice *xendev);
> >      void      (*disconnect)(struct XenDevice *xendev);
> >      int       (*free)(struct XenDevice *xendev);
> > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> count);
> > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> *count);
> >      void      (*backend_changed)(struct XenDevice *xendev, const
> char *node);
> >      void      (*frontend_changed)(struct XenDevice *xendev, const
> char *node);
> >  };
> > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> *xendev);
> >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char
> *fmt, ...)
> >      GCC_FMT_ATTR(3, 4);
> >
> > +/*Xen stubdom vtpm*/
> > +int xen_vtpm_register(struct XenDevOps *ops);
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom);
> > +int xen_vtpm_send(unsigned char *buf, size_t count);
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> > +
> >  /* actual backend drivers */
> >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> */
> >  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c
> */
> >  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
> >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> */
> >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> */
> > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> xen_stubdom_vtpm.c*/
> >
> >  void xen_init_display(int domid);
> >
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 95612a4..fb43084 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void
> *logger, void *dombuild_logger,
> >      return xc_interface_open(logger, dombuild_logger, open_flags);
> >  }
> >
> > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > +                                           unsigned int open_flags)
> > +{
> > +    return xc_gntshr_open(logger, open_flags);
> > +}
> > +
> >  /* FIXME There is now way to have the xen fd */
> >  static inline int xc_fd(xc_interface *xen_xc)
> >  {
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 21f1cbb..c99ace8 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >      int i, rc;
> >      unsigned long ioreq_pfn;
> >      unsigned long bufioreq_evtchn;
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    unsigned long stubdom_vtpm = 0;
> > +#endif
> > +
> >      XenIOState *state;
> >
> >      state = g_malloc0(sizeof (XenIOState));
> > @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >          fprintf(stderr, "%s: xen backend core setup failed\n",
> __FUNCTION__);
> >          return -1;
> >      }
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    xc_get_hvm_param(xen_xc, xen_domid,
> HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > +    if (stubdom_vtpm) {
> > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > +    }
> > +#endif
> 
> Given that vtpm is just a PV frontend, can't you just detect whether is
> present on xenstore and initialize it based on that? Like all the
> backend below?

Also I will explain in my next email. 


> 
> 
> >      xen_be_register("console", &xen_console_ops);
> >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> >      xen_be_register("qdisk", &xen_blkdev_ops);
> > --
> > 1.8.3.2
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:32:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlh1j-0000gE-8u; Tue, 04 Nov 2014 16:32:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xlh1i-0000g7-7E
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:32:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	61/3E-09936-D8FF8545; Tue, 04 Nov 2014 16:32:13 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415118729!5443021!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15030 invoked from network); 4 Nov 2014 16:32:10 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-21.messagelabs.com with SMTP;
	4 Nov 2014 16:32:10 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 04 Nov 2014 08:29:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,313,1413270000"; d="scan'208";a="602077317"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 04 Nov 2014 08:31:48 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 00:31:47 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.13]) with mapi id
	14.03.0195.001; Wed, 5 Nov 2014 00:31:46 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP91zOKlhH4xypD06jTqC2+4O7eZxQng+g
Date: Tue, 4 Nov 2014 16:31:46 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Monday, November 03, 2014 7:54 PM
> To: Xu, Quan
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> stefano.stabellini@eu.citrix.com
> Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> On Sun, 2 Nov 2014, Quan Xu wrote:
> > This drvier transfers any request/repond between TPM xenstubdoms
> > driver and Xen vTPM stubdom, and facilitates communications between
> > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> 
> Please describe what changes did make to xen_backend.c and why.
> The commit message should contains info on all the changes made by the
> patch below.
> 
	
Thanks Stefano. 
one more day, I will explain in detail what changes did make to xen_backend.c 
and why. 
The following 2 sections are introduction and architecture. 

> Please also describe what is the "Xen vTPM stubdom", what is the
> "vTPM xenstubdoms driver" and how the communicate with each others.
> 


Add 2 parts for detailed descriptions, introduction and architecture.  

*INTRODUCTION*

The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality
to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to
interact with a TPM in a virtual machine the same way they interact with a TPM on the
physical system. Each virtual machine gets its own unique, emulated, software TPM.
Each major component of vTPM is implemented as a stubdom, providing secure separation
guaranteed by the hypervisor.
The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine
to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed
from mini-os TPM backend driver.
This patch series are only the Qemu part to enable Xen stubdom vTPM for HVM virtual
machine.
===========

*ARCHITECTURE*

The architecture of stubdom vTPM for HVM virtual machine:

            +--------------------+
            | Windows/Linux DomU | ...
            |        |  ^        |
            |        v  |        |
            |  Qemu tpm1.2 Tis   |
            |        |  ^        |
            |        v  |        |
            |        vTPM        |
            | XenStubdoms driver |  (new ..)
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |  xen_vtpmdev_ops   |  (new ..)
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |  mini-os/tpmback   |
            |        |  ^        |
            |        v  |        |
            |   vTPM stubdom     | ...
            |        |  ^        |
            |        v  |        |
            |  mini-os/tpmfront  |
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |  mini-os/tpmback   |
            |        |  ^        |
            |        v  |        |
            |  vtpmmgr stubdom   |
            |        |  ^        |
            |        v  |        |
            |  mini-os/tpm_tis   |
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |    Hardware TPM    |
            +--------------------+


* Windows/Linux DomU:
    The HVM based guest that wants to use a vTPM. There may be
    more than one of these.

 * Qemu tpm1.2 Tis:
    Implementation of the tpm1.2 Tis interface for HVM virtual
    machines. It is Qemu emulation device.

 * vTPM xenstubdoms driver:
    Similar to a TPM passthrough backend driver, it is a new TPM
    backend for emulated TPM TIS interface. This driver provides
    vTPM initialization and sending data and commends to a Xen
    vTPM stubdom.

 * xen_vtpmdev_ops:
    Register Xen stubdom vTPM backend, and transfer any request/
    repond between TPM xenstubdoms driver and Xen vTPM stubdom.
    Facilitate communications between Xen vTPM stubdom and vTPM
    xenstubdoms driver.

 * mini-os/tpmback:
    Mini-os TPM backend driver. The Linux frontend driver connects
    to this backend driver to facilitate communications between the
    Linux DomU and its vTPM. This driver is also used by vtpmmgr
    stubdom to communicate with vTPM stubdom.

 * vTPM stubdom:
    A mini-os stub domain that implements a vTPM. There is a
    one to one mapping between running vTPM stubdom instances and
    logical vTPMs on the system. The vTPM Platform Configuration
    Registers (PCRs) are all initialized to zero.

 * mini-os/tpmfront:
    Mini-os TPM frontend driver. The vTPM mini-os domain vTPM
    stubdom uses this driver to communicate with vtpmmgr-stubdom.
    This driver could also be used separately to implement a mini-os
    domain that wishes to use a vTPM of its own.

 * vtpmmgr stubdom:
    A mini-os domain that implements the vTPM manager. There is only
    one vTPM manager and it should be running during the entire lifetime
    of the machine. vtpmmgr domain securely stores encryption keys for
    each of the vTPMs and accesses to the hardware TPM to get the root of
    trust for the entire system.

 * mini-os/tpm_tis:
    Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
    This driver used by vtpmmgr-stubdom to talk directly to the hardware
    TPM. Communication is facilitated by mapping hardware memory pages
    into vtpmmgr stubdom.

 * Hardware TPM:
    The physical TPM 1.2 that is soldered onto the motherboard.

===========



> Where does the vTPM backend lives?
The vTPM backend lives in Xen vTPM stubdom (Xen Mini-os)

> 
> 
> >  hw/xen/Makefile.objs         |   1 +
> >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> >  hw/xen/xen_stubdom_vtpm.c    | 333
> +++++++++++++++++++++++++++++++++++++++++++
> >  include/hw/xen/xen_backend.h |  11 ++
> >  include/hw/xen/xen_common.h  |   6 +
> >  xen-hvm.c                    |  13 ++
> >  6 files changed, 544 insertions(+), 2 deletions(-)
> >  create mode 100644 hw/xen/xen_stubdom_vtpm.c
> >
> > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> > index a0ca0aa..724df8d 100644
> > --- a/hw/xen/Makefile.objs
> > +++ b/hw/xen/Makefile.objs
> > @@ -1,5 +1,6 @@
> >  # xen backend driver support
> >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> xen_devconfig.o
> > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> >
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> xen_pt_config_init.o xen_pt_msi.o
> > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> > index b2cb22b..45a5778 100644
> > --- a/hw/xen/xen_backend.c
> > +++ b/hw/xen/xen_backend.c
> > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev,
> enum xenbus_state state)
> >      return 0;
> >  }
> >
> > +/*get stubdom backend*/
> > +static char *xen_stubdom_be(const char *type, int dom, int dev)
> > +{
> > +    char *val, *domu;
> > +    char path[XEN_BUFSIZE];
> > +    unsigned int len, ival;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, dom);
> > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > +             domu, type, dev);
> > +    g_free(domu);
> > +
> > +    val = xs_read(xenstore, 0, path, &len);
> > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > +        g_free(val);
> > +        return NULL;
> > +    }
> > +    g_free(val);
> > +
> > +    /*backend domu*/
> > +    domu = xs_get_domain_path(xenstore, ival);
> > +
> > +    return domu;
> > +}
> > +
> >  /* ------------------------------------------------------------- */
> >
> >  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int
> dev)
> > @@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const
> char *type, int dom, int dev,
> >                                             struct XenDevOps *ops)
> >  {
> >      struct XenDevice *xendev;
> > +    char *stub;
> >
> >      xendev = xen_be_find_xendev(type, dom, dev);
> >      if (xendev) {
> > @@ -235,8 +262,15 @@ static struct XenDevice
> *xen_be_get_xendev(const char *type, int dom, int dev,
> >      xendev->dev   = dev;
> >      xendev->ops   = ops;
> >
> > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > -             xendev->type, xendev->dom, xendev->dev);
> > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> xendev->dev);
> > +        snprintf(xendev->be, sizeof(xendev->be),
> "%s/backend/%s/%d/%d",
> > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > +        g_free(stub);
> > +    } else {
> > +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > +                 xendev->type, xendev->dom, xendev->dev);
> > +    }
> >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> >               xendev->type, xendev->dev);
> >
> > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int
> dom, struct XenDevOps *ops)
> >      return 0;
> >  }
> >
> > +static void stubdom_update_be(char *watch, char *type, int dom,
> > +                              struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE];
> > +    char *ptr, *bepath;
> > +    unsigned int len, dev;
> > +
> > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > +        return;
> > +    }
> > +
> > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > +    ptr = strstr(watch, path);
> > +    if (ptr == NULL) {
> > +        return;
> > +    }
> > +
> > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > +        strcpy(path, "");
> > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > +            dev = -1;
> > +        }
> > +    }
> > +
> > +    if (dev == -1) {
> > +        return;
> > +    }
> > +
> > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > +    if (xendev != NULL) {
> > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > +        if (bepath == NULL) {
> > +            xen_be_del_xendev(dom, dev);
> > +        } else {
> > +            free(bepath);
> > +            xen_be_backend_changed(xendev, path);
> > +        }
> > +    }
> > +}
> > +
> >  static void xenstore_update_be(char *watch, char *type, int dom,
> >                                 struct XenDevOps *ops)
> >  {
> > @@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
> >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> >      }
> > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> PRIxPTR,
> > +               &type, &dom, &ops) == 3) {
> > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom,
> (void *)ops);
> > +    }
> >
> >  cleanup:
> >      free(vec);
> > @@ -732,11 +811,74 @@ err:
> >      return -1;
> >  }
> >
> > +int xen_vtpm_register(struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > +    char *domu;
> > +    unsigned int cdev, j, rc;
> > +    const char *type = "vtpm";
> > +    char **dev = NULL;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > +    snprintf(path, sizeof(path), "%s/device/%s",
> > +             domu, type);
> > +    free(domu);
> > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > +    if (dev == NULL) {
> > +        return 0;
> > +    }
> > +
> > +    for (j = 0; j < cdev; j++) {
> > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> ops);
> > +        if (xendev == NULL) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> NULL.\n");
> > +            continue;
> > +        }
> > +
> > +        if (xendev->ops->initialise) {
> > +            rc = xendev->ops->initialise(xendev);
> > +
> > +            /*if initialise failed, delete it*/
> > +            if (rc != 0) {
> > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > +                continue;
> > +            }
> > +        }
> > +
> > +        /*setup watch*/
> > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > +                 type, xen_domid, xendev->ops);
> > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> failed.\n");
> > +            return -1;
> > +        }
> > +    }
> > +
> > +    free(dev);
> > +    return 0;
> > +}
> 
> What does this function do? I sholdn't need  to guess from the code, I
> should be able to tell from the patch description.
> 
> 
> >  int xen_be_register(const char *type, struct XenDevOps *ops)
> >  {
> >      return xenstore_scan(type, xen_domid, ops);
> >  }
> >
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom)
> > +{
> > +    xendev->local_port =
> xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > +
> remote_dom);
> > +    if (xendev->local_port == -1) {
> > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> > +        return -1;
> > +    }
> > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> xendev->local_port);
> > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > +                        xen_be_evtchn_event, NULL, xendev);
> > +    return 0;
> > +}
> > +
> >  int xen_be_bind_evtchn(struct XenDevice *xendev)
> >  {
> >      if (xendev->local_port != -1) {
> > @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice
> *xendev)
> >      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
> >  }
> >
> > +int xen_vtpm_send(unsigned char *buf, size_t count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->send) {
> > +        rc = xendev->ops->send(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> > +
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->recv) {
> > +        xendev->ops->recv(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> 
> xen_backend.c is supposed to be generic, so stubdom functions might be
> OK but vtpm specific functions should not be here.
> 
> 
> >  /*
> >   * msg_level:
> >   *  0 == errors (stderr + logfile).
> > diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> > new file mode 100644
> > index 0000000..0d740c1
> > --- /dev/null
> > +++ b/hw/xen/xen_stubdom_vtpm.c
> > @@ -0,0 +1,333 @@
> > +/*
> > + * Connect to Xen vTPM stubdom domain
> > + *
> > + *  Copyright (c) 2014 Intel Corporation
> > + *  Authors:
> > + *    Quan Xu <quan.xu@intel.com>
> > + *
> > + * 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 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, see
> <http://www.gnu.org/licenses/>
> > + */
> > +
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <stdarg.h>
> > +#include <string.h>
> > +#include <unistd.h>
> > +#include <signal.h>
> > +#include <inttypes.h>
> > +#include <time.h>
> > +#include <fcntl.h>
> > +#include <errno.h>
> > +#include <sys/ioctl.h>
> > +#include <sys/types.h>
> > +#include <sys/stat.h>
> > +#include <sys/mman.h>
> > +#include <sys/uio.h>
> > +
> > +#include "hw/hw.h"
> > +#include "block/aio.h"
> > +#include "hw/xen/xen_backend.h"
> > +
> > +enum tpmif_state {
> > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> complete */
> > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> > +};
> > +
> > +static AioContext *vtpm_aio_ctx;
> > +
> > +enum status_bits {
> > +    VTPM_STATUS_RUNNING  = 0x1,
> > +    VTPM_STATUS_IDLE     = 0x2,
> > +    VTPM_STATUS_RESULT   = 0x4,
> > +    VTPM_STATUS_CANCELED = 0x8,
> > +};
> > +
> > +struct tpmif_shared_page {
> > +    uint32_t length;         /* request/response length in bytes */
> > +
> > +    uint8_t  state;           /* enum tpmif_state */
> > +    uint8_t  locality;        /* for the current request */
> > +    uint8_t  pad;             /* should be zero */
> > +
> > +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be
> zero */
> > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> nr_extra_pages */
> > +};
> > +
> > +struct QEMUBH {
> > +    AioContext *ctx;
> > +    QEMUBHFunc *cb;
> > +    void *opaque;
> > +    QEMUBH *next;
> > +    bool scheduled;
> > +    bool idle;
> > +    bool deleted;
> > +};
> > +
> > +struct XenVtpmDev {
> > +    struct XenDevice xendev;  /* must be first */
> > +    struct           tpmif_shared_page *shr;
> > +    xc_gntshr        *xen_xcs;
> > +    int              ring_ref;
> > +    int              bedomid;
> > +    QEMUBH           *sr_bh;
> > +};
> > +
> > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> > +{
> > +    switch (vtpmdev->shr->state) {
> > +    case TPMIF_STATE_IDLE:
> > +    case TPMIF_STATE_FINISH:
> > +        return VTPM_STATUS_IDLE;
> > +    case TPMIF_STATE_SUBMIT:
> > +    case TPMIF_STATE_CANCEL:
> > +        return VTPM_STATUS_RUNNING;
> > +    default:
> > +        return 0;
> > +    }
> > +}
> > +
> > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> xenbus_state xbus)
> > +{
> > +    xs_transaction_t xbt = XBT_NULL;
> > +
> > +    if (xendev->fe_state == xbus) {
> > +        return 0;
> > +    }
> > +
> > +    xendev->fe_state = xbus;
> > +
> > +retry_transaction:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto retry_transaction;
> > +        }
> > +    }
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static int vtpm_aio_wait(QEMUBH *qbh)
> > +{
> > +    return aio_poll(qbh->ctx, true);
> > +}
> > +
> > +static void sr_bh_handler(void *opaque)
> > +{
> > +}
> > +
> > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t
> *count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset;
> > +
> > +    if (shr->state == TPMIF_STATE_IDLE) {
> > +        return -ECANCELED;
> > +    }
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > +    *count = shr->length;
> > +
> > +    return 0;
> > +}
> > +
> > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t
> count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > +    shr->length = count;
> > +    barrier();
> > +    shr->state = TPMIF_STATE_SUBMIT;
> > +    xen_wmb();
> > +    xen_be_send_notify(&vtpmdev->xendev);
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    return count;
> > +}
> > +
> > +static int vtpm_initialise(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    xs_transaction_t xbt = XBT_NULL;
> > +    unsigned int ring_ref;
> > +
> > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> "frontend");
> > +    if (vtpmdev->xendev.fe == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /* Get backend domid */
> > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > +                             &vtpmdev->bedomid)) {
> > +        return -1;
> > +    }
> > +
> > +    /*alloc share page*/
> > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> vtpmdev->bedomid, 1,
> > +                                         &ring_ref,
> PROT_READ|PROT_WRITE);
> > +    vtpmdev->ring_ref = ring_ref;
> > +    if (vtpmdev->shr == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /*Create event channel */
> > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> vtpmdev->bedomid)) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +        return -1;
> > +    }
> > +
> > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > +                     vtpmdev->xendev.local_port);
> > +
> > +again:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > +                           vtpmdev->ring_ref)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > +                           vtpmdev->xendev.local_port)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    /* Publish protocol v2 feature */
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1))
> {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto again;
> > +        }
> > +    }
> > +    /* Tell vtpm backend that we are ready */
> > +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static void vtpm_backend_changed(struct XenDevice *xendev, const char
> *node)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    int be_state;
> > +
> > +    if (strcmp(node, "state") == 0) {
> > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > +        switch (be_state) {
> > +        case XenbusStateConnected:
> > +            /*TODO*/
> > +            break;
> > +        case XenbusStateClosing:
> > +        case XenbusStateClosed:
> > +            xenbus_switch_state(&vtpmdev->xendev,
> XenbusStateClosing);
> > +            break;
> > +        default:
> > +            break;
> > +        }
> > +    }
> > +}
> > +
> > +static int vtpm_free(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > +
> > +    aio_poll(qbh->ctx, false);
> > +    qemu_bh_delete(vtpmdev->sr_bh);
> > +    if (vtpmdev->shr) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    }
> > +    xc_interface_close(vtpmdev->xen_xcs);
> > +    return 0;
> > +}
> > +
> > +static void vtpm_alloc(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    vtpm_aio_ctx = aio_context_new(NULL);
> > +    if (vtpm_aio_ctx == NULL) {
> > +        return;
> > +    }
> > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> vtpmdev);
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> > +}
> > +
> > +static void vtpm_event(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +}
> > +
> > +struct XenDevOps xen_vtpmdev_ops = {
> > +    .size             = sizeof(struct XenVtpmDev),
> > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > +                        DEVOPS_FLAG_STUBDOM_BE,
> > +    .event            = vtpm_event,
> > +    .free             = vtpm_free,
> > +    .alloc            = vtpm_alloc,
> > +    .initialise       = vtpm_initialise,
> > +    .backend_changed  = vtpm_backend_changed,
> > +    .recv             = vtpm_recv,
> > +    .send             = vtpm_send,
> > +};
> 
> Is this the frontend, like the subject line would seem to imply?
> If so, XenDevOps are made for backends, while this is a frontend. In
> fact this is the first PV frontend in QEMU. We need to introduce
> something generic and similar to struct XenDevOps and xen_backend.c but
> for frontends.
> 
> 
> > diff --git a/include/hw/xen/xen_backend.h
> b/include/hw/xen/xen_backend.h
> > index 3b4125e..45fd6d3 100644
> > --- a/include/hw/xen/xen_backend.h
> > +++ b/include/hw/xen/xen_backend.h
> > @@ -15,6 +15,8 @@ struct XenDevice;
> >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> >  /* don't expect frontend doing correct state transitions (aka console
> quirk) */
> >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > +/*dev backend is stubdom*/
> > +#define DEVOPS_FLAG_STUBDOM_BE    4
> >
> >  struct XenDevOps {
> >      size_t    size;
> > @@ -26,6 +28,8 @@ struct XenDevOps {
> >      void      (*event)(struct XenDevice *xendev);
> >      void      (*disconnect)(struct XenDevice *xendev);
> >      int       (*free)(struct XenDevice *xendev);
> > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> count);
> > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> *count);
> >      void      (*backend_changed)(struct XenDevice *xendev, const
> char *node);
> >      void      (*frontend_changed)(struct XenDevice *xendev, const
> char *node);
> >  };
> > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> *xendev);
> >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char
> *fmt, ...)
> >      GCC_FMT_ATTR(3, 4);
> >
> > +/*Xen stubdom vtpm*/
> > +int xen_vtpm_register(struct XenDevOps *ops);
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom);
> > +int xen_vtpm_send(unsigned char *buf, size_t count);
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> > +
> >  /* actual backend drivers */
> >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> */
> >  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c
> */
> >  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
> >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> */
> >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> */
> > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> xen_stubdom_vtpm.c*/
> >
> >  void xen_init_display(int domid);
> >
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 95612a4..fb43084 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void
> *logger, void *dombuild_logger,
> >      return xc_interface_open(logger, dombuild_logger, open_flags);
> >  }
> >
> > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > +                                           unsigned int open_flags)
> > +{
> > +    return xc_gntshr_open(logger, open_flags);
> > +}
> > +
> >  /* FIXME There is now way to have the xen fd */
> >  static inline int xc_fd(xc_interface *xen_xc)
> >  {
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 21f1cbb..c99ace8 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >      int i, rc;
> >      unsigned long ioreq_pfn;
> >      unsigned long bufioreq_evtchn;
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    unsigned long stubdom_vtpm = 0;
> > +#endif
> > +
> >      XenIOState *state;
> >
> >      state = g_malloc0(sizeof (XenIOState));
> > @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >          fprintf(stderr, "%s: xen backend core setup failed\n",
> __FUNCTION__);
> >          return -1;
> >      }
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    xc_get_hvm_param(xen_xc, xen_domid,
> HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > +    if (stubdom_vtpm) {
> > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > +    }
> > +#endif
> 
> Given that vtpm is just a PV frontend, can't you just detect whether is
> present on xenstore and initialize it based on that? Like all the
> backend below?

Also I will explain in my next email. 


> 
> 
> >      xen_be_register("console", &xen_console_ops);
> >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> >      xen_be_register("qdisk", &xen_blkdev_ops);
> > --
> > 1.8.3.2
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:32:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1Xlh2H-0000jn-SM; Tue, 04 Nov 2014 16:32:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlh2F-0000jR-Mr
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:32:47 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	B3/4A-03148-FAFF8545; Tue, 04 Nov 2014 16:32:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415118764!12508869!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24850 invoked from network); 4 Nov 2014 16:32:46 -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;
	4 Nov 2014 16:32:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187981457"
Message-ID: <1415118690.11486.53.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Tue, 4 Nov 2014 16:31:30 +0000
In-Reply-To: <5458FB49.4040801@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
> Am 04.11.14 um 16:44 schrieb Ian Campbell:
> > On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
> >> I assume it may be warranted to "upgrade" this issue to a bug status
> >> (obviously also in the hope that it attractes wider interest) by
> >> prefixing the subject line with a [BUG] prefix as per
> >> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project. I have
> >> exhausted all my options (including numerous IRC attempts), provided all
> >> the information I have been asked for but the issue persists and nobody
> >> seems to have an idea how to rectify the problem.
> >
> > Sorry for the delay, the issue is quite perplexing so I was intending to
> > sleep on it, but didn't get any inspiration in doing so...
> Thanks for getting back ... obviously sometimes sleep is not the right cure.
> >
> > In the gdb traces you provided there is:
> > #10 read_all (fd=10, data=data@entry=0x7ffff0000a10, len=len@entry=16, nonblocking=nonblocking@entry=0) at xs.c:374
> >
> Just to be on the same page: That was for the destroy case. The 
> corresponding line for the create case was:
> #10 read_all (fd=18, data=data@entry=0x7fffe80008d0, len=len@entry=16, 
> nonblocking=nonblocking@entry=0) at xs.c:374
> 
> I don't know whether that makes any difference though.
> > which seems to correspond to the
> >          if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
> I did have a look at the file xs.c as well in the source and there are 3 
> source code files named xs.c:
> 	tools/xenstore/xs.c
> 	tools/python/xen/lowlevel/xs/xs.c
> 	extras/mini-os/lib/xs.c
> Out of these only the first two do have at least 374 lines and only the 
> first one has a non empty source code line at line 374. That line 
> however reads as follows in my source:
> 	done = read(fd, data, len)
> and is located in function
> 	static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
> starting at line 361
> 
> The line you referr to is located at line 1139 in the same file. I just 
> wanted to bring this to your attention, but I might be on the wrong 
> track here ...

Right, the line at 1139 is the caller of thing in stack frame #10. The
other potentially caller is at 1150. It's the callers which ultimately
provide the buffer to read into (called "data" in real_all), which is
why I was interested in them.

> > So, I'm afraid I'm completely mystified.
> >
> > You could try running the xl command under valgrind, you may find "xl
> > create -F" (which keeps xl in the foreground) handy if you try this.
> > That might help catch any heap corruption etc.
> I don't know what valgrind is, but I'll have a look and see how to deal 
> with that ...

Valgrind is a totally awesome memory allocation debugger ;-)

> > A related thing to try might be to run "MALLOC_CHECK_=2 xl create ..."
> > which enables glib's heap consistency checks (described at the end of
> > http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html) which might give a clue.
> I tried that, but the same segfault and no more messages on the screen - 
> or should I have run this under gdb as well?

No, just setting the var is all that is needed. The fact that nothing
has changed would suggest that it's not an obvious heap corruption at
least. Valgrind might find something more subtle, but TBH I doubt it.

> > Otherwise I think the next step would be to downgrade to 4.3.1 and see
> > if the problem persists, in order to rule out changes elsewhere in the
> > system. If the problem doesn't happen with a 4.3.1 rebuilt on your
> > current system then the next thing would probably be to bisect the
> > issue. There are only 31 toolstack changes in that range, so it ought to
> > only take 5-6 iterations.
> Unfortunately 4.3.1 is no longer available as an ebuild as 4.3.3 seemed 
> to fix security issues and therefore 4.3.1 has been deleted from the 
> repos. So it's not straightforward and I need to figure out how to get 
> the old version back. But I am sure there's a way.

I don't know anything about ebuilds, but if you end up needing to bisect
then building from xen.git might be useful anyway (unless you can get an
ebuild to trivially build some other 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 Nov 04 16:32:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1Xlh2H-0000jn-SM; Tue, 04 Nov 2014 16:32:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlh2F-0000jR-Mr
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:32:47 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	B3/4A-03148-FAFF8545; Tue, 04 Nov 2014 16:32:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415118764!12508869!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24850 invoked from network); 4 Nov 2014 16:32:46 -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;
	4 Nov 2014 16:32:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187981457"
Message-ID: <1415118690.11486.53.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Tue, 4 Nov 2014 16:31:30 +0000
In-Reply-To: <5458FB49.4040801@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
> Am 04.11.14 um 16:44 schrieb Ian Campbell:
> > On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
> >> I assume it may be warranted to "upgrade" this issue to a bug status
> >> (obviously also in the hope that it attractes wider interest) by
> >> prefixing the subject line with a [BUG] prefix as per
> >> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project. I have
> >> exhausted all my options (including numerous IRC attempts), provided all
> >> the information I have been asked for but the issue persists and nobody
> >> seems to have an idea how to rectify the problem.
> >
> > Sorry for the delay, the issue is quite perplexing so I was intending to
> > sleep on it, but didn't get any inspiration in doing so...
> Thanks for getting back ... obviously sometimes sleep is not the right cure.
> >
> > In the gdb traces you provided there is:
> > #10 read_all (fd=10, data=data@entry=0x7ffff0000a10, len=len@entry=16, nonblocking=nonblocking@entry=0) at xs.c:374
> >
> Just to be on the same page: That was for the destroy case. The 
> corresponding line for the create case was:
> #10 read_all (fd=18, data=data@entry=0x7fffe80008d0, len=len@entry=16, 
> nonblocking=nonblocking@entry=0) at xs.c:374
> 
> I don't know whether that makes any difference though.
> > which seems to correspond to the
> >          if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
> I did have a look at the file xs.c as well in the source and there are 3 
> source code files named xs.c:
> 	tools/xenstore/xs.c
> 	tools/python/xen/lowlevel/xs/xs.c
> 	extras/mini-os/lib/xs.c
> Out of these only the first two do have at least 374 lines and only the 
> first one has a non empty source code line at line 374. That line 
> however reads as follows in my source:
> 	done = read(fd, data, len)
> and is located in function
> 	static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
> starting at line 361
> 
> The line you referr to is located at line 1139 in the same file. I just 
> wanted to bring this to your attention, but I might be on the wrong 
> track here ...

Right, the line at 1139 is the caller of thing in stack frame #10. The
other potentially caller is at 1150. It's the callers which ultimately
provide the buffer to read into (called "data" in real_all), which is
why I was interested in them.

> > So, I'm afraid I'm completely mystified.
> >
> > You could try running the xl command under valgrind, you may find "xl
> > create -F" (which keeps xl in the foreground) handy if you try this.
> > That might help catch any heap corruption etc.
> I don't know what valgrind is, but I'll have a look and see how to deal 
> with that ...

Valgrind is a totally awesome memory allocation debugger ;-)

> > A related thing to try might be to run "MALLOC_CHECK_=2 xl create ..."
> > which enables glib's heap consistency checks (described at the end of
> > http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html) which might give a clue.
> I tried that, but the same segfault and no more messages on the screen - 
> or should I have run this under gdb as well?

No, just setting the var is all that is needed. The fact that nothing
has changed would suggest that it's not an obvious heap corruption at
least. Valgrind might find something more subtle, but TBH I doubt it.

> > Otherwise I think the next step would be to downgrade to 4.3.1 and see
> > if the problem persists, in order to rule out changes elsewhere in the
> > system. If the problem doesn't happen with a 4.3.1 rebuilt on your
> > current system then the next thing would probably be to bisect the
> > issue. There are only 31 toolstack changes in that range, so it ought to
> > only take 5-6 iterations.
> Unfortunately 4.3.1 is no longer available as an ebuild as 4.3.3 seemed 
> to fix security issues and therefore 4.3.1 has been deleted from the 
> repos. So it's not straightforward and I need to figure out how to get 
> the old version back. But I am sure there's a way.

I don't know anything about ebuilds, but if you end up needing to bisect
then building from xen.git might be useful anyway (unless you can get an
ebuild to trivially build some other 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 Nov 04 16:34:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:34:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlh46-0000v7-DS; Tue, 04 Nov 2014 16:34:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xlh45-0000v0-M4
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:34:41 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	52/4B-02954-12009545; Tue, 04 Nov 2014 16:34:41 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415118877!12538319!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23455 invoked from network); 4 Nov 2014 16:34:39 -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;
	4 Nov 2014 16:34:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187982717"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:33:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlh3C-0002Sb-93;
	Tue, 04 Nov 2014 16:33:46 +0000
Date: Tue, 4 Nov 2014 16:33:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041621380.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 9/9] xen/arm: cpufreq: add
	xen-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> Xen changes frequencies on CPUs using this high-level
> cpufreq driver.
> 
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>

You CC the wrong email address for Rafael in the entire series.


>  drivers/cpufreq/Kconfig           |  20 +
>  drivers/cpufreq/Makefile          |   1 +
>  drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
>  drivers/cpufreq/cpufreq_drv_ops.h |   4 +
>  drivers/cpufreq/xen-cpufreq.c     | 869 ++++++++++++++++++++++++++++++++++++++
>  include/xen/interface/platform.h  |   1 +
>  include/xen/interface/xen.h       |   1 +
>  7 files changed, 907 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/cpufreq/xen-cpufreq.c
> 
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index f5a8f84..4847d8a 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -19,6 +19,26 @@ config CPU_FREQ
>  
>  	  If in doubt, say N.
>  
> +config XEN_CPUFREQ
> +	bool "Xen Cpufreq driver"
> +	depends on XEN_DOM0
> +	depends on !CPUMASK_OFFSTACK
> +	default n
> +	select CPUFREQ_DRV_OPS
> +	help
> +	  This driver uploads Power Management information to the Xen
> +	  hypervisor and changes CPUs frequency using CPU Frequency scaling
> +	  drivers.
> +
> +	  To do that the driver uses CPU Frequency scaling drivers to parse
> +	  the Power Management data and uploads said information to the Xen
> +	  hypervisor. Then the Xen hypervisor can select the proper Pxx states.
> +
> +	  Then the Xen hypervisor can change CPUs frequency by giving commands
> +	  via this driver to the CPU Frequency scaling driver.
> +
> +	  If in doubt, say N.
> +
>  if CPUFREQ_DRV_OPS
>  
>  config CPU_FREQ_TABLE
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index f12a0d3..c8d5037 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -1,5 +1,6 @@
>  # CPUfreq core
>  obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
> +obj-$(CONFIG_XEN_CPUFREQ)		+= xen-cpufreq.o
>  obj-$(CONFIG_CPUFREQ_DRV_OPS)		+= cpufreq_drv_ops.o
>  # CPUfreq stats
>  obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
> diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
> index c971442..71c3357 100644
> --- a/drivers/cpufreq/cpufreq_drv_ops.c
> +++ b/drivers/cpufreq/cpufreq_drv_ops.c
> @@ -18,6 +18,8 @@
>  #include <linux/init.h>
>  #include <linux/export.h>
>  
> +#include <xen/xen.h>
> +
>  static struct cpufreq_drv_ops *ops;
>  
>  struct kobject *get_cpufreq_global_kobject(void)
> @@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
>  
>  static int __init cpufreq_drv_ops_init(void)
>  {
> +	if (xen_initial_domain()) {
> +#ifdef CONFIG_XEN_CPUFREQ
> +		ops = &xen_cpufreq_drv_ops;
> +		pr_debug("using xen_cpufreq_drv_ops\n");
> +#endif
> +	} else {
>  #ifdef CONFIG_CPU_FREQ
> -	ops = &kern_cpufreq_drv_ops;
> -	pr_debug("using kern_cpufreq_drv_ops\n");
> +		ops = &kern_cpufreq_drv_ops;
> +		pr_debug("using kern_cpufreq_drv_ops\n");
>  #endif
> +	}
>  
>  	return 0;
>  }
> diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
> index 5cc8e05..d02d509 100644
> --- a/drivers/cpufreq/cpufreq_drv_ops.h
> +++ b/drivers/cpufreq/cpufreq_drv_ops.h
> @@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
>  extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
>  #endif
>  
> +#ifdef CONFIG_XEN_CPUFREQ
> +extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
> +#endif
> +
>  #endif /* _CPUFREQ_DRV_OPS_H */
> diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
> new file mode 100644
> index 0000000..21062c7
> --- /dev/null
> +++ b/drivers/cpufreq/xen-cpufreq.c
> @@ -0,0 +1,869 @@
> +/*
> + *  Copyright (C) 2001 Russell King
> + *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
> + *
> + *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
> + *	Added handling for CPU hotplug
> + *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
> + *	Fix handling for CPU hotplug -- affected CPUs
> + *
> + *           (C) 2014 GlobalLogic Inc.
> + *
> + * Based on drivers/cpufreq/cpufreq.c
> + *
> + * 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.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/notifier.h>
> +#include <linux/types.h>
> +#include <linux/slab.h>
> +#include <linux/mutex.h>
> +#include <linux/irq.h>
> +#include <linux/workqueue.h>
> +#include <linux/cpufreq.h>
> +
> +#include <trace/events/power.h>
> +
> +#include <xen/xen.h>
> +#include <xen/events.h>
> +#include <xen/interface/xen.h>
> +#include <xen/interface/platform.h>
> +#include <xen/interface/sysctl.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/xen/hypervisor.h>
> +
> +#include "cpufreq_drv_ops.h"
> +
> +static int xen_nr_cpus;
> +static int xen_irq;
> +
> +#define for_each_xen_cpu(cpu, mask)			\
> +	for ((cpu) = -1;				\
> +		(cpu) = cpumask_next((cpu), (mask)),	\
> +		(cpu) < xen_nr_cpus;)
> +
> +static struct cpufreq_driver *cpufreq_driver;
> +static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
> +
> +static DEFINE_SPINLOCK(cpufreq_driver_lock);
> +
> +/*
> + * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
> + * all cpufreq/hotplug/workqueue/etc related lock issues.
> + *
> + * The rules for this semaphore:
> + * - Any routine that wants to read from the policy structure will
> + *   do a down_read on this semaphore.
> + * - Any routine that will write to the policy structure and/or may take away
> + *   the policy altogether (eg. CPU hotplug), will hold this lock in write
> + *   mode before doing so.
> + *
> + * Additional rules:
> + * - Governor routines that can be called in cpufreq hotplug path should not
> + *   take this sem as top level hotplug notifier handler takes this.
> + * - Lock should not be held across
> + *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
> + */
> +static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
> +static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
> +
> +#define lock_policy_rwsem(mode, cpu)				\
> +static int lock_policy_rwsem_##mode				\
> +(int cpu)							\
> +{								\
> +	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);	\
> +	BUG_ON(policy_cpu == -1);				\
> +	down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));	\
> +								\
> +	return 0;						\
> +}
> +
> +lock_policy_rwsem(write, cpu);
> +
> +static void unlock_policy_rwsem_write(int cpu)
> +{
> +	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
> +	BUG_ON(policy_cpu == -1);
> +	up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
> +}
> +
> +/**
> + * The "transition" notifier list for kernel code that needs to handle
> + * changes to devices when the CPU clock speed changes.
> + * The mutex locks this list.
> + */
> +static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
> +
> +static bool init_cpufreq_transition_notifier_list_called;
> +static int __init init_cpufreq_transition_notifier_list(void)
> +{
> +	srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
> +	init_cpufreq_transition_notifier_list_called = true;
> +	return 0;
> +}
> +pure_initcall(init_cpufreq_transition_notifier_list);
> +
> +static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
> +{
> +	struct cpufreq_policy *data = NULL;
> +	unsigned long flags;
> +
> +	if (cpu >= xen_nr_cpus)
> +		goto err_out;
> +
> +	/* get the cpufreq driver */
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +
> +	if (!cpufreq_driver)
> +		goto err_out_unlock;
> +
> +	/* get the CPU */
> +	data = per_cpu(cpufreq_cpu_data, cpu);
> +
> +err_out_unlock:
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +err_out:
> +	return data;
> +}
> +
> +static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
> +{
> +	module_put(cpufreq_driver->owner);
> +}
> +
> +static int push_data_to_hypervisor(struct cpufreq_policy *policy,
> +				   struct cpufreq_frequency_table *table)
> +{
> +	int ret = 0;
> +	unsigned int i;
> +	unsigned int cpu;
> +	uint32_t platform_limit = 0;
> +	unsigned int max_freq = 0;
> +	unsigned int state_count = 0;
> +	unsigned int prev_freq = 0;
> +	struct xen_processor_px *dst_states;
> +	struct xen_processor_performance *dst_perf;
> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_set_processor_pminfo,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.set_pminfo.type	= XEN_PM_PX,
> +	};
> +
> +	dst_perf = &op.u.set_pminfo.perf;
> +
> +	/* Check freq table and find max frequency */
> +	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> +		unsigned int freq = table[i].frequency;
> +		if (freq == CPUFREQ_ENTRY_INVALID)
> +			continue;
> +
> +		if (table[i].index != state_count || freq <= prev_freq) {
> +			pr_err("Frequency table format error\n");
> +			return -EINVAL;
> +		}
> +
> +		prev_freq = freq;
> +		state_count++;
> +		if (freq > max_freq)
> +			max_freq = freq;
> +	}
> +
> +	if (!state_count)
> +		return -EINVAL;
> +
> +	dst_perf->state_count = state_count;
> +
> +	dst_states = kcalloc(state_count,
> +			     sizeof(struct xen_processor_px), GFP_KERNEL);
> +
> +	if (!dst_states)
> +		return -ENOMEM;
> +
> +	set_xen_guest_handle(dst_perf->states, dst_states);
> +
> +	/*
> +	 * Freq table should start from lower values
> +	 * dst_states should start from higer values
> +	 */
> +	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> +		unsigned int freq = table[i].frequency;
> +		unsigned int tbl_index = state_count - 1 - table[i].index;
> +		if (freq == CPUFREQ_ENTRY_INVALID)
> +			continue;
> +
> +		if (freq == max_freq)
> +			platform_limit = tbl_index;
> +
> +		dst_states[tbl_index].core_frequency = freq / 1000;
> +		dst_states[tbl_index].transition_latency =
> +				policy->cpuinfo.transition_latency / 1000;
> +	}
> +
> +	dst_perf->shared_type = policy->shared_type;
> +	dst_perf->platform_limit = platform_limit;
> +	dst_perf->domain_info.domain = policy->cpu;
> +	dst_perf->domain_info.num_processors = xen_nr_cpus;
> +	dst_perf->flags = XEN_PX_DATA;
> +
> +	for_each_xen_cpu(cpu, policy->cpus) {
> +		op.u.set_pminfo.id = cpu;
> +		ret = HYPERVISOR_dom0_op(&op);
> +		if (ret) {
> +			pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
> +			goto err_free_states;
> +		}
> +		pr_debug("CPU%u - P-states uploaded\n", cpu);
> +
> +		for (i = 0; i < dst_perf->state_count; i++) {
> +			pr_debug("    state %d: %d MHz, %d uS\n",
> +				 i, (u32) dst_states[i].core_frequency,
> +				 (u32) dst_states[i].transition_latency);
> +		}
> +	}
> +
> +err_free_states:
> +	kfree(dst_states);
> +	return ret;
> +}
> +
> +/*
> + * Returns:
> + *   Negative: Failure
> + *   0:        Success
> + *   Positive: When we have a managed CPU and the sysfs got symlinked
> + */
> +static int xen_cpufreq_add_dev_policy(unsigned int cpu,
> +				  struct cpufreq_policy *policy)
> +{
> +	int ret = 0;
> +#ifdef CONFIG_SMP
> +	unsigned long flags;
> +	unsigned int j;
> +
> +	for_each_cpu(j, policy->cpus) {
> +		struct cpufreq_policy *managed_policy;
> +
> +		if (cpu == j)
> +			continue;
> +
> +		/* Check for existing affected CPUs.
> +		 * They may not be aware of it due to CPU Hotplug.
> +		 * cpufreq_cpu_put is called when the device is removed
> +		 * in __cpufreq_remove_dev()
> +		 */
> +		managed_policy = xen_cpufreq_cpu_get(j);
> +		if (unlikely(managed_policy)) {
> +			/* Set proper policy_cpu */
> +			unlock_policy_rwsem_write(cpu);
> +			per_cpu(cpufreq_policy_cpu, cpu) =
> +						managed_policy->cpu;
> +
> +			if (lock_policy_rwsem_write(cpu) < 0) {
> +				/* Should not go through policy unlock path */
> +				if (cpufreq_driver->exit)
> +					cpufreq_driver->exit(policy);
> +				xen_cpufreq_cpu_put(managed_policy);
> +				return -EBUSY;
> +			}
> +
> +			spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +			cpumask_copy(managed_policy->cpus, policy->cpus);
> +			per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
> +			spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +
> +			pr_debug("CPU already managed, adding link\n");
> +
> +			/*
> +			 * Success. We only needed to be added to the mask.
> +			 * Call driver->exit() because only the cpu parent of
> +			 * the kobj needed to call init().
> +			 */
> +			if (cpufreq_driver->exit)
> +				cpufreq_driver->exit(policy);
> +
> +			return 1;
> +		}
> +	}
> +#endif
> +	return ret;
> +}
> +
> +/**
> + * xen_cpufreq_add_dev - add a CPU device
> + *
> + * Adds the cpufreq interface for a CPU device.
> + */
> +static int xen_cpufreq_add_dev(unsigned int cpu)
> +{
> +	int ret = 0;
> +	struct cpufreq_policy *policy;
> +	unsigned long flags;
> +	unsigned int j;
> +
> +	pr_debug("adding CPU %u\n", cpu);
> +
> +#ifdef CONFIG_SMP
> +	/* check whether a different CPU already registered this
> +	 * CPU because it is in the same boat. */
> +	policy = xen_cpufreq_cpu_get(cpu);
> +	if (unlikely(policy)) {
> +		xen_cpufreq_cpu_put(policy);
> +		return 0;
> +	}
> +#endif
> +
> +	if (!try_module_get(cpufreq_driver->owner)) {
> +		ret = -EINVAL;
> +		goto module_out;
> +	}
> +
> +	ret = -ENOMEM;
> +	policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
> +	if (!policy)
> +		goto nomem_out;
> +
> +	if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
> +		goto err_free_policy;
> +
> +	if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
> +		goto err_free_cpumask;
> +
> +	policy->cpu = cpu;
> +	cpumask_copy(policy->cpus, cpumask_of(cpu));
> +
> +	/* Initially set CPU itself as the policy_cpu */
> +	per_cpu(cpufreq_policy_cpu, cpu) = cpu;
> +	ret = (lock_policy_rwsem_write(cpu) < 0);
> +	WARN_ON(ret);
> +
> +	/* call driver. From then on the cpufreq must be able
> +	 * to accept all calls to ->verify and ->setpolicy for this CPU
> +	 */
> +	ret = cpufreq_driver->init(policy);
> +	if (ret) {
> +		pr_debug("initialization failed\n");
> +		goto err_unlock_policy;
> +	}
> +	ret = xen_cpufreq_add_dev_policy(cpu, policy);
> +	if (ret) {
> +		if (ret > 0)
> +			/* This is a managed cpu, symlink created,
> +			   exit with 0 */
> +			ret = 0;
> +		goto err_unlock_policy;
> +	}
> +
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +	for_each_cpu(j, policy->cpus) {
> +		per_cpu(cpufreq_cpu_data, j) = policy;
> +		per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
> +	}
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +
> +	unlock_policy_rwsem_write(cpu);
> +
> +	module_put(cpufreq_driver->owner);
> +	pr_debug("initialization complete\n");
> +
> +	return 0;
> +
> +err_unlock_policy:
> +	unlock_policy_rwsem_write(cpu);
> +	free_cpumask_var(policy->related_cpus);
> +err_free_cpumask:
> +	free_cpumask_var(policy->cpus);
> +err_free_policy:
> +	kfree(policy);
> +nomem_out:
> +	module_put(cpufreq_driver->owner);
> +module_out:
> +	return ret;
> +}
> +
> +/**
> + * __cpufreq_remove_dev - remove a CPU device
> + *
> + * Removes the cpufreq interface for a CPU device.
> + * Caller should already have policy_rwsem in write mode for this CPU.
> + * This routine frees the rwsem before returning.
> + */
> +static int __cpufreq_remove_dev(unsigned int cpu)
> +{
> +	unsigned long flags;
> +	struct cpufreq_policy *data;
> +#ifdef CONFIG_SMP
> +	unsigned int j;
> +#endif
> +
> +	pr_debug("unregistering CPU %u\n", cpu);
> +
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +	data = per_cpu(cpufreq_cpu_data, cpu);
> +
> +	if (!data) {
> +		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +		unlock_policy_rwsem_write(cpu);
> +		return -EINVAL;
> +	}
> +	per_cpu(cpufreq_cpu_data, cpu) = NULL;
> +
> +
> +#ifdef CONFIG_SMP
> +	/* if this isn't the CPU which is the parent of the kobj, we
> +	 * only need to unlink, put and exit
> +	 */
> +	if (unlikely(cpu != data->cpu)) {
> +		pr_debug("removing link\n");
> +		cpumask_clear_cpu(cpu, data->cpus);
> +		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +		xen_cpufreq_cpu_put(data);
> +		unlock_policy_rwsem_write(cpu);
> +		return 0;
> +	}
> +#endif
> +
> +#ifdef CONFIG_SMP
> +
> +	/* if we have other CPUs still registered, we need to unlink them,
> +	 * or else wait_for_completion below will lock up. Clean the
> +	 * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
> +	 * the sysfs links afterwards.
> +	 */
> +	if (unlikely(cpumask_weight(data->cpus) > 1)) {
> +		for_each_cpu(j, data->cpus) {
> +			if (j == cpu)
> +				continue;
> +			per_cpu(cpufreq_cpu_data, j) = NULL;
> +		}
> +	}
> +
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +
> +	if (unlikely(cpumask_weight(data->cpus) > 1)) {
> +		for_each_cpu(j, data->cpus) {
> +			if (j == cpu)
> +				continue;
> +			pr_debug("removing link for cpu %u\n", j);
> +			unlock_policy_rwsem_write(cpu);
> +			lock_policy_rwsem_write(cpu);
> +			xen_cpufreq_cpu_put(data);
> +		}
> +	}
> +#else
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +#endif
> +
> +	unlock_policy_rwsem_write(cpu);
> +
> +	lock_policy_rwsem_write(cpu);
> +	if (cpufreq_driver->exit)
> +		cpufreq_driver->exit(data);
> +	unlock_policy_rwsem_write(cpu);
> +
> +	free_cpumask_var(data->related_cpus);
> +	free_cpumask_var(data->cpus);
> +	kfree(data);
> +
> +	return 0;
> +}
> +
> +static int cpufreq_remove_dev(unsigned int cpu)
> +{
> +	int retval;
> +
> +	if (unlikely(lock_policy_rwsem_write(cpu)))
> +		BUG();
> +
> +	retval = __cpufreq_remove_dev(cpu);
> +	return retval;
> +}
> +
> +/*********************************************************************
> + *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
> + *********************************************************************/
> +
> +/**
> + * adjust_jiffies - adjust the system "loops_per_jiffy"
> + *
> + * This function alters the system "loops_per_jiffy" for the clock
> + * speed change. Note that loops_per_jiffy cannot be updated on SMP
> + * systems as each CPU might be scaled differently. So, use the arch
> + * per-CPU loops_per_jiffy value wherever possible.
> + */
> +#ifndef CONFIG_SMP
> +static unsigned long l_p_j_ref;
> +static unsigned int  l_p_j_ref_freq;
> +
> +static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
> +{
> +	if (ci->flags & CPUFREQ_CONST_LOOPS)
> +		return;
> +
> +	if (!l_p_j_ref_freq) {
> +		l_p_j_ref = loops_per_jiffy;
> +		l_p_j_ref_freq = ci->old;
> +		pr_debug("saving %lu as reference value for loops_per_jiffy; "
> +			"freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
> +	}
> +	if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
> +	    (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
> +		loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
> +								ci->new);
> +		pr_debug("scaling loops_per_jiffy to %lu "
> +			"for frequency %u kHz\n", loops_per_jiffy, ci->new);
> +	}
> +}
> +#else
> +static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
> +{
> +	return;
> +}
> +#endif

There is quite a lot of code duplication with cpufreq.c, I don't think
that is going to be acceptable for the upstream maintainers.


> +/**
> + * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
> + * on frequency transition.
> + *
> + * This function calls the transition notifiers and the "adjust_jiffies"
> + * function. It is called twice on all CPU frequency changes that have
> + * external effects.
> + */
> +void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
> +				   unsigned int state)
> +{
> +	struct cpufreq_policy *policy;
> +
> +	BUG_ON(irqs_disabled());
> +
> +	freqs->flags = cpufreq_driver->flags;
> +	pr_debug("notification %u of frequency transition to %u kHz\n",
> +		 state, freqs->new);
> +
> +	policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
> +	switch (state) {
> +	case CPUFREQ_PRECHANGE:
> +		/* detect if the driver reported a value as "old frequency"
> +		 * which is not equal to what the cpufreq core thinks is
> +		 * "old frequency".
> +		 */
> +		if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
> +			if ((policy) && (policy->cpu == freqs->cpu) &&
> +			    (policy->cur) && (policy->cur != freqs->old)) {
> +				pr_debug("Warning: CPU frequency is"
> +					 " %u, cpufreq assumed %u kHz.\n",
> +					 freqs->old, policy->cur);
> +				freqs->old = policy->cur;
> +			}
> +		}
> +		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
> +					 CPUFREQ_PRECHANGE, freqs);
> +		adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
> +		break;
> +
> +	case CPUFREQ_POSTCHANGE:
> +		adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
> +		pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
> +			 (unsigned long)freqs->cpu);
> +		trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
> +		trace_cpu_frequency(freqs->new, freqs->cpu);
> +		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
> +					 CPUFREQ_POSTCHANGE, freqs);
> +		if (likely(policy) && likely(policy->cpu == freqs->cpu))
> +			policy->cur = freqs->new;
> +		break;
> +	}
> +}
> +
> +/*********************************************************************
> + *                              GOVERNORS                            *
> + *********************************************************************/
> +
> +int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
> +				unsigned int target_freq,
> +				unsigned int relation)
> +{
> +	int retval = -EINVAL;
> +	unsigned int old_target_freq = target_freq;
> +
> +	/* Make sure that target_freq is within supported range */
> +	if (target_freq > policy->max)
> +		target_freq = policy->max;
> +	if (target_freq < policy->min)
> +		target_freq = policy->min;
> +
> +	pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
> +		 policy->cpu, target_freq, relation, old_target_freq);
> +
> +	if (target_freq == policy->cur)
> +		return 0;
> +
> +	if (cpufreq_driver->target)
> +		retval = cpufreq_driver->target(policy, target_freq,
> +						    relation);
> +
> +	return retval;
> +}
> +
> +int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
> +			      unsigned int target_freq,
> +			      unsigned int relation)
> +{
> +	int ret = -EINVAL;
> +
> +	if (!policy)
> +		goto no_policy;
> +
> +	if (unlikely(lock_policy_rwsem_write(policy->cpu)))
> +		goto fail;
> +
> +	ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
> +
> +	unlock_policy_rwsem_write(policy->cpu);
> +
> +fail:
> +	xen_cpufreq_cpu_put(policy);
> +no_policy:
> +	return ret;
> +}
> +
> +/*********************************************************************
> + *                    HANDLE COMMANDS FROM XEN                       *
> + *********************************************************************/
> +static void cpufreq_work_hnd(struct work_struct *w);
> +
> +static struct workqueue_struct *cpufreq_wq;
> +static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
> +
> +static void cpufreq_work_hnd(struct work_struct *w)
> +{
> +	int ret;
> +	struct cpufreq_policy *policy;
> +	struct cpufreq_sh_info *cpufreq_info;
> +
> +	cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
> +
> +	policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
> +	ret = xen_cpufreq_driver_target(policy,
> +					cpufreq_info->freq,
> +					cpufreq_info->relation);
> +
> +	cpufreq_info->result = ret;
> +}

No barriers? No locking?


> +static irqreturn_t cpufreq_interrupt(int irq, void *data)
> +{
> +	queue_work(cpufreq_wq, &cpufreq_work);
> +	return IRQ_HANDLED;
> +}
> +
> +/*********************************************************************
> + *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
> + *********************************************************************/
> +
> +/**
> + * xen_cpufreq_register_driver - register a CPU Frequency driver
> + * @driver_data: A struct cpufreq_driver containing the values#
> + * submitted by the CPU Frequency driver.
> + *
> + *   Registers a CPU Frequency driver to this core code. This code
> + * returns zero on success, -EBUSY when another driver got here first
> + * (and isn't unregistered in the meantime).
> + *
> + */
> +int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
> +{
> +	unsigned long flags;
> +	int ret;
> +	unsigned int cpu;
> +	struct cpufreq_frequency_table *table;
> +	struct cpufreq_policy *policy;
> +	cpumask_var_t pushed_cpus;
> +	int irq;
> +
> +	if (!xen_nr_cpus)
> +		return -EPROBE_DEFER;
> +
> +	if (!driver_data || !driver_data->verify || !driver_data->init ||
> +	    (!driver_data->target))
> +		return -EINVAL;
> +
> +	pr_debug("trying to register driver %s\n", driver_data->name);
> +
> +	if (driver_data->setpolicy)
> +		driver_data->flags |= CPUFREQ_CONST_LOOPS;
> +
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +
> +	if (cpufreq_driver) {
> +		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +		return -EBUSY;
> +	}
> +	cpufreq_driver = driver_data;
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +
> +	irq = bind_virq_to_irq(VIRQ_CPUFREQ, 0);
> +	if (irq < 0) {
> +		pr_err("Bind virq (%d) error (%d)\n", VIRQ_CPUFREQ, irq);
> +		ret = irq;
> +		goto err_remove_drv;
> +	}
> +
> +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN|IRQ_NOPROBE);
> +
> +	ret = request_irq(irq, cpufreq_interrupt, 0,
> +			   "xen_cpufreq", NULL);
> +
> +	if (ret < 0) {
> +		pr_err("Request irq (%d) error (%d)\n", irq, ret);
> +		goto err_unbind_from_irqhnd;
> +	}
> +
> +	xen_irq = irq;
> +
> +	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
> +		ret = xen_cpufreq_add_dev(cpu);
> +		if (ret)
> +			goto err_remove_cpu;
> +	}
> +
> +	if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
> +		goto err_remove_cpu;
> +
> +	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
> +		if (cpumask_test_cpu(cpu, pushed_cpus))
> +			continue;
> +
> +		policy = xen_cpufreq_cpu_get(cpu);
> +		if (!policy) {
> +			ret = -EINVAL;
> +			goto err_free_cpumask;
> +		}
> +
> +		cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
> +		table = cpufreq_frequency_get_table(policy->cpu);
> +		if (!table) {
> +			ret = -EINVAL;
> +			goto err_free_cpumask;
> +		}
> +
> +		ret = push_data_to_hypervisor(policy, table);
> +		if (ret)
> +			goto err_free_cpumask;
> +	}
> +
> +	free_cpumask_var(pushed_cpus);
> +
> +	pr_debug("driver %s up and running\n", driver_data->name);
> +
> +	return 0;
> +
> +err_free_cpumask:
> +	free_cpumask_var(pushed_cpus);
> +err_remove_cpu:
> +	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
> +		cpufreq_remove_dev(cpu);
> +err_unbind_from_irqhnd:
> +	unbind_from_irqhandler(irq, NULL);
> +err_remove_drv:
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +	cpufreq_driver = NULL;
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +	return ret;
> +}
> +
> +/**
> + * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
> + *
> + *    Unregister the current CPUFreq driver. Only call this if you have
> + * the right to do so, i.e. if you have succeeded in initialising before!
> + * Returns zero if successful, and -EINVAL if the cpufreq_driver is
> + * currently not initialised.
> + */
> +int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
> +{
> +	unsigned long flags;
> +	unsigned int cpu;
> +
> +	if (!cpufreq_driver || (driver != cpufreq_driver))
> +		return -EINVAL;
> +
> +	pr_debug("unregistering driver %s\n", driver->name);
> +
> +	unbind_from_irqhandler(xen_irq, NULL);
> +
> +	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
> +		cpufreq_remove_dev(cpu);
> +
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +	cpufreq_driver = NULL;
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +
> +	return 0;
> +}
> +
> +struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
> +	.notify_transition = xen_cpufreq_notify_transition,
> +	.register_driver = xen_cpufreq_register_driver,
> +	.unregister_driver = xen_cpufreq_unregister_driver,
> +};
> +
> +static int __init xen_cpufreq_init(void)
> +{
> +	int ret;
> +	int i;
> +
> +	struct xen_sysctl op = {
> +		.cmd			= XEN_SYSCTL_physinfo,
> +		.interface_version	= XEN_SYSCTL_INTERFACE_VERSION,
> +	};
> +
> +	ret = HYPERVISOR_sysctl(&op);
> +	if (ret) {
> +		pr_err("Hypervisor get physinfo error (%d)\n", ret);
> +		return ret;
> +	}
> +
> +	xen_nr_cpus = op.u.physinfo.nr_cpus;
> +	if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
> +		xen_nr_cpus = 0;
> +		pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
> +		return -EINVAL;
> +	}
> +
> +	for (i = 0; i < xen_nr_cpus; i++) {
> +		per_cpu(cpufreq_policy_cpu, i) = -1;
> +		init_rwsem(&per_cpu(cpu_policy_rwsem, i));
> +	}
> +
> +	cpufreq_wq = alloc_workqueue("xen_cpufreq", 0, 1);
> +	if (!cpufreq_wq) {
> +		pr_err("Create workqueue error\n");
> +		ret = -ENOMEM;
> +		goto err_create_wq;
> +	}
> +
> +	return 0;
> +
> +err_create_wq:
> +	xen_nr_cpus = 0;
> +	return ret;
> +}
> +
> +MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
> +MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
> +MODULE_LICENSE("GPL");
> +
> +core_initcall(xen_cpufreq_init);
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index c57d5f6..ee3b154 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
>  #define XEN_PX_PSS   2
>  #define XEN_PX_PPC   4
>  #define XEN_PX_PSD   8
> +#define XEN_PX_DATA  16
>  
>  struct xen_power_register {
>  	uint32_t     space_id;
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index cf64566..9133110 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -81,6 +81,7 @@
>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
>  #define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
> +#define VIRQ_CPUFREQ    14 /* (DOM0) Notify cpufreq driver                */
>  
>  /* 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 Nov 04 16:34:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:34:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlh46-0000v7-DS; Tue, 04 Nov 2014 16:34:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xlh45-0000v0-M4
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:34:41 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	52/4B-02954-12009545; Tue, 04 Nov 2014 16:34:41 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415118877!12538319!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23455 invoked from network); 4 Nov 2014 16:34:39 -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;
	4 Nov 2014 16:34:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="187982717"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 11:33:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlh3C-0002Sb-93;
	Tue, 04 Nov 2014 16:33:46 +0000
Date: Tue, 4 Nov 2014 16:33:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Message-ID: <alpine.DEB.2.02.1411041621380.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH v4 9/9] xen/arm: cpufreq: add
	xen-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> Xen changes frequencies on CPUs using this high-level
> cpufreq driver.
> 
> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>

You CC the wrong email address for Rafael in the entire series.


>  drivers/cpufreq/Kconfig           |  20 +
>  drivers/cpufreq/Makefile          |   1 +
>  drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
>  drivers/cpufreq/cpufreq_drv_ops.h |   4 +
>  drivers/cpufreq/xen-cpufreq.c     | 869 ++++++++++++++++++++++++++++++++++++++
>  include/xen/interface/platform.h  |   1 +
>  include/xen/interface/xen.h       |   1 +
>  7 files changed, 907 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/cpufreq/xen-cpufreq.c
> 
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index f5a8f84..4847d8a 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -19,6 +19,26 @@ config CPU_FREQ
>  
>  	  If in doubt, say N.
>  
> +config XEN_CPUFREQ
> +	bool "Xen Cpufreq driver"
> +	depends on XEN_DOM0
> +	depends on !CPUMASK_OFFSTACK
> +	default n
> +	select CPUFREQ_DRV_OPS
> +	help
> +	  This driver uploads Power Management information to the Xen
> +	  hypervisor and changes CPUs frequency using CPU Frequency scaling
> +	  drivers.
> +
> +	  To do that the driver uses CPU Frequency scaling drivers to parse
> +	  the Power Management data and uploads said information to the Xen
> +	  hypervisor. Then the Xen hypervisor can select the proper Pxx states.
> +
> +	  Then the Xen hypervisor can change CPUs frequency by giving commands
> +	  via this driver to the CPU Frequency scaling driver.
> +
> +	  If in doubt, say N.
> +
>  if CPUFREQ_DRV_OPS
>  
>  config CPU_FREQ_TABLE
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index f12a0d3..c8d5037 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -1,5 +1,6 @@
>  # CPUfreq core
>  obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
> +obj-$(CONFIG_XEN_CPUFREQ)		+= xen-cpufreq.o
>  obj-$(CONFIG_CPUFREQ_DRV_OPS)		+= cpufreq_drv_ops.o
>  # CPUfreq stats
>  obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
> diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
> index c971442..71c3357 100644
> --- a/drivers/cpufreq/cpufreq_drv_ops.c
> +++ b/drivers/cpufreq/cpufreq_drv_ops.c
> @@ -18,6 +18,8 @@
>  #include <linux/init.h>
>  #include <linux/export.h>
>  
> +#include <xen/xen.h>
> +
>  static struct cpufreq_drv_ops *ops;
>  
>  struct kobject *get_cpufreq_global_kobject(void)
> @@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
>  
>  static int __init cpufreq_drv_ops_init(void)
>  {
> +	if (xen_initial_domain()) {
> +#ifdef CONFIG_XEN_CPUFREQ
> +		ops = &xen_cpufreq_drv_ops;
> +		pr_debug("using xen_cpufreq_drv_ops\n");
> +#endif
> +	} else {
>  #ifdef CONFIG_CPU_FREQ
> -	ops = &kern_cpufreq_drv_ops;
> -	pr_debug("using kern_cpufreq_drv_ops\n");
> +		ops = &kern_cpufreq_drv_ops;
> +		pr_debug("using kern_cpufreq_drv_ops\n");
>  #endif
> +	}
>  
>  	return 0;
>  }
> diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
> index 5cc8e05..d02d509 100644
> --- a/drivers/cpufreq/cpufreq_drv_ops.h
> +++ b/drivers/cpufreq/cpufreq_drv_ops.h
> @@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
>  extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
>  #endif
>  
> +#ifdef CONFIG_XEN_CPUFREQ
> +extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
> +#endif
> +
>  #endif /* _CPUFREQ_DRV_OPS_H */
> diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
> new file mode 100644
> index 0000000..21062c7
> --- /dev/null
> +++ b/drivers/cpufreq/xen-cpufreq.c
> @@ -0,0 +1,869 @@
> +/*
> + *  Copyright (C) 2001 Russell King
> + *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
> + *
> + *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
> + *	Added handling for CPU hotplug
> + *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
> + *	Fix handling for CPU hotplug -- affected CPUs
> + *
> + *           (C) 2014 GlobalLogic Inc.
> + *
> + * Based on drivers/cpufreq/cpufreq.c
> + *
> + * 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.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/notifier.h>
> +#include <linux/types.h>
> +#include <linux/slab.h>
> +#include <linux/mutex.h>
> +#include <linux/irq.h>
> +#include <linux/workqueue.h>
> +#include <linux/cpufreq.h>
> +
> +#include <trace/events/power.h>
> +
> +#include <xen/xen.h>
> +#include <xen/events.h>
> +#include <xen/interface/xen.h>
> +#include <xen/interface/platform.h>
> +#include <xen/interface/sysctl.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/xen/hypervisor.h>
> +
> +#include "cpufreq_drv_ops.h"
> +
> +static int xen_nr_cpus;
> +static int xen_irq;
> +
> +#define for_each_xen_cpu(cpu, mask)			\
> +	for ((cpu) = -1;				\
> +		(cpu) = cpumask_next((cpu), (mask)),	\
> +		(cpu) < xen_nr_cpus;)
> +
> +static struct cpufreq_driver *cpufreq_driver;
> +static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
> +
> +static DEFINE_SPINLOCK(cpufreq_driver_lock);
> +
> +/*
> + * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
> + * all cpufreq/hotplug/workqueue/etc related lock issues.
> + *
> + * The rules for this semaphore:
> + * - Any routine that wants to read from the policy structure will
> + *   do a down_read on this semaphore.
> + * - Any routine that will write to the policy structure and/or may take away
> + *   the policy altogether (eg. CPU hotplug), will hold this lock in write
> + *   mode before doing so.
> + *
> + * Additional rules:
> + * - Governor routines that can be called in cpufreq hotplug path should not
> + *   take this sem as top level hotplug notifier handler takes this.
> + * - Lock should not be held across
> + *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
> + */
> +static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
> +static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
> +
> +#define lock_policy_rwsem(mode, cpu)				\
> +static int lock_policy_rwsem_##mode				\
> +(int cpu)							\
> +{								\
> +	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);	\
> +	BUG_ON(policy_cpu == -1);				\
> +	down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));	\
> +								\
> +	return 0;						\
> +}
> +
> +lock_policy_rwsem(write, cpu);
> +
> +static void unlock_policy_rwsem_write(int cpu)
> +{
> +	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
> +	BUG_ON(policy_cpu == -1);
> +	up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
> +}
> +
> +/**
> + * The "transition" notifier list for kernel code that needs to handle
> + * changes to devices when the CPU clock speed changes.
> + * The mutex locks this list.
> + */
> +static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
> +
> +static bool init_cpufreq_transition_notifier_list_called;
> +static int __init init_cpufreq_transition_notifier_list(void)
> +{
> +	srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
> +	init_cpufreq_transition_notifier_list_called = true;
> +	return 0;
> +}
> +pure_initcall(init_cpufreq_transition_notifier_list);
> +
> +static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
> +{
> +	struct cpufreq_policy *data = NULL;
> +	unsigned long flags;
> +
> +	if (cpu >= xen_nr_cpus)
> +		goto err_out;
> +
> +	/* get the cpufreq driver */
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +
> +	if (!cpufreq_driver)
> +		goto err_out_unlock;
> +
> +	/* get the CPU */
> +	data = per_cpu(cpufreq_cpu_data, cpu);
> +
> +err_out_unlock:
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +err_out:
> +	return data;
> +}
> +
> +static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
> +{
> +	module_put(cpufreq_driver->owner);
> +}
> +
> +static int push_data_to_hypervisor(struct cpufreq_policy *policy,
> +				   struct cpufreq_frequency_table *table)
> +{
> +	int ret = 0;
> +	unsigned int i;
> +	unsigned int cpu;
> +	uint32_t platform_limit = 0;
> +	unsigned int max_freq = 0;
> +	unsigned int state_count = 0;
> +	unsigned int prev_freq = 0;
> +	struct xen_processor_px *dst_states;
> +	struct xen_processor_performance *dst_perf;
> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_set_processor_pminfo,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.set_pminfo.type	= XEN_PM_PX,
> +	};
> +
> +	dst_perf = &op.u.set_pminfo.perf;
> +
> +	/* Check freq table and find max frequency */
> +	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> +		unsigned int freq = table[i].frequency;
> +		if (freq == CPUFREQ_ENTRY_INVALID)
> +			continue;
> +
> +		if (table[i].index != state_count || freq <= prev_freq) {
> +			pr_err("Frequency table format error\n");
> +			return -EINVAL;
> +		}
> +
> +		prev_freq = freq;
> +		state_count++;
> +		if (freq > max_freq)
> +			max_freq = freq;
> +	}
> +
> +	if (!state_count)
> +		return -EINVAL;
> +
> +	dst_perf->state_count = state_count;
> +
> +	dst_states = kcalloc(state_count,
> +			     sizeof(struct xen_processor_px), GFP_KERNEL);
> +
> +	if (!dst_states)
> +		return -ENOMEM;
> +
> +	set_xen_guest_handle(dst_perf->states, dst_states);
> +
> +	/*
> +	 * Freq table should start from lower values
> +	 * dst_states should start from higer values
> +	 */
> +	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> +		unsigned int freq = table[i].frequency;
> +		unsigned int tbl_index = state_count - 1 - table[i].index;
> +		if (freq == CPUFREQ_ENTRY_INVALID)
> +			continue;
> +
> +		if (freq == max_freq)
> +			platform_limit = tbl_index;
> +
> +		dst_states[tbl_index].core_frequency = freq / 1000;
> +		dst_states[tbl_index].transition_latency =
> +				policy->cpuinfo.transition_latency / 1000;
> +	}
> +
> +	dst_perf->shared_type = policy->shared_type;
> +	dst_perf->platform_limit = platform_limit;
> +	dst_perf->domain_info.domain = policy->cpu;
> +	dst_perf->domain_info.num_processors = xen_nr_cpus;
> +	dst_perf->flags = XEN_PX_DATA;
> +
> +	for_each_xen_cpu(cpu, policy->cpus) {
> +		op.u.set_pminfo.id = cpu;
> +		ret = HYPERVISOR_dom0_op(&op);
> +		if (ret) {
> +			pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
> +			goto err_free_states;
> +		}
> +		pr_debug("CPU%u - P-states uploaded\n", cpu);
> +
> +		for (i = 0; i < dst_perf->state_count; i++) {
> +			pr_debug("    state %d: %d MHz, %d uS\n",
> +				 i, (u32) dst_states[i].core_frequency,
> +				 (u32) dst_states[i].transition_latency);
> +		}
> +	}
> +
> +err_free_states:
> +	kfree(dst_states);
> +	return ret;
> +}
> +
> +/*
> + * Returns:
> + *   Negative: Failure
> + *   0:        Success
> + *   Positive: When we have a managed CPU and the sysfs got symlinked
> + */
> +static int xen_cpufreq_add_dev_policy(unsigned int cpu,
> +				  struct cpufreq_policy *policy)
> +{
> +	int ret = 0;
> +#ifdef CONFIG_SMP
> +	unsigned long flags;
> +	unsigned int j;
> +
> +	for_each_cpu(j, policy->cpus) {
> +		struct cpufreq_policy *managed_policy;
> +
> +		if (cpu == j)
> +			continue;
> +
> +		/* Check for existing affected CPUs.
> +		 * They may not be aware of it due to CPU Hotplug.
> +		 * cpufreq_cpu_put is called when the device is removed
> +		 * in __cpufreq_remove_dev()
> +		 */
> +		managed_policy = xen_cpufreq_cpu_get(j);
> +		if (unlikely(managed_policy)) {
> +			/* Set proper policy_cpu */
> +			unlock_policy_rwsem_write(cpu);
> +			per_cpu(cpufreq_policy_cpu, cpu) =
> +						managed_policy->cpu;
> +
> +			if (lock_policy_rwsem_write(cpu) < 0) {
> +				/* Should not go through policy unlock path */
> +				if (cpufreq_driver->exit)
> +					cpufreq_driver->exit(policy);
> +				xen_cpufreq_cpu_put(managed_policy);
> +				return -EBUSY;
> +			}
> +
> +			spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +			cpumask_copy(managed_policy->cpus, policy->cpus);
> +			per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
> +			spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +
> +			pr_debug("CPU already managed, adding link\n");
> +
> +			/*
> +			 * Success. We only needed to be added to the mask.
> +			 * Call driver->exit() because only the cpu parent of
> +			 * the kobj needed to call init().
> +			 */
> +			if (cpufreq_driver->exit)
> +				cpufreq_driver->exit(policy);
> +
> +			return 1;
> +		}
> +	}
> +#endif
> +	return ret;
> +}
> +
> +/**
> + * xen_cpufreq_add_dev - add a CPU device
> + *
> + * Adds the cpufreq interface for a CPU device.
> + */
> +static int xen_cpufreq_add_dev(unsigned int cpu)
> +{
> +	int ret = 0;
> +	struct cpufreq_policy *policy;
> +	unsigned long flags;
> +	unsigned int j;
> +
> +	pr_debug("adding CPU %u\n", cpu);
> +
> +#ifdef CONFIG_SMP
> +	/* check whether a different CPU already registered this
> +	 * CPU because it is in the same boat. */
> +	policy = xen_cpufreq_cpu_get(cpu);
> +	if (unlikely(policy)) {
> +		xen_cpufreq_cpu_put(policy);
> +		return 0;
> +	}
> +#endif
> +
> +	if (!try_module_get(cpufreq_driver->owner)) {
> +		ret = -EINVAL;
> +		goto module_out;
> +	}
> +
> +	ret = -ENOMEM;
> +	policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
> +	if (!policy)
> +		goto nomem_out;
> +
> +	if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
> +		goto err_free_policy;
> +
> +	if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
> +		goto err_free_cpumask;
> +
> +	policy->cpu = cpu;
> +	cpumask_copy(policy->cpus, cpumask_of(cpu));
> +
> +	/* Initially set CPU itself as the policy_cpu */
> +	per_cpu(cpufreq_policy_cpu, cpu) = cpu;
> +	ret = (lock_policy_rwsem_write(cpu) < 0);
> +	WARN_ON(ret);
> +
> +	/* call driver. From then on the cpufreq must be able
> +	 * to accept all calls to ->verify and ->setpolicy for this CPU
> +	 */
> +	ret = cpufreq_driver->init(policy);
> +	if (ret) {
> +		pr_debug("initialization failed\n");
> +		goto err_unlock_policy;
> +	}
> +	ret = xen_cpufreq_add_dev_policy(cpu, policy);
> +	if (ret) {
> +		if (ret > 0)
> +			/* This is a managed cpu, symlink created,
> +			   exit with 0 */
> +			ret = 0;
> +		goto err_unlock_policy;
> +	}
> +
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +	for_each_cpu(j, policy->cpus) {
> +		per_cpu(cpufreq_cpu_data, j) = policy;
> +		per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
> +	}
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +
> +	unlock_policy_rwsem_write(cpu);
> +
> +	module_put(cpufreq_driver->owner);
> +	pr_debug("initialization complete\n");
> +
> +	return 0;
> +
> +err_unlock_policy:
> +	unlock_policy_rwsem_write(cpu);
> +	free_cpumask_var(policy->related_cpus);
> +err_free_cpumask:
> +	free_cpumask_var(policy->cpus);
> +err_free_policy:
> +	kfree(policy);
> +nomem_out:
> +	module_put(cpufreq_driver->owner);
> +module_out:
> +	return ret;
> +}
> +
> +/**
> + * __cpufreq_remove_dev - remove a CPU device
> + *
> + * Removes the cpufreq interface for a CPU device.
> + * Caller should already have policy_rwsem in write mode for this CPU.
> + * This routine frees the rwsem before returning.
> + */
> +static int __cpufreq_remove_dev(unsigned int cpu)
> +{
> +	unsigned long flags;
> +	struct cpufreq_policy *data;
> +#ifdef CONFIG_SMP
> +	unsigned int j;
> +#endif
> +
> +	pr_debug("unregistering CPU %u\n", cpu);
> +
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +	data = per_cpu(cpufreq_cpu_data, cpu);
> +
> +	if (!data) {
> +		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +		unlock_policy_rwsem_write(cpu);
> +		return -EINVAL;
> +	}
> +	per_cpu(cpufreq_cpu_data, cpu) = NULL;
> +
> +
> +#ifdef CONFIG_SMP
> +	/* if this isn't the CPU which is the parent of the kobj, we
> +	 * only need to unlink, put and exit
> +	 */
> +	if (unlikely(cpu != data->cpu)) {
> +		pr_debug("removing link\n");
> +		cpumask_clear_cpu(cpu, data->cpus);
> +		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +		xen_cpufreq_cpu_put(data);
> +		unlock_policy_rwsem_write(cpu);
> +		return 0;
> +	}
> +#endif
> +
> +#ifdef CONFIG_SMP
> +
> +	/* if we have other CPUs still registered, we need to unlink them,
> +	 * or else wait_for_completion below will lock up. Clean the
> +	 * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
> +	 * the sysfs links afterwards.
> +	 */
> +	if (unlikely(cpumask_weight(data->cpus) > 1)) {
> +		for_each_cpu(j, data->cpus) {
> +			if (j == cpu)
> +				continue;
> +			per_cpu(cpufreq_cpu_data, j) = NULL;
> +		}
> +	}
> +
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +
> +	if (unlikely(cpumask_weight(data->cpus) > 1)) {
> +		for_each_cpu(j, data->cpus) {
> +			if (j == cpu)
> +				continue;
> +			pr_debug("removing link for cpu %u\n", j);
> +			unlock_policy_rwsem_write(cpu);
> +			lock_policy_rwsem_write(cpu);
> +			xen_cpufreq_cpu_put(data);
> +		}
> +	}
> +#else
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +#endif
> +
> +	unlock_policy_rwsem_write(cpu);
> +
> +	lock_policy_rwsem_write(cpu);
> +	if (cpufreq_driver->exit)
> +		cpufreq_driver->exit(data);
> +	unlock_policy_rwsem_write(cpu);
> +
> +	free_cpumask_var(data->related_cpus);
> +	free_cpumask_var(data->cpus);
> +	kfree(data);
> +
> +	return 0;
> +}
> +
> +static int cpufreq_remove_dev(unsigned int cpu)
> +{
> +	int retval;
> +
> +	if (unlikely(lock_policy_rwsem_write(cpu)))
> +		BUG();
> +
> +	retval = __cpufreq_remove_dev(cpu);
> +	return retval;
> +}
> +
> +/*********************************************************************
> + *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
> + *********************************************************************/
> +
> +/**
> + * adjust_jiffies - adjust the system "loops_per_jiffy"
> + *
> + * This function alters the system "loops_per_jiffy" for the clock
> + * speed change. Note that loops_per_jiffy cannot be updated on SMP
> + * systems as each CPU might be scaled differently. So, use the arch
> + * per-CPU loops_per_jiffy value wherever possible.
> + */
> +#ifndef CONFIG_SMP
> +static unsigned long l_p_j_ref;
> +static unsigned int  l_p_j_ref_freq;
> +
> +static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
> +{
> +	if (ci->flags & CPUFREQ_CONST_LOOPS)
> +		return;
> +
> +	if (!l_p_j_ref_freq) {
> +		l_p_j_ref = loops_per_jiffy;
> +		l_p_j_ref_freq = ci->old;
> +		pr_debug("saving %lu as reference value for loops_per_jiffy; "
> +			"freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
> +	}
> +	if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
> +	    (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
> +		loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
> +								ci->new);
> +		pr_debug("scaling loops_per_jiffy to %lu "
> +			"for frequency %u kHz\n", loops_per_jiffy, ci->new);
> +	}
> +}
> +#else
> +static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
> +{
> +	return;
> +}
> +#endif

There is quite a lot of code duplication with cpufreq.c, I don't think
that is going to be acceptable for the upstream maintainers.


> +/**
> + * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
> + * on frequency transition.
> + *
> + * This function calls the transition notifiers and the "adjust_jiffies"
> + * function. It is called twice on all CPU frequency changes that have
> + * external effects.
> + */
> +void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
> +				   unsigned int state)
> +{
> +	struct cpufreq_policy *policy;
> +
> +	BUG_ON(irqs_disabled());
> +
> +	freqs->flags = cpufreq_driver->flags;
> +	pr_debug("notification %u of frequency transition to %u kHz\n",
> +		 state, freqs->new);
> +
> +	policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
> +	switch (state) {
> +	case CPUFREQ_PRECHANGE:
> +		/* detect if the driver reported a value as "old frequency"
> +		 * which is not equal to what the cpufreq core thinks is
> +		 * "old frequency".
> +		 */
> +		if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
> +			if ((policy) && (policy->cpu == freqs->cpu) &&
> +			    (policy->cur) && (policy->cur != freqs->old)) {
> +				pr_debug("Warning: CPU frequency is"
> +					 " %u, cpufreq assumed %u kHz.\n",
> +					 freqs->old, policy->cur);
> +				freqs->old = policy->cur;
> +			}
> +		}
> +		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
> +					 CPUFREQ_PRECHANGE, freqs);
> +		adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
> +		break;
> +
> +	case CPUFREQ_POSTCHANGE:
> +		adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
> +		pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
> +			 (unsigned long)freqs->cpu);
> +		trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
> +		trace_cpu_frequency(freqs->new, freqs->cpu);
> +		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
> +					 CPUFREQ_POSTCHANGE, freqs);
> +		if (likely(policy) && likely(policy->cpu == freqs->cpu))
> +			policy->cur = freqs->new;
> +		break;
> +	}
> +}
> +
> +/*********************************************************************
> + *                              GOVERNORS                            *
> + *********************************************************************/
> +
> +int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
> +				unsigned int target_freq,
> +				unsigned int relation)
> +{
> +	int retval = -EINVAL;
> +	unsigned int old_target_freq = target_freq;
> +
> +	/* Make sure that target_freq is within supported range */
> +	if (target_freq > policy->max)
> +		target_freq = policy->max;
> +	if (target_freq < policy->min)
> +		target_freq = policy->min;
> +
> +	pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
> +		 policy->cpu, target_freq, relation, old_target_freq);
> +
> +	if (target_freq == policy->cur)
> +		return 0;
> +
> +	if (cpufreq_driver->target)
> +		retval = cpufreq_driver->target(policy, target_freq,
> +						    relation);
> +
> +	return retval;
> +}
> +
> +int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
> +			      unsigned int target_freq,
> +			      unsigned int relation)
> +{
> +	int ret = -EINVAL;
> +
> +	if (!policy)
> +		goto no_policy;
> +
> +	if (unlikely(lock_policy_rwsem_write(policy->cpu)))
> +		goto fail;
> +
> +	ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
> +
> +	unlock_policy_rwsem_write(policy->cpu);
> +
> +fail:
> +	xen_cpufreq_cpu_put(policy);
> +no_policy:
> +	return ret;
> +}
> +
> +/*********************************************************************
> + *                    HANDLE COMMANDS FROM XEN                       *
> + *********************************************************************/
> +static void cpufreq_work_hnd(struct work_struct *w);
> +
> +static struct workqueue_struct *cpufreq_wq;
> +static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
> +
> +static void cpufreq_work_hnd(struct work_struct *w)
> +{
> +	int ret;
> +	struct cpufreq_policy *policy;
> +	struct cpufreq_sh_info *cpufreq_info;
> +
> +	cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
> +
> +	policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
> +	ret = xen_cpufreq_driver_target(policy,
> +					cpufreq_info->freq,
> +					cpufreq_info->relation);
> +
> +	cpufreq_info->result = ret;
> +}

No barriers? No locking?


> +static irqreturn_t cpufreq_interrupt(int irq, void *data)
> +{
> +	queue_work(cpufreq_wq, &cpufreq_work);
> +	return IRQ_HANDLED;
> +}
> +
> +/*********************************************************************
> + *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
> + *********************************************************************/
> +
> +/**
> + * xen_cpufreq_register_driver - register a CPU Frequency driver
> + * @driver_data: A struct cpufreq_driver containing the values#
> + * submitted by the CPU Frequency driver.
> + *
> + *   Registers a CPU Frequency driver to this core code. This code
> + * returns zero on success, -EBUSY when another driver got here first
> + * (and isn't unregistered in the meantime).
> + *
> + */
> +int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
> +{
> +	unsigned long flags;
> +	int ret;
> +	unsigned int cpu;
> +	struct cpufreq_frequency_table *table;
> +	struct cpufreq_policy *policy;
> +	cpumask_var_t pushed_cpus;
> +	int irq;
> +
> +	if (!xen_nr_cpus)
> +		return -EPROBE_DEFER;
> +
> +	if (!driver_data || !driver_data->verify || !driver_data->init ||
> +	    (!driver_data->target))
> +		return -EINVAL;
> +
> +	pr_debug("trying to register driver %s\n", driver_data->name);
> +
> +	if (driver_data->setpolicy)
> +		driver_data->flags |= CPUFREQ_CONST_LOOPS;
> +
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +
> +	if (cpufreq_driver) {
> +		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +		return -EBUSY;
> +	}
> +	cpufreq_driver = driver_data;
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +
> +	irq = bind_virq_to_irq(VIRQ_CPUFREQ, 0);
> +	if (irq < 0) {
> +		pr_err("Bind virq (%d) error (%d)\n", VIRQ_CPUFREQ, irq);
> +		ret = irq;
> +		goto err_remove_drv;
> +	}
> +
> +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN|IRQ_NOPROBE);
> +
> +	ret = request_irq(irq, cpufreq_interrupt, 0,
> +			   "xen_cpufreq", NULL);
> +
> +	if (ret < 0) {
> +		pr_err("Request irq (%d) error (%d)\n", irq, ret);
> +		goto err_unbind_from_irqhnd;
> +	}
> +
> +	xen_irq = irq;
> +
> +	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
> +		ret = xen_cpufreq_add_dev(cpu);
> +		if (ret)
> +			goto err_remove_cpu;
> +	}
> +
> +	if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
> +		goto err_remove_cpu;
> +
> +	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
> +		if (cpumask_test_cpu(cpu, pushed_cpus))
> +			continue;
> +
> +		policy = xen_cpufreq_cpu_get(cpu);
> +		if (!policy) {
> +			ret = -EINVAL;
> +			goto err_free_cpumask;
> +		}
> +
> +		cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
> +		table = cpufreq_frequency_get_table(policy->cpu);
> +		if (!table) {
> +			ret = -EINVAL;
> +			goto err_free_cpumask;
> +		}
> +
> +		ret = push_data_to_hypervisor(policy, table);
> +		if (ret)
> +			goto err_free_cpumask;
> +	}
> +
> +	free_cpumask_var(pushed_cpus);
> +
> +	pr_debug("driver %s up and running\n", driver_data->name);
> +
> +	return 0;
> +
> +err_free_cpumask:
> +	free_cpumask_var(pushed_cpus);
> +err_remove_cpu:
> +	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
> +		cpufreq_remove_dev(cpu);
> +err_unbind_from_irqhnd:
> +	unbind_from_irqhandler(irq, NULL);
> +err_remove_drv:
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +	cpufreq_driver = NULL;
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +	return ret;
> +}
> +
> +/**
> + * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
> + *
> + *    Unregister the current CPUFreq driver. Only call this if you have
> + * the right to do so, i.e. if you have succeeded in initialising before!
> + * Returns zero if successful, and -EINVAL if the cpufreq_driver is
> + * currently not initialised.
> + */
> +int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
> +{
> +	unsigned long flags;
> +	unsigned int cpu;
> +
> +	if (!cpufreq_driver || (driver != cpufreq_driver))
> +		return -EINVAL;
> +
> +	pr_debug("unregistering driver %s\n", driver->name);
> +
> +	unbind_from_irqhandler(xen_irq, NULL);
> +
> +	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
> +		cpufreq_remove_dev(cpu);
> +
> +	spin_lock_irqsave(&cpufreq_driver_lock, flags);
> +	cpufreq_driver = NULL;
> +	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +
> +	return 0;
> +}
> +
> +struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
> +	.notify_transition = xen_cpufreq_notify_transition,
> +	.register_driver = xen_cpufreq_register_driver,
> +	.unregister_driver = xen_cpufreq_unregister_driver,
> +};
> +
> +static int __init xen_cpufreq_init(void)
> +{
> +	int ret;
> +	int i;
> +
> +	struct xen_sysctl op = {
> +		.cmd			= XEN_SYSCTL_physinfo,
> +		.interface_version	= XEN_SYSCTL_INTERFACE_VERSION,
> +	};
> +
> +	ret = HYPERVISOR_sysctl(&op);
> +	if (ret) {
> +		pr_err("Hypervisor get physinfo error (%d)\n", ret);
> +		return ret;
> +	}
> +
> +	xen_nr_cpus = op.u.physinfo.nr_cpus;
> +	if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
> +		xen_nr_cpus = 0;
> +		pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
> +		return -EINVAL;
> +	}
> +
> +	for (i = 0; i < xen_nr_cpus; i++) {
> +		per_cpu(cpufreq_policy_cpu, i) = -1;
> +		init_rwsem(&per_cpu(cpu_policy_rwsem, i));
> +	}
> +
> +	cpufreq_wq = alloc_workqueue("xen_cpufreq", 0, 1);
> +	if (!cpufreq_wq) {
> +		pr_err("Create workqueue error\n");
> +		ret = -ENOMEM;
> +		goto err_create_wq;
> +	}
> +
> +	return 0;
> +
> +err_create_wq:
> +	xen_nr_cpus = 0;
> +	return ret;
> +}
> +
> +MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
> +MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
> +MODULE_LICENSE("GPL");
> +
> +core_initcall(xen_cpufreq_init);
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index c57d5f6..ee3b154 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
>  #define XEN_PX_PSS   2
>  #define XEN_PX_PPC   4
>  #define XEN_PX_PSD   8
> +#define XEN_PX_DATA  16
>  
>  struct xen_power_register {
>  	uint32_t     space_id;
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index cf64566..9133110 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -81,6 +81,7 @@
>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
>  #define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
> +#define VIRQ_CPUFREQ    14 /* (DOM0) Notify cpufreq driver                */
>  
>  /* 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 Nov 04 16:36:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlh5v-00016J-3w; Tue, 04 Nov 2014 16:36:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xlh5t-00016A-O0
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:36:34 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	8E/D1-02576-19009545; Tue, 04 Nov 2014 16:36:33 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415118989!12504481!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16007 invoked from network); 4 Nov 2014 16:36:29 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-27.messagelabs.com with SMTP;
	4 Nov 2014 16:36:29 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 04 Nov 2014 08:34:17 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="411252790"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Nov 2014 08:25:38 -0800
Received: from pgsmsx107.gar.corp.intel.com (10.221.44.105) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 00:34:05 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 00:34:05 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.3]) with mapi id
	14.03.0195.001; Wed, 5 Nov 2014 00:34:04 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP9199KlhH4xypD06jTqC2+4O7eZxQq08w
Date: Tue, 4 Nov 2014 16:34:03 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E81F8B2@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<54577143.7040909@redhat.com>
In-Reply-To: <54577143.7040909@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, November 03, 2014 8:13 PM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: stefano.stabellini@eu.citrix.com; xen-devel@lists.xen.org
> Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> 
> 
> On 02/11/2014 07:39, Quan Xu wrote:
> > This drvier transfers any request/repond between TPM xenstubdoms
> > driver and Xen vTPM stubdom, and facilitates communications between
> > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > ---
> >  hw/xen/Makefile.objs         |   1 +
> >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> >  hw/xen/xen_stubdom_vtpm.c    | 333
> +++++++++++++++++++++++++++++++++++++++++++
> >  include/hw/xen/xen_backend.h |  11 ++
> >  include/hw/xen/xen_common.h  |   6 +
> >  xen-hvm.c                    |  13 ++
> >  6 files changed, 544 insertions(+), 2 deletions(-)  create mode
> > 100644 hw/xen/xen_stubdom_vtpm.c
> >
> > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs index
> > a0ca0aa..724df8d 100644
> > --- a/hw/xen/Makefile.objs
> > +++ b/hw/xen/Makefile.objs
> > @@ -1,5 +1,6 @@
> >  # xen backend driver support
> >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> xen_devconfig.o
> > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> >
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> xen_pt_config_init.o
> > xen_pt_msi.o diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> > index b2cb22b..45a5778 100644
> > --- a/hw/xen/xen_backend.c
> > +++ b/hw/xen/xen_backend.c
> > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev,
> enum xenbus_state state)
> >      return 0;
> >  }
> >
> > +/*get stubdom backend*/
> > +static char *xen_stubdom_be(const char *type, int dom, int dev) {
> > +    char *val, *domu;
> > +    char path[XEN_BUFSIZE];
> > +    unsigned int len, ival;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, dom);
> > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > +             domu, type, dev);
> > +    g_free(domu);
> > +
> > +    val = xs_read(xenstore, 0, path, &len);
> > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > +        g_free(val);
> > +        return NULL;
> > +    }
> > +    g_free(val);
> > +
> > +    /*backend domu*/
> > +    domu = xs_get_domain_path(xenstore, ival);
> > +
> > +    return domu;
> > +}
> > +
> >  /* ------------------------------------------------------------- */
> >
> >  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int
> > dev) @@ -222,6 +248,7 @@ static struct XenDevice
> *xen_be_get_xendev(const char *type, int dom, int dev,
> >                                             struct XenDevOps *ops)
> {
> >      struct XenDevice *xendev;
> > +    char *stub;
> >
> >      xendev = xen_be_find_xendev(type, dom, dev);
> >      if (xendev) {
> > @@ -235,8 +262,15 @@ static struct XenDevice
> *xen_be_get_xendev(const char *type, int dom, int dev,
> >      xendev->dev   = dev;
> >      xendev->ops   = ops;
> >
> > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > -             xendev->type, xendev->dom, xendev->dev);
> > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> xendev->dev);
> > +        snprintf(xendev->be, sizeof(xendev->be),
> "%s/backend/%s/%d/%d",
> > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > +        g_free(stub);
> > +    } else {
> > +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > +                 xendev->type, xendev->dom, xendev->dev);
> > +    }
> >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> >               xendev->type, xendev->dev);
> >
> > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int
> dom, struct XenDevOps *ops)
> >      return 0;
> >  }
> >
> > +static void stubdom_update_be(char *watch, char *type, int dom,
> > +                              struct XenDevOps *ops) {
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE];
> > +    char *ptr, *bepath;
> > +    unsigned int len, dev;
> > +
> > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > +        return;
> > +    }
> > +
> > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > +    ptr = strstr(watch, path);
> > +    if (ptr == NULL) {
> > +        return;
> > +    }
> > +
> > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > +        strcpy(path, "");
> > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > +            dev = -1;
> > +        }
> > +    }
> > +
> > +    if (dev == -1) {
> > +        return;
> > +    }
> > +
> > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > +    if (xendev != NULL) {
> > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > +        if (bepath == NULL) {
> > +            xen_be_del_xendev(dom, dev);
> > +        } else {
> > +            free(bepath);
> > +            xen_be_backend_changed(xendev, path);
> > +        }
> > +    }
> > +}
> > +
> >  static void xenstore_update_be(char *watch, char *type, int dom,
> >                                 struct XenDevOps *ops)  { @@
> -681,6
> > +756,10 @@ static void xenstore_update(void *unused)
> >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> >      }
> > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> PRIxPTR,
> > +               &type, &dom, &ops) == 3) {
> > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom,
> (void *)ops);
> > +    }
> >
> >  cleanup:
> >      free(vec);
> > @@ -732,11 +811,74 @@ err:
> >      return -1;
> >  }
> >
> > +int xen_vtpm_register(struct XenDevOps *ops) {
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > +    char *domu;
> > +    unsigned int cdev, j, rc;
> > +    const char *type = "vtpm";
> > +    char **dev = NULL;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > +    snprintf(path, sizeof(path), "%s/device/%s",
> > +             domu, type);
> > +    free(domu);
> > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > +    if (dev == NULL) {
> > +        return 0;
> > +    }
> > +
> > +    for (j = 0; j < cdev; j++) {
> > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> ops);
> > +        if (xendev == NULL) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> NULL.\n");
> > +            continue;
> > +        }
> > +
> > +        if (xendev->ops->initialise) {
> > +            rc = xendev->ops->initialise(xendev);
> > +
> > +            /*if initialise failed, delete it*/
> > +            if (rc != 0) {
> > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > +                continue;
> > +            }
> > +        }
> > +
> > +        /*setup watch*/
> > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > +                 type, xen_domid, xendev->ops);
> > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> failed.\n");
> > +            return -1;
> > +        }
> > +    }
> > +
> > +    free(dev);
> > +    return 0;
> > +}
> > +
> >  int xen_be_register(const char *type, struct XenDevOps *ops)  {
> >      return xenstore_scan(type, xen_domid, ops);  }
> >
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > +remote_dom) {
> > +    xendev->local_port =
> xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > +
> remote_dom);
> > +    if (xendev->local_port == -1) {
> > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> > +        return -1;
> > +    }
> > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> xendev->local_port);
> > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > +                        xen_be_evtchn_event, NULL, xendev);
> > +    return 0;
> > +}
> > +
> >  int xen_be_bind_evtchn(struct XenDevice *xendev)  {
> >      if (xendev->local_port != -1) {
> > @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice
> *xendev)
> >      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
> > }
> >
> > +int xen_vtpm_send(unsigned char *buf, size_t count) {
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->send) {
> > +        rc = xendev->ops->send(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> > +
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count) {
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->recv) {
> > +        xendev->ops->recv(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> > +
> >  /*
> >   * msg_level:
> >   *  0 == errors (stderr + logfile).
> > diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> new
> > file mode 100644 index 0000000..0d740c1
> > --- /dev/null
> > +++ b/hw/xen/xen_stubdom_vtpm.c
> > @@ -0,0 +1,333 @@
> > +/*
> > + * Connect to Xen vTPM stubdom domain
> > + *
> > + *  Copyright (c) 2014 Intel Corporation
> > + *  Authors:
> > + *    Quan Xu <quan.xu@intel.com>
> > + *
> > + * 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 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, see
> > +<http://www.gnu.org/licenses/>  */
> > +
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <stdarg.h>
> > +#include <string.h>
> > +#include <unistd.h>
> > +#include <signal.h>
> > +#include <inttypes.h>
> > +#include <time.h>
> > +#include <fcntl.h>
> > +#include <errno.h>
> > +#include <sys/ioctl.h>
> > +#include <sys/types.h>
> > +#include <sys/stat.h>
> > +#include <sys/mman.h>
> > +#include <sys/uio.h>
> > +
> > +#include "hw/hw.h"
> > +#include "block/aio.h"
> > +#include "hw/xen/xen_backend.h"
> > +
> > +enum tpmif_state {
> > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> complete */
> > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> > +};
> > +
> > +static AioContext *vtpm_aio_ctx;
> > +
> > +enum status_bits {
> > +    VTPM_STATUS_RUNNING  = 0x1,
> > +    VTPM_STATUS_IDLE     = 0x2,
> > +    VTPM_STATUS_RESULT   = 0x4,
> > +    VTPM_STATUS_CANCELED = 0x8,
> > +};
> > +
> > +struct tpmif_shared_page {
> > +    uint32_t length;         /* request/response length in bytes */
> > +
> > +    uint8_t  state;           /* enum tpmif_state */
> > +    uint8_t  locality;        /* for the current request */
> > +    uint8_t  pad;             /* should be zero */
> > +
> > +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be
> zero */
> > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> > +nr_extra_pages */ };
> > +
> > +struct QEMUBH {
> > +    AioContext *ctx;
> > +    QEMUBHFunc *cb;
> > +    void *opaque;
> > +    QEMUBH *next;
> > +    bool scheduled;
> > +    bool idle;
> > +    bool deleted;
> > +};
> 
> This is a private structure, you cannot just copy the definition here.
> 
> You do not even need it in fact, since sr_bh->ctx is always vtpm_aio_ctx.
> 
> Paolo
> 


Thanks Paolo, I will enhance it in v2. 

Quan 
> 
> > +struct XenVtpmDev {
> > +    struct XenDevice xendev;  /* must be first */
> > +    struct           tpmif_shared_page *shr;
> > +    xc_gntshr        *xen_xcs;
> > +    int              ring_ref;
> > +    int              bedomid;
> > +    QEMUBH           *sr_bh;
> > +};
> > +
> > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev) {
> > +    switch (vtpmdev->shr->state) {
> > +    case TPMIF_STATE_IDLE:
> > +    case TPMIF_STATE_FINISH:
> > +        return VTPM_STATUS_IDLE;
> > +    case TPMIF_STATE_SUBMIT:
> > +    case TPMIF_STATE_CANCEL:
> > +        return VTPM_STATUS_RUNNING;
> > +    default:
> > +        return 0;
> > +    }
> > +}
> > +
> > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> > +xenbus_state xbus) {
> > +    xs_transaction_t xbt = XBT_NULL;
> > +
> > +    if (xendev->fe_state == xbus) {
> > +        return 0;
> > +    }
> > +
> > +    xendev->fe_state = xbus;
> > +
> > +retry_transaction:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto retry_transaction;
> > +        }
> > +    }
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static int vtpm_aio_wait(QEMUBH *qbh) {
> > +    return aio_poll(qbh->ctx, true);
> > +}
> > +
> > +static void sr_bh_handler(void *opaque) { }
> > +
> > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t
> > +*count) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset;
> > +
> > +    if (shr->state == TPMIF_STATE_IDLE) {
> > +        return -ECANCELED;
> > +    }
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > +    *count = shr->length;
> > +
> > +    return 0;
> > +}
> > +
> > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t
> > +count) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > +    shr->length = count;
> > +    barrier();
> > +    shr->state = TPMIF_STATE_SUBMIT;
> > +    xen_wmb();
> > +    xen_be_send_notify(&vtpmdev->xendev);
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    return count;
> > +}
> > +
> > +static int vtpm_initialise(struct XenDevice *xendev) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    xs_transaction_t xbt = XBT_NULL;
> > +    unsigned int ring_ref;
> > +
> > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> "frontend");
> > +    if (vtpmdev->xendev.fe == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /* Get backend domid */
> > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > +                             &vtpmdev->bedomid)) {
> > +        return -1;
> > +    }
> > +
> > +    /*alloc share page*/
> > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> vtpmdev->bedomid, 1,
> > +                                         &ring_ref,
> PROT_READ|PROT_WRITE);
> > +    vtpmdev->ring_ref = ring_ref;
> > +    if (vtpmdev->shr == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /*Create event channel */
> > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> vtpmdev->bedomid)) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +        return -1;
> > +    }
> > +
> > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > +                     vtpmdev->xendev.local_port);
> > +
> > +again:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > +                           vtpmdev->ring_ref)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > +                           vtpmdev->xendev.local_port)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    /* Publish protocol v2 feature */
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1))
> {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto again;
> > +        }
> > +    }
> > +    /* Tell vtpm backend that we are ready */
> > +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static void vtpm_backend_changed(struct XenDevice *xendev, const char
> > +*node) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    int be_state;
> > +
> > +    if (strcmp(node, "state") == 0) {
> > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > +        switch (be_state) {
> > +        case XenbusStateConnected:
> > +            /*TODO*/
> > +            break;
> > +        case XenbusStateClosing:
> > +        case XenbusStateClosed:
> > +            xenbus_switch_state(&vtpmdev->xendev,
> XenbusStateClosing);
> > +            break;
> > +        default:
> > +            break;
> > +        }
> > +    }
> > +}
> > +
> > +static int vtpm_free(struct XenDevice *xendev) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > +
> > +    aio_poll(qbh->ctx, false);
> > +    qemu_bh_delete(vtpmdev->sr_bh);
> > +    if (vtpmdev->shr) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    }
> > +    xc_interface_close(vtpmdev->xen_xcs);
> > +    return 0;
> > +}
> > +
> > +static void vtpm_alloc(struct XenDevice *xendev) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    vtpm_aio_ctx = aio_context_new(NULL);
> > +    if (vtpm_aio_ctx == NULL) {
> > +        return;
> > +    }
> > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> vtpmdev);
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0); }
> > +
> > +static void vtpm_event(struct XenDevice *xendev) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    qemu_bh_schedule(vtpmdev->sr_bh); }
> > +
> > +struct XenDevOps xen_vtpmdev_ops = {
> > +    .size             = sizeof(struct XenVtpmDev),
> > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > +                        DEVOPS_FLAG_STUBDOM_BE,
> > +    .event            = vtpm_event,
> > +    .free             = vtpm_free,
> > +    .alloc            = vtpm_alloc,
> > +    .initialise       = vtpm_initialise,
> > +    .backend_changed  = vtpm_backend_changed,
> > +    .recv             = vtpm_recv,
> > +    .send             = vtpm_send,
> > +};
> > diff --git a/include/hw/xen/xen_backend.h
> > b/include/hw/xen/xen_backend.h index 3b4125e..45fd6d3 100644
> > --- a/include/hw/xen/xen_backend.h
> > +++ b/include/hw/xen/xen_backend.h
> > @@ -15,6 +15,8 @@ struct XenDevice;
> >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> >  /* don't expect frontend doing correct state transitions (aka console
> > quirk) */  #define DEVOPS_FLAG_IGNORE_STATE  2
> > +/*dev backend is stubdom*/
> > +#define DEVOPS_FLAG_STUBDOM_BE    4
> >
> >  struct XenDevOps {
> >      size_t    size;
> > @@ -26,6 +28,8 @@ struct XenDevOps {
> >      void      (*event)(struct XenDevice *xendev);
> >      void      (*disconnect)(struct XenDevice *xendev);
> >      int       (*free)(struct XenDevice *xendev);
> > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> count);
> > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> *count);
> >      void      (*backend_changed)(struct XenDevice *xendev, const
> char *node);
> >      void      (*frontend_changed)(struct XenDevice *xendev, const
> char *node);
> >  };
> > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> *xendev);
> > void xen_be_printf(struct XenDevice *xendev, int msg_level, const char
> *fmt, ...)
> >      GCC_FMT_ATTR(3, 4);
> >
> > +/*Xen stubdom vtpm*/
> > +int xen_vtpm_register(struct XenDevOps *ops); int
> > +xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > +remote_dom); int xen_vtpm_send(unsigned char *buf, size_t count); int
> > +xen_vtpm_recv(unsigned char *buf, size_t *count);
> > +
> >  /* actual backend drivers */
> >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> */
> >  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c
> */
> >  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
> >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> */
> >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> */
> > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> xen_stubdom_vtpm.c*/
> >
> >  void xen_init_display(int domid);
> >
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 95612a4..fb43084 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void
> *logger, void *dombuild_logger,
> >      return xc_interface_open(logger, dombuild_logger, open_flags);  }
> >
> > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > +                                           unsigned int open_flags)
> {
> > +    return xc_gntshr_open(logger, open_flags); }
> > +
> >  /* FIXME There is now way to have the xen fd */  static inline int
> > xc_fd(xc_interface *xen_xc)  { diff --git a/xen-hvm.c b/xen-hvm.c
> > index 21f1cbb..c99ace8 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >      int i, rc;
> >      unsigned long ioreq_pfn;
> >      unsigned long bufioreq_evtchn;
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    unsigned long stubdom_vtpm = 0;
> > +#endif
> > +
> >      XenIOState *state;
> >
> >      state = g_malloc0(sizeof (XenIOState)); @@ -1169,6 +1174,14 @@
> > int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t
> *above_4g_mem_size,
> >          fprintf(stderr, "%s: xen backend core setup failed\n",
> __FUNCTION__);
> >          return -1;
> >      }
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    xc_get_hvm_param(xen_xc, xen_domid,
> HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > +    if (stubdom_vtpm) {
> > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > +    }
> > +#endif
> > +
> >      xen_be_register("console", &xen_console_ops);
> >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> >      xen_be_register("qdisk", &xen_blkdev_ops);
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:36:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlh5v-00016J-3w; Tue, 04 Nov 2014 16:36:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xlh5t-00016A-O0
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:36:34 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	8E/D1-02576-19009545; Tue, 04 Nov 2014 16:36:33 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415118989!12504481!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16007 invoked from network); 4 Nov 2014 16:36:29 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-27.messagelabs.com with SMTP;
	4 Nov 2014 16:36:29 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 04 Nov 2014 08:34:17 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="411252790"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Nov 2014 08:25:38 -0800
Received: from pgsmsx107.gar.corp.intel.com (10.221.44.105) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 00:34:05 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 00:34:05 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.3]) with mapi id
	14.03.0195.001; Wed, 5 Nov 2014 00:34:04 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP9199KlhH4xypD06jTqC2+4O7eZxQq08w
Date: Tue, 4 Nov 2014 16:34:03 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E81F8B2@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<54577143.7040909@redhat.com>
In-Reply-To: <54577143.7040909@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, November 03, 2014 8:13 PM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: stefano.stabellini@eu.citrix.com; xen-devel@lists.xen.org
> Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> 
> 
> On 02/11/2014 07:39, Quan Xu wrote:
> > This drvier transfers any request/repond between TPM xenstubdoms
> > driver and Xen vTPM stubdom, and facilitates communications between
> > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > ---
> >  hw/xen/Makefile.objs         |   1 +
> >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> >  hw/xen/xen_stubdom_vtpm.c    | 333
> +++++++++++++++++++++++++++++++++++++++++++
> >  include/hw/xen/xen_backend.h |  11 ++
> >  include/hw/xen/xen_common.h  |   6 +
> >  xen-hvm.c                    |  13 ++
> >  6 files changed, 544 insertions(+), 2 deletions(-)  create mode
> > 100644 hw/xen/xen_stubdom_vtpm.c
> >
> > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs index
> > a0ca0aa..724df8d 100644
> > --- a/hw/xen/Makefile.objs
> > +++ b/hw/xen/Makefile.objs
> > @@ -1,5 +1,6 @@
> >  # xen backend driver support
> >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> xen_devconfig.o
> > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> >
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> xen_pt_config_init.o
> > xen_pt_msi.o diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> > index b2cb22b..45a5778 100644
> > --- a/hw/xen/xen_backend.c
> > +++ b/hw/xen/xen_backend.c
> > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev,
> enum xenbus_state state)
> >      return 0;
> >  }
> >
> > +/*get stubdom backend*/
> > +static char *xen_stubdom_be(const char *type, int dom, int dev) {
> > +    char *val, *domu;
> > +    char path[XEN_BUFSIZE];
> > +    unsigned int len, ival;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, dom);
> > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > +             domu, type, dev);
> > +    g_free(domu);
> > +
> > +    val = xs_read(xenstore, 0, path, &len);
> > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > +        g_free(val);
> > +        return NULL;
> > +    }
> > +    g_free(val);
> > +
> > +    /*backend domu*/
> > +    domu = xs_get_domain_path(xenstore, ival);
> > +
> > +    return domu;
> > +}
> > +
> >  /* ------------------------------------------------------------- */
> >
> >  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int
> > dev) @@ -222,6 +248,7 @@ static struct XenDevice
> *xen_be_get_xendev(const char *type, int dom, int dev,
> >                                             struct XenDevOps *ops)
> {
> >      struct XenDevice *xendev;
> > +    char *stub;
> >
> >      xendev = xen_be_find_xendev(type, dom, dev);
> >      if (xendev) {
> > @@ -235,8 +262,15 @@ static struct XenDevice
> *xen_be_get_xendev(const char *type, int dom, int dev,
> >      xendev->dev   = dev;
> >      xendev->ops   = ops;
> >
> > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > -             xendev->type, xendev->dom, xendev->dev);
> > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> xendev->dev);
> > +        snprintf(xendev->be, sizeof(xendev->be),
> "%s/backend/%s/%d/%d",
> > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > +        g_free(stub);
> > +    } else {
> > +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > +                 xendev->type, xendev->dom, xendev->dev);
> > +    }
> >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> >               xendev->type, xendev->dev);
> >
> > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int
> dom, struct XenDevOps *ops)
> >      return 0;
> >  }
> >
> > +static void stubdom_update_be(char *watch, char *type, int dom,
> > +                              struct XenDevOps *ops) {
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE];
> > +    char *ptr, *bepath;
> > +    unsigned int len, dev;
> > +
> > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > +        return;
> > +    }
> > +
> > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > +    ptr = strstr(watch, path);
> > +    if (ptr == NULL) {
> > +        return;
> > +    }
> > +
> > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > +        strcpy(path, "");
> > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > +            dev = -1;
> > +        }
> > +    }
> > +
> > +    if (dev == -1) {
> > +        return;
> > +    }
> > +
> > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > +    if (xendev != NULL) {
> > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > +        if (bepath == NULL) {
> > +            xen_be_del_xendev(dom, dev);
> > +        } else {
> > +            free(bepath);
> > +            xen_be_backend_changed(xendev, path);
> > +        }
> > +    }
> > +}
> > +
> >  static void xenstore_update_be(char *watch, char *type, int dom,
> >                                 struct XenDevOps *ops)  { @@
> -681,6
> > +756,10 @@ static void xenstore_update(void *unused)
> >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> >      }
> > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> PRIxPTR,
> > +               &type, &dom, &ops) == 3) {
> > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom,
> (void *)ops);
> > +    }
> >
> >  cleanup:
> >      free(vec);
> > @@ -732,11 +811,74 @@ err:
> >      return -1;
> >  }
> >
> > +int xen_vtpm_register(struct XenDevOps *ops) {
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > +    char *domu;
> > +    unsigned int cdev, j, rc;
> > +    const char *type = "vtpm";
> > +    char **dev = NULL;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > +    snprintf(path, sizeof(path), "%s/device/%s",
> > +             domu, type);
> > +    free(domu);
> > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > +    if (dev == NULL) {
> > +        return 0;
> > +    }
> > +
> > +    for (j = 0; j < cdev; j++) {
> > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> ops);
> > +        if (xendev == NULL) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> NULL.\n");
> > +            continue;
> > +        }
> > +
> > +        if (xendev->ops->initialise) {
> > +            rc = xendev->ops->initialise(xendev);
> > +
> > +            /*if initialise failed, delete it*/
> > +            if (rc != 0) {
> > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > +                continue;
> > +            }
> > +        }
> > +
> > +        /*setup watch*/
> > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > +                 type, xen_domid, xendev->ops);
> > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> failed.\n");
> > +            return -1;
> > +        }
> > +    }
> > +
> > +    free(dev);
> > +    return 0;
> > +}
> > +
> >  int xen_be_register(const char *type, struct XenDevOps *ops)  {
> >      return xenstore_scan(type, xen_domid, ops);  }
> >
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > +remote_dom) {
> > +    xendev->local_port =
> xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > +
> remote_dom);
> > +    if (xendev->local_port == -1) {
> > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> > +        return -1;
> > +    }
> > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> xendev->local_port);
> > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > +                        xen_be_evtchn_event, NULL, xendev);
> > +    return 0;
> > +}
> > +
> >  int xen_be_bind_evtchn(struct XenDevice *xendev)  {
> >      if (xendev->local_port != -1) {
> > @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice
> *xendev)
> >      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
> > }
> >
> > +int xen_vtpm_send(unsigned char *buf, size_t count) {
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->send) {
> > +        rc = xendev->ops->send(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> > +
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count) {
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->recv) {
> > +        xendev->ops->recv(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> > +
> >  /*
> >   * msg_level:
> >   *  0 == errors (stderr + logfile).
> > diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> new
> > file mode 100644 index 0000000..0d740c1
> > --- /dev/null
> > +++ b/hw/xen/xen_stubdom_vtpm.c
> > @@ -0,0 +1,333 @@
> > +/*
> > + * Connect to Xen vTPM stubdom domain
> > + *
> > + *  Copyright (c) 2014 Intel Corporation
> > + *  Authors:
> > + *    Quan Xu <quan.xu@intel.com>
> > + *
> > + * 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 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, see
> > +<http://www.gnu.org/licenses/>  */
> > +
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <stdarg.h>
> > +#include <string.h>
> > +#include <unistd.h>
> > +#include <signal.h>
> > +#include <inttypes.h>
> > +#include <time.h>
> > +#include <fcntl.h>
> > +#include <errno.h>
> > +#include <sys/ioctl.h>
> > +#include <sys/types.h>
> > +#include <sys/stat.h>
> > +#include <sys/mman.h>
> > +#include <sys/uio.h>
> > +
> > +#include "hw/hw.h"
> > +#include "block/aio.h"
> > +#include "hw/xen/xen_backend.h"
> > +
> > +enum tpmif_state {
> > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> complete */
> > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> > +};
> > +
> > +static AioContext *vtpm_aio_ctx;
> > +
> > +enum status_bits {
> > +    VTPM_STATUS_RUNNING  = 0x1,
> > +    VTPM_STATUS_IDLE     = 0x2,
> > +    VTPM_STATUS_RESULT   = 0x4,
> > +    VTPM_STATUS_CANCELED = 0x8,
> > +};
> > +
> > +struct tpmif_shared_page {
> > +    uint32_t length;         /* request/response length in bytes */
> > +
> > +    uint8_t  state;           /* enum tpmif_state */
> > +    uint8_t  locality;        /* for the current request */
> > +    uint8_t  pad;             /* should be zero */
> > +
> > +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be
> zero */
> > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> > +nr_extra_pages */ };
> > +
> > +struct QEMUBH {
> > +    AioContext *ctx;
> > +    QEMUBHFunc *cb;
> > +    void *opaque;
> > +    QEMUBH *next;
> > +    bool scheduled;
> > +    bool idle;
> > +    bool deleted;
> > +};
> 
> This is a private structure, you cannot just copy the definition here.
> 
> You do not even need it in fact, since sr_bh->ctx is always vtpm_aio_ctx.
> 
> Paolo
> 


Thanks Paolo, I will enhance it in v2. 

Quan 
> 
> > +struct XenVtpmDev {
> > +    struct XenDevice xendev;  /* must be first */
> > +    struct           tpmif_shared_page *shr;
> > +    xc_gntshr        *xen_xcs;
> > +    int              ring_ref;
> > +    int              bedomid;
> > +    QEMUBH           *sr_bh;
> > +};
> > +
> > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev) {
> > +    switch (vtpmdev->shr->state) {
> > +    case TPMIF_STATE_IDLE:
> > +    case TPMIF_STATE_FINISH:
> > +        return VTPM_STATUS_IDLE;
> > +    case TPMIF_STATE_SUBMIT:
> > +    case TPMIF_STATE_CANCEL:
> > +        return VTPM_STATUS_RUNNING;
> > +    default:
> > +        return 0;
> > +    }
> > +}
> > +
> > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> > +xenbus_state xbus) {
> > +    xs_transaction_t xbt = XBT_NULL;
> > +
> > +    if (xendev->fe_state == xbus) {
> > +        return 0;
> > +    }
> > +
> > +    xendev->fe_state = xbus;
> > +
> > +retry_transaction:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto retry_transaction;
> > +        }
> > +    }
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static int vtpm_aio_wait(QEMUBH *qbh) {
> > +    return aio_poll(qbh->ctx, true);
> > +}
> > +
> > +static void sr_bh_handler(void *opaque) { }
> > +
> > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t
> > +*count) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset;
> > +
> > +    if (shr->state == TPMIF_STATE_IDLE) {
> > +        return -ECANCELED;
> > +    }
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > +    *count = shr->length;
> > +
> > +    return 0;
> > +}
> > +
> > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t
> > +count) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > +    shr->length = count;
> > +    barrier();
> > +    shr->state = TPMIF_STATE_SUBMIT;
> > +    xen_wmb();
> > +    xen_be_send_notify(&vtpmdev->xendev);
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    return count;
> > +}
> > +
> > +static int vtpm_initialise(struct XenDevice *xendev) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    xs_transaction_t xbt = XBT_NULL;
> > +    unsigned int ring_ref;
> > +
> > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> "frontend");
> > +    if (vtpmdev->xendev.fe == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /* Get backend domid */
> > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > +                             &vtpmdev->bedomid)) {
> > +        return -1;
> > +    }
> > +
> > +    /*alloc share page*/
> > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> vtpmdev->bedomid, 1,
> > +                                         &ring_ref,
> PROT_READ|PROT_WRITE);
> > +    vtpmdev->ring_ref = ring_ref;
> > +    if (vtpmdev->shr == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /*Create event channel */
> > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> vtpmdev->bedomid)) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +        return -1;
> > +    }
> > +
> > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > +                     vtpmdev->xendev.local_port);
> > +
> > +again:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > +                           vtpmdev->ring_ref)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > +                           vtpmdev->xendev.local_port)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    /* Publish protocol v2 feature */
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1))
> {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto again;
> > +        }
> > +    }
> > +    /* Tell vtpm backend that we are ready */
> > +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static void vtpm_backend_changed(struct XenDevice *xendev, const char
> > +*node) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    int be_state;
> > +
> > +    if (strcmp(node, "state") == 0) {
> > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > +        switch (be_state) {
> > +        case XenbusStateConnected:
> > +            /*TODO*/
> > +            break;
> > +        case XenbusStateClosing:
> > +        case XenbusStateClosed:
> > +            xenbus_switch_state(&vtpmdev->xendev,
> XenbusStateClosing);
> > +            break;
> > +        default:
> > +            break;
> > +        }
> > +    }
> > +}
> > +
> > +static int vtpm_free(struct XenDevice *xendev) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > +
> > +    aio_poll(qbh->ctx, false);
> > +    qemu_bh_delete(vtpmdev->sr_bh);
> > +    if (vtpmdev->shr) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    }
> > +    xc_interface_close(vtpmdev->xen_xcs);
> > +    return 0;
> > +}
> > +
> > +static void vtpm_alloc(struct XenDevice *xendev) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    vtpm_aio_ctx = aio_context_new(NULL);
> > +    if (vtpm_aio_ctx == NULL) {
> > +        return;
> > +    }
> > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> vtpmdev);
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0); }
> > +
> > +static void vtpm_event(struct XenDevice *xendev) {
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    qemu_bh_schedule(vtpmdev->sr_bh); }
> > +
> > +struct XenDevOps xen_vtpmdev_ops = {
> > +    .size             = sizeof(struct XenVtpmDev),
> > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > +                        DEVOPS_FLAG_STUBDOM_BE,
> > +    .event            = vtpm_event,
> > +    .free             = vtpm_free,
> > +    .alloc            = vtpm_alloc,
> > +    .initialise       = vtpm_initialise,
> > +    .backend_changed  = vtpm_backend_changed,
> > +    .recv             = vtpm_recv,
> > +    .send             = vtpm_send,
> > +};
> > diff --git a/include/hw/xen/xen_backend.h
> > b/include/hw/xen/xen_backend.h index 3b4125e..45fd6d3 100644
> > --- a/include/hw/xen/xen_backend.h
> > +++ b/include/hw/xen/xen_backend.h
> > @@ -15,6 +15,8 @@ struct XenDevice;
> >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> >  /* don't expect frontend doing correct state transitions (aka console
> > quirk) */  #define DEVOPS_FLAG_IGNORE_STATE  2
> > +/*dev backend is stubdom*/
> > +#define DEVOPS_FLAG_STUBDOM_BE    4
> >
> >  struct XenDevOps {
> >      size_t    size;
> > @@ -26,6 +28,8 @@ struct XenDevOps {
> >      void      (*event)(struct XenDevice *xendev);
> >      void      (*disconnect)(struct XenDevice *xendev);
> >      int       (*free)(struct XenDevice *xendev);
> > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> count);
> > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> *count);
> >      void      (*backend_changed)(struct XenDevice *xendev, const
> char *node);
> >      void      (*frontend_changed)(struct XenDevice *xendev, const
> char *node);
> >  };
> > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> *xendev);
> > void xen_be_printf(struct XenDevice *xendev, int msg_level, const char
> *fmt, ...)
> >      GCC_FMT_ATTR(3, 4);
> >
> > +/*Xen stubdom vtpm*/
> > +int xen_vtpm_register(struct XenDevOps *ops); int
> > +xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > +remote_dom); int xen_vtpm_send(unsigned char *buf, size_t count); int
> > +xen_vtpm_recv(unsigned char *buf, size_t *count);
> > +
> >  /* actual backend drivers */
> >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> */
> >  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c
> */
> >  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
> >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> */
> >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> */
> > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> xen_stubdom_vtpm.c*/
> >
> >  void xen_init_display(int domid);
> >
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 95612a4..fb43084 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void
> *logger, void *dombuild_logger,
> >      return xc_interface_open(logger, dombuild_logger, open_flags);  }
> >
> > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > +                                           unsigned int open_flags)
> {
> > +    return xc_gntshr_open(logger, open_flags); }
> > +
> >  /* FIXME There is now way to have the xen fd */  static inline int
> > xc_fd(xc_interface *xen_xc)  { diff --git a/xen-hvm.c b/xen-hvm.c
> > index 21f1cbb..c99ace8 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >      int i, rc;
> >      unsigned long ioreq_pfn;
> >      unsigned long bufioreq_evtchn;
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    unsigned long stubdom_vtpm = 0;
> > +#endif
> > +
> >      XenIOState *state;
> >
> >      state = g_malloc0(sizeof (XenIOState)); @@ -1169,6 +1174,14 @@
> > int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t
> *above_4g_mem_size,
> >          fprintf(stderr, "%s: xen backend core setup failed\n",
> __FUNCTION__);
> >          return -1;
> >      }
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    xc_get_hvm_param(xen_xc, xen_domid,
> HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > +    if (stubdom_vtpm) {
> > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > +    }
> > +#endif
> > +
> >      xen_be_register("console", &xen_console_ops);
> >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> >      xen_be_register("qdisk", &xen_blkdev_ops);
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:43:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1XlhCl-0001Nj-04; Tue, 04 Nov 2014 16:43:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XlhCj-0001Nd-NW
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:43:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	40/73-24532-93209545; Tue, 04 Nov 2014 16:43:37 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415119415!12726434!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30039 invoked from network); 4 Nov 2014 16:43:36 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-15.tower-21.messagelabs.com with SMTP;
	4 Nov 2014 16:43:36 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 04 Nov 2014 08:41:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,313,1413270000"; d="scan'208";a="602084959"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 04 Nov 2014 08:43:22 -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.3.195.1; Wed, 5 Nov 2014 00:43:22 +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.3.195.1; Wed, 5 Nov 2014 00:43:22 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.3]) with mapi id
	14.03.0195.001; Wed, 5 Nov 2014 00:43:20 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Eric Blake <eblake@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [Qemu-devel] [PATCH 1/4] Qemu-Xen-vTPM: Support for Xen
	stubdom vTPM command line options
Thread-Index: AQHP+EfWKgH6z+M/rkyFELymQZtlY5xQqkXg
Date: Tue, 4 Nov 2014 16:43:21 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E81F8F4@SHSMSX101.ccr.corp.intel.com>
References: <1414910361-27681-1-git-send-email-quan.xu@intel.com>
	<5458F6E7.5000606@redhat.com>
In-Reply-To: <5458F6E7.5000606@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"lcapitulino@redhat.com" <lcapitulino@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Eric Blake [mailto:eblake@redhat.com]
> Sent: Tuesday, November 04, 2014 11:55 PM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: lcapitulino@redhat.com; armbru@redhat.com; xen-devel@lists.xen.org
> Subject: Re: [Qemu-devel] [PATCH 1/4] Qemu-Xen-vTPM: Support for Xen
> stubdom vTPM command line options
> 
> On 11/02/2014 07:39 AM, Quan Xu wrote:
> 
> [meta-comment] This message appears to have a cover letter; but you failed
> to properly set the 'In-Reply-To' header; when each patch of your series
> appears as a top-level thread instead of a reply to the cover letter, it is harder
> to review.
> 
:(
Thanks Eric. 
Markus (Markus Armbruster <armbru@redhat.com>) shared how he formats and sends a patch series.
I will submit v2 in the right format. 

> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > ---
> >  configure        | 14 ++++++++++++++
> >  hmp.c            |  7 +++++++
> >  qapi-schema.json | 17 +++++++++++++++--  qemu-options.hx  | 13
> > +++++++++++--
> >  tpm.c            |  7 ++++++-
> >  5 files changed, 53 insertions(+), 5 deletions(-)
> >
> 
> > +++ b/qapi-schema.json
> > @@ -2853,10 +2853,11 @@
> >  # An enumeration of TPM types
> >  #
> >  # @passthrough: TPM passthrough type
> > +# @xenstubdoms: TPM xenstubdoms type
> 
> Missing a '(since 2.3)' designation.

I will add it in v2.

> 
> >  #
> >  # Since: 1.5
> >  ##
> > -{ 'enum': 'TpmType', 'data': [ 'passthrough' ] }
> > +{ 'enum': 'TpmType', 'data': [ 'passthrough', 'xenstubdoms' ] }
> >
> >  ##
> >  # @query-tpm-types:
> > @@ -2884,6 +2885,16 @@
> >  { 'type': 'TPMPassthroughOptions', 'data': { '*path' : 'str',
> >                                               '*cancel-path' : 'str'}
> > }
> >
> > +# @TPMXenstubdomsOptions:
> > +#
> > +# Information about the TPM xenstubdoms type # # Since: > 2.1.0
> 
> 2.1 is wrong; the earliest you can get this into the tree is 2.3 (because you've
> missed soft freeze for 2.2).

I will fix it in v2. 

> 
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:43:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1XlhCl-0001Nj-04; Tue, 04 Nov 2014 16:43:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XlhCj-0001Nd-NW
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:43:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	40/73-24532-93209545; Tue, 04 Nov 2014 16:43:37 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415119415!12726434!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30039 invoked from network); 4 Nov 2014 16:43:36 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-15.tower-21.messagelabs.com with SMTP;
	4 Nov 2014 16:43:36 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 04 Nov 2014 08:41:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,313,1413270000"; d="scan'208";a="602084959"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 04 Nov 2014 08:43:22 -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.3.195.1; Wed, 5 Nov 2014 00:43:22 +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.3.195.1; Wed, 5 Nov 2014 00:43:22 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.3]) with mapi id
	14.03.0195.001; Wed, 5 Nov 2014 00:43:20 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Eric Blake <eblake@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [Qemu-devel] [PATCH 1/4] Qemu-Xen-vTPM: Support for Xen
	stubdom vTPM command line options
Thread-Index: AQHP+EfWKgH6z+M/rkyFELymQZtlY5xQqkXg
Date: Tue, 4 Nov 2014 16:43:21 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E81F8F4@SHSMSX101.ccr.corp.intel.com>
References: <1414910361-27681-1-git-send-email-quan.xu@intel.com>
	<5458F6E7.5000606@redhat.com>
In-Reply-To: <5458F6E7.5000606@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"lcapitulino@redhat.com" <lcapitulino@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Eric Blake [mailto:eblake@redhat.com]
> Sent: Tuesday, November 04, 2014 11:55 PM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: lcapitulino@redhat.com; armbru@redhat.com; xen-devel@lists.xen.org
> Subject: Re: [Qemu-devel] [PATCH 1/4] Qemu-Xen-vTPM: Support for Xen
> stubdom vTPM command line options
> 
> On 11/02/2014 07:39 AM, Quan Xu wrote:
> 
> [meta-comment] This message appears to have a cover letter; but you failed
> to properly set the 'In-Reply-To' header; when each patch of your series
> appears as a top-level thread instead of a reply to the cover letter, it is harder
> to review.
> 
:(
Thanks Eric. 
Markus (Markus Armbruster <armbru@redhat.com>) shared how he formats and sends a patch series.
I will submit v2 in the right format. 

> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > ---
> >  configure        | 14 ++++++++++++++
> >  hmp.c            |  7 +++++++
> >  qapi-schema.json | 17 +++++++++++++++--  qemu-options.hx  | 13
> > +++++++++++--
> >  tpm.c            |  7 ++++++-
> >  5 files changed, 53 insertions(+), 5 deletions(-)
> >
> 
> > +++ b/qapi-schema.json
> > @@ -2853,10 +2853,11 @@
> >  # An enumeration of TPM types
> >  #
> >  # @passthrough: TPM passthrough type
> > +# @xenstubdoms: TPM xenstubdoms type
> 
> Missing a '(since 2.3)' designation.

I will add it in v2.

> 
> >  #
> >  # Since: 1.5
> >  ##
> > -{ 'enum': 'TpmType', 'data': [ 'passthrough' ] }
> > +{ 'enum': 'TpmType', 'data': [ 'passthrough', 'xenstubdoms' ] }
> >
> >  ##
> >  # @query-tpm-types:
> > @@ -2884,6 +2885,16 @@
> >  { 'type': 'TPMPassthroughOptions', 'data': { '*path' : 'str',
> >                                               '*cancel-path' : 'str'}
> > }
> >
> > +# @TPMXenstubdomsOptions:
> > +#
> > +# Information about the TPM xenstubdoms type # # Since: > 2.1.0
> 
> 2.1 is wrong; the earliest you can get this into the tree is 2.3 (because you've
> missed soft freeze for 2.2).

I will fix it in v2. 

> 
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:48:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1XlhHU-0001YS-S4; Tue, 04 Nov 2014 16:48:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XlhHU-0001YN-6Q
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:48:32 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	C8/65-03145-F5309545; Tue, 04 Nov 2014 16:48:31 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415119709!7887537!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2338 invoked from network); 4 Nov 2014 16:48:30 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 16:48:30 -0000
Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlhHQ-0005IO-Qc; Tue, 04 Nov 2014 17:48:28 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.64])
	by justin.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlhHQ-0005AY-HJ; Tue, 04 Nov 2014 17:48:28 +0100
Message-ID: <5459035D.5010204@web2web.at>
Date: Tue, 04 Nov 2014 17:48:29 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>				<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>			<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>		
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>	
	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com>
In-Reply-To: <1415118690.11486.53.camel@citrix.com>
X-Univie-Virus-Scan: scanned by ClamAV on justin.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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

Am 04.11.14 um 17:31 schrieb Ian Campbell:
> On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
>> Am 04.11.14 um 16:44 schrieb Ian Campbell:
>>> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
>>> Otherwise I think the next step would be to downgrade to 4.3.1 and see
>>> if the problem persists, in order to rule out changes elsewhere in the
>>> system. If the problem doesn't happen with a 4.3.1 rebuilt on your
>>> current system then the next thing would probably be to bisect the
>>> issue. There are only 31 toolstack changes in that range, so it ought to
>>> only take 5-6 iterations.
>> Unfortunately 4.3.1 is no longer available as an ebuild as 4.3.3 seemed
>> to fix security issues and therefore 4.3.1 has been deleted from the
>> repos. So it's not straightforward and I need to figure out how to get
>> the old version back. But I am sure there's a way.
>
> I don't know anything about ebuilds, but if you end up needing to bisect
> then building from xen.git might be useful anyway (unless you can get an
> ebuild to trivially build some other version).
Before I go down that route would I also need to re-compile xen (i.e. 
the hypervisor at /boot/xen-4.3.3.gz that's being booted from grub) or 
only xen-tools? In other words does xen-tools 4.3.1 work with the 
hypervisor version 4.3.3 under /boot? I wouldn't want to end up with an 
unbootable system.

In terms of ebuilds: Adding patches to a version is pretty easy as 
gentoo works from source code. So if 4.3.3 is just different by a number 
of well defined patches from 4.3.1 then that should be straightforward 
as applying patches is really trivial.

Thanks Atom2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 16:48:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 16: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 1XlhHU-0001YS-S4; Tue, 04 Nov 2014 16:48:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XlhHU-0001YN-6Q
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 16:48:32 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	C8/65-03145-F5309545; Tue, 04 Nov 2014 16:48:31 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415119709!7887537!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2338 invoked from network); 4 Nov 2014 16:48:30 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 16:48:30 -0000
Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlhHQ-0005IO-Qc; Tue, 04 Nov 2014 17:48:28 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.64])
	by justin.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlhHQ-0005AY-HJ; Tue, 04 Nov 2014 17:48:28 +0100
Message-ID: <5459035D.5010204@web2web.at>
Date: Tue, 04 Nov 2014 17:48:29 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>				<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>			<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>		
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>	
	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com>
In-Reply-To: <1415118690.11486.53.camel@citrix.com>
X-Univie-Virus-Scan: scanned by ClamAV on justin.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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

Am 04.11.14 um 17:31 schrieb Ian Campbell:
> On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
>> Am 04.11.14 um 16:44 schrieb Ian Campbell:
>>> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
>>> Otherwise I think the next step would be to downgrade to 4.3.1 and see
>>> if the problem persists, in order to rule out changes elsewhere in the
>>> system. If the problem doesn't happen with a 4.3.1 rebuilt on your
>>> current system then the next thing would probably be to bisect the
>>> issue. There are only 31 toolstack changes in that range, so it ought to
>>> only take 5-6 iterations.
>> Unfortunately 4.3.1 is no longer available as an ebuild as 4.3.3 seemed
>> to fix security issues and therefore 4.3.1 has been deleted from the
>> repos. So it's not straightforward and I need to figure out how to get
>> the old version back. But I am sure there's a way.
>
> I don't know anything about ebuilds, but if you end up needing to bisect
> then building from xen.git might be useful anyway (unless you can get an
> ebuild to trivially build some other version).
Before I go down that route would I also need to re-compile xen (i.e. 
the hypervisor at /boot/xen-4.3.3.gz that's being booted from grub) or 
only xen-tools? In other words does xen-tools 4.3.1 work with the 
hypervisor version 4.3.3 under /boot? I wouldn't want to end up with an 
unbootable system.

In terms of ebuilds: Adding patches to a version is pretty easy as 
gentoo works from source code. So if 4.3.3 is just different by a number 
of well defined patches from 4.3.1 then that should be straightforward 
as applying patches is really trivial.

Thanks Atom2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:10:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlhcn-0002U0-0t; Tue, 04 Nov 2014 17:10:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xlhcl-0002Tv-Qj
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 17:10:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5E/59-09842-78809545; Tue, 04 Nov 2014 17:10:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415121029!12723946!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31683 invoked from network); 4 Nov 2014 17:10:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 17:10:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4HAP9Q026225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 17:10:26 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HAObI000645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 17:10:24 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HANpV000640; Tue, 4 Nov 2014 17:10:23 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 09:10:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B7B5B1106BE; Tue,  4 Nov 2014 12:10:22 -0500 (EST)
Date: Tue, 4 Nov 2014 12:10:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141104171022.GI4510@laptop.dumpdata.com>
References: <5450DC800200000200017669@gwsmtp1.uni-regensburg.de>
	<1415095735.11486.7.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415095735.11486.7.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xentop: Dynamically expand some columns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 10:08:55AM +0000, Ian Campbell wrote:
> On Wed, 2014-10-29 at 12:24 +0100, Markus Hauschild wrote:
> > Allow certain xentop columns to automatically expand as the amount
> > of data reported gets larger.  The columns allowed to auto expand are:
> > 
> > NETTX(k), NETRX(k), VBD_RD, VBD_WR, VBD_RSECT, VBD_WSECT
> > 
> > If the -f option is used to allow full length VM names, those names will
> > also be aligned based on the longest name in the NAME column.
> > 
> > The default minimum width of all columns remains unchanged.
> > 
> > Signed-off-by: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>
> > Signed-off-by: Charles Arnold <carnold@suse.com>
> 
> Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
> 
> Konrad, I think you were previously intending this to go in for 4.5, is
> that still the case?

Correct.
> 
> > 
> > diff --git a/tools/xenstat/xentop/Makefile b/tools/xenstat/xentop/Makefile
> > index 18bccb6..076e44c 100644
> > --- a/tools/xenstat/xentop/Makefile
> > +++ b/tools/xenstat/xentop/Makefile
> > @@ -19,7 +19,7 @@ all install xentop:
> >  else
> >  
> >  CFLAGS += -DGCC_PRINTF -Werror $(CFLAGS_libxenstat)
> > -LDLIBS += $(LDLIBS_libxenstat) $(CURSES_LIBS) $(SOCKET_LIBS)
> > +LDLIBS += $(LDLIBS_libxenstat) $(CURSES_LIBS) $(SOCKET_LIBS) -lm
> >  CFLAGS += -DHOST_$(XEN_OS)
> >  
> >  # Include configure output (config.h) to headers search path
> > diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c
> > index dd11927..3062cb5 100644
> > --- a/tools/xenstat/xentop/xentop.c
> > +++ b/tools/xenstat/xentop/xentop.c
> > @@ -27,6 +27,7 @@
> >  
> >  #include <ctype.h>
> >  #include <errno.h>
> > +#include <math.h>
> >  #include <stdio.h>
> >  #include <stdlib.h>
> >  #include <stdarg.h>
> > @@ -70,6 +71,8 @@
> >  #define curses_str_t const char *
> >  #endif
> >  
> > +#define INT_FIELD_WIDTH(n) ((unsigned int)(log10(n) + 1))
> > +
> >  /*
> >   * Function prototypes
> >   */
> > @@ -127,7 +130,8 @@ static int compare_vbd_rsect(xenstat_domain *domain1, xenstat_domain *domain2);
> >  static void print_vbd_rsect(xenstat_domain *domain);
> >  static int compare_vbd_wsect(xenstat_domain *domain1, xenstat_domain *domain2);
> >  static void print_vbd_wsect(xenstat_domain *domain);
> > -
> > +static void reset_field_widths(void);
> > +static void adjust_field_widths(xenstat_domain *domain);
> >  
> >  /* Section printing functions */
> >  static void do_summary(void);
> > @@ -444,7 +448,7 @@ int compare_name(xenstat_domain *domain1, xenstat_domain *domain2)
> >  void print_name(xenstat_domain *domain)
> >  {
> >  	if(show_full_name)
> > -		print("%10s", xenstat_domain_name(domain));
> > +		print("%*s", fields[FIELD_NAME-1].default_width, xenstat_domain_name(domain));
> >  	else
> >  		print("%10.10s", xenstat_domain_name(domain));
> >  }
> > @@ -623,7 +627,7 @@ static int compare_net_tx(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total network tx bytes statistic */
> >  static void print_net_tx(xenstat_domain *domain)
> >  {
> > -	print("%8llu", tot_net_bytes(domain, FALSE)/1024);
> > +	print("%*llu", fields[FIELD_NET_TX-1].default_width, tot_net_bytes(domain, FALSE)/1024);
> >  }
> >  
> >  /* Compares number of total network rx bytes of two domains, returning -1,0,1
> > @@ -637,7 +641,7 @@ static int compare_net_rx(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total network rx bytes statistic */
> >  static void print_net_rx(xenstat_domain *domain)
> >  {
> > -	print("%8llu", tot_net_bytes(domain, TRUE)/1024);
> > +	print("%*llu", fields[FIELD_NET_RX-1].default_width, tot_net_bytes(domain, TRUE)/1024);
> >  }
> >  
> >  /* Gets number of total network bytes statistic, if rx true, then rx bytes
> > @@ -705,7 +709,7 @@ static int compare_vbd_rd(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total VBD READ requests statistic */
> >  static void print_vbd_rd(xenstat_domain *domain)
> >  {
> > -	print("%8llu", tot_vbd_reqs(domain, FIELD_VBD_RD));
> > +	print("%*llu", fields[FIELD_VBD_RD-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_RD));
> >  }
> >  
> >  /* Compares number of total VBD WRITE requests of two domains,
> > @@ -719,7 +723,7 @@ static int compare_vbd_wr(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total VBD WRITE requests statistic */
> >  static void print_vbd_wr(xenstat_domain *domain)
> >  {
> > -	print("%8llu", tot_vbd_reqs(domain, FIELD_VBD_WR));
> > +	print("%*llu", fields[FIELD_VBD_WR-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_WR));
> >  }
> >  
> >  /* Compares number of total VBD READ sectors of two domains,
> > @@ -733,7 +737,7 @@ static int compare_vbd_rsect(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total VBD READ sectors statistic */
> >  static void print_vbd_rsect(xenstat_domain *domain)
> >  {
> > -	print("%10llu", tot_vbd_reqs(domain, FIELD_VBD_RSECT));
> > +	print("%*llu", fields[FIELD_VBD_RSECT-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_RSECT));
> >  }
> >  
> >  /* Compares number of total VBD WRITE sectors of two domains,
> > @@ -747,7 +751,7 @@ static int compare_vbd_wsect(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total VBD WRITE sectors statistic */
> >  static void print_vbd_wsect(xenstat_domain *domain)
> >  {
> > -	print("%10llu", tot_vbd_reqs(domain, FIELD_VBD_WSECT));
> > +	print("%*llu", fields[FIELD_VBD_WSECT-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_WSECT));
> >  }
> >  
> > 
> > @@ -806,6 +810,54 @@ static void print_ssid(xenstat_domain *domain)
> >  	print("%4u", xenstat_domain_ssid(domain));
> >  }
> >  
> > +/* Resets default_width for fields with potentially large numbers */
> > +void reset_field_widths(void)
> > +{
> > +	fields[FIELD_NET_TX-1].default_width = 8;
> > +	fields[FIELD_NET_RX-1].default_width = 8;
> > +	fields[FIELD_VBD_RD-1].default_width = 8;
> > +	fields[FIELD_VBD_WR-1].default_width = 8;
> > +	fields[FIELD_VBD_RSECT-1].default_width = 10;
> > +	fields[FIELD_VBD_WSECT-1].default_width = 10;
> > +}
> > +
> > +/* Adjusts default_width for fields with potentially large numbers */
> > +void adjust_field_widths(xenstat_domain *domain)
> > +{
> > +	unsigned int length;
> > +
> > +	if (show_full_name) {
> > +		length = strlen(xenstat_domain_name(domain));
> > +		if (length > fields[FIELD_NAME-1].default_width)
> > +			fields[FIELD_NAME-1].default_width = length;
> > +	}
> > +
> > +	length = INT_FIELD_WIDTH((tot_net_bytes(domain, FALSE)/1024) + 1);
> > +	if (length > fields[FIELD_NET_TX-1].default_width)
> > +		fields[FIELD_NET_TX-1].default_width = length;
> > +
> > +	length = INT_FIELD_WIDTH((tot_net_bytes(domain, TRUE)/1024) + 1);
> > +	if (length > fields[FIELD_NET_RX-1].default_width)
> > +		fields[FIELD_NET_RX-1].default_width = length;
> > +
> > +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_RD)) + 1);
> > +	if (length > fields[FIELD_VBD_RD-1].default_width)
> > +		fields[FIELD_VBD_RD-1].default_width = length;
> > +
> > +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_WR)) + 1);
> > +	if (length > fields[FIELD_VBD_WR-1].default_width)
> > +		fields[FIELD_VBD_WR-1].default_width = length;
> > +
> > +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_RSECT)) + 1);
> > +	if (length > fields[FIELD_VBD_RSECT-1].default_width)
> > +		fields[FIELD_VBD_RSECT-1].default_width = length;
> > +
> > +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_WSECT)) + 1);
> > +	if (length > fields[FIELD_VBD_WSECT-1].default_width)
> > +		fields[FIELD_VBD_WSECT-1].default_width = length;
> > +}
> > +
> > +
> >  /* Section printing functions */
> >  /* Prints the top summary, above the domain table */
> >  void do_summary(void)
> > @@ -1088,6 +1140,12 @@ static void top(void)
> >  	if(first_domain_index >= num_domains)
> >  		first_domain_index = num_domains-1;
> >  
> > +	/* Adjust default_width for fields with potentially large numbers */
> > +	reset_field_widths();
> > +	for (i = first_domain_index; i < num_domains; i++) {
> > +		adjust_field_widths(domains[i]);
> > +	}
> > +
> >  	for (i = first_domain_index; i < num_domains; i++) {
> >  		if(!batch && current_row() == lines()-1)
> >  			break;
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:10:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlhcn-0002U0-0t; Tue, 04 Nov 2014 17:10:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xlhcl-0002Tv-Qj
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 17:10:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5E/59-09842-78809545; Tue, 04 Nov 2014 17:10:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415121029!12723946!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31683 invoked from network); 4 Nov 2014 17:10:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 17:10:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4HAP9Q026225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 17:10:26 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HAObI000645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 17:10:24 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HANpV000640; Tue, 4 Nov 2014 17:10:23 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 09:10:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B7B5B1106BE; Tue,  4 Nov 2014 12:10:22 -0500 (EST)
Date: Tue, 4 Nov 2014 12:10:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141104171022.GI4510@laptop.dumpdata.com>
References: <5450DC800200000200017669@gwsmtp1.uni-regensburg.de>
	<1415095735.11486.7.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415095735.11486.7.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xentop: Dynamically expand some columns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 10:08:55AM +0000, Ian Campbell wrote:
> On Wed, 2014-10-29 at 12:24 +0100, Markus Hauschild wrote:
> > Allow certain xentop columns to automatically expand as the amount
> > of data reported gets larger.  The columns allowed to auto expand are:
> > 
> > NETTX(k), NETRX(k), VBD_RD, VBD_WR, VBD_RSECT, VBD_WSECT
> > 
> > If the -f option is used to allow full length VM names, those names will
> > also be aligned based on the longest name in the NAME column.
> > 
> > The default minimum width of all columns remains unchanged.
> > 
> > Signed-off-by: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>
> > Signed-off-by: Charles Arnold <carnold@suse.com>
> 
> Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
> 
> Konrad, I think you were previously intending this to go in for 4.5, is
> that still the case?

Correct.
> 
> > 
> > diff --git a/tools/xenstat/xentop/Makefile b/tools/xenstat/xentop/Makefile
> > index 18bccb6..076e44c 100644
> > --- a/tools/xenstat/xentop/Makefile
> > +++ b/tools/xenstat/xentop/Makefile
> > @@ -19,7 +19,7 @@ all install xentop:
> >  else
> >  
> >  CFLAGS += -DGCC_PRINTF -Werror $(CFLAGS_libxenstat)
> > -LDLIBS += $(LDLIBS_libxenstat) $(CURSES_LIBS) $(SOCKET_LIBS)
> > +LDLIBS += $(LDLIBS_libxenstat) $(CURSES_LIBS) $(SOCKET_LIBS) -lm
> >  CFLAGS += -DHOST_$(XEN_OS)
> >  
> >  # Include configure output (config.h) to headers search path
> > diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c
> > index dd11927..3062cb5 100644
> > --- a/tools/xenstat/xentop/xentop.c
> > +++ b/tools/xenstat/xentop/xentop.c
> > @@ -27,6 +27,7 @@
> >  
> >  #include <ctype.h>
> >  #include <errno.h>
> > +#include <math.h>
> >  #include <stdio.h>
> >  #include <stdlib.h>
> >  #include <stdarg.h>
> > @@ -70,6 +71,8 @@
> >  #define curses_str_t const char *
> >  #endif
> >  
> > +#define INT_FIELD_WIDTH(n) ((unsigned int)(log10(n) + 1))
> > +
> >  /*
> >   * Function prototypes
> >   */
> > @@ -127,7 +130,8 @@ static int compare_vbd_rsect(xenstat_domain *domain1, xenstat_domain *domain2);
> >  static void print_vbd_rsect(xenstat_domain *domain);
> >  static int compare_vbd_wsect(xenstat_domain *domain1, xenstat_domain *domain2);
> >  static void print_vbd_wsect(xenstat_domain *domain);
> > -
> > +static void reset_field_widths(void);
> > +static void adjust_field_widths(xenstat_domain *domain);
> >  
> >  /* Section printing functions */
> >  static void do_summary(void);
> > @@ -444,7 +448,7 @@ int compare_name(xenstat_domain *domain1, xenstat_domain *domain2)
> >  void print_name(xenstat_domain *domain)
> >  {
> >  	if(show_full_name)
> > -		print("%10s", xenstat_domain_name(domain));
> > +		print("%*s", fields[FIELD_NAME-1].default_width, xenstat_domain_name(domain));
> >  	else
> >  		print("%10.10s", xenstat_domain_name(domain));
> >  }
> > @@ -623,7 +627,7 @@ static int compare_net_tx(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total network tx bytes statistic */
> >  static void print_net_tx(xenstat_domain *domain)
> >  {
> > -	print("%8llu", tot_net_bytes(domain, FALSE)/1024);
> > +	print("%*llu", fields[FIELD_NET_TX-1].default_width, tot_net_bytes(domain, FALSE)/1024);
> >  }
> >  
> >  /* Compares number of total network rx bytes of two domains, returning -1,0,1
> > @@ -637,7 +641,7 @@ static int compare_net_rx(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total network rx bytes statistic */
> >  static void print_net_rx(xenstat_domain *domain)
> >  {
> > -	print("%8llu", tot_net_bytes(domain, TRUE)/1024);
> > +	print("%*llu", fields[FIELD_NET_RX-1].default_width, tot_net_bytes(domain, TRUE)/1024);
> >  }
> >  
> >  /* Gets number of total network bytes statistic, if rx true, then rx bytes
> > @@ -705,7 +709,7 @@ static int compare_vbd_rd(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total VBD READ requests statistic */
> >  static void print_vbd_rd(xenstat_domain *domain)
> >  {
> > -	print("%8llu", tot_vbd_reqs(domain, FIELD_VBD_RD));
> > +	print("%*llu", fields[FIELD_VBD_RD-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_RD));
> >  }
> >  
> >  /* Compares number of total VBD WRITE requests of two domains,
> > @@ -719,7 +723,7 @@ static int compare_vbd_wr(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total VBD WRITE requests statistic */
> >  static void print_vbd_wr(xenstat_domain *domain)
> >  {
> > -	print("%8llu", tot_vbd_reqs(domain, FIELD_VBD_WR));
> > +	print("%*llu", fields[FIELD_VBD_WR-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_WR));
> >  }
> >  
> >  /* Compares number of total VBD READ sectors of two domains,
> > @@ -733,7 +737,7 @@ static int compare_vbd_rsect(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total VBD READ sectors statistic */
> >  static void print_vbd_rsect(xenstat_domain *domain)
> >  {
> > -	print("%10llu", tot_vbd_reqs(domain, FIELD_VBD_RSECT));
> > +	print("%*llu", fields[FIELD_VBD_RSECT-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_RSECT));
> >  }
> >  
> >  /* Compares number of total VBD WRITE sectors of two domains,
> > @@ -747,7 +751,7 @@ static int compare_vbd_wsect(xenstat_domain *domain1, xenstat_domain *domain2)
> >  /* Prints number of total VBD WRITE sectors statistic */
> >  static void print_vbd_wsect(xenstat_domain *domain)
> >  {
> > -	print("%10llu", tot_vbd_reqs(domain, FIELD_VBD_WSECT));
> > +	print("%*llu", fields[FIELD_VBD_WSECT-1].default_width, tot_vbd_reqs(domain, FIELD_VBD_WSECT));
> >  }
> >  
> > 
> > @@ -806,6 +810,54 @@ static void print_ssid(xenstat_domain *domain)
> >  	print("%4u", xenstat_domain_ssid(domain));
> >  }
> >  
> > +/* Resets default_width for fields with potentially large numbers */
> > +void reset_field_widths(void)
> > +{
> > +	fields[FIELD_NET_TX-1].default_width = 8;
> > +	fields[FIELD_NET_RX-1].default_width = 8;
> > +	fields[FIELD_VBD_RD-1].default_width = 8;
> > +	fields[FIELD_VBD_WR-1].default_width = 8;
> > +	fields[FIELD_VBD_RSECT-1].default_width = 10;
> > +	fields[FIELD_VBD_WSECT-1].default_width = 10;
> > +}
> > +
> > +/* Adjusts default_width for fields with potentially large numbers */
> > +void adjust_field_widths(xenstat_domain *domain)
> > +{
> > +	unsigned int length;
> > +
> > +	if (show_full_name) {
> > +		length = strlen(xenstat_domain_name(domain));
> > +		if (length > fields[FIELD_NAME-1].default_width)
> > +			fields[FIELD_NAME-1].default_width = length;
> > +	}
> > +
> > +	length = INT_FIELD_WIDTH((tot_net_bytes(domain, FALSE)/1024) + 1);
> > +	if (length > fields[FIELD_NET_TX-1].default_width)
> > +		fields[FIELD_NET_TX-1].default_width = length;
> > +
> > +	length = INT_FIELD_WIDTH((tot_net_bytes(domain, TRUE)/1024) + 1);
> > +	if (length > fields[FIELD_NET_RX-1].default_width)
> > +		fields[FIELD_NET_RX-1].default_width = length;
> > +
> > +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_RD)) + 1);
> > +	if (length > fields[FIELD_VBD_RD-1].default_width)
> > +		fields[FIELD_VBD_RD-1].default_width = length;
> > +
> > +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_WR)) + 1);
> > +	if (length > fields[FIELD_VBD_WR-1].default_width)
> > +		fields[FIELD_VBD_WR-1].default_width = length;
> > +
> > +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_RSECT)) + 1);
> > +	if (length > fields[FIELD_VBD_RSECT-1].default_width)
> > +		fields[FIELD_VBD_RSECT-1].default_width = length;
> > +
> > +	length = INT_FIELD_WIDTH((tot_vbd_reqs(domain, FIELD_VBD_WSECT)) + 1);
> > +	if (length > fields[FIELD_VBD_WSECT-1].default_width)
> > +		fields[FIELD_VBD_WSECT-1].default_width = length;
> > +}
> > +
> > +
> >  /* Section printing functions */
> >  /* Prints the top summary, above the domain table */
> >  void do_summary(void)
> > @@ -1088,6 +1140,12 @@ static void top(void)
> >  	if(first_domain_index >= num_domains)
> >  		first_domain_index = num_domains-1;
> >  
> > +	/* Adjust default_width for fields with potentially large numbers */
> > +	reset_field_widths();
> > +	for (i = first_domain_index; i < num_domains; i++) {
> > +		adjust_field_widths(domains[i]);
> > +	}
> > +
> >  	for (i = first_domain_index; i < num_domains; i++) {
> >  		if(!batch && current_row() == lines()-1)
> >  			break;
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:12:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlheO-0002ZC-GK; Tue, 04 Nov 2014 17:12:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlheN-0002Z7-2p
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 17:12:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2E/FE-24532-AE809545; Tue, 04 Nov 2014 17:12:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415121128!12724261!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6598 invoked from network); 4 Nov 2014 17:12:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 17:12:09 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4HBkvv028233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 17:11:47 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HBjLf002111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 17:11:46 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HBjmQ002103; Tue, 4 Nov 2014 17:11:45 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 09:11:45 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 646D61106C6; Tue,  4 Nov 2014 12:11:44 -0500 (EST)
Date: Tue, 4 Nov 2014 12:11:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141104171144.GJ4510@laptop.dumpdata.com>
References: <1414144694.15687.31.camel@citrix.com>
	<1414144717-32328-1-git-send-email-ian.campbell@citrix.com>
	<54513A08.3000908@linaro.org>
	<1415096635.11486.15.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415096635.11486.15.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: stefano.stabellini@eu.citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, xen-devel@lists.xen.org,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 1/5] xen: arm: propagate gic's
 #address-cells property 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 Tue, Nov 04, 2014 at 10:23:55AM +0000, Ian Campbell wrote:
> On Wed, 2014-10-29 at 19:03 +0000, Julien Grall wrote:
> > Hi Ian,
> > 
> > On 24/10/2014 10:58, Ian Campbell wrote:
> > > The interrupt-map property requires that the interrupt-parent node
> > > must have both #address-cells and #interrupt-cells properties (see
> > > ePAPR 2.4.3.1). Therefore propagate the property if it is present.
> > >
> > > We must propagate (rather than invent our own value) since this value
> > > is used to size fields within other properties within the tree.
> > >
> > > ePAPR strictly speaking requires that the interrupt-parent node
> > > always has these properties. However reality has diverged from this
> > > and implementations will recursively search parents for #*-cells
> > > properties. Hence we only copy if it is present.
> > >
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Reviewed-by: Julien Grall <julien.grall@linaro.org>
> > 
> > Without this patch I can't boot Xen on the Foundation model with GIC-v3. 
> > Is it possible to push this patch for Xen 4.5 rc1?
> 
> Konrad, I think this is needed for 4.5 since without it dom0 can fail to
> parse certain other constructs within the DT (in bits which we don't
> generate and can't easily/don't want to rewrite as we pass them
> through).

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


> 
> The risk is that some bit of DT which we do generate relies on this
> value being absent (as it was before this patch). I don't believe we
> generate any such nodes. The consumers are typically nodes representing
> devices which we pass through rather than messing with them.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:12:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlheO-0002ZC-GK; Tue, 04 Nov 2014 17:12:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlheN-0002Z7-2p
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 17:12:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2E/FE-24532-AE809545; Tue, 04 Nov 2014 17:12:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415121128!12724261!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6598 invoked from network); 4 Nov 2014 17:12:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 17:12:09 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4HBkvv028233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 17:11:47 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HBjLf002111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 17:11:46 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HBjmQ002103; Tue, 4 Nov 2014 17:11:45 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 09:11:45 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 646D61106C6; Tue,  4 Nov 2014 12:11:44 -0500 (EST)
Date: Tue, 4 Nov 2014 12:11:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141104171144.GJ4510@laptop.dumpdata.com>
References: <1414144694.15687.31.camel@citrix.com>
	<1414144717-32328-1-git-send-email-ian.campbell@citrix.com>
	<54513A08.3000908@linaro.org>
	<1415096635.11486.15.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415096635.11486.15.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: stefano.stabellini@eu.citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, xen-devel@lists.xen.org,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 1/5] xen: arm: propagate gic's
 #address-cells property 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 Tue, Nov 04, 2014 at 10:23:55AM +0000, Ian Campbell wrote:
> On Wed, 2014-10-29 at 19:03 +0000, Julien Grall wrote:
> > Hi Ian,
> > 
> > On 24/10/2014 10:58, Ian Campbell wrote:
> > > The interrupt-map property requires that the interrupt-parent node
> > > must have both #address-cells and #interrupt-cells properties (see
> > > ePAPR 2.4.3.1). Therefore propagate the property if it is present.
> > >
> > > We must propagate (rather than invent our own value) since this value
> > > is used to size fields within other properties within the tree.
> > >
> > > ePAPR strictly speaking requires that the interrupt-parent node
> > > always has these properties. However reality has diverged from this
> > > and implementations will recursively search parents for #*-cells
> > > properties. Hence we only copy if it is present.
> > >
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Reviewed-by: Julien Grall <julien.grall@linaro.org>
> > 
> > Without this patch I can't boot Xen on the Foundation model with GIC-v3. 
> > Is it possible to push this patch for Xen 4.5 rc1?
> 
> Konrad, I think this is needed for 4.5 since without it dom0 can fail to
> parse certain other constructs within the DT (in bits which we don't
> generate and can't easily/don't want to rewrite as we pass them
> through).

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


> 
> The risk is that some bit of DT which we do generate relies on this
> value being absent (as it was before this patch). I don't believe we
> generate any such nodes. The consumers are typically nodes representing
> devices which we pass through rather than messing with them.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:20:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:20:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlhmH-00032M-Ou; Tue, 04 Nov 2014 17:20:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlhmG-00032H-H4
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 17:20:20 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	2E/43-24859-3DA09545; Tue, 04 Nov 2014 17:20:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415121616!11581815!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15243 invoked from network); 4 Nov 2014 17:20:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 17:20:18 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4HK8Lq007027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 17:20:10 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HK7jH029498
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 17:20:08 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HK7mE029490; Tue, 4 Nov 2014 17:20:07 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 09:20:07 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1483C1106DA; Tue,  4 Nov 2014 12:20:06 -0500 (EST)
Date: Tue, 4 Nov 2014 12:20:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141104172006.GL4510@laptop.dumpdata.com>
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
	<1415096249.11486.12.camel@citrix.com>
	<alpine.DEB.2.02.1411041019300.22875@kaball.uk.xensource.com>
	<5458CB0F.7000600@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5458CB0F.7000600@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xen.org, tim@xen.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 12:48:15PM +0000, Julien Grall wrote:
> On 11/04/2014 10:20 AM, Stefano Stabellini wrote:
> > On Tue, 4 Nov 2014, Ian Campbell wrote:
> >> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
> >>
> >> I think we should apply this workaround for 4.5 and do things properly
> >> for 4.6. Any thoughts?
> >  
> > I agree with you
> 
> +1


/me unrolls the first-bandaid and puts it on Xen and signs it with:
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Regards,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:20:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:20:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlhmH-00032M-Ou; Tue, 04 Nov 2014 17:20:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlhmG-00032H-H4
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 17:20:20 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	2E/43-24859-3DA09545; Tue, 04 Nov 2014 17:20:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415121616!11581815!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15243 invoked from network); 4 Nov 2014 17:20:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 17:20:18 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4HK8Lq007027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 17:20:10 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HK7jH029498
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 17:20:08 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HK7mE029490; Tue, 4 Nov 2014 17:20:07 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 09:20:07 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1483C1106DA; Tue,  4 Nov 2014 12:20:06 -0500 (EST)
Date: Tue, 4 Nov 2014 12:20:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141104172006.GL4510@laptop.dumpdata.com>
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
	<1415096249.11486.12.camel@citrix.com>
	<alpine.DEB.2.02.1411041019300.22875@kaball.uk.xensource.com>
	<5458CB0F.7000600@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5458CB0F.7000600@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xen.org, tim@xen.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 12:48:15PM +0000, Julien Grall wrote:
> On 11/04/2014 10:20 AM, Stefano Stabellini wrote:
> > On Tue, 4 Nov 2014, Ian Campbell wrote:
> >> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
> >>
> >> I think we should apply this workaround for 4.5 and do things properly
> >> for 4.6. Any thoughts?
> >  
> > I agree with you
> 
> +1


/me unrolls the first-bandaid and puts it on Xen and signs it with:
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Regards,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:27:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlhsa-0003MU-QY; Tue, 04 Nov 2014 17:26:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlhsZ-0003MP-6h
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 17:26:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	21/84-09842-A5C09545; Tue, 04 Nov 2014 17:26:50 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415122009!12185983!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14322 invoked from network); 4 Nov 2014 17:26:50 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 17:26:50 -0000
Received: by mail-wi0-f172.google.com with SMTP id bs8so10083724wib.11
	for <xen-devel@lists.xenproject.org>;
	Tue, 04 Nov 2014 09:26:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=F1az24psK6HgsKK3mpInQ+qnyKgnGAJD5HMG95+RxWQ=;
	b=M2U3MLp3SUFBi7rg8jFo9e1nSHn/YqC6sJ4Axb3Z8d2gsnc50bzI5iDgBlUUZt8RMu
	AAZ+672Y3WOJJ+ctIKrfYqkG8eAclOPiIxottys4Fv60jVnrZ6Dy+Vh0rdBk4lWNasxu
	+kY/HhKOI8UMP82e2ilw9cFRhtouxjxmra3V+Jr/ypG8VHalebwfkA2xgA/cPUUPkXQZ
	vKiNX66bZJU4MQl6kg7zm1OQUJI1hr3STsiylQjVZsPEhVrMvx3CavgRuMujuSfjFoq7
	+rekaA7k9AAsBKdGBmHYNi/cR9aROsarpNrv+I5lhOwcb2lqoCoJC9yDLU+oWEObPtlz
	sE7Q==
X-Gm-Message-State: ALoCoQnGiynuKJf1ywR9K51DbwMu3RHX/Nk70mN/Hp2/HBd2FCojsHIRkZi0/z6zC94FWk0ovU79
X-Received: by 10.180.11.66 with SMTP id o2mr26073331wib.22.1415122009671;
	Tue, 04 Nov 2014 09:26:49 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ua8sm1253337wjc.7.2014.11.04.09.26.44
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 09:26:46 -0800 (PST)
Message-ID: <54590C48.4080100@linaro.org>
Date: Tue, 04 Nov 2014 17:26:32 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
In-Reply-To: <20141103163904.GF1638@laptop.dumpdata.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 03, 2014 at 06:07:33PM +0530, Vijay Kilari wrote:
>> On Mon, Nov 3, 2014 at 4:31 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>>> On Sat, 1 Nov 2014, Julien Grall wrote:
>>>> The vGIC will emulate the same version as the hardware. The toolstack has
>>>> to retrieve the version of the vGIC in order to be able to create the
>>>> corresponding device tree node.
>>>>
>>>> A new DOMCTL has been introduced for ARM to configure the domain. For now
>>>> it only allow the toolstack to retrieve the version of vGIC.
>>>> This DOMCTL will be extend later to let the user choose the version of the
>>>> emulated GIC.
>>>>
>>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>>> Cc: Jan Beulich <jbeulich@suse.com>
>>>> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>
>>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>
>> Tested with GICv3 platform.
> 
> Thank you for doing that.
> 
> It also needs Acks from Daniel and Jan.

This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
required. Would Ian C. ack be enough?

Anyway, Jan do you have any objection on this patch?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:27:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlhsa-0003MU-QY; Tue, 04 Nov 2014 17:26:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlhsZ-0003MP-6h
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 17:26:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	21/84-09842-A5C09545; Tue, 04 Nov 2014 17:26:50 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415122009!12185983!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14322 invoked from network); 4 Nov 2014 17:26:50 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 17:26:50 -0000
Received: by mail-wi0-f172.google.com with SMTP id bs8so10083724wib.11
	for <xen-devel@lists.xenproject.org>;
	Tue, 04 Nov 2014 09:26:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=F1az24psK6HgsKK3mpInQ+qnyKgnGAJD5HMG95+RxWQ=;
	b=M2U3MLp3SUFBi7rg8jFo9e1nSHn/YqC6sJ4Axb3Z8d2gsnc50bzI5iDgBlUUZt8RMu
	AAZ+672Y3WOJJ+ctIKrfYqkG8eAclOPiIxottys4Fv60jVnrZ6Dy+Vh0rdBk4lWNasxu
	+kY/HhKOI8UMP82e2ilw9cFRhtouxjxmra3V+Jr/ypG8VHalebwfkA2xgA/cPUUPkXQZ
	vKiNX66bZJU4MQl6kg7zm1OQUJI1hr3STsiylQjVZsPEhVrMvx3CavgRuMujuSfjFoq7
	+rekaA7k9AAsBKdGBmHYNi/cR9aROsarpNrv+I5lhOwcb2lqoCoJC9yDLU+oWEObPtlz
	sE7Q==
X-Gm-Message-State: ALoCoQnGiynuKJf1ywR9K51DbwMu3RHX/Nk70mN/Hp2/HBd2FCojsHIRkZi0/z6zC94FWk0ovU79
X-Received: by 10.180.11.66 with SMTP id o2mr26073331wib.22.1415122009671;
	Tue, 04 Nov 2014 09:26:49 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ua8sm1253337wjc.7.2014.11.04.09.26.44
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 09:26:46 -0800 (PST)
Message-ID: <54590C48.4080100@linaro.org>
Date: Tue, 04 Nov 2014 17:26:32 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
In-Reply-To: <20141103163904.GF1638@laptop.dumpdata.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 03, 2014 at 06:07:33PM +0530, Vijay Kilari wrote:
>> On Mon, Nov 3, 2014 at 4:31 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>>> On Sat, 1 Nov 2014, Julien Grall wrote:
>>>> The vGIC will emulate the same version as the hardware. The toolstack has
>>>> to retrieve the version of the vGIC in order to be able to create the
>>>> corresponding device tree node.
>>>>
>>>> A new DOMCTL has been introduced for ARM to configure the domain. For now
>>>> it only allow the toolstack to retrieve the version of vGIC.
>>>> This DOMCTL will be extend later to let the user choose the version of the
>>>> emulated GIC.
>>>>
>>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>>> Cc: Jan Beulich <jbeulich@suse.com>
>>>> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>
>>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>
>> Tested with GICv3 platform.
> 
> Thank you for doing that.
> 
> It also needs Acks from Daniel and Jan.

This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
required. Would Ian C. ack be enough?

Anyway, Jan do you have any objection on this patch?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:31:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:31:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlhwY-0003UX-Ez; Tue, 04 Nov 2014 17:30:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XlhwW-0003UQ-Bn
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 17:30:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A1/65-24532-F4D09545; Tue, 04 Nov 2014 17:30:55 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415122254!12186846!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5448 invoked from network); 4 Nov 2014 17:30:54 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 17:30:54 -0000
Received: from joan.univie.ac.at ([131.130.3.110] helo=joan.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlhwT-000301-30; Tue, 04 Nov 2014 18:30:53 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.64])
	by joan.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlhwS-0004H6-9V; Tue, 04 Nov 2014 18:30:53 +0100
Message-ID: <54590D4D.90300@web2web.at>
Date: Tue, 04 Nov 2014 18:30:53 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>				<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>			<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>		
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>	
	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com>
In-Reply-To: <1415118690.11486.53.camel@citrix.com>
Content-Type: multipart/mixed; boundary="------------020204050108010104030202"
X-Univie-Virus-Scan: scanned by ClamAV on joan.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------020204050108010104030202
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Am 04.11.14 um 17:31 schrieb Ian Campbell:
> On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
>> Am 04.11.14 um 16:44 schrieb Ian Campbell:
>>> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
>>> You could try running the xl command under valgrind, you may find "xl
>>> create -F" (which keeps xl in the foreground) handy if you try this.
>>> That might help catch any heap corruption etc.
>> I don't know what valgrind is, but I'll have a look and see how to deal
>> with that ...
>
> Valgrind is a totally awesome memory allocation debugger ;-)
>
In the attached file named 'valgrind 'please find the output of
	# valgrind xl create -F -c pfsense

There's a lot of information in that file which is above my current 
level of expertise, but I am sure you are able to make sense out of it.

BTW the stuff at lines 6 and 111 to 119 is the usual output of the xl 
command before it segfaults.

Thanks Atom2

--------------020204050108010104030202
Content-Type: text/plain; charset=windows-1252;
 name="valgrind"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="valgrind"

PT0zMDUyND09IE1lbWNoZWNrLCBhIG1lbW9yeSBlcnJvciBkZXRlY3Rvcgo9PTMwNTI0PT0g
Q29weXJpZ2h0IChDKSAyMDAyLTIwMTMsIGFuZCBHTlUgR1BMJ2QsIGJ5IEp1bGlhbiBTZXdh
cmQgZXQgYWwuCj09MzA1MjQ9PSBVc2luZyBWYWxncmluZC0zLjkuMCBhbmQgTGliVkVYOyBy
ZXJ1biB3aXRoIC1oIGZvciBjb3B5cmlnaHQgaW5mbwo9PTMwNTI0PT0gQ29tbWFuZDogeGwg
Y3JlYXRlIC1GIC1jIHBmc2Vuc2UKPT0zMDUyND09ClBhcnNpbmcgY29uZmlnIGZyb20gcGZz
ZW5zZQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5p
bml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDU5RTgxOiBsaWJ4bF9s
aXN0X2RvbWFpbiAobGlieGwuYzo1NjApCj09MzA1MjQ9PSAgICBieSAweDUwN0JGNTA6IGxp
YnhsX25hbWVfdG9fZG9taWQgKGxpYnhsX3V0aWxzLmM6NzMpCj09MzA1MjQ9PSAgICBieSAw
eDUwNTkzNjQ6IGxpYnhsX19kb21haW5fcmVuYW1lIChsaWJ4bC5jOjMxMikKPT0zMDUyND09
ICAgIGJ5IDB4NTA2OTE2MTogbGlieGxfX2RvbWFpbl9tYWtlIChsaWJ4bF9jcmVhdGUuYzo0
NzEpCj09MzA1MjQ9PSAgICBieSAweDUwNjlGNTc6IGRvX2RvbWFpbl9jcmVhdGUgKGxpYnhs
X2NyZWF0ZS5jOjY0MykKPT0zMDUyND09ICAgIGJ5IDB4NTA2QTQ1OTogbGlieGxfZG9tYWlu
X2NyZWF0ZV9uZXcgKGxpYnhsX2NyZWF0ZS5jOjEyNzcpCj09MzA1MjQ9PSAgICBieSAweDEx
OUFENzogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjIwMjApCj09MzA1MjQ9PSAgICBi
eSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0g
ICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUyND09IENv
bmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUo
cykKPT0zMDUyND09ICAgIGF0IDB4NTA1OUU4NTogbGlieGxfbGlzdF9kb21haW4gKGxpYnhs
LmM6NTY2KQo9PTMwNTI0PT0gICAgYnkgMHg1MDdCRjUwOiBsaWJ4bF9uYW1lX3RvX2RvbWlk
IChsaWJ4bF91dGlscy5jOjczKQo9PTMwNTI0PT0gICAgYnkgMHg1MDU5MzY0OiBsaWJ4bF9f
ZG9tYWluX3JlbmFtZSAobGlieGwuYzozMTIpCj09MzA1MjQ9PSAgICBieSAweDUwNjkxNjE6
IGxpYnhsX19kb21haW5fbWFrZSAobGlieGxfY3JlYXRlLmM6NDcxKQo9PTMwNTI0PT0gICAg
YnkgMHg1MDY5RjU3OiBkb19kb21haW5fY3JlYXRlIChsaWJ4bF9jcmVhdGUuYzo2NDMpCj09
MzA1MjQ9PSAgICBieSAweDUwNkE0NTk6IGxpYnhsX2RvbWFpbl9jcmVhdGVfbmV3IChsaWJ4
bF9jcmVhdGUuYzoxMjc3KQo9PTMwNTI0PT0gICAgYnkgMHgxMTlBRDc6IGNyZWF0ZV9kb21h
aW4gKHhsX2NtZGltcGwuYzoyMDIwKQo9PTMwNTI0PT0gICAgYnkgMHgxMURCMzE6IG1haW5f
Y3JlYXRlICh4bF9jbWRpbXBsLmM6NDIxMSkKPT0zMDUyND09ICAgIGJ5IDB4MTEyMkU2OiBt
YWluICh4bC5jOjM1NikKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25kaXRpb25hbCBqdW1wIG9y
IG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09MzA1MjQ9PSAgICBh
dCAweDUwNTlGMDc6IGxpYnhsX2xpc3RfZG9tYWluIChsaWJ4bC5jOjU2NikKPT0zMDUyND09
ICAgIGJ5IDB4NTA3QkY1MDogbGlieGxfbmFtZV90b19kb21pZCAobGlieGxfdXRpbHMuYzo3
MykKPT0zMDUyND09ICAgIGJ5IDB4NTA1OTM2NDogbGlieGxfX2RvbWFpbl9yZW5hbWUgKGxp
YnhsLmM6MzEyKQo9PTMwNTI0PT0gICAgYnkgMHg1MDY5MTYxOiBsaWJ4bF9fZG9tYWluX21h
a2UgKGxpYnhsX2NyZWF0ZS5jOjQ3MSkKPT0zMDUyND09ICAgIGJ5IDB4NTA2OUY1NzogZG9f
ZG9tYWluX2NyZWF0ZSAobGlieGxfY3JlYXRlLmM6NjQzKQo9PTMwNTI0PT0gICAgYnkgMHg1
MDZBNDU5OiBsaWJ4bF9kb21haW5fY3JlYXRlX25ldyAobGlieGxfY3JlYXRlLmM6MTI3NykK
PT0zMDUyND09ICAgIGJ5IDB4MTE5QUQ3OiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6
MjAyMCkKPT0zMDUyND09ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1w
bC5jOjQyMTEpCj09MzA1MjQ9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09
MzA1MjQ9PQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24g
dW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDdCRjYyOiBsaWJ4
bF9uYW1lX3RvX2RvbWlkIChsaWJ4bF91dGlscy5jOjc3KQo9PTMwNTI0PT0gICAgYnkgMHg1
MDU5MzY0OiBsaWJ4bF9fZG9tYWluX3JlbmFtZSAobGlieGwuYzozMTIpCj09MzA1MjQ9PSAg
ICBieSAweDUwNjkxNjE6IGxpYnhsX19kb21haW5fbWFrZSAobGlieGxfY3JlYXRlLmM6NDcx
KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY5RjU3OiBkb19kb21haW5fY3JlYXRlIChsaWJ4bF9j
cmVhdGUuYzo2NDMpCj09MzA1MjQ9PSAgICBieSAweDUwNkE0NTk6IGxpYnhsX2RvbWFpbl9j
cmVhdGVfbmV3IChsaWJ4bF9jcmVhdGUuYzoxMjc3KQo9PTMwNTI0PT0gICAgYnkgMHgxMTlB
RDc6IGNyZWF0ZV9kb21haW4gKHhsX2NtZGltcGwuYzoyMDIwKQo9PTMwNTI0PT0gICAgYnkg
MHgxMURCMzE6IG1haW5fY3JlYXRlICh4bF9jbWRpbXBsLmM6NDIxMSkKPT0zMDUyND09ICAg
IGJ5IDB4MTEyMkU2OiBtYWluICh4bC5jOjM1NikKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25k
aXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMp
Cj09MzA1MjQ9PSAgICBhdCAweDUwN0JGQzM6IGxpYnhsX25hbWVfdG9fZG9taWQgKGxpYnhs
X3V0aWxzLmM6NzcpCj09MzA1MjQ9PSAgICBieSAweDUwNTkzNjQ6IGxpYnhsX19kb21haW5f
cmVuYW1lIChsaWJ4bC5jOjMxMikKPT0zMDUyND09ICAgIGJ5IDB4NTA2OTE2MTogbGlieGxf
X2RvbWFpbl9tYWtlIChsaWJ4bF9jcmVhdGUuYzo0NzEpCj09MzA1MjQ9PSAgICBieSAweDUw
NjlGNTc6IGRvX2RvbWFpbl9jcmVhdGUgKGxpYnhsX2NyZWF0ZS5jOjY0MykKPT0zMDUyND09
ICAgIGJ5IDB4NTA2QTQ1OTogbGlieGxfZG9tYWluX2NyZWF0ZV9uZXcgKGxpYnhsX2NyZWF0
ZS5jOjEyNzcpCj09MzA1MjQ9PSAgICBieSAweDExOUFENzogY3JlYXRlX2RvbWFpbiAoeGxf
Y21kaW1wbC5jOjIwMjApCj09MzA1MjQ9PSAgICBieSAweDExREIzMTogbWFpbl9jcmVhdGUg
KHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0gICAgYnkgMHgxMTIyRTY6IG1haW4gKHhs
LmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBk
ZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTA1
QTI5QjogbGlieGxfbGlzdF92bSAobGlieGwuYzo2ODQpCj09MzA1MjQ9PSAgICBieSAweDUw
NjkzNDc6IGxpYnhsX19kb21haW5fbWFrZSAobGlieGxfY3JlYXRlLmM6NTA2KQo9PTMwNTI0
PT0gICAgYnkgMHg1MDY5RjU3OiBkb19kb21haW5fY3JlYXRlIChsaWJ4bF9jcmVhdGUuYzo2
NDMpCj09MzA1MjQ9PSAgICBieSAweDUwNkE0NTk6IGxpYnhsX2RvbWFpbl9jcmVhdGVfbmV3
IChsaWJ4bF9jcmVhdGUuYzoxMjc3KQo9PTMwNTI0PT0gICAgYnkgMHgxMTlBRDc6IGNyZWF0
ZV9kb21haW4gKHhsX2NtZGltcGwuYzoyMDIwKQo9PTMwNTI0PT0gICAgYnkgMHgxMURCMzE6
IG1haW5fY3JlYXRlICh4bF9jbWRpbXBsLmM6NDIxMSkKPT0zMDUyND09ICAgIGJ5IDB4MTEy
MkU2OiBtYWluICh4bC5jOjM1NikKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25kaXRpb25hbCBq
dW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09MzA1MjQ9
PSAgICBhdCAweDUwNUEyOUY6IGxpYnhsX2xpc3Rfdm0gKGxpYnhsLmM6Njg4KQo9PTMwNTI0
PT0gICAgYnkgMHg1MDY5MzQ3OiBsaWJ4bF9fZG9tYWluX21ha2UgKGxpYnhsX2NyZWF0ZS5j
OjUwNikKPT0zMDUyND09ICAgIGJ5IDB4NTA2OUY1NzogZG9fZG9tYWluX2NyZWF0ZSAobGli
eGxfY3JlYXRlLmM6NjQzKQo9PTMwNTI0PT0gICAgYnkgMHg1MDZBNDU5OiBsaWJ4bF9kb21h
aW5fY3JlYXRlX25ldyAobGlieGxfY3JlYXRlLmM6MTI3NykKPT0zMDUyND09ICAgIGJ5IDB4
MTE5QUQ3OiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MjAyMCkKPT0zMDUyND09ICAg
IGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1wbC5jOjQyMTEpCj09MzA1MjQ9
PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09MzA1MjQ9PQo9PTMwNTI0PT0g
Q29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1
ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDVBMzRGOiBsaWJ4bF9saXN0X3ZtIChsaWJ4bC5j
OjY4OCkKPT0zMDUyND09ICAgIGJ5IDB4NTA2OTM0NzogbGlieGxfX2RvbWFpbl9tYWtlIChs
aWJ4bF9jcmVhdGUuYzo1MDYpCj09MzA1MjQ9PSAgICBieSAweDUwNjlGNTc6IGRvX2RvbWFp
bl9jcmVhdGUgKGxpYnhsX2NyZWF0ZS5jOjY0MykKPT0zMDUyND09ICAgIGJ5IDB4NTA2QTQ1
OTogbGlieGxfZG9tYWluX2NyZWF0ZV9uZXcgKGxpYnhsX2NyZWF0ZS5jOjEyNzcpCj09MzA1
MjQ9PSAgICBieSAweDExOUFENzogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjIwMjAp
Cj09MzA1MjQ9PSAgICBieSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0
MjExKQo9PTMwNTI0PT0gICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0
PT0KPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5p
dGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTA3MkZBMTogbGlieGxfX2Rv
bWFpbl9jcHVwb29sIChsaWJ4bF9kb20uYzo2NykKPT0zMDUyND09ICAgIGJ5IDB4NTA3MzA5
RTogbGlieGxfX2RvbWFpbl9zY2hlZHVsZXIgKGxpYnhsX2RvbS5jOjgyKQo9PTMwNTI0PT0g
ICAgYnkgMHg1MDZBMDFGOiBkb19kb21haW5fY3JlYXRlIChsaWJ4bF9jcmVhdGUuYzo1MykK
PT0zMDUyND09ICAgIGJ5IDB4NTA2QTQ1OTogbGlieGxfZG9tYWluX2NyZWF0ZV9uZXcgKGxp
YnhsX2NyZWF0ZS5jOjEyNzcpCj09MzA1MjQ9PSAgICBieSAweDExOUFENzogY3JlYXRlX2Rv
bWFpbiAoeGxfY21kaW1wbC5jOjIwMjApCj09MzA1MjQ9PSAgICBieSAweDExREIzMTogbWFp
bl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0gICAgYnkgMHgxMTIyRTY6
IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAg
b3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAg
IGF0IDB4NTA3MkU1MTogbGlieGxfX2RvbWFpbl90eXBlIChsaWJ4bF9kb20uYzozNCkKPT0z
MDUyND09ICAgIGJ5IDB4NTA1RjIwRDogbGlieGxfX2RldmljZV9uaWNfc2V0ZGVmYXVsdCAo
bGlieGwuYzoyODI3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDZBMTk5OiBkb19kb21haW5fY3Jl
YXRlIChsaWJ4bF9jcmVhdGUuYzo2ODQpCj09MzA1MjQ9PSAgICBieSAweDUwNkE0NTk6IGxp
YnhsX2RvbWFpbl9jcmVhdGVfbmV3IChsaWJ4bF9jcmVhdGUuYzoxMjc3KQo9PTMwNTI0PT0g
ICAgYnkgMHgxMTlBRDc6IGNyZWF0ZV9kb21haW4gKHhsX2NtZGltcGwuYzoyMDIwKQo9PTMw
NTI0PT0gICAgYnkgMHgxMURCMzE6IG1haW5fY3JlYXRlICh4bF9jbWRpbXBsLmM6NDIxMSkK
PT0zMDUyND09ICAgIGJ5IDB4MTEyMkU2OiBtYWluICh4bC5jOjM1NikKPT0zMDUyND09Ci0t
MzA1MjQtLSBXQVJOSU5HOiB1bmhhbmRsZWQgX19IWVBFUlZJU09SX2RvbWN0bCBzdWJvcDog
MTAKLS0zMDUyNC0tIFlvdSBtYXkgYmUgYWJsZSB0byB3cml0ZSB5b3VyIG93biBoYW5kbGVy
LgotLTMwNTI0LS0gUmVhZCB0aGUgZmlsZSBSRUFETUVfTUlTU0lOR19TWVNDQUxMX09SX0lP
Q1RMLgotLTMwNTI0LS0gTmV2ZXJ0aGVsZXNzIHdlIGNvbnNpZGVyIHRoaXMgYSBidWcuICBQ
bGVhc2UgcmVwb3J0Ci0tMzA1MjQtLSBpdCBhdCBodHRwOi8vdmFsZ3JpbmQub3JnL3N1cHBv
cnQvYnVnX3JlcG9ydHMuaHRtbCAmCi0tMzA1MjQtLSBodHRwOi8vd2lraS54ZW4ub3JnL3dp
a2kvUmVwb3J0aW5nX0J1Z3NfYWdhaW5zdF9YZW4uCnhjOiBpbmZvOiBWSVJUVUFMIE1FTU9S
WSBBUlJBTkdFTUVOVDoKICBMb2FkZXI6ICAgICAgICAwMDAwMDAwMDAwMTAwMDAwLT4wMDAw
MDAwMDAwMWMxMmE0CiAgTW9kdWxlczogICAgICAgMDAwMDAwMDAwMDAwMDAwMC0+MDAwMDAw
MDAwMDAwMDAwMAogIFRPVEFMOiAgICAgICAgIDAwMDAwMDAwMDAwMDAwMDAtPjAwMDAwMDAw
MWY4MDAwMDAKICBFTlRSWSBBRERSRVNTOiAwMDAwMDAwMDAwMTAwMDAwCnhjOiBpbmZvOiBQ
SFlTSUNBTCBNRU1PUlkgQUxMT0NBVElPTjoKICA0S0IgUEFHRVM6IDB4MDAwMDAwMDAwMDAw
MDIwMAogIDJNQiBQQUdFUzogMHgwMDAwMDAwMDAwMDAwMGZiCiAgMUdCIFBBR0VTOiAweDAw
MDAwMDAwMDAwMDAwMDAKLS0zMDUyNC0tIFdBUk5JTkc6IHVuaGFuZGxlZCBfX0hZUEVSVklT
T1JfbWVtb3J5X29wIHN1Ym9wOiA3Ci0tMzA1MjQtLSBZb3UgbWF5IGJlIGFibGUgdG8gd3Jp
dGUgeW91ciBvd24gaGFuZGxlci4KLS0zMDUyNC0tIFJlYWQgdGhlIGZpbGUgUkVBRE1FX01J
U1NJTkdfU1lTQ0FMTF9PUl9JT0NUTC4KLS0zMDUyNC0tIE5ldmVydGhlbGVzcyB3ZSBjb25z
aWRlciB0aGlzIGEgYnVnLiAgUGxlYXNlIHJlcG9ydAotLTMwNTI0LS0gaXQgYXQgaHR0cDov
L3ZhbGdyaW5kLm9yZy9zdXBwb3J0L2J1Z19yZXBvcnRzLmh0bWwgJgotLTMwNTI0LS0gaHR0
cDovL3dpa2kueGVuLm9yZy93aWtpL1JlcG9ydGluZ19CdWdzX2FnYWluc3RfWGVuLgp4Yzog
ZXJyb3I6IHBhbmljOiB4Y19kb21fYm9vdC5jOjM4ODogeGNfZG9tX2dudHRhYl9odm1fc2Vl
ZDogZmFpbGVkIHRvIGFkZCBnbnR0YWIgdG8gcGh5c21hcCBbZXJybm89MzhdCjogSW50ZXJu
YWwgZXJyb3IKPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9u
IHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTA3MkZBMTogbGli
eGxfX2RvbWFpbl9jcHVwb29sIChsaWJ4bF9kb20uYzo2NykKPT0zMDUyND09ICAgIGJ5IDB4
NTA3MzA5RTogbGlieGxfX2RvbWFpbl9zY2hlZHVsZXIgKGxpYnhsX2RvbS5jOjgyKQo9PTMw
NTI0PT0gICAgYnkgMHg1MDY1NDZBOiBsaWJ4bF9kb21haW5fc2NoZWRfcGFyYW1zX3NldCAo
bGlieGwuYzo0NTk3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDczNUNFOiBsaWJ4bF9fYnVpbGRf
cG9zdCAobGlieGxfZG9tLmM6MjY3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY4RDczOiBsaWJ4
bF9fZG9tYWluX2J1aWxkIChsaWJ4bF9jcmVhdGUuYzozNzUpCj09MzA1MjQ9PSAgICBieSAw
eDUwNjlDNzA6IGRvbWNyZWF0ZV9ib290bG9hZGVyX2RvbmUgKGxpYnhsX2NyZWF0ZS5jOjc3
MCkKPT0zMDUyND09ICAgIGJ5IDB4NTA4QUQ0RjogYm9vdGxvYWRlcl9sb2NhbF9kZXRhY2hl
ZF9jYiAobGlieGxfYm9vdGxvYWRlci5jOjI4MSkKPT0zMDUyND09ICAgIGJ5IDB4NTA1ODNE
RDogbG9jYWxfZGV2aWNlX2RldGFjaF9jYiAobGlieGwuYzoyNzc3KQo9PTMwNTI0PT0gICAg
YnkgMHg1MDVFQjA1OiBsaWJ4bF9fZGV2aWNlX2Rpc2tfbG9jYWxfaW5pdGlhdGVfZGV0YWNo
IChsaWJ4bC5jOjI3NTIpCj09MzA1MjQ9PSAgICBieSAweDUwOEI1QTQ6IGJvb3Rsb2FkZXJf
Y2FsbGJhY2sgKGxpYnhsX2Jvb3Rsb2FkZXIuYzoyNjUpCj09MzA1MjQ9PSAgICBieSAweDUw
OEM1QzA6IGxpYnhsX19ib290bG9hZGVyX3J1biAobGlieGxfYm9vdGxvYWRlci5jOjM5MikK
PT0zMDUyND09ICAgIGJ5IDB4NTA2QTJFQjogZG9fZG9tYWluX2NyZWF0ZSAobGlieGxfY3Jl
YXRlLmM6NzA5KQo9PTMwNTI0PT0KPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92
ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4
NTA2NTYzRTogbGlieGxfZG9tYWluX3NjaGVkX3BhcmFtc19zZXQgKGxpYnhsLmM6NDM3MCkK
PT0zMDUyND09ICAgIGJ5IDB4NTA3MzVDRTogbGlieGxfX2J1aWxkX3Bvc3QgKGxpYnhsX2Rv
bS5jOjI2NykKPT0zMDUyND09ICAgIGJ5IDB4NTA2OEQ3MzogbGlieGxfX2RvbWFpbl9idWls
ZCAobGlieGxfY3JlYXRlLmM6Mzc1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY5QzcwOiBkb21j
cmVhdGVfYm9vdGxvYWRlcl9kb25lIChsaWJ4bF9jcmVhdGUuYzo3NzApCj09MzA1MjQ9PSAg
ICBieSAweDUwOEFENEY6IGJvb3Rsb2FkZXJfbG9jYWxfZGV0YWNoZWRfY2IgKGxpYnhsX2Jv
b3Rsb2FkZXIuYzoyODEpCj09MzA1MjQ9PSAgICBieSAweDUwNTgzREQ6IGxvY2FsX2Rldmlj
ZV9kZXRhY2hfY2IgKGxpYnhsLmM6Mjc3NykKPT0zMDUyND09ICAgIGJ5IDB4NTA1RUIwNTog
bGlieGxfX2RldmljZV9kaXNrX2xvY2FsX2luaXRpYXRlX2RldGFjaCAobGlieGwuYzoyNzUy
KQo9PTMwNTI0PT0gICAgYnkgMHg1MDhCNUE0OiBib290bG9hZGVyX2NhbGxiYWNrIChsaWJ4
bF9ib290bG9hZGVyLmM6MjY1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDhDNUMwOiBsaWJ4bF9f
Ym9vdGxvYWRlcl9ydW4gKGxpYnhsX2Jvb3Rsb2FkZXIuYzozOTIpCj09MzA1MjQ9PSAgICBi
eSAweDUwNkEyRUI6IGRvX2RvbWFpbl9jcmVhdGUgKGxpYnhsX2NyZWF0ZS5jOjcwOSkKPT0z
MDUyND09ICAgIGJ5IDB4NTA2QTQ1OTogbGlieGxfZG9tYWluX2NyZWF0ZV9uZXcgKGxpYnhs
X2NyZWF0ZS5jOjEyNzcpCj09MzA1MjQ9PSAgICBieSAweDExOUFENzogY3JlYXRlX2RvbWFp
biAoeGxfY21kaW1wbC5jOjIwMjApCj09MzA1MjQ9PQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwg
anVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0
PT0gICAgYXQgMHg1MDY1NjkwOiBsaWJ4bF9kb21haW5fc2NoZWRfcGFyYW1zX3NldCAobGli
eGwuYzo0Mzc0KQo9PTMwNTI0PT0gICAgYnkgMHg1MDczNUNFOiBsaWJ4bF9fYnVpbGRfcG9z
dCAobGlieGxfZG9tLmM6MjY3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY4RDczOiBsaWJ4bF9f
ZG9tYWluX2J1aWxkIChsaWJ4bF9jcmVhdGUuYzozNzUpCj09MzA1MjQ9PSAgICBieSAweDUw
NjlDNzA6IGRvbWNyZWF0ZV9ib290bG9hZGVyX2RvbmUgKGxpYnhsX2NyZWF0ZS5jOjc3MCkK
PT0zMDUyND09ICAgIGJ5IDB4NTA4QUQ0RjogYm9vdGxvYWRlcl9sb2NhbF9kZXRhY2hlZF9j
YiAobGlieGxfYm9vdGxvYWRlci5jOjI4MSkKPT0zMDUyND09ICAgIGJ5IDB4NTA1ODNERDog
bG9jYWxfZGV2aWNlX2RldGFjaF9jYiAobGlieGwuYzoyNzc3KQo9PTMwNTI0PT0gICAgYnkg
MHg1MDVFQjA1OiBsaWJ4bF9fZGV2aWNlX2Rpc2tfbG9jYWxfaW5pdGlhdGVfZGV0YWNoIChs
aWJ4bC5jOjI3NTIpCj09MzA1MjQ9PSAgICBieSAweDUwOEI1QTQ6IGJvb3Rsb2FkZXJfY2Fs
bGJhY2sgKGxpYnhsX2Jvb3Rsb2FkZXIuYzoyNjUpCj09MzA1MjQ9PSAgICBieSAweDUwOEM1
QzA6IGxpYnhsX19ib290bG9hZGVyX3J1biAobGlieGxfYm9vdGxvYWRlci5jOjM5MikKPT0z
MDUyND09ICAgIGJ5IDB4NTA2QTJFQjogZG9fZG9tYWluX2NyZWF0ZSAobGlieGxfY3JlYXRl
LmM6NzA5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDZBNDU5OiBsaWJ4bF9kb21haW5fY3JlYXRl
X25ldyAobGlieGxfY3JlYXRlLmM6MTI3NykKPT0zMDUyND09ICAgIGJ5IDB4MTE5QUQ3OiBj
cmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MjAyMCkKPT0zMDUyND09Cj09MzA1MjQ9PSBD
b25kaXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVl
KHMpCj09MzA1MjQ9PSAgICBhdCAweDUwNzJFNTE6IGxpYnhsX19kb21haW5fdHlwZSAobGli
eGxfZG9tLmM6MzQpCj09MzA1MjQ9PSAgICBieSAweDUwNUQ2REE6IGRldmljZV9kaXNrX2Fk
ZCAobGlieGwuYzoyMDYxKQo9PTMwNTI0PT0gICAgYnkgMHg1MDVERTY1OiBsaWJ4bF9fZGV2
aWNlX2Rpc2tfYWRkIChsaWJ4bC5jOjIyMjkpCj09MzA1MjQ9PSAgICBieSAweDUwNzk3MjM6
IGxpYnhsX19hZGRfZGlza3MgKGxpYnhsX2RldmljZS5jOjU0OSkKPT0zMDUyND09ICAgIGJ5
IDB4NTA2NzcxQzogZG9tY3JlYXRlX3JlYnVpbGRfZG9uZSAobGlieGxfY3JlYXRlLmM6OTMz
KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY5QzdFOiBkb21jcmVhdGVfYm9vdGxvYWRlcl9kb25l
IChsaWJ4bF9jcmVhdGUuYzo3NzEpCj09MzA1MjQ9PSAgICBieSAweDUwOEFENEY6IGJvb3Rs
b2FkZXJfbG9jYWxfZGV0YWNoZWRfY2IgKGxpYnhsX2Jvb3Rsb2FkZXIuYzoyODEpCj09MzA1
MjQ9PSAgICBieSAweDUwNTgzREQ6IGxvY2FsX2RldmljZV9kZXRhY2hfY2IgKGxpYnhsLmM6
Mjc3NykKPT0zMDUyND09ICAgIGJ5IDB4NTA1RUIwNTogbGlieGxfX2RldmljZV9kaXNrX2xv
Y2FsX2luaXRpYXRlX2RldGFjaCAobGlieGwuYzoyNzUyKQo9PTMwNTI0PT0gICAgYnkgMHg1
MDhCNUE0OiBib290bG9hZGVyX2NhbGxiYWNrIChsaWJ4bF9ib290bG9hZGVyLmM6MjY1KQo9
PTMwNTI0PT0gICAgYnkgMHg1MDhDNUMwOiBsaWJ4bF9fYm9vdGxvYWRlcl9ydW4gKGxpYnhs
X2Jvb3Rsb2FkZXIuYzozOTIpCj09MzA1MjQ9PSAgICBieSAweDUwNkEyRUI6IGRvX2RvbWFp
bl9jcmVhdGUgKGxpYnhsX2NyZWF0ZS5jOjcwOSkKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25k
aXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMp
Cj09MzA1MjQ9PSAgICBhdCAweDUwNTlGOEE6IGxpYnhsX2RvbWFpbl9pbmZvIChsaWJ4bC5j
OjU3OSkKPT0zMDUyND09ICAgIGJ5IDB4NTA3OUZCQTogbGlieGxfX3dhaXRfZGV2aWNlX2Nv
bm5lY3Rpb24gKGxpYnhsX2RldmljZS5jOjcyMykKPT0zMDUyND09ICAgIGJ5IDB4NTA1RERC
ODogZGV2aWNlX2Rpc2tfYWRkIChsaWJ4bC5jOjIyMTUpCj09MzA1MjQ9PSAgICBieSAweDUw
NURFNjU6IGxpYnhsX19kZXZpY2VfZGlza19hZGQgKGxpYnhsLmM6MjIyOSkKPT0zMDUyND09
ICAgIGJ5IDB4NTA3OTcyMzogbGlieGxfX2FkZF9kaXNrcyAobGlieGxfZGV2aWNlLmM6NTQ5
KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY3NzFDOiBkb21jcmVhdGVfcmVidWlsZF9kb25lIChs
aWJ4bF9jcmVhdGUuYzo5MzMpCj09MzA1MjQ9PSAgICBieSAweDUwNjlDN0U6IGRvbWNyZWF0
ZV9ib290bG9hZGVyX2RvbmUgKGxpYnhsX2NyZWF0ZS5jOjc3MSkKPT0zMDUyND09ICAgIGJ5
IDB4NTA4QUQ0RjogYm9vdGxvYWRlcl9sb2NhbF9kZXRhY2hlZF9jYiAobGlieGxfYm9vdGxv
YWRlci5jOjI4MSkKPT0zMDUyND09ICAgIGJ5IDB4NTA1ODNERDogbG9jYWxfZGV2aWNlX2Rl
dGFjaF9jYiAobGlieGwuYzoyNzc3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDVFQjA1OiBsaWJ4
bF9fZGV2aWNlX2Rpc2tfbG9jYWxfaW5pdGlhdGVfZGV0YWNoIChsaWJ4bC5jOjI3NTIpCj09
MzA1MjQ9PSAgICBieSAweDUwOEI1QTQ6IGJvb3Rsb2FkZXJfY2FsbGJhY2sgKGxpYnhsX2Jv
b3Rsb2FkZXIuYzoyNjUpCj09MzA1MjQ9PSAgICBieSAweDUwOEM1QzA6IGxpYnhsX19ib290
bG9hZGVyX3J1biAobGlieGxfYm9vdGxvYWRlci5jOjM5MikKPT0zMDUyND09Cj09MzA1MjQ9
PSBDb25kaXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZh
bHVlKHMpCj09MzA1MjQ9PSAgICBhdCAweDUwNTlGQ0Q6IGxpYnhsX2RvbWFpbl9pbmZvIChs
aWJ4bC5jOjU4MykKPT0zMDUyND09ICAgIGJ5IDB4NTA3OUZCQTogbGlieGxfX3dhaXRfZGV2
aWNlX2Nvbm5lY3Rpb24gKGxpYnhsX2RldmljZS5jOjcyMykKPT0zMDUyND09ICAgIGJ5IDB4
NTA1RERCODogZGV2aWNlX2Rpc2tfYWRkIChsaWJ4bC5jOjIyMTUpCj09MzA1MjQ9PSAgICBi
eSAweDUwNURFNjU6IGxpYnhsX19kZXZpY2VfZGlza19hZGQgKGxpYnhsLmM6MjIyOSkKPT0z
MDUyND09ICAgIGJ5IDB4NTA3OTcyMzogbGlieGxfX2FkZF9kaXNrcyAobGlieGxfZGV2aWNl
LmM6NTQ5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY3NzFDOiBkb21jcmVhdGVfcmVidWlsZF9k
b25lIChsaWJ4bF9jcmVhdGUuYzo5MzMpCj09MzA1MjQ9PSAgICBieSAweDUwNjlDN0U6IGRv
bWNyZWF0ZV9ib290bG9hZGVyX2RvbmUgKGxpYnhsX2NyZWF0ZS5jOjc3MSkKPT0zMDUyND09
ICAgIGJ5IDB4NTA4QUQ0RjogYm9vdGxvYWRlcl9sb2NhbF9kZXRhY2hlZF9jYiAobGlieGxf
Ym9vdGxvYWRlci5jOjI4MSkKPT0zMDUyND09ICAgIGJ5IDB4NTA1ODNERDogbG9jYWxfZGV2
aWNlX2RldGFjaF9jYiAobGlieGwuYzoyNzc3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDVFQjA1
OiBsaWJ4bF9fZGV2aWNlX2Rpc2tfbG9jYWxfaW5pdGlhdGVfZGV0YWNoIChsaWJ4bC5jOjI3
NTIpCj09MzA1MjQ9PSAgICBieSAweDUwOEI1QTQ6IGJvb3Rsb2FkZXJfY2FsbGJhY2sgKGxp
YnhsX2Jvb3Rsb2FkZXIuYzoyNjUpCj09MzA1MjQ9PSAgICBieSAweDUwOEM1QzA6IGxpYnhs
X19ib290bG9hZGVyX3J1biAobGlieGxfYm9vdGxvYWRlci5jOjM5MikKPT0zMDUyND09Cj09
MzA1MjQ9PSBDb25kaXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxp
c2VkIHZhbHVlKHMpCj09MzA1MjQ9PSAgICBhdCAweDUwNzJFNTE6IGxpYnhsX19kb21haW5f
dHlwZSAobGlieGxfZG9tLmM6MzQpCj09MzA1MjQ9PSAgICBieSAweDUwNUYyMEQ6IGxpYnhs
X19kZXZpY2VfbmljX3NldGRlZmF1bHQgKGxpYnhsLmM6MjgyNykKPT0zMDUyND09ICAgIGJ5
IDB4NTA1RjMzRDogbGlieGxfX2RldmljZV9uaWNfYWRkIChsaWJ4bC5jOjI4NzEpCj09MzA1
MjQ9PSAgICBieSAweDUwNzk3Q0I6IGxpYnhsX19hZGRfbmljcyAobGlieGxfZGV2aWNlLmM6
NTUwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDY3QjNFOiBkb21jcmVhdGVfZGV2bW9kZWxfc3Rh
cnRlZCAobGlieGxfY3JlYXRlLmM6MTEwNCkKPT0zMDUyND09ICAgIGJ5IDB4NTA2QTk2Rjog
ZGV2aWNlX21vZGVsX3NwYXduX291dGNvbWUgKGxpYnhsX2RtLmM6MTI5NSkKPT0zMDUyND09
ICAgIGJ5IDB4NTA2QTlDNDogZGV2aWNlX21vZGVsX2RldGFjaGVkIChsaWJ4bF9kbS5jOjEy
NjkpCj09MzA1MjQ9PSAgICBieSAweDUwNzZCMjE6IHNwYXduX21pZGRsZV9kZWF0aCAobGli
eGxfZXhlYy5jOjQ2NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4QTEzOTogY2hpbGRwcm9jX3Jl
YXBlZCAobGlieGxfZm9yay5jOjI2NikKPT0zMDUyND09ICAgIGJ5IDB4NTA4QTU0MjogbGli
eGxfX2Zvcmtfc2VsZnBpcGVfd29rZW4gKGxpYnhsX2ZvcmsuYzozMDIpCj09MzA1MjQ9PSAg
ICBieSAweDUwODdGOEI6IGFmdGVycG9sbF9pbnRlcm5hbCAobGlieGxfZXZlbnQuYzoxMDA4
KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg4MjA4OiBldmVudGxvb3BfaXRlcmF0aW9uIChsaWJ4
bF9ldmVudC5jOjE0NDApCj09MzA1MjQ9PQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBv
ciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAg
YXQgMHg1MDU5RjhBOiBsaWJ4bF9kb21haW5faW5mbyAobGlieGwuYzo1NzkpCj09MzA1MjQ9
PSAgICBieSAweDUwNzlGQkE6IGxpYnhsX193YWl0X2RldmljZV9jb25uZWN0aW9uIChsaWJ4
bF9kZXZpY2UuYzo3MjMpCj09MzA1MjQ9PSAgICBieSAweDUwNUY3NDQ6IGxpYnhsX19kZXZp
Y2VfbmljX2FkZCAobGlieGwuYzoyOTQ3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDc5N0NCOiBs
aWJ4bF9fYWRkX25pY3MgKGxpYnhsX2RldmljZS5jOjU1MCkKPT0zMDUyND09ICAgIGJ5IDB4
NTA2N0IzRTogZG9tY3JlYXRlX2Rldm1vZGVsX3N0YXJ0ZWQgKGxpYnhsX2NyZWF0ZS5jOjEx
MDQpCj09MzA1MjQ9PSAgICBieSAweDUwNkE5NkY6IGRldmljZV9tb2RlbF9zcGF3bl9vdXRj
b21lIChsaWJ4bF9kbS5jOjEyOTUpCj09MzA1MjQ9PSAgICBieSAweDUwNkE5QzQ6IGRldmlj
ZV9tb2RlbF9kZXRhY2hlZCAobGlieGxfZG0uYzoxMjY5KQo9PTMwNTI0PT0gICAgYnkgMHg1
MDc2QjIxOiBzcGF3bl9taWRkbGVfZGVhdGggKGxpYnhsX2V4ZWMuYzo0NjUpCj09MzA1MjQ9
PSAgICBieSAweDUwOEExMzk6IGNoaWxkcHJvY19yZWFwZWQgKGxpYnhsX2ZvcmsuYzoyNjYp
Cj09MzA1MjQ9PSAgICBieSAweDUwOEE1NDI6IGxpYnhsX19mb3JrX3NlbGZwaXBlX3dva2Vu
IChsaWJ4bF9mb3JrLmM6MzAyKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg3RjhCOiBhZnRlcnBv
bGxfaW50ZXJuYWwgKGxpYnhsX2V2ZW50LmM6MTAwOCkKPT0zMDUyND09ICAgIGJ5IDB4NTA4
ODIwODogZXZlbnRsb29wX2l0ZXJhdGlvbiAobGlieGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0
PT0KPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5p
dGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTA1OUZDRDogbGlieGxfZG9t
YWluX2luZm8gKGxpYnhsLmM6NTgzKQo9PTMwNTI0PT0gICAgYnkgMHg1MDc5RkJBOiBsaWJ4
bF9fd2FpdF9kZXZpY2VfY29ubmVjdGlvbiAobGlieGxfZGV2aWNlLmM6NzIzKQo9PTMwNTI0
PT0gICAgYnkgMHg1MDVGNzQ0OiBsaWJ4bF9fZGV2aWNlX25pY19hZGQgKGxpYnhsLmM6Mjk0
NykKPT0zMDUyND09ICAgIGJ5IDB4NTA3OTdDQjogbGlieGxfX2FkZF9uaWNzIChsaWJ4bF9k
ZXZpY2UuYzo1NTApCj09MzA1MjQ9PSAgICBieSAweDUwNjdCM0U6IGRvbWNyZWF0ZV9kZXZt
b2RlbF9zdGFydGVkIChsaWJ4bF9jcmVhdGUuYzoxMTA0KQo9PTMwNTI0PT0gICAgYnkgMHg1
MDZBOTZGOiBkZXZpY2VfbW9kZWxfc3Bhd25fb3V0Y29tZSAobGlieGxfZG0uYzoxMjk1KQo9
PTMwNTI0PT0gICAgYnkgMHg1MDZBOUM0OiBkZXZpY2VfbW9kZWxfZGV0YWNoZWQgKGxpYnhs
X2RtLmM6MTI2OSkKPT0zMDUyND09ICAgIGJ5IDB4NTA3NkIyMTogc3Bhd25fbWlkZGxlX2Rl
YXRoIChsaWJ4bF9leGVjLmM6NDY1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDhBMTM5OiBjaGls
ZHByb2NfcmVhcGVkIChsaWJ4bF9mb3JrLmM6MjY2KQo9PTMwNTI0PT0gICAgYnkgMHg1MDhB
NTQyOiBsaWJ4bF9fZm9ya19zZWxmcGlwZV93b2tlbiAobGlieGxfZm9yay5jOjMwMikKPT0z
MDUyND09ICAgIGJ5IDB4NTA4N0Y4QjogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4bF9ldmVu
dC5jOjEwMDgpCj09MzA1MjQ9PSAgICBieSAweDUwODgyMDg6IGV2ZW50bG9vcF9pdGVyYXRp
b24gKGxpYnhsX2V2ZW50LmM6MTQ0MCkKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25kaXRpb25h
bCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09MzA1
MjQ9PSAgICBhdCAweDUwNzJFNTE6IGxpYnhsX19kb21haW5fdHlwZSAobGlieGxfZG9tLmM6
MzQpCj09MzA1MjQ9PSAgICBieSAweDUwNkZFQTg6IGxpYnhsX19kZXZpY2VfcGNpX2FkZCAo
bGlieGxfcGNpLmM6MTAzOCkKPT0zMDUyND09ICAgIGJ5IDB4NTA2NzgyRTogZG9tY3JlYXRl
X2F0dGFjaF9wY2kgKGxpYnhsX2NyZWF0ZS5jOjExNjgpCj09MzA1MjQ9PSAgICBieSAweDUw
NjdBMEY6IGRvbWNyZWF0ZV9hdHRhY2hfdnRwbXMgKGxpYnhsX2NyZWF0ZS5jOjExNDIpCj09
MzA1MjQ9PSAgICBieSAweDUwNzg1MzU6IG11bHRpZGV2X29uZV9jYWxsYmFjayAobGlieGxf
ZGV2aWNlLmM6NTEyKQo9PTMwNTI0PT0gICAgYnkgMHg1MDc5QTMyOiBkZXZpY2VfaG90cGx1
Z19kb25lIChsaWJ4bF9kZXZpY2UuYzoxMDU5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDc5Q0Q0
OiBkZXZpY2VfaG90cGx1ZyAobGlieGxfZGV2aWNlLmM6OTgyKQo9PTMwNTI0PT0gICAgYnkg
MHg1MDc5RTE2OiBkZXZpY2VfaG90cGx1Z19jaGlsZF9kZWF0aF9jYiAobGlieGxfZGV2aWNl
LmM6MTAzNikKPT0zMDUyND09ICAgIGJ5IDB4NTA4QTEzOTogY2hpbGRwcm9jX3JlYXBlZCAo
bGlieGxfZm9yay5jOjI2NikKPT0zMDUyND09ICAgIGJ5IDB4NTA4QTU0MjogbGlieGxfX2Zv
cmtfc2VsZnBpcGVfd29rZW4gKGxpYnhsX2ZvcmsuYzozMDIpCj09MzA1MjQ9PSAgICBieSAw
eDUwODdGOEI6IGFmdGVycG9sbF9pbnRlcm5hbCAobGlieGxfZXZlbnQuYzoxMDA4KQo9PTMw
NTI0PT0gICAgYnkgMHg1MDg4MjA4OiBldmVudGxvb3BfaXRlcmF0aW9uIChsaWJ4bF9ldmVu
dC5jOjE0NDApCj09MzA1MjQ9PQotLTMwNTI0LS0gV0FSTklORzogdW5oYW5kbGVkIF9fSFlQ
RVJWSVNPUl9kb21jdGwgc3Vib3A6IDQ1Ci0tMzA1MjQtLSBZb3UgbWF5IGJlIGFibGUgdG8g
d3JpdGUgeW91ciBvd24gaGFuZGxlci4KLS0zMDUyNC0tIFJlYWQgdGhlIGZpbGUgUkVBRE1F
X01JU1NJTkdfU1lTQ0FMTF9PUl9JT0NUTC4KLS0zMDUyNC0tIE5ldmVydGhlbGVzcyB3ZSBj
b25zaWRlciB0aGlzIGEgYnVnLiAgUGxlYXNlIHJlcG9ydAotLTMwNTI0LS0gaXQgYXQgaHR0
cDovL3ZhbGdyaW5kLm9yZy9zdXBwb3J0L2J1Z19yZXBvcnRzLmh0bWwgJgotLTMwNTI0LS0g
aHR0cDovL3dpa2kueGVuLm9yZy93aWtpL1JlcG9ydGluZ19CdWdzX2FnYWluc3RfWGVuLgps
aWJ4bDogZXJyb3I6IGxpYnhsX3BjaS5jOjEwNDU6bGlieGxfX2RldmljZV9wY2lfYWRkOiBQ
Q0kgZGV2aWNlIDAwMDA6MDQ6MDAuMCBjYW5ub3QgYmUgYXNzaWduZWQgLSBubyBJT01NVT8K
LS0zMDUyNC0tIFdBUk5JTkc6IHVuaGFuZGxlZCBfX0hZUEVSVklTT1JfZG9tY3RsIHN1Ym9w
OiA0NQotLTMwNTI0LS0gWW91IG1heSBiZSBhYmxlIHRvIHdyaXRlIHlvdXIgb3duIGhhbmRs
ZXIuCi0tMzA1MjQtLSBSZWFkIHRoZSBmaWxlIFJFQURNRV9NSVNTSU5HX1NZU0NBTExfT1Jf
SU9DVEwuCi0tMzA1MjQtLSBOZXZlcnRoZWxlc3Mgd2UgY29uc2lkZXIgdGhpcyBhIGJ1Zy4g
IFBsZWFzZSByZXBvcnQKLS0zMDUyNC0tIGl0IGF0IGh0dHA6Ly92YWxncmluZC5vcmcvc3Vw
cG9ydC9idWdfcmVwb3J0cy5odG1sICYKLS0zMDUyNC0tIGh0dHA6Ly93aWtpLnhlbi5vcmcv
d2lraS9SZXBvcnRpbmdfQnVnc19hZ2FpbnN0X1hlbi4KbGlieGw6IGVycm9yOiBsaWJ4bF9w
Y2kuYzoxMDQ1OmxpYnhsX19kZXZpY2VfcGNpX2FkZDogUENJIGRldmljZSAwMDAwOjBhOjA4
LjAgY2Fubm90IGJlIGFzc2lnbmVkIC0gbm8gSU9NTVU/Ci0tMzA1MjQtLSBXQVJOSU5HOiB1
bmhhbmRsZWQgX19IWVBFUlZJU09SX2RvbWN0bCBzdWJvcDogNDUKLS0zMDUyNC0tIFlvdSBt
YXkgYmUgYWJsZSB0byB3cml0ZSB5b3VyIG93biBoYW5kbGVyLgotLTMwNTI0LS0gUmVhZCB0
aGUgZmlsZSBSRUFETUVfTUlTU0lOR19TWVNDQUxMX09SX0lPQ1RMLgotLTMwNTI0LS0gTmV2
ZXJ0aGVsZXNzIHdlIGNvbnNpZGVyIHRoaXMgYSBidWcuICBQbGVhc2UgcmVwb3J0Ci0tMzA1
MjQtLSBpdCBhdCBodHRwOi8vdmFsZ3JpbmQub3JnL3N1cHBvcnQvYnVnX3JlcG9ydHMuaHRt
bCAmCi0tMzA1MjQtLSBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvUmVwb3J0aW5nX0J1Z3Nf
YWdhaW5zdF9YZW4uCmxpYnhsOiBlcnJvcjogbGlieGxfcGNpLmM6MTA0NTpsaWJ4bF9fZGV2
aWNlX3BjaV9hZGQ6IFBDSSBkZXZpY2UgMDAwMDowYTowYi4wIGNhbm5vdCBiZSBhc3NpZ25l
ZCAtIG5vIElPTU1VPwo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVu
ZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDU5RjhB
OiBsaWJ4bF9kb21haW5faW5mbyAobGlieGwuYzo1NzkpCj09MzA1MjQ9PSAgICBieSAweDUw
NzJDQzI6IHVzZXJkYXRhX3BhdGggKGxpYnhsX2RvbS5jOjE1MTYpCj09MzA1MjQ9PSAgICBi
eSAweDUwNzVDMDU6IGxpYnhsX3VzZXJkYXRhX3N0b3JlIChsaWJ4bF9kb20uYzoxNTc3KQo9
PTMwNTI0PT0gICAgYnkgMHgxMTlDNDQ6IGNyZWF0ZV9kb21haW4gKHhsX2NtZGltcGwuYzoy
MDUzKQo9PTMwNTI0PT0gICAgYnkgMHgxMURCMzE6IG1haW5fY3JlYXRlICh4bF9jbWRpbXBs
LmM6NDIxMSkKPT0zMDUyND09ICAgIGJ5IDB4MTEyMkU2OiBtYWluICh4bC5jOjM1NikKPT0z
MDUyND09Cj09MzA1MjQ9PSBDb25kaXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1
bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09MzA1MjQ9PSAgICBhdCAweDUwNTlGQ0Q6IGxpYnhs
X2RvbWFpbl9pbmZvIChsaWJ4bC5jOjU4MykKPT0zMDUyND09ICAgIGJ5IDB4NTA3MkNDMjog
dXNlcmRhdGFfcGF0aCAobGlieGxfZG9tLmM6MTUxNikKPT0zMDUyND09ICAgIGJ5IDB4NTA3
NUMwNTogbGlieGxfdXNlcmRhdGFfc3RvcmUgKGxpYnhsX2RvbS5jOjE1NzcpCj09MzA1MjQ9
PSAgICBieSAweDExOUM0NDogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjIwNTMpCj09
MzA1MjQ9PSAgICBieSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjEx
KQo9PTMwNTI0PT0gICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0K
PT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlh
bGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTA1OUY4QTogbGlieGxfZG9tYWlu
X2luZm8gKGxpYnhsLmM6NTc5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDcyQ0MyOiB1c2VyZGF0
YV9wYXRoIChsaWJ4bF9kb20uYzoxNTE2KQo9PTMwNTI0PT0gICAgYnkgMHg1MDc1QzNFOiBs
aWJ4bF91c2VyZGF0YV9zdG9yZSAobGlieGxfZG9tLmM6MTU4OCkKPT0zMDUyND09ICAgIGJ5
IDB4MTE5QzQ0OiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MjA1MykKPT0zMDUyND09
ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1wbC5jOjQyMTEpCj09MzA1
MjQ9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09MzA1MjQ9PQo9PTMwNTI0
PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2
YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDU5RkNEOiBsaWJ4bF9kb21haW5faW5mbyAo
bGlieGwuYzo1ODMpCj09MzA1MjQ9PSAgICBieSAweDUwNzJDQzI6IHVzZXJkYXRhX3BhdGgg
KGxpYnhsX2RvbS5jOjE1MTYpCj09MzA1MjQ9PSAgICBieSAweDUwNzVDM0U6IGxpYnhsX3Vz
ZXJkYXRhX3N0b3JlIChsaWJ4bF9kb20uYzoxNTg4KQo9PTMwNTI0PT0gICAgYnkgMHgxMTlD
NDQ6IGNyZWF0ZV9kb21haW4gKHhsX2NtZGltcGwuYzoyMDUzKQo9PTMwNTI0PT0gICAgYnkg
MHgxMURCMzE6IG1haW5fY3JlYXRlICh4bF9jbWRpbXBsLmM6NDIxMSkKPT0zMDUyND09ICAg
IGJ5IDB4MTEyMkU2OiBtYWluICh4bC5jOjM1NikKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25k
aXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMp
Cj09MzA1MjQ9PSAgICBhdCAweDUwNzJFNTE6IGxpYnhsX19kb21haW5fdHlwZSAobGlieGxf
ZG9tLmM6MzQpCj09MzA1MjQ9PSAgICBieSAweDUwNUFDMzU6IGxpYnhsX2RvbWFpbl91bnBh
dXNlIChsaWJ4bC5jOjgzNykKPT0zMDUyND09ICAgIGJ5IDB4MTE5QzgxOiBjcmVhdGVfZG9t
YWluICh4bF9jbWRpbXBsLmM6MjA2NCkKPT0zMDUyND09ICAgIGJ5IDB4MTFEQjMxOiBtYWlu
X2NyZWF0ZSAoeGxfY21kaW1wbC5jOjQyMTEpCj09MzA1MjQ9PSAgICBieSAweDExMjJFNjog
bWFpbiAoeGwuYzozNTYpCj09MzA1MjQ9PQpXYWl0aW5nIGZvciBkb21haW4gcGZzZW5zZSAo
ZG9taWQgMTYpIHRvIGRpZSBbcGlkIDMwNTI0XQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVt
cCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0g
ICAgYXQgMHg1MDU4QjAwOiBkb21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwu
Yzo5OTQpCj09MzA1MjQ9PSAgICBieSAweDUwODc2Mzc6IHdhdGNoZmRfY2FsbGJhY2sgKGxp
YnhsX2V2ZW50LmM6NTA0KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg3RUM1OiBhZnRlcnBvbGxf
aW50ZXJuYWwgKGxpYnhsX2V2ZW50LmM6OTk1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg4MjA4
OiBldmVudGxvb3BfaXRlcmF0aW9uIChsaWJ4bF9ldmVudC5jOjE0NDApCj09MzA1MjQ9PSAg
ICBieSAweDUwODkxQzY6IGxpYnhsX2V2ZW50X3dhaXQgKGxpYnhsX2V2ZW50LmM6MTQ2NSkK
PT0zMDUyND09ICAgIGJ5IDB4MTFBMTREOiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6
MTc4NikKPT0zMDUyND09ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1w
bC5jOjQyMTEpCj09MzA1MjQ9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09
MzA1MjQ9PQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24g
dW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1OTRFRTEyOiB2ZnBy
aW50ZiAodmZwcmludGYuYzoxNjM0KQo9PTMwNTI0PT0gICAgYnkgMHg1QTBERjBBOiBfX3Zh
c3ByaW50Zl9jaGsgKHZhc3ByaW50Zl9jaGsuYzo2NikKPT0zMDUyND09ICAgIGJ5IDB4NTA3
QUQ2MTogbGlieGxfX2xvZ3YgKHN0ZGlvMi5oOjIxMCkKPT0zMDUyND09ICAgIGJ5IDB4NTA3
QUYxQjogbGlieGxfX2xvZyAobGlieGxfaW50ZXJuYWwuYzoyMDkpCj09MzA1MjQ9PSAgICBi
eSAweDUwNThCQTE6IGRvbWFpbl9kZWF0aF94c3dhdGNoX2NhbGxiYWNrIChsaWJ4bC5jOjEw
MDIpCj09MzA1MjQ9PSAgICBieSAweDUwODc2Mzc6IHdhdGNoZmRfY2FsbGJhY2sgKGxpYnhs
X2V2ZW50LmM6NTA0KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg3RUM1OiBhZnRlcnBvbGxfaW50
ZXJuYWwgKGxpYnhsX2V2ZW50LmM6OTk1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg4MjA4OiBl
dmVudGxvb3BfaXRlcmF0aW9uIChsaWJ4bF9ldmVudC5jOjE0NDApCj09MzA1MjQ9PSAgICBi
eSAweDUwODkxQzY6IGxpYnhsX2V2ZW50X3dhaXQgKGxpYnhsX2V2ZW50LmM6MTQ2NSkKPT0z
MDUyND09ICAgIGJ5IDB4MTFBMTREOiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MTc4
NikKPT0zMDUyND09ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1wbC5j
OjQyMTEpCj09MzA1MjQ9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09MzA1
MjQ9PQo9PTMwNTI0PT0gVXNlIG9mIHVuaW5pdGlhbGlzZWQgdmFsdWUgb2Ygc2l6ZSA4Cj09
MzA1MjQ9PSAgICBhdCAweDU5NERDQkI6IF9pdG9hX3dvcmQgKF9pdG9hLmM6MTc5KQo9PTMw
NTI0PT0gICAgYnkgMHg1OTUwRTIzOiB2ZnByaW50ZiAodmZwcmludGYuYzoxNjM0KQo9PTMw
NTI0PT0gICAgYnkgMHg1QTBERjBBOiBfX3Zhc3ByaW50Zl9jaGsgKHZhc3ByaW50Zl9jaGsu
Yzo2NikKPT0zMDUyND09ICAgIGJ5IDB4NTA3QUQ2MTogbGlieGxfX2xvZ3YgKHN0ZGlvMi5o
OjIxMCkKPT0zMDUyND09ICAgIGJ5IDB4NTA3QUYxQjogbGlieGxfX2xvZyAobGlieGxfaW50
ZXJuYWwuYzoyMDkpCj09MzA1MjQ9PSAgICBieSAweDUwNThCQTE6IGRvbWFpbl9kZWF0aF94
c3dhdGNoX2NhbGxiYWNrIChsaWJ4bC5jOjEwMDIpCj09MzA1MjQ9PSAgICBieSAweDUwODc2
Mzc6IHdhdGNoZmRfY2FsbGJhY2sgKGxpYnhsX2V2ZW50LmM6NTA0KQo9PTMwNTI0PT0gICAg
YnkgMHg1MDg3RUM1OiBhZnRlcnBvbGxfaW50ZXJuYWwgKGxpYnhsX2V2ZW50LmM6OTk1KQo9
PTMwNTI0PT0gICAgYnkgMHg1MDg4MjA4OiBldmVudGxvb3BfaXRlcmF0aW9uIChsaWJ4bF9l
dmVudC5jOjE0NDApCj09MzA1MjQ9PSAgICBieSAweDUwODkxQzY6IGxpYnhsX2V2ZW50X3dh
aXQgKGxpYnhsX2V2ZW50LmM6MTQ2NSkKPT0zMDUyND09ICAgIGJ5IDB4MTFBMTREOiBjcmVh
dGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MTc4NikKPT0zMDUyND09ICAgIGJ5IDB4MTFEQjMx
OiBtYWluX2NyZWF0ZSAoeGxfY21kaW1wbC5jOjQyMTEpCj09MzA1MjQ9PQo9PTMwNTI0PT0g
Q29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1
ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1OTREQ0M1OiBfaXRvYV93b3JkIChfaXRvYS5jOjE3
OSkKPT0zMDUyND09ICAgIGJ5IDB4NTk1MEUyMzogdmZwcmludGYgKHZmcHJpbnRmLmM6MTYz
NCkKPT0zMDUyND09ICAgIGJ5IDB4NUEwREYwQTogX192YXNwcmludGZfY2hrICh2YXNwcmlu
dGZfY2hrLmM6NjYpCj09MzA1MjQ9PSAgICBieSAweDUwN0FENjE6IGxpYnhsX19sb2d2IChz
dGRpbzIuaDoyMTApCj09MzA1MjQ9PSAgICBieSAweDUwN0FGMUI6IGxpYnhsX19sb2cgKGxp
YnhsX2ludGVybmFsLmM6MjA5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDU4QkExOiBkb21haW5f
ZGVhdGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwuYzoxMDAyKQo9PTMwNTI0PT0gICAgYnkg
MHg1MDg3NjM3OiB3YXRjaGZkX2NhbGxiYWNrIChsaWJ4bF9ldmVudC5jOjUwNCkKPT0zMDUy
ND09ICAgIGJ5IDB4NTA4N0VDNTogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4bF9ldmVudC5j
Ojk5NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4ODIwODogZXZlbnRsb29wX2l0ZXJhdGlvbiAo
bGlieGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg5MUM2OiBsaWJ4bF9l
dmVudF93YWl0IChsaWJ4bF9ldmVudC5jOjE0NjUpCj09MzA1MjQ9PSAgICBieSAweDExQTE0
RDogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjE3ODYpCj09MzA1MjQ9PSAgICBieSAw
eDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0KPT0z
MDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlz
ZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTk1MEU3MzogdmZwcmludGYgKHZmcHJp
bnRmLmM6MTYzNCkKPT0zMDUyND09ICAgIGJ5IDB4NUEwREYwQTogX192YXNwcmludGZfY2hr
ICh2YXNwcmludGZfY2hrLmM6NjYpCj09MzA1MjQ9PSAgICBieSAweDUwN0FENjE6IGxpYnhs
X19sb2d2IChzdGRpbzIuaDoyMTApCj09MzA1MjQ9PSAgICBieSAweDUwN0FGMUI6IGxpYnhs
X19sb2cgKGxpYnhsX2ludGVybmFsLmM6MjA5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDU4QkEx
OiBkb21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwuYzoxMDAyKQo9PTMwNTI0
PT0gICAgYnkgMHg1MDg3NjM3OiB3YXRjaGZkX2NhbGxiYWNrIChsaWJ4bF9ldmVudC5jOjUw
NCkKPT0zMDUyND09ICAgIGJ5IDB4NTA4N0VDNTogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4
bF9ldmVudC5jOjk5NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4ODIwODogZXZlbnRsb29wX2l0
ZXJhdGlvbiAobGlieGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg5MUM2
OiBsaWJ4bF9ldmVudF93YWl0IChsaWJ4bF9ldmVudC5jOjE0NjUpCj09MzA1MjQ9PSAgICBi
eSAweDExQTE0RDogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjE3ODYpCj09MzA1MjQ9
PSAgICBieSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMw
NTI0PT0gICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUy
ND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQg
dmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTk0RUVFQTogdmZwcmludGYgKHZmcHJpbnRm
LmM6MTYzNCkKPT0zMDUyND09ICAgIGJ5IDB4NUEwREYwQTogX192YXNwcmludGZfY2hrICh2
YXNwcmludGZfY2hrLmM6NjYpCj09MzA1MjQ9PSAgICBieSAweDUwN0FENjE6IGxpYnhsX19s
b2d2IChzdGRpbzIuaDoyMTApCj09MzA1MjQ9PSAgICBieSAweDUwN0FGMUI6IGxpYnhsX19s
b2cgKGxpYnhsX2ludGVybmFsLmM6MjA5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDU4QkExOiBk
b21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwuYzoxMDAyKQo9PTMwNTI0PT0g
ICAgYnkgMHg1MDg3NjM3OiB3YXRjaGZkX2NhbGxiYWNrIChsaWJ4bF9ldmVudC5jOjUwNCkK
PT0zMDUyND09ICAgIGJ5IDB4NTA4N0VDNTogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4bF9l
dmVudC5jOjk5NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4ODIwODogZXZlbnRsb29wX2l0ZXJh
dGlvbiAobGlieGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg5MUM2OiBs
aWJ4bF9ldmVudF93YWl0IChsaWJ4bF9ldmVudC5jOjE0NjUpCj09MzA1MjQ9PSAgICBieSAw
eDExQTE0RDogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjE3ODYpCj09MzA1MjQ9PSAg
ICBieSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0
PT0gICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUyND09
IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFs
dWUocykKPT0zMDUyND09ICAgIGF0IDB4NTk0RUY2RDogdmZwcmludGYgKHZmcHJpbnRmLmM6
MTYzNCkKPT0zMDUyND09ICAgIGJ5IDB4NUEwREYwQTogX192YXNwcmludGZfY2hrICh2YXNw
cmludGZfY2hrLmM6NjYpCj09MzA1MjQ9PSAgICBieSAweDUwN0FENjE6IGxpYnhsX19sb2d2
IChzdGRpbzIuaDoyMTApCj09MzA1MjQ9PSAgICBieSAweDUwN0FGMUI6IGxpYnhsX19sb2cg
KGxpYnhsX2ludGVybmFsLmM6MjA5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDU4QkExOiBkb21h
aW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwuYzoxMDAyKQo9PTMwNTI0PT0gICAg
YnkgMHg1MDg3NjM3OiB3YXRjaGZkX2NhbGxiYWNrIChsaWJ4bF9ldmVudC5jOjUwNCkKPT0z
MDUyND09ICAgIGJ5IDB4NTA4N0VDNTogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4bF9ldmVu
dC5jOjk5NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4ODIwODogZXZlbnRsb29wX2l0ZXJhdGlv
biAobGlieGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg5MUM2OiBsaWJ4
bF9ldmVudF93YWl0IChsaWJ4bF9ldmVudC5jOjE0NjUpCj09MzA1MjQ9PSAgICBieSAweDEx
QTE0RDogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjE3ODYpCj09MzA1MjQ9PSAgICBi
eSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0g
ICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUyND09IENv
bmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUo
cykKPT0zMDUyND09ICAgIGF0IDB4NTA1OEJGOTogZG9tYWluX2RlYXRoX3hzd2F0Y2hfY2Fs
bGJhY2sgKGxpYnhsLmM6MTAxMikKPT0zMDUyND09ICAgIGJ5IDB4NTA4NzYzNzogd2F0Y2hm
ZF9jYWxsYmFjayAobGlieGxfZXZlbnQuYzo1MDQpCj09MzA1MjQ9PSAgICBieSAweDUwODdF
QzU6IGFmdGVycG9sbF9pbnRlcm5hbCAobGlieGxfZXZlbnQuYzo5OTUpCj09MzA1MjQ9PSAg
ICBieSAweDUwODgyMDg6IGV2ZW50bG9vcF9pdGVyYXRpb24gKGxpYnhsX2V2ZW50LmM6MTQ0
MCkKPT0zMDUyND09ICAgIGJ5IDB4NTA4OTFDNjogbGlieGxfZXZlbnRfd2FpdCAobGlieGxf
ZXZlbnQuYzoxNDY1KQo9PTMwNTI0PT0gICAgYnkgMHgxMUExNEQ6IGNyZWF0ZV9kb21haW4g
KHhsX2NtZGltcGwuYzoxNzg2KQo9PTMwNTI0PT0gICAgYnkgMHgxMURCMzE6IG1haW5fY3Jl
YXRlICh4bF9jbWRpbXBsLmM6NDIxMSkKPT0zMDUyND09ICAgIGJ5IDB4MTEyMkU2OiBtYWlu
ICh4bC5jOjM1NikKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25kaXRpb25hbCBqdW1wIG9yIG1v
dmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09MzA1MjQ9PSAgICBhdCAw
eDUwNThDNUU6IGRvbWFpbl9kZWF0aF94c3dhdGNoX2NhbGxiYWNrIChsaWJ4bC5jOjEwMTcp
Cj09MzA1MjQ9PSAgICBieSAweDUwODc2Mzc6IHdhdGNoZmRfY2FsbGJhY2sgKGxpYnhsX2V2
ZW50LmM6NTA0KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg3RUM1OiBhZnRlcnBvbGxfaW50ZXJu
YWwgKGxpYnhsX2V2ZW50LmM6OTk1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg4MjA4OiBldmVu
dGxvb3BfaXRlcmF0aW9uIChsaWJ4bF9ldmVudC5jOjE0NDApCj09MzA1MjQ9PSAgICBieSAw
eDUwODkxQzY6IGxpYnhsX2V2ZW50X3dhaXQgKGxpYnhsX2V2ZW50LmM6MTQ2NSkKPT0zMDUy
ND09ICAgIGJ5IDB4MTFBMTREOiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MTc4NikK
PT0zMDUyND09ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1wbC5jOjQy
MTEpCj09MzA1MjQ9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09MzA1MjQ9
PQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0
aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDU4QzdCOiBkb21haW5fZGVh
dGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwuYzoxMDIyKQo9PTMwNTI0PT0gICAgYnkgMHg1
MDg3NjM3OiB3YXRjaGZkX2NhbGxiYWNrIChsaWJ4bF9ldmVudC5jOjUwNCkKPT0zMDUyND09
ICAgIGJ5IDB4NTA4N0VDNTogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4bF9ldmVudC5jOjk5
NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4ODIwODogZXZlbnRsb29wX2l0ZXJhdGlvbiAobGli
eGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg5MUM2OiBsaWJ4bF9ldmVu
dF93YWl0IChsaWJ4bF9ldmVudC5jOjE0NjUpCj09MzA1MjQ9PSAgICBieSAweDExQTE0RDog
Y3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjE3ODYpCj09MzA1MjQ9PSAgICBieSAweDEx
REIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0gICAgYnkg
MHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDYzNT09IENvbmRpdGlv
bmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT0z
MDYzNT09ICAgIGF0IDB4NTA3MkU1MTogbGlieGxfX2RvbWFpbl90eXBlIChsaWJ4bF9kb20u
YzozNCkKPT0zMDYzNT09ICAgIGJ5IDB4NTA1NzhCQzogbGlieGxfX3ByaW1hcnlfY29uc29s
ZV9maW5kIChsaWJ4bC5jOjE1NzIpCj09MzA2MzU9PSAgICBieSAweDUwNUM1REM6IGxpYnhs
X3ByaW1hcnlfY29uc29sZV9leGVjIChsaWJ4bC5jOjE2MDMpCj09MzA2MzU9PSAgICBieSAw
eDExMzU4NDogYXV0b2Nvbm5lY3RfY29uc29sZSAoeGxfY21kaW1wbC5jOjE3NzYpCj09MzA2
MzU9PSAgICBieSAweDUwODg3RDk6IGxpYnhsX19lZ2NfY2xlYW51cCAobGlieGxfZXZlbnQu
YzoxMTYxKQo9PTMwNjM1PT0gICAgYnkgMHg1MDg5NzU2OiBsaWJ4bF9fYW9faW5wcm9ncmVz
cyAobGlieGxfZXZlbnQuYzoxNjk4KQo9PTMwNjM1PT0gICAgYnkgMHg1MDZBMzc0OiBkb19k
b21haW5fY3JlYXRlIChsaWJ4bF9jcmVhdGUuYzoxMjU2KQo9PTMwNjM1PT0gICAgYnkgMHg1
MDZBNDU5OiBsaWJ4bF9kb21haW5fY3JlYXRlX25ldyAobGlieGxfY3JlYXRlLmM6MTI3NykK
PT0zMDYzNT09ICAgIGJ5IDB4MTE5QUQ3OiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6
MjAyMCkKPT0zMDYzNT09ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1w
bC5jOjQyMTEpCj09MzA2MzU9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09
MzA2MzU9PQoK
--------------020204050108010104030202
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020204050108010104030202--


From xen-devel-bounces@lists.xen.org Tue Nov 04 17:31:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:31:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlhwY-0003UX-Ez; Tue, 04 Nov 2014 17:30:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XlhwW-0003UQ-Bn
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 17:30:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A1/65-24532-F4D09545; Tue, 04 Nov 2014 17:30:55 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415122254!12186846!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5448 invoked from network); 4 Nov 2014 17:30:54 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 17:30:54 -0000
Received: from joan.univie.ac.at ([131.130.3.110] helo=joan.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlhwT-000301-30; Tue, 04 Nov 2014 18:30:53 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.64])
	by joan.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlhwS-0004H6-9V; Tue, 04 Nov 2014 18:30:53 +0100
Message-ID: <54590D4D.90300@web2web.at>
Date: Tue, 04 Nov 2014 18:30:53 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>				<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>			<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>		
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>	
	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com>
In-Reply-To: <1415118690.11486.53.camel@citrix.com>
Content-Type: multipart/mixed; boundary="------------020204050108010104030202"
X-Univie-Virus-Scan: scanned by ClamAV on joan.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------020204050108010104030202
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Am 04.11.14 um 17:31 schrieb Ian Campbell:
> On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
>> Am 04.11.14 um 16:44 schrieb Ian Campbell:
>>> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
>>> You could try running the xl command under valgrind, you may find "xl
>>> create -F" (which keeps xl in the foreground) handy if you try this.
>>> That might help catch any heap corruption etc.
>> I don't know what valgrind is, but I'll have a look and see how to deal
>> with that ...
>
> Valgrind is a totally awesome memory allocation debugger ;-)
>
In the attached file named 'valgrind 'please find the output of
	# valgrind xl create -F -c pfsense

There's a lot of information in that file which is above my current 
level of expertise, but I am sure you are able to make sense out of it.

BTW the stuff at lines 6 and 111 to 119 is the usual output of the xl 
command before it segfaults.

Thanks Atom2

--------------020204050108010104030202
Content-Type: text/plain; charset=windows-1252;
 name="valgrind"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="valgrind"

PT0zMDUyND09IE1lbWNoZWNrLCBhIG1lbW9yeSBlcnJvciBkZXRlY3Rvcgo9PTMwNTI0PT0g
Q29weXJpZ2h0IChDKSAyMDAyLTIwMTMsIGFuZCBHTlUgR1BMJ2QsIGJ5IEp1bGlhbiBTZXdh
cmQgZXQgYWwuCj09MzA1MjQ9PSBVc2luZyBWYWxncmluZC0zLjkuMCBhbmQgTGliVkVYOyBy
ZXJ1biB3aXRoIC1oIGZvciBjb3B5cmlnaHQgaW5mbwo9PTMwNTI0PT0gQ29tbWFuZDogeGwg
Y3JlYXRlIC1GIC1jIHBmc2Vuc2UKPT0zMDUyND09ClBhcnNpbmcgY29uZmlnIGZyb20gcGZz
ZW5zZQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5p
bml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDU5RTgxOiBsaWJ4bF9s
aXN0X2RvbWFpbiAobGlieGwuYzo1NjApCj09MzA1MjQ9PSAgICBieSAweDUwN0JGNTA6IGxp
YnhsX25hbWVfdG9fZG9taWQgKGxpYnhsX3V0aWxzLmM6NzMpCj09MzA1MjQ9PSAgICBieSAw
eDUwNTkzNjQ6IGxpYnhsX19kb21haW5fcmVuYW1lIChsaWJ4bC5jOjMxMikKPT0zMDUyND09
ICAgIGJ5IDB4NTA2OTE2MTogbGlieGxfX2RvbWFpbl9tYWtlIChsaWJ4bF9jcmVhdGUuYzo0
NzEpCj09MzA1MjQ9PSAgICBieSAweDUwNjlGNTc6IGRvX2RvbWFpbl9jcmVhdGUgKGxpYnhs
X2NyZWF0ZS5jOjY0MykKPT0zMDUyND09ICAgIGJ5IDB4NTA2QTQ1OTogbGlieGxfZG9tYWlu
X2NyZWF0ZV9uZXcgKGxpYnhsX2NyZWF0ZS5jOjEyNzcpCj09MzA1MjQ9PSAgICBieSAweDEx
OUFENzogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjIwMjApCj09MzA1MjQ9PSAgICBi
eSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0g
ICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUyND09IENv
bmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUo
cykKPT0zMDUyND09ICAgIGF0IDB4NTA1OUU4NTogbGlieGxfbGlzdF9kb21haW4gKGxpYnhs
LmM6NTY2KQo9PTMwNTI0PT0gICAgYnkgMHg1MDdCRjUwOiBsaWJ4bF9uYW1lX3RvX2RvbWlk
IChsaWJ4bF91dGlscy5jOjczKQo9PTMwNTI0PT0gICAgYnkgMHg1MDU5MzY0OiBsaWJ4bF9f
ZG9tYWluX3JlbmFtZSAobGlieGwuYzozMTIpCj09MzA1MjQ9PSAgICBieSAweDUwNjkxNjE6
IGxpYnhsX19kb21haW5fbWFrZSAobGlieGxfY3JlYXRlLmM6NDcxKQo9PTMwNTI0PT0gICAg
YnkgMHg1MDY5RjU3OiBkb19kb21haW5fY3JlYXRlIChsaWJ4bF9jcmVhdGUuYzo2NDMpCj09
MzA1MjQ9PSAgICBieSAweDUwNkE0NTk6IGxpYnhsX2RvbWFpbl9jcmVhdGVfbmV3IChsaWJ4
bF9jcmVhdGUuYzoxMjc3KQo9PTMwNTI0PT0gICAgYnkgMHgxMTlBRDc6IGNyZWF0ZV9kb21h
aW4gKHhsX2NtZGltcGwuYzoyMDIwKQo9PTMwNTI0PT0gICAgYnkgMHgxMURCMzE6IG1haW5f
Y3JlYXRlICh4bF9jbWRpbXBsLmM6NDIxMSkKPT0zMDUyND09ICAgIGJ5IDB4MTEyMkU2OiBt
YWluICh4bC5jOjM1NikKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25kaXRpb25hbCBqdW1wIG9y
IG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09MzA1MjQ9PSAgICBh
dCAweDUwNTlGMDc6IGxpYnhsX2xpc3RfZG9tYWluIChsaWJ4bC5jOjU2NikKPT0zMDUyND09
ICAgIGJ5IDB4NTA3QkY1MDogbGlieGxfbmFtZV90b19kb21pZCAobGlieGxfdXRpbHMuYzo3
MykKPT0zMDUyND09ICAgIGJ5IDB4NTA1OTM2NDogbGlieGxfX2RvbWFpbl9yZW5hbWUgKGxp
YnhsLmM6MzEyKQo9PTMwNTI0PT0gICAgYnkgMHg1MDY5MTYxOiBsaWJ4bF9fZG9tYWluX21h
a2UgKGxpYnhsX2NyZWF0ZS5jOjQ3MSkKPT0zMDUyND09ICAgIGJ5IDB4NTA2OUY1NzogZG9f
ZG9tYWluX2NyZWF0ZSAobGlieGxfY3JlYXRlLmM6NjQzKQo9PTMwNTI0PT0gICAgYnkgMHg1
MDZBNDU5OiBsaWJ4bF9kb21haW5fY3JlYXRlX25ldyAobGlieGxfY3JlYXRlLmM6MTI3NykK
PT0zMDUyND09ICAgIGJ5IDB4MTE5QUQ3OiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6
MjAyMCkKPT0zMDUyND09ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1w
bC5jOjQyMTEpCj09MzA1MjQ9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09
MzA1MjQ9PQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24g
dW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDdCRjYyOiBsaWJ4
bF9uYW1lX3RvX2RvbWlkIChsaWJ4bF91dGlscy5jOjc3KQo9PTMwNTI0PT0gICAgYnkgMHg1
MDU5MzY0OiBsaWJ4bF9fZG9tYWluX3JlbmFtZSAobGlieGwuYzozMTIpCj09MzA1MjQ9PSAg
ICBieSAweDUwNjkxNjE6IGxpYnhsX19kb21haW5fbWFrZSAobGlieGxfY3JlYXRlLmM6NDcx
KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY5RjU3OiBkb19kb21haW5fY3JlYXRlIChsaWJ4bF9j
cmVhdGUuYzo2NDMpCj09MzA1MjQ9PSAgICBieSAweDUwNkE0NTk6IGxpYnhsX2RvbWFpbl9j
cmVhdGVfbmV3IChsaWJ4bF9jcmVhdGUuYzoxMjc3KQo9PTMwNTI0PT0gICAgYnkgMHgxMTlB
RDc6IGNyZWF0ZV9kb21haW4gKHhsX2NtZGltcGwuYzoyMDIwKQo9PTMwNTI0PT0gICAgYnkg
MHgxMURCMzE6IG1haW5fY3JlYXRlICh4bF9jbWRpbXBsLmM6NDIxMSkKPT0zMDUyND09ICAg
IGJ5IDB4MTEyMkU2OiBtYWluICh4bC5jOjM1NikKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25k
aXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMp
Cj09MzA1MjQ9PSAgICBhdCAweDUwN0JGQzM6IGxpYnhsX25hbWVfdG9fZG9taWQgKGxpYnhs
X3V0aWxzLmM6NzcpCj09MzA1MjQ9PSAgICBieSAweDUwNTkzNjQ6IGxpYnhsX19kb21haW5f
cmVuYW1lIChsaWJ4bC5jOjMxMikKPT0zMDUyND09ICAgIGJ5IDB4NTA2OTE2MTogbGlieGxf
X2RvbWFpbl9tYWtlIChsaWJ4bF9jcmVhdGUuYzo0NzEpCj09MzA1MjQ9PSAgICBieSAweDUw
NjlGNTc6IGRvX2RvbWFpbl9jcmVhdGUgKGxpYnhsX2NyZWF0ZS5jOjY0MykKPT0zMDUyND09
ICAgIGJ5IDB4NTA2QTQ1OTogbGlieGxfZG9tYWluX2NyZWF0ZV9uZXcgKGxpYnhsX2NyZWF0
ZS5jOjEyNzcpCj09MzA1MjQ9PSAgICBieSAweDExOUFENzogY3JlYXRlX2RvbWFpbiAoeGxf
Y21kaW1wbC5jOjIwMjApCj09MzA1MjQ9PSAgICBieSAweDExREIzMTogbWFpbl9jcmVhdGUg
KHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0gICAgYnkgMHgxMTIyRTY6IG1haW4gKHhs
LmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBk
ZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTA1
QTI5QjogbGlieGxfbGlzdF92bSAobGlieGwuYzo2ODQpCj09MzA1MjQ9PSAgICBieSAweDUw
NjkzNDc6IGxpYnhsX19kb21haW5fbWFrZSAobGlieGxfY3JlYXRlLmM6NTA2KQo9PTMwNTI0
PT0gICAgYnkgMHg1MDY5RjU3OiBkb19kb21haW5fY3JlYXRlIChsaWJ4bF9jcmVhdGUuYzo2
NDMpCj09MzA1MjQ9PSAgICBieSAweDUwNkE0NTk6IGxpYnhsX2RvbWFpbl9jcmVhdGVfbmV3
IChsaWJ4bF9jcmVhdGUuYzoxMjc3KQo9PTMwNTI0PT0gICAgYnkgMHgxMTlBRDc6IGNyZWF0
ZV9kb21haW4gKHhsX2NtZGltcGwuYzoyMDIwKQo9PTMwNTI0PT0gICAgYnkgMHgxMURCMzE6
IG1haW5fY3JlYXRlICh4bF9jbWRpbXBsLmM6NDIxMSkKPT0zMDUyND09ICAgIGJ5IDB4MTEy
MkU2OiBtYWluICh4bC5jOjM1NikKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25kaXRpb25hbCBq
dW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09MzA1MjQ9
PSAgICBhdCAweDUwNUEyOUY6IGxpYnhsX2xpc3Rfdm0gKGxpYnhsLmM6Njg4KQo9PTMwNTI0
PT0gICAgYnkgMHg1MDY5MzQ3OiBsaWJ4bF9fZG9tYWluX21ha2UgKGxpYnhsX2NyZWF0ZS5j
OjUwNikKPT0zMDUyND09ICAgIGJ5IDB4NTA2OUY1NzogZG9fZG9tYWluX2NyZWF0ZSAobGli
eGxfY3JlYXRlLmM6NjQzKQo9PTMwNTI0PT0gICAgYnkgMHg1MDZBNDU5OiBsaWJ4bF9kb21h
aW5fY3JlYXRlX25ldyAobGlieGxfY3JlYXRlLmM6MTI3NykKPT0zMDUyND09ICAgIGJ5IDB4
MTE5QUQ3OiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MjAyMCkKPT0zMDUyND09ICAg
IGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1wbC5jOjQyMTEpCj09MzA1MjQ9
PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09MzA1MjQ9PQo9PTMwNTI0PT0g
Q29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1
ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDVBMzRGOiBsaWJ4bF9saXN0X3ZtIChsaWJ4bC5j
OjY4OCkKPT0zMDUyND09ICAgIGJ5IDB4NTA2OTM0NzogbGlieGxfX2RvbWFpbl9tYWtlIChs
aWJ4bF9jcmVhdGUuYzo1MDYpCj09MzA1MjQ9PSAgICBieSAweDUwNjlGNTc6IGRvX2RvbWFp
bl9jcmVhdGUgKGxpYnhsX2NyZWF0ZS5jOjY0MykKPT0zMDUyND09ICAgIGJ5IDB4NTA2QTQ1
OTogbGlieGxfZG9tYWluX2NyZWF0ZV9uZXcgKGxpYnhsX2NyZWF0ZS5jOjEyNzcpCj09MzA1
MjQ9PSAgICBieSAweDExOUFENzogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjIwMjAp
Cj09MzA1MjQ9PSAgICBieSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0
MjExKQo9PTMwNTI0PT0gICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0
PT0KPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5p
dGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTA3MkZBMTogbGlieGxfX2Rv
bWFpbl9jcHVwb29sIChsaWJ4bF9kb20uYzo2NykKPT0zMDUyND09ICAgIGJ5IDB4NTA3MzA5
RTogbGlieGxfX2RvbWFpbl9zY2hlZHVsZXIgKGxpYnhsX2RvbS5jOjgyKQo9PTMwNTI0PT0g
ICAgYnkgMHg1MDZBMDFGOiBkb19kb21haW5fY3JlYXRlIChsaWJ4bF9jcmVhdGUuYzo1MykK
PT0zMDUyND09ICAgIGJ5IDB4NTA2QTQ1OTogbGlieGxfZG9tYWluX2NyZWF0ZV9uZXcgKGxp
YnhsX2NyZWF0ZS5jOjEyNzcpCj09MzA1MjQ9PSAgICBieSAweDExOUFENzogY3JlYXRlX2Rv
bWFpbiAoeGxfY21kaW1wbC5jOjIwMjApCj09MzA1MjQ9PSAgICBieSAweDExREIzMTogbWFp
bl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0gICAgYnkgMHgxMTIyRTY6
IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAg
b3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAg
IGF0IDB4NTA3MkU1MTogbGlieGxfX2RvbWFpbl90eXBlIChsaWJ4bF9kb20uYzozNCkKPT0z
MDUyND09ICAgIGJ5IDB4NTA1RjIwRDogbGlieGxfX2RldmljZV9uaWNfc2V0ZGVmYXVsdCAo
bGlieGwuYzoyODI3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDZBMTk5OiBkb19kb21haW5fY3Jl
YXRlIChsaWJ4bF9jcmVhdGUuYzo2ODQpCj09MzA1MjQ9PSAgICBieSAweDUwNkE0NTk6IGxp
YnhsX2RvbWFpbl9jcmVhdGVfbmV3IChsaWJ4bF9jcmVhdGUuYzoxMjc3KQo9PTMwNTI0PT0g
ICAgYnkgMHgxMTlBRDc6IGNyZWF0ZV9kb21haW4gKHhsX2NtZGltcGwuYzoyMDIwKQo9PTMw
NTI0PT0gICAgYnkgMHgxMURCMzE6IG1haW5fY3JlYXRlICh4bF9jbWRpbXBsLmM6NDIxMSkK
PT0zMDUyND09ICAgIGJ5IDB4MTEyMkU2OiBtYWluICh4bC5jOjM1NikKPT0zMDUyND09Ci0t
MzA1MjQtLSBXQVJOSU5HOiB1bmhhbmRsZWQgX19IWVBFUlZJU09SX2RvbWN0bCBzdWJvcDog
MTAKLS0zMDUyNC0tIFlvdSBtYXkgYmUgYWJsZSB0byB3cml0ZSB5b3VyIG93biBoYW5kbGVy
LgotLTMwNTI0LS0gUmVhZCB0aGUgZmlsZSBSRUFETUVfTUlTU0lOR19TWVNDQUxMX09SX0lP
Q1RMLgotLTMwNTI0LS0gTmV2ZXJ0aGVsZXNzIHdlIGNvbnNpZGVyIHRoaXMgYSBidWcuICBQ
bGVhc2UgcmVwb3J0Ci0tMzA1MjQtLSBpdCBhdCBodHRwOi8vdmFsZ3JpbmQub3JnL3N1cHBv
cnQvYnVnX3JlcG9ydHMuaHRtbCAmCi0tMzA1MjQtLSBodHRwOi8vd2lraS54ZW4ub3JnL3dp
a2kvUmVwb3J0aW5nX0J1Z3NfYWdhaW5zdF9YZW4uCnhjOiBpbmZvOiBWSVJUVUFMIE1FTU9S
WSBBUlJBTkdFTUVOVDoKICBMb2FkZXI6ICAgICAgICAwMDAwMDAwMDAwMTAwMDAwLT4wMDAw
MDAwMDAwMWMxMmE0CiAgTW9kdWxlczogICAgICAgMDAwMDAwMDAwMDAwMDAwMC0+MDAwMDAw
MDAwMDAwMDAwMAogIFRPVEFMOiAgICAgICAgIDAwMDAwMDAwMDAwMDAwMDAtPjAwMDAwMDAw
MWY4MDAwMDAKICBFTlRSWSBBRERSRVNTOiAwMDAwMDAwMDAwMTAwMDAwCnhjOiBpbmZvOiBQ
SFlTSUNBTCBNRU1PUlkgQUxMT0NBVElPTjoKICA0S0IgUEFHRVM6IDB4MDAwMDAwMDAwMDAw
MDIwMAogIDJNQiBQQUdFUzogMHgwMDAwMDAwMDAwMDAwMGZiCiAgMUdCIFBBR0VTOiAweDAw
MDAwMDAwMDAwMDAwMDAKLS0zMDUyNC0tIFdBUk5JTkc6IHVuaGFuZGxlZCBfX0hZUEVSVklT
T1JfbWVtb3J5X29wIHN1Ym9wOiA3Ci0tMzA1MjQtLSBZb3UgbWF5IGJlIGFibGUgdG8gd3Jp
dGUgeW91ciBvd24gaGFuZGxlci4KLS0zMDUyNC0tIFJlYWQgdGhlIGZpbGUgUkVBRE1FX01J
U1NJTkdfU1lTQ0FMTF9PUl9JT0NUTC4KLS0zMDUyNC0tIE5ldmVydGhlbGVzcyB3ZSBjb25z
aWRlciB0aGlzIGEgYnVnLiAgUGxlYXNlIHJlcG9ydAotLTMwNTI0LS0gaXQgYXQgaHR0cDov
L3ZhbGdyaW5kLm9yZy9zdXBwb3J0L2J1Z19yZXBvcnRzLmh0bWwgJgotLTMwNTI0LS0gaHR0
cDovL3dpa2kueGVuLm9yZy93aWtpL1JlcG9ydGluZ19CdWdzX2FnYWluc3RfWGVuLgp4Yzog
ZXJyb3I6IHBhbmljOiB4Y19kb21fYm9vdC5jOjM4ODogeGNfZG9tX2dudHRhYl9odm1fc2Vl
ZDogZmFpbGVkIHRvIGFkZCBnbnR0YWIgdG8gcGh5c21hcCBbZXJybm89MzhdCjogSW50ZXJu
YWwgZXJyb3IKPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9u
IHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTA3MkZBMTogbGli
eGxfX2RvbWFpbl9jcHVwb29sIChsaWJ4bF9kb20uYzo2NykKPT0zMDUyND09ICAgIGJ5IDB4
NTA3MzA5RTogbGlieGxfX2RvbWFpbl9zY2hlZHVsZXIgKGxpYnhsX2RvbS5jOjgyKQo9PTMw
NTI0PT0gICAgYnkgMHg1MDY1NDZBOiBsaWJ4bF9kb21haW5fc2NoZWRfcGFyYW1zX3NldCAo
bGlieGwuYzo0NTk3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDczNUNFOiBsaWJ4bF9fYnVpbGRf
cG9zdCAobGlieGxfZG9tLmM6MjY3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY4RDczOiBsaWJ4
bF9fZG9tYWluX2J1aWxkIChsaWJ4bF9jcmVhdGUuYzozNzUpCj09MzA1MjQ9PSAgICBieSAw
eDUwNjlDNzA6IGRvbWNyZWF0ZV9ib290bG9hZGVyX2RvbmUgKGxpYnhsX2NyZWF0ZS5jOjc3
MCkKPT0zMDUyND09ICAgIGJ5IDB4NTA4QUQ0RjogYm9vdGxvYWRlcl9sb2NhbF9kZXRhY2hl
ZF9jYiAobGlieGxfYm9vdGxvYWRlci5jOjI4MSkKPT0zMDUyND09ICAgIGJ5IDB4NTA1ODNE
RDogbG9jYWxfZGV2aWNlX2RldGFjaF9jYiAobGlieGwuYzoyNzc3KQo9PTMwNTI0PT0gICAg
YnkgMHg1MDVFQjA1OiBsaWJ4bF9fZGV2aWNlX2Rpc2tfbG9jYWxfaW5pdGlhdGVfZGV0YWNo
IChsaWJ4bC5jOjI3NTIpCj09MzA1MjQ9PSAgICBieSAweDUwOEI1QTQ6IGJvb3Rsb2FkZXJf
Y2FsbGJhY2sgKGxpYnhsX2Jvb3Rsb2FkZXIuYzoyNjUpCj09MzA1MjQ9PSAgICBieSAweDUw
OEM1QzA6IGxpYnhsX19ib290bG9hZGVyX3J1biAobGlieGxfYm9vdGxvYWRlci5jOjM5MikK
PT0zMDUyND09ICAgIGJ5IDB4NTA2QTJFQjogZG9fZG9tYWluX2NyZWF0ZSAobGlieGxfY3Jl
YXRlLmM6NzA5KQo9PTMwNTI0PT0KPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92
ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4
NTA2NTYzRTogbGlieGxfZG9tYWluX3NjaGVkX3BhcmFtc19zZXQgKGxpYnhsLmM6NDM3MCkK
PT0zMDUyND09ICAgIGJ5IDB4NTA3MzVDRTogbGlieGxfX2J1aWxkX3Bvc3QgKGxpYnhsX2Rv
bS5jOjI2NykKPT0zMDUyND09ICAgIGJ5IDB4NTA2OEQ3MzogbGlieGxfX2RvbWFpbl9idWls
ZCAobGlieGxfY3JlYXRlLmM6Mzc1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY5QzcwOiBkb21j
cmVhdGVfYm9vdGxvYWRlcl9kb25lIChsaWJ4bF9jcmVhdGUuYzo3NzApCj09MzA1MjQ9PSAg
ICBieSAweDUwOEFENEY6IGJvb3Rsb2FkZXJfbG9jYWxfZGV0YWNoZWRfY2IgKGxpYnhsX2Jv
b3Rsb2FkZXIuYzoyODEpCj09MzA1MjQ9PSAgICBieSAweDUwNTgzREQ6IGxvY2FsX2Rldmlj
ZV9kZXRhY2hfY2IgKGxpYnhsLmM6Mjc3NykKPT0zMDUyND09ICAgIGJ5IDB4NTA1RUIwNTog
bGlieGxfX2RldmljZV9kaXNrX2xvY2FsX2luaXRpYXRlX2RldGFjaCAobGlieGwuYzoyNzUy
KQo9PTMwNTI0PT0gICAgYnkgMHg1MDhCNUE0OiBib290bG9hZGVyX2NhbGxiYWNrIChsaWJ4
bF9ib290bG9hZGVyLmM6MjY1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDhDNUMwOiBsaWJ4bF9f
Ym9vdGxvYWRlcl9ydW4gKGxpYnhsX2Jvb3Rsb2FkZXIuYzozOTIpCj09MzA1MjQ9PSAgICBi
eSAweDUwNkEyRUI6IGRvX2RvbWFpbl9jcmVhdGUgKGxpYnhsX2NyZWF0ZS5jOjcwOSkKPT0z
MDUyND09ICAgIGJ5IDB4NTA2QTQ1OTogbGlieGxfZG9tYWluX2NyZWF0ZV9uZXcgKGxpYnhs
X2NyZWF0ZS5jOjEyNzcpCj09MzA1MjQ9PSAgICBieSAweDExOUFENzogY3JlYXRlX2RvbWFp
biAoeGxfY21kaW1wbC5jOjIwMjApCj09MzA1MjQ9PQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwg
anVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0
PT0gICAgYXQgMHg1MDY1NjkwOiBsaWJ4bF9kb21haW5fc2NoZWRfcGFyYW1zX3NldCAobGli
eGwuYzo0Mzc0KQo9PTMwNTI0PT0gICAgYnkgMHg1MDczNUNFOiBsaWJ4bF9fYnVpbGRfcG9z
dCAobGlieGxfZG9tLmM6MjY3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY4RDczOiBsaWJ4bF9f
ZG9tYWluX2J1aWxkIChsaWJ4bF9jcmVhdGUuYzozNzUpCj09MzA1MjQ9PSAgICBieSAweDUw
NjlDNzA6IGRvbWNyZWF0ZV9ib290bG9hZGVyX2RvbmUgKGxpYnhsX2NyZWF0ZS5jOjc3MCkK
PT0zMDUyND09ICAgIGJ5IDB4NTA4QUQ0RjogYm9vdGxvYWRlcl9sb2NhbF9kZXRhY2hlZF9j
YiAobGlieGxfYm9vdGxvYWRlci5jOjI4MSkKPT0zMDUyND09ICAgIGJ5IDB4NTA1ODNERDog
bG9jYWxfZGV2aWNlX2RldGFjaF9jYiAobGlieGwuYzoyNzc3KQo9PTMwNTI0PT0gICAgYnkg
MHg1MDVFQjA1OiBsaWJ4bF9fZGV2aWNlX2Rpc2tfbG9jYWxfaW5pdGlhdGVfZGV0YWNoIChs
aWJ4bC5jOjI3NTIpCj09MzA1MjQ9PSAgICBieSAweDUwOEI1QTQ6IGJvb3Rsb2FkZXJfY2Fs
bGJhY2sgKGxpYnhsX2Jvb3Rsb2FkZXIuYzoyNjUpCj09MzA1MjQ9PSAgICBieSAweDUwOEM1
QzA6IGxpYnhsX19ib290bG9hZGVyX3J1biAobGlieGxfYm9vdGxvYWRlci5jOjM5MikKPT0z
MDUyND09ICAgIGJ5IDB4NTA2QTJFQjogZG9fZG9tYWluX2NyZWF0ZSAobGlieGxfY3JlYXRl
LmM6NzA5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDZBNDU5OiBsaWJ4bF9kb21haW5fY3JlYXRl
X25ldyAobGlieGxfY3JlYXRlLmM6MTI3NykKPT0zMDUyND09ICAgIGJ5IDB4MTE5QUQ3OiBj
cmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MjAyMCkKPT0zMDUyND09Cj09MzA1MjQ9PSBD
b25kaXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVl
KHMpCj09MzA1MjQ9PSAgICBhdCAweDUwNzJFNTE6IGxpYnhsX19kb21haW5fdHlwZSAobGli
eGxfZG9tLmM6MzQpCj09MzA1MjQ9PSAgICBieSAweDUwNUQ2REE6IGRldmljZV9kaXNrX2Fk
ZCAobGlieGwuYzoyMDYxKQo9PTMwNTI0PT0gICAgYnkgMHg1MDVERTY1OiBsaWJ4bF9fZGV2
aWNlX2Rpc2tfYWRkIChsaWJ4bC5jOjIyMjkpCj09MzA1MjQ9PSAgICBieSAweDUwNzk3MjM6
IGxpYnhsX19hZGRfZGlza3MgKGxpYnhsX2RldmljZS5jOjU0OSkKPT0zMDUyND09ICAgIGJ5
IDB4NTA2NzcxQzogZG9tY3JlYXRlX3JlYnVpbGRfZG9uZSAobGlieGxfY3JlYXRlLmM6OTMz
KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY5QzdFOiBkb21jcmVhdGVfYm9vdGxvYWRlcl9kb25l
IChsaWJ4bF9jcmVhdGUuYzo3NzEpCj09MzA1MjQ9PSAgICBieSAweDUwOEFENEY6IGJvb3Rs
b2FkZXJfbG9jYWxfZGV0YWNoZWRfY2IgKGxpYnhsX2Jvb3Rsb2FkZXIuYzoyODEpCj09MzA1
MjQ9PSAgICBieSAweDUwNTgzREQ6IGxvY2FsX2RldmljZV9kZXRhY2hfY2IgKGxpYnhsLmM6
Mjc3NykKPT0zMDUyND09ICAgIGJ5IDB4NTA1RUIwNTogbGlieGxfX2RldmljZV9kaXNrX2xv
Y2FsX2luaXRpYXRlX2RldGFjaCAobGlieGwuYzoyNzUyKQo9PTMwNTI0PT0gICAgYnkgMHg1
MDhCNUE0OiBib290bG9hZGVyX2NhbGxiYWNrIChsaWJ4bF9ib290bG9hZGVyLmM6MjY1KQo9
PTMwNTI0PT0gICAgYnkgMHg1MDhDNUMwOiBsaWJ4bF9fYm9vdGxvYWRlcl9ydW4gKGxpYnhs
X2Jvb3Rsb2FkZXIuYzozOTIpCj09MzA1MjQ9PSAgICBieSAweDUwNkEyRUI6IGRvX2RvbWFp
bl9jcmVhdGUgKGxpYnhsX2NyZWF0ZS5jOjcwOSkKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25k
aXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMp
Cj09MzA1MjQ9PSAgICBhdCAweDUwNTlGOEE6IGxpYnhsX2RvbWFpbl9pbmZvIChsaWJ4bC5j
OjU3OSkKPT0zMDUyND09ICAgIGJ5IDB4NTA3OUZCQTogbGlieGxfX3dhaXRfZGV2aWNlX2Nv
bm5lY3Rpb24gKGxpYnhsX2RldmljZS5jOjcyMykKPT0zMDUyND09ICAgIGJ5IDB4NTA1RERC
ODogZGV2aWNlX2Rpc2tfYWRkIChsaWJ4bC5jOjIyMTUpCj09MzA1MjQ9PSAgICBieSAweDUw
NURFNjU6IGxpYnhsX19kZXZpY2VfZGlza19hZGQgKGxpYnhsLmM6MjIyOSkKPT0zMDUyND09
ICAgIGJ5IDB4NTA3OTcyMzogbGlieGxfX2FkZF9kaXNrcyAobGlieGxfZGV2aWNlLmM6NTQ5
KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY3NzFDOiBkb21jcmVhdGVfcmVidWlsZF9kb25lIChs
aWJ4bF9jcmVhdGUuYzo5MzMpCj09MzA1MjQ9PSAgICBieSAweDUwNjlDN0U6IGRvbWNyZWF0
ZV9ib290bG9hZGVyX2RvbmUgKGxpYnhsX2NyZWF0ZS5jOjc3MSkKPT0zMDUyND09ICAgIGJ5
IDB4NTA4QUQ0RjogYm9vdGxvYWRlcl9sb2NhbF9kZXRhY2hlZF9jYiAobGlieGxfYm9vdGxv
YWRlci5jOjI4MSkKPT0zMDUyND09ICAgIGJ5IDB4NTA1ODNERDogbG9jYWxfZGV2aWNlX2Rl
dGFjaF9jYiAobGlieGwuYzoyNzc3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDVFQjA1OiBsaWJ4
bF9fZGV2aWNlX2Rpc2tfbG9jYWxfaW5pdGlhdGVfZGV0YWNoIChsaWJ4bC5jOjI3NTIpCj09
MzA1MjQ9PSAgICBieSAweDUwOEI1QTQ6IGJvb3Rsb2FkZXJfY2FsbGJhY2sgKGxpYnhsX2Jv
b3Rsb2FkZXIuYzoyNjUpCj09MzA1MjQ9PSAgICBieSAweDUwOEM1QzA6IGxpYnhsX19ib290
bG9hZGVyX3J1biAobGlieGxfYm9vdGxvYWRlci5jOjM5MikKPT0zMDUyND09Cj09MzA1MjQ9
PSBDb25kaXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZh
bHVlKHMpCj09MzA1MjQ9PSAgICBhdCAweDUwNTlGQ0Q6IGxpYnhsX2RvbWFpbl9pbmZvIChs
aWJ4bC5jOjU4MykKPT0zMDUyND09ICAgIGJ5IDB4NTA3OUZCQTogbGlieGxfX3dhaXRfZGV2
aWNlX2Nvbm5lY3Rpb24gKGxpYnhsX2RldmljZS5jOjcyMykKPT0zMDUyND09ICAgIGJ5IDB4
NTA1RERCODogZGV2aWNlX2Rpc2tfYWRkIChsaWJ4bC5jOjIyMTUpCj09MzA1MjQ9PSAgICBi
eSAweDUwNURFNjU6IGxpYnhsX19kZXZpY2VfZGlza19hZGQgKGxpYnhsLmM6MjIyOSkKPT0z
MDUyND09ICAgIGJ5IDB4NTA3OTcyMzogbGlieGxfX2FkZF9kaXNrcyAobGlieGxfZGV2aWNl
LmM6NTQ5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDY3NzFDOiBkb21jcmVhdGVfcmVidWlsZF9k
b25lIChsaWJ4bF9jcmVhdGUuYzo5MzMpCj09MzA1MjQ9PSAgICBieSAweDUwNjlDN0U6IGRv
bWNyZWF0ZV9ib290bG9hZGVyX2RvbmUgKGxpYnhsX2NyZWF0ZS5jOjc3MSkKPT0zMDUyND09
ICAgIGJ5IDB4NTA4QUQ0RjogYm9vdGxvYWRlcl9sb2NhbF9kZXRhY2hlZF9jYiAobGlieGxf
Ym9vdGxvYWRlci5jOjI4MSkKPT0zMDUyND09ICAgIGJ5IDB4NTA1ODNERDogbG9jYWxfZGV2
aWNlX2RldGFjaF9jYiAobGlieGwuYzoyNzc3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDVFQjA1
OiBsaWJ4bF9fZGV2aWNlX2Rpc2tfbG9jYWxfaW5pdGlhdGVfZGV0YWNoIChsaWJ4bC5jOjI3
NTIpCj09MzA1MjQ9PSAgICBieSAweDUwOEI1QTQ6IGJvb3Rsb2FkZXJfY2FsbGJhY2sgKGxp
YnhsX2Jvb3Rsb2FkZXIuYzoyNjUpCj09MzA1MjQ9PSAgICBieSAweDUwOEM1QzA6IGxpYnhs
X19ib290bG9hZGVyX3J1biAobGlieGxfYm9vdGxvYWRlci5jOjM5MikKPT0zMDUyND09Cj09
MzA1MjQ9PSBDb25kaXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxp
c2VkIHZhbHVlKHMpCj09MzA1MjQ9PSAgICBhdCAweDUwNzJFNTE6IGxpYnhsX19kb21haW5f
dHlwZSAobGlieGxfZG9tLmM6MzQpCj09MzA1MjQ9PSAgICBieSAweDUwNUYyMEQ6IGxpYnhs
X19kZXZpY2VfbmljX3NldGRlZmF1bHQgKGxpYnhsLmM6MjgyNykKPT0zMDUyND09ICAgIGJ5
IDB4NTA1RjMzRDogbGlieGxfX2RldmljZV9uaWNfYWRkIChsaWJ4bC5jOjI4NzEpCj09MzA1
MjQ9PSAgICBieSAweDUwNzk3Q0I6IGxpYnhsX19hZGRfbmljcyAobGlieGxfZGV2aWNlLmM6
NTUwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDY3QjNFOiBkb21jcmVhdGVfZGV2bW9kZWxfc3Rh
cnRlZCAobGlieGxfY3JlYXRlLmM6MTEwNCkKPT0zMDUyND09ICAgIGJ5IDB4NTA2QTk2Rjog
ZGV2aWNlX21vZGVsX3NwYXduX291dGNvbWUgKGxpYnhsX2RtLmM6MTI5NSkKPT0zMDUyND09
ICAgIGJ5IDB4NTA2QTlDNDogZGV2aWNlX21vZGVsX2RldGFjaGVkIChsaWJ4bF9kbS5jOjEy
NjkpCj09MzA1MjQ9PSAgICBieSAweDUwNzZCMjE6IHNwYXduX21pZGRsZV9kZWF0aCAobGli
eGxfZXhlYy5jOjQ2NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4QTEzOTogY2hpbGRwcm9jX3Jl
YXBlZCAobGlieGxfZm9yay5jOjI2NikKPT0zMDUyND09ICAgIGJ5IDB4NTA4QTU0MjogbGli
eGxfX2Zvcmtfc2VsZnBpcGVfd29rZW4gKGxpYnhsX2ZvcmsuYzozMDIpCj09MzA1MjQ9PSAg
ICBieSAweDUwODdGOEI6IGFmdGVycG9sbF9pbnRlcm5hbCAobGlieGxfZXZlbnQuYzoxMDA4
KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg4MjA4OiBldmVudGxvb3BfaXRlcmF0aW9uIChsaWJ4
bF9ldmVudC5jOjE0NDApCj09MzA1MjQ9PQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBv
ciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAg
YXQgMHg1MDU5RjhBOiBsaWJ4bF9kb21haW5faW5mbyAobGlieGwuYzo1NzkpCj09MzA1MjQ9
PSAgICBieSAweDUwNzlGQkE6IGxpYnhsX193YWl0X2RldmljZV9jb25uZWN0aW9uIChsaWJ4
bF9kZXZpY2UuYzo3MjMpCj09MzA1MjQ9PSAgICBieSAweDUwNUY3NDQ6IGxpYnhsX19kZXZp
Y2VfbmljX2FkZCAobGlieGwuYzoyOTQ3KQo9PTMwNTI0PT0gICAgYnkgMHg1MDc5N0NCOiBs
aWJ4bF9fYWRkX25pY3MgKGxpYnhsX2RldmljZS5jOjU1MCkKPT0zMDUyND09ICAgIGJ5IDB4
NTA2N0IzRTogZG9tY3JlYXRlX2Rldm1vZGVsX3N0YXJ0ZWQgKGxpYnhsX2NyZWF0ZS5jOjEx
MDQpCj09MzA1MjQ9PSAgICBieSAweDUwNkE5NkY6IGRldmljZV9tb2RlbF9zcGF3bl9vdXRj
b21lIChsaWJ4bF9kbS5jOjEyOTUpCj09MzA1MjQ9PSAgICBieSAweDUwNkE5QzQ6IGRldmlj
ZV9tb2RlbF9kZXRhY2hlZCAobGlieGxfZG0uYzoxMjY5KQo9PTMwNTI0PT0gICAgYnkgMHg1
MDc2QjIxOiBzcGF3bl9taWRkbGVfZGVhdGggKGxpYnhsX2V4ZWMuYzo0NjUpCj09MzA1MjQ9
PSAgICBieSAweDUwOEExMzk6IGNoaWxkcHJvY19yZWFwZWQgKGxpYnhsX2ZvcmsuYzoyNjYp
Cj09MzA1MjQ9PSAgICBieSAweDUwOEE1NDI6IGxpYnhsX19mb3JrX3NlbGZwaXBlX3dva2Vu
IChsaWJ4bF9mb3JrLmM6MzAyKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg3RjhCOiBhZnRlcnBv
bGxfaW50ZXJuYWwgKGxpYnhsX2V2ZW50LmM6MTAwOCkKPT0zMDUyND09ICAgIGJ5IDB4NTA4
ODIwODogZXZlbnRsb29wX2l0ZXJhdGlvbiAobGlieGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0
PT0KPT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5p
dGlhbGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTA1OUZDRDogbGlieGxfZG9t
YWluX2luZm8gKGxpYnhsLmM6NTgzKQo9PTMwNTI0PT0gICAgYnkgMHg1MDc5RkJBOiBsaWJ4
bF9fd2FpdF9kZXZpY2VfY29ubmVjdGlvbiAobGlieGxfZGV2aWNlLmM6NzIzKQo9PTMwNTI0
PT0gICAgYnkgMHg1MDVGNzQ0OiBsaWJ4bF9fZGV2aWNlX25pY19hZGQgKGxpYnhsLmM6Mjk0
NykKPT0zMDUyND09ICAgIGJ5IDB4NTA3OTdDQjogbGlieGxfX2FkZF9uaWNzIChsaWJ4bF9k
ZXZpY2UuYzo1NTApCj09MzA1MjQ9PSAgICBieSAweDUwNjdCM0U6IGRvbWNyZWF0ZV9kZXZt
b2RlbF9zdGFydGVkIChsaWJ4bF9jcmVhdGUuYzoxMTA0KQo9PTMwNTI0PT0gICAgYnkgMHg1
MDZBOTZGOiBkZXZpY2VfbW9kZWxfc3Bhd25fb3V0Y29tZSAobGlieGxfZG0uYzoxMjk1KQo9
PTMwNTI0PT0gICAgYnkgMHg1MDZBOUM0OiBkZXZpY2VfbW9kZWxfZGV0YWNoZWQgKGxpYnhs
X2RtLmM6MTI2OSkKPT0zMDUyND09ICAgIGJ5IDB4NTA3NkIyMTogc3Bhd25fbWlkZGxlX2Rl
YXRoIChsaWJ4bF9leGVjLmM6NDY1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDhBMTM5OiBjaGls
ZHByb2NfcmVhcGVkIChsaWJ4bF9mb3JrLmM6MjY2KQo9PTMwNTI0PT0gICAgYnkgMHg1MDhB
NTQyOiBsaWJ4bF9fZm9ya19zZWxmcGlwZV93b2tlbiAobGlieGxfZm9yay5jOjMwMikKPT0z
MDUyND09ICAgIGJ5IDB4NTA4N0Y4QjogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4bF9ldmVu
dC5jOjEwMDgpCj09MzA1MjQ9PSAgICBieSAweDUwODgyMDg6IGV2ZW50bG9vcF9pdGVyYXRp
b24gKGxpYnhsX2V2ZW50LmM6MTQ0MCkKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25kaXRpb25h
bCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09MzA1
MjQ9PSAgICBhdCAweDUwNzJFNTE6IGxpYnhsX19kb21haW5fdHlwZSAobGlieGxfZG9tLmM6
MzQpCj09MzA1MjQ9PSAgICBieSAweDUwNkZFQTg6IGxpYnhsX19kZXZpY2VfcGNpX2FkZCAo
bGlieGxfcGNpLmM6MTAzOCkKPT0zMDUyND09ICAgIGJ5IDB4NTA2NzgyRTogZG9tY3JlYXRl
X2F0dGFjaF9wY2kgKGxpYnhsX2NyZWF0ZS5jOjExNjgpCj09MzA1MjQ9PSAgICBieSAweDUw
NjdBMEY6IGRvbWNyZWF0ZV9hdHRhY2hfdnRwbXMgKGxpYnhsX2NyZWF0ZS5jOjExNDIpCj09
MzA1MjQ9PSAgICBieSAweDUwNzg1MzU6IG11bHRpZGV2X29uZV9jYWxsYmFjayAobGlieGxf
ZGV2aWNlLmM6NTEyKQo9PTMwNTI0PT0gICAgYnkgMHg1MDc5QTMyOiBkZXZpY2VfaG90cGx1
Z19kb25lIChsaWJ4bF9kZXZpY2UuYzoxMDU5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDc5Q0Q0
OiBkZXZpY2VfaG90cGx1ZyAobGlieGxfZGV2aWNlLmM6OTgyKQo9PTMwNTI0PT0gICAgYnkg
MHg1MDc5RTE2OiBkZXZpY2VfaG90cGx1Z19jaGlsZF9kZWF0aF9jYiAobGlieGxfZGV2aWNl
LmM6MTAzNikKPT0zMDUyND09ICAgIGJ5IDB4NTA4QTEzOTogY2hpbGRwcm9jX3JlYXBlZCAo
bGlieGxfZm9yay5jOjI2NikKPT0zMDUyND09ICAgIGJ5IDB4NTA4QTU0MjogbGlieGxfX2Zv
cmtfc2VsZnBpcGVfd29rZW4gKGxpYnhsX2ZvcmsuYzozMDIpCj09MzA1MjQ9PSAgICBieSAw
eDUwODdGOEI6IGFmdGVycG9sbF9pbnRlcm5hbCAobGlieGxfZXZlbnQuYzoxMDA4KQo9PTMw
NTI0PT0gICAgYnkgMHg1MDg4MjA4OiBldmVudGxvb3BfaXRlcmF0aW9uIChsaWJ4bF9ldmVu
dC5jOjE0NDApCj09MzA1MjQ9PQotLTMwNTI0LS0gV0FSTklORzogdW5oYW5kbGVkIF9fSFlQ
RVJWSVNPUl9kb21jdGwgc3Vib3A6IDQ1Ci0tMzA1MjQtLSBZb3UgbWF5IGJlIGFibGUgdG8g
d3JpdGUgeW91ciBvd24gaGFuZGxlci4KLS0zMDUyNC0tIFJlYWQgdGhlIGZpbGUgUkVBRE1F
X01JU1NJTkdfU1lTQ0FMTF9PUl9JT0NUTC4KLS0zMDUyNC0tIE5ldmVydGhlbGVzcyB3ZSBj
b25zaWRlciB0aGlzIGEgYnVnLiAgUGxlYXNlIHJlcG9ydAotLTMwNTI0LS0gaXQgYXQgaHR0
cDovL3ZhbGdyaW5kLm9yZy9zdXBwb3J0L2J1Z19yZXBvcnRzLmh0bWwgJgotLTMwNTI0LS0g
aHR0cDovL3dpa2kueGVuLm9yZy93aWtpL1JlcG9ydGluZ19CdWdzX2FnYWluc3RfWGVuLgps
aWJ4bDogZXJyb3I6IGxpYnhsX3BjaS5jOjEwNDU6bGlieGxfX2RldmljZV9wY2lfYWRkOiBQ
Q0kgZGV2aWNlIDAwMDA6MDQ6MDAuMCBjYW5ub3QgYmUgYXNzaWduZWQgLSBubyBJT01NVT8K
LS0zMDUyNC0tIFdBUk5JTkc6IHVuaGFuZGxlZCBfX0hZUEVSVklTT1JfZG9tY3RsIHN1Ym9w
OiA0NQotLTMwNTI0LS0gWW91IG1heSBiZSBhYmxlIHRvIHdyaXRlIHlvdXIgb3duIGhhbmRs
ZXIuCi0tMzA1MjQtLSBSZWFkIHRoZSBmaWxlIFJFQURNRV9NSVNTSU5HX1NZU0NBTExfT1Jf
SU9DVEwuCi0tMzA1MjQtLSBOZXZlcnRoZWxlc3Mgd2UgY29uc2lkZXIgdGhpcyBhIGJ1Zy4g
IFBsZWFzZSByZXBvcnQKLS0zMDUyNC0tIGl0IGF0IGh0dHA6Ly92YWxncmluZC5vcmcvc3Vw
cG9ydC9idWdfcmVwb3J0cy5odG1sICYKLS0zMDUyNC0tIGh0dHA6Ly93aWtpLnhlbi5vcmcv
d2lraS9SZXBvcnRpbmdfQnVnc19hZ2FpbnN0X1hlbi4KbGlieGw6IGVycm9yOiBsaWJ4bF9w
Y2kuYzoxMDQ1OmxpYnhsX19kZXZpY2VfcGNpX2FkZDogUENJIGRldmljZSAwMDAwOjBhOjA4
LjAgY2Fubm90IGJlIGFzc2lnbmVkIC0gbm8gSU9NTVU/Ci0tMzA1MjQtLSBXQVJOSU5HOiB1
bmhhbmRsZWQgX19IWVBFUlZJU09SX2RvbWN0bCBzdWJvcDogNDUKLS0zMDUyNC0tIFlvdSBt
YXkgYmUgYWJsZSB0byB3cml0ZSB5b3VyIG93biBoYW5kbGVyLgotLTMwNTI0LS0gUmVhZCB0
aGUgZmlsZSBSRUFETUVfTUlTU0lOR19TWVNDQUxMX09SX0lPQ1RMLgotLTMwNTI0LS0gTmV2
ZXJ0aGVsZXNzIHdlIGNvbnNpZGVyIHRoaXMgYSBidWcuICBQbGVhc2UgcmVwb3J0Ci0tMzA1
MjQtLSBpdCBhdCBodHRwOi8vdmFsZ3JpbmQub3JnL3N1cHBvcnQvYnVnX3JlcG9ydHMuaHRt
bCAmCi0tMzA1MjQtLSBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvUmVwb3J0aW5nX0J1Z3Nf
YWdhaW5zdF9YZW4uCmxpYnhsOiBlcnJvcjogbGlieGxfcGNpLmM6MTA0NTpsaWJ4bF9fZGV2
aWNlX3BjaV9hZGQ6IFBDSSBkZXZpY2UgMDAwMDowYTowYi4wIGNhbm5vdCBiZSBhc3NpZ25l
ZCAtIG5vIElPTU1VPwo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVu
ZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDU5RjhB
OiBsaWJ4bF9kb21haW5faW5mbyAobGlieGwuYzo1NzkpCj09MzA1MjQ9PSAgICBieSAweDUw
NzJDQzI6IHVzZXJkYXRhX3BhdGggKGxpYnhsX2RvbS5jOjE1MTYpCj09MzA1MjQ9PSAgICBi
eSAweDUwNzVDMDU6IGxpYnhsX3VzZXJkYXRhX3N0b3JlIChsaWJ4bF9kb20uYzoxNTc3KQo9
PTMwNTI0PT0gICAgYnkgMHgxMTlDNDQ6IGNyZWF0ZV9kb21haW4gKHhsX2NtZGltcGwuYzoy
MDUzKQo9PTMwNTI0PT0gICAgYnkgMHgxMURCMzE6IG1haW5fY3JlYXRlICh4bF9jbWRpbXBs
LmM6NDIxMSkKPT0zMDUyND09ICAgIGJ5IDB4MTEyMkU2OiBtYWluICh4bC5jOjM1NikKPT0z
MDUyND09Cj09MzA1MjQ9PSBDb25kaXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1
bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09MzA1MjQ9PSAgICBhdCAweDUwNTlGQ0Q6IGxpYnhs
X2RvbWFpbl9pbmZvIChsaWJ4bC5jOjU4MykKPT0zMDUyND09ICAgIGJ5IDB4NTA3MkNDMjog
dXNlcmRhdGFfcGF0aCAobGlieGxfZG9tLmM6MTUxNikKPT0zMDUyND09ICAgIGJ5IDB4NTA3
NUMwNTogbGlieGxfdXNlcmRhdGFfc3RvcmUgKGxpYnhsX2RvbS5jOjE1NzcpCj09MzA1MjQ9
PSAgICBieSAweDExOUM0NDogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjIwNTMpCj09
MzA1MjQ9PSAgICBieSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjEx
KQo9PTMwNTI0PT0gICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0K
PT0zMDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlh
bGlzZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTA1OUY4QTogbGlieGxfZG9tYWlu
X2luZm8gKGxpYnhsLmM6NTc5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDcyQ0MyOiB1c2VyZGF0
YV9wYXRoIChsaWJ4bF9kb20uYzoxNTE2KQo9PTMwNTI0PT0gICAgYnkgMHg1MDc1QzNFOiBs
aWJ4bF91c2VyZGF0YV9zdG9yZSAobGlieGxfZG9tLmM6MTU4OCkKPT0zMDUyND09ICAgIGJ5
IDB4MTE5QzQ0OiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MjA1MykKPT0zMDUyND09
ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1wbC5jOjQyMTEpCj09MzA1
MjQ9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09MzA1MjQ9PQo9PTMwNTI0
PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2
YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDU5RkNEOiBsaWJ4bF9kb21haW5faW5mbyAo
bGlieGwuYzo1ODMpCj09MzA1MjQ9PSAgICBieSAweDUwNzJDQzI6IHVzZXJkYXRhX3BhdGgg
KGxpYnhsX2RvbS5jOjE1MTYpCj09MzA1MjQ9PSAgICBieSAweDUwNzVDM0U6IGxpYnhsX3Vz
ZXJkYXRhX3N0b3JlIChsaWJ4bF9kb20uYzoxNTg4KQo9PTMwNTI0PT0gICAgYnkgMHgxMTlD
NDQ6IGNyZWF0ZV9kb21haW4gKHhsX2NtZGltcGwuYzoyMDUzKQo9PTMwNTI0PT0gICAgYnkg
MHgxMURCMzE6IG1haW5fY3JlYXRlICh4bF9jbWRpbXBsLmM6NDIxMSkKPT0zMDUyND09ICAg
IGJ5IDB4MTEyMkU2OiBtYWluICh4bC5jOjM1NikKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25k
aXRpb25hbCBqdW1wIG9yIG1vdmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMp
Cj09MzA1MjQ9PSAgICBhdCAweDUwNzJFNTE6IGxpYnhsX19kb21haW5fdHlwZSAobGlieGxf
ZG9tLmM6MzQpCj09MzA1MjQ9PSAgICBieSAweDUwNUFDMzU6IGxpYnhsX2RvbWFpbl91bnBh
dXNlIChsaWJ4bC5jOjgzNykKPT0zMDUyND09ICAgIGJ5IDB4MTE5QzgxOiBjcmVhdGVfZG9t
YWluICh4bF9jbWRpbXBsLmM6MjA2NCkKPT0zMDUyND09ICAgIGJ5IDB4MTFEQjMxOiBtYWlu
X2NyZWF0ZSAoeGxfY21kaW1wbC5jOjQyMTEpCj09MzA1MjQ9PSAgICBieSAweDExMjJFNjog
bWFpbiAoeGwuYzozNTYpCj09MzA1MjQ9PQpXYWl0aW5nIGZvciBkb21haW4gcGZzZW5zZSAo
ZG9taWQgMTYpIHRvIGRpZSBbcGlkIDMwNTI0XQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVt
cCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0g
ICAgYXQgMHg1MDU4QjAwOiBkb21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwu
Yzo5OTQpCj09MzA1MjQ9PSAgICBieSAweDUwODc2Mzc6IHdhdGNoZmRfY2FsbGJhY2sgKGxp
YnhsX2V2ZW50LmM6NTA0KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg3RUM1OiBhZnRlcnBvbGxf
aW50ZXJuYWwgKGxpYnhsX2V2ZW50LmM6OTk1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg4MjA4
OiBldmVudGxvb3BfaXRlcmF0aW9uIChsaWJ4bF9ldmVudC5jOjE0NDApCj09MzA1MjQ9PSAg
ICBieSAweDUwODkxQzY6IGxpYnhsX2V2ZW50X3dhaXQgKGxpYnhsX2V2ZW50LmM6MTQ2NSkK
PT0zMDUyND09ICAgIGJ5IDB4MTFBMTREOiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6
MTc4NikKPT0zMDUyND09ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1w
bC5jOjQyMTEpCj09MzA1MjQ9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09
MzA1MjQ9PQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24g
dW5pbml0aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1OTRFRTEyOiB2ZnBy
aW50ZiAodmZwcmludGYuYzoxNjM0KQo9PTMwNTI0PT0gICAgYnkgMHg1QTBERjBBOiBfX3Zh
c3ByaW50Zl9jaGsgKHZhc3ByaW50Zl9jaGsuYzo2NikKPT0zMDUyND09ICAgIGJ5IDB4NTA3
QUQ2MTogbGlieGxfX2xvZ3YgKHN0ZGlvMi5oOjIxMCkKPT0zMDUyND09ICAgIGJ5IDB4NTA3
QUYxQjogbGlieGxfX2xvZyAobGlieGxfaW50ZXJuYWwuYzoyMDkpCj09MzA1MjQ9PSAgICBi
eSAweDUwNThCQTE6IGRvbWFpbl9kZWF0aF94c3dhdGNoX2NhbGxiYWNrIChsaWJ4bC5jOjEw
MDIpCj09MzA1MjQ9PSAgICBieSAweDUwODc2Mzc6IHdhdGNoZmRfY2FsbGJhY2sgKGxpYnhs
X2V2ZW50LmM6NTA0KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg3RUM1OiBhZnRlcnBvbGxfaW50
ZXJuYWwgKGxpYnhsX2V2ZW50LmM6OTk1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg4MjA4OiBl
dmVudGxvb3BfaXRlcmF0aW9uIChsaWJ4bF9ldmVudC5jOjE0NDApCj09MzA1MjQ9PSAgICBi
eSAweDUwODkxQzY6IGxpYnhsX2V2ZW50X3dhaXQgKGxpYnhsX2V2ZW50LmM6MTQ2NSkKPT0z
MDUyND09ICAgIGJ5IDB4MTFBMTREOiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MTc4
NikKPT0zMDUyND09ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1wbC5j
OjQyMTEpCj09MzA1MjQ9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09MzA1
MjQ9PQo9PTMwNTI0PT0gVXNlIG9mIHVuaW5pdGlhbGlzZWQgdmFsdWUgb2Ygc2l6ZSA4Cj09
MzA1MjQ9PSAgICBhdCAweDU5NERDQkI6IF9pdG9hX3dvcmQgKF9pdG9hLmM6MTc5KQo9PTMw
NTI0PT0gICAgYnkgMHg1OTUwRTIzOiB2ZnByaW50ZiAodmZwcmludGYuYzoxNjM0KQo9PTMw
NTI0PT0gICAgYnkgMHg1QTBERjBBOiBfX3Zhc3ByaW50Zl9jaGsgKHZhc3ByaW50Zl9jaGsu
Yzo2NikKPT0zMDUyND09ICAgIGJ5IDB4NTA3QUQ2MTogbGlieGxfX2xvZ3YgKHN0ZGlvMi5o
OjIxMCkKPT0zMDUyND09ICAgIGJ5IDB4NTA3QUYxQjogbGlieGxfX2xvZyAobGlieGxfaW50
ZXJuYWwuYzoyMDkpCj09MzA1MjQ9PSAgICBieSAweDUwNThCQTE6IGRvbWFpbl9kZWF0aF94
c3dhdGNoX2NhbGxiYWNrIChsaWJ4bC5jOjEwMDIpCj09MzA1MjQ9PSAgICBieSAweDUwODc2
Mzc6IHdhdGNoZmRfY2FsbGJhY2sgKGxpYnhsX2V2ZW50LmM6NTA0KQo9PTMwNTI0PT0gICAg
YnkgMHg1MDg3RUM1OiBhZnRlcnBvbGxfaW50ZXJuYWwgKGxpYnhsX2V2ZW50LmM6OTk1KQo9
PTMwNTI0PT0gICAgYnkgMHg1MDg4MjA4OiBldmVudGxvb3BfaXRlcmF0aW9uIChsaWJ4bF9l
dmVudC5jOjE0NDApCj09MzA1MjQ9PSAgICBieSAweDUwODkxQzY6IGxpYnhsX2V2ZW50X3dh
aXQgKGxpYnhsX2V2ZW50LmM6MTQ2NSkKPT0zMDUyND09ICAgIGJ5IDB4MTFBMTREOiBjcmVh
dGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MTc4NikKPT0zMDUyND09ICAgIGJ5IDB4MTFEQjMx
OiBtYWluX2NyZWF0ZSAoeGxfY21kaW1wbC5jOjQyMTEpCj09MzA1MjQ9PQo9PTMwNTI0PT0g
Q29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1
ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1OTREQ0M1OiBfaXRvYV93b3JkIChfaXRvYS5jOjE3
OSkKPT0zMDUyND09ICAgIGJ5IDB4NTk1MEUyMzogdmZwcmludGYgKHZmcHJpbnRmLmM6MTYz
NCkKPT0zMDUyND09ICAgIGJ5IDB4NUEwREYwQTogX192YXNwcmludGZfY2hrICh2YXNwcmlu
dGZfY2hrLmM6NjYpCj09MzA1MjQ9PSAgICBieSAweDUwN0FENjE6IGxpYnhsX19sb2d2IChz
dGRpbzIuaDoyMTApCj09MzA1MjQ9PSAgICBieSAweDUwN0FGMUI6IGxpYnhsX19sb2cgKGxp
YnhsX2ludGVybmFsLmM6MjA5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDU4QkExOiBkb21haW5f
ZGVhdGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwuYzoxMDAyKQo9PTMwNTI0PT0gICAgYnkg
MHg1MDg3NjM3OiB3YXRjaGZkX2NhbGxiYWNrIChsaWJ4bF9ldmVudC5jOjUwNCkKPT0zMDUy
ND09ICAgIGJ5IDB4NTA4N0VDNTogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4bF9ldmVudC5j
Ojk5NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4ODIwODogZXZlbnRsb29wX2l0ZXJhdGlvbiAo
bGlieGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg5MUM2OiBsaWJ4bF9l
dmVudF93YWl0IChsaWJ4bF9ldmVudC5jOjE0NjUpCj09MzA1MjQ9PSAgICBieSAweDExQTE0
RDogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjE3ODYpCj09MzA1MjQ9PSAgICBieSAw
eDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0KPT0z
MDUyND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlz
ZWQgdmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTk1MEU3MzogdmZwcmludGYgKHZmcHJp
bnRmLmM6MTYzNCkKPT0zMDUyND09ICAgIGJ5IDB4NUEwREYwQTogX192YXNwcmludGZfY2hr
ICh2YXNwcmludGZfY2hrLmM6NjYpCj09MzA1MjQ9PSAgICBieSAweDUwN0FENjE6IGxpYnhs
X19sb2d2IChzdGRpbzIuaDoyMTApCj09MzA1MjQ9PSAgICBieSAweDUwN0FGMUI6IGxpYnhs
X19sb2cgKGxpYnhsX2ludGVybmFsLmM6MjA5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDU4QkEx
OiBkb21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwuYzoxMDAyKQo9PTMwNTI0
PT0gICAgYnkgMHg1MDg3NjM3OiB3YXRjaGZkX2NhbGxiYWNrIChsaWJ4bF9ldmVudC5jOjUw
NCkKPT0zMDUyND09ICAgIGJ5IDB4NTA4N0VDNTogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4
bF9ldmVudC5jOjk5NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4ODIwODogZXZlbnRsb29wX2l0
ZXJhdGlvbiAobGlieGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg5MUM2
OiBsaWJ4bF9ldmVudF93YWl0IChsaWJ4bF9ldmVudC5jOjE0NjUpCj09MzA1MjQ9PSAgICBi
eSAweDExQTE0RDogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjE3ODYpCj09MzA1MjQ9
PSAgICBieSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMw
NTI0PT0gICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUy
ND09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQg
dmFsdWUocykKPT0zMDUyND09ICAgIGF0IDB4NTk0RUVFQTogdmZwcmludGYgKHZmcHJpbnRm
LmM6MTYzNCkKPT0zMDUyND09ICAgIGJ5IDB4NUEwREYwQTogX192YXNwcmludGZfY2hrICh2
YXNwcmludGZfY2hrLmM6NjYpCj09MzA1MjQ9PSAgICBieSAweDUwN0FENjE6IGxpYnhsX19s
b2d2IChzdGRpbzIuaDoyMTApCj09MzA1MjQ9PSAgICBieSAweDUwN0FGMUI6IGxpYnhsX19s
b2cgKGxpYnhsX2ludGVybmFsLmM6MjA5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDU4QkExOiBk
b21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwuYzoxMDAyKQo9PTMwNTI0PT0g
ICAgYnkgMHg1MDg3NjM3OiB3YXRjaGZkX2NhbGxiYWNrIChsaWJ4bF9ldmVudC5jOjUwNCkK
PT0zMDUyND09ICAgIGJ5IDB4NTA4N0VDNTogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4bF9l
dmVudC5jOjk5NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4ODIwODogZXZlbnRsb29wX2l0ZXJh
dGlvbiAobGlieGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg5MUM2OiBs
aWJ4bF9ldmVudF93YWl0IChsaWJ4bF9ldmVudC5jOjE0NjUpCj09MzA1MjQ9PSAgICBieSAw
eDExQTE0RDogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjE3ODYpCj09MzA1MjQ9PSAg
ICBieSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0
PT0gICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUyND09
IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFs
dWUocykKPT0zMDUyND09ICAgIGF0IDB4NTk0RUY2RDogdmZwcmludGYgKHZmcHJpbnRmLmM6
MTYzNCkKPT0zMDUyND09ICAgIGJ5IDB4NUEwREYwQTogX192YXNwcmludGZfY2hrICh2YXNw
cmludGZfY2hrLmM6NjYpCj09MzA1MjQ9PSAgICBieSAweDUwN0FENjE6IGxpYnhsX19sb2d2
IChzdGRpbzIuaDoyMTApCj09MzA1MjQ9PSAgICBieSAweDUwN0FGMUI6IGxpYnhsX19sb2cg
KGxpYnhsX2ludGVybmFsLmM6MjA5KQo9PTMwNTI0PT0gICAgYnkgMHg1MDU4QkExOiBkb21h
aW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwuYzoxMDAyKQo9PTMwNTI0PT0gICAg
YnkgMHg1MDg3NjM3OiB3YXRjaGZkX2NhbGxiYWNrIChsaWJ4bF9ldmVudC5jOjUwNCkKPT0z
MDUyND09ICAgIGJ5IDB4NTA4N0VDNTogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4bF9ldmVu
dC5jOjk5NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4ODIwODogZXZlbnRsb29wX2l0ZXJhdGlv
biAobGlieGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg5MUM2OiBsaWJ4
bF9ldmVudF93YWl0IChsaWJ4bF9ldmVudC5jOjE0NjUpCj09MzA1MjQ9PSAgICBieSAweDEx
QTE0RDogY3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjE3ODYpCj09MzA1MjQ9PSAgICBi
eSAweDExREIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0g
ICAgYnkgMHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDUyND09IENv
bmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUo
cykKPT0zMDUyND09ICAgIGF0IDB4NTA1OEJGOTogZG9tYWluX2RlYXRoX3hzd2F0Y2hfY2Fs
bGJhY2sgKGxpYnhsLmM6MTAxMikKPT0zMDUyND09ICAgIGJ5IDB4NTA4NzYzNzogd2F0Y2hm
ZF9jYWxsYmFjayAobGlieGxfZXZlbnQuYzo1MDQpCj09MzA1MjQ9PSAgICBieSAweDUwODdF
QzU6IGFmdGVycG9sbF9pbnRlcm5hbCAobGlieGxfZXZlbnQuYzo5OTUpCj09MzA1MjQ9PSAg
ICBieSAweDUwODgyMDg6IGV2ZW50bG9vcF9pdGVyYXRpb24gKGxpYnhsX2V2ZW50LmM6MTQ0
MCkKPT0zMDUyND09ICAgIGJ5IDB4NTA4OTFDNjogbGlieGxfZXZlbnRfd2FpdCAobGlieGxf
ZXZlbnQuYzoxNDY1KQo9PTMwNTI0PT0gICAgYnkgMHgxMUExNEQ6IGNyZWF0ZV9kb21haW4g
KHhsX2NtZGltcGwuYzoxNzg2KQo9PTMwNTI0PT0gICAgYnkgMHgxMURCMzE6IG1haW5fY3Jl
YXRlICh4bF9jbWRpbXBsLmM6NDIxMSkKPT0zMDUyND09ICAgIGJ5IDB4MTEyMkU2OiBtYWlu
ICh4bC5jOjM1NikKPT0zMDUyND09Cj09MzA1MjQ9PSBDb25kaXRpb25hbCBqdW1wIG9yIG1v
dmUgZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09MzA1MjQ9PSAgICBhdCAw
eDUwNThDNUU6IGRvbWFpbl9kZWF0aF94c3dhdGNoX2NhbGxiYWNrIChsaWJ4bC5jOjEwMTcp
Cj09MzA1MjQ9PSAgICBieSAweDUwODc2Mzc6IHdhdGNoZmRfY2FsbGJhY2sgKGxpYnhsX2V2
ZW50LmM6NTA0KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg3RUM1OiBhZnRlcnBvbGxfaW50ZXJu
YWwgKGxpYnhsX2V2ZW50LmM6OTk1KQo9PTMwNTI0PT0gICAgYnkgMHg1MDg4MjA4OiBldmVu
dGxvb3BfaXRlcmF0aW9uIChsaWJ4bF9ldmVudC5jOjE0NDApCj09MzA1MjQ9PSAgICBieSAw
eDUwODkxQzY6IGxpYnhsX2V2ZW50X3dhaXQgKGxpYnhsX2V2ZW50LmM6MTQ2NSkKPT0zMDUy
ND09ICAgIGJ5IDB4MTFBMTREOiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6MTc4NikK
PT0zMDUyND09ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1wbC5jOjQy
MTEpCj09MzA1MjQ9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09MzA1MjQ9
PQo9PTMwNTI0PT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRlcGVuZHMgb24gdW5pbml0
aWFsaXNlZCB2YWx1ZShzKQo9PTMwNTI0PT0gICAgYXQgMHg1MDU4QzdCOiBkb21haW5fZGVh
dGhfeHN3YXRjaF9jYWxsYmFjayAobGlieGwuYzoxMDIyKQo9PTMwNTI0PT0gICAgYnkgMHg1
MDg3NjM3OiB3YXRjaGZkX2NhbGxiYWNrIChsaWJ4bF9ldmVudC5jOjUwNCkKPT0zMDUyND09
ICAgIGJ5IDB4NTA4N0VDNTogYWZ0ZXJwb2xsX2ludGVybmFsIChsaWJ4bF9ldmVudC5jOjk5
NSkKPT0zMDUyND09ICAgIGJ5IDB4NTA4ODIwODogZXZlbnRsb29wX2l0ZXJhdGlvbiAobGli
eGxfZXZlbnQuYzoxNDQwKQo9PTMwNTI0PT0gICAgYnkgMHg1MDg5MUM2OiBsaWJ4bF9ldmVu
dF93YWl0IChsaWJ4bF9ldmVudC5jOjE0NjUpCj09MzA1MjQ9PSAgICBieSAweDExQTE0RDog
Y3JlYXRlX2RvbWFpbiAoeGxfY21kaW1wbC5jOjE3ODYpCj09MzA1MjQ9PSAgICBieSAweDEx
REIzMTogbWFpbl9jcmVhdGUgKHhsX2NtZGltcGwuYzo0MjExKQo9PTMwNTI0PT0gICAgYnkg
MHgxMTIyRTY6IG1haW4gKHhsLmM6MzU2KQo9PTMwNTI0PT0KPT0zMDYzNT09IENvbmRpdGlv
bmFsIGp1bXAgb3IgbW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT0z
MDYzNT09ICAgIGF0IDB4NTA3MkU1MTogbGlieGxfX2RvbWFpbl90eXBlIChsaWJ4bF9kb20u
YzozNCkKPT0zMDYzNT09ICAgIGJ5IDB4NTA1NzhCQzogbGlieGxfX3ByaW1hcnlfY29uc29s
ZV9maW5kIChsaWJ4bC5jOjE1NzIpCj09MzA2MzU9PSAgICBieSAweDUwNUM1REM6IGxpYnhs
X3ByaW1hcnlfY29uc29sZV9leGVjIChsaWJ4bC5jOjE2MDMpCj09MzA2MzU9PSAgICBieSAw
eDExMzU4NDogYXV0b2Nvbm5lY3RfY29uc29sZSAoeGxfY21kaW1wbC5jOjE3NzYpCj09MzA2
MzU9PSAgICBieSAweDUwODg3RDk6IGxpYnhsX19lZ2NfY2xlYW51cCAobGlieGxfZXZlbnQu
YzoxMTYxKQo9PTMwNjM1PT0gICAgYnkgMHg1MDg5NzU2OiBsaWJ4bF9fYW9faW5wcm9ncmVz
cyAobGlieGxfZXZlbnQuYzoxNjk4KQo9PTMwNjM1PT0gICAgYnkgMHg1MDZBMzc0OiBkb19k
b21haW5fY3JlYXRlIChsaWJ4bF9jcmVhdGUuYzoxMjU2KQo9PTMwNjM1PT0gICAgYnkgMHg1
MDZBNDU5OiBsaWJ4bF9kb21haW5fY3JlYXRlX25ldyAobGlieGxfY3JlYXRlLmM6MTI3NykK
PT0zMDYzNT09ICAgIGJ5IDB4MTE5QUQ3OiBjcmVhdGVfZG9tYWluICh4bF9jbWRpbXBsLmM6
MjAyMCkKPT0zMDYzNT09ICAgIGJ5IDB4MTFEQjMxOiBtYWluX2NyZWF0ZSAoeGxfY21kaW1w
bC5jOjQyMTEpCj09MzA2MzU9PSAgICBieSAweDExMjJFNjogbWFpbiAoeGwuYzozNTYpCj09
MzA2MzU9PQoK
--------------020204050108010104030202
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020204050108010104030202--


From xen-devel-bounces@lists.xen.org Tue Nov 04 17:32:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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 1XlhyC-0003hS-5u; Tue, 04 Nov 2014 17:32:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlhyB-0003gQ-Fx
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 17:32:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	24/97-24532-6BD09545; Tue, 04 Nov 2014 17:32:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415122357!4727884!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11225 invoked from network); 4 Nov 2014 17:32:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 17:32:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4HWV8q027722
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 17:32:32 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HWUH8011183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 17:32:31 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HWUNO011104; Tue, 4 Nov 2014 17:32:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 09:32:29 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CDE051106F9; Tue,  4 Nov 2014 12:32:28 -0500 (EST)
Date: Tue, 4 Nov 2014 12:32:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141104173228.GM4510@laptop.dumpdata.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 11:52:47AM +0000, Ian Campbell wrote:
> This was disabled by default in Xen 4.4. Since xend has now been removed from
> the tree I don't believe anything is using it.

What about XenServer?

And isn't there some blktap3 ?

> 
> We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xen-traditional otherwise
> it defaults to y and doesn't build.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> I think this has probably missed the boat for 4.5 and there isn't much harm in
> waiting for 4.6. I'm open to being told otherwise though ;-)

You really want to be at the top of the commit list with the most deleted
code, eh?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:32:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 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 1XlhyC-0003hS-5u; Tue, 04 Nov 2014 17:32:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlhyB-0003gQ-Fx
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 17:32:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	24/97-24532-6BD09545; Tue, 04 Nov 2014 17:32:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415122357!4727884!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11225 invoked from network); 4 Nov 2014 17:32:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 17:32:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4HWV8q027722
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 17:32:32 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HWUH8011183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 17:32:31 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4HWUNO011104; Tue, 4 Nov 2014 17:32:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 09:32:29 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CDE051106F9; Tue,  4 Nov 2014 12:32:28 -0500 (EST)
Date: Tue, 4 Nov 2014 12:32:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141104173228.GM4510@laptop.dumpdata.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 11:52:47AM +0000, Ian Campbell wrote:
> This was disabled by default in Xen 4.4. Since xend has now been removed from
> the tree I don't believe anything is using it.

What about XenServer?

And isn't there some blktap3 ?

> 
> We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xen-traditional otherwise
> it defaults to y and doesn't build.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> I think this has probably missed the boat for 4.5 and there isn't much harm in
> waiting for 4.6. I'm open to being told otherwise though ;-)

You really want to be at the top of the commit list with the most deleted
code, eh?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:37:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xli2V-0003z7-8Q; Tue, 04 Nov 2014 17:37: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@citrix.com>) id 1Xli2T-0003yt-Gf
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 17:37:05 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	7C/DC-31453-0CE09545; Tue, 04 Nov 2014 17:37:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415122621!7828447!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28950 invoked from network); 4 Nov 2014 17:37:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 17:37:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="188012467"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 12:36:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xli2I-0003Wu-Fx;
	Tue, 04 Nov 2014 17:36:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xli2I-0001Uq-55;
	Tue, 04 Nov 2014 17:36:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 4 Nov 2014 17:36:51 +0000
Message-ID: <1415122612-5714-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415122612-5714-1-git-send-email-ian.jackson@eu.citrix.com>
References: <21593.3655.232310.365186@mariner.uk.xensource.com>
	<1415122612-5714-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian.Campbell@citrix.com,
	JBeulich@suse.com
Subject: [Xen-devel] [OSSTEST PATCH 2/2] osstest-confirm-booted: Log
	processes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Run a ps if osstest-confirm-booted does not exist, and stash the
output where we read it during log capture.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |    7 ++++---
 ts-logs-capture        |    2 ++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index ef2a853..b348a7e 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -914,9 +914,10 @@ sub host_reboot ($) {
     poll_loop(40,2, 'reboot-confirm-booted', sub {
         my $output;
         if (!eval {
-            $output= target_cmd_output($ho,
-                "stat /dev/shm/osstest-confirm-booted 2>&1 >/dev/null ||:",
-                                       40);
+            $output= target_cmd_output($ho, <<END, 40);
+stat /dev/shm/osstest-confirm-booted 2>&1 >/dev/null \\
+ || ps -efH >osstest-confirm-booted.log
+END
             1;
         }) {
             return $@;
diff --git a/ts-logs-capture b/ts-logs-capture
index 3ccfc00..21974a9 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -130,6 +130,8 @@ sub fetch_logs_host_guests () {
 
                   /etc/xen/*
 
+                  /home/osstest/osstest-confirm-booted.log
+
                   )];
     if (!try_fetch_logs($ho, $logs)) {
         logm("log fetching failed, trying hard host reboot...");
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:37:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xli2T-0003yz-SO; Tue, 04 Nov 2014 17:37: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@citrix.com>) id 1Xli2S-0003yo-RY
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 17:37:04 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	FC/11-22777-0CE09545; Tue, 04 Nov 2014 17:37:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415122621!7828447!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28909 invoked from network); 4 Nov 2014 17:37:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 17:37:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="188012464"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 12:36:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xli2I-0003Wr-5e;
	Tue, 04 Nov 2014 17:36:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xli2H-0001Um-QG;
	Tue, 04 Nov 2014 17:36:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 4 Nov 2014 17:36:50 +0000
Message-ID: <1415122612-5714-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <21593.3655.232310.365186@mariner.uk.xensource.com>
References: <21593.3655.232310.365186@mariner.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian.Campbell@citrix.com,
	JBeulich@suse.com
Subject: [Xen-devel] [OSSTEST PATCH 1/2] poll_loop: Restore diversion of logm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

poll_loop is supposed to divert the logging away so that you don't
have to see a pile of repetitive logging if the operation succeeds.

But this was broken when the code was moved from the perl module
Osstest to Osstest::TestSupport.  Fix it.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 1d77933..ef2a853 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -611,7 +611,7 @@ sub poll_loop ($$$&) {
         $logmtmpfile= IO::File::new_tmpfile or die $!;
 
         if (!eval {
-            local ($Osstest::logm_handle) = ($logmtmpfile);
+            local ($Osstest::TestSupport::logm_handle) = ($logmtmpfile);
             $bad= $code->();
             1;
         }) {
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:37:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xli2V-0003z7-8Q; Tue, 04 Nov 2014 17:37: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@citrix.com>) id 1Xli2T-0003yt-Gf
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 17:37:05 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	7C/DC-31453-0CE09545; Tue, 04 Nov 2014 17:37:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415122621!7828447!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28950 invoked from network); 4 Nov 2014 17:37:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 17:37:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="188012467"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 12:36:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xli2I-0003Wu-Fx;
	Tue, 04 Nov 2014 17:36:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xli2I-0001Uq-55;
	Tue, 04 Nov 2014 17:36:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 4 Nov 2014 17:36:51 +0000
Message-ID: <1415122612-5714-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415122612-5714-1-git-send-email-ian.jackson@eu.citrix.com>
References: <21593.3655.232310.365186@mariner.uk.xensource.com>
	<1415122612-5714-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian.Campbell@citrix.com,
	JBeulich@suse.com
Subject: [Xen-devel] [OSSTEST PATCH 2/2] osstest-confirm-booted: Log
	processes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Run a ps if osstest-confirm-booted does not exist, and stash the
output where we read it during log capture.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |    7 ++++---
 ts-logs-capture        |    2 ++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index ef2a853..b348a7e 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -914,9 +914,10 @@ sub host_reboot ($) {
     poll_loop(40,2, 'reboot-confirm-booted', sub {
         my $output;
         if (!eval {
-            $output= target_cmd_output($ho,
-                "stat /dev/shm/osstest-confirm-booted 2>&1 >/dev/null ||:",
-                                       40);
+            $output= target_cmd_output($ho, <<END, 40);
+stat /dev/shm/osstest-confirm-booted 2>&1 >/dev/null \\
+ || ps -efH >osstest-confirm-booted.log
+END
             1;
         }) {
             return $@;
diff --git a/ts-logs-capture b/ts-logs-capture
index 3ccfc00..21974a9 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -130,6 +130,8 @@ sub fetch_logs_host_guests () {
 
                   /etc/xen/*
 
+                  /home/osstest/osstest-confirm-booted.log
+
                   )];
     if (!try_fetch_logs($ho, $logs)) {
         logm("log fetching failed, trying hard host reboot...");
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:37:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xli2T-0003yz-SO; Tue, 04 Nov 2014 17:37: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@citrix.com>) id 1Xli2S-0003yo-RY
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 17:37:04 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	FC/11-22777-0CE09545; Tue, 04 Nov 2014 17:37:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415122621!7828447!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28909 invoked from network); 4 Nov 2014 17:37:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 17:37:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="188012464"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 12:36:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xli2I-0003Wr-5e;
	Tue, 04 Nov 2014 17:36:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xli2H-0001Um-QG;
	Tue, 04 Nov 2014 17:36:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 4 Nov 2014 17:36:50 +0000
Message-ID: <1415122612-5714-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <21593.3655.232310.365186@mariner.uk.xensource.com>
References: <21593.3655.232310.365186@mariner.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian.Campbell@citrix.com,
	JBeulich@suse.com
Subject: [Xen-devel] [OSSTEST PATCH 1/2] poll_loop: Restore diversion of logm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

poll_loop is supposed to divert the logging away so that you don't
have to see a pile of repetitive logging if the operation succeeds.

But this was broken when the code was moved from the perl module
Osstest to Osstest::TestSupport.  Fix it.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 1d77933..ef2a853 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -611,7 +611,7 @@ sub poll_loop ($$$&) {
         $logmtmpfile= IO::File::new_tmpfile or die $!;
 
         if (!eval {
-            local ($Osstest::logm_handle) = ($logmtmpfile);
+            local ($Osstest::TestSupport::logm_handle) = ($logmtmpfile);
             $bad= $code->();
             1;
         }) {
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:53:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XliI0-0004eV-22; Tue, 04 Nov 2014 17:53:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XliHz-0004eQ-G0
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 17:53:07 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	15/F3-17694-28219545; Tue, 04 Nov 2014 17:53:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415123584!11617601!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6030 invoked from network); 4 Nov 2014 17:53:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 17:53:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,314,1413244800"; d="scan'208";a="189391247"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 12:35:04 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xli0V-0003Uz-Rr;
	Tue, 04 Nov 2014 17:35:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xli0V-0001Sj-Fp;
	Tue, 04 Nov 2014 17:35:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21593.3655.232310.365186@mariner.uk.xensource.com>
Date: Tue, 4 Nov 2014 17:35:03 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415010873.9994.14.camel@citrix.com>
References: <osstest-31315-mainreport@xen.org>
	<5457641C02000078000444BA@mail.emea.novell.com>
	<1415010873.9994.14.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-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] 31315: regressions - FAIL"):
> It's a shame /etc/init.d/osstest-confirm-booted isn't more verbose on
> the console, since this is what appears to have failed (i.e. the ssh bit
> seems to have worked, so I don't think it was networking/dns/etc).

I have some patches to fix this, which I will send in just a 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 Nov 04 17:53:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XliI0-0004eV-22; Tue, 04 Nov 2014 17:53:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XliHz-0004eQ-G0
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 17:53:07 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	15/F3-17694-28219545; Tue, 04 Nov 2014 17:53:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415123584!11617601!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6030 invoked from network); 4 Nov 2014 17:53:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 17:53:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,314,1413244800"; d="scan'208";a="189391247"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 4 Nov 2014 12:35:04 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xli0V-0003Uz-Rr;
	Tue, 04 Nov 2014 17:35:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xli0V-0001Sj-Fp;
	Tue, 04 Nov 2014 17:35:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21593.3655.232310.365186@mariner.uk.xensource.com>
Date: Tue, 4 Nov 2014 17:35:03 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415010873.9994.14.camel@citrix.com>
References: <osstest-31315-mainreport@xen.org>
	<5457641C02000078000444BA@mail.emea.novell.com>
	<1415010873.9994.14.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-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] 31315: regressions - FAIL"):
> It's a shame /etc/init.d/osstest-confirm-booted isn't more verbose on
> the console, since this is what appears to have failed (i.e. the ssh bit
> seems to have worked, so I don't think it was networking/dns/etc).

I have some patches to fix this, which I will send in just a 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 Nov 04 17:54:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:54:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XliJD-0004kW-Ms; Tue, 04 Nov 2014 17:54:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XliJC-0004kL-Ee
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 17:54:22 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	14/7A-11581-DC219545; Tue, 04 Nov 2014 17:54:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415123657!11231543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12907 invoked from network); 4 Nov 2014 17:54:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 17:54:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,314,1413244800"; d="scan'208";a="189391736"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 12:36:43 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xli27-0007Ps-0F;
	Tue, 04 Nov 2014 17:36:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xli26-0003mh-OS;
	Tue, 04 Nov 2014 17:36:42 +0000
Date: Tue, 4 Nov 2014 17:36:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31355-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31355: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31355 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31355/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              3 host-install(3)         broken REGR. vs. 30594
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 31335 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3)   broken pass in 31335
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3)   broken pass in 31335
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot       fail in 31335 pass in 31310
 test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail in 31335 pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31335
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31310
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31335

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-i386-i386-libvirt        1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-i386-i386-xl             1 build-check(1)               blocked  n/a
 test-i386-i386-pv             1 build-check(1)               blocked  n/a
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-pv            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-freebsd10-amd64  1 build-check(1)            blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-qemuu-freebsd10-i386  1 build-check(1)             blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xend-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-i386-i386-xl-winxpsp3    1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-i386-i386-pair           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail in 31335 never pass
 test-i386-i386-libvirt        9 guest-start           fail in 31335 never pass
 test-amd64-i386-libvirt       9 guest-start           fail in 31335 never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check fail in 31335 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31335 never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check     fail in 31335 never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 31335 never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 31335 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31335 never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop            fail in 31335 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 31335 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31335 never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail in 31335 never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop        fail in 31335 never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31335 never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop        fail in 31310 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             broken  
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       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-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-qemuu-freebsd10-amd64                        blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         broken  
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-qemuu-freebsd10-i386                         blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-i386-i386-libvirt                                       blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-i386-pvops host-install(3)
broken-step test-amd64-amd64-xl-qemuu-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemut-win7-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 17:54:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 17:54:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XliJD-0004kW-Ms; Tue, 04 Nov 2014 17:54:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XliJC-0004kL-Ee
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 17:54:22 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	14/7A-11581-DC219545; Tue, 04 Nov 2014 17:54:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415123657!11231543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12907 invoked from network); 4 Nov 2014 17:54:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 17:54:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,314,1413244800"; d="scan'208";a="189391736"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 12:36:43 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xli27-0007Ps-0F;
	Tue, 04 Nov 2014 17:36:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xli26-0003mh-OS;
	Tue, 04 Nov 2014 17:36:42 +0000
Date: Tue, 4 Nov 2014 17:36:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31355-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31355: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31355 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31355/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              3 host-install(3)         broken REGR. vs. 30594
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 31335 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3)   broken pass in 31335
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3)   broken pass in 31335
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot       fail in 31335 pass in 31310
 test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail in 31335 pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31335
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31310
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31335

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-i386-i386-libvirt        1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-i386-i386-xl             1 build-check(1)               blocked  n/a
 test-i386-i386-pv             1 build-check(1)               blocked  n/a
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-pv            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-freebsd10-amd64  1 build-check(1)            blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-qemuu-freebsd10-i386  1 build-check(1)             blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xend-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-i386-i386-xl-winxpsp3    1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-i386-i386-pair           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail in 31335 never pass
 test-i386-i386-libvirt        9 guest-start           fail in 31335 never pass
 test-amd64-i386-libvirt       9 guest-start           fail in 31335 never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check fail in 31335 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31335 never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check     fail in 31335 never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 31335 never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 31335 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31335 never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop            fail in 31335 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 31335 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31335 never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail in 31335 never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop        fail in 31335 never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31335 never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop        fail in 31310 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             broken  
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       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-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-qemuu-freebsd10-amd64                        blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         broken  
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-qemuu-freebsd10-i386                         blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-i386-i386-libvirt                                       blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-i386-pvops host-install(3)
broken-step test-amd64-amd64-xl-qemuu-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemut-win7-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:08:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XliWS-0005Gb-4p; Tue, 04 Nov 2014 18:08:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XliWQ-0005GW-O4
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:08:02 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5D/D6-02702-20619545; Tue, 04 Nov 2014 18:08:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415124479!12527280!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8488 invoked from network); 4 Nov 2014 18:08:01 -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;
	4 Nov 2014 18:08:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,314,1413244800"; d="scan'208";a="188024076"
Message-ID: <545915D7.2070804@citrix.com>
Date: Tue, 4 Nov 2014 18:07:19 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Ian Campbell
	<ian.campbell@citrix.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
In-Reply-To: <20141104173228.GM4510@laptop.dumpdata.com>
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 04/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 04, 2014 at 11:52:47AM +0000, Ian Campbell wrote:
>> This was disabled by default in Xen 4.4. Since xend has now been removed=
 from
>> the tree I don't believe anything is using it.
> What about XenServer?

We are most definitely not using it, and haven=92t used it in a very long
time. We explicitly nuke BLKTAP1 and BLKTAP2 from the Xen build.

>
> And isn't there some blktap3 ?

https://github.com/xapi-project/blktap

>
>> We need to pass an explicit CONFIG_BLKTAP1=3Dn to qemu-xen-traditional o=
therwise
>> it defaults to y and doesn't build.
>>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>> I think this has probably missed the boat for 4.5 and there isn't much h=
arm in
>> waiting for 4.6. I'm open to being told otherwise though ;-)
> You really want to be at the top of the commit list with the most deleted
> code, eh?

/me suspects that he is already, but I for one am a fan of pruning dead
code.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:08:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XliWS-0005Gb-4p; Tue, 04 Nov 2014 18:08:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XliWQ-0005GW-O4
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:08:02 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5D/D6-02702-20619545; Tue, 04 Nov 2014 18:08:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415124479!12527280!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8488 invoked from network); 4 Nov 2014 18:08:01 -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;
	4 Nov 2014 18:08:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,314,1413244800"; d="scan'208";a="188024076"
Message-ID: <545915D7.2070804@citrix.com>
Date: Tue, 4 Nov 2014 18:07:19 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Ian Campbell
	<ian.campbell@citrix.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
In-Reply-To: <20141104173228.GM4510@laptop.dumpdata.com>
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 04/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 04, 2014 at 11:52:47AM +0000, Ian Campbell wrote:
>> This was disabled by default in Xen 4.4. Since xend has now been removed=
 from
>> the tree I don't believe anything is using it.
> What about XenServer?

We are most definitely not using it, and haven=92t used it in a very long
time. We explicitly nuke BLKTAP1 and BLKTAP2 from the Xen build.

>
> And isn't there some blktap3 ?

https://github.com/xapi-project/blktap

>
>> We need to pass an explicit CONFIG_BLKTAP1=3Dn to qemu-xen-traditional o=
therwise
>> it defaults to y and doesn't build.
>>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>> I think this has probably missed the boat for 4.5 and there isn't much h=
arm in
>> waiting for 4.6. I'm open to being told otherwise though ;-)
> You really want to be at the top of the commit list with the most deleted
> code, eh?

/me suspects that he is already, but I for one am a fan of pruning dead
code.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:36:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18: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.xen.org>)
	id 1Xlixn-0005q7-OU; Tue, 04 Nov 2014 18:36:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xlixn-0005q2-3l
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:36:19 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	69/8B-27785-2AC19545; Tue, 04 Nov 2014 18:36:18 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415126175!12551208!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9036 invoked from network); 4 Nov 2014 18:36:17 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 18:36:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415126175; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=g74IRcKBNaeUI89QynuBzFoMSY9ORK4wUauKJ4UPdQc=;
	b=Yi6ScQPT0EcT9OsQ5MECHFa1FAlnYp8tVMnIk+/NvXz5r8KT25UNgGsJfXZpiySIslxBc1uJ0UsRp8EpMwO7ULSdyCZ+bEoHzHhBGYb6PoW2YSTPZkGBK/h747fj7ROPvc59b96p4p2tDEKeJG8XHxZBqaXs8GMXhYp9Vr5cx8A=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Tue, 04 Nov 2014 10:36:14 -0800
	id 000000000003042F.54591C9E.00006AFD
Message-ID: <54591C68.1090501@ihonk.com>
Date: Tue, 04 Nov 2014 10:35:20 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: =?windows-1252?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
In-Reply-To: <20141104082012.GY12451@reaktio.net>
Content-Length: 539
Cc: JBeulich@suse.com, Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/4/2014 0:20, Pasi K=E4rkk=E4inen wrote:
> Does it run stable with Xen 4.5 without PCI/GPU passthru? =


So far yes, I need to work it a bit harder to be sure, though.

> It'd be very helpful if you could set up a serial console to log all the =
Xen and dom0 Linux kernel messages,
> so we could see where it actually crashes..

Okay, I will do that with verbose logging and iommu=3Dintremap,debug.

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:36:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18: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.xen.org>)
	id 1Xlixn-0005q7-OU; Tue, 04 Nov 2014 18:36:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xlixn-0005q2-3l
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:36:19 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	69/8B-27785-2AC19545; Tue, 04 Nov 2014 18:36:18 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415126175!12551208!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9036 invoked from network); 4 Nov 2014 18:36:17 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 18:36:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415126175; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=g74IRcKBNaeUI89QynuBzFoMSY9ORK4wUauKJ4UPdQc=;
	b=Yi6ScQPT0EcT9OsQ5MECHFa1FAlnYp8tVMnIk+/NvXz5r8KT25UNgGsJfXZpiySIslxBc1uJ0UsRp8EpMwO7ULSdyCZ+bEoHzHhBGYb6PoW2YSTPZkGBK/h747fj7ROPvc59b96p4p2tDEKeJG8XHxZBqaXs8GMXhYp9Vr5cx8A=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Tue, 04 Nov 2014 10:36:14 -0800
	id 000000000003042F.54591C9E.00006AFD
Message-ID: <54591C68.1090501@ihonk.com>
Date: Tue, 04 Nov 2014 10:35:20 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: =?windows-1252?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
In-Reply-To: <20141104082012.GY12451@reaktio.net>
Content-Length: 539
Cc: JBeulich@suse.com, Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/4/2014 0:20, Pasi K=E4rkk=E4inen wrote:
> Does it run stable with Xen 4.5 without PCI/GPU passthru? =


So far yes, I need to work it a bit harder to be sure, though.

> It'd be very helpful if you could set up a serial console to log all the =
Xen and dom0 Linux kernel messages,
> so we could see where it actually crashes..

Okay, I will do that with verbose logging and iommu=3Dintremap,debug.

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:39:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18:39:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlj1J-00068K-DM; Tue, 04 Nov 2014 18:39:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1Xlj1H-00068B-WE
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:39:56 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	66/4E-27785-B7D19545; Tue, 04 Nov 2014 18:39:55 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415126393!12549254!1
X-Originating-IP: [209.85.220.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11843 invoked from network); 4 Nov 2014 18:39:54 -0000
Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com)
	(209.85.220.169)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 18:39:54 -0000
Received: by mail-vc0-f169.google.com with SMTP id hy4so7004417vcb.14
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 10:39:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=KPvP/vBclRaj1ZNqlF3lls6J216dmV08cGdeq+nacKU=;
	b=Af6UK/Y1Q46J1l5Ye6bDvDhAv3uboRq98DzeJ1sVEluAavui+E1juWqGq1dysCdJiA
	qeNjrx7/34Nd9q2kaqnoRKewul+wwLT8A74Fg/FZ7dMRhPxpKxfAGUDNI0hSI+nfC/cF
	IlM/TyDnpYYQzOKnSp161Qaw4Y5OoMIFDEsAKgzrPWTp87mqnycF9yUuyHnv+MjOLcM9
	c/HNw3yKWMqaRBkF2ZEt7hkt8UGFaaESO+iSoUjgOghzfD4bNxPkLEY/65U8ejlKrsLz
	Rqqw+0tmQ4iuOstGtzEnceUDjp3s5Xo7h3IY9hKWEGrycWzcUcxoTUVYPWvxaR/okSQ8
	GqSw==
X-Gm-Message-State: ALoCoQnrxsOSe6lTQTaNl7nP6esRXWMhV1PtOOF81Wzq7Fxgf8MOOjE9K/asR15zaxz3JHy3QM0k
MIME-Version: 1.0
X-Received: by 10.52.190.196 with SMTP id gs4mr1162043vdc.72.1415126393150;
	Tue, 04 Nov 2014 10:39:53 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Tue, 4 Nov 2014 10:39:53 -0800 (PST)
In-Reply-To: <5458932F0200007800044A4E@mail.emea.novell.com>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
	<CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
	<5458932F0200007800044A4E@mail.emea.novell.com>
Date: Tue, 4 Nov 2014 10:39:53 -0800
Message-ID: <CAFECyb9Z=YBXhn6xmutp0iV2JNQUbpw3FA=GT4QgSYPwvY9ksw@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 3, 2014 at 11:49 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 04.11.14 at 05:31, <roy.franz@linaro.org> wrote:
>> On Mon, Nov 3, 2014 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
>>>> This patch implements what I understand to be the desired behavior when
>>>> booting
>>>> an EFI Xen image via GRUB based on the thread last week.  The EFI command
>>>> line
>>>> is not used, and the Xen commandline comes via the multiboot protocol (and
>>>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
>>>> GRUB EFI boot cases into alignment in not using the EFI commandline.
>>>
>>> Right, but ...
>>>
>>>> The current state of the arm64 code takes the Xen commandline from the FDT,
>>>> but still looks in the EFI commandline for EFI boot specific options.  If
>>>> unexpected options are passed in the EFI commandline, it will generate
>>>> "unrecognized option" ouput for all unexpected options.
>>>
>>> ... why is this?
>>
>> The EFI boot code did this before any of the arm64 changes, and that
>> behavior is unchanged.
>> The actual message is "WARNING: Unknown command line option"
>>
>> I was simply trying to explain the current behavior regarding the EFI
>> commandline.
>
> Argh, I should have stripped that second sentence from the quoted
> context, as the question was regarding the apparently special ARM64
> behavior you describe.

>>>> The current state of the arm64 code takes the Xen commandline from the FDT,
>>>> but still looks in the EFI commandline for EFI boot specific options.
OK, I'll try address the above.  This behavior is the "no config file
case", which only
exists on arm64 - x86 always uses a config file when booted as an EFI
application, since
for x86 GRUB does execute Xen as en EFI application when using multiboot2.
The case of being executed as an EFI application, loaded by GRUB and provided
module information via the multiboot2 (in FDT) protocol is unique to
arm64.  All the code
is common code, but since efi_arch_use_config_file() is always true
for x86 the case
described only applies to arm64.

When I added the support for arm64 GRUB boot and the no config file
case, I limited
the no config file case to not having a config file, but left console
mode setting, and the
"-basevideo" option that goes with that.  Those changes were narrowly
focused on removing
the need for the config file.  I think that the result of this patch,
which is to have the EFI boot
code only do essential boot setup that doesn't need options (and hence
no EFI command line at all)
is a better way to go.



>
>>>> +    if ( use_cfg_file )
>>>>      {
>>>>          EFI_FILE_HANDLE dir_handle;
>>>> +        size = 0;
>>>
>>> Coding style (missing blank line between declaration(s) and
>>> statement(s). Plus - did you check whether some of the so far
>>> function wide variables (e.g. gop) could be moved into this more
>>> narrow scope?
>>
>> I'll fix the style.  I had not reviewed scope, but now have.  There
>> are only a few
>> variables I can reduce in scope, which I have done in V2 of the patch
>> which I will post shortly.
>> The gop variable and a few others cannot be moved without further code
>> reorganization.  The graphics
>> mode is set later in efi_start() if gop is !null (line 1035)
>> I don't see any reason this code couldn't be moved to be in the if (
>> use_cfg_file ) block, but given that
>> this patch is very late in the release cycle, I'm opting to try to
>> keep this patch minimal.  If you would prefer
>> me to move this code and variables, I am happy to do a v3 with these
>> changes.
>
> No, I'm perfectly fine with your decision not to do a larger re-org.
>
> Jan
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:39:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18:39:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlj1J-00068K-DM; Tue, 04 Nov 2014 18:39:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1Xlj1H-00068B-WE
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:39:56 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	66/4E-27785-B7D19545; Tue, 04 Nov 2014 18:39:55 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415126393!12549254!1
X-Originating-IP: [209.85.220.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11843 invoked from network); 4 Nov 2014 18:39:54 -0000
Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com)
	(209.85.220.169)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 18:39:54 -0000
Received: by mail-vc0-f169.google.com with SMTP id hy4so7004417vcb.14
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 10:39:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=KPvP/vBclRaj1ZNqlF3lls6J216dmV08cGdeq+nacKU=;
	b=Af6UK/Y1Q46J1l5Ye6bDvDhAv3uboRq98DzeJ1sVEluAavui+E1juWqGq1dysCdJiA
	qeNjrx7/34Nd9q2kaqnoRKewul+wwLT8A74Fg/FZ7dMRhPxpKxfAGUDNI0hSI+nfC/cF
	IlM/TyDnpYYQzOKnSp161Qaw4Y5OoMIFDEsAKgzrPWTp87mqnycF9yUuyHnv+MjOLcM9
	c/HNw3yKWMqaRBkF2ZEt7hkt8UGFaaESO+iSoUjgOghzfD4bNxPkLEY/65U8ejlKrsLz
	Rqqw+0tmQ4iuOstGtzEnceUDjp3s5Xo7h3IY9hKWEGrycWzcUcxoTUVYPWvxaR/okSQ8
	GqSw==
X-Gm-Message-State: ALoCoQnrxsOSe6lTQTaNl7nP6esRXWMhV1PtOOF81Wzq7Fxgf8MOOjE9K/asR15zaxz3JHy3QM0k
MIME-Version: 1.0
X-Received: by 10.52.190.196 with SMTP id gs4mr1162043vdc.72.1415126393150;
	Tue, 04 Nov 2014 10:39:53 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Tue, 4 Nov 2014 10:39:53 -0800 (PST)
In-Reply-To: <5458932F0200007800044A4E@mail.emea.novell.com>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
	<CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
	<5458932F0200007800044A4E@mail.emea.novell.com>
Date: Tue, 4 Nov 2014 10:39:53 -0800
Message-ID: <CAFECyb9Z=YBXhn6xmutp0iV2JNQUbpw3FA=GT4QgSYPwvY9ksw@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 3, 2014 at 11:49 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 04.11.14 at 05:31, <roy.franz@linaro.org> wrote:
>> On Mon, Nov 3, 2014 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
>>>> This patch implements what I understand to be the desired behavior when
>>>> booting
>>>> an EFI Xen image via GRUB based on the thread last week.  The EFI command
>>>> line
>>>> is not used, and the Xen commandline comes via the multiboot protocol (and
>>>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
>>>> GRUB EFI boot cases into alignment in not using the EFI commandline.
>>>
>>> Right, but ...
>>>
>>>> The current state of the arm64 code takes the Xen commandline from the FDT,
>>>> but still looks in the EFI commandline for EFI boot specific options.  If
>>>> unexpected options are passed in the EFI commandline, it will generate
>>>> "unrecognized option" ouput for all unexpected options.
>>>
>>> ... why is this?
>>
>> The EFI boot code did this before any of the arm64 changes, and that
>> behavior is unchanged.
>> The actual message is "WARNING: Unknown command line option"
>>
>> I was simply trying to explain the current behavior regarding the EFI
>> commandline.
>
> Argh, I should have stripped that second sentence from the quoted
> context, as the question was regarding the apparently special ARM64
> behavior you describe.

>>>> The current state of the arm64 code takes the Xen commandline from the FDT,
>>>> but still looks in the EFI commandline for EFI boot specific options.
OK, I'll try address the above.  This behavior is the "no config file
case", which only
exists on arm64 - x86 always uses a config file when booted as an EFI
application, since
for x86 GRUB does execute Xen as en EFI application when using multiboot2.
The case of being executed as an EFI application, loaded by GRUB and provided
module information via the multiboot2 (in FDT) protocol is unique to
arm64.  All the code
is common code, but since efi_arch_use_config_file() is always true
for x86 the case
described only applies to arm64.

When I added the support for arm64 GRUB boot and the no config file
case, I limited
the no config file case to not having a config file, but left console
mode setting, and the
"-basevideo" option that goes with that.  Those changes were narrowly
focused on removing
the need for the config file.  I think that the result of this patch,
which is to have the EFI boot
code only do essential boot setup that doesn't need options (and hence
no EFI command line at all)
is a better way to go.



>
>>>> +    if ( use_cfg_file )
>>>>      {
>>>>          EFI_FILE_HANDLE dir_handle;
>>>> +        size = 0;
>>>
>>> Coding style (missing blank line between declaration(s) and
>>> statement(s). Plus - did you check whether some of the so far
>>> function wide variables (e.g. gop) could be moved into this more
>>> narrow scope?
>>
>> I'll fix the style.  I had not reviewed scope, but now have.  There
>> are only a few
>> variables I can reduce in scope, which I have done in V2 of the patch
>> which I will post shortly.
>> The gop variable and a few others cannot be moved without further code
>> reorganization.  The graphics
>> mode is set later in efi_start() if gop is !null (line 1035)
>> I don't see any reason this code couldn't be moved to be in the if (
>> use_cfg_file ) block, but given that
>> this patch is very late in the release cycle, I'm opting to try to
>> keep this patch minimal.  If you would prefer
>> me to move this code and variables, I am happy to do a v3 with these
>> changes.
>
> No, I'm perfectly fine with your decision not to do a larger re-org.
>
> Jan
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:42:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18:42:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlj3k-0006Ko-Vr; Tue, 04 Nov 2014 18:42:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xlj3i-0006KV-Vs
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:42:27 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	F2/0E-02576-21E19545; Tue, 04 Nov 2014 18:42:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415126544!12549571!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23294 invoked from network); 4 Nov 2014 18:42:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 18:42:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4IgBrL026997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 18:42:12 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4IgAZh023321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 18:42:11 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4IgACZ009757; Tue, 4 Nov 2014 18:42:10 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 10:42:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7570D11079B; Tue,  4 Nov 2014 13:42:09 -0500 (EST)
Date: Tue, 4 Nov 2014 13:42:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, yanghy@cn.fujitsu.com,
	guijianfeng@cn.fujitsu.com
Message-ID: <20141104184209.GT4510@laptop.dumpdata.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545915D7.2070804@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMDY6MDc6MTlQTSArMDAwMCwgQW5kcmV3IENvb3BlciB3
cm90ZToKPiBPbiAwNC8xMS8xNCAxNzozMiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+
ID4gT24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMTE6NTI6NDdBTSArMDAwMCwgSWFuIENhbXBiZWxs
IHdyb3RlOgo+ID4+IFRoaXMgd2FzIGRpc2FibGVkIGJ5IGRlZmF1bHQgaW4gWGVuIDQuNC4gU2lu
Y2UgeGVuZCBoYXMgbm93IGJlZW4gcmVtb3ZlZCBmcm9tCj4gPj4gdGhlIHRyZWUgSSBkb24ndCBi
ZWxpZXZlIGFueXRoaW5nIGlzIHVzaW5nIGl0Lgo+ID4gV2hhdCBhYm91dCBYZW5TZXJ2ZXI/Cj4g
Cj4gV2UgYXJlIG1vc3QgZGVmaW5pdGVseSBub3QgdXNpbmcgaXQsIGFuZCBoYXZlbuKAmXQgdXNl
ZCBpdCBpbiBhIHZlcnkgbG9uZwo+IHRpbWUuIFdlIGV4cGxpY2l0bHkgbnVrZSBCTEtUQVAxIGFu
ZCBCTEtUQVAyIGZyb20gdGhlIFhlbiBidWlsZC4KPiAKPiA+Cj4gPiBBbmQgaXNuJ3QgdGhlcmUg
c29tZSBibGt0YXAzID8KPiAKPiBodHRwczovL2dpdGh1Yi5jb20veGFwaS1wcm9qZWN0L2Jsa3Rh
cAo+IAo+ID4KPiA+PiBXZSBuZWVkIHRvIHBhc3MgYW4gZXhwbGljaXQgQ09ORklHX0JMS1RBUDE9
biB0byBxZW11LXhlbi10cmFkaXRpb25hbCBvdGhlcndpc2UKPiA+PiBpdCBkZWZhdWx0cyB0byB5
IGFuZCBkb2Vzbid0IGJ1aWxkLgo+ID4+Cj4gPj4gU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxs
IDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPiA+PiBDYzogS29ucmFkIFJ6ZXN6dXRlayBXaWxr
IDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgo+ID4+IC0tLQo+ID4+IEkgdGhpbmsgdGhpcyBoYXMg
cHJvYmFibHkgbWlzc2VkIHRoZSBib2F0IGZvciA0LjUgYW5kIHRoZXJlIGlzbid0IG11Y2ggaGFy
bSBpbgo+ID4+IHdhaXRpbmcgZm9yIDQuNi4gSSdtIG9wZW4gdG8gYmVpbmcgdG9sZCBvdGhlcndp
c2UgdGhvdWdoIDstKQo+ID4gWW91IHJlYWxseSB3YW50IHRvIGJlIGF0IHRoZSB0b3Agb2YgdGhl
IGNvbW1pdCBsaXN0IHdpdGggdGhlIG1vc3QgZGVsZXRlZAo+ID4gY29kZSwgZWg/Cj4gCj4gL21l
IHN1c3BlY3RzIHRoYXQgaGUgaXMgYWxyZWFkeSwgYnV0IEkgZm9yIG9uZSBhbSBhIGZhbiBvZiBw
cnVuaW5nIGRlYWQKPiBjb2RlLgoKVHJ1ZSwgYnV0IHdlIGRpZCB0YWxrIGFib3V0IHhlbmQgcmVt
b3ZhbCBmb3IgcXVpdGUgYSB3aGlsZSBiZWZvcmUgZG9pbmcgaXQuCgpIb3dldmVyLCBJIGJlbGll
dmUgdGhhdCB0aGUgZm9sa3MgdGhhdCBkaWQgUmVtdXMgbG9vayB0byBiZSB1c2luZyBpdAooQW5k
IHRoZXkgaGF2ZSB0b25zIG9mIHBhdGNoZXMgYWdhaW5zdCBpdCkuCgoKICAgSXQgaXMgdW5jbGVh
ciB0byBtZSB3aGV0aGVyIHRoZXk6CgktIHdhbnQgdG8gYmUgdGhlIG1haW50YWluZXJzIG9mIGl0
PwoJLSB3YW50IHRvIHVzZSBibGt0YXAzIGJ1dCBoYXZlbid0IHlldCBiYWNrcG9ydGVkIHRoZWly
IHBhdGNoZXMuCgoKPiAKPiB+QW5kcmV3Cj4gCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:42:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18:42:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlj3k-0006Ko-Vr; Tue, 04 Nov 2014 18:42:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xlj3i-0006KV-Vs
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:42:27 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	F2/0E-02576-21E19545; Tue, 04 Nov 2014 18:42:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415126544!12549571!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23294 invoked from network); 4 Nov 2014 18:42:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 18:42:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4IgBrL026997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 18:42:12 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4IgAZh023321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 18:42:11 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4IgACZ009757; Tue, 4 Nov 2014 18:42:10 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 10:42:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7570D11079B; Tue,  4 Nov 2014 13:42:09 -0500 (EST)
Date: Tue, 4 Nov 2014 13:42:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, yanghy@cn.fujitsu.com,
	guijianfeng@cn.fujitsu.com
Message-ID: <20141104184209.GT4510@laptop.dumpdata.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545915D7.2070804@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMDY6MDc6MTlQTSArMDAwMCwgQW5kcmV3IENvb3BlciB3
cm90ZToKPiBPbiAwNC8xMS8xNCAxNzozMiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+
ID4gT24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMTE6NTI6NDdBTSArMDAwMCwgSWFuIENhbXBiZWxs
IHdyb3RlOgo+ID4+IFRoaXMgd2FzIGRpc2FibGVkIGJ5IGRlZmF1bHQgaW4gWGVuIDQuNC4gU2lu
Y2UgeGVuZCBoYXMgbm93IGJlZW4gcmVtb3ZlZCBmcm9tCj4gPj4gdGhlIHRyZWUgSSBkb24ndCBi
ZWxpZXZlIGFueXRoaW5nIGlzIHVzaW5nIGl0Lgo+ID4gV2hhdCBhYm91dCBYZW5TZXJ2ZXI/Cj4g
Cj4gV2UgYXJlIG1vc3QgZGVmaW5pdGVseSBub3QgdXNpbmcgaXQsIGFuZCBoYXZlbuKAmXQgdXNl
ZCBpdCBpbiBhIHZlcnkgbG9uZwo+IHRpbWUuIFdlIGV4cGxpY2l0bHkgbnVrZSBCTEtUQVAxIGFu
ZCBCTEtUQVAyIGZyb20gdGhlIFhlbiBidWlsZC4KPiAKPiA+Cj4gPiBBbmQgaXNuJ3QgdGhlcmUg
c29tZSBibGt0YXAzID8KPiAKPiBodHRwczovL2dpdGh1Yi5jb20veGFwaS1wcm9qZWN0L2Jsa3Rh
cAo+IAo+ID4KPiA+PiBXZSBuZWVkIHRvIHBhc3MgYW4gZXhwbGljaXQgQ09ORklHX0JMS1RBUDE9
biB0byBxZW11LXhlbi10cmFkaXRpb25hbCBvdGhlcndpc2UKPiA+PiBpdCBkZWZhdWx0cyB0byB5
IGFuZCBkb2Vzbid0IGJ1aWxkLgo+ID4+Cj4gPj4gU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxs
IDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPiA+PiBDYzogS29ucmFkIFJ6ZXN6dXRlayBXaWxr
IDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgo+ID4+IC0tLQo+ID4+IEkgdGhpbmsgdGhpcyBoYXMg
cHJvYmFibHkgbWlzc2VkIHRoZSBib2F0IGZvciA0LjUgYW5kIHRoZXJlIGlzbid0IG11Y2ggaGFy
bSBpbgo+ID4+IHdhaXRpbmcgZm9yIDQuNi4gSSdtIG9wZW4gdG8gYmVpbmcgdG9sZCBvdGhlcndp
c2UgdGhvdWdoIDstKQo+ID4gWW91IHJlYWxseSB3YW50IHRvIGJlIGF0IHRoZSB0b3Agb2YgdGhl
IGNvbW1pdCBsaXN0IHdpdGggdGhlIG1vc3QgZGVsZXRlZAo+ID4gY29kZSwgZWg/Cj4gCj4gL21l
IHN1c3BlY3RzIHRoYXQgaGUgaXMgYWxyZWFkeSwgYnV0IEkgZm9yIG9uZSBhbSBhIGZhbiBvZiBw
cnVuaW5nIGRlYWQKPiBjb2RlLgoKVHJ1ZSwgYnV0IHdlIGRpZCB0YWxrIGFib3V0IHhlbmQgcmVt
b3ZhbCBmb3IgcXVpdGUgYSB3aGlsZSBiZWZvcmUgZG9pbmcgaXQuCgpIb3dldmVyLCBJIGJlbGll
dmUgdGhhdCB0aGUgZm9sa3MgdGhhdCBkaWQgUmVtdXMgbG9vayB0byBiZSB1c2luZyBpdAooQW5k
IHRoZXkgaGF2ZSB0b25zIG9mIHBhdGNoZXMgYWdhaW5zdCBpdCkuCgoKICAgSXQgaXMgdW5jbGVh
ciB0byBtZSB3aGV0aGVyIHRoZXk6CgktIHdhbnQgdG8gYmUgdGhlIG1haW50YWluZXJzIG9mIGl0
PwoJLSB3YW50IHRvIHVzZSBibGt0YXAzIGJ1dCBoYXZlbid0IHlldCBiYWNrcG9ydGVkIHRoZWly
IHBhdGNoZXMuCgoKPiAKPiB+QW5kcmV3Cj4gCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:45:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18: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 1Xlj6Z-0006a9-Ic; Tue, 04 Nov 2014 18:45:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xlj6Y-0006a2-B0
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:45:22 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	D1/DA-02696-1CE19545; Tue, 04 Nov 2014 18:45:21 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415126717!9210760!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26055 invoked from network); 4 Nov 2014 18:45:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 18:45:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,314,1413244800"; d="scan'208";a="189422118"
Message-ID: <54591EB8.4070007@citrix.com>
Date: Tue, 4 Nov 2014 18:45:12 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, <yanghy@cn.fujitsu.com>,
	<guijianfeng@cn.fujitsu.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
In-Reply-To: <20141104184209.GT4510@laptop.dumpdata.com>
Content-Length: 2387
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDQvMTEvMTQgMTg6NDIsIEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZToKPiBPbiBUdWUs
IE5vdiAwNCwgMjAxNCBhdCAwNjowNzoxOVBNICswMDAwLCBBbmRyZXcgQ29vcGVyIHdyb3RlOgo+
PiBPbiAwNC8xMS8xNCAxNzozMiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+Pj4gT24g
VHVlLCBOb3YgMDQsIDIwMTQgYXQgMTE6NTI6NDdBTSArMDAwMCwgSWFuIENhbXBiZWxsIHdyb3Rl
Ogo+Pj4+IFRoaXMgd2FzIGRpc2FibGVkIGJ5IGRlZmF1bHQgaW4gWGVuIDQuNC4gU2luY2UgeGVu
ZCBoYXMgbm93IGJlZW4gcmVtb3ZlZCBmcm9tCj4+Pj4gdGhlIHRyZWUgSSBkb24ndCBiZWxpZXZl
IGFueXRoaW5nIGlzIHVzaW5nIGl0Lgo+Pj4gV2hhdCBhYm91dCBYZW5TZXJ2ZXI/Cj4+IFdlIGFy
ZSBtb3N0IGRlZmluaXRlbHkgbm90IHVzaW5nIGl0LCBhbmQgaGF2ZW7igJl0IHVzZWQgaXQgaW4g
YSB2ZXJ5IGxvbmcKPj4gdGltZS4gV2UgZXhwbGljaXRseSBudWtlIEJMS1RBUDEgYW5kIEJMS1RB
UDIgZnJvbSB0aGUgWGVuIGJ1aWxkLgo+Pgo+Pj4gQW5kIGlzbid0IHRoZXJlIHNvbWUgYmxrdGFw
MyA/Cj4+IGh0dHBzOi8vZ2l0aHViLmNvbS94YXBpLXByb2plY3QvYmxrdGFwCj4+Cj4+Pj4gV2Ug
bmVlZCB0byBwYXNzIGFuIGV4cGxpY2l0IENPTkZJR19CTEtUQVAxPW4gdG8gcWVtdS14ZW4tdHJh
ZGl0aW9uYWwgb3RoZXJ3aXNlCj4+Pj4gaXQgZGVmYXVsdHMgdG8geSBhbmQgZG9lc24ndCBidWls
ZC4KPj4+Pgo+Pj4+IFNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp
dHJpeC5jb20+Cj4+Pj4gQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3Jh
Y2xlLmNvbT4KPj4+PiAtLS0KPj4+PiBJIHRoaW5rIHRoaXMgaGFzIHByb2JhYmx5IG1pc3NlZCB0
aGUgYm9hdCBmb3IgNC41IGFuZCB0aGVyZSBpc24ndCBtdWNoIGhhcm0gaW4KPj4+PiB3YWl0aW5n
IGZvciA0LjYuIEknbSBvcGVuIHRvIGJlaW5nIHRvbGQgb3RoZXJ3aXNlIHRob3VnaCA7LSkKPj4+
IFlvdSByZWFsbHkgd2FudCB0byBiZSBhdCB0aGUgdG9wIG9mIHRoZSBjb21taXQgbGlzdCB3aXRo
IHRoZSBtb3N0IGRlbGV0ZWQKPj4+IGNvZGUsIGVoPwo+PiAvbWUgc3VzcGVjdHMgdGhhdCBoZSBp
cyBhbHJlYWR5LCBidXQgSSBmb3Igb25lIGFtIGEgZmFuIG9mIHBydW5pbmcgZGVhZAo+PiBjb2Rl
Lgo+IFRydWUsIGJ1dCB3ZSBkaWQgdGFsayBhYm91dCB4ZW5kIHJlbW92YWwgZm9yIHF1aXRlIGEg
d2hpbGUgYmVmb3JlIGRvaW5nIGl0Lgo+Cj4gSG93ZXZlciwgSSBiZWxpZXZlIHRoYXQgdGhlIGZv
bGtzIHRoYXQgZGlkIFJlbXVzIGxvb2sgdG8gYmUgdXNpbmcgaXQKPiAoQW5kIHRoZXkgaGF2ZSB0
b25zIG9mIHBhdGNoZXMgYWdhaW5zdCBpdCkuCj4KPgo+ICAgIEl0IGlzIHVuY2xlYXIgdG8gbWUg
d2hldGhlciB0aGV5Ogo+IAktIHdhbnQgdG8gYmUgdGhlIG1haW50YWluZXJzIG9mIGl0Pwo+IAkt
IHdhbnQgdG8gdXNlIGJsa3RhcDMgYnV0IGhhdmVuJ3QgeWV0IGJhY2twb3J0ZWQgdGhlaXIgcGF0
Y2hlcy4KClRoZSByZW11cyBwYXRjaGVzIGFyZSBhZ2FpbnN0IGJsa3RhcDIsIG5vdCBibGt0YXAx
LiAgV2UgY3VycmVudGx5IGhhdmUKYm90aCBpbi10cmVlLgoKfkFuZHJldwoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:45:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18: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 1Xlj6Z-0006a9-Ic; Tue, 04 Nov 2014 18:45:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xlj6Y-0006a2-B0
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:45:22 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	D1/DA-02696-1CE19545; Tue, 04 Nov 2014 18:45:21 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415126717!9210760!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26055 invoked from network); 4 Nov 2014 18:45:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 18:45:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,314,1413244800"; d="scan'208";a="189422118"
Message-ID: <54591EB8.4070007@citrix.com>
Date: Tue, 4 Nov 2014 18:45:12 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, <yanghy@cn.fujitsu.com>,
	<guijianfeng@cn.fujitsu.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
In-Reply-To: <20141104184209.GT4510@laptop.dumpdata.com>
Content-Length: 2387
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDQvMTEvMTQgMTg6NDIsIEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZToKPiBPbiBUdWUs
IE5vdiAwNCwgMjAxNCBhdCAwNjowNzoxOVBNICswMDAwLCBBbmRyZXcgQ29vcGVyIHdyb3RlOgo+
PiBPbiAwNC8xMS8xNCAxNzozMiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+Pj4gT24g
VHVlLCBOb3YgMDQsIDIwMTQgYXQgMTE6NTI6NDdBTSArMDAwMCwgSWFuIENhbXBiZWxsIHdyb3Rl
Ogo+Pj4+IFRoaXMgd2FzIGRpc2FibGVkIGJ5IGRlZmF1bHQgaW4gWGVuIDQuNC4gU2luY2UgeGVu
ZCBoYXMgbm93IGJlZW4gcmVtb3ZlZCBmcm9tCj4+Pj4gdGhlIHRyZWUgSSBkb24ndCBiZWxpZXZl
IGFueXRoaW5nIGlzIHVzaW5nIGl0Lgo+Pj4gV2hhdCBhYm91dCBYZW5TZXJ2ZXI/Cj4+IFdlIGFy
ZSBtb3N0IGRlZmluaXRlbHkgbm90IHVzaW5nIGl0LCBhbmQgaGF2ZW7igJl0IHVzZWQgaXQgaW4g
YSB2ZXJ5IGxvbmcKPj4gdGltZS4gV2UgZXhwbGljaXRseSBudWtlIEJMS1RBUDEgYW5kIEJMS1RB
UDIgZnJvbSB0aGUgWGVuIGJ1aWxkLgo+Pgo+Pj4gQW5kIGlzbid0IHRoZXJlIHNvbWUgYmxrdGFw
MyA/Cj4+IGh0dHBzOi8vZ2l0aHViLmNvbS94YXBpLXByb2plY3QvYmxrdGFwCj4+Cj4+Pj4gV2Ug
bmVlZCB0byBwYXNzIGFuIGV4cGxpY2l0IENPTkZJR19CTEtUQVAxPW4gdG8gcWVtdS14ZW4tdHJh
ZGl0aW9uYWwgb3RoZXJ3aXNlCj4+Pj4gaXQgZGVmYXVsdHMgdG8geSBhbmQgZG9lc24ndCBidWls
ZC4KPj4+Pgo+Pj4+IFNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp
dHJpeC5jb20+Cj4+Pj4gQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3Jh
Y2xlLmNvbT4KPj4+PiAtLS0KPj4+PiBJIHRoaW5rIHRoaXMgaGFzIHByb2JhYmx5IG1pc3NlZCB0
aGUgYm9hdCBmb3IgNC41IGFuZCB0aGVyZSBpc24ndCBtdWNoIGhhcm0gaW4KPj4+PiB3YWl0aW5n
IGZvciA0LjYuIEknbSBvcGVuIHRvIGJlaW5nIHRvbGQgb3RoZXJ3aXNlIHRob3VnaCA7LSkKPj4+
IFlvdSByZWFsbHkgd2FudCB0byBiZSBhdCB0aGUgdG9wIG9mIHRoZSBjb21taXQgbGlzdCB3aXRo
IHRoZSBtb3N0IGRlbGV0ZWQKPj4+IGNvZGUsIGVoPwo+PiAvbWUgc3VzcGVjdHMgdGhhdCBoZSBp
cyBhbHJlYWR5LCBidXQgSSBmb3Igb25lIGFtIGEgZmFuIG9mIHBydW5pbmcgZGVhZAo+PiBjb2Rl
Lgo+IFRydWUsIGJ1dCB3ZSBkaWQgdGFsayBhYm91dCB4ZW5kIHJlbW92YWwgZm9yIHF1aXRlIGEg
d2hpbGUgYmVmb3JlIGRvaW5nIGl0Lgo+Cj4gSG93ZXZlciwgSSBiZWxpZXZlIHRoYXQgdGhlIGZv
bGtzIHRoYXQgZGlkIFJlbXVzIGxvb2sgdG8gYmUgdXNpbmcgaXQKPiAoQW5kIHRoZXkgaGF2ZSB0
b25zIG9mIHBhdGNoZXMgYWdhaW5zdCBpdCkuCj4KPgo+ICAgIEl0IGlzIHVuY2xlYXIgdG8gbWUg
d2hldGhlciB0aGV5Ogo+IAktIHdhbnQgdG8gYmUgdGhlIG1haW50YWluZXJzIG9mIGl0Pwo+IAkt
IHdhbnQgdG8gdXNlIGJsa3RhcDMgYnV0IGhhdmVuJ3QgeWV0IGJhY2twb3J0ZWQgdGhlaXIgcGF0
Y2hlcy4KClRoZSByZW11cyBwYXRjaGVzIGFyZSBhZ2FpbnN0IGJsa3RhcDIsIG5vdCBibGt0YXAx
LiAgV2UgY3VycmVudGx5IGhhdmUKYm90aCBpbi10cmVlLgoKfkFuZHJldwoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18: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 1Xlj7T-0006f3-02; Tue, 04 Nov 2014 18:46:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1Xlj7S-0006es-2v
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:46:18 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	54/42-19763-9FE19545; Tue, 04 Nov 2014 18:46:17 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415126775!5790117!1
X-Originating-IP: [209.85.220.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26406 invoked from network); 4 Nov 2014 18:46:16 -0000
Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com)
	(209.85.220.180)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 18:46:16 -0000
Received: by mail-vc0-f180.google.com with SMTP id hy10so6905445vcb.25
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 10:46:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=zdseORZouZfDsqxJFqC8VOuHisOv+PsA21qK1I8qpRQ=;
	b=lrYMOILaub2k29TYuDIz5YWesPGV6HiNlHT3sMje+g3tZmI+dzrb4kl8v7ZcJq7Snr
	B9LIFs+zViPIYt3h1Oo+HMDA3gzFWq462IlgjtTVBFaGyWt1ISxTRZc5udiwtcLNFNge
	M+DbuPjdoQZ4cT08FyuUpsOofqzOpwX3FEzNeK5h9SMR2GCrsUslw6d2NCsZwy0n3GB3
	uVI41bJFZVZomWtlxPPx+4gh1R/70G6/IuczDWlMFMr/Q3Iw0YeqGURSaIbo7mOXYBvK
	Cvzm0SDwIs52ZM3WwuJdI3WoIKq2Jbz54JFZQfinS9v5AzFT2yS5rycd8nsICPMQHlDO
	Ub+A==
X-Gm-Message-State: ALoCoQmP4T672j9h8BVEwevLNmrWDs7Oil2oqzSoloi6ahRcC+8D0dW7FIcLf05kucc+s7JxRLFf
MIME-Version: 1.0
X-Received: by 10.221.65.136 with SMTP id xm8mr1522574vcb.62.1415126775081;
	Tue, 04 Nov 2014 10:46:15 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Tue, 4 Nov 2014 10:46:15 -0800 (PST)
In-Reply-To: <20141104115733.GG16923@olila.local.net-space.pl>
References: <1415075851-8987-1-git-send-email-roy.franz@linaro.org>
	<20141104115733.GG16923@olila.local.net-space.pl>
Date: Tue, 4 Nov 2014 10:46:15 -0800
Message-ID: <CAFECyb83ZgB73jCg1EcuWpTaXtcWLMjBeLbcyygiwVfGXGXLKA@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 V2] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 3:57 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> On Mon, Nov 03, 2014 at 08:37:31PM -0800, Roy Franz wrote:
>> Update EFI code to completely ignore the EFI comnandline when booted from GRUB.
>> Previusly it was parsed of EFI boot specific options, but these aren't used
>> when booted from GRUB.
>>
>> Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
>> code does some console and video initialization to support native EFI boot from
>> the EFI boot manager or EFI shell.  This initlization should not be done when
>> booted using GRUB.
>>
>> Update EFI documentation to indicate that it describes EFI native boot, and
>> does not apply at all when Xen is booted using GRUB.
>>
>> Signed-off-by: Roy Franz <roy.franz@linaro.org>
>
> In general Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> but...
>
>> ---
>> This patch implements what I understand to be the desired behavior when booting
>> an EFI Xen image via GRUB based on the thread last week.  The EFI command line
>> is not used, and the Xen commandline comes via the multiboot protocol (and
>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
>> GRUB EFI boot cases into alignment in not using the EFI commandline.
>>
>> The current state of the arm64 code takes the Xen commandline from the FDT,
>> but still looks in the EFI commandline for EFI boot specific options.  If
>> unexpected options are passed in the EFI commandline, it will generate
>> "unrecognized option" ouput for all unexpected options.
>>
>> I think this should be considered for 4.5.
>>
>> Changes from v1:
>> * Fixed style, and removed blank line changes
>> * Reviewed scope of variables now that more code is in if ( use_cfg_file ) block
>>
>>
>>  docs/misc/efi.markdown |   5 ++
>>  xen/common/efi/boot.c  | 240 +++++++++++++++++++++++++------------------------
>>  2 files changed, 128 insertions(+), 117 deletions(-)
>>
>> diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
>> index 5e48aa3..f435ec7 100644
>> --- a/docs/misc/efi.markdown
>> +++ b/docs/misc/efi.markdown
>> @@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
>>  (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
>>  try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
>>  order.) One can override this with a command line option (`-cfg=<filename>`).
>> +This configuration file and EFI commandline are only used for booting directly
>> +from EFI firmware, or when using an EFI loader that does not support
>> +the multiboot2 protocol.  When booting using GRUB or another multiboot aware
>> +loader the EFI commandline is ignored and all information is passed from
>> +the loader to Xen using the multiboot protocol.
>
> First you are referring to multiboot2 and later you are talking about
> multiboot. It makes some confusion. Could you put full stop after "...
> using an EFI loader" or rephrase this sentences in another way to make
> them clear?
>
> Daniel
I think all references should be multiboot2.  I do really want
something that is clear
to most readers.

How about:

"This configuration file and EFI commandline are only used for booting directly
from EFI firmware, or when using an EFI loader. When booting using GRUB or
another multiboot2 aware loader the EFI commandline is ignored and all
information
is passed from the loader to Xen using the multiboot protocol."

Would it be helpful to list an example EFI loader, such as gummiboot?

"... or when using an EFI loader (such as gummiboot.)  When booting using GRUB"

gummiboot and other EFI loaders just execute another EFI application,
so as far as Xen
is concerned this would be like booting from the EFI shell.

Thanks,
Roy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 18:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 18: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 1Xlj7T-0006f3-02; Tue, 04 Nov 2014 18:46:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1Xlj7S-0006es-2v
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 18:46:18 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	54/42-19763-9FE19545; Tue, 04 Nov 2014 18:46:17 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415126775!5790117!1
X-Originating-IP: [209.85.220.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26406 invoked from network); 4 Nov 2014 18:46:16 -0000
Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com)
	(209.85.220.180)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 18:46:16 -0000
Received: by mail-vc0-f180.google.com with SMTP id hy10so6905445vcb.25
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 10:46:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=zdseORZouZfDsqxJFqC8VOuHisOv+PsA21qK1I8qpRQ=;
	b=lrYMOILaub2k29TYuDIz5YWesPGV6HiNlHT3sMje+g3tZmI+dzrb4kl8v7ZcJq7Snr
	B9LIFs+zViPIYt3h1Oo+HMDA3gzFWq462IlgjtTVBFaGyWt1ISxTRZc5udiwtcLNFNge
	M+DbuPjdoQZ4cT08FyuUpsOofqzOpwX3FEzNeK5h9SMR2GCrsUslw6d2NCsZwy0n3GB3
	uVI41bJFZVZomWtlxPPx+4gh1R/70G6/IuczDWlMFMr/Q3Iw0YeqGURSaIbo7mOXYBvK
	Cvzm0SDwIs52ZM3WwuJdI3WoIKq2Jbz54JFZQfinS9v5AzFT2yS5rycd8nsICPMQHlDO
	Ub+A==
X-Gm-Message-State: ALoCoQmP4T672j9h8BVEwevLNmrWDs7Oil2oqzSoloi6ahRcC+8D0dW7FIcLf05kucc+s7JxRLFf
MIME-Version: 1.0
X-Received: by 10.221.65.136 with SMTP id xm8mr1522574vcb.62.1415126775081;
	Tue, 04 Nov 2014 10:46:15 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Tue, 4 Nov 2014 10:46:15 -0800 (PST)
In-Reply-To: <20141104115733.GG16923@olila.local.net-space.pl>
References: <1415075851-8987-1-git-send-email-roy.franz@linaro.org>
	<20141104115733.GG16923@olila.local.net-space.pl>
Date: Tue, 4 Nov 2014 10:46:15 -0800
Message-ID: <CAFECyb83ZgB73jCg1EcuWpTaXtcWLMjBeLbcyygiwVfGXGXLKA@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 V2] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 3:57 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> On Mon, Nov 03, 2014 at 08:37:31PM -0800, Roy Franz wrote:
>> Update EFI code to completely ignore the EFI comnandline when booted from GRUB.
>> Previusly it was parsed of EFI boot specific options, but these aren't used
>> when booted from GRUB.
>>
>> Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
>> code does some console and video initialization to support native EFI boot from
>> the EFI boot manager or EFI shell.  This initlization should not be done when
>> booted using GRUB.
>>
>> Update EFI documentation to indicate that it describes EFI native boot, and
>> does not apply at all when Xen is booted using GRUB.
>>
>> Signed-off-by: Roy Franz <roy.franz@linaro.org>
>
> In general Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> but...
>
>> ---
>> This patch implements what I understand to be the desired behavior when booting
>> an EFI Xen image via GRUB based on the thread last week.  The EFI command line
>> is not used, and the Xen commandline comes via the multiboot protocol (and
>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
>> GRUB EFI boot cases into alignment in not using the EFI commandline.
>>
>> The current state of the arm64 code takes the Xen commandline from the FDT,
>> but still looks in the EFI commandline for EFI boot specific options.  If
>> unexpected options are passed in the EFI commandline, it will generate
>> "unrecognized option" ouput for all unexpected options.
>>
>> I think this should be considered for 4.5.
>>
>> Changes from v1:
>> * Fixed style, and removed blank line changes
>> * Reviewed scope of variables now that more code is in if ( use_cfg_file ) block
>>
>>
>>  docs/misc/efi.markdown |   5 ++
>>  xen/common/efi/boot.c  | 240 +++++++++++++++++++++++++------------------------
>>  2 files changed, 128 insertions(+), 117 deletions(-)
>>
>> diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
>> index 5e48aa3..f435ec7 100644
>> --- a/docs/misc/efi.markdown
>> +++ b/docs/misc/efi.markdown
>> @@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
>>  (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
>>  try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
>>  order.) One can override this with a command line option (`-cfg=<filename>`).
>> +This configuration file and EFI commandline are only used for booting directly
>> +from EFI firmware, or when using an EFI loader that does not support
>> +the multiboot2 protocol.  When booting using GRUB or another multiboot aware
>> +loader the EFI commandline is ignored and all information is passed from
>> +the loader to Xen using the multiboot protocol.
>
> First you are referring to multiboot2 and later you are talking about
> multiboot. It makes some confusion. Could you put full stop after "...
> using an EFI loader" or rephrase this sentences in another way to make
> them clear?
>
> Daniel
I think all references should be multiboot2.  I do really want
something that is clear
to most readers.

How about:

"This configuration file and EFI commandline are only used for booting directly
from EFI firmware, or when using an EFI loader. When booting using GRUB or
another multiboot2 aware loader the EFI commandline is ignored and all
information
is passed from the loader to Xen using the multiboot protocol."

Would it be helpful to list an example EFI loader, such as gummiboot?

"... or when using an EFI loader (such as gummiboot.)  When booting using GRUB"

gummiboot and other EFI loaders just execute another EFI application,
so as far as Xen
is concerned this would be like booting from the EFI shell.

Thanks,
Roy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 20:01:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 20:01:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlkHF-0008UG-1k; Tue, 04 Nov 2014 20:00:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlkHC-0008UB-NH
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 20:00:26 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	15/51-09284-95039545; Tue, 04 Nov 2014 20:00:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415131223!7204659!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1870 invoked from network); 4 Nov 2014 20:00:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 20:00:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4K09Mu000490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 20:00:10 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4K07oS029964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 20:00:08 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4K07Tt029940; Tue, 4 Nov 2014 20:00:07 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 12:00:07 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2AF511108AB; Tue,  4 Nov 2014 15:00:06 -0500 (EST)
Date: Tue, 4 Nov 2014 15:00:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141104200006.GD12464@laptop.dumpdata.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
	<54591EB8.4070007@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54591EB8.4070007@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: wei.liu2@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	guijianfeng@cn.fujitsu.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMDY6NDU6MTJQTSArMDAwMCwgQW5kcmV3IENvb3BlciB3
cm90ZToKPiBPbiAwNC8xMS8xNCAxODo0MiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+
ID4gT24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMDY6MDc6MTlQTSArMDAwMCwgQW5kcmV3IENvb3Bl
ciB3cm90ZToKPiA+PiBPbiAwNC8xMS8xNCAxNzozMiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdy
b3RlOgo+ID4+PiBPbiBUdWUsIE5vdiAwNCwgMjAxNCBhdCAxMTo1Mjo0N0FNICswMDAwLCBJYW4g
Q2FtcGJlbGwgd3JvdGU6Cj4gPj4+PiBUaGlzIHdhcyBkaXNhYmxlZCBieSBkZWZhdWx0IGluIFhl
biA0LjQuIFNpbmNlIHhlbmQgaGFzIG5vdyBiZWVuIHJlbW92ZWQgZnJvbQo+ID4+Pj4gdGhlIHRy
ZWUgSSBkb24ndCBiZWxpZXZlIGFueXRoaW5nIGlzIHVzaW5nIGl0Lgo+ID4+PiBXaGF0IGFib3V0
IFhlblNlcnZlcj8KPiA+PiBXZSBhcmUgbW9zdCBkZWZpbml0ZWx5IG5vdCB1c2luZyBpdCwgYW5k
IGhhdmVu4oCZdCB1c2VkIGl0IGluIGEgdmVyeSBsb25nCj4gPj4gdGltZS4gV2UgZXhwbGljaXRs
eSBudWtlIEJMS1RBUDEgYW5kIEJMS1RBUDIgZnJvbSB0aGUgWGVuIGJ1aWxkLgo+ID4+Cj4gPj4+
IEFuZCBpc24ndCB0aGVyZSBzb21lIGJsa3RhcDMgPwo+ID4+IGh0dHBzOi8vZ2l0aHViLmNvbS94
YXBpLXByb2plY3QvYmxrdGFwCj4gPj4KPiA+Pj4+IFdlIG5lZWQgdG8gcGFzcyBhbiBleHBsaWNp
dCBDT05GSUdfQkxLVEFQMT1uIHRvIHFlbXUteGVuLXRyYWRpdGlvbmFsIG90aGVyd2lzZQo+ID4+
Pj4gaXQgZGVmYXVsdHMgdG8geSBhbmQgZG9lc24ndCBidWlsZC4KPiA+Pj4+Cj4gPj4+PiBTaWdu
ZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+ID4+Pj4g
Q2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPiA+Pj4+
IC0tLQo+ID4+Pj4gSSB0aGluayB0aGlzIGhhcyBwcm9iYWJseSBtaXNzZWQgdGhlIGJvYXQgZm9y
IDQuNSBhbmQgdGhlcmUgaXNuJ3QgbXVjaCBoYXJtIGluCj4gPj4+PiB3YWl0aW5nIGZvciA0LjYu
IEknbSBvcGVuIHRvIGJlaW5nIHRvbGQgb3RoZXJ3aXNlIHRob3VnaCA7LSkKPiA+Pj4gWW91IHJl
YWxseSB3YW50IHRvIGJlIGF0IHRoZSB0b3Agb2YgdGhlIGNvbW1pdCBsaXN0IHdpdGggdGhlIG1v
c3QgZGVsZXRlZAo+ID4+PiBjb2RlLCBlaD8KPiA+PiAvbWUgc3VzcGVjdHMgdGhhdCBoZSBpcyBh
bHJlYWR5LCBidXQgSSBmb3Igb25lIGFtIGEgZmFuIG9mIHBydW5pbmcgZGVhZAo+ID4+IGNvZGUu
Cj4gPiBUcnVlLCBidXQgd2UgZGlkIHRhbGsgYWJvdXQgeGVuZCByZW1vdmFsIGZvciBxdWl0ZSBh
IHdoaWxlIGJlZm9yZSBkb2luZyBpdC4KPiA+Cj4gPiBIb3dldmVyLCBJIGJlbGlldmUgdGhhdCB0
aGUgZm9sa3MgdGhhdCBkaWQgUmVtdXMgbG9vayB0byBiZSB1c2luZyBpdAo+ID4gKEFuZCB0aGV5
IGhhdmUgdG9ucyBvZiBwYXRjaGVzIGFnYWluc3QgaXQpLgo+ID4KPiA+Cj4gPiAgICBJdCBpcyB1
bmNsZWFyIHRvIG1lIHdoZXRoZXIgdGhleToKPiA+IAktIHdhbnQgdG8gYmUgdGhlIG1haW50YWlu
ZXJzIG9mIGl0Pwo+ID4gCS0gd2FudCB0byB1c2UgYmxrdGFwMyBidXQgaGF2ZW4ndCB5ZXQgYmFj
a3BvcnRlZCB0aGVpciBwYXRjaGVzLgo+IAo+IFRoZSByZW11cyBwYXRjaGVzIGFyZSBhZ2FpbnN0
IGJsa3RhcDIsIG5vdCBibGt0YXAxLiAgV2UgY3VycmVudGx5IGhhdmUKPiBib3RoIGluLXRyZWUu
Cgo8c2xhcHMgaGlzIGhlYWQ+CgpPSywgc28gYmxrdGFwMSAtIGRlYWQuIFRoYXQgbG9va3MgbGlr
ZSBpdCBjb3VsZCBnbyB1bmRlciB0aGUga25pZmUgbm93LgoKYmxrdGFwMiAtIHdhaXRpbmcgZm9y
IHJlc3BvbnNlCgpJcyB0aGUgbG9uZy10ZXJtIGlkZWEgdG8gcHV0ICdibGt0YXAzJyBpbiB0aGUg
dHJlZT8KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Nov 04 20:01:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 20:01:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlkHF-0008UG-1k; Tue, 04 Nov 2014 20:00:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XlkHC-0008UB-NH
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 20:00:26 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	15/51-09284-95039545; Tue, 04 Nov 2014 20:00:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415131223!7204659!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1870 invoked from network); 4 Nov 2014 20:00:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 20:00:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4K09Mu000490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 20:00:10 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4K07oS029964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 20:00:08 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4K07Tt029940; Tue, 4 Nov 2014 20:00:07 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 12:00:07 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2AF511108AB; Tue,  4 Nov 2014 15:00:06 -0500 (EST)
Date: Tue, 4 Nov 2014 15:00:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141104200006.GD12464@laptop.dumpdata.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
	<54591EB8.4070007@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54591EB8.4070007@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: wei.liu2@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	guijianfeng@cn.fujitsu.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMDY6NDU6MTJQTSArMDAwMCwgQW5kcmV3IENvb3BlciB3
cm90ZToKPiBPbiAwNC8xMS8xNCAxODo0MiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+
ID4gT24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMDY6MDc6MTlQTSArMDAwMCwgQW5kcmV3IENvb3Bl
ciB3cm90ZToKPiA+PiBPbiAwNC8xMS8xNCAxNzozMiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdy
b3RlOgo+ID4+PiBPbiBUdWUsIE5vdiAwNCwgMjAxNCBhdCAxMTo1Mjo0N0FNICswMDAwLCBJYW4g
Q2FtcGJlbGwgd3JvdGU6Cj4gPj4+PiBUaGlzIHdhcyBkaXNhYmxlZCBieSBkZWZhdWx0IGluIFhl
biA0LjQuIFNpbmNlIHhlbmQgaGFzIG5vdyBiZWVuIHJlbW92ZWQgZnJvbQo+ID4+Pj4gdGhlIHRy
ZWUgSSBkb24ndCBiZWxpZXZlIGFueXRoaW5nIGlzIHVzaW5nIGl0Lgo+ID4+PiBXaGF0IGFib3V0
IFhlblNlcnZlcj8KPiA+PiBXZSBhcmUgbW9zdCBkZWZpbml0ZWx5IG5vdCB1c2luZyBpdCwgYW5k
IGhhdmVu4oCZdCB1c2VkIGl0IGluIGEgdmVyeSBsb25nCj4gPj4gdGltZS4gV2UgZXhwbGljaXRs
eSBudWtlIEJMS1RBUDEgYW5kIEJMS1RBUDIgZnJvbSB0aGUgWGVuIGJ1aWxkLgo+ID4+Cj4gPj4+
IEFuZCBpc24ndCB0aGVyZSBzb21lIGJsa3RhcDMgPwo+ID4+IGh0dHBzOi8vZ2l0aHViLmNvbS94
YXBpLXByb2plY3QvYmxrdGFwCj4gPj4KPiA+Pj4+IFdlIG5lZWQgdG8gcGFzcyBhbiBleHBsaWNp
dCBDT05GSUdfQkxLVEFQMT1uIHRvIHFlbXUteGVuLXRyYWRpdGlvbmFsIG90aGVyd2lzZQo+ID4+
Pj4gaXQgZGVmYXVsdHMgdG8geSBhbmQgZG9lc24ndCBidWlsZC4KPiA+Pj4+Cj4gPj4+PiBTaWdu
ZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+ID4+Pj4g
Q2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPiA+Pj4+
IC0tLQo+ID4+Pj4gSSB0aGluayB0aGlzIGhhcyBwcm9iYWJseSBtaXNzZWQgdGhlIGJvYXQgZm9y
IDQuNSBhbmQgdGhlcmUgaXNuJ3QgbXVjaCBoYXJtIGluCj4gPj4+PiB3YWl0aW5nIGZvciA0LjYu
IEknbSBvcGVuIHRvIGJlaW5nIHRvbGQgb3RoZXJ3aXNlIHRob3VnaCA7LSkKPiA+Pj4gWW91IHJl
YWxseSB3YW50IHRvIGJlIGF0IHRoZSB0b3Agb2YgdGhlIGNvbW1pdCBsaXN0IHdpdGggdGhlIG1v
c3QgZGVsZXRlZAo+ID4+PiBjb2RlLCBlaD8KPiA+PiAvbWUgc3VzcGVjdHMgdGhhdCBoZSBpcyBh
bHJlYWR5LCBidXQgSSBmb3Igb25lIGFtIGEgZmFuIG9mIHBydW5pbmcgZGVhZAo+ID4+IGNvZGUu
Cj4gPiBUcnVlLCBidXQgd2UgZGlkIHRhbGsgYWJvdXQgeGVuZCByZW1vdmFsIGZvciBxdWl0ZSBh
IHdoaWxlIGJlZm9yZSBkb2luZyBpdC4KPiA+Cj4gPiBIb3dldmVyLCBJIGJlbGlldmUgdGhhdCB0
aGUgZm9sa3MgdGhhdCBkaWQgUmVtdXMgbG9vayB0byBiZSB1c2luZyBpdAo+ID4gKEFuZCB0aGV5
IGhhdmUgdG9ucyBvZiBwYXRjaGVzIGFnYWluc3QgaXQpLgo+ID4KPiA+Cj4gPiAgICBJdCBpcyB1
bmNsZWFyIHRvIG1lIHdoZXRoZXIgdGhleToKPiA+IAktIHdhbnQgdG8gYmUgdGhlIG1haW50YWlu
ZXJzIG9mIGl0Pwo+ID4gCS0gd2FudCB0byB1c2UgYmxrdGFwMyBidXQgaGF2ZW4ndCB5ZXQgYmFj
a3BvcnRlZCB0aGVpciBwYXRjaGVzLgo+IAo+IFRoZSByZW11cyBwYXRjaGVzIGFyZSBhZ2FpbnN0
IGJsa3RhcDIsIG5vdCBibGt0YXAxLiAgV2UgY3VycmVudGx5IGhhdmUKPiBib3RoIGluLXRyZWUu
Cgo8c2xhcHMgaGlzIGhlYWQ+CgpPSywgc28gYmxrdGFwMSAtIGRlYWQuIFRoYXQgbG9va3MgbGlr
ZSBpdCBjb3VsZCBnbyB1bmRlciB0aGUga25pZmUgbm93LgoKYmxrdGFwMiAtIHdhaXRpbmcgZm9y
IHJlc3BvbnNlCgpJcyB0aGUgbG9uZy10ZXJtIGlkZWEgdG8gcHV0ICdibGt0YXAzJyBpbiB0aGUg
dHJlZT8KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Nov 04 20:20:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 20:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlkZs-0000ZU-9W; Tue, 04 Nov 2014 20:19:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlkZq-0000ZP-HS
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 20:19:42 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	CA/12-02953-DD439545; Tue, 04 Nov 2014 20:19:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415132378!12544467!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5399 invoked from network); 4 Nov 2014 20:19:41 -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;
	4 Nov 2014 20:19:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,314,1413244800"; d="scan'208";a="188077473"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 15:19:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlkZi-0008CZ-Gz;
	Tue, 04 Nov 2014 20:19:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlkZi-00070r-A7;
	Tue, 04 Nov 2014 20:19:34 +0000
Date: Tue, 4 Nov 2014 20:19:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31358-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31358: 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 31358 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31358/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31338
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31338

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass

version targeted for testing:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c
baseline version:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Nov 04 20:20:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 20:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlkZs-0000ZU-9W; Tue, 04 Nov 2014 20:19:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlkZq-0000ZP-HS
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 20:19:42 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	CA/12-02953-DD439545; Tue, 04 Nov 2014 20:19:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415132378!12544467!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5399 invoked from network); 4 Nov 2014 20:19:41 -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;
	4 Nov 2014 20:19:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,314,1413244800"; d="scan'208";a="188077473"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 15:19:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlkZi-0008CZ-Gz;
	Tue, 04 Nov 2014 20:19:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlkZi-00070r-A7;
	Tue, 04 Nov 2014 20:19:34 +0000
Date: Tue, 4 Nov 2014 20:19:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31358-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31358: 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 31358 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31358/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31338
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31338

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass

version targeted for testing:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c
baseline version:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Nov 04 21:10:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21: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 1XllMk-0001WK-Ql; Tue, 04 Nov 2014 21:10:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1XllMg-0001WF-IB
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 21:10:13 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	7A/FC-11581-1B049545; Tue, 04 Nov 2014 21:10:09 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415135407!11195846!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8927 invoked from network); 4 Nov 2014 21:10:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 21:10:08 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4L9w03021910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 21:09:59 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4L9vUi006741
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 21:09:58 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4L9v0k011776; Tue, 4 Nov 2014 21:09:57 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 13:09:57 -0800
Date: Tue, 4 Nov 2014 22:09:51 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141104210951.GJ16923@olila.local.net-space.pl>
References: <1415075851-8987-1-git-send-email-roy.franz@linaro.org>
	<20141104115733.GG16923@olila.local.net-space.pl>
	<CAFECyb83ZgB73jCg1EcuWpTaXtcWLMjBeLbcyygiwVfGXGXLKA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFECyb83ZgB73jCg1EcuWpTaXtcWLMjBeLbcyygiwVfGXGXLKA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Campbell <ian.campbell@citrix.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 V2] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 10:46:15AM -0800, Roy Franz wrote:
> On Tue, Nov 4, 2014 at 3:57 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > On Mon, Nov 03, 2014 at 08:37:31PM -0800, Roy Franz wrote:
> >> Update EFI code to completely ignore the EFI comnandline when booted from GRUB.
> >> Previusly it was parsed of EFI boot specific options, but these aren't used
> >> when booted from GRUB.
> >>
> >> Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
> >> code does some console and video initialization to support native EFI boot from
> >> the EFI boot manager or EFI shell.  This initlization should not be done when
> >> booted using GRUB.
> >>
> >> Update EFI documentation to indicate that it describes EFI native boot, and
> >> does not apply at all when Xen is booted using GRUB.
> >>
> >> Signed-off-by: Roy Franz <roy.franz@linaro.org>
> >
> > In general Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> but...
> >
> >> ---
> >> This patch implements what I understand to be the desired behavior when booting
> >> an EFI Xen image via GRUB based on the thread last week.  The EFI command line
> >> is not used, and the Xen commandline comes via the multiboot protocol (and
> >> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
> >> GRUB EFI boot cases into alignment in not using the EFI commandline.
> >>
> >> The current state of the arm64 code takes the Xen commandline from the FDT,
> >> but still looks in the EFI commandline for EFI boot specific options.  If
> >> unexpected options are passed in the EFI commandline, it will generate
> >> "unrecognized option" ouput for all unexpected options.
> >>
> >> I think this should be considered for 4.5.
> >>
> >> Changes from v1:
> >> * Fixed style, and removed blank line changes
> >> * Reviewed scope of variables now that more code is in if ( use_cfg_file ) block
> >>
> >>
> >>  docs/misc/efi.markdown |   5 ++
> >>  xen/common/efi/boot.c  | 240 +++++++++++++++++++++++++------------------------
> >>  2 files changed, 128 insertions(+), 117 deletions(-)
> >>
> >> diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
> >> index 5e48aa3..f435ec7 100644
> >> --- a/docs/misc/efi.markdown
> >> +++ b/docs/misc/efi.markdown
> >> @@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
> >>  (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
> >>  try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
> >>  order.) One can override this with a command line option (`-cfg=<filename>`).
> >> +This configuration file and EFI commandline are only used for booting directly
> >> +from EFI firmware, or when using an EFI loader that does not support
> >> +the multiboot2 protocol.  When booting using GRUB or another multiboot aware
> >> +loader the EFI commandline is ignored and all information is passed from
> >> +the loader to Xen using the multiboot protocol.
> >
> > First you are referring to multiboot2 and later you are talking about
> > multiboot. It makes some confusion. Could you put full stop after "...
> > using an EFI loader" or rephrase this sentences in another way to make
> > them clear?
> >
> > Daniel
> I think all references should be multiboot2.  I do really want
> something that is clear
> to most readers.
>
> How about:
>
> "This configuration file and EFI commandline are only used for booting directly
> from EFI firmware, or when using an EFI loader. When booting using GRUB or
> another multiboot2 aware loader the EFI commandline is ignored and all information
> is passed from the loader to Xen using the multiboot protocol."

Much better but right now it indirectly suggest that multiboot2 protocol is available
on all platforms including x86 which is not true (at least now). Additionally, I am
a bit confused about multiboot protocol naming on ARM64. It looks that
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
calls it multiboot. You say multiboot2. Which one is correct?
Could you enlighten me?

> Would it be helpful to list an example EFI loader, such as gummiboot?
>
> "... or when using an EFI loader (such as gummiboot.)  When booting using GRUB"

Yes, please. Hmmm... Should not we use "simple EFI application loader"
instead of "EFI loader"?

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:10:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21: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 1XllMk-0001WK-Ql; Tue, 04 Nov 2014 21:10:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1XllMg-0001WF-IB
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 21:10:13 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	7A/FC-11581-1B049545; Tue, 04 Nov 2014 21:10:09 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415135407!11195846!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8927 invoked from network); 4 Nov 2014 21:10:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 21:10:08 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4L9w03021910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 21:09:59 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4L9vUi006741
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 21:09:58 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4L9v0k011776; Tue, 4 Nov 2014 21:09:57 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 13:09:57 -0800
Date: Tue, 4 Nov 2014 22:09:51 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141104210951.GJ16923@olila.local.net-space.pl>
References: <1415075851-8987-1-git-send-email-roy.franz@linaro.org>
	<20141104115733.GG16923@olila.local.net-space.pl>
	<CAFECyb83ZgB73jCg1EcuWpTaXtcWLMjBeLbcyygiwVfGXGXLKA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFECyb83ZgB73jCg1EcuWpTaXtcWLMjBeLbcyygiwVfGXGXLKA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Campbell <ian.campbell@citrix.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 V2] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 10:46:15AM -0800, Roy Franz wrote:
> On Tue, Nov 4, 2014 at 3:57 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > On Mon, Nov 03, 2014 at 08:37:31PM -0800, Roy Franz wrote:
> >> Update EFI code to completely ignore the EFI comnandline when booted from GRUB.
> >> Previusly it was parsed of EFI boot specific options, but these aren't used
> >> when booted from GRUB.
> >>
> >> Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
> >> code does some console and video initialization to support native EFI boot from
> >> the EFI boot manager or EFI shell.  This initlization should not be done when
> >> booted using GRUB.
> >>
> >> Update EFI documentation to indicate that it describes EFI native boot, and
> >> does not apply at all when Xen is booted using GRUB.
> >>
> >> Signed-off-by: Roy Franz <roy.franz@linaro.org>
> >
> > In general Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> but...
> >
> >> ---
> >> This patch implements what I understand to be the desired behavior when booting
> >> an EFI Xen image via GRUB based on the thread last week.  The EFI command line
> >> is not used, and the Xen commandline comes via the multiboot protocol (and
> >> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
> >> GRUB EFI boot cases into alignment in not using the EFI commandline.
> >>
> >> The current state of the arm64 code takes the Xen commandline from the FDT,
> >> but still looks in the EFI commandline for EFI boot specific options.  If
> >> unexpected options are passed in the EFI commandline, it will generate
> >> "unrecognized option" ouput for all unexpected options.
> >>
> >> I think this should be considered for 4.5.
> >>
> >> Changes from v1:
> >> * Fixed style, and removed blank line changes
> >> * Reviewed scope of variables now that more code is in if ( use_cfg_file ) block
> >>
> >>
> >>  docs/misc/efi.markdown |   5 ++
> >>  xen/common/efi/boot.c  | 240 +++++++++++++++++++++++++------------------------
> >>  2 files changed, 128 insertions(+), 117 deletions(-)
> >>
> >> diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
> >> index 5e48aa3..f435ec7 100644
> >> --- a/docs/misc/efi.markdown
> >> +++ b/docs/misc/efi.markdown
> >> @@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
> >>  (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
> >>  try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
> >>  order.) One can override this with a command line option (`-cfg=<filename>`).
> >> +This configuration file and EFI commandline are only used for booting directly
> >> +from EFI firmware, or when using an EFI loader that does not support
> >> +the multiboot2 protocol.  When booting using GRUB or another multiboot aware
> >> +loader the EFI commandline is ignored and all information is passed from
> >> +the loader to Xen using the multiboot protocol.
> >
> > First you are referring to multiboot2 and later you are talking about
> > multiboot. It makes some confusion. Could you put full stop after "...
> > using an EFI loader" or rephrase this sentences in another way to make
> > them clear?
> >
> > Daniel
> I think all references should be multiboot2.  I do really want
> something that is clear
> to most readers.
>
> How about:
>
> "This configuration file and EFI commandline are only used for booting directly
> from EFI firmware, or when using an EFI loader. When booting using GRUB or
> another multiboot2 aware loader the EFI commandline is ignored and all information
> is passed from the loader to Xen using the multiboot protocol."

Much better but right now it indirectly suggest that multiboot2 protocol is available
on all platforms including x86 which is not true (at least now). Additionally, I am
a bit confused about multiboot protocol naming on ARM64. It looks that
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
calls it multiboot. You say multiboot2. Which one is correct?
Could you enlighten me?

> Would it be helpful to list an example EFI loader, such as gummiboot?
>
> "... or when using an EFI loader (such as gummiboot.)  When booting using GRUB"

Yes, please. Hmmm... Should not we use "simple EFI application loader"
instead of "EFI loader"?

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:17:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21:17:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XllTT-0001pk-Rd; Tue, 04 Nov 2014 21:17:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1XllTS-0001pf-5F
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 21:17:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	21/69-24532-55249545; Tue, 04 Nov 2014 21:17:09 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415135828!12800836!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3700 invoked from network); 4 Nov 2014 21:17:08 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-7.tower-21.messagelabs.com with SMTP;
	4 Nov 2014 21:17:08 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 04CFE583E09;
	Tue,  4 Nov 2014 13:17:05 -0800 (PST)
Date: Tue, 04 Nov 2014 16:17:04 -0500 (EST)
Message-Id: <20141104.161704.1690311989900127361.davem@davemloft.net>
To: zoltan.kiss@linaro.org
From: David Miller <davem@davemloft.net>
In-Reply-To: <5457C807.5080509@linaro.org>
References: <1415036346.1411.3.camel@citrix.com> <5457BF80.2000205@citrix.com>
	<5457C807.5080509@linaro.org>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Tue, 04 Nov 2014 13:17:07 -0800 (PST)
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, netdev@vger.kernel.org,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	malcolm.crossley@citrix.com
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@linaro.org>
Date: Mon, 03 Nov 2014 18:23:03 +0000

> 
> 
> On 03/11/14 17:46, David Vrabel wrote:
>> On 03/11/14 17:39, Ian Campbell wrote:
>>> On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
>>>> From: Malcolm Crossley <malcolm.crossley@citrix.com>
>>>>
>>>> Unconditionally pulling 128 bytes into the linear buffer is not
>>>> required. Netback has already grant copied up-to 128 bytes from the
>>>> first slot of a packet into the linear buffer. The first slot normally
>>>> contain all the IPv4/IPv6 and TCP/UDP headers.
>>>
>>> What about when it doesn't? It sounds as if we now won't pull up,
>>> which
>>> would be bad.
>>
>> The network stack will always pull any headers it needs to inspect
>> (the
>> frag may be a userspace page which has the same security issues as a
>> frag with a foreign page).
> I wouldn't bet my life on this, but indeed it should always happen.

I would bet my life on it.

Every protocol demux starts with pskb_may_pull() to pull frag data
into the linear area, if necessary, before looking at headers.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:17:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21:17:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XllTT-0001pk-Rd; Tue, 04 Nov 2014 21:17:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1XllTS-0001pf-5F
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 21:17:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	21/69-24532-55249545; Tue, 04 Nov 2014 21:17:09 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415135828!12800836!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3700 invoked from network); 4 Nov 2014 21:17:08 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-7.tower-21.messagelabs.com with SMTP;
	4 Nov 2014 21:17:08 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 04CFE583E09;
	Tue,  4 Nov 2014 13:17:05 -0800 (PST)
Date: Tue, 04 Nov 2014 16:17:04 -0500 (EST)
Message-Id: <20141104.161704.1690311989900127361.davem@davemloft.net>
To: zoltan.kiss@linaro.org
From: David Miller <davem@davemloft.net>
In-Reply-To: <5457C807.5080509@linaro.org>
References: <1415036346.1411.3.camel@citrix.com> <5457BF80.2000205@citrix.com>
	<5457C807.5080509@linaro.org>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Tue, 04 Nov 2014 13:17:07 -0800 (PST)
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, netdev@vger.kernel.org,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	malcolm.crossley@citrix.com
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@linaro.org>
Date: Mon, 03 Nov 2014 18:23:03 +0000

> 
> 
> On 03/11/14 17:46, David Vrabel wrote:
>> On 03/11/14 17:39, Ian Campbell wrote:
>>> On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
>>>> From: Malcolm Crossley <malcolm.crossley@citrix.com>
>>>>
>>>> Unconditionally pulling 128 bytes into the linear buffer is not
>>>> required. Netback has already grant copied up-to 128 bytes from the
>>>> first slot of a packet into the linear buffer. The first slot normally
>>>> contain all the IPv4/IPv6 and TCP/UDP headers.
>>>
>>> What about when it doesn't? It sounds as if we now won't pull up,
>>> which
>>> would be bad.
>>
>> The network stack will always pull any headers it needs to inspect
>> (the
>> frag may be a userspace page which has the same security issues as a
>> frag with a foreign page).
> I wouldn't bet my life on this, but indeed it should always happen.

I would bet my life on it.

Every protocol demux starts with pskb_may_pull() to pull frag data
into the linear area, if necessary, before looking at headers.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:18:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21:18:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XllUK-0001sx-AP; Tue, 04 Nov 2014 21:18:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1XllUI-0001sm-VQ
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 21:18:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4E/22-09842-A8249545; Tue, 04 Nov 2014 21:18:02 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415135880!12760757!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19910 invoked from network); 4 Nov 2014 21:18:01 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 21:18:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4LHqvm032073
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 21:17:53 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4LHp1w029478
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 21:17:52 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4LHp78029447; Tue, 4 Nov 2014 21:17:51 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 13:17:50 -0800
Date: Tue, 4 Nov 2014 22:17:45 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141104211745.GK16923@olila.local.net-space.pl>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
	<CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
	<5458932F0200007800044A4E@mail.emea.novell.com>
	<CAFECyb9Z=YBXhn6xmutp0iV2JNQUbpw3FA=GT4QgSYPwvY9ksw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFECyb9Z=YBXhn6xmutp0iV2JNQUbpw3FA=GT4QgSYPwvY9ksw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Campbell <ian.campbell@citrix.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 10:39:53AM -0800, Roy Franz wrote:
> On Mon, Nov 3, 2014 at 11:49 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>> On 04.11.14 at 05:31, <roy.franz@linaro.org> wrote:
> >> On Mon, Nov 3, 2014 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
> >>>> This patch implements what I understand to be the desired behavior when
> >>>> booting
> >>>> an EFI Xen image via GRUB based on the thread last week.  The EFI command
> >>>> line
> >>>> is not used, and the Xen commandline comes via the multiboot protocol (and
> >>>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
> >>>> GRUB EFI boot cases into alignment in not using the EFI commandline.
> >>>
> >>> Right, but ...
> >>>
> >>>> The current state of the arm64 code takes the Xen commandline from the FDT,
> >>>> but still looks in the EFI commandline for EFI boot specific options.  If
> >>>> unexpected options are passed in the EFI commandline, it will generate
> >>>> "unrecognized option" ouput for all unexpected options.
> >>>
> >>> ... why is this?
> >>
> >> The EFI boot code did this before any of the arm64 changes, and that
> >> behavior is unchanged.
> >> The actual message is "WARNING: Unknown command line option"
> >>
> >> I was simply trying to explain the current behavior regarding the EFI
> >> commandline.
> >
> > Argh, I should have stripped that second sentence from the quoted
> > context, as the question was regarding the apparently special ARM64
> > behavior you describe.
>
> >>>> The current state of the arm64 code takes the Xen commandline from the FDT,
> >>>> but still looks in the EFI commandline for EFI boot specific options.
> OK, I'll try address the above.  This behavior is the "no config file
> case", which only
> exists on arm64 - x86 always uses a config file when booted as an EFI
> application, since
> for x86 GRUB does execute Xen as en EFI application when using multiboot2.

I have a feeling that you wrote that by mistake. As I said in my earlier emails
multiboot2 on x86 EFI platform will not load EFI application as an EFI application.

> The case of being executed as an EFI application, loaded by GRUB and provided
> module information via the multiboot2 (in FDT) protocol is unique to
> arm64.  All the code
> is common code, but since efi_arch_use_config_file() is always true
> for x86 the case
> described only applies to arm64.

Right now it is true. Probably it will change after introducing
multiboot2 protocol on x86.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:18:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21:18:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XllUK-0001sx-AP; Tue, 04 Nov 2014 21:18:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1XllUI-0001sm-VQ
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 21:18:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4E/22-09842-A8249545; Tue, 04 Nov 2014 21:18:02 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415135880!12760757!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19910 invoked from network); 4 Nov 2014 21:18:01 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 21:18:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4LHqvm032073
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 21:17:53 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4LHp1w029478
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 4 Nov 2014 21:17:52 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4LHp78029447; Tue, 4 Nov 2014 21:17:51 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 13:17:50 -0800
Date: Tue, 4 Nov 2014 22:17:45 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141104211745.GK16923@olila.local.net-space.pl>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
	<CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
	<5458932F0200007800044A4E@mail.emea.novell.com>
	<CAFECyb9Z=YBXhn6xmutp0iV2JNQUbpw3FA=GT4QgSYPwvY9ksw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFECyb9Z=YBXhn6xmutp0iV2JNQUbpw3FA=GT4QgSYPwvY9ksw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Campbell <ian.campbell@citrix.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 10:39:53AM -0800, Roy Franz wrote:
> On Mon, Nov 3, 2014 at 11:49 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>> On 04.11.14 at 05:31, <roy.franz@linaro.org> wrote:
> >> On Mon, Nov 3, 2014 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
> >>>> This patch implements what I understand to be the desired behavior when
> >>>> booting
> >>>> an EFI Xen image via GRUB based on the thread last week.  The EFI command
> >>>> line
> >>>> is not used, and the Xen commandline comes via the multiboot protocol (and
> >>>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
> >>>> GRUB EFI boot cases into alignment in not using the EFI commandline.
> >>>
> >>> Right, but ...
> >>>
> >>>> The current state of the arm64 code takes the Xen commandline from the FDT,
> >>>> but still looks in the EFI commandline for EFI boot specific options.  If
> >>>> unexpected options are passed in the EFI commandline, it will generate
> >>>> "unrecognized option" ouput for all unexpected options.
> >>>
> >>> ... why is this?
> >>
> >> The EFI boot code did this before any of the arm64 changes, and that
> >> behavior is unchanged.
> >> The actual message is "WARNING: Unknown command line option"
> >>
> >> I was simply trying to explain the current behavior regarding the EFI
> >> commandline.
> >
> > Argh, I should have stripped that second sentence from the quoted
> > context, as the question was regarding the apparently special ARM64
> > behavior you describe.
>
> >>>> The current state of the arm64 code takes the Xen commandline from the FDT,
> >>>> but still looks in the EFI commandline for EFI boot specific options.
> OK, I'll try address the above.  This behavior is the "no config file
> case", which only
> exists on arm64 - x86 always uses a config file when booted as an EFI
> application, since
> for x86 GRUB does execute Xen as en EFI application when using multiboot2.

I have a feeling that you wrote that by mistake. As I said in my earlier emails
multiboot2 on x86 EFI platform will not load EFI application as an EFI application.

> The case of being executed as an EFI application, loaded by GRUB and provided
> module information via the multiboot2 (in FDT) protocol is unique to
> arm64.  All the code
> is common code, but since efi_arch_use_config_file() is always true
> for x86 the case
> described only applies to arm64.

Right now it is true. Probably it will change after introducing
multiboot2 protocol on x86.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:41:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21:41:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xllqr-0002cc-PY; Tue, 04 Nov 2014 21:41:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Xllqq-0002cX-QZ
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 21:41:20 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	93/10-31453-00849545; Tue, 04 Nov 2014 21:41:20 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415137278!8331910!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12917 invoked from network); 4 Nov 2014 21:41:19 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-16.tower-206.messagelabs.com with SMTP;
	4 Nov 2014 21:41:19 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 9DD6C583FE9;
	Tue,  4 Nov 2014 13:41:17 -0800 (PST)
Date: Tue, 04 Nov 2014 16:41:13 -0500 (EST)
Message-Id: <20141104.164113.2265592775058059992.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Tue, 04 Nov 2014 13:41:18 -0800 (PST)
Cc: netdev@vger.kernel.org, malcolm.crossley@citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 3 Nov 2014 17:23:51 +0000

> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> 
> Unconditionally pulling 128 bytes into the linear buffer is not
> required. Netback has already grant copied up-to 128 bytes from the
> first slot of a packet into the linear buffer. The first slot normally
> contain all the IPv4/IPv6 and TCP/UDP headers.
> 
> The unconditional pull would often copy frag data unnecessarily.  This
> is a performance problem when running on a version of Xen where grant
> unmap avoids TLB flushes for pages which are not accessed.  TLB
> flushes can now be avoided for > 99% of unmaps (it was 0% before).
> 
> Grant unmap TLB flush avoidance will be available in a future version
> of Xen (probably 4.6).
> 
> Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Now that this has been discussed a bit, it is possible to get an ack or two?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:41:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21:41:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xllqr-0002cc-PY; Tue, 04 Nov 2014 21:41:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Xllqq-0002cX-QZ
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 21:41:20 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	93/10-31453-00849545; Tue, 04 Nov 2014 21:41:20 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415137278!8331910!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12917 invoked from network); 4 Nov 2014 21:41:19 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-16.tower-206.messagelabs.com with SMTP;
	4 Nov 2014 21:41:19 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 9DD6C583FE9;
	Tue,  4 Nov 2014 13:41:17 -0800 (PST)
Date: Tue, 04 Nov 2014 16:41:13 -0500 (EST)
Message-Id: <20141104.164113.2265592775058059992.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Tue, 04 Nov 2014 13:41:18 -0800 (PST)
Cc: netdev@vger.kernel.org, malcolm.crossley@citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 3 Nov 2014 17:23:51 +0000

> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> 
> Unconditionally pulling 128 bytes into the linear buffer is not
> required. Netback has already grant copied up-to 128 bytes from the
> first slot of a packet into the linear buffer. The first slot normally
> contain all the IPv4/IPv6 and TCP/UDP headers.
> 
> The unconditional pull would often copy frag data unnecessarily.  This
> is a performance problem when running on a version of Xen where grant
> unmap avoids TLB flushes for pages which are not accessed.  TLB
> flushes can now be avoided for > 99% of unmaps (it was 0% before).
> 
> Grant unmap TLB flush avoidance will be available in a future version
> of Xen (probably 4.6).
> 
> Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Now that this has been discussed a bit, it is possible to get an ack or two?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:43:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xllsq-0002hg-As; Tue, 04 Nov 2014 21:43:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Xllso-0002hY-E3
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 21:43:22 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	CA/74-18267-97849545; Tue, 04 Nov 2014 21:43:21 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415137399!11598176!1
X-Originating-IP: [209.85.213.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28005 invoked from network); 4 Nov 2014 21:43:20 -0000
Received: from mail-ig0-f169.google.com (HELO mail-ig0-f169.google.com)
	(209.85.213.169)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 21:43:20 -0000
Received: by mail-ig0-f169.google.com with SMTP id hn18so7222860igb.4
	for <xen-devel@lists.xenproject.org>;
	Tue, 04 Nov 2014 13:43:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:mime-version:content-transfer-encoding;
	bh=uK3lIhFzBVW8hNZOJfwUerbEalY/5gqQnXV7jdVJxOk=;
	b=ymTBXc8YzgCVdZqUElkMncrhrG7KFCYgITWF2Si9OfdOWkKuTY1YrxFR1TSUUAvxOq
	jAn6zp6gtU0OM8B9ixZBMrI6nlyopOpJugwzdjuOtoJ6l/wnHB7Id/cGYALRV1Vf27L8
	lrk0aq4HGeEvyVmPT9MSrBx1PohTemx8LG1tdz58/nwgfQyUFTBe64SrwpmnbSnvrIQ3
	utOEuBhPkZAyTOMNT2NAPHK0zfdEsvDiivJl3XqvGLb1M5oWQIy8KI59B3eIfuqSfzZe
	drztx1UDO/3K2AwVvOAevJmv6xus98AC/z5Fk5WtdJCzdi2Cizy5X0QcyCMq7T3uAQfi
	qkWw==
X-Received: by 10.50.40.100 with SMTP id w4mr26645659igk.29.1415137399644;
	Tue, 04 Nov 2014 13:43:19 -0800 (PST)
Received: from [172.19.245.200] ([172.19.245.200])
	by mx.google.com with ESMTPSA id ro6sm847471igb.3.2014.11.04.13.43.18
	for <multiple recipients>
	(version=SSLv3 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 13:43:19 -0800 (PST)
Message-ID: <1415137397.25370.7.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Miller <davem@davemloft.net>
Date: Tue, 04 Nov 2014 13:43:17 -0800
In-Reply-To: <20141104.161704.1690311989900127361.davem@davemloft.net>
References: <1415036346.1411.3.camel@citrix.com>
	<5457BF80.2000205@citrix.com> <5457C807.5080509@linaro.org>
	<20141104.161704.1690311989900127361.davem@davemloft.net>
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Cc: zoltan.kiss@linaro.org, wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	netdev@vger.kernel.org, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, malcolm.crossley@citrix.com
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 16:17 -0500, David Miller wrote:


> 
> Every protocol demux starts with pskb_may_pull() to pull frag data
> into the linear area, if necessary, before looking at headers.

eth_get_headlen() might be relevant as well, to perform a single copy of
exactly all headers.

This is known to help a bit.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:43:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xllsq-0002hg-As; Tue, 04 Nov 2014 21:43:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Xllso-0002hY-E3
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 21:43:22 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	CA/74-18267-97849545; Tue, 04 Nov 2014 21:43:21 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415137399!11598176!1
X-Originating-IP: [209.85.213.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28005 invoked from network); 4 Nov 2014 21:43:20 -0000
Received: from mail-ig0-f169.google.com (HELO mail-ig0-f169.google.com)
	(209.85.213.169)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 21:43:20 -0000
Received: by mail-ig0-f169.google.com with SMTP id hn18so7222860igb.4
	for <xen-devel@lists.xenproject.org>;
	Tue, 04 Nov 2014 13:43:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:mime-version:content-transfer-encoding;
	bh=uK3lIhFzBVW8hNZOJfwUerbEalY/5gqQnXV7jdVJxOk=;
	b=ymTBXc8YzgCVdZqUElkMncrhrG7KFCYgITWF2Si9OfdOWkKuTY1YrxFR1TSUUAvxOq
	jAn6zp6gtU0OM8B9ixZBMrI6nlyopOpJugwzdjuOtoJ6l/wnHB7Id/cGYALRV1Vf27L8
	lrk0aq4HGeEvyVmPT9MSrBx1PohTemx8LG1tdz58/nwgfQyUFTBe64SrwpmnbSnvrIQ3
	utOEuBhPkZAyTOMNT2NAPHK0zfdEsvDiivJl3XqvGLb1M5oWQIy8KI59B3eIfuqSfzZe
	drztx1UDO/3K2AwVvOAevJmv6xus98AC/z5Fk5WtdJCzdi2Cizy5X0QcyCMq7T3uAQfi
	qkWw==
X-Received: by 10.50.40.100 with SMTP id w4mr26645659igk.29.1415137399644;
	Tue, 04 Nov 2014 13:43:19 -0800 (PST)
Received: from [172.19.245.200] ([172.19.245.200])
	by mx.google.com with ESMTPSA id ro6sm847471igb.3.2014.11.04.13.43.18
	for <multiple recipients>
	(version=SSLv3 cipher=RC4-SHA bits=128/128);
	Tue, 04 Nov 2014 13:43:19 -0800 (PST)
Message-ID: <1415137397.25370.7.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Miller <davem@davemloft.net>
Date: Tue, 04 Nov 2014 13:43:17 -0800
In-Reply-To: <20141104.161704.1690311989900127361.davem@davemloft.net>
References: <1415036346.1411.3.camel@citrix.com>
	<5457BF80.2000205@citrix.com> <5457C807.5080509@linaro.org>
	<20141104.161704.1690311989900127361.davem@davemloft.net>
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Cc: zoltan.kiss@linaro.org, wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	netdev@vger.kernel.org, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, malcolm.crossley@citrix.com
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 16:17 -0500, David Miller wrote:


> 
> Every protocol demux starts with pskb_may_pull() to pull frag data
> into the linear area, if necessary, before looking at headers.

eth_get_headlen() might be relevant as well, to perform a single copy of
exactly all headers.

This is known to help a bit.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:50:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21: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 1XllzQ-0002xa-LG; Tue, 04 Nov 2014 21:50:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1XllzO-0002xT-Vv
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 21:50:11 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	43/54-02559-21A49545; Tue, 04 Nov 2014 21:50:10 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415137808!12571196!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 934 invoked from network); 4 Nov 2014 21:50:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 21:50:09 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4Lo0DJ006749
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 21:50:01 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4LnxfJ016002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Nov 2014 21:49:59 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA4L1lIN008043; Tue, 4 Nov 2014 21:01:47 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 13:49:57 -0800
Date: Tue, 4 Nov 2014 22:49:52 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141104214952.GL16923@olila.local.net-space.pl>
References: <544F58770200007800042ADA@mail.emea.novell.com>
	<CAFECyb-WsRpH4ee1XE5dZdxwygH-7hy-Nw8-ZEQtJF8Wnng8wA@mail.gmail.com>
	<20141029124411.GA3467@olila.local.net-space.pl>
	<1414596400.29580.12.camel@citrix.com>
	<20141029165526.GB3467@olila.local.net-space.pl>
	<CAFECyb_Q34S=L2Sy+PvLMBkZnct7z5y-u_c0Naush3oa2qnpng@mail.gmail.com>
	<20141030175714.GF3467@olila.local.net-space.pl>
	<CAFECyb--vAVRMvHVNZKb39WSaKDO16JbkHQBi-HbL-LLx5VUoA@mail.gmail.com>
	<20141030221857.GA16923@olila.local.net-space.pl>
	<CAFECyb8cJvkrjgUcu1-mr_xBJPZOxKdrEnJ4ekD78gEK0a=5iA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFECyb8cJvkrjgUcu1-mr_xBJPZOxKdrEnJ4ekD78gEK0a=5iA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Campbell <Ian.Campbell@citrix.com>, tim <tim@xen.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH V2 for-4.5] EFI: Always use EFI command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 30, 2014 at 04:54:17PM -0700, Roy Franz wrote:
> On Thu, Oct 30, 2014 at 3:18 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > On Thu, Oct 30, 2014 at 12:29:05PM -0700, Roy Franz wrote:
> >> On Thu, Oct 30, 2014 at 10:57 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >
> > [...]
> >
> >> > If yes then I can see three solutions for this issue:
> >> >   - GRUB2 should pass e.g. --multiboot as first argument to Xen EFI
> >> >     application and after -- all arguments for Xen itself; Xen EFI app
> >> >     should not parse xen.cfg files in this case,
> >> >   - GRUB2 should pass e.g. --multiboot as first argument to Xen EFI
> >> >     application and all arguments for Xen itself (and relevant modules)
> >> >     in FDT; Xen EFI app should not parse xen.cfg files in this case too,
> >> >   - GRUB2 should pass all arguments to EFI application as is via standard
> >> >     way (as GRUB2 linux loader does on ARM64); arguments for modules should
> >> >     be passed via FDT; Xen EFI application should parse all arguments as
> >> >     regular xen.gz; -cfg option should be changed to cfg, -basevideo option
> >> >     should be changed to basevideo, etc. At first sight this looks as most
> >> >     natural thing from new multiboot protocol for ARM64 definition standpoint.
> >> >
> >> > Anyway, I think that this thing should be be described in multiboot for ARM64
> >> > spec as IanC earlier told.
> >> >
> >> > I think that this should be ARM specific solution because we will be using
> >> > multiboot2 protocol on x86 which works on completely different way. Hmmm...
> >> > Maybe third solution (excluding FDT of course), if we choose that one,
> >> > should be common thing and work on any platform including x86.
> >>
> >> The multiboot2 on x86 and the FDT on arm64 are very different, which I think
> >
> > I know.
> >
> >> confuses/complicates these discussions.  The open issue of "is the EFI command
> >
> > Yep.
> >
> >> line used to pass the Xen command line when GRUB boots EFI Xen" applies equally
> >> to x86 and arm64.  I think that consistency between x86/arm64 Xen in this regard
> >
> > No, PE image will not be executed in the same way (simple EFI application load)
> > by GRUB2 on x86 like it happens in case of GRUB2 on ARM64. It means that I will
> > not be entering directly via efi_start() to efi boot code when Xen will be started
> > by GRUB2 on x86_64 EFI platform. I am going to use separate entry point. However, I am
> > going to use most of currently existing EFI boot code too. So, as I wrote in earlier
> > email, I suppose that both paths (GRUB2 and native EFI application) will merge somewhere
> > quite quickly. However, I do not have the details right now. I am working on it.
>
> OK, this is the part I was missing.
>
> >
> >> is more important than following what Linux does, so I'm dropping that
> >> suggestion.
> >
> > OK.
> >
> >> So I'm going to propose the following which I think is in line with
> >> your 2nd option
> >> (I'm not familiar with the GRUB multiboot syntax, so it might not be),
> >> and I think
> >> is along the lines of what Jan has also suggested:
> >>
> >> When booting EFI Xen via GRUB (for both x86 and arm64):
> >> 1) the EFI command line is not used by Xen, and is ignored.
> >
> > As I said above, multiboot2 protocol on x86 does not execute PE
> > application as EFI application. It means that we do not have
> > EFI command line per se.
>
> OK, I understand now it makes things clearer.  My assumptions where
> wrong about how GRUB would start the PE Xen on x86, so I was asking questions
> that didn't really make sense.
>
> >
> >> 2) the Xen commandline is provided to Xen in the multiboot2/FDT data
> >
> > OK.
> >
> >> 3) The Xen EFI configuration file is not used
> >
> > OK.
> >
> >> 4) The EFI Xen boot code does not do any console/video or other initialization.
> >>     There is no way to provide EFI boot code specific options, as it
> >> doesn't and shouldn't
> >>     need any.
> >
> > Please see comment for 1. It means that I will skip code which parse EFI
> > application command line. Hmmm... How are you going to detect that Xen
> > was started by GRUB2 if you in both cases entering via efi_start()?
> > Maybe you should look for arguments in FDT first? Or check FDT for
> > special flag which means that EFI app was executed by GRUB? Later
> > looks better because if Xen command line will be empty then EFI
> > application will try read one of xen.cfg files.
>
> The current implementation is to examine the FDT passed to Xen to see
> if it contains any modules.  If it does, then this indicates to the
> EFI boot code
> that it is being run by a bootloader, and not directly from the EFI bootmanager
> or shell.

I think that it is wrong. I am able to imagine such situation in which
only small binary is loaded to do something specific and this binary
does not require any modules. If we do what you suggest then we must
load an additional module which will not be used by binary itself but
it just signals that binary was loaded by multiboot protocol. Not nice.
That is why I am still thinking that multiboot protocol aware loader
should put a flag in FDT telling that binary was loaded that way.

I am aware that Xen have to have at least one module (kernel image for dom0)
but I think that new protocol should be generic as much as possible and
Xen should not be its only one user.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:50:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21: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 1XllzQ-0002xa-LG; Tue, 04 Nov 2014 21:50:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1XllzO-0002xT-Vv
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 21:50:11 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	43/54-02559-21A49545; Tue, 04 Nov 2014 21:50:10 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415137808!12571196!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 934 invoked from network); 4 Nov 2014 21:50:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Nov 2014 21:50:09 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA4Lo0DJ006749
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Nov 2014 21:50:01 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA4LnxfJ016002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Nov 2014 21:49:59 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA4L1lIN008043; Tue, 4 Nov 2014 21:01:47 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Nov 2014 13:49:57 -0800
Date: Tue, 4 Nov 2014 22:49:52 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141104214952.GL16923@olila.local.net-space.pl>
References: <544F58770200007800042ADA@mail.emea.novell.com>
	<CAFECyb-WsRpH4ee1XE5dZdxwygH-7hy-Nw8-ZEQtJF8Wnng8wA@mail.gmail.com>
	<20141029124411.GA3467@olila.local.net-space.pl>
	<1414596400.29580.12.camel@citrix.com>
	<20141029165526.GB3467@olila.local.net-space.pl>
	<CAFECyb_Q34S=L2Sy+PvLMBkZnct7z5y-u_c0Naush3oa2qnpng@mail.gmail.com>
	<20141030175714.GF3467@olila.local.net-space.pl>
	<CAFECyb--vAVRMvHVNZKb39WSaKDO16JbkHQBi-HbL-LLx5VUoA@mail.gmail.com>
	<20141030221857.GA16923@olila.local.net-space.pl>
	<CAFECyb8cJvkrjgUcu1-mr_xBJPZOxKdrEnJ4ekD78gEK0a=5iA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFECyb8cJvkrjgUcu1-mr_xBJPZOxKdrEnJ4ekD78gEK0a=5iA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Campbell <Ian.Campbell@citrix.com>, tim <tim@xen.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH V2 for-4.5] EFI: Always use EFI command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 30, 2014 at 04:54:17PM -0700, Roy Franz wrote:
> On Thu, Oct 30, 2014 at 3:18 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > On Thu, Oct 30, 2014 at 12:29:05PM -0700, Roy Franz wrote:
> >> On Thu, Oct 30, 2014 at 10:57 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >
> > [...]
> >
> >> > If yes then I can see three solutions for this issue:
> >> >   - GRUB2 should pass e.g. --multiboot as first argument to Xen EFI
> >> >     application and after -- all arguments for Xen itself; Xen EFI app
> >> >     should not parse xen.cfg files in this case,
> >> >   - GRUB2 should pass e.g. --multiboot as first argument to Xen EFI
> >> >     application and all arguments for Xen itself (and relevant modules)
> >> >     in FDT; Xen EFI app should not parse xen.cfg files in this case too,
> >> >   - GRUB2 should pass all arguments to EFI application as is via standard
> >> >     way (as GRUB2 linux loader does on ARM64); arguments for modules should
> >> >     be passed via FDT; Xen EFI application should parse all arguments as
> >> >     regular xen.gz; -cfg option should be changed to cfg, -basevideo option
> >> >     should be changed to basevideo, etc. At first sight this looks as most
> >> >     natural thing from new multiboot protocol for ARM64 definition standpoint.
> >> >
> >> > Anyway, I think that this thing should be be described in multiboot for ARM64
> >> > spec as IanC earlier told.
> >> >
> >> > I think that this should be ARM specific solution because we will be using
> >> > multiboot2 protocol on x86 which works on completely different way. Hmmm...
> >> > Maybe third solution (excluding FDT of course), if we choose that one,
> >> > should be common thing and work on any platform including x86.
> >>
> >> The multiboot2 on x86 and the FDT on arm64 are very different, which I think
> >
> > I know.
> >
> >> confuses/complicates these discussions.  The open issue of "is the EFI command
> >
> > Yep.
> >
> >> line used to pass the Xen command line when GRUB boots EFI Xen" applies equally
> >> to x86 and arm64.  I think that consistency between x86/arm64 Xen in this regard
> >
> > No, PE image will not be executed in the same way (simple EFI application load)
> > by GRUB2 on x86 like it happens in case of GRUB2 on ARM64. It means that I will
> > not be entering directly via efi_start() to efi boot code when Xen will be started
> > by GRUB2 on x86_64 EFI platform. I am going to use separate entry point. However, I am
> > going to use most of currently existing EFI boot code too. So, as I wrote in earlier
> > email, I suppose that both paths (GRUB2 and native EFI application) will merge somewhere
> > quite quickly. However, I do not have the details right now. I am working on it.
>
> OK, this is the part I was missing.
>
> >
> >> is more important than following what Linux does, so I'm dropping that
> >> suggestion.
> >
> > OK.
> >
> >> So I'm going to propose the following which I think is in line with
> >> your 2nd option
> >> (I'm not familiar with the GRUB multiboot syntax, so it might not be),
> >> and I think
> >> is along the lines of what Jan has also suggested:
> >>
> >> When booting EFI Xen via GRUB (for both x86 and arm64):
> >> 1) the EFI command line is not used by Xen, and is ignored.
> >
> > As I said above, multiboot2 protocol on x86 does not execute PE
> > application as EFI application. It means that we do not have
> > EFI command line per se.
>
> OK, I understand now it makes things clearer.  My assumptions where
> wrong about how GRUB would start the PE Xen on x86, so I was asking questions
> that didn't really make sense.
>
> >
> >> 2) the Xen commandline is provided to Xen in the multiboot2/FDT data
> >
> > OK.
> >
> >> 3) The Xen EFI configuration file is not used
> >
> > OK.
> >
> >> 4) The EFI Xen boot code does not do any console/video or other initialization.
> >>     There is no way to provide EFI boot code specific options, as it
> >> doesn't and shouldn't
> >>     need any.
> >
> > Please see comment for 1. It means that I will skip code which parse EFI
> > application command line. Hmmm... How are you going to detect that Xen
> > was started by GRUB2 if you in both cases entering via efi_start()?
> > Maybe you should look for arguments in FDT first? Or check FDT for
> > special flag which means that EFI app was executed by GRUB? Later
> > looks better because if Xen command line will be empty then EFI
> > application will try read one of xen.cfg files.
>
> The current implementation is to examine the FDT passed to Xen to see
> if it contains any modules.  If it does, then this indicates to the
> EFI boot code
> that it is being run by a bootloader, and not directly from the EFI bootmanager
> or shell.

I think that it is wrong. I am able to imagine such situation in which
only small binary is loaded to do something specific and this binary
does not require any modules. If we do what you suggest then we must
load an additional module which will not be used by binary itself but
it just signals that binary was loaded by multiboot protocol. Not nice.
That is why I am still thinking that multiboot protocol aware loader
should put a flag in FDT telling that binary was loaded that way.

I am aware that Xen have to have at least one module (kernel image for dom0)
but I think that new protocol should be generic as much as possible and
Xen should not be its only one user.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 21:58:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21:58:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlm6q-0003Tt-TA; Tue, 04 Nov 2014 21:57:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xlm6p-0003To-Hr
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 21:57:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BC/DE-24532-EDB49545; Tue, 04 Nov 2014 21:57:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415138267!12819875!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1930 invoked from network); 4 Nov 2014 21:57:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 21:57:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,315,1413244800"; d="scan'208";a="188115468"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 16:57:44 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xlm6i-0000E5-4I;
	Tue, 04 Nov 2014 21:57:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xlm6g-0005Zq-Q1;
	Tue, 04 Nov 2014 21:57:43 +0000
Date: Tue, 4 Nov 2014 21:57:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31363-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31363: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31363 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31363/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 04 21:58:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 21:58:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlm6q-0003Tt-TA; Tue, 04 Nov 2014 21:57:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xlm6p-0003To-Hr
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 21:57:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BC/DE-24532-EDB49545; Tue, 04 Nov 2014 21:57:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415138267!12819875!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1930 invoked from network); 4 Nov 2014 21:57:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 21:57:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,315,1413244800"; d="scan'208";a="188115468"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 16:57:44 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xlm6i-0000E5-4I;
	Tue, 04 Nov 2014 21:57:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xlm6g-0005Zq-Q1;
	Tue, 04 Nov 2014 21:57:43 +0000
Date: Tue, 4 Nov 2014 21:57:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31363-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31363: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31363 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31363/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 04 22:36:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 22: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.xen.org>)
	id 1Xlmhu-0004Or-O4; Tue, 04 Nov 2014 22:36:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1Xlmht-0004Om-CT
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 22:36:09 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	80/8A-24124-8D459545; Tue, 04 Nov 2014 22:36:08 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415140567!11221344!1
X-Originating-IP: [209.85.220.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15810 invoked from network); 4 Nov 2014 22:36:08 -0000
Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com)
	(209.85.220.180)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 22:36:08 -0000
Received: by mail-vc0-f180.google.com with SMTP id hy10so7386849vcb.11
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 14:36:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=EAzRwtFddWONnHXJJmTkNFzJlEpNnZPXkH15aohaKnE=;
	b=ZUTt2z/ahYIa+pdynKQC6yIR1cQvMySDFUEmeNO2wmxYE4eNLcPnSlhzYX17r1zuRQ
	O+UX1utBaMRzErVtR25n9tcqZTLwd/lfbA2loCv1G1/ZjmqBhlPplmj1OgU6Ea0JmbcV
	xI2SUxZcDhz84HES4J3Ah6fdgLUcTQvs2gfF/wwIPRoukqkaAeZQiATmNFl7XCssOXa4
	LX5Iym4ihmkNE60CEdzS8TKyTwssSyMsLmIKQsU0QOrAtXlcvjDSyhZFibdHXoE7aRAb
	1iJ+FmEMxtAfJ7jYcvC9xMclftpD7AKz5HzaiDTXPsmJm731Q4hlw3wV7RBWPQfI6wCS
	NTYQ==
X-Gm-Message-State: ALoCoQlwXK7pt11maspdYGI/G6dYWwNzrvyMjSk9EJukuIWYxtzHuXbZeETt+EOxtyUXsXdurhmj
MIME-Version: 1.0
X-Received: by 10.53.13.10 with SMTP id eu10mr2687119vdd.21.1415140566713;
	Tue, 04 Nov 2014 14:36:06 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Tue, 4 Nov 2014 14:36:06 -0800 (PST)
In-Reply-To: <20141104211745.GK16923@olila.local.net-space.pl>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
	<CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
	<5458932F0200007800044A4E@mail.emea.novell.com>
	<CAFECyb9Z=YBXhn6xmutp0iV2JNQUbpw3FA=GT4QgSYPwvY9ksw@mail.gmail.com>
	<20141104211745.GK16923@olila.local.net-space.pl>
Date: Tue, 4 Nov 2014 14:36:06 -0800
Message-ID: <CAFECyb9b6rcHL55iSLfKxqQVxJrWGGf1+JBLwGhJanMRQ=uVvw@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 1:17 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> On Tue, Nov 04, 2014 at 10:39:53AM -0800, Roy Franz wrote:
>> On Mon, Nov 3, 2014 at 11:49 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>> On 04.11.14 at 05:31, <roy.franz@linaro.org> wrote:
>> >> On Mon, Nov 3, 2014 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
>> >>>> This patch implements what I understand to be the desired behavior when
>> >>>> booting
>> >>>> an EFI Xen image via GRUB based on the thread last week.  The EFI command
>> >>>> line
>> >>>> is not used, and the Xen commandline comes via the multiboot protocol (and
>> >>>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
>> >>>> GRUB EFI boot cases into alignment in not using the EFI commandline.
>> >>>
>> >>> Right, but ...
>> >>>
>> >>>> The current state of the arm64 code takes the Xen commandline from the FDT,
>> >>>> but still looks in the EFI commandline for EFI boot specific options.  If
>> >>>> unexpected options are passed in the EFI commandline, it will generate
>> >>>> "unrecognized option" ouput for all unexpected options.
>> >>>
>> >>> ... why is this?
>> >>
>> >> The EFI boot code did this before any of the arm64 changes, and that
>> >> behavior is unchanged.
>> >> The actual message is "WARNING: Unknown command line option"
>> >>
>> >> I was simply trying to explain the current behavior regarding the EFI
>> >> commandline.
>> >
>> > Argh, I should have stripped that second sentence from the quoted
>> > context, as the question was regarding the apparently special ARM64
>> > behavior you describe.
>>
>> >>>> The current state of the arm64 code takes the Xen commandline from the FDT,
>> >>>> but still looks in the EFI commandline for EFI boot specific options.
>> OK, I'll try address the above.  This behavior is the "no config file
>> case", which only
>> exists on arm64 - x86 always uses a config file when booted as an EFI
>> application, since
>> for x86 GRUB does execute Xen as en EFI application when using multiboot2.
>
> I have a feeling that you wrote that by mistake. As I said in my earlier emails
> multiboot2 on x86 EFI platform will not load EFI application as an EFI application.

Grr..  meant "does not execute"  of course.  I do get that now :)
>
>> The case of being executed as an EFI application, loaded by GRUB and provided
>> module information via the multiboot2 (in FDT) protocol is unique to
>> arm64.  All the code
>> is common code, but since efi_arch_use_config_file() is always true
>> for x86 the case
>> described only applies to arm64.
>
> Right now it is true. Probably it will change after introducing
> multiboot2 protocol on x86.

So you expect to be using the efi_start() function mostly as is?

>
> Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 22:36:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 22: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.xen.org>)
	id 1Xlmhu-0004Or-O4; Tue, 04 Nov 2014 22:36:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1Xlmht-0004Om-CT
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 22:36:09 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	80/8A-24124-8D459545; Tue, 04 Nov 2014 22:36:08 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415140567!11221344!1
X-Originating-IP: [209.85.220.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15810 invoked from network); 4 Nov 2014 22:36:08 -0000
Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com)
	(209.85.220.180)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 22:36:08 -0000
Received: by mail-vc0-f180.google.com with SMTP id hy10so7386849vcb.11
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 14:36:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=EAzRwtFddWONnHXJJmTkNFzJlEpNnZPXkH15aohaKnE=;
	b=ZUTt2z/ahYIa+pdynKQC6yIR1cQvMySDFUEmeNO2wmxYE4eNLcPnSlhzYX17r1zuRQ
	O+UX1utBaMRzErVtR25n9tcqZTLwd/lfbA2loCv1G1/ZjmqBhlPplmj1OgU6Ea0JmbcV
	xI2SUxZcDhz84HES4J3Ah6fdgLUcTQvs2gfF/wwIPRoukqkaAeZQiATmNFl7XCssOXa4
	LX5Iym4ihmkNE60CEdzS8TKyTwssSyMsLmIKQsU0QOrAtXlcvjDSyhZFibdHXoE7aRAb
	1iJ+FmEMxtAfJ7jYcvC9xMclftpD7AKz5HzaiDTXPsmJm731Q4hlw3wV7RBWPQfI6wCS
	NTYQ==
X-Gm-Message-State: ALoCoQlwXK7pt11maspdYGI/G6dYWwNzrvyMjSk9EJukuIWYxtzHuXbZeETt+EOxtyUXsXdurhmj
MIME-Version: 1.0
X-Received: by 10.53.13.10 with SMTP id eu10mr2687119vdd.21.1415140566713;
	Tue, 04 Nov 2014 14:36:06 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Tue, 4 Nov 2014 14:36:06 -0800 (PST)
In-Reply-To: <20141104211745.GK16923@olila.local.net-space.pl>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
	<CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
	<5458932F0200007800044A4E@mail.emea.novell.com>
	<CAFECyb9Z=YBXhn6xmutp0iV2JNQUbpw3FA=GT4QgSYPwvY9ksw@mail.gmail.com>
	<20141104211745.GK16923@olila.local.net-space.pl>
Date: Tue, 4 Nov 2014 14:36:06 -0800
Message-ID: <CAFECyb9b6rcHL55iSLfKxqQVxJrWGGf1+JBLwGhJanMRQ=uVvw@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 1:17 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> On Tue, Nov 04, 2014 at 10:39:53AM -0800, Roy Franz wrote:
>> On Mon, Nov 3, 2014 at 11:49 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>> On 04.11.14 at 05:31, <roy.franz@linaro.org> wrote:
>> >> On Mon, Nov 3, 2014 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>>>> On 03.11.14 at 07:13, <roy.franz@linaro.org> wrote:
>> >>>> This patch implements what I understand to be the desired behavior when
>> >>>> booting
>> >>>> an EFI Xen image via GRUB based on the thread last week.  The EFI command
>> >>>> line
>> >>>> is not used, and the Xen commandline comes via the multiboot protocol (and
>> >>>> in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
>> >>>> GRUB EFI boot cases into alignment in not using the EFI commandline.
>> >>>
>> >>> Right, but ...
>> >>>
>> >>>> The current state of the arm64 code takes the Xen commandline from the FDT,
>> >>>> but still looks in the EFI commandline for EFI boot specific options.  If
>> >>>> unexpected options are passed in the EFI commandline, it will generate
>> >>>> "unrecognized option" ouput for all unexpected options.
>> >>>
>> >>> ... why is this?
>> >>
>> >> The EFI boot code did this before any of the arm64 changes, and that
>> >> behavior is unchanged.
>> >> The actual message is "WARNING: Unknown command line option"
>> >>
>> >> I was simply trying to explain the current behavior regarding the EFI
>> >> commandline.
>> >
>> > Argh, I should have stripped that second sentence from the quoted
>> > context, as the question was regarding the apparently special ARM64
>> > behavior you describe.
>>
>> >>>> The current state of the arm64 code takes the Xen commandline from the FDT,
>> >>>> but still looks in the EFI commandline for EFI boot specific options.
>> OK, I'll try address the above.  This behavior is the "no config file
>> case", which only
>> exists on arm64 - x86 always uses a config file when booted as an EFI
>> application, since
>> for x86 GRUB does execute Xen as en EFI application when using multiboot2.
>
> I have a feeling that you wrote that by mistake. As I said in my earlier emails
> multiboot2 on x86 EFI platform will not load EFI application as an EFI application.

Grr..  meant "does not execute"  of course.  I do get that now :)
>
>> The case of being executed as an EFI application, loaded by GRUB and provided
>> module information via the multiboot2 (in FDT) protocol is unique to
>> arm64.  All the code
>> is common code, but since efi_arch_use_config_file() is always true
>> for x86 the case
>> described only applies to arm64.
>
> Right now it is true. Probably it will change after introducing
> multiboot2 protocol on x86.

So you expect to be using the efi_start() function mostly as is?

>
> Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 22:49:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 22:49:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlmuO-0004j4-8q; Tue, 04 Nov 2014 22:49:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XlmuM-0004iz-It
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 22:49:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BC/65-09936-DD759545; Tue, 04 Nov 2014 22:49:01 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415141339!12760780!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32420 invoked from network); 4 Nov 2014 22:49:00 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 22:49:00 -0000
Received: by mail-vc0-f173.google.com with SMTP id le20so7319826vcb.18
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 14:48:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=75kUrzN58MbPv2FCHwL4kdcypHOeme/ozrHWJJOImzU=;
	b=ElGUn2qcog4q156o435QTyujy43Lf20C+Mn0BiiiK7Vpj5kSWIYkqCzS2G4Dz0ox6m
	KaGStbOCHt0TrKBGBWQ7o0UXY+XjkYxXMxEvy2739uDKnMecozjLMguyl/LDxijjK1HO
	99rxq83Csll2x5rR77Ul7+5uDnr2DAQdvTdLkXlieCKqBBtzKN2o+N4Q8o9GpwSpmfSR
	bZW/EDi+mZW6+IW83sTOKDSlxD4J1Mj0GgOYdHSKaMk/gyDtYrYlKFAilDYCYa/sU2Fy
	k7SoKuJNsfHqGotNiBB4O5kKQqmDrIRGs9vm0jL/89HQRWnnbTFjvLgE37dpB3iRSM6U
	Gmhg==
X-Gm-Message-State: ALoCoQmdvHfjxXKVs9iT4b8Zys+tseo5IoBFJYsBC8hXnmS+gaBPDquJ71Ch9Faub5zjnjR94pik
MIME-Version: 1.0
X-Received: by 10.221.19.1 with SMTP id qi1mr41679941vcb.24.1415141339639;
	Tue, 04 Nov 2014 14:48:59 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Tue, 4 Nov 2014 14:48:59 -0800 (PST)
In-Reply-To: <20141104214952.GL16923@olila.local.net-space.pl>
References: <544F58770200007800042ADA@mail.emea.novell.com>
	<CAFECyb-WsRpH4ee1XE5dZdxwygH-7hy-Nw8-ZEQtJF8Wnng8wA@mail.gmail.com>
	<20141029124411.GA3467@olila.local.net-space.pl>
	<1414596400.29580.12.camel@citrix.com>
	<20141029165526.GB3467@olila.local.net-space.pl>
	<CAFECyb_Q34S=L2Sy+PvLMBkZnct7z5y-u_c0Naush3oa2qnpng@mail.gmail.com>
	<20141030175714.GF3467@olila.local.net-space.pl>
	<CAFECyb--vAVRMvHVNZKb39WSaKDO16JbkHQBi-HbL-LLx5VUoA@mail.gmail.com>
	<20141030221857.GA16923@olila.local.net-space.pl>
	<CAFECyb8cJvkrjgUcu1-mr_xBJPZOxKdrEnJ4ekD78gEK0a=5iA@mail.gmail.com>
	<20141104214952.GL16923@olila.local.net-space.pl>
Date: Tue, 4 Nov 2014 14:48:59 -0800
Message-ID: <CAFECyb_NHc9bnG1BFasL-3Gk5A10iHEdN0HTE-8SJan=o=mp6A@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, tim <tim@xen.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH V2 for-4.5] EFI: Always use EFI command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 1:49 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> On Thu, Oct 30, 2014 at 04:54:17PM -0700, Roy Franz wrote:
>> On Thu, Oct 30, 2014 at 3:18 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>> > On Thu, Oct 30, 2014 at 12:29:05PM -0700, Roy Franz wrote:
>> >> On Thu, Oct 30, 2014 at 10:57 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>> >
>> > [...]
>> >
>> >> > If yes then I can see three solutions for this issue:
>> >> >   - GRUB2 should pass e.g. --multiboot as first argument to Xen EFI
>> >> >     application and after -- all arguments for Xen itself; Xen EFI app
>> >> >     should not parse xen.cfg files in this case,
>> >> >   - GRUB2 should pass e.g. --multiboot as first argument to Xen EFI
>> >> >     application and all arguments for Xen itself (and relevant modules)
>> >> >     in FDT; Xen EFI app should not parse xen.cfg files in this case too,
>> >> >   - GRUB2 should pass all arguments to EFI application as is via standard
>> >> >     way (as GRUB2 linux loader does on ARM64); arguments for modules should
>> >> >     be passed via FDT; Xen EFI application should parse all arguments as
>> >> >     regular xen.gz; -cfg option should be changed to cfg, -basevideo option
>> >> >     should be changed to basevideo, etc. At first sight this looks as most
>> >> >     natural thing from new multiboot protocol for ARM64 definition standpoint.
>> >> >
>> >> > Anyway, I think that this thing should be be described in multiboot for ARM64
>> >> > spec as IanC earlier told.
>> >> >
>> >> > I think that this should be ARM specific solution because we will be using
>> >> > multiboot2 protocol on x86 which works on completely different way. Hmmm...
>> >> > Maybe third solution (excluding FDT of course), if we choose that one,
>> >> > should be common thing and work on any platform including x86.
>> >>
>> >> The multiboot2 on x86 and the FDT on arm64 are very different, which I think
>> >
>> > I know.
>> >
>> >> confuses/complicates these discussions.  The open issue of "is the EFI command
>> >
>> > Yep.
>> >
>> >> line used to pass the Xen command line when GRUB boots EFI Xen" applies equally
>> >> to x86 and arm64.  I think that consistency between x86/arm64 Xen in this regard
>> >
>> > No, PE image will not be executed in the same way (simple EFI application load)
>> > by GRUB2 on x86 like it happens in case of GRUB2 on ARM64. It means that I will
>> > not be entering directly via efi_start() to efi boot code when Xen will be started
>> > by GRUB2 on x86_64 EFI platform. I am going to use separate entry point. However, I am
>> > going to use most of currently existing EFI boot code too. So, as I wrote in earlier
>> > email, I suppose that both paths (GRUB2 and native EFI application) will merge somewhere
>> > quite quickly. However, I do not have the details right now. I am working on it.
>>
>> OK, this is the part I was missing.
>>
>> >
>> >> is more important than following what Linux does, so I'm dropping that
>> >> suggestion.
>> >
>> > OK.
>> >
>> >> So I'm going to propose the following which I think is in line with
>> >> your 2nd option
>> >> (I'm not familiar with the GRUB multiboot syntax, so it might not be),
>> >> and I think
>> >> is along the lines of what Jan has also suggested:
>> >>
>> >> When booting EFI Xen via GRUB (for both x86 and arm64):
>> >> 1) the EFI command line is not used by Xen, and is ignored.
>> >
>> > As I said above, multiboot2 protocol on x86 does not execute PE
>> > application as EFI application. It means that we do not have
>> > EFI command line per se.
>>
>> OK, I understand now it makes things clearer.  My assumptions where
>> wrong about how GRUB would start the PE Xen on x86, so I was asking questions
>> that didn't really make sense.
>>
>> >
>> >> 2) the Xen commandline is provided to Xen in the multiboot2/FDT data
>> >
>> > OK.
>> >
>> >> 3) The Xen EFI configuration file is not used
>> >
>> > OK.
>> >
>> >> 4) The EFI Xen boot code does not do any console/video or other initialization.
>> >>     There is no way to provide EFI boot code specific options, as it
>> >> doesn't and shouldn't
>> >>     need any.
>> >
>> > Please see comment for 1. It means that I will skip code which parse EFI
>> > application command line. Hmmm... How are you going to detect that Xen
>> > was started by GRUB2 if you in both cases entering via efi_start()?
>> > Maybe you should look for arguments in FDT first? Or check FDT for
>> > special flag which means that EFI app was executed by GRUB? Later
>> > looks better because if Xen command line will be empty then EFI
>> > application will try read one of xen.cfg files.
>>
>> The current implementation is to examine the FDT passed to Xen to see
>> if it contains any modules.  If it does, then this indicates to the
>> EFI boot code
>> that it is being run by a bootloader, and not directly from the EFI bootmanager
>> or shell.
>
> I think that it is wrong. I am able to imagine such situation in which
> only small binary is loaded to do something specific and this binary
> does not require any modules. If we do what you suggest then we must
> load an additional module which will not be used by binary itself but
> it just signals that binary was loaded by multiboot protocol. Not nice.
> That is why I am still thinking that multiboot protocol aware loader
> should put a flag in FDT telling that binary was loaded that way.
>
> I am aware that Xen have to have at least one module (kernel image for dom0)
> but I think that new protocol should be generic as much as possible and
> Xen should not be its only one user.

I think that what is being done for Xen is robust for Xen, and likely will be
for others as well.  The FDT-multiboot bindings are just a way to pass extra
module information to an application - if there are no
"multiboot,module" compatible nodes,
then the FDT-multiboot bindings are not in use.  Multiboot2 seems to
imply much more
than that - I need to investigate that a bit more so I understand how
this is done on
x86.

>
> Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 22:49:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 22:49:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlmuO-0004j4-8q; Tue, 04 Nov 2014 22:49:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XlmuM-0004iz-It
	for xen-devel@lists.xen.org; Tue, 04 Nov 2014 22:49:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BC/65-09936-DD759545; Tue, 04 Nov 2014 22:49:01 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415141339!12760780!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32420 invoked from network); 4 Nov 2014 22:49:00 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Nov 2014 22:49:00 -0000
Received: by mail-vc0-f173.google.com with SMTP id le20so7319826vcb.18
	for <xen-devel@lists.xen.org>; Tue, 04 Nov 2014 14:48:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=75kUrzN58MbPv2FCHwL4kdcypHOeme/ozrHWJJOImzU=;
	b=ElGUn2qcog4q156o435QTyujy43Lf20C+Mn0BiiiK7Vpj5kSWIYkqCzS2G4Dz0ox6m
	KaGStbOCHt0TrKBGBWQ7o0UXY+XjkYxXMxEvy2739uDKnMecozjLMguyl/LDxijjK1HO
	99rxq83Csll2x5rR77Ul7+5uDnr2DAQdvTdLkXlieCKqBBtzKN2o+N4Q8o9GpwSpmfSR
	bZW/EDi+mZW6+IW83sTOKDSlxD4J1Mj0GgOYdHSKaMk/gyDtYrYlKFAilDYCYa/sU2Fy
	k7SoKuJNsfHqGotNiBB4O5kKQqmDrIRGs9vm0jL/89HQRWnnbTFjvLgE37dpB3iRSM6U
	Gmhg==
X-Gm-Message-State: ALoCoQmdvHfjxXKVs9iT4b8Zys+tseo5IoBFJYsBC8hXnmS+gaBPDquJ71Ch9Faub5zjnjR94pik
MIME-Version: 1.0
X-Received: by 10.221.19.1 with SMTP id qi1mr41679941vcb.24.1415141339639;
	Tue, 04 Nov 2014 14:48:59 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Tue, 4 Nov 2014 14:48:59 -0800 (PST)
In-Reply-To: <20141104214952.GL16923@olila.local.net-space.pl>
References: <544F58770200007800042ADA@mail.emea.novell.com>
	<CAFECyb-WsRpH4ee1XE5dZdxwygH-7hy-Nw8-ZEQtJF8Wnng8wA@mail.gmail.com>
	<20141029124411.GA3467@olila.local.net-space.pl>
	<1414596400.29580.12.camel@citrix.com>
	<20141029165526.GB3467@olila.local.net-space.pl>
	<CAFECyb_Q34S=L2Sy+PvLMBkZnct7z5y-u_c0Naush3oa2qnpng@mail.gmail.com>
	<20141030175714.GF3467@olila.local.net-space.pl>
	<CAFECyb--vAVRMvHVNZKb39WSaKDO16JbkHQBi-HbL-LLx5VUoA@mail.gmail.com>
	<20141030221857.GA16923@olila.local.net-space.pl>
	<CAFECyb8cJvkrjgUcu1-mr_xBJPZOxKdrEnJ4ekD78gEK0a=5iA@mail.gmail.com>
	<20141104214952.GL16923@olila.local.net-space.pl>
Date: Tue, 4 Nov 2014 14:48:59 -0800
Message-ID: <CAFECyb_NHc9bnG1BFasL-3Gk5A10iHEdN0HTE-8SJan=o=mp6A@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, tim <tim@xen.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH V2 for-4.5] EFI: Always use EFI command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 1:49 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> On Thu, Oct 30, 2014 at 04:54:17PM -0700, Roy Franz wrote:
>> On Thu, Oct 30, 2014 at 3:18 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>> > On Thu, Oct 30, 2014 at 12:29:05PM -0700, Roy Franz wrote:
>> >> On Thu, Oct 30, 2014 at 10:57 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>> >
>> > [...]
>> >
>> >> > If yes then I can see three solutions for this issue:
>> >> >   - GRUB2 should pass e.g. --multiboot as first argument to Xen EFI
>> >> >     application and after -- all arguments for Xen itself; Xen EFI app
>> >> >     should not parse xen.cfg files in this case,
>> >> >   - GRUB2 should pass e.g. --multiboot as first argument to Xen EFI
>> >> >     application and all arguments for Xen itself (and relevant modules)
>> >> >     in FDT; Xen EFI app should not parse xen.cfg files in this case too,
>> >> >   - GRUB2 should pass all arguments to EFI application as is via standard
>> >> >     way (as GRUB2 linux loader does on ARM64); arguments for modules should
>> >> >     be passed via FDT; Xen EFI application should parse all arguments as
>> >> >     regular xen.gz; -cfg option should be changed to cfg, -basevideo option
>> >> >     should be changed to basevideo, etc. At first sight this looks as most
>> >> >     natural thing from new multiboot protocol for ARM64 definition standpoint.
>> >> >
>> >> > Anyway, I think that this thing should be be described in multiboot for ARM64
>> >> > spec as IanC earlier told.
>> >> >
>> >> > I think that this should be ARM specific solution because we will be using
>> >> > multiboot2 protocol on x86 which works on completely different way. Hmmm...
>> >> > Maybe third solution (excluding FDT of course), if we choose that one,
>> >> > should be common thing and work on any platform including x86.
>> >>
>> >> The multiboot2 on x86 and the FDT on arm64 are very different, which I think
>> >
>> > I know.
>> >
>> >> confuses/complicates these discussions.  The open issue of "is the EFI command
>> >
>> > Yep.
>> >
>> >> line used to pass the Xen command line when GRUB boots EFI Xen" applies equally
>> >> to x86 and arm64.  I think that consistency between x86/arm64 Xen in this regard
>> >
>> > No, PE image will not be executed in the same way (simple EFI application load)
>> > by GRUB2 on x86 like it happens in case of GRUB2 on ARM64. It means that I will
>> > not be entering directly via efi_start() to efi boot code when Xen will be started
>> > by GRUB2 on x86_64 EFI platform. I am going to use separate entry point. However, I am
>> > going to use most of currently existing EFI boot code too. So, as I wrote in earlier
>> > email, I suppose that both paths (GRUB2 and native EFI application) will merge somewhere
>> > quite quickly. However, I do not have the details right now. I am working on it.
>>
>> OK, this is the part I was missing.
>>
>> >
>> >> is more important than following what Linux does, so I'm dropping that
>> >> suggestion.
>> >
>> > OK.
>> >
>> >> So I'm going to propose the following which I think is in line with
>> >> your 2nd option
>> >> (I'm not familiar with the GRUB multiboot syntax, so it might not be),
>> >> and I think
>> >> is along the lines of what Jan has also suggested:
>> >>
>> >> When booting EFI Xen via GRUB (for both x86 and arm64):
>> >> 1) the EFI command line is not used by Xen, and is ignored.
>> >
>> > As I said above, multiboot2 protocol on x86 does not execute PE
>> > application as EFI application. It means that we do not have
>> > EFI command line per se.
>>
>> OK, I understand now it makes things clearer.  My assumptions where
>> wrong about how GRUB would start the PE Xen on x86, so I was asking questions
>> that didn't really make sense.
>>
>> >
>> >> 2) the Xen commandline is provided to Xen in the multiboot2/FDT data
>> >
>> > OK.
>> >
>> >> 3) The Xen EFI configuration file is not used
>> >
>> > OK.
>> >
>> >> 4) The EFI Xen boot code does not do any console/video or other initialization.
>> >>     There is no way to provide EFI boot code specific options, as it
>> >> doesn't and shouldn't
>> >>     need any.
>> >
>> > Please see comment for 1. It means that I will skip code which parse EFI
>> > application command line. Hmmm... How are you going to detect that Xen
>> > was started by GRUB2 if you in both cases entering via efi_start()?
>> > Maybe you should look for arguments in FDT first? Or check FDT for
>> > special flag which means that EFI app was executed by GRUB? Later
>> > looks better because if Xen command line will be empty then EFI
>> > application will try read one of xen.cfg files.
>>
>> The current implementation is to examine the FDT passed to Xen to see
>> if it contains any modules.  If it does, then this indicates to the
>> EFI boot code
>> that it is being run by a bootloader, and not directly from the EFI bootmanager
>> or shell.
>
> I think that it is wrong. I am able to imagine such situation in which
> only small binary is loaded to do something specific and this binary
> does not require any modules. If we do what you suggest then we must
> load an additional module which will not be used by binary itself but
> it just signals that binary was loaded by multiboot protocol. Not nice.
> That is why I am still thinking that multiboot protocol aware loader
> should put a flag in FDT telling that binary was loaded that way.
>
> I am aware that Xen have to have at least one module (kernel image for dom0)
> but I think that new protocol should be generic as much as possible and
> Xen should not be its only one user.

I think that what is being done for Xen is robust for Xen, and likely will be
for others as well.  The FDT-multiboot bindings are just a way to pass extra
module information to an application - if there are no
"multiboot,module" compatible nodes,
then the FDT-multiboot bindings are not in use.  Multiboot2 seems to
imply much more
than that - I need to investigate that a bit more so I understand how
this is done on
x86.

>
> Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 23:50:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 23: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 1XlnrT-00064m-JF; Tue, 04 Nov 2014 23:50:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlnrS-00064h-KM
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 23:50:06 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	8F/00-02699-D2669545; Tue, 04 Nov 2014 23:50:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415145003!12574692!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17689 invoked from network); 4 Nov 2014 23:50:04 -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;
	4 Nov 2014 23:50:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,316,1413244800"; d="scan'208";a="189539543"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 18:50:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlnrN-0000mW-Gl;
	Tue, 04 Nov 2014 23:50:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlnrN-0003zW-31;
	Tue, 04 Nov 2014 23:50:01 +0000
Date: Tue, 4 Nov 2014 23:50:01 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31373-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31373: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31373 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31373/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          3d8a59f98b15b625babcb8b19d1832d002cc98b0
baseline version:
 rumpuserxen          ccc8df17b7e7e785e28bee8ae90d0f00f93208ca

------------------------------------------------------------
People who touched revisions under test:
  Antti Kantee <pooka@iki.fi>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=3d8a59f98b15b625babcb8b19d1832d002cc98b0
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen 3d8a59f98b15b625babcb8b19d1832d002cc98b0
+ branch=rumpuserxen
+ revision=3d8a59f98b15b625babcb8b19d1832d002cc98b0
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git 3d8a59f98b15b625babcb8b19d1832d002cc98b0:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   ccc8df1..3d8a59f  3d8a59f98b15b625babcb8b19d1832d002cc98b0 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 04 23:50:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Nov 2014 23: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 1XlnrT-00064m-JF; Tue, 04 Nov 2014 23:50:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlnrS-00064h-KM
	for xen-devel@lists.xensource.com; Tue, 04 Nov 2014 23:50:06 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	8F/00-02699-D2669545; Tue, 04 Nov 2014 23:50:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415145003!12574692!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17689 invoked from network); 4 Nov 2014 23:50:04 -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;
	4 Nov 2014 23:50:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,316,1413244800"; d="scan'208";a="189539543"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 18:50:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlnrN-0000mW-Gl;
	Tue, 04 Nov 2014 23:50:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlnrN-0003zW-31;
	Tue, 04 Nov 2014 23:50:01 +0000
Date: Tue, 4 Nov 2014 23:50:01 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31373-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31373: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31373 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31373/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          3d8a59f98b15b625babcb8b19d1832d002cc98b0
baseline version:
 rumpuserxen          ccc8df17b7e7e785e28bee8ae90d0f00f93208ca

------------------------------------------------------------
People who touched revisions under test:
  Antti Kantee <pooka@iki.fi>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=3d8a59f98b15b625babcb8b19d1832d002cc98b0
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen 3d8a59f98b15b625babcb8b19d1832d002cc98b0
+ branch=rumpuserxen
+ revision=3d8a59f98b15b625babcb8b19d1832d002cc98b0
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git 3d8a59f98b15b625babcb8b19d1832d002cc98b0:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   ccc8df1..3d8a59f  3d8a59f98b15b625babcb8b19d1832d002cc98b0 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 01:17:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 01: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 1XlpDo-0003vZ-FC; Wed, 05 Nov 2014 01:17:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlpDn-0003vU-0m
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 01:17:15 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	A0/57-02954-A9A79545; Wed, 05 Nov 2014 01:17:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415150231!12566847!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25803 invoked from network); 5 Nov 2014 01:17:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 01:17:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,316,1413244800"; d="scan'208";a="188163987"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 20:17:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlpDh-0001DA-Ud;
	Wed, 05 Nov 2014 01:17:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlpDh-0001R8-Kc;
	Wed, 05 Nov 2014 01:17:09 +0000
Date: Wed, 5 Nov 2014 01:17:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31372-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31372: 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 31372 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31372/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              4480cd28371ca328ed5561f3532f82d8cbc9f34d
baseline version:
 libvirt              e7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad

------------------------------------------------------------
People who touched revisions under test:
  Daniel Veillard <veillard@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=4480cd28371ca328ed5561f3532f82d8cbc9f34d
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 4480cd28371ca328ed5561f3532f82d8cbc9f34d
+ branch=libvirt
+ revision=4480cd28371ca328ed5561f3532f82d8cbc9f34d
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 4480cd28371ca328ed5561f3532f82d8cbc9f34d:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   e7e0580..4480cd2  4480cd28371ca328ed5561f3532f82d8cbc9f34d -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 01:17:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 01: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 1XlpDo-0003vZ-FC; Wed, 05 Nov 2014 01:17:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlpDn-0003vU-0m
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 01:17:15 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	A0/57-02954-A9A79545; Wed, 05 Nov 2014 01:17:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415150231!12566847!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25803 invoked from network); 5 Nov 2014 01:17:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 01:17:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,316,1413244800"; d="scan'208";a="188163987"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 20:17:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlpDh-0001DA-Ud;
	Wed, 05 Nov 2014 01:17:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlpDh-0001R8-Kc;
	Wed, 05 Nov 2014 01:17:09 +0000
Date: Wed, 5 Nov 2014 01:17:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31372-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31372: 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 31372 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31372/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              4480cd28371ca328ed5561f3532f82d8cbc9f34d
baseline version:
 libvirt              e7e05801e5e81bd80ea7dd9f0e0ae37f43ec49ad

------------------------------------------------------------
People who touched revisions under test:
  Daniel Veillard <veillard@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=4480cd28371ca328ed5561f3532f82d8cbc9f34d
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 4480cd28371ca328ed5561f3532f82d8cbc9f34d
+ branch=libvirt
+ revision=4480cd28371ca328ed5561f3532f82d8cbc9f34d
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 4480cd28371ca328ed5561f3532f82d8cbc9f34d:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   e7e0580..4480cd2  4480cd28371ca328ed5561f3532f82d8cbc9f34d -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 03:00:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 03:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlqp7-00068w-6I; Wed, 05 Nov 2014 02:59:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xlqp5-00068r-UV
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 02:59:52 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	C3/15-02698-7A299545; Wed, 05 Nov 2014 02:59:51 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415156389!12591563!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32749 invoked from network); 5 Nov 2014 02:59:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-27.messagelabs.com with SMTP;
	5 Nov 2014 02:59:50 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 04 Nov 2014 18:59:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,317,1413270000"; d="scan'208";a="602446224"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.128])
	([10.238.130.128])
	by orsmga001.jf.intel.com with ESMTP; 04 Nov 2014 18:59:46 -0800
Message-ID: <545992A2.8070309@intel.com>
Date: Wed, 05 Nov 2014 10:59:46 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
In-Reply-To: <545894610200007800044A5B@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/4 15:54, Jan Beulich wrote:
>>>> On 04.11.14 at 06:05, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 20:34, Jan Beulich wrote:
>>>>>> On 03.11.14 at 12:58, <tiejun.chen@intel.com> wrote:
>>>> Firstly we have a rule that we just allow all devices associated one
>>>> RMRR to be assign same VM, right? So I mean while we create VM, we
>>>> always call current hypercall but inside hypercall, Xen can know which
>>>> devices will be assigned to this VM.
>>>
>>> I.e. the hypercall (at least optionally) becomes per-domain rather
>>> than global. And you imply that device assignment happens
>>> before memory getting populated (which likely can be arranged
>>
>> I tried to find a clue about this point but unfortunately I can't trace
>> when we assign device exactly. But in theory, based on your hint I
>> prefer the device assignment should follow memory getting populated.
>> Because when we add a device, we need to create iommu map so this means
>> at this moment the guest should already finish populating memory, right?
>
> There's no such strong connection: When a device gets assigned,
> IOMMU mappings get created for all memory the guest already has
> assigned (which at least in theory can include the "none" case).
> When (more) memory gets assigned after a device was already
> assigned to the guest, the IOMMU mappings would simply get
> updated.
>
> While I think you're right in that memory assignment happens
> before device assignment, for your specific purpose it might have

Yeah, I also double checked this sequence with printk.

> been easier the other way around, since when memory gets
> populated first you'll need special peeking into which devices will
> get assigned later in order to avoid the respective RMRR areas,
> or you'll need to modify device assignment code to move the
> RAM populated there out of the way.
>

Although I really don't grab these device assignment codes explicitly, 
but looks it may corrupt some existing frameworks to move device 
assignment codes.

I'm not sure if you already have a definitive solution. If yes, please 
guide me and just ignore the reset.

But if not, I have a preliminary picture as follows:

#1 Policy

We will introduce a parameter globally, 'pci_rdmforce'. Then we can pass 
that in the config file, like

pci_rdmforce = 1 => Of course this should be 0 by default.

'1' means we should force check to reserve all ranges. If failed VM 
wouldn't be created successfully. This also can give user a chance to 
work well with later hotplug, even if not a device assignment while 
creating VM.

But we can override that by one specific pci device:

pci = ['AA:BB.CC,rdmforce=0/1]

But this 'rdmforce' should be 1 by default since obviously any 
passthrough device always need to do this. Actually no one really want 
to set as '0' so it may be unnecessary but I'd like to leave this as a 
potential approach.

So if 'pci_rdmforce = 0' and 'rdmforce = 1', we just check to reserve 
the ranges associated to this device.

And in any case of 'pci_rdmforce = 0' which means we have nothing to do, 
so we will have a higher likelihood of failure to assign a device with 
RMRR in both case of adding and attaching it. So we have to reject that 
in case of overlapping. Actually this just depends on whether we can set 
these identified p2m mapping.

#2 How-to

Firstly we should post actively a recommendation message to indicate 
we'd better set 'pci_rdmforce' to work passthrough, if any RMRR exists 
while parsing ACPI.

Next, we need a new domctl to provide these info, 'pci_rdmforce' and 
'rdm_force' when parse the config file. Certainly we may need to 
introduce and set two new fields in strcut domain, and since then we 
just use these fields to modify our current existing iommu callback 
inside to support our policy. I mean we just expose those associated 
RMRR entry. I think its easy to implement this since inside Xen we can 
know which entry is owned by which device. So this can benefit us to 
avoid modifying any tools codes and most Xen codes we already addressed.

So is it feasible to you? Or Anything else I'm missing?

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 03:00:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 03:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlqp7-00068w-6I; Wed, 05 Nov 2014 02:59:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xlqp5-00068r-UV
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 02:59:52 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	C3/15-02698-7A299545; Wed, 05 Nov 2014 02:59:51 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415156389!12591563!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32749 invoked from network); 5 Nov 2014 02:59:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-27.messagelabs.com with SMTP;
	5 Nov 2014 02:59:50 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 04 Nov 2014 18:59:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,317,1413270000"; d="scan'208";a="602446224"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.128])
	([10.238.130.128])
	by orsmga001.jf.intel.com with ESMTP; 04 Nov 2014 18:59:46 -0800
Message-ID: <545992A2.8070309@intel.com>
Date: Wed, 05 Nov 2014 10:59:46 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
In-Reply-To: <545894610200007800044A5B@mail.emea.novell.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/4 15:54, Jan Beulich wrote:
>>>> On 04.11.14 at 06:05, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 20:34, Jan Beulich wrote:
>>>>>> On 03.11.14 at 12:58, <tiejun.chen@intel.com> wrote:
>>>> Firstly we have a rule that we just allow all devices associated one
>>>> RMRR to be assign same VM, right? So I mean while we create VM, we
>>>> always call current hypercall but inside hypercall, Xen can know which
>>>> devices will be assigned to this VM.
>>>
>>> I.e. the hypercall (at least optionally) becomes per-domain rather
>>> than global. And you imply that device assignment happens
>>> before memory getting populated (which likely can be arranged
>>
>> I tried to find a clue about this point but unfortunately I can't trace
>> when we assign device exactly. But in theory, based on your hint I
>> prefer the device assignment should follow memory getting populated.
>> Because when we add a device, we need to create iommu map so this means
>> at this moment the guest should already finish populating memory, right?
>
> There's no such strong connection: When a device gets assigned,
> IOMMU mappings get created for all memory the guest already has
> assigned (which at least in theory can include the "none" case).
> When (more) memory gets assigned after a device was already
> assigned to the guest, the IOMMU mappings would simply get
> updated.
>
> While I think you're right in that memory assignment happens
> before device assignment, for your specific purpose it might have

Yeah, I also double checked this sequence with printk.

> been easier the other way around, since when memory gets
> populated first you'll need special peeking into which devices will
> get assigned later in order to avoid the respective RMRR areas,
> or you'll need to modify device assignment code to move the
> RAM populated there out of the way.
>

Although I really don't grab these device assignment codes explicitly, 
but looks it may corrupt some existing frameworks to move device 
assignment codes.

I'm not sure if you already have a definitive solution. If yes, please 
guide me and just ignore the reset.

But if not, I have a preliminary picture as follows:

#1 Policy

We will introduce a parameter globally, 'pci_rdmforce'. Then we can pass 
that in the config file, like

pci_rdmforce = 1 => Of course this should be 0 by default.

'1' means we should force check to reserve all ranges. If failed VM 
wouldn't be created successfully. This also can give user a chance to 
work well with later hotplug, even if not a device assignment while 
creating VM.

But we can override that by one specific pci device:

pci = ['AA:BB.CC,rdmforce=0/1]

But this 'rdmforce' should be 1 by default since obviously any 
passthrough device always need to do this. Actually no one really want 
to set as '0' so it may be unnecessary but I'd like to leave this as a 
potential approach.

So if 'pci_rdmforce = 0' and 'rdmforce = 1', we just check to reserve 
the ranges associated to this device.

And in any case of 'pci_rdmforce = 0' which means we have nothing to do, 
so we will have a higher likelihood of failure to assign a device with 
RMRR in both case of adding and attaching it. So we have to reject that 
in case of overlapping. Actually this just depends on whether we can set 
these identified p2m mapping.

#2 How-to

Firstly we should post actively a recommendation message to indicate 
we'd better set 'pci_rdmforce' to work passthrough, if any RMRR exists 
while parsing ACPI.

Next, we need a new domctl to provide these info, 'pci_rdmforce' and 
'rdm_force' when parse the config file. Certainly we may need to 
introduce and set two new fields in strcut domain, and since then we 
just use these fields to modify our current existing iommu callback 
inside to support our policy. I mean we just expose those associated 
RMRR entry. I think its easy to implement this since inside Xen we can 
know which entry is owned by which device. So this can benefit us to 
avoid modifying any tools codes and most Xen codes we already addressed.

So is it feasible to you? Or Anything else I'm missing?

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 03:02:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 03: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 1Xlqrc-0006JP-TI; Wed, 05 Nov 2014 03:02:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xlqrc-0006JG-03
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 03:02:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/96-24532-34399545; Wed, 05 Nov 2014 03:02:27 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415156546!5524521!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3797 invoked from network); 5 Nov 2014 03:02:26 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-21.messagelabs.com with SMTP;
	5 Nov 2014 03:02:26 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 04 Nov 2014 19:00:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,317,1413270000"; d="scan'208";a="602447547"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.128])
	([10.238.130.128])
	by orsmga001.jf.intel.com with ESMTP; 04 Nov 2014 19:02:23 -0800
Message-ID: <5459933F.2050407@intel.com>
Date: Wed, 05 Nov 2014 11:02:23 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415062817-3584-1-git-send-email-tiejun.chen@intel.com>
	<5458AB8C0200007800044AFE@mail.emea.novell.com>
In-Reply-To: <5458AB8C0200007800044AFE@mail.emea.novell.com>
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v3][PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/4 17:33, Jan Beulich wrote:
>>>> On 04.11.14 at 02:00, <tiejun.chen@intel.com> wrote:
>> We need to act on some specific hypercall error numbers, so
>> require the hypervisor view on the errno.h value rather than
>> just the build environment's number. So here link this headfile
>> from xen.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>
> Acked-by: Jan Beulich <jbeulich@suse.com>
>
> but only if this goes in
> - together with code actually using it
> - ahead (i.e. still for 4.5) of the planned changes to make error
>    indicator values properly part of the hypercall ABI (4.6)

So looks I just need to add your Ack and include this in my series of 
patches.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 03:02:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 03: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 1Xlqrc-0006JP-TI; Wed, 05 Nov 2014 03:02:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xlqrc-0006JG-03
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 03:02:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/96-24532-34399545; Wed, 05 Nov 2014 03:02:27 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415156546!5524521!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3797 invoked from network); 5 Nov 2014 03:02:26 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-21.messagelabs.com with SMTP;
	5 Nov 2014 03:02:26 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 04 Nov 2014 19:00:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,317,1413270000"; d="scan'208";a="602447547"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.128])
	([10.238.130.128])
	by orsmga001.jf.intel.com with ESMTP; 04 Nov 2014 19:02:23 -0800
Message-ID: <5459933F.2050407@intel.com>
Date: Wed, 05 Nov 2014 11:02:23 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415062817-3584-1-git-send-email-tiejun.chen@intel.com>
	<5458AB8C0200007800044AFE@mail.emea.novell.com>
In-Reply-To: <5458AB8C0200007800044AFE@mail.emea.novell.com>
Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v3][PATCH] tools/hvmloader: link errno.h from xen
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/4 17:33, Jan Beulich wrote:
>>>> On 04.11.14 at 02:00, <tiejun.chen@intel.com> wrote:
>> We need to act on some specific hypercall error numbers, so
>> require the hypervisor view on the errno.h value rather than
>> just the build environment's number. So here link this headfile
>> from xen.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>
> Acked-by: Jan Beulich <jbeulich@suse.com>
>
> but only if this goes in
> - together with code actually using it
> - ahead (i.e. still for 4.5) of the planned changes to make error
>    indicator values properly part of the hypercall ABI (4.6)

So looks I just need to add your Ack and include this in my series of 
patches.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 03:24:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 03:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlrCh-0006rZ-SL; Wed, 05 Nov 2014 03:24:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlrCg-0006rN-0p
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 03:24:14 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	59/A3-25547-D5899545; Wed, 05 Nov 2014 03:24:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415157850!11670766!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15595 invoked from network); 5 Nov 2014 03:24:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 03:24:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,317,1413244800"; d="scan'208";a="188183137"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 22:24:09 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlrCa-0001on-Tp;
	Wed, 05 Nov 2014 03:24:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlrCa-0001V1-Ha;
	Wed, 05 Nov 2014 03:24:08 +0000
Date: Wed, 5 Nov 2014 03:24:08 +0000
Message-ID: <E1XlrCa-0001V1-Ha@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [seabios 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://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  seabios git://git.seabios.org/seabios.git
  Bug introduced:  99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Bug not present: 46000f5608a0ed1156463218f49d33044c4df843


  commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Author: Kevin O'Connor <kevin@koconnor.net>
  Date:   Tue Oct 21 14:34:06 2014 -0400
  
      Do full BREGS backup/restore for pmm, pnp, and irqentry_extrastack
      
      Although these entry points only require backup and restore of the
      registers that the C code clobbers, there is no harm in backing up
      some additional registers.  This allows the BREGS macros to be used
      which makes the code a little more readable.
      
      Signed-off-by: Kevin O'Connor <kevin@koconnor.net>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.seabios.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:
 31343 fail [host=rice-weevil] / 30767 ok.
Failure / basis pass flights: 31343 / 30767
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
Basis pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#d7892a4c389d54bccb9bce8e65eb053a33bbe290-d7892a4c389d54bccb9bce8e65eb053a33bbe290 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#c9d8f8b755e8960edf7725e05f3e6ac743a5e12e-ca78cc83650b535d7e24baeaea32947be0141534 git://git.seabios.org/seabios.git#bfb7b58b30681f5c421e838fdef3dbc358e80f1e-136d4ec190af616bb4fa8624dd9c648e5c9e0d2a git://xenbits.xen.org/xen.git#4d57153b52a36183d58e8de6ba613929f906386a-0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 3005 nodes in revision graph
Searching for test results:
 30761 pass irrelevant
 30767 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
 31223 fail irrelevant
 31314 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 54a1c6d629b7aafe52974a2a9f5c8cf3a3780413 9cea500dc0294947b12b8e2479a238acd0e990f2
 31316 pass irrelevant
 31253 fail irrelevant
 31322 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31306 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
 31317 fail irrelevant
 31307 fail irrelevant
 31312 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 54a1c6d629b7aafe52974a2a9f5c8cf3a3780413 8878d01936594d2b6a4366bc7be191edbc546aa8
 31289 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31337 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 54a1c6d629b7aafe52974a2a9f5c8cf3a3780413 c90a755f261b8ccb3dac7e1f695122cac95c6053
 31320 fail irrelevant
 31325 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31342 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 5b89d959a6ab6fd02e1bd9b1893fb860afec88d0 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31340 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 54a1c6d629b7aafe52974a2a9f5c8cf3a3780413 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31344 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 9978d49d1c858087de518a1d7391ba88aa0f5109 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31343 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31359 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31365 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31370 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31386 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31389 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31390 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
Searching for interesting versions
 Result found: flight 30767 (pass), for basis pass
 Result found: flight 31289 (fail), for basis failure
 Repro found: flight 31306 (pass), for basis pass
 Repro found: flight 31322 (fail), for basis failure
 0 revisions at d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
No revisions left to test, checking graph state.
 Result found: flight 31359 (pass), for last pass
 Result found: flight 31365 (fail), for first failure
 Repro found: flight 31370 (pass), for last pass
 Repro found: flight 31386 (fail), for first failure
 Repro found: flight 31389 (pass), for last pass
 Repro found: flight 31390 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  seabios git://git.seabios.org/seabios.git
  Bug introduced:  99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Bug not present: 46000f5608a0ed1156463218f49d33044c4df843

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Author: Kevin O'Connor <kevin@koconnor.net>
  Date:   Tue Oct 21 14:34:06 2014 -0400
  
      Do full BREGS backup/restore for pmm, pnp, and irqentry_extrastack
      
      Although these entry points only require backup and restore of the
      registers that the C code clobbers, there is no harm in backing up
      some additional registers.  This allows the BREGS macros to be used
      which makes the code a little more readable.
      
      Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

Revision graph left in /home/xc_osstest/results/bisect.seabios.test-amd64-i386-xl-winxpsp3-vcpus1.windows-install.{dot,ps,png,html}.
----------------------------------------
31390: tolerable ALL FAIL

flight 31390 seabios real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31390/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install   fail baseline untested


jobs:
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 03:24:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 03:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlrCh-0006rZ-SL; Wed, 05 Nov 2014 03:24:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlrCg-0006rN-0p
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 03:24:14 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	59/A3-25547-D5899545; Wed, 05 Nov 2014 03:24:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415157850!11670766!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15595 invoked from network); 5 Nov 2014 03:24:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 03:24:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,317,1413244800"; d="scan'208";a="188183137"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 22:24:09 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlrCa-0001on-Tp;
	Wed, 05 Nov 2014 03:24:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlrCa-0001V1-Ha;
	Wed, 05 Nov 2014 03:24:08 +0000
Date: Wed, 5 Nov 2014 03:24:08 +0000
Message-ID: <E1XlrCa-0001V1-Ha@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [seabios 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://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  seabios git://git.seabios.org/seabios.git
  Bug introduced:  99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Bug not present: 46000f5608a0ed1156463218f49d33044c4df843


  commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Author: Kevin O'Connor <kevin@koconnor.net>
  Date:   Tue Oct 21 14:34:06 2014 -0400
  
      Do full BREGS backup/restore for pmm, pnp, and irqentry_extrastack
      
      Although these entry points only require backup and restore of the
      registers that the C code clobbers, there is no harm in backing up
      some additional registers.  This allows the BREGS macros to be used
      which makes the code a little more readable.
      
      Signed-off-by: Kevin O'Connor <kevin@koconnor.net>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.seabios.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:
 31343 fail [host=rice-weevil] / 30767 ok.
Failure / basis pass flights: 31343 / 30767
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
Basis pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#d7892a4c389d54bccb9bce8e65eb053a33bbe290-d7892a4c389d54bccb9bce8e65eb053a33bbe290 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#c9d8f8b755e8960edf7725e05f3e6ac743a5e12e-ca78cc83650b535d7e24baeaea32947be0141534 git://git.seabios.org/seabios.git#bfb7b58b30681f5c421e838fdef3dbc358e80f1e-136d4ec190af616bb4fa8624dd9c648e5c9e0d2a git://xenbits.xen.org/xen.git#4d57153b52a36183d58e8de6ba613929f906386a-0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 3005 nodes in revision graph
Searching for test results:
 30761 pass irrelevant
 30767 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
 31223 fail irrelevant
 31314 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 54a1c6d629b7aafe52974a2a9f5c8cf3a3780413 9cea500dc0294947b12b8e2479a238acd0e990f2
 31316 pass irrelevant
 31253 fail irrelevant
 31322 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31306 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e bfb7b58b30681f5c421e838fdef3dbc358e80f1e 4d57153b52a36183d58e8de6ba613929f906386a
 31317 fail irrelevant
 31307 fail irrelevant
 31312 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 54a1c6d629b7aafe52974a2a9f5c8cf3a3780413 8878d01936594d2b6a4366bc7be191edbc546aa8
 31289 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31337 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 54a1c6d629b7aafe52974a2a9f5c8cf3a3780413 c90a755f261b8ccb3dac7e1f695122cac95c6053
 31320 fail irrelevant
 31325 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31342 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 5b89d959a6ab6fd02e1bd9b1893fb860afec88d0 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31340 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 54a1c6d629b7aafe52974a2a9f5c8cf3a3780413 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31344 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 9978d49d1c858087de518a1d7391ba88aa0f5109 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31343 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 136d4ec190af616bb4fa8624dd9c648e5c9e0d2a 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31359 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31365 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31370 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31386 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31389 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
 31390 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
Searching for interesting versions
 Result found: flight 30767 (pass), for basis pass
 Result found: flight 31289 (fail), for basis failure
 Repro found: flight 31306 (pass), for basis pass
 Repro found: flight 31322 (fail), for basis failure
 0 revisions at d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c9d8f8b755e8960edf7725e05f3e6ac743a5e12e 46000f5608a0ed1156463218f49d33044c4df843 281c892e3bdb0a56cfd8ab6516cd1a33c095c857
No revisions left to test, checking graph state.
 Result found: flight 31359 (pass), for last pass
 Result found: flight 31365 (fail), for first failure
 Repro found: flight 31370 (pass), for last pass
 Repro found: flight 31386 (fail), for first failure
 Repro found: flight 31389 (pass), for last pass
 Repro found: flight 31390 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  seabios git://git.seabios.org/seabios.git
  Bug introduced:  99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Bug not present: 46000f5608a0ed1156463218f49d33044c4df843

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/seabios
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.seabios.org/seabios.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
  Author: Kevin O'Connor <kevin@koconnor.net>
  Date:   Tue Oct 21 14:34:06 2014 -0400
  
      Do full BREGS backup/restore for pmm, pnp, and irqentry_extrastack
      
      Although these entry points only require backup and restore of the
      registers that the C code clobbers, there is no harm in backing up
      some additional registers.  This allows the BREGS macros to be used
      which makes the code a little more readable.
      
      Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

Revision graph left in /home/xc_osstest/results/bisect.seabios.test-amd64-i386-xl-winxpsp3-vcpus1.windows-install.{dot,ps,png,html}.
----------------------------------------
31390: tolerable ALL FAIL

flight 31390 seabios real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31390/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install   fail baseline untested


jobs:
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 04:22:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 04:22:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xls66-00080f-JA; Wed, 05 Nov 2014 04:21:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xls65-00080a-Tz
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 04:21:30 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	FC/A7-02699-9C5A9545; Wed, 05 Nov 2014 04:21:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415161287!12570590!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27459 invoked from network); 5 Nov 2014 04:21:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 04:21:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,317,1413244800"; d="scan'208";a="189585142"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 23:21:26 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xls61-000265-Rx;
	Wed, 05 Nov 2014 04:21:25 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xls61-0003mo-Lp;
	Wed, 05 Nov 2014 04:21:25 +0000
Date: Wed, 5 Nov 2014 04:21:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31368-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31368: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31368 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31368/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pair         7 xen-boot/src_host            fail   like 30761

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Nov 05 04:22:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 04:22:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xls66-00080f-JA; Wed, 05 Nov 2014 04:21:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xls65-00080a-Tz
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 04:21:30 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	FC/A7-02699-9C5A9545; Wed, 05 Nov 2014 04:21:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415161287!12570590!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27459 invoked from network); 5 Nov 2014 04:21:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 04:21:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,317,1413244800"; d="scan'208";a="189585142"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 4 Nov 2014 23:21:26 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xls61-000265-Rx;
	Wed, 05 Nov 2014 04:21:25 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xls61-0003mo-Lp;
	Wed, 05 Nov 2014 04:21:25 +0000
Date: Wed, 5 Nov 2014 04:21:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31368-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31368: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31368 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31368/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pair         7 xen-boot/src_host            fail   like 30761

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Nov 05 06:47:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 06: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 1XluN3-0002W7-0F; Wed, 05 Nov 2014 06:47:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XluN1-0002Vz-RQ
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 06:47:08 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	9C/45-24124-AE7C9545; Wed, 05 Nov 2014 06:47:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415170024!5857495!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8523 invoked from network); 5 Nov 2014 06:47:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 06:47:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,317,1413244800"; d="scan'208";a="188209532"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 01:47:02 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XluMw-0002qF-Bm;
	Wed, 05 Nov 2014 06:47:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XluMw-0000GX-2l;
	Wed, 05 Nov 2014 06:47:02 +0000
Date: Wed, 5 Nov 2014 06:47:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31374-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 10657
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31374: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2610124636981394316=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2610124636981394316==
Content-Type: text/plain
Content-Length: 10402
Content-Transfer-Encoding: quoted-printable

flight 31374 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31374/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass

version targeted for testing:
 qemuu                949ca9e479c381a63ddb257adca1a6f0c44d898e
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 9302 lines long.)


--===============2610124636981394316==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2610124636981394316==--

From xen-devel-bounces@lists.xen.org Wed Nov 05 06:47:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 06: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 1XluN3-0002W7-0F; Wed, 05 Nov 2014 06:47:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XluN1-0002Vz-RQ
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 06:47:08 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	9C/45-24124-AE7C9545; Wed, 05 Nov 2014 06:47:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415170024!5857495!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8523 invoked from network); 5 Nov 2014 06:47:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 06:47:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,317,1413244800"; d="scan'208";a="188209532"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 01:47:02 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XluMw-0002qF-Bm;
	Wed, 05 Nov 2014 06:47:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XluMw-0000GX-2l;
	Wed, 05 Nov 2014 06:47:02 +0000
Date: Wed, 5 Nov 2014 06:47:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31374-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 10657
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31374: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2610124636981394316=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2610124636981394316==
Content-Type: text/plain
Content-Length: 10402
Content-Transfer-Encoding: quoted-printable

flight 31374 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31374/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass

version targeted for testing:
 qemuu                949ca9e479c381a63ddb257adca1a6f0c44d898e
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 9302 lines long.)


--===============2610124636981394316==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2610124636981394316==--

From xen-devel-bounces@lists.xen.org Wed Nov 05 07:24:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 07:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xluwm-0003R6-SC; Wed, 05 Nov 2014 07:24:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xluwl-0003Qe-H9
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 07:24:03 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	13/45-02576-290D9545; Wed, 05 Nov 2014 07:24:02 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415172241!7980997!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6000 invoked from network); 5 Nov 2014 07:24:02 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-5.tower-27.messagelabs.com with SMTP;
	5 Nov 2014 07:24:02 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 04 Nov 2014 23:17:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,317,1413270000"; d="scan'208";a="617376229"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.128])
	([10.238.130.128])
	by fmsmga001.fm.intel.com with ESMTP; 04 Nov 2014 23:23:55 -0800
Message-ID: <5459D08B.7040809@intel.com>
Date: Wed, 05 Nov 2014 15:23:55 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
References: <543622CC.6050807@intel.com> <20141012095021.GC9567@redhat.com>
	<544A0174.7000003@intel.com> <20141024134747.GA6024@redhat.com>
	<5451ED1E.1000300@intel.com> <5457335B.1000308@intel.com>
	<5457686E.7020601@redhat.com> <545768CC.3000903@intel.com>
	<54576B5A.50005@intel.com> <54576E7F.3000901@redhat.com>
	<20141103131022.GB16423@redhat.com>
In-Reply-To: <20141103131022.GB16423@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create isa bridge
 specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 21:10, Michael S. Tsirkin wrote:
> On Mon, Nov 03, 2014 at 01:01:03PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 03/11/2014 12:47, Chen, Tiejun wrote:
>>> On 2014/11/3 19:36, Chen, Tiejun wrote:
>>>> On 2014/11/3 19:35, Paolo Bonzini wrote:
>>>>> On 03/11/2014 08:48, Chen, Tiejun wrote:
>>>>>>>>>> I think the point was mostly to reserve 1f to prevent
>>>>>>>>>> devices from using it.
>>>>>>>>>> As we populate slots in order it doesn't seem to important ...
>>>>>>>>>
>>>>>>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>>>>>>>
>>>>>>>> Right, but I mean if no special options are used, 1f will typically
>>>>>>>> stay free without any effort on our side.
>>>>>>>
>>>>>>> Yeah.
>>>>>>>
>>>>>>> Actually based on current info we know, seems 1f is just specific to
>>>>>>> our
>>>>>>> scenario :) So I always think we can occupy that. But Paolo and you
>>>>>>> can
>>>>>>> really determine this point.
>>>>>>
>>>>>> What's your idea?
>>>>>
>>>>> I do not have any objection to always occupying 1f for Xen IGD
>>>>> passthrough.
>>>
>>> After I go back to look at this again, I hope you don't misunderstand
>>> what Michael mean now. He was saying we don't need to create a new
>>> separate machine specific to IGD passthrough. But that idea is just from
>>> you :)
>>
>> It's difficult for me to follow, because xen_igd_passthrough_pc_hvm_init
>> does not exist in the current tree.
>>
>> The patches seem good to me; I was assuming that the new machine type
>> would call xen_igd_passthrough_pc_hvm_init, but apparently I'm wrong?
>> Paolo
>
> Discussed on irc, Paolo said
> <bonzini> so i don't really care how the ISA bridge is created
>

This means all those previous patches creating new separate machine 
should be gone.

I would rebase these two patches to resend again as RFC.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 07:24:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 07:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xluwm-0003R6-SC; Wed, 05 Nov 2014 07:24:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xluwl-0003Qe-H9
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 07:24:03 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	13/45-02576-290D9545; Wed, 05 Nov 2014 07:24:02 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415172241!7980997!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6000 invoked from network); 5 Nov 2014 07:24:02 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-5.tower-27.messagelabs.com with SMTP;
	5 Nov 2014 07:24:02 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 04 Nov 2014 23:17:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,317,1413270000"; d="scan'208";a="617376229"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.128])
	([10.238.130.128])
	by fmsmga001.fm.intel.com with ESMTP; 04 Nov 2014 23:23:55 -0800
Message-ID: <5459D08B.7040809@intel.com>
Date: Wed, 05 Nov 2014 15:23:55 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
References: <543622CC.6050807@intel.com> <20141012095021.GC9567@redhat.com>
	<544A0174.7000003@intel.com> <20141024134747.GA6024@redhat.com>
	<5451ED1E.1000300@intel.com> <5457335B.1000308@intel.com>
	<5457686E.7020601@redhat.com> <545768CC.3000903@intel.com>
	<54576B5A.50005@intel.com> <54576E7F.3000901@redhat.com>
	<20141103131022.GB16423@redhat.com>
In-Reply-To: <20141103131022.GB16423@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create isa bridge
 specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 21:10, Michael S. Tsirkin wrote:
> On Mon, Nov 03, 2014 at 01:01:03PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 03/11/2014 12:47, Chen, Tiejun wrote:
>>> On 2014/11/3 19:36, Chen, Tiejun wrote:
>>>> On 2014/11/3 19:35, Paolo Bonzini wrote:
>>>>> On 03/11/2014 08:48, Chen, Tiejun wrote:
>>>>>>>>>> I think the point was mostly to reserve 1f to prevent
>>>>>>>>>> devices from using it.
>>>>>>>>>> As we populate slots in order it doesn't seem to important ...
>>>>>>>>>
>>>>>>>>> If we populate slot at !1f GFX driver can't find this ISA bridge.
>>>>>>>>
>>>>>>>> Right, but I mean if no special options are used, 1f will typically
>>>>>>>> stay free without any effort on our side.
>>>>>>>
>>>>>>> Yeah.
>>>>>>>
>>>>>>> Actually based on current info we know, seems 1f is just specific to
>>>>>>> our
>>>>>>> scenario :) So I always think we can occupy that. But Paolo and you
>>>>>>> can
>>>>>>> really determine this point.
>>>>>>
>>>>>> What's your idea?
>>>>>
>>>>> I do not have any objection to always occupying 1f for Xen IGD
>>>>> passthrough.
>>>
>>> After I go back to look at this again, I hope you don't misunderstand
>>> what Michael mean now. He was saying we don't need to create a new
>>> separate machine specific to IGD passthrough. But that idea is just from
>>> you :)
>>
>> It's difficult for me to follow, because xen_igd_passthrough_pc_hvm_init
>> does not exist in the current tree.
>>
>> The patches seem good to me; I was assuming that the new machine type
>> would call xen_igd_passthrough_pc_hvm_init, but apparently I'm wrong?
>> Paolo
>
> Discussed on irc, Paolo said
> <bonzini> so i don't really care how the ISA bridge is created
>

This means all those previous patches creating new separate machine 
should be gone.

I would rebase these two patches to resend again as RFC.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 07:28:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 07: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 1Xlv0e-0003dJ-Iq; Wed, 05 Nov 2014 07:28:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xlv0c-0003d6-Oh
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 07:28:02 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A6/A5-08051-281D9545; Wed, 05 Nov 2014 07:28:02 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415172479!12618189!2
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12373 invoked from network); 5 Nov 2014 07:28:01 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-27.messagelabs.com with SMTP;
	5 Nov 2014 07:28:01 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 04 Nov 2014 23:28:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="411671851"
Received: from tchen0-linux.bj.intel.com ([10.238.135.73])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Nov 2014 23:19:29 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: mst@redhat.com, pbonzini@redhat.com, rth@twiddle.net, aliguori@amazon.com
Date: Wed,  5 Nov 2014 15:22:59 +0800
Message-Id: <1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa bridge
	specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently IGD drivers always need to access PCH by 1f.0, and
PCH vendor/device id is used to identify the card.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index b559181..b19c7a9 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -50,7 +50,7 @@
 #include "cpu.h"
 #include "qemu/error-report.h"
 #ifdef CONFIG_XEN
-#  include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/hvm_info_table.h>
 #endif
 
 #define MAX_IDE_BUS 2
@@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
 }
 
 #ifdef CONFIG_XEN
+static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
+{
+    struct PCIDevice *dev;
+    Error *local_err = NULL;
+    uint16_t device_id = 0xffff;
+
+    /* Currently IGD drivers always need to access PCH by 1f.0. */
+    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
+                            "xen-igd-passthrough-isa-bridge");
+
+    /* Identify PCH card with its own real vendor/device ids.
+     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
+     */
+    if (dev) {
+        device_id = object_property_get_int(OBJECT(dev), "device-id",
+                                            &local_err);
+        if (!local_err && device_id != 0xffff) {
+            pci_config_set_device_id(dev->config, device_id);
+            return;
+        }
+    }
+
+    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
+}
+
 static void pc_xen_hvm_init(MachineState *machine)
 {
     PCIBus *bus;
@@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
     bus = pci_find_primary_bus();
     if (bus != NULL) {
         pci_create_simple(bus, -1, "xen-platform");
+        xen_igd_passthrough_isa_bridge_create(bus);
     }
 }
 #endif
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 07:28:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 07: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 1Xlv0e-0003dQ-UK; Wed, 05 Nov 2014 07:28:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xlv0d-0003dC-Ak
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 07:28:03 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	D4/75-02696-281D9545; Wed, 05 Nov 2014 07:28:02 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415172479!12618189!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12310 invoked from network); 5 Nov 2014 07:28:00 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-27.messagelabs.com with SMTP;
	5 Nov 2014 07:28:00 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 04 Nov 2014 23:27:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="411671840"
Received: from tchen0-linux.bj.intel.com ([10.238.135.73])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Nov 2014 23:19:27 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: mst@redhat.com, pbonzini@redhat.com, rth@twiddle.net, aliguori@amazon.com
Date: Wed,  5 Nov 2014 15:22:58 +0800
Message-Id: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [RFC][PATCH 1/2] hw:xen:xen_pt: register isa bridge
	specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need this instance to passthrough some config fields of PCH.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 hw/xen/xen_pt.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index c1bf357..403c33f 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -60,6 +60,7 @@
 #include "xen_pt.h"
 #include "qemu/range.h"
 #include "exec/address-spaces.h"
+#include "qapi/visitor.h"
 
 #define XEN_PT_NR_IRQS (256)
 static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
@@ -829,3 +830,114 @@ static void xen_pci_passthrough_register_types(void)
 }
 
 type_init(xen_pci_passthrough_register_types)
+
+typedef struct {
+    uint16_t gpu_device_id;
+    uint16_t pch_device_id;
+} XenIGDDeviceIDInfo;
+
+/* In real world different GPU should have different PCH. But actually
+ * the different PCH DIDs likely map to different PCH SKUs. We do the
+ * same thing for the GPU. For PCH, the different SKUs are going to be
+ * all the same silicon design and implementation, just different
+ * features turn on and off with fuses. The SW interfaces should be
+ * consistent across all SKUs in a given family (eg LPT). But just same
+ * features may not be supported.
+ *
+ * Most of these different PCH features probably don't matter to the
+ * Gfx driver, but obviously any difference in display port connections
+ * will so it should be fine with any PCH in case of passthrough.
+ *
+ * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
+ * scenarios, 0x9cc3 for BDW(Broadwell).
+ */
+static const XenIGDDeviceIDInfo xen_igd_combo_id_infos[] = {
+    /* HSW Classic */
+    {0x0402, 0x8c4e}, /* HSWGT1D, HSWD_w7 */
+    {0x0406, 0x8c4e}, /* HSWGT1M, HSWM_w7 */
+    {0x0412, 0x8c4e}, /* HSWGT2D, HSWD_w7 */
+    {0x0416, 0x8c4e}, /* HSWGT2M, HSWM_w7 */
+    {0x041E, 0x8c4e}, /* HSWGT15D, HSWD_w7 */
+    /* HSW ULT */
+    {0x0A06, 0x8c4e}, /* HSWGT1UT, HSWM_w7 */
+    {0x0A16, 0x8c4e}, /* HSWGT2UT, HSWM_w7 */
+    {0x0A26, 0x8c4e}, /* HSWGT3UT, HSWM_w7 */
+    {0x0A2E, 0x8c4e}, /* HSWGT3UT28W, HSWM_w7 */
+    {0x0A1E, 0x8c4e}, /* HSWGT2UX, HSWM_w7 */
+    {0x0A0E, 0x8c4e}, /* HSWGT1ULX, HSWM_w7 */
+    /* HSW CRW */
+    {0x0D26, 0x8c4e}, /* HSWGT3CW, HSWM_w7 */
+    {0x0D22, 0x8c4e}, /* HSWGT3CWDT, HSWD_w7 */
+    /* HSW Server */
+    {0x041A, 0x8c4e}, /* HSWSVGT2, HSWD_w7 */
+    /* HSW SRVR */
+    {0x040A, 0x8c4e}, /* HSWSVGT1, HSWD_w7 */
+    /* BSW */
+    {0x1606, 0x9cc3}, /* BDWULTGT1, BDWM_w7 */
+    {0x1616, 0x9cc3}, /* BDWULTGT2, BDWM_w7 */
+    {0x1626, 0x9cc3}, /* BDWULTGT3, BDWM_w7 */
+    {0x160E, 0x9cc3}, /* BDWULXGT1, BDWM_w7 */
+    {0x161E, 0x9cc3}, /* BDWULXGT2, BDWM_w7 */
+    {0x1602, 0x9cc3}, /* BDWHALOGT1, BDWM_w7 */
+    {0x1612, 0x9cc3}, /* BDWHALOGT2, BDWM_w7 */
+    {0x1622, 0x9cc3}, /* BDWHALOGT3, BDWM_w7 */
+    {0x162B, 0x9cc3}, /* BDWHALO28W, BDWM_w7 */
+    {0x162A, 0x9cc3}, /* BDWGT3WRKS, BDWM_w7 */
+    {0x162D, 0x9cc3}, /* BDWGT3SRVR, BDWM_w7 */
+};
+
+static void xen_igd_passthrough_pciisabridge_get_pci_device_id(Object *obj,
+                                                               Visitor *v,
+                                                               void *opaque,
+                                                               const char *name,
+                                                               Error **errp)
+{
+    uint32_t gpu_id = 0xffff, pch_id = 0xffff;
+    XenHostPCIDevice hdev;
+    int r = 0, num;
+
+    r = xen_host_pci_device_get(&hdev, 0, 0, 0x02, 0);
+    if (!r) {
+        gpu_id = hdev.device_id;
+
+        num = ARRAY_SIZE(xen_igd_combo_id_infos);
+        for (r = 0; r < num; r++)
+            if (gpu_id == xen_igd_combo_id_infos[r].gpu_device_id)
+                pch_id = xen_igd_combo_id_infos[r].pch_device_id;
+    }
+
+    visit_type_uint32(v, &pch_id, name, errp);
+}
+
+static void xen_igd_passthrough_isa_bridge_initfn(Object *obj)
+{
+    object_property_add(obj, "device-id", "int",
+                        xen_igd_passthrough_pciisabridge_get_pci_device_id,
+                        NULL, NULL, NULL, NULL);
+}
+
+static void xen_igd_passthrough_isa_bridge_class_init(ObjectClass *klass,
+                                                      void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    dc->desc        = "XEN IGD PASSTHROUGH ISA bridge";
+    k->class_id     = PCI_CLASS_BRIDGE_ISA;
+    k->vendor_id    = PCI_VENDOR_ID_INTEL;
+};
+
+static TypeInfo xen_igd_passthrough_isa_bridge_info = {
+    .name           = "xen-igd-passthrough-isa-bridge",
+    .parent         = TYPE_PCI_DEVICE,
+    .instance_size  = sizeof(PCIDevice),
+    .instance_init  = xen_igd_passthrough_isa_bridge_initfn,
+    .class_init     = xen_igd_passthrough_isa_bridge_class_init,
+};
+
+static void xen_igd_passthrough_isa_bridge_register_types(void)
+{
+    type_register_static(&xen_igd_passthrough_isa_bridge_info);
+}
+
+type_init(xen_igd_passthrough_isa_bridge_register_types);
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 07:28:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 07: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 1Xlv0e-0003dJ-Iq; Wed, 05 Nov 2014 07:28:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xlv0c-0003d6-Oh
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 07:28:02 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A6/A5-08051-281D9545; Wed, 05 Nov 2014 07:28:02 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415172479!12618189!2
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12373 invoked from network); 5 Nov 2014 07:28:01 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-27.messagelabs.com with SMTP;
	5 Nov 2014 07:28:01 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 04 Nov 2014 23:28:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="411671851"
Received: from tchen0-linux.bj.intel.com ([10.238.135.73])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Nov 2014 23:19:29 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: mst@redhat.com, pbonzini@redhat.com, rth@twiddle.net, aliguori@amazon.com
Date: Wed,  5 Nov 2014 15:22:59 +0800
Message-Id: <1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa bridge
	specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently IGD drivers always need to access PCH by 1f.0, and
PCH vendor/device id is used to identify the card.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index b559181..b19c7a9 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -50,7 +50,7 @@
 #include "cpu.h"
 #include "qemu/error-report.h"
 #ifdef CONFIG_XEN
-#  include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/hvm_info_table.h>
 #endif
 
 #define MAX_IDE_BUS 2
@@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
 }
 
 #ifdef CONFIG_XEN
+static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
+{
+    struct PCIDevice *dev;
+    Error *local_err = NULL;
+    uint16_t device_id = 0xffff;
+
+    /* Currently IGD drivers always need to access PCH by 1f.0. */
+    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
+                            "xen-igd-passthrough-isa-bridge");
+
+    /* Identify PCH card with its own real vendor/device ids.
+     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
+     */
+    if (dev) {
+        device_id = object_property_get_int(OBJECT(dev), "device-id",
+                                            &local_err);
+        if (!local_err && device_id != 0xffff) {
+            pci_config_set_device_id(dev->config, device_id);
+            return;
+        }
+    }
+
+    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
+}
+
 static void pc_xen_hvm_init(MachineState *machine)
 {
     PCIBus *bus;
@@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
     bus = pci_find_primary_bus();
     if (bus != NULL) {
         pci_create_simple(bus, -1, "xen-platform");
+        xen_igd_passthrough_isa_bridge_create(bus);
     }
 }
 #endif
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 07:28:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 07: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 1Xlv0e-0003dQ-UK; Wed, 05 Nov 2014 07:28:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xlv0d-0003dC-Ak
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 07:28:03 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	D4/75-02696-281D9545; Wed, 05 Nov 2014 07:28:02 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415172479!12618189!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12310 invoked from network); 5 Nov 2014 07:28:00 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-27.messagelabs.com with SMTP;
	5 Nov 2014 07:28:00 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 04 Nov 2014 23:27:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="411671840"
Received: from tchen0-linux.bj.intel.com ([10.238.135.73])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Nov 2014 23:19:27 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: mst@redhat.com, pbonzini@redhat.com, rth@twiddle.net, aliguori@amazon.com
Date: Wed,  5 Nov 2014 15:22:58 +0800
Message-Id: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [RFC][PATCH 1/2] hw:xen:xen_pt: register isa bridge
	specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need this instance to passthrough some config fields of PCH.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 hw/xen/xen_pt.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index c1bf357..403c33f 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -60,6 +60,7 @@
 #include "xen_pt.h"
 #include "qemu/range.h"
 #include "exec/address-spaces.h"
+#include "qapi/visitor.h"
 
 #define XEN_PT_NR_IRQS (256)
 static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
@@ -829,3 +830,114 @@ static void xen_pci_passthrough_register_types(void)
 }
 
 type_init(xen_pci_passthrough_register_types)
+
+typedef struct {
+    uint16_t gpu_device_id;
+    uint16_t pch_device_id;
+} XenIGDDeviceIDInfo;
+
+/* In real world different GPU should have different PCH. But actually
+ * the different PCH DIDs likely map to different PCH SKUs. We do the
+ * same thing for the GPU. For PCH, the different SKUs are going to be
+ * all the same silicon design and implementation, just different
+ * features turn on and off with fuses. The SW interfaces should be
+ * consistent across all SKUs in a given family (eg LPT). But just same
+ * features may not be supported.
+ *
+ * Most of these different PCH features probably don't matter to the
+ * Gfx driver, but obviously any difference in display port connections
+ * will so it should be fine with any PCH in case of passthrough.
+ *
+ * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
+ * scenarios, 0x9cc3 for BDW(Broadwell).
+ */
+static const XenIGDDeviceIDInfo xen_igd_combo_id_infos[] = {
+    /* HSW Classic */
+    {0x0402, 0x8c4e}, /* HSWGT1D, HSWD_w7 */
+    {0x0406, 0x8c4e}, /* HSWGT1M, HSWM_w7 */
+    {0x0412, 0x8c4e}, /* HSWGT2D, HSWD_w7 */
+    {0x0416, 0x8c4e}, /* HSWGT2M, HSWM_w7 */
+    {0x041E, 0x8c4e}, /* HSWGT15D, HSWD_w7 */
+    /* HSW ULT */
+    {0x0A06, 0x8c4e}, /* HSWGT1UT, HSWM_w7 */
+    {0x0A16, 0x8c4e}, /* HSWGT2UT, HSWM_w7 */
+    {0x0A26, 0x8c4e}, /* HSWGT3UT, HSWM_w7 */
+    {0x0A2E, 0x8c4e}, /* HSWGT3UT28W, HSWM_w7 */
+    {0x0A1E, 0x8c4e}, /* HSWGT2UX, HSWM_w7 */
+    {0x0A0E, 0x8c4e}, /* HSWGT1ULX, HSWM_w7 */
+    /* HSW CRW */
+    {0x0D26, 0x8c4e}, /* HSWGT3CW, HSWM_w7 */
+    {0x0D22, 0x8c4e}, /* HSWGT3CWDT, HSWD_w7 */
+    /* HSW Server */
+    {0x041A, 0x8c4e}, /* HSWSVGT2, HSWD_w7 */
+    /* HSW SRVR */
+    {0x040A, 0x8c4e}, /* HSWSVGT1, HSWD_w7 */
+    /* BSW */
+    {0x1606, 0x9cc3}, /* BDWULTGT1, BDWM_w7 */
+    {0x1616, 0x9cc3}, /* BDWULTGT2, BDWM_w7 */
+    {0x1626, 0x9cc3}, /* BDWULTGT3, BDWM_w7 */
+    {0x160E, 0x9cc3}, /* BDWULXGT1, BDWM_w7 */
+    {0x161E, 0x9cc3}, /* BDWULXGT2, BDWM_w7 */
+    {0x1602, 0x9cc3}, /* BDWHALOGT1, BDWM_w7 */
+    {0x1612, 0x9cc3}, /* BDWHALOGT2, BDWM_w7 */
+    {0x1622, 0x9cc3}, /* BDWHALOGT3, BDWM_w7 */
+    {0x162B, 0x9cc3}, /* BDWHALO28W, BDWM_w7 */
+    {0x162A, 0x9cc3}, /* BDWGT3WRKS, BDWM_w7 */
+    {0x162D, 0x9cc3}, /* BDWGT3SRVR, BDWM_w7 */
+};
+
+static void xen_igd_passthrough_pciisabridge_get_pci_device_id(Object *obj,
+                                                               Visitor *v,
+                                                               void *opaque,
+                                                               const char *name,
+                                                               Error **errp)
+{
+    uint32_t gpu_id = 0xffff, pch_id = 0xffff;
+    XenHostPCIDevice hdev;
+    int r = 0, num;
+
+    r = xen_host_pci_device_get(&hdev, 0, 0, 0x02, 0);
+    if (!r) {
+        gpu_id = hdev.device_id;
+
+        num = ARRAY_SIZE(xen_igd_combo_id_infos);
+        for (r = 0; r < num; r++)
+            if (gpu_id == xen_igd_combo_id_infos[r].gpu_device_id)
+                pch_id = xen_igd_combo_id_infos[r].pch_device_id;
+    }
+
+    visit_type_uint32(v, &pch_id, name, errp);
+}
+
+static void xen_igd_passthrough_isa_bridge_initfn(Object *obj)
+{
+    object_property_add(obj, "device-id", "int",
+                        xen_igd_passthrough_pciisabridge_get_pci_device_id,
+                        NULL, NULL, NULL, NULL);
+}
+
+static void xen_igd_passthrough_isa_bridge_class_init(ObjectClass *klass,
+                                                      void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    dc->desc        = "XEN IGD PASSTHROUGH ISA bridge";
+    k->class_id     = PCI_CLASS_BRIDGE_ISA;
+    k->vendor_id    = PCI_VENDOR_ID_INTEL;
+};
+
+static TypeInfo xen_igd_passthrough_isa_bridge_info = {
+    .name           = "xen-igd-passthrough-isa-bridge",
+    .parent         = TYPE_PCI_DEVICE,
+    .instance_size  = sizeof(PCIDevice),
+    .instance_init  = xen_igd_passthrough_isa_bridge_initfn,
+    .class_init     = xen_igd_passthrough_isa_bridge_class_init,
+};
+
+static void xen_igd_passthrough_isa_bridge_register_types(void)
+{
+    type_register_static(&xen_igd_passthrough_isa_bridge_info);
+}
+
+type_init(xen_igd_passthrough_isa_bridge_register_types);
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:17:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09: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 1XlwiL-0006LI-V7; Wed, 05 Nov 2014 09:17:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlwiK-0006LD-GB
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 09:17:16 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	EF/1E-01660-B1BE9545; Wed, 05 Nov 2014 09:17:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415179026!7165145!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17058 invoked from network); 5 Nov 2014 09:17:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:17:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188237171"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 04:17:00 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xlwi4-0003Z8-77;
	Wed, 05 Nov 2014 09:17:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xlwi4-0006w4-11;
	Wed, 05 Nov 2014 09:17:00 +0000
Date: Wed, 5 Nov 2014 09:17:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31377-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31377: 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 31377 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31377/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-i386-xl-credit2    9 guest-start             fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     12 guest-localmigrate      fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-i386-xl            9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate.2    fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 guest-localmigrate fail baseline untested
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                f265a73e151794845e801fb065e3fa37f0ec26c2
baseline version:
 linux                12d7aacab56e9ef185c3a5512e867bfd3a9504e4

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:17:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09: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 1XlwiL-0006LI-V7; Wed, 05 Nov 2014 09:17:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlwiK-0006LD-GB
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 09:17:16 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	EF/1E-01660-B1BE9545; Wed, 05 Nov 2014 09:17:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415179026!7165145!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17058 invoked from network); 5 Nov 2014 09:17:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:17:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188237171"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 04:17:00 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xlwi4-0003Z8-77;
	Wed, 05 Nov 2014 09:17:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xlwi4-0006w4-11;
	Wed, 05 Nov 2014 09:17:00 +0000
Date: Wed, 5 Nov 2014 09:17:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31377-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31377: 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 31377 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31377/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-i386-xl-credit2    9 guest-start             fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     12 guest-localmigrate      fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-i386-xl            9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate.2    fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 guest-localmigrate fail baseline untested
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                f265a73e151794845e801fb065e3fa37f0ec26c2
baseline version:
 linux                12d7aacab56e9ef185c3a5512e867bfd3a9504e4

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:20:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlwln-0006SG-KW; Wed, 05 Nov 2014 09:20: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 1Xlwlm-0006S9-EW
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:20:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	83/BE-09936-1FBE9545; Wed, 05 Nov 2014 09:20:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415179248!12884377!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10609 invoked from network); 5 Nov 2014 09:20:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:20:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188238546"
Message-ID: <1415179244.11486.55.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 5 Nov 2014 09:20:44 +0000
In-Reply-To: <20141104200006.GD12464@laptop.dumpdata.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
	<54591EB8.4070007@citrix.com>
	<20141104200006.GD12464@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
Content-Length: 3255
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, George Dunlap <George.Dunlap@citrix.com>,
	xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDE0LTExLTA0IGF0IDE1OjAwIC0wNTAwLCBLb25yYWQgUnplc3p1dGVrIFdpbGsg
d3JvdGU6Cj4gT24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMDY6NDU6MTJQTSArMDAwMCwgQW5kcmV3
IENvb3BlciB3cm90ZToKPiA+IE9uIDA0LzExLzE0IDE4OjQyLCBLb25yYWQgUnplc3p1dGVrIFdp
bGsgd3JvdGU6Cj4gPiA+IE9uIFR1ZSwgTm92IDA0LCAyMDE0IGF0IDA2OjA3OjE5UE0gKzAwMDAs
IEFuZHJldyBDb29wZXIgd3JvdGU6Cj4gPiA+PiBPbiAwNC8xMS8xNCAxNzozMiwgS29ucmFkIFJ6
ZXN6dXRlayBXaWxrIHdyb3RlOgo+ID4gPj4+IE9uIFR1ZSwgTm92IDA0LCAyMDE0IGF0IDExOjUy
OjQ3QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+ID4+Pj4gVGhpcyB3YXMgZGlzYWJs
ZWQgYnkgZGVmYXVsdCBpbiBYZW4gNC40LiBTaW5jZSB4ZW5kIGhhcyBub3cgYmVlbiByZW1vdmVk
IGZyb20KPiA+ID4+Pj4gdGhlIHRyZWUgSSBkb24ndCBiZWxpZXZlIGFueXRoaW5nIGlzIHVzaW5n
IGl0Lgo+ID4gPj4+IFdoYXQgYWJvdXQgWGVuU2VydmVyPwo+ID4gPj4gV2UgYXJlIG1vc3QgZGVm
aW5pdGVseSBub3QgdXNpbmcgaXQsIGFuZCBoYXZlbuKAmXQgdXNlZCBpdCBpbiBhIHZlcnkgbG9u
Zwo+ID4gPj4gdGltZS4gV2UgZXhwbGljaXRseSBudWtlIEJMS1RBUDEgYW5kIEJMS1RBUDIgZnJv
bSB0aGUgWGVuIGJ1aWxkLgo+ID4gPj4KPiA+ID4+PiBBbmQgaXNuJ3QgdGhlcmUgc29tZSBibGt0
YXAzID8KPiA+ID4+IGh0dHBzOi8vZ2l0aHViLmNvbS94YXBpLXByb2plY3QvYmxrdGFwCj4gPiA+
Pgo+ID4gPj4+PiBXZSBuZWVkIHRvIHBhc3MgYW4gZXhwbGljaXQgQ09ORklHX0JMS1RBUDE9biB0
byBxZW11LXhlbi10cmFkaXRpb25hbCBvdGhlcndpc2UKPiA+ID4+Pj4gaXQgZGVmYXVsdHMgdG8g
eSBhbmQgZG9lc24ndCBidWlsZC4KPiA+ID4+Pj4KPiA+ID4+Pj4gU2lnbmVkLW9mZi1ieTogSWFu
IENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPiA+ID4+Pj4gQ2M6IEtvbnJhZCBS
emVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPiA+ID4+Pj4gLS0tCj4gPiA+
Pj4+IEkgdGhpbmsgdGhpcyBoYXMgcHJvYmFibHkgbWlzc2VkIHRoZSBib2F0IGZvciA0LjUgYW5k
IHRoZXJlIGlzbid0IG11Y2ggaGFybSBpbgo+ID4gPj4+PiB3YWl0aW5nIGZvciA0LjYuIEknbSBv
cGVuIHRvIGJlaW5nIHRvbGQgb3RoZXJ3aXNlIHRob3VnaCA7LSkKPiA+ID4+PiBZb3UgcmVhbGx5
IHdhbnQgdG8gYmUgYXQgdGhlIHRvcCBvZiB0aGUgY29tbWl0IGxpc3Qgd2l0aCB0aGUgbW9zdCBk
ZWxldGVkCj4gPiA+Pj4gY29kZSwgZWg/Cj4gPiA+PiAvbWUgc3VzcGVjdHMgdGhhdCBoZSBpcyBh
bHJlYWR5LCBidXQgSSBmb3Igb25lIGFtIGEgZmFuIG9mIHBydW5pbmcgZGVhZAo+ID4gPj4gY29k
ZS4KPiA+ID4gVHJ1ZSwgYnV0IHdlIGRpZCB0YWxrIGFib3V0IHhlbmQgcmVtb3ZhbCBmb3IgcXVp
dGUgYSB3aGlsZSBiZWZvcmUgZG9pbmcgaXQuCj4gPiA+Cj4gPiA+IEhvd2V2ZXIsIEkgYmVsaWV2
ZSB0aGF0IHRoZSBmb2xrcyB0aGF0IGRpZCBSZW11cyBsb29rIHRvIGJlIHVzaW5nIGl0Cj4gPiA+
IChBbmQgdGhleSBoYXZlIHRvbnMgb2YgcGF0Y2hlcyBhZ2FpbnN0IGl0KS4KPiA+ID4KPiA+ID4K
PiA+ID4gICAgSXQgaXMgdW5jbGVhciB0byBtZSB3aGV0aGVyIHRoZXk6Cj4gPiA+IAktIHdhbnQg
dG8gYmUgdGhlIG1haW50YWluZXJzIG9mIGl0Pwo+ID4gPiAJLSB3YW50IHRvIHVzZSBibGt0YXAz
IGJ1dCBoYXZlbid0IHlldCBiYWNrcG9ydGVkIHRoZWlyIHBhdGNoZXMuCj4gPiAKPiA+IFRoZSBy
ZW11cyBwYXRjaGVzIGFyZSBhZ2FpbnN0IGJsa3RhcDIsIG5vdCBibGt0YXAxLiAgV2UgY3VycmVu
dGx5IGhhdmUKPiA+IGJvdGggaW4tdHJlZS4KPiAKPiA8c2xhcHMgaGlzIGhlYWQ+Cj4gCj4gT0ss
IHNvIGJsa3RhcDEgLSBkZWFkLiBUaGF0IGxvb2tzIGxpa2UgaXQgY291bGQgZ28gdW5kZXIgdGhl
IGtuaWZlIG5vdy4KCklNSE8geWVzIGl0IGNvdWxkLgoKPiBibGt0YXAyIC0gd2FpdGluZyBmb3Ig
cmVzcG9uc2UKClRoaXMgc2hvdWxkIHN0YXksIGF0IGxlYXN0IGZvciB0aGUgdGltZSBiZWluZywg
YW5kIGNlcnRhaW5seSBmb3IgNC41LgoKPiBJcyB0aGUgbG9uZy10ZXJtIGlkZWEgdG8gcHV0ICdi
bGt0YXAzJyBpbiB0aGUgdHJlZT8KCkkgZG9uJ3QgdGhpbmsgc28uCgpHZW9yZ2Ugd2FzIGdvaW5n
IHRvIG1ha2UgYSBwcm9wb3NhbCBhYm91dCBmdXR1cmUgcGxhbnMgZm9yIGJsa3RhcCouCgpJYW4u
CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVu
Lm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:20:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlwln-0006SG-KW; Wed, 05 Nov 2014 09:20: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 1Xlwlm-0006S9-EW
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:20:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	83/BE-09936-1FBE9545; Wed, 05 Nov 2014 09:20:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415179248!12884377!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10609 invoked from network); 5 Nov 2014 09:20:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:20:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188238546"
Message-ID: <1415179244.11486.55.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 5 Nov 2014 09:20:44 +0000
In-Reply-To: <20141104200006.GD12464@laptop.dumpdata.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
	<54591EB8.4070007@citrix.com>
	<20141104200006.GD12464@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
Content-Length: 3255
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, George Dunlap <George.Dunlap@citrix.com>,
	xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDE0LTExLTA0IGF0IDE1OjAwIC0wNTAwLCBLb25yYWQgUnplc3p1dGVrIFdpbGsg
d3JvdGU6Cj4gT24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMDY6NDU6MTJQTSArMDAwMCwgQW5kcmV3
IENvb3BlciB3cm90ZToKPiA+IE9uIDA0LzExLzE0IDE4OjQyLCBLb25yYWQgUnplc3p1dGVrIFdp
bGsgd3JvdGU6Cj4gPiA+IE9uIFR1ZSwgTm92IDA0LCAyMDE0IGF0IDA2OjA3OjE5UE0gKzAwMDAs
IEFuZHJldyBDb29wZXIgd3JvdGU6Cj4gPiA+PiBPbiAwNC8xMS8xNCAxNzozMiwgS29ucmFkIFJ6
ZXN6dXRlayBXaWxrIHdyb3RlOgo+ID4gPj4+IE9uIFR1ZSwgTm92IDA0LCAyMDE0IGF0IDExOjUy
OjQ3QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+ID4+Pj4gVGhpcyB3YXMgZGlzYWJs
ZWQgYnkgZGVmYXVsdCBpbiBYZW4gNC40LiBTaW5jZSB4ZW5kIGhhcyBub3cgYmVlbiByZW1vdmVk
IGZyb20KPiA+ID4+Pj4gdGhlIHRyZWUgSSBkb24ndCBiZWxpZXZlIGFueXRoaW5nIGlzIHVzaW5n
IGl0Lgo+ID4gPj4+IFdoYXQgYWJvdXQgWGVuU2VydmVyPwo+ID4gPj4gV2UgYXJlIG1vc3QgZGVm
aW5pdGVseSBub3QgdXNpbmcgaXQsIGFuZCBoYXZlbuKAmXQgdXNlZCBpdCBpbiBhIHZlcnkgbG9u
Zwo+ID4gPj4gdGltZS4gV2UgZXhwbGljaXRseSBudWtlIEJMS1RBUDEgYW5kIEJMS1RBUDIgZnJv
bSB0aGUgWGVuIGJ1aWxkLgo+ID4gPj4KPiA+ID4+PiBBbmQgaXNuJ3QgdGhlcmUgc29tZSBibGt0
YXAzID8KPiA+ID4+IGh0dHBzOi8vZ2l0aHViLmNvbS94YXBpLXByb2plY3QvYmxrdGFwCj4gPiA+
Pgo+ID4gPj4+PiBXZSBuZWVkIHRvIHBhc3MgYW4gZXhwbGljaXQgQ09ORklHX0JMS1RBUDE9biB0
byBxZW11LXhlbi10cmFkaXRpb25hbCBvdGhlcndpc2UKPiA+ID4+Pj4gaXQgZGVmYXVsdHMgdG8g
eSBhbmQgZG9lc24ndCBidWlsZC4KPiA+ID4+Pj4KPiA+ID4+Pj4gU2lnbmVkLW9mZi1ieTogSWFu
IENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPiA+ID4+Pj4gQ2M6IEtvbnJhZCBS
emVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPiA+ID4+Pj4gLS0tCj4gPiA+
Pj4+IEkgdGhpbmsgdGhpcyBoYXMgcHJvYmFibHkgbWlzc2VkIHRoZSBib2F0IGZvciA0LjUgYW5k
IHRoZXJlIGlzbid0IG11Y2ggaGFybSBpbgo+ID4gPj4+PiB3YWl0aW5nIGZvciA0LjYuIEknbSBv
cGVuIHRvIGJlaW5nIHRvbGQgb3RoZXJ3aXNlIHRob3VnaCA7LSkKPiA+ID4+PiBZb3UgcmVhbGx5
IHdhbnQgdG8gYmUgYXQgdGhlIHRvcCBvZiB0aGUgY29tbWl0IGxpc3Qgd2l0aCB0aGUgbW9zdCBk
ZWxldGVkCj4gPiA+Pj4gY29kZSwgZWg/Cj4gPiA+PiAvbWUgc3VzcGVjdHMgdGhhdCBoZSBpcyBh
bHJlYWR5LCBidXQgSSBmb3Igb25lIGFtIGEgZmFuIG9mIHBydW5pbmcgZGVhZAo+ID4gPj4gY29k
ZS4KPiA+ID4gVHJ1ZSwgYnV0IHdlIGRpZCB0YWxrIGFib3V0IHhlbmQgcmVtb3ZhbCBmb3IgcXVp
dGUgYSB3aGlsZSBiZWZvcmUgZG9pbmcgaXQuCj4gPiA+Cj4gPiA+IEhvd2V2ZXIsIEkgYmVsaWV2
ZSB0aGF0IHRoZSBmb2xrcyB0aGF0IGRpZCBSZW11cyBsb29rIHRvIGJlIHVzaW5nIGl0Cj4gPiA+
IChBbmQgdGhleSBoYXZlIHRvbnMgb2YgcGF0Y2hlcyBhZ2FpbnN0IGl0KS4KPiA+ID4KPiA+ID4K
PiA+ID4gICAgSXQgaXMgdW5jbGVhciB0byBtZSB3aGV0aGVyIHRoZXk6Cj4gPiA+IAktIHdhbnQg
dG8gYmUgdGhlIG1haW50YWluZXJzIG9mIGl0Pwo+ID4gPiAJLSB3YW50IHRvIHVzZSBibGt0YXAz
IGJ1dCBoYXZlbid0IHlldCBiYWNrcG9ydGVkIHRoZWlyIHBhdGNoZXMuCj4gPiAKPiA+IFRoZSBy
ZW11cyBwYXRjaGVzIGFyZSBhZ2FpbnN0IGJsa3RhcDIsIG5vdCBibGt0YXAxLiAgV2UgY3VycmVu
dGx5IGhhdmUKPiA+IGJvdGggaW4tdHJlZS4KPiAKPiA8c2xhcHMgaGlzIGhlYWQ+Cj4gCj4gT0ss
IHNvIGJsa3RhcDEgLSBkZWFkLiBUaGF0IGxvb2tzIGxpa2UgaXQgY291bGQgZ28gdW5kZXIgdGhl
IGtuaWZlIG5vdy4KCklNSE8geWVzIGl0IGNvdWxkLgoKPiBibGt0YXAyIC0gd2FpdGluZyBmb3Ig
cmVzcG9uc2UKClRoaXMgc2hvdWxkIHN0YXksIGF0IGxlYXN0IGZvciB0aGUgdGltZSBiZWluZywg
YW5kIGNlcnRhaW5seSBmb3IgNC41LgoKPiBJcyB0aGUgbG9uZy10ZXJtIGlkZWEgdG8gcHV0ICdi
bGt0YXAzJyBpbiB0aGUgdHJlZT8KCkkgZG9uJ3QgdGhpbmsgc28uCgpHZW9yZ2Ugd2FzIGdvaW5n
IHRvIG1ha2UgYSBwcm9wb3NhbCBhYm91dCBmdXR1cmUgcGxhbnMgZm9yIGJsa3RhcCouCgpJYW4u
CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVu
Lm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:21:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 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.xen.org>)
	id 1Xlwmb-0006X2-43; Wed, 05 Nov 2014 09:21:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XlwmZ-0006Wk-Vw
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:21:40 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	87/64-29352-32CE9545; Wed, 05 Nov 2014 09:21:39 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415179297!11279897!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8188 invoked from network); 5 Nov 2014 09:21:38 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-206.messagelabs.com with SMTP;
	5 Nov 2014 09:21:38 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 05 Nov 2014 01:21:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,319,1413270000"; d="scan'208";a="631787445"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga002.jf.intel.com with ESMTP; 05 Nov 2014 01:21:33 -0800
Received: from pgsmsx105.gar.corp.intel.com (10.221.44.96) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 17:18:47 +0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 17:18:47 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.13]) with mapi id
	14.03.0195.001; Wed, 5 Nov 2014 17:18:46 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
	machine
Thread-Index: AQHP91mlLJNh4IXOT0KpYuzQIm5vr5xRwUyw
Date: Wed, 5 Nov 2014 09:18:46 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E81FD36@SHSMSX101.ccr.corp.intel.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031126170.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411031126170.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
 machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Monday, November 03, 2014 7:30 PM
> To: Xu, Quan
> Cc: xen-devel@lists.xen.org; keir@xen.org; ian.campbell@citrix.com;
> tim@xen.org; ian.jackson@eu.citrix.com; jbeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> virtual machine
> 
> On Thu, 30 Oct 2014, Quan Xu wrote:
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> >
> > This patch series are only the Xen part to enable stubdom vTPM for HVM
> virtual machine.
> > it will work w/ Qemu patch series and seaBios patch series. Change
> > QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the
> Qemu/SeaBios patch series are merged.
> 
> Please, could you add more detailed commit messages in your patches?
> Also spending a few more words here to explain why are you doing this and
> how would help.
> 
The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality
to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to
interact with a TPM in a virtual machine the same way they interact with a TPM on the
physical system. Each virtual machine gets its own unique, emulated, software TPM.
Each major component of vTPM is implemented as a stubdom, providing secure separation
guaranteed by the hypervisor.
The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine
to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed
from mini-os TPM backend driver.

This patch series are to enable Xen stubdom vTPM for HVM virtual machine. his allows 
programs to interact with a TPM in a HVM virtual machine(Fedora, Ubuntu, Redhat, Windows .etc)
the same way they interact with a TPM on the physical system.


> It looks like you are trying to introduce vTPM stubdomains. The QEMU
> changes have been posted against upstream QEMU, that is good, however as
> far as I know upstream QEMU doesn't build or work as a stubdomain yet.
> Where are the changes to make upstream QEMU based stubdoms work?
> I don't see them neither here nor in the QEMU series.
> 
It's Xen stubdom, not QEMU stubdom. Sorry for this confusion. 

> How are you testing this work?


The following steps are how to build and test it: 

1. SeaBios with my patch against upstream seabios is not submitted. I will submit seabios patch when I 
finish these questions from review. Now I archive my seabios patch against upstream seabios in 
Github: https://github.com/virt2x/seabios2 , try to build it for test. 

Configure it with Xen,
--- <Xen> Config.mk
-SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
+SEABIOS_UPSTREAM_URL ?= https://github.com/virt2x/seabios2
[...]
-SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
+SEABIOS_UPSTREAM_REVISION ?= ea94c083cc15875f46f0bf288b6531154b866f5a

2. qemu with my patch against upstream QEMU is not merged. now I archive my 
qemu patch series again Upstream QEMU in github: https://github.com/virt2x/qemu-xen-unstable2 

Configure it with Xen, 
--- <Xen> Config.mk

-QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
+QEMU_UPSTREAM_URL ?= https://github.com/virt2x/qemu-xen-unstable2
-QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc1
+QEMU_UPSTREAM_REVISION ?= e867e6cf86c8412ca516cf2d0ccad57130e3388c

3. build/install Xen
Change QEMU_STUBDOM_VTPM option from 'n' to 'y'
   QEMU_STUBDOM_VTPM ?= y
./configure --prefix=/usr
make dist
make install 

4. try to launch vtpmmgr / vtpm domain via <Xen>/docs/misc/vtpm-platforms.txt.
The reader is assumed to have familiarity with building and installing Xen, Linux, and a basic 
understanding of the TPM and vTPM concepts.

The Linux / Windows HVM guest configuration file needs to be modified to include the following line:
[..]
vtpm=["backend=domu-vtpm"]
device_model_version = 'qemu-xen'
acpi = 1
[..]

## domu-vtpm is the name vtpm domain, A mini-os stub domain that implements a vTPM. 

5. enable native TPM 1.2 drvier in HVM virtual machine. for example enable tpm_tis.ko in Linux 
HVM virtual machine. 
If you have trousers and tpm_tools installed on the guest, the tpm_version
command should return the following:

The version command should return the following:
  TPM 1.2 Version Info:
  Chip Version:        1.2.0.7
  Spec Level:          2
  Errata Revision:     1
  TPM Vendor ID:       ETHZ
  TPM Version:         01010000
  Manufacturer Info:   4554485a

Or check it with sysfs, /sys/class/misc/tpm0


BTW, Some local ISV are trying to integrate this feature into their cloud service for trusted services, 
Such as trusted virtual desktop infrastructure(HVM fedora/ubuntu/redhat/windows virtual machine).


> 
> 
> >  Config.mk                             |  4 ++++
> >  extras/mini-os/include/tpmback.h      |  3 +++
> >  extras/mini-os/tpmback.c              | 20 +++++++++++++++++---
> >  tools/Makefile                        |  7 +++++++
> >  tools/firmware/hvmloader/acpi/build.c |  5 +++--
> >  tools/libxl/libxl.c                   | 62
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++
> >  tools/libxl/libxl_create.c            | 16 +++++++++++++---
> >  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
> >  tools/libxl/libxl_dom.c               |  2 ++
> >  tools/libxl/libxl_internal.h          |  3 +++
> >  tools/libxl/libxl_types.idl           |  1 +
> >  tools/libxl/xl_cmdimpl.c              |  2 ++
> >  xen/arch/x86/hvm/hvm.c                |  3 +++
> >  xen/include/public/hvm/params.h       |  1 +
> >
> > I've tried to break it down to smaller patches:
> >
> >  *(Patch 1/6)*  event channel bind interdomain with para/hvm virtual
> > machine
> >
> >  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for HVM
> virtual
> > machine
> >
> >  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual
> > machine
> >
> >  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine when
> > vTPM is added
> >
> >  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> >
> >  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:21:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 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.xen.org>)
	id 1Xlwmb-0006X2-43; Wed, 05 Nov 2014 09:21:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XlwmZ-0006Wk-Vw
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:21:40 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	87/64-29352-32CE9545; Wed, 05 Nov 2014 09:21:39 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415179297!11279897!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8188 invoked from network); 5 Nov 2014 09:21:38 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-206.messagelabs.com with SMTP;
	5 Nov 2014 09:21:38 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 05 Nov 2014 01:21:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,319,1413270000"; d="scan'208";a="631787445"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga002.jf.intel.com with ESMTP; 05 Nov 2014 01:21:33 -0800
Received: from pgsmsx105.gar.corp.intel.com (10.221.44.96) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 17:18:47 +0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 17:18:47 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.13]) with mapi id
	14.03.0195.001; Wed, 5 Nov 2014 17:18:46 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
	machine
Thread-Index: AQHP91mlLJNh4IXOT0KpYuzQIm5vr5xRwUyw
Date: Wed, 5 Nov 2014 09:18:46 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E81FD36@SHSMSX101.ccr.corp.intel.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031126170.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411031126170.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
 machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Monday, November 03, 2014 7:30 PM
> To: Xu, Quan
> Cc: xen-devel@lists.xen.org; keir@xen.org; ian.campbell@citrix.com;
> tim@xen.org; ian.jackson@eu.citrix.com; jbeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> virtual machine
> 
> On Thu, 30 Oct 2014, Quan Xu wrote:
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> >
> > This patch series are only the Xen part to enable stubdom vTPM for HVM
> virtual machine.
> > it will work w/ Qemu patch series and seaBios patch series. Change
> > QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the
> Qemu/SeaBios patch series are merged.
> 
> Please, could you add more detailed commit messages in your patches?
> Also spending a few more words here to explain why are you doing this and
> how would help.
> 
The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality
to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to
interact with a TPM in a virtual machine the same way they interact with a TPM on the
physical system. Each virtual machine gets its own unique, emulated, software TPM.
Each major component of vTPM is implemented as a stubdom, providing secure separation
guaranteed by the hypervisor.
The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine
to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed
from mini-os TPM backend driver.

This patch series are to enable Xen stubdom vTPM for HVM virtual machine. his allows 
programs to interact with a TPM in a HVM virtual machine(Fedora, Ubuntu, Redhat, Windows .etc)
the same way they interact with a TPM on the physical system.


> It looks like you are trying to introduce vTPM stubdomains. The QEMU
> changes have been posted against upstream QEMU, that is good, however as
> far as I know upstream QEMU doesn't build or work as a stubdomain yet.
> Where are the changes to make upstream QEMU based stubdoms work?
> I don't see them neither here nor in the QEMU series.
> 
It's Xen stubdom, not QEMU stubdom. Sorry for this confusion. 

> How are you testing this work?


The following steps are how to build and test it: 

1. SeaBios with my patch against upstream seabios is not submitted. I will submit seabios patch when I 
finish these questions from review. Now I archive my seabios patch against upstream seabios in 
Github: https://github.com/virt2x/seabios2 , try to build it for test. 

Configure it with Xen,
--- <Xen> Config.mk
-SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
+SEABIOS_UPSTREAM_URL ?= https://github.com/virt2x/seabios2
[...]
-SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
+SEABIOS_UPSTREAM_REVISION ?= ea94c083cc15875f46f0bf288b6531154b866f5a

2. qemu with my patch against upstream QEMU is not merged. now I archive my 
qemu patch series again Upstream QEMU in github: https://github.com/virt2x/qemu-xen-unstable2 

Configure it with Xen, 
--- <Xen> Config.mk

-QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
+QEMU_UPSTREAM_URL ?= https://github.com/virt2x/qemu-xen-unstable2
-QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc1
+QEMU_UPSTREAM_REVISION ?= e867e6cf86c8412ca516cf2d0ccad57130e3388c

3. build/install Xen
Change QEMU_STUBDOM_VTPM option from 'n' to 'y'
   QEMU_STUBDOM_VTPM ?= y
./configure --prefix=/usr
make dist
make install 

4. try to launch vtpmmgr / vtpm domain via <Xen>/docs/misc/vtpm-platforms.txt.
The reader is assumed to have familiarity with building and installing Xen, Linux, and a basic 
understanding of the TPM and vTPM concepts.

The Linux / Windows HVM guest configuration file needs to be modified to include the following line:
[..]
vtpm=["backend=domu-vtpm"]
device_model_version = 'qemu-xen'
acpi = 1
[..]

## domu-vtpm is the name vtpm domain, A mini-os stub domain that implements a vTPM. 

5. enable native TPM 1.2 drvier in HVM virtual machine. for example enable tpm_tis.ko in Linux 
HVM virtual machine. 
If you have trousers and tpm_tools installed on the guest, the tpm_version
command should return the following:

The version command should return the following:
  TPM 1.2 Version Info:
  Chip Version:        1.2.0.7
  Spec Level:          2
  Errata Revision:     1
  TPM Vendor ID:       ETHZ
  TPM Version:         01010000
  Manufacturer Info:   4554485a

Or check it with sysfs, /sys/class/misc/tpm0


BTW, Some local ISV are trying to integrate this feature into their cloud service for trusted services, 
Such as trusted virtual desktop infrastructure(HVM fedora/ubuntu/redhat/windows virtual machine).


> 
> 
> >  Config.mk                             |  4 ++++
> >  extras/mini-os/include/tpmback.h      |  3 +++
> >  extras/mini-os/tpmback.c              | 20 +++++++++++++++++---
> >  tools/Makefile                        |  7 +++++++
> >  tools/firmware/hvmloader/acpi/build.c |  5 +++--
> >  tools/libxl/libxl.c                   | 62
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++
> >  tools/libxl/libxl_create.c            | 16 +++++++++++++---
> >  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
> >  tools/libxl/libxl_dom.c               |  2 ++
> >  tools/libxl/libxl_internal.h          |  3 +++
> >  tools/libxl/libxl_types.idl           |  1 +
> >  tools/libxl/xl_cmdimpl.c              |  2 ++
> >  xen/arch/x86/hvm/hvm.c                |  3 +++
> >  xen/include/public/hvm/params.h       |  1 +
> >
> > I've tried to break it down to smaller patches:
> >
> >  *(Patch 1/6)*  event channel bind interdomain with para/hvm virtual
> > machine
> >
> >  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for HVM
> virtual
> > machine
> >
> >  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual
> > machine
> >
> >  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine when
> > vTPM is added
> >
> >  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> >
> >  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:26:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlwqo-0006s2-Rb; Wed, 05 Nov 2014 09:26:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlwqo-0006rt-2b
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 09:26:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	30/AD-09842-92DE9545; Wed, 05 Nov 2014 09:26:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415179559!12886029!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27204 invoked from network); 5 Nov 2014 09:26:00 -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;
	5 Nov 2014 09:26:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189637105"
Message-ID: <1415179557.11486.57.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 5 Nov 2014 09:25:57 +0000
In-Reply-To: <21593.3655.232310.365186@mariner.uk.xensource.com>
References: <osstest-31315-mainreport@xen.org>
	<5457641C02000078000444BA@mail.emea.novell.com>
	<1415010873.9994.14.camel@citrix.com>
	<21593.3655.232310.365186@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 17:35 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL"):
> > It's a shame /etc/init.d/osstest-confirm-booted isn't more verbose on
> > the console, since this is what appears to have failed (i.e. the ssh bit
> > seems to have worked, so I don't think it was networking/dns/etc).
> 
> I have some patches to fix this, which I will send in just a moment.

Both look good to me, Acked-by: Ian Campbell <ian.campbell@citrix.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:26:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlwqo-0006s2-Rb; Wed, 05 Nov 2014 09:26:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlwqo-0006rt-2b
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 09:26:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	30/AD-09842-92DE9545; Wed, 05 Nov 2014 09:26:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415179559!12886029!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27204 invoked from network); 5 Nov 2014 09:26:00 -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;
	5 Nov 2014 09:26:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189637105"
Message-ID: <1415179557.11486.57.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 5 Nov 2014 09:25:57 +0000
In-Reply-To: <21593.3655.232310.365186@mariner.uk.xensource.com>
References: <osstest-31315-mainreport@xen.org>
	<5457641C02000078000444BA@mail.emea.novell.com>
	<1415010873.9994.14.camel@citrix.com>
	<21593.3655.232310.365186@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 17:35 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 31315: regressions - FAIL"):
> > It's a shame /etc/init.d/osstest-confirm-booted isn't more verbose on
> > the console, since this is what appears to have failed (i.e. the ssh bit
> > seems to have worked, so I don't think it was networking/dns/etc).
> 
> I have some patches to fix this, which I will send in just a moment.

Both look good to me, Acked-by: Ian Campbell <ian.campbell@citrix.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:33:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlwy3-00077k-Ry; Wed, 05 Nov 2014 09:33:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlwy2-00077f-5x
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:33:30 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	04/AC-27623-9EEE9545; Wed, 05 Nov 2014 09:33:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415180007!11779693!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29328 invoked from network); 5 Nov 2014 09:33:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:33:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189638827"
Message-ID: <1415180005.11486.59.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Wed, 5 Nov 2014 09:33:25 +0000
In-Reply-To: <5459035D.5010204@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <5459035D.5010204@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 17:48 +0100, Atom2 wrote:
> Am 04.11.14 um 17:31 schrieb Ian Campbell:
> > On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
> >> Am 04.11.14 um 16:44 schrieb Ian Campbell:
> >>> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
> >>> Otherwise I think the next step would be to downgrade to 4.3.1 and see
> >>> if the problem persists, in order to rule out changes elsewhere in the
> >>> system. If the problem doesn't happen with a 4.3.1 rebuilt on your
> >>> current system then the next thing would probably be to bisect the
> >>> issue. There are only 31 toolstack changes in that range, so it ought to
> >>> only take 5-6 iterations.
> >> Unfortunately 4.3.1 is no longer available as an ebuild as 4.3.3 seemed
> >> to fix security issues and therefore 4.3.1 has been deleted from the
> >> repos. So it's not straightforward and I need to figure out how to get
> >> the old version back. But I am sure there's a way.
> >
> > I don't know anything about ebuilds, but if you end up needing to bisect
> > then building from xen.git might be useful anyway (unless you can get an
> > ebuild to trivially build some other version).
> Before I go down that route would I also need to re-compile xen (i.e. 
> the hypervisor at /boot/xen-4.3.3.gz that's being booted from grub) or 
> only xen-tools? In other words does xen-tools 4.3.1 work with the 
> hypervisor version 4.3.3 under /boot?

I think in principal within a stable branch (i.e. 4.3.x) it ought to
work, but I wouldn't swear to it. I think you can probably risk it --
the failure mode in case of a bad mismatch will be very different (liek
a permissions failure early in building a domU), so if you see anything
newly odd you could rebuild Xen.

> I wouldn't want to end up with an unbootable system.

A tools/hv mismatch won't ever stop dom0 booting, it would just stop you
starting a guest. You can always boot the kernel natively in any case.

> In terms of ebuilds: Adding patches to a version is pretty easy as 
> gentoo works from source code. So if 4.3.3 is just different by a number 
> of well defined patches from 4.3.1 then that should be straightforward 
> as applying patches is really trivial.

The git history from 4.3.1 to 4.3.3 is (as it happens) completely
linear, so something like git format patch should trivially produce a
list of patches to apply (or perhaps unapply if it is easier to work
backwards from 4.3.3). I don't know what local patches the ebuild
includes or how much conflict there will be 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 Nov 05 09:33:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlwy3-00077k-Ry; Wed, 05 Nov 2014 09:33:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlwy2-00077f-5x
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:33:30 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	04/AC-27623-9EEE9545; Wed, 05 Nov 2014 09:33:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415180007!11779693!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29328 invoked from network); 5 Nov 2014 09:33:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:33:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189638827"
Message-ID: <1415180005.11486.59.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Wed, 5 Nov 2014 09:33:25 +0000
In-Reply-To: <5459035D.5010204@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <5459035D.5010204@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 17:48 +0100, Atom2 wrote:
> Am 04.11.14 um 17:31 schrieb Ian Campbell:
> > On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
> >> Am 04.11.14 um 16:44 schrieb Ian Campbell:
> >>> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
> >>> Otherwise I think the next step would be to downgrade to 4.3.1 and see
> >>> if the problem persists, in order to rule out changes elsewhere in the
> >>> system. If the problem doesn't happen with a 4.3.1 rebuilt on your
> >>> current system then the next thing would probably be to bisect the
> >>> issue. There are only 31 toolstack changes in that range, so it ought to
> >>> only take 5-6 iterations.
> >> Unfortunately 4.3.1 is no longer available as an ebuild as 4.3.3 seemed
> >> to fix security issues and therefore 4.3.1 has been deleted from the
> >> repos. So it's not straightforward and I need to figure out how to get
> >> the old version back. But I am sure there's a way.
> >
> > I don't know anything about ebuilds, but if you end up needing to bisect
> > then building from xen.git might be useful anyway (unless you can get an
> > ebuild to trivially build some other version).
> Before I go down that route would I also need to re-compile xen (i.e. 
> the hypervisor at /boot/xen-4.3.3.gz that's being booted from grub) or 
> only xen-tools? In other words does xen-tools 4.3.1 work with the 
> hypervisor version 4.3.3 under /boot?

I think in principal within a stable branch (i.e. 4.3.x) it ought to
work, but I wouldn't swear to it. I think you can probably risk it --
the failure mode in case of a bad mismatch will be very different (liek
a permissions failure early in building a domU), so if you see anything
newly odd you could rebuild Xen.

> I wouldn't want to end up with an unbootable system.

A tools/hv mismatch won't ever stop dom0 booting, it would just stop you
starting a guest. You can always boot the kernel natively in any case.

> In terms of ebuilds: Adding patches to a version is pretty easy as 
> gentoo works from source code. So if 4.3.3 is just different by a number 
> of well defined patches from 4.3.1 then that should be straightforward 
> as applying patches is really trivial.

The git history from 4.3.1 to 4.3.3 is (as it happens) completely
linear, so something like git format patch should trivially produce a
list of patches to apply (or perhaps unapply if it is easier to work
backwards from 4.3.3). I don't know what local patches the ebuild
includes or how much conflict there will be 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 Nov 05 09:42:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09: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 1Xlx6g-0007PW-Hc; Wed, 05 Nov 2014 09:42:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6f-0007PG-EU
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:25 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	19/BE-26652-001F9545; Wed, 05 Nov 2014 09:42:24 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415180539!8419169!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14113 invoked from network); 5 Nov 2014 09:42:23 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:23 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBW70485; Wed, 05 Nov 2014 17:42:16 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:08 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:09 +0000
Message-ID: <1415180475-8339-3-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 2/8] xen/arm: Implement hip04-d01 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

Add this new platform to Xen.
This platform requires specific code to initialize CPUs.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/hip04.c  | 300 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 301 insertions(+)
 create mode 100644 xen/arch/arm/platforms/hip04.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8f47c16..d0b2d99 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_64) += seattle.o
+obj-$(CONFIG_ARM_32) += hip04.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
new file mode 100644
index 0000000..f25282c
--- /dev/null
+++ b/xen/arch/arm/platforms/hip04.c
@@ -0,0 +1,300 @@
+/*
+ * xen/arch/arm/platforms/hip04.c
+ *
+ * HiSilicon HIP-04 D01 board
+ *
+ * Copyright (c) 2012-2013 Hisilicon Ltd.
+ * Copyright (c) 2012-2013 Linaro Ltd.
+ * Copyright (c) 2014 Huawei Tech. Co., Ltd.
+ *
+ * Author: Frediano Ziglio <frediano.ziglio@huawei.com>
+ *
+ * Original code from Linux kernel arch/arm/mach-hisi/hisilicon.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/platform.h>
+#include <xen/mm.h>
+#include <xen/vmap.h>
+#include <asm/io.h>
+#include <asm/gic.h>
+#include <xen/delay.h>
+
+#define CORE_RESET_BIT(x)            (1 << x)
+#define NEON_RESET_BIT(x)            (1 << (x + 4))
+#define CORE_DEBUG_RESET_BIT(x)      (1 << (x + 9))
+#define CLUSTER_L2_RESET_BIT         (1 << 8)
+#define CLUSTER_DEBUG_RESET_BIT      (1 << 13)
+
+#define CLUSTER_L2_RESET_STATUS      (1 << 8)
+#define CLUSTER_DEBUG_RESET_STATUS   (1 << 13)
+
+#define SC_CPU_RESET_DREQ(x)         (0x524 + (x << 3))    /* unreset */
+#define SC_CPU_RESET_STATUS(x)       (0x1520 + (x << 3))
+
+#define FAB_SF_MODE                  0x0c
+
+#define HIP04_MAX_CLUSTERS           4
+#define HIP04_MAX_CPUS_PER_CLUSTER   4
+
+struct hip04_secondary_cpu_data
+{
+    u32 bootwrapper_phys;
+    u32 bootwrapper_size;
+    u32 bootwrapper_magic;
+    u32 relocation_entry;
+    u32 relocation_size;
+};
+
+static void __iomem *relocation, *sysctrl, *fabric, *gb2;
+static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
+static struct hip04_secondary_cpu_data hip04_boot;
+
+static void hip04_reset(void)
+{
+    unsigned long data;
+
+    data = readl_relaxed(gb2);
+    writel_relaxed(data & ~0x4000000u, gb2);
+
+    mdelay(10);
+}
+
+static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
+{
+    unsigned long data;
+
+    data = readl_relaxed(fabric + FAB_SF_MODE);
+    if ( on )
+        data |= 1 << cluster;
+    else
+        data &= ~(1 << cluster);
+    writel_relaxed(data, fabric + FAB_SF_MODE);
+    while ( 1 )
+    {
+        if ( data == readl_relaxed(fabric + FAB_SF_MODE) )
+            break;
+    }
+}
+
+static bool __init hip04_cpu_table_init(void)
+{
+    unsigned int mpidr, cpu, cluster;
+
+    mpidr = cpu_logical_map(smp_processor_id());
+    cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+    cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+    if ( cluster >= HIP04_MAX_CLUSTERS ||
+        cpu >= HIP04_MAX_CPUS_PER_CLUSTER )
+    {
+        printk(XENLOG_ERR "%s: boot CPU is out of bound!\n", __func__);
+        return false;
+    }
+
+    hip04_set_snoop_filter(cluster, 1);
+    hip04_cpu_table[cluster][cpu] = 1;
+    return true;
+}
+
+static bool hip04_cluster_down(unsigned int cluster)
+{
+    int i;
+
+    for ( i = 0; i < HIP04_MAX_CPUS_PER_CLUSTER; i++ )
+        if ( hip04_cpu_table[cluster][i] )
+            return false;
+    return true;
+}
+
+static void hip04_cluster_up(unsigned int cluster)
+{
+    unsigned long data, mask;
+
+    if ( !hip04_cluster_down(cluster) )
+        return;
+
+    data = CLUSTER_L2_RESET_BIT | CLUSTER_DEBUG_RESET_BIT;
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+    do {
+        mask = CLUSTER_L2_RESET_STATUS | \
+               CLUSTER_DEBUG_RESET_STATUS;
+        data = readl_relaxed(sysctrl + \
+                     SC_CPU_RESET_STATUS(cluster));
+    } while ( data & mask );
+    hip04_set_snoop_filter(cluster, 1);
+}
+
+static void __init hip04_iounmap(void __iomem **p)
+{
+    iounmap(*p);
+    *p = NULL;
+}
+
+static int __init hip04_smp_init(void)
+{
+    const struct dt_device_node *np, *np_fab, *bw;
+    const char *msg;
+    u64 addr, size;
+
+    np = dt_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
+    msg = "hisilicon,sysctrl missing in DT\n";
+    if ( !np )
+        goto err;
+
+    np_fab = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-fabric");
+    msg = "hisilicon,hip04-fabric missing in DT\n";
+    if ( !np_fab )
+        goto err;
+
+    if ( !dt_property_read_u32(np, "bootwrapper-phys",
+                               &hip04_boot.bootwrapper_phys) ) {
+        u32 boot_method[4];
+        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-bootwrapper");
+        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
+        if ( !bw )
+            goto err;
+
+        msg = "failed to get boot-method\n";
+        if ( !dt_property_read_u32_array(bw, "boot-method", boot_method, 4) )
+            goto err;
+        hip04_boot.bootwrapper_phys = boot_method[0];
+        hip04_boot.bootwrapper_size = boot_method[1];
+        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
+        hip04_boot.relocation_entry = boot_method[2];
+        hip04_boot.relocation_size = boot_method[3];
+    }
+    else
+    {
+        msg = "failed to get bootwrapper-size\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-size",
+                                   &hip04_boot.bootwrapper_size) )
+            goto err;
+
+        msg = "failed to get bootwrapper-magic\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-magic",
+                                   &hip04_boot.bootwrapper_magic) )
+            goto err;
+
+        msg = "failed to get relocation-entry\n";
+        if ( !dt_property_read_u32(np, "relocation-entry",
+                                   &hip04_boot.relocation_entry) )
+            goto err;
+
+        msg = "failed to get relocation-size\n";
+        if ( !dt_property_read_u32(np, "relocation-size",
+                                   &hip04_boot.relocation_size) )
+            goto err;
+    }
+
+    relocation = ioremap_nocache(hip04_boot.relocation_entry,
+                                 hip04_boot.relocation_size);
+    msg = "failed to map relocation space\n";
+    if ( !relocation )
+        goto err;
+
+    msg = "Error in \"hisilicon,sysctrl\"\n";
+    if ( dt_device_get_address(np, 0, &addr, &size) )
+        goto err;
+    sysctrl = ioremap_nocache(addr, size);
+    if ( !sysctrl )
+        goto err;
+
+    msg = "Error in \"hisilicon,hip04-fabric\"\n";
+    if ( dt_device_get_address(np_fab, 0, &addr, &size) )
+        goto err;
+    fabric = ioremap_nocache(addr, size);
+    if ( !fabric )
+        goto err;
+
+    msg = "Error mapping GB2\n";
+    gb2 = ioremap_nocache(0xe4002000, 0x1000);
+    if ( !gb2 )
+        goto err;
+
+    msg = "Error initializing SMP table\n";
+    if ( !hip04_cpu_table_init() )
+        goto err;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    return 0;
+
+err:
+    hip04_iounmap(&relocation);
+    hip04_iounmap(&sysctrl);
+    hip04_iounmap(&fabric);
+    hip04_iounmap(&gb2);
+
+    printk("%s", msg);
+    return -ENXIO;
+}
+
+static int hip04_cpu_up(int cpu)
+{
+    unsigned int cluster;
+    unsigned long data;
+
+    cluster = cpu / HIP04_MAX_CPUS_PER_CLUSTER;
+    cpu %= HIP04_MAX_CPUS_PER_CLUSTER;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    hip04_cluster_up(cluster);
+
+    hip04_cpu_table[cluster][cpu]++;
+
+    data = CORE_RESET_BIT(cpu) | NEON_RESET_BIT(cpu) | \
+           CORE_DEBUG_RESET_BIT(cpu);
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+
+    return cpu_up_send_sgi(cpu);
+}
+
+
+static const char * const hip04_dt_compat[] __initconst =
+{
+    "hisilicon,hip04-d01",
+    NULL
+};
+
+static const struct dt_device_match hip04_blacklist_dev[] __initconst =
+{
+    /* Hardware power management */
+    DT_MATCH_COMPATIBLE("hisilicon,sysctrl"),
+    DT_MATCH_COMPATIBLE("hisilicon,hip04-fabric"),
+    { /* sentinel */ },
+};
+
+
+PLATFORM_START(hip04, "HISILICON HIP04")
+    .compatible = hip04_dt_compat,
+    .smp_init = hip04_smp_init,
+    .cpu_up = hip04_cpu_up,
+    .reset = hip04_reset,
+    .blacklist_dev = hip04_blacklist_dev,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09: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 1Xlx6b-0007Ox-5Y; Wed, 05 Nov 2014 09:42:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6Z-0007Os-MN
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:19 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	E0/08-14727-AF0F9545; Wed, 05 Nov 2014 09:42:18 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415180534!7172171!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21886 invoked from network); 5 Nov 2014 09:42:18 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:18 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWQ73666; Wed, 05 Nov 2014 17:42:12 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:00 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:07 +0000
Message-ID: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020203.5459F0F5.00A7, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 42f0d14420d8e81beb96f740bae5ab0a
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] xen/arm: Add support for Huawei hip04-d01
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details).

Changes from v2:
- rewrote DTS fix patch (Ian Campbell);
- use is_hip04 macro instead of doing explicit test (Julien Grall);
- do not use quirks to distinguish this platform (Ian Cambell);
- move some GIC constants to C files instead of header (Julien Grall);
- minor changes (Julien Grall).

Changes from v1:
- style (Julien Grall);
- make gicv2_send_SGI faster (Julien Grall);
- cleanup correctly if hip04_smp_init fails (Julien Grall);
- remove quirks using compatibility (Ian Campbell);
- other minor suggestions by Julien Grall.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09: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 1Xlx6g-0007PW-Hc; Wed, 05 Nov 2014 09:42:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6f-0007PG-EU
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:25 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	19/BE-26652-001F9545; Wed, 05 Nov 2014 09:42:24 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415180539!8419169!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14113 invoked from network); 5 Nov 2014 09:42:23 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:23 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBW70485; Wed, 05 Nov 2014 17:42:16 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:08 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:09 +0000
Message-ID: <1415180475-8339-3-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 2/8] xen/arm: Implement hip04-d01 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

Add this new platform to Xen.
This platform requires specific code to initialize CPUs.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/hip04.c  | 300 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 301 insertions(+)
 create mode 100644 xen/arch/arm/platforms/hip04.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8f47c16..d0b2d99 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_64) += seattle.o
+obj-$(CONFIG_ARM_32) += hip04.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
new file mode 100644
index 0000000..f25282c
--- /dev/null
+++ b/xen/arch/arm/platforms/hip04.c
@@ -0,0 +1,300 @@
+/*
+ * xen/arch/arm/platforms/hip04.c
+ *
+ * HiSilicon HIP-04 D01 board
+ *
+ * Copyright (c) 2012-2013 Hisilicon Ltd.
+ * Copyright (c) 2012-2013 Linaro Ltd.
+ * Copyright (c) 2014 Huawei Tech. Co., Ltd.
+ *
+ * Author: Frediano Ziglio <frediano.ziglio@huawei.com>
+ *
+ * Original code from Linux kernel arch/arm/mach-hisi/hisilicon.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/platform.h>
+#include <xen/mm.h>
+#include <xen/vmap.h>
+#include <asm/io.h>
+#include <asm/gic.h>
+#include <xen/delay.h>
+
+#define CORE_RESET_BIT(x)            (1 << x)
+#define NEON_RESET_BIT(x)            (1 << (x + 4))
+#define CORE_DEBUG_RESET_BIT(x)      (1 << (x + 9))
+#define CLUSTER_L2_RESET_BIT         (1 << 8)
+#define CLUSTER_DEBUG_RESET_BIT      (1 << 13)
+
+#define CLUSTER_L2_RESET_STATUS      (1 << 8)
+#define CLUSTER_DEBUG_RESET_STATUS   (1 << 13)
+
+#define SC_CPU_RESET_DREQ(x)         (0x524 + (x << 3))    /* unreset */
+#define SC_CPU_RESET_STATUS(x)       (0x1520 + (x << 3))
+
+#define FAB_SF_MODE                  0x0c
+
+#define HIP04_MAX_CLUSTERS           4
+#define HIP04_MAX_CPUS_PER_CLUSTER   4
+
+struct hip04_secondary_cpu_data
+{
+    u32 bootwrapper_phys;
+    u32 bootwrapper_size;
+    u32 bootwrapper_magic;
+    u32 relocation_entry;
+    u32 relocation_size;
+};
+
+static void __iomem *relocation, *sysctrl, *fabric, *gb2;
+static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
+static struct hip04_secondary_cpu_data hip04_boot;
+
+static void hip04_reset(void)
+{
+    unsigned long data;
+
+    data = readl_relaxed(gb2);
+    writel_relaxed(data & ~0x4000000u, gb2);
+
+    mdelay(10);
+}
+
+static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
+{
+    unsigned long data;
+
+    data = readl_relaxed(fabric + FAB_SF_MODE);
+    if ( on )
+        data |= 1 << cluster;
+    else
+        data &= ~(1 << cluster);
+    writel_relaxed(data, fabric + FAB_SF_MODE);
+    while ( 1 )
+    {
+        if ( data == readl_relaxed(fabric + FAB_SF_MODE) )
+            break;
+    }
+}
+
+static bool __init hip04_cpu_table_init(void)
+{
+    unsigned int mpidr, cpu, cluster;
+
+    mpidr = cpu_logical_map(smp_processor_id());
+    cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+    cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+    if ( cluster >= HIP04_MAX_CLUSTERS ||
+        cpu >= HIP04_MAX_CPUS_PER_CLUSTER )
+    {
+        printk(XENLOG_ERR "%s: boot CPU is out of bound!\n", __func__);
+        return false;
+    }
+
+    hip04_set_snoop_filter(cluster, 1);
+    hip04_cpu_table[cluster][cpu] = 1;
+    return true;
+}
+
+static bool hip04_cluster_down(unsigned int cluster)
+{
+    int i;
+
+    for ( i = 0; i < HIP04_MAX_CPUS_PER_CLUSTER; i++ )
+        if ( hip04_cpu_table[cluster][i] )
+            return false;
+    return true;
+}
+
+static void hip04_cluster_up(unsigned int cluster)
+{
+    unsigned long data, mask;
+
+    if ( !hip04_cluster_down(cluster) )
+        return;
+
+    data = CLUSTER_L2_RESET_BIT | CLUSTER_DEBUG_RESET_BIT;
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+    do {
+        mask = CLUSTER_L2_RESET_STATUS | \
+               CLUSTER_DEBUG_RESET_STATUS;
+        data = readl_relaxed(sysctrl + \
+                     SC_CPU_RESET_STATUS(cluster));
+    } while ( data & mask );
+    hip04_set_snoop_filter(cluster, 1);
+}
+
+static void __init hip04_iounmap(void __iomem **p)
+{
+    iounmap(*p);
+    *p = NULL;
+}
+
+static int __init hip04_smp_init(void)
+{
+    const struct dt_device_node *np, *np_fab, *bw;
+    const char *msg;
+    u64 addr, size;
+
+    np = dt_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
+    msg = "hisilicon,sysctrl missing in DT\n";
+    if ( !np )
+        goto err;
+
+    np_fab = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-fabric");
+    msg = "hisilicon,hip04-fabric missing in DT\n";
+    if ( !np_fab )
+        goto err;
+
+    if ( !dt_property_read_u32(np, "bootwrapper-phys",
+                               &hip04_boot.bootwrapper_phys) ) {
+        u32 boot_method[4];
+        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-bootwrapper");
+        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
+        if ( !bw )
+            goto err;
+
+        msg = "failed to get boot-method\n";
+        if ( !dt_property_read_u32_array(bw, "boot-method", boot_method, 4) )
+            goto err;
+        hip04_boot.bootwrapper_phys = boot_method[0];
+        hip04_boot.bootwrapper_size = boot_method[1];
+        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
+        hip04_boot.relocation_entry = boot_method[2];
+        hip04_boot.relocation_size = boot_method[3];
+    }
+    else
+    {
+        msg = "failed to get bootwrapper-size\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-size",
+                                   &hip04_boot.bootwrapper_size) )
+            goto err;
+
+        msg = "failed to get bootwrapper-magic\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-magic",
+                                   &hip04_boot.bootwrapper_magic) )
+            goto err;
+
+        msg = "failed to get relocation-entry\n";
+        if ( !dt_property_read_u32(np, "relocation-entry",
+                                   &hip04_boot.relocation_entry) )
+            goto err;
+
+        msg = "failed to get relocation-size\n";
+        if ( !dt_property_read_u32(np, "relocation-size",
+                                   &hip04_boot.relocation_size) )
+            goto err;
+    }
+
+    relocation = ioremap_nocache(hip04_boot.relocation_entry,
+                                 hip04_boot.relocation_size);
+    msg = "failed to map relocation space\n";
+    if ( !relocation )
+        goto err;
+
+    msg = "Error in \"hisilicon,sysctrl\"\n";
+    if ( dt_device_get_address(np, 0, &addr, &size) )
+        goto err;
+    sysctrl = ioremap_nocache(addr, size);
+    if ( !sysctrl )
+        goto err;
+
+    msg = "Error in \"hisilicon,hip04-fabric\"\n";
+    if ( dt_device_get_address(np_fab, 0, &addr, &size) )
+        goto err;
+    fabric = ioremap_nocache(addr, size);
+    if ( !fabric )
+        goto err;
+
+    msg = "Error mapping GB2\n";
+    gb2 = ioremap_nocache(0xe4002000, 0x1000);
+    if ( !gb2 )
+        goto err;
+
+    msg = "Error initializing SMP table\n";
+    if ( !hip04_cpu_table_init() )
+        goto err;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    return 0;
+
+err:
+    hip04_iounmap(&relocation);
+    hip04_iounmap(&sysctrl);
+    hip04_iounmap(&fabric);
+    hip04_iounmap(&gb2);
+
+    printk("%s", msg);
+    return -ENXIO;
+}
+
+static int hip04_cpu_up(int cpu)
+{
+    unsigned int cluster;
+    unsigned long data;
+
+    cluster = cpu / HIP04_MAX_CPUS_PER_CLUSTER;
+    cpu %= HIP04_MAX_CPUS_PER_CLUSTER;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    hip04_cluster_up(cluster);
+
+    hip04_cpu_table[cluster][cpu]++;
+
+    data = CORE_RESET_BIT(cpu) | NEON_RESET_BIT(cpu) | \
+           CORE_DEBUG_RESET_BIT(cpu);
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+
+    return cpu_up_send_sgi(cpu);
+}
+
+
+static const char * const hip04_dt_compat[] __initconst =
+{
+    "hisilicon,hip04-d01",
+    NULL
+};
+
+static const struct dt_device_match hip04_blacklist_dev[] __initconst =
+{
+    /* Hardware power management */
+    DT_MATCH_COMPATIBLE("hisilicon,sysctrl"),
+    DT_MATCH_COMPATIBLE("hisilicon,hip04-fabric"),
+    { /* sentinel */ },
+};
+
+
+PLATFORM_START(hip04, "HISILICON HIP04")
+    .compatible = hip04_dt_compat,
+    .smp_init = hip04_smp_init,
+    .cpu_up = hip04_cpu_up,
+    .reset = hip04_reset,
+    .blacklist_dev = hip04_blacklist_dev,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09: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 1Xlx6b-0007Ox-5Y; Wed, 05 Nov 2014 09:42:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6Z-0007Os-MN
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:19 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	E0/08-14727-AF0F9545; Wed, 05 Nov 2014 09:42:18 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415180534!7172171!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21886 invoked from network); 5 Nov 2014 09:42:18 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:18 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWQ73666; Wed, 05 Nov 2014 17:42:12 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:00 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:07 +0000
Message-ID: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020203.5459F0F5.00A7, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 42f0d14420d8e81beb96f740bae5ab0a
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] xen/arm: Add support for Huawei hip04-d01
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details).

Changes from v2:
- rewrote DTS fix patch (Ian Campbell);
- use is_hip04 macro instead of doing explicit test (Julien Grall);
- do not use quirks to distinguish this platform (Ian Cambell);
- move some GIC constants to C files instead of header (Julien Grall);
- minor changes (Julien Grall).

Changes from v1:
- style (Julien Grall);
- make gicv2_send_SGI faster (Julien Grall);
- cleanup correctly if hip04_smp_init fails (Julien Grall);
- remove quirks using compatibility (Ian Campbell);
- other minor suggestions by Julien Grall.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx6j-0007RP-V5; Wed, 05 Nov 2014 09:42:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6i-0007Q0-2f
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:28 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	5F/DD-22777-301F9545; Wed, 05 Nov 2014 09:42:27 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415180541!11279254!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4990 invoked from network); 5 Nov 2014 09:42:25 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:25 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBW70498; Wed, 05 Nov 2014 17:42:21 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:13 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:10 +0000
Message-ID: <1415180475-8339-4-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 3/8] xen/arm: Make gic-v2 code handle
	hip04-d01 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

The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.

Use nr_lines to check for maximum irq supported. hip04-d01 support less
interrupts due to some field restriction. Any value above this is already
an error.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 85 ++++++++++++++++++++++++++++++++++++++---------
 xen/arch/arm/gic.c        |  3 +-
 xen/include/asm-arm/gic.h |  4 ++-
 3 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..3cb59dd 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -79,16 +79,25 @@ static struct gic_info gicv2_info;
  * logical CPU numbering. Let's use mapping as returned by the GIC
  * itself
  */
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
 
 /* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+static unsigned int nr_gic_cpu_if = 8;
+static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
+static unsigned int gic_cpu_mask = 0xff;
+
+#define is_hip04() (nr_gic_cpu_if == 16)
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
     writeb_relaxed(val, gicv2.map_dbase + offset);
 }
 
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+    writew_relaxed(val, gicv2.map_dbase + offset);
+}
+
 static inline void writel_gicd(uint32_t val, unsigned int offset)
 {
     writel_relaxed(val, gicv2.map_dbase + offset);
@@ -132,7 +141,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
     cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
     for_each_cpu( cpu, &possible_mask )
     {
-        ASSERT(cpu < NR_GIC_CPU_IF);
+        ASSERT(cpu < nr_gic_cpu_if);
         mask |= per_cpu(gic_cpu_id, cpu);
     }
 
@@ -203,6 +212,15 @@ static unsigned int gicv2_read_irq(void)
     return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
+/* Set target CPU mask (RAZ/WI on uniprocessor) */
+static void gicv2_set_irq_mask(int irq, unsigned int mask)
+{
+    if ( is_hip04() )
+        writew_gicd(mask, GICD_ITARGETSR + irq * 2);
+    else
+        writeb_gicd(mask, GICD_ITARGETSR + irq);
+}
+
 /*
  * needs to be called with a valid cpu_mask, ie each cpu in the mask has
  * already called gic_cpu_init
@@ -230,7 +248,7 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
     writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + irq);
+    gicv2_set_irq_mask(irq, mask);
     /* Set priority */
     writeb_gicd(priority, GICD_IPRIORITYR + irq);
 
@@ -244,16 +262,21 @@ static void __init gicv2_dist_init(void)
     uint32_t gic_cpus;
     int i;
 
-    cpumask = readl_gicd(GICD_ITARGETSR) & 0xff;
-    cpumask |= cpumask << 8;
-    cpumask |= cpumask << 16;
+    cpumask = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* Disable the distributor */
     writel_gicd(0, GICD_CTLR);
 
     type = readl_gicd(GICD_TYPER);
     gicv2_info.nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
-    gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    if ( is_hip04() )
+    {
+        gic_cpus = 16;
+    }
+    else
+    {
+        gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    }
     printk("GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n",
            gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
            (type & GICD_TYPE_SEC) ? ", secure" : "",
@@ -264,8 +287,19 @@ static void __init gicv2_dist_init(void)
         writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
 
     /* Route all global IRQs to this CPU */
-    for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
-        writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    if ( is_hip04() )
+    {
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 2 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 2) * 4);
+    }
+    else
+    {
+        cpumask |= cpumask << 8;
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    }
 
     /* Default priority for global interrupts */
     for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
@@ -285,7 +319,7 @@ static void __cpuinit gicv2_cpu_init(void)
 {
     int i;
 
-    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & 0xff;
+    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
      * even though they are controlled with GICD registers, they must
@@ -366,7 +400,7 @@ static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
         cpumask_and(&online_mask, cpu_mask, &cpu_online_map);
         mask = gicv2_cpu_mask(&online_mask);
         writel_gicd(GICD_SGI_TARGET_LIST |
-                    (mask << GICD_SGI_TARGET_SHIFT) | sgi,
+                    (mask << gicd_sgi_target_shift) | sgi,
                     GICD_SGIR);
         break;
     default:
@@ -581,7 +615,7 @@ static void gicv2_irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_m
     mask = gicv2_cpu_mask(cpu_mask);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + desc->irq);
+    gicv2_set_irq_mask(desc->irq, mask);
 
     spin_unlock(&gicv2.lock);
 }
@@ -684,7 +718,7 @@ const static struct gic_hw_operations gicv2_ops = {
 };
 
 /* Set up the GIC */
-static int __init gicv2_init(struct dt_device_node *node, const void *data)
+static int __init gicv2_init_default(struct dt_device_node *node, const void *data)
 {
     int res;
 
@@ -764,6 +798,15 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
     return 0;
 }
 
+static int __init hip04_gicv2_init(struct dt_device_node *node, const void *data)
+{
+    nr_gic_cpu_if = 16;
+    gicd_sgi_target_shift = 8;
+    gic_cpu_mask = 0xffff;
+
+    return gicv2_init_default(node, data);
+}
+
 static const char * const gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_CORTEX_A15,
@@ -774,9 +817,21 @@ static const char * const gicv2_dt_compat[] __initconst =
 
 DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
         .compatible = gicv2_dt_compat,
-        .init = gicv2_init,
+        .init = gicv2_init_default,
 DT_DEVICE_END
 
+static const char * const hip04_gicv2_dt_compat[] __initconst =
+{
+    DT_COMPAT_GIC_HIP04,
+    NULL
+};
+
+DT_DEVICE_START(hip04_gicv2, "GICv2:", DEVICE_GIC)
+        .compatible = hip04_gicv2_dt_compat,
+        .init = hip04_gicv2_init,
+DT_DEVICE_END
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..8050a65 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
 void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 {
     unsigned int irq;
+    unsigned int max_irq = gic_hw_ops->info->nr_lines;
 
     do  {
         /* Reading IRQ will ACK it */
         irq = gic_hw_ops->read_irq();
 
-        if ( likely(irq >= 16 && irq < 1021) )
+        if ( likely(irq >= 16 && irq < max_irq) )
         {
             local_irq_enable();
             do_IRQ(regs, irq, is_fiq);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..5adb628 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -155,10 +155,12 @@
 #define DT_COMPAT_GIC_400            "arm,gic-400"
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
+#define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx6j-0007RP-V5; Wed, 05 Nov 2014 09:42:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6i-0007Q0-2f
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:28 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	5F/DD-22777-301F9545; Wed, 05 Nov 2014 09:42:27 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415180541!11279254!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4990 invoked from network); 5 Nov 2014 09:42:25 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:25 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBW70498; Wed, 05 Nov 2014 17:42:21 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:13 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:10 +0000
Message-ID: <1415180475-8339-4-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 3/8] xen/arm: Make gic-v2 code handle
	hip04-d01 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

The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.

Use nr_lines to check for maximum irq supported. hip04-d01 support less
interrupts due to some field restriction. Any value above this is already
an error.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 85 ++++++++++++++++++++++++++++++++++++++---------
 xen/arch/arm/gic.c        |  3 +-
 xen/include/asm-arm/gic.h |  4 ++-
 3 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..3cb59dd 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -79,16 +79,25 @@ static struct gic_info gicv2_info;
  * logical CPU numbering. Let's use mapping as returned by the GIC
  * itself
  */
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
 
 /* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+static unsigned int nr_gic_cpu_if = 8;
+static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
+static unsigned int gic_cpu_mask = 0xff;
+
+#define is_hip04() (nr_gic_cpu_if == 16)
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
     writeb_relaxed(val, gicv2.map_dbase + offset);
 }
 
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+    writew_relaxed(val, gicv2.map_dbase + offset);
+}
+
 static inline void writel_gicd(uint32_t val, unsigned int offset)
 {
     writel_relaxed(val, gicv2.map_dbase + offset);
@@ -132,7 +141,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
     cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
     for_each_cpu( cpu, &possible_mask )
     {
-        ASSERT(cpu < NR_GIC_CPU_IF);
+        ASSERT(cpu < nr_gic_cpu_if);
         mask |= per_cpu(gic_cpu_id, cpu);
     }
 
@@ -203,6 +212,15 @@ static unsigned int gicv2_read_irq(void)
     return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
+/* Set target CPU mask (RAZ/WI on uniprocessor) */
+static void gicv2_set_irq_mask(int irq, unsigned int mask)
+{
+    if ( is_hip04() )
+        writew_gicd(mask, GICD_ITARGETSR + irq * 2);
+    else
+        writeb_gicd(mask, GICD_ITARGETSR + irq);
+}
+
 /*
  * needs to be called with a valid cpu_mask, ie each cpu in the mask has
  * already called gic_cpu_init
@@ -230,7 +248,7 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
     writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + irq);
+    gicv2_set_irq_mask(irq, mask);
     /* Set priority */
     writeb_gicd(priority, GICD_IPRIORITYR + irq);
 
@@ -244,16 +262,21 @@ static void __init gicv2_dist_init(void)
     uint32_t gic_cpus;
     int i;
 
-    cpumask = readl_gicd(GICD_ITARGETSR) & 0xff;
-    cpumask |= cpumask << 8;
-    cpumask |= cpumask << 16;
+    cpumask = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* Disable the distributor */
     writel_gicd(0, GICD_CTLR);
 
     type = readl_gicd(GICD_TYPER);
     gicv2_info.nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
-    gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    if ( is_hip04() )
+    {
+        gic_cpus = 16;
+    }
+    else
+    {
+        gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    }
     printk("GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n",
            gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
            (type & GICD_TYPE_SEC) ? ", secure" : "",
@@ -264,8 +287,19 @@ static void __init gicv2_dist_init(void)
         writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
 
     /* Route all global IRQs to this CPU */
-    for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
-        writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    if ( is_hip04() )
+    {
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 2 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 2) * 4);
+    }
+    else
+    {
+        cpumask |= cpumask << 8;
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    }
 
     /* Default priority for global interrupts */
     for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
@@ -285,7 +319,7 @@ static void __cpuinit gicv2_cpu_init(void)
 {
     int i;
 
-    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & 0xff;
+    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
      * even though they are controlled with GICD registers, they must
@@ -366,7 +400,7 @@ static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
         cpumask_and(&online_mask, cpu_mask, &cpu_online_map);
         mask = gicv2_cpu_mask(&online_mask);
         writel_gicd(GICD_SGI_TARGET_LIST |
-                    (mask << GICD_SGI_TARGET_SHIFT) | sgi,
+                    (mask << gicd_sgi_target_shift) | sgi,
                     GICD_SGIR);
         break;
     default:
@@ -581,7 +615,7 @@ static void gicv2_irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_m
     mask = gicv2_cpu_mask(cpu_mask);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + desc->irq);
+    gicv2_set_irq_mask(desc->irq, mask);
 
     spin_unlock(&gicv2.lock);
 }
@@ -684,7 +718,7 @@ const static struct gic_hw_operations gicv2_ops = {
 };
 
 /* Set up the GIC */
-static int __init gicv2_init(struct dt_device_node *node, const void *data)
+static int __init gicv2_init_default(struct dt_device_node *node, const void *data)
 {
     int res;
 
@@ -764,6 +798,15 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
     return 0;
 }
 
+static int __init hip04_gicv2_init(struct dt_device_node *node, const void *data)
+{
+    nr_gic_cpu_if = 16;
+    gicd_sgi_target_shift = 8;
+    gic_cpu_mask = 0xffff;
+
+    return gicv2_init_default(node, data);
+}
+
 static const char * const gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_CORTEX_A15,
@@ -774,9 +817,21 @@ static const char * const gicv2_dt_compat[] __initconst =
 
 DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
         .compatible = gicv2_dt_compat,
-        .init = gicv2_init,
+        .init = gicv2_init_default,
 DT_DEVICE_END
 
+static const char * const hip04_gicv2_dt_compat[] __initconst =
+{
+    DT_COMPAT_GIC_HIP04,
+    NULL
+};
+
+DT_DEVICE_START(hip04_gicv2, "GICv2:", DEVICE_GIC)
+        .compatible = hip04_gicv2_dt_compat,
+        .init = hip04_gicv2_init,
+DT_DEVICE_END
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..8050a65 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
 void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 {
     unsigned int irq;
+    unsigned int max_irq = gic_hw_ops->info->nr_lines;
 
     do  {
         /* Reading IRQ will ACK it */
         irq = gic_hw_ops->read_irq();
 
-        if ( likely(irq >= 16 && irq < 1021) )
+        if ( likely(irq >= 16 && irq < max_irq) )
         {
             local_irq_enable();
             do_IRQ(regs, irq, is_fiq);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..5adb628 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -155,10 +155,12 @@
 #define DT_COMPAT_GIC_400            "arm,gic-400"
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
+#define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx6n-0007TB-D5; Wed, 05 Nov 2014 09:42:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6m-0007SX-At
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	75/E3-09842-701F9545; Wed, 05 Nov 2014 09:42:31 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415180547!12323028!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17706 invoked from network); 5 Nov 2014 09:42:30 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:30 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBW70510; Wed, 05 Nov 2014 17:42:26 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:18 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:11 +0000
Message-ID: <1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This name can appear in some Linux kernel repos. Not very fortunate,
but to avoid others spending an hour to spot that few characters
difference it worth to work around it.

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 1 +
 xen/include/asm-arm/gic.h | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 3cb59dd..9ab30ce 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -823,6 +823,7 @@ DT_DEVICE_END
 static const char * const hip04_gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_HIP04,
+    DT_COMPAT_GIC_HIP04_2,
     NULL
 };
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 5adb628..3d2b3db 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -156,11 +156,13 @@
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
 #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
+#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx6n-0007TB-D5; Wed, 05 Nov 2014 09:42:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6m-0007SX-At
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	75/E3-09842-701F9545; Wed, 05 Nov 2014 09:42:31 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415180547!12323028!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17706 invoked from network); 5 Nov 2014 09:42:30 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:30 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBW70510; Wed, 05 Nov 2014 17:42:26 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:18 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:11 +0000
Message-ID: <1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This name can appear in some Linux kernel repos. Not very fortunate,
but to avoid others spending an hour to spot that few characters
difference it worth to work around it.

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 1 +
 xen/include/asm-arm/gic.h | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 3cb59dd..9ab30ce 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -823,6 +823,7 @@ DT_DEVICE_END
 static const char * const hip04_gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_HIP04,
+    DT_COMPAT_GIC_HIP04_2,
     NULL
 };
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 5adb628..3d2b3db 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -156,11 +156,13 @@
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
 #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
+#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx6u-0007Wg-1C; Wed, 05 Nov 2014 09:42:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6r-0007Ve-TC
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:38 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	6F/91-02953-D01F9545; Wed, 05 Nov 2014 09:42:37 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415180552!12639941!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28857 invoked from network); 5 Nov 2014 09:42:36 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:36 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDY97049; Wed, 05 Nov 2014 17:42:31 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:22 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:12 +0000
Message-ID: <1415180475-8339-6-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 5/8] xen/arm: handle GICH register changes
	for hip04-d01 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

The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 9ab30ce..d766438 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -61,6 +61,9 @@
 #define GICH_V2_VMCR_PRIORITY_MASK   0x1f
 #define GICH_V2_VMCR_PRIORITY_SHIFT  27
 
+#define HIP04_GICH_APR  0x70
+#define HIP04_GICH_LR   0x80
+
 /* Global state */
 static struct {
     paddr_t dbase;            /* Address of distributor registers */
@@ -85,6 +88,8 @@ static DEFINE_PER_CPU(u16, gic_cpu_id);
 static unsigned int nr_gic_cpu_if = 8;
 static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
 static unsigned int gic_cpu_mask = 0xff;
+static unsigned int gich_apr = GICH_APR;
+static unsigned int gich_lr = GICH_LR;
 
 #define is_hip04() (nr_gic_cpu_if == 16)
 
@@ -157,9 +162,9 @@ static void gicv2_save_state(struct vcpu *v)
      * accessed simultaneously by another pCPU.
      */
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        v->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+        v->arch.gic.v2.lr[i] = readl_gich(gich_lr + i * 4);
 
-    v->arch.gic.v2.apr = readl_gich(GICH_APR);
+    v->arch.gic.v2.apr = readl_gich(gich_apr);
     v->arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
     /* Disable until next VCPU scheduled */
     writel_gich(0, GICH_HCR);
@@ -170,9 +175,9 @@ static void gicv2_restore_state(const struct vcpu *v)
     int i;
 
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        writel_gich(v->arch.gic.v2.lr[i], GICH_LR + i * 4);
+        writel_gich(v->arch.gic.v2.lr[i], gich_lr + i * 4);
 
-    writel_gich(v->arch.gic.v2.apr, GICH_APR);
+    writel_gich(v->arch.gic.v2.apr, gich_apr);
     writel_gich(v->arch.gic.v2.vmcr, GICH_VMCR);
     writel_gich(GICH_HCR_EN, GICH_HCR);
 }
@@ -185,7 +190,7 @@ static void gicv2_dump_state(const struct vcpu *v)
     {
         for ( i = 0; i < gicv2_info.nr_lrs; i++ )
             printk("   HW_LR[%d]=%x\n", i,
-                   readl_gich(GICH_LR + i * 4));
+                   readl_gich(gich_lr + i * 4));
     }
     else
     {
@@ -439,12 +444,12 @@ static void gicv2_update_lr(int lr, const struct pending_irq *p,
                             << GICH_V2_LR_PHYSICAL_SHIFT);
     }
 
-    writel_gich(lr_reg, GICH_LR + lr * 4);
+    writel_gich(lr_reg, gich_lr + lr * 4);
 }
 
 static void gicv2_clear_lr(int lr)
 {
-    writel_gich(0, GICH_LR + lr * 4);
+    writel_gich(0, gich_lr + lr * 4);
 }
 
 static int gicv2v_setup(struct domain *d)
@@ -494,7 +499,7 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 {
     uint32_t lrv;
 
-    lrv          = readl_gich(GICH_LR + lr * 4);
+    lrv          = readl_gich(gich_lr + lr * 4);
     lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) & GICH_V2_LR_PHYSICAL_MASK;
     lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
     lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & GICH_V2_LR_PRIORITY_MASK;
@@ -517,7 +522,7 @@ static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
                                        << GICH_V2_LR_HW_SHIFT)  |
           ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) << GICH_V2_LR_GRP_SHIFT) );
 
-    writel_gich(lrv, GICH_LR + lr * 4);
+    writel_gich(lrv, gich_lr + lr * 4);
 }
 
 static void gicv2_hcr_status(uint32_t flag, bool_t status)
@@ -540,7 +545,7 @@ static unsigned int gicv2_read_vmcr_priority(void)
 
 static unsigned int gicv2_read_apr(int apr_reg)
 {
-   return readl_gich(GICH_APR);
+   return readl_gich(gich_apr);
 }
 
 static void gicv2_irq_enable(struct irq_desc *desc)
@@ -803,6 +808,8 @@ static int __init hip04_gicv2_init(struct dt_device_node *node, const void *data
     nr_gic_cpu_if = 16;
     gicd_sgi_target_shift = 8;
     gic_cpu_mask = 0xffff;
+    gich_apr = HIP04_GICH_APR;
+    gich_lr = HIP04_GICH_LR;
 
     return gicv2_init_default(node, data);
 }
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx6u-0007Wg-1C; Wed, 05 Nov 2014 09:42:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6r-0007Ve-TC
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:38 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	6F/91-02953-D01F9545; Wed, 05 Nov 2014 09:42:37 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415180552!12639941!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28857 invoked from network); 5 Nov 2014 09:42:36 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:36 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDY97049; Wed, 05 Nov 2014 17:42:31 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:22 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:12 +0000
Message-ID: <1415180475-8339-6-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 5/8] xen/arm: handle GICH register changes
	for hip04-d01 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

The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 9ab30ce..d766438 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -61,6 +61,9 @@
 #define GICH_V2_VMCR_PRIORITY_MASK   0x1f
 #define GICH_V2_VMCR_PRIORITY_SHIFT  27
 
+#define HIP04_GICH_APR  0x70
+#define HIP04_GICH_LR   0x80
+
 /* Global state */
 static struct {
     paddr_t dbase;            /* Address of distributor registers */
@@ -85,6 +88,8 @@ static DEFINE_PER_CPU(u16, gic_cpu_id);
 static unsigned int nr_gic_cpu_if = 8;
 static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
 static unsigned int gic_cpu_mask = 0xff;
+static unsigned int gich_apr = GICH_APR;
+static unsigned int gich_lr = GICH_LR;
 
 #define is_hip04() (nr_gic_cpu_if == 16)
 
@@ -157,9 +162,9 @@ static void gicv2_save_state(struct vcpu *v)
      * accessed simultaneously by another pCPU.
      */
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        v->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+        v->arch.gic.v2.lr[i] = readl_gich(gich_lr + i * 4);
 
-    v->arch.gic.v2.apr = readl_gich(GICH_APR);
+    v->arch.gic.v2.apr = readl_gich(gich_apr);
     v->arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
     /* Disable until next VCPU scheduled */
     writel_gich(0, GICH_HCR);
@@ -170,9 +175,9 @@ static void gicv2_restore_state(const struct vcpu *v)
     int i;
 
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        writel_gich(v->arch.gic.v2.lr[i], GICH_LR + i * 4);
+        writel_gich(v->arch.gic.v2.lr[i], gich_lr + i * 4);
 
-    writel_gich(v->arch.gic.v2.apr, GICH_APR);
+    writel_gich(v->arch.gic.v2.apr, gich_apr);
     writel_gich(v->arch.gic.v2.vmcr, GICH_VMCR);
     writel_gich(GICH_HCR_EN, GICH_HCR);
 }
@@ -185,7 +190,7 @@ static void gicv2_dump_state(const struct vcpu *v)
     {
         for ( i = 0; i < gicv2_info.nr_lrs; i++ )
             printk("   HW_LR[%d]=%x\n", i,
-                   readl_gich(GICH_LR + i * 4));
+                   readl_gich(gich_lr + i * 4));
     }
     else
     {
@@ -439,12 +444,12 @@ static void gicv2_update_lr(int lr, const struct pending_irq *p,
                             << GICH_V2_LR_PHYSICAL_SHIFT);
     }
 
-    writel_gich(lr_reg, GICH_LR + lr * 4);
+    writel_gich(lr_reg, gich_lr + lr * 4);
 }
 
 static void gicv2_clear_lr(int lr)
 {
-    writel_gich(0, GICH_LR + lr * 4);
+    writel_gich(0, gich_lr + lr * 4);
 }
 
 static int gicv2v_setup(struct domain *d)
@@ -494,7 +499,7 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 {
     uint32_t lrv;
 
-    lrv          = readl_gich(GICH_LR + lr * 4);
+    lrv          = readl_gich(gich_lr + lr * 4);
     lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) & GICH_V2_LR_PHYSICAL_MASK;
     lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
     lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & GICH_V2_LR_PRIORITY_MASK;
@@ -517,7 +522,7 @@ static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
                                        << GICH_V2_LR_HW_SHIFT)  |
           ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) << GICH_V2_LR_GRP_SHIFT) );
 
-    writel_gich(lrv, GICH_LR + lr * 4);
+    writel_gich(lrv, gich_lr + lr * 4);
 }
 
 static void gicv2_hcr_status(uint32_t flag, bool_t status)
@@ -540,7 +545,7 @@ static unsigned int gicv2_read_vmcr_priority(void)
 
 static unsigned int gicv2_read_apr(int apr_reg)
 {
-   return readl_gich(GICH_APR);
+   return readl_gich(gich_apr);
 }
 
 static void gicv2_irq_enable(struct irq_desc *desc)
@@ -803,6 +808,8 @@ static int __init hip04_gicv2_init(struct dt_device_node *node, const void *data
     nr_gic_cpu_if = 16;
     gicd_sgi_target_shift = 8;
     gic_cpu_mask = 0xffff;
+    gich_apr = HIP04_GICH_APR;
+    gich_lr = HIP04_GICH_LR;
 
     return gicv2_init_default(node, data);
 }
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx6y-0007Z8-Eq; Wed, 05 Nov 2014 09:42:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6x-0007YH-1l
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:43 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	8A/BD-02559-211F9545; Wed, 05 Nov 2014 09:42:42 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415180557!12624480!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27075 invoked from network); 5 Nov 2014 09:42:41 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:41 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBW70534; Wed, 05 Nov 2014 17:42:37 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:25 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:13 +0000
Message-ID: <1415180475-8339-7-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 6/8] xen/arm: Force dom0 to use normal GICv2
	driver on Hip04 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

Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index d766438..2f6bbd5 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -641,6 +641,12 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOENT);
     }
 
+    if ( is_hip04() )
+    {
+        compatible = DT_COMPAT_GIC_CORTEX_A15;
+        len = strlen((char*) compatible) + 1;
+    }
+
     res = fdt_begin_node(fdt, "interrupt-controller");
     if ( res )
         return res;
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx6y-0007Z8-Eq; Wed, 05 Nov 2014 09:42:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6x-0007YH-1l
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:43 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	8A/BD-02559-211F9545; Wed, 05 Nov 2014 09:42:42 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415180557!12624480!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27075 invoked from network); 5 Nov 2014 09:42:41 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:41 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBW70534; Wed, 05 Nov 2014 17:42:37 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:25 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:13 +0000
Message-ID: <1415180475-8339-7-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 6/8] xen/arm: Force dom0 to use normal GICv2
	driver on Hip04 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

Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index d766438..2f6bbd5 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -641,6 +641,12 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOENT);
     }
 
+    if ( is_hip04() )
+    {
+        compatible = DT_COMPAT_GIC_CORTEX_A15;
+        len = strlen((char*) compatible) + 1;
+    }
+
     res = fdt_begin_node(fdt, "interrupt-controller");
     if ( res )
         return res;
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx6y-0007Zh-S8; Wed, 05 Nov 2014 09:42:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6x-0007Yf-OK
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8F/44-09842-311F9545; Wed, 05 Nov 2014 09:42:43 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415180558!9449863!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16690 invoked from network); 5 Nov 2014 09:42:42 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:42 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBW70535; Wed, 05 Nov 2014 17:42:37 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:29 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:14 +0000
Message-ID: <1415180475-8339-8-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 7/8] xen/device_tree: Add
	dt_device_get_address_raw
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow to read untranslated address from device node.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/common/device_tree.c      | 34 ++++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h | 11 +++++++++++
 2 files changed, 45 insertions(+)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 1a886c0..4186a24 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -711,6 +711,40 @@ int dt_device_get_address(const struct dt_device_node *dev, int index,
     return 0;
 }
 
+/* dt_device_get_address_raw - Returns address not translated */
+int dt_device_get_address_raw(const struct dt_device_node *dev, int index,
+                          u64 *addr)
+{
+    const __be32 *addrp;
+    const struct dt_device_node *parent;
+    const struct dt_bus *bus;
+    int na, ns;
+
+    if ( !addr )
+        return -EINVAL;
+
+    addrp = dt_get_address(dev, index, NULL, NULL);
+    if ( addrp == NULL )
+        return -EINVAL;
+
+    /* Get parent & match bus type */
+    parent = dt_get_parent(dev);
+    if ( parent == NULL )
+        return -EINVAL;
+    bus = dt_match_bus(parent);
+    if ( !bus )
+        return -EINVAL;
+
+    /* Count address cells & copy address locally */
+    bus->count_cells(dev, &na, &ns);
+    if ( !DT_CHECK_ADDR_COUNT(na) )
+        return -EINVAL;
+
+    *addr = dt_read_number(addrp, na);
+    return 0;
+}
+
+
 /**
  * dt_find_node_by_phandle - Find a node given a phandle
  * @handle: phandle of the node to find
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 629bfb2..3d2a4ae 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -475,6 +475,17 @@ int dt_device_get_address(const struct dt_device_node *dev, int index,
                           u64 *addr, u64 *size);
 
 /**
+ * dt_device_get_address_raw - Get an address for a device
+ * @device: the device whose address is to be resolved
+ * @index: index of the address to resolve
+ * @addr: address filled by this function
+ *
+ * This function get a raw (unresolved) address. It returns 0 on success.
+ */
+int dt_device_get_address_raw(const struct dt_device_node *dev, int index,
+                          u64 *addr);
+
+/**
  * dt_number_of_irq - Get the number of IRQ for a device
  * @device: the device whose number of interrupt is to be retrieved
  *
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx6y-0007Zh-S8; Wed, 05 Nov 2014 09:42:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx6x-0007Yf-OK
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8F/44-09842-311F9545; Wed, 05 Nov 2014 09:42:43 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415180558!9449863!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16690 invoked from network); 5 Nov 2014 09:42:42 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:42 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBW70535; Wed, 05 Nov 2014 17:42:37 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:29 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:14 +0000
Message-ID: <1415180475-8339-8-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 7/8] xen/device_tree: Add
	dt_device_get_address_raw
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow to read untranslated address from device node.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/common/device_tree.c      | 34 ++++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h | 11 +++++++++++
 2 files changed, 45 insertions(+)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 1a886c0..4186a24 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -711,6 +711,40 @@ int dt_device_get_address(const struct dt_device_node *dev, int index,
     return 0;
 }
 
+/* dt_device_get_address_raw - Returns address not translated */
+int dt_device_get_address_raw(const struct dt_device_node *dev, int index,
+                          u64 *addr)
+{
+    const __be32 *addrp;
+    const struct dt_device_node *parent;
+    const struct dt_bus *bus;
+    int na, ns;
+
+    if ( !addr )
+        return -EINVAL;
+
+    addrp = dt_get_address(dev, index, NULL, NULL);
+    if ( addrp == NULL )
+        return -EINVAL;
+
+    /* Get parent & match bus type */
+    parent = dt_get_parent(dev);
+    if ( parent == NULL )
+        return -EINVAL;
+    bus = dt_match_bus(parent);
+    if ( !bus )
+        return -EINVAL;
+
+    /* Count address cells & copy address locally */
+    bus->count_cells(dev, &na, &ns);
+    if ( !DT_CHECK_ADDR_COUNT(na) )
+        return -EINVAL;
+
+    *addr = dt_read_number(addrp, na);
+    return 0;
+}
+
+
 /**
  * dt_find_node_by_phandle - Find a node given a phandle
  * @handle: phandle of the node to find
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 629bfb2..3d2a4ae 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -475,6 +475,17 @@ int dt_device_get_address(const struct dt_device_node *dev, int index,
                           u64 *addr, u64 *size);
 
 /**
+ * dt_device_get_address_raw - Get an address for a device
+ * @device: the device whose address is to be resolved
+ * @index: index of the address to resolve
+ * @addr: address filled by this function
+ *
+ * This function get a raw (unresolved) address. It returns 0 on success.
+ */
+int dt_device_get_address_raw(const struct dt_device_node *dev, int index,
+                          u64 *addr);
+
+/**
  * dt_number_of_irq - Get the number of IRQ for a device
  * @device: the device whose number of interrupt is to be retrieved
  *
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx73-0007dd-8z; Wed, 05 Nov 2014 09:42:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx71-0007c7-SX
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:48 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	2E/19-05632-711F9545; Wed, 05 Nov 2014 09:42:47 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415180562!11750791!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31453 invoked from network); 5 Nov 2014 09:42:46 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:46 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDY97078; Wed, 05 Nov 2014 17:42:41 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:33 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:15 +0000
Message-ID: <1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses for
	hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Translated address could have an offset applied to them.
Replicate same value for device node to avoid improper address
computation in the OS.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2f6bbd5..271074d 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -67,8 +67,10 @@
 /* Global state */
 static struct {
     paddr_t dbase;            /* Address of distributor registers */
+    paddr_t dbase_raw;        /* Untranslated address of distributor registers */
     void __iomem * map_dbase; /* IO mapped Address of distributor registers */
     paddr_t cbase;            /* Address of CPU interface registers */
+    paddr_t cbase_raw;        /* Untranslated address of CPU interface registers */
     void __iomem * map_cbase[2]; /* IO mapped Address of CPU interface registers */
     paddr_t hbase;            /* Address of virtual interface registers */
     void __iomem * map_hbase; /* IO Address of virtual interface registers */
@@ -671,8 +673,17 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOMEM);
 
     tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+
+    if ( is_hardware_domain(d) )
+    {
+        dt_set_range(&tmp, node, gicv2.dbase_raw, PAGE_SIZE);
+        dt_set_range(&tmp, node, gicv2.cbase_raw, PAGE_SIZE * 2);
+    }
+    else
+    {
+        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
+        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+    }
 
     res = fdt_property(fdt, "reg", new_cells, len);
     xfree(new_cells);
@@ -739,10 +750,18 @@ static int __init gicv2_init_default(struct dt_device_node *node, const void *da
     if ( res || !gicv2.dbase || (gicv2.dbase & ~PAGE_MASK) )
         panic("GICv2: Cannot find a valid address for the distributor");
 
+    res = dt_device_get_address_raw(node, 0, &gicv2.dbase_raw);
+    if ( res )
+        panic("GICv2: Cannot find a valid address for the distributor");
+
     res = dt_device_get_address(node, 1, &gicv2.cbase, NULL);
     if ( res || !gicv2.cbase || (gicv2.cbase & ~PAGE_MASK) )
         panic("GICv2: Cannot find a valid address for the CPU");
 
+    res = dt_device_get_address_raw(node, 1, &gicv2.cbase_raw);
+    if ( res )
+        panic("GICv2: Cannot find a valid address for the CPU");
+
     res = dt_device_get_address(node, 2, &gicv2.hbase, NULL);
     if ( res || !gicv2.hbase || (gicv2.hbase & ~PAGE_MASK) )
         panic("GICv2: Cannot find a valid address for the hypervisor");
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:42:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:42:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx73-0007dd-8z; Wed, 05 Nov 2014 09:42:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx71-0007c7-SX
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:42:48 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	2E/19-05632-711F9545; Wed, 05 Nov 2014 09:42:47 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415180562!11750791!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiA4MDE5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31453 invoked from network); 5 Nov 2014 09:42:46 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:42:46 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDY97078; Wed, 05 Nov 2014 17:42:41 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:33 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:15 +0000
Message-ID: <1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses for
	hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Translated address could have an offset applied to them.
Replicate same value for device node to avoid improper address
computation in the OS.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2f6bbd5..271074d 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -67,8 +67,10 @@
 /* Global state */
 static struct {
     paddr_t dbase;            /* Address of distributor registers */
+    paddr_t dbase_raw;        /* Untranslated address of distributor registers */
     void __iomem * map_dbase; /* IO mapped Address of distributor registers */
     paddr_t cbase;            /* Address of CPU interface registers */
+    paddr_t cbase_raw;        /* Untranslated address of CPU interface registers */
     void __iomem * map_cbase[2]; /* IO mapped Address of CPU interface registers */
     paddr_t hbase;            /* Address of virtual interface registers */
     void __iomem * map_hbase; /* IO Address of virtual interface registers */
@@ -671,8 +673,17 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOMEM);
 
     tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+
+    if ( is_hardware_domain(d) )
+    {
+        dt_set_range(&tmp, node, gicv2.dbase_raw, PAGE_SIZE);
+        dt_set_range(&tmp, node, gicv2.cbase_raw, PAGE_SIZE * 2);
+    }
+    else
+    {
+        dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
+        dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+    }
 
     res = fdt_property(fdt, "reg", new_cells, len);
     xfree(new_cells);
@@ -739,10 +750,18 @@ static int __init gicv2_init_default(struct dt_device_node *node, const void *da
     if ( res || !gicv2.dbase || (gicv2.dbase & ~PAGE_MASK) )
         panic("GICv2: Cannot find a valid address for the distributor");
 
+    res = dt_device_get_address_raw(node, 0, &gicv2.dbase_raw);
+    if ( res )
+        panic("GICv2: Cannot find a valid address for the distributor");
+
     res = dt_device_get_address(node, 1, &gicv2.cbase, NULL);
     if ( res || !gicv2.cbase || (gicv2.cbase & ~PAGE_MASK) )
         panic("GICv2: Cannot find a valid address for the CPU");
 
+    res = dt_device_get_address_raw(node, 1, &gicv2.cbase_raw);
+    if ( res )
+        panic("GICv2: Cannot find a valid address for the CPU");
+
     res = dt_device_get_address(node, 2, &gicv2.hbase, NULL);
     if ( res || !gicv2.hbase || (gicv2.hbase & ~PAGE_MASK) )
         panic("GICv2: Cannot find a valid address for the hypervisor");
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:44:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:44:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx8W-0008Eq-V4; Wed, 05 Nov 2014 09:44:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx8V-0008ER-On
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:44:19 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	FD/70-01660-371F9545; Wed, 05 Nov 2014 09:44:19 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415180534!11304085!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30724 invoked from network); 5 Nov 2014 09:44:17 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:44:17 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWQ73659; Wed, 05 Nov 2014 17:42:12 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:04 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:08 +0000
Message-ID: <1415180475-8339-2-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020205.5459F0F5.00BD, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e5101f1ef27fd5f5d7e8bae19f2010bf
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 1/8] xen/device_tree: Add new helper to read
	arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@linaro.org>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
---
 xen/common/device_tree.c      | 13 ++++++++++---
 xen/include/xen/device_tree.h | 11 +++++++++++
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..1a886c0 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -160,14 +160,21 @@ const void *dt_get_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                          const char *name, u32 *out_value)
 {
-    u32 len;
+    return dt_property_read_u32_array(np, name, out_value, 1);
+}
+
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len)
+{
+    u32 len, i;
     const __be32 *val;
 
     val = dt_get_property(np, name, &len);
-    if ( !val || len < sizeof(*out_value) )
+    if ( !val || len < sizeof(*out_value) * out_len )
         return 0;
 
-    *out_value = be32_to_cpup(val);
+    for ( i = 0; i < out_len; i++, val++ )
+        out_value[i] = be32_to_cpup(val);
 
     return 1;
 }
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..629bfb2 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                             const char *name, u32 *out_value);
 /**
+ * dt_property_read_u32_array - Helper to read a u32 array property.
+ * @np: node to get the value
+ * @name: name of the property
+ * @out_value: pointer to return value
+ * @out_len: length of the array
+ *
+ * Return true if get the desired value.
+ */
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len);
+/**
  * dt_property_read_u64 - Helper to read a u64 property.
  * @np: node to get the value
  * @name: name of the property
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:44:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:44:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx8W-0008Eq-V4; Wed, 05 Nov 2014 09:44:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xlx8V-0008ER-On
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:44:19 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	FD/70-01660-371F9545; Wed, 05 Nov 2014 09:44:19 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415180534!11304085!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30724 invoked from network); 5 Nov 2014 09:44:17 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:44:17 -0000
Received: from 172.24.2.119 (EHLO szxeml450-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWQ73659; Wed, 05 Nov 2014 17:42:12 +0800 (CST)
Received: from localhost.localdomain (10.47.71.64) by
	szxeml450-hub.china.huawei.com (10.82.67.193) with Microsoft SMTP
	Server id 14.3.158.1; Wed, 5 Nov 2014 17:42:04 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Wed, 5 Nov 2014 09:41:08 +0000
Message-ID: <1415180475-8339-2-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.71.64]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020205.5459F0F5.00BD, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e5101f1ef27fd5f5d7e8bae19f2010bf
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 1/8] xen/device_tree: Add new helper to read
	arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@linaro.org>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
---
 xen/common/device_tree.c      | 13 ++++++++++---
 xen/include/xen/device_tree.h | 11 +++++++++++
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..1a886c0 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -160,14 +160,21 @@ const void *dt_get_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                          const char *name, u32 *out_value)
 {
-    u32 len;
+    return dt_property_read_u32_array(np, name, out_value, 1);
+}
+
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len)
+{
+    u32 len, i;
     const __be32 *val;
 
     val = dt_get_property(np, name, &len);
-    if ( !val || len < sizeof(*out_value) )
+    if ( !val || len < sizeof(*out_value) * out_len )
         return 0;
 
-    *out_value = be32_to_cpup(val);
+    for ( i = 0; i < out_len; i++, val++ )
+        out_value[i] = be32_to_cpup(val);
 
     return 1;
 }
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..629bfb2 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                             const char *name, u32 *out_value);
 /**
+ * dt_property_read_u32_array - Helper to read a u32 array property.
+ * @np: node to get the value
+ * @name: name of the property
+ * @out_value: pointer to return value
+ * @out_len: length of the array
+ *
+ * Return true if get the desired value.
+ */
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len);
+/**
  * dt_property_read_u64 - Helper to read a u64 property.
  * @np: node to get the value
  * @name: name of the property
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:45:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:45:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx9T-0008UI-DS; Wed, 05 Nov 2014 09:45:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlx9R-0008Ta-Sk
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:45:17 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	9C/C0-14214-DA1F9545; Wed, 05 Nov 2014 09:45:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415180715!11280068!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28604 invoked from network); 5 Nov 2014 09:45:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:45:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189641252"
Message-ID: <1415180713.11486.61.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Wed, 5 Nov 2014 09:45:13 +0000
In-Reply-To: <54590D4D.90300@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 18:30 +0100, Atom2 wrote:
> Am 04.11.14 um 17:31 schrieb Ian Campbell:
> > On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
> >> Am 04.11.14 um 16:44 schrieb Ian Campbell:
> >>> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
> >>> You could try running the xl command under valgrind, you may find "xl
> >>> create -F" (which keeps xl in the foreground) handy if you try this.
> >>> That might help catch any heap corruption etc.
> >> I don't know what valgrind is, but I'll have a look and see how to deal
> >> with that ...
> >
> > Valgrind is a totally awesome memory allocation debugger ;-)
> >
> In the attached file named 'valgrind 'please find the output of
> 	# valgrind xl create -F -c pfsense

Sadly it looks like your version of valgrind doesn't know how to handle
the hypercalls made by the Xen toolstack, which means it produces a lot
of unrelated noise.

You seem to be using valgrind 3.9.0, which lacked knowledge of some of
the HVM related hypercalls that weren't added until 3.10.0. It's
probably not worth pursuing this angle any further (unless it is utterly
trivial to pull in the new version).

Apart from the valgrind output there is a new message from libxl:
        libxl: error: libxl_pci.c:1045:libxl__device_pci_add: PCI device 0000:04:00.0 cannot be assigned - no IOMMU?
which suggests that it isn't passing things through (this might be
fallout from valgrind not understanding things) and no segfault.

OOI what does "xl create -F ..." do without valgrind (I'm wondering if
-F is responsible for the change in behaviour).

> There's a lot of information in that file which is above my current 
> level of expertise, but I am sure you are able to make sense out of it.
> 
> BTW the stuff at lines 6 and 111 to 119 is the usual output of the xl 
> command before it segfaults.
> 
> Thanks Atom2



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:45:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:45:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlx9T-0008UI-DS; Wed, 05 Nov 2014 09:45:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlx9R-0008Ta-Sk
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:45:17 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	9C/C0-14214-DA1F9545; Wed, 05 Nov 2014 09:45:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415180715!11280068!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28604 invoked from network); 5 Nov 2014 09:45:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:45:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189641252"
Message-ID: <1415180713.11486.61.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Wed, 5 Nov 2014 09:45:13 +0000
In-Reply-To: <54590D4D.90300@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 18:30 +0100, Atom2 wrote:
> Am 04.11.14 um 17:31 schrieb Ian Campbell:
> > On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
> >> Am 04.11.14 um 16:44 schrieb Ian Campbell:
> >>> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
> >>> You could try running the xl command under valgrind, you may find "xl
> >>> create -F" (which keeps xl in the foreground) handy if you try this.
> >>> That might help catch any heap corruption etc.
> >> I don't know what valgrind is, but I'll have a look and see how to deal
> >> with that ...
> >
> > Valgrind is a totally awesome memory allocation debugger ;-)
> >
> In the attached file named 'valgrind 'please find the output of
> 	# valgrind xl create -F -c pfsense

Sadly it looks like your version of valgrind doesn't know how to handle
the hypercalls made by the Xen toolstack, which means it produces a lot
of unrelated noise.

You seem to be using valgrind 3.9.0, which lacked knowledge of some of
the HVM related hypercalls that weren't added until 3.10.0. It's
probably not worth pursuing this angle any further (unless it is utterly
trivial to pull in the new version).

Apart from the valgrind output there is a new message from libxl:
        libxl: error: libxl_pci.c:1045:libxl__device_pci_add: PCI device 0000:04:00.0 cannot be assigned - no IOMMU?
which suggests that it isn't passing things through (this might be
fallout from valgrind not understanding things) and no segfault.

OOI what does "xl create -F ..." do without valgrind (I'm wondering if
-F is responsible for the change in behaviour).

> There's a lot of information in that file which is above my current 
> level of expertise, but I am sure you are able to make sense out of it.
> 
> BTW the stuff at lines 6 and 111 to 119 is the usual output of the xl 
> command before it segfaults.
> 
> Thanks Atom2



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:52:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlxFq-0000RY-Gh; Wed, 05 Nov 2014 09:51:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlxFo-0000RT-Rq
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 09:51:52 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	1C/13-14214-833F9545; Wed, 05 Nov 2014 09:51:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415181110!11325155!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1028 invoked from network); 5 Nov 2014 09:51:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:51:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188244760"
Message-ID: <1415181080.11486.63.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Wed, 5 Nov 2014 09:51:20 +0000
In-Reply-To: <20141104.161704.1690311989900127361.davem@davemloft.net>
References: <1415036346.1411.3.camel@citrix.com>
	<5457BF80.2000205@citrix.com> <5457C807.5080509@linaro.org>
	<20141104.161704.1690311989900127361.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: zoltan.kiss@linaro.org, wei.liu2@citrix.com, netdev@vger.kernel.org,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	malcolm.crossley@citrix.com
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 16:17 -0500, David Miller wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> Date: Mon, 03 Nov 2014 18:23:03 +0000
> 
> > 
> > 
> > On 03/11/14 17:46, David Vrabel wrote:
> >> On 03/11/14 17:39, Ian Campbell wrote:
> >>> On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
> >>>> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> >>>>
> >>>> Unconditionally pulling 128 bytes into the linear buffer is not
> >>>> required. Netback has already grant copied up-to 128 bytes from the
> >>>> first slot of a packet into the linear buffer. The first slot normally
> >>>> contain all the IPv4/IPv6 and TCP/UDP headers.
> >>>
> >>> What about when it doesn't? It sounds as if we now won't pull up,
> >>> which
> >>> would be bad.
> >>
> >> The network stack will always pull any headers it needs to inspect
> >> (the
> >> frag may be a userspace page which has the same security issues as a
> >> frag with a foreign page).
> > I wouldn't bet my life on this, but indeed it should always happen.
> 
> I would bet my life on it.
> 
> Every protocol demux starts with pskb_may_pull() to pull frag data
> into the linear area, if necessary, before looking at headers.

Then I stand corrected, I was sure this wasn't the case (but my
information could well be a decade out of date...).

Is this also true for things which hit the iptables paths? I suppose
they must necessarily have already been through the protocol demux stage
before iptables would even be able to interpret them as e.g. an IP
packet.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:52:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlxFq-0000RY-Gh; Wed, 05 Nov 2014 09:51:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlxFo-0000RT-Rq
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 09:51:52 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	1C/13-14214-833F9545; Wed, 05 Nov 2014 09:51:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415181110!11325155!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1028 invoked from network); 5 Nov 2014 09:51:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:51:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188244760"
Message-ID: <1415181080.11486.63.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Wed, 5 Nov 2014 09:51:20 +0000
In-Reply-To: <20141104.161704.1690311989900127361.davem@davemloft.net>
References: <1415036346.1411.3.camel@citrix.com>
	<5457BF80.2000205@citrix.com> <5457C807.5080509@linaro.org>
	<20141104.161704.1690311989900127361.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: zoltan.kiss@linaro.org, wei.liu2@citrix.com, netdev@vger.kernel.org,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	malcolm.crossley@citrix.com
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 16:17 -0500, David Miller wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> Date: Mon, 03 Nov 2014 18:23:03 +0000
> 
> > 
> > 
> > On 03/11/14 17:46, David Vrabel wrote:
> >> On 03/11/14 17:39, Ian Campbell wrote:
> >>> On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
> >>>> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> >>>>
> >>>> Unconditionally pulling 128 bytes into the linear buffer is not
> >>>> required. Netback has already grant copied up-to 128 bytes from the
> >>>> first slot of a packet into the linear buffer. The first slot normally
> >>>> contain all the IPv4/IPv6 and TCP/UDP headers.
> >>>
> >>> What about when it doesn't? It sounds as if we now won't pull up,
> >>> which
> >>> would be bad.
> >>
> >> The network stack will always pull any headers it needs to inspect
> >> (the
> >> frag may be a userspace page which has the same security issues as a
> >> frag with a foreign page).
> > I wouldn't bet my life on this, but indeed it should always happen.
> 
> I would bet my life on it.
> 
> Every protocol demux starts with pskb_may_pull() to pull frag data
> into the linear area, if necessary, before looking at headers.

Then I stand corrected, I was sure this wasn't the case (but my
information could well be a decade out of date...).

Is this also true for things which hit the iptables paths? I suppose
they must necessarily have already been through the protocol demux stage
before iptables would even be able to interpret them as e.g. an IP
packet.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:53:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:53:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlxH6-0000as-4W; Wed, 05 Nov 2014 09:53: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 1XlxH4-0000ah-OX
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 09:53:10 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	98/85-14727-683F9545; Wed, 05 Nov 2014 09:53:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415181188!5899152!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5439 invoked from network); 5 Nov 2014 09:53:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:53:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188245207"
Message-ID: <1415181185.11486.65.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Wed, 5 Nov 2014 09:53:05 +0000
In-Reply-To: <20141104.164113.2265592775058059992.davem@davemloft.net>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
	<20141104.164113.2265592775058059992.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: netdev@vger.kernel.org, malcolm.crossley@citrix.com, wei.liu2@citrix.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 16:41 -0500, David Miller wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 3 Nov 2014 17:23:51 +0000
> 
> > From: Malcolm Crossley <malcolm.crossley@citrix.com>
> > 
> > Unconditionally pulling 128 bytes into the linear buffer is not
> > required. Netback has already grant copied up-to 128 bytes from the
> > first slot of a packet into the linear buffer. The first slot normally
> > contain all the IPv4/IPv6 and TCP/UDP headers.
> > 
> > The unconditional pull would often copy frag data unnecessarily.  This
> > is a performance problem when running on a version of Xen where grant
> > unmap avoids TLB flushes for pages which are not accessed.  TLB
> > flushes can now be avoided for > 99% of unmaps (it was 0% before).
> > 
> > Grant unmap TLB flush avoidance will be available in a future version
> > of Xen (probably 4.6).
> > 
> > Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Now that this has been discussed a bit, it is possible to get an ack or two?

I'd like to see the commit message expanded to explain why this isn't
introducing a (security) bug by not pulling enough stuff into the header
(IOW the conclusion of the discussion).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:53:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:53:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlxH6-0000as-4W; Wed, 05 Nov 2014 09:53: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 1XlxH4-0000ah-OX
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 09:53:10 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	98/85-14727-683F9545; Wed, 05 Nov 2014 09:53:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415181188!5899152!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5439 invoked from network); 5 Nov 2014 09:53:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 09:53:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188245207"
Message-ID: <1415181185.11486.65.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Wed, 5 Nov 2014 09:53:05 +0000
In-Reply-To: <20141104.164113.2265592775058059992.davem@davemloft.net>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
	<20141104.164113.2265592775058059992.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: netdev@vger.kernel.org, malcolm.crossley@citrix.com, wei.liu2@citrix.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 16:41 -0500, David Miller wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 3 Nov 2014 17:23:51 +0000
> 
> > From: Malcolm Crossley <malcolm.crossley@citrix.com>
> > 
> > Unconditionally pulling 128 bytes into the linear buffer is not
> > required. Netback has already grant copied up-to 128 bytes from the
> > first slot of a packet into the linear buffer. The first slot normally
> > contain all the IPv4/IPv6 and TCP/UDP headers.
> > 
> > The unconditional pull would often copy frag data unnecessarily.  This
> > is a performance problem when running on a version of Xen where grant
> > unmap avoids TLB flushes for pages which are not accessed.  TLB
> > flushes can now be avoided for > 99% of unmaps (it was 0% before).
> > 
> > Grant unmap TLB flush avoidance will be available in a future version
> > of Xen (probably 4.6).
> > 
> > Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Now that this has been discussed a bit, it is possible to get an ack or two?

I'd like to see the commit message expanded to explain why this isn't
introducing a (security) bug by not pulling enough stuff into the header
(IOW the conclusion of the discussion).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:59:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:59:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlxN6-0000uU-3c; Wed, 05 Nov 2014 09:59:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlxN4-0000uP-W2
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:59:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7C/3C-09842-AF4F9545; Wed, 05 Nov 2014 09:59:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415181557!9455322!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 636 invoked from network); 5 Nov 2014 09:59:21 -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;
	5 Nov 2014 09:59:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188246341"
Message-ID: <1415181555.11486.68.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kevin O'Connor <kevin@koconnor.net>
Date: Wed, 5 Nov 2014 09:59:15 +0000
In-Reply-To: <1415029377.24785.18.camel@citrix.com>
References: <1415008770.9994.6.camel@citrix.com>
	<1415009105.9994.8.camel@citrix.com>
	<20141103145958.GA27850@morn.localdomain>
	<1415029377.24785.18.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: seabios@seabios.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS]  Regression booting winxp under Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 15:42 +0000, Ian Campbell wrote:
> On Mon, 2014-11-03 at 09:59 -0500, Kevin O'Connor wrote:
> > On Mon, Nov 03, 2014 at 10:05:05AM +0000, Ian Campbell wrote:
> > > On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:
> > > 
> > > > I've not investigated more thoroughly yes, just posting in case
> > > > something obvious leaps out at someone. The automated test is currently
> > > > bisecting the issue, once it is done I'll let you know the result.
> > > 
> > > If I'd read a bit further through my Monday morning INBOX I'd have
> > > found:
> > >         http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
> > >         
> > > which indicates that the bisector has fingered:
> > > 
> > >   commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
> > 
> > Sorry about that - I missed one of the stack offset conversions in the
> > PNP part of that change.  The fix is below and I just pushed it to
> > the main repo.
> > 
> > Thanks for catching it.
> 
> Thanks for the quick fix!

FYI the next Xen osstest run didn't suffer from this issue, thanks.

(in case you go looking at the results, it did fail for other Xen
related reasons, nothing to do with seabios, but this issue is
definitely gone.)

> 
> > -Kevin
> > 
> > 
> > --- a/src/romlayout.S
> > +++ b/src/romlayout.S
> > @@ -286,7 +286,7 @@ entry_pnp_real:
> >          movw %cx, %ds
> >          leal BREGS_size-6+12(%esp), %eax  // %eax points to start of u16 args
> >          calll handle_pnp
> > -        movw %ax, 12(%esp)      // Modify %eax to return %ax
> > +        movw %ax, BREGS_eax(%esp)   // Modify %eax to return %ax
> >          POPBREGS
> >          popfl
> >          popl %esp
> 
> 
> 
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 09:59:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 09:59:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlxN6-0000uU-3c; Wed, 05 Nov 2014 09:59:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlxN4-0000uP-W2
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 09:59:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7C/3C-09842-AF4F9545; Wed, 05 Nov 2014 09:59:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415181557!9455322!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 636 invoked from network); 5 Nov 2014 09:59:21 -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;
	5 Nov 2014 09:59:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188246341"
Message-ID: <1415181555.11486.68.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kevin O'Connor <kevin@koconnor.net>
Date: Wed, 5 Nov 2014 09:59:15 +0000
In-Reply-To: <1415029377.24785.18.camel@citrix.com>
References: <1415008770.9994.6.camel@citrix.com>
	<1415009105.9994.8.camel@citrix.com>
	<20141103145958.GA27850@morn.localdomain>
	<1415029377.24785.18.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: seabios@seabios.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS]  Regression booting winxp under Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-03 at 15:42 +0000, Ian Campbell wrote:
> On Mon, 2014-11-03 at 09:59 -0500, Kevin O'Connor wrote:
> > On Mon, Nov 03, 2014 at 10:05:05AM +0000, Ian Campbell wrote:
> > > On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:
> > > 
> > > > I've not investigated more thoroughly yes, just posting in case
> > > > something obvious leaps out at someone. The automated test is currently
> > > > bisecting the issue, once it is done I'll let you know the result.
> > > 
> > > If I'd read a bit further through my Monday morning INBOX I'd have
> > > found:
> > >         http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
> > >         
> > > which indicates that the bisector has fingered:
> > > 
> > >   commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
> > 
> > Sorry about that - I missed one of the stack offset conversions in the
> > PNP part of that change.  The fix is below and I just pushed it to
> > the main repo.
> > 
> > Thanks for catching it.
> 
> Thanks for the quick fix!

FYI the next Xen osstest run didn't suffer from this issue, thanks.

(in case you go looking at the results, it did fail for other Xen
related reasons, nothing to do with seabios, but this issue is
definitely gone.)

> 
> > -Kevin
> > 
> > 
> > --- a/src/romlayout.S
> > +++ b/src/romlayout.S
> > @@ -286,7 +286,7 @@ entry_pnp_real:
> >          movw %cx, %ds
> >          leal BREGS_size-6+12(%esp), %eax  // %eax points to start of u16 args
> >          calll handle_pnp
> > -        movw %ax, 12(%esp)      // Modify %eax to return %ax
> > +        movw %ax, BREGS_eax(%esp)   // Modify %eax to return %ax
> >          POPBREGS
> >          popfl
> >          popl %esp
> 
> 
> 
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:00:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:00:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlxNs-00011u-Hu; Wed, 05 Nov 2014 10:00:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlxNq-00011o-JJ
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 10:00:10 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	EF/4C-02702-925F9545; Wed, 05 Nov 2014 10:00:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415181605!12675527!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24649 invoked from network); 5 Nov 2014 10:00:08 -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;
	5 Nov 2014 10:00:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189644199"
Message-ID: <1415181601.11486.69.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Emil Condrea <emilcondrea@gmail.com>
Date: Wed, 5 Nov 2014 10:00:01 +0000
In-Reply-To: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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

CCing Daniel.

On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
> 
> I am wondering if this is known issue that when I set locality!=0 to
> vtpmmgr it does not start. It is a bit strange that every call to
> tpm_tis_status returns 255 and device-id is also FFFF: 
> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
> TPM interface capabilities (0xffffffff):
> 
> I am configuring vtpmmgr using:
> 
> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
> memory=8
> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
> name="vtpmmgr"
> iomem=["fed40,5"]
> extra="tpmlocality=2"
> 
> 
> I also tried using :
> iomem=["fed40,1"]
> extra="tpmlocality=0"//works well
> 
> or
> iomem=["fed42,1"]
> extra="tpmlocality=2"
> It seems that everything that is not mapped at fed40-fed41 is
> FFFFFFFF.
> 
> I have an Atmel TPM chipset. 
> 
> Could it be a chipset problem to not handle well different localities?
> 
> When I use locality=0, the device driver info is correct and
> everything works fine:
> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
> TPM interface capabilities (0xfd)
> 
> In linux kernel this information is obtained using locality 0 and
> after that other commands execute using specified locality.
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/tpm/tpm_tis.c#n558
> 
> 
> Thanks,
> 
> Emil
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 05 10:00:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:00:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlxNs-00011u-Hu; Wed, 05 Nov 2014 10:00:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlxNq-00011o-JJ
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 10:00:10 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	EF/4C-02702-925F9545; Wed, 05 Nov 2014 10:00:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415181605!12675527!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24649 invoked from network); 5 Nov 2014 10:00:08 -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;
	5 Nov 2014 10:00:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189644199"
Message-ID: <1415181601.11486.69.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Emil Condrea <emilcondrea@gmail.com>
Date: Wed, 5 Nov 2014 10:00:01 +0000
In-Reply-To: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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

CCing Daniel.

On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
> 
> I am wondering if this is known issue that when I set locality!=0 to
> vtpmmgr it does not start. It is a bit strange that every call to
> tpm_tis_status returns 255 and device-id is also FFFF: 
> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
> TPM interface capabilities (0xffffffff):
> 
> I am configuring vtpmmgr using:
> 
> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
> memory=8
> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
> name="vtpmmgr"
> iomem=["fed40,5"]
> extra="tpmlocality=2"
> 
> 
> I also tried using :
> iomem=["fed40,1"]
> extra="tpmlocality=0"//works well
> 
> or
> iomem=["fed42,1"]
> extra="tpmlocality=2"
> It seems that everything that is not mapped at fed40-fed41 is
> FFFFFFFF.
> 
> I have an Atmel TPM chipset. 
> 
> Could it be a chipset problem to not handle well different localities?
> 
> When I use locality=0, the device driver info is correct and
> everything works fine:
> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
> TPM interface capabilities (0xfd)
> 
> In linux kernel this information is obtained using locality 0 and
> after that other commands execute using specified locality.
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/tpm/tpm_tis.c#n558
> 
> 
> Thanks,
> 
> Emil
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 05 10:24:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10: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 1Xlxl5-0001mK-0S; Wed, 05 Nov 2014 10:24:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlxl4-0001mF-9Y
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:24:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A5/0D-24532-9CAF9545; Wed, 05 Nov 2014 10:24:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415183044!12938130!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18477 invoked from network); 5 Nov 2014 10:24:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:24:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188252831"
Message-ID: <1415183041.11486.74.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 5 Nov 2014 10:24:01 +0000
In-Reply-To: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2014-11-01 at 20:10 +0000, Julien Grall wrote:
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index a9bcd4a..1aa1f45 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>      return 0;
>  }
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config)
> +{
> +    int rc;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> +    domctl.domain = (domid_t)domid;
> +    /* xc_domain_configure_t is an alias to xen_domctl_arm_configuredomain */

"is an alias of".

> +
> +    res = fdt_property_compat(gc, fdt, 1,
> +                              "arm,gic-v3");

Doesn't need wrapping I expect.

>  static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
>  {
>      int res;
> @@ -456,6 +519,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>                                             libxl_domain_build_info *info,
>                                             struct xc_dom_image *dom)
>  {
> +    xc_domain_configuration_t config;
>      void *fdt = NULL;
>      int rc, res;
>      size_t fdt_size = 0;
> @@ -471,8 +535,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>      ainfo = get_arch_info(gc, dom);
>      if (ainfo == NULL) return ERROR_FAIL;
>  
> +    LOG(DEBUG, "configure the domain");
> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> +        LOG(ERROR, "counldn't configure the domain");

"couldn't"

> @@ -520,9 +592,22 @@ next_resize:
>          FDT( make_psci_node(gc, fdt) );
>  
>          FDT( make_memory_nodes(gc, fdt, dom) );
> -        FDT( make_intc_node(gc, fdt,
> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> +
> +        switch (config.gic_version) {
> +        case XEN_DOMCTL_CONFIG_GIC_V2:
> +            FDT( make_gicv2_node(gc, fdt,
> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> +            break;
> +        case XEN_DOMCTL_CONFIG_GIC_V3:
> +            FDT( make_gicv3_node(gc, fdt) );
> +            break;
> +        default:
> +            LOG(ERROR, "Unknown how to create the DT node for gic_version = %d",
> +                config.gic_version);

"Don't know how..." or even just "Unknown GIC version %d".

> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>  
>          return p2m_cache_flush(d, s, e);
>      }
> +    case XEN_DOMCTL_arm_configure_domain:
> +    {
> +        uint8_t gic_version;
> +
> +        /*
> +         * Xen 4.5: The vGIC is emulating the same version of the

No need to say "Xen 4.5" here, this comment is true until it is removed.
You could say "Currently the vGIC is..." or something if you wanted to
indicate that this is temporary.

> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> +         * is allowed. The DOMCTL will return the actual version of the
> +         * GIC.
> +         */
> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> +            return -EOPNOTSUPP;

EOPNOTSUPP doesn't seem quite right. EPARM  or EINVAL perhaps?

I'm also tempted to suggest that we should accept gic_version == the hw
value, i.e. by moping the switch below up and including
        && domctl->u.configuredomain.gic_version != gic_version
in the condition.

> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */

Don't we only support 8 cpus today? I don't mind reserving space for
more, and I'd be pleasantly surprised if 16 actually worked ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:24:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10: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 1Xlxl5-0001mK-0S; Wed, 05 Nov 2014 10:24:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlxl4-0001mF-9Y
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:24:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A5/0D-24532-9CAF9545; Wed, 05 Nov 2014 10:24:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415183044!12938130!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18477 invoked from network); 5 Nov 2014 10:24:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:24:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188252831"
Message-ID: <1415183041.11486.74.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 5 Nov 2014 10:24:01 +0000
In-Reply-To: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2014-11-01 at 20:10 +0000, Julien Grall wrote:
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index a9bcd4a..1aa1f45 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>      return 0;
>  }
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config)
> +{
> +    int rc;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> +    domctl.domain = (domid_t)domid;
> +    /* xc_domain_configure_t is an alias to xen_domctl_arm_configuredomain */

"is an alias of".

> +
> +    res = fdt_property_compat(gc, fdt, 1,
> +                              "arm,gic-v3");

Doesn't need wrapping I expect.

>  static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
>  {
>      int res;
> @@ -456,6 +519,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>                                             libxl_domain_build_info *info,
>                                             struct xc_dom_image *dom)
>  {
> +    xc_domain_configuration_t config;
>      void *fdt = NULL;
>      int rc, res;
>      size_t fdt_size = 0;
> @@ -471,8 +535,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>      ainfo = get_arch_info(gc, dom);
>      if (ainfo == NULL) return ERROR_FAIL;
>  
> +    LOG(DEBUG, "configure the domain");
> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> +        LOG(ERROR, "counldn't configure the domain");

"couldn't"

> @@ -520,9 +592,22 @@ next_resize:
>          FDT( make_psci_node(gc, fdt) );
>  
>          FDT( make_memory_nodes(gc, fdt, dom) );
> -        FDT( make_intc_node(gc, fdt,
> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> +
> +        switch (config.gic_version) {
> +        case XEN_DOMCTL_CONFIG_GIC_V2:
> +            FDT( make_gicv2_node(gc, fdt,
> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> +            break;
> +        case XEN_DOMCTL_CONFIG_GIC_V3:
> +            FDT( make_gicv3_node(gc, fdt) );
> +            break;
> +        default:
> +            LOG(ERROR, "Unknown how to create the DT node for gic_version = %d",
> +                config.gic_version);

"Don't know how..." or even just "Unknown GIC version %d".

> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>  
>          return p2m_cache_flush(d, s, e);
>      }
> +    case XEN_DOMCTL_arm_configure_domain:
> +    {
> +        uint8_t gic_version;
> +
> +        /*
> +         * Xen 4.5: The vGIC is emulating the same version of the

No need to say "Xen 4.5" here, this comment is true until it is removed.
You could say "Currently the vGIC is..." or something if you wanted to
indicate that this is temporary.

> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> +         * is allowed. The DOMCTL will return the actual version of the
> +         * GIC.
> +         */
> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> +            return -EOPNOTSUPP;

EOPNOTSUPP doesn't seem quite right. EPARM  or EINVAL perhaps?

I'm also tempted to suggest that we should accept gic_version == the hw
value, i.e. by moping the switch below up and including
        && domctl->u.configuredomain.gic_version != gic_version
in the condition.

> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */

Don't we only support 8 cpus today? I don't mind reserving space for
more, and I'd be pleasantly surprised if 16 actually worked ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:25:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10: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 1XlxmN-0001tO-Go; Wed, 05 Nov 2014 10:25:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlxmM-0001tG-04
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:25:30 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	42/50-17958-91BF9545; Wed, 05 Nov 2014 10:25:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415183127!11746903!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13018 invoked from network); 5 Nov 2014 10:25:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:25:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188253058"
Message-ID: <1415183124.11486.76.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 5 Nov 2014 10:25:24 +0000
In-Reply-To: <54590C48.4080100@linaro.org>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, Tim
	Deegan <tim@xen.org>, Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 17:26 +0000, Julien Grall wrote:
> Hi Konrad,
> 
> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 03, 2014 at 06:07:33PM +0530, Vijay Kilari wrote:
> >> On Mon, Nov 3, 2014 at 4:31 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >>> On Sat, 1 Nov 2014, Julien Grall wrote:
> >>>> The vGIC will emulate the same version as the hardware. The toolstack has
> >>>> to retrieve the version of the vGIC in order to be able to create the
> >>>> corresponding device tree node.
> >>>>
> >>>> A new DOMCTL has been introduced for ARM to configure the domain. For now
> >>>> it only allow the toolstack to retrieve the version of vGIC.
> >>>> This DOMCTL will be extend later to let the user choose the version of the
> >>>> emulated GIC.
> >>>>
> >>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> >>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >>>> Cc: Jan Beulich <jbeulich@suse.com>
> >>>> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >>>> Cc: Wei Liu <wei.liu2@citrix.com>
> >>>
> >>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>
> >> Tested with GICv3 platform.
> > 
> > Thank you for doing that.
> > 
> > It also needs Acks from Daniel and Jan.
> 
> This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
> required. Would Ian C. ack be enough?

Jan had comments on a previous iteration and adding a new domctl (or
hypercalls generally) could do with eyes from all arches even if they
are currently arch specific, so it would be good to know that he at
least doesn't object.

> Anyway, Jan do you have any objection on this patch?
> 
> Regards,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:25:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10: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 1XlxmN-0001tO-Go; Wed, 05 Nov 2014 10:25:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlxmM-0001tG-04
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:25:30 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	42/50-17958-91BF9545; Wed, 05 Nov 2014 10:25:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415183127!11746903!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13018 invoked from network); 5 Nov 2014 10:25:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:25:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188253058"
Message-ID: <1415183124.11486.76.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 5 Nov 2014 10:25:24 +0000
In-Reply-To: <54590C48.4080100@linaro.org>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, Tim
	Deegan <tim@xen.org>, Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 17:26 +0000, Julien Grall wrote:
> Hi Konrad,
> 
> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 03, 2014 at 06:07:33PM +0530, Vijay Kilari wrote:
> >> On Mon, Nov 3, 2014 at 4:31 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >>> On Sat, 1 Nov 2014, Julien Grall wrote:
> >>>> The vGIC will emulate the same version as the hardware. The toolstack has
> >>>> to retrieve the version of the vGIC in order to be able to create the
> >>>> corresponding device tree node.
> >>>>
> >>>> A new DOMCTL has been introduced for ARM to configure the domain. For now
> >>>> it only allow the toolstack to retrieve the version of vGIC.
> >>>> This DOMCTL will be extend later to let the user choose the version of the
> >>>> emulated GIC.
> >>>>
> >>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> >>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >>>> Cc: Jan Beulich <jbeulich@suse.com>
> >>>> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >>>> Cc: Wei Liu <wei.liu2@citrix.com>
> >>>
> >>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>
> >> Tested with GICv3 platform.
> > 
> > Thank you for doing that.
> > 
> > It also needs Acks from Daniel and Jan.
> 
> This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
> required. Would Ian C. ack be enough?

Jan had comments on a previous iteration and adding a new domctl (or
hypercalls generally) could do with eyes from all arches even if they
are currently arch specific, so it would be good to know that he at
least doesn't object.

> Anyway, Jan do you have any objection on this patch?
> 
> Regards,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:47:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xly76-0002SB-Oh; Wed, 05 Nov 2014 10:46:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xly76-0002S6-1L
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:46:56 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	30/F2-02576-F100A545; Wed, 05 Nov 2014 10:46:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415184413!12659803!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10814 invoked from network); 5 Nov 2014 10:46:54 -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;
	5 Nov 2014 10:46:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188257886"
Message-ID: <545A000D.8070808@citrix.com>
Date: Wed, 5 Nov 2014 10:46:37 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Eric Dumazet <eric.dumazet@gmail.com>, David Miller <davem@davemloft.net>
References: <1415036346.1411.3.camel@citrix.com>	
	<5457BF80.2000205@citrix.com> <5457C807.5080509@linaro.org>	
	<20141104.161704.1690311989900127361.davem@davemloft.net>
	<1415137397.25370.7.camel@edumazet-glaptop2.roam.corp.google.com>
In-Reply-To: <1415137397.25370.7.camel@edumazet-glaptop2.roam.corp.google.com>
X-DLP: MIA2
Cc: zoltan.kiss@linaro.org, wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	netdev@vger.kernel.org, xen-devel@lists.xenproject.org,
	malcolm.crossley@citrix.com
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/14 21:43, Eric Dumazet wrote:
> On Tue, 2014-11-04 at 16:17 -0500, David Miller wrote:
> 
> 
>>
>> Every protocol demux starts with pskb_may_pull() to pull frag data
>> into the linear area, if necessary, before looking at headers.
> 
> eth_get_headlen() might be relevant as well, to perform a single copy of
> exactly all headers.

In netback's case we need an estimate of the header length before
reading any of the packet, since peeking at any frag would prevent any
TLB flush avoidance.

It might be useful to use eth_get_headlen() to adjust the estimate at
runtime, but for now the fixed amount of 128 bytes is simple and seems
good enough.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:47:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xly76-0002SB-Oh; Wed, 05 Nov 2014 10:46:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xly76-0002S6-1L
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:46:56 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	30/F2-02576-F100A545; Wed, 05 Nov 2014 10:46:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415184413!12659803!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10814 invoked from network); 5 Nov 2014 10:46:54 -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;
	5 Nov 2014 10:46:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188257886"
Message-ID: <545A000D.8070808@citrix.com>
Date: Wed, 5 Nov 2014 10:46:37 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Eric Dumazet <eric.dumazet@gmail.com>, David Miller <davem@davemloft.net>
References: <1415036346.1411.3.camel@citrix.com>	
	<5457BF80.2000205@citrix.com> <5457C807.5080509@linaro.org>	
	<20141104.161704.1690311989900127361.davem@davemloft.net>
	<1415137397.25370.7.camel@edumazet-glaptop2.roam.corp.google.com>
In-Reply-To: <1415137397.25370.7.camel@edumazet-glaptop2.roam.corp.google.com>
X-DLP: MIA2
Cc: zoltan.kiss@linaro.org, wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	netdev@vger.kernel.org, xen-devel@lists.xenproject.org,
	malcolm.crossley@citrix.com
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/14 21:43, Eric Dumazet wrote:
> On Tue, 2014-11-04 at 16:17 -0500, David Miller wrote:
> 
> 
>>
>> Every protocol demux starts with pskb_may_pull() to pull frag data
>> into the linear area, if necessary, before looking at headers.
> 
> eth_get_headlen() might be relevant as well, to perform a single copy of
> exactly all headers.

In netback's case we need an estimate of the header length before
reading any of the packet, since peeking at any frag would prevent any
TLB flush avoidance.

It might be useful to use eth_get_headlen() to adjust the estimate at
runtime, but for now the fixed amount of 128 bytes is simple and seems
good enough.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:47:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:47:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xly7m-0002V1-GK; Wed, 05 Nov 2014 10:47:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xly7l-0002Un-5j
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 10:47:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7B/25-24532-8400A545; Wed, 05 Nov 2014 10:47:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415184454!4887432!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23608 invoked from network); 5 Nov 2014 10:47:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:47:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189655957"
Message-ID: <1415184452.11486.80.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 5 Nov 2014 10:47:32 +0000
In-Reply-To: <20141104171144.GJ4510@laptop.dumpdata.com>
References: <1414144694.15687.31.camel@citrix.com>
	<1414144717-32328-1-git-send-email-ian.campbell@citrix.com>
	<54513A08.3000908@linaro.org> <1415096635.11486.15.camel@citrix.com>
	<20141104171144.GJ4510@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, xen-devel@lists.xen.org, Clark
	Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 1/5] xen: arm: propagate gic's
 #address-cells property 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 Tue, 2014-11-04 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 04, 2014 at 10:23:55AM +0000, Ian Campbell wrote:
> > On Wed, 2014-10-29 at 19:03 +0000, Julien Grall wrote:
> > > Hi Ian,
> > > 
> > > On 24/10/2014 10:58, Ian Campbell wrote:
> > > > The interrupt-map property requires that the interrupt-parent node
> > > > must have both #address-cells and #interrupt-cells properties (see
> > > > ePAPR 2.4.3.1). Therefore propagate the property if it is present.
> > > >
> > > > We must propagate (rather than invent our own value) since this value
> > > > is used to size fields within other properties within the tree.
> > > >
> > > > ePAPR strictly speaking requires that the interrupt-parent node
> > > > always has these properties. However reality has diverged from this
> > > > and implementations will recursively search parents for #*-cells
> > > > properties. Hence we only copy if it is present.
> > > >
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > Reviewed-by: Julien Grall <julien.grall@linaro.org>
> > > 
> > > Without this patch I can't boot Xen on the Foundation model with GIC-v3. 
> > > Is it possible to push this patch for Xen 4.5 rc1?
> > 
> > Konrad, I think this is needed for 4.5 since without it dom0 can fail to
> > parse certain other constructs within the DT (in bits which we don't
> > generate and can't easily/don't want to rewrite as we pass them
> > through).
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, thanks.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:47:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:47:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xly7m-0002V1-GK; Wed, 05 Nov 2014 10:47:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xly7l-0002Un-5j
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 10:47:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7B/25-24532-8400A545; Wed, 05 Nov 2014 10:47:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415184454!4887432!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23608 invoked from network); 5 Nov 2014 10:47:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:47:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189655957"
Message-ID: <1415184452.11486.80.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 5 Nov 2014 10:47:32 +0000
In-Reply-To: <20141104171144.GJ4510@laptop.dumpdata.com>
References: <1414144694.15687.31.camel@citrix.com>
	<1414144717-32328-1-git-send-email-ian.campbell@citrix.com>
	<54513A08.3000908@linaro.org> <1415096635.11486.15.camel@citrix.com>
	<20141104171144.GJ4510@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, xen-devel@lists.xen.org, Clark
	Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 1/5] xen: arm: propagate gic's
 #address-cells property 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 Tue, 2014-11-04 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 04, 2014 at 10:23:55AM +0000, Ian Campbell wrote:
> > On Wed, 2014-10-29 at 19:03 +0000, Julien Grall wrote:
> > > Hi Ian,
> > > 
> > > On 24/10/2014 10:58, Ian Campbell wrote:
> > > > The interrupt-map property requires that the interrupt-parent node
> > > > must have both #address-cells and #interrupt-cells properties (see
> > > > ePAPR 2.4.3.1). Therefore propagate the property if it is present.
> > > >
> > > > We must propagate (rather than invent our own value) since this value
> > > > is used to size fields within other properties within the tree.
> > > >
> > > > ePAPR strictly speaking requires that the interrupt-parent node
> > > > always has these properties. However reality has diverged from this
> > > > and implementations will recursively search parents for #*-cells
> > > > properties. Hence we only copy if it is present.
> > > >
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > Reviewed-by: Julien Grall <julien.grall@linaro.org>
> > > 
> > > Without this patch I can't boot Xen on the Foundation model with GIC-v3. 
> > > Is it possible to push this patch for Xen 4.5 rc1?
> > 
> > Konrad, I think this is needed for 4.5 since without it dom0 can fail to
> > parse certain other constructs within the DT (in bits which we don't
> > generate and can't easily/don't want to rewrite as we pass them
> > through).
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, thanks.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:47:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:47:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xly7s-0002Wc-Tt; Wed, 05 Nov 2014 10:47:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xly7s-0002WQ-Cw
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 10:47:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	85/34-09936-F400A545; Wed, 05 Nov 2014 10:47:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415184462!4887482!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25154 invoked from network); 5 Nov 2014 10:47:43 -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;
	5 Nov 2014 10:47:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188258225"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 05:47:41 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xly1k-0003U2-Ad;
	Wed, 05 Nov 2014 10:41:25 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Wed, 05 Nov
	2014 10:41:24 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Wed, 5 Nov 2014 10:41:24 +0000
Message-ID: <1415184084-14650-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST] standalone: Handle multiple
	configuration files.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

OSSTEST_CONFIG can actually be a colon separate list of files, so take this
into account when sanity checking it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 standalone | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/standalone b/standalone
index c1139f8..caf3fd5 100755
--- a/standalone
+++ b/standalone
@@ -112,10 +112,19 @@ if [ ! -f standalone.db ] ; then
     exit 1
 fi
 
-if [ -z "$config" -o ! -r "$config" ] ; then
-    echo "Cannot read config." >&2
+if [ -z "$config" ] ; then
+    echo "No config specified." >&2
     exit 1
 fi
+IFS_saved=$IFS
+IFS=:
+for c in $config ; do
+    if [ -z "$c" -o ! -r "$c" ] ; then
+        echo "Cannot read config $c." >&2
+        exit 1
+    fi
+done
+IFS=$IFS_saved
 
 need_flight() {
     if [ -z "$flight" ] ; then
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:47:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:47:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xly7s-0002Wc-Tt; Wed, 05 Nov 2014 10:47:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xly7s-0002WQ-Cw
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 10:47:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	85/34-09936-F400A545; Wed, 05 Nov 2014 10:47:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415184462!4887482!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25154 invoked from network); 5 Nov 2014 10:47:43 -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;
	5 Nov 2014 10:47:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188258225"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 05:47:41 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xly1k-0003U2-Ad;
	Wed, 05 Nov 2014 10:41:25 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Wed, 05 Nov
	2014 10:41:24 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Wed, 5 Nov 2014 10:41:24 +0000
Message-ID: <1415184084-14650-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST] standalone: Handle multiple
	configuration files.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

OSSTEST_CONFIG can actually be a colon separate list of files, so take this
into account when sanity checking it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 standalone | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/standalone b/standalone
index c1139f8..caf3fd5 100755
--- a/standalone
+++ b/standalone
@@ -112,10 +112,19 @@ if [ ! -f standalone.db ] ; then
     exit 1
 fi
 
-if [ -z "$config" -o ! -r "$config" ] ; then
-    echo "Cannot read config." >&2
+if [ -z "$config" ] ; then
+    echo "No config specified." >&2
     exit 1
 fi
+IFS_saved=$IFS
+IFS=:
+for c in $config ; do
+    if [ -z "$c" -o ! -r "$c" ] ; then
+        echo "Cannot read config $c." >&2
+        exit 1
+    fi
+done
+IFS=$IFS_saved
 
 need_flight() {
     if [ -z "$flight" ] ; then
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:50:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyAZ-0002on-Sv; Wed, 05 Nov 2014 10:50:31 +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 1XlyAY-0002oc-P8
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:50:30 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	DE/87-31453-6F00A545; Wed, 05 Nov 2014 10:50:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415184627!11324280!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14848 invoked from network); 5 Nov 2014 10:50:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:50:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188258893"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 05:50:27 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XlyAU-0004PN-Jw;
	Wed, 05 Nov 2014 10:50:26 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 5 Nov 2014 10:50:22 +0000
Message-ID: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCHv2 net-next] xen-netback: remove unconditional
	__pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Malcolm Crossley <malcolm.crossley@citrix.com>

Unconditionally pulling 128 bytes into the linear area is not required
for:

- security: Every protocol demux starts with pskb_may_pull() to pull
  frag data into the linear area, if necessary, before looking at
  headers.

- performance: Netback has already grant copied up-to 128 bytes from
  the first slot of a packet into the linear area. The first slot
  normally contain all the IPv4/IPv6 and TCP/UDP headers.

The unconditional pull would often copy frag data unnecessarily.  This
is a performance problem when running on a version of Xen where grant
unmap avoids TLB flushes for pages which are not accessed.  TLB
flushes can now be avoided for > 99% of unmaps (it was 0% before).

Grant unmap TLB flush avoidance will be available in a future version
of Xen (probably 4.6).

Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/netback.c |   26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 730252c..14e18bb 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -82,6 +82,16 @@ MODULE_PARM_DESC(max_queues,
 static unsigned int fatal_skb_slots = FATAL_SKB_SLOTS_DEFAULT;
 module_param(fatal_skb_slots, uint, 0444);
 
+/* The amount to copy out of the first guest Tx slot into the skb's
+ * linear area.  If the first slot has more data, it will be mapped
+ * and put into the first frag.
+ *
+ * This is sized to avoid pulling headers from the frags for most
+ * TCP/IP packets.
+ */
+#define XEN_NETBACK_TX_COPY_LEN 128
+
+
 static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx,
 			       u8 status);
 
@@ -125,13 +135,6 @@ static inline struct xenvif_queue *ubuf_to_queue(const struct ubuf_info *ubuf)
 			    pending_tx_info[0]);
 }
 
-/* This is a miniumum size for the linear area to avoid lots of
- * calls to __pskb_pull_tail() as we set up checksum offsets. The
- * value 128 was chosen as it covers all IPv4 and most likely
- * IPv6 headers.
- */
-#define PKT_PROT_LEN 128
-
 static u16 frag_get_pending_idx(skb_frag_t *frag)
 {
 	return (u16)frag->page_offset;
@@ -1446,9 +1449,9 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
 		index = pending_index(queue->pending_cons);
 		pending_idx = queue->pending_ring[index];
 
-		data_len = (txreq.size > PKT_PROT_LEN &&
+		data_len = (txreq.size > XEN_NETBACK_TX_COPY_LEN &&
 			    ret < XEN_NETBK_LEGACY_SLOTS_MAX) ?
-			PKT_PROT_LEN : txreq.size;
+			XEN_NETBACK_TX_COPY_LEN : txreq.size;
 
 		skb = xenvif_alloc_skb(data_len);
 		if (unlikely(skb == NULL)) {
@@ -1653,11 +1656,6 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
 			}
 		}
 
-		if (skb_is_nonlinear(skb) && skb_headlen(skb) < PKT_PROT_LEN) {
-			int target = min_t(int, skb->len, PKT_PROT_LEN);
-			__pskb_pull_tail(skb, target - skb_headlen(skb));
-		}
-
 		skb->dev      = queue->vif->dev;
 		skb->protocol = eth_type_trans(skb, skb->dev);
 		skb_reset_network_header(skb);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:50:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyAZ-0002on-Sv; Wed, 05 Nov 2014 10:50:31 +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 1XlyAY-0002oc-P8
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:50:30 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	DE/87-31453-6F00A545; Wed, 05 Nov 2014 10:50:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415184627!11324280!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14848 invoked from network); 5 Nov 2014 10:50:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:50:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188258893"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 05:50:27 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XlyAU-0004PN-Jw;
	Wed, 05 Nov 2014 10:50:26 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 5 Nov 2014 10:50:22 +0000
Message-ID: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCHv2 net-next] xen-netback: remove unconditional
	__pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Malcolm Crossley <malcolm.crossley@citrix.com>

Unconditionally pulling 128 bytes into the linear area is not required
for:

- security: Every protocol demux starts with pskb_may_pull() to pull
  frag data into the linear area, if necessary, before looking at
  headers.

- performance: Netback has already grant copied up-to 128 bytes from
  the first slot of a packet into the linear area. The first slot
  normally contain all the IPv4/IPv6 and TCP/UDP headers.

The unconditional pull would often copy frag data unnecessarily.  This
is a performance problem when running on a version of Xen where grant
unmap avoids TLB flushes for pages which are not accessed.  TLB
flushes can now be avoided for > 99% of unmaps (it was 0% before).

Grant unmap TLB flush avoidance will be available in a future version
of Xen (probably 4.6).

Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/netback.c |   26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 730252c..14e18bb 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -82,6 +82,16 @@ MODULE_PARM_DESC(max_queues,
 static unsigned int fatal_skb_slots = FATAL_SKB_SLOTS_DEFAULT;
 module_param(fatal_skb_slots, uint, 0444);
 
+/* The amount to copy out of the first guest Tx slot into the skb's
+ * linear area.  If the first slot has more data, it will be mapped
+ * and put into the first frag.
+ *
+ * This is sized to avoid pulling headers from the frags for most
+ * TCP/IP packets.
+ */
+#define XEN_NETBACK_TX_COPY_LEN 128
+
+
 static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx,
 			       u8 status);
 
@@ -125,13 +135,6 @@ static inline struct xenvif_queue *ubuf_to_queue(const struct ubuf_info *ubuf)
 			    pending_tx_info[0]);
 }
 
-/* This is a miniumum size for the linear area to avoid lots of
- * calls to __pskb_pull_tail() as we set up checksum offsets. The
- * value 128 was chosen as it covers all IPv4 and most likely
- * IPv6 headers.
- */
-#define PKT_PROT_LEN 128
-
 static u16 frag_get_pending_idx(skb_frag_t *frag)
 {
 	return (u16)frag->page_offset;
@@ -1446,9 +1449,9 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
 		index = pending_index(queue->pending_cons);
 		pending_idx = queue->pending_ring[index];
 
-		data_len = (txreq.size > PKT_PROT_LEN &&
+		data_len = (txreq.size > XEN_NETBACK_TX_COPY_LEN &&
 			    ret < XEN_NETBK_LEGACY_SLOTS_MAX) ?
-			PKT_PROT_LEN : txreq.size;
+			XEN_NETBACK_TX_COPY_LEN : txreq.size;
 
 		skb = xenvif_alloc_skb(data_len);
 		if (unlikely(skb == NULL)) {
@@ -1653,11 +1656,6 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
 			}
 		}
 
-		if (skb_is_nonlinear(skb) && skb_headlen(skb) < PKT_PROT_LEN) {
-			int target = min_t(int, skb->len, PKT_PROT_LEN);
-			__pskb_pull_tail(skb, target - skb_headlen(skb));
-		}
-
 		skb->dev      = queue->vif->dev;
 		skb->protocol = eth_type_trans(skb, skb->dev);
 		skb_reset_network_header(skb);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:50:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:50:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyAu-0002rR-8f; Wed, 05 Nov 2014 10:50:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlyAt-0002rG-9i
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:50:51 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	7D/BD-25547-A010A545; Wed, 05 Nov 2014 10:50:50 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415184648!11771394!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17040 invoked from network); 5 Nov 2014 10:50:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:50:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189656812"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 05:50:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlxs2-0002v8-SC;
	Wed, 05 Nov 2014 10:31:22 +0000
Date: Wed, 5 Nov 2014 10:31:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415183041.11486.74.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411051029370.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Ian Campbell wrote:
> > +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> > +         * is allowed. The DOMCTL will return the actual version of the
> > +         * GIC.
> > +         */
> > +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> > +            return -EOPNOTSUPP;
> 
> EOPNOTSUPP doesn't seem quite right. EPARM  or EINVAL perhaps?
> 
> I'm also tempted to suggest that we should accept gic_version == the hw
> value, i.e. by moping the switch below up and including
>         && domctl->u.configuredomain.gic_version != gic_version
> in the condition.

I suggested to use -EOPNOTSUPP because one day we want to be able to use
this hypercall to choose a specific gic_version for the guest domain,
including gicv2 on gicv3 hardware for example.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:50:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:50:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyAu-0002rR-8f; Wed, 05 Nov 2014 10:50:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlyAt-0002rG-9i
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:50:51 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	7D/BD-25547-A010A545; Wed, 05 Nov 2014 10:50:50 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415184648!11771394!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17040 invoked from network); 5 Nov 2014 10:50:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:50:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189656812"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 05:50:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xlxs2-0002v8-SC;
	Wed, 05 Nov 2014 10:31:22 +0000
Date: Wed, 5 Nov 2014 10:31:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415183041.11486.74.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411051029370.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Ian Campbell wrote:
> > +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> > +         * is allowed. The DOMCTL will return the actual version of the
> > +         * GIC.
> > +         */
> > +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> > +            return -EOPNOTSUPP;
> 
> EOPNOTSUPP doesn't seem quite right. EPARM  or EINVAL perhaps?
> 
> I'm also tempted to suggest that we should accept gic_version == the hw
> value, i.e. by moping the switch below up and including
>         && domctl->u.configuredomain.gic_version != gic_version
> in the condition.

I suggested to use -EOPNOTSUPP because one day we want to be able to use
this hypercall to choose a specific gic_version for the guest domain,
including gicv2 on gicv3 hardware for example.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:53:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10: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 1XlyDW-0003Cd-Rq; Wed, 05 Nov 2014 10:53:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyDV-0003CU-UO
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:53:34 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	AC/4A-11608-CA10A545; Wed, 05 Nov 2014 10:53:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415184811!7331521!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31878 invoked from network); 5 Nov 2014 10:53:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:53:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188259504"
Message-ID: <1415184808.11486.82.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 5 Nov 2014 10:53:28 +0000
In-Reply-To: <545A000D.8070808@citrix.com>
References: <1415036346.1411.3.camel@citrix.com>
	<5457BF80.2000205@citrix.com> <5457C807.5080509@linaro.org>
	<20141104.161704.1690311989900127361.davem@davemloft.net>
	<1415137397.25370.7.camel@edumazet-glaptop2.roam.corp.google.com>
	<545A000D.8070808@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: zoltan.kiss@linaro.org, wei.liu2@citrix.com,
	Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org,
	xen-devel@lists.xenproject.org, malcolm.crossley@citrix.com,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 10:46 +0000, David Vrabel wrote:
> On 04/11/14 21:43, Eric Dumazet wrote:
> > On Tue, 2014-11-04 at 16:17 -0500, David Miller wrote:
> > 
> > 
> >>
> >> Every protocol demux starts with pskb_may_pull() to pull frag data
> >> into the linear area, if necessary, before looking at headers.
> > 
> > eth_get_headlen() might be relevant as well, to perform a single copy of
> > exactly all headers.
> 
> In netback's case we need an estimate of the header length before
> reading any of the packet, since peeking at any frag would prevent any
> TLB flush avoidance.
> 
> It might be useful to use eth_get_headlen() to adjust the estimate at
> runtime, but for now the fixed amount of 128 bytes is simple and seems
> good enough.

I think what Eric meant was that having done the 128 copy you could call
eth_get_headlen which in the common case should be a nop but would
ensure you always had the headers in the linear area for the uncommon
case.

It looks like the difference compared with skb_checksum_setup is that
eth_get_headlen deals with L4 too whereas skb_checksum_setup only goes
to L3 (and then only for some subset of protocols with checksums).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:53:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10: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 1XlyDW-0003Cd-Rq; Wed, 05 Nov 2014 10:53:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyDV-0003CU-UO
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:53:34 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	AC/4A-11608-CA10A545; Wed, 05 Nov 2014 10:53:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415184811!7331521!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31878 invoked from network); 5 Nov 2014 10:53:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:53:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188259504"
Message-ID: <1415184808.11486.82.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 5 Nov 2014 10:53:28 +0000
In-Reply-To: <545A000D.8070808@citrix.com>
References: <1415036346.1411.3.camel@citrix.com>
	<5457BF80.2000205@citrix.com> <5457C807.5080509@linaro.org>
	<20141104.161704.1690311989900127361.davem@davemloft.net>
	<1415137397.25370.7.camel@edumazet-glaptop2.roam.corp.google.com>
	<545A000D.8070808@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: zoltan.kiss@linaro.org, wei.liu2@citrix.com,
	Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org,
	xen-devel@lists.xenproject.org, malcolm.crossley@citrix.com,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 10:46 +0000, David Vrabel wrote:
> On 04/11/14 21:43, Eric Dumazet wrote:
> > On Tue, 2014-11-04 at 16:17 -0500, David Miller wrote:
> > 
> > 
> >>
> >> Every protocol demux starts with pskb_may_pull() to pull frag data
> >> into the linear area, if necessary, before looking at headers.
> > 
> > eth_get_headlen() might be relevant as well, to perform a single copy of
> > exactly all headers.
> 
> In netback's case we need an estimate of the header length before
> reading any of the packet, since peeking at any frag would prevent any
> TLB flush avoidance.
> 
> It might be useful to use eth_get_headlen() to adjust the estimate at
> runtime, but for now the fixed amount of 128 bytes is simple and seems
> good enough.

I think what Eric meant was that having done the 128 copy you could call
eth_get_headlen which in the common case should be a nop but would
ensure you always had the headers in the linear area for the uncommon
case.

It looks like the difference compared with skb_checksum_setup is that
eth_get_headlen deals with L4 too whereas skb_checksum_setup only goes
to L3 (and then only for some subset of protocols with checksums).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:56:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:56:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyGc-0003R5-J0; Wed, 05 Nov 2014 10:56:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyGb-0003Qx-84
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:56:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DF/2D-09842-C620A545; Wed, 05 Nov 2014 10:56:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415185002!4890651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19483 invoked from network); 5 Nov 2014 10:56:44 -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;
	5 Nov 2014 10:56:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188260050"
Message-ID: <1415184967.11486.84.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 5 Nov 2014 10:56:07 +0000
In-Reply-To: <alpine.DEB.2.02.1411051029370.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com>
	<alpine.DEB.2.02.1411051029370.22875@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 10:31 +0000, Stefano Stabellini wrote:
> On Wed, 5 Nov 2014, Ian Campbell wrote:
> > > +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> > > +         * is allowed. The DOMCTL will return the actual version of the
> > > +         * GIC.
> > > +         */
> > > +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> > > +            return -EOPNOTSUPP;
> > 
> > EOPNOTSUPP doesn't seem quite right. EPARM  or EINVAL perhaps?
> > 
> > I'm also tempted to suggest that we should accept gic_version == the hw
> > value, i.e. by moping the switch below up and including
> >         && domctl->u.configuredomain.gic_version != gic_version
> > in the condition.
> 
> I suggested to use -EOPNOTSUPP because one day we want to be able to use
> this hypercall to choose a specific gic_version for the guest domain,
> including gicv2 on gicv3 hardware for example.

Why is EOPNOTSUPP an appropriate error code for that 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 Nov 05 10:56:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:56:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyGc-0003R5-J0; Wed, 05 Nov 2014 10:56:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyGb-0003Qx-84
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:56:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DF/2D-09842-C620A545; Wed, 05 Nov 2014 10:56:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415185002!4890651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19483 invoked from network); 5 Nov 2014 10:56:44 -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;
	5 Nov 2014 10:56:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188260050"
Message-ID: <1415184967.11486.84.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 5 Nov 2014 10:56:07 +0000
In-Reply-To: <alpine.DEB.2.02.1411051029370.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com>
	<alpine.DEB.2.02.1411051029370.22875@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 10:31 +0000, Stefano Stabellini wrote:
> On Wed, 5 Nov 2014, Ian Campbell wrote:
> > > +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> > > +         * is allowed. The DOMCTL will return the actual version of the
> > > +         * GIC.
> > > +         */
> > > +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> > > +            return -EOPNOTSUPP;
> > 
> > EOPNOTSUPP doesn't seem quite right. EPARM  or EINVAL perhaps?
> > 
> > I'm also tempted to suggest that we should accept gic_version == the hw
> > value, i.e. by moping the switch below up and including
> >         && domctl->u.configuredomain.gic_version != gic_version
> > in the condition.
> 
> I suggested to use -EOPNOTSUPP because one day we want to be able to use
> this hypercall to choose a specific gic_version for the guest domain,
> including gicv2 on gicv3 hardware for example.

Why is EOPNOTSUPP an appropriate error code for that 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 Nov 05 10:57:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyHd-0003W5-2C; Wed, 05 Nov 2014 10:57:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyHb-0003Vv-4V
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:57:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	7D/1C-09936-AA20A545; Wed, 05 Nov 2014 10:57:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415185064!12855309!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21690 invoked from network); 5 Nov 2014 10:57:45 -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;
	5 Nov 2014 10:57:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188260513"
Message-ID: <1415185062.11486.85.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 5 Nov 2014 10:57:42 +0000
In-Reply-To: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: netdev@vger.kernel.org, Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> 
> Unconditionally pulling 128 bytes into the linear area is not required
> for:
> 
> - security: Every protocol demux starts with pskb_may_pull() to pull
>   frag data into the linear area, if necessary, before looking at
>   headers.
> 
> - performance: Netback has already grant copied up-to 128 bytes from
>   the first slot of a packet into the linear area. The first slot
>   normally contain all the IPv4/IPv6 and TCP/UDP headers.

Thanks for adding these.

> The unconditional pull would often copy frag data unnecessarily.  This
> is a performance problem when running on a version of Xen where grant
> unmap avoids TLB flushes for pages which are not accessed.  TLB
> flushes can now be avoided for > 99% of unmaps (it was 0% before).
> 
> Grant unmap TLB flush avoidance will be available in a future version
> of Xen (probably 4.6).
> 
> Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:57:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyHd-0003W5-2C; Wed, 05 Nov 2014 10:57:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyHb-0003Vv-4V
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:57:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	7D/1C-09936-AA20A545; Wed, 05 Nov 2014 10:57:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415185064!12855309!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21690 invoked from network); 5 Nov 2014 10:57:45 -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;
	5 Nov 2014 10:57:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188260513"
Message-ID: <1415185062.11486.85.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 5 Nov 2014 10:57:42 +0000
In-Reply-To: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: netdev@vger.kernel.org, Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> 
> Unconditionally pulling 128 bytes into the linear area is not required
> for:
> 
> - security: Every protocol demux starts with pskb_may_pull() to pull
>   frag data into the linear area, if necessary, before looking at
>   headers.
> 
> - performance: Netback has already grant copied up-to 128 bytes from
>   the first slot of a packet into the linear area. The first slot
>   normally contain all the IPv4/IPv6 and TCP/UDP headers.

Thanks for adding these.

> The unconditional pull would often copy frag data unnecessarily.  This
> is a performance problem when running on a version of Xen where grant
> unmap avoids TLB flushes for pages which are not accessed.  TLB
> flushes can now be avoided for > 99% of unmaps (it was 0% before).
> 
> Grant unmap TLB flush avoidance will be available in a future version
> of Xen (probably 4.6).
> 
> Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:59:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:59:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyIq-0003cw-H0; Wed, 05 Nov 2014 10:59:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyIp-0003cn-6b
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:59:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6D/1F-09936-6F20A545; Wed, 05 Nov 2014 10:59:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415185140!12946995!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7503 invoked from network); 5 Nov 2014 10:59:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:59:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188260788"
Message-ID: <1415185138.11486.87.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 5 Nov 2014 10:58:58 +0000
In-Reply-To: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Malcolm
	Crossley <malcolm.crossley@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dropping netdev since this isn't relevant to them, adding Paul

On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> - performance: Netback has already grant copied up-to 128 bytes from
>   the first slot of a packet into the linear area. The first slot
>   normally contain all the IPv4/IPv6 and TCP/UDP headers.

Does "normally" here include guests other than Linux? I thought Windows
in particular was prone to splitting the headers into a frag per layer
or thereabouts?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 10:59:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 10:59:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyIq-0003cw-H0; Wed, 05 Nov 2014 10:59:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyIp-0003cn-6b
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 10:59:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6D/1F-09936-6F20A545; Wed, 05 Nov 2014 10:59:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415185140!12946995!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7503 invoked from network); 5 Nov 2014 10:59:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 10:59:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188260788"
Message-ID: <1415185138.11486.87.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 5 Nov 2014 10:58:58 +0000
In-Reply-To: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Malcolm
	Crossley <malcolm.crossley@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dropping netdev since this isn't relevant to them, adding Paul

On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> - performance: Netback has already grant copied up-to 128 bytes from
>   the first slot of a packet into the linear area. The first slot
>   normally contain all the IPv4/IPv6 and TCP/UDP headers.

Does "normally" here include guests other than Linux? I thought Windows
in particular was prone to splitting the headers into a frag per layer
or thereabouts?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:00:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11: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 1XlyK2-0003m6-U3; Wed, 05 Nov 2014 11:00:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyK0-0003lm-L0
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 11:00:16 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	CD/E9-22819-F330A545; Wed, 05 Nov 2014 11:00:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415185213!11343608!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29134 invoked from network); 5 Nov 2014 11:00:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:00:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189658683"
Message-ID: <1415185193.15317.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 5 Nov 2014 10:59:53 +0000
In-Reply-To: <20141104172006.GL4510@laptop.dumpdata.com>
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
	<1415096249.11486.12.camel@citrix.com>
	<alpine.DEB.2.02.1411041019300.22875@kaball.uk.xensource.com>
	<5458CB0F.7000600@linaro.org>
	<20141104172006.GL4510@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: tim@xen.org, Julien Grall <julien.grall@linaro.org>,
	xen-devel@lists.xen.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 12:20 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 04, 2014 at 12:48:15PM +0000, Julien Grall wrote:
> > On 11/04/2014 10:20 AM, Stefano Stabellini wrote:
> > > On Tue, 4 Nov 2014, Ian Campbell wrote:
> > >> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
> > >>
> > >> I think we should apply this workaround for 4.5 and do things properly
> > >> for 4.6. Any thoughts?
> > >  
> > > I agree with you
> > 
> > +1
> 
> 
> /me unrolls the first-bandaid and puts it on Xen and signs it with:
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks, applied!

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:00:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11: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 1XlyK1-0003lt-Bj; Wed, 05 Nov 2014 11:00:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyJz-0003lg-S9
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 11:00:15 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	87/35-11581-F330A545; Wed, 05 Nov 2014 11:00:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415185213!11343608!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28973 invoked from network); 5 Nov 2014 11:00:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:00:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189658659"
Message-ID: <1415185188.15317.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 5 Nov 2014 10:59:48 +0000
In-Reply-To: <20141104171022.GI4510@laptop.dumpdata.com>
References: <5450DC800200000200017669@gwsmtp1.uni-regensburg.de>
	<1415095735.11486.7.camel@citrix.com>
	<20141104171022.GI4510@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xentop: Dynamically expand some columns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 12:10 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 04, 2014 at 10:08:55AM +0000, Ian Campbell wrote:
> > On Wed, 2014-10-29 at 12:24 +0100, Markus Hauschild wrote:
> > > Allow certain xentop columns to automatically expand as the amount
> > > of data reported gets larger.  The columns allowed to auto expand are:
> > > 
> > > NETTX(k), NETRX(k), VBD_RD, VBD_WR, VBD_RSECT, VBD_WSECT
> > > 
> > > If the -f option is used to allow full length VM names, those names will
> > > also be aligned based on the longest name in the NAME column.
> > > 
> > > The default minimum width of all columns remains unchanged.
> > > 
> > > Signed-off-by: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>
> > > Signed-off-by: Charles Arnold <carnold@suse.com>
> > 
> > Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
> > 
> > Konrad, I think you were previously intending this to go in for 4.5, is
> > that still the case?
> 
> Correct.

Applied.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:00:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11: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 1XlyK1-0003lt-Bj; Wed, 05 Nov 2014 11:00:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyJz-0003lg-S9
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 11:00:15 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	87/35-11581-F330A545; Wed, 05 Nov 2014 11:00:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415185213!11343608!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28973 invoked from network); 5 Nov 2014 11:00:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:00:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189658659"
Message-ID: <1415185188.15317.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 5 Nov 2014 10:59:48 +0000
In-Reply-To: <20141104171022.GI4510@laptop.dumpdata.com>
References: <5450DC800200000200017669@gwsmtp1.uni-regensburg.de>
	<1415095735.11486.7.camel@citrix.com>
	<20141104171022.GI4510@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xentop: Dynamically expand some columns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 12:10 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 04, 2014 at 10:08:55AM +0000, Ian Campbell wrote:
> > On Wed, 2014-10-29 at 12:24 +0100, Markus Hauschild wrote:
> > > Allow certain xentop columns to automatically expand as the amount
> > > of data reported gets larger.  The columns allowed to auto expand are:
> > > 
> > > NETTX(k), NETRX(k), VBD_RD, VBD_WR, VBD_RSECT, VBD_WSECT
> > > 
> > > If the -f option is used to allow full length VM names, those names will
> > > also be aligned based on the longest name in the NAME column.
> > > 
> > > The default minimum width of all columns remains unchanged.
> > > 
> > > Signed-off-by: Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>
> > > Signed-off-by: Charles Arnold <carnold@suse.com>
> > 
> > Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
> > 
> > Konrad, I think you were previously intending this to go in for 4.5, is
> > that still the case?
> 
> Correct.

Applied.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:00:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11: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 1XlyK2-0003m6-U3; Wed, 05 Nov 2014 11:00:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyK0-0003lm-L0
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 11:00:16 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	CD/E9-22819-F330A545; Wed, 05 Nov 2014 11:00:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415185213!11343608!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29134 invoked from network); 5 Nov 2014 11:00:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:00:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189658683"
Message-ID: <1415185193.15317.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 5 Nov 2014 10:59:53 +0000
In-Reply-To: <20141104172006.GL4510@laptop.dumpdata.com>
References: <1410448889-18731-1-git-send-email-ian.campbell@citrix.com>
	<1415096249.11486.12.camel@citrix.com>
	<alpine.DEB.2.02.1411041019300.22875@kaball.uk.xensource.com>
	<5458CB0F.7000600@linaro.org>
	<20141104172006.GL4510@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: tim@xen.org, Julien Grall <julien.grall@linaro.org>,
	xen-devel@lists.xen.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: arm: configure correct
	dom0_gnttab_start/size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-04 at 12:20 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 04, 2014 at 12:48:15PM +0000, Julien Grall wrote:
> > On 11/04/2014 10:20 AM, Stefano Stabellini wrote:
> > > On Tue, 4 Nov 2014, Ian Campbell wrote:
> > >> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
> > >>
> > >> I think we should apply this workaround for 4.5 and do things properly
> > >> for 4.6. Any thoughts?
> > >  
> > > I agree with you
> > 
> > +1
> 
> 
> /me unrolls the first-bandaid and puts it on Xen and signs it with:
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks, applied!

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:01:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:01:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyLM-0003z9-TD; Wed, 05 Nov 2014 11:01:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlyLL-0003yr-7O
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 11:01:39 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	BE/EF-24859-2930A545; Wed, 05 Nov 2014 11:01:38 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415185296!11714597!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1137 invoked from network); 5 Nov 2014 11:01:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:01:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189659243"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 06:01:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlyLF-0004uG-FQ;
	Wed, 05 Nov 2014 11:01:33 +0000
Date: Wed, 5 Nov 2014 11:01:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Quan" <quan.xu@intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411051036310.22875@kaball.uk.xensource.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Monday, November 03, 2014 7:54 PM
> > To: Xu, Quan
> > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > stefano.stabellini@eu.citrix.com
> > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > frontend driver
> > 
> > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > This drvier transfers any request/repond between TPM xenstubdoms
> > > driver and Xen vTPM stubdom, and facilitates communications between
> > > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > >
> > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > 
> > Please describe what changes did make to xen_backend.c and why.
> > The commit message should contains info on all the changes made by the
> > patch below.
> > 
> 	
> Thanks Stefano. 
> one more day, I will explain in detail what changes did make to xen_backend.c 
> and why. 
> The following 2 sections are introduction and architecture. 
> 
> > Please also describe what is the "Xen vTPM stubdom", what is the
> > "vTPM xenstubdoms driver" and how the communicate with each others.
> > 
> 
> 
> Add 2 parts for detailed descriptions, introduction and architecture.  
> 
> *INTRODUCTION*
> 
> The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality
> to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to
> interact with a TPM in a virtual machine the same way they interact with a TPM on the
> physical system. Each virtual machine gets its own unique, emulated, software TPM.
> Each major component of vTPM is implemented as a stubdom, providing secure separation
> guaranteed by the hypervisor.
> The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine
> to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed
> from mini-os TPM backend driver.
> This patch series are only the Qemu part to enable Xen stubdom vTPM for HVM virtual
> machine.
> ===========
> 
> *ARCHITECTURE*
> 
> The architecture of stubdom vTPM for HVM virtual machine:
> 
>             +--------------------+
>             | Windows/Linux DomU | ...
>             |        |  ^        |
>             |        v  |        |
>             |  Qemu tpm1.2 Tis   |
>             |        |  ^        |
>             |        v  |        |
>             |        vTPM        |
>             | XenStubdoms driver |  (new ..)
>             +--------------------+
>                      |  ^
>                      v  |
>             +--------------------+
>             |  xen_vtpmdev_ops   |  (new ..)
>             +--------------------+
>                      |  ^
>                      v  |
>             +--------------------+
>             |  mini-os/tpmback   |
>             |        |  ^        |
>             |        v  |        |
>             |   vTPM stubdom     | ...
>             |        |  ^        |
>             |        v  |        |
>             |  mini-os/tpmfront  |
>             +--------------------+
>                      |  ^
>                      v  |
>             +--------------------+
>             |  mini-os/tpmback   |
>             |        |  ^        |
>             |        v  |        |
>             |  vtpmmgr stubdom   |
>             |        |  ^        |
>             |        v  |        |
>             |  mini-os/tpm_tis   |
>             +--------------------+
>                      |  ^
>                      v  |
>             +--------------------+
>             |    Hardware TPM    |
>             +--------------------+
> 
> 
> * Windows/Linux DomU:
>     The HVM based guest that wants to use a vTPM. There may be
>     more than one of these.
> 
>  * Qemu tpm1.2 Tis:
>     Implementation of the tpm1.2 Tis interface for HVM virtual
>     machines. It is Qemu emulation device.

It looks like you are running upstream QEMU within a Mini-OS stubdom?
If so, where are the patches to do that? As far as I know upstream QEMU
doesn't run on Mini-OS. Or maybe it is a Linux stubdom? Either way, it
is not clear.


>  * vTPM xenstubdoms driver:
>     Similar to a TPM passthrough backend driver, it is a new TPM
>     backend for emulated TPM TIS interface. This driver provides
>     vTPM initialization and sending data and commends to a Xen
>     vTPM stubdom.

This is patch #3, right? It is basically the internal QEMU "glue" to
connect the tpm emulator to xen_vtpmdev_ops, correct?


>  * xen_vtpmdev_ops:
>     Register Xen stubdom vTPM backend, and transfer any request/
>     repond between TPM xenstubdoms driver and Xen vTPM stubdom.
>     Facilitate communications between Xen vTPM stubdom and vTPM
>     xenstubdoms driver.
 
It looks like this correspond to patch #2? If so, this is a regular Xen
PV frontend, living in QEMU? It requires the gntalloc device so I guess
it is supposed to run on Linux. In that case is it just a tpmfront
implementation in QEMU?

If you are running it on Linux, we might need to introduce Linux based
stundoms to the Xen build system.


>  * mini-os/tpmback:
>     Mini-os TPM backend driver. The Linux frontend driver connects
>     to this backend driver to facilitate communications between the
>     Linux DomU and its vTPM. This driver is also used by vtpmmgr
>     stubdom to communicate with vTPM stubdom.
> 
>  * vTPM stubdom:
>     A mini-os stub domain that implements a vTPM. There is a
>     one to one mapping between running vTPM stubdom instances and
>     logical vTPMs on the system. The vTPM Platform Configuration
>     Registers (PCRs) are all initialized to zero.
>
>  * mini-os/tpmfront:
>     Mini-os TPM frontend driver. The vTPM mini-os domain vTPM
>     stubdom uses this driver to communicate with vtpmmgr-stubdom.
>     This driver could also be used separately to implement a mini-os
>     domain that wishes to use a vTPM of its own.
>
>  * vtpmmgr stubdom:
>     A mini-os domain that implements the vTPM manager. There is only
>     one vTPM manager and it should be running during the entire lifetime
>     of the machine. vtpmmgr domain securely stores encryption keys for
>     each of the vTPMs and accesses to the hardware TPM to get the root of
>     trust for the entire system.
> 
>  * mini-os/tpm_tis:
>     Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
>     This driver used by vtpmmgr-stubdom to talk directly to the hardware
>     TPM. Communication is facilitated by mapping hardware memory pages
>     into vtpmmgr stubdom.
 
Are all the Mini-OS component upstream, or do we need patches?


>  * Hardware TPM:
>     The physical TPM 1.2 that is soldered onto the motherboard.
> 
> ===========
> 
> 
> 
> > Where does the vTPM backend lives?
> The vTPM backend lives in Xen vTPM stubdom (Xen Mini-os)

Thanks for the explanation, it is a bit clearer now.


> > 
> > 
> > >  hw/xen/Makefile.objs         |   1 +
> > >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> > >  hw/xen/xen_stubdom_vtpm.c    | 333
> > +++++++++++++++++++++++++++++++++++++++++++
> > >  include/hw/xen/xen_backend.h |  11 ++
> > >  include/hw/xen/xen_common.h  |   6 +
> > >  xen-hvm.c                    |  13 ++
> > >  6 files changed, 544 insertions(+), 2 deletions(-)
> > >  create mode 100644 hw/xen/xen_stubdom_vtpm.c
> > >
> > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> > > index a0ca0aa..724df8d 100644
> > > --- a/hw/xen/Makefile.objs
> > > +++ b/hw/xen/Makefile.objs
> > > @@ -1,5 +1,6 @@
> > >  # xen backend driver support
> > >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> > xen_devconfig.o
> > > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> > >
> > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> > xen_pt_config_init.o xen_pt_msi.o
> > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> > > index b2cb22b..45a5778 100644
> > > --- a/hw/xen/xen_backend.c
> > > +++ b/hw/xen/xen_backend.c
> > > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev,
> > enum xenbus_state state)
> > >      return 0;
> > >  }
> > >
> > > +/*get stubdom backend*/
> > > +static char *xen_stubdom_be(const char *type, int dom, int dev)
> > > +{
> > > +    char *val, *domu;
> > > +    char path[XEN_BUFSIZE];
> > > +    unsigned int len, ival;
> > > +
> > > +    /*front domu*/
> > > +    domu = xs_get_domain_path(xenstore, dom);
> > > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > > +             domu, type, dev);
> > > +    g_free(domu);
> > > +
> > > +    val = xs_read(xenstore, 0, path, &len);
> > > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > > +        g_free(val);
> > > +        return NULL;
> > > +    }
> > > +    g_free(val);
> > > +
> > > +    /*backend domu*/
> > > +    domu = xs_get_domain_path(xenstore, ival);
> > > +
> > > +    return domu;
> > > +}
> > > +
> > >  /* ------------------------------------------------------------- */
> > >
> > >  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int
> > dev)
> > > @@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const
> > char *type, int dom, int dev,
> > >                                             struct XenDevOps *ops)
> > >  {
> > >      struct XenDevice *xendev;
> > > +    char *stub;
> > >
> > >      xendev = xen_be_find_xendev(type, dom, dev);
> > >      if (xendev) {
> > > @@ -235,8 +262,15 @@ static struct XenDevice
> > *xen_be_get_xendev(const char *type, int dom, int dev,
> > >      xendev->dev   = dev;
> > >      xendev->ops   = ops;
> > >
> > > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > > -             xendev->type, xendev->dom, xendev->dev);
> > > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> > xendev->dev);
> > > +        snprintf(xendev->be, sizeof(xendev->be),
> > "%s/backend/%s/%d/%d",
> > > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > > +        g_free(stub);
> > > +    } else {
> > > +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > > +                 xendev->type, xendev->dom, xendev->dev);
> > > +    }
> > >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> > >               xendev->type, xendev->dev);
> > >
> > > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int
> > dom, struct XenDevOps *ops)
> > >      return 0;
> > >  }
> > >
> > > +static void stubdom_update_be(char *watch, char *type, int dom,
> > > +                              struct XenDevOps *ops)
> > > +{
> > > +    struct XenDevice *xendev;
> > > +    char path[XEN_BUFSIZE];
> > > +    char *ptr, *bepath;
> > > +    unsigned int len, dev;
> > > +
> > > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > > +        return;
> > > +    }
> > > +
> > > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > > +    ptr = strstr(watch, path);
> > > +    if (ptr == NULL) {
> > > +        return;
> > > +    }
> > > +
> > > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > > +        strcpy(path, "");
> > > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > > +            dev = -1;
> > > +        }
> > > +    }
> > > +
> > > +    if (dev == -1) {
> > > +        return;
> > > +    }
> > > +
> > > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > > +    if (xendev != NULL) {
> > > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > > +        if (bepath == NULL) {
> > > +            xen_be_del_xendev(dom, dev);
> > > +        } else {
> > > +            free(bepath);
> > > +            xen_be_backend_changed(xendev, path);
> > > +        }
> > > +    }
> > > +}
> > > +
> > >  static void xenstore_update_be(char *watch, char *type, int dom,
> > >                                 struct XenDevOps *ops)
> > >  {
> > > @@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
> > >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> > >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> > >      }
> > > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> > PRIxPTR,
> > > +               &type, &dom, &ops) == 3) {
> > > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom,
> > (void *)ops);
> > > +    }
> > >
> > >  cleanup:
> > >      free(vec);
> > > @@ -732,11 +811,74 @@ err:
> > >      return -1;
> > >  }
> > >
> > > +int xen_vtpm_register(struct XenDevOps *ops)
> > > +{
> > > +    struct XenDevice *xendev;
> > > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > > +    char *domu;
> > > +    unsigned int cdev, j, rc;
> > > +    const char *type = "vtpm";
> > > +    char **dev = NULL;
> > > +
> > > +    /*front domu*/
> > > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > > +    snprintf(path, sizeof(path), "%s/device/%s",
> > > +             domu, type);
> > > +    free(domu);
> > > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > > +    if (dev == NULL) {
> > > +        return 0;
> > > +    }
> > > +
> > > +    for (j = 0; j < cdev; j++) {
> > > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> > ops);
> > > +        if (xendev == NULL) {
> > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> > NULL.\n");
> > > +            continue;
> > > +        }
> > > +
> > > +        if (xendev->ops->initialise) {
> > > +            rc = xendev->ops->initialise(xendev);
> > > +
> > > +            /*if initialise failed, delete it*/
> > > +            if (rc != 0) {
> > > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > > +                continue;
> > > +            }
> > > +        }
> > > +
> > > +        /*setup watch*/
> > > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > > +                 type, xen_domid, xendev->ops);
> > > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> > failed.\n");
> > > +            return -1;
> > > +        }
> > > +    }
> > > +
> > > +    free(dev);
> > > +    return 0;
> > > +}
> > 
> > What does this function do? I sholdn't need  to guess from the code, I
> > should be able to tell from the patch description.
> > 
> > 
> > >  int xen_be_register(const char *type, struct XenDevOps *ops)
> > >  {
> > >      return xenstore_scan(type, xen_domid, ops);
> > >  }
> > >
> > > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > remote_dom)
> > > +{
> > > +    xendev->local_port =
> > xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > > +
> > remote_dom);
> > > +    if (xendev->local_port == -1) {
> > > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> > > +        return -1;
> > > +    }
> > > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> > xendev->local_port);
> > > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > > +                        xen_be_evtchn_event, NULL, xendev);
> > > +    return 0;
> > > +}
> > > +
> > >  int xen_be_bind_evtchn(struct XenDevice *xendev)
> > >  {
> > >      if (xendev->local_port != -1) {
> > > @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice
> > *xendev)
> > >      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
> > >  }
> > >
> > > +int xen_vtpm_send(unsigned char *buf, size_t count)
> > > +{
> > > +    struct XenDevice *xendev;
> > > +    int rc = -1;
> > > +
> > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > +    if (xendev == NULL) {
> > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > +        return -1;
> > > +    }
> > > +
> > > +    if (xendev->ops->send) {
> > > +        rc = xendev->ops->send(xendev, buf, count);
> > > +    }
> > > +
> > > +    return rc;
> > > +}
> > > +
> > > +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> > > +{
> > > +    struct XenDevice *xendev;
> > > +    int rc = -1;
> > > +
> > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > +    if (xendev == NULL) {
> > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > +        return -1;
> > > +    }
> > > +
> > > +    if (xendev->ops->recv) {
> > > +        xendev->ops->recv(xendev, buf, count);
> > > +    }
> > > +
> > > +    return rc;
> > > +}
> > 
> > xen_backend.c is supposed to be generic, so stubdom functions might be
> > OK but vtpm specific functions should not be here.
> > 
> > 
> > >  /*
> > >   * msg_level:
> > >   *  0 == errors (stderr + logfile).
> > > diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> > > new file mode 100644
> > > index 0000000..0d740c1
> > > --- /dev/null
> > > +++ b/hw/xen/xen_stubdom_vtpm.c
> > > @@ -0,0 +1,333 @@
> > > +/*
> > > + * Connect to Xen vTPM stubdom domain
> > > + *
> > > + *  Copyright (c) 2014 Intel Corporation
> > > + *  Authors:
> > > + *    Quan Xu <quan.xu@intel.com>
> > > + *
> > > + * 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 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, see
> > <http://www.gnu.org/licenses/>
> > > + */
> > > +
> > > +#include <stdio.h>
> > > +#include <stdlib.h>
> > > +#include <stdarg.h>
> > > +#include <string.h>
> > > +#include <unistd.h>
> > > +#include <signal.h>
> > > +#include <inttypes.h>
> > > +#include <time.h>
> > > +#include <fcntl.h>
> > > +#include <errno.h>
> > > +#include <sys/ioctl.h>
> > > +#include <sys/types.h>
> > > +#include <sys/stat.h>
> > > +#include <sys/mman.h>
> > > +#include <sys/uio.h>
> > > +
> > > +#include "hw/hw.h"
> > > +#include "block/aio.h"
> > > +#include "hw/xen/xen_backend.h"
> > > +
> > > +enum tpmif_state {
> > > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> > complete */
> > > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> > > +};
> > > +
> > > +static AioContext *vtpm_aio_ctx;
> > > +
> > > +enum status_bits {
> > > +    VTPM_STATUS_RUNNING  = 0x1,
> > > +    VTPM_STATUS_IDLE     = 0x2,
> > > +    VTPM_STATUS_RESULT   = 0x4,
> > > +    VTPM_STATUS_CANCELED = 0x8,
> > > +};
> > > +
> > > +struct tpmif_shared_page {
> > > +    uint32_t length;         /* request/response length in bytes */
> > > +
> > > +    uint8_t  state;           /* enum tpmif_state */
> > > +    uint8_t  locality;        /* for the current request */
> > > +    uint8_t  pad;             /* should be zero */
> > > +
> > > +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be
> > zero */
> > > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> > nr_extra_pages */
> > > +};
> > > +
> > > +struct QEMUBH {
> > > +    AioContext *ctx;
> > > +    QEMUBHFunc *cb;
> > > +    void *opaque;
> > > +    QEMUBH *next;
> > > +    bool scheduled;
> > > +    bool idle;
> > > +    bool deleted;
> > > +};
> > > +
> > > +struct XenVtpmDev {
> > > +    struct XenDevice xendev;  /* must be first */
> > > +    struct           tpmif_shared_page *shr;
> > > +    xc_gntshr        *xen_xcs;
> > > +    int              ring_ref;
> > > +    int              bedomid;
> > > +    QEMUBH           *sr_bh;
> > > +};
> > > +
> > > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> > > +{
> > > +    switch (vtpmdev->shr->state) {
> > > +    case TPMIF_STATE_IDLE:
> > > +    case TPMIF_STATE_FINISH:
> > > +        return VTPM_STATUS_IDLE;
> > > +    case TPMIF_STATE_SUBMIT:
> > > +    case TPMIF_STATE_CANCEL:
> > > +        return VTPM_STATUS_RUNNING;
> > > +    default:
> > > +        return 0;
> > > +    }
> > > +}
> > > +
> > > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> > xenbus_state xbus)
> > > +{
> > > +    xs_transaction_t xbt = XBT_NULL;
> > > +
> > > +    if (xendev->fe_state == xbus) {
> > > +        return 0;
> > > +    }
> > > +
> > > +    xendev->fe_state = xbus;
> > > +
> > > +retry_transaction:
> > > +    xbt = xs_transaction_start(xenstore);
> > > +    if (xbt == XBT_NULL) {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > +        if (errno == EAGAIN) {
> > > +            goto retry_transaction;
> > > +        }
> > > +    }
> > > +
> > > +    return 0;
> > > +
> > > +abort_transaction:
> > > +    xs_transaction_end(xenstore, xbt, 1);
> > > +    return -1;
> > > +}
> > > +
> > > +static int vtpm_aio_wait(QEMUBH *qbh)
> > > +{
> > > +    return aio_poll(qbh->ctx, true);
> > > +}
> > > +
> > > +static void sr_bh_handler(void *opaque)
> > > +{
> > > +}
> > > +
> > > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t
> > *count)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > +    unsigned int offset;
> > > +
> > > +    if (shr->state == TPMIF_STATE_IDLE) {
> > > +        return -ECANCELED;
> > > +    }
> > > +
> > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > +    }
> > > +
> > > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > > +    *count = shr->length;
> > > +
> > > +    return 0;
> > > +}
> > > +
> > > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t
> > count)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > +
> > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > +    }
> > > +
> > > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > > +    shr->length = count;
> > > +    barrier();
> > > +    shr->state = TPMIF_STATE_SUBMIT;
> > > +    xen_wmb();
> > > +    xen_be_send_notify(&vtpmdev->xendev);
> > > +
> > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > +    }
> > > +
> > > +    return count;
> > > +}
> > > +
> > > +static int vtpm_initialise(struct XenDevice *xendev)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +    xs_transaction_t xbt = XBT_NULL;
> > > +    unsigned int ring_ref;
> > > +
> > > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> > "frontend");
> > > +    if (vtpmdev->xendev.fe == NULL) {
> > > +        return -1;
> > > +    }
> > > +
> > > +    /* Get backend domid */
> > > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > > +                             &vtpmdev->bedomid)) {
> > > +        return -1;
> > > +    }
> > > +
> > > +    /*alloc share page*/
> > > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> > vtpmdev->bedomid, 1,
> > > +                                         &ring_ref,
> > PROT_READ|PROT_WRITE);
> > > +    vtpmdev->ring_ref = ring_ref;
> > > +    if (vtpmdev->shr == NULL) {
> > > +        return -1;
> > > +    }
> > > +
> > > +    /*Create event channel */
> > > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> > vtpmdev->bedomid)) {
> > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > +        return -1;
> > > +    }
> > > +
> > > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > > +                     vtpmdev->xendev.local_port);
> > > +
> > > +again:
> > > +    xbt = xs_transaction_start(xenstore);
> > > +    if (xbt == XBT_NULL) {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > > +                           vtpmdev->ring_ref)) {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > > +                           vtpmdev->xendev.local_port)) {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    /* Publish protocol v2 feature */
> > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1))
> > {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > +        if (errno == EAGAIN) {
> > > +            goto again;
> > > +        }
> > > +    }
> > > +    /* Tell vtpm backend that we are ready */
> > > +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> > > +
> > > +    return 0;
> > > +
> > > +abort_transaction:
> > > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > +    xs_transaction_end(xenstore, xbt, 1);
> > > +    return -1;
> > > +}
> > > +
> > > +static void vtpm_backend_changed(struct XenDevice *xendev, const char
> > *node)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +    int be_state;
> > > +
> > > +    if (strcmp(node, "state") == 0) {
> > > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > > +        switch (be_state) {
> > > +        case XenbusStateConnected:
> > > +            /*TODO*/
> > > +            break;
> > > +        case XenbusStateClosing:
> > > +        case XenbusStateClosed:
> > > +            xenbus_switch_state(&vtpmdev->xendev,
> > XenbusStateClosing);
> > > +            break;
> > > +        default:
> > > +            break;
> > > +        }
> > > +    }
> > > +}
> > > +
> > > +static int vtpm_free(struct XenDevice *xendev)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > > +
> > > +    aio_poll(qbh->ctx, false);
> > > +    qemu_bh_delete(vtpmdev->sr_bh);
> > > +    if (vtpmdev->shr) {
> > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > +    }
> > > +    xc_interface_close(vtpmdev->xen_xcs);
> > > +    return 0;
> > > +}
> > > +
> > > +static void vtpm_alloc(struct XenDevice *xendev)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +
> > > +    vtpm_aio_ctx = aio_context_new(NULL);
> > > +    if (vtpm_aio_ctx == NULL) {
> > > +        return;
> > > +    }
> > > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> > vtpmdev);
> > > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> > > +}
> > > +
> > > +static void vtpm_event(struct XenDevice *xendev)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +
> > > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > > +}
> > > +
> > > +struct XenDevOps xen_vtpmdev_ops = {
> > > +    .size             = sizeof(struct XenVtpmDev),
> > > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > > +                        DEVOPS_FLAG_STUBDOM_BE,
> > > +    .event            = vtpm_event,
> > > +    .free             = vtpm_free,
> > > +    .alloc            = vtpm_alloc,
> > > +    .initialise       = vtpm_initialise,
> > > +    .backend_changed  = vtpm_backend_changed,
> > > +    .recv             = vtpm_recv,
> > > +    .send             = vtpm_send,
> > > +};
> > 
> > Is this the frontend, like the subject line would seem to imply?
> > If so, XenDevOps are made for backends, while this is a frontend. In
> > fact this is the first PV frontend in QEMU. We need to introduce
> > something generic and similar to struct XenDevOps and xen_backend.c but
> > for frontends.
> > 
> > 
> > > diff --git a/include/hw/xen/xen_backend.h
> > b/include/hw/xen/xen_backend.h
> > > index 3b4125e..45fd6d3 100644
> > > --- a/include/hw/xen/xen_backend.h
> > > +++ b/include/hw/xen/xen_backend.h
> > > @@ -15,6 +15,8 @@ struct XenDevice;
> > >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> > >  /* don't expect frontend doing correct state transitions (aka console
> > quirk) */
> > >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > > +/*dev backend is stubdom*/
> > > +#define DEVOPS_FLAG_STUBDOM_BE    4
> > >
> > >  struct XenDevOps {
> > >      size_t    size;
> > > @@ -26,6 +28,8 @@ struct XenDevOps {
> > >      void      (*event)(struct XenDevice *xendev);
> > >      void      (*disconnect)(struct XenDevice *xendev);
> > >      int       (*free)(struct XenDevice *xendev);
> > > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> > count);
> > > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> > *count);
> > >      void      (*backend_changed)(struct XenDevice *xendev, const
> > char *node);
> > >      void      (*frontend_changed)(struct XenDevice *xendev, const
> > char *node);
> > >  };
> > > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> > *xendev);
> > >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char
> > *fmt, ...)
> > >      GCC_FMT_ATTR(3, 4);
> > >
> > > +/*Xen stubdom vtpm*/
> > > +int xen_vtpm_register(struct XenDevOps *ops);
> > > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > remote_dom);
> > > +int xen_vtpm_send(unsigned char *buf, size_t count);
> > > +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> > > +
> > >  /* actual backend drivers */
> > >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> > */
> > >  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c
> > */
> > >  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
> > >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> > */
> > >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> > */
> > > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> > xen_stubdom_vtpm.c*/
> > >
> > >  void xen_init_display(int domid);
> > >
> > > diff --git a/include/hw/xen/xen_common.h
> > b/include/hw/xen/xen_common.h
> > > index 95612a4..fb43084 100644
> > > --- a/include/hw/xen/xen_common.h
> > > +++ b/include/hw/xen/xen_common.h
> > > @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void
> > *logger, void *dombuild_logger,
> > >      return xc_interface_open(logger, dombuild_logger, open_flags);
> > >  }
> > >
> > > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > > +                                           unsigned int open_flags)
> > > +{
> > > +    return xc_gntshr_open(logger, open_flags);
> > > +}
> > > +
> > >  /* FIXME There is now way to have the xen fd */
> > >  static inline int xc_fd(xc_interface *xen_xc)
> > >  {
> > > diff --git a/xen-hvm.c b/xen-hvm.c
> > > index 21f1cbb..c99ace8 100644
> > > --- a/xen-hvm.c
> > > +++ b/xen-hvm.c
> > > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > >      int i, rc;
> > >      unsigned long ioreq_pfn;
> > >      unsigned long bufioreq_evtchn;
> > > +
> > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > +    unsigned long stubdom_vtpm = 0;
> > > +#endif
> > > +
> > >      XenIOState *state;
> > >
> > >      state = g_malloc0(sizeof (XenIOState));
> > > @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t
> > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > >          fprintf(stderr, "%s: xen backend core setup failed\n",
> > __FUNCTION__);
> > >          return -1;
> > >      }
> > > +
> > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > +    xc_get_hvm_param(xen_xc, xen_domid,
> > HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > > +    if (stubdom_vtpm) {
> > > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > > +    }
> > > +#endif
> > 
> > Given that vtpm is just a PV frontend, can't you just detect whether is
> > present on xenstore and initialize it based on that? Like all the
> > backend below?
> 
> Also I will explain in my next email. 
> 
> 
> > 
> > 
> > >      xen_be_register("console", &xen_console_ops);
> > >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> > >      xen_be_register("qdisk", &xen_blkdev_ops);
> > > --
> > > 1.8.3.2
> > >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:01:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:01:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyLM-0003z9-TD; Wed, 05 Nov 2014 11:01:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlyLL-0003yr-7O
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 11:01:39 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	BE/EF-24859-2930A545; Wed, 05 Nov 2014 11:01:38 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415185296!11714597!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1137 invoked from network); 5 Nov 2014 11:01:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:01:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189659243"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 06:01:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlyLF-0004uG-FQ;
	Wed, 05 Nov 2014 11:01:33 +0000
Date: Wed, 5 Nov 2014 11:01:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Quan" <quan.xu@intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411051036310.22875@kaball.uk.xensource.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 4 Nov 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Monday, November 03, 2014 7:54 PM
> > To: Xu, Quan
> > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > stefano.stabellini@eu.citrix.com
> > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > frontend driver
> > 
> > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > This drvier transfers any request/repond between TPM xenstubdoms
> > > driver and Xen vTPM stubdom, and facilitates communications between
> > > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > >
> > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > 
> > Please describe what changes did make to xen_backend.c and why.
> > The commit message should contains info on all the changes made by the
> > patch below.
> > 
> 	
> Thanks Stefano. 
> one more day, I will explain in detail what changes did make to xen_backend.c 
> and why. 
> The following 2 sections are introduction and architecture. 
> 
> > Please also describe what is the "Xen vTPM stubdom", what is the
> > "vTPM xenstubdoms driver" and how the communicate with each others.
> > 
> 
> 
> Add 2 parts for detailed descriptions, introduction and architecture.  
> 
> *INTRODUCTION*
> 
> The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality
> to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to
> interact with a TPM in a virtual machine the same way they interact with a TPM on the
> physical system. Each virtual machine gets its own unique, emulated, software TPM.
> Each major component of vTPM is implemented as a stubdom, providing secure separation
> guaranteed by the hypervisor.
> The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine
> to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed
> from mini-os TPM backend driver.
> This patch series are only the Qemu part to enable Xen stubdom vTPM for HVM virtual
> machine.
> ===========
> 
> *ARCHITECTURE*
> 
> The architecture of stubdom vTPM for HVM virtual machine:
> 
>             +--------------------+
>             | Windows/Linux DomU | ...
>             |        |  ^        |
>             |        v  |        |
>             |  Qemu tpm1.2 Tis   |
>             |        |  ^        |
>             |        v  |        |
>             |        vTPM        |
>             | XenStubdoms driver |  (new ..)
>             +--------------------+
>                      |  ^
>                      v  |
>             +--------------------+
>             |  xen_vtpmdev_ops   |  (new ..)
>             +--------------------+
>                      |  ^
>                      v  |
>             +--------------------+
>             |  mini-os/tpmback   |
>             |        |  ^        |
>             |        v  |        |
>             |   vTPM stubdom     | ...
>             |        |  ^        |
>             |        v  |        |
>             |  mini-os/tpmfront  |
>             +--------------------+
>                      |  ^
>                      v  |
>             +--------------------+
>             |  mini-os/tpmback   |
>             |        |  ^        |
>             |        v  |        |
>             |  vtpmmgr stubdom   |
>             |        |  ^        |
>             |        v  |        |
>             |  mini-os/tpm_tis   |
>             +--------------------+
>                      |  ^
>                      v  |
>             +--------------------+
>             |    Hardware TPM    |
>             +--------------------+
> 
> 
> * Windows/Linux DomU:
>     The HVM based guest that wants to use a vTPM. There may be
>     more than one of these.
> 
>  * Qemu tpm1.2 Tis:
>     Implementation of the tpm1.2 Tis interface for HVM virtual
>     machines. It is Qemu emulation device.

It looks like you are running upstream QEMU within a Mini-OS stubdom?
If so, where are the patches to do that? As far as I know upstream QEMU
doesn't run on Mini-OS. Or maybe it is a Linux stubdom? Either way, it
is not clear.


>  * vTPM xenstubdoms driver:
>     Similar to a TPM passthrough backend driver, it is a new TPM
>     backend for emulated TPM TIS interface. This driver provides
>     vTPM initialization and sending data and commends to a Xen
>     vTPM stubdom.

This is patch #3, right? It is basically the internal QEMU "glue" to
connect the tpm emulator to xen_vtpmdev_ops, correct?


>  * xen_vtpmdev_ops:
>     Register Xen stubdom vTPM backend, and transfer any request/
>     repond between TPM xenstubdoms driver and Xen vTPM stubdom.
>     Facilitate communications between Xen vTPM stubdom and vTPM
>     xenstubdoms driver.
 
It looks like this correspond to patch #2? If so, this is a regular Xen
PV frontend, living in QEMU? It requires the gntalloc device so I guess
it is supposed to run on Linux. In that case is it just a tpmfront
implementation in QEMU?

If you are running it on Linux, we might need to introduce Linux based
stundoms to the Xen build system.


>  * mini-os/tpmback:
>     Mini-os TPM backend driver. The Linux frontend driver connects
>     to this backend driver to facilitate communications between the
>     Linux DomU and its vTPM. This driver is also used by vtpmmgr
>     stubdom to communicate with vTPM stubdom.
> 
>  * vTPM stubdom:
>     A mini-os stub domain that implements a vTPM. There is a
>     one to one mapping between running vTPM stubdom instances and
>     logical vTPMs on the system. The vTPM Platform Configuration
>     Registers (PCRs) are all initialized to zero.
>
>  * mini-os/tpmfront:
>     Mini-os TPM frontend driver. The vTPM mini-os domain vTPM
>     stubdom uses this driver to communicate with vtpmmgr-stubdom.
>     This driver could also be used separately to implement a mini-os
>     domain that wishes to use a vTPM of its own.
>
>  * vtpmmgr stubdom:
>     A mini-os domain that implements the vTPM manager. There is only
>     one vTPM manager and it should be running during the entire lifetime
>     of the machine. vtpmmgr domain securely stores encryption keys for
>     each of the vTPMs and accesses to the hardware TPM to get the root of
>     trust for the entire system.
> 
>  * mini-os/tpm_tis:
>     Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
>     This driver used by vtpmmgr-stubdom to talk directly to the hardware
>     TPM. Communication is facilitated by mapping hardware memory pages
>     into vtpmmgr stubdom.
 
Are all the Mini-OS component upstream, or do we need patches?


>  * Hardware TPM:
>     The physical TPM 1.2 that is soldered onto the motherboard.
> 
> ===========
> 
> 
> 
> > Where does the vTPM backend lives?
> The vTPM backend lives in Xen vTPM stubdom (Xen Mini-os)

Thanks for the explanation, it is a bit clearer now.


> > 
> > 
> > >  hw/xen/Makefile.objs         |   1 +
> > >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> > >  hw/xen/xen_stubdom_vtpm.c    | 333
> > +++++++++++++++++++++++++++++++++++++++++++
> > >  include/hw/xen/xen_backend.h |  11 ++
> > >  include/hw/xen/xen_common.h  |   6 +
> > >  xen-hvm.c                    |  13 ++
> > >  6 files changed, 544 insertions(+), 2 deletions(-)
> > >  create mode 100644 hw/xen/xen_stubdom_vtpm.c
> > >
> > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> > > index a0ca0aa..724df8d 100644
> > > --- a/hw/xen/Makefile.objs
> > > +++ b/hw/xen/Makefile.objs
> > > @@ -1,5 +1,6 @@
> > >  # xen backend driver support
> > >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> > xen_devconfig.o
> > > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> > >
> > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> > xen_pt_config_init.o xen_pt_msi.o
> > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> > > index b2cb22b..45a5778 100644
> > > --- a/hw/xen/xen_backend.c
> > > +++ b/hw/xen/xen_backend.c
> > > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev,
> > enum xenbus_state state)
> > >      return 0;
> > >  }
> > >
> > > +/*get stubdom backend*/
> > > +static char *xen_stubdom_be(const char *type, int dom, int dev)
> > > +{
> > > +    char *val, *domu;
> > > +    char path[XEN_BUFSIZE];
> > > +    unsigned int len, ival;
> > > +
> > > +    /*front domu*/
> > > +    domu = xs_get_domain_path(xenstore, dom);
> > > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > > +             domu, type, dev);
> > > +    g_free(domu);
> > > +
> > > +    val = xs_read(xenstore, 0, path, &len);
> > > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > > +        g_free(val);
> > > +        return NULL;
> > > +    }
> > > +    g_free(val);
> > > +
> > > +    /*backend domu*/
> > > +    domu = xs_get_domain_path(xenstore, ival);
> > > +
> > > +    return domu;
> > > +}
> > > +
> > >  /* ------------------------------------------------------------- */
> > >
> > >  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int
> > dev)
> > > @@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const
> > char *type, int dom, int dev,
> > >                                             struct XenDevOps *ops)
> > >  {
> > >      struct XenDevice *xendev;
> > > +    char *stub;
> > >
> > >      xendev = xen_be_find_xendev(type, dom, dev);
> > >      if (xendev) {
> > > @@ -235,8 +262,15 @@ static struct XenDevice
> > *xen_be_get_xendev(const char *type, int dom, int dev,
> > >      xendev->dev   = dev;
> > >      xendev->ops   = ops;
> > >
> > > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > > -             xendev->type, xendev->dom, xendev->dev);
> > > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> > xendev->dev);
> > > +        snprintf(xendev->be, sizeof(xendev->be),
> > "%s/backend/%s/%d/%d",
> > > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > > +        g_free(stub);
> > > +    } else {
> > > +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > > +                 xendev->type, xendev->dom, xendev->dev);
> > > +    }
> > >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> > >               xendev->type, xendev->dev);
> > >
> > > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int
> > dom, struct XenDevOps *ops)
> > >      return 0;
> > >  }
> > >
> > > +static void stubdom_update_be(char *watch, char *type, int dom,
> > > +                              struct XenDevOps *ops)
> > > +{
> > > +    struct XenDevice *xendev;
> > > +    char path[XEN_BUFSIZE];
> > > +    char *ptr, *bepath;
> > > +    unsigned int len, dev;
> > > +
> > > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > > +        return;
> > > +    }
> > > +
> > > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > > +    ptr = strstr(watch, path);
> > > +    if (ptr == NULL) {
> > > +        return;
> > > +    }
> > > +
> > > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > > +        strcpy(path, "");
> > > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > > +            dev = -1;
> > > +        }
> > > +    }
> > > +
> > > +    if (dev == -1) {
> > > +        return;
> > > +    }
> > > +
> > > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > > +    if (xendev != NULL) {
> > > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > > +        if (bepath == NULL) {
> > > +            xen_be_del_xendev(dom, dev);
> > > +        } else {
> > > +            free(bepath);
> > > +            xen_be_backend_changed(xendev, path);
> > > +        }
> > > +    }
> > > +}
> > > +
> > >  static void xenstore_update_be(char *watch, char *type, int dom,
> > >                                 struct XenDevOps *ops)
> > >  {
> > > @@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
> > >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> > >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> > >      }
> > > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> > PRIxPTR,
> > > +               &type, &dom, &ops) == 3) {
> > > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom,
> > (void *)ops);
> > > +    }
> > >
> > >  cleanup:
> > >      free(vec);
> > > @@ -732,11 +811,74 @@ err:
> > >      return -1;
> > >  }
> > >
> > > +int xen_vtpm_register(struct XenDevOps *ops)
> > > +{
> > > +    struct XenDevice *xendev;
> > > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > > +    char *domu;
> > > +    unsigned int cdev, j, rc;
> > > +    const char *type = "vtpm";
> > > +    char **dev = NULL;
> > > +
> > > +    /*front domu*/
> > > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > > +    snprintf(path, sizeof(path), "%s/device/%s",
> > > +             domu, type);
> > > +    free(domu);
> > > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > > +    if (dev == NULL) {
> > > +        return 0;
> > > +    }
> > > +
> > > +    for (j = 0; j < cdev; j++) {
> > > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> > ops);
> > > +        if (xendev == NULL) {
> > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> > NULL.\n");
> > > +            continue;
> > > +        }
> > > +
> > > +        if (xendev->ops->initialise) {
> > > +            rc = xendev->ops->initialise(xendev);
> > > +
> > > +            /*if initialise failed, delete it*/
> > > +            if (rc != 0) {
> > > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > > +                continue;
> > > +            }
> > > +        }
> > > +
> > > +        /*setup watch*/
> > > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > > +                 type, xen_domid, xendev->ops);
> > > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> > failed.\n");
> > > +            return -1;
> > > +        }
> > > +    }
> > > +
> > > +    free(dev);
> > > +    return 0;
> > > +}
> > 
> > What does this function do? I sholdn't need  to guess from the code, I
> > should be able to tell from the patch description.
> > 
> > 
> > >  int xen_be_register(const char *type, struct XenDevOps *ops)
> > >  {
> > >      return xenstore_scan(type, xen_domid, ops);
> > >  }
> > >
> > > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > remote_dom)
> > > +{
> > > +    xendev->local_port =
> > xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > > +
> > remote_dom);
> > > +    if (xendev->local_port == -1) {
> > > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> > > +        return -1;
> > > +    }
> > > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> > xendev->local_port);
> > > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > > +                        xen_be_evtchn_event, NULL, xendev);
> > > +    return 0;
> > > +}
> > > +
> > >  int xen_be_bind_evtchn(struct XenDevice *xendev)
> > >  {
> > >      if (xendev->local_port != -1) {
> > > @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice
> > *xendev)
> > >      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
> > >  }
> > >
> > > +int xen_vtpm_send(unsigned char *buf, size_t count)
> > > +{
> > > +    struct XenDevice *xendev;
> > > +    int rc = -1;
> > > +
> > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > +    if (xendev == NULL) {
> > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > +        return -1;
> > > +    }
> > > +
> > > +    if (xendev->ops->send) {
> > > +        rc = xendev->ops->send(xendev, buf, count);
> > > +    }
> > > +
> > > +    return rc;
> > > +}
> > > +
> > > +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> > > +{
> > > +    struct XenDevice *xendev;
> > > +    int rc = -1;
> > > +
> > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > +    if (xendev == NULL) {
> > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > +        return -1;
> > > +    }
> > > +
> > > +    if (xendev->ops->recv) {
> > > +        xendev->ops->recv(xendev, buf, count);
> > > +    }
> > > +
> > > +    return rc;
> > > +}
> > 
> > xen_backend.c is supposed to be generic, so stubdom functions might be
> > OK but vtpm specific functions should not be here.
> > 
> > 
> > >  /*
> > >   * msg_level:
> > >   *  0 == errors (stderr + logfile).
> > > diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> > > new file mode 100644
> > > index 0000000..0d740c1
> > > --- /dev/null
> > > +++ b/hw/xen/xen_stubdom_vtpm.c
> > > @@ -0,0 +1,333 @@
> > > +/*
> > > + * Connect to Xen vTPM stubdom domain
> > > + *
> > > + *  Copyright (c) 2014 Intel Corporation
> > > + *  Authors:
> > > + *    Quan Xu <quan.xu@intel.com>
> > > + *
> > > + * 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 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, see
> > <http://www.gnu.org/licenses/>
> > > + */
> > > +
> > > +#include <stdio.h>
> > > +#include <stdlib.h>
> > > +#include <stdarg.h>
> > > +#include <string.h>
> > > +#include <unistd.h>
> > > +#include <signal.h>
> > > +#include <inttypes.h>
> > > +#include <time.h>
> > > +#include <fcntl.h>
> > > +#include <errno.h>
> > > +#include <sys/ioctl.h>
> > > +#include <sys/types.h>
> > > +#include <sys/stat.h>
> > > +#include <sys/mman.h>
> > > +#include <sys/uio.h>
> > > +
> > > +#include "hw/hw.h"
> > > +#include "block/aio.h"
> > > +#include "hw/xen/xen_backend.h"
> > > +
> > > +enum tpmif_state {
> > > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> > complete */
> > > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> > > +};
> > > +
> > > +static AioContext *vtpm_aio_ctx;
> > > +
> > > +enum status_bits {
> > > +    VTPM_STATUS_RUNNING  = 0x1,
> > > +    VTPM_STATUS_IDLE     = 0x2,
> > > +    VTPM_STATUS_RESULT   = 0x4,
> > > +    VTPM_STATUS_CANCELED = 0x8,
> > > +};
> > > +
> > > +struct tpmif_shared_page {
> > > +    uint32_t length;         /* request/response length in bytes */
> > > +
> > > +    uint8_t  state;           /* enum tpmif_state */
> > > +    uint8_t  locality;        /* for the current request */
> > > +    uint8_t  pad;             /* should be zero */
> > > +
> > > +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be
> > zero */
> > > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> > nr_extra_pages */
> > > +};
> > > +
> > > +struct QEMUBH {
> > > +    AioContext *ctx;
> > > +    QEMUBHFunc *cb;
> > > +    void *opaque;
> > > +    QEMUBH *next;
> > > +    bool scheduled;
> > > +    bool idle;
> > > +    bool deleted;
> > > +};
> > > +
> > > +struct XenVtpmDev {
> > > +    struct XenDevice xendev;  /* must be first */
> > > +    struct           tpmif_shared_page *shr;
> > > +    xc_gntshr        *xen_xcs;
> > > +    int              ring_ref;
> > > +    int              bedomid;
> > > +    QEMUBH           *sr_bh;
> > > +};
> > > +
> > > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> > > +{
> > > +    switch (vtpmdev->shr->state) {
> > > +    case TPMIF_STATE_IDLE:
> > > +    case TPMIF_STATE_FINISH:
> > > +        return VTPM_STATUS_IDLE;
> > > +    case TPMIF_STATE_SUBMIT:
> > > +    case TPMIF_STATE_CANCEL:
> > > +        return VTPM_STATUS_RUNNING;
> > > +    default:
> > > +        return 0;
> > > +    }
> > > +}
> > > +
> > > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> > xenbus_state xbus)
> > > +{
> > > +    xs_transaction_t xbt = XBT_NULL;
> > > +
> > > +    if (xendev->fe_state == xbus) {
> > > +        return 0;
> > > +    }
> > > +
> > > +    xendev->fe_state = xbus;
> > > +
> > > +retry_transaction:
> > > +    xbt = xs_transaction_start(xenstore);
> > > +    if (xbt == XBT_NULL) {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > +        if (errno == EAGAIN) {
> > > +            goto retry_transaction;
> > > +        }
> > > +    }
> > > +
> > > +    return 0;
> > > +
> > > +abort_transaction:
> > > +    xs_transaction_end(xenstore, xbt, 1);
> > > +    return -1;
> > > +}
> > > +
> > > +static int vtpm_aio_wait(QEMUBH *qbh)
> > > +{
> > > +    return aio_poll(qbh->ctx, true);
> > > +}
> > > +
> > > +static void sr_bh_handler(void *opaque)
> > > +{
> > > +}
> > > +
> > > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t
> > *count)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > +    unsigned int offset;
> > > +
> > > +    if (shr->state == TPMIF_STATE_IDLE) {
> > > +        return -ECANCELED;
> > > +    }
> > > +
> > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > +    }
> > > +
> > > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > > +    *count = shr->length;
> > > +
> > > +    return 0;
> > > +}
> > > +
> > > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t
> > count)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > +
> > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > +    }
> > > +
> > > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > > +    shr->length = count;
> > > +    barrier();
> > > +    shr->state = TPMIF_STATE_SUBMIT;
> > > +    xen_wmb();
> > > +    xen_be_send_notify(&vtpmdev->xendev);
> > > +
> > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > +    }
> > > +
> > > +    return count;
> > > +}
> > > +
> > > +static int vtpm_initialise(struct XenDevice *xendev)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +    xs_transaction_t xbt = XBT_NULL;
> > > +    unsigned int ring_ref;
> > > +
> > > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> > "frontend");
> > > +    if (vtpmdev->xendev.fe == NULL) {
> > > +        return -1;
> > > +    }
> > > +
> > > +    /* Get backend domid */
> > > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > > +                             &vtpmdev->bedomid)) {
> > > +        return -1;
> > > +    }
> > > +
> > > +    /*alloc share page*/
> > > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> > vtpmdev->bedomid, 1,
> > > +                                         &ring_ref,
> > PROT_READ|PROT_WRITE);
> > > +    vtpmdev->ring_ref = ring_ref;
> > > +    if (vtpmdev->shr == NULL) {
> > > +        return -1;
> > > +    }
> > > +
> > > +    /*Create event channel */
> > > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> > vtpmdev->bedomid)) {
> > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > +        return -1;
> > > +    }
> > > +
> > > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > > +                     vtpmdev->xendev.local_port);
> > > +
> > > +again:
> > > +    xbt = xs_transaction_start(xenstore);
> > > +    if (xbt == XBT_NULL) {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > > +                           vtpmdev->ring_ref)) {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > > +                           vtpmdev->xendev.local_port)) {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    /* Publish protocol v2 feature */
> > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1))
> > {
> > > +        goto abort_transaction;
> > > +    }
> > > +
> > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > +        if (errno == EAGAIN) {
> > > +            goto again;
> > > +        }
> > > +    }
> > > +    /* Tell vtpm backend that we are ready */
> > > +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> > > +
> > > +    return 0;
> > > +
> > > +abort_transaction:
> > > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > +    xs_transaction_end(xenstore, xbt, 1);
> > > +    return -1;
> > > +}
> > > +
> > > +static void vtpm_backend_changed(struct XenDevice *xendev, const char
> > *node)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +    int be_state;
> > > +
> > > +    if (strcmp(node, "state") == 0) {
> > > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > > +        switch (be_state) {
> > > +        case XenbusStateConnected:
> > > +            /*TODO*/
> > > +            break;
> > > +        case XenbusStateClosing:
> > > +        case XenbusStateClosed:
> > > +            xenbus_switch_state(&vtpmdev->xendev,
> > XenbusStateClosing);
> > > +            break;
> > > +        default:
> > > +            break;
> > > +        }
> > > +    }
> > > +}
> > > +
> > > +static int vtpm_free(struct XenDevice *xendev)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > > +
> > > +    aio_poll(qbh->ctx, false);
> > > +    qemu_bh_delete(vtpmdev->sr_bh);
> > > +    if (vtpmdev->shr) {
> > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > +    }
> > > +    xc_interface_close(vtpmdev->xen_xcs);
> > > +    return 0;
> > > +}
> > > +
> > > +static void vtpm_alloc(struct XenDevice *xendev)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +
> > > +    vtpm_aio_ctx = aio_context_new(NULL);
> > > +    if (vtpm_aio_ctx == NULL) {
> > > +        return;
> > > +    }
> > > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> > vtpmdev);
> > > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> > > +}
> > > +
> > > +static void vtpm_event(struct XenDevice *xendev)
> > > +{
> > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > XenVtpmDev,
> > > +                                              xendev);
> > > +
> > > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > > +}
> > > +
> > > +struct XenDevOps xen_vtpmdev_ops = {
> > > +    .size             = sizeof(struct XenVtpmDev),
> > > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > > +                        DEVOPS_FLAG_STUBDOM_BE,
> > > +    .event            = vtpm_event,
> > > +    .free             = vtpm_free,
> > > +    .alloc            = vtpm_alloc,
> > > +    .initialise       = vtpm_initialise,
> > > +    .backend_changed  = vtpm_backend_changed,
> > > +    .recv             = vtpm_recv,
> > > +    .send             = vtpm_send,
> > > +};
> > 
> > Is this the frontend, like the subject line would seem to imply?
> > If so, XenDevOps are made for backends, while this is a frontend. In
> > fact this is the first PV frontend in QEMU. We need to introduce
> > something generic and similar to struct XenDevOps and xen_backend.c but
> > for frontends.
> > 
> > 
> > > diff --git a/include/hw/xen/xen_backend.h
> > b/include/hw/xen/xen_backend.h
> > > index 3b4125e..45fd6d3 100644
> > > --- a/include/hw/xen/xen_backend.h
> > > +++ b/include/hw/xen/xen_backend.h
> > > @@ -15,6 +15,8 @@ struct XenDevice;
> > >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> > >  /* don't expect frontend doing correct state transitions (aka console
> > quirk) */
> > >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > > +/*dev backend is stubdom*/
> > > +#define DEVOPS_FLAG_STUBDOM_BE    4
> > >
> > >  struct XenDevOps {
> > >      size_t    size;
> > > @@ -26,6 +28,8 @@ struct XenDevOps {
> > >      void      (*event)(struct XenDevice *xendev);
> > >      void      (*disconnect)(struct XenDevice *xendev);
> > >      int       (*free)(struct XenDevice *xendev);
> > > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> > count);
> > > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> > *count);
> > >      void      (*backend_changed)(struct XenDevice *xendev, const
> > char *node);
> > >      void      (*frontend_changed)(struct XenDevice *xendev, const
> > char *node);
> > >  };
> > > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> > *xendev);
> > >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char
> > *fmt, ...)
> > >      GCC_FMT_ATTR(3, 4);
> > >
> > > +/*Xen stubdom vtpm*/
> > > +int xen_vtpm_register(struct XenDevOps *ops);
> > > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > remote_dom);
> > > +int xen_vtpm_send(unsigned char *buf, size_t count);
> > > +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> > > +
> > >  /* actual backend drivers */
> > >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> > */
> > >  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c
> > */
> > >  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
> > >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> > */
> > >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> > */
> > > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> > xen_stubdom_vtpm.c*/
> > >
> > >  void xen_init_display(int domid);
> > >
> > > diff --git a/include/hw/xen/xen_common.h
> > b/include/hw/xen/xen_common.h
> > > index 95612a4..fb43084 100644
> > > --- a/include/hw/xen/xen_common.h
> > > +++ b/include/hw/xen/xen_common.h
> > > @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void
> > *logger, void *dombuild_logger,
> > >      return xc_interface_open(logger, dombuild_logger, open_flags);
> > >  }
> > >
> > > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > > +                                           unsigned int open_flags)
> > > +{
> > > +    return xc_gntshr_open(logger, open_flags);
> > > +}
> > > +
> > >  /* FIXME There is now way to have the xen fd */
> > >  static inline int xc_fd(xc_interface *xen_xc)
> > >  {
> > > diff --git a/xen-hvm.c b/xen-hvm.c
> > > index 21f1cbb..c99ace8 100644
> > > --- a/xen-hvm.c
> > > +++ b/xen-hvm.c
> > > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > >      int i, rc;
> > >      unsigned long ioreq_pfn;
> > >      unsigned long bufioreq_evtchn;
> > > +
> > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > +    unsigned long stubdom_vtpm = 0;
> > > +#endif
> > > +
> > >      XenIOState *state;
> > >
> > >      state = g_malloc0(sizeof (XenIOState));
> > > @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t
> > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > >          fprintf(stderr, "%s: xen backend core setup failed\n",
> > __FUNCTION__);
> > >          return -1;
> > >      }
> > > +
> > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > +    xc_get_hvm_param(xen_xc, xen_domid,
> > HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > > +    if (stubdom_vtpm) {
> > > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > > +    }
> > > +#endif
> > 
> > Given that vtpm is just a PV frontend, can't you just detect whether is
> > present on xenstore and initialize it based on that? Like all the
> > backend below?
> 
> Also I will explain in my next email. 
> 
> 
> > 
> > 
> > >      xen_be_register("console", &xen_console_ops);
> > >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> > >      xen_be_register("qdisk", &xen_blkdev_ops);
> > > --
> > > 1.8.3.2
> > >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:01:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:01:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyLP-00040K-Gf; Wed, 05 Nov 2014 11:01:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XlyLL-0003yu-Tg
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:01:40 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	EF/81-14727-3930A545; Wed, 05 Nov 2014 11:01:39 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415185297!11344157!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9839 invoked from network); 5 Nov 2014 11:01:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:01:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189659249"
Message-ID: <545A038F.2020303@citrix.com>
Date: Wed, 5 Nov 2014 11:01:35 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185138.11486.87.camel@citrix.com>
In-Reply-To: <1415185138.11486.87.camel@citrix.com>
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/11/14 10:58, Ian Campbell wrote:
> Dropping netdev since this isn't relevant to them, adding Paul
> 
> On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
>> - performance: Netback has already grant copied up-to 128 bytes from
>>   the first slot of a packet into the linear area. The first slot
>>   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> 
> Does "normally" here include guests other than Linux? I thought Windows
> in particular was prone to splitting the headers into a frag per layer
> or thereabouts?

I'm not sure what guests Malcolm tested with.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:01:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:01:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyLP-00040K-Gf; Wed, 05 Nov 2014 11:01:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XlyLL-0003yu-Tg
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:01:40 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	EF/81-14727-3930A545; Wed, 05 Nov 2014 11:01:39 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415185297!11344157!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9839 invoked from network); 5 Nov 2014 11:01:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:01:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189659249"
Message-ID: <545A038F.2020303@citrix.com>
Date: Wed, 5 Nov 2014 11:01:35 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185138.11486.87.camel@citrix.com>
In-Reply-To: <1415185138.11486.87.camel@citrix.com>
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/11/14 10:58, Ian Campbell wrote:
> Dropping netdev since this isn't relevant to them, adding Paul
> 
> On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
>> - performance: Netback has already grant copied up-to 128 bytes from
>>   the first slot of a packet into the linear area. The first slot
>>   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> 
> Does "normally" here include guests other than Linux? I thought Windows
> in particular was prone to splitting the headers into a frag per layer
> or thereabouts?

I'm not sure what guests Malcolm tested with.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:02:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:02:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyM7-0004Cx-Vt; Wed, 05 Nov 2014 11:02:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlyM6-0004Ca-Gq
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 11:02:26 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	EF/BC-19763-1C30A545; Wed, 05 Nov 2014 11:02:25 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415185341!11303726!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3664 invoked from network); 5 Nov 2014 11:02:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:02:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188261550"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 06:01:44 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlyLP-0004uP-SW;
	Wed, 05 Nov 2014 11:01:43 +0000
Date: Wed, 5 Nov 2014 11:01:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Quan" <quan.xu@intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E81FD36@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411051056500.22875@kaball.uk.xensource.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031126170.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81FD36@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "keir@xen.org" <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
 machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Monday, November 03, 2014 7:30 PM
> > To: Xu, Quan
> > Cc: xen-devel@lists.xen.org; keir@xen.org; ian.campbell@citrix.com;
> > tim@xen.org; ian.jackson@eu.citrix.com; jbeulich@suse.com
> > Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> > virtual machine
> > 
> > On Thu, 30 Oct 2014, Quan Xu wrote:
> > >
> > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > >
> > > This patch series are only the Xen part to enable stubdom vTPM for HVM
> > virtual machine.
> > > it will work w/ Qemu patch series and seaBios patch series. Change
> > > QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the
> > Qemu/SeaBios patch series are merged.
> > 
> > Please, could you add more detailed commit messages in your patches?
> > Also spending a few more words here to explain why are you doing this and
> > how would help.
> > 
> The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality
> to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to
> interact with a TPM in a virtual machine the same way they interact with a TPM on the
> physical system. Each virtual machine gets its own unique, emulated, software TPM.
> Each major component of vTPM is implemented as a stubdom, providing secure separation
> guaranteed by the hypervisor.
> The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine
> to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed
> from mini-os TPM backend driver.
> 
> This patch series are to enable Xen stubdom vTPM for HVM virtual machine. his allows 
> programs to interact with a TPM in a HVM virtual machine(Fedora, Ubuntu, Redhat, Windows .etc)
> the same way they interact with a TPM on the physical system.
> 
> 
> > It looks like you are trying to introduce vTPM stubdomains. The QEMU
> > changes have been posted against upstream QEMU, that is good, however as
> > far as I know upstream QEMU doesn't build or work as a stubdomain yet.
> > Where are the changes to make upstream QEMU based stubdoms work?
> > I don't see them neither here nor in the QEMU series.
> > 
> It's Xen stubdom, not QEMU stubdom. Sorry for this confusion. 

What does "Xen stubdom" mean?
I am still a bit confused, I replied to the other email.


> > How are you testing this work?
> 
> 
> The following steps are how to build and test it: 
> 
> 1. SeaBios with my patch against upstream seabios is not submitted. I will submit seabios patch when I 
> finish these questions from review. Now I archive my seabios patch against upstream seabios in 
> Github: https://github.com/virt2x/seabios2 , try to build it for test. 
> 
> Configure it with Xen,
> --- <Xen> Config.mk
> -SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
> +SEABIOS_UPSTREAM_URL ?= https://github.com/virt2x/seabios2
> [...]
> -SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
> +SEABIOS_UPSTREAM_REVISION ?= ea94c083cc15875f46f0bf288b6531154b866f5a
> 
> 2. qemu with my patch against upstream QEMU is not merged. now I archive my 
> qemu patch series again Upstream QEMU in github: https://github.com/virt2x/qemu-xen-unstable2 
> 
> Configure it with Xen, 
> --- <Xen> Config.mk
> 
> -QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
> +QEMU_UPSTREAM_URL ?= https://github.com/virt2x/qemu-xen-unstable2
> -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc1
> +QEMU_UPSTREAM_REVISION ?= e867e6cf86c8412ca516cf2d0ccad57130e3388c
> 
> 3. build/install Xen
> Change QEMU_STUBDOM_VTPM option from 'n' to 'y'
>    QEMU_STUBDOM_VTPM ?= y
> ./configure --prefix=/usr
> make dist
> make install 

>From the previous email, it looks like you are running QEMU in a Linux
based stubdom. If so, I don't see where are you creating it.


> 4. try to launch vtpmmgr / vtpm domain via <Xen>/docs/misc/vtpm-platforms.txt.
> The reader is assumed to have familiarity with building and installing Xen, Linux, and a basic 
> understanding of the TPM and vTPM concepts.
> 
> The Linux / Windows HVM guest configuration file needs to be modified to include the following line:
> [..]
> vtpm=["backend=domu-vtpm"]
> device_model_version = 'qemu-xen'
> acpi = 1
> [..]
> 
> ## domu-vtpm is the name vtpm domain, A mini-os stub domain that implements a vTPM. 
> 
> 5. enable native TPM 1.2 drvier in HVM virtual machine. for example enable tpm_tis.ko in Linux 
> HVM virtual machine. 
> If you have trousers and tpm_tools installed on the guest, the tpm_version
> command should return the following:
> 
> The version command should return the following:
>   TPM 1.2 Version Info:
>   Chip Version:        1.2.0.7
>   Spec Level:          2
>   Errata Revision:     1
>   TPM Vendor ID:       ETHZ
>   TPM Version:         01010000
>   Manufacturer Info:   4554485a
> 
> Or check it with sysfs, /sys/class/misc/tpm0
> 
> 
> BTW, Some local ISV are trying to integrate this feature into their cloud service for trusted services, 
> Such as trusted virtual desktop infrastructure(HVM fedora/ubuntu/redhat/windows virtual machine).
> 
> 
> > 
> > 
> > >  Config.mk                             |  4 ++++
> > >  extras/mini-os/include/tpmback.h      |  3 +++
> > >  extras/mini-os/tpmback.c              | 20 +++++++++++++++++---
> > >  tools/Makefile                        |  7 +++++++
> > >  tools/firmware/hvmloader/acpi/build.c |  5 +++--
> > >  tools/libxl/libxl.c                   | 62
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > +++
> > >  tools/libxl/libxl_create.c            | 16 +++++++++++++---
> > >  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
> > >  tools/libxl/libxl_dom.c               |  2 ++
> > >  tools/libxl/libxl_internal.h          |  3 +++
> > >  tools/libxl/libxl_types.idl           |  1 +
> > >  tools/libxl/xl_cmdimpl.c              |  2 ++
> > >  xen/arch/x86/hvm/hvm.c                |  3 +++
> > >  xen/include/public/hvm/params.h       |  1 +
> > >
> > > I've tried to break it down to smaller patches:
> > >
> > >  *(Patch 1/6)*  event channel bind interdomain with para/hvm virtual
> > > machine
> > >
> > >  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for HVM
> > virtual
> > > machine
> > >
> > >  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual
> > > machine
> > >
> > >  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine when
> > > vTPM is added
> > >
> > >  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> > >
> > >  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:02:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:02:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyM7-0004Cx-Vt; Wed, 05 Nov 2014 11:02:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlyM6-0004Ca-Gq
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 11:02:26 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	EF/BC-19763-1C30A545; Wed, 05 Nov 2014 11:02:25 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415185341!11303726!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3664 invoked from network); 5 Nov 2014 11:02:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:02:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188261550"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 06:01:44 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlyLP-0004uP-SW;
	Wed, 05 Nov 2014 11:01:43 +0000
Date: Wed, 5 Nov 2014 11:01:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Quan" <quan.xu@intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E81FD36@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411051056500.22875@kaball.uk.xensource.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031126170.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81FD36@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "keir@xen.org" <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
 machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Monday, November 03, 2014 7:30 PM
> > To: Xu, Quan
> > Cc: xen-devel@lists.xen.org; keir@xen.org; ian.campbell@citrix.com;
> > tim@xen.org; ian.jackson@eu.citrix.com; jbeulich@suse.com
> > Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> > virtual machine
> > 
> > On Thu, 30 Oct 2014, Quan Xu wrote:
> > >
> > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > >
> > > This patch series are only the Xen part to enable stubdom vTPM for HVM
> > virtual machine.
> > > it will work w/ Qemu patch series and seaBios patch series. Change
> > > QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the
> > Qemu/SeaBios patch series are merged.
> > 
> > Please, could you add more detailed commit messages in your patches?
> > Also spending a few more words here to explain why are you doing this and
> > how would help.
> > 
> The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality
> to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to
> interact with a TPM in a virtual machine the same way they interact with a TPM on the
> physical system. Each virtual machine gets its own unique, emulated, software TPM.
> Each major component of vTPM is implemented as a stubdom, providing secure separation
> guaranteed by the hypervisor.
> The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine
> to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed
> from mini-os TPM backend driver.
> 
> This patch series are to enable Xen stubdom vTPM for HVM virtual machine. his allows 
> programs to interact with a TPM in a HVM virtual machine(Fedora, Ubuntu, Redhat, Windows .etc)
> the same way they interact with a TPM on the physical system.
> 
> 
> > It looks like you are trying to introduce vTPM stubdomains. The QEMU
> > changes have been posted against upstream QEMU, that is good, however as
> > far as I know upstream QEMU doesn't build or work as a stubdomain yet.
> > Where are the changes to make upstream QEMU based stubdoms work?
> > I don't see them neither here nor in the QEMU series.
> > 
> It's Xen stubdom, not QEMU stubdom. Sorry for this confusion. 

What does "Xen stubdom" mean?
I am still a bit confused, I replied to the other email.


> > How are you testing this work?
> 
> 
> The following steps are how to build and test it: 
> 
> 1. SeaBios with my patch against upstream seabios is not submitted. I will submit seabios patch when I 
> finish these questions from review. Now I archive my seabios patch against upstream seabios in 
> Github: https://github.com/virt2x/seabios2 , try to build it for test. 
> 
> Configure it with Xen,
> --- <Xen> Config.mk
> -SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
> +SEABIOS_UPSTREAM_URL ?= https://github.com/virt2x/seabios2
> [...]
> -SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
> +SEABIOS_UPSTREAM_REVISION ?= ea94c083cc15875f46f0bf288b6531154b866f5a
> 
> 2. qemu with my patch against upstream QEMU is not merged. now I archive my 
> qemu patch series again Upstream QEMU in github: https://github.com/virt2x/qemu-xen-unstable2 
> 
> Configure it with Xen, 
> --- <Xen> Config.mk
> 
> -QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
> +QEMU_UPSTREAM_URL ?= https://github.com/virt2x/qemu-xen-unstable2
> -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc1
> +QEMU_UPSTREAM_REVISION ?= e867e6cf86c8412ca516cf2d0ccad57130e3388c
> 
> 3. build/install Xen
> Change QEMU_STUBDOM_VTPM option from 'n' to 'y'
>    QEMU_STUBDOM_VTPM ?= y
> ./configure --prefix=/usr
> make dist
> make install 

>From the previous email, it looks like you are running QEMU in a Linux
based stubdom. If so, I don't see where are you creating it.


> 4. try to launch vtpmmgr / vtpm domain via <Xen>/docs/misc/vtpm-platforms.txt.
> The reader is assumed to have familiarity with building and installing Xen, Linux, and a basic 
> understanding of the TPM and vTPM concepts.
> 
> The Linux / Windows HVM guest configuration file needs to be modified to include the following line:
> [..]
> vtpm=["backend=domu-vtpm"]
> device_model_version = 'qemu-xen'
> acpi = 1
> [..]
> 
> ## domu-vtpm is the name vtpm domain, A mini-os stub domain that implements a vTPM. 
> 
> 5. enable native TPM 1.2 drvier in HVM virtual machine. for example enable tpm_tis.ko in Linux 
> HVM virtual machine. 
> If you have trousers and tpm_tools installed on the guest, the tpm_version
> command should return the following:
> 
> The version command should return the following:
>   TPM 1.2 Version Info:
>   Chip Version:        1.2.0.7
>   Spec Level:          2
>   Errata Revision:     1
>   TPM Vendor ID:       ETHZ
>   TPM Version:         01010000
>   Manufacturer Info:   4554485a
> 
> Or check it with sysfs, /sys/class/misc/tpm0
> 
> 
> BTW, Some local ISV are trying to integrate this feature into their cloud service for trusted services, 
> Such as trusted virtual desktop infrastructure(HVM fedora/ubuntu/redhat/windows virtual machine).
> 
> 
> > 
> > 
> > >  Config.mk                             |  4 ++++
> > >  extras/mini-os/include/tpmback.h      |  3 +++
> > >  extras/mini-os/tpmback.c              | 20 +++++++++++++++++---
> > >  tools/Makefile                        |  7 +++++++
> > >  tools/firmware/hvmloader/acpi/build.c |  5 +++--
> > >  tools/libxl/libxl.c                   | 62
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > +++
> > >  tools/libxl/libxl_create.c            | 16 +++++++++++++---
> > >  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
> > >  tools/libxl/libxl_dom.c               |  2 ++
> > >  tools/libxl/libxl_internal.h          |  3 +++
> > >  tools/libxl/libxl_types.idl           |  1 +
> > >  tools/libxl/xl_cmdimpl.c              |  2 ++
> > >  xen/arch/x86/hvm/hvm.c                |  3 +++
> > >  xen/include/public/hvm/params.h       |  1 +
> > >
> > > I've tried to break it down to smaller patches:
> > >
> > >  *(Patch 1/6)*  event channel bind interdomain with para/hvm virtual
> > > machine
> > >
> > >  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for HVM
> > virtual
> > > machine
> > >
> > >  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual
> > > machine
> > >
> > >  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine when
> > > vTPM is added
> > >
> > >  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> > >
> > >  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:02:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyMM-0004Hs-C2; Wed, 05 Nov 2014 11:02:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyML-0004HJ-78
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:02:41 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	26/F4-08051-0D30A545; Wed, 05 Nov 2014 11:02:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415185203!12685306!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11206 invoked from network); 5 Nov 2014 11:00:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:00:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189658606"
Message-ID: <1415185172.15200.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 5 Nov 2014 10:59:32 +0000
In-Reply-To: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Malcolm
	Crossley <malcolm.crossley@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dropping netdev since this isn't relevant to them, adding Paul

On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> - performance: Netback has already grant copied up-to 128 bytes from
>   the first slot of a packet into the linear area. The first slot
>   normally contain all the IPv4/IPv6 and TCP/UDP headers.

Does "normally" include guests other than Linux? I thought Windows in
particular was prone to splitting the headers into a frag per layer or
thereabouts?

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:02:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyMM-0004Hs-C2; Wed, 05 Nov 2014 11:02:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlyML-0004HJ-78
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:02:41 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	26/F4-08051-0D30A545; Wed, 05 Nov 2014 11:02:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415185203!12685306!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11206 invoked from network); 5 Nov 2014 11:00:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:00:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189658606"
Message-ID: <1415185172.15200.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 5 Nov 2014 10:59:32 +0000
In-Reply-To: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Malcolm
	Crossley <malcolm.crossley@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dropping netdev since this isn't relevant to them, adding Paul

On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> - performance: Netback has already grant copied up-to 128 bytes from
>   the first slot of a packet into the linear area. The first slot
>   normally contain all the IPv4/IPv6 and TCP/UDP headers.

Does "normally" include guests other than Linux? I thought Windows in
particular was prone to splitting the headers into a frag per layer or
thereabouts?

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:04:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:04:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyOJ-0004j8-Us; Wed, 05 Nov 2014 11:04:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlyOI-0004ii-0x
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:04:42 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	0E/65-28296-9440A545; Wed, 05 Nov 2014 11:04:41 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415185478!11766118!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7341 invoked from network); 5 Nov 2014 11:04:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:04:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188261960"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 06:02:54 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlyMY-0004wA-EI;
	Wed, 05 Nov 2014 11:02:54 +0000
Date: Wed, 5 Nov 2014 11:02:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415184967.11486.84.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411051102020.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com>
	<alpine.DEB.2.02.1411051029370.22875@kaball.uk.xensource.com>
	<1415184967.11486.84.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Ian Campbell wrote:
> On Wed, 2014-11-05 at 10:31 +0000, Stefano Stabellini wrote:
> > On Wed, 5 Nov 2014, Ian Campbell wrote:
> > > > +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> > > > +         * is allowed. The DOMCTL will return the actual version of the
> > > > +         * GIC.
> > > > +         */
> > > > +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> > > > +            return -EOPNOTSUPP;
> > > 
> > > EOPNOTSUPP doesn't seem quite right. EPARM  or EINVAL perhaps?
> > > 
> > > I'm also tempted to suggest that we should accept gic_version == the hw
> > > value, i.e. by moping the switch below up and including
> > >         && domctl->u.configuredomain.gic_version != gic_version
> > > in the condition.
> > 
> > I suggested to use -EOPNOTSUPP because one day we want to be able to use
> > this hypercall to choose a specific gic_version for the guest domain,
> > including gicv2 on gicv3 hardware for example.
> 
> Why is EOPNOTSUPP an appropriate error code for that though?

Because at the moment we don't support this use case? If we did we would
be OK with the user passing gic_version = 2 for example.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:04:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:04:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyOJ-0004j8-Us; Wed, 05 Nov 2014 11:04:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XlyOI-0004ii-0x
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:04:42 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	0E/65-28296-9440A545; Wed, 05 Nov 2014 11:04:41 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415185478!11766118!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7341 invoked from network); 5 Nov 2014 11:04:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:04:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188261960"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 06:02:54 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XlyMY-0004wA-EI;
	Wed, 05 Nov 2014 11:02:54 +0000
Date: Wed, 5 Nov 2014 11:02:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415184967.11486.84.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411051102020.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com>
	<alpine.DEB.2.02.1411051029370.22875@kaball.uk.xensource.com>
	<1415184967.11486.84.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Ian Campbell wrote:
> On Wed, 2014-11-05 at 10:31 +0000, Stefano Stabellini wrote:
> > On Wed, 5 Nov 2014, Ian Campbell wrote:
> > > > +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> > > > +         * is allowed. The DOMCTL will return the actual version of the
> > > > +         * GIC.
> > > > +         */
> > > > +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> > > > +            return -EOPNOTSUPP;
> > > 
> > > EOPNOTSUPP doesn't seem quite right. EPARM  or EINVAL perhaps?
> > > 
> > > I'm also tempted to suggest that we should accept gic_version == the hw
> > > value, i.e. by moping the switch below up and including
> > >         && domctl->u.configuredomain.gic_version != gic_version
> > > in the condition.
> > 
> > I suggested to use -EOPNOTSUPP because one day we want to be able to use
> > this hypercall to choose a specific gic_version for the guest domain,
> > including gicv2 on gicv3 hardware for example.
> 
> Why is EOPNOTSUPP an appropriate error code for that though?

Because at the moment we don't support this use case? If we did we would
be OK with the user passing gic_version = 2 for example.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:10:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:10:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyTd-0004yO-Qq; Wed, 05 Nov 2014 11:10:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlyTc-0004yI-HX
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:10:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7D/9A-24532-3950A545; Wed, 05 Nov 2014 11:10:11 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415185810!12937148!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17518 invoked from network); 5 Nov 2014 11:10:10 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:10:10 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so1633818wib.13
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 03:10:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=0ppLcMn2Nqj/woTFhr5WAlg1LocpEtkXJ31cqB0Npmg=;
	b=iasm/tgsHHLqDh3gZ/B7R2wpyukDO3br8iHlTWYeFawxSUA5SHIfTtF659aYcApENH
	m6srFvTBZbGbQ+mkFXf7eI8UtI8N67jW/GzJsI3T4NHO6pBsTqemsjxRYHwSjB6YZUCa
	psfAu53/I9ZGP9sctpHz6uo/H3i9Fs7fmOdiyh6XeXR5iTozORUtASmf3FfsRsBmo9G1
	y7/M2gxVPJ3Y1lGeCZgOyzvv6Nci/1jcGyjLTOr+QQn13NM2xvN6HMkd59NFmyr9A3KX
	r2Xn6V/E9eYUnkT600+c5ML4fMpDjLWkyhtz2KSOmWhDqSAiWcHdiHOJCeJdKRwVcYWm
	iu+w==
X-Gm-Message-State: ALoCoQlOTakFaFA8T2e6ENS6F1FKag2vCcJE5a5fZnU6pQYfY7jzRb/VcLPoDz807mGtkkZ+mNEd
X-Received: by 10.180.80.39 with SMTP id o7mr4728583wix.37.1415185809754;
	Wed, 05 Nov 2014 03:10:09 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id y5sm15061110wix.9.2014.11.05.03.10.08
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 05 Nov 2014 03:10:08 -0800 (PST)
Message-ID: <545A058F.5040603@linaro.org>
Date: Wed, 05 Nov 2014 11:10:07 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com>
In-Reply-To: <1415183041.11486.74.camel@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Ian,

On 05/11/2014 10:24, Ian Campbell wrote:
>> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>
>>           return p2m_cache_flush(d, s, e);
>>       }
>> +    case XEN_DOMCTL_arm_configure_domain:
>> +    {
>> +        uint8_t gic_version;
>> +
>> +        /*
>> +         * Xen 4.5: The vGIC is emulating the same version of the
>
> No need to say "Xen 4.5" here, this comment is true until it is removed.
> You could say "Currently the vGIC is..." or something if you wanted to
> indicate that this is temporary.

Just saying temporary doesn't say anything about when this has been 
added and will be removed.

"Xen 4.5" gives explicitly the time and show that we want to remove soon.

>
>> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
>> +         * is allowed. The DOMCTL will return the actual version of the
>> +         * GIC.
>> +         */
>> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
>> +            return -EOPNOTSUPP;

> I'm also tempted to suggest that we should accept gic_version == the hw
> value, i.e. by moping the switch below up and including
>          && domctl->u.configuredomain.gic_version != gic_version
> in the condition.

I consider that explicitly asking for a version of the GIC in Xen 4.5 is 
invalid. The user should only be able to use the default GIC.

As the DOMCTL is not set in stone, the developer should not start to 
consider that XEN_DOMCTL_CONFIG_GIC_V{2,3} will be valid in the future.

>> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */
>
> Don't we only support 8 cpus today? I don't mind reserving space for
> more, and I'd be pleasantly surprised if 16 actually worked ;-)

I just copied used the code of Vijay. I suspect we could easily bump the 
number supported VCPUs to 16. But I didn't test it.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:10:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:10:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyTd-0004yO-Qq; Wed, 05 Nov 2014 11:10:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlyTc-0004yI-HX
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:10:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7D/9A-24532-3950A545; Wed, 05 Nov 2014 11:10:11 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415185810!12937148!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17518 invoked from network); 5 Nov 2014 11:10:10 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:10:10 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so1633818wib.13
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 03:10:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=0ppLcMn2Nqj/woTFhr5WAlg1LocpEtkXJ31cqB0Npmg=;
	b=iasm/tgsHHLqDh3gZ/B7R2wpyukDO3br8iHlTWYeFawxSUA5SHIfTtF659aYcApENH
	m6srFvTBZbGbQ+mkFXf7eI8UtI8N67jW/GzJsI3T4NHO6pBsTqemsjxRYHwSjB6YZUCa
	psfAu53/I9ZGP9sctpHz6uo/H3i9Fs7fmOdiyh6XeXR5iTozORUtASmf3FfsRsBmo9G1
	y7/M2gxVPJ3Y1lGeCZgOyzvv6Nci/1jcGyjLTOr+QQn13NM2xvN6HMkd59NFmyr9A3KX
	r2Xn6V/E9eYUnkT600+c5ML4fMpDjLWkyhtz2KSOmWhDqSAiWcHdiHOJCeJdKRwVcYWm
	iu+w==
X-Gm-Message-State: ALoCoQlOTakFaFA8T2e6ENS6F1FKag2vCcJE5a5fZnU6pQYfY7jzRb/VcLPoDz807mGtkkZ+mNEd
X-Received: by 10.180.80.39 with SMTP id o7mr4728583wix.37.1415185809754;
	Wed, 05 Nov 2014 03:10:09 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id y5sm15061110wix.9.2014.11.05.03.10.08
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 05 Nov 2014 03:10:08 -0800 (PST)
Message-ID: <545A058F.5040603@linaro.org>
Date: Wed, 05 Nov 2014 11:10:07 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com>
In-Reply-To: <1415183041.11486.74.camel@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Ian,

On 05/11/2014 10:24, Ian Campbell wrote:
>> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>
>>           return p2m_cache_flush(d, s, e);
>>       }
>> +    case XEN_DOMCTL_arm_configure_domain:
>> +    {
>> +        uint8_t gic_version;
>> +
>> +        /*
>> +         * Xen 4.5: The vGIC is emulating the same version of the
>
> No need to say "Xen 4.5" here, this comment is true until it is removed.
> You could say "Currently the vGIC is..." or something if you wanted to
> indicate that this is temporary.

Just saying temporary doesn't say anything about when this has been 
added and will be removed.

"Xen 4.5" gives explicitly the time and show that we want to remove soon.

>
>> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
>> +         * is allowed. The DOMCTL will return the actual version of the
>> +         * GIC.
>> +         */
>> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
>> +            return -EOPNOTSUPP;

> I'm also tempted to suggest that we should accept gic_version == the hw
> value, i.e. by moping the switch below up and including
>          && domctl->u.configuredomain.gic_version != gic_version
> in the condition.

I consider that explicitly asking for a version of the GIC in Xen 4.5 is 
invalid. The user should only be able to use the default GIC.

As the DOMCTL is not set in stone, the developer should not start to 
consider that XEN_DOMCTL_CONFIG_GIC_V{2,3} will be valid in the future.

>> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU15 */
>
> Don't we only support 8 cpus today? I don't mind reserving space for
> more, and I'd be pleasantly surprised if 16 actually worked ;-)

I just copied used the code of Vijay. I suspect we could easily bump the 
number supported VCPUs to 16. But I didn't test it.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:17:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlyaj-0005FJ-Sv; Wed, 05 Nov 2014 11:17:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Xlyai-0005FC-TW
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:17:33 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	13/28-27785-C470A545; Wed, 05 Nov 2014 11:17:32 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415186251!12694989!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32612 invoked from network); 5 Nov 2014 11:17:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:17:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="26530544"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, David Vrabel
	<david.vrabel@citrix.com>
Thread-Topic: [PATCHv2 net-next] xen-netback: remove unconditional
	__pskb_pull_tail() in guest Tx path
Thread-Index: AQHP+OZm7HxwosuFOE6Js6RlOKbaTpxRzJcAgAAUm/A=
Date: Wed, 5 Nov 2014 11:17:30 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
In-Reply-To: <1415185172.15200.0.camel@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 05 November 2014 11:00
> To: David Vrabel
> Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul Durrant
> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> __pskb_pull_tail() in guest Tx path
> 
> Dropping netdev since this isn't relevant to them, adding Paul
> 
> On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> > - performance: Netback has already grant copied up-to 128 bytes from
> >   the first slot of a packet into the linear area. The first slot
> >   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> 
> Does "normally" include guests other than Linux? I thought Windows in
> particular was prone to splitting the headers into a frag per layer or
> thereabouts?
> 

Current upstream Windows PV drivers will put all parsed headers in the first frag and the rest of the packet in subsequent flags. The parser currently knows about TCP and UDP over IPv4 or v6, with and without SNAP encapsulation. It doesn't, for example, know about ARP so the backend will see only the ethernet header in the first frag.

  Paul

> Ian
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:17:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlyaj-0005FJ-Sv; Wed, 05 Nov 2014 11:17:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Xlyai-0005FC-TW
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:17:33 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	13/28-27785-C470A545; Wed, 05 Nov 2014 11:17:32 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415186251!12694989!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32612 invoked from network); 5 Nov 2014 11:17:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:17:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="26530544"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, David Vrabel
	<david.vrabel@citrix.com>
Thread-Topic: [PATCHv2 net-next] xen-netback: remove unconditional
	__pskb_pull_tail() in guest Tx path
Thread-Index: AQHP+OZm7HxwosuFOE6Js6RlOKbaTpxRzJcAgAAUm/A=
Date: Wed, 5 Nov 2014 11:17:30 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
In-Reply-To: <1415185172.15200.0.camel@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 05 November 2014 11:00
> To: David Vrabel
> Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul Durrant
> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> __pskb_pull_tail() in guest Tx path
> 
> Dropping netdev since this isn't relevant to them, adding Paul
> 
> On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> > - performance: Netback has already grant copied up-to 128 bytes from
> >   the first slot of a packet into the linear area. The first slot
> >   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> 
> Does "normally" include guests other than Linux? I thought Windows in
> particular was prone to splitting the headers into a frag per layer or
> thereabouts?
> 

Current upstream Windows PV drivers will put all parsed headers in the first frag and the rest of the packet in subsequent flags. The parser currently knows about TCP and UDP over IPv4 or v6, with and without SNAP encapsulation. It doesn't, for example, know about ARP so the backend will see only the ethernet header in the first frag.

  Paul

> Ian
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:17:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11: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 1Xlyb9-0005IV-95; Wed, 05 Nov 2014 11:17:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlyb7-0005II-7R
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:17:57 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C2/90-02696-4670A545; Wed, 05 Nov 2014 11:17:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415186274!12669426!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17058 invoked from network); 5 Nov 2014 11:17: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;
	5 Nov 2014 11:17:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188265634"
Message-ID: <1415186272.15317.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@linux.com>
Date: Wed, 5 Nov 2014 11:17:52 +0000
In-Reply-To: <20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<21586.10214.683512.296628@chiark.greenend.org.uk>
	<20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org,
	Ian Jackson <ijackson@chiark.greenend.org.uk>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
> I think that we should reduce any burden on the security team by
> making this a community decision that is discussed in public, rather
> than something that is handled exclusively in a closed manner as it is
> today. This way others who are active community participants can help
> with the decision making process can do the investigation and weigh in
> on the risk/benefit tradeoff to the security process and the
> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> or [1] if you are willing to visit a URL. ;-)
> 
> There's been a bit of talk about "delay" and so on. I'd rather not set
> expectations on how long the processing a petition to be added to the
> predisclosure list should take. Building community consensus takes
> time, just as it does for

I think regardless of who is processing the applications what is more
important is to have a concrete set of *objective* criteria. Anyone who
demonstrates that they meet those criteria must be allowed to join.

It reads to me as if you are instead are proposing that the community
apply some sort of subjective standard of risk/benefit tradeoffs and
building consensus about a new membership. I think to take that approach
(whether in public or private) would be against the previous steer from
the community that the list should be fairly widely inclusive -- there
will naturally be a tendency for those already inside the system to be
more conservative about allowing others to join (since it increases
their risk) and so they will tend (not even deliberately) to
overestimate the risk of allowing new memberships.

In the light of the discussions around sharing amongst predisclosure
list members and pre-embargo deployment I think the inclusive nature of
the list is an important balancing factor in the inherent disparity
between distro style consumers and service providers.

If we do not continue take an inclusive approach to the list membership
then my opinion on the matter of sharing and predeploying will be very
different.

>  other activities like getting a patch
> applied. I don't think that this process needs to be different.

I don't think this analogy is useful. It is rare that someone who has
had a patch accepted has any incentive to prevent another essentially
unrelated patch from being applied. Also, many of the reasons for not
taking a patch are subjective (coding style, taste, disagreements about
design issues, 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 Nov 05 11:17:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11: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 1Xlyb9-0005IV-95; Wed, 05 Nov 2014 11:17:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlyb7-0005II-7R
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:17:57 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C2/90-02696-4670A545; Wed, 05 Nov 2014 11:17:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415186274!12669426!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17058 invoked from network); 5 Nov 2014 11:17: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;
	5 Nov 2014 11:17:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188265634"
Message-ID: <1415186272.15317.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@linux.com>
Date: Wed, 5 Nov 2014 11:17:52 +0000
In-Reply-To: <20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<21586.10214.683512.296628@chiark.greenend.org.uk>
	<20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org,
	Ian Jackson <ijackson@chiark.greenend.org.uk>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
> I think that we should reduce any burden on the security team by
> making this a community decision that is discussed in public, rather
> than something that is handled exclusively in a closed manner as it is
> today. This way others who are active community participants can help
> with the decision making process can do the investigation and weigh in
> on the risk/benefit tradeoff to the security process and the
> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> or [1] if you are willing to visit a URL. ;-)
> 
> There's been a bit of talk about "delay" and so on. I'd rather not set
> expectations on how long the processing a petition to be added to the
> predisclosure list should take. Building community consensus takes
> time, just as it does for

I think regardless of who is processing the applications what is more
important is to have a concrete set of *objective* criteria. Anyone who
demonstrates that they meet those criteria must be allowed to join.

It reads to me as if you are instead are proposing that the community
apply some sort of subjective standard of risk/benefit tradeoffs and
building consensus about a new membership. I think to take that approach
(whether in public or private) would be against the previous steer from
the community that the list should be fairly widely inclusive -- there
will naturally be a tendency for those already inside the system to be
more conservative about allowing others to join (since it increases
their risk) and so they will tend (not even deliberately) to
overestimate the risk of allowing new memberships.

In the light of the discussions around sharing amongst predisclosure
list members and pre-embargo deployment I think the inclusive nature of
the list is an important balancing factor in the inherent disparity
between distro style consumers and service providers.

If we do not continue take an inclusive approach to the list membership
then my opinion on the matter of sharing and predeploying will be very
different.

>  other activities like getting a patch
> applied. I don't think that this process needs to be different.

I don't think this analogy is useful. It is rare that someone who has
had a patch accepted has any incentive to prevent another essentially
unrelated patch from being applied. Also, many of the reasons for not
taking a patch are subjective (coding style, taste, disagreements about
design issues, 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 Nov 05 11:20:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlydI-0005XB-1x; Wed, 05 Nov 2014 11:20:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlydG-0005Wy-Q2
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:20:10 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	2D/3D-27785-AE70A545; Wed, 05 Nov 2014 11:20:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415186407!12681545!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7035 invoked from network); 5 Nov 2014 11:20: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;
	5 Nov 2014 11:20:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188266235"
Message-ID: <1415186405.15317.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 5 Nov 2014 11:20:05 +0000
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Malcolm
	Crossley <malcolm.crossley@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 11:17 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 05 November 2014 11:00
> > To: David Vrabel
> > Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul Durrant
> > Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> > __pskb_pull_tail() in guest Tx path
> > 
> > Dropping netdev since this isn't relevant to them, adding Paul
> > 
> > On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> > > - performance: Netback has already grant copied up-to 128 bytes from
> > >   the first slot of a packet into the linear area. The first slot
> > >   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> > 
> > Does "normally" include guests other than Linux? I thought Windows in
> > particular was prone to splitting the headers into a frag per layer or
> > thereabouts?
> > 
> 
> Current upstream Windows PV drivers will put all parsed headers in the
> first frag and the rest of the packet in subsequent flags. The parser
> currently knows about TCP and UDP over IPv4 or v6, with and without
> SNAP encapsulation. It doesn't, for example, know about ARP so the
> backend will see only the ethernet header in the first frag.

Sounds like that is sufficient to reach the "normally" qualification,
thanks.

(I wonder what sort of benefit parsing arp would bring...)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:20:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlydI-0005XB-1x; Wed, 05 Nov 2014 11:20:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlydG-0005Wy-Q2
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:20:10 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	2D/3D-27785-AE70A545; Wed, 05 Nov 2014 11:20:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415186407!12681545!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7035 invoked from network); 5 Nov 2014 11:20: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;
	5 Nov 2014 11:20:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188266235"
Message-ID: <1415186405.15317.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 5 Nov 2014 11:20:05 +0000
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Malcolm
	Crossley <malcolm.crossley@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 11:17 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 05 November 2014 11:00
> > To: David Vrabel
> > Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul Durrant
> > Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> > __pskb_pull_tail() in guest Tx path
> > 
> > Dropping netdev since this isn't relevant to them, adding Paul
> > 
> > On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> > > - performance: Netback has already grant copied up-to 128 bytes from
> > >   the first slot of a packet into the linear area. The first slot
> > >   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> > 
> > Does "normally" include guests other than Linux? I thought Windows in
> > particular was prone to splitting the headers into a frag per layer or
> > thereabouts?
> > 
> 
> Current upstream Windows PV drivers will put all parsed headers in the
> first frag and the rest of the packet in subsequent flags. The parser
> currently knows about TCP and UDP over IPv4 or v6, with and without
> SNAP encapsulation. It doesn't, for example, know about ARP so the
> backend will see only the ethernet header in the first frag.

Sounds like that is sufficient to reach the "normally" qualification,
thanks.

(I wonder what sort of benefit parsing arp would bring...)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:20:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlydz-0005eX-Gw; Wed, 05 Nov 2014 11:20: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 1Xlydx-0005eJ-VL
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:20:54 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	40/EB-02699-5180A545; Wed, 05 Nov 2014 11:20:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415186449!12666101!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8067 invoked from network); 5 Nov 2014 11:20:51 -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;
	5 Nov 2014 11:20:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189664159"
Message-ID: <1415186446.15317.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 5 Nov 2014 11:20:46 +0000
In-Reply-To: <alpine.DEB.2.02.1411051102020.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com>
	<alpine.DEB.2.02.1411051029370.22875@kaball.uk.xensource.com>
	<1415184967.11486.84.camel@citrix.com>
	<alpine.DEB.2.02.1411051102020.22875@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 11:02 +0000, Stefano Stabellini wrote:
> On Wed, 5 Nov 2014, Ian Campbell wrote:
> > On Wed, 2014-11-05 at 10:31 +0000, Stefano Stabellini wrote:
> > > On Wed, 5 Nov 2014, Ian Campbell wrote:
> > > > > +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> > > > > +         * is allowed. The DOMCTL will return the actual version of the
> > > > > +         * GIC.
> > > > > +         */
> > > > > +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> > > > > +            return -EOPNOTSUPP;
> > > > 
> > > > EOPNOTSUPP doesn't seem quite right. EPARM  or EINVAL perhaps?
> > > > 
> > > > I'm also tempted to suggest that we should accept gic_version == the hw
> > > > value, i.e. by moping the switch below up and including
> > > >         && domctl->u.configuredomain.gic_version != gic_version
> > > > in the condition.
> > > 
> > > I suggested to use -EOPNOTSUPP because one day we want to be able to use
> > > this hypercall to choose a specific gic_version for the guest domain,
> > > including gicv2 on gicv3 hardware for example.
> > 
> > Why is EOPNOTSUPP an appropriate error code for that though?
> 
> Because at the moment we don't support this use case? If we did we would
> be OK with the user passing gic_version = 2 for example.

Ah, I suggested separately in the review we should just accept the g/w
version.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:20:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlydz-0005eX-Gw; Wed, 05 Nov 2014 11:20: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 1Xlydx-0005eJ-VL
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:20:54 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	40/EB-02699-5180A545; Wed, 05 Nov 2014 11:20:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415186449!12666101!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8067 invoked from network); 5 Nov 2014 11:20:51 -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;
	5 Nov 2014 11:20:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189664159"
Message-ID: <1415186446.15317.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 5 Nov 2014 11:20:46 +0000
In-Reply-To: <alpine.DEB.2.02.1411051102020.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com>
	<alpine.DEB.2.02.1411051029370.22875@kaball.uk.xensource.com>
	<1415184967.11486.84.camel@citrix.com>
	<alpine.DEB.2.02.1411051102020.22875@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 11:02 +0000, Stefano Stabellini wrote:
> On Wed, 5 Nov 2014, Ian Campbell wrote:
> > On Wed, 2014-11-05 at 10:31 +0000, Stefano Stabellini wrote:
> > > On Wed, 5 Nov 2014, Ian Campbell wrote:
> > > > > +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> > > > > +         * is allowed. The DOMCTL will return the actual version of the
> > > > > +         * GIC.
> > > > > +         */
> > > > > +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> > > > > +            return -EOPNOTSUPP;
> > > > 
> > > > EOPNOTSUPP doesn't seem quite right. EPARM  or EINVAL perhaps?
> > > > 
> > > > I'm also tempted to suggest that we should accept gic_version == the hw
> > > > value, i.e. by moping the switch below up and including
> > > >         && domctl->u.configuredomain.gic_version != gic_version
> > > > in the condition.
> > > 
> > > I suggested to use -EOPNOTSUPP because one day we want to be able to use
> > > this hypercall to choose a specific gic_version for the guest domain,
> > > including gicv2 on gicv3 hardware for example.
> > 
> > Why is EOPNOTSUPP an appropriate error code for that though?
> 
> Because at the moment we don't support this use case? If we did we would
> be OK with the user passing gic_version = 2 for example.

Ah, I suggested separately in the review we should just accept the g/w
version.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:23:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlyg3-0005uR-0u; Wed, 05 Nov 2014 11:23:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlyg0-0005uM-LF
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:23:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1C/06-09936-4980A545; Wed, 05 Nov 2014 11:23:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415186578!12864055!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8947 invoked from network); 5 Nov 2014 11:22:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:22:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189664528"
Message-ID: <1415186575.15317.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 5 Nov 2014 11:22:55 +0000
In-Reply-To: <545A058F.5040603@linaro.org>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com> <545A058F.5040603@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 11:10 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 05/11/2014 10:24, Ian Campbell wrote:
> >> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >>
> >>           return p2m_cache_flush(d, s, e);
> >>       }
> >> +    case XEN_DOMCTL_arm_configure_domain:
> >> +    {
> >> +        uint8_t gic_version;
> >> +
> >> +        /*
> >> +         * Xen 4.5: The vGIC is emulating the same version of the
> >
> > No need to say "Xen 4.5" here, this comment is true until it is removed.
> > You could say "Currently the vGIC is..." or something if you wanted to
> > indicate that this is temporary.
> 
> Just saying temporary doesn't say anything about when this has been 
> added and will be removed.
> 
> "Xen 4.5" gives explicitly the time and show that we want to remove soon.

Neither of which things belong in the code comment IMHO. Either this
happens soon so it is moot, or it doesn't and we have a strange
misleading comment...

> >
> >> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> >> +         * is allowed. The DOMCTL will return the actual version of the
> >> +         * GIC.
> >> +         */
> >> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> >> +            return -EOPNOTSUPP;
> 
> > I'm also tempted to suggest that we should accept gic_version == the hw
> > value, i.e. by moping the switch below up and including
> >          && domctl->u.configuredomain.gic_version != gic_version
> > in the condition.
> 
> I consider that explicitly asking for a version of the GIC in Xen 4.5 is 
> invalid. The user should only be able to use the default GIC.
> 
> As the DOMCTL is not set in stone, 

I disagree with your reasoning, but given this I'm not inclined to keep
arguing about 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 Nov 05 11:23:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlyg3-0005uR-0u; Wed, 05 Nov 2014 11:23:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlyg0-0005uM-LF
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:23:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1C/06-09936-4980A545; Wed, 05 Nov 2014 11:23:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415186578!12864055!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8947 invoked from network); 5 Nov 2014 11:22:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:22:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189664528"
Message-ID: <1415186575.15317.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 5 Nov 2014 11:22:55 +0000
In-Reply-To: <545A058F.5040603@linaro.org>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<1415183041.11486.74.camel@citrix.com> <545A058F.5040603@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 11:10 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 05/11/2014 10:24, Ian Campbell wrote:
> >> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >>
> >>           return p2m_cache_flush(d, s, e);
> >>       }
> >> +    case XEN_DOMCTL_arm_configure_domain:
> >> +    {
> >> +        uint8_t gic_version;
> >> +
> >> +        /*
> >> +         * Xen 4.5: The vGIC is emulating the same version of the
> >
> > No need to say "Xen 4.5" here, this comment is true until it is removed.
> > You could say "Currently the vGIC is..." or something if you wanted to
> > indicate that this is temporary.
> 
> Just saying temporary doesn't say anything about when this has been 
> added and will be removed.
> 
> "Xen 4.5" gives explicitly the time and show that we want to remove soon.

Neither of which things belong in the code comment IMHO. Either this
happens soon so it is moot, or it doesn't and we have a strange
misleading comment...

> >
> >> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> >> +         * is allowed. The DOMCTL will return the actual version of the
> >> +         * GIC.
> >> +         */
> >> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> >> +            return -EOPNOTSUPP;
> 
> > I'm also tempted to suggest that we should accept gic_version == the hw
> > value, i.e. by moping the switch below up and including
> >          && domctl->u.configuredomain.gic_version != gic_version
> > in the condition.
> 
> I consider that explicitly asking for a version of the GIC in Xen 4.5 is 
> invalid. The user should only be able to use the default GIC.
> 
> As the DOMCTL is not set in stone, 

I disagree with your reasoning, but given this I'm not inclined to keep
arguing about 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 Nov 05 11:24:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:24:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyhJ-00063P-Gs; Wed, 05 Nov 2014 11:24:21 +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 1XlyhH-00063H-W7
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:24:20 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	CE/29-11581-3E80A545; Wed, 05 Nov 2014 11:24:19 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415186657!11323253!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32651 invoked from network); 5 Nov 2014 11:24:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:24:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="26530757"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [PATCHv2 net-next] xen-netback: remove unconditional
	__pskb_pull_tail() in guest Tx path
Thread-Index: AQHP+OZm7HxwosuFOE6Js6RlOKbaTpxRzJcAgAAUm/D///EjgIAAEP8A
Date: Wed, 5 Nov 2014 11:24:16 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
	<1415186405.15317.6.camel@citrix.com>
In-Reply-To: <1415186405.15317.6.camel@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Malcolm
	Crossley <malcolm.crossley@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 05 November 2014 11:20
> To: Paul Durrant
> Cc: David Vrabel; xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley
> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> __pskb_pull_tail() in guest Tx path
> 
> On Wed, 2014-11-05 at 11:17 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 05 November 2014 11:00
> > > To: David Vrabel
> > > Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul
> Durrant
> > > Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> > > __pskb_pull_tail() in guest Tx path
> > >
> > > Dropping netdev since this isn't relevant to them, adding Paul
> > >
> > > On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> > > > - performance: Netback has already grant copied up-to 128 bytes from
> > > >   the first slot of a packet into the linear area. The first slot
> > > >   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> > >
> > > Does "normally" include guests other than Linux? I thought Windows in
> > > particular was prone to splitting the headers into a frag per layer or
> > > thereabouts?
> > >
> >
> > Current upstream Windows PV drivers will put all parsed headers in the
> > first frag and the rest of the packet in subsequent flags. The parser
> > currently knows about TCP and UDP over IPv4 or v6, with and without
> > SNAP encapsulation. It doesn't, for example, know about ARP so the
> > backend will see only the ethernet header in the first frag.
> 
> Sounds like that is sufficient to reach the "normally" qualification,
> thanks.
> 
> (I wonder what sort of benefit parsing arp would bring...)
> 

Previous versions of the drivers used to parse ARPs so that copies of outgoing gratuitous ARPs could be cached for replay after migrate. Newer drivers acquire IP address bindings from the Windows IP helper (which is now available in kernel) and synthesize ARPs/IPv6 neighbour solicitations.

  Paul

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:24:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:24:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlyhJ-00063P-Gs; Wed, 05 Nov 2014 11:24:21 +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 1XlyhH-00063H-W7
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:24:20 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	CE/29-11581-3E80A545; Wed, 05 Nov 2014 11:24:19 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415186657!11323253!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32651 invoked from network); 5 Nov 2014 11:24:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:24:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="26530757"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [PATCHv2 net-next] xen-netback: remove unconditional
	__pskb_pull_tail() in guest Tx path
Thread-Index: AQHP+OZm7HxwosuFOE6Js6RlOKbaTpxRzJcAgAAUm/D///EjgIAAEP8A
Date: Wed, 5 Nov 2014 11:24:16 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
	<1415186405.15317.6.camel@citrix.com>
In-Reply-To: <1415186405.15317.6.camel@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Malcolm
	Crossley <malcolm.crossley@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 05 November 2014 11:20
> To: Paul Durrant
> Cc: David Vrabel; xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley
> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> __pskb_pull_tail() in guest Tx path
> 
> On Wed, 2014-11-05 at 11:17 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 05 November 2014 11:00
> > > To: David Vrabel
> > > Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul
> Durrant
> > > Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> > > __pskb_pull_tail() in guest Tx path
> > >
> > > Dropping netdev since this isn't relevant to them, adding Paul
> > >
> > > On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> > > > - performance: Netback has already grant copied up-to 128 bytes from
> > > >   the first slot of a packet into the linear area. The first slot
> > > >   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> > >
> > > Does "normally" include guests other than Linux? I thought Windows in
> > > particular was prone to splitting the headers into a frag per layer or
> > > thereabouts?
> > >
> >
> > Current upstream Windows PV drivers will put all parsed headers in the
> > first frag and the rest of the packet in subsequent flags. The parser
> > currently knows about TCP and UDP over IPv4 or v6, with and without
> > SNAP encapsulation. It doesn't, for example, know about ARP so the
> > backend will see only the ethernet header in the first frag.
> 
> Sounds like that is sufficient to reach the "normally" qualification,
> thanks.
> 
> (I wonder what sort of benefit parsing arp would bring...)
> 

Previous versions of the drivers used to parse ARPs so that copies of outgoing gratuitous ARPs could be cached for replay after migrate. Newer drivers acquire IP address bindings from the Windows IP helper (which is now available in kernel) and synthesize ARPs/IPv6 neighbour solicitations.

  Paul

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:28:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlylU-0006Lk-81; Wed, 05 Nov 2014 11:28:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlylS-0006Lf-K2
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:28:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	62/81-24532-6E90A545; Wed, 05 Nov 2014 11:28:38 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415186917!12910988!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7609 invoked from network); 5 Nov 2014 11:28:37 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:28:37 -0000
Received: by mail-wi0-f173.google.com with SMTP id n3so12098877wiv.12
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 03:28:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=7+9dMrtj6kDw+hGqFxkLipbCuQLgBIB+eDLRrXdXMQQ=;
	b=hLb/q6zDVXyusJGyS523am6ZveMNMcsfKHYGuTUcShdq729X2ZezFCVbW2fbFsvwcp
	iiY1Hheiwxn8WGY9dx/wVyQQpGmasAidzI6SP8WRYJmOopv2ZVZ4RYh+Q/aU0ZwXYi8N
	D6xaf3MXbIzgyIXUwQvhV8il+z4qMdSzbs3tFoNPuknCH5tRikypTwJcM2bN2KXSjSTx
	mxFBPOPH9apPvWt8dB5v7cjmasQ0CAqico5pCP0UrPqI3K2Jf+STlfbFiCEcJrmL3bkb
	QQ3PnI3PdvWJzL6ifMN0ViliumNC3+e8l3pfMZHts14soYy4T9U0lauFuNYdZwHSoTgV
	beGg==
X-Gm-Message-State: ALoCoQmEOdW/v8iIPiSyn7XPf1eakGkFanv02mNLKBiika8u6ayzHWR2rYGw7jdsc10klX9HD8OV
X-Received: by 10.180.84.198 with SMTP id b6mr31845050wiz.41.1415186917150;
	Wed, 05 Nov 2014 03:28:37 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id u8sm3777833wjq.1.2014.11.05.03.28.35
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 05 Nov 2014 03:28:36 -0800 (PST)
Message-ID: <545A09E2.3090408@linaro.org>
Date: Wed, 05 Nov 2014 11:28:34 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>	
	<1415183041.11486.74.camel@citrix.com>
	<545A058F.5040603@linaro.org> <1415186575.15317.9.camel@citrix.com>
In-Reply-To: <1415186575.15317.9.camel@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 05/11/2014 11:22, Ian Campbell wrote:
>>>
>>>> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
>>>> +         * is allowed. The DOMCTL will return the actual version of the
>>>> +         * GIC.
>>>> +         */
>>>> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
>>>> +            return -EOPNOTSUPP;
>>
>>> I'm also tempted to suggest that we should accept gic_version == the hw
>>> value, i.e. by moping the switch below up and including
>>>           && domctl->u.configuredomain.gic_version != gic_version
>>> in the condition.
>>
>> I consider that explicitly asking for a version of the GIC in Xen 4.5 is
>> invalid. The user should only be able to use the default GIC.
>>
>> As the DOMCTL is not set in stone,
>
> I disagree with your reasoning, but given this I'm not inclined to keep
> arguing about it.

TBH, I should just ignore the value for Xen 4.5 and let the hypervisor 
return the version of the vGIC.

The check was just here to explicitly show that we don't support 
anything else in DOM0.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:28:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlylU-0006Lk-81; Wed, 05 Nov 2014 11:28:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XlylS-0006Lf-K2
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 11:28:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	62/81-24532-6E90A545; Wed, 05 Nov 2014 11:28:38 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415186917!12910988!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7609 invoked from network); 5 Nov 2014 11:28:37 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:28:37 -0000
Received: by mail-wi0-f173.google.com with SMTP id n3so12098877wiv.12
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 03:28:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=7+9dMrtj6kDw+hGqFxkLipbCuQLgBIB+eDLRrXdXMQQ=;
	b=hLb/q6zDVXyusJGyS523am6ZveMNMcsfKHYGuTUcShdq729X2ZezFCVbW2fbFsvwcp
	iiY1Hheiwxn8WGY9dx/wVyQQpGmasAidzI6SP8WRYJmOopv2ZVZ4RYh+Q/aU0ZwXYi8N
	D6xaf3MXbIzgyIXUwQvhV8il+z4qMdSzbs3tFoNPuknCH5tRikypTwJcM2bN2KXSjSTx
	mxFBPOPH9apPvWt8dB5v7cjmasQ0CAqico5pCP0UrPqI3K2Jf+STlfbFiCEcJrmL3bkb
	QQ3PnI3PdvWJzL6ifMN0ViliumNC3+e8l3pfMZHts14soYy4T9U0lauFuNYdZwHSoTgV
	beGg==
X-Gm-Message-State: ALoCoQmEOdW/v8iIPiSyn7XPf1eakGkFanv02mNLKBiika8u6ayzHWR2rYGw7jdsc10klX9HD8OV
X-Received: by 10.180.84.198 with SMTP id b6mr31845050wiz.41.1415186917150;
	Wed, 05 Nov 2014 03:28:37 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id u8sm3777833wjq.1.2014.11.05.03.28.35
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 05 Nov 2014 03:28:36 -0800 (PST)
Message-ID: <545A09E2.3090408@linaro.org>
Date: Wed, 05 Nov 2014 11:28:34 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>	
	<1415183041.11486.74.camel@citrix.com>
	<545A058F.5040603@linaro.org> <1415186575.15317.9.camel@citrix.com>
In-Reply-To: <1415186575.15317.9.camel@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 05/11/2014 11:22, Ian Campbell wrote:
>>>
>>>> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
>>>> +         * is allowed. The DOMCTL will return the actual version of the
>>>> +         * GIC.
>>>> +         */
>>>> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
>>>> +            return -EOPNOTSUPP;
>>
>>> I'm also tempted to suggest that we should accept gic_version == the hw
>>> value, i.e. by moping the switch below up and including
>>>           && domctl->u.configuredomain.gic_version != gic_version
>>> in the condition.
>>
>> I consider that explicitly asking for a version of the GIC in Xen 4.5 is
>> invalid. The user should only be able to use the default GIC.
>>
>> As the DOMCTL is not set in stone,
>
> I disagree with your reasoning, but given this I'm not inclined to keep
> arguing about it.

TBH, I should just ignore the value for Xen 4.5 and let the hypervisor 
return the version of the vGIC.

The check was just here to explicitly show that we don't support 
anything else in DOM0.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:44:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:44:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlz0b-0006ur-9i; Wed, 05 Nov 2014 11:44:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xlz0Z-0006ui-W3
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 11:44:16 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	74/C1-22777-F8D0A545; Wed, 05 Nov 2014 11:44:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415187853!6044252!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18858 invoked from network); 5 Nov 2014 11:44:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:44:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189668662"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 06:44:12 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlyzU-0006Oh-CS;
	Wed, 05 Nov 2014 11:43:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlyzU-0007Fq-36;
	Wed, 05 Nov 2014 11:43:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21594.3403.761882.940904@mariner.uk.xensource.com>
Date: Wed, 5 Nov 2014 11:43:07 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1415184084-14650-1-git-send-email-ian.campbell@citrix.com>
References: <1415184084-14650-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST] standalone: Handle multiple
	configuration files.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH OSSTEST] standalone: Handle multiple configuration files."):
> OSSTEST_CONFIG can actually be a colon separate list of files, so take this
> into account when sanity checking it.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:44:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:44:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlz0b-0006ur-9i; Wed, 05 Nov 2014 11:44:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xlz0Z-0006ui-W3
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 11:44:16 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	74/C1-22777-F8D0A545; Wed, 05 Nov 2014 11:44:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415187853!6044252!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18858 invoked from network); 5 Nov 2014 11:44:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:44:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189668662"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 06:44:12 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlyzU-0006Oh-CS;
	Wed, 05 Nov 2014 11:43:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlyzU-0007Fq-36;
	Wed, 05 Nov 2014 11:43:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21594.3403.761882.940904@mariner.uk.xensource.com>
Date: Wed, 5 Nov 2014 11:43:07 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1415184084-14650-1-git-send-email-ian.campbell@citrix.com>
References: <1415184084-14650-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST] standalone: Handle multiple
	configuration files.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH OSSTEST] standalone: Handle multiple configuration files."):
> OSSTEST_CONFIG can actually be a colon separate list of files, so take this
> into account when sanity checking it.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 11:57:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlzDL-0007JV-S7; Wed, 05 Nov 2014 11:57:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlzDK-0007JQ-J7
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 11:57:26 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	5F/39-03145-5A01A545; Wed, 05 Nov 2014 11:57:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415188643!12680044!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11054 invoked from network); 5 Nov 2014 11:57:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:57:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188273542"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 06:57:22 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlzDG-0004Kw-9N;
	Wed, 05 Nov 2014 11:57:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlzDG-0004cH-2Z;
	Wed, 05 Nov 2014 11:57:22 +0000
Date: Wed, 5 Nov 2014 11:57:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31379-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31379: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31379 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31379/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd  7 redhat-install    fail like 28935-bisect
 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 leak-check/check fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 05 11:57:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 11:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlzDL-0007JV-S7; Wed, 05 Nov 2014 11:57:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XlzDK-0007JQ-J7
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 11:57:26 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	5F/39-03145-5A01A545; Wed, 05 Nov 2014 11:57:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415188643!12680044!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11054 invoked from network); 5 Nov 2014 11:57:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 11:57:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188273542"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 06:57:22 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XlzDG-0004Kw-9N;
	Wed, 05 Nov 2014 11:57:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XlzDG-0004cH-2Z;
	Wed, 05 Nov 2014 11:57:22 +0000
Date: Wed, 5 Nov 2014 11:57:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31379-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31379: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31379 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31379/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd  7 redhat-install    fail like 28935-bisect
 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 leak-check/check fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 05 12:01:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 12:01:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlzH7-0007X6-1i; Wed, 05 Nov 2014 12:01:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XlzH5-0007Wy-4R
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 12:01:19 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	34/F5-28865-D811A545; Wed, 05 Nov 2014 12:01:17 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415188876!3757187!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27825 invoked from network); 5 Nov 2014 12:01:16 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 12:01:16 -0000
Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlzH0-0005tB-C3; Wed, 05 Nov 2014 13:01:14 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.64])
	by justin.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlzGz-00087k-Hk; Wed, 05 Nov 2014 13:01:14 +0100
Message-ID: <545A118B.7040309@web2web.at>
Date: Wed, 05 Nov 2014 13:01:15 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>					<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>				<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>			
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>		
	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>	
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
	<1415180713.11486.61.camel@citrix.com>
In-Reply-To: <1415180713.11486.61.camel@citrix.com>
Content-Type: multipart/mixed; boundary="------------000605000609080501090206"
X-Univie-Virus-Scan: scanned by ClamAV on justin.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------000605000609080501090206
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Am 05.11.14 um 10:45 schrieb Ian Campbell:
> On Tue, 2014-11-04 at 18:30 +0100, Atom2 wrote:
>> Am 04.11.14 um 17:31 schrieb Ian Campbell:
>>> On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
>>>> Am 04.11.14 um 16:44 schrieb Ian Campbell:
>>>>> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
> Sadly it looks like your version of valgrind doesn't know how to handle
> the hypercalls made by the Xen toolstack, which means it produces a lot
> of unrelated noise.
>
> You seem to be using valgrind 3.9.0, which lacked knowledge of some of
> the HVM related hypercalls that weren't added until 3.10.0. It's
> probably not worth pursuing this angle any further (unless it is utterly
> trivial to pull in the new version).
Many thanks again for your quick answers.

You were right, I used valgrind-3.9.0 which is the latest stable version 
for gentoo. 3.10.0 is available under unstable and it was indeed trivial 
to pull that in instead. The unrelated noise seems to have disappeared, 
so attached please find the output of running
	# valgrindd xl create -F -c pfsense

The strange thing was: No segfault at the start, but obviously also 
issues with passing through the PCI devices as evidenced by the same 
error messages you flagged below. Also the boot menu now showed up and I 
was able to boot the domain - but, as expected by the error message, no 
network devices have been passed through. Even a

	# xl shutdown -F pfsense
	Shutting down domain 2
	PV control interface not available: sending ACPI power button event.
	#

from another ssh connection to dom0 worked (no segfault message in that 
session) and as such the attached file 'valgrind.out' contains the 
complete screen output of the valgrind session from start to finnish. 
However, towards the end of that file (line 235) you'll see a SEGFAULT 
message from valgrind. I hope you can make some sense out of that ... or 
should I rerun with some options to valgrind (like the ones mentioned in 
the output):
	--leak-check=full
	-v

To me, it looks as if something is broken with the PCI passthrough stuff 
and that has started with 4.3.3. Strangely however, valgrind seems to 
work around that issue insofar that no segfault happens. Is there any 
explanation of the different behaviour between native execution of xl 
and starting xl under valgrind's control?

In any case, I am positive that there hasn't been any change to the 
hardware of the system, not even a slot change of an add-on card. So I 
have no clue why the system after the upgrade misbehaves.
>
> Apart from the valgrind output there is a new message from libxl:
>          libxl: error: libxl_pci.c:1045:libxl__device_pci_add: PCI device 0000:04:00.0 cannot be assigned - no IOMMU?
> which suggests that it isn't passing things through (this might be
> fallout from valgrind not understanding things) and no segfault.
>
> OOI what does "xl create -F ..." do without valgrind (I'm wondering if
> -F is responsible for the change in behaviour).
I tried that as well:

	vm-host auto [526] # xl create -F -c pfsense
	Parsing config from pfsense
	xc: info: VIRTUAL MEMORY ARRANGEMENT:
	  Loader:        0000000000100000->00000000001c12a4
	  Modules:       0000000000000000->0000000000000000
	  TOTAL:         0000000000000000->000000001f800000
	  ENTRY ADDRESS: 0000000000100000
	xc: info: PHYSICAL MEMORY ALLOCATION:
	  4KB PAGES: 0x0000000000000200
	  2MB PAGES: 0x00000000000000fb
	  1GB PAGES: 0x0000000000000000
	Segmentation fault
	vm-host auto [527] # xl list
	Name                        ID   Mem VCPUs      State   Time(s)
	Domain-0                     0  4094     8     r-----     451.5
	pfsense                      1   512     1     --p---       0.0
	vm-host auto [528] # xl destroy pfsense
	Segmentation fault
	vm-host auto [529] # xl list
	Name                        ID   Mem VCPUs      State   Time(s)
	Domain-0                     0  4096     8     r-----     452.1
	vm-host auto [529] #

and, as you can see, again had the segfault and the same status of the 
domU as back at the time when the issues started (i.e. paused - which 
you explained as being normal after a start).

Thanks Atom2

--------------000605000609080501090206
Content-Type: text/plain; charset=windows-1252;
 name="valgrind.out"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="valgrind.out"

dm0taG9zdCBhdXRvIFs1NDBdICMgdmFsZ3JpbmQgeGwgY3JlYXRlIC1GIC1jIHBmc2Vuc2UK
PT0yNDk4Mj09IE1lbWNoZWNrLCBhIG1lbW9yeSBlcnJvciBkZXRlY3Rvcgo9PTI0OTgyPT0g
Q29weXJpZ2h0IChDKSAyMDAyLTIwMTMsIGFuZCBHTlUgR1BMJ2QsIGJ5IEp1bGlhbiBTZXdh
cmQgZXQgYWwuCj09MjQ5ODI9PSBVc2luZyBWYWxncmluZC0zLjEwLjAgYW5kIExpYlZFWDsg
cmVydW4gd2l0aCAtaCBmb3IgY29weXJpZ2h0IGluZm8KPT0yNDk4Mj09IENvbW1hbmQ6IHhs
IGNyZWF0ZSAtRiAtYyBwZnNlbnNlCj09MjQ5ODI9PQpQYXJzaW5nIGNvbmZpZyBmcm9tIHBm
c2Vuc2UKLS0yNDk4Mi0tIFdBUk5JTkc6IHVuaGFuZGxlZCBfX0hZUEVSVklTT1JfZG9tY3Rs
IHNoYWRvdygxMCkgc3Vib3A6IDMxCi0tMjQ5ODItLSBZb3UgbWF5IGJlIGFibGUgdG8gd3Jp
dGUgeW91ciBvd24gaGFuZGxlci4KLS0yNDk4Mi0tIFJlYWQgdGhlIGZpbGUgUkVBRE1FX01J
U1NJTkdfU1lTQ0FMTF9PUl9JT0NUTC4KLS0yNDk4Mi0tIE5ldmVydGhlbGVzcyB3ZSBjb25z
aWRlciB0aGlzIGEgYnVnLiAgUGxlYXNlIHJlcG9ydAotLTI0OTgyLS0gaXQgYXQgaHR0cDov
L3ZhbGdyaW5kLm9yZy9zdXBwb3J0L2J1Z19yZXBvcnRzLmh0bWwgJgotLTI0OTgyLS0gaHR0
cDovL3dpa2kueGVuLm9yZy93aWtpL1JlcG9ydGluZ19CdWdzX2FnYWluc3RfWGVuLgp4Yzog
aW5mbzogVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6CiAgTG9hZGVyOiAgICAgICAgMDAw
MDAwMDAwMDEwMDAwMC0+MDAwMDAwMDAwMDFjMTJhNAogIE1vZHVsZXM6ICAgICAgIDAwMDAw
MDAwMDAwMDAwMDAtPjAwMDAwMDAwMDAwMDAwMDAKICBUT1RBTDogICAgICAgICAwMDAwMDAw
MDAwMDAwMDAwLT4wMDAwMDAwMDFmODAwMDAwCiAgRU5UUlkgQUREUkVTUzogMDAwMDAwMDAw
MDEwMDAwMAp4YzogaW5mbzogUEhZU0lDQUwgTUVNT1JZIEFMTE9DQVRJT046CiAgNEtCIFBB
R0VTOiAweDAwMDAwMDAwMDAwMDAyMDAKICAyTUIgUEFHRVM6IDB4MDAwMDAwMDAwMDAwMDBm
YgogIDFHQiBQQUdFUzogMHgwMDAwMDAwMDAwMDAwMDAwCi0tMjQ5ODItLSBXQVJOSU5HOiB1
bmhhbmRsZWQgX19IWVBFUlZJU09SX2RvbWN0bCBzdWJvcDogNDUKLS0yNDk4Mi0tIFlvdSBt
YXkgYmUgYWJsZSB0byB3cml0ZSB5b3VyIG93biBoYW5kbGVyLgotLTI0OTgyLS0gUmVhZCB0
aGUgZmlsZSBSRUFETUVfTUlTU0lOR19TWVNDQUxMX09SX0lPQ1RMLgotLTI0OTgyLS0gTmV2
ZXJ0aGVsZXNzIHdlIGNvbnNpZGVyIHRoaXMgYSBidWcuICBQbGVhc2UgcmVwb3J0Ci0tMjQ5
ODItLSBpdCBhdCBodHRwOi8vdmFsZ3JpbmQub3JnL3N1cHBvcnQvYnVnX3JlcG9ydHMuaHRt
bCAmCi0tMjQ5ODItLSBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvUmVwb3J0aW5nX0J1Z3Nf
YWdhaW5zdF9YZW4uCmxpYnhsOiBlcnJvcjogbGlieGxfcGNpLmM6MTA0NTpsaWJ4bF9fZGV2
aWNlX3BjaV9hZGQ6IFBDSSBkZXZpY2UgMDAwMDowNDowMC4wIGNhbm5vdCBiZSBhc3NpZ25l
ZCAtIG5vIElPTU1VPwotLTI0OTgyLS0gV0FSTklORzogdW5oYW5kbGVkIF9fSFlQRVJWSVNP
Ul9kb21jdGwgc3Vib3A6IDQ1Ci0tMjQ5ODItLSBZb3UgbWF5IGJlIGFibGUgdG8gd3JpdGUg
eW91ciBvd24gaGFuZGxlci4KLS0yNDk4Mi0tIFJlYWQgdGhlIGZpbGUgUkVBRE1FX01JU1NJ
TkdfU1lTQ0FMTF9PUl9JT0NUTC4KLS0yNDk4Mi0tIE5ldmVydGhlbGVzcyB3ZSBjb25zaWRl
ciB0aGlzIGEgYnVnLiAgUGxlYXNlIHJlcG9ydAotLTI0OTgyLS0gaXQgYXQgaHR0cDovL3Zh
bGdyaW5kLm9yZy9zdXBwb3J0L2J1Z19yZXBvcnRzLmh0bWwgJgotLTI0OTgyLS0gaHR0cDov
L3dpa2kueGVuLm9yZy93aWtpL1JlcG9ydGluZ19CdWdzX2FnYWluc3RfWGVuLgpsaWJ4bDog
ZXJyb3I6IGxpYnhsX3BjaS5jOjEwNDU6bGlieGxfX2RldmljZV9wY2lfYWRkOiBQQ0kgZGV2
aWNlIDAwMDA6MGE6MDguMCBjYW5ub3QgYmUgYXNzaWduZWQgLSBubyBJT01NVT8KLS0yNDk4
Mi0tIFdBUk5JTkc6IHVuaGFuZGxlZCBfX0hZUEVSVklTT1JfZG9tY3RsIHN1Ym9wOiA0NQot
LTI0OTgyLS0gWW91IG1heSBiZSBhYmxlIHRvIHdyaXRlIHlvdXIgb3duIGhhbmRsZXIuCi0t
MjQ5ODItLSBSZWFkIHRoZSBmaWxlIFJFQURNRV9NSVNTSU5HX1NZU0NBTExfT1JfSU9DVEwu
Ci0tMjQ5ODItLSBOZXZlcnRoZWxlc3Mgd2UgY29uc2lkZXIgdGhpcyBhIGJ1Zy4gIFBsZWFz
ZSByZXBvcnQKLS0yNDk4Mi0tIGl0IGF0IGh0dHA6Ly92YWxncmluZC5vcmcvc3VwcG9ydC9i
dWdfcmVwb3J0cy5odG1sICYKLS0yNDk4Mi0tIGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9S
ZXBvcnRpbmdfQnVnc19hZ2FpbnN0X1hlbi4KbGlieGw6IGVycm9yOiBsaWJ4bF9wY2kuYzox
MDQ1OmxpYnhsX19kZXZpY2VfcGNpX2FkZDogUENJIGRldmljZSAwMDAwOjBhOjBiLjAgY2Fu
bm90IGJlIGFzc2lnbmVkIC0gbm8gSU9NTVU/CldhaXRpbmcgZm9yIGRvbWFpbiBwZnNlbnNl
IChkb21pZCAyKSB0byBkaWUgW3BpZCAyNDk4Ml0KL2Jvb3QvY29uZmlnOiAtRENvbnNvbGVz
OiBpbnRlcm5hbCB2aWRlby9rZXlib2FyZCAgc2VyaWFsIHBvcnQKQklPUyBkcml2ZSBDOiBp
cyBkaXNrMApCSU9TIDYzOWtCLzUxNTA2OGtCIGF2YWlsYWJsZSBtZW1vcnkKCkZyZWVCU0Qv
eDg2IGJvb3RzdHJhcCBsb2FkZXIsIFJldmlzaW9uIDEuMQoocm9vdEBwZjJfMV8xX2FtZDY0
LnBmc2Vuc2Uub3JnLCBNb24gQXVnIDI1IDA4OjE4OjQ4IEVEVCAyMDE0KQpMb2FkaW5nIC9i
b290L2RlZmF1bHRzL2xvYWRlci5jb25mCi9ib290L2tlcm5lbC9rZXJuZWwgZGF0YT0weGJj
MTc5MiBkYXRhPTB4NTk2NDc4KzB4ZTBlZDAgc3ltcz1bMHg4KzB4MTI1ZjcwKzB4OCsweDEx
M2JjNV0KXAoKIO+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/
ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/
ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/vQog77+9ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICDvv70KIO+/vSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAg77+9CiDvv70gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIO+/vQog77+9ICAgICAgICAgIFdlbGNvbWUgdG8gcGZTZW5zZSEgICAg
ICAgICAgICDvv70KIO+/vSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAg77+9ICAgICAgICAgICAgICAgICBfX19fX18KIO+/vSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAg77+9ICAgICAgICAgICAgICAgIC8gICAgICBcCiDvv70g
IDEuIEJvb3QgcGZTZW5zZSBbZGVmYXVsdF0gICAgICAgICAgICAgIO+/vSAgICAgICAgICBf
X19fXy8gICAgZiAgIFwKIO+/vSAgMi4gQm9vdCBwZlNlbnNlIHdpdGggQUNQSSBkaXNhYmxl
ZCAgICAg77+9ICAgICAgICAgLyAgICAgXCAgICAgICAgLwog77+9ICAzLiBCb290IHBmU2Vu
c2UgdXNpbmcgVVNCIGRldmljZSAgICAgICDvv70gICAgICAgIC8gICBwICAgXF9fX19fXy8g
IFNlbnNlCiDvv70gIDQuIEJvb3QgcGZTZW5zZSBpbiBTYWZlIE1vZGUgICAgICAgICAgIO+/
vSAgICAgICAgXCAgICAgICAvICAgICAgXAog77+9ICA1LiBCb290IHBmU2Vuc2UgaW4gc2lu
Z2xlIHVzZXIgbW9kZSAgICDvv70gICAgICAgICBcX19fX18vICAgICAgICBcCiDvv70gIDYu
IEJvb3QgcGZTZW5zZSB3aXRoIHZlcmJvc2UgbG9nZ2luZyAgIO+/vSAgICAgICAgICAgICAg
IFwgICAgICAgIC8KIO+/vSAgNy4gRXNjYXBlIHRvIGxvYWRlciBwcm9tcHQgICAgICAgICAg
ICAg77+9ICAgICAgICAgICAgICAgIFxfX19fX18vCiDvv70gIDguIFJlYm9vdCAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIO+/vQog77+9ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDvv70KIO+/vSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAg77+9CiDvv70gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIO+/vQog77+9ICBTZWxlY3Qgb3B0aW9uLCBbRW50ZXJdIGZvciBkZWZhdWx0ICAg
ICDvv70KIO+/vSAgb3IgW1NwYWNlXSB0byBwYXVzZSB0aW1lciAgMyAgICAgICAgICAg77+9
CiDvv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73vv73vv73vv73vv73vv73vv70KCgpLREI6IGRlYnVnZ2VyIGJhY2tlbmRzOiBkZGIK
S0RCOiBjdXJyZW50IGJhY2tlbmQ6IGRkYgpDb3B5cmlnaHQgKGMpIDE5OTItMjAxMiBUaGUg
RnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYs
IDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKICAgICAgICBUaGUgUmVnZW50
cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVk
LgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91
bmRhdGlvbi4KRnJlZUJTRCA4LjMtUkVMRUFTRS1wMTYgIzA6IE1vbiBBdWcgMjUgMDg6Mjc6
MTEgRURUIDIwMTQKICAgIHJvb3RAcGYyXzFfMV9hbWQ2NC5wZnNlbnNlLm9yZzovdXNyL29i
ai5hbWQ2NC91c3IvcGZTZW5zZXNyYy9zcmMvc3lzL3BmU2Vuc2VfU01QLjggYW1kNjQKVGlt
ZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ1BVOiBJ
bnRlbChSKSBDb3JlKFRNKSBpNS0yMzAwIENQVSBAIDIuODBHSHogKDIzOTQuNTctTUh6IEs4
LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDIwNmE3ICBG
YW1pbHkgPSA2ICBNb2RlbCA9IDJhICBTdGVwcGluZyA9IDcKICBGZWF0dXJlcz0weDE3ODNm
YmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQ
R0UsTUNBLENNT1YsUEFULFBTRTM2LE1NWCxGWFNSLFNTRSxTU0UyLEhUVD4KICBGZWF0dXJl
czI9MHg5N2JhMjIwMzxTU0UzLFBDTE1VTFFEUSxTU1NFMyxDWDE2LFBDSUQsU1NFNC4xLFNT
RTQuMix4MkFQSUMsUE9QQ05ULFRTQ0RMVCxBRVNOSSxYU0FWRSxBVlgsSFY+CiAgQU1EIEZl
YXR1cmVzPTB4MjgxMDA4MDA8U1lTQ0FMTCxOWCxSRFRTQ1AsTE0+CiAgQU1EIEZlYXR1cmVz
Mj0weDE8TEFIRj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50CnJlYWwgbWVtb3J5ICA9IDUy
ODQ4MjMwNCAoNTA0IE1CKQphdmFpbCBtZW1vcnkgPSA0ODM1MjQ2MDggKDQ2MSBNQikKQUNQ
SSBBUElDIFRhYmxlOiA8SFBRT0VNIFNMSUMtQ1BDPgppb2FwaWMwOiBDaGFuZ2luZyBBUElD
IElEIHRvIDEKTUFEVDogRm9yY2luZyBhY3RpdmUtbG93IHBvbGFyaXR5IGFuZCBsZXZlbCB0
cmlnZ2VyIGZvciBTQ0kKaW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC00NyBvbiBtb3Ro
ZXJib2FyZAp3bGFuOiBtYWMgYWNsIHBvbGljeSByZWdpc3RlcmVkCmlwd19ic3M6IFlvdSBu
ZWVkIHRvIHJlYWQgdGhlIExJQ0VOU0UgZmlsZSBpbiAvdXNyL3NoYXJlL2RvYy9sZWdhbC9p
bnRlbF9pcHcvLgppcHdfYnNzOiBJZiB5b3UgYWdyZWUgd2l0aCB0aGUgbGljZW5zZSwgc2V0
IGxlZ2FsLmludGVsX2lwdy5saWNlbnNlX2Fjaz0xIGluIC9ib290L2xvYWRlci5jb25mLgpt
b2R1bGVfcmVnaXN0ZXJfaW5pdDogTU9EX0xPQUQgKGlwd19ic3NfZncsIDB4ZmZmZmZmZmY4
MDRhYmFmMCwgMCkgZXJyb3IgMQppcHdfaWJzczogWW91IG5lZWQgdG8gcmVhZCB0aGUgTElD
RU5TRSBmaWxlIGluIC91c3Ivc2hhcmUvZG9jL2xlZ2FsL2ludGVsX2lwdy8uCmlwd19pYnNz
OiBJZiB5b3UgYWdyZWUgd2l0aCB0aGUgbGljZW5zZSwgc2V0IGxlZ2FsLmludGVsX2lwdy5s
aWNlbnNlX2Fjaz0xIGluIC9ib290L2xvYWRlci5jb25mLgptb2R1bGVfcmVnaXN0ZXJfaW5p
dDogTU9EX0xPQUQgKGlwd19pYnNzX2Z3LCAweGZmZmZmZmZmODA0YWJiOTAsIDApIGVycm9y
IDEKaXB3X21vbml0b3I6IFlvdSBuZWVkIHRvIHJlYWQgdGhlIExJQ0VOU0UgZmlsZSBpbiAv
dXNyL3NoYXJlL2RvYy9sZWdhbC9pbnRlbF9pcHcvLgppcHdfbW9uaXRvcjogSWYgeW91IGFn
cmVlIHdpdGggdGhlIGxpY2Vuc2UsIHNldCBsZWdhbC5pbnRlbF9pcHcubGljZW5zZV9hY2s9
MSBpbiAvYm9vdC9sb2FkZXIuY29uZi4KbW9kdWxlX3JlZ2lzdGVyX2luaXQ6IE1PRF9MT0FE
IChpcHdfbW9uaXRvcl9mdywgMHhmZmZmZmZmZjgwNGFiYzMwLCAwKSBlcnJvciAxCmtiZDEg
YXQga2JkbXV4MApjcnlwdG9zb2Z0MDogPHNvZnR3YXJlIGNyeXB0bz4gb24gbW90aGVyYm9h
cmQKcGFkbG9jazA6IE5vIEFDRSBzdXBwb3J0LgphY3BpMDogPEhQUU9FTSBTTElDLUNQQz4g
b24gbW90aGVyYm9hcmQKYWNwaTA6IFtJVEhSRUFEXQphY3BpMDogUG93ZXIgQnV0dG9uIChm
aXhlZCkKYWNwaTA6IFNsZWVwIEJ1dHRvbiAoZml4ZWQpClRpbWVjb3VudGVyICJBQ1BJLXNh
ZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgODUwCmFjcGlfdGltZXIwOiA8MzIt
Yml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4YjAwOC0weGIwMGIgb24gYWNwaTAK
Y3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdl
PiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBj
aWIwCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMAppc2Ew
OiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPEludGVsIFBJSVgzIFdETUEyIGNvbnRy
b2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhjMjQw
LTB4YzI0ZiBhdCBkZXZpY2UgMS4xIG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVsPiBhdCBj
aGFubmVsIDAgb24gYXRhcGNpMAphdGEwOiBbSVRIUkVBRF0KYXRhMTogPEFUQSBjaGFubmVs
PiBhdCBjaGFubmVsIDEgb24gYXRhcGNpMAphdGExOiBbSVRIUkVBRF0KcGNpMDogPGJyaWRn
ZT4gYXQgZGV2aWNlIDEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQp2Z2FwY2kwOiA8VkdBLWNv
bXBhdGlibGUgZGlzcGxheT4gbWVtIDB4ZjAwMDAwMDAtMHhmMWZmZmZmZiwweGYzMDUyMDAw
LTB4ZjMwNTJmZmYgYXQgZGV2aWNlIDIuMCBvbiBwY2kwCnBjaTA6IDx1bmtub3duPiBhdCBk
ZXZpY2UgMy4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnN5bTA6IDw4OTVhPiBwb3J0IDB4YzEw
MC0weGMxZmYgbWVtIDB4ZjMwNTMwMDAtMHhmMzA1MzNmZiwweGYzMDUwMDAwLTB4ZjMwNTFm
ZmYgaXJxIDMyIGF0IGRldmljZSA0LjAgb24gcGNpMApzeW0wOiBObyBOVlJBTSwgSUQgNywg
RmFzdC00MCwgTFZELCBwYXJpdHkgY2hlY2tpbmcKc3ltMDogW0lUSFJFQURdCmVtMDogPElu
dGVsKFIpIFBSTy8xMDAwIExlZ2FjeSBOZXR3b3JrIENvbm5lY3Rpb24gMS4wLjY+IHBvcnQg
MHhjMjAwLTB4YzIzZiBtZW0gMHhmMzAwMDAwMC0weGYzMDFmZmZmIGlycSAzNiBhdCBkZXZp
Y2UgNS4wIG9uIHBjaTAKZW0wOiBbRklMVEVSXQphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNp
b24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApU
aW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDYyNTAwMDAwIEh6IHF1YWxpdHkgOTAwCmF0
cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MSBpcnEgOCBvbiBhY3Bp
MAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2
NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRj
MAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJF
QURdCnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMApwc20wOiBbR0lBTlQt
TE9DS0VEXQpwc20wOiBbSVRIUkVBRF0KcHNtMDogbW9kZWwgSW50ZWxsaU1vdXNlIEV4cGxv
cmVyLCBkZXZpY2UgSUQgNApmZGMwOiA8ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXI+IHBvcnQg
MHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNwaTAKZmRjMDogZG9lcyBub3Qg
cmVzcG9uZApkZXZpY2VfYXR0YWNoOiBmZGMwIGF0dGFjaCByZXR1cm5lZCA2CnVhcnQwOiA8
MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEw
IG9uIGFjcGkwCnVhcnQwOiBbRklMVEVSXQp1YXJ0MDogY29uc29sZSAoMTE1MjAwLG4sOCwx
KQpwcGMwOiA8UGFyYWxsZWwgcG9ydD4gcG9ydCAweDM3OC0weDM3ZiBpcnEgNyBvbiBhY3Bp
MApwcGMwOiBHZW5lcmljIGNoaXBzZXQgKE5JQkJMRS1vbmx5KSBpbiBDT01QQVRJQkxFIG1v
ZGUKcHBjMDogW0lUSFJFQURdCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMw
CnBsaXAwOiA8UExJUCBuZXR3b3JrIGludGVyZmFjZT4gb24gcHBidXMwCnBsaXAwOiBbSVRI
UkVBRF0KbHB0MDogPFByaW50ZXI+IG9uIHBwYnVzMApscHQwOiBbSVRIUkVBRF0KbHB0MDog
SW50ZXJydXB0LWRyaXZlbiBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMApv
cm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4ZWQ4MDAtMHhlZmZmZiBvbiBpc2Ew
CnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdB
IDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMgSVNB
IFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNh
MApUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMjM5NDU3MDU5NiBIeiBxdWFsaXR5IDgw
MApUaW1lY291bnRlcnMgdGljayBldmVyeSAxMC4wMDAgbXNlYwpJUHNlYzogSW5pdGlhbGl6
ZWQgU2VjdXJpdHkgQXNzb2NpYXRpb24gUHJvY2Vzc2luZy4KYWNkMDogRFZEUk9NIDxRRU1V
IERWRC1ST00vMS4zLjE+IGF0IGF0YTEtbWFzdGVyIFdETUEyCnN5bTA6IHVua25vd24gaW50
ZXJydXB0KHMpIGlnbm9yZWQsIElTVEFUPTB4MSBEU1RBVD0weDgwIFNJU1Q9MHgwCmRhMCBh
dCBzeW0wIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMApkYTA6IDxRRU1VIFFFTVUgSEFS
RERJU0sgMS4zLj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlCmRhMDogMy4z
MDBNQi9zIHRyYW5zZmVycwpkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApkYTA6IDgx
OTJNQiAoMTY3NzcyMTYgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAxMDQ0QykKVHJ5
aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9kYTBzMWEKQ29uZmlndXJpbmcgY3Jh
c2ggZHVtcHMuLi4KVXNpbmcgL2Rldi9kYTBzMWIgZm9yIGR1bXAgZGV2aWNlLgpNb3VudGlu
ZyBmaWxlc3lzdGVtcy4uLgpaRlMgTk9USUNFOiBQcmVmZXRjaCBpcyBkaXNhYmxlZCBieSBk
ZWZhdWx0IGlmIGxlc3MgdGhhbiA0R0Igb2YgUkFNIGlzIHByZXNlbnQ7CiAgICAgICAgICAg
IHRvIGVuYWJsZSwgYWRkICJ2ZnMuemZzLnByZWZldGNoX2Rpc2FibGU9MCIgdG8gL2Jvb3Qv
bG9hZGVyLmNvbmYuClpGUyBXQVJOSU5HOiBSZWNvbW1lbmRlZCBtaW5pbXVtIGttZW1fc2l6
ZSBpcyA1MTJNQjsgZXhwZWN0IHVuc3RhYmxlIGJlaGF2aW9yLgogICAgICAgICAgICAgQ29u
c2lkZXIgdHVuaW5nIHZtLmttZW1fc2l6ZSBhbmQgdm0ua21lbV9zaXplX21heAogICAgICAg
ICAgICAgaW4gL2Jvb3QvbG9hZGVyLmNvbmYuClpGUyBmaWxlc3lzdGVtIHZlcnNpb24gNQpa
RlMgc3RvcmFnZSBwb29sIHZlcnNpb24gMjgKCiAgICAgX19fCiBfX18vIGYgXAovIHAgXF9f
Xy8gU2Vuc2UKXF9fXy8gICBcCiAgICBcX19fLwoKV2VsY29tZSB0byBwZlNlbnNlIDIuMS41
LVJFTEVBU0UgIC4uLgoKTm8gY29yZSBkdW1wcyBmb3VuZC4KQ3JlYXRpbmcgc3ltbGlua3Mu
Li4uLi5kb25lLgo+Pj4gVW5kZXIgNTEyIG1lZ2FieXRlcyBvZiByYW0gZGV0ZWN0ZWQuICBO
b3QgZW5hYmxpbmcgQVBDLgpFeHRlcm5hbCBjb25maWcgbG9hZGVyIDEuMCBpcyBub3cgc3Rh
cnRpbmcuLi4KTGF1bmNoaW5nIHRoZSBpbml0IHN5c3RlbS4uLiBkb25lLgpJbml0aWFsaXpp
bmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBkb25lLgpTdGFydGluZyBkZXZpY2Ug
bWFuYWdlciAoZGV2ZCkuLi5kb25lLgpMb2FkaW5nIGNvbmZpZ3VyYXRpb24uLi4uLi5kb25l
LgpXYXJuaW5nOiBDb25maWd1cmF0aW9uIHJlZmVyZW5jZXMgaW50ZXJmYWNlcyB0aGF0IGRv
IG5vdCBleGlzdDogYXRoMCBybDAKCk5ldHdvcmsgaW50ZXJmYWNlIG1pc21hdGNoIC0tIFJ1
bm5pbmcgaW50ZXJmYWNlIGFzc2lnbm1lbnQgb3B0aW9uLgoKVmFsaWQgaW50ZXJmYWNlcyBh
cmU6CgplbTAgICAwMDoxNjozZTphMTo2NDowMSAgICh1cCkgSW50ZWwoUikgUFJPLzEwMDAg
TGVnYWN5IE5ldHdvcmsgQ29ubmVjdGlvbiAxLjAuNgoKRG8geW91IHdhbnQgdG8gc2V0IHVw
IFZMQU5zIGZpcnN0PwoKSWYgeW91IGFyZSBub3QgZ29pbmcgdG8gdXNlIFZMQU5zLCBvciBv
bmx5IGZvciBvcHRpb25hbCBpbnRlcmZhY2VzLCB5b3Ugc2hvdWxkCnNheSBubyBoZXJlIGFu
ZCB1c2UgdGhlIHdlYkNvbmZpZ3VyYXRvciB0byBjb25maWd1cmUgVkxBTnMgbGF0ZXIsIGlm
IHJlcXVpcmVkLgoKRG8geW91IHdhbnQgdG8gc2V0IHVwIFZMQU5zIG5vdyBbeXxuXT8gZW0w
OiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKCnBmU2Vuc2UgaXMgbm93IHNodXR0aW5nIGRv
d24gLi4uCgpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGB2
bmxydScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0
ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXggNjAg
c2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5jZXInIHRvIHN0b3AuLi4KU3luY2lu
ZyBkaXNrcywgdm5vZGVzIHJlbWFpbmluZy4uLjAgZG9uZQpBbGwgYnVmZmVycyBzeW5jZWQu
ClVwdGltZTogNG0xM3MKYWNwaTA6IFBvd2VyaW5nIHN5c3RlbSBvZmYKRG9tYWluIDIgaGFz
IHNodXQgZG93biwgcmVhc29uIGNvZGUgMCAweDAKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBBY3Rpb24gZm9yIHNodXRkb3duIHJlYXNvbiBjb2RlIDAgaXMg
ZGVzdHJveQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRG9tYWluIDIgbmVlZHMg
dG8gYmUgY2xlYW5lZCB1cDogZGVzdHJveWluZyB0aGUgZG9tYWluCiAgICAgICA9PTI0OTgy
PT0KICAgICAgICAgICAgICAgICA9PTI0OTgyPT0gUHJvY2VzcyB0ZXJtaW5hdGluZyB3aXRo
IGRlZmF1bHQgYWN0aW9uIG9mIHNpZ25hbCAxMSAoU0lHU0VHVikKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA9PTI0OTgyPT0gIEJhZCBwZXJtaXNzaW9ucyBmb3IgbWFw
cGVkIHJlZ2lvbiBhdCBhZGRyZXNzIDB4NDAzNUQ0MAogICAgICAgICAgICAgICAgICAgICAg
PT0yNDk4Mj09ICAgIGF0IDB4NTZFREI5NTogc2lnY2FuY2VsX2hhbmRsZXIgKG5wdGwtaW5p
dC5jOjE3NCkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPT0yNDk4Mj09CiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9PTI0OTgyPT0gSEVBUCBTVU1N
QVJZOgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA9PTI0OTgyPT0gICAgIGluIHVzZSBhdCBleGl0OiA3LDU4MCBieXRl
cyBpbiA1MCBibG9ja3MKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PT0yNDk4Mj09ICAgdG90YWwgaGVhcCB1c2FnZTogMSw2ODggYWxsb2NzLCAxLDYzOCBmcmVl
cywgNCw5NzgsMjY1IGJ5dGVzIGFsbG9jYXRlZAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPT0yNDk4Mj09CiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPT0yNDk4Mj09IExFQUsgU1VNTUFSWToKICAgICAgICAg
ICAgICAgICAgICAgID09MjQ5ODI9PSAgICBkZWZpbml0ZWx5IGxvc3Q6IDUxNiBieXRlcyBp
biA3IGJsb2NrcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPT0yNDk4Mj09ICAgIGluZGlyZWN0bHkg
bG9zdDogMCBieXRlcyBpbiAwIGJsb2NrcwogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID09MjQ5ODI9PSAgICAg
IHBvc3NpYmx5IGxvc3Q6IDU3NiBieXRlcyBpbiAyIGJsb2NrcwogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgID09MjQ5ODI9PSAgICBzdGlsbCByZWFjaGFibGU6
IDYsNDg4IGJ5dGVzIGluIDQxIGJsb2NrcwogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgID09MjQ5ODI9PSAgICAgICAgIHN1cHByZXNzZWQ6IDAgYnl0ZXMgaW4g
MCBibG9ja3MKICAgICAgICAgICAgPT0yNDk4Mj09IFJlcnVuIHdpdGggLS1sZWFrLWNoZWNr
PWZ1bGwgdG8gc2VlIGRldGFpbHMgb2YgbGVha2VkIG1lbW9yeQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPT0yNDk4Mj09CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPT0yNDk4Mj09IEZvciBjb3VudHMgb2YgZGV0ZWN0ZWQgYW5kIHN1cHByZXNzZWQg
ZXJyb3JzLCByZXJ1biB3aXRoOiAtdgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9
PTI0OTgyPT0gRVJST1IgU1VNTUFSWTogMCBlcnJvcnMgZnJvbSAwIGNvbnRleHRzIChzdXBw
cmVzc2VkOiAwIGZyb20gMCkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgS2lsbGVkCgo=
--------------000605000609080501090206
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000605000609080501090206--


From xen-devel-bounces@lists.xen.org Wed Nov 05 12:01:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 12:01:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XlzH7-0007X6-1i; Wed, 05 Nov 2014 12:01:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XlzH5-0007Wy-4R
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 12:01:19 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	34/F5-28865-D811A545; Wed, 05 Nov 2014 12:01:17 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415188876!3757187!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27825 invoked from network); 5 Nov 2014 12:01:16 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 12:01:16 -0000
Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlzH0-0005tB-C3; Wed, 05 Nov 2014 13:01:14 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.64])
	by justin.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XlzGz-00087k-Hk; Wed, 05 Nov 2014 13:01:14 +0100
Message-ID: <545A118B.7040309@web2web.at>
Date: Wed, 05 Nov 2014 13:01:15 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>					<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>				<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>			
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>		
	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>	
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
	<1415180713.11486.61.camel@citrix.com>
In-Reply-To: <1415180713.11486.61.camel@citrix.com>
Content-Type: multipart/mixed; boundary="------------000605000609080501090206"
X-Univie-Virus-Scan: scanned by ClamAV on justin.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------000605000609080501090206
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Am 05.11.14 um 10:45 schrieb Ian Campbell:
> On Tue, 2014-11-04 at 18:30 +0100, Atom2 wrote:
>> Am 04.11.14 um 17:31 schrieb Ian Campbell:
>>> On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
>>>> Am 04.11.14 um 16:44 schrieb Ian Campbell:
>>>>> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
> Sadly it looks like your version of valgrind doesn't know how to handle
> the hypercalls made by the Xen toolstack, which means it produces a lot
> of unrelated noise.
>
> You seem to be using valgrind 3.9.0, which lacked knowledge of some of
> the HVM related hypercalls that weren't added until 3.10.0. It's
> probably not worth pursuing this angle any further (unless it is utterly
> trivial to pull in the new version).
Many thanks again for your quick answers.

You were right, I used valgrind-3.9.0 which is the latest stable version 
for gentoo. 3.10.0 is available under unstable and it was indeed trivial 
to pull that in instead. The unrelated noise seems to have disappeared, 
so attached please find the output of running
	# valgrindd xl create -F -c pfsense

The strange thing was: No segfault at the start, but obviously also 
issues with passing through the PCI devices as evidenced by the same 
error messages you flagged below. Also the boot menu now showed up and I 
was able to boot the domain - but, as expected by the error message, no 
network devices have been passed through. Even a

	# xl shutdown -F pfsense
	Shutting down domain 2
	PV control interface not available: sending ACPI power button event.
	#

from another ssh connection to dom0 worked (no segfault message in that 
session) and as such the attached file 'valgrind.out' contains the 
complete screen output of the valgrind session from start to finnish. 
However, towards the end of that file (line 235) you'll see a SEGFAULT 
message from valgrind. I hope you can make some sense out of that ... or 
should I rerun with some options to valgrind (like the ones mentioned in 
the output):
	--leak-check=full
	-v

To me, it looks as if something is broken with the PCI passthrough stuff 
and that has started with 4.3.3. Strangely however, valgrind seems to 
work around that issue insofar that no segfault happens. Is there any 
explanation of the different behaviour between native execution of xl 
and starting xl under valgrind's control?

In any case, I am positive that there hasn't been any change to the 
hardware of the system, not even a slot change of an add-on card. So I 
have no clue why the system after the upgrade misbehaves.
>
> Apart from the valgrind output there is a new message from libxl:
>          libxl: error: libxl_pci.c:1045:libxl__device_pci_add: PCI device 0000:04:00.0 cannot be assigned - no IOMMU?
> which suggests that it isn't passing things through (this might be
> fallout from valgrind not understanding things) and no segfault.
>
> OOI what does "xl create -F ..." do without valgrind (I'm wondering if
> -F is responsible for the change in behaviour).
I tried that as well:

	vm-host auto [526] # xl create -F -c pfsense
	Parsing config from pfsense
	xc: info: VIRTUAL MEMORY ARRANGEMENT:
	  Loader:        0000000000100000->00000000001c12a4
	  Modules:       0000000000000000->0000000000000000
	  TOTAL:         0000000000000000->000000001f800000
	  ENTRY ADDRESS: 0000000000100000
	xc: info: PHYSICAL MEMORY ALLOCATION:
	  4KB PAGES: 0x0000000000000200
	  2MB PAGES: 0x00000000000000fb
	  1GB PAGES: 0x0000000000000000
	Segmentation fault
	vm-host auto [527] # xl list
	Name                        ID   Mem VCPUs      State   Time(s)
	Domain-0                     0  4094     8     r-----     451.5
	pfsense                      1   512     1     --p---       0.0
	vm-host auto [528] # xl destroy pfsense
	Segmentation fault
	vm-host auto [529] # xl list
	Name                        ID   Mem VCPUs      State   Time(s)
	Domain-0                     0  4096     8     r-----     452.1
	vm-host auto [529] #

and, as you can see, again had the segfault and the same status of the 
domU as back at the time when the issues started (i.e. paused - which 
you explained as being normal after a start).

Thanks Atom2

--------------000605000609080501090206
Content-Type: text/plain; charset=windows-1252;
 name="valgrind.out"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="valgrind.out"

dm0taG9zdCBhdXRvIFs1NDBdICMgdmFsZ3JpbmQgeGwgY3JlYXRlIC1GIC1jIHBmc2Vuc2UK
PT0yNDk4Mj09IE1lbWNoZWNrLCBhIG1lbW9yeSBlcnJvciBkZXRlY3Rvcgo9PTI0OTgyPT0g
Q29weXJpZ2h0IChDKSAyMDAyLTIwMTMsIGFuZCBHTlUgR1BMJ2QsIGJ5IEp1bGlhbiBTZXdh
cmQgZXQgYWwuCj09MjQ5ODI9PSBVc2luZyBWYWxncmluZC0zLjEwLjAgYW5kIExpYlZFWDsg
cmVydW4gd2l0aCAtaCBmb3IgY29weXJpZ2h0IGluZm8KPT0yNDk4Mj09IENvbW1hbmQ6IHhs
IGNyZWF0ZSAtRiAtYyBwZnNlbnNlCj09MjQ5ODI9PQpQYXJzaW5nIGNvbmZpZyBmcm9tIHBm
c2Vuc2UKLS0yNDk4Mi0tIFdBUk5JTkc6IHVuaGFuZGxlZCBfX0hZUEVSVklTT1JfZG9tY3Rs
IHNoYWRvdygxMCkgc3Vib3A6IDMxCi0tMjQ5ODItLSBZb3UgbWF5IGJlIGFibGUgdG8gd3Jp
dGUgeW91ciBvd24gaGFuZGxlci4KLS0yNDk4Mi0tIFJlYWQgdGhlIGZpbGUgUkVBRE1FX01J
U1NJTkdfU1lTQ0FMTF9PUl9JT0NUTC4KLS0yNDk4Mi0tIE5ldmVydGhlbGVzcyB3ZSBjb25z
aWRlciB0aGlzIGEgYnVnLiAgUGxlYXNlIHJlcG9ydAotLTI0OTgyLS0gaXQgYXQgaHR0cDov
L3ZhbGdyaW5kLm9yZy9zdXBwb3J0L2J1Z19yZXBvcnRzLmh0bWwgJgotLTI0OTgyLS0gaHR0
cDovL3dpa2kueGVuLm9yZy93aWtpL1JlcG9ydGluZ19CdWdzX2FnYWluc3RfWGVuLgp4Yzog
aW5mbzogVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6CiAgTG9hZGVyOiAgICAgICAgMDAw
MDAwMDAwMDEwMDAwMC0+MDAwMDAwMDAwMDFjMTJhNAogIE1vZHVsZXM6ICAgICAgIDAwMDAw
MDAwMDAwMDAwMDAtPjAwMDAwMDAwMDAwMDAwMDAKICBUT1RBTDogICAgICAgICAwMDAwMDAw
MDAwMDAwMDAwLT4wMDAwMDAwMDFmODAwMDAwCiAgRU5UUlkgQUREUkVTUzogMDAwMDAwMDAw
MDEwMDAwMAp4YzogaW5mbzogUEhZU0lDQUwgTUVNT1JZIEFMTE9DQVRJT046CiAgNEtCIFBB
R0VTOiAweDAwMDAwMDAwMDAwMDAyMDAKICAyTUIgUEFHRVM6IDB4MDAwMDAwMDAwMDAwMDBm
YgogIDFHQiBQQUdFUzogMHgwMDAwMDAwMDAwMDAwMDAwCi0tMjQ5ODItLSBXQVJOSU5HOiB1
bmhhbmRsZWQgX19IWVBFUlZJU09SX2RvbWN0bCBzdWJvcDogNDUKLS0yNDk4Mi0tIFlvdSBt
YXkgYmUgYWJsZSB0byB3cml0ZSB5b3VyIG93biBoYW5kbGVyLgotLTI0OTgyLS0gUmVhZCB0
aGUgZmlsZSBSRUFETUVfTUlTU0lOR19TWVNDQUxMX09SX0lPQ1RMLgotLTI0OTgyLS0gTmV2
ZXJ0aGVsZXNzIHdlIGNvbnNpZGVyIHRoaXMgYSBidWcuICBQbGVhc2UgcmVwb3J0Ci0tMjQ5
ODItLSBpdCBhdCBodHRwOi8vdmFsZ3JpbmQub3JnL3N1cHBvcnQvYnVnX3JlcG9ydHMuaHRt
bCAmCi0tMjQ5ODItLSBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvUmVwb3J0aW5nX0J1Z3Nf
YWdhaW5zdF9YZW4uCmxpYnhsOiBlcnJvcjogbGlieGxfcGNpLmM6MTA0NTpsaWJ4bF9fZGV2
aWNlX3BjaV9hZGQ6IFBDSSBkZXZpY2UgMDAwMDowNDowMC4wIGNhbm5vdCBiZSBhc3NpZ25l
ZCAtIG5vIElPTU1VPwotLTI0OTgyLS0gV0FSTklORzogdW5oYW5kbGVkIF9fSFlQRVJWSVNP
Ul9kb21jdGwgc3Vib3A6IDQ1Ci0tMjQ5ODItLSBZb3UgbWF5IGJlIGFibGUgdG8gd3JpdGUg
eW91ciBvd24gaGFuZGxlci4KLS0yNDk4Mi0tIFJlYWQgdGhlIGZpbGUgUkVBRE1FX01JU1NJ
TkdfU1lTQ0FMTF9PUl9JT0NUTC4KLS0yNDk4Mi0tIE5ldmVydGhlbGVzcyB3ZSBjb25zaWRl
ciB0aGlzIGEgYnVnLiAgUGxlYXNlIHJlcG9ydAotLTI0OTgyLS0gaXQgYXQgaHR0cDovL3Zh
bGdyaW5kLm9yZy9zdXBwb3J0L2J1Z19yZXBvcnRzLmh0bWwgJgotLTI0OTgyLS0gaHR0cDov
L3dpa2kueGVuLm9yZy93aWtpL1JlcG9ydGluZ19CdWdzX2FnYWluc3RfWGVuLgpsaWJ4bDog
ZXJyb3I6IGxpYnhsX3BjaS5jOjEwNDU6bGlieGxfX2RldmljZV9wY2lfYWRkOiBQQ0kgZGV2
aWNlIDAwMDA6MGE6MDguMCBjYW5ub3QgYmUgYXNzaWduZWQgLSBubyBJT01NVT8KLS0yNDk4
Mi0tIFdBUk5JTkc6IHVuaGFuZGxlZCBfX0hZUEVSVklTT1JfZG9tY3RsIHN1Ym9wOiA0NQot
LTI0OTgyLS0gWW91IG1heSBiZSBhYmxlIHRvIHdyaXRlIHlvdXIgb3duIGhhbmRsZXIuCi0t
MjQ5ODItLSBSZWFkIHRoZSBmaWxlIFJFQURNRV9NSVNTSU5HX1NZU0NBTExfT1JfSU9DVEwu
Ci0tMjQ5ODItLSBOZXZlcnRoZWxlc3Mgd2UgY29uc2lkZXIgdGhpcyBhIGJ1Zy4gIFBsZWFz
ZSByZXBvcnQKLS0yNDk4Mi0tIGl0IGF0IGh0dHA6Ly92YWxncmluZC5vcmcvc3VwcG9ydC9i
dWdfcmVwb3J0cy5odG1sICYKLS0yNDk4Mi0tIGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9S
ZXBvcnRpbmdfQnVnc19hZ2FpbnN0X1hlbi4KbGlieGw6IGVycm9yOiBsaWJ4bF9wY2kuYzox
MDQ1OmxpYnhsX19kZXZpY2VfcGNpX2FkZDogUENJIGRldmljZSAwMDAwOjBhOjBiLjAgY2Fu
bm90IGJlIGFzc2lnbmVkIC0gbm8gSU9NTVU/CldhaXRpbmcgZm9yIGRvbWFpbiBwZnNlbnNl
IChkb21pZCAyKSB0byBkaWUgW3BpZCAyNDk4Ml0KL2Jvb3QvY29uZmlnOiAtRENvbnNvbGVz
OiBpbnRlcm5hbCB2aWRlby9rZXlib2FyZCAgc2VyaWFsIHBvcnQKQklPUyBkcml2ZSBDOiBp
cyBkaXNrMApCSU9TIDYzOWtCLzUxNTA2OGtCIGF2YWlsYWJsZSBtZW1vcnkKCkZyZWVCU0Qv
eDg2IGJvb3RzdHJhcCBsb2FkZXIsIFJldmlzaW9uIDEuMQoocm9vdEBwZjJfMV8xX2FtZDY0
LnBmc2Vuc2Uub3JnLCBNb24gQXVnIDI1IDA4OjE4OjQ4IEVEVCAyMDE0KQpMb2FkaW5nIC9i
b290L2RlZmF1bHRzL2xvYWRlci5jb25mCi9ib290L2tlcm5lbC9rZXJuZWwgZGF0YT0weGJj
MTc5MiBkYXRhPTB4NTk2NDc4KzB4ZTBlZDAgc3ltcz1bMHg4KzB4MTI1ZjcwKzB4OCsweDEx
M2JjNV0KXAoKIO+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/
ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/
ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/vQog77+9ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICDvv70KIO+/vSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAg77+9CiDvv70gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIO+/vQog77+9ICAgICAgICAgIFdlbGNvbWUgdG8gcGZTZW5zZSEgICAg
ICAgICAgICDvv70KIO+/vSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAg77+9ICAgICAgICAgICAgICAgICBfX19fX18KIO+/vSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAg77+9ICAgICAgICAgICAgICAgIC8gICAgICBcCiDvv70g
IDEuIEJvb3QgcGZTZW5zZSBbZGVmYXVsdF0gICAgICAgICAgICAgIO+/vSAgICAgICAgICBf
X19fXy8gICAgZiAgIFwKIO+/vSAgMi4gQm9vdCBwZlNlbnNlIHdpdGggQUNQSSBkaXNhYmxl
ZCAgICAg77+9ICAgICAgICAgLyAgICAgXCAgICAgICAgLwog77+9ICAzLiBCb290IHBmU2Vu
c2UgdXNpbmcgVVNCIGRldmljZSAgICAgICDvv70gICAgICAgIC8gICBwICAgXF9fX19fXy8g
IFNlbnNlCiDvv70gIDQuIEJvb3QgcGZTZW5zZSBpbiBTYWZlIE1vZGUgICAgICAgICAgIO+/
vSAgICAgICAgXCAgICAgICAvICAgICAgXAog77+9ICA1LiBCb290IHBmU2Vuc2UgaW4gc2lu
Z2xlIHVzZXIgbW9kZSAgICDvv70gICAgICAgICBcX19fX18vICAgICAgICBcCiDvv70gIDYu
IEJvb3QgcGZTZW5zZSB3aXRoIHZlcmJvc2UgbG9nZ2luZyAgIO+/vSAgICAgICAgICAgICAg
IFwgICAgICAgIC8KIO+/vSAgNy4gRXNjYXBlIHRvIGxvYWRlciBwcm9tcHQgICAgICAgICAg
ICAg77+9ICAgICAgICAgICAgICAgIFxfX19fX18vCiDvv70gIDguIFJlYm9vdCAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIO+/vQog77+9ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDvv70KIO+/vSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAg77+9CiDvv70gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIO+/vQog77+9ICBTZWxlY3Qgb3B0aW9uLCBbRW50ZXJdIGZvciBkZWZhdWx0ICAg
ICDvv70KIO+/vSAgb3IgW1NwYWNlXSB0byBwYXVzZSB0aW1lciAgMyAgICAgICAgICAg77+9
CiDvv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73vv73vv73vv73vv73vv73vv70KCgpLREI6IGRlYnVnZ2VyIGJhY2tlbmRzOiBkZGIK
S0RCOiBjdXJyZW50IGJhY2tlbmQ6IGRkYgpDb3B5cmlnaHQgKGMpIDE5OTItMjAxMiBUaGUg
RnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYs
IDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKICAgICAgICBUaGUgUmVnZW50
cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVk
LgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91
bmRhdGlvbi4KRnJlZUJTRCA4LjMtUkVMRUFTRS1wMTYgIzA6IE1vbiBBdWcgMjUgMDg6Mjc6
MTEgRURUIDIwMTQKICAgIHJvb3RAcGYyXzFfMV9hbWQ2NC5wZnNlbnNlLm9yZzovdXNyL29i
ai5hbWQ2NC91c3IvcGZTZW5zZXNyYy9zcmMvc3lzL3BmU2Vuc2VfU01QLjggYW1kNjQKVGlt
ZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ1BVOiBJ
bnRlbChSKSBDb3JlKFRNKSBpNS0yMzAwIENQVSBAIDIuODBHSHogKDIzOTQuNTctTUh6IEs4
LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDIwNmE3ICBG
YW1pbHkgPSA2ICBNb2RlbCA9IDJhICBTdGVwcGluZyA9IDcKICBGZWF0dXJlcz0weDE3ODNm
YmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQ
R0UsTUNBLENNT1YsUEFULFBTRTM2LE1NWCxGWFNSLFNTRSxTU0UyLEhUVD4KICBGZWF0dXJl
czI9MHg5N2JhMjIwMzxTU0UzLFBDTE1VTFFEUSxTU1NFMyxDWDE2LFBDSUQsU1NFNC4xLFNT
RTQuMix4MkFQSUMsUE9QQ05ULFRTQ0RMVCxBRVNOSSxYU0FWRSxBVlgsSFY+CiAgQU1EIEZl
YXR1cmVzPTB4MjgxMDA4MDA8U1lTQ0FMTCxOWCxSRFRTQ1AsTE0+CiAgQU1EIEZlYXR1cmVz
Mj0weDE8TEFIRj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50CnJlYWwgbWVtb3J5ICA9IDUy
ODQ4MjMwNCAoNTA0IE1CKQphdmFpbCBtZW1vcnkgPSA0ODM1MjQ2MDggKDQ2MSBNQikKQUNQ
SSBBUElDIFRhYmxlOiA8SFBRT0VNIFNMSUMtQ1BDPgppb2FwaWMwOiBDaGFuZ2luZyBBUElD
IElEIHRvIDEKTUFEVDogRm9yY2luZyBhY3RpdmUtbG93IHBvbGFyaXR5IGFuZCBsZXZlbCB0
cmlnZ2VyIGZvciBTQ0kKaW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC00NyBvbiBtb3Ro
ZXJib2FyZAp3bGFuOiBtYWMgYWNsIHBvbGljeSByZWdpc3RlcmVkCmlwd19ic3M6IFlvdSBu
ZWVkIHRvIHJlYWQgdGhlIExJQ0VOU0UgZmlsZSBpbiAvdXNyL3NoYXJlL2RvYy9sZWdhbC9p
bnRlbF9pcHcvLgppcHdfYnNzOiBJZiB5b3UgYWdyZWUgd2l0aCB0aGUgbGljZW5zZSwgc2V0
IGxlZ2FsLmludGVsX2lwdy5saWNlbnNlX2Fjaz0xIGluIC9ib290L2xvYWRlci5jb25mLgpt
b2R1bGVfcmVnaXN0ZXJfaW5pdDogTU9EX0xPQUQgKGlwd19ic3NfZncsIDB4ZmZmZmZmZmY4
MDRhYmFmMCwgMCkgZXJyb3IgMQppcHdfaWJzczogWW91IG5lZWQgdG8gcmVhZCB0aGUgTElD
RU5TRSBmaWxlIGluIC91c3Ivc2hhcmUvZG9jL2xlZ2FsL2ludGVsX2lwdy8uCmlwd19pYnNz
OiBJZiB5b3UgYWdyZWUgd2l0aCB0aGUgbGljZW5zZSwgc2V0IGxlZ2FsLmludGVsX2lwdy5s
aWNlbnNlX2Fjaz0xIGluIC9ib290L2xvYWRlci5jb25mLgptb2R1bGVfcmVnaXN0ZXJfaW5p
dDogTU9EX0xPQUQgKGlwd19pYnNzX2Z3LCAweGZmZmZmZmZmODA0YWJiOTAsIDApIGVycm9y
IDEKaXB3X21vbml0b3I6IFlvdSBuZWVkIHRvIHJlYWQgdGhlIExJQ0VOU0UgZmlsZSBpbiAv
dXNyL3NoYXJlL2RvYy9sZWdhbC9pbnRlbF9pcHcvLgppcHdfbW9uaXRvcjogSWYgeW91IGFn
cmVlIHdpdGggdGhlIGxpY2Vuc2UsIHNldCBsZWdhbC5pbnRlbF9pcHcubGljZW5zZV9hY2s9
MSBpbiAvYm9vdC9sb2FkZXIuY29uZi4KbW9kdWxlX3JlZ2lzdGVyX2luaXQ6IE1PRF9MT0FE
IChpcHdfbW9uaXRvcl9mdywgMHhmZmZmZmZmZjgwNGFiYzMwLCAwKSBlcnJvciAxCmtiZDEg
YXQga2JkbXV4MApjcnlwdG9zb2Z0MDogPHNvZnR3YXJlIGNyeXB0bz4gb24gbW90aGVyYm9h
cmQKcGFkbG9jazA6IE5vIEFDRSBzdXBwb3J0LgphY3BpMDogPEhQUU9FTSBTTElDLUNQQz4g
b24gbW90aGVyYm9hcmQKYWNwaTA6IFtJVEhSRUFEXQphY3BpMDogUG93ZXIgQnV0dG9uIChm
aXhlZCkKYWNwaTA6IFNsZWVwIEJ1dHRvbiAoZml4ZWQpClRpbWVjb3VudGVyICJBQ1BJLXNh
ZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgODUwCmFjcGlfdGltZXIwOiA8MzIt
Yml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4YjAwOC0weGIwMGIgb24gYWNwaTAK
Y3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdl
PiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBj
aWIwCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMAppc2Ew
OiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPEludGVsIFBJSVgzIFdETUEyIGNvbnRy
b2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhjMjQw
LTB4YzI0ZiBhdCBkZXZpY2UgMS4xIG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVsPiBhdCBj
aGFubmVsIDAgb24gYXRhcGNpMAphdGEwOiBbSVRIUkVBRF0KYXRhMTogPEFUQSBjaGFubmVs
PiBhdCBjaGFubmVsIDEgb24gYXRhcGNpMAphdGExOiBbSVRIUkVBRF0KcGNpMDogPGJyaWRn
ZT4gYXQgZGV2aWNlIDEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQp2Z2FwY2kwOiA8VkdBLWNv
bXBhdGlibGUgZGlzcGxheT4gbWVtIDB4ZjAwMDAwMDAtMHhmMWZmZmZmZiwweGYzMDUyMDAw
LTB4ZjMwNTJmZmYgYXQgZGV2aWNlIDIuMCBvbiBwY2kwCnBjaTA6IDx1bmtub3duPiBhdCBk
ZXZpY2UgMy4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnN5bTA6IDw4OTVhPiBwb3J0IDB4YzEw
MC0weGMxZmYgbWVtIDB4ZjMwNTMwMDAtMHhmMzA1MzNmZiwweGYzMDUwMDAwLTB4ZjMwNTFm
ZmYgaXJxIDMyIGF0IGRldmljZSA0LjAgb24gcGNpMApzeW0wOiBObyBOVlJBTSwgSUQgNywg
RmFzdC00MCwgTFZELCBwYXJpdHkgY2hlY2tpbmcKc3ltMDogW0lUSFJFQURdCmVtMDogPElu
dGVsKFIpIFBSTy8xMDAwIExlZ2FjeSBOZXR3b3JrIENvbm5lY3Rpb24gMS4wLjY+IHBvcnQg
MHhjMjAwLTB4YzIzZiBtZW0gMHhmMzAwMDAwMC0weGYzMDFmZmZmIGlycSAzNiBhdCBkZXZp
Y2UgNS4wIG9uIHBjaTAKZW0wOiBbRklMVEVSXQphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNp
b24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApU
aW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDYyNTAwMDAwIEh6IHF1YWxpdHkgOTAwCmF0
cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MSBpcnEgOCBvbiBhY3Bp
MAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2
NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRj
MAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJF
QURdCnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMApwc20wOiBbR0lBTlQt
TE9DS0VEXQpwc20wOiBbSVRIUkVBRF0KcHNtMDogbW9kZWwgSW50ZWxsaU1vdXNlIEV4cGxv
cmVyLCBkZXZpY2UgSUQgNApmZGMwOiA8ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXI+IHBvcnQg
MHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNwaTAKZmRjMDogZG9lcyBub3Qg
cmVzcG9uZApkZXZpY2VfYXR0YWNoOiBmZGMwIGF0dGFjaCByZXR1cm5lZCA2CnVhcnQwOiA8
MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEw
IG9uIGFjcGkwCnVhcnQwOiBbRklMVEVSXQp1YXJ0MDogY29uc29sZSAoMTE1MjAwLG4sOCwx
KQpwcGMwOiA8UGFyYWxsZWwgcG9ydD4gcG9ydCAweDM3OC0weDM3ZiBpcnEgNyBvbiBhY3Bp
MApwcGMwOiBHZW5lcmljIGNoaXBzZXQgKE5JQkJMRS1vbmx5KSBpbiBDT01QQVRJQkxFIG1v
ZGUKcHBjMDogW0lUSFJFQURdCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMw
CnBsaXAwOiA8UExJUCBuZXR3b3JrIGludGVyZmFjZT4gb24gcHBidXMwCnBsaXAwOiBbSVRI
UkVBRF0KbHB0MDogPFByaW50ZXI+IG9uIHBwYnVzMApscHQwOiBbSVRIUkVBRF0KbHB0MDog
SW50ZXJydXB0LWRyaXZlbiBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMApv
cm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4ZWQ4MDAtMHhlZmZmZiBvbiBpc2Ew
CnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdB
IDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMgSVNB
IFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNh
MApUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMjM5NDU3MDU5NiBIeiBxdWFsaXR5IDgw
MApUaW1lY291bnRlcnMgdGljayBldmVyeSAxMC4wMDAgbXNlYwpJUHNlYzogSW5pdGlhbGl6
ZWQgU2VjdXJpdHkgQXNzb2NpYXRpb24gUHJvY2Vzc2luZy4KYWNkMDogRFZEUk9NIDxRRU1V
IERWRC1ST00vMS4zLjE+IGF0IGF0YTEtbWFzdGVyIFdETUEyCnN5bTA6IHVua25vd24gaW50
ZXJydXB0KHMpIGlnbm9yZWQsIElTVEFUPTB4MSBEU1RBVD0weDgwIFNJU1Q9MHgwCmRhMCBh
dCBzeW0wIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMApkYTA6IDxRRU1VIFFFTVUgSEFS
RERJU0sgMS4zLj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlCmRhMDogMy4z
MDBNQi9zIHRyYW5zZmVycwpkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApkYTA6IDgx
OTJNQiAoMTY3NzcyMTYgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAxMDQ0QykKVHJ5
aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9kYTBzMWEKQ29uZmlndXJpbmcgY3Jh
c2ggZHVtcHMuLi4KVXNpbmcgL2Rldi9kYTBzMWIgZm9yIGR1bXAgZGV2aWNlLgpNb3VudGlu
ZyBmaWxlc3lzdGVtcy4uLgpaRlMgTk9USUNFOiBQcmVmZXRjaCBpcyBkaXNhYmxlZCBieSBk
ZWZhdWx0IGlmIGxlc3MgdGhhbiA0R0Igb2YgUkFNIGlzIHByZXNlbnQ7CiAgICAgICAgICAg
IHRvIGVuYWJsZSwgYWRkICJ2ZnMuemZzLnByZWZldGNoX2Rpc2FibGU9MCIgdG8gL2Jvb3Qv
bG9hZGVyLmNvbmYuClpGUyBXQVJOSU5HOiBSZWNvbW1lbmRlZCBtaW5pbXVtIGttZW1fc2l6
ZSBpcyA1MTJNQjsgZXhwZWN0IHVuc3RhYmxlIGJlaGF2aW9yLgogICAgICAgICAgICAgQ29u
c2lkZXIgdHVuaW5nIHZtLmttZW1fc2l6ZSBhbmQgdm0ua21lbV9zaXplX21heAogICAgICAg
ICAgICAgaW4gL2Jvb3QvbG9hZGVyLmNvbmYuClpGUyBmaWxlc3lzdGVtIHZlcnNpb24gNQpa
RlMgc3RvcmFnZSBwb29sIHZlcnNpb24gMjgKCiAgICAgX19fCiBfX18vIGYgXAovIHAgXF9f
Xy8gU2Vuc2UKXF9fXy8gICBcCiAgICBcX19fLwoKV2VsY29tZSB0byBwZlNlbnNlIDIuMS41
LVJFTEVBU0UgIC4uLgoKTm8gY29yZSBkdW1wcyBmb3VuZC4KQ3JlYXRpbmcgc3ltbGlua3Mu
Li4uLi5kb25lLgo+Pj4gVW5kZXIgNTEyIG1lZ2FieXRlcyBvZiByYW0gZGV0ZWN0ZWQuICBO
b3QgZW5hYmxpbmcgQVBDLgpFeHRlcm5hbCBjb25maWcgbG9hZGVyIDEuMCBpcyBub3cgc3Rh
cnRpbmcuLi4KTGF1bmNoaW5nIHRoZSBpbml0IHN5c3RlbS4uLiBkb25lLgpJbml0aWFsaXpp
bmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBkb25lLgpTdGFydGluZyBkZXZpY2Ug
bWFuYWdlciAoZGV2ZCkuLi5kb25lLgpMb2FkaW5nIGNvbmZpZ3VyYXRpb24uLi4uLi5kb25l
LgpXYXJuaW5nOiBDb25maWd1cmF0aW9uIHJlZmVyZW5jZXMgaW50ZXJmYWNlcyB0aGF0IGRv
IG5vdCBleGlzdDogYXRoMCBybDAKCk5ldHdvcmsgaW50ZXJmYWNlIG1pc21hdGNoIC0tIFJ1
bm5pbmcgaW50ZXJmYWNlIGFzc2lnbm1lbnQgb3B0aW9uLgoKVmFsaWQgaW50ZXJmYWNlcyBh
cmU6CgplbTAgICAwMDoxNjozZTphMTo2NDowMSAgICh1cCkgSW50ZWwoUikgUFJPLzEwMDAg
TGVnYWN5IE5ldHdvcmsgQ29ubmVjdGlvbiAxLjAuNgoKRG8geW91IHdhbnQgdG8gc2V0IHVw
IFZMQU5zIGZpcnN0PwoKSWYgeW91IGFyZSBub3QgZ29pbmcgdG8gdXNlIFZMQU5zLCBvciBv
bmx5IGZvciBvcHRpb25hbCBpbnRlcmZhY2VzLCB5b3Ugc2hvdWxkCnNheSBubyBoZXJlIGFu
ZCB1c2UgdGhlIHdlYkNvbmZpZ3VyYXRvciB0byBjb25maWd1cmUgVkxBTnMgbGF0ZXIsIGlm
IHJlcXVpcmVkLgoKRG8geW91IHdhbnQgdG8gc2V0IHVwIFZMQU5zIG5vdyBbeXxuXT8gZW0w
OiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKCnBmU2Vuc2UgaXMgbm93IHNodXR0aW5nIGRv
d24gLi4uCgpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGB2
bmxydScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0
ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXggNjAg
c2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5jZXInIHRvIHN0b3AuLi4KU3luY2lu
ZyBkaXNrcywgdm5vZGVzIHJlbWFpbmluZy4uLjAgZG9uZQpBbGwgYnVmZmVycyBzeW5jZWQu
ClVwdGltZTogNG0xM3MKYWNwaTA6IFBvd2VyaW5nIHN5c3RlbSBvZmYKRG9tYWluIDIgaGFz
IHNodXQgZG93biwgcmVhc29uIGNvZGUgMCAweDAKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBBY3Rpb24gZm9yIHNodXRkb3duIHJlYXNvbiBjb2RlIDAgaXMg
ZGVzdHJveQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRG9tYWluIDIgbmVlZHMg
dG8gYmUgY2xlYW5lZCB1cDogZGVzdHJveWluZyB0aGUgZG9tYWluCiAgICAgICA9PTI0OTgy
PT0KICAgICAgICAgICAgICAgICA9PTI0OTgyPT0gUHJvY2VzcyB0ZXJtaW5hdGluZyB3aXRo
IGRlZmF1bHQgYWN0aW9uIG9mIHNpZ25hbCAxMSAoU0lHU0VHVikKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA9PTI0OTgyPT0gIEJhZCBwZXJtaXNzaW9ucyBmb3IgbWFw
cGVkIHJlZ2lvbiBhdCBhZGRyZXNzIDB4NDAzNUQ0MAogICAgICAgICAgICAgICAgICAgICAg
PT0yNDk4Mj09ICAgIGF0IDB4NTZFREI5NTogc2lnY2FuY2VsX2hhbmRsZXIgKG5wdGwtaW5p
dC5jOjE3NCkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPT0yNDk4Mj09CiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9PTI0OTgyPT0gSEVBUCBTVU1N
QVJZOgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA9PTI0OTgyPT0gICAgIGluIHVzZSBhdCBleGl0OiA3LDU4MCBieXRl
cyBpbiA1MCBibG9ja3MKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PT0yNDk4Mj09ICAgdG90YWwgaGVhcCB1c2FnZTogMSw2ODggYWxsb2NzLCAxLDYzOCBmcmVl
cywgNCw5NzgsMjY1IGJ5dGVzIGFsbG9jYXRlZAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPT0yNDk4Mj09CiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPT0yNDk4Mj09IExFQUsgU1VNTUFSWToKICAgICAgICAg
ICAgICAgICAgICAgID09MjQ5ODI9PSAgICBkZWZpbml0ZWx5IGxvc3Q6IDUxNiBieXRlcyBp
biA3IGJsb2NrcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPT0yNDk4Mj09ICAgIGluZGlyZWN0bHkg
bG9zdDogMCBieXRlcyBpbiAwIGJsb2NrcwogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID09MjQ5ODI9PSAgICAg
IHBvc3NpYmx5IGxvc3Q6IDU3NiBieXRlcyBpbiAyIGJsb2NrcwogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgID09MjQ5ODI9PSAgICBzdGlsbCByZWFjaGFibGU6
IDYsNDg4IGJ5dGVzIGluIDQxIGJsb2NrcwogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgID09MjQ5ODI9PSAgICAgICAgIHN1cHByZXNzZWQ6IDAgYnl0ZXMgaW4g
MCBibG9ja3MKICAgICAgICAgICAgPT0yNDk4Mj09IFJlcnVuIHdpdGggLS1sZWFrLWNoZWNr
PWZ1bGwgdG8gc2VlIGRldGFpbHMgb2YgbGVha2VkIG1lbW9yeQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPT0yNDk4Mj09CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPT0yNDk4Mj09IEZvciBjb3VudHMgb2YgZGV0ZWN0ZWQgYW5kIHN1cHByZXNzZWQg
ZXJyb3JzLCByZXJ1biB3aXRoOiAtdgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9
PTI0OTgyPT0gRVJST1IgU1VNTUFSWTogMCBlcnJvcnMgZnJvbSAwIGNvbnRleHRzIChzdXBw
cmVzc2VkOiAwIGZyb20gMCkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgS2lsbGVkCgo=
--------------000605000609080501090206
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000605000609080501090206--


From xen-devel-bounces@lists.xen.org Wed Nov 05 12:39:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 12:39:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlzrd-0008V6-VT; Wed, 05 Nov 2014 12:39:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlzrd-0008V1-7g
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 12:39:05 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	F3/95-02953-86A1A545; Wed, 05 Nov 2014 12:39:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415191142!12691591!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27217 invoked from network); 5 Nov 2014 12:39:04 -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;
	5 Nov 2014 12:39:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188283846"
Message-ID: <1415191140.15317.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Wed, 5 Nov 2014 12:39:00 +0000
In-Reply-To: <545A118B.7040309@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
	<1415180713.11486.61.camel@citrix.com> <545A118B.7040309@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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 Wed, 2014-11-05 at 13:01 +0100, Atom2 wrote:

Thanks for all that, sadly it's not giving me any clues what is going
wrong :-/

> To me, it looks as if something is broken with the PCI passthrough stuff 
> and that has started with 4.3.3. Strangely however, valgrind seems to 
> work around that issue insofar that no segfault happens. Is there any 
> explanation of the different behaviour between native execution of xl 
> and starting xl under valgrind's control?

Valgrind has it's own memory allocator etc, but it's supposed to catch
errors, not hide them. I think even 3.10.0 is missing support for some
hypercalls which are being used by passthrough, which is why we are
continuing to see different behaviours.

I think we are reaching the point of diminishing returns with vagrind.
It probably is worth rerunning with "-v --leak-check=full", but after
that we'd be looking at adding valgrind patches for the new hypercalls,
which I don't think will be worthwhile (although I intend to write the
patches anyway).

So unless "-v --leak-check=full" tells me something (which I'm doubtful
of at this stage) I think we're back to bisecting the changes since
4.3.1, sorry.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 12:39:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 12:39:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlzrd-0008V6-VT; Wed, 05 Nov 2014 12:39:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlzrd-0008V1-7g
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 12:39:05 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	F3/95-02953-86A1A545; Wed, 05 Nov 2014 12:39:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415191142!12691591!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27217 invoked from network); 5 Nov 2014 12:39:04 -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;
	5 Nov 2014 12:39:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188283846"
Message-ID: <1415191140.15317.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Wed, 5 Nov 2014 12:39:00 +0000
In-Reply-To: <545A118B.7040309@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
	<1415180713.11486.61.camel@citrix.com> <545A118B.7040309@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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 Wed, 2014-11-05 at 13:01 +0100, Atom2 wrote:

Thanks for all that, sadly it's not giving me any clues what is going
wrong :-/

> To me, it looks as if something is broken with the PCI passthrough stuff 
> and that has started with 4.3.3. Strangely however, valgrind seems to 
> work around that issue insofar that no segfault happens. Is there any 
> explanation of the different behaviour between native execution of xl 
> and starting xl under valgrind's control?

Valgrind has it's own memory allocator etc, but it's supposed to catch
errors, not hide them. I think even 3.10.0 is missing support for some
hypercalls which are being used by passthrough, which is why we are
continuing to see different behaviours.

I think we are reaching the point of diminishing returns with vagrind.
It probably is worth rerunning with "-v --leak-check=full", but after
that we'd be looking at adding valgrind patches for the new hypercalls,
which I don't think will be worthwhile (although I intend to write the
patches anyway).

So unless "-v --leak-check=full" tells me something (which I'm doubtful
of at this stage) I think we're back to bisecting the changes since
4.3.1, sorry.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 12:46:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 12: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 1XlzyF-0000Nd-32; Wed, 05 Nov 2014 12:45:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XlzyD-0000NY-Cx
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 12:45:53 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	E3/84-05632-00C1A545; Wed, 05 Nov 2014 12:45:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415191550!11817879!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22943 invoked from network); 5 Nov 2014 12:45:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 12:45:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188285788"
Message-ID: <545A1BFC.5090505@citrix.com>
Date: Wed, 5 Nov 2014 12:45:48 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, Atom2 <ariel.atom2@web2web.at>
References: <544EB843.9060503@web2web.at>	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>	<5452C43C.6050800@web2web.at>
	<5458ED27.8060502@web2web.at>	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>	<1415118690.11486.53.camel@citrix.com>
	<54590D4D.90300@web2web.at>	<1415180713.11486.61.camel@citrix.com>
	<545A118B.7040309@web2web.at>
	<1415191140.15317.11.camel@citrix.com>
In-Reply-To: <1415191140.15317.11.camel@citrix.com>
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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 05/11/14 12:39, Ian Campbell wrote:
> On Wed, 2014-11-05 at 13:01 +0100, Atom2 wrote:
>
> Thanks for all that, sadly it's not giving me any clues what is going
> wrong :-/
>
>> To me, it looks as if something is broken with the PCI passthrough stuff 
>> and that has started with 4.3.3. Strangely however, valgrind seems to 
>> work around that issue insofar that no segfault happens. Is there any 
>> explanation of the different behaviour between native execution of xl 
>> and starting xl under valgrind's control?
> Valgrind has it's own memory allocator etc, but it's supposed to catch
> errors, not hide them. I think even 3.10.0 is missing support for some
> hypercalls which are being used by passthrough, which is why we are
> continuing to see different behaviours.
>
> I think we are reaching the point of diminishing returns with vagrind.
> It probably is worth rerunning with "-v --leak-check=full", but after
> that we'd be looking at adding valgrind patches for the new hypercalls,
> which I don't think will be worthwhile (although I intend to write the
> patches anyway).
>
> So unless "-v --leak-check=full" tells me something (which I'm doubtful
> of at this stage) I think we're back to bisecting the changes since
> 4.3.1, sorry.

The lack valgrind support for XEN_DOMCTL_test_assign is causing PCI
Passthrough to fail.

This is where "libxl: error: libxl_pci.c:1045:libxl__device_pci_add: PCI
device 0000:0a:0b.0 cannot be assigned - no IOMMU?" comes from.

While I do have 10 patches I really should get around to upstreaming
into valgrind, the passthrough hypercalls are not amongst them.  Fixing
XEN_DOMCTL_test_assign is only the first step.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 12:46:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 12: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 1XlzyF-0000Nd-32; Wed, 05 Nov 2014 12:45:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XlzyD-0000NY-Cx
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 12:45:53 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	E3/84-05632-00C1A545; Wed, 05 Nov 2014 12:45:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415191550!11817879!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22943 invoked from network); 5 Nov 2014 12:45:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 12:45:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="188285788"
Message-ID: <545A1BFC.5090505@citrix.com>
Date: Wed, 5 Nov 2014 12:45:48 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, Atom2 <ariel.atom2@web2web.at>
References: <544EB843.9060503@web2web.at>	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>	<5452C43C.6050800@web2web.at>
	<5458ED27.8060502@web2web.at>	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>	<1415118690.11486.53.camel@citrix.com>
	<54590D4D.90300@web2web.at>	<1415180713.11486.61.camel@citrix.com>
	<545A118B.7040309@web2web.at>
	<1415191140.15317.11.camel@citrix.com>
In-Reply-To: <1415191140.15317.11.camel@citrix.com>
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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 05/11/14 12:39, Ian Campbell wrote:
> On Wed, 2014-11-05 at 13:01 +0100, Atom2 wrote:
>
> Thanks for all that, sadly it's not giving me any clues what is going
> wrong :-/
>
>> To me, it looks as if something is broken with the PCI passthrough stuff 
>> and that has started with 4.3.3. Strangely however, valgrind seems to 
>> work around that issue insofar that no segfault happens. Is there any 
>> explanation of the different behaviour between native execution of xl 
>> and starting xl under valgrind's control?
> Valgrind has it's own memory allocator etc, but it's supposed to catch
> errors, not hide them. I think even 3.10.0 is missing support for some
> hypercalls which are being used by passthrough, which is why we are
> continuing to see different behaviours.
>
> I think we are reaching the point of diminishing returns with vagrind.
> It probably is worth rerunning with "-v --leak-check=full", but after
> that we'd be looking at adding valgrind patches for the new hypercalls,
> which I don't think will be worthwhile (although I intend to write the
> patches anyway).
>
> So unless "-v --leak-check=full" tells me something (which I'm doubtful
> of at this stage) I think we're back to bisecting the changes since
> 4.3.1, sorry.

The lack valgrind support for XEN_DOMCTL_test_assign is causing PCI
Passthrough to fail.

This is where "libxl: error: libxl_pci.c:1045:libxl__device_pci_add: PCI
device 0000:0a:0b.0 cannot be assigned - no IOMMU?" comes from.

While I do have 10 patches I really should get around to upstreaming
into valgrind, the passthrough hypercalls are not amongst them.  Fixing
XEN_DOMCTL_test_assign is only the first step.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 12:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 12:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlzzl-0000Uh-Om; Wed, 05 Nov 2014 12:47:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlzzk-0000UX-Oy
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 12:47:28 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	E4/47-17958-06C1A545; Wed, 05 Nov 2014 12:47:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415191645!8077240!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17550 invoked from network); 5 Nov 2014 12:47:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 12:47:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189684282"
Message-ID: <1415191641.15317.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 5 Nov 2014 12:47:21 +0000
In-Reply-To: <545A1BFC.5090505@citrix.com>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
	<1415180713.11486.61.camel@citrix.com> <545A118B.7040309@web2web.at>
	<1415191140.15317.11.camel@citrix.com> <545A1BFC.5090505@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Atom2 <ariel.atom2@web2web.at>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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 Wed, 2014-11-05 at 12:45 +0000, Andrew Cooper wrote:
> On 05/11/14 12:39, Ian Campbell wrote:
> > On Wed, 2014-11-05 at 13:01 +0100, Atom2 wrote:
> >
> > Thanks for all that, sadly it's not giving me any clues what is going
> > wrong :-/
> >
> >> To me, it looks as if something is broken with the PCI passthrough stuff 
> >> and that has started with 4.3.3. Strangely however, valgrind seems to 
> >> work around that issue insofar that no segfault happens. Is there any 
> >> explanation of the different behaviour between native execution of xl 
> >> and starting xl under valgrind's control?
> > Valgrind has it's own memory allocator etc, but it's supposed to catch
> > errors, not hide them. I think even 3.10.0 is missing support for some
> > hypercalls which are being used by passthrough, which is why we are
> > continuing to see different behaviours.
> >
> > I think we are reaching the point of diminishing returns with vagrind.
> > It probably is worth rerunning with "-v --leak-check=full", but after
> > that we'd be looking at adding valgrind patches for the new hypercalls,
> > which I don't think will be worthwhile (although I intend to write the
> > patches anyway).
> >
> > So unless "-v --leak-check=full" tells me something (which I'm doubtful
> > of at this stage) I think we're back to bisecting the changes since
> > 4.3.1, sorry.
> 
> The lack valgrind support for XEN_DOMCTL_test_assign is causing PCI
> Passthrough to fail.
> 
> This is where "libxl: error: libxl_pci.c:1045:libxl__device_pci_add: PCI
> device 0000:0a:0b.0 cannot be assigned - no IOMMU?" comes from.
> 
> While I do have 10 patches I really should get around to upstreaming
> into valgrind, the passthrough hypercalls are not amongst them.  Fixing
> XEN_DOMCTL_test_assign is only the first step.

I've just written (but not tested) that one.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 12:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 12:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xlzzl-0000Uh-Om; Wed, 05 Nov 2014 12:47:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xlzzk-0000UX-Oy
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 12:47:28 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	E4/47-17958-06C1A545; Wed, 05 Nov 2014 12:47:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415191645!8077240!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17550 invoked from network); 5 Nov 2014 12:47:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 12:47:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,319,1413244800"; d="scan'208";a="189684282"
Message-ID: <1415191641.15317.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 5 Nov 2014 12:47:21 +0000
In-Reply-To: <545A1BFC.5090505@citrix.com>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
	<1415180713.11486.61.camel@citrix.com> <545A118B.7040309@web2web.at>
	<1415191140.15317.11.camel@citrix.com> <545A1BFC.5090505@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Atom2 <ariel.atom2@web2web.at>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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 Wed, 2014-11-05 at 12:45 +0000, Andrew Cooper wrote:
> On 05/11/14 12:39, Ian Campbell wrote:
> > On Wed, 2014-11-05 at 13:01 +0100, Atom2 wrote:
> >
> > Thanks for all that, sadly it's not giving me any clues what is going
> > wrong :-/
> >
> >> To me, it looks as if something is broken with the PCI passthrough stuff 
> >> and that has started with 4.3.3. Strangely however, valgrind seems to 
> >> work around that issue insofar that no segfault happens. Is there any 
> >> explanation of the different behaviour between native execution of xl 
> >> and starting xl under valgrind's control?
> > Valgrind has it's own memory allocator etc, but it's supposed to catch
> > errors, not hide them. I think even 3.10.0 is missing support for some
> > hypercalls which are being used by passthrough, which is why we are
> > continuing to see different behaviours.
> >
> > I think we are reaching the point of diminishing returns with vagrind.
> > It probably is worth rerunning with "-v --leak-check=full", but after
> > that we'd be looking at adding valgrind patches for the new hypercalls,
> > which I don't think will be worthwhile (although I intend to write the
> > patches anyway).
> >
> > So unless "-v --leak-check=full" tells me something (which I'm doubtful
> > of at this stage) I think we're back to bisecting the changes since
> > 4.3.1, sorry.
> 
> The lack valgrind support for XEN_DOMCTL_test_assign is causing PCI
> Passthrough to fail.
> 
> This is where "libxl: error: libxl_pci.c:1045:libxl__device_pci_add: PCI
> device 0000:0a:0b.0 cannot be assigned - no IOMMU?" comes from.
> 
> While I do have 10 patches I really should get around to upstreaming
> into valgrind, the passthrough hypercalls are not amongst them.  Fixing
> XEN_DOMCTL_test_assign is only the first step.

I've just written (but not tested) that one.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 13:05:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 13:05:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm0GU-00015s-Ot; Wed, 05 Nov 2014 13:04:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm0GT-00015i-FA
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 13:04:45 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	31/2D-09936-C602A545; Wed, 05 Nov 2014 13:04:44 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415192683!12986768!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27725 invoked from network); 5 Nov 2014 13:04:43 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 13:04:43 -0000
Received: by mail-wi0-f177.google.com with SMTP id ex7so1928800wid.10
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 05:04:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=v/WeGotGTYISDGVoR1DI4LNBP03xxnz9EwoiDLyB/gk=;
	b=MLH14PoE9EgVEZHTFdtAhLg+xOgOJjl4jXBLEHpNMl2tyNfbpiKM/0+uWZ/ypWGbqy
	k1u8tfPOJFMgsiCzy4DdVUrR7RCuzBNqXcuh1fgwS869HpvSF96EvsaMIilthhLUBs0Z
	eYX+B4oXFAEwdOAsbdTWzeza1Q4g2yxmKhVlhfV/JBrW7w7TR7flgwG9yi0XKTml7ntq
	nakZGqq0d5yhsS3WqrcVemb68pSlstEW+SSuvhlo8zwk8NUukUHlR8uUpr0XwC7MIbA7
	jbP3GjHszb8RM0eIUXui7wvTy2SOCqOzzdoykPmkqt3gdGxD8Jx1Mh+6fGuikD10cr6R
	QF+A==
X-Gm-Message-State: ALoCoQnpF1/9DAbUegiDtHh6PhSKlGoWPvIVydzQD54qEOA/Nte2pBBKfJYxYrv9CVuEcreCT+Xx
X-Received: by 10.180.91.104 with SMTP id cd8mr5626887wib.46.1415192683313;
	Wed, 05 Nov 2014 05:04:43 -0800 (PST)
Received: from belegaer.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id wx3sm4037980wjc.19.2014.11.05.05.04.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 05 Nov 2014 05:04:42 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Wed,  5 Nov 2014 13:04:22 +0000
Message-Id: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 1.7.10.4
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3 for
	domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 vGIC will emulate the same version as the hardware. The toolstack has
to retrieve the version of the vGIC in order to be able to create the
corresponding device tree node.

A new DOMCTL has been introduced for ARM to configure the domain. For now
it only allow the toolstack to retrieve the version of vGIC.
This DOMCTL will be extend later to let the user choose the version of the
emulated GIC.

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Wei Liu <wei.liu2@citrix.com>

---
Stefano, I made one change in the guest memory layout, so I've dropped you
Reviewed-by.

    Changes in v3:
        - Typo and update some comments
        - Coding style
        - Only reserve space for an 8 VCPUs redistributor in the guest
        memory layout

    Changes in v2:
        - Use memcpu in xc_domain_configure
        - Rename the DOMCTL into domctl_arm_configuredomain
        - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
        and fold the code in arch_domain_init_hw_description
        - Return -EOPNOTSUPP when the value of gic_version is not
        supported

This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
defer the initialization of the vGIC [2].

Xen 4.5 has already support for the hardware GICv3. While it's possible to
boot and use DOM0, there is no guest support. The first version of this patch
has been sent a couple of months ago, but has never reached unstable for
various reasons (based on deferred series, lake of review at that time...).
Without it, platform with GICv3 support won't be able to boot any guest.

The patch has been reworked to make it acceptable for Xen 4.5. Except the new
DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.

Features such as adding a new config option to let the user choose the GIC
version are deferred to Xen 4.6.

It has been tested on both GICv2/GICv3 platform. And build tested for x86.

[1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
[2] https://patches.linaro.org/34664/
---
 tools/flask/policy/policy/modules/xen/xen.if |    2 +-
 tools/libxc/include/xenctrl.h                |    6 ++
 tools/libxc/xc_domain.c                      |   20 ++++++
 tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
 xen/arch/arm/domctl.c                        |   35 ++++++++++
 xen/arch/arm/gic-v3.c                        |   16 ++++-
 xen/include/public/arch-arm.h                |   16 +++++
 xen/include/public/domctl.h                  |   17 +++++
 xen/xsm/flask/hooks.c                        |    3 +
 xen/xsm/flask/policy/access_vectors          |    2 +
 10 files changed, 204 insertions(+), 8 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 641c797..fa69c9d 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -49,7 +49,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			getscheduler getvcpuinfo getvcpuextstate getaddrsize
 			getaffinity setaffinity };
-	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
+	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 564e187..45e282c 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
                      uint32_t flags,
                      uint32_t *pdomid);
 
+#if defined(__arm__) || defined(__aarch64__)
+typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
+
+int xc_domain_configure(xc_interface *xch, uint32_t domid,
+                        xc_domain_configuration_t *config);
+#endif
 
 /* Functions to produce a dump of a given domain
  *  xc_domain_dumpcore - produces a dump to a specified file
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index a9bcd4a..b071dea 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
     return 0;
 }
 
+#if defined(__arm__) || defined(__aarch64__)
+int xc_domain_configure(xc_interface *xch, uint32_t domid,
+                        xc_domain_configuration_t *config)
+{
+    int rc;
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
+    domctl.domain = (domid_t)domid;
+    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
+    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
+
+    rc = do_domctl(xch, &domctl);
+    if ( !rc )
+        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
+
+    return rc;
+}
+#endif
+
 int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
                          xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
 {
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index a122e4a..448ac07 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -23,6 +23,18 @@
 #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
 #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
 
+static const char *gicv_to_string(uint8_t gic_version)
+{
+    switch (gic_version) {
+    case XEN_DOMCTL_CONFIG_GIC_V2:
+        return "V2";
+    case XEN_DOMCTL_CONFIG_GIC_V3:
+        return "V3";
+    default:
+        return "unknown";
+    }
+}
+
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                               uint32_t domid)
 {
@@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
     return 0;
 }
 
-static int make_intc_node(libxl__gc *gc, void *fdt,
-                          uint64_t gicd_base, uint64_t gicd_size,
-                          uint64_t gicc_base, uint64_t gicc_size)
+static int make_gicv2_node(libxl__gc *gc, void *fdt,
+                           uint64_t gicd_base, uint64_t gicd_size,
+                           uint64_t gicc_base, uint64_t gicc_size)
 {
     int res;
     const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
@@ -350,6 +362,56 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
     return 0;
 }
 
+static int make_gicv3_node(libxl__gc *gc, void *fdt)
+{
+    int res;
+    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
+    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
+    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
+    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
+    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
+
+    res = fdt_begin_node(fdt, name);
+    if (res) return res;
+
+    res = fdt_property_compat(gc, fdt, 1, "arm,gic-v3");
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#address-cells", 0);
+    if (res) return res;
+
+    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "redistributor-stride",
+                            GUEST_GICV3_RDIST_STRIDE);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#redistributor-regions",
+                            GUEST_GICV3_RDIST_REGIONS);
+    if (res) return res;
+
+    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
+                            2,
+                            gicd_base, gicd_size,
+                            gicr0_base, gicr0_size);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
+    if (res) return res;
+
+    res = fdt_end_node(fdt);
+    if (res) return res;
+
+    return 0;
+}
+
 static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
 {
     int res;
@@ -456,6 +518,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl_domain_build_info *info,
                                            struct xc_dom_image *dom)
 {
+    xc_domain_configuration_t config;
     void *fdt = NULL;
     int rc, res;
     size_t fdt_size = 0;
@@ -471,8 +534,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
     ainfo = get_arch_info(gc, dom);
     if (ainfo == NULL) return ERROR_FAIL;
 
+    LOG(DEBUG, "configure the domain");
+    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
+    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
+        LOG(ERROR, "couldn't configure the domain");
+        return ERROR_FAIL;
+    }
+
     LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
         vers->xen_version_major, vers->xen_version_minor);
+    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
 
 /*
  * Call "call" handling FDR_ERR_*. Will either:
@@ -520,9 +591,21 @@ next_resize:
         FDT( make_psci_node(gc, fdt) );
 
         FDT( make_memory_nodes(gc, fdt, dom) );
-        FDT( make_intc_node(gc, fdt,
-                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
-                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
+
+        switch (config.gic_version) {
+        case XEN_DOMCTL_CONFIG_GIC_V2:
+            FDT( make_gicv2_node(gc, fdt,
+                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
+                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
+            break;
+        case XEN_DOMCTL_CONFIG_GIC_V3:
+            FDT( make_gicv3_node(gc, fdt) );
+            break;
+        default:
+            LOG(ERROR, "Unknown GIC version %d", config.gic_version);
+            rc = ERROR_FAIL;
+            goto out;
+        }
 
         FDT( make_timer_node(gc, fdt, ainfo) );
         FDT( make_hypervisor_node(gc, fdt, vers) );
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 45974e7..d246e84 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -10,6 +10,8 @@
 #include <xen/errno.h>
 #include <xen/sched.h>
 #include <xen/hypercall.h>
+#include <asm/gic.h>
+#include <xen/guest_access.h>
 #include <public/domctl.h>
 
 long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
@@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 
         return p2m_cache_flush(d, s, e);
     }
+    case XEN_DOMCTL_arm_configure_domain:
+    {
+        uint8_t gic_version;
+
+        /*
+         * Currently the vGIC is emulating the same version of the
+         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
+         * is allowed. The DOMCTL will return the actual version of the
+         * GIC.
+         */
+        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
+            return -EOPNOTSUPP;
+
+        switch ( gic_hw_version() )
+        {
+        case GIC_V3:
+            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+            break;
+        case GIC_V2:
+            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
+            break;
+        default:
+            BUG();
+        }
+
+        domctl->u.configuredomain.gic_version = gic_version;
+
+        /* TODO: Make the copy generic for all ARCH domctl */
+        if ( __copy_to_guest(u_domctl, domctl, 1) )
+            return -EFAULT;
+
+        return 0;
+    }
 
     default:
         return subarch_do_domctl(domctl, d, u_domctl);
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 91161a2..076aa62 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
         d->arch.vgic.rdist_count = gicv3.rdist_count;
     }
     else
-        d->arch.vgic.dbase = GUEST_GICD_BASE;
+    {
+        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
+        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
+
+        /* XXX: Only one Re-distributor region mapped for the guest */
+        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
+
+        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
+        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
+
+        /* The first redistributor should contain enough space for all CPUs */
+        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
+        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
+        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
+    }
 
     d->arch.vgic.nr_lines = 0;
 
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index eecc561..72d641f 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
  */
 
 /* Physical Address Space */
+
+/* vGIC mappings: Only one set of mapping is used by the guest.
+ * Therefore they can overlap.
+ */
+
+/* vGIC v2 mappings */
 #define GUEST_GICD_BASE   0x03001000ULL
 #define GUEST_GICD_SIZE   0x00001000ULL
 #define GUEST_GICC_BASE   0x03002000ULL
 #define GUEST_GICC_SIZE   0x00000100ULL
 
+/* vGIC v3 mappings */
+#define GUEST_GICV3_GICD_BASE      0x03001000ULL
+#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
+
+#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
+#define GUEST_GICV3_RDIST_REGIONS  1
+
+#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU7 */
+#define GUEST_GICV3_GICR0_SIZE     0x00100000ULL
+
 /* 16MB == 4096 pages reserved for guest to use as a region to map its
  * grant table in.
  */
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 58b19e7..8da204e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
 
+#if defined(__arm__) || defined(__aarch64__)
+#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
+#define XEN_DOMCTL_CONFIG_GIC_V2        1
+#define XEN_DOMCTL_CONFIG_GIC_V3        2
+/* XEN_DOMCTL_configure_domain */
+struct xen_domctl_arm_configuredomain {
+    /* IN/OUT parameters */
+    uint8_t gic_version;
+};
+typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
+#endif
+
 /* XEN_DOMCTL_getdomaininfo */
 struct xen_domctl_getdomaininfo {
     /* OUT variables. */
@@ -1056,6 +1069,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_vcpu_msrs                 73
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
+#define XEN_DOMCTL_arm_configure_domain          76
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1064,6 +1078,9 @@ struct xen_domctl {
     domid_t  domain;
     union {
         struct xen_domctl_createdomain      createdomain;
+#if defined(__arm__) || defined(__aarch64__)
+        struct xen_domctl_arm_configuredomain configuredomain;
+#endif
         struct xen_domctl_getdomaininfo     getdomaininfo;
         struct xen_domctl_getmemlist        getmemlist;
         struct xen_domctl_getpageframeinfo  getpageframeinfo;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d0fe72..846cf88 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_psr_cmt_op:
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
 
+    case XEN_DOMCTL_configure_domain:
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
+
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
         return -EPERM;
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index de0c707..bfe2fa5 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -216,6 +216,8 @@ class domain2
     get_vnumainfo
 # XEN_DOMCTL_psr_cmt_op
     psr_cmt_op
+# XEN_DOMCTL_configure_domain
+    configure_domain
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 13:05:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 13:05:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm0GU-00015s-Ot; Wed, 05 Nov 2014 13:04:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm0GT-00015i-FA
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 13:04:45 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	31/2D-09936-C602A545; Wed, 05 Nov 2014 13:04:44 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415192683!12986768!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27725 invoked from network); 5 Nov 2014 13:04:43 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 13:04:43 -0000
Received: by mail-wi0-f177.google.com with SMTP id ex7so1928800wid.10
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 05:04:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=v/WeGotGTYISDGVoR1DI4LNBP03xxnz9EwoiDLyB/gk=;
	b=MLH14PoE9EgVEZHTFdtAhLg+xOgOJjl4jXBLEHpNMl2tyNfbpiKM/0+uWZ/ypWGbqy
	k1u8tfPOJFMgsiCzy4DdVUrR7RCuzBNqXcuh1fgwS869HpvSF96EvsaMIilthhLUBs0Z
	eYX+B4oXFAEwdOAsbdTWzeza1Q4g2yxmKhVlhfV/JBrW7w7TR7flgwG9yi0XKTml7ntq
	nakZGqq0d5yhsS3WqrcVemb68pSlstEW+SSuvhlo8zwk8NUukUHlR8uUpr0XwC7MIbA7
	jbP3GjHszb8RM0eIUXui7wvTy2SOCqOzzdoykPmkqt3gdGxD8Jx1Mh+6fGuikD10cr6R
	QF+A==
X-Gm-Message-State: ALoCoQnpF1/9DAbUegiDtHh6PhSKlGoWPvIVydzQD54qEOA/Nte2pBBKfJYxYrv9CVuEcreCT+Xx
X-Received: by 10.180.91.104 with SMTP id cd8mr5626887wib.46.1415192683313;
	Wed, 05 Nov 2014 05:04:43 -0800 (PST)
Received: from belegaer.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id wx3sm4037980wjc.19.2014.11.05.05.04.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 05 Nov 2014 05:04:42 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Wed,  5 Nov 2014 13:04:22 +0000
Message-Id: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 1.7.10.4
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3 for
	domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 vGIC will emulate the same version as the hardware. The toolstack has
to retrieve the version of the vGIC in order to be able to create the
corresponding device tree node.

A new DOMCTL has been introduced for ARM to configure the domain. For now
it only allow the toolstack to retrieve the version of vGIC.
This DOMCTL will be extend later to let the user choose the version of the
emulated GIC.

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Wei Liu <wei.liu2@citrix.com>

---
Stefano, I made one change in the guest memory layout, so I've dropped you
Reviewed-by.

    Changes in v3:
        - Typo and update some comments
        - Coding style
        - Only reserve space for an 8 VCPUs redistributor in the guest
        memory layout

    Changes in v2:
        - Use memcpu in xc_domain_configure
        - Rename the DOMCTL into domctl_arm_configuredomain
        - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
        and fold the code in arch_domain_init_hw_description
        - Return -EOPNOTSUPP when the value of gic_version is not
        supported

This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
defer the initialization of the vGIC [2].

Xen 4.5 has already support for the hardware GICv3. While it's possible to
boot and use DOM0, there is no guest support. The first version of this patch
has been sent a couple of months ago, but has never reached unstable for
various reasons (based on deferred series, lake of review at that time...).
Without it, platform with GICv3 support won't be able to boot any guest.

The patch has been reworked to make it acceptable for Xen 4.5. Except the new
DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.

Features such as adding a new config option to let the user choose the GIC
version are deferred to Xen 4.6.

It has been tested on both GICv2/GICv3 platform. And build tested for x86.

[1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
[2] https://patches.linaro.org/34664/
---
 tools/flask/policy/policy/modules/xen/xen.if |    2 +-
 tools/libxc/include/xenctrl.h                |    6 ++
 tools/libxc/xc_domain.c                      |   20 ++++++
 tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
 xen/arch/arm/domctl.c                        |   35 ++++++++++
 xen/arch/arm/gic-v3.c                        |   16 ++++-
 xen/include/public/arch-arm.h                |   16 +++++
 xen/include/public/domctl.h                  |   17 +++++
 xen/xsm/flask/hooks.c                        |    3 +
 xen/xsm/flask/policy/access_vectors          |    2 +
 10 files changed, 204 insertions(+), 8 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 641c797..fa69c9d 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -49,7 +49,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			getscheduler getvcpuinfo getvcpuextstate getaddrsize
 			getaffinity setaffinity };
-	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
+	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 564e187..45e282c 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
                      uint32_t flags,
                      uint32_t *pdomid);
 
+#if defined(__arm__) || defined(__aarch64__)
+typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
+
+int xc_domain_configure(xc_interface *xch, uint32_t domid,
+                        xc_domain_configuration_t *config);
+#endif
 
 /* Functions to produce a dump of a given domain
  *  xc_domain_dumpcore - produces a dump to a specified file
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index a9bcd4a..b071dea 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
     return 0;
 }
 
+#if defined(__arm__) || defined(__aarch64__)
+int xc_domain_configure(xc_interface *xch, uint32_t domid,
+                        xc_domain_configuration_t *config)
+{
+    int rc;
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
+    domctl.domain = (domid_t)domid;
+    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
+    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
+
+    rc = do_domctl(xch, &domctl);
+    if ( !rc )
+        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
+
+    return rc;
+}
+#endif
+
 int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
                          xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
 {
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index a122e4a..448ac07 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -23,6 +23,18 @@
 #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
 #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
 
+static const char *gicv_to_string(uint8_t gic_version)
+{
+    switch (gic_version) {
+    case XEN_DOMCTL_CONFIG_GIC_V2:
+        return "V2";
+    case XEN_DOMCTL_CONFIG_GIC_V3:
+        return "V3";
+    default:
+        return "unknown";
+    }
+}
+
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                               uint32_t domid)
 {
@@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
     return 0;
 }
 
-static int make_intc_node(libxl__gc *gc, void *fdt,
-                          uint64_t gicd_base, uint64_t gicd_size,
-                          uint64_t gicc_base, uint64_t gicc_size)
+static int make_gicv2_node(libxl__gc *gc, void *fdt,
+                           uint64_t gicd_base, uint64_t gicd_size,
+                           uint64_t gicc_base, uint64_t gicc_size)
 {
     int res;
     const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
@@ -350,6 +362,56 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
     return 0;
 }
 
+static int make_gicv3_node(libxl__gc *gc, void *fdt)
+{
+    int res;
+    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
+    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
+    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
+    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
+    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
+
+    res = fdt_begin_node(fdt, name);
+    if (res) return res;
+
+    res = fdt_property_compat(gc, fdt, 1, "arm,gic-v3");
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#address-cells", 0);
+    if (res) return res;
+
+    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "redistributor-stride",
+                            GUEST_GICV3_RDIST_STRIDE);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "#redistributor-regions",
+                            GUEST_GICV3_RDIST_REGIONS);
+    if (res) return res;
+
+    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
+                            2,
+                            gicd_base, gicd_size,
+                            gicr0_base, gicr0_size);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
+    if (res) return res;
+
+    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
+    if (res) return res;
+
+    res = fdt_end_node(fdt);
+    if (res) return res;
+
+    return 0;
+}
+
 static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
 {
     int res;
@@ -456,6 +518,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl_domain_build_info *info,
                                            struct xc_dom_image *dom)
 {
+    xc_domain_configuration_t config;
     void *fdt = NULL;
     int rc, res;
     size_t fdt_size = 0;
@@ -471,8 +534,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
     ainfo = get_arch_info(gc, dom);
     if (ainfo == NULL) return ERROR_FAIL;
 
+    LOG(DEBUG, "configure the domain");
+    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
+    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
+        LOG(ERROR, "couldn't configure the domain");
+        return ERROR_FAIL;
+    }
+
     LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
         vers->xen_version_major, vers->xen_version_minor);
+    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
 
 /*
  * Call "call" handling FDR_ERR_*. Will either:
@@ -520,9 +591,21 @@ next_resize:
         FDT( make_psci_node(gc, fdt) );
 
         FDT( make_memory_nodes(gc, fdt, dom) );
-        FDT( make_intc_node(gc, fdt,
-                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
-                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
+
+        switch (config.gic_version) {
+        case XEN_DOMCTL_CONFIG_GIC_V2:
+            FDT( make_gicv2_node(gc, fdt,
+                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
+                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
+            break;
+        case XEN_DOMCTL_CONFIG_GIC_V3:
+            FDT( make_gicv3_node(gc, fdt) );
+            break;
+        default:
+            LOG(ERROR, "Unknown GIC version %d", config.gic_version);
+            rc = ERROR_FAIL;
+            goto out;
+        }
 
         FDT( make_timer_node(gc, fdt, ainfo) );
         FDT( make_hypervisor_node(gc, fdt, vers) );
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 45974e7..d246e84 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -10,6 +10,8 @@
 #include <xen/errno.h>
 #include <xen/sched.h>
 #include <xen/hypercall.h>
+#include <asm/gic.h>
+#include <xen/guest_access.h>
 #include <public/domctl.h>
 
 long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
@@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 
         return p2m_cache_flush(d, s, e);
     }
+    case XEN_DOMCTL_arm_configure_domain:
+    {
+        uint8_t gic_version;
+
+        /*
+         * Currently the vGIC is emulating the same version of the
+         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
+         * is allowed. The DOMCTL will return the actual version of the
+         * GIC.
+         */
+        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
+            return -EOPNOTSUPP;
+
+        switch ( gic_hw_version() )
+        {
+        case GIC_V3:
+            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+            break;
+        case GIC_V2:
+            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
+            break;
+        default:
+            BUG();
+        }
+
+        domctl->u.configuredomain.gic_version = gic_version;
+
+        /* TODO: Make the copy generic for all ARCH domctl */
+        if ( __copy_to_guest(u_domctl, domctl, 1) )
+            return -EFAULT;
+
+        return 0;
+    }
 
     default:
         return subarch_do_domctl(domctl, d, u_domctl);
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 91161a2..076aa62 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
         d->arch.vgic.rdist_count = gicv3.rdist_count;
     }
     else
-        d->arch.vgic.dbase = GUEST_GICD_BASE;
+    {
+        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
+        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
+
+        /* XXX: Only one Re-distributor region mapped for the guest */
+        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
+
+        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
+        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
+
+        /* The first redistributor should contain enough space for all CPUs */
+        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
+        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
+        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
+    }
 
     d->arch.vgic.nr_lines = 0;
 
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index eecc561..72d641f 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
  */
 
 /* Physical Address Space */
+
+/* vGIC mappings: Only one set of mapping is used by the guest.
+ * Therefore they can overlap.
+ */
+
+/* vGIC v2 mappings */
 #define GUEST_GICD_BASE   0x03001000ULL
 #define GUEST_GICD_SIZE   0x00001000ULL
 #define GUEST_GICC_BASE   0x03002000ULL
 #define GUEST_GICC_SIZE   0x00000100ULL
 
+/* vGIC v3 mappings */
+#define GUEST_GICV3_GICD_BASE      0x03001000ULL
+#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
+
+#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
+#define GUEST_GICV3_RDIST_REGIONS  1
+
+#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU7 */
+#define GUEST_GICV3_GICR0_SIZE     0x00100000ULL
+
 /* 16MB == 4096 pages reserved for guest to use as a region to map its
  * grant table in.
  */
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 58b19e7..8da204e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
 
+#if defined(__arm__) || defined(__aarch64__)
+#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
+#define XEN_DOMCTL_CONFIG_GIC_V2        1
+#define XEN_DOMCTL_CONFIG_GIC_V3        2
+/* XEN_DOMCTL_configure_domain */
+struct xen_domctl_arm_configuredomain {
+    /* IN/OUT parameters */
+    uint8_t gic_version;
+};
+typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
+#endif
+
 /* XEN_DOMCTL_getdomaininfo */
 struct xen_domctl_getdomaininfo {
     /* OUT variables. */
@@ -1056,6 +1069,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_vcpu_msrs                 73
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
+#define XEN_DOMCTL_arm_configure_domain          76
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1064,6 +1078,9 @@ struct xen_domctl {
     domid_t  domain;
     union {
         struct xen_domctl_createdomain      createdomain;
+#if defined(__arm__) || defined(__aarch64__)
+        struct xen_domctl_arm_configuredomain configuredomain;
+#endif
         struct xen_domctl_getdomaininfo     getdomaininfo;
         struct xen_domctl_getmemlist        getmemlist;
         struct xen_domctl_getpageframeinfo  getpageframeinfo;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d0fe72..846cf88 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_psr_cmt_op:
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
 
+    case XEN_DOMCTL_configure_domain:
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
+
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
         return -EPERM;
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index de0c707..bfe2fa5 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -216,6 +216,8 @@ class domain2
     get_vnumainfo
 # XEN_DOMCTL_psr_cmt_op
     psr_cmt_op
+# XEN_DOMCTL_configure_domain
+    configure_domain
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 13:22:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 13:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm0Wo-0001go-8D; Wed, 05 Nov 2014 13:21:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xm0Wm-0001gi-Es
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 13:21:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	76/6F-24532-F542A545; Wed, 05 Nov 2014 13:21:35 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415193672!12937056!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12352 invoked from network); 5 Nov 2014 13:21:13 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-21.messagelabs.com with SMTP;
	5 Nov 2014 13:21:13 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 05 Nov 2014 05:19:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,319,1413270000"; 
	d="pdf'?scan'208";a="631898662"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga002.jf.intel.com with ESMTP; 05 Nov 2014 05:21:02 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 21:21:00 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id
	14.03.0195.001; Wed, 5 Nov 2014 21:20:59 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
	machine
Thread-Index: AQHP91mlLJNh4IXOT0KpYuzQIm5vr5xRwUyw//+ZoYCAAKU94A==
Date: Wed, 5 Nov 2014 13:20:58 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820119@SHSMSX101.ccr.corp.intel.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031126170.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81FD36@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411051056500.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411051056500.22875@kaball.uk.xensource.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_945CA011AD5F084CBEA3E851C0AB28890E820119SHSMSX101ccrcor_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>, Daniel De
	Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
 machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_945CA011AD5F084CBEA3E851C0AB28890E820119SHSMSX101ccrcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Stefano Stabellini
> Sent: Wednesday, November 05, 2014 7:02 PM
> To: Xu, Quan
> Cc: keir@xen.org; ian.campbell@citrix.com; Stefano Stabellini; tim@xen.or=
g;
> ian.jackson@eu.citrix.com; xen-devel@lists.xen.org; jbeulich@suse.com;
> wei.liu2@citrix.com; Daniel De Graaf
> Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> virtual machine
>=20
> On Wed, 5 Nov 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Monday, November 03, 2014 7:30 PM
> > > To: Xu, Quan
> > > Cc: xen-devel@lists.xen.org; keir@xen.org; ian.campbell@citrix.com;
> > > tim@xen.org; ian.jackson@eu.citrix.com; jbeulich@suse.com
> > > Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> > > virtual machine
> > >
> > > On Thu, 30 Oct 2014, Quan Xu wrote:
> > > >
> > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > >
> > > > This patch series are only the Xen part to enable stubdom vTPM for
> > > > HVM
> > > virtual machine.
> > > > it will work w/ Qemu patch series and seaBios patch series. Change
> > > > QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the
> > > Qemu/SeaBios patch series are merged.
> > >
> > > Please, could you add more detailed commit messages in your patches?
> > > Also spending a few more words here to explain why are you doing
> > > this and how would help.
> > >
> > The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM
> > functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows
> > .etc). This allows programs to interact with a TPM in a virtual
> > machine the same way they interact with a TPM on the physical system.
> Each virtual machine gets its own unique, emulated, software TPM.
> > Each major component of vTPM is implemented as a stubdom, providing
> > secure separation guaranteed by the hypervisor.
> > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the
> > virtual machine to use. It is a small wrapper around the Berlios TPM
> > emulator. TPM commands are passed from mini-os TPM backend driver.
> >
> > This patch series are to enable Xen stubdom vTPM for HVM virtual
> > machine. his allows programs to interact with a TPM in a HVM virtual
> > machine(Fedora, Ubuntu, Redhat, Windows .etc) the same way they
> interact with a TPM on the physical system.
> >
> >
> > > It looks like you are trying to introduce vTPM stubdomains. The QEMU
> > > changes have been posted against upstream QEMU, that is good,
> > > however as far as I know upstream QEMU doesn't build or work as a
> stubdomain yet.
> > > Where are the changes to make upstream QEMU based stubdoms work?
> > > I don't see them neither here nor in the QEMU series.
> > >
> > It's Xen stubdom, not QEMU stubdom. Sorry for this confusion.
>=20
> What does "Xen stubdom" mean?
> I am still a bit confused, I replied to the other email.

It is StubDom, it is xen wiki about StubDom (http://wiki.xen.org/wiki/StubD=
om ).=20
Stubdoms (or stub domains) are lightweight 'service' or 'driver' domain to =
run device models and one technique to=20
implement Dom0 Disaggregation. The initial purpose of stub domains were to =
offload qemu workloads from dom0=20
into a seperate domain.

The following link is the wiki of vTPM.=20
http://wiki.xenproject.org/wiki/Virtual_Trusted_Platform_Module_%28vTPM%29=
=20
in 'vTPM Extensions in Xen 4.3 ' section,=20
[...]
Each major component of vTPM is implemented as a separate domain, providing=
 secure separation guaranteed by the=20
hypervisor. The vTPM domains are implemented in mini-os to reduce memory an=
d processor overhead.


-->=20
So 'Xen stubdom' is a separate domain, and implemented in mini-os.
My mistake, maybe 'Xen stubdom' is not a common Noun in community.=20

>=20
>=20
> > > How are you testing this work?
> >
> >
> > The following steps are how to build and test it:
> >
> > 1. SeaBios with my patch against upstream seabios is not submitted. I
> > will submit seabios patch when I finish these questions from review.
> > Now I archive my seabios patch against upstream seabios in
> > Github: https://github.com/virt2x/seabios2 , try to build it for test.
> >
> > Configure it with Xen,
> > --- <Xen> Config.mk
> > -SEABIOS_UPSTREAM_URL ?=3D git://xenbits.xen.org/seabios.git
> > +SEABIOS_UPSTREAM_URL ?=3D https://github.com/virt2x/seabios2
> > [...]
> > -SEABIOS_UPSTREAM_REVISION ?=3D rel-1.7.5
> > +SEABIOS_UPSTREAM_REVISION ?=3D
> ea94c083cc15875f46f0bf288b6531154b866f5a
> >
> > 2. qemu with my patch against upstream QEMU is not merged. now I
> > archive my qemu patch series again Upstream QEMU in github:
> > https://github.com/virt2x/qemu-xen-unstable2
> >
> > Configure it with Xen,
> > --- <Xen> Config.mk
> >
> > -QEMU_UPSTREAM_URL ?=3D
> git://xenbits.xen.org/qemu-upstream-unstable.git
> > +QEMU_UPSTREAM_URL ?=3D
> https://github.com/virt2x/qemu-xen-unstable2
> > -QEMU_UPSTREAM_REVISION ?=3D qemu-xen-4.5.0-rc1
> > +QEMU_UPSTREAM_REVISION ?=3D
> e867e6cf86c8412ca516cf2d0ccad57130e3388c
> >
> > 3. build/install Xen
> > Change QEMU_STUBDOM_VTPM option from 'n' to 'y'
> >    QEMU_STUBDOM_VTPM ?=3D y
> > ./configure --prefix=3D/usr
> > make dist
> > make install
>=20
> From the previous email, it looks like you are running QEMU in a Linux ba=
sed
> stubdom. If so, I don't see where are you creating it.

Not so,
The attach file is the picture of vTPM architecture.=20

>=20
>=20
> > 4. try to launch vtpmmgr / vtpm domain via
> <Xen>/docs/misc/vtpm-platforms.txt.
> > The reader is assumed to have familiarity with building and installing
> > Xen, Linux, and a basic understanding of the TPM and vTPM concepts.
> >
> > The Linux / Windows HVM guest configuration file needs to be modified t=
o
> include the following line:
> > [..]
> > vtpm=3D["backend=3Ddomu-vtpm"]
> > device_model_version =3D 'qemu-xen'
> > acpi =3D 1
> > [..]
> >
> > ## domu-vtpm is the name vtpm domain, A mini-os stub domain that
> implements a vTPM.
> >
> > 5. enable native TPM 1.2 drvier in HVM virtual machine. for example
> > enable tpm_tis.ko in Linux HVM virtual machine.
> > If you have trousers and tpm_tools installed on the guest, the
> > tpm_version command should return the following:
> >
> > The version command should return the following:
> >   TPM 1.2 Version Info:
> >   Chip Version:        1.2.0.7
> >   Spec Level:          2
> >   Errata Revision:     1
> >   TPM Vendor ID:       ETHZ
> >   TPM Version:         01010000
> >   Manufacturer Info:   4554485a
> >
> > Or check it with sysfs, /sys/class/misc/tpm0
> >
> >
> > BTW, Some local ISV are trying to integrate this feature into their
> > cloud service for trusted services, Such as trusted virtual desktop
> infrastructure(HVM fedora/ubuntu/redhat/windows virtual machine).
> >
> >
> > >
> > >
> > > >  Config.mk                             |  4 ++++
> > > >  extras/mini-os/include/tpmback.h      |  3 +++
> > > >  extras/mini-os/tpmback.c              | 20
> +++++++++++++++++---
> > > >  tools/Makefile                        |  7 +++++++
> > > >  tools/firmware/hvmloader/acpi/build.c |  5 +++--
> > > >  tools/libxl/libxl.c                   | 62
> > >
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > +++
> > > >  tools/libxl/libxl_create.c            | 16 +++++++++++++---
> > > >  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
> > > >  tools/libxl/libxl_dom.c               |  2 ++
> > > >  tools/libxl/libxl_internal.h          |  3 +++
> > > >  tools/libxl/libxl_types.idl           |  1 +
> > > >  tools/libxl/xl_cmdimpl.c              |  2 ++
> > > >  xen/arch/x86/hvm/hvm.c                |  3 +++
> > > >  xen/include/public/hvm/params.h       |  1 +
> > > >
> > > > I've tried to break it down to smaller patches:
> > > >
> > > >  *(Patch 1/6)*  event channel bind interdomain with para/hvm
> > > > virtual machine
> > > >
> > > >  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for
> HVM
> > > virtual
> > > > machine
> > > >
> > > >  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual
> > > > machine
> > > >
> > > >  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine
> when
> > > > vTPM is added
> > > >
> > > >  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> > > >
> > > >  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> > > >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org
> > > > http://lists.xen.org/xen-devel
> > > >
> >
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--_002_945CA011AD5F084CBEA3E851C0AB28890E820119SHSMSX101ccrcor_
Content-Type: application/pdf; name="vtpm.pdf"
Content-Description: vtpm.pdf
Content-Disposition: attachment; filename="vtpm.pdf"; size=166430;
	creation-date="Wed, 05 Nov 2014 13:15:53 GMT";
	modification-date="Wed, 05 Nov 2014 13:15:53 GMT"
Content-Transfer-Encoding: base64

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu
Zyh6aC1DTikgL1N0cnVjdFRyZWVSb290IDI1IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+
Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDIvS2lkc1sgMyAwIFIgMTYg
MCBSXSA+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291
cmNlczw8L0V4dEdTdGF0ZTw8L0dTNSA1IDAgUj4+L0ZvbnQ8PC9GMSA2IDAgUi9GMiA4IDAgUj4+
L1hPYmplY3Q8PC9JbWFnZTEzIDEzIDAgUi9JbWFnZTE1IDE1IDAgUj4+L1Byb2NTZXRbL1BERi9U
ZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250
ZW50cyA0IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdC
Pj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMD4+DQplbmRvYmoNCjQgMCBvYmoNCjw8L0ZpbHRlci9G
bGF0ZURlY29kZS9MZW5ndGggMzAzMT4+DQpzdHJlYW0NCnic5Vtbbx23EX4XoP/Axz0BRPN+CQwD
jZ2mKSrUjdW0gNMHQZVlp+fYrmwn8L/vN0Pu7ZzdPStfCiQ2YIukOMPh8JsbuRb3Hov79++dP/z+
kVAPHohvHj0U/z09UUJJpZQ2RkURjRLeKXF7fXryj6/Ey9OTe9898eLmzemJFjfdZKWCVm40+9lX
pyd/Oz0R354/FGKwkr73l8uXN6K5fnn29yebuuw3F2D8Ry2ckyo4cfGM2IO30EJnK50Rzifps7jY
0Zq88HenJ0+bXy4en4s/bGxzu9GuuXr+4u1Gm+b66u07HrgWm3+Jiz+fnnx7MSGKGazeLudtkCEM
l3vaLDKxS/sx0M54O17L5ITNtNHK/sfzzZnBIq75hRpvX+92N7eDJYfiaZ9lMGN6MTc38KTBXDos
k624uHrafD1LFq3MYyomWNSCW9KCTlMqCJEU3YqlDS9ydjYjVTAypTHRgVSj+UHmMJz/tHlyfVVR
sX0/u3lrZHRjujcbrZu3m9S8AnUApq43Z655eXVLp/X+9cY3b1/gn1cvxeYM3P+zsb65xsD7TWje
0LE+22giFteXV88xJzSvns2tb6OXMY/Xf/scMD5LhI5I6NgjncaZc0YGO2YkZxZ1DpPieO7iafu5
0947YqelseW0zviMjx0yMJdGZEcOOckwWuZp8wMf0c07OpvtJZ128Qji8uqKju36zRscjWBV0i9e
0QGRhp/Tby8ZH//+lX5zeehBRicFR+HtePGLx2B2PqdmGxOf7ZBiUc1hpZq1k2kVw7iOoUlJOjvr
nb5esB34phH1ojhppTiwfXV3GA3J1sBoMP9pc73Dht8RgEwLoLldOyV1GlNfCgpLMPtIZg83wCZs
G4KlBQQ3Gj5jFljKSRvHDP/6hNApl7Bo8phkUfP5WNAKU1HLWC+DXsNfqw+JikZlaab4jzCBraa9
qfgDJa/8QVC+G8WBwzUTW7AaESqPBLuvrM/IjeyDcJ9+DP9+riGs+MBxt/74LIvSKmuikEdkifun
tQicxfQQDmYSODpi5dx7CKeLvS8kBzaMqFakONocE23SaLSJMpkBUod/2LUe/pn1DLC/vMdxUeTF
5HROm8lLjx97Eo9E3Ze760+YyuEydR/DdTpTWfv3wZk9QOlxGjNNM1h7AtYTekKm5MKeohYPwlXd
Kxk8F04oaZDLi11pgR+cmkN+oAmXTvjIP65OT0JtbtEMnqZRL8SOiptgRXPRzJmnUksxu0oFQYlV
YqalgXl1SXRcR+CYCWY9L1WcEb+i3pKIugpm4/Gvh4H9gPoLqvhZ/Fa28mTqXGYz2VK3oFzag66z
0niYoJHFc/Bh6lKM/nNjFDjN5/ZOovjqaY+BJnSgQXDHPxGcpMYJ3GLNoISBMIjHu9KB8VpHrs0E
eFwf6VdQb21BBxqKrL0t9bKMth3QKbQcuFk4ExF6OnVE1ANhSqLSU7VI9HRysSWKru3wUbNEdQCS
VgbUSq1sFWqTKPv9bXUSirPJ+UQJrbWigGoQca3bwyFX04njGXL3uVQdZWYc0q+KgEcT9pSlJbPO
iarogvGubEXqu7uhPPZ2cZE8wVcj6wMmRnyXr3ZUZzvkouENFAEroTAh43EOaHFeqshui3reUNXi
XKZ7A+OTtFk4IMaatkfOBnqHf6oDWxqIMvt2wBsrs255tb2yDlGXAYICuG77gciLVl7sM8s61W9W
MarrrCJSjwSvxNwsjI+Z0xew+SkDM4up5YSvd1FLXYwkm30j40IUSy+amcuBHU/PYY2ZmcVEc88T
OBSvKDt0JsurlvFT83ijbfPjT5tZuTKkHxMti2QXzcl7OEjNrhQBbtcPwM1GZEuBVgNMkAtYrgfQ
pBhP9STjh52n44te6gU3IG87hTmRlQH2qJWyDBAYqPpnPq0TLmv0DruK0DvtKl4dqJJXXm2vLHXM
sL4oNUya2Ow1cJc5Z80uxpDaPiBwBbgJb4b0qyzq+IVl0pTkU4DJrjOjP208RJk1o2CS9GFMtCxH
n9EVA8KxUDu1GR3U7WuSA4Fy8nTvrbTnlNdJX3NejV/6mvbqBEBk6lDGUqmoybxqWhNofk1qfGaO
lY5ScubmYwFVaRKcysroQJpKhBazWpGx/ba2MonmIxnZQcDQKtDNHRa2BwGDL4d9cz5/jWhl0kPa
Y1hK/ZPdWX2EU1nn5de7bKU2vCRsGS2jEaHISyBo4zyw7L3vd5c319qKR6/E1PudWbw73ItOxisq
lMlc4+AGVx2JmybCF5kR2Qort7OXjh1f5wiuFPe03U9PlzjrKWbJSJvGzJblM/uXANaGQWXDvVKY
WGdQ7rUVi/VqUNs4PaxtnB7WNs50LLjZ1TbU62sb7pXSpNJXt0+8+xhB6/YBospUB6ztWHBzXSX3
O93wlPews3dv3X0AUjdjZ4q4NWZiYc3J3LWKs0eDtIVjzHmmilvi7CeYOcXvI+tLN9sHyeQ1Z5yJ
/+UgqRXFghxLcNFwX6Z2t1231gra4KT3e91Uer7reziHEoOW4Iv9/CySOP9/CDEJqdinDyxYsuTu
gyqqcakUTVTUZQp+dFVE4M+qa8bISZ5D4hKFs4oefLWNbIL0PAkim+gRiU0I45oHkPVxoYFfI8kM
KBWTZp40LYZ+rU59QQcSLZKYLrN8dP9leAE2fm35Et7S2xkivnccj6hZCj/DVsr64GaZYI1pyWyy
Lb/e75QryfFedh+2l1af22V9ogYiRhpQt5aS00PZBjvffvqdT0IlLUIlaN9CJZD3CO2G8AuZ+p7C
kr7ABfmVL9GT4ILcC3ZthnDxiPUpFhUj14LGkIywiukqLLRsryrbsAYyLvt6jnyItkRc1oDu9ELN
ojhLJ1MUx80ywTndknnlWn49ZE7GW9l9+FZatW6PqzXGFjUekUxNiTfY/PbTb34SNXnJ9RqEha5A
3FE/0fsZfWYUOWCaYOkhfTDgAy/uWLHGKnY+cHoUtZSmHI90zGHUGGSi6GaOiaAoZpUp1DsKHZUt
TfV8I96v00Mokdd2BUIhloiRAzm7iiENGR13ivPV3lLxVjtdJqCdl8Ob3dqvk5Et22K/CsNpH0+j
re0+bmsjpW/XKj1mVjqCuAFsCpT3hB2oZft51TKFNKeWkEbuO/kB1GxCTKVNGionCOGphK5+IJQb
YgebQAB22Bmqc+XhV7kEocir2GTpoZ4uFDGQI3IW/oyHyi+4bhsQ2HXLliaHsrVunUWo0XFS0DD8
GqYTZQnUqWqkE4kTOo2Dq5ltP1CmG1V2yt93BL6kMHmEttEGdx+7wbHut+t0H+miFLpHsEGcUoz+
A4EH2tl+du1Mgk4vPwr4AFxqUseu7TnSFn0MCptz8PwYC7xi6XDKkIH60uWkQZO91bl0MeE7Nm2P
lyDSMkAWrGrGUQcUmU9l1V7H8zr9bXyVo7+Nr1J2t/eh48NNW+HfwuaL2e0kEmav2LurFAUsncFS
xGjEFXOxcHVZH1zxXL5+Ta9c241tXuDv1Uar5pI+/yrfhy5+QGvvLITJZuXNg+s/P0C2wcCnVCvV
JCslcg1OWSoDdoMBT5tEusuVMnIUR9dHiZv8HqQpkFOPH4McnwR6nhxwaum7HrNnOh7ogdAN8AFW
Ru2rUllkgIQiwwAJRb4WCUX2DlS1t4f+mYexL0sRk4Yxe1N+DJNIJxANLPw0gvinNIxwZyHIMNIq
u4jLz1qoBiM5P0PX/LvBgCfD8yVSOhUJTfSCQP9PofS4NKDvKNuBmvZTuVkGguKErfLqerwUU/MA
fdJpyh12HaCnGFFZ1UuwulJ/Y1Zl6S/Nqqh1oG6jsGo7ZaGjT1xfqkomjWX2e4gjOAXYSHCKIvHw
M6KPMZZ8ZyHIWNZ9NOyXv6kImvO+HhrdQDlOZKV0R1KPGr6NLmJ6aFhLSesAGtZTgGrn2yhz6ni1
vQ4aZWAAjTpQoFFYtdAoK/XQqLL00KiitvPLNiqr2llnLV+sSqasxc9+f3EEqPTmC8E/vbV4c2ch
7mAt9vB9zumg6/tcslDnxPuc4mtzFPnYLs5F8Vco8GuDpzk/fJr7H1UxznUNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQo1IDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwvY2EgMT4+DQplbmRv
YmoNCjYgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjEvQmFzZUZv
bnQvQUJDREVFK0NhbGlicmkvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9y
IDcgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjYvV2lkdGhzIDE0OCAwIFI+Pg0KZW5kb2Jq
DQo3IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDYWxpYnJp
L0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAvQ2FwSGVpZ2h0
IDc1MC9BdmdXaWR0aCA1MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1
MC9TdGVtViA1Mi9Gb250QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZpbGUyIDE0NiAw
IFI+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9u
dC9BQkNERUUrQ2FsaWJyaS9FbmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyA5IDAg
Ui9Ub1VuaWNvZGUgMTQ1IDAgUj4+DQplbmRvYmoNCjkgMCBvYmoNClsgMTAgMCBSXSANCmVuZG9i
ag0KMTAgMCBvYmoNCjw8L0Jhc2VGb250L0FCQ0RFRStDYWxpYnJpL1N1YnR5cGUvQ0lERm9udFR5
cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8g
MTEgMCBSL0ZvbnREZXNjcmlwdG9yIDEyIDAgUi9XIDE0NyAwIFI+Pg0KZW5kb2JqDQoxMSAwIG9i
ag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+
DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RF
RStDYWxpYnJpL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAv
Q2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9Y
SGVpZ2h0IDI1MC9TdGVtViA1Mi9Gb250QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZp
bGUyIDE0NiAwIFI+Pg0KZW5kb2JqDQoxMyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv
SW1hZ2UvV2lkdGggMjU5L0hlaWdodCAyNDIvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNv
bXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDE0IDAgUi9GaWx0ZXIvRmxhdGVEZWNv
ZGUvTGVuZ3RoIDU0NTg+Pg0Kc3RyZWFtDQp4nO3d6VuS6d/H8Tnu30xNu5rmvuYCsm+yKyAgoKio
iIiCoAju+5JabplppmlqtthUNmWW1vUf3ieXM1PTLDUzGqWf13E+6GieXHCcb87ry9J89x0AAMCX
dupCDMvQJK4YJEtoGxSQVY6F9cvilw3wS3v51m5+SSe/uJ2pcZ+LSQn3nj0w8TlySdUVcdWoyH5N
XD0hqZn6YE1j/WFNHdtFtgfZJKKqMWHFiMA2zC8f5Fl7OZZOVlEL29AUlcgI917+N+IZcol9jN75
03m1M1LXrKxuTua+JffcVjQsYmH9ccndC7L6eWndzbzaG3nO6yQN0oWgYoScFNySHra5nWkIMHS+
iITMcO/uzyKuGBbbx8n+D21+90LoMXrvKH0rqqZVtX9d3Xzvd4v8zde+1o77avpCi+wQVeNdpW+Z
bJhQF57bsvo58ioqdkwKq66SM4Jn7WObO5iG5myNh5HvDPdO/3PnY1LIbZ7EMUmuXFY3L/cskkek
8q/lBzbyA/fzgw8KgvfpP2/kN9/Lb14PLfJfsbB+v9TkBbPprqpxReVbVvru0DnMkxdViXOavMAK
bFe41l62qY2hb8rKr78ss0fEXQ733n+PZ+0mCZCrJacbyZl0TV7tyf4vaHlYQCdQENgoaL5XGFy3
9T609T5ovLZJVs/s0765p1eXtmZWX2Ad83Vt+TnZDGRL7O+Nit775d0bhuCqOlQEOSBuy0N3TbP7
90v88iFOSXeusYWh9WWqa1PFpeEu4DuWwSe2X8tzzpBsQwn4Q0dAQcuD9/s/cM/Ueq/x6uPx5ef3
ftp59PwNWVsvd8nafr2382Zvd+8tBcfe3t5bshlevd7b3xv7+2Tjp9czd1/4rz0u6Vinc1iQ198k
44O4elJYOcovHWCbOxl6f5a6Ll1WGZctCUsCZ6ISxVVjEseU1HWTnF/Kxrv5zRsFwf0jILT/izvv
d848XX28E+7nGI6CJy92B+efWttXFO55mevGL6O0bZhT3E2GaHKblCGvShUVf3/i1JesgGsK/noQ
3FJ4l8lQmR94fwSQBBYfbIf7mYOj6dGz1/bedYVnQU7ulKon96cGcptEJugMeXWq2BqbKfoyFXD2
K6i9QSZiVeMqfRA82E9AF1wfmHu29/ZduJ8tOOLmN16aWu+SOyVJzaSwYoRr7WORCVrrzVQ4UkQl
KRztYVcgtg2Jq8d/qYBMBL8mUNC83jC2Sc6vcD9DcFy83n03cPNpvu82mRqEVWO80n62uZ20kCG3
JwssieyCw6tAZBsOVeCalTcs/TIX0wmUdt1ffvQq3E8MHEfktbf+ygN5/Rw5GgTlQyxTa7amIV1W
lcw3xTPVh1GBMFTBBKlA4aUroD8OKGheq7uySdoM9/MBx1rv7DNVAzkapvnlQ7nGYHaBO11akcwz
xjOUB1xB+UBoLvi1AjX9cViBf6116idMBPA1mF75We1dIrdJ/LLB/feR0vLKkzj62CzpgVVQ2ieq
GpM4r+/PBWr6E0ByFgwvbIX70QO8R+7PNU3L0lrSwgBT35ypriWDc3xu/qUM4X+vgFsUFFVcETum
ZPW3lL4VtX+VVKALrs2uvQz34wb42ObWG3PrmtR5nczODJ0vNDjzjHHZ8pg09n+pIENcLLQNiezj
0rqbv3x3oumuLrCG0Ri+Wlvbu+a2tbyaKW5Jd7bGnSYpS2BpYy6Lz0cn/rsK/vfDSUFZv6hybP/N
0tBx0LhSGFxd2MCHZfBV23jyWh9YllSPs81t5AYpWWiJYyijU7lkS/+LEPglXaF3imqmZO4FZeg4
WDa0rJGRJNyPEuDTlh6+MrXcEVWOMg3NGbJKMjXHZEoiE3P+aQVZykpBaZ+w6qrUdTP0TpFvucB/
l0zHb/EeEXwjyBirbVzglw/maL2pYms8Ux2VwjkTEfNPjwNB+dCvM/IdddPKwPwWvikK3xDyoj27
+lLhmuEUd15WOpK4hugM4YW4f/ADN3ZRM9/aK/xlOritalxxjzx8vYsK4Buzt/d2YO4nUdUos7Ap
VVIax1BFJjHPRsV/TgXnY9L4xZ3kQBE7JqV1c0rvUr7/7ubWm3A/JoB/Y+/tO33TLV5pb6bKmcQz
Xkzjn4tJ+7//ff/JELhFAZ61R1g5mueckbtvkemg8epmuB8NwL83vrQlcYznGpvTJGVxOYqIhOzT
EbGfDIFnbuWV9oU+O3DNKhpu4ziAbx05FIyBJX5Zf1a+K4lniEphn436xGcKbL2Xa2nfvy+S1c+r
vEtN1x6H+3EA/FcTd57nOSfJoZAqtsZkSs7FpJ4+F/k3IXCMfm5xp8B2RVIzpfAsaPx3t7bxEwP4
5oUOheZFrrU7Q2GPz1VfiM/+8dzFv6oghavlFAW4JfSAUDuj9C52XH8S7kcAcDDIpCCqHMnReMjI
HJXKOR0Z98PJP/+BM7uwgWNq4ZX2i6quyupm1Y3L+Ok9HBmvd9/JXDPsomCapPRSVt7ZmNQTp879
xYDg45jbQgNC9YTcPa8NrOK3BnCUVPfdE5T1ZyodCbkFFxKyT56N+mMF5y8mcQxNHDOZlIckjkml
ZwFjMhwxwwtbeY5xZqEvmV8UlcI5HRF74uTHX8NjF7rJpMyxdIRCqJlSNizOrr0I94UDHKSNJ68V
7ptsU0uKqDg6XXg2KunkqTMfv19U2MA2+LmWTr5tOM85rWteebGzF+4LBzhgxW3L3JKu9LzyGDIm
RKecOH3+4xD0Xpa+iWMJvXcqc91oGMWnyXAEDc4/E5QPXFZUxzGU5y6lffQm6vlLqWwSApkRiruE
FSPy+rnxpefhvmSAg7f+ZEdsH8vKdyWwNOfjs06dj/n+hx9+CyFHUcku9LAMfhKC2H5N2XAbP8aE
I+n5q11Z7XUyLydx9ZFJuacuXDpzLuL9pKxzs/UN+yeCuHpc5V3Cv1kHR5XCPccqCiTz9t84iv/w
uxacwvchSEgIvjv4N7vgqDK3LLFNLcl8U1Qq70zk70Lg6j3kUAgNy8XdkuoJdeNyuC8W4LDYe1bZ
5rYUgTk6jX8mKuH0+ejfQuAZPGxtXW5hYygEx0RJx71wXyzAYfGOPuBYOlKElug0QSiED37FzDd6
WdpaMkFwi3vyaqYcA/fDfbEAh6V9+jG3pCtFVBKdLjwTlXjmgx/p8A0NuZpaps7LLemROqfxkzQ4
wobmn/JLe1MlpTEZorMkhMi4j0Jg/BLC9ZZJfMsIjqzhUAh9aQgBjjeEAEAhBAAaQgCgEAIADSEA
UAgBgIYQACiEAEBDCAAUQgCgIQQACiEA0BACAPVhCOkIAY4vhABAIQQAGkIAoBACAA0hAFAIAYCG
EAAohABAQwgAFEIAoCEEAAohANAQAgCFEABoCAGAQggANIQAQCEEABpCAKAQAgANIQBQCAGAhhAA
qN+FIEQIcGwhBAAKIQDQEAIAhRAAaAgBgEIIADSEAEAhBAAaQgCgEAIADSEAUAgBgIYQACiEAEBD
CAAUQgCgIQQACiEA0BACAPVZITQgBDjyEAIAhRAAaJ8OQYsQ4OhDCAAUQgCgIQQACiEA0BACAIUQ
AGgIAYBCCAA0hABAIQQAGkIAoBACAA0hAFAIAYCGEAAohABAQwgAFEIAoCEEAAohANAQAgCFEABo
CAGAQggANIQAQCEEABpCAKAQAgANIQBQCAGAhhAAKIQAQEMIABRCAKAhBAAKIQDQEAIAhRAAaAgB
gEIIADSEAEAhBAAaQgCgEAIADSEAUAgBgIYQACiEAEBDCAAUQgCgIQQACiEA0BACAIUQAGgIAYBC
CAA0hABAfRBCNEKAYwwhAFAIAYCGEAAohABAQwgAFEIAoCEEAAohANAQAgCFEABoCAGAQggANIQA
QCEEABpCAKAQAgANIQBQCAGAhhAAKIQAQEMIABRCAKAhBAAKIQDQEAIAhRAAaAgBgEIIADSEAEB9
OgQnQoDjACEAUAgBgIYQACiEAED77BCmm8cRAhxZQ6EQelNDIQg+CkFg9LK1tQyth1PclVcz5Rp+
FO6LBTgs3TM/cUu6UkSWqFTemaiks1Hx708EYwNH52Jo6tnmdoljsqzrXrgvFuCwNF19yLF0JPON
UcnssxeTz15M/OBEaODq6xmaOpapVVJ9zRBYCffFAhyWmv51tqklkVMYmcg8G518PjrpgxnBIzC4
mdq6XGNQZB9T++7svX0X7usFOBSm4FKuwZ/A0kQkMM7FpFy4lPJbCDx9PQmBpa1n6puFlVdU3sWt
7d1wXy/AodB45xiF3niGOiKRce5SWmRc2m8hsDVOgdHN1tUzCxsF5YMKz/zdzZ1wXy/Awdvdeyd1
TmUX1MVlKyISmedjMyIupf4Wwunz0WKTNzQmaD08a4/MdePG2stwXzLAwXv0/I2o8kqGvDImQxSR
kH0h7vIPJ0999wGJpVFk8pJ5mW1uz6uZ7Lz+JNyXDHDwJpaf86xdKULTxTTuhfisiPjM735PYvZJ
S/y5ZF42NIvtY0Wtq+8wLsORY+++yzI2J7AKIpNZF+KzIxOyPgpBaPTISwNcvZuh8wlsg6qGhRWM
CXC0/LyzJ6+7nl3gupQli0hiRiTkXEzK+SiE+CyhzBoQm5sYGjevpFvmmumceRruCwc4SLNrL0WV
wxkyW0y6MDKJGZnI+PFsxHd/ILM2K8taWNo6ljEosV8t6VgP94UDHCTv6AOOuS2ZZ4xK5UYm50Yl
M/9YAZFnaVRXtAuLfAytR1A2oHDPP3mBTxPgiNh7+05dN5Wd74rLUUSlcMiMEJ3C+tMQYtM46oo2
RVkLU+Nim9qkNZOji8/DffkAB+P2/Zd8a3eqyBKTISQhXExlR8Zl/GkIhLIsqHV08w0NTJ1XaBsu
Ci7juxZwNFhbFxjahniGKjqNfzGVG5PG/asKCFFRg87RLSeHgraeW9wpc12fuINDAb55iw+2hbah
9LzyS1l50emC6DRebAb/b0Ig8ivbC519XIMnt9AnqhgqCuALePDNK2tfYhlCHx/EZIhJCJcyBN9/
f+LvQ1CUBg21/UpbG0vn5phbpTUTOBTgm7Z4f1tQ1k8fB9KYyyIyI8Rliv6+AuJ0RKy2utvkHs4r
bmZo3YLSXkPTwutdHArwrbL4b+Ro3PEM5aVMyaXL4thM8cnT5z4ZwnehDxSCxrrBwtp+vsHLNvgl
VaOtE5u4P4Jv0dTSE465PYVvupQli83Ki82SJORIP6eCfTpHr7XxqrqiI1dXzy/uVNZdv31/O9yP
CeCf2dx6k187lqmwx2bLY7OksdnShBzZ51dAcLS1JveVEu8ouUHK1XmE5X0639ytDbQA34z7T3dM
/hu5hY0JuQUkhLgceQJDHpvB+0chhA4FZ3+5f8LoGhSafGy9T1wxaA4urWy+CvfjA/i0Zy/3KjoW
2MYguSmKzdmvQJGcq/qnFRBnImPNnlF764zBNSAo8nKMTZKqK6aW5UfP8b0L+Kptv3lb3rHMNben
ia1xOYo4hiKBqUxiqb4/cerT+/7PMFQVJU0T1e039M4+nt7DNQWk1WPWjnW8iQRfM+fAPX5Jd4a0
Ip6himMoE3JVyez8FLb631WwT+0YKg/O1HTM6hzdLG0t39IqdVyr6l3Hr/vhK7T39p139IGwfCBL
6UjIzY9nqhNZ+Smcgsti83+pYJ/efc3eMedony2o6swtqOGZg3n20eLWFTKSh/txA7xHblQqu1cE
ZX3ZamciWxOfm5/ELkjlajPziv97Bfss/pnantvkHqmwppetdXGL/JLKocLGheVHmJ3hq0BuUSyB
W7zizkyFPZGtTcgtSOJo0/j6LKn1oCrYV9Y65+q7U9e3aKof4hvcHINXbOtXum/O4t+7gHAjNye6
hhmOqfWy1EbOggSWJpmryxCZcuRlB1vBPmvLvKt/xTeyZvVdlZi9bF29qKxHXjvZd2Mz3M8EHF+3
1p+rnONsY3O6xErOgkRyEAiMWdISpqrqxKkzhxECYQnMuwbWAuOPbIEpudVPjwwBcptUHJzHbRJ8
YU9e7FZ13hJYe5ia+jShOYmjS+bpL0ssDEUFuYE/pAR+U+Sfcw1ttE0/dXbdMjh7ebpacjQIrR1S
x1XXwCp+3QlfAJmLW6+ui2xDLH1TptSWzDUkcQvTRaZsWRmLvDgbvIddwT6VY9g1/CA49ax5/KEt
MKkuD5JjiGv0ict7ZTXX2q7hgwY4RCM372vqJrjmtmx1TZqgKJlnSBOasmRluepqrt6dytV+mQr2
/Xg2qqr3nm/8adfcdsPwqsU9LC7y5KrtXIOXnA6qmpGGgcWFez+H+zmDo2Pj8cu2sTs61wjX3MLU
1GVIrCl8Y6rQlKOwcbQuvtErsgROfN73qw+cyjHiGnncMrPdNfeqtmfBVDcgNTcwFDa2tpZvbiYH
hKr2qqPr1sCNR/d+2nny85ut7b0XO3s7b96SFe7nFb5Gr3dDe+PlzluyVZ6+3N14sjO5+KS+706B
a0Jg7WbrG7OV9nSRhRwB6WILQ23nGzwis19ibeMZv9Dt0N8o61rzTTzvmN/tnn/dMLxW1jSutrWw
1JVMVSVbV8crahSWtEkr+q1Nk87uBe/wSufERs/0w+nlZzdWf17YeEmmbKxjvm5vvCSbYWZlq//G
o67J+80jq87uW7bAtNI+JChp5xibyBGQKS3b3/9MdTVP7xZb/HnWFll5l6KyL9wFvJfK09kHHjWM
/9wy+7p38V3z+GN7+5ze2ScvaeIU2LNlVobSxtI4yY0T3+QXWIKC4jahtVNU1i2rHCQTB9YxX7LK
AVFZD9kSZNvzLS08U4Bj8DE1tdmKioy8knSROUNsyVbYyOu/rKxVWdGlqOhRVvWrHEMnz1wI997/
c9aujfqrz5tndroW3nbO7fjGHjm6F62N4zpHj7S4kaupZirLs2WlmXklWVIr+QO5wWNgHftFtkG2
vDSL3hiZeVaysui9wdbUCIs8edaAoqJD4xzU1l7ROK8U1I7l1147eSYi3Jv907h6j3PkWcPktn/m
ddvcbufC29bZV97Rh47u2xWts9amCZNnVF87UGDvUpa3YGGRpbK15le2F1R1aqq7NY5enXPA5L1W
7L9u8V83+aaM3imDd6rQe/0Lvyl0UEjg5b2Paka2PBMvG6e3m2dekRW4vt08/cI/9bxx/KlnbNMz
Go418iWW+7PWo699XTm89fC3VT/8oG7ovnNg3d57t6p7xdZ5p7Rt0RJcMAcWDP5bZC4O914+MJfz
SnTeG6XdD8p7Nyv6f6oafOIYflIz/LhmCOurWI5DX5t/taoHN6v6H1T03i/t2rB0rJtaVw3B5cg/
/F88AOBQ/T8KMcmTDQplbmRzdHJlYW0NCmVuZG9iag0KMTQgMCBvYmoNCjw8L1R5cGUvWE9iamVj
dC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDI1OS9IZWlnaHQgMjQyL0NvbG9yU3BhY2UvRGV2aWNlR3Jh
eS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmls
dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4MDY+Pg0Kc3RyZWFtDQp4nO3ZX1LTYBRA8W8ndCd0JYIs
hOJCRF1JWIGvPtY3ZpxhYKw6itRjQ/lToKVpaXOH3HNWcL8fN0kTSrEm7bx5X/Hqqga7mzn+IZz/
iT7N2n2DwcvOP+RL9CFe3insrP3378D5p52utQvwetd/fisCDLmInnjTXZ6tgnBYXz/da9T8cuB7
9LDb6lezRTgeRw+61arlAsPoGbfe0osgQQo8bxA9W1spsNggeq42U2C+wfA8eqp2myPwOXqmdhsd
PyHo7I/iRf3OfSOY9lBg9yx6nvYbD9IvwcM1GHbtC1GjxrNvjZ37RNSsq5kliJ4lrOR3grpbgSp6
kLgG6Zfgbg1G0XME5hLcGEQPEds1QcLfxvdd1gL70VPENkh/HVxfCdEjRDch+BE9Q3BuAb3Sjx4h
ur1yFD1CdIPM70jTqvS3gsn9MHqA+CSQQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIk
QAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIk
QAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIk
QAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIk
QAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQIJJpYqeILqqHEWPEN2g7EePEF2/9MbRMwTX
K+Vv9AzBlZL+kSBBTZD8kbA3ISgX0VOEVgskvxIkmBKkNuhJMBXI/Ez4cEOQeA2KBHcEJeur0r1A
4V/0MDGVWYOUzQqUtxlfmfsPCFKuQXnUz+iBWu+xQPl4GT1Sy508IUh3KTwVyGYwTyCXwXyBTAaL
BPIY9BYTJDF4BiCJwfMCGQyWCZSu/7f93XKBehGuoufcXo0ASv0xsaMI/aYC9SJ08q1pBYC6r9Hz
brwVAeo69W292V1wTtGDb6p1z9+RXTh42flv6x+dRJ9k9U4+HfSaHO4/bBiqbQ0KZW5kc3RyZWFt
DQplbmRvYmoNCjE1IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAy
NTgvSGVpZ2h0IDE5Ni9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvRmls
dGVyL0RDVERlY29kZS9JbnRlcnBvbGF0ZSB0cnVlL0xlbmd0aCA2NjUyPj4NCnN0cmVhbQ0K/9j/
4AAQSkZJRgABAQEAAAAAAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwg
JC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCADEAQIDASIAAhEB
AxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9
AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6
Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEB
AQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJB
UQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RV
VldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6
wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoqpeX1pp9ubi8uYreJf45n
Cj8zXF6t8WdBsdyWKT6jLj/lmuxPxZufyBrSnSqVH7iuZ1K0Kfxux39FeG6h8WvEF4/l2ENtZhvu
7V82T824P/fNZ5svH3iL76avOjf89GMUf4Biq/lXWsvmlepJROV4+Ddqacj3K61jTLAf6ZqNpB/1
1mVf5mse4+IPhW1+/rMD/wDXJWk/9BBry+2+Eviab/WLY2//AF0myf8Ax1TWrD8Gb1v9frNtF/1z
gL/zIqvq+Fj8VS/p/TJ+sYqXw07ep1snxT8Kr927nf8A3bd/6gVF/wALa8M+t5/34/8Ar1hR/BZB
/rNedv8AdtQP5sakPwXtu2uT/wDgOP8AGnyYFfaf9fIXPjf5V/XzNyP4q+Fn63Nyn+9bv/QGtC2+
IPhS6+5rMCf9dlaP/wBCAri3+C0gH7vX1b/es8fqHrLufhBr0X/Hvc2M4/3mQ/kVx+tHscFLabX9
egvbYyO8F/XzPZLXUrK/j32d3BcL6wyBv5GrlfNl/wCDvEmjyebNpNyu3/lpD+8A99yE4/HFS6V4
98SaSf3OqSzxf887r96PplvmH4EU3l3Mr0ppgsw5XarBo+jqK8y0L4u2F0yw6zbtZv8A8948vF+I
6r+v1r0W1ube8t1uLWaOeGQZWSNgQfoRXDVo1KTtNWO2nWhVV4O5YooorI1CiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAoorB8Uvra6M66AitfSSKis2MIp6tzxx75+lOK5mkKT5Vcsa14i0rw/B
52pXaQBvuL1Z/oo5Nebal8T9Z1q4+xeF9OlXd/y18vzZfrtGVX8c1q6X8LEkn+3eJtQl1G6blo1c
hfoWPzN+ld7YadZ6Zb+RY2kNtF/dijCj6nHU+9dalh6Wy53+ByONeru+VfieRW3w18UeILj7Xr19
9n3f89pPOl/BQdoHtn8K67S/hT4csdr3ST30v/TaTC/gq449jmu8oqZ4ytLS9l5aFQwdKOtrvz1K
NjpVhpseyxsba2X0hjCfyFXqKK5m29WdKSSsgooopDCiiigAooooAKwNa8I6Jr6t9vsY2l/57R/J
IP8AgQ5P0ORW/RVRlKLvF2JlFSVpK54V4o+GOoaMjXemO1/Zryy7f3qD1IH3h7j8q53w74p1Pwzd
+bYTfumbMlu3KSfUdj7jn+VfS9eT/EjwJGYJde0qLa65e7hVeGXu6jsR1I79euc+phsYqn7qvrc8
vEYN0/3lHSx3XhrxNY+KNOF3ZuVdflmhb70Teh9R6Hv+YG9XzJ4d1+68OaxFqFr/AA/LNH2lTup/
oexAr6PsL6DUrGC9tn3wTxh429iM1y4zC+wldbM6sJifbR13RcooorjOwKKKKACiiigAooooAKKK
KACiiigAorgPHnjr+xMaTpP73V58L8q7/J3dOO7HsPfJ7A9R4dtrq18Oafb32TdpCvnbm3HfjJye
5z3rWVGUaam+u3+ZlGtGU3BdDyZ/i94hWR0FtpvysR/qX/8Ai69W8ManPrPhux1G5WNZp497LGpC
9SOAST29a4B/gsXd3/4SAfM27/jy/wDtleieH9J/sLQrPTDN5/2aPZ5m3bu5JzjJx19a6sXLDOCV
Hc5cLHEKb9rsatFFFcB3hRRRQAhIHWsf/hK/D3/Qd03/AMCk/wAa1Ln/AI9Jf9w/yr5RX/VpXbg8
LGvzXdrHFi8VKhy2V7n1ZDPFcwJNA6yRSKGWRGyGB6EEdRU9Yfg//kTdE/68Yf8A0AVuVySXLJrs
dcHeKYUUUVJQUUUUAeHeL/GniPT/ABbqNna6pJFBFLtjjVV4G0HuM967j4Y6zqGt+H7q51K7a5mW
6KKzKBhdinHAHcmvKfHv/I9av/12/wDZRXpPwc/5Fe8/6/m/9ASvYxNOCwqaWuh5GHqTeKcW9NTR
1XVNTXXUiguGjt/N8uTaq4gGUG5mJ6kOWGQR90YHLV1FjOb3TbaaZV3zQq7L25AJ4Pai406zun82
e0hlfbt3MgPA5APqM9qu15cpRcUktj04xabbZ82eMtEGgeKryyjTbb7vNh/3G5A/A5X8K9I+D+rN
c6NeaZI2fskgeP8A3Hycf99Kx/Gsb4z26rqul3A+/LbyI30RgR/6GaqfB+Zk8VXUP8EtmT+KuuP5
n869eq/bYLmlv/keRTXssZyrY9vooorxD2wooooAKKKKACiiigAooooAK5jxr4oi8L6G1wu1rybK
WsZ7v/eI/ur1P4DvXT18++L9Tn8YeOfs1q26FJhZ2vp97Bb8Wyc+gHpXVhKCq1Pe2WrOXF1nSh7u
70R03ww8OvqF1L4p1PdK5kb7O0nO9/4pD9DkD3z6CvXDVLTbCDS9OtrG3XbFBGEX8B1PuetXTWde
s6s3Lp09DShSVKCj/Vz5pk8W+I1dsa5qH3j/AMvDev1r3TwVczXng3TLm5meWaSLc0jtktyepNfO
cv8Ar5f94/zr6I8Af8iJpP8A1x/9mNelmUIxpxsup5uXTlKpK76fqeY+PvEWt6f431G2tNWu4LdP
L2xxzEBcxoTgA+pJ/Gub/wCEv8R/9B3UP/Ahv8a0viX/AMlA1T/tj/6KSuu+EumWN/pOoveWNtO6
XACtNCrFfkHAyK35qdHDRqON9F+RjapVxEqalbV9zgB4w8R9tc1D/wACD/jXXeD/AIm6jDqUNjrc
32m1mYIJmUB4ieASQPmXPXPPOc8YrvvEvhfQ5vDmoEaXaRPHbu8ckcKqyFVJBBAz1FfO55jpUnRx
cGuWw6qrYWa9659XXP8Ax6S/7h/lXyin+rWvqGykabQbeV/vvaqzfUoDXy8n+rWsMrVuf5fqbZm7
8nz/AENeLxRrttapDBrN7FFGuyONZmAAAwABnpX0Tcahb6Zo3269l8uCKIPJI30H5knjHcmsXwto
Wkz+EtHmm0uylleziZma3QlmKDJJI5Ncj8YdWZP7O0aJ9qFTcSKvfBIQfThvyFZVHHFVlTirWbua
01LDUnUk73tYwfEXxP1rVZmTTpm06z/hWPHmsPVn7H2XH1Ncr/bmreZv/ta+3/3vtT5/nXTfDfwx
beItbme+TfaWah2j7O7EhQfbhj+Ar2t9E0uS0+yPp1obfbjy/JXb+AxxXRVxFHDS9nGJz0qFbEr2
kpWPHfDHxP1PTLpYdXma+sG4Z25li9wf4h7Hn0Ne2wTw3NvFNC6yRSKHjZejAjII/CvnPxloaeHf
E91Yw7vI4kh3ddjDIGfY5H4V6j8JdUe98MS2Mj7nsZiin/Yb5gPz3D6AVljaEHTVensbYKvNVHRq
O9jzLx7/AMj1q/8A12/9lFek/Bz/AJFe8/6/m/8AQErzbx7/AMj1q/8A12/9lFek/Bz/AJFe8/6/
m/8AQErbFf7ovkYYX/e38z0aiioLieG1t5biZ1jiiUvIzdFAGST+FeIe2ePfGS7WTXNOtB/ywgLt
/wADbGP/ABz9ah+Dtuz+J7y4/gjsyv4s64/RTXIeI9YbX9fvNTbcqTyfu1bsg+VR+QH45r1b4RaQ
bPw/PqMi/PfS/L/uJkA/99Fv0r3Ky9jg+R77HiUX7bF8y2PR6KKK8M9sKKKKACiiigAooooAKKKK
AMPxZqf9j+FdSvlfY8cJEbf7bfKv6kV498K7AXnjaKRvu2kMk348KP8A0L9K9E+K0pj8DSoOslxE
v/j27+lch8Gwv9v6ln7/ANlH/oYz/SvTw65cHOS6/wDAPMxD5sXCPb+v0PaKDRRXmHpnyjL/AK+X
/eP86+iPAH/IiaT/ANcf/ZjXzxOCs8qN/DIV/U19D+AP+RE0n/rj/wCzGvazP+FH1/Q8XLf4svT9
Tx/4l/8AJQNU/wC2P/opK7n4M/8AIG1T/r6H/oArhviX/wAlA1T/ALY/+ikrufgz/wAgbVP+vof+
gCniP9yj6R/QMP8A75L1Z3Wv/wDIu6r/ANec3/oBr5f/AOWdfUGv/wDIu6r/ANec3/oBr5f/AOWd
TlfwyKzP4on0/pv/ACLNr/15r/6AK+YE/wBWtfUGlpv8OWSf3rRB/wCOCvmDaV+RvldflZaMt3n/
AF3DMtofP9D6W8H/APIm6J/14w/+gCvJ/i5u/wCE1TP/AD5x7f8Avp/65rt/CPjTw/F4V0+3uNUt
7e4toEhkjmbYQVGO/XOM5HrWD8YdLaT+ztZiUPEFNvI393PKH6ct+YrDDXp4p8yte5tiWp4X3Xe1
jzrStO1jUPN/sq2u5/Kx5n2fPGc4zj6H9a0v+Ea8Yf8AQO1X/wAe/wAaseAvFKeF9bd7jd9juUEU
2OSmDlWx3xk8ehr2qPxb4ekhEq65p+zH8VyoI+oJyPxrrxOIq0p2ULo5cNh6VWF3OzPCZPCXimV9
8mjag7f3mjJP616L8J9H1PSH1f8AtGxntfN8ny/OXG7G/OPzH51ev/ipoVnq0FpCXurfdi4uo/ux
ehAxl+euO3TPSu4t7iG6t47i3lWSGRQyurZDA9CDXHicTWdPlnCyZ1YbDUVU5oSu0fO/j3/ketX/
AOu3/sor0n4Of8ivef8AX83/AKAleceP42j8eatu/wCewb80UivR/g5/yK95/wBfzf8AoCV1Yr/d
F8jnw3+9v5no1eM/Ejxymob9D0uXdaq3+kzL0lI/gB/ug9T3I9OrPiL421OTUrzQbUm2tYG2SMjf
PNwCQT2XnGB17nnFcFp2m3er3sVlY27T3En3VX+ZPYD1NZ4PBqNqtT1X+ZeLxblelT9GWvD2hXHi
LXINOtv4uZJP7iD7zH+nuQK+krKzg0+xgs7ZNkECLHGvoAMCsDwd4StvCmmCJdst5Lhrib+8eyj2
H/166muTG4n207R2R14PDexhd7sKKKK4zsCiiigAooooAKKKKACiiigDifipD5vgO6f/AJ5SxP8A
+Phf/Zq88+FF6tp41WF/+Xy3eJfqMMP0Q17H4j0z+1/Dmo6ePvTwMqf72Mr+oFfNtleXGmX8F3B8
lxbSB13eqnOD+WCK9bApVcPOl/X9aHk41+zrwqH1RRWZomr22u6Rb6jat+6mXO3uh7qfcHitOvKa
admeqmmro8a8afDfUTqs+o6ND9pt52MkkCsA6OeWwDwVJ545GcYr0PwTaz2fg7Tba6ieKeOIq0br
gr8x6iuiorepiZ1KahLoYU8NCnNzj1PEfHfhTXtT8aajd2WlzT28vl7ZFxg4jUHv6gj8K674W6Nq
OjaTfxajaS2zyThlWTHzDaBnivQKKqeLnOkqTWit+BMMJGFV1U9Xf8TN1qGS40LUYYl3SyW0iIo7
kqQBXgH/AAgnijZ/yA7n9P8AGvpGijD4qVBNRW4YjCxrtOT2KOlRPDpFnDIm10t0Vl9CFAIrzHxn
8Mby61GfUtDEcizsXktWYKQ56lCeME84JGO3oPXKKzo150pc0TSrQhVjyyPnB/APir5v+JNc/wDf
S/8AxVe+3OnW2paMdPvYvNt5YgkiN9B+RB5z2IrSorTEYuda19LEUMLCje2tzwzX/hVrOnTu+lD+
0LX+H5gJVHoynAP1HX0Fcu3hbxAr7Doepbv+vV/54xX03RW8MyqxVpJM555bTbunY8A0b4ZeIdUn
X7Rb/wBn2/8AFJcdfwQHJP1x9a9o0DQ7Xw7o8WnWnmNHHk7nbJYnkn0GT2HFa9Fc9fFVK2ktjooY
WnR1jucB478Af8JK6ahYSpFqCqEYS5CSgdMkDgj1xz0q18N9C1Hw9od1aalCIpWui67ZAwK7FGcg
+oNdrWdPq1hbahb6dJdxreXGfKgBy7YBJOB0GAeTxU+3qSp+y3Q/YU41Pa7M8z1X4b6r4h8aajeS
vFZ2Ek25ZWO9nG0D5VH07kfjXoPh/wAMaZ4atPKsINrt/rJn5eQ+5/oOK3KKKmJqVIqLeiHTw9OE
nJLVhRRRWBuFFFFABRRRQAUUUUAFFFFABRRRQAV4L8TPDLaL4ga+gT/QtQYuvoknV1/H7w+p9K96
rN1jSbXXNNn0+9j3wSjn1U9mB7Eda6MLiHQqc3Tqc+KoKtDl69DwnwX4yuPCl8yOrT6bO376FeoP
Tcv+1jt3H4Ee86bqllrFkl5YXKTwMPvL/IjqD7GvnzxT4U1DwtfeVcp5tqzfubhV+Vx6H0b1H9Ko
aRrepaDdfaNNu3gb+Lbyr47Mp4NepXwkMQvaU3q/xPLoYqeHfs6i0/I+oaK8r0X4wQSbYdasWib/
AJ7W/wAy/UqeR+BNd1pninQ9X2fYtTtpXbpHv2v/AN8tg/pXk1MPVp/Ej1qeIpVPhZtUUUVibBRR
RQAUUUUAFFFZl7ruk6dn7bqdpbn+7JMoP5ZzTSbdkhNpbmnRXDX/AMU/DNnuEM1xeP8A3YYjj82w
Pyrk9T+MV/KdmmadBbp/z0uGMh/IYAP510Qwdee0bepzzxlGG8vuPZa5XWfH/h7RAyS3yz3C/wDL
C1HmN9Ceg/EivD9W8U65rm9NQ1GeWJv+Watsj/75XAP41j13UssW9R/ccNXM+lNfed/r3xX1fUd8
OmIunW/95fnlb/gWML+Az71m/DuWSf4h6dLM7Sys0rMzNksfKbkk8muXt7ee6nW3topZ5W+7HGpd
j9AOa9T8A/D7VtO1e21nUilsINxW3+/I25SvzY4XrnufpXTWVGhRlFWV0znpOtXqxk7uzR61RRRX
z574UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAU72wtdStJLS9t4p4JPvRyLkf5968p8SfCW4
iZ7nQZfPi6/ZJmww9lc8H6HH1NexUVtRxFSi7wZjWw9OqrSR8q3lldafdtb3tvLBKv8AyzkUofrz
296rkA9a+p77TrLUoPJvbSC5i/uzRhx+tcZqXwm8O3nz2v2mxf8A6Zyb1/Js/oRXqU8zg/jVvxPL
qZbNfA7njVrrWrWP/Hpqd7bp/djuGA/IHFa8PxB8Vwfc1qf/ALaRo/8A6Eprp7v4NajH/wAeOrW0
v/XaNo/1G6sW5+F3iuD7ljBP/wBcbhf/AGYrW/tsLU3a+f8AwTH2OKp7X+X/AABqfFHxYvW+if8A
3rdP6AVIfin4qP8Ay82//fhazn8AeKo/vaLP/wABZD/Jqi/4QrxN/wBAO7/790+TCv8Al/AXPil3
/EvyfEzxa/TVET/dt4/6qapzeOvFNx9/XLn/ALZ4T/0EClTwJ4pfpodz/wAC2j+Zq1F8NfFsv/MJ
8r/akuI/6MT+lP8A2Vfy/gL/AGqX834mBc6vqd3/AMfWo3k//XS4Z/5mqOAOlegW3wg8Qy/665sY
E/66M5/ILj9a2rT4MKBm91l2/wBmGHH6sT/Kk8Zh4faXyBYTET6feeT0IhkkVETc7fKqryW+gr3q
w+FvhiyGZbae8f8AvXEx/ku0fpXT2Ok6fpceywsba2TuIYwn8hzWE8zpr4U3+B0Qyyb+J2PA9L8A
eJdW2+XpzQRN/wAtLr90PyPzfkK7nR/g9axbX1m+adh/yxt/kT6Fj8xH0216lRXFVzCtPZ29Dtp4
CjDV6mZpeh6ZoluYtNsobZCPm2Ly31Y8n8TWnRRXE227s7EklZBRRRSGFFFFABRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//2Q0KZW5kc3RyZWFtDQplbmRvYmoN
CjE2IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0V4dEdTdGF0
ZTw8L0dTNSA1IDAgUj4+L0ZvbnQ8PC9GMSA2IDAgUi9GMyAxOCAwIFI+Pi9YT2JqZWN0PDwvSW1h
Z2UyMyAyMyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4v
TWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMTcgMCBSL0dyb3VwPDwvVHlwZS9Hcm91
cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxPj4N
CmVuZG9iag0KMTcgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzE0Mz4+DQpz
dHJlYW0NCnic7VtLbxzHEb4T4H/o464BDvvdPYFhIJYcy0EISBHjGLADg6IoWQ5XTKhHcspvz/dV
9czOkjO7zC22rAN3qqerurq63tMyp0/N55+fnj365rGxX3xhvnz8yPzz+Mga21lrnfe2mOKtSdGa
26vjo79+Zt4eH51+/TyZ1++Oj5x5PU62Njsbd2a/+uz46Nnxkfnq7JExk5Xc6Z8u3r42q6u3J395
vm7LfnkOwn9wJsbO5mjOX5E8aBtnSuhq8Sam3HlvzjdcUxb++vjo+9XH86dn6xO/Mq/WPq5ubs2T
bxVe/82c//H46CsQJvGBWoi5K3VKDTTe3L7/cHG9hBKL63zcRdlcXP705u2V+d0U6d5W/WR3A7VM
Mm6X2l4iYVlewQR/T16xdjWaQLEp+c+treWL3b1R1jO4NXY17yCvnl1tPph1XL26Xbu6unm7rqv3
axfAzssFefmaulJ2iOzdYDy0wdn9+dIVf3iD8/ubIK+efNxc31y8vLo9XXu/end18eLNOqxu3i0p
UChd7HdJ7N1eWtre7oZ8dR1P4x7B6VQojb071Zj1SVjEwFm4XRQabEg4mcvvVycnC2jAoZnsoAmG
/TcMra6uXkYLKcHuoRr/2Q4mDL6ieugfsObS6tT8fu3c6tHTb5YsrA9d6JdFcE+meZ8PWbQJH1KX
HkS/HKI/R97Vvov5IeTrw1TCRYglPYRg/zCCfen8VmmHf0sq4GLn7uLsY8INMcR2OUlwiB57iGaj
TwnjAd60g2cAlBEp5Ofy+ChnK4/XfMycRiiXEUseQYpz8djrVDxB5iTXsLBHkqoyEeTxgHltSQBx
RIhCBLN+0kjlzb8QU+iSbRdywt8UnfkzYgxE8bP5pWzl+dy57I24ru6ocqDOgUEXul4OXQ7SabD9
bu16UNnnb0JJE+RDGuNHjQnwqVgIobbWYLyrHXa22Q54mG41Bb43FBiy6xyl0PnaDxAE4ODtYh0G
IC7X+y6EYcBBl2sdaA2QLkVsHXC575xT7DbgO59No4XT7IppKykA3MaKwkBtjCrc9tDojJAss9XA
WeX7VAUyq8eLmdDosryny3J9hQe6o73mhIlqliCGFHHB58G+yhS/Rb39WryYwGyjqROBQQh28Ocf
1ydl9f4fm81rmtPt3gXSHM0MJndJ7ucy3/XOPvVw7cbD8jZbKMHfQwly6nr+IGqWKC+yeKIQRgin
GqLvUhIIBjzBHyDQJpJCrmBtp3g6kEWDGhWXEl+3FRoE7MZAGwB2Y64NNMYbrQHSpQ5Z1ycjgll7
Wsxytpk88s0Mb5FpVnejwQ+rb5Htnf2wXgoFsEbEpgn2IRU9mBf5WroMkkhNxkTu/ClS0LPFeATf
xi1MMfYzcTCX8ihsini/fqD44uLy7+uQWmxcKox4rL3fxdxfP9rDAnGiB/ChYSD5+BYCYQ3zcQ2O
bhcFk5ls72DuZ8aNDiQh/7BdsbSoGoO5hVIkH0jPR/oXWtM4EKiNyUtR6CPCBIAq+b4AzIMQPHxs
MLMhHHMdJufeDkT0URYgFiHvqBDXDULo6nszoLuMas8MxBViMtVW14FrDihvOjDwrbQGSNc55E8+
ISHMeRTvD+lrgsOC2jDjsOWeR3l2RfPZfFhQ2WztHeTlSjmjgHW7U8+fnkmp/P4N7OLdXlUPs40b
1FB7Vr9PJT7IYCzSnjLVFWTPluqRh/PA6xSsvhNItCUMkOhKHg7bNQ1RKvKoKzRlcfAYDYkQ8oeA
vSm+Q5ghPrMxfaSm6NJtQDRFOGsDjetGaIB0kYeay69eBLPGcrAxlJgGMJ3tZ2oxaXzGlfmObTmN
O+/YZXn/4cVLNkBvNu8WbaOCwzyhe0iRF9stI6fcLLNROJWxyeS85s6LzSz2S+IOkiC8vH2Djd0L
XvfZKnNWGpBI+QnRQ3urk8a3drJtyb12tX2MLs60wBcMGvrmWOb3/KE2OwvX7bJ6+8hkiOHWwaHG
qFv3zN6pYUnzPwzAK6cMqjIXGplyoUdmOocijXNLYlvI4cdCisgmRFkRzuH1bZYUA4oZNKpA80HR
IWfBeHaOcYMQDMM1tfVdkRw1OxxIEVIRISOolkCr+2RybItmbo6TY5WisUgGipKiUwNBfZhT6FJb
s2pPxDOMkFQEqdLraykmYYJdroLaK8d9krJSsqyMUkxYchLToLFJRaGVYkFaB+ZYC2ELBTK2LCSD
QNgNm2hw233SyT07txxAKkjI6mueMQId1Qape9HJMHlKHedSHCgXbcglclMgRVp/dNwHJ0PqBZMR
lSHrgjBVwVToUaDlPlI+BILKDQPcEaRbGaWtbNZjY2z9BAY4gdRbsZSIOlBFyBQ5WIPEYxa5oZK3
2njC6pXIEAkE56F7rIidEEYBajEZrimoR2MOWmSyS7DEpFBi05fGzPrBq7ZlJ4U9ZnrMDDLFwf95
zRJY5NPmNKmA5KPCVd4mfZt1btR3RXtatA59DVIRB00Rgj68ZmTXMYjUvLQiYp/FfCBySFgmS3sU
NpNsoFbxbFzUuV6QUcsj6MRaqc0uyZlFKBdVBGlIcDpZojoPPpCWHDCVAobnIKMwUaCfxo9a/5uz
mA19vzmL35zFb87iV+0snouvWLL/ojzC9rLav5ePBVFyvmSbDkVKhVwXYTo00YkGUC1iKzMLm4GA
vZMqU04+0F+IYL1ITu1LTizzxMgYkWFi1ckAlkLixHPACuAmwexo9UF0tRmyS0I7y9eQDMFx30Ec
CyGKl5/IgmhdEaXzWqsWTbGjlJ4bLXHla0hmx5nKnvSkvNoCVSmImxGLrKKkEH7ttROexT+lTI4L
PzpkOSxwUKAvNP4kbR+xpOZHsBNZGjC1Mfc8aVqh1RY0WAWkXqL5LmA68XxOt5ysSB8D2A3tjD3x
Ivol3kxdqtM9w/wpH7ryKtg4Z/GNjraRnRKCDtDDCiFP5yvGVNRZW3IuB2XVPVu61URXnIRnKja9
aRG2ezWYKMtQVaPqFz/HEwZ1AqF5NycQ+UhDA362XDnYF2N5rh1+OzTfv9YPjWx1y3fqegdYqgzU
CzjUP3Fobk++Pf34cX3Ss3f+8urjjzf/QLGwt5oPdo7Z3FzIZIn91zC27S9N+3OgQeMMmfuHwHrD
hcLT34wwEoFAP08d9/TW7PPWAeAxIeKOL1lYMuaOE3gwRai0J6V/qacJGGEpNTyFC9V4IOKk19KW
UOBSG9bjS2lEK4M60BhXQgPQt1X3FvOfjAjmrCMc7HwFuCJ2arUpfreaf7LUpc3SPJ9gofLX+yos
8oc7K7SKixdvbvbbwVxXi8HT9rsL7LeDbVerwncwz6zyV2tgXvqBCOFKenU7bQD7YP6J6FJ4v8jy
deJ1HD9AdJa+TgbYn4F5wku3gYxYsKU1QLoUsXXAIwIM2DoAB84WqNJCmi60dKkGSViMkwHqk/La
Bto+Gq0B0qUOtrk+XaHM2srhxhfSMMS0gFB5v0n8ZB2WP+Bm5D5IR7eYh7T5cGsLeYgtCH8I4I3i
t4tfmzJz3LAzef/yZRtUUruBwnIy9tJeQrI/7ZPqx/MWy/0AJxs1Ka2M3iMk9Yy4Vx1ALpu0dzkM
IDMwTJWZCEiOHFnDyFNLosc3DcdbO1nDo07YWcPTN0/X8CxkTOOW3yzGXqkCC6lGqNtrIeJhULNg
OszpVi4VZdlNlbQ5sKIdB2AFYCsxf5TH8XOHQF6S+4ZBZvFDau2Rm2YKFMd3dUSSx5GaQo5nFZE8
I9BwUeT9EVlFxPlbT2McZip0rVDj9PoBN49+VVudPejD99ZQ+aQqX57S/R74s6sNo+CHxY+/vTQV
pNE9dLp5jzXyHmviPda5T7b3L6jOJZAR9mbzLu3911zdttN80rpHzvq0v3uky1HvM++YQaJ9K50g
kQEevvyhjMfJCFR33pamSA1iOYnX1TZzLXCXfrx9MH4XcUyA5B6bNDomr1HI+SmBnc7Ywzc3f9/O
mp9NNWf/7xt+Pn+9Pfp9dUK2hg0t2ZA18vEeRSONJsmNP5Sr7cqfh6PsQ7v25710NHiH1YvZNcwG
CUnBETBTUtcjCEMn+UYD/DfSrWvEJXVTjQ8A4K1h4UnIHcpxfuEbm/NOcc/Ne96bRK2wew3Y+SKd
N1Te/f0U//wpXM7ixbOsydwW9ZA3ife9SXTZtf+7UYNzMwbXW1kPrjsUj+TPyn9uyMFcYsXTbzYX
r698MI9vzKDZ/wUhRLTyDQplbmRzdHJlYW0NCmVuZG9iag0KMTggMCBvYmoNCjw8L1R5cGUvRm9u
dC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FyaWFsL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2Vu
ZGFudEZvbnRzIDE5IDAgUi9Ub1VuaWNvZGUgMTQ5IDAgUj4+DQplbmRvYmoNCjE5IDAgb2JqDQpb
IDIwIDAgUl0gDQplbmRvYmoNCjIwIDAgb2JqDQo8PC9CYXNlRm9udC9BcmlhbC9TdWJ0eXBlL0NJ
REZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0
ZW1JbmZvIDIxIDAgUi9Gb250RGVzY3JpcHRvciAyMiAwIFIvVyAxNTEgMCBSPj4NCmVuZG9iag0K
MjEgMCBvYmoNCjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVt
ZW50IDA+Pg0KZW5kb2JqDQoyMiAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFt
ZS9BcmlhbC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA5MDUvRGVzY2VudCAtMjEwL0Nh
cEhlaWdodCA3MjgvQXZnV2lkdGggNDQxL01heFdpZHRoIDI2NjUvRm9udFdlaWdodCA0MDAvWEhl
aWdodCAyNTAvTGVhZGluZyAzMy9TdGVtViA0NC9Gb250QkJveFsgLTY2NSAtMjEwIDIwMDAgNzI4
XSAvRm9udEZpbGUyIDE1MCAwIFI+Pg0KZW5kb2JqDQoyMyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0
L1N1YnR5cGUvSW1hZ2UvV2lkdGggMjU4L0hlaWdodCAxOTYvQ29sb3JTcGFjZS9EZXZpY2VSR0Iv
Qml0c1BlckNvbXBvbmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5n
dGggNjY1Mj4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEBAAAAAAAA/9sAQwAIBgYHBgUIBwcHCQkI
CgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJ
CQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIy/8AAEQgAxAECAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkK
C//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNi
coIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SF
hoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn
6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQE
AwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBka
JicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWW
l5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5
+v/aAAwDAQACEQMRAD8A9/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKqXl9aafbm4vLmK3iX+OZwo/M1xerfFnQbHclik+oy4/5ZrsT8Wbn8ga0p0qlR+4rmdS
tCn8bsd/RXhuofFrxBeP5dhDbWYb7u1fNk/NuD/3zWebLx94i++mrzo3/PRjFH+AYqv5V1rL5pXq
SUTlePg3amnI9yutY0ywH+majaQf9dZlX+ZrHuPiD4Vtfv6zA/8A1yVpP/QQa8vtvhL4mm/1i2Nv
/wBdJsn/AMdU1qw/Bm9b/X6zbRf9c4C/8yKr6vhY/FUv6f0yfrGKl8NO3qdbJ8U/Cq/du53/AN23
f+oFRf8AC2vDPref9+P/AK9YUfwWQf6zXnb/AHbUD+bGpD8F7btrk/8A4Dj/ABp8mBX2n/XyFz43
+Vf18zcj+KvhZ+tzcp/vW7/0BrQtviD4UuvuazAn/XZWj/8AQgK4t/gtIB+719W/3rPH6h6y7n4Q
a9F/x73NjOP95kP5FcfrR7HBS2m1/XoL22MjvBf18z2S11Kyv499ndwXC+sMgb+Rq5XzZf8Ag7xJ
o8nmzaTcrt/5aQ/vAPfchOPxxUulePfEmkn9zqks8X/PO6/ej6Zb5h+BFN5dzK9KaYLMOV2qwaPo
6ivMtC+LthdMsOs27Wb/APPePLxfiOq/r9a9Ftbm3vLdbi1mjnhkGVkjYEH6EVw1aNSk7TVjtp1o
VVeDuWKKKKyNQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKwfFL62ujOugIrX0kiorNjCK
erc8ce+fpTiuZpCk+VXLGteItK8PwedqV2kAb7i9Wf6KOTXm2pfE/WdauPsXhfTpV3f8tfL82X67
RlV/HNaul/CxJJ/t3ibUJdRum5aNXIX6Fj8zfpXe2GnWemW/kWNpDbRf3Yowo+px1PvXWpYelsud
/gcjjXq7vlX4nkVt8NfFHiC4+169ffZ93/PaTzpfwUHaB7Z/Cuu0v4U+HLHa90k99L/02kwv4KuO
PY5rvKKmeMrS0vZeWhUMHSjra789SjY6VYabHssbG2tl9IYwn8hV6iiuZtvVnSkkrIKKKKQwoooo
AKKKKACsDWvCOia+rfb7GNpf+e0fySD/AIEOT9DkVv0VUZSi7xdiZRUlaSueFeKPhjqGjI13pjtf
2a8su396g9SB94e4/Kud8O+KdT8M3fm2E37pmzJbtykn1HY+45/lX0vXk/xI8CRmCXXtKi2uuXu4
VXhl7uo7EdSO/XrnPqYbGKp+6r63PLxGDdP95R0sd14a8TWPijThd2blXX5ZoW+9E3ofUeh7/mBv
V8yeHdfuvDmsRaha/wAPyzR9pU7qf6HsQK+j7C+g1KxgvbZ98E8YeNvYjNcuMwvsJXWzOrCYn20d
d0XKKKK4zsCiiigAooooAKKKKACiiigAooooAKK4Dx546/sTGk6T+91efC/Ku/yd3Tjux7D3yewP
UeHba6tfDmn299k3aQr525tx34ycnuc961lRlGmpvrt/mZRrRlNwXQ8mf4veIVkdBbab8rEf6l//
AIuvVvDGpz6z4bsdRuVjWaePeyxqQvUjgEk9vWuAf4LF3d/+EgHzNu/48v8A7ZXonh/Sf7C0Kz0w
zef9mj2eZt27uSc4ycdfWurFywzglR3OXCxxCm/a7GrRRRXAd4UUUUAISB1rH/4Svw9/0HdN/wDA
pP8AGtS5/wCPSX/cP8q+UV/1aV24PCxr813axxYvFSoctle59WQzxXMCTQOskUihlkRshgehBHUV
PWH4P/5E3RP+vGH/ANAFblcklyya7HXB3imFFFFSUFFFFAHh3i/xp4j0/wAW6jZ2uqSRQRS7Y41V
eBtB7jPeu4+GOs6hrfh+6udSu2uZluiisygYXYpxwB3Jrynx7/yPWr/9dv8A2UV6T8HP+RXvP+v5
v/QEr2MTTgsKmlroeRh6k3inFvTU0dV1TU111IoLho7fzfLk2quIBlBuZiepDlhkEfdGBy1dRYzm
9022mmVd80Kuy9uQCeD2ouNOs7p/NntIZX27dzIDwOQD6jParteXKUXFJLY9OMWm22fNnjLRBoHi
q8so022+7zYf9xuQPwOV/CvSPg/qzXOjXmmSNn7JIHj/ANx8nH/fSsfxrG+M9uq6rpdwPvy28iN9
EYEf+hmqnwfmZPFV1D/BLZk/irrj+Z/OvXqv22C5pb/5HkU17LGcq2Pb6KKK8Q9sKKKKACiiigAo
oooAKKKKACuY8a+KIvC+htcLta8mylrGe7/3iP7q9T+A7109fPvi/U5/GHjn7NatuhSYWdr6fewW
/FsnPoB6V1YSgqtT3tlqzlxdZ0oe7u9EdN8MPDr6hdS+KdT3SuZG+ztJzvf+KQ/Q5A98+gr1w1S0
2wg0vTraxt12xQRhF/AdT7nrV01nXrOrNy6dPQ0oUlSgo/1c+aZPFviNXbGuah94/wDLw3r9a908
FXM154N0y5uZnlmki3NI7ZLcnqTXznL/AK+X/eP86+iPAH/IiaT/ANcf/ZjXpZlCMacbLqebl05S
qSu+n6nmPj7xFren+N9RtrTVruC3Ty9sccxAXMaE4APqSfxrm/8AhL/Ef/Qd1D/wIb/GtL4l/wDJ
QNU/7Y/+ikrrvhLpljf6TqL3ljbTulwArTQqxX5BwMit+anRw0ajjfRfkY2qVcRKmpW1fc4AeMPE
fbXNQ/8AAg/4113g/wCJuow6lDY63N9ptZmCCZlAeIngEkD5lz1zzznPGK77xL4X0Obw5qBGl2kT
x27vHJHCqshVSQQQM9RXzueY6VJ0cXBrlsOqq2FmveufV1z/AMekv+4f5V8op/q1r6hspGm0G3lf
772qs31KA18vJ/q1rDK1bn+X6m2Zu/J8/wBDXi8Ua7bWqQwazexRRrsjjWZgAAMAAZ6V9E3GoW+m
aN9uvZfLgiiDySN9B+ZJ4x3JrF8LaFpM/hLR5ptLspZXs4mZmt0JZigySSOTXI/GHVmT+ztGifah
U3Eir3wSEH04b8hWVRxxVZU4q1m7mtNSw1J1JO97WMHxF8T9a1WZk06ZtOs/4Vjx5rD1Z+x9lx9T
XK/25q3mb/7Wvt/977U+f5103w38MW3iLW5nvk32lmodo+zuxIUH24Y/gK9rfRNLktPsj6daG324
8vyV2/gMcV0VcRRw0vZxic9KhWxK9pKVjx3wx8T9T0y6WHV5mvrBuGduZYvcH+Iex59DXtsE8Nzb
xTQuskUih42XowIyCPwr5z8ZaGnh3xPdWMO7yOJId3XYwyBn2OR+Feo/CXVHvfDEtjI+57GYop/2
G+YD89w+gFZY2hB01Xp7G2CrzVR0ajvY8y8e/wDI9av/ANdv/ZRXpPwc/wCRXvP+v5v/AEBK828e
/wDI9av/ANdv/ZRXpPwc/wCRXvP+v5v/AEBK2xX+6L5GGF/3t/M9GooqC4nhtbeW4mdY4olLyM3R
QBkk/hXiHtnj3xku1k1zTrQf8sIC7f8AA2xj/wAc/Wofg7bs/ie8uP4I7Mr+LOuP0U1yHiPWG1/X
7zU23Kk8n7tW7IPlUfkB+Oa9W+EWkGz8Pz6jIvz30vy/7iZAP/fRb9K9ysvY4Pke+x4lF+2xfMtj
0eiiivDPbCiiigAooooAKKKKACiiigDD8Wan/Y/hXUr5X2PHCRG3+23yr+pFePfCuwF542ikb7tp
DJN+PCj/ANC/SvRPitKY/A0qDrJcRL/49u/pXIfBsL/b+pZ+/wDZR/6GM/0r08OuXBzkuv8AwDzM
Q+bFwj2/r9D2ig0UV5h6Z8oy/wCvl/3j/OvojwB/yImk/wDXH/2Y188TgrPKjfwyFf1NfQ/gD/kR
NJ/64/8Asxr2sz/hR9f0PFy3+LL0/U8f+Jf/ACUDVP8Atj/6KSu5+DP/ACBtU/6+h/6AK4b4l/8A
JQNU/wC2P/opK7n4M/8AIG1T/r6H/oAp4j/co+kf0DD/AO+S9Wd1r/8AyLuq/wDXnN/6Aa+X/wDl
nX1Br/8AyLuq/wDXnN/6Aa+X/wDlnU5X8Misz+KJ9P6b/wAiza/9ea/+gCvmBP8AVrX1Bpab/Dlk
n960Qf8Ajgr5g2lfkb5XX5WWjLd5/wBdwzLaHz/Q+lvB/wDyJuif9eMP/oAryf4ubv8AhNUz/wA+
ce3/AL6f+ua7fwj408PxeFdPt7jVLe3uLaBIZI5m2EFRjv1zjOR61g/GHS2k/s7WYlDxBTbyN/dz
yh+nLfmKww16eKfMrXubYlqeF913tY860rTtY1Dzf7KtrufyseZ9nzxnOM4+h/WtL/hGvGH/AEDt
V/8AHv8AGrHgLxSnhfW3e43fY7lBFNjkpg5Vsd8ZPHoa9qj8W+HpIRKuuafsx/FcqCPqCcj8a68T
iKtKdlC6OXDYelVhdzszwmTwl4plffJo2oO395oyT+tei/CfR9T0h9X/ALRsZ7XzfJ8vzlxuxvzj
8x+dXr/4qaFZ6tBaQl7q33YuLqP7sXoQMZfnrjt0z0ruLe4hureO4t5VkhkUMrq2QwPQg1x4nE1n
T5ZwsmdWGw1FVOaErtHzv49/5HrV/wDrt/7KK9J+Dn/Ir3n/AF/N/wCgJXnHj+No/Hmrbv8AnsG/
NFIr0f4Of8ivef8AX83/AKAldWK/3RfI58N/vb+Z6NXjPxI8cpqG/Q9Ll3Wqt/pMy9JSP4Af7oPU
9yPTqz4i+NtTk1K80G1JtrWBtkjI3zzcAkE9l5xgde55xXBadpt3q97FZWNu09xJ91V/mT2A9TWe
DwajarU9V/mXi8W5XpU/Rlrw9oVx4i1yDTrb+LmST+4g+8x/p7kCvpKys4NPsYLO2TZBAixxr6AD
ArA8HeErbwppgiXbLeS4a4m/vHso9h/9euprkxuJ9tO0dkdeDw3sYXe7CiiiuM7AooooAKKKKACi
iigAooooA4n4qQ+b4Dun/wCeUsT/APj4X/2avPPhReraeNVhf/l8t3iX6jDD9ENex+I9M/tfw5qO
nj708DKn+9jK/qBXzbZXlxpl/BdwfJcW0gdd3qpzg/lgivWwKVXDzpf1/Wh5ONfs68Kh9UUVmaJq
9trukW+o2rfuplzt7oe6n3B4rTrymmnZnqppq6PGvGnw31E6rPqOjQ/abedjJJArAOjnlsA8FSee
ORnGK9D8E2s9n4O022uoninjiKtG64K/MeoroqK3qYmdSmoS6GFPDQpzc49TxHx34U17U/Gmo3dl
pc09vL5e2RcYOI1B7+oI/Cuu+Fujajo2k38Wo2kts8k4ZVkx8w2gZ4r0Ciqni5zpKk1orfgTDCRh
VdVPV3/EzdahkuNC1GGJd0sltIiKO5KkAV4B/wAIJ4o2f8gO5/T/ABr6Roow+KlQTUVuGIwsa7Tk
9ijpUTw6RZwyJtdLdFZfQhQCK8x8Z/DG8utRn1LQxHIs7F5LVmCkOepQnjBPOCRjt6D1yis6NedK
XNE0q0IVY8sj5wfwD4q+b/iTXP8A30v/AMVXvtzp1tqWjHT72LzbeWIJIjfQfkQec9iK0qK0xGLn
WtfSxFDCwo3trc8M1/4Vazp07vpQ/tC1/h+YCVR6MpwD9R19BXLt4W8QK+w6HqW7/r1f+eMV9N0V
vDMqsVaSTOeeW027p2PANG+GXiHVJ1+0W/8AZ9v/ABSXHX8EByT9cfWvaNA0O18O6PFp1p5jRx5O
52yWJ5J9Bk9hxWvRXPXxVStpLY6KGFp0dY7nAeO/AH/CSumoWEqRagqhGEuQkoHTJA4I9cc9KtfD
fQtR8PaHdWmpQiKVrouu2QMCuxRnIPqDXa1nT6tYW2oW+nSXca3lxnyoAcu2ASTgdBgHk8VPt6kq
fst0P2FONT2uzPM9V+G+q+IfGmo3krxWdhJNuWVjvZxtA+VR9O5H416D4f8ADGmeGrTyrCDa7f6y
Z+XkPuf6DityiipialSKi3oh08PThJyS1YUUUVgbhRRRQAUUUUAFFFFABRRRQAUUUUAFeC/Ezwy2
i+IGvoE/0LUGLr6JJ1dfx+8PqfSveqzdY0m11zTZ9PvY98Eo59VPZgexHWujC4h0KnN06nPiqCrQ
5evQ8J8F+MrjwpfMjq0+mzt++hXqD03L/tY7dx+BHvOm6pZaxZJeWFyk8DD7y/yI6g+xr588U+FN
Q8LX3lXKebas37m4Vflceh9G9R/SqGka3qWg3X2jTbt4G/i28q+OzKeDXqV8JDEL2lN6v8Ty6GKn
h37OotPyPqGivK9F+MEEm2HWrFom/wCe1v8AMv1KnkfgTXdaZ4p0PV9n2LU7aV26R79r/wDfLYP6
V5NTD1afxI9aniKVT4WbVFFFYmwUUUUAFFFFABRRWZe67pOnZ+26naW5/uyTKD+Wc00m3ZITaW5p
0Vw1/wDFPwzZ7hDNcXj/AN2GI4/NsD8q5PU/jFfynZpmnQW6f89LhjIfyGAD+ddEMHXntG3qc88Z
RhvL7j2WuV1nx/4e0QMkt8s9wv8AywtR5jfQnoPxIrw/VvFOua5vTUNRnlib/lmrbI/++VwD+NY9
d1LLFvUf3HDVzPpTX3nf698V9X1HfDpiLp1v/eX55W/4FjC/gM+9Zvw7lkn+IenSzO0srNKzMzZL
Hym5JPJrl7e3nup1t7aKWeVvuxxqXY/QDmvU/APw+1bTtXttZ1IpbCDcVt/vyNuUr82OF657n6V0
1lRoUZRVldM56TrV6sZO7s0etUUUV8+e+FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFO9sLX
UrSS0vbeKeCT70ci5H+fevKfEnwluIme50GXz4uv2SZsMPZXPB+hx9TXsVFbUcRUou8GY1sPTqq0
kfKt5ZXWn3bW97bywSr/AMs5FKH689veq5APWvqe+06y1KDyb20guYv7s0YcfrXGal8JvDt589r9
psX/AOmcm9fybP6EV6lPM4P41b8Ty6mWzXwO541a61q1j/x6ane26f3Y7hgPyBxWvD8QfFcH3Nan
/wC2kaP/AOhKa6e7+DWox/8AHjq1tL/12jaP9RurFufhd4rg+5YwT/8AXG4X/wBmK1v7bC1N2vn/
AMEx9jiqe1/l/wAAanxR8WL1von/AN63T+gFSH4p+Kj/AMvNv/34Ws5/AHiqP72iz/8AAWQ/yaov
+EK8Tf8AQDu/+/dPkwr/AJfwFz4pd/xL8nxM8Wv01RE/3beP+qmqc3jrxTcff1y5/wC2eE/9BApU
8CeKX6aHc/8AAto/matRfDXxbL/zCfK/2pLiP+jE/pT/ANlX8v4C/wBql/N+JgXOr6nd/wDH1qN5
P/10uGf+ZqjgDpXoFt8IPEMv+uubGBP+ujOfyC4/Wtq0+DCgZvdZdv8AZhhx+rE/ypPGYeH2l8gW
ExE+n3nk9CIZJFRE3O3yqq8lvoK96sPhb4YshmW2nvH/AL1xMf5LtH6V09jpOn6XHssLG2tk7iGM
J/Ic1hPM6a+FN/gdEMsm/idjwPS/AHiXVtvl6c0ETf8ALS6/dD8j835Cu50f4PWsW19ZvmnYf8sb
f5E+hY/MR9NtepUVxVcwrT2dvQ7aeAow1epmaXoemaJbmLTbKG2Qj5ti8t9WPJ/E1p0UVxNtu7Ox
JJWQUUUUhhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/
/9kNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNCAwIG9iag0KPDwvVGl0bGUoUG93ZXJQb2ludCBQcmVz
ZW50YXRpb24pIC9BdXRob3IoWHUsIFF1YW4pIC9DcmVhdGlvbkRhdGUoRDoyMDE0MTEwNTIxMTU1
MyswOCcwMCcpIC9Nb2REYXRlKEQ6MjAxNDExMDUyMTE1NTMrMDgnMDAnKSAvUHJvZHVjZXIo/v8A
TQBpAGMAcgBvAHMAbwBmAHQArgAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAgADIAMAAxADApIC9D
cmVhdG9yKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABQAG8AdwBlAHIAUABvAGkAbgB0AK4AIAAy
ADAAMQAwKSA+Pg0KZW5kb2JqDQozMSAwIG9iag0KPDwvVHlwZS9PYmpTdG0vTiAxMTkvRmlyc3Qg
OTc2L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTc3Nj4+DQpzdHJlYW0NCnicrVnbbhQ5EH1H
4h/8uPvULt8tISR2AS2CRRFB2ge0D0PSGyKSGTRMJPj7PdV2Xyb0uHt6Rpqk+lLHrnIdl8tuFYUU
WgtLQitB0ghtBTkntBOKvNBeKBeExo+i0Ph5KQx+ioTBzytcCqu0MGjEW2GMcMoLY4Xz0DbCa6g5
ERxUgogEFS+ig0pEfypy1yQDoRFBxKZIyBCE1YKU9cLCIC2h5yAd9IwgQ9wbZEDnaMeiIwecDU7Y
AAdgMFTJSy/QMXkoObQfiIQDPngt4CRFxXZCeuhZoSQGAe4qkiTgqELDwpNQSkIvQqITuKw07EYT
Ske8N0IZGAPnlcWweIycDVZ4Hjo4iWFQnttDux5OBLQbKAiYrgI6geuK7QhoLwYvANUSIx0QCxkN
Rg5jzzjEQEngEBUFpwKGVwOn8FzjJiKEDn4Coj38hGnaw6nI4YNSBC6gUZKIeETUIgcUb6NDRHk0
JcdUcTgQVYJ/JBE0hT6YGEZ51kH82PvIMrAu0KZpNiDqmlU4/JFfRUSew0fMFLwnQsOeA0GgUACj
EHFcsDITI4I9RGiQzSLQz8qGFSAD90NkcMFxBtIq0ImttRp2k5K44NArMAI24wLKBkEBicAhmExg
qWWGkAJLXKOMlnmsCJS13vETtBx4KoC2NoSGe6CY4SfghmQzGrIx7TBXHHvAtHXERMK0cWAFLph4
GDXCjdM8ukxJQ0xeiQuwASwG6TBvCH+IHFpGN87xBOBp5KEcoeuZQeCTRAuw3HMnsNdrMBHGeYNu
ogLfwIxnz6oLZoQUH6rL6vLbal19/Pmtri5324er3au7+r66uBG6ef9WyOfPnz5pIPAtQS5+0X/7
SYCh/4oO2IG6fj7WP3afNz/GoLqBjKExioUu9fEQczzEHg9xx0P88ZBwPCQeDyG5AEMLMKP0mcCM
MmAW5Szr8ArWCJ9ESCI2AlOwEZSESkInYZKwh4g7e3qR6TDGF30d5eEcX0043UrXYawsWjnK4wkM
0twoMec4Z1N4rDrZR9VnOltknRpl9wRmcXK0ianWne6g7o0NRWNHs+QEZjE9bZpuTp7uYM9SV1yr
1ChL5xjrDi5V860MvZW2aOXopChjsNbrUXrOci5lQ+dP9lGr3t5YtHc0g09geAOy1EefsrqnSR9f
3948bOvqxd3ut9/FqB2jy/wR+DILp/GjBcAR+HLSncSb0cpgNkcMdRhfTC1Yes3ihd7Hk8ls+iU6
UNFQbE/KnCgYGk5fwYzvDS1XwdiGLV5xw+lFj+2X2lAseixv+RcbOl33THLcjhOvzcGXd7fX9Xju
TqVkqhp1LhdTfk11Hp9tNAt7Skg2FZapiuBzi0akgtSlGietaXw20YhUF7iskhrzScWnxnzS9EnT
p959ajpNOT5oaETqISRcIg8fKjQiAcLBiRTb6u5Q2MnluPdhj7pYEbZ7yYT8tadC1KPp7XwMb7n2
7o/N9c/CjvIxzrW4N6M9hsM9xqkezZIe+XjmYJctN9+N2pqCGeM0vrQZPgrjFmD8AkxYgInLeZZm
Bx+IJamy1FmaLO3hoZ49caifOXx0Vpo6tNgjPp07g6l96ccneCVTx2fbFMp0W+ElPlIOF6lz+OoG
VpdPKsYJPYUap/QUapzUEyglTxhUmwc1zwnyWZ6DUKqvE/kEt+QCn7ov90LROaw1A2uLi5waZ/EU
ynW710U+5qykzpGVBjtZPhwvWR2xMz3B6nPwSA94pIs8QtWmT+CRPgeP9IBHusgIfYBHE6gDq/Is
BzOJ9AwSzd4FLx+pAQt1cSOpY7dnXeR2oWia7a6ZWJ8n3TWD9dUUT7nMCRw2+hy+jhe307unmBbp
tEnIFVzzFTHJvLrImFcZmWWuvCjTk/J7ld+rXKGprKdyeyq3l/dsOTk03/KSzPr5YwHlrwWZbM23
uiRzaZE/FZA5tBMZePxxW9cfNptd9WFzV/+9+iaSUdXFaluvm7ciZ1bOoqnD2BX/ndJ7hPJt/VO0
3HiNJtebXV2953+v1tf9TRv1y/pqV/1Vr67rbbpmTHv9Zn13u64vv6zYUH7wYo0WVrvbzTrfb3e3
/61w0dz9s9l+/bzZfK1ebq4e7mFT8+T7l7resZG76u/V1XYzuP/zC/4P7l/eru42N4MHiRq9buoH
ajfb1X1mXvb1/cP9908YkTZs/J2zGR9+3+/E9Z444+efbluf4O22fvhdohN5kz880u/2+sNj8G7L
nwDtln94PtuJ1O3euWYn5h8HxKFoTwXUnsiHA3ZP5DOCsCdyouThb6ey2RN55sgcsnl7qEEGaPFt
Btgr6geyzQjF+nSQKeiRbDPGXtU0kG0GCY9km0nokWwzyt4COpJZ4r78JcPo/Qzz9Mn/rHbhww0K
ZW5kc3RyZWFtDQplbmRvYmoNCjE0NSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0
aCAyMzU+Pg0Kc3RyZWFtDQp4nF2Q3WrDMAyF7/0Uuuwuil2XDQYhUDoGudgPy/YAjq1khsU2inOR
t5/slg4msOGg84kjyXP31AWfQb5TtD1mGH1whEtcySIMOPkgDgqct/mq6m9nk4RkuN+WjHMXxiia
BuQHN5dMG+xOLg54J+QbOSQfJth9nXvW/ZrSD84YMijRtuBw5EEvJr2aGUFWbN857vu87Zn5c3xu
CUFXfbiEsdHhkoxFMmFC0SiuFppnrlZgcP/6+kINo/02VN1HdiulVcvqeP/ISiv9UNmrq0wpy94i
2pWI09WL1FglkA94O1qKqVDl/QKE7nHRDQplbmRzdHJlYW0NCmVuZG9iag0KMTQ2IDAgb2JqDQo8
PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDg5MjQ1L0xlbmd0aDEgMTg5MTkyPj4NCnN0cmVh
bQ0KeJzsewdglEX698y+u5vNlmQ32dRNsptsKklISCihSJY0OiQkCwkQSEioUkNHmgXUIIKKBSue
igWUzdKCWFCx9+7pqXh66p3i2T2BJP/fvM9OCFg+ve++7777LpP89vebZ8o788zM885KZJwxFoEP
LSsvqRw+9OTyb5OZ5sn1jDkuKS0qqbrmqbBMxl5YwZjt7tKiUcXTIqcPYezJfzCmXz+0pLTsk8e+
OcU0j21lTPliaPnYytmNAy9g7Fgy4zeah1Z6ix5/78MOplmdy9jQKWMrc/J+/Oitdsb4W3hqXcO8
+oWvhL34MWPpjRjAsIZlS1y+G46+wlgNynVxMxbOnPf996PNjGXtZiw4dmb94oUsjrnx/E/R3jpz
7soZNx44kMLYlG8Z62OdNb2+8eOU9nPQ/2SU950Fg+XeoN7Ib0M+eda8JSue2mD/jDFNAWOpPc6d
3jT/Ev/WSxnzj2IsaNrcBQ317kejf2Bsm5axhLJ59SsWJmYn34r2rWjvml8/b3rqsgo865CPsZDI
hQsWL+lwsI0Yz1OifGHT9IXn7tFgfn2QT7Yy4Vvdza0b/D3GTw0d9B2LMTCRDn+2+jnBjyddt+rk
ibZNwZ8HHUA2mGkYJbTTs3bGjxp3nDxxYkfw52pPXZLyjbCEJrE6plMNGmZlOWw6VmkrnqtW0Wby
rSg16Lbr8tFlArHyEtuoYQamCdVpNBqtotF+wDQdHra7Qx0B0uhKl4t5MJ1UGkPQzZpUF+O3qJ0e
1IWImaL3kNOj4S9i9W4V6/L7k7aE1f+s/XO2+5/p7xefc+p0fxrtv7ZvkfRv/nKfulGs4ff0pU2i
vnTTWIO2+sx+lXvZ0J9ro3zMQn/PM854XjNL+ll7Gsv9Z/vsTv8dSXmdTf69bbS92XZlGpv4G+vW
nfG8k6z2t7TTLGIpv3dc/zeTcpT1+S31hK+k5m+wDf/08247o5/tP1dH38i2d33eT8ZS8NvWrLN+
l740z5zZr5LIKn5LH5r7WOLveeb/TsJ4t/3WuspNLEnX+tM1VJazDOWWn4+n3ak7dafu1J3+e5Lm
Bm783W2S2WGNjl2r28iu+VeNQ4k6+ztk4FmLWemvtjvV8eMZ9eexDcCqf9W4znwWO0flPmzT/4n+
/5sTvq8POyufC0z/d42nO3Wn7tSdulN36k7dqTt1p+7UnbpTd+pO3ak7dafu1J260/8XSQkgjv4V
gg9CDkpJZ1rugiGXuZiWWaEsLIllIN+HDWBDWAkbzkazKjaeVbOpbDZbyFaytWwHu9dldaV2dKh9
W9A2nWWz3mqLYjYMLcYGWtSzc1nTGS14x3d47njgASW+4zHRQccP+IhniYojMNiojgbN4x9O+zA/
8G8mWUDPwEx6qn8TlRvI9cYIx5w5U2WEcq3SpFQrc5XPWRiLRuscNpJNYDVsIpvCGrmGh3Irj+UJ
PJ2X84m8ls/lC/hSvoyv4Zfyy/hWfj3fz4/wR/gT/Emm55+r/X71k3+/4UwT+ItBDfv1xE+PrMtA
1yrrAkqOlnJfKl911plwRj9aQMyIBbySE1AlQJcZIrcYWHmGW1ZhGD+ZOWxd5o7c2bOXra/+X8zw
35KUGnVP/+tS91n41bPgGdo4dUrt5EkTa6q9VZXjKsrHjhk9auSI4cOGlpWWFBcN8RQOPmfQwAH9
C/r17ZPTMzsrPTUl2Z3kjLbbrKEWkzHYEKTXaRUNZ1ml7rI6ly+1zqdNdQ8bli3y7noY6rsY6nwu
mMrOrONz1anVXGfW9KDmjLNqeqimp7Mmt7oGsUHZWa5St8v3fInb1conVlRDby5x17h8x1U9WtXa
VDVjQSYxES1cpdGzSlw+Xucq9ZUtm9VcWleC/lpMxmJ38XRjdhZrMZogTVC+dPfCFp4+mKtCk146
oEXDDBbxWJ+SUlrf6CuvqC4tcSQm1qg2Vqz25dMX+4LUvlyzxZjZJldL1pHmy1qtbFpdprnR3Vg/
udqn1KNRs1La3Hyxz5bpy3CX+DJWfRSNKU/3ZblLSn2ZbnQ2clznA7hPl2J1u5q/Yxi8+/jnZ1rq
AxZ9ivU7JqSYYqebUC41w9gwQswvMVGMZVOrh01Dxre+opryLjbN4WeenMwan6ZOlByRJRFeUbJe
lnQ2r3MniqUqrQv8LpsV7Vs/zZWdBe+rvyn4RbnLp6TWTWuYJbh+erO7pIT8VlXt85RAeOoDcy1t
yc1B/fo6TGK2cENFtS/HvdBndxdRBRhcYg1mV1arTQLNfPZiH6trCLTy5ZSWiHG5SpvrSmiAoi93
RfUhlt9xrKW3y7E3H2etRozDF1mMRUktba5unOFz1jkasT9nuKodiT5PDdxX466eXiNWyW31ZRzD
4xLVJ6qtMLezasvKYuZBKQZXtcah1IjVgsFVhg930SAUWLFcalasaNEgVzV3MFkNTwnUEOqMfpBR
UoqHiSJFNC0e5kisSaT0K0NyBMakS/EZuvRlhaFzTPScXxwa1RYDynCVTi/pMsAzOtUFBhjo7efH
qRG+CDwYLQxiOYfJIiUFJxc2DbpRTWIVo10+Vu6qdk9317ixhzzl1WJuwtfq+o6sdI+smFitrnZg
l1SdkaPyAsr5WCKKZUZTjD1YlumQy6rmh6r5zuyws4qHy2JXs8E9srJZdO4OdMhcOEGYtD51eP2m
grDeOJpliG7usno3XhhlzfWtHeunNbd4PM0LS+tmDRB9uIc3Nrsrqwc51LGOq17jWCUeFcZG8pFV
RdlZiD1FLW5+SUWLh19SObH6EF5rrkuqqv0arimuK6ppSUZZ9SG89jyqVSOswigyLpERPY1DxqDW
dxzyMLZeLdWqBjXf0MqZajNIG2cNrRqyWaVNA5uWbB7VJhIWKXoWXIxwW+pqFMuzumZWc12NOFws
EkuJX+7j7sHMp3EPbuEavdlndE8v8pncRcJeKOyFZNcLexA2Bo/kcI6ISc11bsQpbKhq5uC0FRXR
pau1o6OqOvF5x/GaRGy1ycDEal9wJmK/LmUE6g0VqIN5qG99Q70YB/NWi7ZBKcMbarBtZYeoMtwX
jB6CAz2gRpnaRmxHNGrA2mAB1fbrkfGtr/HVZIqHVs+uUbez1ceGuQdg2alPXap4UE5Nc5g7Tz2b
OArGlIsFBWNsrLKaLA5k8bAaclKQGSNvcKOooc4Fb2tZQyW2OsVSo4Ms0xEStanTVRgdgUImpqWk
mCxGX3BPdIhfoU09xZHUpQTV1NDg1dzFgQp4ttVnwohSu7gy0ADeQdFwMRb8XoyhiqqPiG4qWtk4
9wpEFjFotacgFPssKcPrEfypvQkWd4FsbBAxwhTo4yhZg8TMzfC7klLV2nGne2Vil5Sd5RYvB7Ex
meMQNjaraT7b4JuUmZ1lONtqUc3NzQbLzzcgfxksnSyMrlK8NRjzByuuVs1F+4Kj+QiIC6W4QIrz
pVgvxTop1kqxRorVUpwnxSopVkqxQorlUiyTYqkUS6RYLMUiKRZKsUCK+VLMk2KuFOdKMUeK2VLM
kmKmFDOkmC5FoxQNUkyTol6KOimmSjFFilopJksxSYqJUtRIUS3FBCnGS+GVokqKSinGSVEhRbkU
Y6UYI8VoKUZJMVKKEVIMl2KYFEOlKJOiVIoSKYqlKJJiiBQeKQqlGCzFOVIMkmKgFAOk6C9FgRT9
pOgrRR8pekuRL0WeFL2kyJUiR4qeUmRLkSVFphQ9pMiQIl2KNClSpUiRIlkKtxRJUiRK4ZLCKUWC
FPFSxEnhkCJWihgpoqWIkiJSiggp7FKESxEmhU0KqxShUoRIYZHCLIVJCqMUwVIYpAiSQi+FTgqt
FIoUGim4FCwgeIcU7VK0SXFKipNSnJDiRyn+IcUPUnwvxXdSfCvFN1J8LcVXUnwpxd+l+EKK41J8
LsVnUvxNir9K8akUn0jxsRR/keIjKT6U4s9SfCDFMSnel+I9Kd6V4k9SvCPF21L8UYq3pHhTijek
eF2K16R4VYpXpHhZipekeFGKF6R4XornpHhWimekeFqKp6R4UoonpHhciqNSPCbFo1I8IsURKR6W
4iEpHpTiASkOS3G/FIekaJXioBQHpNgvxT4p9krhl6JFCp8Ue6S4T4p7pdgtxS4p7pHibinukuJO
KXZKcYcUt0txmxR/kOJWKXZIcYsUN0txkxQ3SnGDFNdLsV2K66S4VoprpLhaim1SXCXFlVJcIcVW
KbZIcbkUm6W4TIpNUjRLcakUl0hxsRQbpdgghbz2cHnt4fLaw+W1h8trD5fXHi6vPVxee7i89nB5
7eHy2sPltYfLaw+X1x4urz1cXnu4vPZwee3hTVLI+w+X9x8u7z9c3n+4vP9wef/h8v7D5f2Hy/sP
l/cfLu8/XN5/uLz/cHn/4fL+w+X9h8v7D5f3Hy7vP1zef7i8/3B5/+Hy/sPl/YfL+w+X9x8u7z9c
3n+4vP9wef/h8v7D5f2Hy2sPl9ceLq89XN52uLztcHnb4fK2w+Vth8vbDpe3HS5vO1zednjxXiFw
a/YnDHbizuxPiABdQLnz/QkDQOspt45orT/BDFpDudVE5xGtIlrpjx8CWuGPLwYtJ1pGtJTKllBu
MVETGRf544tAC4kWEM2nKvOI5hKd648rBc0hmk00i2gm0Qx/XAloOuUaiRqIphHVE9URTSWaQu1q
KTeZaBLRRKIaomqiCUTjibxEVUSVROOIKojKicYSjSEaTTSKaCTRCL9jOGg40TC/YwRoKFGZ3zES
VOp3jAKVEBUTFVHZEGrnISqkdoOJziEaRDUHEg2g5v2JCoj6EfUl6kOd9SbKp17yiHoR5VJnOUQ9
qV02URZRJlEPogyidKI06jqVKIX6TCZyEyVR14lELmrnJEogiieKI3IQxfpjx4BiiKL9sWNBUUSR
ZIwgspMxnCiMyEZlVqJQMoYQWYjMVGYiMhIFU5mBKIhI748pB+n8MRUgLZFCRg3lOBFTiXcQtatV
eBvlThGdJDpBZT9S7h9EPxB9T/SdP7oK9K0/uhL0DeW+JvqK6Esq+zvlviA6TvQ5lX1G9Dcy/pXo
U6JPiD6mKn+h3EeU+5Byfyb6gOgYlb1P9B4Z3yX6E9E7RG9TlT9S7i2iN/1RE0Bv+KPGg14neo2M
rxK9QvQy0UtU5UWiF8j4PNFzRM8SPUNVniZ6ioxPEj1B9DjRUaLHqOajlHuE6AjRw1T2ENGDZHyA
6DDR/USHiFqp5kHKHSDaT7SPaK8/shDk90dOArUQ+Yj2EN1HdC/RbqJdRPf4IxGv+d3Uy11Ed1LZ
TqI7iG4nuo3oD0S3Eu0guoU6u5l6uYnoRiq7geh6ou1E11GDayl3DdHVRNuo7Crq5UqiK6hsK9EW
osuJNhNdRjU3Ua6Z6FKiS4guJtroj6gHbfBHTANdRHShP2IG6AKi8/0RXtB6fwSCMV/nj+gLWku0
hpqvpnbnEa3yRzSCVlLzFUTLiZYRLSVaQrSYum6i5ouIFvojGkALqLP5VHMe0Vyic4nmEM2mdrOI
ZtLIZlDz6USNVLOBaBpRPVEd0VSiKTTpWhrZZKJJNOmJ1HUNPaiaaAINdzw9yEu9VBFVEo0jqvDb
PaByv108YazfLrb3GL/9QtBovz0bNIqqjCQa4bfjXsCHU24Y0VAylvnta0GlfvvFoBK/fR2o2G9f
Dyryh5WBhhB5iAqJBvvD8H7n51BukN9WAxpINMBvE1ujP1GB3zYU1M9vqwb19dsmgvpQWW+ifL8t
C5RHNXv5bWJiuX6bOJs5RD2peTY9IYsokzrrQZRBnaUTpRGlEqX4bcJLyURu6jOJ+kykzlzUi5Mo
gdrFE8UROYhiiWL81lpQtN86BRTlt04FRRJFENmJwonCqIGNGljJGEoUQmQhMlNNE9U0kjGYyEAU
RKSnmjqqqSWjQqQh4kTM0xE6zSnQHtrgbAttdJ6CPgmcAH6E7R+w/QB8D3wHfAv7N8DXKPsK+S+B
vwNfAMdh/xz4DGV/Q/6vwKfAJ8DHITOdfwmZ5fwI+BD4M/ABbMfA7wPvAe8i/yfwO8DbwB+Btyzn
Ot+09HK+AX7dMtf5miXV+SrwCvTLlkznS8CLwAsofx625yzznM9CPwP9NPRTljnOJy2znU9YZjkf
t8x0HkXbx9Dfo8AjgKfjCD4fBh4CHjQvcj5gbnIeNi923m9e4jwEtAIHYT8A7EfZPpTthc0PtAA+
YI9ppfM+0yrnvabVzt2mNc5dprXOe4C7gbuAO4GdwB2mbOft4NuAP6DNreAdpnOdt0DfDH0TcCP0
DejrevS1HX1dB9u1wDXA1cA24CrgSrS7Av1tNY5xbjGOdV5unOncbLzDeZnxTucGJcV5kVLgvJAX
OC/wrveev2u9d513jXftrjVe0xpuWuNYM3LNeWt2rXlnjSdMb1ztXeU9b9cq70rvcu+KXcu992s2
shmaDZ5B3mW7lnq1S+1LlyxVvl3Kdy3lJUt57lKuYUutS11LFfMSb5N38a4mL2sqb1rf5GvSDvQ1
HWvSsCZubO04srfJkVAG9qxusljLFnkXeBfuWuCdP2Oedw4GOLtgpnfWrpneGQWN3um7Gr0NBdO8
9QV13qkFtd4pu2q9kwsmeiftmuitKaj2TkD98QVVXu+uKm9lQYV33K4K79iCMd4xsI8uGOkdtWuk
d0TBMO/wXcO8QwvKvKWYPIuzxrniFKsYwJg4jIQ5eFGuw+M45vjSoWUOn+OIQwkLjXXGajJCY3jx
2Bi+IGZdzJYYJTT6xWiNJzojqyw06sWo96P+HqUN90Rl9CxjkdZIV6QSIeYWObqqTOXCEuJefdS5
jo50p5aFRvDQCGeEptQZwZntmO1LmxLxsPVFqyY0lIeGdoRqPKGoHhriDNGIj44QxRPSq19ZqMVp
0YiPDosS6bHAInpMM5dXlYWanCaNt9A01qTxmAqLyzym7NwypnAX54xbQYpBjIJHOMtwrvdGch3H
+7ylqjIzc2SrgY0b6TOUT/LxS3wpleLTUzHRp7/Ex7wTJ1W3cH55TQvXFFf57OJfbNX8hs2bWVH8
SF98ZbVvR3zNSN96CI8QHRAsviWSFdVkTlm8dHFm5pIp+JiyeEmm+oscXypymcIofhcvQV78LFXz
LPNXE1UDTV2MtEQal/x6q//XE/93D+A/P7Uw8UcGQzo0F7FGzYXABcD5wHpgHbAWWAOsBs4DVgEr
gRXAcmAZsBRYAiwGFgELgQXAfGAeMBc4F5gDzAZmATOBGcB0oBFoAKYB9UAdMBWYAtQCk4FJwESg
BqgGJgDjAS9QBVQC44AKoBwYC4wBRgOjgJHACGA4MAwYCpQBpUAJUAwUAUMAD1AIDAbOAQYBA4EB
QH+gAOgH9AX6AL2BfCAP6AXkAjlATyAbyAIygR5ABpAOpAGpQAqQDLiBJCARcAFOIAGIB+IABxAL
xADRQBQQCUQAdiAcCANsgBUIBUIAC2AGTIARCAYMQBCgB3SAdkgHPhVAA3CAsUYOG28H2oBTwEng
BPAj8A/gB+B74DvgW+Ab4GvgK+BL4O/AF8Bx4HPgM+BvwF+BT4FPgI+BvwAfAR8CfwY+AI4B7wPv
Ae8CfwLeAd4G/gi8BbwJvAG8DrwGvAq8ArwMvAS8CLwAPA88BzwLPAM8DTwFPAk8ATwOHAUeAx4F
HgGOAA8DDwEPAg8Ah4H7gUNAK3AQOADsB/YBewE/0AL4gD3AfcC9wG5gF3APcDdwF3AnsBO4A7gd
uA34A3ArsAO4BbgZuAm4EbgBuB7YDlwHXAtcA1wNbAOuAq4ErgC2AluAy4HNwGXAJqAZuBS4BLgY
2AhsYI1D1nOcf47zz3H+Oc4/x/nnOP8c55/j/HOcf47zz3H+Oc4/x/nnOP8c55/j/HOcf47zz5sA
xACOGMARAzhiAEcM4IgBHDGAIwZwxACOGMARAzhiAEcM4IgBHDGAIwZwxACOGMARA7j4m1PEAI4Y
wBEDOGIARwzgiAEcMYAjBnDEAI4YwBEDOGIAx/nnOP8c55/j7HOcfY6zz3H2Oc4+x9nnOPscZ5/j
7HOc/X93HP4PTzX/7gH8h6foqVMYC7qZsfarzvh77HI2hy1m6/GzkW1mV7GH2TtsGrsQajvbwXay
u5mPPcKeZm/+U3+9/gupfaVuHjMrB5mehTPWcaLjePtOoFUX0sVyFXLhWtdpS4e144uzbF+0X9Vh
bW/VhzGj2taieQXWb3hbxwm8X5Hv6CvymouhQ9UWXwXd3L6n/c6zfFDBJrJJbDKrZXWsHvNvZLPY
bHjmXDaXzWPz1dx8lM3E5wzkxF/OI5ao+nStBWwh0MSWsKVsGX4WQi8O5ETZIjW/lC3Hzwq2kq1i
57HVbE3gc7lqWY2SVWp+BbCWrcPKnM8uUJVkslzILmIbsGoXs0vYpb+au7RTNbNN7DKs8+Vsyy/q
zWfktuLnCnYl9sM2djW7hl2HfXEDu/Es67Wq/Xp2M7sFe0aUXQ3LLaoSpQ+wJ9h+dh/bww6ovmyA
18gj0i8zVB+K/39hNWZ4YZcRk/+Wd3prLeYu5tYcmOkK2C/o0mJZwI+i5oWoSb3QOohe1pzlia2Y
A+nTM6Lc1er8T1u7euXXrNIfN3bxzA1qTqizrb+kr2E34QTeik/hVaH+AE3qFlV3td/cWXeHmr+N
3c7uwFrcqSrJZNkJfSe7C2f7HraL7cbPad1VEd/H7lVXzsdamJ/tZfuwkgfYQdaq2n+t7OfsewN2
f6flELufHcYOeYgdQaR5FD/S8iBsDwesR1Ub5R9ljyEvalHuCfYkItQz7Fn2HHuRPY7cC+rnU8i9
xF5hr7I3uQXqZfZXfLaxl3QfsRA2hDHd/fDzjWwKfnSISouVVxBFFBbE+rPRbAyb9ACz4HUfyQbw
/fsjSkoM2UEP4VWuYS5cBgyM82JPqFZjORgbW+g+2Ee/WbENb+XZ+wqDNuOaW9j2XtsLOW3vHQ/r
n3Oc57z7wXsfWL96wdY/J/+D1z7olcttiTYV9hBNUJBd707qqemTlto3Pz9vsKZP71R3UohGtfXu
22+wkp+XoFHs0jJYI/JceeXURGVsm16z1l04Pl+XEBtqt+h1mrjosOxBKdbKSSmDesYHKUF6RWcI
Su9XlDRybmnS20G2+IjI+DCDISw+MiLeFtT2ji7kxNe6kJPF2rkntyn6gZMLk5XrjAaNVq9vTYiO
6TEwcfj40HCr1hRutUUagsJs5vSSyW0bI+JEH3EREdRX22i4xd1xQrtWZ2dJLJXddIgld3y6z2zl
o9ytAZHa2vHlPhOESQojhCdWqBSr+LSon2b105POU0RxlomPTnanpnxrNpmjk+LdRguP1JqZ2WrW
7HE/7H7RrbjNbnNY/Lgwr87LCgsLw/r3z8mprbVF9bdB2vKtx/Ns+fB4Zi29CllmZkpkpF51eZqS
qIQo7qTU1L79OPk5KsitJGqXGrg1xelMCQ/WLmj7eI5iDHfHxaeEcgP3ay0xaQmuHrEh2vP4+/zR
cyIdIVolyBzMB7Y/HWwJ1upCHJFavynEoCiGUNPmtvPE/21X3/Gl1qxLwM6atjeODcyET/Za+Wjw
l3tDVf58r0XlL/aaVf50Lyae+RC+94WwaJ7DElkqz/KHV2oP8x6sD8vlPVuCx2ObvXZcgOd8oE7O
+sbRXrkp9hB9l62ijwhsHbGpIuwJGrHHxFS1Zo3OYPdMPW/42me3jK685uV1BXMmljkMOkVrMBlC
8sYuGjt+c2O/Pg1bJ41eXNE7NMioVw5ao8NC7Blpjqrbv7rp1lN7Jke4ejhCwmPD7HHhwWk5aaUb
H1l93oPrhqTmpOptCdgVuxnTbsG5CmNOttwTX5jIw6Mx83Arph1ux5zDwzDh8GjMNvwwvuEyFku+
iQ34RmWLyt8L38QGfBN7GN9Fg+Ebsz+kwtHKU1t0VazweGGnL14j6pVbK06ZOzEptY+td9/8RMw8
qDe84bYJR2i3jL/jy53tX0RlZETxlLs+valif+8F92zc07L6nqb+muvvOnnHOGea9oI054TbPt0+
e/9FI07ZBq9/RKzpbuz3cuz3HNa6r7AXd5sDi2oODNwcGLg5MHBzYODmVo3NExeVbBJ+MAk/mKyo
ZjKijkn4wdSqsXqimCeCj2aecPFhteF7hgflLEr8B0MUCD6Asqge45JbeZYn9IiZv2Tm5jNPQk7t
ouOFPAe+EJ4gf+RZAwzHpMigglDUKQMBJgI2KbXlBntidKzLbmjbCxUTnWQ3GOxJ0TGJdoNmtMHu
io2GijWYg3S6ILNBM7jtUam1b0vVdkKjlzrgP14N/0Ww8oOFUWOj9kQpLOBCFnAhC7iQBVzIAi5k
92PtjR1HDsITRus4dbqYZueCp/xkMrxajjs4IjEqputoT48wMCp9JvbrILbbY60bvHCwxpKbG5WT
Y+wZHR3b+hu3pljhhOReZrNRrLFRrLFRrLFRrLFRrLFRzIB1HPHEiOkk960wRUdZcqJ79dQ70yuc
XrmEhWEIY/mY22ty9RDQOpWt/zk5+fkiunWZsZuLiIbYxt1d1lS8WRDceL4Ic6pH9JkGuzMmKjHc
oGnPV0wR8faIBLtJ0z6UYz1jol3hQVmOWa7c5OhgvlzHN5pinakx80Id4ebTjpt5cluQMUjRIjDg
9bG9076zR7I5Nt1xaoKyM6FHjCk4PD5C/L82Hce1n+oScXdPY6s9sXbhGrtwjV2EAbsIA3bhGnur
Jt8T7GK5uOkqLCHg84SAzxMCoTIhECoTAj5POIxQaWQxPMMfWulu5ZktuvFnhoNauT34Wa9SNRp0
iY3aT0dc9d62K1/fVDJi23vbtry2uXR/2qTrFi68bmpG6sRrmxZdPyVdc81Np1qmTtj5/Y7tJ/ZM
HX/HN3fPf3DTmKrLDs9sOrJpdNWWB0Tk6zihPImdFMcy2IqWZH1gIvrARPSBzaMPbB59YCJ6sXmi
bPHCPfHCPfFWs4WPinehLF78cRGzpbRy41693oxpmvZGVJjFVglcNCjonT7i6lzP3AgIgNouAVB5
0rP83hVXBYcnxohj0SOWR/QYPXveqIz9AyfUZt1yw5iZZcnKVfU3zh/U3rNzhe9JTwqKKpy8csLY
Ob1D2n5MH9rA1BUeorsYK5zGBrLLPfHGxLB0MYt0MYt0scjpYpHTxSKnYyYeI3PF5catj1Pi8gLO
yQs4Jy+wynmBVc4LOCdP/B8AYYlGS3Yrz9gXVZmi7SeW2iKW+rXnhRP6n17voyRg65WrC3ggTd/1
1agRr8agBB0/awdgFkaz3l6z5KLBva5pkDth06tbhoVnDO4xfP6wdLuhfffZm6IpymnTJxZOHJSQ
NX7nDzuu/1HsjK9vqth20cLsQcVJoeFuzbH5D2waU7n5/llND1+GbfIgo32iNWGf9GUl7ApPgrWn
rZ8BU+0nvNZPXft+wov9hNv6Yf4HMzzIZhTahK+gbAGf2QIbyhbYULaAz2ziT7XielpbueHAQg/3
eKLOwb7Zn1gRFQgyYuvUHu90XJ6MNarjZGBJU3oqP9lIkVEJCrlQiQqPjOS9U9NSU+WL1aS3JyfE
JtpN2uUR2YOrBi6WWwwv2vBeQ2JHLh6T5i6a3N/VOzvdviTE0N5WUh5TmH/FXSUNRU4EGYNWG2w1
8169JxS62/7YufXuS3PqFEvB+AXFQ2aOHWAPyRw0plf7h8nxyoZRs6OC9O2jEgeWI44P7TiuNGAv
DmefHGJDcAUNxaVySMBFQwKuU9mssuqqIa2aLE9mnifczkfleWy4eeYl55kd0aKtQwRwh9UqPtDE
IZbDcb+ml4jiex3qu+nI3pgA24kPhIoXt7nnYZ7G+jEjT/WYbK5+vJ/HZOajbOLfCY1C9bP1s0UO
auXm/UMcuozKSOztQPTCEhy3iQttZmat9bhVHPDTb/IwKjgrrGnl3qavEj31v3AN1CsNxctvrR2y
YMLAKJMW7g7JL180oqC2ODlv3Oz5s8blD5x9RVXmhNGDwvVajaI3BZlySmoH9C3vHZtXOWf+nMp8
fu6kyxvyIl1J0SlOfKcISkp3J/Qrz+83ZmCv/MFVi8ZWrBufHRrjDDfZosPDcDuMc8fH5xal9B0z
KC//nMpFWKNQRMg3sfOT2PSD0R64N9omvLZPvPF/c7gUL1Jbx5H9Yufrw1p5+t74QETMw5XgK9U5
j2daj0oPdbnpJMpIIO6EypvaYIuhfZu8J0BZDDodPpSLDLjXa4+Gx9kMJ2/u3IjTDLa48HD6AiRu
Dkk4x7Nwn0lm8z3xyeIIpyfzWMGpsTw9iqdaeFYMz4rmMa2B7agKccCjpUUIT5gwxUTHRKemOMdF
68LofhPWv9AWxmnJxXKz2lpeW1uLrzUp6gtfm8bxNaZvl9d8Hr7mBGkOakNi0uIjE6Nt5iClvcbA
w9KT4hLDgrV8MeezFQMOqTPZohgSxFcWrtXh6q/1q19qDBbjyYe1hcIuvtSIOeZixb5X77y5nviM
HJ7Rk6dG89QonhbJ0xnPGOc22eLH2U5/FSuE12vVdPpLF+ed37m6DLlzxFz5yKILy0hyJUeYtO3H
2t/VmSOSExJTQ3UWXt++xxxkxUZLjTTqeSS364zhSfHONJvW3O4bHBkbqlMMpmCN0tb2P+x9eXhb
xbn3zDnaF+tIsmTLsuUjb/IqObbjxE5iK8Rx4jghC2RxwAbFlhMVb0hygiGBsjcl/Zq2LCXlu5fL
bUvpQ1vSEhKgLUmh8YV+gdBCWApcurKUtNByCVyIz/ebOUeOstBy73P/+Z7Pnug9c+bMmXl/77zz
zsw7E8kMtHpHgVe4QGj3+h1YoqFxC+nvTXYjR3Py58z2Xgwr0S4+RRpJlDwQlR3nFZ8XOU+0mvOa
bNCxJtblm1hHb5JY6zQdoCeiOSQUchBqI8w+k1bNgrQydbRrV6t65S3aekAwRXOdeT8nTVKTMO9g
EyVNtKkpvLD6APVHHUdLaEmJrujt8LIFr9hW6EiETVm4PXby6Xtfb2YC80RNX29LRB3ZG2CY+zDn
YwKtqJg9O2tQa5ytjWVaio4Pc0a103sbG5rniO1Sob+gOGfeV1YvSa2ua0t/J7HdO+v8lgWxrlk2
k82sM/rPWzfYFPvChRXf/FLHwHnFPasWji7It9kw47BtbO8s7xxcuHxsWXln06rZ/qLSIpPkc/iK
CkqL3LVrr77wiby69qrOC87rgHTvhHSf119OqskCcuM+TNEtwWat+zZr3blZkxe75/JqPkA/jPo9
NWymUCOzNTGTfw0bAWskvlQWLFEz8ViaZwd1+voDVP9QxTJ/p7S8BdG9+hXMarIhLa8lMxmqOSWz
3szUL+Q5e7mjrv8zk0Gj0+vl06PnG/t399Z0dXaGTC6/J7fQZTC65Xyf7DJVdi9dWrnplvWV3/c0
rYvKbdHFoY7ti9o2zPHRN8YfvaHTWdFaNQJzodPBXOjn8hEN5OQfquaWSudf/8D44usGFriqz2uY
uvOC9fP7r0L/2giJyeKTWODv3FvIRxJ1NfS6tgp680G2XAhptjGk2caQNksKacLE9W32QuiAYI3a
Izk0x/dGcdRiX1qMtaLwoHuZ+KdZzM6a7Utn1R6ghr3mFcyTUHOcExrRZspPqFPIs90JBnUYMWQ7
E0RZ0Bt987s3RGK3x2cvvPzOnprVHbPzzQbBZXeE5q9t3XZNMNo7v2Vde42NLRrucfqcdl95kSt6
1Y/Gb3zsynlSQUl+jjvfFSoOVgb3f3/99RtqympKTe4i1k8vhVzu0g+TCtJCbokWt8+jVn8L650t
bEXVwkblFqYdLUxZWh6l7BcqIqrUIpqwIpqwIlqPjWjCijCFsriDndaWkF+XU80O4eUvQ1fX/Shn
hX45G0i4OrWf4Vfg+jS97MrugpgWTWuVWFGRPbGcI95ldBbmMvfZkjsv6t+1vrJh01cuWXl91Jhb
zHTK/O1FOzraoUHQqIXBBdHOkC+jQNtWrFtx/d5N6UdvWLJ4kWA12tkwZDeeXAzd2bQ92nFdHLq0
aBaTVi+kdSesWg1pIt+PVkea25tHm0U3601umfld3MFaNoepZdKqZWKs5fYNuvDRvo6ab9YIzDG1
j/W2Jp2mfDpNx/i9lV9VA6dj8gsGayc/r9utEw7q6FEd1ekKI69ULMt/+9KcsRwhx/x2IVewXs22
XZ7MGLWGV2tUZUOy5qoxlAaz1MpzuvIJnlAzF6hRvDPkO/nDQOfY6uhAV8RmtBpEQTRam9ddHh29
N9k6//K7+z9326V13xYnti24uK1EEIRQsPuKdWFPgceY43PZ3Q6b1ZfvbrvywJXph69d3JH6xgb3
dbeGl8fnsHGuXPlP4Sb9FWQ+GfihV2IdkHc8v2a1/Blr5dfMmV9TJj/77wb11eUHlKNRF/PalFuO
Ny8pqDhev1ReLi3ls+0GtiateaLxPbWPNT5xakXKVcWj4jZkz7Zh5jPWnctBJ9yEkdpg9ASq/OVN
cs6TGPX0LseTJpgmLN1N10gSMzXXlC4dXlZ6XpkNI7jDnZejN1vN+Y2rWzcZnQXuMvmTP7HBnjn7
RI9c5i5wGnv7bl5XZXfY3H727Wyzp74m7hT/jbSR88kl5GjU46pbwnrZEhMgL5ElN12+pLH9gPIh
E0G71r9wff0h9qjduBLRqN3hostX+nWOerHRaGTaI3F5HYzaEalrNPr9xsY6HZNxtIkJeQOrYoMs
4bUN1eVRK67ljnqjOHfZy7YL3vR4Lp0rvjV/abV83ktzl130krySqENmOx8xjx9TTX9N4xEm3DxM
l9iEyYlE6UgN/tVkCJM6ZOz1qkNBBVaGGCDztBVNRufmYHhtauZU7dlY9NCmiunhtE1wY9ETyhG1
O3Gn23FtaWFD7+fPn9Pvd+UtbP7TorE14abLvn358J2baqXgLHlWpKG8uKzp4muXVy0pppLTOTUV
761fEsmLXzRraSTvgktWvyVX5Ztv2Nodb/OL6dLisvWR86+4oLbI6woHSsOCRQgu6JnXNrZ2Vnm0
pynYNrfR51teu+DSivLe81ZceWGd2RSceu/izfLcrsqeweI5S0/2tbYLJl9dVaVn4aKi+jam33di
Hnc3RuYGMvFgexOtdmv6684otltTbLem8W42LOcFVCcld1dyTyU3G1b2zKL6JwPVPiw0DfvrlpV1
+pZz88kXmDSiuefUwbjldCcdH02M53BBqpNDj3i3yaWOufnhrvq27R245S6qzFC8ZHfXxquWB30Z
fRYcK/o6yjasPXlLJiV7/O3uWjC4M8Ys5Y3Kf9LV+gjxkCDZtb+9dGXpaKno1eZyXk0G/N7Nr1x5
vZqmezWheR8VLieFxKNKyqO95dGeejIi9UBMD1mKo3iTHbx/0Cd1cfkcO16jWUNtZDm3B9PNhl2m
jNBC2namANy181pr2GdaBOINRhWwkda3Vle14JNp+e1o+SZyW9TW3kyrZtFZURddgQnBUc7mLM3g
z2KTCBu/coM/61EhhJWaTUPz6d5tKEOBt66OMKCqUnhLrPrKrsJOZ0YhuJsG0wvMZ7kVbHg9g3sa
eIieQx20PRoYRyOlXq+43eQuKfCX5jsMUzecKRF6ocnlK8n3lXjMdsfUI3TEbuVOBSwEzPSvU/az
FeOTX9KtFrtZxDBituVLU49MlTs9msxoG2TmIVHuqR7lnupze6YzrU3YFxNYpE6OWGvfc3umz2pL
39msaVzoj2JUX0XejvpdklXbNamQmAshlM/o2BramdVzp7s001q3prVubXLIe3Qg4GW+1ECD6pnm
PmrunuYd24LRbP8q5gdZ1RbSis2aY757xhyUCyT0KP0QZkWihh92L8N00xC1L1zW1lk3t6tuuS+r
/bNdsy2ax8nZkvHhM/vAjxz/PSPxaVbDoy0pNWXRH1WNh9uUW9sRbkktZoNkXtBt9NYuCrekp22J
wVWY5y2SjMu/3DW3p6NeqlvdvaRs/dau4lNWpbTlDKtydop4A4ZiUTRbTdvWriyILKyc1VHthrlZ
nrG6aMEGcmvUobYgI5oBPrOVNLt7Zmuy5VHAKkkZO8w3kLL2juiH+zVTzAxx1FK3rNpX1pURPRsn
p21xxk+sSfszGGTPPzLI00K8Y8U/MMinCQoCupTZY7b+eQ0SYnsE34kWtlfRShetcjLfSYWNVpho
hZFWi7RKoOfYF3j9nPsCbHoaiFioJWvDQT59w+ERwcK8ePsdZMUYmsnH/q+NY1kp1kragpKtiTSR
Raa3EXozf/9oP0F8rTX1veTot0aaW1L3p3Cd831/2+dWdiU6gv72z61c+rkOmf5h5OGbus+7+sEk
rstw3d513aaWpkuuW7HsulhLU991bDU9dav4PGTDVtOfZ6vpYLNF0xKLpiWWjPWxaOgtfNj2qAtp
vqTmvkx1TX3OlXSXtPJTV9LnWkifQ0c+fSH91b7KjoXRsixlyfX4Xcaq5StW1236IltIN/KFdGeo
48pFbT1zCuhbW398/RKppKl0qi1jC3VvQWdE5ueZqG6r8iy/4Qfji68dmO+uWjRras8FG+YPbNes
pXAv9+z0Pzg2m1Y4NBE5NMk4MqJyaDJ0MFG5tA1XmDzCZEYKIMHyqLlmWYXDI3d5lhPNePHhq2Z6
LpM9gT9Xt+EiMQj3CgazyZRXVObx1c9uLT2z05QvbG0psgfLimw6kYqbvAGn2Ww25YaXzzn5wNnd
5vrmjpBDNFks5hw/Q7xaOS48DcRd5OmoLdLd3r2y+5ruH3Trs5zeH2jObt5jFjL3gvsMZzh3gtNX
osWq55v7vJlx0RzfbInDepD/EfoB3760sEHeFuUDP24rUF677Qc2wRZ+dY7lT85VzkudY05RdXD/
mnm3l3nfVFVr2rWtObZ72S51lmP71Fzov+rYFp5u7Lvu/Pr1i+u9Fh1zXNe0r5tb3dHgD0VXrV0d
DVWtuWpN2dLWKo9RxFhvMZhLmrsi1dEqT2V0zdoLoiGas3gI7Z3nyy0rdhdIRr/sd5U2l1c0VRaX
1LStmz871lVrc3kkm8MrOX2S0evzukvrC0OzK+WS6vkXsrYIKn8RhnXfI63k4geriLO0TpN5ndYW
dVpb1GlWrE7TyjqmhLY8e93x0qVF9uN5S2cdoLq9RtUIHWFq16h5H448obpmdOdeIJ6+jPRmltPC
sEmSq8J5nQPRoqsdLubd3pGZdrzBfH8uxxtzluSVFeaa9Ga97qKiEinHbCjvTp0v5KgrxGNG5NKZ
bYjwNeSUpfcSs8Wsz8lnuG9lfhrxxxjhvhotxrhmDTENCjENCjFPeIjPK0ISn0DQjx5Se1qxJpVi
TSq4fsj7JoswsRRnOmuxpqOYQH8UNbvrukJWva8L0wz9KWcN65+ZmcW0Sp3TWXNqYsktdfOcU26b
u4yuIk9ekdOw4nY+kBlz1YV1XmRpfdtVi425xei5LvP0+LZt7fnzN+/cJJRkeufJ91desqh8w1ph
PJOi7RGIV0E+teR3D5NSBbaZTduKTYyWF9OAGglQr4bTo11zT03m+NU1vbenvBudwzYGMUY6aUii
lXpaUomEBSW0rIQGWbQ9SMuCVOapMi2TachBtwZpkDkpzE7P0qCMXhtkOw9mqGKQeYjYHWuJICvf
hheDlV1Ba0GXVTWA/ExJDTtL1cvHwRr1H/f0q3Jn+xI1/HTb9HGEUwNknjtvjls71nYVFURh6ojO
XlAZCFT6cnRTT+v01OQuzisqdZt1UzrxY8HiDvrzAk6j+M86s8Vm/OQ+tiWhM+VYxPU2l1nEEkcA
MZ8ssNmEP5ptJlEwWZm0Z2PGfAOkvZi89jBZAvO0ANDmMudF1Vw6h13Lw7QiSCtkWlFMKwK0ooiG
CmmljlaJtHUenddK59XR+ex7mj10haQt/9g1aoG6SjJKkBxaMrtGbWwgYcmOhV08HxNmu7RSGpWu
kXRS1OVdKjV2lXe17q6ltexZLbOaktu7dHPttlphMVLzlpuZkJ9nkux9or39CCSpyvvUxo+69aP+
qYI2TMtZDBnFjMgzbovTRJ4V1d+g00+dEO15lYHiap9N/Ikg/EC0F1QFikO4m/pIr8NcOa+wxGUS
XxKEScHsgtoXu0zCCwI9JpjdwYL8ItYsxlzHqUYRvmQ2n0ydaiJHrtFsRQth3XWywGxGC9lheNmB
oPzMnWCysPaqQu/oRntFyE0Pk1kQjJP5Z5ndCDOLMS9M86GPD7H9mHyap9kGbybJS81MW6vZKoy9
M5/QuaW02UqtMpsss1axWmfVV3WxPaou5/SEWN1Xi0zvqTHlVfW3ptybmzkoKJ5jz8rtPrVntcjk
DhUHSj1W3Ysv6KyeksKicic10/ypEybqDslFpbkW3ZGjOouz2F9U7hLMUx/V5rhteqw1jTQ+9Q1c
RL3NnUP303tz3HadaLAYp/bSlQZ2vsaa65jqY9YDM8DtkE8ZWfMw8QPrbNbz/bTKT/P5UjCfVuQ0
5wghMy1gQ3JrAfXNZYLz0eIun8XdZenWrSTd2hKsHV23Ru20rPMGRRXqHHdFBTSnaXor0c0dX95c
o9B4hWFWQ4HsFAzbzZI49ZhJKgsESnLNekrFDw3OErmwzGmY2ic59bbcHNqic1nEiz35OXrR5LCf
DAvH3FY9xgkXEahF+YC+ou/DirqK5OzTl/tXSJ1g69Wns07niBXTno8zjr7+xMiOnha6jE5q8pQW
+ks9phyzr7K4uAoalV9VXFzpM9PxzHxRfMTmsukNNqft45Zgjd9q9dcEg3U+q9VXh1n1o8oJ+iXx
Nr7i8O8luQeEq/ZbAqVYLzmWkvYj7UfYkNtw9qEh55lMfYlxIFcyDiplxsGZ96Is17Laa+WSOnat
O1kZVBPADkxXQR3rA3eAnxHyOrGSvL1sE/zgQ2yz2yxCWcFKzSE26Gc5gkYibfPD7DO8JBJejA/z
296unNC9S15jZZBSUv0YyRe2kwCxCVcRF1ZZ2/cbgh6z38HKbGw80tCA0ZKF04vWf0qcJiLzW8Ps
Qx8Ps9g82MgnMmlDnZFwxzk+QEan3hAt+p+izU17JT2JRGbV56mGKnP21vgdnT23yOMLunQGoVdn
dwc8mJjo9O/ZHSad0e62G66yO8wwHbl2lLeYPiiEhQXEQXIeJEbrcR1hB6A0v25QZZdt7Athl3Oq
z4U/eo/JDmX9KBQorqgIGJwFhCofTX1NR5R8YieOfcRoeUvH/MlnF+PVEcn5yQKny+UUH5ecU8dK
5UBpSYkMPm6cupf+TX8LJF0S9YjMUIlsiizyozuip9h6I2mPQIvUQxoGzMlcedN74WGRe5lV/PQv
l/RecpGe5hT5XAVum9i8Zm5hccuaRmqWCr15hZKg3/TkVM+xF6Y2/sLmtOoFg0k/+OyLr15++Ssv
/XKzzmCA0ZCYDl0Jjt4AR0HS+DBxqTMIlzYDZdd9jDMXP6Bi5WsclcOahulzJMaMtWt2zW4SQlpP
zPO66BuFc1c3izZ3gaugyE71F/f19ekEqTDPU+g0CZvHBd/lr7747KDeZBD0VqftKXrvC8fovU+a
JQu4M+iOTK0EfwuEj8XHdcNkDqmGsYe6E+KmI1FbYUND8K851e/rvV7oR2NEOv7c8QYwph6Z57pi
UCf56vwtswBQFwTcXhnFnwl1nRfX13c2V5WXlFX7SyIBe4mc63PoKzoumRtZ0lxdFiyrLgxGAjmY
9xRIBqqzdwwuLvWU1oYri11F9W2lLqvOaDP6FyeWlHlKalhqQSRaIVnZHAMW4xZxUNijH8/YLn/F
EmkJbNeRbCMhZlwBZ6R4PcL1BinP5cp3GPIsucG8/GCumU7dfFpafYV4U8Z40WcysalZp6dJEnhZ
ivn2JD9TWUPejvrOcJaUZ5wldWyWUe4QVlxaR7PcIMz3l8vm5rnscGFuPos9KsAMEVldlsia0sia
z1DWJui4vsnsEuaS7Nt1o2YLO64ZJSI/0W9mu6yWlRaB8BkmP/yKugk/78QiFmKpq/WzL0RxXMDO
MmaOap4634IRSfpNb7aPqoaPVp/ucdFleVx04mRk+IFrr7x3sKZ+6IHPX4XrAzn+mvkr6td+boE3
sDC+dO7aBbDMwhdv+2BvbP19J+6+9QS/3h/bs3XtHN+qXT8e+sovPt9atqgveSOkzE69/EqfS6pJ
mHwcbWWTxjoaqqVlIVpWQcsLaYWflhbQMh8tz6flebTCSys8tCKXVki0wkHL9LRMR2v8tJ5JwMWa
oZ7WefMR8cqStq+g7ie8vp/tNxSGw5g8fhItQg6JNZfEmktiSymJNZfEjIzEzr+HiE557kfIpoOo
M9uzUQvbn9XVR0L+8AFqjVp0NUFJsgTXWNRzRBFXS+PxhgZt1lOjrSjZgeIjNeqWf28NyZphZjm6
TtuUzByfyphvj5MND6U0KP4q1/XVzCnik2/bJDtslcVIf6l3B2oDwVkB6atOz9S/CFMX0XvpWLBi
6t3MMopKBimQ7w748uyii43dWKGaPzlcKrx1spVZtjj0/XZ9Dmkjh6L20BwaauZOQZFG+Wk7SDZK
52hr6jn8v5mw45PsiFglRF/JDqOybYnKnJUNow3XNIgN5z5m+4jQSAhK0bR2H9/JwNrr4H6+N+bO
b2Zn7m21re/L7PyOvnZ1PgQ9fWYv0ntcOs6c2VQ6pjmJnuh97jkeVYXLpKspseEMtwbzvJZm/V8F
ZuyC2kaYeHvn5/cOzR+6sNlh0GPNYzVaqpckli4aWx0Ord6+bsGGisL84iJhgclh0ee6popKu+pH
vz3aQu/ecs9oq9OXn2NzFricfqfJV1Qgd2xe1nZJe7GtoFxwBGWzq9BdVjl1m16YHfsiLMC/qIFG
/k64/1QQfJ8xPMyCqPvMYW920FV9SrhHd49+gf5NNRgeORWMwb8bvpYVPp4JpwfTdz8tmBeZnzk7
WAbVYDWeI3zxfzbYtp0jfMyCPf33Qo76t/pUcDQ4Hs8O0upPCW+y4IypwRU6R/jX/05wN54zvJ37
s0zwrPHsnwkz4f/78MmnBW+Hd9C79zOFl7LCJ6eHvCItDOY99NlDvgfhov9Xgi9HC78q+MJMmAkz
YSbMhJkwE2bCTJgJM2EmzISZMBNmwkyYCTNhJsyEmfDfCfzbdSkhxj5C6VwDISa6iuiIS3kPtFt5
C7SH0wHlUtCUci/R0T3K/wE9qLwMOqm8QHTiBmIDTeItF976M2gPpwPEQvKJTvkt6ADKyUcJb4JO
KL8h+eIG5SjpxtO3QAeUJ0FTyhugE8pB0k0PK++TbuT5LVmPPAnQAeUEaEr5AHRCeZWsp4LyHKik
PA9aoLwGGgA/62kl+FlPd/D4buV10D08ZZJRccPUx6BDyq2gSeVx0oOSnwVltfeQCeTpgRTmgR4m
xaRHHCJfAL2GBMhGSObPoN3KO6A9nPYpfwAd4PGU8nuyETy8ArpDOQZ6UPkj6CHl30EnGYWsLKQP
iN4DHVD+CpridEL5G+lD/rdADyl/AZ0EP33g8ATkqIP8B1D7MdBu5TBoD6d9kMYAQiEZgDTYN6ZL
Cvve8wKFfeN6QGHfeb5KYd+2Pq6w73TfyukOnr6Tx3dxulth38S+j8cPKuy76A8p7JvqDyvs++kn
lX8lA+J65UrQDcps0CHlNtAkakyBt7tBmWRS4O0PoD2c9qEFUwhmkgJv/wtUUu4ELVDuAw0oe0BX
KXeBjitPg27ldAfqTYE3Ft/F6W7wkAJvLD6Jdk+Bk/2gG5RG0CHldtCk8g20nEuZBO3mtIfTPrTL
BGp8DjSgvAS6CvKcQC0vg+6BHk6gZBY/CA2cAOpnQCehURMo8wdUoJXK+6B7lOOgB5XXQA8pfwU9
zFMmlZepA3n+Arpb+QB0j3IC9CCPH+L0sPIC6CTiEuTwF9AdoAG89WfQPcp/gLL8AZ4/gPy/AZ1U
/kYrkf9FUEn5FWiB8gvQgHIEtFJ5B3SV8gToDuV50N3KH0APEjvoIWIAnSQWWgkpXQGaVJ4EhQ7T
VSjzZVAJuFahzOOgAfCzCjrvBt0BdKuYZOgqaH4X3cglsJFLYCOXwEYugY1cAhu5BIZQ5qugknIU
tED5N9CA8lPQHcqjoLuRcwglfAC6T/kjHQI/P6LjvORxXvI4L3mclzzOSx7nJW/lebbyPFt5nq08
z1aeZyvPswPpJ0APKR+CHobEdiD9P+hO3i47ebvs5O2yk8t5J5fzTt4uO3m77AL/x0Al5begBcrv
QQOQ5y5ImMV3KP8OuhsYd0HCbtBDxArKJLwLEm4ATaItdqPG46B7lLdAD0KGu3ldu1HX26CTyq/p
HtT1BqjEaQFy7kFdb4PuQJvuwbu/o3tQ2iF6EDl/C8pyHkTOd0ADnFai9oOct4N46zjobqA7CCtn
AT1IbKCHOJ1kFBxuAE0qz9JDKPMtUAnlHEKZfwYNcFoJnTmEMlmclXkIZbL4Hlj5Q7zMQyjTBMrK
PIQyIXGU+Tw9jDJ/DSopvwRFXwMNKE+B7oDWHUY574PuQfmH0frv0MN462d0Em/9BlSCPkzirTdB
A0A6CU4soKt4+g6ezvRnkqOb5JxMck4mufwnwQl6LMr8FWyrjthAXcrLoN3K26A9nA4om0FTSkLc
gDZ6EXQV8YLuUZ4DPaj8CPSQ8mPQSRZHaV+G9uuUh0Wm278WmW4zGuB0lfKqyHSb0d3KS2KS9WXQ
g5weRu1JlPOOeDVqsfAxtk4oIezcN/sb4FTkI28Ov2NxgeSIOi0uknrRpcV1WXn0GDXP0+KGrHQj
+U9xoxY3kWrxqBY3E1l3oRa3CHdP57eSdbq0FreRat1TWtwufF33vhbPIUPGXWxuwP8ajB9qcUqM
pmotLhCj+UotLpJ887VaXJeVR09s5ju1uCEr3Uh2mL+lxU3EY35di5uJZCnR4ha6ajq/ldRYGrS4
jXgsvVrcTpdbklo8hzRbfwpOqM6syVmNq3JW46qc1bgqZzWuy8qjylmNG7LSVTmrcVXOalyVsxpX
5azGVTmrcVXOalyVsxpX5XwfkUkDqUeYi9gK/g38STKK0XOUDJI00hbxXy5Qf78ghpQEYiMkjCcL
yRCCTNYgbTPZgmcpfhfHNY7cW0EHkHMR3htCnk1ISyBHgueL4TOMsgZ43hHcpZA2wp+p7yfAgYxP
DPkSKGECd9sQS6Mumf9ewibEh5BX5jyP4+0B/nsMm3kpo1qpaeQY1upkOWRgHOV1xvnvLjAsXRzr
IFJi/PcAkhyFzK8xjpLVq+Lox5NaXvIwTxniJcYgIzU9U8swyhniEhvTuBxByjCvVS2T4UxnccBq
HONYMr8XoUpb5Z3VNAoJyPyXEjZzKST4byOw35xI8zuGOD3dHqrM1FpkzvuIhmuUy3YTz3mK42xE
TGpX8PdU1JfhPsz1Ibs1Q7y0YV7CBJfDuNby2fJmLabij3P+GX61XZJcG9hVrZG1tYwyxqbRqDxu
1vKkcHelVnoaKNQW2jrdSjGuIzGkDp+GK6PN/eAkxuvv1+oPc43dzNuKPTm7D7Sehbp1utfMJus0
LUpo+jYbJTbj6bm1Pq7pr4ompvG/mT9V+YlrEmM8DnDNZVxdxtss8865nw7+l3rwKW1R22Yt7hKc
B1b/BVzb06e1Y0TjYDQLQb/W79IcZZzr8nKk9JNK3sZVyDPAy1/CuVLfTSOMQYoRhG08hHkfP53z
MC99GHnS0C3G/2aOYAwlTCCVteAgx8J6zumlZtIH+a+2JLn+Zsrr4TyrWjvBtS3FOUzzfpXidkB9
W+YYWJ+Mc41K8DpUCW3i72aktxjyWw6LqL6bzHqi9ucBLpNTfXSb9msnWz6lXvWe5e2HFo1zGQ5M
6/wAfz7GNXYiS8/HONIRTdPVsuKcsp57Jm72XLUQlXirimvnMHDFp/vs2VyNnFXyZ5fRqdIzVlrW
7KyqPf2n2buzsZ/S19P5mpclAYZExaJa/YzWJ6dHkAFuQ0e4LY19KlJVzrHTZBrXtP/MPsCkyjRv
nL85wO0RQxOfLoflHOI27e+10P9UvzjVJyKcG9YH1JEozNtqjFxxn9xQXz9XXpHoT46mRgfT8qLR
5NhoMpZOjI6E5YVDQ/KaxOYt6ZS8Jp6KJ7fGB8KLYkOJTcmEnEjJMXl4dCCeHJFTsZGUjOeJQXkw
NpwYmpC3JdJb5NT4pvRQXE6Ojo8MJEY2p+RRZE3Hh/HmyIDcP5ociSdTYbkrLQ/GY+nxZDwlJ+Ox
ITmRRh39qVo5NRwDB/2xMcTZK8PjQ+nEGIocGR+OJ5EzFU/zAlLyWHIUfDO2UfrQ0Og2eQsYlxPD
Y7H+tJwYkdMMBzjDK/JQYgR1jQ7KmxKbecFqRen4FWm8nLgsHpY1mKGUPBwbmZD7xwFe5Tu9BfXH
t8nJGLAkE4CNF2PD8vgYqwYlbkZKKnElsqdHAWgrgxSTt8WSw2pdTMz9W2JJMBZPhtfEN48PxZLT
LdCaqbqVNc3sdRARQMmzw80NWaKPQ76oJobyNycYH3EwlowNxIdjycvkUfYk63bw3A3MxQI0a0cS
abx/QTqWVjFGUMAor6AfbZdOJuKp8PLx/spYqkoeiMtLkqN4mk6PtUYi27ZtCw9nCg/3jw5H0hNj
o5uTsbEtE5H+9ODoSDqlZWXxwRgAXMby9YyOQ7QT8ngqDiYAiT2WY2jJeHI4kWYMbZrg7C1eu3wh
nib5Ddp5YFxt0W1bEv1bst7FNTHSPzQ+wGQxKg8kUmNDqIDJfCyZQIZ+5IqPpMNypu7REShEZaJK
jg9vYi+dKmokk/mcHPHsTKUh/hTE06/q3XTtXK5aWfM4A5UJ1ALVZ6JPsg4yMLptZGg0ll0peI6p
nELw0y0wOp4eG09D7FsT/XGWZ0t8aOwMQJ+lLXhLRAbigzF0onAsNXbF9HqQ/d/Wm878BTZtrSVi
bWEhbmJUFOLA2kVdRRGskQn5veq7/Tt/OvE9m40ij2D7rPntdp7/3c+a3+Fg+cXnPmt+SWL5dQc+
a36nk+XX3/VZ87vdyI8rYatKHc/PVtWNnLqIneSTAqwOQrDJTaQDM4Vucj5ZTy7CqLyFbMSI0Ueu
h7XeDfv8v2HFv0sFsp86yM+oRJ6hBeRlGiBvQPp/xcpeoRupjfZSHx2iFXSUNtJxGqVbaTfdQdfR
nTRGd9ERuptO0D30BrqPeYToN+gh+m16mO6nk/Rn4jL6jLieviJuoG+IPfS4OET/JiYFUbxSMItX
Cw7xGiEg3ibUiXcITeI7wnzxXaFLfE9Yh/bpPx2jsPkfYFwHjP3AOAaMVwPjLcD4dWD8FjD+EBgf
A8angPFFYPwdML4HjJ/QVdQCjHnAWA6MDcAYBcbzgbEHGAeAcRQYtwPZzcD4VWD8Z2D8LjDuA8bD
wPgsML4GjO8A4wlgPCkOAV9ScAOjDxiLgTECjO3A2AmM5wPjRcC4BZjGT8eoeyULYx4wlgNjIzAu
BEb2nQmDwJgGxuuA8RvAeB8w7gfGnwPjK8D4NjAyH6yeFlAnDVCZVtJaYJwHjMuAsQcYNwPRVmC8
EfTrwPhNYHwAGB8Dxl8A4wtA9gdgfA8YT9LDgkQnhUJxmVAjrhdaxQ3A0COsAMYLgXEQGIeAMQmM
NwDj7cD4T8B4LzDuA8bHgfHZ0zEav5eF0QeMlcA4Bxg7gXEtMI4A483AeDsw7gXGg8D4DDC+Bown
qEAN1EFdwFgCjGFgbAPGZcC4ESEBjBPAeDMw3gGM9wLjI8xjCoy/BEbmrTwOjB/RfYKRHhTc9JBQ
DIwNwNgGjCuAsRcYE8A4BowTwHgLMH4FGO8Axu8C40+A8efA+DQwvgqM7wDjx6djtHwnC6MfGGuA
cR4wrgPGQWC8FhjvAsb7gfFJYHwJGN8Cxo/IBM0FxggwzgfGFcC4ERgvA8YrgHEn7u4Exu8C48PA
+BQw/hoY3wXGk3SnYKG7hAK6WwjRPUITMC4CxlXA2AuMSWC8Bhi/DIx3A+P3gPFBYPwJMB4FxmPA
+AowviveJurEO0Sb+I7oEd8Vy8X3xNmwf4tPx2g/noWxCBhbgXE9nyl2kBuB8R7cPQaMR4HxPdJH
c8gALSYpWg+MK4CxDxiHgPFqYNwFjP8EjPcD40+B8Rlg/A2e/o2OCno6LuTRrUKY7hDmA+MyYLwI
GBPAuA0YbwbG24DxfmB8HBjRH4U//1/izgQ+qupu2OfOTO7cWRKSGCAsCgFENjEiFcoaMCqbIaJY
iq2OgOAg0rAa9iGJGJViREvRWkVqkapFSqzV1k5HkkaQRcQkpoQqBAaVjiFSZpjSvNzvOWcmG+L7
2vf3fb9vDs+de+9Z5r+d/zkTyMX6A6uwTrMmWX+IDvOsV1kXWgdbl1uHWVdbx1jXWO9CxwfRcRE6
rkLHDej4GjrK/zFHGHb+JCf36ZO9sqDASNAMPa/Yx6s4z9A1w2goLuJV3KAuOGuUl4amGTZf/GUY
muEsK/s1r2efVc3yi9QrX43WUFxc3EAzh71VjS6r7KqqpLjYsNHOU+LL6p5c4jEShKFHu8deSriC
guzsPn2Skw2dmqJx4zIzx40r0hM03d5g5BcXq4+x+3xytOIG3abpCXlSrjx135BNaKTa5xVHfb58
wyYMW2ZWQ5Z80UjX80tKPL48lIyNtHOP7BJTUsSVlCL6fCVbAlu2lLRRXzc03fnW3sd4qc+IdY5/
HC8phm6PCUdrq6bbjsU6Iqme5wtkJh+z24TdFhMoU/WUrTc/oCcIPaG4ODe3e3fdIXRHsa/YN5Ws
0YMSq6Mmt9hoaYY+LbIJn65putUnF1Kfxsvq0+xUb3QlCEeCYSQnd5c9fD7NKmy2Y5ouTL3RaaG/
vClfWVnqUp7Il89n4aP0B3ZarZqRsGXLFuUrpaXSk4vMzNzckii+Ul7EKYZBTZsQI0LsQ7Pl8NlD
v2uIOTTD9Z7vPd9WyjMUaQmDgHIMzS7gxUDN8SRDzWipGWH9X4WausjmrE92QatQcyRoDgKkVazp
sVhTFUZzsMkKT0mDrLAJB8F2uWhrGuwy4eawaQ7CLR5vDk1zNNviPw04OR92Bi4JODUFsi4fcfp/
E3F6S8TpTRHXWrpvCTnHfxtyLgsDNIUcoaaum2IuFnT2WNA5YkGHP1uCjouWoOOiKegcDuFwGCJN
pCnpx8j/xTeWhhzGiLHqo8aOkFeOaJGMlIKiqLqSpxfloa3VHU7N4Q7weinrpayNqqynEGoO54ix
a+WL4XQGjxK9UdnF6ZB1YizrX1MZK0YJzdfSrJjQV2Egc26eEtsuHPaLyfGXUkKONQYFpBpSHUM4
5J+1Y3v1Su/Va+xae4JmZwBib/MDTl1zGrR/u5zhy9+WVbF8Xpynqmw22+L1VK1fbNc1u8zHjT7f
SqdNOBOagzSLlnb7SmleHw3y24yJvMou8UD1ORM0pwziYhmqJcVOTXO2GM1nd2h2d6nYryZsrKjP
jQ/VJENR7FPi98vflj1tmj0et+pczjNPcvIxOZ8SmiTNVAOo/igkzSCDkqi0O4XdlZ2VndXPJ0uK
SBGxaipzc4udrZoSjk7N4kxojmAfAWtHBxnCPoumWThn+2RxbtyYqAuXbrO1iWPNlnBMs4uL9ouJ
Vs2Z0L1VIHdXd+RJ7EWVVce9s97cbLNpTr2EV9z78XCWkWFP79Nn3LjiRsNQdbF4JjKcfHHE8S0h
vYaYUC4wNKdj1JjYp44ZJS+djQUqJNcWNKpLeWqqG5c4yOnSnIkBT8DDxNryVPenuj9OKaIQvE7X
qPgnNL3GEL4qGmTwxoLc5bxsu9FCBJx25Iq1JMwLVKTIWPQkK3Xswmk0B3qy0u6bkW7QiD8q1mPB
HgsZ20o87tI1lwzM1tFuj0e7qrNdPtxdNuGS4d4c73bqVssg9LFArWw77KUB70rQXDLgmyLepWmu
Vgb9vxXyUpV8lRMa/l+EvEuzuJpC/tti3kEbKf63Rr0hLhpmklVztYp6Ge3qVkvYq7gnrRkzNq4n
7l0q7lUYxbeDTTkmvTny1eVK1M3Hg0X5LqdwOd3svGXJoGT51vj4xCxflsvQXI6r7ot9fNZ9V8lr
Z3RdLPwL1kVdDs3lavGO2cpTl3rOlai52gXSA+lb+mzpUzKuZJycko8YjxgFhhqlK1+4W8f5GK67
CpcdAdQSEpsQbue3NL2SKdHcODYlClSo5RcheaahFLULV6tJkawUl2ryx5ehVJcmcFNcDv7IkWOT
xWhe59guxTbhzBFixG3X3I5YNMtVrfztNhswVWvhNewWWXvLMNV3aLacJ9QmCHfC0JaJkuWSm/jm
mVKw8pLBCwpi6aVZc7euuY1Wk6XIrWnu1jb3GS7NSHonUKGSTlNRW7umIdvs81wtNWrOqP1cfM74
4jsDmWDIL6QbPSsrGhN8qBolNiBKsr0zmvd6LmG45adOyJqQ1TR11FBqg8PccbVuzhxwaxa33qyB
NLhmMRJ8sV1P6+njltMnyS7cdoulaQLF509C0/xpZ9Xccv40TSDOuqt76qxpArWZQW67nEEqlmJ2
iZlGzgR3Wlqv7Owik2mj6mNzCP8W5btdwu1KEkl8RZflet/1Pk9gDblfpn+3Q3M7u4k8n0cEWhUP
d7oJQtrtvijK2IAHWr3e85X5LsYqW26arVsE3BYs1eZGkuZOPtb1WNeGEYcG1Myrmbdn0v795evf
X1/mLnO7XZo7sZtYEJepqXgCCwIIYSBhY0VZWVlFoxoqyf3trX3imMhUOjWKClGmSoWQ57Gr93wq
ckfMDgSO5XdN0vX9+W5DuB1mestL2Ss2oizSXjHLSRsqacrKZs8ekZ4+YvbssjK1d1xZoeurKyoO
Lk00tESnFPLoqTL5OnU0tu+crSSfPULVW3kNn6Pq5wyXG0nkqai4GAjMGJGoa4n6CI/HE/XEX25Z
v6aC18rAanqsvvQjysoSLVqiLRAgzTS9Eu1aokOeVOyvaWio2b+/It6m1cvh1hztjh77PLOiTVEb
2+ahY9vc2ep89gh3q7pTR+UYcqNSc6xpRLm9zS+XlnWvz5frpd6iyFA1VHxY1JYbXPnNbqaQ5UZK
V4ojiT8yJGamz9k8a/PgnSMa0j3pHrXvVUaXNndfvm86JVMkWiyJrSIPm5DmHAnSPEJaSOY8rixO
2u0P7A+k2EWSXf5ve25cn8kLWQMBzaYl6A2aQ1x0mL5kG06J3Y+9OM1UN9VZ/CXrrXLnw1xNwI3G
fvlS8RI3YMyGMjiTxFWiA2L3FrPFLYSm6dOFLKr1ammulTpBUrFSxH9S7hRbLdOEdeayhfNE2pyF
9z8ohs27b/F8MYka7Y4pY7ujuzBN9XMqXSSyJsSuNIF6or26H7tjYcVox4d3ENbxubnjRK8pk2/r
LjLvnDKxO5u8WBv5dxXJoqO6svIJKc2js4FSP8+MXbFKiCtEZ9FlZt6iPPGyOr6qjjvV8S11fFcd
dz94/8L5Yo86HlTHSnU8oo7H1PGUOobk37WJs/Ko6erYWR0HquNYdbxLHec+9OBDD2qr1XGdOm5Q
x03q+II6blPHHc1/4/A/HbXveDSwJN9l5b+Ek1/MsMv/v3sW/JD4H7/LIJT/Vkf+a44CsVFsFbvE
bnFY1ImzmkU4lKZGXNuQkP9Ozkq/NGaaJn9+qA2LvRevi73/MtqqD/FWv7XNteZubHud1LvtdUpq
2+srnmt7ffXFttd9Lqnv17nt9eBM4bC0vj7Xql4X2q0j2l5Pepx3JzHdR+TKf1tInwJMlWnJFWss
L1s+EVusv7T+UlTaFtteElUJH+vFmtV5h/M+7R3no+wo97iT3TdbbnLf7X7BsixxVuJcy58T1ySu
t5QnWZIMy+Gk80nnLX8Tmi8ibaNXJ7512XKIciTxZKtyOl4OXaacS+rRXPpQhlGyKXNV2XxpSTyU
tDXpzeRN8bKlVXlVFrn/uUxxpuQ2l8dTnmkukVhJ7XqZMpAyOO25VuXlWFE1l5S0XWl7msvB9sco
p2TpYLtcSR3YIbVDn46PtyrPqLL7suVQxwtNJT0tvXNzyY6XCZctuarcFX9vW3zxo2xXoUplc4n1
/jS9oVO/TrM6vdBpuyyXjt5px+VKbPROb3eqi5dzLUV+SqcL6rN8kisn9RzWXCb1nNJcZsXLXIqv
51z5H4v0yrp64NXZPedyHHj17t57rqlW5Vyf6ZS8vr0pA/rW9Y1CXd+L/fb0f0GWvnX93+1/uv/p
AbYBSQPSBvyRUjlwFCV34PTrno8X//W+G3rf8MXgjTcOpowakj5k+pD8obvi5d2hFUMrh/WjDB22
bvjRkboqJSN3q9I46sZRr8fLWyMbuX59VIO6ahhtGW0Z9froAVkbst4dM/DmaZRPb31gZEmsNe8N
sVbjR8l24ydN6DEhc8KoCdsn9lYld+JcVfInrpv4PMf8iR9Qjk1aPsk36dPb8iibcjy0ys05mHNw
4gccj8ozSl1OKOfCZJ8q2ybvV+XTySH4dHIk1zY5Qn0od3ru0dy62xdTNk7pTrttkyOxminLJ0em
nJxSPzX3ropp036c+uOuP+49xzZn+pyaORea3h8YQNk1P3l+j7z8vIK8QF5dXigvssC2YNCC7AWz
F+QtWL6geMGmBa8veGtB+YLDC/MWbly4feHZRWJR6qJxi2YsendR9eLBi2csfn7JXUuKl/iXnFuq
Lx2w9Jalry899XD2wxfyu+bfku/JX5j/fP6O/JplPZb9aNlby2qWXVjuXt5h+dDlY5fPWr5tec2K
fiuyV9yzYvOKV1ccXRFZmbVy+cp3V+mrslYtXLVzVcWqxtWdVz+wetvq0Jpha/LX7PDlfkuueuvS
fNQ22/iWthSZR3xbWkosg3zL3Jtw6YxrO09ikX7ZrNOUeVqVtrnDV9FSZHbwVbaUWF6QOTT51fSK
js+Qh4+MaiBrqhys3sm3Kbnk181JW5M3JR5qzpm0TYn0nCX7Jr6VtLkld8asRHbOVvk31qpH0tYm
68m7MhertkdkvWoftyDjvpV4kky+lR5H1GiHkG4T70dUaVkdTl+yKmS3WgdaVoKtUu5vZP9Xv5H9
nfGc/7jK9yrLq3HonZTN+eamTIg/tsf9RW6K5Z9Yfov7kZxIBpRem9WcHZs8So5Ln+Crkz1afNxz
iq/OV8dostU56nI71fWc8s2YIA9Wtsqol8mzrfPqN3NqPHNXqGiKZdFJTflT5nXu8Km+UKft3JmS
nnvj4JyDHWyxdUy9s2Z1vND+GFGV2rT6NK0qqV072FpWoFhUyrVNtbbJFvTd3SFV1sg7spW8n9o1
8VBTpKZ3Tu3KCpgq+8vz2N2WdbT1SiplUatmfN1stXKmMsKl6+QzbVbHQ/GVMa1JeuovxD5dfv7E
3PbH0rORp431pdWkjfFUqxnbZOPYTJTWjEVKz1nYe4L0prREem7ac8rf26VvWs3qYZ12oGvTClsZ
G9UXSvf5QrEiP0G+95wivSLPYpEm332hqwf2GhQjtsL1GqRWpVZFrnCx1U2tj//LotbUVuWbLdRK
26rEV9zm8s0ecqX9z4pai79zaV6xv6VcailZmtfxbylqZf/ORe02vmO51Dpqj9KqfNN+au/Sqsi4
j3n6PyvfHPl/lu67lZid5d4laetIfUKPkY2JR+SuR5USdUeXOx11VTKhh9wDxeso7KCGyl1T7K7M
/fJMFrU7mqZ2VnIP1TCqQe2P2B1xtntkidqd+Jp3MbJsm+zLOTrZJ3cw6mpbfJ8TO9/GLqhO3pE7
GtkvJ17Ujmex2hvRVtVuk8dOO2i9Te6myBa9c46qfVd+vOSqO73lrktd5eYclXkpXkdh55bJXk3u
0GS/deqMovZpeWo/R1u1U2ver03MHW1RFmmUtrh9ccwSI3WlDxLHJJ34gRpbftI6NZYat+1M/KZH
W8fBNdWxK6HL35G33ma+a50q2snfkZe/IW/1iyFC/ibxIa6C6ixknWqeFBrH88LCca/6zXiXeM1s
FOVmo+YRV2j3iSnaDNFJmykytFkiRXtQpNByMC1HW+eZfxEa45wQNtq6aZtCWzdtnWq8IK3qhUO7
R3Slvif1U6m/kvqejHU1Y2XQ+xfI86n8vVJzF/KmWFcixyrzD8g7zHrC/Ln1pMi0BsUg6+eiv/VL
8yPrab7tytEPqd/Rt3Fmkb9ZL3+vXv1Wfb5oJyaIZBgm+orhIH/L/n6YDfJ37Reb58QSWAoPQz7I
375fbh4WK2AlrILVUEj/IngE1sGjUAyPwePwBKyHd8RY8UeIcn4RTNFXE6BBrhiu3Q5T4A64E7xi
svwtfzT2Wu8SI6x3C8N6L8wTxfK3pa1rRXdrobjK9qJ52LYFXoLDoq/tY6iEKqiGT6AG/gZHoBaO
wt9F34Rk86OEY+bhhH8Id0KI86+gwTysJ4gJel/ebxB99Rt5n2d+pD8E8+EnsMT8XF8K2EbHNjq2
0ZcDttHfEMP1nfAHOC+G2/uJbvb+cK/oa/fADFgAC2EZ+GAtYCN7CTwFL8JLYqz9Nd6/gnpogK/h
LJwHbGjMhFlwPywR3RxCDHekiW4qdk+p5xnIsy/VkwraE7WlRG0p0dabaBtDtBUQbXcQbTOItvFE
W5Z8wgDxMtB6l7lBPlVAPlNAPlFAPk/A6je3WU8QZ0FhtZ4iBr8Ud6s4O0mro2wzm2bFPeK6VuOP
Y/yljH8z4w+h9XTGfkY+J0A+JUA+I0A+IYDx3mW8u0QSo5xhlDOMkswo1zDKfEa5jlGuY5T+jHKN
/G1zRurDSPKpB4MYYbvSdK98MoBIZ4y/MMZfGKOPdq/5R8a5jnHuZZzBjHMH44zWvOaHjHWdttl8
m55/Yjwb4y1FstmMeQWSFTLaE9Y68xzSfWD9gtn6pbjWejo+Y1MYtR+jehl1CKPezKi9GLEPo30s
f+eZmXcbWk4VrniG+S8yicwsz4pCMySK4BFYB49CMTwGj8MTsB4+MKNiH+yHA3AQPoRD8BEcho+h
EqqgBv5umuJT+AyOwXGogxPmPnESgnDWrBX/ZJ6fgzBE4DxEyW7/ov4C/Bsa4b/gIrKYZkgToKms
eMI6nQj7kXnGeg/vHvOM7bAZsn0MlVAF1fAJ1MDf4AjUwlH4O3xhRm1fwmn4B4TgK6iHM9AAX8NZ
+CecA2SxXQTT3JeQau6zZ5lR+80wASZCjvm5/U7ep8J06u+Ge+BeM2T3wAx4kLoFvC+ExZw/DPmw
jOuVvPt4XwvrOH8U8IP9Sd5LeH8Knub8GfgZbIKfM/6L3N/K+cucv8b5G5z/CfCRHR/Z8ZEdH9lr
TdN+FPCRHR/Z8ZH9GH2OQx3gI/uXZq39NPwDXULwlXnIXg9nqGtg7K/hLJzjGt/ZI7yf5xofGTNh
FtyPvyxig0hTK5dVbCB2pxLDcvVK4Oq3XE3gajxRXm79UPQXGncjIpvIrCUya4nMWiKzlsisJTJr
icxaIrOWyKwlMmtp/TmRFiXSokRalEiLEmlRIi1KFIWImAgREyFiIkRMhM+Tzzqotf5YJFjvgxlE
0EzzBFFTS9TUEjW1RE0tUVNL1NQSNbVETS1RU0vU1BI1tURNLZ6M4MkInozgxVq8WIvnInitFq/V
4q0InorgqVq8Uos3arF6FKtHsXoUq0exehSrhrBqCItGsGgEi0awYi1WjGDFWqxYixVr1Yw9IuzY
cgwz2WDt/TNr7++th1hrP2IVYrVR9j2Nhh+h4XFl35VcyafodMW+BYzwiZjGOpnBOpnBOpnBOpnB
OpnBOpnBOpnBOpkh5P84th42iBtZK3uxVvZizlYyZyuZs5XM2ePM2TBzNsycDTNnw8zZMOtpKnM2
yJwNMmeDzNkgcxZ/i4msm4OZp8eZp58xT48zTz+zzhC9rTNhnihiHe3GOtqNdbQLa2cGa2cGa2cG
a2cGa2cGa2cGa2cGa2cGa2cGa2cGa2cGa2cGczHIXAwyF4PMxUrmXpg5V8mcq2TOBVnjMljjMljf
MljfMljXMpgrQda2DNa2XsyVIOtbBvFfSfxXEv+VxH8l8X+c+D9O/IeJ/zDrXyrrXyrxHyTmK4n5
MDEfZA3MYP3LYP3LYP3LkPFunsXWZ9mfbTAfwQPjyOfHyedL8MQ4PPFratcT7TdbD7OTqjQvWqvE
DOW9WlofoVUNK+YGczVXM+h7mL4fczeLvhvo+z59J9C3kn4/FHp8Hv2AllW0rKTlBLW/kjHzihrp
fupHU3+Q+mrqhzPSY9TuZKSxjPQBI2Wq9n9T+8RP1TEinFo70U2bDvPgIfgJ5MECWAiL4XFW+hT5
XBk+pUA+TUY+S0btjbaIjtY/ie9Z38P/daInq/Yd7BJTWbk7s0vsaf2CzPAlEpzm3j/E91jPF5rv
0aMDe8oeck2n/zwxnhVsOjF/txhvvUftvsaLJCTrgmRdkKwLknVBsi5I1gXJuiBZFyTrgmRd6JlG
z/n0TKPnfNUzkZ6J9EykZyI9E+mZSM9EeibSM5GeifTsTc/r6dmbnternm56uunppqebnm56uunp
pqebnm56uuM9B8d7DkaTu0U/zvopG5eqPcJ5rFUrn18Bt8MUuAPuFE72bk72bk72bk72bk6H/Hta
m3yuDH1y4zuNcuWj46JS62PWaX2hH/SHAXAtDITrIBOuh0FwAwyG78GNMASGwvdhGAyHETASRsFo
yIIxMBZugmy4GW6BW2EcjIcJMBEmwW2QA5PhOfgFPA8vwIuwBV6CrfAreBl+DdvgFdgOv4FX4TV4
HX4LO+AN2Am/g11QCm/C79mtBXh/zzyi7YYyKIe/QgX33zertD2wFz6AfbDfPKUdgIPwITuI6Xxb
ucc8ZPsrO4kKeB/2wF74APbBfjhgVtkOwodmVUKKWZeQBu2hA3SEdOhk1ulPwrOADfQXzFP6NvOM
/gpsh9/Aq/Am98t4Z7ep/5XzQ2aV/jHtaziPmHX2K+Eq6AbdIcM8Y+8BPaEXXA29zSr7NdDHPGLv
C8SCnViw43f7IK5voG64eco+gvcp5hnDYtYZVrBBAuhgBwMc4AQXuCERkqAdJAP6GqlwBaC3gd4G
ehvobaC3gd5GZ+gCXQH5DeQ3kN9AfiMDekBP6AVXQ29kGmSeMm6A75tVxjAYzr0suAVuhXtpN4P3
2dTNod0D4IW5sIS6VbAa1oAPnuT+r2j/Cu23m0eM33D9KpzlXtisc2iAro4rzCoHejjam6cc3Ymh
FeqpSlhHwzoa1tGwjoZ1NKyj0UPDOhrW0bCMevZSCqTCFZAG7aEDdIR06ATy6Uzy2UzdoDtkQA/o
Cb3gaugN18jndvEtuy/0g/4wAK6FgXAdZML1MAhugMHwPbgRhsBQ+D4Mg+EwAkbCKBgNWTAGxsJN
kA03wy1wK4yD8TABJsIkIf+LUZeWA5NBPlfqdpgCd8CdMBW574IfwDT4IcinRK2GNeCDtVAAhVAE
j8A6eBSKge8b6jlVT8FGeBqegZ/BJpD/r658xtMv4Hl4AV6ELfASbIVfwcvwa9gGrIDadvgNvAqv
wevwW9gB5FqNXKv9DnZBKbwpn5Iln2EFu6EMyuGv8slSsAf2wgewDy7NIlPN++QTtVgH2pH5R7AO
tCP7j5DP17KR8WxkPBsZz0bGs5HxbGQ8GxnPRsazkfFsZDwbGc9GxrPt4DvKG7ATfge7oBTehN/D
2+ZXtnfgj/AneBf+DH74CwTgPdgNZVAOB4TbdhA+FO6EFOFMSBOuhPbQATpCOnQSLn29+ZX+UzOk
P8n5Js43m5/rz7Im4QOVzbZQhy76r6lDZh2ZdWTWydL6G+ZJfSfsoq4UZJZ7i/Z/4N471P8R/sT1
u4CcOnKq7Pc+1x9Qt4/3/dw7AAfhQzgk3PrHfDbf7XS+2+nV3PvEPK8y5RFk4/uc/jl9+c6ihzhn
d62zu9bPAN9ZdL6z6Hxn0f8J5yAMEXQ7b560J5lf2dtBMqRAunne3gk6QxfoClcKp/0q6Abdobdw
26+BPtAXrufeIN5vAFZZO6trLOsKt2ERLsMKNkgAHeQ/zjXAAU5wgRsSIQnaQTKkQCpcAWnCabSH
DtAR0qETdIYu0BWQ00BOAzkN5DQyoAf0hF5wNVxjfmX05zvaALgWBnLNTsG4nvOmTDyY8xthCAyF
76PHMJjE+W3A91xjMv1yzXLjdpgCPzTPG/ci52zaXZql+b5r8H3XeBhWIcNqWAM+2j/GZzP/Vdbe
xPtmxn0WnoNfwCuMtx2asvhr3MOHRpi+/zbPO4R50qHJX2gwQw75L5mdvKdw/wrhVpmdFcrRkXvp
0AnIx46u8ueScqbH91Wr5NPq1B5td/P9+fLpcernKHK/VS8SLOPMH1lvM8vYnTrlz7ao+0oMsGSa
py2DYQiMhnHmR5bx5j7LRLiNXflU81N2F0fZXRx1TjP3OafDo+ZpZzE8Bo/DE7Aefgp8l3M+CSXw
FGyEp+EZ+Blsgp/DZngWnoNfwPPwS3gBXoQt8BJshV/By+Zpd3/ztLAiacQyje/EC/kOPRz5w8gf
tgwzg8gfttzE+2PmccvjfHe5W1xL/rqWlvucd5hB551wF/wIZprHnXNhHsyHPFgMj5phdAujWxjd
wugWRrcwuoXRLYxuYXQLo1sY3cLoFka3MLqF0S2MbmF0C6NbGN3C6BZGtzC6hdEtjG5hdAujWxjd
wugWRrewa4J53DURJsFtkAOTIRduN4+jexgfDjE/wUP7LcqP5h71k8Nu6L4dvbdb7jZ3WGbBQ/CY
GcAG8tmIR9B9O7pvR/ft6L4d3QPoHkD3ALoH0D2A7gFnvrnDuQxWwFp4xNyBXAHkCiBXALkCyBVA
rgByBZArIMbgAS8e8CLbCTzgRb7zRNA5Iugccn6GJDVIUmOdevGcddrFMKtLIp65jtUlEe9cF/+O
X050nSO6ziFdDdLVIF0N0tUgXQ3S1eAZL57x4hkvnvHiGS+e8eIZL57x4hkvnvHiGS+e8eIZL57x
4hkvnvHiGS+e8eIZL57x4hkvnvHiGS+e8eIZL57x4hkvnvHiGS+e8WKBGixQgwVqsEANFqjBAjVY
oAYL1OAZr7gJK3iwggdf7MUKHvyx1zJOXIn2OWifE/956xPx79P9sEIHrHADVuiAFW6I/5T4h/hq
L77ai6/24qu9WCMHa+RgjRyskYM1crBGDtbwYA0P1vBgDQ/W8GAND9bwYA0P1vBgDQ/W8GAND9bw
YA0P1vBgDQ/W8GAND9bwYA0P1vBgDQ/W8GAND9bwYA0P1vBgDQ/W8GAND9bIwRo5WCMHa+RgjRys
kYM1crBGDtbwCDuxcA6N3Wj8FBovReNUNFyNhg+LTtioHPuUY5tqbFONHVKxQSq1T6N/OfqXo385
+pejfzX6V6N/NfpXo381+lcjRzVyVCNHNXJUI0c1clQjRzVyVDNXvOYrl+S7c+Jay+3kuGngJc/N
Jcc9CPOAsZH4WHOuW0XOWGPuc60wT7tWwipYDWvAB2uhAAqhCB6BdUBudJEbXeRGF7nRRW50kRtd
5EYXudFFbnSRG13kRRd50UVedJEXXeRFF3nRRV50kReTHOAEFzlPZvbTSvYwczzIHA8yx4PYTX5P
703tYeZukLkbZO4GmbtB5m4Q2cPIHkb2MLKHkT2M7GFkDyN7GNnDyB5G9jCyh5E9jOxhZA8jexjZ
w8geRvYwsoeRPYzsYWQPI3sY2cPIHkb2MLKHkT2M7GFkDyN7GNllzppm/g1r78fC7zXnLKnRZ2IQ
GpVSX0f9ebzRiDca8UYjbT+jrUFbFzPFiaYDmSlOtB0Y/xlQBR5qxEONaFmKlqVoWYqWpWhZipal
aFmKlqVoWYqWpWhZipalaFmKlqVoWYqWpWhZipalaFmKlqVoWYqWpWhZipalaFmKlqVoWYqWpWhZ
ipalaFmKlqVoWSq+hyaF+GYPvtlj8Yqu+GcPGsxkBvyLGRBBkyI06Rj/yUxH+ZMZNPm5/GkWvtuD
7/bguz34bg++24NWhWhViFaFaFWIVoVoVYhWhWhViFaFaFWIVoVoVYhWhWhViFaFaFWIVoVoVYhW
hWhViFaFaFWIVoVoVYhWhWhViFaFaFWIVoVoVYhWhWhViFaFzONpah4PRYsP43/ndAtSP43Uu4QL
fQ+g7wF0PYBe7dGpPTU/Q58D6HMAfQ6gzwH0OSB0yxL8utT8l+Vh85SliLj4qVlv+Zn8STt3L1iK
zIjQOP5L9KVFxJJPRCyDIrPKsk4Ylkfpvd78wrJJPmPU/LflWfPfLva3Lva3rivhKugG3SEDesAs
2twPs2EOPABemAsPwjx4CObDTyAPFsBCWASLYQkshYchH5bBcvPfSp8LSHrCssr8HF1OWp4xz1j4
piemWxYS7YtgCXfz0XIZrDEPWXywFgqgSLS3rDPfsDxJuxLzmOUp2AhPw2bzHfR7x2Ux97usYIME
0MEOBjjACS5wQyIkQTtIhhRIhSsgDdpDB+gI6dAJOkMXsx4b1mPDemxYjw3rsWE9NqzHhvWuYeYh
13AYASNhFIyGLBgDY+EmyIab4Ra4FcbBeJiFHvfDbJgDD4AX5sKDMA8egvnwE8iDBbAQFsFiWAJL
4WHIh2Ww3HxH2IicT7Hix1jxuGWT+TWxVGSeJU7Oi1y8EMULUTxwAQ/ICDvOihNhxYnQIoKVo1g5
ygoTYYWJsMJEWGEirDARVpgI1o9i/SjWj2L9KNaPYv0o1o9i/SjWj2L9KNaPYv0o1o9i/SjWj2L9
KNaPYv0o1o9i/SjWj2L9KNaPYv0o1o9i/QtY/wLWv4D1L2D9C1j/Ata/gPUvsMpFWOUirHIRVrkI
q1yEVS7CKhdhlYtg3SjWjWLdKNaNYt0o1o1i3SjWjWLdKNaNYt0o1o1i3SjWjWLdKNaNYt0o1o1i
3SjWjWLdKNaNYt0oc24p0S3n4ipsuproLhJJWPsE1q7D2mdEHjb2Y2M/kf4FLfdg6xPY+oRlOder
zC/pdZbIDxH5ISI/ROSH8MN/4Qc/fvDjh68tG8z3mQGfMAM+YQZ8wgz4hLm0n9xQgY+q8FEVPvLj
Iz8+8uMjPz7y4yM/PvLjIz8+8uMjPz7y4yM/PvLjIz8+8uMjPz7y4yM/PvLjIz8+8uMjPz7y4yM/
PvLjIz8+8uMjPz7y4yM/PvLjoxP46AQ+OoGPTuCjE/joBD46gY9OMENCzJAQMyTEDAkxQ0LMkBAz
JMQMCTFDQsyQEDMkxAwJMUNCzJAQMyTEDAnhYz8+9uNjPz7242M/PvbjYz8+9uPjKnxchY+r8HEV
Pq7Cx1X4uAofV+HjKnxchY+r8HEVPq7Cx1X4uAofV+HjKnxchY+r8HEVPq7Cx1X4uEp48WAQDwbx
4D/x9268eAbPHcFz/8Bz9XiuHs/V47l6/O/G/7vwXgjvhSxPcO+nePpJ87d48As8+AUe/AIPfoEH
v8KDXxMnf8aLn+HFz/BiCC+G8GIIL4bwYggvhvBiEC8G8WIQLwbxYhAvBvFiEC8G8WIQLwbxYhAv
BvFiEC8G8WIQLwbxYhAvBvFiEC8G8WIQLwbxYhAvBvFiEC/V46V6vFSPl+rxUj1eqsdL9XipHi/V
46V6vFSPl+rx0v8h7s7jq67vfI//ck5yTjg5cRfX1rq26rTWunSqXaYdx7HT0dYu1rZTOzNqLVRa
UVERUWhd6oq7KOJSEVErUFNUFFyxaGwwIQc4nAQSWUxyOPmRhGyA8r3Pk9JeO/fex73/3Hv/eD1+
Z/19v9/3Z48xxKwUs1LMSjErlVipxEolViqxUomVSqxUYqUSK7WxUhsrtbFSGyu1sVIbK7WxUhsr
tbFSGyu1sVIbK7WxUhsrtbFSGyu1sVIbK7WxUhsrtbFSGyu1RZ9lpUFWGhyJxj9boZ8VelmhlwUG
WaA8N/VSt5e6vdTtpW4vdXupO0jdQeoOUneQuoPUHaTuIHUHqTtI3UHqDlJ3kLqD1B2k7iB1B6k7
SN1B6g5Sd5C6g9QdpO4gdQepO0idXur0UqeXOr3U6aVOL3V6qdMbHSUzfCAzfCD6S+p5JnGzU9zi
FCO79/heTFfv71e3D9DVHYiP4eM4CJ/AwTgE5/nM+fgpLsDPoIOk9RCth2g9ROshWg/ReojWQ7Qe
ovUQrYdoPUTrIVoP0XqI1kO0HqL1UPQzWnfSutOOS3ZcEgVFUVAUBUVRUBzR/y8RQPf/wfN18Iny
Tzb+197eyR6d7NHJHp3s0ckenezRyR6d7NHJHp3s0ckenezRyR6d7NHJHp3s0ckenezRyR6d7NHJ
Hp3s0ckenezRScESBUsULFGwRMESBUsULFGwJBqKoqEoGoqioSgaiqKhKBqKoqEoGoqioSgaiqKh
KBqKoqEoGoqiofh/EA1FFiqyUJGFiixUZKEiCxVZqMhCRRYqslCRhYosVGShIgsVWajIQkUWKrJQ
kYWKLFRkoSILFUdqfM/If4U8ka1KbFWSbUqyzUbal2hf1rhE4xKNSzQu0bhE4xKNSzQu0bhE4xKN
SzQu0bhE4xKNSzQu0bhE4xKNSzQu0bhE4xKNSzQu0bh8xpIzlpyx5IwlZyw5Y8kZS85YcsaSM5ac
seSMJWcsOWPJGUvOWKop+8IEXIbLwd+cseSMpWg3uXjgb2OGp908EumDcurg/y5G9O6X6VFNpqIt
K9pSou09kba3SMtEZ/w1o0xQjSfjanP5tda6MfTw7B6fHhabPapzv299hsKDFO7/SNfUw7t7eHcP
7+7h3T28u+f/Ubbp4X09vK+H9/Xwvh7e18P7enhfz//Vrqg8rQxTaulf55b+KLnztWFW2h59j7b1
tK1nv27266ZtebIpsEQVfTvo2zGS/6Z5frcZ4R6d0nSv3R866NpB1w66dtC1g64ddO2gaz1d6+la
T9d6utbTtZ6u9XStp2s9XevpWk/XerrW07WervV0radrPV3r6VpP13q61tO1nq71dK2naz2f6uZT
3Xyqm09186luPtXNp7r5VDfdO+jeQfcOunfQvYPuHXTvoHsH3Tvo3kH3Drp30L2D7h1076B7B907
6N5B9w66d9C9g+4ddO+ge0dN+ZwTcBkuxxWYiCtDx4jGW3dGwnC0Z2JBNDrxmo7zdX75RpiSWBrm
JLboMwbCtMTW0JiUOZOfNr0eE+Yljw8b//rbymdFuyW/P/JvqZR/p7Az2xKWsdgs952L10XAGyGX
WMLT38RSa77l+k5oSSwz6eastsJ1JTqjUYkukTqgxx3UCQ1hW+hNRqE9mUY19jP9HxPWJ48NW5Kf
w3E4IQwmTw7rsv8eStnzQ0P255Ajsr90vSi0ZMdDTshOcp3sejX00NlfQ8XM3gpRmZ3m/bu8Jvdl
7/N8Oh50j1lha/ZJ95+H+WFL9vd41mt1ni90daZso9easByrPM+jxeNWtPtcd2jPbsFQaK/dK8S1
e2M0TIe1psPaw7w+NjTU6ulr7av2htBfe2vYUnsP7sdjIY7+ZaeqBXYapuoqqnZTtZuqH1B1A1Xz
VF1F1S1UXUXVVdQcpGYfNfso2UfJPkr2UXErFQeoOEDFAQp2U7BAwVUUXEXBAgVXUTBPwTwFCxTM
/xcFCxTspmA3BbspmKdggYIFCnZTsJuCq6jXTb1u6g1Qb4By3RQboNgAxQYoNUCpAUp1U6qPUn2U
6qNUH6X6KNVHqT5K9VGqj1KrdipVoFQ3pQYoNUCpAUr1RYckngqTEgvCfEq9zAe3U2g2VTYl1oYL
+NmERFd4mHeflejXaW8NX+Znf0wmw5JkKtyWzIZf8PYVyb3CwcmDop8mDw+X8vxDkp8JX6PaY7z/
VD43I/nlcHXyq+FHO387qy35/fBI8uwwNjkmLC7//pJTvSgnvaZKvIGlYY0V32ePtVbcaIUud+1x
x3XuuFksnSyWvmQifIrFXgtNvlWOlz+NxEhn9HHfXu6bb/vmBnvbaG817pAbiYfjQ843Xwtv+9b7
vvWcb+zpG+9Zr20kfk3VIzF8kDj9tOfHhLW+1W6XS6KP8awtI99cwrPexFs85h3fXsarcrrIFa4r
wwbesYF3bOAZG3jGezzjPV7xHq/Ywiu28IotPGKYRwzziGEe8R5PGOYJwzxhA8ttYLktrFbO/J3R
LvaTsvNZ1nvKui8460K8FbbRtZWeG7NXhEH373P/Pvfvy97v+UNh0H36okrf6rfzi31jXdnvdcJP
ySULnOWN0OjVlkSTPFLWcG0o0q3JfVe576robKtO8+kpYmr9iLe8ECZbfbJv9lJiGyW2ucN6SgRK
9O+Mq35K9CfyYa471vGkxkSJ92SwVzg/OZo19sG+ODRckjwMh4dNyU+x85H4NOvRPfkV73915HeX
j7WbY8Xeeur2U7df7K2ncD+FA4WD2FtPhcmUDpSYRolplJgm/tZTexu1t1F7G7WD+Fsv/tZTfRvV
t1FrMuX7KTY5+4xMNBcvhUuyS1z/hAYsw2oUsMZ7ba7vuce6cEltFP5YWxXm1qaQxsGeH4GxMtTU
ME0MrmfNbbX3hnW192E6HsDMMDeq4ZF9vHEdSx8n+3wo+3wo+3zI6p8X6R+K9A9F+oei+sPoQPYo
23KQ9j207/GtlBzVK0f1ylG9zt7v7P3O3u/cPc7d49w9ztrjrD3yS6/80iu39MotvXJLL//ulVt6
7bXfPnvkil65oleu6K3IWHEqD7iX9V9l/TtZ/87EYhZ9Ga+FpYklquKbWBoe4wXbE8u9nuNb+TAh
sTosShTQglaswdpwQ6LNdR3Wu+cG143oQGc0lbfUJYoeb0KJ53W7xtgcLkn0oNfjPmwJY+SmRpk7
L3PnRfBZctSyxHbvfYAPw+LEDtegClcggXL+quRtVR6n5KlMmJKs8Tgbxo3ks11dd8Pu2AN7hZN5
62m89TTeepraen1y/3B58gDvHYjyv2h5sOshOFTOOwyHh39LHuH5J/Epz4/EUR7/HT4d/lGO/A+Z
5RlWm8pqU1ltKm8/Xb68NXmiz3wefx9+lfyC60k4OVyT/KLrl/Dl8GNRcVryHzz+arhYZJy18zdm
nxEhlyd/GO2bPAdjwrvy6++yY0JjdiwuCttFyXYRcqcI2c5LpvKSqbxkanaq93+F3+BG3IRbotHZ
W3Ebpvn8PV67F/d5Ph33u88Mzx9yfTiMyz6KxzArXJ99PFyuml2Tfcrzp/E7PBNOFVWnqnDX8MCp
PHCq/uB6Ve6a7B/Cr7IL8JzPLfTaSz63yOPFeNnrSzxf6vW33Lfea+/gT15rwDI0ulcTlqPZ51f5
bB6rvVeA7M27p4raU7NrwyKRe6oqeo3oPU30nppd7zU+mOWD2ffBD7Od6AqvZvlhlh9mS+CD2c3o
Qa8M0IdBj4fD4uxWbPP4Q/C5LJ+TFabU8rtaflebDItrK12rwgRZYoIsMaG22vNRskcGfLA2G16t
rcUuHu+K3by+O/bAnl7fK+RV+rxKn6/dx/329Zn9sD8OwIH4mM8e5P1P4GDrH+I1GVY2mlJ7TWgU
4VNrb4hG17J1LVvXsnXtzbgFt3rvrnC5yJ8qU50qU50qU50qC0yVrU6tneE+M+37Yfd8zP1nef44
ZuOJcEl0sCxxsSzx+5HK/PpIPX9TJugQ8dNE9o9F9gJRO0/Uvq3mDojYV0TselHZJBrrReFiUdgs
6v5JZJ0jkuaJmFtFzJsipkOU3CNKmkXBy7z/cd7/Td7/Ku8v/58KJ/L4d6P/lK+etJPfqVjLE/NU
qQVywgteW4jX1bk3vLckrJQ9V6pcr8pZ3SrXAjWw2267VK8FqtcC+WuWnb8pT3XZ+TK5aIld5+Wb
dfLNOjvvkK9zdr5Zzs7J2Tn5ZIndPyMXPCMXPGOX2+3y2+WeR/Vanv0Pmfb8sEAFW6CCLVfBFojN
brHZrYItF59Pis9u8fmk+HxSfD6pgi3PXut71+Fm3BJWyuorZfWVYrNbNVuumi2X4VfK8CvF5pOq
2QKx+aRYeobfP8PPn+HTXepJTj3J8dsuNSXHV7v46RJ+OYtfzuKXs/hiF19bx9fW8bV1fKuLb3Xx
q3X8ah2/WqIW5fjUEhVuAZ96UoVbrnKs5B+z+EcX/1ing1zMD17Gazq0peEFSm9QHZr4wtdk81bZ
vJU/vEPVdqo2UrWRTzwvc6+l7FsydStl36LsW3xjE994XzZulo2bZeNmPvJ3fGRIli3IsgW+spqf
bJRZG2TWBpm1gc+skE1Xy6J5mbNZRmySEZuovoHqG6i9QQZskgGbZMAmGbBJBmyi7AZZr0nWa5Lp
mmS0vCxWkMUKslheFmuQxRpksLwMtloGWy1brZatCrJTQXYqyE4F2alBdmqQnRpkp9WyUkFWKuzM
Sg2yUUE2ystGzazzlszSKrO0stJbLPSW7LJWdlkrg6yVLVpli1aZoVVmaJUZWlmqkaUaWapRVlgr
A7SyVCNLNYr8VpZ6S+Q3ifgmEd8k4ptEfJOIbxLxDaK9QbQXRHtBtBdEe4NoL4j2VlZsFOWtorxV
lLeK8lYzcafuuNxXHx8+iE4QZeU56+ciarqImi6iXmfnKaJmK7vOZtc6dq0TLUV2Xc+uc9l0LpvO
FRHDomCYLaawxRQRMMweU3j8MC+fzsun8/LpbDGFlw/z8mFePp2XT+fNW+k1l05zefNWWs2l1Xpa
refVW+m1nidvpU8dferoU0ef9bx5K2/eSqM6GtXRZy7vHea903nuVmeuc8Y3wq08dsgJFnu2xd4H
wlN8c220v5Nt8Wyjk3U5WZeT9ThVgzxQdLIGJ2uwuy1212B3DXa3xe4a7GqLHW2xoy476rKjLrvZ
Yjdb7KbLbrrspsEuyrNsV3SQlQastNpKG6200UqdNCzPqI1W67dao9UarTZgtUarNVptwGqNtOij
RZ9VB2jRZ+UBK2+08kYrb6RFn9UHrD5g9Y1W32j1RquX58ONZoS18uWW8K5Tv2vlfiu2ymULZdxV
Mm55Pnh+JOOmfKp/5wxV3Pn/MB2TPDv63Ihy7d5p9U77yLPybLd9RMeqnd/q86zk/ivdv1c3nNfT
lii8zTkzlIhQpSdNIY2DPT8CM0OPe6wdsUyTT7eoIuU99kdHuMeb3nmBfn3u9aJPvP+X+X6k3kTy
SxrVyIQXnepMpzmXjn10XEvHtXQsz9dr6ddnDy/aw5v28KY9vEnLv527D8CBH5m/D/b5w8TiEa4z
ff5hr5Vn7gpnjqN97K/XnnrtaZM9bdr5E5zNdt9lX5vta7N9bLaPzfaw2dq91u61dq91N1l3k3U3
WW+T9TZZa7N1eq2xKTrM3V9y+j86+VsfybI5Oj9jpcGRrJoZ+U2R63bacrXTjyn/Rs9fso8Tv2XV
l6z6klVf+p9mnnKmOdjnylnmCNdyxpjps/81Y4waqaJb9AFbzdYpdv1euGjnb3e8a+UfjPzG6Ofs
e61PPs9qDeaClfb/CpXmfSSDlCtDnlIz2bpcd9+n1kxqzXSeV9z1Zneby4oNereVFJxJwZks2UDF
mSIiLyLyLNrgfK+IirwzrnXGtc64llUb9GAr9WAr9Vsr/0vmyLNyAys3/DVzHOweh4WZzv6Kc69l
5YaR7HEA1Vuo3jLy04gBWWRreMOuuynfYsfddlz+GU43tVuo3WKX3XbYTeUWKrdQuYXKLVRuoXIL
hVus1E3hFuq2ULeFui3UbRFVA7LuNtWP9/CwgfBKlFAFt+mUtkZJ3chSz3o964gO9iw2wwzrT2L9
SaxSDqmUQyrl0M6fERb1LD36+GEVr6jSFVW6IZVuSL8+rNoV9ejD+opYTz6sug2pbkOq25C+e1jf
PayyDalsQ/qOWGUr6j1ilWZIpRlSXYaiUWr5Vjt5UO2O1exyX/e+VWMWfIwFHxvJKqNU+/7kXjLJ
p0PJCbp8qpQ8IdpVhjHzRMdaJx9Vus8G9yn/zHW4fAInzo78BKFY/jwl9hJPJ4Rhr5d/KusTvrcu
2tuz8un7nb7f6ftHTv5DvcI5YcVHTt7v5P0jp250bcJytKAVTudk/U7W72T90Sestoy+A/RdRd9V
H53MrV2yykbaDlhhoxU2/nUaf3bkJ34baTtA21W0HfibCX2V5/mRnwKOTOq0XWX1jbRd9dFpPapw
8oHosGStR3uFh3VLsW4p1i3F9vScPT1HrQEdU5eOqfzTtW46bdIZxSzwAQs8zQJPmyP3MEeWfzuy
3PV06Xq67Os53U2X7qZLd9Olu+nSzXTpZrrs5zmdTJcuJran53QUXTqKLh1Fl26iK0rbze+tvMWK
w1bcYrWtVnvHau9Eh3r3Pbp12ONqe1ztk4M7f4b93y10gs7uZH79VTrMCh003EbDbX+10rNeq/N8
oetLOq2lrh+12irP8/iL9db4TLvPrwur/8aKo6nWTrV2qrVTqp1S7fbdtvNnUu0UaadIOzXaqdFO
jXZqtFOjnRrtlGinRDsV2qnQToV2KrRH+zvnGmdc44xrnHGzM+acsdkZm52xWada9rpm52nWVRZ1
lUVnWaOzLHtgs7M0O0uzTrLoHM3O0ewca5xhjTM0O0OzMzSP/F+UhyZ/Eh0aTY/OC/dH5+OnuCQ8
El0Z7ogm4SpMxtVYH6ZHG7ARfT6zNdwebcN2fIAPw+0VnwqNFUfiKByNv8On8Rkcg8/iWHwOx+F4
nIAT8Xn8Pb6Ak3Ayvogv4cv4Cv4BX8XX8I84Bf+EU/HPOA1fx7/gG/hXnI4z8E2MifapeDW8UvFa
eL7idbyBJXgTS8PiirfwNurxTlhc+XC4o/IRPIoGz5fhXThr5Q6EcHvVbuH+qj3C9CpddpUuu0qX
XbUP9sV+aA93VJV8phs94Y7UkTgRF4b7U+PwC/wSE8IjqctA99S00JhqDItTJp70EWFx+pP4VHg+
fSQ+h+M8/yJ+GKanf4Rzwu3p+zAL7Z6/h3Vgs3RXeCRdxGbv9Xs+GG6vToTG6iQqUYUUdIrVOsXq
UcigBlnUYhfsit2wO/bAnvhCWFx9En7i8U9dp7g+4TonPF89EBpHudeoPfXHP472CMuiPSH7RXtj
NPbBJ/EpHImjcDS+gX/F6TgD38S3cCa+je/gLPwA54UHee6DPPdBnnt1dGmYGU3AZbgcV+DKMIc3
z+HNc3jzHN48p/KmsKzyZtyCW3EbpuF23IE7cRfuxj24Fw/73iN4NMxh9QerVoVlVa1Ygza0e/19
1w6UvN+NHq99GJalUkhjFDLYF/vhcBwBOqTowDvmpI53PdH1ZNd/xo9xDn6Cf8eF4UGe8yDPeZDn
PMhzruY5V6ecN+W8PGhO9S/L2kR3hMboTtyFu3EP7sVsPIE5eBJPoR7v4E9owDK8i0Y0YTmakcMK
5LE+PCsnPCsnPCsnvB1tQT8GMIghbA3z5Il58sQ8eWKePDGvsjM0VnahiE0owXRSGWMzetCLPphY
KvtR/t4OhDBPvD2blgvSYj8t1tNiPS3O02eEt9Pfdf0efugzP8I5YV76555figm4HFfgKlyPGyDe
0jRK0yhNozSNxNO89G9dZ7nOc30JdEjTIU2HNB3E2rNi7Vmx9qxYe1asvS3W3k5vQgmbfbff6/QQ
d/MqPhNVRrtHVUiV//2P8j9kgFEo//XuGmTLf2ISu+CkaHR0Ms4Lk/j4JD4+iY9P4ONj+fhYPj6W
j4/l42Ojie5wZRjHz8fx83H8fBw/Hxf9Oto1uhbX4XrcgN/gRtyEm3ELFkYfj17E+nAli17Joley
6N0sOodF57DoHBadw6JzovJfkN4aJrPqZFadzKqTWXVyxQNhRcUMPIiH8DAewaP4LR7DLDyO2XgC
c/AknsLT+B2ewVzMw3z8Hs+iDn8IKxKfjXZNHBuNThzv+hWcFiYlvh4uSXwDZ3o+JkxNjA0XJn6O
C8OFerZvJH8ULtW3fSP5E9dLQ31yQmhKNkZVyaZor2SzrneFqXxllEmuD3OSG/QiG6NPJd937Sj/
bSDXTdEelZdGu1dOwGW4HFdgIq7EJFyFybga1+DhME6+GCdfjKtcHu1a2YwcVmAlViGP1SigBa1Y
A3ry9sm8fbJcM6lq97CC118px4yr2hRl5JdJ8ssk+WVc1fZo91QSfCu1B/bEoTgyjEsd5XosjotG
yynjUp/3+MIwSf6YJH9Mkj8myR8T5I8J8sdY+WNsii+lrgRfSt0fVqQeGPk/6FekP4aP4yB8Asfi
jDBHpF0p0q4UaZPT46Nd0xdjCqbiDtzn9YddH40+Lpomp5/2uN3n38M68DmRc7fIuVvkzBE5c9Ld
0ah0jM0+3+99/ieCJqeHol2r9worqvfGaOyDfbEf9scBOBD2Wm2v1fZaba/VB+MQHIrDcDjOda/z
cD4me341rgkrRlWEFZmzwyWZH2JyuDBzDcRNRtxkxE1G3GTETUbcZG7FbZiG2+G8mTtxF+7GPbgX
92E67scDmIEHMRMPgT6ZR/AofovHMCvatWYSrsJkXI1rQNsa2tb8CuK7RnzXiO8a8V1jnzX2WWOf
NfZZY5819lljnzX2WWOfNfZZY4819lhjjzX2WGOPNfZYY4819pg9Otp1l1HIoKb8LyEn3xUp62Wj
8qPy3x7ZJ3G5bJYd+dcFUkijGqOQKf8DOCP/DE75L9hny/8ghw6goAMo6AAKOoCCDqCgAyjoAAo6
gIIOoKADKOgACjLfnjLfnjqBok6gqBMo6gSKOoGiTqCoEyjqBIo6gaJOoKgTKMqSF8iSF8iSF0Q/
C3E0BmPxc1yIcfgFfomLMB4X45IwRka9SEa9SEa9SEa9SEa9SDY9RTY9RTY9RTY9RTY9RTbNyKYZ
2TQjm2Zk04xsmpFNM7JpRjbNyKYZdbdV3W1Vd1vV3VZ1t1XdbVV3W6Pyzzvm4Ek8hYXRfjLvfupv
rP7G6m+s/sbqb6z+xupvrP7G6m+s/sbqb6z+xupvLFuPl63Hy9bjow6zbCe6UMQmlNCNGJvRg170
hftk9tky+2yZfbbMPltmny2rT5TVJ8rqE2X1ibL6RD19Xk+f19Pn9fR5PX1eT5/X0+f19Hk9fV5P
n9fT5/X0eT19Xk+f19Pn9fR5PX1eT5/X0+f19Hk9fV5Pn9fT5/X0eT19Xk+f19Pn9fR5PX1eT5/X
0+f19Hk9fV5Pn9fT5/X0eT19Xk+f19Pn9fT5im9FoyvOxLfxHXwXD4ScSpRTiXIqUU4lyqlEOZUo
pxLlVKKcSpRTiXIqUU4lyqlEOZUopxLlVKKcSpRTiXIqUU4lyqlEOZUopxLlVKKcSpQzS9SZJRaZ
JRaZJRaZJRaZJRaZJerMEnVmiTqzRJ1Zoq7iT1GmogHL8G6UUcWyqlhWFcsmTir/P6qu/+h6WrhG
NTtDNTtjpJr9KJQS52GM6vaRqpYYF0oq25dUtrEq25dUtrFm8WnJS8IzyZfC68mXo12Sr6l+75rn
m8zpzdE+qlxRlUsmV5nv/1zpqlS6w0b+xmTR65tUnkujrCqXVeWyqlxWlcuqcllVLqvKZVW5rCqX
VeWyqlxWJ13USRd10kWddFEnXdRJF3XSRZ10USdd1EkXddJFnXRRJ12svC/EldNxPx7ADDyImXgI
D4dTVM5TVM5TzF115q46c1edKppRRTOqaEYVzaiiGVU0o4pmVNGMKppRRTOqaEYVzegzY31mrM+M
9ZmxPjPWZ8b6zFifGeszY31mrM+M9ZmxPjOuHAilykEMYRhbsQ3b8QHEhMo8UWWeqDJfoDLnVObx
5r+8+S9v/sub//Lmv7z5L29KKJgSCqaEoimhoIKfUrUhxCaFgkmhoJJfoJJfUGVPVfakop+iomdN
DYWqHZ6HEKciVCCBZJRV6bMmioKJomCiKJgoCip/VuXPmiwKJotC6kCf/RgO9drhnh8BudaUUdAZ
nKIzyKY+630+qDvY09RR0CGcokPImjwKJo+CyaNg8iiYPAomj4LO4QKdwwU6hwt0Dhek5NGUPJqS
R1OX4FJMCGN0E2N0ExfpJi7SRZxins3rJHI6iVzqoZG/yDQ6NR9/GPmrTKNTb7o2hjpdRi7Flube
fGooGq3jyOk4cjqOnI4jZxauMwvXmYUXmYUX6UBy5uFF5uG69MlRxkxcZy6IzQWxuSA2F8TmglZd
ymxzQWwuiHUr43Ur49P/FkrpH+OcMNF8EKcv9FhMpX+BX+IijHfPi+FcZodWs0NsdojNDrEOJ6PD
yZghYjNEnL7J528e+auCsa4nY56IzROxeSI2T8S6oIm6oIwuaD9zRawTmqgTypgtYrNFbLaIzRax
2SI2W8Q6pPE6pPE6pPE6pPHpDe69Ee9Drk/L9bqm+3RN9+maZuuaZuuWJuqWxuuWZuuWJuqWMmb9
vFk/b9bPm/XzZv28WT9v1s+b9fNm/bxZP2/Wz5v182b9vFk/b9bPm/XzZv28WT+v68rpunK6rpyu
K6fryum6crqunK4rp+vK6bpyuq6criun68rpunK6rpyuK6fryum6ctWfs6fj8IVQV30SfuLe53p+
Hs7HT712gevPMAZj8ctQ1KHldGg5HVqueorvTPP6Ez47JyyqftLjpzAQ8qOiaLQOLjfK2UbtGepG
7R1lMt8J6zPfxVk4O5yhszsj828eXxFKmYmYhL90elM9vg43RFkdX1bHl9XxZXV8WR1fVseX1fFl
dXxZHV9Wx5fV8WV1fFkdX1bHl9XxZXV8WR1fVseX1fFldXxZHV9Wx5fV8WV1fFkdX1bHl9XxZXV8
WR1f9v9jx5f9m45v7+i28MWKc6LTK/49+k7Ff0RXVPxn9E8V50ZfrDgv+n7itOjsxJjorOT3wteS
Z4evJl8Ms5Mvh9OT68LbesO9kjJc8v1wR7IzLE12RQcki+atTWEwOii6bccb0dNhebQkLHf3L+/8
a7AnuvvR7n60u/9DxZgwqLZutIppzlT2vXCSVb5klQnJReGl5GK8vKOUfDUsUONWJV8PbybfCLdZ
/VorDyc3hg6rn2T1aVZPWv0hq78RVSeXhVnJRnsyySeXh3OTzWFhMudbK0OLqrhGn/p0+KO9/dEn
f6B2LvPp+3x6UnL5jh0+/ahPf10dXeAbl/vGAyN/2/EYu52smn9M9f564nSVfEwYk/hFlEw8pU9+
I/xnYmmYnlgbnZAYUJH3inZNHhMeTy6Ksqr0MU7weystNY8mk8vNmivCH1TpKnff4UQ5lXrSzkqd
3DmTJp2sI9nlVEWvbwrdFd+PKsPCqAoppFGNUcigBlnUYhfsGl6KdsNJoSU6Gb8O86NrcR2uxw34
DW7ETbgZt+A2Gi4MTdGLoakiEVoqkqhEFVJIoxqjkEENarEbdsce2BN7YW+Mxj7YF/vh4zgIn8DB
OASH4jAcjiPwSXwrrKk4E9/Gd/BdTMbVuAZTMBW/wq9xLa7D9bgBv8HtYXXFHbgTd+Fu3IN7cV9Y
nfhsmJ84Hl/BmeGFxI2hkLgpFHj591ilxM8+4GPzWaLEx77Jxz5IDu7oTA6JiOGQTm7dMZTctqMl
uT2kkh/s6Eh+GL6S3OH1EParrNrRWZkKX6tMh3Rl9Y6hylE7WiozIVVZs6OjMhu+Ulnr9V187tKw
sHICLsPluAITcSUm4SpMxtW4Br8NLZWPYRYex2w8gTl4Ek/hafwOz2Au5mE+fo9nUYc/YAFeCGsq
F+JFvIRFWIyX8QpexWt4HW9gCZaH+ZXNyGEFVmIV8liNAlrQijVhftX2sDCVBP9NVYWXUnu47olD
cRSOxXGhJfV511vCmtS9mO65c6Ye99h5Us6Tcp6U86TmeW0+nkUdnsdCr7+Il7AI9p6y91S9x+/g
Tx43YBnexUqsCqtTBe91YBN60Yct6McAhsKa9C7YFbthd+wbVqf3w/44AAfi+NCS/jzGh/npizEF
U3EHHsajoSn9tOtQmF/9ybCm+ujQUv0Z18+6noFvevyDsLr6XO+fh/Nxo9ene/1+PIAZeBrbw+pR
UVgzandX8TVKXI3aHweGlsy5oZAZiwvxC1yESyHeM+I9I94z4j0j3jPiPXMrbsM03A77zdyJu3A3
7sG9uA/TcT8ewAw8iJl4CM6YeQSP4rd4DLPC/Jp/CYWab+BfcTrOwDfxLZyJSeGFmqswGVfjGkzB
VPwKv8a1uA7X4wb8BjfiJtyMW3ArbsM03I47cRfuxj24F/dhOu4PL2SPDvN3GRVe2CWDmvBCVKlW
zJf5i8kV0Wfk5Q+ie6Irw4xoEq7CZFyNraFgfi6Ynwvm54L5uWB+js3Psfk5Nj/H5ufY/Bybn2Pz
c2x+js3Psfk5Nj/H5ufY/Bybn2Pzc2x+js3Psfk5Nj/H5ufY/Bybn2Pzc2x+js3Psfk5Nj/H5ufY
/Bybn2Pzc2x+js3Psfk5Nj/H5ufY/Bybn2Pzc1z+K1wVf7TPpaFkZi2ZWUtm1pKZtWQOnW4OnW7u
bDZ3Nps7mxOzQufI70f++beO3ksMhfdUs7wqNiP5bnSQetmugt1ihpthhpthhpthhiuZ4UpmuPL8
VDA/FcxPBTNTbGaKzUyxmSk2M8VmptiMNMMcNMOcMsNMMsMMMcMMEZsRSmaD2BxQMgeU0keFQvro
kb/HWdL7l3v5gj67oLcu6IULeuCC/jfW/8b631j/G+t/Y/1vrP+N9b+x/jfW/8b631j/G+t/Y/1v
rP+N9b+x/jfW/8b61ZJ+taRfjfWopeoJ7j3F4yfKfzUtxPrNWL9ZGrWXeDo7TNdjTtdTNuspm7OT
Q+d/o+474Ksotv/PlLuz997dJIQQkgAhdLACD1FRBBUrIPoUC11FsYD6aCJSLE9FREFU0CcKCupT
fOizgAKCDRULRaogLQFCDyXUhMz/O3NvYkICKfD099/9zN7ZKWfOzpz5zpyZ3XO9YXDD9RY/QW/w
q8AlwtWES4N7FOGT9QbiGFXex7iOeZyYSeeLWdRVzKVm4ktKQv3OEF9jJvUNNRAL6BrU9TXQ6wOY
MVwE3T5eLKWmqPd1mDmkYp6TjtAMOg3zhWswX6gvttDloPt1dC37dJT0lZ6K9C/YMj9E3D2YVcyi
GITNx91CY5eyuC1ddje1KtmeLvhpgt5xIUpth/HwKvAQCWmC0fIgQi/BaDkLo+U2a6N4u/k3SoRW
x91Fdk2xKtLWAw/mvwg205lIcRbuFlIrPGEC4lLxrMbq2836F9GfWoD/r2VLzNc4Qn7A3U9IjbEJ
c8Is3K3BXW/ycXcEdz9QA5LUigJwDpyCc+GCcCG4MJwH58PFoMSOVEV0whyvG1xvPNMszAO/xDzz
K71Y9qdWcgDcQLgH4QbBPQQ3GO5huCFwQ+GGwQ2nVtDlW0FnbwWdvRV09FbQ0VtBJ28F/bsVdO9W
0Ldb2f+/8DG7zUZJa/AUm8VctKT5N5Ov9HTMbrfj2fujTmaCry+QCk+LZ/cpni2iOmwxNUbNdEM9
XCo6IVVn6iy6WRtznUVv/ZWxSiQG6nQxjpqL8XQuytmFlq6Hmcw0eT41lS2oMWqrM6UiRyrKaYbW
7E9pKGmnKd+W5Ef/1+R70QW5uyJ9D/zeit/+kLBF+jfMkXdgfnzYys9ycpFLkGP+CQWpE5EyESmD
SLkLKbIokTKAophD0SbMm/qiJNOmA/USzLt3oNVjgbiLLb2laMFlyAWaZkYciNe50OFzocPnQkfO
hY6cCx05FzpyLnTfXJTZUW8xXzyB4mnoKcpSW6azqWqRMrsAs3rA9cGz9cdMfKHeA+6y8By7IHFV
UPZ+5JqHcsMo91Cp5YZRbrr5bxZQi0e5AVDcD4o7QDEbFIOgtif6FLnoZx0RauwFdsFMvgdcX8T0
p2TkDIJjBzkPIGcucvrgJc/UGnLmoFdk0BW0EW4T3GFI9hG4HLhcuKNAh47QXG7WjUUXoEVX6i56
4PdW/PaB7tMX/AzUk8UQyMU4Og/ycCFqfBFKbGHb5lf9mi1tqV6OPpcALedIVEaaStCWeXCaGgTi
6QrVCa4zXDdqoMbDTYFbj/sNcOlw4FNlISwbvwfAm7H/mAXODuOZD4Oz0/Dch8HZaXjuFDy3QQwX
zxvCs2aKFRRnpW42cnyNHBuRIwU5NiJHCnKch9Rx4HmzlbxfdQ74PoScG22upfZ/CTqhvM6Q5G74
7Y7fAUDFdKoNxMsCxoSAjMlAxkrAu9n2H3VM+61CKoGQLLRDR/hutn3DWMNLFP0gVQ9ivNsMvreg
xK16l5W39ci3EflCoO6CMkfMKkqmnnoP3QF3J1w/tH5HtGcn8NUNbgAk06TOgJRsRk1ngqet0C+3
gcp2jJMtqWogTu8J7IDbqfc4veH6wN0Hdz/cALiBoBsT/U+glaC8CpRXiX54qgHA/HS0YwakaCN6
kH1a4PAW1NFW/bPVxauCvxzwlwP+cqJPb9aU14LKWlDhoHIaeIwDlYOgkgcqxtK8CwobzP8Rgb8c
8JcD/nLAXw74ywF/OeAvh86kntSO7oC7E24wtaGH4YbADYUbRm1QYixKPAOYFUANXwfMCqCWrwNm
vYOa/gg1/QXk9HvI6VWQ03biPf08nuknjBD1I9xg3DLcbMFs4nxqARltIVvqlXIitZGT4N6gNoE4
ahdYj98d+N0Jt5vaOI3gmsP1pnZOH7j74O6HM/y54OpAVG54VG64bStTg1t1pl2NmAa+346mSoym
SgTfu5CyqV2B2KqXQDJ6530DXXAndL/10PV2QrdbLxvmbYKs9c7bhdAshGTJhvoiUO2dt1YcQD3n
IHcusOGoXiAD+iD0wkMyrLORcgFSXm7zfoXYxQhZjJCQzbtLHEF5OaiVo3oZdMw8GSQHefOQahl0
yTykbAVc6p23GaXkQUvNBmc7xGH85qDUXEhmJGcuSs2DdpoNjndIF78hcBFGeIRSLp5gP6SuN/Ta
g8RAJQtU8kBFg8IWW7ZDDLmzkDsPuTVybony0MjUU94Y8JCO3HWQezVyHxBH0GMN97mQ46OQuDzM
E7Q+Cl7SQa0OqK0GtQMyqJfapwqjnT2Kg6a8DZSPgqf/mFFUc1A8BD7WiDziyHUIZa+RPvwNdS2T
Im8hUmSiPFNTq5AiEzRNLa0Cjd2o3WPaC60fbSfkLqV9bFrbLkhbSnvgGU+yHYCn5ax/oMwprnc8
43Hq28aUWM8UIxMoKKuAvyQKyRRQq4Y81TFnqAF/KuJqIq424urivh7i6iOuAcYDKRNRQjXEpuG3
HtrEkwm4gw4hq6L8FJRQDSUZWqkIr4nwWgivi/B6CAcdtIJJbUquFk1hSjK04sEXR+wmmYiQqnBJ
lAr+4pFyE2imgj8O/jhybZJpiK8FVxvhdZGmHsLqw9/A/Cs5qKwBr+YJuUwGrykUiFIxudeAf/OE
XNZBXF3ERXJzPG8CXBXIXiJ4TgLdFDxLNbR+dZRVwzwX4msiPg3xtRFfF2H1EF8f8Q3wfHgKtE0V
0E1EaFW4JL0cPOShdtJldbRlDTxzKtLURJo0xNeCq400dZCmLtLUR5oGGNlMO3m2XpMoAXyYGjsE
PhLARxh8eLZua+O+rq3BQ+AhATyETauQsM+eEq3nCPem9oR97kiOrCjXnGIrKhPotbtQf8fIBXr7
2eSXVzaQqzGp48kHYutR5VMlI6B2Bp66gnKC3A2p0snKCqicb57o1MgLWuJH244Vkhk7NvjllRuL
6g3FgbytQNIeQJzqQLX24kheFlDtMpGbtw3o0xOolgZUayEDeVuBqD2ARtWBau1lMC8LqHaZDOdt
AzL1BKqlAdVayIS8A6iRM1EjjVAjjWQS7pP1GaiRGHDVBLVSH7VST6YivCbSpSFNLbjauK+DdHWR
rh7S1Ue6BpCaIDQ3DzpXK2H+1+cbqozZbgJmunUxqzgPc4V5mO3F2v8Wmsm60QWsB13ObqVn2G34
vR2ae0c9QdwIXeQmPRMzjwn2n+oanSDVPJvK/AfSChuaf/dhwR2HJj+Hfak/tD7z73bp8MVCSz6T
iFpAJz2NLsbZmNrS9dSEbqSbEHoL5nIX0l00iq6m5+g9up9m0hzcfYnzefqRltNYWolzIq2BdjKJ
MkHxXVaNVaNfWSo7k5awdqw9ZbAO7AbaxDqxLrSddWfdaRe7lfWkLNab3Uf72AD2Mh1g/8KZwibg
rMZex1mdvcveYzXYl2whq8kb86bsbN6Mn8ua8ha8BWvOL+Kt2Ln8Ut6Gnc8v55ezC/iVvC27kLfn
7Vlrfh2/nl3Mb+Q3sza8M+/MruDdeXd2Je/J72BX8V68F2vL7+b3sXa8Lx/I/s4H8afYTfxp/izr
xUfzcaw3f5m/wvrzKfy/bCD/mM9j/+Tf8+VsPF/JM9g7fCvfzj7mWXw3m8738oPsM36Y57A5XAti
XwkuBPtGKOGzeSJWxLOfRYJIYItEokhhi0UtUZstF3VFPbZSNBCN2CpxhjiTrRFni7PZOtFENGXr
RTPRnKWLFuICtkm0FBexTNFatGZbxSXiErZNtBFt2HbRXnRgO8QN4maWJTqJ21m26C36sDzRVzzI
SQwRQ7gjholhXIlxYjx3xTQxjYfEJ+ITHhYzxAzuic/FN9wXC8QKniTSxXZeWxwQmp8hAzKGN5cJ
siFvLVvKlryj7C+f4jfKkfJTfo/8TM7h4+QvciF/Tf4qN/FJcovU/JNAKBDiPwe8gMd/CcQF4vmC
wJLAb3xx4PfAer4ykBHI4GsCmwOb+drAlsBWvi6wPbCbbwjsDezlmYH9gYN8S+Bw4DDfHsgJ5PAd
gaNOgO90lBPDDzhxThzPc+KdKlw7SU6qEE4t528i5JzjnCNqOOc6V4hUp4PTUZztdHUeE82dfzpP
ii7O084zorsz2hktbnOed8aK252XnJfEHc54Z4K405nkTBK9ncnOZNHHect5S9znTHU+Fvc7053Z
YpAz1/laDHe+c74XjzvznWXiCWeFs1KMdVY5q8SLzlpnnXjJyXS2ifHOHidXvKpIcfGOUipNvKfq
q2biW3W+aimWqNaqtVipLlVXiN/U1eoasVZdp64TGeoGdYPYqG5UN4pNqpPqLjar21VPsUPdre4W
u9S9apDIUoPVMHFUPaIelVw9qZ6SUo1Uz0hHjVYvS1f9S/1LxqsJaoKsrF5XE2WCmqKmyEQ1Vc2S
VdU3ar5sqBar5fJstVrtleeobHVEtle5Sssb3PpufXmz29A9Td7inuWeLbu4zdxmspt7vttCdncv
dFvKW93Wbmt5u3ule7Xs6bZz28le7jVuB3mXe73bUd7j3uLeIvu4t7u95H3u/e4/ZD93sDtYDnSH
ukPlg+4j7mNykPuU+7R82H3GHSWHuaPd0fIRd6w7Vj7qjnNflY+577j/liPcqe5UOdKd5k6Tz7h7
3X1ylLvf3S+fcw+5h+ToIIBPjgnKoJRjgyoYki8EvWBVOT6YHEyWk4PVgqlySjAtmCb/Hbo+1Em+
G+oR6iH/G+oZ6ik/Ct0Vult+HLo3dK/8NNQndJ+cHnog9ID8LDQwNFB+HhocGixnhoaEhstZoadC
78u5oS9DP8hNoWWh3+Wu0NrQJnkgdDicIvPCdcJjAmnhseE3As+Fp4fnBF4PLwzvDbzjKS8p8JN3
undZYI13s3dX4JB3r/eAE/T6ev2dWG+gN8iJ9wZ7g50q3hDvCSfRG+E956R5Y7wxTgNvrPei09Ab
501yTvfe9N50mntTvPedc70PvE+c1t4Mb5ZzufeF94XT1pvrzXXaeV95PzjtvZ+9X52O3lJvqdPF
W+6tdLp6q7x1Tg9vg7fbudPb5x1yBnpHvFxniJfnkzPc5z53HvOl7ziP+67vO0/6cX6iM8pP8pOc
F/wUv7rzop/q13XG+/X9+s7r/nB/uDPRf9R/wpnkj/Cfdd7yn/dfcKb6L/njnGn+K/4rzof+q/6r
zn/91/w3nI/8yf47zowYHhPjzI6Jj6nqzI+pFlPDWRhzMOaI8yvxEObvRN4lla6lhpRGp+jQM3WG
3kyN9Rb4V5eYIk+/qj/AmaVH4u5a3Rl55sG3JRq/RW/DdUP07kCx/CZ2m87G+UecKqGcfXAvlsrv
w3BfFAlZixISTSnHPaB5Id1vOgd+DyN5F/Jxn1GUx/ynKaHMn/V6vUv/AgrpeNrM0ngsw+GC6rgo
9Y16h56nN0Xv9hYrfTvcGr1OL9GH9NUURN2dRrUKxeeVVpjej7bLBoU/OEf9Y8YSiX1Lv0UeXEEb
HpN7J9wmvQo01uI2gHlWfboIvpo29lu9QC+H/EB2oLeXXP57+k39On5HwLXSZ+kBuj98heox/+nh
21Esd57+TmdCgr7TP4EPtIOpvaK5CtL+XEpVEPRUohjrey4asgu0f8mXzcJSEQ3JxpPvRd2v1vsw
349FUDO0QkHperttoe35qYvl36G3oo/tyq9xszJqf38vnKY0vqPpVhW5+0eRux/KRgNHE5s+Kml6
BdrP1StKKflgob7dhM4rJfX7+t+mR+vvysxT0fybjXQYmS0Ws6wMufFk+knrm35sf9a3lSE/ZER/
YnFrrWm38h76XYum76Jeix9umShk6ZkWNcsoFyVQ2Ft2qSohdxRh9a8Vyv2hva4wyHHKj7+VofzN
kbFM50CO9pW7BO+EsQ3g/m5LyR/xNkTOaHzNEvI0wlkTZ6MiXL4d/V0YOU+Qv0mJ+aO1CynZD3Ta
fzyGgZ879R4g2Hrbp4xUH7LhL9joVP2lnqOXmhH9OPlzC/mfoWTg/03UwfSQaNgajA2zimNxQZ6c
Qv4xGHli6SrqAf+0aFgGam/x8UfV/PKtRL+C/EGgT98okpvwj/QHJPSM4+Y/VgoDmD31Qviz0fgf
9Peo/x+jd8Xx+0gh/0jkTqb2ZGZCraJhX+jPQeE/xy1/Y8nheWgxg4/6On2N7qk7RFNPLJb/MaDY
W/o/epFeWiiYU1d6nEbB9xyNNt/M0PuQ3Gk0A7PDWTSHmtpVheb0DS2nc+k32kRtKZMxupn1YD2o
HzT6v1N/o8vTQKPF04P8Ht6HHoI+vpKG8tU8g4bxLXwLPcW38e00wujmNJIf4AdpFM/hOfSc0c1p
tNHN6Xno5mF6QdQUNell0UV0pVdED3ErvSqny+lktFpNrwfiA/H0s/Op8yn94nzhzKEFzmrnd1rk
aEfTr0anoyVGp6OV6lp1Ha0xOh2tg053E603Oh2lG52OthidjrYZnY62G52ODhudjvKg0z3DCNrc
88xRL6iXWdDodCzW6HQszuh0rJKarKawykanY1WMTsfqQ6fby86ENqdZB1e4AdbZdd0Q6+Z6bgy7
1a3kVmY93SpuVdbLTXGrs3vcVDeN9XHruPXYA+5FbivWD1rbHWwAtLMRbBC0s2fYYKN/sYeNTsSG
GJ2IDQ0/HB7DHjWaDhvvxXlJbJb3vvc++9bL8HazeUbXYEuMrsF+M7oG+93oGmyd0TXYeqNrsAyj
a7CtRtdgu42uwfYYXYNlG12D5Rg9guUaPYIdNXoE5zHBmDBXMVViqvJQzKGYI9zsKaywEsOsxHBI
zDhoFOPpX5DpV2kKQt7Cqehteg+j1FTIk2PlyYE8zUav+wJSFbJSFYJUzUf4j7SUwrQMJ4eULces
+jf6HbOrNZSOPpYBmatFmbQHPX4vztq0jw5SHTqEsy4dpqNUj/IgkZWsRNawEimsRHpWIj1IZG+K
430gl56Vy3jI5RpK5Gv5WqrM1/ENVJWn83RK4hmQ1+pWXqtZeU2y8lrFymuKldfKXHNNlQWm/5QA
qeW44qAqkF0FPxqfkkUQcpxg5bga5LgL1RddIc0NIM094L8VMt3AynQNyPQaYnKt3ERcbpaZ5Mgt
cheFZZbMplS5Xx6gWHlQ5lJNeRTSX89Kfy0r/TWs9New0l/DSn8NSP+llKDaqDYUVpepy0iqy9Ef
AugPVyOkrWqLkHaqHSnVXrUnV12DflIH/eRa5L0OvSVoe0vYrICQr25Cn4lBn+lMtVQX1ZViVTfV
jeqp7uhFlWwvqmR7EUMvuhe5eqsHkOYfqi9C+ql+xFV/NQClDFQDQflB9LQwetrDyDVEDUH4UDUU
6Yeh7/m27zGznoI0I9TTKHekegaxo9VohIxRY5DrefU80rygxiFkvBoPTl5WLyME/ZNCpn+Czuvq
deSaqCYifLKaDDpT1BSknKqmIuR9NQ15P1AfoB4+VJ+gZj5Vn4PPmWom6mSWmgWuvlHzwO13aj5o
LlaQTLVMQSbVCrUK1FardZSm1qsM1MlGtQVlbVXbqLbarnagJneqXVRXZakslLhb7QXP2SobKfer
/Yg9oA4g/KA6CE4OqcOgf0QdAeUclQPKuSqXKquj6ihKz1N5yKuVNv+v6gaohkETXIEmuAJNcAWa
4Ao0wRVogivQBFegCa5AE2JAk6dwHeGOIG4whaTBFGIGU8gDpgzBdWhoOMUZZCEBZFlOXnhFeCX5
4d/CeynOoAwJgzKUDJTJoMreRm8jJXibvE3ke5u9zZToZXqZiN3ibaEkb6u3lap727yd8O/ydiF9
lpeFNLu93Uizz9sHf7a3n1K8A94BpDnoHUKaI94RxOZ4uRT28jxNSb5RrSsb/MJV+hLXgO9QPFDM
pap+0A9RFT/sh5HS832qDlyrjJAEP5FSDLpRItAtBddqfnWkSfVrUoKf5qeBTi2/Nvx1/DpIX9ev
Cz+wD+HAPoS85r+OUib6k5DrDf8NUJ7sTwHNt/x3qIpBQxIGDSnOoCHFAbH+G0XDMTiFRcMA0PBl
+F8FDgqLgw5Q8H34p9FnuH5OkDag4Zfwfw0MFDQPOCiAg8uAmMuBr8Ku37sWB4XFwSoWBxMtDoYs
Dla1OJhkcTDZ4mCKxUGPxbJY8lkn1gnX3qwPrvezvrj2Z/1xHclGkg+UvI64RckgULInrgYlwxYl
gxYlYywmJvAdfAdVsjgYb3GwMj/Kj1KsRcA4IYWkeGCfC39IhKiS6CQ6UXXR2b7JZrCvhsW+mqKb
6Ibw7vbtNoODNSwO1hS3idupWgEOZpIAAmaTC+zLpZBFvRSLeolm1Rb982J1MXrvJeoSEhbjXHUF
ME4C49rCb9BNWHRzLLolqQ6qA0IMugl1vboe1xtUR6Q0GCctuiVadAtZdEsBuvUgT92mbsP1dnU7
0t+h7sC1l+qFq0E61yJdKIp0/VV/hAwA0jkW41z1kHoIeQerwUifj3TD4Y9g3GPqcfgN0rkW6YRF
upAapUYh17PqOYQY1HMt6nlR1BurxiLcYJ9rsS/Fop6wqCfVa0A9EUW9SWoS/G+oN4Bob6o3kd7g
oLA4mFIIB4XFQRc4OBP+CPbNVl/B/41ahKvBPhfYtwp+g3pVLOolWtQLWdSralEvyaJeskW9FIt6
ntqn9iGXwb5Ei31JFvtSotiXC4wTFuM8l7mMRAStQoNCD1Ew9HDoYVyHhoZSODQc2BQOPRp6FCFP
hJ6goMUpHh4bfoW4RZwEbyewJs7b4+2leIsvcRZZEoAsB+E/5B2mWGBKHvq5wZRKvvAFxQJNFMVY
HIm3OJIABImH3yBIZb+qXxVpDHYk+DX8GgivGcWOWqBgsCPeYkecxY5KFjvigR2vgeZEfyJyTfYn
I/0UoEa8RQ1OvOlus/J67uZLm9PVdPPx5vn/fxx6i95qXPRufUl6l1nnsWt95aW90axwWc37S3u/
Or9Me10U1T53GP3T6qKrdLrOLLqiU3q5+St0+oHyc3hqD90Wmqf5Pa7uXSzHFmja31d8XaaAzo5j
7/Qee42GQ1fMRs2m611wBSt7hTTRhEK5VyHVSjLrHlXhi64w5mvXf9IRKuCmcLke3WLDtpe0uqC3
FV+b03v1Bv0bYortQlT0yF8lL3pn+k9UqgutF4B3UeDfcbxW1uuKr2qeqqPkHZxSc03Rb9jfXLsa
/oNxZn1Ivwvf/GiafMkyPXi/XpgfXq5yNloZTf/j3qyC6TWFUjxr14PMWvk669sIbgojVLR+y9q+
dtU6vfR05T8gaYXo6gM6F+6IWevSR4ukO9G+1P+x40/u82U49ISTyHxtCfTSqSFkMPUkqJ74aEgW
Ww2eWkwt8QA2lHkP8eTHimPoFeGqcN8rY/6P9Bz9YXR/IEFP1HNsaIYZ3QuP3hWaP6wENq6384dM
OzexaGbGJL0ev1OjqXbZ/bYf4ebhzCy6cm2RLJny12a/xVgwXy+Gm4DQq/US/ZMNXxqZRdgd7VvK
z2kxzrcWubNjqP5voZB79GTdRz9tVvl134LQCxD2mel3xXcdyey5Ft8L3aa/xLOsOnU9NV8ezDgG
BMufF86n6P5sYR6AywV7I2aPpRTKv5wqHit6oJZ8+/u82W8uFttff1skbeR3DUa3DCMhFShvmZF6
O9+y9WR8GN/WR2sNV323XmDb+yCJEsYwnxoXo7kL/WBndHdJADnyd50ORmJPfnz7Yx+66H5l/izF
zL3suL0R565ic891du5ZQm9Hbz7F2FXScQyeLSkWn3tsSDT8HyWHU3n20ct96DvLmSHyjsUI/YT9
zbII8LFx8P1bT4/4bFz+/Mzud6KlPq8Adx/pz4CYn0bvvtXvkXk/aIbxwwE5gWLfAiXyZ8FZQN+f
ojgR2T+LKUbze/2pnhulmWDuouFF0EHr8nNr86GX6t8K7vJ1lw3Gl69XRmbiFtHmG/mIvCMS7T97
LSJ31dfau7lkdvMegHsQvjH6ZYx1D0apFHq3BTUwSw+uALe36qH6Td0Hvq/Rq9/UvSw+PIvR6E3U
81w9Qd+FsTXL7AHaJ5upp+lJkZKjo0aK/voYmpl6ObTKSM89p8AXnXfqwxFX9hlzEdrZtr8XvBVU
dJSy43SB5mtnvuvtew+F37g4q+gbK3/WUXQX177BtLN0TuwTFXv/6s84imqyplYhw/tKw0/bOqdM
0y3PUXj+gd5gtKwV+D3OTndBym0nz69+TQ/R/9TjrX8h5P0N86ZMdByKzBf360/g5pxcOZZS48ib
LCdFI0Nvxkhox0e06WbIYcGcO9LqejfmHLtLmgGWu6wKzLkL5f4p0qrgxeDgL9G7ddH+E+X6r+nP
JR36Tn2Hnq2nE7d3Q/VAoHWPyIxAz9CHcDdK/0Ofr+sAR5vpB/XdJ1FWZP6YdlL8RjEpotMWvG/4
RtHYU3noKaeAhpHe5RFUx/y2WOvb+HT96x+j8F97gJvV6HN2zRMybDTFAk0lMtNF7Pdwx3lX9c8+
wO9zhXsu5lcz/0p+jn+gt/U3c6fIm666H2ZHS9H7InFz7XW1/lx31k/DN1r/HgmrYFnfnzy/5Swx
u/B7Xv93j4I57t6Tf7uypHfdT+URmR1i/r0Jo94pWLEo7R3lE+Yto0TpD+za/vaKl1ToSD4lVMp0
YC500jNX/fyp4KSUMqJIh9ntSa/Ln6JWKq2UDMxs/8c95dQdmPVkn7KaiT8JPk5Ff/8T9yMqIo2Y
96RHcka/7MhfF1lg9xkWnDDzfdG0H5a/3D/7qMg3EMVoHHc35AR57Gq9WSmKaMKRFZ2CveDQifRj
u7abTH3IKX+5Nn8FvvLSmXbs+ONbsvw1ubLqdmG6ovyl/qVHYkUzln/nicxbDWZfukCz17PsdSfw
udTdiP9rB+b9+4//zUShdIf+97yU7SgbQlZ0VC/xW6lSy7JvEPzx7aDdsSiQrFCJmfLTmrWq6tQZ
fe4vOIrO3SOoAe2pFJy1OzF/wXqf3nMKaW2g6IpyiV8cNbJfOZkd9IUlxJZG23xHtSE/Z77PrvBv
iIbkl3mBLesYvgrdPfUHzXxezPdaxbgyX2U1Mbs0FdHa9QT9tp5Z8B1Y1GdmBNE1zYUFfDQpxu/b
5S+vSP4KvCmkf7W7Ej8W3Nt3gDDfdMq801eGr/eOU3aJ3yaXkmezXbUyI7nFAnv3LfpeBBlCJ5pf
2hElli4q2/eaJeSvyPsPS8z3ltYdiNzba3TV/MToEH2W6kXfN4J87dGLrZtAVTEn3RrdTVof6dNW
1u4pP6elPEdkh62Qtq576Af1O/p1azeg4J0e3VZ/VE7K3/45M2bD4/HL0Xkl7SpHdhSPCdtT+i5O
RQ/7jkwUmfVezCf2Yn60Uq/6A4n0DoSZPePz9I32/mNIwHLdVc8z93quflF/Z1bMbdwLRWivyQ8v
F0cddB/9qL46emd9kMBe1v+2nqz7Qg4mYLY2EyOvSTFdf6o/iY7aZnU+kRrbPedBurcNi7yP+Drm
1a+Z9jBWEgreAiqyFqQP53/NXy5+X9HvQlf7V/RugS17gsX5BbYOzO7rhzpbf2UTRL7aj75hEJXi
c8pf6l91/E++xi5eyoZ8xIrsO/9VR0X2qdDSO6nQqkOBhYSyjD2Vyby/c731V6dm0D3TbN5NmHVs
sqNJNfqbXoYeas41eq0+H/2lF3k6Mq5H9VT0zohOVTV6/1F0p4JTwRfTNvz9EzyHfbdCD8Y4F12B
1Bfr7nBt9Z1UWUfG4HwbGkPhLtMX6I46+mWD/kH/bt+WMD12G8akDVH99XRqaEfO022qE69ulMzX
G3oyru8W3M80ulyRNytuiHo609/pPGpq7cTUszGFnz2U96sO5x20I+Vsfa/+2Ixheph+3PhAdWSR
YiPvgN1bAX576/vx/PfbGxe+3hY3H7cj9WK0ZWZe5Ev6GdYqSP5ha1b3i9Iog45XYtlbS09TLM8O
+0aAmSdYabLS/C3upY32TjjfMbli6UJwz2lJKXbsOkXt2D1GVzHOqlBPa51ukLVON8JapxvJOrGu
NIbdze6mF61dupfYADaSXmaj2HiaZqzT0UxjnY5mGet0NNtYp6Mv2FdsIc3ljXkTWsCb8ea0yFin
oyW8FW9FS411OlrGr+JtaQXvy/vRKj6IP0S/8zH8BVrLp/AplM7f4dMog0/nM2g7/5x/Tjv5bD6H
dvFv+Tzaw+fz+bSP/8IXUDZfxBfTAb6EL6FDfDlfToeFJ3w6IuJEPOUaC3OkrYU5shbmAqKuqMuU
tTDnWqtyYdFcNGe+tSoXY63KxVmrcvHWnlxl0Ul0Zgmim+jOEs23cizJWH1jKcbqGztLzpBzWCdj
9Y3dZiy9sTuMpTd2ZyAuUIn1CiQEktndxt4buz/we2ADG2jsvbEhxt4bG2rsvbFhxt4be8TYe2NP
BvYHcthTxsYbe87YeGPjjY03NtHYeGOTjI03NsXYeGNTjY03NsfYeGNzjY03tsjp6jzJVhjrbpwZ
625cGutuPGCsu3FlrLtx15nkTOYxxq4bjzd23XhlY9eNVzd23XgdY9eNN3DmOyt5I2PRjZ9vLLrx
Fk6ms51faCy68YuNRTfe3lh049cai278HmPRjT9kvo/jw1zucj7cdVzFH3HDbpg/5sa6cfxxN8FN
4E+4SW4yf9Kt4dbgI9xabm3+tLG4xp8xFtf4KGNxjY92m7hN+PPG7hofa+yu8ReM3TX+ktvavZiP
N3bX+CvG7hqfYOyu8deM3TU+0dhd42+6d7q9+GRjd42/5fZ3+/N/G+tr/F1jfY2/Z6yv8anu0+7T
fJo7yh3FP3BHu2P4h8b6Gv/IWF/jHxvra/xzY32Nz3I/dufw2e6X7hL+g7vcXcF/d39zV/O17ho3
k29wt7r7+A5jlY0fNFbZ+CFXBxk/bKyy8VxjlY0fNVbZBAsmB1OFb+yxicrB2sGGIiF4evAsUS3Y
NNhU1AyeEzxHpAXPDV4gagVbBi8R9YNtgm3EGcHLg1eKM4NXB9uKxsH2wQ6iafCm4M3inOB9wb7i
3FBaqK640Fh3Excb627iKmOtTVxtrLWJB4y1NvGQsdYmHjXW2sTT4RvCt4up5qs9MctYaxPfeMqL
FT8bO21imdfZu0vsNnbaRJ6x0yalsdMmlbHTJkPGTpsMGzttsoqx0yarGzttsoax0ybTjJ02ebo3
xZsqzzB22mQzY6dNtjB22mQrY6dNtjZ22uTFxk6bvMrYaZPXGjtt8jpjp03e4G3w0mUnY2VNdjFW
1mRXY2VN3masrMm7jJU1ea+xsib7xPAYV94X48XEyAEx8TEJcpCxrCYfjjkYc1AOi6VYJocTZ+lA
vRhofLEUR4wq4RQUj3FYUhLG7gBG9XoIr49TUQOMgi6dAZQMAg8vIA94aP7n4SL7DxgGMWMsYsYC
MW9ErptwVgJudgXFbnQ7taaewNCLgaF9MXPoh/MS6k+DqAo9hDORBtMwlDwcCJsEhPUomfkshlLs
F8LVWBww90xgbgOENGQNqTFrxE5D+OnsdPjPABYnWyxuAizugOu1QOTLrL3QZNYVuNzU4nJTi8t/
Ay4PQfhQ9hQ1YyPYCNB8GkhdDUg9mpqzMewlOpeNA2o3sajdxKJ2E4vajYHa78L/HrC7MbB7HsaD
79h3dAH7nv1EF7KfgeYtLZpzoHkzXM8BpjsW0+MspnOL6XEW0xMspl9qMf1si+nnWUyvDkx/l2ry
9/h7VINP5f+hWnwaUL62RfnaFuXTgPKzcf0CWJ9qsb6uxfoawPpfcF0AxE8D4i/CdTFwP9XifqrF
/TrAfY/qCR/oX9+if0OL/g2A/kl0mkgWyXS6SBEp1MaMBPBjJKBGGAka4NpQNEIujAd0hhkPkKuF
aIHrBeICxLYULXG9SFyENBgbcMXYgBDzrfUV9lvrK+331VfY76uvtN9UX45xYjhdJB+R/4+y84GK
6jrb/Z7DnD0HOIAiUURCDCGEIKEECaEELRJCrbGEEmP8rHUGGGYGGIZhmBmGYTjzl9Faa421hlhr
rLHWWmuttdZal7V+1nqty3KNtdbPGGr9rLV+1lprrbHmPvsdYm3Xumvdm6z9zF7v2WefPzNz9u9h
ycMypsNqsZpl6N/Qr2Mf17+pH2GT9G/pN7Jq/dv6r7Mp+s3677Cp+p36H7AcrCg/ZOUiTZRViHWF
1Yh1haliXYFOkCewOfJEeSJ7VqwurByry2mWJP9K/hWbLp+Rz7AM+dfyr5lePiv/hslYdc6j8p78
HioX5AvMIL8vv88UeUweY4/Iv5V/y1LFmsTSxJqEkVfkK2yi/Af5DywTK9MfmU6+Jv8Pjnhd/hOb
JN+Qb7ApYq3CEf8q/5Vly7fl22yW/Df5bzi3O/IdnM/f5b+jf1e+i/4H8gdstvwP+R+Y+T6X2CSe
xPVsNpe5zHRY4QwMiwVXWBpP5iksg6fyVJbEVa6ybJ7G09gsns7TMQaroPir7nwS9s3ij2DfbD4V
43P4NJbJc/mjmDmP5zGRgPo4NJ/nY4Yn+BMYX8ALMP5JXoTxT/On2RRezItRn8FnMD0v4SUsnT/D
SzH/x/jHsG8ZL8Nsz/JnMaacl2PfmXwmU8WKi2M9z59HvYpXY+QL/AXMUMNrmczn8JcwsoE3MAP/
JP8kzvkV/hlcVzN/DfN/jptw9BbeiqO0cQvmsfIuVsvtvIfN4U7uxhE93MvqeD/H04MPcD+bzAf5
IM42wDVcS5CHME+YhzFDhEcwQ5RHWSqP8RiOMsyHMSbO4zgKCIBNEwTAykAAb7AKvoavYTMFB7Cp
4IA3sXWEj7Ac/hbHc4B/lX+V1fANfAPu9ia+Cfp1vpmViwxYjAcrYIZv829Dd3B8SvlOvhP7fpfv
Yi/x7/HvYebd/PvYupfvxb4/5D9EfR/fj5E/5gcw8if8ELb+lB9mlSCMo6j/nP+clYIz/hfGH+fH
UfkF/wVGnuC/xMhRPorz+d/8FMa8y9/FGZ7mv8I5n+Fn2DP81/zX7Hl+lp/FvmAU7HWBX8DM7/P3
sdfv+e8x2xV+FeP/yP+I8X/mf8WY2/w27sbf+N9wbnf4PTZVcAybCY5JQz/dMJFVGDINk9g0Q5Zh
Cqs0ZBty2fOGRw3T2bOgnKdYjaHI8DT7lKHYMIO9YCgxlKDyjOFjbJahzFCGGZ41PIuR5YZyjJlp
mImtFQZ4R7DRx9lzhmpDNY71guEFjK8x1GDrLMMsHEtkCugEM7FywUxQMBMUzAQFM0HBTFAwExTM
BAUzsRzBTGyaYCYomIk9I5gJfTATqxHMxKaKrFpWqsxR5mAvkBMqICeMATlBQU6sUpATex7kBCeg
WBUrmwV+6mEZilPpxRhQFPYFRaEOisLIkBLCPGEljH5EiaAOosL5gKgw/kvKl1iFslpZjb3AVWwm
uGodKm8q+NQpI8pX0f+m8k0ca5uyjX1KkBYqIC2WIkgLCtKCgrSgIC3oH5Q/s08oN5WbOMpflL9g
HlAXKxPUhf6Hyofib28lM/ZSsi5Zx6YKAmPTQGAGqJKssOeS8R8rS05JTkFfTU6HZiRj/U2ekDyB
VSZPTM5EZVLyJFaTnJWcxWYmP5L8CJuVPDl5CupTk6eyiuSc5Bz2TPK05Gno5ybn4iiPJj+KrXnJ
eaiA7dAH2+FMwHZQsB0UbAcF20HBdlCwHRRsBwXbQcF2ULAdFGzHUgTbsU+A7V5lE1IWpCxgPOW1
lNfQX5iyEP3XU15Hf1HKYpYlyA+VZSlbmJTyjZQd6IP/0Af/YQz4D2P+nqpjUqqUmsNeFBTIqhLZ
DYICmSQoEAoKhH5W/Sx7VF2iLmHT1c+pn2MT1aXqUvaYalSN7AnVpJpYvtqitrAktVVtR9+iWjDe
qloxxqbaMKZL7ULfrnazAtWhOjCmR3VijEt1YWuf6mZ5IMt+1H2qD3XwJTSgBqBDqsZy1aAaYo+r
YTWCkVE1ipExdRhHXK5+AZWV6irMDAbFUdaoa6BfVtdizDr1TZzziDqCed5S16P/VfWrGL9B3YD+
19SvYc6N6kZsfVt9mz2lblI3sacFubIikOsWNkP9hvoNVq9uVb+F/nZ1O8Z8W/02tn5X/S50l/o9
VqLuVndj6/fVPdj6Q3UfK1Z/pO5H5cfqj1EB70LBu9CfqofZk+p/qkcw5mfqUVao/lz9OUYeU4/h
KCfUX6Iyqp7CnKBhzH9GPQP9tXoWY86p/4Wt59XzmOc99QL676vvswpQ8m8x20X1IntKsDLLAytH
WG5aNC3G8tOG03CXwM3LWUna59Nwr9JWpq1kj6V9Me2LqLyRtobNSPty2pdZveBpVMDTrETwNMsS
PM0kwdNQ8DQUPM2yBE+zcpBdLfF0A/G0RCSd4OaPiFnwcTrxcTr7D/yfTmQ8l8h4HpFxJpHxfCLj
yUTGU4iMs4mMpz6U3yNTfo9C+T0y5ffIlN+TQvk9MuX3yJTfk0b5PTLl98iU3yNTfk8G5ffIlN+T
Qfk9MuX3fIrye16m/J5JlN/zacrvaaT8nlcov6eJ8ntyQOqp4OY0XRox+lT2nC5HlwOGFqReBVJ/
hVUTi7+qe033H6gLFn9BZ9FZQNgenQfq1fnBzQEQ+fMg8uVsFlj88+h/QfcFjBdE/jyI/E1WCxbf
wOaAwvdAf6D7AavT7dX9BFsFhb9OFP4iUXg9UfhLoPAylkQUnvQQfyeBv18k/v4U+PtlonCRMKSn
hKGJlDA0kRKGHqGEoYnE6J8hRv+49HlpBZstkv3ZgnFSF1w+Q/qu9F32tLQPXP4EEfmTRORPSb+Q
fgH+Fiz+uHRKOoX6r8Dfj1Nq0aPSb6T3QOTvS+9DRYJRCaW6FUuXpP9G5ffS76Ei2y2Pko0KpP+R
rqMv8o0KpT9LN9EXKUdF0gfSPfRF1tFj0n3pQ5ZHiUf5SbokCX2Re1SYJCfJ6Iv0o3xKPypISk1K
RSUD9F9K3F9O3F9B3N+cNC0pF3VB/6VJT4D+P5ZUCPovJfovSypOKka/JKkE+mzSTDYTTuB59KuS
qtgzSR+HHyglP/BsUg38QGnSJ5I+gfmFHyglJ/AaOYGF5AReIyewkDxAA+h/HUsH929kmUT82UT8
04j4q/R7QfwvgPiPsFn6n+lPsDri/vqHMplkymTKoEymSZTJ1EROYB45gTmUz/Qy+YFq+IF3GScP
YJB/Aw/AyQMYyAOkE/0biP6z5UvyJVD+Zfn3qAju50T8U4j45xHxZxLxZxPxT5VvybeggukbiOkN
xPSZxPQNxPQS52B6A9G8gWh+KlF7A/G6gUg9k0h9KtF5A3G5gbg8m7i8ASwO38tLQeScWDyTWLxh
nMIreAXGV/JKjBcs3kAUnmBuA3G2gdh6LrH1PGLrTGLr+cTWk4mtpxBbZxNbTyV6nspX8pVgyi/y
L4ImBT1XEzHX8HV8HeqCmJ8jYp7DN/KN4EjBypV8M1i5hlh5GrHyLL6VbwfHfxuUPI0o+VXi41l8
D9+DvQQlVxIlvwpK3od9fwRWnkasXEWsPIv/Jz+CGX7Gf4bxgpUriZKnESVXESXPIkqu56dAyTVE
yXOIkiuJkmcRJdcSJb9ElPwcf4+/h62CjxNk/By/xm+gIvi4ivi4mvj4VX6f3wehCjKuITKeBTKe
gr5g4lpi4jmGxw1Psjoi43oi49eJjF8kDp5DHPw6cXA9cfA0w/OG56GCgF8iAq43fMLwCcwpEsUy
KEtMpiyxDEoRy6AUMZlSxFIoRayRUsRkShGTDc2GZhxdZInJlCWWQSliL1OK2CRKEWuiFLEcShHL
oRQxmVLEZEoRkylFLINSxCY9lCKWQSliKZQilkEpYjmUIiZTilgGpYjJD6WIyZQilkEpYjKliE2i
FLEcShGTKUUsg1LEch5KEZMpRSyDUsSaKEVMpvww+aH8MJnyw9IoPyyD8sNkyg9reig/TKb8sAzK
D5MpPyyD8sNkyg+TKT8sg/LDZMoP+xTlh71M+WGTKD/s05Qf1kj5Ya9QflgT5YflUH6YTPlhL1N+
WCPlhzU9lB8mU35YDuWHyfAwk1g1HMuTbA75kzrlKeUpeIMipQisP0OZwaqUEuUZ+I1SpRT1MqVs
3LdUKuXKTPYSuZdKpVKpggoPU6+8oLyAeYSHqVMalE9C5yovY7b5yqcxplFpZM8pr8DJzFKalGY4
hNeV17FV+JlaxagYcT6tSiv2SiQxCodTD4fTiWMJh5Ou9CouzNOn9GEvj+JhLyr9Sj8qQ0oQVyF8
TjV5m2mU3FhJDqdGWaWsggqf8xL5nBrlKwqeEuRzKsnhzFLeVt5G5R3lHRxduJ16cjuvK99StmMv
4XlmKd9RvoMx31V2Qb8P55OqXFB+B/1veJ5U8jyfJM9Tp9xSbmFm4XmqlQ+UD3B1wvOkkud5lTzP
HPI8NeR2KsntVJPbqUxOg8OpgcOZyGrJ4dSTw3mRHM5LcDiT4YKmJGdj5FQ4nCryNtPIz9TBzzyF
oxTDz6TCz1RAK5OrobPgYVLJw6TCw7wCFe4lldxLKrmXT8K9LBh3LMKrLIIPWUyOZUnKElTaUtrY
7JTOlE6oPcUOdaQ4oM4UJ9Sd4oaKLLqJlEU3kbLoHqEsukcoi24iZdFNJOeTRN7mM6nTUvPZx1Pn
pX6GzU41p/rZAkqq05Pb0cPhzICLEB5mBnmYp9V2eJjH1Q61E6QufMvj5FhmwLH0oO9Ue+EcvKoX
FeFVnlAH1UFUhtQgXIrwJ0+SP5lB/uRp+JMVqHwBLuVpcilPqV9Sv4Txwp/MUL+irsPWN+FPnoI/
eQuzCX/yJPmThDN5gpxJqfp19evQd9R3oMKZVJAzaVa/BWfyLJzJDtS/o+5kZeRMniVnMpOcSQWc
yfdR2aP+gD2j7lX3YuSP1B+hLvzJx9QD8Cel6kH1ILYegTMpI09SQZ6kWT2u/gJbT6gnURfOZKb6
rvouRgpPUqH+Rj2H+n/Bk8yEJ3kPs12AM8kjZ1KmjqljOK7wJ+XkTz6m/k4F41E6YAnlkRarV9Vr
qIikwHz1unoDfZEXWEh5gfmUF1hCeYH5lBf4GOWR5qn/UP8BFdmBJeqHKgiQEgQLAOYgQMoRfIyy
SfMoTfBRyibNo0zBQsoULKFs0uK09LQM1EW+YGHapLRJqIiUwSJKGXwsLTstB1tF1mAJZQ0WUtZg
EWUNFqTlp+Vjq0gcLKTEwXxKHCxI60zrZI+TE3sSTixMTgyfh7Rlacvg0JbDfT1J7msm+a5m+K6v
oL8ubYSVkfuambY+bT36IrmwkJILH6XkwhJKLiyi5MJCSi7UM920m7khwK+atIK9z5hpMZoJzYJm
R3Oh+R686pzb8aqhxdBWoK1GW4e2AW0z2ja0nWh70PajHUI7inYC7RTaWbQLTAodp8ZMl6hJoVG0
M+hfRbuBdhvtHmMtEpqClo6WhZaDNj1xDi2F/5fXksRcLeXjTexThTabtrGWerR5ifOlfTYnrrGl
CW0h2pJEffxVCp2npnPuQtuL/sUHtUS7gnZ9vH8G7dZ4/26ihdl442gqWiZaNlpeYmy4gMazllY0
W+I+tTge3PPE2GIax1rcaH60EFp8/BpWJo4XLhu/1jVoI2gbx7dvGd9eOd5qUMP72CKu5wDa4QfX
krjmvWgH0A6jHUM7iXYa7RzaGNrl8ddrD71+NP4m2p3x13Pj+915aPt9xlr1aCloE9Amo+X+81W8
f635aEX/z69SuO6f75W4ttbS8ff6/7fl/Gujz/eKxHHoc5WTGEfHfbhVoFX/8/XBHIl5pfBc1GvR
GsY/f9jWOv+fr63NaIv0E5eOdc8bGjXFehgpJ1WhK3oyoat7sqHrevKgG3oKoJt7iodGxV7BJaZt
PWXB1qWXu5uGziy91r1w6LxpZ08lac2D/p6euqHzYmvQtvRm95Khi6b9PXOHLib643qnu3XoiulQ
TyPpAuhR6h+l/omexdBTPSbo2R4L9EKPfeiK2CvogNrQv9/tGLpuutTjgl7t8UFv9GhD10U96Dbq
u91Dt0y3e2LQez0rgn5jSrd/6G6L1LOadB3pBqjSUg9N79kMzerZBs3p2Qmd3rNn6K7YKxhqKezZ
r20wTugOabizPYc0ZpzcHde40GDcmNu9UlNbynuOQqt6TmiqqARXJurjmt+9Rss0FnWPaNkts3tO
PdD6nrNatqgH14xrafdGLa9lXs8F0kvQJuov7LkKXdJzA9racxtq67n3QB1OKTjS4nYqwY3Giu4t
WkGL35muFdBsxeOVkDPrIxWV4BZjdfd2rawl7swhnf5RX9SD24213bu0ypaVzkKtUvSDu4y1zhL0
G7r3ajUta5zlpFUP+iPO2dCNznroFuc86HZnE3SXcyH1l2g1Yt/gXuP87gNanbG5+7A2t2Wvs/WB
HnC2Bg+0HHbatLnGRd3HtEbj0u6TdA4OUveD/jGnH2di7j6tLWg56Qw90NPOuLbA2Nl9TlvccWgg
RBonXQk9OrAGemJgBHpqYCP07MAW6IWB7dpisdewv+PSwK7hkNHZPaaZjN7uy5ql4+rAXuiNgQOk
on974LBmEVuH48ZA9zWNd9wbOKbxTqn72vDKhBoj3Tc1e6cycJL0NDSd+unUzxo4B80ZGINOH7gM
LRy4ptnFXsNroHfQX959X3N1lgzchJYP3IFWDaAi6sMjxlUOvebrnO0XWu9PGd5oXOtI0bTOef4J
Qjvj1J8MbfLnQhf686FL/EXQVn8p1Oav0DSx1/CWToe/eni7cb3xohbrdPtrtZhxk2OCtkJouMC4
1TFZW93p9zdAQ/752mpRGd6VqI/rDkeuts6425GvbeiM+5sf6Er/Inx3UB/eO677HEXa5s41/qWk
5gf9EX8ndKPfCd3i90K3+wPQXf4IdK9/+fCBzgP+VcFW40FHqbat87B/7fBhmm3neOWYfz30pFBR
GT5mPOKo0PZ0nvZvIt36UV/Uh08ajzuqtf2d5/w7tP2iP3y6c8y/e/iccdRRqx3qvIw7D/Xve9C/
5j8Ivek/Ar3jPw697x/VDnXp/WegKf7z2iGx7/CY8YyjQTtqPO+Yr53omuC/+G862X9FO2G86GjW
ThmvOBZpZ7ty/ddJbz3o5/vvameN1x1LtQtdRYPsgZYOcu2C8ZbDrF1qOedcSboGOkb9y84R6DXn
RuhN5xboHed26H3nLu2S2Ct4uFXv3Bs8Zrzr6NSumpjDqd1oTXEegE4gnUya6zys3RBbgydN3OHV
bpu485hQ0W/Nd54MpptUR0C711rkPE167t/6pc4xaIXzMrTaeQ1a67yp3RN7BU+bMh2RoGTKdiwP
Kq0NzjvQ+c770OZePXRRb0pQMeU5VgXTW5eSmnsnBM+ZChxrg1mtnb2TSXNJ84NZpoLeIvSdvaVQ
b28FNNBbLeoYP9Ya6a1FZXlvQ/CyqdixPpjTuqp3PnRtb3Mwx1Tm2KSdEhq81rq+d1HwpqnSsRXj
N/UuxQyVvWahqIwl6uNa49gRnG6qc+zGuW3t7YTuIN3d68SdEfU7rft6vVg9qW+a69gXLGw92Bsg
jTzQI73Locd7V0FHe9dCz/Suh57v3QS92Ls1eL/1Su+OkB7zHAyWmPJ6d0PrHEegjY7jOM/rvfug
t4RSZcy0wDEaLG+923vwX1XUQ7CtvUeChW2893hogmmx40ywqk3tHQ1WiX5osmlxLyomk+M8XVdC
L37Ub8vsvQLN7r0Ozeu9BS3ovQstdjFomYvj2sW+d0wWx8XgbJPdcSVY31bpUv9Na1yZwXqTy3E9
OM/kc9wKNrXVOdcIdWU/0LmuvGCTSXPcDS5sa3QVQBeQLnYVQ02uslCuYJJQfpvFVQk+ARuEitrs
rpqhK20uVx3U55qbWMFDpWIdDFW0aa5GLa8t5lqg5YmVKFTdtsK1WKxKLhMUa02otm21y6JVtq1z
2bG+4PsSamjb4HJpl8TnNjS/bbPLp91r2+bSoDtdscRnLNQs3t/QorY9rhXBQtNc12oo7kNoadt+
1zpxT1wboIkrPeTaDD3q2hZsohXnclfFoIrVRzz5r3VVD2Zq9q7awWxow2De+PP5pnjKDd/pmj9Y
oG027hsshornzP2u5sEy8cwZrITiSRLXdy0arMHTY+lgnXaWPvljbSdcO0PmtlOuPaHOtrOu/SFn
2wXXoZC37ZLr6ND5tquuE0MX2264ToUCGHMWY267LoQibfdcl0LLzZLramiVWXHdCK01p7tuD103
znfd0+rMWX1SaL05p08JbTIu6kvXGs3T+7JCW41FfTmhHcbSvulanrmwrzB4zFzSVxLabS7vKw/t
S/CGuaqvKnTQPLtv9tCoIIrQEXN9X33ouHle3zzxLvQ1fbSym5v6FpIugS7EuY2al/S1hs6YW/ts
ofNmW58jdNHs6HOHrpjdff7QdbO/LxS6lWDaFqkvDopLcBRRijnUtxLsStxojvetga7sGwHFic/G
3ZbWPqh5Td+WMDOP9G0Pc/PGvl1h1bxFjDTq+/YO3TJv7zsQzkyQm2lD3+GhUfOuvmP4jhOjmvf2
nRy60pLTd3rorvlA3zkc3dY3hvtwuO8y9FjfNa3AfLLvJhhse98dnM/pvvvQc259aJXptjsF84+5
J4SzzZfdk0Oj4g6E88zX3LmJz3a4wHzTnY957riLtErzfXdpuLhd764IlyUIsz3FXR2ubJ/grg3X
iO9FuK59srsBlA5WD89NaHuue36CwMOND+kC0sV0FBOppT3f3Tx0pb3IvWjoenupe+nQLUHUYXt7
hds83neR+sT3K6yN30nwcDhGukKcVXh1e7W7M7w60Sdd117rdmqZ7Q1uL3gYVBze0D7fHUgwcHjz
Q7oNpOrWCtqb3RHoIqGCWsM7E9q+1L08QarhPe1m9yqtrL3TvRaKOipO9/oEtYZq/6nh/eJbHz5E
ejSh7V73JrAoiDR8oj3g3gryBJeGT7VH3Du0xvbl7t1Qp3sfmPOk+yDYUrwvZxPavsp9JHyhNd99
HN9u8WROb1/rHsXqme8+g/569/nwJVOe+6JYEdxXwlfbN7mvB2+2b3XfCt9o3+G+G77dvtvDwvfa
93l4RBp/ttPT27TYo0aU9oOeTDyNfZ7sSHriSdh+xJMXyWo/7imI5LSP9jZEpref8RRHChMM0Nrp
KcNaQKtM+3nx3E6s0e0XPZWRkvYrnppIeft1sdq23/LUYdXDUytS1TrqmRupar/rPB2Z3brW0xjM
sTDPgkjO+Lq81bM4mG7hHpNgCY9Fu2RRPXaxpntc2j1LpscXzLJkezQc97wnJtYvD56BljzPatQL
POuCWW1lng0frRSWYs/mSL2lzLMN5waWCGdaKj07Q6Pi6iLzLDWePYknbfC0pc6zH/PM9RzCKoA1
N9JkaXTsjiwU61RkiWWB52ik1bLYcyJis5g8pyIOcd8ibprHb7F4zkZCFrvnAjwOnuGReIJ2hIaW
JvQjqnF4IyuFJiqRNaQj4hwiG0m3WFyeS0HJ4vNcDSoWTdCIIJPQUkvMcyPRx3oHxV5YCyLbxVM3
st2ywnM7wRWRXeOKqwg1W1Z77mG9oD5d13bLOq8UnG7Z4FVAFOCKyF7LZm96giJwVg80MtK61ZsV
LLFs8+ZAd3qnJ1Z8zAONHLDs8RYmVvnIYct+b0mw3HLIWw5FHZWj3qrEKh859pCeFOtU5DTpCOk5
ywnvbKzdWMEjY5ZT3nqs1FjHI5ctZ73zgvMsF7xN0EvehVjFGr1Lggvpnl8jvTl+Z656W4NVlhte
W7DectvrCDZZ7nnd2iWr5PVH7nSZB+fGU7o6BxtjjV3OwQVQ7+BibXVXYNCkWboigxaNdy0ftMcn
YIwLW1cN+uKTu9YOati6fjAWz+3aNLgint+1dXA13NCmwXXaiq4dgxviRca1g5s1rWv34LZ4ade+
wZ3xiq6Dg3vi1Vgx92ubu44MHoou7zo+eDRe2zU6eCLekHAHxuODp7T9XWcGz8bnd5337443d10c
vBBf1HVl8BJ83JXBqw84/PrgjfjSrluDt9G/O3gvutvOAlLcbOcBJd5pVwPpcac9M5AV99qzAznx
gD0vMD0eSTjQznmBQniuhNMhT2EvCJTElydcnr0YFZe9LFAOz4W1Pr6qc0ugKr6qqygwO77WXhmo
j6+31wTmxTs7S8RI46pAk+az1wUWxjclfFbHocCSj/xswmPa55KvnNd5WTi+QOuDo28P2KDkleyN
AQccU8Lj3IfHPGRfMHgjXNM5O+DG/IsD/vhWuykQgs/CHYjvsFsC8XFWWWO3B1Zqm+2uwBrtrN0X
GInvtmuBjfF9CT9ojwW2xA/aVwS2x48Izokft68O7IKnhrOOj5Kesa8L7MWqAQeN9QIaPy80SJ46
flEcJX4lofYNgQO4os3wXC77tsBhzSf8b/y6fWfg2Hj/FuldwUvL2PidhHtdxscVZ7VMte8JnFym
Jvqkmfb9gdPaOvuhwDm4V3jYZdn2o4GxhGNdlveQFnQeC1zGHTsRuAY9JVR4zNCihNrPBm4mfOWy
YvuFwB1tj/1S4D4UdVSuDukTHnNZ2UNaKShuWQ1pXULtN4ZS4BzhH5fNtd8emgCfCBe5rNF+b2iy
dqpbGsqFKkP52tnu9KGi+FLxvixbQLrYuGqoNH69O2uoQtvfnTNUrZ3onj5Ui5GFQw3aYqviDUXu
k3eg9YieXfAs1nRvPKq3ZnlXRlNM3LsmnGnN8Y6ItcO7MTrBOl0o+luik62F3u3RXOiuB1ri3RvN
t5Z7D0SLrFXYS0l4Outs7+FoqbXeeyxaYZ3nPRmttjZ5T0drrTni+Ul6x7rQey58Qzwtow2k81sj
3rFglnWJ93K02drqvRZdZKr03gyOWW3eO9GlVof3ftRM2imek1HnuLeCRr1Wd78+Gkj4LKu/PyUa
sYb6J0SXW+P9k6OrrCv7c6NrrWv686Ej/UXR9eKZGd1EutW6sb80ugNaEZSsW/qro7ut2/tro7sT
a4p1V39DdJ91b//86EHrgf7m6BHr4f5F0ePWY/1LwzX0FFWsJ/vNmsV6ur8zOmo91++MnrGO9Xuj
5032/kCw3nq5PxKcbb3Wv1zbk1ihhEYvmjSshuj3r4r4E+TWPqF/bfSK9Wb/+uh1E+vfFL1lvdO/
NXrXer9/R+S+taR/dzTfpu/fFy21pfQfjDHbhP4jMW6b3H88ptpy+0e11bZ870gs8+HZbEX9Z2LZ
ttL+87E8W0X/xViBrbr/SqzYVtt/PVZma+i/Fau0ze+/G6uxNftYrM62yMdjc21LfWqs0Wb2ZUI7
fdmxzHF1+vK0SzavryC2wBbwFUcjtoivLLbYttxXGTPZVvlqYhbbWl9dzG5b75sbc9k2+RpjPvH+
xjTbVpMvFrPt8C2IrbDl+vDMt+32mWKrE++dbZ/PEltnO+izh1bZjvhcsQ224z4fdNSnxTbbzmDX
bbbzvhWRLNNcHxyW7aJvHfSKb0Nsp+26b3Nsj+2Wbxv0bn91bH8H8+0MX+jgvj0a71B9+2OHOjJ9
h2JHO7J9RzV7R57vROxER4HvVOxUR7HvbOxsR5ljNFzTUem7EK3uqPFdil3AyKsYWee7EbuUOErH
XN/t2NWORt+90GjHggEpdsPEbUXa7Y7FA0rstqlmID04vcM0kBW712EZyBmWOuwD04eVDpctMKyY
Fgxgde7wDZQMg+UGyoMLO7SBquGsjtjA7OGcjhUD9cPTO1YPzBsutJYPNIVvCB0uSbj+jnUDC4fL
OzYMLBmuEvQyPFtQynC9+CnK8LzEN45+grFy/CcV//rtODj+swL6ycBwU8fmgdZokVjfhxcKDz68
RHwah1sTPx2i58Odjm3eEcxPJNaxc8AWPG0tHHAET4//9IZ+rtKxx+EctllvDriHHQnX37F/wD/s
Fu91qJlJbIruhu7PjOn+qrvNJN1d3QdMr/tQ0jEuyRJnyVKqpLJUaYI0kaVJj0iTWYaUI01jE6V8
6Qk2SSqSnmaPSF+TvsamJM1N+hTLlhvkT7Ic2SX3sVz5p/JPWV46/mePpU9P/zSbnt6UvoQ1phvT
h9ln099I/wmLpB9Lv8a+l349/TY7g7P5DNPTXz9IZxksmU1kC1gqW8ha2SvMzL7AlrAvslUsxlaz
d1mc/Yr9lh1nv9OlsF/rVF0a+1CXoXtEp9OJ33FSxL+b1E3RLdZZdbm6Dl1cV6xbrlurm6sb0X1N
95ruB7pf6j6b9J2k7+i8erfeo+vXh/QR3YB+uf4LuoD+Df0bupD+Tf1burD+bf07uph+p36X7vP6
vfof6Vbqf6L/iW61/mf6n+veoN/HXKs/pX9X96b+gn5M95b+sv4Pug36P+n/pNuk/6v+b7qvi39F
p9siT5In6b4pvyvf123jMi/QneZP8ad0t/jTvFT3V/48r9Z9IH7DQ/chf5HXS3rewD8tcf4KXyKl
8xZulnK5hbuk6dzDNekZ/nm+Snqer+YbpFn8bb5Vmid+c0Jq5jv5L6RX+Ul+Uurlo/ys5OLn+Xlp
kI/xMSnAf8+vSkPi32NJYf4XfkuK89v8vrTcwAxp0huGTMMj0tuGKYYnpHcMhYbnpF2GOQa7dMjQ
Z1gjXTN8xfCVJNXwpmFDUprh24adSZPE31VNmvJ/2Psa4CiuK93b86cxxmOZKBjLWJFlLMuyjLEg
RFGITIgQQvODTDAhRIGJpuevp2c0/2AewZglPIXwiEwwIQRjimJZRSEEE0KwAhizWCasnowJxphH
WIJZTLCiUJiVWRbjd87XPWIQckxq91W9qqROfV9f3b59+v6cc+7pZmbI+XXOTuPwnPacV40F/Hkg
Y3HOWznHjGNyjuecNVbk/DHnQ+NEa7F1m3Ga9YPb7jf+wfaftv808fflVNFMPFgU8LeNJ2zVYSWU
iWK1sfayGqiunXy0epQaUZPqvNpT6kJ1SbVa36LuUHep+6rb1QNql3pEPa6eUs86BjmK1GWOtLpi
Yt3EgLpaXaduVNvUrY6iidVkVSay8Quw8X8XkvSx9LEwkEXnCiOduw+fRBWGnxl+JiTDzw0/p3Nb
DS8Jo2G3Ybcw45OoFsMbhjeEFd8Eu83wO8MRMQifQR2MT5/eYfiD4Q/Chs+d3mn4s+HP5B38ydIh
Rsko9f2vwWajRQzFN8eGGYcah4p7jMOMw0Q+Pil6r7HEWCLuw7fCCozjjONEIb4Ddr9xvPErogjf
ihmBz2w8SP0fLA3BzDGL0H4xP7Q/dDB0KHQ0dCJ0OnQu1BO6FLqiitAl1aIOVoeow4ACdYRaGupR
R6lj1XHqBLVWdanT1JmqW/WpqhpX56oL1MXqUrVFXaWuVTcAreoWdbvaru5VO9RO9bB6LFvC09WT
6hn1vHqhT3rVq2FD2JoltnBeOD9cSLXFN0hDuJjaloXLwxXq1YyEq8LV4Tpilvpwo3ohHKC2kXBj
OBmeF14YXhJeRjqLwyvCq8Prwhtp/NJtqh41+Dvrd2FOhpEYxXASkygWDwmzKCPJEY+RWEUlyW1i
HMkgUUVyu6gWE/HpcjtFHf7e5Z3iG2KmyBWzSIZQ3JHFZ0SAJE8kRBLfuJyH71o+g0+U/4PIp3j0
nLhX/IjkPvETkgLxj2KT+Jz4Gcn9YgtJkXiZ5AHxG5IRYjfJg+KfxX7q30GSEvxv2A+LY+IdUSp+
T1Im3iV5VLxHMlJcFB9Q3y+L/xCPi2skoyWDlCPGSIMo9lXi8+NfotiXK8bh8+NVUoF0v3hCekB6
QHwV3/espmhYj290zhQ10rckt5gkNUqNwo7Pkjvw7U6npEqqcElNUpOYIqWktKiXviMtElMpdi4R
Myh6fk98Q/q+tEx8U2qRWsS38O3OWRRJd4rZUrvULjzSXulVIUsd0uvCJ/1W+q0ISP8idYog7DdE
UaBEqNZSa6lowqfzotbHreUihk/kJayV1kqRtFZZq0QK3yRK4/N3c6xu67fF01aP1SP+B63tWdEL
2x/LvyyhbCe0E/YSOgidOg7rOEY4Kb6utCt7lQ6lUzmsHFNOKmeU88oFpZf4asgQspLYQnmh/FBh
qDhUFioPVYSqQtWhulB9aHqoIdQYCoQioWRoXmhhaEloWWhFaHVoXWgjSVtoa2hHaFdoX+hAqCt0
JHQ8dCp0NtQduhi6HLqmNqsmdZCaqw5Vh6tFaok6Uh2jVqrjSWpUhzpVnUEyS5VVRY2qaXW+uohk
ubpSXcP/g6i50RykTfBbtln4fYWJ/2327SS5E1aeCyu/C1b+GVh5Hqz8s7DyobDyYbDyfFj5vbDy
4bDyAlj552DlhbDyIlj5A7DyEbDyB2HlxbDyh2DlD4tOklLY+iOw9TLY+kjY+mOw9VGw9cdh66Nh
658nWzeIsbDvL8C+vyjdJxWQ3bNlj4NlfxmWXYXvRzwBax4Pa/4KrHkCrPmrZM3fIR94RnqGfIC/
JTEJ1lwLa66Tfij9kPyBbdqB70c4Yc0uWHO91El2PFXqkrrE16xPWZ8S06wzrTPFU9agNcjf185d
mLuU1mkwzf3tQorNIrsrJ1QQqgjVel0doZ4wndDAdaa7lDGxsaHDfxlocyx+RKmMjVPGxyaETt4I
rlNqYrWhM4Tz8eMMxRFzhS78ZXAbZWpsmjIjNjPUex38tzIr5g5djblVQ/yUIsd8qvUvA21s8bOK
ElPVvJiqRGNxIB2bq+YTCuMRlIvj3WpZ/KIyP7ZAWRRbrJZfB/6uiF9WmmNL1apPQXX8mlqXMCnL
Yy3AytgqZU1srVqvgcs8NnX6dWCs62Mb1IbYBj4Cm2KtauOng9spm2NblG2x7WrgRig7Y+0ZvdlQ
9sT2qpHrUPbHOm4F0VnpNcrBWKdyKHZ4QByNHWNE5fR6hnIidvKWcDp2RjkXO38TemIXGFElsVy5
FOu9FUSj6U3KldhVRkjEDYAlbmVE0+nNfGyKpNpC7nhjaHDcFhoSz+uP6Pz0ttCweP6nIboovRM6
CuKFwIh4cag0XnYDRsXLb8LYeMUNGBevumVMiFeHauN1N8EVrw9Ni0+/CTPjDTeAx30LUJOJQSFf
PBBS45EBQefUeYlcdWFiKNrF48lbwtz4vNCC+MKbwPqWEJYlhocWx5fcCtQViaLQ0viyPrTEV/SB
z68mrEuUoLwxMVJtS4wJrYqvRn/7Qd2aqER5bXzdp0HdkRiv7krU3KBjQ3zjDWiNt90EvnZfwhHa
Et+qHkhMxbErMWOg/nwitsd3hNrju27C3vi+UEf8wE3ojHdlQz2SmJWJ7dmxOBMr+2Lc8YTcF4NO
JZTsONJnJ9nrmlmXzBydTUT75rY7kc7uE2JJM8UU8v3oci0GRFdq/gu/WhPPx75B9h5dT9iU3pOx
5+hmOtJ9+Lx6MTFfvZxYpF5LNIdNieW8v4QHJVZyPY8tnJtYEx6aWM/xNTw8sYnjZLgosTlcktjG
e0B4ZGInx3aMmew9PCaxJxOfw5WJ/eHxiYM87nBN4hDPRdiROMqxk3UCUxMnwjMSp8OzEufCcqIn
rCQuhaOJK+F0UvD8Yg/iuaQ5DM+nfVLfz8KLaP/R5zncTHqWJy2sA+dWJgeH1ySH8L7Tt9dmrVGf
Toa+p2T2Au4T743h9clh6NumZEFmndGeYz+tPfZl2vMwts3JEVwX3kZ7eKUG3q95fm+AQ9uXeb/C
fkz3yezFfATIfjC2fnss7kUI74wtYPAem9lXMwjvibUw+vZI3jP1vTF7r7xhj9T3yQzC+2kfpDXG
3kf7YfhgrJ0Bu+V9bo+GvphFCB9KluJ4NDkqfCI5FvUUP8Knk+PC55ITwj3J2vClpAv17MO8l7Df
kh+xP4WvJKdFRHImx6KIJemGX2T8QI+LsC3Sw3EuMphik+4jWC+KW3x9Jgbe5Fv9/KovvmT6Tzo4
bkaGJH285pFhSbXvem5P/hYpSMYjI5Jzud+R0uSCyKjkYsRwHg+NITI2uTQyLtmC6z4t/uj9ikzQ
43jGx5dktdH7jLH2i8d94+E4nMEn3esT4mmkVj+64lt5TH3oHyezYyXHx0yMzI6J1BZ6uA2fozmI
TEs4otvS+6M70wcZnNvweiOv2ZM+hDqKWZHDKVt0f/poJn+JHkyfiCxO7kUco7wjeih9GjkFxbTI
luT5yIJkeyYniB5Nn0NM4/2f8waOdSfSPbxHR0+nL0XPpa9E9iavRnvmiOilOZbolTmDY2LOkJhl
zrDY4DkFyMn0eIlrOTfT8ybkPJkchXXpOvhcbMicERwvuV99uV0mD7t0PQYDmRxGzz1YF+djsWFz
SjnfiRXMGZW5Hu1pPPib5gt+QmOLjZgzFnWcN2ag54k3oH8uqOd+N0Cf1/55XR84F8ugf16XydEG
yM1ipRo+NTfj3Cs7/+KcK5N3ZeVY3Fdcy230ObnJt8j/IjOTq27yK3dybSbHiviSGyJqspVjUaZd
JJ7cwnYdmZvcDnvKxAFuwz5H9ofj0mRHpCXZifKq5OHI2uQxRra/RTYkT3KMiLQmz8A+tycv3JTH
ECLtyV6A7JEBP+S41ZEy4NiZsmZ8kH0iciyVFzmZyu/zP45BZ1KFiDXnU8WRC6mySG+qnPeeDHi8
/IwF/6MxR66mKpoMqSropvjRZE1VY5x6+yZbqq4pL1XflJ+a3lSYauBY1FScamwqSwWaylORpopU
kvc/7IEcnygnaKpKzWuqTi3keNxUl1qCZxbaC5vqU8uapqdWNDWkVvN8NTWm1jUFUhv5OaEpmdrK
89Q0L7WD2zctTO1qWpLa17QsdYBzQI7/mdjctCLV1bQ6dQQgfbzPsG03rUsd53lv2pg61dSWOst2
1rQ11Y0YRuvYtCN1Eed2pS5Dx77UNY7lTQfSpqau9KCmI+ncpuPpoU2n0sObzqaLmrrTJU0X0yN5
fpsup8cgjvH4r6Ur+Rg1pcezPUQHpWuiuWlHdGh6anR4ekaf/VAOzvlHtCg9K1qSlqMj0wrq9Zgb
HZOORivTaawf+Ul0fHp+tCa9KOpIN/fZauY5ILNHUTk6Nb2c20RnpFdynTAIybbE1iLE3/8F5W/o
X1C6xcXr/w4g9wrVm+8t9BZ7y7zl3gpv1TSTt9pb560nnu5tkHs18RYyvI3egHxVE2/Em/TO8y70
LvEu867wrvau8270tnm3Tlvu3eHdNW2Pd5/3gLfLa9NlBXDEe9ybp8sp71lvt/ei97L3ms/kG+TL
9Q31DfcV+Up8I31jfJW+8b4aryEj1MLhm+qb4ZvltWrik32KL0rt0ugh94hb8jm+H92B3/Pf0Ua2
Pfm/5T2ok3xjCsldeA86BO9BP4P3oJ/Fe9ChIiAUcbdQSfLxNvRevA29D29DP4e3oYV4G3o/3oY+
gLehI/A29EG8DX0Ib0NL8Db0YbwNLcXb0EfwNrSMfK5TjBRdJI/jbWg53oaOxtvQz+Nt6Fjxnvij
+IJ4n6QS70S/hHeiX8Y70SfwTnQ83ol+Be9EvyoVSAWiGu9EJ+KdaA3eiU7CO9FavBOdjHeidXgn
asc7UYf0HekZ4ZKelZ4VT+Kd6FS8E/0a3ok+hbeh08nTfy2+Lr0svSxm4p3oN/FO9Ft4JzrbtNT0
feHGLw02mnaaXhYy+XWH8JnOmf4oAuS/vTSXkpgrFly3VQ+N2HPUc8Jz2nPO00NyyXOFJt4iD5aH
yMPkAohPVuW4PFdeQLJYXiq3yKvktfIGuVXeAhkhl8qj5LHyOMgEcK3sIp4mz5TdLGw3hkfIbh7V
7WYI7s8WY6A1eoish23FRPNfTtbDtmKBreSQpUwkG+J35reRdcwkG2L7uB32MRjvye+gcYXIktga
cskWniN7YjsYQlawieyJLSBPvETyWVjAUFjA3bT++8lu+X34PbTm75CF8arfi1Ufjnfg99HKnxcF
WONCKZfW+H6sbhHW9QGs6AhptuQWD2JFH6IVjYoSKU0rWoq33I9Iy2gVy7CKj2IVR+Kd9mPSr6Wd
YpSQrGOt47LWo9R0l6e0v8jz5IWeUZ6xGZGLPeN0mdBf5CWeWo9LE3mZZ5pnmryCavqJvFpe55lJ
4ibxscgbcVQ98YzIbZ65N4u8FRrmehboslgTeYdnqWepvIu45WaR93lWedb2yQZuq0urLlv6S3BL
cLtnu6c9I74Lnr26dPSXYLunM3Ov4F7PYZINVNNPvGM8vZ5jJHy/kyyBEtlGxzO4AuLtuVm7pyNQ
Aw0dmZn1nNck2OG54LkQbCXuvVmCnTS+q33ikg19YtVkgJk6IHfJNjmvT47I+ZDj12ciI/IpuVAu
zghW/Kxc1k+6CRflckgFyWW9/prXRFzVNyKXZ4F3kFx9s3hz5TrvULlens7iHS43aOItkiNU0yg3
ekvkxiw9feId6TkvB/okIiczos2+5yStCNm3txK2W+sd761hG/M6eCa8U9k+vDOoNAujLfPKXgU9
UjBWTRNbymGsUmfwWPAkrOEMZv88ZrrbGyXfGUXzN9Yzzpv2tHrn0yzbvIuof83e5WTLbu9Ksve5
3jWywbuebLmlsdm7Sa6g+y4nO1lMbTd7t3l3eq5693j3ew9Sj9n+W7yHMEo3rdgBz2LvUWrh8p7w
niZd7LUYEVpqvsKru9gzzXuO+t9DY75E9Uup3VjyuqXeK1Qa5Z3lE55xPotvsG+Ib5ivwDcCvjxN
E1+pbxT7q2+sbxzJBF8teauqeazP5ZuGu9GdfDM9i31u9kkfaaaWqi/um+tb4FvsWeVbqvsfe2Cr
r8Wnkq3ZYG/5dHaVXCdX+NbK+b4NvlbfFrnBt53Wl1bLu9zX7tvr66CZK5OrqU+r5C5fp+8wtT5G
clIu97XDAnmUWCtuR0IWw7PkO0M4L1eTD7f4eqk+6bvqN/hO+q1+urc/z5/vL/QX+8torhV/Odu7
v8Jf5a/21/nr2cZpZrHm/uneErK2Cn+DT/U3kgT8EbmKhc4l/eX+eTSCOnk6nVkoN/iXsJ0SN/qX
+Vf4V/vX+Ub4N3rO+9vkgH8r2WOEx+bf4d9F92wkC03y+IIXPNuDvQGZIsPe4FVan5M0nmqylxbF
oFgpCrQqNooUHb5V/m4lzzPM09540F+v5CuF7NdkMzRbSrFSppT7WpUKpYoslCNHL0Uznp3WYHuw
XWvhaQkcUqpJF8c7WDBaalGGLJh0HVbqPKuUes8WZbqnQzZQu3bqzwWlgUrb/Q1Ko2evt9JfHqhU
AkpESSIK6pFMmRdEZPVXBA8HDysLlSUU585osU5ZpqzA3ehOymrPeWUdRzPiC8o6ZaPSpmwNDFUo
ovsbtMiF2GUNnld2KcvkBmUf98S/j9aJbafBf8DfxfajiXc59bvDf4Rjkv84rfEpuZ5W5yzZVRnF
gzJ/N831Rv9Fucp/2X/N4wqYAhR3PGcCuYGhjQcbDwaG0wpuJLu54JkbKAqUBEYGxgQqA+PlRt9J
nnfPdrkiUBNweC4EpgZm+M4EZpH3LKUAo8gRuv9J2h/PBsaTB9soZjXSmWggHZgv5wcWBZoDywMr
PQtka2BNYH1gk+dwYHNgW2CnbAvsIa22wP7AQc8x0nwycIj6ZKO+HA2cCJwOnAv0BC5RHztJt9Vz
gVpeCYqgxbM0OJiizRDyJRfZzTC6poxspSJYQPbbHRzh2RIo8Xf7u73L/ac8J32Hg6XBUcERNA+G
4NjguOAEX2ewNugKTgvODLqDvmCtXEdH1dcbjAfnUusFgeX+ruDi4FI5GWwJrgquDW4ILA+2emVk
U4/+/Qnzb+gJMyCi+FTDUP7fZNytQvq2QeS5N5K0kWwl2UGyy71rJol7n3vf7GOzj7kPkHS5u1B3
hOQ4CdedIjlLQtfN6JnR4+4muejmZ1iDzWWbQvfIxRONwBONAc8yRuS8JjzLmPEUY0HOm4OnGCue
Ym7Dk8vteHIZjJzXhpz3TuS8uXhmuQtPK58RUq6cG8GY8LlD9xghuR10rKTjVNNdtZvcNbeCujo6
biZs+wTs1FDXoKF2zy1iP+HgADikoS5Jx6O3hrqFdDyh47SOcxomn9SOdasJ66jcQ7h0M+ra6Hjl
01G3g7CL9AodFsLgG4Gx9cPkIf0w7K9AAWHEACgdQC9jVD+MvTW4aN4njyNM+ATUanAd1TDZdYuY
Rpg5ANwaXLRuk323Bhet7WRVR1zHXA2uc9rReYqOhwkLCItvhotsYPLST4frkq6jRccqwtp+2DAA
Wvthy1+B7YT2AbCX0DEAOvvh8K2h7iwdj7nhHwOCztV1Ey7q7c7cIs4TLgyAY7rOa3TsvTXYTXS8
eh11huvoa5OrH4cShtM56/V7ZcNepN/f9umwlxBG3nh9XV4/5A8AvnYMHQvpWKkfxw/cn09CXTGh
bACUEyoGQNWNsNdkxe/seJuJl3ocszvcffHFPtV9Y/zI2En2uurz3TdHM7LmdtaNfeqLKdkxIOPD
um/xnpGx+SnD+tl0r3beLhMUQlSLEby/2Odr9Twm+yJCsxZf3bxeFCftKwlrtD3Avl6P71c0e7fT
nGTis532NPs2bbz2nfo8kE6Ol6wTYL20nnaKi3aaOzv1wc56z+nzq88nX4t9MrOHnc6aZ9LjEJoO
Pueg/cIxWO9X/3Xqt0Z9e0pmnZq1vdExROubY1jW9Ve0seDvbfreR387CvS6zVnYOQD678uHBsDR
rP01a4/tQ08W+u2vffvlf2WfLHDfuBeWuq/vgVn7XV/MIjgm6Efatxwu3ccofjhoT3LQHuSg/cfh
0+vJh3n/gN/WaP7koH3GEddikWOu7he6H2TiItsW6+E4h/iU8ZFmLW7x9X0xsL9v9fOrTHzp861m
vf+L9TVfev16tCd/c9De5Fil9dtBe5KD96CTekziMdAe5NiiX/dpMah/HB+oTabPA8TjvnPW6/jE
WPdp8bTwRtwUJ7NjZXlWjMyKh2hbqLep0OaAY/QUsp8ppRo4t+H15pxmyii9jmzFWU1ljmN6/jKF
ciNHrx7HaE2nsG0t1uKZk+ee50vPCabU6rGM9/9Vepxj+6M9egrpm0L6nNTfKWQ3U0jfFLKzKayT
bGzKAj1+ZuLlFj03y+RN8etxFLp0HejjYi1eol/943C/GNyXw2TiMI+TdfE5sqkpLVnXL9XHM1ab
L+RcNLYpq/S6cVmoHQD9c0H3ANDntX9e14cFWeif12VytP9KbrbdfWP+tdd9Pe/KzrHc+rXtWXPS
37fI/xyd7pv8ynHY3ZdjOdivT2qxqC9endHs2nFet6dMPbfp1e2PjxRXnLrfOcnHnDYN2f7mzNNi
hDNfs09n8QB5DMFZpqNcA+Ig66/Qj1XXfZB9wkl7nbM+y/+onXO65m9O2qOdjYSAtvdkgHjUps0T
j9kZISR13TQO5zx9nHp7Jz3TOZcQlhFWuBGLnKsJ9Azn3Eho0/Y/BuIk5QTOrYQdWjx27tLslPdC
5z7CAUKXPl9HCMe15wTnWW2enN1aeyftHc7LhGtaDsjxPxObXbQHuAZpYH3YZ8i2XbnavLsoB3UN
1+zMVaTNI6+jq0Q/N1LXMUaL5S7KEV2UH7o49lA+5qI8zEV5lYvyKZesza9L0eMYjd8V1Y9pzR5c
lAu5KAdy0R7hWn7dfjh2cz7golzIRbmQa71er8dcF+UDrs2afvYTF82Ri3IA154sW808B2T2KCq7
9mttXAe1Ov40xh377njt75/G+Ft6V2YqNe3nf1E1HBS/ECKnkFBMKCOUEyoIVVnHakIdoZ4wndBA
aCQECBFCkjCPsJCwhLCMsIKwmrCOsJHQpmMrYQdhF2Ef4QChi3CEcJxwinBWv2f3JxwvEi7r4PbX
hLCatHrrIEKu3rdu/UhjsA4lDCcUafV9xxLCSK2v1jHXx2ytJIwn1BAcmh7rVO1+1hmEWQRZr1cI
UUJa02udT1hEaCYsJ6wkrCGsJ2wibNaP27KOmfY7CXv043r9uj1Z5/cTDhIOEY4SThBOXz/y/FjP
EXr+imNmLi5p8/jXAmuQjXoNrB/rdUpve64frmj/7XzmmLk+o/c2C2Gwvt5Uf9uQ68fbhhEKxC/s
tXaXfZp9pt1t9wGqPW6fa19gX2xfam+xr7KvtW+wt9q32Lfb2+177R32TvthkmP2k/Yz9vP2C/Ze
+1WHwWF12Bx5jnyg0FGMv8tIyh0VhCpHtaPOUe+Ybm9xNNhbHY2OgCMCJB3zHAsdSxzLHCscqx3r
HBsdbY6t9PcOxy7HPscBR5fjiOO445TjrKPbcdFx2XHNaXIOcuY6hzqHO4ucJc6RzjHOSud4Z43T
weepfqpzhnOWU3Yqzqgz7ZzvXAQ0O5c7Vw6INc71zk121blZl20kA5V3kuxx7ncepPIhXY46TwCn
Sc6R9DgvOa+4hMsCDHYNoT3hngF/cUHov7hgxS8uDMIvLgzGLy7Y8IsLufjFhSH4xYU8/OLCUPzi
wt34rYV7bIW2x8W9ttG2avGozWMLiCdsqi0mJtqStqeF3bbA9ox40rbY9l3xNdtztt+Ip2y7bXvE
QtsB2/tiEX59YdP/xz2TpCFSFJ9Xaef/Tb6oXAdFlqIqHdU66rLKDPKaoul6mds16OVGHQEdFHWL
KOoWUdQtoqhbtERvu0xvz3Ursv5erR/X6diYdc82/e+t4pG6gySH6o7Wnag7TXIOfLquh+RS3RW7
sFvsgzWpO2gfYh9mL7CPoNpSqi+wj7KPrTttH2efQD4Jr6y7RH7psrtpre7EL20I/MaGAb+xYbSV
28qFyTbRViPMtsk2p8jB720Mts22NdI6BG0hcZ8tbkuIQts823dEkW2R7R9EsW2XbZcosb1ie0U8
bOu2dYvS/8fapWvfNH2VeCZZh3TtdpQHofw4yo+jPNpUSzzGnER9I+p/hPIy4nLzSyjXoqxd+zjK
9bj2MeKRqB9jikAPX1sO/Q2m0czmb/Jnn8zzqJxnmsBsThFvQ5sX+b4fofzRbvRhEepDKI9GeTTK
Y7Te6jwPHEMb0vnRH0yPEJ/SR/QIzn4TvcJITV/EuILoeYDLxmMoW3FW4KqfoiaMa+2ouRPlJ3Dt
HGi7Ez15AmxGm7Fo4yMehfIolMtNlahXUB4LDagHj8bZcpz9gulLzOYQelKJllwebbyINto8LIO2
XdDGa/GYqRX1GleAp6KNDJ07oJNmw/Ak39HwqNlN/F0zebchjfIT4GPmOPECbiMZwM+jPfppEMxG
H1o+b/YQb4LOu7hGepvL0gc4+xzaT0T7H6CcB20fgE+h/RXTv1C9wfQa8VTTEb4Ll6U/o8Znept4
HLcRvcxSHfg/wLuZjUa0nAw9T3F76V1oaEX55zg7Ce0/RvtSlM+C94F/hfbvm5qopcP8z1S+zHZr
sJhfofI1rpcazQeJT5vIEgz53Ea8b36W+N+ZpbN6DbGxHHrywcNxrRf8HPhu08c4+20qv8FsOIHy
LvAh8POmBl4jy/vgHeA2cDO4hzlnGN1rjLaCaPldC/+GSiPKT4Dv0LkN3Azma+9Gy/04uxU1x1Cz
ADXrtXXnMvEOcBu4GdwD5vaT0XI+rhIam3/MVoHy8+j5JpTbwZv0mjZwM7gHXE1j2WtuhhUFmHH3
t8Ef4NrndN4BbgM3g1nDc5iNH3Ab42rwD9DnD8CnoOcU91l639xJfAn8vvkFcBQ8GwxLMHeThrux
XpfR8hT4vM7Pwgb2sW2g5ho0XIOGa9BwDVZxGmdPo+a0XtNObMRY7jfvh810gqPg2eA3mWEJpzQb
4zJZGmt7E+X3KafnPlCNoVJnGovhdbZSw3DUDEfNcHj3cNZM/Bq4HZa5mcY4T7NPaG4BP6dfy36R
gM3fzf8TN93rBXAUPBv8GrgbzDpP4NoTmI1D0HYI5edRflFnnr2D6OeTOaztDo01S0N5k8bm32Bl
o1hHPvsByu9bvswzrDH3SqCGnmmZ81F/CCt7CDXb4CPF4EJEoccR375rKSF+BvXvIRZdQnkF7yDS
vyGm3aHFQ24pDTL7iT+DaLYYfDdmYwvalMEX3kL5SXCrHgNpf5Gg35DDbHmTV9/yfZ4NM2Kpyc1z
YtnJZUsZl43nYNutsJNyWG8nrtpp3sbXmragV3xW0eK5hSPnI8zkm0fgU0fgR+wdD6L8HM7+mz7G
BPrjw7U/Q/ufYZ4RYczneH6YKVYza+v1qIX2R0Ma7e9AeT/aL9CjRxviQDPvDvBBH+qfB98FfhB3
eRv8cU4tr2bOZtyXz07kVSbP5XKezqzz83pMXkflYbDJN1FTCD5uuZfXF/H2Rdjz1xG3t3MUNR+G
TR7iluYS2J6Va2jt2IbzOJ5LnZoX07My7QhYl8M8wxQH2mFj7fBKjV+Dv7SDX8MOwrE6n6+l+XwF
Vz0LD3oWdsh3SXGvjJP5rHGyFlVMlKtI98HHJ+CqnZYPER+4fQX3liyZa86yp5OFv8U7C3persef
Z9GS77IR/Bx4n+UhLlv+Fzx3Cu8y8NwTOLtLZ81DuTzN8gjOdqOmG/3nGR5reZNjHXr7Au+G0v/G
npiP3n6E+pcw5/ehXIixnOZMyVBvYv1dJhvxOc4eDfcw03o9i6jCq7YGY1zHvmZ8HPvgw8zGQhPV
GH4LzT9Byw+g+V9R/leUJ0F/J888MWuuQ58jzGIryufBXzcPEpxXsP4vYaVKoaFL2385j6I84duI
fmzhS5G9nDcpGAXb2wM4uwY9fxP32g1t+TxS0+94NsyYE9OHWN807+/GoazN+BaXTV9CuQbj7cEo
PkSs+BCemI9+ItobdnEPjWMw9tv03nJPilAuM1HuKr2OUf/aRNmgNB59O4BrYe2GSpPKPo6rpnEO
bJhm/BPxStNE0lyFddxuktk+DT+h8hFoe09n1vYi9HweOstNJuJ3mcnq7hOcldEMGHMwD/+Eq+Lg
FtjAORPP3hZoKAH/CHpcKKcw9hcwzxMwRgVXvQc+AQ7yjFGWxaNYxFkrlW9jq8AeFIa2RvRzGvRY
zKs4AujWyKP7DfpzxTKC2fwB+C3wbtQXges4Jmg5J7c0jAJXmt/GPsLlGi0LhZ43wa9Dz+vQ8zr0
/B+096G9j2sMUdSMQ41Ly1q5LHq5J8RvgXejvghlbn+HltniLrs1Rh41GXom87WGp1B+SiuzHuLd
qC8C34ea4bAf5BvQ+S60XQK3gn8O3mziHXASdE6CzknQOQk6J0HnJMzSJNZsLOWWxlLMwD5o2Ify
r1D+FY+CZnUd+s/8S228XKa+rYOedbjqA2jgmgr080OdD8KzuA9TzY/BW3l1njVxtrlXfzrgu7xm
OgqfxdMBtxRaJn8Guf09eAqoBf8W2u6B/l7wUfBmXDsDXINrd6L+PXCniazUUsTjsrQxmxRuY+oy
v0yejntZ4mbepxowV1HMwH+gvY1n1dIGv34cvX0TdvIuuEV/Tnkbq9MBm3wbq/Y2Zgb2yV5GM1DM
K2W+m3gtnokMaFmAlm+ivBh3H6fZG9bip1xjNGKljKifjPbvgj8Et4I7kMm3Ws7iLlzzMa8LrS+X
z+qMtUZ5p2Y5XEOWUIcVrMOK03O0WGz8HT1Xusy3M1voufWjN9gTP3rDTKts/AkypYM8J6Yv8r5j
8nLZ+BL4h6hv5XzM9CKiItpTbsx50edwrR15UQgtX+XnTdPrHKWNeH40PsXPy6ZcnP0lrvpH5px7
UT8UGq6CN6O9G3aygNfC+CueW+NJlCeBRzObCnmNTEWwjWa0fwUW9Q6zeSPajIZV5HNL4/ewsn9C
WcHZh3F2GKylGhq0Z9XN4Frc6wlkBS9iB6zhGTO+ix2kGbFxP3aNDs5PjOuRkS7HHrQB+eF81HwX
WU0P9OwBHwG/BX4Hes6Au8BzsDe9g312J7P5VZQXgF9GdO3FHvQ/OX8zPYIs7h29vAPcBm4G9/BZ
fvIyn8f8T0bLweAvWr5BrD2R4QnR+LLObeBmMGt4CS3n4qpfcQ0x19RzjXkWrKIBue4csB0cRWYY
R/5Zg2dSZLCmYtjPb3AvtDQ2cyw1oYaYR3EOmh/UeQe4DdwMJm3mh/mZ1PIKbOZ181C66nZoWw/2
gPF8asrD2J9GeYfOO8Bt4Gac5XE9zXNl2s3lnPssPwbPYP24yqQzzw+eEYybeR6MTyDrm6/zC+Ao
eDYYtsSZm2UQ1v1baFnDsdH8oPl1Kv/Z/Crxj1F/VOcoeDb4NfBjbG8424GaDtR8j3Nd4y/YQ6Xv
IJcuAH8ZPAe5ZSGeg76I3LUMWfFyWNQcWOxyzgMNNdD8S5SfxtPrdvTt96j/Pesx2dH/k1xjulfn
F8BR8Gww+9dD3CvT5/gZ1vJPms2zRxjOQNvt4PXIEBbCj/KQP8Rg/2tx9h2dXwBHwbPBr6ENzafp
fr6L+VV+r0jMbV7GVS+jnIcZ6MUsHTe3wRcK+KzGeGI9y0+spnNcY97NPTHtQPnPKJtgJya0n29+
H6ugMT+9vsFPrzQbbBVdpoXoG1usQPll9PxlnNWiaBX4dnMeseD1Mt9jeZLKG7jefD8s+ffgp/VY
ypFnF2Lpc2izFO1/Co/7E/zo9v/L3rnH61RtjX+sNdd69sU2SZvY5Gxyl/sl5BCRa0IqSXVck5DY
LslBUi6pKEpuSSq5dVPJLcktSZKQOo4jqVTu5Ihnv3N81zq/N94+v9P5nfPf7/34fL5rrDHHHGvO
Mceca831PPvBilqHFXg68gpdgV1euVrhGsZlAz7ZvZon8dwXbxWR39b9r9vhaml/LFcqU1dphqcK
u61n8Mw7k5Rotf+I3c04ZughZtBbzI5akN2xWYyHl/EmwcOu1kr8vKNtC3hPFbAjdmOh99Ae7IUH
quw8HIY7mNeH4Q5m62G4g9a+6eTHuOIyonROnwHMDFanjTCgbSt0jxy8AHOUhjcnZnPiEb3fMYsn
I7+F/XPUfYyZPk41iV66GiTuQf8+9vvgTXBO4rQypZPe6bB5UTMnpShyIVgDb+ewn0Kb0/XuEBTQ
91RBlTCL/FHZ17aFP+roBwWYO8Oj/Sb5sCjcpHmi+uDreE+tbywXsMepy7xupveIlOaM3eeM1NUq
J9LDvK70DPesd3VH7LJX14QmWprSnDvLHJ1Nbr1aDtezLi2Heg9tyXukiuj3ot+L/gj6A+i/QN8Z
b3/hKtHOazh3xh3wXb1uuE97lOB9rHmDHfdc7nHT1N7/QPfXbpW7kwj/TJt1Xaqre+1EXmb9YWb3
aqWL5BbWmSq0RLmV0jw8F+XRJx+3Hp5nLsxixdDSEXBcvHporV2sG+/pvtvZTEc/nfazXiVGOvlt
2tw0KOr4vDLIJv6v0dMvGZ3B2NwSW6qmOPugD7WPwSW6Rza8VTbRrm03u7ZNrMkPEIdijHsl9mXP
ki2FQ7cWJVKp9TNPCK/qfjzsHbidRfA4a2w/6vaj7kTk+Xot/yqu2JVxeY5df3d6NJYd7g5mRIDm
Md2VBxVp523YH+WKtCocgzxc9+bmXuTIpi8easPb9XnJPTfqrHw3uEzvC7TwW/I82k03IhOa0fcq
ZqXrVyf1k8iBw5TBnGAxK6fOiGtVDoeGQ2mVxrMDNtHnHatYzUItNQP1LhZ6+MlP/N+lhS/qvtvs
QT6iu3VTDbmZ7tbNQvqST1sSMoOCW4IiTjOb9o8yRxxHGpcJwSH9lCfxAs+EXXS37nqn7Smqe3Yz
AZ8DY2oM88JbdJ8evgtv1X2E+UX7nihEBFqyB99PrT/pPt0URF5N6Una8z0tfAP9MT7LyNbIJMpx
9QbwTvrbB9aOny31rlqEWlt05+5/pjt3M5b4FOH94T5a2AW2ZHTGM46tdNRc9jr6i9EUo53T2cVM
hg0jmR3KZObaZHY6k3VX5UrdTiQsyxP1Giwfgm+FD7Meqmxhq4h4aIWHVnhohuVh9noVVRNURLML
zfTAjbhHXb8UfIT98o3sl29kF1aX/d2zuldymeDs/V5YfsEVC/H8WQlvlbRu0AT5wYhoHlRvjqvQ
l4SXc2d3kQk/pXe9A7crNDPxWRf/Ue8awAd07+naTy/wWRGfFenpYXp6WGMV3KKeE03C7fAhzSI8
vBaR+HRFbk4cGiZaEyvlDezf9+j+3fWitb77Cj7luq2ZQV/i4QTeWuvdSlvlVh7ljKC04x3BaKcf
yorKftntr7V0PCyGpkEwxsn9A21bJTSst8HljMVP8JjSbFaGW5VBJfig1g0rc5WC+GwB68F5eBsX
xQoPR2A5Inw/7KsrXspGjUBqG+J5hn3fPbyl76tySoK7XhctDcsS4c1YNkHuoXLKRvWW2kafTMIk
+8G69CvKjTqMchPGZSZyJh7qY7NQ3w+YP2n8gyxG4TVyo4TexcxB7Z1ZjJwfeQQ2e2ElapWEmYxm
Ia0bztURD+ehr4Hly4zyeJX9n9DUTdSGUzTfsCyio+ny5GHWQOU2fC5CLk2bM4nhA6p3lmdo7Rlm
KJ/U574inpjcD5EX62fZsHruy8jl4Tj9lDwufQXOxX4YcsTCcDL6qO4S5CV4WwT/guYvyLuxcXq/
Xa6+Ea0EH4aDYUO4G45Qer5STqKpDkVpeiJPhS/BS2JZPzXYRd0TaCbDptR6AjmT0n3wLBqu4rdH
cwQ58l+fq5+GX1D6d7gKbwabFvAm9F/HsrZhPprFaJoh51KrAvJBuBa+BX/AsjXyGeQEchIWhvuT
FfTJkPZgL6dUY6LIFINZqvHotXcL/AT9V8gr4TZsoui1SzZyHmpGY6Gy3xDOhnOiUUCuDgVOhS8l
9el0TRR/1XivwhOUfoznaVHvkC+LIo9NEpsSUV/Q7KNVB5E/jfvSiH6lurrDqDtcNUJ8vJFYVk+2
oRfTafl0WjudtiknozkBf0BTQimRXAxmwQNcsQzMhtXgt1wrysAnkb+BWcnGjh2QL2Vkx0Q5qXp/
CfKVSd19f45cDz1Z4acoE2RaYogyeBcP5zUCib4qh5sZ65eiyOTO0E8bsX80yg28PUkbfsbm78Sq
nc5KN6cKk//KSdEonz+uM46eDo7pw2zHy2BDOILSEXgboRoXT9Vfh746lJjZel9AnhpTLdsQ7V1x
5LMZhdlQ5aaqN09QepJatWhhlOEn6RHx9/ZEI0JPn4vyGbk7NkuJ0vZo9dBYBTuIWDR/M5GLEZm1
2K9NXqNvpZAH42cQ8iylYRabFmTgGeI2mVJG07sc/Q8aQ+8cbU4QvSx6lEqUkkqXV5GsfSRW3qMw
ysMuMbOpOxs/av8JPrdT+goknnKUXh+Cs+DHuZc6nqeP6WheR74cOZtRa4u8lZZ/R2kRld2KMd9p
rqF0IJxO6WwiQLabasjRTM/SiPnl0Ucz4kM4A8898NADzzvjKKkcrWxbmNfrmK3fMgqsKl5A5K/G
T7QSboXf59bQSCJvjtZALCdgeUW0BnKVT9Ez+4JRzJ2NyD/nNnPtjO4jc1ltPtdYBVcjX4f+MH5+
RmYl9NNgRVgymrPYbITvxKtTLUfuFN4mbJZGMxqyAvhTiFIDbHbAaN0gb33uCy6qbk9hmPvey3AA
jNaKcvAZOAh9DnJj2JsMvB/9K/G9QPN5dCxrBKJ7R2fsWUP8rtE9hdFMEP/CcDL8BK6ErOfe64xX
LvIKeJa626LxQiaS3hHknrANUTqNnJfSVcgt4E3J09pC9F/jcxJcDBfF8ze6lmb+RjL/NDPiJtgM
/VrkOtg/iDfuO956rp4kN7gzeqzkpgiWq8gWZO80q/FO5EXoOyJH6yqjn1hARuWHD7HC8HySKI63
aEW6ida+lTtTP2PCQ27yUfrr6G2AZ1mH27OSLIZ3YHmWdTiDvkT3qcx4Xc0mt3VlqI+mPtGrz6py
Gn1e4rAqpq69BssWMdXDfEoXx8zmvtOHGGbTTl2XsindAt+iblveMZ7kHX4x3jQWS7zpLDPib9fo
t1Pq8J2c87xbLq/fcvQ+UfoL+Px3PXtP3lB53wT6zZw17Mj4tMVvksijM51PcLaq7L+PfDzYzV6V
z7z0+Vw6+WV0XPSNhKkQ3K1XD17QZwyV/cPBMc1GpTkevCT6fslZyldKrxe1mivDBbzTSMDKwXCd
m3iYH7jnXtMZD+e0NNGBWu1hTb6fcAamBlk64uYBjZhZpzYq+6P0L1z8PkrT3+zFm7OUTUqvZFQL
zXZl8KPS9UI51zymvcBPE32r4G+I/FDaURmOxsMZuBdOgG8YfZ9TQemvNLq7z9Z9vX8GTYGwE+3U
b5FlqEa2qyxfKZ29ypvUPqyPn2xqVTX6/b0yZpqOvplL2xbpO21qvQHroSmn9uFqah2IW6KlHdHM
NsN0tUHfIKZ+jyiIvc3VKNG2t1X29tEe43vK8KT+6g2y7/uq8VZTqt9AruHt5xuz+q22tv4Ex0r6
1sVf6T+hq64/Vlvuv6jzWmX/Ef8RxxG+frrtq703GbZXmnuwmerzXUd/kmMVM97xdeQrzcv4cbJ3
Akvq+k2p+wTypXg7oVnq/ZWrn/Uv1bnsa1Z09AvTzvya/z6f8vsJp2nk59O57JfVuaz2XhvYTimn
lMbgoTnebvKL6Jrpf4JPlU/7X+tdA3kRlq3xkKTuH5APwvc9jfBS2nDIu8JZVvb0DadbF53mnKef
Mp/3Tuq9wK+q66o/ik/t9Zdlf/D2aXuUXiO/kGr8ZXrn8r7Rey4sBisrnTdH+Rp5Eizg7cVyr850
5K+8YXo3wecn3jzHKd6Xej/Slsi3eDilLfHPiei30IOjykQm8t+Q8/Lt9DzIV6F/FY3zEzyfcD6D
TrAJ/FFpvoOLlWEG+nNKP4CPoSmHze3KxC4sK8DWlJZE7orcEcuDaNAHE5QpxZHLUvoePImGq5iP
kHsgj4Jt0YyGQ5UerfUbUPoh8j7ak8BmMlxA6Xrk15F/gjfAW9HTI3OeupG3LfAheDf8HMuayPTL
/MIV70NeR3t2wkNoXsBbd2rVwXIz+hLIS5BnEZNlyEPgc7A8tZ5PcXefRNFodFQOfoS50RipHGag
OYd8TTRGaJ6MRkplczvsCvvj7Y5ovKiVEo0aMjFJHIlGDfvF8CClJZUpxdG8R9uqYDkR9o7iw9Wv
pYVropioxt0TVY4iRpyDubA+VyTa3jFKiaS/Eg9kXTgFbsB+DtwOr4f0OogybRbtHIF9aTwQ89DS
BvLHL0PupWF/AJuFyA2xjHKsMbTK1IVaN7Ug7TTYNMPDOzATfVF6XY7IbMZ+KqXMkWAHtUpxLWJr
pkTzjhjuoi6xDSbAsvh5E5uq+CeefiPqLkXPLAujXO3FtaKZWDzKPfx8jIylP55aP2DzFIwyhOiZ
AVEmc90SxGqJ0juGZgbXivKwFrwatqPuNuQaeKgOv4V/R/8I1+qGfCN+6FfI1cPaWD6On2nIRN5n
fQjmwcHwJmyiK34GowxZQek9kHExRbjivZDIp6AJTnDFYeijNY05GESzm5kb5kNTALIyGLLC4M2P
VipWFf8o9tQNcuArcD76aG1ENp+g2Yi8l6uTV4a54x+nFlkXRrMp6tEqbNKxn4kmGvfV6NvDLEib
DWtmYhw+o1aRFcGXkDkVkBseLU+MpNYD2J9FZiYGw+Fu9IypIf5hZ/SsUQGrVkA++KzqQU+4HPuT
5Mwo8idarxZA1qKQeWQeQhOtnIepG40p424YqQS5ZG6DzDUzCZK9KVuVqWRFyP0rJNsTRDuFvico
DbA3rFGmLrxBry6ie5Dg+aR+WtQJNoE/Ks13cLEyzEB/TukH8DE05bC5XZnYhWUF2JrSkshdkTti
eRAN+mCCMqU4cllK34Mn0XAV8xFyD+RRsC2a0XCo0qO1fgNKP0TeR3sS2EyGCyhdj/w68k/wBngr
enpkzlM38rYFPgTvhp9jWROZfplfuOJ9yOtoz054CM0LeOtOrTpYbkZfAnkJ8ixisgx5CHwOlqdu
UermYnMN8pOU9ke+A30KpC+JI7AKpRNhb3gttdZw3WK0MGo5/Q3mwvrUpdfeMUrpkb+Suox+OAVu
wH4O3A6vh1ELoxGP+jUClsYDfQ8tPhlHvww5kIb9AWwWIjfEMhrrxpBaqZSmFqSdBptmeHgHZlI6
FZnMDHZgUwrPRMbQfvMmpVXxQ2T8RuiXoid7wygHeuEtyvAoVz9Gj40/Hs0PlD4FGR2fOJgBcAbe
onGsBa+G7SjdhlyDWtXht/Dv6B/BZzfkG/FDy0OuEtbG8nH8TEMmVj4zK5gHB8ObsImu+BmMxnQF
pfdAImmKcMV7IdFLQROc4IrD0EerAdkbRPOCnA/zoSkAmVOGcTR486M5znz0j2JP3SAHvgLno49W
FWTzCZqNyHu5OplgyHD/OLXIkzDK+ahHq7BJx34mmmhkV6NvD7MgbTasNolx+IxaxbgHX0JmQcDo
e7Q8MZJaD2B/Fpm5EwyHu9Ezpob4h53RM7sDMsFnJQx6wuXYkNVBtJIcRo5GitE0xD9BhpjbIDlv
JkFyL2Ur+c9Yh6znIbmaIIYp9ChBaYC9YX0wdZXypf+F6FuRra60VPQewzzuNM3Zd/fUtw1mLm8S
WlA6W/821mTr99PMNN6l+Krxv0f/uOr1Cxaif22hms7KcLsyqIz+JHX7U/qdMjEAuSdsjrfDkSXX
7Ri/zSgl+o5C94az0Twcv/GozN/W6VuUlrw/Ocv7kEzejSxCP0/r+tvQ9KT0aWQfD4fhYDifvmco
/VFEoIO+IfE38NaiJnJN847WVRvJ5X3FpfH7E0f5m9qE1fHTnlpNeENSTzXepcFMpy8UvxtZxDuQ
RbwPcUw+mavvqdrmbtW1F7mj7m39bSp7TZE7UdoEeRXybiyHI6ci16P0A2odQlMg8oZmf1J3+ldi
U4BaVWFXSndGpDQL+Sylz+KhFPoX0ddGrkBpAvku5LFRG1T2vojaQOlQlZPtc0+7TCiD5g0p4rgH
ebbKJh97+VylaQCPozmLPA3LvyrD7crAQ+/DRZSmKr2TyIdhVewFm8dhBTiG0sG0YQpyV+T5XPEH
bIYhb6K0D37S8b8Wzotbri3pjWYZmpVwAqSnpjmlFs2o5Ar+F3b1vDqpbwKz8dwvboPqv9IxMg2U
8hV1l8BJeOONh38ATQe1Ccok9btqDSltlHzZMSmtnT4/NtVU4x+N2oznudqGxOVoVqnsTULfPvm6
5qfaB+so3amlru86Ohl4bo++MD6foP1Fc8+6do6mtado2x6tFfanLwfRzyHrRmgtrzbXGoZcEj9V
k+f4BOGcxhNOULqnKeU+NMWwOYhcQGmupVU1GbUNXGsonnvSwn3KREBsy0UZknuTZp3a+AVUo7+/
41ZIZlmQX/uSKIz9QZXD67DJQNMpykOiXYyrZBCZAhox7xF63TGp72b70ML5yOnJWzTHkvq281LY
hqtvIBpNkbuqpXeSWlWRT2O5AQ+TkCei30k0tqAvg+YEpZPR7MHbZDQNsTyidCsO4xXlIe1vTV/+
Rhv2kQlRJk/RXrtdwF6ixLjDUYzUSeyTeKjMtepRWpX82Ye+jtKt7zouLWIb5QFyYDuet0Xxj6Oh
LW9CX/YRq0Lo88KOWPaJr3uOeXGO3DtOJkSWGrfiKrvcPk4mq80dcBKaW7DM4lpZWG6l1gZspsNl
lLaJ529115cEbV5KHz9GXwy+R3t6RZb0t1/Ua7V0WcRbazIqEUd1LllNNDQyXi88P806sJrorY2v
pX6qM1KFopWKWoeptRbLJNleFculZGamyomSko9MW8GIa/tnRjM6niPqrTNjVAr+iRb+GK94RbjX
6FW2xHN2mit9LZrL6s2tlk/TqurUitZV9TyGt8SHpTt51V3v6bntnHwzWXcIG9YBE82jidRt439E
5q9gNLWPa6K1EcuR6DsQ+SlKty6tYK3QVSUakfkwldJset2Y/u6Fj8NzeG7CeF0DS8KWsY2uciPi
cdSV7SldM10+rGA2vUxWnOOT3HPk6jny+RxjofIZ4jYqvosVQaO9nk5P60d3Mdacw4zOSmUKWZTC
XcZ8h2V3yD1Ojmoeumfgv7AGHmcN1BWmA+2sR5ZWJYe3kdWsRc5yLpZq/yr6Plg2R26Ffh4t34m8
CP11yR2wP7PvuD6T61WS03L3M17tdbYyptfTr5LRfS35AZ/XF9TW0vLR9CUby/ZJnnmoW0yKO59Z
8cg6+fxi9SzC77xJoH+nE79pVEo6+nTVi6gmeZt+yzrZSb8Jn+TvQZLpyNWQqyHX0O9pJ2vqd+md
vj/6Bch36vfH9Jv5Tl6PfBj5R5X1r3hc3eX6Kzfoa+q3AZ2fhfw2yyl+32alUv+OQET/zj2ZqX/N
kczUvwdJvpHoo79yk/Kg/sqNyudXqZwcnXhCf+Um5aj6TxxQphxB/lL9p3yH/AtyZNMO1sCyC+yu
v3ujbTu/L2pz4hns5yJHtQ7R5pPoS6HPr0y5ht5Vhkfo7xhKl8IU9Fdh2Zhr/Yh+Mz6ro6lHZCLN
WUpvw34CV9xMlM7CkVy9EZYVqauWVZGrIldPbEJ/BrkifiJ9GVpyM3J55Fvxs0uZmoLML/mkplJ6
G5rxeHtXfwMHD1fhoRpyNeQa+vfyzv5T5EKwILWa0ubqtLkrozyLnp6ilLYlXkJzJ1wPT1J6mWOV
lFeRX8PnauSJ2LwJn0K/FHk78gltof4Kh2ut5mENPpc353ORiZt+kp6sdv57bc95xkI/eXea41p6
fpVGMtIkR8JsSC08VDu/DkvqnqfX52chH8DnB8g7kQ9TSkad/wLNt/jRb+CIpHvjUg+J6Xb/gD6S
edeAHvfIiD5dcvrJG+J2fje2b5wtbmeRmysFJUMSUkyukAJSWWpJXblGWsotcrvz0U4ekAelm9wt
98ogGRvb55UUuVxKyaVSRWo7L42klXSUO9xV28twGe1Wjt7SXwbLOP6PwaiOlVS3ZpSWTKkqV8nV
0titzrfKneLLjfJneUh6yD1ynwyR8VJITIu2bZtLy/Y3XJ8tXTu0b5Ut0/ByGb8Z+ge3NpdxHqtJ
fblWmsn10kn+JEYqSAcZIWOkp/SRATJUJlAnTbKlrOid7o/SRNpIRXkUfWHJ7+JQQrKknPNbQ+pI
A2kqzeUGuU26uHZfKTfJSHlY7pK+MlDul4lxCy6RPFJSikp556GmNJTrpIW0lc7SVUKpJDfLKHlE
ekk/yZFh+lum3aoP7GZuhnfAnrAfHAxHdOvSJ8c8AifB6XAeXAKXdesysIdZCzfBrXAH3AP3devW
t785CE8qAx/mh8XhlbBe9z533xVcB1vD9t373ds36AjvgN1hb9gfDobDew7o0i0YDSfCp+EcuAAu
haud4y7BJrgV7oB7+vQb1DfYBw/CH+FxeAYmlWHQ595ufcJ0mB8WhsVd4YCwFKwAq8LasD5sDJvf
q37awA6wE/wT7An7wAH3DujeLxwKR8Ax/VU/AU6CT8OZcC6cD5cMdGMULoXL4Vq4CW6FOwfe3a9n
+BXcD7+Dh+FJeHZg3279EwLTYSYsDsvB6gMHVq2WqA+bwNawA+wMuztWT/SBOXA4HAMnwimONRIz
4Ty4CC6FK+E6x5qJLXA73A33wgPw0MBBXQcmjsLT8JwyxYep0A4c1H9gSibMgtmwDLwSVs9xkUyp
AxvAJrAlbAtvhvo07ru1J/NfOBo3z4tKsf8nyeOHQ//vDN2KEbpVNEVS/2NnAWeR7LlV72Lm/Z00
bp3Lw28u/zuS51bv32aB302fEfGdVz3jbY/eH/Qp8Xfzkt/Ny/8H8/9uZtNSw9H7FbUHv9bZf0rj
7lSFpPC/KF2G5Lv7U8l/6XiFlPqXjqWlzL9w9Nyd9J/zn8fEc3fwf858v4vV3NNGjrvrT5F5slTW
yQ45ICe9wMv0Snk1vSZeB6+7l+ON8aZ487yl3jpvh3fAO+kHfnG/tT/Mn+BP9xf4y/3N/h7/kH/W
pJssU8HUMy1NJ9PbDDMTzHSzwM1BvVZqlLOmzUXnXS86n3jR+eO/Og8uKk+4ab5bUrxfnafXvPA8
Y+6F9e3pC/1ndrrwvKBc6L9g5kXnZS6yb37ReeeLzi/qT8E9F54XKnfReduLzode2P5icy4sv3zl
heelr7zovPKvzt38K131ovLRnPtufSgQ9bBs2+hYLup54HKukFurysTabfFxT3w8EB+P/pZ1hTfi
48r4uCE+br+wFRXthb2suPzC8yqjL7Sv8tWF59W2XHhe/e2LzpddeF6jw0XnN1903v+i8wEXnT/9
qyxzQu1pF50vv9C+9kWj9D/Kt150vu2i8+0XjmLdrY7WRaabN1V6ejNZbbu6f+Jm6hTxwvzhJdwr
Ckgio4XdkNHcrrNr7FqnSXg/eT85u6PeUfG8495x8b1T3ikxtpFtJIG91l7r7puaD75paprr9fwC
fkGn0b8gstoek9fVrOzOC7ndyACZKRtkn5z1Ml0bUl2rMjPaiZ/RPKO9Y4uMGx1butbnd2tyttst
VHV7nvr2OzF+ftem7zlusG6n5Rd05z9w3GB3iu/OdjtusHscN7m+aoZmSUm7z7V1jSv9G8cNdr87
rnXnX3Pc8CvLA7HlN7Hlwdjy29jyH+1tRXtb097rae8/StpQcgMlbX9dYjfTwi20cCst/EfJNkq2
U7KDEl9SfPfPTbM8vn5zO7+f30W1oIuqybguo5mL+hq7RhKuTWtdpIyz0E8jo7u+m1qufhfGSxgp
zzvrnXWjluvlumiFvnvuwW+I3wR+U/wsP0tS/ZJ+SUnzy/nlJN00d6OZJ+wadpWMsHvYXfKGPcOe
YsNeYS/JFw4IB0j+MCfMkUvCweFgKWCzbbZcakvakq5PpWwpKWjL2DJSyJazbs9nK9gKUtheaa+U
IrayrSxZtqqtyu9y15BitpatJZfbq+xVUtzWtXXlD/Zqe7Vk2z/aP0oJ29A2dKOj+XYF+VbKNrPN
pLS93d4uZWw3203K2h62h5Szd9m7pLztY/tIBdvP9nMLRX/bX660OTZHKtnBdrBUtkPtUKliR9gR
UtWOsqOkmh1jx0h1O9aOlRp2vB0vNe1EO1Fq2cft41LbTraT5Sr7lH1K6tipdqrUtc/YZ6SefdY+
K1fbGXaGy89Zdpb80T5nn5MG9nn7vDS0L9gX5Br7on1RGtmX7cvS2L5iX5Fr7UK7UJrYxXaxNLWv
2dfkOvuGfUOa2aV2qTS3b9u3pYVdZpdJS7vcLpdWdpVdJa0Z7+sZ7zYuV9bJDS5XNkhbu8llSzu7
2WVXe7vFZdeNdqvLrg52m8uqm+x2l1U32x0uq26xO90c6Wh3uzlyq93j5kgnu9fuldv4TezO9og9
IrfbY/aY3GFP2BNypz1lT4n+zvdoNz9Gu0zK5+WTkV6Wd7mM4n9GHeN18jrLw14fr6+M439DneDd
5+XIo94Eb4I84U3znpVJ3jHvmDzpnfZOy1PeL94vMkUXGZnqJ/yEPO1n+BnyjH+Jf4lM8wv5heRZ
v6hfVKb7V/hXyAy/vF9eZvpV/bYyy8/xB8lqf4g/RNa454hh8r7/Z3+ErPXH+GNknT/WHyvr/Sn+
FNngP+M/Ixv9ef4u2WTyuvXnnKlpakrSNDZNJNe0MC0838wyszwT5ATPe0HYLezmVQ97hD28GuFd
4V1ezfDu8G6vVjgwHOjVDgeFg7yrwiHhEK9O+FlinFc3/cb0Lt6R9LF5PC+ZkT+jqX9/xm0Zs/1X
83bP29s/kXdk3on+WevbVJNqS9gSJp+9wl5h8tvStrS5xJa1ZU0BW96WN5fairaiybSVbCVT0Fax
VUwhW81WM5fZmramKWxr29qmiK1j65gsW8/WM0VtfVvfFLMNbANzub3GXmOK28a2sfmDbWKbmGzb
3DY3Jewd9g5TUv9zanOF7Wl7mlK2l+1lStu+tq8pY++195qy9j57nylnB9lBprwdYoeYCvZ+e7+p
aEfakeZK+6B90FSyD9uHTWU7zo4zVewEO8FUtY/Zx0w1+4R9wlS3T9onTQ07xU4xNe3T9mlTy06z
00xtO91ON1fZmXamqWNn29mmrp1j55h6dq6da6628+w8U9++ZF8yf7Tz7XzTwC6wC0xDu8guMtfY
JXaJaWRft6+bxvZN+6a51r5l3zJN7Dv2HdPUvmvfNdfZFXaFaWZX29WmuX3fvm9a2A/sB6alXW/X
m1Z2o91oWtsP7YfmevuR/ci0sR/bj80N9hP7iWlrP7Wfmnb2M/uZaW8/t5+bG+0uu8t0sF/YL8xN
9kv7pbnZ/tX+1dxif7I/mY72qD1qbrXH7XHTyZ60J81t9rT92XSO91L65FOTtba8S+fQu9273al7
eD3EC94J3hE/cT5xXkxqg9QGbvb8Z1Zjl7n/uxr/f74a/3f2ZZF9FfRpy7s78eX/5tj/5th/KMe8
sLd7ns/vlfRrmuuCjlJM6kljaSntpZPbL/R2z+/D3PPABHlSpstcWSBvyHJZK5tlu+yR/XJIjrsn
e/ESXkbaUDFpA9Ny0u7nOChtGMfBaQ9wHJL2Z3fMcdIIjjlpIzkOShvFcXDagxyHpD3kjoOc3RiO
OWkPcxyU9gjHwWljOQ5JG++Og53dBI45aY9yHJQ2kePgtMc4Dkl7wh2HOLtJHHPSJnMclPYkx8Fp
T3EckjZcfFc62nFQ2jjHwWmPOw75NyIylZ4PTHs6jswzcWSmxZF5No7M9DgyM+KIzIwjMiuOyHNx
RObEEXk+jsjcOCIvxBF5MY7IS3FEXo4jMj+OyCtxRBbGEVkUR2RxHJElcURejSMyxfV/YNpsIjKP
iCz4NyPyehyRN+KIvBlHZGkckbfiiLwTR2RZnCvvxpFZHkdmRRyZlXFkVsWRWR1H5L04Iu/HEVkb
R+SDOCLr4oisjyOyMY7IpjgiH8YR2RxH5KM4Iq8RkbfJlDVEZMO/GZGP44hsjSPySRyRbXFEPo0j
8lkckR1xRD6PI7IzjsiuOCJfxBHZE0fkyzhXvooj85c4MnvjyPw1jsy+ODJ/iyPydRyRA3FEvokj
cjCOyLdxRLYQke1EZDeZsv/fjMj3cUQOxRH5IY7Ij3FEfoojciSOyNE4IsfiiByPI3IijsipOCKn
44j8HEfkTByRv8cR+SWOyLk4IufjiCTjXMmNIpMuUWTSvSgy6X4UmXQTR+Y7InKYiJwkImc1U/T/
adR28zato5T3tvvPmdbmBtPT3GV6m3vMQDPIDDH3mz+bcWa8mWAeNRPNY27vst98bQ6Yb8xB8635
znxvDpkfzI/mJ3PYHDFHzTFz3JwwJ82pvLX1/1Hytnnb3AVm61/nmlamlfimjWkjxnQ3PSQwvczd
kjADzABJNTkmR9LMYDPYPQkMNUMljxluhkuGGWEekrxmhpkhl5rl5mPJzFsrby3eMmRJelA8+EOQ
HZQISgZXBKWC0kGZoKz2zLXoFG/XPSn8q3cTFXkf1EctXM2ysUWxX1lc+asyF0nTx1lLkBnob4GV
C8pJnvi6mUHBoFBwWVA4KBJk6W/fOYv/vq4vpSRfUCC4NAiDRJASpAZpQXqQJ8gI8gY2yBfkD/R9
V+D6NtI1Qev4wR+DBpIRNAoaiXVltaWwecnMN4vMq2adWW82mI1mk/nQbDYfmS3m49+KuL4tMy+a
F53Hl/Xvms1Cs9DFe4lx66iL3AfuevvND//H+4vOaqErXW5WmJVmlVlt3jNrzPtmrfngt8YY7y+Z
l5z3+Wa+fiPTLHLeXzVudXYt/Nh5136o98qS+Ztef6MfxGx/HDOt9zuzi3qaDa5e2M9fKg/JGHlY
HpGxMk7Gu3n9qEzkfxd9QibJZDfLn5IpMlWelmdkmjzr5vwMmSmzZLY8J3PkebcCvCDz5EV5SV6W
+fKKWw8WyiJZLEvkVXlNXnerw5uyVN6St+UdWSbvurVihayUVfJf7H0HWNVI2/bMJDlzSHJCFRAQ
QVFBUQ6ISFGs2BUL9oYgKlhAxY4FFMta1y6iIPbexbUBVuy9IHbsXVAUEfiejGVx1/13//f79t3/
+6/XuZyZJIecPPPM3Pf9zOQkB1AKSkVpgByH0GF0BB1Fx1A6Og44chKdQqfRGXQWnUPnAVUuokvo
MrqCrqJrKAMwJhPdQDfRLXQb3UF3AXGy0H30AD1Ej9Bj9ATw5xl6jl6gl+gVeo3eABrloLfoHcpF
79EHlIc+onz0CRWgQlQEHRqTVqQ1aUMCSFvSjrQnHUhH0ol0Jl1IV9KNdCeBpAcJIsGkJwkhvUhv
0oeEkjDSl/Qj/ckAEk4iyECSSK6RDHKdZJIb5Ca5RW6TO+QuuUeyyH3ygDwkj8hj8oQ8Jc/Ic04k
L8hLTiKvyGvyhmSTHPKWvCO55D35QPLIR5JPPpECUkiKAILUu+05jucETsNRTssZcK241lwbLoDr
wnXlArkeXH9uIDeBi+UmcpO4OdwiLp7bwm3ltnM7uN3cL9wZ7ix3jjvPXeAucpe4y9wV7ip3jcvg
rnOZ3A3uJneLu83d4e7yPnwN9b2t/CX+Mn+Fv8pf4zP463wmf4O/yd/ib/N3+Lv8PT6Lv88/4B/y
j/jH/BP+Kf+Mf86/4F/yr/jX/Bs+m8/h3/Lv+Fz+Pf+Bz+M/8vn8J76AL+SLBJ1gQuvQurQerU/9
aAPakDaijWkT2pQ2o81pC+pPW9JWtDVtQwNoW9qOtqcdaEfaiXamXWhX2o12p4G0Bw2iwZBCIPWG
FErDaF/aj/anA2g4jaAD6SA6mEbSIXQoHUaH0xF0JKQoOpqOoWPpOBpNY+h4OoHG0ol0Ep1Mp9Cf
6FQ6jU6nM+hMOov+TGfTOXQunUfn0wV0IV1E4+hiGk+X0KU0gSbSZTSJLqcr6Hq6gW6km+hmuoVu
pdvodrqD7qS71He/0l/oHrqX7qP76QGaQlNpGj1ID9HD9Ag9So/RdHqcnqAn6Sl6mp6hZ+k5ep5e
oBfpJXqZXqFX6TWaQa/TTHqD3qS36G16h96l92gWvU8f0If0EX1Mn9Cn9Bl9Tl/Ql/QVfU3f0Gz6
gebRjzSffqIFtJAWaZEW05V0FV1N19C1dB3NoW/pO5pL34vDxRHiSHGUGCWOFseIY8VxYrQYI44X
J4ix4kRplBQljZbGSGOlcVK0FCONlyZIE6VJ0mRpivSTNFWaJk2XZkgzpVlSnLRYipeWSEulBClR
WiYlSculFdJKaZW0WlojrZXWSeuljdImabO0RdoqbZO2SzuknVKKlCqlSQelQ9Jh6Yh0VDohnZRO
S2eks9I56bx0QbooXZIuS1eka9JdKUt6ID2SnkjPpFfSGylHeiu9k3Kl99IHKU/6KOVLn6RCqUhG
MpaJzMm8LMgaOUu+Lz+QH8qP5MfyE/mp/Ex+Lr+QX8qv5NfyGzlbzpHfyu/kXPm9/EHOkz/K+fIn
uUAulIt0SId1RMfpeJ2g0+ioTqsz0Ik6SSfrdDpFZ6gz0hnrTHSmOjNdCZ25zkJnqSups9JZ62x0
pXS2utI6O529royurM5BV05XXrdYF69boluqS9Al6pbpknTLdSt0K3WrdKt1a9jqM5uRZTOjY0kC
AQRl853LuCbA75e55sDvV7lOXGeUwXXjuqNMxqE3uQguAt0CxotGt7nZ3GyUxS3kFqL7jNkfMN56
yHjrEeOtx4y3nnC7uGT0lDHEc96L98aIzZsSQRRErBeMBCPsymZG3TR3NQ/xY6qn7vglmyXNESeJ
iwkRV4opxEI8Ln4gbmyuNIjNkq4Cts9GBqAOygDntwAFFAcMcADQGb5CikVEOc5qG1hNXaMxQubI
RjoG21eldMgzpOOQZ0qnvn32KtTSkBa0hCWyBQVQ8fPqkZSh7pcyIT8p3YT8tHQb8rPSC/UvlRLq
GRVz9YyKhXpGdq4CdtavazQGsHVEESE/pkjfHTFkR4zYEePvjliyIyXZESt2hCAD8JoefOdJ1Lcl
+RAfREgD0gBxpDFpjHjiT/yRIM4R5yCNmCwmIyq+Fl/D+Yiwhpz/mzj2e4b9/5tf/z0Mq3LoX+XN
v5MzTWhP2ov2oaOAgVTm9APObMbYrBUw0wzGkx2AI1V2/MyNIX+RFaP+hA9/z4aLgAd/ZcDi7PL/
Ght+YzvgxYXA38VZsQ6oD1V7fFYequ5oCcoj74vuyAfV0REUx1KmORJAcXyEXtsOemp3tV9+5U7S
/3velI1kY9lENpXN5BKyuWwhW8olZSvZWraRS8m2cmnZTraXy8hlZQe5nFxeriA7yk5yxR+ybeyP
+VYxUERF+kusu+H3vKsYKkaK8e/Y95iULh1nHHzqhyx8FXg4Q8qUbkq3v/KxYq5YME5+8YesXPB7
XlYslZKK1b/Ezt9xs1zwb2DnFpjgEhDKWmFHZIZb4gBUlq2UOuJuOARVwr1xb1QVh+JQ5I774v6o
Gg7HI5EnjsLzUH0ch5egbngnPouCyCASiUaToWQ0GkfGkmg0mYwnk9BUMoVMR7PITDIbzWNrnovI
fAJoz2L8pZzMmaAEzowzQ6s4c64iWs05cy5oH+fK1UepjPEvMca/zKK3K3wSfxY9FYwFY2wp5Aq5
uKTwQfiArYSPwkdsrYHmwjaaKZrpuJRmpmYOLqOZp1mIK2jiNEtwJU2CZh120WzQ7MA+ml2ao7i+
Jl1zDrfVXNFcwd00GZpM3F1zU3MbB4E2KMAhmiLQBjHUg/rg3bQmrYUPaJ20FXGa1lnrgg9pXbWu
+JjWQ+uB07VeWi98XF0/wye0tbW18UltXW1dfErbQNsAn9Y21jbGZ7TNtM3wWW2ANgCf07bXtsfn
tZ20nfAFbXdtML6oDdWG4msGEPbjDDFIDMbXxRCxD74hhomR+I44VByKnwHPLsbPgWdT8Dvg2Q+4
UCJSZ0KlrtJI0kNOkO+Rsbrpujhy6PP9LRCNbmIrLl1xry97dhXbg5E30nzRHuVB07jD8ZWQ1HwT
qIKVrFS39n/Z2g9bNyGpd9lUwpWg11TBVYDuPLEnnLMhbgjk0hQ3RTxeiBeyu2zSUQ/BSrAWbIRS
gq1QWrAT7IUyQlnBQSgnlBcqCI6Ck1BRqCQ4C5WFKoKLoBdcBTehKr6IL+HL+Aq+iq/hDHwdZ+Ib
+Ca+hW/jO/guvoez8H38AD/Ej/Bj/AQ/xc/wc57jeS6Xe8994PK4j1w+94kr4Aq5ov/OPh5M4Qmb
aeDZrxWM2WqWJSQO2UDioeUqgKXOSL0vzQWSFlrVG3RiDUgi8oUkofrID8moKSQFtYdkiDqiTqAP
u0EyQT0hmaI+kMzQYBSJSqARaCSyQGMhlYTRSZAVNsRGyBrGqBUqhW2xLbJl9zSUhvHaEtnBeO2E
7Nmqbhk2UsvifrgfcmB3OZTDQ/BQVB6PxqNhTE/BU5ATnoqnoYp4Fp6FnGEEx6HKMIJ3oio4Fach
F3wUH0Ou+BQ+haqy+SZ3NvI8mKZuwmadurFZp0A2F2ZVbC6sMrubyod0gRYrRVyJKyhHD+Kh/kaM
1IcjTUgTUI6tSWtQju1JeySA/glBGlA+fUE5ThZ/QlpxmjgLSeIqcTUyEteKG5CJeEW8iszFDPEG
shRvi1mgqaOkMcgeWGQCclAZAjkBQyxDlVQ8Ry6A51eQK6D4TVQNkPw28gAsz0LVAc8fIE+IsR4h
L8D0J8gbcP0Z8gFsfwG++q0tVZgtjUkY2GL7nS1exAuOqBZxpCXENDyzSGAWaUDndUKU2aUFFTcQ
GTC7RGaXjtllwuwyEzeJW8CibeIuZM1stGM2lhEfiU9QefGZ+ArsUi2twix1ZZZ6MEs9gQdXQpyw
GqKNWsxqP2Z1Q+CnXNQU2KkAIpTPq6/qrxx7MotcVBvVJ+0h7y82unz5jCOM3ll4/rd9BK/DW2DL
7NvnYAT8oA1qEGg31hI8863A2kPD2oOy9tCy9jAA3dsViaxVJOZtmbWNTuwodkQKROZjkCFEX7PB
53PFxcgGYrBdyEHcLaYgD4jEXiFf8Y34AYWAhpiE+oNamIVGgjrYgGKA+3eiecD1GWgJ8/lu5vNf
gMHvoj3M83uZ5/cxz+9nnj/APJ/CPJ8KzP4KpQG7v0EHgeEL0CHgcw06AxrHEl0BXWOPboGWqYge
giqR0EtQF8boDXC8FUQAgIQQIQ1ESI0gUV11lgG1Uu+2QW2kUbIfOgN/Uwov+sufY0+7/Js+/a0/
oCDmVT3r8y2L9Qf9r/0BBSDfb/sIasDW7s2+fY4gTowXV8B3porp0MfzJHXkwF4W5X++Ent2Dfov
V/n1Wr0Bzf4FdIe/LMGwEDEsxAwLOYaFPMNCgWGhhmEhZVioZVhowLBQZFgoMSyUGRYqDAsNGRYa
MSw0YVhoyrDQjGFhCYaFFgwL1d82HwQLZNKI24Nq/+laEMEiNoGrLIMrYjfsjeviJrg1XF0QDsMR
eCjopxg8Gc/Ac+FbE/EqvAFvw7vxAXwYn8DnoG1uQDs8xi/xW/wRCEhDZGJCLIktcSAVoY09cEWw
3hHaojIrOwEDq2VX7MXKbtibld2xDysDcQ1W9sA1WRmEfVkZjGuxsieuzcoQXIeVvXB9VobiBqzs
B6yuluHYn5VxgoVa8rsES1YmCyXVUsnXSmopmGpltdSs0OpYuV+rsPKA1pCVBVojVhZqjVlZpDVR
S1BQpqysZYjZ94RhJ0AjQ9AaBLacIe8EikPVL4BJYCX0RLDRFfJA7AZ5D1wV8iAMWgZsqwZ5T+wB
eQiuDnkvXFe9/wTXg7wv9oO8H2gWAlY1gjwCN4Z8IG4C+SDcDPI43BzyeNwC8sWCGSJgbwnIkwV1
9iVfC44BS6FXg5085Pu1oHnARo16R5WWQl6o1UJepDVABGwDBaathZxgbHUBzu8HXB+FJqBpaC6K
RyvQBrQD7UOH0Sl0Cd1A99FzwJcva4rQkyyhrztAX9JjD1wDelMj3AIHQGsEglX98DporThoofWs
7Io3sLIb3sjK7ngTKwPxZlYGAbqrZTDeysoeeBsre+LtrAzBO1jZS1tKLcFGW7UEK0uzcr/WjpUH
tPasLNCWYWWhtiwri7QOagkWl2NlLbyU+S+BeS6ReW4Z81wS89xy5rMVzGcrmRdXMc+tZp5bwzy3
VvWH1oy1eAnW4uasxS1Yi1uyFi/JWtyKtbg1a3Eb1uIY8YaI3VnOMaxAbKRjQ/VnIurThFuw+/od
kRvTAWw2DJuzvmbB+oil+t3qWXDJb7U+ak9SsRfwZD7rKyxXV+mwESAUwiUgrsIMiQjDF5VXLdEU
3Ba3xx1xB9wO9xE7AAN2+jw3TYaQMWQymcfFcWu5bconpUApVIoAZZeIS8UEMVFcJiaJy8UVgLhp
4kHxkHhYPCIeFY+J6cp7hSicwiuColGoohXzxI9ivvhJLBALxSIJYE/6WZotzZHmSvOk+dICaaG0
SNolJUu7pV+kPdJeaZ+0XzogXZduSLekO9I96b70UHosPZWeSy+l11K2TGWtbCCLsiTLsk5WZEO5
kuwsV5aryC6yXnaV3eSqsrtcTfaQq8uespfsLfvINeSasq9cS64t15HryvXk+rKfIis6RVFMFFPF
TPmg5CkfFWvFRlHXQcuzyBOxaFMA1dUUOC2M9APlEAlRpUxGQ1SpY/fNKiyGNGSRoRGb/zXmtnJb
kYlms2YLMtUka5JRCc17zXvQjBAvIQs1XgJtdUt8gJzUqAmU1GTQD97SRlAO9SDiz0DNIOrPRM2Z
fmjB9IM/0w8tmX5oxfRDa6Yf2jD9EMD0Q1umH9ox/dCe6YcOUiEoh46yEaiFIKYWRjO1ME4pAWph
PNi5B3X6Kx791zz4t/jpq4dE1pqItaYBa0cT1o7WrB0dmOWVmeUezPJWzPIAppPaf44+Bfa2Qag3
Qerccl1kW7z//7YX/3F//Nx34AzGrKcg1lM45mEN86fC/GnI/GnE/GnM/GnC/GnK/GnG/FmC+dOc
+dOC+dOS+bMk86cV+M0CWX+5eklQil29Apr3y4hVxzzrp4j1U8z6KWH9lPvyt7JgWOxvLUGVfEOB
ryOdIQcbBawnC6wnU9aTtZ8jafwG5+L8L2rAmJgTa1KWOHGNhWAhROgthAqDhSHCMMVeKauUUyoo
TkolpbLiorgq7oqH4ql4KzUUX6W2UleprzRSuik9lV5KH6W/Eq4MVIYow5QRylglWolVJis/KdOV
mcpsZa4yX1moxCnxylIlUUlSViirlDXKOmWDsknZqmxXdirJyi/KXuWAkqYcUo4ox5TjyknltHJW
Oa9cVC4rV5UMJVO5rbxQXivZylsl9z+/9PjPfZ//Y7/0MALN30swVfKB82v9pfvaYSTiMM2NYnch
a9W7dL7d4/N/uE/n2x0+cA5Sk3QrNtOh7mkKCPRtvgC/Re9Bo1cjnvCJerDPn7Qi7UhH0oX0BKyK
ANQbra6r/Sipa2nFE5zl++T5+6SuvBVP6jrdD1O936QG6ired8n/90ld0SuewJY/SMAH3yWw+fvU
8UcJ+OO7BK30ferG0q/bPX+TekMK+4MU8aMkFX6fgLW+TyV/k8p8n77Y9/l62Rn+Mz/yB/MjGN0C
/qwBXN8IVHYAexbL1yewqE9j+QnNQvMh+klCa9AmiH/2oFR0FCKgC+gatJ+erTf/3+ae/1Lu/6/k
P5wF+TxHIkMxX417UB01FgCuM2fRg7rOgrETxNEE2H4e1OfjBVBfiNU3iC+FyIvgnfiV+hRa/Abi
lWz2Ho53OBfq73Ee48x8qH/ChVAvIupbUAjhoc8JRAN1StQnt0oE4m+iY+8UMSIQYxMTYgb1EsQc
6hbqO0KAV62hbkPsoV6GQORGHNS3jwDHOkG9IqkI9UqkEtSdiTNS36pSGepViPo2oMVkMdTjSTzU
l5AlUF/KNWRPkm2MOK6JYKo+q04AewUrwU99uqLQEHFCI6GH+qxwIRTqYeqbiYGrh0F9uPrUKiFW
iIX6RCEVqW9ZToP6QS0gs5ZAFEm05Q36ImzQzwCUnkF/3VqEdet0EPXq1uvSoH5QdwTqR0GpYsUW
dAYHarKIRXiAyobE0P7z76yZZwgK+vLr4F81CGYaBDMNgov9ihUzDYKZBsFMg2CmQTD77QlmGgQz
DYKZBsFMg2CmQTDTIJhpkM9XSJgSwUyJYKZEMFMimCkRzJQIZkoEMyWCmRLBTIlgpkQwUyKYKRHM
lAhmSgQzJYKZEsFMiWCmRDBTIpgpEcyUCGZKBDMlgpkSwUyJYKZEMFMimCkRzJQIZkoEMyWCmRLB
TIlgpkQwUyKYKRHMlAhmSgQzJYKZEsFMiWCmRDBTIpgpEcyUCGZKBDMlgpkSwUyJYKZEMFMimCkR
zJQIZkoEMyWCmRLBTIlgpkQwUyKYKRHMlAhmSgQzJYKZEsFMiWCmRDBTIpgpEcyUCGZKBDMlgpkS
wUyJYKZEMFMimCkRzJTI12eUfHtiifVgKM3YXmTdVx9j3VtjUHFio4nvdZiSxBjrDrArgGDsKukN
NEIlhSNWAtL30IiVNJjHMdUJ5hPb6FvpnYvtsUmyHWfDlpRqIH8UhAajcADREBQJ/9UlJl+9fbGT
8WYV6HJ/z5zKU57UxZYDn/10/Um9vecSY8wr6mN4E30M+ZjIEUwAHNLQ1Bo1Jhuf980Nfn67tl73
7UoxD9cU4VpJ76Th2vKSaZl64REjBoX27hNp5xjsZOfq5VXdrnlo8KDwweG9Iu3qhQ+KqOJqq7f5
/OES3x8JH9QjMjR8gKu9vrR6nDO1/PV46/DwSLs6QyL7hA8KjRyht7XQeVXXu7rq9dX18K+Thc5N
7+pW1fXL5j9wRTG4TPFmUd9UFQOwAvtFEoMxWkv2p0U89MluYe2YsGB4N/3TpLXTy3X/UDiv2fLk
wiVJdr5RrZIWJ80MdOt7vm7PES83DD0ecD37WfxEm5kJE3ptP9J3ZFDZK6Vq3DLEsx/PP5xSuVdc
XJ/yi855O6fIOzuUT2vwSPT1nO+81tFrzfPG4+tmTTDcG9evbY8NMVHLAisPa/Zk0Y6ePnEtbVy1
DmYJax/9XMnyYc2FwWaBHYSQhFLVW096v/rVXHLU+mJKW7/tU8aleD8PmNtiU8Hqkf0jW2y2PDXf
wNEetZ8VGFp9b1MTWqNdUef8Fb1E7aoL0e3av9rl0808ehh/PffApnHzCrecHntltdWgLjVO7Hut
XV5Gv10Te3y73TDT2NuEg46/PHqNPnqlPjoJWrMU5qPj9NELxhl1PhfxKnTQ0rKtxphtaz6j6OSy
Qf9+/8X8SR/nVB/OeyylTs9ZYFntxW7scG2YcU6XQLeEpdJJX+HnyTOPez+0z37dfo7zzsSG6UGv
Pl095ePTaa1HQGihQ/9ax0+tuyVE3XSdXjPBKCJsb6GJv2Vo6qdz9bKMO9n5Pw0atXldyfRK1ctV
PhCyzOSncobBy98H2OTZH79SIqf1hgH13GhBjMWHB7376Vrl7n/T+tj+R4f1n+xcDSaXmudk1fxy
KbLyzbg73I7Ob7feTG//MqTxsdYBu3ZwjiZFs6681s4cs3vBkfXVne+PvL9mWNbQRHQurFbaBY+f
7tQxWVMtzDoss9rdSzb8/TV+fHqnqp4DmtvogpLFpGkXLwfUanDapu2qiEwT70lzhiSsvpAIqBCo
j+GafUYFscp64xsti7osOZn6FVNK/VNgAOPe0w3+AQK4ARi4usFmta9gMIIhKJxEY0ratnE11Rur
G1pTsX2PwX1CB/SOhK8x0ivqTmpKW4f07B8+oOfXCxP/6MLK6u0/X5hV8eM9Q+zahPYeAGe1a1mv
zp+iQvKI0Ve6bvfzWuO+wfV6XrlqjYel5pdeesxv4KvzDR5fmnaob7PWQW8XkUPNrzXu5+LgG5Jy
pmyy1Ch57JCbfvvXzVRaHilXKTvxka5s6fN1HD4GLTpb0m/lnCalF53e7lLmUJPKUeEZJWx9pnkZ
ed3c7/S2l09l7FZUWKHRqp398KT4/D3bgsfG5HVJjJ4QO2NL9u65y896rmoZa1FhUoub+lxU8+3R
vJrRBya+6Oe1uop77o4qm8XRQT8P7xW/cLBu4ubswzl2v/ibTA8+6Zzh5lfy5d4m831atrE806vV
iHUbJ6W3802IaTl5gLC1Wtooh/2te9Vc1OJUpTFVB0xoqDm/9FyTiWTARLQiddLtNl9Q4aM++r3e
VAWFcrysFzVaIDRBoBz3vwMqDNVrNFVfOynoOSj0pdQdCm/Om50qdWYoiui8+c31wy3iWtWvsrx+
8Gu9pB425HkYRhOLDR2GMaPWbxrTpHz2mX0tIpM6VIisOGT7xIL1zeYOR82fnHhmeSP0iJIUlUPq
HT0x6dSHNqcOJuxvF/46uP7a+ujl/PS4yza7pYSSurlXr9tudBr96sWqwRtm3vKaUXNh2D7P/hcm
by5bcPvJlVCDnyfvL7yL9rrnvI/KMzKpIjxzmj+nbl/HgcmeM+9Q3fGufU7vH1enb681e5P3znA/
kc0ZRY18d+FO3dujCu/e3VCYe/uybnvEldlZ/rs8k6IqX6qZ6S4FVScJ0WFlp+R2CZ65pdNer6uB
09pOsKr6zmdhYoyc1H3qdufkZStPrr9utytFXzLWzkxXcV/rt3XudNNnzXYMnZQWcS9n9foz4+oO
GqoAxoQBxrT+gjE9DIc3ZwqJKz6OBMCZf3BUfwWcqno9IE5VABy9l95N3ayqbuoj/5ZL+3Kc+4Pj
f4o1SZni9LMH0xovPr3O231j2Y59M/sdsC+TPDf96aaUo5fLH3QznrrvelfnfI92tiUqbZqpu2m2
fIBjs7HmtepsmF57a4PJuozouRsXaM61rz+0y9M3n5R7YyOXVz0Z+eBVVo9lY7hkv6LLviaXt5zo
pjs3KjvZVPcpMMwxdsi05I37Yh9b7Jh14J35rqCuL4xve7+07zx187jBh/yy5k0ZFrj40cZhadWn
VzVzMc0MOr7Jaq3/wt4bL9l56Qfemd67wb2jNm91LSPruDwWHMLs+zbeMvvwNq9jdVf272LZZP3M
qzPG+w4XG15bsW1C2UP3skf12tokcn/5Ok3je5gFttCnx+SckyKiXrZtPuyCtu3Q6C9Y80Ef/Y61
fSlDdcTCINSkFhuwOfa1Z0S1+hDQdOEDi6th492FKuUf/xiaVJwoVZa31JuP+/Ewr69+oDRfU++j
90qsnlhtYtU+kZER3i4uwYP6Ven/1YdVgsP7u0T0DVX3ukQMCu85JDhysEu9NtDRqsAufaOvXwk6
pIbeW+/5dVtPJjp/OeGwYcN+dMKQQcXOFPmbAcTQpnb78Da9l9qNd8fKQ4umNTY+uxY99qVuROQw
/wUNLXNQidAxmUGzkgp6L4u/7+j0se3VRYUtU7oZbP9l1YuYnIW24R0/vntzV744VetrbmF3PnWn
X0Nt+cD2Bk3nvtae2tN8wOt7jUwcq021H3S7+67NoSYOc18+cTfIHDMgfLbY+kTFZo3XuTlPfLzs
VNfy+/bVuNN523hpTzUb/wl+DYv2zl3Wka6df3P4/vZjV65ucSp7Y3xcnXsnuzj43hjr3rBF7tn0
UUue7ToeH2zWZvPGuFdXU84mLls/78TISpOcU49lfOrHXU/x3PjmfJeSFoap70+MW2Wktbo5q+yj
Lcua+T7dYlx+uJLm/MuKvsdm1gC0WQJoE/sVbRpHvWBoI/xzaBMQ2j9kcGSP/hHF0cZD7+XqoXet
Vs2NyRtXtummVzf10av+lmuroC/3mShtB9QLjegTMsiufhs/O782Lbxd9fU9K1fzdK9euV7dBp5f
P8iZ2v6BEW1CBg0NDQ75U4B6ukcITs8YsWlCfd+V2w+/aLbU4bbXUFuDK25NOgy/UCljJZ316lHN
/P3lo5bnPxg9xu1sRs2pXtWzP1zzcTe/NDsm3/15n9hBVjPv7G52Z3dsTlWRpCUNHVytWdc3yXeb
jC61e+7wzCLb2BJ1Gww8M7ZCe5Pz4/19zn68lTv1RS2UdflWjzyL6U1XRNd4F1r76d0pKdR/T+So
J/KDhk/X93tzuXe09oP5idGmewffM2j2MSj/RaJXnHfhM+P0HrZBHa6JAeMv+zRteq/tfpdAqxmz
hXrXuz6LEcsuMEgUXEOmzmlhW8c+afasAr/6fuHVtvpV3xi6NiTPvd5Wi4M+XneNpmVbTcoKaFna
Z4nrxuIA9SsgjRn0ukqtdk53yr3vsxt/anp3zNks3++wJ/xxi1oLfnFf33TizH3xTzf41Kl39Nx/
C3siB0cE9/gfwZ6vZ4r8EYJqf4fCPwCo0JExBrL5+VtnG0ypknLefWT02AqOdSrmXLSfrSzY2L1N
N6e8F2kBTdaMfm96TjLLa549sQQakDW+lKPfamcvt5vhcdU7vSzbemYAN73W6vienrke6Wb1dnn7
LjyuOzQw2jGn12rXe126zsxr3fpul2dzZi0JNWg25fz5oc3cdWF3o+qvrtR5fMBYP4eS5Q7/1OBI
uayS40KdzHItjr4u4xzdoFult3mrjg7zLRuet6pn7IykIN3ayrZrHszyHVu0ZcanBc/fFPCbTzc+
0ylyw8cc09LWXmeW77iy7+2Ol+kbs9vZ5td4k36lYv19KfG1RveyPL3NLlg8UbtmiFvJqG27a6aV
b9SiTMlFA6bp0978/D1AGYVJi/xTUbn1xpl+pTuM7J30W5j6Z4KvL+ikd3evrqKTF2z+A8HX74Dz
z/DmRvUB+ZvT6zYZaJl+ppFvm9SP6832OLvtNfFvnT7+hW/VjMausx13/dzzTumWE/YcbHp+rPDh
1ZADU4+tubwpNKLX8Aq9Hu9KfhX7y+mX6wpMVkgdyzi5nK2d0Y63Hrqzf8/+TQIyb765lZIw/ti4
22Obkepz36Uu1baz7dPwdEbq0C4uo3eV43e06xxmE1w0LqrGy8t8ueZewyJp14Ndrk2s7jzkuPLU
1ssgamjhkn4DRt557jtzwdKBSveK/pZBgW5LL4xvUalMlz5+U2+5TDBquS1vp9X0fi/LLTb9cNLo
aqzyNmboYI+j80YmnQrUPBe2TKya/GFu5wl1JnSInTtgS2nnRqfC4+vdCXs8tvyMvp/xJgY7Qos4
/HiE/q8Iv4w0Bl8mQEtgNaZCxdDzh+BY8tsfmBFethVRGzQEBaF6qM73odnv4rofANTc5sauB6Na
7jWesawHxcq0CL/prwYH7K9lIFQu2t2qTazNC6+fk5e3k25N2+VjfT5/w+rjyVtb2VuHa0PH9OWS
yjR40W9H/6gyuxtcnJAz3fAA/ckj7dmYJxFd/RJmXzh15uaM1LspFU9HPT++ye3ypF9OBh/2OG9p
nzL0lk/cduvBS+0nX9uxwyRg2tv4gyFN4hzLxwf+ZOhzzDRkeKO9ZzeO9/bfEtThlv7JE69SWVOy
r3tF55naT+s5LljDz8/+r81ictavduvY9Z/pZupPr3u3mEsmb2bN4zkz945GYo3HR/E5gooWTDLt
a9iOTjPa8dThWLDt3pWd916kmfd+UZo258yG8pBAq2tFLpuUvxk2sawHFlKrmRgZDRrbB7BXhtJX
RIxxL2i8ZSACj28NRkN2Zlbw6mVQKoBGJiezIQ/ysDrQNQgetyGfAbKsqIEyQiOLITCNfe/3Ym/0
nnhvK8esgA2d+/9q+E/capCCpIXHMMwgZIFWgwaDL0MmQzJDEUM+eGQ+jaGEQYEhhKGSoQDISweK
JwJZGQyVC9UaVHBWryWVBfnpRYkFGZUKaMUbSxMjg8L+ZzsiJRmsRGZJdfie+zx1w5zJDote8RmH
s7yzKHb782fjupnvHxg8ruv6+voLc/XXqzE/v5bMbeDO23xrnT5zHkvBK+Zr38Q7dQ+0TDVfet6u
JTacr/LkDckb+/8ad8+7s1lh0Xa31zvr5r9df8Du2Kv9LvcvOu758VJEssv742RG1/Pxxjzd9et6
Fjv3nvjj9z957aTDZw3VQ4u3JGyfyPL9JG/ZOo+KdUyzGk6tm2hipnbsWQrPgj6mk7nytevqwkyP
XBau2eSkNHXm+Sq/grLF67SPKj2vKr4eu6B/4ftwf0MmbYEyl19T3GSSpghX99c8aVF+sHi2nznL
MZ+0VS+W3loaoVzbaXBRXmRhE5O8QROTNCKO2AybmHiAQhx0T6LoNRJKB4MdmkQXxBpIIKdEbsQs
ECPQTrgMqyE/sKq1MDQwAla0RpbGplEYCZHpvwrf/W2JvbF68QYdrlJf1z948wOtzAIlkfvTD3tx
6N7fcVJ62U1F1uM8b9LaVP47MZ13/rD3xEKFsmmP9jyc3Cfk8EhNa9Gyid2JPRI/z2htDJBq/1E9
8VXwUYcXu3Vj+8+5TErJC0tQdeI+3sbU4PhOaWb1UaOqgHc5HU9+mYl/PdY9KUk2ZNaVp8JCC6/N
Xff9f7gVs/vLq+8iPqfZOaZ7x23ft/dmq+6T8B0nJq5OKsyyXy7Mcei89pnSezO7KisKmte6zTq0
ubnTz91KuzlY0WjFv1fH7UvKmA6sW1UUHLsj43jda0PbjFnqDZ+3sG14fnmHoE7TpZz96+8XbnrR
nLRiG2OZwS0+h+BN0ayfv28xS2ENVhTtTnfLE8jKjRQOytvCywAAbNbLQA0KZW5kc3RyZWFtDQpl
bmRvYmoNCjE0NyAwIG9iag0KWyAwWyA1MDddICAzWyAyMjYgNTc5XSAgMThbIDUzM10gIDI0WyA2
MTVdICA0NFsgNjIzXSAgNDdbIDI1Ml0gIDY4WyA4NTVdICA3NVsgNjYyXSAgODdbIDUxN10gIDg5
WyA2NzMgNTQzXSAgOTRbIDQ1OV0gIDEwMFsgNDg3XSAgMTE1WyA1NjddICAxMjFbIDUxOV0gIDI1
OFsgNDc5XSAgMjcxWyA1MjUgNDIzXSAgMjgyWyA1MjVdICAyODZbIDQ5OF0gIDI5NlsgMzA1XSAg
MzM2WyA0NzFdICAzNDZbIDUyNV0gIDM0OVsgMjMwXSAgMzY0WyA0NTVdICAzNjdbIDIzMF0gIDM3
M1sgNzk5IDUyNV0gIDM4MVsgNTI3XSAgMzkzWyA1MjVdICAzOTZbIDM0OV0gIDQwMFsgMzkxXSAg
NDEwWyAzMzVdICA0MzdbIDUyNV0gIDQ0OFsgNDUyIDcxNV0gIDQ1NFsgNDMzIDQ1M10gIDg1NVsg
MjY4IDI1MiA2OTBdICA4NzZbIDM4Nl0gIDg4MlsgMzA2XSAgODkwWyA0OThdICA4OTRbIDMwMyAz
MDNdICA5MTdbIDQ5OF0gIDEwMDRbIDUwN10gIDEwMDhbIDUwNyA1MDddIF0gDQplbmRvYmoNCjE0
OCAwIG9iag0KWyAyMjYgMCAwIDAgMCAwIDAgMCAzMDMgMzAzIDAgMCAwIDMwNiAyNTIgMzg2IDUw
NyAwIDAgMCA1MDcgNTA3IDAgMCAwIDAgMjY4IDAgMCAwIDAgMCAwIDU3OSAwIDUzMyA2MTUgMCAw
IDAgNjIzIDI1MiAwIDAgMCA4NTUgMCA2NjIgNTE3IDY3MyA1NDMgNDU5IDQ4NyAwIDU2NyAwIDUx
OSAwIDAgMCAwIDAgMCA0OTggMCA0NzkgNTI1IDQyMyA1MjUgNDk4IDMwNSA0NzEgNTI1IDIzMCAw
IDQ1NSAyMzAgNzk5IDUyNSA1MjcgNTI1IDAgMzQ5IDM5MSAzMzUgNTI1IDQ1MiA3MTUgNDMzIDQ1
MyAwIDAgMCAwIDQ5OF0gDQplbmRvYmoNCjE0OSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl
L0xlbmd0aCAyMjY+Pg0Kc3RyZWFtDQp4nF2QwWrDMAyG734KHdtDcZrLdgiB0TLIYd1YtgdwbCUz
LLJRnEPefrIXOpjABvn/P/Fb+tJdO/IJ9BsH22OC0ZNjXMLKFmHAyZM6V+C8TXtXbjubqLTA/bYk
nDsag2oa0O8iLok3ODy5MOBR6Vd2yJ4mOHxeeun7NcZvnJESVKptweEog15MvJkZQRfs1DnRfdpO
wvw5PraIUJf+/BvGBodLNBbZ0ISqqaRaaJ6lWoXk/uk7NYz2y3B2Pz6Iu67qurj398zl791D2ZVZ
8pQdlCA5gie8rymGmKl8fgAH/G8nDQplbmRzdHJlYW0NCmVuZG9iag0KMTUwIDAgb2JqDQo8PC9G
aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQwMjcyL0xlbmd0aDEgMTc2MDU2Pj4NCnN0cmVhbQ0K
eJzsnQtAVFX+x3/n3HvnPcMM8mZkBkYoGREFFESC4alG5gM0pkBBJdE0UdSsLHHLNHpYbblqbfbO
ng5g7oi1utm2ZZpumT22FB+910f9e5gP7v937owGu7jruCHbej7H872/87r3d88998w9DFyBAEA4
igi1BSXDhnyTvtANdHkWZs4fUlBYdPvRu4YB2fYEAH11yMgRJTeOfW4VkB01AM9HDSkZk7c7r3IU
0Pm3AkQvv7SktGh64hQVtrfiXmMuKy0Z2ttkugUgvhXAWD6iJDnFnHLTCgByFMsrR+ZfVnryxux8
3P80TA8cWzC8bOR9U78HSMXjW+6fOL2qdsnE601AFs3DNk0T5862P2p9/2sgK8oBVKVX106evvV6
90ogi/tg+trJVXW1EAFa3B+Wg3nytOuvHl+76CIgqzwAmqaaSdPnfXVi+wsABTuAuFbXVFdN+mRs
4d247/ns+DWYEZxqTMP0Wkz3qpk+e94lT9J6PPcyAMdt02ZMrHq85yOfAFk9CSCqaXrVvNrg6QYj
1v8A69uvrZpeXXxd75uAbI4A0PWqnVE3W06EZehPFiuvnVVdG79r+EYgdz0EoP8jsL6Xgspvl6cO
HR+U9b0mWgOMx/ZflMi2b9z72u+OrTk52QwaAya1Sn0GbtXZbZdDvhmOrTl2gxlOl/gRr2E5xjKI
AapkUDBDMozFkufxuAxBWELuAQk00kopFXcQ7dsKf4WrabBGonqVSBliKyTKm2BevuIBUjo83w4u
iLXHSe+2jSKp6mzS5AIiyzLuPUHawM4URJXfJToITm099H0YB78SVM/C8q7at1gHRefSjj4Li35p
X7oDug2md7cPHA6Hw+FwOJyOkNVyS3f7cLZI0b8eXzkcDqc7ISC3aDCagc+bHA6Hw+FwOBwOh8Ph
cDi/foxlakLgOdXZt5jTebajQyqA/Z1zCw7nHCD/vso5VOX8GwjhvcnhcDgcDud/HwEEwpAEgVB8
/omQ/q7fBEc1MmhAI7eBFrTySdCBDlUPelQDGFCNYEQ1KRoEJlQzBKFaUE9AMFhQe0Awagj0QA1F
PQ5hEIIaDqGoEajHIBLC0Y6CSLSjIQrVqmhPiEaNAav8E9gUtUNP1FiwocaBHdWBehR6QSxqPMSh
JqD+CBeBA/Vi6IXaGxJQExV1wkXyD9AHLkZNUrQvJKImgxO1HySh9kf9HlKgL2oqJKOmQT/5Oxig
6EDoj5oOqagZkCb/HwxSNBMGoA5WNAsGol4C6ajZkIGaA4Pkb8EFmai5MBg1D7JQ81G/gQK4BLUQ
slGLIEc+AkPAhToUclGHQR7qpYoWQz7qZVCAOhyK5MNwuaIjYAjqSBiKOgqGyYdgtKIlcClqKRTL
B2EMDEcdq+gVcDlqGYyQ/w5uGIl6JepBuApGoV0OJagVUIo6TtHxMEb+GiphLGoVXIE6AfUrmAhu
1ElwJWo1XIV6NZTLX8JkRWugAnUKjJO/gKlQifY1ik6DKtTpMAHzr4WJqDMUrYVJ8ucwE6pRZ8Fk
1DpFZ0ON/Bku6aegzoWpqNehfgrz4BrU62E66g1wLeqNis6HGag3QS3qzTBTPgALFK2HOtSFMBv1
NzBH3g+3wFzUWxVdBNfJ++A2mIe6GK5HXQI3oN4ON8p7oQHmo94BN2HOnah74S64GfVuWIC6FBai
3oPaCvfCb1Dvg1tQfwu3ynvgfkUfgEWoy2Ax6u9gCZYuR90DK+B21JXQIO+GB+EO1IfgTtTfK/ow
3I26CpaiPgL3oD6K+gk8BveiPg73oT4Bv0V9Eu6XP4an4AH5b/A0LENdDb9DfUbRZ2E56nOwAvV5
eBD1BUVfhIdQ18DvUT3wMGoj6kfQBKtQm+ER1LXwmPwhvASPyx/AOkX/AE+geuFJ1PXwFGqLohtg
NerL8Iz8PrwCz6L+UdGN8BzqJnge9U/wAuqr8CLqZlgj74LXwIP6Z2iU34PXFf0LNKG+Ac3yTngT
1qJugZdQ34J1qFvhD6jbwIv6NqxH3a7oDmhB/Su8jPoOvCK/C++ivgM74Y+o78FG1F2wSf4rvK/o
B/Aq6oewGfUjeA31b4p+DH9G/QReR90Nf5F3wB5FW+FNeTvshS2o++At1P2KHoCtqJ/CNtTP4G3U
z2GH/DZ8oeiX8FfUr+AdeRt8De+i/l3Rg7AT9RDskrfCYXgf9Yii38AHqN/Ch6j/Bx+hfqfo9/Cx
/Bb8AJ+g/gi7UY+iboGfYA/qMWhFPQ57UU8oehL2y29CGxxAleFTVD6nd/2c/s2vfE7/+qzn9C/P
MKd/+U9z+hdnmNM//6c5/bOzmNMPnJ7TZ3WY0/efYU7fr8zp+/9pTt+nzOn72s3p+5Q5fZ8yp+9r
N6fv/ac5vVWZ01uVOb31Vzinf9hNc/pOPqfzOf1XN6f/2p/Tf71z+pme0/mczuf0zuf0N/4H5nTA
GReM5fowDQhAxbP/UY6m8+yO31oHsL9zbsHhnAP07Kuqu86LCw6iD+tuFzgcDofD4XC6GkOEln3x
HcDKRtt5dsfnUL624vyXEsDa6gw/RuCcA9QQ0d0ucDgcDofD4XQ1xigdLmsE6exb6DvP/k/XVgF4
wOGcO8LZV+Vrq18Oaozqbhc4HA6Hw+FwupqgGD0uhKT/fG3V8Tk08JUSX1txzgsBrK10XefFBQcN
iuluFzgcDofD4XC6GrPdwNZWAbzj09h5dsdfFQx8pcTfMso5L/C1VbdAzfbudoHD4XA4HA6nq7HE
GXEh9Iuvrfj/4MD5LyWAX1c9w1e0nHOAWuK62wUOh8PhcDicrqZHggnXVqoA3ogW1Hl2x+fQwFdK
/J1snPNCAGsrQ9d5ccFBeyR0twscDofD4XA4XU1oohkXQoGsrSydZ3dcWwW+UuJrK855IYC11Rm+
ouWcA0JoYne7wOFwOBwOh9PVRPQLxmWN5gwvVu+MHp1nmzqkAn/DGn8nG+e8EMCfAp7hK1rOOSBE
9OtuFzgcDofD4XC6muiBIey/hQ/gr/bDO8/u+BwawFrtnFtwOOdAAL+ueoavaDnngBA9sLtd4HA4
HA6Hw+lqemaG4dpK+5+vrcwdUoG/YY2/k41zXghgbXWGr2g554DYM7O7XeBwOBwOh8PpauyuCNCC
PoA3okV3nt3xZ/yBv2GNv5ONc14I4A/7QrrOiwsO0e7qbhc4HA6Hw+FwuprYvEi2tgrgjWhnWFsF
d0gFvlLi72TjnBcCWFuFdp0XFxxibF53u8DhcDgcDofT1cRfagUd6AN4I5qt8+yOz6GBr5T4O9k4
54UAXpoS0XVeXHBI8Zd2twscDofD4XA4XU1iqR0XQqYA3ojm6Dy7459hmTqv9C/g72TjnBcCeGnK
Gb6i5ZwDUmJpd7vA4XA4HA6H09X0LXeAEUzms28R33l2VIdU4CulADzgcM6dAF6a0rPrvLjgUPUt
724XOBwOh8PhcLqalEkJYAJz8L+veYrenWdbO6QCf3t1AB5wOOdOAGsre5c5ceGhSpnU3S5wOBwO
h8PhdDUDp/WGILAE8LbppM6zYzqkAl8p8fddc84LAbxmJa7rvLjgUA+c1t0ucDgcDofD4XQ1mbP7
gBl6BPBGtOTOs+0dUoGvlPj7rjnnhQBes3KGX3/lnAPqzNnd7QKHw+FwOBxOV5N/WwouhMICeCNa
eufZHZ9DwwJ25Az/JTGH88sSwGtWnF3nxQWHJv+27naBw+FwOBwOp6spXpYBoRAewBvRLuk8O7FD
KjJgR6L+fRUO5z/HfPZV+3WVDxcg2uJl3e0Ch8PhcDgcTldT8lQ2hENkAG9EK+w8u2+HlLXzSv8C
/k42znkhgNesDOg6Ly44dCVPdbcLHA6Hw+FwOF1NubcQoiAq9uxbFHeendohdYb/YPhfYA+4BYdz
DgTwp4CDu86LCw5Dube7XeBwOBwOh8Ppaia9UQxWsPY6+xYlnWdndEgFsFbzc4b/kpjD+WUJ4LUt
ri5z4sLDOOmN7naBw+FwOBwO5zwg+KMViJKehCm0yFQQYSiwP/7XAAUVxMFwLJulctnjZBnY+qld
Wt7vCyc8rdX+/bSDqOB0JqEUcH//UAGjKJ29z/06zx7SITXm7Pd3isWBNzlrfrHedOWPKc115WRf
kjU4c1BG+oC01JT+/ZL7JvVxJva++KKE+F6OuFi7LaanNToqMiI8LDSkR7DFHGQyGvQ6rUatkkSB
EuhT6CiqtHsSKj1igmPo0CSWdlRhRlW7jEqPHbOKOtbx2CuVavaONV1Y8+p/qOny1XSdrknM9izI
SupjL3TYPdsKHHYvuXJUGdp3FTjcds9BxR6u2PcothHt2FhsYC+MqCmwe0ilvdBTNLemobCyAHfX
qNflO/KrdUl9oFGnR1OPlifcUdtIwrOJYtDwwsxGChojOuWJchQUeiIdBcwDjxBfWDXJM3JUWWFB
dGysO6mPh+RPdEzwgCPPE+RUqkC+chiPKt+jVg5jn8LOBu6wN/bZ1HCn1wwTKp2GSY5JVeVlHqHK
zY5hceJxCzzhNxyI+DmJOw/OL1vcvjRaaCiMmGJnyYaGxXbPI6PK2pfGMnW7cR/YlsYXVTYU4aHv
xE4sLrHj0egid5mHLMJD2tmZsLPynV+1o5DlVE61e7SOPEdNw9RKvDRRDR4YfX1sU1SUa73cClGF
9obSMkesJyfa4a4qsDaGQMPo65sjXfbIjiVJfRrNFl/HNpqC/IbB2N6oPl2mWEp1ZhWPPt2zhHnk
GIYDwmOfaEdPyhx4ThlMqjOgYWIGVkPcBFt5JuEVmeLR5lc2mDNZPmvvkeLNDnvD94AjwHHw7x1z
qvw5qnjz98BMNk5ODzUsP2V7nE5PYiIbIup8vKboY7aSHpDUZ66XOhy1ZjtusPtgJPZtlTszGbs/
NpZd4Du8LpiACU/9qDJf2g4TopvAlex0e2glK9l0qiR0DCupP1VyunmlA0fyWuWGDvVoEk7/CzKH
9SisyfSQsH9RXO0rLy5xFI+6ssxe2FDp79vi0g4pX3nG6TK/5emRXyZEU79FowWlFAdl+enKLFFm
8Ijx+E+lDOpJXrUGR6WSQ+xFHnPlUJ+6dbGxZ9nIKx9hrZTNz838bnoynR3TgzukO7hnaBDQYTGB
Fpde2dCg61CGQ813wGH+DY54KC2Lted7YAzemfH4zytvymDRHe1xYZflswo4/nxZ/mSHitF+242w
0ZnUpwgnuoaGIoe9qKGyocor109w2M2OhvX0VfpqQ21h5amB45Vb7oj2FN3pxr6qIZl4U1DIa3SQ
JaMaXWRJyZVl680A9iWlZU2U0PzKPHdjLywrW2/HyV3JpSyXZbKEnSWgmOBJNlGNUj96vQugXikV
lQwlPdFLQMnTnMojMNFLfXnmU3kU80RfnkvJY7A5Jr+0rP3oUW5JdxLAeigVLm5OiLDteFnoDa0Y
qdC7ydnTtl64SOjZNNjm8gqO5uDQlKDcJMGOx0xW1I46A+MajBsxijBeiMF8M+oCjPUY12DciHEH
RnxGQGWldowzMK7C2MpKhJ6CtcluM+deJERi20g8hyAhHA5jlDEKYENNxjgC43iMSzGuwqhS6rGc
GRgXYNyI8YhS4hLCm+5LRd/Dm+5QNs1Tp6UoySpfsrxCSTZf4fZth4/ybQuG+apl+qr1T/Nl983z
bS/q49sGx6fUs63OmLIpN0wIw5MMQ8drUQl9DYIIARs8IoSCByMVVP4clxDc3CshZdVGQQQiUIHg
Y4FN3iSQJqMlJVdHZXoYgsFGD9GDvhJ6sNlkSVmVeyndB2swbsQo0H0Y9tK9sIC2sj5HzcG4CuNG
jNsxHsaooq0Y9mDYTXdDEP0EkjHmYByPcRXGjRgPY1TTT1DN9GM2PynK7ByMlH6MaqZ/w9P6G2oQ
/Qitj+hH6Nq7TemDUtYrhjPZb9ji/UZ4tN8IDkvx0neafuqNIyoBrzSOqA1CHGRDqhDXFN/f5hUi
mrKm2Lx0f7PdaXsktx/dCR6M7EFyJx55J9gxjsRYibEWowqtXWjtgnqM92B8BKMHI44yVDNGO92C
cSvGXdAPowvjSIwauqMJD+Ol25sS8my5YfRt+hcIxx7fRt9Qtlvp68r2LfpnZfsmbmNwu4W+3hRj
g1w9lgO2MePWjNtkLJfon5p7BdvkXAvdiH1nQ03GmINxBMbxGJdiVNGNNK5pki0Yd7IBtmgAazbB
l8r2KXhMA66pNldCPg5AO5OEzEvQQlllX5VAXQnLVmCSScLd96HFJOHWO9FiknDDQrSYJEybixaT
hElT0WKScOV4tJgkjChFC8VLH/5Dr4ts6SOuIfbcIHod9tJ12EvXYS9dByK9jgX4SWS+PdiUmIg9
ttLl7J1oq28h9S+T+tGk/jFSX03qbyb1C0l9FqkfR+qdpN5K6mNIvYvUbyAZ2BX1xLW2Q3KQK4LU
byH1L5D6OlKfQOrjSX0vUm8n6S4vjW0alqpsCpVNcy676XB7STbOPkE0Fns0Fsd8LM4JG1G3Y5SV
lAsr2eN8lSNj2DauOTHHl+6bmTIjdyjdjA0342XYDHswiniBNuMw2ow72Yw7CELNwTge4yaMhzHK
GFVYOw4dX6poEGoyxhyM4zEuwHgYo0px5zBGCjP8Lq5RHEv2Oz2CpehmDHEYYmmsq6fZanaahwpL
rSQohoyIkWNoOoSx1wQGWzQWLzGu+9F49EcjaHO19G66FHrihbjHv13a9FNPm5csb0rYYMsNJb+D
GBFHHRkECSQetxlQp6QHgFXDtmlgpc/hNqXJOhabBTUl9LG1EBNrtc72k/WA7Uurl6L5hXWD7X27
VyRNtvcw57l1tp3W221vJns1mPNygpfgpsWuVF1vzbC9sEWpuhALVjbZbmabdbabrENs11iVgmpf
wbg6TLmCbKMTrrQNxf0VWCfYXHW4z3W2HOs4W5av1gDWZp2tH7rg9JmJ6Gxvq3JQR4yywzHpXlLj
6qNepi5Tj1APVKeo+6hj1TZ1T3W0OkQTrDFrTBqDRqfRaFQaUUM1oAnxyq0uJ1uBhqjMbKMSmYqK
baZM2WKVTXpEQ+FS8PQQimlxSR4p9myaCMUT7J4fShxeosOnFcmRRzzBxVBcmufJcBZ71fJoT7qz
2KMeeVVZIyF3uzHXQ5fgp3RpmZfILGtRNFsXrAdCLIvuimbbixfd5XZDRNjcnIic4GzLoKKCTqTS
r86fiehg9/QsKy4p8zzb0+1JYYbc013s+S1bOKwn35IjhQXryTds4y5bL2STbwtHs3whu8DtLvaS
sUo9sJNvsB6OmG+Uehr8YGb1wK6J8dVb6asXj+2xXi+2wXpaLcQr9eK1WqWeSFi9xrpehQWNvXop
dcLtUKfUqQu3t6+zJR7rxMcrdcLqYYtSZ0tYPavjyVaqWK1YJcaqVCFRYFWqWEmUUmXsz1WS/VVu
P13lduVIAvm5jtVXx9h6qo6xFes4z5bqPKeTNA92Tyxni65KR2E1xkrPHXNrIjz1E+z2xolu/2os
oXLCxBq2rar2uB3VBZ6JjgJ74+DyTorLWfFgR0EjlBeWljWWu6oLmga7Bhc6qgrczUNGpqV3ONbt
p4+VNrKTnY1kO0tjxxqS3klxOisewo6Vzo6Vzo41xDVEORYoY3xkWaMG8tz4jK9sm6leh+O1MjrW
nRdmrs1WBu/g2Iibo1vwaWU16HHJY8DlsxEjK0rKTcplRXhPsSITW1n7iyJuHhwb3UJW+4vMmG1x
5IFz9py6ORBROKXA968OwazZc1iH+9RZdyawrBAXyQV1swGKPYklxZ4cfJptVKsxt5KdkifzVJ5e
X4jP9r7MvpiZyTIF4XRFlpfF8rRaf8V/vv5z/Nt8dhfU0w3NxBVDZkOdW/DEFJdSnApK/UuYFnyW
Yh8PdW48wTriJHWn9uF32+kEXxrYOZ+Ks+f4LX9fzPZvfS2xSd2pLjkN6yzn6R6bjTsEqQUiMUZJ
T0OkmAARAPLnGL9g27Yp8hesnG3pVzjRef0RYDW8QKbAC7ARXiVHsNUaXAisBfYIVAAPwXy4Hxbj
x9qVmHM7jMYgYf79JFJeC8nwKH6wPQrbsO4VcDO0QBiJkL+EBbBIeBdbLQIjxEEujIQZcBe5TJ4D
5bBHvAXS4TK4FmpJvVwm3y3fJz8BT8J64Q35JOghCiZi2CYfkj6QP4YkbPEArIA95D7tS+DCo9Rj
zd/DLFgpVIhEniwfQw9i4Tr0QYThsI1sok7cezV8TiLIfCEf9/K47JFfw1pWqIAaWAktZAAZQmOl
cnm4vA3C8BjzcK8roAnWYfDCK/ARMUhH5CfkIxAJfWAYns9aeJtsEtpOLmzLwR6TsJd6wyAsmQF/
hL/ADuIgf6IzJIOUIrmkG+SdEAL9YQx6+zS2/Iz8SG/GsEB4XSyS88CE/XIv6234M+wlUSSZjCBj
aW86gz4szAINHrE/hkkwBft7Oe59Nw6jddRAtwuPi8+Jx1U921plE16RBHgQfg9/IkY8UzupI78h
u8h+mk/H0wfpPuF+8RnxHXUVnvU4mA53wXPwIwkmGWQUuYrUkPlkMbmXrCDbyA7yBc2lpfQaelio
EWYKr4h5GErEOvEW6TbpDtUXbWVtr7X9te1HOUW+DUbheFiI3j8AD+OZrYft8CGGPbCPSERPTBjs
JJaMITdiuJncRR4jq8kzZC0eZQfZR77Ej6TvyXGKn7RURaPx4Yc9AjnoLHzCvJ8+RLdj2EH/Tn8S
woU4wSkMELIEtzADvVos3IPhJWGvGCVuF2Xs5xRpmbRKWi09J70qHVEZ1L/Bz/itJx4/mXhydxu0
LWlb1tbUtlbeC6F4DfHTAxdcWeh9FYapeL2X4YhbA+8SA/ZdFEkk2eQy7JnxZCqZSeZhT95KVpIn
Fd9fJC9jL71PDqPPRmpVfO5LB9A8OgLDOFpNZ+LD2H10Ld1FjwlqQS8ECaFCojBEqBCqhdnC9cIy
wSNsFT4R9gk/CCcwyKJOtIlxYoLoFIeI48U54sPi5+LnUrn0lvSpSqearrpN5VV9g0812eqR6lHq
CvVS9Tr1Tk0ljs7N8BL8of3PiEmrsFAoFF6Cu2mqGIlLmLdxPI+HScJwiiOVriZL6E1kLe0lzVMN
poPJ5XBETMC+fp2uoj/QwcJwUkxKYCrt79ubKkR8FjdZ4mY4KL6M5/Y27nmeykBupodVBmjCZ6RB
eMw/C/1Ep/AWfCTsIWrxUfibqCPh5CB9WhiJo+AVMVsqg1jhIXhRmElugpdoIYDuuOZOHMeXk2dx
XiglKeSoIONj8OU4itKF/XALXEM/gIN4Hy+B35FJ4mS4G1LJfPgcnsK7ord0rSpRFUrepFPEBtqD
rAUqPoNnN4j0IoIUAreSCmGl6jD9EObAdlEHu4Xn0fvt9EVhuHhEGk1q8A64CW6DmfJCuF4qE98h
k0EgYyFebMXZbb6QIsbidgHOKuU4p63Du7sF54FcYTjmRODIuQzHxRicIVZiWI7zhIgjaAre41fg
LPY2rFWVUi9MlkwEZx0A8a220XCl/BSskCfDtfJ9kITzwWJ5Pu5xNXwKS2E1WdR2I9TiUvJDvLcv
k4rodqlITqIN9ENaQpd1vL7Y2/EkAr7C8CImsqUN0CC+DyWQI98pv4ej+2KcYVfABHxgPYBneQiP
MFTYBKltl9NGuUioxfPdA6Pkp2Ub0UGNPA1GwMvwpFqCKrUTr7GHvIPneyNU09HybKG6bQr2w1Ls
BRf21hycf27Hp2FlwpPYd0dqgFhLrCUeBZ+c4YRd2HTCJcFxsIub2Hc9HvR2KX7KSKCFmxpV7AdN
TRQkL13j0muyVDptppilyiQk+cDJA5Bz8rOc6EarUpqApRRUOv1bgjZTyhCzIAPrCVmU2gkhb+l0
+oWxjy7HJ9/Lzd9VZA03HzQfwF0cMB+CnJzh5pOf4ZNvs4QPJsScZc5yu/v36yFYUi2CMCA19PP0
PWmPbyfTBC0pbNtw4se2+7dtY76OE5rpdYqvepizHj8ijzbHxadJXvmoKy6hd5pepcNOwrWTJKn0
h7QajSBQUGuydEHaei3V4pOCK9QYlKbdTQQxixKX0ZJGIg0zn45gLjqzhp/MMp90VmSdzIKcLObU
ySwUYgkeNIjF/v2I09mDuSekKnpPyrakT/pv6yc0k/AjR9q+9ClbjizHuzII/TTTA42U9eh60Mg/
uPQGAx2jMRktdAz1yofWMgOdP+S6mFmGYFYsBRkELRCq0epNoNFSnV5lNtMxerPRiOqVj61jtfRm
8MqfrWUlaBxdGxSkGCfWslqQjA8X2xTBrt60ybxjxyZLcPggp1M5BSdE+y6zy6a26/WqMSpFBUVF
RSVFNV75W5eDWdSg1FAZDGibmGoNTHWKqpkHRqPS4KjLxqwEiRjsuuC0IEUkgwDEpAeNhlAdO3G2
N8VQdrKBjoVg7KuxLiMoBwLlQHBqt0DYuXyX/B26npOVk5XlO5kK39m0ez6Ldi0AGqQJodEaca7h
NsMb2JWGYYZhQUJvMd7Yx1QmXCXONc4zLTZq9FTSDDIONI2gxUKB2qUZbswz6ZbTFcIy9TLNauFp
tSqYBplM/SQaIklUYzAa+0kaNDWG0UGjiYtQqtFodXq90Wgymdl1qgyuD6bBLXQ1GEn/Jsmu8ZL+
Lp1Bq7O7DAv0RN+CJ2kieiyhXqJ3aYMI2INqzcTspWP/YJcqpXpJwNtqdbNlsDvCGYm3DN40ETgi
D0ZFmg+iHXU6caACInJyspQheipEmQ8eXCz1dS6+6bXFfSPYpn8/fFDW44NyDD4ovwIG+TiOwV1A
5V0ZGRluXCAbsOxiLFsPRvloo0nHcpWHZaO8c13sIFOf2EFGL5rpg0wp6Yr5UhLmJg3ydbl71swK
mFlBKtzuVJxawsIHppNYi8OCj1WW5TjHX9UvLHIAfjpLG9rGrmkrk1qOf3vv0JEPCieOFYlvHR8g
th634x1dJH8h7ME7xQI9yRjXEzoqGuONacYCozQgZID1ClqqGx1SYp1MJ0nV2okhldZNtp3Sez0+
ify0x6chh8O/jvy0Z6tNtoXZbM6orLCsqOKoWts9NnVf2svYNyyTDjAW00JjUcgw6xW6scbJxk9V
n4cdI9+ZzCRUMOnNQRBt1astoAu1CvqIVALxlqB4s3mHhZgtLkulpd4i2lx6PR1jc7H7yhLM7jeL
V/7OZWE3nEVlMqFGKGXsXtGzwWsxmc0qlvaNbgu7J/LYMLbMDu61Ub1dvUctq0WbOkc9Qi2oY9ju
1RHsnlbHsB2plTtAbWAt1FHK7RUZkzbSN0UpVMwcfvDkz2uKipk4LMwns3ByPoh3B0YLm67w8lcQ
doViB6gccQkJA9KCB6amhIXjFEtCwlJTBg5IS3DEqYSM6tcWvDdn6s5bKpclN5+0Pz9n7pOrb5z3
6G0P33n88VVEaBiVS03Himjw1i1/ev2jra+x2W0RTsWvi9l4zd50DU7uQcwicYhpYj4+gF4tzhZV
WotGq9Eae1i0RhA0RG9VqYkKdNqL79EQTZy9B+lB4yzxBNh8bE4dmHaE/QDHDjugFT+f2E1/alpz
WVgHg8h6B1Ssp5Q5jvUvsKsQFhR0erLQKDPF5cFDXotwmn/4uXOcWScPmCu+m4Xdk5Nz0IJT+aBB
ypQO5jcXm5TbpGIWqUi1pIYOxA4KV7NeUatCLYsey56Sc9W47Ly8weNCYsSER2cOzXz6oiE5lbNO
7mS9MJ3soDX4PKUH23p8MClxmbSqrXboh4N6juGKp5kXFQch+SB+rqWxng8NYddh+gM1Ux54YErN
A/TtKfffPwVt3Jfcgs8Lq8m7+Gkd8QpQehjn/6+xk480SiTZzC4sTnWxA2LJ6rZgcojEv+hvI0X/
+zZS9LFVUtXPbQicqc2nPx8H2lpI0c9tNGfRRgM/tmjatTGfRRszHG4x+9owQv3hGlxndUHA9VIA
Qej7L0LjeQjv88ADDzz8z4RvuiKIeh54+C8M8WKO6OaBBx544IEHHnjggQceeOCBBx544OHXG5Tv
rDLpH8H3F9oAUxUVlF9I1ykpZlMwwVdw6i+5x8FWvy22q8N+N/GY31aBiST6bTVMOF1HA/2U/+qd
2VpoIBl+20ifJa+e/jvkAeI0v01AEh/12xTU4l6/LUCy+I7fFtvVkcAgfum3VaCWiN9WQ//TdTQQ
Idb5bS0UShq/bSRjpOHsL9NFAY9lUD2m2BLaZlWTYquU/FcVW63kv63YGsXerdhafx/6bF8f+mxf
H/psXx/6bLFdHV8f+mxfH/psXx/6bF8f+mxfH/psXx8yW9fOf73i2yHFNrTLNyl2m2KbmW9q3z57
oB2stip2SLv6ocp+fHZYu/xIpW1fxY5W6vj22bNdHVs7u5dSP0uxExX7UsVOUuwyZmva+a9pdyxD
u3zDqXN55v95+x6wqK5r33XOmXMYnQMaYtUYgxNKCRolBI0x1GeNpZRaJITQCXPCI/xnQIRhOPOH
mXGYoVxrvWgstTa11FovpZZrreVSSy01xhqrNk2NJNZEa6Ox/qs1xhhjjHXub++ZQZImfe/ru99z
vt9e6+y91tprr7X2PudkgJCZMhGRBwEzFZGNqkGXUBM1Ajq1kp33fB5XDvCsLUd/HZdIx8ij1ICP
mQrRVwt9nVr4VTVoNaRdaKsg+Sj4Ougy2TouUw7o3F4VZJaBOmgp+pqo5l/y5aOSWR+ak3lUS07w
bJ4ssnDvWqLaZnoIFjJoLrg0WKqjSow2YZx5o9P0UbaWwLd/9KpohMvmfrkh3YgZzfQYLNRwi2x0
FvelCRVZx+fN5yM29DDPWmgm+gr4uhx8pI7H6Qm0TshXRb02I2OP0DzkzgpNJ65Z/FpBnTzuLLK2
aJxruK8672tCW8X77Xy+Vp4HZteMHgf3iUlWRnWqo9fl3JKdz74MUjofY1oV3IYezVZDdJ2NI15E
NGJ+OEbJ2nmEq+BxJZ8jEg8395tF5OPXELlmspWYzckjUsUr8aORYBoNnEuD/HRQVmUVUb8/3nbj
/8Pab1uvGsm9g++DWC5jtfpxK4jN/o9+fXZUjthKImvR+XyxXcDsR9ZahR43X3kT31n/rBLKP5T1
ap6dpmgbWVWEd+LKzlsz99Y1Us0RO0yyARL/rIbSf2zOzHgww1xkqzYvaWps0lvt1ebPNznsTY5y
va6pMd38aEODubCu1qa3mAurW6odruqq9EcddeUN5roWc7lZd5RXVS8rdyw1N9V8spVYZ1ZEs7C6
1tlQ7siyVDtaMGx+KD1jrjltSV2lo6mlqUafzqWWFI2YKmJNtqPcXddYa36spqausto8y1zYVFHX
aM6vq7Q1NZS3zDQXlOuOusq6cvMT5c7GKpg2P/jIvExrk9O8rLzV7GypNus2+FzT1Kib9SZzVV2L
vQED5Y1VZrujDp2VGKkGLW8x26sdy+p0vbrKXNEKtWpzA+ZsZCYwwGw4eK/d0VTlrNTN8MNtgyOj
ZgCta6xscFYhXuaYE02NDa3mtLrp5uplFbA9Srrxn87OxavY6h3VLWyVLKq3J2DqI7Y+y1eUVodZ
9OplLAWOOsxa1eRubGgqr/pwEMojS692mLGiJkyF1qnbnbq5qtrFwgwZW3WD/cMRSsf52MT3HTt5
G1Hh7ORsFeJRVfW4Ps9P4dj4E6izyE5hO6JK2iD9TPq19BzwS2mntHWUrXJ+UsWuT3Lb1R+aq/pD
1rg9Q5LhQcOXDV80/C+0j0C6HDuB7bHIncAmbBd+gMcxtvPZ3cLBT2xmI/JsSOH76JP+n8YS/6sz
d5AQDkf+us8S8blk8RFDKtHC1+WduDZHCjr2L4x/9LnwrUcL8wozMqJ/ZpI9iakgl4XrsFaAh75O
EsTV4ndIEjeIG8B/V/wu+G6xG/z3xI3gvy9eBv+2eB38+xI8kBKlRJKkO6Uc8F+Uvgw+TwqAb5Pa
SJSC0lXw70o3wf9dugU+zH4jwEDsqdCgG3TwTkMreK/BC95n+Ab4LsM3wa8zrAP/LcO3wK+XM0mQ
Z8tzSJIfkh8GP0/+LPj5SjYJyhcUzKvkKUvA5ytPgC9iPwSsWJQnwRcrxeCtylPgSxQdvFNxgncp
bvAe5d9IVFYoXwO/Uvk6+FVxPSTE/TDuhyTF9cb9HPwO46MkGhcZ/SQZlxuxOmObsRv894yXwL9l
vAr+3TGYZYx1jJukMR4TnkZNY03xJJkSTGngp5tmg59j+hH4Laafgt9ueh78HtNe8C+Yfgf+RdPv
STS9ZMIztemC6W/ov2R6B/xV0zXw75neA3/dhMib3jfdAP8BkiepgvobPKHtVX8Lfr96Bfw76lUS
1Xfjx5MQf0f8XSTFT4l/kv0SbDTnIt3LIx+JeSTa0ThjjYVYUZERcTMWG7Eio2YsBV9urERbY7Sj
dRlb0XoRDRaHENp2Yzt6vmr8KvgO4wrwXzN+Hfwq47+DX4tYsShdicZERDTuBz/T9ADWkmHK4Ov9
K/iLpot8LS+g3afuw4p+i3WxVUxEOyl+EtYyOX4y+LvYuqLrGUvrhSGSyx3lFWSubHU00IJaR/VS
yrdVVziotKFcb8TuH0vCVwqzzTQBOyuMGBjIFOXwHsNjQ3w3sXeZ+FHXAt4HEkauBew8WMoryjXT
xKiEiDeDcVFewuh4umNptaORbLxt5K3OWy+7IVGQtyt5u5a363nbx9uXeHtq2dJlS+kab2+xVlB4
m8DbibxNIhp5c/toK0Z/0TlGBfaXEuC7zN7U4O9YrF7lb4fwlhLpTsTlU1jRJLwTsd+kupum0j3s
zyDw/wPNx+l9XJ+I9Rs+RMfB/ifR6XgKLsF52IBTz08d1EnrqJt6aCsN0BDtxTvbK3ScTtNFuko3
BYOgClOENGGukC3kCUVCieAQuoQNwmahT+gXdgp7hIPCYVjGG6awArPjbTQxAz6C3mODp6BmitB7
T0f2QnJHhM69FaEPH4rQR9IjNCtSF8IXr0Vo7okI/dKeCH3cTAb2K+WP95HC/sTa035SUEBC+enI
/JUbmTckVDlwHQe6MdJfNRih1ekRWjuRyxnq0usW1Vnq6qNXR+su1lP9hMhV/ZH6C/W3liZGrpYG
l65bumXpUES/IRChy+ojtDGbSxmbkpoym3KbSpv0plVNm5p28N54e7d9u32v/aj9YjM1T2hOa57f
XNBc1exp7ox462B/t4HR0og1R02EtiyMUH0gQp0XInLu0iit4dUmuNeQMM7OI1RHxwUFecsUFgql
gl1oF14URXGO6BD94ipxHbBR7BH7xf3iBWydBMkMLJbskkvaLx3GPWKKodjgMKw0bDZslTPlTdJ+
+aBiVuoVu9KrHJcS4pS4CdDAJ25RXHFcaVxVXF/caWOWcatxn/GQ8caYqWMyxywcUzNm3ZhrY+eM
7TflmRpNnab1pk2mPtNpNVHNVi3qOvVIPMWPjc+IXxRvj98Q3xPfH/9K/LUEY0Jmgp7QlTCYcDDh
aMKpcYZxyeNmjluMak8JP0MPh4/R/PAx4e3wM8L7wAfhZ0QBGBM+Jo4FxmFcoAlhG/aHxOVt9AiQ
FR6Ano2sGNeAEmAHriUaF76H7gCY9TjoDIzSsXGdEvTtwKgBo8do3K3rdAeQghED9+cRICviF3Y0
l4G98dBgdu8Bkrh9G2ViLBt8DpAL5MFyIehXQC2gxaAa9EqAeFjJjlrJhpUBWBngVrKBXPTnwVoh
KNNmmsxPFVrPQOsYtJ6B1jFoHYPWALQGoMU0jkHjGDRYFC7hRIitajzmYSu7B5pJYd+oubKjnmbT
E7guAi2GjBUQ6UsskvQZHsln+Kw7KI+dNJC8AxBH+gX6OWQlHmMLj/8xksVZ4TJxLpAHPB4eEovC
Q9gP48LToDMNT0g9yHM28pyNPGeLU8JbxPuomGT0HkPvMfSyzO9C5neRhN4XRq4MQmb4TXFq+DUx
JXxA7Ay/SWOF9PCbwgPAg8BsjI4HJgFmIBlIBe6H5BhhZvhVYRasyeFXUV02WLXBqk2ciPkQU9hk
f6kHc9EEyK6G7GpYz4HlHFjOged98MYGH23w0QY7q8X48EYxEfyd4QFxMugU0LtB7wHM4RysrEKc
Hs4hEXZfxmwv44RnVYxK/b/yR2HSTDIq9fWYFI1D7/PQfwY+nkUEzsLPs/DzLCSfRxTOIgpnxbuA
aYAZSAWmA/eHz/6D3ZHZR/Lw6ofyoERr6gbq6cboKJCInGxELjbSvdGdwvOMmpuGmpuGOY7By2Pw
cpqQATwIzOZ1MPSRaB5DNI/B82ki9MUJ4XxEIh9RredRvQc0CeeCGWOfDhcgOs+In0HffTQkpkFu
OvpnhPNxv415Oh5xh7fR6n/mE3L6US8+nNOJ4D8+r608r6z++hH9fljsh8V++N+PqL8GqX5EvB9S
/Yh4P54J4Nf/eF0lwpIb8w/AmhuZ6INFN3xwQ/sYvO+D9jH4sxEWjsECq6w+WHDDNzcsuOGbG9nr
Q+VjX1H8P1TTx1VS8keqiWmdhNZJaJ2EFsviSUifhPRJSL+MjP0BGiehcRJZ+gO0TvLYHYDWAWgd
gNYBaB3AXAegeQCaB6B5ABoHcArE9j3b86ZP1IvppEb0MMsBPLeMCyuoSIV+HHZTH9AfHsbJtSNc
xls3ntp2IOILKFt8NHxe/ALNEnPDw+KXwH8ZlJ1iS8K9Yj5OssfBP4k+jSaJDaDLINMI3k2zKEHM
Qg+zkMs1z0OzB5ovQ/O8+BjGHsc1zkJYOC9agWpgGXz5FDSHxAWQWMgtDIlf4FaGYGUIVtywMsTn
fwx+RKyshoUhsRRyNUADeOZLE9AMvjV8Hk+dH7NuzOTGTG7MMoxZVos58C8X9Muwyixq4EuAUsg8
DVSArwZqgFrAhr560GWgTlAX4AFaYV8RlyAW+XylO8VyxNOG62WIjcjnWwqvxkYjNByJEMaXIN5F
AIvp06gnG4/KeTJGoxCL5TCicJ7H8nHwiB/uNKOjHZl7J/sdeVw9xWeeRGOiGucj9gHm09LIKGJ1
HrmbRCaeu1gG2LxLQB9DTCJzDSMewzxfiDCe68fdWo6TZTlOlmGcLMOI7uqRyC6E1O3ojlorr4bh
aDX0cKsaz2EZ1t2LdfeKbvS14m45bsQfXpGQilnKA7+EV8Lq6L11J68ntroyRBErwptG7Anox+Fe
+NYbzTyrsSFxISQjVodhsYfXVcSXHmS+F76sRtZ7xSqgGn013LcysQ6UZX4pz/5qRKJXbAGcgAvw
AK3h1ZSK6FxGdC6PRCfiRQ+8OB+NUk80QkO8yvP5nojE+SmA1d//hkwkMm6xDOPl3KsesRJ8FWg1
+mtAawFWk3Wg9cBS8E2gdsABtAAegNWnMRrVIT5zHiwuGcnwTlgcojjuV2znRfzaGa3IYVRxLt/7
rJ61WGWzE4TtHLy14UQZVUdD0SjvRO6Go1XA8jc7Wldl0XOgB9XH84Laj2X7MWhFqm4IWZ3EfOP7
nO1rNZrJ3mit9ozaI6ujtllV9USzdx5vVuX8jIicV81YyThk+2Uu8zR6yoByXt9Mnu9Ttl6xkdf7
ED9RdMDNPRim8dDGDgPY+XPbAjvRXuZ+sogtHZkzYqkZ1vXo2TQ2djbB0nDUj+GohWFoMx+GuaQI
nWG+R8dEZxwe5e/QqJNvmPmJtT41am/ryJBpRO/pES9ve8hP8OipiZlwPiG/sDGLnxXlLPajzoyG
qG3mj8h7WTQlPgOzzE4c4ygfI+uJRb4pGn0m8XJ0dOdHR/mqDTzrtlEn1NjYnuaxZ3XB444zNhKx
6GogOR6SsyE5m/qgr0XPwtsak7hGJEtnsWcimiwG7miFxY1EbLT3Md/GjGQ/Fs/b2Y7Fchgr+Mgo
ovR09GoZj14DdkAz35U8NyzasfxH765NI/7EIhrzPDbKZhJH1hs3cse7ffKU4eQp43f8MfxN4f/0
liDSQ/y/PRFNwEegFGLf/E7HR6IH8DHQbHxkSD2EZ+KH8YmjRygL7zfz8RlLX8LHRF/BRyUraXjn
K8FnHP0c71DjaS8+icL9wiy6U3hAeIAm4n1+Nk0S3hbepruEd4X3aIrwvvA+3SN8IHxASSL7YyLT
RFmU6V4xThxLyaIqxlOqOE4cR2niJHESTRfvEu+iGeLd4lS6X5wm3ovKTRFTKENMFVPpQXG6OJ0y
xfvF+2m2mC6m0xxxjgjfxSzxUXpYzBZz6HNirphLi8TFYgF9XnwC9+LFokUspjxRQ/0/JlaJNfSk
aENWNLFetNNTYovYgqdPl+ihSnGFuIJqxJXiSqoVO8VOspGgVCl97FtuOkFziOzdwGYSHMdBtwDb
wJ8CHQB2Aruj2Ae8GMVhomYb6FHgBHAaOudALwCXgWvATciIgBFIACYAUwAzkArMhM4l0ExgHh8T
HFf5uOC4AboAyAYWAwWAhYQWpL25BKggcvYCW4F+EpyDoLuAvUK5fbMjy2FoCdh3OwprSh1V9gsO
O8dNh6vZ6NgEfmtzSYvKaUWL2nzR4QdW2rc4Ftq3AQOOhbUZjoXNL7UU2RVHjn2nI2dE5qijGH0L
0bcwYr92bXOPo7S5z1Fq3+co5OMvgp4AvT2vfxRfar8MCjSL0EuA7DXgpmMTrjc1mx293C9Gjzq2
Yo5duD40Qq85jnDcdBznuOA4BZxrTnUcb54JzHOcAs5B/1RzQYvCke24EeNja68pbUliaPa2zOBY
0TIXcSts7nRsYGto3g4/N8O/HS3UPNQyn8UiFoPmiy0aUMbWHo0x5GGfwey4EYtfDIhXHothLG7c
1iu37dkPY/2nR8Vtt6OY520ffDhau36k/6Pjo+KImNgZkN/SUbFuH537T5BxNU/AuhMca4B14Nex
fIDfwPtjmBLJD8vTaPCcGSN5g0/9UToYzd8gfN370fw1ZyJPLF8LkKMF0VwxbG/p4DAj5gWgDOhv
WdWiMERl1nKM7mf5XQzMRL1sjtY1cgzbkfq2RCj6j6M/MVb3nNo4vYHryaBrQBNj/c2NqI8gaoNh
NK/f5lFDKaifDI5OxPOoo765C7F7FuDXteubN6KmbudqJd8vJSwHLYti4DURA6uN16P8G8CZ0bUX
24fYd2zsYksNrl2gDYCj+YrjUvP1Fk/zrSiN5KEf8T/I13V7n1wCrrK6RzxzEbd8Ns7R7ZjD9ySr
AzGa4/3IyR7sgyi1724J8PrnNcn3QaxmizEfo8nMx0g/aOxsGF2z0Rpk9Ygc2VnN8ZqK7n39OrMB
XMYev+w4p9/Cfj8KXItcOw1YR8Ht60h9OJM5RtVKbF28FoyRvPNrI7uG/di12JLIgJzOdaZh7fxM
aAk0dzrT2Vqcc+Af9qkzC/QEWxc7PxzJHOKo8wu+4+5i4t+cEv/O1Mi/LR3Dv9NM4N9mjuffY07g
32Dezb+7vJd/a/lp/o1hKv++Lx1WfiO+JeJ+Ik2TppEo3SvdS5J0nzSdDNL90v0UJ82SZsH6A9ID
NEZ6UHqQxkqzpdlkkh6S5pIqhaR/owTpa9K/053SaukZmix9Q/oG3S19U/oWTZW+LX2bpknfkb5D
Zum70nfpXul70vcpWfqB9B/0GemH0o8oTfqx9GO6X/pP6T9ppvQT6Sc0S/qp9FPif+OCHpD+S/ov
ypB+Lv2cHpR+If2CMqVfSr+k2dKvpF/RHOnX0q/pIek56TmaKz0vPU8PSy9IL9A86YD0Mj0iDUuv
0iLpj9Jr9AXpmHSMcqU/SSfpS9Kb0puUL/1F+gs9Jp2VzlKBdF76Gz0uvSW9QxY5TZ5JT8nz5Wwq
k3PkHKqTc+XFVC/nyXm0TM6X86lRLpALqEkulAvJLhfJRdQsW2QLOeRiuZhaZE3WSJdL5BJyyqVy
KbnkMrmM3HKFXEEeuUquola5RraRV66XG2i53CjbKSg7ZJ2+KrtkD62QvbKfvi4H5AB1ykE5SKvl
drmd1sgdcgc9I6+QV9BaeaW8kr4hr5JXUZfcKXfSN+U18hpaJ6+V19K35C65i9bL6+R19G15vbye
npXxoe/IG+QNtEHulrvpu/JGeSN1y5vkTfQ9ebO8mTbKPXIPfV/ulXtpk7xF3kI/kPvkPtosb5W3
0n/I2+Rt1CNvl7fTD+V+uZ965QF5gH4k75B/RVvkX8vP0Tb5efk39DP5Bfm3NCAfkH9Hv5B/L/+B
dsovyy/Tr+VheZh2ya/Kr9Jz8h/lP9Ju+TX5NXpePiYfoz3yn+Q/0W/kP8t/pr3ySfkkvSC/Kb9J
++S/yH+h38pn5bO0Xz4vn6cD8l/lv9JB+W/y3+h38lvyW/Si/Lb8Nv1efkd+h16S35XfpT/I78nv
0SH5ffl9eln+QP6ADst/l8M0rAiKREcUWYmj15QxiomOK/FKPP1ZGaeMozeUO5Q76KRyp3InnVI+
pXyK3lQmKZPotHKXcjf9RblHSaZzSoqSQpeUVCWV3lLSlDS6rMxQZtDbykxlJl1R0pV0ekfJUDLo
qpKpzKV3lXnKPLqhZCmfpQ+UBcrn6e9KiVIiSEqpUioYlDKlTJCVCqVCUPDUWCvEKXVKnWBSlioN
gqo4lBYhwTTGNEYYb/qZaVC4Q8Xjr3CXalANwhRVURXhbtWoGoWp6lh1rHCPin9CkpqgJgjT1PHq
eMGsJqqJwr3qBHWCkKxOVCcKn1Ynq5OFFHWKOkX4jDpVnSqkqkmqWbhPTVZThBlqqpoqzFLT1DQh
XZ2hzhAeUGeqM4UMNV1NFx5UM9T5Qqa6QF0ofE5dpBYIi9RCtVB4XC1Si4RC1aJahCfUYrVYKFI1
VRO+opaoJYJFLVVLhSfVMrVMKFYr1ArBqlapVYKm1qg24Sm1Xq0XStUGtUF4Wm1UG4UyEsR5YuD2
83M1nkerK0ioxXN0NZ6JqxvBbwbVAS8QjGIF0BlFF1FNGuizwEagBzp49q7uA7YDO4AhYA+wH3gJ
eAV4HXgDOANchM420CvAdT4m1A7wcaEWz+3VtzCHARgLjAcmoh/P8TVTgWSi+hqgAXCQUO8BDQAd
dDfNoxwqwJsR++kdD7VTJ62nTXhXHaBdtJ8O03E6Q5fphmAQEoTJQrIwR8gRCkjSdjyVrA09labt
eQont7ZKO6F1a6fBBbU3tC7tDDiXdlBr1w6Ba9Be1DzaYXAV2g7Npr0Erlgb1Eq1g+Dytc1akbYF
XLbWoy3W8LaiZWlrtBxtHbgMba02X1sPLlXbqM3UusBN1fxasrYGXKJWo03WGsAZYTdBawQ3USvU
DFoxOFUrst7QNHCitsB6Wcsm0XpdW2g9o+WAu6TNsB7XMsCd1mZaD2uZ4PZgdL82FdygNt+6S0si
g/WEthgSBZCwWI/ChgHtYvQWoNdivaCVQHqV9YR1rRXrt223vmFdYdvxP3ZPlPnPGxH/SaPIz/SM
4T9PM4n/NMxdJCAr7XgzVpGvmUQVqKMK1FEF6qgCdVSBOqpAHVW8EQVqqeJiFKilypWg8LIC9VOJ
+qlE/VSifionAqidStROJWq3Mh1A/VdmAQuBHCAPKASKR/WXAlVAPWAHXIAfaCeqxTtlLd4na/E+
WYv3yNrTNNOaZk0H5gBZtQnWHGuedaJ1qjXZetBaZV1orbcWWoutdqvLWmr1o223rsRnjXWddYN1
E3p6rVvx6bcOgt9l3Vu7uLag1sI49lNkiD9WKF4V3yVRfA+5MPBcKDwXcTwXKnLxCDLy2ZGM3IGM
PE6TlSeQl6k8L/comqLRNORlK5lN25Cdz5g+MP2d7jOFkaMZ/x9nEmgh6TzX6WT853nCeWEs1ou9
xcHiFcWdxV3Fz9awn04xiu+I74C5Jl4jQc6Ss0hUCpVCklB7VjIoT6ECZdNPTD8hxXTLdIvi/iUd
IfHSnRgnVdhFOHNs8NWWAEwAppAYRK3ZzEAqgJq1ZUav5wELgOzo9eIoCqIyFqBkBIJNJzFkIBHn
ohgayynZKsCPB79vFHaibyIwNQLWhxIVQ8kRfY60KNKj8nMArDS0EMgZkb/tE85+WyOAc9/m5TaY
z1wnOi/ZcB+wreByYigv2tf5LwD3D9uzo4B7iK2Hx0OsCJL49IoRkK0v0lfB5t7OfeP+8esdn4jI
+BCj4p8sq9y72zbpuU5vW69lfetg21Y935nQ1q8Xte5qG9TzW/diVEPPLr0M7V69pvVg20G9Qfe0
HeI9g7qj9VDbEd3TeqTtuF7WehwyTP4UdHe1ndMD4C9xa1f1IsxyTs8FfwOSpyBZ1HouSJYtno1B
Re9wJgRV3pOor2q91Narr229Gpysr289hLbbaUO72ekNJln2td4IpuhbXJeCM/RuLwUz9G2QSdIH
3DXBufpOtPP13bxnn+dicJH+olcJ5uqHvSp6jqKdbNnnTYRWt3dyMF8/4U0KzrWc9qYEi/TT3hlB
Df2JkLzgzQiW6ZehWwM+EfwF79xgg+Wod37QoV/zLgoS2lz4j7gFPfpNb37boFP0FrXtdRq9Wtsp
8GVY43rvNraKUe027wDn0ToLeA9bXTf6d2Jd/9A6Ld7dQc1Z4t2H9dZ4XwxuRnu47aDlmvdoMMlZ
4T0BO5/Q6ru9p4NbeMsk0eqbebsNuinOBG9NMKBr3gZ4a/NeCG5zNqJ/QPf4x5bvck7wOoLknOL1
oDV6A5Dxeq8FX3QGvTeDh506JHdaOnxi27mlZd4OyJh5BCJaqd78YEe0Z6Z3VXCVMxPtWuc871q0
C7zrg+ud2dzm6HaxtxvRW+zdzFvGr/BcQb1tc+8OHtV36luCJ5ydPmNQdXb5EoJlzmcxywBWtDN4
mtdbP1/XbuRiSzAx4qGe772MqmP9+5wbfRPajluu+aYELzgzfWbEcFXrruBly1HE/5qzx5cavGk5
7JuJ6PUx3rmd8ZbDrbtCon7Tl4n6ZLk76tzhmxcyOoe8c0MJzj3wvN+5H3Xey/fOoPMl34LQBOeQ
Lxujr/gWtw0iU6dDovN1XwF03/BZgoucZ3wlWNGAZRXjUatH9X3OLvCLEc+9kN8ZnLx0PeOdF30V
8OeKz4Y9tc3XiJze9InwzeLTQ1OcEzh/3ftiyIzI54dSLTd93uBp563WwdBMl8EXDGW6xiILveBX
hOa5xjObrom+zmBKhNd3+7pQCUx3gWuq71noRvhkxlvW+za29bvSfD3lh1zpvr62c6weQqmuOWxF
rixY2AqvKsAv9G0f4XN8O3AysFilYEXgUXvgXXmMdxVyvhgrOu4qhZ1sVxXs8LyEsnXNNxRa7Kr3
daLfzr11+fYEk1x+3xC83ebbD769dWpwlWul76W2g855vlfaDrpWel/k/Oucx+5wrXF2le/CmdAR
KnCt870Rsrg2+M6ESlybYL9C32YZCNlcvThJktgJFkrgko1slpCuH/ZdDGVjX5/DqXXYmxHKdhrh
ySnXHJ6L7Ch/JTjZtdWZEKpw9bs95cnYBah2y03vtpBXd7B6QMyvBzXXYDTOV+D5rgjP9mAk/nyf
Jrn2snktu72JWPVB363gYdchvwFrPwKZTcjplfKVTotnQnCR6+DyhqDiOr7cEawB7+F8gPO3+4/4
/ciU7s0oX6lr/vGonKP+iaicMv9WrOiory+Y4j7s3t3e6z7aerV969Iydhdwn1je0d7vuuTvbR9k
Z2z7LqfZ39s26D69fBXyyHnLNXb2ui8sX9u+1315+frgIvc1d0f7QUQv0H6InfztR3C6qu3Hndng
T0G3O7jbfbP1VPs59M9tv+QaxMl/Ff2bUQNbfUPtVz3i8i3BbtcRRHuTx4j+KA//5wa7l5YFRFT1
Ye9A6Iz7QsCIebsDCaj87MAEnBgV7BxzjQ9Mwbp2M96y3j8VuxhzsfPTn4xqPI7K2eU6hXtTv7PL
n9Z2xHXKn46qPuefg8hf8mcFO1xX/Qvbtrpu+HMQpXx/VigVcctDTW7zF+JUyYVkCrtrhIKWVf5i
3lMaWgDJqtAKN/nrUcmn/PZQp1vxu0Jd7KQKPetWPRVtB92Jfn9QdZX629kdypUGz7vcSmije7J/
JSTLfEPBm+4kL4V6MOMaZMrjX9d2yp3i34A73Xr/JuypXH87qmKrvzfUp3ewuyruQSnBMvcMnF2q
O8N5BpVs0LtD21HJx3EKbdHLQjsYHxrC7HmIxtrWc6E97rn+/tB+Z4V/a+glRGMw9ArszA29jpNz
MPQGTgychPpu5qc7EDB3TMF6qcPs6QykdqR6ugIzO2Z6ng1kdmR6Ngbmdczz9AQWdCzw9Ome9izP
9kB2R7ZnR2Bxx2LPUKCgo8Cyz38pmOLZE7B0WDz7vRc6SrCvN+IJAfdrrKU4UAJ+M9vvngTkbtDz
UqDiq5quubeFFrP6CV1Hfm2hxSy/4PcEGjsq9N0BHefDvoC3w+Z5JRCEV6/Dq0bPG/BK95wJTIid
IZZtgRXBm+yO0OGF7pRgB05U3G0xVyfqqgv8btQVeFZXwd2Q6Qp2ROrHdYTz/P7ovoC71WbXykBC
cFWM9+5u3+saZLXnKg08y04DxuvbwKfAzsa2q56LgZ6OoNPMeH1LoCc415UX6IvVJ3RHeN0R6OpY
4TK4bnR06pvdu0M2z5XlSR1dnlTf9o5nPdcD21ED23DCTPDcwpPPgHsL7oMpLHcdG1nuOnrY7ois
InTGdal18Ktr2c7l0YvsjhPBlFZDYAdq5iZW2u1O8vWFzujd/sHQRfd85OKinosnqBT3IlTCFZw/
c0OiG0+DoevYO35W8/5dvN0LmXz/wdAt9yL/wXYDk0dbhHasc4X/UPl4yGchO0f9R1iL3TfZrXmp
fbzlsv942w1WS+jnc7G2faI+oF/A6VHmDoy0NXpu+9RIq+90drUno/JPhXrcDf5z7Wm8TeftHL5f
bNx/W6TSMCNhRof/attxt8d/g53PrDLdgeXUvtDdoeejDbhTyqfqJ5Yr7Tm8TWZtcK571ZPGkAWV
OZetFPHx6heWq+158KSovdC9Vi+rmO9ejx2NPbU8sfyGu9u9tr1YP+1eW34DkTwSTHrSuHwy4olo
hLzuouVJsHB5eUqwxp2Lne519cJPL8tX8Bpr20v1bl9fexU7h9ur3GshY3GVsszCTw2eHMbs9ZGn
MlibEfXH7t68PAMr/W/yvgYqquxK99xLUT/8WRYEaUS6KJEmNE0THlQACbKoGyO3qmjig6rCGNom
xBBiCG0AgQVI82N8PuMjhpCOcTqM7RjTY4yPoX2EMYa2HUJYLENo2+cjxqBteCxjXMRhGBcx8Pbe
997iVjW2ncxM1ltr1ln7O7v23Wefv332OfdSxYXTaXv9vtOuXqgd5C8d3FfYYm1vdi00N78i7Ot0
nX7FVVcOu2T8vrMtOe3tdWEt+e0H9w20bGs/sk/bkvrK0X1DLYUwesMtxe09gDvaj9XuaNkFUaK3
Zff+eYiQ7W139o00t7f30R6x6BpvnO9gDWFwel+EKDEB6zqirqn9VEN040SHFna6po4QPIF3mL6E
dwR99WVwtQ/P8x1RyHfEEh9fV4487pgdSa4F0KlC+SsRtcPAV2Bk60itvd642MGQBznxdZfwHqTB
jKf9OqG5ucMKa4e1V9Qboa75uilsD66Rjpx9p6EN+Q0JKG9I9sq3kbyQ+GLk26vqjzSOvWTB+4X2
rXVm0J9tSAOdHfX3Yc+ax77APgV8xy7iIQKjhdqBhnvtEw2ZwO9uyHUd6thD8t0o79hLfAPpbG0Q
mg92tDaILWfbzjYILQPEDwEvtgx3dDYUtYwAJsAePU/76TDsMs0dh2onYc+9QXwO8ReJ7ya+qi6i
ZRz29BmIjSfVfP01GMOEBhd6cn0ftLm3YWeLtuM48duIPwH6kxBjy+sqO067DrVMdsQ3VAJ/FuUd
Aw3V+7Qdp9/HD5H+cENYy3WY9zTXZMcI+P/1jvHa3a7xjkkVf534m8i3W6DN2R13wEtT2yOJL0Ye
Y7LCd9zF8wmcIS0tIa9Mwb7WDGeA2paQjrn6MbwThDPMzbbdroGG1zoWYB3d7HgE54EbqF/XBnPk
y9M5oa6t7Tj4yUU889S10Y52sZNv4OvaOvXId4wTH+Za2KeFU01ay53OiIamlrttuxvaWuYgKt5s
WXhlpuFAy6M2a1d9V3NXe2PzfmNbfmP9fmNXHqysdvBGiEjgM3gXOYcRu23HvnFYTaKEjUGtFzrf
aDS2Xuo81xjZtLfzfGNM62jnhUZL65XOS9I9cmNiU2HnKN5pdl7Bu8jOq40prVfhVCDd4dK9rXxX
q7pjle9V6S61Mb11yvdeVbobbcxune6casxrnemcbtzaeq9zptHR+qDzXuP21oedDxo9rQ+hFNlp
LGtdaotqrNiv6XyI9XYuUb2pWG+XRr6bxnvnVLx37grClnQZqSWpKy3pipR6IUVIvFPuisF75K4Y
qV945w6W6f4a4xKWBT8fwR2ky4I7SFciSrpScA12RTZW1VV2pcvWjlM7a/YHdWU3tu+PbG+Wnk5I
TwwaD+4b7tpaWwznnMHGI/tjuhzyswi662/s2W/p2t54bH9il0d+5kDjJj9VoPv3xv79W7uq5KcW
0vMBiZeeV0Cpjm2NfftT2i82ntqf3nGisWp/dldZ45n9eV0V+N8q6FeHTPWrQ55+dajR5+s9LJB+
aRhDvzSMo18axuvr9c3sef1+/X9nVvoVoY1+RVgU/NHgVFYcfDf4HttJv3x8kX7n+DmoI43Fs08w
xgT2WRbNytkrLJ3eb1TMutk3WAnrY3/L3OwUpFJ2hp1jO9iP2RB7kY2wd9lLbJr9lr3M/i+7x/ax
BbbMWjieS2Jf4w5xh9k5rpd7l/0D92vuDvtnTZXmy+yPmpOa77NlzQXNW1yAZlzzDmfQzGp+x63V
LAQGcB8JjA/cxG3UHtJe4DZph7VvcR7t29q3uR3aUe0vuc9o/7dOy31eZ9Ct476l26CL5U7q4nT7
uVOG/YYDfKDhvxmO8qGGbxuO8esMf2M4w683/Mgwxj9reMcwxX/K8GvDAv+C4Y9BEfwX8S9NfEdw
WPAavjPYFLyOPxD8m+BZ/nBITchrfG/Iv4Ty/D+Frg9dz78TuiF0I381NCk0if9V6HOhz9Fbn4tZ
FT0pjcXfa9l6gY4DnQA6zaJtx20nbKdtZ20DtiHbMHAjtnHbpO267abtju2ubQ7yBdsjgRf0QpgQ
IUQLZiEBf/tHc8v0Nr2N8XpRL9JvJE18Mp/MGJ/JZzKOz+azGc9v4bewAD6ftzENfZ9Lyzt5J9Px
JXwJ0/Nufgcz8C/yL7JQvpz/HAuj73MZ+S/zX2Zr+Tq+Dmzu45tYOH2fax2MdzyL0v5S+0t83s+u
s5vUMxP+ItJWwcptFbYqW42t3tZsa7cdtB2x9diO2fpsp2xnbP22QdtF22XbmG3Cds12w3bbNgv5
fdu8bVFgglYIEUxClBArxAtJQqpgFXKEfGEbyExCoVAs7BB2CbuFPcJeoUGAw7xtcSWRDqY5YYGS
yZseyemQ0C30fpIXjgMx4YRwGq6dBW5AGBKGhbvCiDAOnyaF68JN4Q7+vk73dzCakT5+jv9DIZ3V
gNdms0bw+Xzyczv49znmBA//MSsE/36XvUBvGCuiMfq0bqNuE9uue0b3DCvRPat7lrl0z+lSmFuX
qktlpTqrzsp26LJ12ewzuhxdDtup+5RuG/us7jO6nexFXZmuDNYLx47DSsJRtuCrw8BnmO0s0ADQ
ENAwy7FN22Zs92wPbA9tS4LG9lAIEoxCpBAjWGwPhEQhRUgXsoU8YavgANwO5BHKhAqhSqiBVC80
C+3CQeGI0AN4TOgTToHsDMj6hUGh2TZluyJctF2BNAr8VcArtnO287YLtkv4W0T9y/o6+rVpkM9o
NUJKZ7+AlMHeg2SFVf9b9nE2CylTV6QrYlm6El0Jy9ZV6CrYZsaFzIfSf8NhSfhutOIwoAjGueYg
jwYyA78A9CggrVjvukMU5rpLhHyEa6442rVAn82uR8UJbp7kyW59cZo7jOR4HWWKnlJO4TPdEV7b
KMeySGhL4dG2wue6o4nwOuZYj3JNIcFtputKOeSxPswVEqE+Ue4P1l0EuQvaiLm/vdXapG6bmh5X
1p+wrzvdCTQule5kb9+VdmFb8DqOjzKu4ipUDnWqCcsphH1RSGkbjhmWQ5vVUKcyNkrd6jlEG3If
84LcaT7jWCTneF3RV3K8VuvO9I6tYhvzJrkNyLe5cyk/4Ba8467kSt34GedTyZU24nhhn7APh93i
+8orfVPyo+6i4lfdruLX3Dt92qnui39bRb9xUPJoVduwP8r4+ftCuYpX+6xe7oMyfihTbJx0l/vU
oeRhj+m/0t8wv/4rn9F/kFfKQV0urSTzz706b7gri8+5q4sfus8VL7nPP3ZcVsubPuT1J+n9OfWU
y+OrjHO033x9UN608tkVIvX7cbl3XPzG2mWSxulJuXfexVVydT/Uvo/5eXetN25ccDcVX3K3Ea/k
SkxW1ueo+4D32hX3YaoX/V6J11fdR4un3K96x0y/4huUT7tf8/YR9WfcJ4vvgc4D9xvedS6XKdG4
L5QEuS+RHcUnIS8xukfRRkmk+4rXX5VcjnUlie7pkhj3VRrDJM+gK9Vz0WX1XHbleMYwrrvyPRMk
2+a55ir03CC9YoiJGC/95xjG0BUF9v3lsP5L+jzbye93rNThnfNdntvYB+9YP8n3yv3Wtr9P+ccr
/7gkjxG2ybXbM6vEENcez33XXs+8q8Gz6B0rpU7/eKz4zWr7k5+8xOKeonFGSnHPlKS776n3qZJs
94OSPPfDkq3uJR9byj4LVOLwaEq2e4KI93iMtOcqpNgp80RSXuGJKanyWEpqPInU/8dQSb0nBUnx
u5JmTzrl7Z5s9V5actCTV3LEs1W995T0eByUHwMbMI40v+q9PUHyg5JTHg/2l/p4xlNW0u+poHKD
nir1eJVc9NSUXPbUl4x5mksmPO0l1zwHS254jpTc9vSUzHqOldz39JXMe06VLHrOvC8Wrrb3KXuK
Og4/Lvf3L397ihz3sXKVv60W95tWsa/EROV8oKwTZc3rVb6EeuiLsfL+nLuSu+Kl+VZyLz2pn4+J
tT6+rM6VdRPmt4789z9VLKX+qHLvvu8Xk3zyx7W3yG88/erz7pX++6p/Xq2Kd+pcmRMlXidL4/2V
2q80KevN1VrKcB24Oku1rkOlIS7m6SfqLjUhec/hij3FNravtzTKu4axHvX5WFl/ytlYLk/xG/YJ
1/HSWO+6RzmsO1x/anuuE6Xxq569Zbuu06VJPuvQL0Ypsch1tjTV50yE1zAmDpRai/WlOcVhpfmu
odJtxCeXFhYnlBYX55bucA2X7qLPcL1YKN1N1+Gaa7y0geSgQ7lsg3hz6R7SGSndi3fx+q/r/wdj
wR+j/1z1++DfM/yPrAl/3ecrgQFsmZ6jvEjPUV7SDmvf5nroCcqr9ATlBD1BmaQnKLfoCcp7hv1B
EXw+PRe5Ts9F/g89F/kVPRe5Rc9FfofPRQKi8blIQCI+Fwn4KD4XCUjF5yIBH4M72pPsjZWnB1ae
bbPmWgWraC2yuqw7rcnWcmultdpaC9gEPG9tsx6wHrYetb5q1VvTrK/BlZPWN6xhlM4BnbeaAS9A
umQdtV6xXrWGpbdbp6zT1hnrPWsEpAfWh9alj2us0ZTM1gSoBVMaWcRP0USZoJtmNeOTAH0pfn/S
7962CWakhe2Hu9qzkLLoPjeb/ZJNwp3sVUif4H7OjbFczYTmHZaHz6ugJMc8rEzVXzOzyC1Ig/qk
nqfJfVd63qTq82HoMfb3HPTzDUjnQavceoHaiE/+1tEvEhl4TwLIEiHxcC+N/283GZKGpbDnWSD7
GEuD++sMlskM0CaBhbKtkMLYNkhrmAjJyByQ1rJC9gK09NNsO4sAn/OwSPovm9GsHtJ61gophrVB
2sDGIcVC399hT3NhXBiLo2+Htq70teBKQFrBlZy5gqsFUwXTuUcKZgruZYxtGS64V/Cg4GHBUsFV
UVPwQAwSjRke0ZhzR4wUY3KrRAvIEnMd1vicuzmPxBQxPaNPzEa0aq0s1yHmiVsz+nKrckasTHQU
zOQ2P18hbi+4UnBF9BRMk1Uj2PcmsQbsUNpSnPMoY0ysRytKsjIpZcyKZVCyOddhj0JbwB8Ujzxf
kVsF/DTRtFghVkF5DfTnKtZCqafgAbTPiO2GVkxt6c2tglJHxPaCGTEFtI+JfQVXcx1IGbNg54F4
SjxTMGWNL5gS+8XBgumcu2jBS0tWRgT6YhBYDhIvkvXL4liGJ2dENEKvkaA2mSbEa2hXqYUsKgRt
QBJvQH4PrAKJPWI9JhwJ8bY4u2VYzN4MbRTTQe++OA8tXLQzxZoYZNdi/T51A9lD7CYxEkYfegut
BE4hlFBJ0KJ2/Tk0bT/u034fsh/PGMvos5+wn7aftQ94+6ui1eQosw+ttNynFyC3D+MsS4RtwDq8
7b+ac1dMtMfmNgPGg1c2k9Wpgqv2pIxZe6rdmltjzymYsefbt9kLM8YK7pGfMntxwZJ9B2jtsu/O
7RHb7XtoDhfte+0NOJL2Vnsn+E46eC7Mof2QvRu8w2PvFfOcNc56Z7Oz3XnQecTZ4zzm7MvIc+aJ
zQUzzlM0m1CD84yzH8l+yHlKzJZK4DXn4PNl5Dve0ZRGTuzJmcQZX5lTUQO+1QPrbhZoHn3LedF5
mWyPOSdya3LmMmrIV4+JNVgCxybnrjU+Iw+Sx/GG45zCU8pznAffSYH8AtAl6D/L6MG05eyWs45R
xxXHVceUY9oa75iB8clz3HM8cDzcMrJlxLEktou3M/o+Ue3gcx1OzeZEZ5DT6Kh0RjpjqIYaa7zT
AqvzojMRfB3qcKZ8gs/Ns++l9QQ1O9Od2fZuGLsdn6jOGXfmObc6HeKic3vBktODs+QsE9OxJzlz
MIMj9nH7pP266IFewQq03wS6Y79uh56Jxza3e8frmH3OvmB/hL3PPZLzSBn3gnsOXsrFdIfeEeaI
cETjKlJkm/vA9qLDjORISG11JDvSCh5atV6itW3vdGRCnfkrccE7LxqIbUi07h25QIJDTG1F33EU
OVzkQzJPXnQdAthOR7l9r6PSnu+odtQ6mhxtjgOKd0NEdYDuYWllOo5CdG1GwtmUYoeDd7zqeM1x
MmekYAa8/0FGz4sTGG2d12AerjlvOCucVc7b4laMh9DGBzD3yfb83GNiIkTnR9AnJuZl9EnRGOfH
OSsec1pw5sU8qD3Red8571wUUwpZobYwpNAk5j1fZj9UGFUYWxgvegqTClMLrYU5hfmF2zLyCgsL
iwt3FCYVPMjtgdkyYsyFmA3RqXBX4W4cE2x3YYMUKdGDYVZHCvcU7qW98PP/iU5QlayGnpnj/5Rn
KfWMA4pI2QupAVIrpF2QOiEdShlP6YbUCykJ0nFIhyCdgHQaEsrOQhqANASpGNIwpJGUEfzvlvoX
9bvov3h+kn0KxrUAFnYAc8LpQMv+K4xeMIzzZ1k440JmQx5Qi+hvXVkDjMvJgXwI8vyAtKyzWY+I
BmRCfghoWP48AjQuyyeBrsvyYVk27FdO4W/KuSKflGlcxY+o+Dsyjcv5ddU1he7K10dUtgbkXCF1
f5RcaaO/vdXapG6bmh5X1p+wr3NynQuqvivtGpav3/Rrrz/51z+sogEVKW27I5cbl+tUxmZSJVfm
cFjVx0d+46jkkyp9JYdr2bxqbNXXlDZAnq2X8zBVGwb86h6Q51PJ1W0fkfLsiFXKD2X59DE7GsgM
lODbTp+++LfVfxz8c/86/edCTWqfVfqgjN+dFRvZyR9Q12r992+Df35TNQ9K/YrMP5d1stOAMoHa
gA58wLj8/5Ir46vkj5uvJ+Tefj8h9x9jZZyelPusL/98cpX2K/Zzs7xrJ1sAEmVeVOmpfDm7SKXj
kuyT38vxOnsnULlqzNS+gfNfmeWzDrOrgWqBmlTjrvjKYaCjWd616F2Tr8pteS3LN9YMZXljXfY5
oJMSv/kIUA/QMaC+LIrrm0/JsjNA/XLdGBMXVplDpQ/+cqhrc6LUN3UdyvXNg1IffGLgk3zNP95+
ULxaLS6NSG3afHFFvvky0BjQhGqsHheHlL6utj/5ybPfkMcZ6TzQhSyffSr7EtAo0BU/W3dWKPsq
0JTMT0tz4yXFzoyc3wN6APRQ7v9jKHtJIsXvNmvkPCjLZy/dbASKzPKJ05tj5Nwij2Oiqu8KwVht
TpH6i33cnA6ULZfL8x2vzVuBHEDbgTxAZUAVQFVANUD1QM1A7R/CP9R7ygfF5Q/rb0qurK3H7T2P
y9WxUb3W/XNlzh+XX38MPan+J8Xe1cbPf/2stv8/KVfFolXzP2d+1HYfs2euWv9q+aSqftW4u5V5
wjVwTVoHm28A3QY6KNOsRN7zqlJesY2+fD9rZQ2PZPmej5X1p5yN5fIYv3Gf2Dy/0gZae5HS+lPb
27yYtfrZW7abw7J816FfjFJiUY42y/dMNCmt45yQlf7lmFR+IevlRPn5iTzeOfErY+mdN/UaQJ3Y
rEf4vSd6ywL7z3OvyXXjf+FnIVwYvtgkaRhoBGgcaBLoOtBNoDtAd+XPc0ALQI+kz8/yMuklnWfD
gCJUFK3SMQMlACUDpcnlM4FyZbnwF5AIVKQiF9BOuR3lQJVSXUTVH0C1LC+pIak1qTPpUFL3U01J
vU/VYkrqVqXjCvfU0aQTSaefOixfPwF09qmipIGkgWfiETGXuSHpE2ieID0sO5x0OmkkaQQ0xlUJ
38Fgev83fenNIhp6p8hH6N0hkfTukKforSEx9L6QDfQdXzN9x/c5ekfIx+jtIOn0XpAMei+Ild4I
kklvBMmid4Fs+avXx3EmTvrW7BB7lrFnwJeeWfCjRzLlS3ki+E0i+FZimIrArxLBrxLNMvEyJch5
8oot0oW5T8yUiOT5K4TXLKNPpGef6X6m1y8df5/kg+WrJHybIH2Tm9GbY6R3xgTSN7mD6JvcofTO
mCh6T0wMvSFmA70bxkzvgLHQ218S6I0vifSWl4/S+12S/sPscuwsG1j5G9CGHubcNLVhENOm6Q2e
TTOb7m16sOkefX6IOdHShsEETUKQrDWYYEQ5poRIlCVYIBmltGkKk2IxIQYseu0RLkmWFDsbPGQh
CHROYTmUSzVvGMQnhzyOsZbv438CYf0t/p9YLP8zfoZt1O7T7mM2jJ5MCP5x8DD7JL2xJgrIJL8L
Js5bXgPlT0L5U/wQC+QvgK1oKhMDGpGE8nisT2EcEr71CRHfZsQyWa5KI4qZoiajJtfHWqottetj
18evT1pfCClqfWrUzfVWoJz1+eu3kY1X8Ru4/Pf570PdP+R/CJIf8T9iPN/P97MA/k3+TWjZP0Jr
AqFPo0xPvQmClv2EBQf/FNpnhBV3kBulZ3fb2Vrw5DbGnnZJZDmwwqvJcnh1ORBnecCcFodl0HzH
ctGcarmM+VMVlv44vWXs6UTLBPLK5+gkyzXUsWy33ECZxWO5jXLzTcss6YRZbljKLPcxR10kS4Vl
nsqArqXKsmip2cgUorKpG/OR0CaRZ6MWqNhL0DaFoG1Q/8Z4uY3zliMbkyR+o9WSvTEH6rtMdfWQ
nRC5XYNym+6r2nONbFdt3GE5tjE1OmljrKVv4zbLqY2FSv+fckA76jeGWJo3mqhf7dBfhT+4MYrm
Ed8JxugNWpxhh+GzjDe8aNjFtIYKQwXTG3YbvsAMhi8avsiCDV8xfIWFGPYavspCDfWGfWzNh/Zh
jjtD7yQLYfVwbmFxEA3jzst0AeiSTBDV4q4AXQWakmjDbshnpFxNcfdW+NipFYLPnCWSeKc505wZ
OxEVGRsT178OuHVF64pi5yFd3BAB3OK6IjN9jnNERT69OzZm3XlIRXGDZsFcHncQrozFjqEOaC1G
Ra47DyXOR8VERUZFxl2MOwLS2ahIsxB72+xaVxk7Yd7pJbJpPowU2x+7iGQW1mWahbgJL2WuJKmN
sfelNpqLoFxTXB/ycYNxp8wJcQ64GiO1D9smtysTahfBsogtAutye8A2tmfefADaeRlaMYbtjp2Q
+g96lXE95nJzJdQGZWNnwRLwccfgU60Z36sSwn+dhxjNf5v/NjPw3+G/w4IMpYZS8IAyQxl4wOcM
nwMPqDJUszDDy4aXWTi99SwieD54nq0LXgheYFH0XrOn/qwY5wEqAqqmKGeh35jsoO8y5MiRz0J6
TfSNA45tVemlsd34dh6vHgfR6Lvg0TzEI6qfaoul2vB9unrydEaeriFP15Kn68jTDeTpQeTpweDp
9SyULGEfGPUhkPqwidrTK7f7DNW9kWTt1GqODatkV+R2q/WGqNUcq5Fl+N+z/i1jj6Me9dhea8kS
I0scWeLJUgBZ0pMNfNNy4PvbQLUEk/2wx44FT+/8wtGQ5iGe+tggj0WNV8aznfIsqvV2y2OxTZb9
JbP0pHl/XLt72aCq3ZJsiJ1U+Z4kq5ZnUS07Ks+iIvv3msMPMwv/lllebSw4dp6N06kgGv/7eMR2
LzkjREjREUURroidgOXwaSfJKgklXoSrYkQ1pPKIWvqMvCinNkhixAGZRJVFPSSRSLGnWFLbqaYc
rzRR/ZXSZ+yL4SXDS9DnGgN4maHOgB7wofcm1k8zKP9lM7wM6BRzhp+AlE942puf8KbT4We9/AAk
QFO/6YipBpNKc9jUT6R8liydpXzFwlmvJclOfXiIJDF5gC6bKkyXw4fChxBNl9HLDZ83VP6lPTTd
B5pnTtOcacH0KJwP14eHhUcAYh4dbg5PID45PA2QD88MzwWZOVwIF4EvCndRKgfN6PBKSJlywjJ6
r8Xq8FrC6PAm0EFretlSm2yn3LQA11Cip9JIAl3ZST0sN9T+GfsHD+f/axRdpXWYgP8/n0vjMtkl
+PyqjzSRS6Eo3O4jjeXiKZbv8ZFGcNGsDT67fKRBnJF+Z5nnI2WclhXD5ySVlGcLdM6O8MpW+vbk
FW7iT/Cvg8bf8acgsv2A/wGcrM/wZ6DkOf4cjM0gP8h0MDZvMT1/GUbIwP+Cn4D4M8m/w0L5d/l3
2Rr+On+dGfkpfoqt5af5abD5Hv8exJyh4CGIOT+BU/lH4FT+U/ANPNt/g/DrhN95H/8NFX9Uxfeo
+G/JPPSdM3PQX055T+kzJIviYuHTnI/MyGHtN3xkei4MPo36yHCEOZhplYw9ZEvwqc9HNgejzsFe
pJbNsvu0G6ll02wGPlX4yKTfmRb5yCbIt3J8ZKM+e4EkG2Yjqrl+hu7RcF4ZxWSOYjJG4z204/mM
qqHqfaN6VCX/JvHlKr5MNfJfV438N1Z4WedbqrLfUtmU+C/5zJrEY18s9K1OvI+UepO4og3tl+5B
EfsBg1ggnPaCvFKfeBOyxFiohjlDWag2NATIFBoVGguIeTx8TgpNhRQVagXMCc0H+TZIJpAXhhaD
BqY9ch5P5dQpFvRMUFYbuhdsNECOOiHy1Ryg1tAddE0qjbSDUmroLsBdobtV54YPez8TxhVTD/dC
v5kpCMioIrj/MMG4mSxA4CGmFFmOen1+dErOz8h8P1A6UDZQnvTZ2MucQZ1rp9cWAc6svbf2wdqH
kO6tXTJpgjoxmYLWLmFu3LZ22mRcO2MymiJNRtB+gMkUZLKYLKRnlJJUSrFoSkSLgGTPlIK20NKK
HVM62NWsnQ4WgY8JTg7aE3TcFAPYGbTn3+3E82F3s9sULULou8QsOBXICpQj50j5QNvkvFC+hnrF
Mu2A8WwNToB+HApOC84Mzg0WIInBRUGHgloxAS9SLoBWGqSEYFfwTvoMCfIi0MXrO6Ukl1qxWK22
h7ZkS4qdzOAE0ExAW0ENQd1B3cHlwZWQtwZ1/4X3J3+R566BtWmE+GwEzzSChxrBc43guUbwXCN4
rhE815gu6zmA4DRo9ADBKckIcdNYBVQjX6sHAq815skEn9NamVM3tiYhrBcweU0mpFxImWum14i6
MUxritYIlOeuSVjjAh3Xmp1rXPQZU/WayjWVdN0lJbmUr8VM0CJ7aIssrdjJhE8iUC7w5fq9un7d
7TXlgGO6/r+65+L7eBdVJwC839Eu1fzpjpKesGOgPkezhzF4dDlTickBndpu4Ge0OLczukOEHpTr
LjBO0xp4AyLzfS3uYosBVxkXeEMLd8maaJQbUgJmGaeL0ThAclt7AHykLJBh2WXc4WYQQQPiPyfS
LjCzVIM8YkAnSgI6/zSFOoiaVpTwF0hzERHqANR8nuT3EXV7lk6AvGEZdvOA7Yhc8nIVnhS0dxF1
pwnjSFJM2E2I7b+hxe9ezmlLEXUTpNmFO5R2GrBXi3dyaTo9yfeQDmIfIQvE+1OGV0G/lCT0HCFw
gCRYlmluEx9G8huk/xohWZDrukaIo71IpRaxR2wRewH8Vby6lEuYTkh3v0swb8vhaHnp12TfoPkp
1XgeRuaHOgHwdcIeLcw0/xbhfcIplAesRz5gmCQTxP+CMIkkz2reBhQICyREObdE/AQid5f4twjr
CbMlHbITQna2oHz5D/wfQGIOhN5pjmjgvByYrIFdXfN75DU/Jfk+xMDPaN4Afgl5rgkxoJCufpck
zsB/hGObiTQ5wi+ThUtk00MYSpImsvO3pBNEGI6oE8nae4SS/RMBJ7DvhN8LAG8PeDewH0cGJfz2
wDHg72g2Av4vlHDJGjyHPo8YYCU+AfW1JtnC3wO+jXJ+v2YD8J8NgPZw/6LJAP4nVOqbiIFfJX43
4XHC/4moLSM7jxC101RjNco1WpLfJc3txEdRXWbiO0lzsyaRWogr5Q+IAZOIGpLwLxPfFnAd34JO
mmWkM0Z4BpGt51zoRYQGQj0HK3H5Pv8m/WeWVFyzHN4H3QhYjy3H+xxumsdxWEIMWA/rkuNTkedf
I74rYBv6A/H3CX+DEv51wgmUcBtI/hARogr+gmkR+YDdhEl0dUITjf2V7CDPnyb+C4RTpDlG/OuE
HsJnOYiWfCG151nCbGqthnh8pxj0SHMOkfhbkgTbALWjzhZCD8nnqOw8SX6DuDynSYNRdQRWA57D
tR/wJZqROmrtbuK/SfwJRNCpJp8HTc0VRP51KpVEkmi8GjBLOrWyZIA8eQBHiTRDSNKBGPhV4jNJ
/yihiywME1+FV3XrSOco4UfJwjfJ2hJFqmVqWwgiu0U236Y2N0l+ReP8Bc1/AV5HPhYe+CLofJxK
ZUl9JNyGuHwbT/j8axTnI5f/QNEb478ZeW4DXX0dr/Ie4t8lvp/wEOnvkeWoP0+SVEKB0LS0U7m7
g6u4p0ySfgJZSKBSdwn3kc4S4ScJpXvHtwnxbQ2wjvCJIsz0FwGPkJ37S+ex76Rzg/aUGuQDqRbQ
R81OjM9wLw3zDiuBdjdEzdPE1xE2kWal5rug+RncBTgXn4U8vx1G6U2+jfBNwjs0GrcA75BfhfIQ
hXiOVtN2wlfJ6+ya3+F+r3kPJH+DlgPMZN9D/CwiN0+SCyTpJNyOqIkmeQJJzhP+gvBLiIGJpPNt
4iOIP0d8A9m8RBIH6b9KWIPIFjX4VHOU8GuIXBTxfYjQKuRvEV4kSQxZ66aW6GULKCHLfCrxyYTj
hIMk7yHcQ9hG8jIqy+Takad2shuEbxDOyTqIvYSHCasRl3cRX0GYg3YC0skyzRd3kuqaoJ5epXHY
Kllbph0cfBzPMz/G0Vg+h/0ivI8IcowkA4hwDkHJebp6gVAgeTfhNKLGQTrbCc2EIYSzpP866dwm
m6NUap4wirCZdA6Rfg3pPNJArObSNL8E/p8Dq4hfAjQHGtHz0X+4QOS5iMBYwODAEOQ1eI68pcVn
KdcD8UxyVxtCoycCPoc7DluveR6Q9ju2hXgD7m7LvyUdk6aN9BMIUf6viMA7CCMIM+mck0r4EToR
vURoIbwMpQbRt4HHd3Ksoz3UExiAI4ZnSHaLzlp9hLekkxi2mU8IpAgQOIqIpzs+Ac+rXJk2mXAe
kSSXUJO7RPJLJJ8nyTxJ5klyKbACEc+63DwitEHS6Sb9UZJL1kbJTjfpYO0e0kmW7JNON/HdZLkb
JWyR+jJKuEgn7UWptTg+/BbqyxbNvyJiKUC0kEx1dUv2qT0nCYtlHq8WoybsJhRjqT2vU9texx4B
n0wxn/qCdcGZoYb449geiGHgP+zTOPv0l5e7DH8Jy5iVEFtrYH9PWIdxbPlHUPYHFFfDIZqChSXa
HQi7SbKIyCVLPJ7n4TR7Hq8izyVLKJ3YqVQy3Qt00+m9G8+9gBhpE1DOe0hnnmyWkU4Z3rME0hOy
wAi0A1hFsXQHliLNearlEvHHCC9RjccI58lmGbVwjq7uk5BK7aOrv6K6fkXtv0WatySbeALnyqR2
0vgsShL5Kp7hR6nUKMrhai7xudTTEFzvfzqNEql2spOMM87mqBSjZ2BbCdnyzwEjlicBY0kSQZLY
5T/C+X8YJVAe8TwiT8/ZeD21ip56Qh9Rkkp8srR70lV6Xsn3EE5IOzVdbZZ6JO2txP8IEUYc1vKy
DRHqQj4aEaxhvfWELxNWI0K8+jnOCLYc5iWIeNr9seV8BekMEnbLvNRmjBiHCWcIJwn7CG9RjZXE
32B0l4E7JvsaR/etunKKNjSGFAmZFFXoWz3PoWT5PkogMuBqitLht1YmaeQZrhqIThSRtFE08tE0
O+TVFBm6ce74LbhmYW12Y6yW7pflu1pppeBYHafRE+Qx7MXzKvGhhFsI79Bo3yX+kHQCIfSgPpw3
8OoL8mz2MvlZN3eSJPQtHq5E0gcbUBciN0/YjcgWif8B4SXSSSA8TZJk4kMJtxDeIfld4i8QHiK8
jxiwna7+jLCZ8AWqZY50skkiEp4k/B7hEl19l3APSYqp5cU048XoIZyD+BeIfwF9A3oteT7ua8/R
qK6XPRD720+++ojOXflk7R8I8+QnzL203lEzm+TjhD8j/J50wiTNj9DOnk8YTPgpwkw6J3QQryWk
ExR7mtAon15wFxZJ803EP9mXKWYuHyQ8TlhFmEL4JuH/Y+/Lw6I4tvZruqZ6RmhQkSgqICIiiuKA
qOCKgoq4AxqjxCiboggIiESJAipuqHGJUa8iQWOM+xY1rmiMS9wTcV/jEvc9xiXCr+qtdq65N3f5
/vjd+3zP8+nj22dOnT516tQ5p6u6e0axamU6Px0oqi4pvQ96L3C00Ia1LnnzAq2cLj3N+NX8zXlx
dS59qNpyvC+QR/hy4CHErStoeTfgOXAMLJQy4p2IBJ2GPfQp6K2I/3ugvwP/NuijwC+AolIR7P6I
EfYLD5TdE/qJI3p5DJoY+wMxFiMfY+nPJj4jb66bmgnLxbWbc3APRA0CPgTuAKYCxeqOCHluFdYP
7BX4Q4FZwGBgDq6/hcDd/CrQy+zPcb9A4zWBaqBABWgkwDTwlws0TRVogLwCjhkyJhcz7rdA/i5a
ewJXCqTgs6ugocFYAs5BaL4AujVoBqwIThDokZBPB5aiLw3ohtYnkHwfdDmg1NwX8miltuC8RqsP
ODfAuQ16BWg7yJcHZgIV4EOMogCYBM4sYCK0RQBhuTEeKEftCDwETj6wP9ALGAmMAmKMxiGwRNrW
HKPbDESrWdq/Aa3JoIvRrzPoMCAspz9DWwA4YwTaYI7KYb7MsUDw6QLonwY93uC3B380zl0KPaeA
eeDA/wxzoTzCuU5o/RIaOqJ1IzSAz/xBF4LuDbwJtICPCCnrK+KQI49DZQwwC5E5QNwjMnyllhfx
KSKf7RdovCZQDRSoAI24N2hMA3+5QNNUgQbIK+DwCJ+LCJ+L2J4rIlZqELTJRWoWtPGu1CZopSdk
VgqkkGdYRVPoN5aAcxD9XgDdGjQDVgQnCPRIyKcDS2GhBnRD6xNIvg+6HFBq7gt5tFJbcF6j1Qec
G+DcBr0CtB3kywMzgQoQ1UMpACaBMwuYCG0RQFhujAfKUTsCD4GTD+wP9AJGAqOAGKNxCCyRtjXH
6DYD0WqW9m9AazLoYvTrDDoMCMspqpwxAJwxcjYxaxeAJZgjItAgZ3O5QBtgOcy4ORaIc+kCaJiG
vrzBJ1IedHvIjEZfS9HvKWAeOJgvhrlTcB/b5ITWL6GtI1o3QgP4zB807nWz3sCbQAv4iKuyvmIv
XNazjMd5WWdcVVeUduF4DThMIHUWaAAqBBgIfk/gPoEE8gZwjJCh08CX8sPRWg/YC5gN/iPQ0KAM
Bl7HuUmgF4FWgGZwCkG3BN0MOAacPOCnwI+BRqDUuQoIvmE86DdorQLOE3CegS4BDW2KCdgCaACO
gEw3YFNwOgKbQFtdYA1wGgHleG2AceC0B1qAjkAfoBuwMSQ/By6EtvNAjNrIIHMWrZtBX0GrPegv
gRPQ+hi0nK9dApmcF8yR0Q/YGpJHoWE/8D3wa4GPs5SfgEOAwcCtwB2QycRZ+eCEg/YAfQ6tkj8f
9HGx8uFxFYW4ErgSGAjEuohI/lOBPIqiEG+CMxf0r5DxKnsu7rti3bgJsfoCq0e8jWNUgVixU7z3
w5aDMxGrxJvgYBdMo0AnoXUpsBq07QNux5OseJz1ZelIsbMAJwV72yvQ0AroLzgm7NEM7kC5L+gN
SXv0It8w+VHYb8Kejsn1v5Pcr2FfHCKQtRBoVIFrwX+B50Qb5f3Y0lCxYheojBdW0WPyviX6GgQM
kv1Cwxm03pL7QfgwUiBdibGchORqsSeics/oDz+gAvCME63XYPlGzMIDWNgHHPBV2M99wlvZAYHG
zsAFYhesTEaPS6DfH/0WQV5D7xp0ZkgN4i4uvwgVY2ddjFELdABuB2YDM4AWnX8SfhY4G5xloLPh
t0TgA9x5wLNFije+jPqd7dJx2PUXod8izI44d59ueQp2i1LDSbE7AEYK5J6UvQjOYV3+JKrZSeiU
UZ0CySLQRRiR4JvhkytC0thS7l+gIRa4EHhARqMe/0WIjSjMspzBFIwdPkcsbcS8ZGLGK4CeAg17
5e4S8s3kPRlocMKoUxGBg+D5VJzVXkaLjAo9R8pxOk+cpeI+A8sXreopaI4Weoz3oP8cepwKq/IF
lkPsmZ8INOG+hLpF1zASM8LRhF2z2k/QjIC/DH77QepEXwVy14z7PHcEGsfJ+IGFxRhLkHjzm8l7
IMmGC5zvApm5GIsT6CjM6SuM9AI4ReDMQV/XwQmHD0cDBwOrATujdRMkl+F5wSloNkIDfMKOIPKz
ZTWDbch0WgtWDcNT1MnAxXiu6ga6BE9a3UG/BmagNRxoAmcZcJjqwrEmns/WBMcTtAM0fApOiEBy
F3hVyoC+AG3x8tku0IInv0uAlaDhGfiXgbP1585ijVGCp8xuApkjdM7WV25CZru+HgsRdyGwvnXX
MUR4G2sMN12PwI54dj8IPRqhzQLbxqHfRKBZcIydwd8EC+uDvwyan0lvQHMrYD0g1mlKFbTOBzbF
WZPBD2IPxRUH/J3izpKCtRDB+kfpDX5j9FgXvaSCkwjvlYHOhuQ5oJ0YhSKfjFOM5YScX7xT4Q09
WOXShpDfDl/tA90VraGgnUFjvcpnSuh8CnqU9Co014E9TpKWT+Rh+Y/o8TrQASNdD5ks0A+g4QH6
PSffCgDnNuTXg74sxyWf77MyYacedVOEPWK3TgMFTcdBc31IvoDMLNC90ddi6WdVvEkUhNaRaO2K
uTuMVjtouCJp8F/i7sRd0P1kzAuaDgGawN8jEbPwCPR50HOAN2XMs1xhv6DZcuAMGc/ivh+9BRln
+HY7ei8Ax1F/FyILWcPRgN0W1wlaf8siRkSjHpNCMgN+G4/WCPSyGpzjQOxWlBDgMMT/XeQO9lA0
Ss41RpGDc3NAPwT9UNI4l6LH27DkGfBT7AsQ7SbYr4YJNCE+2QHYs0qgeR1aPwO/BRA7JpoifQI9
sMQEb6iD4G3sEQxZspKgd09YEi01Q0M+7M+X9UHNhH8yESdTUJ0EHa4GcA3zIBPIRMUeL55M8Zrz
QOzjhAy5Jmg+73i7ANgeiLtVig9aLyA2rsInW4QeZZFe38RzoqfqCKFfr4SuqGCCP5eJN3x+RV8/
o4asBY7GuEbA/h/gH3vwUW8ZATYA53PIFMEnxwQaqwlkr8C5BI4tMACc6sDhMkrZU07fB+cW8DEk
O4s7YzwOg2BPJvoNQi0NQu8cTbg6sEz0fgsynQVyGUFXg28nA7cLeV4rMnGuwFhgA4G0CDl7C3iM
4VrDZHYjnoHbBRo9IHMJtK1AdQlDtAg0bUaEVMHYe8KGo9A/nEk7YRWTWSZ6b4/WTdD5EvRL+BNV
0ajAD6vA/wGjcJbyGO/vTOZsJt5qEBYeh55ZoHvDq9UFGgNgbS+0nsRZhfK6Jq8XurVBmP1M0ILf
AX39Lqul1K97UvQ4FnQz6Pwds3YfMt6iR9N06LmAftMROaegcyz62oneLwGRd8YFwLqYzaaQPwza
S0aRpCFzUeoBzoQkPMZyQSPauVcdMfuC0wQc5KC6GnQadMaCtgF+h9YPcFYv+LwR8GeMayHyxRmc
usCLwA6oA0GgDaDtoRk5qAwEvoGGYqlHZhZoN5z1HPRcnNVeXgsEmsZDG+q8KVHaI6s0JGeAcw80
qjH3tmjFFcGEqxLbCc1FrA7iuQ6uVhGYrzqI3jqI9jrIu5niPhV6xFVSjQTdDrQT+joKy3cB70F/
IazdJ2mpB1iMvgZCMgAZNxmYqMd/EGZH5PUYocGmj6DLzRS02R+ooF+sIsr5IJvwTh3DSsy0GBq6
I1argV6u1weBBj3yOdqkQR7v9Rnj9NgWqDIZY0HIDkF3Ar8DevETtIrqrUbDwzGI9gPiiQO9yE5y
TIVP0oytOG1rXCYi3DiZS2K1adgvaJ4Rk8V9NmCUQEM/zEgLcZYxTXiJR2yAuL9nFHuBVMExlIhe
jKjnRnl9QbV/01V/npLDsTzo8vqTFDybLsOTjrKxwERgd9w7ugs6XzyVEPJlz8tOgjNTXM2FHmWY
QFoZ9GTgdnACQZcINLgDD4PTG63hQDdwZoPWQD8AZgCXgX8M9GLgPKAF6AkMgeZykvPmrLi6YXSZ
oK9CQzxaWwsO38UI+X7AUvAvg74iWhVpQ4mgjY1AH0drfaATNL8C34wn1HVAe6GXKNCJkHwGbc2k
hdDWGTKbwMHYyQUpCY4d5CdD5xW8u2uSNsuxC44SDtyO59o3oeE7tK6XsyCegxv6AT8FZ6DuE6HN
DZrbyafqOLcTtD0AtobONaBLgHbSz5B3Bycbesbh3NPSA3I20boeO7JKkM8C/wX4uzHqFOltqQet
FNgVnI6SlrOge0zoOS+i0XBCIJ9xQb+EvDNaP4B8JKwKRS+hoKWXvCETBmvvyhFhjHPA90UvDmUe
AtHaTO9R8L2heYtANkOg8bVo5bSHqA/gVJOWyJgXbyMonsDGMv5BW/CWggu0ueC9hasCaWW0eoN2
K5shfI69LQW/ALhMekYiONnAZrIV6AycDVwPyUPwQCsZt9Ie4ANgNPAyJB1k5ICTCNtOA+/KuzfQ
876MasjsAx7HuecwrjBgP+BDjPEGZDZD83TwrwAHyYwGHYM4aQLJDKkNSOH/l/DJMWkncCDOKgVt
Bp2Kvk5hZm+Ks8z+gjYhT9VIYBDmrqdoNaFGqXXwJvw9zKMrxjUSVkUgKmIhiaqlSv1G8B9Jy99k
ILME7pE2y0zH/SKKu1L50JmPLC4QccLroQfi1gPVzENUHllhgIGoReOhpxnqA2oUuQZOez37hEw5
WccE0nhZ38AvBZ4HnoDOkNJ6HAloH0hmwtpFMqfgw6e4exkIxBN2ZS7G+6scNd4t6W+8zu3JMHYV
NKJ9N/Yj/XF3ejee7nkTor8jYEMKDMsJG5A6IJq4xXycmkgiB6bGDSH9BsVFp5LBiQPSk0im0Nsz
PMSNuPIrR5n4P/5IOWJLKpJKxE584jwzEd9a00h54kAciT3/LN40FS3EShnEtzF0WiEqoUJv58hQ
N/FbLGg36m2MVCDvxcQMTSHZwDxgPnAOsAC4LDYxYSBZH5+QNIBsAe5MSEpIJ3uBPySkJSeS48BT
XHAAuQD8OTE5JpHcAj4YGhebQJ4BX6XyZgMB4l44MVqRghI3p4R16h84f6UMBPes5bsvOtq+g+Z3
0O4dNAGlHpt3UNOxIvEg9Yk/aUFCSGcSSaJILEkk6SQLvxAwmywgS4gqXksgE6XNBgd5VOX7awaz
+E1n8QvbHvpxNhHf/DTYdCX4BozNRthrsDmqHy/IYwVXeay0np/Hj1Xay6PTIKnHqZj3xfU7Hdc/
X9dHId4nwhtE+FUThVvdRbzJYGqGT//h36Nig0VEGdwVf9re2Js4k2akLQkj4aQPiSaDSSoZSXK5
5z4lc0khWUbWkk1kJ9lHjpJT5BK5Tu6RZ+R3funQTJsINa00rTJtxnG1aQuOa0zf4rjWtJUfV3Fq
G46rTNtxXG3ageMa004c15p2EYUfi/mn1Vx6N46rTHtwXG36Dsc1pr04rjV9z6VXm/bxT2u49H4c
V5kO4LjadBDHNaYfcFxrOsSl15gO809rufQRHFeZjuK42nQMxzWm4ziuNZ3g0mv/xiPil8kzSfa/
5ZEfMfKVpp90z5zUPVOie+aU7pnTvJ+VpjO6f87qfjmn++W87pcLukcu6h65pHvksu6RK7pHrsIj
P+seuaZ75LrukRu6R27qHvkFHrmle+S27pE7ukfu6h65p3vk/r/wyBxSQJaS1f/QIw90jzzUPfJI
98hj3SNPdI88hUee6R75VY+Y57pnftM980L3zEtEzCvdP691//yu++WN7pdS3SNl0iO80MAjZoP0
iFmRHjFT4RGzUXrEzKRHzKr0iNkkPWI2S4+Yy/0PPLKXHCYnyQXukTvkCXllUAw2ZhvpEbOt9IhZ
kx4x20mPmO2lR8zlhUfMFaRHzBWlR8wO0iPmStIjZkfpEfN7wiPmytIj5irSI2YnGTHmqtIz5mrS
M+bqImLMztI/ZhfdP666f2rofqktRmp20/1SU/eLu+6XWrpfPKRf/sceuWf1iKfukTq6R7x0j9TV
PVJP94g3PFJf90gD3SM+ukca6h6x6B7xhUf8dI800j3ir3ukse6RJrpHmsIjAbpHAnWPNNM90lyP
mBa6Z1oiYlrpnmmteyZI90wb6Rnx25rCblyBZvIrgUaSxMtj/GrgTDyJhfsrhHQlvbWfeKUPNvcw
ztRO6tQsrQRUOOed0qlZ2mlOtYPcGZ2apZ0FJeTO6dQs/L6KB/EhAXw+OpNepD+v6ulkNJmonbf2
dMHa00VrT5esPV229nTF2tNVa08/v+1Ju8upDuZgzrunU7O0+6Dacd4DnfpnFl2zWnTdatENq0U3
rRb9YrXoltWi21aL7lgtemi16JHVosdWi55YLeK5b/Ax+PAFTDWlGl8P1lJq4VrMV252/lgFpBPx
a1HqH2aLr35oB6Iov4EKtVIdrVSYleoEiuE38Jz4WtEDZz7BWU9xxjNI/wrJ5yJalCf8DBEts0nV
v/cVmc/XNavJFvIjz58XPHM0Q2WDm6Gewd/QyhBqEO87G233cF3zQH1npfa+pZQjnJoL6qiVOmal
jlupE6DEqlRTfhS0co3jHLT9ZJU6aaVKQFHuPXviqJzCGcKSqYqw4jPInH5HprIibJqjfE8ol5yj
nLFqOmulzlmp81bqgpW6aKUuWanLVuoKKBNfNzsRNz57PqQJaaHwtYGykPd3EL0uVPZzqYUKXyko
BfzzD+AWKAc4t0C5atX1s+4LkzJN+ZTHS6GylEsuU1YSG2W1spqUV9Yq60gFZYOykTgom5StfMVP
sTJ25FEjfsVFrPsq6L+o+AVvWKGs4Do3cnmq7FB28LUijzxlNr4pLn4vT8Qhv+qI/yOdr3x5nVXm
K/OJi7JAWUBcuY5dpAa++d0a3/wOwi/fUXWCmqeI3QKl6J7aUBtxH4pq0Mcl6G3VhYrIN6g11JrC
QkMUWUHv0BrUi3pTH+pHm9BcOo6OpxPpZDqNTqez6Wd0Hi2gRXQp/ZquoKvoGrqOfkO/pTvobvo9
/YEepSdoCT1LL9Kr9AbXdY/ep4/oE+bF6rOWrDVrw4JZCGvPOrIw1pWFs16sD+vHotlANoQlszQ2
go1io1k2y2XjWB6byCazfDaNfcpmstlsDpvL5rMFrIAVsiVsGVvJ1rKNbDPbyraxXew7tp8dYsfY
CXaSnWHn2WV2jd1i99gj9oy9YK9ZmUpVk2qrllcrqpXUKmo11ZWP202tqbqrHqqn6qXWU+urPqpF
baQ2VgPU5mprtY0arEap/dU4Nc12ve1G202aoqmajWavOWiVtWpaDa2W5ql5afW0+pqv1lgL1Fpo
QVo7raPWReuuRWq9tSitvxariV+t+IqaqVhy1KA1+DzUoXWIwr3szeehAW3A64Mv9SWMNqaNiUpz
aA4x0bF0LDFz748n5egEOoHY0El0ErGlU+lUovHZmE7s6Cw+g/Z8Vj4j5fnMzCMV6EK6kFSkX9Av
iAP9kn5JKvGZ+po48tlaQd7jM7aKVOaztoZU4TO3jjjx2fuGVOUz+C2pxmdxB6nOZ3I3ceaz+T1x
oQfpQeJKj9AjpAaf2RPEjc9uCanJZ/gsceezfJHU4jN9lVezG/QGqU1v09vEk96ld0kdPvP3iRd9
SB+SuvQxfUzq8SjwIt48EuqT+qwFa0EasFasFfFhQSyINGRtWVti4dERQnx5hLQnfiyUhZJGPFLC
iD+Plq6kMY+YcNKER00v0pRHTh8SwKOnHwnkERRNmrF4Fk+as8F8R9OCJbEk0pKlslTSimWwDNKa
jWQjSRCPrtGkDY+wbNKWR1kuCeaRNo6E8GjLI+14xE0k7XnUTSYdeOTlk1AefdNIRx6Bn5IwHoUz
SSceibNJZx6Nc0gXHpFzSVcelfNJNx6ZC0h3Hp0FpAeP0EISzqN0CYngkbqMRPJoXUl68ohdS3rx
qN1I3meb2CbSW0Qv+YDH7y7Sl8fwdySKx/F+8iGP5UOkH4/nY+QjHtMnSH/2E/uJDGCn2WkSzeP7
PInhMX6ZxPI4v0bi2C/sFxLP7rK7ZCB7yB6SQewpe0oS2G/sNzKYx/9rMoSVsTKSyPOAkqE8F0wk
ieeDLUnmOVGepPC8qEiG8dyoRFJ5flQhaWpVtSpJV11UFzKc54o7yeCZ4kFG8mzxJKN4xniRLJ41
9cgnqvhG22iePT5kDM8gC8lW/VQ/kqP6q/4kl2dTABmrNlObkXFqK7UVGa8GqUEkT22rtiUTeIZF
kYk8y/qTSWqsGksmq6lqKpliu852Hcm33WC7gUy1/cb2GzKNZ59CpvMMVMmnPAttyAyeifZkJs9G
BzKLZ2RlMptnZTXymeaquZI5mrvmTj7nGepJ5vIs9SLzeKbWI/N5ttYnf9EsmoUs0Pw1f7JQC9AC
SAHP3hZkEc/gIFKohWgh5AstVAslRVpnrTNZzDO6O1nCszqSfMkzuzdZyrM7inzFM7w/WcazPJZ8
rSXyXF/Os/0eSaM1aV1qof70KZ1CZ9DP6V/oIrqYfkU30M10G92FinmYHqcn6Rl6nl6h1+gvvF7e
Y3XpU1aXedMprDPrziJZbxbF+rNYNoglshSWzjJZFitiS9lytpqt57H0LfNmO9keto/9wI7Sk/x4
ip1jF9lVdoPdYQ/YE/acvWKlqqKqqo1qR39hndX3qLtaXU1Um7BITvVTo9WB7KrtFs2omTVNq6A5
ak6as+ameWg+WiOtqdZca60Fax20Tlo3LVzrpfXR+mnRWryWxMeaippGUNMMqGYKqhlFNTOiajHU
KxWVyoRKZUalKodKZYNKZYuKpKEi2aEi2aMilUdFqoCKVBEVyQEVqRIqkiMq0nuoSJVRkaqgIjmh
IlVFRaqGilQdtcgZtcgFtcgVtagG6owb6kxN1Bl31JlaqDMeqDO1UWc8UWfqoM54oc7URZ2phzrj
jTpTH3WmASqADypAQ1QACyqALyqAHypAI1QAf1SAxqgATVEBAlABAlEBmqECNEcFaIEK0BIVoBUq
QGtUgCBUgDaoAG1RAYJRAUJQAdqhArRHBeiAChCKCtARFSAMFaATKkBnVIAuqABdUQG6oQJ057lf
g/RALocjiyOQxZHI3J7I3F7I3PeRub2RrR8gW/sgW/siW6OQrR8iW/shWz9CtvZHtg5AtkYjN2OQ
m7HIzTjkZjxycyBycxByMwG5ORi5OQS5mYjcHIrcTEJuJiM3U5Cbw5Cbqe/kZkPa6J/m5iF6jP5E
T/PcvIzc5DGk52a9fzs3t7B6bAfbzb5nB9kR+hM/lrCzem7eZvfZY/Yre8neqAaVqeWsuVmT5+YQ
5GZN5GY8z83Nf5qbfloTrZnWSmurtdfCtK7/l5v/l5v/i3PTYBD/I7Uz6UcK+VV0I9lJDmB3e5M8
wn0S7JtJPb6P4vs3+iuP5Vz6G8dx9CXHifQ1x2nqRKKwlmomx9bqSI5t1CyOwX+i4Tk0vICGV9Dw
OzRMgoaPoWEUNHwCDXz/p44WEqDGWKlsK5VjpXKt1FgrNc5KjQeFHbX2VNDas7ccXm2uEMLesFKi
8LrA94m8NqhE5fXBhph5Xsfje69huIPkSfyhpYLtYZ7N/Ex65y3F40Ls9o/wT0/57u0i5OzpGJ77
vE0e6R3sEMWOgmBvYOBnXhZ7QjyjMGPH+wvfja4U90CUQrlzJCW25W3t/+7JhbBJPJtyJ/W5d4P0
+wWHsJc9bN33Xxe/fgjqhpW6+ZZSRwjpf7o3xhMbPJHT8KSJu0p5RKsbBxoHGRP0J3cGKUVIFfE9
C0dwSZV+ltwqfdRy9fJC836zM5iUwtwqnTirg2Iw+NpayqnM254q1RixDFBtvFWD0ZDbVDEYCyMs
PSz13+E4F7lmO5MW+NuNRJM0kkwSSRxJ5/9aib+Wmu8oMzpO/0tkbFz1YUavFTM8xh1LTpjq6ONQ
mOvga8k19rfk0s6FVDEoio3PiooXupdFLTxU/PZsF25Kiq+3pa5KexptK7kHJ6d8nJowcFC6m1dM
XTffwMCmbl0SYlKT05Lj092Ck1NTfHxdLc5S+L0/tiSnDkhPSE7yrWmpIdppJae/tocnJ6e7tRme
Pig5NSH9Y4trFTtLU0uAH//TyNfi16eKna8f/9iYM/mfPpaP4SuuRK2k9IzwrWSpKD6YK9m8PyBt
UELSwHTeTQWLvWCaKpnC42KHJifFvjXM5h8ZVstSUxpW7d322Di3iISBSVyrW/fgNpZcg7vFzjqB
BgMjNNdQnnC+jZJrMJDNH39y6sMN7QKX+a/0PfeyduOOI4pf1yjY327YwxPtb53M/25I5/DoZ/OU
77qc6ZjY0KNV3K6jtTbbhm4eM/xiux3Lp9t3/76295PCX+xq1TjRxuNV9LxjVdt9OSusxrwjGxq6
fxfWICv57HuuzfMDKwRe3FH3WXzzBga/stI6oUu/STRMWPB66/qYMbkvowpzxo2ftvbJltmLjwUs
7T6+Sp0JXS9anpOWz/a9bJmzM+9+YuBXPv7PN/qssfkkekZm/IK5aXZ5a57sfer2bTeHqTGH6p/1
a1f1wbawOc27Rzgdje/x8fJVEw70arUot/vEJLau8e5RHjvC41vO63rYe3SjpHEd1BMFx8PylKQ8
sqR4wuUIRfwq8OKcV5ac3yyVuDtdahs1i41q5qHLmIlSS06R4BqMOfMtOZ9nV+h7POVhQmpBrR6j
Hdd3mVZ26IvU/3y85ZYnu8mUFi0mVjzR6nnMvctBlvLCxkoGQ5mRWSg/WFwEw95Y2eh42OVoBknp
u+bxub1d5/cI8VkcEvPIYiuayxuNPI3y3kkdKiJi1IrVo8M8nxzd3jW9qHed9HrDN+S9WdF5dibp
cvuHu04XEr63L8p6qgTv+2HC4RcRh/cs2tEr+VFMyNch5MGcA/NLnLfYLqpqN/v0OddVdT95eH9p
2srplwKntZw7eHvA0B8nrqn15vLtUwnlZkzcUXqVbPN/+lvWywoOPuxu3Tmz2g7xGrY5YPoVk93B
Dwcd2ZHdZkj8sm2bt03z/+EJrZA18tcfr7S9PKr06tWVpc8vl9htSDk181q3TQFFWQ1Otjzvbxvd
VFmUM7jWpOdRMdPX9tkWeLp/fs9x1Rr92nxuYa5W9NGUDfU3f/HloRXn3DbtslQd7+ZoV297+LM2
V/pZrs30SpiwO+Xnp1+tOJrdNjXDnteYkbzGROs1ZoDhWCvUwvLv5hHjdea/mNWi4ATyGtPUz8/f
4hcoCo6vpZH1oyVn7P8X2+wQODx0jV26dQ9/K07/gfi/rD07LJNet0tdFjGkYFI3Uqt450mXlus+
CAp4mjYj1/PmHAcScdY5177FUZdtO35rO/Xzk78HVLv+7ctr934aQHcV/nRqeJeo9l/f7/fox58T
+lZLu7PBearxSN2QwtgPGrrO/TBp/wqnwNy4vV9tXzF8YtU7Ez539NwwxjNjycmAwHHXNniWOL30
vv3jwcp9Ims++XzqhLy6pc861r855YWx9SdHjsyZmWc3jP58vFRr27js9JbWF6e1s/nk+elOq/o+
ykh1GVHrk0mN9zp/uL477dRhqOmrnhPnqtlLc1ZFdj2Tc+rVrrbFvjt72s0riejoYLl748uJWf32
juzjOMG8sWlC4V0/j3zz3ZcnHbde+f3InSXv6bXnhSXn1z+vPX/N4oBMlnagut9fPpqZ13PNpK37
5q1Ln4bpcykvsp4nsikbdcOlltHJUjn7z9M+RAjUMLa0NLcEFjYtbJzXaFB6ekqzhg1jUhN9hr6d
Q5+Y5KENU4YkCG7DlNTk2OEx6WkNgyN44PlwliX0rYUGg7GFpZkl4O1ni5JXX1c4YsSIP1MYl/qO
pvS/SShUHy86dkUlu8elFZPbZpwJXrFlX9tXHnH+q4evHWaZNmfT2Fep10uPNP2lWcrcHm72W4dt
PPis5PrkW14paSX3r+4Z9eBxL/8+2bl3K5xOpXccut67aJc/KqSbNmD4m6QFpotHvfs42QWu7f/m
XJlxubL4zKtpi7ft2D04srnvR9frJx163KWe8xPXjFF5a/ZNOLWu3v2Vh+2Lry8ac+vYrXGpkblO
SfUOFHy2sZrr7uRZ56OX7u40ZNXB+y1nXlvfcMXIEYEDB5NRuQtphUsxn3X0bHvpM/fdE2yPOy7+
6EKaX2oT17IDdb/3CO8WH3rQxeXr7z0DE7p3/ereHjXRJ7X645rnhnqEZue8F5S16HB6QFg3Xn0W
8uozXlafCoNt53UrJrVXVDzfrkbvkQOL/rYG/XfWOk148Wli8bX4+zcVpSeQf/wvrHUiE4bGpaUP
GJry7651LjRNer3mQNuwYU4Hjoa2iih+tcJxa32/bQ7dwg+Mvd+q0dmOvjO9Ns2IvVKj+7itezqd
GMNePBy+c8r+ZSWrE1LiM+vE39q0+eH4b488WP7GYYntB+51Gx4LOtvLWD3jm6GxQ8Miz198fGnX
orH7sy+P6aw0nf1rcYG5l+ugDkfOFmdENfxkU23jxl59BzvHlGVntXhQYqzdJXBEuunDPVFn8prW
H37Q/o5rYLmsjNKFiUkjr9xrNf3zgmH2H9Xr5hTd36/gx7Fdvd2jBrWbcqnhuArd17/8ptrUxAe1
/1LpxaEKp8fbP8vNSGuy77ORRYf7q/fY2rxGm1/M7juuzbje42cnra1RP/Rw8oLgK4NvjfGcNkTW
m1yDF/eIx59VHPP/jtVOBbWcvrN4zyCWMOSdQpl8q2vrz7/1X9Epb/r2BXdWNm8TvO+4par1BEfF
qLnakAgynO9CgkmbP66E/m4Z9ScFanaXir57srpvqzjtiwEmg31+SrupD9Mid7QuxxqUbekRMd75
fuCMzYt72V7K39S8+onXK786uHldj5rVk80Jo4fQIvf29xM3Ds1y39L+p3FPp5bfaZrcZPfd0bdT
Pmy3aOaPh49enFZ8dVe9I1n3Dq72K5nw7aGYvU1OONXclXGp+fwN1dMKak48s3GjQ2T+swV74sLm
e3ku6D+5fPP9leIyQ7cdWzW2Wbe10b0vWW7fDnS5NunJucCcl5Vq5sdmx6jGOU/mK8ENR7WfuLVM
ORv3MuzSOZo+awNL0g4vvOA1ICv0cZUFFWsGKM4TVqrfz/HbciNoX0TLHV9PunQrvunUZ+5zFhxe
OyKyR7NTqSHraz3nBWo5L1Az3y6PWJEFyyPzf2959HeFQNSoAL4aasxLk69vY1GjGsmPvuKjJWfD
f2J5VMdSW350TQpOSBkUl+oWEtHOrV1E12YBjUMaNWhkaRzcoHHb4Pa+tS215Jic/zimBhFiUG4R
cakZCTFx/7K8PTI2WD+nuFrOwNrrPKM3VOp01LK12CHg95w4f9PeJus9Bj03GYv/39inf9n+sVou
ScftpveSQJPtl3PeRllvaV7obivIoWea7frskE0PUxrTSonM115v1XXe2ZRHL7lSMNM7vEXgwnrd
H52yz15pbnl+fh5b0vKikEPWx87b73i4IUIg5+nS64cPlZrv/dL6sPGFxg3pj5/WfWxafO0686L5
oi2/bX+tfrjN6MQCppTPz/5LqRVyBHeJMn1qVi/zbCpc/n6tUcWx6zli/kqp05N83fT/K69vfbOs
YC/z6Vs3jFiPak9w2Dbvqk5bzvbTwka1vcfq1onrG/1J2y27wTX0x9pfuunN6ZqTWy5FLVRGbk4h
CoQX0799f9/z8Vnm48gMv+8zuqruztZDaSlhLTEoaSmVFBckJ1KlpQQzqQR7YY3S/mM7gK204rUv
j59os2+p6ZLbrKwt8mGf3s9cdpyjV3/zWfvCq2015fJ3X4tv2lvz+OfMT1yuHmtFdmfqfLJLTwr5
9K5eXXCS5ZtzN9v9Or4nuCtXq4s6cMzfz2vI0nTDdBvPHIbL3asqEo9u7XCca2d2J2KJ+myrW3vZ
YkWWbeL3Odhn0/0paeaPtLdXP8tobDC6fcqQc89vpQw3n1+Xi5Wea/YpMfwO28+2rnGB6C6Tnxp9
8l5JrAs7vza6v+SdyHE9wrpfLpszc+UBj5rQJvt4BgvnOWxn7G/o7/cv5rT9uyvuy/E35odSEhf4
XrEtOBO9Qbjx4JXFhlJ7U65Nu1RlrxXtFsxpc5b5p30kw5nO4ETDJpbZwBJrOhMjo0Fj+wB22VA6
koihrgWNx0C1EzTaOJkNeZDH0YD2InjchnwGyLKiwFIDrpHFEJjUb3yTZ5gz68Kp7akXbiUca2Wb
b3B2sUEakhYewwiDsAU6DVoMvgyZDMkMRQz54KG4NIYSBgVgdZgPFCkAk4lAkUwgK2+hWoMKzpRa
UlmQn16UWJBRqYBWMrE0MTKwTltw9ucMXz1h7V18kVvfHIpW/LDOPP+v4+ZdDuUZLx6sEZlnWn6j
w/9PxKZ9p46Y62x8NmlP/fWq9i0cb6qW+fdN4lLyC/lz8yFX3v+Nrz+X3mT6fERAoCemLSb6WESY
25Utl/uyvDIs7CweskV/uyFydDmj+AqVjwF6bm6uTLyy6xKyX2z9+Gv3wsi+q5tmL1O1uK1fru7+
Z+G8P5++3fjYt+Rz3Km8dMXfx2Nu7WJs+58fv+/AxJ6PJa3TVib3LjrU8G7vGYkeg4LIMCvTpR8P
h6wy8PkWt/xPezXL6fxK4QO3uWw5Zz3Xvpp95cbPqiCvnq6dpyR9Zs77kZVr1HRTp+zMF++lPJH+
+04fX9jEJG/QxCSNiCU2wyYmHqAQB92TI3oViVJxs0OT44JYAwnktMiNGPhlBNoJl2E15AfWqAYG
FqDq1cjY1CQKIykyPlWLf94j+SNcZ8VTuVKZvWfdl3mglU+gJOL0zXFeW/bKSQ8a+C7oTPhiwMEW
c0x/fsDzrZ4eC6a5Lfqe++tb0iV1O9X/stoJdq9Zjit9r9u3TG//Jk+OrKKXNiozlE/z1QnzPPM0
F5XoVz4Tf0iE89sBa3uGoFWbbu/4zd7zN+CAc7aOc5MiV8iTmmo5lubqHaoLJ126e0ZEglmg2+VW
4E77uqbHa4/mRa9lfXX/jaTT+ZC9i4/3nauL67gV2JZgvbZys86KNxNn/Jmdc1D87xQe4cKSqGdr
AjrZlBwuLIloS1LI/ybwbHXvj5OzJnmtm51iPbm2JHreF80pz9w/nH0bzBX5pe2IwmsDhlXcauUr
rhXcvH/si1VpftLym1qc31etO3HgiioDAwB8OA0tDQplbmRzdHJlYW0NCmVuZG9iag0KMTUxIDAg
b2JqDQpbIDBbIDc1MF0gIDEzNVsgMzUwXSBdIA0KZW5kb2JqDQoxNTIgMCBvYmoNCjw8L1R5cGUv
WFJlZi9TaXplIDE1Mi9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5mbyAyNCAwIFIvSURbPEQ2QURB
NjNDQjUwODE2NDNCQTk2NEJDQzZBNzY2QkM2PjxENkFEQTYzQ0I1MDgxNjQzQkE5NjRCQ0M2QTc2
NkJDNj5dIC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMzNj4+DQpzdHJlYW0NCnicNdO3UoJR
EIDRCyZMJHMCs6gg5ogZBTMqQTBhzgHTjDgWVja+jL2Fj+EYn8DGyk5/7qdb7Jnd2Z3ZZoVQ4udH
pWSDEDGu4UGi+pRodeAEmro3iT4M7BlMsC0xBiWWQ4mVyqWRuG0S76PE54AQfEn8NAN2SeRdCLVy
mVmcwCmcQRf8jZwrCyff/5UaVKCFOIiHBEiEJNBAMqRAKqRBOujAAHowQhZkQCZkQx7kQC7kQxEU
QCGYoBjMUALlUAplUAEWqIQqqIYaqAUr2KAO6sEODdAEjdAMrdACbdAB7dAJEXDABfRAN4zAIPRB
LwxAPzhhCIbBBW4YhXEYgwnwwCRMwTT4YQZmwQs+CEAQ5iAEizAPC7AEYViGFViDVViHLdiATdiG
HdiDXdiHAziCQzhWviPqkV91dRtD9XQjeb6UvNxLXj9iqKN3QvwCkZhFlw0KZW5kc3RyZWFtDQpl
bmRvYmoNCnhyZWYNCjAgMTUzDQowMDAwMDAwMDI1IDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAg
bg0KMDAwMDAwMDEyNSAwMDAwMCBuDQowMDAwMDAwMTg4IDAwMDAwIG4NCjAwMDAwMDA0OTMgMDAw
MDAgbg0KMDAwMDAwMzU5OSAwMDAwMCBuDQowMDAwMDAzNjUyIDAwMDAwIG4NCjAwMDAwMDM4MjEg
MDAwMDAgbg0KMDAwMDAwNDA2MSAwMDAwMCBuDQowMDAwMDA0MTkyIDAwMDAwIG4NCjAwMDAwMDQy
MjEgMDAwMDAgbg0KMDAwMDAwNDM4MiAwMDAwMCBuDQowMDAwMDA0NDU2IDAwMDAwIG4NCjAwMDAw
MDQ2OTcgMDAwMDAgbg0KMDAwMDAxMDM1MCAwMDAwMCBuDQowMDAwMDExMzUzIDAwMDAwIG4NCjAw
MDAwMTgxODQgMDAwMDAgbg0KMDAwMDAxODQ3NyAwMDAwMCBuDQowMDAwMDIxNjk2IDAwMDAwIG4N
CjAwMDAwMjE4MjAgMDAwMDAgbg0KMDAwMDAyMTg1MCAwMDAwMCBuDQowMDAwMDIyMDAyIDAwMDAw
IG4NCjAwMDAwMjIwNzYgMDAwMDAgbg0KMDAwMDAyMjMxOSAwMDAwMCBuDQowMDAwMDI5MTUwIDAw
MDAwIG4NCjAwMDAwMDAwMjYgNjU1MzUgZg0KMDAwMDAwMDAyNyA2NTUzNSBmDQowMDAwMDAwMDI4
IDY1NTM1IGYNCjAwMDAwMDAwMjkgNjU1MzUgZg0KMDAwMDAwMDAzMCA2NTUzNSBmDQowMDAwMDAw
MDMxIDY1NTM1IGYNCjAwMDAwMDAwMzIgNjU1MzUgZg0KMDAwMDAwMDAzMyA2NTUzNSBmDQowMDAw
MDAwMDM0IDY1NTM1IGYNCjAwMDAwMDAwMzUgNjU1MzUgZg0KMDAwMDAwMDAzNiA2NTUzNSBmDQow
MDAwMDAwMDM3IDY1NTM1IGYNCjAwMDAwMDAwMzggNjU1MzUgZg0KMDAwMDAwMDAzOSA2NTUzNSBm
DQowMDAwMDAwMDQwIDY1NTM1IGYNCjAwMDAwMDAwNDEgNjU1MzUgZg0KMDAwMDAwMDA0MiA2NTUz
NSBmDQowMDAwMDAwMDQzIDY1NTM1IGYNCjAwMDAwMDAwNDQgNjU1MzUgZg0KMDAwMDAwMDA0NSA2
NTUzNSBmDQowMDAwMDAwMDQ2IDY1NTM1IGYNCjAwMDAwMDAwNDcgNjU1MzUgZg0KMDAwMDAwMDA0
OCA2NTUzNSBmDQowMDAwMDAwMDQ5IDY1NTM1IGYNCjAwMDAwMDAwNTAgNjU1MzUgZg0KMDAwMDAw
MDA1MSA2NTUzNSBmDQowMDAwMDAwMDUyIDY1NTM1IGYNCjAwMDAwMDAwNTMgNjU1MzUgZg0KMDAw
MDAwMDA1NCA2NTUzNSBmDQowMDAwMDAwMDU1IDY1NTM1IGYNCjAwMDAwMDAwNTYgNjU1MzUgZg0K
MDAwMDAwMDA1NyA2NTUzNSBmDQowMDAwMDAwMDU4IDY1NTM1IGYNCjAwMDAwMDAwNTkgNjU1MzUg
Zg0KMDAwMDAwMDA2MCA2NTUzNSBmDQowMDAwMDAwMDYxIDY1NTM1IGYNCjAwMDAwMDAwNjIgNjU1
MzUgZg0KMDAwMDAwMDA2MyA2NTUzNSBmDQowMDAwMDAwMDY0IDY1NTM1IGYNCjAwMDAwMDAwNjUg
NjU1MzUgZg0KMDAwMDAwMDA2NiA2NTUzNSBmDQowMDAwMDAwMDY3IDY1NTM1IGYNCjAwMDAwMDAw
NjggNjU1MzUgZg0KMDAwMDAwMDA2OSA2NTUzNSBmDQowMDAwMDAwMDcwIDY1NTM1IGYNCjAwMDAw
MDAwNzEgNjU1MzUgZg0KMDAwMDAwMDA3MiA2NTUzNSBmDQowMDAwMDAwMDczIDY1NTM1IGYNCjAw
MDAwMDAwNzQgNjU1MzUgZg0KMDAwMDAwMDA3NSA2NTUzNSBmDQowMDAwMDAwMDc2IDY1NTM1IGYN
CjAwMDAwMDAwNzcgNjU1MzUgZg0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDc5IDY1NTM1
IGYNCjAwMDAwMDAwODAgNjU1MzUgZg0KMDAwMDAwMDA4MSA2NTUzNSBmDQowMDAwMDAwMDgyIDY1
NTM1IGYNCjAwMDAwMDAwODMgNjU1MzUgZg0KMDAwMDAwMDA4NCA2NTUzNSBmDQowMDAwMDAwMDg1
IDY1NTM1IGYNCjAwMDAwMDAwODYgNjU1MzUgZg0KMDAwMDAwMDA4NyA2NTUzNSBmDQowMDAwMDAw
MDg4IDY1NTM1IGYNCjAwMDAwMDAwODkgNjU1MzUgZg0KMDAwMDAwMDA5MCA2NTUzNSBmDQowMDAw
MDAwMDkxIDY1NTM1IGYNCjAwMDAwMDAwOTIgNjU1MzUgZg0KMDAwMDAwMDA5MyA2NTUzNSBmDQow
MDAwMDAwMDk0IDY1NTM1IGYNCjAwMDAwMDAwOTUgNjU1MzUgZg0KMDAwMDAwMDA5NiA2NTUzNSBm
DQowMDAwMDAwMDk3IDY1NTM1IGYNCjAwMDAwMDAwOTggNjU1MzUgZg0KMDAwMDAwMDA5OSA2NTUz
NSBmDQowMDAwMDAwMTAwIDY1NTM1IGYNCjAwMDAwMDAxMDEgNjU1MzUgZg0KMDAwMDAwMDEwMiA2
NTUzNSBmDQowMDAwMDAwMTAzIDY1NTM1IGYNCjAwMDAwMDAxMDQgNjU1MzUgZg0KMDAwMDAwMDEw
NSA2NTUzNSBmDQowMDAwMDAwMTA2IDY1NTM1IGYNCjAwMDAwMDAxMDcgNjU1MzUgZg0KMDAwMDAw
MDEwOCA2NTUzNSBmDQowMDAwMDAwMTA5IDY1NTM1IGYNCjAwMDAwMDAxMTAgNjU1MzUgZg0KMDAw
MDAwMDExMSA2NTUzNSBmDQowMDAwMDAwMTEyIDY1NTM1IGYNCjAwMDAwMDAxMTMgNjU1MzUgZg0K
MDAwMDAwMDExNCA2NTUzNSBmDQowMDAwMDAwMTE1IDY1NTM1IGYNCjAwMDAwMDAxMTYgNjU1MzUg
Zg0KMDAwMDAwMDExNyA2NTUzNSBmDQowMDAwMDAwMTE4IDY1NTM1IGYNCjAwMDAwMDAxMTkgNjU1
MzUgZg0KMDAwMDAwMDEyMCA2NTUzNSBmDQowMDAwMDAwMTIxIDY1NTM1IGYNCjAwMDAwMDAxMjIg
NjU1MzUgZg0KMDAwMDAwMDEyMyA2NTUzNSBmDQowMDAwMDAwMTI0IDY1NTM1IGYNCjAwMDAwMDAx
MjUgNjU1MzUgZg0KMDAwMDAwMDEyNiA2NTUzNSBmDQowMDAwMDAwMTI3IDY1NTM1IGYNCjAwMDAw
MDAxMjggNjU1MzUgZg0KMDAwMDAwMDEyOSA2NTUzNSBmDQowMDAwMDAwMTMwIDY1NTM1IGYNCjAw
MDAwMDAxMzEgNjU1MzUgZg0KMDAwMDAwMDEzMiA2NTUzNSBmDQowMDAwMDAwMTMzIDY1NTM1IGYN
CjAwMDAwMDAxMzQgNjU1MzUgZg0KMDAwMDAwMDEzNSA2NTUzNSBmDQowMDAwMDAwMTM2IDY1NTM1
IGYNCjAwMDAwMDAxMzcgNjU1MzUgZg0KMDAwMDAwMDEzOCA2NTUzNSBmDQowMDAwMDAwMTM5IDY1
NTM1IGYNCjAwMDAwMDAxNDAgNjU1MzUgZg0KMDAwMDAwMDE0MSA2NTUzNSBmDQowMDAwMDAwMTQy
IDY1NTM1IGYNCjAwMDAwMDAxNDMgNjU1MzUgZg0KMDAwMDAwMDE0NCA2NTUzNSBmDQowMDAwMDAw
MDAwIDY1NTM1IGYNCjAwMDAwMzEzMTIgMDAwMDAgbg0KMDAwMDAzMTYyMyAwMDAwMCBuDQowMDAw
MTIwOTYxIDAwMDAwIG4NCjAwMDAxMjE0NjUgMDAwMDAgbg0KMDAwMDEyMTc3NyAwMDAwMCBuDQow
MDAwMTIyMDc5IDAwMDAwIG4NCjAwMDAxNjI0NDQgMDAwMDAgbg0KMDAwMDE2MjQ4OCAwMDAwMCBu
DQp0cmFpbGVyDQo8PC9TaXplIDE1My9Sb290IDEgMCBSL0luZm8gMjQgMCBSL0lEWzxENkFEQTYz
Q0I1MDgxNjQzQkE5NjRCQ0M2QTc2NkJDNj48RDZBREE2M0NCNTA4MTY0M0JBOTY0QkNDNkE3NjZC
QzY+XSA+Pg0Kc3RhcnR4cmVmDQoxNjMwMjcNCiUlRU9GDQp4cmVmDQowIDANCnRyYWlsZXINCjw8
L1NpemUgMTUzL1Jvb3QgMSAwIFIvSW5mbyAyNCAwIFIvSURbPEQ2QURBNjNDQjUwODE2NDNCQTk2
NEJDQzZBNzY2QkM2PjxENkFEQTYzQ0I1MDgxNjQzQkE5NjRCQ0M2QTc2NkJDNj5dIC9QcmV2IDE2
MzAyNy9YUmVmU3RtIDE2MjQ4OD4+DQpzdGFydHhyZWYNCjE2NjI0Nw0KJSVFT0Y=

--_002_945CA011AD5F084CBEA3E851C0AB28890E820119SHSMSX101ccrcor_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_945CA011AD5F084CBEA3E851C0AB28890E820119SHSMSX101ccrcor_--


From xen-devel-bounces@lists.xen.org Wed Nov 05 13:22:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 13:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm0Wo-0001go-8D; Wed, 05 Nov 2014 13:21:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xm0Wm-0001gi-Es
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 13:21:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	76/6F-24532-F542A545; Wed, 05 Nov 2014 13:21:35 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415193672!12937056!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12352 invoked from network); 5 Nov 2014 13:21:13 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-21.messagelabs.com with SMTP;
	5 Nov 2014 13:21:13 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 05 Nov 2014 05:19:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,319,1413270000"; 
	d="pdf'?scan'208";a="631898662"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga002.jf.intel.com with ESMTP; 05 Nov 2014 05:21:02 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 5 Nov 2014 21:21:00 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id
	14.03.0195.001; Wed, 5 Nov 2014 21:20:59 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
	machine
Thread-Index: AQHP91mlLJNh4IXOT0KpYuzQIm5vr5xRwUyw//+ZoYCAAKU94A==
Date: Wed, 5 Nov 2014 13:20:58 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820119@SHSMSX101.ccr.corp.intel.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031126170.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81FD36@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411051056500.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411051056500.22875@kaball.uk.xensource.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_945CA011AD5F084CBEA3E851C0AB28890E820119SHSMSX101ccrcor_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>, Daniel De
	Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual
 machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_945CA011AD5F084CBEA3E851C0AB28890E820119SHSMSX101ccrcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Stefano Stabellini
> Sent: Wednesday, November 05, 2014 7:02 PM
> To: Xu, Quan
> Cc: keir@xen.org; ian.campbell@citrix.com; Stefano Stabellini; tim@xen.or=
g;
> ian.jackson@eu.citrix.com; xen-devel@lists.xen.org; jbeulich@suse.com;
> wei.liu2@citrix.com; Daniel De Graaf
> Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> virtual machine
>=20
> On Wed, 5 Nov 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Monday, November 03, 2014 7:30 PM
> > > To: Xu, Quan
> > > Cc: xen-devel@lists.xen.org; keir@xen.org; ian.campbell@citrix.com;
> > > tim@xen.org; ian.jackson@eu.citrix.com; jbeulich@suse.com
> > > Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> > > virtual machine
> > >
> > > On Thu, 30 Oct 2014, Quan Xu wrote:
> > > >
> > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > >
> > > > This patch series are only the Xen part to enable stubdom vTPM for
> > > > HVM
> > > virtual machine.
> > > > it will work w/ Qemu patch series and seaBios patch series. Change
> > > > QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the
> > > Qemu/SeaBios patch series are merged.
> > >
> > > Please, could you add more detailed commit messages in your patches?
> > > Also spending a few more words here to explain why are you doing
> > > this and how would help.
> > >
> > The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM
> > functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows
> > .etc). This allows programs to interact with a TPM in a virtual
> > machine the same way they interact with a TPM on the physical system.
> Each virtual machine gets its own unique, emulated, software TPM.
> > Each major component of vTPM is implemented as a stubdom, providing
> > secure separation guaranteed by the hypervisor.
> > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the
> > virtual machine to use. It is a small wrapper around the Berlios TPM
> > emulator. TPM commands are passed from mini-os TPM backend driver.
> >
> > This patch series are to enable Xen stubdom vTPM for HVM virtual
> > machine. his allows programs to interact with a TPM in a HVM virtual
> > machine(Fedora, Ubuntu, Redhat, Windows .etc) the same way they
> interact with a TPM on the physical system.
> >
> >
> > > It looks like you are trying to introduce vTPM stubdomains. The QEMU
> > > changes have been posted against upstream QEMU, that is good,
> > > however as far as I know upstream QEMU doesn't build or work as a
> stubdomain yet.
> > > Where are the changes to make upstream QEMU based stubdoms work?
> > > I don't see them neither here nor in the QEMU series.
> > >
> > It's Xen stubdom, not QEMU stubdom. Sorry for this confusion.
>=20
> What does "Xen stubdom" mean?
> I am still a bit confused, I replied to the other email.

It is StubDom, it is xen wiki about StubDom (http://wiki.xen.org/wiki/StubD=
om ).=20
Stubdoms (or stub domains) are lightweight 'service' or 'driver' domain to =
run device models and one technique to=20
implement Dom0 Disaggregation. The initial purpose of stub domains were to =
offload qemu workloads from dom0=20
into a seperate domain.

The following link is the wiki of vTPM.=20
http://wiki.xenproject.org/wiki/Virtual_Trusted_Platform_Module_%28vTPM%29=
=20
in 'vTPM Extensions in Xen 4.3 ' section,=20
[...]
Each major component of vTPM is implemented as a separate domain, providing=
 secure separation guaranteed by the=20
hypervisor. The vTPM domains are implemented in mini-os to reduce memory an=
d processor overhead.


-->=20
So 'Xen stubdom' is a separate domain, and implemented in mini-os.
My mistake, maybe 'Xen stubdom' is not a common Noun in community.=20

>=20
>=20
> > > How are you testing this work?
> >
> >
> > The following steps are how to build and test it:
> >
> > 1. SeaBios with my patch against upstream seabios is not submitted. I
> > will submit seabios patch when I finish these questions from review.
> > Now I archive my seabios patch against upstream seabios in
> > Github: https://github.com/virt2x/seabios2 , try to build it for test.
> >
> > Configure it with Xen,
> > --- <Xen> Config.mk
> > -SEABIOS_UPSTREAM_URL ?=3D git://xenbits.xen.org/seabios.git
> > +SEABIOS_UPSTREAM_URL ?=3D https://github.com/virt2x/seabios2
> > [...]
> > -SEABIOS_UPSTREAM_REVISION ?=3D rel-1.7.5
> > +SEABIOS_UPSTREAM_REVISION ?=3D
> ea94c083cc15875f46f0bf288b6531154b866f5a
> >
> > 2. qemu with my patch against upstream QEMU is not merged. now I
> > archive my qemu patch series again Upstream QEMU in github:
> > https://github.com/virt2x/qemu-xen-unstable2
> >
> > Configure it with Xen,
> > --- <Xen> Config.mk
> >
> > -QEMU_UPSTREAM_URL ?=3D
> git://xenbits.xen.org/qemu-upstream-unstable.git
> > +QEMU_UPSTREAM_URL ?=3D
> https://github.com/virt2x/qemu-xen-unstable2
> > -QEMU_UPSTREAM_REVISION ?=3D qemu-xen-4.5.0-rc1
> > +QEMU_UPSTREAM_REVISION ?=3D
> e867e6cf86c8412ca516cf2d0ccad57130e3388c
> >
> > 3. build/install Xen
> > Change QEMU_STUBDOM_VTPM option from 'n' to 'y'
> >    QEMU_STUBDOM_VTPM ?=3D y
> > ./configure --prefix=3D/usr
> > make dist
> > make install
>=20
> From the previous email, it looks like you are running QEMU in a Linux ba=
sed
> stubdom. If so, I don't see where are you creating it.

Not so,
The attach file is the picture of vTPM architecture.=20

>=20
>=20
> > 4. try to launch vtpmmgr / vtpm domain via
> <Xen>/docs/misc/vtpm-platforms.txt.
> > The reader is assumed to have familiarity with building and installing
> > Xen, Linux, and a basic understanding of the TPM and vTPM concepts.
> >
> > The Linux / Windows HVM guest configuration file needs to be modified t=
o
> include the following line:
> > [..]
> > vtpm=3D["backend=3Ddomu-vtpm"]
> > device_model_version =3D 'qemu-xen'
> > acpi =3D 1
> > [..]
> >
> > ## domu-vtpm is the name vtpm domain, A mini-os stub domain that
> implements a vTPM.
> >
> > 5. enable native TPM 1.2 drvier in HVM virtual machine. for example
> > enable tpm_tis.ko in Linux HVM virtual machine.
> > If you have trousers and tpm_tools installed on the guest, the
> > tpm_version command should return the following:
> >
> > The version command should return the following:
> >   TPM 1.2 Version Info:
> >   Chip Version:        1.2.0.7
> >   Spec Level:          2
> >   Errata Revision:     1
> >   TPM Vendor ID:       ETHZ
> >   TPM Version:         01010000
> >   Manufacturer Info:   4554485a
> >
> > Or check it with sysfs, /sys/class/misc/tpm0
> >
> >
> > BTW, Some local ISV are trying to integrate this feature into their
> > cloud service for trusted services, Such as trusted virtual desktop
> infrastructure(HVM fedora/ubuntu/redhat/windows virtual machine).
> >
> >
> > >
> > >
> > > >  Config.mk                             |  4 ++++
> > > >  extras/mini-os/include/tpmback.h      |  3 +++
> > > >  extras/mini-os/tpmback.c              | 20
> +++++++++++++++++---
> > > >  tools/Makefile                        |  7 +++++++
> > > >  tools/firmware/hvmloader/acpi/build.c |  5 +++--
> > > >  tools/libxl/libxl.c                   | 62
> > >
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > +++
> > > >  tools/libxl/libxl_create.c            | 16 +++++++++++++---
> > > >  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
> > > >  tools/libxl/libxl_dom.c               |  2 ++
> > > >  tools/libxl/libxl_internal.h          |  3 +++
> > > >  tools/libxl/libxl_types.idl           |  1 +
> > > >  tools/libxl/xl_cmdimpl.c              |  2 ++
> > > >  xen/arch/x86/hvm/hvm.c                |  3 +++
> > > >  xen/include/public/hvm/params.h       |  1 +
> > > >
> > > > I've tried to break it down to smaller patches:
> > > >
> > > >  *(Patch 1/6)*  event channel bind interdomain with para/hvm
> > > > virtual machine
> > > >
> > > >  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for
> HVM
> > > virtual
> > > > machine
> > > >
> > > >  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual
> > > > machine
> > > >
> > > >  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine
> when
> > > > vTPM is added
> > > >
> > > >  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> > > >
> > > >  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> > > >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org
> > > > http://lists.xen.org/xen-devel
> > > >
> >
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--_002_945CA011AD5F084CBEA3E851C0AB28890E820119SHSMSX101ccrcor_
Content-Type: application/pdf; name="vtpm.pdf"
Content-Description: vtpm.pdf
Content-Disposition: attachment; filename="vtpm.pdf"; size=166430;
	creation-date="Wed, 05 Nov 2014 13:15:53 GMT";
	modification-date="Wed, 05 Nov 2014 13:15:53 GMT"
Content-Transfer-Encoding: base64

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu
Zyh6aC1DTikgL1N0cnVjdFRyZWVSb290IDI1IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+
Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDIvS2lkc1sgMyAwIFIgMTYg
MCBSXSA+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291
cmNlczw8L0V4dEdTdGF0ZTw8L0dTNSA1IDAgUj4+L0ZvbnQ8PC9GMSA2IDAgUi9GMiA4IDAgUj4+
L1hPYmplY3Q8PC9JbWFnZTEzIDEzIDAgUi9JbWFnZTE1IDE1IDAgUj4+L1Byb2NTZXRbL1BERi9U
ZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250
ZW50cyA0IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdC
Pj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMD4+DQplbmRvYmoNCjQgMCBvYmoNCjw8L0ZpbHRlci9G
bGF0ZURlY29kZS9MZW5ndGggMzAzMT4+DQpzdHJlYW0NCnic5Vtbbx23EX4XoP/Axz0BRPN+CQwD
jZ2mKSrUjdW0gNMHQZVlp+fYrmwn8L/vN0Pu7ZzdPStfCiQ2YIukOMPh8JsbuRb3Hov79++dP/z+
kVAPHohvHj0U/z09UUJJpZQ2RkURjRLeKXF7fXryj6/Ey9OTe9898eLmzemJFjfdZKWCVm40+9lX
pyd/Oz0R354/FGKwkr73l8uXN6K5fnn29yebuuw3F2D8Ry2ckyo4cfGM2IO30EJnK50Rzifps7jY
0Zq88HenJ0+bXy4en4s/bGxzu9GuuXr+4u1Gm+b66u07HrgWm3+Jiz+fnnx7MSGKGazeLudtkCEM
l3vaLDKxS/sx0M54O17L5ITNtNHK/sfzzZnBIq75hRpvX+92N7eDJYfiaZ9lMGN6MTc38KTBXDos
k624uHrafD1LFq3MYyomWNSCW9KCTlMqCJEU3YqlDS9ydjYjVTAypTHRgVSj+UHmMJz/tHlyfVVR
sX0/u3lrZHRjujcbrZu3m9S8AnUApq43Z655eXVLp/X+9cY3b1/gn1cvxeYM3P+zsb65xsD7TWje
0LE+22giFteXV88xJzSvns2tb6OXMY/Xf/scMD5LhI5I6NgjncaZc0YGO2YkZxZ1DpPieO7iafu5
0947YqelseW0zviMjx0yMJdGZEcOOckwWuZp8wMf0c07OpvtJZ128Qji8uqKju36zRscjWBV0i9e
0QGRhp/Tby8ZH//+lX5zeehBRicFR+HtePGLx2B2PqdmGxOf7ZBiUc1hpZq1k2kVw7iOoUlJOjvr
nb5esB34phH1ojhppTiwfXV3GA3J1sBoMP9pc73Dht8RgEwLoLldOyV1GlNfCgpLMPtIZg83wCZs
G4KlBQQ3Gj5jFljKSRvHDP/6hNApl7Bo8phkUfP5WNAKU1HLWC+DXsNfqw+JikZlaab4jzCBraa9
qfgDJa/8QVC+G8WBwzUTW7AaESqPBLuvrM/IjeyDcJ9+DP9+riGs+MBxt/74LIvSKmuikEdkifun
tQicxfQQDmYSODpi5dx7CKeLvS8kBzaMqFakONocE23SaLSJMpkBUod/2LUe/pn1DLC/vMdxUeTF
5HROm8lLjx97Eo9E3Ze760+YyuEydR/DdTpTWfv3wZk9QOlxGjNNM1h7AtYTekKm5MKeohYPwlXd
Kxk8F04oaZDLi11pgR+cmkN+oAmXTvjIP65OT0JtbtEMnqZRL8SOiptgRXPRzJmnUksxu0oFQYlV
YqalgXl1SXRcR+CYCWY9L1WcEb+i3pKIugpm4/Gvh4H9gPoLqvhZ/Fa28mTqXGYz2VK3oFzag66z
0niYoJHFc/Bh6lKM/nNjFDjN5/ZOovjqaY+BJnSgQXDHPxGcpMYJ3GLNoISBMIjHu9KB8VpHrs0E
eFwf6VdQb21BBxqKrL0t9bKMth3QKbQcuFk4ExF6OnVE1ANhSqLSU7VI9HRysSWKru3wUbNEdQCS
VgbUSq1sFWqTKPv9bXUSirPJ+UQJrbWigGoQca3bwyFX04njGXL3uVQdZWYc0q+KgEcT9pSlJbPO
iarogvGubEXqu7uhPPZ2cZE8wVcj6wMmRnyXr3ZUZzvkouENFAEroTAh43EOaHFeqshui3reUNXi
XKZ7A+OTtFk4IMaatkfOBnqHf6oDWxqIMvt2wBsrs255tb2yDlGXAYICuG77gciLVl7sM8s61W9W
MarrrCJSjwSvxNwsjI+Z0xew+SkDM4up5YSvd1FLXYwkm30j40IUSy+amcuBHU/PYY2ZmcVEc88T
OBSvKDt0JsurlvFT83ijbfPjT5tZuTKkHxMti2QXzcl7OEjNrhQBbtcPwM1GZEuBVgNMkAtYrgfQ
pBhP9STjh52n44te6gU3IG87hTmRlQH2qJWyDBAYqPpnPq0TLmv0DruK0DvtKl4dqJJXXm2vLHXM
sL4oNUya2Ow1cJc5Z80uxpDaPiBwBbgJb4b0qyzq+IVl0pTkU4DJrjOjP208RJk1o2CS9GFMtCxH
n9EVA8KxUDu1GR3U7WuSA4Fy8nTvrbTnlNdJX3NejV/6mvbqBEBk6lDGUqmoybxqWhNofk1qfGaO
lY5ScubmYwFVaRKcysroQJpKhBazWpGx/ba2MonmIxnZQcDQKtDNHRa2BwGDL4d9cz5/jWhl0kPa
Y1hK/ZPdWX2EU1nn5de7bKU2vCRsGS2jEaHISyBo4zyw7L3vd5c319qKR6/E1PudWbw73ItOxisq
lMlc4+AGVx2JmybCF5kR2Qort7OXjh1f5wiuFPe03U9PlzjrKWbJSJvGzJblM/uXANaGQWXDvVKY
WGdQ7rUVi/VqUNs4PaxtnB7WNs50LLjZ1TbU62sb7pXSpNJXt0+8+xhB6/YBospUB6ztWHBzXSX3
O93wlPews3dv3X0AUjdjZ4q4NWZiYc3J3LWKs0eDtIVjzHmmilvi7CeYOcXvI+tLN9sHyeQ1Z5yJ
/+UgqRXFghxLcNFwX6Z2t1231gra4KT3e91Uer7reziHEoOW4Iv9/CySOP9/CDEJqdinDyxYsuTu
gyqqcakUTVTUZQp+dFVE4M+qa8bISZ5D4hKFs4oefLWNbIL0PAkim+gRiU0I45oHkPVxoYFfI8kM
KBWTZp40LYZ+rU59QQcSLZKYLrN8dP9leAE2fm35Et7S2xkivnccj6hZCj/DVsr64GaZYI1pyWyy
Lb/e75QryfFedh+2l1af22V9ogYiRhpQt5aS00PZBjvffvqdT0IlLUIlaN9CJZD3CO2G8AuZ+p7C
kr7ABfmVL9GT4ILcC3ZthnDxiPUpFhUj14LGkIywiukqLLRsryrbsAYyLvt6jnyItkRc1oDu9ELN
ojhLJ1MUx80ywTndknnlWn49ZE7GW9l9+FZatW6PqzXGFjUekUxNiTfY/PbTb34SNXnJ9RqEha5A
3FE/0fsZfWYUOWCaYOkhfTDgAy/uWLHGKnY+cHoUtZSmHI90zGHUGGSi6GaOiaAoZpUp1DsKHZUt
TfV8I96v00Mokdd2BUIhloiRAzm7iiENGR13ivPV3lLxVjtdJqCdl8Ob3dqvk5Et22K/CsNpH0+j
re0+bmsjpW/XKj1mVjqCuAFsCpT3hB2oZft51TKFNKeWkEbuO/kB1GxCTKVNGionCOGphK5+IJQb
YgebQAB22Bmqc+XhV7kEocir2GTpoZ4uFDGQI3IW/oyHyi+4bhsQ2HXLliaHsrVunUWo0XFS0DD8
GqYTZQnUqWqkE4kTOo2Dq5ltP1CmG1V2yt93BL6kMHmEttEGdx+7wbHut+t0H+miFLpHsEGcUoz+
A4EH2tl+du1Mgk4vPwr4AFxqUseu7TnSFn0MCptz8PwYC7xi6XDKkIH60uWkQZO91bl0MeE7Nm2P
lyDSMkAWrGrGUQcUmU9l1V7H8zr9bXyVo7+Nr1J2t/eh48NNW+HfwuaL2e0kEmav2LurFAUsncFS
xGjEFXOxcHVZH1zxXL5+Ta9c241tXuDv1Uar5pI+/yrfhy5+QGvvLITJZuXNg+s/P0C2wcCnVCvV
JCslcg1OWSoDdoMBT5tEusuVMnIUR9dHiZv8HqQpkFOPH4McnwR6nhxwaum7HrNnOh7ogdAN8AFW
Ru2rUllkgIQiwwAJRb4WCUX2DlS1t4f+mYexL0sRk4Yxe1N+DJNIJxANLPw0gvinNIxwZyHIMNIq
u4jLz1qoBiM5P0PX/LvBgCfD8yVSOhUJTfSCQP9PofS4NKDvKNuBmvZTuVkGguKErfLqerwUU/MA
fdJpyh12HaCnGFFZ1UuwulJ/Y1Zl6S/Nqqh1oG6jsGo7ZaGjT1xfqkomjWX2e4gjOAXYSHCKIvHw
M6KPMZZ8ZyHIWNZ9NOyXv6kImvO+HhrdQDlOZKV0R1KPGr6NLmJ6aFhLSesAGtZTgGrn2yhz6ni1
vQ4aZWAAjTpQoFFYtdAoK/XQqLL00KiitvPLNiqr2llnLV+sSqasxc9+f3EEqPTmC8E/vbV4c2ch
7mAt9vB9zumg6/tcslDnxPuc4mtzFPnYLs5F8Vco8GuDpzk/fJr7H1UxznUNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQo1IDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwvY2EgMT4+DQplbmRv
YmoNCjYgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjEvQmFzZUZv
bnQvQUJDREVFK0NhbGlicmkvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9y
IDcgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjYvV2lkdGhzIDE0OCAwIFI+Pg0KZW5kb2Jq
DQo3IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDYWxpYnJp
L0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAvQ2FwSGVpZ2h0
IDc1MC9BdmdXaWR0aCA1MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1
MC9TdGVtViA1Mi9Gb250QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZpbGUyIDE0NiAw
IFI+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9u
dC9BQkNERUUrQ2FsaWJyaS9FbmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyA5IDAg
Ui9Ub1VuaWNvZGUgMTQ1IDAgUj4+DQplbmRvYmoNCjkgMCBvYmoNClsgMTAgMCBSXSANCmVuZG9i
ag0KMTAgMCBvYmoNCjw8L0Jhc2VGb250L0FCQ0RFRStDYWxpYnJpL1N1YnR5cGUvQ0lERm9udFR5
cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8g
MTEgMCBSL0ZvbnREZXNjcmlwdG9yIDEyIDAgUi9XIDE0NyAwIFI+Pg0KZW5kb2JqDQoxMSAwIG9i
ag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+
DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RF
RStDYWxpYnJpL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAv
Q2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9Y
SGVpZ2h0IDI1MC9TdGVtViA1Mi9Gb250QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZp
bGUyIDE0NiAwIFI+Pg0KZW5kb2JqDQoxMyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv
SW1hZ2UvV2lkdGggMjU5L0hlaWdodCAyNDIvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNv
bXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDE0IDAgUi9GaWx0ZXIvRmxhdGVEZWNv
ZGUvTGVuZ3RoIDU0NTg+Pg0Kc3RyZWFtDQp4nO3d6VuS6d/H8Tnu30xNu5rmvuYCsm+yKyAgoKio
iIiCoAju+5JabplppmlqtthUNmWW1vUf3ieXM1PTLDUzGqWf13E+6GieXHCcb87ry9J89x0AAMCX
dupCDMvQJK4YJEtoGxSQVY6F9cvilw3wS3v51m5+SSe/uJ2pcZ+LSQn3nj0w8TlySdUVcdWoyH5N
XD0hqZn6YE1j/WFNHdtFtgfZJKKqMWHFiMA2zC8f5Fl7OZZOVlEL29AUlcgI917+N+IZcol9jN75
03m1M1LXrKxuTua+JffcVjQsYmH9ccndC7L6eWndzbzaG3nO6yQN0oWgYoScFNySHra5nWkIMHS+
iITMcO/uzyKuGBbbx8n+D21+90LoMXrvKH0rqqZVtX9d3Xzvd4v8zde+1o77avpCi+wQVeNdpW+Z
bJhQF57bsvo58ioqdkwKq66SM4Jn7WObO5iG5myNh5HvDPdO/3PnY1LIbZ7EMUmuXFY3L/cskkek
8q/lBzbyA/fzgw8KgvfpP2/kN9/Lb14PLfJfsbB+v9TkBbPprqpxReVbVvru0DnMkxdViXOavMAK
bFe41l62qY2hb8rKr78ss0fEXQ733n+PZ+0mCZCrJacbyZl0TV7tyf4vaHlYQCdQENgoaL5XGFy3
9T609T5ovLZJVs/s0765p1eXtmZWX2Ad83Vt+TnZDGRL7O+Nit775d0bhuCqOlQEOSBuy0N3TbP7
90v88iFOSXeusYWh9WWqa1PFpeEu4DuWwSe2X8tzzpBsQwn4Q0dAQcuD9/s/cM/Ueq/x6uPx5ef3
ftp59PwNWVsvd8nafr2382Zvd+8tBcfe3t5bshlevd7b3xv7+2Tjp9czd1/4rz0u6Vinc1iQ198k
44O4elJYOcovHWCbOxl6f5a6Ll1WGZctCUsCZ6ISxVVjEseU1HWTnF/Kxrv5zRsFwf0jILT/izvv
d848XX28E+7nGI6CJy92B+efWttXFO55mevGL6O0bZhT3E2GaHKblCGvShUVf3/i1JesgGsK/noQ
3FJ4l8lQmR94fwSQBBYfbIf7mYOj6dGz1/bedYVnQU7ulKon96cGcptEJugMeXWq2BqbKfoyFXD2
K6i9QSZiVeMqfRA82E9AF1wfmHu29/ZduJ8tOOLmN16aWu+SOyVJzaSwYoRr7WORCVrrzVQ4UkQl
KRztYVcgtg2Jq8d/qYBMBL8mUNC83jC2Sc6vcD9DcFy83n03cPNpvu82mRqEVWO80n62uZ20kCG3
JwssieyCw6tAZBsOVeCalTcs/TIX0wmUdt1ffvQq3E8MHEfktbf+ygN5/Rw5GgTlQyxTa7amIV1W
lcw3xTPVh1GBMFTBBKlA4aUroD8OKGheq7uySdoM9/MBx1rv7DNVAzkapvnlQ7nGYHaBO11akcwz
xjOUB1xB+UBoLvi1AjX9cViBf6116idMBPA1mF75We1dIrdJ/LLB/feR0vLKkzj62CzpgVVQ2ieq
GpM4r+/PBWr6E0ByFgwvbIX70QO8R+7PNU3L0lrSwgBT35ypriWDc3xu/qUM4X+vgFsUFFVcETum
ZPW3lL4VtX+VVKALrs2uvQz34wb42ObWG3PrmtR5nczODJ0vNDjzjHHZ8pg09n+pIENcLLQNiezj
0rqbv3x3oumuLrCG0Ri+Wlvbu+a2tbyaKW5Jd7bGnSYpS2BpYy6Lz0cn/rsK/vfDSUFZv6hybP/N
0tBx0LhSGFxd2MCHZfBV23jyWh9YllSPs81t5AYpWWiJYyijU7lkS/+LEPglXaF3imqmZO4FZeg4
WDa0rJGRJNyPEuDTlh6+MrXcEVWOMg3NGbJKMjXHZEoiE3P+aQVZykpBaZ+w6qrUdTP0TpFvucB/
l0zHb/EeEXwjyBirbVzglw/maL2pYms8Ux2VwjkTEfNPjwNB+dCvM/IdddPKwPwWvikK3xDyoj27
+lLhmuEUd15WOpK4hugM4YW4f/ADN3ZRM9/aK/xlOritalxxjzx8vYsK4Buzt/d2YO4nUdUos7Ap
VVIax1BFJjHPRsV/TgXnY9L4xZ3kQBE7JqV1c0rvUr7/7ubWm3A/JoB/Y+/tO33TLV5pb6bKmcQz
Xkzjn4tJ+7//ff/JELhFAZ61R1g5mueckbtvkemg8epmuB8NwL83vrQlcYznGpvTJGVxOYqIhOzT
EbGfDIFnbuWV9oU+O3DNKhpu4ziAbx05FIyBJX5Zf1a+K4lniEphn436xGcKbL2Xa2nfvy+S1c+r
vEtN1x6H+3EA/FcTd57nOSfJoZAqtsZkSs7FpJ4+F/k3IXCMfm5xp8B2RVIzpfAsaPx3t7bxEwP4
5oUOheZFrrU7Q2GPz1VfiM/+8dzFv6oghavlFAW4JfSAUDuj9C52XH8S7kcAcDDIpCCqHMnReMjI
HJXKOR0Z98PJP/+BM7uwgWNq4ZX2i6quyupm1Y3L+Ok9HBmvd9/JXDPsomCapPRSVt7ZmNQTp879
xYDg45jbQgNC9YTcPa8NrOK3BnCUVPfdE5T1ZyodCbkFFxKyT56N+mMF5y8mcQxNHDOZlIckjkml
ZwFjMhwxwwtbeY5xZqEvmV8UlcI5HRF74uTHX8NjF7rJpMyxdIRCqJlSNizOrr0I94UDHKSNJ68V
7ptsU0uKqDg6XXg2KunkqTMfv19U2MA2+LmWTr5tOM85rWteebGzF+4LBzhgxW3L3JKu9LzyGDIm
RKecOH3+4xD0Xpa+iWMJvXcqc91oGMWnyXAEDc4/E5QPXFZUxzGU5y6lffQm6vlLqWwSApkRiruE
FSPy+rnxpefhvmSAg7f+ZEdsH8vKdyWwNOfjs06dj/n+hx9+CyFHUcku9LAMfhKC2H5N2XAbP8aE
I+n5q11Z7XUyLydx9ZFJuacuXDpzLuL9pKxzs/UN+yeCuHpc5V3Cv1kHR5XCPccqCiTz9t84iv/w
uxacwvchSEgIvjv4N7vgqDK3LLFNLcl8U1Qq70zk70Lg6j3kUAgNy8XdkuoJdeNyuC8W4LDYe1bZ
5rYUgTk6jX8mKuH0+ejfQuAZPGxtXW5hYygEx0RJx71wXyzAYfGOPuBYOlKElug0QSiED37FzDd6
WdpaMkFwi3vyaqYcA/fDfbEAh6V9+jG3pCtFVBKdLjwTlXjmgx/p8A0NuZpaps7LLemROqfxkzQ4
wobmn/JLe1MlpTEZorMkhMi4j0Jg/BLC9ZZJfMsIjqzhUAh9aQgBjjeEAEAhBAAaQgCgEAIADSEA
UAgBgIYQACiEAEBDCAAUQgCgIQQACiEA0BACAPVhCOkIAY4vhABAIQQAGkIAoBACAA0hAFAIAYCG
EAAohABAQwgAFEIAoCEEAAohANAQAgCFEABoCAGAQggANIQAQCEEABpCAKAQAgANIQBQCAGAhhAA
qN+FIEQIcGwhBAAKIQDQEAIAhRAAaAgBgEIIADSEAEAhBAAaQgCgEAIADSEAUAgBgIYQACiEAEBD
CAAUQgCgIQQACiEA0BACAPVZITQgBDjyEAIAhRAAaJ8OQYsQ4OhDCAAUQgCgIQQACiEA0BACAIUQ
AGgIAYBCCAA0hABAIQQAGkIAoBACAA0hAFAIAYCGEAAohABAQwgAFEIAoCEEAAohANAQAgCFEABo
CAGAQggANIQAQCEEABpCAKAQAgANIQBQCAGAhhAAKIQAQEMIABRCAKAhBAAKIQDQEAIAhRAAaAgB
gEIIADSEAEAhBAAaQgCgEAIADSEAUAgBgIYQACiEAEBDCAAUQgCgIQQACiEA0BACAIUQAGgIAYBC
CAA0hABAfRBCNEKAYwwhAFAIAYCGEAAohABAQwgAFEIAoCEEAAohANAQAgCFEABoCAGAQggANIQA
QCEEABpCAKAQAgANIQBQCAGAhhAAKIQAQEMIABRCAKAhBAAKIQDQEAIAhRAAaAgBgEIIADSEAEB9
OgQnQoDjACEAUAgBgIYQACiEAED77BCmm8cRAhxZQ6EQelNDIQg+CkFg9LK1tQyth1PclVcz5Rp+
FO6LBTgs3TM/cUu6UkSWqFTemaiks1Hx708EYwNH52Jo6tnmdoljsqzrXrgvFuCwNF19yLF0JPON
UcnssxeTz15M/OBEaODq6xmaOpapVVJ9zRBYCffFAhyWmv51tqklkVMYmcg8G518PjrpgxnBIzC4
mdq6XGNQZB9T++7svX0X7usFOBSm4FKuwZ/A0kQkMM7FpFy4lPJbCDx9PQmBpa1n6puFlVdU3sWt
7d1wXy/AodB45xiF3niGOiKRce5SWmRc2m8hsDVOgdHN1tUzCxsF5YMKz/zdzZ1wXy/Awdvdeyd1
TmUX1MVlKyISmedjMyIupf4Wwunz0WKTNzQmaD08a4/MdePG2stwXzLAwXv0/I2o8kqGvDImQxSR
kH0h7vIPJ0999wGJpVFk8pJ5mW1uz6uZ7Lz+JNyXDHDwJpaf86xdKULTxTTuhfisiPjM735PYvZJ
S/y5ZF42NIvtY0Wtq+8wLsORY+++yzI2J7AKIpNZF+KzIxOyPgpBaPTISwNcvZuh8wlsg6qGhRWM
CXC0/LyzJ6+7nl3gupQli0hiRiTkXEzK+SiE+CyhzBoQm5sYGjevpFvmmumceRruCwc4SLNrL0WV
wxkyW0y6MDKJGZnI+PFsxHd/ILM2K8taWNo6ljEosV8t6VgP94UDHCTv6AOOuS2ZZ4xK5UYm50Yl
M/9YAZFnaVRXtAuLfAytR1A2oHDPP3mBTxPgiNh7+05dN5Wd74rLUUSlcMiMEJ3C+tMQYtM46oo2
RVkLU+Nim9qkNZOji8/DffkAB+P2/Zd8a3eqyBKTISQhXExlR8Zl/GkIhLIsqHV08w0NTJ1XaBsu
Ci7juxZwNFhbFxjahniGKjqNfzGVG5PG/asKCFFRg87RLSeHgraeW9wpc12fuINDAb55iw+2hbah
9LzyS1l50emC6DRebAb/b0Ig8ivbC519XIMnt9AnqhgqCuALePDNK2tfYhlCHx/EZIhJCJcyBN9/
f+LvQ1CUBg21/UpbG0vn5phbpTUTOBTgm7Z4f1tQ1k8fB9KYyyIyI8Rliv6+AuJ0RKy2utvkHs4r
bmZo3YLSXkPTwutdHArwrbL4b+Ro3PEM5aVMyaXL4thM8cnT5z4ZwnehDxSCxrrBwtp+vsHLNvgl
VaOtE5u4P4Jv0dTSE465PYVvupQli83Ki82SJORIP6eCfTpHr7XxqrqiI1dXzy/uVNZdv31/O9yP
CeCf2dx6k187lqmwx2bLY7OksdnShBzZ51dAcLS1JveVEu8ouUHK1XmE5X0639ytDbQA34z7T3dM
/hu5hY0JuQUkhLgceQJDHpvB+0chhA4FZ3+5f8LoGhSafGy9T1wxaA4urWy+CvfjA/i0Zy/3KjoW
2MYguSmKzdmvQJGcq/qnFRBnImPNnlF764zBNSAo8nKMTZKqK6aW5UfP8b0L+Kptv3lb3rHMNben
ia1xOYo4hiKBqUxiqb4/cerT+/7PMFQVJU0T1e039M4+nt7DNQWk1WPWjnW8iQRfM+fAPX5Jd4a0
Ip6himMoE3JVyez8FLb631WwT+0YKg/O1HTM6hzdLG0t39IqdVyr6l3Hr/vhK7T39p139IGwfCBL
6UjIzY9nqhNZ+Smcgsti83+pYJ/efc3eMedony2o6swtqOGZg3n20eLWFTKSh/txA7xHblQqu1cE
ZX3ZamciWxOfm5/ELkjlajPziv97Bfss/pnantvkHqmwppetdXGL/JLKocLGheVHmJ3hq0BuUSyB
W7zizkyFPZGtTcgtSOJo0/j6LKn1oCrYV9Y65+q7U9e3aKof4hvcHINXbOtXum/O4t+7gHAjNye6
hhmOqfWy1EbOggSWJpmryxCZcuRlB1vBPmvLvKt/xTeyZvVdlZi9bF29qKxHXjvZd2Mz3M8EHF+3
1p+rnONsY3O6xErOgkRyEAiMWdISpqrqxKkzhxECYQnMuwbWAuOPbIEpudVPjwwBcptUHJzHbRJ8
YU9e7FZ13hJYe5ia+jShOYmjS+bpL0ssDEUFuYE/pAR+U+Sfcw1ttE0/dXbdMjh7ebpacjQIrR1S
x1XXwCp+3QlfAJmLW6+ui2xDLH1TptSWzDUkcQvTRaZsWRmLvDgbvIddwT6VY9g1/CA49ax5/KEt
MKkuD5JjiGv0ict7ZTXX2q7hgwY4RCM372vqJrjmtmx1TZqgKJlnSBOasmRluepqrt6dytV+mQr2
/Xg2qqr3nm/8adfcdsPwqsU9LC7y5KrtXIOXnA6qmpGGgcWFez+H+zmDo2Pj8cu2sTs61wjX3MLU
1GVIrCl8Y6rQlKOwcbQuvtErsgROfN73qw+cyjHiGnncMrPdNfeqtmfBVDcgNTcwFDa2tpZvbiYH
hKr2qqPr1sCNR/d+2nny85ut7b0XO3s7b96SFe7nFb5Gr3dDe+PlzluyVZ6+3N14sjO5+KS+706B
a0Jg7WbrG7OV9nSRhRwB6WILQ23nGzwis19ibeMZv9Dt0N8o61rzTTzvmN/tnn/dMLxW1jSutrWw
1JVMVSVbV8crahSWtEkr+q1Nk87uBe/wSufERs/0w+nlZzdWf17YeEmmbKxjvm5vvCSbYWZlq//G
o67J+80jq87uW7bAtNI+JChp5xibyBGQKS3b3/9MdTVP7xZb/HnWFll5l6KyL9wFvJfK09kHHjWM
/9wy+7p38V3z+GN7+5ze2ScvaeIU2LNlVobSxtI4yY0T3+QXWIKC4jahtVNU1i2rHCQTB9YxX7LK
AVFZD9kSZNvzLS08U4Bj8DE1tdmKioy8knSROUNsyVbYyOu/rKxVWdGlqOhRVvWrHEMnz1wI997/
c9aujfqrz5tndroW3nbO7fjGHjm6F62N4zpHj7S4kaupZirLs2WlmXklWVIr+QO5wWNgHftFtkG2
vDSL3hiZeVaysui9wdbUCIs8edaAoqJD4xzU1l7ROK8U1I7l1147eSYi3Jv907h6j3PkWcPktn/m
ddvcbufC29bZV97Rh47u2xWts9amCZNnVF87UGDvUpa3YGGRpbK15le2F1R1aqq7NY5enXPA5L1W
7L9u8V83+aaM3imDd6rQe/0Lvyl0UEjg5b2Paka2PBMvG6e3m2dekRW4vt08/cI/9bxx/KlnbNMz
Go418iWW+7PWo699XTm89fC3VT/8oG7ovnNg3d57t6p7xdZ5p7Rt0RJcMAcWDP5bZC4O914+MJfz
SnTeG6XdD8p7Nyv6f6oafOIYflIz/LhmCOurWI5DX5t/taoHN6v6H1T03i/t2rB0rJtaVw3B5cg/
/F88AOBQ/T8KMcmTDQplbmRzdHJlYW0NCmVuZG9iag0KMTQgMCBvYmoNCjw8L1R5cGUvWE9iamVj
dC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDI1OS9IZWlnaHQgMjQyL0NvbG9yU3BhY2UvRGV2aWNlR3Jh
eS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmls
dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4MDY+Pg0Kc3RyZWFtDQp4nO3ZX1LTYBRA8W8ndCd0JYIs
hOJCRF1JWIGvPtY3ZpxhYKw6itRjQ/lToKVpaXOH3HNWcL8fN0kTSrEm7bx5X/Hqqga7mzn+IZz/
iT7N2n2DwcvOP+RL9CFe3insrP3378D5p52utQvwetd/fisCDLmInnjTXZ6tgnBYXz/da9T8cuB7
9LDb6lezRTgeRw+61arlAsPoGbfe0osgQQo8bxA9W1spsNggeq42U2C+wfA8eqp2myPwOXqmdhsd
PyHo7I/iRf3OfSOY9lBg9yx6nvYbD9IvwcM1GHbtC1GjxrNvjZ37RNSsq5kliJ4lrOR3grpbgSp6
kLgG6Zfgbg1G0XME5hLcGEQPEds1QcLfxvdd1gL70VPENkh/HVxfCdEjRDch+BE9Q3BuAb3Sjx4h
ur1yFD1CdIPM70jTqvS3gsn9MHqA+CSQQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIk
QAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIk
QAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIk
QAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIk
QAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQIJJpYqeILqqHEWPEN2g7EePEF2/9MbRMwTX
K+Vv9AzBlZL+kSBBTZD8kbA3ISgX0VOEVgskvxIkmBKkNuhJMBXI/Ez4cEOQeA2KBHcEJeur0r1A
4V/0MDGVWYOUzQqUtxlfmfsPCFKuQXnUz+iBWu+xQPl4GT1Sy508IUh3KTwVyGYwTyCXwXyBTAaL
BPIY9BYTJDF4BiCJwfMCGQyWCZSu/7f93XKBehGuoufcXo0ASv0xsaMI/aYC9SJ08q1pBYC6r9Hz
brwVAeo69W292V1wTtGDb6p1z9+RXTh42flv6x+dRJ9k9U4+HfSaHO4/bBiqbQ0KZW5kc3RyZWFt
DQplbmRvYmoNCjE1IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAy
NTgvSGVpZ2h0IDE5Ni9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvRmls
dGVyL0RDVERlY29kZS9JbnRlcnBvbGF0ZSB0cnVlL0xlbmd0aCA2NjUyPj4NCnN0cmVhbQ0K/9j/
4AAQSkZJRgABAQEAAAAAAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwg
JC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCADEAQIDASIAAhEB
AxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9
AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6
Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEB
AQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJB
UQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RV
VldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6
wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoqpeX1pp9ubi8uYreJf45n
Cj8zXF6t8WdBsdyWKT6jLj/lmuxPxZufyBrSnSqVH7iuZ1K0Kfxux39FeG6h8WvEF4/l2ENtZhvu
7V82T824P/fNZ5svH3iL76avOjf89GMUf4Biq/lXWsvmlepJROV4+Ddqacj3K61jTLAf6ZqNpB/1
1mVf5mse4+IPhW1+/rMD/wDXJWk/9BBry+2+Eviab/WLY2//AF0myf8Ax1TWrD8Gb1v9frNtF/1z
gL/zIqvq+Fj8VS/p/TJ+sYqXw07ep1snxT8Kr927nf8A3bd/6gVF/wALa8M+t5/34/8Ar1hR/BZB
/rNedv8AdtQP5sakPwXtu2uT/wDgOP8AGnyYFfaf9fIXPjf5V/XzNyP4q+Fn63Nyn+9bv/QGtC2+
IPhS6+5rMCf9dlaP/wBCAri3+C0gH7vX1b/es8fqHrLufhBr0X/Hvc2M4/3mQ/kVx+tHscFLabX9
egvbYyO8F/XzPZLXUrK/j32d3BcL6wyBv5GrlfNl/wCDvEmjyebNpNyu3/lpD+8A99yE4/HFS6V4
98SaSf3OqSzxf887r96PplvmH4EU3l3Mr0ppgsw5XarBo+jqK8y0L4u2F0yw6zbtZv8A8948vF+I
6r+v1r0W1ube8t1uLWaOeGQZWSNgQfoRXDVo1KTtNWO2nWhVV4O5YooorI1CiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAoorB8Uvra6M66AitfSSKis2MIp6tzxx75+lOK5mkKT5Vcsa14i0rw/B
52pXaQBvuL1Z/oo5Nebal8T9Z1q4+xeF9OlXd/y18vzZfrtGVX8c1q6X8LEkn+3eJtQl1G6blo1c
hfoWPzN+ld7YadZ6Zb+RY2kNtF/dijCj6nHU+9dalh6Wy53+ByONeru+VfieRW3w18UeILj7Xr19
9n3f89pPOl/BQdoHtn8K67S/hT4csdr3ST30v/TaTC/gq449jmu8oqZ4ytLS9l5aFQwdKOtrvz1K
NjpVhpseyxsba2X0hjCfyFXqKK5m29WdKSSsgooopDCiiigAooooAKwNa8I6Jr6t9vsY2l/57R/J
IP8AgQ5P0ORW/RVRlKLvF2JlFSVpK54V4o+GOoaMjXemO1/Zryy7f3qD1IH3h7j8q53w74p1Pwzd
+bYTfumbMlu3KSfUdj7jn+VfS9eT/EjwJGYJde0qLa65e7hVeGXu6jsR1I79euc+phsYqn7qvrc8
vEYN0/3lHSx3XhrxNY+KNOF3ZuVdflmhb70Teh9R6Hv+YG9XzJ4d1+68OaxFqFr/AA/LNH2lTup/
oexAr6PsL6DUrGC9tn3wTxh429iM1y4zC+wldbM6sJifbR13RcooorjOwKKKKACiiigAooooAKKK
KACiiigAorgPHnjr+xMaTpP73V58L8q7/J3dOO7HsPfJ7A9R4dtrq18Oafb32TdpCvnbm3HfjJye
5z3rWVGUaam+u3+ZlGtGU3BdDyZ/i94hWR0FtpvysR/qX/8Ai69W8ManPrPhux1G5WNZp497LGpC
9SOAST29a4B/gsXd3/4SAfM27/jy/wDtleieH9J/sLQrPTDN5/2aPZ5m3bu5JzjJx19a6sXLDOCV
Hc5cLHEKb9rsatFFFcB3hRRRQAhIHWsf/hK/D3/Qd03/AMCk/wAa1Ln/AI9Jf9w/yr5RX/VpXbg8
LGvzXdrHFi8VKhy2V7n1ZDPFcwJNA6yRSKGWRGyGB6EEdRU9Yfg//kTdE/68Yf8A0AVuVySXLJrs
dcHeKYUUUVJQUUUUAeHeL/GniPT/ABbqNna6pJFBFLtjjVV4G0HuM967j4Y6zqGt+H7q51K7a5mW
6KKzKBhdinHAHcmvKfHv/I9av/12/wDZRXpPwc/5Fe8/6/m/9ASvYxNOCwqaWuh5GHqTeKcW9NTR
1XVNTXXUiguGjt/N8uTaq4gGUG5mJ6kOWGQR90YHLV1FjOb3TbaaZV3zQq7L25AJ4Pai406zun82
e0hlfbt3MgPA5APqM9qu15cpRcUktj04xabbZ82eMtEGgeKryyjTbb7vNh/3G5A/A5X8K9I+D+rN
c6NeaZI2fskgeP8A3Hycf99Kx/Gsb4z26rqul3A+/LbyI30RgR/6GaqfB+Zk8VXUP8EtmT+KuuP5
n869eq/bYLmlv/keRTXssZyrY9vooorxD2wooooAKKKKACiiigAooooAK5jxr4oi8L6G1wu1rybK
WsZ7v/eI/ur1P4DvXT18++L9Tn8YeOfs1q26FJhZ2vp97Bb8Wyc+gHpXVhKCq1Pe2WrOXF1nSh7u
70R03ww8OvqF1L4p1PdK5kb7O0nO9/4pD9DkD3z6CvXDVLTbCDS9OtrG3XbFBGEX8B1PuetXTWde
s6s3Lp09DShSVKCj/Vz5pk8W+I1dsa5qH3j/AMvDev1r3TwVczXng3TLm5meWaSLc0jtktyepNfO
cv8Ar5f94/zr6I8Af8iJpP8A1x/9mNelmUIxpxsup5uXTlKpK76fqeY+PvEWt6f431G2tNWu4LdP
L2xxzEBcxoTgA+pJ/Gub/wCEv8R/9B3UP/Ahv8a0viX/AMlA1T/tj/6KSuu+EumWN/pOoveWNtO6
XACtNCrFfkHAyK35qdHDRqON9F+RjapVxEqalbV9zgB4w8R9tc1D/wACD/jXXeD/AIm6jDqUNjrc
32m1mYIJmUB4ieASQPmXPXPPOc8YrvvEvhfQ5vDmoEaXaRPHbu8ckcKqyFVJBBAz1FfO55jpUnRx
cGuWw6qrYWa9659XXP8Ax6S/7h/lXyin+rWvqGykabQbeV/vvaqzfUoDXy8n+rWsMrVuf5fqbZm7
8nz/AENeLxRrttapDBrN7FFGuyONZmAAAwABnpX0Tcahb6Zo3269l8uCKIPJI30H5knjHcmsXwto
Wkz+EtHmm0uylleziZma3QlmKDJJI5Ncj8YdWZP7O0aJ9qFTcSKvfBIQfThvyFZVHHFVlTirWbua
01LDUnUk73tYwfEXxP1rVZmTTpm06z/hWPHmsPVn7H2XH1Ncr/bmreZv/ta+3/3vtT5/nXTfDfwx
beItbme+TfaWah2j7O7EhQfbhj+Ar2t9E0uS0+yPp1obfbjy/JXb+AxxXRVxFHDS9nGJz0qFbEr2
kpWPHfDHxP1PTLpYdXma+sG4Z25li9wf4h7Hn0Ne2wTw3NvFNC6yRSKHjZejAjII/CvnPxloaeHf
E91Yw7vI4kh3ddjDIGfY5H4V6j8JdUe98MS2Mj7nsZiin/Yb5gPz3D6AVljaEHTVensbYKvNVHRq
O9jzLx7/AMj1q/8A12/9lFek/Bz/AJFe8/6/m/8AQErzbx7/AMj1q/8A12/9lFek/Bz/AJFe8/6/
m/8AQErbFf7ovkYYX/e38z0aiioLieG1t5biZ1jiiUvIzdFAGST+FeIe2ePfGS7WTXNOtB/ywgLt
/wADbGP/ABz9ah+Dtuz+J7y4/gjsyv4s64/RTXIeI9YbX9fvNTbcqTyfu1bsg+VR+QH45r1b4RaQ
bPw/PqMi/PfS/L/uJkA/99Fv0r3Ky9jg+R77HiUX7bF8y2PR6KKK8M9sKKKKACiiigAooooAKKKK
AMPxZqf9j+FdSvlfY8cJEbf7bfKv6kV498K7AXnjaKRvu2kMk348KP8A0L9K9E+K0pj8DSoOslxE
v/j27+lch8Gwv9v6ln7/ANlH/oYz/SvTw65cHOS6/wDAPMxD5sXCPb+v0PaKDRRXmHpnyjL/AK+X
/eP86+iPAH/IiaT/ANcf/ZjXzxOCs8qN/DIV/U19D+AP+RE0n/rj/wCzGvazP+FH1/Q8XLf4svT9
Tx/4l/8AJQNU/wC2P/opK7n4M/8AIG1T/r6H/oArhviX/wAlA1T/ALY/+ikrufgz/wAgbVP+vof+
gCniP9yj6R/QMP8A75L1Z3Wv/wDIu6r/ANec3/oBr5f/AOWdfUGv/wDIu6r/ANec3/oBr5f/AOWd
TlfwyKzP4on0/pv/ACLNr/15r/6AK+YE/wBWtfUGlpv8OWSf3rRB/wCOCvmDaV+RvldflZaMt3n/
AF3DMtofP9D6W8H/APIm6J/14w/+gCvJ/i5u/wCE1TP/AD5x7f8Avp/65rt/CPjTw/F4V0+3uNUt
7e4toEhkjmbYQVGO/XOM5HrWD8YdLaT+ztZiUPEFNvI393PKH6ct+YrDDXp4p8yte5tiWp4X3Xe1
jzrStO1jUPN/sq2u5/Kx5n2fPGc4zj6H9a0v+Ea8Yf8AQO1X/wAe/wAaseAvFKeF9bd7jd9juUEU
2OSmDlWx3xk8ehr2qPxb4ekhEq65p+zH8VyoI+oJyPxrrxOIq0p2ULo5cNh6VWF3OzPCZPCXimV9
8mjag7f3mjJP616L8J9H1PSH1f8AtGxntfN8ny/OXG7G/OPzH51ev/ipoVnq0FpCXurfdi4uo/ux
ehAxl+euO3TPSu4t7iG6t47i3lWSGRQyurZDA9CDXHicTWdPlnCyZ1YbDUVU5oSu0fO/j3/ketX/
AOu3/sor0n4Of8ivef8AX83/AKAleceP42j8eatu/wCewb80UivR/g5/yK95/wBfzf8AoCV1Yr/d
F8jnw3+9v5no1eM/Ejxymob9D0uXdaq3+kzL0lI/gB/ug9T3I9OrPiL421OTUrzQbUm2tYG2SMjf
PNwCQT2XnGB17nnFcFp2m3er3sVlY27T3En3VX+ZPYD1NZ4PBqNqtT1X+ZeLxblelT9GWvD2hXHi
LXINOtv4uZJP7iD7zH+nuQK+krKzg0+xgs7ZNkECLHGvoAMCsDwd4StvCmmCJdst5Lhrib+8eyj2
H/166muTG4n207R2R14PDexhd7sKKKK4zsCiiigAooooAKKKKACiiigDifipD5vgO6f/AJ5SxP8A
+Phf/Zq88+FF6tp41WF/+Xy3eJfqMMP0Q17H4j0z+1/Dmo6ePvTwMqf72Mr+oFfNtleXGmX8F3B8
lxbSB13eqnOD+WCK9bApVcPOl/X9aHk41+zrwqH1RRWZomr22u6Rb6jat+6mXO3uh7qfcHitOvKa
admeqmmro8a8afDfUTqs+o6ND9pt52MkkCsA6OeWwDwVJ545GcYr0PwTaz2fg7Tba6ieKeOIq0br
gr8x6iuiorepiZ1KahLoYU8NCnNzj1PEfHfhTXtT8aajd2WlzT28vl7ZFxg4jUHv6gj8K674W6Nq
OjaTfxajaS2zyThlWTHzDaBnivQKKqeLnOkqTWit+BMMJGFV1U9Xf8TN1qGS40LUYYl3SyW0iIo7
kqQBXgH/AAgnijZ/yA7n9P8AGvpGijD4qVBNRW4YjCxrtOT2KOlRPDpFnDIm10t0Vl9CFAIrzHxn
8Mby61GfUtDEcizsXktWYKQ56lCeME84JGO3oPXKKzo150pc0TSrQhVjyyPnB/APir5v+JNc/wDf
S/8AxVe+3OnW2paMdPvYvNt5YgkiN9B+RB5z2IrSorTEYuda19LEUMLCje2tzwzX/hVrOnTu+lD+
0LX+H5gJVHoynAP1HX0Fcu3hbxAr7Doepbv+vV/54xX03RW8MyqxVpJM555bTbunY8A0b4ZeIdUn
X7Rb/wBn2/8AFJcdfwQHJP1x9a9o0DQ7Xw7o8WnWnmNHHk7nbJYnkn0GT2HFa9Fc9fFVK2ktjooY
WnR1jucB478Af8JK6ahYSpFqCqEYS5CSgdMkDgj1xz0q18N9C1Hw9od1aalCIpWui67ZAwK7FGcg
+oNdrWdPq1hbahb6dJdxreXGfKgBy7YBJOB0GAeTxU+3qSp+y3Q/YU41Pa7M8z1X4b6r4h8aajeS
vFZ2Ek25ZWO9nG0D5VH07kfjXoPh/wAMaZ4atPKsINrt/rJn5eQ+5/oOK3KKKmJqVIqLeiHTw9OE
nJLVhRRRWBuFFFFABRRRQAUUUUAFFFFABRRRQAV4L8TPDLaL4ga+gT/QtQYuvoknV1/H7w+p9K96
rN1jSbXXNNn0+9j3wSjn1U9mB7Eda6MLiHQqc3Tqc+KoKtDl69DwnwX4yuPCl8yOrT6bO376FeoP
Tcv+1jt3H4Ee86bqllrFkl5YXKTwMPvL/IjqD7GvnzxT4U1DwtfeVcp5tqzfubhV+Vx6H0b1H9Ko
aRrepaDdfaNNu3gb+Lbyr47Mp4NepXwkMQvaU3q/xPLoYqeHfs6i0/I+oaK8r0X4wQSbYdasWib/
AJ7W/wAy/UqeR+BNd1pninQ9X2fYtTtpXbpHv2v/AN8tg/pXk1MPVp/Ej1qeIpVPhZtUUUVibBRR
RQAUUUUAFFFZl7ruk6dn7bqdpbn+7JMoP5ZzTSbdkhNpbmnRXDX/AMU/DNnuEM1xeP8A3YYjj82w
Pyrk9T+MV/KdmmadBbp/z0uGMh/IYAP510Qwdee0bepzzxlGG8vuPZa5XWfH/h7RAyS3yz3C/wDL
C1HmN9Ceg/EivD9W8U65rm9NQ1GeWJv+Watsj/75XAP41j13UssW9R/ccNXM+lNfed/r3xX1fUd8
OmIunW/95fnlb/gWML+Az71m/DuWSf4h6dLM7Sys0rMzNksfKbkk8muXt7ee6nW3topZ5W+7HGpd
j9AOa9T8A/D7VtO1e21nUilsINxW3+/I25SvzY4XrnufpXTWVGhRlFWV0znpOtXqxk7uzR61RRRX
z574UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAU72wtdStJLS9t4p4JPvRyLkf5968p8SfCW4
iZ7nQZfPi6/ZJmww9lc8H6HH1NexUVtRxFSi7wZjWw9OqrSR8q3lldafdtb3tvLBKv8AyzkUofrz
296rkA9a+p77TrLUoPJvbSC5i/uzRhx+tcZqXwm8O3nz2v2mxf8A6Zyb1/Js/oRXqU8zg/jVvxPL
qZbNfA7njVrrWrWP/Hpqd7bp/djuGA/IHFa8PxB8Vwfc1qf/ALaRo/8A6Eprp7v4NajH/wAeOrW0
v/XaNo/1G6sW5+F3iuD7ljBP/wBcbhf/AGYrW/tsLU3a+f8AwTH2OKp7X+X/AABqfFHxYvW+if8A
3rdP6AVIfin4qP8Ay82//fhazn8AeKo/vaLP/wABZD/Jqi/4QrxN/wBAO7/790+TCv8Al/AXPil3
/EvyfEzxa/TVET/dt4/6qapzeOvFNx9/XLn/ALZ4T/0EClTwJ4pfpodz/wAC2j+Zq1F8NfFsv/MJ
8r/akuI/6MT+lP8A2Vfy/gL/AGqX834mBc6vqd3/AMfWo3k//XS4Z/5mqOAOlegW3wg8Qy/665sY
E/66M5/ILj9a2rT4MKBm91l2/wBmGHH6sT/Kk8Zh4faXyBYTET6feeT0IhkkVETc7fKqryW+gr3q
w+FvhiyGZbae8f8AvXEx/ku0fpXT2Ok6fpceywsba2TuIYwn8hzWE8zpr4U3+B0Qyyb+J2PA9L8A
eJdW2+XpzQRN/wAtLr90PyPzfkK7nR/g9axbX1m+adh/yxt/kT6Fj8xH0216lRXFVzCtPZ29Dtp4
CjDV6mZpeh6ZoluYtNsobZCPm2Ly31Y8n8TWnRRXE227s7EklZBRRRSGFFFFABRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//2Q0KZW5kc3RyZWFtDQplbmRvYmoN
CjE2IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0V4dEdTdGF0
ZTw8L0dTNSA1IDAgUj4+L0ZvbnQ8PC9GMSA2IDAgUi9GMyAxOCAwIFI+Pi9YT2JqZWN0PDwvSW1h
Z2UyMyAyMyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4v
TWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMTcgMCBSL0dyb3VwPDwvVHlwZS9Hcm91
cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxPj4N
CmVuZG9iag0KMTcgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzE0Mz4+DQpz
dHJlYW0NCnic7VtLbxzHEb4T4H/o464BDvvdPYFhIJYcy0EISBHjGLADg6IoWQ5XTKhHcspvz/dV
9czOkjO7zC22rAN3qqerurq63tMyp0/N55+fnj365rGxX3xhvnz8yPzz+Mga21lrnfe2mOKtSdGa
26vjo79+Zt4eH51+/TyZ1++Oj5x5PU62Njsbd2a/+uz46Nnxkfnq7JExk5Xc6Z8u3r42q6u3J395
vm7LfnkOwn9wJsbO5mjOX5E8aBtnSuhq8Sam3HlvzjdcUxb++vjo+9XH86dn6xO/Mq/WPq5ubs2T
bxVe/82c//H46CsQJvGBWoi5K3VKDTTe3L7/cHG9hBKL63zcRdlcXP705u2V+d0U6d5W/WR3A7VM
Mm6X2l4iYVlewQR/T16xdjWaQLEp+c+treWL3b1R1jO4NXY17yCvnl1tPph1XL26Xbu6unm7rqv3
axfAzssFefmaulJ2iOzdYDy0wdn9+dIVf3iD8/ubIK+efNxc31y8vLo9XXu/end18eLNOqxu3i0p
UChd7HdJ7N1eWtre7oZ8dR1P4x7B6VQojb071Zj1SVjEwFm4XRQabEg4mcvvVycnC2jAoZnsoAmG
/TcMra6uXkYLKcHuoRr/2Q4mDL6ieugfsObS6tT8fu3c6tHTb5YsrA9d6JdFcE+meZ8PWbQJH1KX
HkS/HKI/R97Vvov5IeTrw1TCRYglPYRg/zCCfen8VmmHf0sq4GLn7uLsY8INMcR2OUlwiB57iGaj
TwnjAd60g2cAlBEp5Ofy+ChnK4/XfMycRiiXEUseQYpz8djrVDxB5iTXsLBHkqoyEeTxgHltSQBx
RIhCBLN+0kjlzb8QU+iSbRdywt8UnfkzYgxE8bP5pWzl+dy57I24ru6ocqDOgUEXul4OXQ7SabD9
bu16UNnnb0JJE+RDGuNHjQnwqVgIobbWYLyrHXa22Q54mG41Bb43FBiy6xyl0PnaDxAE4ODtYh0G
IC7X+y6EYcBBl2sdaA2QLkVsHXC575xT7DbgO59No4XT7IppKykA3MaKwkBtjCrc9tDojJAss9XA
WeX7VAUyq8eLmdDosryny3J9hQe6o73mhIlqliCGFHHB58G+yhS/Rb39WryYwGyjqROBQQh28Ocf
1ydl9f4fm81rmtPt3gXSHM0MJndJ7ucy3/XOPvVw7cbD8jZbKMHfQwly6nr+IGqWKC+yeKIQRgin
GqLvUhIIBjzBHyDQJpJCrmBtp3g6kEWDGhWXEl+3FRoE7MZAGwB2Y64NNMYbrQHSpQ5Z1ycjgll7
Wsxytpk88s0Mb5FpVnejwQ+rb5Htnf2wXgoFsEbEpgn2IRU9mBf5WroMkkhNxkTu/ClS0LPFeATf
xi1MMfYzcTCX8ihsini/fqD44uLy7+uQWmxcKox4rL3fxdxfP9rDAnGiB/ChYSD5+BYCYQ3zcQ2O
bhcFk5ls72DuZ8aNDiQh/7BdsbSoGoO5hVIkH0jPR/oXWtM4EKiNyUtR6CPCBIAq+b4AzIMQPHxs
MLMhHHMdJufeDkT0URYgFiHvqBDXDULo6nszoLuMas8MxBViMtVW14FrDihvOjDwrbQGSNc55E8+
ISHMeRTvD+lrgsOC2jDjsOWeR3l2RfPZfFhQ2WztHeTlSjmjgHW7U8+fnkmp/P4N7OLdXlUPs40b
1FB7Vr9PJT7IYCzSnjLVFWTPluqRh/PA6xSsvhNItCUMkOhKHg7bNQ1RKvKoKzRlcfAYDYkQ8oeA
vSm+Q5ghPrMxfaSm6NJtQDRFOGsDjetGaIB0kYeay69eBLPGcrAxlJgGMJ3tZ2oxaXzGlfmObTmN
O+/YZXn/4cVLNkBvNu8WbaOCwzyhe0iRF9stI6fcLLNROJWxyeS85s6LzSz2S+IOkiC8vH2Djd0L
XvfZKnNWGpBI+QnRQ3urk8a3drJtyb12tX2MLs60wBcMGvrmWOb3/KE2OwvX7bJ6+8hkiOHWwaHG
qFv3zN6pYUnzPwzAK6cMqjIXGplyoUdmOocijXNLYlvI4cdCisgmRFkRzuH1bZYUA4oZNKpA80HR
IWfBeHaOcYMQDMM1tfVdkRw1OxxIEVIRISOolkCr+2RybItmbo6TY5WisUgGipKiUwNBfZhT6FJb
s2pPxDOMkFQEqdLraykmYYJdroLaK8d9krJSsqyMUkxYchLToLFJRaGVYkFaB+ZYC2ELBTK2LCSD
QNgNm2hw233SyT07txxAKkjI6mueMQId1Qape9HJMHlKHedSHCgXbcglclMgRVp/dNwHJ0PqBZMR
lSHrgjBVwVToUaDlPlI+BILKDQPcEaRbGaWtbNZjY2z9BAY4gdRbsZSIOlBFyBQ5WIPEYxa5oZK3
2njC6pXIEAkE56F7rIidEEYBajEZrimoR2MOWmSyS7DEpFBi05fGzPrBq7ZlJ4U9ZnrMDDLFwf95
zRJY5NPmNKmA5KPCVd4mfZt1btR3RXtatA59DVIRB00Rgj68ZmTXMYjUvLQiYp/FfCBySFgmS3sU
NpNsoFbxbFzUuV6QUcsj6MRaqc0uyZlFKBdVBGlIcDpZojoPPpCWHDCVAobnIKMwUaCfxo9a/5uz
mA19vzmL35zFb87iV+0snouvWLL/ojzC9rLav5ePBVFyvmSbDkVKhVwXYTo00YkGUC1iKzMLm4GA
vZMqU04+0F+IYL1ITu1LTizzxMgYkWFi1ckAlkLixHPACuAmwexo9UF0tRmyS0I7y9eQDMFx30Ec
CyGKl5/IgmhdEaXzWqsWTbGjlJ4bLXHla0hmx5nKnvSkvNoCVSmImxGLrKKkEH7ttROexT+lTI4L
PzpkOSxwUKAvNP4kbR+xpOZHsBNZGjC1Mfc8aVqh1RY0WAWkXqL5LmA68XxOt5ysSB8D2A3tjD3x
Ivol3kxdqtM9w/wpH7ryKtg4Z/GNjraRnRKCDtDDCiFP5yvGVNRZW3IuB2XVPVu61URXnIRnKja9
aRG2ezWYKMtQVaPqFz/HEwZ1AqF5NycQ+UhDA362XDnYF2N5rh1+OzTfv9YPjWx1y3fqegdYqgzU
CzjUP3Fobk++Pf34cX3Ss3f+8urjjzf/QLGwt5oPdo7Z3FzIZIn91zC27S9N+3OgQeMMmfuHwHrD
hcLT34wwEoFAP08d9/TW7PPWAeAxIeKOL1lYMuaOE3gwRai0J6V/qacJGGEpNTyFC9V4IOKk19KW
UOBSG9bjS2lEK4M60BhXQgPQt1X3FvOfjAjmrCMc7HwFuCJ2arUpfreaf7LUpc3SPJ9gofLX+yos
8oc7K7SKixdvbvbbwVxXi8HT9rsL7LeDbVerwncwz6zyV2tgXvqBCOFKenU7bQD7YP6J6FJ4v8jy
deJ1HD9AdJa+TgbYn4F5wku3gYxYsKU1QLoUsXXAIwIM2DoAB84WqNJCmi60dKkGSViMkwHqk/La
Bto+Gq0B0qUOtrk+XaHM2srhxhfSMMS0gFB5v0n8ZB2WP+Bm5D5IR7eYh7T5cGsLeYgtCH8I4I3i
t4tfmzJz3LAzef/yZRtUUruBwnIy9tJeQrI/7ZPqx/MWy/0AJxs1Ka2M3iMk9Yy4Vx1ALpu0dzkM
IDMwTJWZCEiOHFnDyFNLosc3DcdbO1nDo07YWcPTN0/X8CxkTOOW3yzGXqkCC6lGqNtrIeJhULNg
OszpVi4VZdlNlbQ5sKIdB2AFYCsxf5TH8XOHQF6S+4ZBZvFDau2Rm2YKFMd3dUSSx5GaQo5nFZE8
I9BwUeT9EVlFxPlbT2McZip0rVDj9PoBN49+VVudPejD99ZQ+aQqX57S/R74s6sNo+CHxY+/vTQV
pNE9dLp5jzXyHmviPda5T7b3L6jOJZAR9mbzLu3911zdttN80rpHzvq0v3uky1HvM++YQaJ9K50g
kQEevvyhjMfJCFR33pamSA1iOYnX1TZzLXCXfrx9MH4XcUyA5B6bNDomr1HI+SmBnc7Ywzc3f9/O
mp9NNWf/7xt+Pn+9Pfp9dUK2hg0t2ZA18vEeRSONJsmNP5Sr7cqfh6PsQ7v25710NHiH1YvZNcwG
CUnBETBTUtcjCEMn+UYD/DfSrWvEJXVTjQ8A4K1h4UnIHcpxfuEbm/NOcc/Ne96bRK2wew3Y+SKd
N1Te/f0U//wpXM7ixbOsydwW9ZA3ife9SXTZtf+7UYNzMwbXW1kPrjsUj+TPyn9uyMFcYsXTbzYX
r698MI9vzKDZ/wUhRLTyDQplbmRzdHJlYW0NCmVuZG9iag0KMTggMCBvYmoNCjw8L1R5cGUvRm9u
dC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FyaWFsL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2Vu
ZGFudEZvbnRzIDE5IDAgUi9Ub1VuaWNvZGUgMTQ5IDAgUj4+DQplbmRvYmoNCjE5IDAgb2JqDQpb
IDIwIDAgUl0gDQplbmRvYmoNCjIwIDAgb2JqDQo8PC9CYXNlRm9udC9BcmlhbC9TdWJ0eXBlL0NJ
REZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0
ZW1JbmZvIDIxIDAgUi9Gb250RGVzY3JpcHRvciAyMiAwIFIvVyAxNTEgMCBSPj4NCmVuZG9iag0K
MjEgMCBvYmoNCjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVt
ZW50IDA+Pg0KZW5kb2JqDQoyMiAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFt
ZS9BcmlhbC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA5MDUvRGVzY2VudCAtMjEwL0Nh
cEhlaWdodCA3MjgvQXZnV2lkdGggNDQxL01heFdpZHRoIDI2NjUvRm9udFdlaWdodCA0MDAvWEhl
aWdodCAyNTAvTGVhZGluZyAzMy9TdGVtViA0NC9Gb250QkJveFsgLTY2NSAtMjEwIDIwMDAgNzI4
XSAvRm9udEZpbGUyIDE1MCAwIFI+Pg0KZW5kb2JqDQoyMyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0
L1N1YnR5cGUvSW1hZ2UvV2lkdGggMjU4L0hlaWdodCAxOTYvQ29sb3JTcGFjZS9EZXZpY2VSR0Iv
Qml0c1BlckNvbXBvbmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5n
dGggNjY1Mj4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEBAAAAAAAA/9sAQwAIBgYHBgUIBwcHCQkI
CgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJ
CQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIy/8AAEQgAxAECAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkK
C//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNi
coIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SF
hoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn
6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQE
AwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBka
JicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWW
l5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5
+v/aAAwDAQACEQMRAD8A9/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKqXl9aafbm4vLmK3iX+OZwo/M1xerfFnQbHclik+oy4/5ZrsT8Wbn8ga0p0qlR+4rmdS
tCn8bsd/RXhuofFrxBeP5dhDbWYb7u1fNk/NuD/3zWebLx94i++mrzo3/PRjFH+AYqv5V1rL5pXq
SUTlePg3amnI9yutY0ywH+majaQf9dZlX+ZrHuPiD4Vtfv6zA/8A1yVpP/QQa8vtvhL4mm/1i2Nv
/wBdJsn/AMdU1qw/Bm9b/X6zbRf9c4C/8yKr6vhY/FUv6f0yfrGKl8NO3qdbJ8U/Cq/du53/AN23
f+oFRf8AC2vDPref9+P/AK9YUfwWQf6zXnb/AHbUD+bGpD8F7btrk/8A4Dj/ABp8mBX2n/XyFz43
+Vf18zcj+KvhZ+tzcp/vW7/0BrQtviD4UuvuazAn/XZWj/8AQgK4t/gtIB+719W/3rPH6h6y7n4Q
a9F/x73NjOP95kP5FcfrR7HBS2m1/XoL22MjvBf18z2S11Kyv499ndwXC+sMgb+Rq5XzZf8Ag7xJ
o8nmzaTcrt/5aQ/vAPfchOPxxUulePfEmkn9zqks8X/PO6/ej6Zb5h+BFN5dzK9KaYLMOV2qwaPo
6ivMtC+LthdMsOs27Wb/APPePLxfiOq/r9a9Ftbm3vLdbi1mjnhkGVkjYEH6EVw1aNSk7TVjtp1o
VVeDuWKKKKyNQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKwfFL62ujOugIrX0kiorNjCK
erc8ce+fpTiuZpCk+VXLGteItK8PwedqV2kAb7i9Wf6KOTXm2pfE/WdauPsXhfTpV3f8tfL82X67
RlV/HNaul/CxJJ/t3ibUJdRum5aNXIX6Fj8zfpXe2GnWemW/kWNpDbRf3Yowo+px1PvXWpYelsud
/gcjjXq7vlX4nkVt8NfFHiC4+169ffZ93/PaTzpfwUHaB7Z/Cuu0v4U+HLHa90k99L/02kwv4KuO
PY5rvKKmeMrS0vZeWhUMHSjra789SjY6VYabHssbG2tl9IYwn8hV6iiuZtvVnSkkrIKKKKQwoooo
AKKKKACsDWvCOia+rfb7GNpf+e0fySD/AIEOT9DkVv0VUZSi7xdiZRUlaSueFeKPhjqGjI13pjtf
2a8su396g9SB94e4/Kud8O+KdT8M3fm2E37pmzJbtykn1HY+45/lX0vXk/xI8CRmCXXtKi2uuXu4
VXhl7uo7EdSO/XrnPqYbGKp+6r63PLxGDdP95R0sd14a8TWPijThd2blXX5ZoW+9E3ofUeh7/mBv
V8yeHdfuvDmsRaha/wAPyzR9pU7qf6HsQK+j7C+g1KxgvbZ98E8YeNvYjNcuMwvsJXWzOrCYn20d
d0XKKKK4zsCiiigAooooAKKKKACiiigAooooAKK4Dx546/sTGk6T+91efC/Ku/yd3Tjux7D3yewP
UeHba6tfDmn299k3aQr525tx34ycnuc961lRlGmpvrt/mZRrRlNwXQ8mf4veIVkdBbab8rEf6l//
AIuvVvDGpz6z4bsdRuVjWaePeyxqQvUjgEk9vWuAf4LF3d/+EgHzNu/48v8A7ZXonh/Sf7C0Kz0w
zef9mj2eZt27uSc4ycdfWurFywzglR3OXCxxCm/a7GrRRRXAd4UUUUAISB1rH/4Svw9/0HdN/wDA
pP8AGtS5/wCPSX/cP8q+UV/1aV24PCxr813axxYvFSoctle59WQzxXMCTQOskUihlkRshgehBHUV
PWH4P/5E3RP+vGH/ANAFblcklyya7HXB3imFFFFSUFFFFAHh3i/xp4j0/wAW6jZ2uqSRQRS7Y41V
eBtB7jPeu4+GOs6hrfh+6udSu2uZluiisygYXYpxwB3Jrynx7/yPWr/9dv8A2UV6T8HP+RXvP+v5
v/QEr2MTTgsKmlroeRh6k3inFvTU0dV1TU111IoLho7fzfLk2quIBlBuZiepDlhkEfdGBy1dRYzm
9022mmVd80Kuy9uQCeD2ouNOs7p/NntIZX27dzIDwOQD6jParteXKUXFJLY9OMWm22fNnjLRBoHi
q8so022+7zYf9xuQPwOV/CvSPg/qzXOjXmmSNn7JIHj/ANx8nH/fSsfxrG+M9uq6rpdwPvy28iN9
EYEf+hmqnwfmZPFV1D/BLZk/irrj+Z/OvXqv22C5pb/5HkU17LGcq2Pb6KKK8Q9sKKKKACiiigAo
oooAKKKKACuY8a+KIvC+htcLta8mylrGe7/3iP7q9T+A7109fPvi/U5/GHjn7NatuhSYWdr6fewW
/FsnPoB6V1YSgqtT3tlqzlxdZ0oe7u9EdN8MPDr6hdS+KdT3SuZG+ztJzvf+KQ/Q5A98+gr1w1S0
2wg0vTraxt12xQRhF/AdT7nrV01nXrOrNy6dPQ0oUlSgo/1c+aZPFviNXbGuah94/wDLw3r9a908
FXM154N0y5uZnlmki3NI7ZLcnqTXznL/AK+X/eP86+iPAH/IiaT/ANcf/ZjXpZlCMacbLqebl05S
qSu+n6nmPj7xFren+N9RtrTVruC3Ty9sccxAXMaE4APqSfxrm/8AhL/Ef/Qd1D/wIb/GtL4l/wDJ
QNU/7Y/+ikrrvhLpljf6TqL3ljbTulwArTQqxX5BwMit+anRw0ajjfRfkY2qVcRKmpW1fc4AeMPE
fbXNQ/8AAg/4113g/wCJuow6lDY63N9ptZmCCZlAeIngEkD5lz1zzznPGK77xL4X0Obw5qBGl2kT
x27vHJHCqshVSQQQM9RXzueY6VJ0cXBrlsOqq2FmveufV1z/AMekv+4f5V8op/q1r6hspGm0G3lf
772qs31KA18vJ/q1rDK1bn+X6m2Zu/J8/wBDXi8Ua7bWqQwazexRRrsjjWZgAAMAAZ6V9E3GoW+m
aN9uvZfLgiiDySN9B+ZJ4x3JrF8LaFpM/hLR5ptLspZXs4mZmt0JZigySSOTXI/GHVmT+ztGifah
U3Eir3wSEH04b8hWVRxxVZU4q1m7mtNSw1J1JO97WMHxF8T9a1WZk06ZtOs/4Vjx5rD1Z+x9lx9T
XK/25q3mb/7Wvt/977U+f5103w38MW3iLW5nvk32lmodo+zuxIUH24Y/gK9rfRNLktPsj6daG324
8vyV2/gMcV0VcRRw0vZxic9KhWxK9pKVjx3wx8T9T0y6WHV5mvrBuGduZYvcH+Iex59DXtsE8Nzb
xTQuskUih42XowIyCPwr5z8ZaGnh3xPdWMO7yOJId3XYwyBn2OR+Feo/CXVHvfDEtjI+57GYop/2
G+YD89w+gFZY2hB01Xp7G2CrzVR0ajvY8y8e/wDI9av/ANdv/ZRXpPwc/wCRXvP+v5v/AEBK828e
/wDI9av/ANdv/ZRXpPwc/wCRXvP+v5v/AEBK2xX+6L5GGF/3t/M9GooqC4nhtbeW4mdY4olLyM3R
QBkk/hXiHtnj3xku1k1zTrQf8sIC7f8AA2xj/wAc/Wofg7bs/ie8uP4I7Mr+LOuP0U1yHiPWG1/X
7zU23Kk8n7tW7IPlUfkB+Oa9W+EWkGz8Pz6jIvz30vy/7iZAP/fRb9K9ysvY4Pke+x4lF+2xfMtj
0eiiivDPbCiiigAooooAKKKKACiiigDD8Wan/Y/hXUr5X2PHCRG3+23yr+pFePfCuwF542ikb7tp
DJN+PCj/ANC/SvRPitKY/A0qDrJcRL/49u/pXIfBsL/b+pZ+/wDZR/6GM/0r08OuXBzkuv8AwDzM
Q+bFwj2/r9D2ig0UV5h6Z8oy/wCvl/3j/OvojwB/yImk/wDXH/2Y188TgrPKjfwyFf1NfQ/gD/kR
NJ/64/8Asxr2sz/hR9f0PFy3+LL0/U8f+Jf/ACUDVP8Atj/6KSu5+DP/ACBtU/6+h/6AK4b4l/8A
JQNU/wC2P/opK7n4M/8AIG1T/r6H/oAp4j/co+kf0DD/AO+S9Wd1r/8AyLuq/wDXnN/6Aa+X/wDl
nX1Br/8AyLuq/wDXnN/6Aa+X/wDlnU5X8Misz+KJ9P6b/wAiza/9ea/+gCvmBP8AVrX1Bpab/Dlk
n960Qf8Ajgr5g2lfkb5XX5WWjLd5/wBdwzLaHz/Q+lvB/wDyJuif9eMP/oAryf4ubv8AhNUz/wA+
ce3/AL6f+ua7fwj408PxeFdPt7jVLe3uLaBIZI5m2EFRjv1zjOR61g/GHS2k/s7WYlDxBTbyN/dz
yh+nLfmKww16eKfMrXubYlqeF913tY860rTtY1Dzf7KtrufyseZ9nzxnOM4+h/WtL/hGvGH/AEDt
V/8AHv8AGrHgLxSnhfW3e43fY7lBFNjkpg5Vsd8ZPHoa9qj8W+HpIRKuuafsx/FcqCPqCcj8a68T
iKtKdlC6OXDYelVhdzszwmTwl4plffJo2oO395oyT+tei/CfR9T0h9X/ALRsZ7XzfJ8vzlxuxvzj
8x+dXr/4qaFZ6tBaQl7q33YuLqP7sXoQMZfnrjt0z0ruLe4hureO4t5VkhkUMrq2QwPQg1x4nE1n
T5ZwsmdWGw1FVOaErtHzv49/5HrV/wDrt/7KK9J+Dn/Ir3n/AF/N/wCgJXnHj+No/Hmrbv8AnsG/
NFIr0f4Of8ivef8AX83/AKAldWK/3RfI58N/vb+Z6NXjPxI8cpqG/Q9Ll3Wqt/pMy9JSP4Af7oPU
9yPTqz4i+NtTk1K80G1JtrWBtkjI3zzcAkE9l5xgde55xXBadpt3q97FZWNu09xJ91V/mT2A9TWe
DwajarU9V/mXi8W5XpU/Rlrw9oVx4i1yDTrb+LmST+4g+8x/p7kCvpKys4NPsYLO2TZBAixxr6AD
ArA8HeErbwppgiXbLeS4a4m/vHso9h/9euprkxuJ9tO0dkdeDw3sYXe7CiiiuM7AooooAKKKKACi
iigAooooA4n4qQ+b4Dun/wCeUsT/APj4X/2avPPhReraeNVhf/l8t3iX6jDD9ENex+I9M/tfw5qO
nj708DKn+9jK/qBXzbZXlxpl/BdwfJcW0gdd3qpzg/lgivWwKVXDzpf1/Wh5ONfs68Kh9UUVmaJq
9trukW+o2rfuplzt7oe6n3B4rTrymmnZnqppq6PGvGnw31E6rPqOjQ/abedjJJArAOjnlsA8FSee
ORnGK9D8E2s9n4O022uoninjiKtG64K/MeoroqK3qYmdSmoS6GFPDQpzc49TxHx34U17U/Gmo3dl
pc09vL5e2RcYOI1B7+oI/Cuu+Fujajo2k38Wo2kts8k4ZVkx8w2gZ4r0Ciqni5zpKk1orfgTDCRh
VdVPV3/EzdahkuNC1GGJd0sltIiKO5KkAV4B/wAIJ4o2f8gO5/T/ABr6Roow+KlQTUVuGIwsa7Tk
9ijpUTw6RZwyJtdLdFZfQhQCK8x8Z/DG8utRn1LQxHIs7F5LVmCkOepQnjBPOCRjt6D1yis6NedK
XNE0q0IVY8sj5wfwD4q+b/iTXP8A30v/AMVXvtzp1tqWjHT72LzbeWIJIjfQfkQec9iK0qK0xGLn
WtfSxFDCwo3trc8M1/4Vazp07vpQ/tC1/h+YCVR6MpwD9R19BXLt4W8QK+w6HqW7/r1f+eMV9N0V
vDMqsVaSTOeeW027p2PANG+GXiHVJ1+0W/8AZ9v/ABSXHX8EByT9cfWvaNA0O18O6PFp1p5jRx5O
52yWJ5J9Bk9hxWvRXPXxVStpLY6KGFp0dY7nAeO/AH/CSumoWEqRagqhGEuQkoHTJA4I9cc9KtfD
fQtR8PaHdWmpQiKVrouu2QMCuxRnIPqDXa1nT6tYW2oW+nSXca3lxnyoAcu2ASTgdBgHk8VPt6kq
fst0P2FONT2uzPM9V+G+q+IfGmo3krxWdhJNuWVjvZxtA+VR9O5H416D4f8ADGmeGrTyrCDa7f6y
Z+XkPuf6DityiipialSKi3oh08PThJyS1YUUUVgbhRRRQAUUUUAFFFFABRRRQAUUUUAFeC/Ezwy2
i+IGvoE/0LUGLr6JJ1dfx+8PqfSveqzdY0m11zTZ9PvY98Eo59VPZgexHWujC4h0KnN06nPiqCrQ
5evQ8J8F+MrjwpfMjq0+mzt++hXqD03L/tY7dx+BHvOm6pZaxZJeWFyk8DD7y/yI6g+xr588U+FN
Q8LX3lXKebas37m4Vflceh9G9R/SqGka3qWg3X2jTbt4G/i28q+OzKeDXqV8JDEL2lN6v8Ty6GKn
h37OotPyPqGivK9F+MEEm2HWrFom/wCe1v8AMv1KnkfgTXdaZ4p0PV9n2LU7aV26R79r/wDfLYP6
V5NTD1afxI9aniKVT4WbVFFFYmwUUUUAFFFFABRRWZe67pOnZ+26naW5/uyTKD+Wc00m3ZITaW5p
0Vw1/wDFPwzZ7hDNcXj/AN2GI4/NsD8q5PU/jFfynZpmnQW6f89LhjIfyGAD+ddEMHXntG3qc88Z
RhvL7j2WuV1nx/4e0QMkt8s9wv8AywtR5jfQnoPxIrw/VvFOua5vTUNRnlib/lmrbI/++VwD+NY9
d1LLFvUf3HDVzPpTX3nf698V9X1HfDpiLp1v/eX55W/4FjC/gM+9Zvw7lkn+IenSzO0srNKzMzZL
Hym5JPJrl7e3nup1t7aKWeVvuxxqXY/QDmvU/APw+1bTtXttZ1IpbCDcVt/vyNuUr82OF657n6V0
1lRoUZRVldM56TrV6sZO7s0etUUUV8+e+FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFO9sLX
UrSS0vbeKeCT70ci5H+fevKfEnwluIme50GXz4uv2SZsMPZXPB+hx9TXsVFbUcRUou8GY1sPTqq0
kfKt5ZXWn3bW97bywSr/AMs5FKH689veq5APWvqe+06y1KDyb20guYv7s0YcfrXGal8JvDt589r9
psX/AOmcm9fybP6EV6lPM4P41b8Ty6mWzXwO541a61q1j/x6ane26f3Y7hgPyBxWvD8QfFcH3Nan
/wC2kaP/AOhKa6e7+DWox/8AHjq1tL/12jaP9RurFufhd4rg+5YwT/8AXG4X/wBmK1v7bC1N2vn/
AMEx9jiqe1/l/wAAanxR8WL1von/AN63T+gFSH4p+Kj/AMvNv/34Ws5/AHiqP72iz/8AAWQ/yaov
+EK8Tf8AQDu/+/dPkwr/AJfwFz4pd/xL8nxM8Wv01RE/3beP+qmqc3jrxTcff1y5/wC2eE/9BApU
8CeKX6aHc/8AAto/matRfDXxbL/zCfK/2pLiP+jE/pT/ANlX8v4C/wBql/N+JgXOr6nd/wDH1qN5
P/10uGf+ZqjgDpXoFt8IPEMv+uubGBP+ujOfyC4/Wtq0+DCgZvdZdv8AZhhx+rE/ypPGYeH2l8gW
ExE+n3nk9CIZJFRE3O3yqq8lvoK96sPhb4YshmW2nvH/AL1xMf5LtH6V09jpOn6XHssLG2tk7iGM
J/Ic1hPM6a+FN/gdEMsm/idjwPS/AHiXVtvl6c0ETf8ALS6/dD8j835Cu50f4PWsW19ZvmnYf8sb
f5E+hY/MR9NtepUVxVcwrT2dvQ7aeAow1epmaXoemaJbmLTbKG2Qj5ti8t9WPJ/E1p0UVxNtu7Ox
JJWQUUUUhhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/
/9kNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNCAwIG9iag0KPDwvVGl0bGUoUG93ZXJQb2ludCBQcmVz
ZW50YXRpb24pIC9BdXRob3IoWHUsIFF1YW4pIC9DcmVhdGlvbkRhdGUoRDoyMDE0MTEwNTIxMTU1
MyswOCcwMCcpIC9Nb2REYXRlKEQ6MjAxNDExMDUyMTE1NTMrMDgnMDAnKSAvUHJvZHVjZXIo/v8A
TQBpAGMAcgBvAHMAbwBmAHQArgAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAgADIAMAAxADApIC9D
cmVhdG9yKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABQAG8AdwBlAHIAUABvAGkAbgB0AK4AIAAy
ADAAMQAwKSA+Pg0KZW5kb2JqDQozMSAwIG9iag0KPDwvVHlwZS9PYmpTdG0vTiAxMTkvRmlyc3Qg
OTc2L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTc3Nj4+DQpzdHJlYW0NCnicrVnbbhQ5EH1H
4h/8uPvULt8tISR2AS2CRRFB2ge0D0PSGyKSGTRMJPj7PdV2Xyb0uHt6Rpqk+lLHrnIdl8tuFYUU
WgtLQitB0ghtBTkntBOKvNBeKBeExo+i0Ph5KQx+ioTBzytcCqu0MGjEW2GMcMoLY4Xz0DbCa6g5
ERxUgogEFS+ig0pEfypy1yQDoRFBxKZIyBCE1YKU9cLCIC2h5yAd9IwgQ9wbZEDnaMeiIwecDU7Y
AAdgMFTJSy/QMXkoObQfiIQDPngt4CRFxXZCeuhZoSQGAe4qkiTgqELDwpNQSkIvQqITuKw07EYT
Ske8N0IZGAPnlcWweIycDVZ4Hjo4iWFQnttDux5OBLQbKAiYrgI6geuK7QhoLwYvANUSIx0QCxkN
Rg5jzzjEQEngEBUFpwKGVwOn8FzjJiKEDn4Coj38hGnaw6nI4YNSBC6gUZKIeETUIgcUb6NDRHk0
JcdUcTgQVYJ/JBE0hT6YGEZ51kH82PvIMrAu0KZpNiDqmlU4/JFfRUSew0fMFLwnQsOeA0GgUACj
EHFcsDITI4I9RGiQzSLQz8qGFSAD90NkcMFxBtIq0ImttRp2k5K44NArMAI24wLKBkEBicAhmExg
qWWGkAJLXKOMlnmsCJS13vETtBx4KoC2NoSGe6CY4SfghmQzGrIx7TBXHHvAtHXERMK0cWAFLph4
GDXCjdM8ukxJQ0xeiQuwASwG6TBvCH+IHFpGN87xBOBp5KEcoeuZQeCTRAuw3HMnsNdrMBHGeYNu
ogLfwIxnz6oLZoQUH6rL6vLbal19/Pmtri5324er3au7+r66uBG6ef9WyOfPnz5pIPAtQS5+0X/7
SYCh/4oO2IG6fj7WP3afNz/GoLqBjKExioUu9fEQczzEHg9xx0P88ZBwPCQeDyG5AEMLMKP0mcCM
MmAW5Szr8ArWCJ9ESCI2AlOwEZSESkInYZKwh4g7e3qR6TDGF30d5eEcX0043UrXYawsWjnK4wkM
0twoMec4Z1N4rDrZR9VnOltknRpl9wRmcXK0ianWne6g7o0NRWNHs+QEZjE9bZpuTp7uYM9SV1yr
1ChL5xjrDi5V860MvZW2aOXopChjsNbrUXrOci5lQ+dP9lGr3t5YtHc0g09geAOy1EefsrqnSR9f
3948bOvqxd3ut9/FqB2jy/wR+DILp/GjBcAR+HLSncSb0cpgNkcMdRhfTC1Yes3ihd7Hk8ls+iU6
UNFQbE/KnCgYGk5fwYzvDS1XwdiGLV5xw+lFj+2X2lAseixv+RcbOl33THLcjhOvzcGXd7fX9Xju
TqVkqhp1LhdTfk11Hp9tNAt7Skg2FZapiuBzi0akgtSlGietaXw20YhUF7iskhrzScWnxnzS9EnT
p959ajpNOT5oaETqISRcIg8fKjQiAcLBiRTb6u5Q2MnluPdhj7pYEbZ7yYT8tadC1KPp7XwMb7n2
7o/N9c/CjvIxzrW4N6M9hsM9xqkezZIe+XjmYJctN9+N2pqCGeM0vrQZPgrjFmD8AkxYgInLeZZm
Bx+IJamy1FmaLO3hoZ49caifOXx0Vpo6tNgjPp07g6l96ccneCVTx2fbFMp0W+ElPlIOF6lz+OoG
VpdPKsYJPYUap/QUapzUEyglTxhUmwc1zwnyWZ6DUKqvE/kEt+QCn7ov90LROaw1A2uLi5waZ/EU
ynW710U+5qykzpGVBjtZPhwvWR2xMz3B6nPwSA94pIs8QtWmT+CRPgeP9IBHusgIfYBHE6gDq/Is
BzOJ9AwSzd4FLx+pAQt1cSOpY7dnXeR2oWia7a6ZWJ8n3TWD9dUUT7nMCRw2+hy+jhe307unmBbp
tEnIFVzzFTHJvLrImFcZmWWuvCjTk/J7ld+rXKGprKdyeyq3l/dsOTk03/KSzPr5YwHlrwWZbM23
uiRzaZE/FZA5tBMZePxxW9cfNptd9WFzV/+9+iaSUdXFaluvm7ciZ1bOoqnD2BX/ndJ7hPJt/VO0
3HiNJtebXV2953+v1tf9TRv1y/pqV/1Vr67rbbpmTHv9Zn13u64vv6zYUH7wYo0WVrvbzTrfb3e3
/61w0dz9s9l+/bzZfK1ebq4e7mFT8+T7l7resZG76u/V1XYzuP/zC/4P7l/eru42N4MHiRq9buoH
ajfb1X1mXvb1/cP9908YkTZs/J2zGR9+3+/E9Z444+efbluf4O22fvhdohN5kz880u/2+sNj8G7L
nwDtln94PtuJ1O3euWYn5h8HxKFoTwXUnsiHA3ZP5DOCsCdyouThb6ey2RN55sgcsnl7qEEGaPFt
Btgr6geyzQjF+nSQKeiRbDPGXtU0kG0GCY9km0nokWwzyt4COpJZ4r78JcPo/Qzz9Mn/rHbhww0K
ZW5kc3RyZWFtDQplbmRvYmoNCjE0NSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0
aCAyMzU+Pg0Kc3RyZWFtDQp4nF2Q3WrDMAyF7/0Uuuwuil2XDQYhUDoGudgPy/YAjq1khsU2inOR
t5/slg4msOGg84kjyXP31AWfQb5TtD1mGH1whEtcySIMOPkgDgqct/mq6m9nk4RkuN+WjHMXxiia
BuQHN5dMG+xOLg54J+QbOSQfJth9nXvW/ZrSD84YMijRtuBw5EEvJr2aGUFWbN857vu87Zn5c3xu
CUFXfbiEsdHhkoxFMmFC0SiuFppnrlZgcP/6+kINo/02VN1HdiulVcvqeP/ISiv9UNmrq0wpy94i
2pWI09WL1FglkA94O1qKqVDl/QKE7nHRDQplbmRzdHJlYW0NCmVuZG9iag0KMTQ2IDAgb2JqDQo8
PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDg5MjQ1L0xlbmd0aDEgMTg5MTkyPj4NCnN0cmVh
bQ0KeJzsewdglEX698y+u5vNlmQ32dRNsptsKklISCihSJY0OiQkCwkQSEioUkNHmgXUIIKKBSue
igWUzdKCWFCx9+7pqXh66p3i2T2BJP/fvM9OCFg+ve++7777LpP89vebZ8o788zM885KZJwxFoEP
LSsvqRw+9OTyb5OZ5sn1jDkuKS0qqbrmqbBMxl5YwZjt7tKiUcXTIqcPYezJfzCmXz+0pLTsk8e+
OcU0j21lTPliaPnYytmNAy9g7Fgy4zeah1Z6ix5/78MOplmdy9jQKWMrc/J+/Oitdsb4W3hqXcO8
+oWvhL34MWPpjRjAsIZlS1y+G46+wlgNynVxMxbOnPf996PNjGXtZiw4dmb94oUsjrnx/E/R3jpz
7soZNx44kMLYlG8Z62OdNb2+8eOU9nPQ/2SU950Fg+XeoN7Ib0M+eda8JSue2mD/jDFNAWOpPc6d
3jT/Ev/WSxnzj2IsaNrcBQ317kejf2Bsm5axhLJ59SsWJmYn34r2rWjvml8/b3rqsgo865CPsZDI
hQsWL+lwsI0Yz1OifGHT9IXn7tFgfn2QT7Yy4Vvdza0b/D3GTw0d9B2LMTCRDn+2+jnBjyddt+rk
ibZNwZ8HHUA2mGkYJbTTs3bGjxp3nDxxYkfw52pPXZLyjbCEJrE6plMNGmZlOWw6VmkrnqtW0Wby
rSg16Lbr8tFlArHyEtuoYQamCdVpNBqtotF+wDQdHra7Qx0B0uhKl4t5MJ1UGkPQzZpUF+O3qJ0e
1IWImaL3kNOj4S9i9W4V6/L7k7aE1f+s/XO2+5/p7xefc+p0fxrtv7ZvkfRv/nKfulGs4ff0pU2i
vnTTWIO2+sx+lXvZ0J9ro3zMQn/PM854XjNL+ll7Gsv9Z/vsTv8dSXmdTf69bbS92XZlGpv4G+vW
nfG8k6z2t7TTLGIpv3dc/zeTcpT1+S31hK+k5m+wDf/08247o5/tP1dH38i2d33eT8ZS8NvWrLN+
l740z5zZr5LIKn5LH5r7WOLveeb/TsJ4t/3WuspNLEnX+tM1VJazDOWWn4+n3ak7dafu1J3+e5Lm
Bm783W2S2WGNjl2r28iu+VeNQ4k6+ztk4FmLWemvtjvV8eMZ9eexDcCqf9W4znwWO0flPmzT/4n+
/5sTvq8POyufC0z/d42nO3Wn7tSdulN36k7dqTt1p+7UnbpTd+pO3ak7dafu1J260/8XSQkgjv4V
gg9CDkpJZ1rugiGXuZiWWaEsLIllIN+HDWBDWAkbzkazKjaeVbOpbDZbyFaytWwHu9dldaV2dKh9
W9A2nWWz3mqLYjYMLcYGWtSzc1nTGS14x3d47njgASW+4zHRQccP+IhniYojMNiojgbN4x9O+zA/
8G8mWUDPwEx6qn8TlRvI9cYIx5w5U2WEcq3SpFQrc5XPWRiLRuscNpJNYDVsIpvCGrmGh3Irj+UJ
PJ2X84m8ls/lC/hSvoyv4Zfyy/hWfj3fz4/wR/gT/Emm55+r/X71k3+/4UwT+ItBDfv1xE+PrMtA
1yrrAkqOlnJfKl911plwRj9aQMyIBbySE1AlQJcZIrcYWHmGW1ZhGD+ZOWxd5o7c2bOXra/+X8zw
35KUGnVP/+tS91n41bPgGdo4dUrt5EkTa6q9VZXjKsrHjhk9auSI4cOGlpWWFBcN8RQOPmfQwAH9
C/r17ZPTMzsrPTUl2Z3kjLbbrKEWkzHYEKTXaRUNZ1ml7rI6ly+1zqdNdQ8bli3y7noY6rsY6nwu
mMrOrONz1anVXGfW9KDmjLNqeqimp7Mmt7oGsUHZWa5St8v3fInb1conVlRDby5x17h8x1U9WtXa
VDVjQSYxES1cpdGzSlw+Xucq9ZUtm9VcWleC/lpMxmJ38XRjdhZrMZogTVC+dPfCFp4+mKtCk146
oEXDDBbxWJ+SUlrf6CuvqC4tcSQm1qg2Vqz25dMX+4LUvlyzxZjZJldL1pHmy1qtbFpdprnR3Vg/
udqn1KNRs1La3Hyxz5bpy3CX+DJWfRSNKU/3ZblLSn2ZbnQ2clznA7hPl2J1u5q/Yxi8+/jnZ1rq
AxZ9ivU7JqSYYqebUC41w9gwQswvMVGMZVOrh01Dxre+opryLjbN4WeenMwan6ZOlByRJRFeUbJe
lnQ2r3MniqUqrQv8LpsV7Vs/zZWdBe+rvyn4RbnLp6TWTWuYJbh+erO7pIT8VlXt85RAeOoDcy1t
yc1B/fo6TGK2cENFtS/HvdBndxdRBRhcYg1mV1arTQLNfPZiH6trCLTy5ZSWiHG5SpvrSmiAoi93
RfUhlt9xrKW3y7E3H2etRozDF1mMRUktba5unOFz1jkasT9nuKodiT5PDdxX466eXiNWyW31ZRzD
4xLVJ6qtMLezasvKYuZBKQZXtcah1IjVgsFVhg930SAUWLFcalasaNEgVzV3MFkNTwnUEOqMfpBR
UoqHiSJFNC0e5kisSaT0K0NyBMakS/EZuvRlhaFzTPScXxwa1RYDynCVTi/pMsAzOtUFBhjo7efH
qRG+CDwYLQxiOYfJIiUFJxc2DbpRTWIVo10+Vu6qdk9317ixhzzl1WJuwtfq+o6sdI+smFitrnZg
l1SdkaPyAsr5WCKKZUZTjD1YlumQy6rmh6r5zuyws4qHy2JXs8E9srJZdO4OdMhcOEGYtD51eP2m
grDeOJpliG7usno3XhhlzfWtHeunNbd4PM0LS+tmDRB9uIc3Nrsrqwc51LGOq17jWCUeFcZG8pFV
RdlZiD1FLW5+SUWLh19SObH6EF5rrkuqqv0arimuK6ppSUZZ9SG89jyqVSOswigyLpERPY1DxqDW
dxzyMLZeLdWqBjXf0MqZajNIG2cNrRqyWaVNA5uWbB7VJhIWKXoWXIxwW+pqFMuzumZWc12NOFws
EkuJX+7j7sHMp3EPbuEavdlndE8v8pncRcJeKOyFZNcLexA2Bo/kcI6ISc11bsQpbKhq5uC0FRXR
pau1o6OqOvF5x/GaRGy1ycDEal9wJmK/LmUE6g0VqIN5qG99Q70YB/NWi7ZBKcMbarBtZYeoMtwX
jB6CAz2gRpnaRmxHNGrA2mAB1fbrkfGtr/HVZIqHVs+uUbez1ceGuQdg2alPXap4UE5Nc5g7Tz2b
OArGlIsFBWNsrLKaLA5k8bAaclKQGSNvcKOooc4Fb2tZQyW2OsVSo4Ms0xEStanTVRgdgUImpqWk
mCxGX3BPdIhfoU09xZHUpQTV1NDg1dzFgQp4ttVnwohSu7gy0ADeQdFwMRb8XoyhiqqPiG4qWtk4
9wpEFjFotacgFPssKcPrEfypvQkWd4FsbBAxwhTo4yhZg8TMzfC7klLV2nGne2Vil5Sd5RYvB7Ex
meMQNjaraT7b4JuUmZ1lONtqUc3NzQbLzzcgfxksnSyMrlK8NRjzByuuVs1F+4Kj+QiIC6W4QIrz
pVgvxTop1kqxRorVUpwnxSopVkqxQorlUiyTYqkUS6RYLMUiKRZKsUCK+VLMk2KuFOdKMUeK2VLM
kmKmFDOkmC5FoxQNUkyTol6KOimmSjFFilopJksxSYqJUtRIUS3FBCnGS+GVokqKSinGSVEhRbkU
Y6UYI8VoKUZJMVKKEVIMl2KYFEOlKJOiVIoSKYqlKJJiiBQeKQqlGCzFOVIMkmKgFAOk6C9FgRT9
pOgrRR8pekuRL0WeFL2kyJUiR4qeUmRLkSVFphQ9pMiQIl2KNClSpUiRIlkKtxRJUiRK4ZLCKUWC
FPFSxEnhkCJWihgpoqWIkiJSiggp7FKESxEmhU0KqxShUoRIYZHCLIVJCqMUwVIYpAiSQi+FTgqt
FIoUGim4FCwgeIcU7VK0SXFKipNSnJDiRyn+IcUPUnwvxXdSfCvFN1J8LcVXUnwpxd+l+EKK41J8
LsVnUvxNir9K8akUn0jxsRR/keIjKT6U4s9SfCDFMSnel+I9Kd6V4k9SvCPF21L8UYq3pHhTijek
eF2K16R4VYpXpHhZipekeFGKF6R4XornpHhWimekeFqKp6R4UoonpHhciqNSPCbFo1I8IsURKR6W
4iEpHpTiASkOS3G/FIekaJXioBQHpNgvxT4p9krhl6JFCp8Ue6S4T4p7pdgtxS4p7pHibinukuJO
KXZKcYcUt0txmxR/kOJWKXZIcYsUN0txkxQ3SnGDFNdLsV2K66S4VoprpLhaim1SXCXFlVJcIcVW
KbZIcbkUm6W4TIpNUjRLcakUl0hxsRQbpdgghbz2cHnt4fLaw+W1h8trD5fXHi6vPVxee7i89nB5
7eHy2sPltYfLaw+X1x4urz1cXnu4vPZwee3hTVLI+w+X9x8u7z9c3n+4vP9wef/h8v7D5f2Hy/sP
l/cfLu8/XN5/uLz/cHn/4fL+w+X9h8v7D5f3Hy7vP1zef7i8/3B5/+Hy/sPl/YfL+w+X9x8u7z9c
3n+4vP9wef/h8v7D5f2Hy2sPl9ceLq89XN52uLztcHnb4fK2w+Vth8vbDpe3HS5vO1zednjxXiFw
a/YnDHbizuxPiABdQLnz/QkDQOspt45orT/BDFpDudVE5xGtIlrpjx8CWuGPLwYtJ1pGtJTKllBu
MVETGRf544tAC4kWEM2nKvOI5hKd648rBc0hmk00i2gm0Qx/XAloOuUaiRqIphHVE9URTSWaQu1q
KTeZaBLRRKIaomqiCUTjibxEVUSVROOIKojKicYSjSEaTTSKaCTRCL9jOGg40TC/YwRoKFGZ3zES
VOp3jAKVEBUTFVHZEGrnISqkdoOJziEaRDUHEg2g5v2JCoj6EfUl6kOd9SbKp17yiHoR5VJnOUQ9
qV02URZRJlEPogyidKI06jqVKIX6TCZyEyVR14lELmrnJEogiieKI3IQxfpjx4BiiKL9sWNBUUSR
ZIwgspMxnCiMyEZlVqJQMoYQWYjMVGYiMhIFU5mBKIhI748pB+n8MRUgLZFCRg3lOBFTiXcQtatV
eBvlThGdJDpBZT9S7h9EPxB9T/SdP7oK9K0/uhL0DeW+JvqK6Esq+zvlviA6TvQ5lX1G9Dcy/pXo
U6JPiD6mKn+h3EeU+5Byfyb6gOgYlb1P9B4Z3yX6E9E7RG9TlT9S7i2iN/1RE0Bv+KPGg14neo2M
rxK9QvQy0UtU5UWiF8j4PNFzRM8SPUNVniZ6ioxPEj1B9DjRUaLHqOajlHuE6AjRw1T2ENGDZHyA
6DDR/USHiFqp5kHKHSDaT7SPaK8/shDk90dOArUQ+Yj2EN1HdC/RbqJdRPf4IxGv+d3Uy11Ed1LZ
TqI7iG4nuo3oD0S3Eu0guoU6u5l6uYnoRiq7geh6ou1E11GDayl3DdHVRNuo7Crq5UqiK6hsK9EW
osuJNhNdRjU3Ua6Z6FKiS4guJtroj6gHbfBHTANdRHShP2IG6AKi8/0RXtB6fwSCMV/nj+gLWku0
hpqvpnbnEa3yRzSCVlLzFUTLiZYRLSVaQrSYum6i5ouIFvojGkALqLP5VHMe0Vyic4nmEM2mdrOI
ZtLIZlDz6USNVLOBaBpRPVEd0VSiKTTpWhrZZKJJNOmJ1HUNPaiaaAINdzw9yEu9VBFVEo0jqvDb
PaByv108YazfLrb3GL/9QtBovz0bNIqqjCQa4bfjXsCHU24Y0VAylvnta0GlfvvFoBK/fR2o2G9f
Dyryh5WBhhB5iAqJBvvD8H7n51BukN9WAxpINMBvE1ujP1GB3zYU1M9vqwb19dsmgvpQWW+ifL8t
C5RHNXv5bWJiuX6bOJs5RD2peTY9IYsokzrrQZRBnaUTpRGlEqX4bcJLyURu6jOJ+kykzlzUi5Mo
gdrFE8UROYhiiWL81lpQtN86BRTlt04FRRJFENmJwonCqIGNGljJGEoUQmQhMlNNE9U0kjGYyEAU
RKSnmjqqqSWjQqQh4kTM0xE6zSnQHtrgbAttdJ6CPgmcAH6E7R+w/QB8D3wHfAv7N8DXKPsK+S+B
vwNfAMdh/xz4DGV/Q/6vwKfAJ8DHITOdfwmZ5fwI+BD4M/ABbMfA7wPvAe8i/yfwO8DbwB+Btyzn
Ot+09HK+AX7dMtf5miXV+SrwCvTLlkznS8CLwAsofx625yzznM9CPwP9NPRTljnOJy2znU9YZjkf
t8x0HkXbx9Dfo8AjgKfjCD4fBh4CHjQvcj5gbnIeNi923m9e4jwEtAIHYT8A7EfZPpTthc0PtAA+
YI9ppfM+0yrnvabVzt2mNc5dprXOe4C7gbuAO4GdwB2mbOft4NuAP6DNreAdpnOdt0DfDH0TcCP0
DejrevS1HX1dB9u1wDXA1cA24CrgSrS7Av1tNY5xbjGOdV5unOncbLzDeZnxTucGJcV5kVLgvJAX
OC/wrveev2u9d513jXftrjVe0xpuWuNYM3LNeWt2rXlnjSdMb1ztXeU9b9cq70rvcu+KXcu992s2
shmaDZ5B3mW7lnq1S+1LlyxVvl3Kdy3lJUt57lKuYUutS11LFfMSb5N38a4mL2sqb1rf5GvSDvQ1
HWvSsCZubO04srfJkVAG9qxusljLFnkXeBfuWuCdP2Oedw4GOLtgpnfWrpneGQWN3um7Gr0NBdO8
9QV13qkFtd4pu2q9kwsmeiftmuitKaj2TkD98QVVXu+uKm9lQYV33K4K79iCMd4xsI8uGOkdtWuk
d0TBMO/wXcO8QwvKvKWYPIuzxrniFKsYwJg4jIQ5eFGuw+M45vjSoWUOn+OIQwkLjXXGajJCY3jx
2Bi+IGZdzJYYJTT6xWiNJzojqyw06sWo96P+HqUN90Rl9CxjkdZIV6QSIeYWObqqTOXCEuJefdS5
jo50p5aFRvDQCGeEptQZwZntmO1LmxLxsPVFqyY0lIeGdoRqPKGoHhriDNGIj44QxRPSq19ZqMVp
0YiPDosS6bHAInpMM5dXlYWanCaNt9A01qTxmAqLyzym7NwypnAX54xbQYpBjIJHOMtwrvdGch3H
+7ylqjIzc2SrgY0b6TOUT/LxS3wpleLTUzHRp7/Ex7wTJ1W3cH55TQvXFFf57OJfbNX8hs2bWVH8
SF98ZbVvR3zNSN96CI8QHRAsviWSFdVkTlm8dHFm5pIp+JiyeEmm+oscXypymcIofhcvQV78LFXz
LPNXE1UDTV2MtEQal/x6q//XE/93D+A/P7Uw8UcGQzo0F7FGzYXABcD5wHpgHbAWWAOsBs4DVgEr
gRXAcmAZsBRYAiwGFgELgQXAfGAeMBc4F5gDzAZmATOBGcB0oBFoAKYB9UAdMBWYAtQCk4FJwESg
BqgGJgDjAS9QBVQC44AKoBwYC4wBRgOjgJHACGA4MAwYCpQBpUAJUAwUAUMAD1AIDAbOAQYBA4EB
QH+gAOgH9AX6AL2BfCAP6AXkAjlATyAbyAIygR5ABpAOpAGpQAqQDLiBJCARcAFOIAGIB+IABxAL
xADRQBQQCUQAdiAcCANsgBUIBUIAC2AGTIARCAYMQBCgB3SAdkgHPhVAA3CAsUYOG28H2oBTwEng
BPAj8A/gB+B74DvgW+Ab4GvgK+BL4O/AF8Bx4HPgM+BvwF+BT4FPgI+BvwAfAR8CfwY+AI4B7wPv
Ae8CfwLeAd4G/gi8BbwJvAG8DrwGvAq8ArwMvAS8CLwAPA88BzwLPAM8DTwFPAk8ATwOHAUeAx4F
HgGOAA8DDwEPAg8Ah4H7gUNAK3AQOADsB/YBewE/0AL4gD3AfcC9wG5gF3APcDdwF3AnsBO4A7gd
uA34A3ArsAO4BbgZuAm4EbgBuB7YDlwHXAtcA1wNbAOuAq4ErgC2AluAy4HNwGXAJqAZuBS4BLgY
2AhsYI1D1nOcf47zz3H+Oc4/x/nnOP8c55/j/HOcf47zz3H+Oc4/x/nnOP8c55/j/HOcf47zz5sA
xACOGMARAzhiAEcM4IgBHDGAIwZwxACOGMARAzhiAEcM4IgBHDGAIwZwxACOGMARA7j4m1PEAI4Y
wBEDOGIARwzgiAEcMYAjBnDEAI4YwBEDOGIAx/nnOP8c55/j7HOcfY6zz3H2Oc4+x9nnOPscZ5/j
7HOc/X93HP4PTzX/7gH8h6foqVMYC7qZsfarzvh77HI2hy1m6/GzkW1mV7GH2TtsGrsQajvbwXay
u5mPPcKeZm/+U3+9/gupfaVuHjMrB5mehTPWcaLjePtOoFUX0sVyFXLhWtdpS4e144uzbF+0X9Vh
bW/VhzGj2taieQXWb3hbxwm8X5Hv6CvymouhQ9UWXwXd3L6n/c6zfFDBJrJJbDKrZXWsHvNvZLPY
bHjmXDaXzWPz1dx8lM3E5wzkxF/OI5ao+nStBWwh0MSWsKVsGX4WQi8O5ETZIjW/lC3Hzwq2kq1i
57HVbE3gc7lqWY2SVWp+BbCWrcPKnM8uUJVkslzILmIbsGoXs0vYpb+au7RTNbNN7DKs8+Vsyy/q
zWfktuLnCnYl9sM2djW7hl2HfXEDu/Es67Wq/Xp2M7sFe0aUXQ3LLaoSpQ+wJ9h+dh/bww6ovmyA
18gj0i8zVB+K/39hNWZ4YZcRk/+Wd3prLeYu5tYcmOkK2C/o0mJZwI+i5oWoSb3QOohe1pzlia2Y
A+nTM6Lc1er8T1u7euXXrNIfN3bxzA1qTqizrb+kr2E34QTeik/hVaH+AE3qFlV3td/cWXeHmr+N
3c7uwFrcqSrJZNkJfSe7C2f7HraL7cbPad1VEd/H7lVXzsdamJ/tZfuwkgfYQdaq2n+t7OfsewN2
f6flELufHcYOeYgdQaR5FD/S8iBsDwesR1Ub5R9ljyEvalHuCfYkItQz7Fn2HHuRPY7cC+rnU8i9
xF5hr7I3uQXqZfZXfLaxl3QfsRA2hDHd/fDzjWwKfnSISouVVxBFFBbE+rPRbAyb9ACz4HUfyQbw
/fsjSkoM2UEP4VWuYS5cBgyM82JPqFZjORgbW+g+2Ee/WbENb+XZ+wqDNuOaW9j2XtsLOW3vHQ/r
n3Oc57z7wXsfWL96wdY/J/+D1z7olcttiTYV9hBNUJBd707qqemTlto3Pz9vsKZP71R3UohGtfXu
22+wkp+XoFHs0jJYI/JceeXURGVsm16z1l04Pl+XEBtqt+h1mrjosOxBKdbKSSmDesYHKUF6RWcI
Su9XlDRybmnS20G2+IjI+DCDISw+MiLeFtT2ji7kxNe6kJPF2rkntyn6gZMLk5XrjAaNVq9vTYiO
6TEwcfj40HCr1hRutUUagsJs5vSSyW0bI+JEH3EREdRX22i4xd1xQrtWZ2dJLJXddIgld3y6z2zl
o9ytAZHa2vHlPhOESQojhCdWqBSr+LSon2b105POU0RxlomPTnanpnxrNpmjk+LdRguP1JqZ2WrW
7HE/7H7RrbjNbnNY/Lgwr87LCgsLw/r3z8mprbVF9bdB2vKtx/Ns+fB4Zi29CllmZkpkpF51eZqS
qIQo7qTU1L79OPk5KsitJGqXGrg1xelMCQ/WLmj7eI5iDHfHxaeEcgP3ay0xaQmuHrEh2vP4+/zR
cyIdIVolyBzMB7Y/HWwJ1upCHJFavynEoCiGUNPmtvPE/21X3/Gl1qxLwM6atjeODcyET/Za+Wjw
l3tDVf58r0XlL/aaVf50Lyae+RC+94WwaJ7DElkqz/KHV2oP8x6sD8vlPVuCx2ObvXZcgOd8oE7O
+sbRXrkp9hB9l62ijwhsHbGpIuwJGrHHxFS1Zo3OYPdMPW/42me3jK685uV1BXMmljkMOkVrMBlC
8sYuGjt+c2O/Pg1bJ41eXNE7NMioVw5ao8NC7Blpjqrbv7rp1lN7Jke4ejhCwmPD7HHhwWk5aaUb
H1l93oPrhqTmpOptCdgVuxnTbsG5CmNOttwTX5jIw6Mx83Arph1ux5zDwzDh8GjMNvwwvuEyFku+
iQ34RmWLyt8L38QGfBN7GN9Fg+Ebsz+kwtHKU1t0VazweGGnL14j6pVbK06ZOzEptY+td9/8RMw8
qDe84bYJR2i3jL/jy53tX0RlZETxlLs+valif+8F92zc07L6nqb+muvvOnnHOGea9oI054TbPt0+
e/9FI07ZBq9/RKzpbuz3cuz3HNa6r7AXd5sDi2oODNwcGLg5MHBzYODmVo3NExeVbBJ+MAk/mKyo
ZjKijkn4wdSqsXqimCeCj2aecPFhteF7hgflLEr8B0MUCD6Asqge45JbeZYn9IiZv2Tm5jNPQk7t
ouOFPAe+EJ4gf+RZAwzHpMigglDUKQMBJgI2KbXlBntidKzLbmjbCxUTnWQ3GOxJ0TGJdoNmtMHu
io2GijWYg3S6ILNBM7jtUam1b0vVdkKjlzrgP14N/0Ww8oOFUWOj9kQpLOBCFnAhC7iQBVzIAi5k
92PtjR1HDsITRus4dbqYZueCp/xkMrxajjs4IjEqputoT48wMCp9JvbrILbbY60bvHCwxpKbG5WT
Y+wZHR3b+hu3pljhhOReZrNRrLFRrLFRrLFRrLFRrLFRzIB1HPHEiOkk960wRUdZcqJ79dQ70yuc
XrmEhWEIY/mY22ty9RDQOpWt/zk5+fkiunWZsZuLiIbYxt1d1lS8WRDceL4Ic6pH9JkGuzMmKjHc
oGnPV0wR8faIBLtJ0z6UYz1jol3hQVmOWa7c5OhgvlzHN5pinakx80Id4ebTjpt5cluQMUjRIjDg
9bG9076zR7I5Nt1xaoKyM6FHjCk4PD5C/L82Hce1n+oScXdPY6s9sXbhGrtwjV2EAbsIA3bhGnur
Jt8T7GK5uOkqLCHg84SAzxMCoTIhECoTAj5POIxQaWQxPMMfWulu5ZktuvFnhoNauT34Wa9SNRp0
iY3aT0dc9d62K1/fVDJi23vbtry2uXR/2qTrFi68bmpG6sRrmxZdPyVdc81Np1qmTtj5/Y7tJ/ZM
HX/HN3fPf3DTmKrLDs9sOrJpdNWWB0Tk6zihPImdFMcy2IqWZH1gIvrARPSBzaMPbB59YCJ6sXmi
bPHCPfHCPfFWs4WPinehLF78cRGzpbRy41693oxpmvZGVJjFVglcNCjonT7i6lzP3AgIgNouAVB5
0rP83hVXBYcnxohj0SOWR/QYPXveqIz9AyfUZt1yw5iZZcnKVfU3zh/U3rNzhe9JTwqKKpy8csLY
Ob1D2n5MH9rA1BUeorsYK5zGBrLLPfHGxLB0MYt0MYt0scjpYpHTxSKnYyYeI3PF5catj1Pi8gLO
yQs4Jy+wynmBVc4LOCdP/B8AYYlGS3Yrz9gXVZmi7SeW2iKW+rXnhRP6n17voyRg65WrC3ggTd/1
1agRr8agBB0/awdgFkaz3l6z5KLBva5pkDth06tbhoVnDO4xfP6wdLuhfffZm6IpymnTJxZOHJSQ
NX7nDzuu/1HsjK9vqth20cLsQcVJoeFuzbH5D2waU7n5/llND1+GbfIgo32iNWGf9GUl7ApPgrWn
rZ8BU+0nvNZPXft+wov9hNv6Yf4HMzzIZhTahK+gbAGf2QIbyhbYULaAz2ziT7XielpbueHAQg/3
eKLOwb7Zn1gRFQgyYuvUHu90XJ6MNarjZGBJU3oqP9lIkVEJCrlQiQqPjOS9U9NSU+WL1aS3JyfE
JtpN2uUR2YOrBi6WWwwv2vBeQ2JHLh6T5i6a3N/VOzvdviTE0N5WUh5TmH/FXSUNRU4EGYNWG2w1
8169JxS62/7YufXuS3PqFEvB+AXFQ2aOHWAPyRw0plf7h8nxyoZRs6OC9O2jEgeWI44P7TiuNGAv
DmefHGJDcAUNxaVySMBFQwKuU9mssuqqIa2aLE9mnifczkfleWy4eeYl55kd0aKtQwRwh9UqPtDE
IZbDcb+ml4jiex3qu+nI3pgA24kPhIoXt7nnYZ7G+jEjT/WYbK5+vJ/HZOajbOLfCY1C9bP1s0UO
auXm/UMcuozKSOztQPTCEhy3iQttZmat9bhVHPDTb/IwKjgrrGnl3qavEj31v3AN1CsNxctvrR2y
YMLAKJMW7g7JL180oqC2ODlv3Oz5s8blD5x9RVXmhNGDwvVajaI3BZlySmoH9C3vHZtXOWf+nMp8
fu6kyxvyIl1J0SlOfKcISkp3J/Qrz+83ZmCv/MFVi8ZWrBufHRrjDDfZosPDcDuMc8fH5xal9B0z
KC//nMpFWKNQRMg3sfOT2PSD0R64N9omvLZPvPF/c7gUL1Jbx5H9Yufrw1p5+t74QETMw5XgK9U5
j2daj0oPdbnpJMpIIO6EypvaYIuhfZu8J0BZDDodPpSLDLjXa4+Gx9kMJ2/u3IjTDLa48HD6AiRu
Dkk4x7Nwn0lm8z3xyeIIpyfzWMGpsTw9iqdaeFYMz4rmMa2B7agKccCjpUUIT5gwxUTHRKemOMdF
68LofhPWv9AWxmnJxXKz2lpeW1uLrzUp6gtfm8bxNaZvl9d8Hr7mBGkOakNi0uIjE6Nt5iClvcbA
w9KT4hLDgrV8MeezFQMOqTPZohgSxFcWrtXh6q/1q19qDBbjyYe1hcIuvtSIOeZixb5X77y5nviM
HJ7Rk6dG89QonhbJ0xnPGOc22eLH2U5/FSuE12vVdPpLF+ed37m6DLlzxFz5yKILy0hyJUeYtO3H
2t/VmSOSExJTQ3UWXt++xxxkxUZLjTTqeSS364zhSfHONJvW3O4bHBkbqlMMpmCN0tb2P+x9eXhb
xbn3zDnaF+tIsmTLsuUjb/IqObbjxE5iK8Rx4jghC2RxwAbFlhMVb0hygiGBsjcl/Zq2LCXlu5fL
bUvpQ1vSEhKgLUmh8YV+gdBCWApcurKUtNByCVyIz/ebOUeOstBy73P/+Z7Pnug9c+bMmXl/77zz
zsw7E8kMtHpHgVe4QGj3+h1YoqFxC+nvTXYjR3Py58z2Xgwr0S4+RRpJlDwQlR3nFZ8XOU+0mvOa
bNCxJtblm1hHb5JY6zQdoCeiOSQUchBqI8w+k1bNgrQydbRrV6t65S3aekAwRXOdeT8nTVKTMO9g
EyVNtKkpvLD6APVHHUdLaEmJrujt8LIFr9hW6EiETVm4PXby6Xtfb2YC80RNX29LRB3ZG2CY+zDn
YwKtqJg9O2tQa5ytjWVaio4Pc0a103sbG5rniO1Sob+gOGfeV1YvSa2ua0t/J7HdO+v8lgWxrlk2
k82sM/rPWzfYFPvChRXf/FLHwHnFPasWji7It9kw47BtbO8s7xxcuHxsWXln06rZ/qLSIpPkc/iK
CkqL3LVrr77wiby69qrOC87rgHTvhHSf119OqskCcuM+TNEtwWat+zZr3blZkxe75/JqPkA/jPo9
NWymUCOzNTGTfw0bAWskvlQWLFEz8ViaZwd1+voDVP9QxTJ/p7S8BdG9+hXMarIhLa8lMxmqOSWz
3szUL+Q5e7mjrv8zk0Gj0+vl06PnG/t399Z0dXaGTC6/J7fQZTC65Xyf7DJVdi9dWrnplvWV3/c0
rYvKbdHFoY7ti9o2zPHRN8YfvaHTWdFaNQJzodPBXOjn8hEN5OQfquaWSudf/8D44usGFriqz2uY
uvOC9fP7r0L/2giJyeKTWODv3FvIRxJ1NfS6tgp680G2XAhptjGk2caQNksKacLE9W32QuiAYI3a
Izk0x/dGcdRiX1qMtaLwoHuZ+KdZzM6a7Utn1R6ghr3mFcyTUHOcExrRZspPqFPIs90JBnUYMWQ7
E0RZ0Bt987s3RGK3x2cvvPzOnprVHbPzzQbBZXeE5q9t3XZNMNo7v2Vde42NLRrucfqcdl95kSt6
1Y/Gb3zsynlSQUl+jjvfFSoOVgb3f3/99RtqympKTe4i1k8vhVzu0g+TCtJCbokWt8+jVn8L650t
bEXVwkblFqYdLUxZWh6l7BcqIqrUIpqwIpqwIlqPjWjCijCFsriDndaWkF+XU80O4eUvQ1fX/Shn
hX45G0i4OrWf4Vfg+jS97MrugpgWTWuVWFGRPbGcI95ldBbmMvfZkjsv6t+1vrJh01cuWXl91Jhb
zHTK/O1FOzraoUHQqIXBBdHOkC+jQNtWrFtx/d5N6UdvWLJ4kWA12tkwZDeeXAzd2bQ92nFdHLq0
aBaTVi+kdSesWg1pIt+PVkea25tHm0U3601umfld3MFaNoepZdKqZWKs5fYNuvDRvo6ab9YIzDG1
j/W2Jp2mfDpNx/i9lV9VA6dj8gsGayc/r9utEw7q6FEd1ekKI69ULMt/+9KcsRwhx/x2IVewXs22
XZ7MGLWGV2tUZUOy5qoxlAaz1MpzuvIJnlAzF6hRvDPkO/nDQOfY6uhAV8RmtBpEQTRam9ddHh29
N9k6//K7+z9326V13xYnti24uK1EEIRQsPuKdWFPgceY43PZ3Q6b1ZfvbrvywJXph69d3JH6xgb3
dbeGl8fnsHGuXPlP4Sb9FWQ+GfihV2IdkHc8v2a1/Blr5dfMmV9TJj/77wb11eUHlKNRF/PalFuO
Ny8pqDhev1ReLi3ls+0GtiateaLxPbWPNT5xakXKVcWj4jZkz7Zh5jPWnctBJ9yEkdpg9ASq/OVN
cs6TGPX0LseTJpgmLN1N10gSMzXXlC4dXlZ6XpkNI7jDnZejN1vN+Y2rWzcZnQXuMvmTP7HBnjn7
RI9c5i5wGnv7bl5XZXfY3H727Wyzp74m7hT/jbSR88kl5GjU46pbwnrZEhMgL5ElN12+pLH9gPIh
E0G71r9wff0h9qjduBLRqN3hostX+nWOerHRaGTaI3F5HYzaEalrNPr9xsY6HZNxtIkJeQOrYoMs
4bUN1eVRK67ljnqjOHfZy7YL3vR4Lp0rvjV/abV83ktzl130krySqENmOx8xjx9TTX9N4xEm3DxM
l9iEyYlE6UgN/tVkCJM6ZOz1qkNBBVaGGCDztBVNRufmYHhtauZU7dlY9NCmiunhtE1wY9ETyhG1
O3Gn23FtaWFD7+fPn9Pvd+UtbP7TorE14abLvn358J2baqXgLHlWpKG8uKzp4muXVy0pppLTOTUV
761fEsmLXzRraSTvgktWvyVX5Ztv2Nodb/OL6dLisvWR86+4oLbI6woHSsOCRQgu6JnXNrZ2Vnm0
pynYNrfR51teu+DSivLe81ZceWGd2RSceu/izfLcrsqeweI5S0/2tbYLJl9dVaVn4aKi+jam33di
Hnc3RuYGMvFgexOtdmv6684otltTbLem8W42LOcFVCcld1dyTyU3G1b2zKL6JwPVPiw0DfvrlpV1
+pZz88kXmDSiuefUwbjldCcdH02M53BBqpNDj3i3yaWOufnhrvq27R245S6qzFC8ZHfXxquWB30Z
fRYcK/o6yjasPXlLJiV7/O3uWjC4M8Ys5Y3Kf9LV+gjxkCDZtb+9dGXpaKno1eZyXk0G/N7Nr1x5
vZqmezWheR8VLieFxKNKyqO95dGeejIi9UBMD1mKo3iTHbx/0Cd1cfkcO16jWUNtZDm3B9PNhl2m
jNBC2namANy181pr2GdaBOINRhWwkda3Vle14JNp+e1o+SZyW9TW3kyrZtFZURddgQnBUc7mLM3g
z2KTCBu/coM/61EhhJWaTUPz6d5tKEOBt66OMKCqUnhLrPrKrsJOZ0YhuJsG0wvMZ7kVbHg9g3sa
eIieQx20PRoYRyOlXq+43eQuKfCX5jsMUzecKRF6ocnlK8n3lXjMdsfUI3TEbuVOBSwEzPSvU/az
FeOTX9KtFrtZxDBituVLU49MlTs9msxoG2TmIVHuqR7lnupze6YzrU3YFxNYpE6OWGvfc3umz2pL
39msaVzoj2JUX0XejvpdklXbNamQmAshlM/o2BramdVzp7s001q3prVubXLIe3Qg4GW+1ECD6pnm
PmrunuYd24LRbP8q5gdZ1RbSis2aY757xhyUCyT0KP0QZkWihh92L8N00xC1L1zW1lk3t6tuuS+r
/bNdsy2ax8nZkvHhM/vAjxz/PSPxaVbDoy0pNWXRH1WNh9uUW9sRbkktZoNkXtBt9NYuCrekp22J
wVWY5y2SjMu/3DW3p6NeqlvdvaRs/dau4lNWpbTlDKtydop4A4ZiUTRbTdvWriyILKyc1VHthrlZ
nrG6aMEGcmvUobYgI5oBPrOVNLt7Zmuy5VHAKkkZO8w3kLL2juiH+zVTzAxx1FK3rNpX1pURPRsn
p21xxk+sSfszGGTPPzLI00K8Y8U/MMinCQoCupTZY7b+eQ0SYnsE34kWtlfRShetcjLfSYWNVpho
hZFWi7RKoOfYF3j9nPsCbHoaiFioJWvDQT59w+ERwcK8ePsdZMUYmsnH/q+NY1kp1kragpKtiTSR
Raa3EXozf/9oP0F8rTX1veTot0aaW1L3p3Cd831/2+dWdiU6gv72z61c+rkOmf5h5OGbus+7+sEk
rstw3d513aaWpkuuW7HsulhLU991bDU9dav4PGTDVtOfZ6vpYLNF0xKLpiWWjPWxaOgtfNj2qAtp
vqTmvkx1TX3OlXSXtPJTV9LnWkifQ0c+fSH91b7KjoXRsixlyfX4Xcaq5StW1236IltIN/KFdGeo
48pFbT1zCuhbW398/RKppKl0qi1jC3VvQWdE5ueZqG6r8iy/4Qfji68dmO+uWjRras8FG+YPbNes
pXAv9+z0Pzg2m1Y4NBE5NMk4MqJyaDJ0MFG5tA1XmDzCZEYKIMHyqLlmWYXDI3d5lhPNePHhq2Z6
LpM9gT9Xt+EiMQj3CgazyZRXVObx1c9uLT2z05QvbG0psgfLimw6kYqbvAGn2Ww25YaXzzn5wNnd
5vrmjpBDNFks5hw/Q7xaOS48DcRd5OmoLdLd3r2y+5ruH3Trs5zeH2jObt5jFjL3gvsMZzh3gtNX
osWq55v7vJlx0RzfbInDepD/EfoB3760sEHeFuUDP24rUF677Qc2wRZ+dY7lT85VzkudY05RdXD/
mnm3l3nfVFVr2rWtObZ72S51lmP71Fzov+rYFp5u7Lvu/Pr1i+u9Fh1zXNe0r5tb3dHgD0VXrV0d
DVWtuWpN2dLWKo9RxFhvMZhLmrsi1dEqT2V0zdoLoiGas3gI7Z3nyy0rdhdIRr/sd5U2l1c0VRaX
1LStmz871lVrc3kkm8MrOX2S0evzukvrC0OzK+WS6vkXsrYIKn8RhnXfI63k4geriLO0TpN5ndYW
dVpb1GlWrE7TyjqmhLY8e93x0qVF9uN5S2cdoLq9RtUIHWFq16h5H448obpmdOdeIJ6+jPRmltPC
sEmSq8J5nQPRoqsdLubd3pGZdrzBfH8uxxtzluSVFeaa9Ga97qKiEinHbCjvTp0v5KgrxGNG5NKZ
bYjwNeSUpfcSs8Wsz8lnuG9lfhrxxxjhvhotxrhmDTENCjENCjFPeIjPK0ISn0DQjx5Se1qxJpVi
TSq4fsj7JoswsRRnOmuxpqOYQH8UNbvrukJWva8L0wz9KWcN65+ZmcW0Sp3TWXNqYsktdfOcU26b
u4yuIk9ekdOw4nY+kBlz1YV1XmRpfdtVi425xei5LvP0+LZt7fnzN+/cJJRkeufJ91desqh8w1ph
PJOi7RGIV0E+teR3D5NSBbaZTduKTYyWF9OAGglQr4bTo11zT03m+NU1vbenvBudwzYGMUY6aUii
lXpaUomEBSW0rIQGWbQ9SMuCVOapMi2TachBtwZpkDkpzE7P0qCMXhtkOw9mqGKQeYjYHWuJICvf
hheDlV1Ba0GXVTWA/ExJDTtL1cvHwRr1H/f0q3Jn+xI1/HTb9HGEUwNknjtvjls71nYVFURh6ojO
XlAZCFT6cnRTT+v01OQuzisqdZt1UzrxY8HiDvrzAk6j+M86s8Vm/OQ+tiWhM+VYxPU2l1nEEkcA
MZ8ssNmEP5ptJlEwWZm0Z2PGfAOkvZi89jBZAvO0ANDmMudF1Vw6h13Lw7QiSCtkWlFMKwK0ooiG
CmmljlaJtHUenddK59XR+ex7mj10haQt/9g1aoG6SjJKkBxaMrtGbWwgYcmOhV08HxNmu7RSGpWu
kXRS1OVdKjV2lXe17q6ltexZLbOaktu7dHPttlphMVLzlpuZkJ9nkux9or39CCSpyvvUxo+69aP+
qYI2TMtZDBnFjMgzbovTRJ4V1d+g00+dEO15lYHiap9N/Ikg/EC0F1QFikO4m/pIr8NcOa+wxGUS
XxKEScHsgtoXu0zCCwI9JpjdwYL8ItYsxlzHqUYRvmQ2n0ydaiJHrtFsRQth3XWywGxGC9lheNmB
oPzMnWCysPaqQu/oRntFyE0Pk1kQjJP5Z5ndCDOLMS9M86GPD7H9mHyap9kGbybJS81MW6vZKoy9
M5/QuaW02UqtMpsss1axWmfVV3WxPaou5/SEWN1Xi0zvqTHlVfW3ptybmzkoKJ5jz8rtPrVntcjk
DhUHSj1W3Ysv6KyeksKicic10/ypEybqDslFpbkW3ZGjOouz2F9U7hLMUx/V5rhteqw1jTQ+9Q1c
RL3NnUP303tz3HadaLAYp/bSlQZ2vsaa65jqY9YDM8DtkE8ZWfMw8QPrbNbz/bTKT/P5UjCfVuQ0
5wghMy1gQ3JrAfXNZYLz0eIun8XdZenWrSTd2hKsHV23Ru20rPMGRRXqHHdFBTSnaXor0c0dX95c
o9B4hWFWQ4HsFAzbzZI49ZhJKgsESnLNekrFDw3OErmwzGmY2ic59bbcHNqic1nEiz35OXrR5LCf
DAvH3FY9xgkXEahF+YC+ou/DirqK5OzTl/tXSJ1g69Wns07niBXTno8zjr7+xMiOnha6jE5q8pQW
+ks9phyzr7K4uAoalV9VXFzpM9PxzHxRfMTmsukNNqft45Zgjd9q9dcEg3U+q9VXh1n1o8oJ+iXx
Nr7i8O8luQeEq/ZbAqVYLzmWkvYj7UfYkNtw9qEh55lMfYlxIFcyDiplxsGZ96Is17Laa+WSOnat
O1kZVBPADkxXQR3rA3eAnxHyOrGSvL1sE/zgQ2yz2yxCWcFKzSE26Gc5gkYibfPD7DO8JBJejA/z
296unNC9S15jZZBSUv0YyRe2kwCxCVcRF1ZZ2/cbgh6z38HKbGw80tCA0ZKF04vWf0qcJiLzW8Ps
Qx8Ps9g82MgnMmlDnZFwxzk+QEan3hAt+p+izU17JT2JRGbV56mGKnP21vgdnT23yOMLunQGoVdn
dwc8mJjo9O/ZHSad0e62G66yO8wwHbl2lLeYPiiEhQXEQXIeJEbrcR1hB6A0v25QZZdt7Athl3Oq
z4U/eo/JDmX9KBQorqgIGJwFhCofTX1NR5R8YieOfcRoeUvH/MlnF+PVEcn5yQKny+UUH5ecU8dK
5UBpSYkMPm6cupf+TX8LJF0S9YjMUIlsiizyozuip9h6I2mPQIvUQxoGzMlcedN74WGRe5lV/PQv
l/RecpGe5hT5XAVum9i8Zm5hccuaRmqWCr15hZKg3/TkVM+xF6Y2/sLmtOoFg0k/+OyLr15++Ssv
/XKzzmCA0ZCYDl0Jjt4AR0HS+DBxqTMIlzYDZdd9jDMXP6Bi5WsclcOahulzJMaMtWt2zW4SQlpP
zPO66BuFc1c3izZ3gaugyE71F/f19ekEqTDPU+g0CZvHBd/lr7747KDeZBD0VqftKXrvC8fovU+a
JQu4M+iOTK0EfwuEj8XHdcNkDqmGsYe6E+KmI1FbYUND8K851e/rvV7oR2NEOv7c8QYwph6Z57pi
UCf56vwtswBQFwTcXhnFnwl1nRfX13c2V5WXlFX7SyIBe4mc63PoKzoumRtZ0lxdFiyrLgxGAjmY
9xRIBqqzdwwuLvWU1oYri11F9W2lLqvOaDP6FyeWlHlKalhqQSRaIVnZHAMW4xZxUNijH8/YLn/F
EmkJbNeRbCMhZlwBZ6R4PcL1BinP5cp3GPIsucG8/GCumU7dfFpafYV4U8Z40WcysalZp6dJEnhZ
ivn2JD9TWUPejvrOcJaUZ5wldWyWUe4QVlxaR7PcIMz3l8vm5rnscGFuPos9KsAMEVldlsia0sia
z1DWJui4vsnsEuaS7Nt1o2YLO64ZJSI/0W9mu6yWlRaB8BkmP/yKugk/78QiFmKpq/WzL0RxXMDO
MmaOap4634IRSfpNb7aPqoaPVp/ucdFleVx04mRk+IFrr7x3sKZ+6IHPX4XrAzn+mvkr6td+boE3
sDC+dO7aBbDMwhdv+2BvbP19J+6+9QS/3h/bs3XtHN+qXT8e+sovPt9atqgveSOkzE69/EqfS6pJ
mHwcbWWTxjoaqqVlIVpWQcsLaYWflhbQMh8tz6flebTCSys8tCKXVki0wkHL9LRMR2v8tJ5JwMWa
oZ7WefMR8cqStq+g7ie8vp/tNxSGw5g8fhItQg6JNZfEmktiSymJNZfEjIzEzr+HiE557kfIpoOo
M9uzUQvbn9XVR0L+8AFqjVp0NUFJsgTXWNRzRBFXS+PxhgZt1lOjrSjZgeIjNeqWf28NyZphZjm6
TtuUzByfyphvj5MND6U0KP4q1/XVzCnik2/bJDtslcVIf6l3B2oDwVkB6atOz9S/CFMX0XvpWLBi
6t3MMopKBimQ7w748uyii43dWKGaPzlcKrx1spVZtjj0/XZ9Dmkjh6L20BwaauZOQZFG+Wk7SDZK
52hr6jn8v5mw45PsiFglRF/JDqOybYnKnJUNow3XNIgN5z5m+4jQSAhK0bR2H9/JwNrr4H6+N+bO
b2Zn7m21re/L7PyOvnZ1PgQ9fWYv0ntcOs6c2VQ6pjmJnuh97jkeVYXLpKspseEMtwbzvJZm/V8F
ZuyC2kaYeHvn5/cOzR+6sNlh0GPNYzVaqpckli4aWx0Ord6+bsGGisL84iJhgclh0ee6popKu+pH
vz3aQu/ecs9oq9OXn2NzFricfqfJV1Qgd2xe1nZJe7GtoFxwBGWzq9BdVjl1m16YHfsiLMC/qIFG
/k64/1QQfJ8xPMyCqPvMYW920FV9SrhHd49+gf5NNRgeORWMwb8bvpYVPp4JpwfTdz8tmBeZnzk7
WAbVYDWeI3zxfzbYtp0jfMyCPf33Qo76t/pUcDQ4Hs8O0upPCW+y4IypwRU6R/jX/05wN54zvJ37
s0zwrPHsnwkz4f/78MmnBW+Hd9C79zOFl7LCJ6eHvCItDOY99NlDvgfhov9Xgi9HC78q+MJMmAkz
YSbMhJkwE2bCTJgJM2EmzISZMBNmwkyYCTNhJsyEmfDfCfzbdSkhxj5C6VwDISa6iuiIS3kPtFt5
C7SH0wHlUtCUci/R0T3K/wE9qLwMOqm8QHTiBmIDTeItF976M2gPpwPEQvKJTvkt6ADKyUcJb4JO
KL8h+eIG5SjpxtO3QAeUJ0FTyhugE8pB0k0PK++TbuT5LVmPPAnQAeUEaEr5AHRCeZWsp4LyHKik
PA9aoLwGGgA/62kl+FlPd/D4buV10D08ZZJRccPUx6BDyq2gSeVx0oOSnwVltfeQCeTpgRTmgR4m
xaRHHCJfAL2GBMhGSObPoN3KO6A9nPYpfwAd4PGU8nuyETy8ArpDOQZ6UPkj6CHl30EnGYWsLKQP
iN4DHVD+CpridEL5G+lD/rdADyl/AZ0EP33g8ATkqIP8B1D7MdBu5TBoD6d9kMYAQiEZgDTYN6ZL
Cvve8wKFfeN6QGHfeb5KYd+2Pq6w73TfyukOnr6Tx3dxulth38S+j8cPKuy76A8p7JvqDyvs++kn
lX8lA+J65UrQDcps0CHlNtAkakyBt7tBmWRS4O0PoD2c9qEFUwhmkgJv/wtUUu4ELVDuAw0oe0BX
KXeBjitPg27ldAfqTYE3Ft/F6W7wkAJvLD6Jdk+Bk/2gG5RG0CHldtCk8g20nEuZBO3mtIfTPrTL
BGp8DjSgvAS6CvKcQC0vg+6BHk6gZBY/CA2cAOpnQCehURMo8wdUoJXK+6B7lOOgB5XXQA8pfwU9
zFMmlZepA3n+Arpb+QB0j3IC9CCPH+L0sPIC6CTiEuTwF9AdoAG89WfQPcp/gLL8AZ4/gPy/AZ1U
/kYrkf9FUEn5FWiB8gvQgHIEtFJ5B3SV8gToDuV50N3KH0APEjvoIWIAnSQWWgkpXQGaVJ4EhQ7T
VSjzZVAJuFahzOOgAfCzCjrvBt0BdKuYZOgqaH4X3cglsJFLYCOXwEYugY1cAhu5BIZQ5qugknIU
tED5N9CA8lPQHcqjoLuRcwglfAC6T/kjHQI/P6LjvORxXvI4L3mclzzOSx7nJW/lebbyPFt5nq08
z1aeZyvPswPpJ0APKR+CHobEdiD9P+hO3i47ebvs5O2yk8t5J5fzTt4uO3m77AL/x0Al5begBcrv
QQOQ5y5ImMV3KP8OuhsYd0HCbtBDxArKJLwLEm4ATaItdqPG46B7lLdAD0KGu3ldu1HX26CTyq/p
HtT1BqjEaQFy7kFdb4PuQJvuwbu/o3tQ2iF6EDl/C8pyHkTOd0ADnFai9oOct4N46zjobqA7CCtn
AT1IbKCHOJ1kFBxuAE0qz9JDKPMtUAnlHEKZfwYNcFoJnTmEMlmclXkIZbL4Hlj5Q7zMQyjTBMrK
PIQyIXGU+Tw9jDJ/DSopvwRFXwMNKE+B7oDWHUY574PuQfmH0frv0MN462d0Em/9BlSCPkzirTdB
A0A6CU4soKt4+g6ezvRnkqOb5JxMck4mufwnwQl6LMr8FWyrjthAXcrLoN3K26A9nA4om0FTSkLc
gDZ6EXQV8YLuUZ4DPaj8CPSQ8mPQSRZHaV+G9uuUh0Wm278WmW4zGuB0lfKqyHSb0d3KS2KS9WXQ
g5weRu1JlPOOeDVqsfAxtk4oIezcN/sb4FTkI28Ov2NxgeSIOi0uknrRpcV1WXn0GDXP0+KGrHQj
+U9xoxY3kWrxqBY3E1l3oRa3CHdP57eSdbq0FreRat1TWtwufF33vhbPIUPGXWxuwP8ajB9qcUqM
pmotLhCj+UotLpJ887VaXJeVR09s5ju1uCEr3Uh2mL+lxU3EY35di5uJZCnR4ha6ajq/ldRYGrS4
jXgsvVrcTpdbklo8hzRbfwpOqM6syVmNq3JW46qc1bgqZzWuy8qjylmNG7LSVTmrcVXOalyVsxpX
5azGVTmrcVXOalyVsxpX5XwfkUkDqUeYi9gK/g38STKK0XOUDJI00hbxXy5Qf78ghpQEYiMkjCcL
yRCCTNYgbTPZgmcpfhfHNY7cW0EHkHMR3htCnk1ISyBHgueL4TOMsgZ43hHcpZA2wp+p7yfAgYxP
DPkSKGECd9sQS6Mumf9ewibEh5BX5jyP4+0B/nsMm3kpo1qpaeQY1upkOWRgHOV1xvnvLjAsXRzr
IFJi/PcAkhyFzK8xjpLVq+Lox5NaXvIwTxniJcYgIzU9U8swyhniEhvTuBxByjCvVS2T4UxnccBq
HONYMr8XoUpb5Z3VNAoJyPyXEjZzKST4byOw35xI8zuGOD3dHqrM1FpkzvuIhmuUy3YTz3mK42xE
TGpX8PdU1JfhPsz1Ibs1Q7y0YV7CBJfDuNby2fJmLabij3P+GX61XZJcG9hVrZG1tYwyxqbRqDxu
1vKkcHelVnoaKNQW2jrdSjGuIzGkDp+GK6PN/eAkxuvv1+oPc43dzNuKPTm7D7Sehbp1utfMJus0
LUpo+jYbJTbj6bm1Pq7pr4ompvG/mT9V+YlrEmM8DnDNZVxdxtss8865nw7+l3rwKW1R22Yt7hKc
B1b/BVzb06e1Y0TjYDQLQb/W79IcZZzr8nKk9JNK3sZVyDPAy1/CuVLfTSOMQYoRhG08hHkfP53z
MC99GHnS0C3G/2aOYAwlTCCVteAgx8J6zumlZtIH+a+2JLn+Zsrr4TyrWjvBtS3FOUzzfpXidkB9
W+YYWJ+Mc41K8DpUCW3i72aktxjyWw6LqL6bzHqi9ucBLpNTfXSb9msnWz6lXvWe5e2HFo1zGQ5M
6/wAfz7GNXYiS8/HONIRTdPVsuKcsp57Jm72XLUQlXirimvnMHDFp/vs2VyNnFXyZ5fRqdIzVlrW
7KyqPf2n2buzsZ/S19P5mpclAYZExaJa/YzWJ6dHkAFuQ0e4LY19KlJVzrHTZBrXtP/MPsCkyjRv
nL85wO0RQxOfLoflHOI27e+10P9UvzjVJyKcG9YH1JEozNtqjFxxn9xQXz9XXpHoT46mRgfT8qLR
5NhoMpZOjI6E5YVDQ/KaxOYt6ZS8Jp6KJ7fGB8KLYkOJTcmEnEjJMXl4dCCeHJFTsZGUjOeJQXkw
NpwYmpC3JdJb5NT4pvRQXE6Ojo8MJEY2p+RRZE3Hh/HmyIDcP5ociSdTYbkrLQ/GY+nxZDwlJ+Ox
ITmRRh39qVo5NRwDB/2xMcTZK8PjQ+nEGIocGR+OJ5EzFU/zAlLyWHIUfDO2UfrQ0Og2eQsYlxPD
Y7H+tJwYkdMMBzjDK/JQYgR1jQ7KmxKbecFqRen4FWm8nLgsHpY1mKGUPBwbmZD7xwFe5Tu9BfXH
t8nJGLAkE4CNF2PD8vgYqwYlbkZKKnElsqdHAWgrgxSTt8WSw2pdTMz9W2JJMBZPhtfEN48PxZLT
LdCaqbqVNc3sdRARQMmzw80NWaKPQ76oJobyNycYH3EwlowNxIdjycvkUfYk63bw3A3MxQI0a0cS
abx/QTqWVjFGUMAor6AfbZdOJuKp8PLx/spYqkoeiMtLkqN4mk6PtUYi27ZtCw9nCg/3jw5H0hNj
o5uTsbEtE5H+9ODoSDqlZWXxwRgAXMby9YyOQ7QT8ngqDiYAiT2WY2jJeHI4kWYMbZrg7C1eu3wh
nib5Ddp5YFxt0W1bEv1bst7FNTHSPzQ+wGQxKg8kUmNDqIDJfCyZQIZ+5IqPpMNypu7REShEZaJK
jg9vYi+dKmokk/mcHPHsTKUh/hTE06/q3XTtXK5aWfM4A5UJ1ALVZ6JPsg4yMLptZGg0ll0peI6p
nELw0y0wOp4eG09D7FsT/XGWZ0t8aOwMQJ+lLXhLRAbigzF0onAsNXbF9HqQ/d/Wm878BTZtrSVi
bWEhbmJUFOLA2kVdRRGskQn5veq7/Tt/OvE9m40ij2D7rPntdp7/3c+a3+Fg+cXnPmt+SWL5dQc+
a36nk+XX3/VZ87vdyI8rYatKHc/PVtWNnLqIneSTAqwOQrDJTaQDM4Vucj5ZTy7CqLyFbMSI0Ueu
h7XeDfv8v2HFv0sFsp86yM+oRJ6hBeRlGiBvQPp/xcpeoRupjfZSHx2iFXSUNtJxGqVbaTfdQdfR
nTRGd9ERuptO0D30BrqPeYToN+gh+m16mO6nk/Rn4jL6jLieviJuoG+IPfS4OET/JiYFUbxSMItX
Cw7xGiEg3ibUiXcITeI7wnzxXaFLfE9Yh/bpPx2jsPkfYFwHjP3AOAaMVwPjLcD4dWD8FjD+EBgf
A8angPFFYPwdML4HjJ/QVdQCjHnAWA6MDcAYBcbzgbEHGAeAcRQYtwPZzcD4VWD8Z2D8LjDuA8bD
wPgsML4GjO8A4wlgPCkOAV9ScAOjDxiLgTECjO3A2AmM5wPjRcC4BZjGT8eoeyULYx4wlgNjIzAu
BEb2nQmDwJgGxuuA8RvAeB8w7gfGnwPjK8D4NjAyH6yeFlAnDVCZVtJaYJwHjMuAsQcYNwPRVmC8
EfTrwPhNYHwAGB8Dxl8A4wtA9gdgfA8YT9LDgkQnhUJxmVAjrhdaxQ3A0COsAMYLgXEQGIeAMQmM
NwDj7cD4T8B4LzDuA8bHgfHZ0zEav5eF0QeMlcA4Bxg7gXEtMI4A483AeDsw7gXGg8D4DDC+Bown
qEAN1EFdwFgCjGFgbAPGZcC4ESEBjBPAeDMw3gGM9wLjI8xjCoy/BEbmrTwOjB/RfYKRHhTc9JBQ
DIwNwNgGjCuAsRcYE8A4BowTwHgLMH4FGO8Axu8C40+A8efA+DQwvgqM7wDjx6djtHwnC6MfGGuA
cR4wrgPGQWC8FhjvAsb7gfFJYHwJGN8Cxo/IBM0FxggwzgfGFcC4ERgvA8YrgHEn7u4Exu8C48PA
+BQw/hoY3wXGk3SnYKG7hAK6WwjRPUITMC4CxlXA2AuMSWC8Bhi/DIx3A+P3gPFBYPwJMB4FxmPA
+AowviveJurEO0Sb+I7oEd8Vy8X3xNmwf4tPx2g/noWxCBhbgXE9nyl2kBuB8R7cPQaMR4HxPdJH
c8gALSYpWg+MK4CxDxiHgPFqYNwFjP8EjPcD40+B8Rlg/A2e/o2OCno6LuTRrUKY7hDmA+MyYLwI
GBPAuA0YbwbG24DxfmB8HBjRH4U//1/izgQ+qupu2OfOTO7cWRKSGCAsCgFENjEiFcoaMCqbIaJY
iq2OgOAg0rAa9iGJGJViREvRWkVqkapFSqzV1k5HkkaQRcQkpoQqBAaVjiFSZpjSvNzvOWcmG+L7
2vf3fb9vDs+de+9Z5r+d/zkTyMX6A6uwTrMmWX+IDvOsV1kXWgdbl1uHWVdbx1jXWO9CxwfRcRE6
rkLHDej4GjrK/zFHGHb+JCf36ZO9sqDASNAMPa/Yx6s4z9A1w2goLuJV3KAuOGuUl4amGTZf/GUY
muEsK/s1r2efVc3yi9QrX43WUFxc3EAzh71VjS6r7KqqpLjYsNHOU+LL6p5c4jEShKFHu8deSriC
guzsPn2Skw2dmqJx4zIzx40r0hM03d5g5BcXq4+x+3xytOIG3abpCXlSrjx135BNaKTa5xVHfb58
wyYMW2ZWQ5Z80UjX80tKPL48lIyNtHOP7BJTUsSVlCL6fCVbAlu2lLRRXzc03fnW3sd4qc+IdY5/
HC8phm6PCUdrq6bbjsU6Iqme5wtkJh+z24TdFhMoU/WUrTc/oCcIPaG4ODe3e3fdIXRHsa/YN5Ws
0YMSq6Mmt9hoaYY+LbIJn65putUnF1Kfxsvq0+xUb3QlCEeCYSQnd5c9fD7NKmy2Y5ouTL3RaaG/
vClfWVnqUp7Il89n4aP0B3ZarZqRsGXLFuUrpaXSk4vMzNzckii+Ul7EKYZBTZsQI0LsQ7Pl8NlD
v2uIOTTD9Z7vPd9WyjMUaQmDgHIMzS7gxUDN8SRDzWipGWH9X4WausjmrE92QatQcyRoDgKkVazp
sVhTFUZzsMkKT0mDrLAJB8F2uWhrGuwy4eawaQ7CLR5vDk1zNNviPw04OR92Bi4JODUFsi4fcfp/
E3F6S8TpTRHXWrpvCTnHfxtyLgsDNIUcoaaum2IuFnT2WNA5YkGHP1uCjouWoOOiKegcDuFwGCJN
pCnpx8j/xTeWhhzGiLHqo8aOkFeOaJGMlIKiqLqSpxfloa3VHU7N4Q7weinrpayNqqynEGoO54ix
a+WL4XQGjxK9UdnF6ZB1YizrX1MZK0YJzdfSrJjQV2Egc26eEtsuHPaLyfGXUkKONQYFpBpSHUM4
5J+1Y3v1Su/Va+xae4JmZwBib/MDTl1zGrR/u5zhy9+WVbF8Xpynqmw22+L1VK1fbNc1u8zHjT7f
SqdNOBOagzSLlnb7SmleHw3y24yJvMou8UD1ORM0pwziYhmqJcVOTXO2GM1nd2h2d6nYryZsrKjP
jQ/VJENR7FPi98vflj1tmj0et+pczjNPcvIxOZ8SmiTNVAOo/igkzSCDkqi0O4XdlZ2VndXPJ0uK
SBGxaipzc4udrZoSjk7N4kxojmAfAWtHBxnCPoumWThn+2RxbtyYqAuXbrO1iWPNlnBMs4uL9ouJ
Vs2Z0L1VIHdXd+RJ7EWVVce9s97cbLNpTr2EV9z78XCWkWFP79Nn3LjiRsNQdbF4JjKcfHHE8S0h
vYaYUC4wNKdj1JjYp44ZJS+djQUqJNcWNKpLeWqqG5c4yOnSnIkBT8DDxNryVPenuj9OKaIQvE7X
qPgnNL3GEL4qGmTwxoLc5bxsu9FCBJx25Iq1JMwLVKTIWPQkK3Xswmk0B3qy0u6bkW7QiD8q1mPB
HgsZ20o87tI1lwzM1tFuj0e7qrNdPtxdNuGS4d4c73bqVssg9LFArWw77KUB70rQXDLgmyLepWmu
Vgb9vxXyUpV8lRMa/l+EvEuzuJpC/tti3kEbKf63Rr0hLhpmklVztYp6Ge3qVkvYq7gnrRkzNq4n
7l0q7lUYxbeDTTkmvTny1eVK1M3Hg0X5LqdwOd3svGXJoGT51vj4xCxflsvQXI6r7ot9fNZ9V8lr
Z3RdLPwL1kVdDs3lavGO2cpTl3rOlai52gXSA+lb+mzpUzKuZJycko8YjxgFhhqlK1+4W8f5GK67
CpcdAdQSEpsQbue3NL2SKdHcODYlClSo5RcheaahFLULV6tJkawUl2ryx5ehVJcmcFNcDv7IkWOT
xWhe59guxTbhzBFixG3X3I5YNMtVrfztNhswVWvhNewWWXvLMNV3aLacJ9QmCHfC0JaJkuWSm/jm
mVKw8pLBCwpi6aVZc7euuY1Wk6XIrWnu1jb3GS7NSHonUKGSTlNRW7umIdvs81wtNWrOqP1cfM74
4jsDmWDIL6QbPSsrGhN8qBolNiBKsr0zmvd6LmG45adOyJqQ1TR11FBqg8PccbVuzhxwaxa33qyB
NLhmMRJ8sV1P6+njltMnyS7cdoulaQLF509C0/xpZ9Xccv40TSDOuqt76qxpArWZQW67nEEqlmJ2
iZlGzgR3Wlqv7Owik2mj6mNzCP8W5btdwu1KEkl8RZflet/1Pk9gDblfpn+3Q3M7u4k8n0cEWhUP
d7oJQtrtvijK2IAHWr3e85X5LsYqW26arVsE3BYs1eZGkuZOPtb1WNeGEYcG1Myrmbdn0v795evf
X1/mLnO7XZo7sZtYEJepqXgCCwIIYSBhY0VZWVlFoxoqyf3trX3imMhUOjWKClGmSoWQ57Gr93wq
ckfMDgSO5XdN0vX9+W5DuB1mestL2Ss2oizSXjHLSRsqacrKZs8ekZ4+YvbssjK1d1xZoeurKyoO
Lk00tESnFPLoqTL5OnU0tu+crSSfPULVW3kNn6Pq5wyXG0nkqai4GAjMGJGoa4n6CI/HE/XEX25Z
v6aC18rAanqsvvQjysoSLVqiLRAgzTS9Eu1aokOeVOyvaWio2b+/It6m1cvh1hztjh77PLOiTVEb
2+ahY9vc2ep89gh3q7pTR+UYcqNSc6xpRLm9zS+XlnWvz5frpd6iyFA1VHxY1JYbXPnNbqaQ5UZK
V4ojiT8yJGamz9k8a/PgnSMa0j3pHrXvVUaXNndfvm86JVMkWiyJrSIPm5DmHAnSPEJaSOY8rixO
2u0P7A+k2EWSXf5ve25cn8kLWQMBzaYl6A2aQ1x0mL5kG06J3Y+9OM1UN9VZ/CXrrXLnw1xNwI3G
fvlS8RI3YMyGMjiTxFWiA2L3FrPFLYSm6dOFLKr1ammulTpBUrFSxH9S7hRbLdOEdeayhfNE2pyF
9z8ohs27b/F8MYka7Y4pY7ujuzBN9XMqXSSyJsSuNIF6or26H7tjYcVox4d3ENbxubnjRK8pk2/r
LjLvnDKxO5u8WBv5dxXJoqO6svIJKc2js4FSP8+MXbFKiCtEZ9FlZt6iPPGyOr6qjjvV8S11fFcd
dz94/8L5Yo86HlTHSnU8oo7H1PGUOobk37WJs/Ko6erYWR0HquNYdbxLHec+9OBDD2qr1XGdOm5Q
x03q+II6blPHHc1/4/A/HbXveDSwJN9l5b+Ek1/MsMv/v3sW/JD4H7/LIJT/Vkf+a44CsVFsFbvE
bnFY1ImzmkU4lKZGXNuQkP9Ozkq/NGaaJn9+qA2LvRevi73/MtqqD/FWv7XNteZubHud1LvtdUpq
2+srnmt7ffXFttd9Lqnv17nt9eBM4bC0vj7Xql4X2q0j2l5Pepx3JzHdR+TKf1tInwJMlWnJFWss
L1s+EVusv7T+UlTaFtteElUJH+vFmtV5h/M+7R3no+wo97iT3TdbbnLf7X7BsixxVuJcy58T1ySu
t5QnWZIMy+Gk80nnLX8Tmi8ibaNXJ7512XKIciTxZKtyOl4OXaacS+rRXPpQhlGyKXNV2XxpSTyU
tDXpzeRN8bKlVXlVFrn/uUxxpuQ2l8dTnmkukVhJ7XqZMpAyOO25VuXlWFE1l5S0XWl7msvB9sco
p2TpYLtcSR3YIbVDn46PtyrPqLL7suVQxwtNJT0tvXNzyY6XCZctuarcFX9vW3zxo2xXoUplc4n1
/jS9oVO/TrM6vdBpuyyXjt5px+VKbPROb3eqi5dzLUV+SqcL6rN8kisn9RzWXCb1nNJcZsXLXIqv
51z5H4v0yrp64NXZPedyHHj17t57rqlW5Vyf6ZS8vr0pA/rW9Y1CXd+L/fb0f0GWvnX93+1/uv/p
AbYBSQPSBvyRUjlwFCV34PTrno8X//W+G3rf8MXgjTcOpowakj5k+pD8obvi5d2hFUMrh/WjDB22
bvjRkboqJSN3q9I46sZRr8fLWyMbuX59VIO6ahhtGW0Z9froAVkbst4dM/DmaZRPb31gZEmsNe8N
sVbjR8l24ydN6DEhc8KoCdsn9lYld+JcVfInrpv4PMf8iR9Qjk1aPsk36dPb8iibcjy0ys05mHNw
4gccj8ozSl1OKOfCZJ8q2ybvV+XTySH4dHIk1zY5Qn0od3ru0dy62xdTNk7pTrttkyOxminLJ0em
nJxSPzX3ropp036c+uOuP+49xzZn+pyaORea3h8YQNk1P3l+j7z8vIK8QF5dXigvssC2YNCC7AWz
F+QtWL6geMGmBa8veGtB+YLDC/MWbly4feHZRWJR6qJxi2YsendR9eLBi2csfn7JXUuKl/iXnFuq
Lx2w9Jalry899XD2wxfyu+bfku/JX5j/fP6O/JplPZb9aNlby2qWXVjuXt5h+dDlY5fPWr5tec2K
fiuyV9yzYvOKV1ccXRFZmbVy+cp3V+mrslYtXLVzVcWqxtWdVz+wetvq0Jpha/LX7PDlfkuueuvS
fNQ22/iWthSZR3xbWkosg3zL3Jtw6YxrO09ikX7ZrNOUeVqVtrnDV9FSZHbwVbaUWF6QOTT51fSK
js+Qh4+MaiBrqhys3sm3Kbnk181JW5M3JR5qzpm0TYn0nCX7Jr6VtLkld8asRHbOVvk31qpH0tYm
68m7MhertkdkvWoftyDjvpV4kky+lR5H1GiHkG4T70dUaVkdTl+yKmS3WgdaVoKtUu5vZP9Xv5H9
nfGc/7jK9yrLq3HonZTN+eamTIg/tsf9RW6K5Z9Yfov7kZxIBpRem9WcHZs8So5Ln+Crkz1afNxz
iq/OV8dostU56nI71fWc8s2YIA9Wtsqol8mzrfPqN3NqPHNXqGiKZdFJTflT5nXu8Km+UKft3JmS
nnvj4JyDHWyxdUy9s2Z1vND+GFGV2rT6NK0qqV072FpWoFhUyrVNtbbJFvTd3SFV1sg7spW8n9o1
8VBTpKZ3Tu3KCpgq+8vz2N2WdbT1SiplUatmfN1stXKmMsKl6+QzbVbHQ/GVMa1JeuovxD5dfv7E
3PbH0rORp431pdWkjfFUqxnbZOPYTJTWjEVKz1nYe4L0prREem7ac8rf26VvWs3qYZ12oGvTClsZ
G9UXSvf5QrEiP0G+95wivSLPYpEm332hqwf2GhQjtsL1GqRWpVZFrnCx1U2tj//LotbUVuWbLdRK
26rEV9zm8s0ecqX9z4pai79zaV6xv6VcailZmtfxbylqZf/ORe02vmO51Dpqj9KqfNN+au/Sqsi4
j3n6PyvfHPl/lu67lZid5d4laetIfUKPkY2JR+SuR5USdUeXOx11VTKhh9wDxeso7KCGyl1T7K7M
/fJMFrU7mqZ2VnIP1TCqQe2P2B1xtntkidqd+Jp3MbJsm+zLOTrZJ3cw6mpbfJ8TO9/GLqhO3pE7
GtkvJ17Ujmex2hvRVtVuk8dOO2i9Te6myBa9c46qfVd+vOSqO73lrktd5eYclXkpXkdh55bJXk3u
0GS/deqMovZpeWo/R1u1U2ver03MHW1RFmmUtrh9ccwSI3WlDxLHJJ34gRpbftI6NZYat+1M/KZH
W8fBNdWxK6HL35G33ma+a50q2snfkZe/IW/1iyFC/ibxIa6C6ixknWqeFBrH88LCca/6zXiXeM1s
FOVmo+YRV2j3iSnaDNFJmykytFkiRXtQpNByMC1HW+eZfxEa45wQNtq6aZtCWzdtnWq8IK3qhUO7
R3Slvif1U6m/kvqejHU1Y2XQ+xfI86n8vVJzF/KmWFcixyrzD8g7zHrC/Ln1pMi0BsUg6+eiv/VL
8yPrab7tytEPqd/Rt3Fmkb9ZL3+vXv1Wfb5oJyaIZBgm+orhIH/L/n6YDfJ37Reb58QSWAoPQz7I
375fbh4WK2AlrILVUEj/IngE1sGjUAyPwePwBKyHd8RY8UeIcn4RTNFXE6BBrhiu3Q5T4A64E7xi
svwtfzT2Wu8SI6x3C8N6L8wTxfK3pa1rRXdrobjK9qJ52LYFXoLDoq/tY6iEKqiGT6AG/gZHoBaO
wt9F34Rk86OEY+bhhH8Id0KI86+gwTysJ4gJel/ebxB99Rt5n2d+pD8E8+EnsMT8XF8K2EbHNjq2
0ZcDttHfEMP1nfAHOC+G2/uJbvb+cK/oa/fADFgAC2EZ+GAtYCN7CTwFL8JLYqz9Nd6/gnpogK/h
LJwHbGjMhFlwPywR3RxCDHekiW4qdk+p5xnIsy/VkwraE7WlRG0p0dabaBtDtBUQbXcQbTOItvFE
W5Z8wgDxMtB6l7lBPlVAPlNAPlFAPk/A6je3WU8QZ0FhtZ4iBr8Ud6s4O0mro2wzm2bFPeK6VuOP
Y/yljH8z4w+h9XTGfkY+J0A+JUA+I0A+IYDx3mW8u0QSo5xhlDOMkswo1zDKfEa5jlGuY5T+jHKN
/G1zRurDSPKpB4MYYbvSdK98MoBIZ4y/MMZfGKOPdq/5R8a5jnHuZZzBjHMH44zWvOaHjHWdttl8
m55/Yjwb4y1FstmMeQWSFTLaE9Y68xzSfWD9gtn6pbjWejo+Y1MYtR+jehl1CKPezKi9GLEPo30s
f+eZmXcbWk4VrniG+S8yicwsz4pCMySK4BFYB49CMTwGj8MTsB4+MKNiH+yHA3AQPoRD8BEcho+h
EqqgBv5umuJT+AyOwXGogxPmPnESgnDWrBX/ZJ6fgzBE4DxEyW7/ov4C/Bsa4b/gIrKYZkgToKms
eMI6nQj7kXnGeg/vHvOM7bAZsn0MlVAF1fAJ1MDf4AjUwlH4O3xhRm1fwmn4B4TgK6iHM9AAX8NZ
+CecA2SxXQTT3JeQau6zZ5lR+80wASZCjvm5/U7ep8J06u+Ge+BeM2T3wAx4kLoFvC+ExZw/DPmw
jOuVvPt4XwvrOH8U8IP9Sd5LeH8Knub8GfgZbIKfM/6L3N/K+cucv8b5G5z/CfCRHR/Z8ZEdH9lr
TdN+FPCRHR/Z8ZH9GH2OQx3gI/uXZq39NPwDXULwlXnIXg9nqGtg7K/hLJzjGt/ZI7yf5xofGTNh
FtyPvyxig0hTK5dVbCB2pxLDcvVK4Oq3XE3gajxRXm79UPQXGncjIpvIrCUya4nMWiKzlsisJTJr
icxaIrOWyKwlMmtp/TmRFiXSokRalEiLEmlRIi1KFIWImAgREyFiIkRMhM+Tzzqotf5YJFjvgxlE
0EzzBFFTS9TUEjW1RE0tUVNL1NQSNbVETS1RU0vU1BI1tURNLZ6M4MkInozgxVq8WIvnInitFq/V
4q0InorgqVq8Uos3arF6FKtHsXoUq0exehSrhrBqCItGsGgEi0awYi1WjGDFWqxYixVr1Yw9IuzY
cgwz2WDt/TNr7++th1hrP2IVYrVR9j2Nhh+h4XFl35VcyafodMW+BYzwiZjGOpnBOpnBOpnBOpnB
OpnBOpnBOpnBOpkh5P84th42iBtZK3uxVvZizlYyZyuZs5XM2ePM2TBzNsycDTNnw8zZMOtpKnM2
yJwNMmeDzNkgcxZ/i4msm4OZp8eZp58xT48zTz+zzhC9rTNhnihiHe3GOtqNdbQLa2cGa2cGa2cG
a2cGa2cGa2cGa2cGa2cGa2cGa2cGa2cGa2cGczHIXAwyF4PMxUrmXpg5V8mcq2TOBVnjMljjMljf
MljfMljXMpgrQda2DNa2XsyVIOtbBvFfSfxXEv+VxH8l8X+c+D9O/IeJ/zDrXyrrXyrxHyTmK4n5
MDEfZA3MYP3LYP3LYP3LkPFunsXWZ9mfbTAfwQPjyOfHyedL8MQ4PPFratcT7TdbD7OTqjQvWqvE
DOW9WlofoVUNK+YGczVXM+h7mL4fczeLvhvo+z59J9C3kn4/FHp8Hv2AllW0rKTlBLW/kjHzihrp
fupHU3+Q+mrqhzPSY9TuZKSxjPQBI2Wq9n9T+8RP1TEinFo70U2bDvPgIfgJ5MECWAiL4XFW+hT5
XBk+pUA+TUY+S0btjbaIjtY/ie9Z38P/daInq/Yd7BJTWbk7s0vsaf2CzPAlEpzm3j/E91jPF5rv
0aMDe8oeck2n/zwxnhVsOjF/txhvvUftvsaLJCTrgmRdkKwLknVBsi5I1gXJuiBZFyTrgmRd6JlG
z/n0TKPnfNUzkZ6J9EykZyI9E+mZSM9EeibSM5GeifTsTc/r6dmbnternm56uunppqebnm56uunp
pqebnm56uuM9B8d7DkaTu0U/zvopG5eqPcJ5rFUrn18Bt8MUuAPuFE72bk72bk72bk72bk6H/Hta
m3yuDH1y4zuNcuWj46JS62PWaX2hH/SHAXAtDITrIBOuh0FwAwyG78GNMASGwvdhGAyHETASRsFo
yIIxMBZugmy4GW6BW2EcjIcJMBEmwW2QA5PhOfgFPA8vwIuwBV6CrfAreBl+DdvgFdgOv4FX4TV4
HX4LO+AN2Am/g11QCm/C79mtBXh/zzyi7YYyKIe/QgX33zertD2wFz6AfbDfPKUdgIPwITuI6Xxb
ucc8ZPsrO4kKeB/2wF74APbBfjhgVtkOwodmVUKKWZeQBu2hA3SEdOhk1ulPwrOADfQXzFP6NvOM
/gpsh9/Aq/Am98t4Z7ep/5XzQ2aV/jHtaziPmHX2K+Eq6AbdIcM8Y+8BPaEXXA29zSr7NdDHPGLv
C8SCnViw43f7IK5voG64eco+gvcp5hnDYtYZVrBBAuhgBwMc4AQXuCERkqAdJAP6GqlwBaC3gd4G
ehvobaC3gd5GZ+gCXQH5DeQ3kN9AfiMDekBP6AVXQ29kGmSeMm6A75tVxjAYzr0suAVuhXtpN4P3
2dTNod0D4IW5sIS6VbAa1oAPnuT+r2j/Cu23m0eM33D9KpzlXtisc2iAro4rzCoHejjam6cc3Ymh
FeqpSlhHwzoa1tGwjoZ1NKyj0UPDOhrW0bCMevZSCqTCFZAG7aEDdIR06ATy6Uzy2UzdoDtkQA/o
Cb3gaugN18jndvEtuy/0g/4wAK6FgXAdZML1MAhugMHwPbgRhsBQ+D4Mg+EwAkbCKBgNWTAGxsJN
kA03wy1wK4yD8TABJsIkIf+LUZeWA5NBPlfqdpgCd8CdMBW574IfwDT4IcinRK2GNeCDtVAAhVAE
j8A6eBSKge8b6jlVT8FGeBqegZ/BJpD/r658xtMv4Hl4AV6ELfASbIVfwcvwa9gGrIDadvgNvAqv
wevwW9gB5FqNXKv9DnZBKbwpn5Iln2EFu6EMyuGv8slSsAf2wgewDy7NIlPN++QTtVgH2pH5R7AO
tCP7j5DP17KR8WxkPBsZz0bGs5HxbGQ8GxnPRsazkfFsZDwbGc9GxrPt4DvKG7ATfge7oBTehN/D
2+ZXtnfgj/AneBf+DH74CwTgPdgNZVAOB4TbdhA+FO6EFOFMSBOuhPbQATpCOnQSLn29+ZX+UzOk
P8n5Js43m5/rz7Im4QOVzbZQhy76r6lDZh2ZdWTWydL6G+ZJfSfsoq4UZJZ7i/Z/4N471P8R/sT1
u4CcOnKq7Pc+1x9Qt4/3/dw7AAfhQzgk3PrHfDbf7XS+2+nV3PvEPK8y5RFk4/uc/jl9+c6ihzhn
d62zu9bPAN9ZdL6z6Hxn0f8J5yAMEXQ7b560J5lf2dtBMqRAunne3gk6QxfoClcKp/0q6Abdobdw
26+BPtAXrufeIN5vAFZZO6trLOsKt2ERLsMKNkgAHeQ/zjXAAU5wgRsSIQnaQTKkQCpcAWnCabSH
DtAR0qETdIYu0BWQ00BOAzkN5DQyoAf0hF5wNVxjfmX05zvaALgWBnLNTsG4nvOmTDyY8xthCAyF
76PHMJjE+W3A91xjMv1yzXLjdpgCPzTPG/ci52zaXZql+b5r8H3XeBhWIcNqWAM+2j/GZzP/Vdbe
xPtmxn0WnoNfwCuMtx2asvhr3MOHRpi+/zbPO4R50qHJX2gwQw75L5mdvKdw/wrhVpmdFcrRkXvp
0AnIx46u8ueScqbH91Wr5NPq1B5td/P9+fLpcernKHK/VS8SLOPMH1lvM8vYnTrlz7ao+0oMsGSa
py2DYQiMhnHmR5bx5j7LRLiNXflU81N2F0fZXRx1TjP3OafDo+ZpZzE8Bo/DE7Aefgp8l3M+CSXw
FGyEp+EZ+Blsgp/DZngWnoNfwPPwS3gBXoQt8BJshV/By+Zpd3/ztLAiacQyje/EC/kOPRz5w8gf
tgwzg8gfttzE+2PmccvjfHe5W1xL/rqWlvucd5hB551wF/wIZprHnXNhHsyHPFgMj5phdAujWxjd
wugWRrcwuoXRLYxuYXQLo1sY3cLoFka3MLqF0S2MbmF0C6NbGN3C6BZGtzC6hdEtjG5hdAujWxjd
wugWRrewa4J53DURJsFtkAOTIRduN4+jexgfDjE/wUP7LcqP5h71k8Nu6L4dvbdb7jZ3WGbBQ/CY
GcAG8tmIR9B9O7pvR/ft6L4d3QPoHkD3ALoH0D2A7gFnvrnDuQxWwFp4xNyBXAHkCiBXALkCyBVA
rgByBZArIMbgAS8e8CLbCTzgRb7zRNA5Iugccn6GJDVIUmOdevGcddrFMKtLIp65jtUlEe9cF/+O
X050nSO6ziFdDdLVIF0N0tUgXQ3S1eAZL57x4hkvnvHiGS+e8eIZL57x4hkvnvHiGS+e8eIZL57x
4hkvnvHiGS+e8eIZL57x4hkvnvHiGS+e8eIZL57x4hkvnvHiGS+e8WKBGixQgwVqsEANFqjBAjVY
oAYL1OAZr7gJK3iwggdf7MUKHvyx1zJOXIn2OWifE/956xPx79P9sEIHrHADVuiAFW6I/5T4h/hq
L77ai6/24qu9WCMHa+RgjRyskYM1crBGDtbwYA0P1vBgDQ/W8GAND9bwYA0P1vBgDQ/W8GAND9bw
YA0P1vBgDQ/W8GAND9bwYA0P1vBgDQ/W8GAND9bwYA0P1vBgDQ/W8GAND9bIwRo5WCMHa+RgjRys
kYM1crBGDtbwCDuxcA6N3Wj8FBovReNUNFyNhg+LTtioHPuUY5tqbFONHVKxQSq1T6N/OfqXo385
+pejfzX6V6N/NfpXo381+lcjRzVyVCNHNXJUI0c1clQjRzVyVDNXvOYrl+S7c+Jay+3kuGngJc/N
Jcc9CPOAsZH4WHOuW0XOWGPuc60wT7tWwipYDWvAB2uhAAqhCB6BdUBudJEbXeRGF7nRRW50kRtd
5EYXudFFbnSRG13kRRd50UVedJEXXeRFF3nRRV50kReTHOAEFzlPZvbTSvYwczzIHA8yx4PYTX5P
703tYeZukLkbZO4GmbtB5m4Q2cPIHkb2MLKHkT2M7GFkDyN7GNnDyB5G9jCyh5E9jOxhZA8jexjZ
w8geRvYwsoeRPYzsYWQPI3sY2cPIHkb2MLKHkT2M7GFkDyN7GNllzppm/g1r78fC7zXnLKnRZ2IQ
GpVSX0f9ebzRiDca8UYjbT+jrUFbFzPFiaYDmSlOtB0Y/xlQBR5qxEONaFmKlqVoWYqWpWhZipal
aFmKlqVoWYqWpWhZipalaFmKlqVoWYqWpWhZipalaFmKlqVoWYqWpWhZipalaFmKlqVoWYqWpWhZ
ipalaFmKlqVoWSq+hyaF+GYPvtlj8Yqu+GcPGsxkBvyLGRBBkyI06Rj/yUxH+ZMZNPm5/GkWvtuD
7/bguz34bg++24NWhWhViFaFaFWIVoVoVYhWhWhViFaFaFWIVoVoVYhWhWhViFaFaFWIVoVoVYhW
hWhViFaFaFWIVoVoVYhWhWhViFaFaFWIVoVoVYhWhWhViFaFzONpah4PRYsP43/ndAtSP43Uu4QL
fQ+g7wF0PYBe7dGpPTU/Q58D6HMAfQ6gzwH0OSB0yxL8utT8l+Vh85SliLj4qVlv+Zn8STt3L1iK
zIjQOP5L9KVFxJJPRCyDIrPKsk4Ylkfpvd78wrJJPmPU/LflWfPfLva3Lva3rivhKugG3SEDesAs
2twPs2EOPABemAsPwjx4CObDTyAPFsBCWASLYQkshYchH5bBcvPfSp8LSHrCssr8HF1OWp4xz1j4
piemWxYS7YtgCXfz0XIZrDEPWXywFgqgSLS3rDPfsDxJuxLzmOUp2AhPw2bzHfR7x2Ux97usYIME
0MEOBjjACS5wQyIkQTtIhhRIhSsgDdpDB+gI6dAJOkMXsx4b1mPDemxYjw3rsWE9NqzHhvWuYeYh
13AYASNhFIyGLBgDY+EmyIab4Ra4FcbBeJiFHvfDbJgDD4AX5sKDMA8egvnwE8iDBbAQFsFiWAJL
4WHIh2Ww3HxH2IicT7Hix1jxuGWT+TWxVGSeJU7Oi1y8EMULUTxwAQ/ICDvOihNhxYnQIoKVo1g5
ygoTYYWJsMJEWGEirDARVpgI1o9i/SjWj2L9KNaPYv0o1o9i/SjWj2L9KNaPYv0o1o9i/SjWj2L9
KNaPYv0o1o9i/SjWj2L9KNaPYv0o1o9i/QtY/wLWv4D1L2D9C1j/Ata/gPUvsMpFWOUirHIRVrkI
q1yEVS7CKhdhlYtg3SjWjWLdKNaNYt0o1o1i3SjWjWLdKNaNYt0o1o1i3SjWjWLdKNaNYt0o1o1i
3SjWjWLdKNaNYt0oc24p0S3n4ipsuproLhJJWPsE1q7D2mdEHjb2Y2M/kf4FLfdg6xPY+oRlOder
zC/pdZbIDxH5ISI/ROSH8MN/4Qc/fvDjh68tG8z3mQGfMAM+YQZ8wgz4hLm0n9xQgY+q8FEVPvLj
Iz8+8uMjPz7y4yM/PvLjIz8+8uMjPz7y4yM/PvLjIz8+8uMjPz7y4yM/PvLjIz8+8uMjPz7y4yM/
PvLjIz8+8uMjPz7y4yM/PvLjoxP46AQ+OoGPTuCjE/joBD46gY9OMENCzJAQMyTEDAkxQ0LMkBAz
JMQMCTFDQsyQEDMkxAwJMUNCzJAQMyTEDAnhYz8+9uNjPz7242M/PvbjYz8+9uPjKnxchY+r8HEV
Pq7Cx1X4uAofV+HjKnxchY+r8HEVPq7Cx1X4uAofV+HjKnxchY+r8HEVPq7Cx1X4uEp48WAQDwbx
4D/x9268eAbPHcFz/8Bz9XiuHs/V47l6/O/G/7vwXgjvhSxPcO+nePpJ87d48As8+AUe/AIPfoEH
v8KDXxMnf8aLn+HFz/BiCC+G8GIIL4bwYggvhvBiEC8G8WIQLwbxYhAvBvFiEC8G8WIQLwbxYhAv
BvFiEC8G8WIQLwbxYhAvBvFiEC8G8WIQLwbxYhAvBvFiEC/V46V6vFSPl+rxUj1eqsdL9XipHi/V
46V6vFSPl+rx0v8h7s7jq67vfI//ck5yTjg5cRfX1rq26rTWunSqXaYdx7HT0dYu1rZTOzNqLVRa
UVERUWhd6oq7KOJSEVErUFNUFFyxaGwwIQc4nAQSWUxyOPmRhGyA8r3Pk9JeO/fex73/3Hv/eD1+
Z/19v9/3Z48xxKwUs1LMSjErlVipxEolViqxUomVSqxUYqUSK7WxUhsrtbFSGyu1sVIbK7WxUhsr
tbFSGyu1sVIbK7WxUhsrtbFSGyu1sVIbK7WxUhsrtbFSGyu1RZ9lpUFWGhyJxj9boZ8VelmhlwUG
WaA8N/VSt5e6vdTtpW4vdXupO0jdQeoOUneQuoPUHaTuIHUHqTtI3UHqDlJ3kLqD1B2k7iB1B6k7
SN1B6g5Sd5C6g9QdpO4gdQepO0idXur0UqeXOr3U6aVOL3V6qdMbHSUzfCAzfCD6S+p5JnGzU9zi
FCO79/heTFfv71e3D9DVHYiP4eM4CJ/AwTgE5/nM+fgpLsDPoIOk9RCth2g9ROshWg/ReojWQ7Qe
ovUQrYdoPUTrIVoP0XqI1kO0HqL1UPQzWnfSutOOS3ZcEgVFUVAUBUVRUBzR/y8RQPf/wfN18Iny
Tzb+197eyR6d7NHJHp3s0ckenezRyR6d7NHJHp3s0ckenezRyR6d7NHJHp3s0ckenezRyR6d7NHJ
Hp3s0ckenezRScESBUsULFGwRMESBUsULFGwJBqKoqEoGoqioSgaiqKhKBqKoqEoGoqioSgaiqKh
KBqKoqEoGoqiofh/EA1FFiqyUJGFiixUZKEiCxVZqMhCRRYqslCRhYosVGShIgsVWajIQkUWKrJQ
kYWKLFRkoSILFUdqfM/If4U8ka1KbFWSbUqyzUbal2hf1rhE4xKNSzQu0bhE4xKNSzQu0bhE4xKN
SzQu0bhE4xKNSzQu0bhE4xKNSzQu0bhE4xKNSzQu0bh8xpIzlpyx5IwlZyw5Y8kZS85YcsaSM5ac
seSMJWcsOWPJGUvOWKop+8IEXIbLwd+cseSMpWg3uXjgb2OGp908EumDcurg/y5G9O6X6VFNpqIt
K9pSou09kba3SMtEZ/w1o0xQjSfjanP5tda6MfTw7B6fHhabPapzv299hsKDFO7/SNfUw7t7eHcP
7+7h3T28u+f/Ubbp4X09vK+H9/Xwvh7e18P7enhfz//Vrqg8rQxTaulf55b+KLnztWFW2h59j7b1
tK1nv27266ZtebIpsEQVfTvo2zGS/6Z5frcZ4R6d0nSv3R866NpB1w66dtC1g64ddO2gaz1d6+la
T9d6utbTtZ6u9XStp2s9XevpWk/XerrW07WervV0radrPV3r6VpP13q61tO1nq71dK2naz2f6uZT
3Xyqm09186luPtXNp7r5VDfdO+jeQfcOunfQvYPuHXTvoHsH3Tvo3kH3Drp30L2D7h1076B7B907
6N5B9w66d9C9g+4ddO+ge0dN+ZwTcBkuxxWYiCtDx4jGW3dGwnC0Z2JBNDrxmo7zdX75RpiSWBrm
JLboMwbCtMTW0JiUOZOfNr0eE+Yljw8b//rbymdFuyW/P/JvqZR/p7Az2xKWsdgs952L10XAGyGX
WMLT38RSa77l+k5oSSwz6eastsJ1JTqjUYkukTqgxx3UCQ1hW+hNRqE9mUY19jP9HxPWJ48NW5Kf
w3E4IQwmTw7rsv8eStnzQ0P255Ajsr90vSi0ZMdDTshOcp3sejX00NlfQ8XM3gpRmZ3m/bu8Jvdl
7/N8Oh50j1lha/ZJ95+H+WFL9vd41mt1ni90daZso9easByrPM+jxeNWtPtcd2jPbsFQaK/dK8S1
e2M0TIe1psPaw7w+NjTU6ulr7av2htBfe2vYUnsP7sdjIY7+ZaeqBXYapuoqqnZTtZuqH1B1A1Xz
VF1F1S1UXUXVVdQcpGYfNfso2UfJPkr2UXErFQeoOEDFAQp2U7BAwVUUXEXBAgVXUTBPwTwFCxTM
/xcFCxTspmA3BbspmKdggYIFCnZTsJuCq6jXTb1u6g1Qb4By3RQboNgAxQYoNUCpAUp1U6qPUn2U
6qNUH6X6KNVHqT5K9VGqj1KrdipVoFQ3pQYoNUCpAUr1RYckngqTEgvCfEq9zAe3U2g2VTYl1oYL
+NmERFd4mHeflejXaW8NX+Znf0wmw5JkKtyWzIZf8PYVyb3CwcmDop8mDw+X8vxDkp8JX6PaY7z/
VD43I/nlcHXyq+FHO387qy35/fBI8uwwNjkmLC7//pJTvSgnvaZKvIGlYY0V32ePtVbcaIUud+1x
x3XuuFksnSyWvmQifIrFXgtNvlWOlz+NxEhn9HHfXu6bb/vmBnvbaG817pAbiYfjQ843Xwtv+9b7
vvWcb+zpG+9Zr20kfk3VIzF8kDj9tOfHhLW+1W6XS6KP8awtI99cwrPexFs85h3fXsarcrrIFa4r
wwbesYF3bOAZG3jGezzjPV7xHq/Ywiu28IotPGKYRwzziGEe8R5PGOYJwzxhA8ttYLktrFbO/J3R
LvaTsvNZ1nvKui8460K8FbbRtZWeG7NXhEH373P/Pvfvy97v+UNh0H36okrf6rfzi31jXdnvdcJP
ySULnOWN0OjVlkSTPFLWcG0o0q3JfVe576robKtO8+kpYmr9iLe8ECZbfbJv9lJiGyW2ucN6SgRK
9O+Mq35K9CfyYa471vGkxkSJ92SwVzg/OZo19sG+ODRckjwMh4dNyU+x85H4NOvRPfkV73915HeX
j7WbY8Xeeur2U7df7K2ncD+FA4WD2FtPhcmUDpSYRolplJgm/tZTexu1t1F7G7WD+Fsv/tZTfRvV
t1FrMuX7KTY5+4xMNBcvhUuyS1z/hAYsw2oUsMZ7ba7vuce6cEltFP5YWxXm1qaQxsGeH4GxMtTU
ME0MrmfNbbX3hnW192E6HsDMMDeq4ZF9vHEdSx8n+3wo+3wo+3zI6p8X6R+K9A9F+oei+sPoQPYo
23KQ9j207/GtlBzVK0f1ylG9zt7v7P3O3u/cPc7d49w9ztrjrD3yS6/80iu39MotvXJLL//ulVt6
7bXfPnvkil65oleu6K3IWHEqD7iX9V9l/TtZ/87EYhZ9Ga+FpYklquKbWBoe4wXbE8u9nuNb+TAh
sTosShTQglaswdpwQ6LNdR3Wu+cG143oQGc0lbfUJYoeb0KJ53W7xtgcLkn0oNfjPmwJY+SmRpk7
L3PnRfBZctSyxHbvfYAPw+LEDtegClcggXL+quRtVR6n5KlMmJKs8Tgbxo3ks11dd8Pu2AN7hZN5
62m89TTeepraen1y/3B58gDvHYjyv2h5sOshOFTOOwyHh39LHuH5J/Epz4/EUR7/HT4d/lGO/A+Z
5RlWm8pqU1ltKm8/Xb68NXmiz3wefx9+lfyC60k4OVyT/KLrl/Dl8GNRcVryHzz+arhYZJy18zdm
nxEhlyd/GO2bPAdjwrvy6++yY0JjdiwuCttFyXYRcqcI2c5LpvKSqbxkanaq93+F3+BG3IRbotHZ
W3Ebpvn8PV67F/d5Ph33u88Mzx9yfTiMyz6KxzArXJ99PFyuml2Tfcrzp/E7PBNOFVWnqnDX8MCp
PHCq/uB6Ve6a7B/Cr7IL8JzPLfTaSz63yOPFeNnrSzxf6vW33Lfea+/gT15rwDI0ulcTlqPZ51f5
bB6rvVeA7M27p4raU7NrwyKRe6oqeo3oPU30nppd7zU+mOWD2ffBD7Od6AqvZvlhlh9mS+CD2c3o
Qa8M0IdBj4fD4uxWbPP4Q/C5LJ+TFabU8rtaflebDItrK12rwgRZYoIsMaG22vNRskcGfLA2G16t
rcUuHu+K3by+O/bAnl7fK+RV+rxKn6/dx/329Zn9sD8OwIH4mM8e5P1P4GDrH+I1GVY2mlJ7TWgU
4VNrb4hG17J1LVvXsnXtzbgFt3rvrnC5yJ8qU50qU50qU50qC0yVrU6tneE+M+37Yfd8zP1nef44
ZuOJcEl0sCxxsSzx+5HK/PpIPX9TJugQ8dNE9o9F9gJRO0/Uvq3mDojYV0TselHZJBrrReFiUdgs
6v5JZJ0jkuaJmFtFzJsipkOU3CNKmkXBy7z/cd7/Td7/Ku8v/58KJ/L4d6P/lK+etJPfqVjLE/NU
qQVywgteW4jX1bk3vLckrJQ9V6pcr8pZ3SrXAjWw2267VK8FqtcC+WuWnb8pT3XZ+TK5aIld5+Wb
dfLNOjvvkK9zdr5Zzs7J2Tn5ZIndPyMXPCMXPGOX2+3y2+WeR/Vanv0Pmfb8sEAFW6CCLVfBFojN
brHZrYItF59Pis9u8fmk+HxSfD6pgi3PXut71+Fm3BJWyuorZfWVYrNbNVuumi2X4VfK8CvF5pOq
2QKx+aRYeobfP8PPn+HTXepJTj3J8dsuNSXHV7v46RJ+OYtfzuKXs/hiF19bx9fW8bV1fKuLb3Xx
q3X8ah2/WqIW5fjUEhVuAZ96UoVbrnKs5B+z+EcX/1ing1zMD17Gazq0peEFSm9QHZr4wtdk81bZ
vJU/vEPVdqo2UrWRTzwvc6+l7FsydStl36LsW3xjE994XzZulo2bZeNmPvJ3fGRIli3IsgW+spqf
bJRZG2TWBpm1gc+skE1Xy6J5mbNZRmySEZuovoHqG6i9QQZskgGbZMAmGbBJBmyi7AZZr0nWa5Lp
mmS0vCxWkMUKslheFmuQxRpksLwMtloGWy1brZatCrJTQXYqyE4F2alBdmqQnRpkp9WyUkFWKuzM
Sg2yUUE2ystGzazzlszSKrO0stJbLPSW7LJWdlkrg6yVLVpli1aZoVVmaJUZWlmqkaUaWapRVlgr
A7SyVCNLNYr8VpZ6S+Q3ifgmEd8k4ptEfJOIbxLxDaK9QbQXRHtBtBdEe4NoL4j2VlZsFOWtorxV
lLeK8lYzcafuuNxXHx8+iE4QZeU56+ciarqImi6iXmfnKaJmK7vOZtc6dq0TLUV2Xc+uc9l0LpvO
FRHDomCYLaawxRQRMMweU3j8MC+fzsun8/LpbDGFlw/z8mFePp2XT+fNW+k1l05zefNWWs2l1Xpa
refVW+m1nidvpU8dferoU0ef9bx5K2/eSqM6GtXRZy7vHea903nuVmeuc8Y3wq08dsgJFnu2xd4H
wlN8c220v5Nt8Wyjk3U5WZeT9ThVgzxQdLIGJ2uwuy1212B3DXa3xe4a7GqLHW2xoy476rKjLrvZ
Yjdb7KbLbrrspsEuyrNsV3SQlQastNpKG6200UqdNCzPqI1W67dao9UarTZgtUarNVptwGqNtOij
RZ9VB2jRZ+UBK2+08kYrb6RFn9UHrD5g9Y1W32j1RquX58ONZoS18uWW8K5Tv2vlfiu2ymULZdxV
Mm55Pnh+JOOmfKp/5wxV3Pn/MB2TPDv63Ihy7d5p9U77yLPybLd9RMeqnd/q86zk/ivdv1c3nNfT
lii8zTkzlIhQpSdNIY2DPT8CM0OPe6wdsUyTT7eoIuU99kdHuMeb3nmBfn3u9aJPvP+X+X6k3kTy
SxrVyIQXnepMpzmXjn10XEvHtXQsz9dr6ddnDy/aw5v28KY9vEnLv527D8CBH5m/D/b5w8TiEa4z
ff5hr5Vn7gpnjqN97K/XnnrtaZM9bdr5E5zNdt9lX5vta7N9bLaPzfaw2dq91u61dq91N1l3k3U3
WW+T9TZZa7N1eq2xKTrM3V9y+j86+VsfybI5Oj9jpcGRrJoZ+U2R63bacrXTjyn/Rs9fso8Tv2XV
l6z6klVf+p9mnnKmOdjnylnmCNdyxpjps/81Y4waqaJb9AFbzdYpdv1euGjnb3e8a+UfjPzG6Ofs
e61PPs9qDeaClfb/CpXmfSSDlCtDnlIz2bpcd9+n1kxqzXSeV9z1Zneby4oNereVFJxJwZks2UDF
mSIiLyLyLNrgfK+IirwzrnXGtc64llUb9GAr9WAr9Vsr/0vmyLNyAys3/DVzHOweh4WZzv6Kc69l
5YaR7HEA1Vuo3jLy04gBWWRreMOuuynfYsfddlz+GU43tVuo3WKX3XbYTeUWKrdQuYXKLVRuoXIL
hVus1E3hFuq2ULeFui3UbRFVA7LuNtWP9/CwgfBKlFAFt+mUtkZJ3chSz3o964gO9iw2wwzrT2L9
SaxSDqmUQyrl0M6fERb1LD36+GEVr6jSFVW6IZVuSL8+rNoV9ejD+opYTz6sug2pbkOq25C+e1jf
PayyDalsQ/qOWGUr6j1ilWZIpRlSXYaiUWr5Vjt5UO2O1exyX/e+VWMWfIwFHxvJKqNU+/7kXjLJ
p0PJCbp8qpQ8IdpVhjHzRMdaJx9Vus8G9yn/zHW4fAInzo78BKFY/jwl9hJPJ4Rhr5d/KusTvrcu
2tuz8un7nb7f6ftHTv5DvcI5YcVHTt7v5P0jp250bcJytKAVTudk/U7W72T90Sestoy+A/RdRd9V
H53MrV2yykbaDlhhoxU2/nUaf3bkJ34baTtA21W0HfibCX2V5/mRnwKOTOq0XWX1jbRd9dFpPapw
8oHosGStR3uFh3VLsW4p1i3F9vScPT1HrQEdU5eOqfzTtW46bdIZxSzwAQs8zQJPmyP3MEeWfzuy
3PV06Xq67Os53U2X7qZLd9Olu+nSzXTpZrrs5zmdTJcuJran53QUXTqKLh1Fl26iK0rbze+tvMWK
w1bcYrWtVnvHau9Eh3r3Pbp12ONqe1ztk4M7f4b93y10gs7uZH79VTrMCh003EbDbX+10rNeq/N8
oetLOq2lrh+12irP8/iL9db4TLvPrwur/8aKo6nWTrV2qrVTqp1S7fbdtvNnUu0UaadIOzXaqdFO
jXZqtFOjnRrtlGinRDsV2qnQToV2KrRH+zvnGmdc44xrnHGzM+acsdkZm52xWada9rpm52nWVRZ1
lUVnWaOzLHtgs7M0O0uzTrLoHM3O0ewca5xhjTM0O0OzMzSP/F+UhyZ/Eh0aTY/OC/dH5+OnuCQ8
El0Z7ogm4SpMxtVYH6ZHG7ARfT6zNdwebcN2fIAPw+0VnwqNFUfiKByNv8On8Rkcg8/iWHwOx+F4
nIAT8Xn8Pb6Ak3Ayvogv4cv4Cv4BX8XX8I84Bf+EU/HPOA1fx7/gG/hXnI4z8E2MifapeDW8UvFa
eL7idbyBJXgTS8PiirfwNurxTlhc+XC4o/IRPIoGz5fhXThr5Q6EcHvVbuH+qj3C9CpddpUuu0qX
XbUP9sV+aA93VJV8phs94Y7UkTgRF4b7U+PwC/wSE8IjqctA99S00JhqDItTJp70EWFx+pP4VHg+
fSQ+h+M8/yJ+GKanf4Rzwu3p+zAL7Z6/h3Vgs3RXeCRdxGbv9Xs+GG6vToTG6iQqUYUUdIrVOsXq
UcigBlnUYhfsit2wO/bAnvhCWFx9En7i8U9dp7g+4TonPF89EBpHudeoPfXHP472CMuiPSH7RXtj
NPbBJ/EpHImjcDS+gX/F6TgD38S3cCa+je/gLPwA54UHee6DPPdBnnt1dGmYGU3AZbgcV+DKMIc3
z+HNc3jzHN48p/KmsKzyZtyCW3EbpuF23IE7cRfuxj24Fw/73iN4NMxh9QerVoVlVa1Ygza0e/19
1w6UvN+NHq99GJalUkhjFDLYF/vhcBwBOqTowDvmpI53PdH1ZNd/xo9xDn6Cf8eF4UGe8yDPeZDn
PMhzruY5V6ecN+W8PGhO9S/L2kR3hMboTtyFu3EP7sVsPIE5eBJPoR7v4E9owDK8i0Y0YTmakcMK
5LE+PCsnPCsnPCsnvB1tQT8GMIghbA3z5Il58sQ8eWKePDGvsjM0VnahiE0owXRSGWMzetCLPphY
KvtR/t4OhDBPvD2blgvSYj8t1tNiPS3O02eEt9Pfdf0efugzP8I5YV76555figm4HFfgKlyPGyDe
0jRK0yhNozSNxNO89G9dZ7nOc30JdEjTIU2HNB3E2rNi7Vmx9qxYe1asvS3W3k5vQgmbfbff6/QQ
d/MqPhNVRrtHVUiV//2P8j9kgFEo//XuGmTLf2ISu+CkaHR0Ms4Lk/j4JD4+iY9P4ONj+fhYPj6W
j4/l42Ojie5wZRjHz8fx83H8fBw/Hxf9Oto1uhbX4XrcgN/gRtyEm3ELFkYfj17E+nAli17Joley
6N0sOodF57DoHBadw6JzovJfkN4aJrPqZFadzKqTWXVyxQNhRcUMPIiH8DAewaP4LR7DLDyO2XgC
c/AknsLT+B2ewVzMw3z8Hs+iDn8IKxKfjXZNHBuNThzv+hWcFiYlvh4uSXwDZ3o+JkxNjA0XJn6O
C8OFerZvJH8ULtW3fSP5E9dLQ31yQmhKNkZVyaZor2SzrneFqXxllEmuD3OSG/QiG6NPJd937Sj/
bSDXTdEelZdGu1dOwGW4HFdgIq7EJFyFybga1+DhME6+GCdfjKtcHu1a2YwcVmAlViGP1SigBa1Y
A3ry9sm8fbJcM6lq97CC118px4yr2hRl5JdJ8ssk+WVc1fZo91QSfCu1B/bEoTgyjEsd5XosjotG
yynjUp/3+MIwSf6YJH9Mkj8myR8T5I8J8sdY+WNsii+lrgRfSt0fVqQeGPk/6FekP4aP4yB8Asfi
jDBHpF0p0q4UaZPT46Nd0xdjCqbiDtzn9YddH40+Lpomp5/2uN3n38M68DmRc7fIuVvkzBE5c9Ld
0ah0jM0+3+99/ieCJqeHol2r9worqvfGaOyDfbEf9scBOBD2Wm2v1fZaba/VB+MQHIrDcDjOda/z
cD4me341rgkrRlWEFZmzwyWZH2JyuDBzDcRNRtxkxE1G3GTETUbcZG7FbZiG2+G8mTtxF+7GPbgX
92E67scDmIEHMRMPgT6ZR/AofovHMCvatWYSrsJkXI1rQNsa2tb8CuK7RnzXiO8a8V1jnzX2WWOf
NfZZY5819lljnzX2WWOfNfZZY4819lhjjzX2WGOPNfZYY4819pg9Otp1l1HIoKb8LyEn3xUp62Wj
8qPy3x7ZJ3G5bJYd+dcFUkijGqOQKf8DOCP/DE75L9hny/8ghw6goAMo6AAKOoCCDqCgAyjoAAo6
gIIOoKADKOgACjLfnjLfnjqBok6gqBMo6gSKOoGiTqCoEyjqBIo6gaJOoKgTKMqSF8iSF8iSF0Q/
C3E0BmPxc1yIcfgFfomLMB4X45IwRka9SEa9SEa9SEa9SEa9SDY9RTY9RTY9RTY9RTY9RTbNyKYZ
2TQjm2Zk04xsmpFNM7JpRjbNyKYZdbdV3W1Vd1vV3VZ1t1XdbVV3W6Pyzzvm4Ek8hYXRfjLvfupv
rP7G6m+s/sbqb6z+xupvrP7G6m+s/sbqb6z+xupvLFuPl63Hy9bjow6zbCe6UMQmlNCNGJvRg170
hftk9tky+2yZfbbMPltmny2rT5TVJ8rqE2X1ibL6RD19Xk+f19Pn9fR5PX1eT5/X0+f19Hk9fV5P
n9fT5/X0eT19Xk+f19Pn9fR5PX1eT5/X0+f19Hk9fV5Pn9fT5/X0eT19Xk+f19Pn9fR5PX1eT5/X
0+f19Hk9fV5Pn9fT5/X0eT19Xk+f19Pn9fT5im9FoyvOxLfxHXwXD4ScSpRTiXIqUU4lyqlEOZUo
pxLlVKKcSpRTiXIqUU4lyqlEOZUopxLlVKKcSpRTiXIqUU4lyqlEOZUopxLlVKKcSpQzS9SZJRaZ
JRaZJRaZJRaZJRaZJerMEnVmiTqzRJ1Zoq7iT1GmogHL8G6UUcWyqlhWFcsmTir/P6qu/+h6WrhG
NTtDNTtjpJr9KJQS52GM6vaRqpYYF0oq25dUtrEq25dUtrFm8WnJS8IzyZfC68mXo12Sr6l+75rn
m8zpzdE+qlxRlUsmV5nv/1zpqlS6w0b+xmTR65tUnkujrCqXVeWyqlxWlcuqcllVLqvKZVW5rCqX
VeWyqlxWJ13USRd10kWddFEnXdRJF3XSRZ10USdd1EkXddJFnXRRJ12svC/EldNxPx7ADDyImXgI
D4dTVM5TVM5TzF115q46c1edKppRRTOqaEYVzaiiGVU0o4pmVNGMKppRRTOqaEYVzegzY31mrM+M
9ZmxPjPWZ8b6zFifGeszY31mrM+M9ZmxPjOuHAilykEMYRhbsQ3b8QHEhMo8UWWeqDJfoDLnVObx
5r+8+S9v/sub//Lmv7z5L29KKJgSCqaEoimhoIKfUrUhxCaFgkmhoJJfoJJfUGVPVfakop+iomdN
DYWqHZ6HEKciVCCBZJRV6bMmioKJomCiKJgoCip/VuXPmiwKJotC6kCf/RgO9drhnh8BudaUUdAZ
nKIzyKY+630+qDvY09RR0CGcokPImjwKJo+CyaNg8iiYPAomj4LO4QKdwwU6hwt0Dhek5NGUPJqS
R1OX4FJMCGN0E2N0ExfpJi7SRZxins3rJHI6iVzqoZG/yDQ6NR9/GPmrTKNTb7o2hjpdRi7Flube
fGooGq3jyOk4cjqOnI4jZxauMwvXmYUXmYUX6UBy5uFF5uG69MlRxkxcZy6IzQWxuSA2F8TmglZd
ymxzQWwuiHUr43Ur49P/FkrpH+OcMNF8EKcv9FhMpX+BX+IijHfPi+FcZodWs0NsdojNDrEOJ6PD
yZghYjNEnL7J528e+auCsa4nY56IzROxeSI2T8S6oIm6oIwuaD9zRawTmqgTypgtYrNFbLaIzRax
2SI2W8Q6pPE6pPE6pPE6pPHpDe69Ee9Drk/L9bqm+3RN9+maZuuaZuuWJuqWxuuWZuuWJuqWMmb9
vFk/b9bPm/XzZv28WT9v1s+b9fNm/bxZP2/Wz5v182b9vFk/b9bPm/XzZv28WT+v68rpunK6rpyu
K6fryum6crqunK4rp+vK6bpyuq6criun68rpunK6rpyuK6fryum6ctWfs6fj8IVQV30SfuLe53p+
Hs7HT712gevPMAZj8ctQ1KHldGg5HVqueorvTPP6Ez47JyyqftLjpzAQ8qOiaLQOLjfK2UbtGepG
7R1lMt8J6zPfxVk4O5yhszsj828eXxFKmYmYhL90elM9vg43RFkdX1bHl9XxZXV8WR1fVseX1fFl
dXxZHV9Wx5fV8WV1fFkdX1bHl9XxZXV8WR1fVseX1fFldXxZHV9Wx5fV8WV1fFkdX1bHl9XxZXV8
WR1f9v9jx5f9m45v7+i28MWKc6LTK/49+k7Ff0RXVPxn9E8V50ZfrDgv+n7itOjsxJjorOT3wteS
Z4evJl8Ms5Mvh9OT68LbesO9kjJc8v1wR7IzLE12RQcki+atTWEwOii6bccb0dNhebQkLHf3L+/8
a7AnuvvR7n60u/9DxZgwqLZutIppzlT2vXCSVb5klQnJReGl5GK8vKOUfDUsUONWJV8PbybfCLdZ
/VorDyc3hg6rn2T1aVZPWv0hq78RVSeXhVnJRnsyySeXh3OTzWFhMudbK0OLqrhGn/p0+KO9/dEn
f6B2LvPp+3x6UnL5jh0+/ahPf10dXeAbl/vGAyN/2/EYu52smn9M9f564nSVfEwYk/hFlEw8pU9+
I/xnYmmYnlgbnZAYUJH3inZNHhMeTy6Ksqr0MU7weystNY8mk8vNmivCH1TpKnff4UQ5lXrSzkqd
3DmTJp2sI9nlVEWvbwrdFd+PKsPCqAoppFGNUcigBlnUYhfsGl6KdsNJoSU6Gb8O86NrcR2uxw34
DW7ETbgZt+A2Gi4MTdGLoakiEVoqkqhEFVJIoxqjkEENarEbdsce2BN7YW+Mxj7YF/vh4zgIn8DB
OASH4jAcjiPwSXwrrKk4E9/Gd/BdTMbVuAZTMBW/wq9xLa7D9bgBv8HtYXXFHbgTd+Fu3IN7cV9Y
nfhsmJ84Hl/BmeGFxI2hkLgpFHj591ilxM8+4GPzWaLEx77Jxz5IDu7oTA6JiOGQTm7dMZTctqMl
uT2kkh/s6Eh+GL6S3OH1EParrNrRWZkKX6tMh3Rl9Y6hylE7WiozIVVZs6OjMhu+Ulnr9V187tKw
sHICLsPluAITcSUm4SpMxtW4Br8NLZWPYRYex2w8gTl4Ek/hafwOz2Au5mE+fo9nUYc/YAFeCGsq
F+JFvIRFWIyX8QpexWt4HW9gCZaH+ZXNyGEFVmIV8liNAlrQijVhftX2sDCVBP9NVYWXUnu47olD
cRSOxXGhJfV511vCmtS9mO65c6Ye99h5Us6Tcp6U86TmeW0+nkUdnsdCr7+Il7AI9p6y91S9x+/g
Tx43YBnexUqsCqtTBe91YBN60Yct6McAhsKa9C7YFbthd+wbVqf3w/44AAfi+NCS/jzGh/npizEF
U3EHHsajoSn9tOtQmF/9ybCm+ujQUv0Z18+6noFvevyDsLr6XO+fh/Nxo9ene/1+PIAZeBrbw+pR
UVgzandX8TVKXI3aHweGlsy5oZAZiwvxC1yESyHeM+I9I94z4j0j3jPiPXMrbsM03A77zdyJu3A3
7sG9uA/TcT8ewAw8iJl4CM6YeQSP4rd4DLPC/Jp/CYWab+BfcTrOwDfxLZyJSeGFmqswGVfjGkzB
VPwKv8a1uA7X4wb8BjfiJtyMW3ArbsM03I47cRfuxj24F/dhOu4PL2SPDvN3GRVe2CWDmvBCVKlW
zJf5i8kV0Wfk5Q+ie6Irw4xoEq7CZFyNraFgfi6Ynwvm54L5uWB+js3Psfk5Nj/H5ufY/Bybn2Pz
c2x+js3Psfk5Nj/H5ufY/Bybn2Pzc2x+js3Psfk5Nj/H5ufY/Bybn2Pzc2x+js3Psfk5Nj/H5ufY
/Bybn2Pzc2x+js3Psfk5Nj/H5ufY/Bybn2Pzc1z+K1wVf7TPpaFkZi2ZWUtm1pKZtWQOnW4OnW7u
bDZ3Nps7mxOzQufI70f++beO3ksMhfdUs7wqNiP5bnSQetmugt1ihpthhpthhpthhiuZ4UpmuPL8
VDA/FcxPBTNTbGaKzUyxmSk2M8VmptiMNMMcNMOcMsNMMsMMMcMMEZsRSmaD2BxQMgeU0keFQvro
kb/HWdL7l3v5gj67oLcu6IULeuCC/jfW/8b631j/G+t/Y/1vrP+N9b+x/jfW/8b631j/G+t/Y/1v
rP+N9b+x/jfW/8b61ZJ+taRfjfWopeoJ7j3F4yfKfzUtxPrNWL9ZGrWXeDo7TNdjTtdTNuspm7OT
Q+d/o+474Ksotv/PlLuz997dJIQQkgAhdLACD1FRBBUrIPoUC11FsYD6aCJSLE9FREFU0CcKCupT
fOizgAKCDRULRaogLQFCDyXUhMz/O3NvYkICKfD099/9zN7ZKWfOzpz5zpyZ3XO9YXDD9RY/QW/w
q8AlwtWES4N7FOGT9QbiGFXex7iOeZyYSeeLWdRVzKVm4ktKQv3OEF9jJvUNNRAL6BrU9TXQ6wOY
MVwE3T5eLKWmqPd1mDmkYp6TjtAMOg3zhWswX6gvttDloPt1dC37dJT0lZ6K9C/YMj9E3D2YVcyi
GITNx91CY5eyuC1ddje1KtmeLvhpgt5xIUpth/HwKvAQCWmC0fIgQi/BaDkLo+U2a6N4u/k3SoRW
x91Fdk2xKtLWAw/mvwg205lIcRbuFlIrPGEC4lLxrMbq2836F9GfWoD/r2VLzNc4Qn7A3U9IjbEJ
c8Is3K3BXW/ycXcEdz9QA5LUigJwDpyCc+GCcCG4MJwH58PFoMSOVEV0whyvG1xvPNMszAO/xDzz
K71Y9qdWcgDcQLgH4QbBPQQ3GO5huCFwQ+GGwQ2nVtDlW0FnbwWdvRV09FbQ0VtBJ28F/bsVdO9W
0Ldb2f+/8DG7zUZJa/AUm8VctKT5N5Ov9HTMbrfj2fujTmaCry+QCk+LZ/cpni2iOmwxNUbNdEM9
XCo6IVVn6iy6WRtznUVv/ZWxSiQG6nQxjpqL8XQuytmFlq6Hmcw0eT41lS2oMWqrM6UiRyrKaYbW
7E9pKGmnKd+W5Ef/1+R70QW5uyJ9D/zeit/+kLBF+jfMkXdgfnzYys9ycpFLkGP+CQWpE5EyESmD
SLkLKbIokTKAophD0SbMm/qiJNOmA/USzLt3oNVjgbiLLb2laMFlyAWaZkYciNe50OFzocPnQkfO
hY6cCx05FzpyLnTfXJTZUW8xXzyB4mnoKcpSW6azqWqRMrsAs3rA9cGz9cdMfKHeA+6y8By7IHFV
UPZ+5JqHcsMo91Cp5YZRbrr5bxZQi0e5AVDcD4o7QDEbFIOgtif6FLnoZx0RauwFdsFMvgdcX8T0
p2TkDIJjBzkPIGcucvrgJc/UGnLmoFdk0BW0EW4T3GFI9hG4HLhcuKNAh47QXG7WjUUXoEVX6i56
4PdW/PaB7tMX/AzUk8UQyMU4Og/ycCFqfBFKbGHb5lf9mi1tqV6OPpcALedIVEaaStCWeXCaGgTi
6QrVCa4zXDdqoMbDTYFbj/sNcOlw4FNlISwbvwfAm7H/mAXODuOZD4Oz0/Dch8HZaXjuFDy3QQwX
zxvCs2aKFRRnpW42cnyNHBuRIwU5NiJHCnKch9Rx4HmzlbxfdQ74PoScG22upfZ/CTqhvM6Q5G74
7Y7fAUDFdKoNxMsCxoSAjMlAxkrAu9n2H3VM+61CKoGQLLRDR/hutn3DWMNLFP0gVQ9ivNsMvreg
xK16l5W39ci3EflCoO6CMkfMKkqmnnoP3QF3J1w/tH5HtGcn8NUNbgAk06TOgJRsRk1ngqet0C+3
gcp2jJMtqWogTu8J7IDbqfc4veH6wN0Hdz/cALiBoBsT/U+glaC8CpRXiX54qgHA/HS0YwakaCN6
kH1a4PAW1NFW/bPVxauCvxzwlwP+cqJPb9aU14LKWlDhoHIaeIwDlYOgkgcqxtK8CwobzP8Rgb8c
8JcD/nLAXw74ywF/OeAvh86kntSO7oC7E24wtaGH4YbADYUbRm1QYixKPAOYFUANXwfMCqCWrwNm
vYOa/gg1/QXk9HvI6VWQ03biPf08nuknjBD1I9xg3DLcbMFs4nxqARltIVvqlXIitZGT4N6gNoE4
ahdYj98d+N0Jt5vaOI3gmsP1pnZOH7j74O6HM/y54OpAVG54VG64bStTg1t1pl2NmAa+346mSoym
SgTfu5CyqV2B2KqXQDJ6530DXXAndL/10PV2QrdbLxvmbYKs9c7bhdAshGTJhvoiUO2dt1YcQD3n
IHcusOGoXiAD+iD0wkMyrLORcgFSXm7zfoXYxQhZjJCQzbtLHEF5OaiVo3oZdMw8GSQHefOQahl0
yTykbAVc6p23GaXkQUvNBmc7xGH85qDUXEhmJGcuSs2DdpoNjndIF78hcBFGeIRSLp5gP6SuN/Ta
g8RAJQtU8kBFg8IWW7ZDDLmzkDsPuTVybony0MjUU94Y8JCO3HWQezVyHxBH0GMN97mQ46OQuDzM
E7Q+Cl7SQa0OqK0GtQMyqJfapwqjnT2Kg6a8DZSPgqf/mFFUc1A8BD7WiDziyHUIZa+RPvwNdS2T
Im8hUmSiPFNTq5AiEzRNLa0Cjd2o3WPaC60fbSfkLqV9bFrbLkhbSnvgGU+yHYCn5ax/oMwprnc8
43Hq28aUWM8UIxMoKKuAvyQKyRRQq4Y81TFnqAF/KuJqIq424urivh7i6iOuAcYDKRNRQjXEpuG3
HtrEkwm4gw4hq6L8FJRQDSUZWqkIr4nwWgivi/B6CAcdtIJJbUquFk1hSjK04sEXR+wmmYiQqnBJ
lAr+4pFyE2imgj8O/jhybZJpiK8FVxvhdZGmHsLqw9/A/Cs5qKwBr+YJuUwGrykUiFIxudeAf/OE
XNZBXF3ERXJzPG8CXBXIXiJ4TgLdFDxLNbR+dZRVwzwX4msiPg3xtRFfF2H1EF8f8Q3wfHgKtE0V
0E1EaFW4JL0cPOShdtJldbRlDTxzKtLURJo0xNeCq400dZCmLtLUR5oGGNlMO3m2XpMoAXyYGjsE
PhLARxh8eLZua+O+rq3BQ+AhATyETauQsM+eEq3nCPem9oR97kiOrCjXnGIrKhPotbtQf8fIBXr7
2eSXVzaQqzGp48kHYutR5VMlI6B2Bp66gnKC3A2p0snKCqicb57o1MgLWuJH244Vkhk7NvjllRuL
6g3FgbytQNIeQJzqQLX24kheFlDtMpGbtw3o0xOolgZUayEDeVuBqD2ARtWBau1lMC8LqHaZDOdt
AzL1BKqlAdVayIS8A6iRM1EjjVAjjWQS7pP1GaiRGHDVBLVSH7VST6YivCbSpSFNLbjauK+DdHWR
rh7S1Ue6BpCaIDQ3DzpXK2H+1+cbqozZbgJmunUxqzgPc4V5mO3F2v8Wmsm60QWsB13ObqVn2G34
vR2ae0c9QdwIXeQmPRMzjwn2n+oanSDVPJvK/AfSChuaf/dhwR2HJj+Hfak/tD7z73bp8MVCSz6T
iFpAJz2NLsbZmNrS9dSEbqSbEHoL5nIX0l00iq6m5+g9up9m0hzcfYnzefqRltNYWolzIq2BdjKJ
MkHxXVaNVaNfWSo7k5awdqw9ZbAO7AbaxDqxLrSddWfdaRe7lfWkLNab3Uf72AD2Mh1g/8KZwibg
rMZex1mdvcveYzXYl2whq8kb86bsbN6Mn8ua8ha8BWvOL+Kt2Ln8Ut6Gnc8v55ezC/iVvC27kLfn
7Vlrfh2/nl3Mb+Q3sza8M+/MruDdeXd2Je/J72BX8V68F2vL7+b3sXa8Lx/I/s4H8afYTfxp/izr
xUfzcaw3f5m/wvrzKfy/bCD/mM9j/+Tf8+VsPF/JM9g7fCvfzj7mWXw3m8738oPsM36Y57A5XAti
XwkuBPtGKOGzeSJWxLOfRYJIYItEokhhi0UtUZstF3VFPbZSNBCN2CpxhjiTrRFni7PZOtFENGXr
RTPRnKWLFuICtkm0FBexTNFatGZbxSXiErZNtBFt2HbRXnRgO8QN4maWJTqJ21m26C36sDzRVzzI
SQwRQ7gjholhXIlxYjx3xTQxjYfEJ+ITHhYzxAzuic/FN9wXC8QKniTSxXZeWxwQmp8hAzKGN5cJ
siFvLVvKlryj7C+f4jfKkfJTfo/8TM7h4+QvciF/Tf4qN/FJcovU/JNAKBDiPwe8gMd/CcQF4vmC
wJLAb3xx4PfAer4ykBHI4GsCmwOb+drAlsBWvi6wPbCbbwjsDezlmYH9gYN8S+Bw4DDfHsgJ5PAd
gaNOgO90lBPDDzhxThzPc+KdKlw7SU6qEE4t528i5JzjnCNqOOc6V4hUp4PTUZztdHUeE82dfzpP
ii7O084zorsz2hktbnOed8aK252XnJfEHc54Z4K405nkTBK9ncnOZNHHect5S9znTHU+Fvc7053Z
YpAz1/laDHe+c74XjzvznWXiCWeFs1KMdVY5q8SLzlpnnXjJyXS2ifHOHidXvKpIcfGOUipNvKfq
q2biW3W+aimWqNaqtVipLlVXiN/U1eoasVZdp64TGeoGdYPYqG5UN4pNqpPqLjar21VPsUPdre4W
u9S9apDIUoPVMHFUPaIelVw9qZ6SUo1Uz0hHjVYvS1f9S/1LxqsJaoKsrF5XE2WCmqKmyEQ1Vc2S
VdU3ar5sqBar5fJstVrtleeobHVEtle5Sssb3PpufXmz29A9Td7inuWeLbu4zdxmspt7vttCdncv
dFvKW93Wbmt5u3ule7Xs6bZz28le7jVuB3mXe73bUd7j3uLeIvu4t7u95H3u/e4/ZD93sDtYDnSH
ukPlg+4j7mNykPuU+7R82H3GHSWHuaPd0fIRd6w7Vj7qjnNflY+577j/liPcqe5UOdKd5k6Tz7h7
3X1ylLvf3S+fcw+5h+ToIIBPjgnKoJRjgyoYki8EvWBVOT6YHEyWk4PVgqlySjAtmCb/Hbo+1Em+
G+oR6iH/G+oZ6ik/Ct0Vult+HLo3dK/8NNQndJ+cHnog9ID8LDQwNFB+HhocGixnhoaEhstZoadC
78u5oS9DP8hNoWWh3+Wu0NrQJnkgdDicIvPCdcJjAmnhseE3As+Fp4fnBF4PLwzvDbzjKS8p8JN3
undZYI13s3dX4JB3r/eAE/T6ev2dWG+gN8iJ9wZ7g50q3hDvCSfRG+E956R5Y7wxTgNvrPei09Ab
501yTvfe9N50mntTvPedc70PvE+c1t4Mb5ZzufeF94XT1pvrzXXaeV95PzjtvZ+9X52O3lJvqdPF
W+6tdLp6q7x1Tg9vg7fbudPb5x1yBnpHvFxniJfnkzPc5z53HvOl7ziP+67vO0/6cX6iM8pP8pOc
F/wUv7rzop/q13XG+/X9+s7r/nB/uDPRf9R/wpnkj/Cfdd7yn/dfcKb6L/njnGn+K/4rzof+q/6r
zn/91/w3nI/8yf47zowYHhPjzI6Jj6nqzI+pFlPDWRhzMOaI8yvxEObvRN4lla6lhpRGp+jQM3WG
3kyN9Rb4V5eYIk+/qj/AmaVH4u5a3Rl55sG3JRq/RW/DdUP07kCx/CZ2m87G+UecKqGcfXAvlsrv
w3BfFAlZixISTSnHPaB5Id1vOgd+DyN5F/Jxn1GUx/ynKaHMn/V6vUv/AgrpeNrM0ngsw+GC6rgo
9Y16h56nN0Xv9hYrfTvcGr1OL9GH9NUURN2dRrUKxeeVVpjej7bLBoU/OEf9Y8YSiX1Lv0UeXEEb
HpN7J9wmvQo01uI2gHlWfboIvpo29lu9QC+H/EB2oLeXXP57+k39On5HwLXSZ+kBuj98heox/+nh
21Esd57+TmdCgr7TP4EPtIOpvaK5CtL+XEpVEPRUohjrey4asgu0f8mXzcJSEQ3JxpPvRd2v1vsw
349FUDO0QkHperttoe35qYvl36G3oo/tyq9xszJqf38vnKY0vqPpVhW5+0eRux/KRgNHE5s+Kml6
BdrP1StKKflgob7dhM4rJfX7+t+mR+vvysxT0fybjXQYmS0Ws6wMufFk+knrm35sf9a3lSE/ZER/
YnFrrWm38h76XYum76Jeix9umShk6ZkWNcsoFyVQ2Ft2qSohdxRh9a8Vyv2hva4wyHHKj7+VofzN
kbFM50CO9pW7BO+EsQ3g/m5LyR/xNkTOaHzNEvI0wlkTZ6MiXL4d/V0YOU+Qv0mJ+aO1CynZD3Ta
fzyGgZ879R4g2Hrbp4xUH7LhL9joVP2lnqOXmhH9OPlzC/mfoWTg/03UwfSQaNgajA2zimNxQZ6c
Qv4xGHli6SrqAf+0aFgGam/x8UfV/PKtRL+C/EGgT98okpvwj/QHJPSM4+Y/VgoDmD31Qviz0fgf
9Peo/x+jd8Xx+0gh/0jkTqb2ZGZCraJhX+jPQeE/xy1/Y8nheWgxg4/6On2N7qk7RFNPLJb/MaDY
W/o/epFeWiiYU1d6nEbB9xyNNt/M0PuQ3Gk0A7PDWTSHmtpVheb0DS2nc+k32kRtKZMxupn1YD2o
HzT6v1N/o8vTQKPF04P8Ht6HHoI+vpKG8tU8g4bxLXwLPcW38e00wujmNJIf4AdpFM/hOfSc0c1p
tNHN6Xno5mF6QdQUNell0UV0pVdED3ErvSqny+lktFpNrwfiA/H0s/Op8yn94nzhzKEFzmrnd1rk
aEfTr0anoyVGp6OV6lp1Ha0xOh2tg053E603Oh2lG52OthidjrYZnY62G52ODhudjvKg0z3DCNrc
88xRL6iXWdDodCzW6HQszuh0rJKarKawykanY1WMTsfqQ6fby86ENqdZB1e4AdbZdd0Q6+Z6bgy7
1a3kVmY93SpuVdbLTXGrs3vcVDeN9XHruPXYA+5FbivWD1rbHWwAtLMRbBC0s2fYYKN/sYeNTsSG
GJ2IDQ0/HB7DHjWaDhvvxXlJbJb3vvc++9bL8HazeUbXYEuMrsF+M7oG+93oGmyd0TXYeqNrsAyj
a7CtRtdgu42uwfYYXYNlG12D5Rg9guUaPYIdNXoE5zHBmDBXMVViqvJQzKGYI9zsKaywEsOsxHBI
zDhoFOPpX5DpV2kKQt7Cqehteg+j1FTIk2PlyYE8zUav+wJSFbJSFYJUzUf4j7SUwrQMJ4eULces
+jf6HbOrNZSOPpYBmatFmbQHPX4vztq0jw5SHTqEsy4dpqNUj/IgkZWsRNawEimsRHpWIj1IZG+K
430gl56Vy3jI5RpK5Gv5WqrM1/ENVJWn83RK4hmQ1+pWXqtZeU2y8lrFymuKldfKXHNNlQWm/5QA
qeW44qAqkF0FPxqfkkUQcpxg5bga5LgL1RddIc0NIM094L8VMt3AynQNyPQaYnKt3ERcbpaZ5Mgt
cheFZZbMplS5Xx6gWHlQ5lJNeRTSX89Kfy0r/TWs9New0l/DSn8NSP+llKDaqDYUVpepy0iqy9Ef
AugPVyOkrWqLkHaqHSnVXrUnV12DflIH/eRa5L0OvSVoe0vYrICQr25Cn4lBn+lMtVQX1ZViVTfV
jeqp7uhFlWwvqmR7EUMvuhe5eqsHkOYfqi9C+ql+xFV/NQClDFQDQflB9LQwetrDyDVEDUH4UDUU
6Yeh7/m27zGznoI0I9TTKHekegaxo9VohIxRY5DrefU80rygxiFkvBoPTl5WLyME/ZNCpn+Czuvq
deSaqCYifLKaDDpT1BSknKqmIuR9NQ15P1AfoB4+VJ+gZj5Vn4PPmWom6mSWmgWuvlHzwO13aj5o
LlaQTLVMQSbVCrUK1FardZSm1qsM1MlGtQVlbVXbqLbarnagJneqXVRXZakslLhb7QXP2SobKfer
/Yg9oA4g/KA6CE4OqcOgf0QdAeUclQPKuSqXKquj6ihKz1N5yKuVNv+v6gaohkETXIEmuAJNcAWa
4Ao0wRVogivQBFegCa5AE2JAk6dwHeGOIG4whaTBFGIGU8gDpgzBdWhoOMUZZCEBZFlOXnhFeCX5
4d/CeynOoAwJgzKUDJTJoMreRm8jJXibvE3ke5u9zZToZXqZiN3ibaEkb6u3lap727yd8O/ydiF9
lpeFNLu93Uizz9sHf7a3n1K8A94BpDnoHUKaI94RxOZ4uRT28jxNSb5RrSsb/MJV+hLXgO9QPFDM
pap+0A9RFT/sh5HS832qDlyrjJAEP5FSDLpRItAtBddqfnWkSfVrUoKf5qeBTi2/Nvx1/DpIX9ev
Cz+wD+HAPoS85r+OUib6k5DrDf8NUJ7sTwHNt/x3qIpBQxIGDSnOoCHFAbH+G0XDMTiFRcMA0PBl
+F8FDgqLgw5Q8H34p9FnuH5OkDag4Zfwfw0MFDQPOCiAg8uAmMuBr8Ku37sWB4XFwSoWBxMtDoYs
Dla1OJhkcTDZ4mCKxUGPxbJY8lkn1gnX3qwPrvezvrj2Z/1xHclGkg+UvI64RckgULInrgYlwxYl
gxYlYywmJvAdfAdVsjgYb3GwMj/Kj1KsRcA4IYWkeGCfC39IhKiS6CQ6UXXR2b7JZrCvhsW+mqKb
6Ibw7vbtNoODNSwO1hS3idupWgEOZpIAAmaTC+zLpZBFvRSLeolm1Rb982J1MXrvJeoSEhbjXHUF
ME4C49rCb9BNWHRzLLolqQ6qA0IMugl1vboe1xtUR6Q0GCctuiVadAtZdEsBuvUgT92mbsP1dnU7
0t+h7sC1l+qFq0E61yJdKIp0/VV/hAwA0jkW41z1kHoIeQerwUifj3TD4Y9g3GPqcfgN0rkW6YRF
upAapUYh17PqOYQY1HMt6nlR1BurxiLcYJ9rsS/Fop6wqCfVa0A9EUW9SWoS/G+oN4Bob6o3kd7g
oLA4mFIIB4XFQRc4OBP+CPbNVl/B/41ahKvBPhfYtwp+g3pVLOolWtQLWdSralEvyaJeskW9FIt6
ntqn9iGXwb5Ei31JFvtSotiXC4wTFuM8l7mMRAStQoNCD1Ew9HDoYVyHhoZSODQc2BQOPRp6FCFP
hJ6goMUpHh4bfoW4RZwEbyewJs7b4+2leIsvcRZZEoAsB+E/5B2mWGBKHvq5wZRKvvAFxQJNFMVY
HIm3OJIABImH3yBIZb+qXxVpDHYk+DX8GgivGcWOWqBgsCPeYkecxY5KFjvigR2vgeZEfyJyTfYn
I/0UoEa8RQ1OvOlus/J67uZLm9PVdPPx5vn/fxx6i95qXPRufUl6l1nnsWt95aW90axwWc37S3u/
Or9Me10U1T53GP3T6qKrdLrOLLqiU3q5+St0+oHyc3hqD90Wmqf5Pa7uXSzHFmja31d8XaaAzo5j
7/Qee42GQ1fMRs2m611wBSt7hTTRhEK5VyHVSjLrHlXhi64w5mvXf9IRKuCmcLke3WLDtpe0uqC3
FV+b03v1Bv0bYortQlT0yF8lL3pn+k9UqgutF4B3UeDfcbxW1uuKr2qeqqPkHZxSc03Rb9jfXLsa
/oNxZn1Ivwvf/GiafMkyPXi/XpgfXq5yNloZTf/j3qyC6TWFUjxr14PMWvk669sIbgojVLR+y9q+
dtU6vfR05T8gaYXo6gM6F+6IWevSR4ukO9G+1P+x40/u82U49ISTyHxtCfTSqSFkMPUkqJ74aEgW
Ww2eWkwt8QA2lHkP8eTHimPoFeGqcN8rY/6P9Bz9YXR/IEFP1HNsaIYZ3QuP3hWaP6wENq6384dM
OzexaGbGJL0ev1OjqXbZ/bYf4ebhzCy6cm2RLJny12a/xVgwXy+Gm4DQq/US/ZMNXxqZRdgd7VvK
z2kxzrcWubNjqP5voZB79GTdRz9tVvl134LQCxD2mel3xXcdyey5Ft8L3aa/xLOsOnU9NV8ezDgG
BMufF86n6P5sYR6AywV7I2aPpRTKv5wqHit6oJZ8+/u82W8uFttff1skbeR3DUa3DCMhFShvmZF6
O9+y9WR8GN/WR2sNV323XmDb+yCJEsYwnxoXo7kL/WBndHdJADnyd50ORmJPfnz7Yx+66H5l/izF
zL3suL0R565ic891du5ZQm9Hbz7F2FXScQyeLSkWn3tsSDT8HyWHU3n20ct96DvLmSHyjsUI/YT9
zbII8LFx8P1bT4/4bFz+/Mzud6KlPq8Adx/pz4CYn0bvvtXvkXk/aIbxwwE5gWLfAiXyZ8FZQN+f
ojgR2T+LKUbze/2pnhulmWDuouFF0EHr8nNr86GX6t8K7vJ1lw3Gl69XRmbiFtHmG/mIvCMS7T97
LSJ31dfau7lkdvMegHsQvjH6ZYx1D0apFHq3BTUwSw+uALe36qH6Td0Hvq/Rq9/UvSw+PIvR6E3U
81w9Qd+FsTXL7AHaJ5upp+lJkZKjo0aK/voYmpl6ObTKSM89p8AXnXfqwxFX9hlzEdrZtr8XvBVU
dJSy43SB5mtnvuvtew+F37g4q+gbK3/WUXQX177BtLN0TuwTFXv/6s84imqyplYhw/tKw0/bOqdM
0y3PUXj+gd5gtKwV+D3OTndBym0nz69+TQ/R/9TjrX8h5P0N86ZMdByKzBf360/g5pxcOZZS48ib
LCdFI0Nvxkhox0e06WbIYcGcO9LqejfmHLtLmgGWu6wKzLkL5f4p0qrgxeDgL9G7ddH+E+X6r+nP
JR36Tn2Hnq2nE7d3Q/VAoHWPyIxAz9CHcDdK/0Ofr+sAR5vpB/XdJ1FWZP6YdlL8RjEpotMWvG/4
RtHYU3noKaeAhpHe5RFUx/y2WOvb+HT96x+j8F97gJvV6HN2zRMybDTFAk0lMtNF7Pdwx3lX9c8+
wO9zhXsu5lcz/0p+jn+gt/U3c6fIm666H2ZHS9H7InFz7XW1/lx31k/DN1r/HgmrYFnfnzy/5Swx
u/B7Xv93j4I57t6Tf7uypHfdT+URmR1i/r0Jo94pWLEo7R3lE+Yto0TpD+za/vaKl1ToSD4lVMp0
YC500jNX/fyp4KSUMqJIh9ntSa/Ln6JWKq2UDMxs/8c95dQdmPVkn7KaiT8JPk5Ff/8T9yMqIo2Y
96RHcka/7MhfF1lg9xkWnDDzfdG0H5a/3D/7qMg3EMVoHHc35AR57Gq9WSmKaMKRFZ2CveDQifRj
u7abTH3IKX+5Nn8FvvLSmXbs+ONbsvw1ubLqdmG6ovyl/qVHYkUzln/nicxbDWZfukCz17PsdSfw
udTdiP9rB+b9+4//zUShdIf+97yU7SgbQlZ0VC/xW6lSy7JvEPzx7aDdsSiQrFCJmfLTmrWq6tQZ
fe4vOIrO3SOoAe2pFJy1OzF/wXqf3nMKaW2g6IpyiV8cNbJfOZkd9IUlxJZG23xHtSE/Z77PrvBv
iIbkl3mBLesYvgrdPfUHzXxezPdaxbgyX2U1Mbs0FdHa9QT9tp5Z8B1Y1GdmBNE1zYUFfDQpxu/b
5S+vSP4KvCmkf7W7Ej8W3Nt3gDDfdMq801eGr/eOU3aJ3yaXkmezXbUyI7nFAnv3LfpeBBlCJ5pf
2hElli4q2/eaJeSvyPsPS8z3ltYdiNzba3TV/MToEH2W6kXfN4J87dGLrZtAVTEn3RrdTVof6dNW
1u4pP6elPEdkh62Qtq576Af1O/p1azeg4J0e3VZ/VE7K3/45M2bD4/HL0Xkl7SpHdhSPCdtT+i5O
RQ/7jkwUmfVezCf2Yn60Uq/6A4n0DoSZPePz9I32/mNIwHLdVc8z93quflF/Z1bMbdwLRWivyQ8v
F0cddB/9qL46emd9kMBe1v+2nqz7Qg4mYLY2EyOvSTFdf6o/iY7aZnU+kRrbPedBurcNi7yP+Drm
1a+Z9jBWEgreAiqyFqQP53/NXy5+X9HvQlf7V/RugS17gsX5BbYOzO7rhzpbf2UTRL7aj75hEJXi
c8pf6l91/E++xi5eyoZ8xIrsO/9VR0X2qdDSO6nQqkOBhYSyjD2Vyby/c731V6dm0D3TbN5NmHVs
sqNJNfqbXoYeas41eq0+H/2lF3k6Mq5H9VT0zohOVTV6/1F0p4JTwRfTNvz9EzyHfbdCD8Y4F12B
1Bfr7nBt9Z1UWUfG4HwbGkPhLtMX6I46+mWD/kH/bt+WMD12G8akDVH99XRqaEfO022qE69ulMzX
G3oyru8W3M80ulyRNytuiHo609/pPGpq7cTUszGFnz2U96sO5x20I+Vsfa/+2Ixheph+3PhAdWSR
YiPvgN1bAX576/vx/PfbGxe+3hY3H7cj9WK0ZWZe5Ev6GdYqSP5ha1b3i9Iog45XYtlbS09TLM8O
+0aAmSdYabLS/C3upY32TjjfMbli6UJwz2lJKXbsOkXt2D1GVzHOqlBPa51ukLVON8JapxvJOrGu
NIbdze6mF61dupfYADaSXmaj2HiaZqzT0UxjnY5mGet0NNtYp6Mv2FdsIc3ljXkTWsCb8ea0yFin
oyW8FW9FS411OlrGr+JtaQXvy/vRKj6IP0S/8zH8BVrLp/AplM7f4dMog0/nM2g7/5x/Tjv5bD6H
dvFv+Tzaw+fz+bSP/8IXUDZfxBfTAb6EL6FDfDlfToeFJ3w6IuJEPOUaC3OkrYU5shbmAqKuqMuU
tTDnWqtyYdFcNGe+tSoXY63KxVmrcvHWnlxl0Ul0Zgmim+jOEs23cizJWH1jKcbqGztLzpBzWCdj
9Y3dZiy9sTuMpTd2ZyAuUIn1CiQEktndxt4buz/we2ADG2jsvbEhxt4bG2rsvbFhxt4be8TYe2NP
BvYHcthTxsYbe87YeGPjjY03NtHYeGOTjI03NsXYeGNTjY03NsfYeGNzjY03tsjp6jzJVhjrbpwZ
625cGutuPGCsu3FlrLtx15nkTOYxxq4bjzd23XhlY9eNVzd23XgdY9eNN3DmOyt5I2PRjZ9vLLrx
Fk6ms51faCy68YuNRTfe3lh049cai278HmPRjT9kvo/jw1zucj7cdVzFH3HDbpg/5sa6cfxxN8FN
4E+4SW4yf9Kt4dbgI9xabm3+tLG4xp8xFtf4KGNxjY92m7hN+PPG7hofa+yu8ReM3TX+ktvavZiP
N3bX+CvG7hqfYOyu8deM3TU+0dhd42+6d7q9+GRjd42/5fZ3+/N/G+tr/F1jfY2/Z6yv8anu0+7T
fJo7yh3FP3BHu2P4h8b6Gv/IWF/jHxvra/xzY32Nz3I/dufw2e6X7hL+g7vcXcF/d39zV/O17ho3
k29wt7r7+A5jlY0fNFbZ+CFXBxk/bKyy8VxjlY0fNVbZBAsmB1OFb+yxicrB2sGGIiF4evAsUS3Y
NNhU1AyeEzxHpAXPDV4gagVbBi8R9YNtgm3EGcHLg1eKM4NXB9uKxsH2wQ6iafCm4M3inOB9wb7i
3FBaqK640Fh3Excb627iKmOtTVxtrLWJB4y1NvGQsdYmHjXW2sTT4RvCt4up5qs9MctYaxPfeMqL
FT8bO21imdfZu0vsNnbaRJ6x0yalsdMmlbHTJkPGTpsMGzttsoqx0yarGzttsoax0ybTjJ02ebo3
xZsqzzB22mQzY6dNtjB22mQrY6dNtjZ22uTFxk6bvMrYaZPXGjtt8jpjp03e4G3w0mUnY2VNdjFW
1mRXY2VN3masrMm7jJU1ea+xsib7xPAYV94X48XEyAEx8TEJcpCxrCYfjjkYc1AOi6VYJocTZ+lA
vRhofLEUR4wq4RQUj3FYUhLG7gBG9XoIr49TUQOMgi6dAZQMAg8vIA94aP7n4SL7DxgGMWMsYsYC
MW9ErptwVgJudgXFbnQ7taaewNCLgaF9MXPoh/MS6k+DqAo9hDORBtMwlDwcCJsEhPUomfkshlLs
F8LVWBww90xgbgOENGQNqTFrxE5D+OnsdPjPABYnWyxuAizugOu1QOTLrL3QZNYVuNzU4nJTi8t/
Ay4PQfhQ9hQ1YyPYCNB8GkhdDUg9mpqzMewlOpeNA2o3sajdxKJ2E4vajYHa78L/HrC7MbB7HsaD
79h3dAH7nv1EF7KfgeYtLZpzoHkzXM8BpjsW0+MspnOL6XEW0xMspl9qMf1si+nnWUyvDkx/l2ry
9/h7VINP5f+hWnwaUL62RfnaFuXTgPKzcf0CWJ9qsb6uxfoawPpfcF0AxE8D4i/CdTFwP9XifqrF
/TrAfY/qCR/oX9+if0OL/g2A/kl0mkgWyXS6SBEp1MaMBPBjJKBGGAka4NpQNEIujAd0hhkPkKuF
aIHrBeICxLYULXG9SFyENBgbcMXYgBDzrfUV9lvrK+331VfY76uvtN9UX45xYjhdJB+R/4+y84GK
6jrb/Z7DnD0HOIAiUURCDCGEIKEECaEELRJCrbGEEmP8rHUGGGYGGIZhmBmGYTjzl9Faa421hlhr
rLHWWmuttdZal7V+1nqty3KNtdbPGGr9rLV+1lprrbHmPvsdYm3Xumvdm6z9zF7v2WefPzNz9u9h
ycMypsNqsZpl6N/Qr2Mf17+pH2GT9G/pN7Jq/dv6r7Mp+s3677Cp+p36H7AcrCg/ZOUiTZRViHWF
1Yh1haliXYFOkCewOfJEeSJ7VqwurByry2mWJP9K/hWbLp+Rz7AM+dfyr5lePiv/hslYdc6j8p78
HioX5AvMIL8vv88UeUweY4/Iv5V/y1LFmsTSxJqEkVfkK2yi/Af5DywTK9MfmU6+Jv8Pjnhd/hOb
JN+Qb7ApYq3CEf8q/5Vly7fl22yW/Df5bzi3O/IdnM/f5b+jf1e+i/4H8gdstvwP+R+Y+T6X2CSe
xPVsNpe5zHRY4QwMiwVXWBpP5iksg6fyVJbEVa6ybJ7G09gsns7TMQaroPir7nwS9s3ij2DfbD4V
43P4NJbJc/mjmDmP5zGRgPo4NJ/nY4Yn+BMYX8ALMP5JXoTxT/On2RRezItRn8FnMD0v4SUsnT/D
SzH/x/jHsG8ZL8Nsz/JnMaacl2PfmXwmU8WKi2M9z59HvYpXY+QL/AXMUMNrmczn8JcwsoE3MAP/
JP8kzvkV/hlcVzN/DfN/jptw9BbeiqO0cQvmsfIuVsvtvIfN4U7uxhE93MvqeD/H04MPcD+bzAf5
IM42wDVcS5CHME+YhzFDhEcwQ5RHWSqP8RiOMsyHMSbO4zgKCIBNEwTAykAAb7AKvoavYTMFB7Cp
4IA3sXWEj7Ac/hbHc4B/lX+V1fANfAPu9ia+Cfp1vpmViwxYjAcrYIZv829Dd3B8SvlOvhP7fpfv
Yi/x7/HvYebd/PvYupfvxb4/5D9EfR/fj5E/5gcw8if8ELb+lB9mlSCMo6j/nP+clYIz/hfGH+fH
UfkF/wVGnuC/xMhRPorz+d/8FMa8y9/FGZ7mv8I5n+Fn2DP81/zX7Hl+lp/FvmAU7HWBX8DM7/P3
sdfv+e8x2xV+FeP/yP+I8X/mf8WY2/w27sbf+N9wbnf4PTZVcAybCY5JQz/dMJFVGDINk9g0Q5Zh
Cqs0ZBty2fOGRw3T2bOgnKdYjaHI8DT7lKHYMIO9YCgxlKDyjOFjbJahzFCGGZ41PIuR5YZyjJlp
mImtFQZ4R7DRx9lzhmpDNY71guEFjK8x1GDrLMMsHEtkCugEM7FywUxQMBMUzAQFM0HBTFAwExTM
BAUzsRzBTGyaYCYomIk9I5gJfTATqxHMxKaKrFpWqsxR5mAvkBMqICeMATlBQU6sUpATex7kBCeg
WBUrmwV+6mEZilPpxRhQFPYFRaEOisLIkBLCPGEljH5EiaAOosL5gKgw/kvKl1iFslpZjb3AVWwm
uGodKm8q+NQpI8pX0f+m8k0ca5uyjX1KkBYqIC2WIkgLCtKCgrSgIC3oH5Q/s08oN5WbOMpflL9g
HlAXKxPUhf6Hyofib28lM/ZSsi5Zx6YKAmPTQGAGqJKssOeS8R8rS05JTkFfTU6HZiRj/U2ekDyB
VSZPTM5EZVLyJFaTnJWcxWYmP5L8CJuVPDl5CupTk6eyiuSc5Bz2TPK05Gno5ybn4iiPJj+KrXnJ
eaiA7dAH2+FMwHZQsB0UbAcF20HBdlCwHRRsBwXbQcF2ULAdFGzHUgTbsU+A7V5lE1IWpCxgPOW1
lNfQX5iyEP3XU15Hf1HKYpYlyA+VZSlbmJTyjZQd6IP/0Af/YQz4D2P+nqpjUqqUmsNeFBTIqhLZ
DYICmSQoEAoKhH5W/Sx7VF2iLmHT1c+pn2MT1aXqUvaYalSN7AnVpJpYvtqitrAktVVtR9+iWjDe
qloxxqbaMKZL7ULfrnazAtWhOjCmR3VijEt1YWuf6mZ5IMt+1H2qD3XwJTSgBqBDqsZy1aAaYo+r
YTWCkVE1ipExdRhHXK5+AZWV6irMDAbFUdaoa6BfVtdizDr1TZzziDqCed5S16P/VfWrGL9B3YD+
19SvYc6N6kZsfVt9mz2lblI3sacFubIikOsWNkP9hvoNVq9uVb+F/nZ1O8Z8W/02tn5X/S50l/o9
VqLuVndj6/fVPdj6Q3UfK1Z/pO5H5cfqj1EB70LBu9CfqofZk+p/qkcw5mfqUVao/lz9OUYeU4/h
KCfUX6Iyqp7CnKBhzH9GPQP9tXoWY86p/4Wt59XzmOc99QL676vvswpQ8m8x20X1IntKsDLLAytH
WG5aNC3G8tOG03CXwM3LWUna59Nwr9JWpq1kj6V9Me2LqLyRtobNSPty2pdZveBpVMDTrETwNMsS
PM0kwdNQ8DQUPM2yBE+zcpBdLfF0A/G0RCSd4OaPiFnwcTrxcTr7D/yfTmQ8l8h4HpFxJpHxfCLj
yUTGU4iMs4mMpz6U3yNTfo9C+T0y5ffIlN+TQvk9MuX3yJTfk0b5PTLl98iU3yNTfk8G5ffIlN+T
Qfk9MuX3fIrye16m/J5JlN/zacrvaaT8nlcov6eJ8ntyQOqp4OY0XRox+lT2nC5HlwOGFqReBVJ/
hVUTi7+qe033H6gLFn9BZ9FZQNgenQfq1fnBzQEQ+fMg8uVsFlj88+h/QfcFjBdE/jyI/E1WCxbf
wOaAwvdAf6D7AavT7dX9BFsFhb9OFP4iUXg9UfhLoPAylkQUnvQQfyeBv18k/v4U+PtlonCRMKSn
hKGJlDA0kRKGHqGEoYnE6J8hRv+49HlpBZstkv3ZgnFSF1w+Q/qu9F32tLQPXP4EEfmTRORPSb+Q
fgH+Fiz+uHRKOoX6r8Dfj1Nq0aPSb6T3QOTvS+9DRYJRCaW6FUuXpP9G5ffS76Ei2y2Pko0KpP+R
rqMv8o0KpT9LN9EXKUdF0gfSPfRF1tFj0n3pQ5ZHiUf5SbokCX2Re1SYJCfJ6Iv0o3xKPypISk1K
RSUD9F9K3F9O3F9B3N+cNC0pF3VB/6VJT4D+P5ZUCPovJfovSypOKka/JKkE+mzSTDYTTuB59KuS
qtgzSR+HHyglP/BsUg38QGnSJ5I+gfmFHyglJ/AaOYGF5AReIyewkDxAA+h/HUsH929kmUT82UT8
04j4q/R7QfwvgPiPsFn6n+lPsDri/vqHMplkymTKoEymSZTJ1EROYB45gTmUz/Qy+YFq+IF3GScP
YJB/Aw/AyQMYyAOkE/0biP6z5UvyJVD+Zfn3qAju50T8U4j45xHxZxLxZxPxT5VvybeggukbiOkN
xPSZxPQNxPQS52B6A9G8gWh+KlF7A/G6gUg9k0h9KtF5A3G5gbg8m7i8ASwO38tLQeScWDyTWLxh
nMIreAXGV/JKjBcs3kAUnmBuA3G2gdh6LrH1PGLrTGLr+cTWk4mtpxBbZxNbTyV6nspX8pVgyi/y
L4ImBT1XEzHX8HV8HeqCmJ8jYp7DN/KN4EjBypV8M1i5hlh5GrHyLL6VbwfHfxuUPI0o+VXi41l8
D9+DvQQlVxIlvwpK3od9fwRWnkasXEWsPIv/Jz+CGX7Gf4bxgpUriZKnESVXESXPIkqu56dAyTVE
yXOIkiuJkmcRJdcSJb9ElPwcf4+/h62CjxNk/By/xm+gIvi4ivi4mvj4VX6f3wehCjKuITKeBTKe
gr5g4lpi4jmGxw1Psjoi43oi49eJjF8kDp5DHPw6cXA9cfA0w/OG56GCgF8iAq43fMLwCcwpEsUy
KEtMpiyxDEoRy6AUMZlSxFIoRayRUsRkShGTDc2GZhxdZInJlCWWQSliL1OK2CRKEWuiFLEcShHL
oRQxmVLEZEoRkylFLINSxCY9lCKWQSliKZQilkEpYjmUIiZTilgGpYjJD6WIyZQilkEpYjKliE2i
FLEcShGTKUUsg1LEch5KEZMpRSyDUsSaKEVMpvww+aH8MJnyw9IoPyyD8sNkyg9reig/TKb8sAzK
D5MpPyyD8sNkyg+TKT8sg/LDZMoP+xTlh71M+WGTKD/s05Qf1kj5Ya9QflgT5YflUH6YTPlhL1N+
WCPlhzU9lB8mU35YDuWHyfAwk1g1HMuTbA75kzrlKeUpeIMipQisP0OZwaqUEuUZ+I1SpRT1MqVs
3LdUKuXKTPYSuZdKpVKpggoPU6+8oLyAeYSHqVMalE9C5yovY7b5yqcxplFpZM8pr8DJzFKalGY4
hNeV17FV+JlaxagYcT6tSiv2SiQxCodTD4fTiWMJh5Ou9CouzNOn9GEvj+JhLyr9Sj8qQ0oQVyF8
TjV5m2mU3FhJDqdGWaWsggqf8xL5nBrlKwqeEuRzKsnhzFLeVt5G5R3lHRxduJ16cjuvK99StmMv
4XlmKd9RvoMx31V2Qb8P55OqXFB+B/1veJ5U8jyfJM9Tp9xSbmFm4XmqlQ+UD3B1wvOkkud5lTzP
HPI8NeR2KsntVJPbqUxOg8OpgcOZyGrJ4dSTw3mRHM5LcDiT4YKmJGdj5FQ4nCryNtPIz9TBzzyF
oxTDz6TCz1RAK5OrobPgYVLJw6TCw7wCFe4lldxLKrmXT8K9LBh3LMKrLIIPWUyOZUnKElTaUtrY
7JTOlE6oPcUOdaQ4oM4UJ9Sd4oaKLLqJlEU3kbLoHqEsukcoi24iZdFNJOeTRN7mM6nTUvPZx1Pn
pX6GzU41p/rZAkqq05Pb0cPhzICLEB5mBnmYp9V2eJjH1Q61E6QufMvj5FhmwLH0oO9Ue+EcvKoX
FeFVnlAH1UFUhtQgXIrwJ0+SP5lB/uRp+JMVqHwBLuVpcilPqV9Sv4Txwp/MUL+irsPWN+FPnoI/
eQuzCX/yJPmThDN5gpxJqfp19evQd9R3oMKZVJAzaVa/BWfyLJzJDtS/o+5kZeRMniVnMpOcSQWc
yfdR2aP+gD2j7lX3YuSP1B+hLvzJx9QD8Cel6kH1ILYegTMpI09SQZ6kWT2u/gJbT6gnURfOZKb6
rvouRgpPUqH+Rj2H+n/Bk8yEJ3kPs12AM8kjZ1KmjqljOK7wJ+XkTz6m/k4F41E6YAnlkRarV9Vr
qIikwHz1unoDfZEXWEh5gfmUF1hCeYH5lBf4GOWR5qn/UP8BFdmBJeqHKgiQEgQLAOYgQMoRfIyy
SfMoTfBRyibNo0zBQsoULKFs0uK09LQM1EW+YGHapLRJqIiUwSJKGXwsLTstB1tF1mAJZQ0WUtZg
EWUNFqTlp+Vjq0gcLKTEwXxKHCxI60zrZI+TE3sSTixMTgyfh7Rlacvg0JbDfT1J7msm+a5m+K6v
oL8ubYSVkfuambY+bT36IrmwkJILH6XkwhJKLiyi5MJCSi7UM920m7khwK+atIK9z5hpMZoJzYJm
R3Oh+R686pzb8aqhxdBWoK1GW4e2AW0z2ja0nWh70PajHUI7inYC7RTaWbQLTAodp8ZMl6hJoVG0
M+hfRbuBdhvtHmMtEpqClo6WhZaDNj1xDi2F/5fXksRcLeXjTexThTabtrGWerR5ifOlfTYnrrGl
CW0h2pJEffxVCp2npnPuQtuL/sUHtUS7gnZ9vH8G7dZ4/26ihdl442gqWiZaNlpeYmy4gMazllY0
W+I+tTge3PPE2GIax1rcaH60EFp8/BpWJo4XLhu/1jVoI2gbx7dvGd9eOd5qUMP72CKu5wDa4QfX
krjmvWgH0A6jHUM7iXYa7RzaGNrl8ddrD71+NP4m2p3x13Pj+915aPt9xlr1aCloE9Amo+X+81W8
f635aEX/z69SuO6f75W4ttbS8ff6/7fl/Gujz/eKxHHoc5WTGEfHfbhVoFX/8/XBHIl5pfBc1GvR
GsY/f9jWOv+fr63NaIv0E5eOdc8bGjXFehgpJ1WhK3oyoat7sqHrevKgG3oKoJt7iodGxV7BJaZt
PWXB1qWXu5uGziy91r1w6LxpZ08lac2D/p6euqHzYmvQtvRm95Khi6b9PXOHLib643qnu3XoiulQ
TyPpAuhR6h+l/omexdBTPSbo2R4L9EKPfeiK2CvogNrQv9/tGLpuutTjgl7t8UFv9GhD10U96Dbq
u91Dt0y3e2LQez0rgn5jSrd/6G6L1LOadB3pBqjSUg9N79kMzerZBs3p2Qmd3rNn6K7YKxhqKezZ
r20wTugOabizPYc0ZpzcHde40GDcmNu9UlNbynuOQqt6TmiqqARXJurjmt+9Rss0FnWPaNkts3tO
PdD6nrNatqgH14xrafdGLa9lXs8F0kvQJuov7LkKXdJzA9racxtq67n3QB1OKTjS4nYqwY3Giu4t
WkGL35muFdBsxeOVkDPrIxWV4BZjdfd2rawl7swhnf5RX9SD24213bu0ypaVzkKtUvSDu4y1zhL0
G7r3ajUta5zlpFUP+iPO2dCNznroFuc86HZnE3SXcyH1l2g1Yt/gXuP87gNanbG5+7A2t2Wvs/WB
HnC2Bg+0HHbatLnGRd3HtEbj0u6TdA4OUveD/jGnH2di7j6tLWg56Qw90NPOuLbA2Nl9TlvccWgg
RBonXQk9OrAGemJgBHpqYCP07MAW6IWB7dpisdewv+PSwK7hkNHZPaaZjN7uy5ql4+rAXuiNgQOk
on974LBmEVuH48ZA9zWNd9wbOKbxTqn72vDKhBoj3Tc1e6cycJL0NDSd+unUzxo4B80ZGINOH7gM
LRy4ptnFXsNroHfQX959X3N1lgzchJYP3IFWDaAi6sMjxlUOvebrnO0XWu9PGd5oXOtI0bTOef4J
Qjvj1J8MbfLnQhf686FL/EXQVn8p1Oav0DSx1/CWToe/eni7cb3xohbrdPtrtZhxk2OCtkJouMC4
1TFZW93p9zdAQ/752mpRGd6VqI/rDkeuts6425GvbeiM+5sf6Er/Inx3UB/eO677HEXa5s41/qWk
5gf9EX8ndKPfCd3i90K3+wPQXf4IdK9/+fCBzgP+VcFW40FHqbat87B/7fBhmm3neOWYfz30pFBR
GT5mPOKo0PZ0nvZvIt36UV/Uh08ajzuqtf2d5/w7tP2iP3y6c8y/e/iccdRRqx3qvIw7D/Xve9C/
5j8Ivek/Ar3jPw697x/VDnXp/WegKf7z2iGx7/CY8YyjQTtqPO+Yr53omuC/+G862X9FO2G86GjW
ThmvOBZpZ7ty/ddJbz3o5/vvameN1x1LtQtdRYPsgZYOcu2C8ZbDrF1qOedcSboGOkb9y84R6DXn
RuhN5xboHed26H3nLu2S2Ct4uFXv3Bs8Zrzr6NSumpjDqd1oTXEegE4gnUya6zys3RBbgydN3OHV
bpu485hQ0W/Nd54MpptUR0C711rkPE167t/6pc4xaIXzMrTaeQ1a67yp3RN7BU+bMh2RoGTKdiwP
Kq0NzjvQ+c770OZePXRRb0pQMeU5VgXTW5eSmnsnBM+ZChxrg1mtnb2TSXNJ84NZpoLeIvSdvaVQ
b28FNNBbLeoYP9Ya6a1FZXlvQ/CyqdixPpjTuqp3PnRtb3Mwx1Tm2KSdEhq81rq+d1HwpqnSsRXj
N/UuxQyVvWahqIwl6uNa49gRnG6qc+zGuW3t7YTuIN3d68SdEfU7rft6vVg9qW+a69gXLGw92Bsg
jTzQI73Locd7V0FHe9dCz/Suh57v3QS92Ls1eL/1Su+OkB7zHAyWmPJ6d0PrHEegjY7jOM/rvfug
t4RSZcy0wDEaLG+923vwX1XUQ7CtvUeChW2893hogmmx40ywqk3tHQ1WiX5osmlxLyomk+M8XVdC
L37Ub8vsvQLN7r0Ozeu9BS3ovQstdjFomYvj2sW+d0wWx8XgbJPdcSVY31bpUv9Na1yZwXqTy3E9
OM/kc9wKNrXVOdcIdWU/0LmuvGCTSXPcDS5sa3QVQBeQLnYVQ02uslCuYJJQfpvFVQk+ARuEitrs
rpqhK20uVx3U55qbWMFDpWIdDFW0aa5GLa8t5lqg5YmVKFTdtsK1WKxKLhMUa02otm21y6JVtq1z
2bG+4PsSamjb4HJpl8TnNjS/bbPLp91r2+bSoDtdscRnLNQs3t/QorY9rhXBQtNc12oo7kNoadt+
1zpxT1wboIkrPeTaDD3q2hZsohXnclfFoIrVRzz5r3VVD2Zq9q7awWxow2De+PP5pnjKDd/pmj9Y
oG027hsshornzP2u5sEy8cwZrITiSRLXdy0arMHTY+lgnXaWPvljbSdcO0PmtlOuPaHOtrOu/SFn
2wXXoZC37ZLr6ND5tquuE0MX2264ToUCGHMWY267LoQibfdcl0LLzZLramiVWXHdCK01p7tuD103
znfd0+rMWX1SaL05p08JbTIu6kvXGs3T+7JCW41FfTmhHcbSvulanrmwrzB4zFzSVxLabS7vKw/t
S/CGuaqvKnTQPLtv9tCoIIrQEXN9X33ouHle3zzxLvQ1fbSym5v6FpIugS7EuY2al/S1hs6YW/ts
ofNmW58jdNHs6HOHrpjdff7QdbO/LxS6lWDaFqkvDopLcBRRijnUtxLsStxojvetga7sGwHFic/G
3ZbWPqh5Td+WMDOP9G0Pc/PGvl1h1bxFjDTq+/YO3TJv7zsQzkyQm2lD3+GhUfOuvmP4jhOjmvf2
nRy60pLTd3rorvlA3zkc3dY3hvtwuO8y9FjfNa3AfLLvJhhse98dnM/pvvvQc259aJXptjsF84+5
J4SzzZfdk0Oj4g6E88zX3LmJz3a4wHzTnY957riLtErzfXdpuLhd764IlyUIsz3FXR2ubJ/grg3X
iO9FuK59srsBlA5WD89NaHuue36CwMOND+kC0sV0FBOppT3f3Tx0pb3IvWjoenupe+nQLUHUYXt7
hds83neR+sT3K6yN30nwcDhGukKcVXh1e7W7M7w60Sdd117rdmqZ7Q1uL3gYVBze0D7fHUgwcHjz
Q7oNpOrWCtqb3RHoIqGCWsM7E9q+1L08QarhPe1m9yqtrL3TvRaKOipO9/oEtYZq/6nh/eJbHz5E
ejSh7V73JrAoiDR8oj3g3gryBJeGT7VH3Du0xvbl7t1Qp3sfmPOk+yDYUrwvZxPavsp9JHyhNd99
HN9u8WROb1/rHsXqme8+g/569/nwJVOe+6JYEdxXwlfbN7mvB2+2b3XfCt9o3+G+G77dvtvDwvfa
93l4RBp/ttPT27TYo0aU9oOeTDyNfZ7sSHriSdh+xJMXyWo/7imI5LSP9jZEpref8RRHChMM0Nrp
KcNaQKtM+3nx3E6s0e0XPZWRkvYrnppIeft1sdq23/LUYdXDUytS1TrqmRupar/rPB2Z3brW0xjM
sTDPgkjO+Lq81bM4mG7hHpNgCY9Fu2RRPXaxpntc2j1LpscXzLJkezQc97wnJtYvD56BljzPatQL
POuCWW1lng0frRSWYs/mSL2lzLMN5waWCGdaKj07Q6Pi6iLzLDWePYknbfC0pc6zH/PM9RzCKoA1
N9JkaXTsjiwU61RkiWWB52ik1bLYcyJis5g8pyIOcd8ibprHb7F4zkZCFrvnAjwOnuGReIJ2hIaW
JvQjqnF4IyuFJiqRNaQj4hwiG0m3WFyeS0HJ4vNcDSoWTdCIIJPQUkvMcyPRx3oHxV5YCyLbxVM3
st2ywnM7wRWRXeOKqwg1W1Z77mG9oD5d13bLOq8UnG7Z4FVAFOCKyF7LZm96giJwVg80MtK61ZsV
LLFs8+ZAd3qnJ1Z8zAONHLDs8RYmVvnIYct+b0mw3HLIWw5FHZWj3qrEKh859pCeFOtU5DTpCOk5
ywnvbKzdWMEjY5ZT3nqs1FjHI5ctZ73zgvMsF7xN0EvehVjFGr1Lggvpnl8jvTl+Z656W4NVlhte
W7DectvrCDZZ7nnd2iWr5PVH7nSZB+fGU7o6BxtjjV3OwQVQ7+BibXVXYNCkWboigxaNdy0ftMcn
YIwLW1cN+uKTu9YOati6fjAWz+3aNLgint+1dXA13NCmwXXaiq4dgxviRca1g5s1rWv34LZ4ade+
wZ3xiq6Dg3vi1Vgx92ubu44MHoou7zo+eDRe2zU6eCLekHAHxuODp7T9XWcGz8bnd5337443d10c
vBBf1HVl8BJ83JXBqw84/PrgjfjSrluDt9G/O3gvutvOAlLcbOcBJd5pVwPpcac9M5AV99qzAznx
gD0vMD0eSTjQznmBQniuhNMhT2EvCJTElydcnr0YFZe9LFAOz4W1Pr6qc0ugKr6qqygwO77WXhmo
j6+31wTmxTs7S8RI46pAk+az1wUWxjclfFbHocCSj/xswmPa55KvnNd5WTi+QOuDo28P2KDkleyN
AQccU8Lj3IfHPGRfMHgjXNM5O+DG/IsD/vhWuykQgs/CHYjvsFsC8XFWWWO3B1Zqm+2uwBrtrN0X
GInvtmuBjfF9CT9ojwW2xA/aVwS2x48Izokft68O7IKnhrOOj5Kesa8L7MWqAQeN9QIaPy80SJ46
flEcJX4lofYNgQO4os3wXC77tsBhzSf8b/y6fWfg2Hj/FuldwUvL2PidhHtdxscVZ7VMte8JnFym
Jvqkmfb9gdPaOvuhwDm4V3jYZdn2o4GxhGNdlveQFnQeC1zGHTsRuAY9JVR4zNCihNrPBm4mfOWy
YvuFwB1tj/1S4D4UdVSuDukTHnNZ2UNaKShuWQ1pXULtN4ZS4BzhH5fNtd8emgCfCBe5rNF+b2iy
dqpbGsqFKkP52tnu9KGi+FLxvixbQLrYuGqoNH69O2uoQtvfnTNUrZ3onj5Ui5GFQw3aYqviDUXu
k3eg9YieXfAs1nRvPKq3ZnlXRlNM3LsmnGnN8Y6ItcO7MTrBOl0o+luik62F3u3RXOiuB1ri3RvN
t5Z7D0SLrFXYS0l4Outs7+FoqbXeeyxaYZ3nPRmttjZ5T0drrTni+Ul6x7rQey58Qzwtow2k81sj
3rFglnWJ93K02drqvRZdZKr03gyOWW3eO9GlVof3ftRM2imek1HnuLeCRr1Wd78+Gkj4LKu/PyUa
sYb6J0SXW+P9k6OrrCv7c6NrrWv686Ej/UXR9eKZGd1EutW6sb80ugNaEZSsW/qro7ut2/tro7sT
a4p1V39DdJ91b//86EHrgf7m6BHr4f5F0ePWY/1LwzX0FFWsJ/vNmsV6ur8zOmo91++MnrGO9Xuj
5032/kCw3nq5PxKcbb3Wv1zbk1ihhEYvmjSshuj3r4r4E+TWPqF/bfSK9Wb/+uh1E+vfFL1lvdO/
NXrXer9/R+S+taR/dzTfpu/fFy21pfQfjDHbhP4jMW6b3H88ptpy+0e11bZ870gs8+HZbEX9Z2LZ
ttL+87E8W0X/xViBrbr/SqzYVtt/PVZma+i/Fau0ze+/G6uxNftYrM62yMdjc21LfWqs0Wb2ZUI7
fdmxzHF1+vK0SzavryC2wBbwFUcjtoivLLbYttxXGTPZVvlqYhbbWl9dzG5b75sbc9k2+RpjPvH+
xjTbVpMvFrPt8C2IrbDl+vDMt+32mWKrE++dbZ/PEltnO+izh1bZjvhcsQ224z4fdNSnxTbbzmDX
bbbzvhWRLNNcHxyW7aJvHfSKb0Nsp+26b3Nsj+2Wbxv0bn91bH8H8+0MX+jgvj0a71B9+2OHOjJ9
h2JHO7J9RzV7R57vROxER4HvVOxUR7HvbOxsR5ljNFzTUem7EK3uqPFdil3AyKsYWee7EbuUOErH
XN/t2NWORt+90GjHggEpdsPEbUXa7Y7FA0rstqlmID04vcM0kBW712EZyBmWOuwD04eVDpctMKyY
Fgxgde7wDZQMg+UGyoMLO7SBquGsjtjA7OGcjhUD9cPTO1YPzBsutJYPNIVvCB0uSbj+jnUDC4fL
OzYMLBmuEvQyPFtQynC9+CnK8LzEN45+grFy/CcV//rtODj+swL6ycBwU8fmgdZokVjfhxcKDz68
RHwah1sTPx2i58Odjm3eEcxPJNaxc8AWPG0tHHAET4//9IZ+rtKxx+EctllvDriHHQnX37F/wD/s
Fu91qJlJbIruhu7PjOn+qrvNJN1d3QdMr/tQ0jEuyRJnyVKqpLJUaYI0kaVJj0iTWYaUI01jE6V8
6Qk2SSqSnmaPSF+TvsamJM1N+hTLlhvkT7Ic2SX3sVz5p/JPWV46/mePpU9P/zSbnt6UvoQ1phvT
h9ln099I/wmLpB9Lv8a+l349/TY7g7P5DNPTXz9IZxksmU1kC1gqW8ha2SvMzL7AlrAvslUsxlaz
d1mc/Yr9lh1nv9OlsF/rVF0a+1CXoXtEp9OJ33FSxL+b1E3RLdZZdbm6Dl1cV6xbrlurm6sb0X1N
95ruB7pf6j6b9J2k7+i8erfeo+vXh/QR3YB+uf4LuoD+Df0bupD+Tf1burD+bf07uph+p36X7vP6
vfof6Vbqf6L/iW61/mf6n+veoN/HXKs/pX9X96b+gn5M95b+sv4Pug36P+n/pNuk/6v+b7qvi39F
p9siT5In6b4pvyvf123jMi/QneZP8ad0t/jTvFT3V/48r9Z9IH7DQ/chf5HXS3rewD8tcf4KXyKl
8xZulnK5hbuk6dzDNekZ/nm+Snqer+YbpFn8bb5Vmid+c0Jq5jv5L6RX+Ul+Uurlo/ys5OLn+Xlp
kI/xMSnAf8+vSkPi32NJYf4XfkuK89v8vrTcwAxp0huGTMMj0tuGKYYnpHcMhYbnpF2GOQa7dMjQ
Z1gjXTN8xfCVJNXwpmFDUprh24adSZPE31VNmvJ/2Psa4CiuK93b86cxxmOZKBjLWJFlLMuyjLEg
RFGITIgQQvODTDAhRIGJpuevp2c0/2AewZglPIXwiEwwIQRjimJZRSEEE0KwAhizWCasnowJxphH
WIJZTLCiUJiVWRbjd87XPWIQckxq91W9qqROfV9f3b59+v6cc+7pZmbI+XXOTuPwnPacV40F/Hkg
Y3HOWznHjGNyjuecNVbk/DHnQ+NEa7F1m3Ga9YPb7jf+wfaftv808fflVNFMPFgU8LeNJ2zVYSWU
iWK1sfayGqiunXy0epQaUZPqvNpT6kJ1SbVa36LuUHep+6rb1QNql3pEPa6eUs86BjmK1GWOtLpi
Yt3EgLpaXaduVNvUrY6iidVkVSay8Quw8X8XkvSx9LEwkEXnCiOduw+fRBWGnxl+JiTDzw0/p3Nb
DS8Jo2G3Ybcw45OoFsMbhjeEFd8Eu83wO8MRMQifQR2MT5/eYfiD4Q/Chs+d3mn4s+HP5B38ydIh
Rsko9f2vwWajRQzFN8eGGYcah4p7jMOMw0Q+Pil6r7HEWCLuw7fCCozjjONEIb4Ddr9xvPErogjf
ihmBz2w8SP0fLA3BzDGL0H4xP7Q/dDB0KHQ0dCJ0OnQu1BO6FLqiitAl1aIOVoeow4ACdYRaGupR
R6lj1XHqBLVWdanT1JmqW/WpqhpX56oL1MXqUrVFXaWuVTcAreoWdbvaru5VO9RO9bB6LFvC09WT
6hn1vHqhT3rVq2FD2JoltnBeOD9cSLXFN0hDuJjaloXLwxXq1YyEq8LV4Tpilvpwo3ohHKC2kXBj
OBmeF14YXhJeRjqLwyvCq8Prwhtp/NJtqh41+Dvrd2FOhpEYxXASkygWDwmzKCPJEY+RWEUlyW1i
HMkgUUVyu6gWE/HpcjtFHf7e5Z3iG2KmyBWzSIZQ3JHFZ0SAJE8kRBLfuJyH71o+g0+U/4PIp3j0
nLhX/IjkPvETkgLxj2KT+Jz4Gcn9YgtJkXiZ5AHxG5IRYjfJg+KfxX7q30GSEvxv2A+LY+IdUSp+
T1Im3iV5VLxHMlJcFB9Q3y+L/xCPi2skoyWDlCPGSIMo9lXi8+NfotiXK8bh8+NVUoF0v3hCekB6
QHwV3/espmhYj290zhQ10rckt5gkNUqNwo7Pkjvw7U6npEqqcElNUpOYIqWktKiXviMtElMpdi4R
Myh6fk98Q/q+tEx8U2qRWsS38O3OWRRJd4rZUrvULjzSXulVIUsd0uvCJ/1W+q0ISP8idYog7DdE
UaBEqNZSa6lowqfzotbHreUihk/kJayV1kqRtFZZq0QK3yRK4/N3c6xu67fF01aP1SP+B63tWdEL
2x/LvyyhbCe0E/YSOgidOg7rOEY4Kb6utCt7lQ6lUzmsHFNOKmeU88oFpZf4asgQspLYQnmh/FBh
qDhUFioPVYSqQtWhulB9aHqoIdQYCoQioWRoXmhhaEloWWhFaHVoXWgjSVtoa2hHaFdoX+hAqCt0
JHQ8dCp0NtQduhi6HLqmNqsmdZCaqw5Vh6tFaok6Uh2jVqrjSWpUhzpVnUEyS5VVRY2qaXW+uohk
ubpSXcP/g6i50RykTfBbtln4fYWJ/2327SS5E1aeCyu/C1b+GVh5Hqz8s7DyobDyYbDyfFj5vbDy
4bDyAlj552DlhbDyIlj5A7DyEbDyB2HlxbDyh2DlD4tOklLY+iOw9TLY+kjY+mOw9VGw9cdh66Nh
658nWzeIsbDvL8C+vyjdJxWQ3bNlj4NlfxmWXYXvRzwBax4Pa/4KrHkCrPmrZM3fIR94RnqGfIC/
JTEJ1lwLa66Tfij9kPyBbdqB70c4Yc0uWHO91El2PFXqkrrE16xPWZ8S06wzrTPFU9agNcjf185d
mLuU1mkwzf3tQorNIrsrJ1QQqgjVel0doZ4wndDAdaa7lDGxsaHDfxlocyx+RKmMjVPGxyaETt4I
rlNqYrWhM4Tz8eMMxRFzhS78ZXAbZWpsmjIjNjPUex38tzIr5g5djblVQ/yUIsd8qvUvA21s8bOK
ElPVvJiqRGNxIB2bq+YTCuMRlIvj3WpZ/KIyP7ZAWRRbrJZfB/6uiF9WmmNL1apPQXX8mlqXMCnL
Yy3AytgqZU1srVqvgcs8NnX6dWCs62Mb1IbYBj4Cm2KtauOng9spm2NblG2x7WrgRig7Y+0ZvdlQ
9sT2qpHrUPbHOm4F0VnpNcrBWKdyKHZ4QByNHWNE5fR6hnIidvKWcDp2RjkXO38TemIXGFElsVy5
FOu9FUSj6U3KldhVRkjEDYAlbmVE0+nNfGyKpNpC7nhjaHDcFhoSz+uP6Pz0ttCweP6nIboovRM6
CuKFwIh4cag0XnYDRsXLb8LYeMUNGBevumVMiFeHauN1N8EVrw9Ni0+/CTPjDTeAx30LUJOJQSFf
PBBS45EBQefUeYlcdWFiKNrF48lbwtz4vNCC+MKbwPqWEJYlhocWx5fcCtQViaLQ0viyPrTEV/SB
z68mrEuUoLwxMVJtS4wJrYqvRn/7Qd2aqER5bXzdp0HdkRiv7krU3KBjQ3zjDWiNt90EvnZfwhHa
Et+qHkhMxbErMWOg/nwitsd3hNrju27C3vi+UEf8wE3ojHdlQz2SmJWJ7dmxOBMr+2Lc8YTcF4NO
JZTsONJnJ9nrmlmXzBydTUT75rY7kc7uE2JJM8UU8v3oci0GRFdq/gu/WhPPx75B9h5dT9iU3pOx
5+hmOtJ9+Lx6MTFfvZxYpF5LNIdNieW8v4QHJVZyPY8tnJtYEx6aWM/xNTw8sYnjZLgosTlcktjG
e0B4ZGInx3aMmew9PCaxJxOfw5WJ/eHxiYM87nBN4hDPRdiROMqxk3UCUxMnwjMSp8OzEufCcqIn
rCQuhaOJK+F0UvD8Yg/iuaQ5DM+nfVLfz8KLaP/R5zncTHqWJy2sA+dWJgeH1ySH8L7Tt9dmrVGf
Toa+p2T2Au4T743h9clh6NumZEFmndGeYz+tPfZl2vMwts3JEVwX3kZ7eKUG3q95fm+AQ9uXeb/C
fkz3yezFfATIfjC2fnss7kUI74wtYPAem9lXMwjvibUw+vZI3jP1vTF7r7xhj9T3yQzC+2kfpDXG
3kf7YfhgrJ0Bu+V9bo+GvphFCB9KluJ4NDkqfCI5FvUUP8Knk+PC55ITwj3J2vClpAv17MO8l7Df
kh+xP4WvJKdFRHImx6KIJemGX2T8QI+LsC3Sw3EuMphik+4jWC+KW3x9Jgbe5Fv9/KovvmT6Tzo4
bkaGJH285pFhSbXvem5P/hYpSMYjI5Jzud+R0uSCyKjkYsRwHg+NITI2uTQyLtmC6z4t/uj9ikzQ
43jGx5dktdH7jLH2i8d94+E4nMEn3esT4mmkVj+64lt5TH3oHyezYyXHx0yMzI6J1BZ6uA2fozmI
TEs4otvS+6M70wcZnNvweiOv2ZM+hDqKWZHDKVt0f/poJn+JHkyfiCxO7kUco7wjeih9GjkFxbTI
luT5yIJkeyYniB5Nn0NM4/2f8waOdSfSPbxHR0+nL0XPpa9E9iavRnvmiOilOZbolTmDY2LOkJhl
zrDY4DkFyMn0eIlrOTfT8ybkPJkchXXpOvhcbMicERwvuV99uV0mD7t0PQYDmRxGzz1YF+djsWFz
SjnfiRXMGZW5Hu1pPPib5gt+QmOLjZgzFnWcN2ag54k3oH8uqOd+N0Cf1/55XR84F8ugf16XydEG
yM1ipRo+NTfj3Cs7/+KcK5N3ZeVY3Fdcy230ObnJt8j/IjOTq27yK3dybSbHiviSGyJqspVjUaZd
JJ7cwnYdmZvcDnvKxAFuwz5H9ofj0mRHpCXZifKq5OHI2uQxRra/RTYkT3KMiLQmz8A+tycv3JTH
ECLtyV6A7JEBP+S41ZEy4NiZsmZ8kH0iciyVFzmZyu/zP45BZ1KFiDXnU8WRC6mySG+qnPeeDHi8
/IwF/6MxR66mKpoMqSropvjRZE1VY5x6+yZbqq4pL1XflJ+a3lSYauBY1FScamwqSwWaylORpopU
kvc/7IEcnygnaKpKzWuqTi3keNxUl1qCZxbaC5vqU8uapqdWNDWkVvN8NTWm1jUFUhv5OaEpmdrK
89Q0L7WD2zctTO1qWpLa17QsdYBzQI7/mdjctCLV1bQ6dQQgfbzPsG03rUsd53lv2pg61dSWOst2
1rQ11Y0YRuvYtCN1Eed2pS5Dx77UNY7lTQfSpqau9KCmI+ncpuPpoU2n0sObzqaLmrrTJU0X0yN5
fpsup8cgjvH4r6Ur+Rg1pcezPUQHpWuiuWlHdGh6anR4ekaf/VAOzvlHtCg9K1qSlqMj0wrq9Zgb
HZOORivTaawf+Ul0fHp+tCa9KOpIN/fZauY5ILNHUTk6Nb2c20RnpFdynTAIybbE1iLE3/8F5W/o
X1C6xcXr/w4g9wrVm+8t9BZ7y7zl3gpv1TSTt9pb560nnu5tkHs18RYyvI3egHxVE2/Em/TO8y70
LvEu867wrvau8270tnm3Tlvu3eHdNW2Pd5/3gLfLa9NlBXDEe9ybp8sp71lvt/ei97L3ms/kG+TL
9Q31DfcV+Up8I31jfJW+8b4aryEj1MLhm+qb4ZvltWrik32KL0rt0ugh94hb8jm+H92B3/Pf0Ua2
Pfm/5T2ok3xjCsldeA86BO9BP4P3oJ/Fe9ChIiAUcbdQSfLxNvRevA29D29DP4e3oYV4G3o/3oY+
gLehI/A29EG8DX0Ib0NL8Db0YbwNLcXb0EfwNrSMfK5TjBRdJI/jbWg53oaOxtvQz+Nt6Fjxnvij
+IJ4n6QS70S/hHeiX8Y70SfwTnQ83ol+Be9EvyoVSAWiGu9EJ+KdaA3eiU7CO9FavBOdjHeidXgn
asc7UYf0HekZ4ZKelZ4VT+Kd6FS8E/0a3ok+hbeh08nTfy2+Lr0svSxm4p3oN/FO9Ft4JzrbtNT0
feHGLw02mnaaXhYy+XWH8JnOmf4oAuS/vTSXkpgrFly3VQ+N2HPUc8Jz2nPO00NyyXOFJt4iD5aH
yMPkAohPVuW4PFdeQLJYXiq3yKvktfIGuVXeAhkhl8qj5LHyOMgEcK3sIp4mz5TdLGw3hkfIbh7V
7WYI7s8WY6A1eoish23FRPNfTtbDtmKBreSQpUwkG+J35reRdcwkG2L7uB32MRjvye+gcYXIktga
cskWniN7YjsYQlawieyJLSBPvETyWVjAUFjA3bT++8lu+X34PbTm75CF8arfi1Ufjnfg99HKnxcF
WONCKZfW+H6sbhHW9QGs6AhptuQWD2JFH6IVjYoSKU0rWoq33I9Iy2gVy7CKj2IVR+Kd9mPSr6Wd
YpSQrGOt47LWo9R0l6e0v8jz5IWeUZ6xGZGLPeN0mdBf5CWeWo9LE3mZZ5pnmryCavqJvFpe55lJ
4ibxscgbcVQ98YzIbZ65N4u8FRrmehboslgTeYdnqWepvIu45WaR93lWedb2yQZuq0urLlv6S3BL
cLtnu6c9I74Lnr26dPSXYLunM3Ov4F7PYZINVNNPvGM8vZ5jJHy/kyyBEtlGxzO4AuLtuVm7pyNQ
Aw0dmZn1nNck2OG54LkQbCXuvVmCnTS+q33ikg19YtVkgJk6IHfJNjmvT47I+ZDj12ciI/IpuVAu
zghW/Kxc1k+6CRflckgFyWW9/prXRFzVNyKXZ4F3kFx9s3hz5TrvULlens7iHS43aOItkiNU0yg3
ekvkxiw9feId6TkvB/okIiczos2+5yStCNm3txK2W+sd761hG/M6eCa8U9k+vDOoNAujLfPKXgU9
UjBWTRNbymGsUmfwWPAkrOEMZv88ZrrbGyXfGUXzN9Yzzpv2tHrn0yzbvIuof83e5WTLbu9Ksve5
3jWywbuebLmlsdm7Sa6g+y4nO1lMbTd7t3l3eq5693j3ew9Sj9n+W7yHMEo3rdgBz2LvUWrh8p7w
niZd7LUYEVpqvsKru9gzzXuO+t9DY75E9Uup3VjyuqXeK1Qa5Z3lE55xPotvsG+Ib5ivwDcCvjxN
E1+pbxT7q2+sbxzJBF8teauqeazP5ZuGu9GdfDM9i31u9kkfaaaWqi/um+tb4FvsWeVbqvsfe2Cr
r8Wnkq3ZYG/5dHaVXCdX+NbK+b4NvlbfFrnBt53Wl1bLu9zX7tvr66CZK5OrqU+r5C5fp+8wtT5G
clIu97XDAnmUWCtuR0IWw7PkO0M4L1eTD7f4eqk+6bvqN/hO+q1+urc/z5/vL/QX+8torhV/Odu7
v8Jf5a/21/nr2cZpZrHm/uneErK2Cn+DT/U3kgT8EbmKhc4l/eX+eTSCOnk6nVkoN/iXsJ0SN/qX
+Vf4V/vX+Ub4N3rO+9vkgH8r2WOEx+bf4d9F92wkC03y+IIXPNuDvQGZIsPe4FVan5M0nmqylxbF
oFgpCrQqNooUHb5V/m4lzzPM09540F+v5CuF7NdkMzRbSrFSppT7WpUKpYoslCNHL0Uznp3WYHuw
XWvhaQkcUqpJF8c7WDBaalGGLJh0HVbqPKuUes8WZbqnQzZQu3bqzwWlgUrb/Q1Ko2evt9JfHqhU
AkpESSIK6pFMmRdEZPVXBA8HDysLlSUU585osU5ZpqzA3ehOymrPeWUdRzPiC8o6ZaPSpmwNDFUo
ovsbtMiF2GUNnld2KcvkBmUf98S/j9aJbafBf8DfxfajiXc59bvDf4Rjkv84rfEpuZ5W5yzZVRnF
gzJ/N831Rv9Fucp/2X/N4wqYAhR3PGcCuYGhjQcbDwaG0wpuJLu54JkbKAqUBEYGxgQqA+PlRt9J
nnfPdrkiUBNweC4EpgZm+M4EZpH3LKUAo8gRuv9J2h/PBsaTB9soZjXSmWggHZgv5wcWBZoDywMr
PQtka2BNYH1gk+dwYHNgW2CnbAvsIa22wP7AQc8x0nwycIj6ZKO+HA2cCJwOnAv0BC5RHztJt9Vz
gVpeCYqgxbM0OJiizRDyJRfZzTC6poxspSJYQPbbHRzh2RIo8Xf7u73L/ac8J32Hg6XBUcERNA+G
4NjguOAEX2ewNugKTgvODLqDvmCtXEdH1dcbjAfnUusFgeX+ruDi4FI5GWwJrgquDW4ILA+2emVk
U4/+/Qnzb+gJMyCi+FTDUP7fZNytQvq2QeS5N5K0kWwl2UGyy71rJol7n3vf7GOzj7kPkHS5u1B3
hOQ4CdedIjlLQtfN6JnR4+4muejmZ1iDzWWbQvfIxRONwBONAc8yRuS8JjzLmPEUY0HOm4OnGCue
Ym7Dk8vteHIZjJzXhpz3TuS8uXhmuQtPK58RUq6cG8GY8LlD9xghuR10rKTjVNNdtZvcNbeCujo6
biZs+wTs1FDXoKF2zy1iP+HgADikoS5Jx6O3hrqFdDyh47SOcxomn9SOdasJ66jcQ7h0M+ra6Hjl
01G3g7CL9AodFsLgG4Gx9cPkIf0w7K9AAWHEACgdQC9jVD+MvTW4aN4njyNM+ATUanAd1TDZdYuY
Rpg5ANwaXLRuk323Bhet7WRVR1zHXA2uc9rReYqOhwkLCItvhotsYPLST4frkq6jRccqwtp+2DAA
Wvthy1+B7YT2AbCX0DEAOvvh8K2h7iwdj7nhHwOCztV1Ey7q7c7cIs4TLgyAY7rOa3TsvTXYTXS8
eh11huvoa5OrH4cShtM56/V7ZcNepN/f9umwlxBG3nh9XV4/5A8AvnYMHQvpWKkfxw/cn09CXTGh
bACUEyoGQNWNsNdkxe/seJuJl3ocszvcffHFPtV9Y/zI2En2uurz3TdHM7LmdtaNfeqLKdkxIOPD
um/xnpGx+SnD+tl0r3beLhMUQlSLEby/2Odr9Twm+yJCsxZf3bxeFCftKwlrtD3Avl6P71c0e7fT
nGTis532NPs2bbz2nfo8kE6Ol6wTYL20nnaKi3aaOzv1wc56z+nzq88nX4t9MrOHnc6aZ9LjEJoO
Pueg/cIxWO9X/3Xqt0Z9e0pmnZq1vdExROubY1jW9Ve0seDvbfreR387CvS6zVnYOQD678uHBsDR
rP01a4/tQ08W+u2vffvlf2WfLHDfuBeWuq/vgVn7XV/MIjgm6Efatxwu3ccofjhoT3LQHuSg/cfh
0+vJh3n/gN/WaP7koH3GEddikWOu7he6H2TiItsW6+E4h/iU8ZFmLW7x9X0xsL9v9fOrTHzp861m
vf+L9TVfev16tCd/c9De5Fil9dtBe5KD96CTekziMdAe5NiiX/dpMah/HB+oTabPA8TjvnPW6/jE
WPdp8bTwRtwUJ7NjZXlWjMyKh2hbqLep0OaAY/QUsp8ppRo4t+H15pxmyii9jmzFWU1ljmN6/jKF
ciNHrx7HaE2nsG0t1uKZk+ee50vPCabU6rGM9/9Vepxj+6M9egrpm0L6nNTfKWQ3U0jfFLKzKayT
bGzKAj1+ZuLlFj03y+RN8etxFLp0HejjYi1eol/943C/GNyXw2TiMI+TdfE5sqkpLVnXL9XHM1ab
L+RcNLYpq/S6cVmoHQD9c0H3ANDntX9e14cFWeif12VytP9KbrbdfWP+tdd9Pe/KzrHc+rXtWXPS
37fI/xyd7pv8ynHY3ZdjOdivT2qxqC9endHs2nFet6dMPbfp1e2PjxRXnLrfOcnHnDYN2f7mzNNi
hDNfs09n8QB5DMFZpqNcA+Ig66/Qj1XXfZB9wkl7nbM+y/+onXO65m9O2qOdjYSAtvdkgHjUps0T
j9kZISR13TQO5zx9nHp7Jz3TOZcQlhFWuBGLnKsJ9Azn3Eho0/Y/BuIk5QTOrYQdWjx27tLslPdC
5z7CAUKXPl9HCMe15wTnWW2enN1aeyftHc7LhGtaDsjxPxObXbQHuAZpYH3YZ8i2XbnavLsoB3UN
1+zMVaTNI6+jq0Q/N1LXMUaL5S7KEV2UH7o49lA+5qI8zEV5lYvyKZesza9L0eMYjd8V1Y9pzR5c
lAu5KAdy0R7hWn7dfjh2cz7golzIRbmQa71er8dcF+UDrs2afvYTF82Ri3IA154sW808B2T2KCq7
9mttXAe1Ov40xh377njt75/G+Ft6V2YqNe3nf1E1HBS/ECKnkFBMKCOUEyoIVVnHakIdoZ4wndBA
aCQECBFCkjCPsJCwhLCMsIKwmrCOsJHQpmMrYQdhF2Ef4QChi3CEcJxwinBWv2f3JxwvEi7r4PbX
hLCatHrrIEKu3rdu/UhjsA4lDCcUafV9xxLCSK2v1jHXx2ytJIwn1BAcmh7rVO1+1hmEWQRZr1cI
UUJa02udT1hEaCYsJ6wkrCGsJ2wibNaP27KOmfY7CXv043r9uj1Z5/cTDhIOEY4SThBOXz/y/FjP
EXr+imNmLi5p8/jXAmuQjXoNrB/rdUpve64frmj/7XzmmLk+o/c2C2Gwvt5Uf9uQ68fbhhEKxC/s
tXaXfZp9pt1t9wGqPW6fa19gX2xfam+xr7KvtW+wt9q32Lfb2+177R32TvthkmP2k/Yz9vP2C/Ze
+1WHwWF12Bx5jnyg0FGMv8tIyh0VhCpHtaPOUe+Ybm9xNNhbHY2OgCMCJB3zHAsdSxzLHCscqx3r
HBsdbY6t9PcOxy7HPscBR5fjiOO445TjrKPbcdFx2XHNaXIOcuY6hzqHO4ucJc6RzjHOSud4Z43T
weepfqpzhnOWU3Yqzqgz7ZzvXAQ0O5c7Vw6INc71zk121blZl20kA5V3kuxx7ncepPIhXY46TwCn
Sc6R9DgvOa+4hMsCDHYNoT3hngF/cUHov7hgxS8uDMIvLgzGLy7Y8IsLufjFhSH4xYU8/OLCUPzi
wt34rYV7bIW2x8W9ttG2avGozWMLiCdsqi0mJtqStqeF3bbA9ox40rbY9l3xNdtztt+Ip2y7bXvE
QtsB2/tiEX59YdP/xz2TpCFSFJ9Xaef/Tb6oXAdFlqIqHdU66rLKDPKaoul6mds16OVGHQEdFHWL
KOoWUdQtoqhbtERvu0xvz3Ursv5erR/X6diYdc82/e+t4pG6gySH6o7Wnag7TXIOfLquh+RS3RW7
sFvsgzWpO2gfYh9mL7CPoNpSqi+wj7KPrTttH2efQD4Jr6y7RH7psrtpre7EL20I/MaGAb+xYbSV
28qFyTbRViPMtsk2p8jB720Mts22NdI6BG0hcZ8tbkuIQts823dEkW2R7R9EsW2XbZcosb1ie0U8
bOu2dYvS/8fapWvfNH2VeCZZh3TtdpQHofw4yo+jPNpUSzzGnER9I+p/hPIy4nLzSyjXoqxd+zjK
9bj2MeKRqB9jikAPX1sO/Q2m0czmb/Jnn8zzqJxnmsBsThFvQ5sX+b4fofzRbvRhEepDKI9GeTTK
Y7Te6jwPHEMb0vnRH0yPEJ/SR/QIzn4TvcJITV/EuILoeYDLxmMoW3FW4KqfoiaMa+2ouRPlJ3Dt
HGi7Ez15AmxGm7Fo4yMehfIolMtNlahXUB4LDagHj8bZcpz9gulLzOYQelKJllwebbyINto8LIO2
XdDGa/GYqRX1GleAp6KNDJ07oJNmw/Ak39HwqNlN/F0zebchjfIT4GPmOPECbiMZwM+jPfppEMxG
H1o+b/YQb4LOu7hGepvL0gc4+xzaT0T7H6CcB20fgE+h/RXTv1C9wfQa8VTTEb4Ll6U/o8Znept4
HLcRvcxSHfg/wLuZjUa0nAw9T3F76V1oaEX55zg7Ce0/RvtSlM+C94F/hfbvm5qopcP8z1S+zHZr
sJhfofI1rpcazQeJT5vIEgz53Ea8b36W+N+ZpbN6DbGxHHrywcNxrRf8HPhu08c4+20qv8FsOIHy
LvAh8POmBl4jy/vgHeA2cDO4hzlnGN1rjLaCaPldC/+GSiPKT4Dv0LkN3Azma+9Gy/04uxU1x1Cz
ADXrtXXnMvEOcBu4GdwD5vaT0XI+rhIam3/MVoHy8+j5JpTbwZv0mjZwM7gHXE1j2WtuhhUFmHH3
t8Ef4NrndN4BbgM3g1nDc5iNH3Ab42rwD9DnD8CnoOcU91l639xJfAn8vvkFcBQ8GwxLMHeThrux
XpfR8hT4vM7Pwgb2sW2g5ho0XIOGa9BwDVZxGmdPo+a0XtNObMRY7jfvh810gqPg2eA3mWEJpzQb
4zJZGmt7E+X3KafnPlCNoVJnGovhdbZSw3DUDEfNcHj3cNZM/Bq4HZa5mcY4T7NPaG4BP6dfy36R
gM3fzf8TN93rBXAUPBv8GrgbzDpP4NoTmI1D0HYI5edRflFnnr2D6OeTOaztDo01S0N5k8bm32Bl
o1hHPvsByu9bvswzrDH3SqCGnmmZ81F/CCt7CDXb4CPF4EJEoccR375rKSF+BvXvIRZdQnkF7yDS
vyGm3aHFQ24pDTL7iT+DaLYYfDdmYwvalMEX3kL5SXCrHgNpf5Gg35DDbHmTV9/yfZ4NM2Kpyc1z
YtnJZUsZl43nYNutsJNyWG8nrtpp3sbXmragV3xW0eK5hSPnI8zkm0fgU0fgR+wdD6L8HM7+mz7G
BPrjw7U/Q/ufYZ4RYczneH6YKVYza+v1qIX2R0Ma7e9AeT/aL9CjRxviQDPvDvBBH+qfB98FfhB3
eRv8cU4tr2bOZtyXz07kVSbP5XKezqzz83pMXkflYbDJN1FTCD5uuZfXF/H2Rdjz1xG3t3MUNR+G
TR7iluYS2J6Va2jt2IbzOJ5LnZoX07My7QhYl8M8wxQH2mFj7fBKjV+Dv7SDX8MOwrE6n6+l+XwF
Vz0LD3oWdsh3SXGvjJP5rHGyFlVMlKtI98HHJ+CqnZYPER+4fQX3liyZa86yp5OFv8U7C3persef
Z9GS77IR/Bx4n+UhLlv+Fzx3Cu8y8NwTOLtLZ81DuTzN8gjOdqOmG/3nGR5reZNjHXr7Au+G0v/G
npiP3n6E+pcw5/ehXIixnOZMyVBvYv1dJhvxOc4eDfcw03o9i6jCq7YGY1zHvmZ8HPvgw8zGQhPV
GH4LzT9Byw+g+V9R/leUJ0F/J888MWuuQ58jzGIryufBXzcPEpxXsP4vYaVKoaFL2385j6I84duI
fmzhS5G9nDcpGAXb2wM4uwY9fxP32g1t+TxS0+94NsyYE9OHWN807+/GoazN+BaXTV9CuQbj7cEo
PkSs+BCemI9+ItobdnEPjWMw9tv03nJPilAuM1HuKr2OUf/aRNmgNB59O4BrYe2GSpPKPo6rpnEO
bJhm/BPxStNE0lyFddxuktk+DT+h8hFoe09n1vYi9HweOstNJuJ3mcnq7hOcldEMGHMwD/+Eq+Lg
FtjAORPP3hZoKAH/CHpcKKcw9hcwzxMwRgVXvQc+AQ7yjFGWxaNYxFkrlW9jq8AeFIa2RvRzGvRY
zKs4AujWyKP7DfpzxTKC2fwB+C3wbtQXges4Jmg5J7c0jAJXmt/GPsLlGi0LhZ43wa9Dz+vQ8zr0
/B+096G9j2sMUdSMQ41Ly1q5LHq5J8RvgXejvghlbn+HltniLrs1Rh41GXom87WGp1B+SiuzHuLd
qC8C34ea4bAf5BvQ+S60XQK3gn8O3mziHXASdE6CzknQOQk6J0HnJMzSJNZsLOWWxlLMwD5o2Ify
r1D+FY+CZnUd+s/8S228XKa+rYOedbjqA2jgmgr080OdD8KzuA9TzY/BW3l1njVxtrlXfzrgu7xm
OgqfxdMBtxRaJn8Guf09eAqoBf8W2u6B/l7wUfBmXDsDXINrd6L+PXCniazUUsTjsrQxmxRuY+oy
v0yejntZ4mbepxowV1HMwH+gvY1n1dIGv34cvX0TdvIuuEV/Tnkbq9MBm3wbq/Y2Zgb2yV5GM1DM
K2W+m3gtnokMaFmAlm+ivBh3H6fZG9bip1xjNGKljKifjPbvgj8Et4I7kMm3Ws7iLlzzMa8LrS+X
z+qMtUZ5p2Y5XEOWUIcVrMOK03O0WGz8HT1Xusy3M1voufWjN9gTP3rDTKts/AkypYM8J6Yv8r5j
8nLZ+BL4h6hv5XzM9CKiItpTbsx50edwrR15UQgtX+XnTdPrHKWNeH40PsXPy6ZcnP0lrvpH5px7
UT8UGq6CN6O9G3aygNfC+CueW+NJlCeBRzObCnmNTEWwjWa0fwUW9Q6zeSPajIZV5HNL4/ewsn9C
WcHZh3F2GKylGhq0Z9XN4Frc6wlkBS9iB6zhGTO+ix2kGbFxP3aNDs5PjOuRkS7HHrQB+eF81HwX
WU0P9OwBHwG/BX4Hes6Au8BzsDe9g312J7P5VZQXgF9GdO3FHvQ/OX8zPYIs7h29vAPcBm4G9/BZ
fvIyn8f8T0bLweAvWr5BrD2R4QnR+LLObeBmMGt4CS3n4qpfcQ0x19RzjXkWrKIBue4csB0cRWYY
R/5Zg2dSZLCmYtjPb3AvtDQ2cyw1oYaYR3EOmh/UeQe4DdwMJm3mh/mZ1PIKbOZ181C66nZoWw/2
gPF8asrD2J9GeYfOO8Bt4Gac5XE9zXNl2s3lnPssPwbPYP24yqQzzw+eEYybeR6MTyDrm6/zC+Ao
eDYYtsSZm2UQ1v1baFnDsdH8oPl1Kv/Z/Crxj1F/VOcoeDb4NfBjbG8424GaDtR8j3Nd4y/YQ6Xv
IJcuAH8ZPAe5ZSGeg76I3LUMWfFyWNQcWOxyzgMNNdD8S5SfxtPrdvTt96j/Pesx2dH/k1xjulfn
F8BR8Gww+9dD3CvT5/gZ1vJPms2zRxjOQNvt4PXIEBbCj/KQP8Rg/2tx9h2dXwBHwbPBr6ENzafp
fr6L+VV+r0jMbV7GVS+jnIcZ6MUsHTe3wRcK+KzGeGI9y0+spnNcY97NPTHtQPnPKJtgJya0n29+
H6ugMT+9vsFPrzQbbBVdpoXoG1usQPll9PxlnNWiaBX4dnMeseD1Mt9jeZLKG7jefD8s+ffgp/VY
ypFnF2Lpc2izFO1/Co/7E/zo9v/L3rnH61RtjX+sNdd69sU2SZvY5Gxyl/sl5BCRa0IqSXVck5DY
LslBUi6pKEpuSSq5dVPJLcktSZKQOo4jqVTu5Ihnv3N81zq/N94+v9P5nfPf7/34fL5rrDHHHGvO
Mceca831PPvBilqHFXg68gpdgV1euVrhGsZlAz7ZvZon8dwXbxWR39b9r9vhaml/LFcqU1dphqcK
u61n8Mw7k5Rotf+I3c04ZughZtBbzI5akN2xWYyHl/EmwcOu1kr8vKNtC3hPFbAjdmOh99Ae7IUH
quw8HIY7mNeH4Q5m62G4g9a+6eTHuOIyonROnwHMDFanjTCgbSt0jxy8AHOUhjcnZnPiEb3fMYsn
I7+F/XPUfYyZPk41iV66GiTuQf8+9vvgTXBO4rQypZPe6bB5UTMnpShyIVgDb+ewn0Kb0/XuEBTQ
91RBlTCL/FHZ17aFP+roBwWYO8Oj/Sb5sCjcpHmi+uDreE+tbywXsMepy7xupveIlOaM3eeM1NUq
J9LDvK70DPesd3VH7LJX14QmWprSnDvLHJ1Nbr1aDtezLi2Heg9tyXukiuj3ot+L/gj6A+i/QN8Z
b3/hKtHOazh3xh3wXb1uuE97lOB9rHmDHfdc7nHT1N7/QPfXbpW7kwj/TJt1Xaqre+1EXmb9YWb3
aqWL5BbWmSq0RLmV0jw8F+XRJx+3Hp5nLsxixdDSEXBcvHporV2sG+/pvtvZTEc/nfazXiVGOvlt
2tw0KOr4vDLIJv6v0dMvGZ3B2NwSW6qmOPugD7WPwSW6Rza8VTbRrm03u7ZNrMkPEIdijHsl9mXP
ki2FQ7cWJVKp9TNPCK/qfjzsHbidRfA4a2w/6vaj7kTk+Xot/yqu2JVxeY5df3d6NJYd7g5mRIDm
Md2VBxVp523YH+WKtCocgzxc9+bmXuTIpi8easPb9XnJPTfqrHw3uEzvC7TwW/I82k03IhOa0fcq
ZqXrVyf1k8iBw5TBnGAxK6fOiGtVDoeGQ2mVxrMDNtHnHatYzUItNQP1LhZ6+MlP/N+lhS/qvtvs
QT6iu3VTDbmZ7tbNQvqST1sSMoOCW4IiTjOb9o8yRxxHGpcJwSH9lCfxAs+EXXS37nqn7Smqe3Yz
AZ8DY2oM88JbdJ8evgtv1X2E+UX7nihEBFqyB99PrT/pPt0URF5N6Una8z0tfAP9MT7LyNbIJMpx
9QbwTvrbB9aOny31rlqEWlt05+5/pjt3M5b4FOH94T5a2AW2ZHTGM46tdNRc9jr6i9EUo53T2cVM
hg0jmR3KZObaZHY6k3VX5UrdTiQsyxP1Giwfgm+FD7Meqmxhq4h4aIWHVnhohuVh9noVVRNURLML
zfTAjbhHXb8UfIT98o3sl29kF1aX/d2zuldymeDs/V5YfsEVC/H8WQlvlbRu0AT5wYhoHlRvjqvQ
l4SXc2d3kQk/pXe9A7crNDPxWRf/Ue8awAd07+naTy/wWRGfFenpYXp6WGMV3KKeE03C7fAhzSI8
vBaR+HRFbk4cGiZaEyvlDezf9+j+3fWitb77Cj7luq2ZQV/i4QTeWuvdSlvlVh7ljKC04x3BaKcf
yorKftntr7V0PCyGpkEwxsn9A21bJTSst8HljMVP8JjSbFaGW5VBJfig1g0rc5WC+GwB68F5eBsX
xQoPR2A5Inw/7KsrXspGjUBqG+J5hn3fPbyl76tySoK7XhctDcsS4c1YNkHuoXLKRvWW2kafTMIk
+8G69CvKjTqMchPGZSZyJh7qY7NQ3w+YP2n8gyxG4TVyo4TexcxB7Z1ZjJwfeQQ2e2ElapWEmYxm
Ia0bztURD+ehr4Hly4zyeJX9n9DUTdSGUzTfsCyio+ny5GHWQOU2fC5CLk2bM4nhA6p3lmdo7Rlm
KJ/U574inpjcD5EX62fZsHruy8jl4Tj9lDwufQXOxX4YcsTCcDL6qO4S5CV4WwT/guYvyLuxcXq/
Xa6+Ea0EH4aDYUO4G45Qer5STqKpDkVpeiJPhS/BS2JZPzXYRd0TaCbDptR6AjmT0n3wLBqu4rdH
cwQ58l+fq5+GX1D6d7gKbwabFvAm9F/HsrZhPprFaJoh51KrAvJBuBa+BX/AsjXyGeQEchIWhvuT
FfTJkPZgL6dUY6LIFINZqvHotXcL/AT9V8gr4TZsoui1SzZyHmpGY6Gy3xDOhnOiUUCuDgVOhS8l
9el0TRR/1XivwhOUfoznaVHvkC+LIo9NEpsSUV/Q7KNVB5E/jfvSiH6lurrDqDtcNUJ8vJFYVk+2
oRfTafl0WjudtiknozkBf0BTQimRXAxmwQNcsQzMhtXgt1wrysAnkb+BWcnGjh2QL2Vkx0Q5qXp/
CfKVSd19f45cDz1Z4acoE2RaYogyeBcP5zUCib4qh5sZ65eiyOTO0E8bsX80yg28PUkbfsbm78Sq
nc5KN6cKk//KSdEonz+uM46eDo7pw2zHy2BDOILSEXgboRoXT9Vfh746lJjZel9AnhpTLdsQ7V1x
5LMZhdlQ5aaqN09QepJatWhhlOEn6RHx9/ZEI0JPn4vyGbk7NkuJ0vZo9dBYBTuIWDR/M5GLEZm1
2K9NXqNvpZAH42cQ8iylYRabFmTgGeI2mVJG07sc/Q8aQ+8cbU4QvSx6lEqUkkqXV5GsfSRW3qMw
ysMuMbOpOxs/av8JPrdT+goknnKUXh+Cs+DHuZc6nqeP6WheR74cOZtRa4u8lZZ/R2kRld2KMd9p
rqF0IJxO6WwiQLabasjRTM/SiPnl0Ucz4kM4A8898NADzzvjKKkcrWxbmNfrmK3fMgqsKl5A5K/G
T7QSboXf59bQSCJvjtZALCdgeUW0BnKVT9Ez+4JRzJ2NyD/nNnPtjO4jc1ltPtdYBVcjX4f+MH5+
RmYl9NNgRVgymrPYbITvxKtTLUfuFN4mbJZGMxqyAvhTiFIDbHbAaN0gb33uCy6qbk9hmPvey3AA
jNaKcvAZOAh9DnJj2JsMvB/9K/G9QPN5dCxrBKJ7R2fsWUP8rtE9hdFMEP/CcDL8BK6ErOfe64xX
LvIKeJa626LxQiaS3hHknrANUTqNnJfSVcgt4E3J09pC9F/jcxJcDBfF8ze6lmb+RjL/NDPiJtgM
/VrkOtg/iDfuO956rp4kN7gzeqzkpgiWq8gWZO80q/FO5EXoOyJH6yqjn1hARuWHD7HC8HySKI63
aEW6ida+lTtTP2PCQ27yUfrr6G2AZ1mH27OSLIZ3YHmWdTiDvkT3qcx4Xc0mt3VlqI+mPtGrz6py
Gn1e4rAqpq69BssWMdXDfEoXx8zmvtOHGGbTTl2XsindAt+iblveMZ7kHX4x3jQWS7zpLDPib9fo
t1Pq8J2c87xbLq/fcvQ+UfoL+Px3PXtP3lB53wT6zZw17Mj4tMVvksijM51PcLaq7L+PfDzYzV6V
z7z0+Vw6+WV0XPSNhKkQ3K1XD17QZwyV/cPBMc1GpTkevCT6fslZyldKrxe1mivDBbzTSMDKwXCd
m3iYH7jnXtMZD+e0NNGBWu1hTb6fcAamBlk64uYBjZhZpzYq+6P0L1z8PkrT3+zFm7OUTUqvZFQL
zXZl8KPS9UI51zymvcBPE32r4G+I/FDaURmOxsMZuBdOgG8YfZ9TQemvNLq7z9Z9vX8GTYGwE+3U
b5FlqEa2qyxfKZ29ypvUPqyPn2xqVTX6/b0yZpqOvplL2xbpO21qvQHroSmn9uFqah2IW6KlHdHM
NsN0tUHfIKZ+jyiIvc3VKNG2t1X29tEe43vK8KT+6g2y7/uq8VZTqt9AruHt5xuz+q22tv4Ex0r6
1sVf6T+hq64/Vlvuv6jzWmX/Ef8RxxG+frrtq703GbZXmnuwmerzXUd/kmMVM97xdeQrzcv4cbJ3
Akvq+k2p+wTypXg7oVnq/ZWrn/Uv1bnsa1Z09AvTzvya/z6f8vsJp2nk59O57JfVuaz2XhvYTimn
lMbgoTnebvKL6Jrpf4JPlU/7X+tdA3kRlq3xkKTuH5APwvc9jfBS2nDIu8JZVvb0DadbF53mnKef
Mp/3Tuq9wK+q66o/ik/t9Zdlf/D2aXuUXiO/kGr8ZXrn8r7Rey4sBisrnTdH+Rp5Eizg7cVyr850
5K+8YXo3wecn3jzHKd6Xej/Slsi3eDilLfHPiei30IOjykQm8t+Q8/Lt9DzIV6F/FY3zEzyfcD6D
TrAJ/FFpvoOLlWEG+nNKP4CPoSmHze3KxC4sK8DWlJZE7orcEcuDaNAHE5QpxZHLUvoePImGq5iP
kHsgj4Jt0YyGQ5UerfUbUPoh8j7ak8BmMlxA6Xrk15F/gjfAW9HTI3OeupG3LfAheDf8HMuayPTL
/MIV70NeR3t2wkNoXsBbd2rVwXIz+hLIS5BnEZNlyEPgc7A8tZ5PcXefRNFodFQOfoS50RipHGag
OYd8TTRGaJ6MRkplczvsCvvj7Y5ovKiVEo0aMjFJHIlGDfvF8CClJZUpxdG8R9uqYDkR9o7iw9Wv
pYVropioxt0TVY4iRpyDubA+VyTa3jFKiaS/Eg9kXTgFbsB+DtwOr4f0OogybRbtHIF9aTwQ89DS
BvLHL0PupWF/AJuFyA2xjHKsMbTK1IVaN7Ug7TTYNMPDOzATfVF6XY7IbMZ+KqXMkWAHtUpxLWJr
pkTzjhjuoi6xDSbAsvh5E5uq+CeefiPqLkXPLAujXO3FtaKZWDzKPfx8jIylP55aP2DzFIwyhOiZ
AVEmc90SxGqJ0juGZgbXivKwFrwatqPuNuQaeKgOv4V/R/8I1+qGfCN+6FfI1cPaWD6On2nIRN5n
fQjmwcHwJmyiK34GowxZQek9kHExRbjivZDIp6AJTnDFYeijNY05GESzm5kb5kNTALIyGLLC4M2P
VipWFf8o9tQNcuArcD76aG1ENp+g2Yi8l6uTV4a54x+nFlkXRrMp6tEqbNKxn4kmGvfV6NvDLEib
DWtmYhw+o1aRFcGXkDkVkBseLU+MpNYD2J9FZiYGw+Fu9IypIf5hZ/SsUQGrVkA++KzqQU+4HPuT
5Mwo8idarxZA1qKQeWQeQhOtnIepG40p424YqQS5ZG6DzDUzCZK9KVuVqWRFyP0rJNsTRDuFvico
DbA3rFGmLrxBry6ie5Dg+aR+WtQJNoE/Ks13cLEyzEB/TukH8DE05bC5XZnYhWUF2JrSkshdkTti
eRAN+mCCMqU4cllK34Mn0XAV8xFyD+RRsC2a0XCo0qO1fgNKP0TeR3sS2EyGCyhdj/w68k/wBngr
enpkzlM38rYFPgTvhp9jWROZfplfuOJ9yOtoz054CM0LeOtOrTpYbkZfAnkJ8ixisgx5CHwOlqdu
UermYnMN8pOU9ke+A30KpC+JI7AKpRNhb3gttdZw3WK0MGo5/Q3mwvrUpdfeMUrpkb+Suox+OAVu
wH4O3A6vh1ELoxGP+jUClsYDfQ8tPhlHvww5kIb9AWwWIjfEMhrrxpBaqZSmFqSdBptmeHgHZlI6
FZnMDHZgUwrPRMbQfvMmpVXxQ2T8RuiXoid7wygHeuEtyvAoVz9Gj40/Hs0PlD4FGR2fOJgBcAbe
onGsBa+G7SjdhlyDWtXht/Dv6B/BZzfkG/FDy0OuEtbG8nH8TEMmVj4zK5gHB8ObsImu+BmMxnQF
pfdAImmKcMV7IdFLQROc4IrD0EerAdkbRPOCnA/zoSkAmVOGcTR486M5znz0j2JP3SAHvgLno49W
FWTzCZqNyHu5OplgyHD/OLXIkzDK+ahHq7BJx34mmmhkV6NvD7MgbTasNolx+IxaxbgHX0JmQcDo
e7Q8MZJaD2B/Fpm5EwyHu9Ezpob4h53RM7sDMsFnJQx6wuXYkNVBtJIcRo5GitE0xD9BhpjbIDlv
JkFyL2Ur+c9Yh6znIbmaIIYp9ChBaYC9YX0wdZXypf+F6FuRra60VPQewzzuNM3Zd/fUtw1mLm8S
WlA6W/821mTr99PMNN6l+Krxv0f/uOr1Cxaif22hms7KcLsyqIz+JHX7U/qdMjEAuSdsjrfDkSXX
7Ri/zSgl+o5C94az0Twcv/GozN/W6VuUlrw/Ocv7kEzejSxCP0/r+tvQ9KT0aWQfD4fhYDifvmco
/VFEoIO+IfE38NaiJnJN847WVRvJ5X3FpfH7E0f5m9qE1fHTnlpNeENSTzXepcFMpy8UvxtZxDuQ
RbwPcUw+mavvqdrmbtW1F7mj7m39bSp7TZE7UdoEeRXybiyHI6ci16P0A2odQlMg8oZmf1J3+ldi
U4BaVWFXSndGpDQL+Sylz+KhFPoX0ddGrkBpAvku5LFRG1T2vojaQOlQlZPtc0+7TCiD5g0p4rgH
ebbKJh97+VylaQCPozmLPA3LvyrD7crAQ+/DRZSmKr2TyIdhVewFm8dhBTiG0sG0YQpyV+T5XPEH
bIYhb6K0D37S8b8Wzotbri3pjWYZmpVwAqSnpjmlFs2o5Ar+F3b1vDqpbwKz8dwvboPqv9IxMg2U
8hV1l8BJeOONh38ATQe1Ccok9btqDSltlHzZMSmtnT4/NtVU4x+N2oznudqGxOVoVqnsTULfPvm6
5qfaB+so3amlru86Ohl4bo++MD6foP1Fc8+6do6mtado2x6tFfanLwfRzyHrRmgtrzbXGoZcEj9V
k+f4BOGcxhNOULqnKeU+NMWwOYhcQGmupVU1GbUNXGsonnvSwn3KREBsy0UZknuTZp3a+AVUo7+/
41ZIZlmQX/uSKIz9QZXD67DJQNMpykOiXYyrZBCZAhox7xF63TGp72b70ML5yOnJWzTHkvq281LY
hqtvIBpNkbuqpXeSWlWRT2O5AQ+TkCei30k0tqAvg+YEpZPR7MHbZDQNsTyidCsO4xXlIe1vTV/+
Rhv2kQlRJk/RXrtdwF6ixLjDUYzUSeyTeKjMtepRWpX82Ye+jtKt7zouLWIb5QFyYDuet0Xxj6Oh
LW9CX/YRq0Lo88KOWPaJr3uOeXGO3DtOJkSWGrfiKrvcPk4mq80dcBKaW7DM4lpZWG6l1gZspsNl
lLaJ529115cEbV5KHz9GXwy+R3t6RZb0t1/Ua7V0WcRbazIqEUd1LllNNDQyXi88P806sJrorY2v
pX6qM1KFopWKWoeptRbLJNleFculZGamyomSko9MW8GIa/tnRjM6niPqrTNjVAr+iRb+GK94RbjX
6FW2xHN2mit9LZrL6s2tlk/TqurUitZV9TyGt8SHpTt51V3v6bntnHwzWXcIG9YBE82jidRt439E
5q9gNLWPa6K1EcuR6DsQ+SlKty6tYK3QVSUakfkwldJset2Y/u6Fj8NzeG7CeF0DS8KWsY2uciPi
cdSV7SldM10+rGA2vUxWnOOT3HPk6jny+RxjofIZ4jYqvosVQaO9nk5P60d3Mdacw4zOSmUKWZTC
XcZ8h2V3yD1Ojmoeumfgv7AGHmcN1BWmA+2sR5ZWJYe3kdWsRc5yLpZq/yr6Plg2R26Ffh4t34m8
CP11yR2wP7PvuD6T61WS03L3M17tdbYyptfTr5LRfS35AZ/XF9TW0vLR9CUby/ZJnnmoW0yKO59Z
8cg6+fxi9SzC77xJoH+nE79pVEo6+nTVi6gmeZt+yzrZSb8Jn+TvQZLpyNWQqyHX0O9pJ2vqd+md
vj/6Bch36vfH9Jv5Tl6PfBj5R5X1r3hc3eX6Kzfoa+q3AZ2fhfw2yyl+32alUv+OQET/zj2ZqX/N
kczUvwdJvpHoo79yk/Kg/sqNyudXqZwcnXhCf+Um5aj6TxxQphxB/lL9p3yH/AtyZNMO1sCyC+yu
v3ujbTu/L2pz4hns5yJHtQ7R5pPoS6HPr0y5ht5Vhkfo7xhKl8IU9Fdh2Zhr/Yh+Mz6ro6lHZCLN
WUpvw34CV9xMlM7CkVy9EZYVqauWVZGrIldPbEJ/BrkifiJ9GVpyM3J55Fvxs0uZmoLML/mkplJ6
G5rxeHtXfwMHD1fhoRpyNeQa+vfyzv5T5EKwILWa0ubqtLkrozyLnp6ilLYlXkJzJ1wPT1J6mWOV
lFeRX8PnauSJ2LwJn0K/FHk78gltof4Kh2ut5mENPpc353ORiZt+kp6sdv57bc95xkI/eXea41p6
fpVGMtIkR8JsSC08VDu/DkvqnqfX52chH8DnB8g7kQ9TSkad/wLNt/jRb+CIpHvjUg+J6Xb/gD6S
edeAHvfIiD5dcvrJG+J2fje2b5wtbmeRmysFJUMSUkyukAJSWWpJXblGWsotcrvz0U4ekAelm9wt
98ogGRvb55UUuVxKyaVSRWo7L42klXSUO9xV28twGe1Wjt7SXwbLOP6PwaiOlVS3ZpSWTKkqV8nV
0titzrfKneLLjfJneUh6yD1ynwyR8VJITIu2bZtLy/Y3XJ8tXTu0b5Ut0/ByGb8Z+ge3NpdxHqtJ
fblWmsn10kn+JEYqSAcZIWOkp/SRATJUJlAnTbKlrOid7o/SRNpIRXkUfWHJ7+JQQrKknPNbQ+pI
A2kqzeUGuU26uHZfKTfJSHlY7pK+MlDul4lxCy6RPFJSikp556GmNJTrpIW0lc7SVUKpJDfLKHlE
ekk/yZFh+lum3aoP7GZuhnfAnrAfHAxHdOvSJ8c8AifB6XAeXAKXdesysIdZCzfBrXAH3AP3devW
t785CE8qAx/mh8XhlbBe9z533xVcB1vD9t373ds36AjvgN1hb9gfDobDew7o0i0YDSfCp+EcuAAu
haud4y7BJrgV7oB7+vQb1DfYBw/CH+FxeAYmlWHQ595ufcJ0mB8WhsVd4YCwFKwAq8LasD5sDJvf
q37awA6wE/wT7An7wAH3DujeLxwKR8Ax/VU/AU6CT8OZcC6cD5cMdGMULoXL4Vq4CW6FOwfe3a9n
+BXcD7+Dh+FJeHZg3279EwLTYSYsDsvB6gMHVq2WqA+bwNawA+wMuztWT/SBOXA4HAMnwimONRIz
4Ty4CC6FK+E6x5qJLXA73A33wgPw0MBBXQcmjsLT8JwyxYep0A4c1H9gSibMgtmwDLwSVs9xkUyp
AxvAJrAlbAtvhvo07ru1J/NfOBo3z4tKsf8nyeOHQ//vDN2KEbpVNEVS/2NnAWeR7LlV72Lm/Z00
bp3Lw28u/zuS51bv32aB302fEfGdVz3jbY/eH/Qp8Xfzkt/Ny/8H8/9uZtNSw9H7FbUHv9bZf0rj
7lSFpPC/KF2G5Lv7U8l/6XiFlPqXjqWlzL9w9Nyd9J/zn8fEc3fwf858v4vV3NNGjrvrT5F5slTW
yQ45ICe9wMv0Snk1vSZeB6+7l+ON8aZ487yl3jpvh3fAO+kHfnG/tT/Mn+BP9xf4y/3N/h7/kH/W
pJssU8HUMy1NJ9PbDDMTzHSzwM1BvVZqlLOmzUXnXS86n3jR+eO/Og8uKk+4ab5bUrxfnafXvPA8
Y+6F9e3pC/1ndrrwvKBc6L9g5kXnZS6yb37ReeeLzi/qT8E9F54XKnfReduLzode2P5icy4sv3zl
heelr7zovPKvzt38K131ovLRnPtufSgQ9bBs2+hYLup54HKukFurysTabfFxT3w8EB+P/pZ1hTfi
48r4uCE+br+wFRXthb2suPzC8yqjL7Sv8tWF59W2XHhe/e2LzpddeF6jw0XnN1903v+i8wEXnT/9
qyxzQu1pF50vv9C+9kWj9D/Kt150vu2i8+0XjmLdrY7WRaabN1V6ejNZbbu6f+Jm6hTxwvzhJdwr
Ckgio4XdkNHcrrNr7FqnSXg/eT85u6PeUfG8495x8b1T3ikxtpFtJIG91l7r7puaD75paprr9fwC
fkGn0b8gstoek9fVrOzOC7ndyACZKRtkn5z1Ml0bUl2rMjPaiZ/RPKO9Y4uMGx1butbnd2tyttst
VHV7nvr2OzF+ftem7zlusG6n5Rd05z9w3GB3iu/OdjtusHscN7m+aoZmSUm7z7V1jSv9G8cNdr87
rnXnX3Pc8CvLA7HlN7Hlwdjy29jyH+1tRXtb097rae8/StpQcgMlbX9dYjfTwi20cCst/EfJNkq2
U7KDEl9SfPfPTbM8vn5zO7+f30W1oIuqybguo5mL+hq7RhKuTWtdpIyz0E8jo7u+m1qufhfGSxgp
zzvrnXWjluvlumiFvnvuwW+I3wR+U/wsP0tS/ZJ+SUnzy/nlJN00d6OZJ+wadpWMsHvYXfKGPcOe
YsNeYS/JFw4IB0j+MCfMkUvCweFgKWCzbbZcakvakq5PpWwpKWjL2DJSyJazbs9nK9gKUtheaa+U
IrayrSxZtqqtyu9y15BitpatJZfbq+xVUtzWtXXlD/Zqe7Vk2z/aP0oJ29A2dKOj+XYF+VbKNrPN
pLS93d4uZWw3203K2h62h5Szd9m7pLztY/tIBdvP9nMLRX/bX660OTZHKtnBdrBUtkPtUKliR9gR
UtWOsqOkmh1jx0h1O9aOlRp2vB0vNe1EO1Fq2cft41LbTraT5Sr7lH1K6tipdqrUtc/YZ6SefdY+
K1fbGXaGy89Zdpb80T5nn5MG9nn7vDS0L9gX5Br7on1RGtmX7cvS2L5iX5Fr7UK7UJrYxXaxNLWv
2dfkOvuGfUOa2aV2qTS3b9u3pYVdZpdJS7vcLpdWdpVdJa0Z7+sZ7zYuV9bJDS5XNkhbu8llSzu7
2WVXe7vFZdeNdqvLrg52m8uqm+x2l1U32x0uq26xO90c6Wh3uzlyq93j5kgnu9fuldv4TezO9og9
IrfbY/aY3GFP2BNypz1lT4n+zvdoNz9Gu0zK5+WTkV6Wd7mM4n9GHeN18jrLw14fr6+M439DneDd
5+XIo94Eb4I84U3znpVJ3jHvmDzpnfZOy1PeL94vMkUXGZnqJ/yEPO1n+BnyjH+Jf4lM8wv5heRZ
v6hfVKb7V/hXyAy/vF9eZvpV/bYyy8/xB8lqf4g/RNa454hh8r7/Z3+ErPXH+GNknT/WHyvr/Sn+
FNngP+M/Ixv9ef4u2WTyuvXnnKlpakrSNDZNJNe0MC0838wyszwT5ATPe0HYLezmVQ97hD28GuFd
4V1ezfDu8G6vVjgwHOjVDgeFg7yrwiHhEK9O+FlinFc3/cb0Lt6R9LF5PC+ZkT+jqX9/xm0Zs/1X
83bP29s/kXdk3on+WevbVJNqS9gSJp+9wl5h8tvStrS5xJa1ZU0BW96WN5fairaiybSVbCVT0Fax
VUwhW81WM5fZmramKWxr29qmiK1j65gsW8/WM0VtfVvfFLMNbANzub3GXmOK28a2sfmDbWKbmGzb
3DY3Jewd9g5TUv9zanOF7Wl7mlK2l+1lStu+tq8pY++195qy9j57nylnB9lBprwdYoeYCvZ+e7+p
aEfakeZK+6B90FSyD9uHTWU7zo4zVewEO8FUtY/Zx0w1+4R9wlS3T9onTQ07xU4xNe3T9mlTy06z
00xtO91ON1fZmXamqWNn29mmrp1j55h6dq6da6628+w8U9++ZF8yf7Tz7XzTwC6wC0xDu8guMtfY
JXaJaWRft6+bxvZN+6a51r5l3zJN7Dv2HdPUvmvfNdfZFXaFaWZX29WmuX3fvm9a2A/sB6alXW/X
m1Z2o91oWtsP7YfmevuR/ci0sR/bj80N9hP7iWlrP7Wfmnb2M/uZaW8/t5+bG+0uu8t0sF/YL8xN
9kv7pbnZ/tX+1dxif7I/mY72qD1qbrXH7XHTyZ60J81t9rT92XSO91L65FOTtba8S+fQu9273al7
eD3EC94J3hE/cT5xXkxqg9QGbvb8Z1Zjl7n/uxr/f74a/3f2ZZF9FfRpy7s78eX/5tj/5th/KMe8
sLd7ns/vlfRrmuuCjlJM6kljaSntpZPbL/R2z+/D3PPABHlSpstcWSBvyHJZK5tlu+yR/XJIjrsn
e/ESXkbaUDFpA9Ny0u7nOChtGMfBaQ9wHJL2Z3fMcdIIjjlpIzkOShvFcXDagxyHpD3kjoOc3RiO
OWkPcxyU9gjHwWljOQ5JG++Og53dBI45aY9yHJQ2kePgtMc4Dkl7wh2HOLtJHHPSJnMclPYkx8Fp
T3EckjZcfFc62nFQ2jjHwWmPOw75NyIylZ4PTHs6jswzcWSmxZF5No7M9DgyM+KIzIwjMiuOyHNx
RObEEXk+jsjcOCIvxBF5MY7IS3FEXo4jMj+OyCtxRBbGEVkUR2RxHJElcURejSMyxfV/YNpsIjKP
iCz4NyPyehyRN+KIvBlHZGkckbfiiLwTR2RZnCvvxpFZHkdmRRyZlXFkVsWRWR1H5L04Iu/HEVkb
R+SDOCLr4oisjyOyMY7IpjgiH8YR2RxH5KM4Iq8RkbfJlDVEZMO/GZGP44hsjSPySRyRbXFEPo0j
8lkckR1xRD6PI7IzjsiuOCJfxBHZE0fkyzhXvooj85c4MnvjyPw1jsy+ODJ/iyPydRyRA3FEvokj
cjCOyLdxRLYQke1EZDeZsv/fjMj3cUQOxRH5IY7Ij3FEfoojciSOyNE4IsfiiByPI3IijsipOCKn
44j8HEfkTByRv8cR+SWOyLk4IufjiCTjXMmNIpMuUWTSvSgy6X4UmXQTR+Y7InKYiJwkImc1U/T/
adR28zato5T3tvvPmdbmBtPT3GV6m3vMQDPIDDH3mz+bcWa8mWAeNRPNY27vst98bQ6Yb8xB8635
znxvDpkfzI/mJ3PYHDFHzTFz3JwwJ82pvLX1/1Hytnnb3AVm61/nmlamlfimjWkjxnQ3PSQwvczd
kjADzABJNTkmR9LMYDPYPQkMNUMljxluhkuGGWEekrxmhpkhl5rl5mPJzFsrby3eMmRJelA8+EOQ
HZQISgZXBKWC0kGZoKz2zLXoFG/XPSn8q3cTFXkf1EctXM2ysUWxX1lc+asyF0nTx1lLkBnob4GV
C8pJnvi6mUHBoFBwWVA4KBJk6W/fOYv/vq4vpSRfUCC4NAiDRJASpAZpQXqQJ8gI8gY2yBfkD/R9
V+D6NtI1Qev4wR+DBpIRNAoaiXVltaWwecnMN4vMq2adWW82mI1mk/nQbDYfmS3m49+KuL4tMy+a
F53Hl/Xvms1Cs9DFe4lx66iL3AfuevvND//H+4vOaqErXW5WmJVmlVlt3jNrzPtmrfngt8YY7y+Z
l5z3+Wa+fiPTLHLeXzVudXYt/Nh5136o98qS+Ztef6MfxGx/HDOt9zuzi3qaDa5e2M9fKg/JGHlY
HpGxMk7Gu3n9qEzkfxd9QibJZDfLn5IpMlWelmdkmjzr5vwMmSmzZLY8J3PkebcCvCDz5EV5SV6W
+fKKWw8WyiJZLEvkVXlNXnerw5uyVN6St+UdWSbvurVihayUVfJf7H0HWNVI2/bMJDlzSHJCFRAQ
QVFBUQ6ISFGs2BUL9oYgKlhAxY4FFMta1y6iIPbexbUBVuy9IHbsXVAUEfiejGVx1/13//f79t3/
+6/XuZyZJIecPPPM3Pf9zOQkB1AKSkVpgByH0GF0BB1Fx1A6Og44chKdQqfRGXQWnUPnAVUuokvo
MrqCrqJrKAMwJhPdQDfRLXQb3UF3AXGy0H30AD1Ej9Bj9ATw5xl6jl6gl+gVeo3eABrloLfoHcpF
79EHlIc+onz0CRWgQlQEHRqTVqQ1aUMCSFvSjrQnHUhH0ol0Jl1IV9KNdCeBpAcJIsGkJwkhvUhv
0oeEkjDSl/Qj/ckAEk4iyECSSK6RDHKdZJIb5Ca5RW6TO+QuuUeyyH3ygDwkj8hj8oQ8Jc/Ic04k
L8hLTiKvyGvyhmSTHPKWvCO55D35QPLIR5JPPpECUkiKAILUu+05jucETsNRTssZcK241lwbLoDr
wnXlArkeXH9uIDeBi+UmcpO4OdwiLp7bwm3ltnM7uN3cL9wZ7ix3jjvPXeAucpe4y9wV7ip3jcvg
rnOZ3A3uJneLu83d4e7yPnwN9b2t/CX+Mn+Fv8pf4zP463wmf4O/yd/ib/N3+Lv8PT6Lv88/4B/y
j/jH/BP+Kf+Mf86/4F/yr/jX/Bs+m8/h3/Lv+Fz+Pf+Bz+M/8vn8J76AL+SLBJ1gQuvQurQerU/9
aAPakDaijWkT2pQ2o81pC+pPW9JWtDVtQwNoW9qOtqcdaEfaiXamXWhX2o12p4G0Bw2iwZBCIPWG
FErDaF/aj/anA2g4jaAD6SA6mEbSIXQoHUaH0xF0JKQoOpqOoWPpOBpNY+h4OoHG0ol0Ep1Mp9Cf
6FQ6jU6nM+hMOov+TGfTOXQunUfn0wV0IV1E4+hiGk+X0KU0gSbSZTSJLqcr6Hq6gW6km+hmuoVu
pdvodrqD7qS71He/0l/oHrqX7qP76QGaQlNpGj1ID9HD9Ag9So/RdHqcnqAn6Sl6mp6hZ+k5ep5e
oBfpJXqZXqFX6TWaQa/TTHqD3qS36G16h96l92gWvU8f0If0EX1Mn9Cn9Bl9Tl/Ql/QVfU3f0Gz6
gebRjzSffqIFtJAWaZEW05V0FV1N19C1dB3NoW/pO5pL34vDxRHiSHGUGCWOFseIY8VxYrQYI44X
J4ix4kRplBQljZbGSGOlcVK0FCONlyZIE6VJ0mRpivSTNFWaJk2XZkgzpVlSnLRYipeWSEulBClR
WiYlSculFdJKaZW0WlojrZXWSeuljdImabO0RdoqbZO2SzuknVKKlCqlSQelQ9Jh6Yh0VDohnZRO
S2eks9I56bx0QbooXZIuS1eka9JdKUt6ID2SnkjPpFfSGylHeiu9k3Kl99IHKU/6KOVLn6RCqUhG
MpaJzMm8LMgaOUu+Lz+QH8qP5MfyE/mp/Ex+Lr+QX8qv5NfyGzlbzpHfyu/kXPm9/EHOkz/K+fIn
uUAulIt0SId1RMfpeJ2g0+ioTqsz0Ik6SSfrdDpFZ6gz0hnrTHSmOjNdCZ25zkJnqSups9JZ62x0
pXS2utI6O529royurM5BV05XXrdYF69boluqS9Al6pbpknTLdSt0K3WrdKt1a9jqM5uRZTOjY0kC
AQRl853LuCbA75e55sDvV7lOXGeUwXXjuqNMxqE3uQguAt0CxotGt7nZ3GyUxS3kFqL7jNkfMN56
yHjrEeOtx4y3nnC7uGT0lDHEc96L98aIzZsSQRRErBeMBCPsymZG3TR3NQ/xY6qn7vglmyXNESeJ
iwkRV4opxEI8Ln4gbmyuNIjNkq4Cts9GBqAOygDntwAFFAcMcADQGb5CikVEOc5qG1hNXaMxQubI
RjoG21eldMgzpOOQZ0qnvn32KtTSkBa0hCWyBQVQ8fPqkZSh7pcyIT8p3YT8tHQb8rPSC/UvlRLq
GRVz9YyKhXpGdq4CdtavazQGsHVEESE/pkjfHTFkR4zYEePvjliyIyXZESt2hCAD8JoefOdJ1Lcl
+RAfREgD0gBxpDFpjHjiT/yRIM4R5yCNmCwmIyq+Fl/D+Yiwhpz/mzj2e4b9/5tf/z0Mq3LoX+XN
v5MzTWhP2ov2oaOAgVTm9APObMbYrBUw0wzGkx2AI1V2/MyNIX+RFaP+hA9/z4aLgAd/ZcDi7PL/
Ght+YzvgxYXA38VZsQ6oD1V7fFYequ5oCcoj74vuyAfV0REUx1KmORJAcXyEXtsOemp3tV9+5U7S
/3velI1kY9lENpXN5BKyuWwhW8olZSvZWraRS8m2cmnZTraXy8hlZQe5nFxeriA7yk5yxR+ybeyP
+VYxUERF+kusu+H3vKsYKkaK8e/Y95iULh1nHHzqhyx8FXg4Q8qUbkq3v/KxYq5YME5+8YesXPB7
XlYslZKK1b/Ezt9xs1zwb2DnFpjgEhDKWmFHZIZb4gBUlq2UOuJuOARVwr1xb1QVh+JQ5I774v6o
Gg7HI5EnjsLzUH0ch5egbngnPouCyCASiUaToWQ0GkfGkmg0mYwnk9BUMoVMR7PITDIbzWNrnovI
fAJoz2L8pZzMmaAEzowzQ6s4c64iWs05cy5oH+fK1UepjPEvMca/zKK3K3wSfxY9FYwFY2wp5Aq5
uKTwQfiArYSPwkdsrYHmwjaaKZrpuJRmpmYOLqOZp1mIK2jiNEtwJU2CZh120WzQ7MA+ml2ao7i+
Jl1zDrfVXNFcwd00GZpM3F1zU3MbB4E2KMAhmiLQBjHUg/rg3bQmrYUPaJ20FXGa1lnrgg9pXbWu
+JjWQ+uB07VeWi98XF0/wye0tbW18UltXW1dfErbQNsAn9Y21jbGZ7TNtM3wWW2ANgCf07bXtsfn
tZ20nfAFbXdtML6oDdWG4msGEPbjDDFIDMbXxRCxD74hhomR+I44VByKnwHPLsbPgWdT8Dvg2Q+4
UCJSZ0KlrtJI0kNOkO+Rsbrpujhy6PP9LRCNbmIrLl1xry97dhXbg5E30nzRHuVB07jD8ZWQ1HwT
qIKVrFS39n/Z2g9bNyGpd9lUwpWg11TBVYDuPLEnnLMhbgjk0hQ3RTxeiBeyu2zSUQ/BSrAWbIRS
gq1QWrAT7IUyQlnBQSgnlBcqCI6Ck1BRqCQ4C5WFKoKLoBdcBTehKr6IL+HL+Aq+iq/hDHwdZ+Ib
+Ca+hW/jO/guvoez8H38AD/Ej/Bj/AQ/xc/wc57jeS6Xe8994PK4j1w+94kr4Aq5ov/OPh5M4Qmb
aeDZrxWM2WqWJSQO2UDioeUqgKXOSL0vzQWSFlrVG3RiDUgi8oUkofrID8moKSQFtYdkiDqiTqAP
u0EyQT0hmaI+kMzQYBSJSqARaCSyQGMhlYTRSZAVNsRGyBrGqBUqhW2xLbJl9zSUhvHaEtnBeO2E
7Nmqbhk2UsvifrgfcmB3OZTDQ/BQVB6PxqNhTE/BU5ATnoqnoYp4Fp6FnGEEx6HKMIJ3oio4Fach
F3wUH0Ou+BQ+haqy+SZ3NvI8mKZuwmadurFZp0A2F2ZVbC6sMrubyod0gRYrRVyJKyhHD+Kh/kaM
1IcjTUgTUI6tSWtQju1JeySA/glBGlA+fUE5ThZ/QlpxmjgLSeIqcTUyEteKG5CJeEW8iszFDPEG
shRvi1mgqaOkMcgeWGQCclAZAjkBQyxDlVQ8Ry6A51eQK6D4TVQNkPw28gAsz0LVAc8fIE+IsR4h
L8D0J8gbcP0Z8gFsfwG++q0tVZgtjUkY2GL7nS1exAuOqBZxpCXENDyzSGAWaUDndUKU2aUFFTcQ
GTC7RGaXjtllwuwyEzeJW8CibeIuZM1stGM2lhEfiU9QefGZ+ArsUi2twix1ZZZ6MEs9gQdXQpyw
GqKNWsxqP2Z1Q+CnXNQU2KkAIpTPq6/qrxx7MotcVBvVJ+0h7y82unz5jCOM3ll4/rd9BK/DW2DL
7NvnYAT8oA1qEGg31hI8863A2kPD2oOy9tCy9jAA3dsViaxVJOZtmbWNTuwodkQKROZjkCFEX7PB
53PFxcgGYrBdyEHcLaYgD4jEXiFf8Y34AYWAhpiE+oNamIVGgjrYgGKA+3eiecD1GWgJ8/lu5vNf
gMHvoj3M83uZ5/cxz+9nnj/APJ/CPJ8KzP4KpQG7v0EHgeEL0CHgcw06AxrHEl0BXWOPboGWqYge
giqR0EtQF8boDXC8FUQAgIQQIQ1ESI0gUV11lgG1Uu+2QW2kUbIfOgN/Uwov+sufY0+7/Js+/a0/
oCDmVT3r8y2L9Qf9r/0BBSDfb/sIasDW7s2+fY4gTowXV8B3porp0MfzJHXkwF4W5X++Ent2Dfov
V/n1Wr0Bzf4FdIe/LMGwEDEsxAwLOYaFPMNCgWGhhmEhZVioZVhowLBQZFgoMSyUGRYqDAsNGRYa
MSw0YVhoyrDQjGFhCYaFFgwL1d82HwQLZNKI24Nq/+laEMEiNoGrLIMrYjfsjeviJrg1XF0QDsMR
eCjopxg8Gc/Ac+FbE/EqvAFvw7vxAXwYn8DnoG1uQDs8xi/xW/wRCEhDZGJCLIktcSAVoY09cEWw
3hHaojIrOwEDq2VX7MXKbtibld2xDysDcQ1W9sA1WRmEfVkZjGuxsieuzcoQXIeVvXB9VobiBqzs
B6yuluHYn5VxgoVa8rsES1YmCyXVUsnXSmopmGpltdSs0OpYuV+rsPKA1pCVBVojVhZqjVlZpDVR
S1BQpqysZYjZ94RhJ0AjQ9AaBLacIe8EikPVL4BJYCX0RLDRFfJA7AZ5D1wV8iAMWgZsqwZ5T+wB
eQiuDnkvXFe9/wTXg7wv9oO8H2gWAlY1gjwCN4Z8IG4C+SDcDPI43BzyeNwC8sWCGSJgbwnIkwV1
9iVfC44BS6FXg5085Pu1oHnARo16R5WWQl6o1UJepDVABGwDBaathZxgbHUBzu8HXB+FJqBpaC6K
RyvQBrQD7UOH0Sl0Cd1A99FzwJcva4rQkyyhrztAX9JjD1wDelMj3AIHQGsEglX98DporThoofWs
7Io3sLIb3sjK7ngTKwPxZlYGAbqrZTDeysoeeBsre+LtrAzBO1jZS1tKLcFGW7UEK0uzcr/WjpUH
tPasLNCWYWWhtiwri7QOagkWl2NlLbyU+S+BeS6ReW4Z81wS89xy5rMVzGcrmRdXMc+tZp5bwzy3
VvWH1oy1eAnW4uasxS1Yi1uyFi/JWtyKtbg1a3Eb1uIY8YaI3VnOMaxAbKRjQ/VnIurThFuw+/od
kRvTAWw2DJuzvmbB+oil+t3qWXDJb7U+ak9SsRfwZD7rKyxXV+mwESAUwiUgrsIMiQjDF5VXLdEU
3Ba3xx1xB9wO9xE7AAN2+jw3TYaQMWQymcfFcWu5bconpUApVIoAZZeIS8UEMVFcJiaJy8UVgLhp
4kHxkHhYPCIeFY+J6cp7hSicwiuColGoohXzxI9ivvhJLBALxSIJYE/6WZotzZHmSvOk+dICaaG0
SNolJUu7pV+kPdJeaZ+0XzogXZduSLekO9I96b70UHosPZWeSy+l11K2TGWtbCCLsiTLsk5WZEO5
kuwsV5aryC6yXnaV3eSqsrtcTfaQq8uespfsLfvINeSasq9cS64t15HryvXk+rKfIis6RVFMFFPF
TPmg5CkfFWvFRlHXQcuzyBOxaFMA1dUUOC2M9APlEAlRpUxGQ1SpY/fNKiyGNGSRoRGb/zXmtnJb
kYlms2YLMtUka5JRCc17zXvQjBAvIQs1XgJtdUt8gJzUqAmU1GTQD97SRlAO9SDiz0DNIOrPRM2Z
fmjB9IM/0w8tmX5oxfRDa6Yf2jD9EMD0Q1umH9ox/dCe6YcOUiEoh46yEaiFIKYWRjO1ME4pAWph
PNi5B3X6Kx791zz4t/jpq4dE1pqItaYBa0cT1o7WrB0dmOWVmeUezPJWzPIAppPaf44+Bfa2Qag3
Qerccl1kW7z//7YX/3F//Nx34AzGrKcg1lM45mEN86fC/GnI/GnE/GnM/GnC/GnK/GnG/FmC+dOc
+dOC+dOS+bMk86cV+M0CWX+5eklQil29Apr3y4hVxzzrp4j1U8z6KWH9lPvyt7JgWOxvLUGVfEOB
ryOdIQcbBawnC6wnU9aTtZ8jafwG5+L8L2rAmJgTa1KWOHGNhWAhROgthAqDhSHCMMVeKauUUyoo
TkolpbLiorgq7oqH4ql4KzUUX6W2UleprzRSuik9lV5KH6W/Eq4MVIYow5QRylglWolVJis/KdOV
mcpsZa4yX1moxCnxylIlUUlSViirlDXKOmWDsknZqmxXdirJyi/KXuWAkqYcUo4ox5TjyknltHJW
Oa9cVC4rV5UMJVO5rbxQXivZylsl9z+/9PjPfZ//Y7/0MALN30swVfKB82v9pfvaYSTiMM2NYnch
a9W7dL7d4/N/uE/n2x0+cA5Sk3QrNtOh7mkKCPRtvgC/Re9Bo1cjnvCJerDPn7Qi7UhH0oX0BKyK
ANQbra6r/Sipa2nFE5zl++T5+6SuvBVP6jrdD1O936QG6ired8n/90ld0SuewJY/SMAH3yWw+fvU
8UcJ+OO7BK30ferG0q/bPX+TekMK+4MU8aMkFX6fgLW+TyV/k8p8n77Y9/l62Rn+Mz/yB/MjGN0C
/qwBXN8IVHYAexbL1yewqE9j+QnNQvMh+klCa9AmiH/2oFR0FCKgC+gatJ+erTf/3+ae/1Lu/6/k
P5wF+TxHIkMxX417UB01FgCuM2fRg7rOgrETxNEE2H4e1OfjBVBfiNU3iC+FyIvgnfiV+hRa/Abi
lWz2Ho53OBfq73Ee48x8qH/ChVAvIupbUAjhoc8JRAN1StQnt0oE4m+iY+8UMSIQYxMTYgb1EsQc
6hbqO0KAV62hbkPsoV6GQORGHNS3jwDHOkG9IqkI9UqkEtSdiTNS36pSGepViPo2oMVkMdTjSTzU
l5AlUF/KNWRPkm2MOK6JYKo+q04AewUrwU99uqLQEHFCI6GH+qxwIRTqYeqbiYGrh0F9uPrUKiFW
iIX6RCEVqW9ZToP6QS0gs5ZAFEm05Q36ImzQzwCUnkF/3VqEdet0EPXq1uvSoH5QdwTqR0GpYsUW
dAYHarKIRXiAyobE0P7z76yZZwgK+vLr4F81CGYaBDMNgov9ihUzDYKZBsFMg2CmQTD77QlmGgQz
DYKZBsFMg2CmQTDTIJhpkM9XSJgSwUyJYKZEMFMimCkRzJQIZkoEMyWCmRLBTIlgpkQwUyKYKRHM
lAhmSgQzJYKZEsFMiWCmRDBTIpgpEcyUCGZKBDMlgpkSwUyJYKZEMFMimCkRzJQIZkoEMyWCmRLB
TIlgpkQwUyKYKRHMlAhmSgQzJYKZEsFMiWCmRDBTIpgpEcyUCGZKBDMlgpkSwUyJYKZEMFMimCkR
zJQIZkoEMyWCmRLBTIlgpkQwUyKYKRHMlAhmSgQzJYKZEsFMiWCmRDBTIpgpEcyUCGZKBDMlgpkS
wUyJYKZEMFMimCkRzJTI12eUfHtiifVgKM3YXmTdVx9j3VtjUHFio4nvdZiSxBjrDrArgGDsKukN
NEIlhSNWAtL30IiVNJjHMdUJ5hPb6FvpnYvtsUmyHWfDlpRqIH8UhAajcADREBQJ/9UlJl+9fbGT
8WYV6HJ/z5zKU57UxZYDn/10/Um9vecSY8wr6mN4E30M+ZjIEUwAHNLQ1Bo1Jhuf980Nfn67tl73
7UoxD9cU4VpJ76Th2vKSaZl64REjBoX27hNp5xjsZOfq5VXdrnlo8KDwweG9Iu3qhQ+KqOJqq7f5
/OES3x8JH9QjMjR8gKu9vrR6nDO1/PV46/DwSLs6QyL7hA8KjRyht7XQeVXXu7rq9dX18K+Thc5N
7+pW1fXL5j9wRTG4TPFmUd9UFQOwAvtFEoMxWkv2p0U89MluYe2YsGB4N/3TpLXTy3X/UDiv2fLk
wiVJdr5RrZIWJ80MdOt7vm7PES83DD0ecD37WfxEm5kJE3ptP9J3ZFDZK6Vq3DLEsx/PP5xSuVdc
XJ/yi855O6fIOzuUT2vwSPT1nO+81tFrzfPG4+tmTTDcG9evbY8NMVHLAisPa/Zk0Y6ePnEtbVy1
DmYJax/9XMnyYc2FwWaBHYSQhFLVW096v/rVXHLU+mJKW7/tU8aleD8PmNtiU8Hqkf0jW2y2PDXf
wNEetZ8VGFp9b1MTWqNdUef8Fb1E7aoL0e3av9rl0808ehh/PffApnHzCrecHntltdWgLjVO7Hut
XV5Gv10Te3y73TDT2NuEg46/PHqNPnqlPjoJWrMU5qPj9NELxhl1PhfxKnTQ0rKtxphtaz6j6OSy
Qf9+/8X8SR/nVB/OeyylTs9ZYFntxW7scG2YcU6XQLeEpdJJX+HnyTOPez+0z37dfo7zzsSG6UGv
Pl095ePTaa1HQGihQ/9ax0+tuyVE3XSdXjPBKCJsb6GJv2Vo6qdz9bKMO9n5Pw0atXldyfRK1ctV
PhCyzOSncobBy98H2OTZH79SIqf1hgH13GhBjMWHB7376Vrl7n/T+tj+R4f1n+xcDSaXmudk1fxy
KbLyzbg73I7Ob7feTG//MqTxsdYBu3ZwjiZFs6681s4cs3vBkfXVne+PvL9mWNbQRHQurFbaBY+f
7tQxWVMtzDoss9rdSzb8/TV+fHqnqp4DmtvogpLFpGkXLwfUanDapu2qiEwT70lzhiSsvpAIqBCo
j+GafUYFscp64xsti7osOZn6FVNK/VNgAOPe0w3+AQK4ARi4usFmta9gMIIhKJxEY0ratnE11Rur
G1pTsX2PwX1CB/SOhK8x0ivqTmpKW4f07B8+oOfXCxP/6MLK6u0/X5hV8eM9Q+zahPYeAGe1a1mv
zp+iQvKI0Ve6bvfzWuO+wfV6XrlqjYel5pdeesxv4KvzDR5fmnaob7PWQW8XkUPNrzXu5+LgG5Jy
pmyy1Ch57JCbfvvXzVRaHilXKTvxka5s6fN1HD4GLTpb0m/lnCalF53e7lLmUJPKUeEZJWx9pnkZ
ed3c7/S2l09l7FZUWKHRqp398KT4/D3bgsfG5HVJjJ4QO2NL9u65y896rmoZa1FhUoub+lxU8+3R
vJrRBya+6Oe1uop77o4qm8XRQT8P7xW/cLBu4ubswzl2v/ibTA8+6Zzh5lfy5d4m831atrE806vV
iHUbJ6W3802IaTl5gLC1Wtooh/2te9Vc1OJUpTFVB0xoqDm/9FyTiWTARLQiddLtNl9Q4aM++r3e
VAWFcrysFzVaIDRBoBz3vwMqDNVrNFVfOynoOSj0pdQdCm/Om50qdWYoiui8+c31wy3iWtWvsrx+
8Gu9pB425HkYRhOLDR2GMaPWbxrTpHz2mX0tIpM6VIisOGT7xIL1zeYOR82fnHhmeSP0iJIUlUPq
HT0x6dSHNqcOJuxvF/46uP7a+ujl/PS4yza7pYSSurlXr9tudBr96sWqwRtm3vKaUXNh2D7P/hcm
by5bcPvJlVCDnyfvL7yL9rrnvI/KMzKpIjxzmj+nbl/HgcmeM+9Q3fGufU7vH1enb681e5P3znA/
kc0ZRY18d+FO3dujCu/e3VCYe/uybnvEldlZ/rs8k6IqX6qZ6S4FVScJ0WFlp+R2CZ65pdNer6uB
09pOsKr6zmdhYoyc1H3qdufkZStPrr9utytFXzLWzkxXcV/rt3XudNNnzXYMnZQWcS9n9foz4+oO
GqoAxoQBxrT+gjE9DIc3ZwqJKz6OBMCZf3BUfwWcqno9IE5VABy9l95N3ayqbuoj/5ZL+3Kc+4Pj
f4o1SZni9LMH0xovPr3O231j2Y59M/sdsC+TPDf96aaUo5fLH3QznrrvelfnfI92tiUqbZqpu2m2
fIBjs7HmtepsmF57a4PJuozouRsXaM61rz+0y9M3n5R7YyOXVz0Z+eBVVo9lY7hkv6LLviaXt5zo
pjs3KjvZVPcpMMwxdsi05I37Yh9b7Jh14J35rqCuL4xve7+07zx187jBh/yy5k0ZFrj40cZhadWn
VzVzMc0MOr7Jaq3/wt4bL9l56Qfemd67wb2jNm91LSPruDwWHMLs+zbeMvvwNq9jdVf272LZZP3M
qzPG+w4XG15bsW1C2UP3skf12tokcn/5Ok3je5gFttCnx+SckyKiXrZtPuyCtu3Q6C9Y80Ef/Y61
fSlDdcTCINSkFhuwOfa1Z0S1+hDQdOEDi6th492FKuUf/xiaVJwoVZa31JuP+/Ewr69+oDRfU++j
90qsnlhtYtU+kZER3i4uwYP6Ven/1YdVgsP7u0T0DVX3ukQMCu85JDhysEu9NtDRqsAufaOvXwk6
pIbeW+/5dVtPJjp/OeGwYcN+dMKQQcXOFPmbAcTQpnb78Da9l9qNd8fKQ4umNTY+uxY99qVuROQw
/wUNLXNQidAxmUGzkgp6L4u/7+j0se3VRYUtU7oZbP9l1YuYnIW24R0/vntzV744VetrbmF3PnWn
X0Nt+cD2Bk3nvtae2tN8wOt7jUwcq021H3S7+67NoSYOc18+cTfIHDMgfLbY+kTFZo3XuTlPfLzs
VNfy+/bVuNN523hpTzUb/wl+DYv2zl3Wka6df3P4/vZjV65ucSp7Y3xcnXsnuzj43hjr3rBF7tn0
UUue7ToeH2zWZvPGuFdXU84mLls/78TISpOcU49lfOrHXU/x3PjmfJeSFoap70+MW2Wktbo5q+yj
Lcua+T7dYlx+uJLm/MuKvsdm1gC0WQJoE/sVbRpHvWBoI/xzaBMQ2j9kcGSP/hHF0cZD7+XqoXet
Vs2NyRtXtummVzf10av+lmuroC/3mShtB9QLjegTMsiufhs/O782Lbxd9fU9K1fzdK9euV7dBp5f
P8iZ2v6BEW1CBg0NDQ75U4B6ukcITs8YsWlCfd+V2w+/aLbU4bbXUFuDK25NOgy/UCljJZ316lHN
/P3lo5bnPxg9xu1sRs2pXtWzP1zzcTe/NDsm3/15n9hBVjPv7G52Z3dsTlWRpCUNHVytWdc3yXeb
jC61e+7wzCLb2BJ1Gww8M7ZCe5Pz4/19zn68lTv1RS2UdflWjzyL6U1XRNd4F1r76d0pKdR/T+So
J/KDhk/X93tzuXe09oP5idGmewffM2j2MSj/RaJXnHfhM+P0HrZBHa6JAeMv+zRteq/tfpdAqxmz
hXrXuz6LEcsuMEgUXEOmzmlhW8c+afasAr/6fuHVtvpV3xi6NiTPvd5Wi4M+XneNpmVbTcoKaFna
Z4nrxuIA9SsgjRn0ukqtdk53yr3vsxt/anp3zNks3++wJ/xxi1oLfnFf33TizH3xTzf41Kl39Nx/
C3siB0cE9/gfwZ6vZ4r8EYJqf4fCPwCo0JExBrL5+VtnG0ypknLefWT02AqOdSrmXLSfrSzY2L1N
N6e8F2kBTdaMfm96TjLLa549sQQakDW+lKPfamcvt5vhcdU7vSzbemYAN73W6vienrke6Wb1dnn7
LjyuOzQw2jGn12rXe126zsxr3fpul2dzZi0JNWg25fz5oc3cdWF3o+qvrtR5fMBYP4eS5Q7/1OBI
uayS40KdzHItjr4u4xzdoFult3mrjg7zLRuet6pn7IykIN3ayrZrHszyHVu0ZcanBc/fFPCbTzc+
0ylyw8cc09LWXmeW77iy7+2Ol+kbs9vZ5td4k36lYv19KfG1RveyPL3NLlg8UbtmiFvJqG27a6aV
b9SiTMlFA6bp0978/D1AGYVJi/xTUbn1xpl+pTuM7J30W5j6Z4KvL+ikd3evrqKTF2z+A8HX74Dz
z/DmRvUB+ZvT6zYZaJl+ppFvm9SP6832OLvtNfFvnT7+hW/VjMausx13/dzzTumWE/YcbHp+rPDh
1ZADU4+tubwpNKLX8Aq9Hu9KfhX7y+mX6wpMVkgdyzi5nK2d0Y63Hrqzf8/+TQIyb765lZIw/ti4
22Obkepz36Uu1baz7dPwdEbq0C4uo3eV43e06xxmE1w0LqrGy8t8ueZewyJp14Ndrk2s7jzkuPLU
1ssgamjhkn4DRt557jtzwdKBSveK/pZBgW5LL4xvUalMlz5+U2+5TDBquS1vp9X0fi/LLTb9cNLo
aqzyNmboYI+j80YmnQrUPBe2TKya/GFu5wl1JnSInTtgS2nnRqfC4+vdCXs8tvyMvp/xJgY7Qos4
/HiE/q8Iv4w0Bl8mQEtgNaZCxdDzh+BY8tsfmBFethVRGzQEBaF6qM73odnv4rofANTc5sauB6Na
7jWesawHxcq0CL/prwYH7K9lIFQu2t2qTazNC6+fk5e3k25N2+VjfT5/w+rjyVtb2VuHa0PH9OWS
yjR40W9H/6gyuxtcnJAz3fAA/ckj7dmYJxFd/RJmXzh15uaM1LspFU9HPT++ye3ypF9OBh/2OG9p
nzL0lk/cduvBS+0nX9uxwyRg2tv4gyFN4hzLxwf+ZOhzzDRkeKO9ZzeO9/bfEtThlv7JE69SWVOy
r3tF55naT+s5LljDz8/+r81ictavduvY9Z/pZupPr3u3mEsmb2bN4zkz945GYo3HR/E5gooWTDLt
a9iOTjPa8dThWLDt3pWd916kmfd+UZo258yG8pBAq2tFLpuUvxk2sawHFlKrmRgZDRrbB7BXhtJX
RIxxL2i8ZSACj28NRkN2Zlbw6mVQKoBGJiezIQ/ysDrQNQgetyGfAbKsqIEyQiOLITCNfe/3Ym/0
nnhvK8esgA2d+/9q+E/capCCpIXHMMwgZIFWgwaDL0MmQzJDEUM+eGQ+jaGEQYEhhKGSoQDISweK
JwJZGQyVC9UaVHBWryWVBfnpRYkFGZUKaMUbSxMjg8L+ZzsiJRmsRGZJdfie+zx1w5zJDote8RmH
s7yzKHb782fjupnvHxg8ruv6+voLc/XXqzE/v5bMbeDO23xrnT5zHkvBK+Zr38Q7dQ+0TDVfet6u
JTacr/LkDckb+/8ad8+7s1lh0Xa31zvr5r9df8Du2Kv9LvcvOu758VJEssv742RG1/Pxxjzd9et6
Fjv3nvjj9z957aTDZw3VQ4u3JGyfyPL9JG/ZOo+KdUyzGk6tm2hipnbsWQrPgj6mk7nytevqwkyP
XBau2eSkNHXm+Sq/grLF67SPKj2vKr4eu6B/4ftwf0MmbYEyl19T3GSSpghX99c8aVF+sHi2nznL
MZ+0VS+W3loaoVzbaXBRXmRhE5O8QROTNCKO2AybmHiAQhx0T6LoNRJKB4MdmkQXxBpIIKdEbsQs
ECPQTrgMqyE/sKq1MDQwAla0RpbGplEYCZHpvwrf/W2JvbF68QYdrlJf1z948wOtzAIlkfvTD3tx
6N7fcVJ62U1F1uM8b9LaVP47MZ13/rD3xEKFsmmP9jyc3Cfk8EhNa9Gyid2JPRI/z2htDJBq/1E9
8VXwUYcXu3Vj+8+5TErJC0tQdeI+3sbU4PhOaWb1UaOqgHc5HU9+mYl/PdY9KUk2ZNaVp8JCC6/N
Xff9f7gVs/vLq+8iPqfZOaZ7x23ft/dmq+6T8B0nJq5OKsyyXy7Mcei89pnSezO7KisKmte6zTq0
ubnTz91KuzlY0WjFv1fH7UvKmA6sW1UUHLsj43jda0PbjFnqDZ+3sG14fnmHoE7TpZz96+8XbnrR
nLRiG2OZwS0+h+BN0ayfv28xS2ENVhTtTnfLE8jKjRQOytvCywAAbNbLQA0KZW5kc3RyZWFtDQpl
bmRvYmoNCjE0NyAwIG9iag0KWyAwWyA1MDddICAzWyAyMjYgNTc5XSAgMThbIDUzM10gIDI0WyA2
MTVdICA0NFsgNjIzXSAgNDdbIDI1Ml0gIDY4WyA4NTVdICA3NVsgNjYyXSAgODdbIDUxN10gIDg5
WyA2NzMgNTQzXSAgOTRbIDQ1OV0gIDEwMFsgNDg3XSAgMTE1WyA1NjddICAxMjFbIDUxOV0gIDI1
OFsgNDc5XSAgMjcxWyA1MjUgNDIzXSAgMjgyWyA1MjVdICAyODZbIDQ5OF0gIDI5NlsgMzA1XSAg
MzM2WyA0NzFdICAzNDZbIDUyNV0gIDM0OVsgMjMwXSAgMzY0WyA0NTVdICAzNjdbIDIzMF0gIDM3
M1sgNzk5IDUyNV0gIDM4MVsgNTI3XSAgMzkzWyA1MjVdICAzOTZbIDM0OV0gIDQwMFsgMzkxXSAg
NDEwWyAzMzVdICA0MzdbIDUyNV0gIDQ0OFsgNDUyIDcxNV0gIDQ1NFsgNDMzIDQ1M10gIDg1NVsg
MjY4IDI1MiA2OTBdICA4NzZbIDM4Nl0gIDg4MlsgMzA2XSAgODkwWyA0OThdICA4OTRbIDMwMyAz
MDNdICA5MTdbIDQ5OF0gIDEwMDRbIDUwN10gIDEwMDhbIDUwNyA1MDddIF0gDQplbmRvYmoNCjE0
OCAwIG9iag0KWyAyMjYgMCAwIDAgMCAwIDAgMCAzMDMgMzAzIDAgMCAwIDMwNiAyNTIgMzg2IDUw
NyAwIDAgMCA1MDcgNTA3IDAgMCAwIDAgMjY4IDAgMCAwIDAgMCAwIDU3OSAwIDUzMyA2MTUgMCAw
IDAgNjIzIDI1MiAwIDAgMCA4NTUgMCA2NjIgNTE3IDY3MyA1NDMgNDU5IDQ4NyAwIDU2NyAwIDUx
OSAwIDAgMCAwIDAgMCA0OTggMCA0NzkgNTI1IDQyMyA1MjUgNDk4IDMwNSA0NzEgNTI1IDIzMCAw
IDQ1NSAyMzAgNzk5IDUyNSA1MjcgNTI1IDAgMzQ5IDM5MSAzMzUgNTI1IDQ1MiA3MTUgNDMzIDQ1
MyAwIDAgMCAwIDQ5OF0gDQplbmRvYmoNCjE0OSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl
L0xlbmd0aCAyMjY+Pg0Kc3RyZWFtDQp4nF2QwWrDMAyG734KHdtDcZrLdgiB0TLIYd1YtgdwbCUz
LLJRnEPefrIXOpjABvn/P/Fb+tJdO/IJ9BsH22OC0ZNjXMLKFmHAyZM6V+C8TXtXbjubqLTA/bYk
nDsag2oa0O8iLok3ODy5MOBR6Vd2yJ4mOHxeeun7NcZvnJESVKptweEog15MvJkZQRfs1DnRfdpO
wvw5PraIUJf+/BvGBodLNBbZ0ISqqaRaaJ6lWoXk/uk7NYz2y3B2Pz6Iu67qurj398zl791D2ZVZ
8pQdlCA5gie8rymGmKl8fgAH/G8nDQplbmRzdHJlYW0NCmVuZG9iag0KMTUwIDAgb2JqDQo8PC9G
aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQwMjcyL0xlbmd0aDEgMTc2MDU2Pj4NCnN0cmVhbQ0K
eJzsnQtAVFX+x3/n3HvnPcMM8mZkBkYoGREFFESC4alG5gM0pkBBJdE0UdSsLHHLNHpYbblqbfbO
ng5g7oi1utm2ZZpumT22FB+910f9e5gP7v937owGu7jruCHbej7H872/87r3d88998w9DFyBAEA4
igi1BSXDhnyTvtANdHkWZs4fUlBYdPvRu4YB2fYEAH11yMgRJTeOfW4VkB01AM9HDSkZk7c7r3IU
0Pm3AkQvv7SktGh64hQVtrfiXmMuKy0Z2ttkugUgvhXAWD6iJDnFnHLTCgByFMsrR+ZfVnryxux8
3P80TA8cWzC8bOR9U78HSMXjW+6fOL2qdsnE601AFs3DNk0T5862P2p9/2sgK8oBVKVX106evvV6
90ogi/tg+trJVXW1EAFa3B+Wg3nytOuvHl+76CIgqzwAmqaaSdPnfXVi+wsABTuAuFbXVFdN+mRs
4d247/ns+DWYEZxqTMP0Wkz3qpk+e94lT9J6PPcyAMdt02ZMrHq85yOfAFk9CSCqaXrVvNrg6QYj
1v8A69uvrZpeXXxd75uAbI4A0PWqnVE3W06EZehPFiuvnVVdG79r+EYgdz0EoP8jsL6Xgspvl6cO
HR+U9b0mWgOMx/ZflMi2b9z72u+OrTk52QwaAya1Sn0GbtXZbZdDvhmOrTl2gxlOl/gRr2E5xjKI
AapkUDBDMozFkufxuAxBWELuAQk00kopFXcQ7dsKf4WrabBGonqVSBliKyTKm2BevuIBUjo83w4u
iLXHSe+2jSKp6mzS5AIiyzLuPUHawM4URJXfJToITm099H0YB78SVM/C8q7at1gHRefSjj4Li35p
X7oDug2md7cPHA6Hw+FwOJyOkNVyS3f7cLZI0b8eXzkcDqc7ISC3aDCagc+bHA6Hw+FwOBwOh8Ph
cDi/foxlakLgOdXZt5jTebajQyqA/Z1zCw7nHCD/vso5VOX8GwjhvcnhcDgcDud/HwEEwpAEgVB8
/omQ/q7fBEc1MmhAI7eBFrTySdCBDlUPelQDGFCNYEQ1KRoEJlQzBKFaUE9AMFhQe0Awagj0QA1F
PQ5hEIIaDqGoEajHIBLC0Y6CSLSjIQrVqmhPiEaNAav8E9gUtUNP1FiwocaBHdWBehR6QSxqPMSh
JqD+CBeBA/Vi6IXaGxJQExV1wkXyD9AHLkZNUrQvJKImgxO1HySh9kf9HlKgL2oqJKOmQT/5Oxig
6EDoj5oOqagZkCb/HwxSNBMGoA5WNAsGol4C6ajZkIGaA4Pkb8EFmai5MBg1D7JQ81G/gQK4BLUQ
slGLIEc+AkPAhToUclGHQR7qpYoWQz7qZVCAOhyK5MNwuaIjYAjqSBiKOgqGyYdgtKIlcClqKRTL
B2EMDEcdq+gVcDlqGYyQ/w5uGIl6JepBuApGoV0OJagVUIo6TtHxMEb+GiphLGoVXIE6AfUrmAhu
1ElwJWo1XIV6NZTLX8JkRWugAnUKjJO/gKlQifY1ik6DKtTpMAHzr4WJqDMUrYVJ8ucwE6pRZ8Fk
1DpFZ0ON/Bku6aegzoWpqNehfgrz4BrU62E66g1wLeqNis6HGag3QS3qzTBTPgALFK2HOtSFMBv1
NzBH3g+3wFzUWxVdBNfJ++A2mIe6GK5HXQI3oN4ON8p7oQHmo94BN2HOnah74S64GfVuWIC6FBai
3oPaCvfCb1Dvg1tQfwu3ynvgfkUfgEWoy2Ax6u9gCZYuR90DK+B21JXQIO+GB+EO1IfgTtTfK/ow
3I26CpaiPgL3oD6K+gk8BveiPg73oT4Bv0V9Eu6XP4an4AH5b/A0LENdDb9DfUbRZ2E56nOwAvV5
eBD1BUVfhIdQ18DvUT3wMGoj6kfQBKtQm+ER1LXwmPwhvASPyx/AOkX/AE+geuFJ1PXwFGqLohtg
NerL8Iz8PrwCz6L+UdGN8BzqJnge9U/wAuqr8CLqZlgj74LXwIP6Z2iU34PXFf0LNKG+Ac3yTngT
1qJugZdQ34J1qFvhD6jbwIv6NqxH3a7oDmhB/Su8jPoOvCK/C++ivgM74Y+o78FG1F2wSf4rvK/o
B/Aq6oewGfUjeA31b4p+DH9G/QReR90Nf5F3wB5FW+FNeTvshS2o++At1P2KHoCtqJ/CNtTP4G3U
z2GH/DZ8oeiX8FfUr+AdeRt8De+i/l3Rg7AT9RDskrfCYXgf9Yii38AHqN/Ch6j/Bx+hfqfo9/Cx
/Bb8AJ+g/gi7UY+iboGfYA/qMWhFPQ57UU8oehL2y29CGxxAleFTVD6nd/2c/s2vfE7/+qzn9C/P
MKd/+U9z+hdnmNM//6c5/bOzmNMPnJ7TZ3WY0/efYU7fr8zp+/9pTt+nzOn72s3p+5Q5fZ8yp+9r
N6fv/ac5vVWZ01uVOb31Vzinf9hNc/pOPqfzOf1XN6f/2p/Tf71z+pme0/mczuf0zuf0N/4H5nTA
GReM5fowDQhAxbP/UY6m8+yO31oHsL9zbsHhnAP07Kuqu86LCw6iD+tuFzgcDofD4XC6GkOEln3x
HcDKRtt5dsfnUL624vyXEsDa6gw/RuCcA9QQ0d0ucDgcDofD4XQ1xigdLmsE6exb6DvP/k/XVgF4
wOGcO8LZV+Vrq18Oaozqbhc4HA6Hw+FwupqgGD0uhKT/fG3V8Tk08JUSX1txzgsBrK10XefFBQcN
iuluFzgcDofD4XC6GrPdwNZWAbzj09h5dsdfFQx8pcTfMso5L/C1VbdAzfbudoHD4XA4HA6nq7HE
GXEh9Iuvrfj/4MD5LyWAX1c9w1e0nHOAWuK62wUOh8PhcDicrqZHggnXVqoA3ogW1Hl2x+fQwFdK
/J1snPNCAGsrQ9d5ccFBeyR0twscDofD4XA4XU1oohkXQoGsrSydZ3dcWwW+UuJrK855IYC11Rm+
ouWcA0JoYne7wOFwOBwOh9PVRPQLxmWN5gwvVu+MHp1nmzqkAn/DGn8nG+e8EMCfAp7hK1rOOSBE
9OtuFzgcDofD4XC6muiBIey/hQ/gr/bDO8/u+BwawFrtnFtwOOdAAL+ueoavaDnngBA9sLtd4HA4
HA6Hw+lqemaG4dpK+5+vrcwdUoG/YY2/k41zXghgbXWGr2g554DYM7O7XeBwOBwOh8PpauyuCNCC
PoA3okV3nt3xZ/yBv2GNv5ONc14I4A/7QrrOiwsO0e7qbhc4HA6Hw+FwuprYvEi2tgrgjWhnWFsF
d0gFvlLi72TjnBcCWFuFdp0XFxxibF53u8DhcDgcDofT1cRfagUd6AN4I5qt8+yOz6GBr5T4O9k4
54UAXpoS0XVeXHBI8Zd2twscDofD4XA4XU1iqR0XQqYA3ojm6Dy7459hmTqv9C/g72TjnBcCeGnK
Gb6i5ZwDUmJpd7vA4XA4HA6H09X0LXeAEUzms28R33l2VIdU4CulADzgcM6dAF6a0rPrvLjgUPUt
724XOBwOh8PhcLqalEkJYAJz8L+veYrenWdbO6QCf3t1AB5wOOdOAGsre5c5ceGhSpnU3S5wOBwO
h8PhdDUDp/WGILAE8LbppM6zYzqkAl8p8fddc84LAbxmJa7rvLjgUA+c1t0ucDgcDofD4XQ1mbP7
gBl6BPBGtOTOs+0dUoGvlPj7rjnnhQBes3KGX3/lnAPqzNnd7QKHw+FwOBxOV5N/WwouhMICeCNa
eufZHZ9DwwJ25Az/JTGH88sSwGtWnF3nxQWHJv+27naBw+FwOBwOp6spXpYBoRAewBvRLuk8O7FD
KjJgR6L+fRUO5z/HfPZV+3WVDxcg2uJl3e0Ch8PhcDgcTldT8lQ2hENkAG9EK+w8u2+HlLXzSv8C
/k42znkhgNesDOg6Ly44dCVPdbcLHA6Hw+FwOF1NubcQoiAq9uxbFHeendohdYb/YPhfYA+4BYdz
DgTwp4CDu86LCw5Dube7XeBwOBwOh8Ppaia9UQxWsPY6+xYlnWdndEgFsFbzc4b/kpjD+WUJ4LUt
ri5z4sLDOOmN7naBw+FwOBwO5zwg+KMViJKehCm0yFQQYSiwP/7XAAUVxMFwLJulctnjZBnY+qld
Wt7vCyc8rdX+/bSDqOB0JqEUcH//UAGjKJ29z/06zx7SITXm7Pd3isWBNzlrfrHedOWPKc115WRf
kjU4c1BG+oC01JT+/ZL7JvVxJva++KKE+F6OuFi7LaanNToqMiI8LDSkR7DFHGQyGvQ6rUatkkSB
EuhT6CiqtHsSKj1igmPo0CSWdlRhRlW7jEqPHbOKOtbx2CuVavaONV1Y8+p/qOny1XSdrknM9izI
SupjL3TYPdsKHHYvuXJUGdp3FTjcds9BxR6u2PcothHt2FhsYC+MqCmwe0ilvdBTNLemobCyAHfX
qNflO/KrdUl9oFGnR1OPlifcUdtIwrOJYtDwwsxGChojOuWJchQUeiIdBcwDjxBfWDXJM3JUWWFB
dGysO6mPh+RPdEzwgCPPE+RUqkC+chiPKt+jVg5jn8LOBu6wN/bZ1HCn1wwTKp2GSY5JVeVlHqHK
zY5hceJxCzzhNxyI+DmJOw/OL1vcvjRaaCiMmGJnyYaGxXbPI6PK2pfGMnW7cR/YlsYXVTYU4aHv
xE4sLrHj0egid5mHLMJD2tmZsLPynV+1o5DlVE61e7SOPEdNw9RKvDRRDR4YfX1sU1SUa73cClGF
9obSMkesJyfa4a4qsDaGQMPo65sjXfbIjiVJfRrNFl/HNpqC/IbB2N6oPl2mWEp1ZhWPPt2zhHnk
GIYDwmOfaEdPyhx4ThlMqjOgYWIGVkPcBFt5JuEVmeLR5lc2mDNZPmvvkeLNDnvD94AjwHHw7x1z
qvw5qnjz98BMNk5ODzUsP2V7nE5PYiIbIup8vKboY7aSHpDUZ66XOhy1ZjtusPtgJPZtlTszGbs/
NpZd4Du8LpiACU/9qDJf2g4TopvAlex0e2glK9l0qiR0DCupP1VyunmlA0fyWuWGDvVoEk7/CzKH
9SisyfSQsH9RXO0rLy5xFI+6ssxe2FDp79vi0g4pX3nG6TK/5emRXyZEU79FowWlFAdl+enKLFFm
8Ijx+E+lDOpJXrUGR6WSQ+xFHnPlUJ+6dbGxZ9nIKx9hrZTNz838bnoynR3TgzukO7hnaBDQYTGB
Fpde2dCg61CGQ813wGH+DY54KC2Lted7YAzemfH4zytvymDRHe1xYZflswo4/nxZ/mSHitF+242w
0ZnUpwgnuoaGIoe9qKGyocor109w2M2OhvX0VfpqQ21h5amB45Vb7oj2FN3pxr6qIZl4U1DIa3SQ
JaMaXWRJyZVl680A9iWlZU2U0PzKPHdjLywrW2/HyV3JpSyXZbKEnSWgmOBJNlGNUj96vQugXikV
lQwlPdFLQMnTnMojMNFLfXnmU3kU80RfnkvJY7A5Jr+0rP3oUW5JdxLAeigVLm5OiLDteFnoDa0Y
qdC7ydnTtl64SOjZNNjm8gqO5uDQlKDcJMGOx0xW1I46A+MajBsxijBeiMF8M+oCjPUY12DciHEH
RnxGQGWldowzMK7C2MpKhJ6CtcluM+deJERi20g8hyAhHA5jlDEKYENNxjgC43iMSzGuwqhS6rGc
GRgXYNyI8YhS4hLCm+5LRd/Dm+5QNs1Tp6UoySpfsrxCSTZf4fZth4/ybQuG+apl+qr1T/Nl983z
bS/q49sGx6fUs63OmLIpN0wIw5MMQ8drUQl9DYIIARs8IoSCByMVVP4clxDc3CshZdVGQQQiUIHg
Y4FN3iSQJqMlJVdHZXoYgsFGD9GDvhJ6sNlkSVmVeyndB2swbsQo0H0Y9tK9sIC2sj5HzcG4CuNG
jNsxHsaooq0Y9mDYTXdDEP0EkjHmYByPcRXGjRgPY1TTT1DN9GM2PynK7ByMlH6MaqZ/w9P6G2oQ
/Qitj+hH6Nq7TemDUtYrhjPZb9ji/UZ4tN8IDkvx0neafuqNIyoBrzSOqA1CHGRDqhDXFN/f5hUi
mrKm2Lx0f7PdaXsktx/dCR6M7EFyJx55J9gxjsRYibEWowqtXWjtgnqM92B8BKMHI44yVDNGO92C
cSvGXdAPowvjSIwauqMJD+Ol25sS8my5YfRt+hcIxx7fRt9Qtlvp68r2LfpnZfsmbmNwu4W+3hRj
g1w9lgO2MePWjNtkLJfon5p7BdvkXAvdiH1nQ03GmINxBMbxGJdiVNGNNK5pki0Yd7IBtmgAazbB
l8r2KXhMA66pNldCPg5AO5OEzEvQQlllX5VAXQnLVmCSScLd96HFJOHWO9FiknDDQrSYJEybixaT
hElT0WKScOV4tJgkjChFC8VLH/5Dr4ts6SOuIfbcIHod9tJ12EvXYS9dByK9jgX4SWS+PdiUmIg9
ttLl7J1oq28h9S+T+tGk/jFSX03qbyb1C0l9FqkfR+qdpN5K6mNIvYvUbyAZ2BX1xLW2Q3KQK4LU
byH1L5D6OlKfQOrjSX0vUm8n6S4vjW0alqpsCpVNcy676XB7STbOPkE0Fns0Fsd8LM4JG1G3Y5SV
lAsr2eN8lSNj2DauOTHHl+6bmTIjdyjdjA0342XYDHswiniBNuMw2ow72Yw7CELNwTge4yaMhzHK
GFVYOw4dX6poEGoyxhyM4zEuwHgYo0px5zBGCjP8Lq5RHEv2Oz2CpehmDHEYYmmsq6fZanaahwpL
rSQohoyIkWNoOoSx1wQGWzQWLzGu+9F49EcjaHO19G66FHrihbjHv13a9FNPm5csb0rYYMsNJb+D
GBFHHRkECSQetxlQp6QHgFXDtmlgpc/hNqXJOhabBTUl9LG1EBNrtc72k/WA7Uurl6L5hXWD7X27
VyRNtvcw57l1tp3W221vJns1mPNygpfgpsWuVF1vzbC9sEWpuhALVjbZbmabdbabrENs11iVgmpf
wbg6TLmCbKMTrrQNxf0VWCfYXHW4z3W2HOs4W5av1gDWZp2tH7rg9JmJ6Gxvq3JQR4yywzHpXlLj
6qNepi5Tj1APVKeo+6hj1TZ1T3W0OkQTrDFrTBqDRqfRaFQaUUM1oAnxyq0uJ1uBhqjMbKMSmYqK
baZM2WKVTXpEQ+FS8PQQimlxSR4p9myaCMUT7J4fShxeosOnFcmRRzzBxVBcmufJcBZ71fJoT7qz
2KMeeVVZIyF3uzHXQ5fgp3RpmZfILGtRNFsXrAdCLIvuimbbixfd5XZDRNjcnIic4GzLoKKCTqTS
r86fiehg9/QsKy4p8zzb0+1JYYbc013s+S1bOKwn35IjhQXryTds4y5bL2STbwtHs3whu8DtLvaS
sUo9sJNvsB6OmG+Uehr8YGb1wK6J8dVb6asXj+2xXi+2wXpaLcQr9eK1WqWeSFi9xrpehQWNvXop
dcLtUKfUqQu3t6+zJR7rxMcrdcLqYYtSZ0tYPavjyVaqWK1YJcaqVCFRYFWqWEmUUmXsz1WS/VVu
P13lduVIAvm5jtVXx9h6qo6xFes4z5bqPKeTNA92Tyxni65KR2E1xkrPHXNrIjz1E+z2xolu/2os
oXLCxBq2rar2uB3VBZ6JjgJ74+DyTorLWfFgR0EjlBeWljWWu6oLmga7Bhc6qgrczUNGpqV3ONbt
p4+VNrKTnY1kO0tjxxqS3klxOisewo6Vzo6Vzo41xDVEORYoY3xkWaMG8tz4jK9sm6leh+O1MjrW
nRdmrs1WBu/g2Iibo1vwaWU16HHJY8DlsxEjK0rKTcplRXhPsSITW1n7iyJuHhwb3UJW+4vMmG1x
5IFz9py6ORBROKXA968OwazZc1iH+9RZdyawrBAXyQV1swGKPYklxZ4cfJptVKsxt5KdkifzVJ5e
X4jP9r7MvpiZyTIF4XRFlpfF8rRaf8V/vv5z/Nt8dhfU0w3NxBVDZkOdW/DEFJdSnApK/UuYFnyW
Yh8PdW48wTriJHWn9uF32+kEXxrYOZ+Ks+f4LX9fzPZvfS2xSd2pLjkN6yzn6R6bjTsEqQUiMUZJ
T0OkmAARAPLnGL9g27Yp8hesnG3pVzjRef0RYDW8QKbAC7ARXiVHsNUaXAisBfYIVAAPwXy4Hxbj
x9qVmHM7jMYgYf79JFJeC8nwKH6wPQrbsO4VcDO0QBiJkL+EBbBIeBdbLQIjxEEujIQZcBe5TJ4D
5bBHvAXS4TK4FmpJvVwm3y3fJz8BT8J64Q35JOghCiZi2CYfkj6QP4YkbPEArIA95D7tS+DCo9Rj
zd/DLFgpVIhEniwfQw9i4Tr0QYThsI1sok7cezV8TiLIfCEf9/K47JFfw1pWqIAaWAktZAAZQmOl
cnm4vA3C8BjzcK8roAnWYfDCK/ARMUhH5CfkIxAJfWAYns9aeJtsEtpOLmzLwR6TsJd6wyAsmQF/
hL/ADuIgf6IzJIOUIrmkG+SdEAL9YQx6+zS2/Iz8SG/GsEB4XSyS88CE/XIv6234M+wlUSSZjCBj
aW86gz4szAINHrE/hkkwBft7Oe59Nw6jddRAtwuPi8+Jx1U921plE16RBHgQfg9/IkY8UzupI78h
u8h+mk/H0wfpPuF+8RnxHXUVnvU4mA53wXPwIwkmGWQUuYrUkPlkMbmXrCDbyA7yBc2lpfQaelio
EWYKr4h5GErEOvEW6TbpDtUXbWVtr7X9te1HOUW+DUbheFiI3j8AD+OZrYft8CGGPbCPSERPTBjs
JJaMITdiuJncRR4jq8kzZC0eZQfZR77Ej6TvyXGKn7RURaPx4Yc9AjnoLHzCvJ8+RLdj2EH/Tn8S
woU4wSkMELIEtzADvVos3IPhJWGvGCVuF2Xs5xRpmbRKWi09J70qHVEZ1L/Bz/itJx4/mXhydxu0
LWlb1tbUtlbeC6F4DfHTAxdcWeh9FYapeL2X4YhbA+8SA/ZdFEkk2eQy7JnxZCqZSeZhT95KVpIn
Fd9fJC9jL71PDqPPRmpVfO5LB9A8OgLDOFpNZ+LD2H10Ld1FjwlqQS8ECaFCojBEqBCqhdnC9cIy
wSNsFT4R9gk/CCcwyKJOtIlxYoLoFIeI48U54sPi5+LnUrn0lvSpSqearrpN5VV9g0812eqR6lHq
CvVS9Tr1Tk0ljs7N8BL8of3PiEmrsFAoFF6Cu2mqGIlLmLdxPI+HScJwiiOVriZL6E1kLe0lzVMN
poPJ5XBETMC+fp2uoj/QwcJwUkxKYCrt79ubKkR8FjdZ4mY4KL6M5/Y27nmeykBupodVBmjCZ6RB
eMw/C/1Ep/AWfCTsIWrxUfibqCPh5CB9WhiJo+AVMVsqg1jhIXhRmElugpdoIYDuuOZOHMeXk2dx
XiglKeSoIONj8OU4itKF/XALXEM/gIN4Hy+B35FJ4mS4G1LJfPgcnsK7ord0rSpRFUrepFPEBtqD
rAUqPoNnN4j0IoIUAreSCmGl6jD9EObAdlEHu4Xn0fvt9EVhuHhEGk1q8A64CW6DmfJCuF4qE98h
k0EgYyFebMXZbb6QIsbidgHOKuU4p63Du7sF54FcYTjmRODIuQzHxRicIVZiWI7zhIgjaAre41fg
LPY2rFWVUi9MlkwEZx0A8a220XCl/BSskCfDtfJ9kITzwWJ5Pu5xNXwKS2E1WdR2I9TiUvJDvLcv
k4rodqlITqIN9ENaQpd1vL7Y2/EkAr7C8CImsqUN0CC+DyWQI98pv4ej+2KcYVfABHxgPYBneQiP
MFTYBKltl9NGuUioxfPdA6Pkp2Ub0UGNPA1GwMvwpFqCKrUTr7GHvIPneyNU09HybKG6bQr2w1Ls
BRf21hycf27Hp2FlwpPYd0dqgFhLrCUeBZ+c4YRd2HTCJcFxsIub2Hc9HvR2KX7KSKCFmxpV7AdN
TRQkL13j0muyVDptppilyiQk+cDJA5Bz8rOc6EarUpqApRRUOv1bgjZTyhCzIAPrCVmU2gkhb+l0
+oWxjy7HJ9/Lzd9VZA03HzQfwF0cMB+CnJzh5pOf4ZNvs4QPJsScZc5yu/v36yFYUi2CMCA19PP0
PWmPbyfTBC0pbNtw4se2+7dtY76OE5rpdYqvepizHj8ijzbHxadJXvmoKy6hd5pepcNOwrWTJKn0
h7QajSBQUGuydEHaei3V4pOCK9QYlKbdTQQxixKX0ZJGIg0zn45gLjqzhp/MMp90VmSdzIKcLObU
ySwUYgkeNIjF/v2I09mDuSekKnpPyrakT/pv6yc0k/AjR9q+9ClbjizHuzII/TTTA42U9eh60Mg/
uPQGAx2jMRktdAz1yofWMgOdP+S6mFmGYFYsBRkELRCq0epNoNFSnV5lNtMxerPRiOqVj61jtfRm
8MqfrWUlaBxdGxSkGCfWslqQjA8X2xTBrt60ybxjxyZLcPggp1M5BSdE+y6zy6a26/WqMSpFBUVF
RSVFNV75W5eDWdSg1FAZDGibmGoNTHWKqpkHRqPS4KjLxqwEiRjsuuC0IEUkgwDEpAeNhlAdO3G2
N8VQdrKBjoVg7KuxLiMoBwLlQHBqt0DYuXyX/B26npOVk5XlO5kK39m0ez6Ldi0AGqQJodEaca7h
NsMb2JWGYYZhQUJvMd7Yx1QmXCXONc4zLTZq9FTSDDIONI2gxUKB2qUZbswz6ZbTFcIy9TLNauFp
tSqYBplM/SQaIklUYzAa+0kaNDWG0UGjiYtQqtFodXq90Wgymdl1qgyuD6bBLXQ1GEn/Jsmu8ZL+
Lp1Bq7O7DAv0RN+CJ2kieiyhXqJ3aYMI2INqzcTspWP/YJcqpXpJwNtqdbNlsDvCGYm3DN40ETgi
D0ZFmg+iHXU6caACInJyspQheipEmQ8eXCz1dS6+6bXFfSPYpn8/fFDW44NyDD4ovwIG+TiOwV1A
5V0ZGRluXCAbsOxiLFsPRvloo0nHcpWHZaO8c13sIFOf2EFGL5rpg0wp6Yr5UhLmJg3ydbl71swK
mFlBKtzuVJxawsIHppNYi8OCj1WW5TjHX9UvLHIAfjpLG9rGrmkrk1qOf3vv0JEPCieOFYlvHR8g
th634x1dJH8h7ME7xQI9yRjXEzoqGuONacYCozQgZID1ClqqGx1SYp1MJ0nV2okhldZNtp3Sez0+
ify0x6chh8O/jvy0Z6tNtoXZbM6orLCsqOKoWts9NnVf2svYNyyTDjAW00JjUcgw6xW6scbJxk9V
n4cdI9+ZzCRUMOnNQRBt1astoAu1CvqIVALxlqB4s3mHhZgtLkulpd4i2lx6PR1jc7H7yhLM7jeL
V/7OZWE3nEVlMqFGKGXsXtGzwWsxmc0qlvaNbgu7J/LYMLbMDu61Ub1dvUctq0WbOkc9Qi2oY9ju
1RHsnlbHsB2plTtAbWAt1FHK7RUZkzbSN0UpVMwcfvDkz2uKipk4LMwns3ByPoh3B0YLm67w8lcQ
doViB6gccQkJA9KCB6amhIXjFEtCwlJTBg5IS3DEqYSM6tcWvDdn6s5bKpclN5+0Pz9n7pOrb5z3
6G0P33n88VVEaBiVS03Himjw1i1/ev2jra+x2W0RTsWvi9l4zd50DU7uQcwicYhpYj4+gF4tzhZV
WotGq9Eae1i0RhA0RG9VqYkKdNqL79EQTZy9B+lB4yzxBNh8bE4dmHaE/QDHDjugFT+f2E1/alpz
WVgHg8h6B1Ssp5Q5jvUvsKsQFhR0erLQKDPF5cFDXotwmn/4uXOcWScPmCu+m4Xdk5Nz0IJT+aBB
ypQO5jcXm5TbpGIWqUi1pIYOxA4KV7NeUatCLYsey56Sc9W47Ly8weNCYsSER2cOzXz6oiE5lbNO
7mS9MJ3soDX4PKUH23p8MClxmbSqrXboh4N6juGKp5kXFQch+SB+rqWxng8NYddh+gM1Ux54YErN
A/TtKfffPwVt3Jfcgs8Lq8m7+Gkd8QpQehjn/6+xk480SiTZzC4sTnWxA2LJ6rZgcojEv+hvI0X/
+zZS9LFVUtXPbQicqc2nPx8H2lpI0c9tNGfRRgM/tmjatTGfRRszHG4x+9owQv3hGlxndUHA9VIA
Qej7L0LjeQjv88ADDzz8z4RvuiKIeh54+C8M8WKO6OaBBx544IEHHnjggQceeOCBBx544OHXG5Tv
rDLpH8H3F9oAUxUVlF9I1ykpZlMwwVdw6i+5x8FWvy22q8N+N/GY31aBiST6bTVMOF1HA/2U/+qd
2VpoIBl+20ifJa+e/jvkAeI0v01AEh/12xTU4l6/LUCy+I7fFtvVkcAgfum3VaCWiN9WQ//TdTQQ
Idb5bS0UShq/bSRjpOHsL9NFAY9lUD2m2BLaZlWTYquU/FcVW63kv63YGsXerdhafx/6bF8f+mxf
H/psXx/6bLFdHV8f+mxfH/psXx/6bF8f+mxfH/psXx8yW9fOf73i2yHFNrTLNyl2m2KbmW9q3z57
oB2stip2SLv6ocp+fHZYu/xIpW1fxY5W6vj22bNdHVs7u5dSP0uxExX7UsVOUuwyZmva+a9pdyxD
u3zDqXN55v95+x6wqK5r33XOmXMYnQMaYtUYgxNKCRolBI0x1GeNpZRaJITQCXPCI/xnQIRhOPOH
mXGYoVxrvWgstTa11FovpZZrreVSSy01xhqrNk2NJNZEa6Ox/qs1xhhjjHXub++ZQZImfe/ru99z
vt9e6+y91tprr7X2PudkgJCZMhGRBwEzFZGNqkGXUBM1Ajq1kp33fB5XDvCsLUd/HZdIx8ij1ICP
mQrRVwt9nVr4VTVoNaRdaKsg+Sj4Ougy2TouUw7o3F4VZJaBOmgp+pqo5l/y5aOSWR+ak3lUS07w
bJ4ssnDvWqLaZnoIFjJoLrg0WKqjSow2YZx5o9P0UbaWwLd/9KpohMvmfrkh3YgZzfQYLNRwi2x0
FvelCRVZx+fN5yM29DDPWmgm+gr4uhx8pI7H6Qm0TshXRb02I2OP0DzkzgpNJ65Z/FpBnTzuLLK2
aJxruK8672tCW8X77Xy+Vp4HZteMHgf3iUlWRnWqo9fl3JKdz74MUjofY1oV3IYezVZDdJ2NI15E
NGJ+OEbJ2nmEq+BxJZ8jEg8395tF5OPXELlmspWYzckjUsUr8aORYBoNnEuD/HRQVmUVUb8/3nbj
/8Pab1uvGsm9g++DWC5jtfpxK4jN/o9+fXZUjthKImvR+XyxXcDsR9ZahR43X3kT31n/rBLKP5T1
ap6dpmgbWVWEd+LKzlsz99Y1Us0RO0yyARL/rIbSf2zOzHgww1xkqzYvaWps0lvt1ebPNznsTY5y
va6pMd38aEODubCu1qa3mAurW6odruqq9EcddeUN5roWc7lZd5RXVS8rdyw1N9V8spVYZ1ZEs7C6
1tlQ7siyVDtaMGx+KD1jrjltSV2lo6mlqUafzqWWFI2YKmJNtqPcXddYa36spqausto8y1zYVFHX
aM6vq7Q1NZS3zDQXlOuOusq6cvMT5c7GKpg2P/jIvExrk9O8rLzV7GypNus2+FzT1Kib9SZzVV2L
vQED5Y1VZrujDp2VGKkGLW8x26sdy+p0vbrKXNEKtWpzA+ZsZCYwwGw4eK/d0VTlrNTN8MNtgyOj
ZgCta6xscFYhXuaYE02NDa3mtLrp5uplFbA9Srrxn87OxavY6h3VLWyVLKq3J2DqI7Y+y1eUVodZ
9OplLAWOOsxa1eRubGgqr/pwEMojS692mLGiJkyF1qnbnbq5qtrFwgwZW3WD/cMRSsf52MT3HTt5
G1Hh7ORsFeJRVfW4Ps9P4dj4E6izyE5hO6JK2iD9TPq19BzwS2mntHWUrXJ+UsWuT3Lb1R+aq/pD
1rg9Q5LhQcOXDV80/C+0j0C6HDuB7bHIncAmbBd+gMcxtvPZ3cLBT2xmI/JsSOH76JP+n8YS/6sz
d5AQDkf+us8S8blk8RFDKtHC1+WduDZHCjr2L4x/9LnwrUcL8wozMqJ/ZpI9iakgl4XrsFaAh75O
EsTV4ndIEjeIG8B/V/wu+G6xG/z3xI3gvy9eBv+2eB38+xI8kBKlRJKkO6Uc8F+Uvgw+TwqAb5Pa
SJSC0lXw70o3wf9dugU+zH4jwEDsqdCgG3TwTkMreK/BC95n+Ab4LsM3wa8zrAP/LcO3wK+XM0mQ
Z8tzSJIfkh8GP0/+LPj5SjYJyhcUzKvkKUvA5ytPgC9iPwSsWJQnwRcrxeCtylPgSxQdvFNxgncp
bvAe5d9IVFYoXwO/Uvk6+FVxPSTE/TDuhyTF9cb9HPwO46MkGhcZ/SQZlxuxOmObsRv894yXwL9l
vAr+3TGYZYx1jJukMR4TnkZNY03xJJkSTGngp5tmg59j+hH4Laafgt9ueh78HtNe8C+Yfgf+RdPv
STS9ZMIztemC6W/ov2R6B/xV0zXw75neA3/dhMib3jfdAP8BkiepgvobPKHtVX8Lfr96Bfw76lUS
1Xfjx5MQf0f8XSTFT4l/kv0SbDTnIt3LIx+JeSTa0ThjjYVYUZERcTMWG7Eio2YsBV9urERbY7Sj
dRlb0XoRDRaHENp2Yzt6vmr8KvgO4wrwXzN+Hfwq47+DX4tYsShdicZERDTuBz/T9ADWkmHK4Ov9
K/iLpot8LS+g3afuw4p+i3WxVUxEOyl+EtYyOX4y+LvYuqLrGUvrhSGSyx3lFWSubHU00IJaR/VS
yrdVVziotKFcb8TuH0vCVwqzzTQBOyuMGBjIFOXwHsNjQ3w3sXeZ+FHXAt4HEkauBew8WMoryjXT
xKiEiDeDcVFewuh4umNptaORbLxt5K3OWy+7IVGQtyt5u5a363nbx9uXeHtq2dJlS+kab2+xVlB4
m8DbibxNIhp5c/toK0Z/0TlGBfaXEuC7zN7U4O9YrF7lb4fwlhLpTsTlU1jRJLwTsd+kupum0j3s
zyDw/wPNx+l9XJ+I9Rs+RMfB/ifR6XgKLsF52IBTz08d1EnrqJt6aCsN0BDtxTvbK3ScTtNFuko3
BYOgClOENGGukC3kCUVCieAQuoQNwmahT+gXdgp7hIPCYVjGG6awArPjbTQxAz6C3mODp6BmitB7
T0f2QnJHhM69FaEPH4rQR9IjNCtSF8IXr0Vo7okI/dKeCH3cTAb2K+WP95HC/sTa035SUEBC+enI
/JUbmTckVDlwHQe6MdJfNRih1ekRWjuRyxnq0usW1Vnq6qNXR+su1lP9hMhV/ZH6C/W3liZGrpYG
l65bumXpUES/IRChy+ojtDGbSxmbkpoym3KbSpv0plVNm5p28N54e7d9u32v/aj9YjM1T2hOa57f
XNBc1exp7ox462B/t4HR0og1R02EtiyMUH0gQp0XInLu0iit4dUmuNeQMM7OI1RHxwUFecsUFgql
gl1oF14URXGO6BD94ipxHbBR7BH7xf3iBWydBMkMLJbskkvaLx3GPWKKodjgMKw0bDZslTPlTdJ+
+aBiVuoVu9KrHJcS4pS4CdDAJ25RXHFcaVxVXF/caWOWcatxn/GQ8caYqWMyxywcUzNm3ZhrY+eM
7TflmRpNnab1pk2mPtNpNVHNVi3qOvVIPMWPjc+IXxRvj98Q3xPfH/9K/LUEY0Jmgp7QlTCYcDDh
aMKpcYZxyeNmjluMak8JP0MPh4/R/PAx4e3wM8L7wAfhZ0QBGBM+Jo4FxmFcoAlhG/aHxOVt9AiQ
FR6Ano2sGNeAEmAHriUaF76H7gCY9TjoDIzSsXGdEvTtwKgBo8do3K3rdAeQghED9+cRICviF3Y0
l4G98dBgdu8Bkrh9G2ViLBt8DpAL5MFyIehXQC2gxaAa9EqAeFjJjlrJhpUBWBngVrKBXPTnwVoh
KNNmmsxPFVrPQOsYtJ6B1jFoHYPWALQGoMU0jkHjGDRYFC7hRIitajzmYSu7B5pJYd+oubKjnmbT
E7guAi2GjBUQ6UsskvQZHsln+Kw7KI+dNJC8AxBH+gX6OWQlHmMLj/8xksVZ4TJxLpAHPB4eEovC
Q9gP48LToDMNT0g9yHM28pyNPGeLU8JbxPuomGT0HkPvMfSyzO9C5neRhN4XRq4MQmb4TXFq+DUx
JXxA7Ay/SWOF9PCbwgPAg8BsjI4HJgFmIBlIBe6H5BhhZvhVYRasyeFXUV02WLXBqk2ciPkQU9hk
f6kHc9EEyK6G7GpYz4HlHFjOged98MYGH23w0QY7q8X48EYxEfyd4QFxMugU0LtB7wHM4RysrEKc
Hs4hEXZfxmwv44RnVYxK/b/yR2HSTDIq9fWYFI1D7/PQfwY+nkUEzsLPs/DzLCSfRxTOIgpnxbuA
aYAZSAWmA/eHz/6D3ZHZR/Lw6ofyoERr6gbq6cboKJCInGxELjbSvdGdwvOMmpuGmpuGOY7By2Pw
cpqQATwIzOZ1MPSRaB5DNI/B82ki9MUJ4XxEIh9RredRvQc0CeeCGWOfDhcgOs+In0HffTQkpkFu
OvpnhPNxv415Oh5xh7fR6n/mE3L6US8+nNOJ4D8+r608r6z++hH9fljsh8V++N+PqL8GqX5EvB9S
/Yh4P54J4Nf/eF0lwpIb8w/AmhuZ6INFN3xwQ/sYvO+D9jH4sxEWjsECq6w+WHDDNzcsuOGbG9nr
Q+VjX1H8P1TTx1VS8keqiWmdhNZJaJ2EFsviSUifhPRJSL+MjP0BGiehcRJZ+gO0TvLYHYDWAWgd
gNYBaB3AXAegeQCaB6B5ABoHcArE9j3b86ZP1IvppEb0MMsBPLeMCyuoSIV+HHZTH9AfHsbJtSNc
xls3ntp2IOILKFt8NHxe/ALNEnPDw+KXwH8ZlJ1iS8K9Yj5OssfBP4k+jSaJDaDLINMI3k2zKEHM
Qg+zkMs1z0OzB5ovQ/O8+BjGHsc1zkJYOC9agWpgGXz5FDSHxAWQWMgtDIlf4FaGYGUIVtywMsTn
fwx+RKyshoUhsRRyNUADeOZLE9AMvjV8Hk+dH7NuzOTGTG7MMoxZVos58C8X9Muwyixq4EuAUsg8
DVSArwZqgFrAhr560GWgTlAX4AFaYV8RlyAW+XylO8VyxNOG62WIjcjnWwqvxkYjNByJEMaXIN5F
AIvp06gnG4/KeTJGoxCL5TCicJ7H8nHwiB/uNKOjHZl7J/sdeVw9xWeeRGOiGucj9gHm09LIKGJ1
HrmbRCaeu1gG2LxLQB9DTCJzDSMewzxfiDCe68fdWo6TZTlOlmGcLMOI7uqRyC6E1O3ojlorr4bh
aDX0cKsaz2EZ1t2LdfeKbvS14m45bsQfXpGQilnKA7+EV8Lq6L11J68ntroyRBErwptG7Anox+Fe
+NYbzTyrsSFxISQjVodhsYfXVcSXHmS+F76sRtZ7xSqgGn013LcysQ6UZX4pz/5qRKJXbAGcgAvw
AK3h1ZSK6FxGdC6PRCfiRQ+8OB+NUk80QkO8yvP5nojE+SmA1d//hkwkMm6xDOPl3KsesRJ8FWg1
+mtAawFWk3Wg9cBS8E2gdsABtAAegNWnMRrVIT5zHiwuGcnwTlgcojjuV2znRfzaGa3IYVRxLt/7
rJ61WGWzE4TtHLy14UQZVUdD0SjvRO6Go1XA8jc7Wldl0XOgB9XH84Laj2X7MWhFqm4IWZ3EfOP7
nO1rNZrJ3mit9ozaI6ujtllV9USzdx5vVuX8jIicV81YyThk+2Uu8zR6yoByXt9Mnu9Ttl6xkdf7
ED9RdMDNPRim8dDGDgPY+XPbAjvRXuZ+sogtHZkzYqkZ1vXo2TQ2djbB0nDUj+GohWFoMx+GuaQI
nWG+R8dEZxwe5e/QqJNvmPmJtT41am/ryJBpRO/pES9ve8hP8OipiZlwPiG/sDGLnxXlLPajzoyG
qG3mj8h7WTQlPgOzzE4c4ygfI+uJRb4pGn0m8XJ0dOdHR/mqDTzrtlEn1NjYnuaxZ3XB444zNhKx
6GogOR6SsyE5m/qgr0XPwtsak7hGJEtnsWcimiwG7miFxY1EbLT3Md/GjGQ/Fs/b2Y7Fchgr+Mgo
ovR09GoZj14DdkAz35U8NyzasfxH765NI/7EIhrzPDbKZhJH1hs3cse7ffKU4eQp43f8MfxN4f/0
liDSQ/y/PRFNwEegFGLf/E7HR6IH8DHQbHxkSD2EZ+KH8YmjRygL7zfz8RlLX8LHRF/BRyUraXjn
K8FnHP0c71DjaS8+icL9wiy6U3hAeIAm4n1+Nk0S3hbepruEd4X3aIrwvvA+3SN8IHxASSL7YyLT
RFmU6V4xThxLyaIqxlOqOE4cR2niJHESTRfvEu+iGeLd4lS6X5wm3ovKTRFTKENMFVPpQXG6OJ0y
xfvF+2m2mC6m0xxxjgjfxSzxUXpYzBZz6HNirphLi8TFYgF9XnwC9+LFokUspjxRQ/0/JlaJNfSk
aENWNLFetNNTYovYgqdPl+ihSnGFuIJqxJXiSqoVO8VOspGgVCl97FtuOkFziOzdwGYSHMdBtwDb
wJ8CHQB2Aruj2Ae8GMVhomYb6FHgBHAaOudALwCXgWvATciIgBFIACYAUwAzkArMhM4l0ExgHh8T
HFf5uOC4AboAyAYWAwWAhYQWpL25BKggcvYCW4F+EpyDoLuAvUK5fbMjy2FoCdh3OwprSh1V9gsO
O8dNh6vZ6NgEfmtzSYvKaUWL2nzR4QdW2rc4Ftq3AQOOhbUZjoXNL7UU2RVHjn2nI2dE5qijGH0L
0bcwYr92bXOPo7S5z1Fq3+co5OMvgp4AvT2vfxRfar8MCjSL0EuA7DXgpmMTrjc1mx293C9Gjzq2
Yo5duD40Qq85jnDcdBznuOA4BZxrTnUcb54JzHOcAs5B/1RzQYvCke24EeNja68pbUliaPa2zOBY
0TIXcSts7nRsYGto3g4/N8O/HS3UPNQyn8UiFoPmiy0aUMbWHo0x5GGfwey4EYtfDIhXHothLG7c
1iu37dkPY/2nR8Vtt6OY520ffDhau36k/6Pjo+KImNgZkN/SUbFuH537T5BxNU/AuhMca4B14Nex
fIDfwPtjmBLJD8vTaPCcGSN5g0/9UToYzd8gfN370fw1ZyJPLF8LkKMF0VwxbG/p4DAj5gWgDOhv
WdWiMERl1nKM7mf5XQzMRL1sjtY1cgzbkfq2RCj6j6M/MVb3nNo4vYHryaBrQBNj/c2NqI8gaoNh
NK/f5lFDKaifDI5OxPOoo765C7F7FuDXteubN6KmbudqJd8vJSwHLYti4DURA6uN16P8G8CZ0bUX
24fYd2zsYksNrl2gDYCj+YrjUvP1Fk/zrSiN5KEf8T/I13V7n1wCrrK6RzxzEbd8Ns7R7ZjD9ySr
AzGa4/3IyR7sgyi1724J8PrnNcn3QaxmizEfo8nMx0g/aOxsGF2z0Rpk9Ygc2VnN8ZqK7n39OrMB
XMYev+w4p9/Cfj8KXItcOw1YR8Ht60h9OJM5RtVKbF28FoyRvPNrI7uG/di12JLIgJzOdaZh7fxM
aAk0dzrT2Vqcc+Af9qkzC/QEWxc7PxzJHOKo8wu+4+5i4t+cEv/O1Mi/LR3Dv9NM4N9mjuffY07g
32Dezb+7vJd/a/lp/o1hKv++Lx1WfiO+JeJ+Ik2TppEo3SvdS5J0nzSdDNL90v0UJ82SZsH6A9ID
NEZ6UHqQxkqzpdlkkh6S5pIqhaR/owTpa9K/053SaukZmix9Q/oG3S19U/oWTZW+LX2bpknfkb5D
Zum70nfpXul70vcpWfqB9B/0GemH0o8oTfqx9GO6X/pP6T9ppvQT6Sc0S/qp9FPif+OCHpD+S/ov
ypB+Lv2cHpR+If2CMqVfSr+k2dKvpF/RHOnX0q/pIek56TmaKz0vPU8PSy9IL9A86YD0Mj0iDUuv
0iLpj9Jr9AXpmHSMcqU/SSfpS9Kb0puUL/1F+gs9Jp2VzlKBdF76Gz0uvSW9QxY5TZ5JT8nz5Wwq
k3PkHKqTc+XFVC/nyXm0TM6X86lRLpALqEkulAvJLhfJRdQsW2QLOeRiuZhaZE3WSJdL5BJyyqVy
KbnkMrmM3HKFXEEeuUquola5RraRV66XG2i53CjbKSg7ZJ2+KrtkD62QvbKfvi4H5AB1ykE5SKvl
drmd1sgdcgc9I6+QV9BaeaW8kr4hr5JXUZfcKXfSN+U18hpaJ6+V19K35C65i9bL6+R19G15vbye
npXxoe/IG+QNtEHulrvpu/JGeSN1y5vkTfQ9ebO8mTbKPXIPfV/ulXtpk7xF3kI/kPvkPtosb5W3
0n/I2+Rt1CNvl7fTD+V+uZ965QF5gH4k75B/RVvkX8vP0Tb5efk39DP5Bfm3NCAfkH9Hv5B/L/+B
dsovyy/Tr+VheZh2ya/Kr9Jz8h/lP9Ju+TX5NXpePiYfoz3yn+Q/0W/kP8t/pr3ySfkkvSC/Kb9J
++S/yH+h38pn5bO0Xz4vn6cD8l/lv9JB+W/y3+h38lvyW/Si/Lb8Nv1efkd+h16S35XfpT/I78nv
0SH5ffl9eln+QP6ADst/l8M0rAiKREcUWYmj15QxiomOK/FKPP1ZGaeMozeUO5Q76KRyp3InnVI+
pXyK3lQmKZPotHKXcjf9RblHSaZzSoqSQpeUVCWV3lLSlDS6rMxQZtDbykxlJl1R0pV0ekfJUDLo
qpKpzKV3lXnKPLqhZCmfpQ+UBcrn6e9KiVIiSEqpUioYlDKlTJCVCqVCUPDUWCvEKXVKnWBSlioN
gqo4lBYhwTTGNEYYb/qZaVC4Q8Xjr3CXalANwhRVURXhbtWoGoWp6lh1rHCPin9CkpqgJgjT1PHq
eMGsJqqJwr3qBHWCkKxOVCcKn1Ynq5OFFHWKOkX4jDpVnSqkqkmqWbhPTVZThBlqqpoqzFLT1DQh
XZ2hzhAeUGeqM4UMNV1NFx5UM9T5Qqa6QF0ofE5dpBYIi9RCtVB4XC1Si4RC1aJahCfUYrVYKFI1
VRO+opaoJYJFLVVLhSfVMrVMKFYr1ArBqlapVYKm1qg24Sm1Xq0XStUGtUF4Wm1UG4UyEsR5YuD2
83M1nkerK0ioxXN0NZ6JqxvBbwbVAS8QjGIF0BlFF1FNGuizwEagBzp49q7uA7YDO4AhYA+wH3gJ
eAV4HXgDOANchM420CvAdT4m1A7wcaEWz+3VtzCHARgLjAcmoh/P8TVTgWSi+hqgAXCQUO8BDQAd
dDfNoxwqwJsR++kdD7VTJ62nTXhXHaBdtJ8O03E6Q5fphmAQEoTJQrIwR8gRCkjSdjyVrA09labt
eQont7ZKO6F1a6fBBbU3tC7tDDiXdlBr1w6Ba9Be1DzaYXAV2g7Npr0Erlgb1Eq1g+Dytc1akbYF
XLbWoy3W8LaiZWlrtBxtHbgMba02X1sPLlXbqM3UusBN1fxasrYGXKJWo03WGsAZYTdBawQ3USvU
DFoxOFUrst7QNHCitsB6Wcsm0XpdW2g9o+WAu6TNsB7XMsCd1mZaD2uZ4PZgdL82FdygNt+6S0si
g/WEthgSBZCwWI/ChgHtYvQWoNdivaCVQHqV9YR1rRXrt223vmFdYdvxP3ZPlPnPGxH/SaPIz/SM
4T9PM4n/NMxdJCAr7XgzVpGvmUQVqKMK1FEF6qgCdVSBOqpAHVW8EQVqqeJiFKilypWg8LIC9VOJ
+qlE/VSifionAqidStROJWq3Mh1A/VdmAQuBHCAPKASKR/WXAlVAPWAHXIAfaCeqxTtlLd4na/E+
WYv3yNrTNNOaZk0H5gBZtQnWHGuedaJ1qjXZetBaZV1orbcWWoutdqvLWmr1o223rsRnjXWddYN1
E3p6rVvx6bcOgt9l3Vu7uLag1sI49lNkiD9WKF4V3yVRfA+5MPBcKDwXcTwXKnLxCDLy2ZGM3IGM
PE6TlSeQl6k8L/comqLRNORlK5lN25Cdz5g+MP2d7jOFkaMZ/x9nEmgh6TzX6WT853nCeWEs1ou9
xcHiFcWdxV3Fz9awn04xiu+I74C5Jl4jQc6Ss0hUCpVCklB7VjIoT6ECZdNPTD8hxXTLdIvi/iUd
IfHSnRgnVdhFOHNs8NWWAEwAppAYRK3ZzEAqgJq1ZUav5wELgOzo9eIoCqIyFqBkBIJNJzFkIBHn
ohgayynZKsCPB79vFHaibyIwNQLWhxIVQ8kRfY60KNKj8nMArDS0EMgZkb/tE85+WyOAc9/m5TaY
z1wnOi/ZcB+wreByYigv2tf5LwD3D9uzo4B7iK2Hx0OsCJL49IoRkK0v0lfB5t7OfeP+8esdn4jI
+BCj4p8sq9y72zbpuU5vW69lfetg21Y935nQ1q8Xte5qG9TzW/diVEPPLr0M7V69pvVg20G9Qfe0
HeI9g7qj9VDbEd3TeqTtuF7WehwyTP4UdHe1ndMD4C9xa1f1IsxyTs8FfwOSpyBZ1HouSJYtno1B
Re9wJgRV3pOor2q91Narr229Gpysr289hLbbaUO72ekNJln2td4IpuhbXJeCM/RuLwUz9G2QSdIH
3DXBufpOtPP13bxnn+dicJH+olcJ5uqHvSp6jqKdbNnnTYRWt3dyMF8/4U0KzrWc9qYEi/TT3hlB
Df2JkLzgzQiW6ZehWwM+EfwF79xgg+Wod37QoV/zLgoS2lz4j7gFPfpNb37boFP0FrXtdRq9Wtsp
8GVY43rvNraKUe027wDn0ToLeA9bXTf6d2Jd/9A6Ld7dQc1Z4t2H9dZ4XwxuRnu47aDlmvdoMMlZ
4T0BO5/Q6ru9p4NbeMsk0eqbebsNuinOBG9NMKBr3gZ4a/NeCG5zNqJ/QPf4x5bvck7wOoLknOL1
oDV6A5Dxeq8FX3QGvTeDh506JHdaOnxi27mlZd4OyJh5BCJaqd78YEe0Z6Z3VXCVMxPtWuc871q0
C7zrg+ud2dzm6HaxtxvRW+zdzFvGr/BcQb1tc+8OHtV36luCJ5ydPmNQdXb5EoJlzmcxywBWtDN4
mtdbP1/XbuRiSzAx4qGe772MqmP9+5wbfRPajluu+aYELzgzfWbEcFXrruBly1HE/5qzx5cavGk5
7JuJ6PUx3rmd8ZbDrbtCon7Tl4n6ZLk76tzhmxcyOoe8c0MJzj3wvN+5H3Xey/fOoPMl34LQBOeQ
Lxujr/gWtw0iU6dDovN1XwF03/BZgoucZ3wlWNGAZRXjUatH9X3OLvCLEc+9kN8ZnLx0PeOdF30V
8OeKz4Y9tc3XiJze9InwzeLTQ1OcEzh/3ftiyIzI54dSLTd93uBp563WwdBMl8EXDGW6xiILveBX
hOa5xjObrom+zmBKhNd3+7pQCUx3gWuq71noRvhkxlvW+za29bvSfD3lh1zpvr62c6weQqmuOWxF
rixY2AqvKsAv9G0f4XN8O3AysFilYEXgUXvgXXmMdxVyvhgrOu4qhZ1sVxXs8LyEsnXNNxRa7Kr3
daLfzr11+fYEk1x+3xC83ebbD769dWpwlWul76W2g855vlfaDrpWel/k/Oucx+5wrXF2le/CmdAR
KnCt870Rsrg2+M6ESlybYL9C32YZCNlcvThJktgJFkrgko1slpCuH/ZdDGVjX5/DqXXYmxHKdhrh
ySnXHJ6L7Ch/JTjZtdWZEKpw9bs95cnYBah2y03vtpBXd7B6QMyvBzXXYDTOV+D5rgjP9mAk/nyf
Jrn2snktu72JWPVB363gYdchvwFrPwKZTcjplfKVTotnQnCR6+DyhqDiOr7cEawB7+F8gPO3+4/4
/ciU7s0oX6lr/vGonKP+iaicMv9WrOiory+Y4j7s3t3e6z7aerV969Iydhdwn1je0d7vuuTvbR9k
Z2z7LqfZ39s26D69fBXyyHnLNXb2ui8sX9u+1315+frgIvc1d0f7QUQv0H6InfztR3C6qu3Hndng
T0G3O7jbfbP1VPs59M9tv+QaxMl/Ff2bUQNbfUPtVz3i8i3BbtcRRHuTx4j+KA//5wa7l5YFRFT1
Ye9A6Iz7QsCIebsDCaj87MAEnBgV7BxzjQ9Mwbp2M96y3j8VuxhzsfPTn4xqPI7K2eU6hXtTv7PL
n9Z2xHXKn46qPuefg8hf8mcFO1xX/Qvbtrpu+HMQpXx/VigVcctDTW7zF+JUyYVkCrtrhIKWVf5i
3lMaWgDJqtAKN/nrUcmn/PZQp1vxu0Jd7KQKPetWPRVtB92Jfn9QdZX629kdypUGz7vcSmije7J/
JSTLfEPBm+4kL4V6MOMaZMrjX9d2yp3i34A73Xr/JuypXH87qmKrvzfUp3ewuyruQSnBMvcMnF2q
O8N5BpVs0LtD21HJx3EKbdHLQjsYHxrC7HmIxtrWc6E97rn+/tB+Z4V/a+glRGMw9ArszA29jpNz
MPQGTgychPpu5qc7EDB3TMF6qcPs6QykdqR6ugIzO2Z6ng1kdmR6Ngbmdczz9AQWdCzw9Ome9izP
9kB2R7ZnR2Bxx2LPUKCgo8Cyz38pmOLZE7B0WDz7vRc6SrCvN+IJAfdrrKU4UAJ+M9vvngTkbtDz
UqDiq5quubeFFrP6CV1Hfm2hxSy/4PcEGjsq9N0BHefDvoC3w+Z5JRCEV6/Dq0bPG/BK95wJTIid
IZZtgRXBm+yO0OGF7pRgB05U3G0xVyfqqgv8btQVeFZXwd2Q6Qp2ROrHdYTz/P7ovoC71WbXykBC
cFWM9+5u3+saZLXnKg08y04DxuvbwKfAzsa2q56LgZ6OoNPMeH1LoCc415UX6IvVJ3RHeN0R6OpY
4TK4bnR06pvdu0M2z5XlSR1dnlTf9o5nPdcD21ED23DCTPDcwpPPgHsL7oMpLHcdG1nuOnrY7ois
InTGdal18Ktr2c7l0YvsjhPBlFZDYAdq5iZW2u1O8vWFzujd/sHQRfd85OKinosnqBT3IlTCFZw/
c0OiG0+DoevYO35W8/5dvN0LmXz/wdAt9yL/wXYDk0dbhHasc4X/UPl4yGchO0f9R1iL3TfZrXmp
fbzlsv942w1WS+jnc7G2faI+oF/A6VHmDoy0NXpu+9RIq+90drUno/JPhXrcDf5z7Wm8TeftHL5f
bNx/W6TSMCNhRof/attxt8d/g53PrDLdgeXUvtDdoeejDbhTyqfqJ5Yr7Tm8TWZtcK571ZPGkAWV
OZetFPHx6heWq+158KSovdC9Vi+rmO9ejx2NPbU8sfyGu9u9tr1YP+1eW34DkTwSTHrSuHwy4olo
hLzuouVJsHB5eUqwxp2Lne519cJPL8tX8Bpr20v1bl9fexU7h9ur3GshY3GVsszCTw2eHMbs9ZGn
MlibEfXH7t68PAMr/W/yvgYqquxK99xLUT/8WRYEaUS6KJEmNE0THlQACbKoGyO3qmjig6rCGNom
xBBiCG0AgQVI82N8PuMjhpCOcTqM7RjTY4yPoX2EMYa2HUJYLENo2+cjxqBteCxjXMRhGBcx8Pbe
997iVjW2ncxM1ltr1ln7O7v23Wefv332OfdSxYXTaXv9vtOuXqgd5C8d3FfYYm1vdi00N78i7Ot0
nX7FVVcOu2T8vrMtOe3tdWEt+e0H9w20bGs/sk/bkvrK0X1DLYUwesMtxe09gDvaj9XuaNkFUaK3
Zff+eYiQ7W139o00t7f30R6x6BpvnO9gDWFwel+EKDEB6zqirqn9VEN040SHFna6po4QPIF3mL6E
dwR99WVwtQ/P8x1RyHfEEh9fV4487pgdSa4F0KlC+SsRtcPAV2Bk60itvd642MGQBznxdZfwHqTB
jKf9OqG5ucMKa4e1V9Qboa75uilsD66Rjpx9p6EN+Q0JKG9I9sq3kbyQ+GLk26vqjzSOvWTB+4X2
rXVm0J9tSAOdHfX3Yc+ax77APgV8xy7iIQKjhdqBhnvtEw2ZwO9uyHUd6thD8t0o79hLfAPpbG0Q
mg92tDaILWfbzjYILQPEDwEvtgx3dDYUtYwAJsAePU/76TDsMs0dh2onYc+9QXwO8ReJ7ya+qi6i
ZRz29BmIjSfVfP01GMOEBhd6cn0ftLm3YWeLtuM48duIPwH6kxBjy+sqO067DrVMdsQ3VAJ/FuUd
Aw3V+7Qdp9/HD5H+cENYy3WY9zTXZMcI+P/1jvHa3a7xjkkVf534m8i3W6DN2R13wEtT2yOJL0Ye
Y7LCd9zF8wmcIS0tIa9Mwb7WDGeA2paQjrn6MbwThDPMzbbdroGG1zoWYB3d7HgE54EbqF/XBnPk
y9M5oa6t7Tj4yUU889S10Y52sZNv4OvaOvXId4wTH+Za2KeFU01ay53OiIamlrttuxvaWuYgKt5s
WXhlpuFAy6M2a1d9V3NXe2PzfmNbfmP9fmNXHqysdvBGiEjgM3gXOYcRu23HvnFYTaKEjUGtFzrf
aDS2Xuo81xjZtLfzfGNM62jnhUZL65XOS9I9cmNiU2HnKN5pdl7Bu8jOq40prVfhVCDd4dK9rXxX
q7pjle9V6S61Mb11yvdeVbobbcxune6casxrnemcbtzaeq9zptHR+qDzXuP21oedDxo9rQ+hFNlp
LGtdaotqrNiv6XyI9XYuUb2pWG+XRr6bxnvnVLx37grClnQZqSWpKy3pipR6IUVIvFPuisF75K4Y
qV945w6W6f4a4xKWBT8fwR2ky4I7SFciSrpScA12RTZW1VV2pcvWjlM7a/YHdWU3tu+PbG+Wnk5I
TwwaD+4b7tpaWwznnMHGI/tjuhzyswi662/s2W/p2t54bH9il0d+5kDjJj9VoPv3xv79W7uq5KcW
0vMBiZeeV0Cpjm2NfftT2i82ntqf3nGisWp/dldZ45n9eV0V+N8q6FeHTPWrQ55+dajR5+s9LJB+
aRhDvzSMo18axuvr9c3sef1+/X9nVvoVoY1+RVgU/NHgVFYcfDf4HttJv3x8kX7n+DmoI43Fs08w
xgT2WRbNytkrLJ3eb1TMutk3WAnrY3/L3OwUpFJ2hp1jO9iP2RB7kY2wd9lLbJr9lr3M/i+7x/ax
BbbMWjieS2Jf4w5xh9k5rpd7l/0D92vuDvtnTZXmy+yPmpOa77NlzQXNW1yAZlzzDmfQzGp+x63V
LAQGcB8JjA/cxG3UHtJe4DZph7VvcR7t29q3uR3aUe0vuc9o/7dOy31eZ9Ct476l26CL5U7q4nT7
uVOG/YYDfKDhvxmO8qGGbxuO8esMf2M4w683/Mgwxj9reMcwxX/K8GvDAv+C4Y9BEfwX8S9NfEdw
WPAavjPYFLyOPxD8m+BZ/nBITchrfG/Iv4Ty/D+Frg9dz78TuiF0I381NCk0if9V6HOhz9Fbn4tZ
FT0pjcXfa9l6gY4DnQA6zaJtx20nbKdtZ20DtiHbMHAjtnHbpO267abtju2ubQ7yBdsjgRf0QpgQ
IUQLZiEBf/tHc8v0Nr2N8XpRL9JvJE18Mp/MGJ/JZzKOz+azGc9v4bewAD6ftzENfZ9Lyzt5J9Px
JXwJ0/Nufgcz8C/yL7JQvpz/HAuj73MZ+S/zX2Zr+Tq+Dmzu45tYOH2fax2MdzyL0v5S+0t83s+u
s5vUMxP+ItJWwcptFbYqW42t3tZsa7cdtB2x9diO2fpsp2xnbP22QdtF22XbmG3Cds12w3bbNgv5
fdu8bVFgglYIEUxClBArxAtJQqpgFXKEfGEbyExCoVAs7BB2CbuFPcJeoUGAw7xtcSWRDqY5YYGS
yZseyemQ0C30fpIXjgMx4YRwGq6dBW5AGBKGhbvCiDAOnyaF68JN4Q7+vk73dzCakT5+jv9DIZ3V
gNdms0bw+Xzyczv49znmBA//MSsE/36XvUBvGCuiMfq0bqNuE9uue0b3DCvRPat7lrl0z+lSmFuX
qktlpTqrzsp26LJ12ewzuhxdDtup+5RuG/us7jO6nexFXZmuDNYLx47DSsJRtuCrw8BnmO0s0ADQ
ENAwy7FN22Zs92wPbA9tS4LG9lAIEoxCpBAjWGwPhEQhRUgXsoU8YavgANwO5BHKhAqhSqiBVC80
C+3CQeGI0AN4TOgTToHsDMj6hUGh2TZluyJctF2BNAr8VcArtnO287YLtkv4W0T9y/o6+rVpkM9o
NUJKZ7+AlMHeg2SFVf9b9nE2CylTV6QrYlm6El0Jy9ZV6CrYZsaFzIfSf8NhSfhutOIwoAjGueYg
jwYyA78A9CggrVjvukMU5rpLhHyEa6442rVAn82uR8UJbp7kyW59cZo7jOR4HWWKnlJO4TPdEV7b
KMeySGhL4dG2wue6o4nwOuZYj3JNIcFtputKOeSxPswVEqE+Ue4P1l0EuQvaiLm/vdXapG6bmh5X
1p+wrzvdCTQule5kb9+VdmFb8DqOjzKu4ipUDnWqCcsphH1RSGkbjhmWQ5vVUKcyNkrd6jlEG3If
84LcaT7jWCTneF3RV3K8VuvO9I6tYhvzJrkNyLe5cyk/4Ba8467kSt34GedTyZU24nhhn7APh93i
+8orfVPyo+6i4lfdruLX3Dt92qnui39bRb9xUPJoVduwP8r4+ftCuYpX+6xe7oMyfihTbJx0l/vU
oeRhj+m/0t8wv/4rn9F/kFfKQV0urSTzz706b7gri8+5q4sfus8VL7nPP3ZcVsubPuT1J+n9OfWU
y+OrjHO033x9UN608tkVIvX7cbl3XPzG2mWSxulJuXfexVVydT/Uvo/5eXetN25ccDcVX3K3Ea/k
SkxW1ueo+4D32hX3YaoX/V6J11fdR4un3K96x0y/4huUT7tf8/YR9WfcJ4vvgc4D9xvedS6XKdG4
L5QEuS+RHcUnIS8xukfRRkmk+4rXX5VcjnUlie7pkhj3VRrDJM+gK9Vz0WX1XHbleMYwrrvyPRMk
2+a55ir03CC9YoiJGC/95xjG0BUF9v3lsP5L+jzbye93rNThnfNdntvYB+9YP8n3yv3Wtr9P+ccr
/7gkjxG2ybXbM6vEENcez33XXs+8q8Gz6B0rpU7/eKz4zWr7k5+8xOKeonFGSnHPlKS776n3qZJs
94OSPPfDkq3uJR9byj4LVOLwaEq2e4KI93iMtOcqpNgp80RSXuGJKanyWEpqPInU/8dQSb0nBUnx
u5JmTzrl7Z5s9V5actCTV3LEs1W995T0eByUHwMbMI40v+q9PUHyg5JTHg/2l/p4xlNW0u+poHKD
nir1eJVc9NSUXPbUl4x5mksmPO0l1zwHS254jpTc9vSUzHqOldz39JXMe06VLHrOvC8Wrrb3KXuK
Og4/Lvf3L397ihz3sXKVv60W95tWsa/EROV8oKwTZc3rVb6EeuiLsfL+nLuSu+Kl+VZyLz2pn4+J
tT6+rM6VdRPmt4789z9VLKX+qHLvvu8Xk3zyx7W3yG88/erz7pX++6p/Xq2Kd+pcmRMlXidL4/2V
2q80KevN1VrKcB24Oku1rkOlIS7m6SfqLjUhec/hij3FNravtzTKu4axHvX5WFl/ytlYLk/xG/YJ
1/HSWO+6RzmsO1x/anuuE6Xxq569Zbuu06VJPuvQL0Ypsch1tjTV50yE1zAmDpRai/WlOcVhpfmu
odJtxCeXFhYnlBYX55bucA2X7qLPcL1YKN1N1+Gaa7y0geSgQ7lsg3hz6R7SGSndi3fx+q/r/wdj
wR+j/1z1++DfM/yPrAl/3ecrgQFsmZ6jvEjPUV7SDmvf5nroCcqr9ATlBD1BmaQnKLfoCcp7hv1B
EXw+PRe5Ts9F/g89F/kVPRe5Rc9FfofPRQKi8blIQCI+Fwn4KD4XCUjF5yIBH4M72pPsjZWnB1ae
bbPmWgWraC2yuqw7rcnWcmultdpaC9gEPG9tsx6wHrYetb5q1VvTrK/BlZPWN6xhlM4BnbeaAS9A
umQdtV6xXrWGpbdbp6zT1hnrPWsEpAfWh9alj2us0ZTM1gSoBVMaWcRP0USZoJtmNeOTAH0pfn/S
7962CWakhe2Hu9qzkLLoPjeb/ZJNwp3sVUif4H7OjbFczYTmHZaHz6ugJMc8rEzVXzOzyC1Ig/qk
nqfJfVd63qTq82HoMfb3HPTzDUjnQavceoHaiE/+1tEvEhl4TwLIEiHxcC+N/283GZKGpbDnWSD7
GEuD++sMlskM0CaBhbKtkMLYNkhrmAjJyByQ1rJC9gK09NNsO4sAn/OwSPovm9GsHtJ61gophrVB
2sDGIcVC399hT3NhXBiLo2+Htq70teBKQFrBlZy5gqsFUwXTuUcKZgruZYxtGS64V/Cg4GHBUsFV
UVPwQAwSjRke0ZhzR4wUY3KrRAvIEnMd1vicuzmPxBQxPaNPzEa0aq0s1yHmiVsz+nKrckasTHQU
zOQ2P18hbi+4UnBF9BRMk1Uj2PcmsQbsUNpSnPMoY0ysRytKsjIpZcyKZVCyOddhj0JbwB8Ujzxf
kVsF/DTRtFghVkF5DfTnKtZCqafgAbTPiO2GVkxt6c2tglJHxPaCGTEFtI+JfQVXcx1IGbNg54F4
SjxTMGWNL5gS+8XBgumcu2jBS0tWRgT6YhBYDhIvkvXL4liGJ2dENEKvkaA2mSbEa2hXqYUsKgRt
QBJvQH4PrAKJPWI9JhwJ8bY4u2VYzN4MbRTTQe++OA8tXLQzxZoYZNdi/T51A9lD7CYxEkYfegut
BE4hlFBJ0KJ2/Tk0bT/u034fsh/PGMvos5+wn7aftQ94+6ui1eQosw+ttNynFyC3D+MsS4RtwDq8
7b+ac1dMtMfmNgPGg1c2k9Wpgqv2pIxZe6rdmltjzymYsefbt9kLM8YK7pGfMntxwZJ9B2jtsu/O
7RHb7XtoDhfte+0NOJL2Vnsn+E46eC7Mof2QvRu8w2PvFfOcNc56Z7Oz3XnQecTZ4zzm7MvIc+aJ
zQUzzlM0m1CD84yzH8l+yHlKzJZK4DXn4PNl5Dve0ZRGTuzJmcQZX5lTUQO+1QPrbhZoHn3LedF5
mWyPOSdya3LmMmrIV4+JNVgCxybnrjU+Iw+Sx/GG45zCU8pznAffSYH8AtAl6D/L6MG05eyWs45R
xxXHVceUY9oa75iB8clz3HM8cDzcMrJlxLEktou3M/o+Ue3gcx1OzeZEZ5DT6Kh0RjpjqIYaa7zT
AqvzojMRfB3qcKZ8gs/Ns++l9QQ1O9Od2fZuGLsdn6jOGXfmObc6HeKic3vBktODs+QsE9OxJzlz
MIMj9nH7pP266IFewQq03wS6Y79uh56Jxza3e8frmH3OvmB/hL3PPZLzSBn3gnsOXsrFdIfeEeaI
cETjKlJkm/vA9qLDjORISG11JDvSCh5atV6itW3vdGRCnfkrccE7LxqIbUi07h25QIJDTG1F33EU
OVzkQzJPXnQdAthOR7l9r6PSnu+odtQ6mhxtjgOKd0NEdYDuYWllOo5CdG1GwtmUYoeDd7zqeM1x
MmekYAa8/0FGz4sTGG2d12AerjlvOCucVc7b4laMh9DGBzD3yfb83GNiIkTnR9AnJuZl9EnRGOfH
OSsec1pw5sU8qD3Red8571wUUwpZobYwpNAk5j1fZj9UGFUYWxgvegqTClMLrYU5hfmF2zLyCgsL
iwt3FCYVPMjtgdkyYsyFmA3RqXBX4W4cE2x3YYMUKdGDYVZHCvcU7qW98PP/iU5QlayGnpnj/5Rn
KfWMA4pI2QupAVIrpF2QOiEdShlP6YbUCykJ0nFIhyCdgHQaEsrOQhqANASpGNIwpJGUEfzvlvoX
9bvov3h+kn0KxrUAFnYAc8LpQMv+K4xeMIzzZ1k440JmQx5Qi+hvXVkDjMvJgXwI8vyAtKyzWY+I
BmRCfghoWP48AjQuyyeBrsvyYVk27FdO4W/KuSKflGlcxY+o+Dsyjcv5ddU1he7K10dUtgbkXCF1
f5RcaaO/vdXapG6bmh5X1p+wr3NynQuqvivtGpav3/Rrrz/51z+sogEVKW27I5cbl+tUxmZSJVfm
cFjVx0d+46jkkyp9JYdr2bxqbNXXlDZAnq2X8zBVGwb86h6Q51PJ1W0fkfLsiFXKD2X59DE7GsgM
lODbTp+++LfVfxz8c/86/edCTWqfVfqgjN+dFRvZyR9Q12r992+Df35TNQ9K/YrMP5d1stOAMoHa
gA58wLj8/5Ir46vkj5uvJ+Tefj8h9x9jZZyelPusL/98cpX2K/Zzs7xrJ1sAEmVeVOmpfDm7SKXj
kuyT38vxOnsnULlqzNS+gfNfmeWzDrOrgWqBmlTjrvjKYaCjWd616F2Tr8pteS3LN9YMZXljXfY5
oJMSv/kIUA/QMaC+LIrrm0/JsjNA/XLdGBMXVplDpQ/+cqhrc6LUN3UdyvXNg1IffGLgk3zNP95+
ULxaLS6NSG3afHFFvvky0BjQhGqsHheHlL6utj/5ybPfkMcZ6TzQhSyffSr7EtAo0BU/W3dWKPsq
0JTMT0tz4yXFzoyc3wN6APRQ7v9jKHtJIsXvNmvkPCjLZy/dbASKzPKJ05tj5Nwij2Oiqu8KwVht
TpH6i33cnA6ULZfL8x2vzVuBHEDbgTxAZUAVQFVANUD1QM1A7R/CP9R7ygfF5Q/rb0qurK3H7T2P
y9WxUb3W/XNlzh+XX38MPan+J8Xe1cbPf/2stv8/KVfFolXzP2d+1HYfs2euWv9q+aSqftW4u5V5
wjVwTVoHm28A3QY6KNOsRN7zqlJesY2+fD9rZQ2PZPmej5X1p5yN5fIYv3Gf2Dy/0gZae5HS+lPb
27yYtfrZW7abw7J816FfjFJiUY42y/dMNCmt45yQlf7lmFR+IevlRPn5iTzeOfErY+mdN/UaQJ3Y
rEf4vSd6ywL7z3OvyXXjf+FnIVwYvtgkaRhoBGgcaBLoOtBNoDtAd+XPc0ALQI+kz8/yMuklnWfD
gCJUFK3SMQMlACUDpcnlM4FyZbnwF5AIVKQiF9BOuR3lQJVSXUTVH0C1LC+pIak1qTPpUFL3U01J
vU/VYkrqVqXjCvfU0aQTSaefOixfPwF09qmipIGkgWfiETGXuSHpE2ieID0sO5x0OmkkaQQ0xlUJ
38Fgev83fenNIhp6p8hH6N0hkfTukKforSEx9L6QDfQdXzN9x/c5ekfIx+jtIOn0XpAMei+Ild4I
kklvBMmid4Fs+avXx3EmTvrW7BB7lrFnwJeeWfCjRzLlS3ki+E0i+FZimIrArxLBrxLNMvEyJch5
8oot0oW5T8yUiOT5K4TXLKNPpGef6X6m1y8df5/kg+WrJHybIH2Tm9GbY6R3xgTSN7mD6JvcofTO
mCh6T0wMvSFmA70bxkzvgLHQ218S6I0vifSWl4/S+12S/sPscuwsG1j5G9CGHubcNLVhENOm6Q2e
TTOb7m16sOkefX6IOdHShsEETUKQrDWYYEQ5poRIlCVYIBmltGkKk2IxIQYseu0RLkmWFDsbPGQh
CHROYTmUSzVvGMQnhzyOsZbv438CYf0t/p9YLP8zfoZt1O7T7mM2jJ5MCP5x8DD7JL2xJgrIJL8L
Js5bXgPlT0L5U/wQC+QvgK1oKhMDGpGE8nisT2EcEr71CRHfZsQyWa5KI4qZoiajJtfHWqottetj
18evT1pfCClqfWrUzfVWoJz1+eu3kY1X8Ru4/Pf570PdP+R/CJIf8T9iPN/P97MA/k3+TWjZP0Jr
AqFPo0xPvQmClv2EBQf/FNpnhBV3kBulZ3fb2Vrw5DbGnnZJZDmwwqvJcnh1ORBnecCcFodl0HzH
ctGcarmM+VMVlv44vWXs6UTLBPLK5+gkyzXUsWy33ECZxWO5jXLzTcss6YRZbljKLPcxR10kS4Vl
nsqArqXKsmip2cgUorKpG/OR0CaRZ6MWqNhL0DaFoG1Q/8Z4uY3zliMbkyR+o9WSvTEH6rtMdfWQ
nRC5XYNym+6r2nONbFdt3GE5tjE1OmljrKVv4zbLqY2FSv+fckA76jeGWJo3mqhf7dBfhT+4MYrm
Ed8JxugNWpxhh+GzjDe8aNjFtIYKQwXTG3YbvsAMhi8avsiCDV8xfIWFGPYavspCDfWGfWzNh/Zh
jjtD7yQLYfVwbmFxEA3jzst0AeiSTBDV4q4AXQWakmjDbshnpFxNcfdW+NipFYLPnCWSeKc505wZ
OxEVGRsT178OuHVF64pi5yFd3BAB3OK6IjN9jnNERT69OzZm3XlIRXGDZsFcHncQrozFjqEOaC1G
Ra47DyXOR8VERUZFxl2MOwLS2ahIsxB72+xaVxk7Yd7pJbJpPowU2x+7iGQW1mWahbgJL2WuJKmN
sfelNpqLoFxTXB/ycYNxp8wJcQ64GiO1D9smtysTahfBsogtAutye8A2tmfefADaeRlaMYbtjp2Q
+g96lXE95nJzJdQGZWNnwRLwccfgU60Z36sSwn+dhxjNf5v/NjPw3+G/w4IMpYZS8IAyQxl4wOcM
nwMPqDJUszDDy4aXWTi99SwieD54nq0LXgheYFH0XrOn/qwY5wEqAqqmKGeh35jsoO8y5MiRz0J6
TfSNA45tVemlsd34dh6vHgfR6Lvg0TzEI6qfaoul2vB9unrydEaeriFP15Kn68jTDeTpQeTpweDp
9SyULGEfGPUhkPqwidrTK7f7DNW9kWTt1GqODatkV+R2q/WGqNUcq5Fl+N+z/i1jj6Me9dhea8kS
I0scWeLJUgBZ0pMNfNNy4PvbQLUEk/2wx44FT+/8wtGQ5iGe+tggj0WNV8aznfIsqvV2y2OxTZb9
JbP0pHl/XLt72aCq3ZJsiJ1U+Z4kq5ZnUS07Ks+iIvv3msMPMwv/lllebSw4dp6N06kgGv/7eMR2
LzkjREjREUURroidgOXwaSfJKgklXoSrYkQ1pPKIWvqMvCinNkhixAGZRJVFPSSRSLGnWFLbqaYc
rzRR/ZXSZ+yL4SXDS9DnGgN4maHOgB7wofcm1k8zKP9lM7wM6BRzhp+AlE942puf8KbT4We9/AAk
QFO/6YipBpNKc9jUT6R8liydpXzFwlmvJclOfXiIJDF5gC6bKkyXw4fChxBNl9HLDZ83VP6lPTTd
B5pnTtOcacH0KJwP14eHhUcAYh4dbg5PID45PA2QD88MzwWZOVwIF4EvCndRKgfN6PBKSJlywjJ6
r8Xq8FrC6PAm0EFretlSm2yn3LQA11Cip9JIAl3ZST0sN9T+GfsHD+f/axRdpXWYgP8/n0vjMtkl
+PyqjzSRS6Eo3O4jjeXiKZbv8ZFGcNGsDT67fKRBnJF+Z5nnI2WclhXD5ySVlGcLdM6O8MpW+vbk
FW7iT/Cvg8bf8acgsv2A/wGcrM/wZ6DkOf4cjM0gP8h0MDZvMT1/GUbIwP+Cn4D4M8m/w0L5d/l3
2Rr+On+dGfkpfoqt5af5abD5Hv8exJyh4CGIOT+BU/lH4FT+U/ANPNt/g/DrhN95H/8NFX9Uxfeo
+G/JPPSdM3PQX055T+kzJIviYuHTnI/MyGHtN3xkei4MPo36yHCEOZhplYw9ZEvwqc9HNgejzsFe
pJbNsvu0G6ll02wGPlX4yKTfmRb5yCbIt3J8ZKM+e4EkG2Yjqrl+hu7RcF4ZxWSOYjJG4z204/mM
qqHqfaN6VCX/JvHlKr5MNfJfV438N1Z4WedbqrLfUtmU+C/5zJrEY18s9K1OvI+UepO4og3tl+5B
EfsBg1ggnPaCvFKfeBOyxFiohjlDWag2NATIFBoVGguIeTx8TgpNhRQVagXMCc0H+TZIJpAXhhaD
BqY9ch5P5dQpFvRMUFYbuhdsNECOOiHy1Ryg1tAddE0qjbSDUmroLsBdobtV54YPez8TxhVTD/dC
v5kpCMioIrj/MMG4mSxA4CGmFFmOen1+dErOz8h8P1A6UDZQnvTZ2MucQZ1rp9cWAc6svbf2wdqH
kO6tXTJpgjoxmYLWLmFu3LZ22mRcO2MymiJNRtB+gMkUZLKYLKRnlJJUSrFoSkSLgGTPlIK20NKK
HVM62NWsnQ4WgY8JTg7aE3TcFAPYGbTn3+3E82F3s9sULULou8QsOBXICpQj50j5QNvkvFC+hnrF
Mu2A8WwNToB+HApOC84Mzg0WIInBRUGHgloxAS9SLoBWGqSEYFfwTvoMCfIi0MXrO6Ukl1qxWK22
h7ZkS4qdzOAE0ExAW0ENQd1B3cHlwZWQtwZ1/4X3J3+R566BtWmE+GwEzzSChxrBc43guUbwXCN4
rhE815gu6zmA4DRo9ADBKckIcdNYBVQjX6sHAq815skEn9NamVM3tiYhrBcweU0mpFxImWum14i6
MUxritYIlOeuSVjjAh3Xmp1rXPQZU/WayjWVdN0lJbmUr8VM0CJ7aIssrdjJhE8iUC7w5fq9un7d
7TXlgGO6/r+65+L7eBdVJwC839Eu1fzpjpKesGOgPkezhzF4dDlTickBndpu4Ge0OLczukOEHpTr
LjBO0xp4AyLzfS3uYosBVxkXeEMLd8maaJQbUgJmGaeL0ThAclt7AHykLJBh2WXc4WYQQQPiPyfS
LjCzVIM8YkAnSgI6/zSFOoiaVpTwF0hzERHqANR8nuT3EXV7lk6AvGEZdvOA7Yhc8nIVnhS0dxF1
pwnjSFJM2E2I7b+hxe9ezmlLEXUTpNmFO5R2GrBXi3dyaTo9yfeQDmIfIQvE+1OGV0G/lCT0HCFw
gCRYlmluEx9G8huk/xohWZDrukaIo71IpRaxR2wRewH8Vby6lEuYTkh3v0swb8vhaHnp12TfoPkp
1XgeRuaHOgHwdcIeLcw0/xbhfcIplAesRz5gmCQTxP+CMIkkz2reBhQICyREObdE/AQid5f4twjr
CbMlHbITQna2oHz5D/wfQGIOhN5pjmjgvByYrIFdXfN75DU/Jfk+xMDPaN4Afgl5rgkxoJCufpck
zsB/hGObiTQ5wi+ThUtk00MYSpImsvO3pBNEGI6oE8nae4SS/RMBJ7DvhN8LAG8PeDewH0cGJfz2
wDHg72g2Av4vlHDJGjyHPo8YYCU+AfW1JtnC3wO+jXJ+v2YD8J8NgPZw/6LJAP4nVOqbiIFfJX43
4XHC/4moLSM7jxC101RjNco1WpLfJc3txEdRXWbiO0lzsyaRWogr5Q+IAZOIGpLwLxPfFnAd34JO
mmWkM0Z4BpGt51zoRYQGQj0HK3H5Pv8m/WeWVFyzHN4H3QhYjy3H+xxumsdxWEIMWA/rkuNTkedf
I74rYBv6A/H3CX+DEv51wgmUcBtI/hARogr+gmkR+YDdhEl0dUITjf2V7CDPnyb+C4RTpDlG/OuE
HsJnOYiWfCG151nCbGqthnh8pxj0SHMOkfhbkgTbALWjzhZCD8nnqOw8SX6DuDynSYNRdQRWA57D
tR/wJZqROmrtbuK/SfwJRNCpJp8HTc0VRP51KpVEkmi8GjBLOrWyZIA8eQBHiTRDSNKBGPhV4jNJ
/yihiywME1+FV3XrSOco4UfJwjfJ2hJFqmVqWwgiu0U236Y2N0l+ReP8Bc1/AV5HPhYe+CLofJxK
ZUl9JNyGuHwbT/j8axTnI5f/QNEb478ZeW4DXX0dr/Ie4t8lvp/wEOnvkeWoP0+SVEKB0LS0U7m7
g6u4p0ySfgJZSKBSdwn3kc4S4ScJpXvHtwnxbQ2wjvCJIsz0FwGPkJ37S+ex76Rzg/aUGuQDqRbQ
R81OjM9wLw3zDiuBdjdEzdPE1xE2kWal5rug+RncBTgXn4U8vx1G6U2+jfBNwjs0GrcA75BfhfIQ
hXiOVtN2wlfJ6+ya3+F+r3kPJH+DlgPMZN9D/CwiN0+SCyTpJNyOqIkmeQJJzhP+gvBLiIGJpPNt
4iOIP0d8A9m8RBIH6b9KWIPIFjX4VHOU8GuIXBTxfYjQKuRvEV4kSQxZ66aW6GULKCHLfCrxyYTj
hIMk7yHcQ9hG8jIqy+Takad2shuEbxDOyTqIvYSHCasRl3cRX0GYg3YC0skyzRd3kuqaoJ5epXHY
Kllbph0cfBzPMz/G0Vg+h/0ivI8IcowkA4hwDkHJebp6gVAgeTfhNKLGQTrbCc2EIYSzpP866dwm
m6NUap4wirCZdA6Rfg3pPNJArObSNL8E/p8Dq4hfAjQHGtHz0X+4QOS5iMBYwODAEOQ1eI68pcVn
KdcD8UxyVxtCoycCPoc7DluveR6Q9ju2hXgD7m7LvyUdk6aN9BMIUf6viMA7CCMIM+mck0r4EToR
vURoIbwMpQbRt4HHd3Ksoz3UExiAI4ZnSHaLzlp9hLekkxi2mU8IpAgQOIqIpzs+Ac+rXJk2mXAe
kSSXUJO7RPJLJJ8nyTxJ5klyKbACEc+63DwitEHS6Sb9UZJL1kbJTjfpYO0e0kmW7JNON/HdZLkb
JWyR+jJKuEgn7UWptTg+/BbqyxbNvyJiKUC0kEx1dUv2qT0nCYtlHq8WoybsJhRjqT2vU9texx4B
n0wxn/qCdcGZoYb449geiGHgP+zTOPv0l5e7DH8Jy5iVEFtrYH9PWIdxbPlHUPYHFFfDIZqChSXa
HQi7SbKIyCVLPJ7n4TR7Hq8izyVLKJ3YqVQy3Qt00+m9G8+9gBhpE1DOe0hnnmyWkU4Z3rME0hOy
wAi0A1hFsXQHliLNearlEvHHCC9RjccI58lmGbVwjq7uk5BK7aOrv6K6fkXtv0WatySbeALnyqR2
0vgsShL5Kp7hR6nUKMrhai7xudTTEFzvfzqNEql2spOMM87mqBSjZ2BbCdnyzwEjlicBY0kSQZLY
5T/C+X8YJVAe8TwiT8/ZeD21ip56Qh9Rkkp8srR70lV6Xsn3EE5IOzVdbZZ6JO2txP8IEUYc1vKy
DRHqQj4aEaxhvfWELxNWI0K8+jnOCLYc5iWIeNr9seV8BekMEnbLvNRmjBiHCWcIJwn7CG9RjZXE
32B0l4E7JvsaR/etunKKNjSGFAmZFFXoWz3PoWT5PkogMuBqitLht1YmaeQZrhqIThSRtFE08tE0
O+TVFBm6ce74LbhmYW12Y6yW7pflu1pppeBYHafRE+Qx7MXzKvGhhFsI79Bo3yX+kHQCIfSgPpw3
8OoL8mz2MvlZN3eSJPQtHq5E0gcbUBciN0/YjcgWif8B4SXSSSA8TZJk4kMJtxDeIfld4i8QHiK8
jxiwna7+jLCZ8AWqZY50skkiEp4k/B7hEl19l3APSYqp5cU048XoIZyD+BeIfwF9A3oteT7ua8/R
qK6XPRD720+++ojOXflk7R8I8+QnzL203lEzm+TjhD8j/J50wiTNj9DOnk8YTPgpwkw6J3QQryWk
ExR7mtAon15wFxZJ803EP9mXKWYuHyQ8TlhFmEL4JuH/Y+/Lw6I4tvZruqZ6RmhQkSgqICIiiuKA
qOCKgoq4AxqjxCiboggIiESJAipuqHGJUa8iQWOM+xY1rmiMS9wTcV/jEvc9xiXCr+qtdq65N3f5
/vjd+3zP8+nj22dOnT516tQ5p6u6e0axamU6Px0oqi4pvQ96L3C00Ia1LnnzAq2cLj3N+NX8zXlx
dS59qNpyvC+QR/hy4CHErStoeTfgOXAMLJQy4p2IBJ2GPfQp6K2I/3ugvwP/NuijwC+AolIR7P6I
EfYLD5TdE/qJI3p5DJoY+wMxFiMfY+nPJj4jb66bmgnLxbWbc3APRA0CPgTuAKYCxeqOCHluFdYP
7BX4Q4FZwGBgDq6/hcDd/CrQy+zPcb9A4zWBaqBABWgkwDTwlws0TRVogLwCjhkyJhcz7rdA/i5a
ewJXCqTgs6ugocFYAs5BaL4AujVoBqwIThDokZBPB5aiLw3ohtYnkHwfdDmg1NwX8miltuC8RqsP
ODfAuQ16BWg7yJcHZgIV4EOMogCYBM4sYCK0RQBhuTEeKEftCDwETj6wP9ALGAmMAmKMxiGwRNrW
HKPbDESrWdq/Aa3JoIvRrzPoMCAspz9DWwA4YwTaYI7KYb7MsUDw6QLonwY93uC3B380zl0KPaeA
eeDA/wxzoTzCuU5o/RIaOqJ1IzSAz/xBF4LuDbwJtICPCCnrK+KQI49DZQwwC5E5QNwjMnyllhfx
KSKf7RdovCZQDRSoAI24N2hMA3+5QNNUgQbIK+DwCJ+LCJ+L2J4rIlZqELTJRWoWtPGu1CZopSdk
VgqkkGdYRVPoN5aAcxD9XgDdGjQDVgQnCPRIyKcDS2GhBnRD6xNIvg+6HFBq7gt5tFJbcF6j1Qec
G+DcBr0CtB3kywMzgQoQ1UMpACaBMwuYCG0RQFhujAfKUTsCD4GTD+wP9AJGAqOAGKNxCCyRtjXH
6DYD0WqW9m9AazLoYvTrDDoMCMspqpwxAJwxcjYxaxeAJZgjItAgZ3O5QBtgOcy4ORaIc+kCaJiG
vrzBJ1IedHvIjEZfS9HvKWAeOJgvhrlTcB/b5ITWL6GtI1o3QgP4zB807nWz3sCbQAv4iKuyvmIv
XNazjMd5WWdcVVeUduF4DThMIHUWaAAqBBgIfk/gPoEE8gZwjJCh08CX8sPRWg/YC5gN/iPQ0KAM
Bl7HuUmgF4FWgGZwCkG3BN0MOAacPOCnwI+BRqDUuQoIvmE86DdorQLOE3CegS4BDW2KCdgCaACO
gEw3YFNwOgKbQFtdYA1wGgHleG2AceC0B1qAjkAfoBuwMSQ/By6EtvNAjNrIIHMWrZtBX0GrPegv
gRPQ+hi0nK9dApmcF8yR0Q/YGpJHoWE/8D3wa4GPs5SfgEOAwcCtwB2QycRZ+eCEg/YAfQ6tkj8f
9HGx8uFxFYW4ErgSGAjEuohI/lOBPIqiEG+CMxf0r5DxKnsu7rti3bgJsfoCq0e8jWNUgVixU7z3
w5aDMxGrxJvgYBdMo0AnoXUpsBq07QNux5OseJz1ZelIsbMAJwV72yvQ0AroLzgm7NEM7kC5L+gN
SXv0It8w+VHYb8Kejsn1v5Pcr2FfHCKQtRBoVIFrwX+B50Qb5f3Y0lCxYheojBdW0WPyviX6GgQM
kv1Cwxm03pL7QfgwUiBdibGchORqsSeics/oDz+gAvCME63XYPlGzMIDWNgHHPBV2M99wlvZAYHG
zsAFYhesTEaPS6DfH/0WQV5D7xp0ZkgN4i4uvwgVY2ddjFELdABuB2YDM4AWnX8SfhY4G5xloLPh
t0TgA9x5wLNFije+jPqd7dJx2PUXod8izI44d59ueQp2i1LDSbE7AEYK5J6UvQjOYV3+JKrZSeiU
UZ0CySLQRRiR4JvhkytC0thS7l+gIRa4EHhARqMe/0WIjSjMspzBFIwdPkcsbcS8ZGLGK4CeAg17
5e4S8s3kPRlocMKoUxGBg+D5VJzVXkaLjAo9R8pxOk+cpeI+A8sXreopaI4Weoz3oP8cepwKq/IF
lkPsmZ8INOG+hLpF1zASM8LRhF2z2k/QjIC/DH77QepEXwVy14z7PHcEGsfJ+IGFxRhLkHjzm8l7
IMmGC5zvApm5GIsT6CjM6SuM9AI4ReDMQV/XwQmHD0cDBwOrATujdRMkl+F5wSloNkIDfMKOIPKz
ZTWDbch0WgtWDcNT1MnAxXiu6ga6BE9a3UG/BmagNRxoAmcZcJjqwrEmns/WBMcTtAM0fApOiEBy
F3hVyoC+AG3x8tku0IInv0uAlaDhGfiXgbP1585ijVGCp8xuApkjdM7WV25CZru+HgsRdyGwvnXX
MUR4G2sMN12PwI54dj8IPRqhzQLbxqHfRKBZcIydwd8EC+uDvwyan0lvQHMrYD0g1mlKFbTOBzbF
WZPBD2IPxRUH/J3izpKCtRDB+kfpDX5j9FgXvaSCkwjvlYHOhuQ5oJ0YhSKfjFOM5YScX7xT4Q09
WOXShpDfDl/tA90VraGgnUFjvcpnSuh8CnqU9Co014E9TpKWT+Rh+Y/o8TrQASNdD5ks0A+g4QH6
PSffCgDnNuTXg74sxyWf77MyYacedVOEPWK3TgMFTcdBc31IvoDMLNC90ddi6WdVvEkUhNaRaO2K
uTuMVjtouCJp8F/i7sRd0P1kzAuaDgGawN8jEbPwCPR50HOAN2XMs1xhv6DZcuAMGc/ivh+9BRln
+HY7ei8Ax1F/FyILWcPRgN0W1wlaf8siRkSjHpNCMgN+G4/WCPSyGpzjQOxWlBDgMMT/XeQO9lA0
Ss41RpGDc3NAPwT9UNI4l6LH27DkGfBT7AsQ7SbYr4YJNCE+2QHYs0qgeR1aPwO/BRA7JpoifQI9
sMQEb6iD4G3sEQxZspKgd09YEi01Q0M+7M+X9UHNhH8yESdTUJ0EHa4GcA3zIBPIRMUeL55M8Zrz
QOzjhAy5Jmg+73i7ANgeiLtVig9aLyA2rsInW4QeZZFe38RzoqfqCKFfr4SuqGCCP5eJN3x+RV8/
o4asBY7GuEbA/h/gH3vwUW8ZATYA53PIFMEnxwQaqwlkr8C5BI4tMACc6sDhMkrZU07fB+cW8DEk
O4s7YzwOg2BPJvoNQi0NQu8cTbg6sEz0fgsynQVyGUFXg28nA7cLeV4rMnGuwFhgA4G0CDl7C3iM
4VrDZHYjnoHbBRo9IHMJtK1AdQlDtAg0bUaEVMHYe8KGo9A/nEk7YRWTWSZ6b4/WTdD5EvRL+BNV
0ajAD6vA/wGjcJbyGO/vTOZsJt5qEBYeh55ZoHvDq9UFGgNgbS+0nsRZhfK6Jq8XurVBmP1M0ILf
AX39Lqul1K97UvQ4FnQz6Pwds3YfMt6iR9N06LmAftMROaegcyz62oneLwGRd8YFwLqYzaaQPwza
S0aRpCFzUeoBzoQkPMZyQSPauVcdMfuC0wQc5KC6GnQadMaCtgF+h9YPcFYv+LwR8GeMayHyxRmc
usCLwA6oA0GgDaDtoRk5qAwEvoGGYqlHZhZoN5z1HPRcnNVeXgsEmsZDG+q8KVHaI6s0JGeAcw80
qjH3tmjFFcGEqxLbCc1FrA7iuQ6uVhGYrzqI3jqI9jrIu5niPhV6xFVSjQTdDrQT+joKy3cB70F/
IazdJ2mpB1iMvgZCMgAZNxmYqMd/EGZH5PUYocGmj6DLzRS02R+ooF+sIsr5IJvwTh3DSsy0GBq6
I1argV6u1weBBj3yOdqkQR7v9Rnj9NgWqDIZY0HIDkF3Ar8DevETtIrqrUbDwzGI9gPiiQO9yE5y
TIVP0oytOG1rXCYi3DiZS2K1adgvaJ4Rk8V9NmCUQEM/zEgLcZYxTXiJR2yAuL9nFHuBVMExlIhe
jKjnRnl9QbV/01V/npLDsTzo8vqTFDybLsOTjrKxwERgd9w7ugs6XzyVEPJlz8tOgjNTXM2FHmWY
QFoZ9GTgdnACQZcINLgDD4PTG63hQDdwZoPWQD8AZgCXgX8M9GLgPKAF6AkMgeZykvPmrLi6YXSZ
oK9CQzxaWwsO38UI+X7AUvAvg74iWhVpQ4mgjY1AH0drfaATNL8C34wn1HVAe6GXKNCJkHwGbc2k
hdDWGTKbwMHYyQUpCY4d5CdD5xW8u2uSNsuxC44SDtyO59o3oeE7tK6XsyCegxv6AT8FZ6DuE6HN
DZrbyafqOLcTtD0AtobONaBLgHbSz5B3Bycbesbh3NPSA3I20boeO7JKkM8C/wX4uzHqFOltqQet
FNgVnI6SlrOge0zoOS+i0XBCIJ9xQb+EvDNaP4B8JKwKRS+hoKWXvCETBmvvyhFhjHPA90UvDmUe
AtHaTO9R8L2heYtANkOg8bVo5bSHqA/gVJOWyJgXbyMonsDGMv5BW/CWggu0ueC9hasCaWW0eoN2
K5shfI69LQW/ALhMekYiONnAZrIV6AycDVwPyUPwQCsZt9Ie4ANgNPAyJB1k5ICTCNtOA+/KuzfQ
876MasjsAx7HuecwrjBgP+BDjPEGZDZD83TwrwAHyYwGHYM4aQLJDKkNSOH/l/DJMWkncCDOKgVt
Bp2Kvk5hZm+Ks8z+gjYhT9VIYBDmrqdoNaFGqXXwJvw9zKMrxjUSVkUgKmIhiaqlSv1G8B9Jy99k
ILME7pE2y0zH/SKKu1L50JmPLC4QccLroQfi1gPVzENUHllhgIGoReOhpxnqA2oUuQZOez37hEw5
WccE0nhZ38AvBZ4HnoDOkNJ6HAloH0hmwtpFMqfgw6e4exkIxBN2ZS7G+6scNd4t6W+8zu3JMHYV
NKJ9N/Yj/XF3ejee7nkTor8jYEMKDMsJG5A6IJq4xXycmkgiB6bGDSH9BsVFp5LBiQPSk0im0Nsz
PMSNuPIrR5n4P/5IOWJLKpJKxE584jwzEd9a00h54kAciT3/LN40FS3EShnEtzF0WiEqoUJv58hQ
N/FbLGg36m2MVCDvxcQMTSHZwDxgPnAOsAC4LDYxYSBZH5+QNIBsAe5MSEpIJ3uBPySkJSeS48BT
XHAAuQD8OTE5JpHcAj4YGhebQJ4BX6XyZgMB4l44MVqRghI3p4R16h84f6UMBPes5bsvOtq+g+Z3
0O4dNAGlHpt3UNOxIvEg9Yk/aUFCSGcSSaJILEkk6SQLvxAwmywgS4gqXksgE6XNBgd5VOX7awaz
+E1n8QvbHvpxNhHf/DTYdCX4BozNRthrsDmqHy/IYwVXeay0np/Hj1Xay6PTIKnHqZj3xfU7Hdc/
X9dHId4nwhtE+FUThVvdRbzJYGqGT//h36Nig0VEGdwVf9re2Js4k2akLQkj4aQPiSaDSSoZSXK5
5z4lc0khWUbWkk1kJ9lHjpJT5BK5Tu6RZ+R3funQTJsINa00rTJtxnG1aQuOa0zf4rjWtJUfV3Fq
G46rTNtxXG3ageMa004c15p2EYUfi/mn1Vx6N46rTHtwXG36Dsc1pr04rjV9z6VXm/bxT2u49H4c
V5kO4LjadBDHNaYfcFxrOsSl15gO809rufQRHFeZjuK42nQMxzWm4ziuNZ3g0mv/xiPil8kzSfa/
5ZEfMfKVpp90z5zUPVOie+aU7pnTvJ+VpjO6f87qfjmn++W87pcLukcu6h65pHvksu6RK7pHrsIj
P+seuaZ75LrukRu6R27qHvkFHrmle+S27pE7ukfu6h65p3vk/r/wyBxSQJaS1f/QIw90jzzUPfJI
98hj3SNPdI88hUee6R75VY+Y57pnftM980L3zEtEzCvdP691//yu++WN7pdS3SNl0iO80MAjZoP0
iFmRHjFT4RGzUXrEzKRHzKr0iNkkPWI2S4+Yy/0PPLKXHCYnyQXukTvkCXllUAw2ZhvpEbOt9IhZ
kx4x20mPmO2lR8zlhUfMFaRHzBWlR8wO0iPmStIjZkfpEfN7wiPmytIj5irSI2YnGTHmqtIz5mrS
M+bqImLMztI/ZhfdP666f2rofqktRmp20/1SU/eLu+6XWrpfPKRf/sceuWf1iKfukTq6R7x0j9TV
PVJP94g3PFJf90gD3SM+ukca6h6x6B7xhUf8dI800j3ir3ukse6RJrpHmsIjAbpHAnWPNNM90lyP
mBa6Z1oiYlrpnmmteyZI90wb6Rnx25rCblyBZvIrgUaSxMtj/GrgTDyJhfsrhHQlvbWfeKUPNvcw
ztRO6tQsrQRUOOed0qlZ2mlOtYPcGZ2apZ0FJeTO6dQs/L6KB/EhAXw+OpNepD+v6ulkNJmonbf2
dMHa00VrT5esPV229nTF2tNVa08/v+1Ju8upDuZgzrunU7O0+6Dacd4DnfpnFl2zWnTdatENq0U3
rRb9YrXoltWi21aL7lgtemi16JHVosdWi55YLeK5b/Ax+PAFTDWlGl8P1lJq4VrMV252/lgFpBPx
a1HqH2aLr35oB6Iov4EKtVIdrVSYleoEiuE38Jz4WtEDZz7BWU9xxjNI/wrJ5yJalCf8DBEts0nV
v/cVmc/XNavJFvIjz58XPHM0Q2WDm6Gewd/QyhBqEO87G233cF3zQH1npfa+pZQjnJoL6qiVOmal
jlupE6DEqlRTfhS0co3jHLT9ZJU6aaVKQFHuPXviqJzCGcKSqYqw4jPInH5HprIibJqjfE8ol5yj
nLFqOmulzlmp81bqgpW6aKUuWanLVuoKKBNfNzsRNz57PqQJaaHwtYGykPd3EL0uVPZzqYUKXyko
BfzzD+AWKAc4t0C5atX1s+4LkzJN+ZTHS6GylEsuU1YSG2W1spqUV9Yq60gFZYOykTgom5StfMVP
sTJ25FEjfsVFrPsq6L+o+AVvWKGs4Do3cnmq7FB28LUijzxlNr4pLn4vT8Qhv+qI/yOdr3x5nVXm
K/OJi7JAWUBcuY5dpAa++d0a3/wOwi/fUXWCmqeI3QKl6J7aUBtxH4pq0Mcl6G3VhYrIN6g11JrC
QkMUWUHv0BrUi3pTH+pHm9BcOo6OpxPpZDqNTqez6Wd0Hi2gRXQp/ZquoKvoGrqOfkO/pTvobvo9
/YEepSdoCT1LL9Kr9AbXdY/ep4/oE+bF6rOWrDVrw4JZCGvPOrIw1pWFs16sD+vHotlANoQlszQ2
go1io1k2y2XjWB6byCazfDaNfcpmstlsDpvL5rMFrIAVsiVsGVvJ1rKNbDPbyraxXew7tp8dYsfY
CXaSnWHn2WV2jd1i99gj9oy9YK9ZmUpVk2qrllcrqpXUKmo11ZWP202tqbqrHqqn6qXWU+urPqpF
baQ2VgPU5mprtY0arEap/dU4Nc12ve1G202aoqmajWavOWiVtWpaDa2W5ql5afW0+pqv1lgL1Fpo
QVo7raPWReuuRWq9tSitvxariV+t+IqaqVhy1KA1+DzUoXWIwr3szeehAW3A64Mv9SWMNqaNiUpz
aA4x0bF0LDFz748n5egEOoHY0El0ErGlU+lUovHZmE7s6Cw+g/Z8Vj4j5fnMzCMV6EK6kFSkX9Av
iAP9kn5JKvGZ+po48tlaQd7jM7aKVOaztoZU4TO3jjjx2fuGVOUz+C2pxmdxB6nOZ3I3ceaz+T1x
oQfpQeJKj9AjpAaf2RPEjc9uCanJZ/gsceezfJHU4jN9lVezG/QGqU1v09vEk96ld0kdPvP3iRd9
SB+SuvQxfUzq8SjwIt48EuqT+qwFa0EasFasFfFhQSyINGRtWVti4dERQnx5hLQnfiyUhZJGPFLC
iD+Plq6kMY+YcNKER00v0pRHTh8SwKOnHwnkERRNmrF4Fk+as8F8R9OCJbEk0pKlslTSimWwDNKa
jWQjSRCPrtGkDY+wbNKWR1kuCeaRNo6E8GjLI+14xE0k7XnUTSYdeOTlk1AefdNIRx6Bn5IwHoUz
SSceibNJZx6Nc0gXHpFzSVcelfNJNx6ZC0h3Hp0FpAeP0EISzqN0CYngkbqMRPJoXUl68ohdS3rx
qN1I3meb2CbSW0Qv+YDH7y7Sl8fwdySKx/F+8iGP5UOkH4/nY+QjHtMnSH/2E/uJDGCn2WkSzeP7
PInhMX6ZxPI4v0bi2C/sFxLP7rK7ZCB7yB6SQewpe0oS2G/sNzKYx/9rMoSVsTKSyPOAkqE8F0wk
ieeDLUnmOVGepPC8qEiG8dyoRFJ5flQhaWpVtSpJV11UFzKc54o7yeCZ4kFG8mzxJKN4xniRLJ41
9cgnqvhG22iePT5kDM8gC8lW/VQ/kqP6q/4kl2dTABmrNlObkXFqK7UVGa8GqUEkT22rtiUTeIZF
kYk8y/qTSWqsGksmq6lqKpliu852Hcm33WC7gUy1/cb2GzKNZ59CpvMMVMmnPAttyAyeifZkJs9G
BzKLZ2RlMptnZTXymeaquZI5mrvmTj7nGepJ5vIs9SLzeKbWI/N5ttYnf9EsmoUs0Pw1f7JQC9AC
SAHP3hZkEc/gIFKohWgh5AstVAslRVpnrTNZzDO6O1nCszqSfMkzuzdZyrM7inzFM7w/WcazPJZ8
rSXyXF/Os/0eSaM1aV1qof70KZ1CZ9DP6V/oIrqYfkU30M10G92FinmYHqcn6Rl6nl6h1+gvvF7e
Y3XpU1aXedMprDPrziJZbxbF+rNYNoglshSWzjJZFitiS9lytpqt57H0LfNmO9keto/9wI7Sk/x4
ip1jF9lVdoPdYQ/YE/acvWKlqqKqqo1qR39hndX3qLtaXU1Um7BITvVTo9WB7KrtFs2omTVNq6A5
ak6as+ameWg+WiOtqdZca60Fax20Tlo3LVzrpfXR+mnRWryWxMeaippGUNMMqGYKqhlFNTOiajHU
KxWVyoRKZUalKodKZYNKZYuKpKEi2aEi2aMilUdFqoCKVBEVyQEVqRIqkiMq0nuoSJVRkaqgIjmh
IlVFRaqGilQdtcgZtcgFtcgVtagG6owb6kxN1Bl31JlaqDMeqDO1UWc8UWfqoM54oc7URZ2phzrj
jTpTH3WmASqADypAQ1QACyqALyqAHypAI1QAf1SAxqgATVEBAlABAlEBmqECNEcFaIEK0BIVoBUq
QGtUgCBUgDaoAG1RAYJRAUJQAdqhArRHBeiAChCKCtARFSAMFaATKkBnVIAuqABdUQG6oQJ057lf
g/RALocjiyOQxZHI3J7I3F7I3PeRub2RrR8gW/sgW/siW6OQrR8iW/shWz9CtvZHtg5AtkYjN2OQ
m7HIzTjkZjxycyBycxByMwG5ORi5OQS5mYjcHIrcTEJuJiM3U5Cbw5Cbqe/kZkPa6J/m5iF6jP5E
T/PcvIzc5DGk52a9fzs3t7B6bAfbzb5nB9kR+hM/lrCzem7eZvfZY/Yre8neqAaVqeWsuVmT5+YQ
5GZN5GY8z83Nf5qbfloTrZnWSmurtdfCtK7/l5v/l5v/i3PTYBD/I7Uz6UcK+VV0I9lJDmB3e5M8
wn0S7JtJPb6P4vs3+iuP5Vz6G8dx9CXHifQ1x2nqRKKwlmomx9bqSI5t1CyOwX+i4Tk0vICGV9Dw
OzRMgoaPoWEUNHwCDXz/p44WEqDGWKlsK5VjpXKt1FgrNc5KjQeFHbX2VNDas7ccXm2uEMLesFKi
8LrA94m8NqhE5fXBhph5Xsfje69huIPkSfyhpYLtYZ7N/Ex65y3F40Ls9o/wT0/57u0i5OzpGJ77
vE0e6R3sEMWOgmBvYOBnXhZ7QjyjMGPH+wvfja4U90CUQrlzJCW25W3t/+7JhbBJPJtyJ/W5d4P0
+wWHsJc9bN33Xxe/fgjqhpW6+ZZSRwjpf7o3xhMbPJHT8KSJu0p5RKsbBxoHGRP0J3cGKUVIFfE9
C0dwSZV+ltwqfdRy9fJC836zM5iUwtwqnTirg2Iw+NpayqnM254q1RixDFBtvFWD0ZDbVDEYCyMs
PSz13+E4F7lmO5MW+NuNRJM0kkwSSRxJ5/9aib+Wmu8oMzpO/0tkbFz1YUavFTM8xh1LTpjq6ONQ
mOvga8k19rfk0s6FVDEoio3PiooXupdFLTxU/PZsF25Kiq+3pa5KexptK7kHJ6d8nJowcFC6m1dM
XTffwMCmbl0SYlKT05Lj092Ck1NTfHxdLc5S+L0/tiSnDkhPSE7yrWmpIdppJae/tocnJ6e7tRme
Pig5NSH9Y4trFTtLU0uAH//TyNfi16eKna8f/9iYM/mfPpaP4SuuRK2k9IzwrWSpKD6YK9m8PyBt
UELSwHTeTQWLvWCaKpnC42KHJifFvjXM5h8ZVstSUxpW7d322Di3iISBSVyrW/fgNpZcg7vFzjqB
BgMjNNdQnnC+jZJrMJDNH39y6sMN7QKX+a/0PfeyduOOI4pf1yjY327YwxPtb53M/25I5/DoZ/OU
77qc6ZjY0KNV3K6jtTbbhm4eM/xiux3Lp9t3/76295PCX+xq1TjRxuNV9LxjVdt9OSusxrwjGxq6
fxfWICv57HuuzfMDKwRe3FH3WXzzBga/stI6oUu/STRMWPB66/qYMbkvowpzxo2ftvbJltmLjwUs
7T6+Sp0JXS9anpOWz/a9bJmzM+9+YuBXPv7PN/qssfkkekZm/IK5aXZ5a57sfer2bTeHqTGH6p/1
a1f1wbawOc27Rzgdje/x8fJVEw70arUot/vEJLau8e5RHjvC41vO63rYe3SjpHEd1BMFx8PylKQ8
sqR4wuUIRfwq8OKcV5ac3yyVuDtdahs1i41q5qHLmIlSS06R4BqMOfMtOZ9nV+h7POVhQmpBrR6j
Hdd3mVZ26IvU/3y85ZYnu8mUFi0mVjzR6nnMvctBlvLCxkoGQ5mRWSg/WFwEw95Y2eh42OVoBknp
u+bxub1d5/cI8VkcEvPIYiuayxuNPI3y3kkdKiJi1IrVo8M8nxzd3jW9qHed9HrDN+S9WdF5dibp
cvuHu04XEr63L8p6qgTv+2HC4RcRh/cs2tEr+VFMyNch5MGcA/NLnLfYLqpqN/v0OddVdT95eH9p
2srplwKntZw7eHvA0B8nrqn15vLtUwnlZkzcUXqVbPN/+lvWywoOPuxu3Tmz2g7xGrY5YPoVk93B
Dwcd2ZHdZkj8sm2bt03z/+EJrZA18tcfr7S9PKr06tWVpc8vl9htSDk181q3TQFFWQ1Otjzvbxvd
VFmUM7jWpOdRMdPX9tkWeLp/fs9x1Rr92nxuYa5W9NGUDfU3f/HloRXn3DbtslQd7+ZoV297+LM2
V/pZrs30SpiwO+Xnp1+tOJrdNjXDnteYkbzGROs1ZoDhWCvUwvLv5hHjdea/mNWi4ATyGtPUz8/f
4hcoCo6vpZH1oyVn7P8X2+wQODx0jV26dQ9/K07/gfi/rD07LJNet0tdFjGkYFI3Uqt450mXlus+
CAp4mjYj1/PmHAcScdY5177FUZdtO35rO/Xzk78HVLv+7ctr934aQHcV/nRqeJeo9l/f7/fox58T
+lZLu7PBearxSN2QwtgPGrrO/TBp/wqnwNy4vV9tXzF8YtU7Ez539NwwxjNjycmAwHHXNniWOL30
vv3jwcp9Ims++XzqhLy6pc861r855YWx9SdHjsyZmWc3jP58vFRr27js9JbWF6e1s/nk+elOq/o+
ykh1GVHrk0mN9zp/uL477dRhqOmrnhPnqtlLc1ZFdj2Tc+rVrrbFvjt72s0riejoYLl748uJWf32
juzjOMG8sWlC4V0/j3zz3ZcnHbde+f3InSXv6bXnhSXn1z+vPX/N4oBMlnagut9fPpqZ13PNpK37
5q1Ln4bpcykvsp4nsikbdcOlltHJUjn7z9M+RAjUMLa0NLcEFjYtbJzXaFB6ekqzhg1jUhN9hr6d
Q5+Y5KENU4YkCG7DlNTk2OEx6WkNgyN44PlwliX0rYUGg7GFpZkl4O1ni5JXX1c4YsSIP1MYl/qO
pvS/SShUHy86dkUlu8elFZPbZpwJXrFlX9tXHnH+q4evHWaZNmfT2Fep10uPNP2lWcrcHm72W4dt
PPis5PrkW14paSX3r+4Z9eBxL/8+2bl3K5xOpXccut67aJc/KqSbNmD4m6QFpotHvfs42QWu7f/m
XJlxubL4zKtpi7ft2D04srnvR9frJx163KWe8xPXjFF5a/ZNOLWu3v2Vh+2Lry8ac+vYrXGpkblO
SfUOFHy2sZrr7uRZ56OX7u40ZNXB+y1nXlvfcMXIEYEDB5NRuQtphUsxn3X0bHvpM/fdE2yPOy7+
6EKaX2oT17IDdb/3CO8WH3rQxeXr7z0DE7p3/ereHjXRJ7X645rnhnqEZue8F5S16HB6QFg3Xn0W
8uozXlafCoNt53UrJrVXVDzfrkbvkQOL/rYG/XfWOk148Wli8bX4+zcVpSeQf/wvrHUiE4bGpaUP
GJry7651LjRNer3mQNuwYU4Hjoa2iih+tcJxa32/bQ7dwg+Mvd+q0dmOvjO9Ns2IvVKj+7itezqd
GMNePBy+c8r+ZSWrE1LiM+vE39q0+eH4b488WP7GYYntB+51Gx4LOtvLWD3jm6GxQ8Miz198fGnX
orH7sy+P6aw0nf1rcYG5l+ugDkfOFmdENfxkU23jxl59BzvHlGVntXhQYqzdJXBEuunDPVFn8prW
H37Q/o5rYLmsjNKFiUkjr9xrNf3zgmH2H9Xr5hTd36/gx7Fdvd2jBrWbcqnhuArd17/8ptrUxAe1
/1LpxaEKp8fbP8vNSGuy77ORRYf7q/fY2rxGm1/M7juuzbje42cnra1RP/Rw8oLgK4NvjfGcNkTW
m1yDF/eIx59VHPP/jtVOBbWcvrN4zyCWMOSdQpl8q2vrz7/1X9Epb/r2BXdWNm8TvO+4par1BEfF
qLnakAgynO9CgkmbP66E/m4Z9ScFanaXir57srpvqzjtiwEmg31+SrupD9Mid7QuxxqUbekRMd75
fuCMzYt72V7K39S8+onXK786uHldj5rVk80Jo4fQIvf29xM3Ds1y39L+p3FPp5bfaZrcZPfd0bdT
Pmy3aOaPh49enFZ8dVe9I1n3Dq72K5nw7aGYvU1OONXclXGp+fwN1dMKak48s3GjQ2T+swV74sLm
e3ku6D+5fPP9leIyQ7cdWzW2Wbe10b0vWW7fDnS5NunJucCcl5Vq5sdmx6jGOU/mK8ENR7WfuLVM
ORv3MuzSOZo+awNL0g4vvOA1ICv0cZUFFWsGKM4TVqrfz/HbciNoX0TLHV9PunQrvunUZ+5zFhxe
OyKyR7NTqSHraz3nBWo5L1Az3y6PWJEFyyPzf2959HeFQNSoAL4aasxLk69vY1GjGsmPvuKjJWfD
f2J5VMdSW350TQpOSBkUl+oWEtHOrV1E12YBjUMaNWhkaRzcoHHb4Pa+tS215Jic/zimBhFiUG4R
cakZCTFx/7K8PTI2WD+nuFrOwNrrPKM3VOp01LK12CHg95w4f9PeJus9Bj03GYv/39inf9n+sVou
ScftpveSQJPtl3PeRllvaV7obivIoWea7frskE0PUxrTSonM115v1XXe2ZRHL7lSMNM7vEXgwnrd
H52yz15pbnl+fh5b0vKikEPWx87b73i4IUIg5+nS64cPlZrv/dL6sPGFxg3pj5/WfWxafO0686L5
oi2/bX+tfrjN6MQCppTPz/5LqRVyBHeJMn1qVi/zbCpc/n6tUcWx6zli/kqp05N83fT/K69vfbOs
YC/z6Vs3jFiPak9w2Dbvqk5bzvbTwka1vcfq1onrG/1J2y27wTX0x9pfuunN6ZqTWy5FLVRGbk4h
CoQX0799f9/z8Vnm48gMv+8zuqruztZDaSlhLTEoaSmVFBckJ1KlpQQzqQR7YY3S/mM7gK204rUv
j59os2+p6ZLbrKwt8mGf3s9cdpyjV3/zWfvCq2015fJ3X4tv2lvz+OfMT1yuHmtFdmfqfLJLTwr5
9K5eXXCS5ZtzN9v9Or4nuCtXq4s6cMzfz2vI0nTDdBvPHIbL3asqEo9u7XCca2d2J2KJ+myrW3vZ
YkWWbeL3Odhn0/0paeaPtLdXP8tobDC6fcqQc89vpQw3n1+Xi5Wea/YpMfwO28+2rnGB6C6Tnxp9
8l5JrAs7vza6v+SdyHE9wrpfLpszc+UBj5rQJvt4BgvnOWxn7G/o7/cv5rT9uyvuy/E35odSEhf4
XrEtOBO9Qbjx4JXFhlJ7U65Nu1RlrxXtFsxpc5b5p30kw5nO4ETDJpbZwBJrOhMjo0Fj+wB22VA6
koihrgWNx0C1EzTaOJkNeZDH0YD2InjchnwGyLKiwFIDrpHFEJjUb3yTZ5gz68Kp7akXbiUca2Wb
b3B2sUEakhYewwiDsAU6DVoMvgyZDMkMRQz54KG4NIYSBgVgdZgPFCkAk4lAkUwgK2+hWoMKzpRa
UlmQn16UWJBRqYBWMrE0MTKwTltw9ucMXz1h7V18kVvfHIpW/LDOPP+v4+ZdDuUZLx6sEZlnWn6j
w/9PxKZ9p46Y62x8NmlP/fWq9i0cb6qW+fdN4lLyC/lz8yFX3v+Nrz+X3mT6fERAoCemLSb6WESY
25Utl/uyvDIs7CweskV/uyFydDmj+AqVjwF6bm6uTLyy6xKyX2z9+Gv3wsi+q5tmL1O1uK1fru7+
Z+G8P5++3fjYt+Rz3Km8dMXfx2Nu7WJs+58fv+/AxJ6PJa3TVib3LjrU8G7vGYkeg4LIMCvTpR8P
h6wy8PkWt/xPezXL6fxK4QO3uWw5Zz3Xvpp95cbPqiCvnq6dpyR9Zs77kZVr1HRTp+zMF++lPJH+
+04fX9jEJG/QxCSNiCU2wyYmHqAQB92TI3oViVJxs0OT44JYAwnktMiNGPhlBNoJl2E15AfWqAYG
FqDq1cjY1CQKIykyPlWLf94j+SNcZ8VTuVKZvWfdl3mglU+gJOL0zXFeW/bKSQ8a+C7oTPhiwMEW
c0x/fsDzrZ4eC6a5Lfqe++tb0iV1O9X/stoJdq9Zjit9r9u3TG//Jk+OrKKXNiozlE/z1QnzPPM0
F5XoVz4Tf0iE89sBa3uGoFWbbu/4zd7zN+CAc7aOc5MiV8iTmmo5lubqHaoLJ126e0ZEglmg2+VW
4E77uqbHa4/mRa9lfXX/jaTT+ZC9i4/3nauL67gV2JZgvbZys86KNxNn/Jmdc1D87xQe4cKSqGdr
AjrZlBwuLIloS1LI/ybwbHXvj5OzJnmtm51iPbm2JHreF80pz9w/nH0bzBX5pe2IwmsDhlXcauUr
rhXcvH/si1VpftLym1qc31etO3HgiioDAwB8OA0tDQplbmRzdHJlYW0NCmVuZG9iag0KMTUxIDAg
b2JqDQpbIDBbIDc1MF0gIDEzNVsgMzUwXSBdIA0KZW5kb2JqDQoxNTIgMCBvYmoNCjw8L1R5cGUv
WFJlZi9TaXplIDE1Mi9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5mbyAyNCAwIFIvSURbPEQ2QURB
NjNDQjUwODE2NDNCQTk2NEJDQzZBNzY2QkM2PjxENkFEQTYzQ0I1MDgxNjQzQkE5NjRCQ0M2QTc2
NkJDNj5dIC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMzNj4+DQpzdHJlYW0NCnicNdO3UoJR
EIDRCyZMJHMCs6gg5ogZBTMqQTBhzgHTjDgWVja+jL2Fj+EYn8DGyk5/7qdb7Jnd2Z3ZZoVQ4udH
pWSDEDGu4UGi+pRodeAEmro3iT4M7BlMsC0xBiWWQ4mVyqWRuG0S76PE54AQfEn8NAN2SeRdCLVy
mVmcwCmcQRf8jZwrCyff/5UaVKCFOIiHBEiEJNBAMqRAKqRBOujAAHowQhZkQCZkQx7kQC7kQxEU
QCGYoBjMUALlUAplUAEWqIQqqIYaqAUr2KAO6sEODdAEjdAMrdACbdAB7dAJEXDABfRAN4zAIPRB
LwxAPzhhCIbBBW4YhXEYgwnwwCRMwTT4YQZmwQs+CEAQ5iAEizAPC7AEYViGFViDVViHLdiATdiG
HdiDXdiHAziCQzhWviPqkV91dRtD9XQjeb6UvNxLXj9iqKN3QvwCkZhFlw0KZW5kc3RyZWFtDQpl
bmRvYmoNCnhyZWYNCjAgMTUzDQowMDAwMDAwMDI1IDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAg
bg0KMDAwMDAwMDEyNSAwMDAwMCBuDQowMDAwMDAwMTg4IDAwMDAwIG4NCjAwMDAwMDA0OTMgMDAw
MDAgbg0KMDAwMDAwMzU5OSAwMDAwMCBuDQowMDAwMDAzNjUyIDAwMDAwIG4NCjAwMDAwMDM4MjEg
MDAwMDAgbg0KMDAwMDAwNDA2MSAwMDAwMCBuDQowMDAwMDA0MTkyIDAwMDAwIG4NCjAwMDAwMDQy
MjEgMDAwMDAgbg0KMDAwMDAwNDM4MiAwMDAwMCBuDQowMDAwMDA0NDU2IDAwMDAwIG4NCjAwMDAw
MDQ2OTcgMDAwMDAgbg0KMDAwMDAxMDM1MCAwMDAwMCBuDQowMDAwMDExMzUzIDAwMDAwIG4NCjAw
MDAwMTgxODQgMDAwMDAgbg0KMDAwMDAxODQ3NyAwMDAwMCBuDQowMDAwMDIxNjk2IDAwMDAwIG4N
CjAwMDAwMjE4MjAgMDAwMDAgbg0KMDAwMDAyMTg1MCAwMDAwMCBuDQowMDAwMDIyMDAyIDAwMDAw
IG4NCjAwMDAwMjIwNzYgMDAwMDAgbg0KMDAwMDAyMjMxOSAwMDAwMCBuDQowMDAwMDI5MTUwIDAw
MDAwIG4NCjAwMDAwMDAwMjYgNjU1MzUgZg0KMDAwMDAwMDAyNyA2NTUzNSBmDQowMDAwMDAwMDI4
IDY1NTM1IGYNCjAwMDAwMDAwMjkgNjU1MzUgZg0KMDAwMDAwMDAzMCA2NTUzNSBmDQowMDAwMDAw
MDMxIDY1NTM1IGYNCjAwMDAwMDAwMzIgNjU1MzUgZg0KMDAwMDAwMDAzMyA2NTUzNSBmDQowMDAw
MDAwMDM0IDY1NTM1IGYNCjAwMDAwMDAwMzUgNjU1MzUgZg0KMDAwMDAwMDAzNiA2NTUzNSBmDQow
MDAwMDAwMDM3IDY1NTM1IGYNCjAwMDAwMDAwMzggNjU1MzUgZg0KMDAwMDAwMDAzOSA2NTUzNSBm
DQowMDAwMDAwMDQwIDY1NTM1IGYNCjAwMDAwMDAwNDEgNjU1MzUgZg0KMDAwMDAwMDA0MiA2NTUz
NSBmDQowMDAwMDAwMDQzIDY1NTM1IGYNCjAwMDAwMDAwNDQgNjU1MzUgZg0KMDAwMDAwMDA0NSA2
NTUzNSBmDQowMDAwMDAwMDQ2IDY1NTM1IGYNCjAwMDAwMDAwNDcgNjU1MzUgZg0KMDAwMDAwMDA0
OCA2NTUzNSBmDQowMDAwMDAwMDQ5IDY1NTM1IGYNCjAwMDAwMDAwNTAgNjU1MzUgZg0KMDAwMDAw
MDA1MSA2NTUzNSBmDQowMDAwMDAwMDUyIDY1NTM1IGYNCjAwMDAwMDAwNTMgNjU1MzUgZg0KMDAw
MDAwMDA1NCA2NTUzNSBmDQowMDAwMDAwMDU1IDY1NTM1IGYNCjAwMDAwMDAwNTYgNjU1MzUgZg0K
MDAwMDAwMDA1NyA2NTUzNSBmDQowMDAwMDAwMDU4IDY1NTM1IGYNCjAwMDAwMDAwNTkgNjU1MzUg
Zg0KMDAwMDAwMDA2MCA2NTUzNSBmDQowMDAwMDAwMDYxIDY1NTM1IGYNCjAwMDAwMDAwNjIgNjU1
MzUgZg0KMDAwMDAwMDA2MyA2NTUzNSBmDQowMDAwMDAwMDY0IDY1NTM1IGYNCjAwMDAwMDAwNjUg
NjU1MzUgZg0KMDAwMDAwMDA2NiA2NTUzNSBmDQowMDAwMDAwMDY3IDY1NTM1IGYNCjAwMDAwMDAw
NjggNjU1MzUgZg0KMDAwMDAwMDA2OSA2NTUzNSBmDQowMDAwMDAwMDcwIDY1NTM1IGYNCjAwMDAw
MDAwNzEgNjU1MzUgZg0KMDAwMDAwMDA3MiA2NTUzNSBmDQowMDAwMDAwMDczIDY1NTM1IGYNCjAw
MDAwMDAwNzQgNjU1MzUgZg0KMDAwMDAwMDA3NSA2NTUzNSBmDQowMDAwMDAwMDc2IDY1NTM1IGYN
CjAwMDAwMDAwNzcgNjU1MzUgZg0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDc5IDY1NTM1
IGYNCjAwMDAwMDAwODAgNjU1MzUgZg0KMDAwMDAwMDA4MSA2NTUzNSBmDQowMDAwMDAwMDgyIDY1
NTM1IGYNCjAwMDAwMDAwODMgNjU1MzUgZg0KMDAwMDAwMDA4NCA2NTUzNSBmDQowMDAwMDAwMDg1
IDY1NTM1IGYNCjAwMDAwMDAwODYgNjU1MzUgZg0KMDAwMDAwMDA4NyA2NTUzNSBmDQowMDAwMDAw
MDg4IDY1NTM1IGYNCjAwMDAwMDAwODkgNjU1MzUgZg0KMDAwMDAwMDA5MCA2NTUzNSBmDQowMDAw
MDAwMDkxIDY1NTM1IGYNCjAwMDAwMDAwOTIgNjU1MzUgZg0KMDAwMDAwMDA5MyA2NTUzNSBmDQow
MDAwMDAwMDk0IDY1NTM1IGYNCjAwMDAwMDAwOTUgNjU1MzUgZg0KMDAwMDAwMDA5NiA2NTUzNSBm
DQowMDAwMDAwMDk3IDY1NTM1IGYNCjAwMDAwMDAwOTggNjU1MzUgZg0KMDAwMDAwMDA5OSA2NTUz
NSBmDQowMDAwMDAwMTAwIDY1NTM1IGYNCjAwMDAwMDAxMDEgNjU1MzUgZg0KMDAwMDAwMDEwMiA2
NTUzNSBmDQowMDAwMDAwMTAzIDY1NTM1IGYNCjAwMDAwMDAxMDQgNjU1MzUgZg0KMDAwMDAwMDEw
NSA2NTUzNSBmDQowMDAwMDAwMTA2IDY1NTM1IGYNCjAwMDAwMDAxMDcgNjU1MzUgZg0KMDAwMDAw
MDEwOCA2NTUzNSBmDQowMDAwMDAwMTA5IDY1NTM1IGYNCjAwMDAwMDAxMTAgNjU1MzUgZg0KMDAw
MDAwMDExMSA2NTUzNSBmDQowMDAwMDAwMTEyIDY1NTM1IGYNCjAwMDAwMDAxMTMgNjU1MzUgZg0K
MDAwMDAwMDExNCA2NTUzNSBmDQowMDAwMDAwMTE1IDY1NTM1IGYNCjAwMDAwMDAxMTYgNjU1MzUg
Zg0KMDAwMDAwMDExNyA2NTUzNSBmDQowMDAwMDAwMTE4IDY1NTM1IGYNCjAwMDAwMDAxMTkgNjU1
MzUgZg0KMDAwMDAwMDEyMCA2NTUzNSBmDQowMDAwMDAwMTIxIDY1NTM1IGYNCjAwMDAwMDAxMjIg
NjU1MzUgZg0KMDAwMDAwMDEyMyA2NTUzNSBmDQowMDAwMDAwMTI0IDY1NTM1IGYNCjAwMDAwMDAx
MjUgNjU1MzUgZg0KMDAwMDAwMDEyNiA2NTUzNSBmDQowMDAwMDAwMTI3IDY1NTM1IGYNCjAwMDAw
MDAxMjggNjU1MzUgZg0KMDAwMDAwMDEyOSA2NTUzNSBmDQowMDAwMDAwMTMwIDY1NTM1IGYNCjAw
MDAwMDAxMzEgNjU1MzUgZg0KMDAwMDAwMDEzMiA2NTUzNSBmDQowMDAwMDAwMTMzIDY1NTM1IGYN
CjAwMDAwMDAxMzQgNjU1MzUgZg0KMDAwMDAwMDEzNSA2NTUzNSBmDQowMDAwMDAwMTM2IDY1NTM1
IGYNCjAwMDAwMDAxMzcgNjU1MzUgZg0KMDAwMDAwMDEzOCA2NTUzNSBmDQowMDAwMDAwMTM5IDY1
NTM1IGYNCjAwMDAwMDAxNDAgNjU1MzUgZg0KMDAwMDAwMDE0MSA2NTUzNSBmDQowMDAwMDAwMTQy
IDY1NTM1IGYNCjAwMDAwMDAxNDMgNjU1MzUgZg0KMDAwMDAwMDE0NCA2NTUzNSBmDQowMDAwMDAw
MDAwIDY1NTM1IGYNCjAwMDAwMzEzMTIgMDAwMDAgbg0KMDAwMDAzMTYyMyAwMDAwMCBuDQowMDAw
MTIwOTYxIDAwMDAwIG4NCjAwMDAxMjE0NjUgMDAwMDAgbg0KMDAwMDEyMTc3NyAwMDAwMCBuDQow
MDAwMTIyMDc5IDAwMDAwIG4NCjAwMDAxNjI0NDQgMDAwMDAgbg0KMDAwMDE2MjQ4OCAwMDAwMCBu
DQp0cmFpbGVyDQo8PC9TaXplIDE1My9Sb290IDEgMCBSL0luZm8gMjQgMCBSL0lEWzxENkFEQTYz
Q0I1MDgxNjQzQkE5NjRCQ0M2QTc2NkJDNj48RDZBREE2M0NCNTA4MTY0M0JBOTY0QkNDNkE3NjZC
QzY+XSA+Pg0Kc3RhcnR4cmVmDQoxNjMwMjcNCiUlRU9GDQp4cmVmDQowIDANCnRyYWlsZXINCjw8
L1NpemUgMTUzL1Jvb3QgMSAwIFIvSW5mbyAyNCAwIFIvSURbPEQ2QURBNjNDQjUwODE2NDNCQTk2
NEJDQzZBNzY2QkM2PjxENkFEQTYzQ0I1MDgxNjQzQkE5NjRCQ0M2QTc2NkJDNj5dIC9QcmV2IDE2
MzAyNy9YUmVmU3RtIDE2MjQ4OD4+DQpzdGFydHhyZWYNCjE2NjI0Nw0KJSVFT0Y=

--_002_945CA011AD5F084CBEA3E851C0AB28890E820119SHSMSX101ccrcor_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_945CA011AD5F084CBEA3E851C0AB28890E820119SHSMSX101ccrcor_--


From xen-devel-bounces@lists.xen.org Wed Nov 05 13:38:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 13:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm0mv-0002Ie-Ar; Wed, 05 Nov 2014 13:38:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm0mu-0002IZ-1C
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 13:38:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C4/6B-09936-7482A545; Wed, 05 Nov 2014 13:38:15 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415194694!12932126!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14069 invoked from network); 5 Nov 2014 13:38:14 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 13:38:14 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so932655wgg.5
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 05:38:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=C3MPfSFB6vptJplv1uzZrN1vhDu4C2HnYesUvIBhZTo=;
	b=eHO9Bq6MxjRWcB+Qe6fZFZOlEjRb9E7GmPjdiHYDdLvmY9Qxc6nQ8pXjiKfMrjNOoi
	UBAFLHBJ7rUzUPNqFpK4EdPF+0SZ0Xmjabgzp6wH94MZTQNeDv8dqtzoBQdAmnEYQ+Ln
	N+b3hGnY7KO2UTagxqFIb7hIX054MZcJTAhNFws6NSpEa0vP6WNIxngdNITneEaVgRjv
	dGd9pnhzot0cYcwav9DyvGMBmZ4/rQFwf3vSpyD4XC8sBPjXMSQmOjBrE9R8XgicDXeB
	noB2b41EwohOQ3YNzP9MDhAWiTdMHhietKE8TPPoHLuW30nsQIOe5oBno6LzHrDYhP9r
	gmoA==
X-Gm-Message-State: ALoCoQnlkysJ56tsO6kkIodW4wpk91cfNRf4jiuZ6LVZJO5kMkc7ZlxqMpUqTh9Eaqii7kvKhXEH
X-Received: by 10.194.58.8 with SMTP id m8mr66166283wjq.43.1415194694556;
	Wed, 05 Nov 2014 05:38:14 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id u13sm4631310wiv.10.2014.11.05.05.38.12
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 05:38:13 -0800 (PST)
Message-ID: <545A283E.20202@linaro.org>
Date: Wed, 05 Nov 2014 13:38:06 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] xen/arm: Add support for Huawei
	hip04-d01 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

Hi Frediano,

Thank you for adding support to this board.

Could you provide the instruction to boot Xen on this board?

It might be interesting to add a wiki page with them and link to:

http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions

Regards,

On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details).
> 
> Changes from v2:
> - rewrote DTS fix patch (Ian Campbell);
> - use is_hip04 macro instead of doing explicit test (Julien Grall);
> - do not use quirks to distinguish this platform (Ian Cambell);
> - move some GIC constants to C files instead of header (Julien Grall);
> - minor changes (Julien Grall).
> 
> Changes from v1:
> - style (Julien Grall);
> - make gicv2_send_SGI faster (Julien Grall);
> - cleanup correctly if hip04_smp_init fails (Julien Grall);
> - remove quirks using compatibility (Ian Campbell);
> - other minor suggestions by Julien Grall.
> 
> 
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 13:38:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 13:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm0mv-0002Ie-Ar; Wed, 05 Nov 2014 13:38:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm0mu-0002IZ-1C
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 13:38:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C4/6B-09936-7482A545; Wed, 05 Nov 2014 13:38:15 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415194694!12932126!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14069 invoked from network); 5 Nov 2014 13:38:14 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 13:38:14 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so932655wgg.5
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 05:38:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=C3MPfSFB6vptJplv1uzZrN1vhDu4C2HnYesUvIBhZTo=;
	b=eHO9Bq6MxjRWcB+Qe6fZFZOlEjRb9E7GmPjdiHYDdLvmY9Qxc6nQ8pXjiKfMrjNOoi
	UBAFLHBJ7rUzUPNqFpK4EdPF+0SZ0Xmjabgzp6wH94MZTQNeDv8dqtzoBQdAmnEYQ+Ln
	N+b3hGnY7KO2UTagxqFIb7hIX054MZcJTAhNFws6NSpEa0vP6WNIxngdNITneEaVgRjv
	dGd9pnhzot0cYcwav9DyvGMBmZ4/rQFwf3vSpyD4XC8sBPjXMSQmOjBrE9R8XgicDXeB
	noB2b41EwohOQ3YNzP9MDhAWiTdMHhietKE8TPPoHLuW30nsQIOe5oBno6LzHrDYhP9r
	gmoA==
X-Gm-Message-State: ALoCoQnlkysJ56tsO6kkIodW4wpk91cfNRf4jiuZ6LVZJO5kMkc7ZlxqMpUqTh9Eaqii7kvKhXEH
X-Received: by 10.194.58.8 with SMTP id m8mr66166283wjq.43.1415194694556;
	Wed, 05 Nov 2014 05:38:14 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id u13sm4631310wiv.10.2014.11.05.05.38.12
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 05:38:13 -0800 (PST)
Message-ID: <545A283E.20202@linaro.org>
Date: Wed, 05 Nov 2014 13:38:06 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] xen/arm: Add support for Huawei
	hip04-d01 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

Hi Frediano,

Thank you for adding support to this board.

Could you provide the instruction to boot Xen on this board?

It might be interesting to add a wiki page with them and link to:

http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions

Regards,

On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details).
> 
> Changes from v2:
> - rewrote DTS fix patch (Ian Campbell);
> - use is_hip04 macro instead of doing explicit test (Julien Grall);
> - do not use quirks to distinguish this platform (Ian Cambell);
> - move some GIC constants to C files instead of header (Julien Grall);
> - minor changes (Julien Grall).
> 
> Changes from v1:
> - style (Julien Grall);
> - make gicv2_send_SGI faster (Julien Grall);
> - cleanup correctly if hip04_smp_init fails (Julien Grall);
> - remove quirks using compatibility (Ian Campbell);
> - other minor suggestions by Julien Grall.
> 
> 
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 13:45:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 13:45:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm0ty-0002dr-C7; Wed, 05 Nov 2014 13:45:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1Xm0tw-0002dm-Ow
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 13:45:32 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	E3/14-02954-CF92A545; Wed, 05 Nov 2014 13:45:32 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415195130!12720389!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25189 invoked from network); 5 Nov 2014 13:45:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 13:45:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5DjQH9005394
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 13:45:27 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA5CvErY014535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Nov 2014 12:57:14 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA5CvDxP014480; Wed, 5 Nov 2014 12:57:13 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 05:45:23 -0800
Date: Wed, 5 Nov 2014 14:45:15 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141105134515.GO16923@olila.local.net-space.pl>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
	<CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
	<5458932F0200007800044A4E@mail.emea.novell.com>
	<CAFECyb9Z=YBXhn6xmutp0iV2JNQUbpw3FA=GT4QgSYPwvY9ksw@mail.gmail.com>
	<20141104211745.GK16923@olila.local.net-space.pl>
	<CAFECyb9b6rcHL55iSLfKxqQVxJrWGGf1+JBLwGhJanMRQ=uVvw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFECyb9b6rcHL55iSLfKxqQVxJrWGGf1+JBLwGhJanMRQ=uVvw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <ian.campbell@citrix.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 02:36:06PM -0800, Roy Franz wrote:
> On Tue, Nov 4, 2014 at 1:17 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > On Tue, Nov 04, 2014 at 10:39:53AM -0800, Roy Franz wrote:

[...]

> >> The case of being executed as an EFI application, loaded by GRUB and provided
> >> module information via the multiboot2 (in FDT) protocol is unique to
> >> arm64.  All the code
> >> is common code, but since efi_arch_use_config_file() is always true
> >> for x86 the case
> >> described only applies to arm64.
> >
> > Right now it is true. Probably it will change after introducing
> > multiboot2 protocol on x86.
>
> So you expect to be using the efi_start() function mostly as is?

More or less. I am working on it right now.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 13:45:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 13:45:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm0ty-0002dr-C7; Wed, 05 Nov 2014 13:45:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1Xm0tw-0002dm-Ow
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 13:45:32 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	E3/14-02954-CF92A545; Wed, 05 Nov 2014 13:45:32 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415195130!12720389!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25189 invoked from network); 5 Nov 2014 13:45:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 13:45:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5DjQH9005394
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 13:45:27 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA5CvErY014535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Nov 2014 12:57:14 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA5CvDxP014480; Wed, 5 Nov 2014 12:57:13 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 05:45:23 -0800
Date: Wed, 5 Nov 2014 14:45:15 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141105134515.GO16923@olila.local.net-space.pl>
References: <1414995190-2267-1-git-send-email-roy.franz@linaro.org>
	<545759FB02000078000443F2@mail.emea.novell.com>
	<CAFECyb-12hu6VG=_X5kYVVRe=LYANQudZJMgp3VMksDnctGPRQ@mail.gmail.com>
	<5458932F0200007800044A4E@mail.emea.novell.com>
	<CAFECyb9Z=YBXhn6xmutp0iV2JNQUbpw3FA=GT4QgSYPwvY9ksw@mail.gmail.com>
	<20141104211745.GK16923@olila.local.net-space.pl>
	<CAFECyb9b6rcHL55iSLfKxqQVxJrWGGf1+JBLwGhJanMRQ=uVvw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFECyb9b6rcHL55iSLfKxqQVxJrWGGf1+JBLwGhJanMRQ=uVvw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <ian.campbell@citrix.com>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 02:36:06PM -0800, Roy Franz wrote:
> On Tue, Nov 4, 2014 at 1:17 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > On Tue, Nov 04, 2014 at 10:39:53AM -0800, Roy Franz wrote:

[...]

> >> The case of being executed as an EFI application, loaded by GRUB and provided
> >> module information via the multiboot2 (in FDT) protocol is unique to
> >> arm64.  All the code
> >> is common code, but since efi_arch_use_config_file() is always true
> >> for x86 the case
> >> described only applies to arm64.
> >
> > Right now it is true. Probably it will change after introducing
> > multiboot2 protocol on x86.
>
> So you expect to be using the efi_start() function mostly as is?

More or less. I am working on it right now.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 13:48:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 13:48:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm0wb-0002kU-Ud; Wed, 05 Nov 2014 13:48:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm0wa-0002kK-89
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 13:48:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8F/51-24532-F9A2A545; Wed, 05 Nov 2014 13:48:15 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415195294!13000417!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27594 invoked from network); 5 Nov 2014 13:48:14 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 13:48:14 -0000
Received: by mail-wg0-f49.google.com with SMTP id x13so938173wgg.22
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 05:48:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=ukzRdyF9Zgkd3GmRx74fJJNs+6ibUCKm6ULa5ywfxmA=;
	b=HPySZkztuM/oPm9ns4RJ60KLZ0jJkCrJiEbiJytyO7oykjhQ/wRN09uMJYzaAmX4rH
	lR6+lm9XgZsqbkWeOgprssV7I4btBCCAdVAXnUZMFEHmtrSFK6dgdmI4m5YyaH7DM7+N
	7AoC57OCEXlnmwdnr49UYnA/LG1RNZetjH6Su8wIQcplmNp/GtDuRGXCBN1rjZv8HDi2
	ceIn8HHWUS3z03AMPhl/T6HvieZiX1C7QKuE5aSPrS/YOuvwJPDCmE7/1o+/rPlIHxpi
	miO2bBAyFNjAAVGBslJlJh9S7GCagvTHkJ6NXqQaI6TUIF8nNM7RQMoKT4n1fE4sc9Y7
	ASBA==
X-Gm-Message-State: ALoCoQny9SQNQdoVkCMgCtFFrA1C0eMmxzH5O7Eq4PqCoPwCwxmPFl423WcBfgCHklcibv+7X8nR
X-Received: by 10.180.11.168 with SMTP id r8mr5953164wib.74.1415195294401;
	Wed, 05 Nov 2014 05:48:14 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ws2sm4147158wjc.32.2014.11.05.05.48.12
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 05:48:13 -0800 (PST)
Message-ID: <545A2A96.8060105@linaro.org>
Date: Wed, 05 Nov 2014 13:48:06 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> This name can appear in some Linux kernel repos. Not very fortunate,
> but to avoid others spending an hour to spot that few characters
> difference it worth to work around it.

Linux upstream is using "hisilicon,hip04-intc" to detect the hisilicon
interrupt controller. So it's not a workaround.

Which kernel is using the "*,hip04-gic"?

Regards,

> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c     | 1 +
>  xen/include/asm-arm/gic.h | 4 +++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 3cb59dd..9ab30ce 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -823,6 +823,7 @@ DT_DEVICE_END
>  static const char * const hip04_gicv2_dt_compat[] __initconst =
>  {
>      DT_COMPAT_GIC_HIP04,
> +    DT_COMPAT_GIC_HIP04_2,
>      NULL
>  };
>  
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 5adb628..3d2b3db 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -156,11 +156,13 @@
>  #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
>  #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
>  #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
> +#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
>  
>  #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
>                          DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
>                          DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
> -                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
> +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
> +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
>  
>  #define DT_COMPAT_GIC_V3             "arm,gic-v3"
>  
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 13:48:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 13:48:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm0wb-0002kU-Ud; Wed, 05 Nov 2014 13:48:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm0wa-0002kK-89
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 13:48:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8F/51-24532-F9A2A545; Wed, 05 Nov 2014 13:48:15 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415195294!13000417!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27594 invoked from network); 5 Nov 2014 13:48:14 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 13:48:14 -0000
Received: by mail-wg0-f49.google.com with SMTP id x13so938173wgg.22
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 05:48:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=ukzRdyF9Zgkd3GmRx74fJJNs+6ibUCKm6ULa5ywfxmA=;
	b=HPySZkztuM/oPm9ns4RJ60KLZ0jJkCrJiEbiJytyO7oykjhQ/wRN09uMJYzaAmX4rH
	lR6+lm9XgZsqbkWeOgprssV7I4btBCCAdVAXnUZMFEHmtrSFK6dgdmI4m5YyaH7DM7+N
	7AoC57OCEXlnmwdnr49UYnA/LG1RNZetjH6Su8wIQcplmNp/GtDuRGXCBN1rjZv8HDi2
	ceIn8HHWUS3z03AMPhl/T6HvieZiX1C7QKuE5aSPrS/YOuvwJPDCmE7/1o+/rPlIHxpi
	miO2bBAyFNjAAVGBslJlJh9S7GCagvTHkJ6NXqQaI6TUIF8nNM7RQMoKT4n1fE4sc9Y7
	ASBA==
X-Gm-Message-State: ALoCoQny9SQNQdoVkCMgCtFFrA1C0eMmxzH5O7Eq4PqCoPwCwxmPFl423WcBfgCHklcibv+7X8nR
X-Received: by 10.180.11.168 with SMTP id r8mr5953164wib.74.1415195294401;
	Wed, 05 Nov 2014 05:48:14 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ws2sm4147158wjc.32.2014.11.05.05.48.12
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 05:48:13 -0800 (PST)
Message-ID: <545A2A96.8060105@linaro.org>
Date: Wed, 05 Nov 2014 13:48:06 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> This name can appear in some Linux kernel repos. Not very fortunate,
> but to avoid others spending an hour to spot that few characters
> difference it worth to work around it.

Linux upstream is using "hisilicon,hip04-intc" to detect the hisilicon
interrupt controller. So it's not a workaround.

Which kernel is using the "*,hip04-gic"?

Regards,

> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c     | 1 +
>  xen/include/asm-arm/gic.h | 4 +++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 3cb59dd..9ab30ce 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -823,6 +823,7 @@ DT_DEVICE_END
>  static const char * const hip04_gicv2_dt_compat[] __initconst =
>  {
>      DT_COMPAT_GIC_HIP04,
> +    DT_COMPAT_GIC_HIP04_2,
>      NULL
>  };
>  
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 5adb628..3d2b3db 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -156,11 +156,13 @@
>  #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
>  #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
>  #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
> +#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
>  
>  #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
>                          DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
>                          DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
> -                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
> +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
> +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
>  
>  #define DT_COMPAT_GIC_V3             "arm,gic-v3"
>  
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:09:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:09:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1H8-0003LU-VO; Wed, 05 Nov 2014 14:09:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Xm1H7-0003LP-O0
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:09:29 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	40/4A-09936-99F2A545; Wed, 05 Nov 2014 14:09:29 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415196567!12916641!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5199 invoked from network); 5 Nov 2014 14:09:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 14:09: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 sA5E99F6016744
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 5 Nov 2014 09:09:10 -0500
Received: from redhat.com (ovpn-116-102.ams2.redhat.com [10.36.116.102])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sA5E96uh030792; Wed, 5 Nov 2014 09:09:07 -0500
Date: Wed, 5 Nov 2014 16:09:06 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141105140906.GA4912@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa
 bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
> Currently IGD drivers always need to access PCH by 1f.0, and
> PCH vendor/device id is used to identify the card.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index b559181..b19c7a9 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -50,7 +50,7 @@
>  #include "cpu.h"
>  #include "qemu/error-report.h"
>  #ifdef CONFIG_XEN
> -#  include <xen/hvm/hvm_info_table.h>
> +#include <xen/hvm/hvm_info_table.h>
>  #endif
>  
>  #define MAX_IDE_BUS 2
> @@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
>  }
>  
>  #ifdef CONFIG_XEN
> +static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
> +{
> +    struct PCIDevice *dev;
> +    Error *local_err = NULL;
> +    uint16_t device_id = 0xffff;
> +
> +    /* Currently IGD drivers always need to access PCH by 1f.0. */
> +    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
> +                            "xen-igd-passthrough-isa-bridge");
> +
> +    /* Identify PCH card with its own real vendor/device ids.
> +     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
> +     */
> +    if (dev) {
> +        device_id = object_property_get_int(OBJECT(dev), "device-id",
> +                                            &local_err);
> +        if (!local_err && device_id != 0xffff) {
> +            pci_config_set_device_id(dev->config, device_id);
> +            return;
> +        }
> +    }
> +
> +    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
> +}
> +
>  static void pc_xen_hvm_init(MachineState *machine)
>  {
>      PCIBus *bus;
> @@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
>      bus = pci_find_primary_bus();
>      if (bus != NULL) {
>          pci_create_simple(bus, -1, "xen-platform");
> +        xen_igd_passthrough_isa_bridge_create(bus);
>      }
>  }
>  #endif

Can't we defer this step until the GPU is added?
This way there won't be need to poke at host device
directly, you could get all info from dev->config
of the host device.
Additionally the correct bridge would be initialized automatically.


> -- 
> 1.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:09:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:09:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1H8-0003LU-VO; Wed, 05 Nov 2014 14:09:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Xm1H7-0003LP-O0
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:09:29 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	40/4A-09936-99F2A545; Wed, 05 Nov 2014 14:09:29 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415196567!12916641!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5199 invoked from network); 5 Nov 2014 14:09:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 14:09: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 sA5E99F6016744
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 5 Nov 2014 09:09:10 -0500
Received: from redhat.com (ovpn-116-102.ams2.redhat.com [10.36.116.102])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sA5E96uh030792; Wed, 5 Nov 2014 09:09:07 -0500
Date: Wed, 5 Nov 2014 16:09:06 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141105140906.GA4912@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa
 bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
> Currently IGD drivers always need to access PCH by 1f.0, and
> PCH vendor/device id is used to identify the card.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index b559181..b19c7a9 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -50,7 +50,7 @@
>  #include "cpu.h"
>  #include "qemu/error-report.h"
>  #ifdef CONFIG_XEN
> -#  include <xen/hvm/hvm_info_table.h>
> +#include <xen/hvm/hvm_info_table.h>
>  #endif
>  
>  #define MAX_IDE_BUS 2
> @@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
>  }
>  
>  #ifdef CONFIG_XEN
> +static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
> +{
> +    struct PCIDevice *dev;
> +    Error *local_err = NULL;
> +    uint16_t device_id = 0xffff;
> +
> +    /* Currently IGD drivers always need to access PCH by 1f.0. */
> +    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
> +                            "xen-igd-passthrough-isa-bridge");
> +
> +    /* Identify PCH card with its own real vendor/device ids.
> +     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
> +     */
> +    if (dev) {
> +        device_id = object_property_get_int(OBJECT(dev), "device-id",
> +                                            &local_err);
> +        if (!local_err && device_id != 0xffff) {
> +            pci_config_set_device_id(dev->config, device_id);
> +            return;
> +        }
> +    }
> +
> +    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
> +}
> +
>  static void pc_xen_hvm_init(MachineState *machine)
>  {
>      PCIBus *bus;
> @@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
>      bus = pci_find_primary_bus();
>      if (bus != NULL) {
>          pci_create_simple(bus, -1, "xen-platform");
> +        xen_igd_passthrough_isa_bridge_create(bus);
>      }
>  }
>  #endif

Can't we defer this step until the GPU is added?
This way there won't be need to poke at host device
directly, you could get all info from dev->config
of the host device.
Additionally the correct bridge would be initialized automatically.


> -- 
> 1.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:18:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:18:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1Q0-0003f7-5J; Wed, 05 Nov 2014 14:18:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm1Py-0003f2-KT
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:18:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	28/7F-24532-EB13A545; Wed, 05 Nov 2014 14:18:38 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415197115!12959020!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14321 invoked from network); 5 Nov 2014 14:18:35 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 14:18:35 -0000
Received: by mail-wi0-f176.google.com with SMTP id h11so12528044wiw.15
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 06:18:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=JmmERgwmOg7FvnRAxMCMP9vCAyMIE+0GpThrygd75Rs=;
	b=fdHNDCBv+wzCwUoyN27YUzTF5b4mjdhWOtlLNv+UGgONEKFKJYdqIvIftQURz/cAnj
	EcDAxL/Vdq6+PVL8OdUj+UGPKl2MO6s0jy6Pu7C01GAsY4pJ46MiAS2fSrDFlBMD65DB
	lYdP+ZeGbOkvse9cZvf/3M/Au4qpFIrF2qqhJfoltlHbf+Ops5JOWQQOgJa6uGbZBHZB
	J2UXJxcK4jKpVWe+6IzgDg9OJ7OF0hC4wlwcrlaG/GsanTJCtI9l6GOeknwApm+TZFe9
	vBfTmPN+T5vPRqyHrh3hLCfkKXB+pzOvRZRv/bin72IRAzv8l70MxtvyBTSADbThSjSO
	4idA==
X-Gm-Message-State: ALoCoQmodOHpBmWCxdhOGZzJUT92X4kBHlwm5l6NQz+j2zDlhZX9U1ZxmIwSzyyk9OgjLxCgKBTQ
X-Received: by 10.194.58.205 with SMTP id t13mr63426703wjq.55.1415197115488;
	Wed, 05 Nov 2014 06:18:35 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	bc1sm15247848wib.16.2014.11.05.06.18.34 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 06:18:34 -0800 (PST)
Message-ID: <545A31B4.6040901@linaro.org>
Date: Wed, 05 Nov 2014 14:18:28 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-8-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415180475-8339-8-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 7/8] xen/device_tree: Add
	dt_device_get_address_raw
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

I will made a global comment here for patch #7 and #8.

On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> Allow to read untranslated address from device node.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> ---
>  xen/common/device_tree.c      | 34 ++++++++++++++++++++++++++++++++++
>  xen/include/xen/device_tree.h | 11 +++++++++++
>  2 files changed, 45 insertions(+)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 1a886c0..4186a24 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -711,6 +711,40 @@ int dt_device_get_address(const struct dt_device_node *dev, int index,
>      return 0;
>  }
>  
> +/* dt_device_get_address_raw - Returns address not translated */
> +int dt_device_get_address_raw(const struct dt_device_node *dev, int index,
> +                          u64 *addr)

This is wrong to assume that the untranslated address will fit in a 64
bits value.

Technically an untranslated address could be encoded on up to 4 cells
(though it has been hardcoded).

In any case, I don't think this is the right solution to the problem. As
DOM0 will always have the same layout as the hardware for the GIC, we
should copy "regs" and strip the unecessary regions (such as the GICH
and GICV).

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:18:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:18:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1Q0-0003f7-5J; Wed, 05 Nov 2014 14:18:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm1Py-0003f2-KT
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:18:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	28/7F-24532-EB13A545; Wed, 05 Nov 2014 14:18:38 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415197115!12959020!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14321 invoked from network); 5 Nov 2014 14:18:35 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 14:18:35 -0000
Received: by mail-wi0-f176.google.com with SMTP id h11so12528044wiw.15
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 06:18:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=JmmERgwmOg7FvnRAxMCMP9vCAyMIE+0GpThrygd75Rs=;
	b=fdHNDCBv+wzCwUoyN27YUzTF5b4mjdhWOtlLNv+UGgONEKFKJYdqIvIftQURz/cAnj
	EcDAxL/Vdq6+PVL8OdUj+UGPKl2MO6s0jy6Pu7C01GAsY4pJ46MiAS2fSrDFlBMD65DB
	lYdP+ZeGbOkvse9cZvf/3M/Au4qpFIrF2qqhJfoltlHbf+Ops5JOWQQOgJa6uGbZBHZB
	J2UXJxcK4jKpVWe+6IzgDg9OJ7OF0hC4wlwcrlaG/GsanTJCtI9l6GOeknwApm+TZFe9
	vBfTmPN+T5vPRqyHrh3hLCfkKXB+pzOvRZRv/bin72IRAzv8l70MxtvyBTSADbThSjSO
	4idA==
X-Gm-Message-State: ALoCoQmodOHpBmWCxdhOGZzJUT92X4kBHlwm5l6NQz+j2zDlhZX9U1ZxmIwSzyyk9OgjLxCgKBTQ
X-Received: by 10.194.58.205 with SMTP id t13mr63426703wjq.55.1415197115488;
	Wed, 05 Nov 2014 06:18:35 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	bc1sm15247848wib.16.2014.11.05.06.18.34 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 06:18:34 -0800 (PST)
Message-ID: <545A31B4.6040901@linaro.org>
Date: Wed, 05 Nov 2014 14:18:28 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-8-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415180475-8339-8-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 7/8] xen/device_tree: Add
	dt_device_get_address_raw
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

I will made a global comment here for patch #7 and #8.

On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> Allow to read untranslated address from device node.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> ---
>  xen/common/device_tree.c      | 34 ++++++++++++++++++++++++++++++++++
>  xen/include/xen/device_tree.h | 11 +++++++++++
>  2 files changed, 45 insertions(+)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 1a886c0..4186a24 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -711,6 +711,40 @@ int dt_device_get_address(const struct dt_device_node *dev, int index,
>      return 0;
>  }
>  
> +/* dt_device_get_address_raw - Returns address not translated */
> +int dt_device_get_address_raw(const struct dt_device_node *dev, int index,
> +                          u64 *addr)

This is wrong to assume that the untranslated address will fit in a 64
bits value.

Technically an untranslated address could be encoded on up to 4 cells
(though it has been hardcoded).

In any case, I don't think this is the right solution to the problem. As
DOM0 will always have the same layout as the hardware for the GIC, we
should copy "regs" and strip the unecessary regions (such as the GICH
and GICV).

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:18:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1QH-0003gs-Hf; Wed, 05 Nov 2014 14:18:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm1QG-0003gh-Gk
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:18:56 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	BC/BC-24124-FC13A545; Wed, 05 Nov 2014 14:18:55 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415197135!11417285!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32153 invoked from network); 5 Nov 2014 14:18:55 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 14:18:55 -0000
Received: by mail-wi0-f178.google.com with SMTP id bs8so153896wib.5
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 06:18:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=nO7TNe8Ylx049n3E2d+/Bsl4sJUxVk1CDEonBZUE7KQ=;
	b=j63PEGnEx4NNtR26tTAfZcvT2x90b2dyQnG7XMgox3ePqtqlKXcv4bMb1FUQSJDHJU
	Wv4jQnoce6UFITHjbK7uIqSWu0TmUkgoGtT6be4dC7g8UYV5hmfKzYDkm2Iu7Z7mEmzG
	CH+W6Jr7uY0y5s7wJz2naRxmllBbEcqqbR8YCBAdGb+v5+dpjGvRLZKYmQRno/obit8A
	FsaW1G7e7JEckHLbrF7gjGYXptqOopFIge/4ERht+bU6mLM6tMh/8sY5YgDLpHLpC69+
	OyEbyyPVzt6VwBG7ue5S5AZdUa95LfyvgKPzoCLnUcaXQi+ue59xf5XEfXnEKRbll7DM
	hQkg==
X-Gm-Message-State: ALoCoQk25vMp3e1+r9Tlk86sxYvu1mG8YEH6/qQOmrT/iqDdL6bxZhM9gjynQKcX8rz9zARTyPTY
X-Received: by 10.194.71.6 with SMTP id q6mr26572976wju.98.1415197135187;
	Wed, 05 Nov 2014 06:18:55 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fx2sm4230007wjb.37.2014.11.05.06.18.53
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 06:18:54 -0800 (PST)
Message-ID: <545A31C7.3070202@linaro.org>
Date: Wed, 05 Nov 2014 14:18:47 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> Translated address could have an offset applied to them.
> Replicate same value for device node to avoid improper address
> computation in the OS.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c | 23 +++++++++++++++++++++--
>  1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 2f6bbd5..271074d 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -67,8 +67,10 @@
>  /* Global state */
>  static struct {
>      paddr_t dbase;            /* Address of distributor registers */
> +    paddr_t dbase_raw;        /* Untranslated address of distributor registers */
>      void __iomem * map_dbase; /* IO mapped Address of distributor registers */
>      paddr_t cbase;            /* Address of CPU interface registers */
> +    paddr_t cbase_raw;        /* Untranslated address of CPU interface registers */
>      void __iomem * map_cbase[2]; /* IO mapped Address of CPU interface registers */
>      paddr_t hbase;            /* Address of virtual interface registers */
>      void __iomem * map_hbase; /* IO Address of virtual interface registers */
> @@ -671,8 +673,17 @@ static int gicv2_make_dt_node(const struct domain *d,
>          return -FDT_ERR_XEN(ENOMEM);
>  
>      tmp = new_cells;
> -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> +
> +    if ( is_hardware_domain(d) )
> +    {

This check is pointless, as said on an earlier version of this series,
gicv2_make_dt_node is only used to create DOM0 (hardware domain) device
tree.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:18:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1QH-0003gs-Hf; Wed, 05 Nov 2014 14:18:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm1QG-0003gh-Gk
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:18:56 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	BC/BC-24124-FC13A545; Wed, 05 Nov 2014 14:18:55 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415197135!11417285!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32153 invoked from network); 5 Nov 2014 14:18:55 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 14:18:55 -0000
Received: by mail-wi0-f178.google.com with SMTP id bs8so153896wib.5
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 06:18:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=nO7TNe8Ylx049n3E2d+/Bsl4sJUxVk1CDEonBZUE7KQ=;
	b=j63PEGnEx4NNtR26tTAfZcvT2x90b2dyQnG7XMgox3ePqtqlKXcv4bMb1FUQSJDHJU
	Wv4jQnoce6UFITHjbK7uIqSWu0TmUkgoGtT6be4dC7g8UYV5hmfKzYDkm2Iu7Z7mEmzG
	CH+W6Jr7uY0y5s7wJz2naRxmllBbEcqqbR8YCBAdGb+v5+dpjGvRLZKYmQRno/obit8A
	FsaW1G7e7JEckHLbrF7gjGYXptqOopFIge/4ERht+bU6mLM6tMh/8sY5YgDLpHLpC69+
	OyEbyyPVzt6VwBG7ue5S5AZdUa95LfyvgKPzoCLnUcaXQi+ue59xf5XEfXnEKRbll7DM
	hQkg==
X-Gm-Message-State: ALoCoQk25vMp3e1+r9Tlk86sxYvu1mG8YEH6/qQOmrT/iqDdL6bxZhM9gjynQKcX8rz9zARTyPTY
X-Received: by 10.194.71.6 with SMTP id q6mr26572976wju.98.1415197135187;
	Wed, 05 Nov 2014 06:18:55 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fx2sm4230007wjb.37.2014.11.05.06.18.53
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 06:18:54 -0800 (PST)
Message-ID: <545A31C7.3070202@linaro.org>
Date: Wed, 05 Nov 2014 14:18:47 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
In-Reply-To: <1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Frediano,

On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> Translated address could have an offset applied to them.
> Replicate same value for device node to avoid improper address
> computation in the OS.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> ---
>  xen/arch/arm/gic-v2.c | 23 +++++++++++++++++++++--
>  1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 2f6bbd5..271074d 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -67,8 +67,10 @@
>  /* Global state */
>  static struct {
>      paddr_t dbase;            /* Address of distributor registers */
> +    paddr_t dbase_raw;        /* Untranslated address of distributor registers */
>      void __iomem * map_dbase; /* IO mapped Address of distributor registers */
>      paddr_t cbase;            /* Address of CPU interface registers */
> +    paddr_t cbase_raw;        /* Untranslated address of CPU interface registers */
>      void __iomem * map_cbase[2]; /* IO mapped Address of CPU interface registers */
>      paddr_t hbase;            /* Address of virtual interface registers */
>      void __iomem * map_hbase; /* IO Address of virtual interface registers */
> @@ -671,8 +673,17 @@ static int gicv2_make_dt_node(const struct domain *d,
>          return -FDT_ERR_XEN(ENOMEM);
>  
>      tmp = new_cells;
> -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> +
> +    if ( is_hardware_domain(d) )
> +    {

This check is pointless, as said on an earlier version of this series,
gicv2_make_dt_node is only used to create DOM0 (hardware domain) device
tree.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:30:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:30:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1bW-00046Y-NY; Wed, 05 Nov 2014 14:30:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1Xm1bV-00046T-AV
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:30:33 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	FE/26-14727-8843A545; Wed, 05 Nov 2014 14:30:32 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415197830!11386120!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4411 invoked from network); 5 Nov 2014 14:30:31 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Nov 2014 14:30:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5EUP1n001956
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 14:30:26 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA5DgDA4014099
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 5 Nov 2014 13:42:14 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5EUNtI019500; Wed, 5 Nov 2014 14:30:23 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 06:30:23 -0800
Date: Wed, 5 Nov 2014 15:30:18 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141105143018.GQ16923@olila.local.net-space.pl>
References: <20141029124411.GA3467@olila.local.net-space.pl>
	<1414596400.29580.12.camel@citrix.com>
	<20141029165526.GB3467@olila.local.net-space.pl>
	<CAFECyb_Q34S=L2Sy+PvLMBkZnct7z5y-u_c0Naush3oa2qnpng@mail.gmail.com>
	<20141030175714.GF3467@olila.local.net-space.pl>
	<CAFECyb--vAVRMvHVNZKb39WSaKDO16JbkHQBi-HbL-LLx5VUoA@mail.gmail.com>
	<20141030221857.GA16923@olila.local.net-space.pl>
	<CAFECyb8cJvkrjgUcu1-mr_xBJPZOxKdrEnJ4ekD78gEK0a=5iA@mail.gmail.com>
	<20141104214952.GL16923@olila.local.net-space.pl>
	<CAFECyb_NHc9bnG1BFasL-3Gk5A10iHEdN0HTE-8SJan=o=mp6A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFECyb_NHc9bnG1BFasL-3Gk5A10iHEdN0HTE-8SJan=o=mp6A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>, tim <tim@xen.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH V2 for-4.5] EFI: Always use EFI command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 02:48:59PM -0800, Roy Franz wrote:
> On Tue, Nov 4, 2014 at 1:49 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > On Thu, Oct 30, 2014 at 04:54:17PM -0700, Roy Franz wrote:

[...]

> >> The current implementation is to examine the FDT passed to Xen to see
> >> if it contains any modules.  If it does, then this indicates to the
> >> EFI boot code
> >> that it is being run by a bootloader, and not directly from the EFI bootmanager
> >> or shell.
> >
> > I think that it is wrong. I am able to imagine such situation in which
> > only small binary is loaded to do something specific and this binary
> > does not require any modules. If we do what you suggest then we must
> > load an additional module which will not be used by binary itself but
> > it just signals that binary was loaded by multiboot protocol. Not nice.
> > That is why I am still thinking that multiboot protocol aware loader
> > should put a flag in FDT telling that binary was loaded that way.
> >
> > I am aware that Xen have to have at least one module (kernel image for dom0)
> > but I think that new protocol should be generic as much as possible and
> > Xen should not be its only one user.
>
> I think that what is being done for Xen is robust for Xen, and likely will be
> for others as well.  The FDT-multiboot bindings are just a way to pass extra
> module information to an application - if there are no "multiboot,module" compatible nodes,
> then the FDT-multiboot bindings are not in use.  Multiboot2 seems to imply much more

OK, however, lack of "multiboot,module" does not mean that image was not
loaded by multiboot aware loader on ARM64 platform. As I can see there
are also other valid FDT multiboot strings in spec, e.g. "multiboot,kernel".
They could not be used by Xen itself but it does not change anything in
boot protocol. Hence, I think that it is much easier to look for one string
or magic value which has meaning "loaded by multiboot aware loader" than
test all possible values to be sure that image was not loaded by "multiboot
aware loader".

> than that - I need to investigate that a bit more so I understand how
> this is done on x86.

multiboot2 aware loader on x86 puts special magic value in %eax to
mark that image should expect multiboot2 as a boot protocol. Early
x86 code looks for this value and do all things accordingly.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:30:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:30:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1bW-00046Y-NY; Wed, 05 Nov 2014 14:30:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1Xm1bV-00046T-AV
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:30:33 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	FE/26-14727-8843A545; Wed, 05 Nov 2014 14:30:32 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415197830!11386120!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4411 invoked from network); 5 Nov 2014 14:30:31 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Nov 2014 14:30:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5EUP1n001956
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 14:30:26 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA5DgDA4014099
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 5 Nov 2014 13:42:14 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5EUNtI019500; Wed, 5 Nov 2014 14:30:23 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 06:30:23 -0800
Date: Wed, 5 Nov 2014 15:30:18 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Roy Franz <roy.franz@linaro.org>
Message-ID: <20141105143018.GQ16923@olila.local.net-space.pl>
References: <20141029124411.GA3467@olila.local.net-space.pl>
	<1414596400.29580.12.camel@citrix.com>
	<20141029165526.GB3467@olila.local.net-space.pl>
	<CAFECyb_Q34S=L2Sy+PvLMBkZnct7z5y-u_c0Naush3oa2qnpng@mail.gmail.com>
	<20141030175714.GF3467@olila.local.net-space.pl>
	<CAFECyb--vAVRMvHVNZKb39WSaKDO16JbkHQBi-HbL-LLx5VUoA@mail.gmail.com>
	<20141030221857.GA16923@olila.local.net-space.pl>
	<CAFECyb8cJvkrjgUcu1-mr_xBJPZOxKdrEnJ4ekD78gEK0a=5iA@mail.gmail.com>
	<20141104214952.GL16923@olila.local.net-space.pl>
	<CAFECyb_NHc9bnG1BFasL-3Gk5A10iHEdN0HTE-8SJan=o=mp6A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFECyb_NHc9bnG1BFasL-3Gk5A10iHEdN0HTE-8SJan=o=mp6A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>, tim <tim@xen.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH V2 for-4.5] EFI: Always use EFI command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 04, 2014 at 02:48:59PM -0800, Roy Franz wrote:
> On Tue, Nov 4, 2014 at 1:49 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > On Thu, Oct 30, 2014 at 04:54:17PM -0700, Roy Franz wrote:

[...]

> >> The current implementation is to examine the FDT passed to Xen to see
> >> if it contains any modules.  If it does, then this indicates to the
> >> EFI boot code
> >> that it is being run by a bootloader, and not directly from the EFI bootmanager
> >> or shell.
> >
> > I think that it is wrong. I am able to imagine such situation in which
> > only small binary is loaded to do something specific and this binary
> > does not require any modules. If we do what you suggest then we must
> > load an additional module which will not be used by binary itself but
> > it just signals that binary was loaded by multiboot protocol. Not nice.
> > That is why I am still thinking that multiboot protocol aware loader
> > should put a flag in FDT telling that binary was loaded that way.
> >
> > I am aware that Xen have to have at least one module (kernel image for dom0)
> > but I think that new protocol should be generic as much as possible and
> > Xen should not be its only one user.
>
> I think that what is being done for Xen is robust for Xen, and likely will be
> for others as well.  The FDT-multiboot bindings are just a way to pass extra
> module information to an application - if there are no "multiboot,module" compatible nodes,
> then the FDT-multiboot bindings are not in use.  Multiboot2 seems to imply much more

OK, however, lack of "multiboot,module" does not mean that image was not
loaded by multiboot aware loader on ARM64 platform. As I can see there
are also other valid FDT multiboot strings in spec, e.g. "multiboot,kernel".
They could not be used by Xen itself but it does not change anything in
boot protocol. Hence, I think that it is much easier to look for one string
or magic value which has meaning "loaded by multiboot aware loader" than
test all possible values to be sure that image was not loaded by "multiboot
aware loader".

> than that - I need to investigate that a bit more so I understand how
> this is done on x86.

multiboot2 aware loader on x86 puts special magic value in %eax to
mark that image should expect multiboot2 as a boot protocol. Early
x86 code looks for this value and do all things accordingly.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:44:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1oX-0004cj-Ec; Wed, 05 Nov 2014 14:44:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm1oW-0004ce-8J
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:44:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DC/E3-09842-FA73A545; Wed, 05 Nov 2014 14:43:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415198637!9548560!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15259 invoked from network); 5 Nov 2014 14:43:59 -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;
	5 Nov 2014 14:43:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="188337664"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:43:56 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0001Pg-6p;
	Wed, 05 Nov 2014 14:43:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm1oR-0007ni-Sn;
	Wed, 05 Nov 2014 14:43:55 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 5 Nov 2014 14:43:46 +0000
Message-ID: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [RFC PATCH 0/4] libxl: CODING_STYLE 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

The structural considerations, error handling patterns, and so on,
have remained undocumented.  This has been a problem during recent
code submissions and reviews.

In this series I have attempted to document current best practice.
The first patch contains much new material and the others are minor
and consequential fixes.

 1/4 libxl: CODING_STYLE: Much new material
 2/4 libxl: CODING_STYLE: Deprecate `error' for out blocks
 3/4 libxl: CODING_STYLE: Mention function out parameters
 4/4 libxl: CODING_STYLE: Discuss existing style problems

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 Nov 05 14:44:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1oX-0004cj-Ec; Wed, 05 Nov 2014 14:44:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm1oW-0004ce-8J
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:44:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DC/E3-09842-FA73A545; Wed, 05 Nov 2014 14:43:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415198637!9548560!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15259 invoked from network); 5 Nov 2014 14:43:59 -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;
	5 Nov 2014 14:43:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="188337664"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:43:56 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0001Pg-6p;
	Wed, 05 Nov 2014 14:43:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm1oR-0007ni-Sn;
	Wed, 05 Nov 2014 14:43:55 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 5 Nov 2014 14:43:46 +0000
Message-ID: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [RFC PATCH 0/4] libxl: CODING_STYLE 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

The structural considerations, error handling patterns, and so on,
have remained undocumented.  This has been a problem during recent
code submissions and reviews.

In this series I have attempted to document current best practice.
The first patch contains much new material and the others are minor
and consequential fixes.

 1/4 libxl: CODING_STYLE: Much new material
 2/4 libxl: CODING_STYLE: Deprecate `error' for out blocks
 3/4 libxl: CODING_STYLE: Mention function out parameters
 4/4 libxl: CODING_STYLE: Discuss existing style problems

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 Nov 05 14:44:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:44:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1oi-0004dd-6M; Wed, 05 Nov 2014 14:44:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm1oh-0004dD-8M
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:44:11 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	31/D7-02702-AB73A545; Wed, 05 Nov 2014 14:44:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415198643!12736683!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29996 invoked from network); 5 Nov 2014 14:44:08 -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;
	5 Nov 2014 14:44:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="189738997"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:44:01 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0001Pm-MH;
	Wed, 05 Nov 2014 14:43:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0007nq-ES;
	Wed, 05 Nov 2014 14:43:56 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 5 Nov 2014 14:43:48 +0000
Message-ID: <1415198630-29937-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2/4] libxl: CODING_STYLE: Deprecate `error' for
	out blocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 should have only one name for this and `out' is more prevalent.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 3e72852..8dcc22b 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -239,7 +239,7 @@ variable that is used to hold a temporary value.
 
 Local variables used to store return values should have descriptive name
 like "rc" or "ret". Following the same reasoning the label used as exit
-path should be called "out" or "error".
+path should be called "out".
 
 Variables, type names and function names are
 lower_case_with_underscores.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:44:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:44:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1oi-0004dd-6M; Wed, 05 Nov 2014 14:44:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm1oh-0004dD-8M
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:44:11 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	31/D7-02702-AB73A545; Wed, 05 Nov 2014 14:44:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415198643!12736683!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29996 invoked from network); 5 Nov 2014 14:44:08 -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;
	5 Nov 2014 14:44:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="189738997"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:44:01 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0001Pm-MH;
	Wed, 05 Nov 2014 14:43:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0007nq-ES;
	Wed, 05 Nov 2014 14:43:56 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 5 Nov 2014 14:43:48 +0000
Message-ID: <1415198630-29937-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2/4] libxl: CODING_STYLE: Deprecate `error' for
	out blocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 should have only one name for this and `out' is more prevalent.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 3e72852..8dcc22b 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -239,7 +239,7 @@ variable that is used to hold a temporary value.
 
 Local variables used to store return values should have descriptive name
 like "rc" or "ret". Following the same reasoning the label used as exit
-path should be called "out" or "error".
+path should be called "out".
 
 Variables, type names and function names are
 lower_case_with_underscores.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:44:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1oj-0004eW-Ic; Wed, 05 Nov 2014 14:44:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm1oi-0004dZ-23
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:44:12 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	88/93-02696-BB73A545; Wed, 05 Nov 2014 14:44:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415198643!12736683!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30593 invoked from network); 5 Nov 2014 14:44:10 -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;
	5 Nov 2014 14:44:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="189738998"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:44:01 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0001Pj-FJ;
	Wed, 05 Nov 2014 14:43:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0007nl-6D;
	Wed, 05 Nov 2014 14:43:56 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 5 Nov 2014 14:43:47 +0000
Message-ID: <1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1/4] libxl: CODING_STYLE: Much new material
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Discuss:

    Memory allocation
    Conventional variable names
    Convenience macros
    Error handling
    Idempotent data structure construction/destruction
    Asynchronous/long-running operations

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |  169 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 168 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 110a48f..3e72852 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -1,6 +1,173 @@
-Libxenlight Coding Style
+LIBXENLIGHT CODING STYLE
 ========================
 
+
+MEMORY ALLOCATION
+-----------------
+
+Memory allocation for libxl-internal purposes should normally be done
+with the provided gc mechanisms; there is then no need to free.  See
+"libxl memory management" in libxl.h.
+
+
+CONVENTIONAL VARIABLE NAMES
+---------------------------
+
+The following local variable names should be used where applicable:
+
+  int rc;    /* a libxl error code - and not anything else */
+  int r;     /* the return value from a system call (or libxc call) */
+
+  uint32_t domid;
+  libxl__gc *gc;
+  libxl__egc *egc;
+  libxl__ao *ao;
+
+  libxl_foo_bar_state *fbs;    /* local variable */
+  libxl_foo_bar_state foo_bar; /* inside another state struct */
+
+
+CONVENIENCE MACROS
+------------------
+
+There are a number of convenience macros which shorten the program and
+avoid opportunity for mistakes.  In some cases non-use of the macros
+produces functional bugs or incorrect error handling.  Use the macros
+whenever they are applicable.  For example:
+
+ Usually, don't use:     Instead, use (see libxl_internal.h):
+  libxl__log[v]           LOG, LOGE, LOGEV
+  libxl__sprintf          GCSPRINTF
+  libxl__*alloc et al.    GCNEW, GCNEW_ARRAY, GCREALLOC_ARRAY
+  malloc et al.           GCNEW, GCNEW_ARRAY, GCREALLOC_ARRAY with NOGC
+  isalnum etc. directly   CTYPE
+  libxl__ctx_[un]lock     CTX_LOCK, CTX_UNLOCK
+  gc=...; ao=...;         EGC_GC, AO_GC, STATE_AO_GC
+  explicit gc creation    GC_INIT, GC_FREE
+
+
+ERROR HANDLING
+--------------
+
+Unless, there are good reasons to do otherwise, the following error
+handling and cleanup paradigm should be used:
+
+  * All local variables referring to resources which might need
+    cleaning up are declared at the top of the function, and
+    initialised to a sentinel value indicating "nothing allocated".
+    For example,
+            libxl_evgen_disk_eject *evg = NULL;
+            int nullfd = -1;
+
+  * If the function is to return a libxl error value, `rc' is
+    used to contain the error codem, but it is NOT initialised:
+            int rc;
+
+  * There is only one error cleanup path out of the function.  It
+    starts with a label `out:'.  That error cleanup path checks for
+    each allocated resource and frees it iff necessary.  It then
+    returns rc.  For example,
+         out:
+             if (evg) libxl__evdisable_disk_eject(gc, evg);
+             if (nullfd >= 0) close(nullfd);
+             return rc;
+
+  * Function calls which might fail (ie most function calls) are
+    handled by putting the return/status value into a variable, and
+    then checking it in a separate statement:
+            evg->vdev = strdup(vdev);
+            if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
+
+  * If a resource is freed in the main body of the function (for
+    example, in a loop), the corresponding variable has to be reset to
+    the sentinel at the point where it's freed.
+
+Whether to use the `out' path for successful returns as well as error
+returns is a matter of taste and convenience for the specific
+function.  Not reusing the out path is fine if the duplicated function
+exit code is only `CTX_UNLOCK; GC_FREE;' (or similar).
+
+If you reuse the `out' path for successful returns, there may be
+resources which are to be returned to the caller rather than freed.
+In that case you have to reset the local variable to `nothing here',
+to avoid the resource being freed on the out path.  That resetting
+should be done immediately after the resource value is stored at the
+applicable _r function parameter (or equivalent).  Do not test `rc' in
+the out section, to discover whether to free things.
+
+The uses of the single-line formatting in the examples above are
+permitted exceptions to the usual libxl code formatting rules.
+
+
+
+IDEMPOTENT DATA STRUCTURE CONSTRUCTION/DESTRUCTION
+--------------------------------------------------
+
+Nontrivial data structures (in structs) should come with an idempotent
+_destroy function, which must free all resources associated with the
+data structure (but not free the struct itself).
+
+Such a struct should also come with an _init function which
+initialises the struct so that _destroy is a no-op.
+
+
+ASYNCHRONOUS/LONG-RUNNING OPERATIONS
+------------------------------------
+
+All long-running operations in libxl need to use the asynchronous
+operation machinery.  Consult the programmer documentation in
+libxl_internal.h for details - search for "Machinery for asynchronous
+operations".
+
+The code for asynchronous operations should be laid out in
+chronological order.  That is, where there is a chain of callback
+functions, each subsequent function should be, textually, the next
+function in the file.  This will normally involve predeclaring the
+callback functions.  Synchronous helper functions should be separated
+out into a section preceding the main callback chain.
+
+Control flow arrangements in asynchronous operations should be made as
+simple as possible, because it can otherwise be very hard to see
+through the tangle.
+
+
+When inventing a new sub-operation in asynchronous code, consider
+whether to structure it formally as a sub-operation with its own state
+structure.  (See, for example, libxl__datacopier_*.)
+
+An ao-suboperation state structure should contain, in this order:
+  * fields that the caller must fill in, and which are,
+    effectively, the parameters to the operation, including:
+      - libxl__ao *ao
+      - the callback function pointer(s), which
+        should be named callback or callback_*.
+  * shared information fields or ones used for returning information
+    to the calling operation
+  * private fields
+These sections should be clearly demarcated by comments.
+
+An asynchronous operation should normally have an idempotent stop or
+cancel function.  It should normally also have an _init function for
+its state struct, which arranges that the stop is a no-op.
+
+The permitted order of calls into your ao operation's methods must be
+documented in comments, if it is nontrivial.
+
+
+When using an ao sub-operation, you should normally:
+ * Physically include the sub-operation state struct in your
+   own state struct;
+ * Use CONTAINER_OF to find your own state struct at the start of
+   your implementations of the sub-operation callback functions;
+ * Unconditionally initialise the sub-operation's struct (with its
+   _init method) in your own _init method.
+ * Unconditionally cancel or destroy the sub-operation in your own
+   cancel or destroy method.
+
+
+FORMATTING AND NAMING
+---------------------
+
 Blatantly copied from qemu and linux with few modifications.
 
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:44:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1oj-0004eW-Ic; Wed, 05 Nov 2014 14:44:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm1oi-0004dZ-23
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:44:12 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	88/93-02696-BB73A545; Wed, 05 Nov 2014 14:44:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415198643!12736683!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30593 invoked from network); 5 Nov 2014 14:44:10 -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;
	5 Nov 2014 14:44:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="189738998"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:44:01 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0001Pj-FJ;
	Wed, 05 Nov 2014 14:43:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0007nl-6D;
	Wed, 05 Nov 2014 14:43:56 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 5 Nov 2014 14:43:47 +0000
Message-ID: <1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1/4] libxl: CODING_STYLE: Much new material
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Discuss:

    Memory allocation
    Conventional variable names
    Convenience macros
    Error handling
    Idempotent data structure construction/destruction
    Asynchronous/long-running operations

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |  169 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 168 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 110a48f..3e72852 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -1,6 +1,173 @@
-Libxenlight Coding Style
+LIBXENLIGHT CODING STYLE
 ========================
 
+
+MEMORY ALLOCATION
+-----------------
+
+Memory allocation for libxl-internal purposes should normally be done
+with the provided gc mechanisms; there is then no need to free.  See
+"libxl memory management" in libxl.h.
+
+
+CONVENTIONAL VARIABLE NAMES
+---------------------------
+
+The following local variable names should be used where applicable:
+
+  int rc;    /* a libxl error code - and not anything else */
+  int r;     /* the return value from a system call (or libxc call) */
+
+  uint32_t domid;
+  libxl__gc *gc;
+  libxl__egc *egc;
+  libxl__ao *ao;
+
+  libxl_foo_bar_state *fbs;    /* local variable */
+  libxl_foo_bar_state foo_bar; /* inside another state struct */
+
+
+CONVENIENCE MACROS
+------------------
+
+There are a number of convenience macros which shorten the program and
+avoid opportunity for mistakes.  In some cases non-use of the macros
+produces functional bugs or incorrect error handling.  Use the macros
+whenever they are applicable.  For example:
+
+ Usually, don't use:     Instead, use (see libxl_internal.h):
+  libxl__log[v]           LOG, LOGE, LOGEV
+  libxl__sprintf          GCSPRINTF
+  libxl__*alloc et al.    GCNEW, GCNEW_ARRAY, GCREALLOC_ARRAY
+  malloc et al.           GCNEW, GCNEW_ARRAY, GCREALLOC_ARRAY with NOGC
+  isalnum etc. directly   CTYPE
+  libxl__ctx_[un]lock     CTX_LOCK, CTX_UNLOCK
+  gc=...; ao=...;         EGC_GC, AO_GC, STATE_AO_GC
+  explicit gc creation    GC_INIT, GC_FREE
+
+
+ERROR HANDLING
+--------------
+
+Unless, there are good reasons to do otherwise, the following error
+handling and cleanup paradigm should be used:
+
+  * All local variables referring to resources which might need
+    cleaning up are declared at the top of the function, and
+    initialised to a sentinel value indicating "nothing allocated".
+    For example,
+            libxl_evgen_disk_eject *evg = NULL;
+            int nullfd = -1;
+
+  * If the function is to return a libxl error value, `rc' is
+    used to contain the error codem, but it is NOT initialised:
+            int rc;
+
+  * There is only one error cleanup path out of the function.  It
+    starts with a label `out:'.  That error cleanup path checks for
+    each allocated resource and frees it iff necessary.  It then
+    returns rc.  For example,
+         out:
+             if (evg) libxl__evdisable_disk_eject(gc, evg);
+             if (nullfd >= 0) close(nullfd);
+             return rc;
+
+  * Function calls which might fail (ie most function calls) are
+    handled by putting the return/status value into a variable, and
+    then checking it in a separate statement:
+            evg->vdev = strdup(vdev);
+            if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
+
+  * If a resource is freed in the main body of the function (for
+    example, in a loop), the corresponding variable has to be reset to
+    the sentinel at the point where it's freed.
+
+Whether to use the `out' path for successful returns as well as error
+returns is a matter of taste and convenience for the specific
+function.  Not reusing the out path is fine if the duplicated function
+exit code is only `CTX_UNLOCK; GC_FREE;' (or similar).
+
+If you reuse the `out' path for successful returns, there may be
+resources which are to be returned to the caller rather than freed.
+In that case you have to reset the local variable to `nothing here',
+to avoid the resource being freed on the out path.  That resetting
+should be done immediately after the resource value is stored at the
+applicable _r function parameter (or equivalent).  Do not test `rc' in
+the out section, to discover whether to free things.
+
+The uses of the single-line formatting in the examples above are
+permitted exceptions to the usual libxl code formatting rules.
+
+
+
+IDEMPOTENT DATA STRUCTURE CONSTRUCTION/DESTRUCTION
+--------------------------------------------------
+
+Nontrivial data structures (in structs) should come with an idempotent
+_destroy function, which must free all resources associated with the
+data structure (but not free the struct itself).
+
+Such a struct should also come with an _init function which
+initialises the struct so that _destroy is a no-op.
+
+
+ASYNCHRONOUS/LONG-RUNNING OPERATIONS
+------------------------------------
+
+All long-running operations in libxl need to use the asynchronous
+operation machinery.  Consult the programmer documentation in
+libxl_internal.h for details - search for "Machinery for asynchronous
+operations".
+
+The code for asynchronous operations should be laid out in
+chronological order.  That is, where there is a chain of callback
+functions, each subsequent function should be, textually, the next
+function in the file.  This will normally involve predeclaring the
+callback functions.  Synchronous helper functions should be separated
+out into a section preceding the main callback chain.
+
+Control flow arrangements in asynchronous operations should be made as
+simple as possible, because it can otherwise be very hard to see
+through the tangle.
+
+
+When inventing a new sub-operation in asynchronous code, consider
+whether to structure it formally as a sub-operation with its own state
+structure.  (See, for example, libxl__datacopier_*.)
+
+An ao-suboperation state structure should contain, in this order:
+  * fields that the caller must fill in, and which are,
+    effectively, the parameters to the operation, including:
+      - libxl__ao *ao
+      - the callback function pointer(s), which
+        should be named callback or callback_*.
+  * shared information fields or ones used for returning information
+    to the calling operation
+  * private fields
+These sections should be clearly demarcated by comments.
+
+An asynchronous operation should normally have an idempotent stop or
+cancel function.  It should normally also have an _init function for
+its state struct, which arranges that the stop is a no-op.
+
+The permitted order of calls into your ao operation's methods must be
+documented in comments, if it is nontrivial.
+
+
+When using an ao sub-operation, you should normally:
+ * Physically include the sub-operation state struct in your
+   own state struct;
+ * Use CONTAINER_OF to find your own state struct at the start of
+   your implementations of the sub-operation callback functions;
+ * Unconditionally initialise the sub-operation's struct (with its
+   _init method) in your own _init method.
+ * Unconditionally cancel or destroy the sub-operation in your own
+   cancel or destroy method.
+
+
+FORMATTING AND NAMING
+---------------------
+
 Blatantly copied from qemu and linux with few modifications.
 
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:44:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1oj-0004f0-Vw; Wed, 05 Nov 2014 14:44:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm1oi-0004dc-K7
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:44:12 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	81/99-02559-BB73A545; Wed, 05 Nov 2014 14:44:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415198643!12736683!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31723 invoked from network); 5 Nov 2014 14:44:11 -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;
	5 Nov 2014 14:44:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="189739000"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:44:01 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0001Pp-Tu;
	Wed, 05 Nov 2014 14:43:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0007nv-Lk;
	Wed, 05 Nov 2014 14:43:56 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 5 Nov 2014 14:43:49 +0000
Message-ID: <1415198630-29937-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3/4] libxl: CODING_STYLE: Mention function out
	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

We seem to use both `_r' and `_out'.  Document both.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 8dcc22b..68d769d 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -241,6 +241,9 @@ Local variables used to store return values should have descriptive name
 like "rc" or "ret". Following the same reasoning the label used as exit
 path should be called "out".
 
+Function arguments which are used to return values to the caller
+should be suffixed `_r' or `_out'.
+
 Variables, type names and function names are
 lower_case_with_underscores.
 Type names and function names use the prefix libxl__ when internal to
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:44:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1oj-0004f0-Vw; Wed, 05 Nov 2014 14:44:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm1oi-0004dc-K7
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:44:12 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	81/99-02559-BB73A545; Wed, 05 Nov 2014 14:44:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415198643!12736683!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31723 invoked from network); 5 Nov 2014 14:44:11 -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;
	5 Nov 2014 14:44:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="189739000"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:44:01 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0001Pp-Tu;
	Wed, 05 Nov 2014 14:43:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0007nv-Lk;
	Wed, 05 Nov 2014 14:43:56 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 5 Nov 2014 14:43:49 +0000
Message-ID: <1415198630-29937-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3/4] libxl: CODING_STYLE: Mention function out
	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

We seem to use both `_r' and `_out'.  Document both.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 8dcc22b..68d769d 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -241,6 +241,9 @@ Local variables used to store return values should have descriptive name
 like "rc" or "ret". Following the same reasoning the label used as exit
 path should be called "out".
 
+Function arguments which are used to return values to the caller
+should be suffixed `_r' or `_out'.
+
 Variables, type names and function names are
 lower_case_with_underscores.
 Type names and function names use the prefix libxl__ when internal to
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:44:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14: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 1Xm1ol-0004g6-Fs; Wed, 05 Nov 2014 14:44:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm1ok-0004ec-36
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:44:14 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	5F/80-02954-DB73A545; Wed, 05 Nov 2014 14:44:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415198643!12736683!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32715 invoked from network); 5 Nov 2014 14:44:11 -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;
	5 Nov 2014 14:44:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="189739002"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:44:02 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm1oT-0001Ps-4b;
	Wed, 05 Nov 2014 14:43:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0007o0-TL;
	Wed, 05 Nov 2014 14:43:56 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 5 Nov 2014 14:43:50 +0000
Message-ID: <1415198630-29937-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4/4] libxl: CODING_STYLE: Discuss existing style
	problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Document that:
 - the existing code is not all confirming yet
 - code should conform
 - we will sometimes accept patches with nonconforming elements if
   they don't make matters worse.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 68d769d..c836f3c 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -2,6 +2,21 @@ LIBXENLIGHT CODING STYLE
 ========================
 
 
+AN APOLOGY AND WARNING
+----------------------
+
+Much of the code in libxl does not yet follow this coding style
+document in every respect.  However, new code is expected to conform.
+
+Patches to improve the style of existing code are welcome.  Please
+separate these out from functional changes.
+
+If it is not feasible to conform fully to the style while patching old
+code, without doing substantial style reengineering first, we may
+accept patches which contain nonconformant elements, provided that
+they don't make the coding style problem worse overall.
+
+
 MEMORY ALLOCATION
 -----------------
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:44:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14: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 1Xm1ol-0004g6-Fs; Wed, 05 Nov 2014 14:44:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm1ok-0004ec-36
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 14:44:14 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	5F/80-02954-DB73A545; Wed, 05 Nov 2014 14:44:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415198643!12736683!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32715 invoked from network); 5 Nov 2014 14:44:11 -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;
	5 Nov 2014 14:44:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="189739002"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:44:02 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm1oT-0001Ps-4b;
	Wed, 05 Nov 2014 14:43:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm1oS-0007o0-TL;
	Wed, 05 Nov 2014 14:43:56 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 5 Nov 2014 14:43:50 +0000
Message-ID: <1415198630-29937-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4/4] libxl: CODING_STYLE: Discuss existing style
	problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Document that:
 - the existing code is not all confirming yet
 - code should conform
 - we will sometimes accept patches with nonconforming elements if
   they don't make matters worse.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 68d769d..c836f3c 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -2,6 +2,21 @@ LIBXENLIGHT CODING STYLE
 ========================
 
 
+AN APOLOGY AND WARNING
+----------------------
+
+Much of the code in libxl does not yet follow this coding style
+document in every respect.  However, new code is expected to conform.
+
+Patches to improve the style of existing code are welcome.  Please
+separate these out from functional changes.
+
+If it is not feasible to conform fully to the style while patching old
+code, without doing substantial style reengineering first, we may
+accept patches which contain nonconformant elements, provided that
+they don't make the coding style problem worse overall.
+
+
 MEMORY ALLOCATION
 -----------------
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:52:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1wl-0005SI-LL; Wed, 05 Nov 2014 14:52:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xm1wj-0005SD-Tr
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:52:30 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	A4/1A-17694-DA93A545; Wed, 05 Nov 2014 14:52:29 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415199147!11832521!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3765 invoked from network); 5 Nov 2014 14:52:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 14:52:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="189742231"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:52:26 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xm1wg-0001aW-4k;
	Wed, 05 Nov 2014 14:52:26 +0000
Date: Wed, 5 Nov 2014 14:52:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <545A2A96.8060105@linaro.org>
Message-ID: <alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
	<545A2A96.8060105@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: zoltan.kiss@huawei.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Julien Grall wrote:
> Hi Frediano,
> 
> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> > This name can appear in some Linux kernel repos. Not very fortunate,
> > but to avoid others spending an hour to spot that few characters
> > difference it worth to work around it.
> 
> Linux upstream is using "hisilicon,hip04-intc" to detect the hisilicon
> interrupt controller. So it's not a workaround.
> 
> Which kernel is using the "*,hip04-gic"?

Good question, but what really matters is the string that u-boot (or any
other firmware/bootloader) is going to use, right? So, which one is it?



> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > ---
> >  xen/arch/arm/gic-v2.c     | 1 +
> >  xen/include/asm-arm/gic.h | 4 +++-
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > index 3cb59dd..9ab30ce 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -823,6 +823,7 @@ DT_DEVICE_END
> >  static const char * const hip04_gicv2_dt_compat[] __initconst =
> >  {
> >      DT_COMPAT_GIC_HIP04,
> > +    DT_COMPAT_GIC_HIP04_2,
> >      NULL
> >  };
> >  
> > diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> > index 5adb628..3d2b3db 100644
> > --- a/xen/include/asm-arm/gic.h
> > +++ b/xen/include/asm-arm/gic.h
> > @@ -156,11 +156,13 @@
> >  #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
> >  #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
> >  #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
> > +#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
> >  
> >  #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
> >                          DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
> >                          DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
> > -                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
> > +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
> > +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
> >  
> >  #define DT_COMPAT_GIC_V3             "arm,gic-v3"
> >  
> > 
> 
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:52:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm1wl-0005SI-LL; Wed, 05 Nov 2014 14:52:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xm1wj-0005SD-Tr
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:52:30 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	A4/1A-17694-DA93A545; Wed, 05 Nov 2014 14:52:29 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415199147!11832521!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3765 invoked from network); 5 Nov 2014 14:52:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 14:52:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="189742231"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 09:52:26 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xm1wg-0001aW-4k;
	Wed, 05 Nov 2014 14:52:26 +0000
Date: Wed, 5 Nov 2014 14:52:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <545A2A96.8060105@linaro.org>
Message-ID: <alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
	<545A2A96.8060105@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: zoltan.kiss@huawei.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Julien Grall wrote:
> Hi Frediano,
> 
> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> > This name can appear in some Linux kernel repos. Not very fortunate,
> > but to avoid others spending an hour to spot that few characters
> > difference it worth to work around it.
> 
> Linux upstream is using "hisilicon,hip04-intc" to detect the hisilicon
> interrupt controller. So it's not a workaround.
> 
> Which kernel is using the "*,hip04-gic"?

Good question, but what really matters is the string that u-boot (or any
other firmware/bootloader) is going to use, right? So, which one is it?



> > Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
> > ---
> >  xen/arch/arm/gic-v2.c     | 1 +
> >  xen/include/asm-arm/gic.h | 4 +++-
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > index 3cb59dd..9ab30ce 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -823,6 +823,7 @@ DT_DEVICE_END
> >  static const char * const hip04_gicv2_dt_compat[] __initconst =
> >  {
> >      DT_COMPAT_GIC_HIP04,
> > +    DT_COMPAT_GIC_HIP04_2,
> >      NULL
> >  };
> >  
> > diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> > index 5adb628..3d2b3db 100644
> > --- a/xen/include/asm-arm/gic.h
> > +++ b/xen/include/asm-arm/gic.h
> > @@ -156,11 +156,13 @@
> >  #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
> >  #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
> >  #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
> > +#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
> >  
> >  #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
> >                          DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
> >                          DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
> > -                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
> > +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
> > +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
> >  
> >  #define DT_COMPAT_GIC_V3             "arm,gic-v3"
> >  
> > 
> 
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:54:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14: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 1Xm1yJ-0005Wn-5D; Wed, 05 Nov 2014 14:54:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1Xm1yH-0005Wh-CB
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:54:05 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	96/48-09842-C0A3A545; Wed, 05 Nov 2014 14:54:04 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415199244!12956397!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26666 invoked from network); 5 Nov 2014 14:54:04 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 14:54:04 -0000
Received: by mail-wi0-f170.google.com with SMTP id r20so246354wiv.5
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 06:54:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=nBPOo/4783PZKFFsW/7Z/ZKBd4kcxIEI5mxoRvgMkKc=;
	b=DwUNMvyT02wukdSViPR6aj/9pod2PjTsF5/ZhE7J8zkDeghn7H0EU5clwPFWd1Sz9n
	xiBmmGTGx73znS+ANKxQovtLk3VOR3JdWlGKITGu4exkplSIorngBDungOnQLoe4hiVc
	+aUu8ta2I288af4qDRClsphfmd0Opk9kkfbdiukC36SNO9R4PwXdXNPJj6mwCN3RUuBf
	DFFfbYumV3ew8EStAL26w3ZnMPPBr+dxmqEbTiMCI9wHVFQgV5ZK28+0msjSeGNkdrXf
	LVLI6Z4VuVCJNeRM29EBFcyZGZ1eZfVaXTHulYPsIfO6SHMIQwvH6skyDHE0AEwBsy6l
	nQjQ==
X-Gm-Message-State: ALoCoQloe0jmQGbFXObCS2f55UDO4OJYDGwwwAB/C6t/cYKhia5OoXWOpKkS31zXG8zjlIy0PWrw
X-Received: by 10.194.246.167 with SMTP id xx7mr20287207wjc.118.1415199244132; 
	Wed, 05 Nov 2014 06:54:04 -0800 (PST)
Received: from [192.168.0.100] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	cg15sm2370125wjb.34.2014.11.05.06.54.02 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 05 Nov 2014 06:54:03 -0800 (PST)
Message-ID: <545A3A0A.9010300@linaro.org>
Date: Wed, 05 Nov 2014 14:54:02 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Julien Grall <julien.grall@linaro.org>, 
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Ian Campbell <ian.campbell@citrix.com>, 
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
In-Reply-To: <545A31C7.3070202@linaro.org>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 05/11/14 14:18, Julien Grall wrote:
> This check is pointless, as said on an earlier version of this series,
> gicv2_make_dt_node is only used to create DOM0 (hardware domain) device
> tree.

Btw. where is the guest DTB created? Quickly checking the code I 
couldn't find it.

Thanks,

Zoli

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:54:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14: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 1Xm1yJ-0005Wn-5D; Wed, 05 Nov 2014 14:54:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1Xm1yH-0005Wh-CB
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:54:05 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	96/48-09842-C0A3A545; Wed, 05 Nov 2014 14:54:04 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415199244!12956397!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26666 invoked from network); 5 Nov 2014 14:54:04 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 14:54:04 -0000
Received: by mail-wi0-f170.google.com with SMTP id r20so246354wiv.5
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 06:54:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=nBPOo/4783PZKFFsW/7Z/ZKBd4kcxIEI5mxoRvgMkKc=;
	b=DwUNMvyT02wukdSViPR6aj/9pod2PjTsF5/ZhE7J8zkDeghn7H0EU5clwPFWd1Sz9n
	xiBmmGTGx73znS+ANKxQovtLk3VOR3JdWlGKITGu4exkplSIorngBDungOnQLoe4hiVc
	+aUu8ta2I288af4qDRClsphfmd0Opk9kkfbdiukC36SNO9R4PwXdXNPJj6mwCN3RUuBf
	DFFfbYumV3ew8EStAL26w3ZnMPPBr+dxmqEbTiMCI9wHVFQgV5ZK28+0msjSeGNkdrXf
	LVLI6Z4VuVCJNeRM29EBFcyZGZ1eZfVaXTHulYPsIfO6SHMIQwvH6skyDHE0AEwBsy6l
	nQjQ==
X-Gm-Message-State: ALoCoQloe0jmQGbFXObCS2f55UDO4OJYDGwwwAB/C6t/cYKhia5OoXWOpKkS31zXG8zjlIy0PWrw
X-Received: by 10.194.246.167 with SMTP id xx7mr20287207wjc.118.1415199244132; 
	Wed, 05 Nov 2014 06:54:04 -0800 (PST)
Received: from [192.168.0.100] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	cg15sm2370125wjb.34.2014.11.05.06.54.02 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 05 Nov 2014 06:54:03 -0800 (PST)
Message-ID: <545A3A0A.9010300@linaro.org>
Date: Wed, 05 Nov 2014 14:54:02 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Julien Grall <julien.grall@linaro.org>, 
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Ian Campbell <ian.campbell@citrix.com>, 
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
In-Reply-To: <545A31C7.3070202@linaro.org>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 05/11/14 14:18, Julien Grall wrote:
> This check is pointless, as said on an earlier version of this series,
> gicv2_make_dt_node is only used to create DOM0 (hardware domain) device
> tree.

Btw. where is the guest DTB created? Quickly checking the code I 
couldn't find it.

Thanks,

Zoli

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:58:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm22S-0005kU-WC; Wed, 05 Nov 2014 14:58:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm22R-0005jz-BI
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:58:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	64/B0-09842-E0B3A545; Wed, 05 Nov 2014 14:58:22 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415199502!12994155!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10451 invoked from network); 5 Nov 2014 14:58:22 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 14:58:22 -0000
Received: by mail-wi0-f170.google.com with SMTP id r20so258142wiv.5
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 06:58:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=gWXkhBbIp7xXYdaCTW4Iy39+m8YIrpCBAoQRguzvTJQ=;
	b=VxGujAo05kKNs4ydMzrHOUks505SdrXDsCuldxBGR849jsubXZ5ZrM2WqNFLIPh6V3
	zl/is9l0eMZe8+nIrHcUSZH9d35ef6gR/zeNrHCUSOY+OSNvsoOypiNqht6JTvUBIrFc
	YWqHNle259hBRNTcPu5hxtXUmFxj4p57lb0e0JyULX4KUD8V0lhr/TYVnvLkP56PspmP
	0G53Ij+xXvnuRkfEe4C+QhupKBPFu78VCU4E5qsNs9rWG+pmgEs05jM/EkUJv8AjwZD9
	o1KR6Zjgy6rRVlxOkAV7bUauUU+Y3NLMQdEZoJvLZBRbuaTrS6kp3QbcAWljBTqUbbgi
	2IWA==
X-Gm-Message-State: ALoCoQln+vIp42AIoxDpWi6VRUaA7NAOsErzOBE/47War8pLRTlky5w5FXZqprQ8Sem1S/xER5os
X-Received: by 10.194.239.164 with SMTP id vt4mr4293258wjc.131.1415199502177; 
	Wed, 05 Nov 2014 06:58:22 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id wm6sm4389081wjb.5.2014.11.05.06.58.20
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 06:58:21 -0800 (PST)
Message-ID: <545A3B06.8090106@linaro.org>
Date: Wed, 05 Nov 2014 14:58:14 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Zoltan Kiss <zoltan.kiss@linaro.org>, 
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Ian Campbell <ian.campbell@citrix.com>, 
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org> <545A3A0A.9010300@linaro.org>
In-Reply-To: <545A3A0A.9010300@linaro.org>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/05/2014 02:54 PM, Zoltan Kiss wrote:
> Hi,
> 
> On 05/11/14 14:18, Julien Grall wrote:
>> This check is pointless, as said on an earlier version of this series,
>> gicv2_make_dt_node is only used to create DOM0 (hardware domain) device
>> tree.
> 
> Btw. where is the guest DTB created? Quickly checking the code I
> couldn't find it.

The guest DTB is created in by the toolstack:

tools/libxl/libxl_arm.c

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 14:58:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 14:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm22S-0005kU-WC; Wed, 05 Nov 2014 14:58:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm22R-0005jz-BI
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 14:58:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	64/B0-09842-E0B3A545; Wed, 05 Nov 2014 14:58:22 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415199502!12994155!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10451 invoked from network); 5 Nov 2014 14:58:22 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 14:58:22 -0000
Received: by mail-wi0-f170.google.com with SMTP id r20so258142wiv.5
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 06:58:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=gWXkhBbIp7xXYdaCTW4Iy39+m8YIrpCBAoQRguzvTJQ=;
	b=VxGujAo05kKNs4ydMzrHOUks505SdrXDsCuldxBGR849jsubXZ5ZrM2WqNFLIPh6V3
	zl/is9l0eMZe8+nIrHcUSZH9d35ef6gR/zeNrHCUSOY+OSNvsoOypiNqht6JTvUBIrFc
	YWqHNle259hBRNTcPu5hxtXUmFxj4p57lb0e0JyULX4KUD8V0lhr/TYVnvLkP56PspmP
	0G53Ij+xXvnuRkfEe4C+QhupKBPFu78VCU4E5qsNs9rWG+pmgEs05jM/EkUJv8AjwZD9
	o1KR6Zjgy6rRVlxOkAV7bUauUU+Y3NLMQdEZoJvLZBRbuaTrS6kp3QbcAWljBTqUbbgi
	2IWA==
X-Gm-Message-State: ALoCoQln+vIp42AIoxDpWi6VRUaA7NAOsErzOBE/47War8pLRTlky5w5FXZqprQ8Sem1S/xER5os
X-Received: by 10.194.239.164 with SMTP id vt4mr4293258wjc.131.1415199502177; 
	Wed, 05 Nov 2014 06:58:22 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id wm6sm4389081wjb.5.2014.11.05.06.58.20
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 06:58:21 -0800 (PST)
Message-ID: <545A3B06.8090106@linaro.org>
Date: Wed, 05 Nov 2014 14:58:14 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Zoltan Kiss <zoltan.kiss@linaro.org>, 
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Ian Campbell <ian.campbell@citrix.com>, 
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org> <545A3A0A.9010300@linaro.org>
In-Reply-To: <545A3A0A.9010300@linaro.org>
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/05/2014 02:54 PM, Zoltan Kiss wrote:
> Hi,
> 
> On 05/11/14 14:18, Julien Grall wrote:
>> This check is pointless, as said on an earlier version of this series,
>> gicv2_make_dt_node is only used to create DOM0 (hardware domain) device
>> tree.
> 
> Btw. where is the guest DTB created? Quickly checking the code I
> couldn't find it.

The guest DTB is created in by the toolstack:

tools/libxl/libxl_arm.c

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 15:13:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 15:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm2HD-0006I9-H6; Wed, 05 Nov 2014 15:13:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xm2HC-0006I4-Dc
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 15:13:38 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	47/17-25547-1AE3A545; Wed, 05 Nov 2014 15:13:37 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415200415!11833912!1
X-Originating-IP: [206.16.17.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjE2LjE3LjcyID0+IDE2MDI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10033 invoked from network); 5 Nov 2014 15:13:37 -0000
Received: from dfwrgout.huawei.com (HELO dfwrgout.huawei.com) (206.16.17.72)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 15:13:37 -0000
Received: from 172.18.9.243 (EHLO lhreml401-hub.china.huawei.com)
	([172.18.9.243])
	by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id AYY78301; Wed, 05 Nov 2014 09:13:33 -0600 (CST)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id
	14.03.0158.001; Wed, 5 Nov 2014 15:13:26 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v3 8/8] xen/arm: Handle translated addresses for
	hardware domains
Thread-Index: AQHP+Nz5JXxbZDhNFky+GUtoHCI5CpxSFRmAgAAOuCA=
Date: Wed, 5 Nov 2014 15:13:26 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
In-Reply-To: <545A31C7.3070202@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.71.64]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi Frediano,
> 
> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> > Translated address could have an offset applied to them.
> > Replicate same value for device node to avoid improper address
> > computation in the OS.
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > ---
> >  xen/arch/arm/gic-v2.c | 23 +++++++++++++++++++++--
> >  1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > 2f6bbd5..271074d 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -67,8 +67,10 @@
> >  /* Global state */
> >  static struct {
> >      paddr_t dbase;            /* Address of distributor registers */
> > +    paddr_t dbase_raw;        /* Untranslated address of distributor
> registers */
> >      void __iomem * map_dbase; /* IO mapped Address of distributor
> registers */
> >      paddr_t cbase;            /* Address of CPU interface registers
> */
> > +    paddr_t cbase_raw;        /* Untranslated address of CPU
> interface registers */
> >      void __iomem * map_cbase[2]; /* IO mapped Address of CPU
> interface registers */
> >      paddr_t hbase;            /* Address of virtual interface
> registers */
> >      void __iomem * map_hbase; /* IO Address of virtual interface
> > registers */ @@ -671,8 +673,17 @@ static int gicv2_make_dt_node(const
> struct domain *d,
> >          return -FDT_ERR_XEN(ENOMEM);
> >
> >      tmp = new_cells;
> > -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > +
> > +    if ( is_hardware_domain(d) )
> > +    {
> 
> This check is pointless, as said on an earlier version of this series,
> gicv2_make_dt_node is only used to create DOM0 (hardware domain) device
> tree.
> 
> Regards,
> 
> --
> Julien Grall

How does sound something like this (already tested, it's working). Perhaps just to be paranoid a test on len after reading reg property would be perfect.

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2f6bbd5..2c4d097 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -632,7 +632,7 @@ static int gicv2_make_dt_node(const struct domain *d,
     const void *compatible = NULL;
     u32 len;
     __be32 *new_cells, *tmp;
-    int res = 0;
+    int res = 0, na, ns;
 
     compatible = dt_get_property(gic, "compatible", &len);
     if ( !compatible )
@@ -664,15 +664,27 @@ static int gicv2_make_dt_node(const struct domain *d,
     if ( res )
         return res;
 
-    len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
+    /* copy GICC and GICD regions */
+    na = dt_n_addr_cells(node);
+    ns = dt_n_size_cells(node);
+
+    if ( na != dt_n_addr_cells(gic) || ns != dt_n_size_cells(gic) )
+        return -FDT_ERR_XEN(EINVAL);
+
+    tmp = (__be32 *) dt_get_property(gic, "reg", &len);
+    if ( !tmp )
+    {
+        dprintk(XENLOG_ERR, "Can't find reg property for the gic node\n");
+        return -FDT_ERR_XEN(ENOENT);
+    }
+
+    len = dt_cells_to_size(na + ns);
     len *= 2; /* GIC has two memory regions: Distributor + CPU interface */
     new_cells = xzalloc_bytes(len);
     if ( new_cells == NULL )
         return -FDT_ERR_XEN(ENOMEM);
 
-    tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+    memcpy(new_cells, tmp, len);
 
     res = fdt_property(fdt, "reg", new_cells, len);
     xfree(new_cells);
-- 
1.9.1

Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 15:13:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 15:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm2HD-0006I9-H6; Wed, 05 Nov 2014 15:13:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xm2HC-0006I4-Dc
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 15:13:38 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	47/17-25547-1AE3A545; Wed, 05 Nov 2014 15:13:37 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415200415!11833912!1
X-Originating-IP: [206.16.17.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjE2LjE3LjcyID0+IDE2MDI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10033 invoked from network); 5 Nov 2014 15:13:37 -0000
Received: from dfwrgout.huawei.com (HELO dfwrgout.huawei.com) (206.16.17.72)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 15:13:37 -0000
Received: from 172.18.9.243 (EHLO lhreml401-hub.china.huawei.com)
	([172.18.9.243])
	by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id AYY78301; Wed, 05 Nov 2014 09:13:33 -0600 (CST)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id
	14.03.0158.001; Wed, 5 Nov 2014 15:13:26 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v3 8/8] xen/arm: Handle translated addresses for
	hardware domains
Thread-Index: AQHP+Nz5JXxbZDhNFky+GUtoHCI5CpxSFRmAgAAOuCA=
Date: Wed, 5 Nov 2014 15:13:26 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
In-Reply-To: <545A31C7.3070202@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.71.64]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi Frediano,
> 
> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> > Translated address could have an offset applied to them.
> > Replicate same value for device node to avoid improper address
> > computation in the OS.
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > ---
> >  xen/arch/arm/gic-v2.c | 23 +++++++++++++++++++++--
> >  1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > 2f6bbd5..271074d 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -67,8 +67,10 @@
> >  /* Global state */
> >  static struct {
> >      paddr_t dbase;            /* Address of distributor registers */
> > +    paddr_t dbase_raw;        /* Untranslated address of distributor
> registers */
> >      void __iomem * map_dbase; /* IO mapped Address of distributor
> registers */
> >      paddr_t cbase;            /* Address of CPU interface registers
> */
> > +    paddr_t cbase_raw;        /* Untranslated address of CPU
> interface registers */
> >      void __iomem * map_cbase[2]; /* IO mapped Address of CPU
> interface registers */
> >      paddr_t hbase;            /* Address of virtual interface
> registers */
> >      void __iomem * map_hbase; /* IO Address of virtual interface
> > registers */ @@ -671,8 +673,17 @@ static int gicv2_make_dt_node(const
> struct domain *d,
> >          return -FDT_ERR_XEN(ENOMEM);
> >
> >      tmp = new_cells;
> > -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > +
> > +    if ( is_hardware_domain(d) )
> > +    {
> 
> This check is pointless, as said on an earlier version of this series,
> gicv2_make_dt_node is only used to create DOM0 (hardware domain) device
> tree.
> 
> Regards,
> 
> --
> Julien Grall

How does sound something like this (already tested, it's working). Perhaps just to be paranoid a test on len after reading reg property would be perfect.

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2f6bbd5..2c4d097 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -632,7 +632,7 @@ static int gicv2_make_dt_node(const struct domain *d,
     const void *compatible = NULL;
     u32 len;
     __be32 *new_cells, *tmp;
-    int res = 0;
+    int res = 0, na, ns;
 
     compatible = dt_get_property(gic, "compatible", &len);
     if ( !compatible )
@@ -664,15 +664,27 @@ static int gicv2_make_dt_node(const struct domain *d,
     if ( res )
         return res;
 
-    len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
+    /* copy GICC and GICD regions */
+    na = dt_n_addr_cells(node);
+    ns = dt_n_size_cells(node);
+
+    if ( na != dt_n_addr_cells(gic) || ns != dt_n_size_cells(gic) )
+        return -FDT_ERR_XEN(EINVAL);
+
+    tmp = (__be32 *) dt_get_property(gic, "reg", &len);
+    if ( !tmp )
+    {
+        dprintk(XENLOG_ERR, "Can't find reg property for the gic node\n");
+        return -FDT_ERR_XEN(ENOENT);
+    }
+
+    len = dt_cells_to_size(na + ns);
     len *= 2; /* GIC has two memory regions: Distributor + CPU interface */
     new_cells = xzalloc_bytes(len);
     if ( new_cells == NULL )
         return -FDT_ERR_XEN(ENOMEM);
 
-    tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
+    memcpy(new_cells, tmp, len);
 
     res = fdt_property(fdt, "reg", new_cells, len);
     xfree(new_cells);
-- 
1.9.1

Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 15:29:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 15: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 1Xm2W3-0006cD-1O; Wed, 05 Nov 2014 15:28:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm2W1-0006c8-8O
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 15:28:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4D/FF-09842-8324A545; Wed, 05 Nov 2014 15:28:56 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415201335!12977446!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18466 invoked from network); 5 Nov 2014 15:28:56 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 15:28:56 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so1212297wgg.2
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 07:28:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=mfsZ98SYk8bGD39QIAIm1B6f8PNCkPsT9fCy18Ws670=;
	b=gURT21qhFCL07erWZ+nT32x+r04b5QR14nsoWMZVhMQw0nUxWpw+OnJ5BWHZSQtRP9
	MAu/V2PdQKFaRST+p9CF14yfWHHpW5f4klnwtdYy2VlEeGqxLw+Z9/LoLFqlQW8q7Iju
	nA55sMkkWUj85Vxy4Q1ozEF6xMvcGtKKH4khdUSR3Mbw2fevCkFD5+inn/XjOu5ujBzx
	LiXM3egu0LPRPHEF5Y1Q93+W81KzzqOAt3ND0PcJWujudyEM0FiQF4dkvCGzMwd1+XF4
	nDGsP16ZBl5zsWTEFvkmF7xisk2tekTWEGxOHz+QdtZp2TsNITqkvy+T5cor5Khima55
	iWxg==
X-Gm-Message-State: ALoCoQmbbJUVRKEl9zOihRi3G+Kz8VhmJjy5BCMsXtb2K/7OhCvLWVskP2s92gtGP4BGT+6qjbRb
X-Received: by 10.180.19.164 with SMTP id g4mr6341206wie.51.1415201335803;
	Wed, 05 Nov 2014 07:28:55 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id q10sm4427961wjq.35.2014.11.05.07.28.54
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 07:28:55 -0800 (PST)
Message-ID: <545A4230.9030506@linaro.org>
Date: Wed, 05 Nov 2014 15:28:48 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/05/2014 03:13 PM, Frediano Ziglio wrote:
> How does sound something like this (already tested, it's working).

The idea looks good to me. Few comments below.

Also, I'm wondering if we could create a generic function for this
purpose. The code of the GICv3 suffers of the same problem.

> Perhaps just to be paranoid a test on len after reading reg property
would be perfect.

The property/node has been validated in the GICv2 initialization.
Checking again here is not necessary.

> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 2f6bbd5..2c4d097 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -632,7 +632,7 @@ static int gicv2_make_dt_node(const struct domain *d,
>      const void *compatible = NULL;
>      u32 len;
>      __be32 *new_cells, *tmp;
> -    int res = 0;
> +    int res = 0, na, ns;
>  
>      compatible = dt_get_property(gic, "compatible", &len);
>      if ( !compatible )
> @@ -664,15 +664,27 @@ static int gicv2_make_dt_node(const struct domain *d,
>      if ( res )
>          return res;
>  
> -    len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
> +    /* copy GICC and GICD regions */
> +    na = dt_n_addr_cells(node);
> +    ns = dt_n_size_cells(node);
> +
> +    if ( na != dt_n_addr_cells(gic) || ns != dt_n_size_cells(gic) )
> +        return -FDT_ERR_XEN(EINVAL);

Not necessary, the caller of this function already check that gic (i.e
dt_interrupt_controller) == node.

If you really to be safe, I would add ASSERT(gic == node);

> +
> +    tmp = (__be32 *) dt_get_property(gic, "reg", &len);

The cast is not necessary.

> +    if ( !tmp )
> +    {
> +        dprintk(XENLOG_ERR, "Can't find reg property for the gic node\n");
> +        return -FDT_ERR_XEN(ENOENT);
> +    }
> +
> +    len = dt_cells_to_size(na + ns);
>      len *= 2; /* GIC has two memory regions: Distributor + CPU interface */
>      new_cells = xzalloc_bytes(len);
>      if ( new_cells == NULL )
>          return -FDT_ERR_XEN(ENOMEM);
>  
> -    tmp = new_cells;
> -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> +    memcpy(new_cells, tmp, len);

You don't need to copy the data in the temporary variable. You can
directly use fdt_property with the right len. Smth like:

fdt_property(fdt, "reg", tmp, len);

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 15:29:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 15: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 1Xm2W3-0006cD-1O; Wed, 05 Nov 2014 15:28:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm2W1-0006c8-8O
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 15:28:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4D/FF-09842-8324A545; Wed, 05 Nov 2014 15:28:56 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415201335!12977446!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18466 invoked from network); 5 Nov 2014 15:28:56 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 15:28:56 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so1212297wgg.2
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 07:28:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=mfsZ98SYk8bGD39QIAIm1B6f8PNCkPsT9fCy18Ws670=;
	b=gURT21qhFCL07erWZ+nT32x+r04b5QR14nsoWMZVhMQw0nUxWpw+OnJ5BWHZSQtRP9
	MAu/V2PdQKFaRST+p9CF14yfWHHpW5f4klnwtdYy2VlEeGqxLw+Z9/LoLFqlQW8q7Iju
	nA55sMkkWUj85Vxy4Q1ozEF6xMvcGtKKH4khdUSR3Mbw2fevCkFD5+inn/XjOu5ujBzx
	LiXM3egu0LPRPHEF5Y1Q93+W81KzzqOAt3ND0PcJWujudyEM0FiQF4dkvCGzMwd1+XF4
	nDGsP16ZBl5zsWTEFvkmF7xisk2tekTWEGxOHz+QdtZp2TsNITqkvy+T5cor5Khima55
	iWxg==
X-Gm-Message-State: ALoCoQmbbJUVRKEl9zOihRi3G+Kz8VhmJjy5BCMsXtb2K/7OhCvLWVskP2s92gtGP4BGT+6qjbRb
X-Received: by 10.180.19.164 with SMTP id g4mr6341206wie.51.1415201335803;
	Wed, 05 Nov 2014 07:28:55 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id q10sm4427961wjq.35.2014.11.05.07.28.54
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 07:28:55 -0800 (PST)
Message-ID: <545A4230.9030506@linaro.org>
Date: Wed, 05 Nov 2014 15:28:48 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/05/2014 03:13 PM, Frediano Ziglio wrote:
> How does sound something like this (already tested, it's working).

The idea looks good to me. Few comments below.

Also, I'm wondering if we could create a generic function for this
purpose. The code of the GICv3 suffers of the same problem.

> Perhaps just to be paranoid a test on len after reading reg property
would be perfect.

The property/node has been validated in the GICv2 initialization.
Checking again here is not necessary.

> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 2f6bbd5..2c4d097 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -632,7 +632,7 @@ static int gicv2_make_dt_node(const struct domain *d,
>      const void *compatible = NULL;
>      u32 len;
>      __be32 *new_cells, *tmp;
> -    int res = 0;
> +    int res = 0, na, ns;
>  
>      compatible = dt_get_property(gic, "compatible", &len);
>      if ( !compatible )
> @@ -664,15 +664,27 @@ static int gicv2_make_dt_node(const struct domain *d,
>      if ( res )
>          return res;
>  
> -    len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
> +    /* copy GICC and GICD regions */
> +    na = dt_n_addr_cells(node);
> +    ns = dt_n_size_cells(node);
> +
> +    if ( na != dt_n_addr_cells(gic) || ns != dt_n_size_cells(gic) )
> +        return -FDT_ERR_XEN(EINVAL);

Not necessary, the caller of this function already check that gic (i.e
dt_interrupt_controller) == node.

If you really to be safe, I would add ASSERT(gic == node);

> +
> +    tmp = (__be32 *) dt_get_property(gic, "reg", &len);

The cast is not necessary.

> +    if ( !tmp )
> +    {
> +        dprintk(XENLOG_ERR, "Can't find reg property for the gic node\n");
> +        return -FDT_ERR_XEN(ENOENT);
> +    }
> +
> +    len = dt_cells_to_size(na + ns);
>      len *= 2; /* GIC has two memory regions: Distributor + CPU interface */
>      new_cells = xzalloc_bytes(len);
>      if ( new_cells == NULL )
>          return -FDT_ERR_XEN(ENOMEM);
>  
> -    tmp = new_cells;
> -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> +    memcpy(new_cells, tmp, len);

You don't need to copy the data in the temporary variable. You can
directly use fdt_property with the right len. Smth like:

fdt_property(fdt, "reg", tmp, len);

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 15:47:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 15:47:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm2nB-00078Z-PR; Wed, 05 Nov 2014 15:46:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xm2nA-00078U-Mj
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 15:46:40 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	F4/AD-02953-0664A545; Wed, 05 Nov 2014 15:46:40 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415202397!12769557!1
X-Originating-IP: [206.16.17.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjE2LjE3LjcyID0+IDE2MDI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10535 invoked from network); 5 Nov 2014 15:46:39 -0000
Received: from dfwrgout.huawei.com (HELO dfwrgout.huawei.com) (206.16.17.72)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 15:46:39 -0000
Received: from 172.18.9.243 (EHLO lhreml402-hub.china.huawei.com)
	([172.18.9.243])
	by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id AYY82315; Wed, 05 Nov 2014 09:46:34 -0600 (CST)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id
	14.03.0158.001; Wed, 5 Nov 2014 15:46:25 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v3 8/8] xen/arm: Handle translated addresses for
	hardware domains
Thread-Index: AQHP+Nz5JXxbZDhNFky+GUtoHCI5CpxSFRmAgAAOuCCAAATYAIAABJGg
Date: Wed, 5 Nov 2014 15:46:25 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B3CE@lhreml509-mbb>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
	<545A4230.9030506@linaro.org>
In-Reply-To: <545A4230.9030506@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.71.64]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On 11/05/2014 03:13 PM, Frediano Ziglio wrote:
> > How does sound something like this (already tested, it's working).
> 
> The idea looks good to me. Few comments below.
> 
> Also, I'm wondering if we could create a generic function for this
> purpose. The code of the GICv3 suffers of the same problem.
> 
> > Perhaps just to be paranoid a test on len after reading reg property
> would be perfect.
> 
> The property/node has been validated in the GICv2 initialization.
> Checking again here is not necessary.
> 
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > 2f6bbd5..2c4d097 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -632,7 +632,7 @@ static int gicv2_make_dt_node(const struct domain
> *d,
> >      const void *compatible = NULL;
> >      u32 len;
> >      __be32 *new_cells, *tmp;
> > -    int res = 0;
> > +    int res = 0, na, ns;
> >
> >      compatible = dt_get_property(gic, "compatible", &len);
> >      if ( !compatible )
> > @@ -664,15 +664,27 @@ static int gicv2_make_dt_node(const struct
> domain *d,
> >      if ( res )
> >          return res;
> >
> > -    len = dt_cells_to_size(dt_n_addr_cells(node) +
> dt_n_size_cells(node));
> > +    /* copy GICC and GICD regions */
> > +    na = dt_n_addr_cells(node);
> > +    ns = dt_n_size_cells(node);
> > +
> > +    if ( na != dt_n_addr_cells(gic) || ns != dt_n_size_cells(gic) )
> > +        return -FDT_ERR_XEN(EINVAL);
> 
> Not necessary, the caller of this function already check that gic (i.e
> dt_interrupt_controller) == node.
> 
> If you really to be safe, I would add ASSERT(gic == node);
> 
> > +
> > +    tmp = (__be32 *) dt_get_property(gic, "reg", &len);
> 
> The cast is not necessary.
> 
> > +    if ( !tmp )
> > +    {
> > +        dprintk(XENLOG_ERR, "Can't find reg property for the gic
> node\n");
> > +        return -FDT_ERR_XEN(ENOENT);
> > +    }
> > +
> > +    len = dt_cells_to_size(na + ns);
> >      len *= 2; /* GIC has two memory regions: Distributor + CPU
> interface */
> >      new_cells = xzalloc_bytes(len);
> >      if ( new_cells == NULL )
> >          return -FDT_ERR_XEN(ENOMEM);
> >
> > -    tmp = new_cells;
> > -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > +    memcpy(new_cells, tmp, len);
> 
> You don't need to copy the data in the temporary variable. You can
> directly use fdt_property with the right len. Smth like:
> 
> fdt_property(fdt, "reg", tmp, len);
> 
> Regards,
> 
> --
> Julien Grall

This then should look much better.

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2f6bbd5..9b9e696 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -629,9 +629,8 @@ static int gicv2_make_dt_node(const struct domain *d,
                               const struct dt_device_node *node, void *fdt)
 {
     const struct dt_device_node *gic = dt_interrupt_controller;
-    const void *compatible = NULL;
+    const void *compatible = NULL, *tmp;
     u32 len;
-    __be32 *new_cells, *tmp;
     int res = 0;
 
     compatible = dt_get_property(gic, "compatible", &len);
@@ -664,18 +663,18 @@ static int gicv2_make_dt_node(const struct domain *d,
     if ( res )
         return res;
 
+    /* copy GICC and GICD regions */
+    tmp = dt_get_property(gic, "reg", &len);
+    if ( !tmp )
+    {
+        dprintk(XENLOG_ERR, "Can't find reg property for the gic node\n");
+        return -FDT_ERR_XEN(ENOENT);
+    }
+
     len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
     len *= 2; /* GIC has two memory regions: Distributor + CPU interface */
-    new_cells = xzalloc_bytes(len);
-    if ( new_cells == NULL )
-        return -FDT_ERR_XEN(ENOMEM);
-
-    tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
 
-    res = fdt_property(fdt, "reg", new_cells, len);
-    xfree(new_cells);
+    res = fdt_property(fdt, "reg", tmp, len);
 
     return res;
 }
-- 
1.9.1

Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 15:47:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 15:47:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm2nB-00078Z-PR; Wed, 05 Nov 2014 15:46:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xm2nA-00078U-Mj
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 15:46:40 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	F4/AD-02953-0664A545; Wed, 05 Nov 2014 15:46:40 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415202397!12769557!1
X-Originating-IP: [206.16.17.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjE2LjE3LjcyID0+IDE2MDI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10535 invoked from network); 5 Nov 2014 15:46:39 -0000
Received: from dfwrgout.huawei.com (HELO dfwrgout.huawei.com) (206.16.17.72)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 15:46:39 -0000
Received: from 172.18.9.243 (EHLO lhreml402-hub.china.huawei.com)
	([172.18.9.243])
	by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id AYY82315; Wed, 05 Nov 2014 09:46:34 -0600 (CST)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id
	14.03.0158.001; Wed, 5 Nov 2014 15:46:25 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v3 8/8] xen/arm: Handle translated addresses for
	hardware domains
Thread-Index: AQHP+Nz5JXxbZDhNFky+GUtoHCI5CpxSFRmAgAAOuCCAAATYAIAABJGg
Date: Wed, 5 Nov 2014 15:46:25 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B3CE@lhreml509-mbb>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
	<545A4230.9030506@linaro.org>
In-Reply-To: <545A4230.9030506@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.71.64]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On 11/05/2014 03:13 PM, Frediano Ziglio wrote:
> > How does sound something like this (already tested, it's working).
> 
> The idea looks good to me. Few comments below.
> 
> Also, I'm wondering if we could create a generic function for this
> purpose. The code of the GICv3 suffers of the same problem.
> 
> > Perhaps just to be paranoid a test on len after reading reg property
> would be perfect.
> 
> The property/node has been validated in the GICv2 initialization.
> Checking again here is not necessary.
> 
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> > 2f6bbd5..2c4d097 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -632,7 +632,7 @@ static int gicv2_make_dt_node(const struct domain
> *d,
> >      const void *compatible = NULL;
> >      u32 len;
> >      __be32 *new_cells, *tmp;
> > -    int res = 0;
> > +    int res = 0, na, ns;
> >
> >      compatible = dt_get_property(gic, "compatible", &len);
> >      if ( !compatible )
> > @@ -664,15 +664,27 @@ static int gicv2_make_dt_node(const struct
> domain *d,
> >      if ( res )
> >          return res;
> >
> > -    len = dt_cells_to_size(dt_n_addr_cells(node) +
> dt_n_size_cells(node));
> > +    /* copy GICC and GICD regions */
> > +    na = dt_n_addr_cells(node);
> > +    ns = dt_n_size_cells(node);
> > +
> > +    if ( na != dt_n_addr_cells(gic) || ns != dt_n_size_cells(gic) )
> > +        return -FDT_ERR_XEN(EINVAL);
> 
> Not necessary, the caller of this function already check that gic (i.e
> dt_interrupt_controller) == node.
> 
> If you really to be safe, I would add ASSERT(gic == node);
> 
> > +
> > +    tmp = (__be32 *) dt_get_property(gic, "reg", &len);
> 
> The cast is not necessary.
> 
> > +    if ( !tmp )
> > +    {
> > +        dprintk(XENLOG_ERR, "Can't find reg property for the gic
> node\n");
> > +        return -FDT_ERR_XEN(ENOENT);
> > +    }
> > +
> > +    len = dt_cells_to_size(na + ns);
> >      len *= 2; /* GIC has two memory regions: Distributor + CPU
> interface */
> >      new_cells = xzalloc_bytes(len);
> >      if ( new_cells == NULL )
> >          return -FDT_ERR_XEN(ENOMEM);
> >
> > -    tmp = new_cells;
> > -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
> > -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
> > +    memcpy(new_cells, tmp, len);
> 
> You don't need to copy the data in the temporary variable. You can
> directly use fdt_property with the right len. Smth like:
> 
> fdt_property(fdt, "reg", tmp, len);
> 
> Regards,
> 
> --
> Julien Grall

This then should look much better.

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2f6bbd5..9b9e696 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -629,9 +629,8 @@ static int gicv2_make_dt_node(const struct domain *d,
                               const struct dt_device_node *node, void *fdt)
 {
     const struct dt_device_node *gic = dt_interrupt_controller;
-    const void *compatible = NULL;
+    const void *compatible = NULL, *tmp;
     u32 len;
-    __be32 *new_cells, *tmp;
     int res = 0;
 
     compatible = dt_get_property(gic, "compatible", &len);
@@ -664,18 +663,18 @@ static int gicv2_make_dt_node(const struct domain *d,
     if ( res )
         return res;
 
+    /* copy GICC and GICD regions */
+    tmp = dt_get_property(gic, "reg", &len);
+    if ( !tmp )
+    {
+        dprintk(XENLOG_ERR, "Can't find reg property for the gic node\n");
+        return -FDT_ERR_XEN(ENOENT);
+    }
+
     len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
     len *= 2; /* GIC has two memory regions: Distributor + CPU interface */
-    new_cells = xzalloc_bytes(len);
-    if ( new_cells == NULL )
-        return -FDT_ERR_XEN(ENOMEM);
-
-    tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
 
-    res = fdt_property(fdt, "reg", new_cells, len);
-    xfree(new_cells);
+    res = fdt_property(fdt, "reg", tmp, len);
 
     return res;
 }
-- 
1.9.1

Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 15:51:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 15:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm2s0-0007Gk-Ge; Wed, 05 Nov 2014 15:51:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm2rz-0007Gf-1g
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 15:51:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DA/1E-24532-A874A545; Wed, 05 Nov 2014 15:51:38 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415202697!4982942!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11565 invoked from network); 5 Nov 2014 15:51:37 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 15:51:37 -0000
Received: by mail-wi0-f179.google.com with SMTP id h11so2427912wiw.6
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 07:51:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=/Zh54wVmIJKH7cP1D0peVRNGdd2GumQDznhGTfOX2P0=;
	b=Bhkzo4TbpGHDnVVvCu3TFWNBTQznjpO5/0AlS49En0f1yPlsPRtFuLUVm/dtB8j99d
	Es3sH7m07QV9oy1IwgaJeq1FtHsmUV0BLkUHWZmvEjsd4Mk19jO6WXM+54FhbFIKsFMv
	VHXWy0LLG+OeaebXgGh1schT0wMpsMo18ZColmHc+VZVlvw9st8InzYiNfKNJbfNOVY5
	zcoxanbngGu2kIK1N58piOP3MuwfIKEH7X9VfarAmOQhjs9PY3RJtyUviWjFo7lkzV6L
	Tejyv4h2G12cb/iWHCDA8z0IcDz5PODCVCBTIE04Nj/LE0u3A474S1PUSqIt2EfUUQtl
	IOmQ==
X-Gm-Message-State: ALoCoQmDwbSD8+Jkiqh/ybDwpa/nCH0kT3n5/0ypwM7majjrXyhOVqJDMwkHMMjjAddokzAvRZvL
X-Received: by 10.180.96.10 with SMTP id do10mr33673475wib.16.1415202697484;
	Wed, 05 Nov 2014 07:51:37 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	cg15sm2528897wjb.34.2014.11.05.07.51.36 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 07:51:36 -0800 (PST)
Message-ID: <545A4782.3050107@linaro.org>
Date: Wed, 05 Nov 2014 15:51:30 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
	<545A4230.9030506@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B3CE@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B3CE@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/05/2014 03:46 PM, Frediano Ziglio wrote:
>> On 11/05/2014 03:13 PM, Frediano Ziglio wrote:
>>> How does sound something like this (already tested, it's working).
>>
>> The idea looks good to me. Few comments below.
>>
>> Also, I'm wondering if we could create a generic function for this
>> purpose. The code of the GICv3 suffers of the same problem.
>>
>>> Perhaps just to be paranoid a test on len after reading reg property
>> would be perfect.
>>
>> The property/node has been validated in the GICv2 initialization.
>> Checking again here is not necessary.
>>
>>>
>>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
>>> 2f6bbd5..2c4d097 100644
>>> --- a/xen/arch/arm/gic-v2.c
>>> +++ b/xen/arch/arm/gic-v2.c
>>> @@ -632,7 +632,7 @@ static int gicv2_make_dt_node(const struct domain
>> *d,
>>>      const void *compatible = NULL;
>>>      u32 len;
>>>      __be32 *new_cells, *tmp;
>>> -    int res = 0;
>>> +    int res = 0, na, ns;
>>>
>>>      compatible = dt_get_property(gic, "compatible", &len);
>>>      if ( !compatible )
>>> @@ -664,15 +664,27 @@ static int gicv2_make_dt_node(const struct
>> domain *d,
>>>      if ( res )
>>>          return res;
>>>
>>> -    len = dt_cells_to_size(dt_n_addr_cells(node) +
>> dt_n_size_cells(node));
>>> +    /* copy GICC and GICD regions */
>>> +    na = dt_n_addr_cells(node);
>>> +    ns = dt_n_size_cells(node);
>>> +
>>> +    if ( na != dt_n_addr_cells(gic) || ns != dt_n_size_cells(gic) )
>>> +        return -FDT_ERR_XEN(EINVAL);
>>
>> Not necessary, the caller of this function already check that gic (i.e
>> dt_interrupt_controller) == node.
>>
>> If you really to be safe, I would add ASSERT(gic == node);
>>
>>> +
>>> +    tmp = (__be32 *) dt_get_property(gic, "reg", &len);
>>
>> The cast is not necessary.
>>
>>> +    if ( !tmp )
>>> +    {
>>> +        dprintk(XENLOG_ERR, "Can't find reg property for the gic
>> node\n");
>>> +        return -FDT_ERR_XEN(ENOENT);
>>> +    }
>>> +
>>> +    len = dt_cells_to_size(na + ns);
>>>      len *= 2; /* GIC has two memory regions: Distributor + CPU
>> interface */
>>>      new_cells = xzalloc_bytes(len);
>>>      if ( new_cells == NULL )
>>>          return -FDT_ERR_XEN(ENOMEM);
>>>
>>> -    tmp = new_cells;
>>> -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
>>> -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
>>> +    memcpy(new_cells, tmp, len);
>>
>> You don't need to copy the data in the temporary variable. You can
>> directly use fdt_property with the right len. Smth like:
>>
>> fdt_property(fdt, "reg", tmp, len);
>>
>> Regards,
>>
>> --
>> Julien Grall
> 
> This then should look much better.
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 2f6bbd5..9b9e696 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -629,9 +629,8 @@ static int gicv2_make_dt_node(const struct domain *d,
>                                const struct dt_device_node *node, void *fdt)
>  {
>      const struct dt_device_node *gic = dt_interrupt_controller;
> -    const void *compatible = NULL;
> +    const void *compatible = NULL, *tmp;
>      u32 len;
> -    __be32 *new_cells, *tmp;

I would prefer if you keep tmp as __be32 *. It documents the real type
of the data. Also, for clarity, I would rename it to cells.

BTW, the commit title/message wasn't really clear. It make thinks you
are fixing the problem for everyone and not only the GICv2.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 15:51:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 15:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm2s0-0007Gk-Ge; Wed, 05 Nov 2014 15:51:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm2rz-0007Gf-1g
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 15:51:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DA/1E-24532-A874A545; Wed, 05 Nov 2014 15:51:38 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415202697!4982942!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11565 invoked from network); 5 Nov 2014 15:51:37 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 15:51:37 -0000
Received: by mail-wi0-f179.google.com with SMTP id h11so2427912wiw.6
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 07:51:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=/Zh54wVmIJKH7cP1D0peVRNGdd2GumQDznhGTfOX2P0=;
	b=Bhkzo4TbpGHDnVVvCu3TFWNBTQznjpO5/0AlS49En0f1yPlsPRtFuLUVm/dtB8j99d
	Es3sH7m07QV9oy1IwgaJeq1FtHsmUV0BLkUHWZmvEjsd4Mk19jO6WXM+54FhbFIKsFMv
	VHXWy0LLG+OeaebXgGh1schT0wMpsMo18ZColmHc+VZVlvw9st8InzYiNfKNJbfNOVY5
	zcoxanbngGu2kIK1N58piOP3MuwfIKEH7X9VfarAmOQhjs9PY3RJtyUviWjFo7lkzV6L
	Tejyv4h2G12cb/iWHCDA8z0IcDz5PODCVCBTIE04Nj/LE0u3A474S1PUSqIt2EfUUQtl
	IOmQ==
X-Gm-Message-State: ALoCoQmDwbSD8+Jkiqh/ybDwpa/nCH0kT3n5/0ypwM7majjrXyhOVqJDMwkHMMjjAddokzAvRZvL
X-Received: by 10.180.96.10 with SMTP id do10mr33673475wib.16.1415202697484;
	Wed, 05 Nov 2014 07:51:37 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	cg15sm2528897wjb.34.2014.11.05.07.51.36 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 07:51:36 -0800 (PST)
Message-ID: <545A4782.3050107@linaro.org>
Date: Wed, 05 Nov 2014 15:51:30 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
	<545A4230.9030506@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B3CE@lhreml509-mbb>
In-Reply-To: <B944B469BF5302468AC6EB05E56CC70D17B3CE@lhreml509-mbb>
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/05/2014 03:46 PM, Frediano Ziglio wrote:
>> On 11/05/2014 03:13 PM, Frediano Ziglio wrote:
>>> How does sound something like this (already tested, it's working).
>>
>> The idea looks good to me. Few comments below.
>>
>> Also, I'm wondering if we could create a generic function for this
>> purpose. The code of the GICv3 suffers of the same problem.
>>
>>> Perhaps just to be paranoid a test on len after reading reg property
>> would be perfect.
>>
>> The property/node has been validated in the GICv2 initialization.
>> Checking again here is not necessary.
>>
>>>
>>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
>>> 2f6bbd5..2c4d097 100644
>>> --- a/xen/arch/arm/gic-v2.c
>>> +++ b/xen/arch/arm/gic-v2.c
>>> @@ -632,7 +632,7 @@ static int gicv2_make_dt_node(const struct domain
>> *d,
>>>      const void *compatible = NULL;
>>>      u32 len;
>>>      __be32 *new_cells, *tmp;
>>> -    int res = 0;
>>> +    int res = 0, na, ns;
>>>
>>>      compatible = dt_get_property(gic, "compatible", &len);
>>>      if ( !compatible )
>>> @@ -664,15 +664,27 @@ static int gicv2_make_dt_node(const struct
>> domain *d,
>>>      if ( res )
>>>          return res;
>>>
>>> -    len = dt_cells_to_size(dt_n_addr_cells(node) +
>> dt_n_size_cells(node));
>>> +    /* copy GICC and GICD regions */
>>> +    na = dt_n_addr_cells(node);
>>> +    ns = dt_n_size_cells(node);
>>> +
>>> +    if ( na != dt_n_addr_cells(gic) || ns != dt_n_size_cells(gic) )
>>> +        return -FDT_ERR_XEN(EINVAL);
>>
>> Not necessary, the caller of this function already check that gic (i.e
>> dt_interrupt_controller) == node.
>>
>> If you really to be safe, I would add ASSERT(gic == node);
>>
>>> +
>>> +    tmp = (__be32 *) dt_get_property(gic, "reg", &len);
>>
>> The cast is not necessary.
>>
>>> +    if ( !tmp )
>>> +    {
>>> +        dprintk(XENLOG_ERR, "Can't find reg property for the gic
>> node\n");
>>> +        return -FDT_ERR_XEN(ENOENT);
>>> +    }
>>> +
>>> +    len = dt_cells_to_size(na + ns);
>>>      len *= 2; /* GIC has two memory regions: Distributor + CPU
>> interface */
>>>      new_cells = xzalloc_bytes(len);
>>>      if ( new_cells == NULL )
>>>          return -FDT_ERR_XEN(ENOMEM);
>>>
>>> -    tmp = new_cells;
>>> -    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
>>> -    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
>>> +    memcpy(new_cells, tmp, len);
>>
>> You don't need to copy the data in the temporary variable. You can
>> directly use fdt_property with the right len. Smth like:
>>
>> fdt_property(fdt, "reg", tmp, len);
>>
>> Regards,
>>
>> --
>> Julien Grall
> 
> This then should look much better.
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 2f6bbd5..9b9e696 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -629,9 +629,8 @@ static int gicv2_make_dt_node(const struct domain *d,
>                                const struct dt_device_node *node, void *fdt)
>  {
>      const struct dt_device_node *gic = dt_interrupt_controller;
> -    const void *compatible = NULL;
> +    const void *compatible = NULL, *tmp;
>      u32 len;
> -    __be32 *new_cells, *tmp;

I would prefer if you keep tmp as __be32 *. It documents the real type
of the data. Also, for clarity, I would rename it to cells.

BTW, the commit title/message wasn't really clear. It make thinks you
are fixing the problem for everyone and not only the GICv2.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 15:52:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 15:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm2sY-0007Mf-2W; Wed, 05 Nov 2014 15:52:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm2sW-0007MO-6C
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 15:52:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	27/5B-09936-BA74A545; Wed, 05 Nov 2014 15:52:11 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415202731!9568868!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22279 invoked from network); 5 Nov 2014 15:52:11 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 15:52:11 -0000
Received: by mail-wi0-f181.google.com with SMTP id n3so2411331wiv.14
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 07:52:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=ObzkOFpfhTkg7RuU9OgTxgwOpjFYEiq6Wpw1WVmOVyY=;
	b=EmYT11mIeJzlu/gDHCTKbMP2ANRG0+ZBvFMLnbNK8Zi+nMrZOPqRJ+i9tRATVkbmJc
	/M0bXn6z0tdTL+E4Q7fGIpMzYxQlhZJobthamRLaxXFlptVVuO3FKk3HKDf5R37YxPwx
	o3LXPKtzuu1Hxr/thnTzWw+MoNVHIXIjA4FQWHC+TwUHNY9Ln+TbEaZhoOF1z/9QiIdq
	jcXaoYICTuz3jrnmIJJ3wProHF8dJ2kQb3kuEFSLhGZkiXYaEtIbcENZDzKbaZ87u2P7
	HlOgp6tz57w/cKMBMIp1CuniQgTrEikgz3IcG0/z8STz0Q5rYimF1cyN4CHaDC4vWIPX
	o6uQ==
X-Gm-Message-State: ALoCoQmF/062UxPRokjNb92x9kH8RgRXJz5WQVSHFthOPDzXI6+MXZOZDy3ZJSLpWwmF74GN8mWW
X-Received: by 10.194.57.81 with SMTP id g17mr68066288wjq.12.1415202731042;
	Wed, 05 Nov 2014 07:52:11 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	ny6sm16212710wic.22.2014.11.05.07.52.09 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 07:52:10 -0800 (PST)
Message-ID: <545A47A3.6090707@linaro.org>
Date: Wed, 05 Nov 2014 15:52:03 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
	<545A4230.9030506@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B3CE@lhreml509-mbb>
	<545A4782.3050107@linaro.org>
In-Reply-To: <545A4782.3050107@linaro.org>
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/05/2014 03:51 PM, Julien Grall wrote:
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index 2f6bbd5..9b9e696 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -629,9 +629,8 @@ static int gicv2_make_dt_node(const struct domain *d,
>>                                const struct dt_device_node *node, void *fdt)
>>  {
>>      const struct dt_device_node *gic = dt_interrupt_controller;
>> -    const void *compatible = NULL;
>> +    const void *compatible = NULL, *tmp;
>>      u32 len;
>> -    __be32 *new_cells, *tmp;
> 
> I would prefer if you keep tmp as __be32 *. It documents the real type
> of the data. Also, for clarity, I would rename it to cells.

s/cells/regs/.  Sorry

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 15:52:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 15:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm2sY-0007Mf-2W; Wed, 05 Nov 2014 15:52:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm2sW-0007MO-6C
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 15:52:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	27/5B-09936-BA74A545; Wed, 05 Nov 2014 15:52:11 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415202731!9568868!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22279 invoked from network); 5 Nov 2014 15:52:11 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 15:52:11 -0000
Received: by mail-wi0-f181.google.com with SMTP id n3so2411331wiv.14
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 07:52:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=ObzkOFpfhTkg7RuU9OgTxgwOpjFYEiq6Wpw1WVmOVyY=;
	b=EmYT11mIeJzlu/gDHCTKbMP2ANRG0+ZBvFMLnbNK8Zi+nMrZOPqRJ+i9tRATVkbmJc
	/M0bXn6z0tdTL+E4Q7fGIpMzYxQlhZJobthamRLaxXFlptVVuO3FKk3HKDf5R37YxPwx
	o3LXPKtzuu1Hxr/thnTzWw+MoNVHIXIjA4FQWHC+TwUHNY9Ln+TbEaZhoOF1z/9QiIdq
	jcXaoYICTuz3jrnmIJJ3wProHF8dJ2kQb3kuEFSLhGZkiXYaEtIbcENZDzKbaZ87u2P7
	HlOgp6tz57w/cKMBMIp1CuniQgTrEikgz3IcG0/z8STz0Q5rYimF1cyN4CHaDC4vWIPX
	o6uQ==
X-Gm-Message-State: ALoCoQmF/062UxPRokjNb92x9kH8RgRXJz5WQVSHFthOPDzXI6+MXZOZDy3ZJSLpWwmF74GN8mWW
X-Received: by 10.194.57.81 with SMTP id g17mr68066288wjq.12.1415202731042;
	Wed, 05 Nov 2014 07:52:11 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	ny6sm16212710wic.22.2014.11.05.07.52.09 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 07:52:10 -0800 (PST)
Message-ID: <545A47A3.6090707@linaro.org>
Date: Wed, 05 Nov 2014 15:52:03 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@huawei.com>, 
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
	<545A4230.9030506@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B3CE@lhreml509-mbb>
	<545A4782.3050107@linaro.org>
In-Reply-To: <545A4782.3050107@linaro.org>
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/05/2014 03:51 PM, Julien Grall wrote:
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index 2f6bbd5..9b9e696 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -629,9 +629,8 @@ static int gicv2_make_dt_node(const struct domain *d,
>>                                const struct dt_device_node *node, void *fdt)
>>  {
>>      const struct dt_device_node *gic = dt_interrupt_controller;
>> -    const void *compatible = NULL;
>> +    const void *compatible = NULL, *tmp;
>>      u32 len;
>> -    __be32 *new_cells, *tmp;
> 
> I would prefer if you keep tmp as __be32 *. It documents the real type
> of the data. Also, for clarity, I would rename it to cells.

s/cells/regs/.  Sorry

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 16:02:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm32N-0008He-8p; Wed, 05 Nov 2014 16:02:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xm32M-0008HZ-9P
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 16:02:22 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	40/F9-27623-D0A4A545; Wed, 05 Nov 2014 16:02:21 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415203339!11862596!1
X-Originating-IP: [206.16.17.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjE2LjE3LjcyID0+IDE2MDI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23151 invoked from network); 5 Nov 2014 16:02:20 -0000
Received: from dfwrgout.huawei.com (HELO dfwrgout.huawei.com) (206.16.17.72)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 16:02:20 -0000
Received: from 172.18.9.243 (EHLO lhreml406-hub.china.huawei.com)
	([172.18.9.243])
	by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CHR84505; Wed, 05 Nov 2014 10:02:16 -0600 (CST)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id
	14.03.0158.001; Wed, 5 Nov 2014 16:02:07 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v3 8/8] xen/arm: Handle translated addresses for
	hardware domains
Thread-Index: AQHP+Nz5JXxbZDhNFky+GUtoHCI5CpxSFRmAgAAOuCCAAATYAIAABJGggAABxgCAAAAogIAAAk0w
Date: Wed, 5 Nov 2014 16:02:06 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B3E4@lhreml509-mbb>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
	<545A4230.9030506@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B3CE@lhreml509-mbb>
	<545A4782.3050107@linaro.org> <545A47A3.6090707@linaro.org>
In-Reply-To: <545A47A3.6090707@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.71.64]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On 11/05/2014 03:51 PM, Julien Grall wrote:
> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> >> 2f6bbd5..9b9e696 100644
> >> --- a/xen/arch/arm/gic-v2.c
> >> +++ b/xen/arch/arm/gic-v2.c
> >> @@ -629,9 +629,8 @@ static int gicv2_make_dt_node(const struct
> domain *d,
> >>                                const struct dt_device_node *node,
> >> void *fdt)  {
> >>      const struct dt_device_node *gic = dt_interrupt_controller;
> >> -    const void *compatible = NULL;
> >> +    const void *compatible = NULL, *tmp;
> >>      u32 len;
> >> -    __be32 *new_cells, *tmp;
> >
> > I would prefer if you keep tmp as __be32 *. It documents the real
> type
> > of the data. Also, for clarity, I would rename it to cells.
> 
> s/cells/regs/.  Sorry
> 
> --
> Julien Grall

This version should be perfect then.


Subject: [PATCH 7/7] xen/arm: Handle translated addresses for hardware domains in GICv2

Translated address could have an offset applied to them.
Replicate same value for device node to avoid improper address
computation in the OS.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2f6bbd5..c2666df 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -631,7 +631,7 @@ static int gicv2_make_dt_node(const struct domain *d,
     const struct dt_device_node *gic = dt_interrupt_controller;
     const void *compatible = NULL;
     u32 len;
-    __be32 *new_cells, *tmp;
+    const __be32 *regs;
     int res = 0;
 
     compatible = dt_get_property(gic, "compatible", &len);
@@ -664,18 +664,18 @@ static int gicv2_make_dt_node(const struct domain *d,
     if ( res )
         return res;
 
+    /* copy GICC and GICD regions */
+    regs = dt_get_property(gic, "reg", &len);
+    if ( !regs )
+    {
+        dprintk(XENLOG_ERR, "Can't find reg property for the gic node\n");
+        return -FDT_ERR_XEN(ENOENT);
+    }
+
     len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
     len *= 2; /* GIC has two memory regions: Distributor + CPU interface */
-    new_cells = xzalloc_bytes(len);
-    if ( new_cells == NULL )
-        return -FDT_ERR_XEN(ENOMEM);
-
-    tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
 
-    res = fdt_property(fdt, "reg", new_cells, len);
-    xfree(new_cells);
+    res = fdt_property(fdt, "reg", regs, len);
 
     return res;
 }
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 16:02:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm32N-0008He-8p; Wed, 05 Nov 2014 16:02:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1Xm32M-0008HZ-9P
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 16:02:22 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	40/F9-27623-D0A4A545; Wed, 05 Nov 2014 16:02:21 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415203339!11862596!1
X-Originating-IP: [206.16.17.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjE2LjE3LjcyID0+IDE2MDI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23151 invoked from network); 5 Nov 2014 16:02:20 -0000
Received: from dfwrgout.huawei.com (HELO dfwrgout.huawei.com) (206.16.17.72)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 16:02:20 -0000
Received: from 172.18.9.243 (EHLO lhreml406-hub.china.huawei.com)
	([172.18.9.243])
	by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CHR84505; Wed, 05 Nov 2014 10:02:16 -0600 (CST)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id
	14.03.0158.001; Wed, 5 Nov 2014 16:02:07 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Ian Campbell
	<ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [PATCH v3 8/8] xen/arm: Handle translated addresses for
	hardware domains
Thread-Index: AQHP+Nz5JXxbZDhNFky+GUtoHCI5CpxSFRmAgAAOuCCAAATYAIAABJGggAABxgCAAAAogIAAAk0w
Date: Wed, 5 Nov 2014 16:02:06 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17B3E4@lhreml509-mbb>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-9-git-send-email-frediano.ziglio@huawei.com>
	<545A31C7.3070202@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B396@lhreml509-mbb>
	<545A4230.9030506@linaro.org>
	<B944B469BF5302468AC6EB05E56CC70D17B3CE@lhreml509-mbb>
	<545A4782.3050107@linaro.org> <545A47A3.6090707@linaro.org>
In-Reply-To: <545A47A3.6090707@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.71.64]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 8/8] xen/arm: Handle translated addresses
 for hardware domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On 11/05/2014 03:51 PM, Julien Grall wrote:
> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index
> >> 2f6bbd5..9b9e696 100644
> >> --- a/xen/arch/arm/gic-v2.c
> >> +++ b/xen/arch/arm/gic-v2.c
> >> @@ -629,9 +629,8 @@ static int gicv2_make_dt_node(const struct
> domain *d,
> >>                                const struct dt_device_node *node,
> >> void *fdt)  {
> >>      const struct dt_device_node *gic = dt_interrupt_controller;
> >> -    const void *compatible = NULL;
> >> +    const void *compatible = NULL, *tmp;
> >>      u32 len;
> >> -    __be32 *new_cells, *tmp;
> >
> > I would prefer if you keep tmp as __be32 *. It documents the real
> type
> > of the data. Also, for clarity, I would rename it to cells.
> 
> s/cells/regs/.  Sorry
> 
> --
> Julien Grall

This version should be perfect then.


Subject: [PATCH 7/7] xen/arm: Handle translated addresses for hardware domains in GICv2

Translated address could have an offset applied to them.
Replicate same value for device node to avoid improper address
computation in the OS.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2f6bbd5..c2666df 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -631,7 +631,7 @@ static int gicv2_make_dt_node(const struct domain *d,
     const struct dt_device_node *gic = dt_interrupt_controller;
     const void *compatible = NULL;
     u32 len;
-    __be32 *new_cells, *tmp;
+    const __be32 *regs;
     int res = 0;
 
     compatible = dt_get_property(gic, "compatible", &len);
@@ -664,18 +664,18 @@ static int gicv2_make_dt_node(const struct domain *d,
     if ( res )
         return res;
 
+    /* copy GICC and GICD regions */
+    regs = dt_get_property(gic, "reg", &len);
+    if ( !regs )
+    {
+        dprintk(XENLOG_ERR, "Can't find reg property for the gic node\n");
+        return -FDT_ERR_XEN(ENOENT);
+    }
+
     len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
     len *= 2; /* GIC has two memory regions: Distributor + CPU interface */
-    new_cells = xzalloc_bytes(len);
-    if ( new_cells == NULL )
-        return -FDT_ERR_XEN(ENOMEM);
-
-    tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
 
-    res = fdt_property(fdt, "reg", new_cells, len);
-    xfree(new_cells);
+    res = fdt_property(fdt, "reg", regs, len);
 
     return res;
 }
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 16:36:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm3ZZ-0000UC-88; Wed, 05 Nov 2014 16:36:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm3ZX-0000U5-IA
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 16:36:39 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	65/F9-02702-6125A545; Wed, 05 Nov 2014 16:36:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415205395!12781609!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11378 invoked from network); 5 Nov 2014 16:36:37 -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;
	5 Nov 2014 16:36:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="188397149"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 11:36:22 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm3ZF-0005hU-J7;
	Wed, 05 Nov 2014 16:36:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm3ZD-00072Y-CR;
	Wed, 05 Nov 2014 16:36:19 +0000
Date: Wed, 5 Nov 2014 16:36:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31382-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31382: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31382 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31382/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf                   3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-armhf-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                980d0d51b1c9617a472b2c0fcbe33d2d15eadc4c
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
349 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  broken  
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          blocked 
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf host-install(3)

Not pushing.

(No revision log; it would be 11318 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 Nov 05 16:36:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm3ZZ-0000UC-88; Wed, 05 Nov 2014 16:36:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm3ZX-0000U5-IA
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 16:36:39 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	65/F9-02702-6125A545; Wed, 05 Nov 2014 16:36:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415205395!12781609!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11378 invoked from network); 5 Nov 2014 16:36:37 -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;
	5 Nov 2014 16:36:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="188397149"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 11:36:22 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm3ZF-0005hU-J7;
	Wed, 05 Nov 2014 16:36:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm3ZD-00072Y-CR;
	Wed, 05 Nov 2014 16:36:19 +0000
Date: Wed, 5 Nov 2014 16:36:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31382-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31382: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31382 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31382/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf                   3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-armhf-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                980d0d51b1c9617a472b2c0fcbe33d2d15eadc4c
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
349 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  broken  
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          blocked 
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf host-install(3)

Not pushing.

(No revision log; it would be 11318 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 Nov 05 16:41:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16:41:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm3eY-0000iD-Vx; Wed, 05 Nov 2014 16:41:50 +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 1Xm3eX-0000i3-4U
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 16:41:49 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	85/59-09284-C435A545; Wed, 05 Nov 2014 16:41:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415205705!11898605!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16067 invoked from network); 5 Nov 2014 16:41:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 16:41:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="188399416"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 11:41:42 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xm3eP-0003sh-R8;
	Wed, 05 Nov 2014 16:41:41 +0000
Date: Wed, 5 Nov 2014 16:41:41 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <linux-kernel@vger.kernel.org>, <mgorman@suse.de>,
	<akpm@linux-foundation.org>, <hughd@google.com>
Message-ID: <20141105164141.GA27834@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, wei.liu2@citrix.com,
	david.vrabel@citrix.com, xen-devel@lists.xen.org
Subject: [Xen-devel] Pte_special broken on Xen PV when NUMA balancing is
	enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all

I'm developing virtual NUMA support for Xen. One thing I notice is that when
NUMA balancing is enabled, kernel will crash with following backtrace.

[  404.281396] CPU: 0 PID: 1058 Comm: dd Tainted: G    B   W      3.18.0-rc3-bp+ #3
[  404.281403]  0000000000000000 00007fd62eca3000 ffffffff817b7cac ffff880172d298b8
[  404.281415]  ffffffff8110383f 0720072007300732 00000007fd62eca3 0720072007200720
[  404.281426]  ffff880172d298b8 ffff88017300bbb0 00007fd62eca3000 0000000000000000
[  404.281437] Call Trace:                                                      
[  404.281444]  [<ffffffff817b7cac>] ? dump_stack+0x41/0x51                     
[  404.281452]  [<ffffffff8110383f>] ? print_bad_pte+0x19f/0x1cb                
[  404.281460]  [<ffffffff81104479>] ? vm_normal_page+0x51/0x87                 
[  404.281469]  [<ffffffff8110c5ef>] ? change_protection+0x4fb/0x76a            
[  404.281477]  [<ffffffff81106435>] ? handle_mm_fault+0x9e0/0xa11              
[  404.281486]  [<ffffffff8111cc22>] ? change_prot_numa+0x13/0x24               
[  404.281495]  [<ffffffff8106abf0>] ? task_numa_work+0x20c/0x2ac               
[  404.281503]  [<ffffffff810615e7>] ? finish_task_switch+0x83/0xc5             
[  404.281512]  [<ffffffff8105af10>] ? task_work_run+0x7b/0x8f                  
[  404.281521]  [<ffffffff8100d732>] ? do_notify_resume+0x5a/0x6d               
[  404.281529]  [<ffffffff817bf49f>] ? retint_signal+0x48/0x89                  
[  404.281537]  [<ffffffff810012eb>] ? xen_hypercall_iret+0xb/0x20

Decoding page flags 0x366 we have _PAGE_SPECIAL(_PAGE_NUMA) and
_PAGE_GLOBAL(_PAGE_PROTNONE) set, _PAGE_PRESENT not set. It's handling
a NUMA hint page fault and crashes because the PTE in question is
considered a special PTE by pte_special.

In a Xen PV guest, _PAGE_GLOBAL is added by hypervisor to mark the page
a guest user space page. Xen PV kernel has already forbidden setting
that bit during initialisation. It's a bit unfortunate that there's
still clash with _PAGE_PROTNONE.

Wei.

P.S.  Interestingly, in b38af4721 ("x86,mm: fix pte_special versus
pte_numa"), the commit which changed pte_special, Hugh (the author)
wrote "It still appears that this patch may be incomplete: aren't there
other places which need to be handling PROTNONE along with PRESENT?"
Looks like now we have a case -- Xen PV -- that PROTNONE and PRESENT
co-exist.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 16:41:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16:41:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm3eY-0000iD-Vx; Wed, 05 Nov 2014 16:41:50 +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 1Xm3eX-0000i3-4U
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 16:41:49 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	85/59-09284-C435A545; Wed, 05 Nov 2014 16:41:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415205705!11898605!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16067 invoked from network); 5 Nov 2014 16:41:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 16:41:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="188399416"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 11:41:42 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xm3eP-0003sh-R8;
	Wed, 05 Nov 2014 16:41:41 +0000
Date: Wed, 5 Nov 2014 16:41:41 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <linux-kernel@vger.kernel.org>, <mgorman@suse.de>,
	<akpm@linux-foundation.org>, <hughd@google.com>
Message-ID: <20141105164141.GA27834@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, wei.liu2@citrix.com,
	david.vrabel@citrix.com, xen-devel@lists.xen.org
Subject: [Xen-devel] Pte_special broken on Xen PV when NUMA balancing is
	enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all

I'm developing virtual NUMA support for Xen. One thing I notice is that when
NUMA balancing is enabled, kernel will crash with following backtrace.

[  404.281396] CPU: 0 PID: 1058 Comm: dd Tainted: G    B   W      3.18.0-rc3-bp+ #3
[  404.281403]  0000000000000000 00007fd62eca3000 ffffffff817b7cac ffff880172d298b8
[  404.281415]  ffffffff8110383f 0720072007300732 00000007fd62eca3 0720072007200720
[  404.281426]  ffff880172d298b8 ffff88017300bbb0 00007fd62eca3000 0000000000000000
[  404.281437] Call Trace:                                                      
[  404.281444]  [<ffffffff817b7cac>] ? dump_stack+0x41/0x51                     
[  404.281452]  [<ffffffff8110383f>] ? print_bad_pte+0x19f/0x1cb                
[  404.281460]  [<ffffffff81104479>] ? vm_normal_page+0x51/0x87                 
[  404.281469]  [<ffffffff8110c5ef>] ? change_protection+0x4fb/0x76a            
[  404.281477]  [<ffffffff81106435>] ? handle_mm_fault+0x9e0/0xa11              
[  404.281486]  [<ffffffff8111cc22>] ? change_prot_numa+0x13/0x24               
[  404.281495]  [<ffffffff8106abf0>] ? task_numa_work+0x20c/0x2ac               
[  404.281503]  [<ffffffff810615e7>] ? finish_task_switch+0x83/0xc5             
[  404.281512]  [<ffffffff8105af10>] ? task_work_run+0x7b/0x8f                  
[  404.281521]  [<ffffffff8100d732>] ? do_notify_resume+0x5a/0x6d               
[  404.281529]  [<ffffffff817bf49f>] ? retint_signal+0x48/0x89                  
[  404.281537]  [<ffffffff810012eb>] ? xen_hypercall_iret+0xb/0x20

Decoding page flags 0x366 we have _PAGE_SPECIAL(_PAGE_NUMA) and
_PAGE_GLOBAL(_PAGE_PROTNONE) set, _PAGE_PRESENT not set. It's handling
a NUMA hint page fault and crashes because the PTE in question is
considered a special PTE by pte_special.

In a Xen PV guest, _PAGE_GLOBAL is added by hypervisor to mark the page
a guest user space page. Xen PV kernel has already forbidden setting
that bit during initialisation. It's a bit unfortunate that there's
still clash with _PAGE_PROTNONE.

Wei.

P.S.  Interestingly, in b38af4721 ("x86,mm: fix pte_special versus
pte_numa"), the commit which changed pte_special, Hugh (the author)
wrote "It still appears that this patch may be incomplete: aren't there
other places which need to be handling PROTNONE along with PRESENT?"
Looks like now we have a case -- Xen PV -- that PROTNONE and PRESENT
co-exist.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 16:56:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16: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 1Xm3s3-00018e-DI; Wed, 05 Nov 2014 16:55:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xm3s1-00018X-Qk
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 16:55:46 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	AC/10-22777-1965A545; Wed, 05 Nov 2014 16:55:45 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415206537!6126102!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6751 invoked from network); 5 Nov 2014 16:55:37 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-10.tower-206.messagelabs.com with SMTP;
	5 Nov 2014 16:55:37 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 05 Nov 2014 08:49:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,320,1413270000"; d="scan'208";a="617658064"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by fmsmga001.fm.intel.com with ESMTP; 05 Nov 2014 08:55:32 -0800
Received: from kmsmsx152.gar.corp.intel.com (172.21.73.87) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 00:55:32 +0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 00:55:31 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id
	14.03.0195.001; Thu, 6 Nov 2014 00:55:30 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP91zOKlhH4xypD06jTqC2+4O7eZxQng+ggAC8ygCAAMpkkA==
Date: Wed, 5 Nov 2014 16:55:30 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8202B7@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411051036310.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411051036310.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Wednesday, November 05, 2014 7:01 PM
> To: Xu, Quan
> Cc: Stefano Stabellini; qemu-devel@nongnu.org; xen-devel@lists.xen.org
> Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> On Tue, 4 Nov 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Monday, November 03, 2014 7:54 PM
> > > To: Xu, Quan
> > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > > stefano.stabellini@eu.citrix.com
> > > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > > frontend driver
> > >
> > > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > > This drvier transfers any request/repond between TPM xenstubdoms
> > > > driver and Xen vTPM stubdom, and facilitates communications
> > > > between Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > > >
> > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > >
> > > Please describe what changes did make to xen_backend.c and why.
> > > The commit message should contains info on all the changes made by
> > > the patch below.
> > >
> >
> > Thanks Stefano.
> > one more day, I will explain in detail what changes did make to
> > xen_backend.c and why.
> > The following 2 sections are introduction and architecture.
> >
> > > Please also describe what is the "Xen vTPM stubdom", what is the
> > > "vTPM xenstubdoms driver" and how the communicate with each others.
> > >
> >
> >
> > Add 2 parts for detailed descriptions, introduction and architecture.
> >
> > *INTRODUCTION*
> >
> > The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM
> > functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows
> > .etc). This allows programs to interact with a TPM in a virtual
> > machine the same way they interact with a TPM on the physical system.
> Each virtual machine gets its own unique, emulated, software TPM.
> > Each major component of vTPM is implemented as a stubdom, providing
> > secure separation guaranteed by the hypervisor.
> > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the
> > virtual machine to use. It is a small wrapper around the Berlios TPM
> > emulator. TPM commands are passed from mini-os TPM backend driver.
> > This patch series are only the Qemu part to enable Xen stubdom vTPM
> > for HVM virtual machine.
> > ===========
> >
> > *ARCHITECTURE*
> >
> > The architecture of stubdom vTPM for HVM virtual machine:
> >
> >             +--------------------+
> >             | Windows/Linux DomU | ...
> >             |        |  ^        |
> >             |        v  |        |
> >             |  Qemu tpm1.2 Tis   |
> >             |        |  ^        |
> >             |        v  |        |
> >             |        vTPM        |
> >             | XenStubdoms driver |  (new ..)
> >             +--------------------+
> >                      |  ^
> >                      v  |
> >             +--------------------+
> >             |  xen_vtpmdev_ops   |  (new ..)
> >             +--------------------+
> >                      |  ^
> >                      v  |
> >             +--------------------+
> >             |  mini-os/tpmback   |
> >             |        |  ^        |
> >             |        v  |        |
> >             |   vTPM stubdom     | ...
> >             |        |  ^        |
> >             |        v  |        |
> >             |  mini-os/tpmfront  |
> >             +--------------------+
> >                      |  ^
> >                      v  |
> >             +--------------------+
> >             |  mini-os/tpmback   |
> >             |        |  ^        |
> >             |        v  |        |
> >             |  vtpmmgr stubdom   |
> >             |        |  ^        |
> >             |        v  |        |
> >             |  mini-os/tpm_tis   |
> >             +--------------------+
> >                      |  ^
> >                      v  |
> >             +--------------------+
> >             |    Hardware TPM    |
> >             +--------------------+
> >
> >
> > * Windows/Linux DomU:
> >     The HVM based guest that wants to use a vTPM. There may be
> >     more than one of these.
> >
> >  * Qemu tpm1.2 Tis:
> >     Implementation of the tpm1.2 Tis interface for HVM virtual
> >     machines. It is Qemu emulation device.
> 
> It looks like you are running upstream QEMU within a Mini-OS stubdom?
> If so, where are the patches to do that? As far as I know upstream QEMU
> doesn't run on Mini-OS. Or maybe it is a Linux stubdom? Either way, it is not
> clear.

Not so.
Refer to below further explanation. 

> 
> 
> >  * vTPM xenstubdoms driver:
> >     Similar to a TPM passthrough backend driver, it is a new TPM
> >     backend for emulated TPM TIS interface. This driver provides
> >     vTPM initialization and sending data and commends to a Xen
> >     vTPM stubdom.
> 
> This is patch #3, right? It is basically the internal QEMU "glue" to connect the
> tpm emulator to xen_vtpmdev_ops, correct?
> 

Yes, it is Patch #3. Agree with your description.  :)

> 
> >  * xen_vtpmdev_ops:
> >     Register Xen stubdom vTPM backend, and transfer any request/
> >     repond between TPM xenstubdoms driver and Xen vTPM stubdom.
> >     Facilitate communications between Xen vTPM stubdom and vTPM
> >     xenstubdoms driver.
> 
> It looks like this correspond to patch #2? If so, this is a regular Xen PV

Yes, it patch #2.


> frontend, living in QEMU? It requires the gntalloc device so I guess it is
> supposed to run on Linux. In that case is it just a tpmfront implementation in
> QEMU?
> 


Yes, it's tpmfront implementation in Qemu. also it supports PV Linux since Xen 4.3.0.
vTPM stubdom / vtpmmgr stubdom  ware implemented by Matthew Fioravante (JHUAPL),
Linux pv vTPM frontend was implemented by Daniel De Graaf (NSA)



> If you are running it on Linux, we might need to introduce Linux based
> stundoms to the Xen build system.

Not so.
Maybe I should explain a bit further. TPM is a character device. 'Qemu tpm1.2 Tis'
Implement some TPM register hook of TPM, and enable TIS (TPM interface Specification).
The ' Qemu tpm1.2 Tis ' should deal with TPM commands. 

Such as TPM_ContinueSelfTest command,
    { 0x00, 0xc1, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x53};
If success, the TPM will respond,
    { 0x00, 0xc4, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x00};

Qemu upstream has supported TPM passthrough. actually, 'Qemu TPM passthrough' send 
These TPM commands from "Qemu tpm1.2 Tis" to TPM hardware, and get the respond. 

" [PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for HVM virtual machine " send 
These TPM commands from "Qemu tpm1.2 Tis" to Xen stubdom( explain in previous email)
And get the respond. 

#(qemu-system-* --tpmdev help)
#(passthrough   Passthrough TPM backend driver)
#( xenstubdoms  Xenstubdoms TPM backend driver)

The following is Qemu part.

            |        |  ^       |
            |        v  |       |
            |        vTPM      |
            | XenStubdoms driver |  (new ..)
            +------------------------------+
                     |  ^
                     v  |
            +------------------------------+
            |  xen_vtpmdev_ops  |  (new ..)
            +------------------------------+
"vTPM XenStubdoms driver" and "xen_vtpmdev_ops" are implemented to send These TPM commands 
from "Qemu tpm1.2 Tis" to Xen stubdom.

> 
> 
> >  * mini-os/tpmback:
> >     Mini-os TPM backend driver. The Linux frontend driver connects
> >     to this backend driver to facilitate communications between the
> >     Linux DomU and its vTPM. This driver is also used by vtpmmgr
> >     stubdom to communicate with vTPM stubdom.
> >
> >  * vTPM stubdom:
> >     A mini-os stub domain that implements a vTPM. There is a
> >     one to one mapping between running vTPM stubdom instances and
> >     logical vTPMs on the system. The vTPM Platform Configuration
> >     Registers (PCRs) are all initialized to zero.
> >
> >  * mini-os/tpmfront:
> >     Mini-os TPM frontend driver. The vTPM mini-os domain vTPM
> >     stubdom uses this driver to communicate with vtpmmgr-stubdom.
> >     This driver could also be used separately to implement a mini-os
> >     domain that wishes to use a vTPM of its own.
> >
> >  * vtpmmgr stubdom:
> >     A mini-os domain that implements the vTPM manager. There is only
> >     one vTPM manager and it should be running during the entire lifetime
> >     of the machine. vtpmmgr domain securely stores encryption keys for
> >     each of the vTPMs and accesses to the hardware TPM to get the root
> of
> >     trust for the entire system.
> >
> >  * mini-os/tpm_tis:
> >     Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
> >     This driver used by vtpmmgr-stubdom to talk directly to the hardware
> >     TPM. Communication is facilitated by mapping hardware memory
> pages
> >     into vtpmmgr stubdom.
> 
> Are all the Mini-OS component upstream, or do we need patches?
> 
> 
> >  * Hardware TPM:
> >     The physical TPM 1.2 that is soldered onto the motherboard.
> >
> > ===========
> >
> >
> >
> > > Where does the vTPM backend lives?
> > The vTPM backend lives in Xen vTPM stubdom (Xen Mini-os)
> 
> Thanks for the explanation, it is a bit clearer now.
> 


Welcome, thanks for your careful review. 



> 
> > >
> > >
> > > >  hw/xen/Makefile.objs         |   1 +
> > > >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> > > >  hw/xen/xen_stubdom_vtpm.c    | 333
> > > +++++++++++++++++++++++++++++++++++++++++++
> > > >  include/hw/xen/xen_backend.h |  11 ++
> > > >  include/hw/xen/xen_common.h  |   6 +
> > > >  xen-hvm.c                    |  13 ++
> > > >  6 files changed, 544 insertions(+), 2 deletions(-)  create mode
> > > > 100644 hw/xen/xen_stubdom_vtpm.c
> > > >
> > > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs index
> > > > a0ca0aa..724df8d 100644
> > > > --- a/hw/xen/Makefile.objs
> > > > +++ b/hw/xen/Makefile.objs
> > > > @@ -1,5 +1,6 @@
> > > >  # xen backend driver support
> > > >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> > > xen_devconfig.o
> > > > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) +=
> xen_stubdom_vtpm.o
> > > >
> > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> > > xen_pt_config_init.o xen_pt_msi.o
> > > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index
> > > > b2cb22b..45a5778 100644
> > > > --- a/hw/xen/xen_backend.c
> > > > +++ b/hw/xen/xen_backend.c
> > > > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice
> > > > *xendev,
> > > enum xenbus_state state)
> > > >      return 0;
> > > >  }
> > > >
> > > > +/*get stubdom backend*/
> > > > +static char *xen_stubdom_be(const char *type, int dom, int dev) {
> > > > +    char *val, *domu;
> > > > +    char path[XEN_BUFSIZE];
> > > > +    unsigned int len, ival;
> > > > +
> > > > +    /*front domu*/
> > > > +    domu = xs_get_domain_path(xenstore, dom);
> > > > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > > > +             domu, type, dev);
> > > > +    g_free(domu);
> > > > +
> > > > +    val = xs_read(xenstore, 0, path, &len);
> > > > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > > > +        g_free(val);
> > > > +        return NULL;
> > > > +    }
> > > > +    g_free(val);
> > > > +
> > > > +    /*backend domu*/
> > > > +    domu = xs_get_domain_path(xenstore, ival);
> > > > +
> > > > +    return domu;
> > > > +}
> > > > +
> > > >  /* -------------------------------------------------------------
> > > > */
> > > >
> > > >  struct XenDevice *xen_be_find_xendev(const char *type, int dom,
> > > > int
> > > dev)
> > > > @@ -222,6 +248,7 @@ static struct XenDevice
> > > > *xen_be_get_xendev(const
> > > char *type, int dom, int dev,
> > > >                                             struct XenDevOps
> *ops)
> > > > {
> > > >      struct XenDevice *xendev;
> > > > +    char *stub;
> > > >
> > > >      xendev = xen_be_find_xendev(type, dom, dev);
> > > >      if (xendev) {
> > > > @@ -235,8 +262,15 @@ static struct XenDevice
> > > *xen_be_get_xendev(const char *type, int dom, int dev,
> > > >      xendev->dev   = dev;
> > > >      xendev->ops   = ops;
> > > >
> > > > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > > > -             xendev->type, xendev->dom, xendev->dev);
> > > > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > > > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> > > xendev->dev);
> > > > +        snprintf(xendev->be, sizeof(xendev->be),
> > > "%s/backend/%s/%d/%d",
> > > > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > > > +        g_free(stub);
> > > > +    } else {
> > > > +        snprintf(xendev->be, sizeof(xendev->be),
> "backend/%s/%d/%d",
> > > > +                 xendev->type, xendev->dom, xendev->dev);
> > > > +    }
> > > >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> > > >               xendev->type, xendev->dev);
> > > >
> > > > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type,
> > > > int
> > > dom, struct XenDevOps *ops)
> > > >      return 0;
> > > >  }
> > > >
> > > > +static void stubdom_update_be(char *watch, char *type, int dom,
> > > > +                              struct XenDevOps *ops) {
> > > > +    struct XenDevice *xendev;
> > > > +    char path[XEN_BUFSIZE];
> > > > +    char *ptr, *bepath;
> > > > +    unsigned int len, dev;
> > > > +
> > > > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > > > +        return;
> > > > +    }
> > > > +
> > > > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > > > +    ptr = strstr(watch, path);
> > > > +    if (ptr == NULL) {
> > > > +        return;
> > > > +    }
> > > > +
> > > > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > > > +        strcpy(path, "");
> > > > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > > > +            dev = -1;
> > > > +        }
> > > > +    }
> > > > +
> > > > +    if (dev == -1) {
> > > > +        return;
> > > > +    }
> > > > +
> > > > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > > > +    if (xendev != NULL) {
> > > > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > > > +        if (bepath == NULL) {
> > > > +            xen_be_del_xendev(dom, dev);
> > > > +        } else {
> > > > +            free(bepath);
> > > > +            xen_be_backend_changed(xendev, path);
> > > > +        }
> > > > +    }
> > > > +}
> > > > +
> > > >  static void xenstore_update_be(char *watch, char *type, int dom,
> > > >                                 struct XenDevOps *ops)  { @@
> > > > -681,6 +756,10 @@ static void xenstore_update(void *unused)
> > > >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> > > >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> > > >      }
> > > > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> > > PRIxPTR,
> > > > +               &type, &dom, &ops) == 3) {
> > > > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type,
> dom,
> > > (void *)ops);
> > > > +    }
> > > >
> > > >  cleanup:
> > > >      free(vec);
> > > > @@ -732,11 +811,74 @@ err:
> > > >      return -1;
> > > >  }
> > > >
> > > > +int xen_vtpm_register(struct XenDevOps *ops) {
> > > > +    struct XenDevice *xendev;
> > > > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > > > +    char *domu;
> > > > +    unsigned int cdev, j, rc;
> > > > +    const char *type = "vtpm";
> > > > +    char **dev = NULL;
> > > > +
> > > > +    /*front domu*/
> > > > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > > > +    snprintf(path, sizeof(path), "%s/device/%s",
> > > > +             domu, type);
> > > > +    free(domu);
> > > > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > > > +    if (dev == NULL) {
> > > > +        return 0;
> > > > +    }
> > > > +
> > > > +    for (j = 0; j < cdev; j++) {
> > > > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> > > ops);
> > > > +        if (xendev == NULL) {
> > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> > > NULL.\n");
> > > > +            continue;
> > > > +        }
> > > > +
> > > > +        if (xendev->ops->initialise) {
> > > > +            rc = xendev->ops->initialise(xendev);
> > > > +
> > > > +            /*if initialise failed, delete it*/
> > > > +            if (rc != 0) {
> > > > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > > > +                continue;
> > > > +            }
> > > > +        }
> > > > +
> > > > +        /*setup watch*/
> > > > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > > > +                 type, xen_domid, xendev->ops);
> > > > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> > > failed.\n");
> > > > +            return -1;
> > > > +        }
> > > > +    }
> > > > +
> > > > +    free(dev);
> > > > +    return 0;
> > > > +}
> > >
> > > What does this function do? I sholdn't need  to guess from the code,
> > > I should be able to tell from the patch description.
> > >
> > >
> > > >  int xen_be_register(const char *type, struct XenDevOps *ops)  {
> > > >      return xenstore_scan(type, xen_domid, ops);  }
> > > >
> > > > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > > remote_dom)
> > > > +{
> > > > +    xendev->local_port =
> > > xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > > > +
> > > remote_dom);
> > > > +    if (xendev->local_port == -1) {
> > > > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound
> failed\n");
> > > > +        return -1;
> > > > +    }
> > > > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> > > xendev->local_port);
> > > > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > > > +                        xen_be_evtchn_event, NULL, xendev);
> > > > +    return 0;
> > > > +}
> > > > +
> > > >  int xen_be_bind_evtchn(struct XenDevice *xendev)  {
> > > >      if (xendev->local_port != -1) { @@ -770,6 +912,42 @@ int
> > > > xen_be_send_notify(struct XenDevice
> > > *xendev)
> > > >      return xc_evtchn_notify(xendev->evtchndev,
> > > > xendev->local_port);  }
> > > >
> > > > +int xen_vtpm_send(unsigned char *buf, size_t count) {
> > > > +    struct XenDevice *xendev;
> > > > +    int rc = -1;
> > > > +
> > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > +    if (xendev == NULL) {
> > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    if (xendev->ops->send) {
> > > > +        rc = xendev->ops->send(xendev, buf, count);
> > > > +    }
> > > > +
> > > > +    return rc;
> > > > +}
> > > > +
> > > > +int xen_vtpm_recv(unsigned char *buf, size_t *count) {
> > > > +    struct XenDevice *xendev;
> > > > +    int rc = -1;
> > > > +
> > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > +    if (xendev == NULL) {
> > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    if (xendev->ops->recv) {
> > > > +        xendev->ops->recv(xendev, buf, count);
> > > > +    }
> > > > +
> > > > +    return rc;
> > > > +}
> > >
> > > xen_backend.c is supposed to be generic, so stubdom functions might
> > > be OK but vtpm specific functions should not be here.
> > >
> > >
> > > >  /*
> > > >   * msg_level:
> > > >   *  0 == errors (stderr + logfile).
> > > > diff --git a/hw/xen/xen_stubdom_vtpm.c
> b/hw/xen/xen_stubdom_vtpm.c
> > > > new file mode 100644 index 0000000..0d740c1
> > > > --- /dev/null
> > > > +++ b/hw/xen/xen_stubdom_vtpm.c
> > > > @@ -0,0 +1,333 @@
> > > > +/*
> > > > + * Connect to Xen vTPM stubdom domain
> > > > + *
> > > > + *  Copyright (c) 2014 Intel Corporation
> > > > + *  Authors:
> > > > + *    Quan Xu <quan.xu@intel.com>
> > > > + *
> > > > + * 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 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, see
> > > <http://www.gnu.org/licenses/>
> > > > + */
> > > > +
> > > > +#include <stdio.h>
> > > > +#include <stdlib.h>
> > > > +#include <stdarg.h>
> > > > +#include <string.h>
> > > > +#include <unistd.h>
> > > > +#include <signal.h>
> > > > +#include <inttypes.h>
> > > > +#include <time.h>
> > > > +#include <fcntl.h>
> > > > +#include <errno.h>
> > > > +#include <sys/ioctl.h>
> > > > +#include <sys/types.h>
> > > > +#include <sys/stat.h>
> > > > +#include <sys/mman.h>
> > > > +#include <sys/uio.h>
> > > > +
> > > > +#include "hw/hw.h"
> > > > +#include "block/aio.h"
> > > > +#include "hw/xen/xen_backend.h"
> > > > +
> > > > +enum tpmif_state {
> > > > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> > > complete */
> > > > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > > > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > > > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM
> working */
> > > > +};
> > > > +
> > > > +static AioContext *vtpm_aio_ctx;
> > > > +
> > > > +enum status_bits {
> > > > +    VTPM_STATUS_RUNNING  = 0x1,
> > > > +    VTPM_STATUS_IDLE     = 0x2,
> > > > +    VTPM_STATUS_RESULT   = 0x4,
> > > > +    VTPM_STATUS_CANCELED = 0x8,
> > > > +};
> > > > +
> > > > +struct tpmif_shared_page {
> > > > +    uint32_t length;         /* request/response length in bytes */
> > > > +
> > > > +    uint8_t  state;           /* enum tpmif_state */
> > > > +    uint8_t  locality;        /* for the current request */
> > > > +    uint8_t  pad;             /* should be zero */
> > > > +
> > > > +    uint8_t  nr_extra_pages;  /* extra pages for long packets;
> > > > + may be
> > > zero */
> > > > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> > > nr_extra_pages */
> > > > +};
> > > > +
> > > > +struct QEMUBH {
> > > > +    AioContext *ctx;
> > > > +    QEMUBHFunc *cb;
> > > > +    void *opaque;
> > > > +    QEMUBH *next;
> > > > +    bool scheduled;
> > > > +    bool idle;
> > > > +    bool deleted;
> > > > +};
> > > > +
> > > > +struct XenVtpmDev {
> > > > +    struct XenDevice xendev;  /* must be first */
> > > > +    struct           tpmif_shared_page *shr;
> > > > +    xc_gntshr        *xen_xcs;
> > > > +    int              ring_ref;
> > > > +    int              bedomid;
> > > > +    QEMUBH           *sr_bh;
> > > > +};
> > > > +
> > > > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev) {
> > > > +    switch (vtpmdev->shr->state) {
> > > > +    case TPMIF_STATE_IDLE:
> > > > +    case TPMIF_STATE_FINISH:
> > > > +        return VTPM_STATUS_IDLE;
> > > > +    case TPMIF_STATE_SUBMIT:
> > > > +    case TPMIF_STATE_CANCEL:
> > > > +        return VTPM_STATUS_RUNNING;
> > > > +    default:
> > > > +        return 0;
> > > > +    }
> > > > +}
> > > > +
> > > > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> > > xenbus_state xbus)
> > > > +{
> > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > +
> > > > +    if (xendev->fe_state == xbus) {
> > > > +        return 0;
> > > > +    }
> > > > +
> > > > +    xendev->fe_state = xbus;
> > > > +
> > > > +retry_transaction:
> > > > +    xbt = xs_transaction_start(xenstore);
> > > > +    if (xbt == XBT_NULL) {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > +        if (errno == EAGAIN) {
> > > > +            goto retry_transaction;
> > > > +        }
> > > > +    }
> > > > +
> > > > +    return 0;
> > > > +
> > > > +abort_transaction:
> > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > +    return -1;
> > > > +}
> > > > +
> > > > +static int vtpm_aio_wait(QEMUBH *qbh) {
> > > > +    return aio_poll(qbh->ctx, true); }
> > > > +
> > > > +static void sr_bh_handler(void *opaque) { }
> > > > +
> > > > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf,
> > > > +size_t
> > > *count)
> > > > +{
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > +    unsigned int offset;
> > > > +
> > > > +    if (shr->state == TPMIF_STATE_IDLE) {
> > > > +        return -ECANCELED;
> > > > +    }
> > > > +
> > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > +    }
> > > > +
> > > > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > > > +    *count = shr->length;
> > > > +
> > > > +    return 0;
> > > > +}
> > > > +
> > > > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf,
> > > > +size_t
> > > count)
> > > > +{
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > > +
> > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > +    }
> > > > +
> > > > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > > > +    shr->length = count;
> > > > +    barrier();
> > > > +    shr->state = TPMIF_STATE_SUBMIT;
> > > > +    xen_wmb();
> > > > +    xen_be_send_notify(&vtpmdev->xendev);
> > > > +
> > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > +    }
> > > > +
> > > > +    return count;
> > > > +}
> > > > +
> > > > +static int vtpm_initialise(struct XenDevice *xendev) {
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > +    unsigned int ring_ref;
> > > > +
> > > > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> > > "frontend");
> > > > +    if (vtpmdev->xendev.fe == NULL) {
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    /* Get backend domid */
> > > > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > > > +                             &vtpmdev->bedomid)) {
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    /*alloc share page*/
> > > > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> > > vtpmdev->bedomid, 1,
> > > > +                                         &ring_ref,
> > > PROT_READ|PROT_WRITE);
> > > > +    vtpmdev->ring_ref = ring_ref;
> > > > +    if (vtpmdev->shr == NULL) {
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    /*Create event channel */
> > > > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> > > vtpmdev->bedomid)) {
> > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > > > +                     vtpmdev->xendev.local_port);
> > > > +
> > > > +again:
> > > > +    xbt = xs_transaction_start(xenstore);
> > > > +    if (xbt == XBT_NULL) {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > > > +                           vtpmdev->ring_ref)) {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > > > +                           vtpmdev->xendev.local_port)) {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    /* Publish protocol v2 feature */
> > > > +    if (xenstore_write_int(vtpmdev->xendev.fe,
> > > > + "feature-protocol-v2", 1))
> > > {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > +        if (errno == EAGAIN) {
> > > > +            goto again;
> > > > +        }
> > > > +    }
> > > > +    /* Tell vtpm backend that we are ready */
> > > > +    xenbus_switch_state(&vtpmdev->xendev,
> > > > + XenbusStateInitialised);
> > > > +
> > > > +    return 0;
> > > > +
> > > > +abort_transaction:
> > > > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > +    return -1;
> > > > +}
> > > > +
> > > > +static void vtpm_backend_changed(struct XenDevice *xendev, const
> > > > +char
> > > *node)
> > > > +{
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +    int be_state;
> > > > +
> > > > +    if (strcmp(node, "state") == 0) {
> > > > +        xenstore_read_be_int(&vtpmdev->xendev, node,
> &be_state);
> > > > +        switch (be_state) {
> > > > +        case XenbusStateConnected:
> > > > +            /*TODO*/
> > > > +            break;
> > > > +        case XenbusStateClosing:
> > > > +        case XenbusStateClosed:
> > > > +            xenbus_switch_state(&vtpmdev->xendev,
> > > XenbusStateClosing);
> > > > +            break;
> > > > +        default:
> > > > +            break;
> > > > +        }
> > > > +    }
> > > > +}
> > > > +
> > > > +static int vtpm_free(struct XenDevice *xendev) {
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > > > +
> > > > +    aio_poll(qbh->ctx, false);
> > > > +    qemu_bh_delete(vtpmdev->sr_bh);
> > > > +    if (vtpmdev->shr) {
> > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > +    }
> > > > +    xc_interface_close(vtpmdev->xen_xcs);
> > > > +    return 0;
> > > > +}
> > > > +
> > > > +static void vtpm_alloc(struct XenDevice *xendev) {
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +
> > > > +    vtpm_aio_ctx = aio_context_new(NULL);
> > > > +    if (vtpm_aio_ctx == NULL) {
> > > > +        return;
> > > > +    }
> > > > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> > > vtpmdev);
> > > > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > > > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0); }
> > > > +
> > > > +static void vtpm_event(struct XenDevice *xendev) {
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +
> > > > +    qemu_bh_schedule(vtpmdev->sr_bh); }
> > > > +
> > > > +struct XenDevOps xen_vtpmdev_ops = {
> > > > +    .size             = sizeof(struct XenVtpmDev),
> > > > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > > > +                        DEVOPS_FLAG_STUBDOM_BE,
> > > > +    .event            = vtpm_event,
> > > > +    .free             = vtpm_free,
> > > > +    .alloc            = vtpm_alloc,
> > > > +    .initialise       = vtpm_initialise,
> > > > +    .backend_changed  = vtpm_backend_changed,
> > > > +    .recv             = vtpm_recv,
> > > > +    .send             = vtpm_send,
> > > > +};
> > >
> > > Is this the frontend, like the subject line would seem to imply?
> > > If so, XenDevOps are made for backends, while this is a frontend. In
> > > fact this is the first PV frontend in QEMU. We need to introduce
> > > something generic and similar to struct XenDevOps and xen_backend.c
> > > but for frontends.
> > >
> > >
> > > > diff --git a/include/hw/xen/xen_backend.h
> > > b/include/hw/xen/xen_backend.h
> > > > index 3b4125e..45fd6d3 100644
> > > > --- a/include/hw/xen/xen_backend.h
> > > > +++ b/include/hw/xen/xen_backend.h
> > > > @@ -15,6 +15,8 @@ struct XenDevice;
> > > >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> > > >  /* don't expect frontend doing correct state transitions (aka
> > > > console
> > > quirk) */
> > > >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > > > +/*dev backend is stubdom*/
> > > > +#define DEVOPS_FLAG_STUBDOM_BE    4
> > > >
> > > >  struct XenDevOps {
> > > >      size_t    size;
> > > > @@ -26,6 +28,8 @@ struct XenDevOps {
> > > >      void      (*event)(struct XenDevice *xendev);
> > > >      void      (*disconnect)(struct XenDevice *xendev);
> > > >      int       (*free)(struct XenDevice *xendev);
> > > > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> > > count);
> > > > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> > > *count);
> > > >      void      (*backend_changed)(struct XenDevice *xendev, const
> > > char *node);
> > > >      void      (*frontend_changed)(struct XenDevice *xendev, const
> > > char *node);
> > > >  };
> > > > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> > > *xendev);
> > > >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const
> > > > char
> > > *fmt, ...)
> > > >      GCC_FMT_ATTR(3, 4);
> > > >
> > > > +/*Xen stubdom vtpm*/
> > > > +int xen_vtpm_register(struct XenDevOps *ops); int
> > > > +xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > > remote_dom);
> > > > +int xen_vtpm_send(unsigned char *buf, size_t count); int
> > > > +xen_vtpm_recv(unsigned char *buf, size_t *count);
> > > > +
> > > >  /* actual backend drivers */
> > > >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> > > */
> > > >  extern struct XenDevOps xen_kbdmouse_ops;     /*
> xen_framebuffer.c
> > > */
> > > >  extern struct XenDevOps xen_framebuffer_ops;  /*
> xen_framebuffer.c */
> > > >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> > > */
> > > >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> > > */
> > > > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> > > xen_stubdom_vtpm.c*/
> > > >
> > > >  void xen_init_display(int domid);
> > > >
> > > > diff --git a/include/hw/xen/xen_common.h
> > > b/include/hw/xen/xen_common.h
> > > > index 95612a4..fb43084 100644
> > > > --- a/include/hw/xen/xen_common.h
> > > > +++ b/include/hw/xen/xen_common.h
> > > > @@ -130,6 +130,12 @@ static inline XenXC
> > > > xen_xc_interface_open(void
> > > *logger, void *dombuild_logger,
> > > >      return xc_interface_open(logger, dombuild_logger,
> > > > open_flags);  }
> > > >
> > > > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > > > +                                           unsigned int
> > > > +open_flags) {
> > > > +    return xc_gntshr_open(logger, open_flags); }
> > > > +
> > > >  /* FIXME There is now way to have the xen fd */  static inline
> > > > int xc_fd(xc_interface *xen_xc)  { diff --git a/xen-hvm.c
> > > > b/xen-hvm.c index 21f1cbb..c99ace8 100644
> > > > --- a/xen-hvm.c
> > > > +++ b/xen-hvm.c
> > > > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > >      int i, rc;
> > > >      unsigned long ioreq_pfn;
> > > >      unsigned long bufioreq_evtchn;
> > > > +
> > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > +    unsigned long stubdom_vtpm = 0; #endif
> > > > +
> > > >      XenIOState *state;
> > > >
> > > >      state = g_malloc0(sizeof (XenIOState)); @@ -1169,6 +1174,14
> > > > @@ int xen_hvm_init(ram_addr_t
> > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > >          fprintf(stderr, "%s: xen backend core setup failed\n",
> > > __FUNCTION__);
> > > >          return -1;
> > > >      }
> > > > +
> > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > +    xc_get_hvm_param(xen_xc, xen_domid,
> > > HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > > > +    if (stubdom_vtpm) {
> > > > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > > > +    }
> > > > +#endif
> > >
> > > Given that vtpm is just a PV frontend, can't you just detect whether
> > > is present on xenstore and initialize it based on that? Like all the
> > > backend below?
> >
> > Also I will explain in my next email.
> >
> >
> > >
> > >
> > > >      xen_be_register("console", &xen_console_ops);
> > > >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> > > >      xen_be_register("qdisk", &xen_blkdev_ops);
> > > > --
> > > > 1.8.3.2
> > > >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 16:56:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16: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 1Xm3s3-00018e-DI; Wed, 05 Nov 2014 16:55:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xm3s1-00018X-Qk
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 16:55:46 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	AC/10-22777-1965A545; Wed, 05 Nov 2014 16:55:45 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415206537!6126102!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6751 invoked from network); 5 Nov 2014 16:55:37 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-10.tower-206.messagelabs.com with SMTP;
	5 Nov 2014 16:55:37 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 05 Nov 2014 08:49:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,320,1413270000"; d="scan'208";a="617658064"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by fmsmga001.fm.intel.com with ESMTP; 05 Nov 2014 08:55:32 -0800
Received: from kmsmsx152.gar.corp.intel.com (172.21.73.87) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 00:55:32 +0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 00:55:31 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id
	14.03.0195.001; Thu, 6 Nov 2014 00:55:30 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP91zOKlhH4xypD06jTqC2+4O7eZxQng+ggAC8ygCAAMpkkA==
Date: Wed, 5 Nov 2014 16:55:30 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8202B7@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411051036310.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411051036310.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Wednesday, November 05, 2014 7:01 PM
> To: Xu, Quan
> Cc: Stefano Stabellini; qemu-devel@nongnu.org; xen-devel@lists.xen.org
> Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> On Tue, 4 Nov 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Monday, November 03, 2014 7:54 PM
> > > To: Xu, Quan
> > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > > stefano.stabellini@eu.citrix.com
> > > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > > frontend driver
> > >
> > > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > > This drvier transfers any request/repond between TPM xenstubdoms
> > > > driver and Xen vTPM stubdom, and facilitates communications
> > > > between Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > > >
> > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > >
> > > Please describe what changes did make to xen_backend.c and why.
> > > The commit message should contains info on all the changes made by
> > > the patch below.
> > >
> >
> > Thanks Stefano.
> > one more day, I will explain in detail what changes did make to
> > xen_backend.c and why.
> > The following 2 sections are introduction and architecture.
> >
> > > Please also describe what is the "Xen vTPM stubdom", what is the
> > > "vTPM xenstubdoms driver" and how the communicate with each others.
> > >
> >
> >
> > Add 2 parts for detailed descriptions, introduction and architecture.
> >
> > *INTRODUCTION*
> >
> > The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM
> > functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows
> > .etc). This allows programs to interact with a TPM in a virtual
> > machine the same way they interact with a TPM on the physical system.
> Each virtual machine gets its own unique, emulated, software TPM.
> > Each major component of vTPM is implemented as a stubdom, providing
> > secure separation guaranteed by the hypervisor.
> > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the
> > virtual machine to use. It is a small wrapper around the Berlios TPM
> > emulator. TPM commands are passed from mini-os TPM backend driver.
> > This patch series are only the Qemu part to enable Xen stubdom vTPM
> > for HVM virtual machine.
> > ===========
> >
> > *ARCHITECTURE*
> >
> > The architecture of stubdom vTPM for HVM virtual machine:
> >
> >             +--------------------+
> >             | Windows/Linux DomU | ...
> >             |        |  ^        |
> >             |        v  |        |
> >             |  Qemu tpm1.2 Tis   |
> >             |        |  ^        |
> >             |        v  |        |
> >             |        vTPM        |
> >             | XenStubdoms driver |  (new ..)
> >             +--------------------+
> >                      |  ^
> >                      v  |
> >             +--------------------+
> >             |  xen_vtpmdev_ops   |  (new ..)
> >             +--------------------+
> >                      |  ^
> >                      v  |
> >             +--------------------+
> >             |  mini-os/tpmback   |
> >             |        |  ^        |
> >             |        v  |        |
> >             |   vTPM stubdom     | ...
> >             |        |  ^        |
> >             |        v  |        |
> >             |  mini-os/tpmfront  |
> >             +--------------------+
> >                      |  ^
> >                      v  |
> >             +--------------------+
> >             |  mini-os/tpmback   |
> >             |        |  ^        |
> >             |        v  |        |
> >             |  vtpmmgr stubdom   |
> >             |        |  ^        |
> >             |        v  |        |
> >             |  mini-os/tpm_tis   |
> >             +--------------------+
> >                      |  ^
> >                      v  |
> >             +--------------------+
> >             |    Hardware TPM    |
> >             +--------------------+
> >
> >
> > * Windows/Linux DomU:
> >     The HVM based guest that wants to use a vTPM. There may be
> >     more than one of these.
> >
> >  * Qemu tpm1.2 Tis:
> >     Implementation of the tpm1.2 Tis interface for HVM virtual
> >     machines. It is Qemu emulation device.
> 
> It looks like you are running upstream QEMU within a Mini-OS stubdom?
> If so, where are the patches to do that? As far as I know upstream QEMU
> doesn't run on Mini-OS. Or maybe it is a Linux stubdom? Either way, it is not
> clear.

Not so.
Refer to below further explanation. 

> 
> 
> >  * vTPM xenstubdoms driver:
> >     Similar to a TPM passthrough backend driver, it is a new TPM
> >     backend for emulated TPM TIS interface. This driver provides
> >     vTPM initialization and sending data and commends to a Xen
> >     vTPM stubdom.
> 
> This is patch #3, right? It is basically the internal QEMU "glue" to connect the
> tpm emulator to xen_vtpmdev_ops, correct?
> 

Yes, it is Patch #3. Agree with your description.  :)

> 
> >  * xen_vtpmdev_ops:
> >     Register Xen stubdom vTPM backend, and transfer any request/
> >     repond between TPM xenstubdoms driver and Xen vTPM stubdom.
> >     Facilitate communications between Xen vTPM stubdom and vTPM
> >     xenstubdoms driver.
> 
> It looks like this correspond to patch #2? If so, this is a regular Xen PV

Yes, it patch #2.


> frontend, living in QEMU? It requires the gntalloc device so I guess it is
> supposed to run on Linux. In that case is it just a tpmfront implementation in
> QEMU?
> 


Yes, it's tpmfront implementation in Qemu. also it supports PV Linux since Xen 4.3.0.
vTPM stubdom / vtpmmgr stubdom  ware implemented by Matthew Fioravante (JHUAPL),
Linux pv vTPM frontend was implemented by Daniel De Graaf (NSA)



> If you are running it on Linux, we might need to introduce Linux based
> stundoms to the Xen build system.

Not so.
Maybe I should explain a bit further. TPM is a character device. 'Qemu tpm1.2 Tis'
Implement some TPM register hook of TPM, and enable TIS (TPM interface Specification).
The ' Qemu tpm1.2 Tis ' should deal with TPM commands. 

Such as TPM_ContinueSelfTest command,
    { 0x00, 0xc1, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x53};
If success, the TPM will respond,
    { 0x00, 0xc4, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x00};

Qemu upstream has supported TPM passthrough. actually, 'Qemu TPM passthrough' send 
These TPM commands from "Qemu tpm1.2 Tis" to TPM hardware, and get the respond. 

" [PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for HVM virtual machine " send 
These TPM commands from "Qemu tpm1.2 Tis" to Xen stubdom( explain in previous email)
And get the respond. 

#(qemu-system-* --tpmdev help)
#(passthrough   Passthrough TPM backend driver)
#( xenstubdoms  Xenstubdoms TPM backend driver)

The following is Qemu part.

            |        |  ^       |
            |        v  |       |
            |        vTPM      |
            | XenStubdoms driver |  (new ..)
            +------------------------------+
                     |  ^
                     v  |
            +------------------------------+
            |  xen_vtpmdev_ops  |  (new ..)
            +------------------------------+
"vTPM XenStubdoms driver" and "xen_vtpmdev_ops" are implemented to send These TPM commands 
from "Qemu tpm1.2 Tis" to Xen stubdom.

> 
> 
> >  * mini-os/tpmback:
> >     Mini-os TPM backend driver. The Linux frontend driver connects
> >     to this backend driver to facilitate communications between the
> >     Linux DomU and its vTPM. This driver is also used by vtpmmgr
> >     stubdom to communicate with vTPM stubdom.
> >
> >  * vTPM stubdom:
> >     A mini-os stub domain that implements a vTPM. There is a
> >     one to one mapping between running vTPM stubdom instances and
> >     logical vTPMs on the system. The vTPM Platform Configuration
> >     Registers (PCRs) are all initialized to zero.
> >
> >  * mini-os/tpmfront:
> >     Mini-os TPM frontend driver. The vTPM mini-os domain vTPM
> >     stubdom uses this driver to communicate with vtpmmgr-stubdom.
> >     This driver could also be used separately to implement a mini-os
> >     domain that wishes to use a vTPM of its own.
> >
> >  * vtpmmgr stubdom:
> >     A mini-os domain that implements the vTPM manager. There is only
> >     one vTPM manager and it should be running during the entire lifetime
> >     of the machine. vtpmmgr domain securely stores encryption keys for
> >     each of the vTPMs and accesses to the hardware TPM to get the root
> of
> >     trust for the entire system.
> >
> >  * mini-os/tpm_tis:
> >     Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
> >     This driver used by vtpmmgr-stubdom to talk directly to the hardware
> >     TPM. Communication is facilitated by mapping hardware memory
> pages
> >     into vtpmmgr stubdom.
> 
> Are all the Mini-OS component upstream, or do we need patches?
> 
> 
> >  * Hardware TPM:
> >     The physical TPM 1.2 that is soldered onto the motherboard.
> >
> > ===========
> >
> >
> >
> > > Where does the vTPM backend lives?
> > The vTPM backend lives in Xen vTPM stubdom (Xen Mini-os)
> 
> Thanks for the explanation, it is a bit clearer now.
> 


Welcome, thanks for your careful review. 



> 
> > >
> > >
> > > >  hw/xen/Makefile.objs         |   1 +
> > > >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> > > >  hw/xen/xen_stubdom_vtpm.c    | 333
> > > +++++++++++++++++++++++++++++++++++++++++++
> > > >  include/hw/xen/xen_backend.h |  11 ++
> > > >  include/hw/xen/xen_common.h  |   6 +
> > > >  xen-hvm.c                    |  13 ++
> > > >  6 files changed, 544 insertions(+), 2 deletions(-)  create mode
> > > > 100644 hw/xen/xen_stubdom_vtpm.c
> > > >
> > > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs index
> > > > a0ca0aa..724df8d 100644
> > > > --- a/hw/xen/Makefile.objs
> > > > +++ b/hw/xen/Makefile.objs
> > > > @@ -1,5 +1,6 @@
> > > >  # xen backend driver support
> > > >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> > > xen_devconfig.o
> > > > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) +=
> xen_stubdom_vtpm.o
> > > >
> > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> > > xen_pt_config_init.o xen_pt_msi.o
> > > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index
> > > > b2cb22b..45a5778 100644
> > > > --- a/hw/xen/xen_backend.c
> > > > +++ b/hw/xen/xen_backend.c
> > > > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice
> > > > *xendev,
> > > enum xenbus_state state)
> > > >      return 0;
> > > >  }
> > > >
> > > > +/*get stubdom backend*/
> > > > +static char *xen_stubdom_be(const char *type, int dom, int dev) {
> > > > +    char *val, *domu;
> > > > +    char path[XEN_BUFSIZE];
> > > > +    unsigned int len, ival;
> > > > +
> > > > +    /*front domu*/
> > > > +    domu = xs_get_domain_path(xenstore, dom);
> > > > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > > > +             domu, type, dev);
> > > > +    g_free(domu);
> > > > +
> > > > +    val = xs_read(xenstore, 0, path, &len);
> > > > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > > > +        g_free(val);
> > > > +        return NULL;
> > > > +    }
> > > > +    g_free(val);
> > > > +
> > > > +    /*backend domu*/
> > > > +    domu = xs_get_domain_path(xenstore, ival);
> > > > +
> > > > +    return domu;
> > > > +}
> > > > +
> > > >  /* -------------------------------------------------------------
> > > > */
> > > >
> > > >  struct XenDevice *xen_be_find_xendev(const char *type, int dom,
> > > > int
> > > dev)
> > > > @@ -222,6 +248,7 @@ static struct XenDevice
> > > > *xen_be_get_xendev(const
> > > char *type, int dom, int dev,
> > > >                                             struct XenDevOps
> *ops)
> > > > {
> > > >      struct XenDevice *xendev;
> > > > +    char *stub;
> > > >
> > > >      xendev = xen_be_find_xendev(type, dom, dev);
> > > >      if (xendev) {
> > > > @@ -235,8 +262,15 @@ static struct XenDevice
> > > *xen_be_get_xendev(const char *type, int dom, int dev,
> > > >      xendev->dev   = dev;
> > > >      xendev->ops   = ops;
> > > >
> > > > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > > > -             xendev->type, xendev->dom, xendev->dev);
> > > > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > > > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> > > xendev->dev);
> > > > +        snprintf(xendev->be, sizeof(xendev->be),
> > > "%s/backend/%s/%d/%d",
> > > > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > > > +        g_free(stub);
> > > > +    } else {
> > > > +        snprintf(xendev->be, sizeof(xendev->be),
> "backend/%s/%d/%d",
> > > > +                 xendev->type, xendev->dom, xendev->dev);
> > > > +    }
> > > >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> > > >               xendev->type, xendev->dev);
> > > >
> > > > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type,
> > > > int
> > > dom, struct XenDevOps *ops)
> > > >      return 0;
> > > >  }
> > > >
> > > > +static void stubdom_update_be(char *watch, char *type, int dom,
> > > > +                              struct XenDevOps *ops) {
> > > > +    struct XenDevice *xendev;
> > > > +    char path[XEN_BUFSIZE];
> > > > +    char *ptr, *bepath;
> > > > +    unsigned int len, dev;
> > > > +
> > > > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > > > +        return;
> > > > +    }
> > > > +
> > > > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > > > +    ptr = strstr(watch, path);
> > > > +    if (ptr == NULL) {
> > > > +        return;
> > > > +    }
> > > > +
> > > > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > > > +        strcpy(path, "");
> > > > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > > > +            dev = -1;
> > > > +        }
> > > > +    }
> > > > +
> > > > +    if (dev == -1) {
> > > > +        return;
> > > > +    }
> > > > +
> > > > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > > > +    if (xendev != NULL) {
> > > > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > > > +        if (bepath == NULL) {
> > > > +            xen_be_del_xendev(dom, dev);
> > > > +        } else {
> > > > +            free(bepath);
> > > > +            xen_be_backend_changed(xendev, path);
> > > > +        }
> > > > +    }
> > > > +}
> > > > +
> > > >  static void xenstore_update_be(char *watch, char *type, int dom,
> > > >                                 struct XenDevOps *ops)  { @@
> > > > -681,6 +756,10 @@ static void xenstore_update(void *unused)
> > > >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> > > >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> > > >      }
> > > > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> > > PRIxPTR,
> > > > +               &type, &dom, &ops) == 3) {
> > > > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type,
> dom,
> > > (void *)ops);
> > > > +    }
> > > >
> > > >  cleanup:
> > > >      free(vec);
> > > > @@ -732,11 +811,74 @@ err:
> > > >      return -1;
> > > >  }
> > > >
> > > > +int xen_vtpm_register(struct XenDevOps *ops) {
> > > > +    struct XenDevice *xendev;
> > > > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > > > +    char *domu;
> > > > +    unsigned int cdev, j, rc;
> > > > +    const char *type = "vtpm";
> > > > +    char **dev = NULL;
> > > > +
> > > > +    /*front domu*/
> > > > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > > > +    snprintf(path, sizeof(path), "%s/device/%s",
> > > > +             domu, type);
> > > > +    free(domu);
> > > > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > > > +    if (dev == NULL) {
> > > > +        return 0;
> > > > +    }
> > > > +
> > > > +    for (j = 0; j < cdev; j++) {
> > > > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> > > ops);
> > > > +        if (xendev == NULL) {
> > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> > > NULL.\n");
> > > > +            continue;
> > > > +        }
> > > > +
> > > > +        if (xendev->ops->initialise) {
> > > > +            rc = xendev->ops->initialise(xendev);
> > > > +
> > > > +            /*if initialise failed, delete it*/
> > > > +            if (rc != 0) {
> > > > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > > > +                continue;
> > > > +            }
> > > > +        }
> > > > +
> > > > +        /*setup watch*/
> > > > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > > > +                 type, xen_domid, xendev->ops);
> > > > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> > > failed.\n");
> > > > +            return -1;
> > > > +        }
> > > > +    }
> > > > +
> > > > +    free(dev);
> > > > +    return 0;
> > > > +}
> > >
> > > What does this function do? I sholdn't need  to guess from the code,
> > > I should be able to tell from the patch description.
> > >
> > >
> > > >  int xen_be_register(const char *type, struct XenDevOps *ops)  {
> > > >      return xenstore_scan(type, xen_domid, ops);  }
> > > >
> > > > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > > remote_dom)
> > > > +{
> > > > +    xendev->local_port =
> > > xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > > > +
> > > remote_dom);
> > > > +    if (xendev->local_port == -1) {
> > > > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound
> failed\n");
> > > > +        return -1;
> > > > +    }
> > > > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> > > xendev->local_port);
> > > > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > > > +                        xen_be_evtchn_event, NULL, xendev);
> > > > +    return 0;
> > > > +}
> > > > +
> > > >  int xen_be_bind_evtchn(struct XenDevice *xendev)  {
> > > >      if (xendev->local_port != -1) { @@ -770,6 +912,42 @@ int
> > > > xen_be_send_notify(struct XenDevice
> > > *xendev)
> > > >      return xc_evtchn_notify(xendev->evtchndev,
> > > > xendev->local_port);  }
> > > >
> > > > +int xen_vtpm_send(unsigned char *buf, size_t count) {
> > > > +    struct XenDevice *xendev;
> > > > +    int rc = -1;
> > > > +
> > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > +    if (xendev == NULL) {
> > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    if (xendev->ops->send) {
> > > > +        rc = xendev->ops->send(xendev, buf, count);
> > > > +    }
> > > > +
> > > > +    return rc;
> > > > +}
> > > > +
> > > > +int xen_vtpm_recv(unsigned char *buf, size_t *count) {
> > > > +    struct XenDevice *xendev;
> > > > +    int rc = -1;
> > > > +
> > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > +    if (xendev == NULL) {
> > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    if (xendev->ops->recv) {
> > > > +        xendev->ops->recv(xendev, buf, count);
> > > > +    }
> > > > +
> > > > +    return rc;
> > > > +}
> > >
> > > xen_backend.c is supposed to be generic, so stubdom functions might
> > > be OK but vtpm specific functions should not be here.
> > >
> > >
> > > >  /*
> > > >   * msg_level:
> > > >   *  0 == errors (stderr + logfile).
> > > > diff --git a/hw/xen/xen_stubdom_vtpm.c
> b/hw/xen/xen_stubdom_vtpm.c
> > > > new file mode 100644 index 0000000..0d740c1
> > > > --- /dev/null
> > > > +++ b/hw/xen/xen_stubdom_vtpm.c
> > > > @@ -0,0 +1,333 @@
> > > > +/*
> > > > + * Connect to Xen vTPM stubdom domain
> > > > + *
> > > > + *  Copyright (c) 2014 Intel Corporation
> > > > + *  Authors:
> > > > + *    Quan Xu <quan.xu@intel.com>
> > > > + *
> > > > + * 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 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, see
> > > <http://www.gnu.org/licenses/>
> > > > + */
> > > > +
> > > > +#include <stdio.h>
> > > > +#include <stdlib.h>
> > > > +#include <stdarg.h>
> > > > +#include <string.h>
> > > > +#include <unistd.h>
> > > > +#include <signal.h>
> > > > +#include <inttypes.h>
> > > > +#include <time.h>
> > > > +#include <fcntl.h>
> > > > +#include <errno.h>
> > > > +#include <sys/ioctl.h>
> > > > +#include <sys/types.h>
> > > > +#include <sys/stat.h>
> > > > +#include <sys/mman.h>
> > > > +#include <sys/uio.h>
> > > > +
> > > > +#include "hw/hw.h"
> > > > +#include "block/aio.h"
> > > > +#include "hw/xen/xen_backend.h"
> > > > +
> > > > +enum tpmif_state {
> > > > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> > > complete */
> > > > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > > > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > > > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM
> working */
> > > > +};
> > > > +
> > > > +static AioContext *vtpm_aio_ctx;
> > > > +
> > > > +enum status_bits {
> > > > +    VTPM_STATUS_RUNNING  = 0x1,
> > > > +    VTPM_STATUS_IDLE     = 0x2,
> > > > +    VTPM_STATUS_RESULT   = 0x4,
> > > > +    VTPM_STATUS_CANCELED = 0x8,
> > > > +};
> > > > +
> > > > +struct tpmif_shared_page {
> > > > +    uint32_t length;         /* request/response length in bytes */
> > > > +
> > > > +    uint8_t  state;           /* enum tpmif_state */
> > > > +    uint8_t  locality;        /* for the current request */
> > > > +    uint8_t  pad;             /* should be zero */
> > > > +
> > > > +    uint8_t  nr_extra_pages;  /* extra pages for long packets;
> > > > + may be
> > > zero */
> > > > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> > > nr_extra_pages */
> > > > +};
> > > > +
> > > > +struct QEMUBH {
> > > > +    AioContext *ctx;
> > > > +    QEMUBHFunc *cb;
> > > > +    void *opaque;
> > > > +    QEMUBH *next;
> > > > +    bool scheduled;
> > > > +    bool idle;
> > > > +    bool deleted;
> > > > +};
> > > > +
> > > > +struct XenVtpmDev {
> > > > +    struct XenDevice xendev;  /* must be first */
> > > > +    struct           tpmif_shared_page *shr;
> > > > +    xc_gntshr        *xen_xcs;
> > > > +    int              ring_ref;
> > > > +    int              bedomid;
> > > > +    QEMUBH           *sr_bh;
> > > > +};
> > > > +
> > > > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev) {
> > > > +    switch (vtpmdev->shr->state) {
> > > > +    case TPMIF_STATE_IDLE:
> > > > +    case TPMIF_STATE_FINISH:
> > > > +        return VTPM_STATUS_IDLE;
> > > > +    case TPMIF_STATE_SUBMIT:
> > > > +    case TPMIF_STATE_CANCEL:
> > > > +        return VTPM_STATUS_RUNNING;
> > > > +    default:
> > > > +        return 0;
> > > > +    }
> > > > +}
> > > > +
> > > > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> > > xenbus_state xbus)
> > > > +{
> > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > +
> > > > +    if (xendev->fe_state == xbus) {
> > > > +        return 0;
> > > > +    }
> > > > +
> > > > +    xendev->fe_state = xbus;
> > > > +
> > > > +retry_transaction:
> > > > +    xbt = xs_transaction_start(xenstore);
> > > > +    if (xbt == XBT_NULL) {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > +        if (errno == EAGAIN) {
> > > > +            goto retry_transaction;
> > > > +        }
> > > > +    }
> > > > +
> > > > +    return 0;
> > > > +
> > > > +abort_transaction:
> > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > +    return -1;
> > > > +}
> > > > +
> > > > +static int vtpm_aio_wait(QEMUBH *qbh) {
> > > > +    return aio_poll(qbh->ctx, true); }
> > > > +
> > > > +static void sr_bh_handler(void *opaque) { }
> > > > +
> > > > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf,
> > > > +size_t
> > > *count)
> > > > +{
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > +    unsigned int offset;
> > > > +
> > > > +    if (shr->state == TPMIF_STATE_IDLE) {
> > > > +        return -ECANCELED;
> > > > +    }
> > > > +
> > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > +    }
> > > > +
> > > > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > > > +    *count = shr->length;
> > > > +
> > > > +    return 0;
> > > > +}
> > > > +
> > > > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf,
> > > > +size_t
> > > count)
> > > > +{
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > > +
> > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > +    }
> > > > +
> > > > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > > > +    shr->length = count;
> > > > +    barrier();
> > > > +    shr->state = TPMIF_STATE_SUBMIT;
> > > > +    xen_wmb();
> > > > +    xen_be_send_notify(&vtpmdev->xendev);
> > > > +
> > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > +    }
> > > > +
> > > > +    return count;
> > > > +}
> > > > +
> > > > +static int vtpm_initialise(struct XenDevice *xendev) {
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > +    unsigned int ring_ref;
> > > > +
> > > > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> > > "frontend");
> > > > +    if (vtpmdev->xendev.fe == NULL) {
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    /* Get backend domid */
> > > > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > > > +                             &vtpmdev->bedomid)) {
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    /*alloc share page*/
> > > > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> > > vtpmdev->bedomid, 1,
> > > > +                                         &ring_ref,
> > > PROT_READ|PROT_WRITE);
> > > > +    vtpmdev->ring_ref = ring_ref;
> > > > +    if (vtpmdev->shr == NULL) {
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    /*Create event channel */
> > > > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> > > vtpmdev->bedomid)) {
> > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > +        return -1;
> > > > +    }
> > > > +
> > > > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > > > +                     vtpmdev->xendev.local_port);
> > > > +
> > > > +again:
> > > > +    xbt = xs_transaction_start(xenstore);
> > > > +    if (xbt == XBT_NULL) {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > > > +                           vtpmdev->ring_ref)) {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > > > +                           vtpmdev->xendev.local_port)) {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    /* Publish protocol v2 feature */
> > > > +    if (xenstore_write_int(vtpmdev->xendev.fe,
> > > > + "feature-protocol-v2", 1))
> > > {
> > > > +        goto abort_transaction;
> > > > +    }
> > > > +
> > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > +        if (errno == EAGAIN) {
> > > > +            goto again;
> > > > +        }
> > > > +    }
> > > > +    /* Tell vtpm backend that we are ready */
> > > > +    xenbus_switch_state(&vtpmdev->xendev,
> > > > + XenbusStateInitialised);
> > > > +
> > > > +    return 0;
> > > > +
> > > > +abort_transaction:
> > > > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > +    return -1;
> > > > +}
> > > > +
> > > > +static void vtpm_backend_changed(struct XenDevice *xendev, const
> > > > +char
> > > *node)
> > > > +{
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +    int be_state;
> > > > +
> > > > +    if (strcmp(node, "state") == 0) {
> > > > +        xenstore_read_be_int(&vtpmdev->xendev, node,
> &be_state);
> > > > +        switch (be_state) {
> > > > +        case XenbusStateConnected:
> > > > +            /*TODO*/
> > > > +            break;
> > > > +        case XenbusStateClosing:
> > > > +        case XenbusStateClosed:
> > > > +            xenbus_switch_state(&vtpmdev->xendev,
> > > XenbusStateClosing);
> > > > +            break;
> > > > +        default:
> > > > +            break;
> > > > +        }
> > > > +    }
> > > > +}
> > > > +
> > > > +static int vtpm_free(struct XenDevice *xendev) {
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > > > +
> > > > +    aio_poll(qbh->ctx, false);
> > > > +    qemu_bh_delete(vtpmdev->sr_bh);
> > > > +    if (vtpmdev->shr) {
> > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > +    }
> > > > +    xc_interface_close(vtpmdev->xen_xcs);
> > > > +    return 0;
> > > > +}
> > > > +
> > > > +static void vtpm_alloc(struct XenDevice *xendev) {
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +
> > > > +    vtpm_aio_ctx = aio_context_new(NULL);
> > > > +    if (vtpm_aio_ctx == NULL) {
> > > > +        return;
> > > > +    }
> > > > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> > > vtpmdev);
> > > > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > > > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0); }
> > > > +
> > > > +static void vtpm_event(struct XenDevice *xendev) {
> > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > XenVtpmDev,
> > > > +                                              xendev);
> > > > +
> > > > +    qemu_bh_schedule(vtpmdev->sr_bh); }
> > > > +
> > > > +struct XenDevOps xen_vtpmdev_ops = {
> > > > +    .size             = sizeof(struct XenVtpmDev),
> > > > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > > > +                        DEVOPS_FLAG_STUBDOM_BE,
> > > > +    .event            = vtpm_event,
> > > > +    .free             = vtpm_free,
> > > > +    .alloc            = vtpm_alloc,
> > > > +    .initialise       = vtpm_initialise,
> > > > +    .backend_changed  = vtpm_backend_changed,
> > > > +    .recv             = vtpm_recv,
> > > > +    .send             = vtpm_send,
> > > > +};
> > >
> > > Is this the frontend, like the subject line would seem to imply?
> > > If so, XenDevOps are made for backends, while this is a frontend. In
> > > fact this is the first PV frontend in QEMU. We need to introduce
> > > something generic and similar to struct XenDevOps and xen_backend.c
> > > but for frontends.
> > >
> > >
> > > > diff --git a/include/hw/xen/xen_backend.h
> > > b/include/hw/xen/xen_backend.h
> > > > index 3b4125e..45fd6d3 100644
> > > > --- a/include/hw/xen/xen_backend.h
> > > > +++ b/include/hw/xen/xen_backend.h
> > > > @@ -15,6 +15,8 @@ struct XenDevice;
> > > >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> > > >  /* don't expect frontend doing correct state transitions (aka
> > > > console
> > > quirk) */
> > > >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > > > +/*dev backend is stubdom*/
> > > > +#define DEVOPS_FLAG_STUBDOM_BE    4
> > > >
> > > >  struct XenDevOps {
> > > >      size_t    size;
> > > > @@ -26,6 +28,8 @@ struct XenDevOps {
> > > >      void      (*event)(struct XenDevice *xendev);
> > > >      void      (*disconnect)(struct XenDevice *xendev);
> > > >      int       (*free)(struct XenDevice *xendev);
> > > > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> > > count);
> > > > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> > > *count);
> > > >      void      (*backend_changed)(struct XenDevice *xendev, const
> > > char *node);
> > > >      void      (*frontend_changed)(struct XenDevice *xendev, const
> > > char *node);
> > > >  };
> > > > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> > > *xendev);
> > > >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const
> > > > char
> > > *fmt, ...)
> > > >      GCC_FMT_ATTR(3, 4);
> > > >
> > > > +/*Xen stubdom vtpm*/
> > > > +int xen_vtpm_register(struct XenDevOps *ops); int
> > > > +xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > > remote_dom);
> > > > +int xen_vtpm_send(unsigned char *buf, size_t count); int
> > > > +xen_vtpm_recv(unsigned char *buf, size_t *count);
> > > > +
> > > >  /* actual backend drivers */
> > > >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> > > */
> > > >  extern struct XenDevOps xen_kbdmouse_ops;     /*
> xen_framebuffer.c
> > > */
> > > >  extern struct XenDevOps xen_framebuffer_ops;  /*
> xen_framebuffer.c */
> > > >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> > > */
> > > >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> > > */
> > > > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> > > xen_stubdom_vtpm.c*/
> > > >
> > > >  void xen_init_display(int domid);
> > > >
> > > > diff --git a/include/hw/xen/xen_common.h
> > > b/include/hw/xen/xen_common.h
> > > > index 95612a4..fb43084 100644
> > > > --- a/include/hw/xen/xen_common.h
> > > > +++ b/include/hw/xen/xen_common.h
> > > > @@ -130,6 +130,12 @@ static inline XenXC
> > > > xen_xc_interface_open(void
> > > *logger, void *dombuild_logger,
> > > >      return xc_interface_open(logger, dombuild_logger,
> > > > open_flags);  }
> > > >
> > > > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > > > +                                           unsigned int
> > > > +open_flags) {
> > > > +    return xc_gntshr_open(logger, open_flags); }
> > > > +
> > > >  /* FIXME There is now way to have the xen fd */  static inline
> > > > int xc_fd(xc_interface *xen_xc)  { diff --git a/xen-hvm.c
> > > > b/xen-hvm.c index 21f1cbb..c99ace8 100644
> > > > --- a/xen-hvm.c
> > > > +++ b/xen-hvm.c
> > > > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > >      int i, rc;
> > > >      unsigned long ioreq_pfn;
> > > >      unsigned long bufioreq_evtchn;
> > > > +
> > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > +    unsigned long stubdom_vtpm = 0; #endif
> > > > +
> > > >      XenIOState *state;
> > > >
> > > >      state = g_malloc0(sizeof (XenIOState)); @@ -1169,6 +1174,14
> > > > @@ int xen_hvm_init(ram_addr_t
> > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > >          fprintf(stderr, "%s: xen backend core setup failed\n",
> > > __FUNCTION__);
> > > >          return -1;
> > > >      }
> > > > +
> > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > +    xc_get_hvm_param(xen_xc, xen_domid,
> > > HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > > > +    if (stubdom_vtpm) {
> > > > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > > > +    }
> > > > +#endif
> > >
> > > Given that vtpm is just a PV frontend, can't you just detect whether
> > > is present on xenstore and initialize it based on that? Like all the
> > > backend below?
> >
> > Also I will explain in my next email.
> >
> >
> > >
> > >
> > > >      xen_be_register("console", &xen_console_ops);
> > > >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> > > >      xen_be_register("qdisk", &xen_blkdev_ops);
> > > > --
> > > > 1.8.3.2
> > > >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 16:57:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm3tG-0001F3-8S; Wed, 05 Nov 2014 16:57:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xm3tE-0001Es-Sb
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 16:57:01 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	9B/F6-25547-CD65A545; Wed, 05 Nov 2014 16:57:00 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415206618!11888092!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16461 invoked from network); 5 Nov 2014 16:56:58 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-8.tower-31.messagelabs.com with SMTP;
	5 Nov 2014 16:56:58 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 73A2B1AA;
	Wed,  5 Nov 2014 10:56:53 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 520535FAD7;
	Wed,  5 Nov 2014 10:56:51 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id CCB8B13F8F5;
	Wed,  5 Nov 2014 10:56:49 -0600 (CST)
Date: Wed, 5 Nov 2014 16:56:47 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141105165646.GN32700@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 11:10:18AM +0000, Stefano Stabellini wrote:
> On Mon, 3 Nov 2014, Will Deacon wrote:
> > On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> > > On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > > > Introduce a boolean flag and an accessor function to check whether a
> > > > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > CC: will.deacon@arm.com
> > > 
> > > Will, Catalin,
> > > are you OK with this patch?
> > 
> > It would be nicer if the dma_coherent flag didn't have to be duplicated by
> > each architecture in dev_archdata. Is there any reason not to put it in the
> > core code?
> 
> Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> struct device as Catalin initially suggested, what would be the default
> for each architecture? Where would I set it for arch that don't use
> device tree?

You don't need to. An architecture that has coherent DMA always doesn't
need to do anything. One that has non-coherent DMA always only needs to
select HAVE_DMA_NONCOHERENT. One that has a mix of both needs to find a
way to set dev->dma_coherent. Since that's a new API you introduce, it
doesn't break any existing architectures.

Note that if !is_device_dma_coherent(), it doesn't always mean that
standard cache maintenance would be enough (but that's a Xen problem,
not sure how to solve).


diff --git a/arch/Kconfig b/arch/Kconfig
index 05d7a8a458d5..8462b2e7491b 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -203,6 +203,9 @@ config HAVE_DMA_ATTRS
 config HAVE_DMA_CONTIGUOUS
 	bool
 
+config HAVE_DMA_NONCOHERENT
+	bool
+
 config GENERIC_SMP_IDLE_THREAD
        bool
 
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 89c4b5ccc68d..fd7d5522764c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -40,6 +40,7 @@ config ARM
 	select HAVE_DMA_API_DEBUG
 	select HAVE_DMA_ATTRS
 	select HAVE_DMA_CONTIGUOUS if MMU
+	select HAVE_DMA_NONCOHERENT if OF
 	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
 	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d5857e..eb7a5aa64e0e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -46,6 +46,7 @@ config ARM64
 	select HAVE_DMA_API_DEBUG
 	select HAVE_DMA_ATTRS
 	select HAVE_DMA_CONTIGUOUS
+	select HAVE_DMA_NONCOHERENT
 	select HAVE_DYNAMIC_FTRACE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS
 	select HAVE_FTRACE_MCOUNT_RECORD
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 3b64d0bf5bba..7e827726b702 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -183,6 +183,7 @@ static void of_dma_configure(struct device *dev)
 	 * dma coherent operations.
 	 */
 	if (of_dma_is_coherent(dev->of_node)) {
+		dev->dma_coherent = true;
 		set_arch_dma_coherent_ops(dev);
 		dev_dbg(dev, "device is dma coherent\n");
 	}
diff --git a/include/linux/device.h b/include/linux/device.h
index ce1f21608b16..e00ca876db01 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -796,6 +796,7 @@ struct device {
 
 	bool			offline_disabled:1;
 	bool			offline:1;
+	bool			dma_coherent:1;
 };
 
 static inline struct device *kobj_to_dev(struct kobject *kobj)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d388160f42..0bdffba2337d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -78,6 +78,18 @@ static inline int is_device_dma_capable(struct device *dev)
 	return dev->dma_mask != NULL && *dev->dma_mask != DMA_MASK_NONE;
 }
 
+#ifdef CONFIG_HAVE_DMA_NONCOHERENT
+static inline int is_device_dma_coherent(struct device *dev)
+{
+	return dev->dma_coherent;
+}
+#else
+static inline int is_device_dma_coherent(struct device *dev)
+{
+	return 1
+}
+#endif
+
 #ifdef CONFIG_HAS_DMA
 #include <asm/dma-mapping.h>
 #else
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d5857e..eb7a5aa64e0e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -46,6 +46,7 @@ config ARM64
 	select HAVE_DMA_API_DEBUG
 	select HAVE_DMA_ATTRS
 	select HAVE_DMA_CONTIGUOUS
+	select HAVE_DMA_NONCOHERENT
 	select HAVE_DYNAMIC_FTRACE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS
 	select HAVE_FTRACE_MCOUNT_RECORD
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 3b64d0bf5bba..7e827726b702 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -183,6 +183,7 @@ static void of_dma_configure(struct device *dev)
 	 * dma coherent operations.
 	 */
 	if (of_dma_is_coherent(dev->of_node)) {
+		dev->dma_coherent = true;
 		set_arch_dma_coherent_ops(dev);
 		dev_dbg(dev, "device is dma coherent\n");
 	}
diff --git a/include/linux/device.h b/include/linux/device.h
index ce1f21608b16..e00ca876db01 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -796,6 +796,7 @@ struct device {
 
 	bool			offline_disabled:1;
 	bool			offline:1;
+	bool			dma_coherent:1;
 };
 
 static inline struct device *kobj_to_dev(struct kobject *kobj)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d388160f42..0bdffba2337d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -78,6 +78,18 @@ static inline int is_device_dma_capable(struct device *dev)
 	return dev->dma_mask != NULL && *dev->dma_mask != DMA_MASK_NONE;
 }
 
+#ifdef CONFIG_HAVE_DMA_NONCOHERENT
+static inline int is_device_dma_coherent(struct device *dev)
+{
+	return dev->dma_coherent;
+}
+#else
+static inline int is_device_dma_coherent(struct device *dev)
+{
+	return 1
+}
+#endif
+
 #ifdef CONFIG_HAS_DMA
 #include <asm/dma-mapping.h>
 #else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 16:57:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm3tG-0001F3-8S; Wed, 05 Nov 2014 16:57:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xm3tE-0001Es-Sb
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 16:57:01 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	9B/F6-25547-CD65A545; Wed, 05 Nov 2014 16:57:00 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415206618!11888092!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16461 invoked from network); 5 Nov 2014 16:56:58 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-8.tower-31.messagelabs.com with SMTP;
	5 Nov 2014 16:56:58 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 73A2B1AA;
	Wed,  5 Nov 2014 10:56:53 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 520535FAD7;
	Wed,  5 Nov 2014 10:56:51 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id CCB8B13F8F5;
	Wed,  5 Nov 2014 10:56:49 -0600 (CST)
Date: Wed, 5 Nov 2014 16:56:47 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141105165646.GN32700@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 11:10:18AM +0000, Stefano Stabellini wrote:
> On Mon, 3 Nov 2014, Will Deacon wrote:
> > On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> > > On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > > > Introduce a boolean flag and an accessor function to check whether a
> > > > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > CC: will.deacon@arm.com
> > > 
> > > Will, Catalin,
> > > are you OK with this patch?
> > 
> > It would be nicer if the dma_coherent flag didn't have to be duplicated by
> > each architecture in dev_archdata. Is there any reason not to put it in the
> > core code?
> 
> Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> struct device as Catalin initially suggested, what would be the default
> for each architecture? Where would I set it for arch that don't use
> device tree?

You don't need to. An architecture that has coherent DMA always doesn't
need to do anything. One that has non-coherent DMA always only needs to
select HAVE_DMA_NONCOHERENT. One that has a mix of both needs to find a
way to set dev->dma_coherent. Since that's a new API you introduce, it
doesn't break any existing architectures.

Note that if !is_device_dma_coherent(), it doesn't always mean that
standard cache maintenance would be enough (but that's a Xen problem,
not sure how to solve).


diff --git a/arch/Kconfig b/arch/Kconfig
index 05d7a8a458d5..8462b2e7491b 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -203,6 +203,9 @@ config HAVE_DMA_ATTRS
 config HAVE_DMA_CONTIGUOUS
 	bool
 
+config HAVE_DMA_NONCOHERENT
+	bool
+
 config GENERIC_SMP_IDLE_THREAD
        bool
 
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 89c4b5ccc68d..fd7d5522764c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -40,6 +40,7 @@ config ARM
 	select HAVE_DMA_API_DEBUG
 	select HAVE_DMA_ATTRS
 	select HAVE_DMA_CONTIGUOUS if MMU
+	select HAVE_DMA_NONCOHERENT if OF
 	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
 	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d5857e..eb7a5aa64e0e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -46,6 +46,7 @@ config ARM64
 	select HAVE_DMA_API_DEBUG
 	select HAVE_DMA_ATTRS
 	select HAVE_DMA_CONTIGUOUS
+	select HAVE_DMA_NONCOHERENT
 	select HAVE_DYNAMIC_FTRACE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS
 	select HAVE_FTRACE_MCOUNT_RECORD
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 3b64d0bf5bba..7e827726b702 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -183,6 +183,7 @@ static void of_dma_configure(struct device *dev)
 	 * dma coherent operations.
 	 */
 	if (of_dma_is_coherent(dev->of_node)) {
+		dev->dma_coherent = true;
 		set_arch_dma_coherent_ops(dev);
 		dev_dbg(dev, "device is dma coherent\n");
 	}
diff --git a/include/linux/device.h b/include/linux/device.h
index ce1f21608b16..e00ca876db01 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -796,6 +796,7 @@ struct device {
 
 	bool			offline_disabled:1;
 	bool			offline:1;
+	bool			dma_coherent:1;
 };
 
 static inline struct device *kobj_to_dev(struct kobject *kobj)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d388160f42..0bdffba2337d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -78,6 +78,18 @@ static inline int is_device_dma_capable(struct device *dev)
 	return dev->dma_mask != NULL && *dev->dma_mask != DMA_MASK_NONE;
 }
 
+#ifdef CONFIG_HAVE_DMA_NONCOHERENT
+static inline int is_device_dma_coherent(struct device *dev)
+{
+	return dev->dma_coherent;
+}
+#else
+static inline int is_device_dma_coherent(struct device *dev)
+{
+	return 1
+}
+#endif
+
 #ifdef CONFIG_HAS_DMA
 #include <asm/dma-mapping.h>
 #else
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d5857e..eb7a5aa64e0e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -46,6 +46,7 @@ config ARM64
 	select HAVE_DMA_API_DEBUG
 	select HAVE_DMA_ATTRS
 	select HAVE_DMA_CONTIGUOUS
+	select HAVE_DMA_NONCOHERENT
 	select HAVE_DYNAMIC_FTRACE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS
 	select HAVE_FTRACE_MCOUNT_RECORD
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 3b64d0bf5bba..7e827726b702 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -183,6 +183,7 @@ static void of_dma_configure(struct device *dev)
 	 * dma coherent operations.
 	 */
 	if (of_dma_is_coherent(dev->of_node)) {
+		dev->dma_coherent = true;
 		set_arch_dma_coherent_ops(dev);
 		dev_dbg(dev, "device is dma coherent\n");
 	}
diff --git a/include/linux/device.h b/include/linux/device.h
index ce1f21608b16..e00ca876db01 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -796,6 +796,7 @@ struct device {
 
 	bool			offline_disabled:1;
 	bool			offline:1;
+	bool			dma_coherent:1;
 };
 
 static inline struct device *kobj_to_dev(struct kobject *kobj)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d388160f42..0bdffba2337d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -78,6 +78,18 @@ static inline int is_device_dma_capable(struct device *dev)
 	return dev->dma_mask != NULL && *dev->dma_mask != DMA_MASK_NONE;
 }
 
+#ifdef CONFIG_HAVE_DMA_NONCOHERENT
+static inline int is_device_dma_coherent(struct device *dev)
+{
+	return dev->dma_coherent;
+}
+#else
+static inline int is_device_dma_coherent(struct device *dev)
+{
+	return 1
+}
+#endif
+
 #ifdef CONFIG_HAS_DMA
 #include <asm/dma-mapping.h>
 #else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 16:59:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16:59:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm3vA-0001QZ-RX; Wed, 05 Nov 2014 16:59:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xm3v9-0001QM-Sp
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 16:58:59 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	F5/46-09284-3575A545; Wed, 05 Nov 2014 16:58:59 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415206733!11746894!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16624 invoked from network); 5 Nov 2014 16:58:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 16:58:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="188406067"
Message-ID: <545A5700.20902@citrix.com>
Date: Wed, 5 Nov 2014 16:57:36 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, <linux-kernel@vger.kernel.org>,
	<mgorman@suse.de>, <akpm@linux-foundation.org>, <hughd@google.com>
References: <20141105164141.GA27834@zion.uk.xensource.com>
In-Reply-To: <20141105164141.GA27834@zion.uk.xensource.com>
X-DLP: MIA2
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Pte_special broken on Xen PV when NUMA balancing is
	enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/11/14 16:41, Wei Liu wrote:
> Hi all
> 
> I'm developing virtual NUMA support for Xen. One thing I notice is that when
> NUMA balancing is enabled, kernel will crash with following backtrace.
> 
> [  404.281396] CPU: 0 PID: 1058 Comm: dd Tainted: G    B   W      3.18.0-rc3-bp+ #3
> [  404.281403]  0000000000000000 00007fd62eca3000 ffffffff817b7cac ffff880172d298b8
> [  404.281415]  ffffffff8110383f 0720072007300732 00000007fd62eca3 0720072007200720
> [  404.281426]  ffff880172d298b8 ffff88017300bbb0 00007fd62eca3000 0000000000000000
> [  404.281437] Call Trace:                                                      
> [  404.281444]  [<ffffffff817b7cac>] ? dump_stack+0x41/0x51                     
> [  404.281452]  [<ffffffff8110383f>] ? print_bad_pte+0x19f/0x1cb                
> [  404.281460]  [<ffffffff81104479>] ? vm_normal_page+0x51/0x87                 
> [  404.281469]  [<ffffffff8110c5ef>] ? change_protection+0x4fb/0x76a            
> [  404.281477]  [<ffffffff81106435>] ? handle_mm_fault+0x9e0/0xa11              
> [  404.281486]  [<ffffffff8111cc22>] ? change_prot_numa+0x13/0x24               
> [  404.281495]  [<ffffffff8106abf0>] ? task_numa_work+0x20c/0x2ac               
> [  404.281503]  [<ffffffff810615e7>] ? finish_task_switch+0x83/0xc5             
> [  404.281512]  [<ffffffff8105af10>] ? task_work_run+0x7b/0x8f                  
> [  404.281521]  [<ffffffff8100d732>] ? do_notify_resume+0x5a/0x6d               
> [  404.281529]  [<ffffffff817bf49f>] ? retint_signal+0x48/0x89                  
> [  404.281537]  [<ffffffff810012eb>] ? xen_hypercall_iret+0xb/0x20
> 
> Decoding page flags 0x366 we have _PAGE_SPECIAL(_PAGE_NUMA) and
> _PAGE_GLOBAL(_PAGE_PROTNONE) set, _PAGE_PRESENT not set. It's handling
> a NUMA hint page fault and crashes because the PTE in question is
> considered a special PTE by pte_special.
> 
> In a Xen PV guest, _PAGE_GLOBAL is added by hypervisor to mark the page
> a guest user space page. Xen PV kernel has already forbidden setting
> that bit during initialisation. It's a bit unfortunate that there's
> still clash with _PAGE_PROTNONE.

_PAGE_IOMAP is no more (f955371 "x86: remove the Xen-specific
_PAGE_IOMAP PTE flag) so there's now a spare _PAGE_SOFTW2 that could be
used for NUMA hinting, instead of this confusing/complex aliasing.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 16:59:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 16:59:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm3vA-0001QZ-RX; Wed, 05 Nov 2014 16:59:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xm3v9-0001QM-Sp
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 16:58:59 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	F5/46-09284-3575A545; Wed, 05 Nov 2014 16:58:59 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415206733!11746894!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16624 invoked from network); 5 Nov 2014 16:58:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 16:58:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="188406067"
Message-ID: <545A5700.20902@citrix.com>
Date: Wed, 5 Nov 2014 16:57:36 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, <linux-kernel@vger.kernel.org>,
	<mgorman@suse.de>, <akpm@linux-foundation.org>, <hughd@google.com>
References: <20141105164141.GA27834@zion.uk.xensource.com>
In-Reply-To: <20141105164141.GA27834@zion.uk.xensource.com>
X-DLP: MIA2
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Pte_special broken on Xen PV when NUMA balancing is
	enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/11/14 16:41, Wei Liu wrote:
> Hi all
> 
> I'm developing virtual NUMA support for Xen. One thing I notice is that when
> NUMA balancing is enabled, kernel will crash with following backtrace.
> 
> [  404.281396] CPU: 0 PID: 1058 Comm: dd Tainted: G    B   W      3.18.0-rc3-bp+ #3
> [  404.281403]  0000000000000000 00007fd62eca3000 ffffffff817b7cac ffff880172d298b8
> [  404.281415]  ffffffff8110383f 0720072007300732 00000007fd62eca3 0720072007200720
> [  404.281426]  ffff880172d298b8 ffff88017300bbb0 00007fd62eca3000 0000000000000000
> [  404.281437] Call Trace:                                                      
> [  404.281444]  [<ffffffff817b7cac>] ? dump_stack+0x41/0x51                     
> [  404.281452]  [<ffffffff8110383f>] ? print_bad_pte+0x19f/0x1cb                
> [  404.281460]  [<ffffffff81104479>] ? vm_normal_page+0x51/0x87                 
> [  404.281469]  [<ffffffff8110c5ef>] ? change_protection+0x4fb/0x76a            
> [  404.281477]  [<ffffffff81106435>] ? handle_mm_fault+0x9e0/0xa11              
> [  404.281486]  [<ffffffff8111cc22>] ? change_prot_numa+0x13/0x24               
> [  404.281495]  [<ffffffff8106abf0>] ? task_numa_work+0x20c/0x2ac               
> [  404.281503]  [<ffffffff810615e7>] ? finish_task_switch+0x83/0xc5             
> [  404.281512]  [<ffffffff8105af10>] ? task_work_run+0x7b/0x8f                  
> [  404.281521]  [<ffffffff8100d732>] ? do_notify_resume+0x5a/0x6d               
> [  404.281529]  [<ffffffff817bf49f>] ? retint_signal+0x48/0x89                  
> [  404.281537]  [<ffffffff810012eb>] ? xen_hypercall_iret+0xb/0x20
> 
> Decoding page flags 0x366 we have _PAGE_SPECIAL(_PAGE_NUMA) and
> _PAGE_GLOBAL(_PAGE_PROTNONE) set, _PAGE_PRESENT not set. It's handling
> a NUMA hint page fault and crashes because the PTE in question is
> considered a special PTE by pte_special.
> 
> In a Xen PV guest, _PAGE_GLOBAL is added by hypervisor to mark the page
> a guest user space page. Xen PV kernel has already forbidden setting
> that bit during initialisation. It's a bit unfortunate that there's
> still clash with _PAGE_PROTNONE.

_PAGE_IOMAP is no more (f955371 "x86: remove the Xen-specific
_PAGE_IOMAP PTE flag) so there's now a spare _PAGE_SOFTW2 that could be
used for NUMA hinting, instead of this confusing/complex aliasing.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 17:00:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 17:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm3wf-0001cV-D3; Wed, 05 Nov 2014 17:00:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1Xm3we-0001cN-Gh
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 17:00:32 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	40/79-02698-FA75A545; Wed, 05 Nov 2014 17:00:31 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415206830!12745882!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28392 invoked from network); 5 Nov 2014 17:00:30 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 17:00:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 05 Nov 2014 17:00:30 +0000
Message-Id: <545A57AD02000078000C1037@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 05 Nov 2014 17:00:29 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
In-Reply-To: <545992A2.8070309@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> "Chen, Tiejun" <tiejun.chen@intel.com> 11/05/14 3:59 AM >>>

Everything up to here sounded reasonable.

>Next, we need a new domctl to provide these info, 'pci_rdmforce' and 
>'rdm_force' when parse the config file. Certainly we may need to 
>introduce and set two new fields in strcut domain, and since then we 
>just use these fields to modify our current existing iommu callback 
>inside to support our policy. I mean we just expose those associated 
>RMRR entry. I think its easy to implement this since inside Xen we can 
>know which entry is owned by which device. So this can benefit us to 
>avoid modifying any tools codes and most Xen codes we already addressed.

Whether a domctl is the right approach I can't really tell with this
somewhat vague description.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 17:00:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 17:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm3wf-0001cV-D3; Wed, 05 Nov 2014 17:00:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1Xm3we-0001cN-Gh
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 17:00:32 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	40/79-02698-FA75A545; Wed, 05 Nov 2014 17:00:31 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415206830!12745882!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28392 invoked from network); 5 Nov 2014 17:00:30 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 17:00:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 05 Nov 2014 17:00:30 +0000
Message-Id: <545A57AD02000078000C1037@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 05 Nov 2014 17:00:29 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544A84B10200007800042016@mail.emea.novell.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
In-Reply-To: <545992A2.8070309@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> "Chen, Tiejun" <tiejun.chen@intel.com> 11/05/14 3:59 AM >>>

Everything up to here sounded reasonable.

>Next, we need a new domctl to provide these info, 'pci_rdmforce' and 
>'rdm_force' when parse the config file. Certainly we may need to 
>introduce and set two new fields in strcut domain, and since then we 
>just use these fields to modify our current existing iommu callback 
>inside to support our policy. I mean we just expose those associated 
>RMRR entry. I think its easy to implement this since inside Xen we can 
>know which entry is owned by which device. So this can benefit us to 
>avoid modifying any tools codes and most Xen codes we already addressed.

Whether a domctl is the right approach I can't really tell with this
somewhat vague description.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 17:15:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 17:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm4Ax-0002Cs-Rh; Wed, 05 Nov 2014 17:15:19 +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 1Xm4Aw-0002Cn-24
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 17:15:18 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	BB/F7-02576-52B5A545; Wed, 05 Nov 2014 17:15:17 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415207716!12762797!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9538 invoked from network); 5 Nov 2014 17:15:16 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-2.tower-27.messagelabs.com with SMTP;
	5 Nov 2014 17:15:16 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 9B69158142E;
	Wed,  5 Nov 2014 09:15:14 -0800 (PST)
Date: Wed, 05 Nov 2014 12:15:11 -0500 (EST)
Message-Id: <20141105.121511.887564988610007845.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1415181080.11486.63.camel@citrix.com>
References: <5457C807.5080509@linaro.org>
	<20141104.161704.1690311989900127361.davem@davemloft.net>
	<1415181080.11486.63.camel@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Wed, 05 Nov 2014 09:15:15 -0800 (PST)
Cc: zoltan.kiss@linaro.org, wei.liu2@citrix.com, netdev@vger.kernel.org,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	malcolm.crossley@citrix.com
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 5 Nov 2014 09:51:20 +0000

> Is this also true for things which hit the iptables paths? I suppose
> they must necessarily have already been through the protocol demux stage
> before iptables would even be able to interpret them as e.g. an IP
> packet.

Netfilter often takes a different approach, by using
skb_header_pointer() which returns a direct pointer if the linear area
contains the requested range already, or alternatively copies from the
frags into a user supplied on-stack header buffer if not.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 17:15:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 17:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm4Ax-0002Cs-Rh; Wed, 05 Nov 2014 17:15:19 +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 1Xm4Aw-0002Cn-24
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 17:15:18 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	BB/F7-02576-52B5A545; Wed, 05 Nov 2014 17:15:17 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415207716!12762797!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9538 invoked from network); 5 Nov 2014 17:15:16 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-2.tower-27.messagelabs.com with SMTP;
	5 Nov 2014 17:15:16 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 9B69158142E;
	Wed,  5 Nov 2014 09:15:14 -0800 (PST)
Date: Wed, 05 Nov 2014 12:15:11 -0500 (EST)
Message-Id: <20141105.121511.887564988610007845.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1415181080.11486.63.camel@citrix.com>
References: <5457C807.5080509@linaro.org>
	<20141104.161704.1690311989900127361.davem@davemloft.net>
	<1415181080.11486.63.camel@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Wed, 05 Nov 2014 09:15:15 -0800 (PST)
Cc: zoltan.kiss@linaro.org, wei.liu2@citrix.com, netdev@vger.kernel.org,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	malcolm.crossley@citrix.com
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 5 Nov 2014 09:51:20 +0000

> Is this also true for things which hit the iptables paths? I suppose
> they must necessarily have already been through the protocol demux stage
> before iptables would even be able to interpret them as e.g. an IP
> packet.

Netfilter often takes a different approach, by using
skb_header_pointer() which returns a direct pointer if the linear area
contains the requested range already, or alternatively copies from the
frags into a user supplied on-stack header buffer if not.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 17:16:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 17:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm4Bh-0002El-8b; Wed, 05 Nov 2014 17:16: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 1Xm4Bf-0002Eb-I1
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 17:16:03 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	19/05-24124-25B5A545; Wed, 05 Nov 2014 17:16:02 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415207762!11437894!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20307 invoked from network); 5 Nov 2014 17:16:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Nov 2014 17:16:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 05 Nov 2014 17:16:01 +0000
Message-Id: <545A5B4F02000078000C1073@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 05 Nov 2014 17:15:59 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <ian.campbell@citrix.com>,<julien.grall@linaro.org>,
	<xen-devel@lists.xenproject.org>, <konrad.wilk@oracle.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
In-Reply-To: <54590C48.4080100@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>> It also needs Acks from Daniel and Jan.
>
>This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
>required. Would Ian C. ack be enough?

Yes, it would.

>Anyway, Jan do you have any objection on this patch?

As said previously, I'm not particularly happy about it, but I also don't strongly
mind it going in in the current shape.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 17:16:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 17:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm4Bh-0002El-8b; Wed, 05 Nov 2014 17:16: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 1Xm4Bf-0002Eb-I1
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 17:16:03 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	19/05-24124-25B5A545; Wed, 05 Nov 2014 17:16:02 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415207762!11437894!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20307 invoked from network); 5 Nov 2014 17:16:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Nov 2014 17:16:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 05 Nov 2014 17:16:01 +0000
Message-Id: <545A5B4F02000078000C1073@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 05 Nov 2014 17:15:59 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <ian.campbell@citrix.com>,<julien.grall@linaro.org>,
	<xen-devel@lists.xenproject.org>, <konrad.wilk@oracle.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
In-Reply-To: <54590C48.4080100@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>> It also needs Acks from Daniel and Jan.
>
>This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
>required. Would Ian C. ack be enough?

Yes, it would.

>Anyway, Jan do you have any objection on this patch?

As said previously, I'm not particularly happy about it, but I also don't strongly
mind it going in in the current shape.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 17:16:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 17:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm4C3-0002I7-Lt; Wed, 05 Nov 2014 17:16:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Xm4C2-0002Hx-SU
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 17:16:26 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B1/69-31453-A6B5A545; Wed, 05 Nov 2014 17:16:26 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415207785!6014368!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25814 invoked from network); 5 Nov 2014 17:16:25 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-14.tower-206.messagelabs.com with SMTP;
	5 Nov 2014 17:16:25 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 8D44C5846AF;
	Wed,  5 Nov 2014 09:16:23 -0800 (PST)
Date: Wed, 05 Nov 2014 12:16:22 -0500 (EST)
Message-Id: <20141105.121622.1937064439841390520.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1415181185.11486.65.camel@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
	<20141104.164113.2265592775058059992.davem@davemloft.net>
	<1415181185.11486.65.camel@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Wed, 05 Nov 2014 09:16:24 -0800 (PST)
Cc: netdev@vger.kernel.org, malcolm.crossley@citrix.com, wei.liu2@citrix.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 5 Nov 2014 09:53:05 +0000

> I'd like to see the commit message expanded to explain why this isn't
> introducing a (security) bug by not pulling enough stuff into the header
> (IOW the conclusion of the discussion).

Just because a fundamental aspect of how we handle packets isn't clear
to some people, doesn't mean that every commit that depends upon that
invariant has to explain it in the commit message. :-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 17:16:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 17:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm4C3-0002I7-Lt; Wed, 05 Nov 2014 17:16:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Xm4C2-0002Hx-SU
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 17:16:26 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B1/69-31453-A6B5A545; Wed, 05 Nov 2014 17:16:26 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415207785!6014368!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25814 invoked from network); 5 Nov 2014 17:16:25 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-14.tower-206.messagelabs.com with SMTP;
	5 Nov 2014 17:16:25 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 8D44C5846AF;
	Wed,  5 Nov 2014 09:16:23 -0800 (PST)
Date: Wed, 05 Nov 2014 12:16:22 -0500 (EST)
Message-Id: <20141105.121622.1937064439841390520.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1415181185.11486.65.camel@citrix.com>
References: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>
	<20141104.164113.2265592775058059992.davem@davemloft.net>
	<1415181185.11486.65.camel@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Wed, 05 Nov 2014 09:16:24 -0800 (PST)
Cc: netdev@vger.kernel.org, malcolm.crossley@citrix.com, wei.liu2@citrix.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove
 unconditional pull_skb_tail in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 5 Nov 2014 09:53:05 +0000

> I'd like to see the commit message expanded to explain why this isn't
> introducing a (security) bug by not pulling enough stuff into the header
> (IOW the conclusion of the discussion).

Just because a fundamental aspect of how we handle packets isn't clear
to some people, doesn't mean that every commit that depends upon that
invariant has to explain it in the commit message. :-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 17:32:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 17:32:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm4RW-0002xb-Bn; Wed, 05 Nov 2014 17:32:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm4RU-0002xW-Sd
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 17:32:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	61/08-24532-82F5A545; Wed, 05 Nov 2014 17:32:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415208743!5737531!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18990 invoked from network); 5 Nov 2014 17:32:23 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 17:32:23 -0000
Received: by mail-wg0-f47.google.com with SMTP id a1so1470007wgh.6
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 09:32:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:content-type:content-transfer-encoding;
	bh=eqsVrdpgTCjpAEnQ6vr9FTHwxJvw04FS6eQJoNEIocc=;
	b=bMfI75D5wh7I5aINdSiELAgi9HhSNwBk+A6Z9XFUwkv0nRMNcXlro3jeDM7jMdAmGE
	IxqzgxRrtxTYrgA1G7+EpdNS2cqD3ruhyTx4w4H8uUctJf1h2wFXt27mr5mABzvzS94i
	oNvDeC6WUmHrfoGiH/Mm9d5EI6TqhpHyRWCU8xkdkTtbfZPOdmypZ553LtMxDMjOVem/
	sZ+XUpN4cJ9r7RvYgdh3nSaLm2/gXEkfeOheVy1CWXN0i17h5phL/myXIR2BGmujY8CW
	Npqh1WPUxQJ6ZBiVZN9mNGtYuSPzXjulXtfx5Dxql5NN4mYQJ/8ipokoXd9K+LRWDdLF
	4qEQ==
X-Gm-Message-State: ALoCoQnIiDEkv06k93kBlvC29y8QL16ZgorlY3MfFlFVHllRrxkMO7K94oI9Lb0PANqXfTctrHEr
X-Received: by 10.181.27.135 with SMTP id jg7mr7595549wid.56.1415208743282;
	Wed, 05 Nov 2014 09:32:23 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id u13sm5306575wiv.10.2014.11.05.09.32.22
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 09:32:22 -0800 (PST)
Message-ID: <545A5F1F.9030006@linaro.org>
Date: Wed, 05 Nov 2014 17:32:15 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] xen/arm: kernel BUG at
	/local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

I've tried your patch series [1] "introduce GNTTABOP_cache_flush"
on midway with non-LPAE (i.e short descriptor) kernel.

While your series should fix the cache flush on this kind of kernel,
I'm still hitting a BUG_ON when I boot a guest (see stack trace [2]).

>From a quick look this is because the dma and physical address don't have
the same size (resp. 64 and 32 bits). Technically xen_bus_to_phys doesn't really
have a meaning on Xen ARM: the address is still a DMA address but we cast it to
a physical address (not sure why?).

It occurs when I use the multi_v7 config (+ XEN) as DOM0. Disabling CONFIG_LPAE
in the config should also do the job.

Regards,

[1] https://lkml.org/lkml/2014/10/27/441

[2] Stack trace:

[   98.092290] dma 0x2b6769000 paddr 0xb6769000
[   98.096475] ------------[ cut here ]------------
[   98.101147] kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102!
[   98.109219] Internal error: Oops - BUG: 0 [#1] SMP ARM
[   98.114427] Modules linked in:
[   98.117554] CPU: 3 PID: 48 Comm: irq/115-highban Not tainted 3.18.0-rc3-00051-g93cf079-dirty #231
[   98.126493] task: db281680 ti: db40e000 task.ti: db40e000
[   98.131965] PC is at xen_unmap_single+0xc4/0xc8
[   98.136563] LR is at xen_unmap_single+0xc4/0xc8
[   98.141162] pc : [<c04d1640>]    lr : [<c04d1640>]    psr: 60000013
[   98.141162] sp : db40fdf0  ip : 00000000  fp : b6769000
[   98.152793] r10: 00000200  r9 : 00000002  r8 : 00000002
[   98.158088] r7 : 00000000  r6 : 002b6769  r5 : 00000002  r4 : b6769000
[   98.164693] r3 : 00000753  r2 : 1af49000  r1 : dbbc73bc  r0 : 00000020
[   98.171282] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   98.178660] Control: 10c5387d  Table: 39e3c06a  DAC: 00000015
[   98.184475] Process irq/115-highban (pid: 48, stack limit = 0xdb40e250)
[   98.191159] Stack: (0xdb40fdf0 to 0xdb410000)
[   98.195586] fde0:                                     b6769000 00000020 00000000 00000002
[   98.203833] fe00: db40fe00 db0ea210 00000000 d98a1a80 00000001 00000001 00000002 db0ea210
[   98.212079] fe20: 00000000 db3e3410 db3f1790 c04d1880 00000200 00000002 00000000 00000016
[   98.220325] fe40: 0000091e db4100b8 d98a1a80 db410000 00000001 000000b0 00000001 c05cdddc
[   98.228570] fe60: 00000000 c0262f9c db08c01c db281680 db40e010 db4100b8 db410000 db4116c8
[   98.236817] fe80: 00000001 c05ce0b0 00000000 00000000 db410000 c05ce478 db410000 db4116c8
[   98.245068] fea0: 00000000 db410000 e0880100 00000008 00000000 e0880000 00000001 c05e5288
[   98.253309] fec0: c0c8a994 db40fee8 e0804000 c020897c c041c868 60000013 ffffffff 00000000
[   98.261554] fee0: db3f1890 0000001f 00000073 00000001 db3f1890 c02836ac db00f7d4 c05e57d0
[   98.269801] ff00: c05e5788 db3f6340 db00f780 00000000 00000001 db00f780 db3f6340 c02836c8
[   98.278047] ff20: db3f6360 db40e000 00000000 c02839ec c02838b4 db40e030 00000000 c02837f8
[   98.286293] ff40: 00000000 db3f6380 00000000 db3f6340 c02838b4 00000000 00000000 00000000
[   98.294538] ff60: 00000000 c0262358 00000000 00000000 00000000 db3f6340 00000000 00000000
[   98.302785] ff80: db40ff80 db40ff80 00000000 00000000 db40ff90 db40ff90 db40ffac db3f6380
[   98.311031] ffa0: c0262280 00000000 00000000 c020f278 00000000 00000000 00000000 00000000
[   98.319276] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   98.327522] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[   98.335780] [<c04d1640>] (xen_unmap_single) from [<c04d1880>] (xen_swiotlb_unmap_sg_attrs+0x48/0x68)
[   98.344974] [<c04d1880>] (xen_swiotlb_unmap_sg_attrs) from [<c05cdddc>] (ata_sg_clean+0x8c/0x120)
[   98.353912] [<c05cdddc>] (ata_sg_clean) from [<c05ce0b0>] (__ata_qc_complete+0x34/0x144)
[   98.362071] [<c05ce0b0>] (__ata_qc_complete) from [<c05ce478>] (ata_qc_complete_multiple+0xa0/0xd4)
[   98.371194] [<c05ce478>] (ata_qc_complete_multiple) from [<c05e5288>] (ahci_port_thread_fn+0x138/0x638)
[   98.380649] [<c05e5288>] (ahci_port_thread_fn) from [<c05e57d0>] (ahci_thread_fn+0x48/0x90)
[   98.389067] [<c05e57d0>] (ahci_thread_fn) from [<c02836c8>] (irq_thread_fn+0x1c/0x40)
[   98.396970] [<c02836c8>] (irq_thread_fn) from [<c02839ec>] (irq_thread+0x138/0x174)
[   98.404693] [<c02839ec>] (irq_thread) from [<c0262358>] (kthread+0xd8/0xf0)
[   98.411723] [<c0262358>] (kthread) from [<c020f278>] (ret_from_fork+0x14/0x3c)
[   98.419011] Code: e1a02004 e1a03005 e34c00ad eb0f9c9a (e7f001f2) 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 17:32:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 17:32:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm4RW-0002xb-Bn; Wed, 05 Nov 2014 17:32:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm4RU-0002xW-Sd
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 17:32:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	61/08-24532-82F5A545; Wed, 05 Nov 2014 17:32:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415208743!5737531!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18990 invoked from network); 5 Nov 2014 17:32:23 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 17:32:23 -0000
Received: by mail-wg0-f47.google.com with SMTP id a1so1470007wgh.6
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 09:32:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:content-type:content-transfer-encoding;
	bh=eqsVrdpgTCjpAEnQ6vr9FTHwxJvw04FS6eQJoNEIocc=;
	b=bMfI75D5wh7I5aINdSiELAgi9HhSNwBk+A6Z9XFUwkv0nRMNcXlro3jeDM7jMdAmGE
	IxqzgxRrtxTYrgA1G7+EpdNS2cqD3ruhyTx4w4H8uUctJf1h2wFXt27mr5mABzvzS94i
	oNvDeC6WUmHrfoGiH/Mm9d5EI6TqhpHyRWCU8xkdkTtbfZPOdmypZ553LtMxDMjOVem/
	sZ+XUpN4cJ9r7RvYgdh3nSaLm2/gXEkfeOheVy1CWXN0i17h5phL/myXIR2BGmujY8CW
	Npqh1WPUxQJ6ZBiVZN9mNGtYuSPzXjulXtfx5Dxql5NN4mYQJ/8ipokoXd9K+LRWDdLF
	4qEQ==
X-Gm-Message-State: ALoCoQnIiDEkv06k93kBlvC29y8QL16ZgorlY3MfFlFVHllRrxkMO7K94oI9Lb0PANqXfTctrHEr
X-Received: by 10.181.27.135 with SMTP id jg7mr7595549wid.56.1415208743282;
	Wed, 05 Nov 2014 09:32:23 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id u13sm5306575wiv.10.2014.11.05.09.32.22
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 09:32:22 -0800 (PST)
Message-ID: <545A5F1F.9030006@linaro.org>
Date: Wed, 05 Nov 2014 17:32:15 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] xen/arm: kernel BUG at
	/local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

I've tried your patch series [1] "introduce GNTTABOP_cache_flush"
on midway with non-LPAE (i.e short descriptor) kernel.

While your series should fix the cache flush on this kind of kernel,
I'm still hitting a BUG_ON when I boot a guest (see stack trace [2]).

>From a quick look this is because the dma and physical address don't have
the same size (resp. 64 and 32 bits). Technically xen_bus_to_phys doesn't really
have a meaning on Xen ARM: the address is still a DMA address but we cast it to
a physical address (not sure why?).

It occurs when I use the multi_v7 config (+ XEN) as DOM0. Disabling CONFIG_LPAE
in the config should also do the job.

Regards,

[1] https://lkml.org/lkml/2014/10/27/441

[2] Stack trace:

[   98.092290] dma 0x2b6769000 paddr 0xb6769000
[   98.096475] ------------[ cut here ]------------
[   98.101147] kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102!
[   98.109219] Internal error: Oops - BUG: 0 [#1] SMP ARM
[   98.114427] Modules linked in:
[   98.117554] CPU: 3 PID: 48 Comm: irq/115-highban Not tainted 3.18.0-rc3-00051-g93cf079-dirty #231
[   98.126493] task: db281680 ti: db40e000 task.ti: db40e000
[   98.131965] PC is at xen_unmap_single+0xc4/0xc8
[   98.136563] LR is at xen_unmap_single+0xc4/0xc8
[   98.141162] pc : [<c04d1640>]    lr : [<c04d1640>]    psr: 60000013
[   98.141162] sp : db40fdf0  ip : 00000000  fp : b6769000
[   98.152793] r10: 00000200  r9 : 00000002  r8 : 00000002
[   98.158088] r7 : 00000000  r6 : 002b6769  r5 : 00000002  r4 : b6769000
[   98.164693] r3 : 00000753  r2 : 1af49000  r1 : dbbc73bc  r0 : 00000020
[   98.171282] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   98.178660] Control: 10c5387d  Table: 39e3c06a  DAC: 00000015
[   98.184475] Process irq/115-highban (pid: 48, stack limit = 0xdb40e250)
[   98.191159] Stack: (0xdb40fdf0 to 0xdb410000)
[   98.195586] fde0:                                     b6769000 00000020 00000000 00000002
[   98.203833] fe00: db40fe00 db0ea210 00000000 d98a1a80 00000001 00000001 00000002 db0ea210
[   98.212079] fe20: 00000000 db3e3410 db3f1790 c04d1880 00000200 00000002 00000000 00000016
[   98.220325] fe40: 0000091e db4100b8 d98a1a80 db410000 00000001 000000b0 00000001 c05cdddc
[   98.228570] fe60: 00000000 c0262f9c db08c01c db281680 db40e010 db4100b8 db410000 db4116c8
[   98.236817] fe80: 00000001 c05ce0b0 00000000 00000000 db410000 c05ce478 db410000 db4116c8
[   98.245068] fea0: 00000000 db410000 e0880100 00000008 00000000 e0880000 00000001 c05e5288
[   98.253309] fec0: c0c8a994 db40fee8 e0804000 c020897c c041c868 60000013 ffffffff 00000000
[   98.261554] fee0: db3f1890 0000001f 00000073 00000001 db3f1890 c02836ac db00f7d4 c05e57d0
[   98.269801] ff00: c05e5788 db3f6340 db00f780 00000000 00000001 db00f780 db3f6340 c02836c8
[   98.278047] ff20: db3f6360 db40e000 00000000 c02839ec c02838b4 db40e030 00000000 c02837f8
[   98.286293] ff40: 00000000 db3f6380 00000000 db3f6340 c02838b4 00000000 00000000 00000000
[   98.294538] ff60: 00000000 c0262358 00000000 00000000 00000000 db3f6340 00000000 00000000
[   98.302785] ff80: db40ff80 db40ff80 00000000 00000000 db40ff90 db40ff90 db40ffac db3f6380
[   98.311031] ffa0: c0262280 00000000 00000000 c020f278 00000000 00000000 00000000 00000000
[   98.319276] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   98.327522] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[   98.335780] [<c04d1640>] (xen_unmap_single) from [<c04d1880>] (xen_swiotlb_unmap_sg_attrs+0x48/0x68)
[   98.344974] [<c04d1880>] (xen_swiotlb_unmap_sg_attrs) from [<c05cdddc>] (ata_sg_clean+0x8c/0x120)
[   98.353912] [<c05cdddc>] (ata_sg_clean) from [<c05ce0b0>] (__ata_qc_complete+0x34/0x144)
[   98.362071] [<c05ce0b0>] (__ata_qc_complete) from [<c05ce478>] (ata_qc_complete_multiple+0xa0/0xd4)
[   98.371194] [<c05ce478>] (ata_qc_complete_multiple) from [<c05e5288>] (ahci_port_thread_fn+0x138/0x638)
[   98.380649] [<c05e5288>] (ahci_port_thread_fn) from [<c05e57d0>] (ahci_thread_fn+0x48/0x90)
[   98.389067] [<c05e57d0>] (ahci_thread_fn) from [<c02836c8>] (irq_thread_fn+0x1c/0x40)
[   98.396970] [<c02836c8>] (irq_thread_fn) from [<c02839ec>] (irq_thread+0x138/0x174)
[   98.404693] [<c02839ec>] (irq_thread) from [<c0262358>] (kthread+0xd8/0xf0)
[   98.411723] [<c0262358>] (kthread) from [<c020f278>] (ret_from_fork+0x14/0x3c)
[   98.419011] Code: e1a02004 e1a03005 e34c00ad eb0f9c9a (e7f001f2) 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 18:05:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 18:05:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm4we-0003pf-Ed; Wed, 05 Nov 2014 18:04:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xm4wd-0003pa-Lw
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 18:04:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2F/07-09842-2B66A545; Wed, 05 Nov 2014 18:04:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415210664!13049796!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTg3ODYgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2206 invoked from network); 5 Nov 2014 18:04:25 -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;
	5 Nov 2014 18:04:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,321,1413244800"; d="scan'208";a="188431776"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 13:03:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xm4iW-0004yK-Gu;
	Wed, 05 Nov 2014 17:50:00 +0000
Date: Wed, 5 Nov 2014 17:49:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Steven Haigh <netwiz@crc.id.au>
In-Reply-To: <5447D30A.4040704@crc.id.au>
Message-ID: <alpine.DEB.2.02.1411051645140.22875@kaball.uk.xensource.com>
References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au>
	<1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-106688891-1415209793=:22875"
X-DLP: MIA2
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] vnc=1 / pvgrub / close fb: backend at
 /local/domain/0/backend/vfb/xx/0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-106688891-1415209793=:22875
Content-Type: text/plain; charset="US-ASCII"

Hello Steven,
I have found some time to debug this myself.
I couldn't reproduce the booting issue that you reported: in my case
after seeing the grub boot menu I can successfully boot the kernel
without problems.

However I can reproduce the timeout issue that you are seeing: the
timeout doesn't work properly in graphics mode.

The reason is that the with a graphics terminal you checkkey () return 0
even when pressing no keys, resulting in wrong behaviour in run_menu. 

Does the following patch (also attached) fixes your issues?


diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
new file mode 100644
index 0000000..fe17b20
--- /dev/null
+++ b/stubdom/grub.patches/11graphics-keyboard.diff
@@ -0,0 +1,13 @@
+diff --git a/stage2/stage2.c b/stage2/stage2.c
+index 9d9fcc3..8353a3b 100644
+--- a/stage2/stage2.c
++++ b/stage2/stage2.c
+@@ -395,7 +395,7 @@ restart:
+ 	 pressed.  
+ 	 This avoids polling (relevant in the grub-shell and later on
+ 	 in grub if interrupt driven I/O is done).  */
+-      if (checkkey () >= 0 || grub_timeout < 0)
++      if (checkkey () > 0 || grub_timeout < 0)
+ 	{
+ 	  /* Key was pressed, show which entry is selected before GETKEY,
+ 	     since we're comming in here also on GRUB_TIMEOUT == -1 and



On Thu, 23 Oct 2014, Steven Haigh wrote:
> On 23/10/2014 2:40 AM, Ian Campbell wrote:
> > On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
> > 
> >> Output using pv-grub:
> > 
> > Can you also post the qemu logs please (under /var/log/xen somewhere I
> > think).
> 
> I get very little out of this:
> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
> [root@dom0 xen]# cat xl-dev.vm.log
> Waiting for domain dev.vm (domid 36) to die [pid 6970]
> 
> That's it :\
> 
> >> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
> >> 00007fffb4573638 error 4
> > 
> > That might be a smoking gun. Is there a core dump and/or could you try
> > and run qemu under gdb?
> 
> Any hints on doing this? I can't say I'm a gdb guru.... I can't find any
> core dumps anywhere so that's not really helpful...
> 
> -- 
> Steven Haigh
> 
> Email: netwiz@crc.id.au
> Web: http://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> 
> 
--1342847746-106688891-1415209793=:22875
Content-Type: text/plain; charset="US-ASCII"; name="2"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1411051749530.22875@kaball.uk.xensource.com>
Content-Description: 
Content-Disposition: attachment; filename="2"

ZGlmZiAtLWdpdCBhL3N0dWJkb20vZ3J1Yi5wYXRjaGVzLzExZ3JhcGhpY3Mt
a2V5Ym9hcmQuZGlmZiBiL3N0dWJkb20vZ3J1Yi5wYXRjaGVzLzExZ3JhcGhp
Y3Mta2V5Ym9hcmQuZGlmZg0KbmV3IGZpbGUgbW9kZSAxMDA2NDQNCmluZGV4
IDAwMDAwMDAuLmZlMTdiMjANCi0tLSAvZGV2L251bGwNCisrKyBiL3N0dWJk
b20vZ3J1Yi5wYXRjaGVzLzExZ3JhcGhpY3Mta2V5Ym9hcmQuZGlmZg0KQEAg
LTAsMCArMSwxMyBAQA0KK2RpZmYgLS1naXQgYS9zdGFnZTIvc3RhZ2UyLmMg
Yi9zdGFnZTIvc3RhZ2UyLmMNCitpbmRleCA5ZDlmY2MzLi44MzUzYTNiIDEw
MDY0NA0KKy0tLSBhL3N0YWdlMi9zdGFnZTIuYw0KKysrKyBiL3N0YWdlMi9z
dGFnZTIuYw0KK0BAIC0zOTUsNyArMzk1LDcgQEAgcmVzdGFydDoNCisgCSBw
cmVzc2VkLiAgDQorIAkgVGhpcyBhdm9pZHMgcG9sbGluZyAocmVsZXZhbnQg
aW4gdGhlIGdydWItc2hlbGwgYW5kIGxhdGVyIG9uDQorIAkgaW4gZ3J1YiBp
ZiBpbnRlcnJ1cHQgZHJpdmVuIEkvTyBpcyBkb25lKS4gICovDQorLSAgICAg
IGlmIChjaGVja2tleSAoKSA+PSAwIHx8IGdydWJfdGltZW91dCA8IDApDQor
KyAgICAgIGlmIChjaGVja2tleSAoKSA+IDAgfHwgZ3J1Yl90aW1lb3V0IDwg
MCkNCisgCXsNCisgCSAgLyogS2V5IHdhcyBwcmVzc2VkLCBzaG93IHdoaWNo
IGVudHJ5IGlzIHNlbGVjdGVkIGJlZm9yZSBHRVRLRVksDQorIAkgICAgIHNp
bmNlIHdlJ3JlIGNvbW1pbmcgaW4gaGVyZSBhbHNvIG9uIEdSVUJfVElNRU9V
VCA9PSAtMSBhbmQNCg==

--1342847746-106688891-1415209793=:22875
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-106688891-1415209793=:22875--


From xen-devel-bounces@lists.xen.org Wed Nov 05 18:05:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 18:05:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm4we-0003pf-Ed; Wed, 05 Nov 2014 18:04:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xm4wd-0003pa-Lw
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 18:04:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2F/07-09842-2B66A545; Wed, 05 Nov 2014 18:04:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415210664!13049796!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTg3ODYgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2206 invoked from network); 5 Nov 2014 18:04:25 -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;
	5 Nov 2014 18:04:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,321,1413244800"; d="scan'208";a="188431776"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 13:03:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xm4iW-0004yK-Gu;
	Wed, 05 Nov 2014 17:50:00 +0000
Date: Wed, 5 Nov 2014 17:49:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Steven Haigh <netwiz@crc.id.au>
In-Reply-To: <5447D30A.4040704@crc.id.au>
Message-ID: <alpine.DEB.2.02.1411051645140.22875@kaball.uk.xensource.com>
References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au>
	<1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-106688891-1415209793=:22875"
X-DLP: MIA2
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] vnc=1 / pvgrub / close fb: backend at
 /local/domain/0/backend/vfb/xx/0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-106688891-1415209793=:22875
Content-Type: text/plain; charset="US-ASCII"

Hello Steven,
I have found some time to debug this myself.
I couldn't reproduce the booting issue that you reported: in my case
after seeing the grub boot menu I can successfully boot the kernel
without problems.

However I can reproduce the timeout issue that you are seeing: the
timeout doesn't work properly in graphics mode.

The reason is that the with a graphics terminal you checkkey () return 0
even when pressing no keys, resulting in wrong behaviour in run_menu. 

Does the following patch (also attached) fixes your issues?


diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
new file mode 100644
index 0000000..fe17b20
--- /dev/null
+++ b/stubdom/grub.patches/11graphics-keyboard.diff
@@ -0,0 +1,13 @@
+diff --git a/stage2/stage2.c b/stage2/stage2.c
+index 9d9fcc3..8353a3b 100644
+--- a/stage2/stage2.c
++++ b/stage2/stage2.c
+@@ -395,7 +395,7 @@ restart:
+ 	 pressed.  
+ 	 This avoids polling (relevant in the grub-shell and later on
+ 	 in grub if interrupt driven I/O is done).  */
+-      if (checkkey () >= 0 || grub_timeout < 0)
++      if (checkkey () > 0 || grub_timeout < 0)
+ 	{
+ 	  /* Key was pressed, show which entry is selected before GETKEY,
+ 	     since we're comming in here also on GRUB_TIMEOUT == -1 and



On Thu, 23 Oct 2014, Steven Haigh wrote:
> On 23/10/2014 2:40 AM, Ian Campbell wrote:
> > On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
> > 
> >> Output using pv-grub:
> > 
> > Can you also post the qemu logs please (under /var/log/xen somewhere I
> > think).
> 
> I get very little out of this:
> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
> [root@dom0 xen]# cat xl-dev.vm.log
> Waiting for domain dev.vm (domid 36) to die [pid 6970]
> 
> That's it :\
> 
> >> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
> >> 00007fffb4573638 error 4
> > 
> > That might be a smoking gun. Is there a core dump and/or could you try
> > and run qemu under gdb?
> 
> Any hints on doing this? I can't say I'm a gdb guru.... I can't find any
> core dumps anywhere so that's not really helpful...
> 
> -- 
> Steven Haigh
> 
> Email: netwiz@crc.id.au
> Web: http://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> 
> 
--1342847746-106688891-1415209793=:22875
Content-Type: text/plain; charset="US-ASCII"; name="2"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1411051749530.22875@kaball.uk.xensource.com>
Content-Description: 
Content-Disposition: attachment; filename="2"

ZGlmZiAtLWdpdCBhL3N0dWJkb20vZ3J1Yi5wYXRjaGVzLzExZ3JhcGhpY3Mt
a2V5Ym9hcmQuZGlmZiBiL3N0dWJkb20vZ3J1Yi5wYXRjaGVzLzExZ3JhcGhp
Y3Mta2V5Ym9hcmQuZGlmZg0KbmV3IGZpbGUgbW9kZSAxMDA2NDQNCmluZGV4
IDAwMDAwMDAuLmZlMTdiMjANCi0tLSAvZGV2L251bGwNCisrKyBiL3N0dWJk
b20vZ3J1Yi5wYXRjaGVzLzExZ3JhcGhpY3Mta2V5Ym9hcmQuZGlmZg0KQEAg
LTAsMCArMSwxMyBAQA0KK2RpZmYgLS1naXQgYS9zdGFnZTIvc3RhZ2UyLmMg
Yi9zdGFnZTIvc3RhZ2UyLmMNCitpbmRleCA5ZDlmY2MzLi44MzUzYTNiIDEw
MDY0NA0KKy0tLSBhL3N0YWdlMi9zdGFnZTIuYw0KKysrKyBiL3N0YWdlMi9z
dGFnZTIuYw0KK0BAIC0zOTUsNyArMzk1LDcgQEAgcmVzdGFydDoNCisgCSBw
cmVzc2VkLiAgDQorIAkgVGhpcyBhdm9pZHMgcG9sbGluZyAocmVsZXZhbnQg
aW4gdGhlIGdydWItc2hlbGwgYW5kIGxhdGVyIG9uDQorIAkgaW4gZ3J1YiBp
ZiBpbnRlcnJ1cHQgZHJpdmVuIEkvTyBpcyBkb25lKS4gICovDQorLSAgICAg
IGlmIChjaGVja2tleSAoKSA+PSAwIHx8IGdydWJfdGltZW91dCA8IDApDQor
KyAgICAgIGlmIChjaGVja2tleSAoKSA+IDAgfHwgZ3J1Yl90aW1lb3V0IDwg
MCkNCisgCXsNCisgCSAgLyogS2V5IHdhcyBwcmVzc2VkLCBzaG93IHdoaWNo
IGVudHJ5IGlzIHNlbGVjdGVkIGJlZm9yZSBHRVRLRVksDQorIAkgICAgIHNp
bmNlIHdlJ3JlIGNvbW1pbmcgaW4gaGVyZSBhbHNvIG9uIEdSVUJfVElNRU9V
VCA9PSAtMSBhbmQNCg==

--1342847746-106688891-1415209793=:22875
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-106688891-1415209793=:22875--


From xen-devel-bounces@lists.xen.org Wed Nov 05 18:08:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 18:08:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm50C-0003w4-2n; Wed, 05 Nov 2014 18:08:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xm50A-0003vw-NA
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 18:08:14 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	CA/86-25547-D876A545; Wed, 05 Nov 2014 18:08:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415210891!11902263!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10859 invoked from network); 5 Nov 2014 18:08:13 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 18:08:13 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5I826E006643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 18:08:03 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5I808f015873
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Nov 2014 18:08:01 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA5HJlMP022525; Wed, 5 Nov 2014 17:19:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 10:07:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E8371110F82; Wed,  5 Nov 2014 13:07:56 -0500 (EST)
Date: Wed, 5 Nov 2014 13:07:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, annie li <annie.li@oracle.com>,
	james.harper@ejbdigital.com.au
Message-ID: <20141105180756.GN2694@laptop.dumpdata.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
	<1415186405.15317.6.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 11:24:16AM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 05 November 2014 11:20
> > To: Paul Durrant
> > Cc: David Vrabel; xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley
> > Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> > __pskb_pull_tail() in guest Tx path
> > 
> > On Wed, 2014-11-05 at 11:17 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 05 November 2014 11:00
> > > > To: David Vrabel
> > > > Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul
> > Durrant
> > > > Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> > > > __pskb_pull_tail() in guest Tx path
> > > >
> > > > Dropping netdev since this isn't relevant to them, adding Paul
> > > >
> > > > On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> > > > > - performance: Netback has already grant copied up-to 128 bytes from
> > > > >   the first slot of a packet into the linear area. The first slot
> > > > >   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> > > >
> > > > Does "normally" include guests other than Linux? I thought Windows in
> > > > particular was prone to splitting the headers into a frag per layer or
> > > > thereabouts?
> > > >
> > >
> > > Current upstream Windows PV drivers will put all parsed headers in the
> > > first frag and the rest of the packet in subsequent flags. The parser
> > > currently knows about TCP and UDP over IPv4 or v6, with and without
> > > SNAP encapsulation. It doesn't, for example, know about ARP so the
> > > backend will see only the ethernet header in the first frag.
> > 
> > Sounds like that is sufficient to reach the "normally" qualification,
> > thanks.
> > 
> > (I wonder what sort of benefit parsing arp would bring...)
> > 
> 
> Previous versions of the drivers used to parse ARPs so that copies of outgoing gratuitous ARPs could be cached for replay after migrate. Newer drivers acquire IP address bindings from the Windows IP helper (which is now available in kernel) and synthesize ARPs/IPv6 neighbour solicitations.
> 

CC-ing Annie and James - the other two Windows drivers authors..
>   Paul
> 
> > 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 Nov 05 18:08:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 18:08:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm50C-0003w4-2n; Wed, 05 Nov 2014 18:08:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xm50A-0003vw-NA
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 18:08:14 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	CA/86-25547-D876A545; Wed, 05 Nov 2014 18:08:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415210891!11902263!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10859 invoked from network); 5 Nov 2014 18:08:13 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 18:08:13 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5I826E006643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 18:08:03 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5I808f015873
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Nov 2014 18:08:01 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA5HJlMP022525; Wed, 5 Nov 2014 17:19:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 10:07:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E8371110F82; Wed,  5 Nov 2014 13:07:56 -0500 (EST)
Date: Wed, 5 Nov 2014 13:07:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, annie li <annie.li@oracle.com>,
	james.harper@ejbdigital.com.au
Message-ID: <20141105180756.GN2694@laptop.dumpdata.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
	<1415186405.15317.6.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 11:24:16AM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 05 November 2014 11:20
> > To: Paul Durrant
> > Cc: David Vrabel; xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley
> > Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> > __pskb_pull_tail() in guest Tx path
> > 
> > On Wed, 2014-11-05 at 11:17 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 05 November 2014 11:00
> > > > To: David Vrabel
> > > > Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul
> > Durrant
> > > > Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> > > > __pskb_pull_tail() in guest Tx path
> > > >
> > > > Dropping netdev since this isn't relevant to them, adding Paul
> > > >
> > > > On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> > > > > - performance: Netback has already grant copied up-to 128 bytes from
> > > > >   the first slot of a packet into the linear area. The first slot
> > > > >   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> > > >
> > > > Does "normally" include guests other than Linux? I thought Windows in
> > > > particular was prone to splitting the headers into a frag per layer or
> > > > thereabouts?
> > > >
> > >
> > > Current upstream Windows PV drivers will put all parsed headers in the
> > > first frag and the rest of the packet in subsequent flags. The parser
> > > currently knows about TCP and UDP over IPv4 or v6, with and without
> > > SNAP encapsulation. It doesn't, for example, know about ARP so the
> > > backend will see only the ethernet header in the first frag.
> > 
> > Sounds like that is sufficient to reach the "normally" qualification,
> > thanks.
> > 
> > (I wonder what sort of benefit parsing arp would bring...)
> > 
> 
> Previous versions of the drivers used to parse ARPs so that copies of outgoing gratuitous ARPs could be cached for replay after migrate. Newer drivers acquire IP address bindings from the Windows IP helper (which is now available in kernel) and synthesize ARPs/IPv6 neighbour solicitations.
> 

CC-ing Annie and James - the other two Windows drivers authors..
>   Paul
> 
> > 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 Nov 05 18:16:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 18:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm57a-0004HQ-2Y; Wed, 05 Nov 2014 18:15: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@citrix.com>) id 1Xm57Y-0004HL-J5
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 18:15:52 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	60/1C-31453-7596A545; Wed, 05 Nov 2014 18:15:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415211348!8550183!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2209 invoked from network); 5 Nov 2014 18:15:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 18:15:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,321,1413244800"; d="scan'208";a="188436681"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 13:15:45 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xm57R-0005XW-8a;
	Wed, 05 Nov 2014 18:15:45 +0000
Date: Wed, 5 Nov 2014 18:15:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141105165646.GN32700@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Catalin Marinas wrote:
> On Mon, Nov 03, 2014 at 11:10:18AM +0000, Stefano Stabellini wrote:
> > On Mon, 3 Nov 2014, Will Deacon wrote:
> > > On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> > > > On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > > > > Introduce a boolean flag and an accessor function to check whether a
> > > > > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > > > > 
> > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > > CC: will.deacon@arm.com
> > > > 
> > > > Will, Catalin,
> > > > are you OK with this patch?
> > > 
> > > It would be nicer if the dma_coherent flag didn't have to be duplicated by
> > > each architecture in dev_archdata. Is there any reason not to put it in the
> > > core code?
> > 
> > Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> > struct device as Catalin initially suggested, what would be the default
> > for each architecture? Where would I set it for arch that don't use
> > device tree?
> 
> You don't need to. An architecture that has coherent DMA always doesn't
> need to do anything. One that has non-coherent DMA always only needs to
> select HAVE_DMA_NONCOHERENT. One that has a mix of both needs to find a
> way to set dev->dma_coherent. Since that's a new API you introduce, it
> doesn't break any existing architectures.

I am not sure that this is better than the current patch but I can see
that this approach is not too controversial, so I am happy to go with
whatever the maintainers prefer.


> Note that if !is_device_dma_coherent(), it doesn't always mean that
> standard cache maintenance would be enough (but that's a Xen problem,
> not sure how to solve).

It is a thorny issue indeed.
Xen would need to know how to do non-standard cache maintenance
operations.
Otherwise we would need to resurrect XENFEAT_grant_map_identity (that I
am reverting in this series) and be content with having CONFIG_XEN_DOM0
depend on CONFIG_ARM_LPAE.


> diff --git a/arch/Kconfig b/arch/Kconfig
> index 05d7a8a458d5..8462b2e7491b 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -203,6 +203,9 @@ config HAVE_DMA_ATTRS
>  config HAVE_DMA_CONTIGUOUS
>  	bool
>  
> +config HAVE_DMA_NONCOHERENT
> +	bool
> +
>  config GENERIC_SMP_IDLE_THREAD
>         bool
>  
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 89c4b5ccc68d..fd7d5522764c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -40,6 +40,7 @@ config ARM
>  	select HAVE_DMA_API_DEBUG
>  	select HAVE_DMA_ATTRS
>  	select HAVE_DMA_CONTIGUOUS if MMU
> +	select HAVE_DMA_NONCOHERENT if OF
>  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
>  	select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
>  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9532f8d5857e..eb7a5aa64e0e 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -46,6 +46,7 @@ config ARM64
>  	select HAVE_DMA_API_DEBUG
>  	select HAVE_DMA_ATTRS
>  	select HAVE_DMA_CONTIGUOUS
> +	select HAVE_DMA_NONCOHERENT
>  	select HAVE_DYNAMIC_FTRACE
>  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
>  	select HAVE_FTRACE_MCOUNT_RECORD
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 3b64d0bf5bba..7e827726b702 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -183,6 +183,7 @@ static void of_dma_configure(struct device *dev)
>  	 * dma coherent operations.
>  	 */
>  	if (of_dma_is_coherent(dev->of_node)) {
> +		dev->dma_coherent = true;
>  		set_arch_dma_coherent_ops(dev);
>  		dev_dbg(dev, "device is dma coherent\n");
>  	}

I think that this would need to be #ifdef'ed as it is possible to have
OF support but no HAVE_DMA_NONCOHERENT (PPC?).


> diff --git a/include/linux/device.h b/include/linux/device.h
> index ce1f21608b16..e00ca876db01 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -796,6 +796,7 @@ struct device {
>  
>  	bool			offline_disabled:1;
>  	bool			offline:1;
> +	bool			dma_coherent:1;
>  };

I guess we would have to #ifdef CONFIG_HAVE_DMA_NONCOHERENT the
dma_coherent flag, right? Otherwise architecures that do not select
CONFIG_HAVE_DMA_NONCOHERENT (x86 for example) would end up with a flag
in struct device that doesn't reflect the properties of the device (dma
coherent devices with dev->dma_coherent == 0).

Overall it is a lot of ifdefs for not so much code sharing.


>  static inline struct device *kobj_to_dev(struct kobject *kobj)
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index d5d388160f42..0bdffba2337d 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -78,6 +78,18 @@ static inline int is_device_dma_capable(struct device *dev)
>  	return dev->dma_mask != NULL && *dev->dma_mask != DMA_MASK_NONE;
>  }
>  
> +#ifdef CONFIG_HAVE_DMA_NONCOHERENT
> +static inline int is_device_dma_coherent(struct device *dev)
> +{
> +	return dev->dma_coherent;
> +}
> +#else
> +static inline int is_device_dma_coherent(struct device *dev)
> +{
> +	return 1
> +}
> +#endif
> +
>  #ifdef CONFIG_HAS_DMA
>  #include <asm/dma-mapping.h>
>  #else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 18:16:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 18:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm57a-0004HQ-2Y; Wed, 05 Nov 2014 18:15: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@citrix.com>) id 1Xm57Y-0004HL-J5
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 18:15:52 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	60/1C-31453-7596A545; Wed, 05 Nov 2014 18:15:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415211348!8550183!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2209 invoked from network); 5 Nov 2014 18:15:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 18:15:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,321,1413244800"; d="scan'208";a="188436681"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 13:15:45 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xm57R-0005XW-8a;
	Wed, 05 Nov 2014 18:15:45 +0000
Date: Wed, 5 Nov 2014 18:15:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141105165646.GN32700@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Catalin Marinas wrote:
> On Mon, Nov 03, 2014 at 11:10:18AM +0000, Stefano Stabellini wrote:
> > On Mon, 3 Nov 2014, Will Deacon wrote:
> > > On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> > > > On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > > > > Introduce a boolean flag and an accessor function to check whether a
> > > > > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > > > > 
> > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > > CC: will.deacon@arm.com
> > > > 
> > > > Will, Catalin,
> > > > are you OK with this patch?
> > > 
> > > It would be nicer if the dma_coherent flag didn't have to be duplicated by
> > > each architecture in dev_archdata. Is there any reason not to put it in the
> > > core code?
> > 
> > Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> > struct device as Catalin initially suggested, what would be the default
> > for each architecture? Where would I set it for arch that don't use
> > device tree?
> 
> You don't need to. An architecture that has coherent DMA always doesn't
> need to do anything. One that has non-coherent DMA always only needs to
> select HAVE_DMA_NONCOHERENT. One that has a mix of both needs to find a
> way to set dev->dma_coherent. Since that's a new API you introduce, it
> doesn't break any existing architectures.

I am not sure that this is better than the current patch but I can see
that this approach is not too controversial, so I am happy to go with
whatever the maintainers prefer.


> Note that if !is_device_dma_coherent(), it doesn't always mean that
> standard cache maintenance would be enough (but that's a Xen problem,
> not sure how to solve).

It is a thorny issue indeed.
Xen would need to know how to do non-standard cache maintenance
operations.
Otherwise we would need to resurrect XENFEAT_grant_map_identity (that I
am reverting in this series) and be content with having CONFIG_XEN_DOM0
depend on CONFIG_ARM_LPAE.


> diff --git a/arch/Kconfig b/arch/Kconfig
> index 05d7a8a458d5..8462b2e7491b 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -203,6 +203,9 @@ config HAVE_DMA_ATTRS
>  config HAVE_DMA_CONTIGUOUS
>  	bool
>  
> +config HAVE_DMA_NONCOHERENT
> +	bool
> +
>  config GENERIC_SMP_IDLE_THREAD
>         bool
>  
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 89c4b5ccc68d..fd7d5522764c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -40,6 +40,7 @@ config ARM
>  	select HAVE_DMA_API_DEBUG
>  	select HAVE_DMA_ATTRS
>  	select HAVE_DMA_CONTIGUOUS if MMU
> +	select HAVE_DMA_NONCOHERENT if OF
>  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
>  	select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
>  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9532f8d5857e..eb7a5aa64e0e 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -46,6 +46,7 @@ config ARM64
>  	select HAVE_DMA_API_DEBUG
>  	select HAVE_DMA_ATTRS
>  	select HAVE_DMA_CONTIGUOUS
> +	select HAVE_DMA_NONCOHERENT
>  	select HAVE_DYNAMIC_FTRACE
>  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
>  	select HAVE_FTRACE_MCOUNT_RECORD
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 3b64d0bf5bba..7e827726b702 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -183,6 +183,7 @@ static void of_dma_configure(struct device *dev)
>  	 * dma coherent operations.
>  	 */
>  	if (of_dma_is_coherent(dev->of_node)) {
> +		dev->dma_coherent = true;
>  		set_arch_dma_coherent_ops(dev);
>  		dev_dbg(dev, "device is dma coherent\n");
>  	}

I think that this would need to be #ifdef'ed as it is possible to have
OF support but no HAVE_DMA_NONCOHERENT (PPC?).


> diff --git a/include/linux/device.h b/include/linux/device.h
> index ce1f21608b16..e00ca876db01 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -796,6 +796,7 @@ struct device {
>  
>  	bool			offline_disabled:1;
>  	bool			offline:1;
> +	bool			dma_coherent:1;
>  };

I guess we would have to #ifdef CONFIG_HAVE_DMA_NONCOHERENT the
dma_coherent flag, right? Otherwise architecures that do not select
CONFIG_HAVE_DMA_NONCOHERENT (x86 for example) would end up with a flag
in struct device that doesn't reflect the properties of the device (dma
coherent devices with dev->dma_coherent == 0).

Overall it is a lot of ifdefs for not so much code sharing.


>  static inline struct device *kobj_to_dev(struct kobject *kobj)
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index d5d388160f42..0bdffba2337d 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -78,6 +78,18 @@ static inline int is_device_dma_capable(struct device *dev)
>  	return dev->dma_mask != NULL && *dev->dma_mask != DMA_MASK_NONE;
>  }
>  
> +#ifdef CONFIG_HAVE_DMA_NONCOHERENT
> +static inline int is_device_dma_coherent(struct device *dev)
> +{
> +	return dev->dma_coherent;
> +}
> +#else
> +static inline int is_device_dma_coherent(struct device *dev)
> +{
> +	return 1
> +}
> +#endif
> +
>  #ifdef CONFIG_HAS_DMA
>  #include <asm/dma-mapping.h>
>  #else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 18:16:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 18:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm58H-0004KE-Fm; Wed, 05 Nov 2014 18:16:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xm58G-0004K3-E1
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 18:16:36 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	F5/FD-28865-3896A545; Wed, 05 Nov 2014 18:16:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415211393!11433080!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32078 invoked from network); 5 Nov 2014 18:16:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 18:16:35 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5IGKSr007305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 18:16:20 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA5HS816018233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 5 Nov 2014 17:28:09 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5IGHWL029900; Wed, 5 Nov 2014 18:16:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 10:16:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7F179110F8E; Wed,  5 Nov 2014 13:16:16 -0500 (EST)
Date: Wed, 5 Nov 2014 13:16:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141105181616.GO2694@laptop.dumpdata.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
	<54591EB8.4070007@citrix.com>
	<20141104200006.GD12464@laptop.dumpdata.com>
	<1415179244.11486.55.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415179244.11486.55.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: wei.liu2@citrix.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, George Dunlap <George.Dunlap@citrix.com>,
	xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCBOb3YgMDUsIDIwMTQgYXQgMDk6MjA6NDRBTSArMDAwMCwgSWFuIENhbXBiZWxsIHdy
b3RlOgo+IE9uIFR1ZSwgMjAxNC0xMS0wNCBhdCAxNTowMCAtMDUwMCwgS29ucmFkIFJ6ZXN6dXRl
ayBXaWxrIHdyb3RlOgo+ID4gT24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMDY6NDU6MTJQTSArMDAw
MCwgQW5kcmV3IENvb3BlciB3cm90ZToKPiA+ID4gT24gMDQvMTEvMTQgMTg6NDIsIEtvbnJhZCBS
emVzenV0ZWsgV2lsayB3cm90ZToKPiA+ID4gPiBPbiBUdWUsIE5vdiAwNCwgMjAxNCBhdCAwNjow
NzoxOVBNICswMDAwLCBBbmRyZXcgQ29vcGVyIHdyb3RlOgo+ID4gPiA+PiBPbiAwNC8xMS8xNCAx
NzozMiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+ID4gPiA+Pj4gT24gVHVlLCBOb3Yg
MDQsIDIwMTQgYXQgMTE6NTI6NDdBTSArMDAwMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gPiA+
Pj4+IFRoaXMgd2FzIGRpc2FibGVkIGJ5IGRlZmF1bHQgaW4gWGVuIDQuNC4gU2luY2UgeGVuZCBo
YXMgbm93IGJlZW4gcmVtb3ZlZCBmcm9tCj4gPiA+ID4+Pj4gdGhlIHRyZWUgSSBkb24ndCBiZWxp
ZXZlIGFueXRoaW5nIGlzIHVzaW5nIGl0Lgo+ID4gPiA+Pj4gV2hhdCBhYm91dCBYZW5TZXJ2ZXI/
Cj4gPiA+ID4+IFdlIGFyZSBtb3N0IGRlZmluaXRlbHkgbm90IHVzaW5nIGl0LCBhbmQgaGF2ZW7i
gJl0IHVzZWQgaXQgaW4gYSB2ZXJ5IGxvbmcKPiA+ID4gPj4gdGltZS4gV2UgZXhwbGljaXRseSBu
dWtlIEJMS1RBUDEgYW5kIEJMS1RBUDIgZnJvbSB0aGUgWGVuIGJ1aWxkLgo+ID4gPiA+Pgo+ID4g
PiA+Pj4gQW5kIGlzbid0IHRoZXJlIHNvbWUgYmxrdGFwMyA/Cj4gPiA+ID4+IGh0dHBzOi8vZ2l0
aHViLmNvbS94YXBpLXByb2plY3QvYmxrdGFwCj4gPiA+ID4+Cj4gPiA+ID4+Pj4gV2UgbmVlZCB0
byBwYXNzIGFuIGV4cGxpY2l0IENPTkZJR19CTEtUQVAxPW4gdG8gcWVtdS14ZW4tdHJhZGl0aW9u
YWwgb3RoZXJ3aXNlCj4gPiA+ID4+Pj4gaXQgZGVmYXVsdHMgdG8geSBhbmQgZG9lc24ndCBidWls
ZC4KPiA+ID4gPj4+Pgo+ID4gPiA+Pj4+IFNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFu
LmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4gPiA+ID4+Pj4gQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2ls
ayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPiA+ID4gPj4+PiAtLS0KPiA+ID4gPj4+PiBJIHRo
aW5rIHRoaXMgaGFzIHByb2JhYmx5IG1pc3NlZCB0aGUgYm9hdCBmb3IgNC41IGFuZCB0aGVyZSBp
c24ndCBtdWNoIGhhcm0gaW4KPiA+ID4gPj4+PiB3YWl0aW5nIGZvciA0LjYuIEknbSBvcGVuIHRv
IGJlaW5nIHRvbGQgb3RoZXJ3aXNlIHRob3VnaCA7LSkKPiA+ID4gPj4+IFlvdSByZWFsbHkgd2Fu
dCB0byBiZSBhdCB0aGUgdG9wIG9mIHRoZSBjb21taXQgbGlzdCB3aXRoIHRoZSBtb3N0IGRlbGV0
ZWQKPiA+ID4gPj4+IGNvZGUsIGVoPwo+ID4gPiA+PiAvbWUgc3VzcGVjdHMgdGhhdCBoZSBpcyBh
bHJlYWR5LCBidXQgSSBmb3Igb25lIGFtIGEgZmFuIG9mIHBydW5pbmcgZGVhZAo+ID4gPiA+PiBj
b2RlLgo+ID4gPiA+IFRydWUsIGJ1dCB3ZSBkaWQgdGFsayBhYm91dCB4ZW5kIHJlbW92YWwgZm9y
IHF1aXRlIGEgd2hpbGUgYmVmb3JlIGRvaW5nIGl0Lgo+ID4gPiA+Cj4gPiA+ID4gSG93ZXZlciwg
SSBiZWxpZXZlIHRoYXQgdGhlIGZvbGtzIHRoYXQgZGlkIFJlbXVzIGxvb2sgdG8gYmUgdXNpbmcg
aXQKPiA+ID4gPiAoQW5kIHRoZXkgaGF2ZSB0b25zIG9mIHBhdGNoZXMgYWdhaW5zdCBpdCkuCj4g
PiA+ID4KPiA+ID4gPgo+ID4gPiA+ICAgIEl0IGlzIHVuY2xlYXIgdG8gbWUgd2hldGhlciB0aGV5
Ogo+ID4gPiA+IAktIHdhbnQgdG8gYmUgdGhlIG1haW50YWluZXJzIG9mIGl0Pwo+ID4gPiA+IAkt
IHdhbnQgdG8gdXNlIGJsa3RhcDMgYnV0IGhhdmVuJ3QgeWV0IGJhY2twb3J0ZWQgdGhlaXIgcGF0
Y2hlcy4KPiA+ID4gCj4gPiA+IFRoZSByZW11cyBwYXRjaGVzIGFyZSBhZ2FpbnN0IGJsa3RhcDIs
IG5vdCBibGt0YXAxLiAgV2UgY3VycmVudGx5IGhhdmUKPiA+ID4gYm90aCBpbi10cmVlLgo+ID4g
Cj4gPiA8c2xhcHMgaGlzIGhlYWQ+Cj4gPiAKPiA+IE9LLCBzbyBibGt0YXAxIC0gZGVhZC4gVGhh
dCBsb29rcyBsaWtlIGl0IGNvdWxkIGdvIHVuZGVyIHRoZSBrbmlmZSBub3cuCj4gCj4gSU1ITyB5
ZXMgaXQgY291bGQuCj4gCj4gPiBibGt0YXAyIC0gd2FpdGluZyBmb3IgcmVzcG9uc2UKPiAKPiBU
aGlzIHNob3VsZCBzdGF5LCBhdCBsZWFzdCBmb3IgdGhlIHRpbWUgYmVpbmcsIGFuZCBjZXJ0YWlu
bHkgZm9yIDQuNS4KPiAKPiA+IElzIHRoZSBsb25nLXRlcm0gaWRlYSB0byBwdXQgJ2Jsa3RhcDMn
IGluIHRoZSB0cmVlPwo+IAo+IEkgZG9uJ3QgdGhpbmsgc28uCj4gCj4gR2VvcmdlIHdhcyBnb2lu
ZyB0byBtYWtlIGEgcHJvcG9zYWwgYWJvdXQgZnV0dXJlIHBsYW5zIGZvciBibGt0YXAqLgoKSSBi
ZWxpdmUgaXQgbWFrZXMgc2Vuc2UgdG8gd2FpdCBmb3IgR2VvcmdlJ3MgcHJvcG9zYWwuCgpXaGls
ZSBJIGJlbGlldmUgdGhlIG91dGNvbWUgb2YgaXQgaXMgZ29pbmcgdG8gYmUgcm0gKmJsa3RhcDEq
IHlvdQpuZXZlciBrbm93IHdobyBpcyBnb2luZyB0byBjb21lIG91dCBvZiB0aGUgd29vZHNoZWQg
d2hlbiBjb2RlIGlzCnRvIGJlIGRlbGV0ZWQuCgo+IAo+IElhbi4KPiAKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Nov 05 18:16:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 18:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm58H-0004KE-Fm; Wed, 05 Nov 2014 18:16:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xm58G-0004K3-E1
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 18:16:36 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	F5/FD-28865-3896A545; Wed, 05 Nov 2014 18:16:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415211393!11433080!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32078 invoked from network); 5 Nov 2014 18:16:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 18:16:35 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5IGKSr007305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 18:16:20 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA5HS816018233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 5 Nov 2014 17:28:09 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5IGHWL029900; Wed, 5 Nov 2014 18:16:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 10:16:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7F179110F8E; Wed,  5 Nov 2014 13:16:16 -0500 (EST)
Date: Wed, 5 Nov 2014 13:16:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141105181616.GO2694@laptop.dumpdata.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
	<54591EB8.4070007@citrix.com>
	<20141104200006.GD12464@laptop.dumpdata.com>
	<1415179244.11486.55.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415179244.11486.55.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: wei.liu2@citrix.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, George Dunlap <George.Dunlap@citrix.com>,
	xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCBOb3YgMDUsIDIwMTQgYXQgMDk6MjA6NDRBTSArMDAwMCwgSWFuIENhbXBiZWxsIHdy
b3RlOgo+IE9uIFR1ZSwgMjAxNC0xMS0wNCBhdCAxNTowMCAtMDUwMCwgS29ucmFkIFJ6ZXN6dXRl
ayBXaWxrIHdyb3RlOgo+ID4gT24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMDY6NDU6MTJQTSArMDAw
MCwgQW5kcmV3IENvb3BlciB3cm90ZToKPiA+ID4gT24gMDQvMTEvMTQgMTg6NDIsIEtvbnJhZCBS
emVzenV0ZWsgV2lsayB3cm90ZToKPiA+ID4gPiBPbiBUdWUsIE5vdiAwNCwgMjAxNCBhdCAwNjow
NzoxOVBNICswMDAwLCBBbmRyZXcgQ29vcGVyIHdyb3RlOgo+ID4gPiA+PiBPbiAwNC8xMS8xNCAx
NzozMiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+ID4gPiA+Pj4gT24gVHVlLCBOb3Yg
MDQsIDIwMTQgYXQgMTE6NTI6NDdBTSArMDAwMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gPiA+
Pj4+IFRoaXMgd2FzIGRpc2FibGVkIGJ5IGRlZmF1bHQgaW4gWGVuIDQuNC4gU2luY2UgeGVuZCBo
YXMgbm93IGJlZW4gcmVtb3ZlZCBmcm9tCj4gPiA+ID4+Pj4gdGhlIHRyZWUgSSBkb24ndCBiZWxp
ZXZlIGFueXRoaW5nIGlzIHVzaW5nIGl0Lgo+ID4gPiA+Pj4gV2hhdCBhYm91dCBYZW5TZXJ2ZXI/
Cj4gPiA+ID4+IFdlIGFyZSBtb3N0IGRlZmluaXRlbHkgbm90IHVzaW5nIGl0LCBhbmQgaGF2ZW7i
gJl0IHVzZWQgaXQgaW4gYSB2ZXJ5IGxvbmcKPiA+ID4gPj4gdGltZS4gV2UgZXhwbGljaXRseSBu
dWtlIEJMS1RBUDEgYW5kIEJMS1RBUDIgZnJvbSB0aGUgWGVuIGJ1aWxkLgo+ID4gPiA+Pgo+ID4g
PiA+Pj4gQW5kIGlzbid0IHRoZXJlIHNvbWUgYmxrdGFwMyA/Cj4gPiA+ID4+IGh0dHBzOi8vZ2l0
aHViLmNvbS94YXBpLXByb2plY3QvYmxrdGFwCj4gPiA+ID4+Cj4gPiA+ID4+Pj4gV2UgbmVlZCB0
byBwYXNzIGFuIGV4cGxpY2l0IENPTkZJR19CTEtUQVAxPW4gdG8gcWVtdS14ZW4tdHJhZGl0aW9u
YWwgb3RoZXJ3aXNlCj4gPiA+ID4+Pj4gaXQgZGVmYXVsdHMgdG8geSBhbmQgZG9lc24ndCBidWls
ZC4KPiA+ID4gPj4+Pgo+ID4gPiA+Pj4+IFNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFu
LmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4gPiA+ID4+Pj4gQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2ls
ayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPiA+ID4gPj4+PiAtLS0KPiA+ID4gPj4+PiBJIHRo
aW5rIHRoaXMgaGFzIHByb2JhYmx5IG1pc3NlZCB0aGUgYm9hdCBmb3IgNC41IGFuZCB0aGVyZSBp
c24ndCBtdWNoIGhhcm0gaW4KPiA+ID4gPj4+PiB3YWl0aW5nIGZvciA0LjYuIEknbSBvcGVuIHRv
IGJlaW5nIHRvbGQgb3RoZXJ3aXNlIHRob3VnaCA7LSkKPiA+ID4gPj4+IFlvdSByZWFsbHkgd2Fu
dCB0byBiZSBhdCB0aGUgdG9wIG9mIHRoZSBjb21taXQgbGlzdCB3aXRoIHRoZSBtb3N0IGRlbGV0
ZWQKPiA+ID4gPj4+IGNvZGUsIGVoPwo+ID4gPiA+PiAvbWUgc3VzcGVjdHMgdGhhdCBoZSBpcyBh
bHJlYWR5LCBidXQgSSBmb3Igb25lIGFtIGEgZmFuIG9mIHBydW5pbmcgZGVhZAo+ID4gPiA+PiBj
b2RlLgo+ID4gPiA+IFRydWUsIGJ1dCB3ZSBkaWQgdGFsayBhYm91dCB4ZW5kIHJlbW92YWwgZm9y
IHF1aXRlIGEgd2hpbGUgYmVmb3JlIGRvaW5nIGl0Lgo+ID4gPiA+Cj4gPiA+ID4gSG93ZXZlciwg
SSBiZWxpZXZlIHRoYXQgdGhlIGZvbGtzIHRoYXQgZGlkIFJlbXVzIGxvb2sgdG8gYmUgdXNpbmcg
aXQKPiA+ID4gPiAoQW5kIHRoZXkgaGF2ZSB0b25zIG9mIHBhdGNoZXMgYWdhaW5zdCBpdCkuCj4g
PiA+ID4KPiA+ID4gPgo+ID4gPiA+ICAgIEl0IGlzIHVuY2xlYXIgdG8gbWUgd2hldGhlciB0aGV5
Ogo+ID4gPiA+IAktIHdhbnQgdG8gYmUgdGhlIG1haW50YWluZXJzIG9mIGl0Pwo+ID4gPiA+IAkt
IHdhbnQgdG8gdXNlIGJsa3RhcDMgYnV0IGhhdmVuJ3QgeWV0IGJhY2twb3J0ZWQgdGhlaXIgcGF0
Y2hlcy4KPiA+ID4gCj4gPiA+IFRoZSByZW11cyBwYXRjaGVzIGFyZSBhZ2FpbnN0IGJsa3RhcDIs
IG5vdCBibGt0YXAxLiAgV2UgY3VycmVudGx5IGhhdmUKPiA+ID4gYm90aCBpbi10cmVlLgo+ID4g
Cj4gPiA8c2xhcHMgaGlzIGhlYWQ+Cj4gPiAKPiA+IE9LLCBzbyBibGt0YXAxIC0gZGVhZC4gVGhh
dCBsb29rcyBsaWtlIGl0IGNvdWxkIGdvIHVuZGVyIHRoZSBrbmlmZSBub3cuCj4gCj4gSU1ITyB5
ZXMgaXQgY291bGQuCj4gCj4gPiBibGt0YXAyIC0gd2FpdGluZyBmb3IgcmVzcG9uc2UKPiAKPiBU
aGlzIHNob3VsZCBzdGF5LCBhdCBsZWFzdCBmb3IgdGhlIHRpbWUgYmVpbmcsIGFuZCBjZXJ0YWlu
bHkgZm9yIDQuNS4KPiAKPiA+IElzIHRoZSBsb25nLXRlcm0gaWRlYSB0byBwdXQgJ2Jsa3RhcDMn
IGluIHRoZSB0cmVlPwo+IAo+IEkgZG9uJ3QgdGhpbmsgc28uCj4gCj4gR2VvcmdlIHdhcyBnb2lu
ZyB0byBtYWtlIGEgcHJvcG9zYWwgYWJvdXQgZnV0dXJlIHBsYW5zIGZvciBibGt0YXAqLgoKSSBi
ZWxpdmUgaXQgbWFrZXMgc2Vuc2UgdG8gd2FpdCBmb3IgR2VvcmdlJ3MgcHJvcG9zYWwuCgpXaGls
ZSBJIGJlbGlldmUgdGhlIG91dGNvbWUgb2YgaXQgaXMgZ29pbmcgdG8gYmUgcm0gKmJsa3RhcDEq
IHlvdQpuZXZlciBrbm93IHdobyBpcyBnb2luZyB0byBjb21lIG91dCBvZiB0aGUgd29vZHNoZWQg
d2hlbiBjb2RlIGlzCnRvIGJlIGRlbGV0ZWQuCgo+IAo+IElhbi4KPiAKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Nov 05 18:22:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 18: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 1Xm5Dd-0004iS-8x; Wed, 05 Nov 2014 18:22:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xm5Db-0004iK-GK
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 18:22:07 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	2D/84-01660-ECA6A545; Wed, 05 Nov 2014 18:22:06 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415211723!11448716!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25384 invoked from network); 5 Nov 2014 18:22:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 18:22:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,321,1413244800"; d="scan'208";a="189841930"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 13:21:38 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xm5D7-0005ct-Vj;
	Wed, 05 Nov 2014 18:21:37 +0000
Message-ID: <545A6A9B.9060002@eu.citrix.com>
Date: Wed, 5 Nov 2014 18:21:15 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
	<54591EB8.4070007@citrix.com>
	<20141104200006.GD12464@laptop.dumpdata.com>
	<1415179244.11486.55.camel@citrix.com>
	<20141105181616.GO2694@laptop.dumpdata.com>
In-Reply-To: <20141105181616.GO2694@laptop.dumpdata.com>
Content-Length: 4260
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, George Dunlap <George.Dunlap@citrix.com>,
	xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

T24gMTEvMDUvMjAxNCAwNjoxNiBQTSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+IE9u
IFdlZCwgTm92IDA1LCAyMDE0IGF0IDA5OjIwOjQ0QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90
ZToKPj4gT24gVHVlLCAyMDE0LTExLTA0IGF0IDE1OjAwIC0wNTAwLCBLb25yYWQgUnplc3p1dGVr
IFdpbGsgd3JvdGU6Cj4+PiBPbiBUdWUsIE5vdiAwNCwgMjAxNCBhdCAwNjo0NToxMlBNICswMDAw
LCBBbmRyZXcgQ29vcGVyIHdyb3RlOgo+Pj4+IE9uIDA0LzExLzE0IDE4OjQyLCBLb25yYWQgUnpl
c3p1dGVrIFdpbGsgd3JvdGU6Cj4+Pj4+IE9uIFR1ZSwgTm92IDA0LCAyMDE0IGF0IDA2OjA3OjE5
UE0gKzAwMDAsIEFuZHJldyBDb29wZXIgd3JvdGU6Cj4+Pj4+PiBPbiAwNC8xMS8xNCAxNzozMiwg
S29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+Pj4+Pj4+IE9uIFR1ZSwgTm92IDA0LCAyMDE0
IGF0IDExOjUyOjQ3QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4+Pj4+Pj4gVGhpcyB3
YXMgZGlzYWJsZWQgYnkgZGVmYXVsdCBpbiBYZW4gNC40LiBTaW5jZSB4ZW5kIGhhcyBub3cgYmVl
biByZW1vdmVkIGZyb20KPj4+Pj4+Pj4gdGhlIHRyZWUgSSBkb24ndCBiZWxpZXZlIGFueXRoaW5n
IGlzIHVzaW5nIGl0Lgo+Pj4+Pj4+IFdoYXQgYWJvdXQgWGVuU2VydmVyPwo+Pj4+Pj4gV2UgYXJl
IG1vc3QgZGVmaW5pdGVseSBub3QgdXNpbmcgaXQsIGFuZCBoYXZlbuKAmXQgdXNlZCBpdCBpbiBh
IHZlcnkgbG9uZwo+Pj4+Pj4gdGltZS4gV2UgZXhwbGljaXRseSBudWtlIEJMS1RBUDEgYW5kIEJM
S1RBUDIgZnJvbSB0aGUgWGVuIGJ1aWxkLgo+Pj4+Pj4KPj4+Pj4+PiBBbmQgaXNuJ3QgdGhlcmUg
c29tZSBibGt0YXAzID8KPj4+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS94YXBpLXByb2plY3QvYmxr
dGFwCj4+Pj4+Pgo+Pj4+Pj4+PiBXZSBuZWVkIHRvIHBhc3MgYW4gZXhwbGljaXQgQ09ORklHX0JM
S1RBUDE9biB0byBxZW11LXhlbi10cmFkaXRpb25hbCBvdGhlcndpc2UKPj4+Pj4+Pj4gaXQgZGVm
YXVsdHMgdG8geSBhbmQgZG9lc24ndCBidWlsZC4KPj4+Pj4+Pj4KPj4+Pj4+Pj4gU2lnbmVkLW9m
Zi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPj4+Pj4+Pj4gQ2M6
IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPj4+Pj4+Pj4g
LS0tCj4+Pj4+Pj4+IEkgdGhpbmsgdGhpcyBoYXMgcHJvYmFibHkgbWlzc2VkIHRoZSBib2F0IGZv
ciA0LjUgYW5kIHRoZXJlIGlzbid0IG11Y2ggaGFybSBpbgo+Pj4+Pj4+PiB3YWl0aW5nIGZvciA0
LjYuIEknbSBvcGVuIHRvIGJlaW5nIHRvbGQgb3RoZXJ3aXNlIHRob3VnaCA7LSkKPj4+Pj4+PiBZ
b3UgcmVhbGx5IHdhbnQgdG8gYmUgYXQgdGhlIHRvcCBvZiB0aGUgY29tbWl0IGxpc3Qgd2l0aCB0
aGUgbW9zdCBkZWxldGVkCj4+Pj4+Pj4gY29kZSwgZWg/Cj4+Pj4+PiAvbWUgc3VzcGVjdHMgdGhh
dCBoZSBpcyBhbHJlYWR5LCBidXQgSSBmb3Igb25lIGFtIGEgZmFuIG9mIHBydW5pbmcgZGVhZAo+
Pj4+Pj4gY29kZS4KPj4+Pj4gVHJ1ZSwgYnV0IHdlIGRpZCB0YWxrIGFib3V0IHhlbmQgcmVtb3Zh
bCBmb3IgcXVpdGUgYSB3aGlsZSBiZWZvcmUgZG9pbmcgaXQuCj4+Pj4+Cj4+Pj4+IEhvd2V2ZXIs
IEkgYmVsaWV2ZSB0aGF0IHRoZSBmb2xrcyB0aGF0IGRpZCBSZW11cyBsb29rIHRvIGJlIHVzaW5n
IGl0Cj4+Pj4+IChBbmQgdGhleSBoYXZlIHRvbnMgb2YgcGF0Y2hlcyBhZ2FpbnN0IGl0KS4KPj4+
Pj4KPj4+Pj4KPj4+Pj4gICAgIEl0IGlzIHVuY2xlYXIgdG8gbWUgd2hldGhlciB0aGV5Ogo+Pj4+
PiAJLSB3YW50IHRvIGJlIHRoZSBtYWludGFpbmVycyBvZiBpdD8KPj4+Pj4gCS0gd2FudCB0byB1
c2UgYmxrdGFwMyBidXQgaGF2ZW4ndCB5ZXQgYmFja3BvcnRlZCB0aGVpciBwYXRjaGVzLgo+Pj4+
IFRoZSByZW11cyBwYXRjaGVzIGFyZSBhZ2FpbnN0IGJsa3RhcDIsIG5vdCBibGt0YXAxLiAgV2Ug
Y3VycmVudGx5IGhhdmUKPj4+PiBib3RoIGluLXRyZWUuCj4+PiA8c2xhcHMgaGlzIGhlYWQ+Cj4+
Pgo+Pj4gT0ssIHNvIGJsa3RhcDEgLSBkZWFkLiBUaGF0IGxvb2tzIGxpa2UgaXQgY291bGQgZ28g
dW5kZXIgdGhlIGtuaWZlIG5vdy4KPj4gSU1ITyB5ZXMgaXQgY291bGQuCj4+Cj4+PiBibGt0YXAy
IC0gd2FpdGluZyBmb3IgcmVzcG9uc2UKPj4gVGhpcyBzaG91bGQgc3RheSwgYXQgbGVhc3QgZm9y
IHRoZSB0aW1lIGJlaW5nLCBhbmQgY2VydGFpbmx5IGZvciA0LjUuCj4+Cj4+PiBJcyB0aGUgbG9u
Zy10ZXJtIGlkZWEgdG8gcHV0ICdibGt0YXAzJyBpbiB0aGUgdHJlZT8KPj4gSSBkb24ndCB0aGlu
ayBzby4KPj4KPj4gR2VvcmdlIHdhcyBnb2luZyB0byBtYWtlIGEgcHJvcG9zYWwgYWJvdXQgZnV0
dXJlIHBsYW5zIGZvciBibGt0YXAqLgo+IEkgYmVsaXZlIGl0IG1ha2VzIHNlbnNlIHRvIHdhaXQg
Zm9yIEdlb3JnZSdzIHByb3Bvc2FsLgo+Cj4gV2hpbGUgSSBiZWxpZXZlIHRoZSBvdXRjb21lIG9m
IGl0IGlzIGdvaW5nIHRvIGJlIHJtICpibGt0YXAxKiB5b3UKPiBuZXZlciBrbm93IHdobyBpcyBn
b2luZyB0byBjb21lIG91dCBvZiB0aGUgd29vZHNoZWQgd2hlbiBjb2RlIGlzCj4gdG8gYmUgZGVs
ZXRlZC4KCk15IHByb3Bvc2FsIGRvZXNuJ3QgY29uc2lkZXIgYmxrdGFwMS4KCldoaWxlIEknbSBh
bGwgaW4gZmF2b3Igb2YgbnVraW5nIHVzZWxlc3MgZnVuY3Rpb25hbGl0eSwgSSB0aGluayB0aGUg
CnRpbWluZyBvZiB0aGlzIGlzIHByZXR0eSBiYWQgLS0gd2UndmUgYWxyZWFkeSBoYWQgYW4gUkM7
IGlmIGFueW9uZSAqaXMqIAp1c2luZyBpdCwgdGhlIHByb2JhYmlsaXR5IG9mIHRoZW0gbm90IG5v
dGljaW5nIHRoYXQgaXQncyBnb25lIG1pc3NpbmcgCmJldHdlZW4gbm93IGFuZCB0aGUgcmVsZWFz
ZSBpcyBwcmV0dHkgaGlnaC4gIEknZCBtdWNoIHJhdGhlciB3YWl0IGFuZCAKbnVrZSBpdCBhdCB0
aGUgYmVnaW5uaW5nIG9mIHRoZSBjeWNsZSwgbGlrZSB3ZSBkaWQgd2l0aCB4ZW5kLgoKICAtR2Vv
cmdlCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Nov 05 18:22:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 18: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 1Xm5Dd-0004iS-8x; Wed, 05 Nov 2014 18:22:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xm5Db-0004iK-GK
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 18:22:07 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	2D/84-01660-ECA6A545; Wed, 05 Nov 2014 18:22:06 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415211723!11448716!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25384 invoked from network); 5 Nov 2014 18:22:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 18:22:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,321,1413244800"; d="scan'208";a="189841930"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 13:21:38 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xm5D7-0005ct-Vj;
	Wed, 05 Nov 2014 18:21:37 +0000
Message-ID: <545A6A9B.9060002@eu.citrix.com>
Date: Wed, 5 Nov 2014 18:21:15 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
	<54591EB8.4070007@citrix.com>
	<20141104200006.GD12464@laptop.dumpdata.com>
	<1415179244.11486.55.camel@citrix.com>
	<20141105181616.GO2694@laptop.dumpdata.com>
In-Reply-To: <20141105181616.GO2694@laptop.dumpdata.com>
Content-Length: 4260
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, George Dunlap <George.Dunlap@citrix.com>,
	xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

T24gMTEvMDUvMjAxNCAwNjoxNiBQTSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+IE9u
IFdlZCwgTm92IDA1LCAyMDE0IGF0IDA5OjIwOjQ0QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90
ZToKPj4gT24gVHVlLCAyMDE0LTExLTA0IGF0IDE1OjAwIC0wNTAwLCBLb25yYWQgUnplc3p1dGVr
IFdpbGsgd3JvdGU6Cj4+PiBPbiBUdWUsIE5vdiAwNCwgMjAxNCBhdCAwNjo0NToxMlBNICswMDAw
LCBBbmRyZXcgQ29vcGVyIHdyb3RlOgo+Pj4+IE9uIDA0LzExLzE0IDE4OjQyLCBLb25yYWQgUnpl
c3p1dGVrIFdpbGsgd3JvdGU6Cj4+Pj4+IE9uIFR1ZSwgTm92IDA0LCAyMDE0IGF0IDA2OjA3OjE5
UE0gKzAwMDAsIEFuZHJldyBDb29wZXIgd3JvdGU6Cj4+Pj4+PiBPbiAwNC8xMS8xNCAxNzozMiwg
S29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+Pj4+Pj4+IE9uIFR1ZSwgTm92IDA0LCAyMDE0
IGF0IDExOjUyOjQ3QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4+Pj4+Pj4gVGhpcyB3
YXMgZGlzYWJsZWQgYnkgZGVmYXVsdCBpbiBYZW4gNC40LiBTaW5jZSB4ZW5kIGhhcyBub3cgYmVl
biByZW1vdmVkIGZyb20KPj4+Pj4+Pj4gdGhlIHRyZWUgSSBkb24ndCBiZWxpZXZlIGFueXRoaW5n
IGlzIHVzaW5nIGl0Lgo+Pj4+Pj4+IFdoYXQgYWJvdXQgWGVuU2VydmVyPwo+Pj4+Pj4gV2UgYXJl
IG1vc3QgZGVmaW5pdGVseSBub3QgdXNpbmcgaXQsIGFuZCBoYXZlbuKAmXQgdXNlZCBpdCBpbiBh
IHZlcnkgbG9uZwo+Pj4+Pj4gdGltZS4gV2UgZXhwbGljaXRseSBudWtlIEJMS1RBUDEgYW5kIEJM
S1RBUDIgZnJvbSB0aGUgWGVuIGJ1aWxkLgo+Pj4+Pj4KPj4+Pj4+PiBBbmQgaXNuJ3QgdGhlcmUg
c29tZSBibGt0YXAzID8KPj4+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS94YXBpLXByb2plY3QvYmxr
dGFwCj4+Pj4+Pgo+Pj4+Pj4+PiBXZSBuZWVkIHRvIHBhc3MgYW4gZXhwbGljaXQgQ09ORklHX0JM
S1RBUDE9biB0byBxZW11LXhlbi10cmFkaXRpb25hbCBvdGhlcndpc2UKPj4+Pj4+Pj4gaXQgZGVm
YXVsdHMgdG8geSBhbmQgZG9lc24ndCBidWlsZC4KPj4+Pj4+Pj4KPj4+Pj4+Pj4gU2lnbmVkLW9m
Zi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPj4+Pj4+Pj4gQ2M6
IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPj4+Pj4+Pj4g
LS0tCj4+Pj4+Pj4+IEkgdGhpbmsgdGhpcyBoYXMgcHJvYmFibHkgbWlzc2VkIHRoZSBib2F0IGZv
ciA0LjUgYW5kIHRoZXJlIGlzbid0IG11Y2ggaGFybSBpbgo+Pj4+Pj4+PiB3YWl0aW5nIGZvciA0
LjYuIEknbSBvcGVuIHRvIGJlaW5nIHRvbGQgb3RoZXJ3aXNlIHRob3VnaCA7LSkKPj4+Pj4+PiBZ
b3UgcmVhbGx5IHdhbnQgdG8gYmUgYXQgdGhlIHRvcCBvZiB0aGUgY29tbWl0IGxpc3Qgd2l0aCB0
aGUgbW9zdCBkZWxldGVkCj4+Pj4+Pj4gY29kZSwgZWg/Cj4+Pj4+PiAvbWUgc3VzcGVjdHMgdGhh
dCBoZSBpcyBhbHJlYWR5LCBidXQgSSBmb3Igb25lIGFtIGEgZmFuIG9mIHBydW5pbmcgZGVhZAo+
Pj4+Pj4gY29kZS4KPj4+Pj4gVHJ1ZSwgYnV0IHdlIGRpZCB0YWxrIGFib3V0IHhlbmQgcmVtb3Zh
bCBmb3IgcXVpdGUgYSB3aGlsZSBiZWZvcmUgZG9pbmcgaXQuCj4+Pj4+Cj4+Pj4+IEhvd2V2ZXIs
IEkgYmVsaWV2ZSB0aGF0IHRoZSBmb2xrcyB0aGF0IGRpZCBSZW11cyBsb29rIHRvIGJlIHVzaW5n
IGl0Cj4+Pj4+IChBbmQgdGhleSBoYXZlIHRvbnMgb2YgcGF0Y2hlcyBhZ2FpbnN0IGl0KS4KPj4+
Pj4KPj4+Pj4KPj4+Pj4gICAgIEl0IGlzIHVuY2xlYXIgdG8gbWUgd2hldGhlciB0aGV5Ogo+Pj4+
PiAJLSB3YW50IHRvIGJlIHRoZSBtYWludGFpbmVycyBvZiBpdD8KPj4+Pj4gCS0gd2FudCB0byB1
c2UgYmxrdGFwMyBidXQgaGF2ZW4ndCB5ZXQgYmFja3BvcnRlZCB0aGVpciBwYXRjaGVzLgo+Pj4+
IFRoZSByZW11cyBwYXRjaGVzIGFyZSBhZ2FpbnN0IGJsa3RhcDIsIG5vdCBibGt0YXAxLiAgV2Ug
Y3VycmVudGx5IGhhdmUKPj4+PiBib3RoIGluLXRyZWUuCj4+PiA8c2xhcHMgaGlzIGhlYWQ+Cj4+
Pgo+Pj4gT0ssIHNvIGJsa3RhcDEgLSBkZWFkLiBUaGF0IGxvb2tzIGxpa2UgaXQgY291bGQgZ28g
dW5kZXIgdGhlIGtuaWZlIG5vdy4KPj4gSU1ITyB5ZXMgaXQgY291bGQuCj4+Cj4+PiBibGt0YXAy
IC0gd2FpdGluZyBmb3IgcmVzcG9uc2UKPj4gVGhpcyBzaG91bGQgc3RheSwgYXQgbGVhc3QgZm9y
IHRoZSB0aW1lIGJlaW5nLCBhbmQgY2VydGFpbmx5IGZvciA0LjUuCj4+Cj4+PiBJcyB0aGUgbG9u
Zy10ZXJtIGlkZWEgdG8gcHV0ICdibGt0YXAzJyBpbiB0aGUgdHJlZT8KPj4gSSBkb24ndCB0aGlu
ayBzby4KPj4KPj4gR2VvcmdlIHdhcyBnb2luZyB0byBtYWtlIGEgcHJvcG9zYWwgYWJvdXQgZnV0
dXJlIHBsYW5zIGZvciBibGt0YXAqLgo+IEkgYmVsaXZlIGl0IG1ha2VzIHNlbnNlIHRvIHdhaXQg
Zm9yIEdlb3JnZSdzIHByb3Bvc2FsLgo+Cj4gV2hpbGUgSSBiZWxpZXZlIHRoZSBvdXRjb21lIG9m
IGl0IGlzIGdvaW5nIHRvIGJlIHJtICpibGt0YXAxKiB5b3UKPiBuZXZlciBrbm93IHdobyBpcyBn
b2luZyB0byBjb21lIG91dCBvZiB0aGUgd29vZHNoZWQgd2hlbiBjb2RlIGlzCj4gdG8gYmUgZGVs
ZXRlZC4KCk15IHByb3Bvc2FsIGRvZXNuJ3QgY29uc2lkZXIgYmxrdGFwMS4KCldoaWxlIEknbSBh
bGwgaW4gZmF2b3Igb2YgbnVraW5nIHVzZWxlc3MgZnVuY3Rpb25hbGl0eSwgSSB0aGluayB0aGUg
CnRpbWluZyBvZiB0aGlzIGlzIHByZXR0eSBiYWQgLS0gd2UndmUgYWxyZWFkeSBoYWQgYW4gUkM7
IGlmIGFueW9uZSAqaXMqIAp1c2luZyBpdCwgdGhlIHByb2JhYmlsaXR5IG9mIHRoZW0gbm90IG5v
dGljaW5nIHRoYXQgaXQncyBnb25lIG1pc3NpbmcgCmJldHdlZW4gbm93IGFuZCB0aGUgcmVsZWFz
ZSBpcyBwcmV0dHkgaGlnaC4gIEknZCBtdWNoIHJhdGhlciB3YWl0IGFuZCAKbnVrZSBpdCBhdCB0
aGUgYmVnaW5uaW5nIG9mIHRoZSBjeWNsZSwgbGlrZSB3ZSBkaWQgd2l0aCB4ZW5kLgoKICAtR2Vv
cmdlCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Nov 05 18:24:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 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 1Xm5Fm-0004pN-Un; Wed, 05 Nov 2014 18:24: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@citrix.com>) id 1Xm5Fl-0004pG-KU
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 18:24:21 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	00/65-22819-45B6A545; Wed, 05 Nov 2014 18:24:20 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415211857!11449020!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27671 invoked from network); 5 Nov 2014 18:24:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 18:24:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,321,1413244800"; d="scan'208";a="189842836"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 13:24:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xm5Fe-0005eO-C0;
	Wed, 05 Nov 2014 18:24:14 +0000
Date: Wed, 5 Nov 2014 18:24:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Quan" <quan.xu@intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E8202B7@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411051821510.22875@kaball.uk.xensource.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411051036310.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8202B7@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Wednesday, November 05, 2014 7:01 PM
> > To: Xu, Quan
> > Cc: Stefano Stabellini; qemu-devel@nongnu.org; xen-devel@lists.xen.org
> > Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > frontend driver
> > 
> > On Tue, 4 Nov 2014, Xu, Quan wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Monday, November 03, 2014 7:54 PM
> > > > To: Xu, Quan
> > > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > > > stefano.stabellini@eu.citrix.com
> > > > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > > > frontend driver
> > > >
> > > > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > > > This drvier transfers any request/repond between TPM xenstubdoms
> > > > > driver and Xen vTPM stubdom, and facilitates communications
> > > > > between Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > > > >
> > > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > >
> > > > Please describe what changes did make to xen_backend.c and why.
> > > > The commit message should contains info on all the changes made by
> > > > the patch below.
> > > >
> > >
> > > Thanks Stefano.
> > > one more day, I will explain in detail what changes did make to
> > > xen_backend.c and why.
> > > The following 2 sections are introduction and architecture.
> > >
> > > > Please also describe what is the "Xen vTPM stubdom", what is the
> > > > "vTPM xenstubdoms driver" and how the communicate with each others.
> > > >
> > >
> > >
> > > Add 2 parts for detailed descriptions, introduction and architecture.
> > >
> > > *INTRODUCTION*
> > >
> > > The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM
> > > functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows
> > > .etc). This allows programs to interact with a TPM in a virtual
> > > machine the same way they interact with a TPM on the physical system.
> > Each virtual machine gets its own unique, emulated, software TPM.
> > > Each major component of vTPM is implemented as a stubdom, providing
> > > secure separation guaranteed by the hypervisor.
> > > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the
> > > virtual machine to use. It is a small wrapper around the Berlios TPM
> > > emulator. TPM commands are passed from mini-os TPM backend driver.
> > > This patch series are only the Qemu part to enable Xen stubdom vTPM
> > > for HVM virtual machine.
> > > ===========
> > >
> > > *ARCHITECTURE*
> > >
> > > The architecture of stubdom vTPM for HVM virtual machine:
> > >
> > >             +--------------------+
> > >             | Windows/Linux DomU | ...
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |  Qemu tpm1.2 Tis   |
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |        vTPM        |
> > >             | XenStubdoms driver |  (new ..)
> > >             +--------------------+
> > >                      |  ^
> > >                      v  |
> > >             +--------------------+
> > >             |  xen_vtpmdev_ops   |  (new ..)
> > >             +--------------------+
> > >                      |  ^
> > >                      v  |
> > >             +--------------------+
> > >             |  mini-os/tpmback   |
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |   vTPM stubdom     | ...
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |  mini-os/tpmfront  |
> > >             +--------------------+
> > >                      |  ^
> > >                      v  |
> > >             +--------------------+
> > >             |  mini-os/tpmback   |
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |  vtpmmgr stubdom   |
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |  mini-os/tpm_tis   |
> > >             +--------------------+
> > >                      |  ^
> > >                      v  |
> > >             +--------------------+
> > >             |    Hardware TPM    |
> > >             +--------------------+
> > >
> > >
> > > * Windows/Linux DomU:
> > >     The HVM based guest that wants to use a vTPM. There may be
> > >     more than one of these.
> > >
> > >  * Qemu tpm1.2 Tis:
> > >     Implementation of the tpm1.2 Tis interface for HVM virtual
> > >     machines. It is Qemu emulation device.
> > 
> > It looks like you are running upstream QEMU within a Mini-OS stubdom?
> > If so, where are the patches to do that? As far as I know upstream QEMU
> > doesn't run on Mini-OS. Or maybe it is a Linux stubdom? Either way, it is not
> > clear.
> 
> Not so.
> Refer to below further explanation. 
> 
> > 
> > 
> > >  * vTPM xenstubdoms driver:
> > >     Similar to a TPM passthrough backend driver, it is a new TPM
> > >     backend for emulated TPM TIS interface. This driver provides
> > >     vTPM initialization and sending data and commends to a Xen
> > >     vTPM stubdom.
> > 
> > This is patch #3, right? It is basically the internal QEMU "glue" to connect the
> > tpm emulator to xen_vtpmdev_ops, correct?
> > 
> 
> Yes, it is Patch #3. Agree with your description.  :)
> 
> > 
> > >  * xen_vtpmdev_ops:
> > >     Register Xen stubdom vTPM backend, and transfer any request/
> > >     repond between TPM xenstubdoms driver and Xen vTPM stubdom.
> > >     Facilitate communications between Xen vTPM stubdom and vTPM
> > >     xenstubdoms driver.
> > 
> > It looks like this correspond to patch #2? If so, this is a regular Xen PV
> 
> Yes, it patch #2.
> 
> 
> > frontend, living in QEMU? It requires the gntalloc device so I guess it is
> > supposed to run on Linux. In that case is it just a tpmfront implementation in
> > QEMU?
> > 
> 
> 
> Yes, it's tpmfront implementation in Qemu. also it supports PV Linux since Xen 4.3.0.
> vTPM stubdom / vtpmmgr stubdom  ware implemented by Matthew Fioravante (JHUAPL),
> Linux pv vTPM frontend was implemented by Daniel De Graaf (NSA)
> 
> 
> 
> > If you are running it on Linux, we might need to introduce Linux based
> > stundoms to the Xen build system.
> 
> Not so.
> Maybe I should explain a bit further. TPM is a character device. 'Qemu tpm1.2 Tis'
> Implement some TPM register hook of TPM, and enable TIS (TPM interface Specification).
> The ' Qemu tpm1.2 Tis ' should deal with TPM commands. 
> 
> Such as TPM_ContinueSelfTest command,
>     { 0x00, 0xc1, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x53};
> If success, the TPM will respond,
>     { 0x00, 0xc4, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x00};
> 
> Qemu upstream has supported TPM passthrough. actually, 'Qemu TPM passthrough' send 
> These TPM commands from "Qemu tpm1.2 Tis" to TPM hardware, and get the respond. 
> 
> " [PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for HVM virtual machine " send 
> These TPM commands from "Qemu tpm1.2 Tis" to Xen stubdom( explain in previous email)
> And get the respond. 
> 
> #(qemu-system-* --tpmdev help)
> #(passthrough   Passthrough TPM backend driver)
> #( xenstubdoms  Xenstubdoms TPM backend driver)
> 
> The following is Qemu part.
> 
>             |        |  ^       |
>             |        v  |       |
>             |        vTPM      |
>             | XenStubdoms driver |  (new ..)
>             +------------------------------+
>                      |  ^
>                      v  |
>             +------------------------------+
>             |  xen_vtpmdev_ops  |  (new ..)
>             +------------------------------+
> "vTPM XenStubdoms driver" and "xen_vtpmdev_ops" are implemented to send These TPM commands 
> from "Qemu tpm1.2 Tis" to Xen stubdom.

OK, so if I understand correctly in your architecture QEMU is running in Dom0 as usual, right?



> > 
> > >  * mini-os/tpmback:
> > >     Mini-os TPM backend driver. The Linux frontend driver connects
> > >     to this backend driver to facilitate communications between the
> > >     Linux DomU and its vTPM. This driver is also used by vtpmmgr
> > >     stubdom to communicate with vTPM stubdom.
> > >
> > >  * vTPM stubdom:
> > >     A mini-os stub domain that implements a vTPM. There is a
> > >     one to one mapping between running vTPM stubdom instances and
> > >     logical vTPMs on the system. The vTPM Platform Configuration
> > >     Registers (PCRs) are all initialized to zero.
> > >
> > >  * mini-os/tpmfront:
> > >     Mini-os TPM frontend driver. The vTPM mini-os domain vTPM
> > >     stubdom uses this driver to communicate with vtpmmgr-stubdom.
> > >     This driver could also be used separately to implement a mini-os
> > >     domain that wishes to use a vTPM of its own.
> > >
> > >  * vtpmmgr stubdom:
> > >     A mini-os domain that implements the vTPM manager. There is only
> > >     one vTPM manager and it should be running during the entire lifetime
> > >     of the machine. vtpmmgr domain securely stores encryption keys for
> > >     each of the vTPMs and accesses to the hardware TPM to get the root
> > of
> > >     trust for the entire system.
> > >
> > >  * mini-os/tpm_tis:
> > >     Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
> > >     This driver used by vtpmmgr-stubdom to talk directly to the hardware
> > >     TPM. Communication is facilitated by mapping hardware memory
> > pages
> > >     into vtpmmgr stubdom.
> > 
> > Are all the Mini-OS component upstream, or do we need patches?
> > 
> > 
> > >  * Hardware TPM:
> > >     The physical TPM 1.2 that is soldered onto the motherboard.
> > >
> > > ===========
> > >
> > >
> > >
> > > > Where does the vTPM backend lives?
> > > The vTPM backend lives in Xen vTPM stubdom (Xen Mini-os)
> > 
> > Thanks for the explanation, it is a bit clearer now.
> > 
> 
> 
> Welcome, thanks for your careful review. 
> 
> 
> 
> > 
> > > >
> > > >
> > > > >  hw/xen/Makefile.objs         |   1 +
> > > > >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> > > > >  hw/xen/xen_stubdom_vtpm.c    | 333
> > > > +++++++++++++++++++++++++++++++++++++++++++
> > > > >  include/hw/xen/xen_backend.h |  11 ++
> > > > >  include/hw/xen/xen_common.h  |   6 +
> > > > >  xen-hvm.c                    |  13 ++
> > > > >  6 files changed, 544 insertions(+), 2 deletions(-)  create mode
> > > > > 100644 hw/xen/xen_stubdom_vtpm.c
> > > > >
> > > > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs index
> > > > > a0ca0aa..724df8d 100644
> > > > > --- a/hw/xen/Makefile.objs
> > > > > +++ b/hw/xen/Makefile.objs
> > > > > @@ -1,5 +1,6 @@
> > > > >  # xen backend driver support
> > > > >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> > > > xen_devconfig.o
> > > > > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) +=
> > xen_stubdom_vtpm.o
> > > > >
> > > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> > > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> > > > xen_pt_config_init.o xen_pt_msi.o
> > > > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index
> > > > > b2cb22b..45a5778 100644
> > > > > --- a/hw/xen/xen_backend.c
> > > > > +++ b/hw/xen/xen_backend.c
> > > > > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice
> > > > > *xendev,
> > > > enum xenbus_state state)
> > > > >      return 0;
> > > > >  }
> > > > >
> > > > > +/*get stubdom backend*/
> > > > > +static char *xen_stubdom_be(const char *type, int dom, int dev) {
> > > > > +    char *val, *domu;
> > > > > +    char path[XEN_BUFSIZE];
> > > > > +    unsigned int len, ival;
> > > > > +
> > > > > +    /*front domu*/
> > > > > +    domu = xs_get_domain_path(xenstore, dom);
> > > > > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > > > > +             domu, type, dev);
> > > > > +    g_free(domu);
> > > > > +
> > > > > +    val = xs_read(xenstore, 0, path, &len);
> > > > > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > > > > +        g_free(val);
> > > > > +        return NULL;
> > > > > +    }
> > > > > +    g_free(val);
> > > > > +
> > > > > +    /*backend domu*/
> > > > > +    domu = xs_get_domain_path(xenstore, ival);
> > > > > +
> > > > > +    return domu;
> > > > > +}
> > > > > +
> > > > >  /* -------------------------------------------------------------
> > > > > */
> > > > >
> > > > >  struct XenDevice *xen_be_find_xendev(const char *type, int dom,
> > > > > int
> > > > dev)
> > > > > @@ -222,6 +248,7 @@ static struct XenDevice
> > > > > *xen_be_get_xendev(const
> > > > char *type, int dom, int dev,
> > > > >                                             struct XenDevOps
> > *ops)
> > > > > {
> > > > >      struct XenDevice *xendev;
> > > > > +    char *stub;
> > > > >
> > > > >      xendev = xen_be_find_xendev(type, dom, dev);
> > > > >      if (xendev) {
> > > > > @@ -235,8 +262,15 @@ static struct XenDevice
> > > > *xen_be_get_xendev(const char *type, int dom, int dev,
> > > > >      xendev->dev   = dev;
> > > > >      xendev->ops   = ops;
> > > > >
> > > > > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > > > > -             xendev->type, xendev->dom, xendev->dev);
> > > > > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > > > > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> > > > xendev->dev);
> > > > > +        snprintf(xendev->be, sizeof(xendev->be),
> > > > "%s/backend/%s/%d/%d",
> > > > > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > > > > +        g_free(stub);
> > > > > +    } else {
> > > > > +        snprintf(xendev->be, sizeof(xendev->be),
> > "backend/%s/%d/%d",
> > > > > +                 xendev->type, xendev->dom, xendev->dev);
> > > > > +    }
> > > > >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> > > > >               xendev->type, xendev->dev);
> > > > >
> > > > > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type,
> > > > > int
> > > > dom, struct XenDevOps *ops)
> > > > >      return 0;
> > > > >  }
> > > > >
> > > > > +static void stubdom_update_be(char *watch, char *type, int dom,
> > > > > +                              struct XenDevOps *ops) {
> > > > > +    struct XenDevice *xendev;
> > > > > +    char path[XEN_BUFSIZE];
> > > > > +    char *ptr, *bepath;
> > > > > +    unsigned int len, dev;
> > > > > +
> > > > > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > > > > +        return;
> > > > > +    }
> > > > > +
> > > > > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > > > > +    ptr = strstr(watch, path);
> > > > > +    if (ptr == NULL) {
> > > > > +        return;
> > > > > +    }
> > > > > +
> > > > > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > > > > +        strcpy(path, "");
> > > > > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > > > > +            dev = -1;
> > > > > +        }
> > > > > +    }
> > > > > +
> > > > > +    if (dev == -1) {
> > > > > +        return;
> > > > > +    }
> > > > > +
> > > > > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > > > > +    if (xendev != NULL) {
> > > > > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > > > > +        if (bepath == NULL) {
> > > > > +            xen_be_del_xendev(dom, dev);
> > > > > +        } else {
> > > > > +            free(bepath);
> > > > > +            xen_be_backend_changed(xendev, path);
> > > > > +        }
> > > > > +    }
> > > > > +}
> > > > > +
> > > > >  static void xenstore_update_be(char *watch, char *type, int dom,
> > > > >                                 struct XenDevOps *ops)  { @@
> > > > > -681,6 +756,10 @@ static void xenstore_update(void *unused)
> > > > >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> > > > >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> > > > >      }
> > > > > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> > > > PRIxPTR,
> > > > > +               &type, &dom, &ops) == 3) {
> > > > > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type,
> > dom,
> > > > (void *)ops);
> > > > > +    }
> > > > >
> > > > >  cleanup:
> > > > >      free(vec);
> > > > > @@ -732,11 +811,74 @@ err:
> > > > >      return -1;
> > > > >  }
> > > > >
> > > > > +int xen_vtpm_register(struct XenDevOps *ops) {
> > > > > +    struct XenDevice *xendev;
> > > > > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > > > > +    char *domu;
> > > > > +    unsigned int cdev, j, rc;
> > > > > +    const char *type = "vtpm";
> > > > > +    char **dev = NULL;
> > > > > +
> > > > > +    /*front domu*/
> > > > > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > > > > +    snprintf(path, sizeof(path), "%s/device/%s",
> > > > > +             domu, type);
> > > > > +    free(domu);
> > > > > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > > > > +    if (dev == NULL) {
> > > > > +        return 0;
> > > > > +    }
> > > > > +
> > > > > +    for (j = 0; j < cdev; j++) {
> > > > > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> > > > ops);
> > > > > +        if (xendev == NULL) {
> > > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> > > > NULL.\n");
> > > > > +            continue;
> > > > > +        }
> > > > > +
> > > > > +        if (xendev->ops->initialise) {
> > > > > +            rc = xendev->ops->initialise(xendev);
> > > > > +
> > > > > +            /*if initialise failed, delete it*/
> > > > > +            if (rc != 0) {
> > > > > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > > > > +                continue;
> > > > > +            }
> > > > > +        }
> > > > > +
> > > > > +        /*setup watch*/
> > > > > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > > > > +                 type, xen_domid, xendev->ops);
> > > > > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> > > > failed.\n");
> > > > > +            return -1;
> > > > > +        }
> > > > > +    }
> > > > > +
> > > > > +    free(dev);
> > > > > +    return 0;
> > > > > +}
> > > >
> > > > What does this function do? I sholdn't need  to guess from the code,
> > > > I should be able to tell from the patch description.
> > > >
> > > >
> > > > >  int xen_be_register(const char *type, struct XenDevOps *ops)  {
> > > > >      return xenstore_scan(type, xen_domid, ops);  }
> > > > >
> > > > > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > > > remote_dom)
> > > > > +{
> > > > > +    xendev->local_port =
> > > > xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > > > > +
> > > > remote_dom);
> > > > > +    if (xendev->local_port == -1) {
> > > > > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound
> > failed\n");
> > > > > +        return -1;
> > > > > +    }
> > > > > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> > > > xendev->local_port);
> > > > > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > > > > +                        xen_be_evtchn_event, NULL, xendev);
> > > > > +    return 0;
> > > > > +}
> > > > > +
> > > > >  int xen_be_bind_evtchn(struct XenDevice *xendev)  {
> > > > >      if (xendev->local_port != -1) { @@ -770,6 +912,42 @@ int
> > > > > xen_be_send_notify(struct XenDevice
> > > > *xendev)
> > > > >      return xc_evtchn_notify(xendev->evtchndev,
> > > > > xendev->local_port);  }
> > > > >
> > > > > +int xen_vtpm_send(unsigned char *buf, size_t count) {
> > > > > +    struct XenDevice *xendev;
> > > > > +    int rc = -1;
> > > > > +
> > > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > > +    if (xendev == NULL) {
> > > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    if (xendev->ops->send) {
> > > > > +        rc = xendev->ops->send(xendev, buf, count);
> > > > > +    }
> > > > > +
> > > > > +    return rc;
> > > > > +}
> > > > > +
> > > > > +int xen_vtpm_recv(unsigned char *buf, size_t *count) {
> > > > > +    struct XenDevice *xendev;
> > > > > +    int rc = -1;
> > > > > +
> > > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > > +    if (xendev == NULL) {
> > > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    if (xendev->ops->recv) {
> > > > > +        xendev->ops->recv(xendev, buf, count);
> > > > > +    }
> > > > > +
> > > > > +    return rc;
> > > > > +}
> > > >
> > > > xen_backend.c is supposed to be generic, so stubdom functions might
> > > > be OK but vtpm specific functions should not be here.
> > > >
> > > >
> > > > >  /*
> > > > >   * msg_level:
> > > > >   *  0 == errors (stderr + logfile).
> > > > > diff --git a/hw/xen/xen_stubdom_vtpm.c
> > b/hw/xen/xen_stubdom_vtpm.c
> > > > > new file mode 100644 index 0000000..0d740c1
> > > > > --- /dev/null
> > > > > +++ b/hw/xen/xen_stubdom_vtpm.c
> > > > > @@ -0,0 +1,333 @@
> > > > > +/*
> > > > > + * Connect to Xen vTPM stubdom domain
> > > > > + *
> > > > > + *  Copyright (c) 2014 Intel Corporation
> > > > > + *  Authors:
> > > > > + *    Quan Xu <quan.xu@intel.com>
> > > > > + *
> > > > > + * 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 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, see
> > > > <http://www.gnu.org/licenses/>
> > > > > + */
> > > > > +
> > > > > +#include <stdio.h>
> > > > > +#include <stdlib.h>
> > > > > +#include <stdarg.h>
> > > > > +#include <string.h>
> > > > > +#include <unistd.h>
> > > > > +#include <signal.h>
> > > > > +#include <inttypes.h>
> > > > > +#include <time.h>
> > > > > +#include <fcntl.h>
> > > > > +#include <errno.h>
> > > > > +#include <sys/ioctl.h>
> > > > > +#include <sys/types.h>
> > > > > +#include <sys/stat.h>
> > > > > +#include <sys/mman.h>
> > > > > +#include <sys/uio.h>
> > > > > +
> > > > > +#include "hw/hw.h"
> > > > > +#include "block/aio.h"
> > > > > +#include "hw/xen/xen_backend.h"
> > > > > +
> > > > > +enum tpmif_state {
> > > > > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> > > > complete */
> > > > > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > > > > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > > > > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM
> > working */
> > > > > +};
> > > > > +
> > > > > +static AioContext *vtpm_aio_ctx;
> > > > > +
> > > > > +enum status_bits {
> > > > > +    VTPM_STATUS_RUNNING  = 0x1,
> > > > > +    VTPM_STATUS_IDLE     = 0x2,
> > > > > +    VTPM_STATUS_RESULT   = 0x4,
> > > > > +    VTPM_STATUS_CANCELED = 0x8,
> > > > > +};
> > > > > +
> > > > > +struct tpmif_shared_page {
> > > > > +    uint32_t length;         /* request/response length in bytes */
> > > > > +
> > > > > +    uint8_t  state;           /* enum tpmif_state */
> > > > > +    uint8_t  locality;        /* for the current request */
> > > > > +    uint8_t  pad;             /* should be zero */
> > > > > +
> > > > > +    uint8_t  nr_extra_pages;  /* extra pages for long packets;
> > > > > + may be
> > > > zero */
> > > > > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> > > > nr_extra_pages */
> > > > > +};
> > > > > +
> > > > > +struct QEMUBH {
> > > > > +    AioContext *ctx;
> > > > > +    QEMUBHFunc *cb;
> > > > > +    void *opaque;
> > > > > +    QEMUBH *next;
> > > > > +    bool scheduled;
> > > > > +    bool idle;
> > > > > +    bool deleted;
> > > > > +};
> > > > > +
> > > > > +struct XenVtpmDev {
> > > > > +    struct XenDevice xendev;  /* must be first */
> > > > > +    struct           tpmif_shared_page *shr;
> > > > > +    xc_gntshr        *xen_xcs;
> > > > > +    int              ring_ref;
> > > > > +    int              bedomid;
> > > > > +    QEMUBH           *sr_bh;
> > > > > +};
> > > > > +
> > > > > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev) {
> > > > > +    switch (vtpmdev->shr->state) {
> > > > > +    case TPMIF_STATE_IDLE:
> > > > > +    case TPMIF_STATE_FINISH:
> > > > > +        return VTPM_STATUS_IDLE;
> > > > > +    case TPMIF_STATE_SUBMIT:
> > > > > +    case TPMIF_STATE_CANCEL:
> > > > > +        return VTPM_STATUS_RUNNING;
> > > > > +    default:
> > > > > +        return 0;
> > > > > +    }
> > > > > +}
> > > > > +
> > > > > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> > > > xenbus_state xbus)
> > > > > +{
> > > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > > +
> > > > > +    if (xendev->fe_state == xbus) {
> > > > > +        return 0;
> > > > > +    }
> > > > > +
> > > > > +    xendev->fe_state = xbus;
> > > > > +
> > > > > +retry_transaction:
> > > > > +    xbt = xs_transaction_start(xenstore);
> > > > > +    if (xbt == XBT_NULL) {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > > +        if (errno == EAGAIN) {
> > > > > +            goto retry_transaction;
> > > > > +        }
> > > > > +    }
> > > > > +
> > > > > +    return 0;
> > > > > +
> > > > > +abort_transaction:
> > > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > > +    return -1;
> > > > > +}
> > > > > +
> > > > > +static int vtpm_aio_wait(QEMUBH *qbh) {
> > > > > +    return aio_poll(qbh->ctx, true); }
> > > > > +
> > > > > +static void sr_bh_handler(void *opaque) { }
> > > > > +
> > > > > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf,
> > > > > +size_t
> > > > *count)
> > > > > +{
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > > +    unsigned int offset;
> > > > > +
> > > > > +    if (shr->state == TPMIF_STATE_IDLE) {
> > > > > +        return -ECANCELED;
> > > > > +    }
> > > > > +
> > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > +    }
> > > > > +
> > > > > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > > > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > > > > +    *count = shr->length;
> > > > > +
> > > > > +    return 0;
> > > > > +}
> > > > > +
> > > > > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf,
> > > > > +size_t
> > > > count)
> > > > > +{
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > > > +
> > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > +    }
> > > > > +
> > > > > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > > > > +    shr->length = count;
> > > > > +    barrier();
> > > > > +    shr->state = TPMIF_STATE_SUBMIT;
> > > > > +    xen_wmb();
> > > > > +    xen_be_send_notify(&vtpmdev->xendev);
> > > > > +
> > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > +    }
> > > > > +
> > > > > +    return count;
> > > > > +}
> > > > > +
> > > > > +static int vtpm_initialise(struct XenDevice *xendev) {
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > > +    unsigned int ring_ref;
> > > > > +
> > > > > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> > > > "frontend");
> > > > > +    if (vtpmdev->xendev.fe == NULL) {
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    /* Get backend domid */
> > > > > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > > > > +                             &vtpmdev->bedomid)) {
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    /*alloc share page*/
> > > > > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> > > > vtpmdev->bedomid, 1,
> > > > > +                                         &ring_ref,
> > > > PROT_READ|PROT_WRITE);
> > > > > +    vtpmdev->ring_ref = ring_ref;
> > > > > +    if (vtpmdev->shr == NULL) {
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    /*Create event channel */
> > > > > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> > > > vtpmdev->bedomid)) {
> > > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > > > > +                     vtpmdev->xendev.local_port);
> > > > > +
> > > > > +again:
> > > > > +    xbt = xs_transaction_start(xenstore);
> > > > > +    if (xbt == XBT_NULL) {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > > > > +                           vtpmdev->ring_ref)) {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > > > > +                           vtpmdev->xendev.local_port)) {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    /* Publish protocol v2 feature */
> > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe,
> > > > > + "feature-protocol-v2", 1))
> > > > {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > > +        if (errno == EAGAIN) {
> > > > > +            goto again;
> > > > > +        }
> > > > > +    }
> > > > > +    /* Tell vtpm backend that we are ready */
> > > > > +    xenbus_switch_state(&vtpmdev->xendev,
> > > > > + XenbusStateInitialised);
> > > > > +
> > > > > +    return 0;
> > > > > +
> > > > > +abort_transaction:
> > > > > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > > +    return -1;
> > > > > +}
> > > > > +
> > > > > +static void vtpm_backend_changed(struct XenDevice *xendev, const
> > > > > +char
> > > > *node)
> > > > > +{
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +    int be_state;
> > > > > +
> > > > > +    if (strcmp(node, "state") == 0) {
> > > > > +        xenstore_read_be_int(&vtpmdev->xendev, node,
> > &be_state);
> > > > > +        switch (be_state) {
> > > > > +        case XenbusStateConnected:
> > > > > +            /*TODO*/
> > > > > +            break;
> > > > > +        case XenbusStateClosing:
> > > > > +        case XenbusStateClosed:
> > > > > +            xenbus_switch_state(&vtpmdev->xendev,
> > > > XenbusStateClosing);
> > > > > +            break;
> > > > > +        default:
> > > > > +            break;
> > > > > +        }
> > > > > +    }
> > > > > +}
> > > > > +
> > > > > +static int vtpm_free(struct XenDevice *xendev) {
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > > > > +
> > > > > +    aio_poll(qbh->ctx, false);
> > > > > +    qemu_bh_delete(vtpmdev->sr_bh);
> > > > > +    if (vtpmdev->shr) {
> > > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > > +    }
> > > > > +    xc_interface_close(vtpmdev->xen_xcs);
> > > > > +    return 0;
> > > > > +}
> > > > > +
> > > > > +static void vtpm_alloc(struct XenDevice *xendev) {
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +
> > > > > +    vtpm_aio_ctx = aio_context_new(NULL);
> > > > > +    if (vtpm_aio_ctx == NULL) {
> > > > > +        return;
> > > > > +    }
> > > > > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> > > > vtpmdev);
> > > > > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > > > > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0); }
> > > > > +
> > > > > +static void vtpm_event(struct XenDevice *xendev) {
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +
> > > > > +    qemu_bh_schedule(vtpmdev->sr_bh); }
> > > > > +
> > > > > +struct XenDevOps xen_vtpmdev_ops = {
> > > > > +    .size             = sizeof(struct XenVtpmDev),
> > > > > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > > > > +                        DEVOPS_FLAG_STUBDOM_BE,
> > > > > +    .event            = vtpm_event,
> > > > > +    .free             = vtpm_free,
> > > > > +    .alloc            = vtpm_alloc,
> > > > > +    .initialise       = vtpm_initialise,
> > > > > +    .backend_changed  = vtpm_backend_changed,
> > > > > +    .recv             = vtpm_recv,
> > > > > +    .send             = vtpm_send,
> > > > > +};
> > > >
> > > > Is this the frontend, like the subject line would seem to imply?
> > > > If so, XenDevOps are made for backends, while this is a frontend. In
> > > > fact this is the first PV frontend in QEMU. We need to introduce
> > > > something generic and similar to struct XenDevOps and xen_backend.c
> > > > but for frontends.
> > > >
> > > >
> > > > > diff --git a/include/hw/xen/xen_backend.h
> > > > b/include/hw/xen/xen_backend.h
> > > > > index 3b4125e..45fd6d3 100644
> > > > > --- a/include/hw/xen/xen_backend.h
> > > > > +++ b/include/hw/xen/xen_backend.h
> > > > > @@ -15,6 +15,8 @@ struct XenDevice;
> > > > >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> > > > >  /* don't expect frontend doing correct state transitions (aka
> > > > > console
> > > > quirk) */
> > > > >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > > > > +/*dev backend is stubdom*/
> > > > > +#define DEVOPS_FLAG_STUBDOM_BE    4
> > > > >
> > > > >  struct XenDevOps {
> > > > >      size_t    size;
> > > > > @@ -26,6 +28,8 @@ struct XenDevOps {
> > > > >      void      (*event)(struct XenDevice *xendev);
> > > > >      void      (*disconnect)(struct XenDevice *xendev);
> > > > >      int       (*free)(struct XenDevice *xendev);
> > > > > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> > > > count);
> > > > > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> > > > *count);
> > > > >      void      (*backend_changed)(struct XenDevice *xendev, const
> > > > char *node);
> > > > >      void      (*frontend_changed)(struct XenDevice *xendev, const
> > > > char *node);
> > > > >  };
> > > > > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> > > > *xendev);
> > > > >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const
> > > > > char
> > > > *fmt, ...)
> > > > >      GCC_FMT_ATTR(3, 4);
> > > > >
> > > > > +/*Xen stubdom vtpm*/
> > > > > +int xen_vtpm_register(struct XenDevOps *ops); int
> > > > > +xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > > > remote_dom);
> > > > > +int xen_vtpm_send(unsigned char *buf, size_t count); int
> > > > > +xen_vtpm_recv(unsigned char *buf, size_t *count);
> > > > > +
> > > > >  /* actual backend drivers */
> > > > >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> > > > */
> > > > >  extern struct XenDevOps xen_kbdmouse_ops;     /*
> > xen_framebuffer.c
> > > > */
> > > > >  extern struct XenDevOps xen_framebuffer_ops;  /*
> > xen_framebuffer.c */
> > > > >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> > > > */
> > > > >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> > > > */
> > > > > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> > > > xen_stubdom_vtpm.c*/
> > > > >
> > > > >  void xen_init_display(int domid);
> > > > >
> > > > > diff --git a/include/hw/xen/xen_common.h
> > > > b/include/hw/xen/xen_common.h
> > > > > index 95612a4..fb43084 100644
> > > > > --- a/include/hw/xen/xen_common.h
> > > > > +++ b/include/hw/xen/xen_common.h
> > > > > @@ -130,6 +130,12 @@ static inline XenXC
> > > > > xen_xc_interface_open(void
> > > > *logger, void *dombuild_logger,
> > > > >      return xc_interface_open(logger, dombuild_logger,
> > > > > open_flags);  }
> > > > >
> > > > > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > > > > +                                           unsigned int
> > > > > +open_flags) {
> > > > > +    return xc_gntshr_open(logger, open_flags); }
> > > > > +
> > > > >  /* FIXME There is now way to have the xen fd */  static inline
> > > > > int xc_fd(xc_interface *xen_xc)  { diff --git a/xen-hvm.c
> > > > > b/xen-hvm.c index 21f1cbb..c99ace8 100644
> > > > > --- a/xen-hvm.c
> > > > > +++ b/xen-hvm.c
> > > > > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> > > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > > >      int i, rc;
> > > > >      unsigned long ioreq_pfn;
> > > > >      unsigned long bufioreq_evtchn;
> > > > > +
> > > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > > +    unsigned long stubdom_vtpm = 0; #endif
> > > > > +
> > > > >      XenIOState *state;
> > > > >
> > > > >      state = g_malloc0(sizeof (XenIOState)); @@ -1169,6 +1174,14
> > > > > @@ int xen_hvm_init(ram_addr_t
> > > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > > >          fprintf(stderr, "%s: xen backend core setup failed\n",
> > > > __FUNCTION__);
> > > > >          return -1;
> > > > >      }
> > > > > +
> > > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > > +    xc_get_hvm_param(xen_xc, xen_domid,
> > > > HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > > > > +    if (stubdom_vtpm) {
> > > > > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > > > > +    }
> > > > > +#endif
> > > >
> > > > Given that vtpm is just a PV frontend, can't you just detect whether
> > > > is present on xenstore and initialize it based on that? Like all the
> > > > backend below?
> > >
> > > Also I will explain in my next email.
> > >
> > >
> > > >
> > > >
> > > > >      xen_be_register("console", &xen_console_ops);
> > > > >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> > > > >      xen_be_register("qdisk", &xen_blkdev_ops);
> > > > > --
> > > > > 1.8.3.2
> > > > >
> > >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 18:24:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 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 1Xm5Fm-0004pN-Un; Wed, 05 Nov 2014 18:24: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@citrix.com>) id 1Xm5Fl-0004pG-KU
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 18:24:21 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	00/65-22819-45B6A545; Wed, 05 Nov 2014 18:24:20 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415211857!11449020!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27671 invoked from network); 5 Nov 2014 18:24:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 18:24:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,321,1413244800"; d="scan'208";a="189842836"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 5 Nov 2014 13:24:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xm5Fe-0005eO-C0;
	Wed, 05 Nov 2014 18:24:14 +0000
Date: Wed, 5 Nov 2014 18:24:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Quan" <quan.xu@intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E8202B7@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411051821510.22875@kaball.uk.xensource.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411051036310.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8202B7@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Nov 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Wednesday, November 05, 2014 7:01 PM
> > To: Xu, Quan
> > Cc: Stefano Stabellini; qemu-devel@nongnu.org; xen-devel@lists.xen.org
> > Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > frontend driver
> > 
> > On Tue, 4 Nov 2014, Xu, Quan wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Monday, November 03, 2014 7:54 PM
> > > > To: Xu, Quan
> > > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > > > stefano.stabellini@eu.citrix.com
> > > > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > > > frontend driver
> > > >
> > > > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > > > This drvier transfers any request/repond between TPM xenstubdoms
> > > > > driver and Xen vTPM stubdom, and facilitates communications
> > > > > between Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > > > >
> > > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > >
> > > > Please describe what changes did make to xen_backend.c and why.
> > > > The commit message should contains info on all the changes made by
> > > > the patch below.
> > > >
> > >
> > > Thanks Stefano.
> > > one more day, I will explain in detail what changes did make to
> > > xen_backend.c and why.
> > > The following 2 sections are introduction and architecture.
> > >
> > > > Please also describe what is the "Xen vTPM stubdom", what is the
> > > > "vTPM xenstubdoms driver" and how the communicate with each others.
> > > >
> > >
> > >
> > > Add 2 parts for detailed descriptions, introduction and architecture.
> > >
> > > *INTRODUCTION*
> > >
> > > The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM
> > > functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows
> > > .etc). This allows programs to interact with a TPM in a virtual
> > > machine the same way they interact with a TPM on the physical system.
> > Each virtual machine gets its own unique, emulated, software TPM.
> > > Each major component of vTPM is implemented as a stubdom, providing
> > > secure separation guaranteed by the hypervisor.
> > > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the
> > > virtual machine to use. It is a small wrapper around the Berlios TPM
> > > emulator. TPM commands are passed from mini-os TPM backend driver.
> > > This patch series are only the Qemu part to enable Xen stubdom vTPM
> > > for HVM virtual machine.
> > > ===========
> > >
> > > *ARCHITECTURE*
> > >
> > > The architecture of stubdom vTPM for HVM virtual machine:
> > >
> > >             +--------------------+
> > >             | Windows/Linux DomU | ...
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |  Qemu tpm1.2 Tis   |
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |        vTPM        |
> > >             | XenStubdoms driver |  (new ..)
> > >             +--------------------+
> > >                      |  ^
> > >                      v  |
> > >             +--------------------+
> > >             |  xen_vtpmdev_ops   |  (new ..)
> > >             +--------------------+
> > >                      |  ^
> > >                      v  |
> > >             +--------------------+
> > >             |  mini-os/tpmback   |
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |   vTPM stubdom     | ...
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |  mini-os/tpmfront  |
> > >             +--------------------+
> > >                      |  ^
> > >                      v  |
> > >             +--------------------+
> > >             |  mini-os/tpmback   |
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |  vtpmmgr stubdom   |
> > >             |        |  ^        |
> > >             |        v  |        |
> > >             |  mini-os/tpm_tis   |
> > >             +--------------------+
> > >                      |  ^
> > >                      v  |
> > >             +--------------------+
> > >             |    Hardware TPM    |
> > >             +--------------------+
> > >
> > >
> > > * Windows/Linux DomU:
> > >     The HVM based guest that wants to use a vTPM. There may be
> > >     more than one of these.
> > >
> > >  * Qemu tpm1.2 Tis:
> > >     Implementation of the tpm1.2 Tis interface for HVM virtual
> > >     machines. It is Qemu emulation device.
> > 
> > It looks like you are running upstream QEMU within a Mini-OS stubdom?
> > If so, where are the patches to do that? As far as I know upstream QEMU
> > doesn't run on Mini-OS. Or maybe it is a Linux stubdom? Either way, it is not
> > clear.
> 
> Not so.
> Refer to below further explanation. 
> 
> > 
> > 
> > >  * vTPM xenstubdoms driver:
> > >     Similar to a TPM passthrough backend driver, it is a new TPM
> > >     backend for emulated TPM TIS interface. This driver provides
> > >     vTPM initialization and sending data and commends to a Xen
> > >     vTPM stubdom.
> > 
> > This is patch #3, right? It is basically the internal QEMU "glue" to connect the
> > tpm emulator to xen_vtpmdev_ops, correct?
> > 
> 
> Yes, it is Patch #3. Agree with your description.  :)
> 
> > 
> > >  * xen_vtpmdev_ops:
> > >     Register Xen stubdom vTPM backend, and transfer any request/
> > >     repond between TPM xenstubdoms driver and Xen vTPM stubdom.
> > >     Facilitate communications between Xen vTPM stubdom and vTPM
> > >     xenstubdoms driver.
> > 
> > It looks like this correspond to patch #2? If so, this is a regular Xen PV
> 
> Yes, it patch #2.
> 
> 
> > frontend, living in QEMU? It requires the gntalloc device so I guess it is
> > supposed to run on Linux. In that case is it just a tpmfront implementation in
> > QEMU?
> > 
> 
> 
> Yes, it's tpmfront implementation in Qemu. also it supports PV Linux since Xen 4.3.0.
> vTPM stubdom / vtpmmgr stubdom  ware implemented by Matthew Fioravante (JHUAPL),
> Linux pv vTPM frontend was implemented by Daniel De Graaf (NSA)
> 
> 
> 
> > If you are running it on Linux, we might need to introduce Linux based
> > stundoms to the Xen build system.
> 
> Not so.
> Maybe I should explain a bit further. TPM is a character device. 'Qemu tpm1.2 Tis'
> Implement some TPM register hook of TPM, and enable TIS (TPM interface Specification).
> The ' Qemu tpm1.2 Tis ' should deal with TPM commands. 
> 
> Such as TPM_ContinueSelfTest command,
>     { 0x00, 0xc1, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x53};
> If success, the TPM will respond,
>     { 0x00, 0xc4, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x00};
> 
> Qemu upstream has supported TPM passthrough. actually, 'Qemu TPM passthrough' send 
> These TPM commands from "Qemu tpm1.2 Tis" to TPM hardware, and get the respond. 
> 
> " [PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for HVM virtual machine " send 
> These TPM commands from "Qemu tpm1.2 Tis" to Xen stubdom( explain in previous email)
> And get the respond. 
> 
> #(qemu-system-* --tpmdev help)
> #(passthrough   Passthrough TPM backend driver)
> #( xenstubdoms  Xenstubdoms TPM backend driver)
> 
> The following is Qemu part.
> 
>             |        |  ^       |
>             |        v  |       |
>             |        vTPM      |
>             | XenStubdoms driver |  (new ..)
>             +------------------------------+
>                      |  ^
>                      v  |
>             +------------------------------+
>             |  xen_vtpmdev_ops  |  (new ..)
>             +------------------------------+
> "vTPM XenStubdoms driver" and "xen_vtpmdev_ops" are implemented to send These TPM commands 
> from "Qemu tpm1.2 Tis" to Xen stubdom.

OK, so if I understand correctly in your architecture QEMU is running in Dom0 as usual, right?



> > 
> > >  * mini-os/tpmback:
> > >     Mini-os TPM backend driver. The Linux frontend driver connects
> > >     to this backend driver to facilitate communications between the
> > >     Linux DomU and its vTPM. This driver is also used by vtpmmgr
> > >     stubdom to communicate with vTPM stubdom.
> > >
> > >  * vTPM stubdom:
> > >     A mini-os stub domain that implements a vTPM. There is a
> > >     one to one mapping between running vTPM stubdom instances and
> > >     logical vTPMs on the system. The vTPM Platform Configuration
> > >     Registers (PCRs) are all initialized to zero.
> > >
> > >  * mini-os/tpmfront:
> > >     Mini-os TPM frontend driver. The vTPM mini-os domain vTPM
> > >     stubdom uses this driver to communicate with vtpmmgr-stubdom.
> > >     This driver could also be used separately to implement a mini-os
> > >     domain that wishes to use a vTPM of its own.
> > >
> > >  * vtpmmgr stubdom:
> > >     A mini-os domain that implements the vTPM manager. There is only
> > >     one vTPM manager and it should be running during the entire lifetime
> > >     of the machine. vtpmmgr domain securely stores encryption keys for
> > >     each of the vTPMs and accesses to the hardware TPM to get the root
> > of
> > >     trust for the entire system.
> > >
> > >  * mini-os/tpm_tis:
> > >     Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
> > >     This driver used by vtpmmgr-stubdom to talk directly to the hardware
> > >     TPM. Communication is facilitated by mapping hardware memory
> > pages
> > >     into vtpmmgr stubdom.
> > 
> > Are all the Mini-OS component upstream, or do we need patches?
> > 
> > 
> > >  * Hardware TPM:
> > >     The physical TPM 1.2 that is soldered onto the motherboard.
> > >
> > > ===========
> > >
> > >
> > >
> > > > Where does the vTPM backend lives?
> > > The vTPM backend lives in Xen vTPM stubdom (Xen Mini-os)
> > 
> > Thanks for the explanation, it is a bit clearer now.
> > 
> 
> 
> Welcome, thanks for your careful review. 
> 
> 
> 
> > 
> > > >
> > > >
> > > > >  hw/xen/Makefile.objs         |   1 +
> > > > >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> > > > >  hw/xen/xen_stubdom_vtpm.c    | 333
> > > > +++++++++++++++++++++++++++++++++++++++++++
> > > > >  include/hw/xen/xen_backend.h |  11 ++
> > > > >  include/hw/xen/xen_common.h  |   6 +
> > > > >  xen-hvm.c                    |  13 ++
> > > > >  6 files changed, 544 insertions(+), 2 deletions(-)  create mode
> > > > > 100644 hw/xen/xen_stubdom_vtpm.c
> > > > >
> > > > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs index
> > > > > a0ca0aa..724df8d 100644
> > > > > --- a/hw/xen/Makefile.objs
> > > > > +++ b/hw/xen/Makefile.objs
> > > > > @@ -1,5 +1,6 @@
> > > > >  # xen backend driver support
> > > > >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> > > > xen_devconfig.o
> > > > > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) +=
> > xen_stubdom_vtpm.o
> > > > >
> > > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> > > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> > > > xen_pt_config_init.o xen_pt_msi.o
> > > > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index
> > > > > b2cb22b..45a5778 100644
> > > > > --- a/hw/xen/xen_backend.c
> > > > > +++ b/hw/xen/xen_backend.c
> > > > > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice
> > > > > *xendev,
> > > > enum xenbus_state state)
> > > > >      return 0;
> > > > >  }
> > > > >
> > > > > +/*get stubdom backend*/
> > > > > +static char *xen_stubdom_be(const char *type, int dom, int dev) {
> > > > > +    char *val, *domu;
> > > > > +    char path[XEN_BUFSIZE];
> > > > > +    unsigned int len, ival;
> > > > > +
> > > > > +    /*front domu*/
> > > > > +    domu = xs_get_domain_path(xenstore, dom);
> > > > > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > > > > +             domu, type, dev);
> > > > > +    g_free(domu);
> > > > > +
> > > > > +    val = xs_read(xenstore, 0, path, &len);
> > > > > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > > > > +        g_free(val);
> > > > > +        return NULL;
> > > > > +    }
> > > > > +    g_free(val);
> > > > > +
> > > > > +    /*backend domu*/
> > > > > +    domu = xs_get_domain_path(xenstore, ival);
> > > > > +
> > > > > +    return domu;
> > > > > +}
> > > > > +
> > > > >  /* -------------------------------------------------------------
> > > > > */
> > > > >
> > > > >  struct XenDevice *xen_be_find_xendev(const char *type, int dom,
> > > > > int
> > > > dev)
> > > > > @@ -222,6 +248,7 @@ static struct XenDevice
> > > > > *xen_be_get_xendev(const
> > > > char *type, int dom, int dev,
> > > > >                                             struct XenDevOps
> > *ops)
> > > > > {
> > > > >      struct XenDevice *xendev;
> > > > > +    char *stub;
> > > > >
> > > > >      xendev = xen_be_find_xendev(type, dom, dev);
> > > > >      if (xendev) {
> > > > > @@ -235,8 +262,15 @@ static struct XenDevice
> > > > *xen_be_get_xendev(const char *type, int dom, int dev,
> > > > >      xendev->dev   = dev;
> > > > >      xendev->ops   = ops;
> > > > >
> > > > > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > > > > -             xendev->type, xendev->dom, xendev->dev);
> > > > > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > > > > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> > > > xendev->dev);
> > > > > +        snprintf(xendev->be, sizeof(xendev->be),
> > > > "%s/backend/%s/%d/%d",
> > > > > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > > > > +        g_free(stub);
> > > > > +    } else {
> > > > > +        snprintf(xendev->be, sizeof(xendev->be),
> > "backend/%s/%d/%d",
> > > > > +                 xendev->type, xendev->dom, xendev->dev);
> > > > > +    }
> > > > >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> > > > >               xendev->type, xendev->dev);
> > > > >
> > > > > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type,
> > > > > int
> > > > dom, struct XenDevOps *ops)
> > > > >      return 0;
> > > > >  }
> > > > >
> > > > > +static void stubdom_update_be(char *watch, char *type, int dom,
> > > > > +                              struct XenDevOps *ops) {
> > > > > +    struct XenDevice *xendev;
> > > > > +    char path[XEN_BUFSIZE];
> > > > > +    char *ptr, *bepath;
> > > > > +    unsigned int len, dev;
> > > > > +
> > > > > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > > > > +        return;
> > > > > +    }
> > > > > +
> > > > > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > > > > +    ptr = strstr(watch, path);
> > > > > +    if (ptr == NULL) {
> > > > > +        return;
> > > > > +    }
> > > > > +
> > > > > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > > > > +        strcpy(path, "");
> > > > > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > > > > +            dev = -1;
> > > > > +        }
> > > > > +    }
> > > > > +
> > > > > +    if (dev == -1) {
> > > > > +        return;
> > > > > +    }
> > > > > +
> > > > > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > > > > +    if (xendev != NULL) {
> > > > > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > > > > +        if (bepath == NULL) {
> > > > > +            xen_be_del_xendev(dom, dev);
> > > > > +        } else {
> > > > > +            free(bepath);
> > > > > +            xen_be_backend_changed(xendev, path);
> > > > > +        }
> > > > > +    }
> > > > > +}
> > > > > +
> > > > >  static void xenstore_update_be(char *watch, char *type, int dom,
> > > > >                                 struct XenDevOps *ops)  { @@
> > > > > -681,6 +756,10 @@ static void xenstore_update(void *unused)
> > > > >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> > > > >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> > > > >      }
> > > > > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> > > > PRIxPTR,
> > > > > +               &type, &dom, &ops) == 3) {
> > > > > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type,
> > dom,
> > > > (void *)ops);
> > > > > +    }
> > > > >
> > > > >  cleanup:
> > > > >      free(vec);
> > > > > @@ -732,11 +811,74 @@ err:
> > > > >      return -1;
> > > > >  }
> > > > >
> > > > > +int xen_vtpm_register(struct XenDevOps *ops) {
> > > > > +    struct XenDevice *xendev;
> > > > > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > > > > +    char *domu;
> > > > > +    unsigned int cdev, j, rc;
> > > > > +    const char *type = "vtpm";
> > > > > +    char **dev = NULL;
> > > > > +
> > > > > +    /*front domu*/
> > > > > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > > > > +    snprintf(path, sizeof(path), "%s/device/%s",
> > > > > +             domu, type);
> > > > > +    free(domu);
> > > > > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > > > > +    if (dev == NULL) {
> > > > > +        return 0;
> > > > > +    }
> > > > > +
> > > > > +    for (j = 0; j < cdev; j++) {
> > > > > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> > > > ops);
> > > > > +        if (xendev == NULL) {
> > > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> > > > NULL.\n");
> > > > > +            continue;
> > > > > +        }
> > > > > +
> > > > > +        if (xendev->ops->initialise) {
> > > > > +            rc = xendev->ops->initialise(xendev);
> > > > > +
> > > > > +            /*if initialise failed, delete it*/
> > > > > +            if (rc != 0) {
> > > > > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > > > > +                continue;
> > > > > +            }
> > > > > +        }
> > > > > +
> > > > > +        /*setup watch*/
> > > > > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > > > > +                 type, xen_domid, xendev->ops);
> > > > > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> > > > failed.\n");
> > > > > +            return -1;
> > > > > +        }
> > > > > +    }
> > > > > +
> > > > > +    free(dev);
> > > > > +    return 0;
> > > > > +}
> > > >
> > > > What does this function do? I sholdn't need  to guess from the code,
> > > > I should be able to tell from the patch description.
> > > >
> > > >
> > > > >  int xen_be_register(const char *type, struct XenDevOps *ops)  {
> > > > >      return xenstore_scan(type, xen_domid, ops);  }
> > > > >
> > > > > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > > > remote_dom)
> > > > > +{
> > > > > +    xendev->local_port =
> > > > xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > > > > +
> > > > remote_dom);
> > > > > +    if (xendev->local_port == -1) {
> > > > > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound
> > failed\n");
> > > > > +        return -1;
> > > > > +    }
> > > > > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> > > > xendev->local_port);
> > > > > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > > > > +                        xen_be_evtchn_event, NULL, xendev);
> > > > > +    return 0;
> > > > > +}
> > > > > +
> > > > >  int xen_be_bind_evtchn(struct XenDevice *xendev)  {
> > > > >      if (xendev->local_port != -1) { @@ -770,6 +912,42 @@ int
> > > > > xen_be_send_notify(struct XenDevice
> > > > *xendev)
> > > > >      return xc_evtchn_notify(xendev->evtchndev,
> > > > > xendev->local_port);  }
> > > > >
> > > > > +int xen_vtpm_send(unsigned char *buf, size_t count) {
> > > > > +    struct XenDevice *xendev;
> > > > > +    int rc = -1;
> > > > > +
> > > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > > +    if (xendev == NULL) {
> > > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    if (xendev->ops->send) {
> > > > > +        rc = xendev->ops->send(xendev, buf, count);
> > > > > +    }
> > > > > +
> > > > > +    return rc;
> > > > > +}
> > > > > +
> > > > > +int xen_vtpm_recv(unsigned char *buf, size_t *count) {
> > > > > +    struct XenDevice *xendev;
> > > > > +    int rc = -1;
> > > > > +
> > > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > > +    if (xendev == NULL) {
> > > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    if (xendev->ops->recv) {
> > > > > +        xendev->ops->recv(xendev, buf, count);
> > > > > +    }
> > > > > +
> > > > > +    return rc;
> > > > > +}
> > > >
> > > > xen_backend.c is supposed to be generic, so stubdom functions might
> > > > be OK but vtpm specific functions should not be here.
> > > >
> > > >
> > > > >  /*
> > > > >   * msg_level:
> > > > >   *  0 == errors (stderr + logfile).
> > > > > diff --git a/hw/xen/xen_stubdom_vtpm.c
> > b/hw/xen/xen_stubdom_vtpm.c
> > > > > new file mode 100644 index 0000000..0d740c1
> > > > > --- /dev/null
> > > > > +++ b/hw/xen/xen_stubdom_vtpm.c
> > > > > @@ -0,0 +1,333 @@
> > > > > +/*
> > > > > + * Connect to Xen vTPM stubdom domain
> > > > > + *
> > > > > + *  Copyright (c) 2014 Intel Corporation
> > > > > + *  Authors:
> > > > > + *    Quan Xu <quan.xu@intel.com>
> > > > > + *
> > > > > + * 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 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, see
> > > > <http://www.gnu.org/licenses/>
> > > > > + */
> > > > > +
> > > > > +#include <stdio.h>
> > > > > +#include <stdlib.h>
> > > > > +#include <stdarg.h>
> > > > > +#include <string.h>
> > > > > +#include <unistd.h>
> > > > > +#include <signal.h>
> > > > > +#include <inttypes.h>
> > > > > +#include <time.h>
> > > > > +#include <fcntl.h>
> > > > > +#include <errno.h>
> > > > > +#include <sys/ioctl.h>
> > > > > +#include <sys/types.h>
> > > > > +#include <sys/stat.h>
> > > > > +#include <sys/mman.h>
> > > > > +#include <sys/uio.h>
> > > > > +
> > > > > +#include "hw/hw.h"
> > > > > +#include "block/aio.h"
> > > > > +#include "hw/xen/xen_backend.h"
> > > > > +
> > > > > +enum tpmif_state {
> > > > > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> > > > complete */
> > > > > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > > > > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > > > > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM
> > working */
> > > > > +};
> > > > > +
> > > > > +static AioContext *vtpm_aio_ctx;
> > > > > +
> > > > > +enum status_bits {
> > > > > +    VTPM_STATUS_RUNNING  = 0x1,
> > > > > +    VTPM_STATUS_IDLE     = 0x2,
> > > > > +    VTPM_STATUS_RESULT   = 0x4,
> > > > > +    VTPM_STATUS_CANCELED = 0x8,
> > > > > +};
> > > > > +
> > > > > +struct tpmif_shared_page {
> > > > > +    uint32_t length;         /* request/response length in bytes */
> > > > > +
> > > > > +    uint8_t  state;           /* enum tpmif_state */
> > > > > +    uint8_t  locality;        /* for the current request */
> > > > > +    uint8_t  pad;             /* should be zero */
> > > > > +
> > > > > +    uint8_t  nr_extra_pages;  /* extra pages for long packets;
> > > > > + may be
> > > > zero */
> > > > > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> > > > nr_extra_pages */
> > > > > +};
> > > > > +
> > > > > +struct QEMUBH {
> > > > > +    AioContext *ctx;
> > > > > +    QEMUBHFunc *cb;
> > > > > +    void *opaque;
> > > > > +    QEMUBH *next;
> > > > > +    bool scheduled;
> > > > > +    bool idle;
> > > > > +    bool deleted;
> > > > > +};
> > > > > +
> > > > > +struct XenVtpmDev {
> > > > > +    struct XenDevice xendev;  /* must be first */
> > > > > +    struct           tpmif_shared_page *shr;
> > > > > +    xc_gntshr        *xen_xcs;
> > > > > +    int              ring_ref;
> > > > > +    int              bedomid;
> > > > > +    QEMUBH           *sr_bh;
> > > > > +};
> > > > > +
> > > > > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev) {
> > > > > +    switch (vtpmdev->shr->state) {
> > > > > +    case TPMIF_STATE_IDLE:
> > > > > +    case TPMIF_STATE_FINISH:
> > > > > +        return VTPM_STATUS_IDLE;
> > > > > +    case TPMIF_STATE_SUBMIT:
> > > > > +    case TPMIF_STATE_CANCEL:
> > > > > +        return VTPM_STATUS_RUNNING;
> > > > > +    default:
> > > > > +        return 0;
> > > > > +    }
> > > > > +}
> > > > > +
> > > > > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> > > > xenbus_state xbus)
> > > > > +{
> > > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > > +
> > > > > +    if (xendev->fe_state == xbus) {
> > > > > +        return 0;
> > > > > +    }
> > > > > +
> > > > > +    xendev->fe_state = xbus;
> > > > > +
> > > > > +retry_transaction:
> > > > > +    xbt = xs_transaction_start(xenstore);
> > > > > +    if (xbt == XBT_NULL) {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > > +        if (errno == EAGAIN) {
> > > > > +            goto retry_transaction;
> > > > > +        }
> > > > > +    }
> > > > > +
> > > > > +    return 0;
> > > > > +
> > > > > +abort_transaction:
> > > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > > +    return -1;
> > > > > +}
> > > > > +
> > > > > +static int vtpm_aio_wait(QEMUBH *qbh) {
> > > > > +    return aio_poll(qbh->ctx, true); }
> > > > > +
> > > > > +static void sr_bh_handler(void *opaque) { }
> > > > > +
> > > > > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf,
> > > > > +size_t
> > > > *count)
> > > > > +{
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > > +    unsigned int offset;
> > > > > +
> > > > > +    if (shr->state == TPMIF_STATE_IDLE) {
> > > > > +        return -ECANCELED;
> > > > > +    }
> > > > > +
> > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > +    }
> > > > > +
> > > > > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > > > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > > > > +    *count = shr->length;
> > > > > +
> > > > > +    return 0;
> > > > > +}
> > > > > +
> > > > > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf,
> > > > > +size_t
> > > > count)
> > > > > +{
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > > > +
> > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > +    }
> > > > > +
> > > > > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > > > > +    shr->length = count;
> > > > > +    barrier();
> > > > > +    shr->state = TPMIF_STATE_SUBMIT;
> > > > > +    xen_wmb();
> > > > > +    xen_be_send_notify(&vtpmdev->xendev);
> > > > > +
> > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > +    }
> > > > > +
> > > > > +    return count;
> > > > > +}
> > > > > +
> > > > > +static int vtpm_initialise(struct XenDevice *xendev) {
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > > +    unsigned int ring_ref;
> > > > > +
> > > > > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> > > > "frontend");
> > > > > +    if (vtpmdev->xendev.fe == NULL) {
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    /* Get backend domid */
> > > > > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > > > > +                             &vtpmdev->bedomid)) {
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    /*alloc share page*/
> > > > > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> > > > vtpmdev->bedomid, 1,
> > > > > +                                         &ring_ref,
> > > > PROT_READ|PROT_WRITE);
> > > > > +    vtpmdev->ring_ref = ring_ref;
> > > > > +    if (vtpmdev->shr == NULL) {
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    /*Create event channel */
> > > > > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> > > > vtpmdev->bedomid)) {
> > > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > > +        return -1;
> > > > > +    }
> > > > > +
> > > > > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > > > > +                     vtpmdev->xendev.local_port);
> > > > > +
> > > > > +again:
> > > > > +    xbt = xs_transaction_start(xenstore);
> > > > > +    if (xbt == XBT_NULL) {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > > > > +                           vtpmdev->ring_ref)) {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > > > > +                           vtpmdev->xendev.local_port)) {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    /* Publish protocol v2 feature */
> > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe,
> > > > > + "feature-protocol-v2", 1))
> > > > {
> > > > > +        goto abort_transaction;
> > > > > +    }
> > > > > +
> > > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > > +        if (errno == EAGAIN) {
> > > > > +            goto again;
> > > > > +        }
> > > > > +    }
> > > > > +    /* Tell vtpm backend that we are ready */
> > > > > +    xenbus_switch_state(&vtpmdev->xendev,
> > > > > + XenbusStateInitialised);
> > > > > +
> > > > > +    return 0;
> > > > > +
> > > > > +abort_transaction:
> > > > > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > > +    return -1;
> > > > > +}
> > > > > +
> > > > > +static void vtpm_backend_changed(struct XenDevice *xendev, const
> > > > > +char
> > > > *node)
> > > > > +{
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +    int be_state;
> > > > > +
> > > > > +    if (strcmp(node, "state") == 0) {
> > > > > +        xenstore_read_be_int(&vtpmdev->xendev, node,
> > &be_state);
> > > > > +        switch (be_state) {
> > > > > +        case XenbusStateConnected:
> > > > > +            /*TODO*/
> > > > > +            break;
> > > > > +        case XenbusStateClosing:
> > > > > +        case XenbusStateClosed:
> > > > > +            xenbus_switch_state(&vtpmdev->xendev,
> > > > XenbusStateClosing);
> > > > > +            break;
> > > > > +        default:
> > > > > +            break;
> > > > > +        }
> > > > > +    }
> > > > > +}
> > > > > +
> > > > > +static int vtpm_free(struct XenDevice *xendev) {
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > > > > +
> > > > > +    aio_poll(qbh->ctx, false);
> > > > > +    qemu_bh_delete(vtpmdev->sr_bh);
> > > > > +    if (vtpmdev->shr) {
> > > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > > +    }
> > > > > +    xc_interface_close(vtpmdev->xen_xcs);
> > > > > +    return 0;
> > > > > +}
> > > > > +
> > > > > +static void vtpm_alloc(struct XenDevice *xendev) {
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +
> > > > > +    vtpm_aio_ctx = aio_context_new(NULL);
> > > > > +    if (vtpm_aio_ctx == NULL) {
> > > > > +        return;
> > > > > +    }
> > > > > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> > > > vtpmdev);
> > > > > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > > > > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0); }
> > > > > +
> > > > > +static void vtpm_event(struct XenDevice *xendev) {
> > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > XenVtpmDev,
> > > > > +                                              xendev);
> > > > > +
> > > > > +    qemu_bh_schedule(vtpmdev->sr_bh); }
> > > > > +
> > > > > +struct XenDevOps xen_vtpmdev_ops = {
> > > > > +    .size             = sizeof(struct XenVtpmDev),
> > > > > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > > > > +                        DEVOPS_FLAG_STUBDOM_BE,
> > > > > +    .event            = vtpm_event,
> > > > > +    .free             = vtpm_free,
> > > > > +    .alloc            = vtpm_alloc,
> > > > > +    .initialise       = vtpm_initialise,
> > > > > +    .backend_changed  = vtpm_backend_changed,
> > > > > +    .recv             = vtpm_recv,
> > > > > +    .send             = vtpm_send,
> > > > > +};
> > > >
> > > > Is this the frontend, like the subject line would seem to imply?
> > > > If so, XenDevOps are made for backends, while this is a frontend. In
> > > > fact this is the first PV frontend in QEMU. We need to introduce
> > > > something generic and similar to struct XenDevOps and xen_backend.c
> > > > but for frontends.
> > > >
> > > >
> > > > > diff --git a/include/hw/xen/xen_backend.h
> > > > b/include/hw/xen/xen_backend.h
> > > > > index 3b4125e..45fd6d3 100644
> > > > > --- a/include/hw/xen/xen_backend.h
> > > > > +++ b/include/hw/xen/xen_backend.h
> > > > > @@ -15,6 +15,8 @@ struct XenDevice;
> > > > >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> > > > >  /* don't expect frontend doing correct state transitions (aka
> > > > > console
> > > > quirk) */
> > > > >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > > > > +/*dev backend is stubdom*/
> > > > > +#define DEVOPS_FLAG_STUBDOM_BE    4
> > > > >
> > > > >  struct XenDevOps {
> > > > >      size_t    size;
> > > > > @@ -26,6 +28,8 @@ struct XenDevOps {
> > > > >      void      (*event)(struct XenDevice *xendev);
> > > > >      void      (*disconnect)(struct XenDevice *xendev);
> > > > >      int       (*free)(struct XenDevice *xendev);
> > > > > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> > > > count);
> > > > > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> > > > *count);
> > > > >      void      (*backend_changed)(struct XenDevice *xendev, const
> > > > char *node);
> > > > >      void      (*frontend_changed)(struct XenDevice *xendev, const
> > > > char *node);
> > > > >  };
> > > > > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> > > > *xendev);
> > > > >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const
> > > > > char
> > > > *fmt, ...)
> > > > >      GCC_FMT_ATTR(3, 4);
> > > > >
> > > > > +/*Xen stubdom vtpm*/
> > > > > +int xen_vtpm_register(struct XenDevOps *ops); int
> > > > > +xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > > > remote_dom);
> > > > > +int xen_vtpm_send(unsigned char *buf, size_t count); int
> > > > > +xen_vtpm_recv(unsigned char *buf, size_t *count);
> > > > > +
> > > > >  /* actual backend drivers */
> > > > >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> > > > */
> > > > >  extern struct XenDevOps xen_kbdmouse_ops;     /*
> > xen_framebuffer.c
> > > > */
> > > > >  extern struct XenDevOps xen_framebuffer_ops;  /*
> > xen_framebuffer.c */
> > > > >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> > > > */
> > > > >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> > > > */
> > > > > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> > > > xen_stubdom_vtpm.c*/
> > > > >
> > > > >  void xen_init_display(int domid);
> > > > >
> > > > > diff --git a/include/hw/xen/xen_common.h
> > > > b/include/hw/xen/xen_common.h
> > > > > index 95612a4..fb43084 100644
> > > > > --- a/include/hw/xen/xen_common.h
> > > > > +++ b/include/hw/xen/xen_common.h
> > > > > @@ -130,6 +130,12 @@ static inline XenXC
> > > > > xen_xc_interface_open(void
> > > > *logger, void *dombuild_logger,
> > > > >      return xc_interface_open(logger, dombuild_logger,
> > > > > open_flags);  }
> > > > >
> > > > > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > > > > +                                           unsigned int
> > > > > +open_flags) {
> > > > > +    return xc_gntshr_open(logger, open_flags); }
> > > > > +
> > > > >  /* FIXME There is now way to have the xen fd */  static inline
> > > > > int xc_fd(xc_interface *xen_xc)  { diff --git a/xen-hvm.c
> > > > > b/xen-hvm.c index 21f1cbb..c99ace8 100644
> > > > > --- a/xen-hvm.c
> > > > > +++ b/xen-hvm.c
> > > > > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> > > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > > >      int i, rc;
> > > > >      unsigned long ioreq_pfn;
> > > > >      unsigned long bufioreq_evtchn;
> > > > > +
> > > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > > +    unsigned long stubdom_vtpm = 0; #endif
> > > > > +
> > > > >      XenIOState *state;
> > > > >
> > > > >      state = g_malloc0(sizeof (XenIOState)); @@ -1169,6 +1174,14
> > > > > @@ int xen_hvm_init(ram_addr_t
> > > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > > >          fprintf(stderr, "%s: xen backend core setup failed\n",
> > > > __FUNCTION__);
> > > > >          return -1;
> > > > >      }
> > > > > +
> > > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > > +    xc_get_hvm_param(xen_xc, xen_domid,
> > > > HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > > > > +    if (stubdom_vtpm) {
> > > > > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > > > > +    }
> > > > > +#endif
> > > >
> > > > Given that vtpm is just a PV frontend, can't you just detect whether
> > > > is present on xenstore and initialize it based on that? Like all the
> > > > backend below?
> > >
> > > Also I will explain in my next email.
> > >
> > >
> > > >
> > > >
> > > > >      xen_be_register("console", &xen_console_ops);
> > > > >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> > > > >      xen_be_register("qdisk", &xen_blkdev_ops);
> > > > > --
> > > > > 1.8.3.2
> > > > >
> > >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 19:02:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 19:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm5qX-0005oA-CL; Wed, 05 Nov 2014 19:02:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Xm5qV-0005o5-Nd
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 19:02:19 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	F4/C7-25547-A347A545; Wed, 05 Nov 2014 19:02:18 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415214136!11886601!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14571 invoked from network); 5 Nov 2014 19:02:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 19:02:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5J2CTu001118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 19:02:13 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5J2BDO029625
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Nov 2014 19:02:12 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA5IE0Zl011219; Wed, 5 Nov 2014 18:14:00 GMT
Received: from [10.149.239.112] (/10.149.239.112)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 11:02:10 -0800
Message-ID: <545A7432.7010206@oracle.com>
Date: Wed, 05 Nov 2014 14:02:10 -0500
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20131118 Thunderbird/17.0.11
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
	<1415186405.15317.6.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 2014/11/5 6:24, Paul Durrant wrote:
>> -----Original Message-----
>> From: Ian Campbell
>> Sent: 05 November 2014 11:20
>> To: Paul Durrant
>> Cc: David Vrabel; xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley
>> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
>> __pskb_pull_tail() in guest Tx path
>>
>> On Wed, 2014-11-05 at 11:17 +0000, Paul Durrant wrote:
>>>> -----Original Message-----
>>>> From: Ian Campbell
>>>> Sent: 05 November 2014 11:00
>>>> To: David Vrabel
>>>> Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul
>> Durrant
>>>> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
>>>> __pskb_pull_tail() in guest Tx path
>>>>
>>>> Dropping netdev since this isn't relevant to them, adding Paul
>>>>
>>>> On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
>>>>> - performance: Netback has already grant copied up-to 128 bytes from
>>>>>    the first slot of a packet into the linear area. The first slot
>>>>>    normally contain all the IPv4/IPv6 and TCP/UDP headers.
>>>> Does "normally" include guests other than Linux? I thought Windows in
>>>> particular was prone to splitting the headers into a frag per layer or
>>>> thereabouts?
>>>>
>>> Current upstream Windows PV drivers will put all parsed headers in the
>>> first frag and the rest of the packet in subsequent flags. The parser
>>> currently knows about TCP and UDP over IPv4 or v6, with and without
>>> SNAP encapsulation. It doesn't, for example, know about ARP so the
>>> backend will see only the ethernet header in the first frag.
>> Sounds like that is sufficient to reach the "normally" qualification,
>> thanks.
>>
>> (I wonder what sort of benefit parsing arp would bring...)
>>
> Previous versions of the drivers used to parse ARPs so that copies of outgoing gratuitous ARPs could be cached for replay after migrate. Newer drivers acquire IP address bindings from the Windows IP helper (which is now available in kernel) and synthesize ARPs/IPv6 neighbour solicitations.
I send out fake ARP after migration to deal with it, guess you are 
mentioning here 
http://msdn.microsoft.com/en-us/library/windows/hardware/ff557015(v=vs.85).aspx 
? which is available for kernel later than Vista.

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 19:02:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 19:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm5qX-0005oA-CL; Wed, 05 Nov 2014 19:02:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Xm5qV-0005o5-Nd
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 19:02:19 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	F4/C7-25547-A347A545; Wed, 05 Nov 2014 19:02:18 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415214136!11886601!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14571 invoked from network); 5 Nov 2014 19:02:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 19:02:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5J2CTu001118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 19:02:13 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5J2BDO029625
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Nov 2014 19:02:12 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA5IE0Zl011219; Wed, 5 Nov 2014 18:14:00 GMT
Received: from [10.149.239.112] (/10.149.239.112)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 11:02:10 -0800
Message-ID: <545A7432.7010206@oracle.com>
Date: Wed, 05 Nov 2014 14:02:10 -0500
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20131118 Thunderbird/17.0.11
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
	<1415186405.15317.6.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 2014/11/5 6:24, Paul Durrant wrote:
>> -----Original Message-----
>> From: Ian Campbell
>> Sent: 05 November 2014 11:20
>> To: Paul Durrant
>> Cc: David Vrabel; xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley
>> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
>> __pskb_pull_tail() in guest Tx path
>>
>> On Wed, 2014-11-05 at 11:17 +0000, Paul Durrant wrote:
>>>> -----Original Message-----
>>>> From: Ian Campbell
>>>> Sent: 05 November 2014 11:00
>>>> To: David Vrabel
>>>> Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul
>> Durrant
>>>> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
>>>> __pskb_pull_tail() in guest Tx path
>>>>
>>>> Dropping netdev since this isn't relevant to them, adding Paul
>>>>
>>>> On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
>>>>> - performance: Netback has already grant copied up-to 128 bytes from
>>>>>    the first slot of a packet into the linear area. The first slot
>>>>>    normally contain all the IPv4/IPv6 and TCP/UDP headers.
>>>> Does "normally" include guests other than Linux? I thought Windows in
>>>> particular was prone to splitting the headers into a frag per layer or
>>>> thereabouts?
>>>>
>>> Current upstream Windows PV drivers will put all parsed headers in the
>>> first frag and the rest of the packet in subsequent flags. The parser
>>> currently knows about TCP and UDP over IPv4 or v6, with and without
>>> SNAP encapsulation. It doesn't, for example, know about ARP so the
>>> backend will see only the ethernet header in the first frag.
>> Sounds like that is sufficient to reach the "normally" qualification,
>> thanks.
>>
>> (I wonder what sort of benefit parsing arp would bring...)
>>
> Previous versions of the drivers used to parse ARPs so that copies of outgoing gratuitous ARPs could be cached for replay after migrate. Newer drivers acquire IP address bindings from the Windows IP helper (which is now available in kernel) and synthesize ARPs/IPv6 neighbour solicitations.
I send out fake ARP after migration to deal with it, guess you are 
mentioning here 
http://msdn.microsoft.com/en-us/library/windows/hardware/ff557015(v=vs.85).aspx 
? which is available for kernel later than Vista.

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 19:03:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 19:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm5rG-0005qd-Pa; Wed, 05 Nov 2014 19:03:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm5rF-0005qU-Pf
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 19:03:05 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	A7/A7-24124-9647A545; Wed, 05 Nov 2014 19:03:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415214181!11442059!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27023 invoked from network); 5 Nov 2014 19:03:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 19:03:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,321,1413244800"; d="scan'208";a="189858782"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 14:02:57 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm5r7-0006PI-Ef;
	Wed, 05 Nov 2014 19:02:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm5r6-0002N5-Lf;
	Wed, 05 Nov 2014 19:02:56 +0000
Date: Wed, 5 Nov 2014 19:02:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31385-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31385 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31385/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv             5 xen-boot                    fail pass in 31335
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot            fail pass in 31335
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot       fail in 31335 pass in 31385
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31385
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31385
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31385

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 19:03:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 19:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm5rG-0005qd-Pa; Wed, 05 Nov 2014 19:03:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm5rF-0005qU-Pf
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 19:03:05 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	A7/A7-24124-9647A545; Wed, 05 Nov 2014 19:03:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415214181!11442059!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27023 invoked from network); 5 Nov 2014 19:03:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 19:03:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,321,1413244800"; d="scan'208";a="189858782"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 14:02:57 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm5r7-0006PI-Ef;
	Wed, 05 Nov 2014 19:02:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm5r6-0002N5-Lf;
	Wed, 05 Nov 2014 19:02:56 +0000
Date: Wed, 5 Nov 2014 19:02:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31385-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31385 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31385/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv             5 xen-boot                    fail pass in 31335
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot            fail pass in 31335
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot       fail in 31335 pass in 31385
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31385
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31385
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31385

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 19:26:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 19:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm6DG-0006R0-Q8; Wed, 05 Nov 2014 19:25:50 +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 1Xm6DF-0006Qv-LC
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 19:25:49 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	AB/9F-02698-CB97A545; Wed, 05 Nov 2014 19:25:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415215546!12809240!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32393 invoked from network); 5 Nov 2014 19:25:47 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 19:25:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5JPHFK010326
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 19:25:18 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA5Ib0In021658
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 5 Nov 2014 18:37:05 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5JPA9E012930; Wed, 5 Nov 2014 19:25:10 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 11:25:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 26833111033; Wed,  5 Nov 2014 14:25:09 -0500 (EST)
Date: Wed, 5 Nov 2014 14:25:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Message-ID: <20141105192509.GC18665@laptop.dumpdata.com>
References: <1413252845-23433-1-git-send-email-wency@cn.fujitsu.com>
	<21565.17844.525542.420665@mariner.uk.xensource.com>
	<543DC859.1080207@cn.fujitsu.com>
	<CAFLBxZZ+EpHNkcQ2NYC3vspZg-v7uKQsuKX=hW=0KWJXuvDQvA@mail.gmail.com>
	<54507FFB.6090800@cn.fujitsu.com> <545751B0.4010503@eu.citrix.com>
	<545753CA.9080804@cn.fujitsu.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545753CA.9080804@cn.fujitsu.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 00/17] blktap2 related bugfix patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 06:07:06PM +0800, Wen Congyang wrote:
> On 11/03/2014 05:58 PM, George Dunlap wrote:
> > On 10/29/2014 05:49 AM, Wen Congyang wrote:
> >> On 10/20/2014 10:25 PM, George Dunlap wrote:
> >>> On Wed, Oct 15, 2014 at 2:05 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
> >>>> On 10/14/2014 11:48 PM, Ian Jackson wrote:
> >>>>> Wen Congyang writes ("[PATCH 00/17] blktap2 related bugfix patches"):
> >>>>>> These bugs are found when we implement COLO, or rebase
> >>>>>> COLO to upstream xen. They are independent patches, so
> >>>>>> post them in separate series.
> >>>>> blktap2 is unmaintained AFAICT.
> >>>>>
> >>>>> In the last year there has been only one commit which shows evidence
> >>>>> of someone caring even slightly about tools/blktap2/.  The last
> >>>>> substantial attention was in March 2013.
> >>>>>
> >>>>> (I'm disregarding commits which touch tools/blktap2/ to fix up compile
> >>>>> problems with new compilers, sort out build system and file
> >>>>> rearrangements, etc.)
> >>>>>
> >>>>> The file you are touching in your 01/17 was last edited (by anyone, at
> >>>>> all) in January 2010.
> >>>>>
> >>>>> Under the circumstances, we should probably take all these changes
> >>>>> without looking for anyone to ack them.
> >>>>>
> >>>>> Perhaps you would like to become the maintainers of blktap2 ? :-)
> >>>> Hmm, I don't have any knowledge about disk format, but blktap2 have
> >>>> such codes(For example: block-vhd.c, block-qcow.c...). I think I can
> >>>> maintain the rest codes.
> >>> Congyang, were you aware that XenServer has a fork of blktap is
> >>> actually still under active development and maintainership outside of
> >>> the main Xen tree?
> >>>
> >>> git://github.com/xen-org/blktap.git
> >>>
> >>> Both CentOS and Fedora are actually using snapshots of the "blktap2"
> >>> branch in that tree for their Xen RPMs.  (I'm sure CentOS is, I
> >>> believe Fedora is.)  It's not unlikely that the bugs you're fixing
> >>> here have already been fixed in the XenServer fork.
> >> I have another question:
> >> Why we don't merge the "blktap2' branch into xen upstream periodically?
> > 
> > I take it you've found blktap "2.5" useful? :-)
> > 
> > I've been meaning to write an e-mail about this.
> > 
> > The basic reason is that it's normally up to the people doing the development to submit changes upstream.  Some years ago XenServer forked the blktap2 codebase but got behind in upstreaming things; at this point there are far too many changes to simply push them upstream.  Furthermore, even XenServer isn't 100% sure what they're going to do in the future; as of a year ago they were planning to get rid of blktap entirely in favor of another solution.
> > 
> > One of the ideas I'm going to discuss in my e-mail is the idea of treating blktap2.5 (and/or blktap3) as an external upstream project, similar to the way that we treat qemu, seabios, ipxe, and ovmf. That would have a similar effect to what you describe.
> 
> I agree with this. Currently, we have blktap2 and blktap2.5. I don't know my work should be for which
> version...

The one that has an active maintainer!

I presume 'blktap2.5' fits in that category? But we would need to sync
the checkout of blktap2.5 in the Xen git tree when building - so that is
definite Xen 4.6 material.

> 
> Thanks
> Wen Congyang
> 
> > 
> >  -George
> > .
> > 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 19:26:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 19:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm6DG-0006R0-Q8; Wed, 05 Nov 2014 19:25:50 +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 1Xm6DF-0006Qv-LC
	for xen-devel@lists.xen.org; Wed, 05 Nov 2014 19:25:49 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	AB/9F-02698-CB97A545; Wed, 05 Nov 2014 19:25:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415215546!12809240!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32393 invoked from network); 5 Nov 2014 19:25:47 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 19:25:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5JPHFK010326
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 19:25:18 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA5Ib0In021658
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 5 Nov 2014 18:37:05 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5JPA9E012930; Wed, 5 Nov 2014 19:25:10 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 11:25:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 26833111033; Wed,  5 Nov 2014 14:25:09 -0500 (EST)
Date: Wed, 5 Nov 2014 14:25:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Message-ID: <20141105192509.GC18665@laptop.dumpdata.com>
References: <1413252845-23433-1-git-send-email-wency@cn.fujitsu.com>
	<21565.17844.525542.420665@mariner.uk.xensource.com>
	<543DC859.1080207@cn.fujitsu.com>
	<CAFLBxZZ+EpHNkcQ2NYC3vspZg-v7uKQsuKX=hW=0KWJXuvDQvA@mail.gmail.com>
	<54507FFB.6090800@cn.fujitsu.com> <545751B0.4010503@eu.citrix.com>
	<545753CA.9080804@cn.fujitsu.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545753CA.9080804@cn.fujitsu.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 00/17] blktap2 related bugfix patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 03, 2014 at 06:07:06PM +0800, Wen Congyang wrote:
> On 11/03/2014 05:58 PM, George Dunlap wrote:
> > On 10/29/2014 05:49 AM, Wen Congyang wrote:
> >> On 10/20/2014 10:25 PM, George Dunlap wrote:
> >>> On Wed, Oct 15, 2014 at 2:05 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
> >>>> On 10/14/2014 11:48 PM, Ian Jackson wrote:
> >>>>> Wen Congyang writes ("[PATCH 00/17] blktap2 related bugfix patches"):
> >>>>>> These bugs are found when we implement COLO, or rebase
> >>>>>> COLO to upstream xen. They are independent patches, so
> >>>>>> post them in separate series.
> >>>>> blktap2 is unmaintained AFAICT.
> >>>>>
> >>>>> In the last year there has been only one commit which shows evidence
> >>>>> of someone caring even slightly about tools/blktap2/.  The last
> >>>>> substantial attention was in March 2013.
> >>>>>
> >>>>> (I'm disregarding commits which touch tools/blktap2/ to fix up compile
> >>>>> problems with new compilers, sort out build system and file
> >>>>> rearrangements, etc.)
> >>>>>
> >>>>> The file you are touching in your 01/17 was last edited (by anyone, at
> >>>>> all) in January 2010.
> >>>>>
> >>>>> Under the circumstances, we should probably take all these changes
> >>>>> without looking for anyone to ack them.
> >>>>>
> >>>>> Perhaps you would like to become the maintainers of blktap2 ? :-)
> >>>> Hmm, I don't have any knowledge about disk format, but blktap2 have
> >>>> such codes(For example: block-vhd.c, block-qcow.c...). I think I can
> >>>> maintain the rest codes.
> >>> Congyang, were you aware that XenServer has a fork of blktap is
> >>> actually still under active development and maintainership outside of
> >>> the main Xen tree?
> >>>
> >>> git://github.com/xen-org/blktap.git
> >>>
> >>> Both CentOS and Fedora are actually using snapshots of the "blktap2"
> >>> branch in that tree for their Xen RPMs.  (I'm sure CentOS is, I
> >>> believe Fedora is.)  It's not unlikely that the bugs you're fixing
> >>> here have already been fixed in the XenServer fork.
> >> I have another question:
> >> Why we don't merge the "blktap2' branch into xen upstream periodically?
> > 
> > I take it you've found blktap "2.5" useful? :-)
> > 
> > I've been meaning to write an e-mail about this.
> > 
> > The basic reason is that it's normally up to the people doing the development to submit changes upstream.  Some years ago XenServer forked the blktap2 codebase but got behind in upstreaming things; at this point there are far too many changes to simply push them upstream.  Furthermore, even XenServer isn't 100% sure what they're going to do in the future; as of a year ago they were planning to get rid of blktap entirely in favor of another solution.
> > 
> > One of the ideas I'm going to discuss in my e-mail is the idea of treating blktap2.5 (and/or blktap3) as an external upstream project, similar to the way that we treat qemu, seabios, ipxe, and ovmf. That would have a similar effect to what you describe.
> 
> I agree with this. Currently, we have blktap2 and blktap2.5. I don't know my work should be for which
> version...

The one that has an active maintainer!

I presume 'blktap2.5' fits in that category? But we would need to sync
the checkout of blktap2.5 in the Xen git tree when building - so that is
definite Xen 4.6 material.

> 
> Thanks
> Wen Congyang
> 
> > 
> >  -George
> > .
> > 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 20:13:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 20:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm6xP-0007XL-Op; Wed, 05 Nov 2014 20:13:31 +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 1Xm6xO-0007XG-Jz
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 20:13:30 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	93/78-22737-9E48A545; Wed, 05 Nov 2014 20:13:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415218407!6037678!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4128 invoked from network); 5 Nov 2014 20:13:28 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Nov 2014 20:13:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5KCEEI028401
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 20:12:16 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5KCDd3019339
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 5 Nov 2014 20:12:13 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5KCD7r019327; Wed, 5 Nov 2014 20:12:13 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 12:12:12 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 981B1111087; Wed,  5 Nov 2014 15:12:10 -0500 (EST)
Date: Wed, 5 Nov 2014 15:12:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141105201210.GA20715@laptop.dumpdata.com>
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 01:04:22PM +0000, Julien Grall wrote:
> The vGIC will emulate the same version as the hardware. The toolstack has
> to retrieve the version of the vGIC in order to be able to create the
> corresponding device tree node.
> 
> A new DOMCTL has been introduced for ARM to configure the domain. For now
> it only allow the toolstack to retrieve the version of vGIC.
> This DOMCTL will be extend later to let the user choose the version of the
> emulated GIC.
> 
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Wei Liu <wei.liu2@citrix.com>
> 
> ---
> Stefano, I made one change in the guest memory layout, so I've dropped you
> Reviewed-by.
> 
>     Changes in v3:
>         - Typo and update some comments
>         - Coding style
>         - Only reserve space for an 8 VCPUs redistributor in the guest
>         memory layout
> 
>     Changes in v2:
>         - Use memcpu in xc_domain_configure
>         - Rename the DOMCTL into domctl_arm_configuredomain
>         - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>         and fold the code in arch_domain_init_hw_description
>         - Return -EOPNOTSUPP when the value of gic_version is not
>         supported
> 
> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> defer the initialization of the vGIC [2].
> 
> Xen 4.5 has already support for the hardware GICv3. While it's possible to
> boot and use DOM0, there is no guest support. The first version of this patch
> has been sent a couple of months ago, but has never reached unstable for
> various reasons (based on deferred series, lake of review at that time...).
> Without it, platform with GICv3 support won't be able to boot any guest.
> 
> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
> 
> Features such as adding a new config option to let the user choose the GIC
> version are deferred to Xen 4.6.
> 
> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> [2] https://patches.linaro.org/34664/
> ---
>  tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>  tools/libxc/include/xenctrl.h                |    6 ++
>  tools/libxc/xc_domain.c                      |   20 ++++++
>  tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
>  xen/arch/arm/domctl.c                        |   35 ++++++++++
>  xen/arch/arm/gic-v3.c                        |   16 ++++-
>  xen/include/public/arch-arm.h                |   16 +++++
>  xen/include/public/domctl.h                  |   17 +++++
>  xen/xsm/flask/hooks.c                        |    3 +
>  xen/xsm/flask/policy/access_vectors          |    2 +
>  10 files changed, 204 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> index 641c797..fa69c9d 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>  			getdomaininfo hypercall setvcpucontext setextvcpucontext
>  			getscheduler getvcpuinfo getvcpuextstate getaddrsize
>  			getaffinity setaffinity };
> -	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>  	allow $1 $2:security check_context;
>  	allow $1 $2:shadow enable;
>  	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 564e187..45e282c 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>                       uint32_t flags,
>                       uint32_t *pdomid);
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> +
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config);
> +#endif
>  
>  /* Functions to produce a dump of a given domain
>   *  xc_domain_dumpcore - produces a dump to a specified file
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index a9bcd4a..b071dea 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>      return 0;
>  }
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config)
> +{
> +    int rc;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> +    domctl.domain = (domid_t)domid;
> +    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));

Why the memcpy? Why not the bounce framework? (xc_hypercall_bounce_post, etc)?

> +
> +    rc = do_domctl(xch, &domctl);
> +    if ( !rc )
> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> +
> +    return rc;
> +}
> +#endif
> +

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 20:13:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 20:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm6xP-0007XL-Op; Wed, 05 Nov 2014 20:13:31 +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 1Xm6xO-0007XG-Jz
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 20:13:30 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	93/78-22737-9E48A545; Wed, 05 Nov 2014 20:13:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415218407!6037678!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4128 invoked from network); 5 Nov 2014 20:13:28 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Nov 2014 20:13:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA5KCEEI028401
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Nov 2014 20:12:16 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5KCDd3019339
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 5 Nov 2014 20:12:13 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA5KCD7r019327; Wed, 5 Nov 2014 20:12:13 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 12:12:12 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 981B1111087; Wed,  5 Nov 2014 15:12:10 -0500 (EST)
Date: Wed, 5 Nov 2014 15:12:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141105201210.GA20715@laptop.dumpdata.com>
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 01:04:22PM +0000, Julien Grall wrote:
> The vGIC will emulate the same version as the hardware. The toolstack has
> to retrieve the version of the vGIC in order to be able to create the
> corresponding device tree node.
> 
> A new DOMCTL has been introduced for ARM to configure the domain. For now
> it only allow the toolstack to retrieve the version of vGIC.
> This DOMCTL will be extend later to let the user choose the version of the
> emulated GIC.
> 
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Wei Liu <wei.liu2@citrix.com>
> 
> ---
> Stefano, I made one change in the guest memory layout, so I've dropped you
> Reviewed-by.
> 
>     Changes in v3:
>         - Typo and update some comments
>         - Coding style
>         - Only reserve space for an 8 VCPUs redistributor in the guest
>         memory layout
> 
>     Changes in v2:
>         - Use memcpu in xc_domain_configure
>         - Rename the DOMCTL into domctl_arm_configuredomain
>         - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>         and fold the code in arch_domain_init_hw_description
>         - Return -EOPNOTSUPP when the value of gic_version is not
>         supported
> 
> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> defer the initialization of the vGIC [2].
> 
> Xen 4.5 has already support for the hardware GICv3. While it's possible to
> boot and use DOM0, there is no guest support. The first version of this patch
> has been sent a couple of months ago, but has never reached unstable for
> various reasons (based on deferred series, lake of review at that time...).
> Without it, platform with GICv3 support won't be able to boot any guest.
> 
> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
> 
> Features such as adding a new config option to let the user choose the GIC
> version are deferred to Xen 4.6.
> 
> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> [2] https://patches.linaro.org/34664/
> ---
>  tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>  tools/libxc/include/xenctrl.h                |    6 ++
>  tools/libxc/xc_domain.c                      |   20 ++++++
>  tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
>  xen/arch/arm/domctl.c                        |   35 ++++++++++
>  xen/arch/arm/gic-v3.c                        |   16 ++++-
>  xen/include/public/arch-arm.h                |   16 +++++
>  xen/include/public/domctl.h                  |   17 +++++
>  xen/xsm/flask/hooks.c                        |    3 +
>  xen/xsm/flask/policy/access_vectors          |    2 +
>  10 files changed, 204 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> index 641c797..fa69c9d 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>  			getdomaininfo hypercall setvcpucontext setextvcpucontext
>  			getscheduler getvcpuinfo getvcpuextstate getaddrsize
>  			getaffinity setaffinity };
> -	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>  	allow $1 $2:security check_context;
>  	allow $1 $2:shadow enable;
>  	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 564e187..45e282c 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>                       uint32_t flags,
>                       uint32_t *pdomid);
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> +
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config);
> +#endif
>  
>  /* Functions to produce a dump of a given domain
>   *  xc_domain_dumpcore - produces a dump to a specified file
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index a9bcd4a..b071dea 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>      return 0;
>  }
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config)
> +{
> +    int rc;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> +    domctl.domain = (domid_t)domid;
> +    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));

Why the memcpy? Why not the bounce framework? (xc_hypercall_bounce_post, etc)?

> +
> +    rc = do_domctl(xch, &domctl);
> +    if ( !rc )
> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> +
> +    return rc;
> +}
> +#endif
> +

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 21:12:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 21:12:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm7sP-0000Ls-LS; Wed, 05 Nov 2014 21:12:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm7sO-0000Ln-Fr
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 21:12:24 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	B6/A0-24859-7B29A545; Wed, 05 Nov 2014 21:12:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415221942!11943243!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27687 invoked from network); 5 Nov 2014 21:12:22 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 21:12:22 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so1913755wgg.19
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 13:12:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=t51kBvyzYR97PcUHElqYSm/IXtSP4rZr64j2pYkDesE=;
	b=m/YKh92KBlq6DwZzDG9P90djRRhGMn5EIM/R775GD0qRtgzbv//PpbOg54Nt/X91qE
	WyyWlH6cTQ0R98vPb2Lg2iBFtE2y7UFv8iZWrBqC+gTxmV7foRFMTKQp0yr2cP69UT2R
	QDeCVhMxsa1DXUqsSzBwgXKMqJ3dLy7HAEih3CWich/D9le3NoJFLDzExrIN69yI1869
	0uvFONm5GxbTKT01e3C7I+KIALLNUQSDhvo1LbK1Jb/c4osoNIX3WnpID7P6Nkekmx79
	iRSjJGtmBiQgOMthmPOhTpVkXzuhs42rxwUL1Q6ymXruO5rECIBrCeiAfxdtT/Oc9vGH
	SLAg==
X-Gm-Message-State: ALoCoQkDUz9mdeJeBwiBWbwKJspOlYlaz/tb64PuAUSOO8w9AfCCq/REaBvHDN392wgpQhMm/aea
X-Received: by 10.194.172.131 with SMTP id bc3mr46264399wjc.64.1415221942025; 
	Wed, 05 Nov 2014 13:12:22 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id
	ko10sm5369863wjb.48.2014.11.05.13.12.20 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 05 Nov 2014 13:12:21 -0800 (PST)
Message-ID: <545A92B3.3000001@linaro.org>
Date: Wed, 05 Nov 2014 21:12:19 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
	<20141105201210.GA20715@laptop.dumpdata.com>
In-Reply-To: <20141105201210.GA20715@laptop.dumpdata.com>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Konrad,

On 05/11/2014 20:12, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 05, 2014 at 01:04:22PM +0000, Julien Grall wrote:
>> The vGIC will emulate the same version as the hardware. The toolstack has
>> to retrieve the version of the vGIC in order to be able to create the
>> corresponding device tree node.
>>
>> A new DOMCTL has been introduced for ARM to configure the domain. For now
>> it only allow the toolstack to retrieve the version of vGIC.
>> This DOMCTL will be extend later to let the user choose the version of the
>> emulated GIC.
>>
>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Jan Beulich <jbeulich@suse.com>
>> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Cc: Wei Liu <wei.liu2@citrix.com>
>>
>> ---
>> Stefano, I made one change in the guest memory layout, so I've dropped you
>> Reviewed-by.
>>
>>      Changes in v3:
>>          - Typo and update some comments
>>          - Coding style
>>          - Only reserve space for an 8 VCPUs redistributor in the guest
>>          memory layout
>>
>>      Changes in v2:
>>          - Use memcpu in xc_domain_configure
>>          - Rename the DOMCTL into domctl_arm_configuredomain
>>          - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>>          and fold the code in arch_domain_init_hw_description
>>          - Return -EOPNOTSUPP when the value of gic_version is not
>>          supported
>>
>> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
>> defer the initialization of the vGIC [2].
>>
>> Xen 4.5 has already support for the hardware GICv3. While it's possible to
>> boot and use DOM0, there is no guest support. The first version of this patch
>> has been sent a couple of months ago, but has never reached unstable for
>> various reasons (based on deferred series, lake of review at that time...).
>> Without it, platform with GICv3 support won't be able to boot any guest.
>>
>> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
>> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
>>
>> Features such as adding a new config option to let the user choose the GIC
>> version are deferred to Xen 4.6.
>>
>> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
>>
>> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
>> [2] https://patches.linaro.org/34664/
>> ---
>>   tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>>   tools/libxc/include/xenctrl.h                |    6 ++
>>   tools/libxc/xc_domain.c                      |   20 ++++++
>>   tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
>>   xen/arch/arm/domctl.c                        |   35 ++++++++++
>>   xen/arch/arm/gic-v3.c                        |   16 ++++-
>>   xen/include/public/arch-arm.h                |   16 +++++
>>   xen/include/public/domctl.h                  |   17 +++++
>>   xen/xsm/flask/hooks.c                        |    3 +
>>   xen/xsm/flask/policy/access_vectors          |    2 +
>>   10 files changed, 204 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
>> index 641c797..fa69c9d 100644
>> --- a/tools/flask/policy/policy/modules/xen/xen.if
>> +++ b/tools/flask/policy/policy/modules/xen/xen.if
>> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>>   			getdomaininfo hypercall setvcpucontext setextvcpucontext
>>   			getscheduler getvcpuinfo getvcpuextstate getaddrsize
>>   			getaffinity setaffinity };
>> -	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
>> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>>   	allow $1 $2:security check_context;
>>   	allow $1 $2:shadow enable;
>>   	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 564e187..45e282c 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>>                        uint32_t flags,
>>                        uint32_t *pdomid);
>>
>> +#if defined(__arm__) || defined(__aarch64__)
>> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
>> +
>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>> +                        xc_domain_configuration_t *config);
>> +#endif
>>
>>   /* Functions to produce a dump of a given domain
>>    *  xc_domain_dumpcore - produces a dump to a specified file
>> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
>> index a9bcd4a..b071dea 100644
>> --- a/tools/libxc/xc_domain.c
>> +++ b/tools/libxc/xc_domain.c
>> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>>       return 0;
>>   }
>>
>> +#if defined(__arm__) || defined(__aarch64__)
>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>> +                        xc_domain_configuration_t *config)
>> +{
>> +    int rc;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
>> +    domctl.domain = (domid_t)domid;
>> +    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
>> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
>
> Why the memcpy? Why not the bounce framework? (xc_hypercall_bounce_post, etc)?

Because AFAIK xc_hypercall_bounce_* is used in coordination with 
GUEST_HANDLE.

In this case, we don't have a guest handle and the job is already done 
in do_domctl.

Also, it's not possible to copy a part of the structure. It would 
require to unroll the memcpy by assigning one by one every field.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 21:12:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 21:12:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm7sP-0000Ls-LS; Wed, 05 Nov 2014 21:12:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xm7sO-0000Ln-Fr
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 21:12:24 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	B6/A0-24859-7B29A545; Wed, 05 Nov 2014 21:12:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415221942!11943243!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27687 invoked from network); 5 Nov 2014 21:12:22 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 21:12:22 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so1913755wgg.19
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 13:12:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=t51kBvyzYR97PcUHElqYSm/IXtSP4rZr64j2pYkDesE=;
	b=m/YKh92KBlq6DwZzDG9P90djRRhGMn5EIM/R775GD0qRtgzbv//PpbOg54Nt/X91qE
	WyyWlH6cTQ0R98vPb2Lg2iBFtE2y7UFv8iZWrBqC+gTxmV7foRFMTKQp0yr2cP69UT2R
	QDeCVhMxsa1DXUqsSzBwgXKMqJ3dLy7HAEih3CWich/D9le3NoJFLDzExrIN69yI1869
	0uvFONm5GxbTKT01e3C7I+KIALLNUQSDhvo1LbK1Jb/c4osoNIX3WnpID7P6Nkekmx79
	iRSjJGtmBiQgOMthmPOhTpVkXzuhs42rxwUL1Q6ymXruO5rECIBrCeiAfxdtT/Oc9vGH
	SLAg==
X-Gm-Message-State: ALoCoQkDUz9mdeJeBwiBWbwKJspOlYlaz/tb64PuAUSOO8w9AfCCq/REaBvHDN392wgpQhMm/aea
X-Received: by 10.194.172.131 with SMTP id bc3mr46264399wjc.64.1415221942025; 
	Wed, 05 Nov 2014 13:12:22 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id
	ko10sm5369863wjb.48.2014.11.05.13.12.20 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 05 Nov 2014 13:12:21 -0800 (PST)
Message-ID: <545A92B3.3000001@linaro.org>
Date: Wed, 05 Nov 2014 21:12:19 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
	<20141105201210.GA20715@laptop.dumpdata.com>
In-Reply-To: <20141105201210.GA20715@laptop.dumpdata.com>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Konrad,

On 05/11/2014 20:12, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 05, 2014 at 01:04:22PM +0000, Julien Grall wrote:
>> The vGIC will emulate the same version as the hardware. The toolstack has
>> to retrieve the version of the vGIC in order to be able to create the
>> corresponding device tree node.
>>
>> A new DOMCTL has been introduced for ARM to configure the domain. For now
>> it only allow the toolstack to retrieve the version of vGIC.
>> This DOMCTL will be extend later to let the user choose the version of the
>> emulated GIC.
>>
>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Jan Beulich <jbeulich@suse.com>
>> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Cc: Wei Liu <wei.liu2@citrix.com>
>>
>> ---
>> Stefano, I made one change in the guest memory layout, so I've dropped you
>> Reviewed-by.
>>
>>      Changes in v3:
>>          - Typo and update some comments
>>          - Coding style
>>          - Only reserve space for an 8 VCPUs redistributor in the guest
>>          memory layout
>>
>>      Changes in v2:
>>          - Use memcpu in xc_domain_configure
>>          - Rename the DOMCTL into domctl_arm_configuredomain
>>          - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>>          and fold the code in arch_domain_init_hw_description
>>          - Return -EOPNOTSUPP when the value of gic_version is not
>>          supported
>>
>> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
>> defer the initialization of the vGIC [2].
>>
>> Xen 4.5 has already support for the hardware GICv3. While it's possible to
>> boot and use DOM0, there is no guest support. The first version of this patch
>> has been sent a couple of months ago, but has never reached unstable for
>> various reasons (based on deferred series, lake of review at that time...).
>> Without it, platform with GICv3 support won't be able to boot any guest.
>>
>> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
>> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
>>
>> Features such as adding a new config option to let the user choose the GIC
>> version are deferred to Xen 4.6.
>>
>> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
>>
>> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
>> [2] https://patches.linaro.org/34664/
>> ---
>>   tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>>   tools/libxc/include/xenctrl.h                |    6 ++
>>   tools/libxc/xc_domain.c                      |   20 ++++++
>>   tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
>>   xen/arch/arm/domctl.c                        |   35 ++++++++++
>>   xen/arch/arm/gic-v3.c                        |   16 ++++-
>>   xen/include/public/arch-arm.h                |   16 +++++
>>   xen/include/public/domctl.h                  |   17 +++++
>>   xen/xsm/flask/hooks.c                        |    3 +
>>   xen/xsm/flask/policy/access_vectors          |    2 +
>>   10 files changed, 204 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
>> index 641c797..fa69c9d 100644
>> --- a/tools/flask/policy/policy/modules/xen/xen.if
>> +++ b/tools/flask/policy/policy/modules/xen/xen.if
>> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>>   			getdomaininfo hypercall setvcpucontext setextvcpucontext
>>   			getscheduler getvcpuinfo getvcpuextstate getaddrsize
>>   			getaffinity setaffinity };
>> -	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
>> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>>   	allow $1 $2:security check_context;
>>   	allow $1 $2:shadow enable;
>>   	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 564e187..45e282c 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>>                        uint32_t flags,
>>                        uint32_t *pdomid);
>>
>> +#if defined(__arm__) || defined(__aarch64__)
>> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
>> +
>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>> +                        xc_domain_configuration_t *config);
>> +#endif
>>
>>   /* Functions to produce a dump of a given domain
>>    *  xc_domain_dumpcore - produces a dump to a specified file
>> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
>> index a9bcd4a..b071dea 100644
>> --- a/tools/libxc/xc_domain.c
>> +++ b/tools/libxc/xc_domain.c
>> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>>       return 0;
>>   }
>>
>> +#if defined(__arm__) || defined(__aarch64__)
>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>> +                        xc_domain_configuration_t *config)
>> +{
>> +    int rc;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
>> +    domctl.domain = (domid_t)domid;
>> +    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
>> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
>
> Why the memcpy? Why not the bounce framework? (xc_hypercall_bounce_post, etc)?

Because AFAIK xc_hypercall_bounce_* is used in coordination with 
GUEST_HANDLE.

In this case, we don't have a guest handle and the job is already done 
in do_domctl.

Also, it's not possible to copy a part of the structure. It would 
require to unroll the memcpy by assigning one by one every field.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 21:45:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 21:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm8OW-0000wF-Eu; Wed, 05 Nov 2014 21:45:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1Xm8OV-0000vz-0c
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 21:45:35 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CD/18-09936-E7A9A545; Wed, 05 Nov 2014 21:45:34 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415223933!13006067!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10903 invoked from network); 5 Nov 2014 21:45:33 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 21:45:33 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-23-29-105.brhm.adsl.virginm.net ([86.23.29.105]:50213
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1Xm8OO-0005Y8-D9 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Wed, 05 Nov 2014 21:45:30 +0000
Message-ID: <545A9A71.2000808@citrix.com>
Date: Wed, 05 Nov 2014 21:45:21 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Julien Grall <julien.grall@linaro.org>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>	<20141105201210.GA20715@laptop.dumpdata.com>
	<545A92B3.3000001@linaro.org>
In-Reply-To: <545A92B3.3000001@linaro.org>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/11/2014 21:12, Julien Grall wrote:
> Hi Konrad,
>
> On 05/11/2014 20:12, Konrad Rzeszutek Wilk wrote:
>> On Wed, Nov 05, 2014 at 01:04:22PM +0000, Julien Grall wrote:
>>> The vGIC will emulate the same version as the hardware. The
>>> toolstack has
>>> to retrieve the version of the vGIC in order to be able to create the
>>> corresponding device tree node.
>>>
>>> A new DOMCTL has been introduced for ARM to configure the domain.
>>> For now
>>> it only allow the toolstack to retrieve the version of vGIC.
>>> This DOMCTL will be extend later to let the user choose the version
>>> of the
>>> emulated GIC.
>>>
>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>> Cc: Jan Beulich <jbeulich@suse.com>
>>> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>
>>> ---
>>> Stefano, I made one change in the guest memory layout, so I've
>>> dropped you
>>> Reviewed-by.
>>>
>>>      Changes in v3:
>>>          - Typo and update some comments
>>>          - Coding style
>>>          - Only reserve space for an 8 VCPUs redistributor in the guest
>>>          memory layout
>>>
>>>      Changes in v2:
>>>          - Use memcpu in xc_domain_configure
>>>          - Rename the DOMCTL into domctl_arm_configuredomain
>>>          - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>>>          and fold the code in arch_domain_init_hw_description
>>>          - Return -EOPNOTSUPP when the value of gic_version is not
>>>          supported
>>>
>>> This patch is based on Vijay's GICv3 guest support patch [1] and my
>>> patch to
>>> defer the initialization of the vGIC [2].
>>>
>>> Xen 4.5 has already support for the hardware GICv3. While it's
>>> possible to
>>> boot and use DOM0, there is no guest support. The first version of
>>> this patch
>>> has been sent a couple of months ago, but has never reached unstable
>>> for
>>> various reasons (based on deferred series, lake of review at that
>>> time...).
>>> Without it, platform with GICv3 support won't be able to boot any
>>> guest.
>>>
>>> The patch has been reworked to make it acceptable for Xen 4.5.
>>> Except the new
>>> DOMCTL to retrieve the GIC version and one check. The code is purely
>>> GICv3.
>>>
>>> Features such as adding a new config option to let the user choose
>>> the GIC
>>> version are deferred to Xen 4.6.
>>>
>>> It has been tested on both GICv2/GICv3 platform. And build tested
>>> for x86.
>>>
>>> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
>>> [2] https://patches.linaro.org/34664/
>>> ---
>>>   tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>>>   tools/libxc/include/xenctrl.h                |    6 ++
>>>   tools/libxc/xc_domain.c                      |   20 ++++++
>>>   tools/libxl/libxl_arm.c                      |   95
>>> ++++++++++++++++++++++++--
>>>   xen/arch/arm/domctl.c                        |   35 ++++++++++
>>>   xen/arch/arm/gic-v3.c                        |   16 ++++-
>>>   xen/include/public/arch-arm.h                |   16 +++++
>>>   xen/include/public/domctl.h                  |   17 +++++
>>>   xen/xsm/flask/hooks.c                        |    3 +
>>>   xen/xsm/flask/policy/access_vectors          |    2 +
>>>   10 files changed, 204 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/tools/flask/policy/policy/modules/xen/xen.if
>>> b/tools/flask/policy/policy/modules/xen/xen.if
>>> index 641c797..fa69c9d 100644
>>> --- a/tools/flask/policy/policy/modules/xen/xen.if
>>> +++ b/tools/flask/policy/policy/modules/xen/xen.if
>>> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>>>               getdomaininfo hypercall setvcpucontext setextvcpucontext
>>>               getscheduler getvcpuinfo getvcpuextstate getaddrsize
>>>               getaffinity setaffinity };
>>> -    allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
>>> set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
>>> +    allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
>>> set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op
>>> configure_domain };
>>>       allow $1 $2:security check_context;
>>>       allow $1 $2:shadow enable;
>>>       allow $1 $2:mmu { map_read map_write adjust memorymap physmap
>>> pinpage mmuext_op };
>>> diff --git a/tools/libxc/include/xenctrl.h
>>> b/tools/libxc/include/xenctrl.h
>>> index 564e187..45e282c 100644
>>> --- a/tools/libxc/include/xenctrl.h
>>> +++ b/tools/libxc/include/xenctrl.h
>>> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>>>                        uint32_t flags,
>>>                        uint32_t *pdomid);
>>>
>>> +#if defined(__arm__) || defined(__aarch64__)
>>> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
>>> +
>>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>>> +                        xc_domain_configuration_t *config);
>>> +#endif
>>>
>>>   /* Functions to produce a dump of a given domain
>>>    *  xc_domain_dumpcore - produces a dump to a specified file
>>> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
>>> index a9bcd4a..b071dea 100644
>>> --- a/tools/libxc/xc_domain.c
>>> +++ b/tools/libxc/xc_domain.c
>>> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>>>       return 0;
>>>   }
>>>
>>> +#if defined(__arm__) || defined(__aarch64__)
>>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>>> +                        xc_domain_configuration_t *config)
>>> +{
>>> +    int rc;
>>> +    DECLARE_DOMCTL;
>>> +
>>> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
>>> +    domctl.domain = (domid_t)domid;
>>> +    /* xc_domain_configure_t is an alias of
>>> xen_domctl_arm_configuredomain */
>>> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
>>
>> Why the memcpy? Why not the bounce framework?
>> (xc_hypercall_bounce_post, etc)?
>
> Because AFAIK xc_hypercall_bounce_* is used in coordination with
> GUEST_HANDLE.
>
> In this case, we don't have a guest handle and the job is already done
> in do_domctl.
>
> Also, it's not possible to copy a part of the structure. It would
> require to unroll the memcpy by assigning one by one every field.
>
> Regards,
>

Any parameter to a hypercall which is a pointer must have the pointed-at
memory inside a bounce buffer, to avoid interaction issues with CoW/THP etc.

In this case, the memcpy is moving a structure into the struct domctl
union, and do_domctl() takes care of correctly bouncing struct domctl. 
Therefore, the memcpy() is correct as-is.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 21:45:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 21:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm8OW-0000wF-Eu; Wed, 05 Nov 2014 21:45:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1Xm8OV-0000vz-0c
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 21:45:35 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CD/18-09936-E7A9A545; Wed, 05 Nov 2014 21:45:34 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415223933!13006067!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10903 invoked from network); 5 Nov 2014 21:45:33 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Nov 2014 21:45:33 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-23-29-105.brhm.adsl.virginm.net ([86.23.29.105]:50213
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1Xm8OO-0005Y8-D9 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Wed, 05 Nov 2014 21:45:30 +0000
Message-ID: <545A9A71.2000808@citrix.com>
Date: Wed, 05 Nov 2014 21:45:21 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Julien Grall <julien.grall@linaro.org>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>	<20141105201210.GA20715@laptop.dumpdata.com>
	<545A92B3.3000001@linaro.org>
In-Reply-To: <545A92B3.3000001@linaro.org>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/11/2014 21:12, Julien Grall wrote:
> Hi Konrad,
>
> On 05/11/2014 20:12, Konrad Rzeszutek Wilk wrote:
>> On Wed, Nov 05, 2014 at 01:04:22PM +0000, Julien Grall wrote:
>>> The vGIC will emulate the same version as the hardware. The
>>> toolstack has
>>> to retrieve the version of the vGIC in order to be able to create the
>>> corresponding device tree node.
>>>
>>> A new DOMCTL has been introduced for ARM to configure the domain.
>>> For now
>>> it only allow the toolstack to retrieve the version of vGIC.
>>> This DOMCTL will be extend later to let the user choose the version
>>> of the
>>> emulated GIC.
>>>
>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>> Cc: Jan Beulich <jbeulich@suse.com>
>>> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>
>>> ---
>>> Stefano, I made one change in the guest memory layout, so I've
>>> dropped you
>>> Reviewed-by.
>>>
>>>      Changes in v3:
>>>          - Typo and update some comments
>>>          - Coding style
>>>          - Only reserve space for an 8 VCPUs redistributor in the guest
>>>          memory layout
>>>
>>>      Changes in v2:
>>>          - Use memcpu in xc_domain_configure
>>>          - Rename the DOMCTL into domctl_arm_configuredomain
>>>          - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>>>          and fold the code in arch_domain_init_hw_description
>>>          - Return -EOPNOTSUPP when the value of gic_version is not
>>>          supported
>>>
>>> This patch is based on Vijay's GICv3 guest support patch [1] and my
>>> patch to
>>> defer the initialization of the vGIC [2].
>>>
>>> Xen 4.5 has already support for the hardware GICv3. While it's
>>> possible to
>>> boot and use DOM0, there is no guest support. The first version of
>>> this patch
>>> has been sent a couple of months ago, but has never reached unstable
>>> for
>>> various reasons (based on deferred series, lake of review at that
>>> time...).
>>> Without it, platform with GICv3 support won't be able to boot any
>>> guest.
>>>
>>> The patch has been reworked to make it acceptable for Xen 4.5.
>>> Except the new
>>> DOMCTL to retrieve the GIC version and one check. The code is purely
>>> GICv3.
>>>
>>> Features such as adding a new config option to let the user choose
>>> the GIC
>>> version are deferred to Xen 4.6.
>>>
>>> It has been tested on both GICv2/GICv3 platform. And build tested
>>> for x86.
>>>
>>> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
>>> [2] https://patches.linaro.org/34664/
>>> ---
>>>   tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>>>   tools/libxc/include/xenctrl.h                |    6 ++
>>>   tools/libxc/xc_domain.c                      |   20 ++++++
>>>   tools/libxl/libxl_arm.c                      |   95
>>> ++++++++++++++++++++++++--
>>>   xen/arch/arm/domctl.c                        |   35 ++++++++++
>>>   xen/arch/arm/gic-v3.c                        |   16 ++++-
>>>   xen/include/public/arch-arm.h                |   16 +++++
>>>   xen/include/public/domctl.h                  |   17 +++++
>>>   xen/xsm/flask/hooks.c                        |    3 +
>>>   xen/xsm/flask/policy/access_vectors          |    2 +
>>>   10 files changed, 204 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/tools/flask/policy/policy/modules/xen/xen.if
>>> b/tools/flask/policy/policy/modules/xen/xen.if
>>> index 641c797..fa69c9d 100644
>>> --- a/tools/flask/policy/policy/modules/xen/xen.if
>>> +++ b/tools/flask/policy/policy/modules/xen/xen.if
>>> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>>>               getdomaininfo hypercall setvcpucontext setextvcpucontext
>>>               getscheduler getvcpuinfo getvcpuextstate getaddrsize
>>>               getaffinity setaffinity };
>>> -    allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
>>> set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
>>> +    allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
>>> set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op
>>> configure_domain };
>>>       allow $1 $2:security check_context;
>>>       allow $1 $2:shadow enable;
>>>       allow $1 $2:mmu { map_read map_write adjust memorymap physmap
>>> pinpage mmuext_op };
>>> diff --git a/tools/libxc/include/xenctrl.h
>>> b/tools/libxc/include/xenctrl.h
>>> index 564e187..45e282c 100644
>>> --- a/tools/libxc/include/xenctrl.h
>>> +++ b/tools/libxc/include/xenctrl.h
>>> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>>>                        uint32_t flags,
>>>                        uint32_t *pdomid);
>>>
>>> +#if defined(__arm__) || defined(__aarch64__)
>>> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
>>> +
>>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>>> +                        xc_domain_configuration_t *config);
>>> +#endif
>>>
>>>   /* Functions to produce a dump of a given domain
>>>    *  xc_domain_dumpcore - produces a dump to a specified file
>>> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
>>> index a9bcd4a..b071dea 100644
>>> --- a/tools/libxc/xc_domain.c
>>> +++ b/tools/libxc/xc_domain.c
>>> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>>>       return 0;
>>>   }
>>>
>>> +#if defined(__arm__) || defined(__aarch64__)
>>> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
>>> +                        xc_domain_configuration_t *config)
>>> +{
>>> +    int rc;
>>> +    DECLARE_DOMCTL;
>>> +
>>> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
>>> +    domctl.domain = (domid_t)domid;
>>> +    /* xc_domain_configure_t is an alias of
>>> xen_domctl_arm_configuredomain */
>>> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
>>
>> Why the memcpy? Why not the bounce framework?
>> (xc_hypercall_bounce_post, etc)?
>
> Because AFAIK xc_hypercall_bounce_* is used in coordination with
> GUEST_HANDLE.
>
> In this case, we don't have a guest handle and the job is already done
> in do_domctl.
>
> Also, it's not possible to copy a part of the structure. It would
> require to unroll the memcpy by assigning one by one every field.
>
> Regards,
>

Any parameter to a hypercall which is a pointer must have the pointed-at
memory inside a bounce buffer, to avoid interaction issues with CoW/THP etc.

In this case, the memcpy is moving a structure into the struct domctl
union, and do_domctl() takes care of correctly bouncing struct domctl. 
Therefore, the memcpy() is correct as-is.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 23:04:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 23:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm9by-0002n6-FW; Wed, 05 Nov 2014 23:03:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm9bw-0002n1-J3
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 23:03:32 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	70/1B-02954-3CCAA545; Wed, 05 Nov 2014 23:03:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415228609!12835776!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18476 invoked from network); 5 Nov 2014 23:03:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 23:03:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,322,1413244800"; d="scan'208";a="188556107"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 18:03:28 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm9br-0007a0-CA;
	Wed, 05 Nov 2014 23:03:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm9br-00086U-2o;
	Wed, 05 Nov 2014 23:03:27 +0000
Date: Wed, 5 Nov 2014 23:03:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31387-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31387: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31387 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31387/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops             3 host-install(3)         broken REGR. vs. 31358

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31358

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass

version targeted for testing:
 xen                  5c8dd034f083dbc0cca2ba375a754978f8e25332
baseline version:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  David Scott <dave.scott@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Martin Pohlack <mpohlack@amazon.de>
  Razvan Cojocaru <rcojocaru@bitdefender.com>
  Rob Hoes <rob.hoes@citrix.com>
  Roy Franz <roy.franz@linaro.org>
  Simon Rowe <simon.rowe@eu.citrix.com>
  Willy Tarreau <w@1wt.eu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf-pvops host-install(3)

Not pushing.

------------------------------------------------------------
commit 5c8dd034f083dbc0cca2ba375a754978f8e25332
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 4 13:15:58 2014 +0100

    ... as being more like a hypervisor extension into the guest than a
    part of the tool stack.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 413e9215ace59eb9d0dcbd00376e1029ec23c6ab
Author: Razvan Cojocaru <rcojocaru@bitdefender.com>
Date:   Tue Nov 4 13:13:55 2014 +0100

    x86: disable emulate.c REP optimization if introspection is active
    
    Emulation for REP instructions is optimized to perform a single
    write for all repeats in the current page if possible. However,
    this interferes with a memory introspection application's ability
    to detect suspect behaviour, since it will cause only one
    mem_event to be sent per page touched.
    This patch disables the optimization, gated on introspection
    being active for the domain.
    
    Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

commit c38cf865ec82f27c62a60f0edfc717a5dc5fc6b4
Author: Roy Franz <roy.franz@linaro.org>
Date:   Tue Nov 4 13:13:26 2014 +0100

    EFI: ignore EFI commandline, skip console setup when booted from GRUB
    
    Update EFI code to completely ignore the EFI comnandline when booted from GRUB.
    Previusly it was parsed of EFI boot specific options, but these aren't used
    when booted from GRUB.
    
    Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
    code does some console and video initialization to support native EFI boot from
    the EFI boot manager or EFI shell.  This initlization should not be done when
    booted using GRUB.
    
    Update EFI documentation to indicate that it describes EFI native boot, and
    does not apply at all when Xen is booted using GRUB.
    
    Signed-off-by: Roy Franz <roy.franz@linaro.org>

commit 10a94ddbd2eb97365872cd14be93837c4613e09d
Author: Willy Tarreau <w@1wt.eu>
Date:   Tue Nov 4 13:09:09 2014 +0100

    lzo: check for length overrun in variable length encoding
    
    This fix ensures that we never meet an integer overflow while adding
    255 while parsing a variable length encoding. It works differently from
    commit 504f70b6 ("lzo: properly check for overruns") because instead of
    ensuring that we don't overrun the input, which is tricky to guarantee
    due to many assumptions in the code, it simply checks that the cumulated
    number of 255 read cannot overflow by bounding this number.
    
    The MAX_255_COUNT is the maximum number of times we can add 255 to a base
    count without overflowing an integer. The multiply will overflow when
    multiplying 255 by more than MAXINT/255. The sum will overflow earlier
    depending on the base count. Since the base count is taken from a u8
    and a few bits, it is safe to assume that it will always be lower than
    or equal to 2*255, thus we can always prevent any overflow by accepting
    two less 255 steps.
    
    This patch also reduces the CPU overhead and actually increases performance
    by 1.1% compared to the initial code, while the previous fix costs 3.1%
    (measured on x86_64).
    
    The fix needs to be backported to all currently supported stable kernels.
    
    Reported-by: Willem Pinckaers <willem@lekkertech.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    [original Linux commit: 72cf9012]
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 092978f2ffcf017b95c6ca674e629268d46222b4
Author: Willy Tarreau <w@1wt.eu>
Date:   Tue Nov 4 13:08:32 2014 +0100

    Revert "lzo: properly check for overruns"
    
    This reverts commit 504f70b6 ("lzo: properly check for overruns").
    
    As analysed by Willem Pinckaers, this fix is still incomplete on
    certain rare corner cases, and it is easier to restart from the
    original code.
    
    Reported-by: Willem Pinckaers <willem@lekkertech.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    [original Linux commit: af958a38]
    Signed-off-by: Jan Beulich <jbeulich@suse.com>

commit 01c019c843df313f62ca5c106544026867da9e9e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 4 13:07:23 2014 +0100

    x86/PVH: replace bogus assertion with conditional
    
    While PVH guests currently have to start in 64-bit mode, nothing keeps
    them from entering compatibility mode via a suitable ring-0 code
    selector and making a hypercall from there. Fail such attempts rather
    than asserting they won't happen.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

commit c9a1b736426b9ba5a96660ef3b23bb2f5100e79e
Author: David Scott <dave.scott@citrix.com>
Date:   Wed Oct 22 14:52:41 2014 +0100

    libxl: a domain can be dying but not shutdown
    
    The shutdown code is only present if the domain is shutdown.
    If we attempt to extract it from the flags from a dying but not
    shutdown domain then we get values like '255' which is not a
    valid LIBXL_SHUTDOWN_REASON_. We should use LIBXL_SHUTDOWN_UNKNOWN
    in this case.
    
    Signed-off-by: David Scott <dave.scott@citrix.com>
    Acked-by: Rob Hoes <rob.hoes@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    [ ijc -- updated comment in libxl_types.idl to match ]

commit 6f78e851395394ece4385b65ad0788840db2b5d1
Author: Martin Pohlack <mpohlack@amazon.de>
Date:   Tue Oct 28 13:35:21 2014 +0100

    blktap: CONFIG_GCRYPT detection
    
    Wrap make variable in () to allow correct evaluation.
    
    This fixes broken CONFIG_GCRYPT detection which was introduced by
    commit 85896a7c4dc7b6b1dba2db79dfb0ca61738a92a4 in 2012.
    
    Signed-off-by: Martin Pohlack <mpohlack@amazon.de>
    Reviewed-by: Uwe Dannowski <uwed@amazon.de>
    Reviewed-by: Anthony Liguori <aliguori@amazon.com>
    Reviewed-by: Matt Wilson <msw@amazon.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit beb0ef5f747bac4c6464383d74259b14adbfce19
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Wed Oct 29 14:09:41 2014 +0000

    tools/pygrub: Fix TOCTOU race introduced by c/s 63dcc68
    
    In addition, use os.makedirs() which will also create intermediate directories
    if they don't exist.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    CC: Ian Campbell <Ian.Campbell@citrix.com>
    CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
    CC: Wei Liu <wei.liu2@citrix.com>
    CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    CC: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 4ee393f9d6528640c29a0554fdc6cb3e795fb6e8
Author: Simon Rowe <simon.rowe@eu.citrix.com>
Date:   Mon Oct 27 16:00:14 2014 +0000

    pygrub: fix non-interactive parsing of grub1 config files
    
    Changes to handle non-numeric default attributes for grub2 caused run_grub()
    to attempt to index into the images list using a string. Pull out the code
    that handles submenus into a new function and use that to ensure sel is
    numeric.
    
    Reported-by: David Scott <dave.scott@citrix.com>
    Signed-off-by: Simon Rowe <simon.rowe@eu.citrix.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Reviewed-and-tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 23:04:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 23:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xm9by-0002n6-FW; Wed, 05 Nov 2014 23:03:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xm9bw-0002n1-J3
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 23:03:32 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	70/1B-02954-3CCAA545; Wed, 05 Nov 2014 23:03:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415228609!12835776!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18476 invoked from network); 5 Nov 2014 23:03:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 23:03:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,322,1413244800"; d="scan'208";a="188556107"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 18:03:28 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xm9br-0007a0-CA;
	Wed, 05 Nov 2014 23:03:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xm9br-00086U-2o;
	Wed, 05 Nov 2014 23:03:27 +0000
Date: Wed, 5 Nov 2014 23:03:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31387-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31387: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31387 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31387/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops             3 host-install(3)         broken REGR. vs. 31358

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31358

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass

version targeted for testing:
 xen                  5c8dd034f083dbc0cca2ba375a754978f8e25332
baseline version:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  David Scott <dave.scott@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Martin Pohlack <mpohlack@amazon.de>
  Razvan Cojocaru <rcojocaru@bitdefender.com>
  Rob Hoes <rob.hoes@citrix.com>
  Roy Franz <roy.franz@linaro.org>
  Simon Rowe <simon.rowe@eu.citrix.com>
  Willy Tarreau <w@1wt.eu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf-pvops host-install(3)

Not pushing.

------------------------------------------------------------
commit 5c8dd034f083dbc0cca2ba375a754978f8e25332
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 4 13:15:58 2014 +0100

    ... as being more like a hypervisor extension into the guest than a
    part of the tool stack.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 413e9215ace59eb9d0dcbd00376e1029ec23c6ab
Author: Razvan Cojocaru <rcojocaru@bitdefender.com>
Date:   Tue Nov 4 13:13:55 2014 +0100

    x86: disable emulate.c REP optimization if introspection is active
    
    Emulation for REP instructions is optimized to perform a single
    write for all repeats in the current page if possible. However,
    this interferes with a memory introspection application's ability
    to detect suspect behaviour, since it will cause only one
    mem_event to be sent per page touched.
    This patch disables the optimization, gated on introspection
    being active for the domain.
    
    Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

commit c38cf865ec82f27c62a60f0edfc717a5dc5fc6b4
Author: Roy Franz <roy.franz@linaro.org>
Date:   Tue Nov 4 13:13:26 2014 +0100

    EFI: ignore EFI commandline, skip console setup when booted from GRUB
    
    Update EFI code to completely ignore the EFI comnandline when booted from GRUB.
    Previusly it was parsed of EFI boot specific options, but these aren't used
    when booted from GRUB.
    
    Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
    code does some console and video initialization to support native EFI boot from
    the EFI boot manager or EFI shell.  This initlization should not be done when
    booted using GRUB.
    
    Update EFI documentation to indicate that it describes EFI native boot, and
    does not apply at all when Xen is booted using GRUB.
    
    Signed-off-by: Roy Franz <roy.franz@linaro.org>

commit 10a94ddbd2eb97365872cd14be93837c4613e09d
Author: Willy Tarreau <w@1wt.eu>
Date:   Tue Nov 4 13:09:09 2014 +0100

    lzo: check for length overrun in variable length encoding
    
    This fix ensures that we never meet an integer overflow while adding
    255 while parsing a variable length encoding. It works differently from
    commit 504f70b6 ("lzo: properly check for overruns") because instead of
    ensuring that we don't overrun the input, which is tricky to guarantee
    due to many assumptions in the code, it simply checks that the cumulated
    number of 255 read cannot overflow by bounding this number.
    
    The MAX_255_COUNT is the maximum number of times we can add 255 to a base
    count without overflowing an integer. The multiply will overflow when
    multiplying 255 by more than MAXINT/255. The sum will overflow earlier
    depending on the base count. Since the base count is taken from a u8
    and a few bits, it is safe to assume that it will always be lower than
    or equal to 2*255, thus we can always prevent any overflow by accepting
    two less 255 steps.
    
    This patch also reduces the CPU overhead and actually increases performance
    by 1.1% compared to the initial code, while the previous fix costs 3.1%
    (measured on x86_64).
    
    The fix needs to be backported to all currently supported stable kernels.
    
    Reported-by: Willem Pinckaers <willem@lekkertech.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    [original Linux commit: 72cf9012]
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 092978f2ffcf017b95c6ca674e629268d46222b4
Author: Willy Tarreau <w@1wt.eu>
Date:   Tue Nov 4 13:08:32 2014 +0100

    Revert "lzo: properly check for overruns"
    
    This reverts commit 504f70b6 ("lzo: properly check for overruns").
    
    As analysed by Willem Pinckaers, this fix is still incomplete on
    certain rare corner cases, and it is easier to restart from the
    original code.
    
    Reported-by: Willem Pinckaers <willem@lekkertech.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    [original Linux commit: af958a38]
    Signed-off-by: Jan Beulich <jbeulich@suse.com>

commit 01c019c843df313f62ca5c106544026867da9e9e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 4 13:07:23 2014 +0100

    x86/PVH: replace bogus assertion with conditional
    
    While PVH guests currently have to start in 64-bit mode, nothing keeps
    them from entering compatibility mode via a suitable ring-0 code
    selector and making a hypercall from there. Fail such attempts rather
    than asserting they won't happen.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

commit c9a1b736426b9ba5a96660ef3b23bb2f5100e79e
Author: David Scott <dave.scott@citrix.com>
Date:   Wed Oct 22 14:52:41 2014 +0100

    libxl: a domain can be dying but not shutdown
    
    The shutdown code is only present if the domain is shutdown.
    If we attempt to extract it from the flags from a dying but not
    shutdown domain then we get values like '255' which is not a
    valid LIBXL_SHUTDOWN_REASON_. We should use LIBXL_SHUTDOWN_UNKNOWN
    in this case.
    
    Signed-off-by: David Scott <dave.scott@citrix.com>
    Acked-by: Rob Hoes <rob.hoes@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    [ ijc -- updated comment in libxl_types.idl to match ]

commit 6f78e851395394ece4385b65ad0788840db2b5d1
Author: Martin Pohlack <mpohlack@amazon.de>
Date:   Tue Oct 28 13:35:21 2014 +0100

    blktap: CONFIG_GCRYPT detection
    
    Wrap make variable in () to allow correct evaluation.
    
    This fixes broken CONFIG_GCRYPT detection which was introduced by
    commit 85896a7c4dc7b6b1dba2db79dfb0ca61738a92a4 in 2012.
    
    Signed-off-by: Martin Pohlack <mpohlack@amazon.de>
    Reviewed-by: Uwe Dannowski <uwed@amazon.de>
    Reviewed-by: Anthony Liguori <aliguori@amazon.com>
    Reviewed-by: Matt Wilson <msw@amazon.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit beb0ef5f747bac4c6464383d74259b14adbfce19
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Wed Oct 29 14:09:41 2014 +0000

    tools/pygrub: Fix TOCTOU race introduced by c/s 63dcc68
    
    In addition, use os.makedirs() which will also create intermediate directories
    if they don't exist.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    CC: Ian Campbell <Ian.Campbell@citrix.com>
    CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
    CC: Wei Liu <wei.liu2@citrix.com>
    CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    CC: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 4ee393f9d6528640c29a0554fdc6cb3e795fb6e8
Author: Simon Rowe <simon.rowe@eu.citrix.com>
Date:   Mon Oct 27 16:00:14 2014 +0000

    pygrub: fix non-interactive parsing of grub1 config files
    
    Changes to handle non-numeric default attributes for grub2 caused run_grub()
    to attempt to index into the images list using a string. Pull out the code
    that handles submenus into a new function and use that to ensure sel is
    numeric.
    
    Reported-by: David Scott <dave.scott@citrix.com>
    Signed-off-by: Simon Rowe <simon.rowe@eu.citrix.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Reviewed-and-tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 23:32:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 23:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmA3D-0003Qg-0r; Wed, 05 Nov 2014 23:31:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1XmA3B-0003Qb-9x
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 23:31:41 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	FF/FB-27785-C53BA545; Wed, 05 Nov 2014 23:31:40 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415230298!12818159!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13772 invoked from network); 5 Nov 2014 23:31:39 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 23:31:39 -0000
Received: by mail-qa0-f50.google.com with SMTP id bm13so1294196qab.23
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 15:31:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=tGiDSN4CaFzWOCJphnVFaHBnpVqF2nvDuR4PgbQQbn0=;
	b=Ib2K/XNDC9DVs5Ay/tHY7YqvFoMLLSh7xgdUZkgq109jfwHriSN3Rs8kPL8FA+FMMN
	fDL4DgK6abEOmcuykmwi6plkVzdoGAokkjlNireV/0i5jzlxLo1iVCepwp5RI/k4GUwy
	asV4XeUUs3KAWZbz4K0I3eibmsxufATgF1UrrDHbpFXnEP5QniUGFwjpozjelSrba+IZ
	FJ3obL8mg8TjXP/iFfwg/iygVt37BpD18IwkJRS1ZYgMIV8zHfkQpLGNCi8AOl4d14rI
	Csd99FfJdHEPqzGJwOynaoX9aWm7D2G8N4V8agkOwr079Zc2heTBvAkqX2sl+1M+5CEY
	fWuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=tGiDSN4CaFzWOCJphnVFaHBnpVqF2nvDuR4PgbQQbn0=;
	b=JWEfA+g2PVa1Ysisq8WFr1k8U2/q7xsGtdYnbuThXlpBnsB/aiNi3KmpGlEF7Ka4aV
	CiqyLTZdbkP78eqwJ1rYD/l7cehoJQ8YrXQYD2JX9Fhb3GtLV1c5M4BrTlBZdLc7mECY
	OYvCeAsn+w/UhVqAeXLUZC6IrXH7h1BoM6zn9qtvMWe1C5hVr+QsEEVwnL/022wGd+E6
	uCWnn6EGMZoNeboeQBgcIqFad6/dFLqtI/4pryqX4n2Zi8n1KKY/lz50zZZfDTuAfKLi
	hEgwMi1p4F8Y3bgjlpqd/FTwha1wuBjrAj3cmVR1ze/6o8cibozPMEk/36g69+T12R6m
	ul4g==
X-Gm-Message-State: ALoCoQnvF36H+Q+6MuZEU7ndmsOksBLvMKwGf7Xc1LV2a0Mtdf+UMm50rWWQL4bvilS53Z5Er8u5
X-Received: by 10.229.212.66 with SMTP id gr2mr1158055qcb.8.1415230298030;
	Wed, 05 Nov 2014 15:31:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.164.210 with HTTP; Wed, 5 Nov 2014 15:31:17 -0800 (PST)
In-Reply-To: <544AD7CF.5020006@gmail.com>
References: <469h2cuyy0a5y5fn77uh3y1b.1413332405802@email.android.com>
	<20141015210355.GB6579@laptop.dumpdata.com>
	<544AD7CF.5020006@gmail.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Wed, 5 Nov 2014 16:31:17 -0700
Message-ID: <CAErSpo78mX9Q8HDsOFMhzNTjtGqD1aiTTrWH-zwGUEo24EF9CA@mail.gmail.com>
To: Chen Gang <gang.chen.5i5j@gmail.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH next] xen: pcifront: Process failure for
	pcifront_(re)scan_root()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[+cc linux-pci again]

On Fri, Oct 24, 2014 at 4:50 PM, Chen Gang <gang.chen.5i5j@gmail.com> wrote:
> On 10/16/14 5:03, Konrad Rzeszutek Wilk wrote:
>> On Wed, Oct 15, 2014 at 08:20:06AM +0800, Chen Gang wrote:
>>>
>>> At least for me, what you said sound OK.
>>
>> Let me review it - next week.
>
> Please help check this patch, when you have time.

linux-pci got dropped from the cc list, which makes it harder for me
to track this in patchwork.

But I'm waiting for Konrad to either ack this or just take it
directly.  Here's my ack if you want it:

Acked-by: Bjorn Helgas <bhelgaas@google.com>

>>> Bjorn Helgaas <bhelgaas@google.com> wrote:
>>>
>>>> On Mon, Oct 06, 2014 at 11:04:45AM +0800, Chen Gang wrote:
>>>>> When pcifront_rescan_root() or pcifront_scan_root() fails, need return
>>>>> error code, neither set XenbusStateConnected state, just like the other
>>>>> areas have done.
>>>>>
>>>>> For pcifront_rescan_root(), it will return error code ("num_roots = 0;",
>>>>> skip xenbus_switch_state return value).
>>>>>
>>>>> For pcifront_scan_root(), it will return 0 ("num_roots = 0;", set 0 by
>>>>> the return value of xenbus_switch_state, which always return 0, at
>>>>> present).
>>>>
>>>> The changelog is somewhat confusing because it talks about the patch hunks
>>>> in reverse order (the pcifront_scan_root() change is first in the patch,
>>>> but the changelog mentions pcifront_rescan_root() first).  I *think* this
>>>> means:
>>>>
>>>>  When pcifront_try_connect() finds no PCI roots, it falls back to calling
>>>>  pcifront_scan_root() for 0000:00.  If that fails, it used to switch to
>>>>  XenbusStateConnected and return success (because xenbus_switch_state()
>>>>  currently always succeeds).
>>>>
>>>>  If pcifront_scan_root() fails, leave the XenbusState unchanged and
>>>>  return an error code.
>>>>
>>>>  Similarly, pcifront_attach_devices() falls back to calling
>>>>  pcifront_rescan_root() for 0000:00.  If that fails, it used to
>>>>  switch to XenbusStateConnected and return an error code.
>>>>
>>>>  If pcifront_rescan_root() fails, leave the XenbusState unchanged and
>>>>  return the error code.
>>>>
>>>> The "num_roots" part doesn't seem relevant to me.
>>>>
>>>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>>>
>>>> Konrad, if you want to take this, feel free.  Otherwise, if you ack it and
>>>> you think my changelog understanding makes sense, I can pick it up.
>>>>
>>>> It does seem odd that pcifront_attach_devices() ignores the
>>>> xenbus_switch_state() return value while pcifront_try_connect() does not.
>>>> But many other callers also ignore the return value, so maybe that's OK.
>>>>
>>>> Bjorn
>>>>
>>>>> ---
>>>>>  drivers/pci/xen-pcifront.c | 10 ++++++++++
>>>>>  1 file changed, 10 insertions(+)
>>>>>
>>>>> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
>>>>> index 53df39a..d78d884 100644
>>>>> --- a/drivers/pci/xen-pcifront.c
>>>>> +++ b/drivers/pci/xen-pcifront.c
>>>>> @@ -866,6 +866,11 @@ static int pcifront_try_connect(struct pcifront_device *pdev)
>>>>>            xenbus_dev_error(pdev->xdev, err,
>>>>>                             "No PCI Roots found, trying 0000:00");
>>>>>            err = pcifront_scan_root(pdev, 0, 0);
>>>>> +          if (err) {
>>>>> +                  xenbus_dev_fatal(pdev->xdev, err,
>>>>> +                                   "Error scanning PCI root 0000:00");
>>>>> +                  goto out;
>>>>> +          }
>>>>>            num_roots = 0;
>>>>>    } else if (err != 1) {
>>>>>            if (err == 0)
>>>>> @@ -947,6 +952,11 @@ static int pcifront_attach_devices(struct pcifront_device *pdev)
>>>>>            xenbus_dev_error(pdev->xdev, err,
>>>>>                             "No PCI Roots found, trying 0000:00");
>>>>>            err = pcifront_rescan_root(pdev, 0, 0);
>>>>> +          if (err) {
>>>>> +                  xenbus_dev_fatal(pdev->xdev, err,
>>>>> +                                   "Error scanning PCI root 0000:00");
>>>>> +                  goto out;
>>>>> +          }
>>>>>            num_roots = 0;
>>>>>    } else if (err != 1) {
>>>>>            if (err == 0)
>>>>> --
>>>>> 1.9.3
>
> --
> Chen Gang
>
> Open, share, and attitude like air, water, and life which God blessed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 23:32:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 23:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmA3D-0003Qg-0r; Wed, 05 Nov 2014 23:31:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1XmA3B-0003Qb-9x
	for xen-devel@lists.xenproject.org; Wed, 05 Nov 2014 23:31:41 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	FF/FB-27785-C53BA545; Wed, 05 Nov 2014 23:31:40 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415230298!12818159!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13772 invoked from network); 5 Nov 2014 23:31:39 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 23:31:39 -0000
Received: by mail-qa0-f50.google.com with SMTP id bm13so1294196qab.23
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 15:31:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=tGiDSN4CaFzWOCJphnVFaHBnpVqF2nvDuR4PgbQQbn0=;
	b=Ib2K/XNDC9DVs5Ay/tHY7YqvFoMLLSh7xgdUZkgq109jfwHriSN3Rs8kPL8FA+FMMN
	fDL4DgK6abEOmcuykmwi6plkVzdoGAokkjlNireV/0i5jzlxLo1iVCepwp5RI/k4GUwy
	asV4XeUUs3KAWZbz4K0I3eibmsxufATgF1UrrDHbpFXnEP5QniUGFwjpozjelSrba+IZ
	FJ3obL8mg8TjXP/iFfwg/iygVt37BpD18IwkJRS1ZYgMIV8zHfkQpLGNCi8AOl4d14rI
	Csd99FfJdHEPqzGJwOynaoX9aWm7D2G8N4V8agkOwr079Zc2heTBvAkqX2sl+1M+5CEY
	fWuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=tGiDSN4CaFzWOCJphnVFaHBnpVqF2nvDuR4PgbQQbn0=;
	b=JWEfA+g2PVa1Ysisq8WFr1k8U2/q7xsGtdYnbuThXlpBnsB/aiNi3KmpGlEF7Ka4aV
	CiqyLTZdbkP78eqwJ1rYD/l7cehoJQ8YrXQYD2JX9Fhb3GtLV1c5M4BrTlBZdLc7mECY
	OYvCeAsn+w/UhVqAeXLUZC6IrXH7h1BoM6zn9qtvMWe1C5hVr+QsEEVwnL/022wGd+E6
	uCWnn6EGMZoNeboeQBgcIqFad6/dFLqtI/4pryqX4n2Zi8n1KKY/lz50zZZfDTuAfKLi
	hEgwMi1p4F8Y3bgjlpqd/FTwha1wuBjrAj3cmVR1ze/6o8cibozPMEk/36g69+T12R6m
	ul4g==
X-Gm-Message-State: ALoCoQnvF36H+Q+6MuZEU7ndmsOksBLvMKwGf7Xc1LV2a0Mtdf+UMm50rWWQL4bvilS53Z5Er8u5
X-Received: by 10.229.212.66 with SMTP id gr2mr1158055qcb.8.1415230298030;
	Wed, 05 Nov 2014 15:31:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.164.210 with HTTP; Wed, 5 Nov 2014 15:31:17 -0800 (PST)
In-Reply-To: <544AD7CF.5020006@gmail.com>
References: <469h2cuyy0a5y5fn77uh3y1b.1413332405802@email.android.com>
	<20141015210355.GB6579@laptop.dumpdata.com>
	<544AD7CF.5020006@gmail.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Wed, 5 Nov 2014 16:31:17 -0700
Message-ID: <CAErSpo78mX9Q8HDsOFMhzNTjtGqD1aiTTrWH-zwGUEo24EF9CA@mail.gmail.com>
To: Chen Gang <gang.chen.5i5j@gmail.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH next] xen: pcifront: Process failure for
	pcifront_(re)scan_root()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[+cc linux-pci again]

On Fri, Oct 24, 2014 at 4:50 PM, Chen Gang <gang.chen.5i5j@gmail.com> wrote:
> On 10/16/14 5:03, Konrad Rzeszutek Wilk wrote:
>> On Wed, Oct 15, 2014 at 08:20:06AM +0800, Chen Gang wrote:
>>>
>>> At least for me, what you said sound OK.
>>
>> Let me review it - next week.
>
> Please help check this patch, when you have time.

linux-pci got dropped from the cc list, which makes it harder for me
to track this in patchwork.

But I'm waiting for Konrad to either ack this or just take it
directly.  Here's my ack if you want it:

Acked-by: Bjorn Helgas <bhelgaas@google.com>

>>> Bjorn Helgaas <bhelgaas@google.com> wrote:
>>>
>>>> On Mon, Oct 06, 2014 at 11:04:45AM +0800, Chen Gang wrote:
>>>>> When pcifront_rescan_root() or pcifront_scan_root() fails, need return
>>>>> error code, neither set XenbusStateConnected state, just like the other
>>>>> areas have done.
>>>>>
>>>>> For pcifront_rescan_root(), it will return error code ("num_roots = 0;",
>>>>> skip xenbus_switch_state return value).
>>>>>
>>>>> For pcifront_scan_root(), it will return 0 ("num_roots = 0;", set 0 by
>>>>> the return value of xenbus_switch_state, which always return 0, at
>>>>> present).
>>>>
>>>> The changelog is somewhat confusing because it talks about the patch hunks
>>>> in reverse order (the pcifront_scan_root() change is first in the patch,
>>>> but the changelog mentions pcifront_rescan_root() first).  I *think* this
>>>> means:
>>>>
>>>>  When pcifront_try_connect() finds no PCI roots, it falls back to calling
>>>>  pcifront_scan_root() for 0000:00.  If that fails, it used to switch to
>>>>  XenbusStateConnected and return success (because xenbus_switch_state()
>>>>  currently always succeeds).
>>>>
>>>>  If pcifront_scan_root() fails, leave the XenbusState unchanged and
>>>>  return an error code.
>>>>
>>>>  Similarly, pcifront_attach_devices() falls back to calling
>>>>  pcifront_rescan_root() for 0000:00.  If that fails, it used to
>>>>  switch to XenbusStateConnected and return an error code.
>>>>
>>>>  If pcifront_rescan_root() fails, leave the XenbusState unchanged and
>>>>  return the error code.
>>>>
>>>> The "num_roots" part doesn't seem relevant to me.
>>>>
>>>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>>>
>>>> Konrad, if you want to take this, feel free.  Otherwise, if you ack it and
>>>> you think my changelog understanding makes sense, I can pick it up.
>>>>
>>>> It does seem odd that pcifront_attach_devices() ignores the
>>>> xenbus_switch_state() return value while pcifront_try_connect() does not.
>>>> But many other callers also ignore the return value, so maybe that's OK.
>>>>
>>>> Bjorn
>>>>
>>>>> ---
>>>>>  drivers/pci/xen-pcifront.c | 10 ++++++++++
>>>>>  1 file changed, 10 insertions(+)
>>>>>
>>>>> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
>>>>> index 53df39a..d78d884 100644
>>>>> --- a/drivers/pci/xen-pcifront.c
>>>>> +++ b/drivers/pci/xen-pcifront.c
>>>>> @@ -866,6 +866,11 @@ static int pcifront_try_connect(struct pcifront_device *pdev)
>>>>>            xenbus_dev_error(pdev->xdev, err,
>>>>>                             "No PCI Roots found, trying 0000:00");
>>>>>            err = pcifront_scan_root(pdev, 0, 0);
>>>>> +          if (err) {
>>>>> +                  xenbus_dev_fatal(pdev->xdev, err,
>>>>> +                                   "Error scanning PCI root 0000:00");
>>>>> +                  goto out;
>>>>> +          }
>>>>>            num_roots = 0;
>>>>>    } else if (err != 1) {
>>>>>            if (err == 0)
>>>>> @@ -947,6 +952,11 @@ static int pcifront_attach_devices(struct pcifront_device *pdev)
>>>>>            xenbus_dev_error(pdev->xdev, err,
>>>>>                             "No PCI Roots found, trying 0000:00");
>>>>>            err = pcifront_rescan_root(pdev, 0, 0);
>>>>> +          if (err) {
>>>>> +                  xenbus_dev_fatal(pdev->xdev, err,
>>>>> +                                   "Error scanning PCI root 0000:00");
>>>>> +                  goto out;
>>>>> +          }
>>>>>            num_roots = 0;
>>>>>    } else if (err != 1) {
>>>>>            if (err == 0)
>>>>> --
>>>>> 1.9.3
>
> --
> Chen Gang
>
> Open, share, and attitude like air, water, and life which God blessed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 05 23:58:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 23: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 1XmASW-00046O-FX; Wed, 05 Nov 2014 23:57:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmASV-00046J-7p
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 23:57:51 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	65/F2-16982-E79BA545; Wed, 05 Nov 2014 23:57:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415231868!11954651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28427 invoked from network); 5 Nov 2014 23:57:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 23:57:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,322,1413244800"; d="scan'208";a="188570869"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 18:57:46 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmASQ-0007q3-LS;
	Wed, 05 Nov 2014 23:57:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmASQ-0003Jp-Fj;
	Wed, 05 Nov 2014 23:57:46 +0000
Date: Wed, 5 Nov 2014 23:57:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31388-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31388: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31388 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31388/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot              fail pass in 31363

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31363 never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 05 23:58:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Nov 2014 23: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 1XmASW-00046O-FX; Wed, 05 Nov 2014 23:57:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmASV-00046J-7p
	for xen-devel@lists.xensource.com; Wed, 05 Nov 2014 23:57:51 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	65/F2-16982-E79BA545; Wed, 05 Nov 2014 23:57:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415231868!11954651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28427 invoked from network); 5 Nov 2014 23:57:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Nov 2014 23:57:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,322,1413244800"; d="scan'208";a="188570869"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 5 Nov 2014 18:57:46 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmASQ-0007q3-LS;
	Wed, 05 Nov 2014 23:57:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmASQ-0003Jp-Fj;
	Wed, 05 Nov 2014 23:57:46 +0000
Date: Wed, 5 Nov 2014 23:57:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31388-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31388: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31388 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31388/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot              fail pass in 31363

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31363 never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 00:11:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 00:11:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmAfy-0004ty-FF; Thu, 06 Nov 2014 00:11:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmAfw-0004tm-Eu
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 00:11:44 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	DB/51-29352-FBCBA545; Thu, 06 Nov 2014 00:11:43 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415232693!6060515!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3338 invoked from network); 6 Nov 2014 00:11:41 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-14.tower-206.messagelabs.com with SMTP;
	6 Nov 2014 00:11:41 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 05 Nov 2014 16:11:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,322,1413270000"; d="scan'208";a="627327987"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by fmsmga002.fm.intel.com with ESMTP; 05 Nov 2014 16:11:16 -0800
Received: from pgsmsx108.gar.corp.intel.com (10.221.44.103) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 08:10:48 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 08:10:48 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.156]) with mapi id
	14.03.0195.001; Thu, 6 Nov 2014 08:10:47 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP91zOKlhH4xypD06jTqC2+4O7eZxQng+ggAC8ygCAAMpkkP//sUyAgADmo8A=
Date: Thu, 6 Nov 2014 00:10:46 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820463@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411051036310.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8202B7@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411051821510.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411051821510.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Thursday, November 06, 2014 2:24 AM
> To: Xu, Quan
> Cc: Stefano Stabellini; qemu-devel@nongnu.org; xen-devel@lists.xen.org
> Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> On Wed, 5 Nov 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Wednesday, November 05, 2014 7:01 PM
> > > To: Xu, Quan
> > > Cc: Stefano Stabellini; qemu-devel@nongnu.org;
> > > xen-devel@lists.xen.org
> > > Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > > frontend driver
> > >
> > > On Tue, 4 Nov 2014, Xu, Quan wrote:
> > > > > -----Original Message-----
> > > > > From: Stefano Stabellini
> > > > > [mailto:stefano.stabellini@eu.citrix.com]
> > > > > Sent: Monday, November 03, 2014 7:54 PM
> > > > > To: Xu, Quan
> > > > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > > > > stefano.stabellini@eu.citrix.com
> > > > > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
> > > > > vTPM frontend driver
> > > > >
> > > > > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > > > > This drvier transfers any request/repond between TPM
> > > > > > xenstubdoms driver and Xen vTPM stubdom, and facilitates
> > > > > > communications between Xen vTPM stubdom domain and vTPM
> > > > > > xenstubdoms driver
> > > > > >
> > > > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > > >
> > > > > Please describe what changes did make to xen_backend.c and why.
> > > > > The commit message should contains info on all the changes made
> > > > > by the patch below.
> > > > >
> > > >
> > > > Thanks Stefano.
> > > > one more day, I will explain in detail what changes did make to
> > > > xen_backend.c and why.
> > > > The following 2 sections are introduction and architecture.
> > > >
> > > > > Please also describe what is the "Xen vTPM stubdom", what is the
> > > > > "vTPM xenstubdoms driver" and how the communicate with each
> others.
> > > > >
> > > >
> > > >
> > > > Add 2 parts for detailed descriptions, introduction and architecture.
> > > >
> > > > *INTRODUCTION*
> > > >
> > > > The goal of virtual Trusted Platform Module (vTPM) is to provide a
> > > > TPM functionality to virtual machines (Fedora, Ubuntu, Redhat,
> > > > Windows .etc). This allows programs to interact with a TPM in a
> > > > virtual machine the same way they interact with a TPM on the physical
> system.
> > > Each virtual machine gets its own unique, emulated, software TPM.
> > > > Each major component of vTPM is implemented as a stubdom,
> > > > providing secure separation guaranteed by the hypervisor.
> > > > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for
> > > > the virtual machine to use. It is a small wrapper around the
> > > > Berlios TPM emulator. TPM commands are passed from mini-os TPM
> backend driver.
> > > > This patch series are only the Qemu part to enable Xen stubdom
> > > > vTPM for HVM virtual machine.
> > > > ===========
> > > >
> > > > *ARCHITECTURE*
> > > >
> > > > The architecture of stubdom vTPM for HVM virtual machine:
> > > >
> > > >             +--------------------+
> > > >             | Windows/Linux DomU | ...
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |  Qemu tpm1.2 Tis   |
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |        vTPM        |
> > > >             | XenStubdoms driver |  (new ..)
> > > >             +--------------------+
> > > >                      |  ^
> > > >                      v  |
> > > >             +--------------------+
> > > >             |  xen_vtpmdev_ops   |  (new ..)
> > > >             +--------------------+
> > > >                      |  ^
> > > >                      v  |
> > > >             +--------------------+
> > > >             |  mini-os/tpmback   |
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |   vTPM stubdom     | ...
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |  mini-os/tpmfront  |
> > > >             +--------------------+
> > > >                      |  ^
> > > >                      v  |
> > > >             +--------------------+
> > > >             |  mini-os/tpmback   |
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |  vtpmmgr stubdom   |
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |  mini-os/tpm_tis   |
> > > >             +--------------------+
> > > >                      |  ^
> > > >                      v  |
> > > >             +--------------------+
> > > >             |    Hardware TPM    |
> > > >             +--------------------+
> > > >
> > > >
> > > > * Windows/Linux DomU:
> > > >     The HVM based guest that wants to use a vTPM. There may be
> > > >     more than one of these.
> > > >
> > > >  * Qemu tpm1.2 Tis:
> > > >     Implementation of the tpm1.2 Tis interface for HVM virtual
> > > >     machines. It is Qemu emulation device.
> > >
> > > It looks like you are running upstream QEMU within a Mini-OS stubdom?
> > > If so, where are the patches to do that? As far as I know upstream
> > > QEMU doesn't run on Mini-OS. Or maybe it is a Linux stubdom? Either
> > > way, it is not clear.
> >
> > Not so.
> > Refer to below further explanation.
> >
> > >
> > >
> > > >  * vTPM xenstubdoms driver:
> > > >     Similar to a TPM passthrough backend driver, it is a new TPM
> > > >     backend for emulated TPM TIS interface. This driver provides
> > > >     vTPM initialization and sending data and commends to a Xen
> > > >     vTPM stubdom.
> > >
> > > This is patch #3, right? It is basically the internal QEMU "glue" to
> > > connect the tpm emulator to xen_vtpmdev_ops, correct?
> > >
> >
> > Yes, it is Patch #3. Agree with your description.  :)
> >
> > >
> > > >  * xen_vtpmdev_ops:
> > > >     Register Xen stubdom vTPM backend, and transfer any request/
> > > >     repond between TPM xenstubdoms driver and Xen vTPM
> stubdom.
> > > >     Facilitate communications between Xen vTPM stubdom and vTPM
> > > >     xenstubdoms driver.
> > >
> > > It looks like this correspond to patch #2? If so, this is a regular
> > > Xen PV
> >
> > Yes, it patch #2.
> >
> >
> > > frontend, living in QEMU? It requires the gntalloc device so I guess
> > > it is supposed to run on Linux. In that case is it just a tpmfront
> > > implementation in QEMU?
> > >
> >
> >
> > Yes, it's tpmfront implementation in Qemu. also it supports PV Linux since
> Xen 4.3.0.
> > vTPM stubdom / vtpmmgr stubdom  ware implemented by Matthew
> Fioravante
> > (JHUAPL), Linux pv vTPM frontend was implemented by Daniel De Graaf
> > (NSA)
> >
> >
> >
> > > If you are running it on Linux, we might need to introduce Linux
> > > based stundoms to the Xen build system.
> >
> > Not so.
> > Maybe I should explain a bit further. TPM is a character device. 'Qemu
> tpm1.2 Tis'
> > Implement some TPM register hook of TPM, and enable TIS (TPM interface
> Specification).
> > The ' Qemu tpm1.2 Tis ' should deal with TPM commands.
> >
> > Such as TPM_ContinueSelfTest command,
> >     { 0x00, 0xc1, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x53}; If
> > success, the TPM will respond,
> >     { 0x00, 0xc4, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x00};
> >
> > Qemu upstream has supported TPM passthrough. actually, 'Qemu TPM
> > passthrough' send These TPM commands from "Qemu tpm1.2 Tis" to TPM
> hardware, and get the respond.
> >
> > " [PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for HVM
> virtual
> > machine " send These TPM commands from "Qemu tpm1.2 Tis" to Xen
> > stubdom( explain in previous email) And get the respond.
> >
> > #(qemu-system-* --tpmdev help)
> > #(passthrough   Passthrough TPM backend driver)
> > #( xenstubdoms  Xenstubdoms TPM backend driver)
> >
> > The following is Qemu part.
> >
> >             |        |  ^       |
> >             |        v  |       |
> >             |        vTPM      |
> >             | XenStubdoms driver |  (new ..)
> >             +------------------------------+
> >                      |  ^
> >                      v  |
> >             +------------------------------+
> >             |  xen_vtpmdev_ops  |  (new ..)
> >             +------------------------------+ "vTPM XenStubdoms driver"
> > and "xen_vtpmdev_ops" are implemented to send These TPM commands
> from
> > "Qemu tpm1.2 Tis" to Xen stubdom.
> 
> OK, so if I understand correctly in your architecture QEMU is running in
> Dom0 as usual, right?

Yes, 

> 
> 
> 
> > >
> > > >  * mini-os/tpmback:
> > > >     Mini-os TPM backend driver. The Linux frontend driver connects
> > > >     to this backend driver to facilitate communications between the
> > > >     Linux DomU and its vTPM. This driver is also used by vtpmmgr
> > > >     stubdom to communicate with vTPM stubdom.
> > > >
> > > >  * vTPM stubdom:
> > > >     A mini-os stub domain that implements a vTPM. There is a
> > > >     one to one mapping between running vTPM stubdom instances
> and
> > > >     logical vTPMs on the system. The vTPM Platform Configuration
> > > >     Registers (PCRs) are all initialized to zero.
> > > >
> > > >  * mini-os/tpmfront:
> > > >     Mini-os TPM frontend driver. The vTPM mini-os domain vTPM
> > > >     stubdom uses this driver to communicate with
> vtpmmgr-stubdom.
> > > >     This driver could also be used separately to implement a mini-os
> > > >     domain that wishes to use a vTPM of its own.
> > > >
> > > >  * vtpmmgr stubdom:
> > > >     A mini-os domain that implements the vTPM manager. There is
> only
> > > >     one vTPM manager and it should be running during the entire
> lifetime
> > > >     of the machine. vtpmmgr domain securely stores encryption keys
> for
> > > >     each of the vTPMs and accesses to the hardware TPM to get the
> > > > root
> > > of
> > > >     trust for the entire system.
> > > >
> > > >  * mini-os/tpm_tis:
> > > >     Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
> > > >     This driver used by vtpmmgr-stubdom to talk directly to the
> hardware
> > > >     TPM. Communication is facilitated by mapping hardware memory
> > > pages
> > > >     into vtpmmgr stubdom.
> > >
> > > Are all the Mini-OS component upstream, or do we need patches?
> > >
> > >
> > > >  * Hardware TPM:
> > > >     The physical TPM 1.2 that is soldered onto the motherboard.
> > > >
> > > > ===========
> > > >
> > > >
> > > >
> > > > > Where does the vTPM backend lives?
> > > > The vTPM backend lives in Xen vTPM stubdom (Xen Mini-os)
> > >
> > > Thanks for the explanation, it is a bit clearer now.
> > >
> >
> >
> > Welcome, thanks for your careful review.
> >
> >
> >
> > >
> > > > >
> > > > >
> > > > > >  hw/xen/Makefile.objs         |   1 +
> > > > > >  hw/xen/xen_backend.c         | 182
> ++++++++++++++++++++++-
> > > > > >  hw/xen/xen_stubdom_vtpm.c    | 333
> > > > > +++++++++++++++++++++++++++++++++++++++++++
> > > > > >  include/hw/xen/xen_backend.h |  11 ++
> > > > > >  include/hw/xen/xen_common.h  |   6 +
> > > > > >  xen-hvm.c                    |  13 ++
> > > > > >  6 files changed, 544 insertions(+), 2 deletions(-)  create
> > > > > > mode
> > > > > > 100644 hw/xen/xen_stubdom_vtpm.c
> > > > > >
> > > > > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs index
> > > > > > a0ca0aa..724df8d 100644
> > > > > > --- a/hw/xen/Makefile.objs
> > > > > > +++ b/hw/xen/Makefile.objs
> > > > > > @@ -1,5 +1,6 @@
> > > > > >  # xen backend driver support
> > > > > >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> > > > > xen_devconfig.o
> > > > > > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) +=
> > > xen_stubdom_vtpm.o
> > > > > >
> > > > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> > > > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> > > > > xen_pt_config_init.o xen_pt_msi.o
> > > > > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index
> > > > > > b2cb22b..45a5778 100644
> > > > > > --- a/hw/xen/xen_backend.c
> > > > > > +++ b/hw/xen/xen_backend.c
> > > > > > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice
> > > > > > *xendev,
> > > > > enum xenbus_state state)
> > > > > >      return 0;
> > > > > >  }
> > > > > >
> > > > > > +/*get stubdom backend*/
> > > > > > +static char *xen_stubdom_be(const char *type, int dom, int dev) {
> > > > > > +    char *val, *domu;
> > > > > > +    char path[XEN_BUFSIZE];
> > > > > > +    unsigned int len, ival;
> > > > > > +
> > > > > > +    /*front domu*/
> > > > > > +    domu = xs_get_domain_path(xenstore, dom);
> > > > > > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > > > > > +             domu, type, dev);
> > > > > > +    g_free(domu);
> > > > > > +
> > > > > > +    val = xs_read(xenstore, 0, path, &len);
> > > > > > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > > > > > +        g_free(val);
> > > > > > +        return NULL;
> > > > > > +    }
> > > > > > +    g_free(val);
> > > > > > +
> > > > > > +    /*backend domu*/
> > > > > > +    domu = xs_get_domain_path(xenstore, ival);
> > > > > > +
> > > > > > +    return domu;
> > > > > > +}
> > > > > > +
> > > > > >  /*
> > > > > > -------------------------------------------------------------
> > > > > > */
> > > > > >
> > > > > >  struct XenDevice *xen_be_find_xendev(const char *type, int
> > > > > > dom, int
> > > > > dev)
> > > > > > @@ -222,6 +248,7 @@ static struct XenDevice
> > > > > > *xen_be_get_xendev(const
> > > > > char *type, int dom, int dev,
> > > > > >                                             struct
> XenDevOps
> > > *ops)
> > > > > > {
> > > > > >      struct XenDevice *xendev;
> > > > > > +    char *stub;
> > > > > >
> > > > > >      xendev = xen_be_find_xendev(type, dom, dev);
> > > > > >      if (xendev) {
> > > > > > @@ -235,8 +262,15 @@ static struct XenDevice
> > > > > *xen_be_get_xendev(const char *type, int dom, int dev,
> > > > > >      xendev->dev   = dev;
> > > > > >      xendev->ops   = ops;
> > > > > >
> > > > > > -    snprintf(xendev->be, sizeof(xendev->be),
> "backend/%s/%d/%d",
> > > > > > -             xendev->type, xendev->dom, xendev->dev);
> > > > > > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > > > > > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> > > > > xendev->dev);
> > > > > > +        snprintf(xendev->be, sizeof(xendev->be),
> > > > > "%s/backend/%s/%d/%d",
> > > > > > +                 stub, xendev->type, xendev->dom,
> xendev->dev);
> > > > > > +        g_free(stub);
> > > > > > +    } else {
> > > > > > +        snprintf(xendev->be, sizeof(xendev->be),
> > > "backend/%s/%d/%d",
> > > > > > +                 xendev->type, xendev->dom, xendev->dev);
> > > > > > +    }
> > > > > >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> > > > > >               xendev->type, xendev->dev);
> > > > > >
> > > > > > @@ -611,6 +645,47 @@ static int xenstore_scan(const char
> > > > > > *type, int
> > > > > dom, struct XenDevOps *ops)
> > > > > >      return 0;
> > > > > >  }
> > > > > >
> > > > > > +static void stubdom_update_be(char *watch, char *type, int dom,
> > > > > > +                              struct XenDevOps *ops) {
> > > > > > +    struct XenDevice *xendev;
> > > > > > +    char path[XEN_BUFSIZE];
> > > > > > +    char *ptr, *bepath;
> > > > > > +    unsigned int len, dev;
> > > > > > +
> > > > > > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > > > > > +        return;
> > > > > > +    }
> > > > > > +
> > > > > > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type,
> dom);
> > > > > > +    ptr = strstr(watch, path);
> > > > > > +    if (ptr == NULL) {
> > > > > > +        return;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > > > > > +        strcpy(path, "");
> > > > > > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > > > > > +            dev = -1;
> > > > > > +        }
> > > > > > +    }
> > > > > > +
> > > > > > +    if (dev == -1) {
> > > > > > +        return;
> > > > > > +    }
> > > > > > +
> > > > > > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > > > > > +    if (xendev != NULL) {
> > > > > > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > > > > > +        if (bepath == NULL) {
> > > > > > +            xen_be_del_xendev(dom, dev);
> > > > > > +        } else {
> > > > > > +            free(bepath);
> > > > > > +            xen_be_backend_changed(xendev, path);
> > > > > > +        }
> > > > > > +    }
> > > > > > +}
> > > > > > +
> > > > > >  static void xenstore_update_be(char *watch, char *type, int dom,
> > > > > >                                 struct XenDevOps *ops)
> { @@
> > > > > > -681,6 +756,10 @@ static void xenstore_update(void *unused)
> > > > > >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1)
> {
> > > > > >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> > > > > >      }
> > > > > > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> > > > > PRIxPTR,
> > > > > > +               &type, &dom, &ops) == 3) {
> > > > > > +        stubdom_update_be(vec[XS_WATCH_PATH], (void
> *)type,
> > > dom,
> > > > > (void *)ops);
> > > > > > +    }
> > > > > >
> > > > > >  cleanup:
> > > > > >      free(vec);
> > > > > > @@ -732,11 +811,74 @@ err:
> > > > > >      return -1;
> > > > > >  }
> > > > > >
> > > > > > +int xen_vtpm_register(struct XenDevOps *ops) {
> > > > > > +    struct XenDevice *xendev;
> > > > > > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > > > > > +    char *domu;
> > > > > > +    unsigned int cdev, j, rc;
> > > > > > +    const char *type = "vtpm";
> > > > > > +    char **dev = NULL;
> > > > > > +
> > > > > > +    /*front domu*/
> > > > > > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > > > > > +    snprintf(path, sizeof(path), "%s/device/%s",
> > > > > > +             domu, type);
> > > > > > +    free(domu);
> > > > > > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > > > > > +    if (dev == NULL) {
> > > > > > +        return 0;
> > > > > > +    }
> > > > > > +
> > > > > > +    for (j = 0; j < cdev; j++) {
> > > > > > +        xendev = xen_be_get_xendev(type, xen_domid,
> > > > > > + atoi(dev[j]),
> > > > > ops);
> > > > > > +        if (xendev == NULL) {
> > > > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register
> > > > > > + xendev is
> > > > > NULL.\n");
> > > > > > +            continue;
> > > > > > +        }
> > > > > > +
> > > > > > +        if (xendev->ops->initialise) {
> > > > > > +            rc = xendev->ops->initialise(xendev);
> > > > > > +
> > > > > > +            /*if initialise failed, delete it*/
> > > > > > +            if (rc != 0) {
> > > > > > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > > > > > +                continue;
> > > > > > +            }
> > > > > > +        }
> > > > > > +
> > > > > > +        /*setup watch*/
> > > > > > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > > > > > +                 type, xen_domid, xendev->ops);
> > > > > > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > > > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register
> > > > > > + xs_watch
> > > > > failed.\n");
> > > > > > +            return -1;
> > > > > > +        }
> > > > > > +    }
> > > > > > +
> > > > > > +    free(dev);
> > > > > > +    return 0;
> > > > > > +}
> > > > >
> > > > > What does this function do? I sholdn't need  to guess from the
> > > > > code, I should be able to tell from the patch description.
> > > > >
> > > > >
> > > > > >  int xen_be_register(const char *type, struct XenDevOps *ops)  {
> > > > > >      return xenstore_scan(type, xen_domid, ops);  }
> > > > > >
> > > > > > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom,
> > > > > > +int
> > > > > remote_dom)
> > > > > > +{
> > > > > > +    xendev->local_port =
> > > > > xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > > > > > +
> > > > > remote_dom);
> > > > > > +    if (xendev->local_port == -1) {
> > > > > > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound
> > > failed\n");
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> > > > > xendev->local_port);
> > > > > > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > > > > > +                        xen_be_evtchn_event, NULL, xendev);
> > > > > > +    return 0;
> > > > > > +}
> > > > > > +
> > > > > >  int xen_be_bind_evtchn(struct XenDevice *xendev)  {
> > > > > >      if (xendev->local_port != -1) { @@ -770,6 +912,42 @@ int
> > > > > > xen_be_send_notify(struct XenDevice
> > > > > *xendev)
> > > > > >      return xc_evtchn_notify(xendev->evtchndev,
> > > > > > xendev->local_port);  }
> > > > > >
> > > > > > +int xen_vtpm_send(unsigned char *buf, size_t count) {
> > > > > > +    struct XenDevice *xendev;
> > > > > > +    int rc = -1;
> > > > > > +
> > > > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > > > +    if (xendev == NULL) {
> > > > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (xendev->ops->send) {
> > > > > > +        rc = xendev->ops->send(xendev, buf, count);
> > > > > > +    }
> > > > > > +
> > > > > > +    return rc;
> > > > > > +}
> > > > > > +
> > > > > > +int xen_vtpm_recv(unsigned char *buf, size_t *count) {
> > > > > > +    struct XenDevice *xendev;
> > > > > > +    int rc = -1;
> > > > > > +
> > > > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > > > +    if (xendev == NULL) {
> > > > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (xendev->ops->recv) {
> > > > > > +        xendev->ops->recv(xendev, buf, count);
> > > > > > +    }
> > > > > > +
> > > > > > +    return rc;
> > > > > > +}
> > > > >
> > > > > xen_backend.c is supposed to be generic, so stubdom functions
> > > > > might be OK but vtpm specific functions should not be here.
> > > > >
> > > > >
> > > > > >  /*
> > > > > >   * msg_level:
> > > > > >   *  0 == errors (stderr + logfile).
> > > > > > diff --git a/hw/xen/xen_stubdom_vtpm.c
> > > b/hw/xen/xen_stubdom_vtpm.c
> > > > > > new file mode 100644 index 0000000..0d740c1
> > > > > > --- /dev/null
> > > > > > +++ b/hw/xen/xen_stubdom_vtpm.c
> > > > > > @@ -0,0 +1,333 @@
> > > > > > +/*
> > > > > > + * Connect to Xen vTPM stubdom domain
> > > > > > + *
> > > > > > + *  Copyright (c) 2014 Intel Corporation
> > > > > > + *  Authors:
> > > > > > + *    Quan Xu <quan.xu@intel.com>
> > > > > > + *
> > > > > > + * 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 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, see
> > > > > <http://www.gnu.org/licenses/>
> > > > > > + */
> > > > > > +
> > > > > > +#include <stdio.h>
> > > > > > +#include <stdlib.h>
> > > > > > +#include <stdarg.h>
> > > > > > +#include <string.h>
> > > > > > +#include <unistd.h>
> > > > > > +#include <signal.h>
> > > > > > +#include <inttypes.h>
> > > > > > +#include <time.h>
> > > > > > +#include <fcntl.h>
> > > > > > +#include <errno.h>
> > > > > > +#include <sys/ioctl.h>
> > > > > > +#include <sys/types.h>
> > > > > > +#include <sys/stat.h>
> > > > > > +#include <sys/mman.h>
> > > > > > +#include <sys/uio.h>
> > > > > > +
> > > > > > +#include "hw/hw.h"
> > > > > > +#include "block/aio.h"
> > > > > > +#include "hw/xen/xen_backend.h"
> > > > > > +
> > > > > > +enum tpmif_state {
> > > > > > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle /
> cancel
> > > > > complete */
> > > > > > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM
> working */
> > > > > > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > > > > > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM
> > > working */
> > > > > > +};
> > > > > > +
> > > > > > +static AioContext *vtpm_aio_ctx;
> > > > > > +
> > > > > > +enum status_bits {
> > > > > > +    VTPM_STATUS_RUNNING  = 0x1,
> > > > > > +    VTPM_STATUS_IDLE     = 0x2,
> > > > > > +    VTPM_STATUS_RESULT   = 0x4,
> > > > > > +    VTPM_STATUS_CANCELED = 0x8, };
> > > > > > +
> > > > > > +struct tpmif_shared_page {
> > > > > > +    uint32_t length;         /* request/response length in
> bytes */
> > > > > > +
> > > > > > +    uint8_t  state;           /* enum tpmif_state */
> > > > > > +    uint8_t  locality;        /* for the current request */
> > > > > > +    uint8_t  pad;             /* should be zero */
> > > > > > +
> > > > > > +    uint8_t  nr_extra_pages;  /* extra pages for long
> > > > > > + packets; may be
> > > > > zero */
> > > > > > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> > > > > nr_extra_pages */
> > > > > > +};
> > > > > > +
> > > > > > +struct QEMUBH {
> > > > > > +    AioContext *ctx;
> > > > > > +    QEMUBHFunc *cb;
> > > > > > +    void *opaque;
> > > > > > +    QEMUBH *next;
> > > > > > +    bool scheduled;
> > > > > > +    bool idle;
> > > > > > +    bool deleted;
> > > > > > +};
> > > > > > +
> > > > > > +struct XenVtpmDev {
> > > > > > +    struct XenDevice xendev;  /* must be first */
> > > > > > +    struct           tpmif_shared_page *shr;
> > > > > > +    xc_gntshr        *xen_xcs;
> > > > > > +    int              ring_ref;
> > > > > > +    int              bedomid;
> > > > > > +    QEMUBH           *sr_bh;
> > > > > > +};
> > > > > > +
> > > > > > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev) {
> > > > > > +    switch (vtpmdev->shr->state) {
> > > > > > +    case TPMIF_STATE_IDLE:
> > > > > > +    case TPMIF_STATE_FINISH:
> > > > > > +        return VTPM_STATUS_IDLE;
> > > > > > +    case TPMIF_STATE_SUBMIT:
> > > > > > +    case TPMIF_STATE_CANCEL:
> > > > > > +        return VTPM_STATUS_RUNNING;
> > > > > > +    default:
> > > > > > +        return 0;
> > > > > > +    }
> > > > > > +}
> > > > > > +
> > > > > > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> > > > > xenbus_state xbus)
> > > > > > +{
> > > > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > > > +
> > > > > > +    if (xendev->fe_state == xbus) {
> > > > > > +        return 0;
> > > > > > +    }
> > > > > > +
> > > > > > +    xendev->fe_state = xbus;
> > > > > > +
> > > > > > +retry_transaction:
> > > > > > +    xbt = xs_transaction_start(xenstore);
> > > > > > +    if (xbt == XBT_NULL) {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > > > +        if (errno == EAGAIN) {
> > > > > > +            goto retry_transaction;
> > > > > > +        }
> > > > > > +    }
> > > > > > +
> > > > > > +    return 0;
> > > > > > +
> > > > > > +abort_transaction:
> > > > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > > > +    return -1;
> > > > > > +}
> > > > > > +
> > > > > > +static int vtpm_aio_wait(QEMUBH *qbh) {
> > > > > > +    return aio_poll(qbh->ctx, true); }
> > > > > > +
> > > > > > +static void sr_bh_handler(void *opaque) { }
> > > > > > +
> > > > > > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf,
> > > > > > +size_t
> > > > > *count)
> > > > > > +{
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > > > +    unsigned int offset;
> > > > > > +
> > > > > > +    if (shr->state == TPMIF_STATE_IDLE) {
> > > > > > +        return -ECANCELED;
> > > > > > +    }
> > > > > > +
> > > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > > +    }
> > > > > > +
> > > > > > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > > > > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > > > > > +    *count = shr->length;
> > > > > > +
> > > > > > +    return 0;
> > > > > > +}
> > > > > > +
> > > > > > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf,
> > > > > > +size_t
> > > > > count)
> > > > > > +{
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > > > +    unsigned int offset = sizeof(*shr) +
> > > > > > + 4*shr->nr_extra_pages;
> > > > > > +
> > > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > > +    }
> > > > > > +
> > > > > > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > > > > > +    shr->length = count;
> > > > > > +    barrier();
> > > > > > +    shr->state = TPMIF_STATE_SUBMIT;
> > > > > > +    xen_wmb();
> > > > > > +    xen_be_send_notify(&vtpmdev->xendev);
> > > > > > +
> > > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > > +    }
> > > > > > +
> > > > > > +    return count;
> > > > > > +}
> > > > > > +
> > > > > > +static int vtpm_initialise(struct XenDevice *xendev) {
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > > > +    unsigned int ring_ref;
> > > > > > +
> > > > > > +    vtpmdev->xendev.fe =
> > > > > > + xenstore_read_be_str(&vtpmdev->xendev,
> > > > > "frontend");
> > > > > > +    if (vtpmdev->xendev.fe == NULL) {
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    /* Get backend domid */
> > > > > > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > > > > > +                             &vtpmdev->bedomid)) {
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    /*alloc share page*/
> > > > > > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> > > > > vtpmdev->bedomid, 1,
> > > > > > +                                         &ring_ref,
> > > > > PROT_READ|PROT_WRITE);
> > > > > > +    vtpmdev->ring_ref = ring_ref;
> > > > > > +    if (vtpmdev->shr == NULL) {
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    /*Create event channel */
> > > > > > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> > > > > vtpmdev->bedomid)) {
> > > > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr,
> 1);
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > > > > > +                     vtpmdev->xendev.local_port);
> > > > > > +
> > > > > > +again:
> > > > > > +    xbt = xs_transaction_start(xenstore);
> > > > > > +    if (xbt == XBT_NULL) {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > > > > > +                           vtpmdev->ring_ref)) {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > > > > > +                           vtpmdev->xendev.local_port)) {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    /* Publish protocol v2 feature */
> > > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe,
> > > > > > + "feature-protocol-v2", 1))
> > > > > {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > > > +        if (errno == EAGAIN) {
> > > > > > +            goto again;
> > > > > > +        }
> > > > > > +    }
> > > > > > +    /* Tell vtpm backend that we are ready */
> > > > > > +    xenbus_switch_state(&vtpmdev->xendev,
> > > > > > + XenbusStateInitialised);
> > > > > > +
> > > > > > +    return 0;
> > > > > > +
> > > > > > +abort_transaction:
> > > > > > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > > > +    return -1;
> > > > > > +}
> > > > > > +
> > > > > > +static void vtpm_backend_changed(struct XenDevice *xendev,
> > > > > > +const char
> > > > > *node)
> > > > > > +{
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +    int be_state;
> > > > > > +
> > > > > > +    if (strcmp(node, "state") == 0) {
> > > > > > +        xenstore_read_be_int(&vtpmdev->xendev, node,
> > > &be_state);
> > > > > > +        switch (be_state) {
> > > > > > +        case XenbusStateConnected:
> > > > > > +            /*TODO*/
> > > > > > +            break;
> > > > > > +        case XenbusStateClosing:
> > > > > > +        case XenbusStateClosed:
> > > > > > +            xenbus_switch_state(&vtpmdev->xendev,
> > > > > XenbusStateClosing);
> > > > > > +            break;
> > > > > > +        default:
> > > > > > +            break;
> > > > > > +        }
> > > > > > +    }
> > > > > > +}
> > > > > > +
> > > > > > +static int vtpm_free(struct XenDevice *xendev) {
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > > > > > +
> > > > > > +    aio_poll(qbh->ctx, false);
> > > > > > +    qemu_bh_delete(vtpmdev->sr_bh);
> > > > > > +    if (vtpmdev->shr) {
> > > > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr,
> 1);
> > > > > > +    }
> > > > > > +    xc_interface_close(vtpmdev->xen_xcs);
> > > > > > +    return 0;
> > > > > > +}
> > > > > > +
> > > > > > +static void vtpm_alloc(struct XenDevice *xendev) {
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +
> > > > > > +    vtpm_aio_ctx = aio_context_new(NULL);
> > > > > > +    if (vtpm_aio_ctx == NULL) {
> > > > > > +        return;
> > > > > > +    }
> > > > > > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx,
> sr_bh_handler,
> > > > > vtpmdev);
> > > > > > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > > > > > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0); }
> > > > > > +
> > > > > > +static void vtpm_event(struct XenDevice *xendev) {
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +
> > > > > > +    qemu_bh_schedule(vtpmdev->sr_bh); }
> > > > > > +
> > > > > > +struct XenDevOps xen_vtpmdev_ops = {
> > > > > > +    .size             = sizeof(struct XenVtpmDev),
> > > > > > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > > > > > +                        DEVOPS_FLAG_STUBDOM_BE,
> > > > > > +    .event            = vtpm_event,
> > > > > > +    .free             = vtpm_free,
> > > > > > +    .alloc            = vtpm_alloc,
> > > > > > +    .initialise       = vtpm_initialise,
> > > > > > +    .backend_changed  = vtpm_backend_changed,
> > > > > > +    .recv             = vtpm_recv,
> > > > > > +    .send             = vtpm_send,
> > > > > > +};
> > > > >
> > > > > Is this the frontend, like the subject line would seem to imply?
> > > > > If so, XenDevOps are made for backends, while this is a
> > > > > frontend. In fact this is the first PV frontend in QEMU. We need
> > > > > to introduce something generic and similar to struct XenDevOps
> > > > > and xen_backend.c but for frontends.
> > > > >
> > > > >
> > > > > > diff --git a/include/hw/xen/xen_backend.h
> > > > > b/include/hw/xen/xen_backend.h
> > > > > > index 3b4125e..45fd6d3 100644
> > > > > > --- a/include/hw/xen/xen_backend.h
> > > > > > +++ b/include/hw/xen/xen_backend.h
> > > > > > @@ -15,6 +15,8 @@ struct XenDevice;
> > > > > >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> > > > > >  /* don't expect frontend doing correct state transitions (aka
> > > > > > console
> > > > > quirk) */
> > > > > >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > > > > > +/*dev backend is stubdom*/
> > > > > > +#define DEVOPS_FLAG_STUBDOM_BE    4
> > > > > >
> > > > > >  struct XenDevOps {
> > > > > >      size_t    size;
> > > > > > @@ -26,6 +28,8 @@ struct XenDevOps {
> > > > > >      void      (*event)(struct XenDevice *xendev);
> > > > > >      void      (*disconnect)(struct XenDevice *xendev);
> > > > > >      int       (*free)(struct XenDevice *xendev);
> > > > > > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf,
> size_t
> > > > > count);
> > > > > > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf,
> size_t
> > > > > *count);
> > > > > >      void      (*backend_changed)(struct XenDevice *xendev,
> const
> > > > > char *node);
> > > > > >      void      (*frontend_changed)(struct XenDevice *xendev,
> const
> > > > > char *node);
> > > > > >  };
> > > > > > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> > > > > *xendev);
> > > > > >  void xen_be_printf(struct XenDevice *xendev, int msg_level,
> > > > > > const char
> > > > > *fmt, ...)
> > > > > >      GCC_FMT_ATTR(3, 4);
> > > > > >
> > > > > > +/*Xen stubdom vtpm*/
> > > > > > +int xen_vtpm_register(struct XenDevOps *ops); int
> > > > > > +xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > > > > remote_dom);
> > > > > > +int xen_vtpm_send(unsigned char *buf, size_t count); int
> > > > > > +xen_vtpm_recv(unsigned char *buf, size_t *count);
> > > > > > +
> > > > > >  /* actual backend drivers */
> > > > > >  extern struct XenDevOps xen_console_ops;      /*
> xen_console.c
> > > > > */
> > > > > >  extern struct XenDevOps xen_kbdmouse_ops;     /*
> > > xen_framebuffer.c
> > > > > */
> > > > > >  extern struct XenDevOps xen_framebuffer_ops;  /*
> > > xen_framebuffer.c */
> > > > > >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> > > > > */
> > > > > >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> > > > > */
> > > > > > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> > > > > xen_stubdom_vtpm.c*/
> > > > > >
> > > > > >  void xen_init_display(int domid);
> > > > > >
> > > > > > diff --git a/include/hw/xen/xen_common.h
> > > > > b/include/hw/xen/xen_common.h
> > > > > > index 95612a4..fb43084 100644
> > > > > > --- a/include/hw/xen/xen_common.h
> > > > > > +++ b/include/hw/xen/xen_common.h
> > > > > > @@ -130,6 +130,12 @@ static inline XenXC
> > > > > > xen_xc_interface_open(void
> > > > > *logger, void *dombuild_logger,
> > > > > >      return xc_interface_open(logger, dombuild_logger,
> > > > > > open_flags);  }
> > > > > >
> > > > > > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > > > > > +                                           unsigned int
> > > > > > +open_flags) {
> > > > > > +    return xc_gntshr_open(logger, open_flags); }
> > > > > > +
> > > > > >  /* FIXME There is now way to have the xen fd */  static
> > > > > > inline int xc_fd(xc_interface *xen_xc)  { diff --git
> > > > > > a/xen-hvm.c b/xen-hvm.c index 21f1cbb..c99ace8 100644
> > > > > > --- a/xen-hvm.c
> > > > > > +++ b/xen-hvm.c
> > > > > > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> > > > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > > > >      int i, rc;
> > > > > >      unsigned long ioreq_pfn;
> > > > > >      unsigned long bufioreq_evtchn;
> > > > > > +
> > > > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > > > +    unsigned long stubdom_vtpm = 0; #endif
> > > > > > +
> > > > > >      XenIOState *state;
> > > > > >
> > > > > >      state = g_malloc0(sizeof (XenIOState)); @@ -1169,6
> > > > > > +1174,14 @@ int xen_hvm_init(ram_addr_t
> > > > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > > > >          fprintf(stderr, "%s: xen backend core setup
> > > > > > failed\n",
> > > > > __FUNCTION__);
> > > > > >          return -1;
> > > > > >      }
> > > > > > +
> > > > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > > > +    xc_get_hvm_param(xen_xc, xen_domid,
> > > > > HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > > > > > +    if (stubdom_vtpm) {
> > > > > > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > > > > > +    }
> > > > > > +#endif
> > > > >
> > > > > Given that vtpm is just a PV frontend, can't you just detect
> > > > > whether is present on xenstore and initialize it based on that?
> > > > > Like all the backend below?
> > > >
> > > > Also I will explain in my next email.
> > > >
> > > >
> > > > >
> > > > >
> > > > > >      xen_be_register("console", &xen_console_ops);
> > > > > >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> > > > > >      xen_be_register("qdisk", &xen_blkdev_ops);
> > > > > > --
> > > > > > 1.8.3.2
> > > > > >
> > > >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 00:11:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 00:11:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmAfy-0004ty-FF; Thu, 06 Nov 2014 00:11:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmAfw-0004tm-Eu
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 00:11:44 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	DB/51-29352-FBCBA545; Thu, 06 Nov 2014 00:11:43 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415232693!6060515!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3338 invoked from network); 6 Nov 2014 00:11:41 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-14.tower-206.messagelabs.com with SMTP;
	6 Nov 2014 00:11:41 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 05 Nov 2014 16:11:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,322,1413270000"; d="scan'208";a="627327987"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by fmsmga002.fm.intel.com with ESMTP; 05 Nov 2014 16:11:16 -0800
Received: from pgsmsx108.gar.corp.intel.com (10.221.44.103) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 08:10:48 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 08:10:48 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.156]) with mapi id
	14.03.0195.001; Thu, 6 Nov 2014 08:10:47 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP91zOKlhH4xypD06jTqC2+4O7eZxQng+ggAC8ygCAAMpkkP//sUyAgADmo8A=
Date: Thu, 6 Nov 2014 00:10:46 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820463@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81F888@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411051036310.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8202B7@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411051821510.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411051821510.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Thursday, November 06, 2014 2:24 AM
> To: Xu, Quan
> Cc: Stefano Stabellini; qemu-devel@nongnu.org; xen-devel@lists.xen.org
> Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> On Wed, 5 Nov 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Wednesday, November 05, 2014 7:01 PM
> > > To: Xu, Quan
> > > Cc: Stefano Stabellini; qemu-devel@nongnu.org;
> > > xen-devel@lists.xen.org
> > > Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > > frontend driver
> > >
> > > On Tue, 4 Nov 2014, Xu, Quan wrote:
> > > > > -----Original Message-----
> > > > > From: Stefano Stabellini
> > > > > [mailto:stefano.stabellini@eu.citrix.com]
> > > > > Sent: Monday, November 03, 2014 7:54 PM
> > > > > To: Xu, Quan
> > > > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > > > > stefano.stabellini@eu.citrix.com
> > > > > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
> > > > > vTPM frontend driver
> > > > >
> > > > > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > > > > This drvier transfers any request/repond between TPM
> > > > > > xenstubdoms driver and Xen vTPM stubdom, and facilitates
> > > > > > communications between Xen vTPM stubdom domain and vTPM
> > > > > > xenstubdoms driver
> > > > > >
> > > > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > > >
> > > > > Please describe what changes did make to xen_backend.c and why.
> > > > > The commit message should contains info on all the changes made
> > > > > by the patch below.
> > > > >
> > > >
> > > > Thanks Stefano.
> > > > one more day, I will explain in detail what changes did make to
> > > > xen_backend.c and why.
> > > > The following 2 sections are introduction and architecture.
> > > >
> > > > > Please also describe what is the "Xen vTPM stubdom", what is the
> > > > > "vTPM xenstubdoms driver" and how the communicate with each
> others.
> > > > >
> > > >
> > > >
> > > > Add 2 parts for detailed descriptions, introduction and architecture.
> > > >
> > > > *INTRODUCTION*
> > > >
> > > > The goal of virtual Trusted Platform Module (vTPM) is to provide a
> > > > TPM functionality to virtual machines (Fedora, Ubuntu, Redhat,
> > > > Windows .etc). This allows programs to interact with a TPM in a
> > > > virtual machine the same way they interact with a TPM on the physical
> system.
> > > Each virtual machine gets its own unique, emulated, software TPM.
> > > > Each major component of vTPM is implemented as a stubdom,
> > > > providing secure separation guaranteed by the hypervisor.
> > > > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for
> > > > the virtual machine to use. It is a small wrapper around the
> > > > Berlios TPM emulator. TPM commands are passed from mini-os TPM
> backend driver.
> > > > This patch series are only the Qemu part to enable Xen stubdom
> > > > vTPM for HVM virtual machine.
> > > > ===========
> > > >
> > > > *ARCHITECTURE*
> > > >
> > > > The architecture of stubdom vTPM for HVM virtual machine:
> > > >
> > > >             +--------------------+
> > > >             | Windows/Linux DomU | ...
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |  Qemu tpm1.2 Tis   |
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |        vTPM        |
> > > >             | XenStubdoms driver |  (new ..)
> > > >             +--------------------+
> > > >                      |  ^
> > > >                      v  |
> > > >             +--------------------+
> > > >             |  xen_vtpmdev_ops   |  (new ..)
> > > >             +--------------------+
> > > >                      |  ^
> > > >                      v  |
> > > >             +--------------------+
> > > >             |  mini-os/tpmback   |
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |   vTPM stubdom     | ...
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |  mini-os/tpmfront  |
> > > >             +--------------------+
> > > >                      |  ^
> > > >                      v  |
> > > >             +--------------------+
> > > >             |  mini-os/tpmback   |
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |  vtpmmgr stubdom   |
> > > >             |        |  ^        |
> > > >             |        v  |        |
> > > >             |  mini-os/tpm_tis   |
> > > >             +--------------------+
> > > >                      |  ^
> > > >                      v  |
> > > >             +--------------------+
> > > >             |    Hardware TPM    |
> > > >             +--------------------+
> > > >
> > > >
> > > > * Windows/Linux DomU:
> > > >     The HVM based guest that wants to use a vTPM. There may be
> > > >     more than one of these.
> > > >
> > > >  * Qemu tpm1.2 Tis:
> > > >     Implementation of the tpm1.2 Tis interface for HVM virtual
> > > >     machines. It is Qemu emulation device.
> > >
> > > It looks like you are running upstream QEMU within a Mini-OS stubdom?
> > > If so, where are the patches to do that? As far as I know upstream
> > > QEMU doesn't run on Mini-OS. Or maybe it is a Linux stubdom? Either
> > > way, it is not clear.
> >
> > Not so.
> > Refer to below further explanation.
> >
> > >
> > >
> > > >  * vTPM xenstubdoms driver:
> > > >     Similar to a TPM passthrough backend driver, it is a new TPM
> > > >     backend for emulated TPM TIS interface. This driver provides
> > > >     vTPM initialization and sending data and commends to a Xen
> > > >     vTPM stubdom.
> > >
> > > This is patch #3, right? It is basically the internal QEMU "glue" to
> > > connect the tpm emulator to xen_vtpmdev_ops, correct?
> > >
> >
> > Yes, it is Patch #3. Agree with your description.  :)
> >
> > >
> > > >  * xen_vtpmdev_ops:
> > > >     Register Xen stubdom vTPM backend, and transfer any request/
> > > >     repond between TPM xenstubdoms driver and Xen vTPM
> stubdom.
> > > >     Facilitate communications between Xen vTPM stubdom and vTPM
> > > >     xenstubdoms driver.
> > >
> > > It looks like this correspond to patch #2? If so, this is a regular
> > > Xen PV
> >
> > Yes, it patch #2.
> >
> >
> > > frontend, living in QEMU? It requires the gntalloc device so I guess
> > > it is supposed to run on Linux. In that case is it just a tpmfront
> > > implementation in QEMU?
> > >
> >
> >
> > Yes, it's tpmfront implementation in Qemu. also it supports PV Linux since
> Xen 4.3.0.
> > vTPM stubdom / vtpmmgr stubdom  ware implemented by Matthew
> Fioravante
> > (JHUAPL), Linux pv vTPM frontend was implemented by Daniel De Graaf
> > (NSA)
> >
> >
> >
> > > If you are running it on Linux, we might need to introduce Linux
> > > based stundoms to the Xen build system.
> >
> > Not so.
> > Maybe I should explain a bit further. TPM is a character device. 'Qemu
> tpm1.2 Tis'
> > Implement some TPM register hook of TPM, and enable TIS (TPM interface
> Specification).
> > The ' Qemu tpm1.2 Tis ' should deal with TPM commands.
> >
> > Such as TPM_ContinueSelfTest command,
> >     { 0x00, 0xc1, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x53}; If
> > success, the TPM will respond,
> >     { 0x00, 0xc4, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x00};
> >
> > Qemu upstream has supported TPM passthrough. actually, 'Qemu TPM
> > passthrough' send These TPM commands from "Qemu tpm1.2 Tis" to TPM
> hardware, and get the respond.
> >
> > " [PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for HVM
> virtual
> > machine " send These TPM commands from "Qemu tpm1.2 Tis" to Xen
> > stubdom( explain in previous email) And get the respond.
> >
> > #(qemu-system-* --tpmdev help)
> > #(passthrough   Passthrough TPM backend driver)
> > #( xenstubdoms  Xenstubdoms TPM backend driver)
> >
> > The following is Qemu part.
> >
> >             |        |  ^       |
> >             |        v  |       |
> >             |        vTPM      |
> >             | XenStubdoms driver |  (new ..)
> >             +------------------------------+
> >                      |  ^
> >                      v  |
> >             +------------------------------+
> >             |  xen_vtpmdev_ops  |  (new ..)
> >             +------------------------------+ "vTPM XenStubdoms driver"
> > and "xen_vtpmdev_ops" are implemented to send These TPM commands
> from
> > "Qemu tpm1.2 Tis" to Xen stubdom.
> 
> OK, so if I understand correctly in your architecture QEMU is running in
> Dom0 as usual, right?

Yes, 

> 
> 
> 
> > >
> > > >  * mini-os/tpmback:
> > > >     Mini-os TPM backend driver. The Linux frontend driver connects
> > > >     to this backend driver to facilitate communications between the
> > > >     Linux DomU and its vTPM. This driver is also used by vtpmmgr
> > > >     stubdom to communicate with vTPM stubdom.
> > > >
> > > >  * vTPM stubdom:
> > > >     A mini-os stub domain that implements a vTPM. There is a
> > > >     one to one mapping between running vTPM stubdom instances
> and
> > > >     logical vTPMs on the system. The vTPM Platform Configuration
> > > >     Registers (PCRs) are all initialized to zero.
> > > >
> > > >  * mini-os/tpmfront:
> > > >     Mini-os TPM frontend driver. The vTPM mini-os domain vTPM
> > > >     stubdom uses this driver to communicate with
> vtpmmgr-stubdom.
> > > >     This driver could also be used separately to implement a mini-os
> > > >     domain that wishes to use a vTPM of its own.
> > > >
> > > >  * vtpmmgr stubdom:
> > > >     A mini-os domain that implements the vTPM manager. There is
> only
> > > >     one vTPM manager and it should be running during the entire
> lifetime
> > > >     of the machine. vtpmmgr domain securely stores encryption keys
> for
> > > >     each of the vTPMs and accesses to the hardware TPM to get the
> > > > root
> > > of
> > > >     trust for the entire system.
> > > >
> > > >  * mini-os/tpm_tis:
> > > >     Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
> > > >     This driver used by vtpmmgr-stubdom to talk directly to the
> hardware
> > > >     TPM. Communication is facilitated by mapping hardware memory
> > > pages
> > > >     into vtpmmgr stubdom.
> > >
> > > Are all the Mini-OS component upstream, or do we need patches?
> > >
> > >
> > > >  * Hardware TPM:
> > > >     The physical TPM 1.2 that is soldered onto the motherboard.
> > > >
> > > > ===========
> > > >
> > > >
> > > >
> > > > > Where does the vTPM backend lives?
> > > > The vTPM backend lives in Xen vTPM stubdom (Xen Mini-os)
> > >
> > > Thanks for the explanation, it is a bit clearer now.
> > >
> >
> >
> > Welcome, thanks for your careful review.
> >
> >
> >
> > >
> > > > >
> > > > >
> > > > > >  hw/xen/Makefile.objs         |   1 +
> > > > > >  hw/xen/xen_backend.c         | 182
> ++++++++++++++++++++++-
> > > > > >  hw/xen/xen_stubdom_vtpm.c    | 333
> > > > > +++++++++++++++++++++++++++++++++++++++++++
> > > > > >  include/hw/xen/xen_backend.h |  11 ++
> > > > > >  include/hw/xen/xen_common.h  |   6 +
> > > > > >  xen-hvm.c                    |  13 ++
> > > > > >  6 files changed, 544 insertions(+), 2 deletions(-)  create
> > > > > > mode
> > > > > > 100644 hw/xen/xen_stubdom_vtpm.c
> > > > > >
> > > > > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs index
> > > > > > a0ca0aa..724df8d 100644
> > > > > > --- a/hw/xen/Makefile.objs
> > > > > > +++ b/hw/xen/Makefile.objs
> > > > > > @@ -1,5 +1,6 @@
> > > > > >  # xen backend driver support
> > > > > >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> > > > > xen_devconfig.o
> > > > > > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) +=
> > > xen_stubdom_vtpm.o
> > > > > >
> > > > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> > > > > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> > > > > xen_pt_config_init.o xen_pt_msi.o
> > > > > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index
> > > > > > b2cb22b..45a5778 100644
> > > > > > --- a/hw/xen/xen_backend.c
> > > > > > +++ b/hw/xen/xen_backend.c
> > > > > > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice
> > > > > > *xendev,
> > > > > enum xenbus_state state)
> > > > > >      return 0;
> > > > > >  }
> > > > > >
> > > > > > +/*get stubdom backend*/
> > > > > > +static char *xen_stubdom_be(const char *type, int dom, int dev) {
> > > > > > +    char *val, *domu;
> > > > > > +    char path[XEN_BUFSIZE];
> > > > > > +    unsigned int len, ival;
> > > > > > +
> > > > > > +    /*front domu*/
> > > > > > +    domu = xs_get_domain_path(xenstore, dom);
> > > > > > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > > > > > +             domu, type, dev);
> > > > > > +    g_free(domu);
> > > > > > +
> > > > > > +    val = xs_read(xenstore, 0, path, &len);
> > > > > > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > > > > > +        g_free(val);
> > > > > > +        return NULL;
> > > > > > +    }
> > > > > > +    g_free(val);
> > > > > > +
> > > > > > +    /*backend domu*/
> > > > > > +    domu = xs_get_domain_path(xenstore, ival);
> > > > > > +
> > > > > > +    return domu;
> > > > > > +}
> > > > > > +
> > > > > >  /*
> > > > > > -------------------------------------------------------------
> > > > > > */
> > > > > >
> > > > > >  struct XenDevice *xen_be_find_xendev(const char *type, int
> > > > > > dom, int
> > > > > dev)
> > > > > > @@ -222,6 +248,7 @@ static struct XenDevice
> > > > > > *xen_be_get_xendev(const
> > > > > char *type, int dom, int dev,
> > > > > >                                             struct
> XenDevOps
> > > *ops)
> > > > > > {
> > > > > >      struct XenDevice *xendev;
> > > > > > +    char *stub;
> > > > > >
> > > > > >      xendev = xen_be_find_xendev(type, dom, dev);
> > > > > >      if (xendev) {
> > > > > > @@ -235,8 +262,15 @@ static struct XenDevice
> > > > > *xen_be_get_xendev(const char *type, int dom, int dev,
> > > > > >      xendev->dev   = dev;
> > > > > >      xendev->ops   = ops;
> > > > > >
> > > > > > -    snprintf(xendev->be, sizeof(xendev->be),
> "backend/%s/%d/%d",
> > > > > > -             xendev->type, xendev->dom, xendev->dev);
> > > > > > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > > > > > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> > > > > xendev->dev);
> > > > > > +        snprintf(xendev->be, sizeof(xendev->be),
> > > > > "%s/backend/%s/%d/%d",
> > > > > > +                 stub, xendev->type, xendev->dom,
> xendev->dev);
> > > > > > +        g_free(stub);
> > > > > > +    } else {
> > > > > > +        snprintf(xendev->be, sizeof(xendev->be),
> > > "backend/%s/%d/%d",
> > > > > > +                 xendev->type, xendev->dom, xendev->dev);
> > > > > > +    }
> > > > > >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> > > > > >               xendev->type, xendev->dev);
> > > > > >
> > > > > > @@ -611,6 +645,47 @@ static int xenstore_scan(const char
> > > > > > *type, int
> > > > > dom, struct XenDevOps *ops)
> > > > > >      return 0;
> > > > > >  }
> > > > > >
> > > > > > +static void stubdom_update_be(char *watch, char *type, int dom,
> > > > > > +                              struct XenDevOps *ops) {
> > > > > > +    struct XenDevice *xendev;
> > > > > > +    char path[XEN_BUFSIZE];
> > > > > > +    char *ptr, *bepath;
> > > > > > +    unsigned int len, dev;
> > > > > > +
> > > > > > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > > > > > +        return;
> > > > > > +    }
> > > > > > +
> > > > > > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type,
> dom);
> > > > > > +    ptr = strstr(watch, path);
> > > > > > +    if (ptr == NULL) {
> > > > > > +        return;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > > > > > +        strcpy(path, "");
> > > > > > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > > > > > +            dev = -1;
> > > > > > +        }
> > > > > > +    }
> > > > > > +
> > > > > > +    if (dev == -1) {
> > > > > > +        return;
> > > > > > +    }
> > > > > > +
> > > > > > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > > > > > +    if (xendev != NULL) {
> > > > > > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > > > > > +        if (bepath == NULL) {
> > > > > > +            xen_be_del_xendev(dom, dev);
> > > > > > +        } else {
> > > > > > +            free(bepath);
> > > > > > +            xen_be_backend_changed(xendev, path);
> > > > > > +        }
> > > > > > +    }
> > > > > > +}
> > > > > > +
> > > > > >  static void xenstore_update_be(char *watch, char *type, int dom,
> > > > > >                                 struct XenDevOps *ops)
> { @@
> > > > > > -681,6 +756,10 @@ static void xenstore_update(void *unused)
> > > > > >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1)
> {
> > > > > >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> > > > > >      }
> > > > > > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> > > > > PRIxPTR,
> > > > > > +               &type, &dom, &ops) == 3) {
> > > > > > +        stubdom_update_be(vec[XS_WATCH_PATH], (void
> *)type,
> > > dom,
> > > > > (void *)ops);
> > > > > > +    }
> > > > > >
> > > > > >  cleanup:
> > > > > >      free(vec);
> > > > > > @@ -732,11 +811,74 @@ err:
> > > > > >      return -1;
> > > > > >  }
> > > > > >
> > > > > > +int xen_vtpm_register(struct XenDevOps *ops) {
> > > > > > +    struct XenDevice *xendev;
> > > > > > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > > > > > +    char *domu;
> > > > > > +    unsigned int cdev, j, rc;
> > > > > > +    const char *type = "vtpm";
> > > > > > +    char **dev = NULL;
> > > > > > +
> > > > > > +    /*front domu*/
> > > > > > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > > > > > +    snprintf(path, sizeof(path), "%s/device/%s",
> > > > > > +             domu, type);
> > > > > > +    free(domu);
> > > > > > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > > > > > +    if (dev == NULL) {
> > > > > > +        return 0;
> > > > > > +    }
> > > > > > +
> > > > > > +    for (j = 0; j < cdev; j++) {
> > > > > > +        xendev = xen_be_get_xendev(type, xen_domid,
> > > > > > + atoi(dev[j]),
> > > > > ops);
> > > > > > +        if (xendev == NULL) {
> > > > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register
> > > > > > + xendev is
> > > > > NULL.\n");
> > > > > > +            continue;
> > > > > > +        }
> > > > > > +
> > > > > > +        if (xendev->ops->initialise) {
> > > > > > +            rc = xendev->ops->initialise(xendev);
> > > > > > +
> > > > > > +            /*if initialise failed, delete it*/
> > > > > > +            if (rc != 0) {
> > > > > > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > > > > > +                continue;
> > > > > > +            }
> > > > > > +        }
> > > > > > +
> > > > > > +        /*setup watch*/
> > > > > > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > > > > > +                 type, xen_domid, xendev->ops);
> > > > > > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > > > > > +            xen_be_printf(xendev, 0, "xen_vtpm_register
> > > > > > + xs_watch
> > > > > failed.\n");
> > > > > > +            return -1;
> > > > > > +        }
> > > > > > +    }
> > > > > > +
> > > > > > +    free(dev);
> > > > > > +    return 0;
> > > > > > +}
> > > > >
> > > > > What does this function do? I sholdn't need  to guess from the
> > > > > code, I should be able to tell from the patch description.
> > > > >
> > > > >
> > > > > >  int xen_be_register(const char *type, struct XenDevOps *ops)  {
> > > > > >      return xenstore_scan(type, xen_domid, ops);  }
> > > > > >
> > > > > > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom,
> > > > > > +int
> > > > > remote_dom)
> > > > > > +{
> > > > > > +    xendev->local_port =
> > > > > xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > > > > > +
> > > > > remote_dom);
> > > > > > +    if (xendev->local_port == -1) {
> > > > > > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound
> > > failed\n");
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> > > > > xendev->local_port);
> > > > > > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > > > > > +                        xen_be_evtchn_event, NULL, xendev);
> > > > > > +    return 0;
> > > > > > +}
> > > > > > +
> > > > > >  int xen_be_bind_evtchn(struct XenDevice *xendev)  {
> > > > > >      if (xendev->local_port != -1) { @@ -770,6 +912,42 @@ int
> > > > > > xen_be_send_notify(struct XenDevice
> > > > > *xendev)
> > > > > >      return xc_evtchn_notify(xendev->evtchndev,
> > > > > > xendev->local_port);  }
> > > > > >
> > > > > > +int xen_vtpm_send(unsigned char *buf, size_t count) {
> > > > > > +    struct XenDevice *xendev;
> > > > > > +    int rc = -1;
> > > > > > +
> > > > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > > > +    if (xendev == NULL) {
> > > > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (xendev->ops->send) {
> > > > > > +        rc = xendev->ops->send(xendev, buf, count);
> > > > > > +    }
> > > > > > +
> > > > > > +    return rc;
> > > > > > +}
> > > > > > +
> > > > > > +int xen_vtpm_recv(unsigned char *buf, size_t *count) {
> > > > > > +    struct XenDevice *xendev;
> > > > > > +    int rc = -1;
> > > > > > +
> > > > > > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > > > > > +    if (xendev == NULL) {
> > > > > > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (xendev->ops->recv) {
> > > > > > +        xendev->ops->recv(xendev, buf, count);
> > > > > > +    }
> > > > > > +
> > > > > > +    return rc;
> > > > > > +}
> > > > >
> > > > > xen_backend.c is supposed to be generic, so stubdom functions
> > > > > might be OK but vtpm specific functions should not be here.
> > > > >
> > > > >
> > > > > >  /*
> > > > > >   * msg_level:
> > > > > >   *  0 == errors (stderr + logfile).
> > > > > > diff --git a/hw/xen/xen_stubdom_vtpm.c
> > > b/hw/xen/xen_stubdom_vtpm.c
> > > > > > new file mode 100644 index 0000000..0d740c1
> > > > > > --- /dev/null
> > > > > > +++ b/hw/xen/xen_stubdom_vtpm.c
> > > > > > @@ -0,0 +1,333 @@
> > > > > > +/*
> > > > > > + * Connect to Xen vTPM stubdom domain
> > > > > > + *
> > > > > > + *  Copyright (c) 2014 Intel Corporation
> > > > > > + *  Authors:
> > > > > > + *    Quan Xu <quan.xu@intel.com>
> > > > > > + *
> > > > > > + * 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 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, see
> > > > > <http://www.gnu.org/licenses/>
> > > > > > + */
> > > > > > +
> > > > > > +#include <stdio.h>
> > > > > > +#include <stdlib.h>
> > > > > > +#include <stdarg.h>
> > > > > > +#include <string.h>
> > > > > > +#include <unistd.h>
> > > > > > +#include <signal.h>
> > > > > > +#include <inttypes.h>
> > > > > > +#include <time.h>
> > > > > > +#include <fcntl.h>
> > > > > > +#include <errno.h>
> > > > > > +#include <sys/ioctl.h>
> > > > > > +#include <sys/types.h>
> > > > > > +#include <sys/stat.h>
> > > > > > +#include <sys/mman.h>
> > > > > > +#include <sys/uio.h>
> > > > > > +
> > > > > > +#include "hw/hw.h"
> > > > > > +#include "block/aio.h"
> > > > > > +#include "hw/xen/xen_backend.h"
> > > > > > +
> > > > > > +enum tpmif_state {
> > > > > > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle /
> cancel
> > > > > complete */
> > > > > > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM
> working */
> > > > > > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > > > > > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM
> > > working */
> > > > > > +};
> > > > > > +
> > > > > > +static AioContext *vtpm_aio_ctx;
> > > > > > +
> > > > > > +enum status_bits {
> > > > > > +    VTPM_STATUS_RUNNING  = 0x1,
> > > > > > +    VTPM_STATUS_IDLE     = 0x2,
> > > > > > +    VTPM_STATUS_RESULT   = 0x4,
> > > > > > +    VTPM_STATUS_CANCELED = 0x8, };
> > > > > > +
> > > > > > +struct tpmif_shared_page {
> > > > > > +    uint32_t length;         /* request/response length in
> bytes */
> > > > > > +
> > > > > > +    uint8_t  state;           /* enum tpmif_state */
> > > > > > +    uint8_t  locality;        /* for the current request */
> > > > > > +    uint8_t  pad;             /* should be zero */
> > > > > > +
> > > > > > +    uint8_t  nr_extra_pages;  /* extra pages for long
> > > > > > + packets; may be
> > > > > zero */
> > > > > > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> > > > > nr_extra_pages */
> > > > > > +};
> > > > > > +
> > > > > > +struct QEMUBH {
> > > > > > +    AioContext *ctx;
> > > > > > +    QEMUBHFunc *cb;
> > > > > > +    void *opaque;
> > > > > > +    QEMUBH *next;
> > > > > > +    bool scheduled;
> > > > > > +    bool idle;
> > > > > > +    bool deleted;
> > > > > > +};
> > > > > > +
> > > > > > +struct XenVtpmDev {
> > > > > > +    struct XenDevice xendev;  /* must be first */
> > > > > > +    struct           tpmif_shared_page *shr;
> > > > > > +    xc_gntshr        *xen_xcs;
> > > > > > +    int              ring_ref;
> > > > > > +    int              bedomid;
> > > > > > +    QEMUBH           *sr_bh;
> > > > > > +};
> > > > > > +
> > > > > > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev) {
> > > > > > +    switch (vtpmdev->shr->state) {
> > > > > > +    case TPMIF_STATE_IDLE:
> > > > > > +    case TPMIF_STATE_FINISH:
> > > > > > +        return VTPM_STATUS_IDLE;
> > > > > > +    case TPMIF_STATE_SUBMIT:
> > > > > > +    case TPMIF_STATE_CANCEL:
> > > > > > +        return VTPM_STATUS_RUNNING;
> > > > > > +    default:
> > > > > > +        return 0;
> > > > > > +    }
> > > > > > +}
> > > > > > +
> > > > > > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> > > > > xenbus_state xbus)
> > > > > > +{
> > > > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > > > +
> > > > > > +    if (xendev->fe_state == xbus) {
> > > > > > +        return 0;
> > > > > > +    }
> > > > > > +
> > > > > > +    xendev->fe_state = xbus;
> > > > > > +
> > > > > > +retry_transaction:
> > > > > > +    xbt = xs_transaction_start(xenstore);
> > > > > > +    if (xbt == XBT_NULL) {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > > > +        if (errno == EAGAIN) {
> > > > > > +            goto retry_transaction;
> > > > > > +        }
> > > > > > +    }
> > > > > > +
> > > > > > +    return 0;
> > > > > > +
> > > > > > +abort_transaction:
> > > > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > > > +    return -1;
> > > > > > +}
> > > > > > +
> > > > > > +static int vtpm_aio_wait(QEMUBH *qbh) {
> > > > > > +    return aio_poll(qbh->ctx, true); }
> > > > > > +
> > > > > > +static void sr_bh_handler(void *opaque) { }
> > > > > > +
> > > > > > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf,
> > > > > > +size_t
> > > > > *count)
> > > > > > +{
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > > > +    unsigned int offset;
> > > > > > +
> > > > > > +    if (shr->state == TPMIF_STATE_IDLE) {
> > > > > > +        return -ECANCELED;
> > > > > > +    }
> > > > > > +
> > > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > > +    }
> > > > > > +
> > > > > > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > > > > > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > > > > > +    *count = shr->length;
> > > > > > +
> > > > > > +    return 0;
> > > > > > +}
> > > > > > +
> > > > > > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf,
> > > > > > +size_t
> > > > > count)
> > > > > > +{
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > > > > > +    unsigned int offset = sizeof(*shr) +
> > > > > > + 4*shr->nr_extra_pages;
> > > > > > +
> > > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > > +    }
> > > > > > +
> > > > > > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > > > > > +    shr->length = count;
> > > > > > +    barrier();
> > > > > > +    shr->state = TPMIF_STATE_SUBMIT;
> > > > > > +    xen_wmb();
> > > > > > +    xen_be_send_notify(&vtpmdev->xendev);
> > > > > > +
> > > > > > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > > > > > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > > > > > +    }
> > > > > > +
> > > > > > +    return count;
> > > > > > +}
> > > > > > +
> > > > > > +static int vtpm_initialise(struct XenDevice *xendev) {
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +    xs_transaction_t xbt = XBT_NULL;
> > > > > > +    unsigned int ring_ref;
> > > > > > +
> > > > > > +    vtpmdev->xendev.fe =
> > > > > > + xenstore_read_be_str(&vtpmdev->xendev,
> > > > > "frontend");
> > > > > > +    if (vtpmdev->xendev.fe == NULL) {
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    /* Get backend domid */
> > > > > > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > > > > > +                             &vtpmdev->bedomid)) {
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    /*alloc share page*/
> > > > > > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> > > > > vtpmdev->bedomid, 1,
> > > > > > +                                         &ring_ref,
> > > > > PROT_READ|PROT_WRITE);
> > > > > > +    vtpmdev->ring_ref = ring_ref;
> > > > > > +    if (vtpmdev->shr == NULL) {
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    /*Create event channel */
> > > > > > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> > > > > vtpmdev->bedomid)) {
> > > > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr,
> 1);
> > > > > > +        return -1;
> > > > > > +    }
> > > > > > +
> > > > > > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > > > > > +                     vtpmdev->xendev.local_port);
> > > > > > +
> > > > > > +again:
> > > > > > +    xbt = xs_transaction_start(xenstore);
> > > > > > +    if (xbt == XBT_NULL) {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > > > > > +                           vtpmdev->ring_ref)) {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > > > > > +                           vtpmdev->xendev.local_port)) {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    /* Publish protocol v2 feature */
> > > > > > +    if (xenstore_write_int(vtpmdev->xendev.fe,
> > > > > > + "feature-protocol-v2", 1))
> > > > > {
> > > > > > +        goto abort_transaction;
> > > > > > +    }
> > > > > > +
> > > > > > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > > > > > +        if (errno == EAGAIN) {
> > > > > > +            goto again;
> > > > > > +        }
> > > > > > +    }
> > > > > > +    /* Tell vtpm backend that we are ready */
> > > > > > +    xenbus_switch_state(&vtpmdev->xendev,
> > > > > > + XenbusStateInitialised);
> > > > > > +
> > > > > > +    return 0;
> > > > > > +
> > > > > > +abort_transaction:
> > > > > > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > > > > > +    xs_transaction_end(xenstore, xbt, 1);
> > > > > > +    return -1;
> > > > > > +}
> > > > > > +
> > > > > > +static void vtpm_backend_changed(struct XenDevice *xendev,
> > > > > > +const char
> > > > > *node)
> > > > > > +{
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +    int be_state;
> > > > > > +
> > > > > > +    if (strcmp(node, "state") == 0) {
> > > > > > +        xenstore_read_be_int(&vtpmdev->xendev, node,
> > > &be_state);
> > > > > > +        switch (be_state) {
> > > > > > +        case XenbusStateConnected:
> > > > > > +            /*TODO*/
> > > > > > +            break;
> > > > > > +        case XenbusStateClosing:
> > > > > > +        case XenbusStateClosed:
> > > > > > +            xenbus_switch_state(&vtpmdev->xendev,
> > > > > XenbusStateClosing);
> > > > > > +            break;
> > > > > > +        default:
> > > > > > +            break;
> > > > > > +        }
> > > > > > +    }
> > > > > > +}
> > > > > > +
> > > > > > +static int vtpm_free(struct XenDevice *xendev) {
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > > > > > +
> > > > > > +    aio_poll(qbh->ctx, false);
> > > > > > +    qemu_bh_delete(vtpmdev->sr_bh);
> > > > > > +    if (vtpmdev->shr) {
> > > > > > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr,
> 1);
> > > > > > +    }
> > > > > > +    xc_interface_close(vtpmdev->xen_xcs);
> > > > > > +    return 0;
> > > > > > +}
> > > > > > +
> > > > > > +static void vtpm_alloc(struct XenDevice *xendev) {
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +
> > > > > > +    vtpm_aio_ctx = aio_context_new(NULL);
> > > > > > +    if (vtpm_aio_ctx == NULL) {
> > > > > > +        return;
> > > > > > +    }
> > > > > > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx,
> sr_bh_handler,
> > > > > vtpmdev);
> > > > > > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > > > > > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0); }
> > > > > > +
> > > > > > +static void vtpm_event(struct XenDevice *xendev) {
> > > > > > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> > > > > XenVtpmDev,
> > > > > > +                                              xendev);
> > > > > > +
> > > > > > +    qemu_bh_schedule(vtpmdev->sr_bh); }
> > > > > > +
> > > > > > +struct XenDevOps xen_vtpmdev_ops = {
> > > > > > +    .size             = sizeof(struct XenVtpmDev),
> > > > > > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > > > > > +                        DEVOPS_FLAG_STUBDOM_BE,
> > > > > > +    .event            = vtpm_event,
> > > > > > +    .free             = vtpm_free,
> > > > > > +    .alloc            = vtpm_alloc,
> > > > > > +    .initialise       = vtpm_initialise,
> > > > > > +    .backend_changed  = vtpm_backend_changed,
> > > > > > +    .recv             = vtpm_recv,
> > > > > > +    .send             = vtpm_send,
> > > > > > +};
> > > > >
> > > > > Is this the frontend, like the subject line would seem to imply?
> > > > > If so, XenDevOps are made for backends, while this is a
> > > > > frontend. In fact this is the first PV frontend in QEMU. We need
> > > > > to introduce something generic and similar to struct XenDevOps
> > > > > and xen_backend.c but for frontends.
> > > > >
> > > > >
> > > > > > diff --git a/include/hw/xen/xen_backend.h
> > > > > b/include/hw/xen/xen_backend.h
> > > > > > index 3b4125e..45fd6d3 100644
> > > > > > --- a/include/hw/xen/xen_backend.h
> > > > > > +++ b/include/hw/xen/xen_backend.h
> > > > > > @@ -15,6 +15,8 @@ struct XenDevice;
> > > > > >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> > > > > >  /* don't expect frontend doing correct state transitions (aka
> > > > > > console
> > > > > quirk) */
> > > > > >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > > > > > +/*dev backend is stubdom*/
> > > > > > +#define DEVOPS_FLAG_STUBDOM_BE    4
> > > > > >
> > > > > >  struct XenDevOps {
> > > > > >      size_t    size;
> > > > > > @@ -26,6 +28,8 @@ struct XenDevOps {
> > > > > >      void      (*event)(struct XenDevice *xendev);
> > > > > >      void      (*disconnect)(struct XenDevice *xendev);
> > > > > >      int       (*free)(struct XenDevice *xendev);
> > > > > > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf,
> size_t
> > > > > count);
> > > > > > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf,
> size_t
> > > > > *count);
> > > > > >      void      (*backend_changed)(struct XenDevice *xendev,
> const
> > > > > char *node);
> > > > > >      void      (*frontend_changed)(struct XenDevice *xendev,
> const
> > > > > char *node);
> > > > > >  };
> > > > > > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> > > > > *xendev);
> > > > > >  void xen_be_printf(struct XenDevice *xendev, int msg_level,
> > > > > > const char
> > > > > *fmt, ...)
> > > > > >      GCC_FMT_ATTR(3, 4);
> > > > > >
> > > > > > +/*Xen stubdom vtpm*/
> > > > > > +int xen_vtpm_register(struct XenDevOps *ops); int
> > > > > > +xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> > > > > remote_dom);
> > > > > > +int xen_vtpm_send(unsigned char *buf, size_t count); int
> > > > > > +xen_vtpm_recv(unsigned char *buf, size_t *count);
> > > > > > +
> > > > > >  /* actual backend drivers */
> > > > > >  extern struct XenDevOps xen_console_ops;      /*
> xen_console.c
> > > > > */
> > > > > >  extern struct XenDevOps xen_kbdmouse_ops;     /*
> > > xen_framebuffer.c
> > > > > */
> > > > > >  extern struct XenDevOps xen_framebuffer_ops;  /*
> > > xen_framebuffer.c */
> > > > > >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> > > > > */
> > > > > >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> > > > > */
> > > > > > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> > > > > xen_stubdom_vtpm.c*/
> > > > > >
> > > > > >  void xen_init_display(int domid);
> > > > > >
> > > > > > diff --git a/include/hw/xen/xen_common.h
> > > > > b/include/hw/xen/xen_common.h
> > > > > > index 95612a4..fb43084 100644
> > > > > > --- a/include/hw/xen/xen_common.h
> > > > > > +++ b/include/hw/xen/xen_common.h
> > > > > > @@ -130,6 +130,12 @@ static inline XenXC
> > > > > > xen_xc_interface_open(void
> > > > > *logger, void *dombuild_logger,
> > > > > >      return xc_interface_open(logger, dombuild_logger,
> > > > > > open_flags);  }
> > > > > >
> > > > > > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > > > > > +                                           unsigned int
> > > > > > +open_flags) {
> > > > > > +    return xc_gntshr_open(logger, open_flags); }
> > > > > > +
> > > > > >  /* FIXME There is now way to have the xen fd */  static
> > > > > > inline int xc_fd(xc_interface *xen_xc)  { diff --git
> > > > > > a/xen-hvm.c b/xen-hvm.c index 21f1cbb..c99ace8 100644
> > > > > > --- a/xen-hvm.c
> > > > > > +++ b/xen-hvm.c
> > > > > > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> > > > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > > > >      int i, rc;
> > > > > >      unsigned long ioreq_pfn;
> > > > > >      unsigned long bufioreq_evtchn;
> > > > > > +
> > > > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > > > +    unsigned long stubdom_vtpm = 0; #endif
> > > > > > +
> > > > > >      XenIOState *state;
> > > > > >
> > > > > >      state = g_malloc0(sizeof (XenIOState)); @@ -1169,6
> > > > > > +1174,14 @@ int xen_hvm_init(ram_addr_t
> > > > > *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> > > > > >          fprintf(stderr, "%s: xen backend core setup
> > > > > > failed\n",
> > > > > __FUNCTION__);
> > > > > >          return -1;
> > > > > >      }
> > > > > > +
> > > > > > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > > > > > +    xc_get_hvm_param(xen_xc, xen_domid,
> > > > > HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > > > > > +    if (stubdom_vtpm) {
> > > > > > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > > > > > +    }
> > > > > > +#endif
> > > > >
> > > > > Given that vtpm is just a PV frontend, can't you just detect
> > > > > whether is present on xenstore and initialize it based on that?
> > > > > Like all the backend below?
> > > >
> > > > Also I will explain in my next email.
> > > >
> > > >
> > > > >
> > > > >
> > > > > >      xen_be_register("console", &xen_console_ops);
> > > > > >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> > > > > >      xen_be_register("qdisk", &xen_blkdev_ops);
> > > > > > --
> > > > > > 1.8.3.2
> > > > > >
> > > >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 03:09:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 03:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmDRv-0004PQ-Go; Thu, 06 Nov 2014 03:09:27 +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 1XmDRt-0004PL-KU
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 03:09:25 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	17/0E-02696-466EA545; Thu, 06 Nov 2014 03:09:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415243362!12853421!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25087 invoked from network); 6 Nov 2014 03:09:23 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 03:09:23 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA639JFB014686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Nov 2014 03:09:19 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA639Ihu001578
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 6 Nov 2014 03:09:18 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA639Hnw029847; Thu, 6 Nov 2014 03:09:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 19:09:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4D7D3111212; Wed,  5 Nov 2014 22:09:16 -0500 (EST)
Date: Wed, 5 Nov 2014 22:09:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Message-ID: <20141106030916.GA4186@laptop.dumpdata.com>
References: <469h2cuyy0a5y5fn77uh3y1b.1413332405802@email.android.com>
	<20141015210355.GB6579@laptop.dumpdata.com>
	<544AD7CF.5020006@gmail.com>
	<CAErSpo78mX9Q8HDsOFMhzNTjtGqD1aiTTrWH-zwGUEo24EF9CA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAErSpo78mX9Q8HDsOFMhzNTjtGqD1aiTTrWH-zwGUEo24EF9CA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Chen Gang <gang.chen.5i5j@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH next] xen: pcifront: Process failure for
 pcifront_(re)scan_root()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 04:31:17PM -0700, Bjorn Helgaas wrote:
> [+cc linux-pci again]
> 
> On Fri, Oct 24, 2014 at 4:50 PM, Chen Gang <gang.chen.5i5j@gmail.com> wrote:
> > On 10/16/14 5:03, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Oct 15, 2014 at 08:20:06AM +0800, Chen Gang wrote:
> >>>
> >>> At least for me, what you said sound OK.
> >>
> >> Let me review it - next week.
> >
> > Please help check this patch, when you have time.
> 
> linux-pci got dropped from the cc list, which makes it harder for me
> to track this in patchwork.
> 
> But I'm waiting for Konrad to either ack this or just take it
> directly.  Here's my ack if you want it:
> 
> Acked-by: Bjorn Helgas <bhelgaas@google.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Bjorn, if you would like to pick it up that would be good!
> 
> >>> Bjorn Helgaas <bhelgaas@google.com> wrote:
> >>>
> >>>> On Mon, Oct 06, 2014 at 11:04:45AM +0800, Chen Gang wrote:
> >>>>> When pcifront_rescan_root() or pcifront_scan_root() fails, need return
> >>>>> error code, neither set XenbusStateConnected state, just like the other
> >>>>> areas have done.
> >>>>>
> >>>>> For pcifront_rescan_root(), it will return error code ("num_roots = 0;",
> >>>>> skip xenbus_switch_state return value).
> >>>>>
> >>>>> For pcifront_scan_root(), it will return 0 ("num_roots = 0;", set 0 by
> >>>>> the return value of xenbus_switch_state, which always return 0, at
> >>>>> present).
> >>>>
> >>>> The changelog is somewhat confusing because it talks about the patch hunks
> >>>> in reverse order (the pcifront_scan_root() change is first in the patch,
> >>>> but the changelog mentions pcifront_rescan_root() first).  I *think* this
> >>>> means:
> >>>>
> >>>>  When pcifront_try_connect() finds no PCI roots, it falls back to calling
> >>>>  pcifront_scan_root() for 0000:00.  If that fails, it used to switch to
> >>>>  XenbusStateConnected and return success (because xenbus_switch_state()
> >>>>  currently always succeeds).
> >>>>
> >>>>  If pcifront_scan_root() fails, leave the XenbusState unchanged and
> >>>>  return an error code.
> >>>>
> >>>>  Similarly, pcifront_attach_devices() falls back to calling
> >>>>  pcifront_rescan_root() for 0000:00.  If that fails, it used to
> >>>>  switch to XenbusStateConnected and return an error code.
> >>>>
> >>>>  If pcifront_rescan_root() fails, leave the XenbusState unchanged and
> >>>>  return the error code.
> >>>>
> >>>> The "num_roots" part doesn't seem relevant to me.
> >>>>
> >>>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> >>>>
> >>>> Konrad, if you want to take this, feel free.  Otherwise, if you ack it and
> >>>> you think my changelog understanding makes sense, I can pick it up.
> >>>>
> >>>> It does seem odd that pcifront_attach_devices() ignores the
> >>>> xenbus_switch_state() return value while pcifront_try_connect() does not.
> >>>> But many other callers also ignore the return value, so maybe that's OK.

It is OK. We had an discussion about making the xenbus_switch_state an
void. The reason being that if the state change fails we call xenbus_switch_fatal
(which does not return anything) - which then sets the state to XenbusStateClosing.

But for some drivers it makes sense to know about this failure so that
they can deallocate their resources. So ignoring ret is OK if the driver
is OK handling its deallocation in a different way.

> >>>>
> >>>> Bjorn
> >>>>
> >>>>> ---
> >>>>>  drivers/pci/xen-pcifront.c | 10 ++++++++++
> >>>>>  1 file changed, 10 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> >>>>> index 53df39a..d78d884 100644
> >>>>> --- a/drivers/pci/xen-pcifront.c
> >>>>> +++ b/drivers/pci/xen-pcifront.c
> >>>>> @@ -866,6 +866,11 @@ static int pcifront_try_connect(struct pcifront_device *pdev)
> >>>>>            xenbus_dev_error(pdev->xdev, err,
> >>>>>                             "No PCI Roots found, trying 0000:00");
> >>>>>            err = pcifront_scan_root(pdev, 0, 0);
> >>>>> +          if (err) {
> >>>>> +                  xenbus_dev_fatal(pdev->xdev, err,
> >>>>> +                                   "Error scanning PCI root 0000:00");
> >>>>> +                  goto out;
> >>>>> +          }
> >>>>>            num_roots = 0;
> >>>>>    } else if (err != 1) {
> >>>>>            if (err == 0)
> >>>>> @@ -947,6 +952,11 @@ static int pcifront_attach_devices(struct pcifront_device *pdev)
> >>>>>            xenbus_dev_error(pdev->xdev, err,
> >>>>>                             "No PCI Roots found, trying 0000:00");
> >>>>>            err = pcifront_rescan_root(pdev, 0, 0);
> >>>>> +          if (err) {
> >>>>> +                  xenbus_dev_fatal(pdev->xdev, err,
> >>>>> +                                   "Error scanning PCI root 0000:00");
> >>>>> +                  goto out;
> >>>>> +          }
> >>>>>            num_roots = 0;
> >>>>>    } else if (err != 1) {
> >>>>>            if (err == 0)
> >>>>> --
> >>>>> 1.9.3
> >
> > --
> > Chen Gang
> >
> > Open, share, and attitude like air, water, and life which God blessed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 03:09:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 03:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmDRv-0004PQ-Go; Thu, 06 Nov 2014 03:09:27 +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 1XmDRt-0004PL-KU
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 03:09:25 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	17/0E-02696-466EA545; Thu, 06 Nov 2014 03:09:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415243362!12853421!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25087 invoked from network); 6 Nov 2014 03:09:23 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 03:09:23 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA639JFB014686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Nov 2014 03:09:19 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA639Ihu001578
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 6 Nov 2014 03:09:18 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA639Hnw029847; Thu, 6 Nov 2014 03:09:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Nov 2014 19:09:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4D7D3111212; Wed,  5 Nov 2014 22:09:16 -0500 (EST)
Date: Wed, 5 Nov 2014 22:09:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Message-ID: <20141106030916.GA4186@laptop.dumpdata.com>
References: <469h2cuyy0a5y5fn77uh3y1b.1413332405802@email.android.com>
	<20141015210355.GB6579@laptop.dumpdata.com>
	<544AD7CF.5020006@gmail.com>
	<CAErSpo78mX9Q8HDsOFMhzNTjtGqD1aiTTrWH-zwGUEo24EF9CA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAErSpo78mX9Q8HDsOFMhzNTjtGqD1aiTTrWH-zwGUEo24EF9CA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Chen Gang <gang.chen.5i5j@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH next] xen: pcifront: Process failure for
 pcifront_(re)scan_root()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 04:31:17PM -0700, Bjorn Helgaas wrote:
> [+cc linux-pci again]
> 
> On Fri, Oct 24, 2014 at 4:50 PM, Chen Gang <gang.chen.5i5j@gmail.com> wrote:
> > On 10/16/14 5:03, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Oct 15, 2014 at 08:20:06AM +0800, Chen Gang wrote:
> >>>
> >>> At least for me, what you said sound OK.
> >>
> >> Let me review it - next week.
> >
> > Please help check this patch, when you have time.
> 
> linux-pci got dropped from the cc list, which makes it harder for me
> to track this in patchwork.
> 
> But I'm waiting for Konrad to either ack this or just take it
> directly.  Here's my ack if you want it:
> 
> Acked-by: Bjorn Helgas <bhelgaas@google.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Bjorn, if you would like to pick it up that would be good!
> 
> >>> Bjorn Helgaas <bhelgaas@google.com> wrote:
> >>>
> >>>> On Mon, Oct 06, 2014 at 11:04:45AM +0800, Chen Gang wrote:
> >>>>> When pcifront_rescan_root() or pcifront_scan_root() fails, need return
> >>>>> error code, neither set XenbusStateConnected state, just like the other
> >>>>> areas have done.
> >>>>>
> >>>>> For pcifront_rescan_root(), it will return error code ("num_roots = 0;",
> >>>>> skip xenbus_switch_state return value).
> >>>>>
> >>>>> For pcifront_scan_root(), it will return 0 ("num_roots = 0;", set 0 by
> >>>>> the return value of xenbus_switch_state, which always return 0, at
> >>>>> present).
> >>>>
> >>>> The changelog is somewhat confusing because it talks about the patch hunks
> >>>> in reverse order (the pcifront_scan_root() change is first in the patch,
> >>>> but the changelog mentions pcifront_rescan_root() first).  I *think* this
> >>>> means:
> >>>>
> >>>>  When pcifront_try_connect() finds no PCI roots, it falls back to calling
> >>>>  pcifront_scan_root() for 0000:00.  If that fails, it used to switch to
> >>>>  XenbusStateConnected and return success (because xenbus_switch_state()
> >>>>  currently always succeeds).
> >>>>
> >>>>  If pcifront_scan_root() fails, leave the XenbusState unchanged and
> >>>>  return an error code.
> >>>>
> >>>>  Similarly, pcifront_attach_devices() falls back to calling
> >>>>  pcifront_rescan_root() for 0000:00.  If that fails, it used to
> >>>>  switch to XenbusStateConnected and return an error code.
> >>>>
> >>>>  If pcifront_rescan_root() fails, leave the XenbusState unchanged and
> >>>>  return the error code.
> >>>>
> >>>> The "num_roots" part doesn't seem relevant to me.
> >>>>
> >>>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> >>>>
> >>>> Konrad, if you want to take this, feel free.  Otherwise, if you ack it and
> >>>> you think my changelog understanding makes sense, I can pick it up.
> >>>>
> >>>> It does seem odd that pcifront_attach_devices() ignores the
> >>>> xenbus_switch_state() return value while pcifront_try_connect() does not.
> >>>> But many other callers also ignore the return value, so maybe that's OK.

It is OK. We had an discussion about making the xenbus_switch_state an
void. The reason being that if the state change fails we call xenbus_switch_fatal
(which does not return anything) - which then sets the state to XenbusStateClosing.

But for some drivers it makes sense to know about this failure so that
they can deallocate their resources. So ignoring ret is OK if the driver
is OK handling its deallocation in a different way.

> >>>>
> >>>> Bjorn
> >>>>
> >>>>> ---
> >>>>>  drivers/pci/xen-pcifront.c | 10 ++++++++++
> >>>>>  1 file changed, 10 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> >>>>> index 53df39a..d78d884 100644
> >>>>> --- a/drivers/pci/xen-pcifront.c
> >>>>> +++ b/drivers/pci/xen-pcifront.c
> >>>>> @@ -866,6 +866,11 @@ static int pcifront_try_connect(struct pcifront_device *pdev)
> >>>>>            xenbus_dev_error(pdev->xdev, err,
> >>>>>                             "No PCI Roots found, trying 0000:00");
> >>>>>            err = pcifront_scan_root(pdev, 0, 0);
> >>>>> +          if (err) {
> >>>>> +                  xenbus_dev_fatal(pdev->xdev, err,
> >>>>> +                                   "Error scanning PCI root 0000:00");
> >>>>> +                  goto out;
> >>>>> +          }
> >>>>>            num_roots = 0;
> >>>>>    } else if (err != 1) {
> >>>>>            if (err == 0)
> >>>>> @@ -947,6 +952,11 @@ static int pcifront_attach_devices(struct pcifront_device *pdev)
> >>>>>            xenbus_dev_error(pdev->xdev, err,
> >>>>>                             "No PCI Roots found, trying 0000:00");
> >>>>>            err = pcifront_rescan_root(pdev, 0, 0);
> >>>>> +          if (err) {
> >>>>> +                  xenbus_dev_fatal(pdev->xdev, err,
> >>>>> +                                   "Error scanning PCI root 0000:00");
> >>>>> +                  goto out;
> >>>>> +          }
> >>>>>            num_roots = 0;
> >>>>>    } else if (err != 1) {
> >>>>>            if (err == 0)
> >>>>> --
> >>>>> 1.9.3
> >
> > --
> > Chen Gang
> >
> > Open, share, and attitude like air, water, and life which God blessed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 04:17:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 04:17:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmEVG-0005rU-CK; Thu, 06 Nov 2014 04:16:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1XmEVF-0005rP-EU
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 04:16:57 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	61/56-01660-836FA545; Thu, 06 Nov 2014 04:16:56 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415247414!11504754!1
X-Originating-IP: [209.85.213.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3905 invoked from network); 6 Nov 2014 04:16:55 -0000
Received: from mail-ig0-f172.google.com (HELO mail-ig0-f172.google.com)
	(209.85.213.172)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 04:16:55 -0000
Received: by mail-ig0-f172.google.com with SMTP id a13so10062155igq.11
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 20:16:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=9pjkdNT6BTbTHJ872EmsM/dm65RSb7UGTWm4EVFxzUs=;
	b=OlKjIX0ponKG/k1KV7bSL2EhvsFXhsUVBg04WLsEA5OgjIxotn6FhkPIynx+Nkci4U
	BrBAnW5zJRijKmegyDtpCM/e2pk50ly9cZdkzrAYxbHhqNMbFey1MhjIQZXVLLoLj16w
	Yu12Cg2RjgyLrQa3pYzh9I8d7cT8USjZ68frCLYCFb5Dgtpt75P5yrJl0+EeX0E2LxFt
	mQmomXkU2dZBL00ARoKyRiMxZ+nEsIwOpBcolutSuwhhNWY6v5W7NmvoNwYJ+FyrYZR0
	gBxMbpBwuZzWyjRvdfMMztRWY9WuznHyBoMuDTqLnlygmKJK3Tjxc2c9whX+MMJapoHI
	betg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=9pjkdNT6BTbTHJ872EmsM/dm65RSb7UGTWm4EVFxzUs=;
	b=PvmyEqxTAp6E3gbfCCEH8wCg63oQ+dUTRW5zSSsVU/Nk8zBS37i9gap2MkZBPcPT9t
	tEOuUHWEsxjKzTgNnkCk4IvYVG2wzJE4UqCJhoVCnxb0U8ivi6NqA0cD8NwMermjLofS
	CEekDTbcmJIJKeUYnIVmRQPnZblUfsWGYAgOFrg/jgMv1l+bGkpYHWcqO4wrNxqnYaV8
	zR84qo9mRfXT0KWjybwSYv29cW/oG/NQxt0+nTXVXYJmjlLamnxBNsc4AeVwf5EGJPIF
	KrlfojdXVySIlDoAUUofR85gOVa3WH5EoC7wc8Yul5Y9DwMxLDiKPV0QREcnmBfFsXIj
	aWmw==
X-Gm-Message-State: ALoCoQl0x7mMPNpGov8MUzQ2WoEYKra8R+aY2yjFE5B0KkL48XxNT+3jpwXFcl8xrchlS5nh9kt5
X-Received: by 10.50.3.4 with SMTP id 4mr37179613igy.22.1415247414652;
	Wed, 05 Nov 2014 20:16:54 -0800 (PST)
Received: from google.com ([172.16.48.42])
	by mx.google.com with ESMTPSA id l8sm5999702igv.13.2014.11.05.20.16.52
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 20:16:53 -0800 (PST)
Date: Wed, 5 Nov 2014 21:16:48 -0700
From: Bjorn Helgaas <bhelgaas@google.com>
To: Chen Gang <gang.chen.5i5j@gmail.com>
Message-ID: <20141106041648.GM6168@google.com>
References: <543206CD.1040505@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <543206CD.1040505@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: linux-pci@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH next] xen: pcifront: Process failure for
 pcifront_(re)scan_root()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 06, 2014 at 11:04:45AM +0800, Chen Gang wrote:
> When pcifront_rescan_root() or pcifront_scan_root() fails, need return
> error code, neither set XenbusStateConnected state, just like the other
> areas have done.
> 
> For pcifront_rescan_root(), it will return error code ("num_roots = 0;",
> skip xenbus_switch_state return value).
> 
> For pcifront_scan_root(), it will return 0 ("num_roots = 0;", set 0 by
> the return value of xenbus_switch_state, which always return 0, at
> present).
> 
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>

Applied to pci/virtualization for v3.19, with Konrad's ack and my changelog
rework.  Thanks!

> ---
>  drivers/pci/xen-pcifront.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index 53df39a..d78d884 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -866,6 +866,11 @@ static int pcifront_try_connect(struct pcifront_device *pdev)
>  		xenbus_dev_error(pdev->xdev, err,
>  				 "No PCI Roots found, trying 0000:00");
>  		err = pcifront_scan_root(pdev, 0, 0);
> +		if (err) {
> +			xenbus_dev_fatal(pdev->xdev, err,
> +					 "Error scanning PCI root 0000:00");
> +			goto out;
> +		}
>  		num_roots = 0;
>  	} else if (err != 1) {
>  		if (err == 0)
> @@ -947,6 +952,11 @@ static int pcifront_attach_devices(struct pcifront_device *pdev)
>  		xenbus_dev_error(pdev->xdev, err,
>  				 "No PCI Roots found, trying 0000:00");
>  		err = pcifront_rescan_root(pdev, 0, 0);
> +		if (err) {
> +			xenbus_dev_fatal(pdev->xdev, err,
> +					 "Error scanning PCI root 0000:00");
> +			goto out;
> +		}
>  		num_roots = 0;
>  	} else if (err != 1) {
>  		if (err == 0)
> -- 
> 1.9.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 04:17:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 04:17:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmEVG-0005rU-CK; Thu, 06 Nov 2014 04:16:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1XmEVF-0005rP-EU
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 04:16:57 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	61/56-01660-836FA545; Thu, 06 Nov 2014 04:16:56 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415247414!11504754!1
X-Originating-IP: [209.85.213.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3905 invoked from network); 6 Nov 2014 04:16:55 -0000
Received: from mail-ig0-f172.google.com (HELO mail-ig0-f172.google.com)
	(209.85.213.172)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 04:16:55 -0000
Received: by mail-ig0-f172.google.com with SMTP id a13so10062155igq.11
	for <xen-devel@lists.xenproject.org>;
	Wed, 05 Nov 2014 20:16:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=9pjkdNT6BTbTHJ872EmsM/dm65RSb7UGTWm4EVFxzUs=;
	b=OlKjIX0ponKG/k1KV7bSL2EhvsFXhsUVBg04WLsEA5OgjIxotn6FhkPIynx+Nkci4U
	BrBAnW5zJRijKmegyDtpCM/e2pk50ly9cZdkzrAYxbHhqNMbFey1MhjIQZXVLLoLj16w
	Yu12Cg2RjgyLrQa3pYzh9I8d7cT8USjZ68frCLYCFb5Dgtpt75P5yrJl0+EeX0E2LxFt
	mQmomXkU2dZBL00ARoKyRiMxZ+nEsIwOpBcolutSuwhhNWY6v5W7NmvoNwYJ+FyrYZR0
	gBxMbpBwuZzWyjRvdfMMztRWY9WuznHyBoMuDTqLnlygmKJK3Tjxc2c9whX+MMJapoHI
	betg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=9pjkdNT6BTbTHJ872EmsM/dm65RSb7UGTWm4EVFxzUs=;
	b=PvmyEqxTAp6E3gbfCCEH8wCg63oQ+dUTRW5zSSsVU/Nk8zBS37i9gap2MkZBPcPT9t
	tEOuUHWEsxjKzTgNnkCk4IvYVG2wzJE4UqCJhoVCnxb0U8ivi6NqA0cD8NwMermjLofS
	CEekDTbcmJIJKeUYnIVmRQPnZblUfsWGYAgOFrg/jgMv1l+bGkpYHWcqO4wrNxqnYaV8
	zR84qo9mRfXT0KWjybwSYv29cW/oG/NQxt0+nTXVXYJmjlLamnxBNsc4AeVwf5EGJPIF
	KrlfojdXVySIlDoAUUofR85gOVa3WH5EoC7wc8Yul5Y9DwMxLDiKPV0QREcnmBfFsXIj
	aWmw==
X-Gm-Message-State: ALoCoQl0x7mMPNpGov8MUzQ2WoEYKra8R+aY2yjFE5B0KkL48XxNT+3jpwXFcl8xrchlS5nh9kt5
X-Received: by 10.50.3.4 with SMTP id 4mr37179613igy.22.1415247414652;
	Wed, 05 Nov 2014 20:16:54 -0800 (PST)
Received: from google.com ([172.16.48.42])
	by mx.google.com with ESMTPSA id l8sm5999702igv.13.2014.11.05.20.16.52
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Wed, 05 Nov 2014 20:16:53 -0800 (PST)
Date: Wed, 5 Nov 2014 21:16:48 -0700
From: Bjorn Helgaas <bhelgaas@google.com>
To: Chen Gang <gang.chen.5i5j@gmail.com>
Message-ID: <20141106041648.GM6168@google.com>
References: <543206CD.1040505@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <543206CD.1040505@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: linux-pci@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH next] xen: pcifront: Process failure for
 pcifront_(re)scan_root()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 06, 2014 at 11:04:45AM +0800, Chen Gang wrote:
> When pcifront_rescan_root() or pcifront_scan_root() fails, need return
> error code, neither set XenbusStateConnected state, just like the other
> areas have done.
> 
> For pcifront_rescan_root(), it will return error code ("num_roots = 0;",
> skip xenbus_switch_state return value).
> 
> For pcifront_scan_root(), it will return 0 ("num_roots = 0;", set 0 by
> the return value of xenbus_switch_state, which always return 0, at
> present).
> 
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>

Applied to pci/virtualization for v3.19, with Konrad's ack and my changelog
rework.  Thanks!

> ---
>  drivers/pci/xen-pcifront.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index 53df39a..d78d884 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -866,6 +866,11 @@ static int pcifront_try_connect(struct pcifront_device *pdev)
>  		xenbus_dev_error(pdev->xdev, err,
>  				 "No PCI Roots found, trying 0000:00");
>  		err = pcifront_scan_root(pdev, 0, 0);
> +		if (err) {
> +			xenbus_dev_fatal(pdev->xdev, err,
> +					 "Error scanning PCI root 0000:00");
> +			goto out;
> +		}
>  		num_roots = 0;
>  	} else if (err != 1) {
>  		if (err == 0)
> @@ -947,6 +952,11 @@ static int pcifront_attach_devices(struct pcifront_device *pdev)
>  		xenbus_dev_error(pdev->xdev, err,
>  				 "No PCI Roots found, trying 0000:00");
>  		err = pcifront_rescan_root(pdev, 0, 0);
> +		if (err) {
> +			xenbus_dev_fatal(pdev->xdev, err,
> +					 "Error scanning PCI root 0000:00");
> +			goto out;
> +		}
>  		num_roots = 0;
>  	} else if (err != 1) {
>  		if (err == 0)
> -- 
> 1.9.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:35:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFj1-0007en-BP; Thu, 06 Nov 2014 05:35:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XmFiz-0007eg-Ua
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 05:35:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	23/9F-24532-1980B545; Thu, 06 Nov 2014 05:35:13 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415252111!3784296!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28687 invoked from network); 6 Nov 2014 05:35:12 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 05:35:12 -0000
Received: by mail-vc0-f173.google.com with SMTP id le20so174792vcb.4
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 21:35:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=KE+OYlNMLALSqCCtm6KmJUI7YkGiEC5OArPBEe5XOW4=;
	b=eqH1cwf1NL/YxrdciP21edUo7QA3vqISsSgEfZ/g/kHHsc738FY+VuRCcwlD5CdEUq
	6TtswjPimNwDuO04zGTfMd/wJDAeY/uu/4FGH84NpK5N6GJEgkpBlYggqKyFDB6E1fD1
	muv3uF5KU6OXiZTXZRsV1R/uVb0cuo5uqW1/1ceR4KczSnvFYTF/T1K54u/RZG3aew3O
	SEvY+dV/HOFrVzPiL9EyeyZulfdJlQAddyKsPVaIiu9Ct3mgDPZKMPjD8kcItonCpSKf
	/IPJCt5+dhkAOtQvxGeVx4jnPkYEQaD0VJ7VKVZ+Kx3+ezJV7nRn7EgAHBfQcetMx2Rj
	zIjQ==
X-Gm-Message-State: ALoCoQkUyuhvR2Qkh1Eow3CmBmLtuTQBMIFr+9W+hpGurQ+87Lx2cxna2gXogJ6kCntO4CQ3TlDh
MIME-Version: 1.0
X-Received: by 10.52.121.167 with SMTP id ll7mr1166137vdb.35.1415252111026;
	Wed, 05 Nov 2014 21:35:11 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Wed, 5 Nov 2014 21:35:10 -0800 (PST)
In-Reply-To: <20141105143018.GQ16923@olila.local.net-space.pl>
References: <20141029124411.GA3467@olila.local.net-space.pl>
	<1414596400.29580.12.camel@citrix.com>
	<20141029165526.GB3467@olila.local.net-space.pl>
	<CAFECyb_Q34S=L2Sy+PvLMBkZnct7z5y-u_c0Naush3oa2qnpng@mail.gmail.com>
	<20141030175714.GF3467@olila.local.net-space.pl>
	<CAFECyb--vAVRMvHVNZKb39WSaKDO16JbkHQBi-HbL-LLx5VUoA@mail.gmail.com>
	<20141030221857.GA16923@olila.local.net-space.pl>
	<CAFECyb8cJvkrjgUcu1-mr_xBJPZOxKdrEnJ4ekD78gEK0a=5iA@mail.gmail.com>
	<20141104214952.GL16923@olila.local.net-space.pl>
	<CAFECyb_NHc9bnG1BFasL-3Gk5A10iHEdN0HTE-8SJan=o=mp6A@mail.gmail.com>
	<20141105143018.GQ16923@olila.local.net-space.pl>
Date: Wed, 5 Nov 2014 21:35:10 -0800
Message-ID: <CAFECyb-ghmNfsYaRjQVysy07Vofw3q6-oxuh1XqDFh1mFga_GA@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, tim <tim@xen.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH V2 for-4.5] EFI: Always use EFI command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 5, 2014 at 6:30 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> On Tue, Nov 04, 2014 at 02:48:59PM -0800, Roy Franz wrote:
>> On Tue, Nov 4, 2014 at 1:49 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>> > On Thu, Oct 30, 2014 at 04:54:17PM -0700, Roy Franz wrote:
>
> [...]
>
>> >> The current implementation is to examine the FDT passed to Xen to see
>> >> if it contains any modules.  If it does, then this indicates to the
>> >> EFI boot code
>> >> that it is being run by a bootloader, and not directly from the EFI bootmanager
>> >> or shell.
>> >
>> > I think that it is wrong. I am able to imagine such situation in which
>> > only small binary is loaded to do something specific and this binary
>> > does not require any modules. If we do what you suggest then we must
>> > load an additional module which will not be used by binary itself but
>> > it just signals that binary was loaded by multiboot protocol. Not nice.
>> > That is why I am still thinking that multiboot protocol aware loader
>> > should put a flag in FDT telling that binary was loaded that way.
>> >
>> > I am aware that Xen have to have at least one module (kernel image for dom0)
>> > but I think that new protocol should be generic as much as possible and
>> > Xen should not be its only one user.
>>
>> I think that what is being done for Xen is robust for Xen, and likely will be
>> for others as well.  The FDT-multiboot bindings are just a way to pass extra
>> module information to an application - if there are no "multiboot,module" compatible nodes,
>> then the FDT-multiboot bindings are not in use.  Multiboot2 seems to imply much more
>
> OK, however, lack of "multiboot,module" does not mean that image was not
> loaded by multiboot aware loader on ARM64 platform. As I can see there
> are also other valid FDT multiboot strings in spec, e.g. "multiboot,kernel".
> They could not be used by Xen itself but it does not change anything in
> boot protocol. Hence, I think that it is much easier to look for one string
> or magic value which has meaning "loaded by multiboot aware loader" than
> test all possible values to be sure that image was not loaded by "multiboot
> aware loader".

I think that this is worth further discussion, but I don't think this
additional FDT node
will be agreed upon and implemented in GRUB and Xen in time for any changes
in 4.5. (and I don't think it is urgently needed.)  Also, I know I
used the term
"loaded by multiboot aware loader", but this may not be the precise thing the
arm64 EFI Xen boot code cares about.  I think what it really cares about is
whether the FDT it has been given has modules (ie dom0, initrd)
already in it, or if the boot code needs to loade them based on a config file.

>
>> than that - I need to investigate that a bit more so I understand how
>> this is done on x86.
>
> multiboot2 aware loader on x86 puts special magic value in %eax to
> mark that image should expect multiboot2 as a boot protocol. Early
> x86 code looks for this value and do all things accordingly.
>
> Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:35:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFj1-0007en-BP; Thu, 06 Nov 2014 05:35:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XmFiz-0007eg-Ua
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 05:35:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	23/9F-24532-1980B545; Thu, 06 Nov 2014 05:35:13 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415252111!3784296!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28687 invoked from network); 6 Nov 2014 05:35:12 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 05:35:12 -0000
Received: by mail-vc0-f173.google.com with SMTP id le20so174792vcb.4
	for <xen-devel@lists.xen.org>; Wed, 05 Nov 2014 21:35:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=KE+OYlNMLALSqCCtm6KmJUI7YkGiEC5OArPBEe5XOW4=;
	b=eqH1cwf1NL/YxrdciP21edUo7QA3vqISsSgEfZ/g/kHHsc738FY+VuRCcwlD5CdEUq
	6TtswjPimNwDuO04zGTfMd/wJDAeY/uu/4FGH84NpK5N6GJEgkpBlYggqKyFDB6E1fD1
	muv3uF5KU6OXiZTXZRsV1R/uVb0cuo5uqW1/1ceR4KczSnvFYTF/T1K54u/RZG3aew3O
	SEvY+dV/HOFrVzPiL9EyeyZulfdJlQAddyKsPVaIiu9Ct3mgDPZKMPjD8kcItonCpSKf
	/IPJCt5+dhkAOtQvxGeVx4jnPkYEQaD0VJ7VKVZ+Kx3+ezJV7nRn7EgAHBfQcetMx2Rj
	zIjQ==
X-Gm-Message-State: ALoCoQkUyuhvR2Qkh1Eow3CmBmLtuTQBMIFr+9W+hpGurQ+87Lx2cxna2gXogJ6kCntO4CQ3TlDh
MIME-Version: 1.0
X-Received: by 10.52.121.167 with SMTP id ll7mr1166137vdb.35.1415252111026;
	Wed, 05 Nov 2014 21:35:11 -0800 (PST)
Received: by 10.220.78.77 with HTTP; Wed, 5 Nov 2014 21:35:10 -0800 (PST)
In-Reply-To: <20141105143018.GQ16923@olila.local.net-space.pl>
References: <20141029124411.GA3467@olila.local.net-space.pl>
	<1414596400.29580.12.camel@citrix.com>
	<20141029165526.GB3467@olila.local.net-space.pl>
	<CAFECyb_Q34S=L2Sy+PvLMBkZnct7z5y-u_c0Naush3oa2qnpng@mail.gmail.com>
	<20141030175714.GF3467@olila.local.net-space.pl>
	<CAFECyb--vAVRMvHVNZKb39WSaKDO16JbkHQBi-HbL-LLx5VUoA@mail.gmail.com>
	<20141030221857.GA16923@olila.local.net-space.pl>
	<CAFECyb8cJvkrjgUcu1-mr_xBJPZOxKdrEnJ4ekD78gEK0a=5iA@mail.gmail.com>
	<20141104214952.GL16923@olila.local.net-space.pl>
	<CAFECyb_NHc9bnG1BFasL-3Gk5A10iHEdN0HTE-8SJan=o=mp6A@mail.gmail.com>
	<20141105143018.GQ16923@olila.local.net-space.pl>
Date: Wed, 5 Nov 2014 21:35:10 -0800
Message-ID: <CAFECyb-ghmNfsYaRjQVysy07Vofw3q6-oxuh1XqDFh1mFga_GA@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, tim <tim@xen.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Fu Wei <fu.wei@linaro.org>
Subject: Re: [Xen-devel] [PATCH V2 for-4.5] EFI: Always use EFI command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 5, 2014 at 6:30 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> On Tue, Nov 04, 2014 at 02:48:59PM -0800, Roy Franz wrote:
>> On Tue, Nov 4, 2014 at 1:49 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>> > On Thu, Oct 30, 2014 at 04:54:17PM -0700, Roy Franz wrote:
>
> [...]
>
>> >> The current implementation is to examine the FDT passed to Xen to see
>> >> if it contains any modules.  If it does, then this indicates to the
>> >> EFI boot code
>> >> that it is being run by a bootloader, and not directly from the EFI bootmanager
>> >> or shell.
>> >
>> > I think that it is wrong. I am able to imagine such situation in which
>> > only small binary is loaded to do something specific and this binary
>> > does not require any modules. If we do what you suggest then we must
>> > load an additional module which will not be used by binary itself but
>> > it just signals that binary was loaded by multiboot protocol. Not nice.
>> > That is why I am still thinking that multiboot protocol aware loader
>> > should put a flag in FDT telling that binary was loaded that way.
>> >
>> > I am aware that Xen have to have at least one module (kernel image for dom0)
>> > but I think that new protocol should be generic as much as possible and
>> > Xen should not be its only one user.
>>
>> I think that what is being done for Xen is robust for Xen, and likely will be
>> for others as well.  The FDT-multiboot bindings are just a way to pass extra
>> module information to an application - if there are no "multiboot,module" compatible nodes,
>> then the FDT-multiboot bindings are not in use.  Multiboot2 seems to imply much more
>
> OK, however, lack of "multiboot,module" does not mean that image was not
> loaded by multiboot aware loader on ARM64 platform. As I can see there
> are also other valid FDT multiboot strings in spec, e.g. "multiboot,kernel".
> They could not be used by Xen itself but it does not change anything in
> boot protocol. Hence, I think that it is much easier to look for one string
> or magic value which has meaning "loaded by multiboot aware loader" than
> test all possible values to be sure that image was not loaded by "multiboot
> aware loader".

I think that this is worth further discussion, but I don't think this
additional FDT node
will be agreed upon and implemented in GRUB and Xen in time for any changes
in 4.5. (and I don't think it is urgently needed.)  Also, I know I
used the term
"loaded by multiboot aware loader", but this may not be the precise thing the
arm64 EFI Xen boot code cares about.  I think what it really cares about is
whether the FDT it has been given has modules (ie dom0, initrd)
already in it, or if the boot code needs to loade them based on a config file.

>
>> than that - I need to investigate that a bit more so I understand how
>> this is done on x86.
>
> multiboot2 aware loader on x86 puts special magic value in %eax to
> mark that image should expect multiboot2 as a boot protocol. Early
> x86 code looks for this value and do all things accordingly.
>
> Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv4-0007y9-Lz; Thu, 06 Nov 2014 05:47:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv3-0007xj-CA
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:41 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	5C/20-07724-C7B0B545; Thu, 06 Nov 2014 05:47:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415252859!11916861!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13060 invoked from network); 6 Nov 2014 05:47:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:40 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 925FFAD8A;
	Thu,  6 Nov 2014 05:47:38 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:28 +0100
Message-Id: <1415252853-7106-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 0/5] xen: Switch to virtual mapped linear p2m
	list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paravirtualized kernels running on Xen use a three level tree for
translation of guest specific physical addresses to machine global
addresses. This p2m tree is used for construction of page table
entries, so the p2m tree walk is performance critical.

By using a linear virtual mapped p2m list accesses to p2m elements
can be sped up while even simplifying code. To achieve this goal
some p2m related initializations have to be performed later in the
boot process, as the final p2m list can be set up only after basic
memory management functions are available.

Changes in V2:
- splitted patch 2 in 4 smaller ones as requested by David Vrabel
- added highmem check when remapping kernel memory as requested by
  David Vrabel

Juergen Gross (5):
  Xen: Delay remapping memory of pv-domain
  xen: Delay m2p_override initialization
  xen: Delay invalidating extra memory
  x86: Introduce function to get pmd entry pointer
  Xen: switch to linear virtual mapped sparse p2m list

 arch/x86/include/asm/pgtable_types.h |    1 +
 arch/x86/include/asm/xen/page.h      |   37 +-
 arch/x86/mm/pageattr.c               |   20 +
 arch/x86/xen/mmu.c                   |   38 +-
 arch/x86/xen/p2m.c                   | 1149 +++++++++++++---------------------
 arch/x86/xen/setup.c                 |  460 +++++++-------
 arch/x86/xen/xen-ops.h               |    6 +-
 7 files changed, 760 insertions(+), 951 deletions(-)

-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv5-0007yG-0S; Thu, 06 Nov 2014 05:47:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv3-0007xk-FE
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:41 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5C/15-24532-C7B0B545; Thu, 06 Nov 2014 05:47:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415252860!11778741!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18562 invoked from network); 6 Nov 2014 05:47:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:40 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CFF9FADA8;
	Thu,  6 Nov 2014 05:47:39 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:32 +0100
Message-Id: <1415252853-7106-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415252853-7106-1-git-send-email-jgross@suse.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 4/5] x86: Introduce function to get pmd entry
	pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduces lookup_pmd_address() to get the address of the pmd entry
related to a virtual address in the current address space. This
function is needed for support of a virtual mapped sparse p2m list
in xen pv domains.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/pgtable_types.h |  1 +
 arch/x86/mm/pageattr.c               | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0778964..d83f5e7 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -396,6 +396,7 @@ static inline void update_page_count(int level, unsigned long pages) { }
 extern pte_t *lookup_address(unsigned long address, unsigned int *level);
 extern pte_t *lookup_address_in_pgd(pgd_t *pgd, unsigned long address,
 				    unsigned int *level);
+extern pmd_t *lookup_pmd_address(unsigned long address);
 extern phys_addr_t slow_virt_to_phys(void *__address);
 extern int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
 				   unsigned numpages, unsigned long page_flags);
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 36de293..1298108 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -384,6 +384,26 @@ static pte_t *_lookup_address_cpa(struct cpa_data *cpa, unsigned long address,
 }
 
 /*
+ * Lookup the PMD entry for a virtual address. Return a pointer to the entry
+ * or NULL if not present.
+ */
+pmd_t *lookup_pmd_address(unsigned long address)
+{
+	pgd_t *pgd;
+	pud_t *pud;
+
+	pgd = pgd_offset_k(address);
+	if (pgd_none(*pgd))
+		return NULL;
+
+	pud = pud_offset(pgd, address);
+	if (pud_none(*pud) || pud_large(*pud) || !pud_present(*pud))
+		return NULL;
+
+	return pmd_offset(pud, address);
+}
+
+/*
  * This is necessary because __pa() does not work on some
  * kinds of memory, like vmalloc() or the alloc_remap()
  * areas on 32-bit NUMA systems.  The percpu areas can
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv6-0007yo-FE; Thu, 06 Nov 2014 05:47:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv5-0007y8-0h
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	68/B0-09842-E7B0B545; Thu, 06 Nov 2014 05:47:42 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415252860!11826616!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21561 invoked from network); 6 Nov 2014 05:47:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:40 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3523CADA9;
	Thu,  6 Nov 2014 05:47:40 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:33 +0100
Message-Id: <1415252853-7106-6-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415252853-7106-1-git-send-email-jgross@suse.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped
	sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At start of the day the Xen hypervisor presents a contiguous mfn list
to a pv-domain. In order to support sparse memory this mfn list is
accessed via a three level p2m tree built early in the boot process.
Whenever the system needs the mfn associated with a pfn this tree is
used to find the mfn.

Instead of using a software walked tree for accessing a specific mfn
list entry this patch is creating a virtual address area for the
entire possible mfn list including memory holes. The holes are
covered by mapping a pre-defined  page consisting only of "invalid
mfn" entries. Access to a mfn entry is possible by just using the
virtual base address of the mfn list and the pfn as index into that
list. This speeds up the (hot) path of determining the mfn of a
pfn.

Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
showed following improvements:

Elapsed time: 32:50 ->  32:35
System:       18:07 ->  17:47
User:        104:00 -> 103:30

Tested on 64 bit dom0 and 32 bit domU.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |  27 +-
 arch/x86/xen/mmu.c              |  34 +-
 arch/x86/xen/p2m.c              | 736 +++++++++++++++++-----------------------
 arch/x86/xen/xen-ops.h          |   2 +-
 4 files changed, 354 insertions(+), 445 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 28fa795..dd65a0c 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -59,6 +59,23 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct page **pages, unsigned int count);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
+static inline unsigned long __pfn_to_mfn(unsigned long pfn)
+{
+	unsigned long mfn;
+
+	if (pfn < xen_p2m_size)
+		mfn = xen_p2m_addr[pfn];
+	else if (unlikely(pfn < xen_max_p2m_pfn))
+		return get_phys_to_machine(pfn);
+	else
+		return IDENTITY_FRAME(pfn);
+
+	if (unlikely(mfn == INVALID_P2M_ENTRY))
+		return get_phys_to_machine(pfn);
+
+	return mfn;
+}
+
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
 {
 	unsigned long mfn;
@@ -66,7 +83,7 @@ static inline unsigned long pfn_to_mfn(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return pfn;
 
-	mfn = get_phys_to_machine(pfn);
+	mfn = __pfn_to_mfn(pfn);
 
 	if (mfn != INVALID_P2M_ENTRY)
 		mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
@@ -79,7 +96,7 @@ static inline int phys_to_machine_mapping_valid(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return 1;
 
-	return get_phys_to_machine(pfn) != INVALID_P2M_ENTRY;
+	return __pfn_to_mfn(pfn) != INVALID_P2M_ENTRY;
 }
 
 static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
@@ -113,7 +130,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) != mfn) {
+	if (__pfn_to_mfn(pfn) != mfn) {
 		/*
 		 * If this appears to be a foreign mfn (because the pfn
 		 * doesn't map back to the mfn), then check the local override
@@ -130,7 +147,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 	 * valid entry for it.
 	 */
 	if (pfn == ~0 &&
-			get_phys_to_machine(mfn) == IDENTITY_FRAME(mfn))
+			__pfn_to_mfn(mfn) == IDENTITY_FRAME(mfn))
 		pfn = mfn;
 
 	return pfn;
@@ -176,7 +193,7 @@ static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn(mfn);
-	if (get_phys_to_machine(pfn) != mfn)
+	if (__pfn_to_mfn(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
 }
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d3e492b..0b43c45 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -387,7 +387,7 @@ static pteval_t pte_pfn_to_mfn(pteval_t val)
 		unsigned long mfn;
 
 		if (!xen_feature(XENFEAT_auto_translated_physmap))
-			mfn = get_phys_to_machine(pfn);
+			mfn = __pfn_to_mfn(pfn);
 		else
 			mfn = pfn;
 		/*
@@ -1158,20 +1158,16 @@ static void __init xen_cleanhighmap(unsigned long vaddr,
 	 * instead of somewhere later and be confusing. */
 	xen_mc_flush();
 }
-static void __init xen_pagetable_p2m_copy(void)
+
+static void __init xen_pagetable_p2m_free(void)
 {
 	unsigned long size;
 	unsigned long addr;
-	unsigned long new_mfn_list;
-
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return;
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 
-	new_mfn_list = xen_revector_p2m_tree();
 	/* No memory or already called. */
-	if (!new_mfn_list || new_mfn_list == xen_start_info->mfn_list)
+	if ((unsigned long)xen_p2m_addr == xen_start_info->mfn_list)
 		return;
 
 	/* using __ka address and sticking INVALID_P2M_ENTRY! */
@@ -1189,8 +1185,6 @@ static void __init xen_pagetable_p2m_copy(void)
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 	memblock_free(__pa(xen_start_info->mfn_list), size);
-	/* And revector! Bye bye old array */
-	xen_start_info->mfn_list = new_mfn_list;
 
 	/* At this stage, cleanup_highmap has already cleaned __ka space
 	 * from _brk_limit way up to the max_pfn_mapped (which is the end of
@@ -1214,12 +1208,26 @@ static void __init xen_pagetable_p2m_copy(void)
 }
 #endif
 
-static void __init xen_pagetable_init(void)
+static void __init xen_pagetable_p2m_setup(void)
 {
-	paging_init();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	xen_vmalloc_p2m_tree();
+
 #ifdef CONFIG_X86_64
-	xen_pagetable_p2m_copy();
+	xen_pagetable_p2m_free();
 #endif
+	/* And revector! Bye bye old array */
+	xen_start_info->mfn_list = (unsigned long)xen_p2m_addr;
+}
+
+static void __init xen_pagetable_init(void)
+{
+	paging_init();
+
+	xen_pagetable_p2m_setup();
+
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 7c409b0..a39ea04 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -3,21 +3,22 @@
  * guests themselves, but it must also access and update the p2m array
  * during suspend/resume when all the pages are reallocated.
  *
- * The p2m table is logically a flat array, but we implement it as a
- * three-level tree to allow the address space to be sparse.
+ * The logical flat p2m table is mapped to a linear kernel memory area.
+ * For accesses by Xen a three-level tree linked via mfns only is set up to
+ * allow the address space to be sparse.
  *
- *                               Xen
- *                                |
- *     p2m_top              p2m_top_mfn
- *       /  \                   /   \
- * p2m_mid p2m_mid	p2m_mid_mfn p2m_mid_mfn
- *    / \      / \         /           /
- *  p2m p2m p2m p2m p2m p2m p2m ...
+ *               Xen
+ *                |
+ *          p2m_top_mfn
+ *              /   \
+ * p2m_mid_mfn p2m_mid_mfn
+ *         /           /
+ *  p2m p2m p2m ...
  *
  * The p2m_mid_mfn pages are mapped by p2m_top_mfn_p.
  *
- * The p2m_top and p2m_top_mfn levels are limited to 1 page, so the
- * maximum representable pseudo-physical address space is:
+ * The p2m_top_mfn level is limited to 1 page, so the maximum representable
+ * pseudo-physical address space is:
  *  P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * P2M_PER_PAGE pages
  *
  * P2M_PER_PAGE depends on the architecture, as a mfn is always
@@ -30,6 +31,9 @@
  * leaf entries, or for the top  root, or middle one, for which there is a void
  * entry, we assume it is  "missing". So (for example)
  *  pfn_to_mfn(0x90909090)=INVALID_P2M_ENTRY.
+ * We have a dedicated page p2m_missing with all entries being
+ * INVALID_P2M_ENTRY. This page may be referenced multiple times in the p2m
+ * list/tree in case there are multiple areas with P2M_PER_PAGE invalid pfns.
  *
  * We also have the possibility of setting 1-1 mappings on certain regions, so
  * that:
@@ -39,122 +43,20 @@
  * PCI BARs, or ACPI spaces), we can create mappings easily because we
  * get the PFN value to match the MFN.
  *
- * For this to work efficiently we have one new page p2m_identity and
- * allocate (via reserved_brk) any other pages we need to cover the sides
- * (1GB or 4MB boundary violations). All entries in p2m_identity are set to
- * INVALID_P2M_ENTRY type (Xen toolstack only recognizes that and MFNs,
- * no other fancy value).
+ * For this to work efficiently we have one new page p2m_identity. All entries
+ * in p2m_identity are set to INVALID_P2M_ENTRY type (Xen toolstack only
+ * recognizes that and MFNs, no other fancy value).
  *
  * On lookup we spot that the entry points to p2m_identity and return the
  * identity value instead of dereferencing and returning INVALID_P2M_ENTRY.
  * If the entry points to an allocated page, we just proceed as before and
- * return the PFN.  If the PFN has IDENTITY_FRAME_BIT set we unmask that in
+ * return the PFN. If the PFN has IDENTITY_FRAME_BIT set we unmask that in
  * appropriate functions (pfn_to_mfn).
  *
  * The reason for having the IDENTITY_FRAME_BIT instead of just returning the
  * PFN is that we could find ourselves where pfn_to_mfn(pfn)==pfn for a
  * non-identity pfn. To protect ourselves against we elect to set (and get) the
  * IDENTITY_FRAME_BIT on all identity mapped PFNs.
- *
- * This simplistic diagram is used to explain the more subtle piece of code.
- * There is also a digram of the P2M at the end that can help.
- * Imagine your E820 looking as so:
- *
- *                    1GB                                           2GB    4GB
- * /-------------------+---------\/----\         /----------\    /---+-----\
- * | System RAM        | Sys RAM ||ACPI|         | reserved |    | Sys RAM |
- * \-------------------+---------/\----/         \----------/    \---+-----/
- *                               ^- 1029MB                       ^- 2001MB
- *
- * [1029MB = 263424 (0x40500), 2001MB = 512256 (0x7D100),
- *  2048MB = 524288 (0x80000)]
- *
- * And dom0_mem=max:3GB,1GB is passed in to the guest, meaning memory past 1GB
- * is actually not present (would have to kick the balloon driver to put it in).
- *
- * When we are told to set the PFNs for identity mapping (see patch: "xen/setup:
- * Set identity mapping for non-RAM E820 and E820 gaps.") we pass in the start
- * of the PFN and the end PFN (263424 and 512256 respectively). The first step
- * is to reserve_brk a top leaf page if the p2m[1] is missing. The top leaf page
- * covers 512^2 of page estate (1GB) and in case the start or end PFN is not
- * aligned on 512^2*PAGE_SIZE (1GB) we reserve_brk new middle and leaf pages as
- * required to split any existing p2m_mid_missing middle pages.
- *
- * With the E820 example above, 263424 is not 1GB aligned so we allocate a
- * reserve_brk page which will cover the PFNs estate from 0x40000 to 0x80000.
- * Each entry in the allocate page is "missing" (points to p2m_missing).
- *
- * Next stage is to determine if we need to do a more granular boundary check
- * on the 4MB (or 2MB depending on architecture) off the start and end pfn's.
- * We check if the start pfn and end pfn violate that boundary check, and if
- * so reserve_brk a (p2m[x][y]) leaf page. This way we have a much finer
- * granularity of setting which PFNs are missing and which ones are identity.
- * In our example 263424 and 512256 both fail the check so we reserve_brk two
- * pages. Populate them with INVALID_P2M_ENTRY (so they both have "missing"
- * values) and assign them to p2m[1][2] and p2m[1][488] respectively.
- *
- * At this point we would at minimum reserve_brk one page, but could be up to
- * three. Each call to set_phys_range_identity has at maximum a three page
- * cost. If we were to query the P2M at this stage, all those entries from
- * start PFN through end PFN (so 1029MB -> 2001MB) would return
- * INVALID_P2M_ENTRY ("missing").
- *
- * The next step is to walk from the start pfn to the end pfn setting
- * the IDENTITY_FRAME_BIT on each PFN. This is done in set_phys_range_identity.
- * If we find that the middle entry is pointing to p2m_missing we can swap it
- * over to p2m_identity - this way covering 4MB (or 2MB) PFN space (and
- * similarly swapping p2m_mid_missing for p2m_mid_identity for larger regions).
- * At this point we do not need to worry about boundary aligment (so no need to
- * reserve_brk a middle page, figure out which PFNs are "missing" and which
- * ones are identity), as that has been done earlier.  If we find that the
- * middle leaf is not occupied by p2m_identity or p2m_missing, we dereference
- * that page (which covers 512 PFNs) and set the appropriate PFN with
- * IDENTITY_FRAME_BIT. In our example 263424 and 512256 end up there, and we
- * set from p2m[1][2][256->511] and p2m[1][488][0->256] with
- * IDENTITY_FRAME_BIT set.
- *
- * All other regions that are void (or not filled) either point to p2m_missing
- * (considered missing) or have the default value of INVALID_P2M_ENTRY (also
- * considered missing). In our case, p2m[1][2][0->255] and p2m[1][488][257->511]
- * contain the INVALID_P2M_ENTRY value and are considered "missing."
- *
- * Finally, the region beyond the end of of the E820 (4 GB in this example)
- * is set to be identity (in case there are MMIO regions placed here).
- *
- * This is what the p2m ends up looking (for the E820 above) with this
- * fabulous drawing:
- *
- *    p2m         /--------------\
- *  /-----\       | &mfn_list[0],|                           /-----------------\
- *  |  0  |------>| &mfn_list[1],|    /---------------\      | ~0, ~0, ..      |
- *  |-----|       |  ..., ~0, ~0 |    | ~0, ~0, [x]---+----->| IDENTITY [@256] |
- *  |  1  |---\   \--------------/    | [p2m_identity]+\     | IDENTITY [@257] |
- *  |-----|    \                      | [p2m_identity]+\\    | ....            |
- *  |  2  |--\  \-------------------->|  ...          | \\   \----------------/
- *  |-----|   \                       \---------------/  \\
- *  |  3  |-\  \                                          \\  p2m_identity [1]
- *  |-----|  \  \-------------------->/---------------\   /-----------------\
- *  | ..  |\  |                       | [p2m_identity]+-->| ~0, ~0, ~0, ... |
- *  \-----/ | |                       | [p2m_identity]+-->| ..., ~0         |
- *          | |                       | ....          |   \-----------------/
- *          | |                       +-[x], ~0, ~0.. +\
- *          | |                       \---------------/ \
- *          | |                                          \-> /---------------\
- *          | V  p2m_mid_missing       p2m_missing           | IDENTITY[@0]  |
- *          | /-----------------\     /------------\         | IDENTITY[@256]|
- *          | | [p2m_missing]   +---->| ~0, ~0, ...|         | ~0, ~0, ....  |
- *          | | [p2m_missing]   +---->| ..., ~0    |         \---------------/
- *          | | ...             |     \------------/
- *          | \-----------------/
- *          |
- *          |     p2m_mid_identity
- *          |   /-----------------\
- *          \-->| [p2m_identity]  +---->[1]
- *              | [p2m_identity]  +---->[1]
- *              | ...             |
- *              \-----------------/
- *
- * where ~0 is INVALID_P2M_ENTRY. IDENTITY is (PFN | IDENTITY_BIT)
  */
 
 #include <linux/init.h>
@@ -179,6 +81,8 @@
 #include "multicalls.h"
 #include "xen-ops.h"
 
+#define PMDS_PER_MID_PAGE	(P2M_MID_PER_PAGE / PTRS_PER_PTE)
+
 static void __init m2p_override_init(void);
 
 unsigned long *xen_p2m_addr __read_mostly;
@@ -188,22 +92,15 @@ EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
 EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
+static DEFINE_SPINLOCK(p2m_update_lock);
+
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
 static unsigned long **p2m_top_mfn_p;
-
-/* Placeholders for holes in the address space */
-static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long **, p2m_top, P2M_TOP_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long, p2m_identity, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
-
-RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
-
-static int use_brk = 1;
+static unsigned long *p2m_missing;
+static unsigned long *p2m_identity;
+static pte_t *p2m_missing_pte;
+static pte_t *p2m_identity_pte;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
@@ -221,14 +118,6 @@ static inline unsigned p2m_index(unsigned long pfn)
 	return pfn % P2M_PER_PAGE;
 }
 
-static void p2m_top_init(unsigned long ***top)
-{
-	unsigned i;
-
-	for (i = 0; i < P2M_TOP_PER_PAGE; i++)
-		top[i] = p2m_mid_missing;
-}
-
 static void p2m_top_mfn_init(unsigned long *top)
 {
 	unsigned i;
@@ -245,35 +134,32 @@ static void p2m_top_mfn_p_init(unsigned long **top)
 		top[i] = p2m_mid_missing_mfn;
 }
 
-static void p2m_mid_init(unsigned long **mid, unsigned long *leaf)
+static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
 {
 	unsigned i;
 
 	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = leaf;
+		mid[i] = virt_to_mfn(leaf);
 }
 
-static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
+static void p2m_init(unsigned long *p2m)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = virt_to_mfn(leaf);
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = INVALID_P2M_ENTRY;
 }
 
-static void p2m_init(unsigned long *p2m)
+static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		p2m[i] = INVALID_P2M_ENTRY;
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = IDENTITY_FRAME(pfn + i);
 }
 
 static void * __ref alloc_p2m_page(void)
 {
-	if (unlikely(use_brk))
-		return extend_brk(PAGE_SIZE, PAGE_SIZE);
-
 	if (unlikely(!slab_is_available()))
 		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
 
@@ -298,6 +184,9 @@ static void free_p2m_page(void *p)
 void __ref xen_build_mfn_list_list(void)
 {
 	unsigned long pfn;
+	pte_t *ptep;
+	unsigned int level, topidx, mididx;
+	unsigned long *mid_mfn_p;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
@@ -317,20 +206,22 @@ void __ref xen_build_mfn_list_list(void)
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 	}
 
-	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned long **mid;
-		unsigned long *mid_mfn_p;
+	for (pfn = 0; pfn < xen_max_p2m_pfn && pfn < MAX_P2M_PFN;
+	     pfn += P2M_PER_PAGE) {
+		topidx = p2m_top_index(pfn);
+		mididx = p2m_mid_index(pfn);
 
-		mid = p2m_top[topidx];
 		mid_mfn_p = p2m_top_mfn_p[topidx];
+		ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn),
+				      &level);
+		BUG_ON(!ptep || level != PG_LEVEL_4K);
+		ptep = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
 		/* Don't bother allocating any mfn mid levels if
 		 * they're just missing, just update the stored mfn,
 		 * since all could have changed over a migrate.
 		 */
-		if (mid == p2m_mid_missing) {
+		if (ptep == p2m_missing_pte || ptep == p2m_identity_pte) {
 			BUG_ON(mididx);
 			BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
 			p2m_top_mfn[topidx] = virt_to_mfn(p2m_mid_missing_mfn);
@@ -339,11 +230,6 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		if (mid_mfn_p == p2m_mid_missing_mfn) {
-			/*
-			 * XXX boot-time only!  We should never find
-			 * missing parts of the mfn tree after
-			 * runtime.
-			 */
 			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
@@ -351,7 +237,7 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
-		mid_mfn_p[mididx] = virt_to_mfn(mid[mididx]);
+		mid_mfn_p[mididx] = virt_to_mfn(xen_p2m_addr + pfn);
 	}
 }
 
@@ -370,154 +256,153 @@ void xen_setup_mfn_list_list(void)
 /* Set up p2m_top to point to the domain-builder provided p2m pages */
 void __init xen_build_dynamic_phys_to_machine(void)
 {
-	unsigned long *mfn_list;
-	unsigned long max_pfn;
 	unsigned long pfn;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
 	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
-	mfn_list = (unsigned long *)xen_start_info->mfn_list;
-	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
-	xen_max_p2m_pfn = max_pfn;
-	xen_p2m_size = max_pfn;
+	xen_p2m_size = ALIGN(xen_start_info->nr_pages, P2M_PER_PAGE);
 
-	p2m_missing = alloc_p2m_page();
-	p2m_init(p2m_missing);
-	p2m_identity = alloc_p2m_page();
-	p2m_init(p2m_identity);
+	for (pfn = xen_start_info->nr_pages; pfn < xen_p2m_size; pfn++)
+		xen_p2m_addr[pfn] = INVALID_P2M_ENTRY;
 
-	p2m_mid_missing = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_identity, p2m_identity);
+	xen_max_p2m_pfn = xen_p2m_size;
+}
 
-	p2m_top = alloc_p2m_page();
-	p2m_top_init(p2m_top);
+#define P2M_TYPE_IDENTITY	0
+#define P2M_TYPE_MISSING	1
+#define P2M_TYPE_PFN		2
+#define P2M_TYPE_UNKNOWN	3
 
-	/*
-	 * The domain builder gives us a pre-constructed p2m array in
-	 * mfn_list for all the pages initially given to us, so we just
-	 * need to graft that into our tree structure.
-	 */
-	for (pfn = 0; pfn < max_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
+static int xen_p2m_elem_type(unsigned long pfn)
+{
+	unsigned long mfn;
 
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = alloc_p2m_page();
-			p2m_mid_init(mid, p2m_missing);
+	if (pfn >= xen_p2m_size)
+		return P2M_TYPE_IDENTITY;
 
-			p2m_top[topidx] = mid;
-		}
+	mfn = xen_p2m_addr[pfn];
 
-		/*
-		 * As long as the mfn_list has enough entries to completely
-		 * fill a p2m page, pointing into the array is ok. But if
-		 * not the entries beyond the last pfn will be undefined.
-		 */
-		if (unlikely(pfn + P2M_PER_PAGE > max_pfn)) {
-			unsigned long p2midx;
+	if (mfn == INVALID_P2M_ENTRY)
+		return P2M_TYPE_MISSING;
 
-			p2midx = max_pfn % P2M_PER_PAGE;
-			for ( ; p2midx < P2M_PER_PAGE; p2midx++)
-				mfn_list[pfn + p2midx] = INVALID_P2M_ENTRY;
-		}
-		p2m_top[topidx][mididx] = &mfn_list[pfn];
-	}
+	if (mfn & IDENTITY_FRAME_BIT)
+		return P2M_TYPE_IDENTITY;
+
+	return P2M_TYPE_PFN;
 }
-#ifdef CONFIG_X86_64
-unsigned long __init xen_revector_p2m_tree(void)
+
+static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 {
-	unsigned long va_start;
-	unsigned long va_end;
+	unsigned int i, chunk;
 	unsigned long pfn;
-	unsigned long pfn_free = 0;
-	unsigned long *mfn_list = NULL;
-	unsigned long size;
-
-	use_brk = 0;
-	va_start = xen_start_info->mfn_list;
-	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
-	 * so make sure it is rounded up to that */
-	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
-	va_end = va_start + size;
-
-	/* If we were revectored already, don't do it again. */
-	if (va_start <= __START_KERNEL_map && va_start >= __PAGE_OFFSET)
-		return 0;
-
-	mfn_list = alloc_bootmem_align(size, PAGE_SIZE);
-	if (!mfn_list) {
-		pr_warn("Could not allocate space for a new P2M tree!\n");
-		return xen_start_info->mfn_list;
-	}
-	/* Fill it out with INVALID_P2M_ENTRY value */
-	memset(mfn_list, 0xFF, size);
-
-	for (pfn = 0; pfn < ALIGN(MAX_DOMAIN_PAGES, P2M_PER_PAGE); pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx;
-		unsigned long *mid_p;
+	unsigned long *mfns;
+	pte_t *ptep;
+	pmd_t *pmdp;
+	int type;
 
-		if (!p2m_top[topidx])
-			continue;
+	p2m_missing = alloc_p2m_page();
+	p2m_init(p2m_missing);
+	p2m_identity = alloc_p2m_page();
+	p2m_init(p2m_identity);
 
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
+	p2m_missing_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_missing_pte) >> PAGE_SHIFT);
+	p2m_identity_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
+	for (i = 0; i < PTRS_PER_PTE; i++) {
+		set_pte(p2m_missing_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
+		set_pte(p2m_identity_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
+	}
 
-		mididx = p2m_mid_index(pfn);
-		mid_p = p2m_top[topidx][mididx];
-		if (!mid_p)
-			continue;
-		if ((mid_p == p2m_missing) || (mid_p == p2m_identity))
+	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
+		/*
+		 * Try to map missing/identity PMDs or p2m-pages if possible.
+		 * We have to respect the structure of the mfn_list_list
+		 * which will be built a little bit later.
+		 * Chunk size to test is one p2m page if we are in the middle
+		 * of a mfn_list_list mid page and the complete mid page area
+		 * if we are at index 0 of the mid page. Please note that a
+		 * mid page might cover more than one PMD, e.g. on 32 bit PAE
+		 * kernels.
+		 */
+		chunk = (pfn & (P2M_PER_PAGE * P2M_MID_PER_PAGE - 1)) ?
+			P2M_PER_PAGE : P2M_PER_PAGE * P2M_MID_PER_PAGE;
+
+		type = xen_p2m_elem_type(pfn);
+		i = 0;
+		if (type != P2M_TYPE_PFN)
+			for (i = 1; i < chunk; i++)
+				if (xen_p2m_elem_type(pfn + i) != type)
+					break;
+		if (i < chunk)
+			/* Reset to minimal chunk size. */
+			chunk = P2M_PER_PAGE;
+
+		if (type == P2M_TYPE_PFN || i < chunk) {
+			/* Use initial p2m page contents. */
+#ifdef CONFIG_X86_64
+			mfns = alloc_p2m_page();
+			copy_page(mfns, xen_p2m_addr + pfn);
+#else
+			mfns = xen_p2m_addr + pfn;
+#endif
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		if ((unsigned long)mid_p == INVALID_P2M_ENTRY)
+		if (chunk == P2M_PER_PAGE) {
+			/* Map complete missing or identity p2m-page. */
+			mfns = (type == P2M_TYPE_MISSING) ?
+				p2m_missing : p2m_identity;
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		/* The old va. Rebase it on mfn_list */
-		if (mid_p >= (unsigned long *)va_start && mid_p <= (unsigned long *)va_end) {
-			unsigned long *new;
+		/* Complete missing or identity PMD(s) can be mapped. */
+		ptep = (type == P2M_TYPE_MISSING) ?
+			p2m_missing_pte : p2m_identity_pte;
+		for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+			pmdp = populate_extra_pmd(
+				(unsigned long)(p2m + pfn + i * PTRS_PER_PTE));
+			set_pmd(pmdp, __pmd(__pa(ptep) | _KERNPG_TABLE));
+		}
+	}
+}
 
-			if (pfn_free  > (size / sizeof(unsigned long))) {
-				WARN(1, "Only allocated for %ld pages, but we want %ld!\n",
-				     size / sizeof(unsigned long), pfn_free);
-				return 0;
-			}
-			new = &mfn_list[pfn_free];
+void __init xen_vmalloc_p2m_tree(void)
+{
+	static struct vm_struct vm;
 
-			copy_page(new, mid_p);
-			p2m_top[topidx][mididx] = &mfn_list[pfn_free];
+	vm.flags = VM_ALLOC;
+	vm.size = ALIGN(sizeof(unsigned long) * xen_max_p2m_pfn,
+			PMD_SIZE * PMDS_PER_MID_PAGE);
+	vm_area_register_early(&vm, PMD_SIZE * PMDS_PER_MID_PAGE);
+	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);
 
-			pfn_free += P2M_PER_PAGE;
+	xen_max_p2m_pfn = vm.size / sizeof(unsigned long);
 
-		}
-		/* This should be the leafs allocated for identity from _brk. */
-	}
+	xen_rebuild_p2m_list(vm.addr);
 
+	xen_p2m_addr = vm.addr;
 	xen_p2m_size = xen_max_p2m_pfn;
-	xen_p2m_addr = mfn_list;
 
 	xen_inv_extra_mem();
 
 	m2p_override_init();
-	return (unsigned long)mfn_list;
 }
-#else
-unsigned long __init xen_revector_p2m_tree(void)
-{
-	use_brk = 0;
-	xen_p2m_size = xen_max_p2m_pfn;
-	xen_inv_extra_mem();
-	m2p_override_init();
-	return 0;
-}
-#endif
+
 unsigned long get_phys_to_machine(unsigned long pfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	if (unlikely(pfn >= xen_p2m_size)) {
 		if (pfn < xen_max_p2m_pfn)
@@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 		return IDENTITY_FRAME(pfn);
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
 	/*
 	 * The INVALID_P2M_ENTRY is filled in both p2m_*identity
 	 * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
 	 * would be wrong.
 	 */
-	if (p2m_top[topidx][mididx] == p2m_identity)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
 		return IDENTITY_FRAME(pfn);
 
-	return p2m_top[topidx][mididx][idx];
+	return xen_p2m_addr[pfn];
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
 /*
+ * Allocate new pmd(s). It is checked whether the old pmd is still in place.
+ * If not, nothing is changed. This is okay as the only reason for allocating
+ * a new pmd is to replace p2m_missing_pte or p2m_identity_pte by a individual
+ * pmd. In case of PAE/x86-32 there are multiple pmds to allocate!
+ */
+static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t *ptep, pte_t *pte_pg)
+{
+	pte_t *ptechk;
+	pte_t *pteret = ptep;
+	pte_t *pte_newpg[PMDS_PER_MID_PAGE];
+	pmd_t *pmdp;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long vaddr;
+	int i;
+
+	/* Do all allocations first to bail out in error case. */
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		pte_newpg[i] = alloc_p2m_page();
+		if (!pte_newpg[i]) {
+			for (i--; i >= 0; i--)
+				free_p2m_page(pte_newpg[i]);
+
+			return NULL;
+		}
+	}
+
+	vaddr = addr & ~(PMD_SIZE * PMDS_PER_MID_PAGE - 1);
+
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		copy_page(pte_newpg[i], pte_pg);
+		paravirt_alloc_pte(&init_mm, __pa(pte_newpg[i]) >> PAGE_SHIFT);
+
+		pmdp = lookup_pmd_address(vaddr);
+		BUG_ON(!pmdp);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		ptechk = lookup_address(vaddr, &level);
+		if (ptechk == pte_pg) {
+			set_pmd(pmdp,
+				__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+			if (vaddr == (addr & ~(PMD_SIZE - 1)))
+				pteret = pte_offset_kernel(pmdp, addr);
+			pte_newpg[i] = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
+
+		if (pte_newpg[i]) {
+			paravirt_release_pte(__pa(pte_newpg[i]) >> PAGE_SHIFT);
+			free_p2m_page(pte_newpg[i]);
+		}
+
+		vaddr += PMD_SIZE;
+	}
+
+	return pteret;
+}
+
+/*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
  * parallel mfn tree is kept in sync.  We may race with other cpus, so
@@ -552,58 +497,62 @@ EXPORT_SYMBOL_GPL(get_phys_to_machine);
 static bool alloc_p2m(unsigned long pfn)
 {
 	unsigned topidx, mididx;
-	unsigned long ***top_p, **mid;
 	unsigned long *top_mfn_p, *mid_mfn;
-	unsigned long *p2m_orig;
+	pte_t *ptep, *pte_pg;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long addr = (unsigned long)(xen_p2m_addr + pfn);
+	unsigned long p2m_pfn;
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
 
-	top_p = &p2m_top[topidx];
-	mid = ACCESS_ONCE(*top_p);
+	ptep = lookup_address(addr, &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
+	pte_pg = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
-	if (mid == p2m_mid_missing) {
-		/* Mid level is missing, allocate a new one */
-		mid = alloc_p2m_page();
-		if (!mid)
+	if (pte_pg == p2m_missing_pte || pte_pg == p2m_identity_pte) {
+		/* PMD level is missing, allocate a new one */
+		ptep = alloc_p2m_pmd(addr, ptep, pte_pg);
+		if (!ptep)
 			return false;
-
-		p2m_mid_init(mid, p2m_missing);
-
-		if (cmpxchg(top_p, p2m_mid_missing, mid) != p2m_mid_missing)
-			free_p2m_page(mid);
 	}
 
-	top_mfn_p = &p2m_top_mfn[topidx];
-	mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
+	if (p2m_top_mfn) {
+		top_mfn_p = &p2m_top_mfn[topidx];
+		mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
 
-	BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
+		BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
 
-	if (mid_mfn == p2m_mid_missing_mfn) {
-		/* Separately check the mid mfn level */
-		unsigned long missing_mfn;
-		unsigned long mid_mfn_mfn;
-		unsigned long old_mfn;
+		if (mid_mfn == p2m_mid_missing_mfn) {
+			/* Separately check the mid mfn level */
+			unsigned long missing_mfn;
+			unsigned long mid_mfn_mfn;
+			unsigned long old_mfn;
 
-		mid_mfn = alloc_p2m_page();
-		if (!mid_mfn)
-			return false;
+			mid_mfn = alloc_p2m_page();
+			if (!mid_mfn)
+				return false;
 
-		p2m_mid_mfn_init(mid_mfn, p2m_missing);
+			p2m_mid_mfn_init(mid_mfn, p2m_missing);
 
-		missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
-		mid_mfn_mfn = virt_to_mfn(mid_mfn);
-		old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
-		if (old_mfn != missing_mfn) {
-			free_p2m_page(mid_mfn);
-			mid_mfn = mfn_to_virt(old_mfn);
-		} else {
-			p2m_top_mfn_p[topidx] = mid_mfn;
+			missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
+			mid_mfn_mfn = virt_to_mfn(mid_mfn);
+			old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
+			if (old_mfn != missing_mfn) {
+				free_p2m_page(mid_mfn);
+				mid_mfn = mfn_to_virt(old_mfn);
+			} else {
+				p2m_top_mfn_p[topidx] = mid_mfn;
+			}
 		}
+	} else {
+		mid_mfn = NULL;
 	}
 
-	p2m_orig = ACCESS_ONCE(p2m_top[topidx][mididx]);
-	if (p2m_orig == p2m_identity || p2m_orig == p2m_missing) {
+	p2m_pfn = pte_pfn(ACCESS_ONCE(*ptep));
+	if (p2m_pfn == PFN_DOWN(__pa(p2m_identity)) ||
+	    p2m_pfn == PFN_DOWN(__pa(p2m_missing))) {
 		/* p2m leaf page is missing */
 		unsigned long *p2m;
 
@@ -611,12 +560,25 @@ static bool alloc_p2m(unsigned long pfn)
 		if (!p2m)
 			return false;
 
-		p2m_init(p2m);
+		if (p2m_pfn == PFN_DOWN(__pa(p2m_missing)))
+			p2m_init(p2m);
+		else
+			p2m_init_identity(p2m, pfn);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		if (pte_pfn(*ptep) == p2m_pfn) {
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(p2m)), PAGE_KERNEL));
+			if (mid_mfn)
+				mid_mfn[mididx] = virt_to_mfn(p2m);
+			p2m = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
 
-		if (cmpxchg(&mid[mididx], p2m_orig, p2m) != p2m_orig)
+		if (p2m)
 			free_p2m_page(p2m);
-		else
-			mid_mfn[mididx] = virt_to_mfn(p2m);
 	}
 
 	return true;
@@ -645,10 +607,10 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	return pfn - pfn_s;
 }
 
-/* Try to install p2m mapping; fail if intermediate bits missing */
 bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	/* don't track P2M changes in autotranslate guests */
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -659,55 +621,27 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* For sparse holes were the p2m leaf has real PFN along with
-	 * PCI holes, stick in the PFN as the MFN value.
-	 *
-	 * set_phys_range_identity() will have allocated new middle
-	 * and leaf pages as required so an existing p2m_mid_missing
-	 * or p2m_missing mean that whole range will be identity so
-	 * these can be switched to p2m_mid_identity or p2m_identity.
-	 */
-	if (mfn != INVALID_P2M_ENTRY && (mfn & IDENTITY_FRAME_BIT)) {
-		if (p2m_top[topidx] == p2m_mid_identity)
-			return true;
-
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx], p2m_mid_missing,
-					p2m_mid_identity) != p2m_mid_missing);
-			return true;
-		}
-
-		if (p2m_top[topidx][mididx] == p2m_identity)
-			return true;
-
-		/* Swap over from MISSING to IDENTITY if needed. */
-		if (p2m_top[topidx][mididx] == p2m_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx][mididx], p2m_missing,
-				p2m_identity) != p2m_missing);
-			return true;
-		}
-	}
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
-	if (p2m_top[topidx][mididx] == p2m_missing)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_missing)))
 		return mfn == INVALID_P2M_ENTRY;
 
-	p2m_top[topidx][mididx][idx] = mfn;
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
+		return mfn == IDENTITY_FRAME(pfn);
+
+	xen_p2m_addr[pfn] = mfn;
 
 	return true;
 }
 
 bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
+	if (unlikely(!__set_phys_to_machine(pfn, mfn))) {
 		if (!alloc_p2m(pfn))
 			return false;
 
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
+		return __set_phys_to_machine(pfn, mfn);
 	}
 
 	return true;
@@ -785,7 +719,7 @@ static int m2p_add_override(unsigned long mfn, struct page *page,
 	 * because mfn_to_pfn (that ends up being called by GUPF) will
 	 * return the backend pfn rather than the frontend pfn. */
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == mfn)
+	if (__pfn_to_mfn(pfn) == mfn)
 		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
 
 	return 0;
@@ -967,7 +901,7 @@ static int m2p_remove_override(struct page *page,
 	 * pfn again. */
 	mfn &= ~FOREIGN_FRAME_BIT;
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
+	if (__pfn_to_mfn(pfn) == FOREIGN_FRAME(mfn) &&
 			m2p_find_override(mfn) == NULL)
 		set_phys_to_machine(pfn, mfn);
 
@@ -1035,79 +969,29 @@ EXPORT_SYMBOL_GPL(m2p_find_override_pfn);
 #include "debugfs.h"
 static int p2m_dump_show(struct seq_file *m, void *v)
 {
-	static const char * const level_name[] = { "top", "middle",
-						"entry", "abnormal", "error"};
-#define TYPE_IDENTITY 0
-#define TYPE_MISSING 1
-#define TYPE_PFN 2
-#define TYPE_UNKNOWN 3
 	static const char * const type_name[] = {
-				[TYPE_IDENTITY] = "identity",
-				[TYPE_MISSING] = "missing",
-				[TYPE_PFN] = "pfn",
-				[TYPE_UNKNOWN] = "abnormal"};
-	unsigned long pfn, prev_pfn_type = 0, prev_pfn_level = 0;
-	unsigned int uninitialized_var(prev_level);
-	unsigned int uninitialized_var(prev_type);
-
-	if (!p2m_top)
-		return 0;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn++) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned idx = p2m_index(pfn);
-		unsigned lvl, type;
-
-		lvl = 4;
-		type = TYPE_UNKNOWN;
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			lvl = 0; type = TYPE_MISSING;
-		} else if (p2m_top[topidx] == NULL) {
-			lvl = 0; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == NULL) {
-			lvl = 1; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == p2m_identity) {
-			lvl = 1; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx] == p2m_missing) {
-			lvl = 1; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == 0) {
-			lvl = 2; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx][idx] == IDENTITY_FRAME(pfn)) {
-			lvl = 2; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx][idx] == INVALID_P2M_ENTRY) {
-			lvl = 2; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == pfn) {
-			lvl = 2; type = TYPE_PFN;
-		} else if (p2m_top[topidx][mididx][idx] != pfn) {
-			lvl = 2; type = TYPE_PFN;
-		}
-		if (pfn == 0) {
-			prev_level = lvl;
+				[P2M_TYPE_IDENTITY] = "identity",
+				[P2M_TYPE_MISSING] = "missing",
+				[P2M_TYPE_PFN] = "pfn",
+				[P2M_TYPE_UNKNOWN] = "abnormal"};
+	unsigned long pfn, first_pfn;
+	int type, prev_type;
+
+	prev_type = xen_p2m_elem_type(0);
+	first_pfn = 0;
+
+	for (pfn = 0; pfn < xen_p2m_size; pfn++) {
+		type = xen_p2m_elem_type(pfn);
+		if (type != prev_type) {
+			seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+				   type_name[prev_type]);
 			prev_type = type;
-		}
-		if (pfn == MAX_DOMAIN_PAGES-1) {
-			lvl = 3;
-			type = TYPE_UNKNOWN;
-		}
-		if (prev_type != type) {
-			seq_printf(m, " [0x%lx->0x%lx] %s\n",
-				prev_pfn_type, pfn, type_name[prev_type]);
-			prev_pfn_type = pfn;
-			prev_type = type;
-		}
-		if (prev_level != lvl) {
-			seq_printf(m, " [0x%lx->0x%lx] level %s\n",
-				prev_pfn_level, pfn, level_name[prev_level]);
-			prev_pfn_level = pfn;
-			prev_level = lvl;
+			first_pfn = pfn;
 		}
 	}
+	seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+		   type_name[prev_type]);
 	return 0;
-#undef TYPE_IDENTITY
-#undef TYPE_MISSING
-#undef TYPE_PFN
-#undef TYPE_UNKNOWN
 }
 
 static int p2m_dump_open(struct inode *inode, struct file *filp)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 02b0b0f..f92921f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -49,7 +49,7 @@ void xen_hvm_init_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-unsigned long __init xen_revector_p2m_tree(void);
+void __init xen_vmalloc_p2m_tree(void);
 
 void xen_init_irq_ops(void);
 void xen_setup_timer(int cpu);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv6-0007yf-3H; Thu, 06 Nov 2014 05:47:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv4-0007xv-6n
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:42 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7D/15-24532-D7B0B545; Thu, 06 Nov 2014 05:47:41 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415252860!11778740!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18569 invoked from network); 6 Nov 2014 05:47:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:40 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8ABC1ADA7;
	Thu,  6 Nov 2014 05:47:39 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:31 +0100
Message-Id: <1415252853-7106-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415252853-7106-1-git-send-email-jgross@suse.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 3/5] xen: Delay invalidating extra memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When the physical memory configuration is initialized the p2m entries
for not pouplated memory pages are set to "invalid". As those pages
are beyond the hypervisor built p2m list the p2m tree has to be
extended.

This patch delays processing the extra memory related p2m entries
during the boot process until some more basic memory management
functions are callable. This removes the need to create new p2m
entries until virtual memory management is available.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |   3 +
 arch/x86/xen/p2m.c              | 130 ++++++++--------------------------------
 arch/x86/xen/setup.c            | 103 ++++++++++++++++++++++---------
 arch/x86/xen/xen-ops.h          |   3 +-
 4 files changed, 107 insertions(+), 132 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index b475297..28fa795 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -41,6 +41,9 @@ typedef struct xpaddr {
 
 extern unsigned long *machine_to_phys_mapping;
 extern unsigned long  machine_to_phys_nr;
+extern unsigned long *xen_p2m_addr;
+extern unsigned long  xen_p2m_size;
+extern unsigned long  xen_max_p2m_pfn;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 2647a65..7c409b0 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -181,7 +181,12 @@
 
 static void __init m2p_override_init(void);
 
+unsigned long *xen_p2m_addr __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_addr);
+unsigned long xen_p2m_size __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
+EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
@@ -198,13 +203,6 @@ static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
 
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
 
-/* For each I/O range remapped we may lose up to two leaf pages for the boundary
- * violations and three mid pages to cover up to 3GB. With
- * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
- * remapped region.
- */
-RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
-
 static int use_brk = 1;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
@@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	unsigned long max_pfn;
 	unsigned long pfn;
 
-	 if (xen_feature(XENFEAT_auto_translated_physmap))
+	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
+	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
 	mfn_list = (unsigned long *)xen_start_info->mfn_list;
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
+	xen_p2m_size = max_pfn;
 
 	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
@@ -497,6 +497,11 @@ unsigned long __init xen_revector_p2m_tree(void)
 		/* This should be the leafs allocated for identity from _brk. */
 	}
 
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_p2m_addr = mfn_list;
+
+	xen_inv_extra_mem();
+
 	m2p_override_init();
 	return (unsigned long)mfn_list;
 }
@@ -504,6 +509,8 @@ unsigned long __init xen_revector_p2m_tree(void)
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_inv_extra_mem();
 	m2p_override_init();
 	return 0;
 }
@@ -512,8 +519,12 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(pfn >= MAX_P2M_PFN))
+	if (unlikely(pfn >= xen_p2m_size)) {
+		if (pfn < xen_max_p2m_pfn)
+			return xen_chk_extra_mem(pfn);
+
 		return IDENTITY_FRAME(pfn);
+	}
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
@@ -611,78 +622,12 @@ static bool alloc_p2m(unsigned long pfn)
 	return true;
 }
 
-static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
-{
-	unsigned topidx, mididx, idx;
-	unsigned long *p2m;
-
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* Pfff.. No boundary cross-over, lets get out. */
-	if (!idx && check_boundary)
-		return false;
-
-	WARN(p2m_top[topidx][mididx] == p2m_identity,
-		"P2M[%d][%d] == IDENTITY, should be MISSING (or alloced)!\n",
-		topidx, mididx);
-
-	/*
-	 * Could be done by xen_build_dynamic_phys_to_machine..
-	 */
-	if (p2m_top[topidx][mididx] != p2m_missing)
-		return false;
-
-	/* Boundary cross-over for the edges: */
-	p2m = alloc_p2m_page();
-
-	p2m_init(p2m);
-
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-
-static bool __init early_alloc_p2m_middle(unsigned long pfn)
-{
-	unsigned topidx = p2m_top_index(pfn);
-	unsigned long **mid;
-
-	mid = p2m_top[topidx];
-	if (mid == p2m_mid_missing) {
-		mid = alloc_p2m_page();
-
-		p2m_mid_init(mid, p2m_missing);
-
-		p2m_top[topidx] = mid;
-	}
-	return true;
-}
-
-static void __init early_split_p2m(unsigned long pfn)
-{
-	unsigned long mididx, idx;
-
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/*
-	 * Allocate new middle and leaf pages if this pfn lies in the
-	 * middle of one.
-	 */
-	if (mididx || idx)
-		early_alloc_p2m_middle(pfn);
-	if (idx)
-		early_alloc_p2m(pfn, false);
-}
-
 unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 				      unsigned long pfn_e)
 {
 	unsigned long pfn;
 
-	if (unlikely(pfn_s >= MAX_P2M_PFN))
+	if (unlikely(pfn_s >= xen_p2m_size))
 		return 0;
 
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -691,34 +636,11 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	if (pfn_s > pfn_e)
 		return 0;
 
-	if (pfn_e > MAX_P2M_PFN)
-		pfn_e = MAX_P2M_PFN;
-
-	early_split_p2m(pfn_s);
-	early_split_p2m(pfn_e);
-
-	for (pfn = pfn_s; pfn < pfn_e;) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-
-		if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
-			break;
-		pfn++;
-
-		/*
-		 * If the PFN was set to a middle or leaf identity
-		 * page the remainder must also be identity, so skip
-		 * ahead to the next middle or leaf entry.
-		 */
-		if (p2m_top[topidx] == p2m_mid_identity)
-			pfn = ALIGN(pfn, P2M_MID_PER_PAGE * P2M_PER_PAGE);
-		else if (p2m_top[topidx][mididx] == p2m_identity)
-			pfn = ALIGN(pfn, P2M_PER_PAGE);
-	}
+	if (pfn_e > xen_p2m_size)
+		pfn_e = xen_p2m_size;
 
-	WARN((pfn - pfn_s) != (pfn_e - pfn_s),
-		"Identity mapping failed. We are %ld short of 1-1 mappings!\n",
-		(pfn_e - pfn_s) - (pfn - pfn_s));
+	for (pfn = pfn_s; pfn < pfn_e; pfn++)
+		xen_p2m_addr[pfn] = IDENTITY_FRAME(pfn);
 
 	return pfn - pfn_s;
 }
@@ -732,7 +654,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
 		return true;
 
-	if (unlikely(pfn >= MAX_P2M_PFN)) {
+	if (unlikely(pfn >= xen_p2m_size)) {
 		BUG_ON(mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 0e5f9b6..8d5985b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -75,7 +75,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 static void __init xen_add_extra_mem(u64 start, u64 size)
 {
-	unsigned long pfn;
 	int i;
 
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
@@ -95,17 +94,74 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
 
 	memblock_reserve(start, size);
+}
 
-	xen_max_p2m_pfn = PFN_DOWN(start + size);
-	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
-		unsigned long mfn = pfn_to_mfn(pfn);
+static void __init xen_del_extra_mem(u64 start, u64 size)
+{
+	int i;
+	u64 start_r, size_r;
 
-		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
-			continue;
-		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
-			  pfn, mfn);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		start_r = xen_extra_mem[i].start;
+		size_r = xen_extra_mem[i].size;
+
+		/* Start of region. */
+		if (start_r == start) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].start += size;
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* End of region. */
+		if (start_r + size_r == start + size) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* Mid of region. */
+		if (start > start_r && start < start_r + size_r) {
+			BUG_ON(start + size > start_r + size_r);
+			xen_extra_mem[i].size = start - start_r;
+			xen_add_extra_mem(start + size, start_r + size_r -
+					  (start + size));
+			break;
+		}
+	}
+	memblock_free(start, size);
+}
+
+/*
+ * Called during boot before the p2m list can take entries beyond the
+ * hypervisor supplied p2m list. Entries in extra mem are to be regarded as
+ * invalid.
+ */
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
+{
+	int i;
+	unsigned long addr = PFN_PHYS(pfn);
 
-		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		if (addr >= xen_extra_mem[i].start &&
+		    addr < xen_extra_mem[i].start + xen_extra_mem[i].size)
+			return INVALID_P2M_ENTRY;
+	}
+
+	return IDENTITY_FRAME(pfn);
+}
+
+/*
+ * Mark all pfns of extra mem as invalid in p2m list.
+ */
+void __init xen_inv_extra_mem(void)
+{
+	unsigned long pfn, pfn_s, pfn_e;
+	int i;
+
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		pfn_s = PFN_DOWN(xen_extra_mem[i].start);
+		pfn_e = PFN_UP(xen_extra_mem[i].start + xen_extra_mem[i].size);
+		for (pfn = pfn_s; pfn < pfn_e; pfn++)
+			set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 	}
 }
 
@@ -269,9 +325,6 @@ static void __init xen_do_set_identity_and_remap_chunk(
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/* Don't use memory until remapped */
-	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
-
 	mfn_save = virt_to_mfn(buf);
 
 	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
@@ -315,7 +368,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
  * pages. In the case of an error the underlying memory is simply released back
  * to Xen and not remapped.
  */
-static unsigned long __init xen_set_identity_and_remap_chunk(
+static unsigned long xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
 	unsigned long *identity, unsigned long *released)
@@ -372,7 +425,7 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 	return remap_pfn;
 }
 
-static unsigned long __init xen_set_identity_and_remap(
+static void __init xen_set_identity_and_remap(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages,
 	unsigned long *released)
 {
@@ -416,8 +469,6 @@ static unsigned long __init xen_set_identity_and_remap(
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
 	pr_info("Released %ld page(s)\n", num_released);
-
-	return last_pfn;
 }
 
 /*
@@ -449,8 +500,9 @@ void __init xen_remap_memory(void)
 			} else {
 				if (!released) {
 					if (pfn_s != ~0UL && len)
-						memblock_free(PFN_PHYS(pfn_s),
-							      PFN_PHYS(len));
+						xen_del_extra_mem(
+							PFN_PHYS(pfn_s),
+							PFN_PHYS(len));
 					pfn_s = xen_remap_buf.target_pfn;
 					len = i;
 				}
@@ -470,7 +522,8 @@ void __init xen_remap_memory(void)
 			} else if (pfn_s + len == xen_remap_buf.target_pfn) {
 				len += xen_remap_buf.size;
 			} else {
-				memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+				xen_del_extra_mem(PFN_PHYS(pfn_s),
+						  PFN_PHYS(len));
 				pfn_s = xen_remap_buf.target_pfn;
 				len = xen_remap_buf.size;
 			}
@@ -484,7 +537,7 @@ void __init xen_remap_memory(void)
 	}
 
 	if (pfn_s != ~0UL && len)
-		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+		xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
 
 	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 
@@ -553,7 +606,6 @@ char * __init xen_memory_setup(void)
 	int rc;
 	struct xen_memory_map memmap;
 	unsigned long max_pages;
-	unsigned long last_pfn = 0;
 	unsigned long extra_pages = 0;
 	int i;
 	int op;
@@ -603,15 +655,11 @@ char * __init xen_memory_setup(void)
 	 * Set identity map on non-RAM pages and prepare remapping the
 	 * underlying RAM.
 	 */
-	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
-					      &xen_released_pages);
+	xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
+				   &xen_released_pages);
 
 	extra_pages += xen_released_pages;
 
-	if (last_pfn > max_pfn) {
-		max_pfn = min(MAX_DOMAIN_PAGES, last_pfn);
-		mem_end = PFN_PHYS(max_pfn);
-	}
 	/*
 	 * Clamp the amount of extra memory to a EXTRA_MEM_RATIO
 	 * factor the base size.  On non-highmem systems, the base
@@ -638,6 +686,7 @@ char * __init xen_memory_setup(void)
 				size = min(size, (u64)extra_pages * PAGE_SIZE);
 				extra_pages -= size / PAGE_SIZE;
 				xen_add_extra_mem(addr, size);
+				xen_max_p2m_pfn = PFN_DOWN(addr + size);
 			} else
 				type = E820_UNUSABLE;
 		}
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 5b72a06..02b0b0f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -29,12 +29,13 @@ void xen_build_mfn_list_list(void);
 void xen_setup_machphys_mapping(void);
 void xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn);
 void xen_reserve_top(void);
-extern unsigned long xen_max_p2m_pfn;
 
 void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn);
+void __init xen_inv_extra_mem(void);
 void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv5-0007yG-0S; Thu, 06 Nov 2014 05:47:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv3-0007xk-FE
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:41 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5C/15-24532-C7B0B545; Thu, 06 Nov 2014 05:47:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415252860!11778741!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18562 invoked from network); 6 Nov 2014 05:47:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:40 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CFF9FADA8;
	Thu,  6 Nov 2014 05:47:39 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:32 +0100
Message-Id: <1415252853-7106-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415252853-7106-1-git-send-email-jgross@suse.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 4/5] x86: Introduce function to get pmd entry
	pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduces lookup_pmd_address() to get the address of the pmd entry
related to a virtual address in the current address space. This
function is needed for support of a virtual mapped sparse p2m list
in xen pv domains.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/pgtable_types.h |  1 +
 arch/x86/mm/pageattr.c               | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0778964..d83f5e7 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -396,6 +396,7 @@ static inline void update_page_count(int level, unsigned long pages) { }
 extern pte_t *lookup_address(unsigned long address, unsigned int *level);
 extern pte_t *lookup_address_in_pgd(pgd_t *pgd, unsigned long address,
 				    unsigned int *level);
+extern pmd_t *lookup_pmd_address(unsigned long address);
 extern phys_addr_t slow_virt_to_phys(void *__address);
 extern int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
 				   unsigned numpages, unsigned long page_flags);
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 36de293..1298108 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -384,6 +384,26 @@ static pte_t *_lookup_address_cpa(struct cpa_data *cpa, unsigned long address,
 }
 
 /*
+ * Lookup the PMD entry for a virtual address. Return a pointer to the entry
+ * or NULL if not present.
+ */
+pmd_t *lookup_pmd_address(unsigned long address)
+{
+	pgd_t *pgd;
+	pud_t *pud;
+
+	pgd = pgd_offset_k(address);
+	if (pgd_none(*pgd))
+		return NULL;
+
+	pud = pud_offset(pgd, address);
+	if (pud_none(*pud) || pud_large(*pud) || !pud_present(*pud))
+		return NULL;
+
+	return pmd_offset(pud, address);
+}
+
+/*
  * This is necessary because __pa() does not work on some
  * kinds of memory, like vmalloc() or the alloc_remap()
  * areas on 32-bit NUMA systems.  The percpu areas can
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv4-0007y9-Lz; Thu, 06 Nov 2014 05:47:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv3-0007xj-CA
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:41 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	5C/20-07724-C7B0B545; Thu, 06 Nov 2014 05:47:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415252859!11916861!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13060 invoked from network); 6 Nov 2014 05:47:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:40 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 925FFAD8A;
	Thu,  6 Nov 2014 05:47:38 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:28 +0100
Message-Id: <1415252853-7106-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 0/5] xen: Switch to virtual mapped linear p2m
	list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paravirtualized kernels running on Xen use a three level tree for
translation of guest specific physical addresses to machine global
addresses. This p2m tree is used for construction of page table
entries, so the p2m tree walk is performance critical.

By using a linear virtual mapped p2m list accesses to p2m elements
can be sped up while even simplifying code. To achieve this goal
some p2m related initializations have to be performed later in the
boot process, as the final p2m list can be set up only after basic
memory management functions are available.

Changes in V2:
- splitted patch 2 in 4 smaller ones as requested by David Vrabel
- added highmem check when remapping kernel memory as requested by
  David Vrabel

Juergen Gross (5):
  Xen: Delay remapping memory of pv-domain
  xen: Delay m2p_override initialization
  xen: Delay invalidating extra memory
  x86: Introduce function to get pmd entry pointer
  Xen: switch to linear virtual mapped sparse p2m list

 arch/x86/include/asm/pgtable_types.h |    1 +
 arch/x86/include/asm/xen/page.h      |   37 +-
 arch/x86/mm/pageattr.c               |   20 +
 arch/x86/xen/mmu.c                   |   38 +-
 arch/x86/xen/p2m.c                   | 1149 +++++++++++++---------------------
 arch/x86/xen/setup.c                 |  460 +++++++-------
 arch/x86/xen/xen-ops.h               |    6 +-
 7 files changed, 760 insertions(+), 951 deletions(-)

-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv5-0007yY-Nk; Thu, 06 Nov 2014 05:47:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv4-0007xp-1T
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:42 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	C7/74-14727-D7B0B545; Thu, 06 Nov 2014 05:47:41 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415252859!11471356!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7912 invoked from network); 6 Nov 2014 05:47:39 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:39 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DAFB4ADA1;
	Thu,  6 Nov 2014 05:47:38 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:29 +0100
Message-Id: <1415252853-7106-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415252853-7106-1-git-send-email-jgross@suse.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 1/5] Xen: Delay remapping memory of pv-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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Early in the boot process the memory layout of a pv-domain is changed
to match the E820 map (either the host one for Dom0 or the Xen one)
regarding placement of RAM and PCI holes. This requires removing memory
pages initially located at positions not suitable for RAM and adding
them later at higher addresses where no restrictions apply.

To be able to operate on the hypervisor supported p2m list until a
virtual mapped linear p2m list can be constructed, remapping must
be delayed until virtual memory management is initialized, as the
initial p2m list can't be extended unlimited at physical memory
initialization time due to it's fixed structure.

A further advantage is the reduction in complexity and code volume as
we don't have to be careful regarding memory restrictions during p2m
updates.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |   1 -
 arch/x86/xen/mmu.c              |   4 +
 arch/x86/xen/p2m.c              | 149 ++++------------
 arch/x86/xen/setup.c            | 385 +++++++++++++++++++---------------------
 arch/x86/xen/xen-ops.h          |   1 +
 5 files changed, 223 insertions(+), 317 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c949923..c29619c 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -44,7 +44,6 @@ extern unsigned long  machine_to_phys_nr;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
-extern bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 					     unsigned long pfn_e);
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a8a1a3d..d3e492b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1223,6 +1223,10 @@ static void __init xen_pagetable_init(void)
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
+	/* Remap memory freed because of conflicts with E820 map */
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_remap_memory();
+
 	xen_setup_shared_info();
 	xen_post_allocator_init();
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index b456b04..49316ac 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -164,6 +164,7 @@
 #include <linux/sched.h>
 #include <linux/seq_file.h>
 #include <linux/bootmem.h>
+#include <linux/slab.h>
 
 #include <asm/cache.h>
 #include <asm/setup.h>
@@ -204,6 +205,8 @@ RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER
  */
 RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
+static int use_brk = 1;
+
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
 	BUG_ON(pfn >= MAX_P2M_PFN);
@@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
 		p2m[i] = INVALID_P2M_ENTRY;
 }
 
+static void * __ref alloc_p2m_page(void)
+{
+	if (unlikely(use_brk))
+		return extend_brk(PAGE_SIZE, PAGE_SIZE);
+
+	if (unlikely(!slab_is_available()))
+		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+
+	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static void free_p2m_page(void *p)
+{
+	free_page((unsigned long)p);
+}
+
 /*
  * Build the parallel p2m_top_mfn and p2m_mid_mfn structures
  *
@@ -287,13 +306,13 @@ void __ref xen_build_mfn_list_list(void)
 
 	/* Pre-initialize p2m_top_mfn to be completely missing */
 	if (p2m_top_mfn == NULL) {
-		p2m_mid_missing_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_mid_missing_mfn = alloc_p2m_page();
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 
-		p2m_top_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn_p = alloc_p2m_page();
 		p2m_top_mfn_p_init(p2m_top_mfn_p);
 
-		p2m_top_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn = alloc_p2m_page();
 		p2m_top_mfn_init(p2m_top_mfn);
 	} else {
 		/* Reinitialise, mfn's all change after migration */
@@ -327,7 +346,7 @@ void __ref xen_build_mfn_list_list(void)
 			 * missing parts of the mfn tree after
 			 * runtime.
 			 */
-			mid_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
 			p2m_top_mfn_p[topidx] = mid_mfn_p;
@@ -364,17 +383,17 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
 
-	p2m_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
-	p2m_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_identity = alloc_p2m_page();
 	p2m_init(p2m_identity);
 
-	p2m_mid_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_missing = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_identity = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_identity, p2m_identity);
 
-	p2m_top = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_top = alloc_p2m_page();
 	p2m_top_init(p2m_top);
 
 	/*
@@ -387,7 +406,7 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		unsigned mididx = p2m_mid_index(pfn);
 
 		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+			unsigned long **mid = alloc_p2m_page();
 			p2m_mid_init(mid, p2m_missing);
 
 			p2m_top[topidx] = mid;
@@ -420,6 +439,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 	unsigned long *mfn_list = NULL;
 	unsigned long size;
 
+	use_brk = 0;
 	va_start = xen_start_info->mfn_list;
 	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
 	 * so make sure it is rounded up to that */
@@ -484,6 +504,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
+	use_brk = 0;
 	return 0;
 }
 #endif
@@ -510,16 +531,6 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
-static void *alloc_p2m_page(void)
-{
-	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
-}
-
-static void free_p2m_page(void *p)
-{
-	free_page((unsigned long)p);
-}
-
 /*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
@@ -624,7 +635,7 @@ static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
 		return false;
 
 	/* Boundary cross-over for the edges: */
-	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m = alloc_p2m_page();
 
 	p2m_init(p2m);
 
@@ -640,7 +651,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 
 	mid = p2m_top[topidx];
 	if (mid == p2m_mid_missing) {
-		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+		mid = alloc_p2m_page();
 
 		p2m_mid_init(mid, p2m_missing);
 
@@ -649,100 +660,6 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 	return true;
 }
 
-/*
- * Skim over the P2M tree looking at pages that are either filled with
- * INVALID_P2M_ENTRY or with 1:1 PFNs. If found, re-use that page and
- * replace the P2M leaf with a p2m_missing or p2m_identity.
- * Stick the old page in the new P2M tree location.
- */
-static bool __init early_can_reuse_p2m_middle(unsigned long set_pfn)
-{
-	unsigned topidx;
-	unsigned mididx;
-	unsigned ident_pfns;
-	unsigned inv_pfns;
-	unsigned long *p2m;
-	unsigned idx;
-	unsigned long pfn;
-
-	/* We only look when this entails a P2M middle layer */
-	if (p2m_index(set_pfn))
-		return false;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
-		topidx = p2m_top_index(pfn);
-
-		if (!p2m_top[topidx])
-			continue;
-
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
-
-		mididx = p2m_mid_index(pfn);
-		p2m = p2m_top[topidx][mididx];
-		if (!p2m)
-			continue;
-
-		if ((p2m == p2m_missing) || (p2m == p2m_identity))
-			continue;
-
-		if ((unsigned long)p2m == INVALID_P2M_ENTRY)
-			continue;
-
-		ident_pfns = 0;
-		inv_pfns = 0;
-		for (idx = 0; idx < P2M_PER_PAGE; idx++) {
-			/* IDENTITY_PFNs are 1:1 */
-			if (p2m[idx] == IDENTITY_FRAME(pfn + idx))
-				ident_pfns++;
-			else if (p2m[idx] == INVALID_P2M_ENTRY)
-				inv_pfns++;
-			else
-				break;
-		}
-		if ((ident_pfns == P2M_PER_PAGE) || (inv_pfns == P2M_PER_PAGE))
-			goto found;
-	}
-	return false;
-found:
-	/* Found one, replace old with p2m_identity or p2m_missing */
-	p2m_top[topidx][mididx] = (ident_pfns ? p2m_identity : p2m_missing);
-
-	/* Reset where we want to stick the old page in. */
-	topidx = p2m_top_index(set_pfn);
-	mididx = p2m_mid_index(set_pfn);
-
-	/* This shouldn't happen */
-	if (WARN_ON(p2m_top[topidx] == p2m_mid_missing))
-		early_alloc_p2m_middle(set_pfn);
-
-	if (WARN_ON(p2m_top[topidx][mididx] != p2m_missing))
-		return false;
-
-	p2m_init(p2m);
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn)
-{
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
-		if (!early_alloc_p2m_middle(pfn))
-			return false;
-
-		if (early_can_reuse_p2m_middle(pfn))
-			return __set_phys_to_machine(pfn, mfn);
-
-		if (!early_alloc_p2m(pfn, false /* boundary crossover OK!*/))
-			return false;
-
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
-	}
-
-	return true;
-}
-
 static void __init early_split_p2m(unsigned long pfn)
 {
 	unsigned long mididx, idx;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 29834b3..0e5f9b6 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -30,6 +30,7 @@
 #include "xen-ops.h"
 #include "vdso.h"
 #include "p2m.h"
+#include "mmu.h"
 
 /* These are code, but not functions.  Defined in entry.S */
 extern const char xen_hypervisor_callback[];
@@ -47,8 +48,18 @@ struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 /* Number of pages released from the initial allocation. */
 unsigned long xen_released_pages;
 
-/* Buffer used to remap identity mapped pages */
-unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
+/*
+ * Buffer used to remap identity mapped pages. We only need the virtual space.
+ * The physical memory for each buffer page is remapped as needed.
+ */
+#define REMAP_SIZE	(P2M_PER_PAGE - 3)
+static struct {
+	unsigned long	next_area_mfn;
+	unsigned long	target_pfn;
+	unsigned long	size;
+	unsigned long	mfns[REMAP_SIZE];
+} xen_remap_buf __initdata __aligned(PAGE_SIZE);
+static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 /* 
  * The maximum amount of extra memory compared to the base size.  The
@@ -98,63 +109,6 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 	}
 }
 
-static unsigned long __init xen_do_chunk(unsigned long start,
-					 unsigned long end, bool release)
-{
-	struct xen_memory_reservation reservation = {
-		.address_bits = 0,
-		.extent_order = 0,
-		.domid        = DOMID_SELF
-	};
-	unsigned long len = 0;
-	unsigned long pfn;
-	int ret;
-
-	for (pfn = start; pfn < end; pfn++) {
-		unsigned long frame;
-		unsigned long mfn = pfn_to_mfn(pfn);
-
-		if (release) {
-			/* Make sure pfn exists to start with */
-			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
-				continue;
-			frame = mfn;
-		} else {
-			if (mfn != INVALID_P2M_ENTRY)
-				continue;
-			frame = pfn;
-		}
-		set_xen_guest_handle(reservation.extent_start, &frame);
-		reservation.nr_extents = 1;
-
-		ret = HYPERVISOR_memory_op(release ? XENMEM_decrease_reservation : XENMEM_populate_physmap,
-					   &reservation);
-		WARN(ret != 1, "Failed to %s pfn %lx err=%d\n",
-		     release ? "release" : "populate", pfn, ret);
-
-		if (ret == 1) {
-			if (!early_set_phys_to_machine(pfn, release ? INVALID_P2M_ENTRY : frame)) {
-				if (release)
-					break;
-				set_xen_guest_handle(reservation.extent_start, &frame);
-				reservation.nr_extents = 1;
-				ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
-							   &reservation);
-				break;
-			}
-			len++;
-		} else
-			break;
-	}
-	if (len)
-		printk(KERN_INFO "%s %lx-%lx pfn range: %lu pages %s\n",
-		       release ? "Freeing" : "Populating",
-		       start, end, len,
-		       release ? "freed" : "added");
-
-	return len;
-}
-
 /*
  * Finds the next RAM pfn available in the E820 map after min_pfn.
  * This function updates min_pfn with the pfn found and returns
@@ -198,23 +152,60 @@ static unsigned long __init xen_find_pfn_range(
 	return done;
 }
 
+static int __init xen_free_mfn(unsigned long mfn)
+{
+	struct xen_memory_reservation reservation = {
+		.address_bits = 0,
+		.extent_order = 0,
+		.domid        = DOMID_SELF
+	};
+
+	set_xen_guest_handle(reservation.extent_start, &mfn);
+	reservation.nr_extents = 1;
+
+	return HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation);
+}
+
 /*
- * This releases a chunk of memory and then does the identity map. It's used as
+ * This releases a chunk of memory and then does the identity map. It's used
  * as a fallback if the remapping fails.
  */
 static void __init xen_set_identity_and_release_chunk(unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long *identity,
 	unsigned long *released)
 {
+	unsigned long len = 0;
+	unsigned long pfn, end;
+	int ret;
+
 	WARN_ON(start_pfn > end_pfn);
 
+	end = min(end_pfn, nr_pages);
+	for (pfn = start_pfn; pfn < end; pfn++) {
+		unsigned long mfn = pfn_to_mfn(pfn);
+
+		/* Make sure pfn exists to start with */
+		if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+			continue;
+
+		ret = xen_free_mfn(mfn);
+		WARN(ret != 1, "Failed to release pfn %lx err=%d\n", pfn, ret);
+
+		if (ret == 1) {
+			if (!__set_phys_to_machine(pfn, INVALID_P2M_ENTRY))
+				break;
+			len++;
+		} else
+			break;
+	}
+
 	/* Need to release pages first */
-	*released += xen_do_chunk(start_pfn, min(end_pfn, nr_pages), true);
+	*released += len;
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
 /*
- * Helper function to update both the p2m and m2p tables.
+ * Helper function to update the p2m and m2p tables and kernel mapping.
  */
 static unsigned long __init xen_update_mem_tables(unsigned long pfn,
 						  unsigned long mfn)
@@ -225,161 +216,92 @@ static unsigned long __init xen_update_mem_tables(unsigned long pfn,
 	};
 
 	/* Update p2m */
-	if (!early_set_phys_to_machine(pfn, mfn)) {
+	if (!set_phys_to_machine(pfn, mfn)) {
 		WARN(1, "Failed to set p2m mapping for pfn=%ld mfn=%ld\n",
 		     pfn, mfn);
-		return false;
+		return 0;
 	}
 
 	/* Update m2p */
 	if (HYPERVISOR_mmu_update(&update, 1, NULL, DOMID_SELF) < 0) {
 		WARN(1, "Failed to set m2p mapping for mfn=%ld pfn=%ld\n",
 		     mfn, pfn);
-		return false;
+		return 0;
+	}
+
+	/* Update kernel mapping, but not for highmem. */
+	if ((pfn << PAGE_SHIFT) >= __pa(high_memory))
+		return 1;
+
+	if (HYPERVISOR_update_va_mapping((unsigned long)__va(pfn << PAGE_SHIFT),
+					 mfn_pte(mfn, PAGE_KERNEL), 0)) {
+		WARN(1, "Failed to update kernel mapping for mfn=%ld pfn=%ld\n",
+		      mfn, pfn);
+		return 0;
 	}
 
-	return true;
+	return 1;
 }
 
 /*
  * This function updates the p2m and m2p tables with an identity map from
- * start_pfn to start_pfn+size and remaps the underlying RAM of the original
- * allocation at remap_pfn. It must do so carefully in P2M_PER_PAGE sized blocks
- * to not exhaust the reserved brk space. Doing it in properly aligned blocks
- * ensures we only allocate the minimum required leaf pages in the p2m table. It
- * copies the existing mfns from the p2m table under the 1:1 map, overwrites
- * them with the identity map and then updates the p2m and m2p tables with the
- * remapped memory.
+ * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the
+ * original allocation at remap_pfn. The information needed for remapping is
+ * saved in the memory itself to avoid the need for allocating buffers. The
+ * complete remap information is contained in a list of MFNs each containing
+ * up to REMAP_SIZE MFNs and the start target PFN for doing the remap.
+ * This enables to preserve the original mfn sequence while doing the remapping
+ * at a time when the memory management is capable of allocating virtual and
+ * physical memory in arbitrary amounts.
  */
-static unsigned long __init xen_do_set_identity_and_remap_chunk(
+static void __init xen_do_set_identity_and_remap_chunk(
         unsigned long start_pfn, unsigned long size, unsigned long remap_pfn)
 {
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn;
 	unsigned long ident_pfn_iter, remap_pfn_iter;
-	unsigned long ident_start_pfn_align, remap_start_pfn_align;
-	unsigned long ident_end_pfn_align, remap_end_pfn_align;
-	unsigned long ident_boundary_pfn, remap_boundary_pfn;
-	unsigned long ident_cnt = 0;
-	unsigned long remap_cnt = 0;
+	unsigned long ident_end_pfn = start_pfn + size;
 	unsigned long left = size;
-	unsigned long mod;
-	int i;
+	unsigned long ident_cnt = 0;
+	unsigned int i, chunk;
 
 	WARN_ON(size == 0);
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/*
-	 * Determine the proper alignment to remap memory in P2M_PER_PAGE sized
-	 * blocks. We need to keep track of both the existing pfn mapping and
-	 * the new pfn remapping.
-	 */
-	mod = start_pfn % P2M_PER_PAGE;
-	ident_start_pfn_align =
-		mod ? (start_pfn - mod + P2M_PER_PAGE) : start_pfn;
-	mod = remap_pfn % P2M_PER_PAGE;
-	remap_start_pfn_align =
-		mod ? (remap_pfn - mod + P2M_PER_PAGE) : remap_pfn;
-	mod = (start_pfn + size) % P2M_PER_PAGE;
-	ident_end_pfn_align = start_pfn + size - mod;
-	mod = (remap_pfn + size) % P2M_PER_PAGE;
-	remap_end_pfn_align = remap_pfn + size - mod;
-
-	/* Iterate over each p2m leaf node in each range */
-	for (ident_pfn_iter = ident_start_pfn_align, remap_pfn_iter = remap_start_pfn_align;
-	     ident_pfn_iter < ident_end_pfn_align && remap_pfn_iter < remap_end_pfn_align;
-	     ident_pfn_iter += P2M_PER_PAGE, remap_pfn_iter += P2M_PER_PAGE) {
-		/* Check we aren't past the end */
-		BUG_ON(ident_pfn_iter + P2M_PER_PAGE > start_pfn + size);
-		BUG_ON(remap_pfn_iter + P2M_PER_PAGE > remap_pfn + size);
-
-		/* Save p2m mappings */
-		for (i = 0; i < P2M_PER_PAGE; i++)
-			xen_remap_buf[i] = pfn_to_mfn(ident_pfn_iter + i);
-
-		/* Set identity map which will free a p2m leaf */
-		ident_cnt += set_phys_range_identity(ident_pfn_iter,
-			ident_pfn_iter + P2M_PER_PAGE);
-
-#ifdef DEBUG
-		/* Helps verify a p2m leaf has been freed */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned int pfn = ident_pfn_iter + i;
-			BUG_ON(pfn_to_mfn(pfn) != pfn);
-		}
-#endif
-		/* Now remap memory */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned long mfn = xen_remap_buf[i];
-
-			/* This will use the p2m leaf freed above */
-			if (!xen_update_mem_tables(remap_pfn_iter + i, mfn)) {
-				WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-					remap_pfn_iter + i, mfn);
-				return 0;
-			}
-
-			remap_cnt++;
-		}
-
-		left -= P2M_PER_PAGE;
-	}
+	/* Don't use memory until remapped */
+	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
 
-	/* Max boundary space possible */
-	BUG_ON(left > (P2M_PER_PAGE - 1) * 2);
+	mfn_save = virt_to_mfn(buf);
 
-	/* Now handle the boundary conditions */
-	ident_boundary_pfn = start_pfn;
-	remap_boundary_pfn = remap_pfn;
-	for (i = 0; i < left; i++) {
-		unsigned long mfn;
+	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
+	     ident_pfn_iter < ident_end_pfn;
+	     ident_pfn_iter += REMAP_SIZE, remap_pfn_iter += REMAP_SIZE) {
+		chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE;
 
-		/* These two checks move from the start to end boundaries */
-		if (ident_boundary_pfn == ident_start_pfn_align)
-			ident_boundary_pfn = ident_pfn_iter;
-		if (remap_boundary_pfn == remap_start_pfn_align)
-			remap_boundary_pfn = remap_pfn_iter;
+		/* Map first pfn to xen_remap_buf */
+		mfn = pfn_to_mfn(ident_pfn_iter);
+		set_pte_mfn(buf, mfn, PAGE_KERNEL);
 
-		/* Check we aren't past the end */
-		BUG_ON(ident_boundary_pfn >= start_pfn + size);
-		BUG_ON(remap_boundary_pfn >= remap_pfn + size);
+		/* Save mapping information in page */
+		xen_remap_buf.next_area_mfn = xen_remap_mfn;
+		xen_remap_buf.target_pfn = remap_pfn_iter;
+		xen_remap_buf.size = chunk;
+		for (i = 0; i < chunk; i++)
+			xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i);
 
-		mfn = pfn_to_mfn(ident_boundary_pfn);
+		/* New element first in list */
+		xen_remap_mfn = mfn;
 
-		if (!xen_update_mem_tables(remap_boundary_pfn, mfn)) {
-			WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-				remap_pfn_iter + i, mfn);
-			return 0;
-		}
-		remap_cnt++;
-
-		ident_boundary_pfn++;
-		remap_boundary_pfn++;
-	}
+		/* Set identity map */
+		ident_cnt += set_phys_range_identity(ident_pfn_iter,
+			ident_pfn_iter + chunk);
 
-	/* Finish up the identity map */
-	if (ident_start_pfn_align >= ident_end_pfn_align) {
-		/*
-                 * In this case we have an identity range which does not span an
-                 * aligned block so everything needs to be identity mapped here.
-                 * If we didn't check this we might remap too many pages since
-                 * the align boundaries are not meaningful in this case.
-	         */
-		ident_cnt += set_phys_range_identity(start_pfn,
-			start_pfn + size);
-	} else {
-		/* Remapped above so check each end of the chunk */
-		if (start_pfn < ident_start_pfn_align)
-			ident_cnt += set_phys_range_identity(start_pfn,
-				ident_start_pfn_align);
-		if (start_pfn + size > ident_pfn_iter)
-			ident_cnt += set_phys_range_identity(ident_pfn_iter,
-				start_pfn + size);
+		left -= chunk;
 	}
 
-	BUG_ON(ident_cnt != size);
-	BUG_ON(remap_cnt != size);
-
-	return size;
+	/* Restore old xen_remap_buf mapping */
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 }
 
 /*
@@ -396,8 +318,7 @@ static unsigned long __init xen_do_set_identity_and_remap_chunk(
 static unsigned long __init xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
-	unsigned long *identity, unsigned long *remapped,
-	unsigned long *released)
+	unsigned long *identity, unsigned long *released)
 {
 	unsigned long pfn;
 	unsigned long i = 0;
@@ -431,19 +352,12 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 		if (size > remap_range_size)
 			size = remap_range_size;
 
-		if (!xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn)) {
-			WARN(1, "Failed to remap 1:1 memory cur_pfn=%ld size=%ld remap_pfn=%ld\n",
-				cur_pfn, size, remap_pfn);
-			xen_set_identity_and_release_chunk(cur_pfn,
-				cur_pfn + left, nr_pages, identity, released);
-			break;
-		}
+		xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn);
 
 		/* Update variables to reflect new mappings. */
 		i += size;
 		remap_pfn += size;
 		*identity += size;
-		*remapped += size;
 	}
 
 	/*
@@ -464,7 +378,6 @@ static unsigned long __init xen_set_identity_and_remap(
 {
 	phys_addr_t start = 0;
 	unsigned long identity = 0;
-	unsigned long remapped = 0;
 	unsigned long last_pfn = nr_pages;
 	const struct e820entry *entry;
 	unsigned long num_released = 0;
@@ -494,8 +407,7 @@ static unsigned long __init xen_set_identity_and_remap(
 				last_pfn = xen_set_identity_and_remap_chunk(
 						list, map_size, start_pfn,
 						end_pfn, nr_pages, last_pfn,
-						&identity, &remapped,
-						&num_released);
+						&identity, &num_released);
 			start = end;
 		}
 	}
@@ -503,12 +415,84 @@ static unsigned long __init xen_set_identity_and_remap(
 	*released = num_released;
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
-	pr_info("Remapped %ld page(s), last_pfn=%ld\n", remapped,
-		last_pfn);
 	pr_info("Released %ld page(s)\n", num_released);
 
 	return last_pfn;
 }
+
+/*
+ * Remap the memory prepared in xen_do_set_identity_and_remap_chunk().
+ */
+void __init xen_remap_memory(void)
+{
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn, pfn;
+	unsigned long remapped = 0, released = 0;
+	unsigned int i, free;
+	unsigned long pfn_s = ~0UL;
+	unsigned long len = 0;
+
+	mfn_save = virt_to_mfn(buf);
+
+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
+		/* Map the remap information */
+		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
+
+		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
+
+		free = 0;
+		pfn = xen_remap_buf.target_pfn;
+		for (i = 0; i < xen_remap_buf.size; i++) {
+			mfn = xen_remap_buf.mfns[i];
+			if (!released && xen_update_mem_tables(pfn, mfn)) {
+				remapped++;
+			} else {
+				if (!released) {
+					if (pfn_s != ~0UL && len)
+						memblock_free(PFN_PHYS(pfn_s),
+							      PFN_PHYS(len));
+					pfn_s = xen_remap_buf.target_pfn;
+					len = i;
+				}
+				/* Don't free the page with our mfn list! */
+				if (i)
+					xen_free_mfn(mfn);
+				else
+					free = 1;
+				released++;
+			}
+			pfn++;
+		}
+		if (!released) {
+			if (pfn_s == ~0UL || pfn == pfn_s) {
+				pfn_s = xen_remap_buf.target_pfn;
+				len += xen_remap_buf.size;
+			} else if (pfn_s + len == xen_remap_buf.target_pfn) {
+				len += xen_remap_buf.size;
+			} else {
+				memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+				pfn_s = xen_remap_buf.target_pfn;
+				len = xen_remap_buf.size;
+			}
+		}
+
+		mfn = xen_remap_mfn;
+		xen_remap_mfn = xen_remap_buf.next_area_mfn;
+		/* Now it's save to free the page holding our data. */
+		if (free)
+			xen_free_mfn(mfn);
+	}
+
+	if (pfn_s != ~0UL && len)
+		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
+
+	pr_info("Remapped %ld page(s)\n", remapped);
+	if (released)
+		pr_info("Released %ld page(s)\n", released);
+}
+
 static unsigned long __init xen_get_max_pages(void)
 {
 	unsigned long max_pages = MAX_DOMAIN_PAGES;
@@ -616,7 +600,8 @@ char * __init xen_memory_setup(void)
 		extra_pages += max_pages - max_pfn;
 
 	/*
-	 * Set identity map on non-RAM pages and remap the underlying RAM.
+	 * Set identity map on non-RAM pages and prepare remapping the
+	 * underlying RAM.
 	 */
 	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
 					      &xen_released_pages);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 28c7e0b..5b72a06 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,6 +35,7 @@ void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
 void __init xen_arch_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv6-0007yo-FE; Thu, 06 Nov 2014 05:47:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv5-0007y8-0h
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	68/B0-09842-E7B0B545; Thu, 06 Nov 2014 05:47:42 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415252860!11826616!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21561 invoked from network); 6 Nov 2014 05:47:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:40 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3523CADA9;
	Thu,  6 Nov 2014 05:47:40 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:33 +0100
Message-Id: <1415252853-7106-6-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415252853-7106-1-git-send-email-jgross@suse.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped
	sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At start of the day the Xen hypervisor presents a contiguous mfn list
to a pv-domain. In order to support sparse memory this mfn list is
accessed via a three level p2m tree built early in the boot process.
Whenever the system needs the mfn associated with a pfn this tree is
used to find the mfn.

Instead of using a software walked tree for accessing a specific mfn
list entry this patch is creating a virtual address area for the
entire possible mfn list including memory holes. The holes are
covered by mapping a pre-defined  page consisting only of "invalid
mfn" entries. Access to a mfn entry is possible by just using the
virtual base address of the mfn list and the pfn as index into that
list. This speeds up the (hot) path of determining the mfn of a
pfn.

Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
showed following improvements:

Elapsed time: 32:50 ->  32:35
System:       18:07 ->  17:47
User:        104:00 -> 103:30

Tested on 64 bit dom0 and 32 bit domU.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |  27 +-
 arch/x86/xen/mmu.c              |  34 +-
 arch/x86/xen/p2m.c              | 736 +++++++++++++++++-----------------------
 arch/x86/xen/xen-ops.h          |   2 +-
 4 files changed, 354 insertions(+), 445 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 28fa795..dd65a0c 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -59,6 +59,23 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct page **pages, unsigned int count);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
+static inline unsigned long __pfn_to_mfn(unsigned long pfn)
+{
+	unsigned long mfn;
+
+	if (pfn < xen_p2m_size)
+		mfn = xen_p2m_addr[pfn];
+	else if (unlikely(pfn < xen_max_p2m_pfn))
+		return get_phys_to_machine(pfn);
+	else
+		return IDENTITY_FRAME(pfn);
+
+	if (unlikely(mfn == INVALID_P2M_ENTRY))
+		return get_phys_to_machine(pfn);
+
+	return mfn;
+}
+
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
 {
 	unsigned long mfn;
@@ -66,7 +83,7 @@ static inline unsigned long pfn_to_mfn(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return pfn;
 
-	mfn = get_phys_to_machine(pfn);
+	mfn = __pfn_to_mfn(pfn);
 
 	if (mfn != INVALID_P2M_ENTRY)
 		mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
@@ -79,7 +96,7 @@ static inline int phys_to_machine_mapping_valid(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return 1;
 
-	return get_phys_to_machine(pfn) != INVALID_P2M_ENTRY;
+	return __pfn_to_mfn(pfn) != INVALID_P2M_ENTRY;
 }
 
 static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
@@ -113,7 +130,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) != mfn) {
+	if (__pfn_to_mfn(pfn) != mfn) {
 		/*
 		 * If this appears to be a foreign mfn (because the pfn
 		 * doesn't map back to the mfn), then check the local override
@@ -130,7 +147,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 	 * valid entry for it.
 	 */
 	if (pfn == ~0 &&
-			get_phys_to_machine(mfn) == IDENTITY_FRAME(mfn))
+			__pfn_to_mfn(mfn) == IDENTITY_FRAME(mfn))
 		pfn = mfn;
 
 	return pfn;
@@ -176,7 +193,7 @@ static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn(mfn);
-	if (get_phys_to_machine(pfn) != mfn)
+	if (__pfn_to_mfn(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
 }
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d3e492b..0b43c45 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -387,7 +387,7 @@ static pteval_t pte_pfn_to_mfn(pteval_t val)
 		unsigned long mfn;
 
 		if (!xen_feature(XENFEAT_auto_translated_physmap))
-			mfn = get_phys_to_machine(pfn);
+			mfn = __pfn_to_mfn(pfn);
 		else
 			mfn = pfn;
 		/*
@@ -1158,20 +1158,16 @@ static void __init xen_cleanhighmap(unsigned long vaddr,
 	 * instead of somewhere later and be confusing. */
 	xen_mc_flush();
 }
-static void __init xen_pagetable_p2m_copy(void)
+
+static void __init xen_pagetable_p2m_free(void)
 {
 	unsigned long size;
 	unsigned long addr;
-	unsigned long new_mfn_list;
-
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return;
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 
-	new_mfn_list = xen_revector_p2m_tree();
 	/* No memory or already called. */
-	if (!new_mfn_list || new_mfn_list == xen_start_info->mfn_list)
+	if ((unsigned long)xen_p2m_addr == xen_start_info->mfn_list)
 		return;
 
 	/* using __ka address and sticking INVALID_P2M_ENTRY! */
@@ -1189,8 +1185,6 @@ static void __init xen_pagetable_p2m_copy(void)
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 	memblock_free(__pa(xen_start_info->mfn_list), size);
-	/* And revector! Bye bye old array */
-	xen_start_info->mfn_list = new_mfn_list;
 
 	/* At this stage, cleanup_highmap has already cleaned __ka space
 	 * from _brk_limit way up to the max_pfn_mapped (which is the end of
@@ -1214,12 +1208,26 @@ static void __init xen_pagetable_p2m_copy(void)
 }
 #endif
 
-static void __init xen_pagetable_init(void)
+static void __init xen_pagetable_p2m_setup(void)
 {
-	paging_init();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	xen_vmalloc_p2m_tree();
+
 #ifdef CONFIG_X86_64
-	xen_pagetable_p2m_copy();
+	xen_pagetable_p2m_free();
 #endif
+	/* And revector! Bye bye old array */
+	xen_start_info->mfn_list = (unsigned long)xen_p2m_addr;
+}
+
+static void __init xen_pagetable_init(void)
+{
+	paging_init();
+
+	xen_pagetable_p2m_setup();
+
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 7c409b0..a39ea04 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -3,21 +3,22 @@
  * guests themselves, but it must also access and update the p2m array
  * during suspend/resume when all the pages are reallocated.
  *
- * The p2m table is logically a flat array, but we implement it as a
- * three-level tree to allow the address space to be sparse.
+ * The logical flat p2m table is mapped to a linear kernel memory area.
+ * For accesses by Xen a three-level tree linked via mfns only is set up to
+ * allow the address space to be sparse.
  *
- *                               Xen
- *                                |
- *     p2m_top              p2m_top_mfn
- *       /  \                   /   \
- * p2m_mid p2m_mid	p2m_mid_mfn p2m_mid_mfn
- *    / \      / \         /           /
- *  p2m p2m p2m p2m p2m p2m p2m ...
+ *               Xen
+ *                |
+ *          p2m_top_mfn
+ *              /   \
+ * p2m_mid_mfn p2m_mid_mfn
+ *         /           /
+ *  p2m p2m p2m ...
  *
  * The p2m_mid_mfn pages are mapped by p2m_top_mfn_p.
  *
- * The p2m_top and p2m_top_mfn levels are limited to 1 page, so the
- * maximum representable pseudo-physical address space is:
+ * The p2m_top_mfn level is limited to 1 page, so the maximum representable
+ * pseudo-physical address space is:
  *  P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * P2M_PER_PAGE pages
  *
  * P2M_PER_PAGE depends on the architecture, as a mfn is always
@@ -30,6 +31,9 @@
  * leaf entries, or for the top  root, or middle one, for which there is a void
  * entry, we assume it is  "missing". So (for example)
  *  pfn_to_mfn(0x90909090)=INVALID_P2M_ENTRY.
+ * We have a dedicated page p2m_missing with all entries being
+ * INVALID_P2M_ENTRY. This page may be referenced multiple times in the p2m
+ * list/tree in case there are multiple areas with P2M_PER_PAGE invalid pfns.
  *
  * We also have the possibility of setting 1-1 mappings on certain regions, so
  * that:
@@ -39,122 +43,20 @@
  * PCI BARs, or ACPI spaces), we can create mappings easily because we
  * get the PFN value to match the MFN.
  *
- * For this to work efficiently we have one new page p2m_identity and
- * allocate (via reserved_brk) any other pages we need to cover the sides
- * (1GB or 4MB boundary violations). All entries in p2m_identity are set to
- * INVALID_P2M_ENTRY type (Xen toolstack only recognizes that and MFNs,
- * no other fancy value).
+ * For this to work efficiently we have one new page p2m_identity. All entries
+ * in p2m_identity are set to INVALID_P2M_ENTRY type (Xen toolstack only
+ * recognizes that and MFNs, no other fancy value).
  *
  * On lookup we spot that the entry points to p2m_identity and return the
  * identity value instead of dereferencing and returning INVALID_P2M_ENTRY.
  * If the entry points to an allocated page, we just proceed as before and
- * return the PFN.  If the PFN has IDENTITY_FRAME_BIT set we unmask that in
+ * return the PFN. If the PFN has IDENTITY_FRAME_BIT set we unmask that in
  * appropriate functions (pfn_to_mfn).
  *
  * The reason for having the IDENTITY_FRAME_BIT instead of just returning the
  * PFN is that we could find ourselves where pfn_to_mfn(pfn)==pfn for a
  * non-identity pfn. To protect ourselves against we elect to set (and get) the
  * IDENTITY_FRAME_BIT on all identity mapped PFNs.
- *
- * This simplistic diagram is used to explain the more subtle piece of code.
- * There is also a digram of the P2M at the end that can help.
- * Imagine your E820 looking as so:
- *
- *                    1GB                                           2GB    4GB
- * /-------------------+---------\/----\         /----------\    /---+-----\
- * | System RAM        | Sys RAM ||ACPI|         | reserved |    | Sys RAM |
- * \-------------------+---------/\----/         \----------/    \---+-----/
- *                               ^- 1029MB                       ^- 2001MB
- *
- * [1029MB = 263424 (0x40500), 2001MB = 512256 (0x7D100),
- *  2048MB = 524288 (0x80000)]
- *
- * And dom0_mem=max:3GB,1GB is passed in to the guest, meaning memory past 1GB
- * is actually not present (would have to kick the balloon driver to put it in).
- *
- * When we are told to set the PFNs for identity mapping (see patch: "xen/setup:
- * Set identity mapping for non-RAM E820 and E820 gaps.") we pass in the start
- * of the PFN and the end PFN (263424 and 512256 respectively). The first step
- * is to reserve_brk a top leaf page if the p2m[1] is missing. The top leaf page
- * covers 512^2 of page estate (1GB) and in case the start or end PFN is not
- * aligned on 512^2*PAGE_SIZE (1GB) we reserve_brk new middle and leaf pages as
- * required to split any existing p2m_mid_missing middle pages.
- *
- * With the E820 example above, 263424 is not 1GB aligned so we allocate a
- * reserve_brk page which will cover the PFNs estate from 0x40000 to 0x80000.
- * Each entry in the allocate page is "missing" (points to p2m_missing).
- *
- * Next stage is to determine if we need to do a more granular boundary check
- * on the 4MB (or 2MB depending on architecture) off the start and end pfn's.
- * We check if the start pfn and end pfn violate that boundary check, and if
- * so reserve_brk a (p2m[x][y]) leaf page. This way we have a much finer
- * granularity of setting which PFNs are missing and which ones are identity.
- * In our example 263424 and 512256 both fail the check so we reserve_brk two
- * pages. Populate them with INVALID_P2M_ENTRY (so they both have "missing"
- * values) and assign them to p2m[1][2] and p2m[1][488] respectively.
- *
- * At this point we would at minimum reserve_brk one page, but could be up to
- * three. Each call to set_phys_range_identity has at maximum a three page
- * cost. If we were to query the P2M at this stage, all those entries from
- * start PFN through end PFN (so 1029MB -> 2001MB) would return
- * INVALID_P2M_ENTRY ("missing").
- *
- * The next step is to walk from the start pfn to the end pfn setting
- * the IDENTITY_FRAME_BIT on each PFN. This is done in set_phys_range_identity.
- * If we find that the middle entry is pointing to p2m_missing we can swap it
- * over to p2m_identity - this way covering 4MB (or 2MB) PFN space (and
- * similarly swapping p2m_mid_missing for p2m_mid_identity for larger regions).
- * At this point we do not need to worry about boundary aligment (so no need to
- * reserve_brk a middle page, figure out which PFNs are "missing" and which
- * ones are identity), as that has been done earlier.  If we find that the
- * middle leaf is not occupied by p2m_identity or p2m_missing, we dereference
- * that page (which covers 512 PFNs) and set the appropriate PFN with
- * IDENTITY_FRAME_BIT. In our example 263424 and 512256 end up there, and we
- * set from p2m[1][2][256->511] and p2m[1][488][0->256] with
- * IDENTITY_FRAME_BIT set.
- *
- * All other regions that are void (or not filled) either point to p2m_missing
- * (considered missing) or have the default value of INVALID_P2M_ENTRY (also
- * considered missing). In our case, p2m[1][2][0->255] and p2m[1][488][257->511]
- * contain the INVALID_P2M_ENTRY value and are considered "missing."
- *
- * Finally, the region beyond the end of of the E820 (4 GB in this example)
- * is set to be identity (in case there are MMIO regions placed here).
- *
- * This is what the p2m ends up looking (for the E820 above) with this
- * fabulous drawing:
- *
- *    p2m         /--------------\
- *  /-----\       | &mfn_list[0],|                           /-----------------\
- *  |  0  |------>| &mfn_list[1],|    /---------------\      | ~0, ~0, ..      |
- *  |-----|       |  ..., ~0, ~0 |    | ~0, ~0, [x]---+----->| IDENTITY [@256] |
- *  |  1  |---\   \--------------/    | [p2m_identity]+\     | IDENTITY [@257] |
- *  |-----|    \                      | [p2m_identity]+\\    | ....            |
- *  |  2  |--\  \-------------------->|  ...          | \\   \----------------/
- *  |-----|   \                       \---------------/  \\
- *  |  3  |-\  \                                          \\  p2m_identity [1]
- *  |-----|  \  \-------------------->/---------------\   /-----------------\
- *  | ..  |\  |                       | [p2m_identity]+-->| ~0, ~0, ~0, ... |
- *  \-----/ | |                       | [p2m_identity]+-->| ..., ~0         |
- *          | |                       | ....          |   \-----------------/
- *          | |                       +-[x], ~0, ~0.. +\
- *          | |                       \---------------/ \
- *          | |                                          \-> /---------------\
- *          | V  p2m_mid_missing       p2m_missing           | IDENTITY[@0]  |
- *          | /-----------------\     /------------\         | IDENTITY[@256]|
- *          | | [p2m_missing]   +---->| ~0, ~0, ...|         | ~0, ~0, ....  |
- *          | | [p2m_missing]   +---->| ..., ~0    |         \---------------/
- *          | | ...             |     \------------/
- *          | \-----------------/
- *          |
- *          |     p2m_mid_identity
- *          |   /-----------------\
- *          \-->| [p2m_identity]  +---->[1]
- *              | [p2m_identity]  +---->[1]
- *              | ...             |
- *              \-----------------/
- *
- * where ~0 is INVALID_P2M_ENTRY. IDENTITY is (PFN | IDENTITY_BIT)
  */
 
 #include <linux/init.h>
@@ -179,6 +81,8 @@
 #include "multicalls.h"
 #include "xen-ops.h"
 
+#define PMDS_PER_MID_PAGE	(P2M_MID_PER_PAGE / PTRS_PER_PTE)
+
 static void __init m2p_override_init(void);
 
 unsigned long *xen_p2m_addr __read_mostly;
@@ -188,22 +92,15 @@ EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
 EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
+static DEFINE_SPINLOCK(p2m_update_lock);
+
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
 static unsigned long **p2m_top_mfn_p;
-
-/* Placeholders for holes in the address space */
-static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long **, p2m_top, P2M_TOP_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long, p2m_identity, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
-
-RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
-
-static int use_brk = 1;
+static unsigned long *p2m_missing;
+static unsigned long *p2m_identity;
+static pte_t *p2m_missing_pte;
+static pte_t *p2m_identity_pte;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
@@ -221,14 +118,6 @@ static inline unsigned p2m_index(unsigned long pfn)
 	return pfn % P2M_PER_PAGE;
 }
 
-static void p2m_top_init(unsigned long ***top)
-{
-	unsigned i;
-
-	for (i = 0; i < P2M_TOP_PER_PAGE; i++)
-		top[i] = p2m_mid_missing;
-}
-
 static void p2m_top_mfn_init(unsigned long *top)
 {
 	unsigned i;
@@ -245,35 +134,32 @@ static void p2m_top_mfn_p_init(unsigned long **top)
 		top[i] = p2m_mid_missing_mfn;
 }
 
-static void p2m_mid_init(unsigned long **mid, unsigned long *leaf)
+static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
 {
 	unsigned i;
 
 	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = leaf;
+		mid[i] = virt_to_mfn(leaf);
 }
 
-static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
+static void p2m_init(unsigned long *p2m)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = virt_to_mfn(leaf);
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = INVALID_P2M_ENTRY;
 }
 
-static void p2m_init(unsigned long *p2m)
+static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		p2m[i] = INVALID_P2M_ENTRY;
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = IDENTITY_FRAME(pfn + i);
 }
 
 static void * __ref alloc_p2m_page(void)
 {
-	if (unlikely(use_brk))
-		return extend_brk(PAGE_SIZE, PAGE_SIZE);
-
 	if (unlikely(!slab_is_available()))
 		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
 
@@ -298,6 +184,9 @@ static void free_p2m_page(void *p)
 void __ref xen_build_mfn_list_list(void)
 {
 	unsigned long pfn;
+	pte_t *ptep;
+	unsigned int level, topidx, mididx;
+	unsigned long *mid_mfn_p;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
@@ -317,20 +206,22 @@ void __ref xen_build_mfn_list_list(void)
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 	}
 
-	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned long **mid;
-		unsigned long *mid_mfn_p;
+	for (pfn = 0; pfn < xen_max_p2m_pfn && pfn < MAX_P2M_PFN;
+	     pfn += P2M_PER_PAGE) {
+		topidx = p2m_top_index(pfn);
+		mididx = p2m_mid_index(pfn);
 
-		mid = p2m_top[topidx];
 		mid_mfn_p = p2m_top_mfn_p[topidx];
+		ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn),
+				      &level);
+		BUG_ON(!ptep || level != PG_LEVEL_4K);
+		ptep = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
 		/* Don't bother allocating any mfn mid levels if
 		 * they're just missing, just update the stored mfn,
 		 * since all could have changed over a migrate.
 		 */
-		if (mid == p2m_mid_missing) {
+		if (ptep == p2m_missing_pte || ptep == p2m_identity_pte) {
 			BUG_ON(mididx);
 			BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
 			p2m_top_mfn[topidx] = virt_to_mfn(p2m_mid_missing_mfn);
@@ -339,11 +230,6 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		if (mid_mfn_p == p2m_mid_missing_mfn) {
-			/*
-			 * XXX boot-time only!  We should never find
-			 * missing parts of the mfn tree after
-			 * runtime.
-			 */
 			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
@@ -351,7 +237,7 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
-		mid_mfn_p[mididx] = virt_to_mfn(mid[mididx]);
+		mid_mfn_p[mididx] = virt_to_mfn(xen_p2m_addr + pfn);
 	}
 }
 
@@ -370,154 +256,153 @@ void xen_setup_mfn_list_list(void)
 /* Set up p2m_top to point to the domain-builder provided p2m pages */
 void __init xen_build_dynamic_phys_to_machine(void)
 {
-	unsigned long *mfn_list;
-	unsigned long max_pfn;
 	unsigned long pfn;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
 	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
-	mfn_list = (unsigned long *)xen_start_info->mfn_list;
-	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
-	xen_max_p2m_pfn = max_pfn;
-	xen_p2m_size = max_pfn;
+	xen_p2m_size = ALIGN(xen_start_info->nr_pages, P2M_PER_PAGE);
 
-	p2m_missing = alloc_p2m_page();
-	p2m_init(p2m_missing);
-	p2m_identity = alloc_p2m_page();
-	p2m_init(p2m_identity);
+	for (pfn = xen_start_info->nr_pages; pfn < xen_p2m_size; pfn++)
+		xen_p2m_addr[pfn] = INVALID_P2M_ENTRY;
 
-	p2m_mid_missing = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_identity, p2m_identity);
+	xen_max_p2m_pfn = xen_p2m_size;
+}
 
-	p2m_top = alloc_p2m_page();
-	p2m_top_init(p2m_top);
+#define P2M_TYPE_IDENTITY	0
+#define P2M_TYPE_MISSING	1
+#define P2M_TYPE_PFN		2
+#define P2M_TYPE_UNKNOWN	3
 
-	/*
-	 * The domain builder gives us a pre-constructed p2m array in
-	 * mfn_list for all the pages initially given to us, so we just
-	 * need to graft that into our tree structure.
-	 */
-	for (pfn = 0; pfn < max_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
+static int xen_p2m_elem_type(unsigned long pfn)
+{
+	unsigned long mfn;
 
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = alloc_p2m_page();
-			p2m_mid_init(mid, p2m_missing);
+	if (pfn >= xen_p2m_size)
+		return P2M_TYPE_IDENTITY;
 
-			p2m_top[topidx] = mid;
-		}
+	mfn = xen_p2m_addr[pfn];
 
-		/*
-		 * As long as the mfn_list has enough entries to completely
-		 * fill a p2m page, pointing into the array is ok. But if
-		 * not the entries beyond the last pfn will be undefined.
-		 */
-		if (unlikely(pfn + P2M_PER_PAGE > max_pfn)) {
-			unsigned long p2midx;
+	if (mfn == INVALID_P2M_ENTRY)
+		return P2M_TYPE_MISSING;
 
-			p2midx = max_pfn % P2M_PER_PAGE;
-			for ( ; p2midx < P2M_PER_PAGE; p2midx++)
-				mfn_list[pfn + p2midx] = INVALID_P2M_ENTRY;
-		}
-		p2m_top[topidx][mididx] = &mfn_list[pfn];
-	}
+	if (mfn & IDENTITY_FRAME_BIT)
+		return P2M_TYPE_IDENTITY;
+
+	return P2M_TYPE_PFN;
 }
-#ifdef CONFIG_X86_64
-unsigned long __init xen_revector_p2m_tree(void)
+
+static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 {
-	unsigned long va_start;
-	unsigned long va_end;
+	unsigned int i, chunk;
 	unsigned long pfn;
-	unsigned long pfn_free = 0;
-	unsigned long *mfn_list = NULL;
-	unsigned long size;
-
-	use_brk = 0;
-	va_start = xen_start_info->mfn_list;
-	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
-	 * so make sure it is rounded up to that */
-	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
-	va_end = va_start + size;
-
-	/* If we were revectored already, don't do it again. */
-	if (va_start <= __START_KERNEL_map && va_start >= __PAGE_OFFSET)
-		return 0;
-
-	mfn_list = alloc_bootmem_align(size, PAGE_SIZE);
-	if (!mfn_list) {
-		pr_warn("Could not allocate space for a new P2M tree!\n");
-		return xen_start_info->mfn_list;
-	}
-	/* Fill it out with INVALID_P2M_ENTRY value */
-	memset(mfn_list, 0xFF, size);
-
-	for (pfn = 0; pfn < ALIGN(MAX_DOMAIN_PAGES, P2M_PER_PAGE); pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx;
-		unsigned long *mid_p;
+	unsigned long *mfns;
+	pte_t *ptep;
+	pmd_t *pmdp;
+	int type;
 
-		if (!p2m_top[topidx])
-			continue;
+	p2m_missing = alloc_p2m_page();
+	p2m_init(p2m_missing);
+	p2m_identity = alloc_p2m_page();
+	p2m_init(p2m_identity);
 
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
+	p2m_missing_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_missing_pte) >> PAGE_SHIFT);
+	p2m_identity_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
+	for (i = 0; i < PTRS_PER_PTE; i++) {
+		set_pte(p2m_missing_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
+		set_pte(p2m_identity_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
+	}
 
-		mididx = p2m_mid_index(pfn);
-		mid_p = p2m_top[topidx][mididx];
-		if (!mid_p)
-			continue;
-		if ((mid_p == p2m_missing) || (mid_p == p2m_identity))
+	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
+		/*
+		 * Try to map missing/identity PMDs or p2m-pages if possible.
+		 * We have to respect the structure of the mfn_list_list
+		 * which will be built a little bit later.
+		 * Chunk size to test is one p2m page if we are in the middle
+		 * of a mfn_list_list mid page and the complete mid page area
+		 * if we are at index 0 of the mid page. Please note that a
+		 * mid page might cover more than one PMD, e.g. on 32 bit PAE
+		 * kernels.
+		 */
+		chunk = (pfn & (P2M_PER_PAGE * P2M_MID_PER_PAGE - 1)) ?
+			P2M_PER_PAGE : P2M_PER_PAGE * P2M_MID_PER_PAGE;
+
+		type = xen_p2m_elem_type(pfn);
+		i = 0;
+		if (type != P2M_TYPE_PFN)
+			for (i = 1; i < chunk; i++)
+				if (xen_p2m_elem_type(pfn + i) != type)
+					break;
+		if (i < chunk)
+			/* Reset to minimal chunk size. */
+			chunk = P2M_PER_PAGE;
+
+		if (type == P2M_TYPE_PFN || i < chunk) {
+			/* Use initial p2m page contents. */
+#ifdef CONFIG_X86_64
+			mfns = alloc_p2m_page();
+			copy_page(mfns, xen_p2m_addr + pfn);
+#else
+			mfns = xen_p2m_addr + pfn;
+#endif
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		if ((unsigned long)mid_p == INVALID_P2M_ENTRY)
+		if (chunk == P2M_PER_PAGE) {
+			/* Map complete missing or identity p2m-page. */
+			mfns = (type == P2M_TYPE_MISSING) ?
+				p2m_missing : p2m_identity;
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		/* The old va. Rebase it on mfn_list */
-		if (mid_p >= (unsigned long *)va_start && mid_p <= (unsigned long *)va_end) {
-			unsigned long *new;
+		/* Complete missing or identity PMD(s) can be mapped. */
+		ptep = (type == P2M_TYPE_MISSING) ?
+			p2m_missing_pte : p2m_identity_pte;
+		for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+			pmdp = populate_extra_pmd(
+				(unsigned long)(p2m + pfn + i * PTRS_PER_PTE));
+			set_pmd(pmdp, __pmd(__pa(ptep) | _KERNPG_TABLE));
+		}
+	}
+}
 
-			if (pfn_free  > (size / sizeof(unsigned long))) {
-				WARN(1, "Only allocated for %ld pages, but we want %ld!\n",
-				     size / sizeof(unsigned long), pfn_free);
-				return 0;
-			}
-			new = &mfn_list[pfn_free];
+void __init xen_vmalloc_p2m_tree(void)
+{
+	static struct vm_struct vm;
 
-			copy_page(new, mid_p);
-			p2m_top[topidx][mididx] = &mfn_list[pfn_free];
+	vm.flags = VM_ALLOC;
+	vm.size = ALIGN(sizeof(unsigned long) * xen_max_p2m_pfn,
+			PMD_SIZE * PMDS_PER_MID_PAGE);
+	vm_area_register_early(&vm, PMD_SIZE * PMDS_PER_MID_PAGE);
+	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);
 
-			pfn_free += P2M_PER_PAGE;
+	xen_max_p2m_pfn = vm.size / sizeof(unsigned long);
 
-		}
-		/* This should be the leafs allocated for identity from _brk. */
-	}
+	xen_rebuild_p2m_list(vm.addr);
 
+	xen_p2m_addr = vm.addr;
 	xen_p2m_size = xen_max_p2m_pfn;
-	xen_p2m_addr = mfn_list;
 
 	xen_inv_extra_mem();
 
 	m2p_override_init();
-	return (unsigned long)mfn_list;
 }
-#else
-unsigned long __init xen_revector_p2m_tree(void)
-{
-	use_brk = 0;
-	xen_p2m_size = xen_max_p2m_pfn;
-	xen_inv_extra_mem();
-	m2p_override_init();
-	return 0;
-}
-#endif
+
 unsigned long get_phys_to_machine(unsigned long pfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	if (unlikely(pfn >= xen_p2m_size)) {
 		if (pfn < xen_max_p2m_pfn)
@@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 		return IDENTITY_FRAME(pfn);
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
 	/*
 	 * The INVALID_P2M_ENTRY is filled in both p2m_*identity
 	 * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
 	 * would be wrong.
 	 */
-	if (p2m_top[topidx][mididx] == p2m_identity)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
 		return IDENTITY_FRAME(pfn);
 
-	return p2m_top[topidx][mididx][idx];
+	return xen_p2m_addr[pfn];
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
 /*
+ * Allocate new pmd(s). It is checked whether the old pmd is still in place.
+ * If not, nothing is changed. This is okay as the only reason for allocating
+ * a new pmd is to replace p2m_missing_pte or p2m_identity_pte by a individual
+ * pmd. In case of PAE/x86-32 there are multiple pmds to allocate!
+ */
+static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t *ptep, pte_t *pte_pg)
+{
+	pte_t *ptechk;
+	pte_t *pteret = ptep;
+	pte_t *pte_newpg[PMDS_PER_MID_PAGE];
+	pmd_t *pmdp;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long vaddr;
+	int i;
+
+	/* Do all allocations first to bail out in error case. */
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		pte_newpg[i] = alloc_p2m_page();
+		if (!pte_newpg[i]) {
+			for (i--; i >= 0; i--)
+				free_p2m_page(pte_newpg[i]);
+
+			return NULL;
+		}
+	}
+
+	vaddr = addr & ~(PMD_SIZE * PMDS_PER_MID_PAGE - 1);
+
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		copy_page(pte_newpg[i], pte_pg);
+		paravirt_alloc_pte(&init_mm, __pa(pte_newpg[i]) >> PAGE_SHIFT);
+
+		pmdp = lookup_pmd_address(vaddr);
+		BUG_ON(!pmdp);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		ptechk = lookup_address(vaddr, &level);
+		if (ptechk == pte_pg) {
+			set_pmd(pmdp,
+				__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+			if (vaddr == (addr & ~(PMD_SIZE - 1)))
+				pteret = pte_offset_kernel(pmdp, addr);
+			pte_newpg[i] = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
+
+		if (pte_newpg[i]) {
+			paravirt_release_pte(__pa(pte_newpg[i]) >> PAGE_SHIFT);
+			free_p2m_page(pte_newpg[i]);
+		}
+
+		vaddr += PMD_SIZE;
+	}
+
+	return pteret;
+}
+
+/*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
  * parallel mfn tree is kept in sync.  We may race with other cpus, so
@@ -552,58 +497,62 @@ EXPORT_SYMBOL_GPL(get_phys_to_machine);
 static bool alloc_p2m(unsigned long pfn)
 {
 	unsigned topidx, mididx;
-	unsigned long ***top_p, **mid;
 	unsigned long *top_mfn_p, *mid_mfn;
-	unsigned long *p2m_orig;
+	pte_t *ptep, *pte_pg;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long addr = (unsigned long)(xen_p2m_addr + pfn);
+	unsigned long p2m_pfn;
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
 
-	top_p = &p2m_top[topidx];
-	mid = ACCESS_ONCE(*top_p);
+	ptep = lookup_address(addr, &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
+	pte_pg = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
-	if (mid == p2m_mid_missing) {
-		/* Mid level is missing, allocate a new one */
-		mid = alloc_p2m_page();
-		if (!mid)
+	if (pte_pg == p2m_missing_pte || pte_pg == p2m_identity_pte) {
+		/* PMD level is missing, allocate a new one */
+		ptep = alloc_p2m_pmd(addr, ptep, pte_pg);
+		if (!ptep)
 			return false;
-
-		p2m_mid_init(mid, p2m_missing);
-
-		if (cmpxchg(top_p, p2m_mid_missing, mid) != p2m_mid_missing)
-			free_p2m_page(mid);
 	}
 
-	top_mfn_p = &p2m_top_mfn[topidx];
-	mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
+	if (p2m_top_mfn) {
+		top_mfn_p = &p2m_top_mfn[topidx];
+		mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
 
-	BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
+		BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
 
-	if (mid_mfn == p2m_mid_missing_mfn) {
-		/* Separately check the mid mfn level */
-		unsigned long missing_mfn;
-		unsigned long mid_mfn_mfn;
-		unsigned long old_mfn;
+		if (mid_mfn == p2m_mid_missing_mfn) {
+			/* Separately check the mid mfn level */
+			unsigned long missing_mfn;
+			unsigned long mid_mfn_mfn;
+			unsigned long old_mfn;
 
-		mid_mfn = alloc_p2m_page();
-		if (!mid_mfn)
-			return false;
+			mid_mfn = alloc_p2m_page();
+			if (!mid_mfn)
+				return false;
 
-		p2m_mid_mfn_init(mid_mfn, p2m_missing);
+			p2m_mid_mfn_init(mid_mfn, p2m_missing);
 
-		missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
-		mid_mfn_mfn = virt_to_mfn(mid_mfn);
-		old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
-		if (old_mfn != missing_mfn) {
-			free_p2m_page(mid_mfn);
-			mid_mfn = mfn_to_virt(old_mfn);
-		} else {
-			p2m_top_mfn_p[topidx] = mid_mfn;
+			missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
+			mid_mfn_mfn = virt_to_mfn(mid_mfn);
+			old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
+			if (old_mfn != missing_mfn) {
+				free_p2m_page(mid_mfn);
+				mid_mfn = mfn_to_virt(old_mfn);
+			} else {
+				p2m_top_mfn_p[topidx] = mid_mfn;
+			}
 		}
+	} else {
+		mid_mfn = NULL;
 	}
 
-	p2m_orig = ACCESS_ONCE(p2m_top[topidx][mididx]);
-	if (p2m_orig == p2m_identity || p2m_orig == p2m_missing) {
+	p2m_pfn = pte_pfn(ACCESS_ONCE(*ptep));
+	if (p2m_pfn == PFN_DOWN(__pa(p2m_identity)) ||
+	    p2m_pfn == PFN_DOWN(__pa(p2m_missing))) {
 		/* p2m leaf page is missing */
 		unsigned long *p2m;
 
@@ -611,12 +560,25 @@ static bool alloc_p2m(unsigned long pfn)
 		if (!p2m)
 			return false;
 
-		p2m_init(p2m);
+		if (p2m_pfn == PFN_DOWN(__pa(p2m_missing)))
+			p2m_init(p2m);
+		else
+			p2m_init_identity(p2m, pfn);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		if (pte_pfn(*ptep) == p2m_pfn) {
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(p2m)), PAGE_KERNEL));
+			if (mid_mfn)
+				mid_mfn[mididx] = virt_to_mfn(p2m);
+			p2m = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
 
-		if (cmpxchg(&mid[mididx], p2m_orig, p2m) != p2m_orig)
+		if (p2m)
 			free_p2m_page(p2m);
-		else
-			mid_mfn[mididx] = virt_to_mfn(p2m);
 	}
 
 	return true;
@@ -645,10 +607,10 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	return pfn - pfn_s;
 }
 
-/* Try to install p2m mapping; fail if intermediate bits missing */
 bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	/* don't track P2M changes in autotranslate guests */
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -659,55 +621,27 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* For sparse holes were the p2m leaf has real PFN along with
-	 * PCI holes, stick in the PFN as the MFN value.
-	 *
-	 * set_phys_range_identity() will have allocated new middle
-	 * and leaf pages as required so an existing p2m_mid_missing
-	 * or p2m_missing mean that whole range will be identity so
-	 * these can be switched to p2m_mid_identity or p2m_identity.
-	 */
-	if (mfn != INVALID_P2M_ENTRY && (mfn & IDENTITY_FRAME_BIT)) {
-		if (p2m_top[topidx] == p2m_mid_identity)
-			return true;
-
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx], p2m_mid_missing,
-					p2m_mid_identity) != p2m_mid_missing);
-			return true;
-		}
-
-		if (p2m_top[topidx][mididx] == p2m_identity)
-			return true;
-
-		/* Swap over from MISSING to IDENTITY if needed. */
-		if (p2m_top[topidx][mididx] == p2m_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx][mididx], p2m_missing,
-				p2m_identity) != p2m_missing);
-			return true;
-		}
-	}
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
-	if (p2m_top[topidx][mididx] == p2m_missing)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_missing)))
 		return mfn == INVALID_P2M_ENTRY;
 
-	p2m_top[topidx][mididx][idx] = mfn;
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
+		return mfn == IDENTITY_FRAME(pfn);
+
+	xen_p2m_addr[pfn] = mfn;
 
 	return true;
 }
 
 bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
+	if (unlikely(!__set_phys_to_machine(pfn, mfn))) {
 		if (!alloc_p2m(pfn))
 			return false;
 
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
+		return __set_phys_to_machine(pfn, mfn);
 	}
 
 	return true;
@@ -785,7 +719,7 @@ static int m2p_add_override(unsigned long mfn, struct page *page,
 	 * because mfn_to_pfn (that ends up being called by GUPF) will
 	 * return the backend pfn rather than the frontend pfn. */
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == mfn)
+	if (__pfn_to_mfn(pfn) == mfn)
 		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
 
 	return 0;
@@ -967,7 +901,7 @@ static int m2p_remove_override(struct page *page,
 	 * pfn again. */
 	mfn &= ~FOREIGN_FRAME_BIT;
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
+	if (__pfn_to_mfn(pfn) == FOREIGN_FRAME(mfn) &&
 			m2p_find_override(mfn) == NULL)
 		set_phys_to_machine(pfn, mfn);
 
@@ -1035,79 +969,29 @@ EXPORT_SYMBOL_GPL(m2p_find_override_pfn);
 #include "debugfs.h"
 static int p2m_dump_show(struct seq_file *m, void *v)
 {
-	static const char * const level_name[] = { "top", "middle",
-						"entry", "abnormal", "error"};
-#define TYPE_IDENTITY 0
-#define TYPE_MISSING 1
-#define TYPE_PFN 2
-#define TYPE_UNKNOWN 3
 	static const char * const type_name[] = {
-				[TYPE_IDENTITY] = "identity",
-				[TYPE_MISSING] = "missing",
-				[TYPE_PFN] = "pfn",
-				[TYPE_UNKNOWN] = "abnormal"};
-	unsigned long pfn, prev_pfn_type = 0, prev_pfn_level = 0;
-	unsigned int uninitialized_var(prev_level);
-	unsigned int uninitialized_var(prev_type);
-
-	if (!p2m_top)
-		return 0;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn++) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned idx = p2m_index(pfn);
-		unsigned lvl, type;
-
-		lvl = 4;
-		type = TYPE_UNKNOWN;
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			lvl = 0; type = TYPE_MISSING;
-		} else if (p2m_top[topidx] == NULL) {
-			lvl = 0; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == NULL) {
-			lvl = 1; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == p2m_identity) {
-			lvl = 1; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx] == p2m_missing) {
-			lvl = 1; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == 0) {
-			lvl = 2; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx][idx] == IDENTITY_FRAME(pfn)) {
-			lvl = 2; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx][idx] == INVALID_P2M_ENTRY) {
-			lvl = 2; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == pfn) {
-			lvl = 2; type = TYPE_PFN;
-		} else if (p2m_top[topidx][mididx][idx] != pfn) {
-			lvl = 2; type = TYPE_PFN;
-		}
-		if (pfn == 0) {
-			prev_level = lvl;
+				[P2M_TYPE_IDENTITY] = "identity",
+				[P2M_TYPE_MISSING] = "missing",
+				[P2M_TYPE_PFN] = "pfn",
+				[P2M_TYPE_UNKNOWN] = "abnormal"};
+	unsigned long pfn, first_pfn;
+	int type, prev_type;
+
+	prev_type = xen_p2m_elem_type(0);
+	first_pfn = 0;
+
+	for (pfn = 0; pfn < xen_p2m_size; pfn++) {
+		type = xen_p2m_elem_type(pfn);
+		if (type != prev_type) {
+			seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+				   type_name[prev_type]);
 			prev_type = type;
-		}
-		if (pfn == MAX_DOMAIN_PAGES-1) {
-			lvl = 3;
-			type = TYPE_UNKNOWN;
-		}
-		if (prev_type != type) {
-			seq_printf(m, " [0x%lx->0x%lx] %s\n",
-				prev_pfn_type, pfn, type_name[prev_type]);
-			prev_pfn_type = pfn;
-			prev_type = type;
-		}
-		if (prev_level != lvl) {
-			seq_printf(m, " [0x%lx->0x%lx] level %s\n",
-				prev_pfn_level, pfn, level_name[prev_level]);
-			prev_pfn_level = pfn;
-			prev_level = lvl;
+			first_pfn = pfn;
 		}
 	}
+	seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+		   type_name[prev_type]);
 	return 0;
-#undef TYPE_IDENTITY
-#undef TYPE_MISSING
-#undef TYPE_PFN
-#undef TYPE_UNKNOWN
 }
 
 static int p2m_dump_open(struct inode *inode, struct file *filp)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 02b0b0f..f92921f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -49,7 +49,7 @@ void xen_hvm_init_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-unsigned long __init xen_revector_p2m_tree(void);
+void __init xen_vmalloc_p2m_tree(void);
 
 void xen_init_irq_ops(void);
 void xen_setup_timer(int cpu);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv6-0007yf-3H; Thu, 06 Nov 2014 05:47:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv4-0007xv-6n
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:42 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7D/15-24532-D7B0B545; Thu, 06 Nov 2014 05:47:41 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415252860!11778740!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18569 invoked from network); 6 Nov 2014 05:47:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:40 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8ABC1ADA7;
	Thu,  6 Nov 2014 05:47:39 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:31 +0100
Message-Id: <1415252853-7106-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415252853-7106-1-git-send-email-jgross@suse.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 3/5] xen: Delay invalidating extra memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When the physical memory configuration is initialized the p2m entries
for not pouplated memory pages are set to "invalid". As those pages
are beyond the hypervisor built p2m list the p2m tree has to be
extended.

This patch delays processing the extra memory related p2m entries
during the boot process until some more basic memory management
functions are callable. This removes the need to create new p2m
entries until virtual memory management is available.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |   3 +
 arch/x86/xen/p2m.c              | 130 ++++++++--------------------------------
 arch/x86/xen/setup.c            | 103 ++++++++++++++++++++++---------
 arch/x86/xen/xen-ops.h          |   3 +-
 4 files changed, 107 insertions(+), 132 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index b475297..28fa795 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -41,6 +41,9 @@ typedef struct xpaddr {
 
 extern unsigned long *machine_to_phys_mapping;
 extern unsigned long  machine_to_phys_nr;
+extern unsigned long *xen_p2m_addr;
+extern unsigned long  xen_p2m_size;
+extern unsigned long  xen_max_p2m_pfn;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 2647a65..7c409b0 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -181,7 +181,12 @@
 
 static void __init m2p_override_init(void);
 
+unsigned long *xen_p2m_addr __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_addr);
+unsigned long xen_p2m_size __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
+EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
@@ -198,13 +203,6 @@ static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
 
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
 
-/* For each I/O range remapped we may lose up to two leaf pages for the boundary
- * violations and three mid pages to cover up to 3GB. With
- * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
- * remapped region.
- */
-RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
-
 static int use_brk = 1;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
@@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	unsigned long max_pfn;
 	unsigned long pfn;
 
-	 if (xen_feature(XENFEAT_auto_translated_physmap))
+	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
+	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
 	mfn_list = (unsigned long *)xen_start_info->mfn_list;
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
+	xen_p2m_size = max_pfn;
 
 	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
@@ -497,6 +497,11 @@ unsigned long __init xen_revector_p2m_tree(void)
 		/* This should be the leafs allocated for identity from _brk. */
 	}
 
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_p2m_addr = mfn_list;
+
+	xen_inv_extra_mem();
+
 	m2p_override_init();
 	return (unsigned long)mfn_list;
 }
@@ -504,6 +509,8 @@ unsigned long __init xen_revector_p2m_tree(void)
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_inv_extra_mem();
 	m2p_override_init();
 	return 0;
 }
@@ -512,8 +519,12 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(pfn >= MAX_P2M_PFN))
+	if (unlikely(pfn >= xen_p2m_size)) {
+		if (pfn < xen_max_p2m_pfn)
+			return xen_chk_extra_mem(pfn);
+
 		return IDENTITY_FRAME(pfn);
+	}
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
@@ -611,78 +622,12 @@ static bool alloc_p2m(unsigned long pfn)
 	return true;
 }
 
-static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
-{
-	unsigned topidx, mididx, idx;
-	unsigned long *p2m;
-
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* Pfff.. No boundary cross-over, lets get out. */
-	if (!idx && check_boundary)
-		return false;
-
-	WARN(p2m_top[topidx][mididx] == p2m_identity,
-		"P2M[%d][%d] == IDENTITY, should be MISSING (or alloced)!\n",
-		topidx, mididx);
-
-	/*
-	 * Could be done by xen_build_dynamic_phys_to_machine..
-	 */
-	if (p2m_top[topidx][mididx] != p2m_missing)
-		return false;
-
-	/* Boundary cross-over for the edges: */
-	p2m = alloc_p2m_page();
-
-	p2m_init(p2m);
-
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-
-static bool __init early_alloc_p2m_middle(unsigned long pfn)
-{
-	unsigned topidx = p2m_top_index(pfn);
-	unsigned long **mid;
-
-	mid = p2m_top[topidx];
-	if (mid == p2m_mid_missing) {
-		mid = alloc_p2m_page();
-
-		p2m_mid_init(mid, p2m_missing);
-
-		p2m_top[topidx] = mid;
-	}
-	return true;
-}
-
-static void __init early_split_p2m(unsigned long pfn)
-{
-	unsigned long mididx, idx;
-
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/*
-	 * Allocate new middle and leaf pages if this pfn lies in the
-	 * middle of one.
-	 */
-	if (mididx || idx)
-		early_alloc_p2m_middle(pfn);
-	if (idx)
-		early_alloc_p2m(pfn, false);
-}
-
 unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 				      unsigned long pfn_e)
 {
 	unsigned long pfn;
 
-	if (unlikely(pfn_s >= MAX_P2M_PFN))
+	if (unlikely(pfn_s >= xen_p2m_size))
 		return 0;
 
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -691,34 +636,11 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	if (pfn_s > pfn_e)
 		return 0;
 
-	if (pfn_e > MAX_P2M_PFN)
-		pfn_e = MAX_P2M_PFN;
-
-	early_split_p2m(pfn_s);
-	early_split_p2m(pfn_e);
-
-	for (pfn = pfn_s; pfn < pfn_e;) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-
-		if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
-			break;
-		pfn++;
-
-		/*
-		 * If the PFN was set to a middle or leaf identity
-		 * page the remainder must also be identity, so skip
-		 * ahead to the next middle or leaf entry.
-		 */
-		if (p2m_top[topidx] == p2m_mid_identity)
-			pfn = ALIGN(pfn, P2M_MID_PER_PAGE * P2M_PER_PAGE);
-		else if (p2m_top[topidx][mididx] == p2m_identity)
-			pfn = ALIGN(pfn, P2M_PER_PAGE);
-	}
+	if (pfn_e > xen_p2m_size)
+		pfn_e = xen_p2m_size;
 
-	WARN((pfn - pfn_s) != (pfn_e - pfn_s),
-		"Identity mapping failed. We are %ld short of 1-1 mappings!\n",
-		(pfn_e - pfn_s) - (pfn - pfn_s));
+	for (pfn = pfn_s; pfn < pfn_e; pfn++)
+		xen_p2m_addr[pfn] = IDENTITY_FRAME(pfn);
 
 	return pfn - pfn_s;
 }
@@ -732,7 +654,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
 		return true;
 
-	if (unlikely(pfn >= MAX_P2M_PFN)) {
+	if (unlikely(pfn >= xen_p2m_size)) {
 		BUG_ON(mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 0e5f9b6..8d5985b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -75,7 +75,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 static void __init xen_add_extra_mem(u64 start, u64 size)
 {
-	unsigned long pfn;
 	int i;
 
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
@@ -95,17 +94,74 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
 
 	memblock_reserve(start, size);
+}
 
-	xen_max_p2m_pfn = PFN_DOWN(start + size);
-	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
-		unsigned long mfn = pfn_to_mfn(pfn);
+static void __init xen_del_extra_mem(u64 start, u64 size)
+{
+	int i;
+	u64 start_r, size_r;
 
-		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
-			continue;
-		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
-			  pfn, mfn);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		start_r = xen_extra_mem[i].start;
+		size_r = xen_extra_mem[i].size;
+
+		/* Start of region. */
+		if (start_r == start) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].start += size;
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* End of region. */
+		if (start_r + size_r == start + size) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* Mid of region. */
+		if (start > start_r && start < start_r + size_r) {
+			BUG_ON(start + size > start_r + size_r);
+			xen_extra_mem[i].size = start - start_r;
+			xen_add_extra_mem(start + size, start_r + size_r -
+					  (start + size));
+			break;
+		}
+	}
+	memblock_free(start, size);
+}
+
+/*
+ * Called during boot before the p2m list can take entries beyond the
+ * hypervisor supplied p2m list. Entries in extra mem are to be regarded as
+ * invalid.
+ */
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
+{
+	int i;
+	unsigned long addr = PFN_PHYS(pfn);
 
-		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		if (addr >= xen_extra_mem[i].start &&
+		    addr < xen_extra_mem[i].start + xen_extra_mem[i].size)
+			return INVALID_P2M_ENTRY;
+	}
+
+	return IDENTITY_FRAME(pfn);
+}
+
+/*
+ * Mark all pfns of extra mem as invalid in p2m list.
+ */
+void __init xen_inv_extra_mem(void)
+{
+	unsigned long pfn, pfn_s, pfn_e;
+	int i;
+
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		pfn_s = PFN_DOWN(xen_extra_mem[i].start);
+		pfn_e = PFN_UP(xen_extra_mem[i].start + xen_extra_mem[i].size);
+		for (pfn = pfn_s; pfn < pfn_e; pfn++)
+			set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 	}
 }
 
@@ -269,9 +325,6 @@ static void __init xen_do_set_identity_and_remap_chunk(
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/* Don't use memory until remapped */
-	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
-
 	mfn_save = virt_to_mfn(buf);
 
 	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
@@ -315,7 +368,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
  * pages. In the case of an error the underlying memory is simply released back
  * to Xen and not remapped.
  */
-static unsigned long __init xen_set_identity_and_remap_chunk(
+static unsigned long xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
 	unsigned long *identity, unsigned long *released)
@@ -372,7 +425,7 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 	return remap_pfn;
 }
 
-static unsigned long __init xen_set_identity_and_remap(
+static void __init xen_set_identity_and_remap(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages,
 	unsigned long *released)
 {
@@ -416,8 +469,6 @@ static unsigned long __init xen_set_identity_and_remap(
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
 	pr_info("Released %ld page(s)\n", num_released);
-
-	return last_pfn;
 }
 
 /*
@@ -449,8 +500,9 @@ void __init xen_remap_memory(void)
 			} else {
 				if (!released) {
 					if (pfn_s != ~0UL && len)
-						memblock_free(PFN_PHYS(pfn_s),
-							      PFN_PHYS(len));
+						xen_del_extra_mem(
+							PFN_PHYS(pfn_s),
+							PFN_PHYS(len));
 					pfn_s = xen_remap_buf.target_pfn;
 					len = i;
 				}
@@ -470,7 +522,8 @@ void __init xen_remap_memory(void)
 			} else if (pfn_s + len == xen_remap_buf.target_pfn) {
 				len += xen_remap_buf.size;
 			} else {
-				memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+				xen_del_extra_mem(PFN_PHYS(pfn_s),
+						  PFN_PHYS(len));
 				pfn_s = xen_remap_buf.target_pfn;
 				len = xen_remap_buf.size;
 			}
@@ -484,7 +537,7 @@ void __init xen_remap_memory(void)
 	}
 
 	if (pfn_s != ~0UL && len)
-		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+		xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
 
 	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 
@@ -553,7 +606,6 @@ char * __init xen_memory_setup(void)
 	int rc;
 	struct xen_memory_map memmap;
 	unsigned long max_pages;
-	unsigned long last_pfn = 0;
 	unsigned long extra_pages = 0;
 	int i;
 	int op;
@@ -603,15 +655,11 @@ char * __init xen_memory_setup(void)
 	 * Set identity map on non-RAM pages and prepare remapping the
 	 * underlying RAM.
 	 */
-	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
-					      &xen_released_pages);
+	xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
+				   &xen_released_pages);
 
 	extra_pages += xen_released_pages;
 
-	if (last_pfn > max_pfn) {
-		max_pfn = min(MAX_DOMAIN_PAGES, last_pfn);
-		mem_end = PFN_PHYS(max_pfn);
-	}
 	/*
 	 * Clamp the amount of extra memory to a EXTRA_MEM_RATIO
 	 * factor the base size.  On non-highmem systems, the base
@@ -638,6 +686,7 @@ char * __init xen_memory_setup(void)
 				size = min(size, (u64)extra_pages * PAGE_SIZE);
 				extra_pages -= size / PAGE_SIZE;
 				xen_add_extra_mem(addr, size);
+				xen_max_p2m_pfn = PFN_DOWN(addr + size);
 			} else
 				type = E820_UNUSABLE;
 		}
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 5b72a06..02b0b0f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -29,12 +29,13 @@ void xen_build_mfn_list_list(void);
 void xen_setup_machphys_mapping(void);
 void xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn);
 void xen_reserve_top(void);
-extern unsigned long xen_max_p2m_pfn;
 
 void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn);
+void __init xen_inv_extra_mem(void);
 void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv5-0007yR-CI; Thu, 06 Nov 2014 05:47:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv3-0007xq-V2
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:42 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	1D/E3-02984-D7B0B545; Thu, 06 Nov 2014 05:47:41 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415252860!11721356!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8155 invoked from network); 6 Nov 2014 05:47:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:40 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 325B2ADA4;
	Thu,  6 Nov 2014 05:47:39 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:30 +0100
Message-Id: <1415252853-7106-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415252853-7106-1-git-send-email-jgross@suse.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 2/5] xen: Delay m2p_override initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 m2p overrides are used to be able to find the local pfn for a
foreign mfn mapped into the domain. They are used by driver backends
having to access frontend data.

As this functionality isn't used in early boot it makes no sense to
initialize the m2p override functions very early. It can be done
later without doing any harm, removing the need for allocating memory
via extend_brk().

While at it make some m2p override functions static as they are only
used internally.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |   6 --
 arch/x86/xen/p2m.c              | 198 ++++++++++++++++++++--------------------
 2 files changed, 101 insertions(+), 103 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c29619c..b475297 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -51,15 +51,9 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 				   struct gnttab_map_grant_ref *kmap_ops,
 				   struct page **pages, unsigned int count);
-extern int m2p_add_override(unsigned long mfn, struct page *page,
-			    struct gnttab_map_grant_ref *kmap_op);
 extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct gnttab_map_grant_ref *kmap_ops,
 				     struct page **pages, unsigned int count);
-extern int m2p_remove_override(struct page *page,
-			       struct gnttab_map_grant_ref *kmap_op,
-			       unsigned long mfn);
-extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 49316ac..2647a65 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -426,8 +426,6 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		}
 		p2m_top[topidx][mididx] = &mfn_list[pfn];
 	}
-
-	m2p_override_init();
 }
 #ifdef CONFIG_X86_64
 unsigned long __init xen_revector_p2m_tree(void)
@@ -498,13 +496,15 @@ unsigned long __init xen_revector_p2m_tree(void)
 		}
 		/* This should be the leafs allocated for identity from _brk. */
 	}
-	return (unsigned long)mfn_list;
 
+	m2p_override_init();
+	return (unsigned long)mfn_list;
 }
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	m2p_override_init();
 	return 0;
 }
 #endif
@@ -794,15 +794,16 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 #define M2P_OVERRIDE_HASH_SHIFT	10
 #define M2P_OVERRIDE_HASH	(1 << M2P_OVERRIDE_HASH_SHIFT)
 
-static RESERVE_BRK_ARRAY(struct list_head, m2p_overrides, M2P_OVERRIDE_HASH);
+static struct list_head *m2p_overrides;
 static DEFINE_SPINLOCK(m2p_override_lock);
 
 static void __init m2p_override_init(void)
 {
 	unsigned i;
 
-	m2p_overrides = extend_brk(sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
-				   sizeof(unsigned long));
+	m2p_overrides = alloc_bootmem_align(
+				sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
+				sizeof(unsigned long));
 
 	for (i = 0; i < M2P_OVERRIDE_HASH; i++)
 		INIT_LIST_HEAD(&m2p_overrides[i]);
@@ -813,67 +814,8 @@ static unsigned long mfn_hash(unsigned long mfn)
 	return hash_long(mfn, M2P_OVERRIDE_HASH_SHIFT);
 }
 
-int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
-			    struct gnttab_map_grant_ref *kmap_ops,
-			    struct page **pages, unsigned int count)
-{
-	int i, ret = 0;
-	bool lazy = false;
-	pte_t *pte;
-
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return 0;
-
-	if (kmap_ops &&
-	    !in_interrupt() &&
-	    paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
-		arch_enter_lazy_mmu_mode();
-		lazy = true;
-	}
-
-	for (i = 0; i < count; i++) {
-		unsigned long mfn, pfn;
-
-		/* Do not add to override if the map failed. */
-		if (map_ops[i].status)
-			continue;
-
-		if (map_ops[i].flags & GNTMAP_contains_pte) {
-			pte = (pte_t *) (mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
-				(map_ops[i].host_addr & ~PAGE_MASK));
-			mfn = pte_mfn(*pte);
-		} else {
-			mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
-		}
-		pfn = page_to_pfn(pages[i]);
-
-		WARN_ON(PagePrivate(pages[i]));
-		SetPagePrivate(pages[i]);
-		set_page_private(pages[i], mfn);
-		pages[i]->index = pfn_to_mfn(pfn);
-
-		if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) {
-			ret = -ENOMEM;
-			goto out;
-		}
-
-		if (kmap_ops) {
-			ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]);
-			if (ret)
-				goto out;
-		}
-	}
-
-out:
-	if (lazy)
-		arch_leave_lazy_mmu_mode();
-
-	return ret;
-}
-EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
-
 /* Add an MFN override for a particular page */
-int m2p_add_override(unsigned long mfn, struct page *page,
+static int m2p_add_override(unsigned long mfn, struct page *page,
 		struct gnttab_map_grant_ref *kmap_op)
 {
 	unsigned long flags;
@@ -926,14 +868,14 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(m2p_add_override);
 
-int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
-			      struct gnttab_map_grant_ref *kmap_ops,
-			      struct page **pages, unsigned int count)
+int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
+			    struct gnttab_map_grant_ref *kmap_ops,
+			    struct page **pages, unsigned int count)
 {
 	int i, ret = 0;
 	bool lazy = false;
+	pte_t *pte;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return 0;
@@ -946,33 +888,74 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 	}
 
 	for (i = 0; i < count; i++) {
-		unsigned long mfn = get_phys_to_machine(page_to_pfn(pages[i]));
-		unsigned long pfn = page_to_pfn(pages[i]);
+		unsigned long mfn, pfn;
 
-		if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
-			ret = -EINVAL;
-			goto out;
+		/* Do not add to override if the map failed. */
+		if (map_ops[i].status)
+			continue;
+
+		if (map_ops[i].flags & GNTMAP_contains_pte) {
+			mfn = PFN_DOWN(map_ops[i].host_addr);
+			pte = (pte_t *)(mfn_to_virt(mfn) +
+				(map_ops[i].host_addr & ~PAGE_MASK));
+			mfn = pte_mfn(*pte);
+		} else {
+			mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
 		}
+		pfn = page_to_pfn(pages[i]);
 
-		set_page_private(pages[i], INVALID_P2M_ENTRY);
-		WARN_ON(!PagePrivate(pages[i]));
-		ClearPagePrivate(pages[i]);
-		set_phys_to_machine(pfn, pages[i]->index);
+		WARN_ON(PagePrivate(pages[i]));
+		SetPagePrivate(pages[i]);
+		set_page_private(pages[i], mfn);
+		pages[i]->index = pfn_to_mfn(pfn);
 
-		if (kmap_ops)
-			ret = m2p_remove_override(pages[i], &kmap_ops[i], mfn);
-		if (ret)
+		if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) {
+			ret = -ENOMEM;
 			goto out;
+		}
+
+		if (kmap_ops) {
+			ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]);
+			if (ret)
+				goto out;
+		}
 	}
 
 out:
 	if (lazy)
 		arch_leave_lazy_mmu_mode();
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
+
+static struct page *m2p_find_override(unsigned long mfn)
+{
+	unsigned long flags;
+	struct list_head *bucket;
+	struct page *p, *ret;
+
+	ret = NULL;
+
+	if (m2p_overrides) {
+		bucket = &m2p_overrides[mfn_hash(mfn)];
+
+		spin_lock_irqsave(&m2p_override_lock, flags);
+
+		list_for_each_entry(p, bucket, lru) {
+			if (page_private(p) == mfn) {
+				ret = p;
+				break;
+			}
+		}
+
+		spin_unlock_irqrestore(&m2p_override_lock, flags);
+	}
+
 	return ret;
 }
-EXPORT_SYMBOL_GPL(clear_foreign_p2m_mapping);
 
-int m2p_remove_override(struct page *page,
+static int m2p_remove_override(struct page *page,
 			struct gnttab_map_grant_ref *kmap_op,
 			unsigned long mfn)
 {
@@ -1068,29 +1051,50 @@ int m2p_remove_override(struct page *page,
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(m2p_remove_override);
 
-struct page *m2p_find_override(unsigned long mfn)
+int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
+			      struct gnttab_map_grant_ref *kmap_ops,
+			      struct page **pages, unsigned int count)
 {
-	unsigned long flags;
-	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
-	struct page *p, *ret;
+	int i, ret = 0;
+	bool lazy = false;
 
-	ret = NULL;
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
 
-	spin_lock_irqsave(&m2p_override_lock, flags);
+	if (kmap_ops &&
+	    !in_interrupt() &&
+	    paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+		arch_enter_lazy_mmu_mode();
+		lazy = true;
+	}
 
-	list_for_each_entry(p, bucket, lru) {
-		if (page_private(p) == mfn) {
-			ret = p;
-			break;
+	for (i = 0; i < count; i++) {
+		unsigned long mfn = get_phys_to_machine(page_to_pfn(pages[i]));
+		unsigned long pfn = page_to_pfn(pages[i]);
+
+		if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
+			ret = -EINVAL;
+			goto out;
 		}
-	}
 
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
+		set_page_private(pages[i], INVALID_P2M_ENTRY);
+		WARN_ON(!PagePrivate(pages[i]));
+		ClearPagePrivate(pages[i]);
+		set_phys_to_machine(pfn, pages[i]->index);
 
+		if (kmap_ops)
+			ret = m2p_remove_override(pages[i], &kmap_ops[i], mfn);
+		if (ret)
+			goto out;
+	}
+
+out:
+	if (lazy)
+		arch_leave_lazy_mmu_mode();
 	return ret;
 }
+EXPORT_SYMBOL_GPL(clear_foreign_p2m_mapping);
 
 unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
 {
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv5-0007yY-Nk; Thu, 06 Nov 2014 05:47:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv4-0007xp-1T
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:42 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	C7/74-14727-D7B0B545; Thu, 06 Nov 2014 05:47:41 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415252859!11471356!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7912 invoked from network); 6 Nov 2014 05:47:39 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:39 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DAFB4ADA1;
	Thu,  6 Nov 2014 05:47:38 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:29 +0100
Message-Id: <1415252853-7106-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415252853-7106-1-git-send-email-jgross@suse.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 1/5] Xen: Delay remapping memory of pv-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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Early in the boot process the memory layout of a pv-domain is changed
to match the E820 map (either the host one for Dom0 or the Xen one)
regarding placement of RAM and PCI holes. This requires removing memory
pages initially located at positions not suitable for RAM and adding
them later at higher addresses where no restrictions apply.

To be able to operate on the hypervisor supported p2m list until a
virtual mapped linear p2m list can be constructed, remapping must
be delayed until virtual memory management is initialized, as the
initial p2m list can't be extended unlimited at physical memory
initialization time due to it's fixed structure.

A further advantage is the reduction in complexity and code volume as
we don't have to be careful regarding memory restrictions during p2m
updates.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |   1 -
 arch/x86/xen/mmu.c              |   4 +
 arch/x86/xen/p2m.c              | 149 ++++------------
 arch/x86/xen/setup.c            | 385 +++++++++++++++++++---------------------
 arch/x86/xen/xen-ops.h          |   1 +
 5 files changed, 223 insertions(+), 317 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c949923..c29619c 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -44,7 +44,6 @@ extern unsigned long  machine_to_phys_nr;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
-extern bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 					     unsigned long pfn_e);
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a8a1a3d..d3e492b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1223,6 +1223,10 @@ static void __init xen_pagetable_init(void)
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
+	/* Remap memory freed because of conflicts with E820 map */
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_remap_memory();
+
 	xen_setup_shared_info();
 	xen_post_allocator_init();
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index b456b04..49316ac 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -164,6 +164,7 @@
 #include <linux/sched.h>
 #include <linux/seq_file.h>
 #include <linux/bootmem.h>
+#include <linux/slab.h>
 
 #include <asm/cache.h>
 #include <asm/setup.h>
@@ -204,6 +205,8 @@ RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER
  */
 RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
+static int use_brk = 1;
+
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
 	BUG_ON(pfn >= MAX_P2M_PFN);
@@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
 		p2m[i] = INVALID_P2M_ENTRY;
 }
 
+static void * __ref alloc_p2m_page(void)
+{
+	if (unlikely(use_brk))
+		return extend_brk(PAGE_SIZE, PAGE_SIZE);
+
+	if (unlikely(!slab_is_available()))
+		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+
+	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static void free_p2m_page(void *p)
+{
+	free_page((unsigned long)p);
+}
+
 /*
  * Build the parallel p2m_top_mfn and p2m_mid_mfn structures
  *
@@ -287,13 +306,13 @@ void __ref xen_build_mfn_list_list(void)
 
 	/* Pre-initialize p2m_top_mfn to be completely missing */
 	if (p2m_top_mfn == NULL) {
-		p2m_mid_missing_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_mid_missing_mfn = alloc_p2m_page();
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 
-		p2m_top_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn_p = alloc_p2m_page();
 		p2m_top_mfn_p_init(p2m_top_mfn_p);
 
-		p2m_top_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn = alloc_p2m_page();
 		p2m_top_mfn_init(p2m_top_mfn);
 	} else {
 		/* Reinitialise, mfn's all change after migration */
@@ -327,7 +346,7 @@ void __ref xen_build_mfn_list_list(void)
 			 * missing parts of the mfn tree after
 			 * runtime.
 			 */
-			mid_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
 			p2m_top_mfn_p[topidx] = mid_mfn_p;
@@ -364,17 +383,17 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
 
-	p2m_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
-	p2m_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_identity = alloc_p2m_page();
 	p2m_init(p2m_identity);
 
-	p2m_mid_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_missing = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_identity = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_identity, p2m_identity);
 
-	p2m_top = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_top = alloc_p2m_page();
 	p2m_top_init(p2m_top);
 
 	/*
@@ -387,7 +406,7 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		unsigned mididx = p2m_mid_index(pfn);
 
 		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+			unsigned long **mid = alloc_p2m_page();
 			p2m_mid_init(mid, p2m_missing);
 
 			p2m_top[topidx] = mid;
@@ -420,6 +439,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 	unsigned long *mfn_list = NULL;
 	unsigned long size;
 
+	use_brk = 0;
 	va_start = xen_start_info->mfn_list;
 	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
 	 * so make sure it is rounded up to that */
@@ -484,6 +504,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
+	use_brk = 0;
 	return 0;
 }
 #endif
@@ -510,16 +531,6 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
-static void *alloc_p2m_page(void)
-{
-	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
-}
-
-static void free_p2m_page(void *p)
-{
-	free_page((unsigned long)p);
-}
-
 /*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
@@ -624,7 +635,7 @@ static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
 		return false;
 
 	/* Boundary cross-over for the edges: */
-	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m = alloc_p2m_page();
 
 	p2m_init(p2m);
 
@@ -640,7 +651,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 
 	mid = p2m_top[topidx];
 	if (mid == p2m_mid_missing) {
-		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+		mid = alloc_p2m_page();
 
 		p2m_mid_init(mid, p2m_missing);
 
@@ -649,100 +660,6 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 	return true;
 }
 
-/*
- * Skim over the P2M tree looking at pages that are either filled with
- * INVALID_P2M_ENTRY or with 1:1 PFNs. If found, re-use that page and
- * replace the P2M leaf with a p2m_missing or p2m_identity.
- * Stick the old page in the new P2M tree location.
- */
-static bool __init early_can_reuse_p2m_middle(unsigned long set_pfn)
-{
-	unsigned topidx;
-	unsigned mididx;
-	unsigned ident_pfns;
-	unsigned inv_pfns;
-	unsigned long *p2m;
-	unsigned idx;
-	unsigned long pfn;
-
-	/* We only look when this entails a P2M middle layer */
-	if (p2m_index(set_pfn))
-		return false;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
-		topidx = p2m_top_index(pfn);
-
-		if (!p2m_top[topidx])
-			continue;
-
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
-
-		mididx = p2m_mid_index(pfn);
-		p2m = p2m_top[topidx][mididx];
-		if (!p2m)
-			continue;
-
-		if ((p2m == p2m_missing) || (p2m == p2m_identity))
-			continue;
-
-		if ((unsigned long)p2m == INVALID_P2M_ENTRY)
-			continue;
-
-		ident_pfns = 0;
-		inv_pfns = 0;
-		for (idx = 0; idx < P2M_PER_PAGE; idx++) {
-			/* IDENTITY_PFNs are 1:1 */
-			if (p2m[idx] == IDENTITY_FRAME(pfn + idx))
-				ident_pfns++;
-			else if (p2m[idx] == INVALID_P2M_ENTRY)
-				inv_pfns++;
-			else
-				break;
-		}
-		if ((ident_pfns == P2M_PER_PAGE) || (inv_pfns == P2M_PER_PAGE))
-			goto found;
-	}
-	return false;
-found:
-	/* Found one, replace old with p2m_identity or p2m_missing */
-	p2m_top[topidx][mididx] = (ident_pfns ? p2m_identity : p2m_missing);
-
-	/* Reset where we want to stick the old page in. */
-	topidx = p2m_top_index(set_pfn);
-	mididx = p2m_mid_index(set_pfn);
-
-	/* This shouldn't happen */
-	if (WARN_ON(p2m_top[topidx] == p2m_mid_missing))
-		early_alloc_p2m_middle(set_pfn);
-
-	if (WARN_ON(p2m_top[topidx][mididx] != p2m_missing))
-		return false;
-
-	p2m_init(p2m);
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn)
-{
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
-		if (!early_alloc_p2m_middle(pfn))
-			return false;
-
-		if (early_can_reuse_p2m_middle(pfn))
-			return __set_phys_to_machine(pfn, mfn);
-
-		if (!early_alloc_p2m(pfn, false /* boundary crossover OK!*/))
-			return false;
-
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
-	}
-
-	return true;
-}
-
 static void __init early_split_p2m(unsigned long pfn)
 {
 	unsigned long mididx, idx;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 29834b3..0e5f9b6 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -30,6 +30,7 @@
 #include "xen-ops.h"
 #include "vdso.h"
 #include "p2m.h"
+#include "mmu.h"
 
 /* These are code, but not functions.  Defined in entry.S */
 extern const char xen_hypervisor_callback[];
@@ -47,8 +48,18 @@ struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 /* Number of pages released from the initial allocation. */
 unsigned long xen_released_pages;
 
-/* Buffer used to remap identity mapped pages */
-unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
+/*
+ * Buffer used to remap identity mapped pages. We only need the virtual space.
+ * The physical memory for each buffer page is remapped as needed.
+ */
+#define REMAP_SIZE	(P2M_PER_PAGE - 3)
+static struct {
+	unsigned long	next_area_mfn;
+	unsigned long	target_pfn;
+	unsigned long	size;
+	unsigned long	mfns[REMAP_SIZE];
+} xen_remap_buf __initdata __aligned(PAGE_SIZE);
+static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 /* 
  * The maximum amount of extra memory compared to the base size.  The
@@ -98,63 +109,6 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 	}
 }
 
-static unsigned long __init xen_do_chunk(unsigned long start,
-					 unsigned long end, bool release)
-{
-	struct xen_memory_reservation reservation = {
-		.address_bits = 0,
-		.extent_order = 0,
-		.domid        = DOMID_SELF
-	};
-	unsigned long len = 0;
-	unsigned long pfn;
-	int ret;
-
-	for (pfn = start; pfn < end; pfn++) {
-		unsigned long frame;
-		unsigned long mfn = pfn_to_mfn(pfn);
-
-		if (release) {
-			/* Make sure pfn exists to start with */
-			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
-				continue;
-			frame = mfn;
-		} else {
-			if (mfn != INVALID_P2M_ENTRY)
-				continue;
-			frame = pfn;
-		}
-		set_xen_guest_handle(reservation.extent_start, &frame);
-		reservation.nr_extents = 1;
-
-		ret = HYPERVISOR_memory_op(release ? XENMEM_decrease_reservation : XENMEM_populate_physmap,
-					   &reservation);
-		WARN(ret != 1, "Failed to %s pfn %lx err=%d\n",
-		     release ? "release" : "populate", pfn, ret);
-
-		if (ret == 1) {
-			if (!early_set_phys_to_machine(pfn, release ? INVALID_P2M_ENTRY : frame)) {
-				if (release)
-					break;
-				set_xen_guest_handle(reservation.extent_start, &frame);
-				reservation.nr_extents = 1;
-				ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
-							   &reservation);
-				break;
-			}
-			len++;
-		} else
-			break;
-	}
-	if (len)
-		printk(KERN_INFO "%s %lx-%lx pfn range: %lu pages %s\n",
-		       release ? "Freeing" : "Populating",
-		       start, end, len,
-		       release ? "freed" : "added");
-
-	return len;
-}
-
 /*
  * Finds the next RAM pfn available in the E820 map after min_pfn.
  * This function updates min_pfn with the pfn found and returns
@@ -198,23 +152,60 @@ static unsigned long __init xen_find_pfn_range(
 	return done;
 }
 
+static int __init xen_free_mfn(unsigned long mfn)
+{
+	struct xen_memory_reservation reservation = {
+		.address_bits = 0,
+		.extent_order = 0,
+		.domid        = DOMID_SELF
+	};
+
+	set_xen_guest_handle(reservation.extent_start, &mfn);
+	reservation.nr_extents = 1;
+
+	return HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation);
+}
+
 /*
- * This releases a chunk of memory and then does the identity map. It's used as
+ * This releases a chunk of memory and then does the identity map. It's used
  * as a fallback if the remapping fails.
  */
 static void __init xen_set_identity_and_release_chunk(unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long *identity,
 	unsigned long *released)
 {
+	unsigned long len = 0;
+	unsigned long pfn, end;
+	int ret;
+
 	WARN_ON(start_pfn > end_pfn);
 
+	end = min(end_pfn, nr_pages);
+	for (pfn = start_pfn; pfn < end; pfn++) {
+		unsigned long mfn = pfn_to_mfn(pfn);
+
+		/* Make sure pfn exists to start with */
+		if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+			continue;
+
+		ret = xen_free_mfn(mfn);
+		WARN(ret != 1, "Failed to release pfn %lx err=%d\n", pfn, ret);
+
+		if (ret == 1) {
+			if (!__set_phys_to_machine(pfn, INVALID_P2M_ENTRY))
+				break;
+			len++;
+		} else
+			break;
+	}
+
 	/* Need to release pages first */
-	*released += xen_do_chunk(start_pfn, min(end_pfn, nr_pages), true);
+	*released += len;
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
 /*
- * Helper function to update both the p2m and m2p tables.
+ * Helper function to update the p2m and m2p tables and kernel mapping.
  */
 static unsigned long __init xen_update_mem_tables(unsigned long pfn,
 						  unsigned long mfn)
@@ -225,161 +216,92 @@ static unsigned long __init xen_update_mem_tables(unsigned long pfn,
 	};
 
 	/* Update p2m */
-	if (!early_set_phys_to_machine(pfn, mfn)) {
+	if (!set_phys_to_machine(pfn, mfn)) {
 		WARN(1, "Failed to set p2m mapping for pfn=%ld mfn=%ld\n",
 		     pfn, mfn);
-		return false;
+		return 0;
 	}
 
 	/* Update m2p */
 	if (HYPERVISOR_mmu_update(&update, 1, NULL, DOMID_SELF) < 0) {
 		WARN(1, "Failed to set m2p mapping for mfn=%ld pfn=%ld\n",
 		     mfn, pfn);
-		return false;
+		return 0;
+	}
+
+	/* Update kernel mapping, but not for highmem. */
+	if ((pfn << PAGE_SHIFT) >= __pa(high_memory))
+		return 1;
+
+	if (HYPERVISOR_update_va_mapping((unsigned long)__va(pfn << PAGE_SHIFT),
+					 mfn_pte(mfn, PAGE_KERNEL), 0)) {
+		WARN(1, "Failed to update kernel mapping for mfn=%ld pfn=%ld\n",
+		      mfn, pfn);
+		return 0;
 	}
 
-	return true;
+	return 1;
 }
 
 /*
  * This function updates the p2m and m2p tables with an identity map from
- * start_pfn to start_pfn+size and remaps the underlying RAM of the original
- * allocation at remap_pfn. It must do so carefully in P2M_PER_PAGE sized blocks
- * to not exhaust the reserved brk space. Doing it in properly aligned blocks
- * ensures we only allocate the minimum required leaf pages in the p2m table. It
- * copies the existing mfns from the p2m table under the 1:1 map, overwrites
- * them with the identity map and then updates the p2m and m2p tables with the
- * remapped memory.
+ * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the
+ * original allocation at remap_pfn. The information needed for remapping is
+ * saved in the memory itself to avoid the need for allocating buffers. The
+ * complete remap information is contained in a list of MFNs each containing
+ * up to REMAP_SIZE MFNs and the start target PFN for doing the remap.
+ * This enables to preserve the original mfn sequence while doing the remapping
+ * at a time when the memory management is capable of allocating virtual and
+ * physical memory in arbitrary amounts.
  */
-static unsigned long __init xen_do_set_identity_and_remap_chunk(
+static void __init xen_do_set_identity_and_remap_chunk(
         unsigned long start_pfn, unsigned long size, unsigned long remap_pfn)
 {
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn;
 	unsigned long ident_pfn_iter, remap_pfn_iter;
-	unsigned long ident_start_pfn_align, remap_start_pfn_align;
-	unsigned long ident_end_pfn_align, remap_end_pfn_align;
-	unsigned long ident_boundary_pfn, remap_boundary_pfn;
-	unsigned long ident_cnt = 0;
-	unsigned long remap_cnt = 0;
+	unsigned long ident_end_pfn = start_pfn + size;
 	unsigned long left = size;
-	unsigned long mod;
-	int i;
+	unsigned long ident_cnt = 0;
+	unsigned int i, chunk;
 
 	WARN_ON(size == 0);
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/*
-	 * Determine the proper alignment to remap memory in P2M_PER_PAGE sized
-	 * blocks. We need to keep track of both the existing pfn mapping and
-	 * the new pfn remapping.
-	 */
-	mod = start_pfn % P2M_PER_PAGE;
-	ident_start_pfn_align =
-		mod ? (start_pfn - mod + P2M_PER_PAGE) : start_pfn;
-	mod = remap_pfn % P2M_PER_PAGE;
-	remap_start_pfn_align =
-		mod ? (remap_pfn - mod + P2M_PER_PAGE) : remap_pfn;
-	mod = (start_pfn + size) % P2M_PER_PAGE;
-	ident_end_pfn_align = start_pfn + size - mod;
-	mod = (remap_pfn + size) % P2M_PER_PAGE;
-	remap_end_pfn_align = remap_pfn + size - mod;
-
-	/* Iterate over each p2m leaf node in each range */
-	for (ident_pfn_iter = ident_start_pfn_align, remap_pfn_iter = remap_start_pfn_align;
-	     ident_pfn_iter < ident_end_pfn_align && remap_pfn_iter < remap_end_pfn_align;
-	     ident_pfn_iter += P2M_PER_PAGE, remap_pfn_iter += P2M_PER_PAGE) {
-		/* Check we aren't past the end */
-		BUG_ON(ident_pfn_iter + P2M_PER_PAGE > start_pfn + size);
-		BUG_ON(remap_pfn_iter + P2M_PER_PAGE > remap_pfn + size);
-
-		/* Save p2m mappings */
-		for (i = 0; i < P2M_PER_PAGE; i++)
-			xen_remap_buf[i] = pfn_to_mfn(ident_pfn_iter + i);
-
-		/* Set identity map which will free a p2m leaf */
-		ident_cnt += set_phys_range_identity(ident_pfn_iter,
-			ident_pfn_iter + P2M_PER_PAGE);
-
-#ifdef DEBUG
-		/* Helps verify a p2m leaf has been freed */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned int pfn = ident_pfn_iter + i;
-			BUG_ON(pfn_to_mfn(pfn) != pfn);
-		}
-#endif
-		/* Now remap memory */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned long mfn = xen_remap_buf[i];
-
-			/* This will use the p2m leaf freed above */
-			if (!xen_update_mem_tables(remap_pfn_iter + i, mfn)) {
-				WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-					remap_pfn_iter + i, mfn);
-				return 0;
-			}
-
-			remap_cnt++;
-		}
-
-		left -= P2M_PER_PAGE;
-	}
+	/* Don't use memory until remapped */
+	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
 
-	/* Max boundary space possible */
-	BUG_ON(left > (P2M_PER_PAGE - 1) * 2);
+	mfn_save = virt_to_mfn(buf);
 
-	/* Now handle the boundary conditions */
-	ident_boundary_pfn = start_pfn;
-	remap_boundary_pfn = remap_pfn;
-	for (i = 0; i < left; i++) {
-		unsigned long mfn;
+	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
+	     ident_pfn_iter < ident_end_pfn;
+	     ident_pfn_iter += REMAP_SIZE, remap_pfn_iter += REMAP_SIZE) {
+		chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE;
 
-		/* These two checks move from the start to end boundaries */
-		if (ident_boundary_pfn == ident_start_pfn_align)
-			ident_boundary_pfn = ident_pfn_iter;
-		if (remap_boundary_pfn == remap_start_pfn_align)
-			remap_boundary_pfn = remap_pfn_iter;
+		/* Map first pfn to xen_remap_buf */
+		mfn = pfn_to_mfn(ident_pfn_iter);
+		set_pte_mfn(buf, mfn, PAGE_KERNEL);
 
-		/* Check we aren't past the end */
-		BUG_ON(ident_boundary_pfn >= start_pfn + size);
-		BUG_ON(remap_boundary_pfn >= remap_pfn + size);
+		/* Save mapping information in page */
+		xen_remap_buf.next_area_mfn = xen_remap_mfn;
+		xen_remap_buf.target_pfn = remap_pfn_iter;
+		xen_remap_buf.size = chunk;
+		for (i = 0; i < chunk; i++)
+			xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i);
 
-		mfn = pfn_to_mfn(ident_boundary_pfn);
+		/* New element first in list */
+		xen_remap_mfn = mfn;
 
-		if (!xen_update_mem_tables(remap_boundary_pfn, mfn)) {
-			WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-				remap_pfn_iter + i, mfn);
-			return 0;
-		}
-		remap_cnt++;
-
-		ident_boundary_pfn++;
-		remap_boundary_pfn++;
-	}
+		/* Set identity map */
+		ident_cnt += set_phys_range_identity(ident_pfn_iter,
+			ident_pfn_iter + chunk);
 
-	/* Finish up the identity map */
-	if (ident_start_pfn_align >= ident_end_pfn_align) {
-		/*
-                 * In this case we have an identity range which does not span an
-                 * aligned block so everything needs to be identity mapped here.
-                 * If we didn't check this we might remap too many pages since
-                 * the align boundaries are not meaningful in this case.
-	         */
-		ident_cnt += set_phys_range_identity(start_pfn,
-			start_pfn + size);
-	} else {
-		/* Remapped above so check each end of the chunk */
-		if (start_pfn < ident_start_pfn_align)
-			ident_cnt += set_phys_range_identity(start_pfn,
-				ident_start_pfn_align);
-		if (start_pfn + size > ident_pfn_iter)
-			ident_cnt += set_phys_range_identity(ident_pfn_iter,
-				start_pfn + size);
+		left -= chunk;
 	}
 
-	BUG_ON(ident_cnt != size);
-	BUG_ON(remap_cnt != size);
-
-	return size;
+	/* Restore old xen_remap_buf mapping */
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 }
 
 /*
@@ -396,8 +318,7 @@ static unsigned long __init xen_do_set_identity_and_remap_chunk(
 static unsigned long __init xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
-	unsigned long *identity, unsigned long *remapped,
-	unsigned long *released)
+	unsigned long *identity, unsigned long *released)
 {
 	unsigned long pfn;
 	unsigned long i = 0;
@@ -431,19 +352,12 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 		if (size > remap_range_size)
 			size = remap_range_size;
 
-		if (!xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn)) {
-			WARN(1, "Failed to remap 1:1 memory cur_pfn=%ld size=%ld remap_pfn=%ld\n",
-				cur_pfn, size, remap_pfn);
-			xen_set_identity_and_release_chunk(cur_pfn,
-				cur_pfn + left, nr_pages, identity, released);
-			break;
-		}
+		xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn);
 
 		/* Update variables to reflect new mappings. */
 		i += size;
 		remap_pfn += size;
 		*identity += size;
-		*remapped += size;
 	}
 
 	/*
@@ -464,7 +378,6 @@ static unsigned long __init xen_set_identity_and_remap(
 {
 	phys_addr_t start = 0;
 	unsigned long identity = 0;
-	unsigned long remapped = 0;
 	unsigned long last_pfn = nr_pages;
 	const struct e820entry *entry;
 	unsigned long num_released = 0;
@@ -494,8 +407,7 @@ static unsigned long __init xen_set_identity_and_remap(
 				last_pfn = xen_set_identity_and_remap_chunk(
 						list, map_size, start_pfn,
 						end_pfn, nr_pages, last_pfn,
-						&identity, &remapped,
-						&num_released);
+						&identity, &num_released);
 			start = end;
 		}
 	}
@@ -503,12 +415,84 @@ static unsigned long __init xen_set_identity_and_remap(
 	*released = num_released;
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
-	pr_info("Remapped %ld page(s), last_pfn=%ld\n", remapped,
-		last_pfn);
 	pr_info("Released %ld page(s)\n", num_released);
 
 	return last_pfn;
 }
+
+/*
+ * Remap the memory prepared in xen_do_set_identity_and_remap_chunk().
+ */
+void __init xen_remap_memory(void)
+{
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn, pfn;
+	unsigned long remapped = 0, released = 0;
+	unsigned int i, free;
+	unsigned long pfn_s = ~0UL;
+	unsigned long len = 0;
+
+	mfn_save = virt_to_mfn(buf);
+
+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
+		/* Map the remap information */
+		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
+
+		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
+
+		free = 0;
+		pfn = xen_remap_buf.target_pfn;
+		for (i = 0; i < xen_remap_buf.size; i++) {
+			mfn = xen_remap_buf.mfns[i];
+			if (!released && xen_update_mem_tables(pfn, mfn)) {
+				remapped++;
+			} else {
+				if (!released) {
+					if (pfn_s != ~0UL && len)
+						memblock_free(PFN_PHYS(pfn_s),
+							      PFN_PHYS(len));
+					pfn_s = xen_remap_buf.target_pfn;
+					len = i;
+				}
+				/* Don't free the page with our mfn list! */
+				if (i)
+					xen_free_mfn(mfn);
+				else
+					free = 1;
+				released++;
+			}
+			pfn++;
+		}
+		if (!released) {
+			if (pfn_s == ~0UL || pfn == pfn_s) {
+				pfn_s = xen_remap_buf.target_pfn;
+				len += xen_remap_buf.size;
+			} else if (pfn_s + len == xen_remap_buf.target_pfn) {
+				len += xen_remap_buf.size;
+			} else {
+				memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+				pfn_s = xen_remap_buf.target_pfn;
+				len = xen_remap_buf.size;
+			}
+		}
+
+		mfn = xen_remap_mfn;
+		xen_remap_mfn = xen_remap_buf.next_area_mfn;
+		/* Now it's save to free the page holding our data. */
+		if (free)
+			xen_free_mfn(mfn);
+	}
+
+	if (pfn_s != ~0UL && len)
+		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
+
+	pr_info("Remapped %ld page(s)\n", remapped);
+	if (released)
+		pr_info("Released %ld page(s)\n", released);
+}
+
 static unsigned long __init xen_get_max_pages(void)
 {
 	unsigned long max_pages = MAX_DOMAIN_PAGES;
@@ -616,7 +600,8 @@ char * __init xen_memory_setup(void)
 		extra_pages += max_pages - max_pfn;
 
 	/*
-	 * Set identity map on non-RAM pages and remap the underlying RAM.
+	 * Set identity map on non-RAM pages and prepare remapping the
+	 * underlying RAM.
 	 */
 	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
 					      &xen_released_pages);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 28c7e0b..5b72a06 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,6 +35,7 @@ void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
 void __init xen_arch_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 05:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 05:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmFv5-0007yR-CI; Thu, 06 Nov 2014 05:47:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmFv3-0007xq-V2
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 05:47:42 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	1D/E3-02984-D7B0B545; Thu, 06 Nov 2014 05:47:41 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415252860!11721356!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8155 invoked from network); 6 Nov 2014 05:47:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 05:47:40 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 325B2ADA4;
	Thu,  6 Nov 2014 05:47:39 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Thu,  6 Nov 2014 06:47:30 +0100
Message-Id: <1415252853-7106-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415252853-7106-1-git-send-email-jgross@suse.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V2 2/5] xen: Delay m2p_override initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 m2p overrides are used to be able to find the local pfn for a
foreign mfn mapped into the domain. They are used by driver backends
having to access frontend data.

As this functionality isn't used in early boot it makes no sense to
initialize the m2p override functions very early. It can be done
later without doing any harm, removing the need for allocating memory
via extend_brk().

While at it make some m2p override functions static as they are only
used internally.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |   6 --
 arch/x86/xen/p2m.c              | 198 ++++++++++++++++++++--------------------
 2 files changed, 101 insertions(+), 103 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c29619c..b475297 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -51,15 +51,9 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 				   struct gnttab_map_grant_ref *kmap_ops,
 				   struct page **pages, unsigned int count);
-extern int m2p_add_override(unsigned long mfn, struct page *page,
-			    struct gnttab_map_grant_ref *kmap_op);
 extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct gnttab_map_grant_ref *kmap_ops,
 				     struct page **pages, unsigned int count);
-extern int m2p_remove_override(struct page *page,
-			       struct gnttab_map_grant_ref *kmap_op,
-			       unsigned long mfn);
-extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 49316ac..2647a65 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -426,8 +426,6 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		}
 		p2m_top[topidx][mididx] = &mfn_list[pfn];
 	}
-
-	m2p_override_init();
 }
 #ifdef CONFIG_X86_64
 unsigned long __init xen_revector_p2m_tree(void)
@@ -498,13 +496,15 @@ unsigned long __init xen_revector_p2m_tree(void)
 		}
 		/* This should be the leafs allocated for identity from _brk. */
 	}
-	return (unsigned long)mfn_list;
 
+	m2p_override_init();
+	return (unsigned long)mfn_list;
 }
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	m2p_override_init();
 	return 0;
 }
 #endif
@@ -794,15 +794,16 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 #define M2P_OVERRIDE_HASH_SHIFT	10
 #define M2P_OVERRIDE_HASH	(1 << M2P_OVERRIDE_HASH_SHIFT)
 
-static RESERVE_BRK_ARRAY(struct list_head, m2p_overrides, M2P_OVERRIDE_HASH);
+static struct list_head *m2p_overrides;
 static DEFINE_SPINLOCK(m2p_override_lock);
 
 static void __init m2p_override_init(void)
 {
 	unsigned i;
 
-	m2p_overrides = extend_brk(sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
-				   sizeof(unsigned long));
+	m2p_overrides = alloc_bootmem_align(
+				sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
+				sizeof(unsigned long));
 
 	for (i = 0; i < M2P_OVERRIDE_HASH; i++)
 		INIT_LIST_HEAD(&m2p_overrides[i]);
@@ -813,67 +814,8 @@ static unsigned long mfn_hash(unsigned long mfn)
 	return hash_long(mfn, M2P_OVERRIDE_HASH_SHIFT);
 }
 
-int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
-			    struct gnttab_map_grant_ref *kmap_ops,
-			    struct page **pages, unsigned int count)
-{
-	int i, ret = 0;
-	bool lazy = false;
-	pte_t *pte;
-
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return 0;
-
-	if (kmap_ops &&
-	    !in_interrupt() &&
-	    paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
-		arch_enter_lazy_mmu_mode();
-		lazy = true;
-	}
-
-	for (i = 0; i < count; i++) {
-		unsigned long mfn, pfn;
-
-		/* Do not add to override if the map failed. */
-		if (map_ops[i].status)
-			continue;
-
-		if (map_ops[i].flags & GNTMAP_contains_pte) {
-			pte = (pte_t *) (mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
-				(map_ops[i].host_addr & ~PAGE_MASK));
-			mfn = pte_mfn(*pte);
-		} else {
-			mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
-		}
-		pfn = page_to_pfn(pages[i]);
-
-		WARN_ON(PagePrivate(pages[i]));
-		SetPagePrivate(pages[i]);
-		set_page_private(pages[i], mfn);
-		pages[i]->index = pfn_to_mfn(pfn);
-
-		if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) {
-			ret = -ENOMEM;
-			goto out;
-		}
-
-		if (kmap_ops) {
-			ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]);
-			if (ret)
-				goto out;
-		}
-	}
-
-out:
-	if (lazy)
-		arch_leave_lazy_mmu_mode();
-
-	return ret;
-}
-EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
-
 /* Add an MFN override for a particular page */
-int m2p_add_override(unsigned long mfn, struct page *page,
+static int m2p_add_override(unsigned long mfn, struct page *page,
 		struct gnttab_map_grant_ref *kmap_op)
 {
 	unsigned long flags;
@@ -926,14 +868,14 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(m2p_add_override);
 
-int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
-			      struct gnttab_map_grant_ref *kmap_ops,
-			      struct page **pages, unsigned int count)
+int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
+			    struct gnttab_map_grant_ref *kmap_ops,
+			    struct page **pages, unsigned int count)
 {
 	int i, ret = 0;
 	bool lazy = false;
+	pte_t *pte;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return 0;
@@ -946,33 +888,74 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 	}
 
 	for (i = 0; i < count; i++) {
-		unsigned long mfn = get_phys_to_machine(page_to_pfn(pages[i]));
-		unsigned long pfn = page_to_pfn(pages[i]);
+		unsigned long mfn, pfn;
 
-		if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
-			ret = -EINVAL;
-			goto out;
+		/* Do not add to override if the map failed. */
+		if (map_ops[i].status)
+			continue;
+
+		if (map_ops[i].flags & GNTMAP_contains_pte) {
+			mfn = PFN_DOWN(map_ops[i].host_addr);
+			pte = (pte_t *)(mfn_to_virt(mfn) +
+				(map_ops[i].host_addr & ~PAGE_MASK));
+			mfn = pte_mfn(*pte);
+		} else {
+			mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
 		}
+		pfn = page_to_pfn(pages[i]);
 
-		set_page_private(pages[i], INVALID_P2M_ENTRY);
-		WARN_ON(!PagePrivate(pages[i]));
-		ClearPagePrivate(pages[i]);
-		set_phys_to_machine(pfn, pages[i]->index);
+		WARN_ON(PagePrivate(pages[i]));
+		SetPagePrivate(pages[i]);
+		set_page_private(pages[i], mfn);
+		pages[i]->index = pfn_to_mfn(pfn);
 
-		if (kmap_ops)
-			ret = m2p_remove_override(pages[i], &kmap_ops[i], mfn);
-		if (ret)
+		if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) {
+			ret = -ENOMEM;
 			goto out;
+		}
+
+		if (kmap_ops) {
+			ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]);
+			if (ret)
+				goto out;
+		}
 	}
 
 out:
 	if (lazy)
 		arch_leave_lazy_mmu_mode();
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
+
+static struct page *m2p_find_override(unsigned long mfn)
+{
+	unsigned long flags;
+	struct list_head *bucket;
+	struct page *p, *ret;
+
+	ret = NULL;
+
+	if (m2p_overrides) {
+		bucket = &m2p_overrides[mfn_hash(mfn)];
+
+		spin_lock_irqsave(&m2p_override_lock, flags);
+
+		list_for_each_entry(p, bucket, lru) {
+			if (page_private(p) == mfn) {
+				ret = p;
+				break;
+			}
+		}
+
+		spin_unlock_irqrestore(&m2p_override_lock, flags);
+	}
+
 	return ret;
 }
-EXPORT_SYMBOL_GPL(clear_foreign_p2m_mapping);
 
-int m2p_remove_override(struct page *page,
+static int m2p_remove_override(struct page *page,
 			struct gnttab_map_grant_ref *kmap_op,
 			unsigned long mfn)
 {
@@ -1068,29 +1051,50 @@ int m2p_remove_override(struct page *page,
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(m2p_remove_override);
 
-struct page *m2p_find_override(unsigned long mfn)
+int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
+			      struct gnttab_map_grant_ref *kmap_ops,
+			      struct page **pages, unsigned int count)
 {
-	unsigned long flags;
-	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
-	struct page *p, *ret;
+	int i, ret = 0;
+	bool lazy = false;
 
-	ret = NULL;
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
 
-	spin_lock_irqsave(&m2p_override_lock, flags);
+	if (kmap_ops &&
+	    !in_interrupt() &&
+	    paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+		arch_enter_lazy_mmu_mode();
+		lazy = true;
+	}
 
-	list_for_each_entry(p, bucket, lru) {
-		if (page_private(p) == mfn) {
-			ret = p;
-			break;
+	for (i = 0; i < count; i++) {
+		unsigned long mfn = get_phys_to_machine(page_to_pfn(pages[i]));
+		unsigned long pfn = page_to_pfn(pages[i]);
+
+		if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
+			ret = -EINVAL;
+			goto out;
 		}
-	}
 
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
+		set_page_private(pages[i], INVALID_P2M_ENTRY);
+		WARN_ON(!PagePrivate(pages[i]));
+		ClearPagePrivate(pages[i]);
+		set_phys_to_machine(pfn, pages[i]->index);
 
+		if (kmap_ops)
+			ret = m2p_remove_override(pages[i], &kmap_ops[i], mfn);
+		if (ret)
+			goto out;
+	}
+
+out:
+	if (lazy)
+		arch_leave_lazy_mmu_mode();
 	return ret;
 }
+EXPORT_SYMBOL_GPL(clear_foreign_p2m_mapping);
 
 unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
 {
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 09:06:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09:06:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmJ1K-0005aN-EQ; Thu, 06 Nov 2014 09:06:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmJ1I-0005aI-Kg
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 09:06:20 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	D0/60-25727-B0A3B545; Thu, 06 Nov 2014 09:06:19 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415264775!10786107!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27459 invoked from network); 6 Nov 2014 09:06:16 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-31.messagelabs.com with SMTP;
	6 Nov 2014 09:06:16 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 06 Nov 2014 01:06:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,324,1413270000"; d="scan'208";a="627535477"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga002.fm.intel.com with ESMTP; 06 Nov 2014 01:05:35 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 17:03:56 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id
	14.03.0195.001; Thu, 6 Nov 2014 17:03:55 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP91zOKlhH4xypD06jTqC2+4O7eZxTR+ug
Date: Thu, 6 Nov 2014 09:03:55 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8206C2@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Monday, November 03, 2014 7:54 PM
> To: Xu, Quan
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> stefano.stabellini@eu.citrix.com
> Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> On Sun, 2 Nov 2014, Quan Xu wrote:
> > This drvier transfers any request/repond between TPM xenstubdoms
> > driver and Xen vTPM stubdom, and facilitates communications between
> > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> 
> Please describe what changes did make to xen_backend.c and why.
> The commit message should contains info on all the changes made by the
> patch below.
> 

The following is code process when Qemu is running with Xen. 
##code process
[...]
 xen_hvm_init()
    -->xen_be_register()
        -->xenstore_scan()
            -->xen_be_check_state()

    -->xen_vtpm_register()

ideally, I can register 'vtpm' via xen_vtpm_register() as

+ xen_be_register("console", &xen_console_ops);
+ xen_be_register("vkbd", &xen_kbdmouse_ops);
+ xen_be_register("qdisk", &xen_blkdev_ops);

but there are 2 reasons why I add xen_vtpm_register(), instead
of xen_be_register().

1. The backend of TPM is runing in a Xen stubDom, not Domain 0.
some functions are not working, for example 'setup watch' and
'look for backend' in xenstore_scan()

2. there is a thread runing in Xen stubDom [event_thread()], it will
handle backend status when the frontend is initialized. It is not
compatible with xen_be_check_state(). xen_be_check_state() always tries 
to modify the status of backend. 

as there is always a tradeoff, if I force to integrate this case into
xen_be_register(), there are maybe a lot of 'if ... else.. '. It will
break the code architecture. Also I should leverage existing source
code with minimum modifcation. i add 'DEVOPS_FLAG_STUBDOM_BE' flag in
include/hw/xen/xen_backend.h to indicate that device backend is Xen
stubDom.


> Please also describe what is the "Xen vTPM stubdom", what is the
> "vTPM xenstubdoms driver" and how the communicate with each others.
> 
In previous email, I have explained what is "Xen vTPM stubdom", what is the 
" vTPM xenstubdoms driver ". 

Let me describe how the communicate with each others.

            |        |  ^       |
            |        v  |       |
            |        vTPM      |
            | XenStubdoms driver |  (new ..)
            +-----------------------------+
                     |  ^
                     v  |
            +-----------------------------+
            |  xen_vtpmdev_ops |  (new ..)
            +-----------------------------+

xen_vtpmdev_ops is initialized with the following process:
 xen_hvm_init()
    [...]
    -->xen_vtpm_register()
      [...]
        --> vtpm_alloc()
        --> vtpm_initialise()

## 
vTPM XenStubdoms driver is initialized by Qemu command line options,
        "-tpmdev xenstubdoms,id=xenvtpm0 -device tpm-tis,tpmdev=xenvtpm0"


(the communicate with each others in following function.
.. hw/tpm/tpm_xenstubdoms.c
static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
{
[...]
    xen_vtpm_send(locty_data->w_buffer.buffer, locty_data->w_offset);
    xen_vtpm_recv(locty_data->r_buffer.buffer, &rlen);
[...]
} 


> Where does the vTPM backend lives?

Xen stubDom. 


> 
> 
> >  hw/xen/Makefile.objs         |   1 +
> >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> >  hw/xen/xen_stubdom_vtpm.c    | 333
> +++++++++++++++++++++++++++++++++++++++++++
> >  include/hw/xen/xen_backend.h |  11 ++
> >  include/hw/xen/xen_common.h  |   6 +
> >  xen-hvm.c                    |  13 ++
> >  6 files changed, 544 insertions(+), 2 deletions(-)
> >  create mode 100644 hw/xen/xen_stubdom_vtpm.c
> >
> > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> > index a0ca0aa..724df8d 100644
> > --- a/hw/xen/Makefile.objs
> > +++ b/hw/xen/Makefile.objs
> > @@ -1,5 +1,6 @@
> >  # xen backend driver support
> >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> xen_devconfig.o
> > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> >
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> xen_pt_config_init.o xen_pt_msi.o
> > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> > index b2cb22b..45a5778 100644
> > --- a/hw/xen/xen_backend.c
> > +++ b/hw/xen/xen_backend.c
> > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev,
> enum xenbus_state state)
> >      return 0;
> >  }
> >
> > +/*get stubdom backend*/
> > +static char *xen_stubdom_be(const char *type, int dom, int dev)
> > +{
> > +    char *val, *domu;
> > +    char path[XEN_BUFSIZE];
> > +    unsigned int len, ival;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, dom);
> > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > +             domu, type, dev);
> > +    g_free(domu);
> > +
> > +    val = xs_read(xenstore, 0, path, &len);
> > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > +        g_free(val);
> > +        return NULL;
> > +    }
> > +    g_free(val);
> > +
> > +    /*backend domu*/
> > +    domu = xs_get_domain_path(xenstore, ival);
> > +
> > +    return domu;
> > +}
> > +
> >  /* ------------------------------------------------------------- */
> >
> >  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int
> dev)
> > @@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const
> char *type, int dom, int dev,
> >                                             struct XenDevOps *ops)
> >  {
> >      struct XenDevice *xendev;
> > +    char *stub;
> >
> >      xendev = xen_be_find_xendev(type, dom, dev);
> >      if (xendev) {
> > @@ -235,8 +262,15 @@ static struct XenDevice
> *xen_be_get_xendev(const char *type, int dom, int dev,
> >      xendev->dev   = dev;
> >      xendev->ops   = ops;
> >
> > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > -             xendev->type, xendev->dom, xendev->dev);
> > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> xendev->dev);
> > +        snprintf(xendev->be, sizeof(xendev->be),
> "%s/backend/%s/%d/%d",
> > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > +        g_free(stub);
> > +    } else {
> > +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > +                 xendev->type, xendev->dom, xendev->dev);
> > +    }
> >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> >               xendev->type, xendev->dev);
> >
> > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int
> dom, struct XenDevOps *ops)
> >      return 0;
> >  }
> >
> > +static void stubdom_update_be(char *watch, char *type, int dom,
> > +                              struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE];
> > +    char *ptr, *bepath;
> > +    unsigned int len, dev;
> > +
> > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > +        return;
> > +    }
> > +
> > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > +    ptr = strstr(watch, path);
> > +    if (ptr == NULL) {
> > +        return;
> > +    }
> > +
> > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > +        strcpy(path, "");
> > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > +            dev = -1;
> > +        }
> > +    }
> > +
> > +    if (dev == -1) {
> > +        return;
> > +    }
> > +
> > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > +    if (xendev != NULL) {
> > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > +        if (bepath == NULL) {
> > +            xen_be_del_xendev(dom, dev);
> > +        } else {
> > +            free(bepath);
> > +            xen_be_backend_changed(xendev, path);
> > +        }
> > +    }
> > +}
> > +
> >  static void xenstore_update_be(char *watch, char *type, int dom,
> >                                 struct XenDevOps *ops)
> >  {
> > @@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
> >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> >      }
> > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> PRIxPTR,
> > +               &type, &dom, &ops) == 3) {
> > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom,
> (void *)ops);
> > +    }
> >
> >  cleanup:
> >      free(vec);
> > @@ -732,11 +811,74 @@ err:
> >      return -1;
> >  }
> >
> > +int xen_vtpm_register(struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > +    char *domu;
> > +    unsigned int cdev, j, rc;
> > +    const char *type = "vtpm";
> > +    char **dev = NULL;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > +    snprintf(path, sizeof(path), "%s/device/%s",
> > +             domu, type);
> > +    free(domu);
> > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > +    if (dev == NULL) {
> > +        return 0;
> > +    }
> > +
> > +    for (j = 0; j < cdev; j++) {
> > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> ops);
> > +        if (xendev == NULL) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> NULL.\n");
> > +            continue;
> > +        }
> > +
> > +        if (xendev->ops->initialise) {
> > +            rc = xendev->ops->initialise(xendev);
> > +
> > +            /*if initialise failed, delete it*/
> > +            if (rc != 0) {
> > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > +                continue;
> > +            }
> > +        }
> > +
> > +        /*setup watch*/
> > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > +                 type, xen_domid, xendev->ops);
> > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> failed.\n");
> > +            return -1;
> > +        }
> > +    }
> > +
> > +    free(dev);
> > +    return 0;
> > +}
> 
> What does this function do? I sholdn't need  to guess from the code, I
> should be able to tell from the patch description.
> 

1. setup watch
2. look for backends
3. initialize the frontend

> 
> >  int xen_be_register(const char *type, struct XenDevOps *ops)
> >  {
> >      return xenstore_scan(type, xen_domid, ops);
> >  }
> >
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom)
> > +{
> > +    xendev->local_port =
> xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > +
> remote_dom);
> > +    if (xendev->local_port == -1) {
> > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> > +        return -1;
> > +    }
> > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> xendev->local_port);
> > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > +                        xen_be_evtchn_event, NULL, xendev);
> > +    return 0;
> > +}
> > +
> >  int xen_be_bind_evtchn(struct XenDevice *xendev)
> >  {
> >      if (xendev->local_port != -1) {
> > @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice
> *xendev)
> >      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
> >  }
> >
> > +int xen_vtpm_send(unsigned char *buf, size_t count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->send) {
> > +        rc = xendev->ops->send(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> > +
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->recv) {
> > +        xendev->ops->recv(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> 
> xen_backend.c is supposed to be generic, so stubdom functions might be
> OK but vtpm specific functions should not be here.
> 


OK, I will move it to hw/tpm. 

> 
> >  /*
> >   * msg_level:
> >   *  0 == errors (stderr + logfile).
> > diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> > new file mode 100644
> > index 0000000..0d740c1
> > --- /dev/null
> > +++ b/hw/xen/xen_stubdom_vtpm.c
> > @@ -0,0 +1,333 @@
> > +/*
> > + * Connect to Xen vTPM stubdom domain
> > + *
> > + *  Copyright (c) 2014 Intel Corporation
> > + *  Authors:
> > + *    Quan Xu <quan.xu@intel.com>
> > + *
> > + * 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 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, see
> <http://www.gnu.org/licenses/>
> > + */
> > +
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <stdarg.h>
> > +#include <string.h>
> > +#include <unistd.h>
> > +#include <signal.h>
> > +#include <inttypes.h>
> > +#include <time.h>
> > +#include <fcntl.h>
> > +#include <errno.h>
> > +#include <sys/ioctl.h>
> > +#include <sys/types.h>
> > +#include <sys/stat.h>
> > +#include <sys/mman.h>
> > +#include <sys/uio.h>
> > +
> > +#include "hw/hw.h"
> > +#include "block/aio.h"
> > +#include "hw/xen/xen_backend.h"
> > +
> > +enum tpmif_state {
> > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> complete */
> > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> > +};
> > +
> > +static AioContext *vtpm_aio_ctx;
> > +
> > +enum status_bits {
> > +    VTPM_STATUS_RUNNING  = 0x1,
> > +    VTPM_STATUS_IDLE     = 0x2,
> > +    VTPM_STATUS_RESULT   = 0x4,
> > +    VTPM_STATUS_CANCELED = 0x8,
> > +};
> > +
> > +struct tpmif_shared_page {
> > +    uint32_t length;         /* request/response length in bytes */
> > +
> > +    uint8_t  state;           /* enum tpmif_state */
> > +    uint8_t  locality;        /* for the current request */
> > +    uint8_t  pad;             /* should be zero */
> > +
> > +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be
> zero */
> > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> nr_extra_pages */
> > +};
> > +
> > +struct QEMUBH {
> > +    AioContext *ctx;
> > +    QEMUBHFunc *cb;
> > +    void *opaque;
> > +    QEMUBH *next;
> > +    bool scheduled;
> > +    bool idle;
> > +    bool deleted;
> > +};
> > +
> > +struct XenVtpmDev {
> > +    struct XenDevice xendev;  /* must be first */
> > +    struct           tpmif_shared_page *shr;
> > +    xc_gntshr        *xen_xcs;
> > +    int              ring_ref;
> > +    int              bedomid;
> > +    QEMUBH           *sr_bh;
> > +};
> > +
> > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> > +{
> > +    switch (vtpmdev->shr->state) {
> > +    case TPMIF_STATE_IDLE:
> > +    case TPMIF_STATE_FINISH:
> > +        return VTPM_STATUS_IDLE;
> > +    case TPMIF_STATE_SUBMIT:
> > +    case TPMIF_STATE_CANCEL:
> > +        return VTPM_STATUS_RUNNING;
> > +    default:
> > +        return 0;
> > +    }
> > +}
> > +
> > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> xenbus_state xbus)
> > +{
> > +    xs_transaction_t xbt = XBT_NULL;
> > +
> > +    if (xendev->fe_state == xbus) {
> > +        return 0;
> > +    }
> > +
> > +    xendev->fe_state = xbus;
> > +
> > +retry_transaction:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto retry_transaction;
> > +        }
> > +    }
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static int vtpm_aio_wait(QEMUBH *qbh)
> > +{
> > +    return aio_poll(qbh->ctx, true);
> > +}
> > +
> > +static void sr_bh_handler(void *opaque)
> > +{
> > +}
> > +
> > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t
> *count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset;
> > +
> > +    if (shr->state == TPMIF_STATE_IDLE) {
> > +        return -ECANCELED;
> > +    }
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > +    *count = shr->length;
> > +
> > +    return 0;
> > +}
> > +
> > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t
> count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > +    shr->length = count;
> > +    barrier();
> > +    shr->state = TPMIF_STATE_SUBMIT;
> > +    xen_wmb();
> > +    xen_be_send_notify(&vtpmdev->xendev);
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    return count;
> > +}
> > +
> > +static int vtpm_initialise(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    xs_transaction_t xbt = XBT_NULL;
> > +    unsigned int ring_ref;
> > +
> > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> "frontend");
> > +    if (vtpmdev->xendev.fe == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /* Get backend domid */
> > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > +                             &vtpmdev->bedomid)) {
> > +        return -1;
> > +    }
> > +
> > +    /*alloc share page*/
> > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> vtpmdev->bedomid, 1,
> > +                                         &ring_ref,
> PROT_READ|PROT_WRITE);
> > +    vtpmdev->ring_ref = ring_ref;
> > +    if (vtpmdev->shr == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /*Create event channel */
> > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> vtpmdev->bedomid)) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +        return -1;
> > +    }
> > +
> > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > +                     vtpmdev->xendev.local_port);
> > +
> > +again:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > +                           vtpmdev->ring_ref)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > +                           vtpmdev->xendev.local_port)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    /* Publish protocol v2 feature */
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1))
> {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto again;
> > +        }
> > +    }
> > +    /* Tell vtpm backend that we are ready */
> > +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static void vtpm_backend_changed(struct XenDevice *xendev, const char
> *node)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    int be_state;
> > +
> > +    if (strcmp(node, "state") == 0) {
> > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > +        switch (be_state) {
> > +        case XenbusStateConnected:
> > +            /*TODO*/
> > +            break;
> > +        case XenbusStateClosing:
> > +        case XenbusStateClosed:
> > +            xenbus_switch_state(&vtpmdev->xendev,
> XenbusStateClosing);
> > +            break;
> > +        default:
> > +            break;
> > +        }
> > +    }
> > +}
> > +
> > +static int vtpm_free(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > +
> > +    aio_poll(qbh->ctx, false);
> > +    qemu_bh_delete(vtpmdev->sr_bh);
> > +    if (vtpmdev->shr) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    }
> > +    xc_interface_close(vtpmdev->xen_xcs);
> > +    return 0;
> > +}
> > +
> > +static void vtpm_alloc(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    vtpm_aio_ctx = aio_context_new(NULL);
> > +    if (vtpm_aio_ctx == NULL) {
> > +        return;
> > +    }
> > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> vtpmdev);
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> > +}
> > +
> > +static void vtpm_event(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +}
> > +
> > +struct XenDevOps xen_vtpmdev_ops = {
> > +    .size             = sizeof(struct XenVtpmDev),
> > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > +                        DEVOPS_FLAG_STUBDOM_BE,
> > +    .event            = vtpm_event,
> > +    .free             = vtpm_free,
> > +    .alloc            = vtpm_alloc,
> > +    .initialise       = vtpm_initialise,
> > +    .backend_changed  = vtpm_backend_changed,
> > +    .recv             = vtpm_recv,
> > +    .send             = vtpm_send,
> > +};
> 
> Is this the frontend, like the subject line would seem to imply?
> If so, XenDevOps are made for backends, while this is a frontend. In
> fact this is the first PV frontend in QEMU. We need to introduce
> something generic and similar to struct XenDevOps and xen_backend.c but
> for frontends.
> 
> 
> > diff --git a/include/hw/xen/xen_backend.h
> b/include/hw/xen/xen_backend.h
> > index 3b4125e..45fd6d3 100644
> > --- a/include/hw/xen/xen_backend.h
> > +++ b/include/hw/xen/xen_backend.h
> > @@ -15,6 +15,8 @@ struct XenDevice;
> >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> >  /* don't expect frontend doing correct state transitions (aka console
> quirk) */
> >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > +/*dev backend is stubdom*/
> > +#define DEVOPS_FLAG_STUBDOM_BE    4
> >
> >  struct XenDevOps {
> >      size_t    size;
> > @@ -26,6 +28,8 @@ struct XenDevOps {
> >      void      (*event)(struct XenDevice *xendev);
> >      void      (*disconnect)(struct XenDevice *xendev);
> >      int       (*free)(struct XenDevice *xendev);
> > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> count);
> > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> *count);
> >      void      (*backend_changed)(struct XenDevice *xendev, const
> char *node);
> >      void      (*frontend_changed)(struct XenDevice *xendev, const
> char *node);
> >  };
> > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> *xendev);
> >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char
> *fmt, ...)
> >      GCC_FMT_ATTR(3, 4);
> >
> > +/*Xen stubdom vtpm*/
> > +int xen_vtpm_register(struct XenDevOps *ops);
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom);
> > +int xen_vtpm_send(unsigned char *buf, size_t count);
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> > +
> >  /* actual backend drivers */
> >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> */
> >  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c
> */
> >  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
> >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> */
> >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> */
> > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> xen_stubdom_vtpm.c*/
> >
> >  void xen_init_display(int domid);
> >
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 95612a4..fb43084 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void
> *logger, void *dombuild_logger,
> >      return xc_interface_open(logger, dombuild_logger, open_flags);
> >  }
> >
> > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > +                                           unsigned int open_flags)
> > +{
> > +    return xc_gntshr_open(logger, open_flags);
> > +}
> > +
> >  /* FIXME There is now way to have the xen fd */
> >  static inline int xc_fd(xc_interface *xen_xc)
> >  {
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 21f1cbb..c99ace8 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >      int i, rc;
> >      unsigned long ioreq_pfn;
> >      unsigned long bufioreq_evtchn;
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    unsigned long stubdom_vtpm = 0;
> > +#endif
> > +
> >      XenIOState *state;
> >
> >      state = g_malloc0(sizeof (XenIOState));
> > @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >          fprintf(stderr, "%s: xen backend core setup failed\n",
> __FUNCTION__);
> >          return -1;
> >      }
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    xc_get_hvm_param(xen_xc, xen_domid,
> HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > +    if (stubdom_vtpm) {
> > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > +    }
> > +#endif
> 
> Given that vtpm is just a PV frontend, can't you just detect whether is
> present on xenstore and initialize it based on that? Like all the
> backend below?

Refer to above explanation. 

Thanks 
Quan 

> 
> 
> >      xen_be_register("console", &xen_console_ops);
> >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> >      xen_be_register("qdisk", &xen_blkdev_ops);
> > --
> > 1.8.3.2
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 09:06:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09:06:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmJ1K-0005aN-EQ; Thu, 06 Nov 2014 09:06:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmJ1I-0005aI-Kg
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 09:06:20 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	D0/60-25727-B0A3B545; Thu, 06 Nov 2014 09:06:19 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415264775!10786107!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27459 invoked from network); 6 Nov 2014 09:06:16 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-31.messagelabs.com with SMTP;
	6 Nov 2014 09:06:16 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 06 Nov 2014 01:06:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,324,1413270000"; d="scan'208";a="627535477"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga002.fm.intel.com with ESMTP; 06 Nov 2014 01:05:35 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 17:03:56 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id
	14.03.0195.001; Thu, 6 Nov 2014 17:03:55 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP91zOKlhH4xypD06jTqC2+4O7eZxTR+ug
Date: Thu, 6 Nov 2014 09:03:55 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8206C2@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Monday, November 03, 2014 7:54 PM
> To: Xu, Quan
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> stefano.stabellini@eu.citrix.com
> Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> On Sun, 2 Nov 2014, Quan Xu wrote:
> > This drvier transfers any request/repond between TPM xenstubdoms
> > driver and Xen vTPM stubdom, and facilitates communications between
> > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> 
> Please describe what changes did make to xen_backend.c and why.
> The commit message should contains info on all the changes made by the
> patch below.
> 

The following is code process when Qemu is running with Xen. 
##code process
[...]
 xen_hvm_init()
    -->xen_be_register()
        -->xenstore_scan()
            -->xen_be_check_state()

    -->xen_vtpm_register()

ideally, I can register 'vtpm' via xen_vtpm_register() as

+ xen_be_register("console", &xen_console_ops);
+ xen_be_register("vkbd", &xen_kbdmouse_ops);
+ xen_be_register("qdisk", &xen_blkdev_ops);

but there are 2 reasons why I add xen_vtpm_register(), instead
of xen_be_register().

1. The backend of TPM is runing in a Xen stubDom, not Domain 0.
some functions are not working, for example 'setup watch' and
'look for backend' in xenstore_scan()

2. there is a thread runing in Xen stubDom [event_thread()], it will
handle backend status when the frontend is initialized. It is not
compatible with xen_be_check_state(). xen_be_check_state() always tries 
to modify the status of backend. 

as there is always a tradeoff, if I force to integrate this case into
xen_be_register(), there are maybe a lot of 'if ... else.. '. It will
break the code architecture. Also I should leverage existing source
code with minimum modifcation. i add 'DEVOPS_FLAG_STUBDOM_BE' flag in
include/hw/xen/xen_backend.h to indicate that device backend is Xen
stubDom.


> Please also describe what is the "Xen vTPM stubdom", what is the
> "vTPM xenstubdoms driver" and how the communicate with each others.
> 
In previous email, I have explained what is "Xen vTPM stubdom", what is the 
" vTPM xenstubdoms driver ". 

Let me describe how the communicate with each others.

            |        |  ^       |
            |        v  |       |
            |        vTPM      |
            | XenStubdoms driver |  (new ..)
            +-----------------------------+
                     |  ^
                     v  |
            +-----------------------------+
            |  xen_vtpmdev_ops |  (new ..)
            +-----------------------------+

xen_vtpmdev_ops is initialized with the following process:
 xen_hvm_init()
    [...]
    -->xen_vtpm_register()
      [...]
        --> vtpm_alloc()
        --> vtpm_initialise()

## 
vTPM XenStubdoms driver is initialized by Qemu command line options,
        "-tpmdev xenstubdoms,id=xenvtpm0 -device tpm-tis,tpmdev=xenvtpm0"


(the communicate with each others in following function.
.. hw/tpm/tpm_xenstubdoms.c
static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
{
[...]
    xen_vtpm_send(locty_data->w_buffer.buffer, locty_data->w_offset);
    xen_vtpm_recv(locty_data->r_buffer.buffer, &rlen);
[...]
} 


> Where does the vTPM backend lives?

Xen stubDom. 


> 
> 
> >  hw/xen/Makefile.objs         |   1 +
> >  hw/xen/xen_backend.c         | 182 ++++++++++++++++++++++-
> >  hw/xen/xen_stubdom_vtpm.c    | 333
> +++++++++++++++++++++++++++++++++++++++++++
> >  include/hw/xen/xen_backend.h |  11 ++
> >  include/hw/xen/xen_common.h  |   6 +
> >  xen-hvm.c                    |  13 ++
> >  6 files changed, 544 insertions(+), 2 deletions(-)
> >  create mode 100644 hw/xen/xen_stubdom_vtpm.c
> >
> > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> > index a0ca0aa..724df8d 100644
> > --- a/hw/xen/Makefile.objs
> > +++ b/hw/xen/Makefile.objs
> > @@ -1,5 +1,6 @@
> >  # xen backend driver support
> >  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o
> xen_devconfig.o
> > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> >
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
> xen_pt_config_init.o xen_pt_msi.o
> > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> > index b2cb22b..45a5778 100644
> > --- a/hw/xen/xen_backend.c
> > +++ b/hw/xen/xen_backend.c
> > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev,
> enum xenbus_state state)
> >      return 0;
> >  }
> >
> > +/*get stubdom backend*/
> > +static char *xen_stubdom_be(const char *type, int dom, int dev)
> > +{
> > +    char *val, *domu;
> > +    char path[XEN_BUFSIZE];
> > +    unsigned int len, ival;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, dom);
> > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > +             domu, type, dev);
> > +    g_free(domu);
> > +
> > +    val = xs_read(xenstore, 0, path, &len);
> > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > +        g_free(val);
> > +        return NULL;
> > +    }
> > +    g_free(val);
> > +
> > +    /*backend domu*/
> > +    domu = xs_get_domain_path(xenstore, ival);
> > +
> > +    return domu;
> > +}
> > +
> >  /* ------------------------------------------------------------- */
> >
> >  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int
> dev)
> > @@ -222,6 +248,7 @@ static struct XenDevice *xen_be_get_xendev(const
> char *type, int dom, int dev,
> >                                             struct XenDevOps *ops)
> >  {
> >      struct XenDevice *xendev;
> > +    char *stub;
> >
> >      xendev = xen_be_find_xendev(type, dom, dev);
> >      if (xendev) {
> > @@ -235,8 +262,15 @@ static struct XenDevice
> *xen_be_get_xendev(const char *type, int dom, int dev,
> >      xendev->dev   = dev;
> >      xendev->ops   = ops;
> >
> > -    snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > -             xendev->type, xendev->dom, xendev->dev);
> > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> xendev->dev);
> > +        snprintf(xendev->be, sizeof(xendev->be),
> "%s/backend/%s/%d/%d",
> > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > +        g_free(stub);
> > +    } else {
> > +        snprintf(xendev->be, sizeof(xendev->be), "backend/%s/%d/%d",
> > +                 xendev->type, xendev->dom, xendev->dev);
> > +    }
> >      snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> >               xendev->type, xendev->dev);
> >
> > @@ -611,6 +645,47 @@ static int xenstore_scan(const char *type, int
> dom, struct XenDevOps *ops)
> >      return 0;
> >  }
> >
> > +static void stubdom_update_be(char *watch, char *type, int dom,
> > +                              struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE];
> > +    char *ptr, *bepath;
> > +    unsigned int len, dev;
> > +
> > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > +        return;
> > +    }
> > +
> > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > +    ptr = strstr(watch, path);
> > +    if (ptr == NULL) {
> > +        return;
> > +    }
> > +
> > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > +        strcpy(path, "");
> > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > +            dev = -1;
> > +        }
> > +    }
> > +
> > +    if (dev == -1) {
> > +        return;
> > +    }
> > +
> > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > +    if (xendev != NULL) {
> > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > +        if (bepath == NULL) {
> > +            xen_be_del_xendev(dom, dev);
> > +        } else {
> > +            free(bepath);
> > +            xen_be_backend_changed(xendev, path);
> > +        }
> > +    }
> > +}
> > +
> >  static void xenstore_update_be(char *watch, char *type, int dom,
> >                                 struct XenDevOps *ops)
> >  {
> > @@ -681,6 +756,10 @@ static void xenstore_update(void *unused)
> >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> >      }
> > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> PRIxPTR,
> > +               &type, &dom, &ops) == 3) {
> > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom,
> (void *)ops);
> > +    }
> >
> >  cleanup:
> >      free(vec);
> > @@ -732,11 +811,74 @@ err:
> >      return -1;
> >  }
> >
> > +int xen_vtpm_register(struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > +    char *domu;
> > +    unsigned int cdev, j, rc;
> > +    const char *type = "vtpm";
> > +    char **dev = NULL;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, xen_domid);
> > +    snprintf(path, sizeof(path), "%s/device/%s",
> > +             domu, type);
> > +    free(domu);
> > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > +    if (dev == NULL) {
> > +        return 0;
> > +    }
> > +
> > +    for (j = 0; j < cdev; j++) {
> > +        xendev = xen_be_get_xendev(type, xen_domid, atoi(dev[j]),
> ops);
> > +        if (xendev == NULL) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xendev is
> NULL.\n");
> > +            continue;
> > +        }
> > +
> > +        if (xendev->ops->initialise) {
> > +            rc = xendev->ops->initialise(xendev);
> > +
> > +            /*if initialise failed, delete it*/
> > +            if (rc != 0) {
> > +                xen_be_del_xendev(xen_domid, atoi(dev[j]));
> > +                continue;
> > +            }
> > +        }
> > +
> > +        /*setup watch*/
> > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > +                 type, xen_domid, xendev->ops);
> > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > +            xen_be_printf(xendev, 0, "xen_vtpm_register xs_watch
> failed.\n");
> > +            return -1;
> > +        }
> > +    }
> > +
> > +    free(dev);
> > +    return 0;
> > +}
> 
> What does this function do? I sholdn't need  to guess from the code, I
> should be able to tell from the patch description.
> 

1. setup watch
2. look for backends
3. initialize the frontend

> 
> >  int xen_be_register(const char *type, struct XenDevOps *ops)
> >  {
> >      return xenstore_scan(type, xen_domid, ops);
> >  }
> >
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom)
> > +{
> > +    xendev->local_port =
> xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > +
> remote_dom);
> > +    if (xendev->local_port == -1) {
> > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> > +        return -1;
> > +    }
> > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> xendev->local_port);
> > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > +                        xen_be_evtchn_event, NULL, xendev);
> > +    return 0;
> > +}
> > +
> >  int xen_be_bind_evtchn(struct XenDevice *xendev)
> >  {
> >      if (xendev->local_port != -1) {
> > @@ -770,6 +912,42 @@ int xen_be_send_notify(struct XenDevice
> *xendev)
> >      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
> >  }
> >
> > +int xen_vtpm_send(unsigned char *buf, size_t count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->send) {
> > +        rc = xendev->ops->send(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> > +
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->recv) {
> > +        xendev->ops->recv(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> 
> xen_backend.c is supposed to be generic, so stubdom functions might be
> OK but vtpm specific functions should not be here.
> 


OK, I will move it to hw/tpm. 

> 
> >  /*
> >   * msg_level:
> >   *  0 == errors (stderr + logfile).
> > diff --git a/hw/xen/xen_stubdom_vtpm.c b/hw/xen/xen_stubdom_vtpm.c
> > new file mode 100644
> > index 0000000..0d740c1
> > --- /dev/null
> > +++ b/hw/xen/xen_stubdom_vtpm.c
> > @@ -0,0 +1,333 @@
> > +/*
> > + * Connect to Xen vTPM stubdom domain
> > + *
> > + *  Copyright (c) 2014 Intel Corporation
> > + *  Authors:
> > + *    Quan Xu <quan.xu@intel.com>
> > + *
> > + * 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 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, see
> <http://www.gnu.org/licenses/>
> > + */
> > +
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <stdarg.h>
> > +#include <string.h>
> > +#include <unistd.h>
> > +#include <signal.h>
> > +#include <inttypes.h>
> > +#include <time.h>
> > +#include <fcntl.h>
> > +#include <errno.h>
> > +#include <sys/ioctl.h>
> > +#include <sys/types.h>
> > +#include <sys/stat.h>
> > +#include <sys/mman.h>
> > +#include <sys/uio.h>
> > +
> > +#include "hw/hw.h"
> > +#include "block/aio.h"
> > +#include "hw/xen/xen_backend.h"
> > +
> > +enum tpmif_state {
> > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> complete */
> > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> > +};
> > +
> > +static AioContext *vtpm_aio_ctx;
> > +
> > +enum status_bits {
> > +    VTPM_STATUS_RUNNING  = 0x1,
> > +    VTPM_STATUS_IDLE     = 0x2,
> > +    VTPM_STATUS_RESULT   = 0x4,
> > +    VTPM_STATUS_CANCELED = 0x8,
> > +};
> > +
> > +struct tpmif_shared_page {
> > +    uint32_t length;         /* request/response length in bytes */
> > +
> > +    uint8_t  state;           /* enum tpmif_state */
> > +    uint8_t  locality;        /* for the current request */
> > +    uint8_t  pad;             /* should be zero */
> > +
> > +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be
> zero */
> > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> nr_extra_pages */
> > +};
> > +
> > +struct QEMUBH {
> > +    AioContext *ctx;
> > +    QEMUBHFunc *cb;
> > +    void *opaque;
> > +    QEMUBH *next;
> > +    bool scheduled;
> > +    bool idle;
> > +    bool deleted;
> > +};
> > +
> > +struct XenVtpmDev {
> > +    struct XenDevice xendev;  /* must be first */
> > +    struct           tpmif_shared_page *shr;
> > +    xc_gntshr        *xen_xcs;
> > +    int              ring_ref;
> > +    int              bedomid;
> > +    QEMUBH           *sr_bh;
> > +};
> > +
> > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> > +{
> > +    switch (vtpmdev->shr->state) {
> > +    case TPMIF_STATE_IDLE:
> > +    case TPMIF_STATE_FINISH:
> > +        return VTPM_STATUS_IDLE;
> > +    case TPMIF_STATE_SUBMIT:
> > +    case TPMIF_STATE_CANCEL:
> > +        return VTPM_STATUS_RUNNING;
> > +    default:
> > +        return 0;
> > +    }
> > +}
> > +
> > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> xenbus_state xbus)
> > +{
> > +    xs_transaction_t xbt = XBT_NULL;
> > +
> > +    if (xendev->fe_state == xbus) {
> > +        return 0;
> > +    }
> > +
> > +    xendev->fe_state = xbus;
> > +
> > +retry_transaction:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto retry_transaction;
> > +        }
> > +    }
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static int vtpm_aio_wait(QEMUBH *qbh)
> > +{
> > +    return aio_poll(qbh->ctx, true);
> > +}
> > +
> > +static void sr_bh_handler(void *opaque)
> > +{
> > +}
> > +
> > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t
> *count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset;
> > +
> > +    if (shr->state == TPMIF_STATE_IDLE) {
> > +        return -ECANCELED;
> > +    }
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > +    *count = shr->length;
> > +
> > +    return 0;
> > +}
> > +
> > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t
> count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > +    shr->length = count;
> > +    barrier();
> > +    shr->state = TPMIF_STATE_SUBMIT;
> > +    xen_wmb();
> > +    xen_be_send_notify(&vtpmdev->xendev);
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpmdev->sr_bh);
> > +    }
> > +
> > +    return count;
> > +}
> > +
> > +static int vtpm_initialise(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    xs_transaction_t xbt = XBT_NULL;
> > +    unsigned int ring_ref;
> > +
> > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> "frontend");
> > +    if (vtpmdev->xendev.fe == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /* Get backend domid */
> > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > +                             &vtpmdev->bedomid)) {
> > +        return -1;
> > +    }
> > +
> > +    /*alloc share page*/
> > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> vtpmdev->bedomid, 1,
> > +                                         &ring_ref,
> PROT_READ|PROT_WRITE);
> > +    vtpmdev->ring_ref = ring_ref;
> > +    if (vtpmdev->shr == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /*Create event channel */
> > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> vtpmdev->bedomid)) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +        return -1;
> > +    }
> > +
> > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > +                     vtpmdev->xendev.local_port);
> > +
> > +again:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > +                           vtpmdev->ring_ref)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > +                           vtpmdev->xendev.local_port)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    /* Publish protocol v2 feature */
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1))
> {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto again;
> > +        }
> > +    }
> > +    /* Tell vtpm backend that we are ready */
> > +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static void vtpm_backend_changed(struct XenDevice *xendev, const char
> *node)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    int be_state;
> > +
> > +    if (strcmp(node, "state") == 0) {
> > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > +        switch (be_state) {
> > +        case XenbusStateConnected:
> > +            /*TODO*/
> > +            break;
> > +        case XenbusStateClosing:
> > +        case XenbusStateClosed:
> > +            xenbus_switch_state(&vtpmdev->xendev,
> XenbusStateClosing);
> > +            break;
> > +        default:
> > +            break;
> > +        }
> > +    }
> > +}
> > +
> > +static int vtpm_free(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    QEMUBH *qbh = vtpmdev->sr_bh;
> > +
> > +    aio_poll(qbh->ctx, false);
> > +    qemu_bh_delete(vtpmdev->sr_bh);
> > +    if (vtpmdev->shr) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    }
> > +    xc_interface_close(vtpmdev->xen_xcs);
> > +    return 0;
> > +}
> > +
> > +static void vtpm_alloc(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    vtpm_aio_ctx = aio_context_new(NULL);
> > +    if (vtpm_aio_ctx == NULL) {
> > +        return;
> > +    }
> > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> vtpmdev);
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> > +}
> > +
> > +static void vtpm_event(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +}
> > +
> > +struct XenDevOps xen_vtpmdev_ops = {
> > +    .size             = sizeof(struct XenVtpmDev),
> > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > +                        DEVOPS_FLAG_STUBDOM_BE,
> > +    .event            = vtpm_event,
> > +    .free             = vtpm_free,
> > +    .alloc            = vtpm_alloc,
> > +    .initialise       = vtpm_initialise,
> > +    .backend_changed  = vtpm_backend_changed,
> > +    .recv             = vtpm_recv,
> > +    .send             = vtpm_send,
> > +};
> 
> Is this the frontend, like the subject line would seem to imply?
> If so, XenDevOps are made for backends, while this is a frontend. In
> fact this is the first PV frontend in QEMU. We need to introduce
> something generic and similar to struct XenDevOps and xen_backend.c but
> for frontends.
> 
> 
> > diff --git a/include/hw/xen/xen_backend.h
> b/include/hw/xen/xen_backend.h
> > index 3b4125e..45fd6d3 100644
> > --- a/include/hw/xen/xen_backend.h
> > +++ b/include/hw/xen/xen_backend.h
> > @@ -15,6 +15,8 @@ struct XenDevice;
> >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> >  /* don't expect frontend doing correct state transitions (aka console
> quirk) */
> >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > +/*dev backend is stubdom*/
> > +#define DEVOPS_FLAG_STUBDOM_BE    4
> >
> >  struct XenDevOps {
> >      size_t    size;
> > @@ -26,6 +28,8 @@ struct XenDevOps {
> >      void      (*event)(struct XenDevice *xendev);
> >      void      (*disconnect)(struct XenDevice *xendev);
> >      int       (*free)(struct XenDevice *xendev);
> > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> count);
> > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> *count);
> >      void      (*backend_changed)(struct XenDevice *xendev, const
> char *node);
> >      void      (*frontend_changed)(struct XenDevice *xendev, const
> char *node);
> >  };
> > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> *xendev);
> >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char
> *fmt, ...)
> >      GCC_FMT_ATTR(3, 4);
> >
> > +/*Xen stubdom vtpm*/
> > +int xen_vtpm_register(struct XenDevOps *ops);
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom);
> > +int xen_vtpm_send(unsigned char *buf, size_t count);
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> > +
> >  /* actual backend drivers */
> >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> */
> >  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c
> */
> >  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
> >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> */
> >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> */
> > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> xen_stubdom_vtpm.c*/
> >
> >  void xen_init_display(int domid);
> >
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 95612a4..fb43084 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void
> *logger, void *dombuild_logger,
> >      return xc_interface_open(logger, dombuild_logger, open_flags);
> >  }
> >
> > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > +                                           unsigned int open_flags)
> > +{
> > +    return xc_gntshr_open(logger, open_flags);
> > +}
> > +
> >  /* FIXME There is now way to have the xen fd */
> >  static inline int xc_fd(xc_interface *xen_xc)
> >  {
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 21f1cbb..c99ace8 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >      int i, rc;
> >      unsigned long ioreq_pfn;
> >      unsigned long bufioreq_evtchn;
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    unsigned long stubdom_vtpm = 0;
> > +#endif
> > +
> >      XenIOState *state;
> >
> >      state = g_malloc0(sizeof (XenIOState));
> > @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >          fprintf(stderr, "%s: xen backend core setup failed\n",
> __FUNCTION__);
> >          return -1;
> >      }
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    xc_get_hvm_param(xen_xc, xen_domid,
> HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > +    if (stubdom_vtpm) {
> > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > +    }
> > +#endif
> 
> Given that vtpm is just a PV frontend, can't you just detect whether is
> present on xenstore and initialize it based on that? Like all the
> backend below?

Refer to above explanation. 

Thanks 
Quan 

> 
> 
> >      xen_be_register("console", &xen_console_ops);
> >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> >      xen_be_register("qdisk", &xen_blkdev_ops);
> > --
> > 1.8.3.2
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 09:29:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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 1XmJNA-00066m-M1; Thu, 06 Nov 2014 09:28:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XmJN9-00066h-AL
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 09:28:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DD/22-09842-65F3B545; Thu, 06 Nov 2014 09:28:54 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415266127!11522061!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20701 invoked from network); 6 Nov 2014 09:28:52 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-21.messagelabs.com with SMTP;
	6 Nov 2014 09:28:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 06 Nov 2014 01:28:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,324,1413270000"; d="scan'208";a="618092271"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.119])
	([10.238.130.119])
	by fmsmga001.fm.intel.com with ESMTP; 06 Nov 2014 01:28:43 -0800
Message-ID: <545B3F4A.5070808@intel.com>
Date: Thu, 06 Nov 2014 17:28:42 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
In-Reply-To: <545A57AD02000078000C1037@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/6 1:00, Jan Beulich wrote:
>>>> "Chen, Tiejun" <tiejun.chen@intel.com> 11/05/14 3:59 AM >>>
>
> Everything up to here sounded reasonable.
>
>> Next, we need a new domctl to provide these info, 'pci_rdmforce' and
>> 'rdm_force' when parse the config file. Certainly we may need to
>> introduce and set two new fields in strcut domain, and since then we
>> just use these fields to modify our current existing iommu callback
>> inside to support our policy. I mean we just expose those associated
>> RMRR entry. I think its easy to implement this since inside Xen we can
>> know which entry is owned by which device. So this can benefit us to
>> avoid modifying any tools codes and most Xen codes we already addressed.
>
> Whether a domctl is the right approach I can't really tell with this
> somewhat vague description.
>

So based on our current patch, I generate a draft patch as follows to 
show my idea. Note I just tried to compile this.

diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 009e351..ff22228 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1642,6 +1642,21 @@ int xc_assign_device(
      return do_domctl(xch, &domctl);
  }

+int xc_domain_device_setrdm(xc_interface *xch,
+                            uint32_t domid,
+                            uint32_t pci_rdmforce,
+                            uint32_t pci_dev_bitmap)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_rdm;
+    domctl.domain = domid;
+    domctl.u.set_rdm.pci_rdmforce = pci_rdmforce;
+    domctl.u.set_rdm.pci_dev_bitmap = pci_dev_bitmap;
+
+    return do_domctl(xch, &domctl);
+}
+
  int xc_get_device_group(
      xc_interface *xch,
      uint32_t domid,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..ca8b754 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -90,6 +90,19 @@ const char *libxl__domain_device_model(libxl__gc *gc,
      return dm;
  }

+int libxl__domain_device_setrdm(libxl__gc *gc,
+                                const libxl_domain_build_info *info,
+                                uint32_t dm_domid)
+{
+    int ret;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    ret = xc_domain_device_setrdm(ctx->xch, dm_domid, info->pci_rdmforce,
+                                  info->pci_dev_bitmap);
+
+    return ret;
+}
+
  const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config 
*guest_config)
  {
      const libxl_vnc_info *vnc = NULL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..06938ee 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1471,6 +1471,11 @@ _hidden int libxl__domain_build(libxl__gc *gc,
  /* for device model creation */
  _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                          const libxl_domain_build_info 
*info);
+
+_hidden int libxl__domain_device_setrdm(libxl__gc *gc,
+                                        const libxl_domain_build_info 
*info,
+                                        uint32_t domid);
+
  _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
          int nr_consoles, libxl__device_console *consoles,
          int nr_vfbs, libxl_device_vfb *vfbs,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ca3f724..ed20823 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -398,6 +398,8 @@ libxl_domain_build_info = Struct("domain_build_info",[
      ("kernel",           string),
      ("cmdline",          string),
      ("ramdisk",          string),
+    ("pci_rdmforce",   uint32),
+    ("pci_dev_bitmap",   uint32),
      ("u", KeyedUnion(None, libxl_domain_type, "type",
                  [("hvm", Struct(None, [("firmware",         string),
                                         ("bios", 
libxl_bios_type),
@@ -518,6 +520,7 @@ libxl_device_pci = Struct("device_pci", [
      ("power_mgmt", bool),
      ("permissive", bool),
      ("seize", bool),
+    ("rdmforce", bool),
      ])

  libxl_device_vtpm = Struct("device_vtpm", [
diff --git a/tools/libxl/libxlu_pci.c b/tools/libxl/libxlu_pci.c
index 26fb143..989eac8 100644
--- a/tools/libxl/libxlu_pci.c
+++ b/tools/libxl/libxlu_pci.c
@@ -143,6 +143,8 @@ int xlu_pci_parse_bdf(XLU_Config *cfg, 
libxl_device_pci *pcidev, const char *str
                      pcidev->permissive = atoi(tok);
                  }else if ( !strcmp(optkey, "seize") ) {
                      pcidev->seize = atoi(tok);
+                }else if ( !strcmp(optkey, "rdmforce") ) {
+                    pcidev->rdmforce = atoi(tok);
                  }else{
                      XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", 
optkey);
                  }
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..64a1e51 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -904,6 +904,7 @@ static void replace_string(char **str, const char *val)
      *str = xstrdup(val);
  }

+#define PCI_BDF(b,d,f) ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
  static void parse_config_data(const char *config_source,
                                const char *config_data,
                                int config_len,
@@ -919,6 +920,7 @@ static void parse_config_data(const char *config_source,
      int pci_msitranslate = 0;
      int pci_permissive = 0;
      int pci_seize = 0;
+    int pci_rdmforce = 0;
      int i, e;

      libxl_domain_create_info *c_info = &d_config->c_info;
@@ -1699,6 +1701,9 @@ skip_vfb:
      if (!xlu_cfg_get_long (config, "pci_seize", &l, 0))
          pci_seize = l;

+    if (!xlu_cfg_get_long (config, "pci_rdmforce", &l, 0))
+        pci_rdmforce = l;
+
      /* To be reworked (automatically enabled) once the auto ballooning
       * after guest starts is done (with PCI devices passed in). */
      if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
@@ -1719,9 +1724,16 @@ skip_vfb:
              pcidev->power_mgmt = pci_power_mgmt;
              pcidev->permissive = pci_permissive;
              pcidev->seize = pci_seize;
+            pcidev->rdmforce = pci_rdmforce;
              if (!xlu_pci_parse_bdf(config, pcidev, buf))
+            {
+                /* Just fake this wit a bitmap. */
+                b_info.pci_dev_bitmap |=  1 << PCI_BDF(pcidev->bus, 
pcidev->dev,
+                                                       pcidev->func);
                  d_config->num_pcidevs++;
+            }
          }
+        b_info.pci_rdmforce = pci_rdmforce;
          if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
              libxl_defbool_set(&b_info->u.pv.e820_host, true);
      }
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index dc18f1b..3bbd28f 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2434,6 +2434,7 @@ static void ept_handle_violation(unsigned long 
qualification, paddr_t gpa)
       * handle such a scenario as its own logic.
       */
      ret = 
iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                           d,
                                             &gfn);
      if ( ret )
      {
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 113d996..ba489ce 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -691,6 +691,7 @@ guest_physmap_add_entry(struct domain *d, unsigned 
long gfn,
          if ( !is_hardware_domain(d) )
          {
              rc = 
iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                                  d,
                                                    &gfn);
              /* We always avoid populating reserved device memory. */
              if ( rc == 1 )
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index af613b9..cd99ba7 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -315,6 +315,7 @@ int compat_memory_op(unsigned int cmd, 
XEN_GUEST_HANDLE_PARAM(void) compat)

              grdm.used_entries = 0;
              rc = 
iommu_get_reserved_device_memory(get_reserved_device_memory,
+                                                  current->domain,
                                                    &grdm);

              if ( !rc && grdm.map.nr_entries < grdm.used_entries )
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index 4c84f88..e7973ee 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -69,6 +69,7 @@ static int mem_access_check_rdm(struct domain *d, 
uint64_aligned_t start,
          {
              gfn = start + i;
              rc = 
iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                                  d,
                                                    &gfn);
              if ( rc < 0 )
                  printk(XENLOG_WARNING
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 2177c56..21db828 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1140,6 +1140,7 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)

          grdm.used_entries = 0;
          rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
+                                              current->domain,
                                                &grdm);

          if ( !rc && grdm.map.nr_entries < grdm.used_entries )
diff --git a/xen/drivers/passthrough/iommu.c 
b/xen/drivers/passthrough/iommu.c
index 7c17e8d..7a5c66d 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -344,14 +344,15 @@ void iommu_crash_shutdown(void)
      iommu_enabled = iommu_intremap = 0;
  }

-int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
+int iommu_get_reserved_device_memory(iommu_grdm_t *func, struct domain* d,
+                                     void *ctxt)
  {
      const struct iommu_ops *ops = iommu_get_ops();

      if ( !iommu_enabled || !ops->get_reserved_device_memory )
          return 0;

-    return ops->get_reserved_device_memory(func, ctxt);
+    return ops->get_reserved_device_memory(func, d, ctxt);
  }

  bool_t iommu_has_feature(struct domain *d, enum iommu_feature feature)
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1eba833..ee689ff 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1540,6 +1540,18 @@ int iommu_do_pci_domctl(
          }
          break;

+    case XEN_DOMCTL_set_rdm:
+        if ( unlikely(d->is_dying) )
+        {
+            ret = -EINVAL;
+            break;
+        }
+
+        d->arch.hvm_domain.pci_rdmforce = domctl->u.set_rdm.pci_rdmforce;
+        d->arch.hvm_domain.pci_dev_bitmap = 
domctl->u.set_rdm.pci_dev_bitmap;
+
+        break;
+
      case XEN_DOMCTL_assign_device:
          if ( unlikely(d->is_dying) )
          {
diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 546eca9..138840c 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -28,6 +28,7 @@
  #include <xen/xmalloc.h>
  #include <xen/pci.h>
  #include <xen/pci_regs.h>
+#include <xen/sched.h>
  #include <asm/string.h>
  #include "dmar.h"
  #include "iommu.h"
@@ -921,18 +922,28 @@ int platform_supports_x2apic(void)
      return cpu_has_x2apic && ((dmar_flags & mask) == 
ACPI_DMAR_INTR_REMAP);
  }

-int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
+int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, struct 
domain *d,
+                                           void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
      int rc = 0;
+    int i;
+    u16 bdf;

-    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+    for_each_rmrr_device ( rmrr, bdf, i )
      {
-        rc = func(PFN_DOWN(rmrr->base_address),
-                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
-                  ctxt);
-        if ( rc )
-            break;
+        if ( d->arch.hvm_domain.pci_rdmforce )
+        {
+            if ( d->arch.hvm_domain.pci_dev_bitmap & (uint32_t)(1 << bdf) )
+            {
+                rc = func(PFN_DOWN(rmrr->base_address),
+                                   PFN_UP(rmrr->end_address) -
+                                   PFN_DOWN(rmrr->base_address),
+                                   ctxt);
+                if ( rc )
+                    break;
+            }
+        }
      }

      return rc;
diff --git a/xen/drivers/passthrough/vtd/extern.h 
b/xen/drivers/passthrough/vtd/extern.h
index f9ee9b0..df9fed3 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -75,7 +75,8 @@ int domain_context_mapping_one(struct domain *domain, 
struct iommu *iommu,
                                 u8 bus, u8 devfn, const struct pci_dev *);
  int domain_context_unmap_one(struct domain *domain, struct iommu *iommu,
                               u8 bus, u8 devfn);
-int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt);
+int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, struct 
domain *d,
+                                           void *ctxt);

  unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg);
  void io_apic_write_remap_rte(unsigned int apic,
diff --git a/xen/include/asm-x86/hvm/domain.h 
b/xen/include/asm-x86/hvm/domain.h
index 2757c7f..5dab8dd 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -90,6 +90,9 @@ struct hvm_domain {
      /* Cached CF8 for guest PCI config cycles */
      uint32_t                pci_cf8;

+    uint32_t                pci_rdmforce;
+    uint32_t                pci_dev_bitmap;
+
      struct pl_time         pl_time;

      struct hvm_io_handler *io_handler;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 58b19e7..8b7cd5b 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -484,6 +484,14 @@ struct xen_domctl_assign_device {
  typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
  DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);

+/* Control whether/how we check and reserve device memory. */
+struct xen_domctl_set_rdm {
+    uint32_t  pci_rdmforce;
+    uint32_t  pci_dev_bitmap;
+};
+typedef struct xen_domctl_set_rdm xen_domctl_set_rdm_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_rdm_t);
+
  /* Retrieve sibling devices infomation of machine_sbdf */
  /* XEN_DOMCTL_get_device_group */
  struct xen_domctl_get_device_group {
@@ -1056,6 +1064,7 @@ struct xen_domctl {
  #define XEN_DOMCTL_set_vcpu_msrs                 73
  #define XEN_DOMCTL_setvnumainfo                  74
  #define XEN_DOMCTL_psr_cmt_op                    75
+#define XEN_DOMCTL_set_rdm                       76
  #define XEN_DOMCTL_gdbsx_guestmemio            1000
  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1118,7 +1127,8 @@ struct xen_domctl {
          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
          struct xen_domctl_vnuma             vnuma;
          struct xen_domctl_psr_cmt_op        psr_cmt_op;
-        uint8_t                             pad[128];
+        struct xen_domctl_set_rdm           set_rdm;
+        uint8_t                             pad[120];
      } u;
  };
  typedef struct xen_domctl xen_domctl_t;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 409f6f8..adf3d52 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -158,14 +158,14 @@ struct iommu_ops {
      void (*crash_shutdown)(void);
      void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned 
int page_count);
      void (*iotlb_flush_all)(struct domain *d);
-    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
+    int (*get_reserved_device_memory)(iommu_grdm_t *, struct domain *, 
void *);
      void (*dump_p2m_table)(struct domain *d);
  };

  void iommu_suspend(void);
  void iommu_resume(void);
  void iommu_crash_shutdown(void);
-int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
+int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain *, 
void *);

  void iommu_share_p2m_table(struct domain *d);

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 09:29:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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 1XmJNA-00066m-M1; Thu, 06 Nov 2014 09:28:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XmJN9-00066h-AL
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 09:28:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DD/22-09842-65F3B545; Thu, 06 Nov 2014 09:28:54 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415266127!11522061!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20701 invoked from network); 6 Nov 2014 09:28:52 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-21.messagelabs.com with SMTP;
	6 Nov 2014 09:28:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 06 Nov 2014 01:28:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,324,1413270000"; d="scan'208";a="618092271"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.119])
	([10.238.130.119])
	by fmsmga001.fm.intel.com with ESMTP; 06 Nov 2014 01:28:43 -0800
Message-ID: <545B3F4A.5070808@intel.com>
Date: Thu, 06 Nov 2014 17:28:42 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
In-Reply-To: <545A57AD02000078000C1037@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/6 1:00, Jan Beulich wrote:
>>>> "Chen, Tiejun" <tiejun.chen@intel.com> 11/05/14 3:59 AM >>>
>
> Everything up to here sounded reasonable.
>
>> Next, we need a new domctl to provide these info, 'pci_rdmforce' and
>> 'rdm_force' when parse the config file. Certainly we may need to
>> introduce and set two new fields in strcut domain, and since then we
>> just use these fields to modify our current existing iommu callback
>> inside to support our policy. I mean we just expose those associated
>> RMRR entry. I think its easy to implement this since inside Xen we can
>> know which entry is owned by which device. So this can benefit us to
>> avoid modifying any tools codes and most Xen codes we already addressed.
>
> Whether a domctl is the right approach I can't really tell with this
> somewhat vague description.
>

So based on our current patch, I generate a draft patch as follows to 
show my idea. Note I just tried to compile this.

diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 009e351..ff22228 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1642,6 +1642,21 @@ int xc_assign_device(
      return do_domctl(xch, &domctl);
  }

+int xc_domain_device_setrdm(xc_interface *xch,
+                            uint32_t domid,
+                            uint32_t pci_rdmforce,
+                            uint32_t pci_dev_bitmap)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_rdm;
+    domctl.domain = domid;
+    domctl.u.set_rdm.pci_rdmforce = pci_rdmforce;
+    domctl.u.set_rdm.pci_dev_bitmap = pci_dev_bitmap;
+
+    return do_domctl(xch, &domctl);
+}
+
  int xc_get_device_group(
      xc_interface *xch,
      uint32_t domid,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..ca8b754 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -90,6 +90,19 @@ const char *libxl__domain_device_model(libxl__gc *gc,
      return dm;
  }

+int libxl__domain_device_setrdm(libxl__gc *gc,
+                                const libxl_domain_build_info *info,
+                                uint32_t dm_domid)
+{
+    int ret;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    ret = xc_domain_device_setrdm(ctx->xch, dm_domid, info->pci_rdmforce,
+                                  info->pci_dev_bitmap);
+
+    return ret;
+}
+
  const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config 
*guest_config)
  {
      const libxl_vnc_info *vnc = NULL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..06938ee 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1471,6 +1471,11 @@ _hidden int libxl__domain_build(libxl__gc *gc,
  /* for device model creation */
  _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                          const libxl_domain_build_info 
*info);
+
+_hidden int libxl__domain_device_setrdm(libxl__gc *gc,
+                                        const libxl_domain_build_info 
*info,
+                                        uint32_t domid);
+
  _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
          int nr_consoles, libxl__device_console *consoles,
          int nr_vfbs, libxl_device_vfb *vfbs,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ca3f724..ed20823 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -398,6 +398,8 @@ libxl_domain_build_info = Struct("domain_build_info",[
      ("kernel",           string),
      ("cmdline",          string),
      ("ramdisk",          string),
+    ("pci_rdmforce",   uint32),
+    ("pci_dev_bitmap",   uint32),
      ("u", KeyedUnion(None, libxl_domain_type, "type",
                  [("hvm", Struct(None, [("firmware",         string),
                                         ("bios", 
libxl_bios_type),
@@ -518,6 +520,7 @@ libxl_device_pci = Struct("device_pci", [
      ("power_mgmt", bool),
      ("permissive", bool),
      ("seize", bool),
+    ("rdmforce", bool),
      ])

  libxl_device_vtpm = Struct("device_vtpm", [
diff --git a/tools/libxl/libxlu_pci.c b/tools/libxl/libxlu_pci.c
index 26fb143..989eac8 100644
--- a/tools/libxl/libxlu_pci.c
+++ b/tools/libxl/libxlu_pci.c
@@ -143,6 +143,8 @@ int xlu_pci_parse_bdf(XLU_Config *cfg, 
libxl_device_pci *pcidev, const char *str
                      pcidev->permissive = atoi(tok);
                  }else if ( !strcmp(optkey, "seize") ) {
                      pcidev->seize = atoi(tok);
+                }else if ( !strcmp(optkey, "rdmforce") ) {
+                    pcidev->rdmforce = atoi(tok);
                  }else{
                      XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", 
optkey);
                  }
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..64a1e51 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -904,6 +904,7 @@ static void replace_string(char **str, const char *val)
      *str = xstrdup(val);
  }

+#define PCI_BDF(b,d,f) ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
  static void parse_config_data(const char *config_source,
                                const char *config_data,
                                int config_len,
@@ -919,6 +920,7 @@ static void parse_config_data(const char *config_source,
      int pci_msitranslate = 0;
      int pci_permissive = 0;
      int pci_seize = 0;
+    int pci_rdmforce = 0;
      int i, e;

      libxl_domain_create_info *c_info = &d_config->c_info;
@@ -1699,6 +1701,9 @@ skip_vfb:
      if (!xlu_cfg_get_long (config, "pci_seize", &l, 0))
          pci_seize = l;

+    if (!xlu_cfg_get_long (config, "pci_rdmforce", &l, 0))
+        pci_rdmforce = l;
+
      /* To be reworked (automatically enabled) once the auto ballooning
       * after guest starts is done (with PCI devices passed in). */
      if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
@@ -1719,9 +1724,16 @@ skip_vfb:
              pcidev->power_mgmt = pci_power_mgmt;
              pcidev->permissive = pci_permissive;
              pcidev->seize = pci_seize;
+            pcidev->rdmforce = pci_rdmforce;
              if (!xlu_pci_parse_bdf(config, pcidev, buf))
+            {
+                /* Just fake this wit a bitmap. */
+                b_info.pci_dev_bitmap |=  1 << PCI_BDF(pcidev->bus, 
pcidev->dev,
+                                                       pcidev->func);
                  d_config->num_pcidevs++;
+            }
          }
+        b_info.pci_rdmforce = pci_rdmforce;
          if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
              libxl_defbool_set(&b_info->u.pv.e820_host, true);
      }
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index dc18f1b..3bbd28f 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2434,6 +2434,7 @@ static void ept_handle_violation(unsigned long 
qualification, paddr_t gpa)
       * handle such a scenario as its own logic.
       */
      ret = 
iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                           d,
                                             &gfn);
      if ( ret )
      {
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 113d996..ba489ce 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -691,6 +691,7 @@ guest_physmap_add_entry(struct domain *d, unsigned 
long gfn,
          if ( !is_hardware_domain(d) )
          {
              rc = 
iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                                  d,
                                                    &gfn);
              /* We always avoid populating reserved device memory. */
              if ( rc == 1 )
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index af613b9..cd99ba7 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -315,6 +315,7 @@ int compat_memory_op(unsigned int cmd, 
XEN_GUEST_HANDLE_PARAM(void) compat)

              grdm.used_entries = 0;
              rc = 
iommu_get_reserved_device_memory(get_reserved_device_memory,
+                                                  current->domain,
                                                    &grdm);

              if ( !rc && grdm.map.nr_entries < grdm.used_entries )
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index 4c84f88..e7973ee 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -69,6 +69,7 @@ static int mem_access_check_rdm(struct domain *d, 
uint64_aligned_t start,
          {
              gfn = start + i;
              rc = 
iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                                  d,
                                                    &gfn);
              if ( rc < 0 )
                  printk(XENLOG_WARNING
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 2177c56..21db828 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1140,6 +1140,7 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)

          grdm.used_entries = 0;
          rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
+                                              current->domain,
                                                &grdm);

          if ( !rc && grdm.map.nr_entries < grdm.used_entries )
diff --git a/xen/drivers/passthrough/iommu.c 
b/xen/drivers/passthrough/iommu.c
index 7c17e8d..7a5c66d 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -344,14 +344,15 @@ void iommu_crash_shutdown(void)
      iommu_enabled = iommu_intremap = 0;
  }

-int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
+int iommu_get_reserved_device_memory(iommu_grdm_t *func, struct domain* d,
+                                     void *ctxt)
  {
      const struct iommu_ops *ops = iommu_get_ops();

      if ( !iommu_enabled || !ops->get_reserved_device_memory )
          return 0;

-    return ops->get_reserved_device_memory(func, ctxt);
+    return ops->get_reserved_device_memory(func, d, ctxt);
  }

  bool_t iommu_has_feature(struct domain *d, enum iommu_feature feature)
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1eba833..ee689ff 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1540,6 +1540,18 @@ int iommu_do_pci_domctl(
          }
          break;

+    case XEN_DOMCTL_set_rdm:
+        if ( unlikely(d->is_dying) )
+        {
+            ret = -EINVAL;
+            break;
+        }
+
+        d->arch.hvm_domain.pci_rdmforce = domctl->u.set_rdm.pci_rdmforce;
+        d->arch.hvm_domain.pci_dev_bitmap = 
domctl->u.set_rdm.pci_dev_bitmap;
+
+        break;
+
      case XEN_DOMCTL_assign_device:
          if ( unlikely(d->is_dying) )
          {
diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 546eca9..138840c 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -28,6 +28,7 @@
  #include <xen/xmalloc.h>
  #include <xen/pci.h>
  #include <xen/pci_regs.h>
+#include <xen/sched.h>
  #include <asm/string.h>
  #include "dmar.h"
  #include "iommu.h"
@@ -921,18 +922,28 @@ int platform_supports_x2apic(void)
      return cpu_has_x2apic && ((dmar_flags & mask) == 
ACPI_DMAR_INTR_REMAP);
  }

-int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
+int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, struct 
domain *d,
+                                           void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
      int rc = 0;
+    int i;
+    u16 bdf;

-    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+    for_each_rmrr_device ( rmrr, bdf, i )
      {
-        rc = func(PFN_DOWN(rmrr->base_address),
-                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
-                  ctxt);
-        if ( rc )
-            break;
+        if ( d->arch.hvm_domain.pci_rdmforce )
+        {
+            if ( d->arch.hvm_domain.pci_dev_bitmap & (uint32_t)(1 << bdf) )
+            {
+                rc = func(PFN_DOWN(rmrr->base_address),
+                                   PFN_UP(rmrr->end_address) -
+                                   PFN_DOWN(rmrr->base_address),
+                                   ctxt);
+                if ( rc )
+                    break;
+            }
+        }
      }

      return rc;
diff --git a/xen/drivers/passthrough/vtd/extern.h 
b/xen/drivers/passthrough/vtd/extern.h
index f9ee9b0..df9fed3 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -75,7 +75,8 @@ int domain_context_mapping_one(struct domain *domain, 
struct iommu *iommu,
                                 u8 bus, u8 devfn, const struct pci_dev *);
  int domain_context_unmap_one(struct domain *domain, struct iommu *iommu,
                               u8 bus, u8 devfn);
-int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt);
+int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, struct 
domain *d,
+                                           void *ctxt);

  unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg);
  void io_apic_write_remap_rte(unsigned int apic,
diff --git a/xen/include/asm-x86/hvm/domain.h 
b/xen/include/asm-x86/hvm/domain.h
index 2757c7f..5dab8dd 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -90,6 +90,9 @@ struct hvm_domain {
      /* Cached CF8 for guest PCI config cycles */
      uint32_t                pci_cf8;

+    uint32_t                pci_rdmforce;
+    uint32_t                pci_dev_bitmap;
+
      struct pl_time         pl_time;

      struct hvm_io_handler *io_handler;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 58b19e7..8b7cd5b 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -484,6 +484,14 @@ struct xen_domctl_assign_device {
  typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
  DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);

+/* Control whether/how we check and reserve device memory. */
+struct xen_domctl_set_rdm {
+    uint32_t  pci_rdmforce;
+    uint32_t  pci_dev_bitmap;
+};
+typedef struct xen_domctl_set_rdm xen_domctl_set_rdm_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_rdm_t);
+
  /* Retrieve sibling devices infomation of machine_sbdf */
  /* XEN_DOMCTL_get_device_group */
  struct xen_domctl_get_device_group {
@@ -1056,6 +1064,7 @@ struct xen_domctl {
  #define XEN_DOMCTL_set_vcpu_msrs                 73
  #define XEN_DOMCTL_setvnumainfo                  74
  #define XEN_DOMCTL_psr_cmt_op                    75
+#define XEN_DOMCTL_set_rdm                       76
  #define XEN_DOMCTL_gdbsx_guestmemio            1000
  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1118,7 +1127,8 @@ struct xen_domctl {
          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
          struct xen_domctl_vnuma             vnuma;
          struct xen_domctl_psr_cmt_op        psr_cmt_op;
-        uint8_t                             pad[128];
+        struct xen_domctl_set_rdm           set_rdm;
+        uint8_t                             pad[120];
      } u;
  };
  typedef struct xen_domctl xen_domctl_t;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 409f6f8..adf3d52 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -158,14 +158,14 @@ struct iommu_ops {
      void (*crash_shutdown)(void);
      void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned 
int page_count);
      void (*iotlb_flush_all)(struct domain *d);
-    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
+    int (*get_reserved_device_memory)(iommu_grdm_t *, struct domain *, 
void *);
      void (*dump_p2m_table)(struct domain *d);
  };

  void iommu_suspend(void);
  void iommu_resume(void);
  void iommu_crash_shutdown(void);
-int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
+int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain *, 
void *);

  void iommu_share_p2m_table(struct domain *d);

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 09:45:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09: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 1XmJcy-0006cZ-03; Thu, 06 Nov 2014 09:45:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmJcv-0006cO-KB
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 09:45:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	41/A8-09936-9234B545; Thu, 06 Nov 2014 09:45:13 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415267112!11527785!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19422 invoked from network); 6 Nov 2014 09:45:12 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 09:45:12 -0000
Received: by mail-wi0-f174.google.com with SMTP id d1so897415wiv.7
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 01:45:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=wNrNhpbx3xgWFPEF+ki14GG5btmwW105I/ozFVphMHM=;
	b=gBMKdPUpqY3TpqbNrhDxPzpyIwBSWJabEag8puauCnZ6hf6DeVh2pie8MlaUcn3or+
	lnZFRX6nqQzjrzjatVkeDAmINvDrcopJ3SwtjmWldyP4zyiXmo3vIFlzt5kTaVdSgE2B
	Oi5NPEodIU+DJBvuwlvcmCSj96wdtRaa6cv2j1wxaKUAeJ+wyavYxVhC36khU+C3j5EH
	IPSmYbQSTLFGpawQflnx6lulzg3BIXsQkCXKMLX58ADBfahlwqusiX45KSeZEg3TZreL
	BBJsf5FW2mMlyjMCC1gP+h3fPshaEtY4RXSj1Muz+mu2DJXbzqheUcyzUYW9NlW6e5TC
	EXpg==
X-Gm-Message-State: ALoCoQneGaBLm/5ZSx5qHAu1EFPCIeu3MJMtlC7d5trE0N4kmdM6Z2bJIA001riVRH13dknaXgEq
X-Received: by 10.194.71.84 with SMTP id s20mr1741039wju.128.1415267112152;
	Thu, 06 Nov 2014 01:45:12 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id h8sm7084470wjs.43.2014.11.06.01.45.10
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 01:45:11 -0800 (PST)
Message-ID: <545B4325.9000801@linaro.org>
Date: Thu, 06 Nov 2014 09:45:09 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>, ian.campbell@citrix.com, 
	xen-devel@lists.xenproject.org, konrad.wilk@oracle.com
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
In-Reply-To: <545A5B4F02000078000C1073@mail.emea.novell.com>
Cc: wei.liu2@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 05/11/2014 17:15, Jan Beulich wrote:
>>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>>> It also needs Acks from Daniel and Jan.
>>
>> This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
>> required. Would Ian C. ack be enough?
>
> Yes, it would.
>
>> Anyway, Jan do you have any objection on this patch?
>
> As said previously, I'm not particularly happy about it, but I also don't strongly
> mind it going in in the current shape.

May I ask what is wrong with the new approach to the a DOMCTL in this patch?

The DOMCTL has been clearly identify as arm specific (there is "arm" in 
the name). Therefore it doesn't seem necessary to expose it for other 
architecture than ARM32 and ARM64.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 09:45:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09: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 1XmJct-0006cH-A2; Thu, 06 Nov 2014 09:45:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmJcs-0006cC-8Q
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 09:45:10 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	A1/68-02559-4234B545; Thu, 06 Nov 2014 09:45:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415267106!11725854!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29429 invoked from network); 6 Nov 2014 09:45:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 09:45:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,324,1413244800"; d="scan'208";a="188699017"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 6 Nov 2014 04:45:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmJcm-0002HQ-RS;
	Thu, 06 Nov 2014 09:45:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmJcm-0006wI-IR;
	Thu, 06 Nov 2014 09:45:04 +0000
Date: Thu, 6 Nov 2014 09:45:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31393-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31393: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31393 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31393/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Thu Nov 06 09:45:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09: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 1XmJcy-0006cZ-03; Thu, 06 Nov 2014 09:45:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmJcv-0006cO-KB
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 09:45:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	41/A8-09936-9234B545; Thu, 06 Nov 2014 09:45:13 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415267112!11527785!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19422 invoked from network); 6 Nov 2014 09:45:12 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 09:45:12 -0000
Received: by mail-wi0-f174.google.com with SMTP id d1so897415wiv.7
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 01:45:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=wNrNhpbx3xgWFPEF+ki14GG5btmwW105I/ozFVphMHM=;
	b=gBMKdPUpqY3TpqbNrhDxPzpyIwBSWJabEag8puauCnZ6hf6DeVh2pie8MlaUcn3or+
	lnZFRX6nqQzjrzjatVkeDAmINvDrcopJ3SwtjmWldyP4zyiXmo3vIFlzt5kTaVdSgE2B
	Oi5NPEodIU+DJBvuwlvcmCSj96wdtRaa6cv2j1wxaKUAeJ+wyavYxVhC36khU+C3j5EH
	IPSmYbQSTLFGpawQflnx6lulzg3BIXsQkCXKMLX58ADBfahlwqusiX45KSeZEg3TZreL
	BBJsf5FW2mMlyjMCC1gP+h3fPshaEtY4RXSj1Muz+mu2DJXbzqheUcyzUYW9NlW6e5TC
	EXpg==
X-Gm-Message-State: ALoCoQneGaBLm/5ZSx5qHAu1EFPCIeu3MJMtlC7d5trE0N4kmdM6Z2bJIA001riVRH13dknaXgEq
X-Received: by 10.194.71.84 with SMTP id s20mr1741039wju.128.1415267112152;
	Thu, 06 Nov 2014 01:45:12 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id h8sm7084470wjs.43.2014.11.06.01.45.10
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 01:45:11 -0800 (PST)
Message-ID: <545B4325.9000801@linaro.org>
Date: Thu, 06 Nov 2014 09:45:09 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>, ian.campbell@citrix.com, 
	xen-devel@lists.xenproject.org, konrad.wilk@oracle.com
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
In-Reply-To: <545A5B4F02000078000C1073@mail.emea.novell.com>
Cc: wei.liu2@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 05/11/2014 17:15, Jan Beulich wrote:
>>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>>> It also needs Acks from Daniel and Jan.
>>
>> This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
>> required. Would Ian C. ack be enough?
>
> Yes, it would.
>
>> Anyway, Jan do you have any objection on this patch?
>
> As said previously, I'm not particularly happy about it, but I also don't strongly
> mind it going in in the current shape.

May I ask what is wrong with the new approach to the a DOMCTL in this patch?

The DOMCTL has been clearly identify as arm specific (there is "arm" in 
the name). Therefore it doesn't seem necessary to expose it for other 
architecture than ARM32 and ARM64.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 09:45:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09: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 1XmJct-0006cH-A2; Thu, 06 Nov 2014 09:45:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmJcs-0006cC-8Q
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 09:45:10 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	A1/68-02559-4234B545; Thu, 06 Nov 2014 09:45:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415267106!11725854!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29429 invoked from network); 6 Nov 2014 09:45:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 09:45:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,324,1413244800"; d="scan'208";a="188699017"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 6 Nov 2014 04:45:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmJcm-0002HQ-RS;
	Thu, 06 Nov 2014 09:45:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmJcm-0006wI-IR;
	Thu, 06 Nov 2014 09:45:04 +0000
Date: Thu, 6 Nov 2014 09:45:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31393-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31393: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31393 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31393/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Thu Nov 06 09:46:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09: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 1XmJeQ-0006nJ-1T; Thu, 06 Nov 2014 09:46:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XmJeO-0006n5-BC
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 09:46:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4C/DC-09842-3834B545; Thu, 06 Nov 2014 09:46:43 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415267203!11898148!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25044 invoked from network); 6 Nov 2014 09:46:43 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 09:46:43 -0000
Received: by mail-wi0-f170.google.com with SMTP id r20so863864wiv.3
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 01:46:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=B2LBHo4yTcsuI/3bTRG0BD5/qrO0NIc4+Z+U7kgA/m4=;
	b=BsdBcT4PypAFVpUB5DIt62EFI/n52bgy9yADPPeOh9t6N+b9uUayTPt4crMs7Rn5Z4
	bnVA8D/XFR0x9x76YXcUXiqbxuqmXm/Je4tVa0UYUah+IU+4EXcUcpAl6j7YQQf4WJ51
	qM8E4ONxBmghgFo+K5aUczV1qa5kwKtXJ7tKsFf2826iinjr7kEkgkjI5WzfGViZEVvU
	PtuF9tj/CvAzfzjPrWYcofZT+xN9iYV0SpuIhUA37Wwn+BplZ9BrWOf+AXt/0vBTkgjZ
	U5VFYIW1H1REfO46e2DuZVZ2EDf05Ibv2aWSJ4tw8CcIKZeT4pinj287zwkXeLrXsxCi
	yh1g==
X-Gm-Message-State: ALoCoQlaX7Z7gGdfpSYzOAtMi6mqr2Vsenke40HC2jahvDcnrw/rM8jVrOEFBC32qz5X8ese8rlT
X-Received: by 10.194.189.240 with SMTP id gl16mr2835231wjc.119.1415267203024; 
	Thu, 06 Nov 2014 01:46:43 -0800 (PST)
Received: from [192.168.0.100] ([90.152.119.35])
	by mx.google.com with ESMTPSA id a8sm7548393wiz.21.2014.11.06.01.46.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 01:46:42 -0800 (PST)
Message-ID: <545B4380.3050209@linaro.org>
Date: Thu, 06 Nov 2014 09:46:40 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Julien Grall <julien.grall@linaro.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>	<545A2A96.8060105@linaro.org>
	<alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
Cc: zoltan.kiss@huawei.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 05/11/14 14:52, Stefano Stabellini wrote:
> On Wed, 5 Nov 2014, Julien Grall wrote:
>> Hi Frediano,
>>
>> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
>>> This name can appear in some Linux kernel repos. Not very fortunate,
>>> but to avoid others spending an hour to spot that few characters
>>> difference it worth to work around it.
>>
>> Linux upstream is using "hisilicon,hip04-intc" to detect the hisilicon
>> interrupt controller. So it's not a workaround.
>>
>> Which kernel is using the "*,hip04-gic"?
>
> Good question, but what really matters is the string that u-boot (or any
> other firmware/bootloader) is going to use, right? So, which one is it?
We are using the DTB from the kernel source, even when loading a bare 
metal kernel. I've looked around, the *gic version seems to exist only 
in internal repos, as far as I can see. Including the one Frediano 
started to use for porting. Therefore, I don't insist to keep both, but 
as I mentioned in the commit message, it would still provide some 
benefit, and given that it's just a 3 line change which just extend a 
few listings, I think we should keep it.
Of course with a different commit message, which clears that this is the 
official name of it.

Zoli

>
>
>
>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
>>> ---
>>>   xen/arch/arm/gic-v2.c     | 1 +
>>>   xen/include/asm-arm/gic.h | 4 +++-
>>>   2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>>> index 3cb59dd..9ab30ce 100644
>>> --- a/xen/arch/arm/gic-v2.c
>>> +++ b/xen/arch/arm/gic-v2.c
>>> @@ -823,6 +823,7 @@ DT_DEVICE_END
>>>   static const char * const hip04_gicv2_dt_compat[] __initconst =
>>>   {
>>>       DT_COMPAT_GIC_HIP04,
>>> +    DT_COMPAT_GIC_HIP04_2,
>>>       NULL
>>>   };
>>>
>>> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
>>> index 5adb628..3d2b3db 100644
>>> --- a/xen/include/asm-arm/gic.h
>>> +++ b/xen/include/asm-arm/gic.h
>>> @@ -156,11 +156,13 @@
>>>   #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
>>>   #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
>>>   #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
>>> +#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
>>>
>>>   #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
>>>                           DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
>>>                           DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
>>> -                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
>>> +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
>>> +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
>>>
>>>   #define DT_COMPAT_GIC_V3             "arm,gic-v3"
>>>
>>>
>>
>>
>> --
>> Julien Grall
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 06 09:46:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09: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 1XmJeQ-0006nJ-1T; Thu, 06 Nov 2014 09:46:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XmJeO-0006n5-BC
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 09:46:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4C/DC-09842-3834B545; Thu, 06 Nov 2014 09:46:43 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415267203!11898148!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25044 invoked from network); 6 Nov 2014 09:46:43 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 09:46:43 -0000
Received: by mail-wi0-f170.google.com with SMTP id r20so863864wiv.3
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 01:46:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=B2LBHo4yTcsuI/3bTRG0BD5/qrO0NIc4+Z+U7kgA/m4=;
	b=BsdBcT4PypAFVpUB5DIt62EFI/n52bgy9yADPPeOh9t6N+b9uUayTPt4crMs7Rn5Z4
	bnVA8D/XFR0x9x76YXcUXiqbxuqmXm/Je4tVa0UYUah+IU+4EXcUcpAl6j7YQQf4WJ51
	qM8E4ONxBmghgFo+K5aUczV1qa5kwKtXJ7tKsFf2826iinjr7kEkgkjI5WzfGViZEVvU
	PtuF9tj/CvAzfzjPrWYcofZT+xN9iYV0SpuIhUA37Wwn+BplZ9BrWOf+AXt/0vBTkgjZ
	U5VFYIW1H1REfO46e2DuZVZ2EDf05Ibv2aWSJ4tw8CcIKZeT4pinj287zwkXeLrXsxCi
	yh1g==
X-Gm-Message-State: ALoCoQlaX7Z7gGdfpSYzOAtMi6mqr2Vsenke40HC2jahvDcnrw/rM8jVrOEFBC32qz5X8ese8rlT
X-Received: by 10.194.189.240 with SMTP id gl16mr2835231wjc.119.1415267203024; 
	Thu, 06 Nov 2014 01:46:43 -0800 (PST)
Received: from [192.168.0.100] ([90.152.119.35])
	by mx.google.com with ESMTPSA id a8sm7548393wiz.21.2014.11.06.01.46.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 01:46:42 -0800 (PST)
Message-ID: <545B4380.3050209@linaro.org>
Date: Thu, 06 Nov 2014 09:46:40 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Julien Grall <julien.grall@linaro.org>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>	<545A2A96.8060105@linaro.org>
	<alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
Cc: zoltan.kiss@huawei.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 05/11/14 14:52, Stefano Stabellini wrote:
> On Wed, 5 Nov 2014, Julien Grall wrote:
>> Hi Frediano,
>>
>> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
>>> This name can appear in some Linux kernel repos. Not very fortunate,
>>> but to avoid others spending an hour to spot that few characters
>>> difference it worth to work around it.
>>
>> Linux upstream is using "hisilicon,hip04-intc" to detect the hisilicon
>> interrupt controller. So it's not a workaround.
>>
>> Which kernel is using the "*,hip04-gic"?
>
> Good question, but what really matters is the string that u-boot (or any
> other firmware/bootloader) is going to use, right? So, which one is it?
We are using the DTB from the kernel source, even when loading a bare 
metal kernel. I've looked around, the *gic version seems to exist only 
in internal repos, as far as I can see. Including the one Frediano 
started to use for porting. Therefore, I don't insist to keep both, but 
as I mentioned in the commit message, it would still provide some 
benefit, and given that it's just a 3 line change which just extend a 
few listings, I think we should keep it.
Of course with a different commit message, which clears that this is the 
official name of it.

Zoli

>
>
>
>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
>>> ---
>>>   xen/arch/arm/gic-v2.c     | 1 +
>>>   xen/include/asm-arm/gic.h | 4 +++-
>>>   2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>>> index 3cb59dd..9ab30ce 100644
>>> --- a/xen/arch/arm/gic-v2.c
>>> +++ b/xen/arch/arm/gic-v2.c
>>> @@ -823,6 +823,7 @@ DT_DEVICE_END
>>>   static const char * const hip04_gicv2_dt_compat[] __initconst =
>>>   {
>>>       DT_COMPAT_GIC_HIP04,
>>> +    DT_COMPAT_GIC_HIP04_2,
>>>       NULL
>>>   };
>>>
>>> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
>>> index 5adb628..3d2b3db 100644
>>> --- a/xen/include/asm-arm/gic.h
>>> +++ b/xen/include/asm-arm/gic.h
>>> @@ -156,11 +156,13 @@
>>>   #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
>>>   #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
>>>   #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-gic"
>>> +#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-intc"
>>>
>>>   #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
>>>                           DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
>>>                           DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
>>> -                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
>>> +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
>>> +                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
>>>
>>>   #define DT_COMPAT_GIC_V3             "arm,gic-v3"
>>>
>>>
>>
>>
>> --
>> Julien Grall
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 06 09:49:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09:49:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmJgz-00070G-JZ; Thu, 06 Nov 2014 09:49:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1XmJgy-000707-8A
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 09:49:24 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	21/C3-17735-3244B545; Thu, 06 Nov 2014 09:49:23 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415267359!8351433!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29136 invoked from network); 6 Nov 2014 09:49:19 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-14.tower-31.messagelabs.com with SMTP;
	6 Nov 2014 09:49:19 -0000
Received: from [10.1.1.186] (dhcp-10-1-1-186.lan.crc.id.au [10.1.1.186])
	by mail.crc.id.au (Postfix) with ESMTPSA id 871E5367698;
	Thu,  6 Nov 2014 20:49:10 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1415267350; bh=nTeDOKAyOlZAhAu2jxhdp/f/7rSygCGAREHWPa7eico=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=Abb9lz6MuzgZsqtYmTco9CYnvfwRC2CvSdvqKRtgO8j+fgm9UvkctauWHl6m7EqQP
	NM3aBx8j+Fnc/0gCzEa9ufCA6jcv+ppA1ttusP8xehu5f6OnRAuhrKv3ViuxtL+Kmz
	Neya2yt5OuCSoOrLKpGJ43yQ+H0vxSaQY6nppvZg=
Message-ID: <545B441C.9040907@crc.id.au>
Date: Thu, 06 Nov 2014 20:49:16 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au>
	<1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411051645140.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411051645140.22875@kaball.uk.xensource.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vnc=1 / pvgrub / close fb: backend at
	/local/domain/0/backend/vfb/xx/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: multipart/mixed; boundary="===============4001079984976973001=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============4001079984976973001==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="EO4TKGBs2sQftavFrJd695TNfgQ37mbMc"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EO4TKGBs2sQftavFrJd695TNfgQ37mbMc
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Stefano,

It seems that this patch fixes the grub issue for me. I no longer get
the infinite wait at the grub prompt.

On 6/11/2014 4:49 AM, Stefano Stabellini wrote:
> Hello Steven,
> I have found some time to debug this myself.
> I couldn't reproduce the booting issue that you reported: in my case
> after seeing the grub boot menu I can successfully boot the kernel
> without problems.
>=20
> However I can reproduce the timeout issue that you are seeing: the
> timeout doesn't work properly in graphics mode.
>=20
> The reason is that the with a graphics terminal you checkkey () return =
0
> even when pressing no keys, resulting in wrong behaviour in run_menu.=20
>=20
> Does the following patch (also attached) fixes your issues?
>=20
>=20
> diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/gr=
ub.patches/11graphics-keyboard.diff
> new file mode 100644
> index 0000000..fe17b20
> --- /dev/null
> +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> @@ -0,0 +1,13 @@
> +diff --git a/stage2/stage2.c b/stage2/stage2.c
> +index 9d9fcc3..8353a3b 100644
> +--- a/stage2/stage2.c
> ++++ b/stage2/stage2.c
> +@@ -395,7 +395,7 @@ restart:
> + 	 pressed. =20
> + 	 This avoids polling (relevant in the grub-shell and later on
> + 	 in grub if interrupt driven I/O is done).  */
> +-      if (checkkey () >=3D 0 || grub_timeout < 0)
> ++      if (checkkey () > 0 || grub_timeout < 0)
> + 	{
> + 	  /* Key was pressed, show which entry is selected before GETKEY,
> + 	     since we're comming in here also on GRUB_TIMEOUT =3D=3D -1 and
>=20
>=20
>=20
> On Thu, 23 Oct 2014, Steven Haigh wrote:
>> On 23/10/2014 2:40 AM, Ian Campbell wrote:
>>> On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
>>>
>>>> Output using pv-grub:
>>>
>>> Can you also post the qemu logs please (under /var/log/xen somewhere =
I
>>> think).
>>
>> I get very little out of this:
>> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
>> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
>> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
>> [root@dom0 xen]# cat xl-dev.vm.log
>> Waiting for domain dev.vm (domid 36) to die [pid 6970]
>>
>> That's it :\
>>
>>>> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
>>>> 00007fffb4573638 error 4
>>>
>>> That might be a smoking gun. Is there a core dump and/or could you tr=
y
>>> and run qemu under gdb?
>>
>> Any hints on doing this? I can't say I'm a gdb guru.... I can't find a=
ny
>> core dumps anywhere so that's not really helpful...
>>
>> --=20
>> Steven Haigh
>>
>> Email: netwiz@crc.id.au
>> Web: http://www.crc.id.au
>> Phone: (03) 9001 6090 - 0412 935 897
>>

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


--EO4TKGBs2sQftavFrJd695TNfgQ37mbMc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJUW0QdAAoJEEGvNdV6fTHcjWsQAJ8vrp2B1GXN1R5ukMaQ2c2y
08xMInRO8Pg8MoDP3TiN6DWmMtho4pdtQzxtmfqIejwqhajsZnGNX5aqDKe2HDUf
dqwYLirAU3MGAEAqNUqPjRcq9DKEL/FEcNmbO6zKhqZurGEg/Aur/jyAux5CVcCf
A9gNEUt7ZKqmz4iC84MFpfUXL8D2SFd8oaUS+rmNi38HVXBiF1P9x+Drr6j8QPEH
S4hpTMdsXG6MXbeP/GFaARn3oKPXB1GB/xiUPL9N6SEziA+JclVT0K/k7sxGK7/t
uAFLoTfP8XZWvI0PTIK6zskD9vAKsX/khJRS6jtUVj+uLwpYrC0Po3wJ4+0hy/4I
h9dzo6/4MqqIuPGy1Txpqg+uHZNxn+LUkWP3QZ8fs7zlOHXji3jOS7tQ/PozSScA
bK33rVM4VKCOS7jvkDY5LEFZv8PIBYvd/90cKzz0JzOcZ/3hPWKPDQVlbubBPNFt
8PLCflqaZY6KSAjkY3holZRIXPC4IT7XJHGkd6Gio7AJiGVtrKEc+3uZ8UKNv2z5
vR4bgAWKNSNcR5Ig2RmlDTlZMidNFx3LJ9RMbyKeQXEAP2qoNv1SFwxrzuTOBeb7
Gy0hU7rRY4n63irpRdGbAyhHMkUWVxqjPSp6OjE5EUDmjMdfqT4kv0OIPB7qnTfS
EXexc7Jn7Ar9AgP3ttfT
=7z9+
-----END PGP SIGNATURE-----

--EO4TKGBs2sQftavFrJd695TNfgQ37mbMc--


--===============4001079984976973001==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4001079984976973001==--


From xen-devel-bounces@lists.xen.org Thu Nov 06 09:49:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09:49:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmJgz-00070G-JZ; Thu, 06 Nov 2014 09:49:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1XmJgy-000707-8A
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 09:49:24 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	21/C3-17735-3244B545; Thu, 06 Nov 2014 09:49:23 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415267359!8351433!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29136 invoked from network); 6 Nov 2014 09:49:19 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-14.tower-31.messagelabs.com with SMTP;
	6 Nov 2014 09:49:19 -0000
Received: from [10.1.1.186] (dhcp-10-1-1-186.lan.crc.id.au [10.1.1.186])
	by mail.crc.id.au (Postfix) with ESMTPSA id 871E5367698;
	Thu,  6 Nov 2014 20:49:10 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1415267350; bh=nTeDOKAyOlZAhAu2jxhdp/f/7rSygCGAREHWPa7eico=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=Abb9lz6MuzgZsqtYmTco9CYnvfwRC2CvSdvqKRtgO8j+fgm9UvkctauWHl6m7EqQP
	NM3aBx8j+Fnc/0gCzEa9ufCA6jcv+ppA1ttusP8xehu5f6OnRAuhrKv3ViuxtL+Kmz
	Neya2yt5OuCSoOrLKpGJ43yQ+H0vxSaQY6nppvZg=
Message-ID: <545B441C.9040907@crc.id.au>
Date: Thu, 06 Nov 2014 20:49:16 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au>
	<1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411051645140.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411051645140.22875@kaball.uk.xensource.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vnc=1 / pvgrub / close fb: backend at
	/local/domain/0/backend/vfb/xx/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: multipart/mixed; boundary="===============4001079984976973001=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============4001079984976973001==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="EO4TKGBs2sQftavFrJd695TNfgQ37mbMc"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EO4TKGBs2sQftavFrJd695TNfgQ37mbMc
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Stefano,

It seems that this patch fixes the grub issue for me. I no longer get
the infinite wait at the grub prompt.

On 6/11/2014 4:49 AM, Stefano Stabellini wrote:
> Hello Steven,
> I have found some time to debug this myself.
> I couldn't reproduce the booting issue that you reported: in my case
> after seeing the grub boot menu I can successfully boot the kernel
> without problems.
>=20
> However I can reproduce the timeout issue that you are seeing: the
> timeout doesn't work properly in graphics mode.
>=20
> The reason is that the with a graphics terminal you checkkey () return =
0
> even when pressing no keys, resulting in wrong behaviour in run_menu.=20
>=20
> Does the following patch (also attached) fixes your issues?
>=20
>=20
> diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/gr=
ub.patches/11graphics-keyboard.diff
> new file mode 100644
> index 0000000..fe17b20
> --- /dev/null
> +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> @@ -0,0 +1,13 @@
> +diff --git a/stage2/stage2.c b/stage2/stage2.c
> +index 9d9fcc3..8353a3b 100644
> +--- a/stage2/stage2.c
> ++++ b/stage2/stage2.c
> +@@ -395,7 +395,7 @@ restart:
> + 	 pressed. =20
> + 	 This avoids polling (relevant in the grub-shell and later on
> + 	 in grub if interrupt driven I/O is done).  */
> +-      if (checkkey () >=3D 0 || grub_timeout < 0)
> ++      if (checkkey () > 0 || grub_timeout < 0)
> + 	{
> + 	  /* Key was pressed, show which entry is selected before GETKEY,
> + 	     since we're comming in here also on GRUB_TIMEOUT =3D=3D -1 and
>=20
>=20
>=20
> On Thu, 23 Oct 2014, Steven Haigh wrote:
>> On 23/10/2014 2:40 AM, Ian Campbell wrote:
>>> On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
>>>
>>>> Output using pv-grub:
>>>
>>> Can you also post the qemu logs please (under /var/log/xen somewhere =
I
>>> think).
>>
>> I get very little out of this:
>> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
>> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
>> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
>> [root@dom0 xen]# cat xl-dev.vm.log
>> Waiting for domain dev.vm (domid 36) to die [pid 6970]
>>
>> That's it :\
>>
>>>> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
>>>> 00007fffb4573638 error 4
>>>
>>> That might be a smoking gun. Is there a core dump and/or could you tr=
y
>>> and run qemu under gdb?
>>
>> Any hints on doing this? I can't say I'm a gdb guru.... I can't find a=
ny
>> core dumps anywhere so that's not really helpful...
>>
>> --=20
>> Steven Haigh
>>
>> Email: netwiz@crc.id.au
>> Web: http://www.crc.id.au
>> Phone: (03) 9001 6090 - 0412 935 897
>>

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


--EO4TKGBs2sQftavFrJd695TNfgQ37mbMc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJUW0QdAAoJEEGvNdV6fTHcjWsQAJ8vrp2B1GXN1R5ukMaQ2c2y
08xMInRO8Pg8MoDP3TiN6DWmMtho4pdtQzxtmfqIejwqhajsZnGNX5aqDKe2HDUf
dqwYLirAU3MGAEAqNUqPjRcq9DKEL/FEcNmbO6zKhqZurGEg/Aur/jyAux5CVcCf
A9gNEUt7ZKqmz4iC84MFpfUXL8D2SFd8oaUS+rmNi38HVXBiF1P9x+Drr6j8QPEH
S4hpTMdsXG6MXbeP/GFaARn3oKPXB1GB/xiUPL9N6SEziA+JclVT0K/k7sxGK7/t
uAFLoTfP8XZWvI0PTIK6zskD9vAKsX/khJRS6jtUVj+uLwpYrC0Po3wJ4+0hy/4I
h9dzo6/4MqqIuPGy1Txpqg+uHZNxn+LUkWP3QZ8fs7zlOHXji3jOS7tQ/PozSScA
bK33rVM4VKCOS7jvkDY5LEFZv8PIBYvd/90cKzz0JzOcZ/3hPWKPDQVlbubBPNFt
8PLCflqaZY6KSAjkY3holZRIXPC4IT7XJHGkd6Gio7AJiGVtrKEc+3uZ8UKNv2z5
vR4bgAWKNSNcR5Ig2RmlDTlZMidNFx3LJ9RMbyKeQXEAP2qoNv1SFwxrzuTOBeb7
Gy0hU7rRY4n63irpRdGbAyhHMkUWVxqjPSp6OjE5EUDmjMdfqT4kv0OIPB7qnTfS
EXexc7Jn7Ar9AgP3ttfT
=7z9+
-----END PGP SIGNATURE-----

--EO4TKGBs2sQftavFrJd695TNfgQ37mbMc--


--===============4001079984976973001==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4001079984976973001==--


From xen-devel-bounces@lists.xen.org Thu Nov 06 09:52:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmJkF-0007Jp-7I; Thu, 06 Nov 2014 09:52:47 +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 1XmJkE-0007Jj-2T
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 09:52:46 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	80/9F-14727-DE44B545; Thu, 06 Nov 2014 09:52:45 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415267564!10840520!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9572 invoked from network); 6 Nov 2014 09:52:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 09:52:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,324,1413244800"; d="scan'208";a="26602585"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: annie li <annie.li@oracle.com>
Thread-Topic: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
	unconditional __pskb_pull_tail() in guest Tx path
Thread-Index: AQHP+OZm7HxwosuFOE6Js6RlOKbaTpxRzJcAgAAUm/D///EjgIAAEP8AgABwHACAAQlp4A==
Date: Thu, 6 Nov 2014 09:52:43 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD0111450E9@AMSPEX01CL01.citrite.net>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
	<1415186405.15317.6.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
	<545A7432.7010206@oracle.com>
In-Reply-To: <545A7432.7010206@oracle.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: annie li [mailto:annie.li@oracle.com]
> Sent: 05 November 2014 19:02
> To: Paul Durrant
> Cc: Ian Campbell; xen-devel@lists.xenproject.org; Malcolm Crossley; Wei Liu;
> David Vrabel
> Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
> unconditional __pskb_pull_tail() in guest Tx path
> 
> 
> On 2014/11/5 6:24, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Ian Campbell
> >> Sent: 05 November 2014 11:20
> >> To: Paul Durrant
> >> Cc: David Vrabel; xen-devel@lists.xenproject.org; Wei Liu; Malcolm
> Crossley
> >> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> >> __pskb_pull_tail() in guest Tx path
> >>
> >> On Wed, 2014-11-05 at 11:17 +0000, Paul Durrant wrote:
> >>>> -----Original Message-----
> >>>> From: Ian Campbell
> >>>> Sent: 05 November 2014 11:00
> >>>> To: David Vrabel
> >>>> Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul
> >> Durrant
> >>>> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> >>>> __pskb_pull_tail() in guest Tx path
> >>>>
> >>>> Dropping netdev since this isn't relevant to them, adding Paul
> >>>>
> >>>> On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> >>>>> - performance: Netback has already grant copied up-to 128 bytes
> from
> >>>>>    the first slot of a packet into the linear area. The first slot
> >>>>>    normally contain all the IPv4/IPv6 and TCP/UDP headers.
> >>>> Does "normally" include guests other than Linux? I thought Windows in
> >>>> particular was prone to splitting the headers into a frag per layer or
> >>>> thereabouts?
> >>>>
> >>> Current upstream Windows PV drivers will put all parsed headers in the
> >>> first frag and the rest of the packet in subsequent flags. The parser
> >>> currently knows about TCP and UDP over IPv4 or v6, with and without
> >>> SNAP encapsulation. It doesn't, for example, know about ARP so the
> >>> backend will see only the ethernet header in the first frag.
> >> Sounds like that is sufficient to reach the "normally" qualification,
> >> thanks.
> >>
> >> (I wonder what sort of benefit parsing arp would bring...)
> >>
> > Previous versions of the drivers used to parse ARPs so that copies of
> outgoing gratuitous ARPs could be cached for replay after migrate. Newer
> drivers acquire IP address bindings from the Windows IP helper (which is
> now available in kernel) and synthesize ARPs/IPv6 neighbour solicitations.
> I send out fake ARP after migration to deal with it, guess you are
> mentioning here
> http://msdn.microsoft.com/en-
> us/library/windows/hardware/ff557015(v=vs.85).aspx
> ? which is available for kernel later than Vista.
> 

Yes. The upstream PV drivers are Vista+ only.

  Paul

> 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 Nov 06 09:52:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmJkF-0007Jp-7I; Thu, 06 Nov 2014 09:52:47 +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 1XmJkE-0007Jj-2T
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 09:52:46 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	80/9F-14727-DE44B545; Thu, 06 Nov 2014 09:52:45 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415267564!10840520!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9572 invoked from network); 6 Nov 2014 09:52:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 09:52:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,324,1413244800"; d="scan'208";a="26602585"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: annie li <annie.li@oracle.com>
Thread-Topic: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
	unconditional __pskb_pull_tail() in guest Tx path
Thread-Index: AQHP+OZm7HxwosuFOE6Js6RlOKbaTpxRzJcAgAAUm/D///EjgIAAEP8AgABwHACAAQlp4A==
Date: Thu, 6 Nov 2014 09:52:43 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD0111450E9@AMSPEX01CL01.citrite.net>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
	<1415185172.15200.0.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114238B@AMSPEX01CL01.citrite.net>
	<1415186405.15317.6.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD011142483@AMSPEX01CL01.citrite.net>
	<545A7432.7010206@oracle.com>
In-Reply-To: <545A7432.7010206@oracle.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: annie li [mailto:annie.li@oracle.com]
> Sent: 05 November 2014 19:02
> To: Paul Durrant
> Cc: Ian Campbell; xen-devel@lists.xenproject.org; Malcolm Crossley; Wei Liu;
> David Vrabel
> Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
> unconditional __pskb_pull_tail() in guest Tx path
> 
> 
> On 2014/11/5 6:24, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Ian Campbell
> >> Sent: 05 November 2014 11:20
> >> To: Paul Durrant
> >> Cc: David Vrabel; xen-devel@lists.xenproject.org; Wei Liu; Malcolm
> Crossley
> >> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> >> __pskb_pull_tail() in guest Tx path
> >>
> >> On Wed, 2014-11-05 at 11:17 +0000, Paul Durrant wrote:
> >>>> -----Original Message-----
> >>>> From: Ian Campbell
> >>>> Sent: 05 November 2014 11:00
> >>>> To: David Vrabel
> >>>> Cc: xen-devel@lists.xenproject.org; Wei Liu; Malcolm Crossley; Paul
> >> Durrant
> >>>> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> >>>> __pskb_pull_tail() in guest Tx path
> >>>>
> >>>> Dropping netdev since this isn't relevant to them, adding Paul
> >>>>
> >>>> On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> >>>>> - performance: Netback has already grant copied up-to 128 bytes
> from
> >>>>>    the first slot of a packet into the linear area. The first slot
> >>>>>    normally contain all the IPv4/IPv6 and TCP/UDP headers.
> >>>> Does "normally" include guests other than Linux? I thought Windows in
> >>>> particular was prone to splitting the headers into a frag per layer or
> >>>> thereabouts?
> >>>>
> >>> Current upstream Windows PV drivers will put all parsed headers in the
> >>> first frag and the rest of the packet in subsequent flags. The parser
> >>> currently knows about TCP and UDP over IPv4 or v6, with and without
> >>> SNAP encapsulation. It doesn't, for example, know about ARP so the
> >>> backend will see only the ethernet header in the first frag.
> >> Sounds like that is sufficient to reach the "normally" qualification,
> >> thanks.
> >>
> >> (I wonder what sort of benefit parsing arp would bring...)
> >>
> > Previous versions of the drivers used to parse ARPs so that copies of
> outgoing gratuitous ARPs could be cached for replay after migrate. Newer
> drivers acquire IP address bindings from the Windows IP helper (which is
> now available in kernel) and synthesize ARPs/IPv6 neighbour solicitations.
> I send out fake ARP after migration to deal with it, guess you are
> mentioning here
> http://msdn.microsoft.com/en-
> us/library/windows/hardware/ff557015(v=vs.85).aspx
> ? which is available for kernel later than Vista.
> 

Yes. The upstream PV drivers are Vista+ only.

  Paul

> 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 Nov 06 09:54:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09: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 1XmJls-0007Pt-Mw; Thu, 06 Nov 2014 09:54:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmJlr-0007Pl-Aq
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 09:54:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	48/BF-24532-2554B545; Thu, 06 Nov 2014 09:54:26 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415267665!3843034!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3451 invoked from network); 6 Nov 2014 09:54:26 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 09:54:26 -0000
Received: by mail-wg0-f51.google.com with SMTP id l18so733064wgh.24
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 01:54:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=izZlu22RuRe9YBXUXMGf4bDLFS97T073XW3S6CsG/Ds=;
	b=OjWYHJNjW2GWNaRzVrdPwS8pJ0FKdqV4Oft+5bKzaKuJ5lf1vrhJNqifPi9vzFzlMZ
	RRNCF1XdYC7DUdryhBEzKtQzI6H1T7Z4Md7gPpJiWNIq2SmbseWVyA6SyLvibhIgi2hb
	WrkbOU6pdfvAZmHXJgmTmKaBkVIgRgyPHsC/XSq4sKum51SZ1YxpL8hg6ytPvGIHDbm4
	JeLUWWwYEZ+rXck4VIawA4Fkx+ak0XPJZMhYSCLV3dnVYhy2O9Vfhd74pHWEBUbil0B1
	TRPtlpg5dA1BJxm3fxv1XDrz+POxk0NTxT4D/DpYuhgEuOkLA0Qa2vcSjEvtRmFDVAVQ
	pIVw==
X-Gm-Message-State: ALoCoQlpNkZOGSlWWdlXhl94Q8j9cjMvHEFoXewej/RxDOCY4YEgUD6J8wllYBKhJXnbBtrxHJqX
X-Received: by 10.181.13.20 with SMTP id eu20mr38868780wid.36.1415267665834;
	Thu, 06 Nov 2014 01:54:25 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id w5sm7617472wif.18.2014.11.06.01.54.24
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 01:54:25 -0800 (PST)
Message-ID: <545B454F.9060401@linaro.org>
Date: Thu, 06 Nov 2014 09:54:23 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Zoltan Kiss <zoltan.kiss@linaro.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>	<545A2A96.8060105@linaro.org>
	<alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
	<545B4380.3050209@linaro.org>
In-Reply-To: <545B4380.3050209@linaro.org>
Cc: zoltan.kiss@huawei.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Zoltan,

On 06/11/2014 09:46, Zoltan Kiss wrote:
>
>
> On 05/11/14 14:52, Stefano Stabellini wrote:
>> On Wed, 5 Nov 2014, Julien Grall wrote:
>>> Hi Frediano,
>>>
>>> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
>>>> This name can appear in some Linux kernel repos. Not very fortunate,
>>>> but to avoid others spending an hour to spot that few characters
>>>> difference it worth to work around it.
>>>
>>> Linux upstream is using "hisilicon,hip04-intc" to detect the hisilicon
>>> interrupt controller. So it's not a workaround.
>>>
>>> Which kernel is using the "*,hip04-gic"?
>>
>> Good question, but what really matters is the string that u-boot (or any
>> other firmware/bootloader) is going to use, right? So, which one is it?
> We are using the DTB from the kernel source, even when loading a bare
> metal kernel. I've looked around, the *gic version seems to exist only
> in internal repos, as far as I can see. Including the one Frediano
> started to use for porting. Therefore, I don't insist to keep both, but
> as I mentioned in the commit message, it would still provide some
> benefit, and given that it's just a 3 line change which just extend a
> few listings, I think we should keep it.

In general, Xen should respect the binding that has been agreed by the 
device tree team. Anything different should not be upstream, hence it's 
for only internal purpose.

> Of course with a different commit message, which clears that this is the
> official name of it.

If it happens that both compatible are upstream. I would prefer that you 
define the *-intc one in the patch #3 and *-gic in #4.

It's more logical than defining first the non-official and then the 
official.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 09:54:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 09: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 1XmJls-0007Pt-Mw; Thu, 06 Nov 2014 09:54:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmJlr-0007Pl-Aq
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 09:54:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	48/BF-24532-2554B545; Thu, 06 Nov 2014 09:54:26 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415267665!3843034!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3451 invoked from network); 6 Nov 2014 09:54:26 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 09:54:26 -0000
Received: by mail-wg0-f51.google.com with SMTP id l18so733064wgh.24
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 01:54:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=izZlu22RuRe9YBXUXMGf4bDLFS97T073XW3S6CsG/Ds=;
	b=OjWYHJNjW2GWNaRzVrdPwS8pJ0FKdqV4Oft+5bKzaKuJ5lf1vrhJNqifPi9vzFzlMZ
	RRNCF1XdYC7DUdryhBEzKtQzI6H1T7Z4Md7gPpJiWNIq2SmbseWVyA6SyLvibhIgi2hb
	WrkbOU6pdfvAZmHXJgmTmKaBkVIgRgyPHsC/XSq4sKum51SZ1YxpL8hg6ytPvGIHDbm4
	JeLUWWwYEZ+rXck4VIawA4Fkx+ak0XPJZMhYSCLV3dnVYhy2O9Vfhd74pHWEBUbil0B1
	TRPtlpg5dA1BJxm3fxv1XDrz+POxk0NTxT4D/DpYuhgEuOkLA0Qa2vcSjEvtRmFDVAVQ
	pIVw==
X-Gm-Message-State: ALoCoQlpNkZOGSlWWdlXhl94Q8j9cjMvHEFoXewej/RxDOCY4YEgUD6J8wllYBKhJXnbBtrxHJqX
X-Received: by 10.181.13.20 with SMTP id eu20mr38868780wid.36.1415267665834;
	Thu, 06 Nov 2014 01:54:25 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id w5sm7617472wif.18.2014.11.06.01.54.24
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 01:54:25 -0800 (PST)
Message-ID: <545B454F.9060401@linaro.org>
Date: Thu, 06 Nov 2014 09:54:23 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Zoltan Kiss <zoltan.kiss@linaro.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>	<545A2A96.8060105@linaro.org>
	<alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
	<545B4380.3050209@linaro.org>
In-Reply-To: <545B4380.3050209@linaro.org>
Cc: zoltan.kiss@huawei.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Zoltan,

On 06/11/2014 09:46, Zoltan Kiss wrote:
>
>
> On 05/11/14 14:52, Stefano Stabellini wrote:
>> On Wed, 5 Nov 2014, Julien Grall wrote:
>>> Hi Frediano,
>>>
>>> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
>>>> This name can appear in some Linux kernel repos. Not very fortunate,
>>>> but to avoid others spending an hour to spot that few characters
>>>> difference it worth to work around it.
>>>
>>> Linux upstream is using "hisilicon,hip04-intc" to detect the hisilicon
>>> interrupt controller. So it's not a workaround.
>>>
>>> Which kernel is using the "*,hip04-gic"?
>>
>> Good question, but what really matters is the string that u-boot (or any
>> other firmware/bootloader) is going to use, right? So, which one is it?
> We are using the DTB from the kernel source, even when loading a bare
> metal kernel. I've looked around, the *gic version seems to exist only
> in internal repos, as far as I can see. Including the one Frediano
> started to use for porting. Therefore, I don't insist to keep both, but
> as I mentioned in the commit message, it would still provide some
> benefit, and given that it's just a 3 line change which just extend a
> few listings, I think we should keep it.

In general, Xen should respect the binding that has been agreed by the 
device tree team. Anything different should not be upstream, hence it's 
for only internal purpose.

> Of course with a different commit message, which clears that this is the
> official name of it.

If it happens that both compatible are upstream. I would prefer that you 
define the *-intc one in the patch #3 and *-gic in #4.

It's more logical than defining first the non-official and then the 
official.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:06:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmJxS-0007hz-1q; Thu, 06 Nov 2014 10:06:26 +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 1XmJxQ-0007hu-Oq
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:06:24 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	F8/51-27785-0284B545; Thu, 06 Nov 2014 10:06:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415268383!11773363!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27409 invoked from network); 6 Nov 2014 10:06:23 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 10:06:23 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 06 Nov 2014 10:06:23 +0000
Message-Id: <545B562F02000078000453FB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 06 Nov 2014 10:06:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
In-Reply-To: <545B3F4A.5070808@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.11.14 at 10:28, <tiejun.chen@intel.com> wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -484,6 +484,14 @@ struct xen_domctl_assign_device {
>   typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
> 
> +/* Control whether/how we check and reserve device memory. */
> +struct xen_domctl_set_rdm {
> +    uint32_t  pci_rdmforce;
> +    uint32_t  pci_dev_bitmap;

So this allows for 32 devices; considering that you index the bitmap
by BDF, all this covers are 0000:00:00.0 through 0000:00:03.7.
Hardly enough to cover even a single pass through device (iirc the
range above is fully used by emulated devices). And of course a
much larger bitmap isn't a good solution either.

Nor am I really clear what you need the 32 bits of "pci_rdmforce"
for, nor why this field isn't just being named "force". Without a
comment alongside the fields, it's remaining guesswork anyway
when and how this domctl is to be used. Looking at your change
to intel_iommu_get_reserved_device_memory() the field appears
to be simply redundant.

> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -158,14 +158,14 @@ struct iommu_ops {
>       void (*crash_shutdown)(void);
>       void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int page_count);
>       void (*iotlb_flush_all)(struct domain *d);
> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct domain *, void *);
>       void (*dump_p2m_table)(struct domain *d);
>   };
> 
>   void iommu_suspend(void);
>   void iommu_resume(void);
>   void iommu_crash_shutdown(void);
> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain *, void *);

I don't see why these generic interfaces would need to change;
the only thing that would seem to need changing is the callback
function (and of course the context passed to it).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:06:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmJxS-0007hz-1q; Thu, 06 Nov 2014 10:06:26 +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 1XmJxQ-0007hu-Oq
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:06:24 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	F8/51-27785-0284B545; Thu, 06 Nov 2014 10:06:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415268383!11773363!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27409 invoked from network); 6 Nov 2014 10:06:23 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 10:06:23 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 06 Nov 2014 10:06:23 +0000
Message-Id: <545B562F02000078000453FB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 06 Nov 2014 10:06:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544DFDB2.2010508@intel.com>
	<544E29C70200007800042595@mail.emea.novell.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
In-Reply-To: <545B3F4A.5070808@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.11.14 at 10:28, <tiejun.chen@intel.com> wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -484,6 +484,14 @@ struct xen_domctl_assign_device {
>   typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
> 
> +/* Control whether/how we check and reserve device memory. */
> +struct xen_domctl_set_rdm {
> +    uint32_t  pci_rdmforce;
> +    uint32_t  pci_dev_bitmap;

So this allows for 32 devices; considering that you index the bitmap
by BDF, all this covers are 0000:00:00.0 through 0000:00:03.7.
Hardly enough to cover even a single pass through device (iirc the
range above is fully used by emulated devices). And of course a
much larger bitmap isn't a good solution either.

Nor am I really clear what you need the 32 bits of "pci_rdmforce"
for, nor why this field isn't just being named "force". Without a
comment alongside the fields, it's remaining guesswork anyway
when and how this domctl is to be used. Looking at your change
to intel_iommu_get_reserved_device_memory() the field appears
to be simply redundant.

> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -158,14 +158,14 @@ struct iommu_ops {
>       void (*crash_shutdown)(void);
>       void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int page_count);
>       void (*iotlb_flush_all)(struct domain *d);
> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct domain *, void *);
>       void (*dump_p2m_table)(struct domain *d);
>   };
> 
>   void iommu_suspend(void);
>   void iommu_resume(void);
>   void iommu_crash_shutdown(void);
> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain *, void *);

I don't see why these generic interfaces would need to change;
the only thing that would seem to need changing is the callback
function (and of course the context passed to it).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:12:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmK2r-0007w5-QN; Thu, 06 Nov 2014 10:12:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XmK2q-0007tt-80
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 10:12:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5D/86-09936-F694B545; Thu, 06 Nov 2014 10:11:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415268719!3849431!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9704 invoked from network); 6 Nov 2014 10:11:59 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 10:11:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 06 Nov 2014 10:11:58 +0000
Message-Id: <545B577D0200007800045407@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 06 Nov 2014 10:11:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
In-Reply-To: <545B4325.9000801@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.11.14 at 10:45, <julien.grall@linaro.org> wrote:
> Hi Jan,
> 
> On 05/11/2014 17:15, Jan Beulich wrote:
>>>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>>> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>>>> It also needs Acks from Daniel and Jan.
>>>
>>> This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
>>> required. Would Ian C. ack be enough?
>>
>> Yes, it would.
>>
>>> Anyway, Jan do you have any objection on this patch?
>>
>> As said previously, I'm not particularly happy about it, but I also don't 
> strongly
>> mind it going in in the current shape.
> 
> May I ask what is wrong with the new approach to the a DOMCTL in this patch?
> 
> The DOMCTL has been clearly identify as arm specific (there is "arm" in 
> the name). Therefore it doesn't seem necessary to expose it for other 
> architecture than ARM32 and ARM64.

I didn't say there's anything actively wrong with it, all I said is that
I'm not particularly happy about it: Irrespective of its name it doesn't
look to be really arch-specific in the long run, plus it feels like the
data being set here should rather be specified right at domain
creation, or via a mechanism similar to x86'es HVM parameters (iirc
the value set here can't be changed once the domain got first
unpaused).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:12:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmK2r-0007w5-QN; Thu, 06 Nov 2014 10:12:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XmK2q-0007tt-80
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 10:12:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5D/86-09936-F694B545; Thu, 06 Nov 2014 10:11:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415268719!3849431!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9704 invoked from network); 6 Nov 2014 10:11:59 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 10:11:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 06 Nov 2014 10:11:58 +0000
Message-Id: <545B577D0200007800045407@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 06 Nov 2014 10:11:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
In-Reply-To: <545B4325.9000801@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.11.14 at 10:45, <julien.grall@linaro.org> wrote:
> Hi Jan,
> 
> On 05/11/2014 17:15, Jan Beulich wrote:
>>>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>>> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>>>> It also needs Acks from Daniel and Jan.
>>>
>>> This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
>>> required. Would Ian C. ack be enough?
>>
>> Yes, it would.
>>
>>> Anyway, Jan do you have any objection on this patch?
>>
>> As said previously, I'm not particularly happy about it, but I also don't 
> strongly
>> mind it going in in the current shape.
> 
> May I ask what is wrong with the new approach to the a DOMCTL in this patch?
> 
> The DOMCTL has been clearly identify as arm specific (there is "arm" in 
> the name). Therefore it doesn't seem necessary to expose it for other 
> architecture than ARM32 and ARM64.

I didn't say there's anything actively wrong with it, all I said is that
I'm not particularly happy about it: Irrespective of its name it doesn't
look to be really arch-specific in the long run, plus it feels like the
data being set here should rather be specified right at domain
creation, or via a mechanism similar to x86'es HVM parameters (iirc
the value set here can't be changed once the domain got first
unpaused).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10: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 1XmK3u-0008Gd-DH; Thu, 06 Nov 2014 10:13:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK3s-0008GT-LN
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:04 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	31/59-17735-FA94B545; Thu, 06 Nov 2014 10:13:03 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415268779!10847287!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28411 invoked from network); 6 Nov 2014 10:13:03 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:03 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY66918; Thu, 06 Nov 2014 18:12:57 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:12:47 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:04 +0000
Message-ID: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v4] xen/arm: Add support for Huawei hip04-d01
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details).

Changes from v3:
- change the way regs property is computed for GICv2 (Julien Grall);
- revert order of compaible names for GIC (Julien Grall).

Changes from v2:
- rewrote DTS fix patch (Ian Campbell);
- use is_hip04 macro instead of doing explicit test (Julien Grall);
- do not use quirks to distinguish this platform (Ian Cambell);
- move some GIC constants to C files instead of header (Julien Grall);
- minor changes (Julien Grall).

Changes from v1:
- style (Julien Grall);
- make gicv2_send_SGI faster (Julien Grall);
- cleanup correctly if hip04_smp_init fails (Julien Grall);
- remove quirks using compatibility (Ian Campbell);
- other minor suggestions by Julien Grall.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10: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 1XmK3u-0008Gd-DH; Thu, 06 Nov 2014 10:13:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK3s-0008GT-LN
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:04 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	31/59-17735-FA94B545; Thu, 06 Nov 2014 10:13:03 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415268779!10847287!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28411 invoked from network); 6 Nov 2014 10:13:03 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:03 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY66918; Thu, 06 Nov 2014 18:12:57 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:12:47 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:04 +0000
Message-ID: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v4] xen/arm: Add support for Huawei hip04-d01
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details).

Changes from v3:
- change the way regs property is computed for GICv2 (Julien Grall);
- revert order of compaible names for GIC (Julien Grall).

Changes from v2:
- rewrote DTS fix patch (Ian Campbell);
- use is_hip04 macro instead of doing explicit test (Julien Grall);
- do not use quirks to distinguish this platform (Ian Cambell);
- move some GIC constants to C files instead of header (Julien Grall);
- minor changes (Julien Grall).

Changes from v1:
- style (Julien Grall);
- make gicv2_send_SGI faster (Julien Grall);
- cleanup correctly if hip04_smp_init fails (Julien Grall);
- remove quirks using compatibility (Ian Campbell);
- other minor suggestions by Julien Grall.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmK47-0008JN-Pp; Thu, 06 Nov 2014 10:13:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK46-0008It-0T
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:18 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	61/7A-14727-DB94B545; Thu, 06 Nov 2014 10:13:17 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415268792!10807855!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21150 invoked from network); 6 Nov 2014 10:13:16 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:16 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY66950; Thu, 06 Nov 2014 18:13:07 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:12:56 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:05 +0000
Message-ID: <1415268731-6519-2-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 1/7] xen/device_tree: Add new helper to read
	arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@linaro.org>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
---
 xen/common/device_tree.c      | 13 ++++++++++---
 xen/include/xen/device_tree.h | 11 +++++++++++
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..1a886c0 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -160,14 +160,21 @@ const void *dt_get_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                          const char *name, u32 *out_value)
 {
-    u32 len;
+    return dt_property_read_u32_array(np, name, out_value, 1);
+}
+
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len)
+{
+    u32 len, i;
     const __be32 *val;
 
     val = dt_get_property(np, name, &len);
-    if ( !val || len < sizeof(*out_value) )
+    if ( !val || len < sizeof(*out_value) * out_len )
         return 0;
 
-    *out_value = be32_to_cpup(val);
+    for ( i = 0; i < out_len; i++, val++ )
+        out_value[i] = be32_to_cpup(val);
 
     return 1;
 }
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..629bfb2 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                             const char *name, u32 *out_value);
 /**
+ * dt_property_read_u32_array - Helper to read a u32 array property.
+ * @np: node to get the value
+ * @name: name of the property
+ * @out_value: pointer to return value
+ * @out_len: length of the array
+ *
+ * Return true if get the desired value.
+ */
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len);
+/**
  * dt_property_read_u64 - Helper to read a u64 property.
  * @np: node to get the value
  * @name: name of the property
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmK48-0008Ja-5Z; Thu, 06 Nov 2014 10:13:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK46-0008J7-Nu
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	66/3C-24532-EB94B545; Thu, 06 Nov 2014 10:13:18 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415268793!8436645!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24466 invoked from network); 6 Nov 2014 10:13:16 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:16 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY66963; Thu, 06 Nov 2014 18:13:12 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:04 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:07 +0000
Message-ID: <1415268731-6519-4-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 3/7] xen/arm: Make gic-v2 code handle
	hip04-d01 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

The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.

Use nr_lines to check for maximum irq supported. hip04-d01 support less
interrupts due to some field restriction. Any value above this is already
an error.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 85 ++++++++++++++++++++++++++++++++++++++---------
 xen/arch/arm/gic.c        |  3 +-
 xen/include/asm-arm/gic.h |  4 ++-
 3 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..3cb59dd 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -79,16 +79,25 @@ static struct gic_info gicv2_info;
  * logical CPU numbering. Let's use mapping as returned by the GIC
  * itself
  */
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
 
 /* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+static unsigned int nr_gic_cpu_if = 8;
+static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
+static unsigned int gic_cpu_mask = 0xff;
+
+#define is_hip04() (nr_gic_cpu_if == 16)
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
     writeb_relaxed(val, gicv2.map_dbase + offset);
 }
 
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+    writew_relaxed(val, gicv2.map_dbase + offset);
+}
+
 static inline void writel_gicd(uint32_t val, unsigned int offset)
 {
     writel_relaxed(val, gicv2.map_dbase + offset);
@@ -132,7 +141,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
     cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
     for_each_cpu( cpu, &possible_mask )
     {
-        ASSERT(cpu < NR_GIC_CPU_IF);
+        ASSERT(cpu < nr_gic_cpu_if);
         mask |= per_cpu(gic_cpu_id, cpu);
     }
 
@@ -203,6 +212,15 @@ static unsigned int gicv2_read_irq(void)
     return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
+/* Set target CPU mask (RAZ/WI on uniprocessor) */
+static void gicv2_set_irq_mask(int irq, unsigned int mask)
+{
+    if ( is_hip04() )
+        writew_gicd(mask, GICD_ITARGETSR + irq * 2);
+    else
+        writeb_gicd(mask, GICD_ITARGETSR + irq);
+}
+
 /*
  * needs to be called with a valid cpu_mask, ie each cpu in the mask has
  * already called gic_cpu_init
@@ -230,7 +248,7 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
     writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + irq);
+    gicv2_set_irq_mask(irq, mask);
     /* Set priority */
     writeb_gicd(priority, GICD_IPRIORITYR + irq);
 
@@ -244,16 +262,21 @@ static void __init gicv2_dist_init(void)
     uint32_t gic_cpus;
     int i;
 
-    cpumask = readl_gicd(GICD_ITARGETSR) & 0xff;
-    cpumask |= cpumask << 8;
-    cpumask |= cpumask << 16;
+    cpumask = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* Disable the distributor */
     writel_gicd(0, GICD_CTLR);
 
     type = readl_gicd(GICD_TYPER);
     gicv2_info.nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
-    gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    if ( is_hip04() )
+    {
+        gic_cpus = 16;
+    }
+    else
+    {
+        gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    }
     printk("GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n",
            gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
            (type & GICD_TYPE_SEC) ? ", secure" : "",
@@ -264,8 +287,19 @@ static void __init gicv2_dist_init(void)
         writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
 
     /* Route all global IRQs to this CPU */
-    for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
-        writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    if ( is_hip04() )
+    {
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 2 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 2) * 4);
+    }
+    else
+    {
+        cpumask |= cpumask << 8;
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    }
 
     /* Default priority for global interrupts */
     for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
@@ -285,7 +319,7 @@ static void __cpuinit gicv2_cpu_init(void)
 {
     int i;
 
-    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & 0xff;
+    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
      * even though they are controlled with GICD registers, they must
@@ -366,7 +400,7 @@ static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
         cpumask_and(&online_mask, cpu_mask, &cpu_online_map);
         mask = gicv2_cpu_mask(&online_mask);
         writel_gicd(GICD_SGI_TARGET_LIST |
-                    (mask << GICD_SGI_TARGET_SHIFT) | sgi,
+                    (mask << gicd_sgi_target_shift) | sgi,
                     GICD_SGIR);
         break;
     default:
@@ -581,7 +615,7 @@ static void gicv2_irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_m
     mask = gicv2_cpu_mask(cpu_mask);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + desc->irq);
+    gicv2_set_irq_mask(desc->irq, mask);
 
     spin_unlock(&gicv2.lock);
 }
@@ -684,7 +718,7 @@ const static struct gic_hw_operations gicv2_ops = {
 };
 
 /* Set up the GIC */
-static int __init gicv2_init(struct dt_device_node *node, const void *data)
+static int __init gicv2_init_default(struct dt_device_node *node, const void *data)
 {
     int res;
 
@@ -764,6 +798,15 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
     return 0;
 }
 
+static int __init hip04_gicv2_init(struct dt_device_node *node, const void *data)
+{
+    nr_gic_cpu_if = 16;
+    gicd_sgi_target_shift = 8;
+    gic_cpu_mask = 0xffff;
+
+    return gicv2_init_default(node, data);
+}
+
 static const char * const gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_CORTEX_A15,
@@ -774,9 +817,21 @@ static const char * const gicv2_dt_compat[] __initconst =
 
 DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
         .compatible = gicv2_dt_compat,
-        .init = gicv2_init,
+        .init = gicv2_init_default,
 DT_DEVICE_END
 
+static const char * const hip04_gicv2_dt_compat[] __initconst =
+{
+    DT_COMPAT_GIC_HIP04,
+    NULL
+};
+
+DT_DEVICE_START(hip04_gicv2, "GICv2:", DEVICE_GIC)
+        .compatible = hip04_gicv2_dt_compat,
+        .init = hip04_gicv2_init,
+DT_DEVICE_END
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..8050a65 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
 void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 {
     unsigned int irq;
+    unsigned int max_irq = gic_hw_ops->info->nr_lines;
 
     do  {
         /* Reading IRQ will ACK it */
         irq = gic_hw_ops->read_irq();
 
-        if ( likely(irq >= 16 && irq < 1021) )
+        if ( likely(irq >= 16 && irq < max_irq) )
         {
             local_irq_enable();
             do_IRQ(regs, irq, is_fiq);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..c880867 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -155,10 +155,12 @@
 #define DT_COMPAT_GIC_400            "arm,gic-400"
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
+#define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-intc"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmK47-0008JN-Pp; Thu, 06 Nov 2014 10:13:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK46-0008It-0T
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:18 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	61/7A-14727-DB94B545; Thu, 06 Nov 2014 10:13:17 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415268792!10807855!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21150 invoked from network); 6 Nov 2014 10:13:16 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:16 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY66950; Thu, 06 Nov 2014 18:13:07 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:12:56 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:05 +0000
Message-ID: <1415268731-6519-2-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, zoltan.kiss@huawei.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 1/7] xen/device_tree: Add new helper to read
	arrays from a DTB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Zoltan Kiss <zoltan.kiss@linaro.org>

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
---
 xen/common/device_tree.c      | 13 ++++++++++---
 xen/include/xen/device_tree.h | 11 +++++++++++
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..1a886c0 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -160,14 +160,21 @@ const void *dt_get_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                          const char *name, u32 *out_value)
 {
-    u32 len;
+    return dt_property_read_u32_array(np, name, out_value, 1);
+}
+
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len)
+{
+    u32 len, i;
     const __be32 *val;
 
     val = dt_get_property(np, name, &len);
-    if ( !val || len < sizeof(*out_value) )
+    if ( !val || len < sizeof(*out_value) * out_len )
         return 0;
 
-    *out_value = be32_to_cpup(val);
+    for ( i = 0; i < out_len; i++, val++ )
+        out_value[i] = be32_to_cpup(val);
 
     return 1;
 }
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..629bfb2 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -346,6 +346,17 @@ const struct dt_property *dt_find_property(const struct dt_device_node *np,
 bool_t dt_property_read_u32(const struct dt_device_node *np,
                             const char *name, u32 *out_value);
 /**
+ * dt_property_read_u32_array - Helper to read a u32 array property.
+ * @np: node to get the value
+ * @name: name of the property
+ * @out_value: pointer to return value
+ * @out_len: length of the array
+ *
+ * Return true if get the desired value.
+ */
+bool_t dt_property_read_u32_array(const struct dt_device_node *np,
+                                  const char *name, u32 *out_value, u16 out_len);
+/**
  * dt_property_read_u64 - Helper to read a u64 property.
  * @np: node to get the value
  * @name: name of the property
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmK48-0008Ja-5Z; Thu, 06 Nov 2014 10:13:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK46-0008J7-Nu
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	66/3C-24532-EB94B545; Thu, 06 Nov 2014 10:13:18 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415268793!8436645!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24466 invoked from network); 6 Nov 2014 10:13:16 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:16 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY66963; Thu, 06 Nov 2014 18:13:12 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:04 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:07 +0000
Message-ID: <1415268731-6519-4-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 3/7] xen/arm: Make gic-v2 code handle
	hip04-d01 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

The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.

Use nr_lines to check for maximum irq supported. hip04-d01 support less
interrupts due to some field restriction. Any value above this is already
an error.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 85 ++++++++++++++++++++++++++++++++++++++---------
 xen/arch/arm/gic.c        |  3 +-
 xen/include/asm-arm/gic.h |  4 ++-
 3 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..3cb59dd 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -79,16 +79,25 @@ static struct gic_info gicv2_info;
  * logical CPU numbering. Let's use mapping as returned by the GIC
  * itself
  */
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
 
 /* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+static unsigned int nr_gic_cpu_if = 8;
+static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
+static unsigned int gic_cpu_mask = 0xff;
+
+#define is_hip04() (nr_gic_cpu_if == 16)
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
     writeb_relaxed(val, gicv2.map_dbase + offset);
 }
 
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+    writew_relaxed(val, gicv2.map_dbase + offset);
+}
+
 static inline void writel_gicd(uint32_t val, unsigned int offset)
 {
     writel_relaxed(val, gicv2.map_dbase + offset);
@@ -132,7 +141,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
     cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
     for_each_cpu( cpu, &possible_mask )
     {
-        ASSERT(cpu < NR_GIC_CPU_IF);
+        ASSERT(cpu < nr_gic_cpu_if);
         mask |= per_cpu(gic_cpu_id, cpu);
     }
 
@@ -203,6 +212,15 @@ static unsigned int gicv2_read_irq(void)
     return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
+/* Set target CPU mask (RAZ/WI on uniprocessor) */
+static void gicv2_set_irq_mask(int irq, unsigned int mask)
+{
+    if ( is_hip04() )
+        writew_gicd(mask, GICD_ITARGETSR + irq * 2);
+    else
+        writeb_gicd(mask, GICD_ITARGETSR + irq);
+}
+
 /*
  * needs to be called with a valid cpu_mask, ie each cpu in the mask has
  * already called gic_cpu_init
@@ -230,7 +248,7 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
     writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + irq);
+    gicv2_set_irq_mask(irq, mask);
     /* Set priority */
     writeb_gicd(priority, GICD_IPRIORITYR + irq);
 
@@ -244,16 +262,21 @@ static void __init gicv2_dist_init(void)
     uint32_t gic_cpus;
     int i;
 
-    cpumask = readl_gicd(GICD_ITARGETSR) & 0xff;
-    cpumask |= cpumask << 8;
-    cpumask |= cpumask << 16;
+    cpumask = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* Disable the distributor */
     writel_gicd(0, GICD_CTLR);
 
     type = readl_gicd(GICD_TYPER);
     gicv2_info.nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
-    gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    if ( is_hip04() )
+    {
+        gic_cpus = 16;
+    }
+    else
+    {
+        gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    }
     printk("GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n",
            gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
            (type & GICD_TYPE_SEC) ? ", secure" : "",
@@ -264,8 +287,19 @@ static void __init gicv2_dist_init(void)
         writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
 
     /* Route all global IRQs to this CPU */
-    for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
-        writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    if ( is_hip04() )
+    {
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 2 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 2) * 4);
+    }
+    else
+    {
+        cpumask |= cpumask << 8;
+        cpumask |= cpumask << 16;
+        for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
+            writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+    }
 
     /* Default priority for global interrupts */
     for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
@@ -285,7 +319,7 @@ static void __cpuinit gicv2_cpu_init(void)
 {
     int i;
 
-    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & 0xff;
+    this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & gic_cpu_mask;
 
     /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
      * even though they are controlled with GICD registers, they must
@@ -366,7 +400,7 @@ static void gicv2_send_SGI(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
         cpumask_and(&online_mask, cpu_mask, &cpu_online_map);
         mask = gicv2_cpu_mask(&online_mask);
         writel_gicd(GICD_SGI_TARGET_LIST |
-                    (mask << GICD_SGI_TARGET_SHIFT) | sgi,
+                    (mask << gicd_sgi_target_shift) | sgi,
                     GICD_SGIR);
         break;
     default:
@@ -581,7 +615,7 @@ static void gicv2_irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_m
     mask = gicv2_cpu_mask(cpu_mask);
 
     /* Set target CPU mask (RAZ/WI on uniprocessor) */
-    writeb_gicd(mask, GICD_ITARGETSR + desc->irq);
+    gicv2_set_irq_mask(desc->irq, mask);
 
     spin_unlock(&gicv2.lock);
 }
@@ -684,7 +718,7 @@ const static struct gic_hw_operations gicv2_ops = {
 };
 
 /* Set up the GIC */
-static int __init gicv2_init(struct dt_device_node *node, const void *data)
+static int __init gicv2_init_default(struct dt_device_node *node, const void *data)
 {
     int res;
 
@@ -764,6 +798,15 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
     return 0;
 }
 
+static int __init hip04_gicv2_init(struct dt_device_node *node, const void *data)
+{
+    nr_gic_cpu_if = 16;
+    gicd_sgi_target_shift = 8;
+    gic_cpu_mask = 0xffff;
+
+    return gicv2_init_default(node, data);
+}
+
 static const char * const gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_CORTEX_A15,
@@ -774,9 +817,21 @@ static const char * const gicv2_dt_compat[] __initconst =
 
 DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
         .compatible = gicv2_dt_compat,
-        .init = gicv2_init,
+        .init = gicv2_init_default,
 DT_DEVICE_END
 
+static const char * const hip04_gicv2_dt_compat[] __initconst =
+{
+    DT_COMPAT_GIC_HIP04,
+    NULL
+};
+
+DT_DEVICE_START(hip04_gicv2, "GICv2:", DEVICE_GIC)
+        .compatible = hip04_gicv2_dt_compat,
+        .init = hip04_gicv2_init,
+DT_DEVICE_END
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..8050a65 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -563,12 +563,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
 void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 {
     unsigned int irq;
+    unsigned int max_irq = gic_hw_ops->info->nr_lines;
 
     do  {
         /* Reading IRQ will ACK it */
         irq = gic_hw_ops->read_irq();
 
-        if ( likely(irq >= 16 && irq < 1021) )
+        if ( likely(irq >= 16 && irq < max_irq) )
         {
             local_irq_enable();
             do_IRQ(regs, irq, is_fiq);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..c880867 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -155,10 +155,12 @@
 #define DT_COMPAT_GIC_400            "arm,gic-400"
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
+#define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-intc"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmK4A-0008LC-IC; Thu, 06 Nov 2014 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 <frediano.ziglio@huawei.com>) id 1XmK48-0008Jm-Q2
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:21 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	70/11-19763-0C94B545; Thu, 06 Nov 2014 10:13:20 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415268793!10815795!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7727 invoked from network); 6 Nov 2014 10:13:17 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:17 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY66965; Thu, 06 Nov 2014 18:13:12 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:00 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:06 +0000
Message-ID: <1415268731-6519-3-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 2/7] xen/arm: Implement hip04-d01 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

Add this new platform to Xen.
This platform requires specific code to initialize CPUs.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/hip04.c  | 300 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 301 insertions(+)
 create mode 100644 xen/arch/arm/platforms/hip04.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8f47c16..d0b2d99 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_64) += seattle.o
+obj-$(CONFIG_ARM_32) += hip04.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
new file mode 100644
index 0000000..f25282c
--- /dev/null
+++ b/xen/arch/arm/platforms/hip04.c
@@ -0,0 +1,300 @@
+/*
+ * xen/arch/arm/platforms/hip04.c
+ *
+ * HiSilicon HIP-04 D01 board
+ *
+ * Copyright (c) 2012-2013 Hisilicon Ltd.
+ * Copyright (c) 2012-2013 Linaro Ltd.
+ * Copyright (c) 2014 Huawei Tech. Co., Ltd.
+ *
+ * Author: Frediano Ziglio <frediano.ziglio@huawei.com>
+ *
+ * Original code from Linux kernel arch/arm/mach-hisi/hisilicon.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/platform.h>
+#include <xen/mm.h>
+#include <xen/vmap.h>
+#include <asm/io.h>
+#include <asm/gic.h>
+#include <xen/delay.h>
+
+#define CORE_RESET_BIT(x)            (1 << x)
+#define NEON_RESET_BIT(x)            (1 << (x + 4))
+#define CORE_DEBUG_RESET_BIT(x)      (1 << (x + 9))
+#define CLUSTER_L2_RESET_BIT         (1 << 8)
+#define CLUSTER_DEBUG_RESET_BIT      (1 << 13)
+
+#define CLUSTER_L2_RESET_STATUS      (1 << 8)
+#define CLUSTER_DEBUG_RESET_STATUS   (1 << 13)
+
+#define SC_CPU_RESET_DREQ(x)         (0x524 + (x << 3))    /* unreset */
+#define SC_CPU_RESET_STATUS(x)       (0x1520 + (x << 3))
+
+#define FAB_SF_MODE                  0x0c
+
+#define HIP04_MAX_CLUSTERS           4
+#define HIP04_MAX_CPUS_PER_CLUSTER   4
+
+struct hip04_secondary_cpu_data
+{
+    u32 bootwrapper_phys;
+    u32 bootwrapper_size;
+    u32 bootwrapper_magic;
+    u32 relocation_entry;
+    u32 relocation_size;
+};
+
+static void __iomem *relocation, *sysctrl, *fabric, *gb2;
+static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
+static struct hip04_secondary_cpu_data hip04_boot;
+
+static void hip04_reset(void)
+{
+    unsigned long data;
+
+    data = readl_relaxed(gb2);
+    writel_relaxed(data & ~0x4000000u, gb2);
+
+    mdelay(10);
+}
+
+static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
+{
+    unsigned long data;
+
+    data = readl_relaxed(fabric + FAB_SF_MODE);
+    if ( on )
+        data |= 1 << cluster;
+    else
+        data &= ~(1 << cluster);
+    writel_relaxed(data, fabric + FAB_SF_MODE);
+    while ( 1 )
+    {
+        if ( data == readl_relaxed(fabric + FAB_SF_MODE) )
+            break;
+    }
+}
+
+static bool __init hip04_cpu_table_init(void)
+{
+    unsigned int mpidr, cpu, cluster;
+
+    mpidr = cpu_logical_map(smp_processor_id());
+    cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+    cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+    if ( cluster >= HIP04_MAX_CLUSTERS ||
+        cpu >= HIP04_MAX_CPUS_PER_CLUSTER )
+    {
+        printk(XENLOG_ERR "%s: boot CPU is out of bound!\n", __func__);
+        return false;
+    }
+
+    hip04_set_snoop_filter(cluster, 1);
+    hip04_cpu_table[cluster][cpu] = 1;
+    return true;
+}
+
+static bool hip04_cluster_down(unsigned int cluster)
+{
+    int i;
+
+    for ( i = 0; i < HIP04_MAX_CPUS_PER_CLUSTER; i++ )
+        if ( hip04_cpu_table[cluster][i] )
+            return false;
+    return true;
+}
+
+static void hip04_cluster_up(unsigned int cluster)
+{
+    unsigned long data, mask;
+
+    if ( !hip04_cluster_down(cluster) )
+        return;
+
+    data = CLUSTER_L2_RESET_BIT | CLUSTER_DEBUG_RESET_BIT;
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+    do {
+        mask = CLUSTER_L2_RESET_STATUS | \
+               CLUSTER_DEBUG_RESET_STATUS;
+        data = readl_relaxed(sysctrl + \
+                     SC_CPU_RESET_STATUS(cluster));
+    } while ( data & mask );
+    hip04_set_snoop_filter(cluster, 1);
+}
+
+static void __init hip04_iounmap(void __iomem **p)
+{
+    iounmap(*p);
+    *p = NULL;
+}
+
+static int __init hip04_smp_init(void)
+{
+    const struct dt_device_node *np, *np_fab, *bw;
+    const char *msg;
+    u64 addr, size;
+
+    np = dt_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
+    msg = "hisilicon,sysctrl missing in DT\n";
+    if ( !np )
+        goto err;
+
+    np_fab = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-fabric");
+    msg = "hisilicon,hip04-fabric missing in DT\n";
+    if ( !np_fab )
+        goto err;
+
+    if ( !dt_property_read_u32(np, "bootwrapper-phys",
+                               &hip04_boot.bootwrapper_phys) ) {
+        u32 boot_method[4];
+        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-bootwrapper");
+        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
+        if ( !bw )
+            goto err;
+
+        msg = "failed to get boot-method\n";
+        if ( !dt_property_read_u32_array(bw, "boot-method", boot_method, 4) )
+            goto err;
+        hip04_boot.bootwrapper_phys = boot_method[0];
+        hip04_boot.bootwrapper_size = boot_method[1];
+        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
+        hip04_boot.relocation_entry = boot_method[2];
+        hip04_boot.relocation_size = boot_method[3];
+    }
+    else
+    {
+        msg = "failed to get bootwrapper-size\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-size",
+                                   &hip04_boot.bootwrapper_size) )
+            goto err;
+
+        msg = "failed to get bootwrapper-magic\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-magic",
+                                   &hip04_boot.bootwrapper_magic) )
+            goto err;
+
+        msg = "failed to get relocation-entry\n";
+        if ( !dt_property_read_u32(np, "relocation-entry",
+                                   &hip04_boot.relocation_entry) )
+            goto err;
+
+        msg = "failed to get relocation-size\n";
+        if ( !dt_property_read_u32(np, "relocation-size",
+                                   &hip04_boot.relocation_size) )
+            goto err;
+    }
+
+    relocation = ioremap_nocache(hip04_boot.relocation_entry,
+                                 hip04_boot.relocation_size);
+    msg = "failed to map relocation space\n";
+    if ( !relocation )
+        goto err;
+
+    msg = "Error in \"hisilicon,sysctrl\"\n";
+    if ( dt_device_get_address(np, 0, &addr, &size) )
+        goto err;
+    sysctrl = ioremap_nocache(addr, size);
+    if ( !sysctrl )
+        goto err;
+
+    msg = "Error in \"hisilicon,hip04-fabric\"\n";
+    if ( dt_device_get_address(np_fab, 0, &addr, &size) )
+        goto err;
+    fabric = ioremap_nocache(addr, size);
+    if ( !fabric )
+        goto err;
+
+    msg = "Error mapping GB2\n";
+    gb2 = ioremap_nocache(0xe4002000, 0x1000);
+    if ( !gb2 )
+        goto err;
+
+    msg = "Error initializing SMP table\n";
+    if ( !hip04_cpu_table_init() )
+        goto err;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    return 0;
+
+err:
+    hip04_iounmap(&relocation);
+    hip04_iounmap(&sysctrl);
+    hip04_iounmap(&fabric);
+    hip04_iounmap(&gb2);
+
+    printk("%s", msg);
+    return -ENXIO;
+}
+
+static int hip04_cpu_up(int cpu)
+{
+    unsigned int cluster;
+    unsigned long data;
+
+    cluster = cpu / HIP04_MAX_CPUS_PER_CLUSTER;
+    cpu %= HIP04_MAX_CPUS_PER_CLUSTER;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    hip04_cluster_up(cluster);
+
+    hip04_cpu_table[cluster][cpu]++;
+
+    data = CORE_RESET_BIT(cpu) | NEON_RESET_BIT(cpu) | \
+           CORE_DEBUG_RESET_BIT(cpu);
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+
+    return cpu_up_send_sgi(cpu);
+}
+
+
+static const char * const hip04_dt_compat[] __initconst =
+{
+    "hisilicon,hip04-d01",
+    NULL
+};
+
+static const struct dt_device_match hip04_blacklist_dev[] __initconst =
+{
+    /* Hardware power management */
+    DT_MATCH_COMPATIBLE("hisilicon,sysctrl"),
+    DT_MATCH_COMPATIBLE("hisilicon,hip04-fabric"),
+    { /* sentinel */ },
+};
+
+
+PLATFORM_START(hip04, "HISILICON HIP04")
+    .compatible = hip04_dt_compat,
+    .smp_init = hip04_smp_init,
+    .cpu_up = hip04_cpu_up,
+    .reset = hip04_reset,
+    .blacklist_dev = hip04_blacklist_dev,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmK4A-0008LC-IC; Thu, 06 Nov 2014 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 <frediano.ziglio@huawei.com>) id 1XmK48-0008Jm-Q2
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:21 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	70/11-19763-0C94B545; Thu, 06 Nov 2014 10:13:20 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415268793!10815795!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7727 invoked from network); 6 Nov 2014 10:13:17 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:17 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY66965; Thu, 06 Nov 2014 18:13:12 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:00 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:06 +0000
Message-ID: <1415268731-6519-3-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 2/7] xen/arm: Implement hip04-d01 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

Add this new platform to Xen.
This platform requires specific code to initialize CPUs.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/hip04.c  | 300 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 301 insertions(+)
 create mode 100644 xen/arch/arm/platforms/hip04.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8f47c16..d0b2d99 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_64) += seattle.o
+obj-$(CONFIG_ARM_32) += hip04.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
diff --git a/xen/arch/arm/platforms/hip04.c b/xen/arch/arm/platforms/hip04.c
new file mode 100644
index 0000000..f25282c
--- /dev/null
+++ b/xen/arch/arm/platforms/hip04.c
@@ -0,0 +1,300 @@
+/*
+ * xen/arch/arm/platforms/hip04.c
+ *
+ * HiSilicon HIP-04 D01 board
+ *
+ * Copyright (c) 2012-2013 Hisilicon Ltd.
+ * Copyright (c) 2012-2013 Linaro Ltd.
+ * Copyright (c) 2014 Huawei Tech. Co., Ltd.
+ *
+ * Author: Frediano Ziglio <frediano.ziglio@huawei.com>
+ *
+ * Original code from Linux kernel arch/arm/mach-hisi/hisilicon.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/platform.h>
+#include <xen/mm.h>
+#include <xen/vmap.h>
+#include <asm/io.h>
+#include <asm/gic.h>
+#include <xen/delay.h>
+
+#define CORE_RESET_BIT(x)            (1 << x)
+#define NEON_RESET_BIT(x)            (1 << (x + 4))
+#define CORE_DEBUG_RESET_BIT(x)      (1 << (x + 9))
+#define CLUSTER_L2_RESET_BIT         (1 << 8)
+#define CLUSTER_DEBUG_RESET_BIT      (1 << 13)
+
+#define CLUSTER_L2_RESET_STATUS      (1 << 8)
+#define CLUSTER_DEBUG_RESET_STATUS   (1 << 13)
+
+#define SC_CPU_RESET_DREQ(x)         (0x524 + (x << 3))    /* unreset */
+#define SC_CPU_RESET_STATUS(x)       (0x1520 + (x << 3))
+
+#define FAB_SF_MODE                  0x0c
+
+#define HIP04_MAX_CLUSTERS           4
+#define HIP04_MAX_CPUS_PER_CLUSTER   4
+
+struct hip04_secondary_cpu_data
+{
+    u32 bootwrapper_phys;
+    u32 bootwrapper_size;
+    u32 bootwrapper_magic;
+    u32 relocation_entry;
+    u32 relocation_size;
+};
+
+static void __iomem *relocation, *sysctrl, *fabric, *gb2;
+static int hip04_cpu_table[HIP04_MAX_CLUSTERS][HIP04_MAX_CPUS_PER_CLUSTER];
+static struct hip04_secondary_cpu_data hip04_boot;
+
+static void hip04_reset(void)
+{
+    unsigned long data;
+
+    data = readl_relaxed(gb2);
+    writel_relaxed(data & ~0x4000000u, gb2);
+
+    mdelay(10);
+}
+
+static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
+{
+    unsigned long data;
+
+    data = readl_relaxed(fabric + FAB_SF_MODE);
+    if ( on )
+        data |= 1 << cluster;
+    else
+        data &= ~(1 << cluster);
+    writel_relaxed(data, fabric + FAB_SF_MODE);
+    while ( 1 )
+    {
+        if ( data == readl_relaxed(fabric + FAB_SF_MODE) )
+            break;
+    }
+}
+
+static bool __init hip04_cpu_table_init(void)
+{
+    unsigned int mpidr, cpu, cluster;
+
+    mpidr = cpu_logical_map(smp_processor_id());
+    cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+    cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+    if ( cluster >= HIP04_MAX_CLUSTERS ||
+        cpu >= HIP04_MAX_CPUS_PER_CLUSTER )
+    {
+        printk(XENLOG_ERR "%s: boot CPU is out of bound!\n", __func__);
+        return false;
+    }
+
+    hip04_set_snoop_filter(cluster, 1);
+    hip04_cpu_table[cluster][cpu] = 1;
+    return true;
+}
+
+static bool hip04_cluster_down(unsigned int cluster)
+{
+    int i;
+
+    for ( i = 0; i < HIP04_MAX_CPUS_PER_CLUSTER; i++ )
+        if ( hip04_cpu_table[cluster][i] )
+            return false;
+    return true;
+}
+
+static void hip04_cluster_up(unsigned int cluster)
+{
+    unsigned long data, mask;
+
+    if ( !hip04_cluster_down(cluster) )
+        return;
+
+    data = CLUSTER_L2_RESET_BIT | CLUSTER_DEBUG_RESET_BIT;
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+    do {
+        mask = CLUSTER_L2_RESET_STATUS | \
+               CLUSTER_DEBUG_RESET_STATUS;
+        data = readl_relaxed(sysctrl + \
+                     SC_CPU_RESET_STATUS(cluster));
+    } while ( data & mask );
+    hip04_set_snoop_filter(cluster, 1);
+}
+
+static void __init hip04_iounmap(void __iomem **p)
+{
+    iounmap(*p);
+    *p = NULL;
+}
+
+static int __init hip04_smp_init(void)
+{
+    const struct dt_device_node *np, *np_fab, *bw;
+    const char *msg;
+    u64 addr, size;
+
+    np = dt_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
+    msg = "hisilicon,sysctrl missing in DT\n";
+    if ( !np )
+        goto err;
+
+    np_fab = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-fabric");
+    msg = "hisilicon,hip04-fabric missing in DT\n";
+    if ( !np_fab )
+        goto err;
+
+    if ( !dt_property_read_u32(np, "bootwrapper-phys",
+                               &hip04_boot.bootwrapper_phys) ) {
+        u32 boot_method[4];
+        bw = dt_find_compatible_node(NULL, NULL, "hisilicon,hip04-bootwrapper");
+        msg = "hisilicon,hip04-bootwrapper missing in DT\n";
+        if ( !bw )
+            goto err;
+
+        msg = "failed to get boot-method\n";
+        if ( !dt_property_read_u32_array(bw, "boot-method", boot_method, 4) )
+            goto err;
+        hip04_boot.bootwrapper_phys = boot_method[0];
+        hip04_boot.bootwrapper_size = boot_method[1];
+        hip04_boot.bootwrapper_magic = 0xa5a5a5a5;
+        hip04_boot.relocation_entry = boot_method[2];
+        hip04_boot.relocation_size = boot_method[3];
+    }
+    else
+    {
+        msg = "failed to get bootwrapper-size\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-size",
+                                   &hip04_boot.bootwrapper_size) )
+            goto err;
+
+        msg = "failed to get bootwrapper-magic\n";
+        if ( !dt_property_read_u32(np, "bootwrapper-magic",
+                                   &hip04_boot.bootwrapper_magic) )
+            goto err;
+
+        msg = "failed to get relocation-entry\n";
+        if ( !dt_property_read_u32(np, "relocation-entry",
+                                   &hip04_boot.relocation_entry) )
+            goto err;
+
+        msg = "failed to get relocation-size\n";
+        if ( !dt_property_read_u32(np, "relocation-size",
+                                   &hip04_boot.relocation_size) )
+            goto err;
+    }
+
+    relocation = ioremap_nocache(hip04_boot.relocation_entry,
+                                 hip04_boot.relocation_size);
+    msg = "failed to map relocation space\n";
+    if ( !relocation )
+        goto err;
+
+    msg = "Error in \"hisilicon,sysctrl\"\n";
+    if ( dt_device_get_address(np, 0, &addr, &size) )
+        goto err;
+    sysctrl = ioremap_nocache(addr, size);
+    if ( !sysctrl )
+        goto err;
+
+    msg = "Error in \"hisilicon,hip04-fabric\"\n";
+    if ( dt_device_get_address(np_fab, 0, &addr, &size) )
+        goto err;
+    fabric = ioremap_nocache(addr, size);
+    if ( !fabric )
+        goto err;
+
+    msg = "Error mapping GB2\n";
+    gb2 = ioremap_nocache(0xe4002000, 0x1000);
+    if ( !gb2 )
+        goto err;
+
+    msg = "Error initializing SMP table\n";
+    if ( !hip04_cpu_table_init() )
+        goto err;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    return 0;
+
+err:
+    hip04_iounmap(&relocation);
+    hip04_iounmap(&sysctrl);
+    hip04_iounmap(&fabric);
+    hip04_iounmap(&gb2);
+
+    printk("%s", msg);
+    return -ENXIO;
+}
+
+static int hip04_cpu_up(int cpu)
+{
+    unsigned int cluster;
+    unsigned long data;
+
+    cluster = cpu / HIP04_MAX_CPUS_PER_CLUSTER;
+    cpu %= HIP04_MAX_CPUS_PER_CLUSTER;
+
+    writel_relaxed(hip04_boot.bootwrapper_phys, relocation);
+    writel_relaxed(hip04_boot.bootwrapper_magic, relocation + 4);
+    writel_relaxed(__pa(init_secondary), relocation + 8);
+    writel_relaxed(0, relocation + 12);
+
+    hip04_cluster_up(cluster);
+
+    hip04_cpu_table[cluster][cpu]++;
+
+    data = CORE_RESET_BIT(cpu) | NEON_RESET_BIT(cpu) | \
+           CORE_DEBUG_RESET_BIT(cpu);
+    writel_relaxed(data, sysctrl + SC_CPU_RESET_DREQ(cluster));
+
+    return cpu_up_send_sgi(cpu);
+}
+
+
+static const char * const hip04_dt_compat[] __initconst =
+{
+    "hisilicon,hip04-d01",
+    NULL
+};
+
+static const struct dt_device_match hip04_blacklist_dev[] __initconst =
+{
+    /* Hardware power management */
+    DT_MATCH_COMPATIBLE("hisilicon,sysctrl"),
+    DT_MATCH_COMPATIBLE("hisilicon,hip04-fabric"),
+    { /* sentinel */ },
+};
+
+
+PLATFORM_START(hip04, "HISILICON HIP04")
+    .compatible = hip04_dt_compat,
+    .smp_init = hip04_smp_init,
+    .cpu_up = hip04_cpu_up,
+    .reset = hip04_reset,
+    .blacklist_dev = hip04_blacklist_dev,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmK4D-0008Ne-86; Thu, 06 Nov 2014 10:13:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK4C-0008Mg-8i
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:24 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	15/6F-09842-3C94B545; Thu, 06 Nov 2014 10:13:23 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415268799!11877987!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10239 invoked from network); 6 Nov 2014 10:13:22 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:22 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY66982; Thu, 06 Nov 2014 18:13:17 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:09 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:08 +0000
Message-ID: <1415268731-6519-5-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 4/7] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This name can appear in some Linux kernel repos. Not very fortunate,
but to avoid others spending an hour to spot that few characters
difference it worth to work around it.

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 1 +
 xen/include/asm-arm/gic.h | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 3cb59dd..9ab30ce 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -823,6 +823,7 @@ DT_DEVICE_END
 static const char * const hip04_gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_HIP04,
+    DT_COMPAT_GIC_HIP04_2,
     NULL
 };
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index c880867..f8ba227 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -156,11 +156,13 @@
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
 #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-intc"
+#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-gic"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmK4D-0008Ne-86; Thu, 06 Nov 2014 10:13:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK4C-0008Mg-8i
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:24 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	15/6F-09842-3C94B545; Thu, 06 Nov 2014 10:13:23 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415268799!11877987!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10239 invoked from network); 6 Nov 2014 10:13:22 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:22 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY66982; Thu, 06 Nov 2014 18:13:17 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:09 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:08 +0000
Message-ID: <1415268731-6519-5-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 4/7] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This name can appear in some Linux kernel repos. Not very fortunate,
but to avoid others spending an hour to spot that few characters
difference it worth to work around it.

Signed-off-by: Zoltan Kiss <zoltan.kiss@huawei.com>
---
 xen/arch/arm/gic-v2.c     | 1 +
 xen/include/asm-arm/gic.h | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 3cb59dd..9ab30ce 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -823,6 +823,7 @@ DT_DEVICE_END
 static const char * const hip04_gicv2_dt_compat[] __initconst =
 {
     DT_COMPAT_GIC_HIP04,
+    DT_COMPAT_GIC_HIP04_2,
     NULL
 };
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index c880867..f8ba227 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -156,11 +156,13 @@
 #define DT_COMPAT_GIC_CORTEX_A15     "arm,cortex-a15-gic"
 #define DT_COMPAT_GIC_CORTEX_A7      "arm,cortex-a7-gic"
 #define DT_COMPAT_GIC_HIP04          "hisilicon,hip04-intc"
+#define DT_COMPAT_GIC_HIP04_2        "hisilicon,hip04-gic"
 
 #define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
                         DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
-                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
+                        DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
 
 #define DT_COMPAT_GIC_V3             "arm,gic-v3"
 
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmK4O-0008Td-NG; Thu, 06 Nov 2014 10:13:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK4L-0008SJ-QB
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:35 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	8B/70-18267-DC94B545; Thu, 06 Nov 2014 10:13:33 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415268808!10802005!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27421 invoked from network); 6 Nov 2014 10:13:32 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:32 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY67018; Thu, 06 Nov 2014 18:13:27 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:18 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:10 +0000
Message-ID: <1415268731-6519-7-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 6/7] xen/arm: Force dom0 to use normal GICv2
	driver on Hip04 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

Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index d766438..2f6bbd5 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -641,6 +641,12 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOENT);
     }
 
+    if ( is_hip04() )
+    {
+        compatible = DT_COMPAT_GIC_CORTEX_A15;
+        len = strlen((char*) compatible) + 1;
+    }
+
     res = fdt_begin_node(fdt, "interrupt-controller");
     if ( res )
         return res;
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmK4O-0008Td-NG; Thu, 06 Nov 2014 10:13:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK4L-0008SJ-QB
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:35 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	8B/70-18267-DC94B545; Thu, 06 Nov 2014 10:13:33 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415268808!10802005!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27421 invoked from network); 6 Nov 2014 10:13:32 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:32 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY67018; Thu, 06 Nov 2014 18:13:27 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:18 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:10 +0000
Message-ID: <1415268731-6519-7-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 6/7] xen/arm: Force dom0 to use normal GICv2
	driver on Hip04 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

Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index d766438..2f6bbd5 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -641,6 +641,12 @@ static int gicv2_make_dt_node(const struct domain *d,
         return -FDT_ERR_XEN(ENOENT);
     }
 
+    if ( is_hip04() )
+    {
+        compatible = DT_COMPAT_GIC_CORTEX_A15;
+        len = strlen((char*) compatible) + 1;
+    }
+
     res = fdt_begin_node(fdt, "interrupt-controller");
     if ( res )
         return res;
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10: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 1XmK4T-00005G-5E; Thu, 06 Nov 2014 10:13:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK4R-0008V7-4m
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:39 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	02/C0-02699-2D94B545; Thu, 06 Nov 2014 10:13:38 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415268803!11770096!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20009 invoked from network); 6 Nov 2014 10:13:37 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:37 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY67004; Thu, 06 Nov 2014 18:13:22 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:13 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:09 +0000
Message-ID: <1415268731-6519-6-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 5/7] xen/arm: handle GICH register changes
	for hip04-d01 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

The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 9ab30ce..d766438 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -61,6 +61,9 @@
 #define GICH_V2_VMCR_PRIORITY_MASK   0x1f
 #define GICH_V2_VMCR_PRIORITY_SHIFT  27
 
+#define HIP04_GICH_APR  0x70
+#define HIP04_GICH_LR   0x80
+
 /* Global state */
 static struct {
     paddr_t dbase;            /* Address of distributor registers */
@@ -85,6 +88,8 @@ static DEFINE_PER_CPU(u16, gic_cpu_id);
 static unsigned int nr_gic_cpu_if = 8;
 static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
 static unsigned int gic_cpu_mask = 0xff;
+static unsigned int gich_apr = GICH_APR;
+static unsigned int gich_lr = GICH_LR;
 
 #define is_hip04() (nr_gic_cpu_if == 16)
 
@@ -157,9 +162,9 @@ static void gicv2_save_state(struct vcpu *v)
      * accessed simultaneously by another pCPU.
      */
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        v->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+        v->arch.gic.v2.lr[i] = readl_gich(gich_lr + i * 4);
 
-    v->arch.gic.v2.apr = readl_gich(GICH_APR);
+    v->arch.gic.v2.apr = readl_gich(gich_apr);
     v->arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
     /* Disable until next VCPU scheduled */
     writel_gich(0, GICH_HCR);
@@ -170,9 +175,9 @@ static void gicv2_restore_state(const struct vcpu *v)
     int i;
 
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        writel_gich(v->arch.gic.v2.lr[i], GICH_LR + i * 4);
+        writel_gich(v->arch.gic.v2.lr[i], gich_lr + i * 4);
 
-    writel_gich(v->arch.gic.v2.apr, GICH_APR);
+    writel_gich(v->arch.gic.v2.apr, gich_apr);
     writel_gich(v->arch.gic.v2.vmcr, GICH_VMCR);
     writel_gich(GICH_HCR_EN, GICH_HCR);
 }
@@ -185,7 +190,7 @@ static void gicv2_dump_state(const struct vcpu *v)
     {
         for ( i = 0; i < gicv2_info.nr_lrs; i++ )
             printk("   HW_LR[%d]=%x\n", i,
-                   readl_gich(GICH_LR + i * 4));
+                   readl_gich(gich_lr + i * 4));
     }
     else
     {
@@ -439,12 +444,12 @@ static void gicv2_update_lr(int lr, const struct pending_irq *p,
                             << GICH_V2_LR_PHYSICAL_SHIFT);
     }
 
-    writel_gich(lr_reg, GICH_LR + lr * 4);
+    writel_gich(lr_reg, gich_lr + lr * 4);
 }
 
 static void gicv2_clear_lr(int lr)
 {
-    writel_gich(0, GICH_LR + lr * 4);
+    writel_gich(0, gich_lr + lr * 4);
 }
 
 static int gicv2v_setup(struct domain *d)
@@ -494,7 +499,7 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 {
     uint32_t lrv;
 
-    lrv          = readl_gich(GICH_LR + lr * 4);
+    lrv          = readl_gich(gich_lr + lr * 4);
     lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) & GICH_V2_LR_PHYSICAL_MASK;
     lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
     lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & GICH_V2_LR_PRIORITY_MASK;
@@ -517,7 +522,7 @@ static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
                                        << GICH_V2_LR_HW_SHIFT)  |
           ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) << GICH_V2_LR_GRP_SHIFT) );
 
-    writel_gich(lrv, GICH_LR + lr * 4);
+    writel_gich(lrv, gich_lr + lr * 4);
 }
 
 static void gicv2_hcr_status(uint32_t flag, bool_t status)
@@ -540,7 +545,7 @@ static unsigned int gicv2_read_vmcr_priority(void)
 
 static unsigned int gicv2_read_apr(int apr_reg)
 {
-   return readl_gich(GICH_APR);
+   return readl_gich(gich_apr);
 }
 
 static void gicv2_irq_enable(struct irq_desc *desc)
@@ -803,6 +808,8 @@ static int __init hip04_gicv2_init(struct dt_device_node *node, const void *data
     nr_gic_cpu_if = 16;
     gicd_sgi_target_shift = 8;
     gic_cpu_mask = 0xffff;
+    gich_apr = HIP04_GICH_APR;
+    gich_lr = HIP04_GICH_LR;
 
     return gicv2_init_default(node, data);
 }
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10: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 1XmK4T-00005G-5E; Thu, 06 Nov 2014 10:13:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK4R-0008V7-4m
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:39 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	02/C0-02699-2D94B545; Thu, 06 Nov 2014 10:13:38 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415268803!11770096!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20009 invoked from network); 6 Nov 2014 10:13:37 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:37 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY67004; Thu, 06 Nov 2014 18:13:22 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:13 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:09 +0000
Message-ID: <1415268731-6519-6-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 5/7] xen/arm: handle GICH register changes
	for hip04-d01 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

The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 9ab30ce..d766438 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -61,6 +61,9 @@
 #define GICH_V2_VMCR_PRIORITY_MASK   0x1f
 #define GICH_V2_VMCR_PRIORITY_SHIFT  27
 
+#define HIP04_GICH_APR  0x70
+#define HIP04_GICH_LR   0x80
+
 /* Global state */
 static struct {
     paddr_t dbase;            /* Address of distributor registers */
@@ -85,6 +88,8 @@ static DEFINE_PER_CPU(u16, gic_cpu_id);
 static unsigned int nr_gic_cpu_if = 8;
 static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
 static unsigned int gic_cpu_mask = 0xff;
+static unsigned int gich_apr = GICH_APR;
+static unsigned int gich_lr = GICH_LR;
 
 #define is_hip04() (nr_gic_cpu_if == 16)
 
@@ -157,9 +162,9 @@ static void gicv2_save_state(struct vcpu *v)
      * accessed simultaneously by another pCPU.
      */
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        v->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+        v->arch.gic.v2.lr[i] = readl_gich(gich_lr + i * 4);
 
-    v->arch.gic.v2.apr = readl_gich(GICH_APR);
+    v->arch.gic.v2.apr = readl_gich(gich_apr);
     v->arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
     /* Disable until next VCPU scheduled */
     writel_gich(0, GICH_HCR);
@@ -170,9 +175,9 @@ static void gicv2_restore_state(const struct vcpu *v)
     int i;
 
     for ( i = 0; i < gicv2_info.nr_lrs; i++ )
-        writel_gich(v->arch.gic.v2.lr[i], GICH_LR + i * 4);
+        writel_gich(v->arch.gic.v2.lr[i], gich_lr + i * 4);
 
-    writel_gich(v->arch.gic.v2.apr, GICH_APR);
+    writel_gich(v->arch.gic.v2.apr, gich_apr);
     writel_gich(v->arch.gic.v2.vmcr, GICH_VMCR);
     writel_gich(GICH_HCR_EN, GICH_HCR);
 }
@@ -185,7 +190,7 @@ static void gicv2_dump_state(const struct vcpu *v)
     {
         for ( i = 0; i < gicv2_info.nr_lrs; i++ )
             printk("   HW_LR[%d]=%x\n", i,
-                   readl_gich(GICH_LR + i * 4));
+                   readl_gich(gich_lr + i * 4));
     }
     else
     {
@@ -439,12 +444,12 @@ static void gicv2_update_lr(int lr, const struct pending_irq *p,
                             << GICH_V2_LR_PHYSICAL_SHIFT);
     }
 
-    writel_gich(lr_reg, GICH_LR + lr * 4);
+    writel_gich(lr_reg, gich_lr + lr * 4);
 }
 
 static void gicv2_clear_lr(int lr)
 {
-    writel_gich(0, GICH_LR + lr * 4);
+    writel_gich(0, gich_lr + lr * 4);
 }
 
 static int gicv2v_setup(struct domain *d)
@@ -494,7 +499,7 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 {
     uint32_t lrv;
 
-    lrv          = readl_gich(GICH_LR + lr * 4);
+    lrv          = readl_gich(gich_lr + lr * 4);
     lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) & GICH_V2_LR_PHYSICAL_MASK;
     lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
     lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & GICH_V2_LR_PRIORITY_MASK;
@@ -517,7 +522,7 @@ static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
                                        << GICH_V2_LR_HW_SHIFT)  |
           ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) << GICH_V2_LR_GRP_SHIFT) );
 
-    writel_gich(lrv, GICH_LR + lr * 4);
+    writel_gich(lrv, gich_lr + lr * 4);
 }
 
 static void gicv2_hcr_status(uint32_t flag, bool_t status)
@@ -540,7 +545,7 @@ static unsigned int gicv2_read_vmcr_priority(void)
 
 static unsigned int gicv2_read_apr(int apr_reg)
 {
-   return readl_gich(GICH_APR);
+   return readl_gich(gich_apr);
 }
 
 static void gicv2_irq_enable(struct irq_desc *desc)
@@ -803,6 +808,8 @@ static int __init hip04_gicv2_init(struct dt_device_node *node, const void *data
     nr_gic_cpu_if = 16;
     gicd_sgi_target_shift = 8;
     gic_cpu_mask = 0xffff;
+    gich_apr = HIP04_GICH_APR;
+    gich_lr = HIP04_GICH_LR;
 
     return gicv2_init_default(node, data);
 }
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10: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 1XmK4T-00005q-Ki; Thu, 06 Nov 2014 10:13:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK4R-0008VO-Na
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:39 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	DE/29-02954-3D94B545; Thu, 06 Nov 2014 10:13:39 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415268814!11777768!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19954 invoked from network); 6 Nov 2014 10:13:38 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:38 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWS31148; Thu, 06 Nov 2014 18:13:33 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:22 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:11 +0000
Message-ID: <1415268731-6519-8-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020209.545B49CD.00F1, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d2fef5729ecab7e5c9cbbbd0b97b1760
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 7/7] xen/arm: Handle translated addresses for
	hardware domains in GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Translated address could have an offset applied to them.
Replicate same value for device node to avoid improper address
computation in the OS.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2f6bbd5..c2666df 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -631,7 +631,7 @@ static int gicv2_make_dt_node(const struct domain *d,
     const struct dt_device_node *gic = dt_interrupt_controller;
     const void *compatible = NULL;
     u32 len;
-    __be32 *new_cells, *tmp;
+    const __be32 *regs;
     int res = 0;
 
     compatible = dt_get_property(gic, "compatible", &len);
@@ -664,18 +664,18 @@ static int gicv2_make_dt_node(const struct domain *d,
     if ( res )
         return res;
 
+    /* copy GICC and GICD regions */
+    regs = dt_get_property(gic, "reg", &len);
+    if ( !regs )
+    {
+        dprintk(XENLOG_ERR, "Can't find reg property for the gic node\n");
+        return -FDT_ERR_XEN(ENOENT);
+    }
+
     len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
     len *= 2; /* GIC has two memory regions: Distributor + CPU interface */
-    new_cells = xzalloc_bytes(len);
-    if ( new_cells == NULL )
-        return -FDT_ERR_XEN(ENOMEM);
-
-    tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
 
-    res = fdt_property(fdt, "reg", new_cells, len);
-    xfree(new_cells);
+    res = fdt_property(fdt, "reg", regs, len);
 
     return res;
 }
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:13:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10: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 1XmK4T-00005q-Ki; Thu, 06 Nov 2014 10:13:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK4R-0008VO-Na
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:13:39 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	DE/29-02954-3D94B545; Thu, 06 Nov 2014 10:13:39 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415268814!11777768!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19954 invoked from network); 6 Nov 2014 10:13:38 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:13:38 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWS31148; Thu, 06 Nov 2014 18:13:33 +0800 (CST)
Received: from localhost.localdomain (10.47.67.20) by
	szxeml460-hub.china.huawei.com (10.82.67.203) with Microsoft SMTP
	Server id 14.3.158.1; Thu, 6 Nov 2014 18:13:22 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Julien Grall
	<julien.grall@linaro.org>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 10:12:11 +0000
Message-ID: <1415268731-6519-8-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
References: <1415268731-6519-1-git-send-email-frediano.ziglio@huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.47.67.20]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020209.545B49CD.00F1, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d2fef5729ecab7e5c9cbbbd0b97b1760
Cc: zoltan.kiss@huawei.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 7/7] xen/arm: Handle translated addresses for
	hardware domains in GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Translated address could have an offset applied to them.
Replicate same value for device node to avoid improper address
computation in the OS.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 xen/arch/arm/gic-v2.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2f6bbd5..c2666df 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -631,7 +631,7 @@ static int gicv2_make_dt_node(const struct domain *d,
     const struct dt_device_node *gic = dt_interrupt_controller;
     const void *compatible = NULL;
     u32 len;
-    __be32 *new_cells, *tmp;
+    const __be32 *regs;
     int res = 0;
 
     compatible = dt_get_property(gic, "compatible", &len);
@@ -664,18 +664,18 @@ static int gicv2_make_dt_node(const struct domain *d,
     if ( res )
         return res;
 
+    /* copy GICC and GICD regions */
+    regs = dt_get_property(gic, "reg", &len);
+    if ( !regs )
+    {
+        dprintk(XENLOG_ERR, "Can't find reg property for the gic node\n");
+        return -FDT_ERR_XEN(ENOENT);
+    }
+
     len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
     len *= 2; /* GIC has two memory regions: Distributor + CPU interface */
-    new_cells = xzalloc_bytes(len);
-    if ( new_cells == NULL )
-        return -FDT_ERR_XEN(ENOMEM);
-
-    tmp = new_cells;
-    dt_set_range(&tmp, node, d->arch.vgic.dbase, PAGE_SIZE);
-    dt_set_range(&tmp, node, d->arch.vgic.cbase, PAGE_SIZE * 2);
 
-    res = fdt_property(fdt, "reg", new_cells, len);
-    xfree(new_cells);
+    res = fdt_property(fdt, "reg", regs, len);
 
     return res;
 }
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:14:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:14:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmK4q-0000Jq-9i; Thu, 06 Nov 2014 10:14:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK4o-0000Ix-Ob
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:14:03 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	4A/E2-11608-9E94B545; Thu, 06 Nov 2014 10:14:01 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415268841!10802206!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32577 invoked from network); 6 Nov 2014 10:14:01 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:14:01 -0000
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLI33441; Thu, 06 Nov 2014 10:13:54 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id
	14.03.0158.001; Thu, 6 Nov 2014 10:13:46 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Zoltan Kiss
	<zoltan.kiss@linaro.org>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
Thread-Index: AQHP+Nzd4ugSrwBZ1kiv4kYRXsWoAZxSDIYAgAAR8oCAATzvAIAAAiiAgAAFTjA=
Date: Thu, 6 Nov 2014 10:13:45 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17DC70@lhreml509-mbb>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
	<545A2A96.8060105@linaro.org>
	<alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
	<545B4380.3050209@linaro.org> <545B454F.9060401@linaro.org>
In-Reply-To: <545B454F.9060401@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.67.20]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Tim Deegan <tim@xen.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi Zoltan,
> 
> On 06/11/2014 09:46, Zoltan Kiss wrote:
> >
> >
> > On 05/11/14 14:52, Stefano Stabellini wrote:
> >> On Wed, 5 Nov 2014, Julien Grall wrote:
> >>> Hi Frediano,
> >>>
> >>> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> >>>> This name can appear in some Linux kernel repos. Not very
> >>>> fortunate, but to avoid others spending an hour to spot that few
> >>>> characters difference it worth to work around it.
> >>>
> >>> Linux upstream is using "hisilicon,hip04-intc" to detect the
> >>> hisilicon interrupt controller. So it's not a workaround.
> >>>
> >>> Which kernel is using the "*,hip04-gic"?
> >>
> >> Good question, but what really matters is the string that u-boot (or
> >> any other firmware/bootloader) is going to use, right? So, which one
> is it?
> > We are using the DTB from the kernel source, even when loading a bare
> > metal kernel. I've looked around, the *gic version seems to exist
> only
> > in internal repos, as far as I can see. Including the one Frediano
> > started to use for porting. Therefore, I don't insist to keep both,
> > but as I mentioned in the commit message, it would still provide some
> > benefit, and given that it's just a 3 line change which just extend a
> > few listings, I think we should keep it.
> 
> In general, Xen should respect the binding that has been agreed by the
> device tree team. Anything different should not be upstream, hence it's
> for only internal purpose.
> 
> > Of course with a different commit message, which clears that this is
> > the official name of it.
> 
> If it happens that both compatible are upstream. I would prefer that
> you define the *-intc one in the patch #3 and *-gic in #4.
> 
> It's more logical than defining first the non-official and then the
> official.
> 

Done

> Regards,
> 

Sent version 4.

Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:14:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:14:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmK4q-0000Jq-9i; Thu, 06 Nov 2014 10:14:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmK4o-0000Ix-Ob
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:14:03 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	4A/E2-11608-9E94B545; Thu, 06 Nov 2014 10:14:01 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415268841!10802206!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32577 invoked from network); 6 Nov 2014 10:14:01 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:14:01 -0000
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLI33441; Thu, 06 Nov 2014 10:13:54 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id
	14.03.0158.001; Thu, 6 Nov 2014 10:13:46 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Zoltan Kiss
	<zoltan.kiss@linaro.org>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
Thread-Index: AQHP+Nzd4ugSrwBZ1kiv4kYRXsWoAZxSDIYAgAAR8oCAATzvAIAAAiiAgAAFTjA=
Date: Thu, 6 Nov 2014 10:13:45 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17DC70@lhreml509-mbb>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
	<545A2A96.8060105@linaro.org>
	<alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
	<545B4380.3050209@linaro.org> <545B454F.9060401@linaro.org>
In-Reply-To: <545B454F.9060401@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.67.20]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Tim Deegan <tim@xen.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi Zoltan,
> 
> On 06/11/2014 09:46, Zoltan Kiss wrote:
> >
> >
> > On 05/11/14 14:52, Stefano Stabellini wrote:
> >> On Wed, 5 Nov 2014, Julien Grall wrote:
> >>> Hi Frediano,
> >>>
> >>> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> >>>> This name can appear in some Linux kernel repos. Not very
> >>>> fortunate, but to avoid others spending an hour to spot that few
> >>>> characters difference it worth to work around it.
> >>>
> >>> Linux upstream is using "hisilicon,hip04-intc" to detect the
> >>> hisilicon interrupt controller. So it's not a workaround.
> >>>
> >>> Which kernel is using the "*,hip04-gic"?
> >>
> >> Good question, but what really matters is the string that u-boot (or
> >> any other firmware/bootloader) is going to use, right? So, which one
> is it?
> > We are using the DTB from the kernel source, even when loading a bare
> > metal kernel. I've looked around, the *gic version seems to exist
> only
> > in internal repos, as far as I can see. Including the one Frediano
> > started to use for porting. Therefore, I don't insist to keep both,
> > but as I mentioned in the commit message, it would still provide some
> > benefit, and given that it's just a 3 line change which just extend a
> > few listings, I think we should keep it.
> 
> In general, Xen should respect the binding that has been agreed by the
> device tree team. Anything different should not be upstream, hence it's
> for only internal purpose.
> 
> > Of course with a different commit message, which clears that this is
> > the official name of it.
> 
> If it happens that both compatible are upstream. I would prefer that
> you define the *-intc one in the patch #3 and *-gic in #4.
> 
> It's more logical than defining first the non-official and then the
> official.
> 

Done

> Regards,
> 

Sent version 4.

Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:28:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmKI7-0001HF-Mg; Thu, 06 Nov 2014 10:27:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmKI5-0001HA-Qh
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 10:27:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2C/90-09842-12D4B545; Thu, 06 Nov 2014 10:27:45 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415269664!11914187!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12115 invoked from network); 6 Nov 2014 10:27:44 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:27:44 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so812467wgg.16
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 02:27:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=QlMB7+YEjs56KlmFsnRuT+pzfWU3kyE28zKlvKwmD4c=;
	b=K8iacYRv83PoWNEGHg73vyOCF1uCcC+iaURPiBcShYsjXa19KogiUeLYbwCNHHRPCB
	wsROagOKhTxVVeQ3Okg95klhue3cZzu/++MsqYOaxLnPAXoFQNcyf6oseALvoOCzT1je
	/IezcNU7Pdzl/spjEis1KVJJg1rH0LBeuX5srTLvYloUZ4kQqP90pL7zVRqoi48YWtyC
	ZeJmQGGH/AvDT780yzEEli6ZwcjW72J5/r0A4bnLJjGs8KlEN3XF/j9KaXOMjEIrgU24
	cCB/HladRKn0RzxEx1PabPDcCU19Jge8B2pCQ8S0IR+PUuMpwF2VhjCMUA4m0L6f3z6k
	ahSQ==
X-Gm-Message-State: ALoCoQnDrLnnX/DfSUiSzClQVwAltiUa2a/3DG3k2eUVUTH2RPWNxjxqeb0NdIciceOtLdfFvElU
X-Received: by 10.180.10.231 with SMTP id l7mr39659431wib.1.1415269664355;
	Thu, 06 Nov 2014 02:27:44 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id he3sm7256410wjc.15.2014.11.06.02.27.42
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 02:27:43 -0800 (PST)
Message-ID: <545B4D1D.4090000@linaro.org>
Date: Thu, 06 Nov 2014 10:27:41 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
In-Reply-To: <545B577D0200007800045407@mail.emea.novell.com>
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 06/11/2014 10:11, Jan Beulich wrote:
>>>> On 06.11.14 at 10:45, <julien.grall@linaro.org> wrote:
>> Hi Jan,
>>
>> On 05/11/2014 17:15, Jan Beulich wrote:
>>>>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>>>> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>>>>> It also needs Acks from Daniel and Jan.
>>>>
>>>> This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
>>>> required. Would Ian C. ack be enough?
>>>
>>> Yes, it would.
>>>
>>>> Anyway, Jan do you have any objection on this patch?
>>>
>>> As said previously, I'm not particularly happy about it, but I also don't
>> strongly
>>> mind it going in in the current shape.
>>
>> May I ask what is wrong with the new approach to the a DOMCTL in this patch?
>>
>> The DOMCTL has been clearly identify as arm specific (there is "arm" in
>> the name). Therefore it doesn't seem necessary to expose it for other
>> architecture than ARM32 and ARM64.
>
> I didn't say there's anything actively wrong with it, all I said is that
> I'm not particularly happy about it: Irrespective of its name it doesn't
> look to be really arch-specific in the long run, plus it feels like the
> data being set here should rather be specified right at domain
> creation, or via a mechanism similar to x86'es HVM parameters (iirc
> the value set here can't be changed once the domain got first
> unpaused).


TBH I choose this solution because I though you would be disagree with 
extending the domain create hypercall.

In long run, there will be more parameters such as the number of spis. 
All will be required at the same time. So the HVM parameters solution 
won't really help here.

However, I could give a look to extending the domain creation hypercall 
(xen_domctl_createdomain) to add arch specific field.

But I don't think it's Xen 4.5 material. So I would prefer to stay on 
this approach for this release because we'd like to have GICv3 guest 
support on Xen. Though I could rename the DOMCTL to DOMCTL_get_gic_version.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:28:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmKI7-0001HF-Mg; Thu, 06 Nov 2014 10:27:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmKI5-0001HA-Qh
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 10:27:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2C/90-09842-12D4B545; Thu, 06 Nov 2014 10:27:45 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415269664!11914187!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12115 invoked from network); 6 Nov 2014 10:27:44 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:27:44 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so812467wgg.16
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 02:27:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=QlMB7+YEjs56KlmFsnRuT+pzfWU3kyE28zKlvKwmD4c=;
	b=K8iacYRv83PoWNEGHg73vyOCF1uCcC+iaURPiBcShYsjXa19KogiUeLYbwCNHHRPCB
	wsROagOKhTxVVeQ3Okg95klhue3cZzu/++MsqYOaxLnPAXoFQNcyf6oseALvoOCzT1je
	/IezcNU7Pdzl/spjEis1KVJJg1rH0LBeuX5srTLvYloUZ4kQqP90pL7zVRqoi48YWtyC
	ZeJmQGGH/AvDT780yzEEli6ZwcjW72J5/r0A4bnLJjGs8KlEN3XF/j9KaXOMjEIrgU24
	cCB/HladRKn0RzxEx1PabPDcCU19Jge8B2pCQ8S0IR+PUuMpwF2VhjCMUA4m0L6f3z6k
	ahSQ==
X-Gm-Message-State: ALoCoQnDrLnnX/DfSUiSzClQVwAltiUa2a/3DG3k2eUVUTH2RPWNxjxqeb0NdIciceOtLdfFvElU
X-Received: by 10.180.10.231 with SMTP id l7mr39659431wib.1.1415269664355;
	Thu, 06 Nov 2014 02:27:44 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id he3sm7256410wjc.15.2014.11.06.02.27.42
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 02:27:43 -0800 (PST)
Message-ID: <545B4D1D.4090000@linaro.org>
Date: Thu, 06 Nov 2014 10:27:41 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
In-Reply-To: <545B577D0200007800045407@mail.emea.novell.com>
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 06/11/2014 10:11, Jan Beulich wrote:
>>>> On 06.11.14 at 10:45, <julien.grall@linaro.org> wrote:
>> Hi Jan,
>>
>> On 05/11/2014 17:15, Jan Beulich wrote:
>>>>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>>>> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>>>>> It also needs Acks from Daniel and Jan.
>>>>
>>>> This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
>>>> required. Would Ian C. ack be enough?
>>>
>>> Yes, it would.
>>>
>>>> Anyway, Jan do you have any objection on this patch?
>>>
>>> As said previously, I'm not particularly happy about it, but I also don't
>> strongly
>>> mind it going in in the current shape.
>>
>> May I ask what is wrong with the new approach to the a DOMCTL in this patch?
>>
>> The DOMCTL has been clearly identify as arm specific (there is "arm" in
>> the name). Therefore it doesn't seem necessary to expose it for other
>> architecture than ARM32 and ARM64.
>
> I didn't say there's anything actively wrong with it, all I said is that
> I'm not particularly happy about it: Irrespective of its name it doesn't
> look to be really arch-specific in the long run, plus it feels like the
> data being set here should rather be specified right at domain
> creation, or via a mechanism similar to x86'es HVM parameters (iirc
> the value set here can't be changed once the domain got first
> unpaused).


TBH I choose this solution because I though you would be disagree with 
extending the domain create hypercall.

In long run, there will be more parameters such as the number of spis. 
All will be required at the same time. So the HVM parameters solution 
won't really help here.

However, I could give a look to extending the domain creation hypercall 
(xen_domctl_createdomain) to add arch specific field.

But I don't think it's Xen 4.5 material. So I would prefer to stay on 
this approach for this release because we'd like to have GICv3 guest 
support on Xen. Though I could rename the DOMCTL to DOMCTL_get_gic_version.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:34:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:34:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmKNz-0001QG-GD; Thu, 06 Nov 2014 10:33:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmKNy-0001QB-NF
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 10:33:50 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	00/72-02702-E8E4B545; Thu, 06 Nov 2014 10:33:50 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415270028!11779664!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20106 invoked from network); 6 Nov 2014 10:33:48 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-13.tower-27.messagelabs.com with SMTP;
	6 Nov 2014 10:33:48 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id ED2991AA;
	Thu,  6 Nov 2014 04:33:43 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 9AB855FAD7;
	Thu,  6 Nov 2014 04:33:41 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 1FAA313F91E;
	Thu,  6 Nov 2014 04:33:40 -0600 (CST)
Date: Thu, 6 Nov 2014 10:33:37 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141106103337.GA19702@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > On Mon, Nov 03, 2014 at 11:10:18AM +0000, Stefano Stabellini wrote:
> > > On Mon, 3 Nov 2014, Will Deacon wrote:
> > > > On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> > > > > On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > > > > > Introduce a boolean flag and an accessor function to check whether a
> > > > > > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > > > > > 
> > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > > > CC: will.deacon@arm.com
> > > > > 
> > > > > Will, Catalin,
> > > > > are you OK with this patch?
> > > > 
> > > > It would be nicer if the dma_coherent flag didn't have to be duplicated by
> > > > each architecture in dev_archdata. Is there any reason not to put it in the
> > > > core code?
> > > 
> > > Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> > > struct device as Catalin initially suggested, what would be the default
> > > for each architecture? Where would I set it for arch that don't use
> > > device tree?
> > 
> > You don't need to. An architecture that has coherent DMA always doesn't
> > need to do anything. One that has non-coherent DMA always only needs to
> > select HAVE_DMA_NONCOHERENT. One that has a mix of both needs to find a
> > way to set dev->dma_coherent. Since that's a new API you introduce, it
> > doesn't break any existing architectures.
> 
> I am not sure that this is better than the current patch but I can see
> that this approach is not too controversial, so I am happy to go with
> whatever the maintainers prefer.

Functionally it is the same, but just less code duplication.

> > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > standard cache maintenance would be enough (but that's a Xen problem,
> > not sure how to solve).
> 
> It is a thorny issue indeed.
> Xen would need to know how to do non-standard cache maintenance
> operations.

Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
just use the currently registered dma ops.

> Otherwise we would need to resurrect XENFEAT_grant_map_identity (that I
> am reverting in this series) and be content with having CONFIG_XEN_DOM0
> depend on CONFIG_ARM_LPAE.

So what does buy you? Is it just the hope that with LPAE you won't have
weird system caches?

> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 05d7a8a458d5..8462b2e7491b 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -203,6 +203,9 @@ config HAVE_DMA_ATTRS
> >  config HAVE_DMA_CONTIGUOUS
> >  	bool
> >  
> > +config HAVE_DMA_NONCOHERENT
> > +	bool
> > +
> >  config GENERIC_SMP_IDLE_THREAD
> >         bool
> >  
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 89c4b5ccc68d..fd7d5522764c 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -40,6 +40,7 @@ config ARM
> >  	select HAVE_DMA_API_DEBUG
> >  	select HAVE_DMA_ATTRS
> >  	select HAVE_DMA_CONTIGUOUS if MMU
> > +	select HAVE_DMA_NONCOHERENT if OF
> >  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
> >  	select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
> >  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 9532f8d5857e..eb7a5aa64e0e 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -46,6 +46,7 @@ config ARM64
> >  	select HAVE_DMA_API_DEBUG
> >  	select HAVE_DMA_ATTRS
> >  	select HAVE_DMA_CONTIGUOUS
> > +	select HAVE_DMA_NONCOHERENT
> >  	select HAVE_DYNAMIC_FTRACE
> >  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
> >  	select HAVE_FTRACE_MCOUNT_RECORD
> > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> > index 3b64d0bf5bba..7e827726b702 100644
> > --- a/drivers/of/platform.c
> > +++ b/drivers/of/platform.c
> > @@ -183,6 +183,7 @@ static void of_dma_configure(struct device *dev)
> >  	 * dma coherent operations.
> >  	 */
> >  	if (of_dma_is_coherent(dev->of_node)) {
> > +		dev->dma_coherent = true;
> >  		set_arch_dma_coherent_ops(dev);
> >  		dev_dbg(dev, "device is dma coherent\n");
> >  	}
> 
> I think that this would need to be #ifdef'ed as it is possible to have
> OF support but no HAVE_DMA_NONCOHERENT (PPC?).

The field is always there. But with !HAVE_DMA_NONCOHERENT,
is_device_dma_coherent() would always return 1. You could avoid
defining is_device_dma_coherent() entirely when !HAVE_DMA_NONCOHERENT,
it wouldn't be worse than your patch in terms of an undefined function.

> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index ce1f21608b16..e00ca876db01 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -796,6 +796,7 @@ struct device {
> >  
> >  	bool			offline_disabled:1;
> >  	bool			offline:1;
> > +	bool			dma_coherent:1;
> >  };
> 
> I guess we would have to #ifdef CONFIG_HAVE_DMA_NONCOHERENT the
> dma_coherent flag, right? Otherwise architecures that do not select
> CONFIG_HAVE_DMA_NONCOHERENT (x86 for example) would end up with a flag
> in struct device that doesn't reflect the properties of the device (dma
> coherent devices with dev->dma_coherent == 0).

In my proposal you should not read this field directly but rather access
it only via is_device_dma_coherent() (you can add a function for setting
it as well).

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:34:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:34:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmKNz-0001QG-GD; Thu, 06 Nov 2014 10:33:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmKNy-0001QB-NF
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 10:33:50 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	00/72-02702-E8E4B545; Thu, 06 Nov 2014 10:33:50 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415270028!11779664!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20106 invoked from network); 6 Nov 2014 10:33:48 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-13.tower-27.messagelabs.com with SMTP;
	6 Nov 2014 10:33:48 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id ED2991AA;
	Thu,  6 Nov 2014 04:33:43 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 9AB855FAD7;
	Thu,  6 Nov 2014 04:33:41 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 1FAA313F91E;
	Thu,  6 Nov 2014 04:33:40 -0600 (CST)
Date: Thu, 6 Nov 2014 10:33:37 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141106103337.GA19702@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > On Mon, Nov 03, 2014 at 11:10:18AM +0000, Stefano Stabellini wrote:
> > > On Mon, 3 Nov 2014, Will Deacon wrote:
> > > > On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> > > > > On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > > > > > Introduce a boolean flag and an accessor function to check whether a
> > > > > > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > > > > > 
> > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > > > CC: will.deacon@arm.com
> > > > > 
> > > > > Will, Catalin,
> > > > > are you OK with this patch?
> > > > 
> > > > It would be nicer if the dma_coherent flag didn't have to be duplicated by
> > > > each architecture in dev_archdata. Is there any reason not to put it in the
> > > > core code?
> > > 
> > > Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> > > struct device as Catalin initially suggested, what would be the default
> > > for each architecture? Where would I set it for arch that don't use
> > > device tree?
> > 
> > You don't need to. An architecture that has coherent DMA always doesn't
> > need to do anything. One that has non-coherent DMA always only needs to
> > select HAVE_DMA_NONCOHERENT. One that has a mix of both needs to find a
> > way to set dev->dma_coherent. Since that's a new API you introduce, it
> > doesn't break any existing architectures.
> 
> I am not sure that this is better than the current patch but I can see
> that this approach is not too controversial, so I am happy to go with
> whatever the maintainers prefer.

Functionally it is the same, but just less code duplication.

> > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > standard cache maintenance would be enough (but that's a Xen problem,
> > not sure how to solve).
> 
> It is a thorny issue indeed.
> Xen would need to know how to do non-standard cache maintenance
> operations.

Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
just use the currently registered dma ops.

> Otherwise we would need to resurrect XENFEAT_grant_map_identity (that I
> am reverting in this series) and be content with having CONFIG_XEN_DOM0
> depend on CONFIG_ARM_LPAE.

So what does buy you? Is it just the hope that with LPAE you won't have
weird system caches?

> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 05d7a8a458d5..8462b2e7491b 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -203,6 +203,9 @@ config HAVE_DMA_ATTRS
> >  config HAVE_DMA_CONTIGUOUS
> >  	bool
> >  
> > +config HAVE_DMA_NONCOHERENT
> > +	bool
> > +
> >  config GENERIC_SMP_IDLE_THREAD
> >         bool
> >  
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 89c4b5ccc68d..fd7d5522764c 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -40,6 +40,7 @@ config ARM
> >  	select HAVE_DMA_API_DEBUG
> >  	select HAVE_DMA_ATTRS
> >  	select HAVE_DMA_CONTIGUOUS if MMU
> > +	select HAVE_DMA_NONCOHERENT if OF
> >  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
> >  	select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
> >  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 9532f8d5857e..eb7a5aa64e0e 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -46,6 +46,7 @@ config ARM64
> >  	select HAVE_DMA_API_DEBUG
> >  	select HAVE_DMA_ATTRS
> >  	select HAVE_DMA_CONTIGUOUS
> > +	select HAVE_DMA_NONCOHERENT
> >  	select HAVE_DYNAMIC_FTRACE
> >  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
> >  	select HAVE_FTRACE_MCOUNT_RECORD
> > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> > index 3b64d0bf5bba..7e827726b702 100644
> > --- a/drivers/of/platform.c
> > +++ b/drivers/of/platform.c
> > @@ -183,6 +183,7 @@ static void of_dma_configure(struct device *dev)
> >  	 * dma coherent operations.
> >  	 */
> >  	if (of_dma_is_coherent(dev->of_node)) {
> > +		dev->dma_coherent = true;
> >  		set_arch_dma_coherent_ops(dev);
> >  		dev_dbg(dev, "device is dma coherent\n");
> >  	}
> 
> I think that this would need to be #ifdef'ed as it is possible to have
> OF support but no HAVE_DMA_NONCOHERENT (PPC?).

The field is always there. But with !HAVE_DMA_NONCOHERENT,
is_device_dma_coherent() would always return 1. You could avoid
defining is_device_dma_coherent() entirely when !HAVE_DMA_NONCOHERENT,
it wouldn't be worse than your patch in terms of an undefined function.

> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index ce1f21608b16..e00ca876db01 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -796,6 +796,7 @@ struct device {
> >  
> >  	bool			offline_disabled:1;
> >  	bool			offline:1;
> > +	bool			dma_coherent:1;
> >  };
> 
> I guess we would have to #ifdef CONFIG_HAVE_DMA_NONCOHERENT the
> dma_coherent flag, right? Otherwise architecures that do not select
> CONFIG_HAVE_DMA_NONCOHERENT (x86 for example) would end up with a flag
> in struct device that doesn't reflect the properties of the device (dma
> coherent devices with dev->dma_coherent == 0).

In my proposal you should not read this field directly but rather access
it only via is_device_dma_coherent() (you can add a function for setting
it as well).

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:34:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:34:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmKOu-0001VI-2k; Thu, 06 Nov 2014 10:34:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmKOs-0001V9-RQ
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:34:47 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	4F/EE-09284-6CE4B545; Thu, 06 Nov 2014 10:34:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415270075!10816080!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTA5MjggKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11208 invoked from network); 6 Nov 2014 10:34:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:34:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="188708958"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 05:34:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmKOg-0003gG-3Q;
	Thu, 06 Nov 2014 10:34:34 +0000
Date: Thu, 6 Nov 2014 10:34:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Steven Haigh <netwiz@crc.id.au>
In-Reply-To: <545B441C.9040907@crc.id.au>
Message-ID: <alpine.DEB.2.02.1411061032330.22875@kaball.uk.xensource.com>
References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au>
	<1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411051645140.22875@kaball.uk.xensource.com>
	<545B441C.9040907@crc.id.au>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] vnc=1 / pvgrub / close fb: backend at
 /local/domain/0/backend/vfb/xx/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

Hello Steven,
thanks for testing!

Regarding the other issue, which QEMU version are you using? Which Xen
version? On Xen 4.5.0-rc1 I don't see any problems.


On Thu, 6 Nov 2014, Steven Haigh wrote:
> Hi Stefano,
> 
> It seems that this patch fixes the grub issue for me. I no longer get
> the infinite wait at the grub prompt.
> 
> On 6/11/2014 4:49 AM, Stefano Stabellini wrote:
> > Hello Steven,
> > I have found some time to debug this myself.
> > I couldn't reproduce the booting issue that you reported: in my case
> > after seeing the grub boot menu I can successfully boot the kernel
> > without problems.
> > 
> > However I can reproduce the timeout issue that you are seeing: the
> > timeout doesn't work properly in graphics mode.
> > 
> > The reason is that the with a graphics terminal you checkkey () return 0
> > even when pressing no keys, resulting in wrong behaviour in run_menu. 
> > 
> > Does the following patch (also attached) fixes your issues?
> > 
> > 
> > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
> > new file mode 100644
> > index 0000000..fe17b20
> > --- /dev/null
> > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> > @@ -0,0 +1,13 @@
> > +diff --git a/stage2/stage2.c b/stage2/stage2.c
> > +index 9d9fcc3..8353a3b 100644
> > +--- a/stage2/stage2.c
> > ++++ b/stage2/stage2.c
> > +@@ -395,7 +395,7 @@ restart:
> > + 	 pressed.  
> > + 	 This avoids polling (relevant in the grub-shell and later on
> > + 	 in grub if interrupt driven I/O is done).  */
> > +-      if (checkkey () >= 0 || grub_timeout < 0)
> > ++      if (checkkey () > 0 || grub_timeout < 0)
> > + 	{
> > + 	  /* Key was pressed, show which entry is selected before GETKEY,
> > + 	     since we're comming in here also on GRUB_TIMEOUT == -1 and
> > 
> > 
> > 
> > On Thu, 23 Oct 2014, Steven Haigh wrote:
> >> On 23/10/2014 2:40 AM, Ian Campbell wrote:
> >>> On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
> >>>
> >>>> Output using pv-grub:
> >>>
> >>> Can you also post the qemu logs please (under /var/log/xen somewhere I
> >>> think).
> >>
> >> I get very little out of this:
> >> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
> >> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
> >> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
> >> [root@dom0 xen]# cat xl-dev.vm.log
> >> Waiting for domain dev.vm (domid 36) to die [pid 6970]
> >>
> >> That's it :\
> >>
> >>>> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
> >>>> 00007fffb4573638 error 4
> >>>
> >>> That might be a smoking gun. Is there a core dump and/or could you try
> >>> and run qemu under gdb?
> >>
> >> Any hints on doing this? I can't say I'm a gdb guru.... I can't find any
> >> core dumps anywhere so that's not really helpful...
> >>
> >> -- 
> >> Steven Haigh
> >>
> >> Email: netwiz@crc.id.au
> >> Web: http://www.crc.id.au
> >> Phone: (03) 9001 6090 - 0412 935 897
> >>
> 
> -- 
> Steven Haigh
> 
> Email: netwiz@crc.id.au
> Web: http://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:34:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:34:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmKOu-0001VI-2k; Thu, 06 Nov 2014 10:34:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmKOs-0001V9-RQ
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:34:47 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	4F/EE-09284-6CE4B545; Thu, 06 Nov 2014 10:34:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415270075!10816080!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTA5MjggKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11208 invoked from network); 6 Nov 2014 10:34:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:34:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="188708958"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 05:34:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmKOg-0003gG-3Q;
	Thu, 06 Nov 2014 10:34:34 +0000
Date: Thu, 6 Nov 2014 10:34:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Steven Haigh <netwiz@crc.id.au>
In-Reply-To: <545B441C.9040907@crc.id.au>
Message-ID: <alpine.DEB.2.02.1411061032330.22875@kaball.uk.xensource.com>
References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au>
	<1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411051645140.22875@kaball.uk.xensource.com>
	<545B441C.9040907@crc.id.au>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] vnc=1 / pvgrub / close fb: backend at
 /local/domain/0/backend/vfb/xx/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

Hello Steven,
thanks for testing!

Regarding the other issue, which QEMU version are you using? Which Xen
version? On Xen 4.5.0-rc1 I don't see any problems.


On Thu, 6 Nov 2014, Steven Haigh wrote:
> Hi Stefano,
> 
> It seems that this patch fixes the grub issue for me. I no longer get
> the infinite wait at the grub prompt.
> 
> On 6/11/2014 4:49 AM, Stefano Stabellini wrote:
> > Hello Steven,
> > I have found some time to debug this myself.
> > I couldn't reproduce the booting issue that you reported: in my case
> > after seeing the grub boot menu I can successfully boot the kernel
> > without problems.
> > 
> > However I can reproduce the timeout issue that you are seeing: the
> > timeout doesn't work properly in graphics mode.
> > 
> > The reason is that the with a graphics terminal you checkkey () return 0
> > even when pressing no keys, resulting in wrong behaviour in run_menu. 
> > 
> > Does the following patch (also attached) fixes your issues?
> > 
> > 
> > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
> > new file mode 100644
> > index 0000000..fe17b20
> > --- /dev/null
> > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> > @@ -0,0 +1,13 @@
> > +diff --git a/stage2/stage2.c b/stage2/stage2.c
> > +index 9d9fcc3..8353a3b 100644
> > +--- a/stage2/stage2.c
> > ++++ b/stage2/stage2.c
> > +@@ -395,7 +395,7 @@ restart:
> > + 	 pressed.  
> > + 	 This avoids polling (relevant in the grub-shell and later on
> > + 	 in grub if interrupt driven I/O is done).  */
> > +-      if (checkkey () >= 0 || grub_timeout < 0)
> > ++      if (checkkey () > 0 || grub_timeout < 0)
> > + 	{
> > + 	  /* Key was pressed, show which entry is selected before GETKEY,
> > + 	     since we're comming in here also on GRUB_TIMEOUT == -1 and
> > 
> > 
> > 
> > On Thu, 23 Oct 2014, Steven Haigh wrote:
> >> On 23/10/2014 2:40 AM, Ian Campbell wrote:
> >>> On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
> >>>
> >>>> Output using pv-grub:
> >>>
> >>> Can you also post the qemu logs please (under /var/log/xen somewhere I
> >>> think).
> >>
> >> I get very little out of this:
> >> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
> >> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
> >> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
> >> [root@dom0 xen]# cat xl-dev.vm.log
> >> Waiting for domain dev.vm (domid 36) to die [pid 6970]
> >>
> >> That's it :\
> >>
> >>>> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
> >>>> 00007fffb4573638 error 4
> >>>
> >>> That might be a smoking gun. Is there a core dump and/or could you try
> >>> and run qemu under gdb?
> >>
> >> Any hints on doing this? I can't say I'm a gdb guru.... I can't find any
> >> core dumps anywhere so that's not really helpful...
> >>
> >> -- 
> >> Steven Haigh
> >>
> >> Email: netwiz@crc.id.au
> >> Web: http://www.crc.id.au
> >> Phone: (03) 9001 6090 - 0412 935 897
> >>
> 
> -- 
> Steven Haigh
> 
> Email: netwiz@crc.id.au
> Web: http://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:42:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmKVn-00023q-VA; Thu, 06 Nov 2014 10:41:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmKVm-00021i-Hu
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:41:54 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	7D/A0-27623-1705B545; Thu, 06 Nov 2014 10:41:53 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415270511!10811840!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18077 invoked from network); 6 Nov 2014 10:41:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:41:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="188710164"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 05:41:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmKVU-0003n5-Ds;
	Thu, 06 Nov 2014 10:41:36 +0000
Date: Thu, 6 Nov 2014 10:41:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <samuel.thibault@ens-lyon.org>
In-Reply-To: <5447D30A.4040704@crc.id.au>
Message-ID: <alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au>
	<1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: netwiz@crc.id.au, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org, Anthony Perard <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When using pvgrub in graphical mode with vnc, the grub timeout doesn't
work: the countdown doesn't even start. With a serial terminal the
problem doesn't occur and the countdown works as expected.

It turns out that the problem is that when using a graphical terminal,
checkkey () returns 0 instead of -1 when there is no activity on the
mouse or keyboard. As a consequence grub thinks that the user typed
something and interrupts the count down.

To fix the issue simply ignore keystrokes returning 0, that is the NUL
character anyway. Add a patch to grub.patches to do that.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Steven Haigh <netwiz@crc.id.au>

diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
new file mode 100644
index 0000000..fe17b20
--- /dev/null
+++ b/stubdom/grub.patches/11graphics-keyboard.diff
@@ -0,0 +1,13 @@
+diff --git a/stage2/stage2.c b/stage2/stage2.c
+index 9d9fcc3..8353a3b 100644
+--- a/stage2/stage2.c
++++ b/stage2/stage2.c
+@@ -395,7 +395,7 @@ restart:
+ 	 pressed.  
+ 	 This avoids polling (relevant in the grub-shell and later on
+ 	 in grub if interrupt driven I/O is done).  */
+-      if (checkkey () >= 0 || grub_timeout < 0)
++      if (checkkey () > 0 || grub_timeout < 0)
+ 	{
+ 	  /* Key was pressed, show which entry is selected before GETKEY,
+ 	     since we're comming in here also on GRUB_TIMEOUT == -1 and

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 10:42:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 10:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmKVn-00023q-VA; Thu, 06 Nov 2014 10:41:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmKVm-00021i-Hu
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 10:41:54 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	7D/A0-27623-1705B545; Thu, 06 Nov 2014 10:41:53 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415270511!10811840!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18077 invoked from network); 6 Nov 2014 10:41:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 10:41:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="188710164"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 05:41:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmKVU-0003n5-Ds;
	Thu, 06 Nov 2014 10:41:36 +0000
Date: Thu, 6 Nov 2014 10:41:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <samuel.thibault@ens-lyon.org>
In-Reply-To: <5447D30A.4040704@crc.id.au>
Message-ID: <alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au>
	<1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: netwiz@crc.id.au, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org, Anthony Perard <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When using pvgrub in graphical mode with vnc, the grub timeout doesn't
work: the countdown doesn't even start. With a serial terminal the
problem doesn't occur and the countdown works as expected.

It turns out that the problem is that when using a graphical terminal,
checkkey () returns 0 instead of -1 when there is no activity on the
mouse or keyboard. As a consequence grub thinks that the user typed
something and interrupts the count down.

To fix the issue simply ignore keystrokes returning 0, that is the NUL
character anyway. Add a patch to grub.patches to do that.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Steven Haigh <netwiz@crc.id.au>

diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
new file mode 100644
index 0000000..fe17b20
--- /dev/null
+++ b/stubdom/grub.patches/11graphics-keyboard.diff
@@ -0,0 +1,13 @@
+diff --git a/stage2/stage2.c b/stage2/stage2.c
+index 9d9fcc3..8353a3b 100644
+--- a/stage2/stage2.c
++++ b/stage2/stage2.c
+@@ -395,7 +395,7 @@ restart:
+ 	 pressed.  
+ 	 This avoids polling (relevant in the grub-shell and later on
+ 	 in grub if interrupt driven I/O is done).  */
+-      if (checkkey () >= 0 || grub_timeout < 0)
++      if (checkkey () > 0 || grub_timeout < 0)
+ 	{
+ 	  /* Key was pressed, show which entry is selected before GETKEY,
+ 	     since we're comming in here also on GRUB_TIMEOUT == -1 and

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:05:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmKsh-0002eh-6B; Thu, 06 Nov 2014 11:05:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1XmKsf-0002ec-AV
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:05:33 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	C5/1A-18267-CF55B545; Thu, 06 Nov 2014 11:05:32 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415271921!7095672!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNjk4OTMgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12237 invoked from network); 6 Nov 2014 11:05:22 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-9.tower-31.messagelabs.com with SMTP;
	6 Nov 2014 11:05:22 -0000
Received: from dhcp-10-1-1-187.lan.crc.id.au (dhcp-10-1-1-187.lan.crc.id.au
	[10.1.1.187])
	by mail.crc.id.au (Postfix) with ESMTPSA id 02C7F3676AE;
	Thu,  6 Nov 2014 22:05:14 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1415271914; bh=zaaKk3ntjhlexs8/gOkj3Zh1mUkXXhry0Z2vcQGEsjw=;
	h=In-Reply-To:References:Subject:From:Date:To:CC;
	b=DTwQMoAA6TGQk+HDf4PXjS8I/BqXLoZi1f14H8TFvSkVRdUwSDGvniQvAcuZhHCKB
	IPt9nikZcFT7nQmkxMuiVncvdQ9PyV80fXI19PpEOs5SExzw1/IeMYF5eJ7/FyXMBZ
	A1//R8jpQEvlueOmp02BGDvKMVoU1C0xrJBII3Ow=
User-Agent: K-9 Mail for Android
In-Reply-To: <alpine.DEB.2.02.1411061032330.22875@kaball.uk.xensource.com>
References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au>
	<1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411051645140.22875@kaball.uk.xensource.com>
	<545B441C.9040907@crc.id.au>
	<alpine.DEB.2.02.1411061032330.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
From: Steven Haigh <netwiz@crc.id.au>
Date: Thu, 06 Nov 2014 22:05:18 +1100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <9B1F07A4-8E01-46FE-9399-8857F6EB105F@crc.id.au>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vnc=1 / pvgrub / close fb: backend at
	/local/domain/0/backend/vfb/xx/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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I've been a bit busy at the moment and haven't had a chance to retest all of this and get some solid issues.

One thing I've come across is the different type of installs I've been playing with.. Some with a filesystem on xvda, some with a filesystem on xvda1.

As it seems you can only give one grub.conf entry in the extra domu config line, I have another issue to look at.

When I get some more free time I'll see I'd I can turn something up ...

On 6 November 2014 9:34:26 pm AEDT, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>Hello Steven,
>thanks for testing!
>
>Regarding the other issue, which QEMU version are you using? Which Xen
>version? On Xen 4.5.0-rc1 I don't see any problems.
>
>
>On Thu, 6 Nov 2014, Steven Haigh wrote:
>> Hi Stefano,
>>
>> It seems that this patch fixes the grub issue for me. I no longer get
>> the infinite wait at the grub prompt.
>>
>> On 6/11/2014 4:49 AM, Stefano Stabellini wrote:
>> > Hello Steven,
>> > I have found some time to debug this myself.
>> > I couldn't reproduce the booting issue that you reported: in my
>case
>> > after seeing the grub boot menu I can successfully boot the kernel
>> > without problems.
>> >
>> > However I can reproduce the timeout issue that you are seeing: the
>> > timeout doesn't work properly in graphics mode.
>> >
>> > The reason is that the with a graphics terminal you checkkey ()
>return 0
>> > even when pressing no keys, resulting in wrong behaviour in
>run_menu.
>> >
>> > Does the following patch (also attached) fixes your issues?
>> >
>> >
>> > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff
>b/stubdom/grub.patches/11graphics-keyboard.diff
>> > new file mode 100644
>> > index 0000000..fe17b20
>> > --- /dev/null
>> > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
>> > @@ -0,0 +1,13 @@
>> > +diff --git a/stage2/stage2.c b/stage2/stage2.c
>> > +index 9d9fcc3..8353a3b 100644
>> > +--- a/stage2/stage2.c
>> > ++++ b/stage2/stage2.c
>> > +@@ -395,7 +395,7 @@ restart:
>> > + 	 pressed.
>> > + 	 This avoids polling (relevant in the grub-shell and later on
>> > + 	 in grub if interrupt driven I/O is done).  */
>> > +-      if (checkkey () >= 0 || grub_timeout < 0)
>> > ++      if (checkkey () > 0 || grub_timeout < 0)
>> > + 	{
>> > + 	  /* Key was pressed, show which entry is selected before
>GETKEY,
>> > + 	     since we're comming in here also on GRUB_TIMEOUT == -1 and
>> >
>> >
>> >
>> > On Thu, 23 Oct 2014, Steven Haigh wrote:
>> >> On 23/10/2014 2:40 AM, Ian Campbell wrote:
>> >>> On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
>> >>>
>> >>>> Output using pv-grub:
>> >>>
>> >>> Can you also post the qemu logs please (under /var/log/xen
>somewhere I
>> >>> think).
>> >>
>> >> I get very little out of this:
>> >> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
>> >> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
>> >> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
>> >> [root@dom0 xen]# cat xl-dev.vm.log
>> >> Waiting for domain dev.vm (domid 36) to die [pid 6970]
>> >>
>> >> That's it :\
>> >>
>> >>>> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
>> >>>> 00007fffb4573638 error 4
>> >>>
>> >>> That might be a smoking gun. Is there a core dump and/or could
>you try
>> >>> and run qemu under gdb?
>> >>
>> >> Any hints on doing this? I can't say I'm a gdb guru.... I can't
>find any
>> >> core dumps anywhere so that's not really helpful...
>> >>
>> >> --
>> >> Steven Haigh
>> >>
>> >> Email: netwiz@crc.id.au
>> >> Web: http://www.crc.id.au
>> >> Phone: (03) 9001 6090 - 0412 935 897
>> >>
>>
>> --
>> Steven Haigh
>>
>> Email: netwiz@crc.id.au
>> Web: http://www.crc.id.au
>> Phone: (03) 9001 6090 - 0412 935 897
>>
>>

- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI9BAEBCgAnBQJUW1XtIBxTdGV2ZW4gSGFpZ2ggPG5ldHdpekBjcmMuaWQuYXU+
AAoJEEGvNdV6fTHcIr4QAKvTrrgaa4zpXxlw3wfvm3bIdYuVbaW3qEeXWWuFwEC7
13cdLPEil04PhJPW/8q/S8T/2V6vEYvlrQMgPWbcTrCfZJ6KxNN5WQJzP/aJ0s9y
IWRizMx3fD+rgQGqE/HEqvSHX7ME2rhLHIHkpAw+q/KV97t76W6n8QOKFAtrwD1+
dcgcuCVdQmra2/RzC/fu028vyFJ63ZBoNyJzD/6MfyseskUL3EYfimiKOnZpXBz0
BeLa8Dyc7UgiTg3yoXJU7+m2V80r+4oBD2kbs+eMBWwY1a/fUzLe3xITxKprBp2c
lKyap/sUJJIs17fsr1VpmoCnyQCFUzDVdms9kU8RaivwVCpCqSdtPNLkiqXZmhqX
DKJ3P2xBDdwz/SH30/fIL+S7o43LfjVl2CbEdj6/t1HN/0iPRWt2BTr/HtoGt+t+
fWedzx0pfwl8C4dd9Ac3aGojnT9UwB4Na9pPVSsLgK5SuXT0pRYU4tpZ46oZNirt
bJBFcR9xrLWcH+a9k5HydruPXf6sCVmV/kwUB+mngECeiifEP2ILQN1psyls66+w
BKwrQlYKf4wJf3EfsV7soPa+GLL0rQLpLV8P+O5UHJ0W62VCzetpKonDVyuxA13o
jCFC+POP4c0dGo4sfGk5IDeh7s0z/PIpd/VjG/sgHt2AU2QWy2FOItxM+eYPq9SN
=2gPy
-----END PGP SIGNATURE-----


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:05:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmKsh-0002eh-6B; Thu, 06 Nov 2014 11:05:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1XmKsf-0002ec-AV
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:05:33 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	C5/1A-18267-CF55B545; Thu, 06 Nov 2014 11:05:32 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415271921!7095672!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNjk4OTMgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12237 invoked from network); 6 Nov 2014 11:05:22 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-9.tower-31.messagelabs.com with SMTP;
	6 Nov 2014 11:05:22 -0000
Received: from dhcp-10-1-1-187.lan.crc.id.au (dhcp-10-1-1-187.lan.crc.id.au
	[10.1.1.187])
	by mail.crc.id.au (Postfix) with ESMTPSA id 02C7F3676AE;
	Thu,  6 Nov 2014 22:05:14 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1415271914; bh=zaaKk3ntjhlexs8/gOkj3Zh1mUkXXhry0Z2vcQGEsjw=;
	h=In-Reply-To:References:Subject:From:Date:To:CC;
	b=DTwQMoAA6TGQk+HDf4PXjS8I/BqXLoZi1f14H8TFvSkVRdUwSDGvniQvAcuZhHCKB
	IPt9nikZcFT7nQmkxMuiVncvdQ9PyV80fXI19PpEOs5SExzw1/IeMYF5eJ7/FyXMBZ
	A1//R8jpQEvlueOmp02BGDvKMVoU1C0xrJBII3Ow=
User-Agent: K-9 Mail for Android
In-Reply-To: <alpine.DEB.2.02.1411061032330.22875@kaball.uk.xensource.com>
References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au>
	<1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411051645140.22875@kaball.uk.xensource.com>
	<545B441C.9040907@crc.id.au>
	<alpine.DEB.2.02.1411061032330.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
From: Steven Haigh <netwiz@crc.id.au>
Date: Thu, 06 Nov 2014 22:05:18 +1100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <9B1F07A4-8E01-46FE-9399-8857F6EB105F@crc.id.au>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vnc=1 / pvgrub / close fb: backend at
	/local/domain/0/backend/vfb/xx/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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I've been a bit busy at the moment and haven't had a chance to retest all of this and get some solid issues.

One thing I've come across is the different type of installs I've been playing with.. Some with a filesystem on xvda, some with a filesystem on xvda1.

As it seems you can only give one grub.conf entry in the extra domu config line, I have another issue to look at.

When I get some more free time I'll see I'd I can turn something up ...

On 6 November 2014 9:34:26 pm AEDT, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>Hello Steven,
>thanks for testing!
>
>Regarding the other issue, which QEMU version are you using? Which Xen
>version? On Xen 4.5.0-rc1 I don't see any problems.
>
>
>On Thu, 6 Nov 2014, Steven Haigh wrote:
>> Hi Stefano,
>>
>> It seems that this patch fixes the grub issue for me. I no longer get
>> the infinite wait at the grub prompt.
>>
>> On 6/11/2014 4:49 AM, Stefano Stabellini wrote:
>> > Hello Steven,
>> > I have found some time to debug this myself.
>> > I couldn't reproduce the booting issue that you reported: in my
>case
>> > after seeing the grub boot menu I can successfully boot the kernel
>> > without problems.
>> >
>> > However I can reproduce the timeout issue that you are seeing: the
>> > timeout doesn't work properly in graphics mode.
>> >
>> > The reason is that the with a graphics terminal you checkkey ()
>return 0
>> > even when pressing no keys, resulting in wrong behaviour in
>run_menu.
>> >
>> > Does the following patch (also attached) fixes your issues?
>> >
>> >
>> > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff
>b/stubdom/grub.patches/11graphics-keyboard.diff
>> > new file mode 100644
>> > index 0000000..fe17b20
>> > --- /dev/null
>> > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
>> > @@ -0,0 +1,13 @@
>> > +diff --git a/stage2/stage2.c b/stage2/stage2.c
>> > +index 9d9fcc3..8353a3b 100644
>> > +--- a/stage2/stage2.c
>> > ++++ b/stage2/stage2.c
>> > +@@ -395,7 +395,7 @@ restart:
>> > + 	 pressed.
>> > + 	 This avoids polling (relevant in the grub-shell and later on
>> > + 	 in grub if interrupt driven I/O is done).  */
>> > +-      if (checkkey () >= 0 || grub_timeout < 0)
>> > ++      if (checkkey () > 0 || grub_timeout < 0)
>> > + 	{
>> > + 	  /* Key was pressed, show which entry is selected before
>GETKEY,
>> > + 	     since we're comming in here also on GRUB_TIMEOUT == -1 and
>> >
>> >
>> >
>> > On Thu, 23 Oct 2014, Steven Haigh wrote:
>> >> On 23/10/2014 2:40 AM, Ian Campbell wrote:
>> >>> On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
>> >>>
>> >>>> Output using pv-grub:
>> >>>
>> >>> Can you also post the qemu logs please (under /var/log/xen
>somewhere I
>> >>> think).
>> >>
>> >> I get very little out of this:
>> >> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
>> >> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
>> >> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
>> >> [root@dom0 xen]# cat xl-dev.vm.log
>> >> Waiting for domain dev.vm (domid 36) to die [pid 6970]
>> >>
>> >> That's it :\
>> >>
>> >>>> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
>> >>>> 00007fffb4573638 error 4
>> >>>
>> >>> That might be a smoking gun. Is there a core dump and/or could
>you try
>> >>> and run qemu under gdb?
>> >>
>> >> Any hints on doing this? I can't say I'm a gdb guru.... I can't
>find any
>> >> core dumps anywhere so that's not really helpful...
>> >>
>> >> --
>> >> Steven Haigh
>> >>
>> >> Email: netwiz@crc.id.au
>> >> Web: http://www.crc.id.au
>> >> Phone: (03) 9001 6090 - 0412 935 897
>> >>
>>
>> --
>> Steven Haigh
>>
>> Email: netwiz@crc.id.au
>> Web: http://www.crc.id.au
>> Phone: (03) 9001 6090 - 0412 935 897
>>
>>

- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI9BAEBCgAnBQJUW1XtIBxTdGV2ZW4gSGFpZ2ggPG5ldHdpekBjcmMuaWQuYXU+
AAoJEEGvNdV6fTHcIr4QAKvTrrgaa4zpXxlw3wfvm3bIdYuVbaW3qEeXWWuFwEC7
13cdLPEil04PhJPW/8q/S8T/2V6vEYvlrQMgPWbcTrCfZJ6KxNN5WQJzP/aJ0s9y
IWRizMx3fD+rgQGqE/HEqvSHX7ME2rhLHIHkpAw+q/KV97t76W6n8QOKFAtrwD1+
dcgcuCVdQmra2/RzC/fu028vyFJ63ZBoNyJzD/6MfyseskUL3EYfimiKOnZpXBz0
BeLa8Dyc7UgiTg3yoXJU7+m2V80r+4oBD2kbs+eMBWwY1a/fUzLe3xITxKprBp2c
lKyap/sUJJIs17fsr1VpmoCnyQCFUzDVdms9kU8RaivwVCpCqSdtPNLkiqXZmhqX
DKJ3P2xBDdwz/SH30/fIL+S7o43LfjVl2CbEdj6/t1HN/0iPRWt2BTr/HtoGt+t+
fWedzx0pfwl8C4dd9Ac3aGojnT9UwB4Na9pPVSsLgK5SuXT0pRYU4tpZ46oZNirt
bJBFcR9xrLWcH+a9k5HydruPXf6sCVmV/kwUB+mngECeiifEP2ILQN1psyls66+w
BKwrQlYKf4wJf3EfsV7soPa+GLL0rQLpLV8P+O5UHJ0W62VCzetpKonDVyuxA13o
jCFC+POP4c0dGo4sfGk5IDeh7s0z/PIpd/VjG/sgHt2AU2QWy2FOItxM+eYPq9SN
=2gPy
-----END PGP SIGNATURE-----


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:31:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:31:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLHb-0003B1-G5; Thu, 06 Nov 2014 11:31:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLHa-0003Aw-1B
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:31:18 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	C7/E7-02698-50C5B545; Thu, 06 Nov 2014 11:31:17 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415273474!11758056!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23979 invoked from network); 6 Nov 2014 11:31:15 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:31:15 -0000
Received: from mail-qg0-f41.google.com ([209.85.192.41]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtcAdUdus2LoE49AmAntspx0aoSg046@postini.com;
	Thu, 06 Nov 2014 03:31:15 PST
Received: by mail-qg0-f41.google.com with SMTP id q107so551338qgd.0
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:31:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=MfIZwnRBg1MEI9/4BGQBDguZFsF4NK1HVlKZfOPKRy4=;
	b=XZ21l6RnwBR2s1a3AyDEhUKzmxkxQ27nPSMyxrPVzPSO2SfzpLGL4ZkvDC3HQeRsCf
	ONlVIoNrUlu2jcLEorsis+lkkBewHXv/DVd4+iG2pXjCQPavt9IDNpYEf1Uvt6cQ4fuN
	rL3pOodlp6oiAEHMyDUsJ8iRaQMdM/6NCpft0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=MfIZwnRBg1MEI9/4BGQBDguZFsF4NK1HVlKZfOPKRy4=;
	b=R5DPgluGOTM3spysb1rEOtkYx7K0DrECHLoJBDbse4/qLJccNAEIR7D0IADIeR5s5/
	hpbiXF09SS9aA2nu8uaYlaVJT3wz3jQ5WVmn83wjioxlFX1ZZF4BgfjiwJS/hPt0qfnb
	gZXwY+qY2a6enD2wpI3hoHaeqPoNbhYGgjYoSnS1mpmQE9h3r4V9ndkmwP2AZIjOKW90
	QoMBMQWNZKh/SDtHRvby3bcYtGZq3GG5ZM7cSBuZUDq9Zo8FS6CFIkoAhQzhrqlj3pvf
	P0O/3KN5A1CCCMZqE6mqu9qM1510w1qcYZLuVj7UfNnpVYzEssGnKT3CtJZVUNL//Il2
	Ifng==
X-Gm-Message-State: ALoCoQmqqRIkY6JSooT3wuooL5lGcgk26Jnn98gKMj+bGjjOigW1qI5Reexau1eZbbBGjtNDNRI1v1iRg987MhfKS0Wj1bgx+GKI2yGQzk1p4cKL5E1dJIAzj97gSla+gKc9WrrJ+heq2GvkZC1l6ZpiYR1XqNDWjw==
X-Received: by 10.224.112.66 with SMTP id v2mr5636378qap.22.1415273473354;
	Thu, 06 Nov 2014 03:31:13 -0800 (PST)
X-Received: by 10.224.112.66 with SMTP id v2mr5636244qap.22.1415273472348;
	Thu, 06 Nov 2014 03:31:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:30:52 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041612330.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041612330.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:30:52 +0200
Message-ID: <CAN58jiuLjaSSaPhSEiq4O1uGk8OchFezknQ-8GKnbfgkHByySA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 10/11] cpufreq: add hwdom-cpufreq
	driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:13 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> This driver uses hwdom to change frequencies on CPUs
>> Workflow:
>>  * cpufreq governor driver in Xen wants to change the
>>    frequency of the physical CPU
>>  * hwdom-cpufreq driver sets parameters in the shared
>>    memory
>>  * hwdom-cpufreq driver sends an VIRQ_CPUFREQ interrupt
>>    to notify the hardware domain
>>  * cpufreq driver in the hardware domain reads parameters
>>    from the shared memory, changes frequency and copies
>>    the result of the operation to the shared memory
>>
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> ---
>>  xen/Rules.mk                        |   1 +
>>  xen/drivers/cpufreq/Makefile        |   1 +
>>  xen/drivers/cpufreq/hwdom-cpufreq.c | 252 ++++++++++++++++++++++++++++++++++++
>>  xen/include/public/xen.h            |   1 +
>>  4 files changed, 255 insertions(+)
>>  create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c
>>
>> diff --git a/xen/Rules.mk b/xen/Rules.mk
>> index 3b0b89b..cccbc72 100644
>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>>  CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
>> +CFLAGS-$(HAS_HWDOM_CPUFREQ) += -DHAS_HWDOM_CPUFREQ
>>  CFLAGS-$(HAS_PM)        += -DHAS_PM
>>  CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
>>  CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>> diff --git a/xen/drivers/cpufreq/Makefile b/xen/drivers/cpufreq/Makefile
>> index b87d127..891997c 100644
>> --- a/xen/drivers/cpufreq/Makefile
>> +++ b/xen/drivers/cpufreq/Makefile
>> @@ -2,3 +2,4 @@ obj-y += cpufreq.o
>>  obj-y += cpufreq_ondemand.o
>>  obj-y += cpufreq_misc_governors.o
>>  obj-y += utility.o
>> +obj-$(HAS_HWDOM_CPUFREQ) += hwdom-cpufreq.o
>> diff --git a/xen/drivers/cpufreq/hwdom-cpufreq.c b/xen/drivers/cpufreq/hwdom-cpufreq.c
>> new file mode 100644
>> index 0000000..a39fc6c
>> --- /dev/null
>> +++ b/xen/drivers/cpufreq/hwdom-cpufreq.c
>> @@ -0,0 +1,252 @@
>> +/*
>> + *  Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
>> + *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
>> + *  Copyright (C) 2002 - 2004 Dominik Brodowski <linux@brodo.de>
>> + *  Copyright (C) 2006        Denis Sadykov <denis.m.sadykov@intel.com>
>> + *
>> + *  Feb 2008 - Liu Jinsong <jinsong.liu@intel.com>
>> + *      porting acpi-cpufreq.c from Linux 2.6.23 to Xen hypervisor
>> + *
>> + *  Copyright (C) 2014 GlobalLogic Inc.
>> + *
>> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + *
>> + *  This program is free software; you can redistribute it and/or modify
>> + *  it under the terms of the GNU General Public License as published by
>> + *  the Free Software Foundation; either version 2 of the License, or (at
>> + *  your option) any later version.
>> + *
>> + *  This program is distributed in the hope that it will be useful, but
>> + *  WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + *  General Public License for more details.
>> + *
>> + *  You should have received a copy of the GNU General Public License along
>> + *  with this program; if not, write to the Free Software Foundation, Inc.,
>> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
>> + *
>> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + */
>> +#include <xen/types.h>
>> +#include <xen/errno.h>
>> +#include <xen/sched.h>
>> +#include <xen/event.h>
>> +#include <xen/irq.h>
>> +#include <xen/spinlock.h>
>> +#include <xen/cpufreq.h>
>> +#include <xen/err.h>
>> +#include <asm/shared.h>
>> +#include <asm/current.h>
>> +#include <asm/system.h>
>> +
>> +struct hwdom_cpufreq_data {
>> +    struct processor_performance *perf_data;
>> +    struct cpufreq_frequency_table *freq_table;
>> +};
>> +
>> +static struct hwdom_cpufreq_data *hwdom_cpufreq_drv_data[NR_CPUS];
>> +
>> +int cpufreq_cpu_init(unsigned int cpuid)
>> +{
>> +    return cpufreq_add_cpu(cpuid);
>> +}
>> +
>> +static void notify_cpufreq_domain(void)
>> +{
>> +    send_global_virq(VIRQ_CPUFREQ);
>> +}
>> +
>> +static int hwdom_cpufreq_verify(struct cpufreq_policy *policy)
>> +{
>> +    struct hwdom_cpufreq_data *data;
>> +    struct processor_performance *perf;
>> +
>> +    if ( !policy || !(data = hwdom_cpufreq_drv_data[policy->cpu]) ||
>> +         !processor_pminfo[policy->cpu] )
>> +        return -EINVAL;
>> +
>> +    perf = &processor_pminfo[policy->cpu]->perf;
>> +
>> +    cpufreq_verify_within_limits(policy, 0,
>> +        perf->states[perf->platform_limit].core_frequency * 1000);
>> +
>> +    return cpufreq_frequency_table_verify(policy, data->freq_table);
>> +}
>> +
>> +static int hwdom_cpufreq_target(struct cpufreq_policy *policy,
>> +                               unsigned int target_freq, unsigned int relation)
>> +{
>> +    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
>> +    struct processor_performance *perf;
>> +    struct cpufreq_freqs freqs;
>> +    struct cpufreq_sh_info *cpufreq_info;
>> +    cpumask_t online_policy_cpus;
>> +    unsigned int next_state = 0; /* Index into freq_table */
>> +    unsigned int next_perf_state = 0; /* Index into perf table */
>> +    unsigned int j;
>> +    int ret = 0;
>> +
>> +    if ( unlikely(data == NULL ||
>> +         data->perf_data == NULL || data->freq_table == NULL) )
>> +        return -ENODEV;
>> +
>> +    perf = data->perf_data;
>> +    ret = cpufreq_frequency_table_target(policy,
>> +                                         data->freq_table,
>> +                                         target_freq,
>> +                                         relation, &next_state);
>> +    if ( unlikely(ret) )
>> +        return -ENODEV;
>> +
>> +    cpumask_and(&online_policy_cpus, &cpu_online_map, policy->cpus);
>> +
>> +    next_perf_state = data->freq_table[next_state].index;
>> +    if ( perf->state == next_perf_state )
>> +    {
>> +        if ( unlikely(policy->resume) )
>> +            policy->resume = 0;
>> +        else
>> +            return 0;
>> +    }
>> +
>> +    freqs.old = perf->states[perf->state].core_frequency * 1000;
>> +    freqs.new = data->freq_table[next_state].frequency;
>> +
>> +     /* Do send cmd for Hardware domain */
>> +    cpufreq_info = arch_get_cpufreq_addr(dom0);
>> +
>> +    /* Set previous result in the Hardware domain then read it */
>> +    smp_rmb();
>> +
>> +     /* return previous result */
>> +    ret = cpufreq_info->result;
>
> What if the previous command hasn't completed yet?
I'll create an event channel between Xen and hwdom.
In this case global VIRQ_CPUFREQ will not be needed and Xen and hwdom
will be able to send notification to each other,


>> +    cpufreq_info->cpu = policy->cpu;
>> +    cpufreq_info->freq = freqs.new;
>> +    cpufreq_info->relation = (uint32_t)relation;
>> +
>> +    smp_wmb(); /* above must be visible before notify_cpufreq_domain() */
>> +
>> +    notify_cpufreq_domain();
>> +
>> +    for_each_cpu( j, &online_policy_cpus )
>> +        cpufreq_statistic_update(j, perf->state, next_perf_state);
>> +
>> +    perf->state = next_perf_state;
>> +    policy->cur = freqs.new;
>> +
>> +    return ret;
>> +}
>> +
>> +static int
>> +hwdom_cpufreq_cpu_init(struct cpufreq_policy *policy)
>> +{
>> +    struct processor_performance *perf;
>> +    struct hwdom_cpufreq_data *data;
>> +    unsigned int cpu = policy->cpu;
>> +    unsigned int valid_states = 0;
>> +    int i;
>> +    int ret = 0;
>> +
>> +    data = xzalloc(struct hwdom_cpufreq_data);
>> +    if ( !data )
>> +        return -ENOMEM;
>> +
>> +    hwdom_cpufreq_drv_data[cpu] = data;
>> +
>> +    data->perf_data = &processor_pminfo[cpu]->perf;
>> +
>> +    perf = data->perf_data;
>> +    policy->shared_type = perf->shared_type;
>> +
>> +    data->freq_table = xmalloc_array(struct cpufreq_frequency_table,
>> +                                     (perf->state_count+1));
>> +    if ( !data->freq_table )
>> +    {
>> +        ret = -ENOMEM;
>> +        goto err_unreg;
>> +    }
>> +
>> +    /* detect transition latency */
>> +    policy->cpuinfo.transition_latency = 0;
>> +    for ( i = 0; i < perf->state_count; i++ )
>> +    {
>> +        if ( (perf->states[i].transition_latency * 1000) >
>> +             policy->cpuinfo.transition_latency )
>> +            policy->cpuinfo.transition_latency =
>> +                perf->states[i].transition_latency * 1000;
>> +    }
>> +
>> +    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
>> +
>> +    /* table init */
>> +    for ( i = 0; i < perf->state_count; i++ )
>> +    {
>> +        if ( i > 0 && perf->states[i].core_frequency >=
>> +            data->freq_table[valid_states-1].frequency / 1000 )
>> +            continue;
>> +
>> +        data->freq_table[valid_states].index = i;
>> +        data->freq_table[valid_states].frequency =
>> +            perf->states[i].core_frequency * 1000;
>> +        valid_states++;
>> +    }
>> +    data->freq_table[valid_states].frequency = CPUFREQ_TABLE_END;
>> +    perf->state = 0;
>> +
>> +    ret = cpufreq_frequency_table_cpuinfo(policy, data->freq_table);
>> +    if ( ret )
>> +        goto err_freqfree;
>> +
>> +
>> +    /*
>> +     * the first call to ->target() should result in us actually
>> +     * send command to the Hardware domain to set frequency.
>> +     */
>> +    policy->resume = 1;
>> +
>> +    /* Set the minimal frequency */
>> +    return hwdom_cpufreq_target(policy, policy->min, CPUFREQ_RELATION_L);
>> +
>> + err_freqfree:
>> +    xfree(data->freq_table);
>> + err_unreg:
>> +    xfree(data);
>> +    hwdom_cpufreq_drv_data[cpu] = NULL;
>> +
>> +    return ret;
>> +}
>> +
>> +static int hwdom_cpufreq_cpu_exit(struct cpufreq_policy *policy)
>> +{
>> +    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
>> +
>> +    if ( data )
>> +    {
>> +        hwdom_cpufreq_drv_data[policy->cpu] = NULL;
>> +        xfree(data->freq_table);
>> +        xfree(data);
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +static struct cpufreq_driver hwdom_cpufreq_driver = {
>> +    .name   = "hwdom-cpufreq",
>> +    .verify = hwdom_cpufreq_verify,
>> +    .target = hwdom_cpufreq_target,
>> +    .init   = hwdom_cpufreq_cpu_init,
>> +    .exit   = hwdom_cpufreq_cpu_exit,
>> +};
>> +
>> +static int __init hwdom_cpufreq_driver_init(void)
>> +{
>> +    int ret = 0;
>> +
>> +    if ( cpufreq_controller == FREQCTL_xen )
>> +        ret = cpufreq_register_driver(&hwdom_cpufreq_driver);
>> +
>> +    return ret;
>> +}
>> +
>> +__initcall(hwdom_cpufreq_driver_init);
>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>> index 8c5697e..abd8438 100644
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -160,6 +160,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>>  #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       */
>> +#define VIRQ_CPUFREQ    14 /* G. (DOM0) Notify cpufreq driver                */
>>
>>  /* Architecture-specific VIRQ definitions. */
>>  #define VIRQ_ARCH_0    16
>> --
>> 1.9.1
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:31:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:31:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLHo-0003C4-0w; Thu, 06 Nov 2014 11:31:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XmLHm-0003Bp-Gw
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 11:31:30 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	F1/2B-17694-11C5B545; Thu, 06 Nov 2014 11:31:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415273489!10845753!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19376 invoked from network); 6 Nov 2014 11:31:29 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:31:29 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 06 Nov 2014 11:31:28 +0000
Message-Id: <545B6A2002000078000454EC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 06 Nov 2014 11:31:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-31385-mainreport@xen.org>
In-Reply-To: <osstest-31385-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.11.14 at 20:02, <Ian.Jackson@eu.citrix.com> wrote:
> flight 31385 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31385/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Ian,

so this continues to be a result of swiotlb issues on the source host.
Iirc you had indicated you took care of this - did that perhaps only
affect -unstable?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:31:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:31:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLHb-0003B1-G5; Thu, 06 Nov 2014 11:31:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLHa-0003Aw-1B
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:31:18 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	C7/E7-02698-50C5B545; Thu, 06 Nov 2014 11:31:17 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415273474!11758056!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23979 invoked from network); 6 Nov 2014 11:31:15 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:31:15 -0000
Received: from mail-qg0-f41.google.com ([209.85.192.41]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtcAdUdus2LoE49AmAntspx0aoSg046@postini.com;
	Thu, 06 Nov 2014 03:31:15 PST
Received: by mail-qg0-f41.google.com with SMTP id q107so551338qgd.0
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:31:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=MfIZwnRBg1MEI9/4BGQBDguZFsF4NK1HVlKZfOPKRy4=;
	b=XZ21l6RnwBR2s1a3AyDEhUKzmxkxQ27nPSMyxrPVzPSO2SfzpLGL4ZkvDC3HQeRsCf
	ONlVIoNrUlu2jcLEorsis+lkkBewHXv/DVd4+iG2pXjCQPavt9IDNpYEf1Uvt6cQ4fuN
	rL3pOodlp6oiAEHMyDUsJ8iRaQMdM/6NCpft0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=MfIZwnRBg1MEI9/4BGQBDguZFsF4NK1HVlKZfOPKRy4=;
	b=R5DPgluGOTM3spysb1rEOtkYx7K0DrECHLoJBDbse4/qLJccNAEIR7D0IADIeR5s5/
	hpbiXF09SS9aA2nu8uaYlaVJT3wz3jQ5WVmn83wjioxlFX1ZZF4BgfjiwJS/hPt0qfnb
	gZXwY+qY2a6enD2wpI3hoHaeqPoNbhYGgjYoSnS1mpmQE9h3r4V9ndkmwP2AZIjOKW90
	QoMBMQWNZKh/SDtHRvby3bcYtGZq3GG5ZM7cSBuZUDq9Zo8FS6CFIkoAhQzhrqlj3pvf
	P0O/3KN5A1CCCMZqE6mqu9qM1510w1qcYZLuVj7UfNnpVYzEssGnKT3CtJZVUNL//Il2
	Ifng==
X-Gm-Message-State: ALoCoQmqqRIkY6JSooT3wuooL5lGcgk26Jnn98gKMj+bGjjOigW1qI5Reexau1eZbbBGjtNDNRI1v1iRg987MhfKS0Wj1bgx+GKI2yGQzk1p4cKL5E1dJIAzj97gSla+gKc9WrrJ+heq2GvkZC1l6ZpiYR1XqNDWjw==
X-Received: by 10.224.112.66 with SMTP id v2mr5636378qap.22.1415273473354;
	Thu, 06 Nov 2014 03:31:13 -0800 (PST)
X-Received: by 10.224.112.66 with SMTP id v2mr5636244qap.22.1415273472348;
	Thu, 06 Nov 2014 03:31:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:30:52 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041612330.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041612330.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:30:52 +0200
Message-ID: <CAN58jiuLjaSSaPhSEiq4O1uGk8OchFezknQ-8GKnbfgkHByySA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 10/11] cpufreq: add hwdom-cpufreq
	driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:13 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> This driver uses hwdom to change frequencies on CPUs
>> Workflow:
>>  * cpufreq governor driver in Xen wants to change the
>>    frequency of the physical CPU
>>  * hwdom-cpufreq driver sets parameters in the shared
>>    memory
>>  * hwdom-cpufreq driver sends an VIRQ_CPUFREQ interrupt
>>    to notify the hardware domain
>>  * cpufreq driver in the hardware domain reads parameters
>>    from the shared memory, changes frequency and copies
>>    the result of the operation to the shared memory
>>
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> ---
>>  xen/Rules.mk                        |   1 +
>>  xen/drivers/cpufreq/Makefile        |   1 +
>>  xen/drivers/cpufreq/hwdom-cpufreq.c | 252 ++++++++++++++++++++++++++++++++++++
>>  xen/include/public/xen.h            |   1 +
>>  4 files changed, 255 insertions(+)
>>  create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c
>>
>> diff --git a/xen/Rules.mk b/xen/Rules.mk
>> index 3b0b89b..cccbc72 100644
>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>>  CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
>> +CFLAGS-$(HAS_HWDOM_CPUFREQ) += -DHAS_HWDOM_CPUFREQ
>>  CFLAGS-$(HAS_PM)        += -DHAS_PM
>>  CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
>>  CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>> diff --git a/xen/drivers/cpufreq/Makefile b/xen/drivers/cpufreq/Makefile
>> index b87d127..891997c 100644
>> --- a/xen/drivers/cpufreq/Makefile
>> +++ b/xen/drivers/cpufreq/Makefile
>> @@ -2,3 +2,4 @@ obj-y += cpufreq.o
>>  obj-y += cpufreq_ondemand.o
>>  obj-y += cpufreq_misc_governors.o
>>  obj-y += utility.o
>> +obj-$(HAS_HWDOM_CPUFREQ) += hwdom-cpufreq.o
>> diff --git a/xen/drivers/cpufreq/hwdom-cpufreq.c b/xen/drivers/cpufreq/hwdom-cpufreq.c
>> new file mode 100644
>> index 0000000..a39fc6c
>> --- /dev/null
>> +++ b/xen/drivers/cpufreq/hwdom-cpufreq.c
>> @@ -0,0 +1,252 @@
>> +/*
>> + *  Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
>> + *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
>> + *  Copyright (C) 2002 - 2004 Dominik Brodowski <linux@brodo.de>
>> + *  Copyright (C) 2006        Denis Sadykov <denis.m.sadykov@intel.com>
>> + *
>> + *  Feb 2008 - Liu Jinsong <jinsong.liu@intel.com>
>> + *      porting acpi-cpufreq.c from Linux 2.6.23 to Xen hypervisor
>> + *
>> + *  Copyright (C) 2014 GlobalLogic Inc.
>> + *
>> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + *
>> + *  This program is free software; you can redistribute it and/or modify
>> + *  it under the terms of the GNU General Public License as published by
>> + *  the Free Software Foundation; either version 2 of the License, or (at
>> + *  your option) any later version.
>> + *
>> + *  This program is distributed in the hope that it will be useful, but
>> + *  WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + *  General Public License for more details.
>> + *
>> + *  You should have received a copy of the GNU General Public License along
>> + *  with this program; if not, write to the Free Software Foundation, Inc.,
>> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
>> + *
>> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + */
>> +#include <xen/types.h>
>> +#include <xen/errno.h>
>> +#include <xen/sched.h>
>> +#include <xen/event.h>
>> +#include <xen/irq.h>
>> +#include <xen/spinlock.h>
>> +#include <xen/cpufreq.h>
>> +#include <xen/err.h>
>> +#include <asm/shared.h>
>> +#include <asm/current.h>
>> +#include <asm/system.h>
>> +
>> +struct hwdom_cpufreq_data {
>> +    struct processor_performance *perf_data;
>> +    struct cpufreq_frequency_table *freq_table;
>> +};
>> +
>> +static struct hwdom_cpufreq_data *hwdom_cpufreq_drv_data[NR_CPUS];
>> +
>> +int cpufreq_cpu_init(unsigned int cpuid)
>> +{
>> +    return cpufreq_add_cpu(cpuid);
>> +}
>> +
>> +static void notify_cpufreq_domain(void)
>> +{
>> +    send_global_virq(VIRQ_CPUFREQ);
>> +}
>> +
>> +static int hwdom_cpufreq_verify(struct cpufreq_policy *policy)
>> +{
>> +    struct hwdom_cpufreq_data *data;
>> +    struct processor_performance *perf;
>> +
>> +    if ( !policy || !(data = hwdom_cpufreq_drv_data[policy->cpu]) ||
>> +         !processor_pminfo[policy->cpu] )
>> +        return -EINVAL;
>> +
>> +    perf = &processor_pminfo[policy->cpu]->perf;
>> +
>> +    cpufreq_verify_within_limits(policy, 0,
>> +        perf->states[perf->platform_limit].core_frequency * 1000);
>> +
>> +    return cpufreq_frequency_table_verify(policy, data->freq_table);
>> +}
>> +
>> +static int hwdom_cpufreq_target(struct cpufreq_policy *policy,
>> +                               unsigned int target_freq, unsigned int relation)
>> +{
>> +    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
>> +    struct processor_performance *perf;
>> +    struct cpufreq_freqs freqs;
>> +    struct cpufreq_sh_info *cpufreq_info;
>> +    cpumask_t online_policy_cpus;
>> +    unsigned int next_state = 0; /* Index into freq_table */
>> +    unsigned int next_perf_state = 0; /* Index into perf table */
>> +    unsigned int j;
>> +    int ret = 0;
>> +
>> +    if ( unlikely(data == NULL ||
>> +         data->perf_data == NULL || data->freq_table == NULL) )
>> +        return -ENODEV;
>> +
>> +    perf = data->perf_data;
>> +    ret = cpufreq_frequency_table_target(policy,
>> +                                         data->freq_table,
>> +                                         target_freq,
>> +                                         relation, &next_state);
>> +    if ( unlikely(ret) )
>> +        return -ENODEV;
>> +
>> +    cpumask_and(&online_policy_cpus, &cpu_online_map, policy->cpus);
>> +
>> +    next_perf_state = data->freq_table[next_state].index;
>> +    if ( perf->state == next_perf_state )
>> +    {
>> +        if ( unlikely(policy->resume) )
>> +            policy->resume = 0;
>> +        else
>> +            return 0;
>> +    }
>> +
>> +    freqs.old = perf->states[perf->state].core_frequency * 1000;
>> +    freqs.new = data->freq_table[next_state].frequency;
>> +
>> +     /* Do send cmd for Hardware domain */
>> +    cpufreq_info = arch_get_cpufreq_addr(dom0);
>> +
>> +    /* Set previous result in the Hardware domain then read it */
>> +    smp_rmb();
>> +
>> +     /* return previous result */
>> +    ret = cpufreq_info->result;
>
> What if the previous command hasn't completed yet?
I'll create an event channel between Xen and hwdom.
In this case global VIRQ_CPUFREQ will not be needed and Xen and hwdom
will be able to send notification to each other,


>> +    cpufreq_info->cpu = policy->cpu;
>> +    cpufreq_info->freq = freqs.new;
>> +    cpufreq_info->relation = (uint32_t)relation;
>> +
>> +    smp_wmb(); /* above must be visible before notify_cpufreq_domain() */
>> +
>> +    notify_cpufreq_domain();
>> +
>> +    for_each_cpu( j, &online_policy_cpus )
>> +        cpufreq_statistic_update(j, perf->state, next_perf_state);
>> +
>> +    perf->state = next_perf_state;
>> +    policy->cur = freqs.new;
>> +
>> +    return ret;
>> +}
>> +
>> +static int
>> +hwdom_cpufreq_cpu_init(struct cpufreq_policy *policy)
>> +{
>> +    struct processor_performance *perf;
>> +    struct hwdom_cpufreq_data *data;
>> +    unsigned int cpu = policy->cpu;
>> +    unsigned int valid_states = 0;
>> +    int i;
>> +    int ret = 0;
>> +
>> +    data = xzalloc(struct hwdom_cpufreq_data);
>> +    if ( !data )
>> +        return -ENOMEM;
>> +
>> +    hwdom_cpufreq_drv_data[cpu] = data;
>> +
>> +    data->perf_data = &processor_pminfo[cpu]->perf;
>> +
>> +    perf = data->perf_data;
>> +    policy->shared_type = perf->shared_type;
>> +
>> +    data->freq_table = xmalloc_array(struct cpufreq_frequency_table,
>> +                                     (perf->state_count+1));
>> +    if ( !data->freq_table )
>> +    {
>> +        ret = -ENOMEM;
>> +        goto err_unreg;
>> +    }
>> +
>> +    /* detect transition latency */
>> +    policy->cpuinfo.transition_latency = 0;
>> +    for ( i = 0; i < perf->state_count; i++ )
>> +    {
>> +        if ( (perf->states[i].transition_latency * 1000) >
>> +             policy->cpuinfo.transition_latency )
>> +            policy->cpuinfo.transition_latency =
>> +                perf->states[i].transition_latency * 1000;
>> +    }
>> +
>> +    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
>> +
>> +    /* table init */
>> +    for ( i = 0; i < perf->state_count; i++ )
>> +    {
>> +        if ( i > 0 && perf->states[i].core_frequency >=
>> +            data->freq_table[valid_states-1].frequency / 1000 )
>> +            continue;
>> +
>> +        data->freq_table[valid_states].index = i;
>> +        data->freq_table[valid_states].frequency =
>> +            perf->states[i].core_frequency * 1000;
>> +        valid_states++;
>> +    }
>> +    data->freq_table[valid_states].frequency = CPUFREQ_TABLE_END;
>> +    perf->state = 0;
>> +
>> +    ret = cpufreq_frequency_table_cpuinfo(policy, data->freq_table);
>> +    if ( ret )
>> +        goto err_freqfree;
>> +
>> +
>> +    /*
>> +     * the first call to ->target() should result in us actually
>> +     * send command to the Hardware domain to set frequency.
>> +     */
>> +    policy->resume = 1;
>> +
>> +    /* Set the minimal frequency */
>> +    return hwdom_cpufreq_target(policy, policy->min, CPUFREQ_RELATION_L);
>> +
>> + err_freqfree:
>> +    xfree(data->freq_table);
>> + err_unreg:
>> +    xfree(data);
>> +    hwdom_cpufreq_drv_data[cpu] = NULL;
>> +
>> +    return ret;
>> +}
>> +
>> +static int hwdom_cpufreq_cpu_exit(struct cpufreq_policy *policy)
>> +{
>> +    struct hwdom_cpufreq_data *data = hwdom_cpufreq_drv_data[policy->cpu];
>> +
>> +    if ( data )
>> +    {
>> +        hwdom_cpufreq_drv_data[policy->cpu] = NULL;
>> +        xfree(data->freq_table);
>> +        xfree(data);
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +static struct cpufreq_driver hwdom_cpufreq_driver = {
>> +    .name   = "hwdom-cpufreq",
>> +    .verify = hwdom_cpufreq_verify,
>> +    .target = hwdom_cpufreq_target,
>> +    .init   = hwdom_cpufreq_cpu_init,
>> +    .exit   = hwdom_cpufreq_cpu_exit,
>> +};
>> +
>> +static int __init hwdom_cpufreq_driver_init(void)
>> +{
>> +    int ret = 0;
>> +
>> +    if ( cpufreq_controller == FREQCTL_xen )
>> +        ret = cpufreq_register_driver(&hwdom_cpufreq_driver);
>> +
>> +    return ret;
>> +}
>> +
>> +__initcall(hwdom_cpufreq_driver_init);
>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>> index 8c5697e..abd8438 100644
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -160,6 +160,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>>  #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       */
>> +#define VIRQ_CPUFREQ    14 /* G. (DOM0) Notify cpufreq driver                */
>>
>>  /* Architecture-specific VIRQ definitions. */
>>  #define VIRQ_ARCH_0    16
>> --
>> 1.9.1
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:31:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:31:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLHo-0003C4-0w; Thu, 06 Nov 2014 11:31:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XmLHm-0003Bp-Gw
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 11:31:30 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	F1/2B-17694-11C5B545; Thu, 06 Nov 2014 11:31:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415273489!10845753!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19376 invoked from network); 6 Nov 2014 11:31:29 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:31:29 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 06 Nov 2014 11:31:28 +0000
Message-Id: <545B6A2002000078000454EC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 06 Nov 2014 11:31:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-31385-mainreport@xen.org>
In-Reply-To: <osstest-31385-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.11.14 at 20:02, <Ian.Jackson@eu.citrix.com> wrote:
> flight 31385 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31385/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Ian,

so this continues to be a result of swiotlb issues on the source host.
Iirc you had indicated you took care of this - did that perhaps only
affect -unstable?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:33:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:33:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLK3-0003ZZ-K2; Thu, 06 Nov 2014 11:33:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLK2-0003ZK-8k
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:33:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	98/F9-09936-C9C5B545; Thu, 06 Nov 2014 11:33:48 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415273624!3878580!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2578 invoked from network); 6 Nov 2014 11:33:46 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:33:46 -0000
Received: from mail-qg0-f45.google.com ([209.85.192.45]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtcmMPvlEjj+1gBdPLK44zX675NjNY6@postini.com;
	Thu, 06 Nov 2014 03:33:46 PST
Received: by mail-qg0-f45.google.com with SMTP id z107so534578qgd.32
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:33:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=leVoWbywfoCUhq4vCJ2R0/LjSFVefV54u6XKqBFieBE=;
	b=CDCm6CYnRpfjYtS2mt/+YVbAugsf/+QEl/Sm0qUixlanWX0r31+yekhEtujT056ib1
	PCzsQxc07mqsOtDEYTbvgMwBJl4+GPPA9EyiYO2Ag/6EYuh02QnzsJGhJA1zdSd5mgmG
	T4bsl2kCuWEjKyiv6t87bv4RimkP0kI0Yztls=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=leVoWbywfoCUhq4vCJ2R0/LjSFVefV54u6XKqBFieBE=;
	b=lhdpOvqoCa7NBk6m4FmtzpH9+Z1nnjkK0VBlJkT+rStvpyjRC+/eRgwUGFYWUnr2Q8
	NDIazbZqefk5ajkVm9oBZbaPTa628LyQ+wWNFmhSv/X+K7ZCD56pVmEU0JHfajwe2zna
	dT9PFeprjVGpIylMLZt4rJnDLeBWrnhefC7gLQpd3NmM66pf+EEIu5yc8LnHxCsnah88
	xpTZ7SDQaxdz6zHYfsqJVRq5bbho6+LDrxcePGjfQnTtXTs96k/JQiuPgJquj0nP+mOl
	UGo+7U5eogLYTCnWf2y+TGyD1Zr2F3TBtpvQY/wV6/KF99JC7DzbD+qw5FF8a74YgZ22
	0Z3A==
X-Gm-Message-State: ALoCoQkZ3YveUETCs3FlmRRXQfRLTiJLG23p5KLlrO02/CJ/mhvWzzr7dajs0PZMU6AzCEpCItkV0Yg4Y2ityB7OOecKX4UMDl8efZGycDDsynS/8QMZOgoCsjPMSly1CVjdowF1lyo/SpL6M/E3QDdz4/SyK5rJ+Q==
X-Received: by 10.140.39.113 with SMTP id u104mr5393436qgu.86.1415273624098;
	Thu, 06 Nov 2014 03:33:44 -0800 (PST)
X-Received: by 10.140.39.113 with SMTP id u104mr5393413qgu.86.1415273623965;
	Thu, 06 Nov 2014 03:33:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:33:23 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:33:23 +0200
Message-ID: <CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>
> Why?
I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.

>>  arch/arm/include/asm/xen/hypercall.h |   1 +
>>  arch/arm/include/asm/xen/interface.h |   2 +
>>  arch/arm/xen/enlighten.c             |   1 +
>>  arch/arm/xen/hypercall.S             |   1 +
>>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
>>  include/xen/interface/xen.h          |   6 +
>>  6 files changed, 657 insertions(+)
>>  create mode 100644 include/xen/interface/sysctl.h
>>
>> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> index c817c56..751869eb 100644
>> --- a/arch/arm/include/asm/xen/hypercall.h
>> +++ b/arch/arm/include/asm/xen/hypercall.h
>> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>>  int HYPERVISOR_tmem_op(void *arg);
>> +int HYPERVISOR_sysctl(void *arg);
>>
>>  static inline void
>>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
>> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
>> index 1151188..acf4b7a 100644
>> --- a/arch/arm/include/asm/xen/interface.h
>> +++ b/arch/arm/include/asm/xen/interface.h
>> @@ -19,6 +19,7 @@
>>       __DEFINE_GUEST_HANDLE(name, struct name)
>>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
>>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
>> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
>>
>>  #define set_xen_guest_handle(hnd, val)                       \
>>       do {                                            \
>> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
>>  DEFINE_GUEST_HANDLE(void);
>>  DEFINE_GUEST_HANDLE(uint64_t);
>>  DEFINE_GUEST_HANDLE(uint32_t);
>> +DEFINE_GUEST_HANDLE(uint8_t);
>>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>>
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index eb0d851..675f17a 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>>  EXPORT_SYMBOL_GPL(privcmd_call);
>> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> index d1cf7b7..a1276df 100644
>> --- a/arch/arm/xen/hypercall.S
>> +++ b/arch/arm/xen/hypercall.S
>> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>>  HYPERCALL2(physdev_op);
>>  HYPERCALL3(vcpu_op);
>>  HYPERCALL1(tmem_op);
>> +HYPERCALL1(sysctl);
>>
>>  ENTRY(privcmd_call)
>>       stmdb sp!, {r4}
>> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
>> new file mode 100644
>> index 0000000..1a8cf7a
>> --- /dev/null
>> +++ b/include/xen/interface/sysctl.h
>> @@ -0,0 +1,646 @@
>> +/******************************************************************************
>> + * sysctl.h
>> + *
>> + * System management operations. For use by node control stack.
>> + *
>> + * Reused from xen: xen/include/public/sysctl.h
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a copy
>> + * of this software and associated documentation files (the "Software"), to
>> + * deal in the Software without restriction, including without limitation the
>> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the Software is
>> + * furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
>> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> + * DEALINGS IN THE SOFTWARE.
>> + *
>> + * Copyright (c) 2002-2006, K Fraser
>> + * Copyright (c) 2014, GlobalLogic Inc.
>> + */
>> +
>> +#ifndef __XEN_PUBLIC_SYSCTL_H__
>> +#define __XEN_PUBLIC_SYSCTL_H__
>> +
>> +#include <xen/interface/xen.h>
>> +
>> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
>> +
>> +/*
>> + * Read console content from Xen buffer ring.
>> + */
>> +/* XEN_SYSCTL_readconsole */
>> +struct xen_sysctl_readconsole {
>> +     /* IN: Non-zero -> clear after reading. */
>> +     uint8_t clear;
>> +     /* IN: Non-zero -> start index specified by @index field. */
>> +     uint8_t incremental;
>> +     uint8_t pad0, pad1;
>> +     /*
>> +     * IN:  Start index for consuming from ring buffer (if @incremental);
>> +     * OUT: End index after consuming from ring buffer.
>> +     */
>> +     uint32_t index;
>> +     /* IN: Virtual address to write console data. */
>> +     GUEST_HANDLE_64(char) buffer;
>> +     /* IN: Size of buffer; OUT: Bytes written to buffer. */
>> +     uint32_t count;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
>> +
>> +/* Get trace buffers machine base address */
>> +/* XEN_SYSCTL_tbuf_op */
>> +struct xen_sysctl_tbuf_op {
>> +    /* IN variables */
>> +#define XEN_SYSCTL_TBUFOP_get_info     0
>> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
>> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
>> +#define XEN_SYSCTL_TBUFOP_set_size     3
>> +#define XEN_SYSCTL_TBUFOP_enable       4
>> +#define XEN_SYSCTL_TBUFOP_disable      5
>> +     uint32_t cmd;
>> +     /* IN/OUT variables */
>> +     struct xenctl_bitmap cpu_mask;
>> +     uint32_t             evt_mask;
>> +     /* OUT variables */
>> +     uint64_aligned_t buffer_mfn;
>> +     uint32_t size;  /* Also an IN variable! */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
>> +
>> +/*
>> + * Get physical information about the host machine
>> + */
>> +/* XEN_SYSCTL_physinfo */
>> + /* (x86) The platform supports HVM guests. */
>> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
>> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
>> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
>> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
>> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
>> +struct xen_sysctl_physinfo {
>> +     uint32_t threads_per_core;
>> +     uint32_t cores_per_socket;
>> +     uint32_t nr_cpus;     /* # CPUs currently online */
>> +     uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
>> +     uint32_t nr_nodes;    /* # nodes currently online */
>> +     uint32_t max_node_id; /* Largest possible node ID on this host */
>> +     uint32_t cpu_khz;
>> +     uint64_aligned_t total_pages;
>> +     uint64_aligned_t free_pages;
>> +     uint64_aligned_t scrub_pages;
>> +     uint64_aligned_t outstanding_pages;
>> +     uint32_t hw_cap[8];
>> +
>> +     /* XEN_SYSCTL_PHYSCAP_??? */
>> +     uint32_t capabilities;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
>> +
>> +/*
>> + * Get the ID of the current scheduler.
>> + */
>> +/* XEN_SYSCTL_sched_id */
>> +struct xen_sysctl_sched_id {
>> +     /* OUT variable */
>> +     uint32_t sched_id;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
>> +
>> +/* Interface for controlling Xen software performance counters. */
>> +/* XEN_SYSCTL_perfc_op */
>> +/* Sub-operations: */
>> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
>> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
>> +struct xen_sysctl_perfc_desc {
>> +     char         name[80];           /* name of perf counter */
>> +     uint32_t     nr_vals;            /* number of values for this counter */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
>> +
>> +struct xen_sysctl_perfc_op {
>> +     /* IN variables. */
>> +     uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
>> +     /* OUT variables. */
>> +     uint32_t       nr_counters;       /*  number of counters description  */
>> +     uint32_t       nr_vals;           /*  number of values  */
>> +     /* counter information (or NULL) */
>> +     GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
>> +     /* counter values (or NULL) */
>> +     GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
>> +
>> +/* Inject debug keys into Xen. */
>> +/* XEN_SYSCTL_debug_keys */
>> +struct xen_sysctl_debug_keys {
>> +     /* IN variables. */
>> +     GUEST_HANDLE_64(char) keys;
>> +     uint32_t nr_keys;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
>> +
>> +/* Get physical CPU information. */
>> +/* XEN_SYSCTL_getcpuinfo */
>> +struct xen_sysctl_cpuinfo {
>> +     uint64_aligned_t idletime;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
>> +struct xen_sysctl_getcpuinfo {
>> +     /* IN variables. */
>> +     uint32_t max_cpus;
>> +     GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
>> +     /* OUT variables. */
>> +     uint32_t nr_cpus;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
>> +
>> +/* XEN_SYSCTL_availheap */
>> +struct xen_sysctl_availheap {
>> +     /* IN variables. */
>> +     uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
>> +     uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
>> +     int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
>> +     /* OUT variables. */
>> +     uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
>> +
>> +/* XEN_SYSCTL_get_pmstat */
>> +struct pm_px_val {
>> +     uint64_aligned_t freq;        /* Px core frequency */
>> +     uint64_aligned_t residency;   /* Px residency time */
>> +     uint64_aligned_t count;       /* Px transition count */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
>> +
>> +struct pm_px_stat {
>> +     uint8_t total;        /* total Px states */
>> +     uint8_t usable;       /* usable Px states */
>> +     uint8_t last;         /* last Px state */
>> +     uint8_t cur;          /* current Px state */
>> +     GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
>> +     GUEST_HANDLE_64(pm_px_val) pt;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
>> +
>> +struct pm_cx_stat {
>> +     uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
>> +     uint32_t last;  /* last Cx state */
>> +     uint64_aligned_t idle_time;                 /* idle time from boot */
>> +     GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
>> +     GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
>> +     uint64_aligned_t pc2;
>> +     uint64_aligned_t pc3;
>> +     uint64_aligned_t pc6;
>> +     uint64_aligned_t pc7;
>> +     uint64_aligned_t cc3;
>> +     uint64_aligned_t cc6;
>> +     uint64_aligned_t cc7;
>> +};
>> +
>> +struct xen_sysctl_get_pmstat {
>> +#define PMSTAT_CATEGORY_MASK 0xf0
>> +#define PMSTAT_PX            0x10
>> +#define PMSTAT_CX            0x20
>> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
>> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
>> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
>> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
>> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
>> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
>> +     uint32_t type;
>> +     uint32_t cpuid;
>> +     union {
>> +             struct pm_px_stat getpx;
>> +             struct pm_cx_stat getcx;
>> +             /* other struct for tx, etc */
>> +     } u;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
>> +
>> +/* XEN_SYSCTL_cpu_hotplug */
>> +struct xen_sysctl_cpu_hotplug {
>> +     /* IN variables */
>> +     uint32_t cpu;   /* Physical cpu. */
>> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
>> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
>> +     uint32_t op;    /* hotplug opcode */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
>> +
>> +/*
>> + * Get/set xen power management, include
>> + * 1. cpufreq governors and related parameters
>> + */
>> +/* XEN_SYSCTL_pm_op */
>> +struct xen_userspace {
>> +     uint32_t scaling_setspeed;
>> +};
>> +
>> +struct xen_ondemand {
>> +     uint32_t sampling_rate_max;
>> +     uint32_t sampling_rate_min;
>> +
>> +     uint32_t sampling_rate;
>> +     uint32_t up_threshold;
>> +};
>> +
>> +/*
>> + * cpufreq para name of this structure named
>> + * same as sysfs file name of native linux
>> + */
>> +#define CPUFREQ_NAME_LEN 16
>> +struct xen_get_cpufreq_para {
>> +     /* IN/OUT variable */
>> +     uint32_t cpu_num;
>> +     uint32_t freq_num;
>> +     uint32_t gov_num;
>> +
>> +     /* for all governors */
>> +     /* OUT variable */
>> +     GUEST_HANDLE_64(uint32_t) affected_cpus;
>> +     GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
>> +     GUEST_HANDLE_64(char)   scaling_available_governors;
>> +     char scaling_driver[CPUFREQ_NAME_LEN];
>> +
>> +     uint32_t cpuinfo_cur_freq;
>> +     uint32_t cpuinfo_max_freq;
>> +     uint32_t cpuinfo_min_freq;
>> +     uint32_t scaling_cur_freq;
>> +
>> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> +     uint32_t scaling_max_freq;
>> +     uint32_t scaling_min_freq;
>> +
>> +     /* for specific governor */
>> +     union {
>> +             struct  xen_userspace userspace;
>> +             struct  xen_ondemand ondemand;
>> +     } u;
>> +
>> +     int32_t turbo_enabled;
>> +};
>> +
>> +struct xen_set_cpufreq_gov {
>> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> +};
>> +
>> +struct xen_set_cpufreq_para {
>> +     #define SCALING_MAX_FREQ           1
>> +     #define SCALING_MIN_FREQ           2
>> +     #define SCALING_SETSPEED           3
>> +     #define SAMPLING_RATE              4
>> +     #define UP_THRESHOLD               5
>> +
>> +     uint32_t ctrl_type;
>> +     uint32_t ctrl_value;
>> +};
>> +
>> +struct xen_sysctl_pm_op {
>> +     #define PM_PARA_CATEGORY_MASK      0xf0
>> +     #define CPUFREQ_PARA               0x10
>> +
>> +     /* cpufreq command type */
>> +     #define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
>> +     #define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
>> +     #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
>> +     #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
>> +
>> +     /* set/reset scheduler power saving option */
>> +     #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
>> +
>> +     /* cpuidle max_cstate access command */
>> +     #define XEN_SYSCTL_pm_op_get_max_cstate       0x22
>> +     #define XEN_SYSCTL_pm_op_set_max_cstate       0x23
>> +
>> +     /* set scheduler migration cost value */
>> +     #define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
>> +     #define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
>> +
>> +     /* enable/disable turbo mode when in dbs governor */
>> +     #define XEN_SYSCTL_pm_op_enable_turbo               0x26
>> +     #define XEN_SYSCTL_pm_op_disable_turbo              0x27
>> +
>> +     uint32_t cmd;
>> +     uint32_t cpuid;
>> +     union {
>> +             struct xen_get_cpufreq_para get_para;
>> +             struct xen_set_cpufreq_gov  set_gov;
>> +             struct xen_set_cpufreq_para set_para;
>> +             uint64_aligned_t get_avgfreq;
>> +             uint32_t                    set_sched_opt_smt;
>> +             uint32_t                    get_max_cstate;
>> +             uint32_t                    set_max_cstate;
>> +             uint32_t                    get_vcpu_migration_delay;
>> +             uint32_t                    set_vcpu_migration_delay;
>> +     } u;
>> +};
>> +
>> +/* XEN_SYSCTL_page_offline_op */
>> +struct xen_sysctl_page_offline_op {
>> +     /* IN: range of page to be offlined */
>> +#define sysctl_page_offline     1
>> +#define sysctl_page_online      2
>> +#define sysctl_query_page_offline  3
>> +     uint32_t cmd;
>> +     uint32_t start;
>> +     uint32_t end;
>> +     /* OUT: result of page offline request */
>> +     /*
>> +     * bit 0~15: result flags
>> +     * bit 16~31: owner
>> +     */
>> +     GUEST_HANDLE(uint32_t) status;
>> +};
>> +
>> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
>> +
>> +/* The result is invalid, i.e. HV does not handle it */
>> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
>> +
>> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
>> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
>> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
>> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
>> +
>> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
>> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
>> +
>> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
>> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
>> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
>> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
>> +
>> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
>> +
>> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
>> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
>> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
>> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
>> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
>> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
>> +
>> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
>> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
>> +
>> +#define PG_OFFLINE_OWNER_SHIFT 16
>> +
>> +/* XEN_SYSCTL_lockprof_op */
>> +/* Sub-operations: */
>> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
>> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
>> +/* Record-type: */
>> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
>> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
>> +#define LOCKPROF_TYPE_N           2   /* number of types */
>> +struct xen_sysctl_lockprof_data {
>> +     char     name[40];   /* lock name (may include up to 2 %d specifiers) */
>> +     int32_t  type;       /* LOCKPROF_TYPE_??? */
>> +     int32_t  idx;        /* index (e.g. domain id) */
>> +     uint64_aligned_t lock_cnt;     /* # of locking succeeded */
>> +     uint64_aligned_t block_cnt;    /* # of wait for lock */
>> +     uint64_aligned_t lock_time;    /* nsecs lock held */
>> +     uint64_aligned_t block_time;   /* nsecs waited for lock */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
>> +
>> +struct xen_sysctl_lockprof_op {
>> +     /* IN variables. */
>> +     uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
>> +     uint32_t       max_elem;          /* size of output buffer */
>> +     /* OUT variables (query only). */
>> +     uint32_t       nr_elem;           /* number of elements available */
>> +     uint64_aligned_t time;            /* nsecs of profile measurement */
>> +     /* profile information (or NULL) */
>> +     GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
>> +
>> +/* XEN_SYSCTL_topologyinfo */
>> +#define INVALID_TOPOLOGY_ID  (~0U)
>> +struct xen_sysctl_topologyinfo {
>> +     /*
>> +      * IN: maximum addressable entry in the caller-provided arrays.
>> +      * OUT: largest cpu identifier in the system.
>> +      * If OUT is greater than IN then the arrays are truncated!
>> +      * If OUT is leass than IN then the array tails are not written by
>> +      * sysctl.
>> +      */
>> +     uint32_t max_cpu_index;
>> +
>> +     /*
>> +      * If not NULL, these arrays are filled with core/socket/node identifier
>> +      * for each cpu.
>> +      * If a cpu has no core/socket/node information (e.g., cpu not present)
>> +      * then the sentinel value ~0u is written to each array.
>> +      * The number of array elements written by the sysctl is:
>> +      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
>> +      */
>> +     GUEST_HANDLE_64(uint32_t) cpu_to_core;
>> +     GUEST_HANDLE_64(uint32_t) cpu_to_socket;
>> +     GUEST_HANDLE_64(uint32_t) cpu_to_node;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
>> +
>> +/* XEN_SYSCTL_numainfo */
>> +#define INVALID_NUMAINFO_ID (~0U)
>> +struct xen_sysctl_numainfo {
>> +     /*
>> +      * IN: maximum addressable entry in the caller-provided arrays.
>> +      * OUT: largest node identifier in the system.
>> +      * If OUT is greater than IN then the arrays are truncated!
>> +      */
>> +     uint32_t max_node_index;
>> +
>> +     /* NB. Entries are 0 if node is not present. */
>> +     GUEST_HANDLE_64(uint64_t) node_to_memsize;
>> +     GUEST_HANDLE_64(uint64_t) node_to_memfree;
>> +
>> +     /*
>> +      * Array, of size (max_node_index+1)^2, listing memory access distances
>> +      * between nodes. If an entry has no node distance information (e.g., node
>> +      * not present) then the value ~0u is written.
>> +      *
>> +      * Note that the array rows must be indexed by multiplying by the minimum
>> +      * of the caller-provided max_node_index and the returned value of
>> +      * max_node_index. That is, if the largest node index in the system is
>> +      * smaller than the caller can handle, a smaller 2-d array is constructed
>> +      * within the space provided by the caller. When this occurs, trailing
>> +      * space provided by the caller is not modified. If the largest node index
>> +      * in the system is larger than the caller can handle, then a 2-d array of
>> +      * the maximum size handleable by the caller is constructed.
>> +      */
>> +     GUEST_HANDLE_64(uint32_t) node_to_node_distance;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
>> +
>> +/* XEN_SYSCTL_cpupool_op */
>> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
>> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
>> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
>> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
>> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
>> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
>> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
>> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
>> +struct xen_sysctl_cpupool_op {
>> +     uint32_t op;          /* IN */
>> +     uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
>> +     uint32_t sched_id;    /* IN: C      OUT: I  */
>> +     uint32_t domid;       /* IN: M              */
>> +     uint32_t cpu;         /* IN: AR             */
>> +     uint32_t n_dom;       /*            OUT: I  */
>> +     struct xenctl_bitmap cpumap; /*     OUT: IF */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
>> +
>> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
>> +/*
>> + * This structure is used to pass a new ARINC653 schedule from a
>> + * privileged domain (ie dom0) to Xen.
>> + */
>> +struct xen_sysctl_arinc653_schedule {
>> +     /* major_frame holds the time for the new schedule's major frame
>> +     * in nanoseconds. */
>> +     uint64_aligned_t     major_frame;
>> +     /* num_sched_entries holds how many of the entries in the
>> +     * sched_entries[] array are valid. */
>> +     uint8_t     num_sched_entries;
>> +     /* The sched_entries array holds the actual schedule entries. */
>> +     struct {
>> +             /* dom_handle must match a domain's UUID */
>> +             xen_domain_handle_t dom_handle;
>> +             /*
>> +              * If a domain has multiple VCPUs, vcpu_id specifies which one
>> +              * this schedule entry applies to. It should be set to 0 if
>> +              * there is only one VCPU for the domain. */
>> +             unsigned int vcpu_id;
>> +             /*
>> +              * runtime specifies the amount of time that should be allocated
>> +              * to this VCPU per major frame. It is specified in nanoseconds
>> +              */
>> +             uint64_aligned_t runtime;
>> +     } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
>> +
>> +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;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
>> +
>> +/* XEN_SYSCTL_scheduler_op */
>> +/* Set or get info? */
>> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
>> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
>> +struct xen_sysctl_scheduler_op {
>> +     uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
>> +     uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
>> +     uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
>> +     union {
>> +             struct xen_sysctl_sched_arinc653 {
>> +                     GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
>> +             } sched_arinc653;
>> +             struct xen_sysctl_credit_schedule sched_credit;
>> +     } u;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
>> +
>> +/* XEN_SYSCTL_coverage_op */
>> +/*
>> + * Get total size of information, to help allocate
>> + * the buffer. The pointer points to a 32 bit value.
>> + */
>> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
>> +
>> +/*
>> + * Read coverage information in a single run
>> + * You must use a tool to split them.
>> + */
>> +#define XEN_SYSCTL_COVERAGE_read           1
>> +
>> +/*
>> + * Reset all the coverage counters to 0
>> + * No parameters.
>> + */
>> +#define XEN_SYSCTL_COVERAGE_reset          2
>> +
>> +/*
>> + * Like XEN_SYSCTL_COVERAGE_read but reset also
>> + * counters to 0 in a single call.
>> + */
>> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
>> +
>> +struct xen_sysctl_coverage_op {
>> +     uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
>> +     union {
>> +             uint32_t total_size; /* OUT */
>> +             GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
>> +     } u;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
>> +
>> +
>> +struct xen_sysctl {
>> +     uint32_t cmd;
>> +#define XEN_SYSCTL_readconsole                    1
>> +#define XEN_SYSCTL_tbuf_op                        2
>> +#define XEN_SYSCTL_physinfo                       3
>> +#define XEN_SYSCTL_sched_id                       4
>> +#define XEN_SYSCTL_perfc_op                       5
>> +#define XEN_SYSCTL_debug_keys                     7
>> +#define XEN_SYSCTL_getcpuinfo                     8
>> +#define XEN_SYSCTL_availheap                      9
>> +#define XEN_SYSCTL_get_pmstat                    10
>> +#define XEN_SYSCTL_cpu_hotplug                   11
>> +#define XEN_SYSCTL_pm_op                         12
>> +#define XEN_SYSCTL_page_offline_op               14
>> +#define XEN_SYSCTL_lockprof_op                   15
>> +#define XEN_SYSCTL_topologyinfo                  16
>> +#define XEN_SYSCTL_numainfo                      17
>> +#define XEN_SYSCTL_cpupool_op                    18
>> +#define XEN_SYSCTL_scheduler_op                  19
>> +#define XEN_SYSCTL_coverage_op                   20
>> +     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
>> +     union {
>> +             struct xen_sysctl_readconsole       readconsole;
>> +             struct xen_sysctl_tbuf_op           tbuf_op;
>> +             struct xen_sysctl_physinfo          physinfo;
>> +             struct xen_sysctl_topologyinfo      topologyinfo;
>> +             struct xen_sysctl_numainfo          numainfo;
>> +             struct xen_sysctl_sched_id          sched_id;
>> +             struct xen_sysctl_perfc_op          perfc_op;
>> +             struct xen_sysctl_debug_keys        debug_keys;
>> +             struct xen_sysctl_getcpuinfo        getcpuinfo;
>> +             struct xen_sysctl_availheap         availheap;
>> +             struct xen_sysctl_get_pmstat        get_pmstat;
>> +             struct xen_sysctl_cpu_hotplug       cpu_hotplug;
>> +             struct xen_sysctl_pm_op             pm_op;
>> +             struct xen_sysctl_page_offline_op   page_offline;
>> +             struct xen_sysctl_lockprof_op       lockprof_op;
>> +             struct xen_sysctl_cpupool_op        cpupool_op;
>> +             struct xen_sysctl_scheduler_op      scheduler_op;
>> +             struct xen_sysctl_coverage_op       coverage_op;
>> +             uint8_t                             pad[128];
>> +     } u;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
>> +
>> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */
>
> We usually only introduce what we need from Xen header files in Linux:
> do not copy the entirety of sysctl.h, just introduce what you need.
I'll do this in the next patch-set.

>> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> index 53ec416..cf64566 100644
>> --- a/include/xen/interface/xen.h
>> +++ b/include/xen/interface/xen.h
>> @@ -57,6 +57,7 @@
>>  #define __HYPERVISOR_event_channel_op     32
>>  #define __HYPERVISOR_physdev_op           33
>>  #define __HYPERVISOR_hvm_op               34
>> +#define __HYPERVISOR_sysctl               35
>>  #define __HYPERVISOR_tmem_op              38
>>
>>  /* Architecture-specific hypercall definitions. */
>> @@ -526,6 +527,11 @@ struct tmem_op {
>>
>>  DEFINE_GUEST_HANDLE(u64);
>>
>> +struct xenctl_bitmap {
>> +     GUEST_HANDLE_64(uint8_t) bitmap;
>> +     uint32_t nr_bits;
>> +};
>> +
>>  #else /* __ASSEMBLY__ */
>>
>>  /* In assembly code we cannot use C numeric constant suffixes. */
>> --
>> 1.9.1
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:33:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:33:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLK3-0003ZZ-K2; Thu, 06 Nov 2014 11:33:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLK2-0003ZK-8k
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:33:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	98/F9-09936-C9C5B545; Thu, 06 Nov 2014 11:33:48 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415273624!3878580!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2578 invoked from network); 6 Nov 2014 11:33:46 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:33:46 -0000
Received: from mail-qg0-f45.google.com ([209.85.192.45]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtcmMPvlEjj+1gBdPLK44zX675NjNY6@postini.com;
	Thu, 06 Nov 2014 03:33:46 PST
Received: by mail-qg0-f45.google.com with SMTP id z107so534578qgd.32
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:33:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=leVoWbywfoCUhq4vCJ2R0/LjSFVefV54u6XKqBFieBE=;
	b=CDCm6CYnRpfjYtS2mt/+YVbAugsf/+QEl/Sm0qUixlanWX0r31+yekhEtujT056ib1
	PCzsQxc07mqsOtDEYTbvgMwBJl4+GPPA9EyiYO2Ag/6EYuh02QnzsJGhJA1zdSd5mgmG
	T4bsl2kCuWEjKyiv6t87bv4RimkP0kI0Yztls=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=leVoWbywfoCUhq4vCJ2R0/LjSFVefV54u6XKqBFieBE=;
	b=lhdpOvqoCa7NBk6m4FmtzpH9+Z1nnjkK0VBlJkT+rStvpyjRC+/eRgwUGFYWUnr2Q8
	NDIazbZqefk5ajkVm9oBZbaPTa628LyQ+wWNFmhSv/X+K7ZCD56pVmEU0JHfajwe2zna
	dT9PFeprjVGpIylMLZt4rJnDLeBWrnhefC7gLQpd3NmM66pf+EEIu5yc8LnHxCsnah88
	xpTZ7SDQaxdz6zHYfsqJVRq5bbho6+LDrxcePGjfQnTtXTs96k/JQiuPgJquj0nP+mOl
	UGo+7U5eogLYTCnWf2y+TGyD1Zr2F3TBtpvQY/wV6/KF99JC7DzbD+qw5FF8a74YgZ22
	0Z3A==
X-Gm-Message-State: ALoCoQkZ3YveUETCs3FlmRRXQfRLTiJLG23p5KLlrO02/CJ/mhvWzzr7dajs0PZMU6AzCEpCItkV0Yg4Y2ityB7OOecKX4UMDl8efZGycDDsynS/8QMZOgoCsjPMSly1CVjdowF1lyo/SpL6M/E3QDdz4/SyK5rJ+Q==
X-Received: by 10.140.39.113 with SMTP id u104mr5393436qgu.86.1415273624098;
	Thu, 06 Nov 2014 03:33:44 -0800 (PST)
X-Received: by 10.140.39.113 with SMTP id u104mr5393413qgu.86.1415273623965;
	Thu, 06 Nov 2014 03:33:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:33:23 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:33:23 +0200
Message-ID: <CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>
> Why?
I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.

>>  arch/arm/include/asm/xen/hypercall.h |   1 +
>>  arch/arm/include/asm/xen/interface.h |   2 +
>>  arch/arm/xen/enlighten.c             |   1 +
>>  arch/arm/xen/hypercall.S             |   1 +
>>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
>>  include/xen/interface/xen.h          |   6 +
>>  6 files changed, 657 insertions(+)
>>  create mode 100644 include/xen/interface/sysctl.h
>>
>> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> index c817c56..751869eb 100644
>> --- a/arch/arm/include/asm/xen/hypercall.h
>> +++ b/arch/arm/include/asm/xen/hypercall.h
>> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>>  int HYPERVISOR_tmem_op(void *arg);
>> +int HYPERVISOR_sysctl(void *arg);
>>
>>  static inline void
>>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
>> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
>> index 1151188..acf4b7a 100644
>> --- a/arch/arm/include/asm/xen/interface.h
>> +++ b/arch/arm/include/asm/xen/interface.h
>> @@ -19,6 +19,7 @@
>>       __DEFINE_GUEST_HANDLE(name, struct name)
>>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
>>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
>> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
>>
>>  #define set_xen_guest_handle(hnd, val)                       \
>>       do {                                            \
>> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
>>  DEFINE_GUEST_HANDLE(void);
>>  DEFINE_GUEST_HANDLE(uint64_t);
>>  DEFINE_GUEST_HANDLE(uint32_t);
>> +DEFINE_GUEST_HANDLE(uint8_t);
>>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>>
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index eb0d851..675f17a 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>>  EXPORT_SYMBOL_GPL(privcmd_call);
>> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> index d1cf7b7..a1276df 100644
>> --- a/arch/arm/xen/hypercall.S
>> +++ b/arch/arm/xen/hypercall.S
>> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>>  HYPERCALL2(physdev_op);
>>  HYPERCALL3(vcpu_op);
>>  HYPERCALL1(tmem_op);
>> +HYPERCALL1(sysctl);
>>
>>  ENTRY(privcmd_call)
>>       stmdb sp!, {r4}
>> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
>> new file mode 100644
>> index 0000000..1a8cf7a
>> --- /dev/null
>> +++ b/include/xen/interface/sysctl.h
>> @@ -0,0 +1,646 @@
>> +/******************************************************************************
>> + * sysctl.h
>> + *
>> + * System management operations. For use by node control stack.
>> + *
>> + * Reused from xen: xen/include/public/sysctl.h
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a copy
>> + * of this software and associated documentation files (the "Software"), to
>> + * deal in the Software without restriction, including without limitation the
>> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the Software is
>> + * furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
>> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> + * DEALINGS IN THE SOFTWARE.
>> + *
>> + * Copyright (c) 2002-2006, K Fraser
>> + * Copyright (c) 2014, GlobalLogic Inc.
>> + */
>> +
>> +#ifndef __XEN_PUBLIC_SYSCTL_H__
>> +#define __XEN_PUBLIC_SYSCTL_H__
>> +
>> +#include <xen/interface/xen.h>
>> +
>> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
>> +
>> +/*
>> + * Read console content from Xen buffer ring.
>> + */
>> +/* XEN_SYSCTL_readconsole */
>> +struct xen_sysctl_readconsole {
>> +     /* IN: Non-zero -> clear after reading. */
>> +     uint8_t clear;
>> +     /* IN: Non-zero -> start index specified by @index field. */
>> +     uint8_t incremental;
>> +     uint8_t pad0, pad1;
>> +     /*
>> +     * IN:  Start index for consuming from ring buffer (if @incremental);
>> +     * OUT: End index after consuming from ring buffer.
>> +     */
>> +     uint32_t index;
>> +     /* IN: Virtual address to write console data. */
>> +     GUEST_HANDLE_64(char) buffer;
>> +     /* IN: Size of buffer; OUT: Bytes written to buffer. */
>> +     uint32_t count;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
>> +
>> +/* Get trace buffers machine base address */
>> +/* XEN_SYSCTL_tbuf_op */
>> +struct xen_sysctl_tbuf_op {
>> +    /* IN variables */
>> +#define XEN_SYSCTL_TBUFOP_get_info     0
>> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
>> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
>> +#define XEN_SYSCTL_TBUFOP_set_size     3
>> +#define XEN_SYSCTL_TBUFOP_enable       4
>> +#define XEN_SYSCTL_TBUFOP_disable      5
>> +     uint32_t cmd;
>> +     /* IN/OUT variables */
>> +     struct xenctl_bitmap cpu_mask;
>> +     uint32_t             evt_mask;
>> +     /* OUT variables */
>> +     uint64_aligned_t buffer_mfn;
>> +     uint32_t size;  /* Also an IN variable! */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
>> +
>> +/*
>> + * Get physical information about the host machine
>> + */
>> +/* XEN_SYSCTL_physinfo */
>> + /* (x86) The platform supports HVM guests. */
>> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
>> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
>> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
>> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
>> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
>> +struct xen_sysctl_physinfo {
>> +     uint32_t threads_per_core;
>> +     uint32_t cores_per_socket;
>> +     uint32_t nr_cpus;     /* # CPUs currently online */
>> +     uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
>> +     uint32_t nr_nodes;    /* # nodes currently online */
>> +     uint32_t max_node_id; /* Largest possible node ID on this host */
>> +     uint32_t cpu_khz;
>> +     uint64_aligned_t total_pages;
>> +     uint64_aligned_t free_pages;
>> +     uint64_aligned_t scrub_pages;
>> +     uint64_aligned_t outstanding_pages;
>> +     uint32_t hw_cap[8];
>> +
>> +     /* XEN_SYSCTL_PHYSCAP_??? */
>> +     uint32_t capabilities;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
>> +
>> +/*
>> + * Get the ID of the current scheduler.
>> + */
>> +/* XEN_SYSCTL_sched_id */
>> +struct xen_sysctl_sched_id {
>> +     /* OUT variable */
>> +     uint32_t sched_id;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
>> +
>> +/* Interface for controlling Xen software performance counters. */
>> +/* XEN_SYSCTL_perfc_op */
>> +/* Sub-operations: */
>> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
>> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
>> +struct xen_sysctl_perfc_desc {
>> +     char         name[80];           /* name of perf counter */
>> +     uint32_t     nr_vals;            /* number of values for this counter */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
>> +
>> +struct xen_sysctl_perfc_op {
>> +     /* IN variables. */
>> +     uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
>> +     /* OUT variables. */
>> +     uint32_t       nr_counters;       /*  number of counters description  */
>> +     uint32_t       nr_vals;           /*  number of values  */
>> +     /* counter information (or NULL) */
>> +     GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
>> +     /* counter values (or NULL) */
>> +     GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
>> +
>> +/* Inject debug keys into Xen. */
>> +/* XEN_SYSCTL_debug_keys */
>> +struct xen_sysctl_debug_keys {
>> +     /* IN variables. */
>> +     GUEST_HANDLE_64(char) keys;
>> +     uint32_t nr_keys;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
>> +
>> +/* Get physical CPU information. */
>> +/* XEN_SYSCTL_getcpuinfo */
>> +struct xen_sysctl_cpuinfo {
>> +     uint64_aligned_t idletime;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
>> +struct xen_sysctl_getcpuinfo {
>> +     /* IN variables. */
>> +     uint32_t max_cpus;
>> +     GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
>> +     /* OUT variables. */
>> +     uint32_t nr_cpus;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
>> +
>> +/* XEN_SYSCTL_availheap */
>> +struct xen_sysctl_availheap {
>> +     /* IN variables. */
>> +     uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
>> +     uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
>> +     int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
>> +     /* OUT variables. */
>> +     uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
>> +
>> +/* XEN_SYSCTL_get_pmstat */
>> +struct pm_px_val {
>> +     uint64_aligned_t freq;        /* Px core frequency */
>> +     uint64_aligned_t residency;   /* Px residency time */
>> +     uint64_aligned_t count;       /* Px transition count */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
>> +
>> +struct pm_px_stat {
>> +     uint8_t total;        /* total Px states */
>> +     uint8_t usable;       /* usable Px states */
>> +     uint8_t last;         /* last Px state */
>> +     uint8_t cur;          /* current Px state */
>> +     GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
>> +     GUEST_HANDLE_64(pm_px_val) pt;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
>> +
>> +struct pm_cx_stat {
>> +     uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
>> +     uint32_t last;  /* last Cx state */
>> +     uint64_aligned_t idle_time;                 /* idle time from boot */
>> +     GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
>> +     GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
>> +     uint64_aligned_t pc2;
>> +     uint64_aligned_t pc3;
>> +     uint64_aligned_t pc6;
>> +     uint64_aligned_t pc7;
>> +     uint64_aligned_t cc3;
>> +     uint64_aligned_t cc6;
>> +     uint64_aligned_t cc7;
>> +};
>> +
>> +struct xen_sysctl_get_pmstat {
>> +#define PMSTAT_CATEGORY_MASK 0xf0
>> +#define PMSTAT_PX            0x10
>> +#define PMSTAT_CX            0x20
>> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
>> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
>> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
>> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
>> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
>> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
>> +     uint32_t type;
>> +     uint32_t cpuid;
>> +     union {
>> +             struct pm_px_stat getpx;
>> +             struct pm_cx_stat getcx;
>> +             /* other struct for tx, etc */
>> +     } u;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
>> +
>> +/* XEN_SYSCTL_cpu_hotplug */
>> +struct xen_sysctl_cpu_hotplug {
>> +     /* IN variables */
>> +     uint32_t cpu;   /* Physical cpu. */
>> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
>> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
>> +     uint32_t op;    /* hotplug opcode */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
>> +
>> +/*
>> + * Get/set xen power management, include
>> + * 1. cpufreq governors and related parameters
>> + */
>> +/* XEN_SYSCTL_pm_op */
>> +struct xen_userspace {
>> +     uint32_t scaling_setspeed;
>> +};
>> +
>> +struct xen_ondemand {
>> +     uint32_t sampling_rate_max;
>> +     uint32_t sampling_rate_min;
>> +
>> +     uint32_t sampling_rate;
>> +     uint32_t up_threshold;
>> +};
>> +
>> +/*
>> + * cpufreq para name of this structure named
>> + * same as sysfs file name of native linux
>> + */
>> +#define CPUFREQ_NAME_LEN 16
>> +struct xen_get_cpufreq_para {
>> +     /* IN/OUT variable */
>> +     uint32_t cpu_num;
>> +     uint32_t freq_num;
>> +     uint32_t gov_num;
>> +
>> +     /* for all governors */
>> +     /* OUT variable */
>> +     GUEST_HANDLE_64(uint32_t) affected_cpus;
>> +     GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
>> +     GUEST_HANDLE_64(char)   scaling_available_governors;
>> +     char scaling_driver[CPUFREQ_NAME_LEN];
>> +
>> +     uint32_t cpuinfo_cur_freq;
>> +     uint32_t cpuinfo_max_freq;
>> +     uint32_t cpuinfo_min_freq;
>> +     uint32_t scaling_cur_freq;
>> +
>> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> +     uint32_t scaling_max_freq;
>> +     uint32_t scaling_min_freq;
>> +
>> +     /* for specific governor */
>> +     union {
>> +             struct  xen_userspace userspace;
>> +             struct  xen_ondemand ondemand;
>> +     } u;
>> +
>> +     int32_t turbo_enabled;
>> +};
>> +
>> +struct xen_set_cpufreq_gov {
>> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> +};
>> +
>> +struct xen_set_cpufreq_para {
>> +     #define SCALING_MAX_FREQ           1
>> +     #define SCALING_MIN_FREQ           2
>> +     #define SCALING_SETSPEED           3
>> +     #define SAMPLING_RATE              4
>> +     #define UP_THRESHOLD               5
>> +
>> +     uint32_t ctrl_type;
>> +     uint32_t ctrl_value;
>> +};
>> +
>> +struct xen_sysctl_pm_op {
>> +     #define PM_PARA_CATEGORY_MASK      0xf0
>> +     #define CPUFREQ_PARA               0x10
>> +
>> +     /* cpufreq command type */
>> +     #define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
>> +     #define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
>> +     #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
>> +     #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
>> +
>> +     /* set/reset scheduler power saving option */
>> +     #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
>> +
>> +     /* cpuidle max_cstate access command */
>> +     #define XEN_SYSCTL_pm_op_get_max_cstate       0x22
>> +     #define XEN_SYSCTL_pm_op_set_max_cstate       0x23
>> +
>> +     /* set scheduler migration cost value */
>> +     #define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
>> +     #define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
>> +
>> +     /* enable/disable turbo mode when in dbs governor */
>> +     #define XEN_SYSCTL_pm_op_enable_turbo               0x26
>> +     #define XEN_SYSCTL_pm_op_disable_turbo              0x27
>> +
>> +     uint32_t cmd;
>> +     uint32_t cpuid;
>> +     union {
>> +             struct xen_get_cpufreq_para get_para;
>> +             struct xen_set_cpufreq_gov  set_gov;
>> +             struct xen_set_cpufreq_para set_para;
>> +             uint64_aligned_t get_avgfreq;
>> +             uint32_t                    set_sched_opt_smt;
>> +             uint32_t                    get_max_cstate;
>> +             uint32_t                    set_max_cstate;
>> +             uint32_t                    get_vcpu_migration_delay;
>> +             uint32_t                    set_vcpu_migration_delay;
>> +     } u;
>> +};
>> +
>> +/* XEN_SYSCTL_page_offline_op */
>> +struct xen_sysctl_page_offline_op {
>> +     /* IN: range of page to be offlined */
>> +#define sysctl_page_offline     1
>> +#define sysctl_page_online      2
>> +#define sysctl_query_page_offline  3
>> +     uint32_t cmd;
>> +     uint32_t start;
>> +     uint32_t end;
>> +     /* OUT: result of page offline request */
>> +     /*
>> +     * bit 0~15: result flags
>> +     * bit 16~31: owner
>> +     */
>> +     GUEST_HANDLE(uint32_t) status;
>> +};
>> +
>> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
>> +
>> +/* The result is invalid, i.e. HV does not handle it */
>> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
>> +
>> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
>> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
>> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
>> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
>> +
>> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
>> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
>> +
>> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
>> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
>> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
>> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
>> +
>> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
>> +
>> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
>> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
>> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
>> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
>> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
>> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
>> +
>> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
>> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
>> +
>> +#define PG_OFFLINE_OWNER_SHIFT 16
>> +
>> +/* XEN_SYSCTL_lockprof_op */
>> +/* Sub-operations: */
>> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
>> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
>> +/* Record-type: */
>> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
>> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
>> +#define LOCKPROF_TYPE_N           2   /* number of types */
>> +struct xen_sysctl_lockprof_data {
>> +     char     name[40];   /* lock name (may include up to 2 %d specifiers) */
>> +     int32_t  type;       /* LOCKPROF_TYPE_??? */
>> +     int32_t  idx;        /* index (e.g. domain id) */
>> +     uint64_aligned_t lock_cnt;     /* # of locking succeeded */
>> +     uint64_aligned_t block_cnt;    /* # of wait for lock */
>> +     uint64_aligned_t lock_time;    /* nsecs lock held */
>> +     uint64_aligned_t block_time;   /* nsecs waited for lock */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
>> +
>> +struct xen_sysctl_lockprof_op {
>> +     /* IN variables. */
>> +     uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
>> +     uint32_t       max_elem;          /* size of output buffer */
>> +     /* OUT variables (query only). */
>> +     uint32_t       nr_elem;           /* number of elements available */
>> +     uint64_aligned_t time;            /* nsecs of profile measurement */
>> +     /* profile information (or NULL) */
>> +     GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
>> +
>> +/* XEN_SYSCTL_topologyinfo */
>> +#define INVALID_TOPOLOGY_ID  (~0U)
>> +struct xen_sysctl_topologyinfo {
>> +     /*
>> +      * IN: maximum addressable entry in the caller-provided arrays.
>> +      * OUT: largest cpu identifier in the system.
>> +      * If OUT is greater than IN then the arrays are truncated!
>> +      * If OUT is leass than IN then the array tails are not written by
>> +      * sysctl.
>> +      */
>> +     uint32_t max_cpu_index;
>> +
>> +     /*
>> +      * If not NULL, these arrays are filled with core/socket/node identifier
>> +      * for each cpu.
>> +      * If a cpu has no core/socket/node information (e.g., cpu not present)
>> +      * then the sentinel value ~0u is written to each array.
>> +      * The number of array elements written by the sysctl is:
>> +      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
>> +      */
>> +     GUEST_HANDLE_64(uint32_t) cpu_to_core;
>> +     GUEST_HANDLE_64(uint32_t) cpu_to_socket;
>> +     GUEST_HANDLE_64(uint32_t) cpu_to_node;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
>> +
>> +/* XEN_SYSCTL_numainfo */
>> +#define INVALID_NUMAINFO_ID (~0U)
>> +struct xen_sysctl_numainfo {
>> +     /*
>> +      * IN: maximum addressable entry in the caller-provided arrays.
>> +      * OUT: largest node identifier in the system.
>> +      * If OUT is greater than IN then the arrays are truncated!
>> +      */
>> +     uint32_t max_node_index;
>> +
>> +     /* NB. Entries are 0 if node is not present. */
>> +     GUEST_HANDLE_64(uint64_t) node_to_memsize;
>> +     GUEST_HANDLE_64(uint64_t) node_to_memfree;
>> +
>> +     /*
>> +      * Array, of size (max_node_index+1)^2, listing memory access distances
>> +      * between nodes. If an entry has no node distance information (e.g., node
>> +      * not present) then the value ~0u is written.
>> +      *
>> +      * Note that the array rows must be indexed by multiplying by the minimum
>> +      * of the caller-provided max_node_index and the returned value of
>> +      * max_node_index. That is, if the largest node index in the system is
>> +      * smaller than the caller can handle, a smaller 2-d array is constructed
>> +      * within the space provided by the caller. When this occurs, trailing
>> +      * space provided by the caller is not modified. If the largest node index
>> +      * in the system is larger than the caller can handle, then a 2-d array of
>> +      * the maximum size handleable by the caller is constructed.
>> +      */
>> +     GUEST_HANDLE_64(uint32_t) node_to_node_distance;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
>> +
>> +/* XEN_SYSCTL_cpupool_op */
>> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
>> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
>> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
>> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
>> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
>> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
>> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
>> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
>> +struct xen_sysctl_cpupool_op {
>> +     uint32_t op;          /* IN */
>> +     uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
>> +     uint32_t sched_id;    /* IN: C      OUT: I  */
>> +     uint32_t domid;       /* IN: M              */
>> +     uint32_t cpu;         /* IN: AR             */
>> +     uint32_t n_dom;       /*            OUT: I  */
>> +     struct xenctl_bitmap cpumap; /*     OUT: IF */
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
>> +
>> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
>> +/*
>> + * This structure is used to pass a new ARINC653 schedule from a
>> + * privileged domain (ie dom0) to Xen.
>> + */
>> +struct xen_sysctl_arinc653_schedule {
>> +     /* major_frame holds the time for the new schedule's major frame
>> +     * in nanoseconds. */
>> +     uint64_aligned_t     major_frame;
>> +     /* num_sched_entries holds how many of the entries in the
>> +     * sched_entries[] array are valid. */
>> +     uint8_t     num_sched_entries;
>> +     /* The sched_entries array holds the actual schedule entries. */
>> +     struct {
>> +             /* dom_handle must match a domain's UUID */
>> +             xen_domain_handle_t dom_handle;
>> +             /*
>> +              * If a domain has multiple VCPUs, vcpu_id specifies which one
>> +              * this schedule entry applies to. It should be set to 0 if
>> +              * there is only one VCPU for the domain. */
>> +             unsigned int vcpu_id;
>> +             /*
>> +              * runtime specifies the amount of time that should be allocated
>> +              * to this VCPU per major frame. It is specified in nanoseconds
>> +              */
>> +             uint64_aligned_t runtime;
>> +     } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
>> +
>> +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;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
>> +
>> +/* XEN_SYSCTL_scheduler_op */
>> +/* Set or get info? */
>> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
>> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
>> +struct xen_sysctl_scheduler_op {
>> +     uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
>> +     uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
>> +     uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
>> +     union {
>> +             struct xen_sysctl_sched_arinc653 {
>> +                     GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
>> +             } sched_arinc653;
>> +             struct xen_sysctl_credit_schedule sched_credit;
>> +     } u;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
>> +
>> +/* XEN_SYSCTL_coverage_op */
>> +/*
>> + * Get total size of information, to help allocate
>> + * the buffer. The pointer points to a 32 bit value.
>> + */
>> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
>> +
>> +/*
>> + * Read coverage information in a single run
>> + * You must use a tool to split them.
>> + */
>> +#define XEN_SYSCTL_COVERAGE_read           1
>> +
>> +/*
>> + * Reset all the coverage counters to 0
>> + * No parameters.
>> + */
>> +#define XEN_SYSCTL_COVERAGE_reset          2
>> +
>> +/*
>> + * Like XEN_SYSCTL_COVERAGE_read but reset also
>> + * counters to 0 in a single call.
>> + */
>> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
>> +
>> +struct xen_sysctl_coverage_op {
>> +     uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
>> +     union {
>> +             uint32_t total_size; /* OUT */
>> +             GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
>> +     } u;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
>> +
>> +
>> +struct xen_sysctl {
>> +     uint32_t cmd;
>> +#define XEN_SYSCTL_readconsole                    1
>> +#define XEN_SYSCTL_tbuf_op                        2
>> +#define XEN_SYSCTL_physinfo                       3
>> +#define XEN_SYSCTL_sched_id                       4
>> +#define XEN_SYSCTL_perfc_op                       5
>> +#define XEN_SYSCTL_debug_keys                     7
>> +#define XEN_SYSCTL_getcpuinfo                     8
>> +#define XEN_SYSCTL_availheap                      9
>> +#define XEN_SYSCTL_get_pmstat                    10
>> +#define XEN_SYSCTL_cpu_hotplug                   11
>> +#define XEN_SYSCTL_pm_op                         12
>> +#define XEN_SYSCTL_page_offline_op               14
>> +#define XEN_SYSCTL_lockprof_op                   15
>> +#define XEN_SYSCTL_topologyinfo                  16
>> +#define XEN_SYSCTL_numainfo                      17
>> +#define XEN_SYSCTL_cpupool_op                    18
>> +#define XEN_SYSCTL_scheduler_op                  19
>> +#define XEN_SYSCTL_coverage_op                   20
>> +     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
>> +     union {
>> +             struct xen_sysctl_readconsole       readconsole;
>> +             struct xen_sysctl_tbuf_op           tbuf_op;
>> +             struct xen_sysctl_physinfo          physinfo;
>> +             struct xen_sysctl_topologyinfo      topologyinfo;
>> +             struct xen_sysctl_numainfo          numainfo;
>> +             struct xen_sysctl_sched_id          sched_id;
>> +             struct xen_sysctl_perfc_op          perfc_op;
>> +             struct xen_sysctl_debug_keys        debug_keys;
>> +             struct xen_sysctl_getcpuinfo        getcpuinfo;
>> +             struct xen_sysctl_availheap         availheap;
>> +             struct xen_sysctl_get_pmstat        get_pmstat;
>> +             struct xen_sysctl_cpu_hotplug       cpu_hotplug;
>> +             struct xen_sysctl_pm_op             pm_op;
>> +             struct xen_sysctl_page_offline_op   page_offline;
>> +             struct xen_sysctl_lockprof_op       lockprof_op;
>> +             struct xen_sysctl_cpupool_op        cpupool_op;
>> +             struct xen_sysctl_scheduler_op      scheduler_op;
>> +             struct xen_sysctl_coverage_op       coverage_op;
>> +             uint8_t                             pad[128];
>> +     } u;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
>> +
>> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */
>
> We usually only introduce what we need from Xen header files in Linux:
> do not copy the entirety of sysctl.h, just introduce what you need.
I'll do this in the next patch-set.

>> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> index 53ec416..cf64566 100644
>> --- a/include/xen/interface/xen.h
>> +++ b/include/xen/interface/xen.h
>> @@ -57,6 +57,7 @@
>>  #define __HYPERVISOR_event_channel_op     32
>>  #define __HYPERVISOR_physdev_op           33
>>  #define __HYPERVISOR_hvm_op               34
>> +#define __HYPERVISOR_sysctl               35
>>  #define __HYPERVISOR_tmem_op              38
>>
>>  /* Architecture-specific hypercall definitions. */
>> @@ -526,6 +527,11 @@ struct tmem_op {
>>
>>  DEFINE_GUEST_HANDLE(u64);
>>
>> +struct xenctl_bitmap {
>> +     GUEST_HANDLE_64(uint8_t) bitmap;
>> +     uint32_t nr_bits;
>> +};
>> +
>>  #else /* __ASSEMBLY__ */
>>
>>  /* In assembly code we cannot use C numeric constant suffixes. */
>> --
>> 1.9.1
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:34:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:34:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLKM-0003cp-68; Thu, 06 Nov 2014 11:34:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLKK-0003cY-NO
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:34:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	18/FC-24532-0BC5B545; Thu, 06 Nov 2014 11:34:08 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415273644!3878693!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5206 invoked from network); 6 Nov 2014 11:34:05 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:34:05 -0000
Received: from mail-qc0-f175.google.com ([209.85.216.175]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtcrGFzL9D7mLUI9eXdVNtzAZCNiurl@postini.com;
	Thu, 06 Nov 2014 03:34:05 PST
Received: by mail-qc0-f175.google.com with SMTP id b13so627007qcw.20
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:34:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=A3l/D7NdIARdrSas78zOyyPoWFewcvHzxfUOMjzSKEw=;
	b=k8UMaSs/GKWwnPfZT93cGsaXe2fmWTl8C5zhDL+p5ObOAyFnrHAOfB9qYvNyvsgrlJ
	OgjJya4XCatTRzJsH8nIKt6cS65/DmmmLJDQvS7wWOTgJ2wQpnCHRhOL68H422sguU+5
	2QEVqm5uvdtLF2Ye7hXG8L1WhQ2WjEoNoA0uQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=A3l/D7NdIARdrSas78zOyyPoWFewcvHzxfUOMjzSKEw=;
	b=dEzivbgzRz6waO/X5mDGnelT9dk1Kr5Tc3lI6OgLKY6SsQu27ty9Ss0KgVs/r6KU2Y
	GSgDTreHxzVL5BCvracnORcXGsJGux8McC+vtkGGeMvg5yo+k3jwOVP1aCohfw5GSg4D
	klhdm1UMoZnKLeELTVcJT0OL3YS68nVYQvSaYlGBtglvlJeYrUvrVGRPsPlvoAhVepfb
	xbZdfE85t3wUNv4DrJ18zehOwk6seN3aI0XK/skiF5JRUoSZdH+CRQ62KjbYrYZ3OG3n
	mgX5O0nu69hj5GVYSSpKnyrju7cTkj+WJKnWMWIJaNay2oMRFZY8RJnZGCRm/Q5bVJuw
	jwMg==
X-Gm-Message-State: ALoCoQnO8e0LtYUF+g/6JH7Q7774+XZ0sb9CoYEqmzw1gb0QtxuGIC+k2fSwfvXUUUi945G6jKaRvq9iOkAqxU+GcsSNTe08URrxc2aE2u52O8JVqiCNEHwAaWL4WCbuGhPwOEQoiS2fbuz7G/hym6csQa9UEQ1Hyg==
X-Received: by 10.224.53.131 with SMTP id m3mr5469202qag.85.1415273643628;
	Thu, 06 Nov 2014 03:34:03 -0800 (PST)
X-Received: by 10.224.53.131 with SMTP id m3mr5469184qag.85.1415273643528;
	Thu, 06 Nov 2014 03:34:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:33:43 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:33:43 +0200
Message-ID: <CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>
> Why?
I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.

>>  arch/arm/include/asm/xen/hypercall.h | 1 +
>>  arch/arm/xen/enlighten.c             | 1 +
>>  arch/arm/xen/hypercall.S             | 1 +
>>  3 files changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> index 751869eb..383c174 100644
>> --- a/arch/arm/include/asm/xen/hypercall.h
>> +++ b/arch/arm/include/asm/xen/hypercall.h
>> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>>  int HYPERVISOR_tmem_op(void *arg);
>> +int HYPERVISOR_dom0_op(void *arg);
>>  int HYPERVISOR_sysctl(void *arg);
>>
>>  static inline void
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index 675f17a..f757c57 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>>  EXPORT_SYMBOL_GPL(privcmd_call);
>> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> index a1276df..99e2254 100644
>> --- a/arch/arm/xen/hypercall.S
>> +++ b/arch/arm/xen/hypercall.S
>> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>>  HYPERCALL2(physdev_op);
>>  HYPERCALL3(vcpu_op);
>>  HYPERCALL1(tmem_op);
>> +HYPERCALL1(dom0_op);
>>  HYPERCALL1(sysctl);
>>
>>  ENTRY(privcmd_call)
>> --
>> 1.9.1
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:34:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:34:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLKM-0003cp-68; Thu, 06 Nov 2014 11:34:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLKK-0003cY-NO
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:34:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	18/FC-24532-0BC5B545; Thu, 06 Nov 2014 11:34:08 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415273644!3878693!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5206 invoked from network); 6 Nov 2014 11:34:05 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:34:05 -0000
Received: from mail-qc0-f175.google.com ([209.85.216.175]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtcrGFzL9D7mLUI9eXdVNtzAZCNiurl@postini.com;
	Thu, 06 Nov 2014 03:34:05 PST
Received: by mail-qc0-f175.google.com with SMTP id b13so627007qcw.20
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:34:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=A3l/D7NdIARdrSas78zOyyPoWFewcvHzxfUOMjzSKEw=;
	b=k8UMaSs/GKWwnPfZT93cGsaXe2fmWTl8C5zhDL+p5ObOAyFnrHAOfB9qYvNyvsgrlJ
	OgjJya4XCatTRzJsH8nIKt6cS65/DmmmLJDQvS7wWOTgJ2wQpnCHRhOL68H422sguU+5
	2QEVqm5uvdtLF2Ye7hXG8L1WhQ2WjEoNoA0uQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=A3l/D7NdIARdrSas78zOyyPoWFewcvHzxfUOMjzSKEw=;
	b=dEzivbgzRz6waO/X5mDGnelT9dk1Kr5Tc3lI6OgLKY6SsQu27ty9Ss0KgVs/r6KU2Y
	GSgDTreHxzVL5BCvracnORcXGsJGux8McC+vtkGGeMvg5yo+k3jwOVP1aCohfw5GSg4D
	klhdm1UMoZnKLeELTVcJT0OL3YS68nVYQvSaYlGBtglvlJeYrUvrVGRPsPlvoAhVepfb
	xbZdfE85t3wUNv4DrJ18zehOwk6seN3aI0XK/skiF5JRUoSZdH+CRQ62KjbYrYZ3OG3n
	mgX5O0nu69hj5GVYSSpKnyrju7cTkj+WJKnWMWIJaNay2oMRFZY8RJnZGCRm/Q5bVJuw
	jwMg==
X-Gm-Message-State: ALoCoQnO8e0LtYUF+g/6JH7Q7774+XZ0sb9CoYEqmzw1gb0QtxuGIC+k2fSwfvXUUUi945G6jKaRvq9iOkAqxU+GcsSNTe08URrxc2aE2u52O8JVqiCNEHwAaWL4WCbuGhPwOEQoiS2fbuz7G/hym6csQa9UEQ1Hyg==
X-Received: by 10.224.53.131 with SMTP id m3mr5469202qag.85.1415273643628;
	Thu, 06 Nov 2014 03:34:03 -0800 (PST)
X-Received: by 10.224.53.131 with SMTP id m3mr5469184qag.85.1415273643528;
	Thu, 06 Nov 2014 03:34:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:33:43 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:33:43 +0200
Message-ID: <CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>
> Why?
I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.

>>  arch/arm/include/asm/xen/hypercall.h | 1 +
>>  arch/arm/xen/enlighten.c             | 1 +
>>  arch/arm/xen/hypercall.S             | 1 +
>>  3 files changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> index 751869eb..383c174 100644
>> --- a/arch/arm/include/asm/xen/hypercall.h
>> +++ b/arch/arm/include/asm/xen/hypercall.h
>> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>>  int HYPERVISOR_tmem_op(void *arg);
>> +int HYPERVISOR_dom0_op(void *arg);
>>  int HYPERVISOR_sysctl(void *arg);
>>
>>  static inline void
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index 675f17a..f757c57 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
>>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>>  EXPORT_SYMBOL_GPL(privcmd_call);
>> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> index a1276df..99e2254 100644
>> --- a/arch/arm/xen/hypercall.S
>> +++ b/arch/arm/xen/hypercall.S
>> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>>  HYPERCALL2(physdev_op);
>>  HYPERCALL3(vcpu_op);
>>  HYPERCALL1(tmem_op);
>> +HYPERCALL1(dom0_op);
>>  HYPERCALL1(sysctl);
>>
>>  ENTRY(privcmd_call)
>> --
>> 1.9.1
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:34:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:34:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLKz-0003kJ-Lk; Thu, 06 Nov 2014 11:34:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLKy-0003k1-4N
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:34:48 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	5A/F7-17735-7DC5B545; Thu, 06 Nov 2014 11:34:47 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415273684!10843975!1
X-Originating-IP: [64.18.0.184]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23936 invoked from network); 6 Nov 2014 11:34:46 -0000
Received: from exprod5og107.obsmtp.com (HELO exprod5og107.obsmtp.com)
	(64.18.0.184)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:34:46 -0000
Received: from mail-qc0-f172.google.com ([209.85.216.172]) (using TLSv1) by
	exprod5ob107.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtc1PF4RgMMTs7qoBfTXrynDfvVJZvB@postini.com;
	Thu, 06 Nov 2014 03:34:46 PST
Received: by mail-qc0-f172.google.com with SMTP id i17so563440qcy.31
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:34:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=Y/XRz19Z3ySP4laZ2nJt5+vklwpKW+kFWk3vq1QPv/8=;
	b=LL1miiFM0EdhCbriOhF6fsrmPv3RF8tDidqzyZK4aQZcMd3w8+LSpIkdANH4YjZlwC
	x/adOoe5BYn7a/amOuf6lmUg0tuelZ0BSegtlA8LqLsJh1Rx1xlSCKySJ4uXQVelNkoo
	JXw9S5I1duN/30SEeRcaVRC/DvpxG9OX0+Zuw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=Y/XRz19Z3ySP4laZ2nJt5+vklwpKW+kFWk3vq1QPv/8=;
	b=Pc2Ydq6Vl5HmHFor7DOQyyuMseAEAcegzdIPowM9rXiSM/B3z/+2CLbqmvYrY6JoSs
	k82569Y/MBe5a156Qq7dFo5pX7hHVq/5joSYkeKDtpiVHaC54wtvrCGgcmnx5pLFlCL5
	Bf9M0750iCsloZ915AyJoupl7Vpdm35EdcF46RikjTtQU4vwFPwlRIGRI6ijvhUPEF0P
	sFGjeBVx2He7TucxQlXR3uqTzpvy6c4mUwniNr1CpvB8SUE7lriGmarmcpFJtdCUa3t0
	06q/5siTdwBCSNi5M2lyvJ7VxXvJbo/Gt5fcXkj9rHFaB7ZCfj4dudftVMO7aSF1XsWB
	U9jg==
X-Gm-Message-State: ALoCoQmgKXcpCaI3IS0QftsDm1IgVp7XuyGeEZ2GFPlYnx9i5IkvJ0rJKvzLTS/E/5JQ5fhlGYbH91EDRneTIuApCR73BbbC9z4xpnI3H+BO3Vhdd7uu4OWTN9tX47u2qTMmYTqM4TuD7zue1bDbUe/YYAe9fpVI9A==
X-Received: by 10.140.39.113 with SMTP id u104mr5400845qgu.86.1415273684002;
	Thu, 06 Nov 2014 03:34:44 -0800 (PST)
X-Received: by 10.140.39.113 with SMTP id u104mr5400828qgu.86.1415273683899;
	Thu, 06 Nov 2014 03:34:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:34:23 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041618420.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041618420.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:34:23 +0200
Message-ID: <CAN58jitz3-daQcdPOEc4rg-1FovFc6PpY1gpzLP44fuBmzAntQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 5/9] cpufreq: cpufreq-cpu0: change
 cpus data path in devtree for hwdom kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:20 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> All information needed for this driver about physical cpus
>> now located in /hypervisor/pcpus node instead of the
>> /cpus node in case if kernel is running as hardware domain.
>>
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> ---
>>  drivers/cpufreq/cpufreq-cpu0.c | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
>> index ef4fbc4..a83838b 100644
>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>> @@ -21,6 +21,8 @@
>>  #include <linux/regulator/consumer.h>
>>  #include <linux/slab.h>
>>
>> +#include <xen/xen.h>
>> +
>>  static unsigned int transition_latency;
>>  static unsigned int voltage_tolerance; /* in percentage */
>>
>> @@ -182,7 +184,13 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
>>       struct device_node *np;
>>       int ret;
>>
>> -     np = of_find_node_by_path("/cpus/cpu@0");
>> +#ifdef CONFIG_XEN_DOM0
>
> the #ifdef is not necessary, xen_initial_domain() is always properly
> defined
I'll fix this in the next patch-set.

>> +     if (xen_initial_domain())
>> +             np = of_find_node_by_path("/hypervisor/pcpus/cpu@0");
>> +     else
>> +#endif
>> +             np = of_find_node_by_path("/cpus/cpu@0");
>>       if (!np) {
>>               pr_err("failed to find cpu0 node\n");
>>               return -ENOENT;
>> --
>> 1.9.1
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:34:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:34:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLKz-0003kJ-Lk; Thu, 06 Nov 2014 11:34:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLKy-0003k1-4N
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:34:48 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	5A/F7-17735-7DC5B545; Thu, 06 Nov 2014 11:34:47 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415273684!10843975!1
X-Originating-IP: [64.18.0.184]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23936 invoked from network); 6 Nov 2014 11:34:46 -0000
Received: from exprod5og107.obsmtp.com (HELO exprod5og107.obsmtp.com)
	(64.18.0.184)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:34:46 -0000
Received: from mail-qc0-f172.google.com ([209.85.216.172]) (using TLSv1) by
	exprod5ob107.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtc1PF4RgMMTs7qoBfTXrynDfvVJZvB@postini.com;
	Thu, 06 Nov 2014 03:34:46 PST
Received: by mail-qc0-f172.google.com with SMTP id i17so563440qcy.31
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:34:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=Y/XRz19Z3ySP4laZ2nJt5+vklwpKW+kFWk3vq1QPv/8=;
	b=LL1miiFM0EdhCbriOhF6fsrmPv3RF8tDidqzyZK4aQZcMd3w8+LSpIkdANH4YjZlwC
	x/adOoe5BYn7a/amOuf6lmUg0tuelZ0BSegtlA8LqLsJh1Rx1xlSCKySJ4uXQVelNkoo
	JXw9S5I1duN/30SEeRcaVRC/DvpxG9OX0+Zuw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=Y/XRz19Z3ySP4laZ2nJt5+vklwpKW+kFWk3vq1QPv/8=;
	b=Pc2Ydq6Vl5HmHFor7DOQyyuMseAEAcegzdIPowM9rXiSM/B3z/+2CLbqmvYrY6JoSs
	k82569Y/MBe5a156Qq7dFo5pX7hHVq/5joSYkeKDtpiVHaC54wtvrCGgcmnx5pLFlCL5
	Bf9M0750iCsloZ915AyJoupl7Vpdm35EdcF46RikjTtQU4vwFPwlRIGRI6ijvhUPEF0P
	sFGjeBVx2He7TucxQlXR3uqTzpvy6c4mUwniNr1CpvB8SUE7lriGmarmcpFJtdCUa3t0
	06q/5siTdwBCSNi5M2lyvJ7VxXvJbo/Gt5fcXkj9rHFaB7ZCfj4dudftVMO7aSF1XsWB
	U9jg==
X-Gm-Message-State: ALoCoQmgKXcpCaI3IS0QftsDm1IgVp7XuyGeEZ2GFPlYnx9i5IkvJ0rJKvzLTS/E/5JQ5fhlGYbH91EDRneTIuApCR73BbbC9z4xpnI3H+BO3Vhdd7uu4OWTN9tX47u2qTMmYTqM4TuD7zue1bDbUe/YYAe9fpVI9A==
X-Received: by 10.140.39.113 with SMTP id u104mr5400845qgu.86.1415273684002;
	Thu, 06 Nov 2014 03:34:44 -0800 (PST)
X-Received: by 10.140.39.113 with SMTP id u104mr5400828qgu.86.1415273683899;
	Thu, 06 Nov 2014 03:34:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:34:23 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041618420.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041618420.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:34:23 +0200
Message-ID: <CAN58jitz3-daQcdPOEc4rg-1FovFc6PpY1gpzLP44fuBmzAntQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 5/9] cpufreq: cpufreq-cpu0: change
 cpus data path in devtree for hwdom kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:20 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> All information needed for this driver about physical cpus
>> now located in /hypervisor/pcpus node instead of the
>> /cpus node in case if kernel is running as hardware domain.
>>
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> ---
>>  drivers/cpufreq/cpufreq-cpu0.c | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
>> index ef4fbc4..a83838b 100644
>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>> @@ -21,6 +21,8 @@
>>  #include <linux/regulator/consumer.h>
>>  #include <linux/slab.h>
>>
>> +#include <xen/xen.h>
>> +
>>  static unsigned int transition_latency;
>>  static unsigned int voltage_tolerance; /* in percentage */
>>
>> @@ -182,7 +184,13 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
>>       struct device_node *np;
>>       int ret;
>>
>> -     np = of_find_node_by_path("/cpus/cpu@0");
>> +#ifdef CONFIG_XEN_DOM0
>
> the #ifdef is not necessary, xen_initial_domain() is always properly
> defined
I'll fix this in the next patch-set.

>> +     if (xen_initial_domain())
>> +             np = of_find_node_by_path("/hypervisor/pcpus/cpu@0");
>> +     else
>> +#endif
>> +             np = of_find_node_by_path("/cpus/cpu@0");
>>       if (!np) {
>>               pr_err("failed to find cpu0 node\n");
>>               return -ENOENT;
>> --
>> 1.9.1
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:37:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:37:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLNN-00040F-7J; Thu, 06 Nov 2014 11:37:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLNM-000405-8K
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:37:16 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	A8/F5-24859-B6D5B545; Thu, 06 Nov 2014 11:37:15 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415273832!10874811!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8640 invoked from network); 6 Nov 2014 11:37:14 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:37:14 -0000
Received: from mail-qg0-f50.google.com ([209.85.192.50]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtdaPnarZ8JWCFI3tPXZeHXlf+b4vD5@postini.com;
	Thu, 06 Nov 2014 03:37:14 PST
Received: by mail-qg0-f50.google.com with SMTP id a108so534980qge.37
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:37:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=IrStfcy+H0l3YumjCbIGbDU85GmEi6IcdNbTwHBARrg=;
	b=ML5OWi9e25ePBP+GWcWiGUxNKDa91MIeyOOYSXxM+GVTLVyXkqm9/iO6NH7XNAjwZL
	nYkzWTXwM7BjqY/6FvqmfkqirShTBAXeP31G+ogsZWHZ7GM4SgHkWsmxJvcsBs+LKW1L
	diAuI37wXDoOVPtn46Q/yt2wwhd/xGlDAz+8s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=IrStfcy+H0l3YumjCbIGbDU85GmEi6IcdNbTwHBARrg=;
	b=A3dBdqR1vb63ph2Vxmv2kG2RP6OqmgEqY0kaMPVqSWtH4FI7pwK31/k8XP0/JGux8W
	5INFyb7GP2QhHdHpkgwRj3RgMeimptYFHHTJkb8iuMtCRiJTM9T12p1CFBPPeyGLVt33
	VLEmMAcYyPxzkqPUhWGQhMYKIgxMe/9eIpBDbdU6NTmN6N+mq2sLzC8y1kTTRdvl+KwE
	OSUXcChLwRdt1RiT3/dbuEicDzVBeGYLNHybCRB6QBqO8Qh4m5wsEHjWaoaGNMZCXkoO
	VojNF5Mnm0/JEDLB91Ia5aWZ8pIs1ELsJROEkrYsPl168KvNNT+wi79PZMR8Vt2xxVfO
	MXFw==
X-Gm-Message-State: ALoCoQnYtt4dBwWUkHyMNPIunWwu04MQjZwKh+2pHQt5p7yaHEccAiL5by0ACRD+ixI1BdxSugqkL9uGQlJLVc1monyFmoFWSTOWsHlnqy6k9l9Aue3Yu9RXseeCryLUW8ysR1lKXwu3uhjjG2d5U0uCsj37rg154A==
X-Received: by 10.224.112.66 with SMTP id v2mr5681481qap.22.1415273831922;
	Thu, 06 Nov 2014 03:37:11 -0800 (PST)
X-Received: by 10.224.112.66 with SMTP id v2mr5681463qap.22.1415273831828;
	Thu, 06 Nov 2014 03:37:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:36:51 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041609070.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041609070.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:36:51 +0200
Message-ID: <CAN58jiuC51hrTDHivnv8mpMjns1V9eT4tafKYxv_gCAgJWgpGg@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared
	info definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:12 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> This shared info will be used by hwdom-cpufreq driver
>> to send commands to the cpufreq driver in the hwdom.
>>
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> ---
>>  xen/include/asm-arm/shared.h  | 14 ++++++++++++++
>>  xen/include/public/arch-arm.h |  8 ++++++++
>>  2 files changed, 22 insertions(+)
>>  create mode 100644 xen/include/asm-arm/shared.h
>>
>> diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
>> new file mode 100644
>> index 0000000..4906f38
>> --- /dev/null
>> +++ b/xen/include/asm-arm/shared.h
>> @@ -0,0 +1,14 @@
>> +#ifndef __XEN_ARM_SHARED_H__
>> +#define __XEN_ARM_SHARED_H__
>> +
>> +#define GET_SET_SHARED(type, field)                                 \
>> +static inline type *arch_get_##field##_addr(const struct domain *d) \
>> +{                                                                   \
>> +   return &d->shared_info->arch.field;                              \
>> +}
>> +
>> +GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
>> +
>> +#undef GET_SET_SHARED
>> +
>> +#endif /* __XEN_ARM_SHARED_H__ */
>> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>> index 7496556..7eef6f7 100644
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@ -309,7 +309,15 @@ struct arch_vcpu_info {
>>  };
>>  typedef struct arch_vcpu_info arch_vcpu_info_t;
>>
>> +struct cpufreq_sh_info {
>> +    uint32_t cpu;       /* Physical CPU number */
>> +    uint32_t freq;      /* Frequency in KHz */
>> +    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
>> +    int32_t result;        /* Returned result of the operation */
>> +};
>> +
>>  struct arch_shared_info {
>> +    struct cpufreq_sh_info cpufreq;
>>  };
>>  typedef struct arch_shared_info arch_shared_info_t;
>>  typedef uint64_t xen_callback_t;
>
> This introduces one global struct cpufreq_sh_info. Do we need to worry
> about locking? Is it possible that we might want to send two commands
> simultaneously? How does Xen get to know that Dom0 completed the
> previous operation before starting a new one?
As I've written before:
I'll create an event channel between Xen and hwdom.
In this case Xen will be able to know that hwdom completed the
previous operation before starting a new one.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:37:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:37:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLNN-00040F-7J; Thu, 06 Nov 2014 11:37:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLNM-000405-8K
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:37:16 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	A8/F5-24859-B6D5B545; Thu, 06 Nov 2014 11:37:15 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415273832!10874811!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8640 invoked from network); 6 Nov 2014 11:37:14 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:37:14 -0000
Received: from mail-qg0-f50.google.com ([209.85.192.50]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtdaPnarZ8JWCFI3tPXZeHXlf+b4vD5@postini.com;
	Thu, 06 Nov 2014 03:37:14 PST
Received: by mail-qg0-f50.google.com with SMTP id a108so534980qge.37
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:37:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=IrStfcy+H0l3YumjCbIGbDU85GmEi6IcdNbTwHBARrg=;
	b=ML5OWi9e25ePBP+GWcWiGUxNKDa91MIeyOOYSXxM+GVTLVyXkqm9/iO6NH7XNAjwZL
	nYkzWTXwM7BjqY/6FvqmfkqirShTBAXeP31G+ogsZWHZ7GM4SgHkWsmxJvcsBs+LKW1L
	diAuI37wXDoOVPtn46Q/yt2wwhd/xGlDAz+8s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=IrStfcy+H0l3YumjCbIGbDU85GmEi6IcdNbTwHBARrg=;
	b=A3dBdqR1vb63ph2Vxmv2kG2RP6OqmgEqY0kaMPVqSWtH4FI7pwK31/k8XP0/JGux8W
	5INFyb7GP2QhHdHpkgwRj3RgMeimptYFHHTJkb8iuMtCRiJTM9T12p1CFBPPeyGLVt33
	VLEmMAcYyPxzkqPUhWGQhMYKIgxMe/9eIpBDbdU6NTmN6N+mq2sLzC8y1kTTRdvl+KwE
	OSUXcChLwRdt1RiT3/dbuEicDzVBeGYLNHybCRB6QBqO8Qh4m5wsEHjWaoaGNMZCXkoO
	VojNF5Mnm0/JEDLB91Ia5aWZ8pIs1ELsJROEkrYsPl168KvNNT+wi79PZMR8Vt2xxVfO
	MXFw==
X-Gm-Message-State: ALoCoQnYtt4dBwWUkHyMNPIunWwu04MQjZwKh+2pHQt5p7yaHEccAiL5by0ACRD+ixI1BdxSugqkL9uGQlJLVc1monyFmoFWSTOWsHlnqy6k9l9Aue3Yu9RXseeCryLUW8ysR1lKXwu3uhjjG2d5U0uCsj37rg154A==
X-Received: by 10.224.112.66 with SMTP id v2mr5681481qap.22.1415273831922;
	Thu, 06 Nov 2014 03:37:11 -0800 (PST)
X-Received: by 10.224.112.66 with SMTP id v2mr5681463qap.22.1415273831828;
	Thu, 06 Nov 2014 03:37:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:36:51 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041609070.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041609070.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:36:51 +0200
Message-ID: <CAN58jiuC51hrTDHivnv8mpMjns1V9eT4tafKYxv_gCAgJWgpGg@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared
	info definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:12 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> This shared info will be used by hwdom-cpufreq driver
>> to send commands to the cpufreq driver in the hwdom.
>>
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> ---
>>  xen/include/asm-arm/shared.h  | 14 ++++++++++++++
>>  xen/include/public/arch-arm.h |  8 ++++++++
>>  2 files changed, 22 insertions(+)
>>  create mode 100644 xen/include/asm-arm/shared.h
>>
>> diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
>> new file mode 100644
>> index 0000000..4906f38
>> --- /dev/null
>> +++ b/xen/include/asm-arm/shared.h
>> @@ -0,0 +1,14 @@
>> +#ifndef __XEN_ARM_SHARED_H__
>> +#define __XEN_ARM_SHARED_H__
>> +
>> +#define GET_SET_SHARED(type, field)                                 \
>> +static inline type *arch_get_##field##_addr(const struct domain *d) \
>> +{                                                                   \
>> +   return &d->shared_info->arch.field;                              \
>> +}
>> +
>> +GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
>> +
>> +#undef GET_SET_SHARED
>> +
>> +#endif /* __XEN_ARM_SHARED_H__ */
>> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>> index 7496556..7eef6f7 100644
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@ -309,7 +309,15 @@ struct arch_vcpu_info {
>>  };
>>  typedef struct arch_vcpu_info arch_vcpu_info_t;
>>
>> +struct cpufreq_sh_info {
>> +    uint32_t cpu;       /* Physical CPU number */
>> +    uint32_t freq;      /* Frequency in KHz */
>> +    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
>> +    int32_t result;        /* Returned result of the operation */
>> +};
>> +
>>  struct arch_shared_info {
>> +    struct cpufreq_sh_info cpufreq;
>>  };
>>  typedef struct arch_shared_info arch_shared_info_t;
>>  typedef uint64_t xen_callback_t;
>
> This introduces one global struct cpufreq_sh_info. Do we need to worry
> about locking? Is it possible that we might want to send two commands
> simultaneously? How does Xen get to know that Dom0 completed the
> previous operation before starting a new one?
As I've written before:
I'll create an event channel between Xen and hwdom.
In this case Xen will be able to know that hwdom completed the
previous operation before starting a new one.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:39:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11: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 1XmLPS-00048e-Oc; Thu, 06 Nov 2014 11:39:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1XmLPR-00048Y-Dx
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:39:25 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	02/E9-02954-CED5B545; Thu, 06 Nov 2014 11:39:24 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415273963!7150776!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6998 invoked from network); 6 Nov 2014 11:39:23 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 11:39:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413237600"; d="scan'208";a="105196972"
Received: from unknown (HELO type.youpi.perso.aquilenet.fr) ([193.50.110.200])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA;
	06 Nov 2014 12:39:23 +0100
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1XmLPP-0005nV-31; Thu, 06 Nov 2014 12:39:23 +0100
Date: Thu, 6 Nov 2014 12:39:23 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141106113923.GA3182@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xen.org,
	netwiz@crc.id.au, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Length: 2023
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Anthony Perard <anthony.perard@citrix.com>, netwiz@crc.id.au,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini, le Thu 06 Nov 2014 10:41:28 +0000, a =E9crit :
> When using pvgrub in graphical mode with vnc, the grub timeout doesn't
> work: the countdown doesn't even start. With a serial terminal the
> problem doesn't occur and the countdown works as expected.
> =

> It turns out that the problem is that when using a graphical terminal,
> checkkey () returns 0 instead of -1 when there is no activity on the
> mouse or keyboard. As a consequence grub thinks that the user typed
> something and interrupts the count down.
> =

> To fix the issue simply ignore keystrokes returning 0, that is the NUL
> character anyway. Add a patch to grub.patches to do that.
> =

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: Steven Haigh <netwiz@crc.id.au>

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> =

> diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub=
.patches/11graphics-keyboard.diff
> new file mode 100644
> index 0000000..fe17b20
> --- /dev/null
> +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> @@ -0,0 +1,13 @@
> +diff --git a/stage2/stage2.c b/stage2/stage2.c
> +index 9d9fcc3..8353a3b 100644
> +--- a/stage2/stage2.c
> ++++ b/stage2/stage2.c
> +@@ -395,7 +395,7 @@ restart:
> + 	 pressed.  =

> + 	 This avoids polling (relevant in the grub-shell and later on
> + 	 in grub if interrupt driven I/O is done).  */
> +-      if (checkkey () >=3D 0 || grub_timeout < 0)
> ++      if (checkkey () > 0 || grub_timeout < 0)
> + 	{
> + 	  /* Key was pressed, show which entry is selected before GETKEY,
> + 	     since we're comming in here also on GRUB_TIMEOUT =3D=3D -1 and
> =


-- =

Samuel
"And the next time you consider complaining that running Lucid Emacs
19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
get the background colors right, you'll know who to thank."
(By Matt Welsh)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:39:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11: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 1XmLPS-00048e-Oc; Thu, 06 Nov 2014 11:39:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1XmLPR-00048Y-Dx
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:39:25 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	02/E9-02954-CED5B545; Thu, 06 Nov 2014 11:39:24 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415273963!7150776!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6998 invoked from network); 6 Nov 2014 11:39:23 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 11:39:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413237600"; d="scan'208";a="105196972"
Received: from unknown (HELO type.youpi.perso.aquilenet.fr) ([193.50.110.200])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA;
	06 Nov 2014 12:39:23 +0100
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1XmLPP-0005nV-31; Thu, 06 Nov 2014 12:39:23 +0100
Date: Thu, 6 Nov 2014 12:39:23 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141106113923.GA3182@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xen.org,
	netwiz@crc.id.au, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Length: 2023
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Anthony Perard <anthony.perard@citrix.com>, netwiz@crc.id.au,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini, le Thu 06 Nov 2014 10:41:28 +0000, a =E9crit :
> When using pvgrub in graphical mode with vnc, the grub timeout doesn't
> work: the countdown doesn't even start. With a serial terminal the
> problem doesn't occur and the countdown works as expected.
> =

> It turns out that the problem is that when using a graphical terminal,
> checkkey () returns 0 instead of -1 when there is no activity on the
> mouse or keyboard. As a consequence grub thinks that the user typed
> something and interrupts the count down.
> =

> To fix the issue simply ignore keystrokes returning 0, that is the NUL
> character anyway. Add a patch to grub.patches to do that.
> =

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: Steven Haigh <netwiz@crc.id.au>

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> =

> diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub=
.patches/11graphics-keyboard.diff
> new file mode 100644
> index 0000000..fe17b20
> --- /dev/null
> +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> @@ -0,0 +1,13 @@
> +diff --git a/stage2/stage2.c b/stage2/stage2.c
> +index 9d9fcc3..8353a3b 100644
> +--- a/stage2/stage2.c
> ++++ b/stage2/stage2.c
> +@@ -395,7 +395,7 @@ restart:
> + 	 pressed.  =

> + 	 This avoids polling (relevant in the grub-shell and later on
> + 	 in grub if interrupt driven I/O is done).  */
> +-      if (checkkey () >=3D 0 || grub_timeout < 0)
> ++      if (checkkey () > 0 || grub_timeout < 0)
> + 	{
> + 	  /* Key was pressed, show which entry is selected before GETKEY,
> + 	     since we're comming in here also on GRUB_TIMEOUT =3D=3D -1 and
> =


-- =

Samuel
"And the next time you consider complaining that running Lucid Emacs
19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
get the background colors right, you'll know who to thank."
(By Matt Welsh)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:44:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:44:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLTr-0004Ub-Es; Thu, 06 Nov 2014 11:43:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLTp-0004UW-Kv
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:43:57 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	56/E4-24124-CFE5B545; Thu, 06 Nov 2014 11:43:56 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415274230!10832622!1
X-Originating-IP: [64.18.0.184]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25775 invoked from network); 6 Nov 2014 11:43:52 -0000
Received: from exprod5og107.obsmtp.com (HELO exprod5og107.obsmtp.com)
	(64.18.0.184)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:43:52 -0000
Received: from mail-qg0-f54.google.com ([209.85.192.54]) (using TLSv1) by
	exprod5ob107.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFte9qFNWHR0CqS5MEkOqYmX26BbKkZ4@postini.com;
	Thu, 06 Nov 2014 03:43:52 PST
Received: by mail-qg0-f54.google.com with SMTP id q108so538770qgd.41
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:43:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=g0+w8JKhiyJoUotOZvmd+7q5bhNmimLOFQs3pR8Aee0=;
	b=ZnCLTNQmt5S56LMk89FX3FpENbEt/OwtNKCjS48epD63C7f8N0iWJRrj5XvvTBChFB
	Xo4sG+ps79berz0q0cPg/yUK3uBnWBadrA1Muzhp3hST4EJ0LzW5UE4VaWsRsC4XTjrY
	es5whn7+YZBOGq7zp7nDpuFZXBc3qbuTvZg0Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=g0+w8JKhiyJoUotOZvmd+7q5bhNmimLOFQs3pR8Aee0=;
	b=bE3m0Cp/fqbTyghIDbOByNYiT7pwuwed3SQf/uVfIYFchwBIEMTKUwqx2VbX2MCR9D
	HwVS36TsUqhd1FI7l6hQbkj6OwQkr0WlMcCy/GxtrQ1Cpzq946Zt/82VE5Bg26GOU6pr
	iwTYLbHS2YeDvh/61FvOxOaSWZok+vCwF647QXb9jX6KRF/PkffLGYXW0LnByuXd/LdK
	AL1CRdC4/VdVsUbk95twgJE18I2KeMO+xOPD3uStJyaMr11lAI3xqx/avC9D76uzcGPn
	uvyaXgMX4CV8BBpJg1c+/y/Otajdyd2DxoN8s6i5rWHNkqLUD/W0CR0fl10jwMZUvGun
	x2oA==
X-Gm-Message-State: ALoCoQl8RjZuw0k8NKGfyYxoXZ4GbCFKUU8OYqtH3+KQ0oI6ZP72qK5cb7lnILoIGljI6CPCNoVosr8lHpYGKGWzH9biI8LBqN7FOp8FqqTU8FevJTxKC6hR+mnbomPkdsfqfViHTRzmPbDTwchKRG5LTPB1i7wETw==
X-Received: by 10.224.60.196 with SMTP id q4mr5694368qah.63.1415274229905;
	Thu, 06 Nov 2014 03:43:49 -0800 (PST)
X-Received: by 10.224.60.196 with SMTP id q4mr5694346qah.63.1415274229780;
	Thu, 06 Nov 2014 03:43:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:43:29 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041621380.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041621380.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:43:29 +0200
Message-ID: <CAN58jivYZMgVuhNNtj6Ks05h1iSZBeihKzqcEGi2wp41T4TxyA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 9/9] xen/arm: cpufreq: add
	xen-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:33 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> Xen changes frequencies on CPUs using this high-level
>> cpufreq driver.
>>
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>
> You CC the wrong email address for Rafael in the entire series.
Could anybody give me right address for Rafael?

>>  drivers/cpufreq/Kconfig           |  20 +
>>  drivers/cpufreq/Makefile          |   1 +
>>  drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
>>  drivers/cpufreq/cpufreq_drv_ops.h |   4 +
>>  drivers/cpufreq/xen-cpufreq.c     | 869 ++++++++++++++++++++++++++++++++++++++
>>  include/xen/interface/platform.h  |   1 +
>>  include/xen/interface/xen.h       |   1 +
>>  7 files changed, 907 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/cpufreq/xen-cpufreq.c
>>
>> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
>> index f5a8f84..4847d8a 100644
>> --- a/drivers/cpufreq/Kconfig
>> +++ b/drivers/cpufreq/Kconfig
>> @@ -19,6 +19,26 @@ config CPU_FREQ
>>
>>         If in doubt, say N.
>>
>> +config XEN_CPUFREQ
>> +     bool "Xen Cpufreq driver"
>> +     depends on XEN_DOM0
>> +     depends on !CPUMASK_OFFSTACK
>> +     default n
>> +     select CPUFREQ_DRV_OPS
>> +     help
>> +       This driver uploads Power Management information to the Xen
>> +       hypervisor and changes CPUs frequency using CPU Frequency scaling
>> +       drivers.
>> +
>> +       To do that the driver uses CPU Frequency scaling drivers to parse
>> +       the Power Management data and uploads said information to the Xen
>> +       hypervisor. Then the Xen hypervisor can select the proper Pxx states.
>> +
>> +       Then the Xen hypervisor can change CPUs frequency by giving commands
>> +       via this driver to the CPU Frequency scaling driver.
>> +
>> +       If in doubt, say N.
>> +
>>  if CPUFREQ_DRV_OPS
>>
>>  config CPU_FREQ_TABLE
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index f12a0d3..c8d5037 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -1,5 +1,6 @@
>>  # CPUfreq core
>>  obj-$(CONFIG_CPU_FREQ)                       += cpufreq.o
>> +obj-$(CONFIG_XEN_CPUFREQ)            += xen-cpufreq.o
>>  obj-$(CONFIG_CPUFREQ_DRV_OPS)                += cpufreq_drv_ops.o
>>  # CPUfreq stats
>>  obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
>> diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
>> index c971442..71c3357 100644
>> --- a/drivers/cpufreq/cpufreq_drv_ops.c
>> +++ b/drivers/cpufreq/cpufreq_drv_ops.c
>> @@ -18,6 +18,8 @@
>>  #include <linux/init.h>
>>  #include <linux/export.h>
>>
>> +#include <xen/xen.h>
>> +
>>  static struct cpufreq_drv_ops *ops;
>>
>>  struct kobject *get_cpufreq_global_kobject(void)
>> @@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
>>
>>  static int __init cpufreq_drv_ops_init(void)
>>  {
>> +     if (xen_initial_domain()) {
>> +#ifdef CONFIG_XEN_CPUFREQ
>> +             ops = &xen_cpufreq_drv_ops;
>> +             pr_debug("using xen_cpufreq_drv_ops\n");
>> +#endif
>> +     } else {
>>  #ifdef CONFIG_CPU_FREQ
>> -     ops = &kern_cpufreq_drv_ops;
>> -     pr_debug("using kern_cpufreq_drv_ops\n");
>> +             ops = &kern_cpufreq_drv_ops;
>> +             pr_debug("using kern_cpufreq_drv_ops\n");
>>  #endif
>> +     }
>>
>>       return 0;
>>  }
>> diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
>> index 5cc8e05..d02d509 100644
>> --- a/drivers/cpufreq/cpufreq_drv_ops.h
>> +++ b/drivers/cpufreq/cpufreq_drv_ops.h
>> @@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
>>  extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
>>  #endif
>>
>> +#ifdef CONFIG_XEN_CPUFREQ
>> +extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
>> +#endif
>> +
>>  #endif /* _CPUFREQ_DRV_OPS_H */
>> diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
>> new file mode 100644
>> index 0000000..21062c7
>> --- /dev/null
>> +++ b/drivers/cpufreq/xen-cpufreq.c
>> @@ -0,0 +1,869 @@
>> +/*
>> + *  Copyright (C) 2001 Russell King
>> + *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
>> + *
>> + *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
>> + *   Added handling for CPU hotplug
>> + *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
>> + *   Fix handling for CPU hotplug -- affected CPUs
>> + *
>> + *           (C) 2014 GlobalLogic Inc.
>> + *
>> + * Based on drivers/cpufreq/cpufreq.c
>> + *
>> + * 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.
>> + */
>> +
>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/init.h>
>> +#include <linux/notifier.h>
>> +#include <linux/types.h>
>> +#include <linux/slab.h>
>> +#include <linux/mutex.h>
>> +#include <linux/irq.h>
>> +#include <linux/workqueue.h>
>> +#include <linux/cpufreq.h>
>> +
>> +#include <trace/events/power.h>
>> +
>> +#include <xen/xen.h>
>> +#include <xen/events.h>
>> +#include <xen/interface/xen.h>
>> +#include <xen/interface/platform.h>
>> +#include <xen/interface/sysctl.h>
>> +#include <asm/xen/hypercall.h>
>> +#include <asm/xen/hypervisor.h>
>> +
>> +#include "cpufreq_drv_ops.h"
>> +
>> +static int xen_nr_cpus;
>> +static int xen_irq;
>> +
>> +#define for_each_xen_cpu(cpu, mask)                  \
>> +     for ((cpu) = -1;                                \
>> +             (cpu) = cpumask_next((cpu), (mask)),    \
>> +             (cpu) < xen_nr_cpus;)
>> +
>> +static struct cpufreq_driver *cpufreq_driver;
>> +static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
>> +
>> +static DEFINE_SPINLOCK(cpufreq_driver_lock);
>> +
>> +/*
>> + * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
>> + * all cpufreq/hotplug/workqueue/etc related lock issues.
>> + *
>> + * The rules for this semaphore:
>> + * - Any routine that wants to read from the policy structure will
>> + *   do a down_read on this semaphore.
>> + * - Any routine that will write to the policy structure and/or may take away
>> + *   the policy altogether (eg. CPU hotplug), will hold this lock in write
>> + *   mode before doing so.
>> + *
>> + * Additional rules:
>> + * - Governor routines that can be called in cpufreq hotplug path should not
>> + *   take this sem as top level hotplug notifier handler takes this.
>> + * - Lock should not be held across
>> + *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
>> + */
>> +static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
>> +static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
>> +
>> +#define lock_policy_rwsem(mode, cpu)                         \
>> +static int lock_policy_rwsem_##mode                          \
>> +(int cpu)                                                    \
>> +{                                                            \
>> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);      \
>> +     BUG_ON(policy_cpu == -1);                               \
>> +     down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));    \
>> +                                                             \
>> +     return 0;                                               \
>> +}
>> +
>> +lock_policy_rwsem(write, cpu);
>> +
>> +static void unlock_policy_rwsem_write(int cpu)
>> +{
>> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
>> +     BUG_ON(policy_cpu == -1);
>> +     up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
>> +}
>> +
>> +/**
>> + * The "transition" notifier list for kernel code that needs to handle
>> + * changes to devices when the CPU clock speed changes.
>> + * The mutex locks this list.
>> + */
>> +static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
>> +
>> +static bool init_cpufreq_transition_notifier_list_called;
>> +static int __init init_cpufreq_transition_notifier_list(void)
>> +{
>> +     srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
>> +     init_cpufreq_transition_notifier_list_called = true;
>> +     return 0;
>> +}
>> +pure_initcall(init_cpufreq_transition_notifier_list);
>> +
>> +static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
>> +{
>> +     struct cpufreq_policy *data = NULL;
>> +     unsigned long flags;
>> +
>> +     if (cpu >= xen_nr_cpus)
>> +             goto err_out;
>> +
>> +     /* get the cpufreq driver */
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +
>> +     if (!cpufreq_driver)
>> +             goto err_out_unlock;
>> +
>> +     /* get the CPU */
>> +     data = per_cpu(cpufreq_cpu_data, cpu);
>> +
>> +err_out_unlock:
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +err_out:
>> +     return data;
>> +}
>> +
>> +static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
>> +{
>> +     module_put(cpufreq_driver->owner);
>> +}
>> +
>> +static int push_data_to_hypervisor(struct cpufreq_policy *policy,
>> +                                struct cpufreq_frequency_table *table)
>> +{
>> +     int ret = 0;
>> +     unsigned int i;
>> +     unsigned int cpu;
>> +     uint32_t platform_limit = 0;
>> +     unsigned int max_freq = 0;
>> +     unsigned int state_count = 0;
>> +     unsigned int prev_freq = 0;
>> +     struct xen_processor_px *dst_states;
>> +     struct xen_processor_performance *dst_perf;
>> +     struct xen_platform_op op = {
>> +             .cmd                    = XENPF_set_processor_pminfo,
>> +             .interface_version      = XENPF_INTERFACE_VERSION,
>> +             .u.set_pminfo.type      = XEN_PM_PX,
>> +     };
>> +
>> +     dst_perf = &op.u.set_pminfo.perf;
>> +
>> +     /* Check freq table and find max frequency */
>> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> +             unsigned int freq = table[i].frequency;
>> +             if (freq == CPUFREQ_ENTRY_INVALID)
>> +                     continue;
>> +
>> +             if (table[i].index != state_count || freq <= prev_freq) {
>> +                     pr_err("Frequency table format error\n");
>> +                     return -EINVAL;
>> +             }
>> +
>> +             prev_freq = freq;
>> +             state_count++;
>> +             if (freq > max_freq)
>> +                     max_freq = freq;
>> +     }
>> +
>> +     if (!state_count)
>> +             return -EINVAL;
>> +
>> +     dst_perf->state_count = state_count;
>> +
>> +     dst_states = kcalloc(state_count,
>> +                          sizeof(struct xen_processor_px), GFP_KERNEL);
>> +
>> +     if (!dst_states)
>> +             return -ENOMEM;
>> +
>> +     set_xen_guest_handle(dst_perf->states, dst_states);
>> +
>> +     /*
>> +      * Freq table should start from lower values
>> +      * dst_states should start from higer values
>> +      */
>> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> +             unsigned int freq = table[i].frequency;
>> +             unsigned int tbl_index = state_count - 1 - table[i].index;
>> +             if (freq == CPUFREQ_ENTRY_INVALID)
>> +                     continue;
>> +
>> +             if (freq == max_freq)
>> +                     platform_limit = tbl_index;
>> +
>> +             dst_states[tbl_index].core_frequency = freq / 1000;
>> +             dst_states[tbl_index].transition_latency =
>> +                             policy->cpuinfo.transition_latency / 1000;
>> +     }
>> +
>> +     dst_perf->shared_type = policy->shared_type;
>> +     dst_perf->platform_limit = platform_limit;
>> +     dst_perf->domain_info.domain = policy->cpu;
>> +     dst_perf->domain_info.num_processors = xen_nr_cpus;
>> +     dst_perf->flags = XEN_PX_DATA;
>> +
>> +     for_each_xen_cpu(cpu, policy->cpus) {
>> +             op.u.set_pminfo.id = cpu;
>> +             ret = HYPERVISOR_dom0_op(&op);
>> +             if (ret) {
>> +                     pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
>> +                     goto err_free_states;
>> +             }
>> +             pr_debug("CPU%u - P-states uploaded\n", cpu);
>> +
>> +             for (i = 0; i < dst_perf->state_count; i++) {
>> +                     pr_debug("    state %d: %d MHz, %d uS\n",
>> +                              i, (u32) dst_states[i].core_frequency,
>> +                              (u32) dst_states[i].transition_latency);
>> +             }
>> +     }
>> +
>> +err_free_states:
>> +     kfree(dst_states);
>> +     return ret;
>> +}
>> +
>> +/*
>> + * Returns:
>> + *   Negative: Failure
>> + *   0:        Success
>> + *   Positive: When we have a managed CPU and the sysfs got symlinked
>> + */
>> +static int xen_cpufreq_add_dev_policy(unsigned int cpu,
>> +                               struct cpufreq_policy *policy)
>> +{
>> +     int ret = 0;
>> +#ifdef CONFIG_SMP
>> +     unsigned long flags;
>> +     unsigned int j;
>> +
>> +     for_each_cpu(j, policy->cpus) {
>> +             struct cpufreq_policy *managed_policy;
>> +
>> +             if (cpu == j)
>> +                     continue;
>> +
>> +             /* Check for existing affected CPUs.
>> +              * They may not be aware of it due to CPU Hotplug.
>> +              * cpufreq_cpu_put is called when the device is removed
>> +              * in __cpufreq_remove_dev()
>> +              */
>> +             managed_policy = xen_cpufreq_cpu_get(j);
>> +             if (unlikely(managed_policy)) {
>> +                     /* Set proper policy_cpu */
>> +                     unlock_policy_rwsem_write(cpu);
>> +                     per_cpu(cpufreq_policy_cpu, cpu) =
>> +                                             managed_policy->cpu;
>> +
>> +                     if (lock_policy_rwsem_write(cpu) < 0) {
>> +                             /* Should not go through policy unlock path */
>> +                             if (cpufreq_driver->exit)
>> +                                     cpufreq_driver->exit(policy);
>> +                             xen_cpufreq_cpu_put(managed_policy);
>> +                             return -EBUSY;
>> +                     }
>> +
>> +                     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +                     cpumask_copy(managed_policy->cpus, policy->cpus);
>> +                     per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
>> +                     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +
>> +                     pr_debug("CPU already managed, adding link\n");
>> +
>> +                     /*
>> +                      * Success. We only needed to be added to the mask.
>> +                      * Call driver->exit() because only the cpu parent of
>> +                      * the kobj needed to call init().
>> +                      */
>> +                     if (cpufreq_driver->exit)
>> +                             cpufreq_driver->exit(policy);
>> +
>> +                     return 1;
>> +             }
>> +     }
>> +#endif
>> +     return ret;
>> +}
>> +
>> +/**
>> + * xen_cpufreq_add_dev - add a CPU device
>> + *
>> + * Adds the cpufreq interface for a CPU device.
>> + */
>> +static int xen_cpufreq_add_dev(unsigned int cpu)
>> +{
>> +     int ret = 0;
>> +     struct cpufreq_policy *policy;
>> +     unsigned long flags;
>> +     unsigned int j;
>> +
>> +     pr_debug("adding CPU %u\n", cpu);
>> +
>> +#ifdef CONFIG_SMP
>> +     /* check whether a different CPU already registered this
>> +      * CPU because it is in the same boat. */
>> +     policy = xen_cpufreq_cpu_get(cpu);
>> +     if (unlikely(policy)) {
>> +             xen_cpufreq_cpu_put(policy);
>> +             return 0;
>> +     }
>> +#endif
>> +
>> +     if (!try_module_get(cpufreq_driver->owner)) {
>> +             ret = -EINVAL;
>> +             goto module_out;
>> +     }
>> +
>> +     ret = -ENOMEM;
>> +     policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
>> +     if (!policy)
>> +             goto nomem_out;
>> +
>> +     if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
>> +             goto err_free_policy;
>> +
>> +     if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
>> +             goto err_free_cpumask;
>> +
>> +     policy->cpu = cpu;
>> +     cpumask_copy(policy->cpus, cpumask_of(cpu));
>> +
>> +     /* Initially set CPU itself as the policy_cpu */
>> +     per_cpu(cpufreq_policy_cpu, cpu) = cpu;
>> +     ret = (lock_policy_rwsem_write(cpu) < 0);
>> +     WARN_ON(ret);
>> +
>> +     /* call driver. From then on the cpufreq must be able
>> +      * to accept all calls to ->verify and ->setpolicy for this CPU
>> +      */
>> +     ret = cpufreq_driver->init(policy);
>> +     if (ret) {
>> +             pr_debug("initialization failed\n");
>> +             goto err_unlock_policy;
>> +     }
>> +     ret = xen_cpufreq_add_dev_policy(cpu, policy);
>> +     if (ret) {
>> +             if (ret > 0)
>> +                     /* This is a managed cpu, symlink created,
>> +                        exit with 0 */
>> +                     ret = 0;
>> +             goto err_unlock_policy;
>> +     }
>> +
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +     for_each_cpu(j, policy->cpus) {
>> +             per_cpu(cpufreq_cpu_data, j) = policy;
>> +             per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
>> +     }
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +
>> +     unlock_policy_rwsem_write(cpu);
>> +
>> +     module_put(cpufreq_driver->owner);
>> +     pr_debug("initialization complete\n");
>> +
>> +     return 0;
>> +
>> +err_unlock_policy:
>> +     unlock_policy_rwsem_write(cpu);
>> +     free_cpumask_var(policy->related_cpus);
>> +err_free_cpumask:
>> +     free_cpumask_var(policy->cpus);
>> +err_free_policy:
>> +     kfree(policy);
>> +nomem_out:
>> +     module_put(cpufreq_driver->owner);
>> +module_out:
>> +     return ret;
>> +}
>> +
>> +/**
>> + * __cpufreq_remove_dev - remove a CPU device
>> + *
>> + * Removes the cpufreq interface for a CPU device.
>> + * Caller should already have policy_rwsem in write mode for this CPU.
>> + * This routine frees the rwsem before returning.
>> + */
>> +static int __cpufreq_remove_dev(unsigned int cpu)
>> +{
>> +     unsigned long flags;
>> +     struct cpufreq_policy *data;
>> +#ifdef CONFIG_SMP
>> +     unsigned int j;
>> +#endif
>> +
>> +     pr_debug("unregistering CPU %u\n", cpu);
>> +
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +     data = per_cpu(cpufreq_cpu_data, cpu);
>> +
>> +     if (!data) {
>> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +             unlock_policy_rwsem_write(cpu);
>> +             return -EINVAL;
>> +     }
>> +     per_cpu(cpufreq_cpu_data, cpu) = NULL;
>> +
>> +
>> +#ifdef CONFIG_SMP
>> +     /* if this isn't the CPU which is the parent of the kobj, we
>> +      * only need to unlink, put and exit
>> +      */
>> +     if (unlikely(cpu != data->cpu)) {
>> +             pr_debug("removing link\n");
>> +             cpumask_clear_cpu(cpu, data->cpus);
>> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +             xen_cpufreq_cpu_put(data);
>> +             unlock_policy_rwsem_write(cpu);
>> +             return 0;
>> +     }
>> +#endif
>> +
>> +#ifdef CONFIG_SMP
>> +
>> +     /* if we have other CPUs still registered, we need to unlink them,
>> +      * or else wait_for_completion below will lock up. Clean the
>> +      * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
>> +      * the sysfs links afterwards.
>> +      */
>> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
>> +             for_each_cpu(j, data->cpus) {
>> +                     if (j == cpu)
>> +                             continue;
>> +                     per_cpu(cpufreq_cpu_data, j) = NULL;
>> +             }
>> +     }
>> +
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +
>> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
>> +             for_each_cpu(j, data->cpus) {
>> +                     if (j == cpu)
>> +                             continue;
>> +                     pr_debug("removing link for cpu %u\n", j);
>> +                     unlock_policy_rwsem_write(cpu);
>> +                     lock_policy_rwsem_write(cpu);
>> +                     xen_cpufreq_cpu_put(data);
>> +             }
>> +     }
>> +#else
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +#endif
>> +
>> +     unlock_policy_rwsem_write(cpu);
>> +
>> +     lock_policy_rwsem_write(cpu);
>> +     if (cpufreq_driver->exit)
>> +             cpufreq_driver->exit(data);
>> +     unlock_policy_rwsem_write(cpu);
>> +
>> +     free_cpumask_var(data->related_cpus);
>> +     free_cpumask_var(data->cpus);
>> +     kfree(data);
>> +
>> +     return 0;
>> +}
>> +
>> +static int cpufreq_remove_dev(unsigned int cpu)
>> +{
>> +     int retval;
>> +
>> +     if (unlikely(lock_policy_rwsem_write(cpu)))
>> +             BUG();
>> +
>> +     retval = __cpufreq_remove_dev(cpu);
>> +     return retval;
>> +}
>> +
>> +/*********************************************************************
>> + *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
>> + *********************************************************************/
>> +
>> +/**
>> + * adjust_jiffies - adjust the system "loops_per_jiffy"
>> + *
>> + * This function alters the system "loops_per_jiffy" for the clock
>> + * speed change. Note that loops_per_jiffy cannot be updated on SMP
>> + * systems as each CPU might be scaled differently. So, use the arch
>> + * per-CPU loops_per_jiffy value wherever possible.
>> + */
>> +#ifndef CONFIG_SMP
>> +static unsigned long l_p_j_ref;
>> +static unsigned int  l_p_j_ref_freq;
>> +
>> +static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
>> +{
>> +     if (ci->flags & CPUFREQ_CONST_LOOPS)
>> +             return;
>> +
>> +     if (!l_p_j_ref_freq) {
>> +             l_p_j_ref = loops_per_jiffy;
>> +             l_p_j_ref_freq = ci->old;
>> +             pr_debug("saving %lu as reference value for loops_per_jiffy; "
>> +                     "freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
>> +     }
>> +     if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
>> +         (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
>> +             loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
>> +                                                             ci->new);
>> +             pr_debug("scaling loops_per_jiffy to %lu "
>> +                     "for frequency %u kHz\n", loops_per_jiffy, ci->new);
>> +     }
>> +}
>> +#else
>> +static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
>> +{
>> +     return;
>> +}
>> +#endif
>
> There is quite a lot of code duplication with cpufreq.c, I don't think
> that is going to be acceptable for the upstream maintainers.
It is very complicated to use an common code. Some functions copied
and modified. I'll try to do something in the future.

>> +/**
>> + * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
>> + * on frequency transition.
>> + *
>> + * This function calls the transition notifiers and the "adjust_jiffies"
>> + * function. It is called twice on all CPU frequency changes that have
>> + * external effects.
>> + */
>> +void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
>> +                                unsigned int state)
>> +{
>> +     struct cpufreq_policy *policy;
>> +
>> +     BUG_ON(irqs_disabled());
>> +
>> +     freqs->flags = cpufreq_driver->flags;
>> +     pr_debug("notification %u of frequency transition to %u kHz\n",
>> +              state, freqs->new);
>> +
>> +     policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
>> +     switch (state) {
>> +     case CPUFREQ_PRECHANGE:
>> +             /* detect if the driver reported a value as "old frequency"
>> +              * which is not equal to what the cpufreq core thinks is
>> +              * "old frequency".
>> +              */
>> +             if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
>> +                     if ((policy) && (policy->cpu == freqs->cpu) &&
>> +                         (policy->cur) && (policy->cur != freqs->old)) {
>> +                             pr_debug("Warning: CPU frequency is"
>> +                                      " %u, cpufreq assumed %u kHz.\n",
>> +                                      freqs->old, policy->cur);
>> +                             freqs->old = policy->cur;
>> +                     }
>> +             }
>> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
>> +                                      CPUFREQ_PRECHANGE, freqs);
>> +             adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
>> +             break;
>> +
>> +     case CPUFREQ_POSTCHANGE:
>> +             adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
>> +             pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
>> +                      (unsigned long)freqs->cpu);
>> +             trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
>> +             trace_cpu_frequency(freqs->new, freqs->cpu);
>> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
>> +                                      CPUFREQ_POSTCHANGE, freqs);
>> +             if (likely(policy) && likely(policy->cpu == freqs->cpu))
>> +                     policy->cur = freqs->new;
>> +             break;
>> +     }
>> +}
>> +
>> +/*********************************************************************
>> + *                              GOVERNORS                            *
>> + *********************************************************************/
>> +
>> +int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
>> +                             unsigned int target_freq,
>> +                             unsigned int relation)
>> +{
>> +     int retval = -EINVAL;
>> +     unsigned int old_target_freq = target_freq;
>> +
>> +     /* Make sure that target_freq is within supported range */
>> +     if (target_freq > policy->max)
>> +             target_freq = policy->max;
>> +     if (target_freq < policy->min)
>> +             target_freq = policy->min;
>> +
>> +     pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
>> +              policy->cpu, target_freq, relation, old_target_freq);
>> +
>> +     if (target_freq == policy->cur)
>> +             return 0;
>> +
>> +     if (cpufreq_driver->target)
>> +             retval = cpufreq_driver->target(policy, target_freq,
>> +                                                 relation);
>> +
>> +     return retval;
>> +}
>> +
>> +int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
>> +                           unsigned int target_freq,
>> +                           unsigned int relation)
>> +{
>> +     int ret = -EINVAL;
>> +
>> +     if (!policy)
>> +             goto no_policy;
>> +
>> +     if (unlikely(lock_policy_rwsem_write(policy->cpu)))
>> +             goto fail;
>> +
>> +     ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
>> +
>> +     unlock_policy_rwsem_write(policy->cpu);
>> +
>> +fail:
>> +     xen_cpufreq_cpu_put(policy);
>> +no_policy:
>> +     return ret;
>> +}
>> +
>> +/*********************************************************************
>> + *                    HANDLE COMMANDS FROM XEN                       *
>> + *********************************************************************/
>> +static void cpufreq_work_hnd(struct work_struct *w);
>> +
>> +static struct workqueue_struct *cpufreq_wq;
>> +static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
>> +
>> +static void cpufreq_work_hnd(struct work_struct *w)
>> +{
>> +     int ret;
>> +     struct cpufreq_policy *policy;
>> +     struct cpufreq_sh_info *cpufreq_info;
>> +
>> +     cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
>> +
>> +     policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
>> +     ret = xen_cpufreq_driver_target(policy,
>> +                                     cpufreq_info->freq,
>> +                                     cpufreq_info->relation);
>> +
>> +     cpufreq_info->result = ret;
>> +}
>
> No barriers? No locking?
I'll add barriers in the next patch-set.

>> +static irqreturn_t cpufreq_interrupt(int irq, void *data)
>> +{
>> +     queue_work(cpufreq_wq, &cpufreq_work);
>> +     return IRQ_HANDLED;
>> +}
>> +
>> +/*********************************************************************
>> + *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
>> + *********************************************************************/
>> +
>> +/**
>> + * xen_cpufreq_register_driver - register a CPU Frequency driver
>> + * @driver_data: A struct cpufreq_driver containing the values#
>> + * submitted by the CPU Frequency driver.
>> + *
>> + *   Registers a CPU Frequency driver to this core code. This code
>> + * returns zero on success, -EBUSY when another driver got here first
>> + * (and isn't unregistered in the meantime).
>> + *
>> + */
>> +int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
>> +{
>> +     unsigned long flags;
>> +     int ret;
>> +     unsigned int cpu;
>> +     struct cpufreq_frequency_table *table;
>> +     struct cpufreq_policy *policy;
>> +     cpumask_var_t pushed_cpus;
>> +     int irq;
>> +
>> +     if (!xen_nr_cpus)
>> +             return -EPROBE_DEFER;
>> +
>> +     if (!driver_data || !driver_data->verify || !driver_data->init ||
>> +         (!driver_data->target))
>> +             return -EINVAL;
>> +
>> +     pr_debug("trying to register driver %s\n", driver_data->name);
>> +
>> +     if (driver_data->setpolicy)
>> +             driver_data->flags |= CPUFREQ_CONST_LOOPS;
>> +
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +
>> +     if (cpufreq_driver) {
>> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +             return -EBUSY;
>> +     }
>> +     cpufreq_driver = driver_data;
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +
>> +     irq = bind_virq_to_irq(VIRQ_CPUFREQ, 0);
>> +     if (irq < 0) {
>> +             pr_err("Bind virq (%d) error (%d)\n", VIRQ_CPUFREQ, irq);
>> +             ret = irq;
>> +             goto err_remove_drv;
>> +     }
>> +
>> +     irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN|IRQ_NOPROBE);
>> +
>> +     ret = request_irq(irq, cpufreq_interrupt, 0,
>> +                        "xen_cpufreq", NULL);
>> +
>> +     if (ret < 0) {
>> +             pr_err("Request irq (%d) error (%d)\n", irq, ret);
>> +             goto err_unbind_from_irqhnd;
>> +     }
>> +
>> +     xen_irq = irq;
>> +
>> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
>> +             ret = xen_cpufreq_add_dev(cpu);
>> +             if (ret)
>> +                     goto err_remove_cpu;
>> +     }
>> +
>> +     if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
>> +             goto err_remove_cpu;
>> +
>> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
>> +             if (cpumask_test_cpu(cpu, pushed_cpus))
>> +                     continue;
>> +
>> +             policy = xen_cpufreq_cpu_get(cpu);
>> +             if (!policy) {
>> +                     ret = -EINVAL;
>> +                     goto err_free_cpumask;
>> +             }
>> +
>> +             cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
>> +             table = cpufreq_frequency_get_table(policy->cpu);
>> +             if (!table) {
>> +                     ret = -EINVAL;
>> +                     goto err_free_cpumask;
>> +             }
>> +
>> +             ret = push_data_to_hypervisor(policy, table);
>> +             if (ret)
>> +                     goto err_free_cpumask;
>> +     }
>> +
>> +     free_cpumask_var(pushed_cpus);
>> +
>> +     pr_debug("driver %s up and running\n", driver_data->name);
>> +
>> +     return 0;
>> +
>> +err_free_cpumask:
>> +     free_cpumask_var(pushed_cpus);
>> +err_remove_cpu:
>> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
>> +             cpufreq_remove_dev(cpu);
>> +err_unbind_from_irqhnd:
>> +     unbind_from_irqhandler(irq, NULL);
>> +err_remove_drv:
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +     cpufreq_driver = NULL;
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +     return ret;
>> +}
>> +
>> +/**
>> + * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
>> + *
>> + *    Unregister the current CPUFreq driver. Only call this if you have
>> + * the right to do so, i.e. if you have succeeded in initialising before!
>> + * Returns zero if successful, and -EINVAL if the cpufreq_driver is
>> + * currently not initialised.
>> + */
>> +int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
>> +{
>> +     unsigned long flags;
>> +     unsigned int cpu;
>> +
>> +     if (!cpufreq_driver || (driver != cpufreq_driver))
>> +             return -EINVAL;
>> +
>> +     pr_debug("unregistering driver %s\n", driver->name);
>> +
>> +     unbind_from_irqhandler(xen_irq, NULL);
>> +
>> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
>> +             cpufreq_remove_dev(cpu);
>> +
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +     cpufreq_driver = NULL;
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +
>> +     return 0;
>> +}
>> +
>> +struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
>> +     .notify_transition = xen_cpufreq_notify_transition,
>> +     .register_driver = xen_cpufreq_register_driver,
>> +     .unregister_driver = xen_cpufreq_unregister_driver,
>> +};
>> +
>> +static int __init xen_cpufreq_init(void)
>> +{
>> +     int ret;
>> +     int i;
>> +
>> +     struct xen_sysctl op = {
>> +             .cmd                    = XEN_SYSCTL_physinfo,
>> +             .interface_version      = XEN_SYSCTL_INTERFACE_VERSION,
>> +     };
>> +
>> +     ret = HYPERVISOR_sysctl(&op);
>> +     if (ret) {
>> +             pr_err("Hypervisor get physinfo error (%d)\n", ret);
>> +             return ret;
>> +     }
>> +
>> +     xen_nr_cpus = op.u.physinfo.nr_cpus;
>> +     if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
>> +             xen_nr_cpus = 0;
>> +             pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
>> +             return -EINVAL;
>> +     }
>> +
>> +     for (i = 0; i < xen_nr_cpus; i++) {
>> +             per_cpu(cpufreq_policy_cpu, i) = -1;
>> +             init_rwsem(&per_cpu(cpu_policy_rwsem, i));
>> +     }
>> +
>> +     cpufreq_wq = alloc_workqueue("xen_cpufreq", 0, 1);
>> +     if (!cpufreq_wq) {
>> +             pr_err("Create workqueue error\n");
>> +             ret = -ENOMEM;
>> +             goto err_create_wq;
>> +     }
>> +
>> +     return 0;
>> +
>> +err_create_wq:
>> +     xen_nr_cpus = 0;
>> +     return ret;
>> +}
>> +
>> +MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
>> +MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
>> +MODULE_LICENSE("GPL");
>> +
>> +core_initcall(xen_cpufreq_init);
>> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
>> index c57d5f6..ee3b154 100644
>> --- a/include/xen/interface/platform.h
>> +++ b/include/xen/interface/platform.h
>> @@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
>>  #define XEN_PX_PSS   2
>>  #define XEN_PX_PPC   4
>>  #define XEN_PX_PSD   8
>> +#define XEN_PX_DATA  16
>>
>>  struct xen_power_register {
>>       uint32_t     space_id;
>> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> index cf64566..9133110 100644
>> --- a/include/xen/interface/xen.h
>> +++ b/include/xen/interface/xen.h
>> @@ -81,6 +81,7 @@
>>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
>>  #define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
>> +#define VIRQ_CPUFREQ    14 /* (DOM0) Notify cpufreq driver                */
>>
>>  /* 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 Nov 06 11:44:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:44:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLTr-0004Ub-Es; Thu, 06 Nov 2014 11:43:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmLTp-0004UW-Kv
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:43:57 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	56/E4-24124-CFE5B545; Thu, 06 Nov 2014 11:43:56 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415274230!10832622!1
X-Originating-IP: [64.18.0.184]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25775 invoked from network); 6 Nov 2014 11:43:52 -0000
Received: from exprod5og107.obsmtp.com (HELO exprod5og107.obsmtp.com)
	(64.18.0.184)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 11:43:52 -0000
Received: from mail-qg0-f54.google.com ([209.85.192.54]) (using TLSv1) by
	exprod5ob107.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFte9qFNWHR0CqS5MEkOqYmX26BbKkZ4@postini.com;
	Thu, 06 Nov 2014 03:43:52 PST
Received: by mail-qg0-f54.google.com with SMTP id q108so538770qgd.41
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 03:43:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=g0+w8JKhiyJoUotOZvmd+7q5bhNmimLOFQs3pR8Aee0=;
	b=ZnCLTNQmt5S56LMk89FX3FpENbEt/OwtNKCjS48epD63C7f8N0iWJRrj5XvvTBChFB
	Xo4sG+ps79berz0q0cPg/yUK3uBnWBadrA1Muzhp3hST4EJ0LzW5UE4VaWsRsC4XTjrY
	es5whn7+YZBOGq7zp7nDpuFZXBc3qbuTvZg0Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=g0+w8JKhiyJoUotOZvmd+7q5bhNmimLOFQs3pR8Aee0=;
	b=bE3m0Cp/fqbTyghIDbOByNYiT7pwuwed3SQf/uVfIYFchwBIEMTKUwqx2VbX2MCR9D
	HwVS36TsUqhd1FI7l6hQbkj6OwQkr0WlMcCy/GxtrQ1Cpzq946Zt/82VE5Bg26GOU6pr
	iwTYLbHS2YeDvh/61FvOxOaSWZok+vCwF647QXb9jX6KRF/PkffLGYXW0LnByuXd/LdK
	AL1CRdC4/VdVsUbk95twgJE18I2KeMO+xOPD3uStJyaMr11lAI3xqx/avC9D76uzcGPn
	uvyaXgMX4CV8BBpJg1c+/y/Otajdyd2DxoN8s6i5rWHNkqLUD/W0CR0fl10jwMZUvGun
	x2oA==
X-Gm-Message-State: ALoCoQl8RjZuw0k8NKGfyYxoXZ4GbCFKUU8OYqtH3+KQ0oI6ZP72qK5cb7lnILoIGljI6CPCNoVosr8lHpYGKGWzH9biI8LBqN7FOp8FqqTU8FevJTxKC6hR+mnbomPkdsfqfViHTRzmPbDTwchKRG5LTPB1i7wETw==
X-Received: by 10.224.60.196 with SMTP id q4mr5694368qah.63.1415274229905;
	Thu, 06 Nov 2014 03:43:49 -0800 (PST)
X-Received: by 10.224.60.196 with SMTP id q4mr5694346qah.63.1415274229780;
	Thu, 06 Nov 2014 03:43:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 03:43:29 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411041621380.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041621380.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 13:43:29 +0200
Message-ID: <CAN58jivYZMgVuhNNtj6Ks05h1iSZBeihKzqcEGi2wp41T4TxyA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 9/9] xen/arm: cpufreq: add
	xen-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 4, 2014 at 6:33 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> Xen changes frequencies on CPUs using this high-level
>> cpufreq driver.
>>
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>
> You CC the wrong email address for Rafael in the entire series.
Could anybody give me right address for Rafael?

>>  drivers/cpufreq/Kconfig           |  20 +
>>  drivers/cpufreq/Makefile          |   1 +
>>  drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
>>  drivers/cpufreq/cpufreq_drv_ops.h |   4 +
>>  drivers/cpufreq/xen-cpufreq.c     | 869 ++++++++++++++++++++++++++++++++++++++
>>  include/xen/interface/platform.h  |   1 +
>>  include/xen/interface/xen.h       |   1 +
>>  7 files changed, 907 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/cpufreq/xen-cpufreq.c
>>
>> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
>> index f5a8f84..4847d8a 100644
>> --- a/drivers/cpufreq/Kconfig
>> +++ b/drivers/cpufreq/Kconfig
>> @@ -19,6 +19,26 @@ config CPU_FREQ
>>
>>         If in doubt, say N.
>>
>> +config XEN_CPUFREQ
>> +     bool "Xen Cpufreq driver"
>> +     depends on XEN_DOM0
>> +     depends on !CPUMASK_OFFSTACK
>> +     default n
>> +     select CPUFREQ_DRV_OPS
>> +     help
>> +       This driver uploads Power Management information to the Xen
>> +       hypervisor and changes CPUs frequency using CPU Frequency scaling
>> +       drivers.
>> +
>> +       To do that the driver uses CPU Frequency scaling drivers to parse
>> +       the Power Management data and uploads said information to the Xen
>> +       hypervisor. Then the Xen hypervisor can select the proper Pxx states.
>> +
>> +       Then the Xen hypervisor can change CPUs frequency by giving commands
>> +       via this driver to the CPU Frequency scaling driver.
>> +
>> +       If in doubt, say N.
>> +
>>  if CPUFREQ_DRV_OPS
>>
>>  config CPU_FREQ_TABLE
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index f12a0d3..c8d5037 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -1,5 +1,6 @@
>>  # CPUfreq core
>>  obj-$(CONFIG_CPU_FREQ)                       += cpufreq.o
>> +obj-$(CONFIG_XEN_CPUFREQ)            += xen-cpufreq.o
>>  obj-$(CONFIG_CPUFREQ_DRV_OPS)                += cpufreq_drv_ops.o
>>  # CPUfreq stats
>>  obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
>> diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
>> index c971442..71c3357 100644
>> --- a/drivers/cpufreq/cpufreq_drv_ops.c
>> +++ b/drivers/cpufreq/cpufreq_drv_ops.c
>> @@ -18,6 +18,8 @@
>>  #include <linux/init.h>
>>  #include <linux/export.h>
>>
>> +#include <xen/xen.h>
>> +
>>  static struct cpufreq_drv_ops *ops;
>>
>>  struct kobject *get_cpufreq_global_kobject(void)
>> @@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
>>
>>  static int __init cpufreq_drv_ops_init(void)
>>  {
>> +     if (xen_initial_domain()) {
>> +#ifdef CONFIG_XEN_CPUFREQ
>> +             ops = &xen_cpufreq_drv_ops;
>> +             pr_debug("using xen_cpufreq_drv_ops\n");
>> +#endif
>> +     } else {
>>  #ifdef CONFIG_CPU_FREQ
>> -     ops = &kern_cpufreq_drv_ops;
>> -     pr_debug("using kern_cpufreq_drv_ops\n");
>> +             ops = &kern_cpufreq_drv_ops;
>> +             pr_debug("using kern_cpufreq_drv_ops\n");
>>  #endif
>> +     }
>>
>>       return 0;
>>  }
>> diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
>> index 5cc8e05..d02d509 100644
>> --- a/drivers/cpufreq/cpufreq_drv_ops.h
>> +++ b/drivers/cpufreq/cpufreq_drv_ops.h
>> @@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
>>  extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
>>  #endif
>>
>> +#ifdef CONFIG_XEN_CPUFREQ
>> +extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
>> +#endif
>> +
>>  #endif /* _CPUFREQ_DRV_OPS_H */
>> diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
>> new file mode 100644
>> index 0000000..21062c7
>> --- /dev/null
>> +++ b/drivers/cpufreq/xen-cpufreq.c
>> @@ -0,0 +1,869 @@
>> +/*
>> + *  Copyright (C) 2001 Russell King
>> + *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
>> + *
>> + *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
>> + *   Added handling for CPU hotplug
>> + *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
>> + *   Fix handling for CPU hotplug -- affected CPUs
>> + *
>> + *           (C) 2014 GlobalLogic Inc.
>> + *
>> + * Based on drivers/cpufreq/cpufreq.c
>> + *
>> + * 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.
>> + */
>> +
>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/init.h>
>> +#include <linux/notifier.h>
>> +#include <linux/types.h>
>> +#include <linux/slab.h>
>> +#include <linux/mutex.h>
>> +#include <linux/irq.h>
>> +#include <linux/workqueue.h>
>> +#include <linux/cpufreq.h>
>> +
>> +#include <trace/events/power.h>
>> +
>> +#include <xen/xen.h>
>> +#include <xen/events.h>
>> +#include <xen/interface/xen.h>
>> +#include <xen/interface/platform.h>
>> +#include <xen/interface/sysctl.h>
>> +#include <asm/xen/hypercall.h>
>> +#include <asm/xen/hypervisor.h>
>> +
>> +#include "cpufreq_drv_ops.h"
>> +
>> +static int xen_nr_cpus;
>> +static int xen_irq;
>> +
>> +#define for_each_xen_cpu(cpu, mask)                  \
>> +     for ((cpu) = -1;                                \
>> +             (cpu) = cpumask_next((cpu), (mask)),    \
>> +             (cpu) < xen_nr_cpus;)
>> +
>> +static struct cpufreq_driver *cpufreq_driver;
>> +static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
>> +
>> +static DEFINE_SPINLOCK(cpufreq_driver_lock);
>> +
>> +/*
>> + * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
>> + * all cpufreq/hotplug/workqueue/etc related lock issues.
>> + *
>> + * The rules for this semaphore:
>> + * - Any routine that wants to read from the policy structure will
>> + *   do a down_read on this semaphore.
>> + * - Any routine that will write to the policy structure and/or may take away
>> + *   the policy altogether (eg. CPU hotplug), will hold this lock in write
>> + *   mode before doing so.
>> + *
>> + * Additional rules:
>> + * - Governor routines that can be called in cpufreq hotplug path should not
>> + *   take this sem as top level hotplug notifier handler takes this.
>> + * - Lock should not be held across
>> + *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
>> + */
>> +static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
>> +static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
>> +
>> +#define lock_policy_rwsem(mode, cpu)                         \
>> +static int lock_policy_rwsem_##mode                          \
>> +(int cpu)                                                    \
>> +{                                                            \
>> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);      \
>> +     BUG_ON(policy_cpu == -1);                               \
>> +     down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));    \
>> +                                                             \
>> +     return 0;                                               \
>> +}
>> +
>> +lock_policy_rwsem(write, cpu);
>> +
>> +static void unlock_policy_rwsem_write(int cpu)
>> +{
>> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
>> +     BUG_ON(policy_cpu == -1);
>> +     up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
>> +}
>> +
>> +/**
>> + * The "transition" notifier list for kernel code that needs to handle
>> + * changes to devices when the CPU clock speed changes.
>> + * The mutex locks this list.
>> + */
>> +static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
>> +
>> +static bool init_cpufreq_transition_notifier_list_called;
>> +static int __init init_cpufreq_transition_notifier_list(void)
>> +{
>> +     srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
>> +     init_cpufreq_transition_notifier_list_called = true;
>> +     return 0;
>> +}
>> +pure_initcall(init_cpufreq_transition_notifier_list);
>> +
>> +static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
>> +{
>> +     struct cpufreq_policy *data = NULL;
>> +     unsigned long flags;
>> +
>> +     if (cpu >= xen_nr_cpus)
>> +             goto err_out;
>> +
>> +     /* get the cpufreq driver */
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +
>> +     if (!cpufreq_driver)
>> +             goto err_out_unlock;
>> +
>> +     /* get the CPU */
>> +     data = per_cpu(cpufreq_cpu_data, cpu);
>> +
>> +err_out_unlock:
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +err_out:
>> +     return data;
>> +}
>> +
>> +static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
>> +{
>> +     module_put(cpufreq_driver->owner);
>> +}
>> +
>> +static int push_data_to_hypervisor(struct cpufreq_policy *policy,
>> +                                struct cpufreq_frequency_table *table)
>> +{
>> +     int ret = 0;
>> +     unsigned int i;
>> +     unsigned int cpu;
>> +     uint32_t platform_limit = 0;
>> +     unsigned int max_freq = 0;
>> +     unsigned int state_count = 0;
>> +     unsigned int prev_freq = 0;
>> +     struct xen_processor_px *dst_states;
>> +     struct xen_processor_performance *dst_perf;
>> +     struct xen_platform_op op = {
>> +             .cmd                    = XENPF_set_processor_pminfo,
>> +             .interface_version      = XENPF_INTERFACE_VERSION,
>> +             .u.set_pminfo.type      = XEN_PM_PX,
>> +     };
>> +
>> +     dst_perf = &op.u.set_pminfo.perf;
>> +
>> +     /* Check freq table and find max frequency */
>> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> +             unsigned int freq = table[i].frequency;
>> +             if (freq == CPUFREQ_ENTRY_INVALID)
>> +                     continue;
>> +
>> +             if (table[i].index != state_count || freq <= prev_freq) {
>> +                     pr_err("Frequency table format error\n");
>> +                     return -EINVAL;
>> +             }
>> +
>> +             prev_freq = freq;
>> +             state_count++;
>> +             if (freq > max_freq)
>> +                     max_freq = freq;
>> +     }
>> +
>> +     if (!state_count)
>> +             return -EINVAL;
>> +
>> +     dst_perf->state_count = state_count;
>> +
>> +     dst_states = kcalloc(state_count,
>> +                          sizeof(struct xen_processor_px), GFP_KERNEL);
>> +
>> +     if (!dst_states)
>> +             return -ENOMEM;
>> +
>> +     set_xen_guest_handle(dst_perf->states, dst_states);
>> +
>> +     /*
>> +      * Freq table should start from lower values
>> +      * dst_states should start from higer values
>> +      */
>> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> +             unsigned int freq = table[i].frequency;
>> +             unsigned int tbl_index = state_count - 1 - table[i].index;
>> +             if (freq == CPUFREQ_ENTRY_INVALID)
>> +                     continue;
>> +
>> +             if (freq == max_freq)
>> +                     platform_limit = tbl_index;
>> +
>> +             dst_states[tbl_index].core_frequency = freq / 1000;
>> +             dst_states[tbl_index].transition_latency =
>> +                             policy->cpuinfo.transition_latency / 1000;
>> +     }
>> +
>> +     dst_perf->shared_type = policy->shared_type;
>> +     dst_perf->platform_limit = platform_limit;
>> +     dst_perf->domain_info.domain = policy->cpu;
>> +     dst_perf->domain_info.num_processors = xen_nr_cpus;
>> +     dst_perf->flags = XEN_PX_DATA;
>> +
>> +     for_each_xen_cpu(cpu, policy->cpus) {
>> +             op.u.set_pminfo.id = cpu;
>> +             ret = HYPERVISOR_dom0_op(&op);
>> +             if (ret) {
>> +                     pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
>> +                     goto err_free_states;
>> +             }
>> +             pr_debug("CPU%u - P-states uploaded\n", cpu);
>> +
>> +             for (i = 0; i < dst_perf->state_count; i++) {
>> +                     pr_debug("    state %d: %d MHz, %d uS\n",
>> +                              i, (u32) dst_states[i].core_frequency,
>> +                              (u32) dst_states[i].transition_latency);
>> +             }
>> +     }
>> +
>> +err_free_states:
>> +     kfree(dst_states);
>> +     return ret;
>> +}
>> +
>> +/*
>> + * Returns:
>> + *   Negative: Failure
>> + *   0:        Success
>> + *   Positive: When we have a managed CPU and the sysfs got symlinked
>> + */
>> +static int xen_cpufreq_add_dev_policy(unsigned int cpu,
>> +                               struct cpufreq_policy *policy)
>> +{
>> +     int ret = 0;
>> +#ifdef CONFIG_SMP
>> +     unsigned long flags;
>> +     unsigned int j;
>> +
>> +     for_each_cpu(j, policy->cpus) {
>> +             struct cpufreq_policy *managed_policy;
>> +
>> +             if (cpu == j)
>> +                     continue;
>> +
>> +             /* Check for existing affected CPUs.
>> +              * They may not be aware of it due to CPU Hotplug.
>> +              * cpufreq_cpu_put is called when the device is removed
>> +              * in __cpufreq_remove_dev()
>> +              */
>> +             managed_policy = xen_cpufreq_cpu_get(j);
>> +             if (unlikely(managed_policy)) {
>> +                     /* Set proper policy_cpu */
>> +                     unlock_policy_rwsem_write(cpu);
>> +                     per_cpu(cpufreq_policy_cpu, cpu) =
>> +                                             managed_policy->cpu;
>> +
>> +                     if (lock_policy_rwsem_write(cpu) < 0) {
>> +                             /* Should not go through policy unlock path */
>> +                             if (cpufreq_driver->exit)
>> +                                     cpufreq_driver->exit(policy);
>> +                             xen_cpufreq_cpu_put(managed_policy);
>> +                             return -EBUSY;
>> +                     }
>> +
>> +                     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +                     cpumask_copy(managed_policy->cpus, policy->cpus);
>> +                     per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
>> +                     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +
>> +                     pr_debug("CPU already managed, adding link\n");
>> +
>> +                     /*
>> +                      * Success. We only needed to be added to the mask.
>> +                      * Call driver->exit() because only the cpu parent of
>> +                      * the kobj needed to call init().
>> +                      */
>> +                     if (cpufreq_driver->exit)
>> +                             cpufreq_driver->exit(policy);
>> +
>> +                     return 1;
>> +             }
>> +     }
>> +#endif
>> +     return ret;
>> +}
>> +
>> +/**
>> + * xen_cpufreq_add_dev - add a CPU device
>> + *
>> + * Adds the cpufreq interface for a CPU device.
>> + */
>> +static int xen_cpufreq_add_dev(unsigned int cpu)
>> +{
>> +     int ret = 0;
>> +     struct cpufreq_policy *policy;
>> +     unsigned long flags;
>> +     unsigned int j;
>> +
>> +     pr_debug("adding CPU %u\n", cpu);
>> +
>> +#ifdef CONFIG_SMP
>> +     /* check whether a different CPU already registered this
>> +      * CPU because it is in the same boat. */
>> +     policy = xen_cpufreq_cpu_get(cpu);
>> +     if (unlikely(policy)) {
>> +             xen_cpufreq_cpu_put(policy);
>> +             return 0;
>> +     }
>> +#endif
>> +
>> +     if (!try_module_get(cpufreq_driver->owner)) {
>> +             ret = -EINVAL;
>> +             goto module_out;
>> +     }
>> +
>> +     ret = -ENOMEM;
>> +     policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
>> +     if (!policy)
>> +             goto nomem_out;
>> +
>> +     if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
>> +             goto err_free_policy;
>> +
>> +     if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
>> +             goto err_free_cpumask;
>> +
>> +     policy->cpu = cpu;
>> +     cpumask_copy(policy->cpus, cpumask_of(cpu));
>> +
>> +     /* Initially set CPU itself as the policy_cpu */
>> +     per_cpu(cpufreq_policy_cpu, cpu) = cpu;
>> +     ret = (lock_policy_rwsem_write(cpu) < 0);
>> +     WARN_ON(ret);
>> +
>> +     /* call driver. From then on the cpufreq must be able
>> +      * to accept all calls to ->verify and ->setpolicy for this CPU
>> +      */
>> +     ret = cpufreq_driver->init(policy);
>> +     if (ret) {
>> +             pr_debug("initialization failed\n");
>> +             goto err_unlock_policy;
>> +     }
>> +     ret = xen_cpufreq_add_dev_policy(cpu, policy);
>> +     if (ret) {
>> +             if (ret > 0)
>> +                     /* This is a managed cpu, symlink created,
>> +                        exit with 0 */
>> +                     ret = 0;
>> +             goto err_unlock_policy;
>> +     }
>> +
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +     for_each_cpu(j, policy->cpus) {
>> +             per_cpu(cpufreq_cpu_data, j) = policy;
>> +             per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
>> +     }
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +
>> +     unlock_policy_rwsem_write(cpu);
>> +
>> +     module_put(cpufreq_driver->owner);
>> +     pr_debug("initialization complete\n");
>> +
>> +     return 0;
>> +
>> +err_unlock_policy:
>> +     unlock_policy_rwsem_write(cpu);
>> +     free_cpumask_var(policy->related_cpus);
>> +err_free_cpumask:
>> +     free_cpumask_var(policy->cpus);
>> +err_free_policy:
>> +     kfree(policy);
>> +nomem_out:
>> +     module_put(cpufreq_driver->owner);
>> +module_out:
>> +     return ret;
>> +}
>> +
>> +/**
>> + * __cpufreq_remove_dev - remove a CPU device
>> + *
>> + * Removes the cpufreq interface for a CPU device.
>> + * Caller should already have policy_rwsem in write mode for this CPU.
>> + * This routine frees the rwsem before returning.
>> + */
>> +static int __cpufreq_remove_dev(unsigned int cpu)
>> +{
>> +     unsigned long flags;
>> +     struct cpufreq_policy *data;
>> +#ifdef CONFIG_SMP
>> +     unsigned int j;
>> +#endif
>> +
>> +     pr_debug("unregistering CPU %u\n", cpu);
>> +
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +     data = per_cpu(cpufreq_cpu_data, cpu);
>> +
>> +     if (!data) {
>> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +             unlock_policy_rwsem_write(cpu);
>> +             return -EINVAL;
>> +     }
>> +     per_cpu(cpufreq_cpu_data, cpu) = NULL;
>> +
>> +
>> +#ifdef CONFIG_SMP
>> +     /* if this isn't the CPU which is the parent of the kobj, we
>> +      * only need to unlink, put and exit
>> +      */
>> +     if (unlikely(cpu != data->cpu)) {
>> +             pr_debug("removing link\n");
>> +             cpumask_clear_cpu(cpu, data->cpus);
>> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +             xen_cpufreq_cpu_put(data);
>> +             unlock_policy_rwsem_write(cpu);
>> +             return 0;
>> +     }
>> +#endif
>> +
>> +#ifdef CONFIG_SMP
>> +
>> +     /* if we have other CPUs still registered, we need to unlink them,
>> +      * or else wait_for_completion below will lock up. Clean the
>> +      * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
>> +      * the sysfs links afterwards.
>> +      */
>> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
>> +             for_each_cpu(j, data->cpus) {
>> +                     if (j == cpu)
>> +                             continue;
>> +                     per_cpu(cpufreq_cpu_data, j) = NULL;
>> +             }
>> +     }
>> +
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +
>> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
>> +             for_each_cpu(j, data->cpus) {
>> +                     if (j == cpu)
>> +                             continue;
>> +                     pr_debug("removing link for cpu %u\n", j);
>> +                     unlock_policy_rwsem_write(cpu);
>> +                     lock_policy_rwsem_write(cpu);
>> +                     xen_cpufreq_cpu_put(data);
>> +             }
>> +     }
>> +#else
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +#endif
>> +
>> +     unlock_policy_rwsem_write(cpu);
>> +
>> +     lock_policy_rwsem_write(cpu);
>> +     if (cpufreq_driver->exit)
>> +             cpufreq_driver->exit(data);
>> +     unlock_policy_rwsem_write(cpu);
>> +
>> +     free_cpumask_var(data->related_cpus);
>> +     free_cpumask_var(data->cpus);
>> +     kfree(data);
>> +
>> +     return 0;
>> +}
>> +
>> +static int cpufreq_remove_dev(unsigned int cpu)
>> +{
>> +     int retval;
>> +
>> +     if (unlikely(lock_policy_rwsem_write(cpu)))
>> +             BUG();
>> +
>> +     retval = __cpufreq_remove_dev(cpu);
>> +     return retval;
>> +}
>> +
>> +/*********************************************************************
>> + *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
>> + *********************************************************************/
>> +
>> +/**
>> + * adjust_jiffies - adjust the system "loops_per_jiffy"
>> + *
>> + * This function alters the system "loops_per_jiffy" for the clock
>> + * speed change. Note that loops_per_jiffy cannot be updated on SMP
>> + * systems as each CPU might be scaled differently. So, use the arch
>> + * per-CPU loops_per_jiffy value wherever possible.
>> + */
>> +#ifndef CONFIG_SMP
>> +static unsigned long l_p_j_ref;
>> +static unsigned int  l_p_j_ref_freq;
>> +
>> +static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
>> +{
>> +     if (ci->flags & CPUFREQ_CONST_LOOPS)
>> +             return;
>> +
>> +     if (!l_p_j_ref_freq) {
>> +             l_p_j_ref = loops_per_jiffy;
>> +             l_p_j_ref_freq = ci->old;
>> +             pr_debug("saving %lu as reference value for loops_per_jiffy; "
>> +                     "freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
>> +     }
>> +     if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
>> +         (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
>> +             loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
>> +                                                             ci->new);
>> +             pr_debug("scaling loops_per_jiffy to %lu "
>> +                     "for frequency %u kHz\n", loops_per_jiffy, ci->new);
>> +     }
>> +}
>> +#else
>> +static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
>> +{
>> +     return;
>> +}
>> +#endif
>
> There is quite a lot of code duplication with cpufreq.c, I don't think
> that is going to be acceptable for the upstream maintainers.
It is very complicated to use an common code. Some functions copied
and modified. I'll try to do something in the future.

>> +/**
>> + * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
>> + * on frequency transition.
>> + *
>> + * This function calls the transition notifiers and the "adjust_jiffies"
>> + * function. It is called twice on all CPU frequency changes that have
>> + * external effects.
>> + */
>> +void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
>> +                                unsigned int state)
>> +{
>> +     struct cpufreq_policy *policy;
>> +
>> +     BUG_ON(irqs_disabled());
>> +
>> +     freqs->flags = cpufreq_driver->flags;
>> +     pr_debug("notification %u of frequency transition to %u kHz\n",
>> +              state, freqs->new);
>> +
>> +     policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
>> +     switch (state) {
>> +     case CPUFREQ_PRECHANGE:
>> +             /* detect if the driver reported a value as "old frequency"
>> +              * which is not equal to what the cpufreq core thinks is
>> +              * "old frequency".
>> +              */
>> +             if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
>> +                     if ((policy) && (policy->cpu == freqs->cpu) &&
>> +                         (policy->cur) && (policy->cur != freqs->old)) {
>> +                             pr_debug("Warning: CPU frequency is"
>> +                                      " %u, cpufreq assumed %u kHz.\n",
>> +                                      freqs->old, policy->cur);
>> +                             freqs->old = policy->cur;
>> +                     }
>> +             }
>> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
>> +                                      CPUFREQ_PRECHANGE, freqs);
>> +             adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
>> +             break;
>> +
>> +     case CPUFREQ_POSTCHANGE:
>> +             adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
>> +             pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
>> +                      (unsigned long)freqs->cpu);
>> +             trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
>> +             trace_cpu_frequency(freqs->new, freqs->cpu);
>> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
>> +                                      CPUFREQ_POSTCHANGE, freqs);
>> +             if (likely(policy) && likely(policy->cpu == freqs->cpu))
>> +                     policy->cur = freqs->new;
>> +             break;
>> +     }
>> +}
>> +
>> +/*********************************************************************
>> + *                              GOVERNORS                            *
>> + *********************************************************************/
>> +
>> +int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
>> +                             unsigned int target_freq,
>> +                             unsigned int relation)
>> +{
>> +     int retval = -EINVAL;
>> +     unsigned int old_target_freq = target_freq;
>> +
>> +     /* Make sure that target_freq is within supported range */
>> +     if (target_freq > policy->max)
>> +             target_freq = policy->max;
>> +     if (target_freq < policy->min)
>> +             target_freq = policy->min;
>> +
>> +     pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
>> +              policy->cpu, target_freq, relation, old_target_freq);
>> +
>> +     if (target_freq == policy->cur)
>> +             return 0;
>> +
>> +     if (cpufreq_driver->target)
>> +             retval = cpufreq_driver->target(policy, target_freq,
>> +                                                 relation);
>> +
>> +     return retval;
>> +}
>> +
>> +int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
>> +                           unsigned int target_freq,
>> +                           unsigned int relation)
>> +{
>> +     int ret = -EINVAL;
>> +
>> +     if (!policy)
>> +             goto no_policy;
>> +
>> +     if (unlikely(lock_policy_rwsem_write(policy->cpu)))
>> +             goto fail;
>> +
>> +     ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
>> +
>> +     unlock_policy_rwsem_write(policy->cpu);
>> +
>> +fail:
>> +     xen_cpufreq_cpu_put(policy);
>> +no_policy:
>> +     return ret;
>> +}
>> +
>> +/*********************************************************************
>> + *                    HANDLE COMMANDS FROM XEN                       *
>> + *********************************************************************/
>> +static void cpufreq_work_hnd(struct work_struct *w);
>> +
>> +static struct workqueue_struct *cpufreq_wq;
>> +static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
>> +
>> +static void cpufreq_work_hnd(struct work_struct *w)
>> +{
>> +     int ret;
>> +     struct cpufreq_policy *policy;
>> +     struct cpufreq_sh_info *cpufreq_info;
>> +
>> +     cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
>> +
>> +     policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
>> +     ret = xen_cpufreq_driver_target(policy,
>> +                                     cpufreq_info->freq,
>> +                                     cpufreq_info->relation);
>> +
>> +     cpufreq_info->result = ret;
>> +}
>
> No barriers? No locking?
I'll add barriers in the next patch-set.

>> +static irqreturn_t cpufreq_interrupt(int irq, void *data)
>> +{
>> +     queue_work(cpufreq_wq, &cpufreq_work);
>> +     return IRQ_HANDLED;
>> +}
>> +
>> +/*********************************************************************
>> + *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
>> + *********************************************************************/
>> +
>> +/**
>> + * xen_cpufreq_register_driver - register a CPU Frequency driver
>> + * @driver_data: A struct cpufreq_driver containing the values#
>> + * submitted by the CPU Frequency driver.
>> + *
>> + *   Registers a CPU Frequency driver to this core code. This code
>> + * returns zero on success, -EBUSY when another driver got here first
>> + * (and isn't unregistered in the meantime).
>> + *
>> + */
>> +int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
>> +{
>> +     unsigned long flags;
>> +     int ret;
>> +     unsigned int cpu;
>> +     struct cpufreq_frequency_table *table;
>> +     struct cpufreq_policy *policy;
>> +     cpumask_var_t pushed_cpus;
>> +     int irq;
>> +
>> +     if (!xen_nr_cpus)
>> +             return -EPROBE_DEFER;
>> +
>> +     if (!driver_data || !driver_data->verify || !driver_data->init ||
>> +         (!driver_data->target))
>> +             return -EINVAL;
>> +
>> +     pr_debug("trying to register driver %s\n", driver_data->name);
>> +
>> +     if (driver_data->setpolicy)
>> +             driver_data->flags |= CPUFREQ_CONST_LOOPS;
>> +
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +
>> +     if (cpufreq_driver) {
>> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +             return -EBUSY;
>> +     }
>> +     cpufreq_driver = driver_data;
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +
>> +     irq = bind_virq_to_irq(VIRQ_CPUFREQ, 0);
>> +     if (irq < 0) {
>> +             pr_err("Bind virq (%d) error (%d)\n", VIRQ_CPUFREQ, irq);
>> +             ret = irq;
>> +             goto err_remove_drv;
>> +     }
>> +
>> +     irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN|IRQ_NOPROBE);
>> +
>> +     ret = request_irq(irq, cpufreq_interrupt, 0,
>> +                        "xen_cpufreq", NULL);
>> +
>> +     if (ret < 0) {
>> +             pr_err("Request irq (%d) error (%d)\n", irq, ret);
>> +             goto err_unbind_from_irqhnd;
>> +     }
>> +
>> +     xen_irq = irq;
>> +
>> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
>> +             ret = xen_cpufreq_add_dev(cpu);
>> +             if (ret)
>> +                     goto err_remove_cpu;
>> +     }
>> +
>> +     if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
>> +             goto err_remove_cpu;
>> +
>> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
>> +             if (cpumask_test_cpu(cpu, pushed_cpus))
>> +                     continue;
>> +
>> +             policy = xen_cpufreq_cpu_get(cpu);
>> +             if (!policy) {
>> +                     ret = -EINVAL;
>> +                     goto err_free_cpumask;
>> +             }
>> +
>> +             cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
>> +             table = cpufreq_frequency_get_table(policy->cpu);
>> +             if (!table) {
>> +                     ret = -EINVAL;
>> +                     goto err_free_cpumask;
>> +             }
>> +
>> +             ret = push_data_to_hypervisor(policy, table);
>> +             if (ret)
>> +                     goto err_free_cpumask;
>> +     }
>> +
>> +     free_cpumask_var(pushed_cpus);
>> +
>> +     pr_debug("driver %s up and running\n", driver_data->name);
>> +
>> +     return 0;
>> +
>> +err_free_cpumask:
>> +     free_cpumask_var(pushed_cpus);
>> +err_remove_cpu:
>> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
>> +             cpufreq_remove_dev(cpu);
>> +err_unbind_from_irqhnd:
>> +     unbind_from_irqhandler(irq, NULL);
>> +err_remove_drv:
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +     cpufreq_driver = NULL;
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +     return ret;
>> +}
>> +
>> +/**
>> + * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
>> + *
>> + *    Unregister the current CPUFreq driver. Only call this if you have
>> + * the right to do so, i.e. if you have succeeded in initialising before!
>> + * Returns zero if successful, and -EINVAL if the cpufreq_driver is
>> + * currently not initialised.
>> + */
>> +int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
>> +{
>> +     unsigned long flags;
>> +     unsigned int cpu;
>> +
>> +     if (!cpufreq_driver || (driver != cpufreq_driver))
>> +             return -EINVAL;
>> +
>> +     pr_debug("unregistering driver %s\n", driver->name);
>> +
>> +     unbind_from_irqhandler(xen_irq, NULL);
>> +
>> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
>> +             cpufreq_remove_dev(cpu);
>> +
>> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> +     cpufreq_driver = NULL;
>> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +
>> +     return 0;
>> +}
>> +
>> +struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
>> +     .notify_transition = xen_cpufreq_notify_transition,
>> +     .register_driver = xen_cpufreq_register_driver,
>> +     .unregister_driver = xen_cpufreq_unregister_driver,
>> +};
>> +
>> +static int __init xen_cpufreq_init(void)
>> +{
>> +     int ret;
>> +     int i;
>> +
>> +     struct xen_sysctl op = {
>> +             .cmd                    = XEN_SYSCTL_physinfo,
>> +             .interface_version      = XEN_SYSCTL_INTERFACE_VERSION,
>> +     };
>> +
>> +     ret = HYPERVISOR_sysctl(&op);
>> +     if (ret) {
>> +             pr_err("Hypervisor get physinfo error (%d)\n", ret);
>> +             return ret;
>> +     }
>> +
>> +     xen_nr_cpus = op.u.physinfo.nr_cpus;
>> +     if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
>> +             xen_nr_cpus = 0;
>> +             pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
>> +             return -EINVAL;
>> +     }
>> +
>> +     for (i = 0; i < xen_nr_cpus; i++) {
>> +             per_cpu(cpufreq_policy_cpu, i) = -1;
>> +             init_rwsem(&per_cpu(cpu_policy_rwsem, i));
>> +     }
>> +
>> +     cpufreq_wq = alloc_workqueue("xen_cpufreq", 0, 1);
>> +     if (!cpufreq_wq) {
>> +             pr_err("Create workqueue error\n");
>> +             ret = -ENOMEM;
>> +             goto err_create_wq;
>> +     }
>> +
>> +     return 0;
>> +
>> +err_create_wq:
>> +     xen_nr_cpus = 0;
>> +     return ret;
>> +}
>> +
>> +MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
>> +MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
>> +MODULE_LICENSE("GPL");
>> +
>> +core_initcall(xen_cpufreq_init);
>> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
>> index c57d5f6..ee3b154 100644
>> --- a/include/xen/interface/platform.h
>> +++ b/include/xen/interface/platform.h
>> @@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
>>  #define XEN_PX_PSS   2
>>  #define XEN_PX_PPC   4
>>  #define XEN_PX_PSD   8
>> +#define XEN_PX_DATA  16
>>
>>  struct xen_power_register {
>>       uint32_t     space_id;
>> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> index cf64566..9133110 100644
>> --- a/include/xen/interface/xen.h
>> +++ b/include/xen/interface/xen.h
>> @@ -81,6 +81,7 @@
>>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
>>  #define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
>> +#define VIRQ_CPUFREQ    14 /* (DOM0) Notify cpufreq driver                */
>>
>>  /* 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 Nov 06 11:56:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11: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 1XmLfj-0004qh-U8; Thu, 06 Nov 2014 11:56:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmLfi-0004qc-PW
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 11:56:14 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	E1/99-02576-ED16B545; Thu, 06 Nov 2014 11:56:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415274972!11788269!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32215 invoked from network); 6 Nov 2014 11:56:13 -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;
	6 Nov 2014 11:56:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="188724315"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 06:56:11 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmLb9-0005Qo-P0;
	Thu, 06 Nov 2014 11:51:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmLb9-0001af-GF;
	Thu, 06 Nov 2014 11:51:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21595.24771.302806.319751@mariner.uk.xensource.com>
Date: Thu, 6 Nov 2014 11:51:31 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <545B6A2002000078000454EC@mail.emea.novell.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> so this continues to be a result of swiotlb issues on the source host.
> Iirc you had indicated you took care of this - did that perhaps only
> affect -unstable?

My change to the host property in the osstest hostdb didn't have the
intended effect (or, any relevant effect).  I'm fixing this but it
will involve a change to osstest.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:56:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11: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 1XmLfj-0004qh-U8; Thu, 06 Nov 2014 11:56:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmLfi-0004qc-PW
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 11:56:14 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	E1/99-02576-ED16B545; Thu, 06 Nov 2014 11:56:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415274972!11788269!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32215 invoked from network); 6 Nov 2014 11:56:13 -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;
	6 Nov 2014 11:56:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="188724315"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 06:56:11 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmLb9-0005Qo-P0;
	Thu, 06 Nov 2014 11:51:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmLb9-0001af-GF;
	Thu, 06 Nov 2014 11:51:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21595.24771.302806.319751@mariner.uk.xensource.com>
Date: Thu, 6 Nov 2014 11:51:31 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <545B6A2002000078000454EC@mail.emea.novell.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> so this continues to be a result of swiotlb issues on the source host.
> Iirc you had indicated you took care of this - did that perhaps only
> affect -unstable?

My change to the host property in the osstest hostdb didn't have the
intended effect (or, any relevant effect).  I'm fixing this but it
will involve a change to osstest.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:56:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:56:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLgK-0004tK-At; Thu, 06 Nov 2014 11:56:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmLgJ-0004t8-7y
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:56:51 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5B/B9-02702-2026B545; Thu, 06 Nov 2014 11:56:50 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415275008!11807433!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10563 invoked from network); 6 Nov 2014 11:56:49 -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;
	6 Nov 2014 11:56:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="190132722"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 06:56:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmLWs-0005Hf-LE;
	Thu, 06 Nov 2014 11:47:06 +0000
Date: Thu, 6 Nov 2014 11:46:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <545A5F1F.9030006@linaro.org>
Message-ID: <alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
References: <545A5F1F.9030006@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/arm: kernel BUG at
 /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Julien,
I didn't manage to reproduce the issue you are seeing but I think you
are right: non-LPAE kernels could get in trouble by calling
xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
occur on x86 because config XEN depends on X86_32 && X86_PAE.

The following patch should fix the issue:


diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ac5d41b..489620d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
 	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
 	phys_addr_t paddr = dma;
 
-	BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
-
 	paddr |= baddr & ~PAGE_MASK;
 
 	return paddr;
@@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 
 	BUG_ON(dir == DMA_NONE);
 
-	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
+	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr)) {


On Wed, 5 Nov 2014, Julien Grall wrote:
> Hi Stefano,
> 
> I've tried your patch series [1] "introduce GNTTABOP_cache_flush"
> on midway with non-LPAE (i.e short descriptor) kernel.
> 
> While your series should fix the cache flush on this kind of kernel,
> I'm still hitting a BUG_ON when I boot a guest (see stack trace [2]).
> 
> >From a quick look this is because the dma and physical address don't have
> the same size (resp. 64 and 32 bits). Technically xen_bus_to_phys doesn't really
> have a meaning on Xen ARM: the address is still a DMA address but we cast it to
> a physical address (not sure why?).
> 
> It occurs when I use the multi_v7 config (+ XEN) as DOM0. Disabling CONFIG_LPAE
> in the config should also do the job.
> 
> Regards,
> 
> [1] https://lkml.org/lkml/2014/10/27/441
> 
> [2] Stack trace:
> 
> [   98.092290] dma 0x2b6769000 paddr 0xb6769000
> [   98.096475] ------------[ cut here ]------------
> [   98.101147] kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102!
> [   98.109219] Internal error: Oops - BUG: 0 [#1] SMP ARM
> [   98.114427] Modules linked in:
> [   98.117554] CPU: 3 PID: 48 Comm: irq/115-highban Not tainted 3.18.0-rc3-00051-g93cf079-dirty #231
> [   98.126493] task: db281680 ti: db40e000 task.ti: db40e000
> [   98.131965] PC is at xen_unmap_single+0xc4/0xc8
> [   98.136563] LR is at xen_unmap_single+0xc4/0xc8
> [   98.141162] pc : [<c04d1640>]    lr : [<c04d1640>]    psr: 60000013
> [   98.141162] sp : db40fdf0  ip : 00000000  fp : b6769000
> [   98.152793] r10: 00000200  r9 : 00000002  r8 : 00000002
> [   98.158088] r7 : 00000000  r6 : 002b6769  r5 : 00000002  r4 : b6769000
> [   98.164693] r3 : 00000753  r2 : 1af49000  r1 : dbbc73bc  r0 : 00000020
> [   98.171282] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> [   98.178660] Control: 10c5387d  Table: 39e3c06a  DAC: 00000015
> [   98.184475] Process irq/115-highban (pid: 48, stack limit = 0xdb40e250)
> [   98.191159] Stack: (0xdb40fdf0 to 0xdb410000)
> [   98.195586] fde0:                                     b6769000 00000020 00000000 00000002
> [   98.203833] fe00: db40fe00 db0ea210 00000000 d98a1a80 00000001 00000001 00000002 db0ea210
> [   98.212079] fe20: 00000000 db3e3410 db3f1790 c04d1880 00000200 00000002 00000000 00000016
> [   98.220325] fe40: 0000091e db4100b8 d98a1a80 db410000 00000001 000000b0 00000001 c05cdddc
> [   98.228570] fe60: 00000000 c0262f9c db08c01c db281680 db40e010 db4100b8 db410000 db4116c8
> [   98.236817] fe80: 00000001 c05ce0b0 00000000 00000000 db410000 c05ce478 db410000 db4116c8
> [   98.245068] fea0: 00000000 db410000 e0880100 00000008 00000000 e0880000 00000001 c05e5288
> [   98.253309] fec0: c0c8a994 db40fee8 e0804000 c020897c c041c868 60000013 ffffffff 00000000
> [   98.261554] fee0: db3f1890 0000001f 00000073 00000001 db3f1890 c02836ac db00f7d4 c05e57d0
> [   98.269801] ff00: c05e5788 db3f6340 db00f780 00000000 00000001 db00f780 db3f6340 c02836c8
> [   98.278047] ff20: db3f6360 db40e000 00000000 c02839ec c02838b4 db40e030 00000000 c02837f8
> [   98.286293] ff40: 00000000 db3f6380 00000000 db3f6340 c02838b4 00000000 00000000 00000000
> [   98.294538] ff60: 00000000 c0262358 00000000 00000000 00000000 db3f6340 00000000 00000000
> [   98.302785] ff80: db40ff80 db40ff80 00000000 00000000 db40ff90 db40ff90 db40ffac db3f6380
> [   98.311031] ffa0: c0262280 00000000 00000000 c020f278 00000000 00000000 00000000 00000000
> [   98.319276] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [   98.327522] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [   98.335780] [<c04d1640>] (xen_unmap_single) from [<c04d1880>] (xen_swiotlb_unmap_sg_attrs+0x48/0x68)
> [   98.344974] [<c04d1880>] (xen_swiotlb_unmap_sg_attrs) from [<c05cdddc>] (ata_sg_clean+0x8c/0x120)
> [   98.353912] [<c05cdddc>] (ata_sg_clean) from [<c05ce0b0>] (__ata_qc_complete+0x34/0x144)
> [   98.362071] [<c05ce0b0>] (__ata_qc_complete) from [<c05ce478>] (ata_qc_complete_multiple+0xa0/0xd4)
> [   98.371194] [<c05ce478>] (ata_qc_complete_multiple) from [<c05e5288>] (ahci_port_thread_fn+0x138/0x638)
> [   98.380649] [<c05e5288>] (ahci_port_thread_fn) from [<c05e57d0>] (ahci_thread_fn+0x48/0x90)
> [   98.389067] [<c05e57d0>] (ahci_thread_fn) from [<c02836c8>] (irq_thread_fn+0x1c/0x40)
> [   98.396970] [<c02836c8>] (irq_thread_fn) from [<c02839ec>] (irq_thread+0x138/0x174)
> [   98.404693] [<c02839ec>] (irq_thread) from [<c0262358>] (kthread+0xd8/0xf0)
> [   98.411723] [<c0262358>] (kthread) from [<c020f278>] (ret_from_fork+0x14/0x3c)
> [   98.419011] Code: e1a02004 e1a03005 e34c00ad eb0f9c9a (e7f001f2) 
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 11:56:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 11:56:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmLgK-0004tK-At; Thu, 06 Nov 2014 11:56:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmLgJ-0004t8-7y
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 11:56:51 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5B/B9-02702-2026B545; Thu, 06 Nov 2014 11:56:50 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415275008!11807433!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10563 invoked from network); 6 Nov 2014 11:56:49 -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;
	6 Nov 2014 11:56:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="190132722"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 06:56:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmLWs-0005Hf-LE;
	Thu, 06 Nov 2014 11:47:06 +0000
Date: Thu, 6 Nov 2014 11:46:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <545A5F1F.9030006@linaro.org>
Message-ID: <alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
References: <545A5F1F.9030006@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/arm: kernel BUG at
 /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Julien,
I didn't manage to reproduce the issue you are seeing but I think you
are right: non-LPAE kernels could get in trouble by calling
xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
occur on x86 because config XEN depends on X86_32 && X86_PAE.

The following patch should fix the issue:


diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ac5d41b..489620d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
 	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
 	phys_addr_t paddr = dma;
 
-	BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
-
 	paddr |= baddr & ~PAGE_MASK;
 
 	return paddr;
@@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 
 	BUG_ON(dir == DMA_NONE);
 
-	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
+	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr)) {


On Wed, 5 Nov 2014, Julien Grall wrote:
> Hi Stefano,
> 
> I've tried your patch series [1] "introduce GNTTABOP_cache_flush"
> on midway with non-LPAE (i.e short descriptor) kernel.
> 
> While your series should fix the cache flush on this kind of kernel,
> I'm still hitting a BUG_ON when I boot a guest (see stack trace [2]).
> 
> >From a quick look this is because the dma and physical address don't have
> the same size (resp. 64 and 32 bits). Technically xen_bus_to_phys doesn't really
> have a meaning on Xen ARM: the address is still a DMA address but we cast it to
> a physical address (not sure why?).
> 
> It occurs when I use the multi_v7 config (+ XEN) as DOM0. Disabling CONFIG_LPAE
> in the config should also do the job.
> 
> Regards,
> 
> [1] https://lkml.org/lkml/2014/10/27/441
> 
> [2] Stack trace:
> 
> [   98.092290] dma 0x2b6769000 paddr 0xb6769000
> [   98.096475] ------------[ cut here ]------------
> [   98.101147] kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102!
> [   98.109219] Internal error: Oops - BUG: 0 [#1] SMP ARM
> [   98.114427] Modules linked in:
> [   98.117554] CPU: 3 PID: 48 Comm: irq/115-highban Not tainted 3.18.0-rc3-00051-g93cf079-dirty #231
> [   98.126493] task: db281680 ti: db40e000 task.ti: db40e000
> [   98.131965] PC is at xen_unmap_single+0xc4/0xc8
> [   98.136563] LR is at xen_unmap_single+0xc4/0xc8
> [   98.141162] pc : [<c04d1640>]    lr : [<c04d1640>]    psr: 60000013
> [   98.141162] sp : db40fdf0  ip : 00000000  fp : b6769000
> [   98.152793] r10: 00000200  r9 : 00000002  r8 : 00000002
> [   98.158088] r7 : 00000000  r6 : 002b6769  r5 : 00000002  r4 : b6769000
> [   98.164693] r3 : 00000753  r2 : 1af49000  r1 : dbbc73bc  r0 : 00000020
> [   98.171282] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> [   98.178660] Control: 10c5387d  Table: 39e3c06a  DAC: 00000015
> [   98.184475] Process irq/115-highban (pid: 48, stack limit = 0xdb40e250)
> [   98.191159] Stack: (0xdb40fdf0 to 0xdb410000)
> [   98.195586] fde0:                                     b6769000 00000020 00000000 00000002
> [   98.203833] fe00: db40fe00 db0ea210 00000000 d98a1a80 00000001 00000001 00000002 db0ea210
> [   98.212079] fe20: 00000000 db3e3410 db3f1790 c04d1880 00000200 00000002 00000000 00000016
> [   98.220325] fe40: 0000091e db4100b8 d98a1a80 db410000 00000001 000000b0 00000001 c05cdddc
> [   98.228570] fe60: 00000000 c0262f9c db08c01c db281680 db40e010 db4100b8 db410000 db4116c8
> [   98.236817] fe80: 00000001 c05ce0b0 00000000 00000000 db410000 c05ce478 db410000 db4116c8
> [   98.245068] fea0: 00000000 db410000 e0880100 00000008 00000000 e0880000 00000001 c05e5288
> [   98.253309] fec0: c0c8a994 db40fee8 e0804000 c020897c c041c868 60000013 ffffffff 00000000
> [   98.261554] fee0: db3f1890 0000001f 00000073 00000001 db3f1890 c02836ac db00f7d4 c05e57d0
> [   98.269801] ff00: c05e5788 db3f6340 db00f780 00000000 00000001 db00f780 db3f6340 c02836c8
> [   98.278047] ff20: db3f6360 db40e000 00000000 c02839ec c02838b4 db40e030 00000000 c02837f8
> [   98.286293] ff40: 00000000 db3f6380 00000000 db3f6340 c02838b4 00000000 00000000 00000000
> [   98.294538] ff60: 00000000 c0262358 00000000 00000000 00000000 db3f6340 00000000 00000000
> [   98.302785] ff80: db40ff80 db40ff80 00000000 00000000 db40ff90 db40ff90 db40ffac db3f6380
> [   98.311031] ffa0: c0262280 00000000 00000000 c020f278 00000000 00000000 00000000 00000000
> [   98.319276] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [   98.327522] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [   98.335780] [<c04d1640>] (xen_unmap_single) from [<c04d1880>] (xen_swiotlb_unmap_sg_attrs+0x48/0x68)
> [   98.344974] [<c04d1880>] (xen_swiotlb_unmap_sg_attrs) from [<c05cdddc>] (ata_sg_clean+0x8c/0x120)
> [   98.353912] [<c05cdddc>] (ata_sg_clean) from [<c05ce0b0>] (__ata_qc_complete+0x34/0x144)
> [   98.362071] [<c05ce0b0>] (__ata_qc_complete) from [<c05ce478>] (ata_qc_complete_multiple+0xa0/0xd4)
> [   98.371194] [<c05ce478>] (ata_qc_complete_multiple) from [<c05e5288>] (ahci_port_thread_fn+0x138/0x638)
> [   98.380649] [<c05e5288>] (ahci_port_thread_fn) from [<c05e57d0>] (ahci_thread_fn+0x48/0x90)
> [   98.389067] [<c05e57d0>] (ahci_thread_fn) from [<c02836c8>] (irq_thread_fn+0x1c/0x40)
> [   98.396970] [<c02836c8>] (irq_thread_fn) from [<c02839ec>] (irq_thread+0x138/0x174)
> [   98.404693] [<c02839ec>] (irq_thread) from [<c0262358>] (kthread+0xd8/0xf0)
> [   98.411723] [<c0262358>] (kthread) from [<c020f278>] (ret_from_fork+0x14/0x3c)
> [   98.419011] Code: e1a02004 e1a03005 e34c00ad eb0f9c9a (e7f001f2) 
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 12:22:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 12:22:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmM54-0005rO-PQ; Thu, 06 Nov 2014 12:22:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmM53-0005qd-4q
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 12:22:25 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	22/85-25727-0086B545; Thu, 06 Nov 2014 12:22:24 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415276542!7118714!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30946 invoked from network); 6 Nov 2014 12:22:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 12:22:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="190141219"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 07:22:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmM4y-0006Cy-VQ;
	Thu, 06 Nov 2014 12:22:20 +0000
Date: Thu, 6 Nov 2014 12:22:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141106103337.GA19702@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Catalin Marinas wrote:
> On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> > On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > > On Mon, Nov 03, 2014 at 11:10:18AM +0000, Stefano Stabellini wrote:
> > > > On Mon, 3 Nov 2014, Will Deacon wrote:
> > > > > On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> > > > > > On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > > > > > > Introduce a boolean flag and an accessor function to check whether a
> > > > > > > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > > > > > > 
> > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > > > > CC: will.deacon@arm.com
> > > > > > 
> > > > > > Will, Catalin,
> > > > > > are you OK with this patch?
> > > > > 
> > > > > It would be nicer if the dma_coherent flag didn't have to be duplicated by
> > > > > each architecture in dev_archdata. Is there any reason not to put it in the
> > > > > core code?
> > > > 
> > > > Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> > > > struct device as Catalin initially suggested, what would be the default
> > > > for each architecture? Where would I set it for arch that don't use
> > > > device tree?
> > > 
> > > You don't need to. An architecture that has coherent DMA always doesn't
> > > need to do anything. One that has non-coherent DMA always only needs to
> > > select HAVE_DMA_NONCOHERENT. One that has a mix of both needs to find a
> > > way to set dev->dma_coherent. Since that's a new API you introduce, it
> > > doesn't break any existing architectures.
> > 
> > I am not sure that this is better than the current patch but I can see
> > that this approach is not too controversial, so I am happy to go with
> > whatever the maintainers prefer.
> 
> Functionally it is the same, but just less code duplication.
> 
> > > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > > standard cache maintenance would be enough (but that's a Xen problem,
> > > not sure how to solve).
> > 
> > It is a thorny issue indeed.
> > Xen would need to know how to do non-standard cache maintenance
> > operations.
> 
> Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
> just use the currently registered dma ops.

It is Xen, so El2 hypervisor.


> > Otherwise we would need to resurrect XENFEAT_grant_map_identity (that I
> > am reverting in this series) and be content with having CONFIG_XEN_DOM0
> > depend on CONFIG_ARM_LPAE.
> 
> So what does buy you? Is it just the hope that with LPAE you won't have
> weird system caches?

Let me explain a bit more and let's assume there is no SMMU.

The problem is not normal dma originating in dom0, currently mapped 1:1
(pseudo-physical == physical). The problem are dma operations that
involve foreign pages (pages belonging to other virtual machines)
currently mapped also in dom0 to do IO. It is common for the Xen PV
network and block frontends to grant access to one or more pages to the
network and block backends for IO. The backends, usually in dom0, map
the pages and perform the actual IO. Sometimes the IO is a dma operation
that involves one of the granted pages directly.

For these pages, the pseudo-physical address in dom0 is different from
the physical address. Dom0 keeps track of the pseudo-physical to
physical relationship (pfn_to_mfn in Xen terminology). The swiotlb-xen
driver makes sure to return the right mfn from map_page and map_sg.

However some of the dma_ops give you only a dma_addr_t handle
(unmap_page and unmap_sg), that is the physical address of the page.
Dom0 doesn't know how to find the pseudo-physical address corresponding
to it. Therefore it also doesn't know how to find the struct page for
it. This is not a trivial problem to solve as the same page can be
granted multiple times, therefore could have multiple pseudo-physical
addresses and multiple struct pages corresponding to one physical
address in dom0.

Fortunately these dma_ops don't actually need to do much. In fact they
only need to flush caches if the device is not dma-coherent. So the
current proposed solution is to issue an hypercall to ask Xen to do the
flushing, passing the physical address dom0 knows.

The older solution that this series is reverting, is based on
XENFEAT_grant_map_identity, that was a feature offered by Xen, already
reverted in the hypervisor. XENFEAT_grant_map_identity told dom0 that
the hypervisor mapped foreign pages at the address requested by dom0
*and* at pseudo-physical == physical address. That way Dom0 could always
find the page at pseudo-physical == physical address and do the flushing
there. However it only works if Dom0 is compiled with CONFIG_ARM_LPAE
(a non-LPAE kernel is not guaranteed to be able to reach the
pseudo-physical address in question) and we didn't want to introduce
that limitation so we changed approach.


> > > diff --git a/arch/Kconfig b/arch/Kconfig
> > > index 05d7a8a458d5..8462b2e7491b 100644
> > > --- a/arch/Kconfig
> > > +++ b/arch/Kconfig
> > > @@ -203,6 +203,9 @@ config HAVE_DMA_ATTRS
> > >  config HAVE_DMA_CONTIGUOUS
> > >  	bool
> > >  
> > > +config HAVE_DMA_NONCOHERENT
> > > +	bool
> > > +
> > >  config GENERIC_SMP_IDLE_THREAD
> > >         bool
> > >  
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index 89c4b5ccc68d..fd7d5522764c 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -40,6 +40,7 @@ config ARM
> > >  	select HAVE_DMA_API_DEBUG
> > >  	select HAVE_DMA_ATTRS
> > >  	select HAVE_DMA_CONTIGUOUS if MMU
> > > +	select HAVE_DMA_NONCOHERENT if OF
> > >  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
> > >  	select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
> > >  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index 9532f8d5857e..eb7a5aa64e0e 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -46,6 +46,7 @@ config ARM64
> > >  	select HAVE_DMA_API_DEBUG
> > >  	select HAVE_DMA_ATTRS
> > >  	select HAVE_DMA_CONTIGUOUS
> > > +	select HAVE_DMA_NONCOHERENT
> > >  	select HAVE_DYNAMIC_FTRACE
> > >  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
> > >  	select HAVE_FTRACE_MCOUNT_RECORD
> > > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> > > index 3b64d0bf5bba..7e827726b702 100644
> > > --- a/drivers/of/platform.c
> > > +++ b/drivers/of/platform.c
> > > @@ -183,6 +183,7 @@ static void of_dma_configure(struct device *dev)
> > >  	 * dma coherent operations.
> > >  	 */
> > >  	if (of_dma_is_coherent(dev->of_node)) {
> > > +		dev->dma_coherent = true;
> > >  		set_arch_dma_coherent_ops(dev);
> > >  		dev_dbg(dev, "device is dma coherent\n");
> > >  	}
> > 
> > I think that this would need to be #ifdef'ed as it is possible to have
> > OF support but no HAVE_DMA_NONCOHERENT (PPC?).
> 
> The field is always there. But with !HAVE_DMA_NONCOHERENT,
> is_device_dma_coherent() would always return 1. You could avoid
> defining is_device_dma_coherent() entirely when !HAVE_DMA_NONCOHERENT,
> it wouldn't be worse than your patch in terms of an undefined function.
> 
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index ce1f21608b16..e00ca876db01 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -796,6 +796,7 @@ struct device {
> > >  
> > >  	bool			offline_disabled:1;
> > >  	bool			offline:1;
> > > +	bool			dma_coherent:1;
> > >  };
> > 
> > I guess we would have to #ifdef CONFIG_HAVE_DMA_NONCOHERENT the
> > dma_coherent flag, right? Otherwise architecures that do not select
> > CONFIG_HAVE_DMA_NONCOHERENT (x86 for example) would end up with a flag
> > in struct device that doesn't reflect the properties of the device (dma
> > coherent devices with dev->dma_coherent == 0).
> 
> In my proposal you should not read this field directly but rather access
> it only via is_device_dma_coherent() (you can add a function for setting
> it as well).

This is the part that I don't like: on other architectures you now have a
field in struct device that is actually incorrect. It is true that one
should call the accessor function to read the property but still...

As I don't feel that strongly against it, I'll resend including this
patch (with you as the author of course).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 12:22:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 12:22:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmM54-0005rO-PQ; Thu, 06 Nov 2014 12:22:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmM53-0005qd-4q
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 12:22:25 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	22/85-25727-0086B545; Thu, 06 Nov 2014 12:22:24 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415276542!7118714!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30946 invoked from network); 6 Nov 2014 12:22:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 12:22:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="190141219"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 07:22:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmM4y-0006Cy-VQ;
	Thu, 06 Nov 2014 12:22:20 +0000
Date: Thu, 6 Nov 2014 12:22:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141106103337.GA19702@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Catalin Marinas wrote:
> On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> > On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > > On Mon, Nov 03, 2014 at 11:10:18AM +0000, Stefano Stabellini wrote:
> > > > On Mon, 3 Nov 2014, Will Deacon wrote:
> > > > > On Mon, Nov 03, 2014 at 10:46:03AM +0000, Stefano Stabellini wrote:
> > > > > > On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > > > > > > Introduce a boolean flag and an accessor function to check whether a
> > > > > > > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > > > > > > 
> > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > > > > CC: will.deacon@arm.com
> > > > > > 
> > > > > > Will, Catalin,
> > > > > > are you OK with this patch?
> > > > > 
> > > > > It would be nicer if the dma_coherent flag didn't have to be duplicated by
> > > > > each architecture in dev_archdata. Is there any reason not to put it in the
> > > > > core code?
> > > > 
> > > > Yes, there is a reason for it: if I added a boolean dma_coherent flag in
> > > > struct device as Catalin initially suggested, what would be the default
> > > > for each architecture? Where would I set it for arch that don't use
> > > > device tree?
> > > 
> > > You don't need to. An architecture that has coherent DMA always doesn't
> > > need to do anything. One that has non-coherent DMA always only needs to
> > > select HAVE_DMA_NONCOHERENT. One that has a mix of both needs to find a
> > > way to set dev->dma_coherent. Since that's a new API you introduce, it
> > > doesn't break any existing architectures.
> > 
> > I am not sure that this is better than the current patch but I can see
> > that this approach is not too controversial, so I am happy to go with
> > whatever the maintainers prefer.
> 
> Functionally it is the same, but just less code duplication.
> 
> > > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > > standard cache maintenance would be enough (but that's a Xen problem,
> > > not sure how to solve).
> > 
> > It is a thorny issue indeed.
> > Xen would need to know how to do non-standard cache maintenance
> > operations.
> 
> Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
> just use the currently registered dma ops.

It is Xen, so El2 hypervisor.


> > Otherwise we would need to resurrect XENFEAT_grant_map_identity (that I
> > am reverting in this series) and be content with having CONFIG_XEN_DOM0
> > depend on CONFIG_ARM_LPAE.
> 
> So what does buy you? Is it just the hope that with LPAE you won't have
> weird system caches?

Let me explain a bit more and let's assume there is no SMMU.

The problem is not normal dma originating in dom0, currently mapped 1:1
(pseudo-physical == physical). The problem are dma operations that
involve foreign pages (pages belonging to other virtual machines)
currently mapped also in dom0 to do IO. It is common for the Xen PV
network and block frontends to grant access to one or more pages to the
network and block backends for IO. The backends, usually in dom0, map
the pages and perform the actual IO. Sometimes the IO is a dma operation
that involves one of the granted pages directly.

For these pages, the pseudo-physical address in dom0 is different from
the physical address. Dom0 keeps track of the pseudo-physical to
physical relationship (pfn_to_mfn in Xen terminology). The swiotlb-xen
driver makes sure to return the right mfn from map_page and map_sg.

However some of the dma_ops give you only a dma_addr_t handle
(unmap_page and unmap_sg), that is the physical address of the page.
Dom0 doesn't know how to find the pseudo-physical address corresponding
to it. Therefore it also doesn't know how to find the struct page for
it. This is not a trivial problem to solve as the same page can be
granted multiple times, therefore could have multiple pseudo-physical
addresses and multiple struct pages corresponding to one physical
address in dom0.

Fortunately these dma_ops don't actually need to do much. In fact they
only need to flush caches if the device is not dma-coherent. So the
current proposed solution is to issue an hypercall to ask Xen to do the
flushing, passing the physical address dom0 knows.

The older solution that this series is reverting, is based on
XENFEAT_grant_map_identity, that was a feature offered by Xen, already
reverted in the hypervisor. XENFEAT_grant_map_identity told dom0 that
the hypervisor mapped foreign pages at the address requested by dom0
*and* at pseudo-physical == physical address. That way Dom0 could always
find the page at pseudo-physical == physical address and do the flushing
there. However it only works if Dom0 is compiled with CONFIG_ARM_LPAE
(a non-LPAE kernel is not guaranteed to be able to reach the
pseudo-physical address in question) and we didn't want to introduce
that limitation so we changed approach.


> > > diff --git a/arch/Kconfig b/arch/Kconfig
> > > index 05d7a8a458d5..8462b2e7491b 100644
> > > --- a/arch/Kconfig
> > > +++ b/arch/Kconfig
> > > @@ -203,6 +203,9 @@ config HAVE_DMA_ATTRS
> > >  config HAVE_DMA_CONTIGUOUS
> > >  	bool
> > >  
> > > +config HAVE_DMA_NONCOHERENT
> > > +	bool
> > > +
> > >  config GENERIC_SMP_IDLE_THREAD
> > >         bool
> > >  
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index 89c4b5ccc68d..fd7d5522764c 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -40,6 +40,7 @@ config ARM
> > >  	select HAVE_DMA_API_DEBUG
> > >  	select HAVE_DMA_ATTRS
> > >  	select HAVE_DMA_CONTIGUOUS if MMU
> > > +	select HAVE_DMA_NONCOHERENT if OF
> > >  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
> > >  	select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
> > >  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index 9532f8d5857e..eb7a5aa64e0e 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -46,6 +46,7 @@ config ARM64
> > >  	select HAVE_DMA_API_DEBUG
> > >  	select HAVE_DMA_ATTRS
> > >  	select HAVE_DMA_CONTIGUOUS
> > > +	select HAVE_DMA_NONCOHERENT
> > >  	select HAVE_DYNAMIC_FTRACE
> > >  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
> > >  	select HAVE_FTRACE_MCOUNT_RECORD
> > > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> > > index 3b64d0bf5bba..7e827726b702 100644
> > > --- a/drivers/of/platform.c
> > > +++ b/drivers/of/platform.c
> > > @@ -183,6 +183,7 @@ static void of_dma_configure(struct device *dev)
> > >  	 * dma coherent operations.
> > >  	 */
> > >  	if (of_dma_is_coherent(dev->of_node)) {
> > > +		dev->dma_coherent = true;
> > >  		set_arch_dma_coherent_ops(dev);
> > >  		dev_dbg(dev, "device is dma coherent\n");
> > >  	}
> > 
> > I think that this would need to be #ifdef'ed as it is possible to have
> > OF support but no HAVE_DMA_NONCOHERENT (PPC?).
> 
> The field is always there. But with !HAVE_DMA_NONCOHERENT,
> is_device_dma_coherent() would always return 1. You could avoid
> defining is_device_dma_coherent() entirely when !HAVE_DMA_NONCOHERENT,
> it wouldn't be worse than your patch in terms of an undefined function.
> 
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index ce1f21608b16..e00ca876db01 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -796,6 +796,7 @@ struct device {
> > >  
> > >  	bool			offline_disabled:1;
> > >  	bool			offline:1;
> > > +	bool			dma_coherent:1;
> > >  };
> > 
> > I guess we would have to #ifdef CONFIG_HAVE_DMA_NONCOHERENT the
> > dma_coherent flag, right? Otherwise architecures that do not select
> > CONFIG_HAVE_DMA_NONCOHERENT (x86 for example) would end up with a flag
> > in struct device that doesn't reflect the properties of the device (dma
> > coherent devices with dev->dma_coherent == 0).
> 
> In my proposal you should not read this field directly but rather access
> it only via is_device_dma_coherent() (you can add a function for setting
> it as well).

This is the part that I don't like: on other architectures you now have a
field in struct device that is actually incorrect. It is true that one
should call the accessor function to read the property but still...

As I don't feel that strongly against it, I'll resend including this
patch (with you as the author of course).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 12:25:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 12:25:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmM8B-0005xl-C8; Thu, 06 Nov 2014 12:25:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmM8A-0005xf-1T
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 12:25:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9B/85-24532-1C86B545; Thu, 06 Nov 2014 12:25:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415276736!11888649!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5053 invoked from network); 6 Nov 2014 12:25:37 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 12:25:37 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so1311723wib.7
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 04:25:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=vsGmS5aQh0TCWEFQjt3ovGaRgIM1+dR9UpvsRyOgLHo=;
	b=Bb9YwXFRHC910u66Xomn0BQo9lcpN1YuVthpijcx2zG1q8kNuw6Qg3gWnvhxMycDJ0
	Em5ESNVLCk7nhaucsnONFnheOJuToLKLIYWM+vAYRIyzliWWKRTORAU/SrvDhBDVOP03
	BUs0muWUqA7XSTLKkht3Gr74k/Ban7je0rKGwMrHvTqpJF1IS2wyuF2WIBZBBkXVt0cu
	oHuHt1E14TFsOV1iKrvx0zNa2U4BZenG8ut1JyFTHpc6lzha9e7tI1hS+FwfW7ipvGZG
	2qqxk3cG8O4eHNw3xzb6NKO5kPet/6agdSNPthgXDrK79Fc6oexmgvAlYyT28xkZrN2i
	bpAg==
X-Gm-Message-State: ALoCoQmHJ/FJmTUEqZP/b1Y54DIZsW4P5cKxSH0FVKGQmJFTg0Is+eAKcWR8kDQ4kN7r5okfl7cm
X-Received: by 10.194.92.148 with SMTP id cm20mr4051562wjb.88.1415276736780;
	Thu, 06 Nov 2014 04:25:36 -0800 (PST)
Received: from [192.168.42.87] (188.29.164.20.threembb.co.uk. [188.29.164.20])
	by mx.google.com with ESMTPSA id
	f9sm7614796wjw.31.2014.11.06.04.25.35 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 04:25:36 -0800 (PST)
Message-ID: <545B68BB.8020205@linaro.org>
Date: Thu, 06 Nov 2014 12:25:31 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <545A5F1F.9030006@linaro.org>
	<alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: kernel BUG at
	/local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 06/11/2014 11:46, Stefano Stabellini wrote:
> Hello Julien,

Hi Stefano,

> I didn't manage to reproduce the issue you are seeing but I think you
> are right: non-LPAE kernels could get in trouble by calling
> xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
> occur on x86 because config XEN depends on X86_32 && X86_PAE.
>
> The following patch should fix the issue:
>
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ac5d41b..489620d 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
>   	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
>   	phys_addr_t paddr = dma;
>
> -	BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
> -

Are you sure that removing this BUG_ON is safe? There is some of place 
where we pass a physical address rather than a DMA. See 
xen_swiotlb_sync_single.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 12:25:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 12:25:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmM8B-0005xl-C8; Thu, 06 Nov 2014 12:25:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmM8A-0005xf-1T
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 12:25:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9B/85-24532-1C86B545; Thu, 06 Nov 2014 12:25:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415276736!11888649!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5053 invoked from network); 6 Nov 2014 12:25:37 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 12:25:37 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so1311723wib.7
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 04:25:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=vsGmS5aQh0TCWEFQjt3ovGaRgIM1+dR9UpvsRyOgLHo=;
	b=Bb9YwXFRHC910u66Xomn0BQo9lcpN1YuVthpijcx2zG1q8kNuw6Qg3gWnvhxMycDJ0
	Em5ESNVLCk7nhaucsnONFnheOJuToLKLIYWM+vAYRIyzliWWKRTORAU/SrvDhBDVOP03
	BUs0muWUqA7XSTLKkht3Gr74k/Ban7je0rKGwMrHvTqpJF1IS2wyuF2WIBZBBkXVt0cu
	oHuHt1E14TFsOV1iKrvx0zNa2U4BZenG8ut1JyFTHpc6lzha9e7tI1hS+FwfW7ipvGZG
	2qqxk3cG8O4eHNw3xzb6NKO5kPet/6agdSNPthgXDrK79Fc6oexmgvAlYyT28xkZrN2i
	bpAg==
X-Gm-Message-State: ALoCoQmHJ/FJmTUEqZP/b1Y54DIZsW4P5cKxSH0FVKGQmJFTg0Is+eAKcWR8kDQ4kN7r5okfl7cm
X-Received: by 10.194.92.148 with SMTP id cm20mr4051562wjb.88.1415276736780;
	Thu, 06 Nov 2014 04:25:36 -0800 (PST)
Received: from [192.168.42.87] (188.29.164.20.threembb.co.uk. [188.29.164.20])
	by mx.google.com with ESMTPSA id
	f9sm7614796wjw.31.2014.11.06.04.25.35 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 04:25:36 -0800 (PST)
Message-ID: <545B68BB.8020205@linaro.org>
Date: Thu, 06 Nov 2014 12:25:31 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <545A5F1F.9030006@linaro.org>
	<alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: kernel BUG at
	/local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 06/11/2014 11:46, Stefano Stabellini wrote:
> Hello Julien,

Hi Stefano,

> I didn't manage to reproduce the issue you are seeing but I think you
> are right: non-LPAE kernels could get in trouble by calling
> xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
> occur on x86 because config XEN depends on X86_32 && X86_PAE.
>
> The following patch should fix the issue:
>
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ac5d41b..489620d 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
>   	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
>   	phys_addr_t paddr = dma;
>
> -	BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
> -

Are you sure that removing this BUG_ON is safe? There is some of place 
where we pass a physical address rather than a DMA. See 
xen_swiotlb_sync_single.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 12:49:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 12:49:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMUd-0006XF-Id; Thu, 06 Nov 2014 12:48:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmMUc-0006XA-Ai
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 12:48:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7E/CF-24532-13E6B545; Thu, 06 Nov 2014 12:48:49 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415278129!11940091!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10064 invoked from network); 6 Nov 2014 12:48:49 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 12:48:49 -0000
Received: by mail-wg0-f50.google.com with SMTP id z12so1107299wgg.9
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 04:48:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:content-type:content-transfer-encoding;
	bh=DsNyLdjxtxSSuQ0M5HivQQAM/jmtCbYCqJ8MLW5OOnk=;
	b=JPFcSnNaWPvsGnNPUAE07vN3OfKPCoX8nZfGtq9mQtKv5VUXmdM8dVxaNpiiIynxjX
	/cX5lgV0FZTSplDo/QXd7+/6yVRZS4A5/95kCIMTP/bfRaZE3/RAdxXOJCdZszODh4yj
	s+fAvlcCS7lNSNAW6fhv6jHMrlOL44+iPRc7c6KwB+VeNOFhAqrkCOMtjuIu+oW2u/sc
	sApvlpPAIXwQYRLPfWiOmhDjN/m53x+ORdZCDs+ymrcfkcHWQNY8Sh0ttPFzb13xMPsN
	53yT9vhcM2B4L7rwl4KuYtvw2oXs9KwxoRBdRNVCmIpcXr0GHo97FSWCxedbiArqlycr
	ZYFw==
X-Gm-Message-State: ALoCoQla/ZdaS71ltuUXyBejPcTJPag3NrgTFZh9DZO9b0L+kBRS2EGSSkrdDK9Xn3q3F96q8Qm6
X-Received: by 10.194.78.82 with SMTP id z18mr4246006wjw.120.1415278127587;
	Thu, 06 Nov 2014 04:48:47 -0800 (PST)
Received: from [192.168.42.87] (188.29.165.51.threembb.co.uk. [188.29.165.51])
	by mx.google.com with ESMTPSA id
	cr6sm277731wjb.44.2014.11.06.04.48.46 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 04:48:46 -0800 (PST)
Message-ID: <545B6E2B.9030303@linaro.org>
Date: Thu, 06 Nov 2014 12:48:43 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] xen/arm: Bootwrapper update to support PSCI and GICv3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 all,

I've been working on updating our aarch64 bootwrapper
to support new feature such as PSCI and GICv3.

Rather than porting the feature from the Linux bootwrapper [1].
I've added support of Xen on top of the Linux repo.

Below an example to configure bootwrapper with GICv3 and PSCI for
the foundation model:

42sh> ./configure --host=aarch64-linux-gnu		\
--with-kernel-dir=$HOME/linux-build/aarch64	\
--with-dtb=$HOME/arm-trusted-firmware/fdts/fvp-foundation-gicv3-psci.dtb \
--with-cmdline="console=hvc0 earlycon=pl011,0x1c090000 init=/root/init.sh root=/dev/vda" \
--enable-psci --with-xen-cmdline="dtuart=serial0 console=dtuart no-bootscrub"		 \
--with-xen="$HOME/xen" --enable-gicv3
42sh> make

Make will produce a xen-system.axf which is the image used to boot
Xen on the model.

The branch with the new version is:
git://xenbits.xen.org/people/julieng/boot-wrapper-aarch64.git branch xen

Ian, can you update your repo with this new version?

Regards,

[1] git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 12:49:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 12:49:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMUd-0006XF-Id; Thu, 06 Nov 2014 12:48:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmMUc-0006XA-Ai
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 12:48:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7E/CF-24532-13E6B545; Thu, 06 Nov 2014 12:48:49 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415278129!11940091!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10064 invoked from network); 6 Nov 2014 12:48:49 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 12:48:49 -0000
Received: by mail-wg0-f50.google.com with SMTP id z12so1107299wgg.9
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 04:48:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:content-type:content-transfer-encoding;
	bh=DsNyLdjxtxSSuQ0M5HivQQAM/jmtCbYCqJ8MLW5OOnk=;
	b=JPFcSnNaWPvsGnNPUAE07vN3OfKPCoX8nZfGtq9mQtKv5VUXmdM8dVxaNpiiIynxjX
	/cX5lgV0FZTSplDo/QXd7+/6yVRZS4A5/95kCIMTP/bfRaZE3/RAdxXOJCdZszODh4yj
	s+fAvlcCS7lNSNAW6fhv6jHMrlOL44+iPRc7c6KwB+VeNOFhAqrkCOMtjuIu+oW2u/sc
	sApvlpPAIXwQYRLPfWiOmhDjN/m53x+ORdZCDs+ymrcfkcHWQNY8Sh0ttPFzb13xMPsN
	53yT9vhcM2B4L7rwl4KuYtvw2oXs9KwxoRBdRNVCmIpcXr0GHo97FSWCxedbiArqlycr
	ZYFw==
X-Gm-Message-State: ALoCoQla/ZdaS71ltuUXyBejPcTJPag3NrgTFZh9DZO9b0L+kBRS2EGSSkrdDK9Xn3q3F96q8Qm6
X-Received: by 10.194.78.82 with SMTP id z18mr4246006wjw.120.1415278127587;
	Thu, 06 Nov 2014 04:48:47 -0800 (PST)
Received: from [192.168.42.87] (188.29.165.51.threembb.co.uk. [188.29.165.51])
	by mx.google.com with ESMTPSA id
	cr6sm277731wjb.44.2014.11.06.04.48.46 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 04:48:46 -0800 (PST)
Message-ID: <545B6E2B.9030303@linaro.org>
Date: Thu, 06 Nov 2014 12:48:43 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] xen/arm: Bootwrapper update to support PSCI and GICv3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 all,

I've been working on updating our aarch64 bootwrapper
to support new feature such as PSCI and GICv3.

Rather than porting the feature from the Linux bootwrapper [1].
I've added support of Xen on top of the Linux repo.

Below an example to configure bootwrapper with GICv3 and PSCI for
the foundation model:

42sh> ./configure --host=aarch64-linux-gnu		\
--with-kernel-dir=$HOME/linux-build/aarch64	\
--with-dtb=$HOME/arm-trusted-firmware/fdts/fvp-foundation-gicv3-psci.dtb \
--with-cmdline="console=hvc0 earlycon=pl011,0x1c090000 init=/root/init.sh root=/dev/vda" \
--enable-psci --with-xen-cmdline="dtuart=serial0 console=dtuart no-bootscrub"		 \
--with-xen="$HOME/xen" --enable-gicv3
42sh> make

Make will produce a xen-system.axf which is the image used to boot
Xen on the model.

The branch with the new version is:
git://xenbits.xen.org/people/julieng/boot-wrapper-aarch64.git branch xen

Ian, can you update your repo with this new version?

Regards,

[1] git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 12:49:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 12:49:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMVe-0006aa-0t; Thu, 06 Nov 2014 12:49:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmMVc-0006aQ-EB
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 12:49:52 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	E7/98-07724-F6E6B545; Thu, 06 Nov 2014 12:49:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415278189!10889583!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7774 invoked from network); 6 Nov 2014 12:49:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 12:49:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="188739920"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 07:49:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmMP5-0006Yd-GB;
	Thu, 06 Nov 2014 12:43:07 +0000
Date: Thu, 6 Nov 2014 12:42:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <545B68BB.8020205@linaro.org>
Message-ID: <alpine.DEB.2.02.1411061239520.22875@kaball.uk.xensource.com>
References: <545A5F1F.9030006@linaro.org>
	<alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
	<545B68BB.8020205@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/arm: kernel BUG at
 /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Julien Grall wrote:
> 
> On 06/11/2014 11:46, Stefano Stabellini wrote:
> > Hello Julien,
> 
> Hi Stefano,
> 
> > I didn't manage to reproduce the issue you are seeing but I think you
> > are right: non-LPAE kernels could get in trouble by calling
> > xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
> > occur on x86 because config XEN depends on X86_32 && X86_PAE.
> > 
> > The following patch should fix the issue:
> > 
> > 
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ac5d41b..489620d 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t
> > baddr)
> >   	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
> >   	phys_addr_t paddr = dma;
> > 
> > -	BUG_ON(paddr != dma); /* truncation has occurred, should never happen
> > */
> > -
> 
> Are you sure that removing this BUG_ON is safe? There is some of place where
> we pass a physical address rather than a DMA. See xen_swiotlb_sync_single.

Yes, it is safe, but we do need to change those call sites to pass
dev_addr instead, like I have done with unmap_single in the patch I
appended in the last email:


diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ac5d41b..489620d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 
 	BUG_ON(dir == DMA_NONE);
 
-	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
+	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 12:49:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 12:49:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMVe-0006aa-0t; Thu, 06 Nov 2014 12:49:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmMVc-0006aQ-EB
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 12:49:52 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	E7/98-07724-F6E6B545; Thu, 06 Nov 2014 12:49:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415278189!10889583!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7774 invoked from network); 6 Nov 2014 12:49:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 12:49:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="188739920"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 07:49:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmMP5-0006Yd-GB;
	Thu, 06 Nov 2014 12:43:07 +0000
Date: Thu, 6 Nov 2014 12:42:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <545B68BB.8020205@linaro.org>
Message-ID: <alpine.DEB.2.02.1411061239520.22875@kaball.uk.xensource.com>
References: <545A5F1F.9030006@linaro.org>
	<alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
	<545B68BB.8020205@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/arm: kernel BUG at
 /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Julien Grall wrote:
> 
> On 06/11/2014 11:46, Stefano Stabellini wrote:
> > Hello Julien,
> 
> Hi Stefano,
> 
> > I didn't manage to reproduce the issue you are seeing but I think you
> > are right: non-LPAE kernels could get in trouble by calling
> > xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
> > occur on x86 because config XEN depends on X86_32 && X86_PAE.
> > 
> > The following patch should fix the issue:
> > 
> > 
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ac5d41b..489620d 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t
> > baddr)
> >   	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
> >   	phys_addr_t paddr = dma;
> > 
> > -	BUG_ON(paddr != dma); /* truncation has occurred, should never happen
> > */
> > -
> 
> Are you sure that removing this BUG_ON is safe? There is some of place where
> we pass a physical address rather than a DMA. See xen_swiotlb_sync_single.

Yes, it is safe, but we do need to change those call sites to pass
dev_addr instead, like I have done with unmap_single in the patch I
appended in the last email:


diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ac5d41b..489620d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 
 	BUG_ON(dir == DMA_NONE);
 
-	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
+	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 12:56:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 12:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMcM-0006zI-18; Thu, 06 Nov 2014 12:56:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmMcK-0006zD-4H
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 12:56:48 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	D3/09-25727-F007B545; Thu, 06 Nov 2014 12:56:47 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415278606!6419341!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13719 invoked from network); 6 Nov 2014 12:56:46 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 12:56:46 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so1122358wgg.16
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 04:56:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=BG1ixdIZVavmEBC+hhA6bU9/RUAMtPG683sSZgdkZvA=;
	b=UPUGG/xnzSucsIiLLLwBMjaVAyHb2mep2B6G9ywT1iF183a6ShDl8avwmpA9wDOCAG
	iWM1fX0dj4Wz6y7elRq5yqoIS4s7NAiSj3pU1J0XxgMlefXVArQTQmEyxASl2sVpJQFm
	q1KvK4RScz9/YN8vEvtBRIYjvKmiimn3AHrgAD2lUStZle/Z9s8+QqfRru65dlsSLh67
	mCyxjBPnLeHWkMXvwzGqcT3yYqQB93dpUHEKOfpijdWpMQ0mMSXlaYmgzc8FxYqU1pmn
	z1fM0ioArEqe5XiSgTq1useqZdwOChVdK8klNCrlV+oUSoHGR3GscBS/0mB/uR2fdRl3
	OzJA==
X-Gm-Message-State: ALoCoQkEsS1A1UbaxeVfyPktYZVzkOWP3gZ16lIoAMn/rCdQfCEAIUSV9LZiIvYXbs6n358xXukD
X-Received: by 10.194.243.106 with SMTP id wx10mr2448094wjc.97.1415278606632; 
	Thu, 06 Nov 2014 04:56:46 -0800 (PST)
Received: from [192.168.42.87] (188.29.165.51.threembb.co.uk. [188.29.165.51])
	by mx.google.com with ESMTPSA id
	v10sm8193298wiy.21.2014.11.06.04.56.40 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 04:56:45 -0800 (PST)
Message-ID: <545B7004.5060406@linaro.org>
Date: Thu, 06 Nov 2014 12:56:36 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <545A5F1F.9030006@linaro.org>
	<alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
	<545B68BB.8020205@linaro.org>
	<alpine.DEB.2.02.1411061239520.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411061239520.22875@kaball.uk.xensource.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: kernel BUG at
	/local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 06/11/2014 12:42, Stefano Stabellini wrote:
> On Thu, 6 Nov 2014, Julien Grall wrote:
>>
>> On 06/11/2014 11:46, Stefano Stabellini wrote:
>>> Hello Julien,
>>
>> Hi Stefano,
>>
>>> I didn't manage to reproduce the issue you are seeing but I think you
>>> are right: non-LPAE kernels could get in trouble by calling
>>> xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
>>> occur on x86 because config XEN depends on X86_32 && X86_PAE.
>>>
>>> The following patch should fix the issue:
>>>
>>>
>>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>>> index ac5d41b..489620d 100644
>>> --- a/drivers/xen/swiotlb-xen.c
>>> +++ b/drivers/xen/swiotlb-xen.c
>>> @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t
>>> baddr)
>>>    	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
>>>    	phys_addr_t paddr = dma;
>>>
>>> -	BUG_ON(paddr != dma); /* truncation has occurred, should never happen
>>> */
>>> -
>>
>> Are you sure that removing this BUG_ON is safe? There is some of place where
>> we pass a physical address rather than a DMA. See xen_swiotlb_sync_single.
>
> Yes, it is safe, but we do need to change those call sites to pass
> dev_addr instead, like I have done with unmap_single in the patch I
> appended in the last email:

Ok. I will give a look to modify all the call site.

Regards,

> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ac5d41b..489620d 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
>
>   	BUG_ON(dir == DMA_NONE);
>
> -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
>
>   	/* NOTE: We use dev_addr here, not paddr! */
>   	if (is_xen_swiotlb_buffer(dev_addr)) {
>

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 12:56:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 12:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMcM-0006zI-18; Thu, 06 Nov 2014 12:56:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmMcK-0006zD-4H
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 12:56:48 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	D3/09-25727-F007B545; Thu, 06 Nov 2014 12:56:47 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415278606!6419341!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13719 invoked from network); 6 Nov 2014 12:56:46 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 12:56:46 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so1122358wgg.16
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 04:56:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=BG1ixdIZVavmEBC+hhA6bU9/RUAMtPG683sSZgdkZvA=;
	b=UPUGG/xnzSucsIiLLLwBMjaVAyHb2mep2B6G9ywT1iF183a6ShDl8avwmpA9wDOCAG
	iWM1fX0dj4Wz6y7elRq5yqoIS4s7NAiSj3pU1J0XxgMlefXVArQTQmEyxASl2sVpJQFm
	q1KvK4RScz9/YN8vEvtBRIYjvKmiimn3AHrgAD2lUStZle/Z9s8+QqfRru65dlsSLh67
	mCyxjBPnLeHWkMXvwzGqcT3yYqQB93dpUHEKOfpijdWpMQ0mMSXlaYmgzc8FxYqU1pmn
	z1fM0ioArEqe5XiSgTq1useqZdwOChVdK8klNCrlV+oUSoHGR3GscBS/0mB/uR2fdRl3
	OzJA==
X-Gm-Message-State: ALoCoQkEsS1A1UbaxeVfyPktYZVzkOWP3gZ16lIoAMn/rCdQfCEAIUSV9LZiIvYXbs6n358xXukD
X-Received: by 10.194.243.106 with SMTP id wx10mr2448094wjc.97.1415278606632; 
	Thu, 06 Nov 2014 04:56:46 -0800 (PST)
Received: from [192.168.42.87] (188.29.165.51.threembb.co.uk. [188.29.165.51])
	by mx.google.com with ESMTPSA id
	v10sm8193298wiy.21.2014.11.06.04.56.40 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 04:56:45 -0800 (PST)
Message-ID: <545B7004.5060406@linaro.org>
Date: Thu, 06 Nov 2014 12:56:36 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <545A5F1F.9030006@linaro.org>
	<alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
	<545B68BB.8020205@linaro.org>
	<alpine.DEB.2.02.1411061239520.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411061239520.22875@kaball.uk.xensource.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: kernel BUG at
	/local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 06/11/2014 12:42, Stefano Stabellini wrote:
> On Thu, 6 Nov 2014, Julien Grall wrote:
>>
>> On 06/11/2014 11:46, Stefano Stabellini wrote:
>>> Hello Julien,
>>
>> Hi Stefano,
>>
>>> I didn't manage to reproduce the issue you are seeing but I think you
>>> are right: non-LPAE kernels could get in trouble by calling
>>> xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
>>> occur on x86 because config XEN depends on X86_32 && X86_PAE.
>>>
>>> The following patch should fix the issue:
>>>
>>>
>>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>>> index ac5d41b..489620d 100644
>>> --- a/drivers/xen/swiotlb-xen.c
>>> +++ b/drivers/xen/swiotlb-xen.c
>>> @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t
>>> baddr)
>>>    	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
>>>    	phys_addr_t paddr = dma;
>>>
>>> -	BUG_ON(paddr != dma); /* truncation has occurred, should never happen
>>> */
>>> -
>>
>> Are you sure that removing this BUG_ON is safe? There is some of place where
>> we pass a physical address rather than a DMA. See xen_swiotlb_sync_single.
>
> Yes, it is safe, but we do need to change those call sites to pass
> dev_addr instead, like I have done with unmap_single in the patch I
> appended in the last email:

Ok. I will give a look to modify all the call site.

Regards,

> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ac5d41b..489620d 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
>
>   	BUG_ON(dir == DMA_NONE);
>
> -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
>
>   	/* NOTE: We use dev_addr here, not paddr! */
>   	if (is_xen_swiotlb_buffer(dev_addr)) {
>

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:01:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13:01:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMgR-0007Af-RC; Thu, 06 Nov 2014 13:01:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XmMgQ-0007AZ-9n
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:01:02 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	97/07-24859-D017B545; Thu, 06 Nov 2014 13:01:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415278859!10801510!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21221 invoked from network); 6 Nov 2014 13:01:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 13:01:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="190150222"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 08:00:33 -0500
Received: from cosworth.uk.xensource.com	([10.80.16.52]
	helo=localhost.localdomain ident=ianc)	by ukmail1.uk.xensource.com with
	smtp (Exim 4.69)	(envelope-from <ian.campbell@citrix.com>)	id
	1XmMfw-0006tc-21; Thu, 06 Nov 2014 13:00:33 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Thu, 06 Nov
	2014 13:00:31 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, <ian.jackson@eu.citrix.com>,
	<wei.liu2@citrix.com>
Date: Thu, 6 Nov 2014 13:00:31 +0000
Message-ID: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] tools: libxl: do not leak diskpath during local
	disk attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a
strdup of the device path. This is then passed to the callback, e.g.
parse_bootloader_result but bootloader_cleanup will not free it.

Since the callback is within the scope of the (e)gc and therefore doesn't need
to be malloc'd, a gc'd alloc will do. All other assignments to this field use
the gc.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295

Reported-by: Gedalya <gedalya@gedalya.net>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
This is a bug fix for 4.5.

This fix should be queued for backporting to at least 4.4
---
 tools/libxl/libxl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 18561fb..e76d898 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3030,7 +3030,7 @@ void libxl__device_disk_local_initiate_attach(libxl__egc *egc,
     }
 
     if (dev != NULL)
-        dls->diskpath = strdup(dev);
+        dls->diskpath = libxl__strdup(gc, dev);
 
     dls->callback(egc, dls, 0);
     return;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:01:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13:01:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMgR-0007Af-RC; Thu, 06 Nov 2014 13:01:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XmMgQ-0007AZ-9n
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:01:02 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	97/07-24859-D017B545; Thu, 06 Nov 2014 13:01:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415278859!10801510!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21221 invoked from network); 6 Nov 2014 13:01:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 13:01:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="190150222"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 08:00:33 -0500
Received: from cosworth.uk.xensource.com	([10.80.16.52]
	helo=localhost.localdomain ident=ianc)	by ukmail1.uk.xensource.com with
	smtp (Exim 4.69)	(envelope-from <ian.campbell@citrix.com>)	id
	1XmMfw-0006tc-21; Thu, 06 Nov 2014 13:00:33 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Thu, 06 Nov
	2014 13:00:31 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, <ian.jackson@eu.citrix.com>,
	<wei.liu2@citrix.com>
Date: Thu, 6 Nov 2014 13:00:31 +0000
Message-ID: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] tools: libxl: do not leak diskpath during local
	disk attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a
strdup of the device path. This is then passed to the callback, e.g.
parse_bootloader_result but bootloader_cleanup will not free it.

Since the callback is within the scope of the (e)gc and therefore doesn't need
to be malloc'd, a gc'd alloc will do. All other assignments to this field use
the gc.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295

Reported-by: Gedalya <gedalya@gedalya.net>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
This is a bug fix for 4.5.

This fix should be queued for backporting to at least 4.4
---
 tools/libxl/libxl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 18561fb..e76d898 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3030,7 +3030,7 @@ void libxl__device_disk_local_initiate_attach(libxl__egc *egc,
     }
 
     if (dev != NULL)
-        dls->diskpath = strdup(dev);
+        dls->diskpath = libxl__strdup(gc, dev);
 
     dls->callback(egc, dls, 0);
     return;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:01:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13:01:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMh5-0007E1-82; Thu, 06 Nov 2014 13:01:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmMh4-0007Dp-2X
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:01:42 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	24/BF-26858-5317B545; Thu, 06 Nov 2014 13:01:41 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415278899!10873802!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7651 invoked from network); 6 Nov 2014 13:01:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 13:01:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="190150642"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 08:01:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmMgj-0006vr-3m;
	Thu, 06 Nov 2014 13:01:21 +0000
Date: Thu, 6 Nov 2014 13:01:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <545B7004.5060406@linaro.org>
Message-ID: <alpine.DEB.2.02.1411061300410.22875@kaball.uk.xensource.com>
References: <545A5F1F.9030006@linaro.org>
	<alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
	<545B68BB.8020205@linaro.org>
	<alpine.DEB.2.02.1411061239520.22875@kaball.uk.xensource.com>
	<545B7004.5060406@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/arm: kernel BUG at
 /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Julien Grall wrote:
> On 06/11/2014 12:42, Stefano Stabellini wrote:
> > On Thu, 6 Nov 2014, Julien Grall wrote:
> > > 
> > > On 06/11/2014 11:46, Stefano Stabellini wrote:
> > > > Hello Julien,
> > > 
> > > Hi Stefano,
> > > 
> > > > I didn't manage to reproduce the issue you are seeing but I think you
> > > > are right: non-LPAE kernels could get in trouble by calling
> > > > xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
> > > > occur on x86 because config XEN depends on X86_32 && X86_PAE.
> > > > 
> > > > The following patch should fix the issue:
> > > > 
> > > > 
> > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > > > index ac5d41b..489620d 100644
> > > > --- a/drivers/xen/swiotlb-xen.c
> > > > +++ b/drivers/xen/swiotlb-xen.c
> > > > @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t
> > > > baddr)
> > > >    	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
> > > >    	phys_addr_t paddr = dma;
> > > > 
> > > > -	BUG_ON(paddr != dma); /* truncation has occurred, should never happen
> > > > */
> > > > -
> > > 
> > > Are you sure that removing this BUG_ON is safe? There is some of place
> > > where
> > > we pass a physical address rather than a DMA. See xen_swiotlb_sync_single.
> > 
> > Yes, it is safe, but we do need to change those call sites to pass
> > dev_addr instead, like I have done with unmap_single in the patch I
> > appended in the last email:
> 
> Ok. I will give a look to modify all the call site.

No need, I am already writing a new patch to be part of the next version
of my series.



> 
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ac5d41b..489620d 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev,
> > dma_addr_t dev_addr,
> > 
> >   	BUG_ON(dir == DMA_NONE);
> > 
> > -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> > +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
> > 
> >   	/* NOTE: We use dev_addr here, not paddr! */
> >   	if (is_xen_swiotlb_buffer(dev_addr)) {
> > 
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:01:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13:01:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMh5-0007E1-82; Thu, 06 Nov 2014 13:01:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmMh4-0007Dp-2X
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:01:42 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	24/BF-26858-5317B545; Thu, 06 Nov 2014 13:01:41 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415278899!10873802!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7651 invoked from network); 6 Nov 2014 13:01:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 13:01:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="190150642"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 08:01:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmMgj-0006vr-3m;
	Thu, 06 Nov 2014 13:01:21 +0000
Date: Thu, 6 Nov 2014 13:01:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <545B7004.5060406@linaro.org>
Message-ID: <alpine.DEB.2.02.1411061300410.22875@kaball.uk.xensource.com>
References: <545A5F1F.9030006@linaro.org>
	<alpine.DEB.2.02.1411061127280.22875@kaball.uk.xensource.com>
	<545B68BB.8020205@linaro.org>
	<alpine.DEB.2.02.1411061239520.22875@kaball.uk.xensource.com>
	<545B7004.5060406@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/arm: kernel BUG at
 /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Julien Grall wrote:
> On 06/11/2014 12:42, Stefano Stabellini wrote:
> > On Thu, 6 Nov 2014, Julien Grall wrote:
> > > 
> > > On 06/11/2014 11:46, Stefano Stabellini wrote:
> > > > Hello Julien,
> > > 
> > > Hi Stefano,
> > > 
> > > > I didn't manage to reproduce the issue you are seeing but I think you
> > > > are right: non-LPAE kernels could get in trouble by calling
> > > > xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
> > > > occur on x86 because config XEN depends on X86_32 && X86_PAE.
> > > > 
> > > > The following patch should fix the issue:
> > > > 
> > > > 
> > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > > > index ac5d41b..489620d 100644
> > > > --- a/drivers/xen/swiotlb-xen.c
> > > > +++ b/drivers/xen/swiotlb-xen.c
> > > > @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t
> > > > baddr)
> > > >    	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
> > > >    	phys_addr_t paddr = dma;
> > > > 
> > > > -	BUG_ON(paddr != dma); /* truncation has occurred, should never happen
> > > > */
> > > > -
> > > 
> > > Are you sure that removing this BUG_ON is safe? There is some of place
> > > where
> > > we pass a physical address rather than a DMA. See xen_swiotlb_sync_single.
> > 
> > Yes, it is safe, but we do need to change those call sites to pass
> > dev_addr instead, like I have done with unmap_single in the patch I
> > appended in the last email:
> 
> Ok. I will give a look to modify all the call site.

No need, I am already writing a new patch to be part of the next version
of my series.



> 
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ac5d41b..489620d 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev,
> > dma_addr_t dev_addr,
> > 
> >   	BUG_ON(dir == DMA_NONE);
> > 
> > -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> > +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
> > 
> >   	/* NOTE: We use dev_addr here, not paddr! */
> >   	if (is_xen_swiotlb_buffer(dev_addr)) {
> > 
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:04:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13:04:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMjj-0007bi-Qp; Thu, 06 Nov 2014 13:04:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XmMji-0007bW-3K
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:04:26 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	33/0A-25727-9D17B545; Thu, 06 Nov 2014 13:04:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415279063!10860894!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29990 invoked from network); 6 Nov 2014 13:04:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 13:04:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="190152248"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 08:04:05 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XmMjN-0006yC-AB;
	Thu, 06 Nov 2014 13:04:05 +0000
Date: Thu, 6 Nov 2014 13:04:05 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141106130405.GA2580@zion.uk.xensource.com>
References: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not leak diskpath during
 local disk attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 01:00:31PM +0000, Ian Campbell wrote:
> libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a
> strdup of the device path. This is then passed to the callback, e.g.
> parse_bootloader_result but bootloader_cleanup will not free it.
> 
> Since the callback is within the scope of the (e)gc and therefore doesn't need
> to be malloc'd, a gc'd alloc will do. All other assignments to this field use
> the gc.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295
> 
> Reported-by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>

> ---
> This is a bug fix for 4.5.
> 
> This fix should be queued for backporting to at least 4.4
> ---
>  tools/libxl/libxl.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 18561fb..e76d898 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3030,7 +3030,7 @@ void libxl__device_disk_local_initiate_attach(libxl__egc *egc,
>      }
>  
>      if (dev != NULL)
> -        dls->diskpath = strdup(dev);
> +        dls->diskpath = libxl__strdup(gc, dev);
>  
>      dls->callback(egc, dls, 0);
>      return;
> -- 
> 1.7.10.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:04:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13:04:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMjj-0007bi-Qp; Thu, 06 Nov 2014 13:04:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XmMji-0007bW-3K
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:04:26 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	33/0A-25727-9D17B545; Thu, 06 Nov 2014 13:04:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415279063!10860894!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29990 invoked from network); 6 Nov 2014 13:04:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 13:04:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,325,1413244800"; d="scan'208";a="190152248"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 08:04:05 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XmMjN-0006yC-AB;
	Thu, 06 Nov 2014 13:04:05 +0000
Date: Thu, 6 Nov 2014 13:04:05 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141106130405.GA2580@zion.uk.xensource.com>
References: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not leak diskpath during
 local disk attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 01:00:31PM +0000, Ian Campbell wrote:
> libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a
> strdup of the device path. This is then passed to the callback, e.g.
> parse_bootloader_result but bootloader_cleanup will not free it.
> 
> Since the callback is within the scope of the (e)gc and therefore doesn't need
> to be malloc'd, a gc'd alloc will do. All other assignments to this field use
> the gc.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295
> 
> Reported-by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>

> ---
> This is a bug fix for 4.5.
> 
> This fix should be queued for backporting to at least 4.4
> ---
>  tools/libxl/libxl.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 18561fb..e76d898 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3030,7 +3030,7 @@ void libxl__device_disk_local_initiate_attach(libxl__egc *egc,
>      }
>  
>      if (dev != NULL)
> -        dls->diskpath = strdup(dev);
> +        dls->diskpath = libxl__strdup(gc, dev);
>  
>      dls->callback(egc, dls, 0);
>      return;
> -- 
> 1.7.10.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:10:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13:10:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMp3-0007lU-Io; Thu, 06 Nov 2014 13:09:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iurii.konovalenko@globallogic.com>)
	id 1XmMp2-0007lP-5s
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:09:56 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A4/28-03148-3237B545; Thu, 06 Nov 2014 13:09:55 +0000
X-Env-Sender: iurii.konovalenko@globallogic.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415279392!7175562!1
X-Originating-IP: [64.18.0.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28258 invoked from network); 6 Nov 2014 13:09:54 -0000
Received: from exprod5og104.obsmtp.com (HELO exprod5og104.obsmtp.com)
	(64.18.0.178)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 13:09:54 -0000
Received: from mail-pa0-f46.google.com ([209.85.220.46]) (using TLSv1) by
	exprod5ob104.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtzIKVDRDNMc+kjnMe8W7PkbI5omcJZ@postini.com;
	Thu, 06 Nov 2014 05:09:54 PST
Received: by mail-pa0-f46.google.com with SMTP id lf10so1223210pab.19
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 05:09:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=lebU4rCxbrC2pbBA636BOi5hYnvCDR2R1QgJu5eapgI=;
	b=UaArzhQe/ayxkI/lHjqZm7IQkDNh60M4marWqxROUO6KZChrIHk33L+UNpyhRSCL3X
	YcZPh45P3WWz65pOjRMLVqpCKSMI+73C7aNu2cXIFgP68EB8Rp6NgAE6G7cAyiGvURHU
	BWGgYdPxb9VHa+ul1SO+JWOg64HqHzhXnHBsw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=lebU4rCxbrC2pbBA636BOi5hYnvCDR2R1QgJu5eapgI=;
	b=h6ahC4refK1HNKlHL93eETH6+GLn77sK1vstwX04OaJb8BJT2FVslduxs6lznyMaLn
	ZM9PovY1UdOEZGvee9eDX2Mo/4AIblLY08AgFz3npw0LusS3mVAHB4hPbGQXJZjgBgO4
	PSaf5gykKEanNxpnfuOkR0hGXzbrGzrWgwyLT3IZfrgcTw4+Z5yzg4VRCrpAkfQiXL8C
	Uep21tFdJA9CtUIdWX2XumhM1duJjd2Z4KmEp1N0AwsLQ37XlGVZ/01Iwkj1yByjrxJl
	nHDPUtxwPCre3Z6WeeBs2C3DOh35Bakw/wMb1Bj83x6+OiAkWwHp44xfXrmbt2ZCzbKh
	ttXA==
X-Gm-Message-State: ALoCoQkw7hU4EypbIJ3lfTb005KWXAhBGRILZys8Wmdxr4mzyuZo8zhaBnsXxKVZo60fjJ8QJAI3gm2xWy6N7wQ2johUHFzOtV06OLJTcXjTwNqRQfF6YPTDIvrSvM1Wrn3a9isGCmY5KK56xaCSmJ7XXbPzTsptYg==
X-Received: by 10.66.237.145 with SMTP id vc17mr4446205pac.34.1415279392221;
	Thu, 06 Nov 2014 05:09:52 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.66.237.145 with SMTP id vc17mr4446179pac.34.1415279392058;
	Thu, 06 Nov 2014 05:09:52 -0800 (PST)
Received: by 10.70.122.37 with HTTP; Thu, 6 Nov 2014 05:09:52 -0800 (PST)
In-Reply-To: <CAGQvs6jvhgtrDbKp7teFwONUdXDSARtjtbqLUs9LW7ThB2VtZw@mail.gmail.com>
References: <CABc08zLfxgwPDAQ=qGtnqvD5SZPWOVqGCNsDQMNUqi_BNmx0Ng@mail.gmail.com>
	<544FCEB4.9080307@linaro.org> <1414571045.3584.37.camel@citrix.com>
	<CAGQvs6h65CPshmn79o_gPJdg5txUWkDeRexHsxJUBXRnyKnhsQ@mail.gmail.com>
	<1414663662.2064.21.camel@citrix.com>
	<CAGQvs6jvhgtrDbKp7teFwONUdXDSARtjtbqLUs9LW7ThB2VtZw@mail.gmail.com>
Date: Thu, 6 Nov 2014 15:09:52 +0200
Message-ID: <CABc08z+4NtrkrVKxpn=8tGffx=SBaFKOfDSMko5JFFhH=m_3fg@mail.gmail.com>
From: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
To: Andrii Anisov <andrii.anisov@globallogic.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Fail to start Dom0 in ARM highmem.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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!

At last, I started my setup on Xen 4.5.
Xen has successfully allocated 1GB for Dom0, splitting it in two banks:

(XEN) Allocating 1:1 mappings totalling 1024MB for dom0:
(XEN) BANK[0] 0x00000040000000-0x00000070000000 (768MB)
(XEN) BANK[1] 0x000001c0000000-0x000001d0000000 (256MB)

Thanks a lot guys for your support!
Best regards.

Iurii Konovalenko | Senior Software Engineer
GlobalLogic
P +3.8044.492.9695 M +38.099.932.2909
S yufuntik
www.globallogic.com
http://www.globallogic.com/email_disclaimer.txt


On Thu, Oct 30, 2014 at 1:19 PM, Andrii Anisov
<andrii.anisov@globallogic.com> wrote:
>> If you wanted to stick with 4.4
>
> No we definitely will switch to 4.5.
> We plan to bringup driver domain on that setup, so will need stuff
> from 4.5. Like iomem/interrupt assignment for domU, we will bringup
> their IPMMU (close to ARM SMMU but different), etc.
>
>> either use less RAM for dom0
>
> Yep, that is what we actually will do anyway. We estimate dom0 as a
> "thin dom0". I assume with block device driver only, so it will not
> need lot of RAM.
>
> Andrii Anisov | Team Lead
> GlobalLogic
> Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
> P +38.044.492.9695x3664  M +380505738852  S andriyanisov
> www.globallogic.com
>
> http://www.globallogic.com/email_disclaimer.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:10:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13:10:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmMp3-0007lU-Io; Thu, 06 Nov 2014 13:09:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iurii.konovalenko@globallogic.com>)
	id 1XmMp2-0007lP-5s
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:09:56 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A4/28-03148-3237B545; Thu, 06 Nov 2014 13:09:55 +0000
X-Env-Sender: iurii.konovalenko@globallogic.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415279392!7175562!1
X-Originating-IP: [64.18.0.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28258 invoked from network); 6 Nov 2014 13:09:54 -0000
Received: from exprod5og104.obsmtp.com (HELO exprod5og104.obsmtp.com)
	(64.18.0.178)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 13:09:54 -0000
Received: from mail-pa0-f46.google.com ([209.85.220.46]) (using TLSv1) by
	exprod5ob104.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFtzIKVDRDNMc+kjnMe8W7PkbI5omcJZ@postini.com;
	Thu, 06 Nov 2014 05:09:54 PST
Received: by mail-pa0-f46.google.com with SMTP id lf10so1223210pab.19
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 05:09:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=lebU4rCxbrC2pbBA636BOi5hYnvCDR2R1QgJu5eapgI=;
	b=UaArzhQe/ayxkI/lHjqZm7IQkDNh60M4marWqxROUO6KZChrIHk33L+UNpyhRSCL3X
	YcZPh45P3WWz65pOjRMLVqpCKSMI+73C7aNu2cXIFgP68EB8Rp6NgAE6G7cAyiGvURHU
	BWGgYdPxb9VHa+ul1SO+JWOg64HqHzhXnHBsw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=lebU4rCxbrC2pbBA636BOi5hYnvCDR2R1QgJu5eapgI=;
	b=h6ahC4refK1HNKlHL93eETH6+GLn77sK1vstwX04OaJb8BJT2FVslduxs6lznyMaLn
	ZM9PovY1UdOEZGvee9eDX2Mo/4AIblLY08AgFz3npw0LusS3mVAHB4hPbGQXJZjgBgO4
	PSaf5gykKEanNxpnfuOkR0hGXzbrGzrWgwyLT3IZfrgcTw4+Z5yzg4VRCrpAkfQiXL8C
	Uep21tFdJA9CtUIdWX2XumhM1duJjd2Z4KmEp1N0AwsLQ37XlGVZ/01Iwkj1yByjrxJl
	nHDPUtxwPCre3Z6WeeBs2C3DOh35Bakw/wMb1Bj83x6+OiAkWwHp44xfXrmbt2ZCzbKh
	ttXA==
X-Gm-Message-State: ALoCoQkw7hU4EypbIJ3lfTb005KWXAhBGRILZys8Wmdxr4mzyuZo8zhaBnsXxKVZo60fjJ8QJAI3gm2xWy6N7wQ2johUHFzOtV06OLJTcXjTwNqRQfF6YPTDIvrSvM1Wrn3a9isGCmY5KK56xaCSmJ7XXbPzTsptYg==
X-Received: by 10.66.237.145 with SMTP id vc17mr4446205pac.34.1415279392221;
	Thu, 06 Nov 2014 05:09:52 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.66.237.145 with SMTP id vc17mr4446179pac.34.1415279392058;
	Thu, 06 Nov 2014 05:09:52 -0800 (PST)
Received: by 10.70.122.37 with HTTP; Thu, 6 Nov 2014 05:09:52 -0800 (PST)
In-Reply-To: <CAGQvs6jvhgtrDbKp7teFwONUdXDSARtjtbqLUs9LW7ThB2VtZw@mail.gmail.com>
References: <CABc08zLfxgwPDAQ=qGtnqvD5SZPWOVqGCNsDQMNUqi_BNmx0Ng@mail.gmail.com>
	<544FCEB4.9080307@linaro.org> <1414571045.3584.37.camel@citrix.com>
	<CAGQvs6h65CPshmn79o_gPJdg5txUWkDeRexHsxJUBXRnyKnhsQ@mail.gmail.com>
	<1414663662.2064.21.camel@citrix.com>
	<CAGQvs6jvhgtrDbKp7teFwONUdXDSARtjtbqLUs9LW7ThB2VtZw@mail.gmail.com>
Date: Thu, 6 Nov 2014 15:09:52 +0200
Message-ID: <CABc08z+4NtrkrVKxpn=8tGffx=SBaFKOfDSMko5JFFhH=m_3fg@mail.gmail.com>
From: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
To: Andrii Anisov <andrii.anisov@globallogic.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Fail to start Dom0 in ARM highmem.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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!

At last, I started my setup on Xen 4.5.
Xen has successfully allocated 1GB for Dom0, splitting it in two banks:

(XEN) Allocating 1:1 mappings totalling 1024MB for dom0:
(XEN) BANK[0] 0x00000040000000-0x00000070000000 (768MB)
(XEN) BANK[1] 0x000001c0000000-0x000001d0000000 (256MB)

Thanks a lot guys for your support!
Best regards.

Iurii Konovalenko | Senior Software Engineer
GlobalLogic
P +3.8044.492.9695 M +38.099.932.2909
S yufuntik
www.globallogic.com
http://www.globallogic.com/email_disclaimer.txt


On Thu, Oct 30, 2014 at 1:19 PM, Andrii Anisov
<andrii.anisov@globallogic.com> wrote:
>> If you wanted to stick with 4.4
>
> No we definitely will switch to 4.5.
> We plan to bringup driver domain on that setup, so will need stuff
> from 4.5. Like iomem/interrupt assignment for domU, we will bringup
> their IPMMU (close to ARM SMMU but different), etc.
>
>> either use less RAM for dom0
>
> Yep, that is what we actually will do anyway. We estimate dom0 as a
> "thin dom0". I assume with block device driver only, so it will not
> need lot of RAM.
>
> Andrii Anisov | Team Lead
> GlobalLogic
> Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
> P +38.044.492.9695x3664  M +380505738852  S andriyanisov
> www.globallogic.com
>
> http://www.globallogic.com/email_disclaimer.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmNIz-0008V8-8E; Thu, 06 Nov 2014 13:40:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmNIx-0008V3-O2
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 13:40:51 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	77/38-20825-26A7B545; Thu, 06 Nov 2014 13:40:50 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415281249!10881811!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3596 invoked from network); 6 Nov 2014 13:40:50 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-6.tower-206.messagelabs.com with SMTP;
	6 Nov 2014 13:40:50 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 09BEC66;
	Thu,  6 Nov 2014 07:40:35 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id E1FD95FAD7;
	Thu,  6 Nov 2014 07:40:32 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 7519C13F91E;
	Thu,  6 Nov 2014 07:40:31 -0600 (CST)
Date: Thu, 6 Nov 2014 13:40:29 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141106134028.GB19702@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 12:22:13PM +0000, Stefano Stabellini wrote:
> As I don't feel that strongly against it, I'll resend including this
> patch (with you as the author of course).

Not just yet, let me understand your reply properly ;).

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmNIz-0008V8-8E; Thu, 06 Nov 2014 13:40:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmNIx-0008V3-O2
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 13:40:51 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	77/38-20825-26A7B545; Thu, 06 Nov 2014 13:40:50 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415281249!10881811!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3596 invoked from network); 6 Nov 2014 13:40:50 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-6.tower-206.messagelabs.com with SMTP;
	6 Nov 2014 13:40:50 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 09BEC66;
	Thu,  6 Nov 2014 07:40:35 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id E1FD95FAD7;
	Thu,  6 Nov 2014 07:40:32 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 7519C13F91E;
	Thu,  6 Nov 2014 07:40:31 -0600 (CST)
Date: Thu, 6 Nov 2014 13:40:29 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141106134028.GB19702@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 12:22:13PM +0000, Stefano Stabellini wrote:
> As I don't feel that strongly against it, I'll resend including this
> patch (with you as the author of course).

Not just yet, let me understand your reply properly ;).

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:44:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13: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 1XmNM6-0000Go-RV; Thu, 06 Nov 2014 13:44:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XmNM4-0000Ge-U3
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:44:05 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	8D/65-02698-42B7B545; Thu, 06 Nov 2014 13:44:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415281440!11829419!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7927 invoked from network); 6 Nov 2014 13:44:01 -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;
	6 Nov 2014 13:44:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190164793"
Received: from localhost (10.80.16.17) by smtprelay.citrix.com (10.13.107.78)
	with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 08:43:59 -0500
Message-ID: <1415281437.2030.1.camel@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 6 Nov 2014 13:43:57 +0000
In-Reply-To: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
References: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not leak diskpath during
 local disk attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 13:00 +0000, Ian Campbell wrote:
> libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a
> strdup of the device path. This is then passed to the callback, e.g.
> parse_bootloader_result but bootloader_cleanup will not free it.
> 
> Since the callback is within the scope of the (e)gc and therefore doesn't need
> to be malloc'd, a gc'd alloc will do. All other assignments to this field use
> the gc.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295

I should really have included the valgrind spew:

==4739== 48 bytes in 2 blocks are definitely lost in loss record 30 of 41
==4739==    at 0x4026B2D: malloc (vg_replace_malloc.c:299)
==4739==    by 0x41979FF: strdup (strdup.c:43)
==4739==    by 0x4064EC4: libxl__device_disk_local_initiate_attach (libxl.c:3033)
==4739==    by 0x4099256: libxl__bootloader_run (libxl_bootloader.c:387)
==4739==    by 0x4073CCE: initiate_domain_create (libxl_create.c:915)
==4739==    by 0x4073CCE: do_domain_create (libxl_create.c:1513)
==4739==    by 0x4073E75: libxl_domain_create_new (libxl_create.c:1536)
==4739==    by 0x80578DB: create_domain (xl_cmdimpl.c:2518)
==4739==    by 0x805B4B2: main_create (xl_cmdimpl.c:4652)
==4739==    by 0x804EAB2: main (xl.c:378)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 13:44:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 13: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 1XmNM6-0000Go-RV; Thu, 06 Nov 2014 13:44:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XmNM4-0000Ge-U3
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:44:05 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	8D/65-02698-42B7B545; Thu, 06 Nov 2014 13:44:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415281440!11829419!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7927 invoked from network); 6 Nov 2014 13:44:01 -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;
	6 Nov 2014 13:44:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190164793"
Received: from localhost (10.80.16.17) by smtprelay.citrix.com (10.13.107.78)
	with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 08:43:59 -0500
Message-ID: <1415281437.2030.1.camel@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 6 Nov 2014 13:43:57 +0000
In-Reply-To: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
References: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not leak diskpath during
 local disk attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 13:00 +0000, Ian Campbell wrote:
> libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a
> strdup of the device path. This is then passed to the callback, e.g.
> parse_bootloader_result but bootloader_cleanup will not free it.
> 
> Since the callback is within the scope of the (e)gc and therefore doesn't need
> to be malloc'd, a gc'd alloc will do. All other assignments to this field use
> the gc.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295

I should really have included the valgrind spew:

==4739== 48 bytes in 2 blocks are definitely lost in loss record 30 of 41
==4739==    at 0x4026B2D: malloc (vg_replace_malloc.c:299)
==4739==    by 0x41979FF: strdup (strdup.c:43)
==4739==    by 0x4064EC4: libxl__device_disk_local_initiate_attach (libxl.c:3033)
==4739==    by 0x4099256: libxl__bootloader_run (libxl_bootloader.c:387)
==4739==    by 0x4073CCE: initiate_domain_create (libxl_create.c:915)
==4739==    by 0x4073CCE: do_domain_create (libxl_create.c:1513)
==4739==    by 0x4073E75: libxl_domain_create_new (libxl_create.c:1536)
==4739==    by 0x80578DB: create_domain (xl_cmdimpl.c:2518)
==4739==    by 0x805B4B2: main_create (xl_cmdimpl.c:4652)
==4739==    by 0x804EAB2: main (xl.c:378)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 14:00:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 14:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmNbL-0000i7-CB; Thu, 06 Nov 2014 13:59: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 1XmNbJ-0000i2-RH
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:59:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2D/69-24532-5DE7B545; Thu, 06 Nov 2014 13:59:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415282385!11966052!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1299 invoked from network); 6 Nov 2014 13:59:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 13:59:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188760835"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 08:59:44 -0500
Received: from cosworth.uk.xensource.com	([10.80.16.52]
	helo=localhost.localdomain ident=ianc)	by ukmail1.uk.xensource.com with
	smtp (Exim 4.69)	(envelope-from <ian.campbell@citrix.com>)	id
	1XmNbD-0007ry-7j; Thu, 06 Nov 2014 13:59:44 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Thu, 06 Nov
	2014 13:59:43 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, <ian.jackson@eu.citrix.com>,
	<wei.liu2@citrix.com>
Date: Thu, 6 Nov 2014 13:59:43 +0000
Message-ID: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] tools: libxl: do not overrun input buffer in
	libxl__parse_mac
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Valgrind reports:
==7971== Invalid read of size 1
==7971==    at 0x40877BE: libxl__parse_mac (libxl_internal.c:288)
==7971==    by 0x405C5F8: libxl__device_nic_from_xs_be (libxl.c:3405)
==7971==    by 0x4065542: libxl__append_nic_list_of_type (libxl.c:3484)
==7971==    by 0x4065542: libxl_device_nic_list (libxl.c:3504)
==7971==    by 0x406F561: libxl_retrieve_domain_configuration (libxl.c:6661)
==7971==    by 0x805671C: reload_domain_config (xl_cmdimpl.c:2037)
==7971==    by 0x8057F30: handle_domain_death (xl_cmdimpl.c:2116)
==7971==    by 0x8057F30: create_domain (xl_cmdimpl.c:2580)
==7971==    by 0x805B4B2: main_create (xl_cmdimpl.c:4652)
==7971==    by 0x804EAB2: main (xl.c:378)

This is because on the final iteration the tok += 3 skips over the terminating
NUL to the next byte, and then *tok reads it. Fix this by using endptr as the
iterator.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 02a71cb..00c3b1e 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -284,10 +284,12 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac)
     char *endptr;
     int i;
 
-    for (i = 0, tok = s; *tok && (i < 6); ++i, tok += 3) {
+    for (i = 0, tok = s; *tok && (i < 6); ++i, tok = endptr) {
         mac[i] = strtol(tok, &endptr, 16);
         if (endptr != (tok + 2) || (*endptr != '\0' && *endptr != ':') )
             return ERROR_INVAL;
+        if (*endptr == ':')
+            endptr++;
     }
     if ( i != 6 )
         return ERROR_INVAL;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 14:00:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 14:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmNbL-0000i7-CB; Thu, 06 Nov 2014 13:59: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 1XmNbJ-0000i2-RH
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 13:59:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2D/69-24532-5DE7B545; Thu, 06 Nov 2014 13:59:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415282385!11966052!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1299 invoked from network); 6 Nov 2014 13:59:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 13:59:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188760835"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 08:59:44 -0500
Received: from cosworth.uk.xensource.com	([10.80.16.52]
	helo=localhost.localdomain ident=ianc)	by ukmail1.uk.xensource.com with
	smtp (Exim 4.69)	(envelope-from <ian.campbell@citrix.com>)	id
	1XmNbD-0007ry-7j; Thu, 06 Nov 2014 13:59:44 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Thu, 06 Nov
	2014 13:59:43 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, <ian.jackson@eu.citrix.com>,
	<wei.liu2@citrix.com>
Date: Thu, 6 Nov 2014 13:59:43 +0000
Message-ID: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] tools: libxl: do not overrun input buffer in
	libxl__parse_mac
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Valgrind reports:
==7971== Invalid read of size 1
==7971==    at 0x40877BE: libxl__parse_mac (libxl_internal.c:288)
==7971==    by 0x405C5F8: libxl__device_nic_from_xs_be (libxl.c:3405)
==7971==    by 0x4065542: libxl__append_nic_list_of_type (libxl.c:3484)
==7971==    by 0x4065542: libxl_device_nic_list (libxl.c:3504)
==7971==    by 0x406F561: libxl_retrieve_domain_configuration (libxl.c:6661)
==7971==    by 0x805671C: reload_domain_config (xl_cmdimpl.c:2037)
==7971==    by 0x8057F30: handle_domain_death (xl_cmdimpl.c:2116)
==7971==    by 0x8057F30: create_domain (xl_cmdimpl.c:2580)
==7971==    by 0x805B4B2: main_create (xl_cmdimpl.c:4652)
==7971==    by 0x804EAB2: main (xl.c:378)

This is because on the final iteration the tok += 3 skips over the terminating
NUL to the next byte, and then *tok reads it. Fix this by using endptr as the
iterator.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 02a71cb..00c3b1e 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -284,10 +284,12 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac)
     char *endptr;
     int i;
 
-    for (i = 0, tok = s; *tok && (i < 6); ++i, tok += 3) {
+    for (i = 0, tok = s; *tok && (i < 6); ++i, tok = endptr) {
         mac[i] = strtol(tok, &endptr, 16);
         if (endptr != (tok + 2) || (*endptr != '\0' && *endptr != ':') )
             return ERROR_INVAL;
+        if (*endptr == ':')
+            endptr++;
     }
     if ( i != 6 )
         return ERROR_INVAL;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 14:41:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 14:41:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOFl-0001p0-FN; Thu, 06 Nov 2014 14:41:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XmOFj-0001ov-Ts
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 14:41:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	24/B0-09842-F988B545; Thu, 06 Nov 2014 14:41:35 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415284893!11626822!1
X-Originating-IP: [199.249.25.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19087 invoked from network); 6 Nov 2014 14:41:34 -0000
Received: from omzsmtpe02.verizonbusiness.com (HELO
	omzsmtpe02.verizonbusiness.com) (199.249.25.209)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 14:41:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1415284894; x=1446820894;
	h=from:to:cc:subject:date:message-id:references:
	in-reply-to:content-id:content-transfer-encoding: mime-version;
	bh=Kq5kzQZXiXNFYqkcPv1p5uU7ENCWvB0VsDYX0WzHMgo=;
	b=CWTQO5O/vGwv0C0c5CilNIOd4yRiYxfgmsihPnSnzgaqAgemEBLQmDEe
	WtvvdEkU9nHJQkKBbKveMrbRN3SHDpqiWcnc2Ay4EVv4D4zUtoY7k0McY
	d1c/FKZyfaw6Y2cTbU5uz5pXcmki9gCnKbOxgQm+dpVH2y0qEMAqf+KQG M=;
X-IronPort-Anti-Spam-Filtered: false
Received: from omzsmtpi03.vzbi.com ([165.122.46.173])
	by omzsmtpe02.verizonbusiness.com with ESMTP; 06 Nov 2014 14:41:32 +0000
From: "Slutz, Donald Christopher" <dslutz@verizon.com>
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="330504930"
Received: from unknown (HELO MIA20725CAS894.apps.tmrk.corp) ([162.47.1.61])
	by omzsmtpi03.vzbi.com with ESMTP; 06 Nov 2014 14:41:29 +0000
Received: from MIA20725MBX891B.apps.tmrk.corp ([fe80::b5d9:30f:fe26:9a96]) by
	MIA20725CAS894.apps.tmrk.corp ([::1]) with mapi id 14.02.0318.001;
	Thu, 6 Nov 2014 09:40:36 -0500
To: Ian Campbell <ian.campbell@citrix.com>
Thread-Topic: [Xen-devel] [PATCH] tools: libxl: do not overrun input buffer
	in libxl__parse_mac
Thread-Index: AQHP+c+Y1zSYnUOItkC838yfz5px4g==
Date: Thu, 6 Nov 2014 14:40:22 +0000
Message-ID: <A3CD31A5D207064088A18AC2AF7B5DC6C2535385@MIA20725MBX891B.apps.tmrk.corp>
References: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625
	Thunderbird/17.0.7
x-originating-ip: [10.1.3.235]
Content-ID: <22833E6759711D4AB02DE5D628F12DF4@tmrk.corp>
MIME-Version: 1.0
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not overrun input buffer
 in libxl__parse_mac
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/06/14 08:59, Ian Campbell wrote:
> Valgrind reports:
> ==7971== Invalid read of size 1
> ==7971==    at 0x40877BE: libxl__parse_mac (libxl_internal.c:288)
> ==7971==    by 0x405C5F8: libxl__device_nic_from_xs_be (libxl.c:3405)
> ==7971==    by 0x4065542: libxl__append_nic_list_of_type (libxl.c:3484)
> ==7971==    by 0x4065542: libxl_device_nic_list (libxl.c:3504)
> ==7971==    by 0x406F561: libxl_retrieve_domain_configuration (libxl.c:6661)
> ==7971==    by 0x805671C: reload_domain_config (xl_cmdimpl.c:2037)
> ==7971==    by 0x8057F30: handle_domain_death (xl_cmdimpl.c:2116)
> ==7971==    by 0x8057F30: create_domain (xl_cmdimpl.c:2580)
> ==7971==    by 0x805B4B2: main_create (xl_cmdimpl.c:4652)
> ==7971==    by 0x804EAB2: main (xl.c:378)
>
> This is because on the final iteration the tok += 3 skips over the terminating
> NUL to the next byte, and then *tok reads it. Fix this by using endptr as the
> iterator.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>   tools/libxl/libxl_internal.c |    4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index 02a71cb..00c3b1e 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -284,10 +284,12 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac)
>       char *endptr;
>       int i;
>   
> -    for (i = 0, tok = s; *tok && (i < 6); ++i, tok += 3) {
> +    for (i = 0, tok = s; *tok && (i < 6); ++i, tok = endptr) {
>           mac[i] = strtol(tok, &endptr, 16);
>           if (endptr != (tok + 2) || (*endptr != '\0' && *endptr != ':') )
>               return ERROR_INVAL;
> +        if (*endptr == ':')
> +            endptr++;
>       }
>       if ( i != 6 )
>           return ERROR_INVAL;
Looks good to me.

Reviewed-by: Don Slutz <dslutz@verizon.com>

    -Don Slutz
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 14:41:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 14:41:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOFl-0001p0-FN; Thu, 06 Nov 2014 14:41:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XmOFj-0001ov-Ts
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 14:41:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	24/B0-09842-F988B545; Thu, 06 Nov 2014 14:41:35 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415284893!11626822!1
X-Originating-IP: [199.249.25.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19087 invoked from network); 6 Nov 2014 14:41:34 -0000
Received: from omzsmtpe02.verizonbusiness.com (HELO
	omzsmtpe02.verizonbusiness.com) (199.249.25.209)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 14:41:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1415284894; x=1446820894;
	h=from:to:cc:subject:date:message-id:references:
	in-reply-to:content-id:content-transfer-encoding: mime-version;
	bh=Kq5kzQZXiXNFYqkcPv1p5uU7ENCWvB0VsDYX0WzHMgo=;
	b=CWTQO5O/vGwv0C0c5CilNIOd4yRiYxfgmsihPnSnzgaqAgemEBLQmDEe
	WtvvdEkU9nHJQkKBbKveMrbRN3SHDpqiWcnc2Ay4EVv4D4zUtoY7k0McY
	d1c/FKZyfaw6Y2cTbU5uz5pXcmki9gCnKbOxgQm+dpVH2y0qEMAqf+KQG M=;
X-IronPort-Anti-Spam-Filtered: false
Received: from omzsmtpi03.vzbi.com ([165.122.46.173])
	by omzsmtpe02.verizonbusiness.com with ESMTP; 06 Nov 2014 14:41:32 +0000
From: "Slutz, Donald Christopher" <dslutz@verizon.com>
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="330504930"
Received: from unknown (HELO MIA20725CAS894.apps.tmrk.corp) ([162.47.1.61])
	by omzsmtpi03.vzbi.com with ESMTP; 06 Nov 2014 14:41:29 +0000
Received: from MIA20725MBX891B.apps.tmrk.corp ([fe80::b5d9:30f:fe26:9a96]) by
	MIA20725CAS894.apps.tmrk.corp ([::1]) with mapi id 14.02.0318.001;
	Thu, 6 Nov 2014 09:40:36 -0500
To: Ian Campbell <ian.campbell@citrix.com>
Thread-Topic: [Xen-devel] [PATCH] tools: libxl: do not overrun input buffer
	in libxl__parse_mac
Thread-Index: AQHP+c+Y1zSYnUOItkC838yfz5px4g==
Date: Thu, 6 Nov 2014 14:40:22 +0000
Message-ID: <A3CD31A5D207064088A18AC2AF7B5DC6C2535385@MIA20725MBX891B.apps.tmrk.corp>
References: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625
	Thunderbird/17.0.7
x-originating-ip: [10.1.3.235]
Content-ID: <22833E6759711D4AB02DE5D628F12DF4@tmrk.corp>
MIME-Version: 1.0
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not overrun input buffer
 in libxl__parse_mac
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/06/14 08:59, Ian Campbell wrote:
> Valgrind reports:
> ==7971== Invalid read of size 1
> ==7971==    at 0x40877BE: libxl__parse_mac (libxl_internal.c:288)
> ==7971==    by 0x405C5F8: libxl__device_nic_from_xs_be (libxl.c:3405)
> ==7971==    by 0x4065542: libxl__append_nic_list_of_type (libxl.c:3484)
> ==7971==    by 0x4065542: libxl_device_nic_list (libxl.c:3504)
> ==7971==    by 0x406F561: libxl_retrieve_domain_configuration (libxl.c:6661)
> ==7971==    by 0x805671C: reload_domain_config (xl_cmdimpl.c:2037)
> ==7971==    by 0x8057F30: handle_domain_death (xl_cmdimpl.c:2116)
> ==7971==    by 0x8057F30: create_domain (xl_cmdimpl.c:2580)
> ==7971==    by 0x805B4B2: main_create (xl_cmdimpl.c:4652)
> ==7971==    by 0x804EAB2: main (xl.c:378)
>
> This is because on the final iteration the tok += 3 skips over the terminating
> NUL to the next byte, and then *tok reads it. Fix this by using endptr as the
> iterator.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>   tools/libxl/libxl_internal.c |    4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index 02a71cb..00c3b1e 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -284,10 +284,12 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac)
>       char *endptr;
>       int i;
>   
> -    for (i = 0, tok = s; *tok && (i < 6); ++i, tok += 3) {
> +    for (i = 0, tok = s; *tok && (i < 6); ++i, tok = endptr) {
>           mac[i] = strtol(tok, &endptr, 16);
>           if (endptr != (tok + 2) || (*endptr != '\0' && *endptr != ':') )
>               return ERROR_INVAL;
> +        if (*endptr == ':')
> +            endptr++;
>       }
>       if ( i != 6 )
>           return ERROR_INVAL;
Looks good to me.

Reviewed-by: Don Slutz <dslutz@verizon.com>

    -Don Slutz
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 14:50:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 14:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOO2-0002B6-MP; Thu, 06 Nov 2014 14:50:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmOO1-0002B1-Pv
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 14:50:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AB/C1-09842-1AA8B545; Thu, 06 Nov 2014 14:50:09 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415285407!12000523!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28408 invoked from network); 6 Nov 2014 14:50:08 -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;
	6 Nov 2014 14:50:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190197725"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 09:50:06 -0500
Received: from etemp.uk.xensource.com ([10.80.228.66]
	helo=etemp.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <paul.durrant@citrix.com>)	id 1XmONx-0000CE-S3;
	Thu, 06 Nov 2014 14:50:05 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 6 Nov 2014 14:50:04 +0000
Message-ID: <1415285404-11008-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Paul Durrant <paul.durrant@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

HVM guests have always been confined to using the domain callback
via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
which is an IOAPIC vector and is only used if the event channel is
bound to vcpu 0.
This patch adds a new HVM op allowing a guest to specify a local
APIC vector to use as an upcall notification for a specific vcpu.
This therefore allows a guest which sets a vector for a vcpu
other than 0 to then bind event channels to that vcpu.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c          |   35 +++++++++++++++++++++++++++++++++++
 xen/arch/x86/hvm/irq.c          |    9 +++++++++
 xen/include/asm-x86/hvm/vcpu.h  |    1 +
 xen/include/public/hvm/hvm_op.h |   16 ++++++++++++++++
 4 files changed, 61 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 78f519d..684e666 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5458,6 +5458,36 @@ static int hvmop_destroy_ioreq_server(
     return rc;
 }
 
+static int hvmop_set_evtchn_upcall_vector(
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t) uop)
+{
+    xen_hvm_set_evtchn_upcall_vector_t op;
+    struct domain *d;
+    struct vcpu *v;
+    int rc;
+
+    if ( copy_from_guest(&op, uop, 1) )
+        return -EFAULT;
+
+    d = rcu_lock_current_domain();
+
+    rc = -EINVAL;
+    if ( !is_hvm_domain(d) )
+        goto out;
+
+    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
+        goto out;
+
+    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
+
+    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
+    rc = 0;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 #define HVMOP_op_mask 0xff
 
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
@@ -5499,6 +5529,11 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
             guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
         break;
     
+    case HVMOP_set_evtchn_upcall_vector:
+        rc = hvmop_set_evtchn_upcall_vector(
+            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
+        break;
+    
     case HVMOP_set_param:
     case HVMOP_get_param:
     {
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 35f4f94..3e4c0b4 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
     spin_unlock(&d->arch.hvm_domain.irq_lock);
 }
 
+static void hvm_set_upcall_irq(struct vcpu *v)
+{
+    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
+
+    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
+}
+
 static void hvm_set_callback_irq_level(struct vcpu *v)
 {
     struct domain *d = v->domain;
@@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
 
     if ( is_hvm_pv_evtchn_vcpu(v) )
         vcpu_kick(v);
+    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
+        hvm_set_upcall_irq(v);
     else if ( v->vcpu_id == 0 )
         hvm_set_callback_irq_level(v);
 }
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..edd4523 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -160,6 +160,7 @@ struct hvm_vcpu {
     } u;
 
     struct tasklet      assert_evtchn_irq_tasklet;
+    u8                  evtchn_upcall_vector;
 
     struct nestedvcpu   nvcpu;
 
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index eeb0a60..33ccf45 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -369,6 +369,22 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
 
 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
 
+/*
+ * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used for event
+ *                                 channel upcalls on the specified <vcpu>. If set,
+ *                                 this vector will be used in preference to the
+ *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
+ *                                 and hence allows HVM guests to bind event
+ *                                 event channels to a vcpu other than 0.
+ */
+#define HVMOP_set_evtchn_upcall_vector 23
+struct xen_hvm_set_evtchn_upcall_vector {
+    uint32_t vcpu;
+    uint8_t vector;
+};
+typedef struct xen_hvm_set_evtchn_upcall_vector xen_hvm_set_evtchn_upcall_vector_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 14:50:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 14:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOO2-0002B6-MP; Thu, 06 Nov 2014 14:50:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmOO1-0002B1-Pv
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 14:50:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AB/C1-09842-1AA8B545; Thu, 06 Nov 2014 14:50:09 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415285407!12000523!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28408 invoked from network); 6 Nov 2014 14:50:08 -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;
	6 Nov 2014 14:50:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190197725"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 09:50:06 -0500
Received: from etemp.uk.xensource.com ([10.80.228.66]
	helo=etemp.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <paul.durrant@citrix.com>)	id 1XmONx-0000CE-S3;
	Thu, 06 Nov 2014 14:50:05 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 6 Nov 2014 14:50:04 +0000
Message-ID: <1415285404-11008-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Paul Durrant <paul.durrant@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

HVM guests have always been confined to using the domain callback
via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
which is an IOAPIC vector and is only used if the event channel is
bound to vcpu 0.
This patch adds a new HVM op allowing a guest to specify a local
APIC vector to use as an upcall notification for a specific vcpu.
This therefore allows a guest which sets a vector for a vcpu
other than 0 to then bind event channels to that vcpu.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c          |   35 +++++++++++++++++++++++++++++++++++
 xen/arch/x86/hvm/irq.c          |    9 +++++++++
 xen/include/asm-x86/hvm/vcpu.h  |    1 +
 xen/include/public/hvm/hvm_op.h |   16 ++++++++++++++++
 4 files changed, 61 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 78f519d..684e666 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5458,6 +5458,36 @@ static int hvmop_destroy_ioreq_server(
     return rc;
 }
 
+static int hvmop_set_evtchn_upcall_vector(
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t) uop)
+{
+    xen_hvm_set_evtchn_upcall_vector_t op;
+    struct domain *d;
+    struct vcpu *v;
+    int rc;
+
+    if ( copy_from_guest(&op, uop, 1) )
+        return -EFAULT;
+
+    d = rcu_lock_current_domain();
+
+    rc = -EINVAL;
+    if ( !is_hvm_domain(d) )
+        goto out;
+
+    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
+        goto out;
+
+    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
+
+    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
+    rc = 0;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 #define HVMOP_op_mask 0xff
 
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
@@ -5499,6 +5529,11 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
             guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
         break;
     
+    case HVMOP_set_evtchn_upcall_vector:
+        rc = hvmop_set_evtchn_upcall_vector(
+            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
+        break;
+    
     case HVMOP_set_param:
     case HVMOP_get_param:
     {
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 35f4f94..3e4c0b4 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
     spin_unlock(&d->arch.hvm_domain.irq_lock);
 }
 
+static void hvm_set_upcall_irq(struct vcpu *v)
+{
+    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
+
+    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
+}
+
 static void hvm_set_callback_irq_level(struct vcpu *v)
 {
     struct domain *d = v->domain;
@@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
 
     if ( is_hvm_pv_evtchn_vcpu(v) )
         vcpu_kick(v);
+    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
+        hvm_set_upcall_irq(v);
     else if ( v->vcpu_id == 0 )
         hvm_set_callback_irq_level(v);
 }
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..edd4523 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -160,6 +160,7 @@ struct hvm_vcpu {
     } u;
 
     struct tasklet      assert_evtchn_irq_tasklet;
+    u8                  evtchn_upcall_vector;
 
     struct nestedvcpu   nvcpu;
 
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index eeb0a60..33ccf45 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -369,6 +369,22 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
 
 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
 
+/*
+ * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used for event
+ *                                 channel upcalls on the specified <vcpu>. If set,
+ *                                 this vector will be used in preference to the
+ *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
+ *                                 and hence allows HVM guests to bind event
+ *                                 event channels to a vcpu other than 0.
+ */
+#define HVMOP_set_evtchn_upcall_vector 23
+struct xen_hvm_set_evtchn_upcall_vector {
+    uint32_t vcpu;
+    uint8_t vector;
+};
+typedef struct xen_hvm_set_evtchn_upcall_vector xen_hvm_set_evtchn_upcall_vector_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 14:56:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 14:56:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOTu-0002Ul-F8; Thu, 06 Nov 2014 14:56:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XmOTs-0002Ug-VH
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 14:56:13 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	E4/B5-02559-C0C8B545; Thu, 06 Nov 2014 14:56:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415285770!11857531!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15442 invoked from network); 6 Nov 2014 14:56:11 -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;
	6 Nov 2014 14:56:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190199908"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 09:55:39 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XmOTL-0000H8-67;
	Thu, 06 Nov 2014 14:55:39 +0000
Date: Thu, 6 Nov 2014 14:55:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141106145539.GB2580@zion.uk.xensource.com>
References: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not overrun input buffer
 in libxl__parse_mac
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 01:59:43PM +0000, Ian Campbell wrote:
> Valgrind reports:
> ==7971== Invalid read of size 1
> ==7971==    at 0x40877BE: libxl__parse_mac (libxl_internal.c:288)
> ==7971==    by 0x405C5F8: libxl__device_nic_from_xs_be (libxl.c:3405)
> ==7971==    by 0x4065542: libxl__append_nic_list_of_type (libxl.c:3484)
> ==7971==    by 0x4065542: libxl_device_nic_list (libxl.c:3504)
> ==7971==    by 0x406F561: libxl_retrieve_domain_configuration (libxl.c:6661)
> ==7971==    by 0x805671C: reload_domain_config (xl_cmdimpl.c:2037)
> ==7971==    by 0x8057F30: handle_domain_death (xl_cmdimpl.c:2116)
> ==7971==    by 0x8057F30: create_domain (xl_cmdimpl.c:2580)
> ==7971==    by 0x805B4B2: main_create (xl_cmdimpl.c:4652)
> ==7971==    by 0x804EAB2: main (xl.c:378)
> 
> This is because on the final iteration the tok += 3 skips over the terminating
> NUL to the next byte, and then *tok reads it. Fix this by using endptr as the
> iterator.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>

This is a candidate for backporting.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 14:56:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 14:56:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOTu-0002Ul-F8; Thu, 06 Nov 2014 14:56:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XmOTs-0002Ug-VH
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 14:56:13 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	E4/B5-02559-C0C8B545; Thu, 06 Nov 2014 14:56:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415285770!11857531!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15442 invoked from network); 6 Nov 2014 14:56:11 -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;
	6 Nov 2014 14:56:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190199908"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 09:55:39 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XmOTL-0000H8-67;
	Thu, 06 Nov 2014 14:55:39 +0000
Date: Thu, 6 Nov 2014 14:55:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141106145539.GB2580@zion.uk.xensource.com>
References: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not overrun input buffer
 in libxl__parse_mac
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 01:59:43PM +0000, Ian Campbell wrote:
> Valgrind reports:
> ==7971== Invalid read of size 1
> ==7971==    at 0x40877BE: libxl__parse_mac (libxl_internal.c:288)
> ==7971==    by 0x405C5F8: libxl__device_nic_from_xs_be (libxl.c:3405)
> ==7971==    by 0x4065542: libxl__append_nic_list_of_type (libxl.c:3484)
> ==7971==    by 0x4065542: libxl_device_nic_list (libxl.c:3504)
> ==7971==    by 0x406F561: libxl_retrieve_domain_configuration (libxl.c:6661)
> ==7971==    by 0x805671C: reload_domain_config (xl_cmdimpl.c:2037)
> ==7971==    by 0x8057F30: handle_domain_death (xl_cmdimpl.c:2116)
> ==7971==    by 0x8057F30: create_domain (xl_cmdimpl.c:2580)
> ==7971==    by 0x805B4B2: main_create (xl_cmdimpl.c:4652)
> ==7971==    by 0x804EAB2: main (xl.c:378)
> 
> This is because on the final iteration the tok += 3 skips over the terminating
> NUL to the next byte, and then *tok reads it. Fix this by using endptr as the
> iterator.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>

This is a candidate for backporting.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:03:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:03:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOac-0002qR-9s; Thu, 06 Nov 2014 15:03:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmOaa-0002qM-9w
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:03:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	41/BD-09842-BAD8B545; Thu, 06 Nov 2014 15:03:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415286185!11949528!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19629 invoked from network); 6 Nov 2014 15:03:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:03:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190202602"
Message-ID: <545B8D5A.2090404@citrix.com>
Date: Thu, 6 Nov 2014 15:01:46 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>, <xen-devel@lists.xen.org>
References: <1415285404-11008-1-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1415285404-11008-1-git-send-email-paul.durrant@citrix.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 14:50, Paul Durrant wrote:
> HVM guests have always been confined to using the domain callback
> via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
> which is an IOAPIC vector and is only used if the event channel is
> bound to vcpu 0.
> This patch adds a new HVM op allowing a guest to specify a local
> APIC vector to use as an upcall notification for a specific vcpu.
> This therefore allows a guest which sets a vector for a vcpu
> other than 0 to then bind event channels to that vcpu.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>

Substantially more minimal changes than I would have guessed!

> ---
>  xen/arch/x86/hvm/hvm.c          |   35 +++++++++++++++++++++++++++++++++++
>  xen/arch/x86/hvm/irq.c          |    9 +++++++++
>  xen/include/asm-x86/hvm/vcpu.h  |    1 +
>  xen/include/public/hvm/hvm_op.h |   16 ++++++++++++++++
>  4 files changed, 61 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 78f519d..684e666 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5458,6 +5458,36 @@ static int hvmop_destroy_ioreq_server(
>      return rc;
>  }
>  
> +static int hvmop_set_evtchn_upcall_vector(
> +    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t) uop)
> +{
> +    xen_hvm_set_evtchn_upcall_vector_t op;
> +    struct domain *d;
> +    struct vcpu *v;
> +    int rc;
> +
> +    if ( copy_from_guest(&op, uop, 1) )
> +        return -EFAULT;
> +
> +    d = rcu_lock_current_domain();
> +
> +    rc = -EINVAL;
> +    if ( !is_hvm_domain(d) )
> +        goto out;
> +

ENOENT, to help differentiate the various failures.

> +    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
> +        goto out;
> +

Need to verify that op.vector > 0xf.  The first 16 vectors are not valid
for delivery via the LAPIC.

> +    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
> +
> +    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
> +    rc = 0;
> +
> + out:
> +    rcu_unlock_domain(d);
> +    return rc;
> +}
> +
>  #define HVMOP_op_mask 0xff
>  
>  long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
> @@ -5499,6 +5529,11 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>              guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
>          break;
>      
> +    case HVMOP_set_evtchn_upcall_vector:
> +        rc = hvmop_set_evtchn_upcall_vector(
> +            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
> +        break;
> +    
>      case HVMOP_set_param:
>      case HVMOP_get_param:
>      {
> diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> index 35f4f94..3e4c0b4 100644
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
>      spin_unlock(&d->arch.hvm_domain.irq_lock);
>  }
>  
> +static void hvm_set_upcall_irq(struct vcpu *v)
> +{
> +    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
> +
> +    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
> +}
> +
>  static void hvm_set_callback_irq_level(struct vcpu *v)
>  {
>      struct domain *d = v->domain;
> @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
>  
>      if ( is_hvm_pv_evtchn_vcpu(v) )
>          vcpu_kick(v);
> +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> +        hvm_set_upcall_irq(v);
>      else if ( v->vcpu_id == 0 )
>          hvm_set_callback_irq_level(v);
>  }
> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
> index 01e0665..edd4523 100644
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -160,6 +160,7 @@ struct hvm_vcpu {
>      } u;
>  
>      struct tasklet      assert_evtchn_irq_tasklet;
> +    u8                  evtchn_upcall_vector;
>  
>      struct nestedvcpu   nvcpu;
>  
> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
> index eeb0a60..33ccf45 100644
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -369,6 +369,22 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
>  
>  #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */

This new hvmop looks like it should live in an x86 specific section.

>  
> +/*
> + * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used for event
> + *                                 channel upcalls on the specified <vcpu>. If set,
> + *                                 this vector will be used in preference to the
> + *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
> + *                                 and hence allows HVM guests to bind event
> + *                                 event channels to a vcpu other than 0.
> + */
> +#define HVMOP_set_evtchn_upcall_vector 23
> +struct xen_hvm_set_evtchn_upcall_vector {
> +    uint32_t vcpu;
> +    uint8_t vector;

Is it plausible that a device model might want to call this hypercall on
a domain which it controls?  I don't believe so, but the question is
worth considering with a view to adding a domid parameter before the API
is set in stone.

~Andrew

> +};
> +typedef struct xen_hvm_set_evtchn_upcall_vector xen_hvm_set_evtchn_upcall_vector_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
> +
>  #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:03:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:03:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOac-0002qR-9s; Thu, 06 Nov 2014 15:03:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmOaa-0002qM-9w
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:03:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	41/BD-09842-BAD8B545; Thu, 06 Nov 2014 15:03:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415286185!11949528!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19629 invoked from network); 6 Nov 2014 15:03:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:03:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190202602"
Message-ID: <545B8D5A.2090404@citrix.com>
Date: Thu, 6 Nov 2014 15:01:46 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>, <xen-devel@lists.xen.org>
References: <1415285404-11008-1-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1415285404-11008-1-git-send-email-paul.durrant@citrix.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 14:50, Paul Durrant wrote:
> HVM guests have always been confined to using the domain callback
> via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
> which is an IOAPIC vector and is only used if the event channel is
> bound to vcpu 0.
> This patch adds a new HVM op allowing a guest to specify a local
> APIC vector to use as an upcall notification for a specific vcpu.
> This therefore allows a guest which sets a vector for a vcpu
> other than 0 to then bind event channels to that vcpu.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>

Substantially more minimal changes than I would have guessed!

> ---
>  xen/arch/x86/hvm/hvm.c          |   35 +++++++++++++++++++++++++++++++++++
>  xen/arch/x86/hvm/irq.c          |    9 +++++++++
>  xen/include/asm-x86/hvm/vcpu.h  |    1 +
>  xen/include/public/hvm/hvm_op.h |   16 ++++++++++++++++
>  4 files changed, 61 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 78f519d..684e666 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5458,6 +5458,36 @@ static int hvmop_destroy_ioreq_server(
>      return rc;
>  }
>  
> +static int hvmop_set_evtchn_upcall_vector(
> +    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t) uop)
> +{
> +    xen_hvm_set_evtchn_upcall_vector_t op;
> +    struct domain *d;
> +    struct vcpu *v;
> +    int rc;
> +
> +    if ( copy_from_guest(&op, uop, 1) )
> +        return -EFAULT;
> +
> +    d = rcu_lock_current_domain();
> +
> +    rc = -EINVAL;
> +    if ( !is_hvm_domain(d) )
> +        goto out;
> +

ENOENT, to help differentiate the various failures.

> +    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
> +        goto out;
> +

Need to verify that op.vector > 0xf.  The first 16 vectors are not valid
for delivery via the LAPIC.

> +    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
> +
> +    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
> +    rc = 0;
> +
> + out:
> +    rcu_unlock_domain(d);
> +    return rc;
> +}
> +
>  #define HVMOP_op_mask 0xff
>  
>  long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
> @@ -5499,6 +5529,11 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>              guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
>          break;
>      
> +    case HVMOP_set_evtchn_upcall_vector:
> +        rc = hvmop_set_evtchn_upcall_vector(
> +            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
> +        break;
> +    
>      case HVMOP_set_param:
>      case HVMOP_get_param:
>      {
> diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> index 35f4f94..3e4c0b4 100644
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
>      spin_unlock(&d->arch.hvm_domain.irq_lock);
>  }
>  
> +static void hvm_set_upcall_irq(struct vcpu *v)
> +{
> +    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
> +
> +    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
> +}
> +
>  static void hvm_set_callback_irq_level(struct vcpu *v)
>  {
>      struct domain *d = v->domain;
> @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
>  
>      if ( is_hvm_pv_evtchn_vcpu(v) )
>          vcpu_kick(v);
> +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> +        hvm_set_upcall_irq(v);
>      else if ( v->vcpu_id == 0 )
>          hvm_set_callback_irq_level(v);
>  }
> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
> index 01e0665..edd4523 100644
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -160,6 +160,7 @@ struct hvm_vcpu {
>      } u;
>  
>      struct tasklet      assert_evtchn_irq_tasklet;
> +    u8                  evtchn_upcall_vector;
>  
>      struct nestedvcpu   nvcpu;
>  
> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
> index eeb0a60..33ccf45 100644
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -369,6 +369,22 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
>  
>  #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */

This new hvmop looks like it should live in an x86 specific section.

>  
> +/*
> + * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used for event
> + *                                 channel upcalls on the specified <vcpu>. If set,
> + *                                 this vector will be used in preference to the
> + *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
> + *                                 and hence allows HVM guests to bind event
> + *                                 event channels to a vcpu other than 0.
> + */
> +#define HVMOP_set_evtchn_upcall_vector 23
> +struct xen_hvm_set_evtchn_upcall_vector {
> +    uint32_t vcpu;
> +    uint8_t vector;

Is it plausible that a device model might want to call this hypercall on
a domain which it controls?  I don't believe so, but the question is
worth considering with a view to adding a domid parameter before the API
is set in stone.

~Andrew

> +};
> +typedef struct xen_hvm_set_evtchn_upcall_vector xen_hvm_set_evtchn_upcall_vector_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
> +
>  #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:06:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:06:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOdM-0002wh-SJ; Thu, 06 Nov 2014 15:06: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 1XmOdK-0002wU-LD
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 15:05:58 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	1A/83-01660-55E8B545; Thu, 06 Nov 2014 15:05:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415286353!10950257!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23450 invoked from network); 6 Nov 2014 15:05:53 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:05:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 06 Nov 2014 15:05:52 +0000
Message-Id: <545B9C5F020000780004561B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 06 Nov 2014 15:05:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen-pciback: drop SR-IOV VFs when PF driver
	unloads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When a PF driver unloads, it may find it necessary to leave the VFs
around simply because of pciback having marked them as assigned to a
guest. Utilize a suitable notification to let go of the VFs, thus
allowing the PF to go back into the state it was before its driver
loaded (which in particular allows the driver to be loaded again with
it being able to create the VFs anew, but which also allows to then
pass through the PF instead of the VFs).

Don't do this however for any VFs currently in active use by a guest.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
 drivers/xen/xen-pciback/pci_stub.c |   46 +++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

--- 3.18-rc3/drivers/xen/xen-pciback/pci_stub.c
+++ 3.18-rc3-pciback-release-VFs/drivers/xen/xen-pciback/pci_stub.c
@@ -1502,6 +1502,45 @@ parse_error:
 fs_initcall(pcistub_init);
 #endif
 
+#ifdef CONFIG_PCI_IOV
+static int pci_stub_notifier(struct notifier_block *nb,
+			     unsigned long action, void *data)
+{
+	struct device *dev = data;
+	const struct pci_dev *pdev = to_pci_dev(dev);
+
+	switch (action) {
+	case BUS_NOTIFY_UNBIND_DRIVER:
+		if (!pdev->is_physfn)
+			break;
+		for (;;) {
+			struct pcistub_device *psdev;
+			unsigned long flags;
+			bool found = false;
+
+			spin_lock_irqsave(&pcistub_devices_lock, flags);
+			list_for_each_entry(psdev, &pcistub_devices, dev_list)
+				if (!psdev->pdev && psdev->dev != pdev
+				    && pci_physfn(psdev->dev) == pdev) {
+					found = true;
+					break;
+				}
+			spin_unlock_irqrestore(&pcistub_devices_lock, flags);
+			if (!found)
+				break;
+			device_release_driver(&psdev->dev->dev);
+		}
+		break;
+	}
+
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block pci_stub_nb = {
+	.notifier_call = pci_stub_notifier,
+};
+#endif
+
 static int __init xen_pcibk_init(void)
 {
 	int err;
@@ -1523,12 +1562,19 @@ static int __init xen_pcibk_init(void)
 	err = xen_pcibk_xenbus_register();
 	if (err)
 		pcistub_exit();
+#ifdef CONFIG_PCI_IOV
+	else
+		bus_register_notifier(&pci_bus_type, &pci_stub_nb);
+#endif
 
 	return err;
 }
 
 static void __exit xen_pcibk_cleanup(void)
 {
+#ifdef CONFIG_PCI_IOV
+	bus_unregister_notifier(&pci_bus_type, &pci_stub_nb);
+#endif
 	xen_pcibk_xenbus_unregister();
 	pcistub_exit();
 }




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:06:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:06:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOdM-0002wh-SJ; Thu, 06 Nov 2014 15:06: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 1XmOdK-0002wU-LD
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 15:05:58 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	1A/83-01660-55E8B545; Thu, 06 Nov 2014 15:05:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415286353!10950257!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23450 invoked from network); 6 Nov 2014 15:05:53 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:05:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 06 Nov 2014 15:05:52 +0000
Message-Id: <545B9C5F020000780004561B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 06 Nov 2014 15:05:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen-pciback: drop SR-IOV VFs when PF driver
	unloads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When a PF driver unloads, it may find it necessary to leave the VFs
around simply because of pciback having marked them as assigned to a
guest. Utilize a suitable notification to let go of the VFs, thus
allowing the PF to go back into the state it was before its driver
loaded (which in particular allows the driver to be loaded again with
it being able to create the VFs anew, but which also allows to then
pass through the PF instead of the VFs).

Don't do this however for any VFs currently in active use by a guest.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
 drivers/xen/xen-pciback/pci_stub.c |   46 +++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

--- 3.18-rc3/drivers/xen/xen-pciback/pci_stub.c
+++ 3.18-rc3-pciback-release-VFs/drivers/xen/xen-pciback/pci_stub.c
@@ -1502,6 +1502,45 @@ parse_error:
 fs_initcall(pcistub_init);
 #endif
 
+#ifdef CONFIG_PCI_IOV
+static int pci_stub_notifier(struct notifier_block *nb,
+			     unsigned long action, void *data)
+{
+	struct device *dev = data;
+	const struct pci_dev *pdev = to_pci_dev(dev);
+
+	switch (action) {
+	case BUS_NOTIFY_UNBIND_DRIVER:
+		if (!pdev->is_physfn)
+			break;
+		for (;;) {
+			struct pcistub_device *psdev;
+			unsigned long flags;
+			bool found = false;
+
+			spin_lock_irqsave(&pcistub_devices_lock, flags);
+			list_for_each_entry(psdev, &pcistub_devices, dev_list)
+				if (!psdev->pdev && psdev->dev != pdev
+				    && pci_physfn(psdev->dev) == pdev) {
+					found = true;
+					break;
+				}
+			spin_unlock_irqrestore(&pcistub_devices_lock, flags);
+			if (!found)
+				break;
+			device_release_driver(&psdev->dev->dev);
+		}
+		break;
+	}
+
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block pci_stub_nb = {
+	.notifier_call = pci_stub_notifier,
+};
+#endif
+
 static int __init xen_pcibk_init(void)
 {
 	int err;
@@ -1523,12 +1562,19 @@ static int __init xen_pcibk_init(void)
 	err = xen_pcibk_xenbus_register();
 	if (err)
 		pcistub_exit();
+#ifdef CONFIG_PCI_IOV
+	else
+		bus_register_notifier(&pci_bus_type, &pci_stub_nb);
+#endif
 
 	return err;
 }
 
 static void __exit xen_pcibk_cleanup(void)
 {
+#ifdef CONFIG_PCI_IOV
+	bus_unregister_notifier(&pci_bus_type, &pci_stub_nb);
+#endif
 	xen_pcibk_xenbus_unregister();
 	pcistub_exit();
 }




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:09:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOgv-00036R-GF; Thu, 06 Nov 2014 15:09:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmOgu-00036M-M5
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:09:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	85/DD-09936-43F8B545; Thu, 06 Nov 2014 15:09:40 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415286577!11989170!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23191 invoked from network); 6 Nov 2014 15:09:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:09:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190205537"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:07:12 -0500
Received: from etemp.uk.xensource.com ([10.80.228.66]
	helo=etemp.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <paul.durrant@citrix.com>)	id 1XmOeW-0000T5-10;
	Thu, 06 Nov 2014 15:07:12 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 6 Nov 2014 15:07:10 +0000
Message-ID: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Paul Durrant <paul.durrant@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu 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

To perform certain hypercalls HVM guests need to use Xen's idea of
vcpu id, which may well not match the guest OS idea of CPU id.
This patch adds vcpu id to the HVM cpuid leaf allowing the guest
to build a mapping.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c              |    4 ++++
 xen/include/public/arch-x86/cpuid.h |    5 +++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 78f519d..d9a5706 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t sub_idx,
          * foreign pages) has valid IOMMU entries.
          */
         *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
+
+        /* Indicate presence of vcpu id and set it in ebx */
+        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
+        *ebx = current->vcpu_id;
     }
 }
 
diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
index 6005dfe..8ccb6e1 100644
--- a/xen/include/public/arch-x86/cpuid.h
+++ b/xen/include/public/arch-x86/cpuid.h
@@ -76,13 +76,14 @@
 /*
  * Leaf 5 (0x40000x04)
  * HVM-specific features
+ * EAX: Features
+ * EBX: VCPU ID
  */
-
-/* EAX Features */
 #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized APIC registers */
 #define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized x2APIC accesses */
 /* Memory mapped from other domains has valid IOMMU entries */
 #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
+#define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu is present in EBX */
 
 #define XEN_CPUID_MAX_NUM_LEAVES 4
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:09:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOgv-00036R-GF; Thu, 06 Nov 2014 15:09:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmOgu-00036M-M5
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:09:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	85/DD-09936-43F8B545; Thu, 06 Nov 2014 15:09:40 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415286577!11989170!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23191 invoked from network); 6 Nov 2014 15:09:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:09:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190205537"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:07:12 -0500
Received: from etemp.uk.xensource.com ([10.80.228.66]
	helo=etemp.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <paul.durrant@citrix.com>)	id 1XmOeW-0000T5-10;
	Thu, 06 Nov 2014 15:07:12 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 6 Nov 2014 15:07:10 +0000
Message-ID: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Paul Durrant <paul.durrant@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu 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

To perform certain hypercalls HVM guests need to use Xen's idea of
vcpu id, which may well not match the guest OS idea of CPU id.
This patch adds vcpu id to the HVM cpuid leaf allowing the guest
to build a mapping.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c              |    4 ++++
 xen/include/public/arch-x86/cpuid.h |    5 +++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 78f519d..d9a5706 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t sub_idx,
          * foreign pages) has valid IOMMU entries.
          */
         *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
+
+        /* Indicate presence of vcpu id and set it in ebx */
+        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
+        *ebx = current->vcpu_id;
     }
 }
 
diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
index 6005dfe..8ccb6e1 100644
--- a/xen/include/public/arch-x86/cpuid.h
+++ b/xen/include/public/arch-x86/cpuid.h
@@ -76,13 +76,14 @@
 /*
  * Leaf 5 (0x40000x04)
  * HVM-specific features
+ * EAX: Features
+ * EBX: VCPU ID
  */
-
-/* EAX Features */
 #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized APIC registers */
 #define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized x2APIC accesses */
 /* Memory mapped from other domains has valid IOMMU entries */
 #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
+#define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu is present in EBX */
 
 #define XEN_CPUID_MAX_NUM_LEAVES 4
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:11:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:11:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOiv-0003Bp-4m; Thu, 06 Nov 2014 15:11:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XmOit-0003BX-Gg
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:11:43 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	09/5E-24859-EAF8B545; Thu, 06 Nov 2014 15:11:42 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415286702!8449442!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30102 invoked from network); 6 Nov 2014 15:11:42 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:11:42 -0000
Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XmOiq-0006Rb-UF; Thu, 06 Nov 2014 16:11:40 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.66])
	by justin.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XmOiq-0003ge-II; Thu, 06 Nov 2014 16:11:40 +0100
Message-ID: <545B8FAE.9090608@web2web.at>
Date: Thu, 06 Nov 2014 16:11:42 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>						<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>					<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>				
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>			
	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>		
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>	
	<1415180713.11486.61.camel@citrix.com>
	<545A118B.7040309@web2web.at>
	<1415191140.15317.11.camel@citrix.com>
In-Reply-To: <1415191140.15317.11.camel@citrix.com>
X-Univie-Virus-Scan: scanned by ClamAV on justin.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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

Am 05.11.14 um 13:39 schrieb Ian Campbell:
> On Wed, 2014-11-05 at 13:01 +0100, Atom2 wrote:
>
> Thanks for all that, sadly it's not giving me any clues what is going
> wrong :-/
>
> So unless "-v --leak-check=full" tells me something (which I'm doubtful
> of at this stage) I think we're back to bisecting the changes since
> 4.3.1, sorry.
Things are getting very strange at the moment.
After much work an research I have been able to download the source and 
compile the old version which has worked before (which incidentally was 
not 4.3.1 but rather 4.3.2-r5 - sorry for any confusion that might have 
caused). I initially thought that's good news because there are less 
changes between 4.3.2 and 4.3.3 but after re-ompiling 4.3.2-r5 I am now 
experiencing the same segfault as with 4.3.3.

So my next step was trying to figure out what else had changed since the 
problems started on 26.10.14 by working through log files and those are 
the relevant events that had happened. The sequence of events was as 
follows:

11.10.14 04:13:	Last system reboot with working version (xen 4.3.2-r5)
		(xen-4.3.2-r5 was in use since 21.08.14)
18.10.14 22:50:	Last successful creation of HVM with PCI passthrough
		(that domU run up to 26.10.14 as did another HVM)

Updates and new package installs since last reboot:
22.10.14:	app-misc/pax-utils-0.8.1 (update)
24.10.14:	dev-libs/libaio-0.3.110 (update)
		dev-libs/popt-1.16-r2 (update)
		sys-libs/libcap-ng-0.7.3 (new)
		dev-libs/libgcrypt-1.5.4-r1 (update)
		net-analyzer/tcpdump-4.6.2 (update)
25.10.14:	sys-devel/gcc-4.8.3 (update from 4.7.3-r1)
26.10.14:	app-emulation/xen-tools-4.3.3-r1 (update from 4.3.2-r5)
		app-emulation/xen-4.3.3-r1 (update from 4.3.2-r5)

26.10.14:	reboot - 1st segfault msg in syslog at shutdown time
		system reboots, can't start HVM PCI passthrough domUs
		segfault messages in syslog referring to libgcc_s.so.1
		problems since despite world/kernel/system recompile

If I read this correctly I would come to the conclusion that the only 
package that is a dependency for both 4.3.2-r5 (the previously working, 
but now also non-working version) and 4.3.3-r1 (which never worked) is 
gcc which is required to compile the binaries from source. I don't think 
any of the other packages should have any influence.

Also the error message referring to libgcc_s.so.1 might hint towards a 
problme with gcc. It's probably worth mentioning that the system apart 
from XEN runs without any hickups and is still rock solid. At the moment 
it looks as if xen and gcc-4.8.3 don't co-operate well.

It's probably also worth mentioning that gcc is (and also was with the 
older gcc-4.7.3) the hardened gcc version of gentoo which forces 
position-independent executables (PIE), stack smashing protection (SPP) 
and compile time buffer checks (see 
http://wiki.gentoo.org/wiki/Hardened_Gentoo). The rest of hardend (PAX, 
grSecurity, SELinux is not (and never was) in use (so far). I don't know 
whether any of this might have contributed to the problems I am 
currently being faced with.

Now going back to to an older version of gcc from a newer version is not 
recommened and (according to my research on google) might create 
numerous other issues - so there seems to be no easy route to get back 
to gcc-4.7.3 and therefore getting back the binaries for 4.3.2-r5 in the 
state they were before the problems started seems impossible.

I am still at loss and hope for the combined intelligence of the list to 
again get my system up and running.

Many thanks Atom2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:11:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:11:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOiv-0003Bp-4m; Thu, 06 Nov 2014 15:11:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XmOit-0003BX-Gg
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:11:43 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	09/5E-24859-EAF8B545; Thu, 06 Nov 2014 15:11:42 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415286702!8449442!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30102 invoked from network); 6 Nov 2014 15:11:42 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:11:42 -0000
Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XmOiq-0006Rb-UF; Thu, 06 Nov 2014 16:11:40 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.66])
	by justin.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XmOiq-0003ge-II; Thu, 06 Nov 2014 16:11:40 +0100
Message-ID: <545B8FAE.9090608@web2web.at>
Date: Thu, 06 Nov 2014 16:11:42 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>						<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>					<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>				
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>			
	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>		
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>	
	<1415180713.11486.61.camel@citrix.com>
	<545A118B.7040309@web2web.at>
	<1415191140.15317.11.camel@citrix.com>
In-Reply-To: <1415191140.15317.11.camel@citrix.com>
X-Univie-Virus-Scan: scanned by ClamAV on justin.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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

Am 05.11.14 um 13:39 schrieb Ian Campbell:
> On Wed, 2014-11-05 at 13:01 +0100, Atom2 wrote:
>
> Thanks for all that, sadly it's not giving me any clues what is going
> wrong :-/
>
> So unless "-v --leak-check=full" tells me something (which I'm doubtful
> of at this stage) I think we're back to bisecting the changes since
> 4.3.1, sorry.
Things are getting very strange at the moment.
After much work an research I have been able to download the source and 
compile the old version which has worked before (which incidentally was 
not 4.3.1 but rather 4.3.2-r5 - sorry for any confusion that might have 
caused). I initially thought that's good news because there are less 
changes between 4.3.2 and 4.3.3 but after re-ompiling 4.3.2-r5 I am now 
experiencing the same segfault as with 4.3.3.

So my next step was trying to figure out what else had changed since the 
problems started on 26.10.14 by working through log files and those are 
the relevant events that had happened. The sequence of events was as 
follows:

11.10.14 04:13:	Last system reboot with working version (xen 4.3.2-r5)
		(xen-4.3.2-r5 was in use since 21.08.14)
18.10.14 22:50:	Last successful creation of HVM with PCI passthrough
		(that domU run up to 26.10.14 as did another HVM)

Updates and new package installs since last reboot:
22.10.14:	app-misc/pax-utils-0.8.1 (update)
24.10.14:	dev-libs/libaio-0.3.110 (update)
		dev-libs/popt-1.16-r2 (update)
		sys-libs/libcap-ng-0.7.3 (new)
		dev-libs/libgcrypt-1.5.4-r1 (update)
		net-analyzer/tcpdump-4.6.2 (update)
25.10.14:	sys-devel/gcc-4.8.3 (update from 4.7.3-r1)
26.10.14:	app-emulation/xen-tools-4.3.3-r1 (update from 4.3.2-r5)
		app-emulation/xen-4.3.3-r1 (update from 4.3.2-r5)

26.10.14:	reboot - 1st segfault msg in syslog at shutdown time
		system reboots, can't start HVM PCI passthrough domUs
		segfault messages in syslog referring to libgcc_s.so.1
		problems since despite world/kernel/system recompile

If I read this correctly I would come to the conclusion that the only 
package that is a dependency for both 4.3.2-r5 (the previously working, 
but now also non-working version) and 4.3.3-r1 (which never worked) is 
gcc which is required to compile the binaries from source. I don't think 
any of the other packages should have any influence.

Also the error message referring to libgcc_s.so.1 might hint towards a 
problme with gcc. It's probably worth mentioning that the system apart 
from XEN runs without any hickups and is still rock solid. At the moment 
it looks as if xen and gcc-4.8.3 don't co-operate well.

It's probably also worth mentioning that gcc is (and also was with the 
older gcc-4.7.3) the hardened gcc version of gentoo which forces 
position-independent executables (PIE), stack smashing protection (SPP) 
and compile time buffer checks (see 
http://wiki.gentoo.org/wiki/Hardened_Gentoo). The rest of hardend (PAX, 
grSecurity, SELinux is not (and never was) in use (so far). I don't know 
whether any of this might have contributed to the problems I am 
currently being faced with.

Now going back to to an older version of gcc from a newer version is not 
recommened and (according to my research on google) might create 
numerous other issues - so there seems to be no easy route to get back 
to gcc-4.7.3 and therefore getting back the binaries for 4.3.2-r5 in the 
state they were before the problems started seems impossible.

I am still at loss and hope for the combined intelligence of the list to 
again get my system up and running.

Many thanks Atom2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:11:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:11:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOj3-0003FG-Oq; Thu, 06 Nov 2014 15:11:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XmOj2-0003Eu-NP
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 15:11:52 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	A3/A2-01660-8BF8B545; Thu, 06 Nov 2014 15:11:52 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415286710!5616069!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20356 invoked from network); 6 Nov 2014 15:11:51 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:11:51 -0000
Received: by mail-wi0-f176.google.com with SMTP id h11so1791820wiw.3
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 07:11:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=/hk+iJS3dzaUOQ5sfV4qCjjiYbjSYvK3IkZB/nKS+4s=;
	b=QD8whLhyKZkdow4MlLPNDnKmK/57LFY230RQ6qv1N2YHWIYsM+2gSM0D7gdCv0izja
	l7OVDdXboNF6RZLaNoW/N7mqGt6cGQCLC0eVq2HAzRUI7b2o5pdayeJMx+F/R7REhwdq
	wbeehuVp2tyFvq1vqnMFmk6X2kPcG3uT+gnMcq68M0cSJiuZ6JOPYZgwYJbJw50MNrF/
	L2GDGTQgv6bfIcN3RubTXUzah+Ad8npj43HErDk1uWHjBe5jPVMMW8+0Ie2BZoXhMZ/d
	+AVkJl7iuwePxFxezpqSQNEyPklz6h2YvgbJygLOXxThRGbONxBjuF4ZSUB/jL+angfh
	zZmQ==
X-Gm-Message-State: ALoCoQm5CFs+uLRKOTFIfPVjxZanqzpXWCnzVDS//oAhzUVymQN6N4LwxK/Tq0rlq9fVVg0e3ZT5
X-Received: by 10.180.99.163 with SMTP id er3mr15089807wib.18.1415286710563;
	Thu, 06 Nov 2014 07:11:50 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id hh14sm824238wib.13.2014.11.06.07.11.43
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 07:11:49 -0800 (PST)
Message-ID: <545B8FCE.60902@m2r.biz>
Date: Thu, 06 Nov 2014 16:12:14 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<544B5AF5.7050103@m2r.biz>
	<20141027161542.GK4050@laptop.dumpdata.com>
	<544F987E.5060508@m2r.biz>
	<20141028171811.GA27336@laptop.dumpdata.com>
	<CABMPFziN9eM6_0_mfQcamOqyQBXVOOD5amom+7JTv=LorbbTeQ@mail.gmail.com>
	<20141031143338.GB6913@laptop.dumpdata.com>
	<54576188.9050500@m2r.biz>
	<20141103160347.GD1638@laptop.dumpdata.com>
In-Reply-To: <20141103160347.GD1638@laptop.dumpdata.com>
Cc: Artem Mygaiev <artem.mygaiev@globallogic.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, mengxu@cis.upenn.edu,
	M A Young <m.a.young@durham.ac.uk>, chao.p.peng@linux.intel.com,
	zhigang.x.wang@oracle.com, Parth Dixit <parth.dixit@linaro.org>,
	davi.d.vrabel@citrix.com, Paul.Skentzos@dornerworks.com,
	wency@cn.fujitsu.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, Daniel Kiper <daniel.kiper@oracle.com>,
	josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	yjhyun.yoo@samsung.com, Olaf Hering <olaf@aepfle.de>,
	Ian Campbell <ian.campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mcgrof@suse.com, Julien Grall <julien.grall@linaro.org>,
	Dave Scott <dave.scott@citrix.com>, robert.vanvossen@dornerworks.com,
	Roy Franz <roy.franz@linaro.org>, Yang Z Zhang <yang.z.zhang@intel.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Matt Wilson <msw@amazon.com>, spice-devel@lists.freedesktop.org,
	boris.ostrovsky@oracle.com, andrii.tseglytskyi@globallogic.com,
	Juergen Gross <jgross@suse.com>,
	Thomas Leonard <talex5@gmail.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, aravindp@cisco.com,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Suriyan Ramasami <suriyan.r@gmail.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Steve.VanderLeest@dornerworks.com, Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	Don Slutz <dslutz@verizon.com>, tklengyel@sec.in.tum.de,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Suravee.Suthikulpanit@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tiejun Chen <tiejun.chen@intel.com>, malcolm.crossley@citrix.com,
	yanghy@cn.fujitsu.com, Vijaya.Kumar@caviumnetworks.com,
	feng.wu@intel.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Is: QXL in Xen (busted) Was :Re: Xen 4.5-rc1 update
 (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 03/11/2014 17:03, Konrad Rzeszutek Wilk ha scritto:
> On Mon, Nov 03, 2014 at 12:05:44PM +0100, Fabio Fantoni wrote:
>> Il 31/10/2014 15:33, Konrad Rzeszutek Wilk ha scritto:
>>>> I always posted all versions of the patch in xen-devel, the latest was long
>>>> time ago.
>>> Sometimes you need to poke the maintainers. They (at least
>>> I do) have mailboxes so packed that sometimes emails end up
>>> going missing. But I think their arguments is going to be:
>>> lets figure out what is broken before putting this in the source.
>>>
>>> .. snip..
>>>>> Does SPICE always have to be enabled to use QXL?
>>>>>
>>> .. snip ..
>>>> Xen with spice full working on both windows and linux (including
>>>> save/restore) used for both vkvm and thin client I think would be perfect.
>>> Right. But there is some work needed in that area (figure out what
>>> is happening on Linux).
>>>
>>> ..snip..
>>>>> OK, looking at how the driver is setup - it seems that there is an QXL
>>>>> KMS driver. If you boot without Xorg running but just with in the console
>>>>> can
>>>>> you use 'fbset' or any other framebuffer tools (linux-fb-tools)?
>>>>> That is I am curious to see whether the 'FB' is working properly first
>>>>> before figuring out whether Xorg is working.
>>>>>
>>>> Some tests ago I tried without xorg to see if kernel parts is ok (advice of
>>>> other developer) and seems was ok.
>>> What did you test? There is an 'drm-test' tool that was floating around?
>>> (http://cgit.freedesktop.org/mesa/drm/)
>>>
>>> It allows you to run most (if not all) of the Xorg functionality - but
>>> using an tool from user-space - and with much more exposure of what
>>> went wrong.
>>>
>>> Could you try the following (without having Xorg in either guest):
>>>   1). Boot up your KVM guest, install said tool - run it. Record what
>>>      works and what does not.
>>>
>>>   2). Boot up your Xen guest, and do the same thing.
>>>
>>> That should narrow down which of the hundreds' of DRM ioctls is failing
>>> when using spice under Xen. And that ought to help narrow down this further.
>>>
>>> I can help you a bit by sending you some debug patches, thought I do
>>> have to warn you that I am under a lot of time-pressure so my response
>>> is not as fast as I would want it to be.
>>>
>> I tested only without xorg, just console with drm without particular tests.
>>
>> I can't find the drm-test tool you mentioned, is it available in debian
>> and/or fedora repositories an what is it called?
>> I also did a quick google search and found only something about wayland and
>> not about X.org.
> I mentioned the URL in the email, but here it is again:
>
> http://cgit.freedesktop.org/mesa/drm/
>
> You will need to compile it, etc.

Thanks for your reply, sorry for my late reply, I was busy.
I prepared 2 Trusty (ubuntu 14.04) vm minimal for the tests (one on kvm 
and one on xen).
Started and both arrive to console login successfull and they have qxl 
kernel module active:

lsmod
...
qxl
drm_kms_helper qxl
drm qxl,ttm,drm_kms_helper
...

I downloaded compile and installed mesa/drm from git master brach
./configure
make
sudo make install

After I tried to execute the tests binary I found under test but all fails:
sudo ./modetest
...
no device found.

sudo ./vbltest
...
failed to load any modules, aborting.

sudo ./kmstest
main: Could not open device (Operation not permitted)

Same result on both xen and kvm.
Seems that there is any module in mesa/drm about qxl even if kernel 
modules is present and active and qxl xorg driver use it FWIK.

I did another fast search on google without found how to test qxl drm to 
find the difference between xen and kvm.
Someone can tell me what I must do to take useful data about xen and kvm 
difference for qxl problem?

I added also spice-devel to cc.

Thanks for any reply and sorry for my bad english.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:11:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:11:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOj3-0003FG-Oq; Thu, 06 Nov 2014 15:11:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XmOj2-0003Eu-NP
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 15:11:52 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	A3/A2-01660-8BF8B545; Thu, 06 Nov 2014 15:11:52 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415286710!5616069!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20356 invoked from network); 6 Nov 2014 15:11:51 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:11:51 -0000
Received: by mail-wi0-f176.google.com with SMTP id h11so1791820wiw.3
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 07:11:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=/hk+iJS3dzaUOQ5sfV4qCjjiYbjSYvK3IkZB/nKS+4s=;
	b=QD8whLhyKZkdow4MlLPNDnKmK/57LFY230RQ6qv1N2YHWIYsM+2gSM0D7gdCv0izja
	l7OVDdXboNF6RZLaNoW/N7mqGt6cGQCLC0eVq2HAzRUI7b2o5pdayeJMx+F/R7REhwdq
	wbeehuVp2tyFvq1vqnMFmk6X2kPcG3uT+gnMcq68M0cSJiuZ6JOPYZgwYJbJw50MNrF/
	L2GDGTQgv6bfIcN3RubTXUzah+Ad8npj43HErDk1uWHjBe5jPVMMW8+0Ie2BZoXhMZ/d
	+AVkJl7iuwePxFxezpqSQNEyPklz6h2YvgbJygLOXxThRGbONxBjuF4ZSUB/jL+angfh
	zZmQ==
X-Gm-Message-State: ALoCoQm5CFs+uLRKOTFIfPVjxZanqzpXWCnzVDS//oAhzUVymQN6N4LwxK/Tq0rlq9fVVg0e3ZT5
X-Received: by 10.180.99.163 with SMTP id er3mr15089807wib.18.1415286710563;
	Thu, 06 Nov 2014 07:11:50 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id hh14sm824238wib.13.2014.11.06.07.11.43
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 07:11:49 -0800 (PST)
Message-ID: <545B8FCE.60902@m2r.biz>
Date: Thu, 06 Nov 2014 16:12:14 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<544B5AF5.7050103@m2r.biz>
	<20141027161542.GK4050@laptop.dumpdata.com>
	<544F987E.5060508@m2r.biz>
	<20141028171811.GA27336@laptop.dumpdata.com>
	<CABMPFziN9eM6_0_mfQcamOqyQBXVOOD5amom+7JTv=LorbbTeQ@mail.gmail.com>
	<20141031143338.GB6913@laptop.dumpdata.com>
	<54576188.9050500@m2r.biz>
	<20141103160347.GD1638@laptop.dumpdata.com>
In-Reply-To: <20141103160347.GD1638@laptop.dumpdata.com>
Cc: Artem Mygaiev <artem.mygaiev@globallogic.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, mengxu@cis.upenn.edu,
	M A Young <m.a.young@durham.ac.uk>, chao.p.peng@linux.intel.com,
	zhigang.x.wang@oracle.com, Parth Dixit <parth.dixit@linaro.org>,
	davi.d.vrabel@citrix.com, Paul.Skentzos@dornerworks.com,
	wency@cn.fujitsu.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, Daniel Kiper <daniel.kiper@oracle.com>,
	josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	yjhyun.yoo@samsung.com, Olaf Hering <olaf@aepfle.de>,
	Ian Campbell <ian.campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mcgrof@suse.com, Julien Grall <julien.grall@linaro.org>,
	Dave Scott <dave.scott@citrix.com>, robert.vanvossen@dornerworks.com,
	Roy Franz <roy.franz@linaro.org>, Yang Z Zhang <yang.z.zhang@intel.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Matt Wilson <msw@amazon.com>, spice-devel@lists.freedesktop.org,
	boris.ostrovsky@oracle.com, andrii.tseglytskyi@globallogic.com,
	Juergen Gross <jgross@suse.com>,
	Thomas Leonard <talex5@gmail.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, aravindp@cisco.com,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Suriyan Ramasami <suriyan.r@gmail.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Steve.VanderLeest@dornerworks.com, Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	Don Slutz <dslutz@verizon.com>, tklengyel@sec.in.tum.de,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Suravee.Suthikulpanit@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tiejun Chen <tiejun.chen@intel.com>, malcolm.crossley@citrix.com,
	yanghy@cn.fujitsu.com, Vijaya.Kumar@caviumnetworks.com,
	feng.wu@intel.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Is: QXL in Xen (busted) Was :Re: Xen 4.5-rc1 update
 (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 03/11/2014 17:03, Konrad Rzeszutek Wilk ha scritto:
> On Mon, Nov 03, 2014 at 12:05:44PM +0100, Fabio Fantoni wrote:
>> Il 31/10/2014 15:33, Konrad Rzeszutek Wilk ha scritto:
>>>> I always posted all versions of the patch in xen-devel, the latest was long
>>>> time ago.
>>> Sometimes you need to poke the maintainers. They (at least
>>> I do) have mailboxes so packed that sometimes emails end up
>>> going missing. But I think their arguments is going to be:
>>> lets figure out what is broken before putting this in the source.
>>>
>>> .. snip..
>>>>> Does SPICE always have to be enabled to use QXL?
>>>>>
>>> .. snip ..
>>>> Xen with spice full working on both windows and linux (including
>>>> save/restore) used for both vkvm and thin client I think would be perfect.
>>> Right. But there is some work needed in that area (figure out what
>>> is happening on Linux).
>>>
>>> ..snip..
>>>>> OK, looking at how the driver is setup - it seems that there is an QXL
>>>>> KMS driver. If you boot without Xorg running but just with in the console
>>>>> can
>>>>> you use 'fbset' or any other framebuffer tools (linux-fb-tools)?
>>>>> That is I am curious to see whether the 'FB' is working properly first
>>>>> before figuring out whether Xorg is working.
>>>>>
>>>> Some tests ago I tried without xorg to see if kernel parts is ok (advice of
>>>> other developer) and seems was ok.
>>> What did you test? There is an 'drm-test' tool that was floating around?
>>> (http://cgit.freedesktop.org/mesa/drm/)
>>>
>>> It allows you to run most (if not all) of the Xorg functionality - but
>>> using an tool from user-space - and with much more exposure of what
>>> went wrong.
>>>
>>> Could you try the following (without having Xorg in either guest):
>>>   1). Boot up your KVM guest, install said tool - run it. Record what
>>>      works and what does not.
>>>
>>>   2). Boot up your Xen guest, and do the same thing.
>>>
>>> That should narrow down which of the hundreds' of DRM ioctls is failing
>>> when using spice under Xen. And that ought to help narrow down this further.
>>>
>>> I can help you a bit by sending you some debug patches, thought I do
>>> have to warn you that I am under a lot of time-pressure so my response
>>> is not as fast as I would want it to be.
>>>
>> I tested only without xorg, just console with drm without particular tests.
>>
>> I can't find the drm-test tool you mentioned, is it available in debian
>> and/or fedora repositories an what is it called?
>> I also did a quick google search and found only something about wayland and
>> not about X.org.
> I mentioned the URL in the email, but here it is again:
>
> http://cgit.freedesktop.org/mesa/drm/
>
> You will need to compile it, etc.

Thanks for your reply, sorry for my late reply, I was busy.
I prepared 2 Trusty (ubuntu 14.04) vm minimal for the tests (one on kvm 
and one on xen).
Started and both arrive to console login successfull and they have qxl 
kernel module active:

lsmod
...
qxl
drm_kms_helper qxl
drm qxl,ttm,drm_kms_helper
...

I downloaded compile and installed mesa/drm from git master brach
./configure
make
sudo make install

After I tried to execute the tests binary I found under test but all fails:
sudo ./modetest
...
no device found.

sudo ./vbltest
...
failed to load any modules, aborting.

sudo ./kmstest
main: Could not open device (Operation not permitted)

Same result on both xen and kvm.
Seems that there is any module in mesa/drm about qxl even if kernel 
modules is present and active and qxl xorg driver use it FWIK.

I did another fast search on google without found how to test qxl drm to 
find the difference between xen and kvm.
Someone can tell me what I must do to take useful data about xen and kvm 
difference for qxl problem?

I added also spice-devel to cc.

Thanks for any reply and sorry for my bad english.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:14:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:14:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOlu-0003gh-D7; Thu, 06 Nov 2014 15:14:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmOlt-0003gb-Ao
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:14:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	29/59-02696-8609B545; Thu, 06 Nov 2014 15:14:48 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415286887!11847581!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14741 invoked from network); 6 Nov 2014 15:14:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:14:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="26612973"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
Thread-Index: AQHP+dD1g0CxeTnTMEenPEi10BA3zpxToMUAgAASoAA=
Date: Thu, 6 Nov 2014 15:14:46 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD0111465C9@AMSPEX01CL01.citrite.net>
References: <1415285404-11008-1-git-send-email-paul.durrant@citrix.com>
	<545B8D5A.2090404@citrix.com>
In-Reply-To: <545B8D5A.2090404@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Andrew Cooper
> Sent: 06 November 2014 15:02
> To: Paul Durrant; xen-devel@lists.xen.org
> Cc: Keir (Xen.org); Jan Beulich
> Subject: Re: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
> 
> On 06/11/14 14:50, Paul Durrant wrote:
> > HVM guests have always been confined to using the domain callback
> > via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
> > which is an IOAPIC vector and is only used if the event channel is
> > bound to vcpu 0.
> > This patch adds a new HVM op allowing a guest to specify a local
> > APIC vector to use as an upcall notification for a specific vcpu.
> > This therefore allows a guest which sets a vector for a vcpu
> > other than 0 to then bind event channels to that vcpu.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > Cc: Keir Fraser <keir@xen.org>
> > Cc: Jan Beulich <jbeulich@suse.com>
> 
> Substantially more minimal changes than I would have guessed!
> 

Yep :-) most of the change needed is guest-side.

> > ---
> >  xen/arch/x86/hvm/hvm.c          |   35
> +++++++++++++++++++++++++++++++++++
> >  xen/arch/x86/hvm/irq.c          |    9 +++++++++
> >  xen/include/asm-x86/hvm/vcpu.h  |    1 +
> >  xen/include/public/hvm/hvm_op.h |   16 ++++++++++++++++
> >  4 files changed, 61 insertions(+)
> >
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 78f519d..684e666 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -5458,6 +5458,36 @@ static int hvmop_destroy_ioreq_server(
> >      return rc;
> >  }
> >
> > +static int hvmop_set_evtchn_upcall_vector(
> > +    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t)
> uop)
> > +{
> > +    xen_hvm_set_evtchn_upcall_vector_t op;
> > +    struct domain *d;
> > +    struct vcpu *v;
> > +    int rc;
> > +
> > +    if ( copy_from_guest(&op, uop, 1) )
> > +        return -EFAULT;
> > +
> > +    d = rcu_lock_current_domain();
> > +
> > +    rc = -EINVAL;
> > +    if ( !is_hvm_domain(d) )
> > +        goto out;
> > +
> 
> ENOENT, to help differentiate the various failures.
> 

Sure.

> > +    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
> > +        goto out;
> > +
> 
> Need to verify that op.vector > 0xf.  The first 16 vectors are not valid
> for delivery via the LAPIC.

Good point. I'll add that check.

> 
> > +    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
> > +
> > +    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
> > +    rc = 0;
> > +
> > + out:
> > +    rcu_unlock_domain(d);
> > +    return rc;
> > +}
> > +
> >  #define HVMOP_op_mask 0xff
> >
> >  long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void)
> arg)
> > @@ -5499,6 +5529,11 @@ long do_hvm_op(unsigned long op,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> >              guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
> >          break;
> >
> > +    case HVMOP_set_evtchn_upcall_vector:
> > +        rc = hvmop_set_evtchn_upcall_vector(
> > +            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
> > +        break;
> > +
> >      case HVMOP_set_param:
> >      case HVMOP_get_param:
> >      {
> > diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> > index 35f4f94..3e4c0b4 100644
> > --- a/xen/arch/x86/hvm/irq.c
> > +++ b/xen/arch/x86/hvm/irq.c
> > @@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
> >      spin_unlock(&d->arch.hvm_domain.irq_lock);
> >  }
> >
> > +static void hvm_set_upcall_irq(struct vcpu *v)
> > +{
> > +    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
> > +
> > +    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
> > +}
> > +
> >  static void hvm_set_callback_irq_level(struct vcpu *v)
> >  {
> >      struct domain *d = v->domain;
> > @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
> >
> >      if ( is_hvm_pv_evtchn_vcpu(v) )
> >          vcpu_kick(v);
> > +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> > +        hvm_set_upcall_irq(v);
> >      else if ( v->vcpu_id == 0 )
> >          hvm_set_callback_irq_level(v);
> >  }
> > diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-
> x86/hvm/vcpu.h
> > index 01e0665..edd4523 100644
> > --- a/xen/include/asm-x86/hvm/vcpu.h
> > +++ b/xen/include/asm-x86/hvm/vcpu.h
> > @@ -160,6 +160,7 @@ struct hvm_vcpu {
> >      } u;
> >
> >      struct tasklet      assert_evtchn_irq_tasklet;
> > +    u8                  evtchn_upcall_vector;
> >
> >      struct nestedvcpu   nvcpu;
> >
> > diff --git a/xen/include/public/hvm/hvm_op.h
> b/xen/include/public/hvm/hvm_op.h
> > index eeb0a60..33ccf45 100644
> > --- a/xen/include/public/hvm/hvm_op.h
> > +++ b/xen/include/public/hvm/hvm_op.h
> > @@ -369,6 +369,22 @@
> DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
> >
> >  #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
> 
> This new hvmop looks like it should live in an x86 specific section.
> 

Hmm. Aren't HVM ops essentially x86 specific anyway? There's certainly x86-ness all over the header.

> >
> > +/*
> > + * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used
> for event
> > + *                                 channel upcalls on the specified <vcpu>. If set,
> > + *                                 this vector will be used in preference to the
> > + *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
> > + *                                 and hence allows HVM guests to bind event
> > + *                                 event channels to a vcpu other than 0.
> > + */
> > +#define HVMOP_set_evtchn_upcall_vector 23
> > +struct xen_hvm_set_evtchn_upcall_vector {
> > +    uint32_t vcpu;
> > +    uint8_t vector;
> 
> Is it plausible that a device model might want to call this hypercall on
> a domain which it controls?  I don't believe so, but the question is
> worth considering with a view to adding a domid parameter before the API
> is set in stone.

No, I don't think it's useful outside guest context. I'm open to adding a domid if anyone else thinks otherwise though.

  Paul

> 
> ~Andrew
> 
> > +};
> > +typedef struct xen_hvm_set_evtchn_upcall_vector
> xen_hvm_set_evtchn_upcall_vector_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
> > +
> >  #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
> >
> >  /*
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:14:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:14:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOlu-0003gh-D7; Thu, 06 Nov 2014 15:14:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmOlt-0003gb-Ao
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:14:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	29/59-02696-8609B545; Thu, 06 Nov 2014 15:14:48 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415286887!11847581!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14741 invoked from network); 6 Nov 2014 15:14:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:14:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="26612973"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
Thread-Index: AQHP+dD1g0CxeTnTMEenPEi10BA3zpxToMUAgAASoAA=
Date: Thu, 6 Nov 2014 15:14:46 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD0111465C9@AMSPEX01CL01.citrite.net>
References: <1415285404-11008-1-git-send-email-paul.durrant@citrix.com>
	<545B8D5A.2090404@citrix.com>
In-Reply-To: <545B8D5A.2090404@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Andrew Cooper
> Sent: 06 November 2014 15:02
> To: Paul Durrant; xen-devel@lists.xen.org
> Cc: Keir (Xen.org); Jan Beulich
> Subject: Re: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
> 
> On 06/11/14 14:50, Paul Durrant wrote:
> > HVM guests have always been confined to using the domain callback
> > via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
> > which is an IOAPIC vector and is only used if the event channel is
> > bound to vcpu 0.
> > This patch adds a new HVM op allowing a guest to specify a local
> > APIC vector to use as an upcall notification for a specific vcpu.
> > This therefore allows a guest which sets a vector for a vcpu
> > other than 0 to then bind event channels to that vcpu.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > Cc: Keir Fraser <keir@xen.org>
> > Cc: Jan Beulich <jbeulich@suse.com>
> 
> Substantially more minimal changes than I would have guessed!
> 

Yep :-) most of the change needed is guest-side.

> > ---
> >  xen/arch/x86/hvm/hvm.c          |   35
> +++++++++++++++++++++++++++++++++++
> >  xen/arch/x86/hvm/irq.c          |    9 +++++++++
> >  xen/include/asm-x86/hvm/vcpu.h  |    1 +
> >  xen/include/public/hvm/hvm_op.h |   16 ++++++++++++++++
> >  4 files changed, 61 insertions(+)
> >
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 78f519d..684e666 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -5458,6 +5458,36 @@ static int hvmop_destroy_ioreq_server(
> >      return rc;
> >  }
> >
> > +static int hvmop_set_evtchn_upcall_vector(
> > +    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t)
> uop)
> > +{
> > +    xen_hvm_set_evtchn_upcall_vector_t op;
> > +    struct domain *d;
> > +    struct vcpu *v;
> > +    int rc;
> > +
> > +    if ( copy_from_guest(&op, uop, 1) )
> > +        return -EFAULT;
> > +
> > +    d = rcu_lock_current_domain();
> > +
> > +    rc = -EINVAL;
> > +    if ( !is_hvm_domain(d) )
> > +        goto out;
> > +
> 
> ENOENT, to help differentiate the various failures.
> 

Sure.

> > +    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
> > +        goto out;
> > +
> 
> Need to verify that op.vector > 0xf.  The first 16 vectors are not valid
> for delivery via the LAPIC.

Good point. I'll add that check.

> 
> > +    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
> > +
> > +    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
> > +    rc = 0;
> > +
> > + out:
> > +    rcu_unlock_domain(d);
> > +    return rc;
> > +}
> > +
> >  #define HVMOP_op_mask 0xff
> >
> >  long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void)
> arg)
> > @@ -5499,6 +5529,11 @@ long do_hvm_op(unsigned long op,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> >              guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
> >          break;
> >
> > +    case HVMOP_set_evtchn_upcall_vector:
> > +        rc = hvmop_set_evtchn_upcall_vector(
> > +            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
> > +        break;
> > +
> >      case HVMOP_set_param:
> >      case HVMOP_get_param:
> >      {
> > diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> > index 35f4f94..3e4c0b4 100644
> > --- a/xen/arch/x86/hvm/irq.c
> > +++ b/xen/arch/x86/hvm/irq.c
> > @@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
> >      spin_unlock(&d->arch.hvm_domain.irq_lock);
> >  }
> >
> > +static void hvm_set_upcall_irq(struct vcpu *v)
> > +{
> > +    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
> > +
> > +    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
> > +}
> > +
> >  static void hvm_set_callback_irq_level(struct vcpu *v)
> >  {
> >      struct domain *d = v->domain;
> > @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
> >
> >      if ( is_hvm_pv_evtchn_vcpu(v) )
> >          vcpu_kick(v);
> > +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> > +        hvm_set_upcall_irq(v);
> >      else if ( v->vcpu_id == 0 )
> >          hvm_set_callback_irq_level(v);
> >  }
> > diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-
> x86/hvm/vcpu.h
> > index 01e0665..edd4523 100644
> > --- a/xen/include/asm-x86/hvm/vcpu.h
> > +++ b/xen/include/asm-x86/hvm/vcpu.h
> > @@ -160,6 +160,7 @@ struct hvm_vcpu {
> >      } u;
> >
> >      struct tasklet      assert_evtchn_irq_tasklet;
> > +    u8                  evtchn_upcall_vector;
> >
> >      struct nestedvcpu   nvcpu;
> >
> > diff --git a/xen/include/public/hvm/hvm_op.h
> b/xen/include/public/hvm/hvm_op.h
> > index eeb0a60..33ccf45 100644
> > --- a/xen/include/public/hvm/hvm_op.h
> > +++ b/xen/include/public/hvm/hvm_op.h
> > @@ -369,6 +369,22 @@
> DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
> >
> >  #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
> 
> This new hvmop looks like it should live in an x86 specific section.
> 

Hmm. Aren't HVM ops essentially x86 specific anyway? There's certainly x86-ness all over the header.

> >
> > +/*
> > + * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used
> for event
> > + *                                 channel upcalls on the specified <vcpu>. If set,
> > + *                                 this vector will be used in preference to the
> > + *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
> > + *                                 and hence allows HVM guests to bind event
> > + *                                 event channels to a vcpu other than 0.
> > + */
> > +#define HVMOP_set_evtchn_upcall_vector 23
> > +struct xen_hvm_set_evtchn_upcall_vector {
> > +    uint32_t vcpu;
> > +    uint8_t vector;
> 
> Is it plausible that a device model might want to call this hypercall on
> a domain which it controls?  I don't believe so, but the question is
> worth considering with a view to adding a domid parameter before the API
> is set in stone.

No, I don't think it's useful outside guest context. I'm open to adding a domid if anyone else thinks otherwise though.

  Paul

> 
> ~Andrew
> 
> > +};
> > +typedef struct xen_hvm_set_evtchn_upcall_vector
> xen_hvm_set_evtchn_upcall_vector_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
> > +
> >  #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
> >
> >  /*
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:16:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOnE-0003mm-SG; Thu, 06 Nov 2014 15:16:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmOnD-0003me-K2
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:16:11 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	C8/47-02702-AB09B545; Thu, 06 Nov 2014 15:16:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415286965!11831140!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26451 invoked from network); 6 Nov 2014 15:16:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:16:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188792534"
Message-ID: <545B903F.1090503@citrix.com>
Date: Thu, 6 Nov 2014 15:14:07 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>, <xen-devel@lists.xen.org>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 15:07, Paul Durrant wrote:
> To perform certain hypercalls HVM guests need to use Xen's idea of
> vcpu id, which may well not match the guest OS idea of CPU id.
> This patch adds vcpu id to the HVM cpuid leaf allowing the guest
> to build a mapping.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>
> ---
>  xen/arch/x86/hvm/hvm.c              |    4 ++++
>  xen/include/public/arch-x86/cpuid.h |    5 +++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 78f519d..d9a5706 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t sub_idx,
>           * foreign pages) has valid IOMMU entries.
>           */
>          *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
> +
> +        /* Indicate presence of vcpu id and set it in ebx */
> +        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
> +        *ebx = current->vcpu_id;
>      }
>  }
>  
> diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
> index 6005dfe..8ccb6e1 100644
> --- a/xen/include/public/arch-x86/cpuid.h
> +++ b/xen/include/public/arch-x86/cpuid.h
> @@ -76,13 +76,14 @@
>  /*
>   * Leaf 5 (0x40000x04)
>   * HVM-specific features
> + * EAX: Features
> + * EBX: VCPU ID

Probably want "iff EAX & VCPU_ID_PRESENT" in this comment.

>   */
> -
> -/* EAX Features */

Spurious delete?

>  #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized APIC registers */
>  #define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized x2APIC accesses */
>  /* Memory mapped from other domains has valid IOMMU entries */
>  #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
> +#define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu is present in EBX */

vcpu id?

~Andrew

>  
>  #define XEN_CPUID_MAX_NUM_LEAVES 4
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:16:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOnE-0003mm-SG; Thu, 06 Nov 2014 15:16:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmOnD-0003me-K2
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:16:11 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	C8/47-02702-AB09B545; Thu, 06 Nov 2014 15:16:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415286965!11831140!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26451 invoked from network); 6 Nov 2014 15:16:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:16:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188792534"
Message-ID: <545B903F.1090503@citrix.com>
Date: Thu, 6 Nov 2014 15:14:07 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>, <xen-devel@lists.xen.org>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 15:07, Paul Durrant wrote:
> To perform certain hypercalls HVM guests need to use Xen's idea of
> vcpu id, which may well not match the guest OS idea of CPU id.
> This patch adds vcpu id to the HVM cpuid leaf allowing the guest
> to build a mapping.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>
> ---
>  xen/arch/x86/hvm/hvm.c              |    4 ++++
>  xen/include/public/arch-x86/cpuid.h |    5 +++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 78f519d..d9a5706 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t sub_idx,
>           * foreign pages) has valid IOMMU entries.
>           */
>          *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
> +
> +        /* Indicate presence of vcpu id and set it in ebx */
> +        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
> +        *ebx = current->vcpu_id;
>      }
>  }
>  
> diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
> index 6005dfe..8ccb6e1 100644
> --- a/xen/include/public/arch-x86/cpuid.h
> +++ b/xen/include/public/arch-x86/cpuid.h
> @@ -76,13 +76,14 @@
>  /*
>   * Leaf 5 (0x40000x04)
>   * HVM-specific features
> + * EAX: Features
> + * EBX: VCPU ID

Probably want "iff EAX & VCPU_ID_PRESENT" in this comment.

>   */
> -
> -/* EAX Features */

Spurious delete?

>  #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized APIC registers */
>  #define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized x2APIC accesses */
>  /* Memory mapped from other domains has valid IOMMU entries */
>  #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
> +#define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu is present in EBX */

vcpu id?

~Andrew

>  
>  #define XEN_CPUID_MAX_NUM_LEAVES 4
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:16:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOnK-0003o8-8R; Thu, 06 Nov 2014 15:16:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmOnI-0003nj-Fe
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:16:16 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	43/35-03145-FB09B545; Thu, 06 Nov 2014 15:16:15 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415286974!11865494!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20750 invoked from network); 6 Nov 2014 15:16:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:16:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="26613007"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
Thread-Index: AQHP+dNYgGQeh6AsokmWYd8YGEcZWJxTpDOAgAARHSA=
Date: Thu, 6 Nov 2014 15:16:13 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD0111465F1@AMSPEX01CL01.citrite.net>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<545B903F.1090503@citrix.com>
In-Reply-To: <545B903F.1090503@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu 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

> -----Original Message-----
> From: Andrew Cooper
> Sent: 06 November 2014 15:14
> To: Paul Durrant; xen-devel@lists.xen.org
> Cc: Keir (Xen.org); Jan Beulich
> Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu
> id
> 
> On 06/11/14 15:07, Paul Durrant wrote:
> > To perform certain hypercalls HVM guests need to use Xen's idea of
> > vcpu id, which may well not match the guest OS idea of CPU id.
> > This patch adds vcpu id to the HVM cpuid leaf allowing the guest
> > to build a mapping.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > Cc: Keir Fraser <keir@xen.org>
> > Cc: Jan Beulich <jbeulich@suse.com>
> > ---
> >  xen/arch/x86/hvm/hvm.c              |    4 ++++
> >  xen/include/public/arch-x86/cpuid.h |    5 +++--
> >  2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 78f519d..d9a5706 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t
> sub_idx,
> >           * foreign pages) has valid IOMMU entries.
> >           */
> >          *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
> > +
> > +        /* Indicate presence of vcpu id and set it in ebx */
> > +        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
> > +        *ebx = current->vcpu_id;
> >      }
> >  }
> >
> > diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-
> x86/cpuid.h
> > index 6005dfe..8ccb6e1 100644
> > --- a/xen/include/public/arch-x86/cpuid.h
> > +++ b/xen/include/public/arch-x86/cpuid.h
> > @@ -76,13 +76,14 @@
> >  /*
> >   * Leaf 5 (0x40000x04)
> >   * HVM-specific features
> > + * EAX: Features
> > + * EBX: VCPU ID
> 
> Probably want "iff EAX & VCPU_ID_PRESENT" in this comment.
> 

Yes, I guess.

> >   */
> > -
> > -/* EAX Features */
> 
> Spurious delete?
> 

Nope - it moved up into the above block.

> >  #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized
> APIC registers */
> >  #define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized x2APIC
> accesses */
> >  /* Memory mapped from other domains has valid IOMMU entries */
> >  #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
> > +#define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu is
> present in EBX */
> 
> vcpu id?

Yes. Typo.

  Paul

> 
> ~Andrew
> 
> >
> >  #define XEN_CPUID_MAX_NUM_LEAVES 4
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:16:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOnK-0003o8-8R; Thu, 06 Nov 2014 15:16:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmOnI-0003nj-Fe
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:16:16 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	43/35-03145-FB09B545; Thu, 06 Nov 2014 15:16:15 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415286974!11865494!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20750 invoked from network); 6 Nov 2014 15:16:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:16:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="26613007"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
Thread-Index: AQHP+dNYgGQeh6AsokmWYd8YGEcZWJxTpDOAgAARHSA=
Date: Thu, 6 Nov 2014 15:16:13 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD0111465F1@AMSPEX01CL01.citrite.net>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<545B903F.1090503@citrix.com>
In-Reply-To: <545B903F.1090503@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu 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

> -----Original Message-----
> From: Andrew Cooper
> Sent: 06 November 2014 15:14
> To: Paul Durrant; xen-devel@lists.xen.org
> Cc: Keir (Xen.org); Jan Beulich
> Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu
> id
> 
> On 06/11/14 15:07, Paul Durrant wrote:
> > To perform certain hypercalls HVM guests need to use Xen's idea of
> > vcpu id, which may well not match the guest OS idea of CPU id.
> > This patch adds vcpu id to the HVM cpuid leaf allowing the guest
> > to build a mapping.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > Cc: Keir Fraser <keir@xen.org>
> > Cc: Jan Beulich <jbeulich@suse.com>
> > ---
> >  xen/arch/x86/hvm/hvm.c              |    4 ++++
> >  xen/include/public/arch-x86/cpuid.h |    5 +++--
> >  2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 78f519d..d9a5706 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t
> sub_idx,
> >           * foreign pages) has valid IOMMU entries.
> >           */
> >          *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
> > +
> > +        /* Indicate presence of vcpu id and set it in ebx */
> > +        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
> > +        *ebx = current->vcpu_id;
> >      }
> >  }
> >
> > diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-
> x86/cpuid.h
> > index 6005dfe..8ccb6e1 100644
> > --- a/xen/include/public/arch-x86/cpuid.h
> > +++ b/xen/include/public/arch-x86/cpuid.h
> > @@ -76,13 +76,14 @@
> >  /*
> >   * Leaf 5 (0x40000x04)
> >   * HVM-specific features
> > + * EAX: Features
> > + * EBX: VCPU ID
> 
> Probably want "iff EAX & VCPU_ID_PRESENT" in this comment.
> 

Yes, I guess.

> >   */
> > -
> > -/* EAX Features */
> 
> Spurious delete?
> 

Nope - it moved up into the above block.

> >  #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized
> APIC registers */
> >  #define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized x2APIC
> accesses */
> >  /* Memory mapped from other domains has valid IOMMU entries */
> >  #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
> > +#define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu is
> present in EBX */
> 
> vcpu id?

Yes. Typo.

  Paul

> 
> ~Andrew
> 
> >
> >  #define XEN_CPUID_MAX_NUM_LEAVES 4
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:19:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOqI-00044b-Sy; Thu, 06 Nov 2014 15:19: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@citrix.com>) id 1XmOqI-00044M-4x
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:19:22 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	D4/89-19763-9719B545; Thu, 06 Nov 2014 15:19:21 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415287157!10930251!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1101 invoked from network); 6 Nov 2014 15:19:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:19:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188793931"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:16:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOnm-0000bD-5J;
	Thu, 06 Nov 2014 15:16:46 +0000
Date: Thu, 6 Nov 2014 15:16:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061516210.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
	<CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >
> > Why?
> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.

I meant why are you introducing HYPERVISOR_dom0_op?


> >>  arch/arm/include/asm/xen/hypercall.h | 1 +
> >>  arch/arm/xen/enlighten.c             | 1 +
> >>  arch/arm/xen/hypercall.S             | 1 +
> >>  3 files changed, 3 insertions(+)
> >>
> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> >> index 751869eb..383c174 100644
> >> --- a/arch/arm/include/asm/xen/hypercall.h
> >> +++ b/arch/arm/include/asm/xen/hypercall.h
> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
> >>  int HYPERVISOR_tmem_op(void *arg);
> >> +int HYPERVISOR_dom0_op(void *arg);
> >>  int HYPERVISOR_sysctl(void *arg);
> >>
> >>  static inline void
> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> >> index 675f17a..f757c57 100644
> >> --- a/arch/arm/xen/enlighten.c
> >> +++ b/arch/arm/xen/enlighten.c
> >> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
> >>  EXPORT_SYMBOL_GPL(privcmd_call);
> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> >> index a1276df..99e2254 100644
> >> --- a/arch/arm/xen/hypercall.S
> >> +++ b/arch/arm/xen/hypercall.S
> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
> >>  HYPERCALL2(physdev_op);
> >>  HYPERCALL3(vcpu_op);
> >>  HYPERCALL1(tmem_op);
> >> +HYPERCALL1(dom0_op);
> >>  HYPERCALL1(sysctl);
> >>
> >>  ENTRY(privcmd_call)
> >> --
> >> 1.9.1
> >>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:19:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOqI-00044b-Sy; Thu, 06 Nov 2014 15:19: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@citrix.com>) id 1XmOqI-00044M-4x
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:19:22 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	D4/89-19763-9719B545; Thu, 06 Nov 2014 15:19:21 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415287157!10930251!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1101 invoked from network); 6 Nov 2014 15:19:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:19:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188793931"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:16:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOnm-0000bD-5J;
	Thu, 06 Nov 2014 15:16:46 +0000
Date: Thu, 6 Nov 2014 15:16:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061516210.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
	<CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >
> > Why?
> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.

I meant why are you introducing HYPERVISOR_dom0_op?


> >>  arch/arm/include/asm/xen/hypercall.h | 1 +
> >>  arch/arm/xen/enlighten.c             | 1 +
> >>  arch/arm/xen/hypercall.S             | 1 +
> >>  3 files changed, 3 insertions(+)
> >>
> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> >> index 751869eb..383c174 100644
> >> --- a/arch/arm/include/asm/xen/hypercall.h
> >> +++ b/arch/arm/include/asm/xen/hypercall.h
> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
> >>  int HYPERVISOR_tmem_op(void *arg);
> >> +int HYPERVISOR_dom0_op(void *arg);
> >>  int HYPERVISOR_sysctl(void *arg);
> >>
> >>  static inline void
> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> >> index 675f17a..f757c57 100644
> >> --- a/arch/arm/xen/enlighten.c
> >> +++ b/arch/arm/xen/enlighten.c
> >> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
> >>  EXPORT_SYMBOL_GPL(privcmd_call);
> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> >> index a1276df..99e2254 100644
> >> --- a/arch/arm/xen/hypercall.S
> >> +++ b/arch/arm/xen/hypercall.S
> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
> >>  HYPERCALL2(physdev_op);
> >>  HYPERCALL3(vcpu_op);
> >>  HYPERCALL1(tmem_op);
> >> +HYPERCALL1(dom0_op);
> >>  HYPERCALL1(sysctl);
> >>
> >>  ENTRY(privcmd_call)
> >> --
> >> 1.9.1
> >>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:19:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOqM-00045Y-ER; Thu, 06 Nov 2014 15:19:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmOqK-000457-JX
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:19:24 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	8B/25-27785-B719B545; Thu, 06 Nov 2014 15:19:23 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415287154!11839287!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30195 invoked from network); 6 Nov 2014 15:19:22 -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;
	6 Nov 2014 15:19:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190210989"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:16:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOnT-0000ag-DG;
	Thu, 06 Nov 2014 15:16:27 +0000
Date: Thu, 6 Nov 2014 15:16:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061515400.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
	<CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >
> > Why?
> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.

Sorry, I meant why are you introducing HYPERVISOR_sysctl?


> >>  arch/arm/include/asm/xen/hypercall.h |   1 +
> >>  arch/arm/include/asm/xen/interface.h |   2 +
> >>  arch/arm/xen/enlighten.c             |   1 +
> >>  arch/arm/xen/hypercall.S             |   1 +
> >>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
> >>  include/xen/interface/xen.h          |   6 +
> >>  6 files changed, 657 insertions(+)
> >>  create mode 100644 include/xen/interface/sysctl.h
> >>
> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> >> index c817c56..751869eb 100644
> >> --- a/arch/arm/include/asm/xen/hypercall.h
> >> +++ b/arch/arm/include/asm/xen/hypercall.h
> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
> >>  int HYPERVISOR_tmem_op(void *arg);
> >> +int HYPERVISOR_sysctl(void *arg);
> >>
> >>  static inline void
> >>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
> >> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> >> index 1151188..acf4b7a 100644
> >> --- a/arch/arm/include/asm/xen/interface.h
> >> +++ b/arch/arm/include/asm/xen/interface.h
> >> @@ -19,6 +19,7 @@
> >>       __DEFINE_GUEST_HANDLE(name, struct name)
> >>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
> >>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
> >> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
> >>
> >>  #define set_xen_guest_handle(hnd, val)                       \
> >>       do {                                            \
> >> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
> >>  DEFINE_GUEST_HANDLE(void);
> >>  DEFINE_GUEST_HANDLE(uint64_t);
> >>  DEFINE_GUEST_HANDLE(uint32_t);
> >> +DEFINE_GUEST_HANDLE(uint8_t);
> >>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> >>  DEFINE_GUEST_HANDLE(xen_ulong_t);
> >>
> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> >> index eb0d851..675f17a 100644
> >> --- a/arch/arm/xen/enlighten.c
> >> +++ b/arch/arm/xen/enlighten.c
> >> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
> >>  EXPORT_SYMBOL_GPL(privcmd_call);
> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> >> index d1cf7b7..a1276df 100644
> >> --- a/arch/arm/xen/hypercall.S
> >> +++ b/arch/arm/xen/hypercall.S
> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
> >>  HYPERCALL2(physdev_op);
> >>  HYPERCALL3(vcpu_op);
> >>  HYPERCALL1(tmem_op);
> >> +HYPERCALL1(sysctl);
> >>
> >>  ENTRY(privcmd_call)
> >>       stmdb sp!, {r4}
> >> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
> >> new file mode 100644
> >> index 0000000..1a8cf7a
> >> --- /dev/null
> >> +++ b/include/xen/interface/sysctl.h
> >> @@ -0,0 +1,646 @@
> >> +/******************************************************************************
> >> + * sysctl.h
> >> + *
> >> + * System management operations. For use by node control stack.
> >> + *
> >> + * Reused from xen: xen/include/public/sysctl.h
> >> + *
> >> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> >> + * of this software and associated documentation files (the "Software"), to
> >> + * deal in the Software without restriction, including without limitation the
> >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> >> + * sell copies of the Software, and to permit persons to whom the Software is
> >> + * furnished to do so, subject to the following conditions:
> >> + *
> >> + * The above copyright notice and this permission notice shall be included in
> >> + * all copies or substantial portions of the Software.
> >> + *
> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> >> + * DEALINGS IN THE SOFTWARE.
> >> + *
> >> + * Copyright (c) 2002-2006, K Fraser
> >> + * Copyright (c) 2014, GlobalLogic Inc.
> >> + */
> >> +
> >> +#ifndef __XEN_PUBLIC_SYSCTL_H__
> >> +#define __XEN_PUBLIC_SYSCTL_H__
> >> +
> >> +#include <xen/interface/xen.h>
> >> +
> >> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
> >> +
> >> +/*
> >> + * Read console content from Xen buffer ring.
> >> + */
> >> +/* XEN_SYSCTL_readconsole */
> >> +struct xen_sysctl_readconsole {
> >> +     /* IN: Non-zero -> clear after reading. */
> >> +     uint8_t clear;
> >> +     /* IN: Non-zero -> start index specified by @index field. */
> >> +     uint8_t incremental;
> >> +     uint8_t pad0, pad1;
> >> +     /*
> >> +     * IN:  Start index for consuming from ring buffer (if @incremental);
> >> +     * OUT: End index after consuming from ring buffer.
> >> +     */
> >> +     uint32_t index;
> >> +     /* IN: Virtual address to write console data. */
> >> +     GUEST_HANDLE_64(char) buffer;
> >> +     /* IN: Size of buffer; OUT: Bytes written to buffer. */
> >> +     uint32_t count;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
> >> +
> >> +/* Get trace buffers machine base address */
> >> +/* XEN_SYSCTL_tbuf_op */
> >> +struct xen_sysctl_tbuf_op {
> >> +    /* IN variables */
> >> +#define XEN_SYSCTL_TBUFOP_get_info     0
> >> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
> >> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
> >> +#define XEN_SYSCTL_TBUFOP_set_size     3
> >> +#define XEN_SYSCTL_TBUFOP_enable       4
> >> +#define XEN_SYSCTL_TBUFOP_disable      5
> >> +     uint32_t cmd;
> >> +     /* IN/OUT variables */
> >> +     struct xenctl_bitmap cpu_mask;
> >> +     uint32_t             evt_mask;
> >> +     /* OUT variables */
> >> +     uint64_aligned_t buffer_mfn;
> >> +     uint32_t size;  /* Also an IN variable! */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
> >> +
> >> +/*
> >> + * Get physical information about the host machine
> >> + */
> >> +/* XEN_SYSCTL_physinfo */
> >> + /* (x86) The platform supports HVM guests. */
> >> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
> >> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
> >> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
> >> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
> >> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
> >> +struct xen_sysctl_physinfo {
> >> +     uint32_t threads_per_core;
> >> +     uint32_t cores_per_socket;
> >> +     uint32_t nr_cpus;     /* # CPUs currently online */
> >> +     uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
> >> +     uint32_t nr_nodes;    /* # nodes currently online */
> >> +     uint32_t max_node_id; /* Largest possible node ID on this host */
> >> +     uint32_t cpu_khz;
> >> +     uint64_aligned_t total_pages;
> >> +     uint64_aligned_t free_pages;
> >> +     uint64_aligned_t scrub_pages;
> >> +     uint64_aligned_t outstanding_pages;
> >> +     uint32_t hw_cap[8];
> >> +
> >> +     /* XEN_SYSCTL_PHYSCAP_??? */
> >> +     uint32_t capabilities;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
> >> +
> >> +/*
> >> + * Get the ID of the current scheduler.
> >> + */
> >> +/* XEN_SYSCTL_sched_id */
> >> +struct xen_sysctl_sched_id {
> >> +     /* OUT variable */
> >> +     uint32_t sched_id;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
> >> +
> >> +/* Interface for controlling Xen software performance counters. */
> >> +/* XEN_SYSCTL_perfc_op */
> >> +/* Sub-operations: */
> >> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
> >> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
> >> +struct xen_sysctl_perfc_desc {
> >> +     char         name[80];           /* name of perf counter */
> >> +     uint32_t     nr_vals;            /* number of values for this counter */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
> >> +
> >> +struct xen_sysctl_perfc_op {
> >> +     /* IN variables. */
> >> +     uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
> >> +     /* OUT variables. */
> >> +     uint32_t       nr_counters;       /*  number of counters description  */
> >> +     uint32_t       nr_vals;           /*  number of values  */
> >> +     /* counter information (or NULL) */
> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
> >> +     /* counter values (or NULL) */
> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
> >> +
> >> +/* Inject debug keys into Xen. */
> >> +/* XEN_SYSCTL_debug_keys */
> >> +struct xen_sysctl_debug_keys {
> >> +     /* IN variables. */
> >> +     GUEST_HANDLE_64(char) keys;
> >> +     uint32_t nr_keys;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
> >> +
> >> +/* Get physical CPU information. */
> >> +/* XEN_SYSCTL_getcpuinfo */
> >> +struct xen_sysctl_cpuinfo {
> >> +     uint64_aligned_t idletime;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
> >> +struct xen_sysctl_getcpuinfo {
> >> +     /* IN variables. */
> >> +     uint32_t max_cpus;
> >> +     GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
> >> +     /* OUT variables. */
> >> +     uint32_t nr_cpus;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
> >> +
> >> +/* XEN_SYSCTL_availheap */
> >> +struct xen_sysctl_availheap {
> >> +     /* IN variables. */
> >> +     uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
> >> +     uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
> >> +     int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
> >> +     /* OUT variables. */
> >> +     uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
> >> +
> >> +/* XEN_SYSCTL_get_pmstat */
> >> +struct pm_px_val {
> >> +     uint64_aligned_t freq;        /* Px core frequency */
> >> +     uint64_aligned_t residency;   /* Px residency time */
> >> +     uint64_aligned_t count;       /* Px transition count */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
> >> +
> >> +struct pm_px_stat {
> >> +     uint8_t total;        /* total Px states */
> >> +     uint8_t usable;       /* usable Px states */
> >> +     uint8_t last;         /* last Px state */
> >> +     uint8_t cur;          /* current Px state */
> >> +     GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
> >> +     GUEST_HANDLE_64(pm_px_val) pt;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
> >> +
> >> +struct pm_cx_stat {
> >> +     uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
> >> +     uint32_t last;  /* last Cx state */
> >> +     uint64_aligned_t idle_time;                 /* idle time from boot */
> >> +     GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
> >> +     GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
> >> +     uint64_aligned_t pc2;
> >> +     uint64_aligned_t pc3;
> >> +     uint64_aligned_t pc6;
> >> +     uint64_aligned_t pc7;
> >> +     uint64_aligned_t cc3;
> >> +     uint64_aligned_t cc6;
> >> +     uint64_aligned_t cc7;
> >> +};
> >> +
> >> +struct xen_sysctl_get_pmstat {
> >> +#define PMSTAT_CATEGORY_MASK 0xf0
> >> +#define PMSTAT_PX            0x10
> >> +#define PMSTAT_CX            0x20
> >> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
> >> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
> >> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
> >> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
> >> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
> >> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
> >> +     uint32_t type;
> >> +     uint32_t cpuid;
> >> +     union {
> >> +             struct pm_px_stat getpx;
> >> +             struct pm_cx_stat getcx;
> >> +             /* other struct for tx, etc */
> >> +     } u;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
> >> +
> >> +/* XEN_SYSCTL_cpu_hotplug */
> >> +struct xen_sysctl_cpu_hotplug {
> >> +     /* IN variables */
> >> +     uint32_t cpu;   /* Physical cpu. */
> >> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
> >> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
> >> +     uint32_t op;    /* hotplug opcode */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
> >> +
> >> +/*
> >> + * Get/set xen power management, include
> >> + * 1. cpufreq governors and related parameters
> >> + */
> >> +/* XEN_SYSCTL_pm_op */
> >> +struct xen_userspace {
> >> +     uint32_t scaling_setspeed;
> >> +};
> >> +
> >> +struct xen_ondemand {
> >> +     uint32_t sampling_rate_max;
> >> +     uint32_t sampling_rate_min;
> >> +
> >> +     uint32_t sampling_rate;
> >> +     uint32_t up_threshold;
> >> +};
> >> +
> >> +/*
> >> + * cpufreq para name of this structure named
> >> + * same as sysfs file name of native linux
> >> + */
> >> +#define CPUFREQ_NAME_LEN 16
> >> +struct xen_get_cpufreq_para {
> >> +     /* IN/OUT variable */
> >> +     uint32_t cpu_num;
> >> +     uint32_t freq_num;
> >> +     uint32_t gov_num;
> >> +
> >> +     /* for all governors */
> >> +     /* OUT variable */
> >> +     GUEST_HANDLE_64(uint32_t) affected_cpus;
> >> +     GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
> >> +     GUEST_HANDLE_64(char)   scaling_available_governors;
> >> +     char scaling_driver[CPUFREQ_NAME_LEN];
> >> +
> >> +     uint32_t cpuinfo_cur_freq;
> >> +     uint32_t cpuinfo_max_freq;
> >> +     uint32_t cpuinfo_min_freq;
> >> +     uint32_t scaling_cur_freq;
> >> +
> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
> >> +     uint32_t scaling_max_freq;
> >> +     uint32_t scaling_min_freq;
> >> +
> >> +     /* for specific governor */
> >> +     union {
> >> +             struct  xen_userspace userspace;
> >> +             struct  xen_ondemand ondemand;
> >> +     } u;
> >> +
> >> +     int32_t turbo_enabled;
> >> +};
> >> +
> >> +struct xen_set_cpufreq_gov {
> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
> >> +};
> >> +
> >> +struct xen_set_cpufreq_para {
> >> +     #define SCALING_MAX_FREQ           1
> >> +     #define SCALING_MIN_FREQ           2
> >> +     #define SCALING_SETSPEED           3
> >> +     #define SAMPLING_RATE              4
> >> +     #define UP_THRESHOLD               5
> >> +
> >> +     uint32_t ctrl_type;
> >> +     uint32_t ctrl_value;
> >> +};
> >> +
> >> +struct xen_sysctl_pm_op {
> >> +     #define PM_PARA_CATEGORY_MASK      0xf0
> >> +     #define CPUFREQ_PARA               0x10
> >> +
> >> +     /* cpufreq command type */
> >> +     #define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
> >> +     #define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
> >> +     #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
> >> +     #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
> >> +
> >> +     /* set/reset scheduler power saving option */
> >> +     #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
> >> +
> >> +     /* cpuidle max_cstate access command */
> >> +     #define XEN_SYSCTL_pm_op_get_max_cstate       0x22
> >> +     #define XEN_SYSCTL_pm_op_set_max_cstate       0x23
> >> +
> >> +     /* set scheduler migration cost value */
> >> +     #define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
> >> +     #define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
> >> +
> >> +     /* enable/disable turbo mode when in dbs governor */
> >> +     #define XEN_SYSCTL_pm_op_enable_turbo               0x26
> >> +     #define XEN_SYSCTL_pm_op_disable_turbo              0x27
> >> +
> >> +     uint32_t cmd;
> >> +     uint32_t cpuid;
> >> +     union {
> >> +             struct xen_get_cpufreq_para get_para;
> >> +             struct xen_set_cpufreq_gov  set_gov;
> >> +             struct xen_set_cpufreq_para set_para;
> >> +             uint64_aligned_t get_avgfreq;
> >> +             uint32_t                    set_sched_opt_smt;
> >> +             uint32_t                    get_max_cstate;
> >> +             uint32_t                    set_max_cstate;
> >> +             uint32_t                    get_vcpu_migration_delay;
> >> +             uint32_t                    set_vcpu_migration_delay;
> >> +     } u;
> >> +};
> >> +
> >> +/* XEN_SYSCTL_page_offline_op */
> >> +struct xen_sysctl_page_offline_op {
> >> +     /* IN: range of page to be offlined */
> >> +#define sysctl_page_offline     1
> >> +#define sysctl_page_online      2
> >> +#define sysctl_query_page_offline  3
> >> +     uint32_t cmd;
> >> +     uint32_t start;
> >> +     uint32_t end;
> >> +     /* OUT: result of page offline request */
> >> +     /*
> >> +     * bit 0~15: result flags
> >> +     * bit 16~31: owner
> >> +     */
> >> +     GUEST_HANDLE(uint32_t) status;
> >> +};
> >> +
> >> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
> >> +
> >> +/* The result is invalid, i.e. HV does not handle it */
> >> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
> >> +
> >> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
> >> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
> >> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
> >> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
> >> +
> >> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
> >> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
> >> +
> >> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
> >> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
> >> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
> >> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
> >> +
> >> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
> >> +
> >> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
> >> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
> >> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
> >> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
> >> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
> >> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
> >> +
> >> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
> >> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
> >> +
> >> +#define PG_OFFLINE_OWNER_SHIFT 16
> >> +
> >> +/* XEN_SYSCTL_lockprof_op */
> >> +/* Sub-operations: */
> >> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
> >> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
> >> +/* Record-type: */
> >> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
> >> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
> >> +#define LOCKPROF_TYPE_N           2   /* number of types */
> >> +struct xen_sysctl_lockprof_data {
> >> +     char     name[40];   /* lock name (may include up to 2 %d specifiers) */
> >> +     int32_t  type;       /* LOCKPROF_TYPE_??? */
> >> +     int32_t  idx;        /* index (e.g. domain id) */
> >> +     uint64_aligned_t lock_cnt;     /* # of locking succeeded */
> >> +     uint64_aligned_t block_cnt;    /* # of wait for lock */
> >> +     uint64_aligned_t lock_time;    /* nsecs lock held */
> >> +     uint64_aligned_t block_time;   /* nsecs waited for lock */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
> >> +
> >> +struct xen_sysctl_lockprof_op {
> >> +     /* IN variables. */
> >> +     uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
> >> +     uint32_t       max_elem;          /* size of output buffer */
> >> +     /* OUT variables (query only). */
> >> +     uint32_t       nr_elem;           /* number of elements available */
> >> +     uint64_aligned_t time;            /* nsecs of profile measurement */
> >> +     /* profile information (or NULL) */
> >> +     GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
> >> +
> >> +/* XEN_SYSCTL_topologyinfo */
> >> +#define INVALID_TOPOLOGY_ID  (~0U)
> >> +struct xen_sysctl_topologyinfo {
> >> +     /*
> >> +      * IN: maximum addressable entry in the caller-provided arrays.
> >> +      * OUT: largest cpu identifier in the system.
> >> +      * If OUT is greater than IN then the arrays are truncated!
> >> +      * If OUT is leass than IN then the array tails are not written by
> >> +      * sysctl.
> >> +      */
> >> +     uint32_t max_cpu_index;
> >> +
> >> +     /*
> >> +      * If not NULL, these arrays are filled with core/socket/node identifier
> >> +      * for each cpu.
> >> +      * If a cpu has no core/socket/node information (e.g., cpu not present)
> >> +      * then the sentinel value ~0u is written to each array.
> >> +      * The number of array elements written by the sysctl is:
> >> +      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
> >> +      */
> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_core;
> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_socket;
> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_node;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
> >> +
> >> +/* XEN_SYSCTL_numainfo */
> >> +#define INVALID_NUMAINFO_ID (~0U)
> >> +struct xen_sysctl_numainfo {
> >> +     /*
> >> +      * IN: maximum addressable entry in the caller-provided arrays.
> >> +      * OUT: largest node identifier in the system.
> >> +      * If OUT is greater than IN then the arrays are truncated!
> >> +      */
> >> +     uint32_t max_node_index;
> >> +
> >> +     /* NB. Entries are 0 if node is not present. */
> >> +     GUEST_HANDLE_64(uint64_t) node_to_memsize;
> >> +     GUEST_HANDLE_64(uint64_t) node_to_memfree;
> >> +
> >> +     /*
> >> +      * Array, of size (max_node_index+1)^2, listing memory access distances
> >> +      * between nodes. If an entry has no node distance information (e.g., node
> >> +      * not present) then the value ~0u is written.
> >> +      *
> >> +      * Note that the array rows must be indexed by multiplying by the minimum
> >> +      * of the caller-provided max_node_index and the returned value of
> >> +      * max_node_index. That is, if the largest node index in the system is
> >> +      * smaller than the caller can handle, a smaller 2-d array is constructed
> >> +      * within the space provided by the caller. When this occurs, trailing
> >> +      * space provided by the caller is not modified. If the largest node index
> >> +      * in the system is larger than the caller can handle, then a 2-d array of
> >> +      * the maximum size handleable by the caller is constructed.
> >> +      */
> >> +     GUEST_HANDLE_64(uint32_t) node_to_node_distance;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
> >> +
> >> +/* XEN_SYSCTL_cpupool_op */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
> >> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
> >> +struct xen_sysctl_cpupool_op {
> >> +     uint32_t op;          /* IN */
> >> +     uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
> >> +     uint32_t sched_id;    /* IN: C      OUT: I  */
> >> +     uint32_t domid;       /* IN: M              */
> >> +     uint32_t cpu;         /* IN: AR             */
> >> +     uint32_t n_dom;       /*            OUT: I  */
> >> +     struct xenctl_bitmap cpumap; /*     OUT: IF */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
> >> +
> >> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
> >> +/*
> >> + * This structure is used to pass a new ARINC653 schedule from a
> >> + * privileged domain (ie dom0) to Xen.
> >> + */
> >> +struct xen_sysctl_arinc653_schedule {
> >> +     /* major_frame holds the time for the new schedule's major frame
> >> +     * in nanoseconds. */
> >> +     uint64_aligned_t     major_frame;
> >> +     /* num_sched_entries holds how many of the entries in the
> >> +     * sched_entries[] array are valid. */
> >> +     uint8_t     num_sched_entries;
> >> +     /* The sched_entries array holds the actual schedule entries. */
> >> +     struct {
> >> +             /* dom_handle must match a domain's UUID */
> >> +             xen_domain_handle_t dom_handle;
> >> +             /*
> >> +              * If a domain has multiple VCPUs, vcpu_id specifies which one
> >> +              * this schedule entry applies to. It should be set to 0 if
> >> +              * there is only one VCPU for the domain. */
> >> +             unsigned int vcpu_id;
> >> +             /*
> >> +              * runtime specifies the amount of time that should be allocated
> >> +              * to this VCPU per major frame. It is specified in nanoseconds
> >> +              */
> >> +             uint64_aligned_t runtime;
> >> +     } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
> >> +
> >> +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;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
> >> +
> >> +/* XEN_SYSCTL_scheduler_op */
> >> +/* Set or get info? */
> >> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
> >> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
> >> +struct xen_sysctl_scheduler_op {
> >> +     uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
> >> +     uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
> >> +     uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
> >> +     union {
> >> +             struct xen_sysctl_sched_arinc653 {
> >> +                     GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
> >> +             } sched_arinc653;
> >> +             struct xen_sysctl_credit_schedule sched_credit;
> >> +     } u;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
> >> +
> >> +/* XEN_SYSCTL_coverage_op */
> >> +/*
> >> + * Get total size of information, to help allocate
> >> + * the buffer. The pointer points to a 32 bit value.
> >> + */
> >> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
> >> +
> >> +/*
> >> + * Read coverage information in a single run
> >> + * You must use a tool to split them.
> >> + */
> >> +#define XEN_SYSCTL_COVERAGE_read           1
> >> +
> >> +/*
> >> + * Reset all the coverage counters to 0
> >> + * No parameters.
> >> + */
> >> +#define XEN_SYSCTL_COVERAGE_reset          2
> >> +
> >> +/*
> >> + * Like XEN_SYSCTL_COVERAGE_read but reset also
> >> + * counters to 0 in a single call.
> >> + */
> >> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
> >> +
> >> +struct xen_sysctl_coverage_op {
> >> +     uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
> >> +     union {
> >> +             uint32_t total_size; /* OUT */
> >> +             GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
> >> +     } u;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
> >> +
> >> +
> >> +struct xen_sysctl {
> >> +     uint32_t cmd;
> >> +#define XEN_SYSCTL_readconsole                    1
> >> +#define XEN_SYSCTL_tbuf_op                        2
> >> +#define XEN_SYSCTL_physinfo                       3
> >> +#define XEN_SYSCTL_sched_id                       4
> >> +#define XEN_SYSCTL_perfc_op                       5
> >> +#define XEN_SYSCTL_debug_keys                     7
> >> +#define XEN_SYSCTL_getcpuinfo                     8
> >> +#define XEN_SYSCTL_availheap                      9
> >> +#define XEN_SYSCTL_get_pmstat                    10
> >> +#define XEN_SYSCTL_cpu_hotplug                   11
> >> +#define XEN_SYSCTL_pm_op                         12
> >> +#define XEN_SYSCTL_page_offline_op               14
> >> +#define XEN_SYSCTL_lockprof_op                   15
> >> +#define XEN_SYSCTL_topologyinfo                  16
> >> +#define XEN_SYSCTL_numainfo                      17
> >> +#define XEN_SYSCTL_cpupool_op                    18
> >> +#define XEN_SYSCTL_scheduler_op                  19
> >> +#define XEN_SYSCTL_coverage_op                   20
> >> +     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
> >> +     union {
> >> +             struct xen_sysctl_readconsole       readconsole;
> >> +             struct xen_sysctl_tbuf_op           tbuf_op;
> >> +             struct xen_sysctl_physinfo          physinfo;
> >> +             struct xen_sysctl_topologyinfo      topologyinfo;
> >> +             struct xen_sysctl_numainfo          numainfo;
> >> +             struct xen_sysctl_sched_id          sched_id;
> >> +             struct xen_sysctl_perfc_op          perfc_op;
> >> +             struct xen_sysctl_debug_keys        debug_keys;
> >> +             struct xen_sysctl_getcpuinfo        getcpuinfo;
> >> +             struct xen_sysctl_availheap         availheap;
> >> +             struct xen_sysctl_get_pmstat        get_pmstat;
> >> +             struct xen_sysctl_cpu_hotplug       cpu_hotplug;
> >> +             struct xen_sysctl_pm_op             pm_op;
> >> +             struct xen_sysctl_page_offline_op   page_offline;
> >> +             struct xen_sysctl_lockprof_op       lockprof_op;
> >> +             struct xen_sysctl_cpupool_op        cpupool_op;
> >> +             struct xen_sysctl_scheduler_op      scheduler_op;
> >> +             struct xen_sysctl_coverage_op       coverage_op;
> >> +             uint8_t                             pad[128];
> >> +     } u;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
> >> +
> >> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */
> >
> > We usually only introduce what we need from Xen header files in Linux:
> > do not copy the entirety of sysctl.h, just introduce what you need.
> I'll do this in the next patch-set.
> 
> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> >> index 53ec416..cf64566 100644
> >> --- a/include/xen/interface/xen.h
> >> +++ b/include/xen/interface/xen.h
> >> @@ -57,6 +57,7 @@
> >>  #define __HYPERVISOR_event_channel_op     32
> >>  #define __HYPERVISOR_physdev_op           33
> >>  #define __HYPERVISOR_hvm_op               34
> >> +#define __HYPERVISOR_sysctl               35
> >>  #define __HYPERVISOR_tmem_op              38
> >>
> >>  /* Architecture-specific hypercall definitions. */
> >> @@ -526,6 +527,11 @@ struct tmem_op {
> >>
> >>  DEFINE_GUEST_HANDLE(u64);
> >>
> >> +struct xenctl_bitmap {
> >> +     GUEST_HANDLE_64(uint8_t) bitmap;
> >> +     uint32_t nr_bits;
> >> +};
> >> +
> >>  #else /* __ASSEMBLY__ */
> >>
> >>  /* In assembly code we cannot use C numeric constant suffixes. */
> >> --
> >> 1.9.1
> >>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:19:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOqM-00045Y-ER; Thu, 06 Nov 2014 15:19:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmOqK-000457-JX
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:19:24 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	8B/25-27785-B719B545; Thu, 06 Nov 2014 15:19:23 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415287154!11839287!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30195 invoked from network); 6 Nov 2014 15:19:22 -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;
	6 Nov 2014 15:19:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190210989"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:16:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOnT-0000ag-DG;
	Thu, 06 Nov 2014 15:16:27 +0000
Date: Thu, 6 Nov 2014 15:16:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061515400.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
	<CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >
> > Why?
> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.

Sorry, I meant why are you introducing HYPERVISOR_sysctl?


> >>  arch/arm/include/asm/xen/hypercall.h |   1 +
> >>  arch/arm/include/asm/xen/interface.h |   2 +
> >>  arch/arm/xen/enlighten.c             |   1 +
> >>  arch/arm/xen/hypercall.S             |   1 +
> >>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
> >>  include/xen/interface/xen.h          |   6 +
> >>  6 files changed, 657 insertions(+)
> >>  create mode 100644 include/xen/interface/sysctl.h
> >>
> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> >> index c817c56..751869eb 100644
> >> --- a/arch/arm/include/asm/xen/hypercall.h
> >> +++ b/arch/arm/include/asm/xen/hypercall.h
> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
> >>  int HYPERVISOR_tmem_op(void *arg);
> >> +int HYPERVISOR_sysctl(void *arg);
> >>
> >>  static inline void
> >>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
> >> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> >> index 1151188..acf4b7a 100644
> >> --- a/arch/arm/include/asm/xen/interface.h
> >> +++ b/arch/arm/include/asm/xen/interface.h
> >> @@ -19,6 +19,7 @@
> >>       __DEFINE_GUEST_HANDLE(name, struct name)
> >>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
> >>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
> >> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
> >>
> >>  #define set_xen_guest_handle(hnd, val)                       \
> >>       do {                                            \
> >> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
> >>  DEFINE_GUEST_HANDLE(void);
> >>  DEFINE_GUEST_HANDLE(uint64_t);
> >>  DEFINE_GUEST_HANDLE(uint32_t);
> >> +DEFINE_GUEST_HANDLE(uint8_t);
> >>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> >>  DEFINE_GUEST_HANDLE(xen_ulong_t);
> >>
> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> >> index eb0d851..675f17a 100644
> >> --- a/arch/arm/xen/enlighten.c
> >> +++ b/arch/arm/xen/enlighten.c
> >> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
> >>  EXPORT_SYMBOL_GPL(privcmd_call);
> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> >> index d1cf7b7..a1276df 100644
> >> --- a/arch/arm/xen/hypercall.S
> >> +++ b/arch/arm/xen/hypercall.S
> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
> >>  HYPERCALL2(physdev_op);
> >>  HYPERCALL3(vcpu_op);
> >>  HYPERCALL1(tmem_op);
> >> +HYPERCALL1(sysctl);
> >>
> >>  ENTRY(privcmd_call)
> >>       stmdb sp!, {r4}
> >> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
> >> new file mode 100644
> >> index 0000000..1a8cf7a
> >> --- /dev/null
> >> +++ b/include/xen/interface/sysctl.h
> >> @@ -0,0 +1,646 @@
> >> +/******************************************************************************
> >> + * sysctl.h
> >> + *
> >> + * System management operations. For use by node control stack.
> >> + *
> >> + * Reused from xen: xen/include/public/sysctl.h
> >> + *
> >> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> >> + * of this software and associated documentation files (the "Software"), to
> >> + * deal in the Software without restriction, including without limitation the
> >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> >> + * sell copies of the Software, and to permit persons to whom the Software is
> >> + * furnished to do so, subject to the following conditions:
> >> + *
> >> + * The above copyright notice and this permission notice shall be included in
> >> + * all copies or substantial portions of the Software.
> >> + *
> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> >> + * DEALINGS IN THE SOFTWARE.
> >> + *
> >> + * Copyright (c) 2002-2006, K Fraser
> >> + * Copyright (c) 2014, GlobalLogic Inc.
> >> + */
> >> +
> >> +#ifndef __XEN_PUBLIC_SYSCTL_H__
> >> +#define __XEN_PUBLIC_SYSCTL_H__
> >> +
> >> +#include <xen/interface/xen.h>
> >> +
> >> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
> >> +
> >> +/*
> >> + * Read console content from Xen buffer ring.
> >> + */
> >> +/* XEN_SYSCTL_readconsole */
> >> +struct xen_sysctl_readconsole {
> >> +     /* IN: Non-zero -> clear after reading. */
> >> +     uint8_t clear;
> >> +     /* IN: Non-zero -> start index specified by @index field. */
> >> +     uint8_t incremental;
> >> +     uint8_t pad0, pad1;
> >> +     /*
> >> +     * IN:  Start index for consuming from ring buffer (if @incremental);
> >> +     * OUT: End index after consuming from ring buffer.
> >> +     */
> >> +     uint32_t index;
> >> +     /* IN: Virtual address to write console data. */
> >> +     GUEST_HANDLE_64(char) buffer;
> >> +     /* IN: Size of buffer; OUT: Bytes written to buffer. */
> >> +     uint32_t count;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
> >> +
> >> +/* Get trace buffers machine base address */
> >> +/* XEN_SYSCTL_tbuf_op */
> >> +struct xen_sysctl_tbuf_op {
> >> +    /* IN variables */
> >> +#define XEN_SYSCTL_TBUFOP_get_info     0
> >> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
> >> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
> >> +#define XEN_SYSCTL_TBUFOP_set_size     3
> >> +#define XEN_SYSCTL_TBUFOP_enable       4
> >> +#define XEN_SYSCTL_TBUFOP_disable      5
> >> +     uint32_t cmd;
> >> +     /* IN/OUT variables */
> >> +     struct xenctl_bitmap cpu_mask;
> >> +     uint32_t             evt_mask;
> >> +     /* OUT variables */
> >> +     uint64_aligned_t buffer_mfn;
> >> +     uint32_t size;  /* Also an IN variable! */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
> >> +
> >> +/*
> >> + * Get physical information about the host machine
> >> + */
> >> +/* XEN_SYSCTL_physinfo */
> >> + /* (x86) The platform supports HVM guests. */
> >> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
> >> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
> >> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
> >> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
> >> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
> >> +struct xen_sysctl_physinfo {
> >> +     uint32_t threads_per_core;
> >> +     uint32_t cores_per_socket;
> >> +     uint32_t nr_cpus;     /* # CPUs currently online */
> >> +     uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
> >> +     uint32_t nr_nodes;    /* # nodes currently online */
> >> +     uint32_t max_node_id; /* Largest possible node ID on this host */
> >> +     uint32_t cpu_khz;
> >> +     uint64_aligned_t total_pages;
> >> +     uint64_aligned_t free_pages;
> >> +     uint64_aligned_t scrub_pages;
> >> +     uint64_aligned_t outstanding_pages;
> >> +     uint32_t hw_cap[8];
> >> +
> >> +     /* XEN_SYSCTL_PHYSCAP_??? */
> >> +     uint32_t capabilities;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
> >> +
> >> +/*
> >> + * Get the ID of the current scheduler.
> >> + */
> >> +/* XEN_SYSCTL_sched_id */
> >> +struct xen_sysctl_sched_id {
> >> +     /* OUT variable */
> >> +     uint32_t sched_id;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
> >> +
> >> +/* Interface for controlling Xen software performance counters. */
> >> +/* XEN_SYSCTL_perfc_op */
> >> +/* Sub-operations: */
> >> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
> >> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
> >> +struct xen_sysctl_perfc_desc {
> >> +     char         name[80];           /* name of perf counter */
> >> +     uint32_t     nr_vals;            /* number of values for this counter */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
> >> +
> >> +struct xen_sysctl_perfc_op {
> >> +     /* IN variables. */
> >> +     uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
> >> +     /* OUT variables. */
> >> +     uint32_t       nr_counters;       /*  number of counters description  */
> >> +     uint32_t       nr_vals;           /*  number of values  */
> >> +     /* counter information (or NULL) */
> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
> >> +     /* counter values (or NULL) */
> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
> >> +
> >> +/* Inject debug keys into Xen. */
> >> +/* XEN_SYSCTL_debug_keys */
> >> +struct xen_sysctl_debug_keys {
> >> +     /* IN variables. */
> >> +     GUEST_HANDLE_64(char) keys;
> >> +     uint32_t nr_keys;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
> >> +
> >> +/* Get physical CPU information. */
> >> +/* XEN_SYSCTL_getcpuinfo */
> >> +struct xen_sysctl_cpuinfo {
> >> +     uint64_aligned_t idletime;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
> >> +struct xen_sysctl_getcpuinfo {
> >> +     /* IN variables. */
> >> +     uint32_t max_cpus;
> >> +     GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
> >> +     /* OUT variables. */
> >> +     uint32_t nr_cpus;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
> >> +
> >> +/* XEN_SYSCTL_availheap */
> >> +struct xen_sysctl_availheap {
> >> +     /* IN variables. */
> >> +     uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
> >> +     uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
> >> +     int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
> >> +     /* OUT variables. */
> >> +     uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
> >> +
> >> +/* XEN_SYSCTL_get_pmstat */
> >> +struct pm_px_val {
> >> +     uint64_aligned_t freq;        /* Px core frequency */
> >> +     uint64_aligned_t residency;   /* Px residency time */
> >> +     uint64_aligned_t count;       /* Px transition count */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
> >> +
> >> +struct pm_px_stat {
> >> +     uint8_t total;        /* total Px states */
> >> +     uint8_t usable;       /* usable Px states */
> >> +     uint8_t last;         /* last Px state */
> >> +     uint8_t cur;          /* current Px state */
> >> +     GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
> >> +     GUEST_HANDLE_64(pm_px_val) pt;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
> >> +
> >> +struct pm_cx_stat {
> >> +     uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
> >> +     uint32_t last;  /* last Cx state */
> >> +     uint64_aligned_t idle_time;                 /* idle time from boot */
> >> +     GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
> >> +     GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
> >> +     uint64_aligned_t pc2;
> >> +     uint64_aligned_t pc3;
> >> +     uint64_aligned_t pc6;
> >> +     uint64_aligned_t pc7;
> >> +     uint64_aligned_t cc3;
> >> +     uint64_aligned_t cc6;
> >> +     uint64_aligned_t cc7;
> >> +};
> >> +
> >> +struct xen_sysctl_get_pmstat {
> >> +#define PMSTAT_CATEGORY_MASK 0xf0
> >> +#define PMSTAT_PX            0x10
> >> +#define PMSTAT_CX            0x20
> >> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
> >> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
> >> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
> >> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
> >> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
> >> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
> >> +     uint32_t type;
> >> +     uint32_t cpuid;
> >> +     union {
> >> +             struct pm_px_stat getpx;
> >> +             struct pm_cx_stat getcx;
> >> +             /* other struct for tx, etc */
> >> +     } u;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
> >> +
> >> +/* XEN_SYSCTL_cpu_hotplug */
> >> +struct xen_sysctl_cpu_hotplug {
> >> +     /* IN variables */
> >> +     uint32_t cpu;   /* Physical cpu. */
> >> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
> >> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
> >> +     uint32_t op;    /* hotplug opcode */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
> >> +
> >> +/*
> >> + * Get/set xen power management, include
> >> + * 1. cpufreq governors and related parameters
> >> + */
> >> +/* XEN_SYSCTL_pm_op */
> >> +struct xen_userspace {
> >> +     uint32_t scaling_setspeed;
> >> +};
> >> +
> >> +struct xen_ondemand {
> >> +     uint32_t sampling_rate_max;
> >> +     uint32_t sampling_rate_min;
> >> +
> >> +     uint32_t sampling_rate;
> >> +     uint32_t up_threshold;
> >> +};
> >> +
> >> +/*
> >> + * cpufreq para name of this structure named
> >> + * same as sysfs file name of native linux
> >> + */
> >> +#define CPUFREQ_NAME_LEN 16
> >> +struct xen_get_cpufreq_para {
> >> +     /* IN/OUT variable */
> >> +     uint32_t cpu_num;
> >> +     uint32_t freq_num;
> >> +     uint32_t gov_num;
> >> +
> >> +     /* for all governors */
> >> +     /* OUT variable */
> >> +     GUEST_HANDLE_64(uint32_t) affected_cpus;
> >> +     GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
> >> +     GUEST_HANDLE_64(char)   scaling_available_governors;
> >> +     char scaling_driver[CPUFREQ_NAME_LEN];
> >> +
> >> +     uint32_t cpuinfo_cur_freq;
> >> +     uint32_t cpuinfo_max_freq;
> >> +     uint32_t cpuinfo_min_freq;
> >> +     uint32_t scaling_cur_freq;
> >> +
> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
> >> +     uint32_t scaling_max_freq;
> >> +     uint32_t scaling_min_freq;
> >> +
> >> +     /* for specific governor */
> >> +     union {
> >> +             struct  xen_userspace userspace;
> >> +             struct  xen_ondemand ondemand;
> >> +     } u;
> >> +
> >> +     int32_t turbo_enabled;
> >> +};
> >> +
> >> +struct xen_set_cpufreq_gov {
> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
> >> +};
> >> +
> >> +struct xen_set_cpufreq_para {
> >> +     #define SCALING_MAX_FREQ           1
> >> +     #define SCALING_MIN_FREQ           2
> >> +     #define SCALING_SETSPEED           3
> >> +     #define SAMPLING_RATE              4
> >> +     #define UP_THRESHOLD               5
> >> +
> >> +     uint32_t ctrl_type;
> >> +     uint32_t ctrl_value;
> >> +};
> >> +
> >> +struct xen_sysctl_pm_op {
> >> +     #define PM_PARA_CATEGORY_MASK      0xf0
> >> +     #define CPUFREQ_PARA               0x10
> >> +
> >> +     /* cpufreq command type */
> >> +     #define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
> >> +     #define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
> >> +     #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
> >> +     #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
> >> +
> >> +     /* set/reset scheduler power saving option */
> >> +     #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
> >> +
> >> +     /* cpuidle max_cstate access command */
> >> +     #define XEN_SYSCTL_pm_op_get_max_cstate       0x22
> >> +     #define XEN_SYSCTL_pm_op_set_max_cstate       0x23
> >> +
> >> +     /* set scheduler migration cost value */
> >> +     #define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
> >> +     #define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
> >> +
> >> +     /* enable/disable turbo mode when in dbs governor */
> >> +     #define XEN_SYSCTL_pm_op_enable_turbo               0x26
> >> +     #define XEN_SYSCTL_pm_op_disable_turbo              0x27
> >> +
> >> +     uint32_t cmd;
> >> +     uint32_t cpuid;
> >> +     union {
> >> +             struct xen_get_cpufreq_para get_para;
> >> +             struct xen_set_cpufreq_gov  set_gov;
> >> +             struct xen_set_cpufreq_para set_para;
> >> +             uint64_aligned_t get_avgfreq;
> >> +             uint32_t                    set_sched_opt_smt;
> >> +             uint32_t                    get_max_cstate;
> >> +             uint32_t                    set_max_cstate;
> >> +             uint32_t                    get_vcpu_migration_delay;
> >> +             uint32_t                    set_vcpu_migration_delay;
> >> +     } u;
> >> +};
> >> +
> >> +/* XEN_SYSCTL_page_offline_op */
> >> +struct xen_sysctl_page_offline_op {
> >> +     /* IN: range of page to be offlined */
> >> +#define sysctl_page_offline     1
> >> +#define sysctl_page_online      2
> >> +#define sysctl_query_page_offline  3
> >> +     uint32_t cmd;
> >> +     uint32_t start;
> >> +     uint32_t end;
> >> +     /* OUT: result of page offline request */
> >> +     /*
> >> +     * bit 0~15: result flags
> >> +     * bit 16~31: owner
> >> +     */
> >> +     GUEST_HANDLE(uint32_t) status;
> >> +};
> >> +
> >> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
> >> +
> >> +/* The result is invalid, i.e. HV does not handle it */
> >> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
> >> +
> >> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
> >> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
> >> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
> >> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
> >> +
> >> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
> >> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
> >> +
> >> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
> >> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
> >> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
> >> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
> >> +
> >> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
> >> +
> >> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
> >> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
> >> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
> >> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
> >> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
> >> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
> >> +
> >> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
> >> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
> >> +
> >> +#define PG_OFFLINE_OWNER_SHIFT 16
> >> +
> >> +/* XEN_SYSCTL_lockprof_op */
> >> +/* Sub-operations: */
> >> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
> >> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
> >> +/* Record-type: */
> >> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
> >> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
> >> +#define LOCKPROF_TYPE_N           2   /* number of types */
> >> +struct xen_sysctl_lockprof_data {
> >> +     char     name[40];   /* lock name (may include up to 2 %d specifiers) */
> >> +     int32_t  type;       /* LOCKPROF_TYPE_??? */
> >> +     int32_t  idx;        /* index (e.g. domain id) */
> >> +     uint64_aligned_t lock_cnt;     /* # of locking succeeded */
> >> +     uint64_aligned_t block_cnt;    /* # of wait for lock */
> >> +     uint64_aligned_t lock_time;    /* nsecs lock held */
> >> +     uint64_aligned_t block_time;   /* nsecs waited for lock */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
> >> +
> >> +struct xen_sysctl_lockprof_op {
> >> +     /* IN variables. */
> >> +     uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
> >> +     uint32_t       max_elem;          /* size of output buffer */
> >> +     /* OUT variables (query only). */
> >> +     uint32_t       nr_elem;           /* number of elements available */
> >> +     uint64_aligned_t time;            /* nsecs of profile measurement */
> >> +     /* profile information (or NULL) */
> >> +     GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
> >> +
> >> +/* XEN_SYSCTL_topologyinfo */
> >> +#define INVALID_TOPOLOGY_ID  (~0U)
> >> +struct xen_sysctl_topologyinfo {
> >> +     /*
> >> +      * IN: maximum addressable entry in the caller-provided arrays.
> >> +      * OUT: largest cpu identifier in the system.
> >> +      * If OUT is greater than IN then the arrays are truncated!
> >> +      * If OUT is leass than IN then the array tails are not written by
> >> +      * sysctl.
> >> +      */
> >> +     uint32_t max_cpu_index;
> >> +
> >> +     /*
> >> +      * If not NULL, these arrays are filled with core/socket/node identifier
> >> +      * for each cpu.
> >> +      * If a cpu has no core/socket/node information (e.g., cpu not present)
> >> +      * then the sentinel value ~0u is written to each array.
> >> +      * The number of array elements written by the sysctl is:
> >> +      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
> >> +      */
> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_core;
> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_socket;
> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_node;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
> >> +
> >> +/* XEN_SYSCTL_numainfo */
> >> +#define INVALID_NUMAINFO_ID (~0U)
> >> +struct xen_sysctl_numainfo {
> >> +     /*
> >> +      * IN: maximum addressable entry in the caller-provided arrays.
> >> +      * OUT: largest node identifier in the system.
> >> +      * If OUT is greater than IN then the arrays are truncated!
> >> +      */
> >> +     uint32_t max_node_index;
> >> +
> >> +     /* NB. Entries are 0 if node is not present. */
> >> +     GUEST_HANDLE_64(uint64_t) node_to_memsize;
> >> +     GUEST_HANDLE_64(uint64_t) node_to_memfree;
> >> +
> >> +     /*
> >> +      * Array, of size (max_node_index+1)^2, listing memory access distances
> >> +      * between nodes. If an entry has no node distance information (e.g., node
> >> +      * not present) then the value ~0u is written.
> >> +      *
> >> +      * Note that the array rows must be indexed by multiplying by the minimum
> >> +      * of the caller-provided max_node_index and the returned value of
> >> +      * max_node_index. That is, if the largest node index in the system is
> >> +      * smaller than the caller can handle, a smaller 2-d array is constructed
> >> +      * within the space provided by the caller. When this occurs, trailing
> >> +      * space provided by the caller is not modified. If the largest node index
> >> +      * in the system is larger than the caller can handle, then a 2-d array of
> >> +      * the maximum size handleable by the caller is constructed.
> >> +      */
> >> +     GUEST_HANDLE_64(uint32_t) node_to_node_distance;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
> >> +
> >> +/* XEN_SYSCTL_cpupool_op */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
> >> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
> >> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
> >> +struct xen_sysctl_cpupool_op {
> >> +     uint32_t op;          /* IN */
> >> +     uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
> >> +     uint32_t sched_id;    /* IN: C      OUT: I  */
> >> +     uint32_t domid;       /* IN: M              */
> >> +     uint32_t cpu;         /* IN: AR             */
> >> +     uint32_t n_dom;       /*            OUT: I  */
> >> +     struct xenctl_bitmap cpumap; /*     OUT: IF */
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
> >> +
> >> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
> >> +/*
> >> + * This structure is used to pass a new ARINC653 schedule from a
> >> + * privileged domain (ie dom0) to Xen.
> >> + */
> >> +struct xen_sysctl_arinc653_schedule {
> >> +     /* major_frame holds the time for the new schedule's major frame
> >> +     * in nanoseconds. */
> >> +     uint64_aligned_t     major_frame;
> >> +     /* num_sched_entries holds how many of the entries in the
> >> +     * sched_entries[] array are valid. */
> >> +     uint8_t     num_sched_entries;
> >> +     /* The sched_entries array holds the actual schedule entries. */
> >> +     struct {
> >> +             /* dom_handle must match a domain's UUID */
> >> +             xen_domain_handle_t dom_handle;
> >> +             /*
> >> +              * If a domain has multiple VCPUs, vcpu_id specifies which one
> >> +              * this schedule entry applies to. It should be set to 0 if
> >> +              * there is only one VCPU for the domain. */
> >> +             unsigned int vcpu_id;
> >> +             /*
> >> +              * runtime specifies the amount of time that should be allocated
> >> +              * to this VCPU per major frame. It is specified in nanoseconds
> >> +              */
> >> +             uint64_aligned_t runtime;
> >> +     } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
> >> +
> >> +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;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
> >> +
> >> +/* XEN_SYSCTL_scheduler_op */
> >> +/* Set or get info? */
> >> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
> >> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
> >> +struct xen_sysctl_scheduler_op {
> >> +     uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
> >> +     uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
> >> +     uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
> >> +     union {
> >> +             struct xen_sysctl_sched_arinc653 {
> >> +                     GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
> >> +             } sched_arinc653;
> >> +             struct xen_sysctl_credit_schedule sched_credit;
> >> +     } u;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
> >> +
> >> +/* XEN_SYSCTL_coverage_op */
> >> +/*
> >> + * Get total size of information, to help allocate
> >> + * the buffer. The pointer points to a 32 bit value.
> >> + */
> >> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
> >> +
> >> +/*
> >> + * Read coverage information in a single run
> >> + * You must use a tool to split them.
> >> + */
> >> +#define XEN_SYSCTL_COVERAGE_read           1
> >> +
> >> +/*
> >> + * Reset all the coverage counters to 0
> >> + * No parameters.
> >> + */
> >> +#define XEN_SYSCTL_COVERAGE_reset          2
> >> +
> >> +/*
> >> + * Like XEN_SYSCTL_COVERAGE_read but reset also
> >> + * counters to 0 in a single call.
> >> + */
> >> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
> >> +
> >> +struct xen_sysctl_coverage_op {
> >> +     uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
> >> +     union {
> >> +             uint32_t total_size; /* OUT */
> >> +             GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
> >> +     } u;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
> >> +
> >> +
> >> +struct xen_sysctl {
> >> +     uint32_t cmd;
> >> +#define XEN_SYSCTL_readconsole                    1
> >> +#define XEN_SYSCTL_tbuf_op                        2
> >> +#define XEN_SYSCTL_physinfo                       3
> >> +#define XEN_SYSCTL_sched_id                       4
> >> +#define XEN_SYSCTL_perfc_op                       5
> >> +#define XEN_SYSCTL_debug_keys                     7
> >> +#define XEN_SYSCTL_getcpuinfo                     8
> >> +#define XEN_SYSCTL_availheap                      9
> >> +#define XEN_SYSCTL_get_pmstat                    10
> >> +#define XEN_SYSCTL_cpu_hotplug                   11
> >> +#define XEN_SYSCTL_pm_op                         12
> >> +#define XEN_SYSCTL_page_offline_op               14
> >> +#define XEN_SYSCTL_lockprof_op                   15
> >> +#define XEN_SYSCTL_topologyinfo                  16
> >> +#define XEN_SYSCTL_numainfo                      17
> >> +#define XEN_SYSCTL_cpupool_op                    18
> >> +#define XEN_SYSCTL_scheduler_op                  19
> >> +#define XEN_SYSCTL_coverage_op                   20
> >> +     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
> >> +     union {
> >> +             struct xen_sysctl_readconsole       readconsole;
> >> +             struct xen_sysctl_tbuf_op           tbuf_op;
> >> +             struct xen_sysctl_physinfo          physinfo;
> >> +             struct xen_sysctl_topologyinfo      topologyinfo;
> >> +             struct xen_sysctl_numainfo          numainfo;
> >> +             struct xen_sysctl_sched_id          sched_id;
> >> +             struct xen_sysctl_perfc_op          perfc_op;
> >> +             struct xen_sysctl_debug_keys        debug_keys;
> >> +             struct xen_sysctl_getcpuinfo        getcpuinfo;
> >> +             struct xen_sysctl_availheap         availheap;
> >> +             struct xen_sysctl_get_pmstat        get_pmstat;
> >> +             struct xen_sysctl_cpu_hotplug       cpu_hotplug;
> >> +             struct xen_sysctl_pm_op             pm_op;
> >> +             struct xen_sysctl_page_offline_op   page_offline;
> >> +             struct xen_sysctl_lockprof_op       lockprof_op;
> >> +             struct xen_sysctl_cpupool_op        cpupool_op;
> >> +             struct xen_sysctl_scheduler_op      scheduler_op;
> >> +             struct xen_sysctl_coverage_op       coverage_op;
> >> +             uint8_t                             pad[128];
> >> +     } u;
> >> +};
> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
> >> +
> >> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */
> >
> > We usually only introduce what we need from Xen header files in Linux:
> > do not copy the entirety of sysctl.h, just introduce what you need.
> I'll do this in the next patch-set.
> 
> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> >> index 53ec416..cf64566 100644
> >> --- a/include/xen/interface/xen.h
> >> +++ b/include/xen/interface/xen.h
> >> @@ -57,6 +57,7 @@
> >>  #define __HYPERVISOR_event_channel_op     32
> >>  #define __HYPERVISOR_physdev_op           33
> >>  #define __HYPERVISOR_hvm_op               34
> >> +#define __HYPERVISOR_sysctl               35
> >>  #define __HYPERVISOR_tmem_op              38
> >>
> >>  /* Architecture-specific hypercall definitions. */
> >> @@ -526,6 +527,11 @@ struct tmem_op {
> >>
> >>  DEFINE_GUEST_HANDLE(u64);
> >>
> >> +struct xenctl_bitmap {
> >> +     GUEST_HANDLE_64(uint8_t) bitmap;
> >> +     uint32_t nr_bits;
> >> +};
> >> +
> >>  #else /* __ASSEMBLY__ */
> >>
> >>  /* In assembly code we cannot use C numeric constant suffixes. */
> >> --
> >> 1.9.1
> >>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:21:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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 1XmOsd-0004N0-BE; Thu, 06 Nov 2014 15:21:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmOsc-0004MQ-Hu
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:21:46 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	94/45-09936-9029B545; Thu, 06 Nov 2014 15:21:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415287303!3951399!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15689 invoked from network); 6 Nov 2014 15:21:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:21:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188795294"
Message-ID: <545B916B.906@citrix.com>
Date: Thu, 6 Nov 2014 15:19:07 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <1415285404-11008-1-git-send-email-paul.durrant@citrix.com>
	<545B8D5A.2090404@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0111465C9@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0111465C9@AMSPEX01CL01.citrite.net>
X-DLP: MIA2
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 15:14, Paul Durrant wrote:
>> -----Original Message-----
>> From: Andrew Cooper
>> Sent: 06 November 2014 15:02
>> To: Paul Durrant; xen-devel@lists.xen.org
>> Cc: Keir (Xen.org); Jan Beulich
>> Subject: Re: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
>>
>> On 06/11/14 14:50, Paul Durrant wrote:
>>> HVM guests have always been confined to using the domain callback
>>> via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
>>> which is an IOAPIC vector and is only used if the event channel is
>>> bound to vcpu 0.
>>> This patch adds a new HVM op allowing a guest to specify a local
>>> APIC vector to use as an upcall notification for a specific vcpu.
>>> This therefore allows a guest which sets a vector for a vcpu
>>> other than 0 to then bind event channels to that vcpu.
>>>
>>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>> Cc: Keir Fraser <keir@xen.org>
>>> Cc: Jan Beulich <jbeulich@suse.com>
>> Substantially more minimal changes than I would have guessed!
>>
> Yep :-) most of the change needed is guest-side.
>
>>> ---
>>>  xen/arch/x86/hvm/hvm.c          |   35
>> +++++++++++++++++++++++++++++++++++
>>>  xen/arch/x86/hvm/irq.c          |    9 +++++++++
>>>  xen/include/asm-x86/hvm/vcpu.h  |    1 +
>>>  xen/include/public/hvm/hvm_op.h |   16 ++++++++++++++++
>>>  4 files changed, 61 insertions(+)
>>>
>>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>>> index 78f519d..684e666 100644
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -5458,6 +5458,36 @@ static int hvmop_destroy_ioreq_server(
>>>      return rc;
>>>  }
>>>
>>> +static int hvmop_set_evtchn_upcall_vector(
>>> +    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t)
>> uop)
>>> +{
>>> +    xen_hvm_set_evtchn_upcall_vector_t op;
>>> +    struct domain *d;
>>> +    struct vcpu *v;
>>> +    int rc;
>>> +
>>> +    if ( copy_from_guest(&op, uop, 1) )
>>> +        return -EFAULT;
>>> +
>>> +    d = rcu_lock_current_domain();
>>> +
>>> +    rc = -EINVAL;
>>> +    if ( !is_hvm_domain(d) )
>>> +        goto out;
>>> +
>> ENOENT, to help differentiate the various failures.
>>
> Sure.
>
>>> +    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
>>> +        goto out;
>>> +
>> Need to verify that op.vector > 0xf.  The first 16 vectors are not valid
>> for delivery via the LAPIC.
> Good point. I'll add that check.
>
>>> +    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
>>> +
>>> +    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
>>> +    rc = 0;
>>> +
>>> + out:
>>> +    rcu_unlock_domain(d);
>>> +    return rc;
>>> +}
>>> +
>>>  #define HVMOP_op_mask 0xff
>>>
>>>  long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void)
>> arg)
>>> @@ -5499,6 +5529,11 @@ long do_hvm_op(unsigned long op,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>              guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
>>>          break;
>>>
>>> +    case HVMOP_set_evtchn_upcall_vector:
>>> +        rc = hvmop_set_evtchn_upcall_vector(
>>> +            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
>>> +        break;
>>> +
>>>      case HVMOP_set_param:
>>>      case HVMOP_get_param:
>>>      {
>>> diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
>>> index 35f4f94..3e4c0b4 100644
>>> --- a/xen/arch/x86/hvm/irq.c
>>> +++ b/xen/arch/x86/hvm/irq.c
>>> @@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
>>>      spin_unlock(&d->arch.hvm_domain.irq_lock);
>>>  }
>>>
>>> +static void hvm_set_upcall_irq(struct vcpu *v)
>>> +{
>>> +    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
>>> +
>>> +    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
>>> +}
>>> +
>>>  static void hvm_set_callback_irq_level(struct vcpu *v)
>>>  {
>>>      struct domain *d = v->domain;
>>> @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
>>>
>>>      if ( is_hvm_pv_evtchn_vcpu(v) )
>>>          vcpu_kick(v);
>>> +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
>>> +        hvm_set_upcall_irq(v);
>>>      else if ( v->vcpu_id == 0 )
>>>          hvm_set_callback_irq_level(v);
>>>  }
>>> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-
>> x86/hvm/vcpu.h
>>> index 01e0665..edd4523 100644
>>> --- a/xen/include/asm-x86/hvm/vcpu.h
>>> +++ b/xen/include/asm-x86/hvm/vcpu.h
>>> @@ -160,6 +160,7 @@ struct hvm_vcpu {
>>>      } u;
>>>
>>>      struct tasklet      assert_evtchn_irq_tasklet;
>>> +    u8                  evtchn_upcall_vector;
>>>
>>>      struct nestedvcpu   nvcpu;
>>>
>>> diff --git a/xen/include/public/hvm/hvm_op.h
>> b/xen/include/public/hvm/hvm_op.h
>>> index eeb0a60..33ccf45 100644
>>> --- a/xen/include/public/hvm/hvm_op.h
>>> +++ b/xen/include/public/hvm/hvm_op.h
>>> @@ -369,6 +369,22 @@
>> DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
>>>  #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
>> This new hvmop looks like it should live in an x86 specific section.
>>
> Hmm. Aren't HVM ops essentially x86 specific anyway? There's certainly x86-ness all over the header.

ARM uses some of the HVM ops, but I would agree that most of them are x86.

>
>>> +/*
>>> + * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used
>> for event
>>> + *                                 channel upcalls on the specified <vcpu>. If set,
>>> + *                                 this vector will be used in preference to the
>>> + *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
>>> + *                                 and hence allows HVM guests to bind event
>>> + *                                 event channels to a vcpu other than 0.
>>> + */
>>> +#define HVMOP_set_evtchn_upcall_vector 23
>>> +struct xen_hvm_set_evtchn_upcall_vector {
>>> +    uint32_t vcpu;
>>> +    uint8_t vector;
>> Is it plausible that a device model might want to call this hypercall on
>> a domain which it controls?  I don't believe so, but the question is
>> worth considering with a view to adding a domid parameter before the API
>> is set in stone.
> No, I don't think it's useful outside guest context. I'm open to adding a domid if anyone else thinks otherwise though.
>
>   Paul

More "double checking that this has at least been considered".  I admit
that I can't think of a plausible reason why this hypercall would be
valid to use on anything other than DOMID_SELF.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:21:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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 1XmOsd-0004N0-BE; Thu, 06 Nov 2014 15:21:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmOsc-0004MQ-Hu
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:21:46 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	94/45-09936-9029B545; Thu, 06 Nov 2014 15:21:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415287303!3951399!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15689 invoked from network); 6 Nov 2014 15:21:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:21:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188795294"
Message-ID: <545B916B.906@citrix.com>
Date: Thu, 6 Nov 2014 15:19:07 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <1415285404-11008-1-git-send-email-paul.durrant@citrix.com>
	<545B8D5A.2090404@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0111465C9@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0111465C9@AMSPEX01CL01.citrite.net>
X-DLP: MIA2
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 15:14, Paul Durrant wrote:
>> -----Original Message-----
>> From: Andrew Cooper
>> Sent: 06 November 2014 15:02
>> To: Paul Durrant; xen-devel@lists.xen.org
>> Cc: Keir (Xen.org); Jan Beulich
>> Subject: Re: [Xen-devel] [PATCH] x86/hvm: Add per-vcpu evtchn upcalls
>>
>> On 06/11/14 14:50, Paul Durrant wrote:
>>> HVM guests have always been confined to using the domain callback
>>> via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
>>> which is an IOAPIC vector and is only used if the event channel is
>>> bound to vcpu 0.
>>> This patch adds a new HVM op allowing a guest to specify a local
>>> APIC vector to use as an upcall notification for a specific vcpu.
>>> This therefore allows a guest which sets a vector for a vcpu
>>> other than 0 to then bind event channels to that vcpu.
>>>
>>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>> Cc: Keir Fraser <keir@xen.org>
>>> Cc: Jan Beulich <jbeulich@suse.com>
>> Substantially more minimal changes than I would have guessed!
>>
> Yep :-) most of the change needed is guest-side.
>
>>> ---
>>>  xen/arch/x86/hvm/hvm.c          |   35
>> +++++++++++++++++++++++++++++++++++
>>>  xen/arch/x86/hvm/irq.c          |    9 +++++++++
>>>  xen/include/asm-x86/hvm/vcpu.h  |    1 +
>>>  xen/include/public/hvm/hvm_op.h |   16 ++++++++++++++++
>>>  4 files changed, 61 insertions(+)
>>>
>>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>>> index 78f519d..684e666 100644
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -5458,6 +5458,36 @@ static int hvmop_destroy_ioreq_server(
>>>      return rc;
>>>  }
>>>
>>> +static int hvmop_set_evtchn_upcall_vector(
>>> +    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t)
>> uop)
>>> +{
>>> +    xen_hvm_set_evtchn_upcall_vector_t op;
>>> +    struct domain *d;
>>> +    struct vcpu *v;
>>> +    int rc;
>>> +
>>> +    if ( copy_from_guest(&op, uop, 1) )
>>> +        return -EFAULT;
>>> +
>>> +    d = rcu_lock_current_domain();
>>> +
>>> +    rc = -EINVAL;
>>> +    if ( !is_hvm_domain(d) )
>>> +        goto out;
>>> +
>> ENOENT, to help differentiate the various failures.
>>
> Sure.
>
>>> +    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
>>> +        goto out;
>>> +
>> Need to verify that op.vector > 0xf.  The first 16 vectors are not valid
>> for delivery via the LAPIC.
> Good point. I'll add that check.
>
>>> +    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
>>> +
>>> +    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
>>> +    rc = 0;
>>> +
>>> + out:
>>> +    rcu_unlock_domain(d);
>>> +    return rc;
>>> +}
>>> +
>>>  #define HVMOP_op_mask 0xff
>>>
>>>  long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void)
>> arg)
>>> @@ -5499,6 +5529,11 @@ long do_hvm_op(unsigned long op,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>              guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
>>>          break;
>>>
>>> +    case HVMOP_set_evtchn_upcall_vector:
>>> +        rc = hvmop_set_evtchn_upcall_vector(
>>> +            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
>>> +        break;
>>> +
>>>      case HVMOP_set_param:
>>>      case HVMOP_get_param:
>>>      {
>>> diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
>>> index 35f4f94..3e4c0b4 100644
>>> --- a/xen/arch/x86/hvm/irq.c
>>> +++ b/xen/arch/x86/hvm/irq.c
>>> @@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
>>>      spin_unlock(&d->arch.hvm_domain.irq_lock);
>>>  }
>>>
>>> +static void hvm_set_upcall_irq(struct vcpu *v)
>>> +{
>>> +    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
>>> +
>>> +    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
>>> +}
>>> +
>>>  static void hvm_set_callback_irq_level(struct vcpu *v)
>>>  {
>>>      struct domain *d = v->domain;
>>> @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
>>>
>>>      if ( is_hvm_pv_evtchn_vcpu(v) )
>>>          vcpu_kick(v);
>>> +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
>>> +        hvm_set_upcall_irq(v);
>>>      else if ( v->vcpu_id == 0 )
>>>          hvm_set_callback_irq_level(v);
>>>  }
>>> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-
>> x86/hvm/vcpu.h
>>> index 01e0665..edd4523 100644
>>> --- a/xen/include/asm-x86/hvm/vcpu.h
>>> +++ b/xen/include/asm-x86/hvm/vcpu.h
>>> @@ -160,6 +160,7 @@ struct hvm_vcpu {
>>>      } u;
>>>
>>>      struct tasklet      assert_evtchn_irq_tasklet;
>>> +    u8                  evtchn_upcall_vector;
>>>
>>>      struct nestedvcpu   nvcpu;
>>>
>>> diff --git a/xen/include/public/hvm/hvm_op.h
>> b/xen/include/public/hvm/hvm_op.h
>>> index eeb0a60..33ccf45 100644
>>> --- a/xen/include/public/hvm/hvm_op.h
>>> +++ b/xen/include/public/hvm/hvm_op.h
>>> @@ -369,6 +369,22 @@
>> DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
>>>  #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
>> This new hvmop looks like it should live in an x86 specific section.
>>
> Hmm. Aren't HVM ops essentially x86 specific anyway? There's certainly x86-ness all over the header.

ARM uses some of the HVM ops, but I would agree that most of them are x86.

>
>>> +/*
>>> + * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used
>> for event
>>> + *                                 channel upcalls on the specified <vcpu>. If set,
>>> + *                                 this vector will be used in preference to the
>>> + *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
>>> + *                                 and hence allows HVM guests to bind event
>>> + *                                 event channels to a vcpu other than 0.
>>> + */
>>> +#define HVMOP_set_evtchn_upcall_vector 23
>>> +struct xen_hvm_set_evtchn_upcall_vector {
>>> +    uint32_t vcpu;
>>> +    uint8_t vector;
>> Is it plausible that a device model might want to call this hypercall on
>> a domain which it controls?  I don't believe so, but the question is
>> worth considering with a view to adding a domid parameter before the API
>> is set in stone.
> No, I don't think it's useful outside guest context. I'm open to adding a domid if anyone else thinks otherwise though.
>
>   Paul

More "double checking that this has at least been considered".  I admit
that I can't think of a plausible reason why this hypercall would be
valid to use on anything other than DOMID_SELF.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:23:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOu3-0004Uu-QV; Thu, 06 Nov 2014 15:23:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmOu2-0004Ui-1t
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:23:14 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	47/D2-02696-1629B545; Thu, 06 Nov 2014 15:23:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415287390!8521830!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13028 invoked from network); 6 Nov 2014 15:23:11 -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;
	6 Nov 2014 15:23:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188796009"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:20:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOrR-0000g2-8k;
	Thu, 06 Nov 2014 15:20:33 +0000
Date: Thu, 6 Nov 2014 15:20:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jivYZMgVuhNNtj6Ks05h1iSZBeihKzqcEGi2wp41T4TxyA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061518510.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041621380.22875@kaball.uk.xensource.com>
	<CAN58jivYZMgVuhNNtj6Ks05h1iSZBeihKzqcEGi2wp41T4TxyA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v4 9/9] xen/arm: cpufreq: add
	xen-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Tue, Nov 4, 2014 at 6:33 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> Xen changes frequencies on CPUs using this high-level
> >> cpufreq driver.
> >>
> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >
> > You CC the wrong email address for Rafael in the entire series.
> Could anybody give me right address for Rafael?

rjw@rjwysocki.net

You can also find it by running ./scripts/get_maintainer.pl on the
patch:

sstabellini@st22:/local/scratch/sstabellini/linux-pvops-latest$ ./scripts/get_maintainer.pl ~/patch
"Rafael J. Wysocki" <rjw@rjwysocki.net> (maintainer:CPU FREQUENCY DRI...)
Viresh Kumar <viresh.kumar@linaro.org> (maintainer:CPU FREQUENCY DRI...)
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/3=33%)
Boris Ostrovsky <boris.ostrovsky@oracle.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/3=33%)
David Vrabel <david.vrabel@citrix.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/1=100%,commit_signer:3/3=100%,authored:1/3=33%,removed_lines:6/33=18%)
Stefano Stabellini <stefano.stabellini@eu.citrix.com> (commit_signer:1/1=100%)
Tang Liang <liang.tang@oracle.com> (commit_signer:1/1=100%)
Daniel Kiper <daniel.kiper@oracle.com> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:123/123=100%)
Jan Beulich <jbeulich@suse.com> (commit_signer:1/1=100%)
Ian Campbell <ian.campbell@citrix.com> (commit_signer:1/3=33%,authored:1/3=33%,removed_lines:3/33=9%)
Juergen Gross <jgross@suse.com> (commit_signer:1/3=33%,authored:1/3=33%,added_lines:248/251=99%,removed_lines:24/33=73%)
linux-kernel@vger.kernel.org (open list)
linux-pm@vger.kernel.org (open list:CPU FREQUENCY DRI...)
xen-devel@lists.xenproject.org (moderated list:XEN HYPERVISOR IN...)



> >>  drivers/cpufreq/Kconfig           |  20 +
> >>  drivers/cpufreq/Makefile          |   1 +
> >>  drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
> >>  drivers/cpufreq/cpufreq_drv_ops.h |   4 +
> >>  drivers/cpufreq/xen-cpufreq.c     | 869 ++++++++++++++++++++++++++++++++++++++
> >>  include/xen/interface/platform.h  |   1 +
> >>  include/xen/interface/xen.h       |   1 +
> >>  7 files changed, 907 insertions(+), 2 deletions(-)
> >>  create mode 100644 drivers/cpufreq/xen-cpufreq.c
> >>
> >> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> >> index f5a8f84..4847d8a 100644
> >> --- a/drivers/cpufreq/Kconfig
> >> +++ b/drivers/cpufreq/Kconfig
> >> @@ -19,6 +19,26 @@ config CPU_FREQ
> >>
> >>         If in doubt, say N.
> >>
> >> +config XEN_CPUFREQ
> >> +     bool "Xen Cpufreq driver"
> >> +     depends on XEN_DOM0
> >> +     depends on !CPUMASK_OFFSTACK
> >> +     default n
> >> +     select CPUFREQ_DRV_OPS
> >> +     help
> >> +       This driver uploads Power Management information to the Xen
> >> +       hypervisor and changes CPUs frequency using CPU Frequency scaling
> >> +       drivers.
> >> +
> >> +       To do that the driver uses CPU Frequency scaling drivers to parse
> >> +       the Power Management data and uploads said information to the Xen
> >> +       hypervisor. Then the Xen hypervisor can select the proper Pxx states.
> >> +
> >> +       Then the Xen hypervisor can change CPUs frequency by giving commands
> >> +       via this driver to the CPU Frequency scaling driver.
> >> +
> >> +       If in doubt, say N.
> >> +
> >>  if CPUFREQ_DRV_OPS
> >>
> >>  config CPU_FREQ_TABLE
> >> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> >> index f12a0d3..c8d5037 100644
> >> --- a/drivers/cpufreq/Makefile
> >> +++ b/drivers/cpufreq/Makefile
> >> @@ -1,5 +1,6 @@
> >>  # CPUfreq core
> >>  obj-$(CONFIG_CPU_FREQ)                       += cpufreq.o
> >> +obj-$(CONFIG_XEN_CPUFREQ)            += xen-cpufreq.o
> >>  obj-$(CONFIG_CPUFREQ_DRV_OPS)                += cpufreq_drv_ops.o
> >>  # CPUfreq stats
> >>  obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
> >> diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
> >> index c971442..71c3357 100644
> >> --- a/drivers/cpufreq/cpufreq_drv_ops.c
> >> +++ b/drivers/cpufreq/cpufreq_drv_ops.c
> >> @@ -18,6 +18,8 @@
> >>  #include <linux/init.h>
> >>  #include <linux/export.h>
> >>
> >> +#include <xen/xen.h>
> >> +
> >>  static struct cpufreq_drv_ops *ops;
> >>
> >>  struct kobject *get_cpufreq_global_kobject(void)
> >> @@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
> >>
> >>  static int __init cpufreq_drv_ops_init(void)
> >>  {
> >> +     if (xen_initial_domain()) {
> >> +#ifdef CONFIG_XEN_CPUFREQ
> >> +             ops = &xen_cpufreq_drv_ops;
> >> +             pr_debug("using xen_cpufreq_drv_ops\n");
> >> +#endif
> >> +     } else {
> >>  #ifdef CONFIG_CPU_FREQ
> >> -     ops = &kern_cpufreq_drv_ops;
> >> -     pr_debug("using kern_cpufreq_drv_ops\n");
> >> +             ops = &kern_cpufreq_drv_ops;
> >> +             pr_debug("using kern_cpufreq_drv_ops\n");
> >>  #endif
> >> +     }
> >>
> >>       return 0;
> >>  }
> >> diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
> >> index 5cc8e05..d02d509 100644
> >> --- a/drivers/cpufreq/cpufreq_drv_ops.h
> >> +++ b/drivers/cpufreq/cpufreq_drv_ops.h
> >> @@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
> >>  extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
> >>  #endif
> >>
> >> +#ifdef CONFIG_XEN_CPUFREQ
> >> +extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
> >> +#endif
> >> +
> >>  #endif /* _CPUFREQ_DRV_OPS_H */
> >> diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
> >> new file mode 100644
> >> index 0000000..21062c7
> >> --- /dev/null
> >> +++ b/drivers/cpufreq/xen-cpufreq.c
> >> @@ -0,0 +1,869 @@
> >> +/*
> >> + *  Copyright (C) 2001 Russell King
> >> + *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
> >> + *
> >> + *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
> >> + *   Added handling for CPU hotplug
> >> + *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
> >> + *   Fix handling for CPU hotplug -- affected CPUs
> >> + *
> >> + *           (C) 2014 GlobalLogic Inc.
> >> + *
> >> + * Based on drivers/cpufreq/cpufreq.c
> >> + *
> >> + * 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.
> >> + */
> >> +
> >> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >> +
> >> +#include <linux/kernel.h>
> >> +#include <linux/module.h>
> >> +#include <linux/init.h>
> >> +#include <linux/notifier.h>
> >> +#include <linux/types.h>
> >> +#include <linux/slab.h>
> >> +#include <linux/mutex.h>
> >> +#include <linux/irq.h>
> >> +#include <linux/workqueue.h>
> >> +#include <linux/cpufreq.h>
> >> +
> >> +#include <trace/events/power.h>
> >> +
> >> +#include <xen/xen.h>
> >> +#include <xen/events.h>
> >> +#include <xen/interface/xen.h>
> >> +#include <xen/interface/platform.h>
> >> +#include <xen/interface/sysctl.h>
> >> +#include <asm/xen/hypercall.h>
> >> +#include <asm/xen/hypervisor.h>
> >> +
> >> +#include "cpufreq_drv_ops.h"
> >> +
> >> +static int xen_nr_cpus;
> >> +static int xen_irq;
> >> +
> >> +#define for_each_xen_cpu(cpu, mask)                  \
> >> +     for ((cpu) = -1;                                \
> >> +             (cpu) = cpumask_next((cpu), (mask)),    \
> >> +             (cpu) < xen_nr_cpus;)
> >> +
> >> +static struct cpufreq_driver *cpufreq_driver;
> >> +static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
> >> +
> >> +static DEFINE_SPINLOCK(cpufreq_driver_lock);
> >> +
> >> +/*
> >> + * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
> >> + * all cpufreq/hotplug/workqueue/etc related lock issues.
> >> + *
> >> + * The rules for this semaphore:
> >> + * - Any routine that wants to read from the policy structure will
> >> + *   do a down_read on this semaphore.
> >> + * - Any routine that will write to the policy structure and/or may take away
> >> + *   the policy altogether (eg. CPU hotplug), will hold this lock in write
> >> + *   mode before doing so.
> >> + *
> >> + * Additional rules:
> >> + * - Governor routines that can be called in cpufreq hotplug path should not
> >> + *   take this sem as top level hotplug notifier handler takes this.
> >> + * - Lock should not be held across
> >> + *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
> >> + */
> >> +static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
> >> +static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
> >> +
> >> +#define lock_policy_rwsem(mode, cpu)                         \
> >> +static int lock_policy_rwsem_##mode                          \
> >> +(int cpu)                                                    \
> >> +{                                                            \
> >> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);      \
> >> +     BUG_ON(policy_cpu == -1);                               \
> >> +     down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));    \
> >> +                                                             \
> >> +     return 0;                                               \
> >> +}
> >> +
> >> +lock_policy_rwsem(write, cpu);
> >> +
> >> +static void unlock_policy_rwsem_write(int cpu)
> >> +{
> >> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
> >> +     BUG_ON(policy_cpu == -1);
> >> +     up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
> >> +}
> >> +
> >> +/**
> >> + * The "transition" notifier list for kernel code that needs to handle
> >> + * changes to devices when the CPU clock speed changes.
> >> + * The mutex locks this list.
> >> + */
> >> +static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
> >> +
> >> +static bool init_cpufreq_transition_notifier_list_called;
> >> +static int __init init_cpufreq_transition_notifier_list(void)
> >> +{
> >> +     srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
> >> +     init_cpufreq_transition_notifier_list_called = true;
> >> +     return 0;
> >> +}
> >> +pure_initcall(init_cpufreq_transition_notifier_list);
> >> +
> >> +static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
> >> +{
> >> +     struct cpufreq_policy *data = NULL;
> >> +     unsigned long flags;
> >> +
> >> +     if (cpu >= xen_nr_cpus)
> >> +             goto err_out;
> >> +
> >> +     /* get the cpufreq driver */
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +
> >> +     if (!cpufreq_driver)
> >> +             goto err_out_unlock;
> >> +
> >> +     /* get the CPU */
> >> +     data = per_cpu(cpufreq_cpu_data, cpu);
> >> +
> >> +err_out_unlock:
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +err_out:
> >> +     return data;
> >> +}
> >> +
> >> +static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
> >> +{
> >> +     module_put(cpufreq_driver->owner);
> >> +}
> >> +
> >> +static int push_data_to_hypervisor(struct cpufreq_policy *policy,
> >> +                                struct cpufreq_frequency_table *table)
> >> +{
> >> +     int ret = 0;
> >> +     unsigned int i;
> >> +     unsigned int cpu;
> >> +     uint32_t platform_limit = 0;
> >> +     unsigned int max_freq = 0;
> >> +     unsigned int state_count = 0;
> >> +     unsigned int prev_freq = 0;
> >> +     struct xen_processor_px *dst_states;
> >> +     struct xen_processor_performance *dst_perf;
> >> +     struct xen_platform_op op = {
> >> +             .cmd                    = XENPF_set_processor_pminfo,
> >> +             .interface_version      = XENPF_INTERFACE_VERSION,
> >> +             .u.set_pminfo.type      = XEN_PM_PX,
> >> +     };
> >> +
> >> +     dst_perf = &op.u.set_pminfo.perf;
> >> +
> >> +     /* Check freq table and find max frequency */
> >> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> >> +             unsigned int freq = table[i].frequency;
> >> +             if (freq == CPUFREQ_ENTRY_INVALID)
> >> +                     continue;
> >> +
> >> +             if (table[i].index != state_count || freq <= prev_freq) {
> >> +                     pr_err("Frequency table format error\n");
> >> +                     return -EINVAL;
> >> +             }
> >> +
> >> +             prev_freq = freq;
> >> +             state_count++;
> >> +             if (freq > max_freq)
> >> +                     max_freq = freq;
> >> +     }
> >> +
> >> +     if (!state_count)
> >> +             return -EINVAL;
> >> +
> >> +     dst_perf->state_count = state_count;
> >> +
> >> +     dst_states = kcalloc(state_count,
> >> +                          sizeof(struct xen_processor_px), GFP_KERNEL);
> >> +
> >> +     if (!dst_states)
> >> +             return -ENOMEM;
> >> +
> >> +     set_xen_guest_handle(dst_perf->states, dst_states);
> >> +
> >> +     /*
> >> +      * Freq table should start from lower values
> >> +      * dst_states should start from higer values
> >> +      */
> >> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> >> +             unsigned int freq = table[i].frequency;
> >> +             unsigned int tbl_index = state_count - 1 - table[i].index;
> >> +             if (freq == CPUFREQ_ENTRY_INVALID)
> >> +                     continue;
> >> +
> >> +             if (freq == max_freq)
> >> +                     platform_limit = tbl_index;
> >> +
> >> +             dst_states[tbl_index].core_frequency = freq / 1000;
> >> +             dst_states[tbl_index].transition_latency =
> >> +                             policy->cpuinfo.transition_latency / 1000;
> >> +     }
> >> +
> >> +     dst_perf->shared_type = policy->shared_type;
> >> +     dst_perf->platform_limit = platform_limit;
> >> +     dst_perf->domain_info.domain = policy->cpu;
> >> +     dst_perf->domain_info.num_processors = xen_nr_cpus;
> >> +     dst_perf->flags = XEN_PX_DATA;
> >> +
> >> +     for_each_xen_cpu(cpu, policy->cpus) {
> >> +             op.u.set_pminfo.id = cpu;
> >> +             ret = HYPERVISOR_dom0_op(&op);
> >> +             if (ret) {
> >> +                     pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
> >> +                     goto err_free_states;
> >> +             }
> >> +             pr_debug("CPU%u - P-states uploaded\n", cpu);
> >> +
> >> +             for (i = 0; i < dst_perf->state_count; i++) {
> >> +                     pr_debug("    state %d: %d MHz, %d uS\n",
> >> +                              i, (u32) dst_states[i].core_frequency,
> >> +                              (u32) dst_states[i].transition_latency);
> >> +             }
> >> +     }
> >> +
> >> +err_free_states:
> >> +     kfree(dst_states);
> >> +     return ret;
> >> +}
> >> +
> >> +/*
> >> + * Returns:
> >> + *   Negative: Failure
> >> + *   0:        Success
> >> + *   Positive: When we have a managed CPU and the sysfs got symlinked
> >> + */
> >> +static int xen_cpufreq_add_dev_policy(unsigned int cpu,
> >> +                               struct cpufreq_policy *policy)
> >> +{
> >> +     int ret = 0;
> >> +#ifdef CONFIG_SMP
> >> +     unsigned long flags;
> >> +     unsigned int j;
> >> +
> >> +     for_each_cpu(j, policy->cpus) {
> >> +             struct cpufreq_policy *managed_policy;
> >> +
> >> +             if (cpu == j)
> >> +                     continue;
> >> +
> >> +             /* Check for existing affected CPUs.
> >> +              * They may not be aware of it due to CPU Hotplug.
> >> +              * cpufreq_cpu_put is called when the device is removed
> >> +              * in __cpufreq_remove_dev()
> >> +              */
> >> +             managed_policy = xen_cpufreq_cpu_get(j);
> >> +             if (unlikely(managed_policy)) {
> >> +                     /* Set proper policy_cpu */
> >> +                     unlock_policy_rwsem_write(cpu);
> >> +                     per_cpu(cpufreq_policy_cpu, cpu) =
> >> +                                             managed_policy->cpu;
> >> +
> >> +                     if (lock_policy_rwsem_write(cpu) < 0) {
> >> +                             /* Should not go through policy unlock path */
> >> +                             if (cpufreq_driver->exit)
> >> +                                     cpufreq_driver->exit(policy);
> >> +                             xen_cpufreq_cpu_put(managed_policy);
> >> +                             return -EBUSY;
> >> +                     }
> >> +
> >> +                     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +                     cpumask_copy(managed_policy->cpus, policy->cpus);
> >> +                     per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
> >> +                     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +
> >> +                     pr_debug("CPU already managed, adding link\n");
> >> +
> >> +                     /*
> >> +                      * Success. We only needed to be added to the mask.
> >> +                      * Call driver->exit() because only the cpu parent of
> >> +                      * the kobj needed to call init().
> >> +                      */
> >> +                     if (cpufreq_driver->exit)
> >> +                             cpufreq_driver->exit(policy);
> >> +
> >> +                     return 1;
> >> +             }
> >> +     }
> >> +#endif
> >> +     return ret;
> >> +}
> >> +
> >> +/**
> >> + * xen_cpufreq_add_dev - add a CPU device
> >> + *
> >> + * Adds the cpufreq interface for a CPU device.
> >> + */
> >> +static int xen_cpufreq_add_dev(unsigned int cpu)
> >> +{
> >> +     int ret = 0;
> >> +     struct cpufreq_policy *policy;
> >> +     unsigned long flags;
> >> +     unsigned int j;
> >> +
> >> +     pr_debug("adding CPU %u\n", cpu);
> >> +
> >> +#ifdef CONFIG_SMP
> >> +     /* check whether a different CPU already registered this
> >> +      * CPU because it is in the same boat. */
> >> +     policy = xen_cpufreq_cpu_get(cpu);
> >> +     if (unlikely(policy)) {
> >> +             xen_cpufreq_cpu_put(policy);
> >> +             return 0;
> >> +     }
> >> +#endif
> >> +
> >> +     if (!try_module_get(cpufreq_driver->owner)) {
> >> +             ret = -EINVAL;
> >> +             goto module_out;
> >> +     }
> >> +
> >> +     ret = -ENOMEM;
> >> +     policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
> >> +     if (!policy)
> >> +             goto nomem_out;
> >> +
> >> +     if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
> >> +             goto err_free_policy;
> >> +
> >> +     if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
> >> +             goto err_free_cpumask;
> >> +
> >> +     policy->cpu = cpu;
> >> +     cpumask_copy(policy->cpus, cpumask_of(cpu));
> >> +
> >> +     /* Initially set CPU itself as the policy_cpu */
> >> +     per_cpu(cpufreq_policy_cpu, cpu) = cpu;
> >> +     ret = (lock_policy_rwsem_write(cpu) < 0);
> >> +     WARN_ON(ret);
> >> +
> >> +     /* call driver. From then on the cpufreq must be able
> >> +      * to accept all calls to ->verify and ->setpolicy for this CPU
> >> +      */
> >> +     ret = cpufreq_driver->init(policy);
> >> +     if (ret) {
> >> +             pr_debug("initialization failed\n");
> >> +             goto err_unlock_policy;
> >> +     }
> >> +     ret = xen_cpufreq_add_dev_policy(cpu, policy);
> >> +     if (ret) {
> >> +             if (ret > 0)
> >> +                     /* This is a managed cpu, symlink created,
> >> +                        exit with 0 */
> >> +                     ret = 0;
> >> +             goto err_unlock_policy;
> >> +     }
> >> +
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +     for_each_cpu(j, policy->cpus) {
> >> +             per_cpu(cpufreq_cpu_data, j) = policy;
> >> +             per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
> >> +     }
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +
> >> +     unlock_policy_rwsem_write(cpu);
> >> +
> >> +     module_put(cpufreq_driver->owner);
> >> +     pr_debug("initialization complete\n");
> >> +
> >> +     return 0;
> >> +
> >> +err_unlock_policy:
> >> +     unlock_policy_rwsem_write(cpu);
> >> +     free_cpumask_var(policy->related_cpus);
> >> +err_free_cpumask:
> >> +     free_cpumask_var(policy->cpus);
> >> +err_free_policy:
> >> +     kfree(policy);
> >> +nomem_out:
> >> +     module_put(cpufreq_driver->owner);
> >> +module_out:
> >> +     return ret;
> >> +}
> >> +
> >> +/**
> >> + * __cpufreq_remove_dev - remove a CPU device
> >> + *
> >> + * Removes the cpufreq interface for a CPU device.
> >> + * Caller should already have policy_rwsem in write mode for this CPU.
> >> + * This routine frees the rwsem before returning.
> >> + */
> >> +static int __cpufreq_remove_dev(unsigned int cpu)
> >> +{
> >> +     unsigned long flags;
> >> +     struct cpufreq_policy *data;
> >> +#ifdef CONFIG_SMP
> >> +     unsigned int j;
> >> +#endif
> >> +
> >> +     pr_debug("unregistering CPU %u\n", cpu);
> >> +
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +     data = per_cpu(cpufreq_cpu_data, cpu);
> >> +
> >> +     if (!data) {
> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +             unlock_policy_rwsem_write(cpu);
> >> +             return -EINVAL;
> >> +     }
> >> +     per_cpu(cpufreq_cpu_data, cpu) = NULL;
> >> +
> >> +
> >> +#ifdef CONFIG_SMP
> >> +     /* if this isn't the CPU which is the parent of the kobj, we
> >> +      * only need to unlink, put and exit
> >> +      */
> >> +     if (unlikely(cpu != data->cpu)) {
> >> +             pr_debug("removing link\n");
> >> +             cpumask_clear_cpu(cpu, data->cpus);
> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +             xen_cpufreq_cpu_put(data);
> >> +             unlock_policy_rwsem_write(cpu);
> >> +             return 0;
> >> +     }
> >> +#endif
> >> +
> >> +#ifdef CONFIG_SMP
> >> +
> >> +     /* if we have other CPUs still registered, we need to unlink them,
> >> +      * or else wait_for_completion below will lock up. Clean the
> >> +      * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
> >> +      * the sysfs links afterwards.
> >> +      */
> >> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
> >> +             for_each_cpu(j, data->cpus) {
> >> +                     if (j == cpu)
> >> +                             continue;
> >> +                     per_cpu(cpufreq_cpu_data, j) = NULL;
> >> +             }
> >> +     }
> >> +
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +
> >> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
> >> +             for_each_cpu(j, data->cpus) {
> >> +                     if (j == cpu)
> >> +                             continue;
> >> +                     pr_debug("removing link for cpu %u\n", j);
> >> +                     unlock_policy_rwsem_write(cpu);
> >> +                     lock_policy_rwsem_write(cpu);
> >> +                     xen_cpufreq_cpu_put(data);
> >> +             }
> >> +     }
> >> +#else
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +#endif
> >> +
> >> +     unlock_policy_rwsem_write(cpu);
> >> +
> >> +     lock_policy_rwsem_write(cpu);
> >> +     if (cpufreq_driver->exit)
> >> +             cpufreq_driver->exit(data);
> >> +     unlock_policy_rwsem_write(cpu);
> >> +
> >> +     free_cpumask_var(data->related_cpus);
> >> +     free_cpumask_var(data->cpus);
> >> +     kfree(data);
> >> +
> >> +     return 0;
> >> +}
> >> +
> >> +static int cpufreq_remove_dev(unsigned int cpu)
> >> +{
> >> +     int retval;
> >> +
> >> +     if (unlikely(lock_policy_rwsem_write(cpu)))
> >> +             BUG();
> >> +
> >> +     retval = __cpufreq_remove_dev(cpu);
> >> +     return retval;
> >> +}
> >> +
> >> +/*********************************************************************
> >> + *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
> >> + *********************************************************************/
> >> +
> >> +/**
> >> + * adjust_jiffies - adjust the system "loops_per_jiffy"
> >> + *
> >> + * This function alters the system "loops_per_jiffy" for the clock
> >> + * speed change. Note that loops_per_jiffy cannot be updated on SMP
> >> + * systems as each CPU might be scaled differently. So, use the arch
> >> + * per-CPU loops_per_jiffy value wherever possible.
> >> + */
> >> +#ifndef CONFIG_SMP
> >> +static unsigned long l_p_j_ref;
> >> +static unsigned int  l_p_j_ref_freq;
> >> +
> >> +static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
> >> +{
> >> +     if (ci->flags & CPUFREQ_CONST_LOOPS)
> >> +             return;
> >> +
> >> +     if (!l_p_j_ref_freq) {
> >> +             l_p_j_ref = loops_per_jiffy;
> >> +             l_p_j_ref_freq = ci->old;
> >> +             pr_debug("saving %lu as reference value for loops_per_jiffy; "
> >> +                     "freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
> >> +     }
> >> +     if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
> >> +         (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
> >> +             loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
> >> +                                                             ci->new);
> >> +             pr_debug("scaling loops_per_jiffy to %lu "
> >> +                     "for frequency %u kHz\n", loops_per_jiffy, ci->new);
> >> +     }
> >> +}
> >> +#else
> >> +static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
> >> +{
> >> +     return;
> >> +}
> >> +#endif
> >
> > There is quite a lot of code duplication with cpufreq.c, I don't think
> > that is going to be acceptable for the upstream maintainers.
> It is very complicated to use an common code. Some functions copied
> and modified. I'll try to do something in the future.
> 
> >> +/**
> >> + * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
> >> + * on frequency transition.
> >> + *
> >> + * This function calls the transition notifiers and the "adjust_jiffies"
> >> + * function. It is called twice on all CPU frequency changes that have
> >> + * external effects.
> >> + */
> >> +void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
> >> +                                unsigned int state)
> >> +{
> >> +     struct cpufreq_policy *policy;
> >> +
> >> +     BUG_ON(irqs_disabled());
> >> +
> >> +     freqs->flags = cpufreq_driver->flags;
> >> +     pr_debug("notification %u of frequency transition to %u kHz\n",
> >> +              state, freqs->new);
> >> +
> >> +     policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
> >> +     switch (state) {
> >> +     case CPUFREQ_PRECHANGE:
> >> +             /* detect if the driver reported a value as "old frequency"
> >> +              * which is not equal to what the cpufreq core thinks is
> >> +              * "old frequency".
> >> +              */
> >> +             if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
> >> +                     if ((policy) && (policy->cpu == freqs->cpu) &&
> >> +                         (policy->cur) && (policy->cur != freqs->old)) {
> >> +                             pr_debug("Warning: CPU frequency is"
> >> +                                      " %u, cpufreq assumed %u kHz.\n",
> >> +                                      freqs->old, policy->cur);
> >> +                             freqs->old = policy->cur;
> >> +                     }
> >> +             }
> >> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
> >> +                                      CPUFREQ_PRECHANGE, freqs);
> >> +             adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
> >> +             break;
> >> +
> >> +     case CPUFREQ_POSTCHANGE:
> >> +             adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
> >> +             pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
> >> +                      (unsigned long)freqs->cpu);
> >> +             trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
> >> +             trace_cpu_frequency(freqs->new, freqs->cpu);
> >> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
> >> +                                      CPUFREQ_POSTCHANGE, freqs);
> >> +             if (likely(policy) && likely(policy->cpu == freqs->cpu))
> >> +                     policy->cur = freqs->new;
> >> +             break;
> >> +     }
> >> +}
> >> +
> >> +/*********************************************************************
> >> + *                              GOVERNORS                            *
> >> + *********************************************************************/
> >> +
> >> +int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
> >> +                             unsigned int target_freq,
> >> +                             unsigned int relation)
> >> +{
> >> +     int retval = -EINVAL;
> >> +     unsigned int old_target_freq = target_freq;
> >> +
> >> +     /* Make sure that target_freq is within supported range */
> >> +     if (target_freq > policy->max)
> >> +             target_freq = policy->max;
> >> +     if (target_freq < policy->min)
> >> +             target_freq = policy->min;
> >> +
> >> +     pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
> >> +              policy->cpu, target_freq, relation, old_target_freq);
> >> +
> >> +     if (target_freq == policy->cur)
> >> +             return 0;
> >> +
> >> +     if (cpufreq_driver->target)
> >> +             retval = cpufreq_driver->target(policy, target_freq,
> >> +                                                 relation);
> >> +
> >> +     return retval;
> >> +}
> >> +
> >> +int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
> >> +                           unsigned int target_freq,
> >> +                           unsigned int relation)
> >> +{
> >> +     int ret = -EINVAL;
> >> +
> >> +     if (!policy)
> >> +             goto no_policy;
> >> +
> >> +     if (unlikely(lock_policy_rwsem_write(policy->cpu)))
> >> +             goto fail;
> >> +
> >> +     ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
> >> +
> >> +     unlock_policy_rwsem_write(policy->cpu);
> >> +
> >> +fail:
> >> +     xen_cpufreq_cpu_put(policy);
> >> +no_policy:
> >> +     return ret;
> >> +}
> >> +
> >> +/*********************************************************************
> >> + *                    HANDLE COMMANDS FROM XEN                       *
> >> + *********************************************************************/
> >> +static void cpufreq_work_hnd(struct work_struct *w);
> >> +
> >> +static struct workqueue_struct *cpufreq_wq;
> >> +static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
> >> +
> >> +static void cpufreq_work_hnd(struct work_struct *w)
> >> +{
> >> +     int ret;
> >> +     struct cpufreq_policy *policy;
> >> +     struct cpufreq_sh_info *cpufreq_info;
> >> +
> >> +     cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
> >> +
> >> +     policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
> >> +     ret = xen_cpufreq_driver_target(policy,
> >> +                                     cpufreq_info->freq,
> >> +                                     cpufreq_info->relation);
> >> +
> >> +     cpufreq_info->result = ret;
> >> +}
> >
> > No barriers? No locking?
> I'll add barriers in the next patch-set.
> 
> >> +static irqreturn_t cpufreq_interrupt(int irq, void *data)
> >> +{
> >> +     queue_work(cpufreq_wq, &cpufreq_work);
> >> +     return IRQ_HANDLED;
> >> +}
> >> +
> >> +/*********************************************************************
> >> + *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
> >> + *********************************************************************/
> >> +
> >> +/**
> >> + * xen_cpufreq_register_driver - register a CPU Frequency driver
> >> + * @driver_data: A struct cpufreq_driver containing the values#
> >> + * submitted by the CPU Frequency driver.
> >> + *
> >> + *   Registers a CPU Frequency driver to this core code. This code
> >> + * returns zero on success, -EBUSY when another driver got here first
> >> + * (and isn't unregistered in the meantime).
> >> + *
> >> + */
> >> +int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
> >> +{
> >> +     unsigned long flags;
> >> +     int ret;
> >> +     unsigned int cpu;
> >> +     struct cpufreq_frequency_table *table;
> >> +     struct cpufreq_policy *policy;
> >> +     cpumask_var_t pushed_cpus;
> >> +     int irq;
> >> +
> >> +     if (!xen_nr_cpus)
> >> +             return -EPROBE_DEFER;
> >> +
> >> +     if (!driver_data || !driver_data->verify || !driver_data->init ||
> >> +         (!driver_data->target))
> >> +             return -EINVAL;
> >> +
> >> +     pr_debug("trying to register driver %s\n", driver_data->name);
> >> +
> >> +     if (driver_data->setpolicy)
> >> +             driver_data->flags |= CPUFREQ_CONST_LOOPS;
> >> +
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +
> >> +     if (cpufreq_driver) {
> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +             return -EBUSY;
> >> +     }
> >> +     cpufreq_driver = driver_data;
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +
> >> +     irq = bind_virq_to_irq(VIRQ_CPUFREQ, 0);
> >> +     if (irq < 0) {
> >> +             pr_err("Bind virq (%d) error (%d)\n", VIRQ_CPUFREQ, irq);
> >> +             ret = irq;
> >> +             goto err_remove_drv;
> >> +     }
> >> +
> >> +     irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN|IRQ_NOPROBE);
> >> +
> >> +     ret = request_irq(irq, cpufreq_interrupt, 0,
> >> +                        "xen_cpufreq", NULL);
> >> +
> >> +     if (ret < 0) {
> >> +             pr_err("Request irq (%d) error (%d)\n", irq, ret);
> >> +             goto err_unbind_from_irqhnd;
> >> +     }
> >> +
> >> +     xen_irq = irq;
> >> +
> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
> >> +             ret = xen_cpufreq_add_dev(cpu);
> >> +             if (ret)
> >> +                     goto err_remove_cpu;
> >> +     }
> >> +
> >> +     if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
> >> +             goto err_remove_cpu;
> >> +
> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
> >> +             if (cpumask_test_cpu(cpu, pushed_cpus))
> >> +                     continue;
> >> +
> >> +             policy = xen_cpufreq_cpu_get(cpu);
> >> +             if (!policy) {
> >> +                     ret = -EINVAL;
> >> +                     goto err_free_cpumask;
> >> +             }
> >> +
> >> +             cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
> >> +             table = cpufreq_frequency_get_table(policy->cpu);
> >> +             if (!table) {
> >> +                     ret = -EINVAL;
> >> +                     goto err_free_cpumask;
> >> +             }
> >> +
> >> +             ret = push_data_to_hypervisor(policy, table);
> >> +             if (ret)
> >> +                     goto err_free_cpumask;
> >> +     }
> >> +
> >> +     free_cpumask_var(pushed_cpus);
> >> +
> >> +     pr_debug("driver %s up and running\n", driver_data->name);
> >> +
> >> +     return 0;
> >> +
> >> +err_free_cpumask:
> >> +     free_cpumask_var(pushed_cpus);
> >> +err_remove_cpu:
> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
> >> +             cpufreq_remove_dev(cpu);
> >> +err_unbind_from_irqhnd:
> >> +     unbind_from_irqhandler(irq, NULL);
> >> +err_remove_drv:
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +     cpufreq_driver = NULL;
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +     return ret;
> >> +}
> >> +
> >> +/**
> >> + * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
> >> + *
> >> + *    Unregister the current CPUFreq driver. Only call this if you have
> >> + * the right to do so, i.e. if you have succeeded in initialising before!
> >> + * Returns zero if successful, and -EINVAL if the cpufreq_driver is
> >> + * currently not initialised.
> >> + */
> >> +int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
> >> +{
> >> +     unsigned long flags;
> >> +     unsigned int cpu;
> >> +
> >> +     if (!cpufreq_driver || (driver != cpufreq_driver))
> >> +             return -EINVAL;
> >> +
> >> +     pr_debug("unregistering driver %s\n", driver->name);
> >> +
> >> +     unbind_from_irqhandler(xen_irq, NULL);
> >> +
> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
> >> +             cpufreq_remove_dev(cpu);
> >> +
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +     cpufreq_driver = NULL;
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +
> >> +     return 0;
> >> +}
> >> +
> >> +struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
> >> +     .notify_transition = xen_cpufreq_notify_transition,
> >> +     .register_driver = xen_cpufreq_register_driver,
> >> +     .unregister_driver = xen_cpufreq_unregister_driver,
> >> +};
> >> +
> >> +static int __init xen_cpufreq_init(void)
> >> +{
> >> +     int ret;
> >> +     int i;
> >> +
> >> +     struct xen_sysctl op = {
> >> +             .cmd                    = XEN_SYSCTL_physinfo,
> >> +             .interface_version      = XEN_SYSCTL_INTERFACE_VERSION,
> >> +     };
> >> +
> >> +     ret = HYPERVISOR_sysctl(&op);
> >> +     if (ret) {
> >> +             pr_err("Hypervisor get physinfo error (%d)\n", ret);
> >> +             return ret;
> >> +     }
> >> +
> >> +     xen_nr_cpus = op.u.physinfo.nr_cpus;
> >> +     if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
> >> +             xen_nr_cpus = 0;
> >> +             pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
> >> +             return -EINVAL;
> >> +     }
> >> +
> >> +     for (i = 0; i < xen_nr_cpus; i++) {
> >> +             per_cpu(cpufreq_policy_cpu, i) = -1;
> >> +             init_rwsem(&per_cpu(cpu_policy_rwsem, i));
> >> +     }
> >> +
> >> +     cpufreq_wq = alloc_workqueue("xen_cpufreq", 0, 1);
> >> +     if (!cpufreq_wq) {
> >> +             pr_err("Create workqueue error\n");
> >> +             ret = -ENOMEM;
> >> +             goto err_create_wq;
> >> +     }
> >> +
> >> +     return 0;
> >> +
> >> +err_create_wq:
> >> +     xen_nr_cpus = 0;
> >> +     return ret;
> >> +}
> >> +
> >> +MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
> >> +MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
> >> +MODULE_LICENSE("GPL");
> >> +
> >> +core_initcall(xen_cpufreq_init);
> >> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> >> index c57d5f6..ee3b154 100644
> >> --- a/include/xen/interface/platform.h
> >> +++ b/include/xen/interface/platform.h
> >> @@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
> >>  #define XEN_PX_PSS   2
> >>  #define XEN_PX_PPC   4
> >>  #define XEN_PX_PSD   8
> >> +#define XEN_PX_DATA  16
> >>
> >>  struct xen_power_register {
> >>       uint32_t     space_id;
> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> >> index cf64566..9133110 100644
> >> --- a/include/xen/interface/xen.h
> >> +++ b/include/xen/interface/xen.h
> >> @@ -81,6 +81,7 @@
> >>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
> >>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
> >>  #define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
> >> +#define VIRQ_CPUFREQ    14 /* (DOM0) Notify cpufreq driver                */
> >>
> >>  /* 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 Nov 06 15:23:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOu3-0004Uu-QV; Thu, 06 Nov 2014 15:23:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmOu2-0004Ui-1t
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:23:14 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	47/D2-02696-1629B545; Thu, 06 Nov 2014 15:23:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415287390!8521830!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13028 invoked from network); 6 Nov 2014 15:23:11 -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;
	6 Nov 2014 15:23:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188796009"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:20:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOrR-0000g2-8k;
	Thu, 06 Nov 2014 15:20:33 +0000
Date: Thu, 6 Nov 2014 15:20:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jivYZMgVuhNNtj6Ks05h1iSZBeihKzqcEGi2wp41T4TxyA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061518510.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041621380.22875@kaball.uk.xensource.com>
	<CAN58jivYZMgVuhNNtj6Ks05h1iSZBeihKzqcEGi2wp41T4TxyA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v4 9/9] xen/arm: cpufreq: add
	xen-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Tue, Nov 4, 2014 at 6:33 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> Xen changes frequencies on CPUs using this high-level
> >> cpufreq driver.
> >>
> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >
> > You CC the wrong email address for Rafael in the entire series.
> Could anybody give me right address for Rafael?

rjw@rjwysocki.net

You can also find it by running ./scripts/get_maintainer.pl on the
patch:

sstabellini@st22:/local/scratch/sstabellini/linux-pvops-latest$ ./scripts/get_maintainer.pl ~/patch
"Rafael J. Wysocki" <rjw@rjwysocki.net> (maintainer:CPU FREQUENCY DRI...)
Viresh Kumar <viresh.kumar@linaro.org> (maintainer:CPU FREQUENCY DRI...)
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/3=33%)
Boris Ostrovsky <boris.ostrovsky@oracle.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/3=33%)
David Vrabel <david.vrabel@citrix.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/1=100%,commit_signer:3/3=100%,authored:1/3=33%,removed_lines:6/33=18%)
Stefano Stabellini <stefano.stabellini@eu.citrix.com> (commit_signer:1/1=100%)
Tang Liang <liang.tang@oracle.com> (commit_signer:1/1=100%)
Daniel Kiper <daniel.kiper@oracle.com> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:123/123=100%)
Jan Beulich <jbeulich@suse.com> (commit_signer:1/1=100%)
Ian Campbell <ian.campbell@citrix.com> (commit_signer:1/3=33%,authored:1/3=33%,removed_lines:3/33=9%)
Juergen Gross <jgross@suse.com> (commit_signer:1/3=33%,authored:1/3=33%,added_lines:248/251=99%,removed_lines:24/33=73%)
linux-kernel@vger.kernel.org (open list)
linux-pm@vger.kernel.org (open list:CPU FREQUENCY DRI...)
xen-devel@lists.xenproject.org (moderated list:XEN HYPERVISOR IN...)



> >>  drivers/cpufreq/Kconfig           |  20 +
> >>  drivers/cpufreq/Makefile          |   1 +
> >>  drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
> >>  drivers/cpufreq/cpufreq_drv_ops.h |   4 +
> >>  drivers/cpufreq/xen-cpufreq.c     | 869 ++++++++++++++++++++++++++++++++++++++
> >>  include/xen/interface/platform.h  |   1 +
> >>  include/xen/interface/xen.h       |   1 +
> >>  7 files changed, 907 insertions(+), 2 deletions(-)
> >>  create mode 100644 drivers/cpufreq/xen-cpufreq.c
> >>
> >> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> >> index f5a8f84..4847d8a 100644
> >> --- a/drivers/cpufreq/Kconfig
> >> +++ b/drivers/cpufreq/Kconfig
> >> @@ -19,6 +19,26 @@ config CPU_FREQ
> >>
> >>         If in doubt, say N.
> >>
> >> +config XEN_CPUFREQ
> >> +     bool "Xen Cpufreq driver"
> >> +     depends on XEN_DOM0
> >> +     depends on !CPUMASK_OFFSTACK
> >> +     default n
> >> +     select CPUFREQ_DRV_OPS
> >> +     help
> >> +       This driver uploads Power Management information to the Xen
> >> +       hypervisor and changes CPUs frequency using CPU Frequency scaling
> >> +       drivers.
> >> +
> >> +       To do that the driver uses CPU Frequency scaling drivers to parse
> >> +       the Power Management data and uploads said information to the Xen
> >> +       hypervisor. Then the Xen hypervisor can select the proper Pxx states.
> >> +
> >> +       Then the Xen hypervisor can change CPUs frequency by giving commands
> >> +       via this driver to the CPU Frequency scaling driver.
> >> +
> >> +       If in doubt, say N.
> >> +
> >>  if CPUFREQ_DRV_OPS
> >>
> >>  config CPU_FREQ_TABLE
> >> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> >> index f12a0d3..c8d5037 100644
> >> --- a/drivers/cpufreq/Makefile
> >> +++ b/drivers/cpufreq/Makefile
> >> @@ -1,5 +1,6 @@
> >>  # CPUfreq core
> >>  obj-$(CONFIG_CPU_FREQ)                       += cpufreq.o
> >> +obj-$(CONFIG_XEN_CPUFREQ)            += xen-cpufreq.o
> >>  obj-$(CONFIG_CPUFREQ_DRV_OPS)                += cpufreq_drv_ops.o
> >>  # CPUfreq stats
> >>  obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
> >> diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
> >> index c971442..71c3357 100644
> >> --- a/drivers/cpufreq/cpufreq_drv_ops.c
> >> +++ b/drivers/cpufreq/cpufreq_drv_ops.c
> >> @@ -18,6 +18,8 @@
> >>  #include <linux/init.h>
> >>  #include <linux/export.h>
> >>
> >> +#include <xen/xen.h>
> >> +
> >>  static struct cpufreq_drv_ops *ops;
> >>
> >>  struct kobject *get_cpufreq_global_kobject(void)
> >> @@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
> >>
> >>  static int __init cpufreq_drv_ops_init(void)
> >>  {
> >> +     if (xen_initial_domain()) {
> >> +#ifdef CONFIG_XEN_CPUFREQ
> >> +             ops = &xen_cpufreq_drv_ops;
> >> +             pr_debug("using xen_cpufreq_drv_ops\n");
> >> +#endif
> >> +     } else {
> >>  #ifdef CONFIG_CPU_FREQ
> >> -     ops = &kern_cpufreq_drv_ops;
> >> -     pr_debug("using kern_cpufreq_drv_ops\n");
> >> +             ops = &kern_cpufreq_drv_ops;
> >> +             pr_debug("using kern_cpufreq_drv_ops\n");
> >>  #endif
> >> +     }
> >>
> >>       return 0;
> >>  }
> >> diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
> >> index 5cc8e05..d02d509 100644
> >> --- a/drivers/cpufreq/cpufreq_drv_ops.h
> >> +++ b/drivers/cpufreq/cpufreq_drv_ops.h
> >> @@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
> >>  extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
> >>  #endif
> >>
> >> +#ifdef CONFIG_XEN_CPUFREQ
> >> +extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
> >> +#endif
> >> +
> >>  #endif /* _CPUFREQ_DRV_OPS_H */
> >> diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
> >> new file mode 100644
> >> index 0000000..21062c7
> >> --- /dev/null
> >> +++ b/drivers/cpufreq/xen-cpufreq.c
> >> @@ -0,0 +1,869 @@
> >> +/*
> >> + *  Copyright (C) 2001 Russell King
> >> + *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
> >> + *
> >> + *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
> >> + *   Added handling for CPU hotplug
> >> + *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
> >> + *   Fix handling for CPU hotplug -- affected CPUs
> >> + *
> >> + *           (C) 2014 GlobalLogic Inc.
> >> + *
> >> + * Based on drivers/cpufreq/cpufreq.c
> >> + *
> >> + * 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.
> >> + */
> >> +
> >> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >> +
> >> +#include <linux/kernel.h>
> >> +#include <linux/module.h>
> >> +#include <linux/init.h>
> >> +#include <linux/notifier.h>
> >> +#include <linux/types.h>
> >> +#include <linux/slab.h>
> >> +#include <linux/mutex.h>
> >> +#include <linux/irq.h>
> >> +#include <linux/workqueue.h>
> >> +#include <linux/cpufreq.h>
> >> +
> >> +#include <trace/events/power.h>
> >> +
> >> +#include <xen/xen.h>
> >> +#include <xen/events.h>
> >> +#include <xen/interface/xen.h>
> >> +#include <xen/interface/platform.h>
> >> +#include <xen/interface/sysctl.h>
> >> +#include <asm/xen/hypercall.h>
> >> +#include <asm/xen/hypervisor.h>
> >> +
> >> +#include "cpufreq_drv_ops.h"
> >> +
> >> +static int xen_nr_cpus;
> >> +static int xen_irq;
> >> +
> >> +#define for_each_xen_cpu(cpu, mask)                  \
> >> +     for ((cpu) = -1;                                \
> >> +             (cpu) = cpumask_next((cpu), (mask)),    \
> >> +             (cpu) < xen_nr_cpus;)
> >> +
> >> +static struct cpufreq_driver *cpufreq_driver;
> >> +static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
> >> +
> >> +static DEFINE_SPINLOCK(cpufreq_driver_lock);
> >> +
> >> +/*
> >> + * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
> >> + * all cpufreq/hotplug/workqueue/etc related lock issues.
> >> + *
> >> + * The rules for this semaphore:
> >> + * - Any routine that wants to read from the policy structure will
> >> + *   do a down_read on this semaphore.
> >> + * - Any routine that will write to the policy structure and/or may take away
> >> + *   the policy altogether (eg. CPU hotplug), will hold this lock in write
> >> + *   mode before doing so.
> >> + *
> >> + * Additional rules:
> >> + * - Governor routines that can be called in cpufreq hotplug path should not
> >> + *   take this sem as top level hotplug notifier handler takes this.
> >> + * - Lock should not be held across
> >> + *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
> >> + */
> >> +static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
> >> +static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
> >> +
> >> +#define lock_policy_rwsem(mode, cpu)                         \
> >> +static int lock_policy_rwsem_##mode                          \
> >> +(int cpu)                                                    \
> >> +{                                                            \
> >> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);      \
> >> +     BUG_ON(policy_cpu == -1);                               \
> >> +     down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));    \
> >> +                                                             \
> >> +     return 0;                                               \
> >> +}
> >> +
> >> +lock_policy_rwsem(write, cpu);
> >> +
> >> +static void unlock_policy_rwsem_write(int cpu)
> >> +{
> >> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
> >> +     BUG_ON(policy_cpu == -1);
> >> +     up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
> >> +}
> >> +
> >> +/**
> >> + * The "transition" notifier list for kernel code that needs to handle
> >> + * changes to devices when the CPU clock speed changes.
> >> + * The mutex locks this list.
> >> + */
> >> +static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
> >> +
> >> +static bool init_cpufreq_transition_notifier_list_called;
> >> +static int __init init_cpufreq_transition_notifier_list(void)
> >> +{
> >> +     srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
> >> +     init_cpufreq_transition_notifier_list_called = true;
> >> +     return 0;
> >> +}
> >> +pure_initcall(init_cpufreq_transition_notifier_list);
> >> +
> >> +static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
> >> +{
> >> +     struct cpufreq_policy *data = NULL;
> >> +     unsigned long flags;
> >> +
> >> +     if (cpu >= xen_nr_cpus)
> >> +             goto err_out;
> >> +
> >> +     /* get the cpufreq driver */
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +
> >> +     if (!cpufreq_driver)
> >> +             goto err_out_unlock;
> >> +
> >> +     /* get the CPU */
> >> +     data = per_cpu(cpufreq_cpu_data, cpu);
> >> +
> >> +err_out_unlock:
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +err_out:
> >> +     return data;
> >> +}
> >> +
> >> +static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
> >> +{
> >> +     module_put(cpufreq_driver->owner);
> >> +}
> >> +
> >> +static int push_data_to_hypervisor(struct cpufreq_policy *policy,
> >> +                                struct cpufreq_frequency_table *table)
> >> +{
> >> +     int ret = 0;
> >> +     unsigned int i;
> >> +     unsigned int cpu;
> >> +     uint32_t platform_limit = 0;
> >> +     unsigned int max_freq = 0;
> >> +     unsigned int state_count = 0;
> >> +     unsigned int prev_freq = 0;
> >> +     struct xen_processor_px *dst_states;
> >> +     struct xen_processor_performance *dst_perf;
> >> +     struct xen_platform_op op = {
> >> +             .cmd                    = XENPF_set_processor_pminfo,
> >> +             .interface_version      = XENPF_INTERFACE_VERSION,
> >> +             .u.set_pminfo.type      = XEN_PM_PX,
> >> +     };
> >> +
> >> +     dst_perf = &op.u.set_pminfo.perf;
> >> +
> >> +     /* Check freq table and find max frequency */
> >> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> >> +             unsigned int freq = table[i].frequency;
> >> +             if (freq == CPUFREQ_ENTRY_INVALID)
> >> +                     continue;
> >> +
> >> +             if (table[i].index != state_count || freq <= prev_freq) {
> >> +                     pr_err("Frequency table format error\n");
> >> +                     return -EINVAL;
> >> +             }
> >> +
> >> +             prev_freq = freq;
> >> +             state_count++;
> >> +             if (freq > max_freq)
> >> +                     max_freq = freq;
> >> +     }
> >> +
> >> +     if (!state_count)
> >> +             return -EINVAL;
> >> +
> >> +     dst_perf->state_count = state_count;
> >> +
> >> +     dst_states = kcalloc(state_count,
> >> +                          sizeof(struct xen_processor_px), GFP_KERNEL);
> >> +
> >> +     if (!dst_states)
> >> +             return -ENOMEM;
> >> +
> >> +     set_xen_guest_handle(dst_perf->states, dst_states);
> >> +
> >> +     /*
> >> +      * Freq table should start from lower values
> >> +      * dst_states should start from higer values
> >> +      */
> >> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> >> +             unsigned int freq = table[i].frequency;
> >> +             unsigned int tbl_index = state_count - 1 - table[i].index;
> >> +             if (freq == CPUFREQ_ENTRY_INVALID)
> >> +                     continue;
> >> +
> >> +             if (freq == max_freq)
> >> +                     platform_limit = tbl_index;
> >> +
> >> +             dst_states[tbl_index].core_frequency = freq / 1000;
> >> +             dst_states[tbl_index].transition_latency =
> >> +                             policy->cpuinfo.transition_latency / 1000;
> >> +     }
> >> +
> >> +     dst_perf->shared_type = policy->shared_type;
> >> +     dst_perf->platform_limit = platform_limit;
> >> +     dst_perf->domain_info.domain = policy->cpu;
> >> +     dst_perf->domain_info.num_processors = xen_nr_cpus;
> >> +     dst_perf->flags = XEN_PX_DATA;
> >> +
> >> +     for_each_xen_cpu(cpu, policy->cpus) {
> >> +             op.u.set_pminfo.id = cpu;
> >> +             ret = HYPERVISOR_dom0_op(&op);
> >> +             if (ret) {
> >> +                     pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
> >> +                     goto err_free_states;
> >> +             }
> >> +             pr_debug("CPU%u - P-states uploaded\n", cpu);
> >> +
> >> +             for (i = 0; i < dst_perf->state_count; i++) {
> >> +                     pr_debug("    state %d: %d MHz, %d uS\n",
> >> +                              i, (u32) dst_states[i].core_frequency,
> >> +                              (u32) dst_states[i].transition_latency);
> >> +             }
> >> +     }
> >> +
> >> +err_free_states:
> >> +     kfree(dst_states);
> >> +     return ret;
> >> +}
> >> +
> >> +/*
> >> + * Returns:
> >> + *   Negative: Failure
> >> + *   0:        Success
> >> + *   Positive: When we have a managed CPU and the sysfs got symlinked
> >> + */
> >> +static int xen_cpufreq_add_dev_policy(unsigned int cpu,
> >> +                               struct cpufreq_policy *policy)
> >> +{
> >> +     int ret = 0;
> >> +#ifdef CONFIG_SMP
> >> +     unsigned long flags;
> >> +     unsigned int j;
> >> +
> >> +     for_each_cpu(j, policy->cpus) {
> >> +             struct cpufreq_policy *managed_policy;
> >> +
> >> +             if (cpu == j)
> >> +                     continue;
> >> +
> >> +             /* Check for existing affected CPUs.
> >> +              * They may not be aware of it due to CPU Hotplug.
> >> +              * cpufreq_cpu_put is called when the device is removed
> >> +              * in __cpufreq_remove_dev()
> >> +              */
> >> +             managed_policy = xen_cpufreq_cpu_get(j);
> >> +             if (unlikely(managed_policy)) {
> >> +                     /* Set proper policy_cpu */
> >> +                     unlock_policy_rwsem_write(cpu);
> >> +                     per_cpu(cpufreq_policy_cpu, cpu) =
> >> +                                             managed_policy->cpu;
> >> +
> >> +                     if (lock_policy_rwsem_write(cpu) < 0) {
> >> +                             /* Should not go through policy unlock path */
> >> +                             if (cpufreq_driver->exit)
> >> +                                     cpufreq_driver->exit(policy);
> >> +                             xen_cpufreq_cpu_put(managed_policy);
> >> +                             return -EBUSY;
> >> +                     }
> >> +
> >> +                     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +                     cpumask_copy(managed_policy->cpus, policy->cpus);
> >> +                     per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
> >> +                     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +
> >> +                     pr_debug("CPU already managed, adding link\n");
> >> +
> >> +                     /*
> >> +                      * Success. We only needed to be added to the mask.
> >> +                      * Call driver->exit() because only the cpu parent of
> >> +                      * the kobj needed to call init().
> >> +                      */
> >> +                     if (cpufreq_driver->exit)
> >> +                             cpufreq_driver->exit(policy);
> >> +
> >> +                     return 1;
> >> +             }
> >> +     }
> >> +#endif
> >> +     return ret;
> >> +}
> >> +
> >> +/**
> >> + * xen_cpufreq_add_dev - add a CPU device
> >> + *
> >> + * Adds the cpufreq interface for a CPU device.
> >> + */
> >> +static int xen_cpufreq_add_dev(unsigned int cpu)
> >> +{
> >> +     int ret = 0;
> >> +     struct cpufreq_policy *policy;
> >> +     unsigned long flags;
> >> +     unsigned int j;
> >> +
> >> +     pr_debug("adding CPU %u\n", cpu);
> >> +
> >> +#ifdef CONFIG_SMP
> >> +     /* check whether a different CPU already registered this
> >> +      * CPU because it is in the same boat. */
> >> +     policy = xen_cpufreq_cpu_get(cpu);
> >> +     if (unlikely(policy)) {
> >> +             xen_cpufreq_cpu_put(policy);
> >> +             return 0;
> >> +     }
> >> +#endif
> >> +
> >> +     if (!try_module_get(cpufreq_driver->owner)) {
> >> +             ret = -EINVAL;
> >> +             goto module_out;
> >> +     }
> >> +
> >> +     ret = -ENOMEM;
> >> +     policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
> >> +     if (!policy)
> >> +             goto nomem_out;
> >> +
> >> +     if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
> >> +             goto err_free_policy;
> >> +
> >> +     if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
> >> +             goto err_free_cpumask;
> >> +
> >> +     policy->cpu = cpu;
> >> +     cpumask_copy(policy->cpus, cpumask_of(cpu));
> >> +
> >> +     /* Initially set CPU itself as the policy_cpu */
> >> +     per_cpu(cpufreq_policy_cpu, cpu) = cpu;
> >> +     ret = (lock_policy_rwsem_write(cpu) < 0);
> >> +     WARN_ON(ret);
> >> +
> >> +     /* call driver. From then on the cpufreq must be able
> >> +      * to accept all calls to ->verify and ->setpolicy for this CPU
> >> +      */
> >> +     ret = cpufreq_driver->init(policy);
> >> +     if (ret) {
> >> +             pr_debug("initialization failed\n");
> >> +             goto err_unlock_policy;
> >> +     }
> >> +     ret = xen_cpufreq_add_dev_policy(cpu, policy);
> >> +     if (ret) {
> >> +             if (ret > 0)
> >> +                     /* This is a managed cpu, symlink created,
> >> +                        exit with 0 */
> >> +                     ret = 0;
> >> +             goto err_unlock_policy;
> >> +     }
> >> +
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +     for_each_cpu(j, policy->cpus) {
> >> +             per_cpu(cpufreq_cpu_data, j) = policy;
> >> +             per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
> >> +     }
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +
> >> +     unlock_policy_rwsem_write(cpu);
> >> +
> >> +     module_put(cpufreq_driver->owner);
> >> +     pr_debug("initialization complete\n");
> >> +
> >> +     return 0;
> >> +
> >> +err_unlock_policy:
> >> +     unlock_policy_rwsem_write(cpu);
> >> +     free_cpumask_var(policy->related_cpus);
> >> +err_free_cpumask:
> >> +     free_cpumask_var(policy->cpus);
> >> +err_free_policy:
> >> +     kfree(policy);
> >> +nomem_out:
> >> +     module_put(cpufreq_driver->owner);
> >> +module_out:
> >> +     return ret;
> >> +}
> >> +
> >> +/**
> >> + * __cpufreq_remove_dev - remove a CPU device
> >> + *
> >> + * Removes the cpufreq interface for a CPU device.
> >> + * Caller should already have policy_rwsem in write mode for this CPU.
> >> + * This routine frees the rwsem before returning.
> >> + */
> >> +static int __cpufreq_remove_dev(unsigned int cpu)
> >> +{
> >> +     unsigned long flags;
> >> +     struct cpufreq_policy *data;
> >> +#ifdef CONFIG_SMP
> >> +     unsigned int j;
> >> +#endif
> >> +
> >> +     pr_debug("unregistering CPU %u\n", cpu);
> >> +
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +     data = per_cpu(cpufreq_cpu_data, cpu);
> >> +
> >> +     if (!data) {
> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +             unlock_policy_rwsem_write(cpu);
> >> +             return -EINVAL;
> >> +     }
> >> +     per_cpu(cpufreq_cpu_data, cpu) = NULL;
> >> +
> >> +
> >> +#ifdef CONFIG_SMP
> >> +     /* if this isn't the CPU which is the parent of the kobj, we
> >> +      * only need to unlink, put and exit
> >> +      */
> >> +     if (unlikely(cpu != data->cpu)) {
> >> +             pr_debug("removing link\n");
> >> +             cpumask_clear_cpu(cpu, data->cpus);
> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +             xen_cpufreq_cpu_put(data);
> >> +             unlock_policy_rwsem_write(cpu);
> >> +             return 0;
> >> +     }
> >> +#endif
> >> +
> >> +#ifdef CONFIG_SMP
> >> +
> >> +     /* if we have other CPUs still registered, we need to unlink them,
> >> +      * or else wait_for_completion below will lock up. Clean the
> >> +      * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
> >> +      * the sysfs links afterwards.
> >> +      */
> >> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
> >> +             for_each_cpu(j, data->cpus) {
> >> +                     if (j == cpu)
> >> +                             continue;
> >> +                     per_cpu(cpufreq_cpu_data, j) = NULL;
> >> +             }
> >> +     }
> >> +
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +
> >> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
> >> +             for_each_cpu(j, data->cpus) {
> >> +                     if (j == cpu)
> >> +                             continue;
> >> +                     pr_debug("removing link for cpu %u\n", j);
> >> +                     unlock_policy_rwsem_write(cpu);
> >> +                     lock_policy_rwsem_write(cpu);
> >> +                     xen_cpufreq_cpu_put(data);
> >> +             }
> >> +     }
> >> +#else
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +#endif
> >> +
> >> +     unlock_policy_rwsem_write(cpu);
> >> +
> >> +     lock_policy_rwsem_write(cpu);
> >> +     if (cpufreq_driver->exit)
> >> +             cpufreq_driver->exit(data);
> >> +     unlock_policy_rwsem_write(cpu);
> >> +
> >> +     free_cpumask_var(data->related_cpus);
> >> +     free_cpumask_var(data->cpus);
> >> +     kfree(data);
> >> +
> >> +     return 0;
> >> +}
> >> +
> >> +static int cpufreq_remove_dev(unsigned int cpu)
> >> +{
> >> +     int retval;
> >> +
> >> +     if (unlikely(lock_policy_rwsem_write(cpu)))
> >> +             BUG();
> >> +
> >> +     retval = __cpufreq_remove_dev(cpu);
> >> +     return retval;
> >> +}
> >> +
> >> +/*********************************************************************
> >> + *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
> >> + *********************************************************************/
> >> +
> >> +/**
> >> + * adjust_jiffies - adjust the system "loops_per_jiffy"
> >> + *
> >> + * This function alters the system "loops_per_jiffy" for the clock
> >> + * speed change. Note that loops_per_jiffy cannot be updated on SMP
> >> + * systems as each CPU might be scaled differently. So, use the arch
> >> + * per-CPU loops_per_jiffy value wherever possible.
> >> + */
> >> +#ifndef CONFIG_SMP
> >> +static unsigned long l_p_j_ref;
> >> +static unsigned int  l_p_j_ref_freq;
> >> +
> >> +static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
> >> +{
> >> +     if (ci->flags & CPUFREQ_CONST_LOOPS)
> >> +             return;
> >> +
> >> +     if (!l_p_j_ref_freq) {
> >> +             l_p_j_ref = loops_per_jiffy;
> >> +             l_p_j_ref_freq = ci->old;
> >> +             pr_debug("saving %lu as reference value for loops_per_jiffy; "
> >> +                     "freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
> >> +     }
> >> +     if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
> >> +         (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
> >> +             loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
> >> +                                                             ci->new);
> >> +             pr_debug("scaling loops_per_jiffy to %lu "
> >> +                     "for frequency %u kHz\n", loops_per_jiffy, ci->new);
> >> +     }
> >> +}
> >> +#else
> >> +static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
> >> +{
> >> +     return;
> >> +}
> >> +#endif
> >
> > There is quite a lot of code duplication with cpufreq.c, I don't think
> > that is going to be acceptable for the upstream maintainers.
> It is very complicated to use an common code. Some functions copied
> and modified. I'll try to do something in the future.
> 
> >> +/**
> >> + * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
> >> + * on frequency transition.
> >> + *
> >> + * This function calls the transition notifiers and the "adjust_jiffies"
> >> + * function. It is called twice on all CPU frequency changes that have
> >> + * external effects.
> >> + */
> >> +void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
> >> +                                unsigned int state)
> >> +{
> >> +     struct cpufreq_policy *policy;
> >> +
> >> +     BUG_ON(irqs_disabled());
> >> +
> >> +     freqs->flags = cpufreq_driver->flags;
> >> +     pr_debug("notification %u of frequency transition to %u kHz\n",
> >> +              state, freqs->new);
> >> +
> >> +     policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
> >> +     switch (state) {
> >> +     case CPUFREQ_PRECHANGE:
> >> +             /* detect if the driver reported a value as "old frequency"
> >> +              * which is not equal to what the cpufreq core thinks is
> >> +              * "old frequency".
> >> +              */
> >> +             if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
> >> +                     if ((policy) && (policy->cpu == freqs->cpu) &&
> >> +                         (policy->cur) && (policy->cur != freqs->old)) {
> >> +                             pr_debug("Warning: CPU frequency is"
> >> +                                      " %u, cpufreq assumed %u kHz.\n",
> >> +                                      freqs->old, policy->cur);
> >> +                             freqs->old = policy->cur;
> >> +                     }
> >> +             }
> >> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
> >> +                                      CPUFREQ_PRECHANGE, freqs);
> >> +             adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
> >> +             break;
> >> +
> >> +     case CPUFREQ_POSTCHANGE:
> >> +             adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
> >> +             pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
> >> +                      (unsigned long)freqs->cpu);
> >> +             trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
> >> +             trace_cpu_frequency(freqs->new, freqs->cpu);
> >> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
> >> +                                      CPUFREQ_POSTCHANGE, freqs);
> >> +             if (likely(policy) && likely(policy->cpu == freqs->cpu))
> >> +                     policy->cur = freqs->new;
> >> +             break;
> >> +     }
> >> +}
> >> +
> >> +/*********************************************************************
> >> + *                              GOVERNORS                            *
> >> + *********************************************************************/
> >> +
> >> +int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
> >> +                             unsigned int target_freq,
> >> +                             unsigned int relation)
> >> +{
> >> +     int retval = -EINVAL;
> >> +     unsigned int old_target_freq = target_freq;
> >> +
> >> +     /* Make sure that target_freq is within supported range */
> >> +     if (target_freq > policy->max)
> >> +             target_freq = policy->max;
> >> +     if (target_freq < policy->min)
> >> +             target_freq = policy->min;
> >> +
> >> +     pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
> >> +              policy->cpu, target_freq, relation, old_target_freq);
> >> +
> >> +     if (target_freq == policy->cur)
> >> +             return 0;
> >> +
> >> +     if (cpufreq_driver->target)
> >> +             retval = cpufreq_driver->target(policy, target_freq,
> >> +                                                 relation);
> >> +
> >> +     return retval;
> >> +}
> >> +
> >> +int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
> >> +                           unsigned int target_freq,
> >> +                           unsigned int relation)
> >> +{
> >> +     int ret = -EINVAL;
> >> +
> >> +     if (!policy)
> >> +             goto no_policy;
> >> +
> >> +     if (unlikely(lock_policy_rwsem_write(policy->cpu)))
> >> +             goto fail;
> >> +
> >> +     ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
> >> +
> >> +     unlock_policy_rwsem_write(policy->cpu);
> >> +
> >> +fail:
> >> +     xen_cpufreq_cpu_put(policy);
> >> +no_policy:
> >> +     return ret;
> >> +}
> >> +
> >> +/*********************************************************************
> >> + *                    HANDLE COMMANDS FROM XEN                       *
> >> + *********************************************************************/
> >> +static void cpufreq_work_hnd(struct work_struct *w);
> >> +
> >> +static struct workqueue_struct *cpufreq_wq;
> >> +static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
> >> +
> >> +static void cpufreq_work_hnd(struct work_struct *w)
> >> +{
> >> +     int ret;
> >> +     struct cpufreq_policy *policy;
> >> +     struct cpufreq_sh_info *cpufreq_info;
> >> +
> >> +     cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
> >> +
> >> +     policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
> >> +     ret = xen_cpufreq_driver_target(policy,
> >> +                                     cpufreq_info->freq,
> >> +                                     cpufreq_info->relation);
> >> +
> >> +     cpufreq_info->result = ret;
> >> +}
> >
> > No barriers? No locking?
> I'll add barriers in the next patch-set.
> 
> >> +static irqreturn_t cpufreq_interrupt(int irq, void *data)
> >> +{
> >> +     queue_work(cpufreq_wq, &cpufreq_work);
> >> +     return IRQ_HANDLED;
> >> +}
> >> +
> >> +/*********************************************************************
> >> + *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
> >> + *********************************************************************/
> >> +
> >> +/**
> >> + * xen_cpufreq_register_driver - register a CPU Frequency driver
> >> + * @driver_data: A struct cpufreq_driver containing the values#
> >> + * submitted by the CPU Frequency driver.
> >> + *
> >> + *   Registers a CPU Frequency driver to this core code. This code
> >> + * returns zero on success, -EBUSY when another driver got here first
> >> + * (and isn't unregistered in the meantime).
> >> + *
> >> + */
> >> +int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
> >> +{
> >> +     unsigned long flags;
> >> +     int ret;
> >> +     unsigned int cpu;
> >> +     struct cpufreq_frequency_table *table;
> >> +     struct cpufreq_policy *policy;
> >> +     cpumask_var_t pushed_cpus;
> >> +     int irq;
> >> +
> >> +     if (!xen_nr_cpus)
> >> +             return -EPROBE_DEFER;
> >> +
> >> +     if (!driver_data || !driver_data->verify || !driver_data->init ||
> >> +         (!driver_data->target))
> >> +             return -EINVAL;
> >> +
> >> +     pr_debug("trying to register driver %s\n", driver_data->name);
> >> +
> >> +     if (driver_data->setpolicy)
> >> +             driver_data->flags |= CPUFREQ_CONST_LOOPS;
> >> +
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +
> >> +     if (cpufreq_driver) {
> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +             return -EBUSY;
> >> +     }
> >> +     cpufreq_driver = driver_data;
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +
> >> +     irq = bind_virq_to_irq(VIRQ_CPUFREQ, 0);
> >> +     if (irq < 0) {
> >> +             pr_err("Bind virq (%d) error (%d)\n", VIRQ_CPUFREQ, irq);
> >> +             ret = irq;
> >> +             goto err_remove_drv;
> >> +     }
> >> +
> >> +     irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN|IRQ_NOPROBE);
> >> +
> >> +     ret = request_irq(irq, cpufreq_interrupt, 0,
> >> +                        "xen_cpufreq", NULL);
> >> +
> >> +     if (ret < 0) {
> >> +             pr_err("Request irq (%d) error (%d)\n", irq, ret);
> >> +             goto err_unbind_from_irqhnd;
> >> +     }
> >> +
> >> +     xen_irq = irq;
> >> +
> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
> >> +             ret = xen_cpufreq_add_dev(cpu);
> >> +             if (ret)
> >> +                     goto err_remove_cpu;
> >> +     }
> >> +
> >> +     if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
> >> +             goto err_remove_cpu;
> >> +
> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
> >> +             if (cpumask_test_cpu(cpu, pushed_cpus))
> >> +                     continue;
> >> +
> >> +             policy = xen_cpufreq_cpu_get(cpu);
> >> +             if (!policy) {
> >> +                     ret = -EINVAL;
> >> +                     goto err_free_cpumask;
> >> +             }
> >> +
> >> +             cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
> >> +             table = cpufreq_frequency_get_table(policy->cpu);
> >> +             if (!table) {
> >> +                     ret = -EINVAL;
> >> +                     goto err_free_cpumask;
> >> +             }
> >> +
> >> +             ret = push_data_to_hypervisor(policy, table);
> >> +             if (ret)
> >> +                     goto err_free_cpumask;
> >> +     }
> >> +
> >> +     free_cpumask_var(pushed_cpus);
> >> +
> >> +     pr_debug("driver %s up and running\n", driver_data->name);
> >> +
> >> +     return 0;
> >> +
> >> +err_free_cpumask:
> >> +     free_cpumask_var(pushed_cpus);
> >> +err_remove_cpu:
> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
> >> +             cpufreq_remove_dev(cpu);
> >> +err_unbind_from_irqhnd:
> >> +     unbind_from_irqhandler(irq, NULL);
> >> +err_remove_drv:
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +     cpufreq_driver = NULL;
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +     return ret;
> >> +}
> >> +
> >> +/**
> >> + * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
> >> + *
> >> + *    Unregister the current CPUFreq driver. Only call this if you have
> >> + * the right to do so, i.e. if you have succeeded in initialising before!
> >> + * Returns zero if successful, and -EINVAL if the cpufreq_driver is
> >> + * currently not initialised.
> >> + */
> >> +int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
> >> +{
> >> +     unsigned long flags;
> >> +     unsigned int cpu;
> >> +
> >> +     if (!cpufreq_driver || (driver != cpufreq_driver))
> >> +             return -EINVAL;
> >> +
> >> +     pr_debug("unregistering driver %s\n", driver->name);
> >> +
> >> +     unbind_from_irqhandler(xen_irq, NULL);
> >> +
> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
> >> +             cpufreq_remove_dev(cpu);
> >> +
> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
> >> +     cpufreq_driver = NULL;
> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> >> +
> >> +     return 0;
> >> +}
> >> +
> >> +struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
> >> +     .notify_transition = xen_cpufreq_notify_transition,
> >> +     .register_driver = xen_cpufreq_register_driver,
> >> +     .unregister_driver = xen_cpufreq_unregister_driver,
> >> +};
> >> +
> >> +static int __init xen_cpufreq_init(void)
> >> +{
> >> +     int ret;
> >> +     int i;
> >> +
> >> +     struct xen_sysctl op = {
> >> +             .cmd                    = XEN_SYSCTL_physinfo,
> >> +             .interface_version      = XEN_SYSCTL_INTERFACE_VERSION,
> >> +     };
> >> +
> >> +     ret = HYPERVISOR_sysctl(&op);
> >> +     if (ret) {
> >> +             pr_err("Hypervisor get physinfo error (%d)\n", ret);
> >> +             return ret;
> >> +     }
> >> +
> >> +     xen_nr_cpus = op.u.physinfo.nr_cpus;
> >> +     if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
> >> +             xen_nr_cpus = 0;
> >> +             pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
> >> +             return -EINVAL;
> >> +     }
> >> +
> >> +     for (i = 0; i < xen_nr_cpus; i++) {
> >> +             per_cpu(cpufreq_policy_cpu, i) = -1;
> >> +             init_rwsem(&per_cpu(cpu_policy_rwsem, i));
> >> +     }
> >> +
> >> +     cpufreq_wq = alloc_workqueue("xen_cpufreq", 0, 1);
> >> +     if (!cpufreq_wq) {
> >> +             pr_err("Create workqueue error\n");
> >> +             ret = -ENOMEM;
> >> +             goto err_create_wq;
> >> +     }
> >> +
> >> +     return 0;
> >> +
> >> +err_create_wq:
> >> +     xen_nr_cpus = 0;
> >> +     return ret;
> >> +}
> >> +
> >> +MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
> >> +MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
> >> +MODULE_LICENSE("GPL");
> >> +
> >> +core_initcall(xen_cpufreq_init);
> >> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> >> index c57d5f6..ee3b154 100644
> >> --- a/include/xen/interface/platform.h
> >> +++ b/include/xen/interface/platform.h
> >> @@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
> >>  #define XEN_PX_PSS   2
> >>  #define XEN_PX_PPC   4
> >>  #define XEN_PX_PSD   8
> >> +#define XEN_PX_DATA  16
> >>
> >>  struct xen_power_register {
> >>       uint32_t     space_id;
> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> >> index cf64566..9133110 100644
> >> --- a/include/xen/interface/xen.h
> >> +++ b/include/xen/interface/xen.h
> >> @@ -81,6 +81,7 @@
> >>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
> >>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
> >>  #define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
> >> +#define VIRQ_CPUFREQ    14 /* (DOM0) Notify cpufreq driver                */
> >>
> >>  /* 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 Nov 06 15:23:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:23:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOuM-0004ZL-E8; Thu, 06 Nov 2014 15:23:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmOuL-0004Z7-PY
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:23:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9A/C9-09842-5729B545; Thu, 06 Nov 2014 15:23:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415287408!11963669!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20818 invoked from network); 6 Nov 2014 15:23:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:23:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190213415"
Message-ID: <545B91D5.8030608@citrix.com>
Date: Thu, 6 Nov 2014 15:20:53 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<545B903F.1090503@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0111465F1@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0111465F1@AMSPEX01CL01.citrite.net>
X-DLP: MIA1
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 15:16, Paul Durrant wrote:
>> -----Original Message-----
>> From: Andrew Cooper
>> Sent: 06 November 2014 15:14
>> To: Paul Durrant; xen-devel@lists.xen.org
>> Cc: Keir (Xen.org); Jan Beulich
>> Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu
>> id
>>
>> On 06/11/14 15:07, Paul Durrant wrote:
>>> To perform certain hypercalls HVM guests need to use Xen's idea of
>>> vcpu id, which may well not match the guest OS idea of CPU id.
>>> This patch adds vcpu id to the HVM cpuid leaf allowing the guest
>>> to build a mapping.
>>>
>>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>> Cc: Keir Fraser <keir@xen.org>
>>> Cc: Jan Beulich <jbeulich@suse.com>
>>> ---
>>>  xen/arch/x86/hvm/hvm.c              |    4 ++++
>>>  xen/include/public/arch-x86/cpuid.h |    5 +++--
>>>  2 files changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>>> index 78f519d..d9a5706 100644
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t
>> sub_idx,
>>>           * foreign pages) has valid IOMMU entries.
>>>           */
>>>          *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
>>> +
>>> +        /* Indicate presence of vcpu id and set it in ebx */
>>> +        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
>>> +        *ebx = current->vcpu_id;
>>>      }
>>>  }
>>>
>>> diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-
>> x86/cpuid.h
>>> index 6005dfe..8ccb6e1 100644
>>> --- a/xen/include/public/arch-x86/cpuid.h
>>> +++ b/xen/include/public/arch-x86/cpuid.h
>>> @@ -76,13 +76,14 @@
>>>  /*
>>>   * Leaf 5 (0x40000x04)
>>>   * HVM-specific features
>>> + * EAX: Features
>>> + * EBX: VCPU ID
>> Probably want "iff EAX & VCPU_ID_PRESENT" in this comment.
>>
> Yes, I guess.
>
>>>   */
>>> -
>>> -/* EAX Features */
>> Spurious delete?
>>
> Nope - it moved up into the above block.

Ah - I see now.  That looks ok.

With the other changes, Reviewed-by: Andrew Cooper
<andrew.cooper3@citrix.com>

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:23:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:23:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOuM-0004ZL-E8; Thu, 06 Nov 2014 15:23:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmOuL-0004Z7-PY
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:23:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9A/C9-09842-5729B545; Thu, 06 Nov 2014 15:23:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415287408!11963669!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20818 invoked from network); 6 Nov 2014 15:23:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:23:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190213415"
Message-ID: <545B91D5.8030608@citrix.com>
Date: Thu, 6 Nov 2014 15:20:53 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<545B903F.1090503@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0111465F1@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0111465F1@AMSPEX01CL01.citrite.net>
X-DLP: MIA1
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 15:16, Paul Durrant wrote:
>> -----Original Message-----
>> From: Andrew Cooper
>> Sent: 06 November 2014 15:14
>> To: Paul Durrant; xen-devel@lists.xen.org
>> Cc: Keir (Xen.org); Jan Beulich
>> Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu
>> id
>>
>> On 06/11/14 15:07, Paul Durrant wrote:
>>> To perform certain hypercalls HVM guests need to use Xen's idea of
>>> vcpu id, which may well not match the guest OS idea of CPU id.
>>> This patch adds vcpu id to the HVM cpuid leaf allowing the guest
>>> to build a mapping.
>>>
>>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>> Cc: Keir Fraser <keir@xen.org>
>>> Cc: Jan Beulich <jbeulich@suse.com>
>>> ---
>>>  xen/arch/x86/hvm/hvm.c              |    4 ++++
>>>  xen/include/public/arch-x86/cpuid.h |    5 +++--
>>>  2 files changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>>> index 78f519d..d9a5706 100644
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t
>> sub_idx,
>>>           * foreign pages) has valid IOMMU entries.
>>>           */
>>>          *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
>>> +
>>> +        /* Indicate presence of vcpu id and set it in ebx */
>>> +        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
>>> +        *ebx = current->vcpu_id;
>>>      }
>>>  }
>>>
>>> diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-
>> x86/cpuid.h
>>> index 6005dfe..8ccb6e1 100644
>>> --- a/xen/include/public/arch-x86/cpuid.h
>>> +++ b/xen/include/public/arch-x86/cpuid.h
>>> @@ -76,13 +76,14 @@
>>>  /*
>>>   * Leaf 5 (0x40000x04)
>>>   * HVM-specific features
>>> + * EAX: Features
>>> + * EBX: VCPU ID
>> Probably want "iff EAX & VCPU_ID_PRESENT" in this comment.
>>
> Yes, I guess.
>
>>>   */
>>> -
>>> -/* EAX Features */
>> Spurious delete?
>>
> Nope - it moved up into the above block.

Ah - I see now.  That looks ok.

With the other changes, Reviewed-by: Andrew Cooper
<andrew.cooper3@citrix.com>

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:24:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOvg-0004jU-Th; Thu, 06 Nov 2014 15:24:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmOvf-0004jG-C0
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:24:55 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	6C/36-03145-6C29B545; Thu, 06 Nov 2014 15:24:54 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415287490!11764936!1
X-Originating-IP: [64.18.0.141]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3673 invoked from network); 6 Nov 2014 15:24:52 -0000
Received: from exprod5og101.obsmtp.com (HELO exprod5og101.obsmtp.com)
	(64.18.0.141)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:24:52 -0000
Received: from mail-qa0-f46.google.com ([209.85.216.46]) (using TLSv1) by
	exprod5ob101.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuSwtMSpf0xIsi9RFOcq6wsjUXEKYNO@postini.com;
	Thu, 06 Nov 2014 07:24:52 PST
Received: by mail-qa0-f46.google.com with SMTP id n8so871725qaq.33
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:24:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=Oro112YMXQ9fvunkfx1M+AuWmitauAIh4nuYzfwJgC8=;
	b=dX6CSpBj5BfhcbHcmXSoGecRd6LfTj+20avMm+nP0vH6GNjTcqqPHBaMZmlQmF35cE
	LzUxbn0YT7FBNWK7G9VrI4kAUoWpKUsXcjR21r53EF9vtlP/uTomeC38t5hUoSe5nluh
	KWIBf1jzPuTWd/7959gCF8ydEW4dWraneQ/HU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=Oro112YMXQ9fvunkfx1M+AuWmitauAIh4nuYzfwJgC8=;
	b=Nj+iRO5iQ31vch0brY3QRdTfIvKSwg+qYD9fjWIdbpnq6XtzNzspSk+PTpdBupc4JA
	yIM2bDUCxCAdskt9F/FGzjopQs0FdXeR/qXOtrpOu5E4jKqaHFRz9zNhVpV/GsSYnyCi
	v/ib9VQzPHbCujUSc4AEqCKXucpQHQ6rFPS1jO85XQqQ8/EP4ehk8nWT3k3maxOKIOsy
	abXkXBGNlgvKFC2NsHbVu3CXU/rzfzPepqzsn8+YAuSEbYD4g7yEesDp7AIfZwhI1l2+
	JGScba4tL44srvA7WRwS59N6/nug+a61UwuZOIN45HOvn4P128421yYQ+igeMONEgDVX
	uYrQ==
X-Gm-Message-State: ALoCoQmGTIWoBkR3WeelDlmU2Wt1BSK8+fvYa71EJPs36mZEMwo4SJ1qaojxS/B+lHoKjRrmAgU8nxhhg75jwhWWe6h6ESMwHZThwSSJtBfAWax4+2QXQBLL0+s1UmUK6HwbEZc3cb1bzJewZ5AdXZGg8ZIxE+7rKQ==
X-Received: by 10.224.54.205 with SMTP id r13mr1639689qag.73.1415287489747;
	Thu, 06 Nov 2014 07:24:49 -0800 (PST)
X-Received: by 10.224.54.205 with SMTP id r13mr1639665qag.73.1415287489623;
	Thu, 06 Nov 2014 07:24:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:24:29 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061515400.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
	<CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
	<alpine.DEB.2.02.1411061515400.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:24:29 +0200
Message-ID: <CAN58jivVbpc4exAfq_g9NswoQycdNUdSJQwa=msCXKnuF4=f9w@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >
>> > Why?
>> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
>
> Sorry, I meant why are you introducing HYPERVISOR_sysctl?
I use it to get real physical CPUs counter.
Also I'll implement a new sysctl operation: XEN_SYSCTL_cpufreq_op
Kernel will use this op to start/stop cpufreq notification
events sending.

>> >>  arch/arm/include/asm/xen/hypercall.h |   1 +
>> >>  arch/arm/include/asm/xen/interface.h |   2 +
>> >>  arch/arm/xen/enlighten.c             |   1 +
>> >>  arch/arm/xen/hypercall.S             |   1 +
>> >>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
>> >>  include/xen/interface/xen.h          |   6 +
>> >>  6 files changed, 657 insertions(+)
>> >>  create mode 100644 include/xen/interface/sysctl.h
>> >>
>> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> >> index c817c56..751869eb 100644
>> >> --- a/arch/arm/include/asm/xen/hypercall.h
>> >> +++ b/arch/arm/include/asm/xen/hypercall.h
>> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>> >>  int HYPERVISOR_tmem_op(void *arg);
>> >> +int HYPERVISOR_sysctl(void *arg);
>> >>
>> >>  static inline void
>> >>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
>> >> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
>> >> index 1151188..acf4b7a 100644
>> >> --- a/arch/arm/include/asm/xen/interface.h
>> >> +++ b/arch/arm/include/asm/xen/interface.h
>> >> @@ -19,6 +19,7 @@
>> >>       __DEFINE_GUEST_HANDLE(name, struct name)
>> >>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
>> >>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
>> >> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
>> >>
>> >>  #define set_xen_guest_handle(hnd, val)                       \
>> >>       do {                                            \
>> >> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
>> >>  DEFINE_GUEST_HANDLE(void);
>> >>  DEFINE_GUEST_HANDLE(uint64_t);
>> >>  DEFINE_GUEST_HANDLE(uint32_t);
>> >> +DEFINE_GUEST_HANDLE(uint8_t);
>> >>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>> >>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>> >>
>> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> >> index eb0d851..675f17a 100644
>> >> --- a/arch/arm/xen/enlighten.c
>> >> +++ b/arch/arm/xen/enlighten.c
>> >> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>> >>  EXPORT_SYMBOL_GPL(privcmd_call);
>> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> >> index d1cf7b7..a1276df 100644
>> >> --- a/arch/arm/xen/hypercall.S
>> >> +++ b/arch/arm/xen/hypercall.S
>> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>> >>  HYPERCALL2(physdev_op);
>> >>  HYPERCALL3(vcpu_op);
>> >>  HYPERCALL1(tmem_op);
>> >> +HYPERCALL1(sysctl);
>> >>
>> >>  ENTRY(privcmd_call)
>> >>       stmdb sp!, {r4}
>> >> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
>> >> new file mode 100644
>> >> index 0000000..1a8cf7a
>> >> --- /dev/null
>> >> +++ b/include/xen/interface/sysctl.h
>> >> @@ -0,0 +1,646 @@
>> >> +/******************************************************************************
>> >> + * sysctl.h
>> >> + *
>> >> + * System management operations. For use by node control stack.
>> >> + *
>> >> + * Reused from xen: xen/include/public/sysctl.h
>> >> + *
>> >> + * Permission is hereby granted, free of charge, to any person obtaining a copy
>> >> + * of this software and associated documentation files (the "Software"), to
>> >> + * deal in the Software without restriction, including without limitation the
>> >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
>> >> + * sell copies of the Software, and to permit persons to whom the Software is
>> >> + * furnished to do so, subject to the following conditions:
>> >> + *
>> >> + * The above copyright notice and this permission notice shall be included in
>> >> + * all copies or substantial portions of the Software.
>> >> + *
>> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
>> >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> >> + * DEALINGS IN THE SOFTWARE.
>> >> + *
>> >> + * Copyright (c) 2002-2006, K Fraser
>> >> + * Copyright (c) 2014, GlobalLogic Inc.
>> >> + */
>> >> +
>> >> +#ifndef __XEN_PUBLIC_SYSCTL_H__
>> >> +#define __XEN_PUBLIC_SYSCTL_H__
>> >> +
>> >> +#include <xen/interface/xen.h>
>> >> +
>> >> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
>> >> +
>> >> +/*
>> >> + * Read console content from Xen buffer ring.
>> >> + */
>> >> +/* XEN_SYSCTL_readconsole */
>> >> +struct xen_sysctl_readconsole {
>> >> +     /* IN: Non-zero -> clear after reading. */
>> >> +     uint8_t clear;
>> >> +     /* IN: Non-zero -> start index specified by @index field. */
>> >> +     uint8_t incremental;
>> >> +     uint8_t pad0, pad1;
>> >> +     /*
>> >> +     * IN:  Start index for consuming from ring buffer (if @incremental);
>> >> +     * OUT: End index after consuming from ring buffer.
>> >> +     */
>> >> +     uint32_t index;
>> >> +     /* IN: Virtual address to write console data. */
>> >> +     GUEST_HANDLE_64(char) buffer;
>> >> +     /* IN: Size of buffer; OUT: Bytes written to buffer. */
>> >> +     uint32_t count;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
>> >> +
>> >> +/* Get trace buffers machine base address */
>> >> +/* XEN_SYSCTL_tbuf_op */
>> >> +struct xen_sysctl_tbuf_op {
>> >> +    /* IN variables */
>> >> +#define XEN_SYSCTL_TBUFOP_get_info     0
>> >> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
>> >> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
>> >> +#define XEN_SYSCTL_TBUFOP_set_size     3
>> >> +#define XEN_SYSCTL_TBUFOP_enable       4
>> >> +#define XEN_SYSCTL_TBUFOP_disable      5
>> >> +     uint32_t cmd;
>> >> +     /* IN/OUT variables */
>> >> +     struct xenctl_bitmap cpu_mask;
>> >> +     uint32_t             evt_mask;
>> >> +     /* OUT variables */
>> >> +     uint64_aligned_t buffer_mfn;
>> >> +     uint32_t size;  /* Also an IN variable! */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
>> >> +
>> >> +/*
>> >> + * Get physical information about the host machine
>> >> + */
>> >> +/* XEN_SYSCTL_physinfo */
>> >> + /* (x86) The platform supports HVM guests. */
>> >> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
>> >> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
>> >> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
>> >> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
>> >> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
>> >> +struct xen_sysctl_physinfo {
>> >> +     uint32_t threads_per_core;
>> >> +     uint32_t cores_per_socket;
>> >> +     uint32_t nr_cpus;     /* # CPUs currently online */
>> >> +     uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
>> >> +     uint32_t nr_nodes;    /* # nodes currently online */
>> >> +     uint32_t max_node_id; /* Largest possible node ID on this host */
>> >> +     uint32_t cpu_khz;
>> >> +     uint64_aligned_t total_pages;
>> >> +     uint64_aligned_t free_pages;
>> >> +     uint64_aligned_t scrub_pages;
>> >> +     uint64_aligned_t outstanding_pages;
>> >> +     uint32_t hw_cap[8];
>> >> +
>> >> +     /* XEN_SYSCTL_PHYSCAP_??? */
>> >> +     uint32_t capabilities;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
>> >> +
>> >> +/*
>> >> + * Get the ID of the current scheduler.
>> >> + */
>> >> +/* XEN_SYSCTL_sched_id */
>> >> +struct xen_sysctl_sched_id {
>> >> +     /* OUT variable */
>> >> +     uint32_t sched_id;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
>> >> +
>> >> +/* Interface for controlling Xen software performance counters. */
>> >> +/* XEN_SYSCTL_perfc_op */
>> >> +/* Sub-operations: */
>> >> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
>> >> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
>> >> +struct xen_sysctl_perfc_desc {
>> >> +     char         name[80];           /* name of perf counter */
>> >> +     uint32_t     nr_vals;            /* number of values for this counter */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
>> >> +
>> >> +struct xen_sysctl_perfc_op {
>> >> +     /* IN variables. */
>> >> +     uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
>> >> +     /* OUT variables. */
>> >> +     uint32_t       nr_counters;       /*  number of counters description  */
>> >> +     uint32_t       nr_vals;           /*  number of values  */
>> >> +     /* counter information (or NULL) */
>> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
>> >> +     /* counter values (or NULL) */
>> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
>> >> +
>> >> +/* Inject debug keys into Xen. */
>> >> +/* XEN_SYSCTL_debug_keys */
>> >> +struct xen_sysctl_debug_keys {
>> >> +     /* IN variables. */
>> >> +     GUEST_HANDLE_64(char) keys;
>> >> +     uint32_t nr_keys;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
>> >> +
>> >> +/* Get physical CPU information. */
>> >> +/* XEN_SYSCTL_getcpuinfo */
>> >> +struct xen_sysctl_cpuinfo {
>> >> +     uint64_aligned_t idletime;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
>> >> +struct xen_sysctl_getcpuinfo {
>> >> +     /* IN variables. */
>> >> +     uint32_t max_cpus;
>> >> +     GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
>> >> +     /* OUT variables. */
>> >> +     uint32_t nr_cpus;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
>> >> +
>> >> +/* XEN_SYSCTL_availheap */
>> >> +struct xen_sysctl_availheap {
>> >> +     /* IN variables. */
>> >> +     uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
>> >> +     uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
>> >> +     int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
>> >> +     /* OUT variables. */
>> >> +     uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
>> >> +
>> >> +/* XEN_SYSCTL_get_pmstat */
>> >> +struct pm_px_val {
>> >> +     uint64_aligned_t freq;        /* Px core frequency */
>> >> +     uint64_aligned_t residency;   /* Px residency time */
>> >> +     uint64_aligned_t count;       /* Px transition count */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
>> >> +
>> >> +struct pm_px_stat {
>> >> +     uint8_t total;        /* total Px states */
>> >> +     uint8_t usable;       /* usable Px states */
>> >> +     uint8_t last;         /* last Px state */
>> >> +     uint8_t cur;          /* current Px state */
>> >> +     GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
>> >> +     GUEST_HANDLE_64(pm_px_val) pt;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
>> >> +
>> >> +struct pm_cx_stat {
>> >> +     uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
>> >> +     uint32_t last;  /* last Cx state */
>> >> +     uint64_aligned_t idle_time;                 /* idle time from boot */
>> >> +     GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
>> >> +     GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
>> >> +     uint64_aligned_t pc2;
>> >> +     uint64_aligned_t pc3;
>> >> +     uint64_aligned_t pc6;
>> >> +     uint64_aligned_t pc7;
>> >> +     uint64_aligned_t cc3;
>> >> +     uint64_aligned_t cc6;
>> >> +     uint64_aligned_t cc7;
>> >> +};
>> >> +
>> >> +struct xen_sysctl_get_pmstat {
>> >> +#define PMSTAT_CATEGORY_MASK 0xf0
>> >> +#define PMSTAT_PX            0x10
>> >> +#define PMSTAT_CX            0x20
>> >> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
>> >> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
>> >> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
>> >> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
>> >> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
>> >> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
>> >> +     uint32_t type;
>> >> +     uint32_t cpuid;
>> >> +     union {
>> >> +             struct pm_px_stat getpx;
>> >> +             struct pm_cx_stat getcx;
>> >> +             /* other struct for tx, etc */
>> >> +     } u;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
>> >> +
>> >> +/* XEN_SYSCTL_cpu_hotplug */
>> >> +struct xen_sysctl_cpu_hotplug {
>> >> +     /* IN variables */
>> >> +     uint32_t cpu;   /* Physical cpu. */
>> >> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
>> >> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
>> >> +     uint32_t op;    /* hotplug opcode */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
>> >> +
>> >> +/*
>> >> + * Get/set xen power management, include
>> >> + * 1. cpufreq governors and related parameters
>> >> + */
>> >> +/* XEN_SYSCTL_pm_op */
>> >> +struct xen_userspace {
>> >> +     uint32_t scaling_setspeed;
>> >> +};
>> >> +
>> >> +struct xen_ondemand {
>> >> +     uint32_t sampling_rate_max;
>> >> +     uint32_t sampling_rate_min;
>> >> +
>> >> +     uint32_t sampling_rate;
>> >> +     uint32_t up_threshold;
>> >> +};
>> >> +
>> >> +/*
>> >> + * cpufreq para name of this structure named
>> >> + * same as sysfs file name of native linux
>> >> + */
>> >> +#define CPUFREQ_NAME_LEN 16
>> >> +struct xen_get_cpufreq_para {
>> >> +     /* IN/OUT variable */
>> >> +     uint32_t cpu_num;
>> >> +     uint32_t freq_num;
>> >> +     uint32_t gov_num;
>> >> +
>> >> +     /* for all governors */
>> >> +     /* OUT variable */
>> >> +     GUEST_HANDLE_64(uint32_t) affected_cpus;
>> >> +     GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
>> >> +     GUEST_HANDLE_64(char)   scaling_available_governors;
>> >> +     char scaling_driver[CPUFREQ_NAME_LEN];
>> >> +
>> >> +     uint32_t cpuinfo_cur_freq;
>> >> +     uint32_t cpuinfo_max_freq;
>> >> +     uint32_t cpuinfo_min_freq;
>> >> +     uint32_t scaling_cur_freq;
>> >> +
>> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> >> +     uint32_t scaling_max_freq;
>> >> +     uint32_t scaling_min_freq;
>> >> +
>> >> +     /* for specific governor */
>> >> +     union {
>> >> +             struct  xen_userspace userspace;
>> >> +             struct  xen_ondemand ondemand;
>> >> +     } u;
>> >> +
>> >> +     int32_t turbo_enabled;
>> >> +};
>> >> +
>> >> +struct xen_set_cpufreq_gov {
>> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> >> +};
>> >> +
>> >> +struct xen_set_cpufreq_para {
>> >> +     #define SCALING_MAX_FREQ           1
>> >> +     #define SCALING_MIN_FREQ           2
>> >> +     #define SCALING_SETSPEED           3
>> >> +     #define SAMPLING_RATE              4
>> >> +     #define UP_THRESHOLD               5
>> >> +
>> >> +     uint32_t ctrl_type;
>> >> +     uint32_t ctrl_value;
>> >> +};
>> >> +
>> >> +struct xen_sysctl_pm_op {
>> >> +     #define PM_PARA_CATEGORY_MASK      0xf0
>> >> +     #define CPUFREQ_PARA               0x10
>> >> +
>> >> +     /* cpufreq command type */
>> >> +     #define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
>> >> +     #define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
>> >> +     #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
>> >> +     #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
>> >> +
>> >> +     /* set/reset scheduler power saving option */
>> >> +     #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
>> >> +
>> >> +     /* cpuidle max_cstate access command */
>> >> +     #define XEN_SYSCTL_pm_op_get_max_cstate       0x22
>> >> +     #define XEN_SYSCTL_pm_op_set_max_cstate       0x23
>> >> +
>> >> +     /* set scheduler migration cost value */
>> >> +     #define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
>> >> +     #define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
>> >> +
>> >> +     /* enable/disable turbo mode when in dbs governor */
>> >> +     #define XEN_SYSCTL_pm_op_enable_turbo               0x26
>> >> +     #define XEN_SYSCTL_pm_op_disable_turbo              0x27
>> >> +
>> >> +     uint32_t cmd;
>> >> +     uint32_t cpuid;
>> >> +     union {
>> >> +             struct xen_get_cpufreq_para get_para;
>> >> +             struct xen_set_cpufreq_gov  set_gov;
>> >> +             struct xen_set_cpufreq_para set_para;
>> >> +             uint64_aligned_t get_avgfreq;
>> >> +             uint32_t                    set_sched_opt_smt;
>> >> +             uint32_t                    get_max_cstate;
>> >> +             uint32_t                    set_max_cstate;
>> >> +             uint32_t                    get_vcpu_migration_delay;
>> >> +             uint32_t                    set_vcpu_migration_delay;
>> >> +     } u;
>> >> +};
>> >> +
>> >> +/* XEN_SYSCTL_page_offline_op */
>> >> +struct xen_sysctl_page_offline_op {
>> >> +     /* IN: range of page to be offlined */
>> >> +#define sysctl_page_offline     1
>> >> +#define sysctl_page_online      2
>> >> +#define sysctl_query_page_offline  3
>> >> +     uint32_t cmd;
>> >> +     uint32_t start;
>> >> +     uint32_t end;
>> >> +     /* OUT: result of page offline request */
>> >> +     /*
>> >> +     * bit 0~15: result flags
>> >> +     * bit 16~31: owner
>> >> +     */
>> >> +     GUEST_HANDLE(uint32_t) status;
>> >> +};
>> >> +
>> >> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
>> >> +
>> >> +/* The result is invalid, i.e. HV does not handle it */
>> >> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
>> >> +
>> >> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
>> >> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
>> >> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
>> >> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
>> >> +
>> >> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
>> >> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
>> >> +
>> >> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
>> >> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
>> >> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
>> >> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
>> >> +
>> >> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
>> >> +
>> >> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
>> >> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
>> >> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
>> >> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
>> >> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
>> >> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
>> >> +
>> >> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
>> >> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
>> >> +
>> >> +#define PG_OFFLINE_OWNER_SHIFT 16
>> >> +
>> >> +/* XEN_SYSCTL_lockprof_op */
>> >> +/* Sub-operations: */
>> >> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
>> >> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
>> >> +/* Record-type: */
>> >> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
>> >> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
>> >> +#define LOCKPROF_TYPE_N           2   /* number of types */
>> >> +struct xen_sysctl_lockprof_data {
>> >> +     char     name[40];   /* lock name (may include up to 2 %d specifiers) */
>> >> +     int32_t  type;       /* LOCKPROF_TYPE_??? */
>> >> +     int32_t  idx;        /* index (e.g. domain id) */
>> >> +     uint64_aligned_t lock_cnt;     /* # of locking succeeded */
>> >> +     uint64_aligned_t block_cnt;    /* # of wait for lock */
>> >> +     uint64_aligned_t lock_time;    /* nsecs lock held */
>> >> +     uint64_aligned_t block_time;   /* nsecs waited for lock */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
>> >> +
>> >> +struct xen_sysctl_lockprof_op {
>> >> +     /* IN variables. */
>> >> +     uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
>> >> +     uint32_t       max_elem;          /* size of output buffer */
>> >> +     /* OUT variables (query only). */
>> >> +     uint32_t       nr_elem;           /* number of elements available */
>> >> +     uint64_aligned_t time;            /* nsecs of profile measurement */
>> >> +     /* profile information (or NULL) */
>> >> +     GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
>> >> +
>> >> +/* XEN_SYSCTL_topologyinfo */
>> >> +#define INVALID_TOPOLOGY_ID  (~0U)
>> >> +struct xen_sysctl_topologyinfo {
>> >> +     /*
>> >> +      * IN: maximum addressable entry in the caller-provided arrays.
>> >> +      * OUT: largest cpu identifier in the system.
>> >> +      * If OUT is greater than IN then the arrays are truncated!
>> >> +      * If OUT is leass than IN then the array tails are not written by
>> >> +      * sysctl.
>> >> +      */
>> >> +     uint32_t max_cpu_index;
>> >> +
>> >> +     /*
>> >> +      * If not NULL, these arrays are filled with core/socket/node identifier
>> >> +      * for each cpu.
>> >> +      * If a cpu has no core/socket/node information (e.g., cpu not present)
>> >> +      * then the sentinel value ~0u is written to each array.
>> >> +      * The number of array elements written by the sysctl is:
>> >> +      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
>> >> +      */
>> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_core;
>> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_socket;
>> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_node;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
>> >> +
>> >> +/* XEN_SYSCTL_numainfo */
>> >> +#define INVALID_NUMAINFO_ID (~0U)
>> >> +struct xen_sysctl_numainfo {
>> >> +     /*
>> >> +      * IN: maximum addressable entry in the caller-provided arrays.
>> >> +      * OUT: largest node identifier in the system.
>> >> +      * If OUT is greater than IN then the arrays are truncated!
>> >> +      */
>> >> +     uint32_t max_node_index;
>> >> +
>> >> +     /* NB. Entries are 0 if node is not present. */
>> >> +     GUEST_HANDLE_64(uint64_t) node_to_memsize;
>> >> +     GUEST_HANDLE_64(uint64_t) node_to_memfree;
>> >> +
>> >> +     /*
>> >> +      * Array, of size (max_node_index+1)^2, listing memory access distances
>> >> +      * between nodes. If an entry has no node distance information (e.g., node
>> >> +      * not present) then the value ~0u is written.
>> >> +      *
>> >> +      * Note that the array rows must be indexed by multiplying by the minimum
>> >> +      * of the caller-provided max_node_index and the returned value of
>> >> +      * max_node_index. That is, if the largest node index in the system is
>> >> +      * smaller than the caller can handle, a smaller 2-d array is constructed
>> >> +      * within the space provided by the caller. When this occurs, trailing
>> >> +      * space provided by the caller is not modified. If the largest node index
>> >> +      * in the system is larger than the caller can handle, then a 2-d array of
>> >> +      * the maximum size handleable by the caller is constructed.
>> >> +      */
>> >> +     GUEST_HANDLE_64(uint32_t) node_to_node_distance;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
>> >> +
>> >> +/* XEN_SYSCTL_cpupool_op */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
>> >> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
>> >> +struct xen_sysctl_cpupool_op {
>> >> +     uint32_t op;          /* IN */
>> >> +     uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
>> >> +     uint32_t sched_id;    /* IN: C      OUT: I  */
>> >> +     uint32_t domid;       /* IN: M              */
>> >> +     uint32_t cpu;         /* IN: AR             */
>> >> +     uint32_t n_dom;       /*            OUT: I  */
>> >> +     struct xenctl_bitmap cpumap; /*     OUT: IF */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
>> >> +
>> >> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
>> >> +/*
>> >> + * This structure is used to pass a new ARINC653 schedule from a
>> >> + * privileged domain (ie dom0) to Xen.
>> >> + */
>> >> +struct xen_sysctl_arinc653_schedule {
>> >> +     /* major_frame holds the time for the new schedule's major frame
>> >> +     * in nanoseconds. */
>> >> +     uint64_aligned_t     major_frame;
>> >> +     /* num_sched_entries holds how many of the entries in the
>> >> +     * sched_entries[] array are valid. */
>> >> +     uint8_t     num_sched_entries;
>> >> +     /* The sched_entries array holds the actual schedule entries. */
>> >> +     struct {
>> >> +             /* dom_handle must match a domain's UUID */
>> >> +             xen_domain_handle_t dom_handle;
>> >> +             /*
>> >> +              * If a domain has multiple VCPUs, vcpu_id specifies which one
>> >> +              * this schedule entry applies to. It should be set to 0 if
>> >> +              * there is only one VCPU for the domain. */
>> >> +             unsigned int vcpu_id;
>> >> +             /*
>> >> +              * runtime specifies the amount of time that should be allocated
>> >> +              * to this VCPU per major frame. It is specified in nanoseconds
>> >> +              */
>> >> +             uint64_aligned_t runtime;
>> >> +     } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
>> >> +
>> >> +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;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
>> >> +
>> >> +/* XEN_SYSCTL_scheduler_op */
>> >> +/* Set or get info? */
>> >> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
>> >> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
>> >> +struct xen_sysctl_scheduler_op {
>> >> +     uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
>> >> +     uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
>> >> +     uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
>> >> +     union {
>> >> +             struct xen_sysctl_sched_arinc653 {
>> >> +                     GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
>> >> +             } sched_arinc653;
>> >> +             struct xen_sysctl_credit_schedule sched_credit;
>> >> +     } u;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
>> >> +
>> >> +/* XEN_SYSCTL_coverage_op */
>> >> +/*
>> >> + * Get total size of information, to help allocate
>> >> + * the buffer. The pointer points to a 32 bit value.
>> >> + */
>> >> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
>> >> +
>> >> +/*
>> >> + * Read coverage information in a single run
>> >> + * You must use a tool to split them.
>> >> + */
>> >> +#define XEN_SYSCTL_COVERAGE_read           1
>> >> +
>> >> +/*
>> >> + * Reset all the coverage counters to 0
>> >> + * No parameters.
>> >> + */
>> >> +#define XEN_SYSCTL_COVERAGE_reset          2
>> >> +
>> >> +/*
>> >> + * Like XEN_SYSCTL_COVERAGE_read but reset also
>> >> + * counters to 0 in a single call.
>> >> + */
>> >> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
>> >> +
>> >> +struct xen_sysctl_coverage_op {
>> >> +     uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
>> >> +     union {
>> >> +             uint32_t total_size; /* OUT */
>> >> +             GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
>> >> +     } u;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
>> >> +
>> >> +
>> >> +struct xen_sysctl {
>> >> +     uint32_t cmd;
>> >> +#define XEN_SYSCTL_readconsole                    1
>> >> +#define XEN_SYSCTL_tbuf_op                        2
>> >> +#define XEN_SYSCTL_physinfo                       3
>> >> +#define XEN_SYSCTL_sched_id                       4
>> >> +#define XEN_SYSCTL_perfc_op                       5
>> >> +#define XEN_SYSCTL_debug_keys                     7
>> >> +#define XEN_SYSCTL_getcpuinfo                     8
>> >> +#define XEN_SYSCTL_availheap                      9
>> >> +#define XEN_SYSCTL_get_pmstat                    10
>> >> +#define XEN_SYSCTL_cpu_hotplug                   11
>> >> +#define XEN_SYSCTL_pm_op                         12
>> >> +#define XEN_SYSCTL_page_offline_op               14
>> >> +#define XEN_SYSCTL_lockprof_op                   15
>> >> +#define XEN_SYSCTL_topologyinfo                  16
>> >> +#define XEN_SYSCTL_numainfo                      17
>> >> +#define XEN_SYSCTL_cpupool_op                    18
>> >> +#define XEN_SYSCTL_scheduler_op                  19
>> >> +#define XEN_SYSCTL_coverage_op                   20
>> >> +     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
>> >> +     union {
>> >> +             struct xen_sysctl_readconsole       readconsole;
>> >> +             struct xen_sysctl_tbuf_op           tbuf_op;
>> >> +             struct xen_sysctl_physinfo          physinfo;
>> >> +             struct xen_sysctl_topologyinfo      topologyinfo;
>> >> +             struct xen_sysctl_numainfo          numainfo;
>> >> +             struct xen_sysctl_sched_id          sched_id;
>> >> +             struct xen_sysctl_perfc_op          perfc_op;
>> >> +             struct xen_sysctl_debug_keys        debug_keys;
>> >> +             struct xen_sysctl_getcpuinfo        getcpuinfo;
>> >> +             struct xen_sysctl_availheap         availheap;
>> >> +             struct xen_sysctl_get_pmstat        get_pmstat;
>> >> +             struct xen_sysctl_cpu_hotplug       cpu_hotplug;
>> >> +             struct xen_sysctl_pm_op             pm_op;
>> >> +             struct xen_sysctl_page_offline_op   page_offline;
>> >> +             struct xen_sysctl_lockprof_op       lockprof_op;
>> >> +             struct xen_sysctl_cpupool_op        cpupool_op;
>> >> +             struct xen_sysctl_scheduler_op      scheduler_op;
>> >> +             struct xen_sysctl_coverage_op       coverage_op;
>> >> +             uint8_t                             pad[128];
>> >> +     } u;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
>> >> +
>> >> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */
>> >
>> > We usually only introduce what we need from Xen header files in Linux:
>> > do not copy the entirety of sysctl.h, just introduce what you need.
>> I'll do this in the next patch-set.
>>
>> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> >> index 53ec416..cf64566 100644
>> >> --- a/include/xen/interface/xen.h
>> >> +++ b/include/xen/interface/xen.h
>> >> @@ -57,6 +57,7 @@
>> >>  #define __HYPERVISOR_event_channel_op     32
>> >>  #define __HYPERVISOR_physdev_op           33
>> >>  #define __HYPERVISOR_hvm_op               34
>> >> +#define __HYPERVISOR_sysctl               35
>> >>  #define __HYPERVISOR_tmem_op              38
>> >>
>> >>  /* Architecture-specific hypercall definitions. */
>> >> @@ -526,6 +527,11 @@ struct tmem_op {
>> >>
>> >>  DEFINE_GUEST_HANDLE(u64);
>> >>
>> >> +struct xenctl_bitmap {
>> >> +     GUEST_HANDLE_64(uint8_t) bitmap;
>> >> +     uint32_t nr_bits;
>> >> +};
>> >> +
>> >>  #else /* __ASSEMBLY__ */
>> >>
>> >>  /* In assembly code we cannot use C numeric constant suffixes. */
>> >> --
>> >> 1.9.1
>> >>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:24:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOvg-0004jU-Th; Thu, 06 Nov 2014 15:24:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmOvf-0004jG-C0
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:24:55 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	6C/36-03145-6C29B545; Thu, 06 Nov 2014 15:24:54 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415287490!11764936!1
X-Originating-IP: [64.18.0.141]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3673 invoked from network); 6 Nov 2014 15:24:52 -0000
Received: from exprod5og101.obsmtp.com (HELO exprod5og101.obsmtp.com)
	(64.18.0.141)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:24:52 -0000
Received: from mail-qa0-f46.google.com ([209.85.216.46]) (using TLSv1) by
	exprod5ob101.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuSwtMSpf0xIsi9RFOcq6wsjUXEKYNO@postini.com;
	Thu, 06 Nov 2014 07:24:52 PST
Received: by mail-qa0-f46.google.com with SMTP id n8so871725qaq.33
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:24:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=Oro112YMXQ9fvunkfx1M+AuWmitauAIh4nuYzfwJgC8=;
	b=dX6CSpBj5BfhcbHcmXSoGecRd6LfTj+20avMm+nP0vH6GNjTcqqPHBaMZmlQmF35cE
	LzUxbn0YT7FBNWK7G9VrI4kAUoWpKUsXcjR21r53EF9vtlP/uTomeC38t5hUoSe5nluh
	KWIBf1jzPuTWd/7959gCF8ydEW4dWraneQ/HU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=Oro112YMXQ9fvunkfx1M+AuWmitauAIh4nuYzfwJgC8=;
	b=Nj+iRO5iQ31vch0brY3QRdTfIvKSwg+qYD9fjWIdbpnq6XtzNzspSk+PTpdBupc4JA
	yIM2bDUCxCAdskt9F/FGzjopQs0FdXeR/qXOtrpOu5E4jKqaHFRz9zNhVpV/GsSYnyCi
	v/ib9VQzPHbCujUSc4AEqCKXucpQHQ6rFPS1jO85XQqQ8/EP4ehk8nWT3k3maxOKIOsy
	abXkXBGNlgvKFC2NsHbVu3CXU/rzfzPepqzsn8+YAuSEbYD4g7yEesDp7AIfZwhI1l2+
	JGScba4tL44srvA7WRwS59N6/nug+a61UwuZOIN45HOvn4P128421yYQ+igeMONEgDVX
	uYrQ==
X-Gm-Message-State: ALoCoQmGTIWoBkR3WeelDlmU2Wt1BSK8+fvYa71EJPs36mZEMwo4SJ1qaojxS/B+lHoKjRrmAgU8nxhhg75jwhWWe6h6ESMwHZThwSSJtBfAWax4+2QXQBLL0+s1UmUK6HwbEZc3cb1bzJewZ5AdXZGg8ZIxE+7rKQ==
X-Received: by 10.224.54.205 with SMTP id r13mr1639689qag.73.1415287489747;
	Thu, 06 Nov 2014 07:24:49 -0800 (PST)
X-Received: by 10.224.54.205 with SMTP id r13mr1639665qag.73.1415287489623;
	Thu, 06 Nov 2014 07:24:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:24:29 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061515400.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
	<CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
	<alpine.DEB.2.02.1411061515400.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:24:29 +0200
Message-ID: <CAN58jivVbpc4exAfq_g9NswoQycdNUdSJQwa=msCXKnuF4=f9w@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >
>> > Why?
>> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
>
> Sorry, I meant why are you introducing HYPERVISOR_sysctl?
I use it to get real physical CPUs counter.
Also I'll implement a new sysctl operation: XEN_SYSCTL_cpufreq_op
Kernel will use this op to start/stop cpufreq notification
events sending.

>> >>  arch/arm/include/asm/xen/hypercall.h |   1 +
>> >>  arch/arm/include/asm/xen/interface.h |   2 +
>> >>  arch/arm/xen/enlighten.c             |   1 +
>> >>  arch/arm/xen/hypercall.S             |   1 +
>> >>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
>> >>  include/xen/interface/xen.h          |   6 +
>> >>  6 files changed, 657 insertions(+)
>> >>  create mode 100644 include/xen/interface/sysctl.h
>> >>
>> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> >> index c817c56..751869eb 100644
>> >> --- a/arch/arm/include/asm/xen/hypercall.h
>> >> +++ b/arch/arm/include/asm/xen/hypercall.h
>> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>> >>  int HYPERVISOR_tmem_op(void *arg);
>> >> +int HYPERVISOR_sysctl(void *arg);
>> >>
>> >>  static inline void
>> >>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
>> >> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
>> >> index 1151188..acf4b7a 100644
>> >> --- a/arch/arm/include/asm/xen/interface.h
>> >> +++ b/arch/arm/include/asm/xen/interface.h
>> >> @@ -19,6 +19,7 @@
>> >>       __DEFINE_GUEST_HANDLE(name, struct name)
>> >>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
>> >>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
>> >> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
>> >>
>> >>  #define set_xen_guest_handle(hnd, val)                       \
>> >>       do {                                            \
>> >> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
>> >>  DEFINE_GUEST_HANDLE(void);
>> >>  DEFINE_GUEST_HANDLE(uint64_t);
>> >>  DEFINE_GUEST_HANDLE(uint32_t);
>> >> +DEFINE_GUEST_HANDLE(uint8_t);
>> >>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>> >>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>> >>
>> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> >> index eb0d851..675f17a 100644
>> >> --- a/arch/arm/xen/enlighten.c
>> >> +++ b/arch/arm/xen/enlighten.c
>> >> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>> >>  EXPORT_SYMBOL_GPL(privcmd_call);
>> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> >> index d1cf7b7..a1276df 100644
>> >> --- a/arch/arm/xen/hypercall.S
>> >> +++ b/arch/arm/xen/hypercall.S
>> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>> >>  HYPERCALL2(physdev_op);
>> >>  HYPERCALL3(vcpu_op);
>> >>  HYPERCALL1(tmem_op);
>> >> +HYPERCALL1(sysctl);
>> >>
>> >>  ENTRY(privcmd_call)
>> >>       stmdb sp!, {r4}
>> >> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
>> >> new file mode 100644
>> >> index 0000000..1a8cf7a
>> >> --- /dev/null
>> >> +++ b/include/xen/interface/sysctl.h
>> >> @@ -0,0 +1,646 @@
>> >> +/******************************************************************************
>> >> + * sysctl.h
>> >> + *
>> >> + * System management operations. For use by node control stack.
>> >> + *
>> >> + * Reused from xen: xen/include/public/sysctl.h
>> >> + *
>> >> + * Permission is hereby granted, free of charge, to any person obtaining a copy
>> >> + * of this software and associated documentation files (the "Software"), to
>> >> + * deal in the Software without restriction, including without limitation the
>> >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
>> >> + * sell copies of the Software, and to permit persons to whom the Software is
>> >> + * furnished to do so, subject to the following conditions:
>> >> + *
>> >> + * The above copyright notice and this permission notice shall be included in
>> >> + * all copies or substantial portions of the Software.
>> >> + *
>> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
>> >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> >> + * DEALINGS IN THE SOFTWARE.
>> >> + *
>> >> + * Copyright (c) 2002-2006, K Fraser
>> >> + * Copyright (c) 2014, GlobalLogic Inc.
>> >> + */
>> >> +
>> >> +#ifndef __XEN_PUBLIC_SYSCTL_H__
>> >> +#define __XEN_PUBLIC_SYSCTL_H__
>> >> +
>> >> +#include <xen/interface/xen.h>
>> >> +
>> >> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
>> >> +
>> >> +/*
>> >> + * Read console content from Xen buffer ring.
>> >> + */
>> >> +/* XEN_SYSCTL_readconsole */
>> >> +struct xen_sysctl_readconsole {
>> >> +     /* IN: Non-zero -> clear after reading. */
>> >> +     uint8_t clear;
>> >> +     /* IN: Non-zero -> start index specified by @index field. */
>> >> +     uint8_t incremental;
>> >> +     uint8_t pad0, pad1;
>> >> +     /*
>> >> +     * IN:  Start index for consuming from ring buffer (if @incremental);
>> >> +     * OUT: End index after consuming from ring buffer.
>> >> +     */
>> >> +     uint32_t index;
>> >> +     /* IN: Virtual address to write console data. */
>> >> +     GUEST_HANDLE_64(char) buffer;
>> >> +     /* IN: Size of buffer; OUT: Bytes written to buffer. */
>> >> +     uint32_t count;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
>> >> +
>> >> +/* Get trace buffers machine base address */
>> >> +/* XEN_SYSCTL_tbuf_op */
>> >> +struct xen_sysctl_tbuf_op {
>> >> +    /* IN variables */
>> >> +#define XEN_SYSCTL_TBUFOP_get_info     0
>> >> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
>> >> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
>> >> +#define XEN_SYSCTL_TBUFOP_set_size     3
>> >> +#define XEN_SYSCTL_TBUFOP_enable       4
>> >> +#define XEN_SYSCTL_TBUFOP_disable      5
>> >> +     uint32_t cmd;
>> >> +     /* IN/OUT variables */
>> >> +     struct xenctl_bitmap cpu_mask;
>> >> +     uint32_t             evt_mask;
>> >> +     /* OUT variables */
>> >> +     uint64_aligned_t buffer_mfn;
>> >> +     uint32_t size;  /* Also an IN variable! */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
>> >> +
>> >> +/*
>> >> + * Get physical information about the host machine
>> >> + */
>> >> +/* XEN_SYSCTL_physinfo */
>> >> + /* (x86) The platform supports HVM guests. */
>> >> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
>> >> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
>> >> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
>> >> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
>> >> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
>> >> +struct xen_sysctl_physinfo {
>> >> +     uint32_t threads_per_core;
>> >> +     uint32_t cores_per_socket;
>> >> +     uint32_t nr_cpus;     /* # CPUs currently online */
>> >> +     uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
>> >> +     uint32_t nr_nodes;    /* # nodes currently online */
>> >> +     uint32_t max_node_id; /* Largest possible node ID on this host */
>> >> +     uint32_t cpu_khz;
>> >> +     uint64_aligned_t total_pages;
>> >> +     uint64_aligned_t free_pages;
>> >> +     uint64_aligned_t scrub_pages;
>> >> +     uint64_aligned_t outstanding_pages;
>> >> +     uint32_t hw_cap[8];
>> >> +
>> >> +     /* XEN_SYSCTL_PHYSCAP_??? */
>> >> +     uint32_t capabilities;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
>> >> +
>> >> +/*
>> >> + * Get the ID of the current scheduler.
>> >> + */
>> >> +/* XEN_SYSCTL_sched_id */
>> >> +struct xen_sysctl_sched_id {
>> >> +     /* OUT variable */
>> >> +     uint32_t sched_id;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
>> >> +
>> >> +/* Interface for controlling Xen software performance counters. */
>> >> +/* XEN_SYSCTL_perfc_op */
>> >> +/* Sub-operations: */
>> >> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
>> >> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
>> >> +struct xen_sysctl_perfc_desc {
>> >> +     char         name[80];           /* name of perf counter */
>> >> +     uint32_t     nr_vals;            /* number of values for this counter */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
>> >> +
>> >> +struct xen_sysctl_perfc_op {
>> >> +     /* IN variables. */
>> >> +     uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
>> >> +     /* OUT variables. */
>> >> +     uint32_t       nr_counters;       /*  number of counters description  */
>> >> +     uint32_t       nr_vals;           /*  number of values  */
>> >> +     /* counter information (or NULL) */
>> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
>> >> +     /* counter values (or NULL) */
>> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
>> >> +
>> >> +/* Inject debug keys into Xen. */
>> >> +/* XEN_SYSCTL_debug_keys */
>> >> +struct xen_sysctl_debug_keys {
>> >> +     /* IN variables. */
>> >> +     GUEST_HANDLE_64(char) keys;
>> >> +     uint32_t nr_keys;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
>> >> +
>> >> +/* Get physical CPU information. */
>> >> +/* XEN_SYSCTL_getcpuinfo */
>> >> +struct xen_sysctl_cpuinfo {
>> >> +     uint64_aligned_t idletime;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
>> >> +struct xen_sysctl_getcpuinfo {
>> >> +     /* IN variables. */
>> >> +     uint32_t max_cpus;
>> >> +     GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
>> >> +     /* OUT variables. */
>> >> +     uint32_t nr_cpus;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
>> >> +
>> >> +/* XEN_SYSCTL_availheap */
>> >> +struct xen_sysctl_availheap {
>> >> +     /* IN variables. */
>> >> +     uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
>> >> +     uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
>> >> +     int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
>> >> +     /* OUT variables. */
>> >> +     uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
>> >> +
>> >> +/* XEN_SYSCTL_get_pmstat */
>> >> +struct pm_px_val {
>> >> +     uint64_aligned_t freq;        /* Px core frequency */
>> >> +     uint64_aligned_t residency;   /* Px residency time */
>> >> +     uint64_aligned_t count;       /* Px transition count */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
>> >> +
>> >> +struct pm_px_stat {
>> >> +     uint8_t total;        /* total Px states */
>> >> +     uint8_t usable;       /* usable Px states */
>> >> +     uint8_t last;         /* last Px state */
>> >> +     uint8_t cur;          /* current Px state */
>> >> +     GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
>> >> +     GUEST_HANDLE_64(pm_px_val) pt;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
>> >> +
>> >> +struct pm_cx_stat {
>> >> +     uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
>> >> +     uint32_t last;  /* last Cx state */
>> >> +     uint64_aligned_t idle_time;                 /* idle time from boot */
>> >> +     GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
>> >> +     GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
>> >> +     uint64_aligned_t pc2;
>> >> +     uint64_aligned_t pc3;
>> >> +     uint64_aligned_t pc6;
>> >> +     uint64_aligned_t pc7;
>> >> +     uint64_aligned_t cc3;
>> >> +     uint64_aligned_t cc6;
>> >> +     uint64_aligned_t cc7;
>> >> +};
>> >> +
>> >> +struct xen_sysctl_get_pmstat {
>> >> +#define PMSTAT_CATEGORY_MASK 0xf0
>> >> +#define PMSTAT_PX            0x10
>> >> +#define PMSTAT_CX            0x20
>> >> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
>> >> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
>> >> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
>> >> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
>> >> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
>> >> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
>> >> +     uint32_t type;
>> >> +     uint32_t cpuid;
>> >> +     union {
>> >> +             struct pm_px_stat getpx;
>> >> +             struct pm_cx_stat getcx;
>> >> +             /* other struct for tx, etc */
>> >> +     } u;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
>> >> +
>> >> +/* XEN_SYSCTL_cpu_hotplug */
>> >> +struct xen_sysctl_cpu_hotplug {
>> >> +     /* IN variables */
>> >> +     uint32_t cpu;   /* Physical cpu. */
>> >> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
>> >> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
>> >> +     uint32_t op;    /* hotplug opcode */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
>> >> +
>> >> +/*
>> >> + * Get/set xen power management, include
>> >> + * 1. cpufreq governors and related parameters
>> >> + */
>> >> +/* XEN_SYSCTL_pm_op */
>> >> +struct xen_userspace {
>> >> +     uint32_t scaling_setspeed;
>> >> +};
>> >> +
>> >> +struct xen_ondemand {
>> >> +     uint32_t sampling_rate_max;
>> >> +     uint32_t sampling_rate_min;
>> >> +
>> >> +     uint32_t sampling_rate;
>> >> +     uint32_t up_threshold;
>> >> +};
>> >> +
>> >> +/*
>> >> + * cpufreq para name of this structure named
>> >> + * same as sysfs file name of native linux
>> >> + */
>> >> +#define CPUFREQ_NAME_LEN 16
>> >> +struct xen_get_cpufreq_para {
>> >> +     /* IN/OUT variable */
>> >> +     uint32_t cpu_num;
>> >> +     uint32_t freq_num;
>> >> +     uint32_t gov_num;
>> >> +
>> >> +     /* for all governors */
>> >> +     /* OUT variable */
>> >> +     GUEST_HANDLE_64(uint32_t) affected_cpus;
>> >> +     GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
>> >> +     GUEST_HANDLE_64(char)   scaling_available_governors;
>> >> +     char scaling_driver[CPUFREQ_NAME_LEN];
>> >> +
>> >> +     uint32_t cpuinfo_cur_freq;
>> >> +     uint32_t cpuinfo_max_freq;
>> >> +     uint32_t cpuinfo_min_freq;
>> >> +     uint32_t scaling_cur_freq;
>> >> +
>> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> >> +     uint32_t scaling_max_freq;
>> >> +     uint32_t scaling_min_freq;
>> >> +
>> >> +     /* for specific governor */
>> >> +     union {
>> >> +             struct  xen_userspace userspace;
>> >> +             struct  xen_ondemand ondemand;
>> >> +     } u;
>> >> +
>> >> +     int32_t turbo_enabled;
>> >> +};
>> >> +
>> >> +struct xen_set_cpufreq_gov {
>> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> >> +};
>> >> +
>> >> +struct xen_set_cpufreq_para {
>> >> +     #define SCALING_MAX_FREQ           1
>> >> +     #define SCALING_MIN_FREQ           2
>> >> +     #define SCALING_SETSPEED           3
>> >> +     #define SAMPLING_RATE              4
>> >> +     #define UP_THRESHOLD               5
>> >> +
>> >> +     uint32_t ctrl_type;
>> >> +     uint32_t ctrl_value;
>> >> +};
>> >> +
>> >> +struct xen_sysctl_pm_op {
>> >> +     #define PM_PARA_CATEGORY_MASK      0xf0
>> >> +     #define CPUFREQ_PARA               0x10
>> >> +
>> >> +     /* cpufreq command type */
>> >> +     #define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
>> >> +     #define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
>> >> +     #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
>> >> +     #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
>> >> +
>> >> +     /* set/reset scheduler power saving option */
>> >> +     #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
>> >> +
>> >> +     /* cpuidle max_cstate access command */
>> >> +     #define XEN_SYSCTL_pm_op_get_max_cstate       0x22
>> >> +     #define XEN_SYSCTL_pm_op_set_max_cstate       0x23
>> >> +
>> >> +     /* set scheduler migration cost value */
>> >> +     #define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
>> >> +     #define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
>> >> +
>> >> +     /* enable/disable turbo mode when in dbs governor */
>> >> +     #define XEN_SYSCTL_pm_op_enable_turbo               0x26
>> >> +     #define XEN_SYSCTL_pm_op_disable_turbo              0x27
>> >> +
>> >> +     uint32_t cmd;
>> >> +     uint32_t cpuid;
>> >> +     union {
>> >> +             struct xen_get_cpufreq_para get_para;
>> >> +             struct xen_set_cpufreq_gov  set_gov;
>> >> +             struct xen_set_cpufreq_para set_para;
>> >> +             uint64_aligned_t get_avgfreq;
>> >> +             uint32_t                    set_sched_opt_smt;
>> >> +             uint32_t                    get_max_cstate;
>> >> +             uint32_t                    set_max_cstate;
>> >> +             uint32_t                    get_vcpu_migration_delay;
>> >> +             uint32_t                    set_vcpu_migration_delay;
>> >> +     } u;
>> >> +};
>> >> +
>> >> +/* XEN_SYSCTL_page_offline_op */
>> >> +struct xen_sysctl_page_offline_op {
>> >> +     /* IN: range of page to be offlined */
>> >> +#define sysctl_page_offline     1
>> >> +#define sysctl_page_online      2
>> >> +#define sysctl_query_page_offline  3
>> >> +     uint32_t cmd;
>> >> +     uint32_t start;
>> >> +     uint32_t end;
>> >> +     /* OUT: result of page offline request */
>> >> +     /*
>> >> +     * bit 0~15: result flags
>> >> +     * bit 16~31: owner
>> >> +     */
>> >> +     GUEST_HANDLE(uint32_t) status;
>> >> +};
>> >> +
>> >> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
>> >> +
>> >> +/* The result is invalid, i.e. HV does not handle it */
>> >> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
>> >> +
>> >> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
>> >> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
>> >> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
>> >> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
>> >> +
>> >> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
>> >> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
>> >> +
>> >> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
>> >> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
>> >> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
>> >> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
>> >> +
>> >> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
>> >> +
>> >> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
>> >> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
>> >> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
>> >> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
>> >> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
>> >> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
>> >> +
>> >> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
>> >> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
>> >> +
>> >> +#define PG_OFFLINE_OWNER_SHIFT 16
>> >> +
>> >> +/* XEN_SYSCTL_lockprof_op */
>> >> +/* Sub-operations: */
>> >> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
>> >> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
>> >> +/* Record-type: */
>> >> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
>> >> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
>> >> +#define LOCKPROF_TYPE_N           2   /* number of types */
>> >> +struct xen_sysctl_lockprof_data {
>> >> +     char     name[40];   /* lock name (may include up to 2 %d specifiers) */
>> >> +     int32_t  type;       /* LOCKPROF_TYPE_??? */
>> >> +     int32_t  idx;        /* index (e.g. domain id) */
>> >> +     uint64_aligned_t lock_cnt;     /* # of locking succeeded */
>> >> +     uint64_aligned_t block_cnt;    /* # of wait for lock */
>> >> +     uint64_aligned_t lock_time;    /* nsecs lock held */
>> >> +     uint64_aligned_t block_time;   /* nsecs waited for lock */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
>> >> +
>> >> +struct xen_sysctl_lockprof_op {
>> >> +     /* IN variables. */
>> >> +     uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
>> >> +     uint32_t       max_elem;          /* size of output buffer */
>> >> +     /* OUT variables (query only). */
>> >> +     uint32_t       nr_elem;           /* number of elements available */
>> >> +     uint64_aligned_t time;            /* nsecs of profile measurement */
>> >> +     /* profile information (or NULL) */
>> >> +     GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
>> >> +
>> >> +/* XEN_SYSCTL_topologyinfo */
>> >> +#define INVALID_TOPOLOGY_ID  (~0U)
>> >> +struct xen_sysctl_topologyinfo {
>> >> +     /*
>> >> +      * IN: maximum addressable entry in the caller-provided arrays.
>> >> +      * OUT: largest cpu identifier in the system.
>> >> +      * If OUT is greater than IN then the arrays are truncated!
>> >> +      * If OUT is leass than IN then the array tails are not written by
>> >> +      * sysctl.
>> >> +      */
>> >> +     uint32_t max_cpu_index;
>> >> +
>> >> +     /*
>> >> +      * If not NULL, these arrays are filled with core/socket/node identifier
>> >> +      * for each cpu.
>> >> +      * If a cpu has no core/socket/node information (e.g., cpu not present)
>> >> +      * then the sentinel value ~0u is written to each array.
>> >> +      * The number of array elements written by the sysctl is:
>> >> +      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
>> >> +      */
>> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_core;
>> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_socket;
>> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_node;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
>> >> +
>> >> +/* XEN_SYSCTL_numainfo */
>> >> +#define INVALID_NUMAINFO_ID (~0U)
>> >> +struct xen_sysctl_numainfo {
>> >> +     /*
>> >> +      * IN: maximum addressable entry in the caller-provided arrays.
>> >> +      * OUT: largest node identifier in the system.
>> >> +      * If OUT is greater than IN then the arrays are truncated!
>> >> +      */
>> >> +     uint32_t max_node_index;
>> >> +
>> >> +     /* NB. Entries are 0 if node is not present. */
>> >> +     GUEST_HANDLE_64(uint64_t) node_to_memsize;
>> >> +     GUEST_HANDLE_64(uint64_t) node_to_memfree;
>> >> +
>> >> +     /*
>> >> +      * Array, of size (max_node_index+1)^2, listing memory access distances
>> >> +      * between nodes. If an entry has no node distance information (e.g., node
>> >> +      * not present) then the value ~0u is written.
>> >> +      *
>> >> +      * Note that the array rows must be indexed by multiplying by the minimum
>> >> +      * of the caller-provided max_node_index and the returned value of
>> >> +      * max_node_index. That is, if the largest node index in the system is
>> >> +      * smaller than the caller can handle, a smaller 2-d array is constructed
>> >> +      * within the space provided by the caller. When this occurs, trailing
>> >> +      * space provided by the caller is not modified. If the largest node index
>> >> +      * in the system is larger than the caller can handle, then a 2-d array of
>> >> +      * the maximum size handleable by the caller is constructed.
>> >> +      */
>> >> +     GUEST_HANDLE_64(uint32_t) node_to_node_distance;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
>> >> +
>> >> +/* XEN_SYSCTL_cpupool_op */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
>> >> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
>> >> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
>> >> +struct xen_sysctl_cpupool_op {
>> >> +     uint32_t op;          /* IN */
>> >> +     uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
>> >> +     uint32_t sched_id;    /* IN: C      OUT: I  */
>> >> +     uint32_t domid;       /* IN: M              */
>> >> +     uint32_t cpu;         /* IN: AR             */
>> >> +     uint32_t n_dom;       /*            OUT: I  */
>> >> +     struct xenctl_bitmap cpumap; /*     OUT: IF */
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
>> >> +
>> >> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
>> >> +/*
>> >> + * This structure is used to pass a new ARINC653 schedule from a
>> >> + * privileged domain (ie dom0) to Xen.
>> >> + */
>> >> +struct xen_sysctl_arinc653_schedule {
>> >> +     /* major_frame holds the time for the new schedule's major frame
>> >> +     * in nanoseconds. */
>> >> +     uint64_aligned_t     major_frame;
>> >> +     /* num_sched_entries holds how many of the entries in the
>> >> +     * sched_entries[] array are valid. */
>> >> +     uint8_t     num_sched_entries;
>> >> +     /* The sched_entries array holds the actual schedule entries. */
>> >> +     struct {
>> >> +             /* dom_handle must match a domain's UUID */
>> >> +             xen_domain_handle_t dom_handle;
>> >> +             /*
>> >> +              * If a domain has multiple VCPUs, vcpu_id specifies which one
>> >> +              * this schedule entry applies to. It should be set to 0 if
>> >> +              * there is only one VCPU for the domain. */
>> >> +             unsigned int vcpu_id;
>> >> +             /*
>> >> +              * runtime specifies the amount of time that should be allocated
>> >> +              * to this VCPU per major frame. It is specified in nanoseconds
>> >> +              */
>> >> +             uint64_aligned_t runtime;
>> >> +     } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
>> >> +
>> >> +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;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
>> >> +
>> >> +/* XEN_SYSCTL_scheduler_op */
>> >> +/* Set or get info? */
>> >> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
>> >> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
>> >> +struct xen_sysctl_scheduler_op {
>> >> +     uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
>> >> +     uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
>> >> +     uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
>> >> +     union {
>> >> +             struct xen_sysctl_sched_arinc653 {
>> >> +                     GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
>> >> +             } sched_arinc653;
>> >> +             struct xen_sysctl_credit_schedule sched_credit;
>> >> +     } u;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
>> >> +
>> >> +/* XEN_SYSCTL_coverage_op */
>> >> +/*
>> >> + * Get total size of information, to help allocate
>> >> + * the buffer. The pointer points to a 32 bit value.
>> >> + */
>> >> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
>> >> +
>> >> +/*
>> >> + * Read coverage information in a single run
>> >> + * You must use a tool to split them.
>> >> + */
>> >> +#define XEN_SYSCTL_COVERAGE_read           1
>> >> +
>> >> +/*
>> >> + * Reset all the coverage counters to 0
>> >> + * No parameters.
>> >> + */
>> >> +#define XEN_SYSCTL_COVERAGE_reset          2
>> >> +
>> >> +/*
>> >> + * Like XEN_SYSCTL_COVERAGE_read but reset also
>> >> + * counters to 0 in a single call.
>> >> + */
>> >> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
>> >> +
>> >> +struct xen_sysctl_coverage_op {
>> >> +     uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
>> >> +     union {
>> >> +             uint32_t total_size; /* OUT */
>> >> +             GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
>> >> +     } u;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
>> >> +
>> >> +
>> >> +struct xen_sysctl {
>> >> +     uint32_t cmd;
>> >> +#define XEN_SYSCTL_readconsole                    1
>> >> +#define XEN_SYSCTL_tbuf_op                        2
>> >> +#define XEN_SYSCTL_physinfo                       3
>> >> +#define XEN_SYSCTL_sched_id                       4
>> >> +#define XEN_SYSCTL_perfc_op                       5
>> >> +#define XEN_SYSCTL_debug_keys                     7
>> >> +#define XEN_SYSCTL_getcpuinfo                     8
>> >> +#define XEN_SYSCTL_availheap                      9
>> >> +#define XEN_SYSCTL_get_pmstat                    10
>> >> +#define XEN_SYSCTL_cpu_hotplug                   11
>> >> +#define XEN_SYSCTL_pm_op                         12
>> >> +#define XEN_SYSCTL_page_offline_op               14
>> >> +#define XEN_SYSCTL_lockprof_op                   15
>> >> +#define XEN_SYSCTL_topologyinfo                  16
>> >> +#define XEN_SYSCTL_numainfo                      17
>> >> +#define XEN_SYSCTL_cpupool_op                    18
>> >> +#define XEN_SYSCTL_scheduler_op                  19
>> >> +#define XEN_SYSCTL_coverage_op                   20
>> >> +     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
>> >> +     union {
>> >> +             struct xen_sysctl_readconsole       readconsole;
>> >> +             struct xen_sysctl_tbuf_op           tbuf_op;
>> >> +             struct xen_sysctl_physinfo          physinfo;
>> >> +             struct xen_sysctl_topologyinfo      topologyinfo;
>> >> +             struct xen_sysctl_numainfo          numainfo;
>> >> +             struct xen_sysctl_sched_id          sched_id;
>> >> +             struct xen_sysctl_perfc_op          perfc_op;
>> >> +             struct xen_sysctl_debug_keys        debug_keys;
>> >> +             struct xen_sysctl_getcpuinfo        getcpuinfo;
>> >> +             struct xen_sysctl_availheap         availheap;
>> >> +             struct xen_sysctl_get_pmstat        get_pmstat;
>> >> +             struct xen_sysctl_cpu_hotplug       cpu_hotplug;
>> >> +             struct xen_sysctl_pm_op             pm_op;
>> >> +             struct xen_sysctl_page_offline_op   page_offline;
>> >> +             struct xen_sysctl_lockprof_op       lockprof_op;
>> >> +             struct xen_sysctl_cpupool_op        cpupool_op;
>> >> +             struct xen_sysctl_scheduler_op      scheduler_op;
>> >> +             struct xen_sysctl_coverage_op       coverage_op;
>> >> +             uint8_t                             pad[128];
>> >> +     } u;
>> >> +};
>> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
>> >> +
>> >> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */
>> >
>> > We usually only introduce what we need from Xen header files in Linux:
>> > do not copy the entirety of sysctl.h, just introduce what you need.
>> I'll do this in the next patch-set.
>>
>> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> >> index 53ec416..cf64566 100644
>> >> --- a/include/xen/interface/xen.h
>> >> +++ b/include/xen/interface/xen.h
>> >> @@ -57,6 +57,7 @@
>> >>  #define __HYPERVISOR_event_channel_op     32
>> >>  #define __HYPERVISOR_physdev_op           33
>> >>  #define __HYPERVISOR_hvm_op               34
>> >> +#define __HYPERVISOR_sysctl               35
>> >>  #define __HYPERVISOR_tmem_op              38
>> >>
>> >>  /* Architecture-specific hypercall definitions. */
>> >> @@ -526,6 +527,11 @@ struct tmem_op {
>> >>
>> >>  DEFINE_GUEST_HANDLE(u64);
>> >>
>> >> +struct xenctl_bitmap {
>> >> +     GUEST_HANDLE_64(uint8_t) bitmap;
>> >> +     uint32_t nr_bits;
>> >> +};
>> >> +
>> >>  #else /* __ASSEMBLY__ */
>> >>
>> >>  /* In assembly code we cannot use C numeric constant suffixes. */
>> >> --
>> >> 1.9.1
>> >>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:26:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOwu-0004yH-ID; Thu, 06 Nov 2014 15:26:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmOws-0004xr-Sc
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:26:11 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	0A/78-19763-2139B545; Thu, 06 Nov 2014 15:26:10 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415287563!10912501!1
X-Originating-IP: [64.18.0.24]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13250 invoked from network); 6 Nov 2014 15:26:05 -0000
Received: from exprod5og112.obsmtp.com (HELO exprod5og112.obsmtp.com)
	(64.18.0.24)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:26:05 -0000
Received: from mail-qc0-f175.google.com ([209.85.216.175]) (using TLSv1) by
	exprod5ob112.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuTClc0+ge+HKAW4TAjB2I1neQEc88E@postini.com;
	Thu, 06 Nov 2014 07:26:04 PST
Received: by mail-qc0-f175.google.com with SMTP id b13so1035643qcw.34
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:26:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=lJ8C3ZZfemuxZ9eClaMGk4gUGAxzBxLohRfyYhyikVo=;
	b=Px9PKdcyeTg2V2uXkUIQJvJU2VrxvrFYyke2rQ3K4seMflX6gAHSjc8VpyDIgV+Dya
	l8Phd24SUPEXQK+RrYUuFFnfeJbtIkyUBlw3RXmctpIWBiIAAidsihavWDHQbi4flsEi
	suiRiOvlNa+oprxa6i1NKzBUCl6HAe6KQlEVc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=lJ8C3ZZfemuxZ9eClaMGk4gUGAxzBxLohRfyYhyikVo=;
	b=A89puqp7t6Hw+8LSwLwbOeCT/8uovSiGpL3l+aYyHXttr5RqM/uAZn+fzRDE2FfD0u
	VakoP3rlVQ12ko7xxkwg6ZrENisEkyPwe3MUzURrRLZfqwhzPsn46rjRgubZjxIZ/M6+
	H2wRLoTO2X5h2sOi8E7U8TYpn8rvGYaFZawcbYAec3Y2Phf7Klyheq9Ho0eKsG431TIX
	X3CLZyNWHoiT4xjk3LKVm8Mlkl0+1sMCEp6cw0KUOq09/59MqX+5CJ5wf2IWRphA20Ba
	P82fOVTSCioKS5/dzqVovaMQu8b2B8ZpiN9r8DkmAP47gIFmYHALRSe9EYHAeLbJoG4E
	dulw==
X-Gm-Message-State: ALoCoQkP6NkPzZPsDCmzJXUzi5Lg60X5WhXuHQPnKLfH/V4xz5vkpMUHiXxk46VjG2bBn0q7SDFwBGUIY6nzetLYw2sfNdNPFVCu9Hp9+6NM4Hx5lglR6EnYTITE+Ta/lHPZG673efA7W9fW2mT/x9AwaJwDPEW9zA==
X-Received: by 10.229.176.70 with SMTP id bd6mr8006044qcb.12.1415287562300;
	Thu, 06 Nov 2014 07:26:02 -0800 (PST)
X-Received: by 10.229.176.70 with SMTP id bd6mr8006023qcb.12.1415287562188;
	Thu, 06 Nov 2014 07:26:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:25:42 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061516210.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
	<CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
	<alpine.DEB.2.02.1411061516210.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:25:42 +0200
Message-ID: <CAN58jis_GbKe2s+Fbg=A4-Jfu4vCzZGCmMqPqVZ9yKwX9LdwcA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >
>> > Why?
>> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
>
> I meant why are you introducing HYPERVISOR_dom0_op?
HYPERVISOR_dom0_op is used to upload CPUs PM data from Kernel to Xen


>> >>  arch/arm/include/asm/xen/hypercall.h | 1 +
>> >>  arch/arm/xen/enlighten.c             | 1 +
>> >>  arch/arm/xen/hypercall.S             | 1 +
>> >>  3 files changed, 3 insertions(+)
>> >>
>> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> >> index 751869eb..383c174 100644
>> >> --- a/arch/arm/include/asm/xen/hypercall.h
>> >> +++ b/arch/arm/include/asm/xen/hypercall.h
>> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>> >>  int HYPERVISOR_tmem_op(void *arg);
>> >> +int HYPERVISOR_dom0_op(void *arg);
>> >>  int HYPERVISOR_sysctl(void *arg);
>> >>
>> >>  static inline void
>> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> >> index 675f17a..f757c57 100644
>> >> --- a/arch/arm/xen/enlighten.c
>> >> +++ b/arch/arm/xen/enlighten.c
>> >> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>> >>  EXPORT_SYMBOL_GPL(privcmd_call);
>> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> >> index a1276df..99e2254 100644
>> >> --- a/arch/arm/xen/hypercall.S
>> >> +++ b/arch/arm/xen/hypercall.S
>> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>> >>  HYPERCALL2(physdev_op);
>> >>  HYPERCALL3(vcpu_op);
>> >>  HYPERCALL1(tmem_op);
>> >> +HYPERCALL1(dom0_op);
>> >>  HYPERCALL1(sysctl);
>> >>
>> >>  ENTRY(privcmd_call)
>> >> --
>> >> 1.9.1
>> >>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:26:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOwu-0004yH-ID; Thu, 06 Nov 2014 15:26:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmOws-0004xr-Sc
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:26:11 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	0A/78-19763-2139B545; Thu, 06 Nov 2014 15:26:10 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415287563!10912501!1
X-Originating-IP: [64.18.0.24]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13250 invoked from network); 6 Nov 2014 15:26:05 -0000
Received: from exprod5og112.obsmtp.com (HELO exprod5og112.obsmtp.com)
	(64.18.0.24)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:26:05 -0000
Received: from mail-qc0-f175.google.com ([209.85.216.175]) (using TLSv1) by
	exprod5ob112.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuTClc0+ge+HKAW4TAjB2I1neQEc88E@postini.com;
	Thu, 06 Nov 2014 07:26:04 PST
Received: by mail-qc0-f175.google.com with SMTP id b13so1035643qcw.34
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:26:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=lJ8C3ZZfemuxZ9eClaMGk4gUGAxzBxLohRfyYhyikVo=;
	b=Px9PKdcyeTg2V2uXkUIQJvJU2VrxvrFYyke2rQ3K4seMflX6gAHSjc8VpyDIgV+Dya
	l8Phd24SUPEXQK+RrYUuFFnfeJbtIkyUBlw3RXmctpIWBiIAAidsihavWDHQbi4flsEi
	suiRiOvlNa+oprxa6i1NKzBUCl6HAe6KQlEVc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=lJ8C3ZZfemuxZ9eClaMGk4gUGAxzBxLohRfyYhyikVo=;
	b=A89puqp7t6Hw+8LSwLwbOeCT/8uovSiGpL3l+aYyHXttr5RqM/uAZn+fzRDE2FfD0u
	VakoP3rlVQ12ko7xxkwg6ZrENisEkyPwe3MUzURrRLZfqwhzPsn46rjRgubZjxIZ/M6+
	H2wRLoTO2X5h2sOi8E7U8TYpn8rvGYaFZawcbYAec3Y2Phf7Klyheq9Ho0eKsG431TIX
	X3CLZyNWHoiT4xjk3LKVm8Mlkl0+1sMCEp6cw0KUOq09/59MqX+5CJ5wf2IWRphA20Ba
	P82fOVTSCioKS5/dzqVovaMQu8b2B8ZpiN9r8DkmAP47gIFmYHALRSe9EYHAeLbJoG4E
	dulw==
X-Gm-Message-State: ALoCoQkP6NkPzZPsDCmzJXUzi5Lg60X5WhXuHQPnKLfH/V4xz5vkpMUHiXxk46VjG2bBn0q7SDFwBGUIY6nzetLYw2sfNdNPFVCu9Hp9+6NM4Hx5lglR6EnYTITE+Ta/lHPZG673efA7W9fW2mT/x9AwaJwDPEW9zA==
X-Received: by 10.229.176.70 with SMTP id bd6mr8006044qcb.12.1415287562300;
	Thu, 06 Nov 2014 07:26:02 -0800 (PST)
X-Received: by 10.229.176.70 with SMTP id bd6mr8006023qcb.12.1415287562188;
	Thu, 06 Nov 2014 07:26:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:25:42 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061516210.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
	<CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
	<alpine.DEB.2.02.1411061516210.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:25:42 +0200
Message-ID: <CAN58jis_GbKe2s+Fbg=A4-Jfu4vCzZGCmMqPqVZ9yKwX9LdwcA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >
>> > Why?
>> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
>
> I meant why are you introducing HYPERVISOR_dom0_op?
HYPERVISOR_dom0_op is used to upload CPUs PM data from Kernel to Xen


>> >>  arch/arm/include/asm/xen/hypercall.h | 1 +
>> >>  arch/arm/xen/enlighten.c             | 1 +
>> >>  arch/arm/xen/hypercall.S             | 1 +
>> >>  3 files changed, 3 insertions(+)
>> >>
>> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> >> index 751869eb..383c174 100644
>> >> --- a/arch/arm/include/asm/xen/hypercall.h
>> >> +++ b/arch/arm/include/asm/xen/hypercall.h
>> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>> >>  int HYPERVISOR_tmem_op(void *arg);
>> >> +int HYPERVISOR_dom0_op(void *arg);
>> >>  int HYPERVISOR_sysctl(void *arg);
>> >>
>> >>  static inline void
>> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> >> index 675f17a..f757c57 100644
>> >> --- a/arch/arm/xen/enlighten.c
>> >> +++ b/arch/arm/xen/enlighten.c
>> >> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
>> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>> >>  EXPORT_SYMBOL_GPL(privcmd_call);
>> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> >> index a1276df..99e2254 100644
>> >> --- a/arch/arm/xen/hypercall.S
>> >> +++ b/arch/arm/xen/hypercall.S
>> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>> >>  HYPERCALL2(physdev_op);
>> >>  HYPERCALL3(vcpu_op);
>> >>  HYPERCALL1(tmem_op);
>> >> +HYPERCALL1(dom0_op);
>> >>  HYPERCALL1(sysctl);
>> >>
>> >>  ENTRY(privcmd_call)
>> >> --
>> >> 1.9.1
>> >>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOyK-00058y-2N; Thu, 06 Nov 2014 15:27:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmOyI-00058q-W2
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:27:39 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	53/2A-16982-A639B545; Thu, 06 Nov 2014 15:27:38 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415287653!8454417!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22150 invoked from network); 6 Nov 2014 15:27:35 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:27:35 -0000
Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuTZC0i3oX+V1lZRysZLe/ti4siiO3x@postini.com;
	Thu, 06 Nov 2014 07:27:35 PST
Received: by mail-qa0-f45.google.com with SMTP id dc16so891163qab.18
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:27:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=F7xTabXBLkMTFQQFAAVj2QiaO+q1S1SHtldMt6HVlvc=;
	b=k8drmxrsS+Qhg2P6Fu96oS57LpWdh/4k4iIche+PhuqTr1ZKHP6exI9bQdjpcb+4b4
	yCvjVcOWROeD3/Mo8gTxodJXmb8ZYst25UP0uFFIkWDA2frw0m8aMJzYwweTlszhbQAT
	zbUMPEaFvVHNYDXR2ePelwzNADHIHZ3IRYHMk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=F7xTabXBLkMTFQQFAAVj2QiaO+q1S1SHtldMt6HVlvc=;
	b=csFy/QYHf8efKs7fzGFrNlrMxrPkvNTfz+48BBQkim2ezkuTvr+0MrAmOcUuijLSEL
	ZptUCO65bKmkeCP02frL612m4HXDPju6NW2xQUEkLCZKJ5FR4MFemn6tYJrIAlKVQnaA
	ASZ4waFiUW++tmvWgEmrDrjp45v7F8KykbTfd3Kmj89fdoce7dBY35zmpuJGr1jY1eob
	+DjxgMhnTk652lVZLNY641LUkpTDO0/2hYs1DI/D4swhBOf4eH3NvN308lLszlpHehGR
	zbccZ+uyhPmw71/FYfwXfHR6xQLVm26Nx4kHE5jlhpLfgkLW8iRNFqYPXUyhgXtMq+9C
	Wi7A==
X-Gm-Message-State: ALoCoQksuKoCsGpNkDnhYGPdB6Olqe2tR54OsVbN2BACNQKJ1Tv67yQWO63qpRlzDO8wkXKjfYWlbUlJOSY1Bm68GE8PdKdKvtKz7R62l9I5s/s2gxNqQHf7PnHka3A83PkW8VenEI69pEOeshnBkQrU5LO30BVJJw==
X-Received: by 10.140.107.37 with SMTP id g34mr7498037qgf.38.1415287652488;
	Thu, 06 Nov 2014 07:27:32 -0800 (PST)
X-Received: by 10.140.107.37 with SMTP id g34mr7497913qgf.38.1415287651686;
	Thu, 06 Nov 2014 07:27:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:27:10 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061518510.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041621380.22875@kaball.uk.xensource.com>
	<CAN58jivYZMgVuhNNtj6Ks05h1iSZBeihKzqcEGi2wp41T4TxyA@mail.gmail.com>
	<alpine.DEB.2.02.1411061518510.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:27:10 +0200
Message-ID: <CAN58jistuz--3CaAqMei-2Ox6UEjRcE-ZRqezjhx3dY71tHs4g@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 9/9] xen/arm: cpufreq: add
	xen-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 6, 2014 at 5:20 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Tue, Nov 4, 2014 at 6:33 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> Xen changes frequencies on CPUs using this high-level
>> >> cpufreq driver.
>> >>
>> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >
>> > You CC the wrong email address for Rafael in the entire series.
>> Could anybody give me right address for Rafael?
>
> rjw@rjwysocki.net
>
> You can also find it by running ./scripts/get_maintainer.pl on the
> patch:
>
> sstabellini@st22:/local/scratch/sstabellini/linux-pvops-latest$ ./scripts/get_maintainer.pl ~/patch
> "Rafael J. Wysocki" <rjw@rjwysocki.net> (maintainer:CPU FREQUENCY DRI...)
> Viresh Kumar <viresh.kumar@linaro.org> (maintainer:CPU FREQUENCY DRI...)
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/3=33%)
> Boris Ostrovsky <boris.ostrovsky@oracle.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/3=33%)
> David Vrabel <david.vrabel@citrix.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/1=100%,commit_signer:3/3=100%,authored:1/3=33%,removed_lines:6/33=18%)
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> (commit_signer:1/1=100%)
> Tang Liang <liang.tang@oracle.com> (commit_signer:1/1=100%)
> Daniel Kiper <daniel.kiper@oracle.com> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:123/123=100%)
> Jan Beulich <jbeulich@suse.com> (commit_signer:1/1=100%)
> Ian Campbell <ian.campbell@citrix.com> (commit_signer:1/3=33%,authored:1/3=33%,removed_lines:3/33=9%)
> Juergen Gross <jgross@suse.com> (commit_signer:1/3=33%,authored:1/3=33%,added_lines:248/251=99%,removed_lines:24/33=73%)
> linux-kernel@vger.kernel.org (open list)
> linux-pm@vger.kernel.org (open list:CPU FREQUENCY DRI...)
> xen-devel@lists.xenproject.org (moderated list:XEN HYPERVISOR IN...)
Thank You for the clarification.


>> >>  drivers/cpufreq/Kconfig           |  20 +
>> >>  drivers/cpufreq/Makefile          |   1 +
>> >>  drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
>> >>  drivers/cpufreq/cpufreq_drv_ops.h |   4 +
>> >>  drivers/cpufreq/xen-cpufreq.c     | 869 ++++++++++++++++++++++++++++++++++++++
>> >>  include/xen/interface/platform.h  |   1 +
>> >>  include/xen/interface/xen.h       |   1 +
>> >>  7 files changed, 907 insertions(+), 2 deletions(-)
>> >>  create mode 100644 drivers/cpufreq/xen-cpufreq.c
>> >>
>> >> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
>> >> index f5a8f84..4847d8a 100644
>> >> --- a/drivers/cpufreq/Kconfig
>> >> +++ b/drivers/cpufreq/Kconfig
>> >> @@ -19,6 +19,26 @@ config CPU_FREQ
>> >>
>> >>         If in doubt, say N.
>> >>
>> >> +config XEN_CPUFREQ
>> >> +     bool "Xen Cpufreq driver"
>> >> +     depends on XEN_DOM0
>> >> +     depends on !CPUMASK_OFFSTACK
>> >> +     default n
>> >> +     select CPUFREQ_DRV_OPS
>> >> +     help
>> >> +       This driver uploads Power Management information to the Xen
>> >> +       hypervisor and changes CPUs frequency using CPU Frequency scaling
>> >> +       drivers.
>> >> +
>> >> +       To do that the driver uses CPU Frequency scaling drivers to parse
>> >> +       the Power Management data and uploads said information to the Xen
>> >> +       hypervisor. Then the Xen hypervisor can select the proper Pxx states.
>> >> +
>> >> +       Then the Xen hypervisor can change CPUs frequency by giving commands
>> >> +       via this driver to the CPU Frequency scaling driver.
>> >> +
>> >> +       If in doubt, say N.
>> >> +
>> >>  if CPUFREQ_DRV_OPS
>> >>
>> >>  config CPU_FREQ_TABLE
>> >> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> >> index f12a0d3..c8d5037 100644
>> >> --- a/drivers/cpufreq/Makefile
>> >> +++ b/drivers/cpufreq/Makefile
>> >> @@ -1,5 +1,6 @@
>> >>  # CPUfreq core
>> >>  obj-$(CONFIG_CPU_FREQ)                       += cpufreq.o
>> >> +obj-$(CONFIG_XEN_CPUFREQ)            += xen-cpufreq.o
>> >>  obj-$(CONFIG_CPUFREQ_DRV_OPS)                += cpufreq_drv_ops.o
>> >>  # CPUfreq stats
>> >>  obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
>> >> diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
>> >> index c971442..71c3357 100644
>> >> --- a/drivers/cpufreq/cpufreq_drv_ops.c
>> >> +++ b/drivers/cpufreq/cpufreq_drv_ops.c
>> >> @@ -18,6 +18,8 @@
>> >>  #include <linux/init.h>
>> >>  #include <linux/export.h>
>> >>
>> >> +#include <xen/xen.h>
>> >> +
>> >>  static struct cpufreq_drv_ops *ops;
>> >>
>> >>  struct kobject *get_cpufreq_global_kobject(void)
>> >> @@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
>> >>
>> >>  static int __init cpufreq_drv_ops_init(void)
>> >>  {
>> >> +     if (xen_initial_domain()) {
>> >> +#ifdef CONFIG_XEN_CPUFREQ
>> >> +             ops = &xen_cpufreq_drv_ops;
>> >> +             pr_debug("using xen_cpufreq_drv_ops\n");
>> >> +#endif
>> >> +     } else {
>> >>  #ifdef CONFIG_CPU_FREQ
>> >> -     ops = &kern_cpufreq_drv_ops;
>> >> -     pr_debug("using kern_cpufreq_drv_ops\n");
>> >> +             ops = &kern_cpufreq_drv_ops;
>> >> +             pr_debug("using kern_cpufreq_drv_ops\n");
>> >>  #endif
>> >> +     }
>> >>
>> >>       return 0;
>> >>  }
>> >> diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
>> >> index 5cc8e05..d02d509 100644
>> >> --- a/drivers/cpufreq/cpufreq_drv_ops.h
>> >> +++ b/drivers/cpufreq/cpufreq_drv_ops.h
>> >> @@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
>> >>  extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
>> >>  #endif
>> >>
>> >> +#ifdef CONFIG_XEN_CPUFREQ
>> >> +extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
>> >> +#endif
>> >> +
>> >>  #endif /* _CPUFREQ_DRV_OPS_H */
>> >> diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
>> >> new file mode 100644
>> >> index 0000000..21062c7
>> >> --- /dev/null
>> >> +++ b/drivers/cpufreq/xen-cpufreq.c
>> >> @@ -0,0 +1,869 @@
>> >> +/*
>> >> + *  Copyright (C) 2001 Russell King
>> >> + *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
>> >> + *
>> >> + *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
>> >> + *   Added handling for CPU hotplug
>> >> + *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
>> >> + *   Fix handling for CPU hotplug -- affected CPUs
>> >> + *
>> >> + *           (C) 2014 GlobalLogic Inc.
>> >> + *
>> >> + * Based on drivers/cpufreq/cpufreq.c
>> >> + *
>> >> + * 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.
>> >> + */
>> >> +
>> >> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> >> +
>> >> +#include <linux/kernel.h>
>> >> +#include <linux/module.h>
>> >> +#include <linux/init.h>
>> >> +#include <linux/notifier.h>
>> >> +#include <linux/types.h>
>> >> +#include <linux/slab.h>
>> >> +#include <linux/mutex.h>
>> >> +#include <linux/irq.h>
>> >> +#include <linux/workqueue.h>
>> >> +#include <linux/cpufreq.h>
>> >> +
>> >> +#include <trace/events/power.h>
>> >> +
>> >> +#include <xen/xen.h>
>> >> +#include <xen/events.h>
>> >> +#include <xen/interface/xen.h>
>> >> +#include <xen/interface/platform.h>
>> >> +#include <xen/interface/sysctl.h>
>> >> +#include <asm/xen/hypercall.h>
>> >> +#include <asm/xen/hypervisor.h>
>> >> +
>> >> +#include "cpufreq_drv_ops.h"
>> >> +
>> >> +static int xen_nr_cpus;
>> >> +static int xen_irq;
>> >> +
>> >> +#define for_each_xen_cpu(cpu, mask)                  \
>> >> +     for ((cpu) = -1;                                \
>> >> +             (cpu) = cpumask_next((cpu), (mask)),    \
>> >> +             (cpu) < xen_nr_cpus;)
>> >> +
>> >> +static struct cpufreq_driver *cpufreq_driver;
>> >> +static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
>> >> +
>> >> +static DEFINE_SPINLOCK(cpufreq_driver_lock);
>> >> +
>> >> +/*
>> >> + * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
>> >> + * all cpufreq/hotplug/workqueue/etc related lock issues.
>> >> + *
>> >> + * The rules for this semaphore:
>> >> + * - Any routine that wants to read from the policy structure will
>> >> + *   do a down_read on this semaphore.
>> >> + * - Any routine that will write to the policy structure and/or may take away
>> >> + *   the policy altogether (eg. CPU hotplug), will hold this lock in write
>> >> + *   mode before doing so.
>> >> + *
>> >> + * Additional rules:
>> >> + * - Governor routines that can be called in cpufreq hotplug path should not
>> >> + *   take this sem as top level hotplug notifier handler takes this.
>> >> + * - Lock should not be held across
>> >> + *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
>> >> + */
>> >> +static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
>> >> +static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
>> >> +
>> >> +#define lock_policy_rwsem(mode, cpu)                         \
>> >> +static int lock_policy_rwsem_##mode                          \
>> >> +(int cpu)                                                    \
>> >> +{                                                            \
>> >> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);      \
>> >> +     BUG_ON(policy_cpu == -1);                               \
>> >> +     down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));    \
>> >> +                                                             \
>> >> +     return 0;                                               \
>> >> +}
>> >> +
>> >> +lock_policy_rwsem(write, cpu);
>> >> +
>> >> +static void unlock_policy_rwsem_write(int cpu)
>> >> +{
>> >> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
>> >> +     BUG_ON(policy_cpu == -1);
>> >> +     up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
>> >> +}
>> >> +
>> >> +/**
>> >> + * The "transition" notifier list for kernel code that needs to handle
>> >> + * changes to devices when the CPU clock speed changes.
>> >> + * The mutex locks this list.
>> >> + */
>> >> +static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
>> >> +
>> >> +static bool init_cpufreq_transition_notifier_list_called;
>> >> +static int __init init_cpufreq_transition_notifier_list(void)
>> >> +{
>> >> +     srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
>> >> +     init_cpufreq_transition_notifier_list_called = true;
>> >> +     return 0;
>> >> +}
>> >> +pure_initcall(init_cpufreq_transition_notifier_list);
>> >> +
>> >> +static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
>> >> +{
>> >> +     struct cpufreq_policy *data = NULL;
>> >> +     unsigned long flags;
>> >> +
>> >> +     if (cpu >= xen_nr_cpus)
>> >> +             goto err_out;
>> >> +
>> >> +     /* get the cpufreq driver */
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     if (!cpufreq_driver)
>> >> +             goto err_out_unlock;
>> >> +
>> >> +     /* get the CPU */
>> >> +     data = per_cpu(cpufreq_cpu_data, cpu);
>> >> +
>> >> +err_out_unlock:
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +err_out:
>> >> +     return data;
>> >> +}
>> >> +
>> >> +static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
>> >> +{
>> >> +     module_put(cpufreq_driver->owner);
>> >> +}
>> >> +
>> >> +static int push_data_to_hypervisor(struct cpufreq_policy *policy,
>> >> +                                struct cpufreq_frequency_table *table)
>> >> +{
>> >> +     int ret = 0;
>> >> +     unsigned int i;
>> >> +     unsigned int cpu;
>> >> +     uint32_t platform_limit = 0;
>> >> +     unsigned int max_freq = 0;
>> >> +     unsigned int state_count = 0;
>> >> +     unsigned int prev_freq = 0;
>> >> +     struct xen_processor_px *dst_states;
>> >> +     struct xen_processor_performance *dst_perf;
>> >> +     struct xen_platform_op op = {
>> >> +             .cmd                    = XENPF_set_processor_pminfo,
>> >> +             .interface_version      = XENPF_INTERFACE_VERSION,
>> >> +             .u.set_pminfo.type      = XEN_PM_PX,
>> >> +     };
>> >> +
>> >> +     dst_perf = &op.u.set_pminfo.perf;
>> >> +
>> >> +     /* Check freq table and find max frequency */
>> >> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> >> +             unsigned int freq = table[i].frequency;
>> >> +             if (freq == CPUFREQ_ENTRY_INVALID)
>> >> +                     continue;
>> >> +
>> >> +             if (table[i].index != state_count || freq <= prev_freq) {
>> >> +                     pr_err("Frequency table format error\n");
>> >> +                     return -EINVAL;
>> >> +             }
>> >> +
>> >> +             prev_freq = freq;
>> >> +             state_count++;
>> >> +             if (freq > max_freq)
>> >> +                     max_freq = freq;
>> >> +     }
>> >> +
>> >> +     if (!state_count)
>> >> +             return -EINVAL;
>> >> +
>> >> +     dst_perf->state_count = state_count;
>> >> +
>> >> +     dst_states = kcalloc(state_count,
>> >> +                          sizeof(struct xen_processor_px), GFP_KERNEL);
>> >> +
>> >> +     if (!dst_states)
>> >> +             return -ENOMEM;
>> >> +
>> >> +     set_xen_guest_handle(dst_perf->states, dst_states);
>> >> +
>> >> +     /*
>> >> +      * Freq table should start from lower values
>> >> +      * dst_states should start from higer values
>> >> +      */
>> >> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> >> +             unsigned int freq = table[i].frequency;
>> >> +             unsigned int tbl_index = state_count - 1 - table[i].index;
>> >> +             if (freq == CPUFREQ_ENTRY_INVALID)
>> >> +                     continue;
>> >> +
>> >> +             if (freq == max_freq)
>> >> +                     platform_limit = tbl_index;
>> >> +
>> >> +             dst_states[tbl_index].core_frequency = freq / 1000;
>> >> +             dst_states[tbl_index].transition_latency =
>> >> +                             policy->cpuinfo.transition_latency / 1000;
>> >> +     }
>> >> +
>> >> +     dst_perf->shared_type = policy->shared_type;
>> >> +     dst_perf->platform_limit = platform_limit;
>> >> +     dst_perf->domain_info.domain = policy->cpu;
>> >> +     dst_perf->domain_info.num_processors = xen_nr_cpus;
>> >> +     dst_perf->flags = XEN_PX_DATA;
>> >> +
>> >> +     for_each_xen_cpu(cpu, policy->cpus) {
>> >> +             op.u.set_pminfo.id = cpu;
>> >> +             ret = HYPERVISOR_dom0_op(&op);
>> >> +             if (ret) {
>> >> +                     pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
>> >> +                     goto err_free_states;
>> >> +             }
>> >> +             pr_debug("CPU%u - P-states uploaded\n", cpu);
>> >> +
>> >> +             for (i = 0; i < dst_perf->state_count; i++) {
>> >> +                     pr_debug("    state %d: %d MHz, %d uS\n",
>> >> +                              i, (u32) dst_states[i].core_frequency,
>> >> +                              (u32) dst_states[i].transition_latency);
>> >> +             }
>> >> +     }
>> >> +
>> >> +err_free_states:
>> >> +     kfree(dst_states);
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +/*
>> >> + * Returns:
>> >> + *   Negative: Failure
>> >> + *   0:        Success
>> >> + *   Positive: When we have a managed CPU and the sysfs got symlinked
>> >> + */
>> >> +static int xen_cpufreq_add_dev_policy(unsigned int cpu,
>> >> +                               struct cpufreq_policy *policy)
>> >> +{
>> >> +     int ret = 0;
>> >> +#ifdef CONFIG_SMP
>> >> +     unsigned long flags;
>> >> +     unsigned int j;
>> >> +
>> >> +     for_each_cpu(j, policy->cpus) {
>> >> +             struct cpufreq_policy *managed_policy;
>> >> +
>> >> +             if (cpu == j)
>> >> +                     continue;
>> >> +
>> >> +             /* Check for existing affected CPUs.
>> >> +              * They may not be aware of it due to CPU Hotplug.
>> >> +              * cpufreq_cpu_put is called when the device is removed
>> >> +              * in __cpufreq_remove_dev()
>> >> +              */
>> >> +             managed_policy = xen_cpufreq_cpu_get(j);
>> >> +             if (unlikely(managed_policy)) {
>> >> +                     /* Set proper policy_cpu */
>> >> +                     unlock_policy_rwsem_write(cpu);
>> >> +                     per_cpu(cpufreq_policy_cpu, cpu) =
>> >> +                                             managed_policy->cpu;
>> >> +
>> >> +                     if (lock_policy_rwsem_write(cpu) < 0) {
>> >> +                             /* Should not go through policy unlock path */
>> >> +                             if (cpufreq_driver->exit)
>> >> +                                     cpufreq_driver->exit(policy);
>> >> +                             xen_cpufreq_cpu_put(managed_policy);
>> >> +                             return -EBUSY;
>> >> +                     }
>> >> +
>> >> +                     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +                     cpumask_copy(managed_policy->cpus, policy->cpus);
>> >> +                     per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
>> >> +                     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +
>> >> +                     pr_debug("CPU already managed, adding link\n");
>> >> +
>> >> +                     /*
>> >> +                      * Success. We only needed to be added to the mask.
>> >> +                      * Call driver->exit() because only the cpu parent of
>> >> +                      * the kobj needed to call init().
>> >> +                      */
>> >> +                     if (cpufreq_driver->exit)
>> >> +                             cpufreq_driver->exit(policy);
>> >> +
>> >> +                     return 1;
>> >> +             }
>> >> +     }
>> >> +#endif
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +/**
>> >> + * xen_cpufreq_add_dev - add a CPU device
>> >> + *
>> >> + * Adds the cpufreq interface for a CPU device.
>> >> + */
>> >> +static int xen_cpufreq_add_dev(unsigned int cpu)
>> >> +{
>> >> +     int ret = 0;
>> >> +     struct cpufreq_policy *policy;
>> >> +     unsigned long flags;
>> >> +     unsigned int j;
>> >> +
>> >> +     pr_debug("adding CPU %u\n", cpu);
>> >> +
>> >> +#ifdef CONFIG_SMP
>> >> +     /* check whether a different CPU already registered this
>> >> +      * CPU because it is in the same boat. */
>> >> +     policy = xen_cpufreq_cpu_get(cpu);
>> >> +     if (unlikely(policy)) {
>> >> +             xen_cpufreq_cpu_put(policy);
>> >> +             return 0;
>> >> +     }
>> >> +#endif
>> >> +
>> >> +     if (!try_module_get(cpufreq_driver->owner)) {
>> >> +             ret = -EINVAL;
>> >> +             goto module_out;
>> >> +     }
>> >> +
>> >> +     ret = -ENOMEM;
>> >> +     policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
>> >> +     if (!policy)
>> >> +             goto nomem_out;
>> >> +
>> >> +     if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
>> >> +             goto err_free_policy;
>> >> +
>> >> +     if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
>> >> +             goto err_free_cpumask;
>> >> +
>> >> +     policy->cpu = cpu;
>> >> +     cpumask_copy(policy->cpus, cpumask_of(cpu));
>> >> +
>> >> +     /* Initially set CPU itself as the policy_cpu */
>> >> +     per_cpu(cpufreq_policy_cpu, cpu) = cpu;
>> >> +     ret = (lock_policy_rwsem_write(cpu) < 0);
>> >> +     WARN_ON(ret);
>> >> +
>> >> +     /* call driver. From then on the cpufreq must be able
>> >> +      * to accept all calls to ->verify and ->setpolicy for this CPU
>> >> +      */
>> >> +     ret = cpufreq_driver->init(policy);
>> >> +     if (ret) {
>> >> +             pr_debug("initialization failed\n");
>> >> +             goto err_unlock_policy;
>> >> +     }
>> >> +     ret = xen_cpufreq_add_dev_policy(cpu, policy);
>> >> +     if (ret) {
>> >> +             if (ret > 0)
>> >> +                     /* This is a managed cpu, symlink created,
>> >> +                        exit with 0 */
>> >> +                     ret = 0;
>> >> +             goto err_unlock_policy;
>> >> +     }
>> >> +
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +     for_each_cpu(j, policy->cpus) {
>> >> +             per_cpu(cpufreq_cpu_data, j) = policy;
>> >> +             per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
>> >> +     }
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     unlock_policy_rwsem_write(cpu);
>> >> +
>> >> +     module_put(cpufreq_driver->owner);
>> >> +     pr_debug("initialization complete\n");
>> >> +
>> >> +     return 0;
>> >> +
>> >> +err_unlock_policy:
>> >> +     unlock_policy_rwsem_write(cpu);
>> >> +     free_cpumask_var(policy->related_cpus);
>> >> +err_free_cpumask:
>> >> +     free_cpumask_var(policy->cpus);
>> >> +err_free_policy:
>> >> +     kfree(policy);
>> >> +nomem_out:
>> >> +     module_put(cpufreq_driver->owner);
>> >> +module_out:
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +/**
>> >> + * __cpufreq_remove_dev - remove a CPU device
>> >> + *
>> >> + * Removes the cpufreq interface for a CPU device.
>> >> + * Caller should already have policy_rwsem in write mode for this CPU.
>> >> + * This routine frees the rwsem before returning.
>> >> + */
>> >> +static int __cpufreq_remove_dev(unsigned int cpu)
>> >> +{
>> >> +     unsigned long flags;
>> >> +     struct cpufreq_policy *data;
>> >> +#ifdef CONFIG_SMP
>> >> +     unsigned int j;
>> >> +#endif
>> >> +
>> >> +     pr_debug("unregistering CPU %u\n", cpu);
>> >> +
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +     data = per_cpu(cpufreq_cpu_data, cpu);
>> >> +
>> >> +     if (!data) {
>> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +             unlock_policy_rwsem_write(cpu);
>> >> +             return -EINVAL;
>> >> +     }
>> >> +     per_cpu(cpufreq_cpu_data, cpu) = NULL;
>> >> +
>> >> +
>> >> +#ifdef CONFIG_SMP
>> >> +     /* if this isn't the CPU which is the parent of the kobj, we
>> >> +      * only need to unlink, put and exit
>> >> +      */
>> >> +     if (unlikely(cpu != data->cpu)) {
>> >> +             pr_debug("removing link\n");
>> >> +             cpumask_clear_cpu(cpu, data->cpus);
>> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +             xen_cpufreq_cpu_put(data);
>> >> +             unlock_policy_rwsem_write(cpu);
>> >> +             return 0;
>> >> +     }
>> >> +#endif
>> >> +
>> >> +#ifdef CONFIG_SMP
>> >> +
>> >> +     /* if we have other CPUs still registered, we need to unlink them,
>> >> +      * or else wait_for_completion below will lock up. Clean the
>> >> +      * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
>> >> +      * the sysfs links afterwards.
>> >> +      */
>> >> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
>> >> +             for_each_cpu(j, data->cpus) {
>> >> +                     if (j == cpu)
>> >> +                             continue;
>> >> +                     per_cpu(cpufreq_cpu_data, j) = NULL;
>> >> +             }
>> >> +     }
>> >> +
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
>> >> +             for_each_cpu(j, data->cpus) {
>> >> +                     if (j == cpu)
>> >> +                             continue;
>> >> +                     pr_debug("removing link for cpu %u\n", j);
>> >> +                     unlock_policy_rwsem_write(cpu);
>> >> +                     lock_policy_rwsem_write(cpu);
>> >> +                     xen_cpufreq_cpu_put(data);
>> >> +             }
>> >> +     }
>> >> +#else
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +#endif
>> >> +
>> >> +     unlock_policy_rwsem_write(cpu);
>> >> +
>> >> +     lock_policy_rwsem_write(cpu);
>> >> +     if (cpufreq_driver->exit)
>> >> +             cpufreq_driver->exit(data);
>> >> +     unlock_policy_rwsem_write(cpu);
>> >> +
>> >> +     free_cpumask_var(data->related_cpus);
>> >> +     free_cpumask_var(data->cpus);
>> >> +     kfree(data);
>> >> +
>> >> +     return 0;
>> >> +}
>> >> +
>> >> +static int cpufreq_remove_dev(unsigned int cpu)
>> >> +{
>> >> +     int retval;
>> >> +
>> >> +     if (unlikely(lock_policy_rwsem_write(cpu)))
>> >> +             BUG();
>> >> +
>> >> +     retval = __cpufreq_remove_dev(cpu);
>> >> +     return retval;
>> >> +}
>> >> +
>> >> +/*********************************************************************
>> >> + *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
>> >> + *********************************************************************/
>> >> +
>> >> +/**
>> >> + * adjust_jiffies - adjust the system "loops_per_jiffy"
>> >> + *
>> >> + * This function alters the system "loops_per_jiffy" for the clock
>> >> + * speed change. Note that loops_per_jiffy cannot be updated on SMP
>> >> + * systems as each CPU might be scaled differently. So, use the arch
>> >> + * per-CPU loops_per_jiffy value wherever possible.
>> >> + */
>> >> +#ifndef CONFIG_SMP
>> >> +static unsigned long l_p_j_ref;
>> >> +static unsigned int  l_p_j_ref_freq;
>> >> +
>> >> +static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
>> >> +{
>> >> +     if (ci->flags & CPUFREQ_CONST_LOOPS)
>> >> +             return;
>> >> +
>> >> +     if (!l_p_j_ref_freq) {
>> >> +             l_p_j_ref = loops_per_jiffy;
>> >> +             l_p_j_ref_freq = ci->old;
>> >> +             pr_debug("saving %lu as reference value for loops_per_jiffy; "
>> >> +                     "freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
>> >> +     }
>> >> +     if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
>> >> +         (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
>> >> +             loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
>> >> +                                                             ci->new);
>> >> +             pr_debug("scaling loops_per_jiffy to %lu "
>> >> +                     "for frequency %u kHz\n", loops_per_jiffy, ci->new);
>> >> +     }
>> >> +}
>> >> +#else
>> >> +static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
>> >> +{
>> >> +     return;
>> >> +}
>> >> +#endif
>> >
>> > There is quite a lot of code duplication with cpufreq.c, I don't think
>> > that is going to be acceptable for the upstream maintainers.
>> It is very complicated to use an common code. Some functions copied
>> and modified. I'll try to do something in the future.
>>
>> >> +/**
>> >> + * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
>> >> + * on frequency transition.
>> >> + *
>> >> + * This function calls the transition notifiers and the "adjust_jiffies"
>> >> + * function. It is called twice on all CPU frequency changes that have
>> >> + * external effects.
>> >> + */
>> >> +void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
>> >> +                                unsigned int state)
>> >> +{
>> >> +     struct cpufreq_policy *policy;
>> >> +
>> >> +     BUG_ON(irqs_disabled());
>> >> +
>> >> +     freqs->flags = cpufreq_driver->flags;
>> >> +     pr_debug("notification %u of frequency transition to %u kHz\n",
>> >> +              state, freqs->new);
>> >> +
>> >> +     policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
>> >> +     switch (state) {
>> >> +     case CPUFREQ_PRECHANGE:
>> >> +             /* detect if the driver reported a value as "old frequency"
>> >> +              * which is not equal to what the cpufreq core thinks is
>> >> +              * "old frequency".
>> >> +              */
>> >> +             if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
>> >> +                     if ((policy) && (policy->cpu == freqs->cpu) &&
>> >> +                         (policy->cur) && (policy->cur != freqs->old)) {
>> >> +                             pr_debug("Warning: CPU frequency is"
>> >> +                                      " %u, cpufreq assumed %u kHz.\n",
>> >> +                                      freqs->old, policy->cur);
>> >> +                             freqs->old = policy->cur;
>> >> +                     }
>> >> +             }
>> >> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
>> >> +                                      CPUFREQ_PRECHANGE, freqs);
>> >> +             adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
>> >> +             break;
>> >> +
>> >> +     case CPUFREQ_POSTCHANGE:
>> >> +             adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
>> >> +             pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
>> >> +                      (unsigned long)freqs->cpu);
>> >> +             trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
>> >> +             trace_cpu_frequency(freqs->new, freqs->cpu);
>> >> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
>> >> +                                      CPUFREQ_POSTCHANGE, freqs);
>> >> +             if (likely(policy) && likely(policy->cpu == freqs->cpu))
>> >> +                     policy->cur = freqs->new;
>> >> +             break;
>> >> +     }
>> >> +}
>> >> +
>> >> +/*********************************************************************
>> >> + *                              GOVERNORS                            *
>> >> + *********************************************************************/
>> >> +
>> >> +int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
>> >> +                             unsigned int target_freq,
>> >> +                             unsigned int relation)
>> >> +{
>> >> +     int retval = -EINVAL;
>> >> +     unsigned int old_target_freq = target_freq;
>> >> +
>> >> +     /* Make sure that target_freq is within supported range */
>> >> +     if (target_freq > policy->max)
>> >> +             target_freq = policy->max;
>> >> +     if (target_freq < policy->min)
>> >> +             target_freq = policy->min;
>> >> +
>> >> +     pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
>> >> +              policy->cpu, target_freq, relation, old_target_freq);
>> >> +
>> >> +     if (target_freq == policy->cur)
>> >> +             return 0;
>> >> +
>> >> +     if (cpufreq_driver->target)
>> >> +             retval = cpufreq_driver->target(policy, target_freq,
>> >> +                                                 relation);
>> >> +
>> >> +     return retval;
>> >> +}
>> >> +
>> >> +int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
>> >> +                           unsigned int target_freq,
>> >> +                           unsigned int relation)
>> >> +{
>> >> +     int ret = -EINVAL;
>> >> +
>> >> +     if (!policy)
>> >> +             goto no_policy;
>> >> +
>> >> +     if (unlikely(lock_policy_rwsem_write(policy->cpu)))
>> >> +             goto fail;
>> >> +
>> >> +     ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
>> >> +
>> >> +     unlock_policy_rwsem_write(policy->cpu);
>> >> +
>> >> +fail:
>> >> +     xen_cpufreq_cpu_put(policy);
>> >> +no_policy:
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +/*********************************************************************
>> >> + *                    HANDLE COMMANDS FROM XEN                       *
>> >> + *********************************************************************/
>> >> +static void cpufreq_work_hnd(struct work_struct *w);
>> >> +
>> >> +static struct workqueue_struct *cpufreq_wq;
>> >> +static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
>> >> +
>> >> +static void cpufreq_work_hnd(struct work_struct *w)
>> >> +{
>> >> +     int ret;
>> >> +     struct cpufreq_policy *policy;
>> >> +     struct cpufreq_sh_info *cpufreq_info;
>> >> +
>> >> +     cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
>> >> +
>> >> +     policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
>> >> +     ret = xen_cpufreq_driver_target(policy,
>> >> +                                     cpufreq_info->freq,
>> >> +                                     cpufreq_info->relation);
>> >> +
>> >> +     cpufreq_info->result = ret;
>> >> +}
>> >
>> > No barriers? No locking?
>> I'll add barriers in the next patch-set.
>>
>> >> +static irqreturn_t cpufreq_interrupt(int irq, void *data)
>> >> +{
>> >> +     queue_work(cpufreq_wq, &cpufreq_work);
>> >> +     return IRQ_HANDLED;
>> >> +}
>> >> +
>> >> +/*********************************************************************
>> >> + *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
>> >> + *********************************************************************/
>> >> +
>> >> +/**
>> >> + * xen_cpufreq_register_driver - register a CPU Frequency driver
>> >> + * @driver_data: A struct cpufreq_driver containing the values#
>> >> + * submitted by the CPU Frequency driver.
>> >> + *
>> >> + *   Registers a CPU Frequency driver to this core code. This code
>> >> + * returns zero on success, -EBUSY when another driver got here first
>> >> + * (and isn't unregistered in the meantime).
>> >> + *
>> >> + */
>> >> +int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
>> >> +{
>> >> +     unsigned long flags;
>> >> +     int ret;
>> >> +     unsigned int cpu;
>> >> +     struct cpufreq_frequency_table *table;
>> >> +     struct cpufreq_policy *policy;
>> >> +     cpumask_var_t pushed_cpus;
>> >> +     int irq;
>> >> +
>> >> +     if (!xen_nr_cpus)
>> >> +             return -EPROBE_DEFER;
>> >> +
>> >> +     if (!driver_data || !driver_data->verify || !driver_data->init ||
>> >> +         (!driver_data->target))
>> >> +             return -EINVAL;
>> >> +
>> >> +     pr_debug("trying to register driver %s\n", driver_data->name);
>> >> +
>> >> +     if (driver_data->setpolicy)
>> >> +             driver_data->flags |= CPUFREQ_CONST_LOOPS;
>> >> +
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     if (cpufreq_driver) {
>> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +             return -EBUSY;
>> >> +     }
>> >> +     cpufreq_driver = driver_data;
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     irq = bind_virq_to_irq(VIRQ_CPUFREQ, 0);
>> >> +     if (irq < 0) {
>> >> +             pr_err("Bind virq (%d) error (%d)\n", VIRQ_CPUFREQ, irq);
>> >> +             ret = irq;
>> >> +             goto err_remove_drv;
>> >> +     }
>> >> +
>> >> +     irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN|IRQ_NOPROBE);
>> >> +
>> >> +     ret = request_irq(irq, cpufreq_interrupt, 0,
>> >> +                        "xen_cpufreq", NULL);
>> >> +
>> >> +     if (ret < 0) {
>> >> +             pr_err("Request irq (%d) error (%d)\n", irq, ret);
>> >> +             goto err_unbind_from_irqhnd;
>> >> +     }
>> >> +
>> >> +     xen_irq = irq;
>> >> +
>> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
>> >> +             ret = xen_cpufreq_add_dev(cpu);
>> >> +             if (ret)
>> >> +                     goto err_remove_cpu;
>> >> +     }
>> >> +
>> >> +     if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
>> >> +             goto err_remove_cpu;
>> >> +
>> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
>> >> +             if (cpumask_test_cpu(cpu, pushed_cpus))
>> >> +                     continue;
>> >> +
>> >> +             policy = xen_cpufreq_cpu_get(cpu);
>> >> +             if (!policy) {
>> >> +                     ret = -EINVAL;
>> >> +                     goto err_free_cpumask;
>> >> +             }
>> >> +
>> >> +             cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
>> >> +             table = cpufreq_frequency_get_table(policy->cpu);
>> >> +             if (!table) {
>> >> +                     ret = -EINVAL;
>> >> +                     goto err_free_cpumask;
>> >> +             }
>> >> +
>> >> +             ret = push_data_to_hypervisor(policy, table);
>> >> +             if (ret)
>> >> +                     goto err_free_cpumask;
>> >> +     }
>> >> +
>> >> +     free_cpumask_var(pushed_cpus);
>> >> +
>> >> +     pr_debug("driver %s up and running\n", driver_data->name);
>> >> +
>> >> +     return 0;
>> >> +
>> >> +err_free_cpumask:
>> >> +     free_cpumask_var(pushed_cpus);
>> >> +err_remove_cpu:
>> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
>> >> +             cpufreq_remove_dev(cpu);
>> >> +err_unbind_from_irqhnd:
>> >> +     unbind_from_irqhandler(irq, NULL);
>> >> +err_remove_drv:
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +     cpufreq_driver = NULL;
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +/**
>> >> + * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
>> >> + *
>> >> + *    Unregister the current CPUFreq driver. Only call this if you have
>> >> + * the right to do so, i.e. if you have succeeded in initialising before!
>> >> + * Returns zero if successful, and -EINVAL if the cpufreq_driver is
>> >> + * currently not initialised.
>> >> + */
>> >> +int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
>> >> +{
>> >> +     unsigned long flags;
>> >> +     unsigned int cpu;
>> >> +
>> >> +     if (!cpufreq_driver || (driver != cpufreq_driver))
>> >> +             return -EINVAL;
>> >> +
>> >> +     pr_debug("unregistering driver %s\n", driver->name);
>> >> +
>> >> +     unbind_from_irqhandler(xen_irq, NULL);
>> >> +
>> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
>> >> +             cpufreq_remove_dev(cpu);
>> >> +
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +     cpufreq_driver = NULL;
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     return 0;
>> >> +}
>> >> +
>> >> +struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
>> >> +     .notify_transition = xen_cpufreq_notify_transition,
>> >> +     .register_driver = xen_cpufreq_register_driver,
>> >> +     .unregister_driver = xen_cpufreq_unregister_driver,
>> >> +};
>> >> +
>> >> +static int __init xen_cpufreq_init(void)
>> >> +{
>> >> +     int ret;
>> >> +     int i;
>> >> +
>> >> +     struct xen_sysctl op = {
>> >> +             .cmd                    = XEN_SYSCTL_physinfo,
>> >> +             .interface_version      = XEN_SYSCTL_INTERFACE_VERSION,
>> >> +     };
>> >> +
>> >> +     ret = HYPERVISOR_sysctl(&op);
>> >> +     if (ret) {
>> >> +             pr_err("Hypervisor get physinfo error (%d)\n", ret);
>> >> +             return ret;
>> >> +     }
>> >> +
>> >> +     xen_nr_cpus = op.u.physinfo.nr_cpus;
>> >> +     if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
>> >> +             xen_nr_cpus = 0;
>> >> +             pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
>> >> +             return -EINVAL;
>> >> +     }
>> >> +
>> >> +     for (i = 0; i < xen_nr_cpus; i++) {
>> >> +             per_cpu(cpufreq_policy_cpu, i) = -1;
>> >> +             init_rwsem(&per_cpu(cpu_policy_rwsem, i));
>> >> +     }
>> >> +
>> >> +     cpufreq_wq = alloc_workqueue("xen_cpufreq", 0, 1);
>> >> +     if (!cpufreq_wq) {
>> >> +             pr_err("Create workqueue error\n");
>> >> +             ret = -ENOMEM;
>> >> +             goto err_create_wq;
>> >> +     }
>> >> +
>> >> +     return 0;
>> >> +
>> >> +err_create_wq:
>> >> +     xen_nr_cpus = 0;
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
>> >> +MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
>> >> +MODULE_LICENSE("GPL");
>> >> +
>> >> +core_initcall(xen_cpufreq_init);
>> >> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
>> >> index c57d5f6..ee3b154 100644
>> >> --- a/include/xen/interface/platform.h
>> >> +++ b/include/xen/interface/platform.h
>> >> @@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
>> >>  #define XEN_PX_PSS   2
>> >>  #define XEN_PX_PPC   4
>> >>  #define XEN_PX_PSD   8
>> >> +#define XEN_PX_DATA  16
>> >>
>> >>  struct xen_power_register {
>> >>       uint32_t     space_id;
>> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> >> index cf64566..9133110 100644
>> >> --- a/include/xen/interface/xen.h
>> >> +++ b/include/xen/interface/xen.h
>> >> @@ -81,6 +81,7 @@
>> >>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>> >>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
>> >>  #define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
>> >> +#define VIRQ_CPUFREQ    14 /* (DOM0) Notify cpufreq driver                */
>> >>
>> >>  /* 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 Nov 06 15:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOyK-00058y-2N; Thu, 06 Nov 2014 15:27:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmOyI-00058q-W2
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:27:39 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	53/2A-16982-A639B545; Thu, 06 Nov 2014 15:27:38 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415287653!8454417!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22150 invoked from network); 6 Nov 2014 15:27:35 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:27:35 -0000
Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuTZC0i3oX+V1lZRysZLe/ti4siiO3x@postini.com;
	Thu, 06 Nov 2014 07:27:35 PST
Received: by mail-qa0-f45.google.com with SMTP id dc16so891163qab.18
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:27:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=F7xTabXBLkMTFQQFAAVj2QiaO+q1S1SHtldMt6HVlvc=;
	b=k8drmxrsS+Qhg2P6Fu96oS57LpWdh/4k4iIche+PhuqTr1ZKHP6exI9bQdjpcb+4b4
	yCvjVcOWROeD3/Mo8gTxodJXmb8ZYst25UP0uFFIkWDA2frw0m8aMJzYwweTlszhbQAT
	zbUMPEaFvVHNYDXR2ePelwzNADHIHZ3IRYHMk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=F7xTabXBLkMTFQQFAAVj2QiaO+q1S1SHtldMt6HVlvc=;
	b=csFy/QYHf8efKs7fzGFrNlrMxrPkvNTfz+48BBQkim2ezkuTvr+0MrAmOcUuijLSEL
	ZptUCO65bKmkeCP02frL612m4HXDPju6NW2xQUEkLCZKJ5FR4MFemn6tYJrIAlKVQnaA
	ASZ4waFiUW++tmvWgEmrDrjp45v7F8KykbTfd3Kmj89fdoce7dBY35zmpuJGr1jY1eob
	+DjxgMhnTk652lVZLNY641LUkpTDO0/2hYs1DI/D4swhBOf4eH3NvN308lLszlpHehGR
	zbccZ+uyhPmw71/FYfwXfHR6xQLVm26Nx4kHE5jlhpLfgkLW8iRNFqYPXUyhgXtMq+9C
	Wi7A==
X-Gm-Message-State: ALoCoQksuKoCsGpNkDnhYGPdB6Olqe2tR54OsVbN2BACNQKJ1Tv67yQWO63qpRlzDO8wkXKjfYWlbUlJOSY1Bm68GE8PdKdKvtKz7R62l9I5s/s2gxNqQHf7PnHka3A83PkW8VenEI69pEOeshnBkQrU5LO30BVJJw==
X-Received: by 10.140.107.37 with SMTP id g34mr7498037qgf.38.1415287652488;
	Thu, 06 Nov 2014 07:27:32 -0800 (PST)
X-Received: by 10.140.107.37 with SMTP id g34mr7497913qgf.38.1415287651686;
	Thu, 06 Nov 2014 07:27:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:27:10 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061518510.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041621380.22875@kaball.uk.xensource.com>
	<CAN58jivYZMgVuhNNtj6Ks05h1iSZBeihKzqcEGi2wp41T4TxyA@mail.gmail.com>
	<alpine.DEB.2.02.1411061518510.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:27:10 +0200
Message-ID: <CAN58jistuz--3CaAqMei-2Ox6UEjRcE-ZRqezjhx3dY71tHs4g@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 9/9] xen/arm: cpufreq: add
	xen-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 6, 2014 at 5:20 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Tue, Nov 4, 2014 at 6:33 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> Xen changes frequencies on CPUs using this high-level
>> >> cpufreq driver.
>> >>
>> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >
>> > You CC the wrong email address for Rafael in the entire series.
>> Could anybody give me right address for Rafael?
>
> rjw@rjwysocki.net
>
> You can also find it by running ./scripts/get_maintainer.pl on the
> patch:
>
> sstabellini@st22:/local/scratch/sstabellini/linux-pvops-latest$ ./scripts/get_maintainer.pl ~/patch
> "Rafael J. Wysocki" <rjw@rjwysocki.net> (maintainer:CPU FREQUENCY DRI...)
> Viresh Kumar <viresh.kumar@linaro.org> (maintainer:CPU FREQUENCY DRI...)
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/3=33%)
> Boris Ostrovsky <boris.ostrovsky@oracle.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/3=33%)
> David Vrabel <david.vrabel@citrix.com> (supporter:XEN HYPERVISOR IN...,commit_signer:1/1=100%,commit_signer:3/3=100%,authored:1/3=33%,removed_lines:6/33=18%)
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> (commit_signer:1/1=100%)
> Tang Liang <liang.tang@oracle.com> (commit_signer:1/1=100%)
> Daniel Kiper <daniel.kiper@oracle.com> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:123/123=100%)
> Jan Beulich <jbeulich@suse.com> (commit_signer:1/1=100%)
> Ian Campbell <ian.campbell@citrix.com> (commit_signer:1/3=33%,authored:1/3=33%,removed_lines:3/33=9%)
> Juergen Gross <jgross@suse.com> (commit_signer:1/3=33%,authored:1/3=33%,added_lines:248/251=99%,removed_lines:24/33=73%)
> linux-kernel@vger.kernel.org (open list)
> linux-pm@vger.kernel.org (open list:CPU FREQUENCY DRI...)
> xen-devel@lists.xenproject.org (moderated list:XEN HYPERVISOR IN...)
Thank You for the clarification.


>> >>  drivers/cpufreq/Kconfig           |  20 +
>> >>  drivers/cpufreq/Makefile          |   1 +
>> >>  drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
>> >>  drivers/cpufreq/cpufreq_drv_ops.h |   4 +
>> >>  drivers/cpufreq/xen-cpufreq.c     | 869 ++++++++++++++++++++++++++++++++++++++
>> >>  include/xen/interface/platform.h  |   1 +
>> >>  include/xen/interface/xen.h       |   1 +
>> >>  7 files changed, 907 insertions(+), 2 deletions(-)
>> >>  create mode 100644 drivers/cpufreq/xen-cpufreq.c
>> >>
>> >> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
>> >> index f5a8f84..4847d8a 100644
>> >> --- a/drivers/cpufreq/Kconfig
>> >> +++ b/drivers/cpufreq/Kconfig
>> >> @@ -19,6 +19,26 @@ config CPU_FREQ
>> >>
>> >>         If in doubt, say N.
>> >>
>> >> +config XEN_CPUFREQ
>> >> +     bool "Xen Cpufreq driver"
>> >> +     depends on XEN_DOM0
>> >> +     depends on !CPUMASK_OFFSTACK
>> >> +     default n
>> >> +     select CPUFREQ_DRV_OPS
>> >> +     help
>> >> +       This driver uploads Power Management information to the Xen
>> >> +       hypervisor and changes CPUs frequency using CPU Frequency scaling
>> >> +       drivers.
>> >> +
>> >> +       To do that the driver uses CPU Frequency scaling drivers to parse
>> >> +       the Power Management data and uploads said information to the Xen
>> >> +       hypervisor. Then the Xen hypervisor can select the proper Pxx states.
>> >> +
>> >> +       Then the Xen hypervisor can change CPUs frequency by giving commands
>> >> +       via this driver to the CPU Frequency scaling driver.
>> >> +
>> >> +       If in doubt, say N.
>> >> +
>> >>  if CPUFREQ_DRV_OPS
>> >>
>> >>  config CPU_FREQ_TABLE
>> >> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> >> index f12a0d3..c8d5037 100644
>> >> --- a/drivers/cpufreq/Makefile
>> >> +++ b/drivers/cpufreq/Makefile
>> >> @@ -1,5 +1,6 @@
>> >>  # CPUfreq core
>> >>  obj-$(CONFIG_CPU_FREQ)                       += cpufreq.o
>> >> +obj-$(CONFIG_XEN_CPUFREQ)            += xen-cpufreq.o
>> >>  obj-$(CONFIG_CPUFREQ_DRV_OPS)                += cpufreq_drv_ops.o
>> >>  # CPUfreq stats
>> >>  obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
>> >> diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
>> >> index c971442..71c3357 100644
>> >> --- a/drivers/cpufreq/cpufreq_drv_ops.c
>> >> +++ b/drivers/cpufreq/cpufreq_drv_ops.c
>> >> @@ -18,6 +18,8 @@
>> >>  #include <linux/init.h>
>> >>  #include <linux/export.h>
>> >>
>> >> +#include <xen/xen.h>
>> >> +
>> >>  static struct cpufreq_drv_ops *ops;
>> >>
>> >>  struct kobject *get_cpufreq_global_kobject(void)
>> >> @@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
>> >>
>> >>  static int __init cpufreq_drv_ops_init(void)
>> >>  {
>> >> +     if (xen_initial_domain()) {
>> >> +#ifdef CONFIG_XEN_CPUFREQ
>> >> +             ops = &xen_cpufreq_drv_ops;
>> >> +             pr_debug("using xen_cpufreq_drv_ops\n");
>> >> +#endif
>> >> +     } else {
>> >>  #ifdef CONFIG_CPU_FREQ
>> >> -     ops = &kern_cpufreq_drv_ops;
>> >> -     pr_debug("using kern_cpufreq_drv_ops\n");
>> >> +             ops = &kern_cpufreq_drv_ops;
>> >> +             pr_debug("using kern_cpufreq_drv_ops\n");
>> >>  #endif
>> >> +     }
>> >>
>> >>       return 0;
>> >>  }
>> >> diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
>> >> index 5cc8e05..d02d509 100644
>> >> --- a/drivers/cpufreq/cpufreq_drv_ops.h
>> >> +++ b/drivers/cpufreq/cpufreq_drv_ops.h
>> >> @@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
>> >>  extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
>> >>  #endif
>> >>
>> >> +#ifdef CONFIG_XEN_CPUFREQ
>> >> +extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
>> >> +#endif
>> >> +
>> >>  #endif /* _CPUFREQ_DRV_OPS_H */
>> >> diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
>> >> new file mode 100644
>> >> index 0000000..21062c7
>> >> --- /dev/null
>> >> +++ b/drivers/cpufreq/xen-cpufreq.c
>> >> @@ -0,0 +1,869 @@
>> >> +/*
>> >> + *  Copyright (C) 2001 Russell King
>> >> + *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
>> >> + *
>> >> + *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
>> >> + *   Added handling for CPU hotplug
>> >> + *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
>> >> + *   Fix handling for CPU hotplug -- affected CPUs
>> >> + *
>> >> + *           (C) 2014 GlobalLogic Inc.
>> >> + *
>> >> + * Based on drivers/cpufreq/cpufreq.c
>> >> + *
>> >> + * 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.
>> >> + */
>> >> +
>> >> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> >> +
>> >> +#include <linux/kernel.h>
>> >> +#include <linux/module.h>
>> >> +#include <linux/init.h>
>> >> +#include <linux/notifier.h>
>> >> +#include <linux/types.h>
>> >> +#include <linux/slab.h>
>> >> +#include <linux/mutex.h>
>> >> +#include <linux/irq.h>
>> >> +#include <linux/workqueue.h>
>> >> +#include <linux/cpufreq.h>
>> >> +
>> >> +#include <trace/events/power.h>
>> >> +
>> >> +#include <xen/xen.h>
>> >> +#include <xen/events.h>
>> >> +#include <xen/interface/xen.h>
>> >> +#include <xen/interface/platform.h>
>> >> +#include <xen/interface/sysctl.h>
>> >> +#include <asm/xen/hypercall.h>
>> >> +#include <asm/xen/hypervisor.h>
>> >> +
>> >> +#include "cpufreq_drv_ops.h"
>> >> +
>> >> +static int xen_nr_cpus;
>> >> +static int xen_irq;
>> >> +
>> >> +#define for_each_xen_cpu(cpu, mask)                  \
>> >> +     for ((cpu) = -1;                                \
>> >> +             (cpu) = cpumask_next((cpu), (mask)),    \
>> >> +             (cpu) < xen_nr_cpus;)
>> >> +
>> >> +static struct cpufreq_driver *cpufreq_driver;
>> >> +static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
>> >> +
>> >> +static DEFINE_SPINLOCK(cpufreq_driver_lock);
>> >> +
>> >> +/*
>> >> + * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
>> >> + * all cpufreq/hotplug/workqueue/etc related lock issues.
>> >> + *
>> >> + * The rules for this semaphore:
>> >> + * - Any routine that wants to read from the policy structure will
>> >> + *   do a down_read on this semaphore.
>> >> + * - Any routine that will write to the policy structure and/or may take away
>> >> + *   the policy altogether (eg. CPU hotplug), will hold this lock in write
>> >> + *   mode before doing so.
>> >> + *
>> >> + * Additional rules:
>> >> + * - Governor routines that can be called in cpufreq hotplug path should not
>> >> + *   take this sem as top level hotplug notifier handler takes this.
>> >> + * - Lock should not be held across
>> >> + *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
>> >> + */
>> >> +static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
>> >> +static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
>> >> +
>> >> +#define lock_policy_rwsem(mode, cpu)                         \
>> >> +static int lock_policy_rwsem_##mode                          \
>> >> +(int cpu)                                                    \
>> >> +{                                                            \
>> >> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);      \
>> >> +     BUG_ON(policy_cpu == -1);                               \
>> >> +     down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));    \
>> >> +                                                             \
>> >> +     return 0;                                               \
>> >> +}
>> >> +
>> >> +lock_policy_rwsem(write, cpu);
>> >> +
>> >> +static void unlock_policy_rwsem_write(int cpu)
>> >> +{
>> >> +     int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
>> >> +     BUG_ON(policy_cpu == -1);
>> >> +     up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
>> >> +}
>> >> +
>> >> +/**
>> >> + * The "transition" notifier list for kernel code that needs to handle
>> >> + * changes to devices when the CPU clock speed changes.
>> >> + * The mutex locks this list.
>> >> + */
>> >> +static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
>> >> +
>> >> +static bool init_cpufreq_transition_notifier_list_called;
>> >> +static int __init init_cpufreq_transition_notifier_list(void)
>> >> +{
>> >> +     srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
>> >> +     init_cpufreq_transition_notifier_list_called = true;
>> >> +     return 0;
>> >> +}
>> >> +pure_initcall(init_cpufreq_transition_notifier_list);
>> >> +
>> >> +static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
>> >> +{
>> >> +     struct cpufreq_policy *data = NULL;
>> >> +     unsigned long flags;
>> >> +
>> >> +     if (cpu >= xen_nr_cpus)
>> >> +             goto err_out;
>> >> +
>> >> +     /* get the cpufreq driver */
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     if (!cpufreq_driver)
>> >> +             goto err_out_unlock;
>> >> +
>> >> +     /* get the CPU */
>> >> +     data = per_cpu(cpufreq_cpu_data, cpu);
>> >> +
>> >> +err_out_unlock:
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +err_out:
>> >> +     return data;
>> >> +}
>> >> +
>> >> +static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
>> >> +{
>> >> +     module_put(cpufreq_driver->owner);
>> >> +}
>> >> +
>> >> +static int push_data_to_hypervisor(struct cpufreq_policy *policy,
>> >> +                                struct cpufreq_frequency_table *table)
>> >> +{
>> >> +     int ret = 0;
>> >> +     unsigned int i;
>> >> +     unsigned int cpu;
>> >> +     uint32_t platform_limit = 0;
>> >> +     unsigned int max_freq = 0;
>> >> +     unsigned int state_count = 0;
>> >> +     unsigned int prev_freq = 0;
>> >> +     struct xen_processor_px *dst_states;
>> >> +     struct xen_processor_performance *dst_perf;
>> >> +     struct xen_platform_op op = {
>> >> +             .cmd                    = XENPF_set_processor_pminfo,
>> >> +             .interface_version      = XENPF_INTERFACE_VERSION,
>> >> +             .u.set_pminfo.type      = XEN_PM_PX,
>> >> +     };
>> >> +
>> >> +     dst_perf = &op.u.set_pminfo.perf;
>> >> +
>> >> +     /* Check freq table and find max frequency */
>> >> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> >> +             unsigned int freq = table[i].frequency;
>> >> +             if (freq == CPUFREQ_ENTRY_INVALID)
>> >> +                     continue;
>> >> +
>> >> +             if (table[i].index != state_count || freq <= prev_freq) {
>> >> +                     pr_err("Frequency table format error\n");
>> >> +                     return -EINVAL;
>> >> +             }
>> >> +
>> >> +             prev_freq = freq;
>> >> +             state_count++;
>> >> +             if (freq > max_freq)
>> >> +                     max_freq = freq;
>> >> +     }
>> >> +
>> >> +     if (!state_count)
>> >> +             return -EINVAL;
>> >> +
>> >> +     dst_perf->state_count = state_count;
>> >> +
>> >> +     dst_states = kcalloc(state_count,
>> >> +                          sizeof(struct xen_processor_px), GFP_KERNEL);
>> >> +
>> >> +     if (!dst_states)
>> >> +             return -ENOMEM;
>> >> +
>> >> +     set_xen_guest_handle(dst_perf->states, dst_states);
>> >> +
>> >> +     /*
>> >> +      * Freq table should start from lower values
>> >> +      * dst_states should start from higer values
>> >> +      */
>> >> +     for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> >> +             unsigned int freq = table[i].frequency;
>> >> +             unsigned int tbl_index = state_count - 1 - table[i].index;
>> >> +             if (freq == CPUFREQ_ENTRY_INVALID)
>> >> +                     continue;
>> >> +
>> >> +             if (freq == max_freq)
>> >> +                     platform_limit = tbl_index;
>> >> +
>> >> +             dst_states[tbl_index].core_frequency = freq / 1000;
>> >> +             dst_states[tbl_index].transition_latency =
>> >> +                             policy->cpuinfo.transition_latency / 1000;
>> >> +     }
>> >> +
>> >> +     dst_perf->shared_type = policy->shared_type;
>> >> +     dst_perf->platform_limit = platform_limit;
>> >> +     dst_perf->domain_info.domain = policy->cpu;
>> >> +     dst_perf->domain_info.num_processors = xen_nr_cpus;
>> >> +     dst_perf->flags = XEN_PX_DATA;
>> >> +
>> >> +     for_each_xen_cpu(cpu, policy->cpus) {
>> >> +             op.u.set_pminfo.id = cpu;
>> >> +             ret = HYPERVISOR_dom0_op(&op);
>> >> +             if (ret) {
>> >> +                     pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
>> >> +                     goto err_free_states;
>> >> +             }
>> >> +             pr_debug("CPU%u - P-states uploaded\n", cpu);
>> >> +
>> >> +             for (i = 0; i < dst_perf->state_count; i++) {
>> >> +                     pr_debug("    state %d: %d MHz, %d uS\n",
>> >> +                              i, (u32) dst_states[i].core_frequency,
>> >> +                              (u32) dst_states[i].transition_latency);
>> >> +             }
>> >> +     }
>> >> +
>> >> +err_free_states:
>> >> +     kfree(dst_states);
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +/*
>> >> + * Returns:
>> >> + *   Negative: Failure
>> >> + *   0:        Success
>> >> + *   Positive: When we have a managed CPU and the sysfs got symlinked
>> >> + */
>> >> +static int xen_cpufreq_add_dev_policy(unsigned int cpu,
>> >> +                               struct cpufreq_policy *policy)
>> >> +{
>> >> +     int ret = 0;
>> >> +#ifdef CONFIG_SMP
>> >> +     unsigned long flags;
>> >> +     unsigned int j;
>> >> +
>> >> +     for_each_cpu(j, policy->cpus) {
>> >> +             struct cpufreq_policy *managed_policy;
>> >> +
>> >> +             if (cpu == j)
>> >> +                     continue;
>> >> +
>> >> +             /* Check for existing affected CPUs.
>> >> +              * They may not be aware of it due to CPU Hotplug.
>> >> +              * cpufreq_cpu_put is called when the device is removed
>> >> +              * in __cpufreq_remove_dev()
>> >> +              */
>> >> +             managed_policy = xen_cpufreq_cpu_get(j);
>> >> +             if (unlikely(managed_policy)) {
>> >> +                     /* Set proper policy_cpu */
>> >> +                     unlock_policy_rwsem_write(cpu);
>> >> +                     per_cpu(cpufreq_policy_cpu, cpu) =
>> >> +                                             managed_policy->cpu;
>> >> +
>> >> +                     if (lock_policy_rwsem_write(cpu) < 0) {
>> >> +                             /* Should not go through policy unlock path */
>> >> +                             if (cpufreq_driver->exit)
>> >> +                                     cpufreq_driver->exit(policy);
>> >> +                             xen_cpufreq_cpu_put(managed_policy);
>> >> +                             return -EBUSY;
>> >> +                     }
>> >> +
>> >> +                     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +                     cpumask_copy(managed_policy->cpus, policy->cpus);
>> >> +                     per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
>> >> +                     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +
>> >> +                     pr_debug("CPU already managed, adding link\n");
>> >> +
>> >> +                     /*
>> >> +                      * Success. We only needed to be added to the mask.
>> >> +                      * Call driver->exit() because only the cpu parent of
>> >> +                      * the kobj needed to call init().
>> >> +                      */
>> >> +                     if (cpufreq_driver->exit)
>> >> +                             cpufreq_driver->exit(policy);
>> >> +
>> >> +                     return 1;
>> >> +             }
>> >> +     }
>> >> +#endif
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +/**
>> >> + * xen_cpufreq_add_dev - add a CPU device
>> >> + *
>> >> + * Adds the cpufreq interface for a CPU device.
>> >> + */
>> >> +static int xen_cpufreq_add_dev(unsigned int cpu)
>> >> +{
>> >> +     int ret = 0;
>> >> +     struct cpufreq_policy *policy;
>> >> +     unsigned long flags;
>> >> +     unsigned int j;
>> >> +
>> >> +     pr_debug("adding CPU %u\n", cpu);
>> >> +
>> >> +#ifdef CONFIG_SMP
>> >> +     /* check whether a different CPU already registered this
>> >> +      * CPU because it is in the same boat. */
>> >> +     policy = xen_cpufreq_cpu_get(cpu);
>> >> +     if (unlikely(policy)) {
>> >> +             xen_cpufreq_cpu_put(policy);
>> >> +             return 0;
>> >> +     }
>> >> +#endif
>> >> +
>> >> +     if (!try_module_get(cpufreq_driver->owner)) {
>> >> +             ret = -EINVAL;
>> >> +             goto module_out;
>> >> +     }
>> >> +
>> >> +     ret = -ENOMEM;
>> >> +     policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
>> >> +     if (!policy)
>> >> +             goto nomem_out;
>> >> +
>> >> +     if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
>> >> +             goto err_free_policy;
>> >> +
>> >> +     if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
>> >> +             goto err_free_cpumask;
>> >> +
>> >> +     policy->cpu = cpu;
>> >> +     cpumask_copy(policy->cpus, cpumask_of(cpu));
>> >> +
>> >> +     /* Initially set CPU itself as the policy_cpu */
>> >> +     per_cpu(cpufreq_policy_cpu, cpu) = cpu;
>> >> +     ret = (lock_policy_rwsem_write(cpu) < 0);
>> >> +     WARN_ON(ret);
>> >> +
>> >> +     /* call driver. From then on the cpufreq must be able
>> >> +      * to accept all calls to ->verify and ->setpolicy for this CPU
>> >> +      */
>> >> +     ret = cpufreq_driver->init(policy);
>> >> +     if (ret) {
>> >> +             pr_debug("initialization failed\n");
>> >> +             goto err_unlock_policy;
>> >> +     }
>> >> +     ret = xen_cpufreq_add_dev_policy(cpu, policy);
>> >> +     if (ret) {
>> >> +             if (ret > 0)
>> >> +                     /* This is a managed cpu, symlink created,
>> >> +                        exit with 0 */
>> >> +                     ret = 0;
>> >> +             goto err_unlock_policy;
>> >> +     }
>> >> +
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +     for_each_cpu(j, policy->cpus) {
>> >> +             per_cpu(cpufreq_cpu_data, j) = policy;
>> >> +             per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
>> >> +     }
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     unlock_policy_rwsem_write(cpu);
>> >> +
>> >> +     module_put(cpufreq_driver->owner);
>> >> +     pr_debug("initialization complete\n");
>> >> +
>> >> +     return 0;
>> >> +
>> >> +err_unlock_policy:
>> >> +     unlock_policy_rwsem_write(cpu);
>> >> +     free_cpumask_var(policy->related_cpus);
>> >> +err_free_cpumask:
>> >> +     free_cpumask_var(policy->cpus);
>> >> +err_free_policy:
>> >> +     kfree(policy);
>> >> +nomem_out:
>> >> +     module_put(cpufreq_driver->owner);
>> >> +module_out:
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +/**
>> >> + * __cpufreq_remove_dev - remove a CPU device
>> >> + *
>> >> + * Removes the cpufreq interface for a CPU device.
>> >> + * Caller should already have policy_rwsem in write mode for this CPU.
>> >> + * This routine frees the rwsem before returning.
>> >> + */
>> >> +static int __cpufreq_remove_dev(unsigned int cpu)
>> >> +{
>> >> +     unsigned long flags;
>> >> +     struct cpufreq_policy *data;
>> >> +#ifdef CONFIG_SMP
>> >> +     unsigned int j;
>> >> +#endif
>> >> +
>> >> +     pr_debug("unregistering CPU %u\n", cpu);
>> >> +
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +     data = per_cpu(cpufreq_cpu_data, cpu);
>> >> +
>> >> +     if (!data) {
>> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +             unlock_policy_rwsem_write(cpu);
>> >> +             return -EINVAL;
>> >> +     }
>> >> +     per_cpu(cpufreq_cpu_data, cpu) = NULL;
>> >> +
>> >> +
>> >> +#ifdef CONFIG_SMP
>> >> +     /* if this isn't the CPU which is the parent of the kobj, we
>> >> +      * only need to unlink, put and exit
>> >> +      */
>> >> +     if (unlikely(cpu != data->cpu)) {
>> >> +             pr_debug("removing link\n");
>> >> +             cpumask_clear_cpu(cpu, data->cpus);
>> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +             xen_cpufreq_cpu_put(data);
>> >> +             unlock_policy_rwsem_write(cpu);
>> >> +             return 0;
>> >> +     }
>> >> +#endif
>> >> +
>> >> +#ifdef CONFIG_SMP
>> >> +
>> >> +     /* if we have other CPUs still registered, we need to unlink them,
>> >> +      * or else wait_for_completion below will lock up. Clean the
>> >> +      * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
>> >> +      * the sysfs links afterwards.
>> >> +      */
>> >> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
>> >> +             for_each_cpu(j, data->cpus) {
>> >> +                     if (j == cpu)
>> >> +                             continue;
>> >> +                     per_cpu(cpufreq_cpu_data, j) = NULL;
>> >> +             }
>> >> +     }
>> >> +
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     if (unlikely(cpumask_weight(data->cpus) > 1)) {
>> >> +             for_each_cpu(j, data->cpus) {
>> >> +                     if (j == cpu)
>> >> +                             continue;
>> >> +                     pr_debug("removing link for cpu %u\n", j);
>> >> +                     unlock_policy_rwsem_write(cpu);
>> >> +                     lock_policy_rwsem_write(cpu);
>> >> +                     xen_cpufreq_cpu_put(data);
>> >> +             }
>> >> +     }
>> >> +#else
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +#endif
>> >> +
>> >> +     unlock_policy_rwsem_write(cpu);
>> >> +
>> >> +     lock_policy_rwsem_write(cpu);
>> >> +     if (cpufreq_driver->exit)
>> >> +             cpufreq_driver->exit(data);
>> >> +     unlock_policy_rwsem_write(cpu);
>> >> +
>> >> +     free_cpumask_var(data->related_cpus);
>> >> +     free_cpumask_var(data->cpus);
>> >> +     kfree(data);
>> >> +
>> >> +     return 0;
>> >> +}
>> >> +
>> >> +static int cpufreq_remove_dev(unsigned int cpu)
>> >> +{
>> >> +     int retval;
>> >> +
>> >> +     if (unlikely(lock_policy_rwsem_write(cpu)))
>> >> +             BUG();
>> >> +
>> >> +     retval = __cpufreq_remove_dev(cpu);
>> >> +     return retval;
>> >> +}
>> >> +
>> >> +/*********************************************************************
>> >> + *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
>> >> + *********************************************************************/
>> >> +
>> >> +/**
>> >> + * adjust_jiffies - adjust the system "loops_per_jiffy"
>> >> + *
>> >> + * This function alters the system "loops_per_jiffy" for the clock
>> >> + * speed change. Note that loops_per_jiffy cannot be updated on SMP
>> >> + * systems as each CPU might be scaled differently. So, use the arch
>> >> + * per-CPU loops_per_jiffy value wherever possible.
>> >> + */
>> >> +#ifndef CONFIG_SMP
>> >> +static unsigned long l_p_j_ref;
>> >> +static unsigned int  l_p_j_ref_freq;
>> >> +
>> >> +static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
>> >> +{
>> >> +     if (ci->flags & CPUFREQ_CONST_LOOPS)
>> >> +             return;
>> >> +
>> >> +     if (!l_p_j_ref_freq) {
>> >> +             l_p_j_ref = loops_per_jiffy;
>> >> +             l_p_j_ref_freq = ci->old;
>> >> +             pr_debug("saving %lu as reference value for loops_per_jiffy; "
>> >> +                     "freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
>> >> +     }
>> >> +     if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
>> >> +         (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
>> >> +             loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
>> >> +                                                             ci->new);
>> >> +             pr_debug("scaling loops_per_jiffy to %lu "
>> >> +                     "for frequency %u kHz\n", loops_per_jiffy, ci->new);
>> >> +     }
>> >> +}
>> >> +#else
>> >> +static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
>> >> +{
>> >> +     return;
>> >> +}
>> >> +#endif
>> >
>> > There is quite a lot of code duplication with cpufreq.c, I don't think
>> > that is going to be acceptable for the upstream maintainers.
>> It is very complicated to use an common code. Some functions copied
>> and modified. I'll try to do something in the future.
>>
>> >> +/**
>> >> + * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
>> >> + * on frequency transition.
>> >> + *
>> >> + * This function calls the transition notifiers and the "adjust_jiffies"
>> >> + * function. It is called twice on all CPU frequency changes that have
>> >> + * external effects.
>> >> + */
>> >> +void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
>> >> +                                unsigned int state)
>> >> +{
>> >> +     struct cpufreq_policy *policy;
>> >> +
>> >> +     BUG_ON(irqs_disabled());
>> >> +
>> >> +     freqs->flags = cpufreq_driver->flags;
>> >> +     pr_debug("notification %u of frequency transition to %u kHz\n",
>> >> +              state, freqs->new);
>> >> +
>> >> +     policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
>> >> +     switch (state) {
>> >> +     case CPUFREQ_PRECHANGE:
>> >> +             /* detect if the driver reported a value as "old frequency"
>> >> +              * which is not equal to what the cpufreq core thinks is
>> >> +              * "old frequency".
>> >> +              */
>> >> +             if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
>> >> +                     if ((policy) && (policy->cpu == freqs->cpu) &&
>> >> +                         (policy->cur) && (policy->cur != freqs->old)) {
>> >> +                             pr_debug("Warning: CPU frequency is"
>> >> +                                      " %u, cpufreq assumed %u kHz.\n",
>> >> +                                      freqs->old, policy->cur);
>> >> +                             freqs->old = policy->cur;
>> >> +                     }
>> >> +             }
>> >> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
>> >> +                                      CPUFREQ_PRECHANGE, freqs);
>> >> +             adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
>> >> +             break;
>> >> +
>> >> +     case CPUFREQ_POSTCHANGE:
>> >> +             adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
>> >> +             pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
>> >> +                      (unsigned long)freqs->cpu);
>> >> +             trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
>> >> +             trace_cpu_frequency(freqs->new, freqs->cpu);
>> >> +             srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
>> >> +                                      CPUFREQ_POSTCHANGE, freqs);
>> >> +             if (likely(policy) && likely(policy->cpu == freqs->cpu))
>> >> +                     policy->cur = freqs->new;
>> >> +             break;
>> >> +     }
>> >> +}
>> >> +
>> >> +/*********************************************************************
>> >> + *                              GOVERNORS                            *
>> >> + *********************************************************************/
>> >> +
>> >> +int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
>> >> +                             unsigned int target_freq,
>> >> +                             unsigned int relation)
>> >> +{
>> >> +     int retval = -EINVAL;
>> >> +     unsigned int old_target_freq = target_freq;
>> >> +
>> >> +     /* Make sure that target_freq is within supported range */
>> >> +     if (target_freq > policy->max)
>> >> +             target_freq = policy->max;
>> >> +     if (target_freq < policy->min)
>> >> +             target_freq = policy->min;
>> >> +
>> >> +     pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
>> >> +              policy->cpu, target_freq, relation, old_target_freq);
>> >> +
>> >> +     if (target_freq == policy->cur)
>> >> +             return 0;
>> >> +
>> >> +     if (cpufreq_driver->target)
>> >> +             retval = cpufreq_driver->target(policy, target_freq,
>> >> +                                                 relation);
>> >> +
>> >> +     return retval;
>> >> +}
>> >> +
>> >> +int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
>> >> +                           unsigned int target_freq,
>> >> +                           unsigned int relation)
>> >> +{
>> >> +     int ret = -EINVAL;
>> >> +
>> >> +     if (!policy)
>> >> +             goto no_policy;
>> >> +
>> >> +     if (unlikely(lock_policy_rwsem_write(policy->cpu)))
>> >> +             goto fail;
>> >> +
>> >> +     ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
>> >> +
>> >> +     unlock_policy_rwsem_write(policy->cpu);
>> >> +
>> >> +fail:
>> >> +     xen_cpufreq_cpu_put(policy);
>> >> +no_policy:
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +/*********************************************************************
>> >> + *                    HANDLE COMMANDS FROM XEN                       *
>> >> + *********************************************************************/
>> >> +static void cpufreq_work_hnd(struct work_struct *w);
>> >> +
>> >> +static struct workqueue_struct *cpufreq_wq;
>> >> +static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
>> >> +
>> >> +static void cpufreq_work_hnd(struct work_struct *w)
>> >> +{
>> >> +     int ret;
>> >> +     struct cpufreq_policy *policy;
>> >> +     struct cpufreq_sh_info *cpufreq_info;
>> >> +
>> >> +     cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
>> >> +
>> >> +     policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
>> >> +     ret = xen_cpufreq_driver_target(policy,
>> >> +                                     cpufreq_info->freq,
>> >> +                                     cpufreq_info->relation);
>> >> +
>> >> +     cpufreq_info->result = ret;
>> >> +}
>> >
>> > No barriers? No locking?
>> I'll add barriers in the next patch-set.
>>
>> >> +static irqreturn_t cpufreq_interrupt(int irq, void *data)
>> >> +{
>> >> +     queue_work(cpufreq_wq, &cpufreq_work);
>> >> +     return IRQ_HANDLED;
>> >> +}
>> >> +
>> >> +/*********************************************************************
>> >> + *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
>> >> + *********************************************************************/
>> >> +
>> >> +/**
>> >> + * xen_cpufreq_register_driver - register a CPU Frequency driver
>> >> + * @driver_data: A struct cpufreq_driver containing the values#
>> >> + * submitted by the CPU Frequency driver.
>> >> + *
>> >> + *   Registers a CPU Frequency driver to this core code. This code
>> >> + * returns zero on success, -EBUSY when another driver got here first
>> >> + * (and isn't unregistered in the meantime).
>> >> + *
>> >> + */
>> >> +int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
>> >> +{
>> >> +     unsigned long flags;
>> >> +     int ret;
>> >> +     unsigned int cpu;
>> >> +     struct cpufreq_frequency_table *table;
>> >> +     struct cpufreq_policy *policy;
>> >> +     cpumask_var_t pushed_cpus;
>> >> +     int irq;
>> >> +
>> >> +     if (!xen_nr_cpus)
>> >> +             return -EPROBE_DEFER;
>> >> +
>> >> +     if (!driver_data || !driver_data->verify || !driver_data->init ||
>> >> +         (!driver_data->target))
>> >> +             return -EINVAL;
>> >> +
>> >> +     pr_debug("trying to register driver %s\n", driver_data->name);
>> >> +
>> >> +     if (driver_data->setpolicy)
>> >> +             driver_data->flags |= CPUFREQ_CONST_LOOPS;
>> >> +
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     if (cpufreq_driver) {
>> >> +             spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +             return -EBUSY;
>> >> +     }
>> >> +     cpufreq_driver = driver_data;
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     irq = bind_virq_to_irq(VIRQ_CPUFREQ, 0);
>> >> +     if (irq < 0) {
>> >> +             pr_err("Bind virq (%d) error (%d)\n", VIRQ_CPUFREQ, irq);
>> >> +             ret = irq;
>> >> +             goto err_remove_drv;
>> >> +     }
>> >> +
>> >> +     irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN|IRQ_NOPROBE);
>> >> +
>> >> +     ret = request_irq(irq, cpufreq_interrupt, 0,
>> >> +                        "xen_cpufreq", NULL);
>> >> +
>> >> +     if (ret < 0) {
>> >> +             pr_err("Request irq (%d) error (%d)\n", irq, ret);
>> >> +             goto err_unbind_from_irqhnd;
>> >> +     }
>> >> +
>> >> +     xen_irq = irq;
>> >> +
>> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
>> >> +             ret = xen_cpufreq_add_dev(cpu);
>> >> +             if (ret)
>> >> +                     goto err_remove_cpu;
>> >> +     }
>> >> +
>> >> +     if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
>> >> +             goto err_remove_cpu;
>> >> +
>> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
>> >> +             if (cpumask_test_cpu(cpu, pushed_cpus))
>> >> +                     continue;
>> >> +
>> >> +             policy = xen_cpufreq_cpu_get(cpu);
>> >> +             if (!policy) {
>> >> +                     ret = -EINVAL;
>> >> +                     goto err_free_cpumask;
>> >> +             }
>> >> +
>> >> +             cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
>> >> +             table = cpufreq_frequency_get_table(policy->cpu);
>> >> +             if (!table) {
>> >> +                     ret = -EINVAL;
>> >> +                     goto err_free_cpumask;
>> >> +             }
>> >> +
>> >> +             ret = push_data_to_hypervisor(policy, table);
>> >> +             if (ret)
>> >> +                     goto err_free_cpumask;
>> >> +     }
>> >> +
>> >> +     free_cpumask_var(pushed_cpus);
>> >> +
>> >> +     pr_debug("driver %s up and running\n", driver_data->name);
>> >> +
>> >> +     return 0;
>> >> +
>> >> +err_free_cpumask:
>> >> +     free_cpumask_var(pushed_cpus);
>> >> +err_remove_cpu:
>> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
>> >> +             cpufreq_remove_dev(cpu);
>> >> +err_unbind_from_irqhnd:
>> >> +     unbind_from_irqhandler(irq, NULL);
>> >> +err_remove_drv:
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +     cpufreq_driver = NULL;
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +/**
>> >> + * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
>> >> + *
>> >> + *    Unregister the current CPUFreq driver. Only call this if you have
>> >> + * the right to do so, i.e. if you have succeeded in initialising before!
>> >> + * Returns zero if successful, and -EINVAL if the cpufreq_driver is
>> >> + * currently not initialised.
>> >> + */
>> >> +int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
>> >> +{
>> >> +     unsigned long flags;
>> >> +     unsigned int cpu;
>> >> +
>> >> +     if (!cpufreq_driver || (driver != cpufreq_driver))
>> >> +             return -EINVAL;
>> >> +
>> >> +     pr_debug("unregistering driver %s\n", driver->name);
>> >> +
>> >> +     unbind_from_irqhandler(xen_irq, NULL);
>> >> +
>> >> +     for (cpu = 0; cpu < xen_nr_cpus; cpu++)
>> >> +             cpufreq_remove_dev(cpu);
>> >> +
>> >> +     spin_lock_irqsave(&cpufreq_driver_lock, flags);
>> >> +     cpufreq_driver = NULL;
>> >> +     spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> >> +
>> >> +     return 0;
>> >> +}
>> >> +
>> >> +struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
>> >> +     .notify_transition = xen_cpufreq_notify_transition,
>> >> +     .register_driver = xen_cpufreq_register_driver,
>> >> +     .unregister_driver = xen_cpufreq_unregister_driver,
>> >> +};
>> >> +
>> >> +static int __init xen_cpufreq_init(void)
>> >> +{
>> >> +     int ret;
>> >> +     int i;
>> >> +
>> >> +     struct xen_sysctl op = {
>> >> +             .cmd                    = XEN_SYSCTL_physinfo,
>> >> +             .interface_version      = XEN_SYSCTL_INTERFACE_VERSION,
>> >> +     };
>> >> +
>> >> +     ret = HYPERVISOR_sysctl(&op);
>> >> +     if (ret) {
>> >> +             pr_err("Hypervisor get physinfo error (%d)\n", ret);
>> >> +             return ret;
>> >> +     }
>> >> +
>> >> +     xen_nr_cpus = op.u.physinfo.nr_cpus;
>> >> +     if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
>> >> +             xen_nr_cpus = 0;
>> >> +             pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
>> >> +             return -EINVAL;
>> >> +     }
>> >> +
>> >> +     for (i = 0; i < xen_nr_cpus; i++) {
>> >> +             per_cpu(cpufreq_policy_cpu, i) = -1;
>> >> +             init_rwsem(&per_cpu(cpu_policy_rwsem, i));
>> >> +     }
>> >> +
>> >> +     cpufreq_wq = alloc_workqueue("xen_cpufreq", 0, 1);
>> >> +     if (!cpufreq_wq) {
>> >> +             pr_err("Create workqueue error\n");
>> >> +             ret = -ENOMEM;
>> >> +             goto err_create_wq;
>> >> +     }
>> >> +
>> >> +     return 0;
>> >> +
>> >> +err_create_wq:
>> >> +     xen_nr_cpus = 0;
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
>> >> +MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
>> >> +MODULE_LICENSE("GPL");
>> >> +
>> >> +core_initcall(xen_cpufreq_init);
>> >> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
>> >> index c57d5f6..ee3b154 100644
>> >> --- a/include/xen/interface/platform.h
>> >> +++ b/include/xen/interface/platform.h
>> >> @@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
>> >>  #define XEN_PX_PSS   2
>> >>  #define XEN_PX_PPC   4
>> >>  #define XEN_PX_PSD   8
>> >> +#define XEN_PX_DATA  16
>> >>
>> >>  struct xen_power_register {
>> >>       uint32_t     space_id;
>> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> >> index cf64566..9133110 100644
>> >> --- a/include/xen/interface/xen.h
>> >> +++ b/include/xen/interface/xen.h
>> >> @@ -81,6 +81,7 @@
>> >>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>> >>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
>> >>  #define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
>> >> +#define VIRQ_CPUFREQ    14 /* (DOM0) Notify cpufreq driver                */
>> >>
>> >>  /* 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 Nov 06 15:27:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOyW-0005BU-Lb; Thu, 06 Nov 2014 15:27:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmOyU-0005B8-TO
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:27:51 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	DF/6D-27623-6739B545; Thu, 06 Nov 2014 15:27:50 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415287668!6462166!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31725 invoked from network); 6 Nov 2014 15:27:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:27:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190216078"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:26:26 -0500
Received: from etemp.uk.xensource.com ([10.80.228.66]
	helo=etemp.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <paul.durrant@citrix.com>)	id 1XmOx8-0000lT-Gt;
	Thu, 06 Nov 2014 15:26:26 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 6 Nov 2014 15:26:24 +0000
Message-ID: <1415287584-11322-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Paul Durrant <paul.durrant@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH v2] x86/hvm: Extend HVM cpuid leaf with vcpu 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

To perform certain hypercalls HVM guests need to use Xen's idea of
vcpu id, which may well not match the guest OS idea of CPU id.
This patch adds vcpu id to the HVM cpuid leaf allowing the guest
to build a mapping.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
 xen/arch/x86/hvm/hvm.c              |    4 ++++
 xen/include/public/arch-x86/cpuid.h |    5 +++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 78f519d..d9a5706 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t sub_idx,
          * foreign pages) has valid IOMMU entries.
          */
         *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
+
+        /* Indicate presence of vcpu id and set it in ebx */
+        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
+        *ebx = current->vcpu_id;
     }
 }
 
diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
index 6005dfe..d709340 100644
--- a/xen/include/public/arch-x86/cpuid.h
+++ b/xen/include/public/arch-x86/cpuid.h
@@ -76,13 +76,14 @@
 /*
  * Leaf 5 (0x40000x04)
  * HVM-specific features
+ * EAX: Features
+ * EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT flag)
  */
-
-/* EAX Features */
 #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized APIC registers */
 #define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized x2APIC accesses */
 /* Memory mapped from other domains has valid IOMMU entries */
 #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
+#define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu id is present in EBX */
 
 #define XEN_CPUID_MAX_NUM_LEAVES 4
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:27:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOyW-0005BU-Lb; Thu, 06 Nov 2014 15:27:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmOyU-0005B8-TO
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:27:51 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	DF/6D-27623-6739B545; Thu, 06 Nov 2014 15:27:50 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415287668!6462166!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31725 invoked from network); 6 Nov 2014 15:27:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:27:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190216078"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:26:26 -0500
Received: from etemp.uk.xensource.com ([10.80.228.66]
	helo=etemp.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <paul.durrant@citrix.com>)	id 1XmOx8-0000lT-Gt;
	Thu, 06 Nov 2014 15:26:26 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 6 Nov 2014 15:26:24 +0000
Message-ID: <1415287584-11322-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Paul Durrant <paul.durrant@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH v2] x86/hvm: Extend HVM cpuid leaf with vcpu 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

To perform certain hypercalls HVM guests need to use Xen's idea of
vcpu id, which may well not match the guest OS idea of CPU id.
This patch adds vcpu id to the HVM cpuid leaf allowing the guest
to build a mapping.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
 xen/arch/x86/hvm/hvm.c              |    4 ++++
 xen/include/public/arch-x86/cpuid.h |    5 +++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 78f519d..d9a5706 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t sub_idx,
          * foreign pages) has valid IOMMU entries.
          */
         *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
+
+        /* Indicate presence of vcpu id and set it in ebx */
+        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
+        *ebx = current->vcpu_id;
     }
 }
 
diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
index 6005dfe..d709340 100644
--- a/xen/include/public/arch-x86/cpuid.h
+++ b/xen/include/public/arch-x86/cpuid.h
@@ -76,13 +76,14 @@
 /*
  * Leaf 5 (0x40000x04)
  * HVM-specific features
+ * EAX: Features
+ * EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT flag)
  */
-
-/* EAX Features */
 #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized APIC registers */
 #define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized x2APIC accesses */
 /* Memory mapped from other domains has valid IOMMU entries */
 #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
+#define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu id is present in EBX */
 
 #define XEN_CPUID_MAX_NUM_LEAVES 4
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:28:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOz4-0005IT-2z; Thu, 06 Nov 2014 15:28:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XmOz1-0005Ht-PS
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:28:24 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	7B/3F-02696-7939B545; Thu, 06 Nov 2014 15:28:23 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415287699!11866482!1
X-Originating-IP: [209.85.220.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14777 invoked from network); 6 Nov 2014 15:28:20 -0000
Received: from mail-vc0-f174.google.com (HELO mail-vc0-f174.google.com)
	(209.85.220.174)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:28:20 -0000
Received: by mail-vc0-f174.google.com with SMTP id im17so652399vcb.19
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:28:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Ko/E/hgvTswLyTISYvTeVH44ZNbX0scGn7dn8zQN1BQ=;
	b=mCUUwzzzQrWt/Qzym3dZpOhpyL9xE/GtpFEPhxRNczi5q8asXjkuvCNZyZyt60aVTE
	cLn5NTivGuwk1WRhMnoA5qgMQ93jF9TfO/gLEyjuDmHqXJk7FJSY+rg6ioRP+sY2P38F
	1eNdxJNKwKoERRXTX4m9lwV7Gez36s2WGktbEMXn27OLW4kit+eV2ecUJ5eWspwcTXk/
	IMDbnMiSy3Nk40n4gmTJkvIlI2WJjUYCJeVi22Vv47jTWvJkAbfpjEZQt8SVdvxzmjvc
	I2DEUtGiq26IWqIVtdbC8Gi3B5od9Bs7dba5eerM8dcBRaRIqVLtZBswzX/rRVms59Hf
	OQFg==
MIME-Version: 1.0
X-Received: by 10.220.202.199 with SMTP id ff7mr268247vcb.57.1415287698719;
	Thu, 06 Nov 2014 07:28:18 -0800 (PST)
Received: by 10.221.57.8 with HTTP; Thu, 6 Nov 2014 07:28:18 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>
	<CAAiw7Jmg+p0--fFYcRnMDA2DdQ7Ss5zjH9iuLHeX=TpBPZYGbA@mail.gmail.com>
	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>
	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>
	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
Date: Thu, 6 Nov 2014 20:58:18 +0530
Message-ID: <CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, JBeulich@suse.com, 
	Julien Grall <julien.grall@linaro.org>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>
Content-Type: multipart/mixed; boundary=089e0158b1568d74910507325860
Cc: manish.jaggi@caviumnetworks.com, Ryan Wilson <hap9@epoch.ncsc.mil>,
	Vijay Kilari <vijay.kilari@gmail.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--089e0158b1568d74910507325860
Content-Type: text/plain; charset=UTF-8

On 20 October 2014 20:24, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 20 Oct 2014, manish jaggi wrote:
>> On 8 October 2014 20:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
>> >> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
>> >> >> Thanks for replying. As detailed in this thread, I need to create a
>> >> >> hypercall that would send the following information to Xen at the time
>> >> >> of PCI attach
>> >> >> { sbdf , domU sbdf, domainId }.
>> >> >> I am not able to find a way to get the domU sbdf from dom0 at the time
>> >> >> of pci-attach.
>> >> >
>> >> > I think it would need to be done by the pciback driver in the dom0
>> >> > kernel, which AFAIK is the thing which consistently knows both physical
>> >> > and virtual sbdf for a given assigned device.
>> >> >
>> >> > Ian.
>> >> >
>> >> Correct, can you point out which data structure holds the domU sbdf
>> >> corresponding to the actual sbdf in pciback.
>> >
>> > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
>> > is that what you are referring to?
>>
>> Xen docs also mention about xen-pciback.passthrough=1. If I set this
>> in dom0 i see that the device is enumerated as the same sbdf in domU,
>> but
>> a) it is not shown in lspci
>> b) no front-back communication is done for reading devices configuration space
>> .
>> Is option useful / fully implemented for ARM ?
>
> I don't think this option is very useful. I wouldn't worry about it for
> now.

Stefano / Ian / Konard / Julien,

Attached is a first raw code FYI RFC Patches of PCI passthrough support on ARM.
- Linux Patch (3.18)
- Xen Patch  (4.5 staging)
---(Smmu changes not included, thats a separate patch altogether)
This patches show the logic, at places need of improvements in code
organization/quality. I wanted to share to get initial comments.
This is working with SRIOV as well.

Please have a look and let me know your positive comments

--089e0158b1568d74910507325860
Content-Type: application/octet-stream; 
	name="0002-Removing-X86-as-a-dependency-on-XEN_PCI_FRONTEND-and.patch"
Content-Disposition: attachment; 
	filename="0002-Removing-X86-as-a-dependency-on-XEN_PCI_FRONTEND-and.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i269o8gs0

RnJvbSBhMjlkNjU4ZWVhOTMzNzNhZDU5N2Q4NDlkZjUzMGZiMWZjOWE3MDY2IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBtYW5pc2ggPG1hbmlzaC5qYWdnaUBjYXZpdW1uZXR3b3Jrcy5j
b20+CkRhdGU6IFdlZCwgNSBOb3YgMjAxNCAxMjoxNzowNSArMDUzMApTdWJqZWN0OiBbUEFUQ0gg
Mi81XSBSZW1vdmluZyBYODYgYXMgYSBkZXBlbmRlbmN5IG9uIFhFTl9QQ0lfRlJPTlRFTkQgYW5k
CiBYRU5fUENJX0JBQ0tFTkQKCi0tLQogZHJpdmVycy9wY2kvS2NvbmZpZyB8IDIgKy0KIGRyaXZl
cnMveGVuL0tjb25maWcgfCAyICstCiAyIGZpbGVzIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKSwg
MiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kcml2ZXJzL3BjaS9LY29uZmlnIGIvZHJpdmVy
cy9wY2kvS2NvbmZpZwppbmRleCA4OTM1MDNmLi5jNTM0Y2UwIDEwMDY0NAotLS0gYS9kcml2ZXJz
L3BjaS9LY29uZmlnCisrKyBiL2RyaXZlcnMvcGNpL0tjb25maWcKQEAgLTUwLDcgKzUwLDcgQEAg
Y29uZmlnIFBDSV9TVFVCCiAKIGNvbmZpZyBYRU5fUENJREVWX0ZST05URU5ECiAgICAgICAgIHRy
aXN0YXRlICJYZW4gUENJIEZyb250ZW5kIgotICAgICAgICBkZXBlbmRzIG9uIFBDSSAmJiBYODYg
JiYgWEVOCisgICAgICAgIGRlcGVuZHMgb24gUENJICYmIFhFTgogICAgICAgICBzZWxlY3QgUENJ
X1hFTgogCXNlbGVjdCBYRU5fWEVOQlVTX0ZST05URU5ECiAgICAgICAgIGRlZmF1bHQgeQpkaWZm
IC0tZ2l0IGEvZHJpdmVycy94ZW4vS2NvbmZpZyBiL2RyaXZlcnMveGVuL0tjb25maWcKaW5kZXgg
YjgxMjQ2Mi4uMTMzMmVlZCAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vS2NvbmZpZworKysgYi9k
cml2ZXJzL3hlbi9LY29uZmlnCkBAIC0xNTEsNyArMTUxLDcgQEAgY29uZmlnIFhFTl9UTUVNCiAK
IGNvbmZpZyBYRU5fUENJREVWX0JBQ0tFTkQKIAl0cmlzdGF0ZSAiWGVuIFBDSS1kZXZpY2UgYmFj
a2VuZCBkcml2ZXIiCi0JZGVwZW5kcyBvbiBQQ0kgJiYgWDg2ICYmIFhFTgorCWRlcGVuZHMgb24g
UENJICYmIFhFTgogCWRlcGVuZHMgb24gWEVOX0JBQ0tFTkQKIAlkZWZhdWx0IG0KIAloZWxwCi0t
IAoxLjkuMQoK
--089e0158b1568d74910507325860
Content-Type: application/octet-stream; 
	name="0005-PCI-passthrough-support-for-Xen.patch"
Content-Disposition: attachment; 
	filename="0005-PCI-passthrough-support-for-Xen.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i269o8h41

RnJvbSA3MTY1ZGRjMmRmZGQ0MTZiZWI5NjRhZjM5NjZiMmEyY2Q1NTYyMzcxIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBtYW5pc2ggPG1hbmlzaC5qYWdnaUBjYXZpdW1uZXR3b3Jrcy5j
b20+CkRhdGU6IFdlZCwgNSBOb3YgMjAxNCAyMDowNToyNSArMDUzMApTdWJqZWN0OiBbUEFUQ0gg
NS81XSBQQ0kgcGFzc3Rocm91Z2ggc3VwcG9ydCBmb3IgWGVuIGEpIE1BUCBTQkRGIGh5cGVyY2Fs
bAogYWRkZWQgYikgTUFQIE1NSU8gQkFSIHJlZ2lvbnMgaHlwZXJjYWxsIGFkZGVkIGMpIEJhc2lj
IFBDSSBwYXNzdGhyb3VnaCBBUk0KIHN1cHBvcnQKCi0tLQogYXJjaC9hcm02NC9pbmNsdWRlL2Fz
bS94ZW4vcGNpLmggICAgICAgICB8IDgyICsrKysrKysrKysrKysrKysrKysrKysrKysrKwogYXJj
aC9hcm02NC9pbmNsdWRlL2FzbS94ZW4vc3dpb3RsYi14ZW4uaCB8ICA3ICsrKwogYXJjaC9hcm02
NC94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgICAgICB8ICAyICstCiBhcmNoL2FybTY0L3hlbi94
ZW5fcGNpLmMgICAgICAgICAgICAgICAgIHwgOTUgKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysKIGRyaXZlcnMvcGNpL3hlbi1wY2lmcm9udC5jICAgICAgICAgICAgICAgfCAzMiArKysr
KysrKystLQogZHJpdmVycy94ZW4vcGNpLmMgICAgICAgICAgICAgICAgICAgICAgICB8IDY3ICsr
KysrKysrKysrKysrKysrKysrKy0KIGRyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaV9zdHViLmMg
ICAgICAgfCAgNCArLQogZHJpdmVycy94ZW4veGVuLXBjaWJhY2svcGNpYmFjay5oICAgICAgICB8
ICA0ICsrCiBkcml2ZXJzL3hlbi94ZW4tcGNpYmFjay9wY2liYWNrX29wcy5jICAgIHwgIDIgKwog
ZHJpdmVycy94ZW4veGVuLXBjaWJhY2svdnBjaS5jICAgICAgICAgICB8IDM3ICsrKysrKysrKysr
Ky0KIGluY2x1ZGUveGVuL2ludGVyZmFjZS9waHlzZGV2LmggICAgICAgICAgfCAyMSArKysrKysr
CiAxMSBmaWxlcyBjaGFuZ2VkLCAzNDAgaW5zZXJ0aW9ucygrKSwgMTMgZGVsZXRpb25zKC0pCiBj
cmVhdGUgbW9kZSAxMDA2NDQgYXJjaC9hcm02NC9pbmNsdWRlL2FzbS94ZW4vcGNpLmgKIGNyZWF0
ZSBtb2RlIDEwMDY0NCBhcmNoL2FybTY0L2luY2x1ZGUvYXNtL3hlbi9zd2lvdGxiLXhlbi5oCiBj
cmVhdGUgbW9kZSAxMDA2NDQgYXJjaC9hcm02NC94ZW4veGVuX3BjaS5jCgpkaWZmIC0tZ2l0IGEv
YXJjaC9hcm02NC9pbmNsdWRlL2FzbS94ZW4vcGNpLmggYi9hcmNoL2FybTY0L2luY2x1ZGUvYXNt
L3hlbi9wY2kuaApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi41NzkwZWZlCi0t
LSAvZGV2L251bGwKKysrIGIvYXJjaC9hcm02NC9pbmNsdWRlL2FzbS94ZW4vcGNpLmgKQEAgLTAs
MCArMSw4MiBAQAorI2lmbmRlZiBfQVNNX0FSTV9YRU5fUENJX0gKKyNkZWZpbmUgX0FTTV9BUk1f
WEVOX1BDSV9ICisKKyNpZiBkZWZpbmVkKENPTkZJR19QQ0lfWEVOKQorZXh0ZXJuIGludCBfX2lu
aXQgcGNpX3hlbl9pbml0KHZvaWQpOworZXh0ZXJuIGludCBfX2luaXQgcGNpX3hlbl9odm1faW5p
dCh2b2lkKTsKKyNkZWZpbmUgcGNpX3hlbiAxCisjZWxzZQorI2RlZmluZSBwY2lfeGVuIDAKKyNk
ZWZpbmUgcGNpX3hlbl9pbml0ICgwKQorc3RhdGljIGlubGluZSBpbnQgcGNpX3hlbl9odm1faW5p
dCh2b2lkKQoreworCXJldHVybiAtMTsKK30KKyNlbmRpZgorI2lmIGRlZmluZWQoQ09ORklHX1hF
Tl9ET00wKQoraW50IF9faW5pdCBwY2lfeGVuX2luaXRpYWxfZG9tYWluKHZvaWQpOworaW50IHhl
bl9maW5kX2RldmljZV9kb21haW5fb3duZXIoc3RydWN0IHBjaV9kZXYgKmRldik7CitpbnQgeGVu
X3JlZ2lzdGVyX2RldmljZV9kb21haW5fb3duZXIoc3RydWN0IHBjaV9kZXYgKmRldiwgdWludDE2
X3QgZG9tYWluKTsKK2ludCB4ZW5fdW5yZWdpc3Rlcl9kZXZpY2VfZG9tYWluX293bmVyKHN0cnVj
dCBwY2lfZGV2ICpkZXYpOworI2Vsc2UKK3N0YXRpYyBpbmxpbmUgaW50IF9faW5pdCBwY2lfeGVu
X2luaXRpYWxfZG9tYWluKHZvaWQpCit7CisJcmV0dXJuIC0xOworfQorc3RhdGljIGlubGluZSBp
bnQgeGVuX2ZpbmRfZGV2aWNlX2RvbWFpbl9vd25lcihzdHJ1Y3QgcGNpX2RldiAqZGV2KQorewor
CXJldHVybiAtMTsKK30KK3N0YXRpYyBpbmxpbmUgaW50IHhlbl9yZWdpc3Rlcl9kZXZpY2VfZG9t
YWluX293bmVyKHN0cnVjdCBwY2lfZGV2ICpkZXYsCisJCQkJCQkgICB1aW50MTZfdCBkb21haW4p
Cit7CisJcmV0dXJuIC0xOworfQorc3RhdGljIGlubGluZSBpbnQgeGVuX3VucmVnaXN0ZXJfZGV2
aWNlX2RvbWFpbl9vd25lcihzdHJ1Y3QgcGNpX2RldiAqZGV2KQoreworCXJldHVybiAtMTsKK30K
KyNlbmRpZgorCisjaWYgZGVmaW5lZChDT05GSUdfUENJX01TSSkKKyNpZiBkZWZpbmVkKENPTkZJ
R19QQ0lfWEVOKQorLyogVGhlIGRyaXZlcnMvcGNpL3hlbi1wY2lmcm9udC5jIHNldHMgdGhpcyBz
dHJ1Y3R1cmUgdG8KKyAqIGl0cyBvd24gZnVuY3Rpb25zLgorICovCitzdHJ1Y3QgeGVuX3BjaV9m
cm9udGVuZF9vcHMgeworCWludCAoKmVuYWJsZV9tc2kpKHN0cnVjdCBwY2lfZGV2ICpkZXYsIGlu
dCB2ZWN0b3JzW10pOworCXZvaWQgKCpkaXNhYmxlX21zaSkoc3RydWN0IHBjaV9kZXYgKmRldik7
CisJaW50ICgqZW5hYmxlX21zaXgpKHN0cnVjdCBwY2lfZGV2ICpkZXYsIGludCB2ZWN0b3JzW10s
IGludCBudmVjKTsKKwl2b2lkICgqZGlzYWJsZV9tc2l4KShzdHJ1Y3QgcGNpX2RldiAqZGV2KTsK
K307CisKK2V4dGVybiBzdHJ1Y3QgeGVuX3BjaV9mcm9udGVuZF9vcHMgKnhlbl9wY2lfZnJvbnRl
bmQ7CisKK3N0YXRpYyBpbmxpbmUgaW50IHhlbl9wY2lfZnJvbnRlbmRfZW5hYmxlX21zaShzdHJ1
Y3QgcGNpX2RldiAqZGV2LAorCQkJCQkgICAgICBpbnQgdmVjdG9yc1tdKQoreworCWlmICh4ZW5f
cGNpX2Zyb250ZW5kICYmIHhlbl9wY2lfZnJvbnRlbmQtPmVuYWJsZV9tc2kpCisJCXJldHVybiB4
ZW5fcGNpX2Zyb250ZW5kLT5lbmFibGVfbXNpKGRldiwgdmVjdG9ycyk7CisJcmV0dXJuIC1FTk9E
RVY7Cit9CitzdGF0aWMgaW5saW5lIHZvaWQgeGVuX3BjaV9mcm9udGVuZF9kaXNhYmxlX21zaShz
dHJ1Y3QgcGNpX2RldiAqZGV2KQoreworCWlmICh4ZW5fcGNpX2Zyb250ZW5kICYmIHhlbl9wY2lf
ZnJvbnRlbmQtPmRpc2FibGVfbXNpKQorCQkJeGVuX3BjaV9mcm9udGVuZC0+ZGlzYWJsZV9tc2ko
ZGV2KTsKK30KK3N0YXRpYyBpbmxpbmUgaW50IHhlbl9wY2lfZnJvbnRlbmRfZW5hYmxlX21zaXgo
c3RydWN0IHBjaV9kZXYgKmRldiwKKwkJCQkJICAgICAgIGludCB2ZWN0b3JzW10sIGludCBudmVj
KQoreworCWlmICh4ZW5fcGNpX2Zyb250ZW5kICYmIHhlbl9wY2lfZnJvbnRlbmQtPmVuYWJsZV9t
c2l4KQorCQlyZXR1cm4geGVuX3BjaV9mcm9udGVuZC0+ZW5hYmxlX21zaXgoZGV2LCB2ZWN0b3Jz
LCBudmVjKTsKKwlyZXR1cm4gLUVOT0RFVjsKK30KK3N0YXRpYyBpbmxpbmUgdm9pZCB4ZW5fcGNp
X2Zyb250ZW5kX2Rpc2FibGVfbXNpeChzdHJ1Y3QgcGNpX2RldiAqZGV2KQoreworCWlmICh4ZW5f
cGNpX2Zyb250ZW5kICYmIHhlbl9wY2lfZnJvbnRlbmQtPmRpc2FibGVfbXNpeCkKKwkJCXhlbl9w
Y2lfZnJvbnRlbmQtPmRpc2FibGVfbXNpeChkZXYpOworfQorI2VuZGlmIC8qIENPTkZJR19QQ0lf
WEVOICovCisjZW5kaWYgLyogQ09ORklHX1BDSV9NU0kgKi8KKworI2VuZGlmCS8qIF9BU01fWDg2
X1hFTl9QQ0lfSCAqLwpkaWZmIC0tZ2l0IGEvYXJjaC9hcm02NC9pbmNsdWRlL2FzbS94ZW4vc3dp
b3RsYi14ZW4uaCBiL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20veGVuL3N3aW90bGIteGVuLmgKbmV3
IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uMDJhYjJhMQotLS0gL2Rldi9udWxsCisr
KyBiL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20veGVuL3N3aW90bGIteGVuLmgKQEAgLTAsMCArMSw3
IEBACisjaWZuZGVmIEFSTTY0X1NXSU9UTEJfWEVOCisjZGVmaW5lIEFSTTY0X1NXSU9UTEJfWEVO
CisvKiBQbGFjZSBob2xkZXIgZmlsZSAqLworc3RhdGljIGlubGluZSBpbnQgX19pbml0IHBjaV94
ZW5fc3dpb3RsYl9kZXRlY3Qodm9pZCkgeyByZXR1cm4gMDsgfQorc3RhdGljIGlubGluZSB2b2lk
IF9faW5pdCBwY2lfeGVuX3N3aW90bGJfaW5pdCh2b2lkKSB7IH0KK3N0YXRpYyBpbmxpbmUgaW50
IHBjaV94ZW5fc3dpb3RsYl9pbml0X2xhdGUodm9pZCkgeyByZXR1cm4gLUVOWElPOyB9CisjZW5k
aWYKZGlmZiAtLWdpdCBhL2FyY2gvYXJtNjQveGVuL01ha2VmaWxlIGIvYXJjaC9hcm02NC94ZW4v
TWFrZWZpbGUKaW5kZXggNzRhOGQ4Ny4uODE4ZWM0NSAxMDA2NDQKLS0tIGEvYXJjaC9hcm02NC94
ZW4vTWFrZWZpbGUKKysrIGIvYXJjaC9hcm02NC94ZW4vTWFrZWZpbGUKQEAgLTEsMiArMSwyIEBA
CiB4ZW4tYXJtLXkJKz0gJChhZGRwcmVmaXggLi4vLi4vYXJtL3hlbi8sIGVubGlnaHRlbi5vIGdy
YW50LXRhYmxlLm8gcDJtLm8gbW0ubykKLW9iai15CQk6PSB4ZW4tYXJtLm8gaHlwZXJjYWxsLm8K
K29iai15CQk6PSB4ZW4tYXJtLm8gaHlwZXJjYWxsLm8geGVuX3BjaS5vCmRpZmYgLS1naXQgYS9h
cmNoL2FybTY0L3hlbi94ZW5fcGNpLmMgYi9hcmNoL2FybTY0L3hlbi94ZW5fcGNpLmMKbmV3IGZp
bGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uNzdkNjY3MAotLS0gL2Rldi9udWxsCisrKyBi
L2FyY2gvYXJtNjQveGVuL3hlbl9wY2kuYwpAQCAtMCwwICsxLDk1IEBACisvKgorICogWGVuIFBD
SSAtIGhhbmRsZSBQQ0kgKElOVHgpIGFuZCBNU0kgaW5mcmFzdHJ1Y3R1cmUgY2FsbHMgZm9yIFBW
LCBIVk0gYW5kCisgKiBpbml0aWFsIGRvbWFpbiBzdXBwb3J0LiBXZSBhbHNvIGhhbmRsZSB0aGUg
RFNEVCBfUFJUIGNhbGxiYWNrcyBmb3IgR1NJJ3MKKyAqIHVzZWQgaW4gSFZNIGFuZCBpbml0aWFs
IGRvbWFpbiBtb2RlIChQViBkb2VzIG5vdCBwYXJzZSBBQ1BJLCBzbyBpdCBoYXMgbm8KKyAqIGNv
bmNlcHQgb2YgR1NJcykuIFVuZGVyIFBWIHdlIGhvb2sgdW5kZXIgdGhlIHBuYmJpb3MgQVBJIGZv
ciBJUlFzIGFuZAorICogMHhjZjggUENJIGNvbmZpZ3VyYXRpb24gcmVhZC93cml0ZS4KKyAqCisg
KiAgIEF1dGhvcjogUnlhbiBXaWxzb24gPGhhcDlAZXBvY2gubmNzYy5taWw+CisgKiAgICAgICAg
ICAgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgorICogICAg
ICAgICAgIFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJpeC5j
b20+CisgKi8KKyNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4KKyNpbmNsdWRlIDxsaW51eC9pbml0
Lmg+CisjaW5jbHVkZSA8bGludXgvcGNpLmg+CisKKyNpbmNsdWRlIDxsaW51eC9pby5oPgorCisj
aW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+CisKKyNpbmNsdWRlIDx4ZW4vZmVhdHVyZXMu
aD4KKyNpbmNsdWRlIDx4ZW4vZXZlbnRzLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9wY2kuaD4KK3N0
cnVjdCB4ZW5fZGV2aWNlX2RvbWFpbl9vd25lciB7CisJZG9taWRfdCBkb21haW47CisJc3RydWN0
IHBjaV9kZXYgKmRldjsKKwlzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7Cit9OworCisKK3N0YXRpYyBE
RUZJTkVfU1BJTkxPQ0soZGV2X2RvbWFpbl9saXN0X3NwaW5sb2NrKTsKK3N0YXRpYyBzdHJ1Y3Qg
bGlzdF9oZWFkIGRldl9kb21haW5fbGlzdCA9IExJU1RfSEVBRF9JTklUKGRldl9kb21haW5fbGlz
dCk7CisKK3N0YXRpYyBzdHJ1Y3QgeGVuX2RldmljZV9kb21haW5fb3duZXIgKmZpbmRfZGV2aWNl
KHN0cnVjdCBwY2lfZGV2ICpkZXYpCit7CisJc3RydWN0IHhlbl9kZXZpY2VfZG9tYWluX293bmVy
ICpvd25lcjsKKworCWxpc3RfZm9yX2VhY2hfZW50cnkob3duZXIsICZkZXZfZG9tYWluX2xpc3Qs
IGxpc3QpIHsKKwkJaWYgKG93bmVyLT5kZXYgPT0gZGV2KQorCQkJcmV0dXJuIG93bmVyOworCX0K
KwlyZXR1cm4gTlVMTDsKK30KKworaW50IHhlbl9maW5kX2RldmljZV9kb21haW5fb3duZXIoc3Ry
dWN0IHBjaV9kZXYgKmRldikKK3sKKwlzdHJ1Y3QgeGVuX2RldmljZV9kb21haW5fb3duZXIgKm93
bmVyOworCWludCBkb21haW4gPSAtRU5PREVWOworCisJc3Bpbl9sb2NrKCZkZXZfZG9tYWluX2xp
c3Rfc3BpbmxvY2spOworCW93bmVyID0gZmluZF9kZXZpY2UoZGV2KTsKKwlpZiAob3duZXIpCisJ
CWRvbWFpbiA9IG93bmVyLT5kb21haW47CisJc3Bpbl91bmxvY2soJmRldl9kb21haW5fbGlzdF9z
cGlubG9jayk7CisJcmV0dXJuIGRvbWFpbjsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHhlbl9maW5k
X2RldmljZV9kb21haW5fb3duZXIpOworCitpbnQgeGVuX3JlZ2lzdGVyX2RldmljZV9kb21haW5f
b3duZXIoc3RydWN0IHBjaV9kZXYgKmRldiwgdWludDE2X3QgZG9tYWluKQoreworCXN0cnVjdCB4
ZW5fZGV2aWNlX2RvbWFpbl9vd25lciAqb3duZXI7CisKKwlvd25lciA9IGt6YWxsb2Moc2l6ZW9m
KHN0cnVjdCB4ZW5fZGV2aWNlX2RvbWFpbl9vd25lciksIEdGUF9LRVJORUwpOworCWlmICghb3du
ZXIpCisJCXJldHVybiAtRU5PREVWOworCisJc3Bpbl9sb2NrKCZkZXZfZG9tYWluX2xpc3Rfc3Bp
bmxvY2spOworCWlmIChmaW5kX2RldmljZShkZXYpKSB7CisJCXNwaW5fdW5sb2NrKCZkZXZfZG9t
YWluX2xpc3Rfc3BpbmxvY2spOworCQlrZnJlZShvd25lcik7CisJCXJldHVybiAtRUVYSVNUOwor
CX0KKwlvd25lci0+ZG9tYWluID0gZG9tYWluOworCW93bmVyLT5kZXYgPSBkZXY7CisJbGlzdF9h
ZGRfdGFpbCgmb3duZXItPmxpc3QsICZkZXZfZG9tYWluX2xpc3QpOworCXNwaW5fdW5sb2NrKCZk
ZXZfZG9tYWluX2xpc3Rfc3BpbmxvY2spOworCXJldHVybiAwOworfQorRVhQT1JUX1NZTUJPTF9H
UEwoeGVuX3JlZ2lzdGVyX2RldmljZV9kb21haW5fb3duZXIpOworCitpbnQgeGVuX3VucmVnaXN0
ZXJfZGV2aWNlX2RvbWFpbl9vd25lcihzdHJ1Y3QgcGNpX2RldiAqZGV2KQoreworCXN0cnVjdCB4
ZW5fZGV2aWNlX2RvbWFpbl9vd25lciAqb3duZXI7CisKKwlzcGluX2xvY2soJmRldl9kb21haW5f
bGlzdF9zcGlubG9jayk7CisJb3duZXIgPSBmaW5kX2RldmljZShkZXYpOworCWlmICghb3duZXIp
IHsKKwkJc3Bpbl91bmxvY2soJmRldl9kb21haW5fbGlzdF9zcGlubG9jayk7CisJCXJldHVybiAt
RU5PREVWOworCX0KKwlsaXN0X2RlbCgmb3duZXItPmxpc3QpOworCXNwaW5fdW5sb2NrKCZkZXZf
ZG9tYWluX2xpc3Rfc3BpbmxvY2spOworCWtmcmVlKG93bmVyKTsKKwlyZXR1cm4gMDsKK30KK0VY
UE9SVF9TWU1CT0xfR1BMKHhlbl91bnJlZ2lzdGVyX2RldmljZV9kb21haW5fb3duZXIpOwpkaWZm
IC0tZ2l0IGEvZHJpdmVycy9wY2kveGVuLXBjaWZyb250LmMgYi9kcml2ZXJzL3BjaS94ZW4tcGNp
ZnJvbnQuYwppbmRleCAxMTZjYTM3Li5lMzBjYTdiIDEwMDY0NAotLS0gYS9kcml2ZXJzL3BjaS94
ZW4tcGNpZnJvbnQuYworKysgYi9kcml2ZXJzL3BjaS94ZW4tcGNpZnJvbnQuYwpAQCAtMTAsNiAr
MTAsMTEgQEAKICNpbmNsdWRlIDx4ZW4vZXZlbnRzLmg+CiAjaW5jbHVkZSA8eGVuL2dyYW50X3Rh
YmxlLmg+CiAjaW5jbHVkZSA8eGVuL3BhZ2UuaD4KKyNpbmNsdWRlIDxsaW51eC9vZl9pcnEuaD4K
KyNpbmNsdWRlIDxsaW51eC9vZl9wY2kuaD4KKyNpbmNsdWRlIDxsaW51eC9vZi5oPgorI2luY2x1
ZGUgPGxpbnV4L29mX2FkZHJlc3MuaD4KKyNpbmNsdWRlIDxsaW51eC9vZl9kZXZpY2UuaD4KICNp
bmNsdWRlIDxsaW51eC9zcGlubG9jay5oPgogI2luY2x1ZGUgPGxpbnV4L3BjaS5oPgogI2luY2x1
ZGUgPGxpbnV4L21zaS5oPgpAQCAtMjEsOCArMjYsOCBAQAogI2luY2x1ZGUgPGxpbnV4L2JpdG9w
cy5oPgogI2luY2x1ZGUgPGxpbnV4L3RpbWUuaD4KICNpbmNsdWRlIDx4ZW4vcGxhdGZvcm1fcGNp
Lmg+Ci0KICNpbmNsdWRlIDxhc20veGVuL3N3aW90bGIteGVuLmg+CisjaW5jbHVkZSA8bGludXgv
c3dpb3RsYi5oPgogI2RlZmluZSBJTlZBTElEX0dSQU5UX1JFRiAoMCkKICNkZWZpbmUgSU5WQUxJ
RF9FVlRDSE4gICAgKC0xKQogCkBAIC0yNDMsNyArMjQ4LDcgQEAgc3RhdGljIHN0cnVjdCBwY2lf
b3BzIHBjaWZyb250X2J1c19vcHMgPSB7CiAJLndyaXRlID0gcGNpZnJvbnRfYnVzX3dyaXRlLAog
fTsKIAotI2lmZGVmIENPTkZJR19QQ0lfTVNJCisjaWYgZGVmaW5lZChDT05GSUdfUENJX01TSSkg
JiYgZGVmaW5lZChDT05GSUdfWDg2KQogc3RhdGljIGludCBwY2lfZnJvbnRlbmRfZW5hYmxlX21z
aXgoc3RydWN0IHBjaV9kZXYgKmRldiwKIAkJCQkgICAgaW50IHZlY3RvcltdLCBpbnQgbnZlYykK
IHsKQEAgLTM4Nyw3ICszOTIsNyBAQCBzdGF0aWMgdm9pZCBwY2lfZnJvbnRlbmRfcmVnaXN0cmFy
KGludCBlbmFibGUpCiB9OwogI2Vsc2UKIHN0YXRpYyBpbmxpbmUgdm9pZCBwY2lfZnJvbnRlbmRf
cmVnaXN0cmFyKGludCBlbmFibGUpIHsgfTsKLSNlbmRpZiAvKiBDT05GSUdfUENJX01TSSAqLwor
I2VuZGlmIC8qIENPTkZJR19QQ0lfTVNJICYmIFg4NiovCiAKIC8qIENsYWltIHJlc291cmNlcyBm
b3IgdGhlIFBDSSBmcm9udGVuZCBhcy1pcywgYmFja2VuZCB3b24ndCBhbGxvdyBjaGFuZ2VzICov
CiBzdGF0aWMgaW50IHBjaWZyb250X2NsYWltX3Jlc291cmNlKHN0cnVjdCBwY2lfZGV2ICpkZXYs
IHZvaWQgKmRhdGEpCkBAIC00NDgsNiArNDUzLDcgQEAgc3RhdGljIGludCBwY2lmcm9udF9zY2Fu
X3Jvb3Qoc3RydWN0IHBjaWZyb250X2RldmljZSAqcGRldiwKIAlzdHJ1Y3QgcGNpX2J1cyAqYjsK
IAlzdHJ1Y3QgcGNpZnJvbnRfc2QgKnNkID0gTlVMTDsKIAlzdHJ1Y3QgcGNpX2J1c19lbnRyeSAq
YnVzX2VudHJ5ID0gTlVMTDsKK3N0cnVjdCBkZXZpY2Vfbm9kZSAqbXNpX25vZGU7CiAJaW50IGVy
ciA9IDA7CiAKICNpZm5kZWYgQ09ORklHX1BDSV9ET01BSU5TCkBAIC00ODUsNiArNDkxLDE3IEBA
IHN0YXRpYyBpbnQgcGNpZnJvbnRfc2Nhbl9yb290KHN0cnVjdCBwY2lmcm9udF9kZXZpY2UgKnBk
ZXYsCiAJfQogCiAJYnVzX2VudHJ5LT5idXMgPSBiOworICAgICAgICBtc2lfbm9kZSA9IG9mX2Zp
bmRfY29tcGF0aWJsZV9ub2RlKE5VTEwsTlVMTCwgImFybSxnaWMtdjMtaXRzIik7CisgICAgICAg
IGlmKG1zaV9ub2RlKSB7CisgICAgICAgICAgICBiLT5tc2kgPSBvZl9wY2lfZmluZF9tc2lfY2hp
cF9ieV9ub2RlKG1zaV9ub2RlKTsKKyAgICAgICAgICAgIGlmKCFiLT5tc2kpIHsKKyAgICAgICAg
ICAgICAgIHByaW50ayhLRVJOX0VSUiJVbmFibGUgdG8gZmluZCBidXMtPm1zaSBub2RlIFxyXG4i
KTsKKyAgICAgICAgICAgICAgIGdvdG8gZXJyX291dDsKKyAgICAgICAgICAgIH0KKyAgICAgICAg
fWVsc2UgeworICAgICAgICAgICAgICAgcHJpbnRrKEtFUk5fRVJSIlVuYWJsZSB0byBmaW5kIGFy
bSxnaWMtdjMtaXRzIGNvbXBhdGlibGUgbm9kZSBcclxuIik7CisgICAgICAgICAgICAgICBnb3Rv
IGVycl9vdXQ7CisgICAgICAgIH0KIAogCWxpc3RfYWRkKCZidXNfZW50cnktPmxpc3QsICZwZGV2
LT5yb290X2J1c2VzKTsKIApAQCAtMTE0NiwxMiArMTE2MywxNyBAQCBzdGF0aWMgc3RydWN0IHhl
bmJ1c19kcml2ZXIgeGVucGNpX2RyaXZlciA9IHsKIAogc3RhdGljIGludCBfX2luaXQgcGNpZnJv
bnRfaW5pdCh2b2lkKQogewotCWlmICgheGVuX3B2X2RvbWFpbigpIHx8IHhlbl9pbml0aWFsX2Rv
bWFpbigpKQorCWlmKAorI2lmZGVmIFg4NgorCSF4ZW5fcHZfZG9tYWluKCkgfHwKKyNlbmRpZgor
CXhlbl9pbml0aWFsX2RvbWFpbigpKQogCQlyZXR1cm4gLUVOT0RFVjsKIAorI2lmZGVmIFg4Ngog
CWlmICgheGVuX2hhc19wdl9kZXZpY2VzKCkpCiAJCXJldHVybiAtRU5PREVWOwotCisjZW5kaWYK
IAlwY2lfZnJvbnRlbmRfcmVnaXN0cmFyKDEgLyogZW5hYmxlICovKTsKIAogCXJldHVybiB4ZW5i
dXNfcmVnaXN0ZXJfZnJvbnRlbmQoJnhlbnBjaV9kcml2ZXIpOwpkaWZmIC0tZ2l0IGEvZHJpdmVy
cy94ZW4vcGNpLmMgYi9kcml2ZXJzL3hlbi9wY2kuYwppbmRleCBkZDljMjQ5Li5hNTYwZjQyIDEw
MDY0NAotLS0gYS9kcml2ZXJzL3hlbi9wY2kuYworKysgYi9kcml2ZXJzL3hlbi9wY2kuYwpAQCAt
MjIsNiArMjIsNyBAQAogI2luY2x1ZGUgPHhlbi94ZW4uaD4KICNpbmNsdWRlIDx4ZW4vaW50ZXJm
YWNlL3BoeXNkZXYuaD4KICNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3hlbi5oPgorI2luY2x1ZGUg
PHhlbi9odmMtY29uc29sZS5oPgogCiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+CiAj
aW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KQEAgLTEzMCw3ICsxMzEsNyBAQCBzdGF0aWMg
aW50IHhlbl9hZGRfZGV2aWNlKHN0cnVjdCBkZXZpY2UgKmRldikKIAlyZXR1cm4gcjsKIH0KIAot
c3RhdGljIGludCB4ZW5fcmVtb3ZlX2RldmljZShzdHJ1Y3QgZGV2aWNlICpkZXYpCitpbnQgeGVu
X3JlbW92ZV9kZXZpY2Uoc3RydWN0IGRldmljZSAqZGV2KQogewogCWludCByOwogCXN0cnVjdCBw
Y2lfZGV2ICpwY2lfZGV2ID0gdG9fcGNpX2RldihkZXYpOwpAQCAtMTU4LDYgKzE1OSw2NCBAQCBz
dGF0aWMgaW50IHhlbl9yZW1vdmVfZGV2aWNlKHN0cnVjdCBkZXZpY2UgKmRldikKIAogCXJldHVy
biByOwogfQorc3RhdGljIGludCB4ZW5fbWFwX3BjaV9iYXJzKHN0cnVjdCBkZXZpY2UgKmRldikK
K3sKKwlpbnQgaSxyPTA7CisJc3RydWN0IHBjaV9kZXYgKnBjaV9kZXYgPSB0b19wY2lfZGV2KGRl
dik7CisJZm9yKGk9MDsgaTw2OyBpKyspIHsKKwkJc3RydWN0IHBoeXNkZXZfbWFwX21taW8gbWFw
bTsKKwkJbWFwbS5hZGRyID0gcGNpX3Jlc291cmNlX3N0YXJ0KHBjaV9kZXYsaSk7CisJCW1hcG0u
c2l6ZSA9IHBjaV9yZXNvdXJjZV9sZW4ocGNpX2RldixpKTsKKwkJeGVuX3Jhd19wcmludGsoIiVz
IEFERFI9JWx4IFNJWkU9JWx4XHJcbiIsX19mdW5jX18sIG1hcG0uYWRkciwgbWFwbS5zaXplKTsK
KwkJaWYobWFwbS5hZGRyICYmIG1hcG0uc2l6ZSkgeworCQkJciA9IEhZUEVSVklTT1JfcGh5c2Rl
dl9vcChQSFlTREVWT1BfbWFwX21taW8sICZtYXBtKTsKKwkJCWlmIChyKQorCQkJCXByaW50ayhL
RVJOX0VSUiAiJXMgWGVuIEVycm9yIFVuYWJsZSB0byBtYXAgQUREUj0lbHggU0laRT0lbHhcclxu
IixfX2Z1bmNfXywgbWFwbS5hZGRyLCBtYXBtLnNpemUpOworCQl9CisJfQorCXJldHVybiByOwor
Cit9CitzdGF0aWMgaW50IHhlbl91bm1hcF9wY2lfYmFycyhzdHJ1Y3QgZGV2aWNlICpkZXYpCit7
CisJaW50IGkscj0wOworCXN0cnVjdCBwY2lfZGV2ICpwY2lfZGV2ID0gdG9fcGNpX2RldihkZXYp
OworCWZvcihpPTA7IGk8NjsgaSsrKSB7CisJCXN0cnVjdCBwaHlzZGV2X21hcF9tbWlvIG1hcG07
CisJCW1hcG0uYWRkciA9IHBjaV9yZXNvdXJjZV9zdGFydChwY2lfZGV2LGkpOworCQltYXBtLnNp
emUgPSBwY2lfcmVzb3VyY2VfbGVuKHBjaV9kZXYsaSk7CisJCXhlbl9yYXdfcHJpbnRrKCIlcyBB
RERSPSVseCBTSVpFPSVseFxyXG4iLF9fZnVuY19fLCBtYXBtLmFkZHIsIG1hcG0uc2l6ZSk7CisJ
CWlmKG1hcG0uYWRkciAmJiBtYXBtLnNpemUpIHsKKwkJCXIgPSBIWVBFUlZJU09SX3BoeXNkZXZf
b3AoUEhZU0RFVk9QX3VubWFwX21taW8sICZtYXBtKTsKKwkJCWlmIChyKQorCQkJCXByaW50ayhL
RVJOX0VSUiAiJXMgWGVuIEVycm9yIFVuYWJsZSB0byB1bm1hcCBBRERSPSVseCBTSVpFPSVseFxy
XG4iLF9fZnVuY19fLCBtYXBtLmFkZHIsIG1hcG0uc2l6ZSk7CisJCX0KKwl9CisJcmV0dXJuIHI7
CisKK30KK2ludCB4ZW5fYWRkX3BjaV9kZXZpY2Uoc3RydWN0IGRldmljZSAqZGV2KQoreworCWlu
dCByID0gMDsKKwlpZiAoeGVuX2luaXRpYWxfZG9tYWluKCkpCisJICAgIHIgPSB4ZW5fYWRkX2Rl
dmljZShkZXYpOworCWlmKCFyKSB7CisJCXIgPSB4ZW5fbWFwX3BjaV9iYXJzKGRldik7CisJfQor
CXJldHVybiByOworfQorCitpbnQgeGVuX3JlbW92ZV9wY2lfZGV2aWNlKHN0cnVjdCBkZXZpY2Ug
KmRldikKK3sKKwlpbnQgciA9IDA7CisJcHJpbnRrKEtFUk5fRVJSIj4+JXMgXHJcbiIsX19mdW5j
X18pOworCXIgPSB4ZW5fcmVtb3ZlX2RldmljZShkZXYpOworCWlmKCFyKSB7CisJCXIgPSB4ZW5f
dW5tYXBfcGNpX2JhcnMoZGV2KTsKKwl9CisJcHJpbnRrKEtFUk5fRVJSIjw8JXMgJXNcclxuIiwg
X19mdW5jX18sIF9fTElORV9fKTsKKwlyZXR1cm4gcjsKK30KIAogc3RhdGljIGludCB4ZW5fcGNp
X25vdGlmaWVyKHN0cnVjdCBub3RpZmllcl9ibG9jayAqbmIsCiAJCQkgICAgdW5zaWduZWQgbG9u
ZyBhY3Rpb24sIHZvaWQgKmRhdGEpCkBAIC0xNjcsMTAgKzIyNiwxMCBAQCBzdGF0aWMgaW50IHhl
bl9wY2lfbm90aWZpZXIoc3RydWN0IG5vdGlmaWVyX2Jsb2NrICpuYiwKIAogCXN3aXRjaCAoYWN0
aW9uKSB7CiAJY2FzZSBCVVNfTk9USUZZX0FERF9ERVZJQ0U6Ci0JCXIgPSB4ZW5fYWRkX2Rldmlj
ZShkZXYpOworCQlyID0geGVuX2FkZF9wY2lfZGV2aWNlKGRldik7CiAJCWJyZWFrOwogCWNhc2Ug
QlVTX05PVElGWV9ERUxfREVWSUNFOgotCQlyID0geGVuX3JlbW92ZV9kZXZpY2UoZGV2KTsKKwkJ
ciA9IHhlbl9yZW1vdmVfcGNpX2RldmljZShkZXYpOwogCQlicmVhazsKIAlkZWZhdWx0OgogCQly
ZXR1cm4gTk9USUZZX0RPTkU7CkBAIC0xODgsOCArMjQ3LDEwIEBAIHN0YXRpYyBzdHJ1Y3Qgbm90
aWZpZXJfYmxvY2sgZGV2aWNlX25iID0gewogCiBzdGF0aWMgaW50IF9faW5pdCByZWdpc3Rlcl94
ZW5fcGNpX25vdGlmaWVyKHZvaWQpCiB7CisjaWZkZWYgWDg2CiAJaWYgKCF4ZW5faW5pdGlhbF9k
b21haW4oKSkKIAkJcmV0dXJuIDA7CisjZW5kaWYKIAogCXJldHVybiBidXNfcmVnaXN0ZXJfbm90
aWZpZXIoJnBjaV9idXNfdHlwZSwgJmRldmljZV9uYik7CiB9CmRpZmYgLS1naXQgYS9kcml2ZXJz
L3hlbi94ZW4tcGNpYmFjay9wY2lfc3R1Yi5jIGIvZHJpdmVycy94ZW4veGVuLXBjaWJhY2svcGNp
X3N0dWIuYwppbmRleCAwMTcwNjlhLi5lODQzNTA2IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94
ZW4tcGNpYmFjay9wY2lfc3R1Yi5jCisrKyBiL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaV9z
dHViLmMKQEAgLTM4Miw3ICszODIsNyBAQCBzdGF0aWMgaW50IHBjaXN0dWJfaW5pdF9kZXZpY2Uo
c3RydWN0IHBjaV9kZXYgKmRldikKIAllcnIgPSBwY2lfZW5hYmxlX2RldmljZShkZXYpOwogCWlm
IChlcnIpCiAJCWdvdG8gY29uZmlnX3JlbGVhc2U7Ci0KKyNpZmRlZiBDT05GSUdfWDg2CiAJaWYg
KGRldi0+bXNpeF9jYXApIHsKIAkJc3RydWN0IHBoeXNkZXZfcGNpX2RldmljZSBwcGRldiA9IHsK
IAkJCS5zZWcgPSBwY2lfZG9tYWluX25yKGRldi0+YnVzKSwKQEAgLTM5NSw3ICszOTUsNyBAQCBz
dGF0aWMgaW50IHBjaXN0dWJfaW5pdF9kZXZpY2Uoc3RydWN0IHBjaV9kZXYgKmRldikKIAkJCWRl
dl9lcnIoJmRldi0+ZGV2LCAiTVNJLVggcHJlcGFyYXRpb24gZmFpbGVkICglZClcbiIsCiAJCQkJ
ZXJyKTsKIAl9Ci0KKyNlbmRpZgogCS8qIFdlIG5lZWQgdGhlIGRldmljZSBhY3RpdmUgdG8gc2F2
ZSB0aGUgc3RhdGUuICovCiAJZGV2X2RiZygmZGV2LT5kZXYsICJzYXZlIHN0YXRlIG9mIGRldmlj
ZVxuIik7CiAJcGNpX3NhdmVfc3RhdGUoZGV2KTsKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL3hl
bi1wY2liYWNrL3BjaWJhY2suaCBiL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaWJhY2suaApp
bmRleCBmNzJhZjg3Li41MmVmMDMxIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94ZW4tcGNpYmFj
ay9wY2liYWNrLmgKKysrIGIvZHJpdmVycy94ZW4veGVuLXBjaWJhY2svcGNpYmFjay5oCkBAIC0z
Nyw2ICszNywxMCBAQCBzdHJ1Y3QgeGVuX3BjaWJrX2RldmljZSB7CiAJc3RydWN0IHhlbl9wY2lf
c2hhcmVkaW5mbyAqc2hfaW5mbzsKIAl1bnNpZ25lZCBsb25nIGZsYWdzOwogCXN0cnVjdCB3b3Jr
X3N0cnVjdCBvcF93b3JrOworCWludCBwY2lfZG9tYWluOworCWludCBidXM7CisJaW50IHNsb3Q7
CisJaW50IGZ1bmM7CiB9OwogCiBzdHJ1Y3QgeGVuX3BjaWJrX2Rldl9kYXRhIHsKZGlmZiAtLWdp
dCBhL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaWJhY2tfb3BzLmMgYi9kcml2ZXJzL3hlbi94
ZW4tcGNpYmFjay9wY2liYWNrX29wcy5jCmluZGV4IGM0YTA2NjYuLjhhNTcwMWQgMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaWJhY2tfb3BzLmMKKysrIGIvZHJpdmVycy94
ZW4veGVuLXBjaWJhY2svcGNpYmFja19vcHMuYwpAQCAtNzAsNiArNzAsNyBAQCBzdGF0aWMgdm9p
ZCB4ZW5fcGNpYmtfY29udHJvbF9pc3Ioc3RydWN0IHBjaV9kZXYgKmRldiwgaW50IHJlc2V0KQog
CQllbmFibGUgPyAiZW5hYmxlIiA6ICJkaXNhYmxlIik7CiAKIAlpZiAoZW5hYmxlKSB7CisjaWZk
ZWYgQ09ORklHX1g4NgogCQlyYyA9IHJlcXVlc3RfaXJxKGRldl9kYXRhLT5pcnEsCiAJCQkJeGVu
X3BjaWJrX2d1ZXN0X2ludGVycnVwdCwgSVJRRl9TSEFSRUQsCiAJCQkJZGV2X2RhdGEtPmlycV9u
YW1lLCBkZXYpOwpAQCAtNzksNiArODAsNyBAQCBzdGF0aWMgdm9pZCB4ZW5fcGNpYmtfY29udHJv
bF9pc3Ioc3RydWN0IHBjaV9kZXYgKmRldiwgaW50IHJlc2V0KQogCQkJCWRldl9kYXRhLT5pcnFf
bmFtZSwgZGV2X2RhdGEtPmlycSwgcmMpOwogCQkJZ290byBvdXQ7CiAJCX0KKyNlbmRpZgogCX0g
ZWxzZSB7CiAJCWZyZWVfaXJxKGRldl9kYXRhLT5pcnEsIGRldik7CiAJCWRldl9kYXRhLT5pcnEg
PSAwOwpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4veGVuLXBjaWJhY2svdnBjaS5jIGIvZHJpdmVy
cy94ZW4veGVuLXBjaWJhY2svdnBjaS5jCmluZGV4IDUxYWZmZjkuLmIwNzMzMjcgMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3ZwY2kuYworKysgYi9kcml2ZXJzL3hlbi94ZW4t
cGNpYmFjay92cGNpLmMKQEAgLTExLDYgKzExLDEwIEBACiAjaW5jbHVkZSA8bGludXgvc2xhYi5o
PgogI2luY2x1ZGUgPGxpbnV4L3BjaS5oPgogI2luY2x1ZGUgPGxpbnV4L211dGV4Lmg+CisjaW5j
bHVkZSA8eGVuL3hlbi5oPgorI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvcGh5c2Rldi5oPgorI2lu
Y2x1ZGUgPGFzbS94ZW4vaHlwZXJ2aXNvci5oPgorI2luY2x1ZGUgPGFzbS94ZW4vaHlwZXJjYWxs
Lmg+CiAjaW5jbHVkZSAicGNpYmFjay5oIgogCiAjZGVmaW5lIFBDSV9TTE9UX01BWCAzMgpAQCAt
NzEsNiArNzUsOSBAQCBzdGF0aWMgaW50IF9feGVuX3BjaWJrX2FkZF9wY2lfZGV2KHN0cnVjdCB4
ZW5fcGNpYmtfZGV2aWNlICpwZGV2LAogCWludCBlcnIgPSAwLCBzbG90LCBmdW5jID0gLTE7CiAJ
c3RydWN0IHBjaV9kZXZfZW50cnkgKnQsICpkZXZfZW50cnk7CiAJc3RydWN0IHZwY2lfZGV2X2Rh
dGEgKnZwY2lfZGV2ID0gcGRldi0+cGNpX2Rldl9kYXRhOworCXN0cnVjdCBwaHlzZGV2X21hcF9z
YmRmIG1hcF9zYmRmOzsKKworcHJpbnRrKCIlcyAlZFxyXG4iLCBfX2Z1bmNfXywgX19MSU5FX18p
OwogCiAJaWYgKChkZXYtPmNsYXNzID4+IDI0KSA9PSBQQ0lfQkFTRV9DTEFTU19CUklER0UpIHsK
IAkJZXJyID0gLUVGQVVMVDsKQEAgLTExOCwxMSArMTI1LDExIEBAIHN0YXRpYyBpbnQgX194ZW5f
cGNpYmtfYWRkX3BjaV9kZXYoc3RydWN0IHhlbl9wY2lia19kZXZpY2UgKnBkZXYsCiAJLyogQXNz
aWduIHRvIGEgbmV3IHNsb3Qgb24gdGhlIHZpcnR1YWwgUENJIGJ1cyAqLwogCWZvciAoc2xvdCA9
IDA7IHNsb3QgPCBQQ0lfU0xPVF9NQVg7IHNsb3QrKykgewogCQlpZiAobGlzdF9lbXB0eSgmdnBj
aV9kZXYtPmRldl9saXN0W3Nsb3RdKSkgewotCQkJcHJfaW5mbygidnBjaTogJXM6IGFzc2lnbiB0
byB2aXJ0dWFsIHNsb3QgJWRcbiIsCi0JCQkJcGNpX25hbWUoZGV2KSwgc2xvdCk7CiAJCQlsaXN0
X2FkZF90YWlsKCZkZXZfZW50cnktPmxpc3QsCiAJCQkJICAgICAgJnZwY2lfZGV2LT5kZXZfbGlz
dFtzbG90XSk7CiAJCQlmdW5jID0gZGV2LT5pc192aXJ0Zm4gPyAwIDogUENJX0ZVTkMoZGV2LT5k
ZXZmbik7CisJCQlwcl9pbmZvKCJ2cGNpOiAlczogYXNzaWduIHRvIHZpcnR1YWwgc2xvdCAlZCBm
dW5jdGlvbiAlZFxuIiwKKwkJCQlwY2lfbmFtZShkZXYpLCBzbG90LCBmdW5jKTsKIAkJCWdvdG8g
dW5sb2NrOwogCQl9CiAJfQpAQCAtMTQwLDYgKzE0NywzMSBAQCB1bmxvY2s6CiAJZWxzZQogCQlr
ZnJlZShkZXZfZW50cnkpOwogCisJLypJc3N1ZSBIeXBlcmNhbGwgaGVyZSAqLworCisJbWFwX3Ni
ZGYuZG9tYWluX2lkID0gcGRldi0+eGRldi0+b3RoZXJlbmRfaWQ7CisJbWFwX3NiZGYuc2JkZl9z
ID0gZGV2LT5idXMtPmRvbWFpbl9ucjsKKwltYXBfc2JkZi5zYmRmX2IgPSBkZXYtPmJ1cy0+bnVt
YmVyOworCW1hcF9zYmRmLnNiZGZfZCA9IGRldi0+ZGV2Zm4+PjM7CisJbWFwX3NiZGYuc2JkZl9m
ID0gZGV2LT5kZXZmbiAmIDB4NzsKKwltYXBfc2JkZi5nc2JkZl9zID0gMDsKKwltYXBfc2JkZi5n
c2JkZl9iID0gMDsKKwltYXBfc2JkZi5nc2JkZl9kID0gc2xvdDsKKwltYXBfc2JkZi5nc2JkZl9m
ID0gZGV2LT5kZXZmbiAmIDB4NzsKKwlwcmludGsoS0VSTl9FUlIiIyMgc2JkZiA9ICVkOiVkOiVk
LiVkIGdfc2JkZiAlZDolZDolZC4lZCBkb21haW5faWQ9JWQgIyNcclxuIiwKKwltYXBfc2JkZi5z
YmRmX3MsCisJbWFwX3NiZGYuc2JkZl9iLAorCW1hcF9zYmRmLnNiZGZfZCwKKwltYXBfc2JkZi5z
YmRmX2YsCisJbWFwX3NiZGYuZ3NiZGZfcywKKwltYXBfc2JkZi5nc2JkZl9iLAorCW1hcF9zYmRm
LmdzYmRmX2QsCisJbWFwX3NiZGYuZ3NiZGZfZiwKKwltYXBfc2JkZi5kb21haW5faWQpOworCQor
CWVyciA9IEhZUEVSVklTT1JfcGh5c2Rldl9vcChQSFlTREVWT1BfbWFwX3NiZGYsICZtYXBfc2Jk
Zik7CisJaWYgKGVycikKKwkJcHJpbnRrKEtFUk5fRVJSICIgWGVuIEVycm9yIFBIWVNERVZPUF9t
YXBfc2JkZiIpOwogb3V0OgogCXJldHVybiBlcnI7CiB9CkBAIC0yNDMsNiArMjc1LDcgQEAgc3Rh
dGljIGludCBfX3hlbl9wY2lia19nZXRfcGNpZnJvbnRfZGV2KHN0cnVjdCBwY2lfZGV2ICpwY2lk
ZXYsCiAJCQkJKmJ1cyA9IDA7CiAJCQkJKmRldmZuID0gUENJX0RFVkZOKHNsb3QsCiAJCQkJCSBQ
Q0lfRlVOQyhwY2lkZXYtPmRldmZuKSk7CisJCQkJcHJpbnRrKEtFUk5fRVJSIiVzICVkOiVkOiVk
LiVkIFxyXG4iLCBfX2Z1bmNfXywgKmRvbWFpbiwgKmJ1cywgKCpkZXZmbik+PjMgLCAoKmRldmZu
KSYgMHg3KTsKIAkJCX0KIAkJfQogCX0KZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFj
ZS9waHlzZGV2LmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGh5c2Rldi5oCmluZGV4IDYxMGRi
YTkuLmYxMmFhNmIgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9waHlzZGV2LmgK
KysrIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BoeXNkZXYuaApAQCAtMjk2LDYgKzI5NiwyNyBA
QCBzdHJ1Y3QgcGh5c2Rldl9kYmdwX29wIHsKICAgICAgICAgc3RydWN0IHBoeXNkZXZfcGNpX2Rl
dmljZSBwY2k7CiAgICAgfSB1OwogfTsKKyNkZWZpbmUgUEhZU0RFVk9QX21hcF9tbWlvCQk0MAor
c3RydWN0IHBoeXNkZXZfbWFwX21taW8geworICAgIC8qIElOICovCisgICAgdWludDY0X3QgYWRk
cjsKKyAgICB1aW50NjRfdCBzaXplOwkKK307CisjZGVmaW5lIFBIWVNERVZPUF91bm1hcF9tbWlv
CQk0MQorCisjZGVmaW5lIFBIWVNERVZPUF9tYXBfc2JkZgkJNDMKK3N0cnVjdCBwaHlzZGV2X21h
cF9zYmRmIHsKKwlpbnQgZG9tYWluX2lkOworCWludCBzYmRmX3M7CisJaW50IHNiZGZfYjsKKwlp
bnQgc2JkZl9kOworCWludCBzYmRmX2Y7CisKKwlpbnQgZ3NiZGZfczsKKwlpbnQgZ3NiZGZfYjsK
KwlpbnQgZ3NiZGZfZDsKKwlpbnQgZ3NiZGZfZjsKK307CiAKIC8qCiAgKiBOb3RpZnkgdGhhdCBz
b21lIFBJUlEtYm91bmQgZXZlbnQgY2hhbm5lbHMgaGF2ZSBiZWVuIHVubWFza2VkLgotLSAKMS45
LjEKCg==
--089e0158b1568d74910507325860
Content-Type: application/octet-stream; 
	name="0002-SMMU-fix-sbdf-patch.patch"
Content-Disposition: attachment; filename="0002-SMMU-fix-sbdf-patch.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i269ooas2

RnJvbSA4NmI1ZGQ1MjU0ZmY5ZWVkOTk2ZDkzMzI2ODJjMDgwMDM1OTEwMTAzIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBtYW5pc2ggPG1hbmlzaC5qYWdnaUBjYXZpdW1uZXR3b3Jrcy5j
b20+CkRhdGU6IFdlZCwgNSBOb3YgMjAxNCAyMDoxMDo0MCArMDUzMApTdWJqZWN0OiBbUEFUQ0gg
Mi8yXSBTTU1VIGZpeCArIHNiZGYgcGF0Y2gKCi0tLQogdG9vbHMvbGlieGwvbGlieGxfcGNpLmMg
ICAgICAgICAgICB8ICA0ICsrKy0KIHhlbi9hcmNoL2FybS9waHlzZGV2LmMgICAgICAgICAgICAg
fCAzNCArKysrKysrKysrKysrKysrKysrKysrKysrLQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gv
YXJtL3NtbXUuYyB8ICAyICsrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2dpYy1pdHMuaCAgICAgIHwg
NDkgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0KIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vcGNpLmggICAgICAgICAgfCAgNCArKysrCiB4ZW4vaW5jbHVkZS9wdWJsaWMvcGh5c2Rl
di5oICAgICAgIHwgMTggKysrKysrKysrKysrKysKIDggZmlsZXMgY2hhbmdlZCwgMTI0IGluc2Vy
dGlvbnMoKyksIDI1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhs
X3BjaS5jIGIvdG9vbHMvbGlieGwvbGlieGxfcGNpLmMKaW5kZXggOWY0MDEwMC4uNjU3MWM2YSAx
MDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfcGNpLmMKKysrIGIvdG9vbHMvbGlieGwvbGli
eGxfcGNpLmMKQEAgLTk2OCwxMCArOTY4LDExIEBAIHN0YXRpYyBpbnQgZG9fcGNpX2FkZChsaWJ4
bF9fZ2MgKmdjLCB1aW50MzJfdCBkb21pZCwgbGlieGxfZGV2aWNlX3BjaSAqcGNpZGV2LCBpCiAg
ICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAiQ291bGRuJ3Qg
b3BlbiAlcyIsIHN5c2ZzX3BhdGgpOwogICAgICAgICBnb3RvIG91dDsKICAgICB9CisjaWZkZWYg
Q09ORklHX1g4NgogICAgIGlmICgoZnNjYW5mKGYsICIldSIsICZpcnEpID09IDEpICYmIGlycSkg
ewogICAgICAgICByYyA9IHhjX3BoeXNkZXZfbWFwX3BpcnEoY3R4LT54Y2gsIGRvbWlkLCBpcnEs
ICZpcnEpOwogICAgICAgICBpZiAocmMgPCAwKSB7CiAgICAgICAgICAgICBmY2xvc2UoZik7CiAg
ICAgICAgICAgICByZXR1cm4gRVJST1JfRkFJTDsKICAgICAgICAgfQpAQCAtOTgyLDYgKzk4Myw3
IEBAIHN0YXRpYyBpbnQgZG9fcGNpX2FkZChsaWJ4bF9fZ2MgKmdjLCB1aW50MzJfdCBkb21pZCwg
bGlieGxfZGV2aWNlX3BjaSAqcGNpZGV2LCBpCiAgICAgICAgICAgICByZXR1cm4gRVJST1JfRkFJ
TDsKICAgICAgICAgfQogICAgIH0KKyNlbmRpZgogICAgIGZjbG9zZShmKTsKIAogICAgIC8qIERv
bid0IHJlc3RyaWN0IHdyaXRlcyB0byB0aGUgUENJIGNvbmZpZyBzcGFjZSBmcm9tIHRoaXMgVk0g
Ki8KIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3BoeXNkZXYuYyBiL3hlbi9hcmNoL2FybS9w
aHlzZGV2LmMKaW5kZXggNzc2MjgwNi4uOGM2ODQ4NyAxMDA2NDQKLS0tIGEveGVuL2FyY2gvYXJt
L3BoeXNkZXYuYworKysgYi94ZW4vYXJjaC9hcm0vcGh5c2Rldi5jCkBAIC0zOCwxMSArMzgsNDMg
QEAKIGludCBkb19waHlzZGV2X29wKGludCBjbWQsIFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0odm9p
ZCkgYXJnKQogewogICAvLyAgaW50IGlycTsKLSAgICBpbnQgcmV0PTA7CisgICAgaW50IHJldD0t
MTsKICAgICBzdHJ1Y3QgdmNwdSAqdiA9IGN1cnJlbnQ7CiAJcHJpbnRrKCIlcyBjbWQ9JWRcclxu
IiwgX19mdW5jX18gLCBjbWQpOwogICAgIHN3aXRjaCAoIGNtZCApCiAgICAgeworICAgIGNhc2Ug
UEhZU0RFVk9QX21hcF9zYmRmOnsKKyAgICAgICAgc3RydWN0IHBoeXNkZXZfbWFwX3NiZGYgbWFw
X3NiZGY7CisgICAgICAgIHN0cnVjdCBkb21haW4gKmQ7CisgICAgICAgIHN0cnVjdCBwY2lfZGV2
ICpwZGV2OworCisgICAgICAgIGlmICggY29weV9mcm9tX2d1ZXN0KCZtYXBfc2JkZiwgYXJnLCAx
KSAhPSAwICkKKyAgICAgICAgICAgIGJyZWFrOworCisgICAgICAgIGZvcl9lYWNoX2RvbWFpbihk
KXsKKyAgICAgICAgCXByaW50aygiQCNAICVkICVkXHJcbiIsZC0+ZG9tYWluX2lkICwgbWFwX3Ni
ZGYuZG9tYWluX2lkKTsKKyAgICAgICAgCWlmKGQtPmRvbWFpbl9pZCA9PSBtYXBfc2JkZi5kb21h
aW5faWQpeworICAgICAgICAJCWZvcl9lYWNoX3BkZXYoZCxwZGV2KXsKKyAgICAgICAgCQkJcHJp
bnRrKCJAQCAlZDolZDolZDolZCwgJWQ6JWQ6JWQ6JWQgXHJcbiIsCisgICAgICAgIAkJCQkJcGRl
di0+c2VnLHBkZXYtPmJ1cyxwZGV2LT5kZXZmbj4+MyxwZGV2LT5kZXZmbiAmIDB4NywKKyAgICAg
ICAgCQkJCQltYXBfc2JkZi5zYmRmX3MsbWFwX3NiZGYuc2JkZl9iLG1hcF9zYmRmLnNiZGZfZCxt
YXBfc2JkZi5zYmRmX2YpOworCisgICAgICAgIAkJCWlmKHBkZXYtPnNlZyA9PSBtYXBfc2JkZi5z
YmRmX3MgJiYKKyAgICAgICAgCQkJcGRldi0+YnVzID09IG1hcF9zYmRmLnNiZGZfYiAmJgorICAg
ICAgICAJCQkocGRldi0+ZGV2Zm4gPj4gMykgPT0gbWFwX3NiZGYuc2JkZl9kICYmCisgICAgICAg
IAkJCShwZGV2LT5kZXZmbiAmIDB4NykgPT0gbWFwX3NiZGYuc2JkZl9mKXsKKyAgICAgICAgCQkJ
CQlwZGV2LT5hcmNoLmdzYmRmX3MgPSBtYXBfc2JkZi5nc2JkZl9zOworICAgICAgICAJCQkJCXBk
ZXYtPmFyY2guZ3NiZGZfYiA9IG1hcF9zYmRmLmdzYmRmX2I7CisgICAgICAgIAkJCQkJcGRldi0+
YXJjaC5nc2JkZl9kID0gbWFwX3NiZGYuZ3NiZGZfZDsKKyAgICAgICAgCQkJCQlwZGV2LT5hcmNo
LmdzYmRmX2YgPSBtYXBfc2JkZi5nc2JkZl9mOworCQkJCQkJcmV0dXJuIDA7CisgICAgICAgIAkJ
CX0KKyAgICAgICAgCQl9CisgICAgICAgIAl9CisgICAgICAgIH0KKyAgICBicmVhazsKKyAgICB9
CisKICAgICBjYXNlIFBIWVNERVZPUF9tYXBfbW1pbzogewogCXN0cnVjdCBwaHlzZGV2X21hcF9t
bWlvIG1hcG07CiAgICAgICAgIHU2NCBhZGRyOwpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFz
c3Rocm91Z2gvYXJtL3NtbXUuYyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LmMK
aW5kZXggNTY0ZmY5Ni4uYzFhMjliNSAxMDA2NDQKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91
Z2gvYXJtL3NtbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS5jCkBA
IC0yMDg2LDYgKzIwODYsOCBAQCBvdXRfZXJyOgogc3RhdGljIGNvbnN0IGNoYXIgKiBjb25zdCBz
bW11X2R0X2NvbXBhdFtdIF9faW5pdGNvbnN0ID0KIHsKICAgICAiYXJtLG1tdS00MDAiLAorICAg
ICJhcm0sbW11LTUwMCIsCisgICAgInRodW5kZXIsc21tdS12MiIsCiAgICAgTlVMTAogfTsKIApk
aWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLWFybS9naWMtaXRzLmggYi94ZW4vaW5jbHVkZS9h
c20tYXJtL2dpYy1pdHMuaAppbmRleCA5OThjYmQ5Li5iZDc0MDU5IDEwMDY0NAotLS0gYS94ZW4v
aW5jbHVkZS9hc20tYXJtL2dpYy1pdHMuaAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2dpYy1p
dHMuaApAQCAtOTQsMTAgKzk0LDQwIEBAIHN0YXRpYyBpbmxpbmUgdWludDhfdCBpdHNfZGVjb2Rl
X2NtZChzdHJ1Y3QgaXRzX2NtZF9ibG9jayAqY21kKQogICAgIHJldHVybiBjbWQtPnJhd19jbWRb
MF0gJiAweGZmOwogfQogCi1zdGF0aWMgaW5saW5lIHVpbnQzMl90IGl0c19kZWNvZGVfZGV2aWQo
c3RydWN0IGl0c19jbWRfYmxvY2sgKmNtZCkKK3N0YXRpYyBpbmxpbmUgaW50IG1hcF9nc2JkZihz
dHJ1Y3QgZG9tYWluICpkLCB1aW50MzJfdCBnc2JkZiwgdWludDMyX3QgKnNiZGYpCiB7CisJc3Ry
dWN0IHBjaV9kZXYgKnBkZXY7CisJaW50IHJldCA9IC0xOworCXVpbnQzMl90IHRtcF9zYmRmLHQ7
CisKKwlpZihkLT5kb21haW5faWQgPT0gMCkgeworCQkqc2JkZiA9IGdzYmRmOworCQlyZXR1cm4g
MDsKKwl9CisKKwlmb3JfZWFjaF9wZGV2KGQscGRldil7CisJCXRtcF9zYmRmID0gKHBkZXYtPmFy
Y2guZ3NiZGZfcyA8PCAxNikgfAorCQkJCShwZGV2LT5hcmNoLmdzYmRmX2IgPDwgOCkgfAorCQkJ
CShwZGV2LT5hcmNoLmdzYmRmX2QgPDwzKSB8CisJCQkJcGRldi0+YXJjaC5nc2JkZl9mOworCQl0
ID0gKHBkZXYtPnNlZyA8PDE2KSB8IChwZGV2LT5idXMgPDw4KSB8IHBkZXYtPmRldmZuOworCQlw
cmludGsoS0VSTl9FUlIiJXMgRG9tYWluPSVkIHRtcF9zYmRmPSVkICBnc2JkZj0lZCBzYmRmPSVk
XHJcbiIsCisJCQkJX19mdW5jX18sZC0+ZG9tYWluX2lkLCB0bXBfc2JkZiwgZ3NiZGYsIHQpOwor
CQlpZih0bXBfc2JkZiA9PSBnc2JkZikgeworCQkJKnNiZGYgPSB0OworCQkJcmV0ID0gMDsKKwkJ
CWJyZWFrOworCQl9CisJfQorCXJldHVybiByZXQ7Cit9CitzdGF0aWMgaW5saW5lIHVpbnQzMl90
IGl0c19kZWNvZGVfZGV2aWQoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGl0c19jbWRfYmxvY2sg
KmNtZCkKK3sKKwl1aW50MzJfdCBudmFsOwogICAgIHVpbnQzMl90IHZhbCA9IGNtZC0+cmF3X2Nt
ZFswXSA+PiAzMjsKLSAgICBpZih2YWw9PTApIHJldHVybiAweDEwMDI4OworICAgIGlmKCFtYXBf
Z3NiZGYoZCx2YWwsJm52YWwpKQorICAgIAlyZXR1cm4gbnZhbDsKKwogICAgIHJldHVybiAoY21k
LT5yYXdfY21kWzBdID4+IDMyKTsgIAogfQogCkBAIC0xNDIsOSArMTcyLDIwIEBAIHN0YXRpYyBp
bmxpbmUgdm9pZCBpdHNfZW5jb2RlX2NtZChzdHJ1Y3QgaXRzX2NtZF9ibG9jayAqY21kLCB1OCBj
bWRfbnIpCiAgICAgY21kLT5yYXdfY21kWzBdIHw9IGNtZF9ucjsKIH0KIAotc3RhdGljIGlubGlu
ZSB2b2lkIGl0c19lbmNvZGVfZGV2aWQoc3RydWN0IGl0c19jbWRfYmxvY2sgKmNtZCwgdWludDMy
X3QgZGV2aWQpCitzdGF0aWMgaW5saW5lIHZvaWQgaXRzX2VuY29kZV9kZXZpZChzdHJ1Y3QgZG9t
YWluICpkLCBzdHJ1Y3QgaXRzX2NtZF9ibG9jayAqY21kLCB1aW50MzJfdCBkZXZpZCkKK3sKKwl1
aW50MzJfdCBuZGV2aWQ7CisgICAgaWYoIW1hcF9nc2JkZihkLGRldmlkLCZuZGV2aWQpKQorICAg
IAlkZXZpZCA9IG5kZXZpZDsKKworICAgIGNtZC0+cmF3X2NtZFswXSAmPSB+KDB4ZmZmZlVMIDw8
IDMyKTsKKyAgICBjbWQtPnJhd19jbWRbMF0gfD0gKCh1aW50NjRfdClkZXZpZCAmIDB4ZmZmZmZm
ZmZVTCkgPDwgMzI7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBfaXRzX2VuY29kZV9kZXZpZChz
dHJ1Y3QgaXRzX2NtZF9ibG9jayAqY21kLCB1aW50MzJfdCBkZXZpZCkKIHsKLSAgICBpZihkZXZp
ZD09MCkgZGV2aWQgPSAweDEwMDI4OworCiAgICAgY21kLT5yYXdfY21kWzBdICY9IH4oMHhmZmZm
VUwgPDwgMzIpOwogICAgIGNtZC0+cmF3X2NtZFswXSB8PSAoKHVpbnQ2NF90KWRldmlkICYgMHhm
ZmZmZmZmZlVMKSA8PCAzMjsKIH0KZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vcGNp
LmggYi94ZW4vaW5jbHVkZS9hc20tYXJtL3BjaS5oCmluZGV4IGQyMGEyOTkuLmJmZTg2ZjUgMTAw
NjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vcGNpLmgKKysrIGIveGVuL2luY2x1ZGUvYXNt
LWFybS9wY2kuaApAQCAtNiw2ICs2LDEwIEBACiBzdHJ1Y3QgYXJjaF9wY2lfZGV2IHsKIAl1NjQg
YWRkcltNQVhfUENJX0JBUlNdOwogCXU2NCBzaXplW01BWF9QQ0lfQkFSU107CisgICAgaW50IGdz
YmRmX3M7CisgICAgaW50IGdzYmRmX2I7CisgICAgaW50IGdzYmRmX2Q7CisgICAgaW50IGdzYmRm
X2Y7CiAJaW50IHZhbGlkOwogfTsKIHN0cnVjdCBwY2lfY29uZiB7CmRpZmYgLS1naXQgYS94ZW4v
aW5jbHVkZS9wdWJsaWMvcGh5c2Rldi5oIGIveGVuL2luY2x1ZGUvcHVibGljL3BoeXNkZXYuaApp
bmRleCA5ZDE1Mjg2Li5kNGFkMzhjIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvcGh5
c2Rldi5oCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9waHlzZGV2LmgKQEAgLTM0NCw5ICszNDQs
MjcgQEAgc3RydWN0IHBoeXNkZXZfbWFwX21taW8gewogICAgIHVpbnQ2NF90IGFkZHI7CiAgICAg
dWludDY0X3Qgc2l6ZTsKIH07CisKICNkZWZpbmUgUEhZU0RFVk9QX3BjaV9kb21haW5fZGV0YWNo
ICAgICAgICAgICAgICA0MgogdHlwZWRlZiBzdHJ1Y3QgcGh5c2Rldl9tYXBfbW1pbyBwaHlzZGV2
X21hcF9tbWlvX3Q7CiBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShwaHlzZGV2X21hcF9tbWlvX3Qp
OworCisjZGVmaW5lIFBIWVNERVZPUF9tYXBfc2JkZgkJNDMKK3N0cnVjdCBwaHlzZGV2X21hcF9z
YmRmIHsKKwlpbnQgZG9tYWluX2lkOworCWludCBzYmRmX3M7CisJaW50IHNiZGZfYjsKKwlpbnQg
c2JkZl9kOworCWludCBzYmRmX2Y7CisKKwlpbnQgZ3NiZGZfczsKKwlpbnQgZ3NiZGZfYjsKKwlp
bnQgZ3NiZGZfZDsKKwlpbnQgZ3NiZGZfZjsKK307Cit0eXBlZGVmIHN0cnVjdCBwaHlzZGV2X21h
cF9zYmRmIHBoeXNkZXZfbWFwX3NiZGZfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHBoeXNk
ZXZfbWFwX3NiZGZfdCk7CisKIC8qCiAgKiBOb3RpZnkgdGhhdCBzb21lIFBJUlEtYm91bmQgZXZl
bnQgY2hhbm5lbHMgaGF2ZSBiZWVuIHVubWFza2VkLgogICogKiogVGhpcyBjb21tYW5kIGlzIG9i
c29sZXRlIHNpbmNlIGludGVyZmFjZSB2ZXJzaW9uIDB4MDAwMzAyMDIgYW5kIGlzICoqCi0tIAox
LjkuMQoK
--089e0158b1568d74910507325860
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--089e0158b1568d74910507325860--


From xen-devel-bounces@lists.xen.org Thu Nov 06 15:28:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOz4-0005IT-2z; Thu, 06 Nov 2014 15:28:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XmOz1-0005Ht-PS
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:28:24 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	7B/3F-02696-7939B545; Thu, 06 Nov 2014 15:28:23 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415287699!11866482!1
X-Originating-IP: [209.85.220.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14777 invoked from network); 6 Nov 2014 15:28:20 -0000
Received: from mail-vc0-f174.google.com (HELO mail-vc0-f174.google.com)
	(209.85.220.174)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:28:20 -0000
Received: by mail-vc0-f174.google.com with SMTP id im17so652399vcb.19
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:28:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Ko/E/hgvTswLyTISYvTeVH44ZNbX0scGn7dn8zQN1BQ=;
	b=mCUUwzzzQrWt/Qzym3dZpOhpyL9xE/GtpFEPhxRNczi5q8asXjkuvCNZyZyt60aVTE
	cLn5NTivGuwk1WRhMnoA5qgMQ93jF9TfO/gLEyjuDmHqXJk7FJSY+rg6ioRP+sY2P38F
	1eNdxJNKwKoERRXTX4m9lwV7Gez36s2WGktbEMXn27OLW4kit+eV2ecUJ5eWspwcTXk/
	IMDbnMiSy3Nk40n4gmTJkvIlI2WJjUYCJeVi22Vv47jTWvJkAbfpjEZQt8SVdvxzmjvc
	I2DEUtGiq26IWqIVtdbC8Gi3B5od9Bs7dba5eerM8dcBRaRIqVLtZBswzX/rRVms59Hf
	OQFg==
MIME-Version: 1.0
X-Received: by 10.220.202.199 with SMTP id ff7mr268247vcb.57.1415287698719;
	Thu, 06 Nov 2014 07:28:18 -0800 (PST)
Received: by 10.221.57.8 with HTTP; Thu, 6 Nov 2014 07:28:18 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>
	<CAAiw7Jmg+p0--fFYcRnMDA2DdQ7Ss5zjH9iuLHeX=TpBPZYGbA@mail.gmail.com>
	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>
	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>
	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
Date: Thu, 6 Nov 2014 20:58:18 +0530
Message-ID: <CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, JBeulich@suse.com, 
	Julien Grall <julien.grall@linaro.org>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>
Content-Type: multipart/mixed; boundary=089e0158b1568d74910507325860
Cc: manish.jaggi@caviumnetworks.com, Ryan Wilson <hap9@epoch.ncsc.mil>,
	Vijay Kilari <vijay.kilari@gmail.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--089e0158b1568d74910507325860
Content-Type: text/plain; charset=UTF-8

On 20 October 2014 20:24, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 20 Oct 2014, manish jaggi wrote:
>> On 8 October 2014 20:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
>> >> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
>> >> >> Thanks for replying. As detailed in this thread, I need to create a
>> >> >> hypercall that would send the following information to Xen at the time
>> >> >> of PCI attach
>> >> >> { sbdf , domU sbdf, domainId }.
>> >> >> I am not able to find a way to get the domU sbdf from dom0 at the time
>> >> >> of pci-attach.
>> >> >
>> >> > I think it would need to be done by the pciback driver in the dom0
>> >> > kernel, which AFAIK is the thing which consistently knows both physical
>> >> > and virtual sbdf for a given assigned device.
>> >> >
>> >> > Ian.
>> >> >
>> >> Correct, can you point out which data structure holds the domU sbdf
>> >> corresponding to the actual sbdf in pciback.
>> >
>> > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
>> > is that what you are referring to?
>>
>> Xen docs also mention about xen-pciback.passthrough=1. If I set this
>> in dom0 i see that the device is enumerated as the same sbdf in domU,
>> but
>> a) it is not shown in lspci
>> b) no front-back communication is done for reading devices configuration space
>> .
>> Is option useful / fully implemented for ARM ?
>
> I don't think this option is very useful. I wouldn't worry about it for
> now.

Stefano / Ian / Konard / Julien,

Attached is a first raw code FYI RFC Patches of PCI passthrough support on ARM.
- Linux Patch (3.18)
- Xen Patch  (4.5 staging)
---(Smmu changes not included, thats a separate patch altogether)
This patches show the logic, at places need of improvements in code
organization/quality. I wanted to share to get initial comments.
This is working with SRIOV as well.

Please have a look and let me know your positive comments

--089e0158b1568d74910507325860
Content-Type: application/octet-stream; 
	name="0002-Removing-X86-as-a-dependency-on-XEN_PCI_FRONTEND-and.patch"
Content-Disposition: attachment; 
	filename="0002-Removing-X86-as-a-dependency-on-XEN_PCI_FRONTEND-and.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i269o8gs0

RnJvbSBhMjlkNjU4ZWVhOTMzNzNhZDU5N2Q4NDlkZjUzMGZiMWZjOWE3MDY2IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBtYW5pc2ggPG1hbmlzaC5qYWdnaUBjYXZpdW1uZXR3b3Jrcy5j
b20+CkRhdGU6IFdlZCwgNSBOb3YgMjAxNCAxMjoxNzowNSArMDUzMApTdWJqZWN0OiBbUEFUQ0gg
Mi81XSBSZW1vdmluZyBYODYgYXMgYSBkZXBlbmRlbmN5IG9uIFhFTl9QQ0lfRlJPTlRFTkQgYW5k
CiBYRU5fUENJX0JBQ0tFTkQKCi0tLQogZHJpdmVycy9wY2kvS2NvbmZpZyB8IDIgKy0KIGRyaXZl
cnMveGVuL0tjb25maWcgfCAyICstCiAyIGZpbGVzIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKSwg
MiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kcml2ZXJzL3BjaS9LY29uZmlnIGIvZHJpdmVy
cy9wY2kvS2NvbmZpZwppbmRleCA4OTM1MDNmLi5jNTM0Y2UwIDEwMDY0NAotLS0gYS9kcml2ZXJz
L3BjaS9LY29uZmlnCisrKyBiL2RyaXZlcnMvcGNpL0tjb25maWcKQEAgLTUwLDcgKzUwLDcgQEAg
Y29uZmlnIFBDSV9TVFVCCiAKIGNvbmZpZyBYRU5fUENJREVWX0ZST05URU5ECiAgICAgICAgIHRy
aXN0YXRlICJYZW4gUENJIEZyb250ZW5kIgotICAgICAgICBkZXBlbmRzIG9uIFBDSSAmJiBYODYg
JiYgWEVOCisgICAgICAgIGRlcGVuZHMgb24gUENJICYmIFhFTgogICAgICAgICBzZWxlY3QgUENJ
X1hFTgogCXNlbGVjdCBYRU5fWEVOQlVTX0ZST05URU5ECiAgICAgICAgIGRlZmF1bHQgeQpkaWZm
IC0tZ2l0IGEvZHJpdmVycy94ZW4vS2NvbmZpZyBiL2RyaXZlcnMveGVuL0tjb25maWcKaW5kZXgg
YjgxMjQ2Mi4uMTMzMmVlZCAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vS2NvbmZpZworKysgYi9k
cml2ZXJzL3hlbi9LY29uZmlnCkBAIC0xNTEsNyArMTUxLDcgQEAgY29uZmlnIFhFTl9UTUVNCiAK
IGNvbmZpZyBYRU5fUENJREVWX0JBQ0tFTkQKIAl0cmlzdGF0ZSAiWGVuIFBDSS1kZXZpY2UgYmFj
a2VuZCBkcml2ZXIiCi0JZGVwZW5kcyBvbiBQQ0kgJiYgWDg2ICYmIFhFTgorCWRlcGVuZHMgb24g
UENJICYmIFhFTgogCWRlcGVuZHMgb24gWEVOX0JBQ0tFTkQKIAlkZWZhdWx0IG0KIAloZWxwCi0t
IAoxLjkuMQoK
--089e0158b1568d74910507325860
Content-Type: application/octet-stream; 
	name="0005-PCI-passthrough-support-for-Xen.patch"
Content-Disposition: attachment; 
	filename="0005-PCI-passthrough-support-for-Xen.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i269o8h41

RnJvbSA3MTY1ZGRjMmRmZGQ0MTZiZWI5NjRhZjM5NjZiMmEyY2Q1NTYyMzcxIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBtYW5pc2ggPG1hbmlzaC5qYWdnaUBjYXZpdW1uZXR3b3Jrcy5j
b20+CkRhdGU6IFdlZCwgNSBOb3YgMjAxNCAyMDowNToyNSArMDUzMApTdWJqZWN0OiBbUEFUQ0gg
NS81XSBQQ0kgcGFzc3Rocm91Z2ggc3VwcG9ydCBmb3IgWGVuIGEpIE1BUCBTQkRGIGh5cGVyY2Fs
bAogYWRkZWQgYikgTUFQIE1NSU8gQkFSIHJlZ2lvbnMgaHlwZXJjYWxsIGFkZGVkIGMpIEJhc2lj
IFBDSSBwYXNzdGhyb3VnaCBBUk0KIHN1cHBvcnQKCi0tLQogYXJjaC9hcm02NC9pbmNsdWRlL2Fz
bS94ZW4vcGNpLmggICAgICAgICB8IDgyICsrKysrKysrKysrKysrKysrKysrKysrKysrKwogYXJj
aC9hcm02NC9pbmNsdWRlL2FzbS94ZW4vc3dpb3RsYi14ZW4uaCB8ICA3ICsrKwogYXJjaC9hcm02
NC94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgICAgICB8ICAyICstCiBhcmNoL2FybTY0L3hlbi94
ZW5fcGNpLmMgICAgICAgICAgICAgICAgIHwgOTUgKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysKIGRyaXZlcnMvcGNpL3hlbi1wY2lmcm9udC5jICAgICAgICAgICAgICAgfCAzMiArKysr
KysrKystLQogZHJpdmVycy94ZW4vcGNpLmMgICAgICAgICAgICAgICAgICAgICAgICB8IDY3ICsr
KysrKysrKysrKysrKysrKysrKy0KIGRyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaV9zdHViLmMg
ICAgICAgfCAgNCArLQogZHJpdmVycy94ZW4veGVuLXBjaWJhY2svcGNpYmFjay5oICAgICAgICB8
ICA0ICsrCiBkcml2ZXJzL3hlbi94ZW4tcGNpYmFjay9wY2liYWNrX29wcy5jICAgIHwgIDIgKwog
ZHJpdmVycy94ZW4veGVuLXBjaWJhY2svdnBjaS5jICAgICAgICAgICB8IDM3ICsrKysrKysrKysr
Ky0KIGluY2x1ZGUveGVuL2ludGVyZmFjZS9waHlzZGV2LmggICAgICAgICAgfCAyMSArKysrKysr
CiAxMSBmaWxlcyBjaGFuZ2VkLCAzNDAgaW5zZXJ0aW9ucygrKSwgMTMgZGVsZXRpb25zKC0pCiBj
cmVhdGUgbW9kZSAxMDA2NDQgYXJjaC9hcm02NC9pbmNsdWRlL2FzbS94ZW4vcGNpLmgKIGNyZWF0
ZSBtb2RlIDEwMDY0NCBhcmNoL2FybTY0L2luY2x1ZGUvYXNtL3hlbi9zd2lvdGxiLXhlbi5oCiBj
cmVhdGUgbW9kZSAxMDA2NDQgYXJjaC9hcm02NC94ZW4veGVuX3BjaS5jCgpkaWZmIC0tZ2l0IGEv
YXJjaC9hcm02NC9pbmNsdWRlL2FzbS94ZW4vcGNpLmggYi9hcmNoL2FybTY0L2luY2x1ZGUvYXNt
L3hlbi9wY2kuaApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi41NzkwZWZlCi0t
LSAvZGV2L251bGwKKysrIGIvYXJjaC9hcm02NC9pbmNsdWRlL2FzbS94ZW4vcGNpLmgKQEAgLTAs
MCArMSw4MiBAQAorI2lmbmRlZiBfQVNNX0FSTV9YRU5fUENJX0gKKyNkZWZpbmUgX0FTTV9BUk1f
WEVOX1BDSV9ICisKKyNpZiBkZWZpbmVkKENPTkZJR19QQ0lfWEVOKQorZXh0ZXJuIGludCBfX2lu
aXQgcGNpX3hlbl9pbml0KHZvaWQpOworZXh0ZXJuIGludCBfX2luaXQgcGNpX3hlbl9odm1faW5p
dCh2b2lkKTsKKyNkZWZpbmUgcGNpX3hlbiAxCisjZWxzZQorI2RlZmluZSBwY2lfeGVuIDAKKyNk
ZWZpbmUgcGNpX3hlbl9pbml0ICgwKQorc3RhdGljIGlubGluZSBpbnQgcGNpX3hlbl9odm1faW5p
dCh2b2lkKQoreworCXJldHVybiAtMTsKK30KKyNlbmRpZgorI2lmIGRlZmluZWQoQ09ORklHX1hF
Tl9ET00wKQoraW50IF9faW5pdCBwY2lfeGVuX2luaXRpYWxfZG9tYWluKHZvaWQpOworaW50IHhl
bl9maW5kX2RldmljZV9kb21haW5fb3duZXIoc3RydWN0IHBjaV9kZXYgKmRldik7CitpbnQgeGVu
X3JlZ2lzdGVyX2RldmljZV9kb21haW5fb3duZXIoc3RydWN0IHBjaV9kZXYgKmRldiwgdWludDE2
X3QgZG9tYWluKTsKK2ludCB4ZW5fdW5yZWdpc3Rlcl9kZXZpY2VfZG9tYWluX293bmVyKHN0cnVj
dCBwY2lfZGV2ICpkZXYpOworI2Vsc2UKK3N0YXRpYyBpbmxpbmUgaW50IF9faW5pdCBwY2lfeGVu
X2luaXRpYWxfZG9tYWluKHZvaWQpCit7CisJcmV0dXJuIC0xOworfQorc3RhdGljIGlubGluZSBp
bnQgeGVuX2ZpbmRfZGV2aWNlX2RvbWFpbl9vd25lcihzdHJ1Y3QgcGNpX2RldiAqZGV2KQorewor
CXJldHVybiAtMTsKK30KK3N0YXRpYyBpbmxpbmUgaW50IHhlbl9yZWdpc3Rlcl9kZXZpY2VfZG9t
YWluX293bmVyKHN0cnVjdCBwY2lfZGV2ICpkZXYsCisJCQkJCQkgICB1aW50MTZfdCBkb21haW4p
Cit7CisJcmV0dXJuIC0xOworfQorc3RhdGljIGlubGluZSBpbnQgeGVuX3VucmVnaXN0ZXJfZGV2
aWNlX2RvbWFpbl9vd25lcihzdHJ1Y3QgcGNpX2RldiAqZGV2KQoreworCXJldHVybiAtMTsKK30K
KyNlbmRpZgorCisjaWYgZGVmaW5lZChDT05GSUdfUENJX01TSSkKKyNpZiBkZWZpbmVkKENPTkZJ
R19QQ0lfWEVOKQorLyogVGhlIGRyaXZlcnMvcGNpL3hlbi1wY2lmcm9udC5jIHNldHMgdGhpcyBz
dHJ1Y3R1cmUgdG8KKyAqIGl0cyBvd24gZnVuY3Rpb25zLgorICovCitzdHJ1Y3QgeGVuX3BjaV9m
cm9udGVuZF9vcHMgeworCWludCAoKmVuYWJsZV9tc2kpKHN0cnVjdCBwY2lfZGV2ICpkZXYsIGlu
dCB2ZWN0b3JzW10pOworCXZvaWQgKCpkaXNhYmxlX21zaSkoc3RydWN0IHBjaV9kZXYgKmRldik7
CisJaW50ICgqZW5hYmxlX21zaXgpKHN0cnVjdCBwY2lfZGV2ICpkZXYsIGludCB2ZWN0b3JzW10s
IGludCBudmVjKTsKKwl2b2lkICgqZGlzYWJsZV9tc2l4KShzdHJ1Y3QgcGNpX2RldiAqZGV2KTsK
K307CisKK2V4dGVybiBzdHJ1Y3QgeGVuX3BjaV9mcm9udGVuZF9vcHMgKnhlbl9wY2lfZnJvbnRl
bmQ7CisKK3N0YXRpYyBpbmxpbmUgaW50IHhlbl9wY2lfZnJvbnRlbmRfZW5hYmxlX21zaShzdHJ1
Y3QgcGNpX2RldiAqZGV2LAorCQkJCQkgICAgICBpbnQgdmVjdG9yc1tdKQoreworCWlmICh4ZW5f
cGNpX2Zyb250ZW5kICYmIHhlbl9wY2lfZnJvbnRlbmQtPmVuYWJsZV9tc2kpCisJCXJldHVybiB4
ZW5fcGNpX2Zyb250ZW5kLT5lbmFibGVfbXNpKGRldiwgdmVjdG9ycyk7CisJcmV0dXJuIC1FTk9E
RVY7Cit9CitzdGF0aWMgaW5saW5lIHZvaWQgeGVuX3BjaV9mcm9udGVuZF9kaXNhYmxlX21zaShz
dHJ1Y3QgcGNpX2RldiAqZGV2KQoreworCWlmICh4ZW5fcGNpX2Zyb250ZW5kICYmIHhlbl9wY2lf
ZnJvbnRlbmQtPmRpc2FibGVfbXNpKQorCQkJeGVuX3BjaV9mcm9udGVuZC0+ZGlzYWJsZV9tc2ko
ZGV2KTsKK30KK3N0YXRpYyBpbmxpbmUgaW50IHhlbl9wY2lfZnJvbnRlbmRfZW5hYmxlX21zaXgo
c3RydWN0IHBjaV9kZXYgKmRldiwKKwkJCQkJICAgICAgIGludCB2ZWN0b3JzW10sIGludCBudmVj
KQoreworCWlmICh4ZW5fcGNpX2Zyb250ZW5kICYmIHhlbl9wY2lfZnJvbnRlbmQtPmVuYWJsZV9t
c2l4KQorCQlyZXR1cm4geGVuX3BjaV9mcm9udGVuZC0+ZW5hYmxlX21zaXgoZGV2LCB2ZWN0b3Jz
LCBudmVjKTsKKwlyZXR1cm4gLUVOT0RFVjsKK30KK3N0YXRpYyBpbmxpbmUgdm9pZCB4ZW5fcGNp
X2Zyb250ZW5kX2Rpc2FibGVfbXNpeChzdHJ1Y3QgcGNpX2RldiAqZGV2KQoreworCWlmICh4ZW5f
cGNpX2Zyb250ZW5kICYmIHhlbl9wY2lfZnJvbnRlbmQtPmRpc2FibGVfbXNpeCkKKwkJCXhlbl9w
Y2lfZnJvbnRlbmQtPmRpc2FibGVfbXNpeChkZXYpOworfQorI2VuZGlmIC8qIENPTkZJR19QQ0lf
WEVOICovCisjZW5kaWYgLyogQ09ORklHX1BDSV9NU0kgKi8KKworI2VuZGlmCS8qIF9BU01fWDg2
X1hFTl9QQ0lfSCAqLwpkaWZmIC0tZ2l0IGEvYXJjaC9hcm02NC9pbmNsdWRlL2FzbS94ZW4vc3dp
b3RsYi14ZW4uaCBiL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20veGVuL3N3aW90bGIteGVuLmgKbmV3
IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uMDJhYjJhMQotLS0gL2Rldi9udWxsCisr
KyBiL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20veGVuL3N3aW90bGIteGVuLmgKQEAgLTAsMCArMSw3
IEBACisjaWZuZGVmIEFSTTY0X1NXSU9UTEJfWEVOCisjZGVmaW5lIEFSTTY0X1NXSU9UTEJfWEVO
CisvKiBQbGFjZSBob2xkZXIgZmlsZSAqLworc3RhdGljIGlubGluZSBpbnQgX19pbml0IHBjaV94
ZW5fc3dpb3RsYl9kZXRlY3Qodm9pZCkgeyByZXR1cm4gMDsgfQorc3RhdGljIGlubGluZSB2b2lk
IF9faW5pdCBwY2lfeGVuX3N3aW90bGJfaW5pdCh2b2lkKSB7IH0KK3N0YXRpYyBpbmxpbmUgaW50
IHBjaV94ZW5fc3dpb3RsYl9pbml0X2xhdGUodm9pZCkgeyByZXR1cm4gLUVOWElPOyB9CisjZW5k
aWYKZGlmZiAtLWdpdCBhL2FyY2gvYXJtNjQveGVuL01ha2VmaWxlIGIvYXJjaC9hcm02NC94ZW4v
TWFrZWZpbGUKaW5kZXggNzRhOGQ4Ny4uODE4ZWM0NSAxMDA2NDQKLS0tIGEvYXJjaC9hcm02NC94
ZW4vTWFrZWZpbGUKKysrIGIvYXJjaC9hcm02NC94ZW4vTWFrZWZpbGUKQEAgLTEsMiArMSwyIEBA
CiB4ZW4tYXJtLXkJKz0gJChhZGRwcmVmaXggLi4vLi4vYXJtL3hlbi8sIGVubGlnaHRlbi5vIGdy
YW50LXRhYmxlLm8gcDJtLm8gbW0ubykKLW9iai15CQk6PSB4ZW4tYXJtLm8gaHlwZXJjYWxsLm8K
K29iai15CQk6PSB4ZW4tYXJtLm8gaHlwZXJjYWxsLm8geGVuX3BjaS5vCmRpZmYgLS1naXQgYS9h
cmNoL2FybTY0L3hlbi94ZW5fcGNpLmMgYi9hcmNoL2FybTY0L3hlbi94ZW5fcGNpLmMKbmV3IGZp
bGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uNzdkNjY3MAotLS0gL2Rldi9udWxsCisrKyBi
L2FyY2gvYXJtNjQveGVuL3hlbl9wY2kuYwpAQCAtMCwwICsxLDk1IEBACisvKgorICogWGVuIFBD
SSAtIGhhbmRsZSBQQ0kgKElOVHgpIGFuZCBNU0kgaW5mcmFzdHJ1Y3R1cmUgY2FsbHMgZm9yIFBW
LCBIVk0gYW5kCisgKiBpbml0aWFsIGRvbWFpbiBzdXBwb3J0LiBXZSBhbHNvIGhhbmRsZSB0aGUg
RFNEVCBfUFJUIGNhbGxiYWNrcyBmb3IgR1NJJ3MKKyAqIHVzZWQgaW4gSFZNIGFuZCBpbml0aWFs
IGRvbWFpbiBtb2RlIChQViBkb2VzIG5vdCBwYXJzZSBBQ1BJLCBzbyBpdCBoYXMgbm8KKyAqIGNv
bmNlcHQgb2YgR1NJcykuIFVuZGVyIFBWIHdlIGhvb2sgdW5kZXIgdGhlIHBuYmJpb3MgQVBJIGZv
ciBJUlFzIGFuZAorICogMHhjZjggUENJIGNvbmZpZ3VyYXRpb24gcmVhZC93cml0ZS4KKyAqCisg
KiAgIEF1dGhvcjogUnlhbiBXaWxzb24gPGhhcDlAZXBvY2gubmNzYy5taWw+CisgKiAgICAgICAg
ICAgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgorICogICAg
ICAgICAgIFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJpeC5j
b20+CisgKi8KKyNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4KKyNpbmNsdWRlIDxsaW51eC9pbml0
Lmg+CisjaW5jbHVkZSA8bGludXgvcGNpLmg+CisKKyNpbmNsdWRlIDxsaW51eC9pby5oPgorCisj
aW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+CisKKyNpbmNsdWRlIDx4ZW4vZmVhdHVyZXMu
aD4KKyNpbmNsdWRlIDx4ZW4vZXZlbnRzLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9wY2kuaD4KK3N0
cnVjdCB4ZW5fZGV2aWNlX2RvbWFpbl9vd25lciB7CisJZG9taWRfdCBkb21haW47CisJc3RydWN0
IHBjaV9kZXYgKmRldjsKKwlzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7Cit9OworCisKK3N0YXRpYyBE
RUZJTkVfU1BJTkxPQ0soZGV2X2RvbWFpbl9saXN0X3NwaW5sb2NrKTsKK3N0YXRpYyBzdHJ1Y3Qg
bGlzdF9oZWFkIGRldl9kb21haW5fbGlzdCA9IExJU1RfSEVBRF9JTklUKGRldl9kb21haW5fbGlz
dCk7CisKK3N0YXRpYyBzdHJ1Y3QgeGVuX2RldmljZV9kb21haW5fb3duZXIgKmZpbmRfZGV2aWNl
KHN0cnVjdCBwY2lfZGV2ICpkZXYpCit7CisJc3RydWN0IHhlbl9kZXZpY2VfZG9tYWluX293bmVy
ICpvd25lcjsKKworCWxpc3RfZm9yX2VhY2hfZW50cnkob3duZXIsICZkZXZfZG9tYWluX2xpc3Qs
IGxpc3QpIHsKKwkJaWYgKG93bmVyLT5kZXYgPT0gZGV2KQorCQkJcmV0dXJuIG93bmVyOworCX0K
KwlyZXR1cm4gTlVMTDsKK30KKworaW50IHhlbl9maW5kX2RldmljZV9kb21haW5fb3duZXIoc3Ry
dWN0IHBjaV9kZXYgKmRldikKK3sKKwlzdHJ1Y3QgeGVuX2RldmljZV9kb21haW5fb3duZXIgKm93
bmVyOworCWludCBkb21haW4gPSAtRU5PREVWOworCisJc3Bpbl9sb2NrKCZkZXZfZG9tYWluX2xp
c3Rfc3BpbmxvY2spOworCW93bmVyID0gZmluZF9kZXZpY2UoZGV2KTsKKwlpZiAob3duZXIpCisJ
CWRvbWFpbiA9IG93bmVyLT5kb21haW47CisJc3Bpbl91bmxvY2soJmRldl9kb21haW5fbGlzdF9z
cGlubG9jayk7CisJcmV0dXJuIGRvbWFpbjsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHhlbl9maW5k
X2RldmljZV9kb21haW5fb3duZXIpOworCitpbnQgeGVuX3JlZ2lzdGVyX2RldmljZV9kb21haW5f
b3duZXIoc3RydWN0IHBjaV9kZXYgKmRldiwgdWludDE2X3QgZG9tYWluKQoreworCXN0cnVjdCB4
ZW5fZGV2aWNlX2RvbWFpbl9vd25lciAqb3duZXI7CisKKwlvd25lciA9IGt6YWxsb2Moc2l6ZW9m
KHN0cnVjdCB4ZW5fZGV2aWNlX2RvbWFpbl9vd25lciksIEdGUF9LRVJORUwpOworCWlmICghb3du
ZXIpCisJCXJldHVybiAtRU5PREVWOworCisJc3Bpbl9sb2NrKCZkZXZfZG9tYWluX2xpc3Rfc3Bp
bmxvY2spOworCWlmIChmaW5kX2RldmljZShkZXYpKSB7CisJCXNwaW5fdW5sb2NrKCZkZXZfZG9t
YWluX2xpc3Rfc3BpbmxvY2spOworCQlrZnJlZShvd25lcik7CisJCXJldHVybiAtRUVYSVNUOwor
CX0KKwlvd25lci0+ZG9tYWluID0gZG9tYWluOworCW93bmVyLT5kZXYgPSBkZXY7CisJbGlzdF9h
ZGRfdGFpbCgmb3duZXItPmxpc3QsICZkZXZfZG9tYWluX2xpc3QpOworCXNwaW5fdW5sb2NrKCZk
ZXZfZG9tYWluX2xpc3Rfc3BpbmxvY2spOworCXJldHVybiAwOworfQorRVhQT1JUX1NZTUJPTF9H
UEwoeGVuX3JlZ2lzdGVyX2RldmljZV9kb21haW5fb3duZXIpOworCitpbnQgeGVuX3VucmVnaXN0
ZXJfZGV2aWNlX2RvbWFpbl9vd25lcihzdHJ1Y3QgcGNpX2RldiAqZGV2KQoreworCXN0cnVjdCB4
ZW5fZGV2aWNlX2RvbWFpbl9vd25lciAqb3duZXI7CisKKwlzcGluX2xvY2soJmRldl9kb21haW5f
bGlzdF9zcGlubG9jayk7CisJb3duZXIgPSBmaW5kX2RldmljZShkZXYpOworCWlmICghb3duZXIp
IHsKKwkJc3Bpbl91bmxvY2soJmRldl9kb21haW5fbGlzdF9zcGlubG9jayk7CisJCXJldHVybiAt
RU5PREVWOworCX0KKwlsaXN0X2RlbCgmb3duZXItPmxpc3QpOworCXNwaW5fdW5sb2NrKCZkZXZf
ZG9tYWluX2xpc3Rfc3BpbmxvY2spOworCWtmcmVlKG93bmVyKTsKKwlyZXR1cm4gMDsKK30KK0VY
UE9SVF9TWU1CT0xfR1BMKHhlbl91bnJlZ2lzdGVyX2RldmljZV9kb21haW5fb3duZXIpOwpkaWZm
IC0tZ2l0IGEvZHJpdmVycy9wY2kveGVuLXBjaWZyb250LmMgYi9kcml2ZXJzL3BjaS94ZW4tcGNp
ZnJvbnQuYwppbmRleCAxMTZjYTM3Li5lMzBjYTdiIDEwMDY0NAotLS0gYS9kcml2ZXJzL3BjaS94
ZW4tcGNpZnJvbnQuYworKysgYi9kcml2ZXJzL3BjaS94ZW4tcGNpZnJvbnQuYwpAQCAtMTAsNiAr
MTAsMTEgQEAKICNpbmNsdWRlIDx4ZW4vZXZlbnRzLmg+CiAjaW5jbHVkZSA8eGVuL2dyYW50X3Rh
YmxlLmg+CiAjaW5jbHVkZSA8eGVuL3BhZ2UuaD4KKyNpbmNsdWRlIDxsaW51eC9vZl9pcnEuaD4K
KyNpbmNsdWRlIDxsaW51eC9vZl9wY2kuaD4KKyNpbmNsdWRlIDxsaW51eC9vZi5oPgorI2luY2x1
ZGUgPGxpbnV4L29mX2FkZHJlc3MuaD4KKyNpbmNsdWRlIDxsaW51eC9vZl9kZXZpY2UuaD4KICNp
bmNsdWRlIDxsaW51eC9zcGlubG9jay5oPgogI2luY2x1ZGUgPGxpbnV4L3BjaS5oPgogI2luY2x1
ZGUgPGxpbnV4L21zaS5oPgpAQCAtMjEsOCArMjYsOCBAQAogI2luY2x1ZGUgPGxpbnV4L2JpdG9w
cy5oPgogI2luY2x1ZGUgPGxpbnV4L3RpbWUuaD4KICNpbmNsdWRlIDx4ZW4vcGxhdGZvcm1fcGNp
Lmg+Ci0KICNpbmNsdWRlIDxhc20veGVuL3N3aW90bGIteGVuLmg+CisjaW5jbHVkZSA8bGludXgv
c3dpb3RsYi5oPgogI2RlZmluZSBJTlZBTElEX0dSQU5UX1JFRiAoMCkKICNkZWZpbmUgSU5WQUxJ
RF9FVlRDSE4gICAgKC0xKQogCkBAIC0yNDMsNyArMjQ4LDcgQEAgc3RhdGljIHN0cnVjdCBwY2lf
b3BzIHBjaWZyb250X2J1c19vcHMgPSB7CiAJLndyaXRlID0gcGNpZnJvbnRfYnVzX3dyaXRlLAog
fTsKIAotI2lmZGVmIENPTkZJR19QQ0lfTVNJCisjaWYgZGVmaW5lZChDT05GSUdfUENJX01TSSkg
JiYgZGVmaW5lZChDT05GSUdfWDg2KQogc3RhdGljIGludCBwY2lfZnJvbnRlbmRfZW5hYmxlX21z
aXgoc3RydWN0IHBjaV9kZXYgKmRldiwKIAkJCQkgICAgaW50IHZlY3RvcltdLCBpbnQgbnZlYykK
IHsKQEAgLTM4Nyw3ICszOTIsNyBAQCBzdGF0aWMgdm9pZCBwY2lfZnJvbnRlbmRfcmVnaXN0cmFy
KGludCBlbmFibGUpCiB9OwogI2Vsc2UKIHN0YXRpYyBpbmxpbmUgdm9pZCBwY2lfZnJvbnRlbmRf
cmVnaXN0cmFyKGludCBlbmFibGUpIHsgfTsKLSNlbmRpZiAvKiBDT05GSUdfUENJX01TSSAqLwor
I2VuZGlmIC8qIENPTkZJR19QQ0lfTVNJICYmIFg4NiovCiAKIC8qIENsYWltIHJlc291cmNlcyBm
b3IgdGhlIFBDSSBmcm9udGVuZCBhcy1pcywgYmFja2VuZCB3b24ndCBhbGxvdyBjaGFuZ2VzICov
CiBzdGF0aWMgaW50IHBjaWZyb250X2NsYWltX3Jlc291cmNlKHN0cnVjdCBwY2lfZGV2ICpkZXYs
IHZvaWQgKmRhdGEpCkBAIC00NDgsNiArNDUzLDcgQEAgc3RhdGljIGludCBwY2lmcm9udF9zY2Fu
X3Jvb3Qoc3RydWN0IHBjaWZyb250X2RldmljZSAqcGRldiwKIAlzdHJ1Y3QgcGNpX2J1cyAqYjsK
IAlzdHJ1Y3QgcGNpZnJvbnRfc2QgKnNkID0gTlVMTDsKIAlzdHJ1Y3QgcGNpX2J1c19lbnRyeSAq
YnVzX2VudHJ5ID0gTlVMTDsKK3N0cnVjdCBkZXZpY2Vfbm9kZSAqbXNpX25vZGU7CiAJaW50IGVy
ciA9IDA7CiAKICNpZm5kZWYgQ09ORklHX1BDSV9ET01BSU5TCkBAIC00ODUsNiArNDkxLDE3IEBA
IHN0YXRpYyBpbnQgcGNpZnJvbnRfc2Nhbl9yb290KHN0cnVjdCBwY2lmcm9udF9kZXZpY2UgKnBk
ZXYsCiAJfQogCiAJYnVzX2VudHJ5LT5idXMgPSBiOworICAgICAgICBtc2lfbm9kZSA9IG9mX2Zp
bmRfY29tcGF0aWJsZV9ub2RlKE5VTEwsTlVMTCwgImFybSxnaWMtdjMtaXRzIik7CisgICAgICAg
IGlmKG1zaV9ub2RlKSB7CisgICAgICAgICAgICBiLT5tc2kgPSBvZl9wY2lfZmluZF9tc2lfY2hp
cF9ieV9ub2RlKG1zaV9ub2RlKTsKKyAgICAgICAgICAgIGlmKCFiLT5tc2kpIHsKKyAgICAgICAg
ICAgICAgIHByaW50ayhLRVJOX0VSUiJVbmFibGUgdG8gZmluZCBidXMtPm1zaSBub2RlIFxyXG4i
KTsKKyAgICAgICAgICAgICAgIGdvdG8gZXJyX291dDsKKyAgICAgICAgICAgIH0KKyAgICAgICAg
fWVsc2UgeworICAgICAgICAgICAgICAgcHJpbnRrKEtFUk5fRVJSIlVuYWJsZSB0byBmaW5kIGFy
bSxnaWMtdjMtaXRzIGNvbXBhdGlibGUgbm9kZSBcclxuIik7CisgICAgICAgICAgICAgICBnb3Rv
IGVycl9vdXQ7CisgICAgICAgIH0KIAogCWxpc3RfYWRkKCZidXNfZW50cnktPmxpc3QsICZwZGV2
LT5yb290X2J1c2VzKTsKIApAQCAtMTE0NiwxMiArMTE2MywxNyBAQCBzdGF0aWMgc3RydWN0IHhl
bmJ1c19kcml2ZXIgeGVucGNpX2RyaXZlciA9IHsKIAogc3RhdGljIGludCBfX2luaXQgcGNpZnJv
bnRfaW5pdCh2b2lkKQogewotCWlmICgheGVuX3B2X2RvbWFpbigpIHx8IHhlbl9pbml0aWFsX2Rv
bWFpbigpKQorCWlmKAorI2lmZGVmIFg4NgorCSF4ZW5fcHZfZG9tYWluKCkgfHwKKyNlbmRpZgor
CXhlbl9pbml0aWFsX2RvbWFpbigpKQogCQlyZXR1cm4gLUVOT0RFVjsKIAorI2lmZGVmIFg4Ngog
CWlmICgheGVuX2hhc19wdl9kZXZpY2VzKCkpCiAJCXJldHVybiAtRU5PREVWOwotCisjZW5kaWYK
IAlwY2lfZnJvbnRlbmRfcmVnaXN0cmFyKDEgLyogZW5hYmxlICovKTsKIAogCXJldHVybiB4ZW5i
dXNfcmVnaXN0ZXJfZnJvbnRlbmQoJnhlbnBjaV9kcml2ZXIpOwpkaWZmIC0tZ2l0IGEvZHJpdmVy
cy94ZW4vcGNpLmMgYi9kcml2ZXJzL3hlbi9wY2kuYwppbmRleCBkZDljMjQ5Li5hNTYwZjQyIDEw
MDY0NAotLS0gYS9kcml2ZXJzL3hlbi9wY2kuYworKysgYi9kcml2ZXJzL3hlbi9wY2kuYwpAQCAt
MjIsNiArMjIsNyBAQAogI2luY2x1ZGUgPHhlbi94ZW4uaD4KICNpbmNsdWRlIDx4ZW4vaW50ZXJm
YWNlL3BoeXNkZXYuaD4KICNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3hlbi5oPgorI2luY2x1ZGUg
PHhlbi9odmMtY29uc29sZS5oPgogCiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+CiAj
aW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KQEAgLTEzMCw3ICsxMzEsNyBAQCBzdGF0aWMg
aW50IHhlbl9hZGRfZGV2aWNlKHN0cnVjdCBkZXZpY2UgKmRldikKIAlyZXR1cm4gcjsKIH0KIAot
c3RhdGljIGludCB4ZW5fcmVtb3ZlX2RldmljZShzdHJ1Y3QgZGV2aWNlICpkZXYpCitpbnQgeGVu
X3JlbW92ZV9kZXZpY2Uoc3RydWN0IGRldmljZSAqZGV2KQogewogCWludCByOwogCXN0cnVjdCBw
Y2lfZGV2ICpwY2lfZGV2ID0gdG9fcGNpX2RldihkZXYpOwpAQCAtMTU4LDYgKzE1OSw2NCBAQCBz
dGF0aWMgaW50IHhlbl9yZW1vdmVfZGV2aWNlKHN0cnVjdCBkZXZpY2UgKmRldikKIAogCXJldHVy
biByOwogfQorc3RhdGljIGludCB4ZW5fbWFwX3BjaV9iYXJzKHN0cnVjdCBkZXZpY2UgKmRldikK
K3sKKwlpbnQgaSxyPTA7CisJc3RydWN0IHBjaV9kZXYgKnBjaV9kZXYgPSB0b19wY2lfZGV2KGRl
dik7CisJZm9yKGk9MDsgaTw2OyBpKyspIHsKKwkJc3RydWN0IHBoeXNkZXZfbWFwX21taW8gbWFw
bTsKKwkJbWFwbS5hZGRyID0gcGNpX3Jlc291cmNlX3N0YXJ0KHBjaV9kZXYsaSk7CisJCW1hcG0u
c2l6ZSA9IHBjaV9yZXNvdXJjZV9sZW4ocGNpX2RldixpKTsKKwkJeGVuX3Jhd19wcmludGsoIiVz
IEFERFI9JWx4IFNJWkU9JWx4XHJcbiIsX19mdW5jX18sIG1hcG0uYWRkciwgbWFwbS5zaXplKTsK
KwkJaWYobWFwbS5hZGRyICYmIG1hcG0uc2l6ZSkgeworCQkJciA9IEhZUEVSVklTT1JfcGh5c2Rl
dl9vcChQSFlTREVWT1BfbWFwX21taW8sICZtYXBtKTsKKwkJCWlmIChyKQorCQkJCXByaW50ayhL
RVJOX0VSUiAiJXMgWGVuIEVycm9yIFVuYWJsZSB0byBtYXAgQUREUj0lbHggU0laRT0lbHhcclxu
IixfX2Z1bmNfXywgbWFwbS5hZGRyLCBtYXBtLnNpemUpOworCQl9CisJfQorCXJldHVybiByOwor
Cit9CitzdGF0aWMgaW50IHhlbl91bm1hcF9wY2lfYmFycyhzdHJ1Y3QgZGV2aWNlICpkZXYpCit7
CisJaW50IGkscj0wOworCXN0cnVjdCBwY2lfZGV2ICpwY2lfZGV2ID0gdG9fcGNpX2RldihkZXYp
OworCWZvcihpPTA7IGk8NjsgaSsrKSB7CisJCXN0cnVjdCBwaHlzZGV2X21hcF9tbWlvIG1hcG07
CisJCW1hcG0uYWRkciA9IHBjaV9yZXNvdXJjZV9zdGFydChwY2lfZGV2LGkpOworCQltYXBtLnNp
emUgPSBwY2lfcmVzb3VyY2VfbGVuKHBjaV9kZXYsaSk7CisJCXhlbl9yYXdfcHJpbnRrKCIlcyBB
RERSPSVseCBTSVpFPSVseFxyXG4iLF9fZnVuY19fLCBtYXBtLmFkZHIsIG1hcG0uc2l6ZSk7CisJ
CWlmKG1hcG0uYWRkciAmJiBtYXBtLnNpemUpIHsKKwkJCXIgPSBIWVBFUlZJU09SX3BoeXNkZXZf
b3AoUEhZU0RFVk9QX3VubWFwX21taW8sICZtYXBtKTsKKwkJCWlmIChyKQorCQkJCXByaW50ayhL
RVJOX0VSUiAiJXMgWGVuIEVycm9yIFVuYWJsZSB0byB1bm1hcCBBRERSPSVseCBTSVpFPSVseFxy
XG4iLF9fZnVuY19fLCBtYXBtLmFkZHIsIG1hcG0uc2l6ZSk7CisJCX0KKwl9CisJcmV0dXJuIHI7
CisKK30KK2ludCB4ZW5fYWRkX3BjaV9kZXZpY2Uoc3RydWN0IGRldmljZSAqZGV2KQoreworCWlu
dCByID0gMDsKKwlpZiAoeGVuX2luaXRpYWxfZG9tYWluKCkpCisJICAgIHIgPSB4ZW5fYWRkX2Rl
dmljZShkZXYpOworCWlmKCFyKSB7CisJCXIgPSB4ZW5fbWFwX3BjaV9iYXJzKGRldik7CisJfQor
CXJldHVybiByOworfQorCitpbnQgeGVuX3JlbW92ZV9wY2lfZGV2aWNlKHN0cnVjdCBkZXZpY2Ug
KmRldikKK3sKKwlpbnQgciA9IDA7CisJcHJpbnRrKEtFUk5fRVJSIj4+JXMgXHJcbiIsX19mdW5j
X18pOworCXIgPSB4ZW5fcmVtb3ZlX2RldmljZShkZXYpOworCWlmKCFyKSB7CisJCXIgPSB4ZW5f
dW5tYXBfcGNpX2JhcnMoZGV2KTsKKwl9CisJcHJpbnRrKEtFUk5fRVJSIjw8JXMgJXNcclxuIiwg
X19mdW5jX18sIF9fTElORV9fKTsKKwlyZXR1cm4gcjsKK30KIAogc3RhdGljIGludCB4ZW5fcGNp
X25vdGlmaWVyKHN0cnVjdCBub3RpZmllcl9ibG9jayAqbmIsCiAJCQkgICAgdW5zaWduZWQgbG9u
ZyBhY3Rpb24sIHZvaWQgKmRhdGEpCkBAIC0xNjcsMTAgKzIyNiwxMCBAQCBzdGF0aWMgaW50IHhl
bl9wY2lfbm90aWZpZXIoc3RydWN0IG5vdGlmaWVyX2Jsb2NrICpuYiwKIAogCXN3aXRjaCAoYWN0
aW9uKSB7CiAJY2FzZSBCVVNfTk9USUZZX0FERF9ERVZJQ0U6Ci0JCXIgPSB4ZW5fYWRkX2Rldmlj
ZShkZXYpOworCQlyID0geGVuX2FkZF9wY2lfZGV2aWNlKGRldik7CiAJCWJyZWFrOwogCWNhc2Ug
QlVTX05PVElGWV9ERUxfREVWSUNFOgotCQlyID0geGVuX3JlbW92ZV9kZXZpY2UoZGV2KTsKKwkJ
ciA9IHhlbl9yZW1vdmVfcGNpX2RldmljZShkZXYpOwogCQlicmVhazsKIAlkZWZhdWx0OgogCQly
ZXR1cm4gTk9USUZZX0RPTkU7CkBAIC0xODgsOCArMjQ3LDEwIEBAIHN0YXRpYyBzdHJ1Y3Qgbm90
aWZpZXJfYmxvY2sgZGV2aWNlX25iID0gewogCiBzdGF0aWMgaW50IF9faW5pdCByZWdpc3Rlcl94
ZW5fcGNpX25vdGlmaWVyKHZvaWQpCiB7CisjaWZkZWYgWDg2CiAJaWYgKCF4ZW5faW5pdGlhbF9k
b21haW4oKSkKIAkJcmV0dXJuIDA7CisjZW5kaWYKIAogCXJldHVybiBidXNfcmVnaXN0ZXJfbm90
aWZpZXIoJnBjaV9idXNfdHlwZSwgJmRldmljZV9uYik7CiB9CmRpZmYgLS1naXQgYS9kcml2ZXJz
L3hlbi94ZW4tcGNpYmFjay9wY2lfc3R1Yi5jIGIvZHJpdmVycy94ZW4veGVuLXBjaWJhY2svcGNp
X3N0dWIuYwppbmRleCAwMTcwNjlhLi5lODQzNTA2IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94
ZW4tcGNpYmFjay9wY2lfc3R1Yi5jCisrKyBiL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaV9z
dHViLmMKQEAgLTM4Miw3ICszODIsNyBAQCBzdGF0aWMgaW50IHBjaXN0dWJfaW5pdF9kZXZpY2Uo
c3RydWN0IHBjaV9kZXYgKmRldikKIAllcnIgPSBwY2lfZW5hYmxlX2RldmljZShkZXYpOwogCWlm
IChlcnIpCiAJCWdvdG8gY29uZmlnX3JlbGVhc2U7Ci0KKyNpZmRlZiBDT05GSUdfWDg2CiAJaWYg
KGRldi0+bXNpeF9jYXApIHsKIAkJc3RydWN0IHBoeXNkZXZfcGNpX2RldmljZSBwcGRldiA9IHsK
IAkJCS5zZWcgPSBwY2lfZG9tYWluX25yKGRldi0+YnVzKSwKQEAgLTM5NSw3ICszOTUsNyBAQCBz
dGF0aWMgaW50IHBjaXN0dWJfaW5pdF9kZXZpY2Uoc3RydWN0IHBjaV9kZXYgKmRldikKIAkJCWRl
dl9lcnIoJmRldi0+ZGV2LCAiTVNJLVggcHJlcGFyYXRpb24gZmFpbGVkICglZClcbiIsCiAJCQkJ
ZXJyKTsKIAl9Ci0KKyNlbmRpZgogCS8qIFdlIG5lZWQgdGhlIGRldmljZSBhY3RpdmUgdG8gc2F2
ZSB0aGUgc3RhdGUuICovCiAJZGV2X2RiZygmZGV2LT5kZXYsICJzYXZlIHN0YXRlIG9mIGRldmlj
ZVxuIik7CiAJcGNpX3NhdmVfc3RhdGUoZGV2KTsKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL3hl
bi1wY2liYWNrL3BjaWJhY2suaCBiL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaWJhY2suaApp
bmRleCBmNzJhZjg3Li41MmVmMDMxIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94ZW4tcGNpYmFj
ay9wY2liYWNrLmgKKysrIGIvZHJpdmVycy94ZW4veGVuLXBjaWJhY2svcGNpYmFjay5oCkBAIC0z
Nyw2ICszNywxMCBAQCBzdHJ1Y3QgeGVuX3BjaWJrX2RldmljZSB7CiAJc3RydWN0IHhlbl9wY2lf
c2hhcmVkaW5mbyAqc2hfaW5mbzsKIAl1bnNpZ25lZCBsb25nIGZsYWdzOwogCXN0cnVjdCB3b3Jr
X3N0cnVjdCBvcF93b3JrOworCWludCBwY2lfZG9tYWluOworCWludCBidXM7CisJaW50IHNsb3Q7
CisJaW50IGZ1bmM7CiB9OwogCiBzdHJ1Y3QgeGVuX3BjaWJrX2Rldl9kYXRhIHsKZGlmZiAtLWdp
dCBhL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaWJhY2tfb3BzLmMgYi9kcml2ZXJzL3hlbi94
ZW4tcGNpYmFjay9wY2liYWNrX29wcy5jCmluZGV4IGM0YTA2NjYuLjhhNTcwMWQgMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaWJhY2tfb3BzLmMKKysrIGIvZHJpdmVycy94
ZW4veGVuLXBjaWJhY2svcGNpYmFja19vcHMuYwpAQCAtNzAsNiArNzAsNyBAQCBzdGF0aWMgdm9p
ZCB4ZW5fcGNpYmtfY29udHJvbF9pc3Ioc3RydWN0IHBjaV9kZXYgKmRldiwgaW50IHJlc2V0KQog
CQllbmFibGUgPyAiZW5hYmxlIiA6ICJkaXNhYmxlIik7CiAKIAlpZiAoZW5hYmxlKSB7CisjaWZk
ZWYgQ09ORklHX1g4NgogCQlyYyA9IHJlcXVlc3RfaXJxKGRldl9kYXRhLT5pcnEsCiAJCQkJeGVu
X3BjaWJrX2d1ZXN0X2ludGVycnVwdCwgSVJRRl9TSEFSRUQsCiAJCQkJZGV2X2RhdGEtPmlycV9u
YW1lLCBkZXYpOwpAQCAtNzksNiArODAsNyBAQCBzdGF0aWMgdm9pZCB4ZW5fcGNpYmtfY29udHJv
bF9pc3Ioc3RydWN0IHBjaV9kZXYgKmRldiwgaW50IHJlc2V0KQogCQkJCWRldl9kYXRhLT5pcnFf
bmFtZSwgZGV2X2RhdGEtPmlycSwgcmMpOwogCQkJZ290byBvdXQ7CiAJCX0KKyNlbmRpZgogCX0g
ZWxzZSB7CiAJCWZyZWVfaXJxKGRldl9kYXRhLT5pcnEsIGRldik7CiAJCWRldl9kYXRhLT5pcnEg
PSAwOwpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4veGVuLXBjaWJhY2svdnBjaS5jIGIvZHJpdmVy
cy94ZW4veGVuLXBjaWJhY2svdnBjaS5jCmluZGV4IDUxYWZmZjkuLmIwNzMzMjcgMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3ZwY2kuYworKysgYi9kcml2ZXJzL3hlbi94ZW4t
cGNpYmFjay92cGNpLmMKQEAgLTExLDYgKzExLDEwIEBACiAjaW5jbHVkZSA8bGludXgvc2xhYi5o
PgogI2luY2x1ZGUgPGxpbnV4L3BjaS5oPgogI2luY2x1ZGUgPGxpbnV4L211dGV4Lmg+CisjaW5j
bHVkZSA8eGVuL3hlbi5oPgorI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvcGh5c2Rldi5oPgorI2lu
Y2x1ZGUgPGFzbS94ZW4vaHlwZXJ2aXNvci5oPgorI2luY2x1ZGUgPGFzbS94ZW4vaHlwZXJjYWxs
Lmg+CiAjaW5jbHVkZSAicGNpYmFjay5oIgogCiAjZGVmaW5lIFBDSV9TTE9UX01BWCAzMgpAQCAt
NzEsNiArNzUsOSBAQCBzdGF0aWMgaW50IF9feGVuX3BjaWJrX2FkZF9wY2lfZGV2KHN0cnVjdCB4
ZW5fcGNpYmtfZGV2aWNlICpwZGV2LAogCWludCBlcnIgPSAwLCBzbG90LCBmdW5jID0gLTE7CiAJ
c3RydWN0IHBjaV9kZXZfZW50cnkgKnQsICpkZXZfZW50cnk7CiAJc3RydWN0IHZwY2lfZGV2X2Rh
dGEgKnZwY2lfZGV2ID0gcGRldi0+cGNpX2Rldl9kYXRhOworCXN0cnVjdCBwaHlzZGV2X21hcF9z
YmRmIG1hcF9zYmRmOzsKKworcHJpbnRrKCIlcyAlZFxyXG4iLCBfX2Z1bmNfXywgX19MSU5FX18p
OwogCiAJaWYgKChkZXYtPmNsYXNzID4+IDI0KSA9PSBQQ0lfQkFTRV9DTEFTU19CUklER0UpIHsK
IAkJZXJyID0gLUVGQVVMVDsKQEAgLTExOCwxMSArMTI1LDExIEBAIHN0YXRpYyBpbnQgX194ZW5f
cGNpYmtfYWRkX3BjaV9kZXYoc3RydWN0IHhlbl9wY2lia19kZXZpY2UgKnBkZXYsCiAJLyogQXNz
aWduIHRvIGEgbmV3IHNsb3Qgb24gdGhlIHZpcnR1YWwgUENJIGJ1cyAqLwogCWZvciAoc2xvdCA9
IDA7IHNsb3QgPCBQQ0lfU0xPVF9NQVg7IHNsb3QrKykgewogCQlpZiAobGlzdF9lbXB0eSgmdnBj
aV9kZXYtPmRldl9saXN0W3Nsb3RdKSkgewotCQkJcHJfaW5mbygidnBjaTogJXM6IGFzc2lnbiB0
byB2aXJ0dWFsIHNsb3QgJWRcbiIsCi0JCQkJcGNpX25hbWUoZGV2KSwgc2xvdCk7CiAJCQlsaXN0
X2FkZF90YWlsKCZkZXZfZW50cnktPmxpc3QsCiAJCQkJICAgICAgJnZwY2lfZGV2LT5kZXZfbGlz
dFtzbG90XSk7CiAJCQlmdW5jID0gZGV2LT5pc192aXJ0Zm4gPyAwIDogUENJX0ZVTkMoZGV2LT5k
ZXZmbik7CisJCQlwcl9pbmZvKCJ2cGNpOiAlczogYXNzaWduIHRvIHZpcnR1YWwgc2xvdCAlZCBm
dW5jdGlvbiAlZFxuIiwKKwkJCQlwY2lfbmFtZShkZXYpLCBzbG90LCBmdW5jKTsKIAkJCWdvdG8g
dW5sb2NrOwogCQl9CiAJfQpAQCAtMTQwLDYgKzE0NywzMSBAQCB1bmxvY2s6CiAJZWxzZQogCQlr
ZnJlZShkZXZfZW50cnkpOwogCisJLypJc3N1ZSBIeXBlcmNhbGwgaGVyZSAqLworCisJbWFwX3Ni
ZGYuZG9tYWluX2lkID0gcGRldi0+eGRldi0+b3RoZXJlbmRfaWQ7CisJbWFwX3NiZGYuc2JkZl9z
ID0gZGV2LT5idXMtPmRvbWFpbl9ucjsKKwltYXBfc2JkZi5zYmRmX2IgPSBkZXYtPmJ1cy0+bnVt
YmVyOworCW1hcF9zYmRmLnNiZGZfZCA9IGRldi0+ZGV2Zm4+PjM7CisJbWFwX3NiZGYuc2JkZl9m
ID0gZGV2LT5kZXZmbiAmIDB4NzsKKwltYXBfc2JkZi5nc2JkZl9zID0gMDsKKwltYXBfc2JkZi5n
c2JkZl9iID0gMDsKKwltYXBfc2JkZi5nc2JkZl9kID0gc2xvdDsKKwltYXBfc2JkZi5nc2JkZl9m
ID0gZGV2LT5kZXZmbiAmIDB4NzsKKwlwcmludGsoS0VSTl9FUlIiIyMgc2JkZiA9ICVkOiVkOiVk
LiVkIGdfc2JkZiAlZDolZDolZC4lZCBkb21haW5faWQ9JWQgIyNcclxuIiwKKwltYXBfc2JkZi5z
YmRmX3MsCisJbWFwX3NiZGYuc2JkZl9iLAorCW1hcF9zYmRmLnNiZGZfZCwKKwltYXBfc2JkZi5z
YmRmX2YsCisJbWFwX3NiZGYuZ3NiZGZfcywKKwltYXBfc2JkZi5nc2JkZl9iLAorCW1hcF9zYmRm
LmdzYmRmX2QsCisJbWFwX3NiZGYuZ3NiZGZfZiwKKwltYXBfc2JkZi5kb21haW5faWQpOworCQor
CWVyciA9IEhZUEVSVklTT1JfcGh5c2Rldl9vcChQSFlTREVWT1BfbWFwX3NiZGYsICZtYXBfc2Jk
Zik7CisJaWYgKGVycikKKwkJcHJpbnRrKEtFUk5fRVJSICIgWGVuIEVycm9yIFBIWVNERVZPUF9t
YXBfc2JkZiIpOwogb3V0OgogCXJldHVybiBlcnI7CiB9CkBAIC0yNDMsNiArMjc1LDcgQEAgc3Rh
dGljIGludCBfX3hlbl9wY2lia19nZXRfcGNpZnJvbnRfZGV2KHN0cnVjdCBwY2lfZGV2ICpwY2lk
ZXYsCiAJCQkJKmJ1cyA9IDA7CiAJCQkJKmRldmZuID0gUENJX0RFVkZOKHNsb3QsCiAJCQkJCSBQ
Q0lfRlVOQyhwY2lkZXYtPmRldmZuKSk7CisJCQkJcHJpbnRrKEtFUk5fRVJSIiVzICVkOiVkOiVk
LiVkIFxyXG4iLCBfX2Z1bmNfXywgKmRvbWFpbiwgKmJ1cywgKCpkZXZmbik+PjMgLCAoKmRldmZu
KSYgMHg3KTsKIAkJCX0KIAkJfQogCX0KZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFj
ZS9waHlzZGV2LmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGh5c2Rldi5oCmluZGV4IDYxMGRi
YTkuLmYxMmFhNmIgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9waHlzZGV2LmgK
KysrIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BoeXNkZXYuaApAQCAtMjk2LDYgKzI5NiwyNyBA
QCBzdHJ1Y3QgcGh5c2Rldl9kYmdwX29wIHsKICAgICAgICAgc3RydWN0IHBoeXNkZXZfcGNpX2Rl
dmljZSBwY2k7CiAgICAgfSB1OwogfTsKKyNkZWZpbmUgUEhZU0RFVk9QX21hcF9tbWlvCQk0MAor
c3RydWN0IHBoeXNkZXZfbWFwX21taW8geworICAgIC8qIElOICovCisgICAgdWludDY0X3QgYWRk
cjsKKyAgICB1aW50NjRfdCBzaXplOwkKK307CisjZGVmaW5lIFBIWVNERVZPUF91bm1hcF9tbWlv
CQk0MQorCisjZGVmaW5lIFBIWVNERVZPUF9tYXBfc2JkZgkJNDMKK3N0cnVjdCBwaHlzZGV2X21h
cF9zYmRmIHsKKwlpbnQgZG9tYWluX2lkOworCWludCBzYmRmX3M7CisJaW50IHNiZGZfYjsKKwlp
bnQgc2JkZl9kOworCWludCBzYmRmX2Y7CisKKwlpbnQgZ3NiZGZfczsKKwlpbnQgZ3NiZGZfYjsK
KwlpbnQgZ3NiZGZfZDsKKwlpbnQgZ3NiZGZfZjsKK307CiAKIC8qCiAgKiBOb3RpZnkgdGhhdCBz
b21lIFBJUlEtYm91bmQgZXZlbnQgY2hhbm5lbHMgaGF2ZSBiZWVuIHVubWFza2VkLgotLSAKMS45
LjEKCg==
--089e0158b1568d74910507325860
Content-Type: application/octet-stream; 
	name="0002-SMMU-fix-sbdf-patch.patch"
Content-Disposition: attachment; filename="0002-SMMU-fix-sbdf-patch.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i269ooas2

RnJvbSA4NmI1ZGQ1MjU0ZmY5ZWVkOTk2ZDkzMzI2ODJjMDgwMDM1OTEwMTAzIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBtYW5pc2ggPG1hbmlzaC5qYWdnaUBjYXZpdW1uZXR3b3Jrcy5j
b20+CkRhdGU6IFdlZCwgNSBOb3YgMjAxNCAyMDoxMDo0MCArMDUzMApTdWJqZWN0OiBbUEFUQ0gg
Mi8yXSBTTU1VIGZpeCArIHNiZGYgcGF0Y2gKCi0tLQogdG9vbHMvbGlieGwvbGlieGxfcGNpLmMg
ICAgICAgICAgICB8ICA0ICsrKy0KIHhlbi9hcmNoL2FybS9waHlzZGV2LmMgICAgICAgICAgICAg
fCAzNCArKysrKysrKysrKysrKysrKysrKysrKysrLQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gv
YXJtL3NtbXUuYyB8ICAyICsrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2dpYy1pdHMuaCAgICAgIHwg
NDkgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0KIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vcGNpLmggICAgICAgICAgfCAgNCArKysrCiB4ZW4vaW5jbHVkZS9wdWJsaWMvcGh5c2Rl
di5oICAgICAgIHwgMTggKysrKysrKysrKysrKysKIDggZmlsZXMgY2hhbmdlZCwgMTI0IGluc2Vy
dGlvbnMoKyksIDI1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhs
X3BjaS5jIGIvdG9vbHMvbGlieGwvbGlieGxfcGNpLmMKaW5kZXggOWY0MDEwMC4uNjU3MWM2YSAx
MDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfcGNpLmMKKysrIGIvdG9vbHMvbGlieGwvbGli
eGxfcGNpLmMKQEAgLTk2OCwxMCArOTY4LDExIEBAIHN0YXRpYyBpbnQgZG9fcGNpX2FkZChsaWJ4
bF9fZ2MgKmdjLCB1aW50MzJfdCBkb21pZCwgbGlieGxfZGV2aWNlX3BjaSAqcGNpZGV2LCBpCiAg
ICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAiQ291bGRuJ3Qg
b3BlbiAlcyIsIHN5c2ZzX3BhdGgpOwogICAgICAgICBnb3RvIG91dDsKICAgICB9CisjaWZkZWYg
Q09ORklHX1g4NgogICAgIGlmICgoZnNjYW5mKGYsICIldSIsICZpcnEpID09IDEpICYmIGlycSkg
ewogICAgICAgICByYyA9IHhjX3BoeXNkZXZfbWFwX3BpcnEoY3R4LT54Y2gsIGRvbWlkLCBpcnEs
ICZpcnEpOwogICAgICAgICBpZiAocmMgPCAwKSB7CiAgICAgICAgICAgICBmY2xvc2UoZik7CiAg
ICAgICAgICAgICByZXR1cm4gRVJST1JfRkFJTDsKICAgICAgICAgfQpAQCAtOTgyLDYgKzk4Myw3
IEBAIHN0YXRpYyBpbnQgZG9fcGNpX2FkZChsaWJ4bF9fZ2MgKmdjLCB1aW50MzJfdCBkb21pZCwg
bGlieGxfZGV2aWNlX3BjaSAqcGNpZGV2LCBpCiAgICAgICAgICAgICByZXR1cm4gRVJST1JfRkFJ
TDsKICAgICAgICAgfQogICAgIH0KKyNlbmRpZgogICAgIGZjbG9zZShmKTsKIAogICAgIC8qIERv
bid0IHJlc3RyaWN0IHdyaXRlcyB0byB0aGUgUENJIGNvbmZpZyBzcGFjZSBmcm9tIHRoaXMgVk0g
Ki8KIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3BoeXNkZXYuYyBiL3hlbi9hcmNoL2FybS9w
aHlzZGV2LmMKaW5kZXggNzc2MjgwNi4uOGM2ODQ4NyAxMDA2NDQKLS0tIGEveGVuL2FyY2gvYXJt
L3BoeXNkZXYuYworKysgYi94ZW4vYXJjaC9hcm0vcGh5c2Rldi5jCkBAIC0zOCwxMSArMzgsNDMg
QEAKIGludCBkb19waHlzZGV2X29wKGludCBjbWQsIFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0odm9p
ZCkgYXJnKQogewogICAvLyAgaW50IGlycTsKLSAgICBpbnQgcmV0PTA7CisgICAgaW50IHJldD0t
MTsKICAgICBzdHJ1Y3QgdmNwdSAqdiA9IGN1cnJlbnQ7CiAJcHJpbnRrKCIlcyBjbWQ9JWRcclxu
IiwgX19mdW5jX18gLCBjbWQpOwogICAgIHN3aXRjaCAoIGNtZCApCiAgICAgeworICAgIGNhc2Ug
UEhZU0RFVk9QX21hcF9zYmRmOnsKKyAgICAgICAgc3RydWN0IHBoeXNkZXZfbWFwX3NiZGYgbWFw
X3NiZGY7CisgICAgICAgIHN0cnVjdCBkb21haW4gKmQ7CisgICAgICAgIHN0cnVjdCBwY2lfZGV2
ICpwZGV2OworCisgICAgICAgIGlmICggY29weV9mcm9tX2d1ZXN0KCZtYXBfc2JkZiwgYXJnLCAx
KSAhPSAwICkKKyAgICAgICAgICAgIGJyZWFrOworCisgICAgICAgIGZvcl9lYWNoX2RvbWFpbihk
KXsKKyAgICAgICAgCXByaW50aygiQCNAICVkICVkXHJcbiIsZC0+ZG9tYWluX2lkICwgbWFwX3Ni
ZGYuZG9tYWluX2lkKTsKKyAgICAgICAgCWlmKGQtPmRvbWFpbl9pZCA9PSBtYXBfc2JkZi5kb21h
aW5faWQpeworICAgICAgICAJCWZvcl9lYWNoX3BkZXYoZCxwZGV2KXsKKyAgICAgICAgCQkJcHJp
bnRrKCJAQCAlZDolZDolZDolZCwgJWQ6JWQ6JWQ6JWQgXHJcbiIsCisgICAgICAgIAkJCQkJcGRl
di0+c2VnLHBkZXYtPmJ1cyxwZGV2LT5kZXZmbj4+MyxwZGV2LT5kZXZmbiAmIDB4NywKKyAgICAg
ICAgCQkJCQltYXBfc2JkZi5zYmRmX3MsbWFwX3NiZGYuc2JkZl9iLG1hcF9zYmRmLnNiZGZfZCxt
YXBfc2JkZi5zYmRmX2YpOworCisgICAgICAgIAkJCWlmKHBkZXYtPnNlZyA9PSBtYXBfc2JkZi5z
YmRmX3MgJiYKKyAgICAgICAgCQkJcGRldi0+YnVzID09IG1hcF9zYmRmLnNiZGZfYiAmJgorICAg
ICAgICAJCQkocGRldi0+ZGV2Zm4gPj4gMykgPT0gbWFwX3NiZGYuc2JkZl9kICYmCisgICAgICAg
IAkJCShwZGV2LT5kZXZmbiAmIDB4NykgPT0gbWFwX3NiZGYuc2JkZl9mKXsKKyAgICAgICAgCQkJ
CQlwZGV2LT5hcmNoLmdzYmRmX3MgPSBtYXBfc2JkZi5nc2JkZl9zOworICAgICAgICAJCQkJCXBk
ZXYtPmFyY2guZ3NiZGZfYiA9IG1hcF9zYmRmLmdzYmRmX2I7CisgICAgICAgIAkJCQkJcGRldi0+
YXJjaC5nc2JkZl9kID0gbWFwX3NiZGYuZ3NiZGZfZDsKKyAgICAgICAgCQkJCQlwZGV2LT5hcmNo
LmdzYmRmX2YgPSBtYXBfc2JkZi5nc2JkZl9mOworCQkJCQkJcmV0dXJuIDA7CisgICAgICAgIAkJ
CX0KKyAgICAgICAgCQl9CisgICAgICAgIAl9CisgICAgICAgIH0KKyAgICBicmVhazsKKyAgICB9
CisKICAgICBjYXNlIFBIWVNERVZPUF9tYXBfbW1pbzogewogCXN0cnVjdCBwaHlzZGV2X21hcF9t
bWlvIG1hcG07CiAgICAgICAgIHU2NCBhZGRyOwpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFz
c3Rocm91Z2gvYXJtL3NtbXUuYyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LmMK
aW5kZXggNTY0ZmY5Ni4uYzFhMjliNSAxMDA2NDQKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91
Z2gvYXJtL3NtbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS5jCkBA
IC0yMDg2LDYgKzIwODYsOCBAQCBvdXRfZXJyOgogc3RhdGljIGNvbnN0IGNoYXIgKiBjb25zdCBz
bW11X2R0X2NvbXBhdFtdIF9faW5pdGNvbnN0ID0KIHsKICAgICAiYXJtLG1tdS00MDAiLAorICAg
ICJhcm0sbW11LTUwMCIsCisgICAgInRodW5kZXIsc21tdS12MiIsCiAgICAgTlVMTAogfTsKIApk
aWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLWFybS9naWMtaXRzLmggYi94ZW4vaW5jbHVkZS9h
c20tYXJtL2dpYy1pdHMuaAppbmRleCA5OThjYmQ5Li5iZDc0MDU5IDEwMDY0NAotLS0gYS94ZW4v
aW5jbHVkZS9hc20tYXJtL2dpYy1pdHMuaAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2dpYy1p
dHMuaApAQCAtOTQsMTAgKzk0LDQwIEBAIHN0YXRpYyBpbmxpbmUgdWludDhfdCBpdHNfZGVjb2Rl
X2NtZChzdHJ1Y3QgaXRzX2NtZF9ibG9jayAqY21kKQogICAgIHJldHVybiBjbWQtPnJhd19jbWRb
MF0gJiAweGZmOwogfQogCi1zdGF0aWMgaW5saW5lIHVpbnQzMl90IGl0c19kZWNvZGVfZGV2aWQo
c3RydWN0IGl0c19jbWRfYmxvY2sgKmNtZCkKK3N0YXRpYyBpbmxpbmUgaW50IG1hcF9nc2JkZihz
dHJ1Y3QgZG9tYWluICpkLCB1aW50MzJfdCBnc2JkZiwgdWludDMyX3QgKnNiZGYpCiB7CisJc3Ry
dWN0IHBjaV9kZXYgKnBkZXY7CisJaW50IHJldCA9IC0xOworCXVpbnQzMl90IHRtcF9zYmRmLHQ7
CisKKwlpZihkLT5kb21haW5faWQgPT0gMCkgeworCQkqc2JkZiA9IGdzYmRmOworCQlyZXR1cm4g
MDsKKwl9CisKKwlmb3JfZWFjaF9wZGV2KGQscGRldil7CisJCXRtcF9zYmRmID0gKHBkZXYtPmFy
Y2guZ3NiZGZfcyA8PCAxNikgfAorCQkJCShwZGV2LT5hcmNoLmdzYmRmX2IgPDwgOCkgfAorCQkJ
CShwZGV2LT5hcmNoLmdzYmRmX2QgPDwzKSB8CisJCQkJcGRldi0+YXJjaC5nc2JkZl9mOworCQl0
ID0gKHBkZXYtPnNlZyA8PDE2KSB8IChwZGV2LT5idXMgPDw4KSB8IHBkZXYtPmRldmZuOworCQlw
cmludGsoS0VSTl9FUlIiJXMgRG9tYWluPSVkIHRtcF9zYmRmPSVkICBnc2JkZj0lZCBzYmRmPSVk
XHJcbiIsCisJCQkJX19mdW5jX18sZC0+ZG9tYWluX2lkLCB0bXBfc2JkZiwgZ3NiZGYsIHQpOwor
CQlpZih0bXBfc2JkZiA9PSBnc2JkZikgeworCQkJKnNiZGYgPSB0OworCQkJcmV0ID0gMDsKKwkJ
CWJyZWFrOworCQl9CisJfQorCXJldHVybiByZXQ7Cit9CitzdGF0aWMgaW5saW5lIHVpbnQzMl90
IGl0c19kZWNvZGVfZGV2aWQoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGl0c19jbWRfYmxvY2sg
KmNtZCkKK3sKKwl1aW50MzJfdCBudmFsOwogICAgIHVpbnQzMl90IHZhbCA9IGNtZC0+cmF3X2Nt
ZFswXSA+PiAzMjsKLSAgICBpZih2YWw9PTApIHJldHVybiAweDEwMDI4OworICAgIGlmKCFtYXBf
Z3NiZGYoZCx2YWwsJm52YWwpKQorICAgIAlyZXR1cm4gbnZhbDsKKwogICAgIHJldHVybiAoY21k
LT5yYXdfY21kWzBdID4+IDMyKTsgIAogfQogCkBAIC0xNDIsOSArMTcyLDIwIEBAIHN0YXRpYyBp
bmxpbmUgdm9pZCBpdHNfZW5jb2RlX2NtZChzdHJ1Y3QgaXRzX2NtZF9ibG9jayAqY21kLCB1OCBj
bWRfbnIpCiAgICAgY21kLT5yYXdfY21kWzBdIHw9IGNtZF9ucjsKIH0KIAotc3RhdGljIGlubGlu
ZSB2b2lkIGl0c19lbmNvZGVfZGV2aWQoc3RydWN0IGl0c19jbWRfYmxvY2sgKmNtZCwgdWludDMy
X3QgZGV2aWQpCitzdGF0aWMgaW5saW5lIHZvaWQgaXRzX2VuY29kZV9kZXZpZChzdHJ1Y3QgZG9t
YWluICpkLCBzdHJ1Y3QgaXRzX2NtZF9ibG9jayAqY21kLCB1aW50MzJfdCBkZXZpZCkKK3sKKwl1
aW50MzJfdCBuZGV2aWQ7CisgICAgaWYoIW1hcF9nc2JkZihkLGRldmlkLCZuZGV2aWQpKQorICAg
IAlkZXZpZCA9IG5kZXZpZDsKKworICAgIGNtZC0+cmF3X2NtZFswXSAmPSB+KDB4ZmZmZlVMIDw8
IDMyKTsKKyAgICBjbWQtPnJhd19jbWRbMF0gfD0gKCh1aW50NjRfdClkZXZpZCAmIDB4ZmZmZmZm
ZmZVTCkgPDwgMzI7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBfaXRzX2VuY29kZV9kZXZpZChz
dHJ1Y3QgaXRzX2NtZF9ibG9jayAqY21kLCB1aW50MzJfdCBkZXZpZCkKIHsKLSAgICBpZihkZXZp
ZD09MCkgZGV2aWQgPSAweDEwMDI4OworCiAgICAgY21kLT5yYXdfY21kWzBdICY9IH4oMHhmZmZm
VUwgPDwgMzIpOwogICAgIGNtZC0+cmF3X2NtZFswXSB8PSAoKHVpbnQ2NF90KWRldmlkICYgMHhm
ZmZmZmZmZlVMKSA8PCAzMjsKIH0KZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vcGNp
LmggYi94ZW4vaW5jbHVkZS9hc20tYXJtL3BjaS5oCmluZGV4IGQyMGEyOTkuLmJmZTg2ZjUgMTAw
NjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vcGNpLmgKKysrIGIveGVuL2luY2x1ZGUvYXNt
LWFybS9wY2kuaApAQCAtNiw2ICs2LDEwIEBACiBzdHJ1Y3QgYXJjaF9wY2lfZGV2IHsKIAl1NjQg
YWRkcltNQVhfUENJX0JBUlNdOwogCXU2NCBzaXplW01BWF9QQ0lfQkFSU107CisgICAgaW50IGdz
YmRmX3M7CisgICAgaW50IGdzYmRmX2I7CisgICAgaW50IGdzYmRmX2Q7CisgICAgaW50IGdzYmRm
X2Y7CiAJaW50IHZhbGlkOwogfTsKIHN0cnVjdCBwY2lfY29uZiB7CmRpZmYgLS1naXQgYS94ZW4v
aW5jbHVkZS9wdWJsaWMvcGh5c2Rldi5oIGIveGVuL2luY2x1ZGUvcHVibGljL3BoeXNkZXYuaApp
bmRleCA5ZDE1Mjg2Li5kNGFkMzhjIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvcGh5
c2Rldi5oCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9waHlzZGV2LmgKQEAgLTM0NCw5ICszNDQs
MjcgQEAgc3RydWN0IHBoeXNkZXZfbWFwX21taW8gewogICAgIHVpbnQ2NF90IGFkZHI7CiAgICAg
dWludDY0X3Qgc2l6ZTsKIH07CisKICNkZWZpbmUgUEhZU0RFVk9QX3BjaV9kb21haW5fZGV0YWNo
ICAgICAgICAgICAgICA0MgogdHlwZWRlZiBzdHJ1Y3QgcGh5c2Rldl9tYXBfbW1pbyBwaHlzZGV2
X21hcF9tbWlvX3Q7CiBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShwaHlzZGV2X21hcF9tbWlvX3Qp
OworCisjZGVmaW5lIFBIWVNERVZPUF9tYXBfc2JkZgkJNDMKK3N0cnVjdCBwaHlzZGV2X21hcF9z
YmRmIHsKKwlpbnQgZG9tYWluX2lkOworCWludCBzYmRmX3M7CisJaW50IHNiZGZfYjsKKwlpbnQg
c2JkZl9kOworCWludCBzYmRmX2Y7CisKKwlpbnQgZ3NiZGZfczsKKwlpbnQgZ3NiZGZfYjsKKwlp
bnQgZ3NiZGZfZDsKKwlpbnQgZ3NiZGZfZjsKK307Cit0eXBlZGVmIHN0cnVjdCBwaHlzZGV2X21h
cF9zYmRmIHBoeXNkZXZfbWFwX3NiZGZfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHBoeXNk
ZXZfbWFwX3NiZGZfdCk7CisKIC8qCiAgKiBOb3RpZnkgdGhhdCBzb21lIFBJUlEtYm91bmQgZXZl
bnQgY2hhbm5lbHMgaGF2ZSBiZWVuIHVubWFza2VkLgogICogKiogVGhpcyBjb21tYW5kIGlzIG9i
c29sZXRlIHNpbmNlIGludGVyZmFjZSB2ZXJzaW9uIDB4MDAwMzAyMDIgYW5kIGlzICoqCi0tIAox
LjkuMQoK
--089e0158b1568d74910507325860
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--089e0158b1568d74910507325860--


From xen-devel-bounces@lists.xen.org Thu Nov 06 15:28:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOz4-0005J3-MO; Thu, 06 Nov 2014 15:28:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmOz3-0005ID-Dp
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:28:25 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	38/CB-09284-8939B545; Thu, 06 Nov 2014 15:28:24 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415287702!6462344!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4691 invoked from network); 6 Nov 2014 15:28:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:28:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190216443"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:27:13 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOxt-0000mK-E9;
	Thu, 06 Nov 2014 15:27:13 +0000
Date: Thu, 6 Nov 2014 15:27:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jiuC51hrTDHivnv8mpMjns1V9eT4tafKYxv_gCAgJWgpGg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061521110.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041609070.22875@kaball.uk.xensource.com>
	<CAN58jiuC51hrTDHivnv8mpMjns1V9eT4tafKYxv_gCAgJWgpGg@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared
 info definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Tue, Nov 4, 2014 at 6:12 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> This shared info will be used by hwdom-cpufreq driver
> >> to send commands to the cpufreq driver in the hwdom.
> >>
> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >> ---
> >>  xen/include/asm-arm/shared.h  | 14 ++++++++++++++
> >>  xen/include/public/arch-arm.h |  8 ++++++++
> >>  2 files changed, 22 insertions(+)
> >>  create mode 100644 xen/include/asm-arm/shared.h
> >>
> >> diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
> >> new file mode 100644
> >> index 0000000..4906f38
> >> --- /dev/null
> >> +++ b/xen/include/asm-arm/shared.h
> >> @@ -0,0 +1,14 @@
> >> +#ifndef __XEN_ARM_SHARED_H__
> >> +#define __XEN_ARM_SHARED_H__
> >> +
> >> +#define GET_SET_SHARED(type, field)                                 \
> >> +static inline type *arch_get_##field##_addr(const struct domain *d) \
> >> +{                                                                   \
> >> +   return &d->shared_info->arch.field;                              \
> >> +}
> >> +
> >> +GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
> >> +
> >> +#undef GET_SET_SHARED
> >> +
> >> +#endif /* __XEN_ARM_SHARED_H__ */
> >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> >> index 7496556..7eef6f7 100644
> >> --- a/xen/include/public/arch-arm.h
> >> +++ b/xen/include/public/arch-arm.h
> >> @@ -309,7 +309,15 @@ struct arch_vcpu_info {
> >>  };
> >>  typedef struct arch_vcpu_info arch_vcpu_info_t;
> >>
> >> +struct cpufreq_sh_info {
> >> +    uint32_t cpu;       /* Physical CPU number */
> >> +    uint32_t freq;      /* Frequency in KHz */
> >> +    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
> >> +    int32_t result;        /* Returned result of the operation */
> >> +};
> >> +
> >>  struct arch_shared_info {
> >> +    struct cpufreq_sh_info cpufreq;
> >>  };
> >>  typedef struct arch_shared_info arch_shared_info_t;
> >>  typedef uint64_t xen_callback_t;
> >
> > This introduces one global struct cpufreq_sh_info. Do we need to worry
> > about locking? Is it possible that we might want to send two commands
> > simultaneously? How does Xen get to know that Dom0 completed the
> > previous operation before starting a new one?
> As I've written before:
> I'll create an event channel between Xen and hwdom.
> In this case Xen will be able to know that hwdom completed the
> previous operation before starting a new one.

I don't think that Xen can receive event channel notifications.  You
might have to introduce some kind of synchronization protocol within
struct cpufreq_sh_info.

It would greatly simplify your problem if you made sure that the guest
cpufreq "handler" only ran on one particular vcpu. Maybe you could
register the vcpu handler at boot time via hypercall. Otherwise you
could have one struct cpufreq_sh_info per guest vcpu.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:28:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmOz4-0005J3-MO; Thu, 06 Nov 2014 15:28:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmOz3-0005ID-Dp
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:28:25 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	38/CB-09284-8939B545; Thu, 06 Nov 2014 15:28:24 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415287702!6462344!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4691 invoked from network); 6 Nov 2014 15:28:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:28:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190216443"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:27:13 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOxt-0000mK-E9;
	Thu, 06 Nov 2014 15:27:13 +0000
Date: Thu, 6 Nov 2014 15:27:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jiuC51hrTDHivnv8mpMjns1V9eT4tafKYxv_gCAgJWgpGg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061521110.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041609070.22875@kaball.uk.xensource.com>
	<CAN58jiuC51hrTDHivnv8mpMjns1V9eT4tafKYxv_gCAgJWgpGg@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared
 info definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Tue, Nov 4, 2014 at 6:12 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> This shared info will be used by hwdom-cpufreq driver
> >> to send commands to the cpufreq driver in the hwdom.
> >>
> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >> ---
> >>  xen/include/asm-arm/shared.h  | 14 ++++++++++++++
> >>  xen/include/public/arch-arm.h |  8 ++++++++
> >>  2 files changed, 22 insertions(+)
> >>  create mode 100644 xen/include/asm-arm/shared.h
> >>
> >> diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
> >> new file mode 100644
> >> index 0000000..4906f38
> >> --- /dev/null
> >> +++ b/xen/include/asm-arm/shared.h
> >> @@ -0,0 +1,14 @@
> >> +#ifndef __XEN_ARM_SHARED_H__
> >> +#define __XEN_ARM_SHARED_H__
> >> +
> >> +#define GET_SET_SHARED(type, field)                                 \
> >> +static inline type *arch_get_##field##_addr(const struct domain *d) \
> >> +{                                                                   \
> >> +   return &d->shared_info->arch.field;                              \
> >> +}
> >> +
> >> +GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
> >> +
> >> +#undef GET_SET_SHARED
> >> +
> >> +#endif /* __XEN_ARM_SHARED_H__ */
> >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> >> index 7496556..7eef6f7 100644
> >> --- a/xen/include/public/arch-arm.h
> >> +++ b/xen/include/public/arch-arm.h
> >> @@ -309,7 +309,15 @@ struct arch_vcpu_info {
> >>  };
> >>  typedef struct arch_vcpu_info arch_vcpu_info_t;
> >>
> >> +struct cpufreq_sh_info {
> >> +    uint32_t cpu;       /* Physical CPU number */
> >> +    uint32_t freq;      /* Frequency in KHz */
> >> +    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
> >> +    int32_t result;        /* Returned result of the operation */
> >> +};
> >> +
> >>  struct arch_shared_info {
> >> +    struct cpufreq_sh_info cpufreq;
> >>  };
> >>  typedef struct arch_shared_info arch_shared_info_t;
> >>  typedef uint64_t xen_callback_t;
> >
> > This introduces one global struct cpufreq_sh_info. Do we need to worry
> > about locking? Is it possible that we might want to send two commands
> > simultaneously? How does Xen get to know that Dom0 completed the
> > previous operation before starting a new one?
> As I've written before:
> I'll create an event channel between Xen and hwdom.
> In this case Xen will be able to know that hwdom completed the
> previous operation before starting a new one.

I don't think that Xen can receive event channel notifications.  You
might have to introduce some kind of synchronization protocol within
struct cpufreq_sh_info.

It would greatly simplify your problem if you made sure that the guest
cpufreq "handler" only ran on one particular vcpu. Maybe you could
register the vcpu handler at boot time via hypercall. Otherwise you
could have one struct cpufreq_sh_info per guest vcpu.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:29:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:29:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmP0C-0005cW-79; Thu, 06 Nov 2014 15:29:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmP0A-0005c4-9E
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:29:34 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	56/CB-02576-DD39B545; Thu, 06 Nov 2014 15:29:33 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415287771!11866818!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24313 invoked from network); 6 Nov 2014 15:29:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:29:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188799718"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:28:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOym-0000mu-9f;
	Thu, 06 Nov 2014 15:28:08 +0000
Date: Thu, 6 Nov 2014 15:28:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jis_GbKe2s+Fbg=A4-Jfu4vCzZGCmMqPqVZ9yKwX9LdwcA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061527390.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
	<CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
	<alpine.DEB.2.02.1411061516210.22875@kaball.uk.xensource.com>
	<CAN58jis_GbKe2s+Fbg=A4-Jfu4vCzZGCmMqPqVZ9yKwX9LdwcA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >> >
> >> > Why?
> >> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
> >
> > I meant why are you introducing HYPERVISOR_dom0_op?
> HYPERVISOR_dom0_op is used to upload CPUs PM data from Kernel to Xen

Please add the explanation to the commit message.


> 
> >> >>  arch/arm/include/asm/xen/hypercall.h | 1 +
> >> >>  arch/arm/xen/enlighten.c             | 1 +
> >> >>  arch/arm/xen/hypercall.S             | 1 +
> >> >>  3 files changed, 3 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> >> >> index 751869eb..383c174 100644
> >> >> --- a/arch/arm/include/asm/xen/hypercall.h
> >> >> +++ b/arch/arm/include/asm/xen/hypercall.h
> >> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> >> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
> >> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
> >> >>  int HYPERVISOR_tmem_op(void *arg);
> >> >> +int HYPERVISOR_dom0_op(void *arg);
> >> >>  int HYPERVISOR_sysctl(void *arg);
> >> >>
> >> >>  static inline void
> >> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> >> >> index 675f17a..f757c57 100644
> >> >> --- a/arch/arm/xen/enlighten.c
> >> >> +++ b/arch/arm/xen/enlighten.c
> >> >> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> >> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
> >> >>  EXPORT_SYMBOL_GPL(privcmd_call);
> >> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> >> >> index a1276df..99e2254 100644
> >> >> --- a/arch/arm/xen/hypercall.S
> >> >> +++ b/arch/arm/xen/hypercall.S
> >> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
> >> >>  HYPERCALL2(physdev_op);
> >> >>  HYPERCALL3(vcpu_op);
> >> >>  HYPERCALL1(tmem_op);
> >> >> +HYPERCALL1(dom0_op);
> >> >>  HYPERCALL1(sysctl);
> >> >>
> >> >>  ENTRY(privcmd_call)
> >> >> --
> >> >> 1.9.1
> >> >>
> >>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:29:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:29:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmP0C-0005cW-79; Thu, 06 Nov 2014 15:29:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmP0A-0005c4-9E
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:29:34 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	56/CB-02576-DD39B545; Thu, 06 Nov 2014 15:29:33 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415287771!11866818!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24313 invoked from network); 6 Nov 2014 15:29:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:29:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188799718"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:28:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOym-0000mu-9f;
	Thu, 06 Nov 2014 15:28:08 +0000
Date: Thu, 6 Nov 2014 15:28:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jis_GbKe2s+Fbg=A4-Jfu4vCzZGCmMqPqVZ9yKwX9LdwcA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061527390.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
	<CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
	<alpine.DEB.2.02.1411061516210.22875@kaball.uk.xensource.com>
	<CAN58jis_GbKe2s+Fbg=A4-Jfu4vCzZGCmMqPqVZ9yKwX9LdwcA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >> >
> >> > Why?
> >> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
> >
> > I meant why are you introducing HYPERVISOR_dom0_op?
> HYPERVISOR_dom0_op is used to upload CPUs PM data from Kernel to Xen

Please add the explanation to the commit message.


> 
> >> >>  arch/arm/include/asm/xen/hypercall.h | 1 +
> >> >>  arch/arm/xen/enlighten.c             | 1 +
> >> >>  arch/arm/xen/hypercall.S             | 1 +
> >> >>  3 files changed, 3 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> >> >> index 751869eb..383c174 100644
> >> >> --- a/arch/arm/include/asm/xen/hypercall.h
> >> >> +++ b/arch/arm/include/asm/xen/hypercall.h
> >> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> >> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
> >> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
> >> >>  int HYPERVISOR_tmem_op(void *arg);
> >> >> +int HYPERVISOR_dom0_op(void *arg);
> >> >>  int HYPERVISOR_sysctl(void *arg);
> >> >>
> >> >>  static inline void
> >> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> >> >> index 675f17a..f757c57 100644
> >> >> --- a/arch/arm/xen/enlighten.c
> >> >> +++ b/arch/arm/xen/enlighten.c
> >> >> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> >> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
> >> >>  EXPORT_SYMBOL_GPL(privcmd_call);
> >> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> >> >> index a1276df..99e2254 100644
> >> >> --- a/arch/arm/xen/hypercall.S
> >> >> +++ b/arch/arm/xen/hypercall.S
> >> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
> >> >>  HYPERCALL2(physdev_op);
> >> >>  HYPERCALL3(vcpu_op);
> >> >>  HYPERCALL1(tmem_op);
> >> >> +HYPERCALL1(dom0_op);
> >> >>  HYPERCALL1(sysctl);
> >> >>
> >> >>  ENTRY(privcmd_call)
> >> >> --
> >> >> 1.9.1
> >> >>
> >>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:29:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmP0Q-0005gG-LW; Thu, 06 Nov 2014 15:29:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmP0O-0005ff-SK
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:29:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EB/D3-24532-CE39B545; Thu, 06 Nov 2014 15:29:48 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415287784!12012739!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20681 invoked from network); 6 Nov 2014 15:29:46 -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;
	6 Nov 2014 15:29:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190217368"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:29:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOzn-0000o3-EO;
	Thu, 06 Nov 2014 15:29:11 +0000
Date: Thu, 6 Nov 2014 15:29:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jivVbpc4exAfq_g9NswoQycdNUdSJQwa=msCXKnuF4=f9w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061528020.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
	<CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
	<alpine.DEB.2.02.1411061515400.22875@kaball.uk.xensource.com>
	<CAN58jivVbpc4exAfq_g9NswoQycdNUdSJQwa=msCXKnuF4=f9w@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >> >
> >> > Why?
> >> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
> >
> > Sorry, I meant why are you introducing HYPERVISOR_sysctl?
> I use it to get real physical CPUs counter.
> Also I'll implement a new sysctl operation: XEN_SYSCTL_cpufreq_op
> Kernel will use this op to start/stop cpufreq notification
> events sending.

Please add the exaplanation to the commit message. Also don't add
structs and definitions that you don't need, such as
xen_sysctl_readconsole and XEN_SYSCTL_SCHEDOP_putinfo.


> >> >>  arch/arm/include/asm/xen/hypercall.h |   1 +
> >> >>  arch/arm/include/asm/xen/interface.h |   2 +
> >> >>  arch/arm/xen/enlighten.c             |   1 +
> >> >>  arch/arm/xen/hypercall.S             |   1 +
> >> >>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
> >> >>  include/xen/interface/xen.h          |   6 +
> >> >>  6 files changed, 657 insertions(+)
> >> >>  create mode 100644 include/xen/interface/sysctl.h
> >> >>
> >> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> >> >> index c817c56..751869eb 100644
> >> >> --- a/arch/arm/include/asm/xen/hypercall.h
> >> >> +++ b/arch/arm/include/asm/xen/hypercall.h
> >> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> >> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
> >> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
> >> >>  int HYPERVISOR_tmem_op(void *arg);
> >> >> +int HYPERVISOR_sysctl(void *arg);
> >> >>
> >> >>  static inline void
> >> >>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
> >> >> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> >> >> index 1151188..acf4b7a 100644
> >> >> --- a/arch/arm/include/asm/xen/interface.h
> >> >> +++ b/arch/arm/include/asm/xen/interface.h
> >> >> @@ -19,6 +19,7 @@
> >> >>       __DEFINE_GUEST_HANDLE(name, struct name)
> >> >>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
> >> >>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
> >> >> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
> >> >>
> >> >>  #define set_xen_guest_handle(hnd, val)                       \
> >> >>       do {                                            \
> >> >> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
> >> >>  DEFINE_GUEST_HANDLE(void);
> >> >>  DEFINE_GUEST_HANDLE(uint64_t);
> >> >>  DEFINE_GUEST_HANDLE(uint32_t);
> >> >> +DEFINE_GUEST_HANDLE(uint8_t);
> >> >>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> >> >>  DEFINE_GUEST_HANDLE(xen_ulong_t);
> >> >>
> >> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> >> >> index eb0d851..675f17a 100644
> >> >> --- a/arch/arm/xen/enlighten.c
> >> >> +++ b/arch/arm/xen/enlighten.c
> >> >> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> >> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
> >> >>  EXPORT_SYMBOL_GPL(privcmd_call);
> >> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> >> >> index d1cf7b7..a1276df 100644
> >> >> --- a/arch/arm/xen/hypercall.S
> >> >> +++ b/arch/arm/xen/hypercall.S
> >> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
> >> >>  HYPERCALL2(physdev_op);
> >> >>  HYPERCALL3(vcpu_op);
> >> >>  HYPERCALL1(tmem_op);
> >> >> +HYPERCALL1(sysctl);
> >> >>
> >> >>  ENTRY(privcmd_call)
> >> >>       stmdb sp!, {r4}
> >> >> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
> >> >> new file mode 100644
> >> >> index 0000000..1a8cf7a
> >> >> --- /dev/null
> >> >> +++ b/include/xen/interface/sysctl.h
> >> >> @@ -0,0 +1,646 @@
> >> >> +/******************************************************************************
> >> >> + * sysctl.h
> >> >> + *
> >> >> + * System management operations. For use by node control stack.
> >> >> + *
> >> >> + * Reused from xen: xen/include/public/sysctl.h
> >> >> + *
> >> >> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> >> >> + * of this software and associated documentation files (the "Software"), to
> >> >> + * deal in the Software without restriction, including without limitation the
> >> >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> >> >> + * sell copies of the Software, and to permit persons to whom the Software is
> >> >> + * furnished to do so, subject to the following conditions:
> >> >> + *
> >> >> + * The above copyright notice and this permission notice shall be included in
> >> >> + * all copies or substantial portions of the Software.
> >> >> + *
> >> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> >> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> >> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> >> >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> >> >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> >> >> + * DEALINGS IN THE SOFTWARE.
> >> >> + *
> >> >> + * Copyright (c) 2002-2006, K Fraser
> >> >> + * Copyright (c) 2014, GlobalLogic Inc.
> >> >> + */
> >> >> +
> >> >> +#ifndef __XEN_PUBLIC_SYSCTL_H__
> >> >> +#define __XEN_PUBLIC_SYSCTL_H__
> >> >> +
> >> >> +#include <xen/interface/xen.h>
> >> >> +
> >> >> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
> >> >> +
> >> >> +/*
> >> >> + * Read console content from Xen buffer ring.
> >> >> + */
> >> >> +/* XEN_SYSCTL_readconsole */
> >> >> +struct xen_sysctl_readconsole {
> >> >> +     /* IN: Non-zero -> clear after reading. */
> >> >> +     uint8_t clear;
> >> >> +     /* IN: Non-zero -> start index specified by @index field. */
> >> >> +     uint8_t incremental;
> >> >> +     uint8_t pad0, pad1;
> >> >> +     /*
> >> >> +     * IN:  Start index for consuming from ring buffer (if @incremental);
> >> >> +     * OUT: End index after consuming from ring buffer.
> >> >> +     */
> >> >> +     uint32_t index;
> >> >> +     /* IN: Virtual address to write console data. */
> >> >> +     GUEST_HANDLE_64(char) buffer;
> >> >> +     /* IN: Size of buffer; OUT: Bytes written to buffer. */
> >> >> +     uint32_t count;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
> >> >> +
> >> >> +/* Get trace buffers machine base address */
> >> >> +/* XEN_SYSCTL_tbuf_op */
> >> >> +struct xen_sysctl_tbuf_op {
> >> >> +    /* IN variables */
> >> >> +#define XEN_SYSCTL_TBUFOP_get_info     0
> >> >> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
> >> >> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
> >> >> +#define XEN_SYSCTL_TBUFOP_set_size     3
> >> >> +#define XEN_SYSCTL_TBUFOP_enable       4
> >> >> +#define XEN_SYSCTL_TBUFOP_disable      5
> >> >> +     uint32_t cmd;
> >> >> +     /* IN/OUT variables */
> >> >> +     struct xenctl_bitmap cpu_mask;
> >> >> +     uint32_t             evt_mask;
> >> >> +     /* OUT variables */
> >> >> +     uint64_aligned_t buffer_mfn;
> >> >> +     uint32_t size;  /* Also an IN variable! */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
> >> >> +
> >> >> +/*
> >> >> + * Get physical information about the host machine
> >> >> + */
> >> >> +/* XEN_SYSCTL_physinfo */
> >> >> + /* (x86) The platform supports HVM guests. */
> >> >> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
> >> >> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
> >> >> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
> >> >> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
> >> >> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
> >> >> +struct xen_sysctl_physinfo {
> >> >> +     uint32_t threads_per_core;
> >> >> +     uint32_t cores_per_socket;
> >> >> +     uint32_t nr_cpus;     /* # CPUs currently online */
> >> >> +     uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
> >> >> +     uint32_t nr_nodes;    /* # nodes currently online */
> >> >> +     uint32_t max_node_id; /* Largest possible node ID on this host */
> >> >> +     uint32_t cpu_khz;
> >> >> +     uint64_aligned_t total_pages;
> >> >> +     uint64_aligned_t free_pages;
> >> >> +     uint64_aligned_t scrub_pages;
> >> >> +     uint64_aligned_t outstanding_pages;
> >> >> +     uint32_t hw_cap[8];
> >> >> +
> >> >> +     /* XEN_SYSCTL_PHYSCAP_??? */
> >> >> +     uint32_t capabilities;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
> >> >> +
> >> >> +/*
> >> >> + * Get the ID of the current scheduler.
> >> >> + */
> >> >> +/* XEN_SYSCTL_sched_id */
> >> >> +struct xen_sysctl_sched_id {
> >> >> +     /* OUT variable */
> >> >> +     uint32_t sched_id;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
> >> >> +
> >> >> +/* Interface for controlling Xen software performance counters. */
> >> >> +/* XEN_SYSCTL_perfc_op */
> >> >> +/* Sub-operations: */
> >> >> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
> >> >> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
> >> >> +struct xen_sysctl_perfc_desc {
> >> >> +     char         name[80];           /* name of perf counter */
> >> >> +     uint32_t     nr_vals;            /* number of values for this counter */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
> >> >> +
> >> >> +struct xen_sysctl_perfc_op {
> >> >> +     /* IN variables. */
> >> >> +     uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
> >> >> +     /* OUT variables. */
> >> >> +     uint32_t       nr_counters;       /*  number of counters description  */
> >> >> +     uint32_t       nr_vals;           /*  number of values  */
> >> >> +     /* counter information (or NULL) */
> >> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
> >> >> +     /* counter values (or NULL) */
> >> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
> >> >> +
> >> >> +/* Inject debug keys into Xen. */
> >> >> +/* XEN_SYSCTL_debug_keys */
> >> >> +struct xen_sysctl_debug_keys {
> >> >> +     /* IN variables. */
> >> >> +     GUEST_HANDLE_64(char) keys;
> >> >> +     uint32_t nr_keys;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
> >> >> +
> >> >> +/* Get physical CPU information. */
> >> >> +/* XEN_SYSCTL_getcpuinfo */
> >> >> +struct xen_sysctl_cpuinfo {
> >> >> +     uint64_aligned_t idletime;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
> >> >> +struct xen_sysctl_getcpuinfo {
> >> >> +     /* IN variables. */
> >> >> +     uint32_t max_cpus;
> >> >> +     GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
> >> >> +     /* OUT variables. */
> >> >> +     uint32_t nr_cpus;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
> >> >> +
> >> >> +/* XEN_SYSCTL_availheap */
> >> >> +struct xen_sysctl_availheap {
> >> >> +     /* IN variables. */
> >> >> +     uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
> >> >> +     uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
> >> >> +     int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
> >> >> +     /* OUT variables. */
> >> >> +     uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
> >> >> +
> >> >> +/* XEN_SYSCTL_get_pmstat */
> >> >> +struct pm_px_val {
> >> >> +     uint64_aligned_t freq;        /* Px core frequency */
> >> >> +     uint64_aligned_t residency;   /* Px residency time */
> >> >> +     uint64_aligned_t count;       /* Px transition count */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
> >> >> +
> >> >> +struct pm_px_stat {
> >> >> +     uint8_t total;        /* total Px states */
> >> >> +     uint8_t usable;       /* usable Px states */
> >> >> +     uint8_t last;         /* last Px state */
> >> >> +     uint8_t cur;          /* current Px state */
> >> >> +     GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
> >> >> +     GUEST_HANDLE_64(pm_px_val) pt;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
> >> >> +
> >> >> +struct pm_cx_stat {
> >> >> +     uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
> >> >> +     uint32_t last;  /* last Cx state */
> >> >> +     uint64_aligned_t idle_time;                 /* idle time from boot */
> >> >> +     GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
> >> >> +     GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
> >> >> +     uint64_aligned_t pc2;
> >> >> +     uint64_aligned_t pc3;
> >> >> +     uint64_aligned_t pc6;
> >> >> +     uint64_aligned_t pc7;
> >> >> +     uint64_aligned_t cc3;
> >> >> +     uint64_aligned_t cc6;
> >> >> +     uint64_aligned_t cc7;
> >> >> +};
> >> >> +
> >> >> +struct xen_sysctl_get_pmstat {
> >> >> +#define PMSTAT_CATEGORY_MASK 0xf0
> >> >> +#define PMSTAT_PX            0x10
> >> >> +#define PMSTAT_CX            0x20
> >> >> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
> >> >> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
> >> >> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
> >> >> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
> >> >> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
> >> >> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
> >> >> +     uint32_t type;
> >> >> +     uint32_t cpuid;
> >> >> +     union {
> >> >> +             struct pm_px_stat getpx;
> >> >> +             struct pm_cx_stat getcx;
> >> >> +             /* other struct for tx, etc */
> >> >> +     } u;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
> >> >> +
> >> >> +/* XEN_SYSCTL_cpu_hotplug */
> >> >> +struct xen_sysctl_cpu_hotplug {
> >> >> +     /* IN variables */
> >> >> +     uint32_t cpu;   /* Physical cpu. */
> >> >> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
> >> >> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
> >> >> +     uint32_t op;    /* hotplug opcode */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
> >> >> +
> >> >> +/*
> >> >> + * Get/set xen power management, include
> >> >> + * 1. cpufreq governors and related parameters
> >> >> + */
> >> >> +/* XEN_SYSCTL_pm_op */
> >> >> +struct xen_userspace {
> >> >> +     uint32_t scaling_setspeed;
> >> >> +};
> >> >> +
> >> >> +struct xen_ondemand {
> >> >> +     uint32_t sampling_rate_max;
> >> >> +     uint32_t sampling_rate_min;
> >> >> +
> >> >> +     uint32_t sampling_rate;
> >> >> +     uint32_t up_threshold;
> >> >> +};
> >> >> +
> >> >> +/*
> >> >> + * cpufreq para name of this structure named
> >> >> + * same as sysfs file name of native linux
> >> >> + */
> >> >> +#define CPUFREQ_NAME_LEN 16
> >> >> +struct xen_get_cpufreq_para {
> >> >> +     /* IN/OUT variable */
> >> >> +     uint32_t cpu_num;
> >> >> +     uint32_t freq_num;
> >> >> +     uint32_t gov_num;
> >> >> +
> >> >> +     /* for all governors */
> >> >> +     /* OUT variable */
> >> >> +     GUEST_HANDLE_64(uint32_t) affected_cpus;
> >> >> +     GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
> >> >> +     GUEST_HANDLE_64(char)   scaling_available_governors;
> >> >> +     char scaling_driver[CPUFREQ_NAME_LEN];
> >> >> +
> >> >> +     uint32_t cpuinfo_cur_freq;
> >> >> +     uint32_t cpuinfo_max_freq;
> >> >> +     uint32_t cpuinfo_min_freq;
> >> >> +     uint32_t scaling_cur_freq;
> >> >> +
> >> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
> >> >> +     uint32_t scaling_max_freq;
> >> >> +     uint32_t scaling_min_freq;
> >> >> +
> >> >> +     /* for specific governor */
> >> >> +     union {
> >> >> +             struct  xen_userspace userspace;
> >> >> +             struct  xen_ondemand ondemand;
> >> >> +     } u;
> >> >> +
> >> >> +     int32_t turbo_enabled;
> >> >> +};
> >> >> +
> >> >> +struct xen_set_cpufreq_gov {
> >> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
> >> >> +};
> >> >> +
> >> >> +struct xen_set_cpufreq_para {
> >> >> +     #define SCALING_MAX_FREQ           1
> >> >> +     #define SCALING_MIN_FREQ           2
> >> >> +     #define SCALING_SETSPEED           3
> >> >> +     #define SAMPLING_RATE              4
> >> >> +     #define UP_THRESHOLD               5
> >> >> +
> >> >> +     uint32_t ctrl_type;
> >> >> +     uint32_t ctrl_value;
> >> >> +};
> >> >> +
> >> >> +struct xen_sysctl_pm_op {
> >> >> +     #define PM_PARA_CATEGORY_MASK      0xf0
> >> >> +     #define CPUFREQ_PARA               0x10
> >> >> +
> >> >> +     /* cpufreq command type */
> >> >> +     #define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
> >> >> +     #define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
> >> >> +     #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
> >> >> +     #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
> >> >> +
> >> >> +     /* set/reset scheduler power saving option */
> >> >> +     #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
> >> >> +
> >> >> +     /* cpuidle max_cstate access command */
> >> >> +     #define XEN_SYSCTL_pm_op_get_max_cstate       0x22
> >> >> +     #define XEN_SYSCTL_pm_op_set_max_cstate       0x23
> >> >> +
> >> >> +     /* set scheduler migration cost value */
> >> >> +     #define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
> >> >> +     #define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
> >> >> +
> >> >> +     /* enable/disable turbo mode when in dbs governor */
> >> >> +     #define XEN_SYSCTL_pm_op_enable_turbo               0x26
> >> >> +     #define XEN_SYSCTL_pm_op_disable_turbo              0x27
> >> >> +
> >> >> +     uint32_t cmd;
> >> >> +     uint32_t cpuid;
> >> >> +     union {
> >> >> +             struct xen_get_cpufreq_para get_para;
> >> >> +             struct xen_set_cpufreq_gov  set_gov;
> >> >> +             struct xen_set_cpufreq_para set_para;
> >> >> +             uint64_aligned_t get_avgfreq;
> >> >> +             uint32_t                    set_sched_opt_smt;
> >> >> +             uint32_t                    get_max_cstate;
> >> >> +             uint32_t                    set_max_cstate;
> >> >> +             uint32_t                    get_vcpu_migration_delay;
> >> >> +             uint32_t                    set_vcpu_migration_delay;
> >> >> +     } u;
> >> >> +};
> >> >> +
> >> >> +/* XEN_SYSCTL_page_offline_op */
> >> >> +struct xen_sysctl_page_offline_op {
> >> >> +     /* IN: range of page to be offlined */
> >> >> +#define sysctl_page_offline     1
> >> >> +#define sysctl_page_online      2
> >> >> +#define sysctl_query_page_offline  3
> >> >> +     uint32_t cmd;
> >> >> +     uint32_t start;
> >> >> +     uint32_t end;
> >> >> +     /* OUT: result of page offline request */
> >> >> +     /*
> >> >> +     * bit 0~15: result flags
> >> >> +     * bit 16~31: owner
> >> >> +     */
> >> >> +     GUEST_HANDLE(uint32_t) status;
> >> >> +};
> >> >> +
> >> >> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
> >> >> +
> >> >> +/* The result is invalid, i.e. HV does not handle it */
> >> >> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
> >> >> +
> >> >> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
> >> >> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
> >> >> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
> >> >> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
> >> >> +
> >> >> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
> >> >> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
> >> >> +
> >> >> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
> >> >> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
> >> >> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
> >> >> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
> >> >> +
> >> >> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
> >> >> +
> >> >> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
> >> >> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
> >> >> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
> >> >> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
> >> >> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
> >> >> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
> >> >> +
> >> >> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
> >> >> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
> >> >> +
> >> >> +#define PG_OFFLINE_OWNER_SHIFT 16
> >> >> +
> >> >> +/* XEN_SYSCTL_lockprof_op */
> >> >> +/* Sub-operations: */
> >> >> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
> >> >> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
> >> >> +/* Record-type: */
> >> >> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
> >> >> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
> >> >> +#define LOCKPROF_TYPE_N           2   /* number of types */
> >> >> +struct xen_sysctl_lockprof_data {
> >> >> +     char     name[40];   /* lock name (may include up to 2 %d specifiers) */
> >> >> +     int32_t  type;       /* LOCKPROF_TYPE_??? */
> >> >> +     int32_t  idx;        /* index (e.g. domain id) */
> >> >> +     uint64_aligned_t lock_cnt;     /* # of locking succeeded */
> >> >> +     uint64_aligned_t block_cnt;    /* # of wait for lock */
> >> >> +     uint64_aligned_t lock_time;    /* nsecs lock held */
> >> >> +     uint64_aligned_t block_time;   /* nsecs waited for lock */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
> >> >> +
> >> >> +struct xen_sysctl_lockprof_op {
> >> >> +     /* IN variables. */
> >> >> +     uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
> >> >> +     uint32_t       max_elem;          /* size of output buffer */
> >> >> +     /* OUT variables (query only). */
> >> >> +     uint32_t       nr_elem;           /* number of elements available */
> >> >> +     uint64_aligned_t time;            /* nsecs of profile measurement */
> >> >> +     /* profile information (or NULL) */
> >> >> +     GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
> >> >> +
> >> >> +/* XEN_SYSCTL_topologyinfo */
> >> >> +#define INVALID_TOPOLOGY_ID  (~0U)
> >> >> +struct xen_sysctl_topologyinfo {
> >> >> +     /*
> >> >> +      * IN: maximum addressable entry in the caller-provided arrays.
> >> >> +      * OUT: largest cpu identifier in the system.
> >> >> +      * If OUT is greater than IN then the arrays are truncated!
> >> >> +      * If OUT is leass than IN then the array tails are not written by
> >> >> +      * sysctl.
> >> >> +      */
> >> >> +     uint32_t max_cpu_index;
> >> >> +
> >> >> +     /*
> >> >> +      * If not NULL, these arrays are filled with core/socket/node identifier
> >> >> +      * for each cpu.
> >> >> +      * If a cpu has no core/socket/node information (e.g., cpu not present)
> >> >> +      * then the sentinel value ~0u is written to each array.
> >> >> +      * The number of array elements written by the sysctl is:
> >> >> +      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
> >> >> +      */
> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_core;
> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_socket;
> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_node;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
> >> >> +
> >> >> +/* XEN_SYSCTL_numainfo */
> >> >> +#define INVALID_NUMAINFO_ID (~0U)
> >> >> +struct xen_sysctl_numainfo {
> >> >> +     /*
> >> >> +      * IN: maximum addressable entry in the caller-provided arrays.
> >> >> +      * OUT: largest node identifier in the system.
> >> >> +      * If OUT is greater than IN then the arrays are truncated!
> >> >> +      */
> >> >> +     uint32_t max_node_index;
> >> >> +
> >> >> +     /* NB. Entries are 0 if node is not present. */
> >> >> +     GUEST_HANDLE_64(uint64_t) node_to_memsize;
> >> >> +     GUEST_HANDLE_64(uint64_t) node_to_memfree;
> >> >> +
> >> >> +     /*
> >> >> +      * Array, of size (max_node_index+1)^2, listing memory access distances
> >> >> +      * between nodes. If an entry has no node distance information (e.g., node
> >> >> +      * not present) then the value ~0u is written.
> >> >> +      *
> >> >> +      * Note that the array rows must be indexed by multiplying by the minimum
> >> >> +      * of the caller-provided max_node_index and the returned value of
> >> >> +      * max_node_index. That is, if the largest node index in the system is
> >> >> +      * smaller than the caller can handle, a smaller 2-d array is constructed
> >> >> +      * within the space provided by the caller. When this occurs, trailing
> >> >> +      * space provided by the caller is not modified. If the largest node index
> >> >> +      * in the system is larger than the caller can handle, then a 2-d array of
> >> >> +      * the maximum size handleable by the caller is constructed.
> >> >> +      */
> >> >> +     GUEST_HANDLE_64(uint32_t) node_to_node_distance;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
> >> >> +
> >> >> +/* XEN_SYSCTL_cpupool_op */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
> >> >> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
> >> >> +struct xen_sysctl_cpupool_op {
> >> >> +     uint32_t op;          /* IN */
> >> >> +     uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
> >> >> +     uint32_t sched_id;    /* IN: C      OUT: I  */
> >> >> +     uint32_t domid;       /* IN: M              */
> >> >> +     uint32_t cpu;         /* IN: AR             */
> >> >> +     uint32_t n_dom;       /*            OUT: I  */
> >> >> +     struct xenctl_bitmap cpumap; /*     OUT: IF */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
> >> >> +
> >> >> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
> >> >> +/*
> >> >> + * This structure is used to pass a new ARINC653 schedule from a
> >> >> + * privileged domain (ie dom0) to Xen.
> >> >> + */
> >> >> +struct xen_sysctl_arinc653_schedule {
> >> >> +     /* major_frame holds the time for the new schedule's major frame
> >> >> +     * in nanoseconds. */
> >> >> +     uint64_aligned_t     major_frame;
> >> >> +     /* num_sched_entries holds how many of the entries in the
> >> >> +     * sched_entries[] array are valid. */
> >> >> +     uint8_t     num_sched_entries;
> >> >> +     /* The sched_entries array holds the actual schedule entries. */
> >> >> +     struct {
> >> >> +             /* dom_handle must match a domain's UUID */
> >> >> +             xen_domain_handle_t dom_handle;
> >> >> +             /*
> >> >> +              * If a domain has multiple VCPUs, vcpu_id specifies which one
> >> >> +              * this schedule entry applies to. It should be set to 0 if
> >> >> +              * there is only one VCPU for the domain. */
> >> >> +             unsigned int vcpu_id;
> >> >> +             /*
> >> >> +              * runtime specifies the amount of time that should be allocated
> >> >> +              * to this VCPU per major frame. It is specified in nanoseconds
> >> >> +              */
> >> >> +             uint64_aligned_t runtime;
> >> >> +     } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
> >> >> +
> >> >> +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;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
> >> >> +
> >> >> +/* XEN_SYSCTL_scheduler_op */
> >> >> +/* Set or get info? */
> >> >> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
> >> >> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
> >> >> +struct xen_sysctl_scheduler_op {
> >> >> +     uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
> >> >> +     uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
> >> >> +     uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
> >> >> +     union {
> >> >> +             struct xen_sysctl_sched_arinc653 {
> >> >> +                     GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
> >> >> +             } sched_arinc653;
> >> >> +             struct xen_sysctl_credit_schedule sched_credit;
> >> >> +     } u;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
> >> >> +
> >> >> +/* XEN_SYSCTL_coverage_op */
> >> >> +/*
> >> >> + * Get total size of information, to help allocate
> >> >> + * the buffer. The pointer points to a 32 bit value.
> >> >> + */
> >> >> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
> >> >> +
> >> >> +/*
> >> >> + * Read coverage information in a single run
> >> >> + * You must use a tool to split them.
> >> >> + */
> >> >> +#define XEN_SYSCTL_COVERAGE_read           1
> >> >> +
> >> >> +/*
> >> >> + * Reset all the coverage counters to 0
> >> >> + * No parameters.
> >> >> + */
> >> >> +#define XEN_SYSCTL_COVERAGE_reset          2
> >> >> +
> >> >> +/*
> >> >> + * Like XEN_SYSCTL_COVERAGE_read but reset also
> >> >> + * counters to 0 in a single call.
> >> >> + */
> >> >> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
> >> >> +
> >> >> +struct xen_sysctl_coverage_op {
> >> >> +     uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
> >> >> +     union {
> >> >> +             uint32_t total_size; /* OUT */
> >> >> +             GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
> >> >> +     } u;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
> >> >> +
> >> >> +
> >> >> +struct xen_sysctl {
> >> >> +     uint32_t cmd;
> >> >> +#define XEN_SYSCTL_readconsole                    1
> >> >> +#define XEN_SYSCTL_tbuf_op                        2
> >> >> +#define XEN_SYSCTL_physinfo                       3
> >> >> +#define XEN_SYSCTL_sched_id                       4
> >> >> +#define XEN_SYSCTL_perfc_op                       5
> >> >> +#define XEN_SYSCTL_debug_keys                     7
> >> >> +#define XEN_SYSCTL_getcpuinfo                     8
> >> >> +#define XEN_SYSCTL_availheap                      9
> >> >> +#define XEN_SYSCTL_get_pmstat                    10
> >> >> +#define XEN_SYSCTL_cpu_hotplug                   11
> >> >> +#define XEN_SYSCTL_pm_op                         12
> >> >> +#define XEN_SYSCTL_page_offline_op               14
> >> >> +#define XEN_SYSCTL_lockprof_op                   15
> >> >> +#define XEN_SYSCTL_topologyinfo                  16
> >> >> +#define XEN_SYSCTL_numainfo                      17
> >> >> +#define XEN_SYSCTL_cpupool_op                    18
> >> >> +#define XEN_SYSCTL_scheduler_op                  19
> >> >> +#define XEN_SYSCTL_coverage_op                   20
> >> >> +     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
> >> >> +     union {
> >> >> +             struct xen_sysctl_readconsole       readconsole;
> >> >> +             struct xen_sysctl_tbuf_op           tbuf_op;
> >> >> +             struct xen_sysctl_physinfo          physinfo;
> >> >> +             struct xen_sysctl_topologyinfo      topologyinfo;
> >> >> +             struct xen_sysctl_numainfo          numainfo;
> >> >> +             struct xen_sysctl_sched_id          sched_id;
> >> >> +             struct xen_sysctl_perfc_op          perfc_op;
> >> >> +             struct xen_sysctl_debug_keys        debug_keys;
> >> >> +             struct xen_sysctl_getcpuinfo        getcpuinfo;
> >> >> +             struct xen_sysctl_availheap         availheap;
> >> >> +             struct xen_sysctl_get_pmstat        get_pmstat;
> >> >> +             struct xen_sysctl_cpu_hotplug       cpu_hotplug;
> >> >> +             struct xen_sysctl_pm_op             pm_op;
> >> >> +             struct xen_sysctl_page_offline_op   page_offline;
> >> >> +             struct xen_sysctl_lockprof_op       lockprof_op;
> >> >> +             struct xen_sysctl_cpupool_op        cpupool_op;
> >> >> +             struct xen_sysctl_scheduler_op      scheduler_op;
> >> >> +             struct xen_sysctl_coverage_op       coverage_op;
> >> >> +             uint8_t                             pad[128];
> >> >> +     } u;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
> >> >> +
> >> >> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */
> >> >
> >> > We usually only introduce what we need from Xen header files in Linux:
> >> > do not copy the entirety of sysctl.h, just introduce what you need.
> >> I'll do this in the next patch-set.
> >>
> >> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> >> >> index 53ec416..cf64566 100644
> >> >> --- a/include/xen/interface/xen.h
> >> >> +++ b/include/xen/interface/xen.h
> >> >> @@ -57,6 +57,7 @@
> >> >>  #define __HYPERVISOR_event_channel_op     32
> >> >>  #define __HYPERVISOR_physdev_op           33
> >> >>  #define __HYPERVISOR_hvm_op               34
> >> >> +#define __HYPERVISOR_sysctl               35
> >> >>  #define __HYPERVISOR_tmem_op              38
> >> >>
> >> >>  /* Architecture-specific hypercall definitions. */
> >> >> @@ -526,6 +527,11 @@ struct tmem_op {
> >> >>
> >> >>  DEFINE_GUEST_HANDLE(u64);
> >> >>
> >> >> +struct xenctl_bitmap {
> >> >> +     GUEST_HANDLE_64(uint8_t) bitmap;
> >> >> +     uint32_t nr_bits;
> >> >> +};
> >> >> +
> >> >>  #else /* __ASSEMBLY__ */
> >> >>
> >> >>  /* In assembly code we cannot use C numeric constant suffixes. */
> >> >> --
> >> >> 1.9.1
> >> >>
> >>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:29:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmP0Q-0005gG-LW; Thu, 06 Nov 2014 15:29:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmP0O-0005ff-SK
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:29:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EB/D3-24532-CE39B545; Thu, 06 Nov 2014 15:29:48 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415287784!12012739!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20681 invoked from network); 6 Nov 2014 15:29:46 -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;
	6 Nov 2014 15:29:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190217368"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:29:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmOzn-0000o3-EO;
	Thu, 06 Nov 2014 15:29:11 +0000
Date: Thu, 6 Nov 2014 15:29:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <CAN58jivVbpc4exAfq_g9NswoQycdNUdSJQwa=msCXKnuF4=f9w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061528020.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
	<CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
	<alpine.DEB.2.02.1411061515400.22875@kaball.uk.xensource.com>
	<CAN58jivVbpc4exAfq_g9NswoQycdNUdSJQwa=msCXKnuF4=f9w@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
> >> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >> >
> >> > Why?
> >> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
> >
> > Sorry, I meant why are you introducing HYPERVISOR_sysctl?
> I use it to get real physical CPUs counter.
> Also I'll implement a new sysctl operation: XEN_SYSCTL_cpufreq_op
> Kernel will use this op to start/stop cpufreq notification
> events sending.

Please add the exaplanation to the commit message. Also don't add
structs and definitions that you don't need, such as
xen_sysctl_readconsole and XEN_SYSCTL_SCHEDOP_putinfo.


> >> >>  arch/arm/include/asm/xen/hypercall.h |   1 +
> >> >>  arch/arm/include/asm/xen/interface.h |   2 +
> >> >>  arch/arm/xen/enlighten.c             |   1 +
> >> >>  arch/arm/xen/hypercall.S             |   1 +
> >> >>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
> >> >>  include/xen/interface/xen.h          |   6 +
> >> >>  6 files changed, 657 insertions(+)
> >> >>  create mode 100644 include/xen/interface/sysctl.h
> >> >>
> >> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> >> >> index c817c56..751869eb 100644
> >> >> --- a/arch/arm/include/asm/xen/hypercall.h
> >> >> +++ b/arch/arm/include/asm/xen/hypercall.h
> >> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> >> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
> >> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
> >> >>  int HYPERVISOR_tmem_op(void *arg);
> >> >> +int HYPERVISOR_sysctl(void *arg);
> >> >>
> >> >>  static inline void
> >> >>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
> >> >> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> >> >> index 1151188..acf4b7a 100644
> >> >> --- a/arch/arm/include/asm/xen/interface.h
> >> >> +++ b/arch/arm/include/asm/xen/interface.h
> >> >> @@ -19,6 +19,7 @@
> >> >>       __DEFINE_GUEST_HANDLE(name, struct name)
> >> >>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
> >> >>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
> >> >> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
> >> >>
> >> >>  #define set_xen_guest_handle(hnd, val)                       \
> >> >>       do {                                            \
> >> >> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
> >> >>  DEFINE_GUEST_HANDLE(void);
> >> >>  DEFINE_GUEST_HANDLE(uint64_t);
> >> >>  DEFINE_GUEST_HANDLE(uint32_t);
> >> >> +DEFINE_GUEST_HANDLE(uint8_t);
> >> >>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> >> >>  DEFINE_GUEST_HANDLE(xen_ulong_t);
> >> >>
> >> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> >> >> index eb0d851..675f17a 100644
> >> >> --- a/arch/arm/xen/enlighten.c
> >> >> +++ b/arch/arm/xen/enlighten.c
> >> >> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> >> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
> >> >>  EXPORT_SYMBOL_GPL(privcmd_call);
> >> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> >> >> index d1cf7b7..a1276df 100644
> >> >> --- a/arch/arm/xen/hypercall.S
> >> >> +++ b/arch/arm/xen/hypercall.S
> >> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
> >> >>  HYPERCALL2(physdev_op);
> >> >>  HYPERCALL3(vcpu_op);
> >> >>  HYPERCALL1(tmem_op);
> >> >> +HYPERCALL1(sysctl);
> >> >>
> >> >>  ENTRY(privcmd_call)
> >> >>       stmdb sp!, {r4}
> >> >> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
> >> >> new file mode 100644
> >> >> index 0000000..1a8cf7a
> >> >> --- /dev/null
> >> >> +++ b/include/xen/interface/sysctl.h
> >> >> @@ -0,0 +1,646 @@
> >> >> +/******************************************************************************
> >> >> + * sysctl.h
> >> >> + *
> >> >> + * System management operations. For use by node control stack.
> >> >> + *
> >> >> + * Reused from xen: xen/include/public/sysctl.h
> >> >> + *
> >> >> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> >> >> + * of this software and associated documentation files (the "Software"), to
> >> >> + * deal in the Software without restriction, including without limitation the
> >> >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> >> >> + * sell copies of the Software, and to permit persons to whom the Software is
> >> >> + * furnished to do so, subject to the following conditions:
> >> >> + *
> >> >> + * The above copyright notice and this permission notice shall be included in
> >> >> + * all copies or substantial portions of the Software.
> >> >> + *
> >> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> >> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> >> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> >> >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> >> >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> >> >> + * DEALINGS IN THE SOFTWARE.
> >> >> + *
> >> >> + * Copyright (c) 2002-2006, K Fraser
> >> >> + * Copyright (c) 2014, GlobalLogic Inc.
> >> >> + */
> >> >> +
> >> >> +#ifndef __XEN_PUBLIC_SYSCTL_H__
> >> >> +#define __XEN_PUBLIC_SYSCTL_H__
> >> >> +
> >> >> +#include <xen/interface/xen.h>
> >> >> +
> >> >> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
> >> >> +
> >> >> +/*
> >> >> + * Read console content from Xen buffer ring.
> >> >> + */
> >> >> +/* XEN_SYSCTL_readconsole */
> >> >> +struct xen_sysctl_readconsole {
> >> >> +     /* IN: Non-zero -> clear after reading. */
> >> >> +     uint8_t clear;
> >> >> +     /* IN: Non-zero -> start index specified by @index field. */
> >> >> +     uint8_t incremental;
> >> >> +     uint8_t pad0, pad1;
> >> >> +     /*
> >> >> +     * IN:  Start index for consuming from ring buffer (if @incremental);
> >> >> +     * OUT: End index after consuming from ring buffer.
> >> >> +     */
> >> >> +     uint32_t index;
> >> >> +     /* IN: Virtual address to write console data. */
> >> >> +     GUEST_HANDLE_64(char) buffer;
> >> >> +     /* IN: Size of buffer; OUT: Bytes written to buffer. */
> >> >> +     uint32_t count;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
> >> >> +
> >> >> +/* Get trace buffers machine base address */
> >> >> +/* XEN_SYSCTL_tbuf_op */
> >> >> +struct xen_sysctl_tbuf_op {
> >> >> +    /* IN variables */
> >> >> +#define XEN_SYSCTL_TBUFOP_get_info     0
> >> >> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
> >> >> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
> >> >> +#define XEN_SYSCTL_TBUFOP_set_size     3
> >> >> +#define XEN_SYSCTL_TBUFOP_enable       4
> >> >> +#define XEN_SYSCTL_TBUFOP_disable      5
> >> >> +     uint32_t cmd;
> >> >> +     /* IN/OUT variables */
> >> >> +     struct xenctl_bitmap cpu_mask;
> >> >> +     uint32_t             evt_mask;
> >> >> +     /* OUT variables */
> >> >> +     uint64_aligned_t buffer_mfn;
> >> >> +     uint32_t size;  /* Also an IN variable! */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
> >> >> +
> >> >> +/*
> >> >> + * Get physical information about the host machine
> >> >> + */
> >> >> +/* XEN_SYSCTL_physinfo */
> >> >> + /* (x86) The platform supports HVM guests. */
> >> >> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
> >> >> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
> >> >> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
> >> >> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
> >> >> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
> >> >> +struct xen_sysctl_physinfo {
> >> >> +     uint32_t threads_per_core;
> >> >> +     uint32_t cores_per_socket;
> >> >> +     uint32_t nr_cpus;     /* # CPUs currently online */
> >> >> +     uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
> >> >> +     uint32_t nr_nodes;    /* # nodes currently online */
> >> >> +     uint32_t max_node_id; /* Largest possible node ID on this host */
> >> >> +     uint32_t cpu_khz;
> >> >> +     uint64_aligned_t total_pages;
> >> >> +     uint64_aligned_t free_pages;
> >> >> +     uint64_aligned_t scrub_pages;
> >> >> +     uint64_aligned_t outstanding_pages;
> >> >> +     uint32_t hw_cap[8];
> >> >> +
> >> >> +     /* XEN_SYSCTL_PHYSCAP_??? */
> >> >> +     uint32_t capabilities;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
> >> >> +
> >> >> +/*
> >> >> + * Get the ID of the current scheduler.
> >> >> + */
> >> >> +/* XEN_SYSCTL_sched_id */
> >> >> +struct xen_sysctl_sched_id {
> >> >> +     /* OUT variable */
> >> >> +     uint32_t sched_id;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
> >> >> +
> >> >> +/* Interface for controlling Xen software performance counters. */
> >> >> +/* XEN_SYSCTL_perfc_op */
> >> >> +/* Sub-operations: */
> >> >> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
> >> >> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
> >> >> +struct xen_sysctl_perfc_desc {
> >> >> +     char         name[80];           /* name of perf counter */
> >> >> +     uint32_t     nr_vals;            /* number of values for this counter */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
> >> >> +
> >> >> +struct xen_sysctl_perfc_op {
> >> >> +     /* IN variables. */
> >> >> +     uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
> >> >> +     /* OUT variables. */
> >> >> +     uint32_t       nr_counters;       /*  number of counters description  */
> >> >> +     uint32_t       nr_vals;           /*  number of values  */
> >> >> +     /* counter information (or NULL) */
> >> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
> >> >> +     /* counter values (or NULL) */
> >> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
> >> >> +
> >> >> +/* Inject debug keys into Xen. */
> >> >> +/* XEN_SYSCTL_debug_keys */
> >> >> +struct xen_sysctl_debug_keys {
> >> >> +     /* IN variables. */
> >> >> +     GUEST_HANDLE_64(char) keys;
> >> >> +     uint32_t nr_keys;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
> >> >> +
> >> >> +/* Get physical CPU information. */
> >> >> +/* XEN_SYSCTL_getcpuinfo */
> >> >> +struct xen_sysctl_cpuinfo {
> >> >> +     uint64_aligned_t idletime;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
> >> >> +struct xen_sysctl_getcpuinfo {
> >> >> +     /* IN variables. */
> >> >> +     uint32_t max_cpus;
> >> >> +     GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
> >> >> +     /* OUT variables. */
> >> >> +     uint32_t nr_cpus;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
> >> >> +
> >> >> +/* XEN_SYSCTL_availheap */
> >> >> +struct xen_sysctl_availheap {
> >> >> +     /* IN variables. */
> >> >> +     uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
> >> >> +     uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
> >> >> +     int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
> >> >> +     /* OUT variables. */
> >> >> +     uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
> >> >> +
> >> >> +/* XEN_SYSCTL_get_pmstat */
> >> >> +struct pm_px_val {
> >> >> +     uint64_aligned_t freq;        /* Px core frequency */
> >> >> +     uint64_aligned_t residency;   /* Px residency time */
> >> >> +     uint64_aligned_t count;       /* Px transition count */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
> >> >> +
> >> >> +struct pm_px_stat {
> >> >> +     uint8_t total;        /* total Px states */
> >> >> +     uint8_t usable;       /* usable Px states */
> >> >> +     uint8_t last;         /* last Px state */
> >> >> +     uint8_t cur;          /* current Px state */
> >> >> +     GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
> >> >> +     GUEST_HANDLE_64(pm_px_val) pt;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
> >> >> +
> >> >> +struct pm_cx_stat {
> >> >> +     uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
> >> >> +     uint32_t last;  /* last Cx state */
> >> >> +     uint64_aligned_t idle_time;                 /* idle time from boot */
> >> >> +     GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
> >> >> +     GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
> >> >> +     uint64_aligned_t pc2;
> >> >> +     uint64_aligned_t pc3;
> >> >> +     uint64_aligned_t pc6;
> >> >> +     uint64_aligned_t pc7;
> >> >> +     uint64_aligned_t cc3;
> >> >> +     uint64_aligned_t cc6;
> >> >> +     uint64_aligned_t cc7;
> >> >> +};
> >> >> +
> >> >> +struct xen_sysctl_get_pmstat {
> >> >> +#define PMSTAT_CATEGORY_MASK 0xf0
> >> >> +#define PMSTAT_PX            0x10
> >> >> +#define PMSTAT_CX            0x20
> >> >> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
> >> >> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
> >> >> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
> >> >> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
> >> >> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
> >> >> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
> >> >> +     uint32_t type;
> >> >> +     uint32_t cpuid;
> >> >> +     union {
> >> >> +             struct pm_px_stat getpx;
> >> >> +             struct pm_cx_stat getcx;
> >> >> +             /* other struct for tx, etc */
> >> >> +     } u;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
> >> >> +
> >> >> +/* XEN_SYSCTL_cpu_hotplug */
> >> >> +struct xen_sysctl_cpu_hotplug {
> >> >> +     /* IN variables */
> >> >> +     uint32_t cpu;   /* Physical cpu. */
> >> >> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
> >> >> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
> >> >> +     uint32_t op;    /* hotplug opcode */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
> >> >> +
> >> >> +/*
> >> >> + * Get/set xen power management, include
> >> >> + * 1. cpufreq governors and related parameters
> >> >> + */
> >> >> +/* XEN_SYSCTL_pm_op */
> >> >> +struct xen_userspace {
> >> >> +     uint32_t scaling_setspeed;
> >> >> +};
> >> >> +
> >> >> +struct xen_ondemand {
> >> >> +     uint32_t sampling_rate_max;
> >> >> +     uint32_t sampling_rate_min;
> >> >> +
> >> >> +     uint32_t sampling_rate;
> >> >> +     uint32_t up_threshold;
> >> >> +};
> >> >> +
> >> >> +/*
> >> >> + * cpufreq para name of this structure named
> >> >> + * same as sysfs file name of native linux
> >> >> + */
> >> >> +#define CPUFREQ_NAME_LEN 16
> >> >> +struct xen_get_cpufreq_para {
> >> >> +     /* IN/OUT variable */
> >> >> +     uint32_t cpu_num;
> >> >> +     uint32_t freq_num;
> >> >> +     uint32_t gov_num;
> >> >> +
> >> >> +     /* for all governors */
> >> >> +     /* OUT variable */
> >> >> +     GUEST_HANDLE_64(uint32_t) affected_cpus;
> >> >> +     GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
> >> >> +     GUEST_HANDLE_64(char)   scaling_available_governors;
> >> >> +     char scaling_driver[CPUFREQ_NAME_LEN];
> >> >> +
> >> >> +     uint32_t cpuinfo_cur_freq;
> >> >> +     uint32_t cpuinfo_max_freq;
> >> >> +     uint32_t cpuinfo_min_freq;
> >> >> +     uint32_t scaling_cur_freq;
> >> >> +
> >> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
> >> >> +     uint32_t scaling_max_freq;
> >> >> +     uint32_t scaling_min_freq;
> >> >> +
> >> >> +     /* for specific governor */
> >> >> +     union {
> >> >> +             struct  xen_userspace userspace;
> >> >> +             struct  xen_ondemand ondemand;
> >> >> +     } u;
> >> >> +
> >> >> +     int32_t turbo_enabled;
> >> >> +};
> >> >> +
> >> >> +struct xen_set_cpufreq_gov {
> >> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
> >> >> +};
> >> >> +
> >> >> +struct xen_set_cpufreq_para {
> >> >> +     #define SCALING_MAX_FREQ           1
> >> >> +     #define SCALING_MIN_FREQ           2
> >> >> +     #define SCALING_SETSPEED           3
> >> >> +     #define SAMPLING_RATE              4
> >> >> +     #define UP_THRESHOLD               5
> >> >> +
> >> >> +     uint32_t ctrl_type;
> >> >> +     uint32_t ctrl_value;
> >> >> +};
> >> >> +
> >> >> +struct xen_sysctl_pm_op {
> >> >> +     #define PM_PARA_CATEGORY_MASK      0xf0
> >> >> +     #define CPUFREQ_PARA               0x10
> >> >> +
> >> >> +     /* cpufreq command type */
> >> >> +     #define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
> >> >> +     #define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
> >> >> +     #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
> >> >> +     #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
> >> >> +
> >> >> +     /* set/reset scheduler power saving option */
> >> >> +     #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
> >> >> +
> >> >> +     /* cpuidle max_cstate access command */
> >> >> +     #define XEN_SYSCTL_pm_op_get_max_cstate       0x22
> >> >> +     #define XEN_SYSCTL_pm_op_set_max_cstate       0x23
> >> >> +
> >> >> +     /* set scheduler migration cost value */
> >> >> +     #define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
> >> >> +     #define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
> >> >> +
> >> >> +     /* enable/disable turbo mode when in dbs governor */
> >> >> +     #define XEN_SYSCTL_pm_op_enable_turbo               0x26
> >> >> +     #define XEN_SYSCTL_pm_op_disable_turbo              0x27
> >> >> +
> >> >> +     uint32_t cmd;
> >> >> +     uint32_t cpuid;
> >> >> +     union {
> >> >> +             struct xen_get_cpufreq_para get_para;
> >> >> +             struct xen_set_cpufreq_gov  set_gov;
> >> >> +             struct xen_set_cpufreq_para set_para;
> >> >> +             uint64_aligned_t get_avgfreq;
> >> >> +             uint32_t                    set_sched_opt_smt;
> >> >> +             uint32_t                    get_max_cstate;
> >> >> +             uint32_t                    set_max_cstate;
> >> >> +             uint32_t                    get_vcpu_migration_delay;
> >> >> +             uint32_t                    set_vcpu_migration_delay;
> >> >> +     } u;
> >> >> +};
> >> >> +
> >> >> +/* XEN_SYSCTL_page_offline_op */
> >> >> +struct xen_sysctl_page_offline_op {
> >> >> +     /* IN: range of page to be offlined */
> >> >> +#define sysctl_page_offline     1
> >> >> +#define sysctl_page_online      2
> >> >> +#define sysctl_query_page_offline  3
> >> >> +     uint32_t cmd;
> >> >> +     uint32_t start;
> >> >> +     uint32_t end;
> >> >> +     /* OUT: result of page offline request */
> >> >> +     /*
> >> >> +     * bit 0~15: result flags
> >> >> +     * bit 16~31: owner
> >> >> +     */
> >> >> +     GUEST_HANDLE(uint32_t) status;
> >> >> +};
> >> >> +
> >> >> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
> >> >> +
> >> >> +/* The result is invalid, i.e. HV does not handle it */
> >> >> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
> >> >> +
> >> >> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
> >> >> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
> >> >> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
> >> >> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
> >> >> +
> >> >> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
> >> >> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
> >> >> +
> >> >> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
> >> >> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
> >> >> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
> >> >> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
> >> >> +
> >> >> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
> >> >> +
> >> >> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
> >> >> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
> >> >> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
> >> >> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
> >> >> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
> >> >> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
> >> >> +
> >> >> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
> >> >> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
> >> >> +
> >> >> +#define PG_OFFLINE_OWNER_SHIFT 16
> >> >> +
> >> >> +/* XEN_SYSCTL_lockprof_op */
> >> >> +/* Sub-operations: */
> >> >> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
> >> >> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
> >> >> +/* Record-type: */
> >> >> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
> >> >> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
> >> >> +#define LOCKPROF_TYPE_N           2   /* number of types */
> >> >> +struct xen_sysctl_lockprof_data {
> >> >> +     char     name[40];   /* lock name (may include up to 2 %d specifiers) */
> >> >> +     int32_t  type;       /* LOCKPROF_TYPE_??? */
> >> >> +     int32_t  idx;        /* index (e.g. domain id) */
> >> >> +     uint64_aligned_t lock_cnt;     /* # of locking succeeded */
> >> >> +     uint64_aligned_t block_cnt;    /* # of wait for lock */
> >> >> +     uint64_aligned_t lock_time;    /* nsecs lock held */
> >> >> +     uint64_aligned_t block_time;   /* nsecs waited for lock */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
> >> >> +
> >> >> +struct xen_sysctl_lockprof_op {
> >> >> +     /* IN variables. */
> >> >> +     uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
> >> >> +     uint32_t       max_elem;          /* size of output buffer */
> >> >> +     /* OUT variables (query only). */
> >> >> +     uint32_t       nr_elem;           /* number of elements available */
> >> >> +     uint64_aligned_t time;            /* nsecs of profile measurement */
> >> >> +     /* profile information (or NULL) */
> >> >> +     GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
> >> >> +
> >> >> +/* XEN_SYSCTL_topologyinfo */
> >> >> +#define INVALID_TOPOLOGY_ID  (~0U)
> >> >> +struct xen_sysctl_topologyinfo {
> >> >> +     /*
> >> >> +      * IN: maximum addressable entry in the caller-provided arrays.
> >> >> +      * OUT: largest cpu identifier in the system.
> >> >> +      * If OUT is greater than IN then the arrays are truncated!
> >> >> +      * If OUT is leass than IN then the array tails are not written by
> >> >> +      * sysctl.
> >> >> +      */
> >> >> +     uint32_t max_cpu_index;
> >> >> +
> >> >> +     /*
> >> >> +      * If not NULL, these arrays are filled with core/socket/node identifier
> >> >> +      * for each cpu.
> >> >> +      * If a cpu has no core/socket/node information (e.g., cpu not present)
> >> >> +      * then the sentinel value ~0u is written to each array.
> >> >> +      * The number of array elements written by the sysctl is:
> >> >> +      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
> >> >> +      */
> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_core;
> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_socket;
> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_node;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
> >> >> +
> >> >> +/* XEN_SYSCTL_numainfo */
> >> >> +#define INVALID_NUMAINFO_ID (~0U)
> >> >> +struct xen_sysctl_numainfo {
> >> >> +     /*
> >> >> +      * IN: maximum addressable entry in the caller-provided arrays.
> >> >> +      * OUT: largest node identifier in the system.
> >> >> +      * If OUT is greater than IN then the arrays are truncated!
> >> >> +      */
> >> >> +     uint32_t max_node_index;
> >> >> +
> >> >> +     /* NB. Entries are 0 if node is not present. */
> >> >> +     GUEST_HANDLE_64(uint64_t) node_to_memsize;
> >> >> +     GUEST_HANDLE_64(uint64_t) node_to_memfree;
> >> >> +
> >> >> +     /*
> >> >> +      * Array, of size (max_node_index+1)^2, listing memory access distances
> >> >> +      * between nodes. If an entry has no node distance information (e.g., node
> >> >> +      * not present) then the value ~0u is written.
> >> >> +      *
> >> >> +      * Note that the array rows must be indexed by multiplying by the minimum
> >> >> +      * of the caller-provided max_node_index and the returned value of
> >> >> +      * max_node_index. That is, if the largest node index in the system is
> >> >> +      * smaller than the caller can handle, a smaller 2-d array is constructed
> >> >> +      * within the space provided by the caller. When this occurs, trailing
> >> >> +      * space provided by the caller is not modified. If the largest node index
> >> >> +      * in the system is larger than the caller can handle, then a 2-d array of
> >> >> +      * the maximum size handleable by the caller is constructed.
> >> >> +      */
> >> >> +     GUEST_HANDLE_64(uint32_t) node_to_node_distance;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
> >> >> +
> >> >> +/* XEN_SYSCTL_cpupool_op */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
> >> >> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
> >> >> +struct xen_sysctl_cpupool_op {
> >> >> +     uint32_t op;          /* IN */
> >> >> +     uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
> >> >> +     uint32_t sched_id;    /* IN: C      OUT: I  */
> >> >> +     uint32_t domid;       /* IN: M              */
> >> >> +     uint32_t cpu;         /* IN: AR             */
> >> >> +     uint32_t n_dom;       /*            OUT: I  */
> >> >> +     struct xenctl_bitmap cpumap; /*     OUT: IF */
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
> >> >> +
> >> >> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
> >> >> +/*
> >> >> + * This structure is used to pass a new ARINC653 schedule from a
> >> >> + * privileged domain (ie dom0) to Xen.
> >> >> + */
> >> >> +struct xen_sysctl_arinc653_schedule {
> >> >> +     /* major_frame holds the time for the new schedule's major frame
> >> >> +     * in nanoseconds. */
> >> >> +     uint64_aligned_t     major_frame;
> >> >> +     /* num_sched_entries holds how many of the entries in the
> >> >> +     * sched_entries[] array are valid. */
> >> >> +     uint8_t     num_sched_entries;
> >> >> +     /* The sched_entries array holds the actual schedule entries. */
> >> >> +     struct {
> >> >> +             /* dom_handle must match a domain's UUID */
> >> >> +             xen_domain_handle_t dom_handle;
> >> >> +             /*
> >> >> +              * If a domain has multiple VCPUs, vcpu_id specifies which one
> >> >> +              * this schedule entry applies to. It should be set to 0 if
> >> >> +              * there is only one VCPU for the domain. */
> >> >> +             unsigned int vcpu_id;
> >> >> +             /*
> >> >> +              * runtime specifies the amount of time that should be allocated
> >> >> +              * to this VCPU per major frame. It is specified in nanoseconds
> >> >> +              */
> >> >> +             uint64_aligned_t runtime;
> >> >> +     } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
> >> >> +
> >> >> +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;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
> >> >> +
> >> >> +/* XEN_SYSCTL_scheduler_op */
> >> >> +/* Set or get info? */
> >> >> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
> >> >> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
> >> >> +struct xen_sysctl_scheduler_op {
> >> >> +     uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
> >> >> +     uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
> >> >> +     uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
> >> >> +     union {
> >> >> +             struct xen_sysctl_sched_arinc653 {
> >> >> +                     GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
> >> >> +             } sched_arinc653;
> >> >> +             struct xen_sysctl_credit_schedule sched_credit;
> >> >> +     } u;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
> >> >> +
> >> >> +/* XEN_SYSCTL_coverage_op */
> >> >> +/*
> >> >> + * Get total size of information, to help allocate
> >> >> + * the buffer. The pointer points to a 32 bit value.
> >> >> + */
> >> >> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
> >> >> +
> >> >> +/*
> >> >> + * Read coverage information in a single run
> >> >> + * You must use a tool to split them.
> >> >> + */
> >> >> +#define XEN_SYSCTL_COVERAGE_read           1
> >> >> +
> >> >> +/*
> >> >> + * Reset all the coverage counters to 0
> >> >> + * No parameters.
> >> >> + */
> >> >> +#define XEN_SYSCTL_COVERAGE_reset          2
> >> >> +
> >> >> +/*
> >> >> + * Like XEN_SYSCTL_COVERAGE_read but reset also
> >> >> + * counters to 0 in a single call.
> >> >> + */
> >> >> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
> >> >> +
> >> >> +struct xen_sysctl_coverage_op {
> >> >> +     uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
> >> >> +     union {
> >> >> +             uint32_t total_size; /* OUT */
> >> >> +             GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
> >> >> +     } u;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
> >> >> +
> >> >> +
> >> >> +struct xen_sysctl {
> >> >> +     uint32_t cmd;
> >> >> +#define XEN_SYSCTL_readconsole                    1
> >> >> +#define XEN_SYSCTL_tbuf_op                        2
> >> >> +#define XEN_SYSCTL_physinfo                       3
> >> >> +#define XEN_SYSCTL_sched_id                       4
> >> >> +#define XEN_SYSCTL_perfc_op                       5
> >> >> +#define XEN_SYSCTL_debug_keys                     7
> >> >> +#define XEN_SYSCTL_getcpuinfo                     8
> >> >> +#define XEN_SYSCTL_availheap                      9
> >> >> +#define XEN_SYSCTL_get_pmstat                    10
> >> >> +#define XEN_SYSCTL_cpu_hotplug                   11
> >> >> +#define XEN_SYSCTL_pm_op                         12
> >> >> +#define XEN_SYSCTL_page_offline_op               14
> >> >> +#define XEN_SYSCTL_lockprof_op                   15
> >> >> +#define XEN_SYSCTL_topologyinfo                  16
> >> >> +#define XEN_SYSCTL_numainfo                      17
> >> >> +#define XEN_SYSCTL_cpupool_op                    18
> >> >> +#define XEN_SYSCTL_scheduler_op                  19
> >> >> +#define XEN_SYSCTL_coverage_op                   20
> >> >> +     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
> >> >> +     union {
> >> >> +             struct xen_sysctl_readconsole       readconsole;
> >> >> +             struct xen_sysctl_tbuf_op           tbuf_op;
> >> >> +             struct xen_sysctl_physinfo          physinfo;
> >> >> +             struct xen_sysctl_topologyinfo      topologyinfo;
> >> >> +             struct xen_sysctl_numainfo          numainfo;
> >> >> +             struct xen_sysctl_sched_id          sched_id;
> >> >> +             struct xen_sysctl_perfc_op          perfc_op;
> >> >> +             struct xen_sysctl_debug_keys        debug_keys;
> >> >> +             struct xen_sysctl_getcpuinfo        getcpuinfo;
> >> >> +             struct xen_sysctl_availheap         availheap;
> >> >> +             struct xen_sysctl_get_pmstat        get_pmstat;
> >> >> +             struct xen_sysctl_cpu_hotplug       cpu_hotplug;
> >> >> +             struct xen_sysctl_pm_op             pm_op;
> >> >> +             struct xen_sysctl_page_offline_op   page_offline;
> >> >> +             struct xen_sysctl_lockprof_op       lockprof_op;
> >> >> +             struct xen_sysctl_cpupool_op        cpupool_op;
> >> >> +             struct xen_sysctl_scheduler_op      scheduler_op;
> >> >> +             struct xen_sysctl_coverage_op       coverage_op;
> >> >> +             uint8_t                             pad[128];
> >> >> +     } u;
> >> >> +};
> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
> >> >> +
> >> >> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */
> >> >
> >> > We usually only introduce what we need from Xen header files in Linux:
> >> > do not copy the entirety of sysctl.h, just introduce what you need.
> >> I'll do this in the next patch-set.
> >>
> >> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> >> >> index 53ec416..cf64566 100644
> >> >> --- a/include/xen/interface/xen.h
> >> >> +++ b/include/xen/interface/xen.h
> >> >> @@ -57,6 +57,7 @@
> >> >>  #define __HYPERVISOR_event_channel_op     32
> >> >>  #define __HYPERVISOR_physdev_op           33
> >> >>  #define __HYPERVISOR_hvm_op               34
> >> >> +#define __HYPERVISOR_sysctl               35
> >> >>  #define __HYPERVISOR_tmem_op              38
> >> >>
> >> >>  /* Architecture-specific hypercall definitions. */
> >> >> @@ -526,6 +527,11 @@ struct tmem_op {
> >> >>
> >> >>  DEFINE_GUEST_HANDLE(u64);
> >> >>
> >> >> +struct xenctl_bitmap {
> >> >> +     GUEST_HANDLE_64(uint8_t) bitmap;
> >> >> +     uint32_t nr_bits;
> >> >> +};
> >> >> +
> >> >>  #else /* __ASSEMBLY__ */
> >> >>
> >> >>  /* In assembly code we cannot use C numeric constant suffixes. */
> >> >> --
> >> >> 1.9.1
> >> >>
> >>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:33:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmP3q-0006Nr-GF; Thu, 06 Nov 2014 15:33:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmP3o-0006Nl-Nm
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:33:21 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	BC/A3-26858-0C49B545; Thu, 06 Nov 2014 15:33:20 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415287995!10848697!1
X-Originating-IP: [64.18.0.20]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14365 invoked from network); 6 Nov 2014 15:33:17 -0000
Received: from exprod5og110.obsmtp.com (HELO exprod5og110.obsmtp.com)
	(64.18.0.20)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:33:17 -0000
Received: from mail-qc0-f180.google.com ([209.85.216.180]) (using TLSv1) by
	exprod5ob110.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuUuv6pZva8TYzBF+1812hPA7vgn+nx@postini.com;
	Thu, 06 Nov 2014 07:33:17 PST
Received: by mail-qc0-f180.google.com with SMTP id o8so913254qcw.39
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:33:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=1hCJPh+dSvRm8nP7wichOPegqY6oq8uoCaUArpVVeEQ=;
	b=YZX3EM/TyTABrKsI9BzG4kfNdmjLnZOWuHWyzhbtDEk5yip0iD89+X0hUnIOjYpVKd
	uggYBj79kbgyehXaYHcbcWh8rI3aEeygn0Kj/jLa0nTt/2yjn9y9Hh+vRTeFo/93r2/G
	3YMGaq9XEo3oBs7cx6leu02b1B/cYQhXtCQys=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=1hCJPh+dSvRm8nP7wichOPegqY6oq8uoCaUArpVVeEQ=;
	b=dPeoSqaSzX85Xnu9IFdmdDQo8ciHP7yEKeE97bOIYK7fuqcKJ4w/vtueTv6RTt0fkv
	/J1/s7Ag71nd4Lly7hkGIcREipuCsS+ROYjc3T4kY+7d7CnI7gAHx/Y7E3TP0ylwEYW6
	MN37fO883MxJXf2VG10AefvUqW2yi00K5nwjUwsXukVs30+f5mPCe//VFtn1AMbIwh6L
	sFiYTzCOatyZGQ/+ay7UmS+H75aCfL5Yaq1Sbkop54qiRgdJu0NzguUo5ZgSIX5cOINj
	5jUbtG/SIwxlhXN1npInpL/HLZkcfwkdwOZ9x5GND+UnW5tPRb6XhuJXsuv2K64HLSai
	LRUQ==
X-Gm-Message-State: ALoCoQm8ttxqg3qR8++eJd9ClCII5bD4Kysy1Mtc+OyFKZthjRsZcYv19K9lqgwf3yvN/wK/b4/qKx3d4WJ14DYt+W435rOWif9jbAFrEmcKhVN8P56IcFTJilVEDhz3VUrH0c0lh/epRAPp/3sRQDwzusrp92/+fQ==
X-Received: by 10.224.127.133 with SMTP id g5mr8104719qas.24.1415287994439;
	Thu, 06 Nov 2014 07:33:14 -0800 (PST)
X-Received: by 10.224.127.133 with SMTP id g5mr8104680qas.24.1415287994179;
	Thu, 06 Nov 2014 07:33:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:32:53 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061528020.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
	<CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
	<alpine.DEB.2.02.1411061515400.22875@kaball.uk.xensource.com>
	<CAN58jivVbpc4exAfq_g9NswoQycdNUdSJQwa=msCXKnuF4=f9w@mail.gmail.com>
	<alpine.DEB.2.02.1411061528020.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:32:53 +0200
Message-ID: <CAN58jitykW8L8s0HexcV7ZeDscyem_1nvye8rbt=7XjYjBnQmw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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'll do this in the next patch-set.

Oleksandr Dmytryshyn | Product Engineering and Development
GlobalLogic
M +38.067.382.2525
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Thu, Nov 6, 2014 at 5:29 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >> >
>> >> > Why?
>> >> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
>> >
>> > Sorry, I meant why are you introducing HYPERVISOR_sysctl?
>> I use it to get real physical CPUs counter.
>> Also I'll implement a new sysctl operation: XEN_SYSCTL_cpufreq_op
>> Kernel will use this op to start/stop cpufreq notification
>> events sending.
>
> Please add the exaplanation to the commit message. Also don't add
> structs and definitions that you don't need, such as
> xen_sysctl_readconsole and XEN_SYSCTL_SCHEDOP_putinfo.
>
>
>> >> >>  arch/arm/include/asm/xen/hypercall.h |   1 +
>> >> >>  arch/arm/include/asm/xen/interface.h |   2 +
>> >> >>  arch/arm/xen/enlighten.c             |   1 +
>> >> >>  arch/arm/xen/hypercall.S             |   1 +
>> >> >>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
>> >> >>  include/xen/interface/xen.h          |   6 +
>> >> >>  6 files changed, 657 insertions(+)
>> >> >>  create mode 100644 include/xen/interface/sysctl.h
>> >> >>
>> >> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> >> >> index c817c56..751869eb 100644
>> >> >> --- a/arch/arm/include/asm/xen/hypercall.h
>> >> >> +++ b/arch/arm/include/asm/xen/hypercall.h
>> >> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>> >> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>> >> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>> >> >>  int HYPERVISOR_tmem_op(void *arg);
>> >> >> +int HYPERVISOR_sysctl(void *arg);
>> >> >>
>> >> >>  static inline void
>> >> >>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
>> >> >> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
>> >> >> index 1151188..acf4b7a 100644
>> >> >> --- a/arch/arm/include/asm/xen/interface.h
>> >> >> +++ b/arch/arm/include/asm/xen/interface.h
>> >> >> @@ -19,6 +19,7 @@
>> >> >>       __DEFINE_GUEST_HANDLE(name, struct name)
>> >> >>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
>> >> >>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
>> >> >> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
>> >> >>
>> >> >>  #define set_xen_guest_handle(hnd, val)                       \
>> >> >>       do {                                            \
>> >> >> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
>> >> >>  DEFINE_GUEST_HANDLE(void);
>> >> >>  DEFINE_GUEST_HANDLE(uint64_t);
>> >> >>  DEFINE_GUEST_HANDLE(uint32_t);
>> >> >> +DEFINE_GUEST_HANDLE(uint8_t);
>> >> >>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>> >> >>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>> >> >>
>> >> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> >> >> index eb0d851..675f17a 100644
>> >> >> --- a/arch/arm/xen/enlighten.c
>> >> >> +++ b/arch/arm/xen/enlighten.c
>> >> >> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> >> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>> >> >>  EXPORT_SYMBOL_GPL(privcmd_call);
>> >> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> >> >> index d1cf7b7..a1276df 100644
>> >> >> --- a/arch/arm/xen/hypercall.S
>> >> >> +++ b/arch/arm/xen/hypercall.S
>> >> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>> >> >>  HYPERCALL2(physdev_op);
>> >> >>  HYPERCALL3(vcpu_op);
>> >> >>  HYPERCALL1(tmem_op);
>> >> >> +HYPERCALL1(sysctl);
>> >> >>
>> >> >>  ENTRY(privcmd_call)
>> >> >>       stmdb sp!, {r4}
>> >> >> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
>> >> >> new file mode 100644
>> >> >> index 0000000..1a8cf7a
>> >> >> --- /dev/null
>> >> >> +++ b/include/xen/interface/sysctl.h
>> >> >> @@ -0,0 +1,646 @@
>> >> >> +/******************************************************************************
>> >> >> + * sysctl.h
>> >> >> + *
>> >> >> + * System management operations. For use by node control stack.
>> >> >> + *
>> >> >> + * Reused from xen: xen/include/public/sysctl.h
>> >> >> + *
>> >> >> + * Permission is hereby granted, free of charge, to any person obtaining a copy
>> >> >> + * of this software and associated documentation files (the "Software"), to
>> >> >> + * deal in the Software without restriction, including without limitation the
>> >> >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
>> >> >> + * sell copies of the Software, and to permit persons to whom the Software is
>> >> >> + * furnished to do so, subject to the following conditions:
>> >> >> + *
>> >> >> + * The above copyright notice and this permission notice shall be included in
>> >> >> + * all copies or substantial portions of the Software.
>> >> >> + *
>> >> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> >> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> >> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
>> >> >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> >> >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> >> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> >> >> + * DEALINGS IN THE SOFTWARE.
>> >> >> + *
>> >> >> + * Copyright (c) 2002-2006, K Fraser
>> >> >> + * Copyright (c) 2014, GlobalLogic Inc.
>> >> >> + */
>> >> >> +
>> >> >> +#ifndef __XEN_PUBLIC_SYSCTL_H__
>> >> >> +#define __XEN_PUBLIC_SYSCTL_H__
>> >> >> +
>> >> >> +#include <xen/interface/xen.h>
>> >> >> +
>> >> >> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
>> >> >> +
>> >> >> +/*
>> >> >> + * Read console content from Xen buffer ring.
>> >> >> + */
>> >> >> +/* XEN_SYSCTL_readconsole */
>> >> >> +struct xen_sysctl_readconsole {
>> >> >> +     /* IN: Non-zero -> clear after reading. */
>> >> >> +     uint8_t clear;
>> >> >> +     /* IN: Non-zero -> start index specified by @index field. */
>> >> >> +     uint8_t incremental;
>> >> >> +     uint8_t pad0, pad1;
>> >> >> +     /*
>> >> >> +     * IN:  Start index for consuming from ring buffer (if @incremental);
>> >> >> +     * OUT: End index after consuming from ring buffer.
>> >> >> +     */
>> >> >> +     uint32_t index;
>> >> >> +     /* IN: Virtual address to write console data. */
>> >> >> +     GUEST_HANDLE_64(char) buffer;
>> >> >> +     /* IN: Size of buffer; OUT: Bytes written to buffer. */
>> >> >> +     uint32_t count;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
>> >> >> +
>> >> >> +/* Get trace buffers machine base address */
>> >> >> +/* XEN_SYSCTL_tbuf_op */
>> >> >> +struct xen_sysctl_tbuf_op {
>> >> >> +    /* IN variables */
>> >> >> +#define XEN_SYSCTL_TBUFOP_get_info     0
>> >> >> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
>> >> >> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
>> >> >> +#define XEN_SYSCTL_TBUFOP_set_size     3
>> >> >> +#define XEN_SYSCTL_TBUFOP_enable       4
>> >> >> +#define XEN_SYSCTL_TBUFOP_disable      5
>> >> >> +     uint32_t cmd;
>> >> >> +     /* IN/OUT variables */
>> >> >> +     struct xenctl_bitmap cpu_mask;
>> >> >> +     uint32_t             evt_mask;
>> >> >> +     /* OUT variables */
>> >> >> +     uint64_aligned_t buffer_mfn;
>> >> >> +     uint32_t size;  /* Also an IN variable! */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
>> >> >> +
>> >> >> +/*
>> >> >> + * Get physical information about the host machine
>> >> >> + */
>> >> >> +/* XEN_SYSCTL_physinfo */
>> >> >> + /* (x86) The platform supports HVM guests. */
>> >> >> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
>> >> >> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
>> >> >> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
>> >> >> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
>> >> >> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
>> >> >> +struct xen_sysctl_physinfo {
>> >> >> +     uint32_t threads_per_core;
>> >> >> +     uint32_t cores_per_socket;
>> >> >> +     uint32_t nr_cpus;     /* # CPUs currently online */
>> >> >> +     uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
>> >> >> +     uint32_t nr_nodes;    /* # nodes currently online */
>> >> >> +     uint32_t max_node_id; /* Largest possible node ID on this host */
>> >> >> +     uint32_t cpu_khz;
>> >> >> +     uint64_aligned_t total_pages;
>> >> >> +     uint64_aligned_t free_pages;
>> >> >> +     uint64_aligned_t scrub_pages;
>> >> >> +     uint64_aligned_t outstanding_pages;
>> >> >> +     uint32_t hw_cap[8];
>> >> >> +
>> >> >> +     /* XEN_SYSCTL_PHYSCAP_??? */
>> >> >> +     uint32_t capabilities;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
>> >> >> +
>> >> >> +/*
>> >> >> + * Get the ID of the current scheduler.
>> >> >> + */
>> >> >> +/* XEN_SYSCTL_sched_id */
>> >> >> +struct xen_sysctl_sched_id {
>> >> >> +     /* OUT variable */
>> >> >> +     uint32_t sched_id;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
>> >> >> +
>> >> >> +/* Interface for controlling Xen software performance counters. */
>> >> >> +/* XEN_SYSCTL_perfc_op */
>> >> >> +/* Sub-operations: */
>> >> >> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
>> >> >> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
>> >> >> +struct xen_sysctl_perfc_desc {
>> >> >> +     char         name[80];           /* name of perf counter */
>> >> >> +     uint32_t     nr_vals;            /* number of values for this counter */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
>> >> >> +
>> >> >> +struct xen_sysctl_perfc_op {
>> >> >> +     /* IN variables. */
>> >> >> +     uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
>> >> >> +     /* OUT variables. */
>> >> >> +     uint32_t       nr_counters;       /*  number of counters description  */
>> >> >> +     uint32_t       nr_vals;           /*  number of values  */
>> >> >> +     /* counter information (or NULL) */
>> >> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
>> >> >> +     /* counter values (or NULL) */
>> >> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
>> >> >> +
>> >> >> +/* Inject debug keys into Xen. */
>> >> >> +/* XEN_SYSCTL_debug_keys */
>> >> >> +struct xen_sysctl_debug_keys {
>> >> >> +     /* IN variables. */
>> >> >> +     GUEST_HANDLE_64(char) keys;
>> >> >> +     uint32_t nr_keys;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
>> >> >> +
>> >> >> +/* Get physical CPU information. */
>> >> >> +/* XEN_SYSCTL_getcpuinfo */
>> >> >> +struct xen_sysctl_cpuinfo {
>> >> >> +     uint64_aligned_t idletime;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
>> >> >> +struct xen_sysctl_getcpuinfo {
>> >> >> +     /* IN variables. */
>> >> >> +     uint32_t max_cpus;
>> >> >> +     GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
>> >> >> +     /* OUT variables. */
>> >> >> +     uint32_t nr_cpus;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_availheap */
>> >> >> +struct xen_sysctl_availheap {
>> >> >> +     /* IN variables. */
>> >> >> +     uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
>> >> >> +     uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
>> >> >> +     int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
>> >> >> +     /* OUT variables. */
>> >> >> +     uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_get_pmstat */
>> >> >> +struct pm_px_val {
>> >> >> +     uint64_aligned_t freq;        /* Px core frequency */
>> >> >> +     uint64_aligned_t residency;   /* Px residency time */
>> >> >> +     uint64_aligned_t count;       /* Px transition count */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
>> >> >> +
>> >> >> +struct pm_px_stat {
>> >> >> +     uint8_t total;        /* total Px states */
>> >> >> +     uint8_t usable;       /* usable Px states */
>> >> >> +     uint8_t last;         /* last Px state */
>> >> >> +     uint8_t cur;          /* current Px state */
>> >> >> +     GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
>> >> >> +     GUEST_HANDLE_64(pm_px_val) pt;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
>> >> >> +
>> >> >> +struct pm_cx_stat {
>> >> >> +     uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
>> >> >> +     uint32_t last;  /* last Cx state */
>> >> >> +     uint64_aligned_t idle_time;                 /* idle time from boot */
>> >> >> +     GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
>> >> >> +     GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
>> >> >> +     uint64_aligned_t pc2;
>> >> >> +     uint64_aligned_t pc3;
>> >> >> +     uint64_aligned_t pc6;
>> >> >> +     uint64_aligned_t pc7;
>> >> >> +     uint64_aligned_t cc3;
>> >> >> +     uint64_aligned_t cc6;
>> >> >> +     uint64_aligned_t cc7;
>> >> >> +};
>> >> >> +
>> >> >> +struct xen_sysctl_get_pmstat {
>> >> >> +#define PMSTAT_CATEGORY_MASK 0xf0
>> >> >> +#define PMSTAT_PX            0x10
>> >> >> +#define PMSTAT_CX            0x20
>> >> >> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
>> >> >> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
>> >> >> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
>> >> >> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
>> >> >> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
>> >> >> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
>> >> >> +     uint32_t type;
>> >> >> +     uint32_t cpuid;
>> >> >> +     union {
>> >> >> +             struct pm_px_stat getpx;
>> >> >> +             struct pm_cx_stat getcx;
>> >> >> +             /* other struct for tx, etc */
>> >> >> +     } u;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_cpu_hotplug */
>> >> >> +struct xen_sysctl_cpu_hotplug {
>> >> >> +     /* IN variables */
>> >> >> +     uint32_t cpu;   /* Physical cpu. */
>> >> >> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
>> >> >> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
>> >> >> +     uint32_t op;    /* hotplug opcode */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
>> >> >> +
>> >> >> +/*
>> >> >> + * Get/set xen power management, include
>> >> >> + * 1. cpufreq governors and related parameters
>> >> >> + */
>> >> >> +/* XEN_SYSCTL_pm_op */
>> >> >> +struct xen_userspace {
>> >> >> +     uint32_t scaling_setspeed;
>> >> >> +};
>> >> >> +
>> >> >> +struct xen_ondemand {
>> >> >> +     uint32_t sampling_rate_max;
>> >> >> +     uint32_t sampling_rate_min;
>> >> >> +
>> >> >> +     uint32_t sampling_rate;
>> >> >> +     uint32_t up_threshold;
>> >> >> +};
>> >> >> +
>> >> >> +/*
>> >> >> + * cpufreq para name of this structure named
>> >> >> + * same as sysfs file name of native linux
>> >> >> + */
>> >> >> +#define CPUFREQ_NAME_LEN 16
>> >> >> +struct xen_get_cpufreq_para {
>> >> >> +     /* IN/OUT variable */
>> >> >> +     uint32_t cpu_num;
>> >> >> +     uint32_t freq_num;
>> >> >> +     uint32_t gov_num;
>> >> >> +
>> >> >> +     /* for all governors */
>> >> >> +     /* OUT variable */
>> >> >> +     GUEST_HANDLE_64(uint32_t) affected_cpus;
>> >> >> +     GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
>> >> >> +     GUEST_HANDLE_64(char)   scaling_available_governors;
>> >> >> +     char scaling_driver[CPUFREQ_NAME_LEN];
>> >> >> +
>> >> >> +     uint32_t cpuinfo_cur_freq;
>> >> >> +     uint32_t cpuinfo_max_freq;
>> >> >> +     uint32_t cpuinfo_min_freq;
>> >> >> +     uint32_t scaling_cur_freq;
>> >> >> +
>> >> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> >> >> +     uint32_t scaling_max_freq;
>> >> >> +     uint32_t scaling_min_freq;
>> >> >> +
>> >> >> +     /* for specific governor */
>> >> >> +     union {
>> >> >> +             struct  xen_userspace userspace;
>> >> >> +             struct  xen_ondemand ondemand;
>> >> >> +     } u;
>> >> >> +
>> >> >> +     int32_t turbo_enabled;
>> >> >> +};
>> >> >> +
>> >> >> +struct xen_set_cpufreq_gov {
>> >> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> >> >> +};
>> >> >> +
>> >> >> +struct xen_set_cpufreq_para {
>> >> >> +     #define SCALING_MAX_FREQ           1
>> >> >> +     #define SCALING_MIN_FREQ           2
>> >> >> +     #define SCALING_SETSPEED           3
>> >> >> +     #define SAMPLING_RATE              4
>> >> >> +     #define UP_THRESHOLD               5
>> >> >> +
>> >> >> +     uint32_t ctrl_type;
>> >> >> +     uint32_t ctrl_value;
>> >> >> +};
>> >> >> +
>> >> >> +struct xen_sysctl_pm_op {
>> >> >> +     #define PM_PARA_CATEGORY_MASK      0xf0
>> >> >> +     #define CPUFREQ_PARA               0x10
>> >> >> +
>> >> >> +     /* cpufreq command type */
>> >> >> +     #define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
>> >> >> +     #define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
>> >> >> +     #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
>> >> >> +     #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
>> >> >> +
>> >> >> +     /* set/reset scheduler power saving option */
>> >> >> +     #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
>> >> >> +
>> >> >> +     /* cpuidle max_cstate access command */
>> >> >> +     #define XEN_SYSCTL_pm_op_get_max_cstate       0x22
>> >> >> +     #define XEN_SYSCTL_pm_op_set_max_cstate       0x23
>> >> >> +
>> >> >> +     /* set scheduler migration cost value */
>> >> >> +     #define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
>> >> >> +     #define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
>> >> >> +
>> >> >> +     /* enable/disable turbo mode when in dbs governor */
>> >> >> +     #define XEN_SYSCTL_pm_op_enable_turbo               0x26
>> >> >> +     #define XEN_SYSCTL_pm_op_disable_turbo              0x27
>> >> >> +
>> >> >> +     uint32_t cmd;
>> >> >> +     uint32_t cpuid;
>> >> >> +     union {
>> >> >> +             struct xen_get_cpufreq_para get_para;
>> >> >> +             struct xen_set_cpufreq_gov  set_gov;
>> >> >> +             struct xen_set_cpufreq_para set_para;
>> >> >> +             uint64_aligned_t get_avgfreq;
>> >> >> +             uint32_t                    set_sched_opt_smt;
>> >> >> +             uint32_t                    get_max_cstate;
>> >> >> +             uint32_t                    set_max_cstate;
>> >> >> +             uint32_t                    get_vcpu_migration_delay;
>> >> >> +             uint32_t                    set_vcpu_migration_delay;
>> >> >> +     } u;
>> >> >> +};
>> >> >> +
>> >> >> +/* XEN_SYSCTL_page_offline_op */
>> >> >> +struct xen_sysctl_page_offline_op {
>> >> >> +     /* IN: range of page to be offlined */
>> >> >> +#define sysctl_page_offline     1
>> >> >> +#define sysctl_page_online      2
>> >> >> +#define sysctl_query_page_offline  3
>> >> >> +     uint32_t cmd;
>> >> >> +     uint32_t start;
>> >> >> +     uint32_t end;
>> >> >> +     /* OUT: result of page offline request */
>> >> >> +     /*
>> >> >> +     * bit 0~15: result flags
>> >> >> +     * bit 16~31: owner
>> >> >> +     */
>> >> >> +     GUEST_HANDLE(uint32_t) status;
>> >> >> +};
>> >> >> +
>> >> >> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
>> >> >> +
>> >> >> +/* The result is invalid, i.e. HV does not handle it */
>> >> >> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
>> >> >> +
>> >> >> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
>> >> >> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
>> >> >> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
>> >> >> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
>> >> >> +
>> >> >> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
>> >> >> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
>> >> >> +
>> >> >> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
>> >> >> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
>> >> >> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
>> >> >> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
>> >> >> +
>> >> >> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
>> >> >> +
>> >> >> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
>> >> >> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
>> >> >> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
>> >> >> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
>> >> >> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
>> >> >> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
>> >> >> +
>> >> >> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
>> >> >> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
>> >> >> +
>> >> >> +#define PG_OFFLINE_OWNER_SHIFT 16
>> >> >> +
>> >> >> +/* XEN_SYSCTL_lockprof_op */
>> >> >> +/* Sub-operations: */
>> >> >> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
>> >> >> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
>> >> >> +/* Record-type: */
>> >> >> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
>> >> >> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
>> >> >> +#define LOCKPROF_TYPE_N           2   /* number of types */
>> >> >> +struct xen_sysctl_lockprof_data {
>> >> >> +     char     name[40];   /* lock name (may include up to 2 %d specifiers) */
>> >> >> +     int32_t  type;       /* LOCKPROF_TYPE_??? */
>> >> >> +     int32_t  idx;        /* index (e.g. domain id) */
>> >> >> +     uint64_aligned_t lock_cnt;     /* # of locking succeeded */
>> >> >> +     uint64_aligned_t block_cnt;    /* # of wait for lock */
>> >> >> +     uint64_aligned_t lock_time;    /* nsecs lock held */
>> >> >> +     uint64_aligned_t block_time;   /* nsecs waited for lock */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
>> >> >> +
>> >> >> +struct xen_sysctl_lockprof_op {
>> >> >> +     /* IN variables. */
>> >> >> +     uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
>> >> >> +     uint32_t       max_elem;          /* size of output buffer */
>> >> >> +     /* OUT variables (query only). */
>> >> >> +     uint32_t       nr_elem;           /* number of elements available */
>> >> >> +     uint64_aligned_t time;            /* nsecs of profile measurement */
>> >> >> +     /* profile information (or NULL) */
>> >> >> +     GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_topologyinfo */
>> >> >> +#define INVALID_TOPOLOGY_ID  (~0U)
>> >> >> +struct xen_sysctl_topologyinfo {
>> >> >> +     /*
>> >> >> +      * IN: maximum addressable entry in the caller-provided arrays.
>> >> >> +      * OUT: largest cpu identifier in the system.
>> >> >> +      * If OUT is greater than IN then the arrays are truncated!
>> >> >> +      * If OUT is leass than IN then the array tails are not written by
>> >> >> +      * sysctl.
>> >> >> +      */
>> >> >> +     uint32_t max_cpu_index;
>> >> >> +
>> >> >> +     /*
>> >> >> +      * If not NULL, these arrays are filled with core/socket/node identifier
>> >> >> +      * for each cpu.
>> >> >> +      * If a cpu has no core/socket/node information (e.g., cpu not present)
>> >> >> +      * then the sentinel value ~0u is written to each array.
>> >> >> +      * The number of array elements written by the sysctl is:
>> >> >> +      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
>> >> >> +      */
>> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_core;
>> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_socket;
>> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_node;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_numainfo */
>> >> >> +#define INVALID_NUMAINFO_ID (~0U)
>> >> >> +struct xen_sysctl_numainfo {
>> >> >> +     /*
>> >> >> +      * IN: maximum addressable entry in the caller-provided arrays.
>> >> >> +      * OUT: largest node identifier in the system.
>> >> >> +      * If OUT is greater than IN then the arrays are truncated!
>> >> >> +      */
>> >> >> +     uint32_t max_node_index;
>> >> >> +
>> >> >> +     /* NB. Entries are 0 if node is not present. */
>> >> >> +     GUEST_HANDLE_64(uint64_t) node_to_memsize;
>> >> >> +     GUEST_HANDLE_64(uint64_t) node_to_memfree;
>> >> >> +
>> >> >> +     /*
>> >> >> +      * Array, of size (max_node_index+1)^2, listing memory access distances
>> >> >> +      * between nodes. If an entry has no node distance information (e.g., node
>> >> >> +      * not present) then the value ~0u is written.
>> >> >> +      *
>> >> >> +      * Note that the array rows must be indexed by multiplying by the minimum
>> >> >> +      * of the caller-provided max_node_index and the returned value of
>> >> >> +      * max_node_index. That is, if the largest node index in the system is
>> >> >> +      * smaller than the caller can handle, a smaller 2-d array is constructed
>> >> >> +      * within the space provided by the caller. When this occurs, trailing
>> >> >> +      * space provided by the caller is not modified. If the largest node index
>> >> >> +      * in the system is larger than the caller can handle, then a 2-d array of
>> >> >> +      * the maximum size handleable by the caller is constructed.
>> >> >> +      */
>> >> >> +     GUEST_HANDLE_64(uint32_t) node_to_node_distance;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_cpupool_op */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
>> >> >> +struct xen_sysctl_cpupool_op {
>> >> >> +     uint32_t op;          /* IN */
>> >> >> +     uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
>> >> >> +     uint32_t sched_id;    /* IN: C      OUT: I  */
>> >> >> +     uint32_t domid;       /* IN: M              */
>> >> >> +     uint32_t cpu;         /* IN: AR             */
>> >> >> +     uint32_t n_dom;       /*            OUT: I  */
>> >> >> +     struct xenctl_bitmap cpumap; /*     OUT: IF */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
>> >> >> +
>> >> >> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
>> >> >> +/*
>> >> >> + * This structure is used to pass a new ARINC653 schedule from a
>> >> >> + * privileged domain (ie dom0) to Xen.
>> >> >> + */
>> >> >> +struct xen_sysctl_arinc653_schedule {
>> >> >> +     /* major_frame holds the time for the new schedule's major frame
>> >> >> +     * in nanoseconds. */
>> >> >> +     uint64_aligned_t     major_frame;
>> >> >> +     /* num_sched_entries holds how many of the entries in the
>> >> >> +     * sched_entries[] array are valid. */
>> >> >> +     uint8_t     num_sched_entries;
>> >> >> +     /* The sched_entries array holds the actual schedule entries. */
>> >> >> +     struct {
>> >> >> +             /* dom_handle must match a domain's UUID */
>> >> >> +             xen_domain_handle_t dom_handle;
>> >> >> +             /*
>> >> >> +              * If a domain has multiple VCPUs, vcpu_id specifies which one
>> >> >> +              * this schedule entry applies to. It should be set to 0 if
>> >> >> +              * there is only one VCPU for the domain. */
>> >> >> +             unsigned int vcpu_id;
>> >> >> +             /*
>> >> >> +              * runtime specifies the amount of time that should be allocated
>> >> >> +              * to this VCPU per major frame. It is specified in nanoseconds
>> >> >> +              */
>> >> >> +             uint64_aligned_t runtime;
>> >> >> +     } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
>> >> >> +
>> >> >> +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;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_scheduler_op */
>> >> >> +/* Set or get info? */
>> >> >> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
>> >> >> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
>> >> >> +struct xen_sysctl_scheduler_op {
>> >> >> +     uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
>> >> >> +     uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
>> >> >> +     uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
>> >> >> +     union {
>> >> >> +             struct xen_sysctl_sched_arinc653 {
>> >> >> +                     GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
>> >> >> +             } sched_arinc653;
>> >> >> +             struct xen_sysctl_credit_schedule sched_credit;
>> >> >> +     } u;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_coverage_op */
>> >> >> +/*
>> >> >> + * Get total size of information, to help allocate
>> >> >> + * the buffer. The pointer points to a 32 bit value.
>> >> >> + */
>> >> >> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
>> >> >> +
>> >> >> +/*
>> >> >> + * Read coverage information in a single run
>> >> >> + * You must use a tool to split them.
>> >> >> + */
>> >> >> +#define XEN_SYSCTL_COVERAGE_read           1
>> >> >> +
>> >> >> +/*
>> >> >> + * Reset all the coverage counters to 0
>> >> >> + * No parameters.
>> >> >> + */
>> >> >> +#define XEN_SYSCTL_COVERAGE_reset          2
>> >> >> +
>> >> >> +/*
>> >> >> + * Like XEN_SYSCTL_COVERAGE_read but reset also
>> >> >> + * counters to 0 in a single call.
>> >> >> + */
>> >> >> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
>> >> >> +
>> >> >> +struct xen_sysctl_coverage_op {
>> >> >> +     uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
>> >> >> +     union {
>> >> >> +             uint32_t total_size; /* OUT */
>> >> >> +             GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
>> >> >> +     } u;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
>> >> >> +
>> >> >> +
>> >> >> +struct xen_sysctl {
>> >> >> +     uint32_t cmd;
>> >> >> +#define XEN_SYSCTL_readconsole                    1
>> >> >> +#define XEN_SYSCTL_tbuf_op                        2
>> >> >> +#define XEN_SYSCTL_physinfo                       3
>> >> >> +#define XEN_SYSCTL_sched_id                       4
>> >> >> +#define XEN_SYSCTL_perfc_op                       5
>> >> >> +#define XEN_SYSCTL_debug_keys                     7
>> >> >> +#define XEN_SYSCTL_getcpuinfo                     8
>> >> >> +#define XEN_SYSCTL_availheap                      9
>> >> >> +#define XEN_SYSCTL_get_pmstat                    10
>> >> >> +#define XEN_SYSCTL_cpu_hotplug                   11
>> >> >> +#define XEN_SYSCTL_pm_op                         12
>> >> >> +#define XEN_SYSCTL_page_offline_op               14
>> >> >> +#define XEN_SYSCTL_lockprof_op                   15
>> >> >> +#define XEN_SYSCTL_topologyinfo                  16
>> >> >> +#define XEN_SYSCTL_numainfo                      17
>> >> >> +#define XEN_SYSCTL_cpupool_op                    18
>> >> >> +#define XEN_SYSCTL_scheduler_op                  19
>> >> >> +#define XEN_SYSCTL_coverage_op                   20
>> >> >> +     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
>> >> >> +     union {
>> >> >> +             struct xen_sysctl_readconsole       readconsole;
>> >> >> +             struct xen_sysctl_tbuf_op           tbuf_op;
>> >> >> +             struct xen_sysctl_physinfo          physinfo;
>> >> >> +             struct xen_sysctl_topologyinfo      topologyinfo;
>> >> >> +             struct xen_sysctl_numainfo          numainfo;
>> >> >> +             struct xen_sysctl_sched_id          sched_id;
>> >> >> +             struct xen_sysctl_perfc_op          perfc_op;
>> >> >> +             struct xen_sysctl_debug_keys        debug_keys;
>> >> >> +             struct xen_sysctl_getcpuinfo        getcpuinfo;
>> >> >> +             struct xen_sysctl_availheap         availheap;
>> >> >> +             struct xen_sysctl_get_pmstat        get_pmstat;
>> >> >> +             struct xen_sysctl_cpu_hotplug       cpu_hotplug;
>> >> >> +             struct xen_sysctl_pm_op             pm_op;
>> >> >> +             struct xen_sysctl_page_offline_op   page_offline;
>> >> >> +             struct xen_sysctl_lockprof_op       lockprof_op;
>> >> >> +             struct xen_sysctl_cpupool_op        cpupool_op;
>> >> >> +             struct xen_sysctl_scheduler_op      scheduler_op;
>> >> >> +             struct xen_sysctl_coverage_op       coverage_op;
>> >> >> +             uint8_t                             pad[128];
>> >> >> +     } u;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
>> >> >> +
>> >> >> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */
>> >> >
>> >> > We usually only introduce what we need from Xen header files in Linux:
>> >> > do not copy the entirety of sysctl.h, just introduce what you need.
>> >> I'll do this in the next patch-set.
>> >>
>> >> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> >> >> index 53ec416..cf64566 100644
>> >> >> --- a/include/xen/interface/xen.h
>> >> >> +++ b/include/xen/interface/xen.h
>> >> >> @@ -57,6 +57,7 @@
>> >> >>  #define __HYPERVISOR_event_channel_op     32
>> >> >>  #define __HYPERVISOR_physdev_op           33
>> >> >>  #define __HYPERVISOR_hvm_op               34
>> >> >> +#define __HYPERVISOR_sysctl               35
>> >> >>  #define __HYPERVISOR_tmem_op              38
>> >> >>
>> >> >>  /* Architecture-specific hypercall definitions. */
>> >> >> @@ -526,6 +527,11 @@ struct tmem_op {
>> >> >>
>> >> >>  DEFINE_GUEST_HANDLE(u64);
>> >> >>
>> >> >> +struct xenctl_bitmap {
>> >> >> +     GUEST_HANDLE_64(uint8_t) bitmap;
>> >> >> +     uint32_t nr_bits;
>> >> >> +};
>> >> >> +
>> >> >>  #else /* __ASSEMBLY__ */
>> >> >>
>> >> >>  /* In assembly code we cannot use C numeric constant suffixes. */
>> >> >> --
>> >> >> 1.9.1
>> >> >>
>> >>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:33:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmP43-0006PU-1j; Thu, 06 Nov 2014 15:33:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmP41-0006PA-8d
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:33:33 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	A0/2E-16982-CC49B545; Thu, 06 Nov 2014 15:33:32 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415288009!10873047!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4815 invoked from network); 6 Nov 2014 15:33:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:33:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190219348"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:33:18 -0500
Received: from etemp.uk.xensource.com ([10.80.228.66]
	helo=etemp.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <paul.durrant@citrix.com>)	id 1XmP3l-0000tn-VG;
	Thu, 06 Nov 2014 15:33:17 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 6 Nov 2014 15:33:15 +0000
Message-ID: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Paul Durrant <paul.durrant@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

HVM guests have always been confined to using the domain callback
via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
which is an IOAPIC vector and is only used if the event channel is
bound to vcpu 0.
This patch adds a new HVM op allowing a guest to specify a local
APIC vector to use as an upcall notification for a specific vcpu.
This therefore allows a guest which sets a vector for a vcpu
other than 0 to then bind event channels to that vcpu.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c          |   39 +++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/hvm/irq.c          |    9 +++++++++
 xen/include/asm-x86/hvm/vcpu.h  |    1 +
 xen/include/public/hvm/hvm_op.h |   20 ++++++++++++++++++++
 4 files changed, 69 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 78f519d..70845b0 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5458,6 +5458,40 @@ static int hvmop_destroy_ioreq_server(
     return rc;
 }
 
+static int hvmop_set_evtchn_upcall_vector(
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t) uop)
+{
+    xen_hvm_set_evtchn_upcall_vector_t op;
+    struct domain *d;
+    struct vcpu *v;
+    int rc;
+
+    if ( copy_from_guest(&op, uop, 1) )
+        return -EFAULT;
+
+    d = rcu_lock_current_domain();
+
+    rc = -EINVAL;
+    if ( !is_hvm_domain(d) )
+        goto out;
+
+    if ( op.vector < 0x10 )
+        goto out;
+
+    rc = -ENOENT;
+    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
+        goto out;
+
+    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
+
+    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
+    rc = 0;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 #define HVMOP_op_mask 0xff
 
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
@@ -5499,6 +5533,11 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
             guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
         break;
     
+    case HVMOP_set_evtchn_upcall_vector:
+        rc = hvmop_set_evtchn_upcall_vector(
+            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
+        break;
+    
     case HVMOP_set_param:
     case HVMOP_get_param:
     {
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 35f4f94..3e4c0b4 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
     spin_unlock(&d->arch.hvm_domain.irq_lock);
 }
 
+static void hvm_set_upcall_irq(struct vcpu *v)
+{
+    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
+
+    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
+}
+
 static void hvm_set_callback_irq_level(struct vcpu *v)
 {
     struct domain *d = v->domain;
@@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
 
     if ( is_hvm_pv_evtchn_vcpu(v) )
         vcpu_kick(v);
+    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
+        hvm_set_upcall_irq(v);
     else if ( v->vcpu_id == 0 )
         hvm_set_callback_irq_level(v);
 }
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..edd4523 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -160,6 +160,7 @@ struct hvm_vcpu {
     } u;
 
     struct tasklet      assert_evtchn_irq_tasklet;
+    u8                  evtchn_upcall_vector;
 
     struct nestedvcpu   nvcpu;
 
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index eeb0a60..cfbf85d 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -369,6 +369,26 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
 
 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
 
+#if defined(__i386__) || defined(__x86_64__)
+
+/*
+ * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used for event
+ *                                 channel upcalls on the specified <vcpu>. If set,
+ *                                 this vector will be used in preference to the
+ *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
+ *                                 and hence allows HVM guests to bind event
+ *                                 event channels to a vcpu other than 0.
+ */
+#define HVMOP_set_evtchn_upcall_vector 23
+struct xen_hvm_set_evtchn_upcall_vector {
+    uint32_t vcpu;
+    uint8_t vector;
+};
+typedef struct xen_hvm_set_evtchn_upcall_vector xen_hvm_set_evtchn_upcall_vector_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
+
+#endif /* defined(__i386__) || defined(__x86_64__) */
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:33:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmP3q-0006Nr-GF; Thu, 06 Nov 2014 15:33:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmP3o-0006Nl-Nm
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:33:21 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	BC/A3-26858-0C49B545; Thu, 06 Nov 2014 15:33:20 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415287995!10848697!1
X-Originating-IP: [64.18.0.20]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14365 invoked from network); 6 Nov 2014 15:33:17 -0000
Received: from exprod5og110.obsmtp.com (HELO exprod5og110.obsmtp.com)
	(64.18.0.20)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:33:17 -0000
Received: from mail-qc0-f180.google.com ([209.85.216.180]) (using TLSv1) by
	exprod5ob110.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuUuv6pZva8TYzBF+1812hPA7vgn+nx@postini.com;
	Thu, 06 Nov 2014 07:33:17 PST
Received: by mail-qc0-f180.google.com with SMTP id o8so913254qcw.39
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:33:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=1hCJPh+dSvRm8nP7wichOPegqY6oq8uoCaUArpVVeEQ=;
	b=YZX3EM/TyTABrKsI9BzG4kfNdmjLnZOWuHWyzhbtDEk5yip0iD89+X0hUnIOjYpVKd
	uggYBj79kbgyehXaYHcbcWh8rI3aEeygn0Kj/jLa0nTt/2yjn9y9Hh+vRTeFo/93r2/G
	3YMGaq9XEo3oBs7cx6leu02b1B/cYQhXtCQys=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=1hCJPh+dSvRm8nP7wichOPegqY6oq8uoCaUArpVVeEQ=;
	b=dPeoSqaSzX85Xnu9IFdmdDQo8ciHP7yEKeE97bOIYK7fuqcKJ4w/vtueTv6RTt0fkv
	/J1/s7Ag71nd4Lly7hkGIcREipuCsS+ROYjc3T4kY+7d7CnI7gAHx/Y7E3TP0ylwEYW6
	MN37fO883MxJXf2VG10AefvUqW2yi00K5nwjUwsXukVs30+f5mPCe//VFtn1AMbIwh6L
	sFiYTzCOatyZGQ/+ay7UmS+H75aCfL5Yaq1Sbkop54qiRgdJu0NzguUo5ZgSIX5cOINj
	5jUbtG/SIwxlhXN1npInpL/HLZkcfwkdwOZ9x5GND+UnW5tPRb6XhuJXsuv2K64HLSai
	LRUQ==
X-Gm-Message-State: ALoCoQm8ttxqg3qR8++eJd9ClCII5bD4Kysy1Mtc+OyFKZthjRsZcYv19K9lqgwf3yvN/wK/b4/qKx3d4WJ14DYt+W435rOWif9jbAFrEmcKhVN8P56IcFTJilVEDhz3VUrH0c0lh/epRAPp/3sRQDwzusrp92/+fQ==
X-Received: by 10.224.127.133 with SMTP id g5mr8104719qas.24.1415287994439;
	Thu, 06 Nov 2014 07:33:14 -0800 (PST)
X-Received: by 10.224.127.133 with SMTP id g5mr8104680qas.24.1415287994179;
	Thu, 06 Nov 2014 07:33:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:32:53 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061528020.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041615240.22875@kaball.uk.xensource.com>
	<CAN58jis31KHyoA2LcQYqJk7+Ez1zsVs6PeHeY4LEG13+=oejNA@mail.gmail.com>
	<alpine.DEB.2.02.1411061515400.22875@kaball.uk.xensource.com>
	<CAN58jivVbpc4exAfq_g9NswoQycdNUdSJQwa=msCXKnuF4=f9w@mail.gmail.com>
	<alpine.DEB.2.02.1411061528020.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:32:53 +0200
Message-ID: <CAN58jitykW8L8s0HexcV7ZeDscyem_1nvye8rbt=7XjYjBnQmw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 2/9] xen/arm: implement
	HYPERVISOR_sysctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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'll do this in the next patch-set.

Oleksandr Dmytryshyn | Product Engineering and Development
GlobalLogic
M +38.067.382.2525
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Thu, Nov 6, 2014 at 5:29 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >> >
>> >> > Why?
>> >> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
>> >
>> > Sorry, I meant why are you introducing HYPERVISOR_sysctl?
>> I use it to get real physical CPUs counter.
>> Also I'll implement a new sysctl operation: XEN_SYSCTL_cpufreq_op
>> Kernel will use this op to start/stop cpufreq notification
>> events sending.
>
> Please add the exaplanation to the commit message. Also don't add
> structs and definitions that you don't need, such as
> xen_sysctl_readconsole and XEN_SYSCTL_SCHEDOP_putinfo.
>
>
>> >> >>  arch/arm/include/asm/xen/hypercall.h |   1 +
>> >> >>  arch/arm/include/asm/xen/interface.h |   2 +
>> >> >>  arch/arm/xen/enlighten.c             |   1 +
>> >> >>  arch/arm/xen/hypercall.S             |   1 +
>> >> >>  include/xen/interface/sysctl.h       | 646 +++++++++++++++++++++++++++++++++++
>> >> >>  include/xen/interface/xen.h          |   6 +
>> >> >>  6 files changed, 657 insertions(+)
>> >> >>  create mode 100644 include/xen/interface/sysctl.h
>> >> >>
>> >> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> >> >> index c817c56..751869eb 100644
>> >> >> --- a/arch/arm/include/asm/xen/hypercall.h
>> >> >> +++ b/arch/arm/include/asm/xen/hypercall.h
>> >> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>> >> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>> >> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>> >> >>  int HYPERVISOR_tmem_op(void *arg);
>> >> >> +int HYPERVISOR_sysctl(void *arg);
>> >> >>
>> >> >>  static inline void
>> >> >>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
>> >> >> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
>> >> >> index 1151188..acf4b7a 100644
>> >> >> --- a/arch/arm/include/asm/xen/interface.h
>> >> >> +++ b/arch/arm/include/asm/xen/interface.h
>> >> >> @@ -19,6 +19,7 @@
>> >> >>       __DEFINE_GUEST_HANDLE(name, struct name)
>> >> >>  #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
>> >> >>  #define GUEST_HANDLE(name)        __guest_handle_ ## name
>> >> >> +#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
>> >> >>
>> >> >>  #define set_xen_guest_handle(hnd, val)                       \
>> >> >>       do {                                            \
>> >> >> @@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
>> >> >>  DEFINE_GUEST_HANDLE(void);
>> >> >>  DEFINE_GUEST_HANDLE(uint64_t);
>> >> >>  DEFINE_GUEST_HANDLE(uint32_t);
>> >> >> +DEFINE_GUEST_HANDLE(uint8_t);
>> >> >>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>> >> >>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>> >> >>
>> >> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> >> >> index eb0d851..675f17a 100644
>> >> >> --- a/arch/arm/xen/enlighten.c
>> >> >> +++ b/arch/arm/xen/enlighten.c
>> >> >> @@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> >> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>> >> >>  EXPORT_SYMBOL_GPL(privcmd_call);
>> >> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> >> >> index d1cf7b7..a1276df 100644
>> >> >> --- a/arch/arm/xen/hypercall.S
>> >> >> +++ b/arch/arm/xen/hypercall.S
>> >> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>> >> >>  HYPERCALL2(physdev_op);
>> >> >>  HYPERCALL3(vcpu_op);
>> >> >>  HYPERCALL1(tmem_op);
>> >> >> +HYPERCALL1(sysctl);
>> >> >>
>> >> >>  ENTRY(privcmd_call)
>> >> >>       stmdb sp!, {r4}
>> >> >> diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
>> >> >> new file mode 100644
>> >> >> index 0000000..1a8cf7a
>> >> >> --- /dev/null
>> >> >> +++ b/include/xen/interface/sysctl.h
>> >> >> @@ -0,0 +1,646 @@
>> >> >> +/******************************************************************************
>> >> >> + * sysctl.h
>> >> >> + *
>> >> >> + * System management operations. For use by node control stack.
>> >> >> + *
>> >> >> + * Reused from xen: xen/include/public/sysctl.h
>> >> >> + *
>> >> >> + * Permission is hereby granted, free of charge, to any person obtaining a copy
>> >> >> + * of this software and associated documentation files (the "Software"), to
>> >> >> + * deal in the Software without restriction, including without limitation the
>> >> >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
>> >> >> + * sell copies of the Software, and to permit persons to whom the Software is
>> >> >> + * furnished to do so, subject to the following conditions:
>> >> >> + *
>> >> >> + * The above copyright notice and this permission notice shall be included in
>> >> >> + * all copies or substantial portions of the Software.
>> >> >> + *
>> >> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> >> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> >> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
>> >> >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> >> >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> >> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> >> >> + * DEALINGS IN THE SOFTWARE.
>> >> >> + *
>> >> >> + * Copyright (c) 2002-2006, K Fraser
>> >> >> + * Copyright (c) 2014, GlobalLogic Inc.
>> >> >> + */
>> >> >> +
>> >> >> +#ifndef __XEN_PUBLIC_SYSCTL_H__
>> >> >> +#define __XEN_PUBLIC_SYSCTL_H__
>> >> >> +
>> >> >> +#include <xen/interface/xen.h>
>> >> >> +
>> >> >> +#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
>> >> >> +
>> >> >> +/*
>> >> >> + * Read console content from Xen buffer ring.
>> >> >> + */
>> >> >> +/* XEN_SYSCTL_readconsole */
>> >> >> +struct xen_sysctl_readconsole {
>> >> >> +     /* IN: Non-zero -> clear after reading. */
>> >> >> +     uint8_t clear;
>> >> >> +     /* IN: Non-zero -> start index specified by @index field. */
>> >> >> +     uint8_t incremental;
>> >> >> +     uint8_t pad0, pad1;
>> >> >> +     /*
>> >> >> +     * IN:  Start index for consuming from ring buffer (if @incremental);
>> >> >> +     * OUT: End index after consuming from ring buffer.
>> >> >> +     */
>> >> >> +     uint32_t index;
>> >> >> +     /* IN: Virtual address to write console data. */
>> >> >> +     GUEST_HANDLE_64(char) buffer;
>> >> >> +     /* IN: Size of buffer; OUT: Bytes written to buffer. */
>> >> >> +     uint32_t count;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_readconsole);
>> >> >> +
>> >> >> +/* Get trace buffers machine base address */
>> >> >> +/* XEN_SYSCTL_tbuf_op */
>> >> >> +struct xen_sysctl_tbuf_op {
>> >> >> +    /* IN variables */
>> >> >> +#define XEN_SYSCTL_TBUFOP_get_info     0
>> >> >> +#define XEN_SYSCTL_TBUFOP_set_cpu_mask 1
>> >> >> +#define XEN_SYSCTL_TBUFOP_set_evt_mask 2
>> >> >> +#define XEN_SYSCTL_TBUFOP_set_size     3
>> >> >> +#define XEN_SYSCTL_TBUFOP_enable       4
>> >> >> +#define XEN_SYSCTL_TBUFOP_disable      5
>> >> >> +     uint32_t cmd;
>> >> >> +     /* IN/OUT variables */
>> >> >> +     struct xenctl_bitmap cpu_mask;
>> >> >> +     uint32_t             evt_mask;
>> >> >> +     /* OUT variables */
>> >> >> +     uint64_aligned_t buffer_mfn;
>> >> >> +     uint32_t size;  /* Also an IN variable! */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_tbuf_op);
>> >> >> +
>> >> >> +/*
>> >> >> + * Get physical information about the host machine
>> >> >> + */
>> >> >> +/* XEN_SYSCTL_physinfo */
>> >> >> + /* (x86) The platform supports HVM guests. */
>> >> >> +#define _XEN_SYSCTL_PHYSCAP_hvm          0
>> >> >> +#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
>> >> >> + /* (x86) The platform supports HVM-guest direct access to I/O devices. */
>> >> >> +#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
>> >> >> +#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
>> >> >> +struct xen_sysctl_physinfo {
>> >> >> +     uint32_t threads_per_core;
>> >> >> +     uint32_t cores_per_socket;
>> >> >> +     uint32_t nr_cpus;     /* # CPUs currently online */
>> >> >> +     uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
>> >> >> +     uint32_t nr_nodes;    /* # nodes currently online */
>> >> >> +     uint32_t max_node_id; /* Largest possible node ID on this host */
>> >> >> +     uint32_t cpu_khz;
>> >> >> +     uint64_aligned_t total_pages;
>> >> >> +     uint64_aligned_t free_pages;
>> >> >> +     uint64_aligned_t scrub_pages;
>> >> >> +     uint64_aligned_t outstanding_pages;
>> >> >> +     uint32_t hw_cap[8];
>> >> >> +
>> >> >> +     /* XEN_SYSCTL_PHYSCAP_??? */
>> >> >> +     uint32_t capabilities;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
>> >> >> +
>> >> >> +/*
>> >> >> + * Get the ID of the current scheduler.
>> >> >> + */
>> >> >> +/* XEN_SYSCTL_sched_id */
>> >> >> +struct xen_sysctl_sched_id {
>> >> >> +     /* OUT variable */
>> >> >> +     uint32_t sched_id;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_sched_id);
>> >> >> +
>> >> >> +/* Interface for controlling Xen software performance counters. */
>> >> >> +/* XEN_SYSCTL_perfc_op */
>> >> >> +/* Sub-operations: */
>> >> >> +#define XEN_SYSCTL_PERFCOP_reset 1   /* Reset all counters to zero. */
>> >> >> +#define XEN_SYSCTL_PERFCOP_query 2   /* Get perfctr information. */
>> >> >> +struct xen_sysctl_perfc_desc {
>> >> >> +     char         name[80];           /* name of perf counter */
>> >> >> +     uint32_t     nr_vals;            /* number of values for this counter */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_desc);
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_val);
>> >> >> +
>> >> >> +struct xen_sysctl_perfc_op {
>> >> >> +     /* IN variables. */
>> >> >> +     uint32_t       cmd;                /*  XEN_SYSCTL_PERFCOP_??? */
>> >> >> +     /* OUT variables. */
>> >> >> +     uint32_t       nr_counters;       /*  number of counters description  */
>> >> >> +     uint32_t       nr_vals;           /*  number of values  */
>> >> >> +     /* counter information (or NULL) */
>> >> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_desc) desc;
>> >> >> +     /* counter values (or NULL) */
>> >> >> +     GUEST_HANDLE_64(xen_sysctl_perfc_val) val;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_perfc_op);
>> >> >> +
>> >> >> +/* Inject debug keys into Xen. */
>> >> >> +/* XEN_SYSCTL_debug_keys */
>> >> >> +struct xen_sysctl_debug_keys {
>> >> >> +     /* IN variables. */
>> >> >> +     GUEST_HANDLE_64(char) keys;
>> >> >> +     uint32_t nr_keys;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_debug_keys);
>> >> >> +
>> >> >> +/* Get physical CPU information. */
>> >> >> +/* XEN_SYSCTL_getcpuinfo */
>> >> >> +struct xen_sysctl_cpuinfo {
>> >> >> +     uint64_aligned_t idletime;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpuinfo);
>> >> >> +struct xen_sysctl_getcpuinfo {
>> >> >> +     /* IN variables. */
>> >> >> +     uint32_t max_cpus;
>> >> >> +     GUEST_HANDLE_64(xen_sysctl_cpuinfo) info;
>> >> >> +     /* OUT variables. */
>> >> >> +     uint32_t nr_cpus;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_getcpuinfo);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_availheap */
>> >> >> +struct xen_sysctl_availheap {
>> >> >> +     /* IN variables. */
>> >> >> +     uint32_t min_bitwidth; /* Smallest address width (zero if don't care) */
>> >> >> +     uint32_t max_bitwidth; /* Largest address width (zero if don't care)  */
>> >> >> +     int32_t  node;         /* NUMA node of interest (-1 for all nodes)   */
>> >> >> +     /* OUT variables. */
>> >> >> +     uint64_aligned_t avail_bytes;/* Bytes available in the specified region */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_availheap);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_get_pmstat */
>> >> >> +struct pm_px_val {
>> >> >> +     uint64_aligned_t freq;        /* Px core frequency */
>> >> >> +     uint64_aligned_t residency;   /* Px residency time */
>> >> >> +     uint64_aligned_t count;       /* Px transition count */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_val);
>> >> >> +
>> >> >> +struct pm_px_stat {
>> >> >> +     uint8_t total;        /* total Px states */
>> >> >> +     uint8_t usable;       /* usable Px states */
>> >> >> +     uint8_t last;         /* last Px state */
>> >> >> +     uint8_t cur;          /* current Px state */
>> >> >> +     GUEST_HANDLE_64(uint64_t) trans_pt;   /* Px transition table */
>> >> >> +     GUEST_HANDLE_64(pm_px_val) pt;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(pm_px_stat);
>> >> >> +
>> >> >> +struct pm_cx_stat {
>> >> >> +     uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
>> >> >> +     uint32_t last;  /* last Cx state */
>> >> >> +     uint64_aligned_t idle_time;                 /* idle time from boot */
>> >> >> +     GUEST_HANDLE_64(uint64_t) triggers;    /* Cx trigger counts */
>> >> >> +     GUEST_HANDLE_64(uint64_t) residencies; /* Cx residencies */
>> >> >> +     uint64_aligned_t pc2;
>> >> >> +     uint64_aligned_t pc3;
>> >> >> +     uint64_aligned_t pc6;
>> >> >> +     uint64_aligned_t pc7;
>> >> >> +     uint64_aligned_t cc3;
>> >> >> +     uint64_aligned_t cc6;
>> >> >> +     uint64_aligned_t cc7;
>> >> >> +};
>> >> >> +
>> >> >> +struct xen_sysctl_get_pmstat {
>> >> >> +#define PMSTAT_CATEGORY_MASK 0xf0
>> >> >> +#define PMSTAT_PX            0x10
>> >> >> +#define PMSTAT_CX            0x20
>> >> >> +#define PMSTAT_get_max_px    (PMSTAT_PX | 0x1)
>> >> >> +#define PMSTAT_get_pxstat    (PMSTAT_PX | 0x2)
>> >> >> +#define PMSTAT_reset_pxstat  (PMSTAT_PX | 0x3)
>> >> >> +#define PMSTAT_get_max_cx    (PMSTAT_CX | 0x1)
>> >> >> +#define PMSTAT_get_cxstat    (PMSTAT_CX | 0x2)
>> >> >> +#define PMSTAT_reset_cxstat  (PMSTAT_CX | 0x3)
>> >> >> +     uint32_t type;
>> >> >> +     uint32_t cpuid;
>> >> >> +     union {
>> >> >> +             struct pm_px_stat getpx;
>> >> >> +             struct pm_cx_stat getcx;
>> >> >> +             /* other struct for tx, etc */
>> >> >> +     } u;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_get_pmstat);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_cpu_hotplug */
>> >> >> +struct xen_sysctl_cpu_hotplug {
>> >> >> +     /* IN variables */
>> >> >> +     uint32_t cpu;   /* Physical cpu. */
>> >> >> +#define XEN_SYSCTL_CPU_HOTPLUG_ONLINE  0
>> >> >> +#define XEN_SYSCTL_CPU_HOTPLUG_OFFLINE 1
>> >> >> +     uint32_t op;    /* hotplug opcode */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpu_hotplug);
>> >> >> +
>> >> >> +/*
>> >> >> + * Get/set xen power management, include
>> >> >> + * 1. cpufreq governors and related parameters
>> >> >> + */
>> >> >> +/* XEN_SYSCTL_pm_op */
>> >> >> +struct xen_userspace {
>> >> >> +     uint32_t scaling_setspeed;
>> >> >> +};
>> >> >> +
>> >> >> +struct xen_ondemand {
>> >> >> +     uint32_t sampling_rate_max;
>> >> >> +     uint32_t sampling_rate_min;
>> >> >> +
>> >> >> +     uint32_t sampling_rate;
>> >> >> +     uint32_t up_threshold;
>> >> >> +};
>> >> >> +
>> >> >> +/*
>> >> >> + * cpufreq para name of this structure named
>> >> >> + * same as sysfs file name of native linux
>> >> >> + */
>> >> >> +#define CPUFREQ_NAME_LEN 16
>> >> >> +struct xen_get_cpufreq_para {
>> >> >> +     /* IN/OUT variable */
>> >> >> +     uint32_t cpu_num;
>> >> >> +     uint32_t freq_num;
>> >> >> +     uint32_t gov_num;
>> >> >> +
>> >> >> +     /* for all governors */
>> >> >> +     /* OUT variable */
>> >> >> +     GUEST_HANDLE_64(uint32_t) affected_cpus;
>> >> >> +     GUEST_HANDLE_64(uint32_t) scaling_available_frequencies;
>> >> >> +     GUEST_HANDLE_64(char)   scaling_available_governors;
>> >> >> +     char scaling_driver[CPUFREQ_NAME_LEN];
>> >> >> +
>> >> >> +     uint32_t cpuinfo_cur_freq;
>> >> >> +     uint32_t cpuinfo_max_freq;
>> >> >> +     uint32_t cpuinfo_min_freq;
>> >> >> +     uint32_t scaling_cur_freq;
>> >> >> +
>> >> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> >> >> +     uint32_t scaling_max_freq;
>> >> >> +     uint32_t scaling_min_freq;
>> >> >> +
>> >> >> +     /* for specific governor */
>> >> >> +     union {
>> >> >> +             struct  xen_userspace userspace;
>> >> >> +             struct  xen_ondemand ondemand;
>> >> >> +     } u;
>> >> >> +
>> >> >> +     int32_t turbo_enabled;
>> >> >> +};
>> >> >> +
>> >> >> +struct xen_set_cpufreq_gov {
>> >> >> +     char scaling_governor[CPUFREQ_NAME_LEN];
>> >> >> +};
>> >> >> +
>> >> >> +struct xen_set_cpufreq_para {
>> >> >> +     #define SCALING_MAX_FREQ           1
>> >> >> +     #define SCALING_MIN_FREQ           2
>> >> >> +     #define SCALING_SETSPEED           3
>> >> >> +     #define SAMPLING_RATE              4
>> >> >> +     #define UP_THRESHOLD               5
>> >> >> +
>> >> >> +     uint32_t ctrl_type;
>> >> >> +     uint32_t ctrl_value;
>> >> >> +};
>> >> >> +
>> >> >> +struct xen_sysctl_pm_op {
>> >> >> +     #define PM_PARA_CATEGORY_MASK      0xf0
>> >> >> +     #define CPUFREQ_PARA               0x10
>> >> >> +
>> >> >> +     /* cpufreq command type */
>> >> >> +     #define GET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x01)
>> >> >> +     #define SET_CPUFREQ_GOV            (CPUFREQ_PARA | 0x02)
>> >> >> +     #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
>> >> >> +     #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
>> >> >> +
>> >> >> +     /* set/reset scheduler power saving option */
>> >> >> +     #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
>> >> >> +
>> >> >> +     /* cpuidle max_cstate access command */
>> >> >> +     #define XEN_SYSCTL_pm_op_get_max_cstate       0x22
>> >> >> +     #define XEN_SYSCTL_pm_op_set_max_cstate       0x23
>> >> >> +
>> >> >> +     /* set scheduler migration cost value */
>> >> >> +     #define XEN_SYSCTL_pm_op_set_vcpu_migration_delay   0x24
>> >> >> +     #define XEN_SYSCTL_pm_op_get_vcpu_migration_delay   0x25
>> >> >> +
>> >> >> +     /* enable/disable turbo mode when in dbs governor */
>> >> >> +     #define XEN_SYSCTL_pm_op_enable_turbo               0x26
>> >> >> +     #define XEN_SYSCTL_pm_op_disable_turbo              0x27
>> >> >> +
>> >> >> +     uint32_t cmd;
>> >> >> +     uint32_t cpuid;
>> >> >> +     union {
>> >> >> +             struct xen_get_cpufreq_para get_para;
>> >> >> +             struct xen_set_cpufreq_gov  set_gov;
>> >> >> +             struct xen_set_cpufreq_para set_para;
>> >> >> +             uint64_aligned_t get_avgfreq;
>> >> >> +             uint32_t                    set_sched_opt_smt;
>> >> >> +             uint32_t                    get_max_cstate;
>> >> >> +             uint32_t                    set_max_cstate;
>> >> >> +             uint32_t                    get_vcpu_migration_delay;
>> >> >> +             uint32_t                    set_vcpu_migration_delay;
>> >> >> +     } u;
>> >> >> +};
>> >> >> +
>> >> >> +/* XEN_SYSCTL_page_offline_op */
>> >> >> +struct xen_sysctl_page_offline_op {
>> >> >> +     /* IN: range of page to be offlined */
>> >> >> +#define sysctl_page_offline     1
>> >> >> +#define sysctl_page_online      2
>> >> >> +#define sysctl_query_page_offline  3
>> >> >> +     uint32_t cmd;
>> >> >> +     uint32_t start;
>> >> >> +     uint32_t end;
>> >> >> +     /* OUT: result of page offline request */
>> >> >> +     /*
>> >> >> +     * bit 0~15: result flags
>> >> >> +     * bit 16~31: owner
>> >> >> +     */
>> >> >> +     GUEST_HANDLE(uint32_t) status;
>> >> >> +};
>> >> >> +
>> >> >> +#define PG_OFFLINE_STATUS_MASK    (0xFFUL)
>> >> >> +
>> >> >> +/* The result is invalid, i.e. HV does not handle it */
>> >> >> +#define PG_OFFLINE_INVALID   (0x1UL << 0)
>> >> >> +
>> >> >> +#define PG_OFFLINE_OFFLINED  (0x1UL << 1)
>> >> >> +#define PG_OFFLINE_PENDING   (0x1UL << 2)
>> >> >> +#define PG_OFFLINE_FAILED    (0x1UL << 3)
>> >> >> +#define PG_OFFLINE_AGAIN     (0x1UL << 4)
>> >> >> +
>> >> >> +#define PG_ONLINE_FAILED     PG_OFFLINE_FAILED
>> >> >> +#define PG_ONLINE_ONLINED    PG_OFFLINE_OFFLINED
>> >> >> +
>> >> >> +#define PG_OFFLINE_STATUS_OFFLINED              (0x1UL << 1)
>> >> >> +#define PG_OFFLINE_STATUS_ONLINE                (0x1UL << 2)
>> >> >> +#define PG_OFFLINE_STATUS_OFFLINE_PENDING       (0x1UL << 3)
>> >> >> +#define PG_OFFLINE_STATUS_BROKEN                (0x1UL << 4)
>> >> >> +
>> >> >> +#define PG_OFFLINE_MISC_MASK    (0xFFUL << 4)
>> >> >> +
>> >> >> +/* valid when PG_OFFLINE_FAILED or PG_OFFLINE_PENDING */
>> >> >> +#define PG_OFFLINE_XENPAGE   (0x1UL << 8)
>> >> >> +#define PG_OFFLINE_DOM0PAGE  (0x1UL << 9)
>> >> >> +#define PG_OFFLINE_ANONYMOUS (0x1UL << 10)
>> >> >> +#define PG_OFFLINE_NOT_CONV_RAM   (0x1UL << 11)
>> >> >> +#define PG_OFFLINE_OWNED     (0x1UL << 12)
>> >> >> +
>> >> >> +#define PG_OFFLINE_BROKEN    (0x1UL << 13)
>> >> >> +#define PG_ONLINE_BROKEN     PG_OFFLINE_BROKEN
>> >> >> +
>> >> >> +#define PG_OFFLINE_OWNER_SHIFT 16
>> >> >> +
>> >> >> +/* XEN_SYSCTL_lockprof_op */
>> >> >> +/* Sub-operations: */
>> >> >> +#define XEN_SYSCTL_LOCKPROF_reset 1   /* Reset all profile data to zero. */
>> >> >> +#define XEN_SYSCTL_LOCKPROF_query 2   /* Get lock profile information. */
>> >> >> +/* Record-type: */
>> >> >> +#define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
>> >> >> +#define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
>> >> >> +#define LOCKPROF_TYPE_N           2   /* number of types */
>> >> >> +struct xen_sysctl_lockprof_data {
>> >> >> +     char     name[40];   /* lock name (may include up to 2 %d specifiers) */
>> >> >> +     int32_t  type;       /* LOCKPROF_TYPE_??? */
>> >> >> +     int32_t  idx;        /* index (e.g. domain id) */
>> >> >> +     uint64_aligned_t lock_cnt;     /* # of locking succeeded */
>> >> >> +     uint64_aligned_t block_cnt;    /* # of wait for lock */
>> >> >> +     uint64_aligned_t lock_time;    /* nsecs lock held */
>> >> >> +     uint64_aligned_t block_time;   /* nsecs waited for lock */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_data);
>> >> >> +
>> >> >> +struct xen_sysctl_lockprof_op {
>> >> >> +     /* IN variables. */
>> >> >> +     uint32_t       cmd;               /* XEN_SYSCTL_LOCKPROF_??? */
>> >> >> +     uint32_t       max_elem;          /* size of output buffer */
>> >> >> +     /* OUT variables (query only). */
>> >> >> +     uint32_t       nr_elem;           /* number of elements available */
>> >> >> +     uint64_aligned_t time;            /* nsecs of profile measurement */
>> >> >> +     /* profile information (or NULL) */
>> >> >> +     GUEST_HANDLE_64(xen_sysctl_lockprof_data) data;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_lockprof_op);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_topologyinfo */
>> >> >> +#define INVALID_TOPOLOGY_ID  (~0U)
>> >> >> +struct xen_sysctl_topologyinfo {
>> >> >> +     /*
>> >> >> +      * IN: maximum addressable entry in the caller-provided arrays.
>> >> >> +      * OUT: largest cpu identifier in the system.
>> >> >> +      * If OUT is greater than IN then the arrays are truncated!
>> >> >> +      * If OUT is leass than IN then the array tails are not written by
>> >> >> +      * sysctl.
>> >> >> +      */
>> >> >> +     uint32_t max_cpu_index;
>> >> >> +
>> >> >> +     /*
>> >> >> +      * If not NULL, these arrays are filled with core/socket/node identifier
>> >> >> +      * for each cpu.
>> >> >> +      * If a cpu has no core/socket/node information (e.g., cpu not present)
>> >> >> +      * then the sentinel value ~0u is written to each array.
>> >> >> +      * The number of array elements written by the sysctl is:
>> >> >> +      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
>> >> >> +      */
>> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_core;
>> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_socket;
>> >> >> +     GUEST_HANDLE_64(uint32_t) cpu_to_node;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_topologyinfo);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_numainfo */
>> >> >> +#define INVALID_NUMAINFO_ID (~0U)
>> >> >> +struct xen_sysctl_numainfo {
>> >> >> +     /*
>> >> >> +      * IN: maximum addressable entry in the caller-provided arrays.
>> >> >> +      * OUT: largest node identifier in the system.
>> >> >> +      * If OUT is greater than IN then the arrays are truncated!
>> >> >> +      */
>> >> >> +     uint32_t max_node_index;
>> >> >> +
>> >> >> +     /* NB. Entries are 0 if node is not present. */
>> >> >> +     GUEST_HANDLE_64(uint64_t) node_to_memsize;
>> >> >> +     GUEST_HANDLE_64(uint64_t) node_to_memfree;
>> >> >> +
>> >> >> +     /*
>> >> >> +      * Array, of size (max_node_index+1)^2, listing memory access distances
>> >> >> +      * between nodes. If an entry has no node distance information (e.g., node
>> >> >> +      * not present) then the value ~0u is written.
>> >> >> +      *
>> >> >> +      * Note that the array rows must be indexed by multiplying by the minimum
>> >> >> +      * of the caller-provided max_node_index and the returned value of
>> >> >> +      * max_node_index. That is, if the largest node index in the system is
>> >> >> +      * smaller than the caller can handle, a smaller 2-d array is constructed
>> >> >> +      * within the space provided by the caller. When this occurs, trailing
>> >> >> +      * space provided by the caller is not modified. If the largest node index
>> >> >> +      * in the system is larger than the caller can handle, then a 2-d array of
>> >> >> +      * the maximum size handleable by the caller is constructed.
>> >> >> +      */
>> >> >> +     GUEST_HANDLE_64(uint32_t) node_to_node_distance;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_numainfo);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_cpupool_op */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_CREATE                1  /* C */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_DESTROY               2  /* D */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_INFO                  3  /* I */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_ADDCPU                4  /* A */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_RMCPU                 5  /* R */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN            6  /* M */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_OP_FREEINFO              7  /* F */
>> >> >> +#define XEN_SYSCTL_CPUPOOL_PAR_ANY     0xFFFFFFFF
>> >> >> +struct xen_sysctl_cpupool_op {
>> >> >> +     uint32_t op;          /* IN */
>> >> >> +     uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
>> >> >> +     uint32_t sched_id;    /* IN: C      OUT: I  */
>> >> >> +     uint32_t domid;       /* IN: M              */
>> >> >> +     uint32_t cpu;         /* IN: AR             */
>> >> >> +     uint32_t n_dom;       /*            OUT: I  */
>> >> >> +     struct xenctl_bitmap cpumap; /*     OUT: IF */
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpupool_op);
>> >> >> +
>> >> >> +#define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
>> >> >> +/*
>> >> >> + * This structure is used to pass a new ARINC653 schedule from a
>> >> >> + * privileged domain (ie dom0) to Xen.
>> >> >> + */
>> >> >> +struct xen_sysctl_arinc653_schedule {
>> >> >> +     /* major_frame holds the time for the new schedule's major frame
>> >> >> +     * in nanoseconds. */
>> >> >> +     uint64_aligned_t     major_frame;
>> >> >> +     /* num_sched_entries holds how many of the entries in the
>> >> >> +     * sched_entries[] array are valid. */
>> >> >> +     uint8_t     num_sched_entries;
>> >> >> +     /* The sched_entries array holds the actual schedule entries. */
>> >> >> +     struct {
>> >> >> +             /* dom_handle must match a domain's UUID */
>> >> >> +             xen_domain_handle_t dom_handle;
>> >> >> +             /*
>> >> >> +              * If a domain has multiple VCPUs, vcpu_id specifies which one
>> >> >> +              * this schedule entry applies to. It should be set to 0 if
>> >> >> +              * there is only one VCPU for the domain. */
>> >> >> +             unsigned int vcpu_id;
>> >> >> +             /*
>> >> >> +              * runtime specifies the amount of time that should be allocated
>> >> >> +              * to this VCPU per major frame. It is specified in nanoseconds
>> >> >> +              */
>> >> >> +             uint64_aligned_t runtime;
>> >> >> +     } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE];
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_arinc653_schedule);
>> >> >> +
>> >> >> +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;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_credit_schedule);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_scheduler_op */
>> >> >> +/* Set or get info? */
>> >> >> +#define XEN_SYSCTL_SCHEDOP_putinfo 0
>> >> >> +#define XEN_SYSCTL_SCHEDOP_getinfo 1
>> >> >> +struct xen_sysctl_scheduler_op {
>> >> >> +     uint32_t cpupool_id; /* Cpupool whose scheduler is to be targetted. */
>> >> >> +     uint32_t sched_id;   /* XEN_SCHEDULER_* (domctl.h) */
>> >> >> +     uint32_t cmd;        /* XEN_SYSCTL_SCHEDOP_* */
>> >> >> +     union {
>> >> >> +             struct xen_sysctl_sched_arinc653 {
>> >> >> +                     GUEST_HANDLE_64(xen_sysctl_arinc653_schedule) schedule;
>> >> >> +             } sched_arinc653;
>> >> >> +             struct xen_sysctl_credit_schedule sched_credit;
>> >> >> +     } u;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_scheduler_op);
>> >> >> +
>> >> >> +/* XEN_SYSCTL_coverage_op */
>> >> >> +/*
>> >> >> + * Get total size of information, to help allocate
>> >> >> + * the buffer. The pointer points to a 32 bit value.
>> >> >> + */
>> >> >> +#define XEN_SYSCTL_COVERAGE_get_total_size 0
>> >> >> +
>> >> >> +/*
>> >> >> + * Read coverage information in a single run
>> >> >> + * You must use a tool to split them.
>> >> >> + */
>> >> >> +#define XEN_SYSCTL_COVERAGE_read           1
>> >> >> +
>> >> >> +/*
>> >> >> + * Reset all the coverage counters to 0
>> >> >> + * No parameters.
>> >> >> + */
>> >> >> +#define XEN_SYSCTL_COVERAGE_reset          2
>> >> >> +
>> >> >> +/*
>> >> >> + * Like XEN_SYSCTL_COVERAGE_read but reset also
>> >> >> + * counters to 0 in a single call.
>> >> >> + */
>> >> >> +#define XEN_SYSCTL_COVERAGE_read_and_reset 3
>> >> >> +
>> >> >> +struct xen_sysctl_coverage_op {
>> >> >> +     uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
>> >> >> +     union {
>> >> >> +             uint32_t total_size; /* OUT */
>> >> >> +             GUEST_HANDLE_64(uint8_t)  raw_info;   /* OUT */
>> >> >> +     } u;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_coverage_op);
>> >> >> +
>> >> >> +
>> >> >> +struct xen_sysctl {
>> >> >> +     uint32_t cmd;
>> >> >> +#define XEN_SYSCTL_readconsole                    1
>> >> >> +#define XEN_SYSCTL_tbuf_op                        2
>> >> >> +#define XEN_SYSCTL_physinfo                       3
>> >> >> +#define XEN_SYSCTL_sched_id                       4
>> >> >> +#define XEN_SYSCTL_perfc_op                       5
>> >> >> +#define XEN_SYSCTL_debug_keys                     7
>> >> >> +#define XEN_SYSCTL_getcpuinfo                     8
>> >> >> +#define XEN_SYSCTL_availheap                      9
>> >> >> +#define XEN_SYSCTL_get_pmstat                    10
>> >> >> +#define XEN_SYSCTL_cpu_hotplug                   11
>> >> >> +#define XEN_SYSCTL_pm_op                         12
>> >> >> +#define XEN_SYSCTL_page_offline_op               14
>> >> >> +#define XEN_SYSCTL_lockprof_op                   15
>> >> >> +#define XEN_SYSCTL_topologyinfo                  16
>> >> >> +#define XEN_SYSCTL_numainfo                      17
>> >> >> +#define XEN_SYSCTL_cpupool_op                    18
>> >> >> +#define XEN_SYSCTL_scheduler_op                  19
>> >> >> +#define XEN_SYSCTL_coverage_op                   20
>> >> >> +     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
>> >> >> +     union {
>> >> >> +             struct xen_sysctl_readconsole       readconsole;
>> >> >> +             struct xen_sysctl_tbuf_op           tbuf_op;
>> >> >> +             struct xen_sysctl_physinfo          physinfo;
>> >> >> +             struct xen_sysctl_topologyinfo      topologyinfo;
>> >> >> +             struct xen_sysctl_numainfo          numainfo;
>> >> >> +             struct xen_sysctl_sched_id          sched_id;
>> >> >> +             struct xen_sysctl_perfc_op          perfc_op;
>> >> >> +             struct xen_sysctl_debug_keys        debug_keys;
>> >> >> +             struct xen_sysctl_getcpuinfo        getcpuinfo;
>> >> >> +             struct xen_sysctl_availheap         availheap;
>> >> >> +             struct xen_sysctl_get_pmstat        get_pmstat;
>> >> >> +             struct xen_sysctl_cpu_hotplug       cpu_hotplug;
>> >> >> +             struct xen_sysctl_pm_op             pm_op;
>> >> >> +             struct xen_sysctl_page_offline_op   page_offline;
>> >> >> +             struct xen_sysctl_lockprof_op       lockprof_op;
>> >> >> +             struct xen_sysctl_cpupool_op        cpupool_op;
>> >> >> +             struct xen_sysctl_scheduler_op      scheduler_op;
>> >> >> +             struct xen_sysctl_coverage_op       coverage_op;
>> >> >> +             uint8_t                             pad[128];
>> >> >> +     } u;
>> >> >> +};
>> >> >> +DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
>> >> >> +
>> >> >> +#endif /* __XEN_PUBLIC_SYSCTL_H__ */
>> >> >
>> >> > We usually only introduce what we need from Xen header files in Linux:
>> >> > do not copy the entirety of sysctl.h, just introduce what you need.
>> >> I'll do this in the next patch-set.
>> >>
>> >> >> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> >> >> index 53ec416..cf64566 100644
>> >> >> --- a/include/xen/interface/xen.h
>> >> >> +++ b/include/xen/interface/xen.h
>> >> >> @@ -57,6 +57,7 @@
>> >> >>  #define __HYPERVISOR_event_channel_op     32
>> >> >>  #define __HYPERVISOR_physdev_op           33
>> >> >>  #define __HYPERVISOR_hvm_op               34
>> >> >> +#define __HYPERVISOR_sysctl               35
>> >> >>  #define __HYPERVISOR_tmem_op              38
>> >> >>
>> >> >>  /* Architecture-specific hypercall definitions. */
>> >> >> @@ -526,6 +527,11 @@ struct tmem_op {
>> >> >>
>> >> >>  DEFINE_GUEST_HANDLE(u64);
>> >> >>
>> >> >> +struct xenctl_bitmap {
>> >> >> +     GUEST_HANDLE_64(uint8_t) bitmap;
>> >> >> +     uint32_t nr_bits;
>> >> >> +};
>> >> >> +
>> >> >>  #else /* __ASSEMBLY__ */
>> >> >>
>> >> >>  /* In assembly code we cannot use C numeric constant suffixes. */
>> >> >> --
>> >> >> 1.9.1
>> >> >>
>> >>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:33:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmP43-0006PU-1j; Thu, 06 Nov 2014 15:33:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmP41-0006PA-8d
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:33:33 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	A0/2E-16982-CC49B545; Thu, 06 Nov 2014 15:33:32 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415288009!10873047!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4815 invoked from network); 6 Nov 2014 15:33:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:33:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190219348"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:33:18 -0500
Received: from etemp.uk.xensource.com ([10.80.228.66]
	helo=etemp.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <paul.durrant@citrix.com>)	id 1XmP3l-0000tn-VG;
	Thu, 06 Nov 2014 15:33:17 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 6 Nov 2014 15:33:15 +0000
Message-ID: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Paul Durrant <paul.durrant@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

HVM guests have always been confined to using the domain callback
via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
which is an IOAPIC vector and is only used if the event channel is
bound to vcpu 0.
This patch adds a new HVM op allowing a guest to specify a local
APIC vector to use as an upcall notification for a specific vcpu.
This therefore allows a guest which sets a vector for a vcpu
other than 0 to then bind event channels to that vcpu.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c          |   39 +++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/hvm/irq.c          |    9 +++++++++
 xen/include/asm-x86/hvm/vcpu.h  |    1 +
 xen/include/public/hvm/hvm_op.h |   20 ++++++++++++++++++++
 4 files changed, 69 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 78f519d..70845b0 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5458,6 +5458,40 @@ static int hvmop_destroy_ioreq_server(
     return rc;
 }
 
+static int hvmop_set_evtchn_upcall_vector(
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t) uop)
+{
+    xen_hvm_set_evtchn_upcall_vector_t op;
+    struct domain *d;
+    struct vcpu *v;
+    int rc;
+
+    if ( copy_from_guest(&op, uop, 1) )
+        return -EFAULT;
+
+    d = rcu_lock_current_domain();
+
+    rc = -EINVAL;
+    if ( !is_hvm_domain(d) )
+        goto out;
+
+    if ( op.vector < 0x10 )
+        goto out;
+
+    rc = -ENOENT;
+    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
+        goto out;
+
+    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
+
+    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
+    rc = 0;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 #define HVMOP_op_mask 0xff
 
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
@@ -5499,6 +5533,11 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
             guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
         break;
     
+    case HVMOP_set_evtchn_upcall_vector:
+        rc = hvmop_set_evtchn_upcall_vector(
+            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
+        break;
+    
     case HVMOP_set_param:
     case HVMOP_get_param:
     {
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 35f4f94..3e4c0b4 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
     spin_unlock(&d->arch.hvm_domain.irq_lock);
 }
 
+static void hvm_set_upcall_irq(struct vcpu *v)
+{
+    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
+
+    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
+}
+
 static void hvm_set_callback_irq_level(struct vcpu *v)
 {
     struct domain *d = v->domain;
@@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
 
     if ( is_hvm_pv_evtchn_vcpu(v) )
         vcpu_kick(v);
+    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
+        hvm_set_upcall_irq(v);
     else if ( v->vcpu_id == 0 )
         hvm_set_callback_irq_level(v);
 }
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..edd4523 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -160,6 +160,7 @@ struct hvm_vcpu {
     } u;
 
     struct tasklet      assert_evtchn_irq_tasklet;
+    u8                  evtchn_upcall_vector;
 
     struct nestedvcpu   nvcpu;
 
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index eeb0a60..cfbf85d 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -369,6 +369,26 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
 
 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
 
+#if defined(__i386__) || defined(__x86_64__)
+
+/*
+ * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used for event
+ *                                 channel upcalls on the specified <vcpu>. If set,
+ *                                 this vector will be used in preference to the
+ *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
+ *                                 and hence allows HVM guests to bind event
+ *                                 event channels to a vcpu other than 0.
+ */
+#define HVMOP_set_evtchn_upcall_vector 23
+struct xen_hvm_set_evtchn_upcall_vector {
+    uint32_t vcpu;
+    uint8_t vector;
+};
+typedef struct xen_hvm_set_evtchn_upcall_vector xen_hvm_set_evtchn_upcall_vector_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
+
+#endif /* defined(__i386__) || defined(__x86_64__) */
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:33:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmP4A-0006Rs-Ec; Thu, 06 Nov 2014 15:33:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmP49-0006RE-30
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:33:41 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	7F/E3-17694-4D49B545; Thu, 06 Nov 2014 15:33:40 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415288017!10945299!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6170 invoked from network); 6 Nov 2014 15:33:39 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:33:39 -0000
Received: from mail-qg0-f46.google.com ([209.85.192.46]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuU0UC0+9FBnZXedlVyzGKZREJEf6vL@postini.com;
	Thu, 06 Nov 2014 07:33:39 PST
Received: by mail-qg0-f46.google.com with SMTP id i50so888373qgf.5
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:33:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=n+IN+EdzAu0flTvOa2Vi2Nbf/ZoRadaq3s7FM9aZtgY=;
	b=lcxCCQOFNL7A5hjJa6K8+H+w9+/PBySD7UKJnJdqatZbPHEGBqVm7JB1EuW9Nkr61t
	Vau/fpRCBK8dn1AKsLb7U2J528KkR5FU3cRTwn7jc3YZ8YjaTFf1Rft39QGfKtuIOsAQ
	1/TaOoMvL4vT3v7lL7Ee+f4Y5cSFxSnB53AzI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=n+IN+EdzAu0flTvOa2Vi2Nbf/ZoRadaq3s7FM9aZtgY=;
	b=cY278L9O27lzbxq0J6DxrAsEek0+CFr5NzGwczfimk7zLjCpkels/rnE6eh5w+yxk9
	eD5OxJNE+Zfgy0XGS9s+hBYc9CvpSkBRHpGsDghQqr6eoUR6JwHDBCpWelwzx77dBpO4
	SvUFHhUcTEOnkVPvUqoUhK+DyRXJaSnQyKWeFtJcxQ8LCDVFGZ2JOy5669oxV9y7gfwS
	VyJ+fVwW0UpaYpQOgio9h5NPMGiMqEUae5+z9wc6wa9XE/NDTqFuFHyX+v6kO+l0Qq7b
	11HJigv7WWizkXzowwrzCd4s+PdSYXZLhpGnyNVwc+8nkcRct3+AGwGb2VJ6GE/L4jcv
	fgGg==
X-Gm-Message-State: ALoCoQnZMlhExdtOQVB5dUlKEPjqj/sCRg5Wl75NtIdERoIgK0OsX6d3lPGquyNR8NvYaGi7Z7GIMPSqGqCai8hR55YXvLnWHhgz6GFMtOxeIdWQfJ0dMXmjq6UFXnO/Q6ZDEFqyFAraebKj3rRHRmqo1lA+H3WX8Q==
X-Received: by 10.224.127.133 with SMTP id g5mr8108203qas.24.1415288016752;
	Thu, 06 Nov 2014 07:33:36 -0800 (PST)
X-Received: by 10.224.127.133 with SMTP id g5mr8108192qas.24.1415288016667;
	Thu, 06 Nov 2014 07:33:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:33:15 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061527390.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
	<CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
	<alpine.DEB.2.02.1411061516210.22875@kaball.uk.xensource.com>
	<CAN58jis_GbKe2s+Fbg=A4-Jfu4vCzZGCmMqPqVZ9yKwX9LdwcA@mail.gmail.com>
	<alpine.DEB.2.02.1411061527390.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:33:15 +0200
Message-ID: <CAN58jivoZC0D0t0v+BxFSYbzV8t8yGfb4LhaPpGV5JLPpGWVGA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 6, 2014 at 5:28 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >> >
>> >> > Why?
>> >> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
>> >
>> > I meant why are you introducing HYPERVISOR_dom0_op?
>> HYPERVISOR_dom0_op is used to upload CPUs PM data from Kernel to Xen
>
> Please add the explanation to the commit message.
I'll do this in the next patch-set.

>>
>> >> >>  arch/arm/include/asm/xen/hypercall.h | 1 +
>> >> >>  arch/arm/xen/enlighten.c             | 1 +
>> >> >>  arch/arm/xen/hypercall.S             | 1 +
>> >> >>  3 files changed, 3 insertions(+)
>> >> >>
>> >> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> >> >> index 751869eb..383c174 100644
>> >> >> --- a/arch/arm/include/asm/xen/hypercall.h
>> >> >> +++ b/arch/arm/include/asm/xen/hypercall.h
>> >> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>> >> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>> >> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>> >> >>  int HYPERVISOR_tmem_op(void *arg);
>> >> >> +int HYPERVISOR_dom0_op(void *arg);
>> >> >>  int HYPERVISOR_sysctl(void *arg);
>> >> >>
>> >> >>  static inline void
>> >> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> >> >> index 675f17a..f757c57 100644
>> >> >> --- a/arch/arm/xen/enlighten.c
>> >> >> +++ b/arch/arm/xen/enlighten.c
>> >> >> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> >> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>> >> >>  EXPORT_SYMBOL_GPL(privcmd_call);
>> >> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> >> >> index a1276df..99e2254 100644
>> >> >> --- a/arch/arm/xen/hypercall.S
>> >> >> +++ b/arch/arm/xen/hypercall.S
>> >> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>> >> >>  HYPERCALL2(physdev_op);
>> >> >>  HYPERCALL3(vcpu_op);
>> >> >>  HYPERCALL1(tmem_op);
>> >> >> +HYPERCALL1(dom0_op);
>> >> >>  HYPERCALL1(sysctl);
>> >> >>
>> >> >>  ENTRY(privcmd_call)
>> >> >> --
>> >> >> 1.9.1
>> >> >>
>> >>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:33:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmP4A-0006Rs-Ec; Thu, 06 Nov 2014 15:33:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmP49-0006RE-30
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:33:41 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	7F/E3-17694-4D49B545; Thu, 06 Nov 2014 15:33:40 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415288017!10945299!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6170 invoked from network); 6 Nov 2014 15:33:39 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:33:39 -0000
Received: from mail-qg0-f46.google.com ([209.85.192.46]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuU0UC0+9FBnZXedlVyzGKZREJEf6vL@postini.com;
	Thu, 06 Nov 2014 07:33:39 PST
Received: by mail-qg0-f46.google.com with SMTP id i50so888373qgf.5
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:33:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=n+IN+EdzAu0flTvOa2Vi2Nbf/ZoRadaq3s7FM9aZtgY=;
	b=lcxCCQOFNL7A5hjJa6K8+H+w9+/PBySD7UKJnJdqatZbPHEGBqVm7JB1EuW9Nkr61t
	Vau/fpRCBK8dn1AKsLb7U2J528KkR5FU3cRTwn7jc3YZ8YjaTFf1Rft39QGfKtuIOsAQ
	1/TaOoMvL4vT3v7lL7Ee+f4Y5cSFxSnB53AzI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=n+IN+EdzAu0flTvOa2Vi2Nbf/ZoRadaq3s7FM9aZtgY=;
	b=cY278L9O27lzbxq0J6DxrAsEek0+CFr5NzGwczfimk7zLjCpkels/rnE6eh5w+yxk9
	eD5OxJNE+Zfgy0XGS9s+hBYc9CvpSkBRHpGsDghQqr6eoUR6JwHDBCpWelwzx77dBpO4
	SvUFHhUcTEOnkVPvUqoUhK+DyRXJaSnQyKWeFtJcxQ8LCDVFGZ2JOy5669oxV9y7gfwS
	VyJ+fVwW0UpaYpQOgio9h5NPMGiMqEUae5+z9wc6wa9XE/NDTqFuFHyX+v6kO+l0Qq7b
	11HJigv7WWizkXzowwrzCd4s+PdSYXZLhpGnyNVwc+8nkcRct3+AGwGb2VJ6GE/L4jcv
	fgGg==
X-Gm-Message-State: ALoCoQnZMlhExdtOQVB5dUlKEPjqj/sCRg5Wl75NtIdERoIgK0OsX6d3lPGquyNR8NvYaGi7Z7GIMPSqGqCai8hR55YXvLnWHhgz6GFMtOxeIdWQfJ0dMXmjq6UFXnO/Q6ZDEFqyFAraebKj3rRHRmqo1lA+H3WX8Q==
X-Received: by 10.224.127.133 with SMTP id g5mr8108203qas.24.1415288016752;
	Thu, 06 Nov 2014 07:33:36 -0800 (PST)
X-Received: by 10.224.127.133 with SMTP id g5mr8108192qas.24.1415288016667;
	Thu, 06 Nov 2014 07:33:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:33:15 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061527390.22875@kaball.uk.xensource.com>
References: <1415106572-3178-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106572-3178-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041617480.22875@kaball.uk.xensource.com>
	<CAN58jitCvhC3YUGNmvW6PMLxDZO7YH5_qe3yTfQzFPWD3_Xygg@mail.gmail.com>
	<alpine.DEB.2.02.1411061516210.22875@kaball.uk.xensource.com>
	<CAN58jis_GbKe2s+Fbg=A4-Jfu4vCzZGCmMqPqVZ9yKwX9LdwcA@mail.gmail.com>
	<alpine.DEB.2.02.1411061527390.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:33:15 +0200
Message-ID: <CAN58jivoZC0D0t0v+BxFSYbzV8t8yGfb4LhaPpGV5JLPpGWVGA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 3/9] xen/arm: implement
	HYPERVISOR_dom0_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 6, 2014 at 5:28 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Thu, Nov 6, 2014 at 5:16 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> On Tue, Nov 4, 2014 at 6:17 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >> >
>> >> > Why?
>> >> I'll add authors Signed-off-by before my Signed-off-by in the next patch-set.
>> >
>> > I meant why are you introducing HYPERVISOR_dom0_op?
>> HYPERVISOR_dom0_op is used to upload CPUs PM data from Kernel to Xen
>
> Please add the explanation to the commit message.
I'll do this in the next patch-set.

>>
>> >> >>  arch/arm/include/asm/xen/hypercall.h | 1 +
>> >> >>  arch/arm/xen/enlighten.c             | 1 +
>> >> >>  arch/arm/xen/hypercall.S             | 1 +
>> >> >>  3 files changed, 3 insertions(+)
>> >> >>
>> >> >> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
>> >> >> index 751869eb..383c174 100644
>> >> >> --- a/arch/arm/include/asm/xen/hypercall.h
>> >> >> +++ b/arch/arm/include/asm/xen/hypercall.h
>> >> >> @@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>> >> >>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>> >> >>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>> >> >>  int HYPERVISOR_tmem_op(void *arg);
>> >> >> +int HYPERVISOR_dom0_op(void *arg);
>> >> >>  int HYPERVISOR_sysctl(void *arg);
>> >> >>
>> >> >>  static inline void
>> >> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> >> >> index 675f17a..f757c57 100644
>> >> >> --- a/arch/arm/xen/enlighten.c
>> >> >> +++ b/arch/arm/xen/enlighten.c
>> >> >> @@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>> >> >> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
>> >> >>  EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
>> >> >>  EXPORT_SYMBOL_GPL(privcmd_call);
>> >> >> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
>> >> >> index a1276df..99e2254 100644
>> >> >> --- a/arch/arm/xen/hypercall.S
>> >> >> +++ b/arch/arm/xen/hypercall.S
>> >> >> @@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
>> >> >>  HYPERCALL2(physdev_op);
>> >> >>  HYPERCALL3(vcpu_op);
>> >> >>  HYPERCALL1(tmem_op);
>> >> >> +HYPERCALL1(dom0_op);
>> >> >>  HYPERCALL1(sysctl);
>> >> >>
>> >> >>  ENTRY(privcmd_call)
>> >> >> --
>> >> >> 1.9.1
>> >> >>
>> >>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:37:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmP7J-0006oc-LO; Thu, 06 Nov 2014 15:36:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmP7I-0006oJ-89
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:36:56 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	03/83-11581-7959B545; Thu, 06 Nov 2014 15:36:55 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415288211!10898225!1
X-Originating-IP: [64.18.0.145]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2166 invoked from network); 6 Nov 2014 15:36:54 -0000
Received: from exprod5og103.obsmtp.com (HELO exprod5og103.obsmtp.com)
	(64.18.0.145)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:36:54 -0000
Received: from mail-qc0-f173.google.com ([209.85.216.173]) (using TLSv1) by
	exprod5ob103.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuVkwTl2FEmI7Qx05VITOaiMGlEzxP+@postini.com;
	Thu, 06 Nov 2014 07:36:54 PST
Received: by mail-qc0-f173.google.com with SMTP id x3so952854qcv.18
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:36:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=V0RxkNg/5Jml2o9C4V51VYHXdcghwwh6xautt7LVg2w=;
	b=DCEWBeLba6y9Vv/K4GjgzGZAAnmzWXAlL4Plk9qaKMHJ4zSyq0pOqMfkKw3t2NpmlB
	UF/5evcswkbTi4vXV4AvZaJgIBkM7q+qWfExmgkZz6sXFcL+lURUf/LSt+Q+2rrwI//P
	j342/7+YX5i6zkDQswqAUlOl6582xRNpKssQo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=V0RxkNg/5Jml2o9C4V51VYHXdcghwwh6xautt7LVg2w=;
	b=EsK4/yw9XDR3R6CmfrG3KUYdkHJCt247fXjzSuhyB94cwld3ANlEnunA4Vxv035Faw
	G1xy8qAGbrhwhiLDYm3b7uCm8AakAh2sJagzRBW0fyVw0RA5FeoIIR5Nj82FUTutSaUa
	Psdf/dniMWNzpDUFzV10CBFRkFsyc4dQ+Jmw6ijNSHtd6QDPvMGhUzvOOzkaD8dWgh3l
	F4QpWZ3KgJCEWhVfYRfvii7l5TSihDmuTmZ9y22ctWWUCmjsAs5S8H40tWo/KQnun6ZY
	8wLUl2p+XUBsqP9g3O6ltZyFdkR1ZirvF9JQb1q+z3rKF6td2SsK+/oP+wstBEHOMxOy
	fOrg==
X-Gm-Message-State: ALoCoQnzi2XcpC8gcV8SEKai3DOexYJecyif4ygcvx7pmL+pNeXHwpbFEIRb3qTUcELD2qE0x/U1Yrjl+CoCy7zpMH9TxVcuZODGLaZ7+/1Km80Al2LcL1k10mMikkKYeunsEO5G5nSlBeME/JjxW/vEt3erZ+cImw==
X-Received: by 10.224.127.133 with SMTP id g5mr8138098qas.24.1415288210921;
	Thu, 06 Nov 2014 07:36:50 -0800 (PST)
X-Received: by 10.224.127.133 with SMTP id g5mr8138070qas.24.1415288210815;
	Thu, 06 Nov 2014 07:36:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:36:30 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061521110.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041609070.22875@kaball.uk.xensource.com>
	<CAN58jiuC51hrTDHivnv8mpMjns1V9eT4tafKYxv_gCAgJWgpGg@mail.gmail.com>
	<alpine.DEB.2.02.1411061521110.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:36:30 +0200
Message-ID: <CAN58jiujmrxZ4jOeWAdDzQmYwLNCwtu6UDSW65ruost=NKgreQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared
	info definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 6, 2014 at 5:27 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Tue, Nov 4, 2014 at 6:12 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> This shared info will be used by hwdom-cpufreq driver
>> >> to send commands to the cpufreq driver in the hwdom.
>> >>
>> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >> ---
>> >>  xen/include/asm-arm/shared.h  | 14 ++++++++++++++
>> >>  xen/include/public/arch-arm.h |  8 ++++++++
>> >>  2 files changed, 22 insertions(+)
>> >>  create mode 100644 xen/include/asm-arm/shared.h
>> >>
>> >> diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
>> >> new file mode 100644
>> >> index 0000000..4906f38
>> >> --- /dev/null
>> >> +++ b/xen/include/asm-arm/shared.h
>> >> @@ -0,0 +1,14 @@
>> >> +#ifndef __XEN_ARM_SHARED_H__
>> >> +#define __XEN_ARM_SHARED_H__
>> >> +
>> >> +#define GET_SET_SHARED(type, field)                                 \
>> >> +static inline type *arch_get_##field##_addr(const struct domain *d) \
>> >> +{                                                                   \
>> >> +   return &d->shared_info->arch.field;                              \
>> >> +}
>> >> +
>> >> +GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
>> >> +
>> >> +#undef GET_SET_SHARED
>> >> +
>> >> +#endif /* __XEN_ARM_SHARED_H__ */
>> >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>> >> index 7496556..7eef6f7 100644
>> >> --- a/xen/include/public/arch-arm.h
>> >> +++ b/xen/include/public/arch-arm.h
>> >> @@ -309,7 +309,15 @@ struct arch_vcpu_info {
>> >>  };
>> >>  typedef struct arch_vcpu_info arch_vcpu_info_t;
>> >>
>> >> +struct cpufreq_sh_info {
>> >> +    uint32_t cpu;       /* Physical CPU number */
>> >> +    uint32_t freq;      /* Frequency in KHz */
>> >> +    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
>> >> +    int32_t result;        /* Returned result of the operation */
>> >> +};
>> >> +
>> >>  struct arch_shared_info {
>> >> +    struct cpufreq_sh_info cpufreq;
>> >>  };
>> >>  typedef struct arch_shared_info arch_shared_info_t;
>> >>  typedef uint64_t xen_callback_t;
>> >
>> > This introduces one global struct cpufreq_sh_info. Do we need to worry
>> > about locking? Is it possible that we might want to send two commands
>> > simultaneously? How does Xen get to know that Dom0 completed the
>> > previous operation before starting a new one?
>> As I've written before:
>> I'll create an event channel between Xen and hwdom.
>> In this case Xen will be able to know that hwdom completed the
>> previous operation before starting a new one.
>
> I don't think that Xen can receive event channel notifications.  You
> might have to introduce some kind of synchronization protocol within
> struct cpufreq_sh_info.
>
> It would greatly simplify your problem if you made sure that the guest
> cpufreq "handler" only ran on one particular vcpu. Maybe you could
> register the vcpu handler at boot time via hypercall. Otherwise you
> could have one struct cpufreq_sh_info per guest vcpu.
I'll think about it.
I've checked that Xen can receive event channel notifications (and hwdom too).
(I've created an event channel between Xen and hwdom).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:37:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmP7J-0006oc-LO; Thu, 06 Nov 2014 15:36:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XmP7I-0006oJ-89
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:36:56 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	03/83-11581-7959B545; Thu, 06 Nov 2014 15:36:55 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415288211!10898225!1
X-Originating-IP: [64.18.0.145]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2166 invoked from network); 6 Nov 2014 15:36:54 -0000
Received: from exprod5og103.obsmtp.com (HELO exprod5og103.obsmtp.com)
	(64.18.0.145)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 15:36:54 -0000
Received: from mail-qc0-f173.google.com ([209.85.216.173]) (using TLSv1) by
	exprod5ob103.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVFuVkwTl2FEmI7Qx05VITOaiMGlEzxP+@postini.com;
	Thu, 06 Nov 2014 07:36:54 PST
Received: by mail-qc0-f173.google.com with SMTP id x3so952854qcv.18
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:36:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=V0RxkNg/5Jml2o9C4V51VYHXdcghwwh6xautt7LVg2w=;
	b=DCEWBeLba6y9Vv/K4GjgzGZAAnmzWXAlL4Plk9qaKMHJ4zSyq0pOqMfkKw3t2NpmlB
	UF/5evcswkbTi4vXV4AvZaJgIBkM7q+qWfExmgkZz6sXFcL+lURUf/LSt+Q+2rrwI//P
	j342/7+YX5i6zkDQswqAUlOl6582xRNpKssQo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=V0RxkNg/5Jml2o9C4V51VYHXdcghwwh6xautt7LVg2w=;
	b=EsK4/yw9XDR3R6CmfrG3KUYdkHJCt247fXjzSuhyB94cwld3ANlEnunA4Vxv035Faw
	G1xy8qAGbrhwhiLDYm3b7uCm8AakAh2sJagzRBW0fyVw0RA5FeoIIR5Nj82FUTutSaUa
	Psdf/dniMWNzpDUFzV10CBFRkFsyc4dQ+Jmw6ijNSHtd6QDPvMGhUzvOOzkaD8dWgh3l
	F4QpWZ3KgJCEWhVfYRfvii7l5TSihDmuTmZ9y22ctWWUCmjsAs5S8H40tWo/KQnun6ZY
	8wLUl2p+XUBsqP9g3O6ltZyFdkR1ZirvF9JQb1q+z3rKF6td2SsK+/oP+wstBEHOMxOy
	fOrg==
X-Gm-Message-State: ALoCoQnzi2XcpC8gcV8SEKai3DOexYJecyif4ygcvx7pmL+pNeXHwpbFEIRb3qTUcELD2qE0x/U1Yrjl+CoCy7zpMH9TxVcuZODGLaZ7+/1Km80Al2LcL1k10mMikkKYeunsEO5G5nSlBeME/JjxW/vEt3erZ+cImw==
X-Received: by 10.224.127.133 with SMTP id g5mr8138098qas.24.1415288210921;
	Thu, 06 Nov 2014 07:36:50 -0800 (PST)
X-Received: by 10.224.127.133 with SMTP id g5mr8138070qas.24.1415288210815;
	Thu, 06 Nov 2014 07:36:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.1 with HTTP; Thu, 6 Nov 2014 07:36:30 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061521110.22875@kaball.uk.xensource.com>
References: <1415106521-3115-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415106521-3115-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<alpine.DEB.2.02.1411041609070.22875@kaball.uk.xensource.com>
	<CAN58jiuC51hrTDHivnv8mpMjns1V9eT4tafKYxv_gCAgJWgpGg@mail.gmail.com>
	<alpine.DEB.2.02.1411061521110.22875@kaball.uk.xensource.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Thu, 6 Nov 2014 17:36:30 +0200
Message-ID: <CAN58jiujmrxZ4jOeWAdDzQmYwLNCwtu6UDSW65ruost=NKgreQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared
	info definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 6, 2014 at 5:27 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Tue, Nov 4, 2014 at 6:12 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> This shared info will be used by hwdom-cpufreq driver
>> >> to send commands to the cpufreq driver in the hwdom.
>> >>
>> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>> >> ---
>> >>  xen/include/asm-arm/shared.h  | 14 ++++++++++++++
>> >>  xen/include/public/arch-arm.h |  8 ++++++++
>> >>  2 files changed, 22 insertions(+)
>> >>  create mode 100644 xen/include/asm-arm/shared.h
>> >>
>> >> diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
>> >> new file mode 100644
>> >> index 0000000..4906f38
>> >> --- /dev/null
>> >> +++ b/xen/include/asm-arm/shared.h
>> >> @@ -0,0 +1,14 @@
>> >> +#ifndef __XEN_ARM_SHARED_H__
>> >> +#define __XEN_ARM_SHARED_H__
>> >> +
>> >> +#define GET_SET_SHARED(type, field)                                 \
>> >> +static inline type *arch_get_##field##_addr(const struct domain *d) \
>> >> +{                                                                   \
>> >> +   return &d->shared_info->arch.field;                              \
>> >> +}
>> >> +
>> >> +GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
>> >> +
>> >> +#undef GET_SET_SHARED
>> >> +
>> >> +#endif /* __XEN_ARM_SHARED_H__ */
>> >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>> >> index 7496556..7eef6f7 100644
>> >> --- a/xen/include/public/arch-arm.h
>> >> +++ b/xen/include/public/arch-arm.h
>> >> @@ -309,7 +309,15 @@ struct arch_vcpu_info {
>> >>  };
>> >>  typedef struct arch_vcpu_info arch_vcpu_info_t;
>> >>
>> >> +struct cpufreq_sh_info {
>> >> +    uint32_t cpu;       /* Physical CPU number */
>> >> +    uint32_t freq;      /* Frequency in KHz */
>> >> +    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
>> >> +    int32_t result;        /* Returned result of the operation */
>> >> +};
>> >> +
>> >>  struct arch_shared_info {
>> >> +    struct cpufreq_sh_info cpufreq;
>> >>  };
>> >>  typedef struct arch_shared_info arch_shared_info_t;
>> >>  typedef uint64_t xen_callback_t;
>> >
>> > This introduces one global struct cpufreq_sh_info. Do we need to worry
>> > about locking? Is it possible that we might want to send two commands
>> > simultaneously? How does Xen get to know that Dom0 completed the
>> > previous operation before starting a new one?
>> As I've written before:
>> I'll create an event channel between Xen and hwdom.
>> In this case Xen will be able to know that hwdom completed the
>> previous operation before starting a new one.
>
> I don't think that Xen can receive event channel notifications.  You
> might have to introduce some kind of synchronization protocol within
> struct cpufreq_sh_info.
>
> It would greatly simplify your problem if you made sure that the guest
> cpufreq "handler" only ran on one particular vcpu. Maybe you could
> register the vcpu handler at boot time via hypercall. Otherwise you
> could have one struct cpufreq_sh_info per guest vcpu.
I'll think about it.
I've checked that Xen can receive event channel notifications (and hwdom too).
(I've created an event channel between Xen and hwdom).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:42:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:42:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPC4-00075z-CB; Thu, 06 Nov 2014 15:41:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmPC3-00075k-0D
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:41:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	46/ED-09842-EB69B545; Thu, 06 Nov 2014 15:41:50 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415288507!11969014!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11436 invoked from network); 6 Nov 2014 15:41:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:41:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190222583"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:41:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmPBy-000134-7M;
	Thu, 06 Nov 2014 15:41:46 +0000
Date: Thu, 6 Nov 2014 15:41:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Quan" <quan.xu@intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E8206C2@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411061537320.22875@kaball.uk.xensource.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8206C2@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Monday, November 03, 2014 7:54 PM
> > To: Xu, Quan
> > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > stefano.stabellini@eu.citrix.com
> > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > frontend driver
> > 
> > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > This drvier transfers any request/repond between TPM xenstubdoms
> > > driver and Xen vTPM stubdom, and facilitates communications between
> > > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > >
> > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > 
> > Please describe what changes did make to xen_backend.c and why.
> > The commit message should contains info on all the changes made by the
> > patch below.
> > 
> 
> The following is code process when Qemu is running with Xen. 
> ##code process
> [...]
>  xen_hvm_init()
>     -->xen_be_register()
>         -->xenstore_scan()
>             -->xen_be_check_state()
> 
>     -->xen_vtpm_register()
> 
> ideally, I can register 'vtpm' via xen_vtpm_register() as
> 
> + xen_be_register("console", &xen_console_ops);
> + xen_be_register("vkbd", &xen_kbdmouse_ops);
> + xen_be_register("qdisk", &xen_blkdev_ops);
> 
> but there are 2 reasons why I add xen_vtpm_register(), instead
> of xen_be_register().
> 
> 1. The backend of TPM is runing in a Xen stubDom, not Domain 0.
> some functions are not working, for example 'setup watch' and
> 'look for backend' in xenstore_scan()
> 
> 2. there is a thread runing in Xen stubDom [event_thread()], it will
> handle backend status when the frontend is initialized. It is not
> compatible with xen_be_check_state(). xen_be_check_state() always tries 
> to modify the status of backend. 
> 
> as there is always a tradeoff, if I force to integrate this case into
> xen_be_register(), there are maybe a lot of 'if ... else.. '. It will
> break the code architecture. Also I should leverage existing source
> code with minimum modifcation. i add 'DEVOPS_FLAG_STUBDOM_BE' flag in
> include/hw/xen/xen_backend.h to indicate that device backend is Xen
> stubDom.

Given that xen_vtpm_register is actually registering a frontend, not a
backend, you cannot use xen_be_register for it.

However instead of introducing xen_vtpm_register, I think you should be
adding a generic xen_fe_register function that handle any Xen PV
frontend registration. It should also be able to handle backends not in
Dom0. Then you can call:

xen_fe_register("console", &xen_vtpm_ops);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:42:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:42:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPC4-00075z-CB; Thu, 06 Nov 2014 15:41:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmPC3-00075k-0D
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:41:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	46/ED-09842-EB69B545; Thu, 06 Nov 2014 15:41:50 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415288507!11969014!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11436 invoked from network); 6 Nov 2014 15:41:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:41:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190222583"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:41:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmPBy-000134-7M;
	Thu, 06 Nov 2014 15:41:46 +0000
Date: Thu, 6 Nov 2014 15:41:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Quan" <quan.xu@intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E8206C2@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411061537320.22875@kaball.uk.xensource.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8206C2@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Monday, November 03, 2014 7:54 PM
> > To: Xu, Quan
> > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > stefano.stabellini@eu.citrix.com
> > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > frontend driver
> > 
> > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > This drvier transfers any request/repond between TPM xenstubdoms
> > > driver and Xen vTPM stubdom, and facilitates communications between
> > > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > >
> > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > 
> > Please describe what changes did make to xen_backend.c and why.
> > The commit message should contains info on all the changes made by the
> > patch below.
> > 
> 
> The following is code process when Qemu is running with Xen. 
> ##code process
> [...]
>  xen_hvm_init()
>     -->xen_be_register()
>         -->xenstore_scan()
>             -->xen_be_check_state()
> 
>     -->xen_vtpm_register()
> 
> ideally, I can register 'vtpm' via xen_vtpm_register() as
> 
> + xen_be_register("console", &xen_console_ops);
> + xen_be_register("vkbd", &xen_kbdmouse_ops);
> + xen_be_register("qdisk", &xen_blkdev_ops);
> 
> but there are 2 reasons why I add xen_vtpm_register(), instead
> of xen_be_register().
> 
> 1. The backend of TPM is runing in a Xen stubDom, not Domain 0.
> some functions are not working, for example 'setup watch' and
> 'look for backend' in xenstore_scan()
> 
> 2. there is a thread runing in Xen stubDom [event_thread()], it will
> handle backend status when the frontend is initialized. It is not
> compatible with xen_be_check_state(). xen_be_check_state() always tries 
> to modify the status of backend. 
> 
> as there is always a tradeoff, if I force to integrate this case into
> xen_be_register(), there are maybe a lot of 'if ... else.. '. It will
> break the code architecture. Also I should leverage existing source
> code with minimum modifcation. i add 'DEVOPS_FLAG_STUBDOM_BE' flag in
> include/hw/xen/xen_backend.h to indicate that device backend is Xen
> stubDom.

Given that xen_vtpm_register is actually registering a frontend, not a
backend, you cannot use xen_be_register for it.

However instead of introducing xen_vtpm_register, I think you should be
adding a generic xen_fe_register function that handle any Xen PV
frontend registration. It should also be able to handle backends not in
Dom0. Then you can call:

xen_fe_register("console", &xen_vtpm_ops);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:44:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPE3-0007Ig-Tt; Thu, 06 Nov 2014 15:43:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmPE2-0007IV-KA
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:43:54 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	3C/D3-11581-9379B545; Thu, 06 Nov 2014 15:43:53 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415288631!10936269!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2421 invoked from network); 6 Nov 2014 15:43:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:43:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190223298"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:43:50 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmPDy-00015L-9U;
	Thu, 06 Nov 2014 15:43:50 +0000
Date: Thu, 6 Nov 2014 15:43:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
In-Reply-To: <20141106113923.GA3182@type.bordeaux.inria.fr>
Message-ID: <alpine.DEB.2.02.1411061543170.22875@kaball.uk.xensource.com>
References: <1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
	<20141106113923.GA3182@type.bordeaux.inria.fr>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-247393973-1415288622=:22875"
X-DLP: MIA1
Cc: netwiz@crc.id.au, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-247393973-1415288622=:22875
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 6 Nov 2014, Samuel Thibault wrote:
> Stefano Stabellini, le Thu 06 Nov 2014 10:41:28 +0000, a =C3=A9crit :
> > When using pvgrub in graphical mode with vnc, the grub timeout doesn't
> > work: the countdown doesn't even start. With a serial terminal the
> > problem doesn't occur and the countdown works as expected.
> >=20
> > It turns out that the problem is that when using a graphical terminal,
> > checkkey () returns 0 instead of -1 when there is no activity on the
> > mouse or keyboard. As a consequence grub thinks that the user typed
> > something and interrupts the count down.
> >=20
> > To fix the issue simply ignore keystrokes returning 0, that is the NUL
> > character anyway. Add a patch to grub.patches to do that.
> >=20
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Tested-by: Steven Haigh <netwiz@crc.id.au>
>=20
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

This being a bug fix, I guess it doesn't actually need a release
exception to go in?


> > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/gr=
ub.patches/11graphics-keyboard.diff
> > new file mode 100644
> > index 0000000..fe17b20
> > --- /dev/null
> > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> > @@ -0,0 +1,13 @@
> > +diff --git a/stage2/stage2.c b/stage2/stage2.c
> > +index 9d9fcc3..8353a3b 100644
> > +--- a/stage2/stage2.c
> > ++++ b/stage2/stage2.c
> > +@@ -395,7 +395,7 @@ restart:
> > + =09 pressed. =20
> > + =09 This avoids polling (relevant in the grub-shell and later on
> > + =09 in grub if interrupt driven I/O is done).  */
> > +-      if (checkkey () >=3D 0 || grub_timeout < 0)
> > ++      if (checkkey () > 0 || grub_timeout < 0)
> > + =09{
> > + =09  /* Key was pressed, show which entry is selected before GETKEY,
> > + =09     since we're comming in here also on GRUB_TIMEOUT =3D=3D -1 an=
d
> >=20
>=20
> --=20
> Samuel
> "And the next time you consider complaining that running Lucid Emacs
> 19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
> get the background colors right, you'll know who to thank."
> (By Matt Welsh)
>=20
--1342847746-247393973-1415288622=:22875
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-247393973-1415288622=:22875--


From xen-devel-bounces@lists.xen.org Thu Nov 06 15:44:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPE3-0007Ig-Tt; Thu, 06 Nov 2014 15:43:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmPE2-0007IV-KA
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:43:54 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	3C/D3-11581-9379B545; Thu, 06 Nov 2014 15:43:53 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415288631!10936269!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2421 invoked from network); 6 Nov 2014 15:43:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:43:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190223298"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:43:50 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmPDy-00015L-9U;
	Thu, 06 Nov 2014 15:43:50 +0000
Date: Thu, 6 Nov 2014 15:43:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
In-Reply-To: <20141106113923.GA3182@type.bordeaux.inria.fr>
Message-ID: <alpine.DEB.2.02.1411061543170.22875@kaball.uk.xensource.com>
References: <1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
	<20141106113923.GA3182@type.bordeaux.inria.fr>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-247393973-1415288622=:22875"
X-DLP: MIA1
Cc: netwiz@crc.id.au, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-247393973-1415288622=:22875
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 6 Nov 2014, Samuel Thibault wrote:
> Stefano Stabellini, le Thu 06 Nov 2014 10:41:28 +0000, a =C3=A9crit :
> > When using pvgrub in graphical mode with vnc, the grub timeout doesn't
> > work: the countdown doesn't even start. With a serial terminal the
> > problem doesn't occur and the countdown works as expected.
> >=20
> > It turns out that the problem is that when using a graphical terminal,
> > checkkey () returns 0 instead of -1 when there is no activity on the
> > mouse or keyboard. As a consequence grub thinks that the user typed
> > something and interrupts the count down.
> >=20
> > To fix the issue simply ignore keystrokes returning 0, that is the NUL
> > character anyway. Add a patch to grub.patches to do that.
> >=20
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Tested-by: Steven Haigh <netwiz@crc.id.au>
>=20
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

This being a bug fix, I guess it doesn't actually need a release
exception to go in?


> > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/gr=
ub.patches/11graphics-keyboard.diff
> > new file mode 100644
> > index 0000000..fe17b20
> > --- /dev/null
> > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> > @@ -0,0 +1,13 @@
> > +diff --git a/stage2/stage2.c b/stage2/stage2.c
> > +index 9d9fcc3..8353a3b 100644
> > +--- a/stage2/stage2.c
> > ++++ b/stage2/stage2.c
> > +@@ -395,7 +395,7 @@ restart:
> > + =09 pressed. =20
> > + =09 This avoids polling (relevant in the grub-shell and later on
> > + =09 in grub if interrupt driven I/O is done).  */
> > +-      if (checkkey () >=3D 0 || grub_timeout < 0)
> > ++      if (checkkey () > 0 || grub_timeout < 0)
> > + =09{
> > + =09  /* Key was pressed, show which entry is selected before GETKEY,
> > + =09     since we're comming in here also on GRUB_TIMEOUT =3D=3D -1 an=
d
> >=20
>=20
> --=20
> Samuel
> "And the next time you consider complaining that running Lucid Emacs
> 19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
> get the background colors right, you'll know who to thank."
> (By Matt Welsh)
>=20
--1342847746-247393973-1415288622=:22875
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-247393973-1415288622=:22875--


From xen-devel-bounces@lists.xen.org Thu Nov 06 15:48:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:48:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPIe-0007gY-Qc; Thu, 06 Nov 2014 15:48: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@citrix.com>) id 1XmPIb-0007gS-01
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:48:37 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	4B/B5-14214-4589B545; Thu, 06 Nov 2014 15:48:36 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415288912!10915330!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8560 invoked from network); 6 Nov 2014 15:48:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:48:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190225049"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:48:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmPIV-0001AG-28;
	Thu, 06 Nov 2014 15:48:31 +0000
Date: Thu, 6 Nov 2014 15:48:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: manish jaggi <manishjaggi.oss@gmail.com>
In-Reply-To: <CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>
	<CAAiw7Jmg+p0--fFYcRnMDA2DdQ7Ss5zjH9iuLHeX=TpBPZYGbA@mail.gmail.com>
	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>
	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>
	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ryan Wilson <hap9@epoch.ncsc.mil>, Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>, JBeulich@suse.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, manish jaggi wrote:
> On 20 October 2014 20:24, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 20 Oct 2014, manish jaggi wrote:
> >> On 8 October 2014 20:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
> >> >> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >> > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
> >> >> >> Thanks for replying. As detailed in this thread, I need to create a
> >> >> >> hypercall that would send the following information to Xen at the time
> >> >> >> of PCI attach
> >> >> >> { sbdf , domU sbdf, domainId }.
> >> >> >> I am not able to find a way to get the domU sbdf from dom0 at the time
> >> >> >> of pci-attach.
> >> >> >
> >> >> > I think it would need to be done by the pciback driver in the dom0
> >> >> > kernel, which AFAIK is the thing which consistently knows both physical
> >> >> > and virtual sbdf for a given assigned device.
> >> >> >
> >> >> > Ian.
> >> >> >
> >> >> Correct, can you point out which data structure holds the domU sbdf
> >> >> corresponding to the actual sbdf in pciback.
> >> >
> >> > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
> >> > is that what you are referring to?
> >>
> >> Xen docs also mention about xen-pciback.passthrough=1. If I set this
> >> in dom0 i see that the device is enumerated as the same sbdf in domU,
> >> but
> >> a) it is not shown in lspci
> >> b) no front-back communication is done for reading devices configuration space
> >> .
> >> Is option useful / fully implemented for ARM ?
> >
> > I don't think this option is very useful. I wouldn't worry about it for
> > now.
> 
> Stefano / Ian / Konard / Julien,
> 
> Attached is a first raw code FYI RFC Patches of PCI passthrough support on ARM.
> - Linux Patch (3.18)
> - Xen Patch  (4.5 staging)
> ---(Smmu changes not included, thats a separate patch altogether)
> This patches show the logic, at places need of improvements in code
> organization/quality. I wanted to share to get initial comments.
> This is working with SRIOV as well.
> 
> Please have a look and let me know your positive comments

Please send as individual inline patches. not attachments.
Please also add a proper description to each patch and an entry 0/N email
with the high level explanation of your work.

See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:48:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:48:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPIe-0007gY-Qc; Thu, 06 Nov 2014 15:48: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@citrix.com>) id 1XmPIb-0007gS-01
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:48:37 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	4B/B5-14214-4589B545; Thu, 06 Nov 2014 15:48:36 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415288912!10915330!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8560 invoked from network); 6 Nov 2014 15:48:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:48:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190225049"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:48:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmPIV-0001AG-28;
	Thu, 06 Nov 2014 15:48:31 +0000
Date: Thu, 6 Nov 2014 15:48:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: manish jaggi <manishjaggi.oss@gmail.com>
In-Reply-To: <CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>
	<CAAiw7Jmg+p0--fFYcRnMDA2DdQ7Ss5zjH9iuLHeX=TpBPZYGbA@mail.gmail.com>
	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>
	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>
	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ryan Wilson <hap9@epoch.ncsc.mil>, Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>, JBeulich@suse.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, manish jaggi wrote:
> On 20 October 2014 20:24, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 20 Oct 2014, manish jaggi wrote:
> >> On 8 October 2014 20:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
> >> >> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >> > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
> >> >> >> Thanks for replying. As detailed in this thread, I need to create a
> >> >> >> hypercall that would send the following information to Xen at the time
> >> >> >> of PCI attach
> >> >> >> { sbdf , domU sbdf, domainId }.
> >> >> >> I am not able to find a way to get the domU sbdf from dom0 at the time
> >> >> >> of pci-attach.
> >> >> >
> >> >> > I think it would need to be done by the pciback driver in the dom0
> >> >> > kernel, which AFAIK is the thing which consistently knows both physical
> >> >> > and virtual sbdf for a given assigned device.
> >> >> >
> >> >> > Ian.
> >> >> >
> >> >> Correct, can you point out which data structure holds the domU sbdf
> >> >> corresponding to the actual sbdf in pciback.
> >> >
> >> > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
> >> > is that what you are referring to?
> >>
> >> Xen docs also mention about xen-pciback.passthrough=1. If I set this
> >> in dom0 i see that the device is enumerated as the same sbdf in domU,
> >> but
> >> a) it is not shown in lspci
> >> b) no front-back communication is done for reading devices configuration space
> >> .
> >> Is option useful / fully implemented for ARM ?
> >
> > I don't think this option is very useful. I wouldn't worry about it for
> > now.
> 
> Stefano / Ian / Konard / Julien,
> 
> Attached is a first raw code FYI RFC Patches of PCI passthrough support on ARM.
> - Linux Patch (3.18)
> - Xen Patch  (4.5 staging)
> ---(Smmu changes not included, thats a separate patch altogether)
> This patches show the logic, at places need of improvements in code
> organization/quality. I wanted to share to get initial comments.
> This is working with SRIOV as well.
> 
> Please have a look and let me know your positive comments

Please send as individual inline patches. not attachments.
Please also add a proper description to each patch and an entry 0/N email
with the high level explanation of your work.

See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:49:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPJV-0007kk-8H; Thu, 06 Nov 2014 15:49:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmPJT-0007kX-0R
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:49:31 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	0F/C8-22819-A889B545; Thu, 06 Nov 2014 15:49:30 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415288968!10901372!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4799 invoked from network); 6 Nov 2014 15:49:29 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-5.tower-206.messagelabs.com with SMTP;
	6 Nov 2014 15:49:29 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 06 Nov 2014 07:46:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,326,1413270000"; d="scan'208";a="632693289"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga002.jf.intel.com with ESMTP; 06 Nov 2014 07:49:01 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 23:48:54 +0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 23:48:53 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id
	14.03.0195.001; Thu, 6 Nov 2014 23:48:46 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP91zOKlhH4xypD06jTqC2+4O7eZxTR+ug///zjQCAAId7cA==
Date: Thu, 6 Nov 2014 15:48:45 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820C61@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8206C2@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411061537320.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411061537320.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Thursday, November 06, 2014 11:42 PM
> To: Xu, Quan
> Cc: Stefano Stabellini; qemu-devel@nongnu.org; xen-devel@lists.xen.org
> Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> On Thu, 6 Nov 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Monday, November 03, 2014 7:54 PM
> > > To: Xu, Quan
> > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > > stefano.stabellini@eu.citrix.com
> > > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > > frontend driver
> > >
> > > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > > This drvier transfers any request/repond between TPM xenstubdoms
> > > > driver and Xen vTPM stubdom, and facilitates communications
> > > > between Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > > >
> > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > >
> > > Please describe what changes did make to xen_backend.c and why.
> > > The commit message should contains info on all the changes made by
> > > the patch below.
> > >
> >
> > The following is code process when Qemu is running with Xen.
> > ##code process
> > [...]
> >  xen_hvm_init()
> >     -->xen_be_register()
> >         -->xenstore_scan()
> >             -->xen_be_check_state()
> >
> >     -->xen_vtpm_register()
> >
> > ideally, I can register 'vtpm' via xen_vtpm_register() as
> >
> > + xen_be_register("console", &xen_console_ops);
> > + xen_be_register("vkbd", &xen_kbdmouse_ops); xen_be_register("qdisk",
> > + &xen_blkdev_ops);
> >
> > but there are 2 reasons why I add xen_vtpm_register(), instead of
> > xen_be_register().
> >
> > 1. The backend of TPM is runing in a Xen stubDom, not Domain 0.
> > some functions are not working, for example 'setup watch' and 'look
> > for backend' in xenstore_scan()
> >
> > 2. there is a thread runing in Xen stubDom [event_thread()], it will
> > handle backend status when the frontend is initialized. It is not
> > compatible with xen_be_check_state(). xen_be_check_state() always
> > tries to modify the status of backend.
> >
> > as there is always a tradeoff, if I force to integrate this case into
> > xen_be_register(), there are maybe a lot of 'if ... else.. '. It will
> > break the code architecture. Also I should leverage existing source
> > code with minimum modifcation. i add 'DEVOPS_FLAG_STUBDOM_BE' flag
> in
> > include/hw/xen/xen_backend.h to indicate that device backend is Xen
> > stubDom.
> 
> Given that xen_vtpm_register is actually registering a frontend, not a
> backend, you cannot use xen_be_register for it.
> 
> However instead of introducing xen_vtpm_register, I think you should be
> adding a generic xen_fe_register function that handle any Xen PV frontend
> registration. It should also be able to handle backends not in Dom0. Then you
> can call:
> 
> xen_fe_register("console", &xen_vtpm_ops);

  xen_fe_register("vtpm", &xen_vtpm_ops); ?

A good solution, I will try to add a generic xen_fe_register function that handle any Xen PV frontend in v2.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:49:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPJV-0007kk-8H; Thu, 06 Nov 2014 15:49:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmPJT-0007kX-0R
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:49:31 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	0F/C8-22819-A889B545; Thu, 06 Nov 2014 15:49:30 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415288968!10901372!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4799 invoked from network); 6 Nov 2014 15:49:29 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-5.tower-206.messagelabs.com with SMTP;
	6 Nov 2014 15:49:29 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 06 Nov 2014 07:46:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,326,1413270000"; d="scan'208";a="632693289"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga002.jf.intel.com with ESMTP; 06 Nov 2014 07:49:01 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 23:48:54 +0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 6 Nov 2014 23:48:53 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id
	14.03.0195.001; Thu, 6 Nov 2014 23:48:46 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
	driver
Thread-Index: AQHP91zOKlhH4xypD06jTqC2+4O7eZxTR+ug///zjQCAAId7cA==
Date: Thu, 6 Nov 2014 15:48:45 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820C61@SHSMSX101.ccr.corp.intel.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8206C2@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411061537320.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411061537320.22875@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Thursday, November 06, 2014 11:42 PM
> To: Xu, Quan
> Cc: Stefano Stabellini; qemu-devel@nongnu.org; xen-devel@lists.xen.org
> Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> On Thu, 6 Nov 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Monday, November 03, 2014 7:54 PM
> > > To: Xu, Quan
> > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > > stefano.stabellini@eu.citrix.com
> > > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > > frontend driver
> > >
> > > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > > This drvier transfers any request/repond between TPM xenstubdoms
> > > > driver and Xen vTPM stubdom, and facilitates communications
> > > > between Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > > >
> > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > >
> > > Please describe what changes did make to xen_backend.c and why.
> > > The commit message should contains info on all the changes made by
> > > the patch below.
> > >
> >
> > The following is code process when Qemu is running with Xen.
> > ##code process
> > [...]
> >  xen_hvm_init()
> >     -->xen_be_register()
> >         -->xenstore_scan()
> >             -->xen_be_check_state()
> >
> >     -->xen_vtpm_register()
> >
> > ideally, I can register 'vtpm' via xen_vtpm_register() as
> >
> > + xen_be_register("console", &xen_console_ops);
> > + xen_be_register("vkbd", &xen_kbdmouse_ops); xen_be_register("qdisk",
> > + &xen_blkdev_ops);
> >
> > but there are 2 reasons why I add xen_vtpm_register(), instead of
> > xen_be_register().
> >
> > 1. The backend of TPM is runing in a Xen stubDom, not Domain 0.
> > some functions are not working, for example 'setup watch' and 'look
> > for backend' in xenstore_scan()
> >
> > 2. there is a thread runing in Xen stubDom [event_thread()], it will
> > handle backend status when the frontend is initialized. It is not
> > compatible with xen_be_check_state(). xen_be_check_state() always
> > tries to modify the status of backend.
> >
> > as there is always a tradeoff, if I force to integrate this case into
> > xen_be_register(), there are maybe a lot of 'if ... else.. '. It will
> > break the code architecture. Also I should leverage existing source
> > code with minimum modifcation. i add 'DEVOPS_FLAG_STUBDOM_BE' flag
> in
> > include/hw/xen/xen_backend.h to indicate that device backend is Xen
> > stubDom.
> 
> Given that xen_vtpm_register is actually registering a frontend, not a
> backend, you cannot use xen_be_register for it.
> 
> However instead of introducing xen_vtpm_register, I think you should be
> adding a generic xen_fe_register function that handle any Xen PV frontend
> registration. It should also be able to handle backends not in Dom0. Then you
> can call:
> 
> xen_fe_register("console", &xen_vtpm_ops);

  xen_fe_register("vtpm", &xen_vtpm_ops); ?

A good solution, I will try to add a generic xen_fe_register function that handle any Xen PV frontend in v2.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:54:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPNo-00088o-1G; Thu, 06 Nov 2014 15:54:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmPNn-00088W-7x
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:53:59 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	9B/AC-08051-6999B545; Thu, 06 Nov 2014 15:53:58 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415289236!11881890!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24759 invoked from network); 6 Nov 2014 15:53:57 -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;
	6 Nov 2014 15:53:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188809900"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:53:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmPNh-0001Fy-5P;
	Thu, 06 Nov 2014 15:53:53 +0000
Date: Thu, 6 Nov 2014 15:53:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Quan" <quan.xu@intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E820C61@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411061553180.22875@kaball.uk.xensource.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8206C2@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411061537320.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E820C61@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Thursday, November 06, 2014 11:42 PM
> > To: Xu, Quan
> > Cc: Stefano Stabellini; qemu-devel@nongnu.org; xen-devel@lists.xen.org
> > Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > frontend driver
> > 
> > On Thu, 6 Nov 2014, Xu, Quan wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Monday, November 03, 2014 7:54 PM
> > > > To: Xu, Quan
> > > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > > > stefano.stabellini@eu.citrix.com
> > > > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > > > frontend driver
> > > >
> > > > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > > > This drvier transfers any request/repond between TPM xenstubdoms
> > > > > driver and Xen vTPM stubdom, and facilitates communications
> > > > > between Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > > > >
> > > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > >
> > > > Please describe what changes did make to xen_backend.c and why.
> > > > The commit message should contains info on all the changes made by
> > > > the patch below.
> > > >
> > >
> > > The following is code process when Qemu is running with Xen.
> > > ##code process
> > > [...]
> > >  xen_hvm_init()
> > >     -->xen_be_register()
> > >         -->xenstore_scan()
> > >             -->xen_be_check_state()
> > >
> > >     -->xen_vtpm_register()
> > >
> > > ideally, I can register 'vtpm' via xen_vtpm_register() as
> > >
> > > + xen_be_register("console", &xen_console_ops);
> > > + xen_be_register("vkbd", &xen_kbdmouse_ops); xen_be_register("qdisk",
> > > + &xen_blkdev_ops);
> > >
> > > but there are 2 reasons why I add xen_vtpm_register(), instead of
> > > xen_be_register().
> > >
> > > 1. The backend of TPM is runing in a Xen stubDom, not Domain 0.
> > > some functions are not working, for example 'setup watch' and 'look
> > > for backend' in xenstore_scan()
> > >
> > > 2. there is a thread runing in Xen stubDom [event_thread()], it will
> > > handle backend status when the frontend is initialized. It is not
> > > compatible with xen_be_check_state(). xen_be_check_state() always
> > > tries to modify the status of backend.
> > >
> > > as there is always a tradeoff, if I force to integrate this case into
> > > xen_be_register(), there are maybe a lot of 'if ... else.. '. It will
> > > break the code architecture. Also I should leverage existing source
> > > code with minimum modifcation. i add 'DEVOPS_FLAG_STUBDOM_BE' flag
> > in
> > > include/hw/xen/xen_backend.h to indicate that device backend is Xen
> > > stubDom.
> > 
> > Given that xen_vtpm_register is actually registering a frontend, not a
> > backend, you cannot use xen_be_register for it.
> > 
> > However instead of introducing xen_vtpm_register, I think you should be
> > adding a generic xen_fe_register function that handle any Xen PV frontend
> > registration. It should also be able to handle backends not in Dom0. Then you
> > can call:
> > 
> > xen_fe_register("console", &xen_vtpm_ops);
> 
>   xen_fe_register("vtpm", &xen_vtpm_ops); ?

Yes, that is what I meant, sorry.

> A good solution, I will try to add a generic xen_fe_register function that handle any Xen PV frontend in v2.

Cool, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:54:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPNo-00088o-1G; Thu, 06 Nov 2014 15:54:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmPNn-00088W-7x
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:53:59 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	9B/AC-08051-6999B545; Thu, 06 Nov 2014 15:53:58 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415289236!11881890!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24759 invoked from network); 6 Nov 2014 15:53:57 -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;
	6 Nov 2014 15:53:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188809900"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 10:53:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmPNh-0001Fy-5P;
	Thu, 06 Nov 2014 15:53:53 +0000
Date: Thu, 6 Nov 2014 15:53:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Quan" <quan.xu@intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E820C61@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411061553180.22875@kaball.uk.xensource.com>
References: <1414910365-27720-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411031132340.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8206C2@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411061537320.22875@kaball.uk.xensource.com>
	<945CA011AD5F084CBEA3E851C0AB28890E820C61@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom
 vTPM frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Thursday, November 06, 2014 11:42 PM
> > To: Xu, Quan
> > Cc: Stefano Stabellini; qemu-devel@nongnu.org; xen-devel@lists.xen.org
> > Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > frontend driver
> > 
> > On Thu, 6 Nov 2014, Xu, Quan wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Monday, November 03, 2014 7:54 PM
> > > > To: Xu, Quan
> > > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > > > stefano.stabellini@eu.citrix.com
> > > > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > > > frontend driver
> > > >
> > > > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > > > This drvier transfers any request/repond between TPM xenstubdoms
> > > > > driver and Xen vTPM stubdom, and facilitates communications
> > > > > between Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > > > >
> > > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > >
> > > > Please describe what changes did make to xen_backend.c and why.
> > > > The commit message should contains info on all the changes made by
> > > > the patch below.
> > > >
> > >
> > > The following is code process when Qemu is running with Xen.
> > > ##code process
> > > [...]
> > >  xen_hvm_init()
> > >     -->xen_be_register()
> > >         -->xenstore_scan()
> > >             -->xen_be_check_state()
> > >
> > >     -->xen_vtpm_register()
> > >
> > > ideally, I can register 'vtpm' via xen_vtpm_register() as
> > >
> > > + xen_be_register("console", &xen_console_ops);
> > > + xen_be_register("vkbd", &xen_kbdmouse_ops); xen_be_register("qdisk",
> > > + &xen_blkdev_ops);
> > >
> > > but there are 2 reasons why I add xen_vtpm_register(), instead of
> > > xen_be_register().
> > >
> > > 1. The backend of TPM is runing in a Xen stubDom, not Domain 0.
> > > some functions are not working, for example 'setup watch' and 'look
> > > for backend' in xenstore_scan()
> > >
> > > 2. there is a thread runing in Xen stubDom [event_thread()], it will
> > > handle backend status when the frontend is initialized. It is not
> > > compatible with xen_be_check_state(). xen_be_check_state() always
> > > tries to modify the status of backend.
> > >
> > > as there is always a tradeoff, if I force to integrate this case into
> > > xen_be_register(), there are maybe a lot of 'if ... else.. '. It will
> > > break the code architecture. Also I should leverage existing source
> > > code with minimum modifcation. i add 'DEVOPS_FLAG_STUBDOM_BE' flag
> > in
> > > include/hw/xen/xen_backend.h to indicate that device backend is Xen
> > > stubDom.
> > 
> > Given that xen_vtpm_register is actually registering a frontend, not a
> > backend, you cannot use xen_be_register for it.
> > 
> > However instead of introducing xen_vtpm_register, I think you should be
> > adding a generic xen_fe_register function that handle any Xen PV frontend
> > registration. It should also be able to handle backends not in Dom0. Then you
> > can call:
> > 
> > xen_fe_register("console", &xen_vtpm_ops);
> 
>   xen_fe_register("vtpm", &xen_vtpm_ops); ?

Yes, that is what I meant, sorry.

> A good solution, I will try to add a generic xen_fe_register function that handle any Xen PV frontend in v2.

Cool, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:55:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPPf-0008LN-Jg; Thu, 06 Nov 2014 15:55:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XmPPe-0008LD-9j
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:55:54 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B7/E3-24532-90A9B545; Thu, 06 Nov 2014 15:55:53 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415289352!12002324!1
X-Originating-IP: [209.85.220.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10441 invoked from network); 6 Nov 2014 15:55:53 -0000
Received: from mail-vc0-f179.google.com (HELO mail-vc0-f179.google.com)
	(209.85.220.179)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:55:53 -0000
Received: by mail-vc0-f179.google.com with SMTP id ij19so667208vcb.24
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:55:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=jFzUBxVh7lTZnOrGhAtGi9Rk6Mg3TOKEsdeqfmyTIgs=;
	b=ZABgthCAaU4/KoDGBfiqqr0m0JH/pJdOCb+wh1JAvJ3AUwplA3ojkmjp4yE92vuv5M
	f3ZlFzkBvD0BXdl0t5/n00+cW6y/jWHh7zFA1sIGqguFT/WLnPq7JzI/9cDeA91EtRUF
	8cgxYs/eLw2Hcq+esRJOaVenJ2Gnkrpk0i97ro4kTJXhlZI9Zt1hBDNYPUanbql85taQ
	6bugNzi57fLlR0zKq0PAkWB0HLwypc1PNqpWjAe+UJ8U6g6IYFMDUuQbRigkS9qoSTmG
	BWQ+z/OCGn5uQ4oQ6Ov2N+b/E+fBKNgnIzZwEb65Y/BgP0r1gtV4OfI4EfemL9/Wz8Qb
	B6eg==
MIME-Version: 1.0
X-Received: by 10.220.195.132 with SMTP id ec4mr3492883vcb.16.1415289352112;
	Thu, 06 Nov 2014 07:55:52 -0800 (PST)
Received: by 10.221.57.8 with HTTP; Thu, 6 Nov 2014 07:55:51 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>
	<CAAiw7Jmg+p0--fFYcRnMDA2DdQ7Ss5zjH9iuLHeX=TpBPZYGbA@mail.gmail.com>
	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>
	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>
	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
	<alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
Date: Thu, 6 Nov 2014 21:25:51 +0530
Message-ID: <CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ryan Wilson <hap9@epoch.ncsc.mil>, Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>, JBeulich@suse.com
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in 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 6 November 2014 21:18, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, manish jaggi wrote:
>> On 20 October 2014 20:24, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Mon, 20 Oct 2014, manish jaggi wrote:
>> >> On 8 October 2014 20:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> >> > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
>> >> >> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> >> > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
>> >> >> >> Thanks for replying. As detailed in this thread, I need to create a
>> >> >> >> hypercall that would send the following information to Xen at the time
>> >> >> >> of PCI attach
>> >> >> >> { sbdf , domU sbdf, domainId }.
>> >> >> >> I am not able to find a way to get the domU sbdf from dom0 at the time
>> >> >> >> of pci-attach.
>> >> >> >
>> >> >> > I think it would need to be done by the pciback driver in the dom0
>> >> >> > kernel, which AFAIK is the thing which consistently knows both physical
>> >> >> > and virtual sbdf for a given assigned device.
>> >> >> >
>> >> >> > Ian.
>> >> >> >
>> >> >> Correct, can you point out which data structure holds the domU sbdf
>> >> >> corresponding to the actual sbdf in pciback.
>> >> >
>> >> > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
>> >> > is that what you are referring to?
>> >>
>> >> Xen docs also mention about xen-pciback.passthrough=1. If I set this
>> >> in dom0 i see that the device is enumerated as the same sbdf in domU,
>> >> but
>> >> a) it is not shown in lspci
>> >> b) no front-back communication is done for reading devices configuration space
>> >> .
>> >> Is option useful / fully implemented for ARM ?
>> >
>> > I don't think this option is very useful. I wouldn't worry about it for
>> > now.
>>
>> Stefano / Ian / Konard / Julien,
>>
>> Attached is a first raw code FYI RFC Patches of PCI passthrough support on ARM.
>> - Linux Patch (3.18)
>> - Xen Patch  (4.5 staging)
>> ---(Smmu changes not included, thats a separate patch altogether)
>> This patches show the logic, at places need of improvements in code
>> organization/quality. I wanted to share to get initial comments.
>> This is working with SRIOV as well.
>>
>> Please have a look and let me know your positive comments
>
> Please send as individual inline patches. not attachments.
> Please also add a proper description to each patch and an entry 0/N email
> with the high level explanation of your work.
>
> See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
Stefano I just wanted to share the patches as reference to our
discussion on the approach. Please recall I had shared in this mail a
design flow. These are just an extension to it. I wanted to move this
discussion to a conclusion

There are not patches which I am submitting to xen git.
If you are ok with the approach I will formally send the patches post
4.5 release.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 15:55:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 15:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPPf-0008LN-Jg; Thu, 06 Nov 2014 15:55:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XmPPe-0008LD-9j
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 15:55:54 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B7/E3-24532-90A9B545; Thu, 06 Nov 2014 15:55:53 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415289352!12002324!1
X-Originating-IP: [209.85.220.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10441 invoked from network); 6 Nov 2014 15:55:53 -0000
Received: from mail-vc0-f179.google.com (HELO mail-vc0-f179.google.com)
	(209.85.220.179)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 15:55:53 -0000
Received: by mail-vc0-f179.google.com with SMTP id ij19so667208vcb.24
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 07:55:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=jFzUBxVh7lTZnOrGhAtGi9Rk6Mg3TOKEsdeqfmyTIgs=;
	b=ZABgthCAaU4/KoDGBfiqqr0m0JH/pJdOCb+wh1JAvJ3AUwplA3ojkmjp4yE92vuv5M
	f3ZlFzkBvD0BXdl0t5/n00+cW6y/jWHh7zFA1sIGqguFT/WLnPq7JzI/9cDeA91EtRUF
	8cgxYs/eLw2Hcq+esRJOaVenJ2Gnkrpk0i97ro4kTJXhlZI9Zt1hBDNYPUanbql85taQ
	6bugNzi57fLlR0zKq0PAkWB0HLwypc1PNqpWjAe+UJ8U6g6IYFMDUuQbRigkS9qoSTmG
	BWQ+z/OCGn5uQ4oQ6Ov2N+b/E+fBKNgnIzZwEb65Y/BgP0r1gtV4OfI4EfemL9/Wz8Qb
	B6eg==
MIME-Version: 1.0
X-Received: by 10.220.195.132 with SMTP id ec4mr3492883vcb.16.1415289352112;
	Thu, 06 Nov 2014 07:55:52 -0800 (PST)
Received: by 10.221.57.8 with HTTP; Thu, 6 Nov 2014 07:55:51 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>
	<CAAiw7Jmg+p0--fFYcRnMDA2DdQ7Ss5zjH9iuLHeX=TpBPZYGbA@mail.gmail.com>
	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>
	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>
	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
	<alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
Date: Thu, 6 Nov 2014 21:25:51 +0530
Message-ID: <CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ryan Wilson <hap9@epoch.ncsc.mil>, Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>, JBeulich@suse.com
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in 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 6 November 2014 21:18, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, manish jaggi wrote:
>> On 20 October 2014 20:24, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Mon, 20 Oct 2014, manish jaggi wrote:
>> >> On 8 October 2014 20:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> >> > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
>> >> >> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> >> > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
>> >> >> >> Thanks for replying. As detailed in this thread, I need to create a
>> >> >> >> hypercall that would send the following information to Xen at the time
>> >> >> >> of PCI attach
>> >> >> >> { sbdf , domU sbdf, domainId }.
>> >> >> >> I am not able to find a way to get the domU sbdf from dom0 at the time
>> >> >> >> of pci-attach.
>> >> >> >
>> >> >> > I think it would need to be done by the pciback driver in the dom0
>> >> >> > kernel, which AFAIK is the thing which consistently knows both physical
>> >> >> > and virtual sbdf for a given assigned device.
>> >> >> >
>> >> >> > Ian.
>> >> >> >
>> >> >> Correct, can you point out which data structure holds the domU sbdf
>> >> >> corresponding to the actual sbdf in pciback.
>> >> >
>> >> > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
>> >> > is that what you are referring to?
>> >>
>> >> Xen docs also mention about xen-pciback.passthrough=1. If I set this
>> >> in dom0 i see that the device is enumerated as the same sbdf in domU,
>> >> but
>> >> a) it is not shown in lspci
>> >> b) no front-back communication is done for reading devices configuration space
>> >> .
>> >> Is option useful / fully implemented for ARM ?
>> >
>> > I don't think this option is very useful. I wouldn't worry about it for
>> > now.
>>
>> Stefano / Ian / Konard / Julien,
>>
>> Attached is a first raw code FYI RFC Patches of PCI passthrough support on ARM.
>> - Linux Patch (3.18)
>> - Xen Patch  (4.5 staging)
>> ---(Smmu changes not included, thats a separate patch altogether)
>> This patches show the logic, at places need of improvements in code
>> organization/quality. I wanted to share to get initial comments.
>> This is working with SRIOV as well.
>>
>> Please have a look and let me know your positive comments
>
> Please send as individual inline patches. not attachments.
> Please also add a proper description to each patch and an entry 0/N email
> with the high level explanation of your work.
>
> See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
Stefano I just wanted to share the patches as reference to our
discussion on the approach. Please recall I had shared in this mail a
design flow. These are just an extension to it. I wanted to move this
discussion to a conclusion

There are not patches which I am submitting to xen git.
If you are ok with the approach I will formally send the patches post
4.5 release.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:01:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPUm-0000Nv-KB; Thu, 06 Nov 2014 16:01:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1XmPUl-0000Nq-GY
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:01:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	33/74-09842-64B9B545; Thu, 06 Nov 2014 16:01:10 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415289670!11650990!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30737 invoked from network); 6 Nov 2014 16:01:10 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 16:01:10 -0000
Received: by mail-wg0-f44.google.com with SMTP id x12so1574939wgg.3
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 08:01:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=duhje6Db8nM8XEfrr3UgJhiBFf1auwlpUUq+EpqMjAo=;
	b=M3kFOjt9Oif2Dxh9OGwLnkf3fIdpjlpAy7cV4WfLWnKhWs566HSVwt46Og8Kxicu05
	0WQJq6K37RyPh1+BH38JPKpbyNONk+sdHUeT1WW6hSP+6Xhi03hU4fMlCE8rNrsiu6zl
	aoynYESKH1Ev2GnY4mjEfpUN/wT+rDGprLick4seEUeqOlLACu5RVyHe7XkfGuMAAv3N
	Rft4dReqjXqvYiypjTHJmAHD+9MVPk6pFITVRaEYDPkZjTrfEvrXe2NQqIAu1+NsskhN
	m+1WkbbbyvbiloXl7PRcEn0DmwY+jxNfwgXbNmkA4USpcw6jF0iY6q4u71i7vMcArkWf
	Iplg==
X-Received: by 10.180.126.37 with SMTP id mv5mr29907645wib.2.1415289669745;
	Thu, 06 Nov 2014 08:01:09 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id r6sm2481921wif.0.2014.11.06.08.01.06
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 06 Nov 2014 08:01:07 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Lars Kurth <lars.kurth.xen@gmail.com>
In-Reply-To: <1415186272.15317.5.camel@citrix.com>
Date: Thu, 6 Nov 2014 16:01:04 +0000
Message-Id: <0E6C0A5F-0FE6-42A6-BD57-60ADB3D21B82@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<21586.10214.683512.296628@chiark.greenend.org.uk>
	<20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
	<1415186272.15317.5.camel@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1878.6)
Cc: Matt Wilson <msw@linux.com>, Ian Jackson <ijackson@chiark.greenend.org.uk>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 5 Nov 2014, at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
>> I think that we should reduce any burden on the security team by
>> making this a community decision that is discussed in public, rather
>> than something that is handled exclusively in a closed manner as it is
>> today. This way others who are active community participants can help
>> with the decision making process can do the investigation and weigh in
>> on the risk/benefit tradeoff to the security process and the
>> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
>> or [1] if you are willing to visit a URL. ;-)
>> 
>> There's been a bit of talk about "delay" and so on. I'd rather not set
>> expectations on how long the processing a petition to be added to the
>> predisclosure list should take. Building community consensus takes
>> time, just as it does for
> 
> I think regardless of who is processing the applications what is more
> important is to have a concrete set of *objective* criteria. Anyone who
> demonstrates that they meet those criteria must be allowed to join.

I don't think that having applications discussed and processed on a dedicated public list and objective criteria are mutually exclusive. The two may provide a good balance, and allow for some flexibility in ambiguous cases. 

In particular if we either have a strong owner or follow the "two +1 with no -1" model of a set of decision makers who earned that status over time. More or less what we use for access to Coverity Scan output. 

Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:01:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPUm-0000Nv-KB; Thu, 06 Nov 2014 16:01:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1XmPUl-0000Nq-GY
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:01:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	33/74-09842-64B9B545; Thu, 06 Nov 2014 16:01:10 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415289670!11650990!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30737 invoked from network); 6 Nov 2014 16:01:10 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 16:01:10 -0000
Received: by mail-wg0-f44.google.com with SMTP id x12so1574939wgg.3
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 08:01:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=duhje6Db8nM8XEfrr3UgJhiBFf1auwlpUUq+EpqMjAo=;
	b=M3kFOjt9Oif2Dxh9OGwLnkf3fIdpjlpAy7cV4WfLWnKhWs566HSVwt46Og8Kxicu05
	0WQJq6K37RyPh1+BH38JPKpbyNONk+sdHUeT1WW6hSP+6Xhi03hU4fMlCE8rNrsiu6zl
	aoynYESKH1Ev2GnY4mjEfpUN/wT+rDGprLick4seEUeqOlLACu5RVyHe7XkfGuMAAv3N
	Rft4dReqjXqvYiypjTHJmAHD+9MVPk6pFITVRaEYDPkZjTrfEvrXe2NQqIAu1+NsskhN
	m+1WkbbbyvbiloXl7PRcEn0DmwY+jxNfwgXbNmkA4USpcw6jF0iY6q4u71i7vMcArkWf
	Iplg==
X-Received: by 10.180.126.37 with SMTP id mv5mr29907645wib.2.1415289669745;
	Thu, 06 Nov 2014 08:01:09 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id r6sm2481921wif.0.2014.11.06.08.01.06
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 06 Nov 2014 08:01:07 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Lars Kurth <lars.kurth.xen@gmail.com>
In-Reply-To: <1415186272.15317.5.camel@citrix.com>
Date: Thu, 6 Nov 2014 16:01:04 +0000
Message-Id: <0E6C0A5F-0FE6-42A6-BD57-60ADB3D21B82@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<21586.10214.683512.296628@chiark.greenend.org.uk>
	<20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
	<1415186272.15317.5.camel@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1878.6)
Cc: Matt Wilson <msw@linux.com>, Ian Jackson <ijackson@chiark.greenend.org.uk>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 5 Nov 2014, at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
>> I think that we should reduce any burden on the security team by
>> making this a community decision that is discussed in public, rather
>> than something that is handled exclusively in a closed manner as it is
>> today. This way others who are active community participants can help
>> with the decision making process can do the investigation and weigh in
>> on the risk/benefit tradeoff to the security process and the
>> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
>> or [1] if you are willing to visit a URL. ;-)
>> 
>> There's been a bit of talk about "delay" and so on. I'd rather not set
>> expectations on how long the processing a petition to be added to the
>> predisclosure list should take. Building community consensus takes
>> time, just as it does for
> 
> I think regardless of who is processing the applications what is more
> important is to have a concrete set of *objective* criteria. Anyone who
> demonstrates that they meet those criteria must be allowed to join.

I don't think that having applications discussed and processed on a dedicated public list and objective criteria are mutually exclusive. The two may provide a good balance, and allow for some flexibility in ambiguous cases. 

In particular if we either have a strong owner or follow the "two +1 with no -1" model of a set of decision makers who earned that status over time. More or less what we use for access to Coverity Scan output. 

Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:02:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPWK-0000n3-J8; Thu, 06 Nov 2014 16:02:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmPWJ-0000mu-Jq
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:02:47 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	7B/02-03145-6AB9B545; Thu, 06 Nov 2014 16:02:46 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415289766!11884434!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9051 invoked from network); 6 Nov 2014 16:02:46 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 16:02:46 -0000
Received: by mail-wi0-f178.google.com with SMTP id bs8so1928023wib.17
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 08:02:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=CXkcn0yXhs5efeMPg91RYubeE+rlXbnr51hKyeL4kcw=;
	b=Sdv4G7ltL9xF1yT22H+l/uWxdM+44vpAsUO2Rqz55pAUWkl7CiKwWt6oZ2Co9Y1P9L
	VS/F66OW1kCfjdJoRWUT4RnTqu50kny24YthQiPc2ecHXkczjn2i1i0vvmor50U9uygh
	t5H8TZ5xnVy6ZCYoAMtSMPM9H6TfhjWUu1HPpUfAuLQTZ8mHL63k2blDcaEwhkxE/5Zn
	yaNDFTyqFMgBrEWhLMkXiAAtSjm/YgJzu/gf30vyoChGtTvEEYiwS0WXPF9xdZdaisCa
	rXHdJ0prTCswBhYLhsGgchzlppMhoEpWq/IzNqizYiLPrqH2Aoz8fneJB8gvcOcTpfTX
	g+JQ==
X-Gm-Message-State: ALoCoQk+obW5mhLqFb3/3uiBh5zRaikg5FJ7yWavZ6g1UNRq5P0HXgKnJWm5mpeVW2iALN+Nj2nR
X-Received: by 10.194.237.9 with SMTP id uy9mr6787476wjc.69.1415289763982;
	Thu, 06 Nov 2014 08:02:43 -0800 (PST)
Received: from [192.168.42.137] (92.40.249.244.threembb.co.uk. [92.40.249.244])
	by mx.google.com with ESMTPSA id i3sm20047792wix.0.2014.11.06.08.02.37
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 08:02:43 -0800 (PST)
Message-ID: <545B9B96.6080102@linaro.org>
Date: Thu, 06 Nov 2014 16:02:30 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>	<20141008124657.GB13391@laptop.dumpdata.com>	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>	<1412775916.24894.15.camel@citrix.com>	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>	<20141008145107.GC18573@laptop.dumpdata.com>	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>	<alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
	<CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>
In-Reply-To: <CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Ryan Wilson <hap9@epoch.ncsc.mil>,
	xen-devel <xen-devel@lists.xen.org>, JBeulich@suse.com
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Manish,

On 06/11/2014 15:55, manish jaggi wrote:
> On 6 November 2014 21:18, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Thu, 6 Nov 2014, manish jaggi wrote:
>>> On 20 October 2014 20:24, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>> On Mon, 20 Oct 2014, manish jaggi wrote:
>>>>> On 8 October 2014 20:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>>>>> On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
>>>>>>> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>>>>>>> On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
>>>>>>>>> Thanks for replying. As detailed in this thread, I need to create a
>>>>>>>>> hypercall that would send the following information to Xen at the time
>>>>>>>>> of PCI attach
>>>>>>>>> { sbdf , domU sbdf, domainId }.
>>>>>>>>> I am not able to find a way to get the domU sbdf from dom0 at the time
>>>>>>>>> of pci-attach.
>>>>>>>>
>>>>>>>> I think it would need to be done by the pciback driver in the dom0
>>>>>>>> kernel, which AFAIK is the thing which consistently knows both physical
>>>>>>>> and virtual sbdf for a given assigned device.
>>>>>>>>
>>>>>>>> Ian.
>>>>>>>>
>>>>>>> Correct, can you point out which data structure holds the domU sbdf
>>>>>>> corresponding to the actual sbdf in pciback.
>>>>>>
>>>>>> See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
>>>>>> is that what you are referring to?
>>>>>
>>>>> Xen docs also mention about xen-pciback.passthrough=1. If I set this
>>>>> in dom0 i see that the device is enumerated as the same sbdf in domU,
>>>>> but
>>>>> a) it is not shown in lspci
>>>>> b) no front-back communication is done for reading devices configuration space
>>>>> .
>>>>> Is option useful / fully implemented for ARM ?
>>>>
>>>> I don't think this option is very useful. I wouldn't worry about it for
>>>> now.
>>>
>>> Stefano / Ian / Konard / Julien,
>>>
>>> Attached is a first raw code FYI RFC Patches of PCI passthrough support on ARM.
>>> - Linux Patch (3.18)
>>> - Xen Patch  (4.5 staging)
>>> ---(Smmu changes not included, thats a separate patch altogether)
>>> This patches show the logic, at places need of improvements in code
>>> organization/quality. I wanted to share to get initial comments.
>>> This is working with SRIOV as well.
>>>
>>> Please have a look and let me know your positive comments
>>
>> Please send as individual inline patches. not attachments.
>> Please also add a proper description to each patch and an entry 0/N email
>> with the high level explanation of your work.
>>
>> See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
> Stefano I just wanted to share the patches as reference to our
> discussion on the approach. Please recall I had shared in this mail a
> design flow. These are just an extension to it. I wanted to move this
> discussion to a conclusion
> There are not patches which I am submitting to xen git.
> If you are ok with the approach I will formally send the patches post
> 4.5 release.

In this case you can send the patch series tagged "[RFC]" in the 
subject. It would better to start sending your patch series now, rather 
than post 4.5 release. So we can start to review it and maybe merge it 
as soon as 4.6 windows is opened.

I gave a quick look to the patch you provided. It looks like it depends 
on GICv3 ITS and maybe some SMMU patches? (I doubt the current driver is 
working out-of-box).

Please provide everything so we can try the patch series and have a 
better overview of the changes.

Regards,


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:02:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPWK-0000n3-J8; Thu, 06 Nov 2014 16:02:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XmPWJ-0000mu-Jq
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:02:47 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	7B/02-03145-6AB9B545; Thu, 06 Nov 2014 16:02:46 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415289766!11884434!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9051 invoked from network); 6 Nov 2014 16:02:46 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 16:02:46 -0000
Received: by mail-wi0-f178.google.com with SMTP id bs8so1928023wib.17
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 08:02:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=CXkcn0yXhs5efeMPg91RYubeE+rlXbnr51hKyeL4kcw=;
	b=Sdv4G7ltL9xF1yT22H+l/uWxdM+44vpAsUO2Rqz55pAUWkl7CiKwWt6oZ2Co9Y1P9L
	VS/F66OW1kCfjdJoRWUT4RnTqu50kny24YthQiPc2ecHXkczjn2i1i0vvmor50U9uygh
	t5H8TZ5xnVy6ZCYoAMtSMPM9H6TfhjWUu1HPpUfAuLQTZ8mHL63k2blDcaEwhkxE/5Zn
	yaNDFTyqFMgBrEWhLMkXiAAtSjm/YgJzu/gf30vyoChGtTvEEYiwS0WXPF9xdZdaisCa
	rXHdJ0prTCswBhYLhsGgchzlppMhoEpWq/IzNqizYiLPrqH2Aoz8fneJB8gvcOcTpfTX
	g+JQ==
X-Gm-Message-State: ALoCoQk+obW5mhLqFb3/3uiBh5zRaikg5FJ7yWavZ6g1UNRq5P0HXgKnJWm5mpeVW2iALN+Nj2nR
X-Received: by 10.194.237.9 with SMTP id uy9mr6787476wjc.69.1415289763982;
	Thu, 06 Nov 2014 08:02:43 -0800 (PST)
Received: from [192.168.42.137] (92.40.249.244.threembb.co.uk. [92.40.249.244])
	by mx.google.com with ESMTPSA id i3sm20047792wix.0.2014.11.06.08.02.37
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Nov 2014 08:02:43 -0800 (PST)
Message-ID: <545B9B96.6080102@linaro.org>
Date: Thu, 06 Nov 2014 16:02:30 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>	<20141008124657.GB13391@laptop.dumpdata.com>	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>	<1412775916.24894.15.camel@citrix.com>	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>	<20141008145107.GC18573@laptop.dumpdata.com>	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>	<alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
	<CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>
In-Reply-To: <CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Ryan Wilson <hap9@epoch.ncsc.mil>,
	xen-devel <xen-devel@lists.xen.org>, JBeulich@suse.com
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Manish,

On 06/11/2014 15:55, manish jaggi wrote:
> On 6 November 2014 21:18, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Thu, 6 Nov 2014, manish jaggi wrote:
>>> On 20 October 2014 20:24, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>> On Mon, 20 Oct 2014, manish jaggi wrote:
>>>>> On 8 October 2014 20:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>>>>> On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
>>>>>>> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>>>>>>> On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
>>>>>>>>> Thanks for replying. As detailed in this thread, I need to create a
>>>>>>>>> hypercall that would send the following information to Xen at the time
>>>>>>>>> of PCI attach
>>>>>>>>> { sbdf , domU sbdf, domainId }.
>>>>>>>>> I am not able to find a way to get the domU sbdf from dom0 at the time
>>>>>>>>> of pci-attach.
>>>>>>>>
>>>>>>>> I think it would need to be done by the pciback driver in the dom0
>>>>>>>> kernel, which AFAIK is the thing which consistently knows both physical
>>>>>>>> and virtual sbdf for a given assigned device.
>>>>>>>>
>>>>>>>> Ian.
>>>>>>>>
>>>>>>> Correct, can you point out which data structure holds the domU sbdf
>>>>>>> corresponding to the actual sbdf in pciback.
>>>>>>
>>>>>> See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
>>>>>> is that what you are referring to?
>>>>>
>>>>> Xen docs also mention about xen-pciback.passthrough=1. If I set this
>>>>> in dom0 i see that the device is enumerated as the same sbdf in domU,
>>>>> but
>>>>> a) it is not shown in lspci
>>>>> b) no front-back communication is done for reading devices configuration space
>>>>> .
>>>>> Is option useful / fully implemented for ARM ?
>>>>
>>>> I don't think this option is very useful. I wouldn't worry about it for
>>>> now.
>>>
>>> Stefano / Ian / Konard / Julien,
>>>
>>> Attached is a first raw code FYI RFC Patches of PCI passthrough support on ARM.
>>> - Linux Patch (3.18)
>>> - Xen Patch  (4.5 staging)
>>> ---(Smmu changes not included, thats a separate patch altogether)
>>> This patches show the logic, at places need of improvements in code
>>> organization/quality. I wanted to share to get initial comments.
>>> This is working with SRIOV as well.
>>>
>>> Please have a look and let me know your positive comments
>>
>> Please send as individual inline patches. not attachments.
>> Please also add a proper description to each patch and an entry 0/N email
>> with the high level explanation of your work.
>>
>> See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
> Stefano I just wanted to share the patches as reference to our
> discussion on the approach. Please recall I had shared in this mail a
> design flow. These are just an extension to it. I wanted to move this
> discussion to a conclusion
> There are not patches which I am submitting to xen git.
> If you are ok with the approach I will formally send the patches post
> 4.5 release.

In this case you can send the patch series tagged "[RFC]" in the 
subject. It would better to start sending your patch series now, rather 
than post 4.5 release. So we can start to review it and maybe merge it 
as soon as 4.6 windows is opened.

I gave a quick look to the patch you provided. It looks like it depends 
on GICv3 ITS and maybe some SMMU patches? (I doubt the current driver is 
working out-of-box).

Please provide everything so we can try the patch series and have a 
better overview of the changes.

Regards,


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:09:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:09:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPcr-0000zo-Im; Thu, 06 Nov 2014 16:09:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmPcq-0000zj-0M
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:09:32 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	BC/66-11608-B3D9B545; Thu, 06 Nov 2014 16:09:31 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415290167!10902819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8219 invoked from network); 6 Nov 2014 16:09:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 16:09:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188816680"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 11:07:50 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmPbB-0001UC-OA;
	Thu, 06 Nov 2014 16:07:49 +0000
Date: Thu, 6 Nov 2014 16:07:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <545B9B96.6080102@linaro.org>
Message-ID: <alpine.DEB.2.02.1411061607150.22875@kaball.uk.xensource.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>
	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>
	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>
	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
	<alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
	<CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>
	<545B9B96.6080102@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ryan Wilson <hap9@epoch.ncsc.mil>, Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com,
	xen-devel <xen-devel@lists.xen.org>, JBeulich@suse.com,
	manish jaggi <manishjaggi.oss@gmail.com>
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Julien Grall wrote:
> Hi Manish,
> 
> On 06/11/2014 15:55, manish jaggi wrote:
> > On 6 November 2014 21:18, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> > > On Thu, 6 Nov 2014, manish jaggi wrote:
> > > > On 20 October 2014 20:24, Stefano Stabellini
> > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > > On Mon, 20 Oct 2014, manish jaggi wrote:
> > > > > > On 8 October 2014 20:21, Konrad Rzeszutek Wilk
> > > > > > <konrad.wilk@oracle.com> wrote:
> > > > > > > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
> > > > > > > > On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com>
> > > > > > > > wrote:
> > > > > > > > > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
> > > > > > > > > > Thanks for replying. As detailed in this thread, I need to
> > > > > > > > > > create a
> > > > > > > > > > hypercall that would send the following information to Xen
> > > > > > > > > > at the time
> > > > > > > > > > of PCI attach
> > > > > > > > > > { sbdf , domU sbdf, domainId }.
> > > > > > > > > > I am not able to find a way to get the domU sbdf from dom0
> > > > > > > > > > at the time
> > > > > > > > > > of pci-attach.
> > > > > > > > > 
> > > > > > > > > I think it would need to be done by the pciback driver in the
> > > > > > > > > dom0
> > > > > > > > > kernel, which AFAIK is the thing which consistently knows both
> > > > > > > > > physical
> > > > > > > > > and virtual sbdf for a given assigned device.
> > > > > > > > > 
> > > > > > > > > Ian.
> > > > > > > > > 
> > > > > > > > Correct, can you point out which data structure holds the domU
> > > > > > > > sbdf
> > > > > > > > corresponding to the actual sbdf in pciback.
> > > > > > > 
> > > > > > > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
> > > > > > > is that what you are referring to?
> > > > > > 
> > > > > > Xen docs also mention about xen-pciback.passthrough=1. If I set this
> > > > > > in dom0 i see that the device is enumerated as the same sbdf in
> > > > > > domU,
> > > > > > but
> > > > > > a) it is not shown in lspci
> > > > > > b) no front-back communication is done for reading devices
> > > > > > configuration space
> > > > > > .
> > > > > > Is option useful / fully implemented for ARM ?
> > > > > 
> > > > > I don't think this option is very useful. I wouldn't worry about it
> > > > > for
> > > > > now.
> > > > 
> > > > Stefano / Ian / Konard / Julien,
> > > > 
> > > > Attached is a first raw code FYI RFC Patches of PCI passthrough support
> > > > on ARM.
> > > > - Linux Patch (3.18)
> > > > - Xen Patch  (4.5 staging)
> > > > ---(Smmu changes not included, thats a separate patch altogether)
> > > > This patches show the logic, at places need of improvements in code
> > > > organization/quality. I wanted to share to get initial comments.
> > > > This is working with SRIOV as well.
> > > > 
> > > > Please have a look and let me know your positive comments
> > > 
> > > Please send as individual inline patches. not attachments.
> > > Please also add a proper description to each patch and an entry 0/N email
> > > with the high level explanation of your work.
> > > 
> > > See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
> > Stefano I just wanted to share the patches as reference to our
> > discussion on the approach. Please recall I had shared in this mail a
> > design flow. These are just an extension to it. I wanted to move this
> > discussion to a conclusion
> > There are not patches which I am submitting to xen git.
> > If you are ok with the approach I will formally send the patches post
> > 4.5 release.
> 
> In this case you can send the patch series tagged "[RFC]" in the subject.

That's right. It is difficult to give even just an early feedback
without the patch descriptions.


> It
> would better to start sending your patch series now, rather than post 4.5
> release. So we can start to review it and maybe merge it as soon as 4.6
> windows is opened.
> 
> I gave a quick look to the patch you provided. It looks like it depends on
> GICv3 ITS and maybe some SMMU patches? (I doubt the current driver is working
> out-of-box).
> 
> Please provide everything so we can try the patch series and have a better
> overview of the changes.
> 
> Regards,
> 
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:09:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:09:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPcr-0000zo-Im; Thu, 06 Nov 2014 16:09:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmPcq-0000zj-0M
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:09:32 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	BC/66-11608-B3D9B545; Thu, 06 Nov 2014 16:09:31 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415290167!10902819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8219 invoked from network); 6 Nov 2014 16:09:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 16:09:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="188816680"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 11:07:50 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmPbB-0001UC-OA;
	Thu, 06 Nov 2014 16:07:49 +0000
Date: Thu, 6 Nov 2014 16:07:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <545B9B96.6080102@linaro.org>
Message-ID: <alpine.DEB.2.02.1411061607150.22875@kaball.uk.xensource.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>
	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>
	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>
	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
	<alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
	<CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>
	<545B9B96.6080102@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ryan Wilson <hap9@epoch.ncsc.mil>, Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com,
	xen-devel <xen-devel@lists.xen.org>, JBeulich@suse.com,
	manish jaggi <manishjaggi.oss@gmail.com>
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 6 Nov 2014, Julien Grall wrote:
> Hi Manish,
> 
> On 06/11/2014 15:55, manish jaggi wrote:
> > On 6 November 2014 21:18, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> > > On Thu, 6 Nov 2014, manish jaggi wrote:
> > > > On 20 October 2014 20:24, Stefano Stabellini
> > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > > On Mon, 20 Oct 2014, manish jaggi wrote:
> > > > > > On 8 October 2014 20:21, Konrad Rzeszutek Wilk
> > > > > > <konrad.wilk@oracle.com> wrote:
> > > > > > > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
> > > > > > > > On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com>
> > > > > > > > wrote:
> > > > > > > > > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
> > > > > > > > > > Thanks for replying. As detailed in this thread, I need to
> > > > > > > > > > create a
> > > > > > > > > > hypercall that would send the following information to Xen
> > > > > > > > > > at the time
> > > > > > > > > > of PCI attach
> > > > > > > > > > { sbdf , domU sbdf, domainId }.
> > > > > > > > > > I am not able to find a way to get the domU sbdf from dom0
> > > > > > > > > > at the time
> > > > > > > > > > of pci-attach.
> > > > > > > > > 
> > > > > > > > > I think it would need to be done by the pciback driver in the
> > > > > > > > > dom0
> > > > > > > > > kernel, which AFAIK is the thing which consistently knows both
> > > > > > > > > physical
> > > > > > > > > and virtual sbdf for a given assigned device.
> > > > > > > > > 
> > > > > > > > > Ian.
> > > > > > > > > 
> > > > > > > > Correct, can you point out which data structure holds the domU
> > > > > > > > sbdf
> > > > > > > > corresponding to the actual sbdf in pciback.
> > > > > > > 
> > > > > > > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
> > > > > > > is that what you are referring to?
> > > > > > 
> > > > > > Xen docs also mention about xen-pciback.passthrough=1. If I set this
> > > > > > in dom0 i see that the device is enumerated as the same sbdf in
> > > > > > domU,
> > > > > > but
> > > > > > a) it is not shown in lspci
> > > > > > b) no front-back communication is done for reading devices
> > > > > > configuration space
> > > > > > .
> > > > > > Is option useful / fully implemented for ARM ?
> > > > > 
> > > > > I don't think this option is very useful. I wouldn't worry about it
> > > > > for
> > > > > now.
> > > > 
> > > > Stefano / Ian / Konard / Julien,
> > > > 
> > > > Attached is a first raw code FYI RFC Patches of PCI passthrough support
> > > > on ARM.
> > > > - Linux Patch (3.18)
> > > > - Xen Patch  (4.5 staging)
> > > > ---(Smmu changes not included, thats a separate patch altogether)
> > > > This patches show the logic, at places need of improvements in code
> > > > organization/quality. I wanted to share to get initial comments.
> > > > This is working with SRIOV as well.
> > > > 
> > > > Please have a look and let me know your positive comments
> > > 
> > > Please send as individual inline patches. not attachments.
> > > Please also add a proper description to each patch and an entry 0/N email
> > > with the high level explanation of your work.
> > > 
> > > See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
> > Stefano I just wanted to share the patches as reference to our
> > discussion on the approach. Please recall I had shared in this mail a
> > design flow. These are just an extension to it. I wanted to move this
> > discussion to a conclusion
> > There are not patches which I am submitting to xen git.
> > If you are ok with the approach I will formally send the patches post
> > 4.5 release.
> 
> In this case you can send the patch series tagged "[RFC]" in the subject.

That's right. It is difficult to give even just an early feedback
without the patch descriptions.


> It
> would better to start sending your patch series now, rather than post 4.5
> release. So we can start to review it and maybe merge it as soon as 4.6
> windows is opened.
> 
> I gave a quick look to the patch you provided. It looks like it depends on
> GICv3 ITS and maybe some SMMU patches? (I doubt the current driver is working
> out-of-box).
> 
> Please provide everything so we can try the patch series and have a better
> overview of the changes.
> 
> Regards,
> 
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:15:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:15:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPip-0001KB-FQ; Thu, 06 Nov 2014 16:15:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmPin-0001K5-F5
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:15:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	40/74-09842-CAE9B545; Thu, 06 Nov 2014 16:15:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415290536!12026425!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9658 invoked from network); 6 Nov 2014 16:15:40 -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;
	6 Nov 2014 16:15:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190238963"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 11:15:34 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmPia-0001bY-V3;
	Thu, 06 Nov 2014 16:15:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmPia-0002IY-LK;
	Thu, 06 Nov 2014 16:15:28 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 6 Nov 2014 16:15:25 +0000
Message-ID: <1415290525-8802-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.campbell@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH] ts-host-install: Honour
	linux-boot-append <suite> (host prop)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 have `install-append <suite>' but that goes before d-i's -- so only
applies during installation.  Provide an option that applies
post-installation too.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-host-install |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/ts-host-install b/ts-host-install
index 95ce845..c65a66a 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -207,6 +207,9 @@ END
 
     push @installcmdline, qw(--);
 
+    push @installcmdline,
+        get_host_property($ho, "linux-boot-append $ho->{Suite}", '');
+
     my $console = get_host_property($ho, "LinuxSerialConsole", "ttyS0");
     push @installcmdline, "console=$console,$c{Baud}n8"
         unless $console eq "NONE";
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:15:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:15:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmPip-0001KB-FQ; Thu, 06 Nov 2014 16:15:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmPin-0001K5-F5
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:15:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	40/74-09842-CAE9B545; Thu, 06 Nov 2014 16:15:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415290536!12026425!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9658 invoked from network); 6 Nov 2014 16:15:40 -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;
	6 Nov 2014 16:15:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190238963"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 11:15:34 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmPia-0001bY-V3;
	Thu, 06 Nov 2014 16:15:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmPia-0002IY-LK;
	Thu, 06 Nov 2014 16:15:28 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 6 Nov 2014 16:15:25 +0000
Message-ID: <1415290525-8802-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.campbell@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH] ts-host-install: Honour
	linux-boot-append <suite> (host prop)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 have `install-append <suite>' but that goes before d-i's -- so only
applies during installation.  Provide an option that applies
post-installation too.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-host-install |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/ts-host-install b/ts-host-install
index 95ce845..c65a66a 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -207,6 +207,9 @@ END
 
     push @installcmdline, qw(--);
 
+    push @installcmdline,
+        get_host_property($ho, "linux-boot-append $ho->{Suite}", '');
+
     my $console = get_host_property($ho, "LinuxSerialConsole", "ttyS0");
     push @installcmdline, "console=$console,$c{Baud}n8"
         unless $console eq "NONE";
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:20:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16: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.xen.org>)
	id 1XmPnE-0001TE-8n; Thu, 06 Nov 2014 16:20:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XmPnD-0001T9-Gp
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:20:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B4/BE-09842-EBF9B545; Thu, 06 Nov 2014 16:20:14 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415290813!3968828!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2186 invoked from network); 6 Nov 2014 16:20:14 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 16:20:14 -0000
Received: by mail-vc0-f173.google.com with SMTP id le20so721406vcb.18
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 08:20:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=106I3xp0QOBcFzyudSEK6pHHrWPmLIoASzx3qltXy0k=;
	b=dyOltLFh7e3+4dxeL41NWYtx+aJ9cxA6vkzLAdeaZ2JXqhq/Pzg/8wzoFA36DViSrJ
	q1CWoP7HopIhusnGl8I5ACeIxqzBVRlf/o3C/i0iPQiDi+QWhVA29k4a+mRTg0j8L26k
	pp/70/deoRqEFc4uOowimj5BMDVT8kXXr2/e31Ragg5fW9ZGuJr17UIOi7RJaySIKjJl
	IQVFw6Rz46DMMWloVRmxKBjzcT5+n9pVIFuE10HJE+DUSsesPNRFEsiORsaAWMvVVlnL
	UlGWkmGIdCT5JlOFQSUb7pHNHhHwH5HZ34707+RaG3N5PRXYRMlUHmcZN+GxHt1c4vrR
	OCYw==
MIME-Version: 1.0
X-Received: by 10.220.238.3 with SMTP id kq3mr3563837vcb.8.1415290813316; Thu,
	06 Nov 2014 08:20:13 -0800 (PST)
Received: by 10.221.57.8 with HTTP; Thu, 6 Nov 2014 08:20:13 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061607150.22875@kaball.uk.xensource.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>
	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>
	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>
	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
	<alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
	<CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>
	<545B9B96.6080102@linaro.org>
	<alpine.DEB.2.02.1411061607150.22875@kaball.uk.xensource.com>
Date: Thu, 6 Nov 2014 21:50:13 +0530
Message-ID: <CAAiw7JmvYpzYsQzg40+bmLWu+6SPJk4J09fuiYStR3LF62bLZQ@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ryan Wilson <hap9@epoch.ncsc.mil>, Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in 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 6 November 2014 21:37, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Julien Grall wrote:
>> Hi Manish,
>>
>> On 06/11/2014 15:55, manish jaggi wrote:
>> > On 6 November 2014 21:18, Stefano Stabellini
>> > <stefano.stabellini@eu.citrix.com> wrote:
>> > > On Thu, 6 Nov 2014, manish jaggi wrote:
>> > > > On 20 October 2014 20:24, Stefano Stabellini
>> > > > <stefano.stabellini@eu.citrix.com> wrote:
>> > > > > On Mon, 20 Oct 2014, manish jaggi wrote:
>> > > > > > On 8 October 2014 20:21, Konrad Rzeszutek Wilk
>> > > > > > <konrad.wilk@oracle.com> wrote:
>> > > > > > > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
>> > > > > > > > On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com>
>> > > > > > > > wrote:
>> > > > > > > > > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
>> > > > > > > > > > Thanks for replying. As detailed in this thread, I need to
>> > > > > > > > > > create a
>> > > > > > > > > > hypercall that would send the following information to Xen
>> > > > > > > > > > at the time
>> > > > > > > > > > of PCI attach
>> > > > > > > > > > { sbdf , domU sbdf, domainId }.
>> > > > > > > > > > I am not able to find a way to get the domU sbdf from dom0
>> > > > > > > > > > at the time
>> > > > > > > > > > of pci-attach.
>> > > > > > > > >
>> > > > > > > > > I think it would need to be done by the pciback driver in the
>> > > > > > > > > dom0
>> > > > > > > > > kernel, which AFAIK is the thing which consistently knows both
>> > > > > > > > > physical
>> > > > > > > > > and virtual sbdf for a given assigned device.
>> > > > > > > > >
>> > > > > > > > > Ian.
>> > > > > > > > >
>> > > > > > > > Correct, can you point out which data structure holds the domU
>> > > > > > > > sbdf
>> > > > > > > > corresponding to the actual sbdf in pciback.
>> > > > > > >
>> > > > > > > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
>> > > > > > > is that what you are referring to?
>> > > > > >
>> > > > > > Xen docs also mention about xen-pciback.passthrough=1. If I set this
>> > > > > > in dom0 i see that the device is enumerated as the same sbdf in
>> > > > > > domU,
>> > > > > > but
>> > > > > > a) it is not shown in lspci
>> > > > > > b) no front-back communication is done for reading devices
>> > > > > > configuration space
>> > > > > > .
>> > > > > > Is option useful / fully implemented for ARM ?
>> > > > >
>> > > > > I don't think this option is very useful. I wouldn't worry about it
>> > > > > for
>> > > > > now.
>> > > >
>> > > > Stefano / Ian / Konard / Julien,
>> > > >
>> > > > Attached is a first raw code FYI RFC Patches of PCI passthrough support
>> > > > on ARM.
>> > > > - Linux Patch (3.18)
>> > > > - Xen Patch  (4.5 staging)
>> > > > ---(Smmu changes not included, thats a separate patch altogether)
>> > > > This patches show the logic, at places need of improvements in code
>> > > > organization/quality. I wanted to share to get initial comments.
>> > > > This is working with SRIOV as well.
>> > > >
>> > > > Please have a look and let me know your positive comments
>> > >
>> > > Please send as individual inline patches. not attachments.
>> > > Please also add a proper description to each patch and an entry 0/N email
>> > > with the high level explanation of your work.
>> > >
>> > > See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
>> > Stefano I just wanted to share the patches as reference to our
>> > discussion on the approach. Please recall I had shared in this mail a
>> > design flow. These are just an extension to it. I wanted to move this
>> > discussion to a conclusion
>> > There are not patches which I am submitting to xen git.
>> > If you are ok with the approach I will formally send the patches post
>> > 4.5 release.
>>
>> In this case you can send the patch series tagged "[RFC]" in the subject.
>
> That's right. It is difficult to give even just an early feedback
> without the patch descriptions.
>
I assumed that the context is preserved in this mail thread. I shared
the flow in the first few mails and am sharing the code after a lot of
discussion in this thread.

Anyhow I will share the code as RFC in some time.
Thanks for the comments.

>
>> It
>> would better to start sending your patch series now, rather than post 4.5
>> release. So we can start to review it and maybe merge it as soon as 4.6
>> windows is opened.
>>
>> I gave a quick look to the patch you provided. It looks like it depends on
>> GICv3 ITS and maybe some SMMU patches? (I doubt the current driver is working
>> out-of-box).
>>
>> Please provide everything so we can try the patch series and have a better
>> overview of the changes.
>>
>> Regards,
>>
>>
>> --
>> Julien Grall
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:20:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16: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.xen.org>)
	id 1XmPnE-0001TE-8n; Thu, 06 Nov 2014 16:20:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XmPnD-0001T9-Gp
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:20:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B4/BE-09842-EBF9B545; Thu, 06 Nov 2014 16:20:14 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415290813!3968828!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2186 invoked from network); 6 Nov 2014 16:20:14 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 16:20:14 -0000
Received: by mail-vc0-f173.google.com with SMTP id le20so721406vcb.18
	for <xen-devel@lists.xen.org>; Thu, 06 Nov 2014 08:20:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=106I3xp0QOBcFzyudSEK6pHHrWPmLIoASzx3qltXy0k=;
	b=dyOltLFh7e3+4dxeL41NWYtx+aJ9cxA6vkzLAdeaZ2JXqhq/Pzg/8wzoFA36DViSrJ
	q1CWoP7HopIhusnGl8I5ACeIxqzBVRlf/o3C/i0iPQiDi+QWhVA29k4a+mRTg0j8L26k
	pp/70/deoRqEFc4uOowimj5BMDVT8kXXr2/e31Ragg5fW9ZGuJr17UIOi7RJaySIKjJl
	IQVFw6Rz46DMMWloVRmxKBjzcT5+n9pVIFuE10HJE+DUSsesPNRFEsiORsaAWMvVVlnL
	UlGWkmGIdCT5JlOFQSUb7pHNHhHwH5HZ34707+RaG3N5PRXYRMlUHmcZN+GxHt1c4vrR
	OCYw==
MIME-Version: 1.0
X-Received: by 10.220.238.3 with SMTP id kq3mr3563837vcb.8.1415290813316; Thu,
	06 Nov 2014 08:20:13 -0800 (PST)
Received: by 10.221.57.8 with HTTP; Thu, 6 Nov 2014 08:20:13 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061607150.22875@kaball.uk.xensource.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>
	<alpine.DEB.2.02.1410061452000.17038@kaball.uk.xensource.com>
	<CAAiw7JkOw=OQ5oBSO5jzcJt6eKhVTahzNkqeQ7p=qH_z-YCekg@mail.gmail.com>
	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
	<alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>
	<CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>
	<545B9B96.6080102@linaro.org>
	<alpine.DEB.2.02.1411061607150.22875@kaball.uk.xensource.com>
Date: Thu, 6 Nov 2014 21:50:13 +0530
Message-ID: <CAAiw7JmvYpzYsQzg40+bmLWu+6SPJk4J09fuiYStR3LF62bLZQ@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ryan Wilson <hap9@epoch.ncsc.mil>, Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in 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 6 November 2014 21:37, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 6 Nov 2014, Julien Grall wrote:
>> Hi Manish,
>>
>> On 06/11/2014 15:55, manish jaggi wrote:
>> > On 6 November 2014 21:18, Stefano Stabellini
>> > <stefano.stabellini@eu.citrix.com> wrote:
>> > > On Thu, 6 Nov 2014, manish jaggi wrote:
>> > > > On 20 October 2014 20:24, Stefano Stabellini
>> > > > <stefano.stabellini@eu.citrix.com> wrote:
>> > > > > On Mon, 20 Oct 2014, manish jaggi wrote:
>> > > > > > On 8 October 2014 20:21, Konrad Rzeszutek Wilk
>> > > > > > <konrad.wilk@oracle.com> wrote:
>> > > > > > > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
>> > > > > > > > On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com>
>> > > > > > > > wrote:
>> > > > > > > > > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
>> > > > > > > > > > Thanks for replying. As detailed in this thread, I need to
>> > > > > > > > > > create a
>> > > > > > > > > > hypercall that would send the following information to Xen
>> > > > > > > > > > at the time
>> > > > > > > > > > of PCI attach
>> > > > > > > > > > { sbdf , domU sbdf, domainId }.
>> > > > > > > > > > I am not able to find a way to get the domU sbdf from dom0
>> > > > > > > > > > at the time
>> > > > > > > > > > of pci-attach.
>> > > > > > > > >
>> > > > > > > > > I think it would need to be done by the pciback driver in the
>> > > > > > > > > dom0
>> > > > > > > > > kernel, which AFAIK is the thing which consistently knows both
>> > > > > > > > > physical
>> > > > > > > > > and virtual sbdf for a given assigned device.
>> > > > > > > > >
>> > > > > > > > > Ian.
>> > > > > > > > >
>> > > > > > > > Correct, can you point out which data structure holds the domU
>> > > > > > > > sbdf
>> > > > > > > > corresponding to the actual sbdf in pciback.
>> > > > > > >
>> > > > > > > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
>> > > > > > > is that what you are referring to?
>> > > > > >
>> > > > > > Xen docs also mention about xen-pciback.passthrough=1. If I set this
>> > > > > > in dom0 i see that the device is enumerated as the same sbdf in
>> > > > > > domU,
>> > > > > > but
>> > > > > > a) it is not shown in lspci
>> > > > > > b) no front-back communication is done for reading devices
>> > > > > > configuration space
>> > > > > > .
>> > > > > > Is option useful / fully implemented for ARM ?
>> > > > >
>> > > > > I don't think this option is very useful. I wouldn't worry about it
>> > > > > for
>> > > > > now.
>> > > >
>> > > > Stefano / Ian / Konard / Julien,
>> > > >
>> > > > Attached is a first raw code FYI RFC Patches of PCI passthrough support
>> > > > on ARM.
>> > > > - Linux Patch (3.18)
>> > > > - Xen Patch  (4.5 staging)
>> > > > ---(Smmu changes not included, thats a separate patch altogether)
>> > > > This patches show the logic, at places need of improvements in code
>> > > > organization/quality. I wanted to share to get initial comments.
>> > > > This is working with SRIOV as well.
>> > > >
>> > > > Please have a look and let me know your positive comments
>> > >
>> > > Please send as individual inline patches. not attachments.
>> > > Please also add a proper description to each patch and an entry 0/N email
>> > > with the high level explanation of your work.
>> > >
>> > > See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
>> > Stefano I just wanted to share the patches as reference to our
>> > discussion on the approach. Please recall I had shared in this mail a
>> > design flow. These are just an extension to it. I wanted to move this
>> > discussion to a conclusion
>> > There are not patches which I am submitting to xen git.
>> > If you are ok with the approach I will formally send the patches post
>> > 4.5 release.
>>
>> In this case you can send the patch series tagged "[RFC]" in the subject.
>
> That's right. It is difficult to give even just an early feedback
> without the patch descriptions.
>
I assumed that the context is preserved in this mail thread. I shared
the flow in the first few mails and am sharing the code after a lot of
discussion in this thread.

Anyhow I will share the code as RFC in some time.
Thanks for the comments.

>
>> It
>> would better to start sending your patch series now, rather than post 4.5
>> release. So we can start to review it and maybe merge it as soon as 4.6
>> windows is opened.
>>
>> I gave a quick look to the patch you provided. It looks like it depends on
>> GICv3 ITS and maybe some SMMU patches? (I doubt the current driver is working
>> out-of-box).
>>
>> Please provide everything so we can try the patch series and have a better
>> overview of the changes.
>>
>> Regards,
>>
>>
>> --
>> Julien Grall
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:28:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16: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 1XmPvJ-0001nn-F5; Thu, 06 Nov 2014 16:28:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmPvH-0001ni-Sf
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:28:35 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	B1/D9-02699-3B1AB545; Thu, 06 Nov 2014 16:28:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415291312!11875171!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28121 invoked from network); 6 Nov 2014 16:28:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 16:28:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190244121"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 11:28:29 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmPvB-0001pb-Ck;
	Thu, 06 Nov 2014 16:28:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmPvB-0002RF-47;
	Thu, 06 Nov 2014 16:28:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21595.41388.814871.925485@mariner.uk.xensource.com>
Date: Thu, 6 Nov 2014 16:28:28 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
References: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not leak diskpath during
	local disk attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] tools: libxl: do not leak diskpath during local disk attach"):
> libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a
> strdup of the device path. This is then passed to the callback, e.g.
> parse_bootloader_result but bootloader_cleanup will not free it.
> 
> Since the callback is within the scope of the (e)gc and therefore doesn't need
> to be malloc'd, a gc'd alloc will do. All other assignments to this field use
> the gc.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295
> 
> Reported-by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

This patch is correct.  Apropos of your question on IRC, it is correct
to use `gc', which is the gc from the ao.  Its lifetime is the whole
device creation operation, which is fine.

You sometimes (including here) don't want to use the egc's gc in an ao
operation, because its lifetime is just the current event callback.
This is why we have STATE_AO_GC at the top of these functions, to make
sure `gc' is simply the right gc.

I will apply this patch to staging and queue it for backport.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:28:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16: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 1XmPvJ-0001nn-F5; Thu, 06 Nov 2014 16:28:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmPvH-0001ni-Sf
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:28:35 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	B1/D9-02699-3B1AB545; Thu, 06 Nov 2014 16:28:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415291312!11875171!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28121 invoked from network); 6 Nov 2014 16:28:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 16:28:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,326,1413244800"; d="scan'208";a="190244121"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 11:28:29 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmPvB-0001pb-Ck;
	Thu, 06 Nov 2014 16:28:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmPvB-0002RF-47;
	Thu, 06 Nov 2014 16:28:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21595.41388.814871.925485@mariner.uk.xensource.com>
Date: Thu, 6 Nov 2014 16:28:28 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
References: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not leak diskpath during
	local disk attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] tools: libxl: do not leak diskpath during local disk attach"):
> libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a
> strdup of the device path. This is then passed to the callback, e.g.
> parse_bootloader_result but bootloader_cleanup will not free it.
> 
> Since the callback is within the scope of the (e)gc and therefore doesn't need
> to be malloc'd, a gc'd alloc will do. All other assignments to this field use
> the gc.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295
> 
> Reported-by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

This patch is correct.  Apropos of your question on IRC, it is correct
to use `gc', which is the gc from the ao.  Its lifetime is the whole
device creation operation, which is fine.

You sometimes (including here) don't want to use the egc's gc in an ao
operation, because its lifetime is just the current event callback.
This is why we have STATE_AO_GC at the top of these functions, to make
sure `gc' is simply the right gc.

I will apply this patch to staging and queue it for backport.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:38:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:38:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmQ56-0002AN-PP; Thu, 06 Nov 2014 16:38:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmQ55-0002AG-AN
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:38:43 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	C6/E8-02698-214AB545; Thu, 06 Nov 2014 16:38:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415291920!11880012!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25134 invoked from network); 6 Nov 2014 16:38:42 -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;
	6 Nov 2014 16:38:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="scan'208";a="188830095"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 11:35:44 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmQ2B-0001wP-LB;
	Thu, 06 Nov 2014 16:35:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmQ2B-0002Zw-BK;
	Thu, 06 Nov 2014 16:35:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21595.41822.840885.58412@mariner.uk.xensource.com>
Date: Thu, 6 Nov 2014 16:35:42 +0000
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141106145539.GB2580@zion.uk.xensource.com>
References: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
	<20141106145539.GB2580@zion.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not overrun input buffer
 in libxl__parse_mac
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wei Liu writes ("Re: [PATCH] tools: libxl: do not overrun input buffer in libx\
l__parse_mac"):
> > This is because on the final iteration the tok += 3 skips over the termina\
ting
> > NUL to the next byte, and then *tok reads it. Fix this by using endptr as \
the
> > iterator.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Wei Liu <wei.liu2@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

> This is a candidate for backporting.

Queued.

Ian, I don't suppose you could persuade your text editor to wrap your
commit messages a bit narrower ?  By the time they've been quoted a
couple of times they look to me like what you see above.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:38:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:38:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmQ56-0002AN-PP; Thu, 06 Nov 2014 16:38:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmQ55-0002AG-AN
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:38:43 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	C6/E8-02698-214AB545; Thu, 06 Nov 2014 16:38:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415291920!11880012!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25134 invoked from network); 6 Nov 2014 16:38:42 -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;
	6 Nov 2014 16:38:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="scan'208";a="188830095"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 11:35:44 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmQ2B-0001wP-LB;
	Thu, 06 Nov 2014 16:35:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmQ2B-0002Zw-BK;
	Thu, 06 Nov 2014 16:35:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21595.41822.840885.58412@mariner.uk.xensource.com>
Date: Thu, 6 Nov 2014 16:35:42 +0000
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141106145539.GB2580@zion.uk.xensource.com>
References: <1415282383-26594-1-git-send-email-ian.campbell@citrix.com>
	<20141106145539.GB2580@zion.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: do not overrun input buffer
 in libxl__parse_mac
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wei Liu writes ("Re: [PATCH] tools: libxl: do not overrun input buffer in libx\
l__parse_mac"):
> > This is because on the final iteration the tok += 3 skips over the termina\
ting
> > NUL to the next byte, and then *tok reads it. Fix this by using endptr as \
the
> > iterator.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Wei Liu <wei.liu2@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

> This is a candidate for backporting.

Queued.

Ian, I don't suppose you could persuade your text editor to wrap your
commit messages a bit narrower ?  By the time they've been quoted a
couple of times they look to me like what you see above.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:46:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:46:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmQC9-0002Ua-Nk; Thu, 06 Nov 2014 16:46:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@roeck-us.net>) id 1XmQC8-0002UV-J6
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:46:00 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	39/84-29352-7C5AB545; Thu, 06 Nov 2014 16:45:59 +0000
X-Env-Sender: linux@roeck-us.net
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415292356!10915583!1
X-Originating-IP: [208.91.199.152]
X-SpamReason: No, hits=2.7 required=7.0 tests=BODY_RANDOM_LONG,
	SUSPICIOUS_RECIPS,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16897 invoked from network); 6 Nov 2014 16:45:58 -0000
Received: from bh-25.webhostbox.net (HELO bh-25.webhostbox.net)
	(208.91.199.152)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 16:45:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roeck-us.net;
	s=default; 
	h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=1Go5vcjEmM3rzRrnnyPNMi30qCyKVF5mQcViOm/0gAY=; 
	b=m0IhrRUCnZkzb0L8Pez5tFfZL0VPPcJcsaC3i5pOfqftTRMW4o5arVQnFd15YNB4+1zbzRMJHfojOVsO8vUbPfyiadkqT3MtXN9NCTPpwIjRQWOymhEkpdFD2LzEwcLRKKH3VXsrJY0rKqKfHCOOKs3q3zCEBR30A6XIUKMpVr8=;
Received: from mailnull by bh-25.webhostbox.net with sa-checked (Exim 4.82)
	(envelope-from <linux@roeck-us.net>) id 1XmQC4-000X6V-Cl
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:45:56 +0000
Received: from 108-223-40-66.lightspeed.sntcca.sbcglobal.net
	([108.223.40.66]:35302 helo=localhost)
	by bh-25.webhostbox.net with esmtpa (Exim 4.82)
	(envelope-from <linux@roeck-us.net>)
	id 1XmQAA-000Srg-5y; Thu, 06 Nov 2014 16:44:00 +0000
From: Guenter Roeck <linux@roeck-us.net>
To: linux-kernel@vger.kernel.org
Date: Thu,  6 Nov 2014 08:42:52 -0800
Message-Id: <1415292213-28652-9-git-send-email-linux@roeck-us.net>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415292213-28652-1-git-send-email-linux@roeck-us.net>
References: <1415292213-28652-1-git-send-email-linux@roeck-us.net>
X-Authenticated_sender: guenter@roeck-us.net
X-OutGoing-Spam-Status: No, score=2.5
X-Spam-Checker-Version: spamc_ctasd client on
	localost
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=50.0 tests=SpamClass_Unknown,
	VirusClass_Unknown autolearn=disabled version=1.0.0
X-CTCH-PVer: 0000001
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-Flags: 0
X-CTCH-RefID: str=0001.0A020206.545BA5C4.0184, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-Score: 0.000
X-CTCH-ScoreCust: 0.000
X-CTCH-Rules: 
X-CTCH-SenderID: linux@roeck-us.net
X-CTCH-SenderID-Flags: 0
X-CTCH-SenderID-TotalMessages: 292
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-TotalRecipients: 0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - lists.xenproject.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from
	get_relayhosts_entry
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
	linux-sh@vger.kernel.org, linux@lists.openrisc.net,
	sparclinux@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-am33-list@redhat.com, linux-c6x-dev@linux-c6x.org,
	linux-hexagon@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xenproject.org, Guenter Roeck <linux@roeck-us.net>,
	linux-xtensa@linux-xtensa.org, user-mode-linux-devel@lists.sourceforge.net,
	linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net,
	linux-m68k@lists.linux-m68k.org,
	user-mode-linux-user@lists.sourceforge.net, linux-metag@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
	linux-alpha@vger.kernel.org, linux390@de.ibm.com,
	linuxppc-dev@lists.ozlabs.org
Subject: [Xen-devel] [PATCH v5 08/48] kernel: Move pm_power_off to common
	code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pm_power_off is defined for all architectures. Move it to common code.

Have all architectures call do_kernel_power_off instead of pm_power_off.
Some architectures point pm_power_off to machine_power_off. For those,
call do_kernel_power_off from machine_power_off instead.

Acked-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Hirokazu Takata <takata@linux-m32r.org>
Acked-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
Acked-by: Richard Weinberger <richard@nod.at>
Acked-by: Xuetao Guan <gxt@mprc.pku.edu.cn>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v5:
- Rebase to v3.18-rc3
- Update powerpc code to reflect merged power-off handler changes
v4:
- No change
v3:
- Replace poweroff in all newly introduced variables and in text
  with power_off or power-off as appropriate
v2:
- do_kernel_poweroff -> do_kernel_power_off
- have_kernel_poweroff -> have_kernel_power_off

 arch/alpha/kernel/process.c        |  9 +++------
 arch/arc/kernel/reset.c            |  5 +----
 arch/arm/kernel/process.c          |  5 +----
 arch/arm64/kernel/process.c        |  5 +----
 arch/avr32/kernel/process.c        |  6 +-----
 arch/blackfin/kernel/process.c     |  3 ---
 arch/blackfin/kernel/reboot.c      |  2 ++
 arch/c6x/kernel/process.c          |  9 +--------
 arch/cris/kernel/process.c         |  4 +---
 arch/frv/kernel/process.c          |  5 ++---
 arch/hexagon/kernel/reset.c        |  5 ++---
 arch/ia64/kernel/process.c         |  5 +----
 arch/m32r/kernel/process.c         |  8 ++++----
 arch/m68k/kernel/process.c         |  6 +-----
 arch/metag/kernel/process.c        |  6 +-----
 arch/microblaze/kernel/process.c   |  3 ---
 arch/microblaze/kernel/reset.c     |  1 +
 arch/mips/kernel/reset.c           |  6 +-----
 arch/mn10300/kernel/process.c      |  8 ++------
 arch/openrisc/kernel/process.c     |  8 +++++---
 arch/parisc/kernel/process.c       |  8 ++++----
 arch/powerpc/kernel/setup-common.c |  6 +-----
 arch/powerpc/xmon/xmon.c           |  3 +--
 arch/s390/kernel/setup.c           |  8 ++------
 arch/score/kernel/process.c        |  8 ++++----
 arch/sh/kernel/reboot.c            |  6 +-----
 arch/sparc/kernel/process_32.c     | 10 ++--------
 arch/sparc/kernel/reboot.c         |  8 ++------
 arch/tile/kernel/reboot.c          |  7 +++----
 arch/um/kernel/reboot.c            |  2 --
 arch/unicore32/kernel/process.c    |  9 +--------
 arch/x86/kernel/reboot.c           | 11 +++--------
 arch/x86/xen/enlighten.c           |  3 +--
 arch/xtensa/kernel/process.c       |  4 ----
 drivers/parisc/power.c             |  3 +--
 kernel/power/power_off_handler.c   |  9 +++++++++
 kernel/reboot.c                    |  4 ++--
 37 files changed, 68 insertions(+), 150 deletions(-)

diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 1941a07..81c43f8 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -24,6 +24,7 @@
 #include <linux/vt.h>
 #include <linux/mman.h>
 #include <linux/elfcore.h>
+#include <linux/pm.h>
 #include <linux/reboot.h>
 #include <linux/tty.h>
 #include <linux/console.h>
@@ -40,12 +41,6 @@
 #include "proto.h"
 #include "pci_impl.h"
 
-/*
- * Power off function, if any
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 #ifdef CONFIG_ALPHA_WTINT
 /*
  * Sleep the CPU.
@@ -184,6 +179,8 @@ machine_halt(void)
 void
 machine_power_off(void)
 {
+	do_kernel_power_off();
+
 	common_shutdown(LINUX_REBOOT_CMD_POWER_OFF, NULL);
 }
 
diff --git a/arch/arc/kernel/reset.c b/arch/arc/kernel/reset.c
index 2768fa1..0758d9d 100644
--- a/arch/arc/kernel/reset.c
+++ b/arch/arc/kernel/reset.c
@@ -26,9 +26,6 @@ void machine_restart(char *__unused)
 
 void machine_power_off(void)
 {
-	/* FIXME ::  power off ??? */
+	do_kernel_power_off();
 	machine_halt();
 }
-
-void (*pm_power_off) (void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index fe972a2..aa3f656 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -117,8 +117,6 @@ void soft_restart(unsigned long addr)
 /*
  * Function pointers to optional machine specific functions
  */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 
@@ -205,8 +203,7 @@ void machine_power_off(void)
 	local_irq_disable();
 	smp_send_stop();
 
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index fde9923..6f623a0 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -68,8 +68,6 @@ void soft_restart(unsigned long addr)
 /*
  * Function pointers to optional machine specific functions
  */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL_GPL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 
@@ -129,8 +127,7 @@ void machine_power_off(void)
 {
 	local_irq_disable();
 	smp_send_stop();
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/avr32/kernel/process.c b/arch/avr32/kernel/process.c
index 42a53e74..529c1f6 100644
--- a/arch/avr32/kernel/process.c
+++ b/arch/avr32/kernel/process.c
@@ -23,9 +23,6 @@
 
 #include <mach/pm.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * This file handles the architecture-dependent parts of process handling..
  */
@@ -48,8 +45,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 void machine_restart(char *cmd)
diff --git a/arch/blackfin/kernel/process.c b/arch/blackfin/kernel/process.c
index 4aa5545..812dd83 100644
--- a/arch/blackfin/kernel/process.c
+++ b/arch/blackfin/kernel/process.c
@@ -39,9 +39,6 @@ int nr_l1stack_tasks;
 void *l1_stack_base;
 unsigned long l1_stack_len;
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * The idle loop on BFIN
  */
diff --git a/arch/blackfin/kernel/reboot.c b/arch/blackfin/kernel/reboot.c
index c4f50a3..387d610 100644
--- a/arch/blackfin/kernel/reboot.c
+++ b/arch/blackfin/kernel/reboot.c
@@ -7,6 +7,7 @@
  */
 
 #include <linux/interrupt.h>
+#include <linux/pm.h>
 #include <asm/bfin-global.h>
 #include <asm/reboot.h>
 #include <asm/bfrom.h>
@@ -106,6 +107,7 @@ void machine_halt(void)
 __attribute__((weak))
 void native_machine_power_off(void)
 {
+	do_kernel_power_off();
 	idle_with_irq_disabled();
 }
 
diff --git a/arch/c6x/kernel/process.c b/arch/c6x/kernel/process.c
index 57d2ea8..edf7e5a 100644
--- a/arch/c6x/kernel/process.c
+++ b/arch/c6x/kernel/process.c
@@ -27,12 +27,6 @@ void	(*c6x_halt)(void);
 extern asmlinkage void ret_from_fork(void);
 extern asmlinkage void ret_from_kernel_thread(void);
 
-/*
- * power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void arch_cpu_idle(void)
 {
 	unsigned long tmp;
@@ -73,8 +67,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	halt_loop();
 }
 
diff --git a/arch/cris/kernel/process.c b/arch/cris/kernel/process.c
index b78498e..9ebd76b 100644
--- a/arch/cris/kernel/process.c
+++ b/arch/cris/kernel/process.c
@@ -31,9 +31,6 @@
 
 extern void default_idle(void);
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void arch_cpu_idle(void)
 {
 	default_idle();
@@ -60,6 +57,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/frv/kernel/process.c b/arch/frv/kernel/process.c
index 5d40aeb77..502dabb 100644
--- a/arch/frv/kernel/process.c
+++ b/arch/frv/kernel/process.c
@@ -42,9 +42,6 @@ asmlinkage void ret_from_kernel_thread(void);
 
 #include <asm/pgalloc.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 static void core_sleep_idle(void)
 {
 #ifdef LED_DEBUG_SLEEP
@@ -107,6 +104,8 @@ void machine_power_off(void)
 	gdbstub_exit(0);
 #endif
 
+	do_kernel_power_off();
+
 	for (;;);
 }
 
diff --git a/arch/hexagon/kernel/reset.c b/arch/hexagon/kernel/reset.c
index 76483c1..6f607b6 100644
--- a/arch/hexagon/kernel/reset.c
+++ b/arch/hexagon/kernel/reset.c
@@ -16,11 +16,13 @@
  * 02110-1301, USA.
  */
 
+#include <linux/pm.h>
 #include <linux/smp.h>
 #include <asm/hexagon_vm.h>
 
 void machine_power_off(void)
 {
+	do_kernel_power_off();
 	smp_send_stop();
 	__vmstop();
 }
@@ -32,6 +34,3 @@ void machine_halt(void)
 void machine_restart(char *cmd)
 {
 }
-
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index b515149..88121a2 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -57,8 +57,6 @@ void (*ia64_mark_idle)(int);
 
 unsigned long boot_option_idle_override = IDLE_NO_OVERRIDE;
 EXPORT_SYMBOL(boot_option_idle_override);
-void (*pm_power_off) (void);
-EXPORT_SYMBOL(pm_power_off);
 
 void
 ia64_do_show_stack (struct unw_frame_info *info, void *arg)
@@ -675,8 +673,7 @@ machine_halt (void)
 void
 machine_power_off (void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	machine_halt();
 }
 
diff --git a/arch/m32r/kernel/process.c b/arch/m32r/kernel/process.c
index e69221d..65a037e 100644
--- a/arch/m32r/kernel/process.c
+++ b/arch/m32r/kernel/process.c
@@ -23,6 +23,7 @@
 #include <linux/fs.h>
 #include <linux/slab.h>
 #include <linux/module.h>
+#include <linux/pm.h>
 #include <linux/ptrace.h>
 #include <linux/unistd.h>
 #include <linux/hardirq.h>
@@ -44,9 +45,6 @@ unsigned long thread_saved_pc(struct task_struct *tsk)
 	return tsk->thread.lr;
 }
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_restart(char *__unused)
 {
 #if defined(CONFIG_PLAT_MAPPI3)
@@ -67,7 +65,9 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	/* M32R_FIXME */
+	do_kernel_power_off();
+	for (;;)
+		;
 }
 
 void show_regs(struct pt_regs * regs)
diff --git a/arch/m68k/kernel/process.c b/arch/m68k/kernel/process.c
index afe3d6e..bbc0a63 100644
--- a/arch/m68k/kernel/process.c
+++ b/arch/m68k/kernel/process.c
@@ -78,14 +78,10 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	for (;;);
 }
 
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 void show_regs(struct pt_regs * regs)
 {
 	printk("\n");
diff --git a/arch/metag/kernel/process.c b/arch/metag/kernel/process.c
index 483dff9..8d95773 100644
--- a/arch/metag/kernel/process.c
+++ b/arch/metag/kernel/process.c
@@ -67,9 +67,6 @@ void arch_cpu_idle_dead(void)
 }
 #endif
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void (*soc_restart)(char *cmd);
 void (*soc_halt)(void);
 
@@ -90,8 +87,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	smp_send_stop();
 	hard_processor_halt(HALT_OK);
 }
diff --git a/arch/microblaze/kernel/process.c b/arch/microblaze/kernel/process.c
index b2dd371..0ebca36 100644
--- a/arch/microblaze/kernel/process.c
+++ b/arch/microblaze/kernel/process.c
@@ -44,9 +44,6 @@ void show_regs(struct pt_regs *regs)
 				regs->msr, regs->ear, regs->esr, regs->fsr);
 }
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void flush_thread(void)
 {
 }
diff --git a/arch/microblaze/kernel/reset.c b/arch/microblaze/kernel/reset.c
index fbe58c6..2c6b32c 100644
--- a/arch/microblaze/kernel/reset.c
+++ b/arch/microblaze/kernel/reset.c
@@ -103,6 +103,7 @@ void machine_halt(void)
 void machine_power_off(void)
 {
 	pr_notice("Machine power off...\n");
+	do_kernel_power_off();
 	while (1)
 		;
 }
diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 07fc524..09e74d2 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -21,9 +21,6 @@
  */
 void (*_machine_restart)(char *command);
 void (*_machine_halt)(void);
-void (*pm_power_off)(void);
-
-EXPORT_SYMBOL(pm_power_off);
 
 void machine_restart(char *command)
 {
@@ -39,6 +36,5 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
diff --git a/arch/mn10300/kernel/process.c b/arch/mn10300/kernel/process.c
index 3707da5..c78b2eb 100644
--- a/arch/mn10300/kernel/process.c
+++ b/arch/mn10300/kernel/process.c
@@ -20,6 +20,7 @@
 #include <linux/user.h>
 #include <linux/interrupt.h>
 #include <linux/delay.h>
+#include <linux/pm.h>
 #include <linux/reboot.h>
 #include <linux/percpu.h>
 #include <linux/err.h>
@@ -45,12 +46,6 @@ unsigned long thread_saved_pc(struct task_struct *tsk)
 }
 
 /*
- * power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
-/*
  * On SMP it's slightly faster (but much more power-consuming!)
  * to poll the ->work.need_resched flag instead of waiting for the
  * cross-CPU IPI to arrive. Use this option with caution.
@@ -93,6 +88,7 @@ void machine_power_off(void)
 #ifdef CONFIG_KERNEL_DEBUGGER
 	gdbstub_exit(0);
 #endif
+	do_kernel_power_off();
 }
 
 void show_regs(struct pt_regs *regs)
diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
index 386af25..494afd2 100644
--- a/arch/openrisc/kernel/process.c
+++ b/arch/openrisc/kernel/process.c
@@ -25,6 +25,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/mm.h>
+#include <linux/pm.h>
 #include <linux/stddef.h>
 #include <linux/unistd.h>
 #include <linux/ptrace.h>
@@ -51,7 +52,7 @@
  */
 struct thread_info *current_thread_info_set[NR_CPUS] = { &init_thread_info, };
 
-void machine_restart(void)
+void machine_restart(char *cmd)
 {
 	printk(KERN_INFO "*** MACHINE RESTART ***\n");
 	__asm__("l.nop 1");
@@ -72,11 +73,12 @@ void machine_halt(void)
 void machine_power_off(void)
 {
 	printk(KERN_INFO "*** MACHINE POWER OFF ***\n");
+
+	do_kernel_power_off();
+
 	__asm__("l.nop 1");
 }
 
-void (*pm_power_off) (void) = machine_power_off;
-
 /*
  * When a process does an "exec", machine state like FPU and debug
  * registers need to be reset.  This is a hook function for that.
diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
index 0bbbf0d..3f5d14a 100644
--- a/arch/parisc/kernel/process.c
+++ b/arch/parisc/kernel/process.c
@@ -41,6 +41,7 @@
 #include <linux/fs.h>
 #include <linux/module.h>
 #include <linux/personality.h>
+#include <linux/pm.h>
 #include <linux/ptrace.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
@@ -133,7 +134,9 @@ void machine_power_off(void)
 	pdc_soft_power_button(0);
 	
 	pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN);
-		
+
+	do_kernel_power_off();
+
 	/* It seems we have no way to power the system off via
 	 * software. The user has to press the button himself. */
 
@@ -141,9 +144,6 @@ void machine_power_off(void)
 	       "Please power this system off now.");
 }
 
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * Free current thread data structures etc..
  */
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 44c8d03..a2efce7 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -139,8 +139,7 @@ void machine_restart(char *cmd)
 void machine_power_off(void)
 {
 	machine_shutdown();
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 #ifdef CONFIG_SMP
 	smp_send_stop();
 #endif
@@ -151,9 +150,6 @@ void machine_power_off(void)
 /* Used by the G5 thermal driver */
 EXPORT_SYMBOL_GPL(machine_power_off);
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL_GPL(pm_power_off);
-
 void machine_halt(void)
 {
 	machine_shutdown();
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 506d256..8780178 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -981,8 +981,7 @@ static void bootcmds(void)
 	else if (cmd == 'h')
 		ppc_md.halt();
 	else if (cmd == 'p')
-		if (pm_power_off)
-			pm_power_off();
+		do_kernel_power_off();
 }
 
 static int cpu_cmd(void)
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index e80d9ff..267e025 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -263,13 +263,9 @@ void machine_power_off(void)
 		 */
 		console_unblank();
 	_machine_power_off();
-}
 
-/*
- * Dummy power off function.
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL_GPL(pm_power_off);
+	do_kernel_power_off();
+}
 
 static int __init early_parse_mem(char *p)
 {
diff --git a/arch/score/kernel/process.c b/arch/score/kernel/process.c
index a1519ad3..b76ea67 100644
--- a/arch/score/kernel/process.c
+++ b/arch/score/kernel/process.c
@@ -29,9 +29,6 @@
 #include <linux/pm.h>
 #include <linux/rcupdate.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 /* If or when software machine-restart is implemented, add code here. */
 void machine_restart(char *command) {}
 
@@ -39,7 +36,10 @@ void machine_restart(char *command) {}
 void machine_halt(void) {}
 
 /* If or when software machine-power-off is implemented, add code here. */
-void machine_power_off(void) {}
+void machine_power_off(void)
+{
+	do_kernel_power_off();
+}
 
 void ret_from_fork(void);
 void ret_from_kernel_thread(void);
diff --git a/arch/sh/kernel/reboot.c b/arch/sh/kernel/reboot.c
index 04afe5b..065de12 100644
--- a/arch/sh/kernel/reboot.c
+++ b/arch/sh/kernel/reboot.c
@@ -11,9 +11,6 @@
 #include <asm/tlbflush.h>
 #include <asm/traps.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 #ifdef CONFIG_SUPERH32
 static void watchdog_trigger_immediate(void)
 {
@@ -51,8 +48,7 @@ static void native_machine_shutdown(void)
 
 static void native_machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 static void native_machine_halt(void)
diff --git a/arch/sparc/kernel/process_32.c b/arch/sparc/kernel/process_32.c
index 50e7b62..cb8148a 100644
--- a/arch/sparc/kernel/process_32.c
+++ b/arch/sparc/kernel/process_32.c
@@ -48,14 +48,6 @@
  */
 void (*sparc_idle)(void);
 
-/* 
- * Power-off handler instantiation for pm.h compliance
- * This is done via auxio, but could be used as a fallback
- * handler when auxio is not present-- unused for now...
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * sysctl - toggle power-off restriction for serial console 
  * systems in machine_power_off()
@@ -112,6 +104,8 @@ void machine_power_off(void)
 		sbus_writeb(power_register, auxio_power_register);
 	}
 
+	do_kernel_power_off();
+
 	machine_halt();
 }
 
diff --git a/arch/sparc/kernel/reboot.c b/arch/sparc/kernel/reboot.c
index eba7d91..3c0bb03 100644
--- a/arch/sparc/kernel/reboot.c
+++ b/arch/sparc/kernel/reboot.c
@@ -16,17 +16,13 @@
  */
 int scons_pwroff = 1;
 
-/* This isn't actually used, it exists merely to satisfy the
- * reference in kernel/sys.c
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_power_off(void)
 {
 	if (strcmp(of_console_device->type, "serial") || scons_pwroff)
 		prom_halt_power_off();
 
+	do_kernel_power_off();
+
 	prom_halt();
 }
 
diff --git a/arch/tile/kernel/reboot.c b/arch/tile/kernel/reboot.c
index 6c5d2c0..8ff4a7f 100644
--- a/arch/tile/kernel/reboot.c
+++ b/arch/tile/kernel/reboot.c
@@ -36,6 +36,9 @@ void machine_power_off(void)
 {
 	arch_local_irq_disable_all();
 	smp_send_stop();
+
+	do_kernel_power_off();
+
 	hv_power_off();
 }
 
@@ -45,7 +48,3 @@ void machine_restart(char *cmd)
 	smp_send_stop();
 	hv_restart((HV_VirtAddr) "vmlinux", (HV_VirtAddr) cmd);
 }
-
-/* No interesting distinction to be made here. */
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/um/kernel/reboot.c b/arch/um/kernel/reboot.c
index ced8903..a82ef28 100644
--- a/arch/um/kernel/reboot.c
+++ b/arch/um/kernel/reboot.c
@@ -11,8 +11,6 @@
 #include <os.h>
 #include <skas.h>
 
-void (*pm_power_off)(void);
-
 static void kill_off_processes(void)
 {
 	if (proc_mm)
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index b008e99..9490dd5 100644
--- a/arch/unicore32/kernel/process.c
+++ b/arch/unicore32/kernel/process.c
@@ -56,16 +56,9 @@ void machine_halt(void)
 	gpio_set_value(GPO_SOFT_OFF, 0);
 }
 
-/*
- * Function pointers to optional machine specific functions
- */
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	machine_halt();
 }
 
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 17962e6..5c09e28 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -30,12 +30,6 @@
 #include <asm/x86_init.h>
 #include <asm/efi.h>
 
-/*
- * Power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 static const struct desc_ptr no_idt = {};
 
 /*
@@ -647,11 +641,12 @@ static void native_machine_halt(void)
 
 static void native_machine_power_off(void)
 {
-	if (pm_power_off) {
+	if (have_kernel_power_off()) {
 		if (!reboot_force)
 			machine_shutdown();
-		pm_power_off();
+		do_kernel_power_off();
 	}
+
 	/* A fallback in case there is no PM info available */
 	tboot_shutdown(TB_SHUTDOWN_HALT);
 }
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index fac5e4f..bc08998 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1320,8 +1320,7 @@ static void xen_machine_halt(void)
 
 static void xen_machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	xen_reboot(SHUTDOWN_poweroff);
 }
 
diff --git a/arch/xtensa/kernel/process.c b/arch/xtensa/kernel/process.c
index 1c85323..c487296 100644
--- a/arch/xtensa/kernel/process.c
+++ b/arch/xtensa/kernel/process.c
@@ -49,10 +49,6 @@ extern void ret_from_kernel_thread(void);
 
 struct task_struct *current_set[NR_CPUS] = {&init_task, };
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
-
 #if XTENSA_HAVE_COPROCESSORS
 
 void coprocessor_release_all(struct thread_info *ti)
diff --git a/drivers/parisc/power.c b/drivers/parisc/power.c
index ef31b77..f10cf92 100644
--- a/drivers/parisc/power.c
+++ b/drivers/parisc/power.c
@@ -95,8 +95,7 @@ static void process_shutdown(void)
 		/* send kill signal */
 		if (kill_cad_pid(SIGINT, 1)) {
 			/* just in case killing init process failed */
-			if (pm_power_off)
-				pm_power_off();
+			kernel_power_off();
 		}
 	}
 }
diff --git a/kernel/power/power_off_handler.c b/kernel/power/power_off_handler.c
index e576534..e283ea1 100644
--- a/kernel/power/power_off_handler.c
+++ b/kernel/power/power_off_handler.c
@@ -23,6 +23,12 @@
 #include <linux/types.h>
 
 /*
+ * If set, calling this function will power off the system immediately.
+ */
+void (*pm_power_off)(void);
+EXPORT_SYMBOL(pm_power_off);
+
+/*
  * List of handlers for kernel code which wants to be called
  * to power off the system.
  */
@@ -272,6 +278,9 @@ void do_kernel_power_off(void)
 	 * that risk.
 	 */
 
+	if (pm_power_off)
+		pm_power_off();
+
 	p = rcu_dereference_raw(power_off_handler_list);
 	while (p) {
 		next_p = rcu_dereference_raw(p->next);
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 5925f5a..d87d921 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -306,9 +306,9 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
 		return ret;
 
 	/* Instead of trying to make the power_off code look like
-	 * halt when pm_power_off is not set do it the easy way.
+	 * halt when no power-off handler exists do it the easy way.
 	 */
-	if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) && !pm_power_off)
+	if (cmd == LINUX_REBOOT_CMD_POWER_OFF && !have_kernel_power_off())
 		cmd = LINUX_REBOOT_CMD_HALT;
 
 	mutex_lock(&reboot_mutex);
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:46:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:46:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmQC9-0002Ua-Nk; Thu, 06 Nov 2014 16:46:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@roeck-us.net>) id 1XmQC8-0002UV-J6
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:46:00 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	39/84-29352-7C5AB545; Thu, 06 Nov 2014 16:45:59 +0000
X-Env-Sender: linux@roeck-us.net
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415292356!10915583!1
X-Originating-IP: [208.91.199.152]
X-SpamReason: No, hits=2.7 required=7.0 tests=BODY_RANDOM_LONG,
	SUSPICIOUS_RECIPS,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16897 invoked from network); 6 Nov 2014 16:45:58 -0000
Received: from bh-25.webhostbox.net (HELO bh-25.webhostbox.net)
	(208.91.199.152)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 16:45:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roeck-us.net;
	s=default; 
	h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=1Go5vcjEmM3rzRrnnyPNMi30qCyKVF5mQcViOm/0gAY=; 
	b=m0IhrRUCnZkzb0L8Pez5tFfZL0VPPcJcsaC3i5pOfqftTRMW4o5arVQnFd15YNB4+1zbzRMJHfojOVsO8vUbPfyiadkqT3MtXN9NCTPpwIjRQWOymhEkpdFD2LzEwcLRKKH3VXsrJY0rKqKfHCOOKs3q3zCEBR30A6XIUKMpVr8=;
Received: from mailnull by bh-25.webhostbox.net with sa-checked (Exim 4.82)
	(envelope-from <linux@roeck-us.net>) id 1XmQC4-000X6V-Cl
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:45:56 +0000
Received: from 108-223-40-66.lightspeed.sntcca.sbcglobal.net
	([108.223.40.66]:35302 helo=localhost)
	by bh-25.webhostbox.net with esmtpa (Exim 4.82)
	(envelope-from <linux@roeck-us.net>)
	id 1XmQAA-000Srg-5y; Thu, 06 Nov 2014 16:44:00 +0000
From: Guenter Roeck <linux@roeck-us.net>
To: linux-kernel@vger.kernel.org
Date: Thu,  6 Nov 2014 08:42:52 -0800
Message-Id: <1415292213-28652-9-git-send-email-linux@roeck-us.net>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415292213-28652-1-git-send-email-linux@roeck-us.net>
References: <1415292213-28652-1-git-send-email-linux@roeck-us.net>
X-Authenticated_sender: guenter@roeck-us.net
X-OutGoing-Spam-Status: No, score=2.5
X-Spam-Checker-Version: spamc_ctasd client on
	localost
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=50.0 tests=SpamClass_Unknown,
	VirusClass_Unknown autolearn=disabled version=1.0.0
X-CTCH-PVer: 0000001
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-Flags: 0
X-CTCH-RefID: str=0001.0A020206.545BA5C4.0184, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-Score: 0.000
X-CTCH-ScoreCust: 0.000
X-CTCH-Rules: 
X-CTCH-SenderID: linux@roeck-us.net
X-CTCH-SenderID-Flags: 0
X-CTCH-SenderID-TotalMessages: 292
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-TotalRecipients: 0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - lists.xenproject.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from
	get_relayhosts_entry
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
	linux-sh@vger.kernel.org, linux@lists.openrisc.net,
	sparclinux@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-am33-list@redhat.com, linux-c6x-dev@linux-c6x.org,
	linux-hexagon@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xenproject.org, Guenter Roeck <linux@roeck-us.net>,
	linux-xtensa@linux-xtensa.org, user-mode-linux-devel@lists.sourceforge.net,
	linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net,
	linux-m68k@lists.linux-m68k.org,
	user-mode-linux-user@lists.sourceforge.net, linux-metag@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
	linux-alpha@vger.kernel.org, linux390@de.ibm.com,
	linuxppc-dev@lists.ozlabs.org
Subject: [Xen-devel] [PATCH v5 08/48] kernel: Move pm_power_off to common
	code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pm_power_off is defined for all architectures. Move it to common code.

Have all architectures call do_kernel_power_off instead of pm_power_off.
Some architectures point pm_power_off to machine_power_off. For those,
call do_kernel_power_off from machine_power_off instead.

Acked-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Hirokazu Takata <takata@linux-m32r.org>
Acked-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
Acked-by: Richard Weinberger <richard@nod.at>
Acked-by: Xuetao Guan <gxt@mprc.pku.edu.cn>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v5:
- Rebase to v3.18-rc3
- Update powerpc code to reflect merged power-off handler changes
v4:
- No change
v3:
- Replace poweroff in all newly introduced variables and in text
  with power_off or power-off as appropriate
v2:
- do_kernel_poweroff -> do_kernel_power_off
- have_kernel_poweroff -> have_kernel_power_off

 arch/alpha/kernel/process.c        |  9 +++------
 arch/arc/kernel/reset.c            |  5 +----
 arch/arm/kernel/process.c          |  5 +----
 arch/arm64/kernel/process.c        |  5 +----
 arch/avr32/kernel/process.c        |  6 +-----
 arch/blackfin/kernel/process.c     |  3 ---
 arch/blackfin/kernel/reboot.c      |  2 ++
 arch/c6x/kernel/process.c          |  9 +--------
 arch/cris/kernel/process.c         |  4 +---
 arch/frv/kernel/process.c          |  5 ++---
 arch/hexagon/kernel/reset.c        |  5 ++---
 arch/ia64/kernel/process.c         |  5 +----
 arch/m32r/kernel/process.c         |  8 ++++----
 arch/m68k/kernel/process.c         |  6 +-----
 arch/metag/kernel/process.c        |  6 +-----
 arch/microblaze/kernel/process.c   |  3 ---
 arch/microblaze/kernel/reset.c     |  1 +
 arch/mips/kernel/reset.c           |  6 +-----
 arch/mn10300/kernel/process.c      |  8 ++------
 arch/openrisc/kernel/process.c     |  8 +++++---
 arch/parisc/kernel/process.c       |  8 ++++----
 arch/powerpc/kernel/setup-common.c |  6 +-----
 arch/powerpc/xmon/xmon.c           |  3 +--
 arch/s390/kernel/setup.c           |  8 ++------
 arch/score/kernel/process.c        |  8 ++++----
 arch/sh/kernel/reboot.c            |  6 +-----
 arch/sparc/kernel/process_32.c     | 10 ++--------
 arch/sparc/kernel/reboot.c         |  8 ++------
 arch/tile/kernel/reboot.c          |  7 +++----
 arch/um/kernel/reboot.c            |  2 --
 arch/unicore32/kernel/process.c    |  9 +--------
 arch/x86/kernel/reboot.c           | 11 +++--------
 arch/x86/xen/enlighten.c           |  3 +--
 arch/xtensa/kernel/process.c       |  4 ----
 drivers/parisc/power.c             |  3 +--
 kernel/power/power_off_handler.c   |  9 +++++++++
 kernel/reboot.c                    |  4 ++--
 37 files changed, 68 insertions(+), 150 deletions(-)

diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 1941a07..81c43f8 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -24,6 +24,7 @@
 #include <linux/vt.h>
 #include <linux/mman.h>
 #include <linux/elfcore.h>
+#include <linux/pm.h>
 #include <linux/reboot.h>
 #include <linux/tty.h>
 #include <linux/console.h>
@@ -40,12 +41,6 @@
 #include "proto.h"
 #include "pci_impl.h"
 
-/*
- * Power off function, if any
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 #ifdef CONFIG_ALPHA_WTINT
 /*
  * Sleep the CPU.
@@ -184,6 +179,8 @@ machine_halt(void)
 void
 machine_power_off(void)
 {
+	do_kernel_power_off();
+
 	common_shutdown(LINUX_REBOOT_CMD_POWER_OFF, NULL);
 }
 
diff --git a/arch/arc/kernel/reset.c b/arch/arc/kernel/reset.c
index 2768fa1..0758d9d 100644
--- a/arch/arc/kernel/reset.c
+++ b/arch/arc/kernel/reset.c
@@ -26,9 +26,6 @@ void machine_restart(char *__unused)
 
 void machine_power_off(void)
 {
-	/* FIXME ::  power off ??? */
+	do_kernel_power_off();
 	machine_halt();
 }
-
-void (*pm_power_off) (void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index fe972a2..aa3f656 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -117,8 +117,6 @@ void soft_restart(unsigned long addr)
 /*
  * Function pointers to optional machine specific functions
  */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 
@@ -205,8 +203,7 @@ void machine_power_off(void)
 	local_irq_disable();
 	smp_send_stop();
 
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index fde9923..6f623a0 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -68,8 +68,6 @@ void soft_restart(unsigned long addr)
 /*
  * Function pointers to optional machine specific functions
  */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL_GPL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 
@@ -129,8 +127,7 @@ void machine_power_off(void)
 {
 	local_irq_disable();
 	smp_send_stop();
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/avr32/kernel/process.c b/arch/avr32/kernel/process.c
index 42a53e74..529c1f6 100644
--- a/arch/avr32/kernel/process.c
+++ b/arch/avr32/kernel/process.c
@@ -23,9 +23,6 @@
 
 #include <mach/pm.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * This file handles the architecture-dependent parts of process handling..
  */
@@ -48,8 +45,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 void machine_restart(char *cmd)
diff --git a/arch/blackfin/kernel/process.c b/arch/blackfin/kernel/process.c
index 4aa5545..812dd83 100644
--- a/arch/blackfin/kernel/process.c
+++ b/arch/blackfin/kernel/process.c
@@ -39,9 +39,6 @@ int nr_l1stack_tasks;
 void *l1_stack_base;
 unsigned long l1_stack_len;
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * The idle loop on BFIN
  */
diff --git a/arch/blackfin/kernel/reboot.c b/arch/blackfin/kernel/reboot.c
index c4f50a3..387d610 100644
--- a/arch/blackfin/kernel/reboot.c
+++ b/arch/blackfin/kernel/reboot.c
@@ -7,6 +7,7 @@
  */
 
 #include <linux/interrupt.h>
+#include <linux/pm.h>
 #include <asm/bfin-global.h>
 #include <asm/reboot.h>
 #include <asm/bfrom.h>
@@ -106,6 +107,7 @@ void machine_halt(void)
 __attribute__((weak))
 void native_machine_power_off(void)
 {
+	do_kernel_power_off();
 	idle_with_irq_disabled();
 }
 
diff --git a/arch/c6x/kernel/process.c b/arch/c6x/kernel/process.c
index 57d2ea8..edf7e5a 100644
--- a/arch/c6x/kernel/process.c
+++ b/arch/c6x/kernel/process.c
@@ -27,12 +27,6 @@ void	(*c6x_halt)(void);
 extern asmlinkage void ret_from_fork(void);
 extern asmlinkage void ret_from_kernel_thread(void);
 
-/*
- * power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void arch_cpu_idle(void)
 {
 	unsigned long tmp;
@@ -73,8 +67,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	halt_loop();
 }
 
diff --git a/arch/cris/kernel/process.c b/arch/cris/kernel/process.c
index b78498e..9ebd76b 100644
--- a/arch/cris/kernel/process.c
+++ b/arch/cris/kernel/process.c
@@ -31,9 +31,6 @@
 
 extern void default_idle(void);
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void arch_cpu_idle(void)
 {
 	default_idle();
@@ -60,6 +57,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/frv/kernel/process.c b/arch/frv/kernel/process.c
index 5d40aeb77..502dabb 100644
--- a/arch/frv/kernel/process.c
+++ b/arch/frv/kernel/process.c
@@ -42,9 +42,6 @@ asmlinkage void ret_from_kernel_thread(void);
 
 #include <asm/pgalloc.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 static void core_sleep_idle(void)
 {
 #ifdef LED_DEBUG_SLEEP
@@ -107,6 +104,8 @@ void machine_power_off(void)
 	gdbstub_exit(0);
 #endif
 
+	do_kernel_power_off();
+
 	for (;;);
 }
 
diff --git a/arch/hexagon/kernel/reset.c b/arch/hexagon/kernel/reset.c
index 76483c1..6f607b6 100644
--- a/arch/hexagon/kernel/reset.c
+++ b/arch/hexagon/kernel/reset.c
@@ -16,11 +16,13 @@
  * 02110-1301, USA.
  */
 
+#include <linux/pm.h>
 #include <linux/smp.h>
 #include <asm/hexagon_vm.h>
 
 void machine_power_off(void)
 {
+	do_kernel_power_off();
 	smp_send_stop();
 	__vmstop();
 }
@@ -32,6 +34,3 @@ void machine_halt(void)
 void machine_restart(char *cmd)
 {
 }
-
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index b515149..88121a2 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -57,8 +57,6 @@ void (*ia64_mark_idle)(int);
 
 unsigned long boot_option_idle_override = IDLE_NO_OVERRIDE;
 EXPORT_SYMBOL(boot_option_idle_override);
-void (*pm_power_off) (void);
-EXPORT_SYMBOL(pm_power_off);
 
 void
 ia64_do_show_stack (struct unw_frame_info *info, void *arg)
@@ -675,8 +673,7 @@ machine_halt (void)
 void
 machine_power_off (void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	machine_halt();
 }
 
diff --git a/arch/m32r/kernel/process.c b/arch/m32r/kernel/process.c
index e69221d..65a037e 100644
--- a/arch/m32r/kernel/process.c
+++ b/arch/m32r/kernel/process.c
@@ -23,6 +23,7 @@
 #include <linux/fs.h>
 #include <linux/slab.h>
 #include <linux/module.h>
+#include <linux/pm.h>
 #include <linux/ptrace.h>
 #include <linux/unistd.h>
 #include <linux/hardirq.h>
@@ -44,9 +45,6 @@ unsigned long thread_saved_pc(struct task_struct *tsk)
 	return tsk->thread.lr;
 }
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_restart(char *__unused)
 {
 #if defined(CONFIG_PLAT_MAPPI3)
@@ -67,7 +65,9 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	/* M32R_FIXME */
+	do_kernel_power_off();
+	for (;;)
+		;
 }
 
 void show_regs(struct pt_regs * regs)
diff --git a/arch/m68k/kernel/process.c b/arch/m68k/kernel/process.c
index afe3d6e..bbc0a63 100644
--- a/arch/m68k/kernel/process.c
+++ b/arch/m68k/kernel/process.c
@@ -78,14 +78,10 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	for (;;);
 }
 
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 void show_regs(struct pt_regs * regs)
 {
 	printk("\n");
diff --git a/arch/metag/kernel/process.c b/arch/metag/kernel/process.c
index 483dff9..8d95773 100644
--- a/arch/metag/kernel/process.c
+++ b/arch/metag/kernel/process.c
@@ -67,9 +67,6 @@ void arch_cpu_idle_dead(void)
 }
 #endif
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void (*soc_restart)(char *cmd);
 void (*soc_halt)(void);
 
@@ -90,8 +87,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	smp_send_stop();
 	hard_processor_halt(HALT_OK);
 }
diff --git a/arch/microblaze/kernel/process.c b/arch/microblaze/kernel/process.c
index b2dd371..0ebca36 100644
--- a/arch/microblaze/kernel/process.c
+++ b/arch/microblaze/kernel/process.c
@@ -44,9 +44,6 @@ void show_regs(struct pt_regs *regs)
 				regs->msr, regs->ear, regs->esr, regs->fsr);
 }
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void flush_thread(void)
 {
 }
diff --git a/arch/microblaze/kernel/reset.c b/arch/microblaze/kernel/reset.c
index fbe58c6..2c6b32c 100644
--- a/arch/microblaze/kernel/reset.c
+++ b/arch/microblaze/kernel/reset.c
@@ -103,6 +103,7 @@ void machine_halt(void)
 void machine_power_off(void)
 {
 	pr_notice("Machine power off...\n");
+	do_kernel_power_off();
 	while (1)
 		;
 }
diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 07fc524..09e74d2 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -21,9 +21,6 @@
  */
 void (*_machine_restart)(char *command);
 void (*_machine_halt)(void);
-void (*pm_power_off)(void);
-
-EXPORT_SYMBOL(pm_power_off);
 
 void machine_restart(char *command)
 {
@@ -39,6 +36,5 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
diff --git a/arch/mn10300/kernel/process.c b/arch/mn10300/kernel/process.c
index 3707da5..c78b2eb 100644
--- a/arch/mn10300/kernel/process.c
+++ b/arch/mn10300/kernel/process.c
@@ -20,6 +20,7 @@
 #include <linux/user.h>
 #include <linux/interrupt.h>
 #include <linux/delay.h>
+#include <linux/pm.h>
 #include <linux/reboot.h>
 #include <linux/percpu.h>
 #include <linux/err.h>
@@ -45,12 +46,6 @@ unsigned long thread_saved_pc(struct task_struct *tsk)
 }
 
 /*
- * power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
-/*
  * On SMP it's slightly faster (but much more power-consuming!)
  * to poll the ->work.need_resched flag instead of waiting for the
  * cross-CPU IPI to arrive. Use this option with caution.
@@ -93,6 +88,7 @@ void machine_power_off(void)
 #ifdef CONFIG_KERNEL_DEBUGGER
 	gdbstub_exit(0);
 #endif
+	do_kernel_power_off();
 }
 
 void show_regs(struct pt_regs *regs)
diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
index 386af25..494afd2 100644
--- a/arch/openrisc/kernel/process.c
+++ b/arch/openrisc/kernel/process.c
@@ -25,6 +25,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/mm.h>
+#include <linux/pm.h>
 #include <linux/stddef.h>
 #include <linux/unistd.h>
 #include <linux/ptrace.h>
@@ -51,7 +52,7 @@
  */
 struct thread_info *current_thread_info_set[NR_CPUS] = { &init_thread_info, };
 
-void machine_restart(void)
+void machine_restart(char *cmd)
 {
 	printk(KERN_INFO "*** MACHINE RESTART ***\n");
 	__asm__("l.nop 1");
@@ -72,11 +73,12 @@ void machine_halt(void)
 void machine_power_off(void)
 {
 	printk(KERN_INFO "*** MACHINE POWER OFF ***\n");
+
+	do_kernel_power_off();
+
 	__asm__("l.nop 1");
 }
 
-void (*pm_power_off) (void) = machine_power_off;
-
 /*
  * When a process does an "exec", machine state like FPU and debug
  * registers need to be reset.  This is a hook function for that.
diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
index 0bbbf0d..3f5d14a 100644
--- a/arch/parisc/kernel/process.c
+++ b/arch/parisc/kernel/process.c
@@ -41,6 +41,7 @@
 #include <linux/fs.h>
 #include <linux/module.h>
 #include <linux/personality.h>
+#include <linux/pm.h>
 #include <linux/ptrace.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
@@ -133,7 +134,9 @@ void machine_power_off(void)
 	pdc_soft_power_button(0);
 	
 	pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN);
-		
+
+	do_kernel_power_off();
+
 	/* It seems we have no way to power the system off via
 	 * software. The user has to press the button himself. */
 
@@ -141,9 +144,6 @@ void machine_power_off(void)
 	       "Please power this system off now.");
 }
 
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * Free current thread data structures etc..
  */
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 44c8d03..a2efce7 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -139,8 +139,7 @@ void machine_restart(char *cmd)
 void machine_power_off(void)
 {
 	machine_shutdown();
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 #ifdef CONFIG_SMP
 	smp_send_stop();
 #endif
@@ -151,9 +150,6 @@ void machine_power_off(void)
 /* Used by the G5 thermal driver */
 EXPORT_SYMBOL_GPL(machine_power_off);
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL_GPL(pm_power_off);
-
 void machine_halt(void)
 {
 	machine_shutdown();
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 506d256..8780178 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -981,8 +981,7 @@ static void bootcmds(void)
 	else if (cmd == 'h')
 		ppc_md.halt();
 	else if (cmd == 'p')
-		if (pm_power_off)
-			pm_power_off();
+		do_kernel_power_off();
 }
 
 static int cpu_cmd(void)
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index e80d9ff..267e025 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -263,13 +263,9 @@ void machine_power_off(void)
 		 */
 		console_unblank();
 	_machine_power_off();
-}
 
-/*
- * Dummy power off function.
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL_GPL(pm_power_off);
+	do_kernel_power_off();
+}
 
 static int __init early_parse_mem(char *p)
 {
diff --git a/arch/score/kernel/process.c b/arch/score/kernel/process.c
index a1519ad3..b76ea67 100644
--- a/arch/score/kernel/process.c
+++ b/arch/score/kernel/process.c
@@ -29,9 +29,6 @@
 #include <linux/pm.h>
 #include <linux/rcupdate.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 /* If or when software machine-restart is implemented, add code here. */
 void machine_restart(char *command) {}
 
@@ -39,7 +36,10 @@ void machine_restart(char *command) {}
 void machine_halt(void) {}
 
 /* If or when software machine-power-off is implemented, add code here. */
-void machine_power_off(void) {}
+void machine_power_off(void)
+{
+	do_kernel_power_off();
+}
 
 void ret_from_fork(void);
 void ret_from_kernel_thread(void);
diff --git a/arch/sh/kernel/reboot.c b/arch/sh/kernel/reboot.c
index 04afe5b..065de12 100644
--- a/arch/sh/kernel/reboot.c
+++ b/arch/sh/kernel/reboot.c
@@ -11,9 +11,6 @@
 #include <asm/tlbflush.h>
 #include <asm/traps.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 #ifdef CONFIG_SUPERH32
 static void watchdog_trigger_immediate(void)
 {
@@ -51,8 +48,7 @@ static void native_machine_shutdown(void)
 
 static void native_machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 static void native_machine_halt(void)
diff --git a/arch/sparc/kernel/process_32.c b/arch/sparc/kernel/process_32.c
index 50e7b62..cb8148a 100644
--- a/arch/sparc/kernel/process_32.c
+++ b/arch/sparc/kernel/process_32.c
@@ -48,14 +48,6 @@
  */
 void (*sparc_idle)(void);
 
-/* 
- * Power-off handler instantiation for pm.h compliance
- * This is done via auxio, but could be used as a fallback
- * handler when auxio is not present-- unused for now...
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * sysctl - toggle power-off restriction for serial console 
  * systems in machine_power_off()
@@ -112,6 +104,8 @@ void machine_power_off(void)
 		sbus_writeb(power_register, auxio_power_register);
 	}
 
+	do_kernel_power_off();
+
 	machine_halt();
 }
 
diff --git a/arch/sparc/kernel/reboot.c b/arch/sparc/kernel/reboot.c
index eba7d91..3c0bb03 100644
--- a/arch/sparc/kernel/reboot.c
+++ b/arch/sparc/kernel/reboot.c
@@ -16,17 +16,13 @@
  */
 int scons_pwroff = 1;
 
-/* This isn't actually used, it exists merely to satisfy the
- * reference in kernel/sys.c
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_power_off(void)
 {
 	if (strcmp(of_console_device->type, "serial") || scons_pwroff)
 		prom_halt_power_off();
 
+	do_kernel_power_off();
+
 	prom_halt();
 }
 
diff --git a/arch/tile/kernel/reboot.c b/arch/tile/kernel/reboot.c
index 6c5d2c0..8ff4a7f 100644
--- a/arch/tile/kernel/reboot.c
+++ b/arch/tile/kernel/reboot.c
@@ -36,6 +36,9 @@ void machine_power_off(void)
 {
 	arch_local_irq_disable_all();
 	smp_send_stop();
+
+	do_kernel_power_off();
+
 	hv_power_off();
 }
 
@@ -45,7 +48,3 @@ void machine_restart(char *cmd)
 	smp_send_stop();
 	hv_restart((HV_VirtAddr) "vmlinux", (HV_VirtAddr) cmd);
 }
-
-/* No interesting distinction to be made here. */
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/um/kernel/reboot.c b/arch/um/kernel/reboot.c
index ced8903..a82ef28 100644
--- a/arch/um/kernel/reboot.c
+++ b/arch/um/kernel/reboot.c
@@ -11,8 +11,6 @@
 #include <os.h>
 #include <skas.h>
 
-void (*pm_power_off)(void);
-
 static void kill_off_processes(void)
 {
 	if (proc_mm)
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index b008e99..9490dd5 100644
--- a/arch/unicore32/kernel/process.c
+++ b/arch/unicore32/kernel/process.c
@@ -56,16 +56,9 @@ void machine_halt(void)
 	gpio_set_value(GPO_SOFT_OFF, 0);
 }
 
-/*
- * Function pointers to optional machine specific functions
- */
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	machine_halt();
 }
 
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 17962e6..5c09e28 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -30,12 +30,6 @@
 #include <asm/x86_init.h>
 #include <asm/efi.h>
 
-/*
- * Power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 static const struct desc_ptr no_idt = {};
 
 /*
@@ -647,11 +641,12 @@ static void native_machine_halt(void)
 
 static void native_machine_power_off(void)
 {
-	if (pm_power_off) {
+	if (have_kernel_power_off()) {
 		if (!reboot_force)
 			machine_shutdown();
-		pm_power_off();
+		do_kernel_power_off();
 	}
+
 	/* A fallback in case there is no PM info available */
 	tboot_shutdown(TB_SHUTDOWN_HALT);
 }
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index fac5e4f..bc08998 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1320,8 +1320,7 @@ static void xen_machine_halt(void)
 
 static void xen_machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	xen_reboot(SHUTDOWN_poweroff);
 }
 
diff --git a/arch/xtensa/kernel/process.c b/arch/xtensa/kernel/process.c
index 1c85323..c487296 100644
--- a/arch/xtensa/kernel/process.c
+++ b/arch/xtensa/kernel/process.c
@@ -49,10 +49,6 @@ extern void ret_from_kernel_thread(void);
 
 struct task_struct *current_set[NR_CPUS] = {&init_task, };
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
-
 #if XTENSA_HAVE_COPROCESSORS
 
 void coprocessor_release_all(struct thread_info *ti)
diff --git a/drivers/parisc/power.c b/drivers/parisc/power.c
index ef31b77..f10cf92 100644
--- a/drivers/parisc/power.c
+++ b/drivers/parisc/power.c
@@ -95,8 +95,7 @@ static void process_shutdown(void)
 		/* send kill signal */
 		if (kill_cad_pid(SIGINT, 1)) {
 			/* just in case killing init process failed */
-			if (pm_power_off)
-				pm_power_off();
+			kernel_power_off();
 		}
 	}
 }
diff --git a/kernel/power/power_off_handler.c b/kernel/power/power_off_handler.c
index e576534..e283ea1 100644
--- a/kernel/power/power_off_handler.c
+++ b/kernel/power/power_off_handler.c
@@ -23,6 +23,12 @@
 #include <linux/types.h>
 
 /*
+ * If set, calling this function will power off the system immediately.
+ */
+void (*pm_power_off)(void);
+EXPORT_SYMBOL(pm_power_off);
+
+/*
  * List of handlers for kernel code which wants to be called
  * to power off the system.
  */
@@ -272,6 +278,9 @@ void do_kernel_power_off(void)
 	 * that risk.
 	 */
 
+	if (pm_power_off)
+		pm_power_off();
+
 	p = rcu_dereference_raw(power_off_handler_list);
 	while (p) {
 		next_p = rcu_dereference_raw(p->next);
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 5925f5a..d87d921 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -306,9 +306,9 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
 		return ret;
 
 	/* Instead of trying to make the power_off code look like
-	 * halt when pm_power_off is not set do it the easy way.
+	 * halt when no power-off handler exists do it the easy way.
 	 */
-	if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) && !pm_power_off)
+	if (cmd == LINUX_REBOOT_CMD_POWER_OFF && !have_kernel_power_off())
 		cmd = LINUX_REBOOT_CMD_HALT;
 
 	mutex_lock(&reboot_mutex);
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:47:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16: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 1XmQDH-0002ZK-Cb; Thu, 06 Nov 2014 16:47:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@roeck-us.net>) id 1XmQDF-0002Z9-MA
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:47:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D9/F4-24532-D06AB545; Thu, 06 Nov 2014 16:47:09 +0000
X-Env-Sender: linux@roeck-us.net
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415292426!11969455!1
X-Originating-IP: [208.91.199.152]
X-SpamReason: No, hits=2.2 required=7.0 tests=SUSPICIOUS_RECIPS,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14863 invoked from network); 6 Nov 2014 16:47:07 -0000
Received: from bh-25.webhostbox.net (HELO bh-25.webhostbox.net)
	(208.91.199.152)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 16:47:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roeck-us.net;
	s=default; 
	h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=Y8zSis+gE1RiJQjDus4cYg4FYnofJ8mi5dLts6zg3hc=; 
	b=OU7t8c2a2Km81hmAtlBGNoeqxPSrQ5GdvdzyWAjCU/l7TarGwTzQ1Fz5pYI330sobBd7nqpQG8JLlk5qrweqt0A5V9gYFgJGtAUauTQlRMGifss2NSddBzPvvszmqmov2aE5Ih8ZKsBpfVEtSz6SOMY7T+I10vnHQl/x7U9/92g=;
Received: from mailnull by bh-25.webhostbox.net with sa-checked (Exim 4.82)
	(envelope-from <linux@roeck-us.net>) id 1XmQDB-000YHh-Pk
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:47:05 +0000
Received: from 108-223-40-66.lightspeed.sntcca.sbcglobal.net
	([108.223.40.66]:35333 helo=localhost)
	by bh-25.webhostbox.net with esmtpa (Exim 4.82)
	(envelope-from <linux@roeck-us.net>)
	id 1XmQBD-000Uxd-LV; Thu, 06 Nov 2014 16:45:05 +0000
From: Guenter Roeck <linux@roeck-us.net>
To: linux-kernel@vger.kernel.org
Date: Thu,  6 Nov 2014 08:43:19 -0800
Message-Id: <1415292213-28652-36-git-send-email-linux@roeck-us.net>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415292213-28652-1-git-send-email-linux@roeck-us.net>
References: <1415292213-28652-1-git-send-email-linux@roeck-us.net>
X-Authenticated_sender: guenter@roeck-us.net
X-OutGoing-Spam-Status: No, score=1.5
X-Spam-Checker-Version: spamc_ctasd client on
	localost
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=50.0 tests=SpamClass_Unknown,
	VirusClass_Unknown autolearn=disabled version=1.0.0
X-CTCH-PVer: 0000001
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-Flags: 0
X-CTCH-RefID: str=0001.0A020203.545BA609.02E8, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-Score: 0.000
X-CTCH-ScoreCust: 0.000
X-CTCH-Rules: 
X-CTCH-SenderID: linux@roeck-us.net
X-CTCH-SenderID-Flags: 0
X-CTCH-SenderID-TotalMessages: 310
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-TotalRecipients: 0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - lists.xenproject.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from
	get_relayhosts_entry
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: linux-samsung-soc@vger.kernel.org, Russell King <linux@arm.linux.org.uk>,
	linux-pm@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com,
	Guenter Roeck <linux@roeck-us.net>,
	xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 35/48] arm: Register with kernel power-off
	handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Register with kernel power-off handler instead of setting pm_power_off
directly. Always use register_power_off_handler_simple as there is no
indication that more than one power-off handler is registered.

If the power-off handler only resets the system or puts the CPU in sleep mode,
select the fallback priority to indicate that the power-off handler is one
of last resort. If the power-off handler powers off the system, select the
default priority.

Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v5:
- Rebase to v3.18-rc3
v4:
- No change
v3:
- Replace poweroff in all newly introduced variables and in text
  with power_off or power-off as appropriate
- Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
v2:
- Use defines to specify poweroff handler priorities
- Drop changes in arch/arm/mach-at91/setup.c (file removed upstream)

 arch/arm/kernel/psci.c                         | 3 ++-
 arch/arm/mach-at91/board-gsia18s.c             | 3 ++-
 arch/arm/mach-bcm/board_bcm2835.c              | 3 ++-
 arch/arm/mach-cns3xxx/cns3420vb.c              | 3 ++-
 arch/arm/mach-cns3xxx/core.c                   | 3 ++-
 arch/arm/mach-highbank/highbank.c              | 3 ++-
 arch/arm/mach-imx/mach-mx31moboard.c           | 3 ++-
 arch/arm/mach-iop32x/em7210.c                  | 3 ++-
 arch/arm/mach-iop32x/glantank.c                | 3 ++-
 arch/arm/mach-iop32x/iq31244.c                 | 3 ++-
 arch/arm/mach-iop32x/n2100.c                   | 3 ++-
 arch/arm/mach-ixp4xx/dsmg600-setup.c           | 3 ++-
 arch/arm/mach-ixp4xx/nas100d-setup.c           | 3 ++-
 arch/arm/mach-ixp4xx/nslu2-setup.c             | 3 ++-
 arch/arm/mach-omap2/board-omap3touchbook.c     | 3 ++-
 arch/arm/mach-orion5x/board-mss2.c             | 3 ++-
 arch/arm/mach-orion5x/dns323-setup.c           | 9 ++++++---
 arch/arm/mach-orion5x/kurobox_pro-setup.c      | 3 ++-
 arch/arm/mach-orion5x/ls-chl-setup.c           | 3 ++-
 arch/arm/mach-orion5x/ls_hgl-setup.c           | 3 ++-
 arch/arm/mach-orion5x/lsmini-setup.c           | 3 ++-
 arch/arm/mach-orion5x/mv2120-setup.c           | 3 ++-
 arch/arm/mach-orion5x/net2big-setup.c          | 3 ++-
 arch/arm/mach-orion5x/terastation_pro2-setup.c | 3 ++-
 arch/arm/mach-orion5x/ts209-setup.c            | 3 ++-
 arch/arm/mach-orion5x/ts409-setup.c            | 3 ++-
 arch/arm/mach-pxa/corgi.c                      | 3 ++-
 arch/arm/mach-pxa/mioa701.c                    | 3 ++-
 arch/arm/mach-pxa/poodle.c                     | 3 ++-
 arch/arm/mach-pxa/spitz.c                      | 3 ++-
 arch/arm/mach-pxa/tosa.c                       | 3 ++-
 arch/arm/mach-pxa/viper.c                      | 3 ++-
 arch/arm/mach-pxa/z2.c                         | 7 ++++---
 arch/arm/mach-pxa/zeus.c                       | 7 ++++---
 arch/arm/mach-s3c24xx/mach-gta02.c             | 3 ++-
 arch/arm/mach-s3c24xx/mach-jive.c              | 3 ++-
 arch/arm/mach-s3c24xx/mach-vr1000.c            | 3 ++-
 arch/arm/mach-s3c64xx/mach-smartq.c            | 3 ++-
 arch/arm/mach-sa1100/generic.c                 | 3 ++-
 arch/arm/mach-sa1100/simpad.c                  | 3 ++-
 arch/arm/mach-u300/regulator.c                 | 3 ++-
 arch/arm/mach-vt8500/vt8500.c                  | 3 ++-
 arch/arm/xen/enlighten.c                       | 3 ++-
 43 files changed, 94 insertions(+), 49 deletions(-)

diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index f73891b..a7a2b4a 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -264,7 +264,8 @@ static int psci_0_2_init(struct device_node *np)
 
 	arm_pm_restart = psci_sys_reset;
 
-	pm_power_off = psci_sys_poweroff;
+	register_power_off_handler_simple(psci_sys_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 out_put_node:
 	of_node_put(np);
diff --git a/arch/arm/mach-at91/board-gsia18s.c b/arch/arm/mach-at91/board-gsia18s.c
index bf5cc55..e628c4a 100644
--- a/arch/arm/mach-at91/board-gsia18s.c
+++ b/arch/arm/mach-at91/board-gsia18s.c
@@ -521,7 +521,8 @@ static void gsia18s_power_off(void)
 
 static int __init gsia18s_power_off_init(void)
 {
-	pm_power_off = gsia18s_power_off;
+	register_power_off_handler_simple(gsia18s_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 	return 0;
 }
 
diff --git a/arch/arm/mach-bcm/board_bcm2835.c b/arch/arm/mach-bcm/board_bcm2835.c
index 70f2f39..1d75c76 100644
--- a/arch/arm/mach-bcm/board_bcm2835.c
+++ b/arch/arm/mach-bcm/board_bcm2835.c
@@ -111,7 +111,8 @@ static void __init bcm2835_init(void)
 
 	bcm2835_setup_restart();
 	if (wdt_regs)
-		pm_power_off = bcm2835_power_off;
+		register_power_off_handler_simple(bcm2835_power_off,
+						  POWER_OFF_PRIORITY_FALLBACK);
 
 	bcm2835_init_clocks();
 
diff --git a/arch/arm/mach-cns3xxx/cns3420vb.c b/arch/arm/mach-cns3xxx/cns3420vb.c
index 6428bcc7..5c50461 100644
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -224,7 +224,8 @@ static void __init cns3420_init(void)
 	cns3xxx_ahci_init();
 	cns3xxx_sdhci_init();
 
-	pm_power_off = cns3xxx_power_off;
+	register_power_off_handler_simple(cns3xxx_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 static struct map_desc cns3420_io_desc[] __initdata = {
diff --git a/arch/arm/mach-cns3xxx/core.c b/arch/arm/mach-cns3xxx/core.c
index 4e9837d..9c214cf 100644
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -386,7 +386,8 @@ static void __init cns3xxx_init(void)
 		cns3xxx_pwr_soft_rst(CNS3XXX_PWR_SOFTWARE_RST(SDIO));
 	}
 
-	pm_power_off = cns3xxx_power_off;
+	register_power_off_handler_simple(cns3xxx_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	of_platform_populate(NULL, of_default_bus_match_table,
                         cns3xxx_auxdata, NULL);
diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index 07a0957..6fbdc01 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -155,7 +155,8 @@ static void __init highbank_init(void)
 	sregs_base = of_iomap(np, 0);
 	WARN_ON(!sregs_base);
 
-	pm_power_off = highbank_power_off;
+	register_power_off_handler_simple(highbank_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	highbank_pm_init();
 
 	bus_register_notifier(&platform_bus_type, &highbank_platform_nb);
diff --git a/arch/arm/mach-imx/mach-mx31moboard.c b/arch/arm/mach-imx/mach-mx31moboard.c
index bb6f8a5..3001b14 100644
--- a/arch/arm/mach-imx/mach-mx31moboard.c
+++ b/arch/arm/mach-imx/mach-mx31moboard.c
@@ -559,7 +559,8 @@ static void __init mx31moboard_init(void)
 
 	imx_add_platform_device("imx_mc13783", 0, NULL, 0, NULL, 0);
 
-	pm_power_off = mx31moboard_poweroff;
+	register_power_off_handler_simple(mx31moboard_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	switch (mx31moboard_baseboard) {
 	case MX31NOBOARD:
diff --git a/arch/arm/mach-iop32x/em7210.c b/arch/arm/mach-iop32x/em7210.c
index 77e1ff0..fd3ad09 100644
--- a/arch/arm/mach-iop32x/em7210.c
+++ b/arch/arm/mach-iop32x/em7210.c
@@ -201,7 +201,8 @@ static int __init em7210_request_gpios(void)
 		return 0;
 	}
 
-	pm_power_off = em7210_power_off;
+	register_power_off_handler_simple(em7210_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return 0;
 }
diff --git a/arch/arm/mach-iop32x/glantank.c b/arch/arm/mach-iop32x/glantank.c
index 547b234..9298ea0 100644
--- a/arch/arm/mach-iop32x/glantank.c
+++ b/arch/arm/mach-iop32x/glantank.c
@@ -199,7 +199,8 @@ static void __init glantank_init_machine(void)
 	i2c_register_board_info(0, glantank_i2c_devices,
 		ARRAY_SIZE(glantank_i2c_devices));
 
-	pm_power_off = glantank_power_off;
+	register_power_off_handler_simple(glantank_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(GLANTANK, "GLAN Tank")
diff --git a/arch/arm/mach-iop32x/iq31244.c b/arch/arm/mach-iop32x/iq31244.c
index 0e1392b..50ba54b 100644
--- a/arch/arm/mach-iop32x/iq31244.c
+++ b/arch/arm/mach-iop32x/iq31244.c
@@ -293,7 +293,8 @@ static void __init iq31244_init_machine(void)
 	platform_device_register(&iop3xx_dma_1_channel);
 
 	if (is_ep80219())
-		pm_power_off = ep80219_power_off;
+		register_power_off_handler_simple(ep80219_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (!is_80219())
 		platform_device_register(&iop3xx_aau_channel);
diff --git a/arch/arm/mach-iop32x/n2100.c b/arch/arm/mach-iop32x/n2100.c
index c1cd80e..734a092 100644
--- a/arch/arm/mach-iop32x/n2100.c
+++ b/arch/arm/mach-iop32x/n2100.c
@@ -356,7 +356,8 @@ static void __init n2100_init_machine(void)
 	i2c_register_board_info(0, n2100_i2c_devices,
 		ARRAY_SIZE(n2100_i2c_devices));
 
-	pm_power_off = n2100_power_off;
+	register_power_off_handler_simple(n2100_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(N2100, "Thecus N2100")
diff --git a/arch/arm/mach-ixp4xx/dsmg600-setup.c b/arch/arm/mach-ixp4xx/dsmg600-setup.c
index 43ee06d..f34564d 100644
--- a/arch/arm/mach-ixp4xx/dsmg600-setup.c
+++ b/arch/arm/mach-ixp4xx/dsmg600-setup.c
@@ -281,7 +281,8 @@ static void __init dsmg600_init(void)
 
 	platform_add_devices(dsmg600_devices, ARRAY_SIZE(dsmg600_devices));
 
-	pm_power_off = dsmg600_power_off;
+	register_power_off_handler_simple(dsmg600_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(DSMG600, "D-Link DSM-G600 RevA")
diff --git a/arch/arm/mach-ixp4xx/nas100d-setup.c b/arch/arm/mach-ixp4xx/nas100d-setup.c
index 4e0f762..43a9333 100644
--- a/arch/arm/mach-ixp4xx/nas100d-setup.c
+++ b/arch/arm/mach-ixp4xx/nas100d-setup.c
@@ -292,7 +292,8 @@ static void __init nas100d_init(void)
 
 	platform_add_devices(nas100d_devices, ARRAY_SIZE(nas100d_devices));
 
-	pm_power_off = nas100d_power_off;
+	register_power_off_handler_simple(nas100d_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (request_irq(gpio_to_irq(NAS100D_RB_GPIO), &nas100d_reset_handler,
 		IRQF_TRIGGER_LOW, "NAS100D reset button", NULL) < 0) {
diff --git a/arch/arm/mach-ixp4xx/nslu2-setup.c b/arch/arm/mach-ixp4xx/nslu2-setup.c
index 88c025f..e094d5f 100644
--- a/arch/arm/mach-ixp4xx/nslu2-setup.c
+++ b/arch/arm/mach-ixp4xx/nslu2-setup.c
@@ -262,7 +262,8 @@ static void __init nslu2_init(void)
 
 	platform_add_devices(nslu2_devices, ARRAY_SIZE(nslu2_devices));
 
-	pm_power_off = nslu2_power_off;
+	register_power_off_handler_simple(nslu2_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (request_irq(gpio_to_irq(NSLU2_RB_GPIO), &nslu2_reset_handler,
 		IRQF_TRIGGER_LOW, "NSLU2 reset button", NULL) < 0) {
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
index a01993e..8abce2c 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -344,7 +344,8 @@ static void __init omap3_touchbook_init(void)
 {
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 
-	pm_power_off = omap3_touchbook_poweroff;
+	register_power_off_handler_simple(omap3_touchbook_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (system_rev >= 0x20 && system_rev <= 0x34301000) {
 		omap_mux_init_gpio(23, OMAP_PIN_INPUT);
diff --git a/arch/arm/mach-orion5x/board-mss2.c b/arch/arm/mach-orion5x/board-mss2.c
index 66f9c3b..cac2793 100644
--- a/arch/arm/mach-orion5x/board-mss2.c
+++ b/arch/arm/mach-orion5x/board-mss2.c
@@ -86,5 +86,6 @@ static void mss2_power_off(void)
 void __init mss2_init(void)
 {
 	/* register mss2 specific power-off method */
-	pm_power_off = mss2_power_off;
+	register_power_off_handler_simple(mss2_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 }
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index 09d2a26..9876509 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -669,7 +669,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323a_power_off;
+		register_power_off_handler_simple(dns323a_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 		break;
 	case DNS323_REV_B1:
 		/* 5182 built-in SATA init */
@@ -686,7 +687,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323b_power_off;
+		register_power_off_handler_simple(dns323b_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 		break;
 	case DNS323_REV_C1:
 		/* 5182 built-in SATA init */
@@ -696,7 +698,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323C_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323C_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323c_power_off;
+		register_power_off_handler_simple(dns323c_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 
 		/* Now, -this- should theorically be done by the sata_mv driver
 		 * once I figure out what's going on there. Maybe the behaviour
diff --git a/arch/arm/mach-orion5x/kurobox_pro-setup.c b/arch/arm/mach-orion5x/kurobox_pro-setup.c
index fe6a48a..872d4fe 100644
--- a/arch/arm/mach-orion5x/kurobox_pro-setup.c
+++ b/arch/arm/mach-orion5x/kurobox_pro-setup.c
@@ -376,7 +376,8 @@ static void __init kurobox_pro_init(void)
 	i2c_register_board_info(0, &kurobox_pro_i2c_rtc, 1);
 
 	/* register Kurobox Pro specific power-off method */
-	pm_power_off = kurobox_pro_power_off;
+	register_power_off_handler_simple(kurobox_pro_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 #ifdef CONFIG_MACH_KUROBOX_PRO
diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
index 028ea03..3f540d1 100644
--- a/arch/arm/mach-orion5x/ls-chl-setup.c
+++ b/arch/arm/mach-orion5x/ls-chl-setup.c
@@ -312,7 +312,8 @@ static void __init lschl_init(void)
 	gpio_set_value(LSCHL_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = lschl_power_off;
+	register_power_off_handler_simple(lschl_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c b/arch/arm/mach-orion5x/ls_hgl-setup.c
index 32b7129..699a5a1 100644
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion5x/ls_hgl-setup.c
@@ -259,7 +259,8 @@ static void __init ls_hgl_init(void)
 	gpio_set_value(LS_HGL_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = ls_hgl_power_off;
+	register_power_off_handler_simple(ls_hgl_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/lsmini-setup.c b/arch/arm/mach-orion5x/lsmini-setup.c
index a6493e7..c5712ff 100644
--- a/arch/arm/mach-orion5x/lsmini-setup.c
+++ b/arch/arm/mach-orion5x/lsmini-setup.c
@@ -260,7 +260,8 @@ static void __init lsmini_init(void)
 	gpio_set_value(LSMINI_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = lsmini_power_off;
+	register_power_off_handler_simple(lsmini_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c b/arch/arm/mach-orion5x/mv2120-setup.c
index e032f01..13efbec 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -225,7 +225,8 @@ static void __init mv2120_init(void)
 	if (gpio_request(MV2120_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 	    gpio_direction_output(MV2120_GPIO_POWER_OFF, 1) != 0)
 		pr_err("mv2120: failed to setup power-off GPIO\n");
-	pm_power_off = mv2120_power_off;
+	register_power_off_handler_simple(mv2120_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 /* Warning: HP uses a wrong mach-type (=526) in their bootloader */
diff --git a/arch/arm/mach-orion5x/net2big-setup.c b/arch/arm/mach-orion5x/net2big-setup.c
index ba73dc7..c7648f0 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -413,7 +413,8 @@ static void __init net2big_init(void)
 
 	if (gpio_request(NET2BIG_GPIO_POWER_OFF, "power-off") == 0 &&
 	    gpio_direction_output(NET2BIG_GPIO_POWER_OFF, 0) == 0)
-		pm_power_off = net2big_power_off;
+		register_power_off_handler_simple(net2big_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 	else
 		pr_err("net2big: failed to configure power-off GPIO\n");
 
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c b/arch/arm/mach-orion5x/terastation_pro2-setup.c
index 1208674..227ae91 100644
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
@@ -353,7 +353,8 @@ static void __init tsp2_init(void)
 	i2c_register_board_info(0, &tsp2_i2c_rtc, 1);
 
 	/* register Terastation Pro II specific power-off method */
-	pm_power_off = tsp2_power_off;
+	register_power_off_handler_simple(tsp2_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TERASTATION_PRO2, "Buffalo Terastation Pro II/Live")
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index c725b7c..540e3f3 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -318,7 +318,8 @@ static void __init qnap_ts209_init(void)
 	i2c_register_board_info(0, &qnap_ts209_i2c_rtc, 1);
 
 	/* register tsx09 specific power-off method */
-	pm_power_off = qnap_tsx09_power_off;
+	register_power_off_handler_simple(qnap_tsx09_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TS209, "QNAP TS-109/TS-209")
diff --git a/arch/arm/mach-orion5x/ts409-setup.c b/arch/arm/mach-orion5x/ts409-setup.c
index cf2ab53..40cbdd7 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -307,7 +307,8 @@ static void __init qnap_ts409_init(void)
 	platform_device_register(&ts409_leds);
 
 	/* register tsx09 specific power-off method */
-	pm_power_off = qnap_tsx09_power_off;
+	register_power_off_handler_simple(qnap_tsx09_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TS409, "QNAP TS-409")
diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index 06022b2..93b73a1 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -718,7 +718,8 @@ static void corgi_restart(enum reboot_mode mode, const char *cmd)
 
 static void __init corgi_init(void)
 {
-	pm_power_off = corgi_poweroff;
+	register_power_off_handler_simple(corgi_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	/* Stop 3.6MHz and drive HIGH to PCMCIA and CS */
 	PCFR |= PCFR_OPDE;
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 29997bd..5d318d4 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -750,7 +750,8 @@ static void __init mioa701_machine_init(void)
 	pxa_set_keypad_info(&mioa701_keypad_info);
 	pxa_set_udc_info(&mioa701_udc_info);
 	pxa_set_ac97_info(&mioa701_ac97_info);
-	pm_power_off = mioa701_poweroff;
+	register_power_off_handler_simple(mioa701_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	platform_add_devices(devices, ARRAY_SIZE(devices));
 	gsm_init();
 
diff --git a/arch/arm/mach-pxa/poodle.c b/arch/arm/mach-pxa/poodle.c
index 1319916..749d2af 100644
--- a/arch/arm/mach-pxa/poodle.c
+++ b/arch/arm/mach-pxa/poodle.c
@@ -432,7 +432,8 @@ static void __init poodle_init(void)
 {
 	int ret = 0;
 
-	pm_power_off = poodle_poweroff;
+	register_power_off_handler_simple(poodle_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PCFR |= PCFR_OPDE;
 
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 840c3a4..ab25b6c 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -944,7 +944,8 @@ static void spitz_restart(enum reboot_mode mode, const char *cmd)
 static void __init spitz_init(void)
 {
 	init_gpio_reset(SPITZ_GPIO_ON_RESET, 1, 0);
-	pm_power_off = spitz_poweroff;
+	register_power_off_handler_simple(spitz_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PMCR = 0x00;
 
diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
index c158a6e..8823448 100644
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -940,7 +940,8 @@ static void __init tosa_init(void)
 
 	init_gpio_reset(TOSA_GPIO_ON_RESET, 0, 0);
 
-	pm_power_off = tosa_poweroff;
+	register_power_off_handler_simple(tosa_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PCFR |= PCFR_OPDE;
 
diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index de3b080..6bb4de3 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -919,7 +919,8 @@ static void __init viper_init(void)
 {
 	u8 version;
 
-	pm_power_off = viper_power_off;
+	register_power_off_handler_simple(viper_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	pxa2xx_mfp_config(ARRAY_AND_SIZE(viper_pin_config));
 
diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
index e1a121b..0d0a6ae 100644
--- a/arch/arm/mach-pxa/z2.c
+++ b/arch/arm/mach-pxa/z2.c
@@ -693,8 +693,6 @@ static void z2_power_off(void)
 	pxa27x_set_pwrmode(PWRMODE_DEEPSLEEP);
 	pxa27x_cpu_pm_enter(PM_SUSPEND_MEM);
 }
-#else
-#define z2_power_off   NULL
 #endif
 
 /******************************************************************************
@@ -719,7 +717,10 @@ static void __init z2_init(void)
 	z2_keys_init();
 	z2_pmic_init();
 
-	pm_power_off = z2_power_off;
+#ifdef CONFIG_PM
+	register_power_off_handler_simple(z2_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
+#endif
 }
 
 MACHINE_START(ZIPIT2, "Zipit Z2")
diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index 205f9bf..457eed1 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -690,8 +690,6 @@ static void zeus_power_off(void)
 	local_irq_disable();
 	cpu_suspend(PWRMODE_DEEPSLEEP, pxa27x_finish_suspend);
 }
-#else
-#define zeus_power_off   NULL
 #endif
 
 #ifdef CONFIG_APM_EMULATION
@@ -847,7 +845,10 @@ static void __init zeus_init(void)
 	__raw_writel(msc0, MSC0);
 	__raw_writel(msc1, MSC1);
 
-	pm_power_off = zeus_power_off;
+#ifdef CONFIG_PM
+	register_power_off_handler_simple(zeus_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
+#endif
 	zeus_setup_apm();
 
 	pxa2xx_mfp_config(ARRAY_AND_SIZE(zeus_pin_config));
diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-s3c24xx/mach-gta02.c
index 6d1e0b9..8366b3e 100644
--- a/arch/arm/mach-s3c24xx/mach-gta02.c
+++ b/arch/arm/mach-s3c24xx/mach-gta02.c
@@ -579,7 +579,8 @@ static void __init gta02_machine_init(void)
 	i2c_register_board_info(0, gta02_i2c_devs, ARRAY_SIZE(gta02_i2c_devs));
 
 	platform_add_devices(gta02_devices, ARRAY_SIZE(gta02_devices));
-	pm_power_off = gta02_poweroff;
+	register_power_off_handler_simple(gta02_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	regulator_has_full_constraints();
 }
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c
index 7d99fe8..20beb39 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -657,7 +657,8 @@ static void __init jive_machine_init(void)
 	s3c_i2c0_set_platdata(&jive_i2c_cfg);
 	i2c_register_board_info(0, jive_i2c_devs, ARRAY_SIZE(jive_i2c_devs));
 
-	pm_power_off = jive_power_off;
+	register_power_off_handler_simple(jive_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	platform_add_devices(jive_devices, ARRAY_SIZE(jive_devices));
 }
diff --git a/arch/arm/mach-s3c24xx/mach-vr1000.c b/arch/arm/mach-s3c24xx/mach-vr1000.c
index 89f32bd..1f32ba7 100644
--- a/arch/arm/mach-s3c24xx/mach-vr1000.c
+++ b/arch/arm/mach-s3c24xx/mach-vr1000.c
@@ -306,7 +306,8 @@ static void vr1000_power_off(void)
 
 static void __init vr1000_map_io(void)
 {
-	pm_power_off = vr1000_power_off;
+	register_power_off_handler_simple(vr1000_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	s3c24xx_init_io(vr1000_iodesc, ARRAY_SIZE(vr1000_iodesc));
 	s3c24xx_init_uarts(vr1000_uartcfgs, ARRAY_SIZE(vr1000_uartcfgs));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c b/arch/arm/mach-s3c64xx/mach-smartq.c
index b3d1353..b30906f 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -291,7 +291,8 @@ static int __init smartq_power_off_init(void)
 	/* leave power on */
 	gpio_direction_output(S3C64XX_GPK(15), 0);
 
-	pm_power_off = smartq_power_off;
+	register_power_off_handler_simple(smartq_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return ret;
 }
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index d4ea142..371bffe 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -311,7 +311,8 @@ static struct platform_device *sa11x0_devices[] __initdata = {
 
 static int __init sa1100_init(void)
 {
-	pm_power_off = sa1100_power_off;
+	register_power_off_handler_simple(sa1100_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	return platform_add_devices(sa11x0_devices, ARRAY_SIZE(sa11x0_devices));
 }
 
diff --git a/arch/arm/mach-sa1100/simpad.c b/arch/arm/mach-sa1100/simpad.c
index 41e476e..fb85730 100644
--- a/arch/arm/mach-sa1100/simpad.c
+++ b/arch/arm/mach-sa1100/simpad.c
@@ -373,7 +373,8 @@ static int __init simpad_init(void)
 	if (ret)
 		printk(KERN_WARNING "simpad: Unable to register cs3 GPIO device");
 
-	pm_power_off = simpad_power_off;
+	register_power_off_handler_simple(simpad_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	sa11x0_ppc_configure_mcp();
 	sa11x0_register_mtd(&simpad_flash_data, simpad_flash_resources,
diff --git a/arch/arm/mach-u300/regulator.c b/arch/arm/mach-u300/regulator.c
index 0493a84..4ff09b0 100644
--- a/arch/arm/mach-u300/regulator.c
+++ b/arch/arm/mach-u300/regulator.c
@@ -98,7 +98,8 @@ static int __init __u300_init_boardpower(struct platform_device *pdev)
 			   U300_SYSCON_PMCR_DCON_ENABLE, 0);
 
 	/* Register globally exported PM poweroff hook */
-	pm_power_off = u300_pm_poweroff;
+	register_power_off_handler_simple(u300_pm_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return 0;
 }
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 3bc0dc9..48e4fbf 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -155,7 +155,8 @@ static void __init vt8500_init(void)
 			pr_err("%s:ioremap(power_off) failed\n", __func__);
 	}
 	if (pmc_base)
-		pm_power_off = &vt8500_power_off;
+		register_power_off_handler_simple(vt8500_power_off,
+						  POWER_OFF_PRIORITY_FALLBACK);
 	else
 		pr_err("%s: PMC Hibernation register could not be remapped, not enabling power off!\n", __func__);
 
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e15f01..1c8bce0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -336,7 +336,8 @@ static int __init xen_pm_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	pm_power_off = xen_power_off;
+	register_power_off_handler_simple(xen_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 	arm_pm_restart = xen_restart;
 
 	return 0;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:47:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16: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 1XmQDH-0002ZK-Cb; Thu, 06 Nov 2014 16:47:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@roeck-us.net>) id 1XmQDF-0002Z9-MA
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:47:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D9/F4-24532-D06AB545; Thu, 06 Nov 2014 16:47:09 +0000
X-Env-Sender: linux@roeck-us.net
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415292426!11969455!1
X-Originating-IP: [208.91.199.152]
X-SpamReason: No, hits=2.2 required=7.0 tests=SUSPICIOUS_RECIPS,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14863 invoked from network); 6 Nov 2014 16:47:07 -0000
Received: from bh-25.webhostbox.net (HELO bh-25.webhostbox.net)
	(208.91.199.152)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 16:47:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roeck-us.net;
	s=default; 
	h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=Y8zSis+gE1RiJQjDus4cYg4FYnofJ8mi5dLts6zg3hc=; 
	b=OU7t8c2a2Km81hmAtlBGNoeqxPSrQ5GdvdzyWAjCU/l7TarGwTzQ1Fz5pYI330sobBd7nqpQG8JLlk5qrweqt0A5V9gYFgJGtAUauTQlRMGifss2NSddBzPvvszmqmov2aE5Ih8ZKsBpfVEtSz6SOMY7T+I10vnHQl/x7U9/92g=;
Received: from mailnull by bh-25.webhostbox.net with sa-checked (Exim 4.82)
	(envelope-from <linux@roeck-us.net>) id 1XmQDB-000YHh-Pk
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 16:47:05 +0000
Received: from 108-223-40-66.lightspeed.sntcca.sbcglobal.net
	([108.223.40.66]:35333 helo=localhost)
	by bh-25.webhostbox.net with esmtpa (Exim 4.82)
	(envelope-from <linux@roeck-us.net>)
	id 1XmQBD-000Uxd-LV; Thu, 06 Nov 2014 16:45:05 +0000
From: Guenter Roeck <linux@roeck-us.net>
To: linux-kernel@vger.kernel.org
Date: Thu,  6 Nov 2014 08:43:19 -0800
Message-Id: <1415292213-28652-36-git-send-email-linux@roeck-us.net>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415292213-28652-1-git-send-email-linux@roeck-us.net>
References: <1415292213-28652-1-git-send-email-linux@roeck-us.net>
X-Authenticated_sender: guenter@roeck-us.net
X-OutGoing-Spam-Status: No, score=1.5
X-Spam-Checker-Version: spamc_ctasd client on
	localost
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=50.0 tests=SpamClass_Unknown,
	VirusClass_Unknown autolearn=disabled version=1.0.0
X-CTCH-PVer: 0000001
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-Flags: 0
X-CTCH-RefID: str=0001.0A020203.545BA609.02E8, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-Score: 0.000
X-CTCH-ScoreCust: 0.000
X-CTCH-Rules: 
X-CTCH-SenderID: linux@roeck-us.net
X-CTCH-SenderID-Flags: 0
X-CTCH-SenderID-TotalMessages: 310
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-TotalRecipients: 0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - lists.xenproject.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from
	get_relayhosts_entry
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: linux-samsung-soc@vger.kernel.org, Russell King <linux@arm.linux.org.uk>,
	linux-pm@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com,
	Guenter Roeck <linux@roeck-us.net>,
	xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 35/48] arm: Register with kernel power-off
	handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Register with kernel power-off handler instead of setting pm_power_off
directly. Always use register_power_off_handler_simple as there is no
indication that more than one power-off handler is registered.

If the power-off handler only resets the system or puts the CPU in sleep mode,
select the fallback priority to indicate that the power-off handler is one
of last resort. If the power-off handler powers off the system, select the
default priority.

Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v5:
- Rebase to v3.18-rc3
v4:
- No change
v3:
- Replace poweroff in all newly introduced variables and in text
  with power_off or power-off as appropriate
- Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
v2:
- Use defines to specify poweroff handler priorities
- Drop changes in arch/arm/mach-at91/setup.c (file removed upstream)

 arch/arm/kernel/psci.c                         | 3 ++-
 arch/arm/mach-at91/board-gsia18s.c             | 3 ++-
 arch/arm/mach-bcm/board_bcm2835.c              | 3 ++-
 arch/arm/mach-cns3xxx/cns3420vb.c              | 3 ++-
 arch/arm/mach-cns3xxx/core.c                   | 3 ++-
 arch/arm/mach-highbank/highbank.c              | 3 ++-
 arch/arm/mach-imx/mach-mx31moboard.c           | 3 ++-
 arch/arm/mach-iop32x/em7210.c                  | 3 ++-
 arch/arm/mach-iop32x/glantank.c                | 3 ++-
 arch/arm/mach-iop32x/iq31244.c                 | 3 ++-
 arch/arm/mach-iop32x/n2100.c                   | 3 ++-
 arch/arm/mach-ixp4xx/dsmg600-setup.c           | 3 ++-
 arch/arm/mach-ixp4xx/nas100d-setup.c           | 3 ++-
 arch/arm/mach-ixp4xx/nslu2-setup.c             | 3 ++-
 arch/arm/mach-omap2/board-omap3touchbook.c     | 3 ++-
 arch/arm/mach-orion5x/board-mss2.c             | 3 ++-
 arch/arm/mach-orion5x/dns323-setup.c           | 9 ++++++---
 arch/arm/mach-orion5x/kurobox_pro-setup.c      | 3 ++-
 arch/arm/mach-orion5x/ls-chl-setup.c           | 3 ++-
 arch/arm/mach-orion5x/ls_hgl-setup.c           | 3 ++-
 arch/arm/mach-orion5x/lsmini-setup.c           | 3 ++-
 arch/arm/mach-orion5x/mv2120-setup.c           | 3 ++-
 arch/arm/mach-orion5x/net2big-setup.c          | 3 ++-
 arch/arm/mach-orion5x/terastation_pro2-setup.c | 3 ++-
 arch/arm/mach-orion5x/ts209-setup.c            | 3 ++-
 arch/arm/mach-orion5x/ts409-setup.c            | 3 ++-
 arch/arm/mach-pxa/corgi.c                      | 3 ++-
 arch/arm/mach-pxa/mioa701.c                    | 3 ++-
 arch/arm/mach-pxa/poodle.c                     | 3 ++-
 arch/arm/mach-pxa/spitz.c                      | 3 ++-
 arch/arm/mach-pxa/tosa.c                       | 3 ++-
 arch/arm/mach-pxa/viper.c                      | 3 ++-
 arch/arm/mach-pxa/z2.c                         | 7 ++++---
 arch/arm/mach-pxa/zeus.c                       | 7 ++++---
 arch/arm/mach-s3c24xx/mach-gta02.c             | 3 ++-
 arch/arm/mach-s3c24xx/mach-jive.c              | 3 ++-
 arch/arm/mach-s3c24xx/mach-vr1000.c            | 3 ++-
 arch/arm/mach-s3c64xx/mach-smartq.c            | 3 ++-
 arch/arm/mach-sa1100/generic.c                 | 3 ++-
 arch/arm/mach-sa1100/simpad.c                  | 3 ++-
 arch/arm/mach-u300/regulator.c                 | 3 ++-
 arch/arm/mach-vt8500/vt8500.c                  | 3 ++-
 arch/arm/xen/enlighten.c                       | 3 ++-
 43 files changed, 94 insertions(+), 49 deletions(-)

diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index f73891b..a7a2b4a 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -264,7 +264,8 @@ static int psci_0_2_init(struct device_node *np)
 
 	arm_pm_restart = psci_sys_reset;
 
-	pm_power_off = psci_sys_poweroff;
+	register_power_off_handler_simple(psci_sys_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 out_put_node:
 	of_node_put(np);
diff --git a/arch/arm/mach-at91/board-gsia18s.c b/arch/arm/mach-at91/board-gsia18s.c
index bf5cc55..e628c4a 100644
--- a/arch/arm/mach-at91/board-gsia18s.c
+++ b/arch/arm/mach-at91/board-gsia18s.c
@@ -521,7 +521,8 @@ static void gsia18s_power_off(void)
 
 static int __init gsia18s_power_off_init(void)
 {
-	pm_power_off = gsia18s_power_off;
+	register_power_off_handler_simple(gsia18s_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 	return 0;
 }
 
diff --git a/arch/arm/mach-bcm/board_bcm2835.c b/arch/arm/mach-bcm/board_bcm2835.c
index 70f2f39..1d75c76 100644
--- a/arch/arm/mach-bcm/board_bcm2835.c
+++ b/arch/arm/mach-bcm/board_bcm2835.c
@@ -111,7 +111,8 @@ static void __init bcm2835_init(void)
 
 	bcm2835_setup_restart();
 	if (wdt_regs)
-		pm_power_off = bcm2835_power_off;
+		register_power_off_handler_simple(bcm2835_power_off,
+						  POWER_OFF_PRIORITY_FALLBACK);
 
 	bcm2835_init_clocks();
 
diff --git a/arch/arm/mach-cns3xxx/cns3420vb.c b/arch/arm/mach-cns3xxx/cns3420vb.c
index 6428bcc7..5c50461 100644
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -224,7 +224,8 @@ static void __init cns3420_init(void)
 	cns3xxx_ahci_init();
 	cns3xxx_sdhci_init();
 
-	pm_power_off = cns3xxx_power_off;
+	register_power_off_handler_simple(cns3xxx_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 static struct map_desc cns3420_io_desc[] __initdata = {
diff --git a/arch/arm/mach-cns3xxx/core.c b/arch/arm/mach-cns3xxx/core.c
index 4e9837d..9c214cf 100644
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -386,7 +386,8 @@ static void __init cns3xxx_init(void)
 		cns3xxx_pwr_soft_rst(CNS3XXX_PWR_SOFTWARE_RST(SDIO));
 	}
 
-	pm_power_off = cns3xxx_power_off;
+	register_power_off_handler_simple(cns3xxx_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	of_platform_populate(NULL, of_default_bus_match_table,
                         cns3xxx_auxdata, NULL);
diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index 07a0957..6fbdc01 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -155,7 +155,8 @@ static void __init highbank_init(void)
 	sregs_base = of_iomap(np, 0);
 	WARN_ON(!sregs_base);
 
-	pm_power_off = highbank_power_off;
+	register_power_off_handler_simple(highbank_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	highbank_pm_init();
 
 	bus_register_notifier(&platform_bus_type, &highbank_platform_nb);
diff --git a/arch/arm/mach-imx/mach-mx31moboard.c b/arch/arm/mach-imx/mach-mx31moboard.c
index bb6f8a5..3001b14 100644
--- a/arch/arm/mach-imx/mach-mx31moboard.c
+++ b/arch/arm/mach-imx/mach-mx31moboard.c
@@ -559,7 +559,8 @@ static void __init mx31moboard_init(void)
 
 	imx_add_platform_device("imx_mc13783", 0, NULL, 0, NULL, 0);
 
-	pm_power_off = mx31moboard_poweroff;
+	register_power_off_handler_simple(mx31moboard_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	switch (mx31moboard_baseboard) {
 	case MX31NOBOARD:
diff --git a/arch/arm/mach-iop32x/em7210.c b/arch/arm/mach-iop32x/em7210.c
index 77e1ff0..fd3ad09 100644
--- a/arch/arm/mach-iop32x/em7210.c
+++ b/arch/arm/mach-iop32x/em7210.c
@@ -201,7 +201,8 @@ static int __init em7210_request_gpios(void)
 		return 0;
 	}
 
-	pm_power_off = em7210_power_off;
+	register_power_off_handler_simple(em7210_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return 0;
 }
diff --git a/arch/arm/mach-iop32x/glantank.c b/arch/arm/mach-iop32x/glantank.c
index 547b234..9298ea0 100644
--- a/arch/arm/mach-iop32x/glantank.c
+++ b/arch/arm/mach-iop32x/glantank.c
@@ -199,7 +199,8 @@ static void __init glantank_init_machine(void)
 	i2c_register_board_info(0, glantank_i2c_devices,
 		ARRAY_SIZE(glantank_i2c_devices));
 
-	pm_power_off = glantank_power_off;
+	register_power_off_handler_simple(glantank_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(GLANTANK, "GLAN Tank")
diff --git a/arch/arm/mach-iop32x/iq31244.c b/arch/arm/mach-iop32x/iq31244.c
index 0e1392b..50ba54b 100644
--- a/arch/arm/mach-iop32x/iq31244.c
+++ b/arch/arm/mach-iop32x/iq31244.c
@@ -293,7 +293,8 @@ static void __init iq31244_init_machine(void)
 	platform_device_register(&iop3xx_dma_1_channel);
 
 	if (is_ep80219())
-		pm_power_off = ep80219_power_off;
+		register_power_off_handler_simple(ep80219_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (!is_80219())
 		platform_device_register(&iop3xx_aau_channel);
diff --git a/arch/arm/mach-iop32x/n2100.c b/arch/arm/mach-iop32x/n2100.c
index c1cd80e..734a092 100644
--- a/arch/arm/mach-iop32x/n2100.c
+++ b/arch/arm/mach-iop32x/n2100.c
@@ -356,7 +356,8 @@ static void __init n2100_init_machine(void)
 	i2c_register_board_info(0, n2100_i2c_devices,
 		ARRAY_SIZE(n2100_i2c_devices));
 
-	pm_power_off = n2100_power_off;
+	register_power_off_handler_simple(n2100_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(N2100, "Thecus N2100")
diff --git a/arch/arm/mach-ixp4xx/dsmg600-setup.c b/arch/arm/mach-ixp4xx/dsmg600-setup.c
index 43ee06d..f34564d 100644
--- a/arch/arm/mach-ixp4xx/dsmg600-setup.c
+++ b/arch/arm/mach-ixp4xx/dsmg600-setup.c
@@ -281,7 +281,8 @@ static void __init dsmg600_init(void)
 
 	platform_add_devices(dsmg600_devices, ARRAY_SIZE(dsmg600_devices));
 
-	pm_power_off = dsmg600_power_off;
+	register_power_off_handler_simple(dsmg600_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(DSMG600, "D-Link DSM-G600 RevA")
diff --git a/arch/arm/mach-ixp4xx/nas100d-setup.c b/arch/arm/mach-ixp4xx/nas100d-setup.c
index 4e0f762..43a9333 100644
--- a/arch/arm/mach-ixp4xx/nas100d-setup.c
+++ b/arch/arm/mach-ixp4xx/nas100d-setup.c
@@ -292,7 +292,8 @@ static void __init nas100d_init(void)
 
 	platform_add_devices(nas100d_devices, ARRAY_SIZE(nas100d_devices));
 
-	pm_power_off = nas100d_power_off;
+	register_power_off_handler_simple(nas100d_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (request_irq(gpio_to_irq(NAS100D_RB_GPIO), &nas100d_reset_handler,
 		IRQF_TRIGGER_LOW, "NAS100D reset button", NULL) < 0) {
diff --git a/arch/arm/mach-ixp4xx/nslu2-setup.c b/arch/arm/mach-ixp4xx/nslu2-setup.c
index 88c025f..e094d5f 100644
--- a/arch/arm/mach-ixp4xx/nslu2-setup.c
+++ b/arch/arm/mach-ixp4xx/nslu2-setup.c
@@ -262,7 +262,8 @@ static void __init nslu2_init(void)
 
 	platform_add_devices(nslu2_devices, ARRAY_SIZE(nslu2_devices));
 
-	pm_power_off = nslu2_power_off;
+	register_power_off_handler_simple(nslu2_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (request_irq(gpio_to_irq(NSLU2_RB_GPIO), &nslu2_reset_handler,
 		IRQF_TRIGGER_LOW, "NSLU2 reset button", NULL) < 0) {
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
index a01993e..8abce2c 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -344,7 +344,8 @@ static void __init omap3_touchbook_init(void)
 {
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 
-	pm_power_off = omap3_touchbook_poweroff;
+	register_power_off_handler_simple(omap3_touchbook_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (system_rev >= 0x20 && system_rev <= 0x34301000) {
 		omap_mux_init_gpio(23, OMAP_PIN_INPUT);
diff --git a/arch/arm/mach-orion5x/board-mss2.c b/arch/arm/mach-orion5x/board-mss2.c
index 66f9c3b..cac2793 100644
--- a/arch/arm/mach-orion5x/board-mss2.c
+++ b/arch/arm/mach-orion5x/board-mss2.c
@@ -86,5 +86,6 @@ static void mss2_power_off(void)
 void __init mss2_init(void)
 {
 	/* register mss2 specific power-off method */
-	pm_power_off = mss2_power_off;
+	register_power_off_handler_simple(mss2_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 }
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index 09d2a26..9876509 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -669,7 +669,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323a_power_off;
+		register_power_off_handler_simple(dns323a_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 		break;
 	case DNS323_REV_B1:
 		/* 5182 built-in SATA init */
@@ -686,7 +687,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323b_power_off;
+		register_power_off_handler_simple(dns323b_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 		break;
 	case DNS323_REV_C1:
 		/* 5182 built-in SATA init */
@@ -696,7 +698,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323C_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323C_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323c_power_off;
+		register_power_off_handler_simple(dns323c_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 
 		/* Now, -this- should theorically be done by the sata_mv driver
 		 * once I figure out what's going on there. Maybe the behaviour
diff --git a/arch/arm/mach-orion5x/kurobox_pro-setup.c b/arch/arm/mach-orion5x/kurobox_pro-setup.c
index fe6a48a..872d4fe 100644
--- a/arch/arm/mach-orion5x/kurobox_pro-setup.c
+++ b/arch/arm/mach-orion5x/kurobox_pro-setup.c
@@ -376,7 +376,8 @@ static void __init kurobox_pro_init(void)
 	i2c_register_board_info(0, &kurobox_pro_i2c_rtc, 1);
 
 	/* register Kurobox Pro specific power-off method */
-	pm_power_off = kurobox_pro_power_off;
+	register_power_off_handler_simple(kurobox_pro_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 #ifdef CONFIG_MACH_KUROBOX_PRO
diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
index 028ea03..3f540d1 100644
--- a/arch/arm/mach-orion5x/ls-chl-setup.c
+++ b/arch/arm/mach-orion5x/ls-chl-setup.c
@@ -312,7 +312,8 @@ static void __init lschl_init(void)
 	gpio_set_value(LSCHL_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = lschl_power_off;
+	register_power_off_handler_simple(lschl_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c b/arch/arm/mach-orion5x/ls_hgl-setup.c
index 32b7129..699a5a1 100644
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion5x/ls_hgl-setup.c
@@ -259,7 +259,8 @@ static void __init ls_hgl_init(void)
 	gpio_set_value(LS_HGL_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = ls_hgl_power_off;
+	register_power_off_handler_simple(ls_hgl_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/lsmini-setup.c b/arch/arm/mach-orion5x/lsmini-setup.c
index a6493e7..c5712ff 100644
--- a/arch/arm/mach-orion5x/lsmini-setup.c
+++ b/arch/arm/mach-orion5x/lsmini-setup.c
@@ -260,7 +260,8 @@ static void __init lsmini_init(void)
 	gpio_set_value(LSMINI_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = lsmini_power_off;
+	register_power_off_handler_simple(lsmini_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c b/arch/arm/mach-orion5x/mv2120-setup.c
index e032f01..13efbec 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -225,7 +225,8 @@ static void __init mv2120_init(void)
 	if (gpio_request(MV2120_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 	    gpio_direction_output(MV2120_GPIO_POWER_OFF, 1) != 0)
 		pr_err("mv2120: failed to setup power-off GPIO\n");
-	pm_power_off = mv2120_power_off;
+	register_power_off_handler_simple(mv2120_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 /* Warning: HP uses a wrong mach-type (=526) in their bootloader */
diff --git a/arch/arm/mach-orion5x/net2big-setup.c b/arch/arm/mach-orion5x/net2big-setup.c
index ba73dc7..c7648f0 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -413,7 +413,8 @@ static void __init net2big_init(void)
 
 	if (gpio_request(NET2BIG_GPIO_POWER_OFF, "power-off") == 0 &&
 	    gpio_direction_output(NET2BIG_GPIO_POWER_OFF, 0) == 0)
-		pm_power_off = net2big_power_off;
+		register_power_off_handler_simple(net2big_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 	else
 		pr_err("net2big: failed to configure power-off GPIO\n");
 
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c b/arch/arm/mach-orion5x/terastation_pro2-setup.c
index 1208674..227ae91 100644
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
@@ -353,7 +353,8 @@ static void __init tsp2_init(void)
 	i2c_register_board_info(0, &tsp2_i2c_rtc, 1);
 
 	/* register Terastation Pro II specific power-off method */
-	pm_power_off = tsp2_power_off;
+	register_power_off_handler_simple(tsp2_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TERASTATION_PRO2, "Buffalo Terastation Pro II/Live")
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index c725b7c..540e3f3 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -318,7 +318,8 @@ static void __init qnap_ts209_init(void)
 	i2c_register_board_info(0, &qnap_ts209_i2c_rtc, 1);
 
 	/* register tsx09 specific power-off method */
-	pm_power_off = qnap_tsx09_power_off;
+	register_power_off_handler_simple(qnap_tsx09_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TS209, "QNAP TS-109/TS-209")
diff --git a/arch/arm/mach-orion5x/ts409-setup.c b/arch/arm/mach-orion5x/ts409-setup.c
index cf2ab53..40cbdd7 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -307,7 +307,8 @@ static void __init qnap_ts409_init(void)
 	platform_device_register(&ts409_leds);
 
 	/* register tsx09 specific power-off method */
-	pm_power_off = qnap_tsx09_power_off;
+	register_power_off_handler_simple(qnap_tsx09_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TS409, "QNAP TS-409")
diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index 06022b2..93b73a1 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -718,7 +718,8 @@ static void corgi_restart(enum reboot_mode mode, const char *cmd)
 
 static void __init corgi_init(void)
 {
-	pm_power_off = corgi_poweroff;
+	register_power_off_handler_simple(corgi_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	/* Stop 3.6MHz and drive HIGH to PCMCIA and CS */
 	PCFR |= PCFR_OPDE;
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 29997bd..5d318d4 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -750,7 +750,8 @@ static void __init mioa701_machine_init(void)
 	pxa_set_keypad_info(&mioa701_keypad_info);
 	pxa_set_udc_info(&mioa701_udc_info);
 	pxa_set_ac97_info(&mioa701_ac97_info);
-	pm_power_off = mioa701_poweroff;
+	register_power_off_handler_simple(mioa701_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	platform_add_devices(devices, ARRAY_SIZE(devices));
 	gsm_init();
 
diff --git a/arch/arm/mach-pxa/poodle.c b/arch/arm/mach-pxa/poodle.c
index 1319916..749d2af 100644
--- a/arch/arm/mach-pxa/poodle.c
+++ b/arch/arm/mach-pxa/poodle.c
@@ -432,7 +432,8 @@ static void __init poodle_init(void)
 {
 	int ret = 0;
 
-	pm_power_off = poodle_poweroff;
+	register_power_off_handler_simple(poodle_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PCFR |= PCFR_OPDE;
 
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 840c3a4..ab25b6c 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -944,7 +944,8 @@ static void spitz_restart(enum reboot_mode mode, const char *cmd)
 static void __init spitz_init(void)
 {
 	init_gpio_reset(SPITZ_GPIO_ON_RESET, 1, 0);
-	pm_power_off = spitz_poweroff;
+	register_power_off_handler_simple(spitz_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PMCR = 0x00;
 
diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
index c158a6e..8823448 100644
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -940,7 +940,8 @@ static void __init tosa_init(void)
 
 	init_gpio_reset(TOSA_GPIO_ON_RESET, 0, 0);
 
-	pm_power_off = tosa_poweroff;
+	register_power_off_handler_simple(tosa_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PCFR |= PCFR_OPDE;
 
diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index de3b080..6bb4de3 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -919,7 +919,8 @@ static void __init viper_init(void)
 {
 	u8 version;
 
-	pm_power_off = viper_power_off;
+	register_power_off_handler_simple(viper_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	pxa2xx_mfp_config(ARRAY_AND_SIZE(viper_pin_config));
 
diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
index e1a121b..0d0a6ae 100644
--- a/arch/arm/mach-pxa/z2.c
+++ b/arch/arm/mach-pxa/z2.c
@@ -693,8 +693,6 @@ static void z2_power_off(void)
 	pxa27x_set_pwrmode(PWRMODE_DEEPSLEEP);
 	pxa27x_cpu_pm_enter(PM_SUSPEND_MEM);
 }
-#else
-#define z2_power_off   NULL
 #endif
 
 /******************************************************************************
@@ -719,7 +717,10 @@ static void __init z2_init(void)
 	z2_keys_init();
 	z2_pmic_init();
 
-	pm_power_off = z2_power_off;
+#ifdef CONFIG_PM
+	register_power_off_handler_simple(z2_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
+#endif
 }
 
 MACHINE_START(ZIPIT2, "Zipit Z2")
diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index 205f9bf..457eed1 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -690,8 +690,6 @@ static void zeus_power_off(void)
 	local_irq_disable();
 	cpu_suspend(PWRMODE_DEEPSLEEP, pxa27x_finish_suspend);
 }
-#else
-#define zeus_power_off   NULL
 #endif
 
 #ifdef CONFIG_APM_EMULATION
@@ -847,7 +845,10 @@ static void __init zeus_init(void)
 	__raw_writel(msc0, MSC0);
 	__raw_writel(msc1, MSC1);
 
-	pm_power_off = zeus_power_off;
+#ifdef CONFIG_PM
+	register_power_off_handler_simple(zeus_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
+#endif
 	zeus_setup_apm();
 
 	pxa2xx_mfp_config(ARRAY_AND_SIZE(zeus_pin_config));
diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-s3c24xx/mach-gta02.c
index 6d1e0b9..8366b3e 100644
--- a/arch/arm/mach-s3c24xx/mach-gta02.c
+++ b/arch/arm/mach-s3c24xx/mach-gta02.c
@@ -579,7 +579,8 @@ static void __init gta02_machine_init(void)
 	i2c_register_board_info(0, gta02_i2c_devs, ARRAY_SIZE(gta02_i2c_devs));
 
 	platform_add_devices(gta02_devices, ARRAY_SIZE(gta02_devices));
-	pm_power_off = gta02_poweroff;
+	register_power_off_handler_simple(gta02_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	regulator_has_full_constraints();
 }
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c
index 7d99fe8..20beb39 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -657,7 +657,8 @@ static void __init jive_machine_init(void)
 	s3c_i2c0_set_platdata(&jive_i2c_cfg);
 	i2c_register_board_info(0, jive_i2c_devs, ARRAY_SIZE(jive_i2c_devs));
 
-	pm_power_off = jive_power_off;
+	register_power_off_handler_simple(jive_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	platform_add_devices(jive_devices, ARRAY_SIZE(jive_devices));
 }
diff --git a/arch/arm/mach-s3c24xx/mach-vr1000.c b/arch/arm/mach-s3c24xx/mach-vr1000.c
index 89f32bd..1f32ba7 100644
--- a/arch/arm/mach-s3c24xx/mach-vr1000.c
+++ b/arch/arm/mach-s3c24xx/mach-vr1000.c
@@ -306,7 +306,8 @@ static void vr1000_power_off(void)
 
 static void __init vr1000_map_io(void)
 {
-	pm_power_off = vr1000_power_off;
+	register_power_off_handler_simple(vr1000_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	s3c24xx_init_io(vr1000_iodesc, ARRAY_SIZE(vr1000_iodesc));
 	s3c24xx_init_uarts(vr1000_uartcfgs, ARRAY_SIZE(vr1000_uartcfgs));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c b/arch/arm/mach-s3c64xx/mach-smartq.c
index b3d1353..b30906f 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -291,7 +291,8 @@ static int __init smartq_power_off_init(void)
 	/* leave power on */
 	gpio_direction_output(S3C64XX_GPK(15), 0);
 
-	pm_power_off = smartq_power_off;
+	register_power_off_handler_simple(smartq_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return ret;
 }
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index d4ea142..371bffe 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -311,7 +311,8 @@ static struct platform_device *sa11x0_devices[] __initdata = {
 
 static int __init sa1100_init(void)
 {
-	pm_power_off = sa1100_power_off;
+	register_power_off_handler_simple(sa1100_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	return platform_add_devices(sa11x0_devices, ARRAY_SIZE(sa11x0_devices));
 }
 
diff --git a/arch/arm/mach-sa1100/simpad.c b/arch/arm/mach-sa1100/simpad.c
index 41e476e..fb85730 100644
--- a/arch/arm/mach-sa1100/simpad.c
+++ b/arch/arm/mach-sa1100/simpad.c
@@ -373,7 +373,8 @@ static int __init simpad_init(void)
 	if (ret)
 		printk(KERN_WARNING "simpad: Unable to register cs3 GPIO device");
 
-	pm_power_off = simpad_power_off;
+	register_power_off_handler_simple(simpad_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	sa11x0_ppc_configure_mcp();
 	sa11x0_register_mtd(&simpad_flash_data, simpad_flash_resources,
diff --git a/arch/arm/mach-u300/regulator.c b/arch/arm/mach-u300/regulator.c
index 0493a84..4ff09b0 100644
--- a/arch/arm/mach-u300/regulator.c
+++ b/arch/arm/mach-u300/regulator.c
@@ -98,7 +98,8 @@ static int __init __u300_init_boardpower(struct platform_device *pdev)
 			   U300_SYSCON_PMCR_DCON_ENABLE, 0);
 
 	/* Register globally exported PM poweroff hook */
-	pm_power_off = u300_pm_poweroff;
+	register_power_off_handler_simple(u300_pm_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return 0;
 }
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 3bc0dc9..48e4fbf 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -155,7 +155,8 @@ static void __init vt8500_init(void)
 			pr_err("%s:ioremap(power_off) failed\n", __func__);
 	}
 	if (pmc_base)
-		pm_power_off = &vt8500_power_off;
+		register_power_off_handler_simple(vt8500_power_off,
+						  POWER_OFF_PRIORITY_FALLBACK);
 	else
 		pr_err("%s: PMC Hibernation register could not be remapped, not enabling power off!\n", __func__);
 
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e15f01..1c8bce0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -336,7 +336,8 @@ static int __init xen_pm_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	pm_power_off = xen_power_off;
+	register_power_off_handler_simple(xen_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 	arm_pm_restart = xen_restart;
 
 	return 0;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:56:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:56:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmQMM-0002zu-KG; Thu, 06 Nov 2014 16:56:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmQML-0002zp-CW
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:56:33 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6F/85-24532-048AB545; Thu, 06 Nov 2014 16:56:32 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415292991!11981210!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28778 invoked from network); 6 Nov 2014 16:56:31 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-21.messagelabs.com with SMTP;
	6 Nov 2014 16:56:31 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 06 Nov 2014 08:56:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,327,1413270000"; d="scan'208";a="618318803"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 06 Nov 2014 08:56:26 -0800
Received: from pgsmsx107.gar.corp.intel.com (10.221.44.105) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 7 Nov 2014 00:55:51 +0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 7 Nov 2014 00:55:50 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id
	14.03.0195.001; Fri, 7 Nov 2014 00:55:49 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Thread-Topic: FW: [PATCH 1/6]  vTPM: event channel bind interdomain with
	para/hvm virtual machine
Thread-Index: AQHP9DbGM7cWOHWQDECdt6BGyNN1jZxIva0Q//+yl4CAC19FUA==
Date: Thu, 6 Nov 2014 16:55:49 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820D74@SHSMSX101.ccr.corp.intel.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<1414654731-32641-2-git-send-email-quan.xu@intel.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81D119@SHSMSX101.ccr.corp.intel.com>
	<54528379.5080107@tycho.nsa.gov>
In-Reply-To: <54528379.5080107@tycho.nsa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>, "Xu,
	Quan" <quan.xu@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] FW: [PATCH 1/6] vTPM: event channel bind
 interdomain with para/hvm virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> Sent: Friday, October 31, 2014 2:29 AM
> To: Xu, Quan
> Cc: samuel.thibault@ens-lyon.org
> Subject: Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> para/hvm virtual machine
> 
> On 10/30/2014 11:06 AM, Xu, Quan wrote:
> [...]
> >> +   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
> 
> This seems to preclude the use of stub domain device models for HVM
> domains; in that case, the event channel/grant page would need to be
> mapped to the stub domain.  I think it may be better to pass in the target
> domain ID in xenstore rather than overriding it based on PV vs HVM.  In any
> case, in order to support HVM domains with PV drivers, an additional
> backend/frontend pair is required for QEMU rather than redirecting the
> existing vTPM to the device model's domain.
> 

Thanks Graaf.
HVM domains are still runing tpm_tis.ko driver or Windows TPM 1.2 driver,
as they run on physical machine.
When I tried to enable vTPM for HVM domains, I pass in the target domain ID
in XenStore too, but it is not working. because the vTPM frontend is implemented in QEMU.

For HVM domains, QEMU is running in Dom0 as usual. So the domid shoud be 0.
some requirement from local ISV, they need vTPM for unmodified domain in
virtual desktop infrastructure.

> I would suggest attaching the vTPM directly to domain 0, but that would
> cause the vTPM to be picked up by the dom0 kernel instead of by QEMU, so
> that is not helpful.  If there is an existing solution for disk or network driver
> domains attached to HVM, the solution used there should be mirrored here;
> I have not looked to see how (or if) it is solved in those drivers.
> 
In this patch series, It is a solution for HVM domains. 
I am very pleased if we can collaborate to enhance / modify it in coming Xen version(4.7 or ..) 

> A solution needs to be able to handle:
> 
> 1. Existing PV domains

Yes, it is compatible with pv domains or non-vtpm domains. 

> 2. HVM domain using TIS MMIO and no stubdom - without special casing
> dom0 3. HVM domain using TIS MMIO via a stubdom 

Now the TIS MMIO is registered in Qemu. 


>4. Linux HVM domain
> with the PV vTPM driver (talks directly to the vTPM)

I did not have available physical machine. It is still building the domu 
kernel with PV vTPM driver.
I guess, there may be /dev/tpm0 and /dev/tpm1
I will share the test result tomorrow 

> 
> Similar to network and disk, when an OS that understands Xen devices finds
> a vTPM interface, it should detach/ignore the MMIO TPM interface.
> The vTPM domain is set up to handle this case: multiple connections to a
> single vTPM domain are permitted and will all talk to the same TPM instance.

Yes, pv domains and hvm domains can talk to the same TPM instance.
 
> Locality restrictions are based on the event channel endpoint, and so will still
> work even when tpmif->domid is incorrect; this is required to properly
> implement the DRTM if it is to be emulated.


Graaf, I will read your suggestion again and again. I have not read your new feature in 
Docs/misc/vtpm-platforms.txt.
I am still committing some other features, And dealing with some review comments. 
BTW, could you share some document about disk_io in stubdom/vtpmmgr. 
I enabled vtpmmgr on TPM 2.0 based on Xen 4.3.0. try to get rooted trust on TPM 2.0 .
it is not working now, as you changed disk io. 



> 
> --
> Daniel De Graaf
> National Security Agency


Thanks 
Quan Xu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 16:56:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 16:56:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmQMM-0002zu-KG; Thu, 06 Nov 2014 16:56:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmQML-0002zp-CW
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 16:56:33 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6F/85-24532-048AB545; Thu, 06 Nov 2014 16:56:32 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415292991!11981210!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28778 invoked from network); 6 Nov 2014 16:56:31 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-21.messagelabs.com with SMTP;
	6 Nov 2014 16:56:31 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 06 Nov 2014 08:56:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,327,1413270000"; d="scan'208";a="618318803"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 06 Nov 2014 08:56:26 -0800
Received: from pgsmsx107.gar.corp.intel.com (10.221.44.105) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 7 Nov 2014 00:55:51 +0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 7 Nov 2014 00:55:50 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id
	14.03.0195.001; Fri, 7 Nov 2014 00:55:49 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Thread-Topic: FW: [PATCH 1/6]  vTPM: event channel bind interdomain with
	para/hvm virtual machine
Thread-Index: AQHP9DbGM7cWOHWQDECdt6BGyNN1jZxIva0Q//+yl4CAC19FUA==
Date: Thu, 6 Nov 2014 16:55:49 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820D74@SHSMSX101.ccr.corp.intel.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<1414654731-32641-2-git-send-email-quan.xu@intel.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81D119@SHSMSX101.ccr.corp.intel.com>
	<54528379.5080107@tycho.nsa.gov>
In-Reply-To: <54528379.5080107@tycho.nsa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>, "Xu,
	Quan" <quan.xu@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] FW: [PATCH 1/6] vTPM: event channel bind
 interdomain with para/hvm virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> Sent: Friday, October 31, 2014 2:29 AM
> To: Xu, Quan
> Cc: samuel.thibault@ens-lyon.org
> Subject: Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> para/hvm virtual machine
> 
> On 10/30/2014 11:06 AM, Xu, Quan wrote:
> [...]
> >> +   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
> 
> This seems to preclude the use of stub domain device models for HVM
> domains; in that case, the event channel/grant page would need to be
> mapped to the stub domain.  I think it may be better to pass in the target
> domain ID in xenstore rather than overriding it based on PV vs HVM.  In any
> case, in order to support HVM domains with PV drivers, an additional
> backend/frontend pair is required for QEMU rather than redirecting the
> existing vTPM to the device model's domain.
> 

Thanks Graaf.
HVM domains are still runing tpm_tis.ko driver or Windows TPM 1.2 driver,
as they run on physical machine.
When I tried to enable vTPM for HVM domains, I pass in the target domain ID
in XenStore too, but it is not working. because the vTPM frontend is implemented in QEMU.

For HVM domains, QEMU is running in Dom0 as usual. So the domid shoud be 0.
some requirement from local ISV, they need vTPM for unmodified domain in
virtual desktop infrastructure.

> I would suggest attaching the vTPM directly to domain 0, but that would
> cause the vTPM to be picked up by the dom0 kernel instead of by QEMU, so
> that is not helpful.  If there is an existing solution for disk or network driver
> domains attached to HVM, the solution used there should be mirrored here;
> I have not looked to see how (or if) it is solved in those drivers.
> 
In this patch series, It is a solution for HVM domains. 
I am very pleased if we can collaborate to enhance / modify it in coming Xen version(4.7 or ..) 

> A solution needs to be able to handle:
> 
> 1. Existing PV domains

Yes, it is compatible with pv domains or non-vtpm domains. 

> 2. HVM domain using TIS MMIO and no stubdom - without special casing
> dom0 3. HVM domain using TIS MMIO via a stubdom 

Now the TIS MMIO is registered in Qemu. 


>4. Linux HVM domain
> with the PV vTPM driver (talks directly to the vTPM)

I did not have available physical machine. It is still building the domu 
kernel with PV vTPM driver.
I guess, there may be /dev/tpm0 and /dev/tpm1
I will share the test result tomorrow 

> 
> Similar to network and disk, when an OS that understands Xen devices finds
> a vTPM interface, it should detach/ignore the MMIO TPM interface.
> The vTPM domain is set up to handle this case: multiple connections to a
> single vTPM domain are permitted and will all talk to the same TPM instance.

Yes, pv domains and hvm domains can talk to the same TPM instance.
 
> Locality restrictions are based on the event channel endpoint, and so will still
> work even when tpmif->domid is incorrect; this is required to properly
> implement the DRTM if it is to be emulated.


Graaf, I will read your suggestion again and again. I have not read your new feature in 
Docs/misc/vtpm-platforms.txt.
I am still committing some other features, And dealing with some review comments. 
BTW, could you share some document about disk_io in stubdom/vtpmmgr. 
I enabled vtpmmgr on TPM 2.0 based on Xen 4.3.0. try to get rooted trust on TPM 2.0 .
it is not working now, as you changed disk io. 



> 
> --
> Daniel De Graaf
> National Security Agency


Thanks 
Quan Xu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 17:08:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 17:08:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmQXT-0003Lz-S4; Thu, 06 Nov 2014 17:08:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmQXS-0003Lu-UP
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 17:08:03 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B5/8B-02984-2FAAB545; Thu, 06 Nov 2014 17:08:02 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415293678!11883866!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22894 invoked from network); 6 Nov 2014 17:08:01 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 17:08:01 -0000
Received: from 172.24.2.119 (EHLO SZXEML455-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY96866; Fri, 07 Nov 2014 01:07:51 +0800 (CST)
Received: from localhost.localdomain (10.47.66.28) by
	SZXEML455-HUB.china.huawei.com (10.82.67.198) with Microsoft SMTP
	Server id 14.3.158.1; Fri, 7 Nov 2014 01:07:41 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 17:07:31 +0000
Message-ID: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-Originating-IP: [10.47.66.28]
X-CFilter-Loop: Reflected
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/arm: Return correct code error for
	xen_swiotlb_map_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 ARM error code is not 0 so avoid to return it as error.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 drivers/xen/swiotlb-xen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..3b8d628 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 	 */
 	if (!dma_capable(dev, dev_addr, size)) {
 		swiotlb_tbl_unmap_single(dev, map, size, dir);
-		dev_addr = 0;
+		dev_addr = DMA_ERROR_CODE;
 	}
 	return dev_addr;
 }
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 17:08:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 17:08:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmQXT-0003Lz-S4; Thu, 06 Nov 2014 17:08:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmQXS-0003Lu-UP
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 17:08:03 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B5/8B-02984-2FAAB545; Thu, 06 Nov 2014 17:08:02 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415293678!11883866!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22894 invoked from network); 6 Nov 2014 17:08:01 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 17:08:01 -0000
Received: from 172.24.2.119 (EHLO SZXEML455-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CBY96866; Fri, 07 Nov 2014 01:07:51 +0800 (CST)
Received: from localhost.localdomain (10.47.66.28) by
	SZXEML455-HUB.china.huawei.com (10.82.67.198) with Microsoft SMTP
	Server id 14.3.158.1; Fri, 7 Nov 2014 01:07:41 +0800
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, <frediano.ziglio@huawei.com>
Date: Thu, 6 Nov 2014 17:07:31 +0000
Message-ID: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-Originating-IP: [10.47.66.28]
X-CFilter-Loop: Reflected
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/arm: Return correct code error for
	xen_swiotlb_map_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 ARM error code is not 0 so avoid to return it as error.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
---
 drivers/xen/swiotlb-xen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..3b8d628 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 	 */
 	if (!dma_capable(dev, dev_addr, size)) {
 		swiotlb_tbl_unmap_single(dev, map, size, dir);
-		dev_addr = 0;
+		dev_addr = DMA_ERROR_CODE;
 	}
 	return dev_addr;
 }
-- 
1.9.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 17:16:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 17:16:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmQfh-0003fs-RT; Thu, 06 Nov 2014 17:16:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmQfg-0003fn-L5
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 17:16:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DB/76-09842-FECAB545; Thu, 06 Nov 2014 17:16:31 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415294190!12025720!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29669 invoked from network); 6 Nov 2014 17:16:31 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-21.messagelabs.com with SMTP;
	6 Nov 2014 17:16:31 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 06 Nov 2014 09:14:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,327,1413270000"; d="scan'208";a="632762374"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 06 Nov 2014 09:16:13 -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.3.195.1; Fri, 7 Nov 2014 01:16:12 +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.3.195.1; Fri, 7 Nov 2014 01:16:12 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.156]) with mapi id
	14.03.0195.001; Fri, 7 Nov 2014 01:16:11 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is initialized
	before tpm_init()
Thread-Index: AQHP92DOrv3uCTLgX0agQ9/cKaVBUJxT24AQ
Date: Thu, 6 Nov 2014 17:16:11 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820D99@SHSMSX101.ccr.corp.intel.com>
References: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
	<54577379.3060009@redhat.com>
In-Reply-To: <54577379.3060009@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "aliguori@amazon.com" <aliguori@amazon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is
 initialized before tpm_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



> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, November 03, 2014 8:22 PM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: aliguori@amazon.com; xen-devel@lists.xen.org
> Subject: Re: [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is initialized
> before tpm_init()
> 
> On 02/11/2014 07:39, Quan Xu wrote:
> > make sure QEMU machine class is initialized and QEMU has registered
> > Xen stubdom vTPM driver when call tpm_init() [vl.c]
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > ---
> >  vl.c | 16 ++++++++++------
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/vl.c b/vl.c
> > index f6b3546..dd437e1 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -4114,12 +4114,6 @@ int main(int argc, char **argv, char **envp)
> >          exit(1);
> >      }
> >
> > -#ifdef CONFIG_TPM
> > -    if (tpm_init() < 0) {
> > -        exit(1);
> > -    }
> > -#endif
> > -
> >      /* init the bluetooth world */
> >      if (foreach_device_config(DEV_BT, bt_parse))
> >          exit(1);
> > @@ -4225,6 +4219,16 @@ int main(int argc, char **argv, char **envp)
> >              exit(1);
> >      }
> >
> > +    /* For compatible with Xen stubdom vTPM driver, make
> > +     * sure QEMU machine class is initialized and QEMU has
> > +     * registered Xen stubdom vTPM driver ..
> > +    */
> > +#ifdef CONFIG_TPM
> > +    if (tpm_init() < 0) {
> > +        exit(1);
> > +    }
> > +#endif
> > +
> >      /* init generic devices */
> >      if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func,
> NULL, 1) != 0)
> >          exit(1);
> >
> 
> Assuming you tested the non-Xen TPM backend, this is okay.

Yes, I have tested Qemu TPM passthrough in KVM virtual machine. It is working ..

> 
> Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 17:16:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 17:16:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmQfh-0003fs-RT; Thu, 06 Nov 2014 17:16:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmQfg-0003fn-L5
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 17:16:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DB/76-09842-FECAB545; Thu, 06 Nov 2014 17:16:31 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415294190!12025720!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29669 invoked from network); 6 Nov 2014 17:16:31 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-21.messagelabs.com with SMTP;
	6 Nov 2014 17:16:31 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 06 Nov 2014 09:14:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,327,1413270000"; d="scan'208";a="632762374"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 06 Nov 2014 09:16:13 -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.3.195.1; Fri, 7 Nov 2014 01:16:12 +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.3.195.1; Fri, 7 Nov 2014 01:16:12 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.156]) with mapi id
	14.03.0195.001; Fri, 7 Nov 2014 01:16:11 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is initialized
	before tpm_init()
Thread-Index: AQHP92DOrv3uCTLgX0agQ9/cKaVBUJxT24AQ
Date: Thu, 6 Nov 2014 17:16:11 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820D99@SHSMSX101.ccr.corp.intel.com>
References: <1414910371-27794-1-git-send-email-quan.xu@intel.com>
	<54577379.3060009@redhat.com>
In-Reply-To: <54577379.3060009@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "aliguori@amazon.com" <aliguori@amazon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is
 initialized before tpm_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



> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, November 03, 2014 8:22 PM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: aliguori@amazon.com; xen-devel@lists.xen.org
> Subject: Re: [PATCH 4/4] Qemu-Xen-vTPM: QEMU machine class is initialized
> before tpm_init()
> 
> On 02/11/2014 07:39, Quan Xu wrote:
> > make sure QEMU machine class is initialized and QEMU has registered
> > Xen stubdom vTPM driver when call tpm_init() [vl.c]
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > ---
> >  vl.c | 16 ++++++++++------
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/vl.c b/vl.c
> > index f6b3546..dd437e1 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -4114,12 +4114,6 @@ int main(int argc, char **argv, char **envp)
> >          exit(1);
> >      }
> >
> > -#ifdef CONFIG_TPM
> > -    if (tpm_init() < 0) {
> > -        exit(1);
> > -    }
> > -#endif
> > -
> >      /* init the bluetooth world */
> >      if (foreach_device_config(DEV_BT, bt_parse))
> >          exit(1);
> > @@ -4225,6 +4219,16 @@ int main(int argc, char **argv, char **envp)
> >              exit(1);
> >      }
> >
> > +    /* For compatible with Xen stubdom vTPM driver, make
> > +     * sure QEMU machine class is initialized and QEMU has
> > +     * registered Xen stubdom vTPM driver ..
> > +    */
> > +#ifdef CONFIG_TPM
> > +    if (tpm_init() < 0) {
> > +        exit(1);
> > +    }
> > +#endif
> > +
> >      /* init generic devices */
> >      if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func,
> NULL, 1) != 0)
> >          exit(1);
> >
> 
> Assuming you tested the non-Xen TPM backend, this is okay.

Yes, I have tested Qemu TPM passthrough in KVM virtual machine. It is working ..

> 
> Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 17:39:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 17:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmR1o-0004CK-50; Thu, 06 Nov 2014 17:39:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmR1m-0004CF-2V
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 17:39:22 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	18/2C-27623-942BB545; Thu, 06 Nov 2014 17:39:21 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415295559!10878738!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15477 invoked from network); 6 Nov 2014 17:39:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 17:39:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="scan'208";a="190270188"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 12:31:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmQtn-0002gV-WD;
	Thu, 06 Nov 2014 17:31:08 +0000
Date: Thu, 6 Nov 2014 17:30:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Frediano Ziglio <frediano.ziglio@huawei.com>
In-Reply-To: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
Message-ID: <alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
 xen_swiotlb_map_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 Thu, 6 Nov 2014, Frediano Ziglio wrote:
> On ARM error code is not 0 so avoid to return it as error.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


Could you please fix the same error in lib/swiotlb.c too please?

>  drivers/xen/swiotlb-xen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ebd8f21..3b8d628 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
>  	 */
>  	if (!dma_capable(dev, dev_addr, size)) {
>  		swiotlb_tbl_unmap_single(dev, map, size, dir);
> -		dev_addr = 0;
> +		dev_addr = DMA_ERROR_CODE;
>  	}
>  	return dev_addr;
>  }
> -- 
> 1.9.1
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://secure-web.cisco.com/1cvjROyUxV6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpcxwEH-udGrGCCqkCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYcvWsOK5s3qg/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 17:39:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 17:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmR1o-0004CK-50; Thu, 06 Nov 2014 17:39:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmR1m-0004CF-2V
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 17:39:22 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	18/2C-27623-942BB545; Thu, 06 Nov 2014 17:39:21 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415295559!10878738!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15477 invoked from network); 6 Nov 2014 17:39:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 17:39:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="scan'208";a="190270188"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 12:31:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmQtn-0002gV-WD;
	Thu, 06 Nov 2014 17:31:08 +0000
Date: Thu, 6 Nov 2014 17:30:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Frediano Ziglio <frediano.ziglio@huawei.com>
In-Reply-To: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
Message-ID: <alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
 xen_swiotlb_map_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 Thu, 6 Nov 2014, Frediano Ziglio wrote:
> On ARM error code is not 0 so avoid to return it as error.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


Could you please fix the same error in lib/swiotlb.c too please?

>  drivers/xen/swiotlb-xen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ebd8f21..3b8d628 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
>  	 */
>  	if (!dma_capable(dev, dev_addr, size)) {
>  		swiotlb_tbl_unmap_single(dev, map, size, dir);
> -		dev_addr = 0;
> +		dev_addr = DMA_ERROR_CODE;
>  	}
>  	return dev_addr;
>  }
> -- 
> 1.9.1
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://secure-web.cisco.com/1cvjROyUxV6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpcxwEH-udGrGCCqkCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYcvWsOK5s3qg/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 17:49:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 17:49:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmRBP-0004Wc-8a; Thu, 06 Nov 2014 17:49:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XmRBO-0004WX-0b
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 17:49:18 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	2F/CC-02712-D94BB545; Thu, 06 Nov 2014 17:49:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415296154!11891228!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 541 invoked from network); 6 Nov 2014 17:49:16 -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;
	6 Nov 2014 17:49:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="scan'208";a="188858961"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 12:48:17 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XmRAO-0002wv-RR;
	Thu, 06 Nov 2014 17:48:16 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <linux-mm@kvack.org>, <xen-devel@lists.xenproject.org>
Date: Thu, 6 Nov 2014 17:48:16 +0000
Message-ID: <1415296096-22873-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Hugh Dickins <hughd@google.com>,
	David Vrabel <david.vrabel@citrix.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mgorman@suse.de>
Subject: [Xen-devel] [PATCH RFC] x86,
	mm: use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 b38af4721 ("x86,mm: fix pte_special versus pte_numa") pte_special()
(SPECIAL with PRESENT or PROTNONE) was made to complement pte_numa()
(SPECIAL with neither PRESENT nor PROTNONE). That broke Xen PV guest
with NUMA balancing support.

That's because Xen hypervisor sets _PAGE_GLOBAL (_PAGE_GLOBAL /
_PAGE_PROTNONE in Linux) for guest user space mapping. So in a Xen PV
guest, when NUMA balancing is enabled, a NUMA hinted PTE ends up
"SPECIAL (in fact NUMA) with PROTNONE but not PRESENT", which makes
pte_special() returns true when it shouldn't.

Fundamentally we only need _PAGE_NUMA and _PAGE_PRESENT to tell
difference between an unmapped entry and an entry protected for NUMA
hinting fault. So use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA, adjust
_PAGE_NUMA_MASK and SWP_OFFSET_SHIFT as needed.

Suggested-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: linux-mm@kvack.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/include/asm/pgtable.h       |    5 -----
 arch/x86/include/asm/pgtable_64.h    |    2 +-
 arch/x86/include/asm/pgtable_types.h |    8 ++++----
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index aa97a07..8dee3ed 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -131,11 +131,6 @@ static inline int pte_exec(pte_t pte)
 
 static inline int pte_special(pte_t pte)
 {
-	/*
-	 * See CONFIG_NUMA_BALANCING pte_numa in include/asm-generic/pgtable.h.
-	 * On x86 we have _PAGE_BIT_NUMA == _PAGE_BIT_GLOBAL+1 ==
-	 * __PAGE_BIT_SOFTW1 == _PAGE_BIT_SPECIAL.
-	 */
 	return (pte_flags(pte) & _PAGE_SPECIAL) &&
 		(pte_flags(pte) & (_PAGE_PRESENT|_PAGE_PROTNONE));
 }
diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
index 4572b2f..26f2ade 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -148,7 +148,7 @@ static inline int pgd_large(pgd_t pgd) { return 0; }
 #define SWP_TYPE_BITS (_PAGE_BIT_FILE - _PAGE_BIT_PRESENT - 1)
 #ifdef CONFIG_NUMA_BALANCING
 /* Automatic NUMA balancing needs to be distinguishable from swap entries */
-#define SWP_OFFSET_SHIFT (_PAGE_BIT_PROTNONE + 2)
+#define SWP_OFFSET_SHIFT (_PAGE_BIT_PROTNONE + 3)
 #else
 #define SWP_OFFSET_SHIFT (_PAGE_BIT_PROTNONE + 1)
 #endif
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0778964..bc82d6b 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -31,9 +31,9 @@
  * Swap offsets on configurations that allow automatic NUMA balancing use the
  * bits after _PAGE_BIT_GLOBAL. To uniquely distinguish NUMA hinting PTEs from
  * swap entries, we use the first bit after _PAGE_BIT_GLOBAL and shrink the
- * maximum possible swap space from 16TB to 8TB.
+ * maximum possible swap space from 16TB to 4TB.
  */
-#define _PAGE_BIT_NUMA		(_PAGE_BIT_GLOBAL+1)
+#define _PAGE_BIT_NUMA		_PAGE_BIT_SOFTW2
 
 /* If _PAGE_BIT_PRESENT is clear, we use these: */
 /* - if the user mapped it with PROT_NONE; pte_present gives true */
@@ -325,8 +325,8 @@ static inline pteval_t pte_flags(pte_t pte)
 }
 
 #ifdef CONFIG_NUMA_BALANCING
-/* Set of bits that distinguishes present, prot_none and numa ptes */
-#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)
+/* Set of bits that distinguishes present and numa ptes */
+#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PRESENT)
 static inline pteval_t ptenuma_flags(pte_t pte)
 {
 	return pte_flags(pte) & _PAGE_NUMA_MASK;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 17:49:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 17:49:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmRBP-0004Wc-8a; Thu, 06 Nov 2014 17:49:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XmRBO-0004WX-0b
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 17:49:18 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	2F/CC-02712-D94BB545; Thu, 06 Nov 2014 17:49:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415296154!11891228!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 541 invoked from network); 6 Nov 2014 17:49:16 -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;
	6 Nov 2014 17:49:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="scan'208";a="188858961"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 12:48:17 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XmRAO-0002wv-RR;
	Thu, 06 Nov 2014 17:48:16 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <linux-mm@kvack.org>, <xen-devel@lists.xenproject.org>
Date: Thu, 6 Nov 2014 17:48:16 +0000
Message-ID: <1415296096-22873-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Hugh Dickins <hughd@google.com>,
	David Vrabel <david.vrabel@citrix.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mgorman@suse.de>
Subject: [Xen-devel] [PATCH RFC] x86,
	mm: use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 b38af4721 ("x86,mm: fix pte_special versus pte_numa") pte_special()
(SPECIAL with PRESENT or PROTNONE) was made to complement pte_numa()
(SPECIAL with neither PRESENT nor PROTNONE). That broke Xen PV guest
with NUMA balancing support.

That's because Xen hypervisor sets _PAGE_GLOBAL (_PAGE_GLOBAL /
_PAGE_PROTNONE in Linux) for guest user space mapping. So in a Xen PV
guest, when NUMA balancing is enabled, a NUMA hinted PTE ends up
"SPECIAL (in fact NUMA) with PROTNONE but not PRESENT", which makes
pte_special() returns true when it shouldn't.

Fundamentally we only need _PAGE_NUMA and _PAGE_PRESENT to tell
difference between an unmapped entry and an entry protected for NUMA
hinting fault. So use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA, adjust
_PAGE_NUMA_MASK and SWP_OFFSET_SHIFT as needed.

Suggested-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: linux-mm@kvack.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/include/asm/pgtable.h       |    5 -----
 arch/x86/include/asm/pgtable_64.h    |    2 +-
 arch/x86/include/asm/pgtable_types.h |    8 ++++----
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index aa97a07..8dee3ed 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -131,11 +131,6 @@ static inline int pte_exec(pte_t pte)
 
 static inline int pte_special(pte_t pte)
 {
-	/*
-	 * See CONFIG_NUMA_BALANCING pte_numa in include/asm-generic/pgtable.h.
-	 * On x86 we have _PAGE_BIT_NUMA == _PAGE_BIT_GLOBAL+1 ==
-	 * __PAGE_BIT_SOFTW1 == _PAGE_BIT_SPECIAL.
-	 */
 	return (pte_flags(pte) & _PAGE_SPECIAL) &&
 		(pte_flags(pte) & (_PAGE_PRESENT|_PAGE_PROTNONE));
 }
diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
index 4572b2f..26f2ade 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -148,7 +148,7 @@ static inline int pgd_large(pgd_t pgd) { return 0; }
 #define SWP_TYPE_BITS (_PAGE_BIT_FILE - _PAGE_BIT_PRESENT - 1)
 #ifdef CONFIG_NUMA_BALANCING
 /* Automatic NUMA balancing needs to be distinguishable from swap entries */
-#define SWP_OFFSET_SHIFT (_PAGE_BIT_PROTNONE + 2)
+#define SWP_OFFSET_SHIFT (_PAGE_BIT_PROTNONE + 3)
 #else
 #define SWP_OFFSET_SHIFT (_PAGE_BIT_PROTNONE + 1)
 #endif
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0778964..bc82d6b 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -31,9 +31,9 @@
  * Swap offsets on configurations that allow automatic NUMA balancing use the
  * bits after _PAGE_BIT_GLOBAL. To uniquely distinguish NUMA hinting PTEs from
  * swap entries, we use the first bit after _PAGE_BIT_GLOBAL and shrink the
- * maximum possible swap space from 16TB to 8TB.
+ * maximum possible swap space from 16TB to 4TB.
  */
-#define _PAGE_BIT_NUMA		(_PAGE_BIT_GLOBAL+1)
+#define _PAGE_BIT_NUMA		_PAGE_BIT_SOFTW2
 
 /* If _PAGE_BIT_PRESENT is clear, we use these: */
 /* - if the user mapped it with PROT_NONE; pte_present gives true */
@@ -325,8 +325,8 @@ static inline pteval_t pte_flags(pte_t pte)
 }
 
 #ifdef CONFIG_NUMA_BALANCING
-/* Set of bits that distinguishes present, prot_none and numa ptes */
-#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)
+/* Set of bits that distinguishes present and numa ptes */
+#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PRESENT)
 static inline pteval_t ptenuma_flags(pte_t pte)
 {
 	return pte_flags(pte) & _PAGE_NUMA_MASK;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 18:41:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 18:41:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmRzi-0005cj-9T; Thu, 06 Nov 2014 18:41:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmRzf-0005ce-OS
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 18:41:16 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	43/43-02953-BC0CB545; Thu, 06 Nov 2014 18:41:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415299271!11908733!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9573 invoked from network); 6 Nov 2014 18:41:12 -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;
	6 Nov 2014 18:41:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="scan'208";a="190297987"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 6 Nov 2014 13:41:02 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmRzS-0004rb-77;
	Thu, 06 Nov 2014 18:41:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmRzR-0001vB-V8;
	Thu, 06 Nov 2014 18:41:02 +0000
Date: Thu, 6 Nov 2014 18:41:01 +0000
Message-ID: <E1XmRzR-0001vB-V8@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [linux-linus bisection] complete
	test-amd64-i386-rumpuserxen-i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6490934011355994455=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6490934011355994455==
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rumpuserxen-i386
test guest-start

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.=
6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: rumpuserxen git://xenbits.xen.org/rumpuser-xen.git
Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.gi=
t
Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torv=
alds/linux-2.6.git
  Bug introduced:  89453379aaf0608253124057df6cd8ac63948135
  Bug not present: 53429290a054b30e4683297409fc4627b2592315


  commit 89453379aaf0608253124057df6cd8ac63948135
  Merge: 5342929 99a49ce
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Oct 31 15:04:58 2014 -0700
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
     =20
      Pull networking fixes from David Miller:
       "A bit has accumulated, but it's been a week or so since my last bat=
ch
        of post-merge-window fixes, so...
     =20
         1) Missing module license in netfilter reject module, from Pablo.
            Lots of people ran into this.
     =20
         2) Off by one in mac80211 baserate calculation, from Karl Beldan.
     =20
         3) Fix incorrect return value from ax88179_178a driver's set_mac_a=
ddr
            op, which broke use of it with bonding.  From Ian Morgan.
     =20
         4) Checking of skb_gso_segment()'s return value was not all
            encompassing, it can return an SKB pointer, a pointer error, or
            NULL.  Fix from Florian Westphal.
     =20
            This is crummy, and longer term will be fixed to just return er=
ror
            pointers or a real SKB.
     =20
         6) Encapsulation offloads not being handled by
            skb_gso_transport_seglen().  From Florian Westphal.
     =20
         7) Fix deadlock in TIPC stack, from Ying Xue.
     =20
         8) Fix performance regression from using rhashtable for netlink
            sockets.  The problem was the synchronize_net() invoked for eve=
ry
            socket destroy.  From Thomas Graf.
     =20
         9) Fix bug in eBPF verifier, and remove the strong dependency of B=
PF
            on NET.  From Alexei Starovoitov.
     =20
        10) In qdisc_create(), use the correct interface to allocate
            ->cpu_bstats, otherwise the u64_stats_sync member isn't
            initialized properly.  From Sabrina Dubroca.
     =20
        11) Off by one in ip_set_nfnl_get_byindex(), from Dan Carpenter.
     =20
        12) nf_tables_newchain() was erroneously expecting error pointers f=
rom
            netdev_alloc_pcpu_stats().  It only returna a valid pointer or
            NULL.  From Sabrina Dubroca.
     =20
        13) Fix use-after-free in _decode_session6(), from Li RongQing.
     =20
        14) When we set the TX flow hash on a socket, we mistakenly do so
            before we've nailed down the final source port.  Move the setti=
ng
            deeper to fix this.  From Sathya Perla.
     =20
        15) NAPI budget accounting in amd-xgbe driver was counting descript=
ors
            instead of full packets, fix from Thomas Lendacky.
     =20
        16) Fix total_data_buflen calculation in hyperv driver, from Haiyan=
g
            Zhang.
     =20
        17) Fix bcma driver build with OF_ADDRESS disabled, from Hauke
            Mehrtens.
     =20
        18) Fix mis-use of per-cpu memory in TCP md5 code.  The problem is
            that something that ends up being vmalloc memory can't be passe=
d
            to the crypto hash routines via scatter-gather lists.  From Eri=
c
            Dumazet.
     =20
        19) Fix regression in promiscuous mode enabling in cdc-ether, from
            Olivier Blin.
     =20
        20) Bucket eviction and frag entry killing can race with eachother,
            causing an unlink of the object from the wrong list.  Fix from
            Nikolay Aleksandrov.
     =20
        21) Missing initialization of spinlock in cxgb4 driver, from Anish
            Bhatt.
     =20
        22) Do not cache ipv4 routing failures, otherwise if the sysctl for
            forwarding is subsequently enabled this won't be seen.  From
            Nicolas Cavallari"
     =20
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (131 commi=
ts)
        drivers: net: cpsw: Support ALLMULTI and fix IFF_PROMISC in switch =
mode
        drivers: net: cpsw: Fix broken loop condition in switch mode
        net: ethtool: Return -EOPNOTSUPP if user space tries to read EEPROM=
 with lengh 0
        stmmac: pci: set default of the filter bins
        net: smc91x: Fix gpios for device tree based booting
        mpls: Allow mpls_gso to be built as module
        mpls: Fix mpls_gso handler.
        r8152: stop submitting intr for -EPROTO
        netfilter: nft_reject_bridge: restrict reject to prerouting and inp=
ut
        netfilter: nft_reject_bridge: don't use IP stack to reject traffic
        netfilter: nf_reject_ipv6: split nf_send_reset6() in smaller functi=
ons
        netfilter: nf_reject_ipv4: split nf_send_reset() in smaller functio=
ns
        netfilter: nf_tables_bridge: update hook_mask to allow {pre,post}ro=
uting
        drivers/net: macvtap and tun depend on INET
        drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packe=
ts
        drivers/net: Disable UFO through virtio
        net: skb_fclone_busy() needs to detect orphaned skb
        gre: Use inner mac length when computing tunnel length
        mlx4: Avoid leaking steering rules on flow creation error flow
        net/mlx4_en: Don't attempt to TX offload the outer UDP checksum for=
 VXLAN
        ...
 =20
  commit 99a49ce613057f1934e1c378808374fd683b1541
  Merge: 1e5c4bc 75a916e
  Author: David S. Miller <davem@davemloft.net>
  Date:   Fri Oct 31 16:18:35 2014 -0400
 =20
      Merge tag 'master-2014-10-30' of git://git.kernel.org/pub/scm/linux/k=
ernel/git/linville/wireless
     =20
      John W. Linville says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      pull request: wireless 2014-10-31
     =20
      Please pull this small batch of spooky fixes intended for the 3.18
      stream...boo!
     =20
      Cyril Brulebois adds an rt2x00 device ID.
     =20
      Dan Carpenter provides a one-line masking fix for an ath9k debugfs
      entry.
     =20
      Larry Finger gives us a package of small rtlwifi fixes which add some
      bits that were left out of some feature updates that were included
      in the merge window.  Hopefully this isn't a sign that the rtlwifi
      base is getting too big...
     =20
      Marc Yang brings a fix for a temporary mwifiex stall when doing 11n
      RX reordering.
     =20
      Please let me know if there are problems!
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e5c4bc497c0a96e1ad2974539d353870f2cb0b6
  Author: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  Date:   Fri Oct 31 13:38:52 2014 -0400
 =20
      drivers: net: cpsw: Support ALLMULTI and fix IFF_PROMISC in switch mo=
de
     =20
      The cpsw driver did not support the IFF_ALLMULTI flag which makes dyn=
amic
      multicast routing not work.  Related to this, when enabling IFF_PROMI=
SC
      in switch mode, all registered multicast addresses are flushed, resul=
ting
      in only broadcast and unicast traffic being received.
     =20
      A new cpsw_ale_set_allmulti function now scans through the ALE entry
      table and adds/removes the host port from the unregistered multicast
      port mask of each vlan entry depending on the state of IFF_ALLMULTI.
      In promiscious mode, cpsw_ale_set_allmulti is used to force reception
      of all multicast traffic in addition to the unicast and broadcast tra=
ffic.
     =20
      With this change dynamic multicast and promiscious mode both work in
      switch mode.
     =20
      Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 6f979eb3fcfb4c3f42f230d174db4bbad0080710
  Author: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  Date:   Fri Oct 31 13:28:54 2014 -0400
 =20
      drivers: net: cpsw: Fix broken loop condition in switch mode
     =20
      0d961b3b52f566f823070ce2366511a7f64b928c (drivers: net: cpsw: fix bug=
gy
      loop condition) accidentally fixed a loop comparison in too many plac=
es
      while fixing a real bug.
     =20
      It was correct to fix the dual_emac mode section since there 'i' is u=
sed
      as an index into priv->slaves which is a 0 based array.
     =20
      However the other two changes (which are only used in switch mode)
      are wrong since there 'i' is actually the ALE port number, and port 0
      is the host port, while port 1 and up are the slave ports.
     =20
      Putting the loop condition back in the switch mode section fixes it.
     =20
      A comment has been added to point out the intent clearly to avoid fut=
ure
      confusion.  Also a comment is fixed that said the opposite of what wa=
s
      actually happening.
     =20
      Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
      Acked-by: Heiko Schocher <hs@denx.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e0fb6fb6d52686134b2ece144060219591d4f8d3
  Author: Guenter Roeck <linux@roeck-us.net>
  Date:   Thu Oct 30 20:50:15 2014 -0700
 =20
      net: ethtool: Return -EOPNOTSUPP if user space tries to read EEPROM w=
ith lengh 0
     =20
      If a driver supports reading EEPROM but no EEPROM is installed in the=
 system,
      the driver's get_eeprom_len function returns 0. ethtool will subseque=
ntly
      try to read that zero-length EEPROM anyway. If the driver does not su=
pport
      EEPROM access at all, this operation will return -EOPNOTSUPP. If the =
driver
      does support EEPROM access but no EEPROM is installed, the operation =
will
      return -EINVAL. Return -EOPNOTSUPP in both cases for consistency.
     =20
      Signed-off-by: Guenter Roeck <linux@roeck-us.net>
      Tested-by: Andrew Lunn <andrew@lunn.ch>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e19e084eae727654052339757ab7f1eaff58bad
  Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Date:   Fri Oct 31 18:28:03 2014 +0200
 =20
      stmmac: pci: set default of the filter bins
     =20
      The commit 3b57de958e2a brought the support for a different amount of=
 the
      filter bins, but didn't update the PCI driver accordingly. This patch=
 appends
      the default values when the device is enumerated via PCI bus.
     =20
      Fixes: 3b57de958e2a (net: stmmac: Support devicetree configs for mcas=
t and ucast filter entries)
      Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7d2911c4381555b31ef0bcae42a0dbf9ade7426e
  Author: Tony Lindgren <tony@atomide.com>
  Date:   Thu Oct 30 09:59:27 2014 -0700
 =20
      net: smc91x: Fix gpios for device tree based booting
     =20
      With legacy booting, the platform init code was taking care of
      the configuring of GPIOs. With device tree based booting, things
      may or may not work depending what bootloader has configured or
      if the legacy platform code gets called.
     =20
      Let's add support for the pwrdn and reset GPIOs to the smc91x
      driver to fix the issues of smc91x not working properly when
      booted in device tree mode.
     =20
      And let's change n900 to use these settings as some versions
      of the bootloader do not configure things properly causing
      errors.
     =20
      Reported-by: Kevin Hilman <khilman@linaro.org>
      Signed-off-by: Tony Lindgren <tony@atomide.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit de05c400f7dfa566f598140f8604a5de8067cd5f
  Author: Pravin B Shelar <pshelar@nicira.com>
  Date:   Thu Oct 30 00:50:04 2014 -0700
 =20
      mpls: Allow mpls_gso to be built as module
     =20
      Kconfig already allows mpls to be built as module. Following patch
      fixes Makefile to do same.
     =20
      CC: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
      Acked-by: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f7065f4bd3fe4ad6bf7e49ba7c68baa2c7046146
  Author: Pravin B Shelar <pshelar@nicira.com>
  Date:   Thu Oct 30 00:49:57 2014 -0700
 =20
      mpls: Fix mpls_gso handler.
     =20
      mpls gso handler needs to pull skb after segmenting skb.
     =20
      CC: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
      Acked-by: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d59c876dd61f3c151db077f9d73774e605f2b35e
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Fri Oct 31 13:35:57 2014 +0800
 =20
      r8152: stop submitting intr for -EPROTO
     =20
      For Renesas USB 3.0 host controller, when unplugging the usb hub whic=
h
      has the RTL8153 plugged, the driver would get -EPROTO for interrupt
      transfer. There is high probability to get the information of "HC die=
d;
      cleaning up", if the driver continues to submit the interrupt transfe=
r
      before the disconnect() is called.
     =20
      [ 1024.197678] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.213673] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.229668] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.245661] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.261653] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.277648] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.293642] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.309638] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.325633] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.341627] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.357621] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.373615] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.383097] usb 9-1: USB disconnect, device number 2
      [ 1024.383103] usb 9-1.4: USB disconnect, device number 6
      [ 1029.391010] xhci_hcd 0000:04:00.0: xHCI host not responding to sto=
p endpoint command.
      [ 1029.391016] xhci_hcd 0000:04:00.0: Assuming host is dying, halting=
 host.
      [ 1029.392551] xhci_hcd 0000:04:00.0: HC died; cleaning up
      [ 1029.421480] usb 8-1: USB disconnect, device number 2
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e3a88f9c4f79a4d138a0ea464cfbac40ba46644c
  Merge: de11b0e 127917c
  Author: David S. Miller <davem@davemloft.net>
  Date:   Fri Oct 31 12:29:42 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      netfilter/ipvs fixes for net
     =20
      The following patchset contains fixes for netfilter/ipvs. This round =
of
      fixes is larger than usual at this stage, specifically because of the
      nf_tables bridge reject fixes that I would like to see in 3.18. The
      patches are:
     =20
      1) Fix a null-pointer dereference that may occur when logging
         errors. This problem was introduced by 4a4739d56b0 ("ipvs: Pull
         out crosses_local_route_boundary logic") in v3.17-rc5.
     =20
      2) Update hook mask in nft_reject_bridge so we can also filter out
         packets from there. This fixes 36d2af5 ("netfilter: nf_tables: all=
ow
         to filter from prerouting and postrouting"), which needs this chun=
k
         to work.
     =20
      3) Two patches to refactor common code to forge the IPv4 and IPv6
         reject packets from the bridge. These are required by the nf_table=
s
         reject bridge fix.
     =20
      4) Fix nft_reject_bridge by avoiding the use of the IP stack to rejec=
t
         packets from the bridge. The idea is to forge the reject packets a=
nd
         inject them to the original port via br_deliver() which is now
         exported for that purpose.
     =20
      5) Restrict nft_reject_bridge to bridge prerouting and input hooks.
         the original skbuff may cloned after prerouting when the bridge st=
ack
         needs to flood it to several bridge ports, it is too late to rejec=
t
         the traffic.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 127917c29a432c3b798e014a1714e9c1af0f87fe
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Mon Oct 27 14:08:17 2014 +0100
 =20
      netfilter: nft_reject_bridge: restrict reject to prerouting and input
     =20
      Restrict the reject expression to the prerouting and input bridge
      hooks. If we allow this to be used from forward or any other later
      bridge hook, if the frame is flooded to several ports, we'll end up
      sending several reject packets, one per cloned packet.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 523b929d5446c023e1219aa81455a8c766cac883
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 18:40:26 2014 +0200
 =20
      netfilter: nft_reject_bridge: don't use IP stack to reject traffic
     =20
      If the packet is received via the bridge stack, this cannot reject
      packets from the IP stack.
     =20
      This adds functions to build the reject packet and send it from the
      bridge stack. Comments and assumptions on this patch:
     =20
      1) Validate the IPv4 and IPv6 headers before further processing,
         given that the packet comes from the bridge stack, we cannot assum=
e
         they are clean. Truncated packets are dropped, we follow similar
         approach in the existing iptables match/target extensions that nee=
d
         to inspect layer 4 headers that is not available. This also includ=
es
         packets that are directed to multicast and broadcast ethernet
         addresses.
     =20
      2) br_deliver() is exported to inject the reject packet via
         bridge localout -> postrouting. So the approach is similar to what
         we already do in the iptables reject target. The reject packet is
         sent to the bridge port from which we have received the original
         packet.
     =20
      3) The reject packet is forged based on the original packet. The TTL
         is set based on sysctl_ip_default_ttl for IPv4 and per-net
         ipv6.devconf_all hoplimit for IPv6.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 8bfcdf6671b1c8006c52c3eaf9fd1b5dfcf41c3d
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sun Oct 26 12:35:54 2014 +0100
 =20
      netfilter: nf_reject_ipv6: split nf_send_reset6() in smaller function=
s
     =20
      That can be reused by the reject bridge expression to build the rejec=
t
      packet. The new functions are:
     =20
      * nf_reject_ip6_tcphdr_get(): to sanitize and to obtain the TCP heade=
r.
      * nf_reject_ip6hdr_put(): to build the IPv6 header.
      * nf_reject_ip6_tcphdr_put(): to build the TCP header.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 052b9498eea532deb5de75277a53f6e0623215dc
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 18:24:57 2014 +0200
 =20
      netfilter: nf_reject_ipv4: split nf_send_reset() in smaller functions
     =20
      That can be reused by the reject bridge expression to build the rejec=
t
      packet. The new functions are:
     =20
      * nf_reject_ip_tcphdr_get(): to sanitize and to obtain the TCP header=
.
      * nf_reject_iphdr_put(): to build the IPv4 header.
      * nf_reject_ip_tcphdr_put(): to build the TCP header.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 4d87716cd057bde3f90e304289c1fec88d45a1cc
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 12:25:06 2014 +0200
 =20
      netfilter: nf_tables_bridge: update hook_mask to allow {pre,post}rout=
ing
     =20
      Fixes: 36d2af5 ("netfilter: nf_tables: allow to filter from preroutin=
g and postrouting")
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit de11b0e8c569b96c2cf6a811e3805b7aeef498a3
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Fri Oct 31 03:10:31 2014 +0000
 =20
      drivers/net: macvtap and tun depend on INET
     =20
      These drivers now call ipv6_proxy_select_ident(), which is defined
      only if CONFIG_INET is enabled.  However, they have really depended
      on CONFIG_INET for as long as they have allowed sending GSO packets
      from userland.
     =20
      Reported-by: kbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
      Fixes: b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
      Fixes: 5188cd44c55d ("drivers/net, ipv6: Select IPv6 fragment idents =
for virtio UFO packets")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c1304b217c7cefa5718fab9d36c59ba0d0133c6e
  Merge: 39bb5e6 5188cd4
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 20:01:27 2014 -0400
 =20
      Merge branch 'ufo-fix'
     =20
      Ben Hutchings says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      drivers/net,ipv6: Fix IPv6 fragment ID selection for virtio
     =20
      The virtio net protocol supports UFO but does not provide for passing=
 a
      fragment ID for fragmentation of IPv6 packets.  We used to generate a
      fragment ID wherever such a packet was fragmented, but currently we
      always use ID=3D0!
     =20
      v2: Add blank lines after declarations
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Thu Oct 30 18:27:17 2014 +0000
 =20
      drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets
     =20
      UFO is now disabled on all drivers that work with virtio net headers,
      but userland may try to send UFO/IPv6 packets anyway.  Instead of
      sending with ID=3D0, we should select identifiers on their behalf (as=
 we
      used to).
     =20
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_dat=
a")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Thu Oct 30 18:27:12 2014 +0000
 =20
      drivers/net: Disable UFO through virtio
     =20
      IPv6 does not allow fragmentation by routers, so there is no
      fragmentation ID in the fixed header.  UFO for IPv6 requires the ID t=
o
      be passed separately, but there is no provision for this in the virti=
o
      net protocol.
     =20
      Until recently our software implementation of UFO/IPv6 generated a ne=
w
      ID, but this was a bug.  Now we will use ID=3D0 for any UFO/IPv6 pack=
et
      passed through a tap, which is even worse.
     =20
      Unfortunately there is no distinction between UFO/IPv4 and v6
      features, so disable UFO on taps and virtio_net completely until we
      have a proper solution.
     =20
      We cannot depend on VM managers respecting the tap feature flags, so
      keep accepting UFO packets but log a warning the first time we do
      this.
     =20
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_dat=
a")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 39bb5e62867de82b269b07df900165029b928359
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 30 10:32:34 2014 -0700
 =20
      net: skb_fclone_busy() needs to detect orphaned skb
     =20
      Some drivers are unable to perform TX completions in a bound time.
      They instead call skb_orphan()
     =20
      Problem is skb_fclone_busy() has to detect this case, otherwise
      we block TCP retransmits and can freeze unlucky tcp sessions on
      mostly idle hosts.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 1f3279ae0c13 ("tcp: avoid retransmits of TCP packets hanging i=
n host queues")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 14051f0452a2c26a3f4791e6ad6a435e8f1945ff
  Author: Tom Herbert <therbert@google.com>
  Date:   Thu Oct 30 08:40:56 2014 -0700
 =20
      gre: Use inner mac length when computing tunnel length
     =20
      Currently, skb_inner_network_header is used but this does not account
      for Ethernet header for ETH_P_TEB. Use skb_inner_mac_header which
      handles TEB and also should work with IP encapsulation in which case
      inner mac and inner network headers are the same.
     =20
      Tested: Ran TCP_STREAM over GRE, worked as expected.
     =20
      Signed-off-by: Tom Herbert <therbert@google.com>
      Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 292dd6542f90126826fe87b302e6afa3b7ada6b8
  Merge: 9cc233f 571e1b2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 19:49:20 2014 -0400
 =20
      Merge branch 'mellanox-net'
     =20
      Or Gerlitz says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      mlx4 driver encapsulation/steering fixes
     =20
      The 1st patch fixes a bug in the TX path that supports offloading the
      TX checksum of (VXLAN) encapsulated TCP packets. It turns out that th=
e
      bug is revealed only when the receiver runs in non-offloaded mode, so
      we somehow missed it so far... please queue it for -stable >=3D 3.14
     =20
      The 2nd patch makes sure not to leak steering entry on error flow,
      please queue it to 3.17-stable
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 571e1b2c7a4c2fd5faa1648462a6b65fa26530d7
  Author: Or Gerlitz <ogerlitz@mellanox.com>
  Date:   Thu Oct 30 15:59:28 2014 +0200
 =20
      mlx4: Avoid leaking steering rules on flow creation error flow
     =20
      If mlx4_ib_create_flow() attempts to create > 1 rules with the
      firmware, and one of these registrations fail, we leaked the
      already created flow rules.
     =20
      One example of the leak is when the registration of the VXLAN ghost
      steering rule fails, we didn't unregister the original rule requested
      by the user, introduced in commit d2fce8a9060d "mlx4: Set
      user-space raw Ethernet QPs to properly handle VXLAN traffic".
     =20
      While here, add dump of the VXLAN portion of steering rules
      so it can actually be seen when flow creation fails.
     =20
      Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit a4f2dacbf2a5045e34b98a35d9a3857800f25a7b
  Author: Or Gerlitz <ogerlitz@mellanox.com>
  Date:   Thu Oct 30 15:59:27 2014 +0200
 =20
      net/mlx4_en: Don't attempt to TX offload the outer UDP checksum for V=
XLAN
     =20
      For VXLAN/NVGRE encapsulation, the current HW doesn't support offload=
ing
      both the outer UDP TX checksum and the inner TCP/UDP TX checksum.
     =20
      The driver doesn't advertize SKB_GSO_UDP_TUNNEL_CSUM, however we are =
wrongly
      telling the HW to offload the outer UDP checksum for encapsulated pac=
kets,
      fix that.
     =20
      Fixes: 837052d0ccc5 ('net/mlx4_en: Add netdev support for TCP/IP
      		     offloads of vxlan tunneling')
      Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9cc233fb0f94b79d07cf141a625e237769d267a1
  Merge: fa19c2b0 e3215f0
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 19:46:33 2014 -0400
 =20
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/gi=
t/jkirsher/net
     =20
      Jeff Kirsher says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      Intel Wired LAN Driver Updates 2014-10-30
     =20
      This series contains updates to e1000, igb and ixgbe.
     =20
      Francesco Ruggeri fixes an issue with e1000 where in a VM the driver =
did
      not support unicast filtering.
     =20
      Roman Gushchin fixes an issue with igb where the driver was re-using
      mapped pages so that packets were still getting dropped even if all
      the memory issues are gone and there is free memory.
     =20
      Junwei Zhang found where in the ixgbe_clean_rx_ring() we were repeati=
ng
      the assignment of NULL to the receive buffer skb and fixes it.
     =20
      Emil fixes a race condition between setup_link and SFP detection rout=
ine
      in the watchdog when setting the advertised speed.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit fa19c2b050ab5254326f5fc07096dd3c6a8d5d58
  Author: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
  Date:   Thu Oct 30 10:09:53 2014 +0100
 =20
      ipv4: Do not cache routing failures due to disabled forwarding.
     =20
      If we cache them, the kernel will reuse them, independently of
      whether forwarding is enabled or not.  Which means that if forwarding=
 is
      disabled on the input interface where the first routing request comes
      from, then that unreachable result will be cached and reused for
      other interfaces, even if forwarding is enabled on them.  The opposit=
e
      is also true.
     =20
      This can be verified with two interfaces A and B and an output interf=
ace
      C, where B has forwarding enabled, but not A and trying
      ip route get $dst iif A from $src && ip route get $dst iif B from $sr=
c
     =20
      Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communicati=
ons.fr>
      Reviewed-by: Julian Anastasov <ja@ssi.bg>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e327c225c911529898ec300cb96d2088893de3df
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Wed Oct 29 17:54:03 2014 -0700
 =20
      cxgb4 : Fix missing initialization of win0_lock
     =20
      win0_lock was being used un-initialized, resulting in warning traces
      being seen when lock debugging is enabled (and just wrong)
     =20
      Fixes : fc5ab0209650 ('cxgb4: Replaced the backdoor mechanism to acce=
ss the HW
       memory with PCIe Window method')
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: Casey Leedom <leedom@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 83810a9a6af310e413ce649c6ca2df2b4946e5a4
  Merge: d70127e e3bd1a8
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 15:49:05 2014 -0400
 =20
      Merge branch 'r8152-net'
     =20
      Hayes Wang says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      r8152: patches for autosuspend
     =20
      There are unexpected processes when enabling autosuspend.
      These patches are used to fix them.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e3bd1a81cd1e3f8ed961e642e97206d715db06c4
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:17 2014 +0800
 =20
      r8152: check WORK_ENABLE in suspend function
     =20
      Avoid unnecessary behavior when autosuspend occurs during open().
      The relative processes should only be run after finishing open().
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f4c7476b041d200c3b347f019eebf05e6d0b47f9
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:16 2014 +0800
 =20
      r8152: reset tp->speed before autoresuming in open function
     =20
      If (tp->speed & LINK_STATUS) is not zero, the rtl8152_resume()
      would call rtl_start_rx() before enabling the tx/rx. Avoid this
      by resetting it to zero.
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 923e1ee3ff0b585cc4f56cf696c8455708537ffb
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:15 2014 +0800
 =20
      r8152: clear SELECTIVE_SUSPEND when autoresuming
     =20
      The flag of SELECTIVE_SUSPEND should be cleared when autoresuming.
      Otherwise, when the system suspend and resume occur, it may have
      the wrong flow.
     =20
      Besides, because the flag of SELECTIVE_SUSPEND couldn't be used
      to check if the hw enables the relative feature, it should alwayes
      be disabled in close().
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 75a916e1944fea8347d2245c62567187e4eff9dd
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:13 2014 -0500
 =20
      rtlwifi: rtl8192se: Fix firmware loading
     =20
      An error in the code makes the allocated space for firmware to be too
      small.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 8ae3c16e41b02db8ffe4121468519d6352baedc1
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:11 2014 -0500
 =20
      rtlwifi: rtl8192ce: Add missing section to read descriptor setting
     =20
      The new version of rtlwifi needs code in rtl92ce_get_desc() that retu=
rns
      the buffer address for read operations.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 30c5ccc6afee39754cff75ad8d775ad39a2ce989
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:10 2014 -0500
 =20
      rtlwifi: rtl8192se: Add missing section to read descriptor setting
     =20
      The new version of rtlwifi needs code in rtl92se_get_desc() that retu=
rns
      the buffer address for read operations.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 501479699ff484ba8acc1d07022271f00cfc55a3
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:09 2014 -0500
 =20
      rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw()
     =20
      Driver rtlwifi has been modified to call ieee80211_register_hw()
      from the probe routine; however, the existing call in the callback
      routine for deferred firmware loading was not removed.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit c0386f1584127442d0f2aea41bc948056d6b1337
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:08 2014 -0500
 =20
      rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing ge=
t_btc_status
     =20
      The recent changes in checking for Bluetooth status added some callba=
cks to code
      in rtlwifi. To make certain that all callbacks are defined, a dummy r=
outine has been
      added to rtlwifi, and the drivers that need to use it are modified.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 3a8fede115f12f7b90524d1ba4e709ce398ce8c6
  Author: Marc Yang <yangyang@marvell.com>
  Date:   Wed Oct 29 22:44:34 2014 +0530
 =20
      mwifiex: restart rxreorder timer correctly
     =20
      During 11n RX reordering, if there is a hole in RX table,
      driver will not send packets to kernel until the rxreorder
      timer expires or the table is full.
      However, currently driver always restarts rxreorder timer when
      receiving a packet, which causes the timer hardly to expire.
      So while connected with to 11n AP in a busy environment,
      ping packets may get blocked for about 30 seconds.
     =20
      This patch fixes this timer restarting by ensuring rxreorder timer
      would only be restarted either timer is not set or start_win
      has changed.
     =20
      Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
      Signed-off-by: Plus Chen <pchen@marvell.com>
      Signed-off-by: Marc Yang <yangyang@marvell.com>
      Signed-off-by: Cathy Luo <cluo@marvell.com>
      Signed-off-by: Avinash Patil <patila@marvell.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit a017ff755e43de9a3221d4ff4f03184ea7b93733
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Wed Oct 29 18:48:05 2014 +0300
 =20
      ath9k: fix some debugfs output
     =20
      The right shift operation has higher precedence than the mask so we
      left shift by "(i * 3)" and then immediately right shift by "(i * 3)"
      then we mask.  It should be left shift, mask, and then right shift.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 664d6a792785cc677c2091038ce10322c8d04ae1
  Author: Cyril Brulebois <kibi@debian.org>
  Date:   Tue Oct 28 16:42:41 2014 +0100
 =20
      wireless: rt2x00: add new rt2800usb device
     =20
      0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
     =20
      References: https://bugs.debian.org/766802
      Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
      Cc: stable@vger.kernel.org
      Signed-off-by: Cyril Brulebois <kibi@debian.org>
      Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit e3215f0ac77ec23b052cb0bf511143038ac2ad7b
  Author: Emil Tantilov <emil.s.tantilov@intel.com>
  Date:   Tue Oct 28 05:50:03 2014 +0000
 =20
      ixgbe: fix race when setting advertised speed
     =20
      Following commands:
     =20
      modprobe ixgbe
      ifconfig ethX up
      ethtool -s ethX advertise 0x020
     =20
      can lead to "setup link failed with code -14" error due to the setup_=
link
      call racing with the SFP detection routine in the watchdog.
     =20
      This patch resolves this issue by protecting the setup_link call with=
 check
      for __IXGBE_IN_SFP_INIT.
     =20
      Reported-by: Scott Harrison <scoharr2@cisco.com>
      Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
      Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit 4d2fcfbcf8141cdf70245a0c0612b8076f4b7e32
  Author: Junwei Zhang <linggao.zjw@alibaba-inc.com>
  Date:   Wed Oct 22 15:29:03 2014 +0000
 =20
      ixgbe: need not repeat init skb with NULL
     =20
      Signed-off-by: Martin Zhang <martinbj2008@gmail.com>
      Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit bc16e47f03a7dce9ad68029b21519265c334eb12
  Author: Roman Gushchin <klamm@yandex-team.ru>
  Date:   Thu Oct 23 03:32:27 2014 +0000
 =20
      igb: don't reuse pages with pfmemalloc flag
     =20
      Incoming packet is dropped silently by sk_filter(), if the skb was
      allocated from pfmemalloc reserves and the corresponding socket is
      not marked with the SOCK_MEMALLOC flag.
     =20
      Igb driver allocates pages for DMA with __skb_alloc_page(), which
      calls alloc_pages_node() with the __GFP_MEMALLOC flag. So, in case
      of OOM condition, igb can get pages with pfmemalloc flag set.
     =20
      If an incoming packet hits the pfmemalloc page and is large enough
      (small packets are copying into the memory, allocated with
      netdev_alloc_skb_ip_align(), so they are not affected), it will be
      dropped.
     =20
      This behavior is ok under high memory pressure, but the problem is
      that the igb driver reuses these mapped pages. So, packets are still
      dropping even if all memory issues are gone and there is a plenty
      of free memory.
     =20
      In my case, some TCP sessions hang on a small percentage (< 0.1%)
      of machines days after OOMs.
     =20
      Fix this by avoiding reuse of such pages.
     =20
      Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
      Tested-by: Aaron Brown "aaron.f.brown@intel.com"
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit a22bb0b9b9b09b4cc711f6d577679773e074dde9
  Author: Francesco Ruggeri <fruggeri@aristanetworks.com>
  Date:   Wed Oct 22 15:29:24 2014 +0000
 =20
      e1000: unset IFF_UNICAST_FLT on WMware 82545EM
     =20
      VMWare's e1000 implementation does not seem to support unicast filter=
ing.
      This can be observed by configuring a macvlan interface on eth0 in a =
VM in
      VMWare Fusion 5.0.5, and trying to use that interface instead of eth0=
.
      Tested on 3.16.
     =20
      Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
      Tested-by: Aaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit d70127e8a942364de8dd140fe73893efda363293
  Author: Nikolay Aleksandrov <nikolay@redhat.com>
  Date:   Tue Oct 28 10:44:01 2014 +0100
 =20
      inet: frags: remove the WARN_ON from inet_evict_bucket
     =20
      The WARN_ON in inet_evict_bucket can be triggered by a valid case:
      inet_frag_kill and inet_evict_bucket can be running in parallel on th=
e
      same queue which means that there has been at least one more ref adde=
d
      by a previous inet_frag_find call, but inet_frag_kill can delete the
      timer before inet_evict_bucket which will cause the WARN_ON() there t=
o
      trigger since we'll have refcnt!=3D1. Now, this case is valid because=
 the
      queue is being "killed" for some reason (removed from the chain list =
and
      its timer deleted) so it will get destroyed in the end by one of the
      inet_frag_put() calls which reaches 0 i.e. refcnt is still valid.
     =20
      CC: Florian Westphal <fw@strlen.de>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Patrick McLean <chutzpah@gentoo.org>
     =20
      Fixes: b13d3cbfb8e8 ("inet: frag: move eviction of queues to work que=
ue")
      Reported-by: Patrick McLean <chutzpah@gentoo.org>
      Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 65ba1f1ec0eff1c25933468e1d238201c0c2cb29
  Author: Nikolay Aleksandrov <nikolay@redhat.com>
  Date:   Tue Oct 28 10:30:34 2014 +0100
 =20
      inet: frags: fix a race between inet_evict_bucket and inet_frag_kill
     =20
      When the evictor is running it adds some chosen frags to a local list=
 to
      be evicted once the chain lock has been released but at the same time
      the *frag_queue can be running for some of the same queues and it
      may call inet_frag_kill which will wait on the chain lock and
      will then delete the queue from the wrong list since it was added in =
the
      eviction one. The fix is simple - check if the queue has the evict fl=
ag
      set under the chain lock before deleting it, this is safe because the
      evict flag is set only under that lock and having the flag set also m=
eans
      that the queue has been detached from the chain list, so no need to d=
elete
      it again.
      An important note to make is that we're safe w.r.t refcnt because
      inet_frag_kill and inet_evict_bucket will sync on the del_timer opera=
tion
      where only one of the two can succeed (or if the timer is executing -
      none of them), the cases are:
      1. inet_frag_kill succeeds in del_timer
       - then the timer ref is removed, but inet_evict_bucket will not add
         this queue to its expire list but will restart eviction in that ch=
ain
      2. inet_evict_bucket succeeds in del_timer
       - then the timer ref is kept until the evictor "expires" the queue, =
but
         inet_frag_kill will remove the initial ref and will set
         INET_FRAG_COMPLETE which will make the frag_expire fn just to remo=
ve
         its ref.
      In the end all of the queue users will do an inet_frag_put and the on=
e
      that reaches 0 will free it. The refcount balance should be okay.
     =20
      CC: Florian Westphal <fw@strlen.de>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Patrick McLean <chutzpah@gentoo.org>
     =20
      Fixes: b13d3cbfb8e8 ("inet: frag: move eviction of queues to work que=
ue")
      Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
      Reported-by: Patrick McLean <chutzpah@gentoo.org>
      Tested-by: Patrick McLean <chutzpah@gentoo.org>
      Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
      Reviewed-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8f4eb70059ee834522ce90a6fce0aa3078c18620
  Author: Tej Parkash <tej.parkash@qlogic.com>
  Date:   Tue Oct 28 01:18:15 2014 -0400
 =20
      cnic: Update the rcu_access_pointer() usages
     =20
      1. Remove the rcu_read_lock/unlock around rcu_access_pointer
      2. Replace the rcu_dereference with rcu_access_pointer
     =20
      Signed-off-by: Tej Parkash <tej.parkash@qlogic.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit cd03cf0158449f9f4c19ecb54dfc97d9bd86eeeb
  Author: Hariprasad Shenai <hariprasad@chelsio.com>
  Date:   Mon Oct 27 23:22:10 2014 +0530
 =20
      cxgb4vf: Replace repetitive pci device ID's with right ones
     =20
      Replaced repetive Device ID's which got added in commit b961f9a48844e=
cf3
      ("cxgb4vf: Remove superfluous "idx" parameter of CH_DEVICE() macro")
     =20
      Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b2ed64a97430a26a63c6ea91c9b50e639a98dfbc
  Author: Lubomir Rintel <lkundrak@v3.sk>
  Date:   Mon Oct 27 17:39:16 2014 +0100
 =20
      ipv6: notify userspace when we added or changed an ipv6 token
     =20
      NetworkManager might want to know that it changed when the router adv=
ertisement
      arrives.
     =20
      Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: Daniel Borkmann <dborkman@redhat.com>
      Acked-by: Daniel Borkmann <dborkman@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d56109020d93337545dd257a790cb429a70acfad
  Author: WANG Cong <xiyou.wangcong@gmail.com>
  Date:   Fri Oct 24 16:55:58 2014 -0700
 =20
      sch_pie: schedule the timer after all init succeed
     =20
      Cc: Vijay Subramanian <vijaynsu@cisco.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
      Acked-by: Eric Dumazet <edumazet@google.com>
 =20
  commit 068301f2be36a5c1ee9a2521c94b98e343612a88
  Merge: 9ffa1fc b77e26d
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 17:26:24 2014 -0400
 =20
      Merge branch 'cdc-ether'
     =20
      Olivier Blin says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      cdc-ether: handle promiscuous mode
     =20
      Since kernel 3.16, my Lenovo USB network adapters (RTL8153) using
      cdc-ether are not working anymore in a bridge.
     =20
      This is due to commit c472ab68ad67db23c9907a27649b7dc0899b61f9, which
      resets the packet filter when the device is bound.
     =20
      The default packet filter set by cdc-ether does not include
      promiscuous, while the adapter seemed to have promiscuous enabled by
      default.
     =20
      This patch series allows to support promiscuous mode for cdc-ether, b=
y
      hooking into set_rx_mode.
     =20
      Incidentally, maybe this device should be handled by the r8152 driver=
,
      but this patch series is still nice for other adapters.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
      Acked-by: Oliver Neukum <oneukum@suse.de>
 =20
  commit b77e26d191590c73b4a982ea3b3b87194069a56a
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:02 2014 +0200
 =20
      cdc-ether: handle promiscuous mode with a set_rx_mode callback
     =20
      Promiscuous mode was not supported anymore with my Lenovo adapters
      (RTL8153) since commit c472ab68ad67db23c9907a27649b7dc0899b61f9
      (cdc-ether: clean packet filter upon probe).
     =20
      It was not possible to use them in a bridge anymore.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Also-analyzed-by: Lo=C3=AFc Yhuel <loic.yhuel@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d80c679bc1526183f1cf4adc54b0b72e8798555e
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:01 2014 +0200
 =20
      cdc-ether: extract usbnet_cdc_update_filter function
     =20
      This will be used by the set_rx_mode callback.
     =20
      Also move a comment about multicast filtering in this new function.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1efed2d06c703489342ab6af2951683e07509c99
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:00 2014 +0200
 =20
      usbnet: add a callback for set_rx_mode
     =20
      To delegate promiscuous mode and multicast filtering to the subdriver=
.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9ffa1fcaef222026a8e031830f8db29d3f2cfc47
  Merge: ebcf34f 704d33e
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 17:08:56 2014 -0400
 =20
      Merge branch 'systemport-net'
     =20
      Florian Fainelli says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      net: systemport: RX path and suspend fixes
     =20
      These two patches fix a race condition where we have our RX interrupt=
s
      enabled, but not NAPI for the RX path, and the second patch fixes an
      issue for packets stuck in RX fifo during a suspend/resume cycle.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 704d33e7006f20f9b4fa7d24a0f08c4b5919b131
  Author: Florian Fainelli <f.fainelli@gmail.com>
  Date:   Tue Oct 28 11:12:01 2014 -0700
 =20
      net: systemport: reset UniMAC coming out of a suspend cycle
     =20
      bcm_sysport_resume() was missing an UniMAC reset which can lead to
      various receive FIFO corruptions coming out of a suspend cycle. If th=
e
      RX FIFO is stuck, it will deliver corrupted/duplicate packets towards
      the host CPU interface.
     =20
      This could be reproduced on crowded network and when Wake-on-LAN is
      enabled for this particular interface because the switch still forwar=
ds
      packets towards the host CPU interface (SYSTEMPORT), and we had to le=
ave
      the UniMAC RX enable bit on to allow matching MagicPackets.
     =20
      Once we re-enter the resume function, there is a small window during
      which the UniMAC receive is still enabled, and we start queueing
      packets, but the RDMA and RBUF engines are not ready, which leads to
      having packets stuck in the UniMAC RX FIFO, ultimately delivered towa=
rds
      the host CPU as corrupted.
     =20
      Fixes: 40755a0fce17 ("net: systemport: add suspend and resume support=
")
      Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8edf0047f4b8e03d94ef88f5a7dec146cce03a06
  Author: Florian Fainelli <f.fainelli@gmail.com>
  Date:   Tue Oct 28 11:12:00 2014 -0700
 =20
      net: systemport: enable RX interrupts after NAPI
     =20
      There is currently a small window during which the SYSTEMPORT adapter
      enables its RX interrupts without having enabled its NAPI handler, wh=
ich
      can result in packets to be discarded during interface bringup.
     =20
      A similar but more serious window exists in bcm_sysport_resume() duri=
ng
      which we can have the RDMA engine not fully prepared to receive packe=
ts
      and yet having RX interrupts enabled.
     =20
      Fix this my moving the RX interrupt enable down to
      bcm_sysport_netif_start() after napi_enable() for the RX path is call=
ed,
      which fixes both call sites: bcm_sysport_open() and
      bcm_sysport_resume().
     =20
      Fixes: b02e6d9ba7ad ("net: systemport: add bcm_sysport_netif_{enable,=
stop}")
      Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ebcf34f3d4be11f994340aff629f3c17171a4f65
  Author: Randy Dunlap <rdunlap@infradead.org>
  Date:   Sun Oct 26 19:14:06 2014 -0700
 =20
      skbuff.h: fix kernel-doc warning for headers_end
     =20
      Fix kernel-doc warning in <linux/skbuff.h> by making both headers_sta=
rt
      and headers_end private fields.
     =20
      Warning(..//include/linux/skbuff.h:654): No description found for par=
ameter 'headers_end[0]'
     =20
      Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 99d881f993f066c75059d24e44c74f7a3fc199bc
  Author: Vince Bridgers <vbridger@opensource.altera.com>
  Date:   Sun Oct 26 14:22:24 2014 -0500
 =20
      net: phy: Add SGMII Configuration for Marvell 88E1145 Initialization
     =20
      Marvell phy 88E1145 configuration & initialization was missing a case
      for initializing SGMII mode. This patch adds that case.
     =20
      Signed-off-by: Vince Bridgers <vbridger@opensource.altera.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 47276fcc2d542e7b15e384c08b1709c1921b06c1
  Author: Mugunthan V N <mugunthanvnm@ti.com>
  Date:   Fri Oct 24 18:51:33 2014 +0530
 =20
      drivers: net:cpsw: fix probe_dt when only slave 1 is pinned out
     =20
      when slave 0 has no phy and slave 1 connected to phy, driver probe wi=
ll
      fail as there is no phy id present for slave 0 device tree, so contin=
uing
      even though no phy-id found, also moving mac-id read later to ensure
      mac-id is read from device tree even when phy-id entry in not found.
     =20
      Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 25946f20b775f5c630d4326dd7a7f1df0576eb57
  Merge: 3923d68 99c8140
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 15:30:15 2014 -0400
 =20
      Merge tag 'master-2014-10-27' of git://git.kernel.org/pub/scm/linux/k=
ernel/git/linville/wireless
     =20
      John W. Linville says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      pull request: wireless 2014-10-28
     =20
      Please pull this batch of fixes intended for the 3.18 stream!
     =20
      For the mac80211 bits, Johannes says:
     =20
      "Here are a few fixes for the wireless stack: one fixes the
      RTS rate, one for a debugfs file, one to return the correct
      channel to userspace, a sanity check for a userspace value
      and the remaining two are just documentation fixes."
     =20
      For the iwlwifi bits, Emmanuel says:
     =20
      "I revert here a patch that caused interoperability issues.
      dvm gets a fix for a bug that was reported by many users.
      Two minor fixes for BT Coex and platform power fix that helps
      reducing latency when the PCIe link goes to low power states."
     =20
      In addition...
     =20
      Felix Fietkau adds a couple of ath code fixes related to regulatory
      rule enforcement.
     =20
      Hauke Mehrtens fixes a build break with bcma when CONFIG_OF_ADDRESS
      is not set.
     =20
      Karsten Wiese provides a trio of minor fixes for rtl8192cu.
     =20
      Kees Cook prevents a potential information leak in rtlwifi.
     =20
      Larry Finger also brings a trio of minor fixes for rtlwifi.
     =20
      Rafa=C5=82 Mi=C5=82ecki adds a device ID to the bcma bus driver.
     =20
      Rickard Strandqvist offers some strn* -> strl* changes in brcmfmac
      to eliminate non-terminated string issues.
     =20
      Sujith Manoharan avoids some ath9k stalls by enabling HW queue contro=
l
      only for MCC.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3923d68dc05033aa843b67d73110a6d402ac6e14
  Merge: f89b775 c146b77
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 15:28:30 2014 -0400
 =20
      Merge branch 'dsa-net'
     =20
      Andrew Lunn says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      DSA tagging mismatches
     =20
      The second patch is a fix, which should be applied to -rc. It is
      possible to get a DSA configuration which does not work. The patch
      stops this happening.
     =20
      The first patch detects this situation, and errors out the probe of
      DSA, making it more obvious something is wrong. It is not required to
      apply it -rc.
     =20
      v2 fixes the use case pointed out by Florian, that a switch driver
      may use DSA_TAG_PROTO_NONE which the patch did not correctly handle.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c146b7788e5721ec15bc0197bedf75849508e7ea
  Author: Andrew Lunn <andrew@lunn.ch>
  Date:   Fri Oct 24 23:44:05 2014 +0200
 =20
      dsa: mv88e6171: Fix tagging protocol/Kconfig
     =20
      The mv88e6171 can support two different tagging protocols, DSA and
      EDSA. The switch driver structure only allows one protocol to be
      enumerated, and DSA was chosen. However the Kconfig entry ensures the
      EDSA tagging code is built. With a minimal configuration, we then end
      up with a mismatch. The probe is successful, EDSA tagging is used, bu=
t
      the switch is configured for DSA, resulting in mangled packets.
     =20
      Change the switch driver structure to enumerate EDSA, fixing the
      mismatch.
     =20
      Signed-off-by: Andrew Lunn <andrew@lunn.ch>
      Fixes: 42f272539487 ("net: DSA: Marvell mv88e6171 switch driver")
      Acked-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ae439286a0dec99cc8029868243689b5b5f3ff75
  Author: Andrew Lunn <andrew@lunn.ch>
  Date:   Fri Oct 24 23:44:04 2014 +0200
 =20
      net: dsa: Error out on tagging protocol mismatches
     =20
      If there is a mismatch between enabled tagging protocols and the
      protocol the switch supports, error out, rather than continue with a
      situation which is unlikely to work.
     =20
      Signed-off-by: Andrew Lunn <andrew@lunn.ch>
      cc: alexander.h.duyck@intel.com
      Acked-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3d53666b40007b55204ee8890618da79a20c9940
  Author: Alex Gartrell <agartrell@fb.com>
  Date:   Mon Oct 6 08:46:19 2014 -0700
 =20
      ipvs: Avoid null-pointer deref in debug code
     =20
      Use daddr instead of reaching into dest.
     =20
      Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: Alex Gartrell <agartrell@fb.com>
      Signed-off-by: Simon Horman <horms@verge.net.au>
 =20
  commit f89b7755f517cdbb755d7543eef986ee9d54e654
  Author: Alexei Starovoitov <ast@plumgrid.com>
  Date:   Thu Oct 23 18:41:08 2014 -0700
 =20
      bpf: split eBPF out of NET
     =20
      introduce two configs:
      - hidden CONFIG_BPF to select eBPF interpreter that classic socket fi=
lters
        depend on
      - visible CONFIG_BPF_SYSCALL (default off) that tracing and sockets c=
an use
     =20
      that solves several problems:
      - tracing and others that wish to use eBPF don't need to depend on NE=
T.
        They can use BPF_SYSCALL to allow loading from userspace or select =
BPF
        to use it directly from kernel in NET-less configs.
      - in 3.18 programs cannot be attached to events yet, so don't force i=
t on
      - when the rest of eBPF infra is there in 3.19+, it's still useful to
        switch it off to minimize kernel size
     =20
      bloat-o-meter on x64 shows:
      add/remove: 0/60 grow/shrink: 0/2 up/down: 0/-15601 (-15601)
     =20
      tested with many different config combinations. Hopefully didn't miss=
 anything.
     =20
      Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
      Acked-by: Daniel Borkmann <dborkman@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8ae3c911b9efcca653c552a9c74957a6cb04a87d
  Merge: 5d26b1f 3bb0626
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 27 19:00:16 2014 -0400
 =20
      Merge branch 'cxgb4-net'
     =20
      Anish Bhatt says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      cxgb4 : DCBx fixes for apps/host lldp agents
     =20
      This patchset  contains some minor fixes for cxgb4 DCBx code. Chiefly=
, cxgb4
      was not cleaning up any apps added to kernel app table when link was =
lost.
      Disabling DCBx in firmware would automatically set DCBx state to host=
-managed
      and enabled, we now wait for an explicit enable call from an lldp age=
nt instead
     =20
      First patch was originally sent to net-next, but considering it appli=
es to
      correcting behaviour of code already in net, I think it qualifies as =
a bug fix.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3bb062613b1ecbd0c388106f61344d699f7859ec
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Thu Oct 23 14:37:31 2014 -0700
 =20
      cxgb4 : Handle dcb enable correctly
     =20
      Disabling DCBx in firmware automatically enables DCBx for control via=
 host
      lldp agents. Wait for an explicit setstate call from an lldp agents t=
o enable
       DCBx instead.
     =20
      Fixes: 76bcb31efc06 ("cxgb4 : Add DCBx support codebase and dcbnl_ops=
")
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 2376c879b80c83424a3013834be97fb9fe2d4180
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Thu Oct 23 14:37:30 2014 -0700
 =20
      cxgb4 : Improve handling of DCB negotiation or loss thereof
     =20
      Clear out any DCB apps we might have added to kernel table when we lo=
se DCB
      sync (or IEEE equivalent event). These were previously left behind an=
d not
      cleaned up correctly. IEEE allows individual components to work indep=
endently,
       so improve check for IEEE completion by specifying individual compon=
ents.
     =20
      Fixes: 10b0046685ab ("cxgb4: IEEE fixes for DCBx state machine")
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5d26b1f50a610fb28700cdc3446590495a5f607c
  Merge: 93a35f5 7965ee9
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 27 18:47:40 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      Netfilter fixes for net
     =20
      The following patchset contains Netfilter fixes for your net tree,
      they are:
     =20
      1) Allow to recycle a TCP port in conntrack when the change role from
         server to client, from Marcelo Leitner.
     =20
      2) Fix possible off by one access in ip_set_nfnl_get_byindex(), patch
         from Dan Carpenter.
     =20
      3) alloc_percpu returns NULL on error, no need for IS_ERR() in nf_tab=
les
         chain statistic updates. From Sabrina Dubroca.
     =20
      4) Don't compile ip options in bridge netfilter, this mangles the pac=
ket
         and bridge should not alter layer >=3D 3 headers when forwarding p=
ackets.
         Patch from Herbert Xu and tested by Florian Westphal.
     =20
      5) Account the final NLMSG_DONE message when calculating the size of =
the
         nflog netlink batches. Patch from Florian Westphal.
     =20
      6) Fix a possible netlink attribute length overflow with large packet=
s.
         Again from Florian Westphal.
     =20
      7) Release the skbuff if nfnetlink_log fails to put the final
         NLMSG_DONE message. This fixes a leak on error. This shouldn't eve=
r
         happen though, otherwise this means we miscalculate the netlink ba=
tch
         size, so spot a warning if this ever happens so we can track down =
the
         problem. This patch from Houcheng Lin.
     =20
      8) Look at the right list when recycling targets in the nft_compat,
         patch from Arturo Borrero.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7965ee93719921ea5978f331da653dfa2d7b99f5
  Author: Arturo Borrero <arturo.borrero.glez@gmail.com>
  Date:   Sun Oct 26 12:22:40 2014 +0100
 =20
      netfilter: nft_compat: fix wrong target lookup in nft_target_select_o=
ps()
     =20
      The code looks for an already loaded target, and the correct list to =
search
      is nft_target_list, not nft_match_list.
     =20
      Signed-off-by: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com=
>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 99c814066e75d09e6a38574c6c395f022a04b730
  Merge: fad1dbc 11b2357
  Author: John W. Linville <linville@tuxdriver.com>
  Date:   Mon Oct 27 13:38:15 2014 -0400
 =20
      Merge tag 'mac80211-for-john-2014-10-23' of git://git.kernel.org/pub/=
scm/linux/kernel/git/jberg/mac80211
     =20
      Johannes Berg <johannes@sipsolutions.net> says:
     =20
      "Here are a few fixes for the wireless stack: one fixes the
      RTS rate, one for a debugfs file, one to return the correct
      channel to userspace, a sanity check for a userspace value
      and the remaining two are just documentation fixes."
     =20
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit fad1dbc8efb4e51e121c745a99c0fb22b420a5c6
  Merge: 0805420 7f2ac8f
  Author: John W. Linville <linville@tuxdriver.com>
  Date:   Mon Oct 27 13:35:59 2014 -0400
 =20
      Merge tag 'iwlwifi-for-john-2014-10-23' of git://git.kernel.org/pub/s=
cm/linux/kernel/git/iwlwifi/iwlwifi-fixes
     =20
      Emmanuel Grumbach <egrumbach@gmail.com> says:
     =20
      "I revert here a patch that caused interoperability issues.
      dvm gets a fix for a bug that was reported by many users.
      Two minor fixes for BT Coex and platform power fix that helps
      reducing latency when the PCIe link goes to low power states."
     =20
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 93a35f59f1b13a02674877e3efdf07ae47e34052
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 23 06:30:30 2014 -0700
 =20
      net: napi_reuse_skb() should check pfmemalloc
     =20
      Do not reuse skb if it was pfmemalloc tainted, otherwise
      future frame might be dropped anyway.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit aa9c5579153535fb317a9d34c7d8eaf02b7ef4cd
  Merge: b71e821 bf1bac5
  Author: David S. Miller <davem@davemloft.net>
  Date:   Sun Oct 26 22:46:08 2014 -0400
 =20
      Merge branch 'mellanox'
     =20
      Eli Cohen says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      irq sync fixes
     =20
      This two patch series fixes a race where an interrupt handler could a=
ccess a
      freed memory.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit bf1bac5b7882daa41249f85fbc97828f0597de5c
  Author: Eli Cohen <eli@dev.mellanox.co.il>
  Date:   Thu Oct 23 15:57:27 2014 +0300
 =20
      net/mlx4_core: Call synchronize_irq() before freeing EQ buffer
     =20
      After moving the EQ ownership to software effectively destroying it, =
call
      synchronize_irq() to ensure that any handler routines running on othe=
r CPU
      cores finish execution. Only then free the EQ buffer.
      The same thing is done when we destroy a CQ which is one of the sourc=
es
      generating interrupts. In the case of CQ we want to avoid completion =
handlers
      on a CQ that was destroyed. In the case we do the same to avoid recei=
ving
      asynchronous events after the EQ has been destroyed and its buffers f=
reed.
     =20
      Signed-off-by: Eli Cohen <eli@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 96e4be06cbfcb8c9c2da7c77bacce0e56b581c0b
  Author: Eli Cohen <eli@dev.mellanox.co.il>
  Date:   Thu Oct 23 15:57:26 2014 +0300
 =20
      net/mlx5_core: Call synchronize_irq() before freeing EQ buffer
     =20
      After destroying the EQ, the object responsible for generating interr=
upts, call
      synchronize_irq() to ensure that any handler routines running on othe=
r CPU
      cores finish execution. Only then free the EQ buffer. This patch solv=
es a very
      rare case when we get panic on driver unload.
      The same thing is done when we destroy a CQ which is one of the sourc=
es
      generating interrupts. In the case of CQ we want to avoid completion =
handlers
      on a CQ that was destroyed. In the case we do the same to avoid recei=
ving
      asynchronous events after the EQ has been destroyed and its buffers f=
reed.
     =20
      Signed-off-by: Eli Cohen <eli@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b71e821de50f0ff92f10f33064ee1713e9014158
  Author: Geert Uytterhoeven <geert@linux-m68k.org>
  Date:   Thu Oct 23 10:25:53 2014 +0200
 =20
      drivers: net: xgene: Rewrite buggy loop in xgene_enet_ecc_init()
     =20
      drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function =E2=80=
=98xgene_enet_ecc_init=E2=80=99:
      drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:126: warning: =E2=
=80=98data=E2=80=99 may be used uninitialized in this function
     =20
      Depending on the arbitrary value on the stack, the loop may terminate
      too early, and cause a bogus -ENODEV failure.
     =20
      Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 013f6579c6e4f9517127a176bfc37bbac0b766cb
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Wed Oct 22 20:06:29 2014 -0700
 =20
      i40e: _MASK vs _SHIFT typo in i40e_handle_mdd_event()
     =20
      We accidentally mask by the _SHIFT variable.  It means that "event" i=
s
      always zero.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Tested-by: Jim Young <jamesx.m.young@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit fe0ca7328d03d36aafecebb3af650e1bb2841c20
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Wed Oct 22 19:43:46 2014 -0700
 =20
      macvlan: fix a race on port dismantle and possible skb leaks
     =20
      We need to cancel the work queue after rcu grace period,
      otherwise it can be rescheduled by incoming packets.
     =20
      We need to purge queue if some skbs are still in it.
     =20
      We can use __skb_queue_head_init() variant in
      macvlan_process_broadcast()
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 412ca1550cbec ("macvlan: Move broadcasts into a work queue")
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 349ce993ac706869d553a1816426d3a4bfda02b1
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 23 12:58:58 2014 -0700
 =20
      tcp: md5: do not use alloc_percpu()
     =20
      percpu tcp_md5sig_pool contains memory blobs that ultimately
      go through sg_set_buf().
     =20
      -> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
     =20
      This requires that whole area is in a physically contiguous portion
      of memory. And that @buf is not backed by vmalloc().
     =20
      Given that alloc_percpu() can use vmalloc() areas, this does not
      fit the requirements.
     =20
      Replace alloc_percpu() by a static DEFINE_PER_CPU() as tcp_md5sig_poo=
l
      is small anyway, there is no gain to dynamically allocate it.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 765cf9976e93 ("tcp: md5: remove one indirection level in tcp_m=
d5sig_pool")
      Reported-by: Crestez Dan Leonard <cdleonard@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 4cc40af08032a513e2e68fa6d7818b77179a86af
  Merge: 5345c1d ecf08d2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Sat Oct 25 14:15:25 2014 -0400
 =20
      Merge branch 'xen-netback'
     =20
      David Vrabel says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      xen-netback: guest Rx queue drain and stall fixes
     =20
      This series fixes two critical xen-netback bugs.
     =20
      1. Netback may consume all of host memory by queuing an unlimited
         number of skb on the internal guest Rx queue.  This behaviour is
         guest triggerable.
     =20
      2. Carrier flapping under high traffic rates which reduces
         performance.
     =20
      The first patch is a prerequite.  Removing support for frontends with
      feature-rx-notify makes it easier to reason about the correctness of
      netback since it no longer has to support this outdated and broken
      mode.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:55 2014 +0100
 =20
      xen-netback: reintroduce guest Rx stall detection
     =20
      If a frontend not receiving packets it is useful to detect this and
      turn off the carrier so packets are dropped early instead of being
      queued and drained when they expire.
     =20
      A to-guest queue is stalled if it doesn't have enough free slots for =
a
      an extended period of time (default 60 s).
     =20
      If at least one queue is stalled, the carrier is turned off (in the
      expectation that the other queues will soon stall as well).  The
      carrier is only turned on once all queues are ready.
     =20
      When the frontend connects, all the queues start in the stalled state
      and only become ready once the frontend queues enough Rx requests.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Reviewed-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f48da8b14d04ca87ffcffe68829afd45f926ec6a
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:54 2014 +0100
 =20
      xen-netback: fix unlimited guest Rx internal queue and carrier flappi=
ng
     =20
      Netback needs to discard old to-guest skb's (guest Rx queue drain) an=
d
      it needs detect guest Rx stalls (to disable the carrier so packets ar=
e
      discarded earlier), but the current implementation is very broken.
     =20
      1. The check in hard_start_xmit of the slot availability did not
         consider the number of packets that were already in the guest Rx
         queue.  This could allow the queue to grow without bound.
     =20
         The guest stops consuming packets and the ring was allowed to fill
         leaving S slot free.  Netback queues a packet requiring more than =
S
         slots (ensuring that the ring stays with S slots free).  Netback
         queue indefinately packets provided that then require S or fewer
         slots.
     =20
      2. The Rx stall detection is not triggered in this case since the
         (host) Tx queue is not stopped.
     =20
      3. If the Tx queue is stopped and a guest Rx interrupt occurs, netbac=
k
         will consider this an Rx purge event which may result in it taking
         the carrier down unnecessarily.  It also considers a queue with
         only 1 slot free as unstalled (even though the next packet might
         not fit in this).
     =20
      The internal guest Rx queue is limited by a byte length (to 512 Kib,
      enough for half the ring).  The (host) Tx queue is stopped and starte=
d
      based on this limit.  This sets an upper bound on the amount of memor=
y
      used by packets on the internal queue.
     =20
      This allows the estimatation of the number of slots for an skb to be
      removed (it wasn't a very good estimate anyway).  Instead, the guest
      Rx thread just waits for enough free slots for a maximum sized packet=
.
     =20
      skbs queued on the internal queue have an 'expires' time (set to the
      current time plus the drain timeout).  The guest Rx thread will detec=
t
      when the skb at the head of the queue has expired and discard expired
      skbs.  This sets a clear upper bound on the length of time an skb can
      be queued for.  For a guest being destroyed the maximum time needed t=
o
      wait for all the packets it sent to be dropped is still the drain
      timeout (10 s) since it will not be sending new packets.
     =20
      Rx stall detection is reintroduced in a later commit.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Reviewed-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit bc96f648df1bbc2729abbb84513cf4f64273a1f1
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:53 2014 +0100
 =20
      xen-netback: make feature-rx-notify mandatory
     =20
      Frontends that do not provide feature-rx-notify may stall because
      netback depends on the notification from frontend to wake the guest R=
x
      thread (even if can_queue is false).
     =20
      This could be fixed but feature-rx-notify was introduced in 2006 and =
I
      am not aware of any frontends that do not implement this.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Acked-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5345c1d417c1b0caf46fd2766d16bb4357a347d8
  Author: Richard Cochran <richardcochran@gmail.com>
  Date:   Wed Oct 22 21:35:15 2014 +0200
 =20
      ptp: restore the makefile for building the test program.
     =20
      This patch brings back the makefile called testptp.mk which was remov=
ed
      in commit adb19fb66eee (Documentation: add makefiles for more targets=
).
     =20
      While the idea of that commit was to improve build coverage of the
      examples, the new Makefile is unable to cross compile the testptp pro=
gram.
      In contrast, the deleted makefile was able to do this just fine.
     =20
      This patch fixes the regression by restoring the original makefile.
     =20
      Signed-off-by: Richard Cochran <richardcochran@gmail.com>
      Acked-by: Peter Foley <pefoley2@pefoley.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b51d3fa364885a2c1e1668f88776c67c95291820
  Author: Houcheng Lin <houcheng@gmail.com>
  Date:   Thu Oct 23 10:36:08 2014 +0200
 =20
      netfilter: nf_log: release skbuff on nlmsg put failure
     =20
      The kernel should reserve enough room in the skb so that the DONE
      message can always be appended.  However, in case of e.g. new attribu=
te
      erronously not being size-accounted for, __nfulnl_send() will still
      try to put next nlmsg into this full skbuf, causing the skb to be stu=
ck
      forever and blocking delivery of further messages.
     =20
      Fix issue by releasing skb immediately after nlmsg_put error and
      WARN() so we can track down the cause of such size mismatch.
     =20
      [ fw@strlen.de: add tailroom/len info to WARN ]
     =20
      Signed-off-by: Houcheng Lin <houcheng@gmail.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit c1e7dc91eed0ed1a51c9b814d648db18bf8fc6e9
  Author: Florian Westphal <fw@strlen.de>
  Date:   Thu Oct 23 10:36:07 2014 +0200
 =20
      netfilter: nfnetlink_log: fix maximum packet length logged to userspa=
ce
     =20
      don't try to queue payloads > 0xffff - NLA_HDRLEN, it does not work.
      The nla length includes the size of the nla struct, so anything large=
r
      results in u16 integer overflow.
     =20
      This patch is similar to
      9cefbbc9c8f9abe (netfilter: nfnetlink_queue: cleanup copy_range usage=
).
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 9dfa1dfe4d5e5e66a991321ab08afe69759d797a
  Author: Florian Westphal <fw@strlen.de>
  Date:   Thu Oct 23 10:36:06 2014 +0200
 =20
      netfilter: nf_log: account for size of NLMSG_DONE attribute
     =20
      We currently neither account for the nlattr size, nor do we consider
      the size of the trailing NLMSG_DONE when allocating nlmsg skb.
     =20
      This can result in nflog to stop working, as __nfulnl_send() re-tries
      sending forever if it failed to append NLMSG_DONE (which will never
      work if buffer is not large enough).
     =20
      Reported-by: Houcheng Lin <houcheng@gmail.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7677e86843e2136a9b05549a9ca47d4f744565b6
  Author: Herbert Xu <herbert@gondor.apana.org.au>
  Date:   Sat Oct 4 22:18:02 2014 +0800
 =20
      bridge: Do not compile options in br_parse_ip_options
     =20
      Commit 462fb2af9788a82a534f8184abfde31574e1cfa0
     =20
      	bridge : Sanitize skb before it enters the IP stack
     =20
      broke when IP options are actually used because it mangles the
      skb as if it entered the IP stack which is wrong because the
      bridge is supposed to operate below the IP stack.
     =20
      Since nobody has actually requested for parsing of IP options
      this patch fixes it by simply reverting to the previous approach
      of ignoring all IP options, i.e., zeroing the IPCB.
     =20
      If and when somebody who uses IP options and actually needs them
      to be parsed by the bridge complains then we can revisit this.
     =20
      Reported-by: David Newall <davidn@davidnewall.com>
      Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
      Tested-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7f2ac8fb31896c9fb70dbd2a2e6642b79996fc13
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Thu Oct 23 08:53:21 2014 +0300
 =20
      iwlwifi: pcie: fix polling in various places
     =20
      iwl_poll_bit may return a strictly positive value when the
      poll doesn't match on the first try.
      This was caught when WoWLAN started failing upon resume
      even if the poll_bit actually succeeded.
     =20
      Also change a wrong print. If we reach the end of
      iwl_pcie_prepare_card_hw, it means that we couldn't
      get the devices.
     =20
      Reviewed-by: Johannes Berg <johannes.berg@intel.com>
      Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 1ffde699aae127e7abdb98dbdedc2cc6a973a1a1
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Oct 20 08:29:55 2014 +0300
 =20
      Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate"
     =20
      This reverts commit aa11bbf3df026d6b1c6b528bef634fd9de7c2619.
      This commit was causing connection issues and is not needed
      if IWL_MVM_RS_RSSI_BASED_INIT_RATE is set to false by default.
     =20
      Regardless of the issues mentioned above, this patch added the
      following WARNING:
     =20
      WARNING: CPU: 0 PID: 3946 at drivers/net/wireless/iwlwifi/mvm/tx.c:19=
0 iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]()
      Got an HT rate for a non data frame 0x8
      CPU: 0 PID: 3946 Comm: wpa_supplicant Tainted: G           O   3.17.0=
+ #6
      Hardware name: LENOVO 20ANCTO1WW/20ANCTO1WW, BIOS GLET71WW (2.25 ) 07=
/02/2014
       0000000000000009 ffffffff814fa911 ffff8804288db8f8 ffffffff81064f52
       0000000000001808 ffff8804288db948 ffff88040add8660 ffff8804291b5600
       0000000000000000 ffffffff81064fb7 ffffffffa07b73d0 0000000000000020
      Call Trace:
       [<ffffffff814fa911>] ? dump_stack+0x41/0x51
       [<ffffffff81064f52>] ? warn_slowpath_common+0x72/0x90
       [<ffffffff81064fb7>] ? warn_slowpath_fmt+0x47/0x50
       [<ffffffffa07a39ea>] ? iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]
       [<ffffffffa07a3cf8>] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm]
       [<ffffffffa079cb9b>] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm]
       [<ffffffffa0746ce9>] ? __ieee80211_tx+0x2b9/0x3c0 [mac80211]
       [<ffffffffa07492f3>] ? ieee80211_tx+0xb3/0x100 [mac80211]
       [<ffffffffa0749c49>] ? ieee80211_subif_start_xmit+0x459/0xca0 [mac80=
211]
       [<ffffffff814116e7>] ? dev_hard_start_xmit+0x337/0x5f0
       [<ffffffff81430d46>] ? sch_direct_xmit+0x96/0x1f0
       [<ffffffff81411ba3>] ? __dev_queue_xmit+0x203/0x4f0
       [<ffffffff8142f670>] ? ether_setup+0x70/0x70
       [<ffffffff814e96a1>] ? packet_sendmsg+0xf81/0x1110
       [<ffffffff8140625c>] ? skb_free_datagram+0xc/0x40
       [<ffffffff813f7538>] ? sock_sendmsg+0x88/0xc0
       [<ffffffff813f7274>] ? move_addr_to_kernel.part.20+0x14/0x60
       [<ffffffff811c47c2>] ? __inode_wait_for_writeback+0x62/0xb0
       [<ffffffff813f7a91>] ? SYSC_sendto+0xf1/0x180
       [<ffffffff813f88f9>] ? __sys_recvmsg+0x39/0x70
       [<ffffffff8150066d>] ? system_call_fastpath+0x1a/0x1f
      ---[ end trace cc19a150d311fc63 ]---
     =20
      which was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=
=3D85691
     =20
      CC: <stable@vger.kernel.org> [3.13+]
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit a0855054e59b0c5b2b00237fdb5147f7bcc18efb
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Sun Oct 5 09:11:14 2014 +0300
 =20
      iwlwifi: dvm: drop non VO frames when flushing
     =20
      When mac80211 wants to ensure that a frame is sent, it calls
      the flush() callback. Until now, iwldvm implemented this by
      waiting that all the frames are sent (ACKed or timeout).
      In case of weak signal, this can take a significant amount
      of time, delaying the next connection (in case of roaming).
      Many users have reported that the flush would take too long
      leading to the following error messages to be printed:
     =20
      iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2
      iwlwifi 0000:03:00.0: Current SW read_ptr 161 write_ptr 201
      iwl data: 00000000: 00 00 00 00 00 00 00 00 fe ff 01 00 00 00 00 00
      [snip]
      iwlwifi 0000:03:00.0: FH TRBs(0) =3D 0x00000000
      [snip]
      iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x000=
0 [9,9]
      [snip]
     =20
      Instead of waiting for these packets, simply drop them. This
      significantly improves the responsiveness of the network.
      Note that all the queues are flushed, but the VO one. This
      is not typically used by the applications and it likely
      contains management frames that are useful for connection
      or roaming.
     =20
      This bug is tracked here:
      https://bugzilla.kernel.org/show_bug.cgi?id=3D56581
     =20
      But it is duplicated in distributions' trackers.
      A simple search in Ubuntu's database led to these bugs:
     =20
      https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1270808
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305406
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356236
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1360597
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361809
     =20
      Cc: <stable@vger.kernel.org>
      Depends-on: 77be2c54c5bd ("mac80211: add vif to flush call")
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit a6cc5163149532734b84c86cbffa4994e527074b
  Author: Matti Gottlieb <matti.gottlieb@intel.com>
  Date:   Mon Sep 29 11:46:04 2014 +0300
 =20
      iwlwifi: mvm: ROC - bug fixes around time events and locking
     =20
      Don't add the time event to the list. We added it several
      times the same time event, which leads to an infinite loop
      when walking the list.
     =20
      Since we (currently) don't support more than one ROC for STA
      vif at a time, enforce this and don't add the time event
      to any list.
     =20
      We were also missing the locking of the mutex which led to
      a lockdep splat - fix that.
     =20
      Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 79b7a69d730180d8bf535e52fe2b4f3dd5904007
  Author: Haim Dreyfuss <haim.dreyfuss@intel.com>
  Date:   Sun Sep 14 12:40:00 2014 +0300
 =20
      iwlwifi: mvm: Add tx power condition to bss_info_changed_ap_ibss
     =20
      The tx power should be limited from many reasons.
      currently, setting the tx power is available by the mvm only for
      station interface. Adding the tx power condition to
      bss_info_changed_ap_ibss make it available also for AP.
     =20
      Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 3856b78c1be32a2afe0618c7a84e05ff8c03cf10
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Sep 22 12:03:41 2014 +0300
 =20
      iwlwifi: mvm: BT coex - fix BT prio for probe requests
     =20
      The probe requests sent during scan must get BT prio 3.
      Fix that.
     =20
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit d14b28fd2c61af0bf310230472e342864d799c98
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Sep 22 16:12:24 2014 +0300
 =20
      iwlwifi: mvm: BT Coex - update the MPLUT Boost register value
     =20
      Cc: <stable@vger.kernel.org> [3.16+]
      Fixes: 2adc8949efab ("iwlwifi: mvm: BT Coex - fix boost register / LU=
T values")
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 405b7338abc5ceac4a420ce7f49cc9b530d4e78b
  Author: Liad Kaufman <liad.kaufman@intel.com>
  Date:   Tue Sep 23 15:15:17 2014 +0300
 =20
      iwlwifi: 8000: fix string given to MODULE_FIRMWARE
     =20
      I changed the string but forgot to update the fix also to
      MODULE_FIRMWARE().
     =20
      Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 9180ac50716a097a407c6d7e7e4589754a922260
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Tue Sep 23 23:02:41 2014 +0300
 =20
      iwlwifi: configure the LTR
     =20
      The LTR is the handshake between the device and the root
      complex about the latency allowed when the bus exits power
      save. This configuration was missing and this led to high
      latency in the link power up. The end user could experience
      high latency in the network because of this.
     =20
      Cc: <stable@vger.kernel.org> [3.10+]
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 08054200117a95afc14c3d2ed3a38bf4e345bf78
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Thu Oct 23 11:27:09 2014 -0500
 =20
      rtlwifi: Add check for get_btc_status callback
     =20
      Drivers that do not use the get_btc_status() callback may not define =
a
      dummy routine. The caller needs to check before making the call.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
      Cc: Thadeu Cascardo <cascardo@cascardo.eti.br>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 763254516187015cb5b391553af35c6ed1f4bb36
  Author: Felix Fietkau <nbd@openwrt.org>
  Date:   Wed Oct 22 18:17:35 2014 +0200
 =20
      ath9k_common: always update value in ath9k_cmn_update_txpow
     =20
      In some cases the limit may be the same as reg->power_limit, but the
      actual value that the hardware uses is not up to date. In that case, =
a
      wrong value for current tx power is tracked internally.
      Fix this by unconditionally updating it.
     =20
      Signed-off-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 4f2b244c7d5b81ce4f0c6c0382f3a3b7c2dbec1c
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:34 2014 +0200
 =20
      rtl8192cu: Prevent Ooops under rtl92c_set_fw_rsvdpagepkt
     =20
      rtl92c_set_fw_rsvdpagepkt is used by rtl8192cu and its pci sibling rt=
l8192ce.
      rtl_cmd_send_packet crashes when called inside rtl8192cu because it w=
orks on
      memory allocated only by rtl8192ce.
      Fix the crash by calling a dummy function when used in rtl8192cu.
      Comparision with the realtek vendor driver makes me think, something =
is missing in
      the dummy function.
      Short test as WPA2 station show good results connected to an 802.11g =
basestation.
      Traffic stops after few MBytes as WPA2 station connected to an 802.11=
n basestation.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit cefe3dfdb9f5f498cae9871f7e52800f5e22c614
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:33 2014 +0200
 =20
      rtl8192cu: Call ieee80211_register_hw from rtl_usb_probe
     =20
      In a previous patch the call to ieee80211_register_hw was moved from =
the
      load firmware callback to the rtl_pci_probe only.
      rt8192cu also uses this callback. Currently it doesnt create a wlan%d=
 device.
      Fill in the call to ieee80211_register_hw in rtl_usb_probe.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit b2d624a5810203a1a8b7735e1ec5685109b22fc3
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:32 2014 +0200
 =20
      rtl8192cu: Fix for rtlwifi's bluetooth coexist functionality
     =20
      Initialize function pointer with a function indicating bt coexist is =
not there.
      Prevents Ooops.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 94e05900770c0abe31200881df93e41d296fe8bd
  Author: Felix Fietkau <nbd@openwrt.org>
  Date:   Wed Oct 22 15:27:53 2014 +0200
 =20
      ath: use CTL region from cfg80211 if unset in EEPROM
     =20
      Many AP devices do not have the proper regulatory domain programmed i=
n
      EEPROM. Instead they expect the software to set the appropriate regio=
n.
      For these devices, the country code defaults to US, and the driver us=
es
      the US CTL tables as well.
      On devices bought in Europe this can lead to tx power being set too h=
igh
      on the band edges, even if the cfg80211 regdomain is set correctly.
      Fix this issue by taking into account the DFS region, but only when t=
he
      EEPROM regdomain is set to default.
     =20
      Signed-off-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit d514aefb8ce89562ef2d7dcddc530e5de6287c4b
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Tue Oct 21 10:52:51 2014 -0500
 =20
      rtlwifi: rtl8821ae: Fix possible array overrun
     =20
      The kbuild test robot reported a possible array overrun. The affected=
 code
      checks for overruns, but fails to take the steps necessary to fix the=
m.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 868caae3fe2e35e2353d86af95e03eeaa9439d97
  Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Date:   Tue Oct 21 19:23:02 2014 +0530
 =20
      ath9k: Enable HW queue control only for MCC
     =20
      Enabling HW queue control for normal (non-mcc) mode
      causes problems with queue management, resulting
      in traffic stall. Since it is mainly required for
      fairness in MCC mode, disable it for the general case.
     =20
      Bug: https://dev.openwrt.org/ticket/18164
     =20
      Cc: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 598a0df07fc6c4642f9b0497cef1233e41d4c987
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Oct 20 14:57:08 2014 -0700
 =20
      rtlwifi: prevent format string usage from leaking
     =20
      Use "%s" in the workqueue allocation to make sure the rtl_hal_cfg nam=
e
      can never accidentally leak information via a format string.
     =20
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 34b6d4299923ec9101bbf364440cee36420b3fc0
  Author: Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
  Date:   Wed Oct 15 07:51:44 2014 +0200
 =20
      bcma: add another PCI ID of device with BCM43228
     =20
      It was found attached to the BCM47081A0 SoC. Log:
      bcma: bus0: Found chip with id 43228, rev 0x00 and package 0x08
     =20
      Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 59dfdd92288e55bed374309a9944c3a95b4e13c9
  Author: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
  Date:   Sun Oct 12 13:42:14 2014 +0200
 =20
      brcmfmac: dhd_sdio.c: Cleaning up missing null-terminate in conjuncti=
on with strncpy
     =20
      Replacing strncpy with strlcpy to avoid strings that lacks null termi=
nate.
      And changed from using strncat to strlcat to simplify code.
     =20
      Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigit=
al.se>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 47481d977cb2987ab363202c68a79ec1bccd357c
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Sat Oct 11 12:59:53 2014 -0500
 =20
      rtlwifi: rtl8192ee: Prevent log spamming for switch statements
     =20
      The driver logs a message when the default branch of switch statement=
s are
      taken. Such information is useful when debugging, but these log items=
 should
      not be seen for standard usage.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 78afe83c3b008e25123bd1be36ee4b6595e595d1
  Author: Hauke Mehrtens <hauke@hauke-m.de>
  Date:   Thu Oct 9 23:39:41 2014 +0200
 =20
      bcma: fix build when CONFIG_OF_ADDRESS is not set
     =20
      Commit 2101e533f41a ("bcma: register bcma as device tree driver")
      introduces a hard dependency on OF_ADDRESS into the bcma driver.
      OF_ADDRESS is specifically disabled for the sparc architecture.
      This results in the following error when building sparc64:allmodconfi=
g.
     =20
      drivers/bcma/main.c: In function 'bcma_of_find_child_device':
      drivers/bcma/main.c:150:3: error: implicit declaration of function 'o=
f_translate_address'
     =20
      Fixes: 2101e533f41a ("bcma: register bcma as device tree driver")
      Reported-by: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 942396b01989d54977120f3625e5ba31afe7a75c
  Author: Haiyang Zhang <haiyangz@microsoft.com>
  Date:   Wed Oct 22 13:47:18 2014 -0700
 =20
      hyperv: Fix the total_data_buflen in send path
     =20
      total_data_buflen is used by netvsc_send() to decide if a packet can =
be put
      into send buffer. It should also include the size of RNDIS message be=
fore the
      Ethernet frame. Otherwise, a messge with total size bigger than send_=
section_size
      may be copied into the send buffer, and cause data corruption.
     =20
      [Request to include this patch to the Stable branches]
     =20
      Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
      Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f765678e325b4ae3e2fbdb304fc2d5ee018aa860
  Merge: 81f35ff 55ca6bc
  Author: David S. Miller <davem@davemloft.net>
  Date:   Wed Oct 22 17:50:39 2014 -0400
 =20
      Merge branch 'amd-xgbe'
     =20
      Tom Lendacky says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      amd-xgbe: AMD XGBE driver fixes 2014-10-22
     =20
      The following series of patches includes fixes to the driver.
     =20
      - Properly handle feature changes via ethtool by using correctly size=
d
        variables
      - Perform proper napi packet counting and budget checking
     =20
      This patch series is based on net.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 55ca6bcd733b739d5667d48d7591899f376dcfb8
  Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Date:   Wed Oct 22 11:26:17 2014 -0500
 =20
      amd-xgbe: Fix napi Rx budget accounting
     =20
      Currently the amd-xgbe driver increments the packets processed counte=
r
      each time a descriptor is processed.  Since a packet can be represent=
ed
      by more than one descriptor incrementing the counter in this way is n=
ot
      appropriate.  Also, since multiple descriptors cause the budget check
      to be short circuited, sometimes the returned value from the poll
      function would be larger than the budget value resulting in a WARN_ON=
CE
      being triggered.
     =20
      Update the polling logic to properly account for the number of packet=
s
      processed and exit when the budget value is reached.
     =20
      Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 386f1c9650b7fe4849d2942bd42f41f0ca3aedfb
  Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Date:   Wed Oct 22 11:26:11 2014 -0500
 =20
      amd-xgbe: Properly handle feature changes via ethtool
     =20
      The ndo_set_features callback function was improperly using an unsign=
ed
      int to save the current feature value for features such as NETIF_F_RX=
CSUM.
      Since that feature is in the upper 32 bits of a 64 bit variable the
      result was always 0 making it not possible to actually turn off the
      hardware RX checksum support.  Change the unsigned int type to the
      netdev_features_t type in order to properly capture the current value
      and perform the proper operation.
     =20
      Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 81f35ffde0e95ee18de83646bbf93dda55d9cc8b
  Author: Philipp Zabel <p.zabel@pengutronix.de>
  Date:   Wed Oct 22 16:34:35 2014 +0200
 =20
      net: fec: ptp: fix NULL pointer dereference if ptp_clock is not set
     =20
      Since commit 278d24047891 (net: fec: ptp: Enable PPS output based on =
ptp clock)
      fec_enet_interrupt calls fec_ptp_check_pps_event unconditionally, whi=
ch calls
      into ptp_clock_event. If fep->ptp_clock is NULL, ptp_clock_event trie=
s to
      dereference the NULL pointer.
      Since on i.MX53 fep->bufdesc_ex is not set, fec_ptp_init is never cal=
led,
      and fep->ptp_clock is NULL, which reliably causes a kernel panic.
     =20
      This patch adds a check for fep->ptp_clock =3D=3D NULL in fec_enet_in=
terrupt.
     =20
      Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9e7ceb060754f134231f68cb29d5db31419fe1ed
  Author: Sathya Perla <sathya.perla@emulex.com>
  Date:   Wed Oct 22 21:42:01 2014 +0530
 =20
      net: fix saving TX flow hash in sock for outgoing connections
     =20
      The commit "net: Save TX flow hash in sock and set in skbuf on xmit"
      introduced the inet_set_txhash() and ip6_set_txhash() routines to cal=
culate
      and record flow hash(sk_txhash) in the socket structure. sk_txhash is=
 used
      to set skb->hash which is used to spread flows across multiple TXQs.
     =20
      But, the above routines are invoked before the source port of the con=
nection
      is created. Because of this all outgoing connections that just differ=
 in the
      source port get hashed into the same TXQ.
     =20
      This patch fixes this problem for IPv4/6 by invoking the the above ro=
utines
      after the source port is available for the socket.
     =20
      Fixes: b73c3d0e4("net: Save TX flow hash in sock and set in skbuf on =
xmit")
     =20
      Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
      Acked-by: Eric Dumazet <edumazet@google.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 789f202326640814c52f82e80cef3584d8254623
  Author: Li RongQing <roy.qing.li@gmail.com>
  Date:   Wed Oct 22 17:09:53 2014 +0800
 =20
      xfrm6: fix a potential use after free in xfrm6_policy.c
     =20
      pskb_may_pull() maybe change skb->data and make nh and exthdr pointer
      oboslete, so recompute the nd and exthdr
     =20
      Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8751b12cd93cc37337256f650e309b8364d40b35
  Author: LEROY Christophe <christophe.leroy@c-s.fr>
  Date:   Wed Oct 22 09:05:47 2014 +0200
 =20
      net: fs_enet: set back promiscuity mode after restart
     =20
      After interface restart (eg: after link disconnection/reconnection), =
the bridge
      function doesn't work anymore. This is due to the promiscuous mode be=
ing cleared
      by the restart.
     =20
      The mac-fcc already includes code to set the promiscuous mode back du=
ring the restart.
      This patch adds the same handling to mac-fec and mac-scc.
     =20
      Tested with bridge function on MPC885 with FEC.
     =20
      Reported-by: Germain Montoies <germain.montoies@c-s.fr>
      Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit a63ba13eec092b70d4e5522d692eaeb2f9747387
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Tue Oct 21 16:06:05 2014 +0200
 =20
      net: tso: fix unaligned access to crafted TCP header in helper API
     =20
      The crafted header start address is from a driver supplied buffer, wh=
ich
      one can reasonably expect to be aligned on a 4-bytes boundary.
      However ATM the TSO helper API is only used by ethernet drivers and
      the tcp header will then be aligned to a 2-bytes only boundary from t=
he
      header start address.
     =20
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8fc963515e893867330dec87464e9edc5204c024
  Author: Jon Cooper <jcooper@solarflare.com>
  Date:   Tue Oct 21 14:50:29 2014 +0100
 =20
      sfc: remove incorrect EFX_BUG_ON_PARANOID check
     =20
      write_count and insert_count can wrap around, making > check invalid.
     =20
      Fixes: 70b33fb0ddec827cbbd14cdc664fc27b2ef4a6b6 ("sfc: add support fo=
r
       skb->xmit_more").
     =20
      Signed-off-by: Edward Cree <ecree@solarflare.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c123bb7163043bb8f33858cf8e45b01c17dbd171
  Author: Sabrina Dubroca <sd@queasysnail.net>
  Date:   Tue Oct 21 11:08:21 2014 +0200
 =20
      netfilter: nf_tables: check for NULL in nf_tables_newchain pcpu stats=
 allocation
     =20
      alloc_percpu returns NULL on failure, not a negative error code.
     =20
      Fixes: ff3cd7b3c922 ("netfilter: nf_tables: refactor chain statistic =
routines")
      Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 0f9f5e1b83abd2b37c67658e02a6fc9001831fa5
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Tue Oct 21 11:28:12 2014 +0300
 =20
      netfilter: ipset: off by one in ip_set_nfnl_get_byindex()
     =20
      The ->ip_set_list[] array is initialized in ip_set_net_init() and it
      has ->ip_set_max elements so this check should be >=3D instead of >
      otherwise we are off by one.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit e37ad9fd636071e45368d1d9cc3b7b421281ce7f
  Author: Marcelo Leitner <mleitner@redhat.com>
  Date:   Mon Oct 13 13:09:28 2014 -0300
 =20
      netfilter: nf_conntrack: allow server to become a client in TW handli=
ng
     =20
      When a port that was used to listen for inbound connections gets clos=
ed
      and reused for outgoing connections (like rsh ends up doing for stder=
r
      flow), current we may reject the SYN/ACK packet for the new connectio=
n
      because tcp_conntracks states forbirds a port to become a client whil=
e
      there is still a TIME_WAIT entry in there for it.
     =20
      As TCP may expire the TIME_WAIT socket in 60s and conntrack's timeout
      for it is 120s, there is a ~60s window that the application can end u=
p
      opening a port that conntrack will end up blocking.
     =20
      This patch fixes this by simply allowing such state transition: if we
      see a SYN, in TIME_WAIT state, on REPLY direction, move it to sSS. No=
te
      that the rest of the code already handles this situation, more
      specificly in tcp_packet(), first switch clause.
     =20
      Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
      Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7c1c97d54f9bfc810908d3903cb8bcacf734df18
  Author: Sabrina Dubroca <sd@queasysnail.net>
  Date:   Tue Oct 21 11:23:30 2014 +0200
 =20
      net: sched: initialize bstats syncp
     =20
      Use netdev_alloc_pcpu_stats to allocate percpu stats and initialize s=
yncp.
     =20
      Fixes: 22e0f8b9322c "net: sched: make bstats per cpu and estimator RC=
U safe"
      Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
      Acked-by: Cong Wang <cwang@twopensource.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 32bf08a6257b9c7380dcd040af3c0858eee3ef05
  Author: Alexei Starovoitov <ast@plumgrid.com>
  Date:   Mon Oct 20 14:54:57 2014 -0700
 =20
      bpf: fix bug in eBPF verifier
     =20
      while comparing for verifier state equivalency the comparison
      was missing a check for uninitialized register.
      Make sure it does so and add a testcase.
     =20
      Fixes: f1bca824dabb ("bpf: add search pruning optimization to verifie=
r")
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
      Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 78fd1d0ab072d4d9b5f0b7c14a1516665170b565
  Author: Thomas Graf <tgraf@suug.ch>
  Date:   Tue Oct 21 22:05:38 2014 +0200
 =20
      netlink: Re-add locking to netlink_lookup() and seq walker
     =20
      The synchronize_rcu() in netlink_release() introduces unacceptable
      latency. Reintroduce minimal lookup so we can drop the
      synchronize_rcu() until socket destruction has been RCUfied.
     =20
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
      Reported-and-tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: Thomas Graf <tgraf@suug.ch>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1a194c2d59c55c37cb4c0c459d5418071a141341
  Author: Ying Xue <ying.xue@windriver.com>
  Date:   Mon Oct 20 14:46:35 2014 +0800
 =20
      tipc: fix lockdep warning when intra-node messages are delivered
     =20
      When running tipcTC&tipcTS test suite, below lockdep unsafe locking
      scenario is reported:
     =20
      [ 1109.997854]
      [ 1109.997988] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      [ 1109.998290] [ INFO: inconsistent lock state ]
      [ 1109.998575] 3.17.0-rc1+ #113 Not tainted
      [ 1109.998762] ---------------------------------
      [ 1109.998762] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [ 1109.998762] swapper/7/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [ 1109.998762]  (slock-AF_TIPC){+.?...}, at: [<ffffffffa0011969>] tip=
c_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762] {SOFTIRQ-ON-W} state was registered at:
      [ 1109.998762]   [<ffffffff810a4770>] __lock_acquire+0x6a0/0x1d80
      [ 1109.998762]   [<ffffffff810a6555>] lock_acquire+0x95/0x1e0
      [ 1109.998762]   [<ffffffff81a2d1ce>] _raw_spin_lock+0x3e/0x80
      [ 1109.998762]   [<ffffffffa0011969>] tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]   [<ffffffffa0004fe8>] tipc_link_xmit+0xa8/0xc0 [tipc]
      [ 1109.998762]   [<ffffffffa000ec6f>] tipc_sendmsg+0x15f/0x550 [tipc]
      [ 1109.998762]   [<ffffffffa000f165>] tipc_connect+0x105/0x140 [tipc]
      [ 1109.998762]   [<ffffffff817676ee>] SYSC_connect+0xae/0xc0
      [ 1109.998762]   [<ffffffff81767b7e>] SyS_connect+0xe/0x10
      [ 1109.998762]   [<ffffffff817a9788>] compat_SyS_socketcall+0xb8/0x20=
0
      [ 1109.998762]   [<ffffffff81a306e5>] sysenter_dispatch+0x7/0x1f
      [ 1109.998762] irq event stamp: 241060
      [ 1109.998762] hardirqs last  enabled at (241060): [<ffffffff8105a4ad=
>] __local_bh_enable_ip+0x6d/0xd0
      [ 1109.998762] hardirqs last disabled at (241059): [<ffffffff8105a46f=
>] __local_bh_enable_ip+0x2f/0xd0
      [ 1109.998762] softirqs last  enabled at (241020): [<ffffffff81059a52=
>] _local_bh_enable+0x22/0x50
      [ 1109.998762] softirqs last disabled at (241021): [<ffffffff8105a626=
>] irq_exit+0x96/0xc0
      [ 1109.998762]
      [ 1109.998762] other info that might help us debug this:
      [ 1109.998762]  Possible unsafe locking scenario:
      [ 1109.998762]
      [ 1109.998762]        CPU0
      [ 1109.998762]        ----
      [ 1109.998762]   lock(slock-AF_TIPC);
      [ 1109.998762]   <Interrupt>
      [ 1109.998762]     lock(slock-AF_TIPC);
      [ 1109.998762]
      [ 1109.998762]  *** DEADLOCK ***
      [ 1109.998762]
      [ 1109.998762] 2 locks held by swapper/7/0:
      [ 1109.998762]  #0:  (rcu_read_lock){......}, at: [<ffffffff81782dc9>=
] __netif_receive_skb_core+0x69/0xb70
      [ 1109.998762]  #1:  (rcu_read_lock){......}, at: [<ffffffffa0001c90>=
] tipc_l2_rcv_msg+0x40/0x260 [tipc]
      [ 1109.998762]
      [ 1109.998762] stack backtrace:
      [ 1109.998762] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.17.0-rc1+ =
#113
      [ 1109.998762] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [ 1109.998762]  ffffffff82745830 ffff880016c03828 ffffffff81a209eb 00=
00000000000007
      [ 1109.998762]  ffff880017b3cac0 ffff880016c03888 ffffffff81a1c5ef 00=
00000000000001
      [ 1109.998762]  ffff880000000001 ffff880000000000 ffffffff81012d4f 00=
00000000000000
      [ 1109.998762] Call Trace:
      [ 1109.998762]  <IRQ>  [<ffffffff81a209eb>] dump_stack+0x4e/0x68
      [ 1109.998762]  [<ffffffff81a1c5ef>] print_usage_bug+0x1f1/0x202
      [ 1109.998762]  [<ffffffff81012d4f>] ? save_stack_trace+0x2f/0x50
      [ 1109.998762]  [<ffffffff810a406c>] mark_lock+0x28c/0x2f0
      [ 1109.998762]  [<ffffffff810a3440>] ? print_irq_inversion_bug.part.4=
6+0x1f0/0x1f0
      [ 1109.998762]  [<ffffffff810a467d>] __lock_acquire+0x5ad/0x1d80
      [ 1109.998762]  [<ffffffff810a70dd>] ? trace_hardirqs_on+0xd/0x10
      [ 1109.998762]  [<ffffffff8108ace8>] ? sched_clock_cpu+0x98/0xc0
      [ 1109.998762]  [<ffffffff8108ad2b>] ? local_clock+0x1b/0x30
      [ 1109.998762]  [<ffffffff810a10dc>] ? lock_release_holdtime.part.29+=
0x1c/0x1a0
      [ 1109.998762]  [<ffffffff8108aa05>] ? sched_clock_local+0x25/0x90
      [ 1109.998762]  [<ffffffffa000dec0>] ? tipc_sk_get+0x60/0x80 [tipc]
      [ 1109.998762]  [<ffffffff810a6555>] lock_acquire+0x95/0x1e0
      [ 1109.998762]  [<ffffffffa0011969>] ? tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffff810a6fb6>] ? trace_hardirqs_on_caller+0xa6/=
0x1c0
      [ 1109.998762]  [<ffffffff81a2d1ce>] _raw_spin_lock+0x3e/0x80
      [ 1109.998762]  [<ffffffffa0011969>] ? tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffffa000dec0>] ? tipc_sk_get+0x60/0x80 [tipc]
      [ 1109.998762]  [<ffffffffa0011969>] tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffffa00076bd>] tipc_rcv+0x5ed/0x960 [tipc]
      [ 1109.998762]  [<ffffffffa0001d1c>] tipc_l2_rcv_msg+0xcc/0x260 [tipc=
]
      [ 1109.998762]  [<ffffffffa0001c90>] ? tipc_l2_rcv_msg+0x40/0x260 [ti=
pc]
      [ 1109.998762]  [<ffffffff81783345>] __netif_receive_skb_core+0x5e5/0=
xb70
      [ 1109.998762]  [<ffffffff81782dc9>] ? __netif_receive_skb_core+0x69/=
0xb70
      [ 1109.998762]  [<ffffffff81784eb9>] ? dev_gro_receive+0x259/0x4e0
      [ 1109.998762]  [<ffffffff817838f6>] __netif_receive_skb+0x26/0x70
      [ 1109.998762]  [<ffffffff81783acd>] netif_receive_skb_internal+0x2d/=
0x1f0
      [ 1109.998762]  [<ffffffff81785518>] napi_gro_receive+0xd8/0x240
      [ 1109.998762]  [<ffffffff815bf854>] e1000_clean_rx_irq+0x2c4/0x530
      [ 1109.998762]  [<ffffffff815c1a46>] e1000_clean+0x266/0x9c0
      [ 1109.998762]  [<ffffffff8108ad2b>] ? local_clock+0x1b/0x30
      [ 1109.998762]  [<ffffffff8108aa05>] ? sched_clock_local+0x25/0x90
      [ 1109.998762]  [<ffffffff817842b1>] net_rx_action+0x141/0x310
      [ 1109.998762]  [<ffffffff810bd710>] ? handle_fasteoi_irq+0xe0/0x150
      [ 1109.998762]  [<ffffffff81059fa6>] __do_softirq+0x116/0x4d0
      [ 1109.998762]  [<ffffffff8105a626>] irq_exit+0x96/0xc0
      [ 1109.998762]  [<ffffffff81a30d07>] do_IRQ+0x67/0x110
      [ 1109.998762]  [<ffffffff81a2ee2f>] common_interrupt+0x6f/0x6f
      [ 1109.998762]  <EOI>  [<ffffffff8100d2b7>] ? default_idle+0x37/0x250
      [ 1109.998762]  [<ffffffff8100d2b5>] ? default_idle+0x35/0x250
      [ 1109.998762]  [<ffffffff8100dd1f>] arch_cpu_idle+0xf/0x20
      [ 1109.998762]  [<ffffffff810999fd>] cpu_startup_entry+0x27d/0x4d0
      [ 1109.998762]  [<ffffffff81034c78>] start_secondary+0x188/0x1f0
     =20
      When intra-node messages are delivered from one process to another
      process, tipc_link_xmit() doesn't disable BH before it directly calls
      tipc_sk_rcv() on process context to forward messages to destination
      socket. Meanwhile, if messages delivered by remote node arrive at the
      node and their destinations are also the same socket, tipc_sk_rcv()
      running on process context might be preempted by tipc_sk_rcv() runnin=
g
      BH context. As a result, the latter cannot obtain the socket lock as
      the lock was obtained by the former, however, the former has no chanc=
e
      to be run as the latter is owning the CPU now, so headlock happens. T=
o
      avoid it, BH should be always disabled in tipc_sk_rcv().
     =20
      Signed-off-by: Ying Xue <ying.xue@windriver.com>
      Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7b8613e0a1502b43b3b36c93c66f835c891f63b3
  Author: Ying Xue <ying.xue@windriver.com>
  Date:   Mon Oct 20 14:44:25 2014 +0800
 =20
      tipc: fix a potential deadlock
     =20
      Locking dependency detected below possible unsafe locking scenario:
     =20
                 CPU0                          CPU1
      T0:  tipc_named_rcv()                tipc_rcv()
      T1:  [grab nametble write lock]*     [grab node lock]*
      T2:  tipc_update_nametbl()           tipc_node_link_up()
      T3:  tipc_nodesub_subscribe()        tipc_nametbl_publish()
      T4:  [grab node lock]*               [grab nametble write lock]*
     =20
      The opposite order of holding nametbl write lock and node lock on
      above two different paths may result in a deadlock. If we move the
      the updating of the name table after link state named out of node
      lock, the reverse order of holding locks will be eliminated, and
      as a result, the deadlock risk.
     =20
      Signed-off-by: Ying Xue <ying.xue@windriver.com>
      Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 73829bf6fec70703f10e360676d81d327f21ebf6
  Merge: d10845f 39dc90c
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 21 15:24:30 2014 -0400
 =20
      Merge branch 'enic'
     =20
      Govindarajulu Varadarajan says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      enic: Bug fixes
     =20
      This series fixes the following problem.
     =20
      Please apply this to net.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 39dc90c159c1bcc0fdd42913a7d560b1a1cd3acf
  Author: Govindarajulu Varadarajan <_govind@gmx.com>
  Date:   Sun Oct 19 14:20:28 2014 +0530
 =20
      enic: Do not call napi_disable when preemption is disabled.
     =20
      In enic_stop, we disable preemption using local_bh_disable(). We disa=
ble
      preemption to wait for busy_poll to finish.
     =20
      napi_disable should not be called here as it might sleep.
     =20
      Moving napi_disable() call out side of local_bh_disable.
     =20
      BUG: sleeping function called from invalid context at include/linux/n=
etdevice.h:477
      in_atomic(): 1, irqs_disabled(): 0, pid: 443, name: ifconfig
      INFO: lockdep is turned off.
      Preemption disabled at:[<ffffffffa029c5c4>] enic_rfs_flw_tbl_free+0x3=
4/0xd0 [enic]
     =20
      CPU: 31 PID: 443 Comm: ifconfig Not tainted 3.17.0-netnext-05504-g59f=
35b8 #268
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       ffff8800dac10000 ffff88020b8dfcb8 ffffffff8148a57c 0000000000000000
       ffff88020b8dfcd0 ffffffff8107e253 ffff8800dac12a40 ffff88020b8dfd10
       ffffffffa029305b ffff88020b8dfd48 ffff8800dac10000 ffff88020b8dfd48
      Call Trace:
       [<ffffffff8148a57c>] dump_stack+0x4e/0x7a
       [<ffffffff8107e253>] __might_sleep+0x123/0x1a0
       [<ffffffffa029305b>] enic_stop+0xdb/0x4d0 [enic]
       [<ffffffff8138ed7d>] __dev_close_many+0x9d/0xf0
       [<ffffffff8138ef81>] __dev_close+0x31/0x50
       [<ffffffff813974a8>] __dev_change_flags+0x98/0x160
       [<ffffffff81397594>] dev_change_flags+0x24/0x60
       [<ffffffff814085fd>] devinet_ioctl+0x63d/0x710
       [<ffffffff81139c16>] ? might_fault+0x56/0xc0
       [<ffffffff81409ef5>] inet_ioctl+0x65/0x90
       [<ffffffff813768e0>] sock_do_ioctl+0x20/0x50
       [<ffffffff81376ebb>] sock_ioctl+0x20b/0x2e0
       [<ffffffff81197250>] do_vfs_ioctl+0x2e0/0x500
       [<ffffffff81492619>] ? sysret_check+0x22/0x5d
       [<ffffffff81285f23>] ? __this_cpu_preempt_check+0x13/0x20
       [<ffffffff8109fe19>] ? trace_hardirqs_on_caller+0x119/0x270
       [<ffffffff811974ac>] SyS_ioctl+0x3c/0x80
       [<ffffffff814925ed>] system_call_fastpath+0x1a/0x1f
     =20
      Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b6931c9ba728d60c542c39ff037fe6f595c074a2
  Author: Govindarajulu Varadarajan <_govind@gmx.com>
  Date:   Sun Oct 19 14:20:27 2014 +0530
 =20
      enic: fix possible deadlock in enic_stop/ enic_rfs_flw_tbl_free
     =20
      The following warning is shown when spinlock debug is enabled.
     =20
      This occurs when enic_flow_may_expire timer function is running and
      enic_stop is called on same CPU.
     =20
      Fix this by using spink_lock_bh().
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      [ INFO: inconsistent lock state ]
      3.17.0-netnext-05504-g59f35b8 #268 Not tainted
      ---------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      ifconfig/443 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&enic->rfs_h.lock)->rlock){+.?...}, at:
      enic_rfs_flw_tbl_free+0x34/0xd0 [enic]
      {IN-SOFTIRQ-W} state was registered at:
        [<ffffffff810a25af>] __lock_acquire+0x83f/0x21c0
        [<ffffffff810a45f2>] lock_acquire+0xa2/0xd0
        [<ffffffff814913fc>] _raw_spin_lock+0x3c/0x80
        [<ffffffffa029c3d5>] enic_flow_may_expire+0x25/0x130[enic]
        [<ffffffff810bcd07>] call_timer_fn+0x77/0x100
        [<ffffffff810bd8e3>] run_timer_softirq+0x1e3/0x270
        [<ffffffff8105f9ae>] __do_softirq+0x14e/0x280
        [<ffffffff8105fdae>] irq_exit+0x8e/0xb0
        [<ffffffff8103da0f>] smp_apic_timer_interrupt+0x3f/0x50
        [<ffffffff81493742>] apic_timer_interrupt+0x72/0x80
        [<ffffffff81018143>] default_idle+0x13/0x20
        [<ffffffff81018a6a>] arch_cpu_idle+0xa/0x10
        [<ffffffff81097676>] cpu_startup_entry+0x2c6/0x330
        [<ffffffff8103b7ad>] start_secondary+0x21d/0x290
      irq event stamp: 2997
      hardirqs last  enabled at (2997): [<ffffffff81491865>] _raw_spin_unlo=
ck_irqrestore+0x65/0x90
      hardirqs last disabled at (2996): [<ffffffff814915e6>] _raw_spin_lock=
_irqsave+0x26/0x90
      softirqs last  enabled at (2968): [<ffffffff813b57a3>] dev_deactivate=
_many+0x213/0x260
      softirqs last disabled at (2966): [<ffffffff813b5783>] dev_deactivate=
_many+0x1f3/0x260
     =20
      other info that might help us debug this:
       Possible unsafe locking scenario:
     =20
             CPU0
             ----
        lock(&(&enic->rfs_h.lock)->rlock);
        <Interrupt>
          lock(&(&enic->rfs_h.lock)->rlock);
     =20
       *** DEADLOCK ***
     =20
      Reported-by: Jan Stancek <jstancek@redhat.com>
      Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d10845fc85b2e690b5f6425c5ba4df33a073fbc9
  Merge: ce8ec48 f993bc2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 20 12:38:19 2014 -0400
 =20
      Merge branch 'gso_encap_fixes'
     =20
      Florian Westphal says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      net: minor gso encapsulation fixes
     =20
      The following series fixes a minor bug in the gso segmentation handle=
rs
      when encapsulation offload is used.
     =20
      Theoretically this could cause kernel panic when the stack tries
      to software-segment such a GRE offload packet, but it looks like ther=
e
      is only one affected call site (tbf scheduler) and it handles NULL
      return value.
     =20
      I've included a followup patch to add IS_ERR_OR_NULL checks where nee=
ded.
     =20
      While looking into this, I also found that size computation of the in=
dividual
      segments is incorrect if skb->encapsulation is set.
     =20
      Please see individual patches for delta vs. v1.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f993bc25e5196e60514c216d0bca0f600de64af8
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:18 2014 +0200
 =20
      net: core: handle encapsulation offloads when computing segment lengt=
hs
     =20
      if ->encapsulation is set we have to use inner_tcp_hdrlen and add the
      size of the inner network headers too.
     =20
      This is 'mostly harmless'; tbf might send skb that is slightly over
      quota or drop skb even if it would have fit.
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 330966e501ffe282d7184fde4518d5e0c24bc7f8
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:17 2014 +0200
 =20
      net: make skb_gso_segment error handling more robust
     =20
      skb_gso_segment has three possible return values:
      1. a pointer to the first segmented skb
      2. an errno value (IS_ERR())
      3. NULL.  This can happen when GSO is used for header verification.
     =20
      However, several callers currently test IS_ERR instead of IS_ERR_OR_N=
ULL
      and would oops when NULL is returned.
     =20
      Note that these call sites should never actually see such a NULL retu=
rn
      value; all callers mask out the GSO bits in the feature argument.
     =20
      However, there have been issues with some protocol handlers erronousl=
y not
      respecting the specified feature mask in some cases.
     =20
      It is preferable to get 'have to turn off hw offloading, else slow' r=
eports
      rather than 'kernel crashes'.
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e16aa3ddf863c6b9f37eddf52503230a62dedb3
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:16 2014 +0200
 =20
      net: gso: use feature flag argument in all protocol gso handlers
     =20
      skb_gso_segment() has a 'features' argument representing offload feat=
ures
      available to the output path.
     =20
      A few handlers, e.g. GRE, instead re-fetch the features of skb->dev a=
nd use
      those instead of the provided ones when handing encapsulation/tunnels=
.
     =20
      Depending on dev->hw_enc_features of the output device skb_gso_segmen=
t() can
      then return NULL even when the caller has disabled all GSO feature bi=
ts,
      as segmentation of inner header thinks device will take care of segme=
ntation.
     =20
      This e.g. affects the tbf scheduler, which will silently drop GRE-enc=
ap GSO skbs
      that did not fit the remaining token quota as the segmentation does n=
ot work
      when device supports corresponding hw offload capabilities.
     =20
      Cc: Pravin B Shelar <pshelar@nicira.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ce8ec4896749783bd6cdc457e6012cfc18e09c8b
  Merge: 95ff886 1e2d56a
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 20 11:57:47 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      netfilter fixes for net
     =20
      The following patchset contains netfilter fixes for your net tree,
      they are:
     =20
      1) Fix missing MODULE_LICENSE() in the new nf_reject_ipv{4,6} modules=
.
     =20
      2) Restrict nat and masq expressions to the nat chain type. Otherwise=
,
         users may crash their kernel if they attach a nat/masq rule to a n=
on
         nat chain.
     =20
      3) Fix hook validation in nft_compat when non-base chains are used.
         Basically, initialize hook_mask to zero.
     =20
      4) Make sure you use match/targets in nft_compat from the right chain
         type. The existing validation relies on the table name which can b=
e
         avoided by
     =20
      5) Better netlink attribute validation in nft_nat. This expression ha=
s
         to reject the configuration when no address and proto configuratio=
ns
         are specified.
     =20
      6) Interpret NFTA_NAT_REG_*_MAX if only if NFTA_NAT_REG_*_MIN is set.
         Yet another sanity check to reject incorrect configurations from
         userspace.
     =20
      7) Conditional NAT attribute dumping depending on the existing
         configuration.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 11b2357d5dbce999803e9055f8c09829a8a87db4
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Mon Oct 20 10:54:36 2014 +0200
 =20
      mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats
     =20
      ATM an HT rc_stats line is 106 chars.
      Times 8(MCS_GROUP_RATES)*3(SS)*2(GI)*2(BW) + CCK(4), i.e. x100, this =
is
      well above the current 8192 - sizeof(*ms) currently allocated.
     =20
      Fix this by squeezing the output as follows (not that we're short on
      memory but this also improves readability and range, the new format a=
dds
      one more digit to *ok/*cum and ok/cum):
     =20
      - Before (HT) (106 ch):
      type           rate     throughput  ewma prob   this prob  retry   th=
is succ/attempt   success    attempts
      CCK/LP          5.5M           0.0        0.0         0.0      0     =
         0(  0)         0           0
      HT20/LGI ABCDP MCS0            0.0        0.0         0.0      1     =
         0(  0)         0           0
      - After (75 ch):
      type           rate     tpt eprob *prob ret  *ok(*cum)        ok(    =
  cum)
      CCK/LP          5.5M    0.0   0.0   0.0   0    0(   0)         0(    =
    0)
      HT20/LGI ABCDP MCS0     0.0   0.0   0.0   1    0(   0)         0(    =
    0)
     =20
      - Align non-HT format Before (non-HT) (83 ch):
      rate      throughput  ewma prob  this prob  this succ/attempt   succe=
ss    attempts
      ABCDP  6         0.0        0.0        0.0             0(  0)        =
 0           0
            54         0.0        0.0        0.0             0(  0)        =
 0           0
      - After (61 ch):
      rate          tpt eprob *prob  *ok(*cum)        ok(      cum)
      ABCDP  1      0.0   0.0   0.0    0(   0)         0(        0)
            54      0.0   0.0   0.0    0(   0)         0(        0)
     =20
      *This also adds dynamic checks for overflow, lowers the size of the
      non-HT request (allowing > 30 entries) and replaces the buddy-rounded
      allocations (s/sizeof(*ms) + 8192/8192).
     =20
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Acked-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 95ff88688781db2f64042e69bd499e518bbb36e5
  Author: Ian Morgan <imorgan@primordial.ca>
  Date:   Sun Oct 19 08:05:13 2014 -0400
 =20
      ax88179_178a: fix bonding failure
     =20
      The following patch fixes a bug which causes the ax88179_178a driver =
to be
      incapable of being added to a bond.
     =20
      When I brought up the issue with the bonding maintainers, they indica=
ted
      that the real problem was with the NIC driver which must return zero =
for
      success (of setting the MAC address). I see that several other NIC dr=
ivers
      follow that pattern by either simply always returing zero, or by pass=
ing
      through a negative (error) result while rewriting any positive return=
 code
      to zero. With that same philisophy applied to the ax88179_178a driver=
, it
      allows it to work correctly with the bonding driver.
     =20
      I believe this is suitable for queuing in -stable, as it's a small, s=
imple,
      and obvious fix that corrects a defect with no other known workaround=
.
     =20
      This patch is against vanilla 3.17(.0).
     =20
      Signed-off-by: Ian Morgan <imorgan@primordial.ca>
     =20
       drivers/net/usb/ax88179_178a.c |    7 ++++++-
       1 file changed, 6 insertions(+), 1 deletion(-)
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e2d56a5d33a7e1fcd21ed3859f52596d02708b0
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:24:14 2014 +0200
 =20
      netfilter: nft_nat: dump attributes if they are set
     =20
      Dump NFTA_NAT_REG_ADDR_MIN if this is non-zero. Same thing with
      NFTA_NAT_REG_PROTO_MIN.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 61cfac6b42af98ab46bcb3a47e150e7b20d5015e
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:19:35 2014 +0200
 =20
      netfilter: nft_nat: NFTA_NAT_REG_ADDR_MAX depends on NFTA_NAT_REG_ADD=
R_MIN
     =20
      Interpret NFTA_NAT_REG_ADDR_MAX if NFTA_NAT_REG_ADDR_MIN is present,
      otherwise, skip it. Same thing with NFTA_NAT_REG_PROTO_MAX.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 5c819a39753d6a3ae9c0092236f59730a369b619
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:16:57 2014 +0200
 =20
      netfilter: nft_nat: insufficient attribute validation
     =20
      We have to validate that we at least get an NFTA_NAT_REG_ADDR_MIN or
      NFTA_NFT_REG_PROTO_MIN attribute. Reject the configuration if none
      of them are present.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit f3f5ddeddd6aeadcef523d55ea9288e3d5c1cbc3
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Tue Oct 14 10:13:48 2014 +0200
 =20
      netfilter: nft_compat: validate chain type in match/target
     =20
      We have to validate the real chain type to ensure that matches/target=
s
      are not used out from their scope (eg. MASQUERADE in nat chain type).
      The existing validation relies on the table name, but this is not
      sufficient since userspace can fool us by using the appropriate table
      name with a different chain type.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 493618a92c6afdd3f6224ab586f169d6a259bb06
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Tue Oct 14 12:43:50 2014 +0200
 =20
      netfilter: nft_compat: fix hook validation for non-base chains
     =20
      Set hook_mask to zero for non-base chains, otherwise people may hit
      bogus errors from the xt_check_target() and xt_check_match() when
      validating the uninitialized hook_mask.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit c7abf25af0f41be4b50d44c5b185d52eea360cb8
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Mon Oct 13 14:34:41 2014 +0200
 =20
      mac80211: fix typo in starting baserate for rts_cts_rate_idx
     =20
      It affects non-(V)HT rates and can lead to selecting an rts_cts rate
      that is not a basic rate or way superior to the reference rate (ATM
      rates[0] used for the 1st attempt of the protected frame data).
     =20
      E.g, assuming drivers register growing (bitrate) sorted tables of
      ieee80211_rate-s, having :
      - rates[0].idx =3D=3D d'2 and basic_rates =3D=3D b'10100
      will select rts_cts idx b'10011 & ~d'(BIT(2)-1), i.e. 1, likewise
      - rates[0].idx =3D=3D d'2 and basic_rates =3D=3D b'10001
      will select rts_cts idx b'10000
      The first is not a basic rate and the second is > rates[0].
     =20
      Also, wrt severity of the addressed misbehavior, ATM we only have one
      rts_cts_rate_idx rather than one per rate table entry, so this idx mi=
ght
      still point to bitrates > rates[1..MAX_RATES].
     =20
      Fixes: 5253ffb8c9e1 ("mac80211: always pick a basic rate to tx RTS/CT=
S for pre-HT rates")
      Cc: stable@vger.kernel.org
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 7210e4e38f945dfa173c4a4e59ad827c9ecad541
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Mon Oct 13 19:50:22 2014 +0200
 =20
      netfilter: nf_tables: restrict nat/masq expressions to nat chain type
     =20
      This adds the missing validation code to avoid the use of nat/masq fr=
om
      non-nat chains. The validation assumes two possible configuration
      scenarios:
     =20
      1) Use of nat from base chain that is not of nat type. Reject this
         configuration from the nft_*_init() path of the expression.
     =20
      2) Use of nat from non-base chain. In this case, we have to wait unti=
l
         the non-base chain is referenced by at least one base chain via
         jump/goto. This is resolved from the nft_*_validate() path which i=
s
         called from nf_tables_check_loops().
     =20
      The user gets an -EOPNOTSUPP in both cases.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit ab2d7251d666995740da17b2a51ca545ac5dd037
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Fri Oct 10 11:25:20 2014 +0200
 =20
      netfilter: missing module license in the nf_reject_ipvX modules
     =20
      [   23.545204] nf_reject_ipv4: module license 'unspecified' taints ke=
rnel.
     =20
      Fixes: c8d7b98 ("netfilter: move nf_send_resetX() code to nf_reject_i=
pvX modules")
      Reported-by: Dave Young <dyoung@redhat.com>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 252e07ca5f64dd31fdfca8027287e7d75fefdab1
  Author: Luciano Coelho <luciano.coelho@intel.com>
  Date:   Wed Oct 8 09:48:34 2014 +0300
 =20
      nl80211: sanity check the channel switch counter value
     =20
      The nl80211 channel switch count attribute
      (NL80211_ATTR_CH_SWITCH_COUNT) is specified as u32, but the
      specification uses u8 for the counter.  To make sure strange things
      don't happen without informing the user, sanity check the value and
      return -EINVAL if it doesn't fit in u8.
     =20
      Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit bc37b16870a382e8b71d881444c19a16de1c1a7f
  Author: Fabian Frederick <fabf@skynet.be>
  Date:   Tue Oct 7 22:20:23 2014 +0200
 =20
      net: rfkill: kernel-doc warning fixes
     =20
      Correct the kernel-doc, the parameter is called "blocked" not "state"=
.
     =20
      Signed-off-by: Fabian Frederick <fabf@skynet.be>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit c12bc4885f4b3bab0ed779c69d5d7e3223fa5003
  Author: Luciano Coelho <luciano.coelho@intel.com>
  Date:   Tue Sep 30 07:08:02 2014 +0300
 =20
      mac80211: return the vif's chandef in ieee80211_cfg_get_channel()
     =20
      The chandef of the channel context a vif is using may be different
      than the chandef of the vif itself.  For instance, the bandwidth used
      by the vif may be narrower than the one configured in the channel
      context.  To avoid confusion, return the vif's chandef in
      ieee80211_cfg_get_channel() instead of the chandef of the channel
      context.
     =20
      Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 8975ae88e137ea02a71b7a86af2f8eb790c2f1e7
  Author: Liad Kaufman <liad.kaufman@intel.com>
  Date:   Sun Sep 14 21:48:28 2014 +0300
 =20
      mac80211: fix warning on htmldocs for last_tdls_pkt_time
     =20
      Forgot to add an entry to the struct description of sta_info.
     =20
      Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
      Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.linux-linus.t=
est-amd64-i386-rumpuserxen-i386.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31352 fail [host=3Dbush-cricket] / 31282 [host=3Dworm-moth] 31266 ok.
Failure / basis pass flights: 31352 / 31266
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.=
6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: rumpuserxen git://xenbits.xen.org/rumpuser-xen.git
Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.gi=
t
Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd
Tree: xen git://xenbits.xen.org/xen.git
Latest 0df1f2487d2f0d04703f142813d53615d62a1da4 c530a75c1e6a472b0eb9558310b=
518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24=
baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb61896d1f6=
8884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0f2bde=
078ace619fe8e26730495b6ef2c3a2e9bf
Basis pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb9558=
310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d=
7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 94c092b90=
6e348acd512744536d28e4f06e4c1ef 3687f55f417008a1fcdc04195644009232ae609d 66=
88825c240586708129df8887ad9b12a1708497
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/=
pub/scm/linux/kernel/git/torvalds/linux-2.6.git#a7ca10f263d7e673c74d8e0946d=
6b9993405cc9c-0df1f2487d2f0d04703f142813d53615d62a1da4 git://xenbits.xen.or=
g/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a=
75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-=
unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b=
3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.gi=
t#ca78cc83650b535d7e24baeaea32947be0141534-ca78cc83650b535d7e24baeaea32947b=
e0141534 git://xenbits.xen.org/rumpuser-xen.git#2ee4e55123b64feb79d8c824668=
a86e717ba47f8-ccc8df17b7e7e785e28bee8ae90d0f00f93208ca https://github.com/r=
umpkernel/buildrump.sh.git#94c092b906e348acd512744536d28e4f06e4c1ef-e8eb618=
96d1f68884b9c39b61e7e1ddb41e90c0b https://github.com/rumpkernel/src-netbsd#=
3687f55f417008a1fcdc04195644009232ae609d-3687f55f417008a1fcdc04195644009232=
ae609d git://xenbits.xen.org/xen.git#6688825c240586708129df8887ad9b12a17084=
97-0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.ker=
nel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/rumpuser-xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits=
.xen.org/rumpuser-xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/buildrump.sh
+ git remote set-url origin git://drall.uk.xensource.com:9419/https://githu=
b.com/rumpkernel/buildrump.sh.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits=
.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
>From git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen
   816f5bb..5a430ec  staging    -> origin/staging
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.ker=
nel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/rumpuser-xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits=
.xen.org/rumpuser-xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/buildrump.sh
+ git remote set-url origin git://drall.uk.xensource.com:9419/https://githu=
b.com/rumpkernel/buildrump.sh.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits=
.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Loaded 123760 nodes in revision graph
Searching for test results:
 31266 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 94c092b9=
06e348acd512744536d28e4f06e4c1ef 3687f55f417008a1fcdc04195644009232ae609d 6=
688825c240586708129df8887ad9b12a1708497
 31282 [host=3Dworm-moth]
 31334 fail 12d7aacab56e9ef185c3a5512e867bfd3a9504e4 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31352 fail 0df1f2487d2f0d04703f142813d53615d62a1da4 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31416 pass 53429290a054b30e4683297409fc4627b2592315 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31401 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 94c092b9=
06e348acd512744536d28e4f06e4c1ef 3687f55f417008a1fcdc04195644009232ae609d 6=
688825c240586708129df8887ad9b12a1708497
 31418 fail 89453379aaf0608253124057df6cd8ac63948135 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31402 fail 0df1f2487d2f0d04703f142813d53615d62a1da4 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31420 pass 53429290a054b30e4683297409fc4627b2592315 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31404 pass 3a2f22b7d0cc64482a91529e23c2570aa0602fa6 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2d0d163ae7cdabe002fd8a4ba441d9e7eb731fcf e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31421 fail 89453379aaf0608253124057df6cd8ac63948135 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31405 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 06ca11260277a9099a5ebeb04669fa0abf694106 e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31407 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 af976539=
24fa6f230f517d2efa850fd3c366054f 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31408 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 05c06de5=
24743a92d1d7b610dc9b4e23421f5e54 3687f55f417008a1fcdc04195644009232ae609d 9=
12054bbbc5914174b6f90c6bcd0a5c4f370bdbe
 31422 pass 53429290a054b30e4683297409fc4627b2592315 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31410 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 a55697c8=
28687a7ff09b1fc93a42b73685368717 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31412 pass f5fa363026c3508735c6ab2f1029110d2c4966a2 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31424 fail 89453379aaf0608253124057df6cd8ac63948135 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31414 fail 32e8fd2f8eac3262e7000d9a219d70ace10e0adf c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
Searching for interesting versions
 Result found: flight 31266 (pass), for basis pass
 Result found: flight 31352 (fail), for basis failure
 Repro found: flight 31401 (pass), for basis pass
 Repro found: flight 31402 (fail), for basis failure
 0 revisions at 53429290a054b30e4683297409fc4627b2592315 c530a75c1e6a472b0e=
b9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650=
b535d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb=
61896d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae60=
9d 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
No revisions left to test, checking graph state.
 Result found: flight 31416 (pass), for last pass
 Result found: flight 31418 (fail), for first failure
 Repro found: flight 31420 (pass), for last pass
 Repro found: flight 31421 (fail), for first failure
 Repro found: flight 31422 (pass), for last pass
 Repro found: flight 31424 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torv=
alds/linux-2.6.git
  Bug introduced:  89453379aaf0608253124057df6cd8ac63948135
  Bug not present: 53429290a054b30e4683297409fc4627b2592315

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.ker=
nel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 89453379aaf0608253124057df6cd8ac63948135
  Merge: 5342929 99a49ce
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Oct 31 15:04:58 2014 -0700
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
     =20
      Pull networking fixes from David Miller:
       "A bit has accumulated, but it's been a week or so since my last bat=
ch
        of post-merge-window fixes, so...
     =20
         1) Missing module license in netfilter reject module, from Pablo.
            Lots of people ran into this.
     =20
         2) Off by one in mac80211 baserate calculation, from Karl Beldan.
     =20
         3) Fix incorrect return value from ax88179_178a driver's set_mac_a=
ddr
            op, which broke use of it with bonding.  From Ian Morgan.
     =20
         4) Checking of skb_gso_segment()'s return value was not all
            encompassing, it can return an SKB pointer, a pointer error, or
            NULL.  Fix from Florian Westphal.
     =20
            This is crummy, and longer term will be fixed to just return er=
ror
            pointers or a real SKB.
     =20
         6) Encapsulation offloads not being handled by
            skb_gso_transport_seglen().  From Florian Westphal.
     =20
         7) Fix deadlock in TIPC stack, from Ying Xue.
     =20
         8) Fix performance regression from using rhashtable for netlink
            sockets.  The problem was the synchronize_net() invoked for eve=
ry
            socket destroy.  From Thomas Graf.
     =20
         9) Fix bug in eBPF verifier, and remove the strong dependency of B=
PF
            on NET.  From Alexei Starovoitov.
     =20
        10) In qdisc_create(), use the correct interface to allocate
            ->cpu_bstats, otherwise the u64_stats_sync member isn't
            initialized properly.  From Sabrina Dubroca.
     =20
        11) Off by one in ip_set_nfnl_get_byindex(), from Dan Carpenter.
     =20
        12) nf_tables_newchain() was erroneously expecting error pointers f=
rom
            netdev_alloc_pcpu_stats().  It only returna a valid pointer or
            NULL.  From Sabrina Dubroca.
     =20
        13) Fix use-after-free in _decode_session6(), from Li RongQing.
     =20
        14) When we set the TX flow hash on a socket, we mistakenly do so
            before we've nailed down the final source port.  Move the setti=
ng
            deeper to fix this.  From Sathya Perla.
     =20
        15) NAPI budget accounting in amd-xgbe driver was counting descript=
ors
            instead of full packets, fix from Thomas Lendacky.
     =20
        16) Fix total_data_buflen calculation in hyperv driver, from Haiyan=
g
            Zhang.
     =20
        17) Fix bcma driver build with OF_ADDRESS disabled, from Hauke
            Mehrtens.
     =20
        18) Fix mis-use of per-cpu memory in TCP md5 code.  The problem is
            that something that ends up being vmalloc memory can't be passe=
d
            to the crypto hash routines via scatter-gather lists.  From Eri=
c
            Dumazet.
     =20
        19) Fix regression in promiscuous mode enabling in cdc-ether, from
            Olivier Blin.
     =20
        20) Bucket eviction and frag entry killing can race with eachother,
            causing an unlink of the object from the wrong list.  Fix from
            Nikolay Aleksandrov.
     =20
        21) Missing initialization of spinlock in cxgb4 driver, from Anish
            Bhatt.
     =20
        22) Do not cache ipv4 routing failures, otherwise if the sysctl for
            forwarding is subsequently enabled this won't be seen.  From
            Nicolas Cavallari"
     =20
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (131 commi=
ts)
        drivers: net: cpsw: Support ALLMULTI and fix IFF_PROMISC in switch =
mode
        drivers: net: cpsw: Fix broken loop condition in switch mode
        net: ethtool: Return -EOPNOTSUPP if user space tries to read EEPROM=
 with lengh 0
        stmmac: pci: set default of the filter bins
        net: smc91x: Fix gpios for device tree based booting
        mpls: Allow mpls_gso to be built as module
        mpls: Fix mpls_gso handler.
        r8152: stop submitting intr for -EPROTO
        netfilter: nft_reject_bridge: restrict reject to prerouting and inp=
ut
        netfilter: nft_reject_bridge: don't use IP stack to reject traffic
        netfilter: nf_reject_ipv6: split nf_send_reset6() in smaller functi=
ons
        netfilter: nf_reject_ipv4: split nf_send_reset() in smaller functio=
ns
        netfilter: nf_tables_bridge: update hook_mask to allow {pre,post}ro=
uting
        drivers/net: macvtap and tun depend on INET
        drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packe=
ts
        drivers/net: Disable UFO through virtio
        net: skb_fclone_busy() needs to detect orphaned skb
        gre: Use inner mac length when computing tunnel length
        mlx4: Avoid leaking steering rules on flow creation error flow
        net/mlx4_en: Don't attempt to TX offload the outer UDP checksum for=
 VXLAN
        ...
 =20
  commit 99a49ce613057f1934e1c378808374fd683b1541
  Merge: 1e5c4bc 75a916e
  Author: David S. Miller <davem@davemloft.net>
  Date:   Fri Oct 31 16:18:35 2014 -0400
 =20
      Merge tag 'master-2014-10-30' of git://git.kernel.org/pub/scm/linux/k=
ernel/git/linville/wireless
     =20
      John W. Linville says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      pull request: wireless 2014-10-31
     =20
      Please pull this small batch of spooky fixes intended for the 3.18
      stream...boo!
     =20
      Cyril Brulebois adds an rt2x00 device ID.
     =20
      Dan Carpenter provides a one-line masking fix for an ath9k debugfs
      entry.
     =20
      Larry Finger gives us a package of small rtlwifi fixes which add some
      bits that were left out of some feature updates that were included
      in the merge window.  Hopefully this isn't a sign that the rtlwifi
      base is getting too big...
     =20
      Marc Yang brings a fix for a temporary mwifiex stall when doing 11n
      RX reordering.
     =20
      Please let me know if there are problems!
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e5c4bc497c0a96e1ad2974539d353870f2cb0b6
  Author: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  Date:   Fri Oct 31 13:38:52 2014 -0400
 =20
      drivers: net: cpsw: Support ALLMULTI and fix IFF_PROMISC in switch mo=
de
     =20
      The cpsw driver did not support the IFF_ALLMULTI flag which makes dyn=
amic
      multicast routing not work.  Related to this, when enabling IFF_PROMI=
SC
      in switch mode, all registered multicast addresses are flushed, resul=
ting
      in only broadcast and unicast traffic being received.
     =20
      A new cpsw_ale_set_allmulti function now scans through the ALE entry
      table and adds/removes the host port from the unregistered multicast
      port mask of each vlan entry depending on the state of IFF_ALLMULTI.
      In promiscious mode, cpsw_ale_set_allmulti is used to force reception
      of all multicast traffic in addition to the unicast and broadcast tra=
ffic.
     =20
      With this change dynamic multicast and promiscious mode both work in
      switch mode.
     =20
      Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 6f979eb3fcfb4c3f42f230d174db4bbad0080710
  Author: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  Date:   Fri Oct 31 13:28:54 2014 -0400
 =20
      drivers: net: cpsw: Fix broken loop condition in switch mode
     =20
      0d961b3b52f566f823070ce2366511a7f64b928c (drivers: net: cpsw: fix bug=
gy
      loop condition) accidentally fixed a loop comparison in too many plac=
es
      while fixing a real bug.
     =20
      It was correct to fix the dual_emac mode section since there 'i' is u=
sed
      as an index into priv->slaves which is a 0 based array.
     =20
      However the other two changes (which are only used in switch mode)
      are wrong since there 'i' is actually the ALE port number, and port 0
      is the host port, while port 1 and up are the slave ports.
     =20
      Putting the loop condition back in the switch mode section fixes it.
     =20
      A comment has been added to point out the intent clearly to avoid fut=
ure
      confusion.  Also a comment is fixed that said the opposite of what wa=
s
      actually happening.
     =20
      Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
      Acked-by: Heiko Schocher <hs@denx.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e0fb6fb6d52686134b2ece144060219591d4f8d3
  Author: Guenter Roeck <linux@roeck-us.net>
  Date:   Thu Oct 30 20:50:15 2014 -0700
 =20
      net: ethtool: Return -EOPNOTSUPP if user space tries to read EEPROM w=
ith lengh 0
     =20
      If a driver supports reading EEPROM but no EEPROM is installed in the=
 system,
      the driver's get_eeprom_len function returns 0. ethtool will subseque=
ntly
      try to read that zero-length EEPROM anyway. If the driver does not su=
pport
      EEPROM access at all, this operation will return -EOPNOTSUPP. If the =
driver
      does support EEPROM access but no EEPROM is installed, the operation =
will
      return -EINVAL. Return -EOPNOTSUPP in both cases for consistency.
     =20
      Signed-off-by: Guenter Roeck <linux@roeck-us.net>
      Tested-by: Andrew Lunn <andrew@lunn.ch>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e19e084eae727654052339757ab7f1eaff58bad
  Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Date:   Fri Oct 31 18:28:03 2014 +0200
 =20
      stmmac: pci: set default of the filter bins
     =20
      The commit 3b57de958e2a brought the support for a different amount of=
 the
      filter bins, but didn't update the PCI driver accordingly. This patch=
 appends
      the default values when the device is enumerated via PCI bus.
     =20
      Fixes: 3b57de958e2a (net: stmmac: Support devicetree configs for mcas=
t and ucast filter entries)
      Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7d2911c4381555b31ef0bcae42a0dbf9ade7426e
  Author: Tony Lindgren <tony@atomide.com>
  Date:   Thu Oct 30 09:59:27 2014 -0700
 =20
      net: smc91x: Fix gpios for device tree based booting
     =20
      With legacy booting, the platform init code was taking care of
      the configuring of GPIOs. With device tree based booting, things
      may or may not work depending what bootloader has configured or
      if the legacy platform code gets called.
     =20
      Let's add support for the pwrdn and reset GPIOs to the smc91x
      driver to fix the issues of smc91x not working properly when
      booted in device tree mode.
     =20
      And let's change n900 to use these settings as some versions
      of the bootloader do not configure things properly causing
      errors.
     =20
      Reported-by: Kevin Hilman <khilman@linaro.org>
      Signed-off-by: Tony Lindgren <tony@atomide.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit de05c400f7dfa566f598140f8604a5de8067cd5f
  Author: Pravin B Shelar <pshelar@nicira.com>
  Date:   Thu Oct 30 00:50:04 2014 -0700
 =20
      mpls: Allow mpls_gso to be built as module
     =20
      Kconfig already allows mpls to be built as module. Following patch
      fixes Makefile to do same.
     =20
      CC: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
      Acked-by: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f7065f4bd3fe4ad6bf7e49ba7c68baa2c7046146
  Author: Pravin B Shelar <pshelar@nicira.com>
  Date:   Thu Oct 30 00:49:57 2014 -0700
 =20
      mpls: Fix mpls_gso handler.
     =20
      mpls gso handler needs to pull skb after segmenting skb.
     =20
      CC: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
      Acked-by: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d59c876dd61f3c151db077f9d73774e605f2b35e
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Fri Oct 31 13:35:57 2014 +0800
 =20
      r8152: stop submitting intr for -EPROTO
     =20
      For Renesas USB 3.0 host controller, when unplugging the usb hub whic=
h
      has the RTL8153 plugged, the driver would get -EPROTO for interrupt
      transfer. There is high probability to get the information of "HC die=
d;
      cleaning up", if the driver continues to submit the interrupt transfe=
r
      before the disconnect() is called.
     =20
      [ 1024.197678] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.213673] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.229668] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.245661] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.261653] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.277648] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.293642] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.309638] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.325633] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.341627] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.357621] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.373615] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.383097] usb 9-1: USB disconnect, device number 2
      [ 1024.383103] usb 9-1.4: USB disconnect, device number 6
      [ 1029.391010] xhci_hcd 0000:04:00.0: xHCI host not responding to sto=
p endpoint command.
      [ 1029.391016] xhci_hcd 0000:04:00.0: Assuming host is dying, halting=
 host.
      [ 1029.392551] xhci_hcd 0000:04:00.0: HC died; cleaning up
      [ 1029.421480] usb 8-1: USB disconnect, device number 2
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e3a88f9c4f79a4d138a0ea464cfbac40ba46644c
  Merge: de11b0e 127917c
  Author: David S. Miller <davem@davemloft.net>
  Date:   Fri Oct 31 12:29:42 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      netfilter/ipvs fixes for net
     =20
      The following patchset contains fixes for netfilter/ipvs. This round =
of
      fixes is larger than usual at this stage, specifically because of the
      nf_tables bridge reject fixes that I would like to see in 3.18. The
      patches are:
     =20
      1) Fix a null-pointer dereference that may occur when logging
         errors. This problem was introduced by 4a4739d56b0 ("ipvs: Pull
         out crosses_local_route_boundary logic") in v3.17-rc5.
     =20
      2) Update hook mask in nft_reject_bridge so we can also filter out
         packets from there. This fixes 36d2af5 ("netfilter: nf_tables: all=
ow
         to filter from prerouting and postrouting"), which needs this chun=
k
         to work.
     =20
      3) Two patches to refactor common code to forge the IPv4 and IPv6
         reject packets from the bridge. These are required by the nf_table=
s
         reject bridge fix.
     =20
      4) Fix nft_reject_bridge by avoiding the use of the IP stack to rejec=
t
         packets from the bridge. The idea is to forge the reject packets a=
nd
         inject them to the original port via br_deliver() which is now
         exported for that purpose.
     =20
      5) Restrict nft_reject_bridge to bridge prerouting and input hooks.
         the original skbuff may cloned after prerouting when the bridge st=
ack
         needs to flood it to several bridge ports, it is too late to rejec=
t
         the traffic.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 127917c29a432c3b798e014a1714e9c1af0f87fe
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Mon Oct 27 14:08:17 2014 +0100
 =20
      netfilter: nft_reject_bridge: restrict reject to prerouting and input
     =20
      Restrict the reject expression to the prerouting and input bridge
      hooks. If we allow this to be used from forward or any other later
      bridge hook, if the frame is flooded to several ports, we'll end up
      sending several reject packets, one per cloned packet.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 523b929d5446c023e1219aa81455a8c766cac883
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 18:40:26 2014 +0200
 =20
      netfilter: nft_reject_bridge: don't use IP stack to reject traffic
     =20
      If the packet is received via the bridge stack, this cannot reject
      packets from the IP stack.
     =20
      This adds functions to build the reject packet and send it from the
      bridge stack. Comments and assumptions on this patch:
     =20
      1) Validate the IPv4 and IPv6 headers before further processing,
         given that the packet comes from the bridge stack, we cannot assum=
e
         they are clean. Truncated packets are dropped, we follow similar
         approach in the existing iptables match/target extensions that nee=
d
         to inspect layer 4 headers that is not available. This also includ=
es
         packets that are directed to multicast and broadcast ethernet
         addresses.
     =20
      2) br_deliver() is exported to inject the reject packet via
         bridge localout -> postrouting. So the approach is similar to what
         we already do in the iptables reject target. The reject packet is
         sent to the bridge port from which we have received the original
         packet.
     =20
      3) The reject packet is forged based on the original packet. The TTL
         is set based on sysctl_ip_default_ttl for IPv4 and per-net
         ipv6.devconf_all hoplimit for IPv6.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 8bfcdf6671b1c8006c52c3eaf9fd1b5dfcf41c3d
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sun Oct 26 12:35:54 2014 +0100
 =20
      netfilter: nf_reject_ipv6: split nf_send_reset6() in smaller function=
s
     =20
      That can be reused by the reject bridge expression to build the rejec=
t
      packet. The new functions are:
     =20
      * nf_reject_ip6_tcphdr_get(): to sanitize and to obtain the TCP heade=
r.
      * nf_reject_ip6hdr_put(): to build the IPv6 header.
      * nf_reject_ip6_tcphdr_put(): to build the TCP header.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 052b9498eea532deb5de75277a53f6e0623215dc
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 18:24:57 2014 +0200
 =20
      netfilter: nf_reject_ipv4: split nf_send_reset() in smaller functions
     =20
      That can be reused by the reject bridge expression to build the rejec=
t
      packet. The new functions are:
     =20
      * nf_reject_ip_tcphdr_get(): to sanitize and to obtain the TCP header=
.
      * nf_reject_iphdr_put(): to build the IPv4 header.
      * nf_reject_ip_tcphdr_put(): to build the TCP header.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 4d87716cd057bde3f90e304289c1fec88d45a1cc
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 12:25:06 2014 +0200
 =20
      netfilter: nf_tables_bridge: update hook_mask to allow {pre,post}rout=
ing
     =20
      Fixes: 36d2af5 ("netfilter: nf_tables: allow to filter from preroutin=
g and postrouting")
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit de11b0e8c569b96c2cf6a811e3805b7aeef498a3
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Fri Oct 31 03:10:31 2014 +0000
 =20
      drivers/net: macvtap and tun depend on INET
     =20
      These drivers now call ipv6_proxy_select_ident(), which is defined
      only if CONFIG_INET is enabled.  However, they have really depended
      on CONFIG_INET for as long as they have allowed sending GSO packets
      from userland.
     =20
      Reported-by: kbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
      Fixes: b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
      Fixes: 5188cd44c55d ("drivers/net, ipv6: Select IPv6 fragment idents =
for virtio UFO packets")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c1304b217c7cefa5718fab9d36c59ba0d0133c6e
  Merge: 39bb5e6 5188cd4
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 20:01:27 2014 -0400
 =20
      Merge branch 'ufo-fix'
     =20
      Ben Hutchings says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      drivers/net,ipv6: Fix IPv6 fragment ID selection for virtio
     =20
      The virtio net protocol supports UFO but does not provide for passing=
 a
      fragment ID for fragmentation of IPv6 packets.  We used to generate a
      fragment ID wherever such a packet was fragmented, but currently we
      always use ID=3D0!
     =20
      v2: Add blank lines after declarations
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Thu Oct 30 18:27:17 2014 +0000
 =20
      drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets
     =20
      UFO is now disabled on all drivers that work with virtio net headers,
      but userland may try to send UFO/IPv6 packets anyway.  Instead of
      sending with ID=3D0, we should select identifiers on their behalf (as=
 we
      used to).
     =20
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_dat=
a")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Thu Oct 30 18:27:12 2014 +0000
 =20
      drivers/net: Disable UFO through virtio
     =20
      IPv6 does not allow fragmentation by routers, so there is no
      fragmentation ID in the fixed header.  UFO for IPv6 requires the ID t=
o
      be passed separately, but there is no provision for this in the virti=
o
      net protocol.
     =20
      Until recently our software implementation of UFO/IPv6 generated a ne=
w
      ID, but this was a bug.  Now we will use ID=3D0 for any UFO/IPv6 pack=
et
      passed through a tap, which is even worse.
     =20
      Unfortunately there is no distinction between UFO/IPv4 and v6
      features, so disable UFO on taps and virtio_net completely until we
      have a proper solution.
     =20
      We cannot depend on VM managers respecting the tap feature flags, so
      keep accepting UFO packets but log a warning the first time we do
      this.
     =20
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_dat=
a")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 39bb5e62867de82b269b07df900165029b928359
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 30 10:32:34 2014 -0700
 =20
      net: skb_fclone_busy() needs to detect orphaned skb
     =20
      Some drivers are unable to perform TX completions in a bound time.
      They instead call skb_orphan()
     =20
      Problem is skb_fclone_busy() has to detect this case, otherwise
      we block TCP retransmits and can freeze unlucky tcp sessions on
      mostly idle hosts.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 1f3279ae0c13 ("tcp: avoid retransmits of TCP packets hanging i=
n host queues")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 14051f0452a2c26a3f4791e6ad6a435e8f1945ff
  Author: Tom Herbert <therbert@google.com>
  Date:   Thu Oct 30 08:40:56 2014 -0700
 =20
      gre: Use inner mac length when computing tunnel length
     =20
      Currently, skb_inner_network_header is used but this does not account
      for Ethernet header for ETH_P_TEB. Use skb_inner_mac_header which
      handles TEB and also should work with IP encapsulation in which case
      inner mac and inner network headers are the same.
     =20
      Tested: Ran TCP_STREAM over GRE, worked as expected.
     =20
      Signed-off-by: Tom Herbert <therbert@google.com>
      Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 292dd6542f90126826fe87b302e6afa3b7ada6b8
  Merge: 9cc233f 571e1b2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 19:49:20 2014 -0400
 =20
      Merge branch 'mellanox-net'
     =20
      Or Gerlitz says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      mlx4 driver encapsulation/steering fixes
     =20
      The 1st patch fixes a bug in the TX path that supports offloading the
      TX checksum of (VXLAN) encapsulated TCP packets. It turns out that th=
e
      bug is revealed only when the receiver runs in non-offloaded mode, so
      we somehow missed it so far... please queue it for -stable >=3D 3.14
     =20
      The 2nd patch makes sure not to leak steering entry on error flow,
      please queue it to 3.17-stable
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 571e1b2c7a4c2fd5faa1648462a6b65fa26530d7
  Author: Or Gerlitz <ogerlitz@mellanox.com>
  Date:   Thu Oct 30 15:59:28 2014 +0200
 =20
      mlx4: Avoid leaking steering rules on flow creation error flow
     =20
      If mlx4_ib_create_flow() attempts to create > 1 rules with the
      firmware, and one of these registrations fail, we leaked the
      already created flow rules.
     =20
      One example of the leak is when the registration of the VXLAN ghost
      steering rule fails, we didn't unregister the original rule requested
      by the user, introduced in commit d2fce8a9060d "mlx4: Set
      user-space raw Ethernet QPs to properly handle VXLAN traffic".
     =20
      While here, add dump of the VXLAN portion of steering rules
      so it can actually be seen when flow creation fails.
     =20
      Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit a4f2dacbf2a5045e34b98a35d9a3857800f25a7b
  Author: Or Gerlitz <ogerlitz@mellanox.com>
  Date:   Thu Oct 30 15:59:27 2014 +0200
 =20
      net/mlx4_en: Don't attempt to TX offload the outer UDP checksum for V=
XLAN
     =20
      For VXLAN/NVGRE encapsulation, the current HW doesn't support offload=
ing
      both the outer UDP TX checksum and the inner TCP/UDP TX checksum.
     =20
      The driver doesn't advertize SKB_GSO_UDP_TUNNEL_CSUM, however we are =
wrongly
      telling the HW to offload the outer UDP checksum for encapsulated pac=
kets,
      fix that.
     =20
      Fixes: 837052d0ccc5 ('net/mlx4_en: Add netdev support for TCP/IP
      		     offloads of vxlan tunneling')
      Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9cc233fb0f94b79d07cf141a625e237769d267a1
  Merge: fa19c2b0 e3215f0
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 19:46:33 2014 -0400
 =20
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/gi=
t/jkirsher/net
     =20
      Jeff Kirsher says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      Intel Wired LAN Driver Updates 2014-10-30
     =20
      This series contains updates to e1000, igb and ixgbe.
     =20
      Francesco Ruggeri fixes an issue with e1000 where in a VM the driver =
did
      not support unicast filtering.
     =20
      Roman Gushchin fixes an issue with igb where the driver was re-using
      mapped pages so that packets were still getting dropped even if all
      the memory issues are gone and there is free memory.
     =20
      Junwei Zhang found where in the ixgbe_clean_rx_ring() we were repeati=
ng
      the assignment of NULL to the receive buffer skb and fixes it.
     =20
      Emil fixes a race condition between setup_link and SFP detection rout=
ine
      in the watchdog when setting the advertised speed.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit fa19c2b050ab5254326f5fc07096dd3c6a8d5d58
  Author: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
  Date:   Thu Oct 30 10:09:53 2014 +0100
 =20
      ipv4: Do not cache routing failures due to disabled forwarding.
     =20
      If we cache them, the kernel will reuse them, independently of
      whether forwarding is enabled or not.  Which means that if forwarding=
 is
      disabled on the input interface where the first routing request comes
      from, then that unreachable result will be cached and reused for
      other interfaces, even if forwarding is enabled on them.  The opposit=
e
      is also true.
     =20
      This can be verified with two interfaces A and B and an output interf=
ace
      C, where B has forwarding enabled, but not A and trying
      ip route get $dst iif A from $src && ip route get $dst iif B from $sr=
c
     =20
      Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communicati=
ons.fr>
      Reviewed-by: Julian Anastasov <ja@ssi.bg>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e327c225c911529898ec300cb96d2088893de3df
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Wed Oct 29 17:54:03 2014 -0700
 =20
      cxgb4 : Fix missing initialization of win0_lock
     =20
      win0_lock was being used un-initialized, resulting in warning traces
      being seen when lock debugging is enabled (and just wrong)
     =20
      Fixes : fc5ab0209650 ('cxgb4: Replaced the backdoor mechanism to acce=
ss the HW
       memory with PCIe Window method')
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: Casey Leedom <leedom@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 83810a9a6af310e413ce649c6ca2df2b4946e5a4
  Merge: d70127e e3bd1a8
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 15:49:05 2014 -0400
 =20
      Merge branch 'r8152-net'
     =20
      Hayes Wang says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      r8152: patches for autosuspend
     =20
      There are unexpected processes when enabling autosuspend.
      These patches are used to fix them.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e3bd1a81cd1e3f8ed961e642e97206d715db06c4
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:17 2014 +0800
 =20
      r8152: check WORK_ENABLE in suspend function
     =20
      Avoid unnecessary behavior when autosuspend occurs during open().
      The relative processes should only be run after finishing open().
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f4c7476b041d200c3b347f019eebf05e6d0b47f9
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:16 2014 +0800
 =20
      r8152: reset tp->speed before autoresuming in open function
     =20
      If (tp->speed & LINK_STATUS) is not zero, the rtl8152_resume()
      would call rtl_start_rx() before enabling the tx/rx. Avoid this
      by resetting it to zero.
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 923e1ee3ff0b585cc4f56cf696c8455708537ffb
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:15 2014 +0800
 =20
      r8152: clear SELECTIVE_SUSPEND when autoresuming
     =20
      The flag of SELECTIVE_SUSPEND should be cleared when autoresuming.
      Otherwise, when the system suspend and resume occur, it may have
      the wrong flow.
     =20
      Besides, because the flag of SELECTIVE_SUSPEND couldn't be used
      to check if the hw enables the relative feature, it should alwayes
      be disabled in close().
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 75a916e1944fea8347d2245c62567187e4eff9dd
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:13 2014 -0500
 =20
      rtlwifi: rtl8192se: Fix firmware loading
     =20
      An error in the code makes the allocated space for firmware to be too
      small.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 8ae3c16e41b02db8ffe4121468519d6352baedc1
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:11 2014 -0500
 =20
      rtlwifi: rtl8192ce: Add missing section to read descriptor setting
     =20
      The new version of rtlwifi needs code in rtl92ce_get_desc() that retu=
rns
      the buffer address for read operations.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 30c5ccc6afee39754cff75ad8d775ad39a2ce989
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:10 2014 -0500
 =20
      rtlwifi: rtl8192se: Add missing section to read descriptor setting
     =20
      The new version of rtlwifi needs code in rtl92se_get_desc() that retu=
rns
      the buffer address for read operations.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 501479699ff484ba8acc1d07022271f00cfc55a3
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:09 2014 -0500
 =20
      rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw()
     =20
      Driver rtlwifi has been modified to call ieee80211_register_hw()
      from the probe routine; however, the existing call in the callback
      routine for deferred firmware loading was not removed.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit c0386f1584127442d0f2aea41bc948056d6b1337
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:08 2014 -0500
 =20
      rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing ge=
t_btc_status
     =20
      The recent changes in checking for Bluetooth status added some callba=
cks to code
      in rtlwifi. To make certain that all callbacks are defined, a dummy r=
outine has been
      added to rtlwifi, and the drivers that need to use it are modified.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 3a8fede115f12f7b90524d1ba4e709ce398ce8c6
  Author: Marc Yang <yangyang@marvell.com>
  Date:   Wed Oct 29 22:44:34 2014 +0530
 =20
      mwifiex: restart rxreorder timer correctly
     =20
      During 11n RX reordering, if there is a hole in RX table,
      driver will not send packets to kernel until the rxreorder
      timer expires or the table is full.
      However, currently driver always restarts rxreorder timer when
      receiving a packet, which causes the timer hardly to expire.
      So while connected with to 11n AP in a busy environment,
      ping packets may get blocked for about 30 seconds.
     =20
      This patch fixes this timer restarting by ensuring rxreorder timer
      would only be restarted either timer is not set or start_win
      has changed.
     =20
      Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
      Signed-off-by: Plus Chen <pchen@marvell.com>
      Signed-off-by: Marc Yang <yangyang@marvell.com>
      Signed-off-by: Cathy Luo <cluo@marvell.com>
      Signed-off-by: Avinash Patil <patila@marvell.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit a017ff755e43de9a3221d4ff4f03184ea7b93733
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Wed Oct 29 18:48:05 2014 +0300
 =20
      ath9k: fix some debugfs output
     =20
      The right shift operation has higher precedence than the mask so we
      left shift by "(i * 3)" and then immediately right shift by "(i * 3)"
      then we mask.  It should be left shift, mask, and then right shift.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 664d6a792785cc677c2091038ce10322c8d04ae1
  Author: Cyril Brulebois <kibi@debian.org>
  Date:   Tue Oct 28 16:42:41 2014 +0100
 =20
      wireless: rt2x00: add new rt2800usb device
     =20
      0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
     =20
      References: https://bugs.debian.org/766802
      Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
      Cc: stable@vger.kernel.org
      Signed-off-by: Cyril Brulebois <kibi@debian.org>
      Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit e3215f0ac77ec23b052cb0bf511143038ac2ad7b
  Author: Emil Tantilov <emil.s.tantilov@intel.com>
  Date:   Tue Oct 28 05:50:03 2014 +0000
 =20
      ixgbe: fix race when setting advertised speed
     =20
      Following commands:
     =20
      modprobe ixgbe
      ifconfig ethX up
      ethtool -s ethX advertise 0x020
     =20
      can lead to "setup link failed with code -14" error due to the setup_=
link
      call racing with the SFP detection routine in the watchdog.
     =20
      This patch resolves this issue by protecting the setup_link call with=
 check
      for __IXGBE_IN_SFP_INIT.
     =20
      Reported-by: Scott Harrison <scoharr2@cisco.com>
      Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
      Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit 4d2fcfbcf8141cdf70245a0c0612b8076f4b7e32
  Author: Junwei Zhang <linggao.zjw@alibaba-inc.com>
  Date:   Wed Oct 22 15:29:03 2014 +0000
 =20
      ixgbe: need not repeat init skb with NULL
     =20
      Signed-off-by: Martin Zhang <martinbj2008@gmail.com>
      Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit bc16e47f03a7dce9ad68029b21519265c334eb12
  Author: Roman Gushchin <klamm@yandex-team.ru>
  Date:   Thu Oct 23 03:32:27 2014 +0000
 =20
      igb: don't reuse pages with pfmemalloc flag
     =20
      Incoming packet is dropped silently by sk_filter(), if the skb was
      allocated from pfmemalloc reserves and the corresponding socket is
      not marked with the SOCK_MEMALLOC flag.
     =20
      Igb driver allocates pages for DMA with __skb_alloc_page(), which
      calls alloc_pages_node() with the __GFP_MEMALLOC flag. So, in case
      of OOM condition, igb can get pages with pfmemalloc flag set.
     =20
      If an incoming packet hits the pfmemalloc page and is large enough
      (small packets are copying into the memory, allocated with
      netdev_alloc_skb_ip_align(), so they are not affected), it will be
      dropped.
     =20
      This behavior is ok under high memory pressure, but the problem is
      that the igb driver reuses these mapped pages. So, packets are still
      dropping even if all memory issues are gone and there is a plenty
      of free memory.
     =20
      In my case, some TCP sessions hang on a small percentage (< 0.1%)
      of machines days after OOMs.
     =20
      Fix this by avoiding reuse of such pages.
     =20
      Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
      Tested-by: Aaron Brown "aaron.f.brown@intel.com"
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit a22bb0b9b9b09b4cc711f6d577679773e074dde9
  Author: Francesco Ruggeri <fruggeri@aristanetworks.com>
  Date:   Wed Oct 22 15:29:24 2014 +0000
 =20
      e1000: unset IFF_UNICAST_FLT on WMware 82545EM
     =20
      VMWare's e1000 implementation does not seem to support unicast filter=
ing.
      This can be observed by configuring a macvlan interface on eth0 in a =
VM in
      VMWare Fusion 5.0.5, and trying to use that interface instead of eth0=
.
      Tested on 3.16.
     =20
      Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
      Tested-by: Aaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit d70127e8a942364de8dd140fe73893efda363293
  Author: Nikolay Aleksandrov <nikolay@redhat.com>
  Date:   Tue Oct 28 10:44:01 2014 +0100
 =20
      inet: frags: remove the WARN_ON from inet_evict_bucket
     =20
      The WARN_ON in inet_evict_bucket can be triggered by a valid case:
      inet_frag_kill and inet_evict_bucket can be running in parallel on th=
e
      same queue which means that there has been at least one more ref adde=
d
      by a previous inet_frag_find call, but inet_frag_kill can delete the
      timer before inet_evict_bucket which will cause the WARN_ON() there t=
o
      trigger since we'll have refcnt!=3D1. Now, this case is valid because=
 the
      queue is being "killed" for some reason (removed from the chain list =
and
      its timer deleted) so it will get destroyed in the end by one of the
      inet_frag_put() calls which reaches 0 i.e. refcnt is still valid.
     =20
      CC: Florian Westphal <fw@strlen.de>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Patrick McLean <chutzpah@gentoo.org>
     =20
      Fixes: b13d3cbfb8e8 ("inet: frag: move eviction of queues to work que=
ue")
      Reported-by: Patrick McLean <chutzpah@gentoo.org>
      Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 65ba1f1ec0eff1c25933468e1d238201c0c2cb29
  Author: Nikolay Aleksandrov <nikolay@redhat.com>
  Date:   Tue Oct 28 10:30:34 2014 +0100
 =20
      inet: frags: fix a race between inet_evict_bucket and inet_frag_kill
     =20
      When the evictor is running it adds some chosen frags to a local list=
 to
      be evicted once the chain lock has been released but at the same time
      the *frag_queue can be running for some of the same queues and it
      may call inet_frag_kill which will wait on the chain lock and
      will then delete the queue from the wrong list since it was added in =
the
      eviction one. The fix is simple - check if the queue has the evict fl=
ag
      set under the chain lock before deleting it, this is safe because the
      evict flag is set only under that lock and having the flag set also m=
eans
      that the queue has been detached from the chain list, so no need to d=
elete
      it again.
      An important note to make is that we're safe w.r.t refcnt because
      inet_frag_kill and inet_evict_bucket will sync on the del_timer opera=
tion
      where only one of the two can succeed (or if the timer is executing -
      none of them), the cases are:
      1. inet_frag_kill succeeds in del_timer
       - then the timer ref is removed, but inet_evict_bucket will not add
         this queue to its expire list but will restart eviction in that ch=
ain
      2. inet_evict_bucket succeeds in del_timer
       - then the timer ref is kept until the evictor "expires" the queue, =
but
         inet_frag_kill will remove the initial ref and will set
         INET_FRAG_COMPLETE which will make the frag_expire fn just to remo=
ve
         its ref.
      In the end all of the queue users will do an inet_frag_put and the on=
e
      that reaches 0 will free it. The refcount balance should be okay.
     =20
      CC: Florian Westphal <fw@strlen.de>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Patrick McLean <chutzpah@gentoo.org>
     =20
      Fixes: b13d3cbfb8e8 ("inet: frag: move eviction of queues to work que=
ue")
      Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
      Reported-by: Patrick McLean <chutzpah@gentoo.org>
      Tested-by: Patrick McLean <chutzpah@gentoo.org>
      Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
      Reviewed-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8f4eb70059ee834522ce90a6fce0aa3078c18620
  Author: Tej Parkash <tej.parkash@qlogic.com>
  Date:   Tue Oct 28 01:18:15 2014 -0400
 =20
      cnic: Update the rcu_access_pointer() usages
     =20
      1. Remove the rcu_read_lock/unlock around rcu_access_pointer
      2. Replace the rcu_dereference with rcu_access_pointer
     =20
      Signed-off-by: Tej Parkash <tej.parkash@qlogic.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit cd03cf0158449f9f4c19ecb54dfc97d9bd86eeeb
  Author: Hariprasad Shenai <hariprasad@chelsio.com>
  Date:   Mon Oct 27 23:22:10 2014 +0530
 =20
      cxgb4vf: Replace repetitive pci device ID's with right ones
     =20
      Replaced repetive Device ID's which got added in commit b961f9a48844e=
cf3
      ("cxgb4vf: Remove superfluous "idx" parameter of CH_DEVICE() macro")
     =20
      Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b2ed64a97430a26a63c6ea91c9b50e639a98dfbc
  Author: Lubomir Rintel <lkundrak@v3.sk>
  Date:   Mon Oct 27 17:39:16 2014 +0100
 =20
      ipv6: notify userspace when we added or changed an ipv6 token
     =20
      NetworkManager might want to know that it changed when the router adv=
ertisement
      arrives.
     =20
      Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: Daniel Borkmann <dborkman@redhat.com>
      Acked-by: Daniel Borkmann <dborkman@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d56109020d93337545dd257a790cb429a70acfad
  Author: WANG Cong <xiyou.wangcong@gmail.com>
  Date:   Fri Oct 24 16:55:58 2014 -0700
 =20
      sch_pie: schedule the timer after all init succeed
     =20
      Cc: Vijay Subramanian <vijaynsu@cisco.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
      Acked-by: Eric Dumazet <edumazet@google.com>
 =20
  commit 068301f2be36a5c1ee9a2521c94b98e343612a88
  Merge: 9ffa1fc b77e26d
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 17:26:24 2014 -0400
 =20
      Merge branch 'cdc-ether'
     =20
      Olivier Blin says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      cdc-ether: handle promiscuous mode
     =20
      Since kernel 3.16, my Lenovo USB network adapters (RTL8153) using
      cdc-ether are not working anymore in a bridge.
     =20
      This is due to commit c472ab68ad67db23c9907a27649b7dc0899b61f9, which
      resets the packet filter when the device is bound.
     =20
      The default packet filter set by cdc-ether does not include
      promiscuous, while the adapter seemed to have promiscuous enabled by
      default.
     =20
      This patch series allows to support promiscuous mode for cdc-ether, b=
y
      hooking into set_rx_mode.
     =20
      Incidentally, maybe this device should be handled by the r8152 driver=
,
      but this patch series is still nice for other adapters.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
      Acked-by: Oliver Neukum <oneukum@suse.de>
 =20
  commit b77e26d191590c73b4a982ea3b3b87194069a56a
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:02 2014 +0200
 =20
      cdc-ether: handle promiscuous mode with a set_rx_mode callback
     =20
      Promiscuous mode was not supported anymore with my Lenovo adapters
      (RTL8153) since commit c472ab68ad67db23c9907a27649b7dc0899b61f9
      (cdc-ether: clean packet filter upon probe).
     =20
      It was not possible to use them in a bridge anymore.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Also-analyzed-by: Lo=C3=AFc Yhuel <loic.yhuel@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d80c679bc1526183f1cf4adc54b0b72e8798555e
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:01 2014 +0200
 =20
      cdc-ether: extract usbnet_cdc_update_filter function
     =20
      This will be used by the set_rx_mode callback.
     =20
      Also move a comment about multicast filtering in this new function.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1efed2d06c703489342ab6af2951683e07509c99
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:00 2014 +0200
 =20
      usbnet: add a callback for set_rx_mode
     =20
      To delegate promiscuous mode and multicast filtering to the subdriver=
.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9ffa1fcaef222026a8e031830f8db29d3f2cfc47
  Merge: ebcf34f 704d33e
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 17:08:56 2014 -0400
 =20
      Merge branch 'systemport-net'
     =20
      Florian Fainelli says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      net: systemport: RX path and suspend fixes
     =20
      These two patches fix a race condition where we have our RX interrupt=
s
      enabled, but not NAPI for the RX path, and the second patch fixes an
      issue for packets stuck in RX fifo during a suspend/resume cycle.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 704d33e7006f20f9b4fa7d24a0f08c4b5919b131
  Author: Florian Fainelli <f.fainelli@gmail.com>
  Date:   Tue Oct 28 11:12:01 2014 -0700
 =20
      net: systemport: reset UniMAC coming out of a suspend cycle
     =20
      bcm_sysport_resume() was missing an UniMAC reset which can lead to
      various receive FIFO corruptions coming out of a suspend cycle. If th=
e
      RX FIFO is stuck, it will deliver corrupted/duplicate packets towards
      the host CPU interface.
     =20
      This could be reproduced on crowded network and when Wake-on-LAN is
      enabled for this particular interface because the switch still forwar=
ds
      packets towards the host CPU interface (SYSTEMPORT), and we had to le=
ave
      the UniMAC RX enable bit on to allow matching MagicPackets.
     =20
      Once we re-enter the resume function, there is a small window during
      which the UniMAC receive is still enabled, and we start queueing
      packets, but the RDMA and RBUF engines are not ready, which leads to
      having packets stuck in the UniMAC RX FIFO, ultimately delivered towa=
rds
      the host CPU as corrupted.
     =20
      Fixes: 40755a0fce17 ("net: systemport: add suspend and resume support=
")
      Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8edf0047f4b8e03d94ef88f5a7dec146cce03a06
  Author: Florian Fainelli <f.fainelli@gmail.com>
  Date:   Tue Oct 28 11:12:00 2014 -0700
 =20
      net: systemport: enable RX interrupts after NAPI
     =20
      There is currently a small window during which the SYSTEMPORT adapter
      enables its RX interrupts without having enabled its NAPI handler, wh=
ich
      can result in packets to be discarded during interface bringup.
     =20
      A similar but more serious window exists in bcm_sysport_resume() duri=
ng
      which we can have the RDMA engine not fully prepared to receive packe=
ts
      and yet having RX interrupts enabled.
     =20
      Fix this my moving the RX interrupt enable down to
      bcm_sysport_netif_start() after napi_enable() for the RX path is call=
ed,
      which fixes both call sites: bcm_sysport_open() and
      bcm_sysport_resume().
     =20
      Fixes: b02e6d9ba7ad ("net: systemport: add bcm_sysport_netif_{enable,=
stop}")
      Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ebcf34f3d4be11f994340aff629f3c17171a4f65
  Author: Randy Dunlap <rdunlap@infradead.org>
  Date:   Sun Oct 26 19:14:06 2014 -0700
 =20
      skbuff.h: fix kernel-doc warning for headers_end
     =20
      Fix kernel-doc warning in <linux/skbuff.h> by making both headers_sta=
rt
      and headers_end private fields.
     =20
      Warning(..//include/linux/skbuff.h:654): No description found for par=
ameter 'headers_end[0]'
     =20
      Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 99d881f993f066c75059d24e44c74f7a3fc199bc
  Author: Vince Bridgers <vbridger@opensource.altera.com>
  Date:   Sun Oct 26 14:22:24 2014 -0500
 =20
      net: phy: Add SGMII Configuration for Marvell 88E1145 Initialization
     =20
      Marvell phy 88E1145 configuration & initialization was missing a case
      for initializing SGMII mode. This patch adds that case.
     =20
      Signed-off-by: Vince Bridgers <vbridger@opensource.altera.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 47276fcc2d542e7b15e384c08b1709c1921b06c1
  Author: Mugunthan V N <mugunthanvnm@ti.com>
  Date:   Fri Oct 24 18:51:33 2014 +0530
 =20
      drivers: net:cpsw: fix probe_dt when only slave 1 is pinned out
     =20
      when slave 0 has no phy and slave 1 connected to phy, driver probe wi=
ll
      fail as there is no phy id present for slave 0 device tree, so contin=
uing
      even though no phy-id found, also moving mac-id read later to ensure
      mac-id is read from device tree even when phy-id entry in not found.
     =20
      Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 25946f20b775f5c630d4326dd7a7f1df0576eb57
  Merge: 3923d68 99c8140
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 15:30:15 2014 -0400
 =20
      Merge tag 'master-2014-10-27' of git://git.kernel.org/pub/scm/linux/k=
ernel/git/linville/wireless
     =20
      John W. Linville says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      pull request: wireless 2014-10-28
     =20
      Please pull this batch of fixes intended for the 3.18 stream!
     =20
      For the mac80211 bits, Johannes says:
     =20
      "Here are a few fixes for the wireless stack: one fixes the
      RTS rate, one for a debugfs file, one to return the correct
      channel to userspace, a sanity check for a userspace value
      and the remaining two are just documentation fixes."
     =20
      For the iwlwifi bits, Emmanuel says:
     =20
      "I revert here a patch that caused interoperability issues.
      dvm gets a fix for a bug that was reported by many users.
      Two minor fixes for BT Coex and platform power fix that helps
      reducing latency when the PCIe link goes to low power states."
     =20
      In addition...
     =20
      Felix Fietkau adds a couple of ath code fixes related to regulatory
      rule enforcement.
     =20
      Hauke Mehrtens fixes a build break with bcma when CONFIG_OF_ADDRESS
      is not set.
     =20
      Karsten Wiese provides a trio of minor fixes for rtl8192cu.
     =20
      Kees Cook prevents a potential information leak in rtlwifi.
     =20
      Larry Finger also brings a trio of minor fixes for rtlwifi.
     =20
      Rafa=C5=82 Mi=C5=82ecki adds a device ID to the bcma bus driver.
     =20
      Rickard Strandqvist offers some strn* -> strl* changes in brcmfmac
      to eliminate non-terminated string issues.
     =20
      Sujith Manoharan avoids some ath9k stalls by enabling HW queue contro=
l
      only for MCC.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3923d68dc05033aa843b67d73110a6d402ac6e14
  Merge: f89b775 c146b77
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 15:28:30 2014 -0400
 =20
      Merge branch 'dsa-net'
     =20
      Andrew Lunn says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      DSA tagging mismatches
     =20
      The second patch is a fix, which should be applied to -rc. It is
      possible to get a DSA configuration which does not work. The patch
      stops this happening.
     =20
      The first patch detects this situation, and errors out the probe of
      DSA, making it more obvious something is wrong. It is not required to
      apply it -rc.
     =20
      v2 fixes the use case pointed out by Florian, that a switch driver
      may use DSA_TAG_PROTO_NONE which the patch did not correctly handle.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c146b7788e5721ec15bc0197bedf75849508e7ea
  Author: Andrew Lunn <andrew@lunn.ch>
  Date:   Fri Oct 24 23:44:05 2014 +0200
 =20
      dsa: mv88e6171: Fix tagging protocol/Kconfig
     =20
      The mv88e6171 can support two different tagging protocols, DSA and
      EDSA. The switch driver structure only allows one protocol to be
      enumerated, and DSA was chosen. However the Kconfig entry ensures the
      EDSA tagging code is built. With a minimal configuration, we then end
      up with a mismatch. The probe is successful, EDSA tagging is used, bu=
t
      the switch is configured for DSA, resulting in mangled packets.
     =20
      Change the switch driver structure to enumerate EDSA, fixing the
      mismatch.
     =20
      Signed-off-by: Andrew Lunn <andrew@lunn.ch>
      Fixes: 42f272539487 ("net: DSA: Marvell mv88e6171 switch driver")
      Acked-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ae439286a0dec99cc8029868243689b5b5f3ff75
  Author: Andrew Lunn <andrew@lunn.ch>
  Date:   Fri Oct 24 23:44:04 2014 +0200
 =20
      net: dsa: Error out on tagging protocol mismatches
     =20
      If there is a mismatch between enabled tagging protocols and the
      protocol the switch supports, error out, rather than continue with a
      situation which is unlikely to work.
     =20
      Signed-off-by: Andrew Lunn <andrew@lunn.ch>
      cc: alexander.h.duyck@intel.com
      Acked-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3d53666b40007b55204ee8890618da79a20c9940
  Author: Alex Gartrell <agartrell@fb.com>
  Date:   Mon Oct 6 08:46:19 2014 -0700
 =20
      ipvs: Avoid null-pointer deref in debug code
     =20
      Use daddr instead of reaching into dest.
     =20
      Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: Alex Gartrell <agartrell@fb.com>
      Signed-off-by: Simon Horman <horms@verge.net.au>
 =20
  commit f89b7755f517cdbb755d7543eef986ee9d54e654
  Author: Alexei Starovoitov <ast@plumgrid.com>
  Date:   Thu Oct 23 18:41:08 2014 -0700
 =20
      bpf: split eBPF out of NET
     =20
      introduce two configs:
      - hidden CONFIG_BPF to select eBPF interpreter that classic socket fi=
lters
        depend on
      - visible CONFIG_BPF_SYSCALL (default off) that tracing and sockets c=
an use
     =20
      that solves several problems:
      - tracing and others that wish to use eBPF don't need to depend on NE=
T.
        They can use BPF_SYSCALL to allow loading from userspace or select =
BPF
        to use it directly from kernel in NET-less configs.
      - in 3.18 programs cannot be attached to events yet, so don't force i=
t on
      - when the rest of eBPF infra is there in 3.19+, it's still useful to
        switch it off to minimize kernel size
     =20
      bloat-o-meter on x64 shows:
      add/remove: 0/60 grow/shrink: 0/2 up/down: 0/-15601 (-15601)
     =20
      tested with many different config combinations. Hopefully didn't miss=
 anything.
     =20
      Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
      Acked-by: Daniel Borkmann <dborkman@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8ae3c911b9efcca653c552a9c74957a6cb04a87d
  Merge: 5d26b1f 3bb0626
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 27 19:00:16 2014 -0400
 =20
      Merge branch 'cxgb4-net'
     =20
      Anish Bhatt says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      cxgb4 : DCBx fixes for apps/host lldp agents
     =20
      This patchset  contains some minor fixes for cxgb4 DCBx code. Chiefly=
, cxgb4
      was not cleaning up any apps added to kernel app table when link was =
lost.
      Disabling DCBx in firmware would automatically set DCBx state to host=
-managed
      and enabled, we now wait for an explicit enable call from an lldp age=
nt instead
     =20
      First patch was originally sent to net-next, but considering it appli=
es to
      correcting behaviour of code already in net, I think it qualifies as =
a bug fix.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3bb062613b1ecbd0c388106f61344d699f7859ec
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Thu Oct 23 14:37:31 2014 -0700
 =20
      cxgb4 : Handle dcb enable correctly
     =20
      Disabling DCBx in firmware automatically enables DCBx for control via=
 host
      lldp agents. Wait for an explicit setstate call from an lldp agents t=
o enable
       DCBx instead.
     =20
      Fixes: 76bcb31efc06 ("cxgb4 : Add DCBx support codebase and dcbnl_ops=
")
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 2376c879b80c83424a3013834be97fb9fe2d4180
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Thu Oct 23 14:37:30 2014 -0700
 =20
      cxgb4 : Improve handling of DCB negotiation or loss thereof
     =20
      Clear out any DCB apps we might have added to kernel table when we lo=
se DCB
      sync (or IEEE equivalent event). These were previously left behind an=
d not
      cleaned up correctly. IEEE allows individual components to work indep=
endently,
       so improve check for IEEE completion by specifying individual compon=
ents.
     =20
      Fixes: 10b0046685ab ("cxgb4: IEEE fixes for DCBx state machine")
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5d26b1f50a610fb28700cdc3446590495a5f607c
  Merge: 93a35f5 7965ee9
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 27 18:47:40 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      Netfilter fixes for net
     =20
      The following patchset contains Netfilter fixes for your net tree,
      they are:
     =20
      1) Allow to recycle a TCP port in conntrack when the change role from
         server to client, from Marcelo Leitner.
     =20
      2) Fix possible off by one access in ip_set_nfnl_get_byindex(), patch
         from Dan Carpenter.
     =20
      3) alloc_percpu returns NULL on error, no need for IS_ERR() in nf_tab=
les
         chain statistic updates. From Sabrina Dubroca.
     =20
      4) Don't compile ip options in bridge netfilter, this mangles the pac=
ket
         and bridge should not alter layer >=3D 3 headers when forwarding p=
ackets.
         Patch from Herbert Xu and tested by Florian Westphal.
     =20
      5) Account the final NLMSG_DONE message when calculating the size of =
the
         nflog netlink batches. Patch from Florian Westphal.
     =20
      6) Fix a possible netlink attribute length overflow with large packet=
s.
         Again from Florian Westphal.
     =20
      7) Release the skbuff if nfnetlink_log fails to put the final
         NLMSG_DONE message. This fixes a leak on error. This shouldn't eve=
r
         happen though, otherwise this means we miscalculate the netlink ba=
tch
         size, so spot a warning if this ever happens so we can track down =
the
         problem. This patch from Houcheng Lin.
     =20
      8) Look at the right list when recycling targets in the nft_compat,
         patch from Arturo Borrero.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7965ee93719921ea5978f331da653dfa2d7b99f5
  Author: Arturo Borrero <arturo.borrero.glez@gmail.com>
  Date:   Sun Oct 26 12:22:40 2014 +0100
 =20
      netfilter: nft_compat: fix wrong target lookup in nft_target_select_o=
ps()
     =20
      The code looks for an already loaded target, and the correct list to =
search
      is nft_target_list, not nft_match_list.
     =20
      Signed-off-by: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com=
>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 99c814066e75d09e6a38574c6c395f022a04b730
  Merge: fad1dbc 11b2357
  Author: John W. Linville <linville@tuxdriver.com>
  Date:   Mon Oct 27 13:38:15 2014 -0400
 =20
      Merge tag 'mac80211-for-john-2014-10-23' of git://git.kernel.org/pub/=
scm/linux/kernel/git/jberg/mac80211
     =20
      Johannes Berg <johannes@sipsolutions.net> says:
     =20
      "Here are a few fixes for the wireless stack: one fixes the
      RTS rate, one for a debugfs file, one to return the correct
      channel to userspace, a sanity check for a userspace value
      and the remaining two are just documentation fixes."
     =20
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit fad1dbc8efb4e51e121c745a99c0fb22b420a5c6
  Merge: 0805420 7f2ac8f
  Author: John W. Linville <linville@tuxdriver.com>
  Date:   Mon Oct 27 13:35:59 2014 -0400
 =20
      Merge tag 'iwlwifi-for-john-2014-10-23' of git://git.kernel.org/pub/s=
cm/linux/kernel/git/iwlwifi/iwlwifi-fixes
     =20
      Emmanuel Grumbach <egrumbach@gmail.com> says:
     =20
      "I revert here a patch that caused interoperability issues.
      dvm gets a fix for a bug that was reported by many users.
      Two minor fixes for BT Coex and platform power fix that helps
      reducing latency when the PCIe link goes to low power states."
     =20
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 93a35f59f1b13a02674877e3efdf07ae47e34052
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 23 06:30:30 2014 -0700
 =20
      net: napi_reuse_skb() should check pfmemalloc
     =20
      Do not reuse skb if it was pfmemalloc tainted, otherwise
      future frame might be dropped anyway.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit aa9c5579153535fb317a9d34c7d8eaf02b7ef4cd
  Merge: b71e821 bf1bac5
  Author: David S. Miller <davem@davemloft.net>
  Date:   Sun Oct 26 22:46:08 2014 -0400
 =20
      Merge branch 'mellanox'
     =20
      Eli Cohen says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      irq sync fixes
     =20
      This two patch series fixes a race where an interrupt handler could a=
ccess a
      freed memory.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit bf1bac5b7882daa41249f85fbc97828f0597de5c
  Author: Eli Cohen <eli@dev.mellanox.co.il>
  Date:   Thu Oct 23 15:57:27 2014 +0300
 =20
      net/mlx4_core: Call synchronize_irq() before freeing EQ buffer
     =20
      After moving the EQ ownership to software effectively destroying it, =
call
      synchronize_irq() to ensure that any handler routines running on othe=
r CPU
      cores finish execution. Only then free the EQ buffer.
      The same thing is done when we destroy a CQ which is one of the sourc=
es
      generating interrupts. In the case of CQ we want to avoid completion =
handlers
      on a CQ that was destroyed. In the case we do the same to avoid recei=
ving
      asynchronous events after the EQ has been destroyed and its buffers f=
reed.
     =20
      Signed-off-by: Eli Cohen <eli@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 96e4be06cbfcb8c9c2da7c77bacce0e56b581c0b
  Author: Eli Cohen <eli@dev.mellanox.co.il>
  Date:   Thu Oct 23 15:57:26 2014 +0300
 =20
      net/mlx5_core: Call synchronize_irq() before freeing EQ buffer
     =20
      After destroying the EQ, the object responsible for generating interr=
upts, call
      synchronize_irq() to ensure that any handler routines running on othe=
r CPU
      cores finish execution. Only then free the EQ buffer. This patch solv=
es a very
      rare case when we get panic on driver unload.
      The same thing is done when we destroy a CQ which is one of the sourc=
es
      generating interrupts. In the case of CQ we want to avoid completion =
handlers
      on a CQ that was destroyed. In the case we do the same to avoid recei=
ving
      asynchronous events after the EQ has been destroyed and its buffers f=
reed.
     =20
      Signed-off-by: Eli Cohen <eli@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b71e821de50f0ff92f10f33064ee1713e9014158
  Author: Geert Uytterhoeven <geert@linux-m68k.org>
  Date:   Thu Oct 23 10:25:53 2014 +0200
 =20
      drivers: net: xgene: Rewrite buggy loop in xgene_enet_ecc_init()
     =20
      drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function =E2=80=
=98xgene_enet_ecc_init=E2=80=99:
      drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:126: warning: =E2=
=80=98data=E2=80=99 may be used uninitialized in this function
     =20
      Depending on the arbitrary value on the stack, the loop may terminate
      too early, and cause a bogus -ENODEV failure.
     =20
      Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 013f6579c6e4f9517127a176bfc37bbac0b766cb
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Wed Oct 22 20:06:29 2014 -0700
 =20
      i40e: _MASK vs _SHIFT typo in i40e_handle_mdd_event()
     =20
      We accidentally mask by the _SHIFT variable.  It means that "event" i=
s
      always zero.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Tested-by: Jim Young <jamesx.m.young@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit fe0ca7328d03d36aafecebb3af650e1bb2841c20
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Wed Oct 22 19:43:46 2014 -0700
 =20
      macvlan: fix a race on port dismantle and possible skb leaks
     =20
      We need to cancel the work queue after rcu grace period,
      otherwise it can be rescheduled by incoming packets.
     =20
      We need to purge queue if some skbs are still in it.
     =20
      We can use __skb_queue_head_init() variant in
      macvlan_process_broadcast()
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 412ca1550cbec ("macvlan: Move broadcasts into a work queue")
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 349ce993ac706869d553a1816426d3a4bfda02b1
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 23 12:58:58 2014 -0700
 =20
      tcp: md5: do not use alloc_percpu()
     =20
      percpu tcp_md5sig_pool contains memory blobs that ultimately
      go through sg_set_buf().
     =20
      -> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
     =20
      This requires that whole area is in a physically contiguous portion
      of memory. And that @buf is not backed by vmalloc().
     =20
      Given that alloc_percpu() can use vmalloc() areas, this does not
      fit the requirements.
     =20
      Replace alloc_percpu() by a static DEFINE_PER_CPU() as tcp_md5sig_poo=
l
      is small anyway, there is no gain to dynamically allocate it.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 765cf9976e93 ("tcp: md5: remove one indirection level in tcp_m=
d5sig_pool")
      Reported-by: Crestez Dan Leonard <cdleonard@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 4cc40af08032a513e2e68fa6d7818b77179a86af
  Merge: 5345c1d ecf08d2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Sat Oct 25 14:15:25 2014 -0400
 =20
      Merge branch 'xen-netback'
     =20
      David Vrabel says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      xen-netback: guest Rx queue drain and stall fixes
     =20
      This series fixes two critical xen-netback bugs.
     =20
      1. Netback may consume all of host memory by queuing an unlimited
         number of skb on the internal guest Rx queue.  This behaviour is
         guest triggerable.
     =20
      2. Carrier flapping under high traffic rates which reduces
         performance.
     =20
      The first patch is a prerequite.  Removing support for frontends with
      feature-rx-notify makes it easier to reason about the correctness of
      netback since it no longer has to support this outdated and broken
      mode.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:55 2014 +0100
 =20
      xen-netback: reintroduce guest Rx stall detection
     =20
      If a frontend not receiving packets it is useful to detect this and
      turn off the carrier so packets are dropped early instead of being
      queued and drained when they expire.
     =20
      A to-guest queue is stalled if it doesn't have enough free slots for =
a
      an extended period of time (default 60 s).
     =20
      If at least one queue is stalled, the carrier is turned off (in the
      expectation that the other queues will soon stall as well).  The
      carrier is only turned on once all queues are ready.
     =20
      When the frontend connects, all the queues start in the stalled state
      and only become ready once the frontend queues enough Rx requests.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Reviewed-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f48da8b14d04ca87ffcffe68829afd45f926ec6a
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:54 2014 +0100
 =20
      xen-netback: fix unlimited guest Rx internal queue and carrier flappi=
ng
     =20
      Netback needs to discard old to-guest skb's (guest Rx queue drain) an=
d
      it needs detect guest Rx stalls (to disable the carrier so packets ar=
e
      discarded earlier), but the current implementation is very broken.
     =20
      1. The check in hard_start_xmit of the slot availability did not
         consider the number of packets that were already in the guest Rx
         queue.  This could allow the queue to grow without bound.
     =20
         The guest stops consuming packets and the ring was allowed to fill
         leaving S slot free.  Netback queues a packet requiring more than =
S
         slots (ensuring that the ring stays with S slots free).  Netback
         queue indefinately packets provided that then require S or fewer
         slots.
     =20
      2. The Rx stall detection is not triggered in this case since the
         (host) Tx queue is not stopped.
     =20
      3. If the Tx queue is stopped and a guest Rx interrupt occurs, netbac=
k
         will consider this an Rx purge event which may result in it taking
         the carrier down unnecessarily.  It also considers a queue with
         only 1 slot free as unstalled (even though the next packet might
         not fit in this).
     =20
      The internal guest Rx queue is limited by a byte length (to 512 Kib,
      enough for half the ring).  The (host) Tx queue is stopped and starte=
d
      based on this limit.  This sets an upper bound on the amount of memor=
y
      used by packets on the internal queue.
     =20
      This allows the estimatation of the number of slots for an skb to be
      removed (it wasn't a very good estimate anyway).  Instead, the guest
      Rx thread just waits for enough free slots for a maximum sized packet=
.
     =20
      skbs queued on the internal queue have an 'expires' time (set to the
      current time plus the drain timeout).  The guest Rx thread will detec=
t
      when the skb at the head of the queue has expired and discard expired
      skbs.  This sets a clear upper bound on the length of time an skb can
      be queued for.  For a guest being destroyed the maximum time needed t=
o
      wait for all the packets it sent to be dropped is still the drain
      timeout (10 s) since it will not be sending new packets.
     =20
      Rx stall detection is reintroduced in a later commit.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Reviewed-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit bc96f648df1bbc2729abbb84513cf4f64273a1f1
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:53 2014 +0100
 =20
      xen-netback: make feature-rx-notify mandatory
     =20
      Frontends that do not provide feature-rx-notify may stall because
      netback depends on the notification from frontend to wake the guest R=
x
      thread (even if can_queue is false).
     =20
      This could be fixed but feature-rx-notify was introduced in 2006 and =
I
      am not aware of any frontends that do not implement this.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Acked-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5345c1d417c1b0caf46fd2766d16bb4357a347d8
  Author: Richard Cochran <richardcochran@gmail.com>
  Date:   Wed Oct 22 21:35:15 2014 +0200
 =20
      ptp: restore the makefile for building the test program.
     =20
      This patch brings back the makefile called testptp.mk which was remov=
ed
      in commit adb19fb66eee (Documentation: add makefiles for more targets=
).
     =20
      While the idea of that commit was to improve build coverage of the
      examples, the new Makefile is unable to cross compile the testptp pro=
gram.
      In contrast, the deleted makefile was able to do this just fine.
     =20
      This patch fixes the regression by restoring the original makefile.
     =20
      Signed-off-by: Richard Cochran <richardcochran@gmail.com>
      Acked-by: Peter Foley <pefoley2@pefoley.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b51d3fa364885a2c1e1668f88776c67c95291820
  Author: Houcheng Lin <houcheng@gmail.com>
  Date:   Thu Oct 23 10:36:08 2014 +0200
 =20
      netfilter: nf_log: release skbuff on nlmsg put failure
     =20
      The kernel should reserve enough room in the skb so that the DONE
      message can always be appended.  However, in case of e.g. new attribu=
te
      erronously not being size-accounted for, __nfulnl_send() will still
      try to put next nlmsg into this full skbuf, causing the skb to be stu=
ck
      forever and blocking delivery of further messages.
     =20
      Fix issue by releasing skb immediately after nlmsg_put error and
      WARN() so we can track down the cause of such size mismatch.
     =20
      [ fw@strlen.de: add tailroom/len info to WARN ]
     =20
      Signed-off-by: Houcheng Lin <houcheng@gmail.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit c1e7dc91eed0ed1a51c9b814d648db18bf8fc6e9
  Author: Florian Westphal <fw@strlen.de>
  Date:   Thu Oct 23 10:36:07 2014 +0200
 =20
      netfilter: nfnetlink_log: fix maximum packet length logged to userspa=
ce
     =20
      don't try to queue payloads > 0xffff - NLA_HDRLEN, it does not work.
      The nla length includes the size of the nla struct, so anything large=
r
      results in u16 integer overflow.
     =20
      This patch is similar to
      9cefbbc9c8f9abe (netfilter: nfnetlink_queue: cleanup copy_range usage=
).
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 9dfa1dfe4d5e5e66a991321ab08afe69759d797a
  Author: Florian Westphal <fw@strlen.de>
  Date:   Thu Oct 23 10:36:06 2014 +0200
 =20
      netfilter: nf_log: account for size of NLMSG_DONE attribute
     =20
      We currently neither account for the nlattr size, nor do we consider
      the size of the trailing NLMSG_DONE when allocating nlmsg skb.
     =20
      This can result in nflog to stop working, as __nfulnl_send() re-tries
      sending forever if it failed to append NLMSG_DONE (which will never
      work if buffer is not large enough).
     =20
      Reported-by: Houcheng Lin <houcheng@gmail.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7677e86843e2136a9b05549a9ca47d4f744565b6
  Author: Herbert Xu <herbert@gondor.apana.org.au>
  Date:   Sat Oct 4 22:18:02 2014 +0800
 =20
      bridge: Do not compile options in br_parse_ip_options
     =20
      Commit 462fb2af9788a82a534f8184abfde31574e1cfa0
     =20
      	bridge : Sanitize skb before it enters the IP stack
     =20
      broke when IP options are actually used because it mangles the
      skb as if it entered the IP stack which is wrong because the
      bridge is supposed to operate below the IP stack.
     =20
      Since nobody has actually requested for parsing of IP options
      this patch fixes it by simply reverting to the previous approach
      of ignoring all IP options, i.e., zeroing the IPCB.
     =20
      If and when somebody who uses IP options and actually needs them
      to be parsed by the bridge complains then we can revisit this.
     =20
      Reported-by: David Newall <davidn@davidnewall.com>
      Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
      Tested-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7f2ac8fb31896c9fb70dbd2a2e6642b79996fc13
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Thu Oct 23 08:53:21 2014 +0300
 =20
      iwlwifi: pcie: fix polling in various places
     =20
      iwl_poll_bit may return a strictly positive value when the
      poll doesn't match on the first try.
      This was caught when WoWLAN started failing upon resume
      even if the poll_bit actually succeeded.
     =20
      Also change a wrong print. If we reach the end of
      iwl_pcie_prepare_card_hw, it means that we couldn't
      get the devices.
     =20
      Reviewed-by: Johannes Berg <johannes.berg@intel.com>
      Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 1ffde699aae127e7abdb98dbdedc2cc6a973a1a1
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Oct 20 08:29:55 2014 +0300
 =20
      Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate"
     =20
      This reverts commit aa11bbf3df026d6b1c6b528bef634fd9de7c2619.
      This commit was causing connection issues and is not needed
      if IWL_MVM_RS_RSSI_BASED_INIT_RATE is set to false by default.
     =20
      Regardless of the issues mentioned above, this patch added the
      following WARNING:
     =20
      WARNING: CPU: 0 PID: 3946 at drivers/net/wireless/iwlwifi/mvm/tx.c:19=
0 iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]()
      Got an HT rate for a non data frame 0x8
      CPU: 0 PID: 3946 Comm: wpa_supplicant Tainted: G           O   3.17.0=
+ #6
      Hardware name: LENOVO 20ANCTO1WW/20ANCTO1WW, BIOS GLET71WW (2.25 ) 07=
/02/2014
       0000000000000009 ffffffff814fa911 ffff8804288db8f8 ffffffff81064f52
       0000000000001808 ffff8804288db948 ffff88040add8660 ffff8804291b5600
       0000000000000000 ffffffff81064fb7 ffffffffa07b73d0 0000000000000020
      Call Trace:
       [<ffffffff814fa911>] ? dump_stack+0x41/0x51
       [<ffffffff81064f52>] ? warn_slowpath_common+0x72/0x90
       [<ffffffff81064fb7>] ? warn_slowpath_fmt+0x47/0x50
       [<ffffffffa07a39ea>] ? iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]
       [<ffffffffa07a3cf8>] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm]
       [<ffffffffa079cb9b>] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm]
       [<ffffffffa0746ce9>] ? __ieee80211_tx+0x2b9/0x3c0 [mac80211]
       [<ffffffffa07492f3>] ? ieee80211_tx+0xb3/0x100 [mac80211]
       [<ffffffffa0749c49>] ? ieee80211_subif_start_xmit+0x459/0xca0 [mac80=
211]
       [<ffffffff814116e7>] ? dev_hard_start_xmit+0x337/0x5f0
       [<ffffffff81430d46>] ? sch_direct_xmit+0x96/0x1f0
       [<ffffffff81411ba3>] ? __dev_queue_xmit+0x203/0x4f0
       [<ffffffff8142f670>] ? ether_setup+0x70/0x70
       [<ffffffff814e96a1>] ? packet_sendmsg+0xf81/0x1110
       [<ffffffff8140625c>] ? skb_free_datagram+0xc/0x40
       [<ffffffff813f7538>] ? sock_sendmsg+0x88/0xc0
       [<ffffffff813f7274>] ? move_addr_to_kernel.part.20+0x14/0x60
       [<ffffffff811c47c2>] ? __inode_wait_for_writeback+0x62/0xb0
       [<ffffffff813f7a91>] ? SYSC_sendto+0xf1/0x180
       [<ffffffff813f88f9>] ? __sys_recvmsg+0x39/0x70
       [<ffffffff8150066d>] ? system_call_fastpath+0x1a/0x1f
      ---[ end trace cc19a150d311fc63 ]---
     =20
      which was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=
=3D85691
     =20
      CC: <stable@vger.kernel.org> [3.13+]
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit a0855054e59b0c5b2b00237fdb5147f7bcc18efb
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Sun Oct 5 09:11:14 2014 +0300
 =20
      iwlwifi: dvm: drop non VO frames when flushing
     =20
      When mac80211 wants to ensure that a frame is sent, it calls
      the flush() callback. Until now, iwldvm implemented this by
      waiting that all the frames are sent (ACKed or timeout).
      In case of weak signal, this can take a significant amount
      of time, delaying the next connection (in case of roaming).
      Many users have reported that the flush would take too long
      leading to the following error messages to be printed:
     =20
      iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2
      iwlwifi 0000:03:00.0: Current SW read_ptr 161 write_ptr 201
      iwl data: 00000000: 00 00 00 00 00 00 00 00 fe ff 01 00 00 00 00 00
      [snip]
      iwlwifi 0000:03:00.0: FH TRBs(0) =3D 0x00000000
      [snip]
      iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x000=
0 [9,9]
      [snip]
     =20
      Instead of waiting for these packets, simply drop them. This
      significantly improves the responsiveness of the network.
      Note that all the queues are flushed, but the VO one. This
      is not typically used by the applications and it likely
      contains management frames that are useful for connection
      or roaming.
     =20
      This bug is tracked here:
      https://bugzilla.kernel.org/show_bug.cgi?id=3D56581
     =20
      But it is duplicated in distributions' trackers.
      A simple search in Ubuntu's database led to these bugs:
     =20
      https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1270808
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305406
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356236
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1360597
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361809
     =20
      Cc: <stable@vger.kernel.org>
      Depends-on: 77be2c54c5bd ("mac80211: add vif to flush call")
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit a6cc5163149532734b84c86cbffa4994e527074b
  Author: Matti Gottlieb <matti.gottlieb@intel.com>
  Date:   Mon Sep 29 11:46:04 2014 +0300
 =20
      iwlwifi: mvm: ROC - bug fixes around time events and locking
     =20
      Don't add the time event to the list. We added it several
      times the same time event, which leads to an infinite loop
      when walking the list.
     =20
      Since we (currently) don't support more than one ROC for STA
      vif at a time, enforce this and don't add the time event
      to any list.
     =20
      We were also missing the locking of the mutex which led to
      a lockdep splat - fix that.
     =20
      Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 79b7a69d730180d8bf535e52fe2b4f3dd5904007
  Author: Haim Dreyfuss <haim.dreyfuss@intel.com>
  Date:   Sun Sep 14 12:40:00 2014 +0300
 =20
      iwlwifi: mvm: Add tx power condition to bss_info_changed_ap_ibss
     =20
      The tx power should be limited from many reasons.
      currently, setting the tx power is available by the mvm only for
      station interface. Adding the tx power condition to
      bss_info_changed_ap_ibss make it available also for AP.
     =20
      Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 3856b78c1be32a2afe0618c7a84e05ff8c03cf10
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Sep 22 12:03:41 2014 +0300
 =20
      iwlwifi: mvm: BT coex - fix BT prio for probe requests
     =20
      The probe requests sent during scan must get BT prio 3.
      Fix that.
     =20
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit d14b28fd2c61af0bf310230472e342864d799c98
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Sep 22 16:12:24 2014 +0300
 =20
      iwlwifi: mvm: BT Coex - update the MPLUT Boost register value
     =20
      Cc: <stable@vger.kernel.org> [3.16+]
      Fixes: 2adc8949efab ("iwlwifi: mvm: BT Coex - fix boost register / LU=
T values")
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 405b7338abc5ceac4a420ce7f49cc9b530d4e78b
  Author: Liad Kaufman <liad.kaufman@intel.com>
  Date:   Tue Sep 23 15:15:17 2014 +0300
 =20
      iwlwifi: 8000: fix string given to MODULE_FIRMWARE
     =20
      I changed the string but forgot to update the fix also to
      MODULE_FIRMWARE().
     =20
      Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 9180ac50716a097a407c6d7e7e4589754a922260
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Tue Sep 23 23:02:41 2014 +0300
 =20
      iwlwifi: configure the LTR
     =20
      The LTR is the handshake between the device and the root
      complex about the latency allowed when the bus exits power
      save. This configuration was missing and this led to high
      latency in the link power up. The end user could experience
      high latency in the network because of this.
     =20
      Cc: <stable@vger.kernel.org> [3.10+]
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 08054200117a95afc14c3d2ed3a38bf4e345bf78
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Thu Oct 23 11:27:09 2014 -0500
 =20
      rtlwifi: Add check for get_btc_status callback
     =20
      Drivers that do not use the get_btc_status() callback may not define =
a
      dummy routine. The caller needs to check before making the call.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
      Cc: Thadeu Cascardo <cascardo@cascardo.eti.br>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 763254516187015cb5b391553af35c6ed1f4bb36
  Author: Felix Fietkau <nbd@openwrt.org>
  Date:   Wed Oct 22 18:17:35 2014 +0200
 =20
      ath9k_common: always update value in ath9k_cmn_update_txpow
     =20
      In some cases the limit may be the same as reg->power_limit, but the
      actual value that the hardware uses is not up to date. In that case, =
a
      wrong value for current tx power is tracked internally.
      Fix this by unconditionally updating it.
     =20
      Signed-off-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 4f2b244c7d5b81ce4f0c6c0382f3a3b7c2dbec1c
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:34 2014 +0200
 =20
      rtl8192cu: Prevent Ooops under rtl92c_set_fw_rsvdpagepkt
     =20
      rtl92c_set_fw_rsvdpagepkt is used by rtl8192cu and its pci sibling rt=
l8192ce.
      rtl_cmd_send_packet crashes when called inside rtl8192cu because it w=
orks on
      memory allocated only by rtl8192ce.
      Fix the crash by calling a dummy function when used in rtl8192cu.
      Comparision with the realtek vendor driver makes me think, something =
is missing in
      the dummy function.
      Short test as WPA2 station show good results connected to an 802.11g =
basestation.
      Traffic stops after few MBytes as WPA2 station connected to an 802.11=
n basestation.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit cefe3dfdb9f5f498cae9871f7e52800f5e22c614
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:33 2014 +0200
 =20
      rtl8192cu: Call ieee80211_register_hw from rtl_usb_probe
     =20
      In a previous patch the call to ieee80211_register_hw was moved from =
the
      load firmware callback to the rtl_pci_probe only.
      rt8192cu also uses this callback. Currently it doesnt create a wlan%d=
 device.
      Fill in the call to ieee80211_register_hw in rtl_usb_probe.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit b2d624a5810203a1a8b7735e1ec5685109b22fc3
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:32 2014 +0200
 =20
      rtl8192cu: Fix for rtlwifi's bluetooth coexist functionality
     =20
      Initialize function pointer with a function indicating bt coexist is =
not there.
      Prevents Ooops.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 94e05900770c0abe31200881df93e41d296fe8bd
  Author: Felix Fietkau <nbd@openwrt.org>
  Date:   Wed Oct 22 15:27:53 2014 +0200
 =20
      ath: use CTL region from cfg80211 if unset in EEPROM
     =20
      Many AP devices do not have the proper regulatory domain programmed i=
n
      EEPROM. Instead they expect the software to set the appropriate regio=
n.
      For these devices, the country code defaults to US, and the driver us=
es
      the US CTL tables as well.
      On devices bought in Europe this can lead to tx power being set too h=
igh
      on the band edges, even if the cfg80211 regdomain is set correctly.
      Fix this issue by taking into account the DFS region, but only when t=
he
      EEPROM regdomain is set to default.
     =20
      Signed-off-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit d514aefb8ce89562ef2d7dcddc530e5de6287c4b
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Tue Oct 21 10:52:51 2014 -0500
 =20
      rtlwifi: rtl8821ae: Fix possible array overrun
     =20
      The kbuild test robot reported a possible array overrun. The affected=
 code
      checks for overruns, but fails to take the steps necessary to fix the=
m.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 868caae3fe2e35e2353d86af95e03eeaa9439d97
  Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Date:   Tue Oct 21 19:23:02 2014 +0530
 =20
      ath9k: Enable HW queue control only for MCC
     =20
      Enabling HW queue control for normal (non-mcc) mode
      causes problems with queue management, resulting
      in traffic stall. Since it is mainly required for
      fairness in MCC mode, disable it for the general case.
     =20
      Bug: https://dev.openwrt.org/ticket/18164
     =20
      Cc: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 598a0df07fc6c4642f9b0497cef1233e41d4c987
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Oct 20 14:57:08 2014 -0700
 =20
      rtlwifi: prevent format string usage from leaking
     =20
      Use "%s" in the workqueue allocation to make sure the rtl_hal_cfg nam=
e
      can never accidentally leak information via a format string.
     =20
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 34b6d4299923ec9101bbf364440cee36420b3fc0
  Author: Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
  Date:   Wed Oct 15 07:51:44 2014 +0200
 =20
      bcma: add another PCI ID of device with BCM43228
     =20
      It was found attached to the BCM47081A0 SoC. Log:
      bcma: bus0: Found chip with id 43228, rev 0x00 and package 0x08
     =20
      Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 59dfdd92288e55bed374309a9944c3a95b4e13c9
  Author: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
  Date:   Sun Oct 12 13:42:14 2014 +0200
 =20
      brcmfmac: dhd_sdio.c: Cleaning up missing null-terminate in conjuncti=
on with strncpy
     =20
      Replacing strncpy with strlcpy to avoid strings that lacks null termi=
nate.
      And changed from using strncat to strlcat to simplify code.
     =20
      Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigit=
al.se>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 47481d977cb2987ab363202c68a79ec1bccd357c
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Sat Oct 11 12:59:53 2014 -0500
 =20
      rtlwifi: rtl8192ee: Prevent log spamming for switch statements
     =20
      The driver logs a message when the default branch of switch statement=
s are
      taken. Such information is useful when debugging, but these log items=
 should
      not be seen for standard usage.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 78afe83c3b008e25123bd1be36ee4b6595e595d1
  Author: Hauke Mehrtens <hauke@hauke-m.de>
  Date:   Thu Oct 9 23:39:41 2014 +0200
 =20
      bcma: fix build when CONFIG_OF_ADDRESS is not set
     =20
      Commit 2101e533f41a ("bcma: register bcma as device tree driver")
      introduces a hard dependency on OF_ADDRESS into the bcma driver.
      OF_ADDRESS is specifically disabled for the sparc architecture.
      This results in the following error when building sparc64:allmodconfi=
g.
     =20
      drivers/bcma/main.c: In function 'bcma_of_find_child_device':
      drivers/bcma/main.c:150:3: error: implicit declaration of function 'o=
f_translate_address'
     =20
      Fixes: 2101e533f41a ("bcma: register bcma as device tree driver")
      Reported-by: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 942396b01989d54977120f3625e5ba31afe7a75c
  Author: Haiyang Zhang <haiyangz@microsoft.com>
  Date:   Wed Oct 22 13:47:18 2014 -0700
 =20
      hyperv: Fix the total_data_buflen in send path
     =20
      total_data_buflen is used by netvsc_send() to decide if a packet can =
be put
      into send buffer. It should also include the size of RNDIS message be=
fore the
      Ethernet frame. Otherwise, a messge with total size bigger than send_=
section_size
      may be copied into the send buffer, and cause data corruption.
     =20
      [Request to include this patch to the Stable branches]
     =20
      Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
      Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f765678e325b4ae3e2fbdb304fc2d5ee018aa860
  Merge: 81f35ff 55ca6bc
  Author: David S. Miller <davem@davemloft.net>
  Date:   Wed Oct 22 17:50:39 2014 -0400
 =20
      Merge branch 'amd-xgbe'
     =20
      Tom Lendacky says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      amd-xgbe: AMD XGBE driver fixes 2014-10-22
     =20
      The following series of patches includes fixes to the driver.
     =20
      - Properly handle feature changes via ethtool by using correctly size=
d
        variables
      - Perform proper napi packet counting and budget checking
     =20
      This patch series is based on net.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 55ca6bcd733b739d5667d48d7591899f376dcfb8
  Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Date:   Wed Oct 22 11:26:17 2014 -0500
 =20
      amd-xgbe: Fix napi Rx budget accounting
     =20
      Currently the amd-xgbe driver increments the packets processed counte=
r
      each time a descriptor is processed.  Since a packet can be represent=
ed
      by more than one descriptor incrementing the counter in this way is n=
ot
      appropriate.  Also, since multiple descriptors cause the budget check
      to be short circuited, sometimes the returned value from the poll
      function would be larger than the budget value resulting in a WARN_ON=
CE
      being triggered.
     =20
      Update the polling logic to properly account for the number of packet=
s
      processed and exit when the budget value is reached.
     =20
      Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 386f1c9650b7fe4849d2942bd42f41f0ca3aedfb
  Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Date:   Wed Oct 22 11:26:11 2014 -0500
 =20
      amd-xgbe: Properly handle feature changes via ethtool
     =20
      The ndo_set_features callback function was improperly using an unsign=
ed
      int to save the current feature value for features such as NETIF_F_RX=
CSUM.
      Since that feature is in the upper 32 bits of a 64 bit variable the
      result was always 0 making it not possible to actually turn off the
      hardware RX checksum support.  Change the unsigned int type to the
      netdev_features_t type in order to properly capture the current value
      and perform the proper operation.
     =20
      Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 81f35ffde0e95ee18de83646bbf93dda55d9cc8b
  Author: Philipp Zabel <p.zabel@pengutronix.de>
  Date:   Wed Oct 22 16:34:35 2014 +0200
 =20
      net: fec: ptp: fix NULL pointer dereference if ptp_clock is not set
     =20
      Since commit 278d24047891 (net: fec: ptp: Enable PPS output based on =
ptp clock)
      fec_enet_interrupt calls fec_ptp_check_pps_event unconditionally, whi=
ch calls
      into ptp_clock_event. If fep->ptp_clock is NULL, ptp_clock_event trie=
s to
      dereference the NULL pointer.
      Since on i.MX53 fep->bufdesc_ex is not set, fec_ptp_init is never cal=
led,
      and fep->ptp_clock is NULL, which reliably causes a kernel panic.
     =20
      This patch adds a check for fep->ptp_clock =3D=3D NULL in fec_enet_in=
terrupt.
     =20
      Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9e7ceb060754f134231f68cb29d5db31419fe1ed
  Author: Sathya Perla <sathya.perla@emulex.com>
  Date:   Wed Oct 22 21:42:01 2014 +0530
 =20
      net: fix saving TX flow hash in sock for outgoing connections
     =20
      The commit "net: Save TX flow hash in sock and set in skbuf on xmit"
      introduced the inet_set_txhash() and ip6_set_txhash() routines to cal=
culate
      and record flow hash(sk_txhash) in the socket structure. sk_txhash is=
 used
      to set skb->hash which is used to spread flows across multiple TXQs.
     =20
      But, the above routines are invoked before the source port of the con=
nection
      is created. Because of this all outgoing connections that just differ=
 in the
      source port get hashed into the same TXQ.
     =20
      This patch fixes this problem for IPv4/6 by invoking the the above ro=
utines
      after the source port is available for the socket.
     =20
      Fixes: b73c3d0e4("net: Save TX flow hash in sock and set in skbuf on =
xmit")
     =20
      Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
      Acked-by: Eric Dumazet <edumazet@google.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 789f202326640814c52f82e80cef3584d8254623
  Author: Li RongQing <roy.qing.li@gmail.com>
  Date:   Wed Oct 22 17:09:53 2014 +0800
 =20
      xfrm6: fix a potential use after free in xfrm6_policy.c
     =20
      pskb_may_pull() maybe change skb->data and make nh and exthdr pointer
      oboslete, so recompute the nd and exthdr
     =20
      Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8751b12cd93cc37337256f650e309b8364d40b35
  Author: LEROY Christophe <christophe.leroy@c-s.fr>
  Date:   Wed Oct 22 09:05:47 2014 +0200
 =20
      net: fs_enet: set back promiscuity mode after restart
     =20
      After interface restart (eg: after link disconnection/reconnection), =
the bridge
      function doesn't work anymore. This is due to the promiscuous mode be=
ing cleared
      by the restart.
     =20
      The mac-fcc already includes code to set the promiscuous mode back du=
ring the restart.
      This patch adds the same handling to mac-fec and mac-scc.
     =20
      Tested with bridge function on MPC885 with FEC.
     =20
      Reported-by: Germain Montoies <germain.montoies@c-s.fr>
      Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit a63ba13eec092b70d4e5522d692eaeb2f9747387
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Tue Oct 21 16:06:05 2014 +0200
 =20
      net: tso: fix unaligned access to crafted TCP header in helper API
     =20
      The crafted header start address is from a driver supplied buffer, wh=
ich
      one can reasonably expect to be aligned on a 4-bytes boundary.
      However ATM the TSO helper API is only used by ethernet drivers and
      the tcp header will then be aligned to a 2-bytes only boundary from t=
he
      header start address.
     =20
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8fc963515e893867330dec87464e9edc5204c024
  Author: Jon Cooper <jcooper@solarflare.com>
  Date:   Tue Oct 21 14:50:29 2014 +0100
 =20
      sfc: remove incorrect EFX_BUG_ON_PARANOID check
     =20
      write_count and insert_count can wrap around, making > check invalid.
     =20
      Fixes: 70b33fb0ddec827cbbd14cdc664fc27b2ef4a6b6 ("sfc: add support fo=
r
       skb->xmit_more").
     =20
      Signed-off-by: Edward Cree <ecree@solarflare.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c123bb7163043bb8f33858cf8e45b01c17dbd171
  Author: Sabrina Dubroca <sd@queasysnail.net>
  Date:   Tue Oct 21 11:08:21 2014 +0200
 =20
      netfilter: nf_tables: check for NULL in nf_tables_newchain pcpu stats=
 allocation
     =20
      alloc_percpu returns NULL on failure, not a negative error code.
     =20
      Fixes: ff3cd7b3c922 ("netfilter: nf_tables: refactor chain statistic =
routines")
      Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 0f9f5e1b83abd2b37c67658e02a6fc9001831fa5
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Tue Oct 21 11:28:12 2014 +0300
 =20
      netfilter: ipset: off by one in ip_set_nfnl_get_byindex()
     =20
      The ->ip_set_list[] array is initialized in ip_set_net_init() and it
      has ->ip_set_max elements so this check should be >=3D instead of >
      otherwise we are off by one.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit e37ad9fd636071e45368d1d9cc3b7b421281ce7f
  Author: Marcelo Leitner <mleitner@redhat.com>
  Date:   Mon Oct 13 13:09:28 2014 -0300
 =20
      netfilter: nf_conntrack: allow server to become a client in TW handli=
ng
     =20
      When a port that was used to listen for inbound connections gets clos=
ed
      and reused for outgoing connections (like rsh ends up doing for stder=
r
      flow), current we may reject the SYN/ACK packet for the new connectio=
n
      because tcp_conntracks states forbirds a port to become a client whil=
e
      there is still a TIME_WAIT entry in there for it.
     =20
      As TCP may expire the TIME_WAIT socket in 60s and conntrack's timeout
      for it is 120s, there is a ~60s window that the application can end u=
p
      opening a port that conntrack will end up blocking.
     =20
      This patch fixes this by simply allowing such state transition: if we
      see a SYN, in TIME_WAIT state, on REPLY direction, move it to sSS. No=
te
      that the rest of the code already handles this situation, more
      specificly in tcp_packet(), first switch clause.
     =20
      Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
      Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7c1c97d54f9bfc810908d3903cb8bcacf734df18
  Author: Sabrina Dubroca <sd@queasysnail.net>
  Date:   Tue Oct 21 11:23:30 2014 +0200
 =20
      net: sched: initialize bstats syncp
     =20
      Use netdev_alloc_pcpu_stats to allocate percpu stats and initialize s=
yncp.
     =20
      Fixes: 22e0f8b9322c "net: sched: make bstats per cpu and estimator RC=
U safe"
      Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
      Acked-by: Cong Wang <cwang@twopensource.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 32bf08a6257b9c7380dcd040af3c0858eee3ef05
  Author: Alexei Starovoitov <ast@plumgrid.com>
  Date:   Mon Oct 20 14:54:57 2014 -0700
 =20
      bpf: fix bug in eBPF verifier
     =20
      while comparing for verifier state equivalency the comparison
      was missing a check for uninitialized register.
      Make sure it does so and add a testcase.
     =20
      Fixes: f1bca824dabb ("bpf: add search pruning optimization to verifie=
r")
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
      Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 78fd1d0ab072d4d9b5f0b7c14a1516665170b565
  Author: Thomas Graf <tgraf@suug.ch>
  Date:   Tue Oct 21 22:05:38 2014 +0200
 =20
      netlink: Re-add locking to netlink_lookup() and seq walker
     =20
      The synchronize_rcu() in netlink_release() introduces unacceptable
      latency. Reintroduce minimal lookup so we can drop the
      synchronize_rcu() until socket destruction has been RCUfied.
     =20
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
      Reported-and-tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: Thomas Graf <tgraf@suug.ch>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1a194c2d59c55c37cb4c0c459d5418071a141341
  Author: Ying Xue <ying.xue@windriver.com>
  Date:   Mon Oct 20 14:46:35 2014 +0800
 =20
      tipc: fix lockdep warning when intra-node messages are delivered
     =20
      When running tipcTC&tipcTS test suite, below lockdep unsafe locking
      scenario is reported:
     =20
      [ 1109.997854]
      [ 1109.997988] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      [ 1109.998290] [ INFO: inconsistent lock state ]
      [ 1109.998575] 3.17.0-rc1+ #113 Not tainted
      [ 1109.998762] ---------------------------------
      [ 1109.998762] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [ 1109.998762] swapper/7/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [ 1109.998762]  (slock-AF_TIPC){+.?...}, at: [<ffffffffa0011969>] tip=
c_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762] {SOFTIRQ-ON-W} state was registered at:
      [ 1109.998762]   [<ffffffff810a4770>] __lock_acquire+0x6a0/0x1d80
      [ 1109.998762]   [<ffffffff810a6555>] lock_acquire+0x95/0x1e0
      [ 1109.998762]   [<ffffffff81a2d1ce>] _raw_spin_lock+0x3e/0x80
      [ 1109.998762]   [<ffffffffa0011969>] tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]   [<ffffffffa0004fe8>] tipc_link_xmit+0xa8/0xc0 [tipc]
      [ 1109.998762]   [<ffffffffa000ec6f>] tipc_sendmsg+0x15f/0x550 [tipc]
      [ 1109.998762]   [<ffffffffa000f165>] tipc_connect+0x105/0x140 [tipc]
      [ 1109.998762]   [<ffffffff817676ee>] SYSC_connect+0xae/0xc0
      [ 1109.998762]   [<ffffffff81767b7e>] SyS_connect+0xe/0x10
      [ 1109.998762]   [<ffffffff817a9788>] compat_SyS_socketcall+0xb8/0x20=
0
      [ 1109.998762]   [<ffffffff81a306e5>] sysenter_dispatch+0x7/0x1f
      [ 1109.998762] irq event stamp: 241060
      [ 1109.998762] hardirqs last  enabled at (241060): [<ffffffff8105a4ad=
>] __local_bh_enable_ip+0x6d/0xd0
      [ 1109.998762] hardirqs last disabled at (241059): [<ffffffff8105a46f=
>] __local_bh_enable_ip+0x2f/0xd0
      [ 1109.998762] softirqs last  enabled at (241020): [<ffffffff81059a52=
>] _local_bh_enable+0x22/0x50
      [ 1109.998762] softirqs last disabled at (241021): [<ffffffff8105a626=
>] irq_exit+0x96/0xc0
      [ 1109.998762]
      [ 1109.998762] other info that might help us debug this:
      [ 1109.998762]  Possible unsafe locking scenario:
      [ 1109.998762]
      [ 1109.998762]        CPU0
      [ 1109.998762]        ----
      [ 1109.998762]   lock(slock-AF_TIPC);
      [ 1109.998762]   <Interrupt>
      [ 1109.998762]     lock(slock-AF_TIPC);
      [ 1109.998762]
      [ 1109.998762]  *** DEADLOCK ***
      [ 1109.998762]
      [ 1109.998762] 2 locks held by swapper/7/0:
      [ 1109.998762]  #0:  (rcu_read_lock){......}, at: [<ffffffff81782dc9>=
] __netif_receive_skb_core+0x69/0xb70
      [ 1109.998762]  #1:  (rcu_read_lock){......}, at: [<ffffffffa0001c90>=
] tipc_l2_rcv_msg+0x40/0x260 [tipc]
      [ 1109.998762]
      [ 1109.998762] stack backtrace:
      [ 1109.998762] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.17.0-rc1+ =
#113
      [ 1109.998762] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [ 1109.998762]  ffffffff82745830 ffff880016c03828 ffffffff81a209eb 00=
00000000000007
      [ 1109.998762]  ffff880017b3cac0 ffff880016c03888 ffffffff81a1c5ef 00=
00000000000001
      [ 1109.998762]  ffff880000000001 ffff880000000000 ffffffff81012d4f 00=
00000000000000
      [ 1109.998762] Call Trace:
      [ 1109.998762]  <IRQ>  [<ffffffff81a209eb>] dump_stack+0x4e/0x68
      [ 1109.998762]  [<ffffffff81a1c5ef>] print_usage_bug+0x1f1/0x202
      [ 1109.998762]  [<ffffffff81012d4f>] ? save_stack_trace+0x2f/0x50
      [ 1109.998762]  [<ffffffff810a406c>] mark_lock+0x28c/0x2f0
      [ 1109.998762]  [<ffffffff810a3440>] ? print_irq_inversion_bug.part.4=
6+0x1f0/0x1f0
      [ 1109.998762]  [<ffffffff810a467d>] __lock_acquire+0x5ad/0x1d80
      [ 1109.998762]  [<ffffffff810a70dd>] ? trace_hardirqs_on+0xd/0x10
      [ 1109.998762]  [<ffffffff8108ace8>] ? sched_clock_cpu+0x98/0xc0
      [ 1109.998762]  [<ffffffff8108ad2b>] ? local_clock+0x1b/0x30
      [ 1109.998762]  [<ffffffff810a10dc>] ? lock_release_holdtime.part.29+=
0x1c/0x1a0
      [ 1109.998762]  [<ffffffff8108aa05>] ? sched_clock_local+0x25/0x90
      [ 1109.998762]  [<ffffffffa000dec0>] ? tipc_sk_get+0x60/0x80 [tipc]
      [ 1109.998762]  [<ffffffff810a6555>] lock_acquire+0x95/0x1e0
      [ 1109.998762]  [<ffffffffa0011969>] ? tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffff810a6fb6>] ? trace_hardirqs_on_caller+0xa6/=
0x1c0
      [ 1109.998762]  [<ffffffff81a2d1ce>] _raw_spin_lock+0x3e/0x80
      [ 1109.998762]  [<ffffffffa0011969>] ? tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffffa000dec0>] ? tipc_sk_get+0x60/0x80 [tipc]
      [ 1109.998762]  [<ffffffffa0011969>] tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffffa00076bd>] tipc_rcv+0x5ed/0x960 [tipc]
      [ 1109.998762]  [<ffffffffa0001d1c>] tipc_l2_rcv_msg+0xcc/0x260 [tipc=
]
      [ 1109.998762]  [<ffffffffa0001c90>] ? tipc_l2_rcv_msg+0x40/0x260 [ti=
pc]
      [ 1109.998762]  [<ffffffff81783345>] __netif_receive_skb_core+0x5e5/0=
xb70
      [ 1109.998762]  [<ffffffff81782dc9>] ? __netif_receive_skb_core+0x69/=
0xb70
      [ 1109.998762]  [<ffffffff81784eb9>] ? dev_gro_receive+0x259/0x4e0
      [ 1109.998762]  [<ffffffff817838f6>] __netif_receive_skb+0x26/0x70
      [ 1109.998762]  [<ffffffff81783acd>] netif_receive_skb_internal+0x2d/=
0x1f0
      [ 1109.998762]  [<ffffffff81785518>] napi_gro_receive+0xd8/0x240
      [ 1109.998762]  [<ffffffff815bf854>] e1000_clean_rx_irq+0x2c4/0x530
      [ 1109.998762]  [<ffffffff815c1a46>] e1000_clean+0x266/0x9c0
      [ 1109.998762]  [<ffffffff8108ad2b>] ? local_clock+0x1b/0x30
      [ 1109.998762]  [<ffffffff8108aa05>] ? sched_clock_local+0x25/0x90
      [ 1109.998762]  [<ffffffff817842b1>] net_rx_action+0x141/0x310
      [ 1109.998762]  [<ffffffff810bd710>] ? handle_fasteoi_irq+0xe0/0x150
      [ 1109.998762]  [<ffffffff81059fa6>] __do_softirq+0x116/0x4d0
      [ 1109.998762]  [<ffffffff8105a626>] irq_exit+0x96/0xc0
      [ 1109.998762]  [<ffffffff81a30d07>] do_IRQ+0x67/0x110
      [ 1109.998762]  [<ffffffff81a2ee2f>] common_interrupt+0x6f/0x6f
      [ 1109.998762]  <EOI>  [<ffffffff8100d2b7>] ? default_idle+0x37/0x250
      [ 1109.998762]  [<ffffffff8100d2b5>] ? default_idle+0x35/0x250
      [ 1109.998762]  [<ffffffff8100dd1f>] arch_cpu_idle+0xf/0x20
      [ 1109.998762]  [<ffffffff810999fd>] cpu_startup_entry+0x27d/0x4d0
      [ 1109.998762]  [<ffffffff81034c78>] start_secondary+0x188/0x1f0
     =20
      When intra-node messages are delivered from one process to another
      process, tipc_link_xmit() doesn't disable BH before it directly calls
      tipc_sk_rcv() on process context to forward messages to destination
      socket. Meanwhile, if messages delivered by remote node arrive at the
      node and their destinations are also the same socket, tipc_sk_rcv()
      running on process context might be preempted by tipc_sk_rcv() runnin=
g
      BH context. As a result, the latter cannot obtain the socket lock as
      the lock was obtained by the former, however, the former has no chanc=
e
      to be run as the latter is owning the CPU now, so headlock happens. T=
o
      avoid it, BH should be always disabled in tipc_sk_rcv().
     =20
      Signed-off-by: Ying Xue <ying.xue@windriver.com>
      Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7b8613e0a1502b43b3b36c93c66f835c891f63b3
  Author: Ying Xue <ying.xue@windriver.com>
  Date:   Mon Oct 20 14:44:25 2014 +0800
 =20
      tipc: fix a potential deadlock
     =20
      Locking dependency detected below possible unsafe locking scenario:
     =20
                 CPU0                          CPU1
      T0:  tipc_named_rcv()                tipc_rcv()
      T1:  [grab nametble write lock]*     [grab node lock]*
      T2:  tipc_update_nametbl()           tipc_node_link_up()
      T3:  tipc_nodesub_subscribe()        tipc_nametbl_publish()
      T4:  [grab node lock]*               [grab nametble write lock]*
     =20
      The opposite order of holding nametbl write lock and node lock on
      above two different paths may result in a deadlock. If we move the
      the updating of the name table after link state named out of node
      lock, the reverse order of holding locks will be eliminated, and
      as a result, the deadlock risk.
     =20
      Signed-off-by: Ying Xue <ying.xue@windriver.com>
      Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 73829bf6fec70703f10e360676d81d327f21ebf6
  Merge: d10845f 39dc90c
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 21 15:24:30 2014 -0400
 =20
      Merge branch 'enic'
     =20
      Govindarajulu Varadarajan says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      enic: Bug fixes
     =20
      This series fixes the following problem.
     =20
      Please apply this to net.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 39dc90c159c1bcc0fdd42913a7d560b1a1cd3acf
  Author: Govindarajulu Varadarajan <_govind@gmx.com>
  Date:   Sun Oct 19 14:20:28 2014 +0530
 =20
      enic: Do not call napi_disable when preemption is disabled.
     =20
      In enic_stop, we disable preemption using local_bh_disable(). We disa=
ble
      preemption to wait for busy_poll to finish.
     =20
      napi_disable should not be called here as it might sleep.
     =20
      Moving napi_disable() call out side of local_bh_disable.
     =20
      BUG: sleeping function called from invalid context at include/linux/n=
etdevice.h:477
      in_atomic(): 1, irqs_disabled(): 0, pid: 443, name: ifconfig
      INFO: lockdep is turned off.
      Preemption disabled at:[<ffffffffa029c5c4>] enic_rfs_flw_tbl_free+0x3=
4/0xd0 [enic]
     =20
      CPU: 31 PID: 443 Comm: ifconfig Not tainted 3.17.0-netnext-05504-g59f=
35b8 #268
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       ffff8800dac10000 ffff88020b8dfcb8 ffffffff8148a57c 0000000000000000
       ffff88020b8dfcd0 ffffffff8107e253 ffff8800dac12a40 ffff88020b8dfd10
       ffffffffa029305b ffff88020b8dfd48 ffff8800dac10000 ffff88020b8dfd48
      Call Trace:
       [<ffffffff8148a57c>] dump_stack+0x4e/0x7a
       [<ffffffff8107e253>] __might_sleep+0x123/0x1a0
       [<ffffffffa029305b>] enic_stop+0xdb/0x4d0 [enic]
       [<ffffffff8138ed7d>] __dev_close_many+0x9d/0xf0
       [<ffffffff8138ef81>] __dev_close+0x31/0x50
       [<ffffffff813974a8>] __dev_change_flags+0x98/0x160
       [<ffffffff81397594>] dev_change_flags+0x24/0x60
       [<ffffffff814085fd>] devinet_ioctl+0x63d/0x710
       [<ffffffff81139c16>] ? might_fault+0x56/0xc0
       [<ffffffff81409ef5>] inet_ioctl+0x65/0x90
       [<ffffffff813768e0>] sock_do_ioctl+0x20/0x50
       [<ffffffff81376ebb>] sock_ioctl+0x20b/0x2e0
       [<ffffffff81197250>] do_vfs_ioctl+0x2e0/0x500
       [<ffffffff81492619>] ? sysret_check+0x22/0x5d
       [<ffffffff81285f23>] ? __this_cpu_preempt_check+0x13/0x20
       [<ffffffff8109fe19>] ? trace_hardirqs_on_caller+0x119/0x270
       [<ffffffff811974ac>] SyS_ioctl+0x3c/0x80
       [<ffffffff814925ed>] system_call_fastpath+0x1a/0x1f
     =20
      Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b6931c9ba728d60c542c39ff037fe6f595c074a2
  Author: Govindarajulu Varadarajan <_govind@gmx.com>
  Date:   Sun Oct 19 14:20:27 2014 +0530
 =20
      enic: fix possible deadlock in enic_stop/ enic_rfs_flw_tbl_free
     =20
      The following warning is shown when spinlock debug is enabled.
     =20
      This occurs when enic_flow_may_expire timer function is running and
      enic_stop is called on same CPU.
     =20
      Fix this by using spink_lock_bh().
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      [ INFO: inconsistent lock state ]
      3.17.0-netnext-05504-g59f35b8 #268 Not tainted
      ---------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      ifconfig/443 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&enic->rfs_h.lock)->rlock){+.?...}, at:
      enic_rfs_flw_tbl_free+0x34/0xd0 [enic]
      {IN-SOFTIRQ-W} state was registered at:
        [<ffffffff810a25af>] __lock_acquire+0x83f/0x21c0
        [<ffffffff810a45f2>] lock_acquire+0xa2/0xd0
        [<ffffffff814913fc>] _raw_spin_lock+0x3c/0x80
        [<ffffffffa029c3d5>] enic_flow_may_expire+0x25/0x130[enic]
        [<ffffffff810bcd07>] call_timer_fn+0x77/0x100
        [<ffffffff810bd8e3>] run_timer_softirq+0x1e3/0x270
        [<ffffffff8105f9ae>] __do_softirq+0x14e/0x280
        [<ffffffff8105fdae>] irq_exit+0x8e/0xb0
        [<ffffffff8103da0f>] smp_apic_timer_interrupt+0x3f/0x50
        [<ffffffff81493742>] apic_timer_interrupt+0x72/0x80
        [<ffffffff81018143>] default_idle+0x13/0x20
        [<ffffffff81018a6a>] arch_cpu_idle+0xa/0x10
        [<ffffffff81097676>] cpu_startup_entry+0x2c6/0x330
        [<ffffffff8103b7ad>] start_secondary+0x21d/0x290
      irq event stamp: 2997
      hardirqs last  enabled at (2997): [<ffffffff81491865>] _raw_spin_unlo=
ck_irqrestore+0x65/0x90
      hardirqs last disabled at (2996): [<ffffffff814915e6>] _raw_spin_lock=
_irqsave+0x26/0x90
      softirqs last  enabled at (2968): [<ffffffff813b57a3>] dev_deactivate=
_many+0x213/0x260
      softirqs last disabled at (2966): [<ffffffff813b5783>] dev_deactivate=
_many+0x1f3/0x260
     =20
      other info that might help us debug this:
       Possible unsafe locking scenario:
     =20
             CPU0
             ----
        lock(&(&enic->rfs_h.lock)->rlock);
        <Interrupt>
          lock(&(&enic->rfs_h.lock)->rlock);
     =20
       *** DEADLOCK ***
     =20
      Reported-by: Jan Stancek <jstancek@redhat.com>
      Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d10845fc85b2e690b5f6425c5ba4df33a073fbc9
  Merge: ce8ec48 f993bc2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 20 12:38:19 2014 -0400
 =20
      Merge branch 'gso_encap_fixes'
     =20
      Florian Westphal says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      net: minor gso encapsulation fixes
     =20
      The following series fixes a minor bug in the gso segmentation handle=
rs
      when encapsulation offload is used.
     =20
      Theoretically this could cause kernel panic when the stack tries
      to software-segment such a GRE offload packet, but it looks like ther=
e
      is only one affected call site (tbf scheduler) and it handles NULL
      return value.
     =20
      I've included a followup patch to add IS_ERR_OR_NULL checks where nee=
ded.
     =20
      While looking into this, I also found that size computation of the in=
dividual
      segments is incorrect if skb->encapsulation is set.
     =20
      Please see individual patches for delta vs. v1.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f993bc25e5196e60514c216d0bca0f600de64af8
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:18 2014 +0200
 =20
      net: core: handle encapsulation offloads when computing segment lengt=
hs
     =20
      if ->encapsulation is set we have to use inner_tcp_hdrlen and add the
      size of the inner network headers too.
     =20
      This is 'mostly harmless'; tbf might send skb that is slightly over
      quota or drop skb even if it would have fit.
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 330966e501ffe282d7184fde4518d5e0c24bc7f8
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:17 2014 +0200
 =20
      net: make skb_gso_segment error handling more robust
     =20
      skb_gso_segment has three possible return values:
      1. a pointer to the first segmented skb
      2. an errno value (IS_ERR())
      3. NULL.  This can happen when GSO is used for header verification.
     =20
      However, several callers currently test IS_ERR instead of IS_ERR_OR_N=
ULL
      and would oops when NULL is returned.
     =20
      Note that these call sites should never actually see such a NULL retu=
rn
      value; all callers mask out the GSO bits in the feature argument.
     =20
      However, there have been issues with some protocol handlers erronousl=
y not
      respecting the specified feature mask in some cases.
     =20
      It is preferable to get 'have to turn off hw offloading, else slow' r=
eports
      rather than 'kernel crashes'.
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e16aa3ddf863c6b9f37eddf52503230a62dedb3
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:16 2014 +0200
 =20
      net: gso: use feature flag argument in all protocol gso handlers
     =20
      skb_gso_segment() has a 'features' argument representing offload feat=
ures
      available to the output path.
     =20
      A few handlers, e.g. GRE, instead re-fetch the features of skb->dev a=
nd use
      those instead of the provided ones when handing encapsulation/tunnels=
.
     =20
      Depending on dev->hw_enc_features of the output device skb_gso_segmen=
t() can
      then return NULL even when the caller has disabled all GSO feature bi=
ts,
      as segmentation of inner header thinks device will take care of segme=
ntation.
     =20
      This e.g. affects the tbf scheduler, which will silently drop GRE-enc=
ap GSO skbs
      that did not fit the remaining token quota as the segmentation does n=
ot work
      when device supports corresponding hw offload capabilities.
     =20
      Cc: Pravin B Shelar <pshelar@nicira.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ce8ec4896749783bd6cdc457e6012cfc18e09c8b
  Merge: 95ff886 1e2d56a
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 20 11:57:47 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      netfilter fixes for net
     =20
      The following patchset contains netfilter fixes for your net tree,
      they are:
     =20
      1) Fix missing MODULE_LICENSE() in the new nf_reject_ipv{4,6} modules=
.
     =20
      2) Restrict nat and masq expressions to the nat chain type. Otherwise=
,
         users may crash their kernel if they attach a nat/masq rule to a n=
on
         nat chain.
     =20
      3) Fix hook validation in nft_compat when non-base chains are used.
         Basically, initialize hook_mask to zero.
     =20
      4) Make sure you use match/targets in nft_compat from the right chain
         type. The existing validation relies on the table name which can b=
e
         avoided by
     =20
      5) Better netlink attribute validation in nft_nat. This expression ha=
s
         to reject the configuration when no address and proto configuratio=
ns
         are specified.
     =20
      6) Interpret NFTA_NAT_REG_*_MAX if only if NFTA_NAT_REG_*_MIN is set.
         Yet another sanity check to reject incorrect configurations from
         userspace.
     =20
      7) Conditional NAT attribute dumping depending on the existing
         configuration.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 11b2357d5dbce999803e9055f8c09829a8a87db4
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Mon Oct 20 10:54:36 2014 +0200
 =20
      mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats
     =20
      ATM an HT rc_stats line is 106 chars.
      Times 8(MCS_GROUP_RATES)*3(SS)*2(GI)*2(BW) + CCK(4), i.e. x100, this =
is
      well above the current 8192 - sizeof(*ms) currently allocated.
     =20
      Fix this by squeezing the output as follows (not that we're short on
      memory but this also improves readability and range, the new format a=
dds
      one more digit to *ok/*cum and ok/cum):
     =20
      - Before (HT) (106 ch):
      type           rate     throughput  ewma prob   this prob  retry   th=
is succ/attempt   success    attempts
      CCK/LP          5.5M           0.0        0.0         0.0      0     =
         0(  0)         0           0
      HT20/LGI ABCDP MCS0            0.0        0.0         0.0      1     =
         0(  0)         0           0
      - After (75 ch):
      type           rate     tpt eprob *prob ret  *ok(*cum)        ok(    =
  cum)
      CCK/LP          5.5M    0.0   0.0   0.0   0    0(   0)         0(    =
    0)
      HT20/LGI ABCDP MCS0     0.0   0.0   0.0   1    0(   0)         0(    =
    0)
     =20
      - Align non-HT format Before (non-HT) (83 ch):
      rate      throughput  ewma prob  this prob  this succ/attempt   succe=
ss    attempts
      ABCDP  6         0.0        0.0        0.0             0(  0)        =
 0           0
            54         0.0        0.0        0.0             0(  0)        =
 0           0
      - After (61 ch):
      rate          tpt eprob *prob  *ok(*cum)        ok(      cum)
      ABCDP  1      0.0   0.0   0.0    0(   0)         0(        0)
            54      0.0   0.0   0.0    0(   0)         0(        0)
     =20
      *This also adds dynamic checks for overflow, lowers the size of the
      non-HT request (allowing > 30 entries) and replaces the buddy-rounded
      allocations (s/sizeof(*ms) + 8192/8192).
     =20
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Acked-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 95ff88688781db2f64042e69bd499e518bbb36e5
  Author: Ian Morgan <imorgan@primordial.ca>
  Date:   Sun Oct 19 08:05:13 2014 -0400
 =20
      ax88179_178a: fix bonding failure
     =20
      The following patch fixes a bug which causes the ax88179_178a driver =
to be
      incapable of being added to a bond.
     =20
      When I brought up the issue with the bonding maintainers, they indica=
ted
      that the real problem was with the NIC driver which must return zero =
for
      success (of setting the MAC address). I see that several other NIC dr=
ivers
      follow that pattern by either simply always returing zero, or by pass=
ing
      through a negative (error) result while rewriting any positive return=
 code
      to zero. With that same philisophy applied to the ax88179_178a driver=
, it
      allows it to work correctly with the bonding driver.
     =20
      I believe this is suitable for queuing in -stable, as it's a small, s=
imple,
      and obvious fix that corrects a defect with no other known workaround=
.
     =20
      This patch is against vanilla 3.17(.0).
     =20
      Signed-off-by: Ian Morgan <imorgan@primordial.ca>
     =20
       drivers/net/usb/ax88179_178a.c |    7 ++++++-
       1 file changed, 6 insertions(+), 1 deletion(-)
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e2d56a5d33a7e1fcd21ed3859f52596d02708b0
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:24:14 2014 +0200
 =20
      netfilter: nft_nat: dump attributes if they are set
     =20
      Dump NFTA_NAT_REG_ADDR_MIN if this is non-zero. Same thing with
      NFTA_NAT_REG_PROTO_MIN.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 61cfac6b42af98ab46bcb3a47e150e7b20d5015e
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:19:35 2014 +0200
 =20
      netfilter: nft_nat: NFTA_NAT_REG_ADDR_MAX depends on NFTA_NAT_REG_ADD=
R_MIN
     =20
      Interpret NFTA_NAT_REG_ADDR_MAX if NFTA_NAT_REG_ADDR_MIN is present,
      otherwise, skip it. Same thing with NFTA_NAT_REG_PROTO_MAX.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 5c819a39753d6a3ae9c0092236f59730a369b619
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:16:57 2014 +0200
 =20
      netfilter: nft_nat: insufficient attribute validation
     =20
      We have to validate that we at least get an NFTA_NAT_REG_ADDR_MIN or
      NFTA_NFT_REG_PROTO_MIN attribute. Reject the configuration if none
      of them are present.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit f3f5ddeddd6aeadcef523d55ea9288e3d5c1cbc3
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Tue Oct 14 10:13:48 2014 +0200
 =20
      netfilter: nft_compat: validate chain type in match/target
     =20
      We have to validate the real chain type to ensure that matches/target=
s
      are not used out from their scope (eg. MASQUERADE in nat chain type).
      The existing validation relies on the table name, but this is not
      sufficient since userspace can fool us by using the appropriate table
      name with a different chain type.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 493618a92c6afdd3f6224ab586f169d6a259bb06
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Tue Oct 14 12:43:50 2014 +0200
 =20
      netfilter: nft_compat: fix hook validation for non-base chains
     =20
      Set hook_mask to zero for non-base chains, otherwise people may hit
      bogus errors from the xt_check_target() and xt_check_match() when
      validating the uninitialized hook_mask.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit c7abf25af0f41be4b50d44c5b185d52eea360cb8
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Mon Oct 13 14:34:41 2014 +0200
 =20
      mac80211: fix typo in starting baserate for rts_cts_rate_idx
     =20
      It affects non-(V)HT rates and can lead to selecting an rts_cts rate
      that is not a basic rate or way superior to the reference rate (ATM
      rates[0] used for the 1st attempt of the protected frame data).
     =20
      E.g, assuming drivers register growing (bitrate) sorted tables of
      ieee80211_rate-s, having :
      - rates[0].idx =3D=3D d'2 and basic_rates =3D=3D b'10100
      will select rts_cts idx b'10011 & ~d'(BIT(2)-1), i.e. 1, likewise
      - rates[0].idx =3D=3D d'2 and basic_rates =3D=3D b'10001
      will select rts_cts idx b'10000
      The first is not a basic rate and the second is > rates[0].
     =20
      Also, wrt severity of the addressed misbehavior, ATM we only have one
      rts_cts_rate_idx rather than one per rate table entry, so this idx mi=
ght
      still point to bitrates > rates[1..MAX_RATES].
     =20
      Fixes: 5253ffb8c9e1 ("mac80211: always pick a basic rate to tx RTS/CT=
S for pre-HT rates")
      Cc: stable@vger.kernel.org
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 7210e4e38f945dfa173c4a4e59ad827c9ecad541
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Mon Oct 13 19:50:22 2014 +0200
 =20
      netfilter: nf_tables: restrict nat/masq expressions to nat chain type
     =20
      This adds the missing validation code to avoid the use of nat/masq fr=
om
      non-nat chains. The validation assumes two possible configuration
      scenarios:
     =20
      1) Use of nat from base chain that is not of nat type. Reject this
         configuration from the nft_*_init() path of the expression.
     =20
      2) Use of nat from non-base chain. In this case, we have to wait unti=
l
         the non-base chain is referenced by at least one base chain via
         jump/goto. This is resolved from the nft_*_validate() path which i=
s
         called from nf_tables_check_loops().
     =20
      The user gets an -EOPNOTSUPP in both cases.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit ab2d7251d666995740da17b2a51ca545ac5dd037
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Fri Oct 10 11:25:20 2014 +0200
 =20
      netfilter: missing module license in the nf_reject_ipvX modules
     =20
      [   23.545204] nf_reject_ipv4: module license 'unspecified' taints ke=
rnel.
     =20
      Fixes: c8d7b98 ("netfilter: move nf_send_resetX() code to nf_reject_i=
pvX modules")
      Reported-by: Dave Young <dyoung@redhat.com>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 252e07ca5f64dd31fdfca8027287e7d75fefdab1
  Author: Luciano Coelho <luciano.coelho@intel.com>
  Date:   Wed Oct 8 09:48:34 2014 +0300
 =20
      nl80211: sanity check the channel switch counter value
     =20
      The nl80211 channel switch count attribute
      (NL80211_ATTR_CH_SWITCH_COUNT) is specified as u32, but the
      specification uses u8 for the counter.  To make sure strange things
      don't happen without informing the user, sanity check the value and
      return -EINVAL if it doesn't fit in u8.
     =20
      Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit bc37b16870a382e8b71d881444c19a16de1c1a7f
  Author: Fabian Frederick <fabf@skynet.be>
  Date:   Tue Oct 7 22:20:23 2014 +0200
 =20
      net: rfkill: kernel-doc warning fixes
     =20
      Correct the kernel-doc, the parameter is called "blocked" not "state"=
.
     =20
      Signed-off-by: Fabian Frederick <fabf@skynet.be>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit c12bc4885f4b3bab0ed779c69d5d7e3223fa5003
  Author: Luciano Coelho <luciano.coelho@intel.com>
  Date:   Tue Sep 30 07:08:02 2014 +0300
 =20
      mac80211: return the vif's chandef in ieee80211_cfg_get_channel()
     =20
      The chandef of the channel context a vif is using may be different
      than the chandef of the vif itself.  For instance, the bandwidth used
      by the vif may be narrower than the one configured in the channel
      context.  To avoid confusion, return the vif's chandef in
      ieee80211_cfg_get_channel() instead of the chandef of the channel
      context.
     =20
      Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 8975ae88e137ea02a71b7a86af2f8eb790c2f1e7
  Author: Liad Kaufman <liad.kaufman@intel.com>
  Date:   Sun Sep 14 21:48:28 2014 +0300
 =20
      mac80211: fix warning on htmldocs for last_tdls_pkt_time
     =20
      Forgot to add an entry to the struct description of sta_info.
     =20
      Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
      Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Revision graph left in /home/xc_osstest/results/bisect.linux-linus.test-amd=
64-i386-rumpuserxen-i386.guest-start.{dot,ps,png,html}.
----------------------------------------
31424: tolerable FAIL

flight 31424 linux-linus real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31424/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline unte=
sted


jobs:
 build-i386-rumpuserxen                                       pass   =20
 test-amd64-i386-rumpuserxen-i386                             fail   =20


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=3Dosstest.git;a=3Dsummary



--===============6490934011355994455==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6490934011355994455==--

From xen-devel-bounces@lists.xen.org Thu Nov 06 18:41:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 18:41:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmRzi-0005cj-9T; Thu, 06 Nov 2014 18:41:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmRzf-0005ce-OS
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 18:41:16 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	43/43-02953-BC0CB545; Thu, 06 Nov 2014 18:41:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415299271!11908733!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9573 invoked from network); 6 Nov 2014 18:41:12 -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;
	6 Nov 2014 18:41:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="scan'208";a="190297987"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 6 Nov 2014 13:41:02 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmRzS-0004rb-77;
	Thu, 06 Nov 2014 18:41:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmRzR-0001vB-V8;
	Thu, 06 Nov 2014 18:41:02 +0000
Date: Thu, 6 Nov 2014 18:41:01 +0000
Message-ID: <E1XmRzR-0001vB-V8@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [linux-linus bisection] complete
	test-amd64-i386-rumpuserxen-i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6490934011355994455=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6490934011355994455==
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rumpuserxen-i386
test guest-start

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.=
6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: rumpuserxen git://xenbits.xen.org/rumpuser-xen.git
Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.gi=
t
Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torv=
alds/linux-2.6.git
  Bug introduced:  89453379aaf0608253124057df6cd8ac63948135
  Bug not present: 53429290a054b30e4683297409fc4627b2592315


  commit 89453379aaf0608253124057df6cd8ac63948135
  Merge: 5342929 99a49ce
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Oct 31 15:04:58 2014 -0700
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
     =20
      Pull networking fixes from David Miller:
       "A bit has accumulated, but it's been a week or so since my last bat=
ch
        of post-merge-window fixes, so...
     =20
         1) Missing module license in netfilter reject module, from Pablo.
            Lots of people ran into this.
     =20
         2) Off by one in mac80211 baserate calculation, from Karl Beldan.
     =20
         3) Fix incorrect return value from ax88179_178a driver's set_mac_a=
ddr
            op, which broke use of it with bonding.  From Ian Morgan.
     =20
         4) Checking of skb_gso_segment()'s return value was not all
            encompassing, it can return an SKB pointer, a pointer error, or
            NULL.  Fix from Florian Westphal.
     =20
            This is crummy, and longer term will be fixed to just return er=
ror
            pointers or a real SKB.
     =20
         6) Encapsulation offloads not being handled by
            skb_gso_transport_seglen().  From Florian Westphal.
     =20
         7) Fix deadlock in TIPC stack, from Ying Xue.
     =20
         8) Fix performance regression from using rhashtable for netlink
            sockets.  The problem was the synchronize_net() invoked for eve=
ry
            socket destroy.  From Thomas Graf.
     =20
         9) Fix bug in eBPF verifier, and remove the strong dependency of B=
PF
            on NET.  From Alexei Starovoitov.
     =20
        10) In qdisc_create(), use the correct interface to allocate
            ->cpu_bstats, otherwise the u64_stats_sync member isn't
            initialized properly.  From Sabrina Dubroca.
     =20
        11) Off by one in ip_set_nfnl_get_byindex(), from Dan Carpenter.
     =20
        12) nf_tables_newchain() was erroneously expecting error pointers f=
rom
            netdev_alloc_pcpu_stats().  It only returna a valid pointer or
            NULL.  From Sabrina Dubroca.
     =20
        13) Fix use-after-free in _decode_session6(), from Li RongQing.
     =20
        14) When we set the TX flow hash on a socket, we mistakenly do so
            before we've nailed down the final source port.  Move the setti=
ng
            deeper to fix this.  From Sathya Perla.
     =20
        15) NAPI budget accounting in amd-xgbe driver was counting descript=
ors
            instead of full packets, fix from Thomas Lendacky.
     =20
        16) Fix total_data_buflen calculation in hyperv driver, from Haiyan=
g
            Zhang.
     =20
        17) Fix bcma driver build with OF_ADDRESS disabled, from Hauke
            Mehrtens.
     =20
        18) Fix mis-use of per-cpu memory in TCP md5 code.  The problem is
            that something that ends up being vmalloc memory can't be passe=
d
            to the crypto hash routines via scatter-gather lists.  From Eri=
c
            Dumazet.
     =20
        19) Fix regression in promiscuous mode enabling in cdc-ether, from
            Olivier Blin.
     =20
        20) Bucket eviction and frag entry killing can race with eachother,
            causing an unlink of the object from the wrong list.  Fix from
            Nikolay Aleksandrov.
     =20
        21) Missing initialization of spinlock in cxgb4 driver, from Anish
            Bhatt.
     =20
        22) Do not cache ipv4 routing failures, otherwise if the sysctl for
            forwarding is subsequently enabled this won't be seen.  From
            Nicolas Cavallari"
     =20
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (131 commi=
ts)
        drivers: net: cpsw: Support ALLMULTI and fix IFF_PROMISC in switch =
mode
        drivers: net: cpsw: Fix broken loop condition in switch mode
        net: ethtool: Return -EOPNOTSUPP if user space tries to read EEPROM=
 with lengh 0
        stmmac: pci: set default of the filter bins
        net: smc91x: Fix gpios for device tree based booting
        mpls: Allow mpls_gso to be built as module
        mpls: Fix mpls_gso handler.
        r8152: stop submitting intr for -EPROTO
        netfilter: nft_reject_bridge: restrict reject to prerouting and inp=
ut
        netfilter: nft_reject_bridge: don't use IP stack to reject traffic
        netfilter: nf_reject_ipv6: split nf_send_reset6() in smaller functi=
ons
        netfilter: nf_reject_ipv4: split nf_send_reset() in smaller functio=
ns
        netfilter: nf_tables_bridge: update hook_mask to allow {pre,post}ro=
uting
        drivers/net: macvtap and tun depend on INET
        drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packe=
ts
        drivers/net: Disable UFO through virtio
        net: skb_fclone_busy() needs to detect orphaned skb
        gre: Use inner mac length when computing tunnel length
        mlx4: Avoid leaking steering rules on flow creation error flow
        net/mlx4_en: Don't attempt to TX offload the outer UDP checksum for=
 VXLAN
        ...
 =20
  commit 99a49ce613057f1934e1c378808374fd683b1541
  Merge: 1e5c4bc 75a916e
  Author: David S. Miller <davem@davemloft.net>
  Date:   Fri Oct 31 16:18:35 2014 -0400
 =20
      Merge tag 'master-2014-10-30' of git://git.kernel.org/pub/scm/linux/k=
ernel/git/linville/wireless
     =20
      John W. Linville says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      pull request: wireless 2014-10-31
     =20
      Please pull this small batch of spooky fixes intended for the 3.18
      stream...boo!
     =20
      Cyril Brulebois adds an rt2x00 device ID.
     =20
      Dan Carpenter provides a one-line masking fix for an ath9k debugfs
      entry.
     =20
      Larry Finger gives us a package of small rtlwifi fixes which add some
      bits that were left out of some feature updates that were included
      in the merge window.  Hopefully this isn't a sign that the rtlwifi
      base is getting too big...
     =20
      Marc Yang brings a fix for a temporary mwifiex stall when doing 11n
      RX reordering.
     =20
      Please let me know if there are problems!
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e5c4bc497c0a96e1ad2974539d353870f2cb0b6
  Author: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  Date:   Fri Oct 31 13:38:52 2014 -0400
 =20
      drivers: net: cpsw: Support ALLMULTI and fix IFF_PROMISC in switch mo=
de
     =20
      The cpsw driver did not support the IFF_ALLMULTI flag which makes dyn=
amic
      multicast routing not work.  Related to this, when enabling IFF_PROMI=
SC
      in switch mode, all registered multicast addresses are flushed, resul=
ting
      in only broadcast and unicast traffic being received.
     =20
      A new cpsw_ale_set_allmulti function now scans through the ALE entry
      table and adds/removes the host port from the unregistered multicast
      port mask of each vlan entry depending on the state of IFF_ALLMULTI.
      In promiscious mode, cpsw_ale_set_allmulti is used to force reception
      of all multicast traffic in addition to the unicast and broadcast tra=
ffic.
     =20
      With this change dynamic multicast and promiscious mode both work in
      switch mode.
     =20
      Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 6f979eb3fcfb4c3f42f230d174db4bbad0080710
  Author: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  Date:   Fri Oct 31 13:28:54 2014 -0400
 =20
      drivers: net: cpsw: Fix broken loop condition in switch mode
     =20
      0d961b3b52f566f823070ce2366511a7f64b928c (drivers: net: cpsw: fix bug=
gy
      loop condition) accidentally fixed a loop comparison in too many plac=
es
      while fixing a real bug.
     =20
      It was correct to fix the dual_emac mode section since there 'i' is u=
sed
      as an index into priv->slaves which is a 0 based array.
     =20
      However the other two changes (which are only used in switch mode)
      are wrong since there 'i' is actually the ALE port number, and port 0
      is the host port, while port 1 and up are the slave ports.
     =20
      Putting the loop condition back in the switch mode section fixes it.
     =20
      A comment has been added to point out the intent clearly to avoid fut=
ure
      confusion.  Also a comment is fixed that said the opposite of what wa=
s
      actually happening.
     =20
      Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
      Acked-by: Heiko Schocher <hs@denx.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e0fb6fb6d52686134b2ece144060219591d4f8d3
  Author: Guenter Roeck <linux@roeck-us.net>
  Date:   Thu Oct 30 20:50:15 2014 -0700
 =20
      net: ethtool: Return -EOPNOTSUPP if user space tries to read EEPROM w=
ith lengh 0
     =20
      If a driver supports reading EEPROM but no EEPROM is installed in the=
 system,
      the driver's get_eeprom_len function returns 0. ethtool will subseque=
ntly
      try to read that zero-length EEPROM anyway. If the driver does not su=
pport
      EEPROM access at all, this operation will return -EOPNOTSUPP. If the =
driver
      does support EEPROM access but no EEPROM is installed, the operation =
will
      return -EINVAL. Return -EOPNOTSUPP in both cases for consistency.
     =20
      Signed-off-by: Guenter Roeck <linux@roeck-us.net>
      Tested-by: Andrew Lunn <andrew@lunn.ch>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e19e084eae727654052339757ab7f1eaff58bad
  Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Date:   Fri Oct 31 18:28:03 2014 +0200
 =20
      stmmac: pci: set default of the filter bins
     =20
      The commit 3b57de958e2a brought the support for a different amount of=
 the
      filter bins, but didn't update the PCI driver accordingly. This patch=
 appends
      the default values when the device is enumerated via PCI bus.
     =20
      Fixes: 3b57de958e2a (net: stmmac: Support devicetree configs for mcas=
t and ucast filter entries)
      Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7d2911c4381555b31ef0bcae42a0dbf9ade7426e
  Author: Tony Lindgren <tony@atomide.com>
  Date:   Thu Oct 30 09:59:27 2014 -0700
 =20
      net: smc91x: Fix gpios for device tree based booting
     =20
      With legacy booting, the platform init code was taking care of
      the configuring of GPIOs. With device tree based booting, things
      may or may not work depending what bootloader has configured or
      if the legacy platform code gets called.
     =20
      Let's add support for the pwrdn and reset GPIOs to the smc91x
      driver to fix the issues of smc91x not working properly when
      booted in device tree mode.
     =20
      And let's change n900 to use these settings as some versions
      of the bootloader do not configure things properly causing
      errors.
     =20
      Reported-by: Kevin Hilman <khilman@linaro.org>
      Signed-off-by: Tony Lindgren <tony@atomide.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit de05c400f7dfa566f598140f8604a5de8067cd5f
  Author: Pravin B Shelar <pshelar@nicira.com>
  Date:   Thu Oct 30 00:50:04 2014 -0700
 =20
      mpls: Allow mpls_gso to be built as module
     =20
      Kconfig already allows mpls to be built as module. Following patch
      fixes Makefile to do same.
     =20
      CC: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
      Acked-by: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f7065f4bd3fe4ad6bf7e49ba7c68baa2c7046146
  Author: Pravin B Shelar <pshelar@nicira.com>
  Date:   Thu Oct 30 00:49:57 2014 -0700
 =20
      mpls: Fix mpls_gso handler.
     =20
      mpls gso handler needs to pull skb after segmenting skb.
     =20
      CC: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
      Acked-by: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d59c876dd61f3c151db077f9d73774e605f2b35e
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Fri Oct 31 13:35:57 2014 +0800
 =20
      r8152: stop submitting intr for -EPROTO
     =20
      For Renesas USB 3.0 host controller, when unplugging the usb hub whic=
h
      has the RTL8153 plugged, the driver would get -EPROTO for interrupt
      transfer. There is high probability to get the information of "HC die=
d;
      cleaning up", if the driver continues to submit the interrupt transfe=
r
      before the disconnect() is called.
     =20
      [ 1024.197678] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.213673] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.229668] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.245661] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.261653] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.277648] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.293642] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.309638] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.325633] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.341627] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.357621] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.373615] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.383097] usb 9-1: USB disconnect, device number 2
      [ 1024.383103] usb 9-1.4: USB disconnect, device number 6
      [ 1029.391010] xhci_hcd 0000:04:00.0: xHCI host not responding to sto=
p endpoint command.
      [ 1029.391016] xhci_hcd 0000:04:00.0: Assuming host is dying, halting=
 host.
      [ 1029.392551] xhci_hcd 0000:04:00.0: HC died; cleaning up
      [ 1029.421480] usb 8-1: USB disconnect, device number 2
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e3a88f9c4f79a4d138a0ea464cfbac40ba46644c
  Merge: de11b0e 127917c
  Author: David S. Miller <davem@davemloft.net>
  Date:   Fri Oct 31 12:29:42 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      netfilter/ipvs fixes for net
     =20
      The following patchset contains fixes for netfilter/ipvs. This round =
of
      fixes is larger than usual at this stage, specifically because of the
      nf_tables bridge reject fixes that I would like to see in 3.18. The
      patches are:
     =20
      1) Fix a null-pointer dereference that may occur when logging
         errors. This problem was introduced by 4a4739d56b0 ("ipvs: Pull
         out crosses_local_route_boundary logic") in v3.17-rc5.
     =20
      2) Update hook mask in nft_reject_bridge so we can also filter out
         packets from there. This fixes 36d2af5 ("netfilter: nf_tables: all=
ow
         to filter from prerouting and postrouting"), which needs this chun=
k
         to work.
     =20
      3) Two patches to refactor common code to forge the IPv4 and IPv6
         reject packets from the bridge. These are required by the nf_table=
s
         reject bridge fix.
     =20
      4) Fix nft_reject_bridge by avoiding the use of the IP stack to rejec=
t
         packets from the bridge. The idea is to forge the reject packets a=
nd
         inject them to the original port via br_deliver() which is now
         exported for that purpose.
     =20
      5) Restrict nft_reject_bridge to bridge prerouting and input hooks.
         the original skbuff may cloned after prerouting when the bridge st=
ack
         needs to flood it to several bridge ports, it is too late to rejec=
t
         the traffic.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 127917c29a432c3b798e014a1714e9c1af0f87fe
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Mon Oct 27 14:08:17 2014 +0100
 =20
      netfilter: nft_reject_bridge: restrict reject to prerouting and input
     =20
      Restrict the reject expression to the prerouting and input bridge
      hooks. If we allow this to be used from forward or any other later
      bridge hook, if the frame is flooded to several ports, we'll end up
      sending several reject packets, one per cloned packet.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 523b929d5446c023e1219aa81455a8c766cac883
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 18:40:26 2014 +0200
 =20
      netfilter: nft_reject_bridge: don't use IP stack to reject traffic
     =20
      If the packet is received via the bridge stack, this cannot reject
      packets from the IP stack.
     =20
      This adds functions to build the reject packet and send it from the
      bridge stack. Comments and assumptions on this patch:
     =20
      1) Validate the IPv4 and IPv6 headers before further processing,
         given that the packet comes from the bridge stack, we cannot assum=
e
         they are clean. Truncated packets are dropped, we follow similar
         approach in the existing iptables match/target extensions that nee=
d
         to inspect layer 4 headers that is not available. This also includ=
es
         packets that are directed to multicast and broadcast ethernet
         addresses.
     =20
      2) br_deliver() is exported to inject the reject packet via
         bridge localout -> postrouting. So the approach is similar to what
         we already do in the iptables reject target. The reject packet is
         sent to the bridge port from which we have received the original
         packet.
     =20
      3) The reject packet is forged based on the original packet. The TTL
         is set based on sysctl_ip_default_ttl for IPv4 and per-net
         ipv6.devconf_all hoplimit for IPv6.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 8bfcdf6671b1c8006c52c3eaf9fd1b5dfcf41c3d
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sun Oct 26 12:35:54 2014 +0100
 =20
      netfilter: nf_reject_ipv6: split nf_send_reset6() in smaller function=
s
     =20
      That can be reused by the reject bridge expression to build the rejec=
t
      packet. The new functions are:
     =20
      * nf_reject_ip6_tcphdr_get(): to sanitize and to obtain the TCP heade=
r.
      * nf_reject_ip6hdr_put(): to build the IPv6 header.
      * nf_reject_ip6_tcphdr_put(): to build the TCP header.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 052b9498eea532deb5de75277a53f6e0623215dc
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 18:24:57 2014 +0200
 =20
      netfilter: nf_reject_ipv4: split nf_send_reset() in smaller functions
     =20
      That can be reused by the reject bridge expression to build the rejec=
t
      packet. The new functions are:
     =20
      * nf_reject_ip_tcphdr_get(): to sanitize and to obtain the TCP header=
.
      * nf_reject_iphdr_put(): to build the IPv4 header.
      * nf_reject_ip_tcphdr_put(): to build the TCP header.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 4d87716cd057bde3f90e304289c1fec88d45a1cc
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 12:25:06 2014 +0200
 =20
      netfilter: nf_tables_bridge: update hook_mask to allow {pre,post}rout=
ing
     =20
      Fixes: 36d2af5 ("netfilter: nf_tables: allow to filter from preroutin=
g and postrouting")
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit de11b0e8c569b96c2cf6a811e3805b7aeef498a3
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Fri Oct 31 03:10:31 2014 +0000
 =20
      drivers/net: macvtap and tun depend on INET
     =20
      These drivers now call ipv6_proxy_select_ident(), which is defined
      only if CONFIG_INET is enabled.  However, they have really depended
      on CONFIG_INET for as long as they have allowed sending GSO packets
      from userland.
     =20
      Reported-by: kbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
      Fixes: b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
      Fixes: 5188cd44c55d ("drivers/net, ipv6: Select IPv6 fragment idents =
for virtio UFO packets")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c1304b217c7cefa5718fab9d36c59ba0d0133c6e
  Merge: 39bb5e6 5188cd4
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 20:01:27 2014 -0400
 =20
      Merge branch 'ufo-fix'
     =20
      Ben Hutchings says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      drivers/net,ipv6: Fix IPv6 fragment ID selection for virtio
     =20
      The virtio net protocol supports UFO but does not provide for passing=
 a
      fragment ID for fragmentation of IPv6 packets.  We used to generate a
      fragment ID wherever such a packet was fragmented, but currently we
      always use ID=3D0!
     =20
      v2: Add blank lines after declarations
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Thu Oct 30 18:27:17 2014 +0000
 =20
      drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets
     =20
      UFO is now disabled on all drivers that work with virtio net headers,
      but userland may try to send UFO/IPv6 packets anyway.  Instead of
      sending with ID=3D0, we should select identifiers on their behalf (as=
 we
      used to).
     =20
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_dat=
a")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Thu Oct 30 18:27:12 2014 +0000
 =20
      drivers/net: Disable UFO through virtio
     =20
      IPv6 does not allow fragmentation by routers, so there is no
      fragmentation ID in the fixed header.  UFO for IPv6 requires the ID t=
o
      be passed separately, but there is no provision for this in the virti=
o
      net protocol.
     =20
      Until recently our software implementation of UFO/IPv6 generated a ne=
w
      ID, but this was a bug.  Now we will use ID=3D0 for any UFO/IPv6 pack=
et
      passed through a tap, which is even worse.
     =20
      Unfortunately there is no distinction between UFO/IPv4 and v6
      features, so disable UFO on taps and virtio_net completely until we
      have a proper solution.
     =20
      We cannot depend on VM managers respecting the tap feature flags, so
      keep accepting UFO packets but log a warning the first time we do
      this.
     =20
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_dat=
a")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 39bb5e62867de82b269b07df900165029b928359
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 30 10:32:34 2014 -0700
 =20
      net: skb_fclone_busy() needs to detect orphaned skb
     =20
      Some drivers are unable to perform TX completions in a bound time.
      They instead call skb_orphan()
     =20
      Problem is skb_fclone_busy() has to detect this case, otherwise
      we block TCP retransmits and can freeze unlucky tcp sessions on
      mostly idle hosts.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 1f3279ae0c13 ("tcp: avoid retransmits of TCP packets hanging i=
n host queues")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 14051f0452a2c26a3f4791e6ad6a435e8f1945ff
  Author: Tom Herbert <therbert@google.com>
  Date:   Thu Oct 30 08:40:56 2014 -0700
 =20
      gre: Use inner mac length when computing tunnel length
     =20
      Currently, skb_inner_network_header is used but this does not account
      for Ethernet header for ETH_P_TEB. Use skb_inner_mac_header which
      handles TEB and also should work with IP encapsulation in which case
      inner mac and inner network headers are the same.
     =20
      Tested: Ran TCP_STREAM over GRE, worked as expected.
     =20
      Signed-off-by: Tom Herbert <therbert@google.com>
      Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 292dd6542f90126826fe87b302e6afa3b7ada6b8
  Merge: 9cc233f 571e1b2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 19:49:20 2014 -0400
 =20
      Merge branch 'mellanox-net'
     =20
      Or Gerlitz says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      mlx4 driver encapsulation/steering fixes
     =20
      The 1st patch fixes a bug in the TX path that supports offloading the
      TX checksum of (VXLAN) encapsulated TCP packets. It turns out that th=
e
      bug is revealed only when the receiver runs in non-offloaded mode, so
      we somehow missed it so far... please queue it for -stable >=3D 3.14
     =20
      The 2nd patch makes sure not to leak steering entry on error flow,
      please queue it to 3.17-stable
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 571e1b2c7a4c2fd5faa1648462a6b65fa26530d7
  Author: Or Gerlitz <ogerlitz@mellanox.com>
  Date:   Thu Oct 30 15:59:28 2014 +0200
 =20
      mlx4: Avoid leaking steering rules on flow creation error flow
     =20
      If mlx4_ib_create_flow() attempts to create > 1 rules with the
      firmware, and one of these registrations fail, we leaked the
      already created flow rules.
     =20
      One example of the leak is when the registration of the VXLAN ghost
      steering rule fails, we didn't unregister the original rule requested
      by the user, introduced in commit d2fce8a9060d "mlx4: Set
      user-space raw Ethernet QPs to properly handle VXLAN traffic".
     =20
      While here, add dump of the VXLAN portion of steering rules
      so it can actually be seen when flow creation fails.
     =20
      Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit a4f2dacbf2a5045e34b98a35d9a3857800f25a7b
  Author: Or Gerlitz <ogerlitz@mellanox.com>
  Date:   Thu Oct 30 15:59:27 2014 +0200
 =20
      net/mlx4_en: Don't attempt to TX offload the outer UDP checksum for V=
XLAN
     =20
      For VXLAN/NVGRE encapsulation, the current HW doesn't support offload=
ing
      both the outer UDP TX checksum and the inner TCP/UDP TX checksum.
     =20
      The driver doesn't advertize SKB_GSO_UDP_TUNNEL_CSUM, however we are =
wrongly
      telling the HW to offload the outer UDP checksum for encapsulated pac=
kets,
      fix that.
     =20
      Fixes: 837052d0ccc5 ('net/mlx4_en: Add netdev support for TCP/IP
      		     offloads of vxlan tunneling')
      Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9cc233fb0f94b79d07cf141a625e237769d267a1
  Merge: fa19c2b0 e3215f0
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 19:46:33 2014 -0400
 =20
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/gi=
t/jkirsher/net
     =20
      Jeff Kirsher says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      Intel Wired LAN Driver Updates 2014-10-30
     =20
      This series contains updates to e1000, igb and ixgbe.
     =20
      Francesco Ruggeri fixes an issue with e1000 where in a VM the driver =
did
      not support unicast filtering.
     =20
      Roman Gushchin fixes an issue with igb where the driver was re-using
      mapped pages so that packets were still getting dropped even if all
      the memory issues are gone and there is free memory.
     =20
      Junwei Zhang found where in the ixgbe_clean_rx_ring() we were repeati=
ng
      the assignment of NULL to the receive buffer skb and fixes it.
     =20
      Emil fixes a race condition between setup_link and SFP detection rout=
ine
      in the watchdog when setting the advertised speed.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit fa19c2b050ab5254326f5fc07096dd3c6a8d5d58
  Author: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
  Date:   Thu Oct 30 10:09:53 2014 +0100
 =20
      ipv4: Do not cache routing failures due to disabled forwarding.
     =20
      If we cache them, the kernel will reuse them, independently of
      whether forwarding is enabled or not.  Which means that if forwarding=
 is
      disabled on the input interface where the first routing request comes
      from, then that unreachable result will be cached and reused for
      other interfaces, even if forwarding is enabled on them.  The opposit=
e
      is also true.
     =20
      This can be verified with two interfaces A and B and an output interf=
ace
      C, where B has forwarding enabled, but not A and trying
      ip route get $dst iif A from $src && ip route get $dst iif B from $sr=
c
     =20
      Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communicati=
ons.fr>
      Reviewed-by: Julian Anastasov <ja@ssi.bg>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e327c225c911529898ec300cb96d2088893de3df
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Wed Oct 29 17:54:03 2014 -0700
 =20
      cxgb4 : Fix missing initialization of win0_lock
     =20
      win0_lock was being used un-initialized, resulting in warning traces
      being seen when lock debugging is enabled (and just wrong)
     =20
      Fixes : fc5ab0209650 ('cxgb4: Replaced the backdoor mechanism to acce=
ss the HW
       memory with PCIe Window method')
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: Casey Leedom <leedom@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 83810a9a6af310e413ce649c6ca2df2b4946e5a4
  Merge: d70127e e3bd1a8
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 15:49:05 2014 -0400
 =20
      Merge branch 'r8152-net'
     =20
      Hayes Wang says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      r8152: patches for autosuspend
     =20
      There are unexpected processes when enabling autosuspend.
      These patches are used to fix them.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e3bd1a81cd1e3f8ed961e642e97206d715db06c4
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:17 2014 +0800
 =20
      r8152: check WORK_ENABLE in suspend function
     =20
      Avoid unnecessary behavior when autosuspend occurs during open().
      The relative processes should only be run after finishing open().
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f4c7476b041d200c3b347f019eebf05e6d0b47f9
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:16 2014 +0800
 =20
      r8152: reset tp->speed before autoresuming in open function
     =20
      If (tp->speed & LINK_STATUS) is not zero, the rtl8152_resume()
      would call rtl_start_rx() before enabling the tx/rx. Avoid this
      by resetting it to zero.
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 923e1ee3ff0b585cc4f56cf696c8455708537ffb
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:15 2014 +0800
 =20
      r8152: clear SELECTIVE_SUSPEND when autoresuming
     =20
      The flag of SELECTIVE_SUSPEND should be cleared when autoresuming.
      Otherwise, when the system suspend and resume occur, it may have
      the wrong flow.
     =20
      Besides, because the flag of SELECTIVE_SUSPEND couldn't be used
      to check if the hw enables the relative feature, it should alwayes
      be disabled in close().
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 75a916e1944fea8347d2245c62567187e4eff9dd
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:13 2014 -0500
 =20
      rtlwifi: rtl8192se: Fix firmware loading
     =20
      An error in the code makes the allocated space for firmware to be too
      small.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 8ae3c16e41b02db8ffe4121468519d6352baedc1
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:11 2014 -0500
 =20
      rtlwifi: rtl8192ce: Add missing section to read descriptor setting
     =20
      The new version of rtlwifi needs code in rtl92ce_get_desc() that retu=
rns
      the buffer address for read operations.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 30c5ccc6afee39754cff75ad8d775ad39a2ce989
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:10 2014 -0500
 =20
      rtlwifi: rtl8192se: Add missing section to read descriptor setting
     =20
      The new version of rtlwifi needs code in rtl92se_get_desc() that retu=
rns
      the buffer address for read operations.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 501479699ff484ba8acc1d07022271f00cfc55a3
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:09 2014 -0500
 =20
      rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw()
     =20
      Driver rtlwifi has been modified to call ieee80211_register_hw()
      from the probe routine; however, the existing call in the callback
      routine for deferred firmware loading was not removed.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit c0386f1584127442d0f2aea41bc948056d6b1337
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:08 2014 -0500
 =20
      rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing ge=
t_btc_status
     =20
      The recent changes in checking for Bluetooth status added some callba=
cks to code
      in rtlwifi. To make certain that all callbacks are defined, a dummy r=
outine has been
      added to rtlwifi, and the drivers that need to use it are modified.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 3a8fede115f12f7b90524d1ba4e709ce398ce8c6
  Author: Marc Yang <yangyang@marvell.com>
  Date:   Wed Oct 29 22:44:34 2014 +0530
 =20
      mwifiex: restart rxreorder timer correctly
     =20
      During 11n RX reordering, if there is a hole in RX table,
      driver will not send packets to kernel until the rxreorder
      timer expires or the table is full.
      However, currently driver always restarts rxreorder timer when
      receiving a packet, which causes the timer hardly to expire.
      So while connected with to 11n AP in a busy environment,
      ping packets may get blocked for about 30 seconds.
     =20
      This patch fixes this timer restarting by ensuring rxreorder timer
      would only be restarted either timer is not set or start_win
      has changed.
     =20
      Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
      Signed-off-by: Plus Chen <pchen@marvell.com>
      Signed-off-by: Marc Yang <yangyang@marvell.com>
      Signed-off-by: Cathy Luo <cluo@marvell.com>
      Signed-off-by: Avinash Patil <patila@marvell.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit a017ff755e43de9a3221d4ff4f03184ea7b93733
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Wed Oct 29 18:48:05 2014 +0300
 =20
      ath9k: fix some debugfs output
     =20
      The right shift operation has higher precedence than the mask so we
      left shift by "(i * 3)" and then immediately right shift by "(i * 3)"
      then we mask.  It should be left shift, mask, and then right shift.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 664d6a792785cc677c2091038ce10322c8d04ae1
  Author: Cyril Brulebois <kibi@debian.org>
  Date:   Tue Oct 28 16:42:41 2014 +0100
 =20
      wireless: rt2x00: add new rt2800usb device
     =20
      0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
     =20
      References: https://bugs.debian.org/766802
      Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
      Cc: stable@vger.kernel.org
      Signed-off-by: Cyril Brulebois <kibi@debian.org>
      Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit e3215f0ac77ec23b052cb0bf511143038ac2ad7b
  Author: Emil Tantilov <emil.s.tantilov@intel.com>
  Date:   Tue Oct 28 05:50:03 2014 +0000
 =20
      ixgbe: fix race when setting advertised speed
     =20
      Following commands:
     =20
      modprobe ixgbe
      ifconfig ethX up
      ethtool -s ethX advertise 0x020
     =20
      can lead to "setup link failed with code -14" error due to the setup_=
link
      call racing with the SFP detection routine in the watchdog.
     =20
      This patch resolves this issue by protecting the setup_link call with=
 check
      for __IXGBE_IN_SFP_INIT.
     =20
      Reported-by: Scott Harrison <scoharr2@cisco.com>
      Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
      Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit 4d2fcfbcf8141cdf70245a0c0612b8076f4b7e32
  Author: Junwei Zhang <linggao.zjw@alibaba-inc.com>
  Date:   Wed Oct 22 15:29:03 2014 +0000
 =20
      ixgbe: need not repeat init skb with NULL
     =20
      Signed-off-by: Martin Zhang <martinbj2008@gmail.com>
      Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit bc16e47f03a7dce9ad68029b21519265c334eb12
  Author: Roman Gushchin <klamm@yandex-team.ru>
  Date:   Thu Oct 23 03:32:27 2014 +0000
 =20
      igb: don't reuse pages with pfmemalloc flag
     =20
      Incoming packet is dropped silently by sk_filter(), if the skb was
      allocated from pfmemalloc reserves and the corresponding socket is
      not marked with the SOCK_MEMALLOC flag.
     =20
      Igb driver allocates pages for DMA with __skb_alloc_page(), which
      calls alloc_pages_node() with the __GFP_MEMALLOC flag. So, in case
      of OOM condition, igb can get pages with pfmemalloc flag set.
     =20
      If an incoming packet hits the pfmemalloc page and is large enough
      (small packets are copying into the memory, allocated with
      netdev_alloc_skb_ip_align(), so they are not affected), it will be
      dropped.
     =20
      This behavior is ok under high memory pressure, but the problem is
      that the igb driver reuses these mapped pages. So, packets are still
      dropping even if all memory issues are gone and there is a plenty
      of free memory.
     =20
      In my case, some TCP sessions hang on a small percentage (< 0.1%)
      of machines days after OOMs.
     =20
      Fix this by avoiding reuse of such pages.
     =20
      Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
      Tested-by: Aaron Brown "aaron.f.brown@intel.com"
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit a22bb0b9b9b09b4cc711f6d577679773e074dde9
  Author: Francesco Ruggeri <fruggeri@aristanetworks.com>
  Date:   Wed Oct 22 15:29:24 2014 +0000
 =20
      e1000: unset IFF_UNICAST_FLT on WMware 82545EM
     =20
      VMWare's e1000 implementation does not seem to support unicast filter=
ing.
      This can be observed by configuring a macvlan interface on eth0 in a =
VM in
      VMWare Fusion 5.0.5, and trying to use that interface instead of eth0=
.
      Tested on 3.16.
     =20
      Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
      Tested-by: Aaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit d70127e8a942364de8dd140fe73893efda363293
  Author: Nikolay Aleksandrov <nikolay@redhat.com>
  Date:   Tue Oct 28 10:44:01 2014 +0100
 =20
      inet: frags: remove the WARN_ON from inet_evict_bucket
     =20
      The WARN_ON in inet_evict_bucket can be triggered by a valid case:
      inet_frag_kill and inet_evict_bucket can be running in parallel on th=
e
      same queue which means that there has been at least one more ref adde=
d
      by a previous inet_frag_find call, but inet_frag_kill can delete the
      timer before inet_evict_bucket which will cause the WARN_ON() there t=
o
      trigger since we'll have refcnt!=3D1. Now, this case is valid because=
 the
      queue is being "killed" for some reason (removed from the chain list =
and
      its timer deleted) so it will get destroyed in the end by one of the
      inet_frag_put() calls which reaches 0 i.e. refcnt is still valid.
     =20
      CC: Florian Westphal <fw@strlen.de>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Patrick McLean <chutzpah@gentoo.org>
     =20
      Fixes: b13d3cbfb8e8 ("inet: frag: move eviction of queues to work que=
ue")
      Reported-by: Patrick McLean <chutzpah@gentoo.org>
      Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 65ba1f1ec0eff1c25933468e1d238201c0c2cb29
  Author: Nikolay Aleksandrov <nikolay@redhat.com>
  Date:   Tue Oct 28 10:30:34 2014 +0100
 =20
      inet: frags: fix a race between inet_evict_bucket and inet_frag_kill
     =20
      When the evictor is running it adds some chosen frags to a local list=
 to
      be evicted once the chain lock has been released but at the same time
      the *frag_queue can be running for some of the same queues and it
      may call inet_frag_kill which will wait on the chain lock and
      will then delete the queue from the wrong list since it was added in =
the
      eviction one. The fix is simple - check if the queue has the evict fl=
ag
      set under the chain lock before deleting it, this is safe because the
      evict flag is set only under that lock and having the flag set also m=
eans
      that the queue has been detached from the chain list, so no need to d=
elete
      it again.
      An important note to make is that we're safe w.r.t refcnt because
      inet_frag_kill and inet_evict_bucket will sync on the del_timer opera=
tion
      where only one of the two can succeed (or if the timer is executing -
      none of them), the cases are:
      1. inet_frag_kill succeeds in del_timer
       - then the timer ref is removed, but inet_evict_bucket will not add
         this queue to its expire list but will restart eviction in that ch=
ain
      2. inet_evict_bucket succeeds in del_timer
       - then the timer ref is kept until the evictor "expires" the queue, =
but
         inet_frag_kill will remove the initial ref and will set
         INET_FRAG_COMPLETE which will make the frag_expire fn just to remo=
ve
         its ref.
      In the end all of the queue users will do an inet_frag_put and the on=
e
      that reaches 0 will free it. The refcount balance should be okay.
     =20
      CC: Florian Westphal <fw@strlen.de>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Patrick McLean <chutzpah@gentoo.org>
     =20
      Fixes: b13d3cbfb8e8 ("inet: frag: move eviction of queues to work que=
ue")
      Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
      Reported-by: Patrick McLean <chutzpah@gentoo.org>
      Tested-by: Patrick McLean <chutzpah@gentoo.org>
      Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
      Reviewed-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8f4eb70059ee834522ce90a6fce0aa3078c18620
  Author: Tej Parkash <tej.parkash@qlogic.com>
  Date:   Tue Oct 28 01:18:15 2014 -0400
 =20
      cnic: Update the rcu_access_pointer() usages
     =20
      1. Remove the rcu_read_lock/unlock around rcu_access_pointer
      2. Replace the rcu_dereference with rcu_access_pointer
     =20
      Signed-off-by: Tej Parkash <tej.parkash@qlogic.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit cd03cf0158449f9f4c19ecb54dfc97d9bd86eeeb
  Author: Hariprasad Shenai <hariprasad@chelsio.com>
  Date:   Mon Oct 27 23:22:10 2014 +0530
 =20
      cxgb4vf: Replace repetitive pci device ID's with right ones
     =20
      Replaced repetive Device ID's which got added in commit b961f9a48844e=
cf3
      ("cxgb4vf: Remove superfluous "idx" parameter of CH_DEVICE() macro")
     =20
      Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b2ed64a97430a26a63c6ea91c9b50e639a98dfbc
  Author: Lubomir Rintel <lkundrak@v3.sk>
  Date:   Mon Oct 27 17:39:16 2014 +0100
 =20
      ipv6: notify userspace when we added or changed an ipv6 token
     =20
      NetworkManager might want to know that it changed when the router adv=
ertisement
      arrives.
     =20
      Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: Daniel Borkmann <dborkman@redhat.com>
      Acked-by: Daniel Borkmann <dborkman@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d56109020d93337545dd257a790cb429a70acfad
  Author: WANG Cong <xiyou.wangcong@gmail.com>
  Date:   Fri Oct 24 16:55:58 2014 -0700
 =20
      sch_pie: schedule the timer after all init succeed
     =20
      Cc: Vijay Subramanian <vijaynsu@cisco.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
      Acked-by: Eric Dumazet <edumazet@google.com>
 =20
  commit 068301f2be36a5c1ee9a2521c94b98e343612a88
  Merge: 9ffa1fc b77e26d
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 17:26:24 2014 -0400
 =20
      Merge branch 'cdc-ether'
     =20
      Olivier Blin says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      cdc-ether: handle promiscuous mode
     =20
      Since kernel 3.16, my Lenovo USB network adapters (RTL8153) using
      cdc-ether are not working anymore in a bridge.
     =20
      This is due to commit c472ab68ad67db23c9907a27649b7dc0899b61f9, which
      resets the packet filter when the device is bound.
     =20
      The default packet filter set by cdc-ether does not include
      promiscuous, while the adapter seemed to have promiscuous enabled by
      default.
     =20
      This patch series allows to support promiscuous mode for cdc-ether, b=
y
      hooking into set_rx_mode.
     =20
      Incidentally, maybe this device should be handled by the r8152 driver=
,
      but this patch series is still nice for other adapters.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
      Acked-by: Oliver Neukum <oneukum@suse.de>
 =20
  commit b77e26d191590c73b4a982ea3b3b87194069a56a
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:02 2014 +0200
 =20
      cdc-ether: handle promiscuous mode with a set_rx_mode callback
     =20
      Promiscuous mode was not supported anymore with my Lenovo adapters
      (RTL8153) since commit c472ab68ad67db23c9907a27649b7dc0899b61f9
      (cdc-ether: clean packet filter upon probe).
     =20
      It was not possible to use them in a bridge anymore.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Also-analyzed-by: Lo=C3=AFc Yhuel <loic.yhuel@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d80c679bc1526183f1cf4adc54b0b72e8798555e
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:01 2014 +0200
 =20
      cdc-ether: extract usbnet_cdc_update_filter function
     =20
      This will be used by the set_rx_mode callback.
     =20
      Also move a comment about multicast filtering in this new function.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1efed2d06c703489342ab6af2951683e07509c99
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:00 2014 +0200
 =20
      usbnet: add a callback for set_rx_mode
     =20
      To delegate promiscuous mode and multicast filtering to the subdriver=
.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9ffa1fcaef222026a8e031830f8db29d3f2cfc47
  Merge: ebcf34f 704d33e
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 17:08:56 2014 -0400
 =20
      Merge branch 'systemport-net'
     =20
      Florian Fainelli says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      net: systemport: RX path and suspend fixes
     =20
      These two patches fix a race condition where we have our RX interrupt=
s
      enabled, but not NAPI for the RX path, and the second patch fixes an
      issue for packets stuck in RX fifo during a suspend/resume cycle.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 704d33e7006f20f9b4fa7d24a0f08c4b5919b131
  Author: Florian Fainelli <f.fainelli@gmail.com>
  Date:   Tue Oct 28 11:12:01 2014 -0700
 =20
      net: systemport: reset UniMAC coming out of a suspend cycle
     =20
      bcm_sysport_resume() was missing an UniMAC reset which can lead to
      various receive FIFO corruptions coming out of a suspend cycle. If th=
e
      RX FIFO is stuck, it will deliver corrupted/duplicate packets towards
      the host CPU interface.
     =20
      This could be reproduced on crowded network and when Wake-on-LAN is
      enabled for this particular interface because the switch still forwar=
ds
      packets towards the host CPU interface (SYSTEMPORT), and we had to le=
ave
      the UniMAC RX enable bit on to allow matching MagicPackets.
     =20
      Once we re-enter the resume function, there is a small window during
      which the UniMAC receive is still enabled, and we start queueing
      packets, but the RDMA and RBUF engines are not ready, which leads to
      having packets stuck in the UniMAC RX FIFO, ultimately delivered towa=
rds
      the host CPU as corrupted.
     =20
      Fixes: 40755a0fce17 ("net: systemport: add suspend and resume support=
")
      Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8edf0047f4b8e03d94ef88f5a7dec146cce03a06
  Author: Florian Fainelli <f.fainelli@gmail.com>
  Date:   Tue Oct 28 11:12:00 2014 -0700
 =20
      net: systemport: enable RX interrupts after NAPI
     =20
      There is currently a small window during which the SYSTEMPORT adapter
      enables its RX interrupts without having enabled its NAPI handler, wh=
ich
      can result in packets to be discarded during interface bringup.
     =20
      A similar but more serious window exists in bcm_sysport_resume() duri=
ng
      which we can have the RDMA engine not fully prepared to receive packe=
ts
      and yet having RX interrupts enabled.
     =20
      Fix this my moving the RX interrupt enable down to
      bcm_sysport_netif_start() after napi_enable() for the RX path is call=
ed,
      which fixes both call sites: bcm_sysport_open() and
      bcm_sysport_resume().
     =20
      Fixes: b02e6d9ba7ad ("net: systemport: add bcm_sysport_netif_{enable,=
stop}")
      Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ebcf34f3d4be11f994340aff629f3c17171a4f65
  Author: Randy Dunlap <rdunlap@infradead.org>
  Date:   Sun Oct 26 19:14:06 2014 -0700
 =20
      skbuff.h: fix kernel-doc warning for headers_end
     =20
      Fix kernel-doc warning in <linux/skbuff.h> by making both headers_sta=
rt
      and headers_end private fields.
     =20
      Warning(..//include/linux/skbuff.h:654): No description found for par=
ameter 'headers_end[0]'
     =20
      Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 99d881f993f066c75059d24e44c74f7a3fc199bc
  Author: Vince Bridgers <vbridger@opensource.altera.com>
  Date:   Sun Oct 26 14:22:24 2014 -0500
 =20
      net: phy: Add SGMII Configuration for Marvell 88E1145 Initialization
     =20
      Marvell phy 88E1145 configuration & initialization was missing a case
      for initializing SGMII mode. This patch adds that case.
     =20
      Signed-off-by: Vince Bridgers <vbridger@opensource.altera.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 47276fcc2d542e7b15e384c08b1709c1921b06c1
  Author: Mugunthan V N <mugunthanvnm@ti.com>
  Date:   Fri Oct 24 18:51:33 2014 +0530
 =20
      drivers: net:cpsw: fix probe_dt when only slave 1 is pinned out
     =20
      when slave 0 has no phy and slave 1 connected to phy, driver probe wi=
ll
      fail as there is no phy id present for slave 0 device tree, so contin=
uing
      even though no phy-id found, also moving mac-id read later to ensure
      mac-id is read from device tree even when phy-id entry in not found.
     =20
      Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 25946f20b775f5c630d4326dd7a7f1df0576eb57
  Merge: 3923d68 99c8140
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 15:30:15 2014 -0400
 =20
      Merge tag 'master-2014-10-27' of git://git.kernel.org/pub/scm/linux/k=
ernel/git/linville/wireless
     =20
      John W. Linville says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      pull request: wireless 2014-10-28
     =20
      Please pull this batch of fixes intended for the 3.18 stream!
     =20
      For the mac80211 bits, Johannes says:
     =20
      "Here are a few fixes for the wireless stack: one fixes the
      RTS rate, one for a debugfs file, one to return the correct
      channel to userspace, a sanity check for a userspace value
      and the remaining two are just documentation fixes."
     =20
      For the iwlwifi bits, Emmanuel says:
     =20
      "I revert here a patch that caused interoperability issues.
      dvm gets a fix for a bug that was reported by many users.
      Two minor fixes for BT Coex and platform power fix that helps
      reducing latency when the PCIe link goes to low power states."
     =20
      In addition...
     =20
      Felix Fietkau adds a couple of ath code fixes related to regulatory
      rule enforcement.
     =20
      Hauke Mehrtens fixes a build break with bcma when CONFIG_OF_ADDRESS
      is not set.
     =20
      Karsten Wiese provides a trio of minor fixes for rtl8192cu.
     =20
      Kees Cook prevents a potential information leak in rtlwifi.
     =20
      Larry Finger also brings a trio of minor fixes for rtlwifi.
     =20
      Rafa=C5=82 Mi=C5=82ecki adds a device ID to the bcma bus driver.
     =20
      Rickard Strandqvist offers some strn* -> strl* changes in brcmfmac
      to eliminate non-terminated string issues.
     =20
      Sujith Manoharan avoids some ath9k stalls by enabling HW queue contro=
l
      only for MCC.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3923d68dc05033aa843b67d73110a6d402ac6e14
  Merge: f89b775 c146b77
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 15:28:30 2014 -0400
 =20
      Merge branch 'dsa-net'
     =20
      Andrew Lunn says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      DSA tagging mismatches
     =20
      The second patch is a fix, which should be applied to -rc. It is
      possible to get a DSA configuration which does not work. The patch
      stops this happening.
     =20
      The first patch detects this situation, and errors out the probe of
      DSA, making it more obvious something is wrong. It is not required to
      apply it -rc.
     =20
      v2 fixes the use case pointed out by Florian, that a switch driver
      may use DSA_TAG_PROTO_NONE which the patch did not correctly handle.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c146b7788e5721ec15bc0197bedf75849508e7ea
  Author: Andrew Lunn <andrew@lunn.ch>
  Date:   Fri Oct 24 23:44:05 2014 +0200
 =20
      dsa: mv88e6171: Fix tagging protocol/Kconfig
     =20
      The mv88e6171 can support two different tagging protocols, DSA and
      EDSA. The switch driver structure only allows one protocol to be
      enumerated, and DSA was chosen. However the Kconfig entry ensures the
      EDSA tagging code is built. With a minimal configuration, we then end
      up with a mismatch. The probe is successful, EDSA tagging is used, bu=
t
      the switch is configured for DSA, resulting in mangled packets.
     =20
      Change the switch driver structure to enumerate EDSA, fixing the
      mismatch.
     =20
      Signed-off-by: Andrew Lunn <andrew@lunn.ch>
      Fixes: 42f272539487 ("net: DSA: Marvell mv88e6171 switch driver")
      Acked-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ae439286a0dec99cc8029868243689b5b5f3ff75
  Author: Andrew Lunn <andrew@lunn.ch>
  Date:   Fri Oct 24 23:44:04 2014 +0200
 =20
      net: dsa: Error out on tagging protocol mismatches
     =20
      If there is a mismatch between enabled tagging protocols and the
      protocol the switch supports, error out, rather than continue with a
      situation which is unlikely to work.
     =20
      Signed-off-by: Andrew Lunn <andrew@lunn.ch>
      cc: alexander.h.duyck@intel.com
      Acked-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3d53666b40007b55204ee8890618da79a20c9940
  Author: Alex Gartrell <agartrell@fb.com>
  Date:   Mon Oct 6 08:46:19 2014 -0700
 =20
      ipvs: Avoid null-pointer deref in debug code
     =20
      Use daddr instead of reaching into dest.
     =20
      Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: Alex Gartrell <agartrell@fb.com>
      Signed-off-by: Simon Horman <horms@verge.net.au>
 =20
  commit f89b7755f517cdbb755d7543eef986ee9d54e654
  Author: Alexei Starovoitov <ast@plumgrid.com>
  Date:   Thu Oct 23 18:41:08 2014 -0700
 =20
      bpf: split eBPF out of NET
     =20
      introduce two configs:
      - hidden CONFIG_BPF to select eBPF interpreter that classic socket fi=
lters
        depend on
      - visible CONFIG_BPF_SYSCALL (default off) that tracing and sockets c=
an use
     =20
      that solves several problems:
      - tracing and others that wish to use eBPF don't need to depend on NE=
T.
        They can use BPF_SYSCALL to allow loading from userspace or select =
BPF
        to use it directly from kernel in NET-less configs.
      - in 3.18 programs cannot be attached to events yet, so don't force i=
t on
      - when the rest of eBPF infra is there in 3.19+, it's still useful to
        switch it off to minimize kernel size
     =20
      bloat-o-meter on x64 shows:
      add/remove: 0/60 grow/shrink: 0/2 up/down: 0/-15601 (-15601)
     =20
      tested with many different config combinations. Hopefully didn't miss=
 anything.
     =20
      Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
      Acked-by: Daniel Borkmann <dborkman@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8ae3c911b9efcca653c552a9c74957a6cb04a87d
  Merge: 5d26b1f 3bb0626
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 27 19:00:16 2014 -0400
 =20
      Merge branch 'cxgb4-net'
     =20
      Anish Bhatt says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      cxgb4 : DCBx fixes for apps/host lldp agents
     =20
      This patchset  contains some minor fixes for cxgb4 DCBx code. Chiefly=
, cxgb4
      was not cleaning up any apps added to kernel app table when link was =
lost.
      Disabling DCBx in firmware would automatically set DCBx state to host=
-managed
      and enabled, we now wait for an explicit enable call from an lldp age=
nt instead
     =20
      First patch was originally sent to net-next, but considering it appli=
es to
      correcting behaviour of code already in net, I think it qualifies as =
a bug fix.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3bb062613b1ecbd0c388106f61344d699f7859ec
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Thu Oct 23 14:37:31 2014 -0700
 =20
      cxgb4 : Handle dcb enable correctly
     =20
      Disabling DCBx in firmware automatically enables DCBx for control via=
 host
      lldp agents. Wait for an explicit setstate call from an lldp agents t=
o enable
       DCBx instead.
     =20
      Fixes: 76bcb31efc06 ("cxgb4 : Add DCBx support codebase and dcbnl_ops=
")
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 2376c879b80c83424a3013834be97fb9fe2d4180
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Thu Oct 23 14:37:30 2014 -0700
 =20
      cxgb4 : Improve handling of DCB negotiation or loss thereof
     =20
      Clear out any DCB apps we might have added to kernel table when we lo=
se DCB
      sync (or IEEE equivalent event). These were previously left behind an=
d not
      cleaned up correctly. IEEE allows individual components to work indep=
endently,
       so improve check for IEEE completion by specifying individual compon=
ents.
     =20
      Fixes: 10b0046685ab ("cxgb4: IEEE fixes for DCBx state machine")
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5d26b1f50a610fb28700cdc3446590495a5f607c
  Merge: 93a35f5 7965ee9
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 27 18:47:40 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      Netfilter fixes for net
     =20
      The following patchset contains Netfilter fixes for your net tree,
      they are:
     =20
      1) Allow to recycle a TCP port in conntrack when the change role from
         server to client, from Marcelo Leitner.
     =20
      2) Fix possible off by one access in ip_set_nfnl_get_byindex(), patch
         from Dan Carpenter.
     =20
      3) alloc_percpu returns NULL on error, no need for IS_ERR() in nf_tab=
les
         chain statistic updates. From Sabrina Dubroca.
     =20
      4) Don't compile ip options in bridge netfilter, this mangles the pac=
ket
         and bridge should not alter layer >=3D 3 headers when forwarding p=
ackets.
         Patch from Herbert Xu and tested by Florian Westphal.
     =20
      5) Account the final NLMSG_DONE message when calculating the size of =
the
         nflog netlink batches. Patch from Florian Westphal.
     =20
      6) Fix a possible netlink attribute length overflow with large packet=
s.
         Again from Florian Westphal.
     =20
      7) Release the skbuff if nfnetlink_log fails to put the final
         NLMSG_DONE message. This fixes a leak on error. This shouldn't eve=
r
         happen though, otherwise this means we miscalculate the netlink ba=
tch
         size, so spot a warning if this ever happens so we can track down =
the
         problem. This patch from Houcheng Lin.
     =20
      8) Look at the right list when recycling targets in the nft_compat,
         patch from Arturo Borrero.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7965ee93719921ea5978f331da653dfa2d7b99f5
  Author: Arturo Borrero <arturo.borrero.glez@gmail.com>
  Date:   Sun Oct 26 12:22:40 2014 +0100
 =20
      netfilter: nft_compat: fix wrong target lookup in nft_target_select_o=
ps()
     =20
      The code looks for an already loaded target, and the correct list to =
search
      is nft_target_list, not nft_match_list.
     =20
      Signed-off-by: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com=
>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 99c814066e75d09e6a38574c6c395f022a04b730
  Merge: fad1dbc 11b2357
  Author: John W. Linville <linville@tuxdriver.com>
  Date:   Mon Oct 27 13:38:15 2014 -0400
 =20
      Merge tag 'mac80211-for-john-2014-10-23' of git://git.kernel.org/pub/=
scm/linux/kernel/git/jberg/mac80211
     =20
      Johannes Berg <johannes@sipsolutions.net> says:
     =20
      "Here are a few fixes for the wireless stack: one fixes the
      RTS rate, one for a debugfs file, one to return the correct
      channel to userspace, a sanity check for a userspace value
      and the remaining two are just documentation fixes."
     =20
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit fad1dbc8efb4e51e121c745a99c0fb22b420a5c6
  Merge: 0805420 7f2ac8f
  Author: John W. Linville <linville@tuxdriver.com>
  Date:   Mon Oct 27 13:35:59 2014 -0400
 =20
      Merge tag 'iwlwifi-for-john-2014-10-23' of git://git.kernel.org/pub/s=
cm/linux/kernel/git/iwlwifi/iwlwifi-fixes
     =20
      Emmanuel Grumbach <egrumbach@gmail.com> says:
     =20
      "I revert here a patch that caused interoperability issues.
      dvm gets a fix for a bug that was reported by many users.
      Two minor fixes for BT Coex and platform power fix that helps
      reducing latency when the PCIe link goes to low power states."
     =20
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 93a35f59f1b13a02674877e3efdf07ae47e34052
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 23 06:30:30 2014 -0700
 =20
      net: napi_reuse_skb() should check pfmemalloc
     =20
      Do not reuse skb if it was pfmemalloc tainted, otherwise
      future frame might be dropped anyway.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit aa9c5579153535fb317a9d34c7d8eaf02b7ef4cd
  Merge: b71e821 bf1bac5
  Author: David S. Miller <davem@davemloft.net>
  Date:   Sun Oct 26 22:46:08 2014 -0400
 =20
      Merge branch 'mellanox'
     =20
      Eli Cohen says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      irq sync fixes
     =20
      This two patch series fixes a race where an interrupt handler could a=
ccess a
      freed memory.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit bf1bac5b7882daa41249f85fbc97828f0597de5c
  Author: Eli Cohen <eli@dev.mellanox.co.il>
  Date:   Thu Oct 23 15:57:27 2014 +0300
 =20
      net/mlx4_core: Call synchronize_irq() before freeing EQ buffer
     =20
      After moving the EQ ownership to software effectively destroying it, =
call
      synchronize_irq() to ensure that any handler routines running on othe=
r CPU
      cores finish execution. Only then free the EQ buffer.
      The same thing is done when we destroy a CQ which is one of the sourc=
es
      generating interrupts. In the case of CQ we want to avoid completion =
handlers
      on a CQ that was destroyed. In the case we do the same to avoid recei=
ving
      asynchronous events after the EQ has been destroyed and its buffers f=
reed.
     =20
      Signed-off-by: Eli Cohen <eli@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 96e4be06cbfcb8c9c2da7c77bacce0e56b581c0b
  Author: Eli Cohen <eli@dev.mellanox.co.il>
  Date:   Thu Oct 23 15:57:26 2014 +0300
 =20
      net/mlx5_core: Call synchronize_irq() before freeing EQ buffer
     =20
      After destroying the EQ, the object responsible for generating interr=
upts, call
      synchronize_irq() to ensure that any handler routines running on othe=
r CPU
      cores finish execution. Only then free the EQ buffer. This patch solv=
es a very
      rare case when we get panic on driver unload.
      The same thing is done when we destroy a CQ which is one of the sourc=
es
      generating interrupts. In the case of CQ we want to avoid completion =
handlers
      on a CQ that was destroyed. In the case we do the same to avoid recei=
ving
      asynchronous events after the EQ has been destroyed and its buffers f=
reed.
     =20
      Signed-off-by: Eli Cohen <eli@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b71e821de50f0ff92f10f33064ee1713e9014158
  Author: Geert Uytterhoeven <geert@linux-m68k.org>
  Date:   Thu Oct 23 10:25:53 2014 +0200
 =20
      drivers: net: xgene: Rewrite buggy loop in xgene_enet_ecc_init()
     =20
      drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function =E2=80=
=98xgene_enet_ecc_init=E2=80=99:
      drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:126: warning: =E2=
=80=98data=E2=80=99 may be used uninitialized in this function
     =20
      Depending on the arbitrary value on the stack, the loop may terminate
      too early, and cause a bogus -ENODEV failure.
     =20
      Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 013f6579c6e4f9517127a176bfc37bbac0b766cb
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Wed Oct 22 20:06:29 2014 -0700
 =20
      i40e: _MASK vs _SHIFT typo in i40e_handle_mdd_event()
     =20
      We accidentally mask by the _SHIFT variable.  It means that "event" i=
s
      always zero.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Tested-by: Jim Young <jamesx.m.young@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit fe0ca7328d03d36aafecebb3af650e1bb2841c20
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Wed Oct 22 19:43:46 2014 -0700
 =20
      macvlan: fix a race on port dismantle and possible skb leaks
     =20
      We need to cancel the work queue after rcu grace period,
      otherwise it can be rescheduled by incoming packets.
     =20
      We need to purge queue if some skbs are still in it.
     =20
      We can use __skb_queue_head_init() variant in
      macvlan_process_broadcast()
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 412ca1550cbec ("macvlan: Move broadcasts into a work queue")
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 349ce993ac706869d553a1816426d3a4bfda02b1
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 23 12:58:58 2014 -0700
 =20
      tcp: md5: do not use alloc_percpu()
     =20
      percpu tcp_md5sig_pool contains memory blobs that ultimately
      go through sg_set_buf().
     =20
      -> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
     =20
      This requires that whole area is in a physically contiguous portion
      of memory. And that @buf is not backed by vmalloc().
     =20
      Given that alloc_percpu() can use vmalloc() areas, this does not
      fit the requirements.
     =20
      Replace alloc_percpu() by a static DEFINE_PER_CPU() as tcp_md5sig_poo=
l
      is small anyway, there is no gain to dynamically allocate it.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 765cf9976e93 ("tcp: md5: remove one indirection level in tcp_m=
d5sig_pool")
      Reported-by: Crestez Dan Leonard <cdleonard@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 4cc40af08032a513e2e68fa6d7818b77179a86af
  Merge: 5345c1d ecf08d2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Sat Oct 25 14:15:25 2014 -0400
 =20
      Merge branch 'xen-netback'
     =20
      David Vrabel says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      xen-netback: guest Rx queue drain and stall fixes
     =20
      This series fixes two critical xen-netback bugs.
     =20
      1. Netback may consume all of host memory by queuing an unlimited
         number of skb on the internal guest Rx queue.  This behaviour is
         guest triggerable.
     =20
      2. Carrier flapping under high traffic rates which reduces
         performance.
     =20
      The first patch is a prerequite.  Removing support for frontends with
      feature-rx-notify makes it easier to reason about the correctness of
      netback since it no longer has to support this outdated and broken
      mode.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:55 2014 +0100
 =20
      xen-netback: reintroduce guest Rx stall detection
     =20
      If a frontend not receiving packets it is useful to detect this and
      turn off the carrier so packets are dropped early instead of being
      queued and drained when they expire.
     =20
      A to-guest queue is stalled if it doesn't have enough free slots for =
a
      an extended period of time (default 60 s).
     =20
      If at least one queue is stalled, the carrier is turned off (in the
      expectation that the other queues will soon stall as well).  The
      carrier is only turned on once all queues are ready.
     =20
      When the frontend connects, all the queues start in the stalled state
      and only become ready once the frontend queues enough Rx requests.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Reviewed-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f48da8b14d04ca87ffcffe68829afd45f926ec6a
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:54 2014 +0100
 =20
      xen-netback: fix unlimited guest Rx internal queue and carrier flappi=
ng
     =20
      Netback needs to discard old to-guest skb's (guest Rx queue drain) an=
d
      it needs detect guest Rx stalls (to disable the carrier so packets ar=
e
      discarded earlier), but the current implementation is very broken.
     =20
      1. The check in hard_start_xmit of the slot availability did not
         consider the number of packets that were already in the guest Rx
         queue.  This could allow the queue to grow without bound.
     =20
         The guest stops consuming packets and the ring was allowed to fill
         leaving S slot free.  Netback queues a packet requiring more than =
S
         slots (ensuring that the ring stays with S slots free).  Netback
         queue indefinately packets provided that then require S or fewer
         slots.
     =20
      2. The Rx stall detection is not triggered in this case since the
         (host) Tx queue is not stopped.
     =20
      3. If the Tx queue is stopped and a guest Rx interrupt occurs, netbac=
k
         will consider this an Rx purge event which may result in it taking
         the carrier down unnecessarily.  It also considers a queue with
         only 1 slot free as unstalled (even though the next packet might
         not fit in this).
     =20
      The internal guest Rx queue is limited by a byte length (to 512 Kib,
      enough for half the ring).  The (host) Tx queue is stopped and starte=
d
      based on this limit.  This sets an upper bound on the amount of memor=
y
      used by packets on the internal queue.
     =20
      This allows the estimatation of the number of slots for an skb to be
      removed (it wasn't a very good estimate anyway).  Instead, the guest
      Rx thread just waits for enough free slots for a maximum sized packet=
.
     =20
      skbs queued on the internal queue have an 'expires' time (set to the
      current time plus the drain timeout).  The guest Rx thread will detec=
t
      when the skb at the head of the queue has expired and discard expired
      skbs.  This sets a clear upper bound on the length of time an skb can
      be queued for.  For a guest being destroyed the maximum time needed t=
o
      wait for all the packets it sent to be dropped is still the drain
      timeout (10 s) since it will not be sending new packets.
     =20
      Rx stall detection is reintroduced in a later commit.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Reviewed-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit bc96f648df1bbc2729abbb84513cf4f64273a1f1
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:53 2014 +0100
 =20
      xen-netback: make feature-rx-notify mandatory
     =20
      Frontends that do not provide feature-rx-notify may stall because
      netback depends on the notification from frontend to wake the guest R=
x
      thread (even if can_queue is false).
     =20
      This could be fixed but feature-rx-notify was introduced in 2006 and =
I
      am not aware of any frontends that do not implement this.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Acked-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5345c1d417c1b0caf46fd2766d16bb4357a347d8
  Author: Richard Cochran <richardcochran@gmail.com>
  Date:   Wed Oct 22 21:35:15 2014 +0200
 =20
      ptp: restore the makefile for building the test program.
     =20
      This patch brings back the makefile called testptp.mk which was remov=
ed
      in commit adb19fb66eee (Documentation: add makefiles for more targets=
).
     =20
      While the idea of that commit was to improve build coverage of the
      examples, the new Makefile is unable to cross compile the testptp pro=
gram.
      In contrast, the deleted makefile was able to do this just fine.
     =20
      This patch fixes the regression by restoring the original makefile.
     =20
      Signed-off-by: Richard Cochran <richardcochran@gmail.com>
      Acked-by: Peter Foley <pefoley2@pefoley.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b51d3fa364885a2c1e1668f88776c67c95291820
  Author: Houcheng Lin <houcheng@gmail.com>
  Date:   Thu Oct 23 10:36:08 2014 +0200
 =20
      netfilter: nf_log: release skbuff on nlmsg put failure
     =20
      The kernel should reserve enough room in the skb so that the DONE
      message can always be appended.  However, in case of e.g. new attribu=
te
      erronously not being size-accounted for, __nfulnl_send() will still
      try to put next nlmsg into this full skbuf, causing the skb to be stu=
ck
      forever and blocking delivery of further messages.
     =20
      Fix issue by releasing skb immediately after nlmsg_put error and
      WARN() so we can track down the cause of such size mismatch.
     =20
      [ fw@strlen.de: add tailroom/len info to WARN ]
     =20
      Signed-off-by: Houcheng Lin <houcheng@gmail.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit c1e7dc91eed0ed1a51c9b814d648db18bf8fc6e9
  Author: Florian Westphal <fw@strlen.de>
  Date:   Thu Oct 23 10:36:07 2014 +0200
 =20
      netfilter: nfnetlink_log: fix maximum packet length logged to userspa=
ce
     =20
      don't try to queue payloads > 0xffff - NLA_HDRLEN, it does not work.
      The nla length includes the size of the nla struct, so anything large=
r
      results in u16 integer overflow.
     =20
      This patch is similar to
      9cefbbc9c8f9abe (netfilter: nfnetlink_queue: cleanup copy_range usage=
).
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 9dfa1dfe4d5e5e66a991321ab08afe69759d797a
  Author: Florian Westphal <fw@strlen.de>
  Date:   Thu Oct 23 10:36:06 2014 +0200
 =20
      netfilter: nf_log: account for size of NLMSG_DONE attribute
     =20
      We currently neither account for the nlattr size, nor do we consider
      the size of the trailing NLMSG_DONE when allocating nlmsg skb.
     =20
      This can result in nflog to stop working, as __nfulnl_send() re-tries
      sending forever if it failed to append NLMSG_DONE (which will never
      work if buffer is not large enough).
     =20
      Reported-by: Houcheng Lin <houcheng@gmail.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7677e86843e2136a9b05549a9ca47d4f744565b6
  Author: Herbert Xu <herbert@gondor.apana.org.au>
  Date:   Sat Oct 4 22:18:02 2014 +0800
 =20
      bridge: Do not compile options in br_parse_ip_options
     =20
      Commit 462fb2af9788a82a534f8184abfde31574e1cfa0
     =20
      	bridge : Sanitize skb before it enters the IP stack
     =20
      broke when IP options are actually used because it mangles the
      skb as if it entered the IP stack which is wrong because the
      bridge is supposed to operate below the IP stack.
     =20
      Since nobody has actually requested for parsing of IP options
      this patch fixes it by simply reverting to the previous approach
      of ignoring all IP options, i.e., zeroing the IPCB.
     =20
      If and when somebody who uses IP options and actually needs them
      to be parsed by the bridge complains then we can revisit this.
     =20
      Reported-by: David Newall <davidn@davidnewall.com>
      Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
      Tested-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7f2ac8fb31896c9fb70dbd2a2e6642b79996fc13
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Thu Oct 23 08:53:21 2014 +0300
 =20
      iwlwifi: pcie: fix polling in various places
     =20
      iwl_poll_bit may return a strictly positive value when the
      poll doesn't match on the first try.
      This was caught when WoWLAN started failing upon resume
      even if the poll_bit actually succeeded.
     =20
      Also change a wrong print. If we reach the end of
      iwl_pcie_prepare_card_hw, it means that we couldn't
      get the devices.
     =20
      Reviewed-by: Johannes Berg <johannes.berg@intel.com>
      Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 1ffde699aae127e7abdb98dbdedc2cc6a973a1a1
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Oct 20 08:29:55 2014 +0300
 =20
      Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate"
     =20
      This reverts commit aa11bbf3df026d6b1c6b528bef634fd9de7c2619.
      This commit was causing connection issues and is not needed
      if IWL_MVM_RS_RSSI_BASED_INIT_RATE is set to false by default.
     =20
      Regardless of the issues mentioned above, this patch added the
      following WARNING:
     =20
      WARNING: CPU: 0 PID: 3946 at drivers/net/wireless/iwlwifi/mvm/tx.c:19=
0 iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]()
      Got an HT rate for a non data frame 0x8
      CPU: 0 PID: 3946 Comm: wpa_supplicant Tainted: G           O   3.17.0=
+ #6
      Hardware name: LENOVO 20ANCTO1WW/20ANCTO1WW, BIOS GLET71WW (2.25 ) 07=
/02/2014
       0000000000000009 ffffffff814fa911 ffff8804288db8f8 ffffffff81064f52
       0000000000001808 ffff8804288db948 ffff88040add8660 ffff8804291b5600
       0000000000000000 ffffffff81064fb7 ffffffffa07b73d0 0000000000000020
      Call Trace:
       [<ffffffff814fa911>] ? dump_stack+0x41/0x51
       [<ffffffff81064f52>] ? warn_slowpath_common+0x72/0x90
       [<ffffffff81064fb7>] ? warn_slowpath_fmt+0x47/0x50
       [<ffffffffa07a39ea>] ? iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]
       [<ffffffffa07a3cf8>] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm]
       [<ffffffffa079cb9b>] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm]
       [<ffffffffa0746ce9>] ? __ieee80211_tx+0x2b9/0x3c0 [mac80211]
       [<ffffffffa07492f3>] ? ieee80211_tx+0xb3/0x100 [mac80211]
       [<ffffffffa0749c49>] ? ieee80211_subif_start_xmit+0x459/0xca0 [mac80=
211]
       [<ffffffff814116e7>] ? dev_hard_start_xmit+0x337/0x5f0
       [<ffffffff81430d46>] ? sch_direct_xmit+0x96/0x1f0
       [<ffffffff81411ba3>] ? __dev_queue_xmit+0x203/0x4f0
       [<ffffffff8142f670>] ? ether_setup+0x70/0x70
       [<ffffffff814e96a1>] ? packet_sendmsg+0xf81/0x1110
       [<ffffffff8140625c>] ? skb_free_datagram+0xc/0x40
       [<ffffffff813f7538>] ? sock_sendmsg+0x88/0xc0
       [<ffffffff813f7274>] ? move_addr_to_kernel.part.20+0x14/0x60
       [<ffffffff811c47c2>] ? __inode_wait_for_writeback+0x62/0xb0
       [<ffffffff813f7a91>] ? SYSC_sendto+0xf1/0x180
       [<ffffffff813f88f9>] ? __sys_recvmsg+0x39/0x70
       [<ffffffff8150066d>] ? system_call_fastpath+0x1a/0x1f
      ---[ end trace cc19a150d311fc63 ]---
     =20
      which was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=
=3D85691
     =20
      CC: <stable@vger.kernel.org> [3.13+]
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit a0855054e59b0c5b2b00237fdb5147f7bcc18efb
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Sun Oct 5 09:11:14 2014 +0300
 =20
      iwlwifi: dvm: drop non VO frames when flushing
     =20
      When mac80211 wants to ensure that a frame is sent, it calls
      the flush() callback. Until now, iwldvm implemented this by
      waiting that all the frames are sent (ACKed or timeout).
      In case of weak signal, this can take a significant amount
      of time, delaying the next connection (in case of roaming).
      Many users have reported that the flush would take too long
      leading to the following error messages to be printed:
     =20
      iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2
      iwlwifi 0000:03:00.0: Current SW read_ptr 161 write_ptr 201
      iwl data: 00000000: 00 00 00 00 00 00 00 00 fe ff 01 00 00 00 00 00
      [snip]
      iwlwifi 0000:03:00.0: FH TRBs(0) =3D 0x00000000
      [snip]
      iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x000=
0 [9,9]
      [snip]
     =20
      Instead of waiting for these packets, simply drop them. This
      significantly improves the responsiveness of the network.
      Note that all the queues are flushed, but the VO one. This
      is not typically used by the applications and it likely
      contains management frames that are useful for connection
      or roaming.
     =20
      This bug is tracked here:
      https://bugzilla.kernel.org/show_bug.cgi?id=3D56581
     =20
      But it is duplicated in distributions' trackers.
      A simple search in Ubuntu's database led to these bugs:
     =20
      https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1270808
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305406
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356236
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1360597
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361809
     =20
      Cc: <stable@vger.kernel.org>
      Depends-on: 77be2c54c5bd ("mac80211: add vif to flush call")
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit a6cc5163149532734b84c86cbffa4994e527074b
  Author: Matti Gottlieb <matti.gottlieb@intel.com>
  Date:   Mon Sep 29 11:46:04 2014 +0300
 =20
      iwlwifi: mvm: ROC - bug fixes around time events and locking
     =20
      Don't add the time event to the list. We added it several
      times the same time event, which leads to an infinite loop
      when walking the list.
     =20
      Since we (currently) don't support more than one ROC for STA
      vif at a time, enforce this and don't add the time event
      to any list.
     =20
      We were also missing the locking of the mutex which led to
      a lockdep splat - fix that.
     =20
      Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 79b7a69d730180d8bf535e52fe2b4f3dd5904007
  Author: Haim Dreyfuss <haim.dreyfuss@intel.com>
  Date:   Sun Sep 14 12:40:00 2014 +0300
 =20
      iwlwifi: mvm: Add tx power condition to bss_info_changed_ap_ibss
     =20
      The tx power should be limited from many reasons.
      currently, setting the tx power is available by the mvm only for
      station interface. Adding the tx power condition to
      bss_info_changed_ap_ibss make it available also for AP.
     =20
      Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 3856b78c1be32a2afe0618c7a84e05ff8c03cf10
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Sep 22 12:03:41 2014 +0300
 =20
      iwlwifi: mvm: BT coex - fix BT prio for probe requests
     =20
      The probe requests sent during scan must get BT prio 3.
      Fix that.
     =20
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit d14b28fd2c61af0bf310230472e342864d799c98
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Sep 22 16:12:24 2014 +0300
 =20
      iwlwifi: mvm: BT Coex - update the MPLUT Boost register value
     =20
      Cc: <stable@vger.kernel.org> [3.16+]
      Fixes: 2adc8949efab ("iwlwifi: mvm: BT Coex - fix boost register / LU=
T values")
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 405b7338abc5ceac4a420ce7f49cc9b530d4e78b
  Author: Liad Kaufman <liad.kaufman@intel.com>
  Date:   Tue Sep 23 15:15:17 2014 +0300
 =20
      iwlwifi: 8000: fix string given to MODULE_FIRMWARE
     =20
      I changed the string but forgot to update the fix also to
      MODULE_FIRMWARE().
     =20
      Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 9180ac50716a097a407c6d7e7e4589754a922260
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Tue Sep 23 23:02:41 2014 +0300
 =20
      iwlwifi: configure the LTR
     =20
      The LTR is the handshake between the device and the root
      complex about the latency allowed when the bus exits power
      save. This configuration was missing and this led to high
      latency in the link power up. The end user could experience
      high latency in the network because of this.
     =20
      Cc: <stable@vger.kernel.org> [3.10+]
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 08054200117a95afc14c3d2ed3a38bf4e345bf78
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Thu Oct 23 11:27:09 2014 -0500
 =20
      rtlwifi: Add check for get_btc_status callback
     =20
      Drivers that do not use the get_btc_status() callback may not define =
a
      dummy routine. The caller needs to check before making the call.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
      Cc: Thadeu Cascardo <cascardo@cascardo.eti.br>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 763254516187015cb5b391553af35c6ed1f4bb36
  Author: Felix Fietkau <nbd@openwrt.org>
  Date:   Wed Oct 22 18:17:35 2014 +0200
 =20
      ath9k_common: always update value in ath9k_cmn_update_txpow
     =20
      In some cases the limit may be the same as reg->power_limit, but the
      actual value that the hardware uses is not up to date. In that case, =
a
      wrong value for current tx power is tracked internally.
      Fix this by unconditionally updating it.
     =20
      Signed-off-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 4f2b244c7d5b81ce4f0c6c0382f3a3b7c2dbec1c
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:34 2014 +0200
 =20
      rtl8192cu: Prevent Ooops under rtl92c_set_fw_rsvdpagepkt
     =20
      rtl92c_set_fw_rsvdpagepkt is used by rtl8192cu and its pci sibling rt=
l8192ce.
      rtl_cmd_send_packet crashes when called inside rtl8192cu because it w=
orks on
      memory allocated only by rtl8192ce.
      Fix the crash by calling a dummy function when used in rtl8192cu.
      Comparision with the realtek vendor driver makes me think, something =
is missing in
      the dummy function.
      Short test as WPA2 station show good results connected to an 802.11g =
basestation.
      Traffic stops after few MBytes as WPA2 station connected to an 802.11=
n basestation.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit cefe3dfdb9f5f498cae9871f7e52800f5e22c614
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:33 2014 +0200
 =20
      rtl8192cu: Call ieee80211_register_hw from rtl_usb_probe
     =20
      In a previous patch the call to ieee80211_register_hw was moved from =
the
      load firmware callback to the rtl_pci_probe only.
      rt8192cu also uses this callback. Currently it doesnt create a wlan%d=
 device.
      Fill in the call to ieee80211_register_hw in rtl_usb_probe.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit b2d624a5810203a1a8b7735e1ec5685109b22fc3
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:32 2014 +0200
 =20
      rtl8192cu: Fix for rtlwifi's bluetooth coexist functionality
     =20
      Initialize function pointer with a function indicating bt coexist is =
not there.
      Prevents Ooops.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 94e05900770c0abe31200881df93e41d296fe8bd
  Author: Felix Fietkau <nbd@openwrt.org>
  Date:   Wed Oct 22 15:27:53 2014 +0200
 =20
      ath: use CTL region from cfg80211 if unset in EEPROM
     =20
      Many AP devices do not have the proper regulatory domain programmed i=
n
      EEPROM. Instead they expect the software to set the appropriate regio=
n.
      For these devices, the country code defaults to US, and the driver us=
es
      the US CTL tables as well.
      On devices bought in Europe this can lead to tx power being set too h=
igh
      on the band edges, even if the cfg80211 regdomain is set correctly.
      Fix this issue by taking into account the DFS region, but only when t=
he
      EEPROM regdomain is set to default.
     =20
      Signed-off-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit d514aefb8ce89562ef2d7dcddc530e5de6287c4b
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Tue Oct 21 10:52:51 2014 -0500
 =20
      rtlwifi: rtl8821ae: Fix possible array overrun
     =20
      The kbuild test robot reported a possible array overrun. The affected=
 code
      checks for overruns, but fails to take the steps necessary to fix the=
m.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 868caae3fe2e35e2353d86af95e03eeaa9439d97
  Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Date:   Tue Oct 21 19:23:02 2014 +0530
 =20
      ath9k: Enable HW queue control only for MCC
     =20
      Enabling HW queue control for normal (non-mcc) mode
      causes problems with queue management, resulting
      in traffic stall. Since it is mainly required for
      fairness in MCC mode, disable it for the general case.
     =20
      Bug: https://dev.openwrt.org/ticket/18164
     =20
      Cc: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 598a0df07fc6c4642f9b0497cef1233e41d4c987
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Oct 20 14:57:08 2014 -0700
 =20
      rtlwifi: prevent format string usage from leaking
     =20
      Use "%s" in the workqueue allocation to make sure the rtl_hal_cfg nam=
e
      can never accidentally leak information via a format string.
     =20
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 34b6d4299923ec9101bbf364440cee36420b3fc0
  Author: Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
  Date:   Wed Oct 15 07:51:44 2014 +0200
 =20
      bcma: add another PCI ID of device with BCM43228
     =20
      It was found attached to the BCM47081A0 SoC. Log:
      bcma: bus0: Found chip with id 43228, rev 0x00 and package 0x08
     =20
      Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 59dfdd92288e55bed374309a9944c3a95b4e13c9
  Author: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
  Date:   Sun Oct 12 13:42:14 2014 +0200
 =20
      brcmfmac: dhd_sdio.c: Cleaning up missing null-terminate in conjuncti=
on with strncpy
     =20
      Replacing strncpy with strlcpy to avoid strings that lacks null termi=
nate.
      And changed from using strncat to strlcat to simplify code.
     =20
      Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigit=
al.se>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 47481d977cb2987ab363202c68a79ec1bccd357c
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Sat Oct 11 12:59:53 2014 -0500
 =20
      rtlwifi: rtl8192ee: Prevent log spamming for switch statements
     =20
      The driver logs a message when the default branch of switch statement=
s are
      taken. Such information is useful when debugging, but these log items=
 should
      not be seen for standard usage.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 78afe83c3b008e25123bd1be36ee4b6595e595d1
  Author: Hauke Mehrtens <hauke@hauke-m.de>
  Date:   Thu Oct 9 23:39:41 2014 +0200
 =20
      bcma: fix build when CONFIG_OF_ADDRESS is not set
     =20
      Commit 2101e533f41a ("bcma: register bcma as device tree driver")
      introduces a hard dependency on OF_ADDRESS into the bcma driver.
      OF_ADDRESS is specifically disabled for the sparc architecture.
      This results in the following error when building sparc64:allmodconfi=
g.
     =20
      drivers/bcma/main.c: In function 'bcma_of_find_child_device':
      drivers/bcma/main.c:150:3: error: implicit declaration of function 'o=
f_translate_address'
     =20
      Fixes: 2101e533f41a ("bcma: register bcma as device tree driver")
      Reported-by: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 942396b01989d54977120f3625e5ba31afe7a75c
  Author: Haiyang Zhang <haiyangz@microsoft.com>
  Date:   Wed Oct 22 13:47:18 2014 -0700
 =20
      hyperv: Fix the total_data_buflen in send path
     =20
      total_data_buflen is used by netvsc_send() to decide if a packet can =
be put
      into send buffer. It should also include the size of RNDIS message be=
fore the
      Ethernet frame. Otherwise, a messge with total size bigger than send_=
section_size
      may be copied into the send buffer, and cause data corruption.
     =20
      [Request to include this patch to the Stable branches]
     =20
      Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
      Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f765678e325b4ae3e2fbdb304fc2d5ee018aa860
  Merge: 81f35ff 55ca6bc
  Author: David S. Miller <davem@davemloft.net>
  Date:   Wed Oct 22 17:50:39 2014 -0400
 =20
      Merge branch 'amd-xgbe'
     =20
      Tom Lendacky says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      amd-xgbe: AMD XGBE driver fixes 2014-10-22
     =20
      The following series of patches includes fixes to the driver.
     =20
      - Properly handle feature changes via ethtool by using correctly size=
d
        variables
      - Perform proper napi packet counting and budget checking
     =20
      This patch series is based on net.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 55ca6bcd733b739d5667d48d7591899f376dcfb8
  Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Date:   Wed Oct 22 11:26:17 2014 -0500
 =20
      amd-xgbe: Fix napi Rx budget accounting
     =20
      Currently the amd-xgbe driver increments the packets processed counte=
r
      each time a descriptor is processed.  Since a packet can be represent=
ed
      by more than one descriptor incrementing the counter in this way is n=
ot
      appropriate.  Also, since multiple descriptors cause the budget check
      to be short circuited, sometimes the returned value from the poll
      function would be larger than the budget value resulting in a WARN_ON=
CE
      being triggered.
     =20
      Update the polling logic to properly account for the number of packet=
s
      processed and exit when the budget value is reached.
     =20
      Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 386f1c9650b7fe4849d2942bd42f41f0ca3aedfb
  Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Date:   Wed Oct 22 11:26:11 2014 -0500
 =20
      amd-xgbe: Properly handle feature changes via ethtool
     =20
      The ndo_set_features callback function was improperly using an unsign=
ed
      int to save the current feature value for features such as NETIF_F_RX=
CSUM.
      Since that feature is in the upper 32 bits of a 64 bit variable the
      result was always 0 making it not possible to actually turn off the
      hardware RX checksum support.  Change the unsigned int type to the
      netdev_features_t type in order to properly capture the current value
      and perform the proper operation.
     =20
      Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 81f35ffde0e95ee18de83646bbf93dda55d9cc8b
  Author: Philipp Zabel <p.zabel@pengutronix.de>
  Date:   Wed Oct 22 16:34:35 2014 +0200
 =20
      net: fec: ptp: fix NULL pointer dereference if ptp_clock is not set
     =20
      Since commit 278d24047891 (net: fec: ptp: Enable PPS output based on =
ptp clock)
      fec_enet_interrupt calls fec_ptp_check_pps_event unconditionally, whi=
ch calls
      into ptp_clock_event. If fep->ptp_clock is NULL, ptp_clock_event trie=
s to
      dereference the NULL pointer.
      Since on i.MX53 fep->bufdesc_ex is not set, fec_ptp_init is never cal=
led,
      and fep->ptp_clock is NULL, which reliably causes a kernel panic.
     =20
      This patch adds a check for fep->ptp_clock =3D=3D NULL in fec_enet_in=
terrupt.
     =20
      Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9e7ceb060754f134231f68cb29d5db31419fe1ed
  Author: Sathya Perla <sathya.perla@emulex.com>
  Date:   Wed Oct 22 21:42:01 2014 +0530
 =20
      net: fix saving TX flow hash in sock for outgoing connections
     =20
      The commit "net: Save TX flow hash in sock and set in skbuf on xmit"
      introduced the inet_set_txhash() and ip6_set_txhash() routines to cal=
culate
      and record flow hash(sk_txhash) in the socket structure. sk_txhash is=
 used
      to set skb->hash which is used to spread flows across multiple TXQs.
     =20
      But, the above routines are invoked before the source port of the con=
nection
      is created. Because of this all outgoing connections that just differ=
 in the
      source port get hashed into the same TXQ.
     =20
      This patch fixes this problem for IPv4/6 by invoking the the above ro=
utines
      after the source port is available for the socket.
     =20
      Fixes: b73c3d0e4("net: Save TX flow hash in sock and set in skbuf on =
xmit")
     =20
      Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
      Acked-by: Eric Dumazet <edumazet@google.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 789f202326640814c52f82e80cef3584d8254623
  Author: Li RongQing <roy.qing.li@gmail.com>
  Date:   Wed Oct 22 17:09:53 2014 +0800
 =20
      xfrm6: fix a potential use after free in xfrm6_policy.c
     =20
      pskb_may_pull() maybe change skb->data and make nh and exthdr pointer
      oboslete, so recompute the nd and exthdr
     =20
      Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8751b12cd93cc37337256f650e309b8364d40b35
  Author: LEROY Christophe <christophe.leroy@c-s.fr>
  Date:   Wed Oct 22 09:05:47 2014 +0200
 =20
      net: fs_enet: set back promiscuity mode after restart
     =20
      After interface restart (eg: after link disconnection/reconnection), =
the bridge
      function doesn't work anymore. This is due to the promiscuous mode be=
ing cleared
      by the restart.
     =20
      The mac-fcc already includes code to set the promiscuous mode back du=
ring the restart.
      This patch adds the same handling to mac-fec and mac-scc.
     =20
      Tested with bridge function on MPC885 with FEC.
     =20
      Reported-by: Germain Montoies <germain.montoies@c-s.fr>
      Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit a63ba13eec092b70d4e5522d692eaeb2f9747387
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Tue Oct 21 16:06:05 2014 +0200
 =20
      net: tso: fix unaligned access to crafted TCP header in helper API
     =20
      The crafted header start address is from a driver supplied buffer, wh=
ich
      one can reasonably expect to be aligned on a 4-bytes boundary.
      However ATM the TSO helper API is only used by ethernet drivers and
      the tcp header will then be aligned to a 2-bytes only boundary from t=
he
      header start address.
     =20
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8fc963515e893867330dec87464e9edc5204c024
  Author: Jon Cooper <jcooper@solarflare.com>
  Date:   Tue Oct 21 14:50:29 2014 +0100
 =20
      sfc: remove incorrect EFX_BUG_ON_PARANOID check
     =20
      write_count and insert_count can wrap around, making > check invalid.
     =20
      Fixes: 70b33fb0ddec827cbbd14cdc664fc27b2ef4a6b6 ("sfc: add support fo=
r
       skb->xmit_more").
     =20
      Signed-off-by: Edward Cree <ecree@solarflare.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c123bb7163043bb8f33858cf8e45b01c17dbd171
  Author: Sabrina Dubroca <sd@queasysnail.net>
  Date:   Tue Oct 21 11:08:21 2014 +0200
 =20
      netfilter: nf_tables: check for NULL in nf_tables_newchain pcpu stats=
 allocation
     =20
      alloc_percpu returns NULL on failure, not a negative error code.
     =20
      Fixes: ff3cd7b3c922 ("netfilter: nf_tables: refactor chain statistic =
routines")
      Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 0f9f5e1b83abd2b37c67658e02a6fc9001831fa5
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Tue Oct 21 11:28:12 2014 +0300
 =20
      netfilter: ipset: off by one in ip_set_nfnl_get_byindex()
     =20
      The ->ip_set_list[] array is initialized in ip_set_net_init() and it
      has ->ip_set_max elements so this check should be >=3D instead of >
      otherwise we are off by one.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit e37ad9fd636071e45368d1d9cc3b7b421281ce7f
  Author: Marcelo Leitner <mleitner@redhat.com>
  Date:   Mon Oct 13 13:09:28 2014 -0300
 =20
      netfilter: nf_conntrack: allow server to become a client in TW handli=
ng
     =20
      When a port that was used to listen for inbound connections gets clos=
ed
      and reused for outgoing connections (like rsh ends up doing for stder=
r
      flow), current we may reject the SYN/ACK packet for the new connectio=
n
      because tcp_conntracks states forbirds a port to become a client whil=
e
      there is still a TIME_WAIT entry in there for it.
     =20
      As TCP may expire the TIME_WAIT socket in 60s and conntrack's timeout
      for it is 120s, there is a ~60s window that the application can end u=
p
      opening a port that conntrack will end up blocking.
     =20
      This patch fixes this by simply allowing such state transition: if we
      see a SYN, in TIME_WAIT state, on REPLY direction, move it to sSS. No=
te
      that the rest of the code already handles this situation, more
      specificly in tcp_packet(), first switch clause.
     =20
      Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
      Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7c1c97d54f9bfc810908d3903cb8bcacf734df18
  Author: Sabrina Dubroca <sd@queasysnail.net>
  Date:   Tue Oct 21 11:23:30 2014 +0200
 =20
      net: sched: initialize bstats syncp
     =20
      Use netdev_alloc_pcpu_stats to allocate percpu stats and initialize s=
yncp.
     =20
      Fixes: 22e0f8b9322c "net: sched: make bstats per cpu and estimator RC=
U safe"
      Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
      Acked-by: Cong Wang <cwang@twopensource.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 32bf08a6257b9c7380dcd040af3c0858eee3ef05
  Author: Alexei Starovoitov <ast@plumgrid.com>
  Date:   Mon Oct 20 14:54:57 2014 -0700
 =20
      bpf: fix bug in eBPF verifier
     =20
      while comparing for verifier state equivalency the comparison
      was missing a check for uninitialized register.
      Make sure it does so and add a testcase.
     =20
      Fixes: f1bca824dabb ("bpf: add search pruning optimization to verifie=
r")
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
      Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 78fd1d0ab072d4d9b5f0b7c14a1516665170b565
  Author: Thomas Graf <tgraf@suug.ch>
  Date:   Tue Oct 21 22:05:38 2014 +0200
 =20
      netlink: Re-add locking to netlink_lookup() and seq walker
     =20
      The synchronize_rcu() in netlink_release() introduces unacceptable
      latency. Reintroduce minimal lookup so we can drop the
      synchronize_rcu() until socket destruction has been RCUfied.
     =20
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
      Reported-and-tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: Thomas Graf <tgraf@suug.ch>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1a194c2d59c55c37cb4c0c459d5418071a141341
  Author: Ying Xue <ying.xue@windriver.com>
  Date:   Mon Oct 20 14:46:35 2014 +0800
 =20
      tipc: fix lockdep warning when intra-node messages are delivered
     =20
      When running tipcTC&tipcTS test suite, below lockdep unsafe locking
      scenario is reported:
     =20
      [ 1109.997854]
      [ 1109.997988] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      [ 1109.998290] [ INFO: inconsistent lock state ]
      [ 1109.998575] 3.17.0-rc1+ #113 Not tainted
      [ 1109.998762] ---------------------------------
      [ 1109.998762] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [ 1109.998762] swapper/7/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [ 1109.998762]  (slock-AF_TIPC){+.?...}, at: [<ffffffffa0011969>] tip=
c_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762] {SOFTIRQ-ON-W} state was registered at:
      [ 1109.998762]   [<ffffffff810a4770>] __lock_acquire+0x6a0/0x1d80
      [ 1109.998762]   [<ffffffff810a6555>] lock_acquire+0x95/0x1e0
      [ 1109.998762]   [<ffffffff81a2d1ce>] _raw_spin_lock+0x3e/0x80
      [ 1109.998762]   [<ffffffffa0011969>] tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]   [<ffffffffa0004fe8>] tipc_link_xmit+0xa8/0xc0 [tipc]
      [ 1109.998762]   [<ffffffffa000ec6f>] tipc_sendmsg+0x15f/0x550 [tipc]
      [ 1109.998762]   [<ffffffffa000f165>] tipc_connect+0x105/0x140 [tipc]
      [ 1109.998762]   [<ffffffff817676ee>] SYSC_connect+0xae/0xc0
      [ 1109.998762]   [<ffffffff81767b7e>] SyS_connect+0xe/0x10
      [ 1109.998762]   [<ffffffff817a9788>] compat_SyS_socketcall+0xb8/0x20=
0
      [ 1109.998762]   [<ffffffff81a306e5>] sysenter_dispatch+0x7/0x1f
      [ 1109.998762] irq event stamp: 241060
      [ 1109.998762] hardirqs last  enabled at (241060): [<ffffffff8105a4ad=
>] __local_bh_enable_ip+0x6d/0xd0
      [ 1109.998762] hardirqs last disabled at (241059): [<ffffffff8105a46f=
>] __local_bh_enable_ip+0x2f/0xd0
      [ 1109.998762] softirqs last  enabled at (241020): [<ffffffff81059a52=
>] _local_bh_enable+0x22/0x50
      [ 1109.998762] softirqs last disabled at (241021): [<ffffffff8105a626=
>] irq_exit+0x96/0xc0
      [ 1109.998762]
      [ 1109.998762] other info that might help us debug this:
      [ 1109.998762]  Possible unsafe locking scenario:
      [ 1109.998762]
      [ 1109.998762]        CPU0
      [ 1109.998762]        ----
      [ 1109.998762]   lock(slock-AF_TIPC);
      [ 1109.998762]   <Interrupt>
      [ 1109.998762]     lock(slock-AF_TIPC);
      [ 1109.998762]
      [ 1109.998762]  *** DEADLOCK ***
      [ 1109.998762]
      [ 1109.998762] 2 locks held by swapper/7/0:
      [ 1109.998762]  #0:  (rcu_read_lock){......}, at: [<ffffffff81782dc9>=
] __netif_receive_skb_core+0x69/0xb70
      [ 1109.998762]  #1:  (rcu_read_lock){......}, at: [<ffffffffa0001c90>=
] tipc_l2_rcv_msg+0x40/0x260 [tipc]
      [ 1109.998762]
      [ 1109.998762] stack backtrace:
      [ 1109.998762] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.17.0-rc1+ =
#113
      [ 1109.998762] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [ 1109.998762]  ffffffff82745830 ffff880016c03828 ffffffff81a209eb 00=
00000000000007
      [ 1109.998762]  ffff880017b3cac0 ffff880016c03888 ffffffff81a1c5ef 00=
00000000000001
      [ 1109.998762]  ffff880000000001 ffff880000000000 ffffffff81012d4f 00=
00000000000000
      [ 1109.998762] Call Trace:
      [ 1109.998762]  <IRQ>  [<ffffffff81a209eb>] dump_stack+0x4e/0x68
      [ 1109.998762]  [<ffffffff81a1c5ef>] print_usage_bug+0x1f1/0x202
      [ 1109.998762]  [<ffffffff81012d4f>] ? save_stack_trace+0x2f/0x50
      [ 1109.998762]  [<ffffffff810a406c>] mark_lock+0x28c/0x2f0
      [ 1109.998762]  [<ffffffff810a3440>] ? print_irq_inversion_bug.part.4=
6+0x1f0/0x1f0
      [ 1109.998762]  [<ffffffff810a467d>] __lock_acquire+0x5ad/0x1d80
      [ 1109.998762]  [<ffffffff810a70dd>] ? trace_hardirqs_on+0xd/0x10
      [ 1109.998762]  [<ffffffff8108ace8>] ? sched_clock_cpu+0x98/0xc0
      [ 1109.998762]  [<ffffffff8108ad2b>] ? local_clock+0x1b/0x30
      [ 1109.998762]  [<ffffffff810a10dc>] ? lock_release_holdtime.part.29+=
0x1c/0x1a0
      [ 1109.998762]  [<ffffffff8108aa05>] ? sched_clock_local+0x25/0x90
      [ 1109.998762]  [<ffffffffa000dec0>] ? tipc_sk_get+0x60/0x80 [tipc]
      [ 1109.998762]  [<ffffffff810a6555>] lock_acquire+0x95/0x1e0
      [ 1109.998762]  [<ffffffffa0011969>] ? tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffff810a6fb6>] ? trace_hardirqs_on_caller+0xa6/=
0x1c0
      [ 1109.998762]  [<ffffffff81a2d1ce>] _raw_spin_lock+0x3e/0x80
      [ 1109.998762]  [<ffffffffa0011969>] ? tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffffa000dec0>] ? tipc_sk_get+0x60/0x80 [tipc]
      [ 1109.998762]  [<ffffffffa0011969>] tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffffa00076bd>] tipc_rcv+0x5ed/0x960 [tipc]
      [ 1109.998762]  [<ffffffffa0001d1c>] tipc_l2_rcv_msg+0xcc/0x260 [tipc=
]
      [ 1109.998762]  [<ffffffffa0001c90>] ? tipc_l2_rcv_msg+0x40/0x260 [ti=
pc]
      [ 1109.998762]  [<ffffffff81783345>] __netif_receive_skb_core+0x5e5/0=
xb70
      [ 1109.998762]  [<ffffffff81782dc9>] ? __netif_receive_skb_core+0x69/=
0xb70
      [ 1109.998762]  [<ffffffff81784eb9>] ? dev_gro_receive+0x259/0x4e0
      [ 1109.998762]  [<ffffffff817838f6>] __netif_receive_skb+0x26/0x70
      [ 1109.998762]  [<ffffffff81783acd>] netif_receive_skb_internal+0x2d/=
0x1f0
      [ 1109.998762]  [<ffffffff81785518>] napi_gro_receive+0xd8/0x240
      [ 1109.998762]  [<ffffffff815bf854>] e1000_clean_rx_irq+0x2c4/0x530
      [ 1109.998762]  [<ffffffff815c1a46>] e1000_clean+0x266/0x9c0
      [ 1109.998762]  [<ffffffff8108ad2b>] ? local_clock+0x1b/0x30
      [ 1109.998762]  [<ffffffff8108aa05>] ? sched_clock_local+0x25/0x90
      [ 1109.998762]  [<ffffffff817842b1>] net_rx_action+0x141/0x310
      [ 1109.998762]  [<ffffffff810bd710>] ? handle_fasteoi_irq+0xe0/0x150
      [ 1109.998762]  [<ffffffff81059fa6>] __do_softirq+0x116/0x4d0
      [ 1109.998762]  [<ffffffff8105a626>] irq_exit+0x96/0xc0
      [ 1109.998762]  [<ffffffff81a30d07>] do_IRQ+0x67/0x110
      [ 1109.998762]  [<ffffffff81a2ee2f>] common_interrupt+0x6f/0x6f
      [ 1109.998762]  <EOI>  [<ffffffff8100d2b7>] ? default_idle+0x37/0x250
      [ 1109.998762]  [<ffffffff8100d2b5>] ? default_idle+0x35/0x250
      [ 1109.998762]  [<ffffffff8100dd1f>] arch_cpu_idle+0xf/0x20
      [ 1109.998762]  [<ffffffff810999fd>] cpu_startup_entry+0x27d/0x4d0
      [ 1109.998762]  [<ffffffff81034c78>] start_secondary+0x188/0x1f0
     =20
      When intra-node messages are delivered from one process to another
      process, tipc_link_xmit() doesn't disable BH before it directly calls
      tipc_sk_rcv() on process context to forward messages to destination
      socket. Meanwhile, if messages delivered by remote node arrive at the
      node and their destinations are also the same socket, tipc_sk_rcv()
      running on process context might be preempted by tipc_sk_rcv() runnin=
g
      BH context. As a result, the latter cannot obtain the socket lock as
      the lock was obtained by the former, however, the former has no chanc=
e
      to be run as the latter is owning the CPU now, so headlock happens. T=
o
      avoid it, BH should be always disabled in tipc_sk_rcv().
     =20
      Signed-off-by: Ying Xue <ying.xue@windriver.com>
      Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7b8613e0a1502b43b3b36c93c66f835c891f63b3
  Author: Ying Xue <ying.xue@windriver.com>
  Date:   Mon Oct 20 14:44:25 2014 +0800
 =20
      tipc: fix a potential deadlock
     =20
      Locking dependency detected below possible unsafe locking scenario:
     =20
                 CPU0                          CPU1
      T0:  tipc_named_rcv()                tipc_rcv()
      T1:  [grab nametble write lock]*     [grab node lock]*
      T2:  tipc_update_nametbl()           tipc_node_link_up()
      T3:  tipc_nodesub_subscribe()        tipc_nametbl_publish()
      T4:  [grab node lock]*               [grab nametble write lock]*
     =20
      The opposite order of holding nametbl write lock and node lock on
      above two different paths may result in a deadlock. If we move the
      the updating of the name table after link state named out of node
      lock, the reverse order of holding locks will be eliminated, and
      as a result, the deadlock risk.
     =20
      Signed-off-by: Ying Xue <ying.xue@windriver.com>
      Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 73829bf6fec70703f10e360676d81d327f21ebf6
  Merge: d10845f 39dc90c
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 21 15:24:30 2014 -0400
 =20
      Merge branch 'enic'
     =20
      Govindarajulu Varadarajan says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      enic: Bug fixes
     =20
      This series fixes the following problem.
     =20
      Please apply this to net.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 39dc90c159c1bcc0fdd42913a7d560b1a1cd3acf
  Author: Govindarajulu Varadarajan <_govind@gmx.com>
  Date:   Sun Oct 19 14:20:28 2014 +0530
 =20
      enic: Do not call napi_disable when preemption is disabled.
     =20
      In enic_stop, we disable preemption using local_bh_disable(). We disa=
ble
      preemption to wait for busy_poll to finish.
     =20
      napi_disable should not be called here as it might sleep.
     =20
      Moving napi_disable() call out side of local_bh_disable.
     =20
      BUG: sleeping function called from invalid context at include/linux/n=
etdevice.h:477
      in_atomic(): 1, irqs_disabled(): 0, pid: 443, name: ifconfig
      INFO: lockdep is turned off.
      Preemption disabled at:[<ffffffffa029c5c4>] enic_rfs_flw_tbl_free+0x3=
4/0xd0 [enic]
     =20
      CPU: 31 PID: 443 Comm: ifconfig Not tainted 3.17.0-netnext-05504-g59f=
35b8 #268
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       ffff8800dac10000 ffff88020b8dfcb8 ffffffff8148a57c 0000000000000000
       ffff88020b8dfcd0 ffffffff8107e253 ffff8800dac12a40 ffff88020b8dfd10
       ffffffffa029305b ffff88020b8dfd48 ffff8800dac10000 ffff88020b8dfd48
      Call Trace:
       [<ffffffff8148a57c>] dump_stack+0x4e/0x7a
       [<ffffffff8107e253>] __might_sleep+0x123/0x1a0
       [<ffffffffa029305b>] enic_stop+0xdb/0x4d0 [enic]
       [<ffffffff8138ed7d>] __dev_close_many+0x9d/0xf0
       [<ffffffff8138ef81>] __dev_close+0x31/0x50
       [<ffffffff813974a8>] __dev_change_flags+0x98/0x160
       [<ffffffff81397594>] dev_change_flags+0x24/0x60
       [<ffffffff814085fd>] devinet_ioctl+0x63d/0x710
       [<ffffffff81139c16>] ? might_fault+0x56/0xc0
       [<ffffffff81409ef5>] inet_ioctl+0x65/0x90
       [<ffffffff813768e0>] sock_do_ioctl+0x20/0x50
       [<ffffffff81376ebb>] sock_ioctl+0x20b/0x2e0
       [<ffffffff81197250>] do_vfs_ioctl+0x2e0/0x500
       [<ffffffff81492619>] ? sysret_check+0x22/0x5d
       [<ffffffff81285f23>] ? __this_cpu_preempt_check+0x13/0x20
       [<ffffffff8109fe19>] ? trace_hardirqs_on_caller+0x119/0x270
       [<ffffffff811974ac>] SyS_ioctl+0x3c/0x80
       [<ffffffff814925ed>] system_call_fastpath+0x1a/0x1f
     =20
      Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b6931c9ba728d60c542c39ff037fe6f595c074a2
  Author: Govindarajulu Varadarajan <_govind@gmx.com>
  Date:   Sun Oct 19 14:20:27 2014 +0530
 =20
      enic: fix possible deadlock in enic_stop/ enic_rfs_flw_tbl_free
     =20
      The following warning is shown when spinlock debug is enabled.
     =20
      This occurs when enic_flow_may_expire timer function is running and
      enic_stop is called on same CPU.
     =20
      Fix this by using spink_lock_bh().
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      [ INFO: inconsistent lock state ]
      3.17.0-netnext-05504-g59f35b8 #268 Not tainted
      ---------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      ifconfig/443 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&enic->rfs_h.lock)->rlock){+.?...}, at:
      enic_rfs_flw_tbl_free+0x34/0xd0 [enic]
      {IN-SOFTIRQ-W} state was registered at:
        [<ffffffff810a25af>] __lock_acquire+0x83f/0x21c0
        [<ffffffff810a45f2>] lock_acquire+0xa2/0xd0
        [<ffffffff814913fc>] _raw_spin_lock+0x3c/0x80
        [<ffffffffa029c3d5>] enic_flow_may_expire+0x25/0x130[enic]
        [<ffffffff810bcd07>] call_timer_fn+0x77/0x100
        [<ffffffff810bd8e3>] run_timer_softirq+0x1e3/0x270
        [<ffffffff8105f9ae>] __do_softirq+0x14e/0x280
        [<ffffffff8105fdae>] irq_exit+0x8e/0xb0
        [<ffffffff8103da0f>] smp_apic_timer_interrupt+0x3f/0x50
        [<ffffffff81493742>] apic_timer_interrupt+0x72/0x80
        [<ffffffff81018143>] default_idle+0x13/0x20
        [<ffffffff81018a6a>] arch_cpu_idle+0xa/0x10
        [<ffffffff81097676>] cpu_startup_entry+0x2c6/0x330
        [<ffffffff8103b7ad>] start_secondary+0x21d/0x290
      irq event stamp: 2997
      hardirqs last  enabled at (2997): [<ffffffff81491865>] _raw_spin_unlo=
ck_irqrestore+0x65/0x90
      hardirqs last disabled at (2996): [<ffffffff814915e6>] _raw_spin_lock=
_irqsave+0x26/0x90
      softirqs last  enabled at (2968): [<ffffffff813b57a3>] dev_deactivate=
_many+0x213/0x260
      softirqs last disabled at (2966): [<ffffffff813b5783>] dev_deactivate=
_many+0x1f3/0x260
     =20
      other info that might help us debug this:
       Possible unsafe locking scenario:
     =20
             CPU0
             ----
        lock(&(&enic->rfs_h.lock)->rlock);
        <Interrupt>
          lock(&(&enic->rfs_h.lock)->rlock);
     =20
       *** DEADLOCK ***
     =20
      Reported-by: Jan Stancek <jstancek@redhat.com>
      Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d10845fc85b2e690b5f6425c5ba4df33a073fbc9
  Merge: ce8ec48 f993bc2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 20 12:38:19 2014 -0400
 =20
      Merge branch 'gso_encap_fixes'
     =20
      Florian Westphal says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      net: minor gso encapsulation fixes
     =20
      The following series fixes a minor bug in the gso segmentation handle=
rs
      when encapsulation offload is used.
     =20
      Theoretically this could cause kernel panic when the stack tries
      to software-segment such a GRE offload packet, but it looks like ther=
e
      is only one affected call site (tbf scheduler) and it handles NULL
      return value.
     =20
      I've included a followup patch to add IS_ERR_OR_NULL checks where nee=
ded.
     =20
      While looking into this, I also found that size computation of the in=
dividual
      segments is incorrect if skb->encapsulation is set.
     =20
      Please see individual patches for delta vs. v1.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f993bc25e5196e60514c216d0bca0f600de64af8
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:18 2014 +0200
 =20
      net: core: handle encapsulation offloads when computing segment lengt=
hs
     =20
      if ->encapsulation is set we have to use inner_tcp_hdrlen and add the
      size of the inner network headers too.
     =20
      This is 'mostly harmless'; tbf might send skb that is slightly over
      quota or drop skb even if it would have fit.
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 330966e501ffe282d7184fde4518d5e0c24bc7f8
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:17 2014 +0200
 =20
      net: make skb_gso_segment error handling more robust
     =20
      skb_gso_segment has three possible return values:
      1. a pointer to the first segmented skb
      2. an errno value (IS_ERR())
      3. NULL.  This can happen when GSO is used for header verification.
     =20
      However, several callers currently test IS_ERR instead of IS_ERR_OR_N=
ULL
      and would oops when NULL is returned.
     =20
      Note that these call sites should never actually see such a NULL retu=
rn
      value; all callers mask out the GSO bits in the feature argument.
     =20
      However, there have been issues with some protocol handlers erronousl=
y not
      respecting the specified feature mask in some cases.
     =20
      It is preferable to get 'have to turn off hw offloading, else slow' r=
eports
      rather than 'kernel crashes'.
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e16aa3ddf863c6b9f37eddf52503230a62dedb3
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:16 2014 +0200
 =20
      net: gso: use feature flag argument in all protocol gso handlers
     =20
      skb_gso_segment() has a 'features' argument representing offload feat=
ures
      available to the output path.
     =20
      A few handlers, e.g. GRE, instead re-fetch the features of skb->dev a=
nd use
      those instead of the provided ones when handing encapsulation/tunnels=
.
     =20
      Depending on dev->hw_enc_features of the output device skb_gso_segmen=
t() can
      then return NULL even when the caller has disabled all GSO feature bi=
ts,
      as segmentation of inner header thinks device will take care of segme=
ntation.
     =20
      This e.g. affects the tbf scheduler, which will silently drop GRE-enc=
ap GSO skbs
      that did not fit the remaining token quota as the segmentation does n=
ot work
      when device supports corresponding hw offload capabilities.
     =20
      Cc: Pravin B Shelar <pshelar@nicira.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ce8ec4896749783bd6cdc457e6012cfc18e09c8b
  Merge: 95ff886 1e2d56a
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 20 11:57:47 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      netfilter fixes for net
     =20
      The following patchset contains netfilter fixes for your net tree,
      they are:
     =20
      1) Fix missing MODULE_LICENSE() in the new nf_reject_ipv{4,6} modules=
.
     =20
      2) Restrict nat and masq expressions to the nat chain type. Otherwise=
,
         users may crash their kernel if they attach a nat/masq rule to a n=
on
         nat chain.
     =20
      3) Fix hook validation in nft_compat when non-base chains are used.
         Basically, initialize hook_mask to zero.
     =20
      4) Make sure you use match/targets in nft_compat from the right chain
         type. The existing validation relies on the table name which can b=
e
         avoided by
     =20
      5) Better netlink attribute validation in nft_nat. This expression ha=
s
         to reject the configuration when no address and proto configuratio=
ns
         are specified.
     =20
      6) Interpret NFTA_NAT_REG_*_MAX if only if NFTA_NAT_REG_*_MIN is set.
         Yet another sanity check to reject incorrect configurations from
         userspace.
     =20
      7) Conditional NAT attribute dumping depending on the existing
         configuration.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 11b2357d5dbce999803e9055f8c09829a8a87db4
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Mon Oct 20 10:54:36 2014 +0200
 =20
      mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats
     =20
      ATM an HT rc_stats line is 106 chars.
      Times 8(MCS_GROUP_RATES)*3(SS)*2(GI)*2(BW) + CCK(4), i.e. x100, this =
is
      well above the current 8192 - sizeof(*ms) currently allocated.
     =20
      Fix this by squeezing the output as follows (not that we're short on
      memory but this also improves readability and range, the new format a=
dds
      one more digit to *ok/*cum and ok/cum):
     =20
      - Before (HT) (106 ch):
      type           rate     throughput  ewma prob   this prob  retry   th=
is succ/attempt   success    attempts
      CCK/LP          5.5M           0.0        0.0         0.0      0     =
         0(  0)         0           0
      HT20/LGI ABCDP MCS0            0.0        0.0         0.0      1     =
         0(  0)         0           0
      - After (75 ch):
      type           rate     tpt eprob *prob ret  *ok(*cum)        ok(    =
  cum)
      CCK/LP          5.5M    0.0   0.0   0.0   0    0(   0)         0(    =
    0)
      HT20/LGI ABCDP MCS0     0.0   0.0   0.0   1    0(   0)         0(    =
    0)
     =20
      - Align non-HT format Before (non-HT) (83 ch):
      rate      throughput  ewma prob  this prob  this succ/attempt   succe=
ss    attempts
      ABCDP  6         0.0        0.0        0.0             0(  0)        =
 0           0
            54         0.0        0.0        0.0             0(  0)        =
 0           0
      - After (61 ch):
      rate          tpt eprob *prob  *ok(*cum)        ok(      cum)
      ABCDP  1      0.0   0.0   0.0    0(   0)         0(        0)
            54      0.0   0.0   0.0    0(   0)         0(        0)
     =20
      *This also adds dynamic checks for overflow, lowers the size of the
      non-HT request (allowing > 30 entries) and replaces the buddy-rounded
      allocations (s/sizeof(*ms) + 8192/8192).
     =20
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Acked-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 95ff88688781db2f64042e69bd499e518bbb36e5
  Author: Ian Morgan <imorgan@primordial.ca>
  Date:   Sun Oct 19 08:05:13 2014 -0400
 =20
      ax88179_178a: fix bonding failure
     =20
      The following patch fixes a bug which causes the ax88179_178a driver =
to be
      incapable of being added to a bond.
     =20
      When I brought up the issue with the bonding maintainers, they indica=
ted
      that the real problem was with the NIC driver which must return zero =
for
      success (of setting the MAC address). I see that several other NIC dr=
ivers
      follow that pattern by either simply always returing zero, or by pass=
ing
      through a negative (error) result while rewriting any positive return=
 code
      to zero. With that same philisophy applied to the ax88179_178a driver=
, it
      allows it to work correctly with the bonding driver.
     =20
      I believe this is suitable for queuing in -stable, as it's a small, s=
imple,
      and obvious fix that corrects a defect with no other known workaround=
.
     =20
      This patch is against vanilla 3.17(.0).
     =20
      Signed-off-by: Ian Morgan <imorgan@primordial.ca>
     =20
       drivers/net/usb/ax88179_178a.c |    7 ++++++-
       1 file changed, 6 insertions(+), 1 deletion(-)
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e2d56a5d33a7e1fcd21ed3859f52596d02708b0
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:24:14 2014 +0200
 =20
      netfilter: nft_nat: dump attributes if they are set
     =20
      Dump NFTA_NAT_REG_ADDR_MIN if this is non-zero. Same thing with
      NFTA_NAT_REG_PROTO_MIN.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 61cfac6b42af98ab46bcb3a47e150e7b20d5015e
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:19:35 2014 +0200
 =20
      netfilter: nft_nat: NFTA_NAT_REG_ADDR_MAX depends on NFTA_NAT_REG_ADD=
R_MIN
     =20
      Interpret NFTA_NAT_REG_ADDR_MAX if NFTA_NAT_REG_ADDR_MIN is present,
      otherwise, skip it. Same thing with NFTA_NAT_REG_PROTO_MAX.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 5c819a39753d6a3ae9c0092236f59730a369b619
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:16:57 2014 +0200
 =20
      netfilter: nft_nat: insufficient attribute validation
     =20
      We have to validate that we at least get an NFTA_NAT_REG_ADDR_MIN or
      NFTA_NFT_REG_PROTO_MIN attribute. Reject the configuration if none
      of them are present.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit f3f5ddeddd6aeadcef523d55ea9288e3d5c1cbc3
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Tue Oct 14 10:13:48 2014 +0200
 =20
      netfilter: nft_compat: validate chain type in match/target
     =20
      We have to validate the real chain type to ensure that matches/target=
s
      are not used out from their scope (eg. MASQUERADE in nat chain type).
      The existing validation relies on the table name, but this is not
      sufficient since userspace can fool us by using the appropriate table
      name with a different chain type.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 493618a92c6afdd3f6224ab586f169d6a259bb06
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Tue Oct 14 12:43:50 2014 +0200
 =20
      netfilter: nft_compat: fix hook validation for non-base chains
     =20
      Set hook_mask to zero for non-base chains, otherwise people may hit
      bogus errors from the xt_check_target() and xt_check_match() when
      validating the uninitialized hook_mask.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit c7abf25af0f41be4b50d44c5b185d52eea360cb8
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Mon Oct 13 14:34:41 2014 +0200
 =20
      mac80211: fix typo in starting baserate for rts_cts_rate_idx
     =20
      It affects non-(V)HT rates and can lead to selecting an rts_cts rate
      that is not a basic rate or way superior to the reference rate (ATM
      rates[0] used for the 1st attempt of the protected frame data).
     =20
      E.g, assuming drivers register growing (bitrate) sorted tables of
      ieee80211_rate-s, having :
      - rates[0].idx =3D=3D d'2 and basic_rates =3D=3D b'10100
      will select rts_cts idx b'10011 & ~d'(BIT(2)-1), i.e. 1, likewise
      - rates[0].idx =3D=3D d'2 and basic_rates =3D=3D b'10001
      will select rts_cts idx b'10000
      The first is not a basic rate and the second is > rates[0].
     =20
      Also, wrt severity of the addressed misbehavior, ATM we only have one
      rts_cts_rate_idx rather than one per rate table entry, so this idx mi=
ght
      still point to bitrates > rates[1..MAX_RATES].
     =20
      Fixes: 5253ffb8c9e1 ("mac80211: always pick a basic rate to tx RTS/CT=
S for pre-HT rates")
      Cc: stable@vger.kernel.org
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 7210e4e38f945dfa173c4a4e59ad827c9ecad541
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Mon Oct 13 19:50:22 2014 +0200
 =20
      netfilter: nf_tables: restrict nat/masq expressions to nat chain type
     =20
      This adds the missing validation code to avoid the use of nat/masq fr=
om
      non-nat chains. The validation assumes two possible configuration
      scenarios:
     =20
      1) Use of nat from base chain that is not of nat type. Reject this
         configuration from the nft_*_init() path of the expression.
     =20
      2) Use of nat from non-base chain. In this case, we have to wait unti=
l
         the non-base chain is referenced by at least one base chain via
         jump/goto. This is resolved from the nft_*_validate() path which i=
s
         called from nf_tables_check_loops().
     =20
      The user gets an -EOPNOTSUPP in both cases.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit ab2d7251d666995740da17b2a51ca545ac5dd037
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Fri Oct 10 11:25:20 2014 +0200
 =20
      netfilter: missing module license in the nf_reject_ipvX modules
     =20
      [   23.545204] nf_reject_ipv4: module license 'unspecified' taints ke=
rnel.
     =20
      Fixes: c8d7b98 ("netfilter: move nf_send_resetX() code to nf_reject_i=
pvX modules")
      Reported-by: Dave Young <dyoung@redhat.com>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 252e07ca5f64dd31fdfca8027287e7d75fefdab1
  Author: Luciano Coelho <luciano.coelho@intel.com>
  Date:   Wed Oct 8 09:48:34 2014 +0300
 =20
      nl80211: sanity check the channel switch counter value
     =20
      The nl80211 channel switch count attribute
      (NL80211_ATTR_CH_SWITCH_COUNT) is specified as u32, but the
      specification uses u8 for the counter.  To make sure strange things
      don't happen without informing the user, sanity check the value and
      return -EINVAL if it doesn't fit in u8.
     =20
      Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit bc37b16870a382e8b71d881444c19a16de1c1a7f
  Author: Fabian Frederick <fabf@skynet.be>
  Date:   Tue Oct 7 22:20:23 2014 +0200
 =20
      net: rfkill: kernel-doc warning fixes
     =20
      Correct the kernel-doc, the parameter is called "blocked" not "state"=
.
     =20
      Signed-off-by: Fabian Frederick <fabf@skynet.be>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit c12bc4885f4b3bab0ed779c69d5d7e3223fa5003
  Author: Luciano Coelho <luciano.coelho@intel.com>
  Date:   Tue Sep 30 07:08:02 2014 +0300
 =20
      mac80211: return the vif's chandef in ieee80211_cfg_get_channel()
     =20
      The chandef of the channel context a vif is using may be different
      than the chandef of the vif itself.  For instance, the bandwidth used
      by the vif may be narrower than the one configured in the channel
      context.  To avoid confusion, return the vif's chandef in
      ieee80211_cfg_get_channel() instead of the chandef of the channel
      context.
     =20
      Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 8975ae88e137ea02a71b7a86af2f8eb790c2f1e7
  Author: Liad Kaufman <liad.kaufman@intel.com>
  Date:   Sun Sep 14 21:48:28 2014 +0300
 =20
      mac80211: fix warning on htmldocs for last_tdls_pkt_time
     =20
      Forgot to add an entry to the struct description of sta_info.
     =20
      Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
      Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.linux-linus.t=
est-amd64-i386-rumpuserxen-i386.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31352 fail [host=3Dbush-cricket] / 31282 [host=3Dworm-moth] 31266 ok.
Failure / basis pass flights: 31352 / 31266
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.=
6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: rumpuserxen git://xenbits.xen.org/rumpuser-xen.git
Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.gi=
t
Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd
Tree: xen git://xenbits.xen.org/xen.git
Latest 0df1f2487d2f0d04703f142813d53615d62a1da4 c530a75c1e6a472b0eb9558310b=
518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24=
baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb61896d1f6=
8884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0f2bde=
078ace619fe8e26730495b6ef2c3a2e9bf
Basis pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb9558=
310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d=
7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 94c092b90=
6e348acd512744536d28e4f06e4c1ef 3687f55f417008a1fcdc04195644009232ae609d 66=
88825c240586708129df8887ad9b12a1708497
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/=
pub/scm/linux/kernel/git/torvalds/linux-2.6.git#a7ca10f263d7e673c74d8e0946d=
6b9993405cc9c-0df1f2487d2f0d04703f142813d53615d62a1da4 git://xenbits.xen.or=
g/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a=
75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-=
unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b=
3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.gi=
t#ca78cc83650b535d7e24baeaea32947be0141534-ca78cc83650b535d7e24baeaea32947b=
e0141534 git://xenbits.xen.org/rumpuser-xen.git#2ee4e55123b64feb79d8c824668=
a86e717ba47f8-ccc8df17b7e7e785e28bee8ae90d0f00f93208ca https://github.com/r=
umpkernel/buildrump.sh.git#94c092b906e348acd512744536d28e4f06e4c1ef-e8eb618=
96d1f68884b9c39b61e7e1ddb41e90c0b https://github.com/rumpkernel/src-netbsd#=
3687f55f417008a1fcdc04195644009232ae609d-3687f55f417008a1fcdc04195644009232=
ae609d git://xenbits.xen.org/xen.git#6688825c240586708129df8887ad9b12a17084=
97-0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.ker=
nel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/rumpuser-xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits=
.xen.org/rumpuser-xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/buildrump.sh
+ git remote set-url origin git://drall.uk.xensource.com:9419/https://githu=
b.com/rumpkernel/buildrump.sh.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits=
.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
>From git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen
   816f5bb..5a430ec  staging    -> origin/staging
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.ker=
nel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/rumpuser-xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits=
.xen.org/rumpuser-xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/buildrump.sh
+ git remote set-url origin git://drall.uk.xensource.com:9419/https://githu=
b.com/rumpkernel/buildrump.sh.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits=
.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Use of uninitialized value $parents in array dereference at ./adhoc-revtupl=
e-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtup=
le-generator line 461.
Loaded 123760 nodes in revision graph
Searching for test results:
 31266 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 94c092b9=
06e348acd512744536d28e4f06e4c1ef 3687f55f417008a1fcdc04195644009232ae609d 6=
688825c240586708129df8887ad9b12a1708497
 31282 [host=3Dworm-moth]
 31334 fail 12d7aacab56e9ef185c3a5512e867bfd3a9504e4 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31352 fail 0df1f2487d2f0d04703f142813d53615d62a1da4 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31416 pass 53429290a054b30e4683297409fc4627b2592315 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31401 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 94c092b9=
06e348acd512744536d28e4f06e4c1ef 3687f55f417008a1fcdc04195644009232ae609d 6=
688825c240586708129df8887ad9b12a1708497
 31418 fail 89453379aaf0608253124057df6cd8ac63948135 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31402 fail 0df1f2487d2f0d04703f142813d53615d62a1da4 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31420 pass 53429290a054b30e4683297409fc4627b2592315 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31404 pass 3a2f22b7d0cc64482a91529e23c2570aa0602fa6 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2d0d163ae7cdabe002fd8a4ba441d9e7eb731fcf e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31421 fail 89453379aaf0608253124057df6cd8ac63948135 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31405 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 06ca11260277a9099a5ebeb04669fa0abf694106 e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31407 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 af976539=
24fa6f230f517d2efa850fd3c366054f 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31408 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 05c06de5=
24743a92d1d7b610dc9b4e23421f5e54 3687f55f417008a1fcdc04195644009232ae609d 9=
12054bbbc5914174b6f90c6bcd0a5c4f370bdbe
 31422 pass 53429290a054b30e4683297409fc4627b2592315 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31410 pass a7ca10f263d7e673c74d8e0946d6b9993405cc9c c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 2ee4e55123b64feb79d8c824668a86e717ba47f8 a55697c8=
28687a7ff09b1fc93a42b73685368717 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31412 pass f5fa363026c3508735c6ab2f1029110d2c4966a2 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31424 fail 89453379aaf0608253124057df6cd8ac63948135 c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
 31414 fail 32e8fd2f8eac3262e7000d9a219d70ace10e0adf c530a75c1e6a472b0eb955=
8310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535=
d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb6189=
6d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae609d 0=
f2bde078ace619fe8e26730495b6ef2c3a2e9bf
Searching for interesting versions
 Result found: flight 31266 (pass), for basis pass
 Result found: flight 31352 (fail), for basis failure
 Repro found: flight 31401 (pass), for basis pass
 Repro found: flight 31402 (fail), for basis failure
 0 revisions at 53429290a054b30e4683297409fc4627b2592315 c530a75c1e6a472b0e=
b9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650=
b535d7e24baeaea32947be0141534 ccc8df17b7e7e785e28bee8ae90d0f00f93208ca e8eb=
61896d1f68884b9c39b61e7e1ddb41e90c0b 3687f55f417008a1fcdc04195644009232ae60=
9d 0f2bde078ace619fe8e26730495b6ef2c3a2e9bf
No revisions left to test, checking graph state.
 Result found: flight 31416 (pass), for last pass
 Result found: flight 31418 (fail), for first failure
 Repro found: flight 31420 (pass), for last pass
 Repro found: flight 31421 (fail), for first failure
 Repro found: flight 31422 (pass), for last pass
 Repro found: flight 31424 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torv=
alds/linux-2.6.git
  Bug introduced:  89453379aaf0608253124057df6cd8ac63948135
  Bug not present: 53429290a054b30e4683297409fc4627b2592315

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.ker=
nel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 89453379aaf0608253124057df6cd8ac63948135
  Merge: 5342929 99a49ce
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Oct 31 15:04:58 2014 -0700
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
     =20
      Pull networking fixes from David Miller:
       "A bit has accumulated, but it's been a week or so since my last bat=
ch
        of post-merge-window fixes, so...
     =20
         1) Missing module license in netfilter reject module, from Pablo.
            Lots of people ran into this.
     =20
         2) Off by one in mac80211 baserate calculation, from Karl Beldan.
     =20
         3) Fix incorrect return value from ax88179_178a driver's set_mac_a=
ddr
            op, which broke use of it with bonding.  From Ian Morgan.
     =20
         4) Checking of skb_gso_segment()'s return value was not all
            encompassing, it can return an SKB pointer, a pointer error, or
            NULL.  Fix from Florian Westphal.
     =20
            This is crummy, and longer term will be fixed to just return er=
ror
            pointers or a real SKB.
     =20
         6) Encapsulation offloads not being handled by
            skb_gso_transport_seglen().  From Florian Westphal.
     =20
         7) Fix deadlock in TIPC stack, from Ying Xue.
     =20
         8) Fix performance regression from using rhashtable for netlink
            sockets.  The problem was the synchronize_net() invoked for eve=
ry
            socket destroy.  From Thomas Graf.
     =20
         9) Fix bug in eBPF verifier, and remove the strong dependency of B=
PF
            on NET.  From Alexei Starovoitov.
     =20
        10) In qdisc_create(), use the correct interface to allocate
            ->cpu_bstats, otherwise the u64_stats_sync member isn't
            initialized properly.  From Sabrina Dubroca.
     =20
        11) Off by one in ip_set_nfnl_get_byindex(), from Dan Carpenter.
     =20
        12) nf_tables_newchain() was erroneously expecting error pointers f=
rom
            netdev_alloc_pcpu_stats().  It only returna a valid pointer or
            NULL.  From Sabrina Dubroca.
     =20
        13) Fix use-after-free in _decode_session6(), from Li RongQing.
     =20
        14) When we set the TX flow hash on a socket, we mistakenly do so
            before we've nailed down the final source port.  Move the setti=
ng
            deeper to fix this.  From Sathya Perla.
     =20
        15) NAPI budget accounting in amd-xgbe driver was counting descript=
ors
            instead of full packets, fix from Thomas Lendacky.
     =20
        16) Fix total_data_buflen calculation in hyperv driver, from Haiyan=
g
            Zhang.
     =20
        17) Fix bcma driver build with OF_ADDRESS disabled, from Hauke
            Mehrtens.
     =20
        18) Fix mis-use of per-cpu memory in TCP md5 code.  The problem is
            that something that ends up being vmalloc memory can't be passe=
d
            to the crypto hash routines via scatter-gather lists.  From Eri=
c
            Dumazet.
     =20
        19) Fix regression in promiscuous mode enabling in cdc-ether, from
            Olivier Blin.
     =20
        20) Bucket eviction and frag entry killing can race with eachother,
            causing an unlink of the object from the wrong list.  Fix from
            Nikolay Aleksandrov.
     =20
        21) Missing initialization of spinlock in cxgb4 driver, from Anish
            Bhatt.
     =20
        22) Do not cache ipv4 routing failures, otherwise if the sysctl for
            forwarding is subsequently enabled this won't be seen.  From
            Nicolas Cavallari"
     =20
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (131 commi=
ts)
        drivers: net: cpsw: Support ALLMULTI and fix IFF_PROMISC in switch =
mode
        drivers: net: cpsw: Fix broken loop condition in switch mode
        net: ethtool: Return -EOPNOTSUPP if user space tries to read EEPROM=
 with lengh 0
        stmmac: pci: set default of the filter bins
        net: smc91x: Fix gpios for device tree based booting
        mpls: Allow mpls_gso to be built as module
        mpls: Fix mpls_gso handler.
        r8152: stop submitting intr for -EPROTO
        netfilter: nft_reject_bridge: restrict reject to prerouting and inp=
ut
        netfilter: nft_reject_bridge: don't use IP stack to reject traffic
        netfilter: nf_reject_ipv6: split nf_send_reset6() in smaller functi=
ons
        netfilter: nf_reject_ipv4: split nf_send_reset() in smaller functio=
ns
        netfilter: nf_tables_bridge: update hook_mask to allow {pre,post}ro=
uting
        drivers/net: macvtap and tun depend on INET
        drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packe=
ts
        drivers/net: Disable UFO through virtio
        net: skb_fclone_busy() needs to detect orphaned skb
        gre: Use inner mac length when computing tunnel length
        mlx4: Avoid leaking steering rules on flow creation error flow
        net/mlx4_en: Don't attempt to TX offload the outer UDP checksum for=
 VXLAN
        ...
 =20
  commit 99a49ce613057f1934e1c378808374fd683b1541
  Merge: 1e5c4bc 75a916e
  Author: David S. Miller <davem@davemloft.net>
  Date:   Fri Oct 31 16:18:35 2014 -0400
 =20
      Merge tag 'master-2014-10-30' of git://git.kernel.org/pub/scm/linux/k=
ernel/git/linville/wireless
     =20
      John W. Linville says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      pull request: wireless 2014-10-31
     =20
      Please pull this small batch of spooky fixes intended for the 3.18
      stream...boo!
     =20
      Cyril Brulebois adds an rt2x00 device ID.
     =20
      Dan Carpenter provides a one-line masking fix for an ath9k debugfs
      entry.
     =20
      Larry Finger gives us a package of small rtlwifi fixes which add some
      bits that were left out of some feature updates that were included
      in the merge window.  Hopefully this isn't a sign that the rtlwifi
      base is getting too big...
     =20
      Marc Yang brings a fix for a temporary mwifiex stall when doing 11n
      RX reordering.
     =20
      Please let me know if there are problems!
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e5c4bc497c0a96e1ad2974539d353870f2cb0b6
  Author: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  Date:   Fri Oct 31 13:38:52 2014 -0400
 =20
      drivers: net: cpsw: Support ALLMULTI and fix IFF_PROMISC in switch mo=
de
     =20
      The cpsw driver did not support the IFF_ALLMULTI flag which makes dyn=
amic
      multicast routing not work.  Related to this, when enabling IFF_PROMI=
SC
      in switch mode, all registered multicast addresses are flushed, resul=
ting
      in only broadcast and unicast traffic being received.
     =20
      A new cpsw_ale_set_allmulti function now scans through the ALE entry
      table and adds/removes the host port from the unregistered multicast
      port mask of each vlan entry depending on the state of IFF_ALLMULTI.
      In promiscious mode, cpsw_ale_set_allmulti is used to force reception
      of all multicast traffic in addition to the unicast and broadcast tra=
ffic.
     =20
      With this change dynamic multicast and promiscious mode both work in
      switch mode.
     =20
      Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 6f979eb3fcfb4c3f42f230d174db4bbad0080710
  Author: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
  Date:   Fri Oct 31 13:28:54 2014 -0400
 =20
      drivers: net: cpsw: Fix broken loop condition in switch mode
     =20
      0d961b3b52f566f823070ce2366511a7f64b928c (drivers: net: cpsw: fix bug=
gy
      loop condition) accidentally fixed a loop comparison in too many plac=
es
      while fixing a real bug.
     =20
      It was correct to fix the dual_emac mode section since there 'i' is u=
sed
      as an index into priv->slaves which is a 0 based array.
     =20
      However the other two changes (which are only used in switch mode)
      are wrong since there 'i' is actually the ALE port number, and port 0
      is the host port, while port 1 and up are the slave ports.
     =20
      Putting the loop condition back in the switch mode section fixes it.
     =20
      A comment has been added to point out the intent clearly to avoid fut=
ure
      confusion.  Also a comment is fixed that said the opposite of what wa=
s
      actually happening.
     =20
      Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
      Acked-by: Heiko Schocher <hs@denx.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e0fb6fb6d52686134b2ece144060219591d4f8d3
  Author: Guenter Roeck <linux@roeck-us.net>
  Date:   Thu Oct 30 20:50:15 2014 -0700
 =20
      net: ethtool: Return -EOPNOTSUPP if user space tries to read EEPROM w=
ith lengh 0
     =20
      If a driver supports reading EEPROM but no EEPROM is installed in the=
 system,
      the driver's get_eeprom_len function returns 0. ethtool will subseque=
ntly
      try to read that zero-length EEPROM anyway. If the driver does not su=
pport
      EEPROM access at all, this operation will return -EOPNOTSUPP. If the =
driver
      does support EEPROM access but no EEPROM is installed, the operation =
will
      return -EINVAL. Return -EOPNOTSUPP in both cases for consistency.
     =20
      Signed-off-by: Guenter Roeck <linux@roeck-us.net>
      Tested-by: Andrew Lunn <andrew@lunn.ch>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e19e084eae727654052339757ab7f1eaff58bad
  Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Date:   Fri Oct 31 18:28:03 2014 +0200
 =20
      stmmac: pci: set default of the filter bins
     =20
      The commit 3b57de958e2a brought the support for a different amount of=
 the
      filter bins, but didn't update the PCI driver accordingly. This patch=
 appends
      the default values when the device is enumerated via PCI bus.
     =20
      Fixes: 3b57de958e2a (net: stmmac: Support devicetree configs for mcas=
t and ucast filter entries)
      Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7d2911c4381555b31ef0bcae42a0dbf9ade7426e
  Author: Tony Lindgren <tony@atomide.com>
  Date:   Thu Oct 30 09:59:27 2014 -0700
 =20
      net: smc91x: Fix gpios for device tree based booting
     =20
      With legacy booting, the platform init code was taking care of
      the configuring of GPIOs. With device tree based booting, things
      may or may not work depending what bootloader has configured or
      if the legacy platform code gets called.
     =20
      Let's add support for the pwrdn and reset GPIOs to the smc91x
      driver to fix the issues of smc91x not working properly when
      booted in device tree mode.
     =20
      And let's change n900 to use these settings as some versions
      of the bootloader do not configure things properly causing
      errors.
     =20
      Reported-by: Kevin Hilman <khilman@linaro.org>
      Signed-off-by: Tony Lindgren <tony@atomide.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit de05c400f7dfa566f598140f8604a5de8067cd5f
  Author: Pravin B Shelar <pshelar@nicira.com>
  Date:   Thu Oct 30 00:50:04 2014 -0700
 =20
      mpls: Allow mpls_gso to be built as module
     =20
      Kconfig already allows mpls to be built as module. Following patch
      fixes Makefile to do same.
     =20
      CC: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
      Acked-by: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f7065f4bd3fe4ad6bf7e49ba7c68baa2c7046146
  Author: Pravin B Shelar <pshelar@nicira.com>
  Date:   Thu Oct 30 00:49:57 2014 -0700
 =20
      mpls: Fix mpls_gso handler.
     =20
      mpls gso handler needs to pull skb after segmenting skb.
     =20
      CC: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
      Acked-by: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d59c876dd61f3c151db077f9d73774e605f2b35e
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Fri Oct 31 13:35:57 2014 +0800
 =20
      r8152: stop submitting intr for -EPROTO
     =20
      For Renesas USB 3.0 host controller, when unplugging the usb hub whic=
h
      has the RTL8153 plugged, the driver would get -EPROTO for interrupt
      transfer. There is high probability to get the information of "HC die=
d;
      cleaning up", if the driver continues to submit the interrupt transfe=
r
      before the disconnect() is called.
     =20
      [ 1024.197678] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.213673] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.229668] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.245661] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.261653] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.277648] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.293642] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.309638] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.325633] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.341627] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.357621] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.373615] r8152 9-1.4:1.0 eth0: intr status -71
      [ 1024.383097] usb 9-1: USB disconnect, device number 2
      [ 1024.383103] usb 9-1.4: USB disconnect, device number 6
      [ 1029.391010] xhci_hcd 0000:04:00.0: xHCI host not responding to sto=
p endpoint command.
      [ 1029.391016] xhci_hcd 0000:04:00.0: Assuming host is dying, halting=
 host.
      [ 1029.392551] xhci_hcd 0000:04:00.0: HC died; cleaning up
      [ 1029.421480] usb 8-1: USB disconnect, device number 2
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e3a88f9c4f79a4d138a0ea464cfbac40ba46644c
  Merge: de11b0e 127917c
  Author: David S. Miller <davem@davemloft.net>
  Date:   Fri Oct 31 12:29:42 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      netfilter/ipvs fixes for net
     =20
      The following patchset contains fixes for netfilter/ipvs. This round =
of
      fixes is larger than usual at this stage, specifically because of the
      nf_tables bridge reject fixes that I would like to see in 3.18. The
      patches are:
     =20
      1) Fix a null-pointer dereference that may occur when logging
         errors. This problem was introduced by 4a4739d56b0 ("ipvs: Pull
         out crosses_local_route_boundary logic") in v3.17-rc5.
     =20
      2) Update hook mask in nft_reject_bridge so we can also filter out
         packets from there. This fixes 36d2af5 ("netfilter: nf_tables: all=
ow
         to filter from prerouting and postrouting"), which needs this chun=
k
         to work.
     =20
      3) Two patches to refactor common code to forge the IPv4 and IPv6
         reject packets from the bridge. These are required by the nf_table=
s
         reject bridge fix.
     =20
      4) Fix nft_reject_bridge by avoiding the use of the IP stack to rejec=
t
         packets from the bridge. The idea is to forge the reject packets a=
nd
         inject them to the original port via br_deliver() which is now
         exported for that purpose.
     =20
      5) Restrict nft_reject_bridge to bridge prerouting and input hooks.
         the original skbuff may cloned after prerouting when the bridge st=
ack
         needs to flood it to several bridge ports, it is too late to rejec=
t
         the traffic.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 127917c29a432c3b798e014a1714e9c1af0f87fe
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Mon Oct 27 14:08:17 2014 +0100
 =20
      netfilter: nft_reject_bridge: restrict reject to prerouting and input
     =20
      Restrict the reject expression to the prerouting and input bridge
      hooks. If we allow this to be used from forward or any other later
      bridge hook, if the frame is flooded to several ports, we'll end up
      sending several reject packets, one per cloned packet.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 523b929d5446c023e1219aa81455a8c766cac883
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 18:40:26 2014 +0200
 =20
      netfilter: nft_reject_bridge: don't use IP stack to reject traffic
     =20
      If the packet is received via the bridge stack, this cannot reject
      packets from the IP stack.
     =20
      This adds functions to build the reject packet and send it from the
      bridge stack. Comments and assumptions on this patch:
     =20
      1) Validate the IPv4 and IPv6 headers before further processing,
         given that the packet comes from the bridge stack, we cannot assum=
e
         they are clean. Truncated packets are dropped, we follow similar
         approach in the existing iptables match/target extensions that nee=
d
         to inspect layer 4 headers that is not available. This also includ=
es
         packets that are directed to multicast and broadcast ethernet
         addresses.
     =20
      2) br_deliver() is exported to inject the reject packet via
         bridge localout -> postrouting. So the approach is similar to what
         we already do in the iptables reject target. The reject packet is
         sent to the bridge port from which we have received the original
         packet.
     =20
      3) The reject packet is forged based on the original packet. The TTL
         is set based on sysctl_ip_default_ttl for IPv4 and per-net
         ipv6.devconf_all hoplimit for IPv6.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 8bfcdf6671b1c8006c52c3eaf9fd1b5dfcf41c3d
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sun Oct 26 12:35:54 2014 +0100
 =20
      netfilter: nf_reject_ipv6: split nf_send_reset6() in smaller function=
s
     =20
      That can be reused by the reject bridge expression to build the rejec=
t
      packet. The new functions are:
     =20
      * nf_reject_ip6_tcphdr_get(): to sanitize and to obtain the TCP heade=
r.
      * nf_reject_ip6hdr_put(): to build the IPv6 header.
      * nf_reject_ip6_tcphdr_put(): to build the TCP header.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 052b9498eea532deb5de75277a53f6e0623215dc
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 18:24:57 2014 +0200
 =20
      netfilter: nf_reject_ipv4: split nf_send_reset() in smaller functions
     =20
      That can be reused by the reject bridge expression to build the rejec=
t
      packet. The new functions are:
     =20
      * nf_reject_ip_tcphdr_get(): to sanitize and to obtain the TCP header=
.
      * nf_reject_iphdr_put(): to build the IPv4 header.
      * nf_reject_ip_tcphdr_put(): to build the TCP header.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 4d87716cd057bde3f90e304289c1fec88d45a1cc
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Sat Oct 25 12:25:06 2014 +0200
 =20
      netfilter: nf_tables_bridge: update hook_mask to allow {pre,post}rout=
ing
     =20
      Fixes: 36d2af5 ("netfilter: nf_tables: allow to filter from preroutin=
g and postrouting")
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit de11b0e8c569b96c2cf6a811e3805b7aeef498a3
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Fri Oct 31 03:10:31 2014 +0000
 =20
      drivers/net: macvtap and tun depend on INET
     =20
      These drivers now call ipv6_proxy_select_ident(), which is defined
      only if CONFIG_INET is enabled.  However, they have really depended
      on CONFIG_INET for as long as they have allowed sending GSO packets
      from userland.
     =20
      Reported-by: kbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
      Fixes: b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
      Fixes: 5188cd44c55d ("drivers/net, ipv6: Select IPv6 fragment idents =
for virtio UFO packets")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c1304b217c7cefa5718fab9d36c59ba0d0133c6e
  Merge: 39bb5e6 5188cd4
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 20:01:27 2014 -0400
 =20
      Merge branch 'ufo-fix'
     =20
      Ben Hutchings says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      drivers/net,ipv6: Fix IPv6 fragment ID selection for virtio
     =20
      The virtio net protocol supports UFO but does not provide for passing=
 a
      fragment ID for fragmentation of IPv6 packets.  We used to generate a
      fragment ID wherever such a packet was fragmented, but currently we
      always use ID=3D0!
     =20
      v2: Add blank lines after declarations
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Thu Oct 30 18:27:17 2014 +0000
 =20
      drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets
     =20
      UFO is now disabled on all drivers that work with virtio net headers,
      but userland may try to send UFO/IPv6 packets anyway.  Instead of
      sending with ID=3D0, we should select identifiers on their behalf (as=
 we
      used to).
     =20
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_dat=
a")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
  Author: Ben Hutchings <ben@decadent.org.uk>
  Date:   Thu Oct 30 18:27:12 2014 +0000
 =20
      drivers/net: Disable UFO through virtio
     =20
      IPv6 does not allow fragmentation by routers, so there is no
      fragmentation ID in the fixed header.  UFO for IPv6 requires the ID t=
o
      be passed separately, but there is no provision for this in the virti=
o
      net protocol.
     =20
      Until recently our software implementation of UFO/IPv6 generated a ne=
w
      ID, but this was a bug.  Now we will use ID=3D0 for any UFO/IPv6 pack=
et
      passed through a tap, which is even worse.
     =20
      Unfortunately there is no distinction between UFO/IPv4 and v6
      features, so disable UFO on taps and virtio_net completely until we
      have a proper solution.
     =20
      We cannot depend on VM managers respecting the tap feature flags, so
      keep accepting UFO packets but log a warning the first time we do
      this.
     =20
      Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
      Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_dat=
a")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 39bb5e62867de82b269b07df900165029b928359
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 30 10:32:34 2014 -0700
 =20
      net: skb_fclone_busy() needs to detect orphaned skb
     =20
      Some drivers are unable to perform TX completions in a bound time.
      They instead call skb_orphan()
     =20
      Problem is skb_fclone_busy() has to detect this case, otherwise
      we block TCP retransmits and can freeze unlucky tcp sessions on
      mostly idle hosts.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 1f3279ae0c13 ("tcp: avoid retransmits of TCP packets hanging i=
n host queues")
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 14051f0452a2c26a3f4791e6ad6a435e8f1945ff
  Author: Tom Herbert <therbert@google.com>
  Date:   Thu Oct 30 08:40:56 2014 -0700
 =20
      gre: Use inner mac length when computing tunnel length
     =20
      Currently, skb_inner_network_header is used but this does not account
      for Ethernet header for ETH_P_TEB. Use skb_inner_mac_header which
      handles TEB and also should work with IP encapsulation in which case
      inner mac and inner network headers are the same.
     =20
      Tested: Ran TCP_STREAM over GRE, worked as expected.
     =20
      Signed-off-by: Tom Herbert <therbert@google.com>
      Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 292dd6542f90126826fe87b302e6afa3b7ada6b8
  Merge: 9cc233f 571e1b2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 19:49:20 2014 -0400
 =20
      Merge branch 'mellanox-net'
     =20
      Or Gerlitz says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      mlx4 driver encapsulation/steering fixes
     =20
      The 1st patch fixes a bug in the TX path that supports offloading the
      TX checksum of (VXLAN) encapsulated TCP packets. It turns out that th=
e
      bug is revealed only when the receiver runs in non-offloaded mode, so
      we somehow missed it so far... please queue it for -stable >=3D 3.14
     =20
      The 2nd patch makes sure not to leak steering entry on error flow,
      please queue it to 3.17-stable
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 571e1b2c7a4c2fd5faa1648462a6b65fa26530d7
  Author: Or Gerlitz <ogerlitz@mellanox.com>
  Date:   Thu Oct 30 15:59:28 2014 +0200
 =20
      mlx4: Avoid leaking steering rules on flow creation error flow
     =20
      If mlx4_ib_create_flow() attempts to create > 1 rules with the
      firmware, and one of these registrations fail, we leaked the
      already created flow rules.
     =20
      One example of the leak is when the registration of the VXLAN ghost
      steering rule fails, we didn't unregister the original rule requested
      by the user, introduced in commit d2fce8a9060d "mlx4: Set
      user-space raw Ethernet QPs to properly handle VXLAN traffic".
     =20
      While here, add dump of the VXLAN portion of steering rules
      so it can actually be seen when flow creation fails.
     =20
      Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit a4f2dacbf2a5045e34b98a35d9a3857800f25a7b
  Author: Or Gerlitz <ogerlitz@mellanox.com>
  Date:   Thu Oct 30 15:59:27 2014 +0200
 =20
      net/mlx4_en: Don't attempt to TX offload the outer UDP checksum for V=
XLAN
     =20
      For VXLAN/NVGRE encapsulation, the current HW doesn't support offload=
ing
      both the outer UDP TX checksum and the inner TCP/UDP TX checksum.
     =20
      The driver doesn't advertize SKB_GSO_UDP_TUNNEL_CSUM, however we are =
wrongly
      telling the HW to offload the outer UDP checksum for encapsulated pac=
kets,
      fix that.
     =20
      Fixes: 837052d0ccc5 ('net/mlx4_en: Add netdev support for TCP/IP
      		     offloads of vxlan tunneling')
      Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9cc233fb0f94b79d07cf141a625e237769d267a1
  Merge: fa19c2b0 e3215f0
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 19:46:33 2014 -0400
 =20
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/gi=
t/jkirsher/net
     =20
      Jeff Kirsher says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      Intel Wired LAN Driver Updates 2014-10-30
     =20
      This series contains updates to e1000, igb and ixgbe.
     =20
      Francesco Ruggeri fixes an issue with e1000 where in a VM the driver =
did
      not support unicast filtering.
     =20
      Roman Gushchin fixes an issue with igb where the driver was re-using
      mapped pages so that packets were still getting dropped even if all
      the memory issues are gone and there is free memory.
     =20
      Junwei Zhang found where in the ixgbe_clean_rx_ring() we were repeati=
ng
      the assignment of NULL to the receive buffer skb and fixes it.
     =20
      Emil fixes a race condition between setup_link and SFP detection rout=
ine
      in the watchdog when setting the advertised speed.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit fa19c2b050ab5254326f5fc07096dd3c6a8d5d58
  Author: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
  Date:   Thu Oct 30 10:09:53 2014 +0100
 =20
      ipv4: Do not cache routing failures due to disabled forwarding.
     =20
      If we cache them, the kernel will reuse them, independently of
      whether forwarding is enabled or not.  Which means that if forwarding=
 is
      disabled on the input interface where the first routing request comes
      from, then that unreachable result will be cached and reused for
      other interfaces, even if forwarding is enabled on them.  The opposit=
e
      is also true.
     =20
      This can be verified with two interfaces A and B and an output interf=
ace
      C, where B has forwarding enabled, but not A and trying
      ip route get $dst iif A from $src && ip route get $dst iif B from $sr=
c
     =20
      Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communicati=
ons.fr>
      Reviewed-by: Julian Anastasov <ja@ssi.bg>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e327c225c911529898ec300cb96d2088893de3df
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Wed Oct 29 17:54:03 2014 -0700
 =20
      cxgb4 : Fix missing initialization of win0_lock
     =20
      win0_lock was being used un-initialized, resulting in warning traces
      being seen when lock debugging is enabled (and just wrong)
     =20
      Fixes : fc5ab0209650 ('cxgb4: Replaced the backdoor mechanism to acce=
ss the HW
       memory with PCIe Window method')
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: Casey Leedom <leedom@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 83810a9a6af310e413ce649c6ca2df2b4946e5a4
  Merge: d70127e e3bd1a8
  Author: David S. Miller <davem@davemloft.net>
  Date:   Thu Oct 30 15:49:05 2014 -0400
 =20
      Merge branch 'r8152-net'
     =20
      Hayes Wang says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      r8152: patches for autosuspend
     =20
      There are unexpected processes when enabling autosuspend.
      These patches are used to fix them.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit e3bd1a81cd1e3f8ed961e642e97206d715db06c4
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:17 2014 +0800
 =20
      r8152: check WORK_ENABLE in suspend function
     =20
      Avoid unnecessary behavior when autosuspend occurs during open().
      The relative processes should only be run after finishing open().
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f4c7476b041d200c3b347f019eebf05e6d0b47f9
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:16 2014 +0800
 =20
      r8152: reset tp->speed before autoresuming in open function
     =20
      If (tp->speed & LINK_STATUS) is not zero, the rtl8152_resume()
      would call rtl_start_rx() before enabling the tx/rx. Avoid this
      by resetting it to zero.
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 923e1ee3ff0b585cc4f56cf696c8455708537ffb
  Author: hayeswang <hayeswang@realtek.com>
  Date:   Wed Oct 29 11:12:15 2014 +0800
 =20
      r8152: clear SELECTIVE_SUSPEND when autoresuming
     =20
      The flag of SELECTIVE_SUSPEND should be cleared when autoresuming.
      Otherwise, when the system suspend and resume occur, it may have
      the wrong flow.
     =20
      Besides, because the flag of SELECTIVE_SUSPEND couldn't be used
      to check if the hw enables the relative feature, it should alwayes
      be disabled in close().
     =20
      Signed-off-by: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 75a916e1944fea8347d2245c62567187e4eff9dd
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:13 2014 -0500
 =20
      rtlwifi: rtl8192se: Fix firmware loading
     =20
      An error in the code makes the allocated space for firmware to be too
      small.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 8ae3c16e41b02db8ffe4121468519d6352baedc1
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:11 2014 -0500
 =20
      rtlwifi: rtl8192ce: Add missing section to read descriptor setting
     =20
      The new version of rtlwifi needs code in rtl92ce_get_desc() that retu=
rns
      the buffer address for read operations.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 30c5ccc6afee39754cff75ad8d775ad39a2ce989
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:10 2014 -0500
 =20
      rtlwifi: rtl8192se: Add missing section to read descriptor setting
     =20
      The new version of rtlwifi needs code in rtl92se_get_desc() that retu=
rns
      the buffer address for read operations.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 501479699ff484ba8acc1d07022271f00cfc55a3
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:09 2014 -0500
 =20
      rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw()
     =20
      Driver rtlwifi has been modified to call ieee80211_register_hw()
      from the probe routine; however, the existing call in the callback
      routine for deferred firmware loading was not removed.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit c0386f1584127442d0f2aea41bc948056d6b1337
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Wed Oct 29 23:17:08 2014 -0500
 =20
      rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing ge=
t_btc_status
     =20
      The recent changes in checking for Bluetooth status added some callba=
cks to code
      in rtlwifi. To make certain that all callbacks are defined, a dummy r=
outine has been
      added to rtlwifi, and the drivers that need to use it are modified.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 3a8fede115f12f7b90524d1ba4e709ce398ce8c6
  Author: Marc Yang <yangyang@marvell.com>
  Date:   Wed Oct 29 22:44:34 2014 +0530
 =20
      mwifiex: restart rxreorder timer correctly
     =20
      During 11n RX reordering, if there is a hole in RX table,
      driver will not send packets to kernel until the rxreorder
      timer expires or the table is full.
      However, currently driver always restarts rxreorder timer when
      receiving a packet, which causes the timer hardly to expire.
      So while connected with to 11n AP in a busy environment,
      ping packets may get blocked for about 30 seconds.
     =20
      This patch fixes this timer restarting by ensuring rxreorder timer
      would only be restarted either timer is not set or start_win
      has changed.
     =20
      Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
      Signed-off-by: Plus Chen <pchen@marvell.com>
      Signed-off-by: Marc Yang <yangyang@marvell.com>
      Signed-off-by: Cathy Luo <cluo@marvell.com>
      Signed-off-by: Avinash Patil <patila@marvell.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit a017ff755e43de9a3221d4ff4f03184ea7b93733
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Wed Oct 29 18:48:05 2014 +0300
 =20
      ath9k: fix some debugfs output
     =20
      The right shift operation has higher precedence than the mask so we
      left shift by "(i * 3)" and then immediately right shift by "(i * 3)"
      then we mask.  It should be left shift, mask, and then right shift.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 664d6a792785cc677c2091038ce10322c8d04ae1
  Author: Cyril Brulebois <kibi@debian.org>
  Date:   Tue Oct 28 16:42:41 2014 +0100
 =20
      wireless: rt2x00: add new rt2800usb device
     =20
      0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
     =20
      References: https://bugs.debian.org/766802
      Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
      Cc: stable@vger.kernel.org
      Signed-off-by: Cyril Brulebois <kibi@debian.org>
      Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit e3215f0ac77ec23b052cb0bf511143038ac2ad7b
  Author: Emil Tantilov <emil.s.tantilov@intel.com>
  Date:   Tue Oct 28 05:50:03 2014 +0000
 =20
      ixgbe: fix race when setting advertised speed
     =20
      Following commands:
     =20
      modprobe ixgbe
      ifconfig ethX up
      ethtool -s ethX advertise 0x020
     =20
      can lead to "setup link failed with code -14" error due to the setup_=
link
      call racing with the SFP detection routine in the watchdog.
     =20
      This patch resolves this issue by protecting the setup_link call with=
 check
      for __IXGBE_IN_SFP_INIT.
     =20
      Reported-by: Scott Harrison <scoharr2@cisco.com>
      Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
      Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit 4d2fcfbcf8141cdf70245a0c0612b8076f4b7e32
  Author: Junwei Zhang <linggao.zjw@alibaba-inc.com>
  Date:   Wed Oct 22 15:29:03 2014 +0000
 =20
      ixgbe: need not repeat init skb with NULL
     =20
      Signed-off-by: Martin Zhang <martinbj2008@gmail.com>
      Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit bc16e47f03a7dce9ad68029b21519265c334eb12
  Author: Roman Gushchin <klamm@yandex-team.ru>
  Date:   Thu Oct 23 03:32:27 2014 +0000
 =20
      igb: don't reuse pages with pfmemalloc flag
     =20
      Incoming packet is dropped silently by sk_filter(), if the skb was
      allocated from pfmemalloc reserves and the corresponding socket is
      not marked with the SOCK_MEMALLOC flag.
     =20
      Igb driver allocates pages for DMA with __skb_alloc_page(), which
      calls alloc_pages_node() with the __GFP_MEMALLOC flag. So, in case
      of OOM condition, igb can get pages with pfmemalloc flag set.
     =20
      If an incoming packet hits the pfmemalloc page and is large enough
      (small packets are copying into the memory, allocated with
      netdev_alloc_skb_ip_align(), so they are not affected), it will be
      dropped.
     =20
      This behavior is ok under high memory pressure, but the problem is
      that the igb driver reuses these mapped pages. So, packets are still
      dropping even if all memory issues are gone and there is a plenty
      of free memory.
     =20
      In my case, some TCP sessions hang on a small percentage (< 0.1%)
      of machines days after OOMs.
     =20
      Fix this by avoiding reuse of such pages.
     =20
      Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
      Tested-by: Aaron Brown "aaron.f.brown@intel.com"
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit a22bb0b9b9b09b4cc711f6d577679773e074dde9
  Author: Francesco Ruggeri <fruggeri@aristanetworks.com>
  Date:   Wed Oct 22 15:29:24 2014 +0000
 =20
      e1000: unset IFF_UNICAST_FLT on WMware 82545EM
     =20
      VMWare's e1000 implementation does not seem to support unicast filter=
ing.
      This can be observed by configuring a macvlan interface on eth0 in a =
VM in
      VMWare Fusion 5.0.5, and trying to use that interface instead of eth0=
.
      Tested on 3.16.
     =20
      Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
      Tested-by: Aaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
 =20
  commit d70127e8a942364de8dd140fe73893efda363293
  Author: Nikolay Aleksandrov <nikolay@redhat.com>
  Date:   Tue Oct 28 10:44:01 2014 +0100
 =20
      inet: frags: remove the WARN_ON from inet_evict_bucket
     =20
      The WARN_ON in inet_evict_bucket can be triggered by a valid case:
      inet_frag_kill and inet_evict_bucket can be running in parallel on th=
e
      same queue which means that there has been at least one more ref adde=
d
      by a previous inet_frag_find call, but inet_frag_kill can delete the
      timer before inet_evict_bucket which will cause the WARN_ON() there t=
o
      trigger since we'll have refcnt!=3D1. Now, this case is valid because=
 the
      queue is being "killed" for some reason (removed from the chain list =
and
      its timer deleted) so it will get destroyed in the end by one of the
      inet_frag_put() calls which reaches 0 i.e. refcnt is still valid.
     =20
      CC: Florian Westphal <fw@strlen.de>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Patrick McLean <chutzpah@gentoo.org>
     =20
      Fixes: b13d3cbfb8e8 ("inet: frag: move eviction of queues to work que=
ue")
      Reported-by: Patrick McLean <chutzpah@gentoo.org>
      Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 65ba1f1ec0eff1c25933468e1d238201c0c2cb29
  Author: Nikolay Aleksandrov <nikolay@redhat.com>
  Date:   Tue Oct 28 10:30:34 2014 +0100
 =20
      inet: frags: fix a race between inet_evict_bucket and inet_frag_kill
     =20
      When the evictor is running it adds some chosen frags to a local list=
 to
      be evicted once the chain lock has been released but at the same time
      the *frag_queue can be running for some of the same queues and it
      may call inet_frag_kill which will wait on the chain lock and
      will then delete the queue from the wrong list since it was added in =
the
      eviction one. The fix is simple - check if the queue has the evict fl=
ag
      set under the chain lock before deleting it, this is safe because the
      evict flag is set only under that lock and having the flag set also m=
eans
      that the queue has been detached from the chain list, so no need to d=
elete
      it again.
      An important note to make is that we're safe w.r.t refcnt because
      inet_frag_kill and inet_evict_bucket will sync on the del_timer opera=
tion
      where only one of the two can succeed (or if the timer is executing -
      none of them), the cases are:
      1. inet_frag_kill succeeds in del_timer
       - then the timer ref is removed, but inet_evict_bucket will not add
         this queue to its expire list but will restart eviction in that ch=
ain
      2. inet_evict_bucket succeeds in del_timer
       - then the timer ref is kept until the evictor "expires" the queue, =
but
         inet_frag_kill will remove the initial ref and will set
         INET_FRAG_COMPLETE which will make the frag_expire fn just to remo=
ve
         its ref.
      In the end all of the queue users will do an inet_frag_put and the on=
e
      that reaches 0 will free it. The refcount balance should be okay.
     =20
      CC: Florian Westphal <fw@strlen.de>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Patrick McLean <chutzpah@gentoo.org>
     =20
      Fixes: b13d3cbfb8e8 ("inet: frag: move eviction of queues to work que=
ue")
      Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
      Reported-by: Patrick McLean <chutzpah@gentoo.org>
      Tested-by: Patrick McLean <chutzpah@gentoo.org>
      Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
      Reviewed-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8f4eb70059ee834522ce90a6fce0aa3078c18620
  Author: Tej Parkash <tej.parkash@qlogic.com>
  Date:   Tue Oct 28 01:18:15 2014 -0400
 =20
      cnic: Update the rcu_access_pointer() usages
     =20
      1. Remove the rcu_read_lock/unlock around rcu_access_pointer
      2. Replace the rcu_dereference with rcu_access_pointer
     =20
      Signed-off-by: Tej Parkash <tej.parkash@qlogic.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit cd03cf0158449f9f4c19ecb54dfc97d9bd86eeeb
  Author: Hariprasad Shenai <hariprasad@chelsio.com>
  Date:   Mon Oct 27 23:22:10 2014 +0530
 =20
      cxgb4vf: Replace repetitive pci device ID's with right ones
     =20
      Replaced repetive Device ID's which got added in commit b961f9a48844e=
cf3
      ("cxgb4vf: Remove superfluous "idx" parameter of CH_DEVICE() macro")
     =20
      Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b2ed64a97430a26a63c6ea91c9b50e639a98dfbc
  Author: Lubomir Rintel <lkundrak@v3.sk>
  Date:   Mon Oct 27 17:39:16 2014 +0100
 =20
      ipv6: notify userspace when we added or changed an ipv6 token
     =20
      NetworkManager might want to know that it changed when the router adv=
ertisement
      arrives.
     =20
      Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: Daniel Borkmann <dborkman@redhat.com>
      Acked-by: Daniel Borkmann <dborkman@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d56109020d93337545dd257a790cb429a70acfad
  Author: WANG Cong <xiyou.wangcong@gmail.com>
  Date:   Fri Oct 24 16:55:58 2014 -0700
 =20
      sch_pie: schedule the timer after all init succeed
     =20
      Cc: Vijay Subramanian <vijaynsu@cisco.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
      Acked-by: Eric Dumazet <edumazet@google.com>
 =20
  commit 068301f2be36a5c1ee9a2521c94b98e343612a88
  Merge: 9ffa1fc b77e26d
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 17:26:24 2014 -0400
 =20
      Merge branch 'cdc-ether'
     =20
      Olivier Blin says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      cdc-ether: handle promiscuous mode
     =20
      Since kernel 3.16, my Lenovo USB network adapters (RTL8153) using
      cdc-ether are not working anymore in a bridge.
     =20
      This is due to commit c472ab68ad67db23c9907a27649b7dc0899b61f9, which
      resets the packet filter when the device is bound.
     =20
      The default packet filter set by cdc-ether does not include
      promiscuous, while the adapter seemed to have promiscuous enabled by
      default.
     =20
      This patch series allows to support promiscuous mode for cdc-ether, b=
y
      hooking into set_rx_mode.
     =20
      Incidentally, maybe this device should be handled by the r8152 driver=
,
      but this patch series is still nice for other adapters.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
      Acked-by: Oliver Neukum <oneukum@suse.de>
 =20
  commit b77e26d191590c73b4a982ea3b3b87194069a56a
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:02 2014 +0200
 =20
      cdc-ether: handle promiscuous mode with a set_rx_mode callback
     =20
      Promiscuous mode was not supported anymore with my Lenovo adapters
      (RTL8153) since commit c472ab68ad67db23c9907a27649b7dc0899b61f9
      (cdc-ether: clean packet filter upon probe).
     =20
      It was not possible to use them in a bridge anymore.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Also-analyzed-by: Lo=C3=AFc Yhuel <loic.yhuel@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d80c679bc1526183f1cf4adc54b0b72e8798555e
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:01 2014 +0200
 =20
      cdc-ether: extract usbnet_cdc_update_filter function
     =20
      This will be used by the set_rx_mode callback.
     =20
      Also move a comment about multicast filtering in this new function.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1efed2d06c703489342ab6af2951683e07509c99
  Author: Olivier Blin <olivier.blin@softathome.com>
  Date:   Fri Oct 24 19:43:00 2014 +0200
 =20
      usbnet: add a callback for set_rx_mode
     =20
      To delegate promiscuous mode and multicast filtering to the subdriver=
.
     =20
      Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9ffa1fcaef222026a8e031830f8db29d3f2cfc47
  Merge: ebcf34f 704d33e
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 17:08:56 2014 -0400
 =20
      Merge branch 'systemport-net'
     =20
      Florian Fainelli says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      net: systemport: RX path and suspend fixes
     =20
      These two patches fix a race condition where we have our RX interrupt=
s
      enabled, but not NAPI for the RX path, and the second patch fixes an
      issue for packets stuck in RX fifo during a suspend/resume cycle.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 704d33e7006f20f9b4fa7d24a0f08c4b5919b131
  Author: Florian Fainelli <f.fainelli@gmail.com>
  Date:   Tue Oct 28 11:12:01 2014 -0700
 =20
      net: systemport: reset UniMAC coming out of a suspend cycle
     =20
      bcm_sysport_resume() was missing an UniMAC reset which can lead to
      various receive FIFO corruptions coming out of a suspend cycle. If th=
e
      RX FIFO is stuck, it will deliver corrupted/duplicate packets towards
      the host CPU interface.
     =20
      This could be reproduced on crowded network and when Wake-on-LAN is
      enabled for this particular interface because the switch still forwar=
ds
      packets towards the host CPU interface (SYSTEMPORT), and we had to le=
ave
      the UniMAC RX enable bit on to allow matching MagicPackets.
     =20
      Once we re-enter the resume function, there is a small window during
      which the UniMAC receive is still enabled, and we start queueing
      packets, but the RDMA and RBUF engines are not ready, which leads to
      having packets stuck in the UniMAC RX FIFO, ultimately delivered towa=
rds
      the host CPU as corrupted.
     =20
      Fixes: 40755a0fce17 ("net: systemport: add suspend and resume support=
")
      Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8edf0047f4b8e03d94ef88f5a7dec146cce03a06
  Author: Florian Fainelli <f.fainelli@gmail.com>
  Date:   Tue Oct 28 11:12:00 2014 -0700
 =20
      net: systemport: enable RX interrupts after NAPI
     =20
      There is currently a small window during which the SYSTEMPORT adapter
      enables its RX interrupts without having enabled its NAPI handler, wh=
ich
      can result in packets to be discarded during interface bringup.
     =20
      A similar but more serious window exists in bcm_sysport_resume() duri=
ng
      which we can have the RDMA engine not fully prepared to receive packe=
ts
      and yet having RX interrupts enabled.
     =20
      Fix this my moving the RX interrupt enable down to
      bcm_sysport_netif_start() after napi_enable() for the RX path is call=
ed,
      which fixes both call sites: bcm_sysport_open() and
      bcm_sysport_resume().
     =20
      Fixes: b02e6d9ba7ad ("net: systemport: add bcm_sysport_netif_{enable,=
stop}")
      Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ebcf34f3d4be11f994340aff629f3c17171a4f65
  Author: Randy Dunlap <rdunlap@infradead.org>
  Date:   Sun Oct 26 19:14:06 2014 -0700
 =20
      skbuff.h: fix kernel-doc warning for headers_end
     =20
      Fix kernel-doc warning in <linux/skbuff.h> by making both headers_sta=
rt
      and headers_end private fields.
     =20
      Warning(..//include/linux/skbuff.h:654): No description found for par=
ameter 'headers_end[0]'
     =20
      Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 99d881f993f066c75059d24e44c74f7a3fc199bc
  Author: Vince Bridgers <vbridger@opensource.altera.com>
  Date:   Sun Oct 26 14:22:24 2014 -0500
 =20
      net: phy: Add SGMII Configuration for Marvell 88E1145 Initialization
     =20
      Marvell phy 88E1145 configuration & initialization was missing a case
      for initializing SGMII mode. This patch adds that case.
     =20
      Signed-off-by: Vince Bridgers <vbridger@opensource.altera.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 47276fcc2d542e7b15e384c08b1709c1921b06c1
  Author: Mugunthan V N <mugunthanvnm@ti.com>
  Date:   Fri Oct 24 18:51:33 2014 +0530
 =20
      drivers: net:cpsw: fix probe_dt when only slave 1 is pinned out
     =20
      when slave 0 has no phy and slave 1 connected to phy, driver probe wi=
ll
      fail as there is no phy id present for slave 0 device tree, so contin=
uing
      even though no phy-id found, also moving mac-id read later to ensure
      mac-id is read from device tree even when phy-id entry in not found.
     =20
      Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 25946f20b775f5c630d4326dd7a7f1df0576eb57
  Merge: 3923d68 99c8140
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 15:30:15 2014 -0400
 =20
      Merge tag 'master-2014-10-27' of git://git.kernel.org/pub/scm/linux/k=
ernel/git/linville/wireless
     =20
      John W. Linville says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      pull request: wireless 2014-10-28
     =20
      Please pull this batch of fixes intended for the 3.18 stream!
     =20
      For the mac80211 bits, Johannes says:
     =20
      "Here are a few fixes for the wireless stack: one fixes the
      RTS rate, one for a debugfs file, one to return the correct
      channel to userspace, a sanity check for a userspace value
      and the remaining two are just documentation fixes."
     =20
      For the iwlwifi bits, Emmanuel says:
     =20
      "I revert here a patch that caused interoperability issues.
      dvm gets a fix for a bug that was reported by many users.
      Two minor fixes for BT Coex and platform power fix that helps
      reducing latency when the PCIe link goes to low power states."
     =20
      In addition...
     =20
      Felix Fietkau adds a couple of ath code fixes related to regulatory
      rule enforcement.
     =20
      Hauke Mehrtens fixes a build break with bcma when CONFIG_OF_ADDRESS
      is not set.
     =20
      Karsten Wiese provides a trio of minor fixes for rtl8192cu.
     =20
      Kees Cook prevents a potential information leak in rtlwifi.
     =20
      Larry Finger also brings a trio of minor fixes for rtlwifi.
     =20
      Rafa=C5=82 Mi=C5=82ecki adds a device ID to the bcma bus driver.
     =20
      Rickard Strandqvist offers some strn* -> strl* changes in brcmfmac
      to eliminate non-terminated string issues.
     =20
      Sujith Manoharan avoids some ath9k stalls by enabling HW queue contro=
l
      only for MCC.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3923d68dc05033aa843b67d73110a6d402ac6e14
  Merge: f89b775 c146b77
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 28 15:28:30 2014 -0400
 =20
      Merge branch 'dsa-net'
     =20
      Andrew Lunn says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      DSA tagging mismatches
     =20
      The second patch is a fix, which should be applied to -rc. It is
      possible to get a DSA configuration which does not work. The patch
      stops this happening.
     =20
      The first patch detects this situation, and errors out the probe of
      DSA, making it more obvious something is wrong. It is not required to
      apply it -rc.
     =20
      v2 fixes the use case pointed out by Florian, that a switch driver
      may use DSA_TAG_PROTO_NONE which the patch did not correctly handle.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c146b7788e5721ec15bc0197bedf75849508e7ea
  Author: Andrew Lunn <andrew@lunn.ch>
  Date:   Fri Oct 24 23:44:05 2014 +0200
 =20
      dsa: mv88e6171: Fix tagging protocol/Kconfig
     =20
      The mv88e6171 can support two different tagging protocols, DSA and
      EDSA. The switch driver structure only allows one protocol to be
      enumerated, and DSA was chosen. However the Kconfig entry ensures the
      EDSA tagging code is built. With a minimal configuration, we then end
      up with a mismatch. The probe is successful, EDSA tagging is used, bu=
t
      the switch is configured for DSA, resulting in mangled packets.
     =20
      Change the switch driver structure to enumerate EDSA, fixing the
      mismatch.
     =20
      Signed-off-by: Andrew Lunn <andrew@lunn.ch>
      Fixes: 42f272539487 ("net: DSA: Marvell mv88e6171 switch driver")
      Acked-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ae439286a0dec99cc8029868243689b5b5f3ff75
  Author: Andrew Lunn <andrew@lunn.ch>
  Date:   Fri Oct 24 23:44:04 2014 +0200
 =20
      net: dsa: Error out on tagging protocol mismatches
     =20
      If there is a mismatch between enabled tagging protocols and the
      protocol the switch supports, error out, rather than continue with a
      situation which is unlikely to work.
     =20
      Signed-off-by: Andrew Lunn <andrew@lunn.ch>
      cc: alexander.h.duyck@intel.com
      Acked-by: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3d53666b40007b55204ee8890618da79a20c9940
  Author: Alex Gartrell <agartrell@fb.com>
  Date:   Mon Oct 6 08:46:19 2014 -0700
 =20
      ipvs: Avoid null-pointer deref in debug code
     =20
      Use daddr instead of reaching into dest.
     =20
      Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: Alex Gartrell <agartrell@fb.com>
      Signed-off-by: Simon Horman <horms@verge.net.au>
 =20
  commit f89b7755f517cdbb755d7543eef986ee9d54e654
  Author: Alexei Starovoitov <ast@plumgrid.com>
  Date:   Thu Oct 23 18:41:08 2014 -0700
 =20
      bpf: split eBPF out of NET
     =20
      introduce two configs:
      - hidden CONFIG_BPF to select eBPF interpreter that classic socket fi=
lters
        depend on
      - visible CONFIG_BPF_SYSCALL (default off) that tracing and sockets c=
an use
     =20
      that solves several problems:
      - tracing and others that wish to use eBPF don't need to depend on NE=
T.
        They can use BPF_SYSCALL to allow loading from userspace or select =
BPF
        to use it directly from kernel in NET-less configs.
      - in 3.18 programs cannot be attached to events yet, so don't force i=
t on
      - when the rest of eBPF infra is there in 3.19+, it's still useful to
        switch it off to minimize kernel size
     =20
      bloat-o-meter on x64 shows:
      add/remove: 0/60 grow/shrink: 0/2 up/down: 0/-15601 (-15601)
     =20
      tested with many different config combinations. Hopefully didn't miss=
 anything.
     =20
      Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
      Acked-by: Daniel Borkmann <dborkman@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8ae3c911b9efcca653c552a9c74957a6cb04a87d
  Merge: 5d26b1f 3bb0626
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 27 19:00:16 2014 -0400
 =20
      Merge branch 'cxgb4-net'
     =20
      Anish Bhatt says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      cxgb4 : DCBx fixes for apps/host lldp agents
     =20
      This patchset  contains some minor fixes for cxgb4 DCBx code. Chiefly=
, cxgb4
      was not cleaning up any apps added to kernel app table when link was =
lost.
      Disabling DCBx in firmware would automatically set DCBx state to host=
-managed
      and enabled, we now wait for an explicit enable call from an lldp age=
nt instead
     =20
      First patch was originally sent to net-next, but considering it appli=
es to
      correcting behaviour of code already in net, I think it qualifies as =
a bug fix.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 3bb062613b1ecbd0c388106f61344d699f7859ec
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Thu Oct 23 14:37:31 2014 -0700
 =20
      cxgb4 : Handle dcb enable correctly
     =20
      Disabling DCBx in firmware automatically enables DCBx for control via=
 host
      lldp agents. Wait for an explicit setstate call from an lldp agents t=
o enable
       DCBx instead.
     =20
      Fixes: 76bcb31efc06 ("cxgb4 : Add DCBx support codebase and dcbnl_ops=
")
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 2376c879b80c83424a3013834be97fb9fe2d4180
  Author: Anish Bhatt <anish@chelsio.com>
  Date:   Thu Oct 23 14:37:30 2014 -0700
 =20
      cxgb4 : Improve handling of DCB negotiation or loss thereof
     =20
      Clear out any DCB apps we might have added to kernel table when we lo=
se DCB
      sync (or IEEE equivalent event). These were previously left behind an=
d not
      cleaned up correctly. IEEE allows individual components to work indep=
endently,
       so improve check for IEEE completion by specifying individual compon=
ents.
     =20
      Fixes: 10b0046685ab ("cxgb4: IEEE fixes for DCBx state machine")
     =20
      Signed-off-by: Anish Bhatt <anish@chelsio.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5d26b1f50a610fb28700cdc3446590495a5f607c
  Merge: 93a35f5 7965ee9
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 27 18:47:40 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      Netfilter fixes for net
     =20
      The following patchset contains Netfilter fixes for your net tree,
      they are:
     =20
      1) Allow to recycle a TCP port in conntrack when the change role from
         server to client, from Marcelo Leitner.
     =20
      2) Fix possible off by one access in ip_set_nfnl_get_byindex(), patch
         from Dan Carpenter.
     =20
      3) alloc_percpu returns NULL on error, no need for IS_ERR() in nf_tab=
les
         chain statistic updates. From Sabrina Dubroca.
     =20
      4) Don't compile ip options in bridge netfilter, this mangles the pac=
ket
         and bridge should not alter layer >=3D 3 headers when forwarding p=
ackets.
         Patch from Herbert Xu and tested by Florian Westphal.
     =20
      5) Account the final NLMSG_DONE message when calculating the size of =
the
         nflog netlink batches. Patch from Florian Westphal.
     =20
      6) Fix a possible netlink attribute length overflow with large packet=
s.
         Again from Florian Westphal.
     =20
      7) Release the skbuff if nfnetlink_log fails to put the final
         NLMSG_DONE message. This fixes a leak on error. This shouldn't eve=
r
         happen though, otherwise this means we miscalculate the netlink ba=
tch
         size, so spot a warning if this ever happens so we can track down =
the
         problem. This patch from Houcheng Lin.
     =20
      8) Look at the right list when recycling targets in the nft_compat,
         patch from Arturo Borrero.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7965ee93719921ea5978f331da653dfa2d7b99f5
  Author: Arturo Borrero <arturo.borrero.glez@gmail.com>
  Date:   Sun Oct 26 12:22:40 2014 +0100
 =20
      netfilter: nft_compat: fix wrong target lookup in nft_target_select_o=
ps()
     =20
      The code looks for an already loaded target, and the correct list to =
search
      is nft_target_list, not nft_match_list.
     =20
      Signed-off-by: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com=
>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 99c814066e75d09e6a38574c6c395f022a04b730
  Merge: fad1dbc 11b2357
  Author: John W. Linville <linville@tuxdriver.com>
  Date:   Mon Oct 27 13:38:15 2014 -0400
 =20
      Merge tag 'mac80211-for-john-2014-10-23' of git://git.kernel.org/pub/=
scm/linux/kernel/git/jberg/mac80211
     =20
      Johannes Berg <johannes@sipsolutions.net> says:
     =20
      "Here are a few fixes for the wireless stack: one fixes the
      RTS rate, one for a debugfs file, one to return the correct
      channel to userspace, a sanity check for a userspace value
      and the remaining two are just documentation fixes."
     =20
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit fad1dbc8efb4e51e121c745a99c0fb22b420a5c6
  Merge: 0805420 7f2ac8f
  Author: John W. Linville <linville@tuxdriver.com>
  Date:   Mon Oct 27 13:35:59 2014 -0400
 =20
      Merge tag 'iwlwifi-for-john-2014-10-23' of git://git.kernel.org/pub/s=
cm/linux/kernel/git/iwlwifi/iwlwifi-fixes
     =20
      Emmanuel Grumbach <egrumbach@gmail.com> says:
     =20
      "I revert here a patch that caused interoperability issues.
      dvm gets a fix for a bug that was reported by many users.
      Two minor fixes for BT Coex and platform power fix that helps
      reducing latency when the PCIe link goes to low power states."
     =20
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 93a35f59f1b13a02674877e3efdf07ae47e34052
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 23 06:30:30 2014 -0700
 =20
      net: napi_reuse_skb() should check pfmemalloc
     =20
      Do not reuse skb if it was pfmemalloc tainted, otherwise
      future frame might be dropped anyway.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit aa9c5579153535fb317a9d34c7d8eaf02b7ef4cd
  Merge: b71e821 bf1bac5
  Author: David S. Miller <davem@davemloft.net>
  Date:   Sun Oct 26 22:46:08 2014 -0400
 =20
      Merge branch 'mellanox'
     =20
      Eli Cohen says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      irq sync fixes
     =20
      This two patch series fixes a race where an interrupt handler could a=
ccess a
      freed memory.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit bf1bac5b7882daa41249f85fbc97828f0597de5c
  Author: Eli Cohen <eli@dev.mellanox.co.il>
  Date:   Thu Oct 23 15:57:27 2014 +0300
 =20
      net/mlx4_core: Call synchronize_irq() before freeing EQ buffer
     =20
      After moving the EQ ownership to software effectively destroying it, =
call
      synchronize_irq() to ensure that any handler routines running on othe=
r CPU
      cores finish execution. Only then free the EQ buffer.
      The same thing is done when we destroy a CQ which is one of the sourc=
es
      generating interrupts. In the case of CQ we want to avoid completion =
handlers
      on a CQ that was destroyed. In the case we do the same to avoid recei=
ving
      asynchronous events after the EQ has been destroyed and its buffers f=
reed.
     =20
      Signed-off-by: Eli Cohen <eli@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 96e4be06cbfcb8c9c2da7c77bacce0e56b581c0b
  Author: Eli Cohen <eli@dev.mellanox.co.il>
  Date:   Thu Oct 23 15:57:26 2014 +0300
 =20
      net/mlx5_core: Call synchronize_irq() before freeing EQ buffer
     =20
      After destroying the EQ, the object responsible for generating interr=
upts, call
      synchronize_irq() to ensure that any handler routines running on othe=
r CPU
      cores finish execution. Only then free the EQ buffer. This patch solv=
es a very
      rare case when we get panic on driver unload.
      The same thing is done when we destroy a CQ which is one of the sourc=
es
      generating interrupts. In the case of CQ we want to avoid completion =
handlers
      on a CQ that was destroyed. In the case we do the same to avoid recei=
ving
      asynchronous events after the EQ has been destroyed and its buffers f=
reed.
     =20
      Signed-off-by: Eli Cohen <eli@mellanox.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b71e821de50f0ff92f10f33064ee1713e9014158
  Author: Geert Uytterhoeven <geert@linux-m68k.org>
  Date:   Thu Oct 23 10:25:53 2014 +0200
 =20
      drivers: net: xgene: Rewrite buggy loop in xgene_enet_ecc_init()
     =20
      drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function =E2=80=
=98xgene_enet_ecc_init=E2=80=99:
      drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:126: warning: =E2=
=80=98data=E2=80=99 may be used uninitialized in this function
     =20
      Depending on the arbitrary value on the stack, the loop may terminate
      too early, and cause a bogus -ENODEV failure.
     =20
      Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 013f6579c6e4f9517127a176bfc37bbac0b766cb
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Wed Oct 22 20:06:29 2014 -0700
 =20
      i40e: _MASK vs _SHIFT typo in i40e_handle_mdd_event()
     =20
      We accidentally mask by the _SHIFT variable.  It means that "event" i=
s
      always zero.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Tested-by: Jim Young <jamesx.m.young@intel.com>
      Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit fe0ca7328d03d36aafecebb3af650e1bb2841c20
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Wed Oct 22 19:43:46 2014 -0700
 =20
      macvlan: fix a race on port dismantle and possible skb leaks
     =20
      We need to cancel the work queue after rcu grace period,
      otherwise it can be rescheduled by incoming packets.
     =20
      We need to purge queue if some skbs are still in it.
     =20
      We can use __skb_queue_head_init() variant in
      macvlan_process_broadcast()
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 412ca1550cbec ("macvlan: Move broadcasts into a work queue")
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 349ce993ac706869d553a1816426d3a4bfda02b1
  Author: Eric Dumazet <edumazet@google.com>
  Date:   Thu Oct 23 12:58:58 2014 -0700
 =20
      tcp: md5: do not use alloc_percpu()
     =20
      percpu tcp_md5sig_pool contains memory blobs that ultimately
      go through sg_set_buf().
     =20
      -> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
     =20
      This requires that whole area is in a physically contiguous portion
      of memory. And that @buf is not backed by vmalloc().
     =20
      Given that alloc_percpu() can use vmalloc() areas, this does not
      fit the requirements.
     =20
      Replace alloc_percpu() by a static DEFINE_PER_CPU() as tcp_md5sig_poo=
l
      is small anyway, there is no gain to dynamically allocate it.
     =20
      Signed-off-by: Eric Dumazet <edumazet@google.com>
      Fixes: 765cf9976e93 ("tcp: md5: remove one indirection level in tcp_m=
d5sig_pool")
      Reported-by: Crestez Dan Leonard <cdleonard@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 4cc40af08032a513e2e68fa6d7818b77179a86af
  Merge: 5345c1d ecf08d2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Sat Oct 25 14:15:25 2014 -0400
 =20
      Merge branch 'xen-netback'
     =20
      David Vrabel says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      xen-netback: guest Rx queue drain and stall fixes
     =20
      This series fixes two critical xen-netback bugs.
     =20
      1. Netback may consume all of host memory by queuing an unlimited
         number of skb on the internal guest Rx queue.  This behaviour is
         guest triggerable.
     =20
      2. Carrier flapping under high traffic rates which reduces
         performance.
     =20
      The first patch is a prerequite.  Removing support for frontends with
      feature-rx-notify makes it easier to reason about the correctness of
      netback since it no longer has to support this outdated and broken
      mode.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:55 2014 +0100
 =20
      xen-netback: reintroduce guest Rx stall detection
     =20
      If a frontend not receiving packets it is useful to detect this and
      turn off the carrier so packets are dropped early instead of being
      queued and drained when they expire.
     =20
      A to-guest queue is stalled if it doesn't have enough free slots for =
a
      an extended period of time (default 60 s).
     =20
      If at least one queue is stalled, the carrier is turned off (in the
      expectation that the other queues will soon stall as well).  The
      carrier is only turned on once all queues are ready.
     =20
      When the frontend connects, all the queues start in the stalled state
      and only become ready once the frontend queues enough Rx requests.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Reviewed-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f48da8b14d04ca87ffcffe68829afd45f926ec6a
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:54 2014 +0100
 =20
      xen-netback: fix unlimited guest Rx internal queue and carrier flappi=
ng
     =20
      Netback needs to discard old to-guest skb's (guest Rx queue drain) an=
d
      it needs detect guest Rx stalls (to disable the carrier so packets ar=
e
      discarded earlier), but the current implementation is very broken.
     =20
      1. The check in hard_start_xmit of the slot availability did not
         consider the number of packets that were already in the guest Rx
         queue.  This could allow the queue to grow without bound.
     =20
         The guest stops consuming packets and the ring was allowed to fill
         leaving S slot free.  Netback queues a packet requiring more than =
S
         slots (ensuring that the ring stays with S slots free).  Netback
         queue indefinately packets provided that then require S or fewer
         slots.
     =20
      2. The Rx stall detection is not triggered in this case since the
         (host) Tx queue is not stopped.
     =20
      3. If the Tx queue is stopped and a guest Rx interrupt occurs, netbac=
k
         will consider this an Rx purge event which may result in it taking
         the carrier down unnecessarily.  It also considers a queue with
         only 1 slot free as unstalled (even though the next packet might
         not fit in this).
     =20
      The internal guest Rx queue is limited by a byte length (to 512 Kib,
      enough for half the ring).  The (host) Tx queue is stopped and starte=
d
      based on this limit.  This sets an upper bound on the amount of memor=
y
      used by packets on the internal queue.
     =20
      This allows the estimatation of the number of slots for an skb to be
      removed (it wasn't a very good estimate anyway).  Instead, the guest
      Rx thread just waits for enough free slots for a maximum sized packet=
.
     =20
      skbs queued on the internal queue have an 'expires' time (set to the
      current time plus the drain timeout).  The guest Rx thread will detec=
t
      when the skb at the head of the queue has expired and discard expired
      skbs.  This sets a clear upper bound on the length of time an skb can
      be queued for.  For a guest being destroyed the maximum time needed t=
o
      wait for all the packets it sent to be dropped is still the drain
      timeout (10 s) since it will not be sending new packets.
     =20
      Rx stall detection is reintroduced in a later commit.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Reviewed-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit bc96f648df1bbc2729abbb84513cf4f64273a1f1
  Author: David Vrabel <david.vrabel@citrix.com>
  Date:   Wed Oct 22 14:08:53 2014 +0100
 =20
      xen-netback: make feature-rx-notify mandatory
     =20
      Frontends that do not provide feature-rx-notify may stall because
      netback depends on the notification from frontend to wake the guest R=
x
      thread (even if can_queue is false).
     =20
      This could be fixed but feature-rx-notify was introduced in 2006 and =
I
      am not aware of any frontends that do not implement this.
     =20
      Signed-off-by: David Vrabel <david.vrabel@citrix.com>
      Acked-by: Wei Liu <wei.liu2@citrix.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 5345c1d417c1b0caf46fd2766d16bb4357a347d8
  Author: Richard Cochran <richardcochran@gmail.com>
  Date:   Wed Oct 22 21:35:15 2014 +0200
 =20
      ptp: restore the makefile for building the test program.
     =20
      This patch brings back the makefile called testptp.mk which was remov=
ed
      in commit adb19fb66eee (Documentation: add makefiles for more targets=
).
     =20
      While the idea of that commit was to improve build coverage of the
      examples, the new Makefile is unable to cross compile the testptp pro=
gram.
      In contrast, the deleted makefile was able to do this just fine.
     =20
      This patch fixes the regression by restoring the original makefile.
     =20
      Signed-off-by: Richard Cochran <richardcochran@gmail.com>
      Acked-by: Peter Foley <pefoley2@pefoley.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b51d3fa364885a2c1e1668f88776c67c95291820
  Author: Houcheng Lin <houcheng@gmail.com>
  Date:   Thu Oct 23 10:36:08 2014 +0200
 =20
      netfilter: nf_log: release skbuff on nlmsg put failure
     =20
      The kernel should reserve enough room in the skb so that the DONE
      message can always be appended.  However, in case of e.g. new attribu=
te
      erronously not being size-accounted for, __nfulnl_send() will still
      try to put next nlmsg into this full skbuf, causing the skb to be stu=
ck
      forever and blocking delivery of further messages.
     =20
      Fix issue by releasing skb immediately after nlmsg_put error and
      WARN() so we can track down the cause of such size mismatch.
     =20
      [ fw@strlen.de: add tailroom/len info to WARN ]
     =20
      Signed-off-by: Houcheng Lin <houcheng@gmail.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit c1e7dc91eed0ed1a51c9b814d648db18bf8fc6e9
  Author: Florian Westphal <fw@strlen.de>
  Date:   Thu Oct 23 10:36:07 2014 +0200
 =20
      netfilter: nfnetlink_log: fix maximum packet length logged to userspa=
ce
     =20
      don't try to queue payloads > 0xffff - NLA_HDRLEN, it does not work.
      The nla length includes the size of the nla struct, so anything large=
r
      results in u16 integer overflow.
     =20
      This patch is similar to
      9cefbbc9c8f9abe (netfilter: nfnetlink_queue: cleanup copy_range usage=
).
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 9dfa1dfe4d5e5e66a991321ab08afe69759d797a
  Author: Florian Westphal <fw@strlen.de>
  Date:   Thu Oct 23 10:36:06 2014 +0200
 =20
      netfilter: nf_log: account for size of NLMSG_DONE attribute
     =20
      We currently neither account for the nlattr size, nor do we consider
      the size of the trailing NLMSG_DONE when allocating nlmsg skb.
     =20
      This can result in nflog to stop working, as __nfulnl_send() re-tries
      sending forever if it failed to append NLMSG_DONE (which will never
      work if buffer is not large enough).
     =20
      Reported-by: Houcheng Lin <houcheng@gmail.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7677e86843e2136a9b05549a9ca47d4f744565b6
  Author: Herbert Xu <herbert@gondor.apana.org.au>
  Date:   Sat Oct 4 22:18:02 2014 +0800
 =20
      bridge: Do not compile options in br_parse_ip_options
     =20
      Commit 462fb2af9788a82a534f8184abfde31574e1cfa0
     =20
      	bridge : Sanitize skb before it enters the IP stack
     =20
      broke when IP options are actually used because it mangles the
      skb as if it entered the IP stack which is wrong because the
      bridge is supposed to operate below the IP stack.
     =20
      Since nobody has actually requested for parsing of IP options
      this patch fixes it by simply reverting to the previous approach
      of ignoring all IP options, i.e., zeroing the IPCB.
     =20
      If and when somebody who uses IP options and actually needs them
      to be parsed by the bridge complains then we can revisit this.
     =20
      Reported-by: David Newall <davidn@davidnewall.com>
      Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
      Tested-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7f2ac8fb31896c9fb70dbd2a2e6642b79996fc13
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Thu Oct 23 08:53:21 2014 +0300
 =20
      iwlwifi: pcie: fix polling in various places
     =20
      iwl_poll_bit may return a strictly positive value when the
      poll doesn't match on the first try.
      This was caught when WoWLAN started failing upon resume
      even if the poll_bit actually succeeded.
     =20
      Also change a wrong print. If we reach the end of
      iwl_pcie_prepare_card_hw, it means that we couldn't
      get the devices.
     =20
      Reviewed-by: Johannes Berg <johannes.berg@intel.com>
      Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 1ffde699aae127e7abdb98dbdedc2cc6a973a1a1
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Oct 20 08:29:55 2014 +0300
 =20
      Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate"
     =20
      This reverts commit aa11bbf3df026d6b1c6b528bef634fd9de7c2619.
      This commit was causing connection issues and is not needed
      if IWL_MVM_RS_RSSI_BASED_INIT_RATE is set to false by default.
     =20
      Regardless of the issues mentioned above, this patch added the
      following WARNING:
     =20
      WARNING: CPU: 0 PID: 3946 at drivers/net/wireless/iwlwifi/mvm/tx.c:19=
0 iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]()
      Got an HT rate for a non data frame 0x8
      CPU: 0 PID: 3946 Comm: wpa_supplicant Tainted: G           O   3.17.0=
+ #6
      Hardware name: LENOVO 20ANCTO1WW/20ANCTO1WW, BIOS GLET71WW (2.25 ) 07=
/02/2014
       0000000000000009 ffffffff814fa911 ffff8804288db8f8 ffffffff81064f52
       0000000000001808 ffff8804288db948 ffff88040add8660 ffff8804291b5600
       0000000000000000 ffffffff81064fb7 ffffffffa07b73d0 0000000000000020
      Call Trace:
       [<ffffffff814fa911>] ? dump_stack+0x41/0x51
       [<ffffffff81064f52>] ? warn_slowpath_common+0x72/0x90
       [<ffffffff81064fb7>] ? warn_slowpath_fmt+0x47/0x50
       [<ffffffffa07a39ea>] ? iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]
       [<ffffffffa07a3cf8>] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm]
       [<ffffffffa079cb9b>] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm]
       [<ffffffffa0746ce9>] ? __ieee80211_tx+0x2b9/0x3c0 [mac80211]
       [<ffffffffa07492f3>] ? ieee80211_tx+0xb3/0x100 [mac80211]
       [<ffffffffa0749c49>] ? ieee80211_subif_start_xmit+0x459/0xca0 [mac80=
211]
       [<ffffffff814116e7>] ? dev_hard_start_xmit+0x337/0x5f0
       [<ffffffff81430d46>] ? sch_direct_xmit+0x96/0x1f0
       [<ffffffff81411ba3>] ? __dev_queue_xmit+0x203/0x4f0
       [<ffffffff8142f670>] ? ether_setup+0x70/0x70
       [<ffffffff814e96a1>] ? packet_sendmsg+0xf81/0x1110
       [<ffffffff8140625c>] ? skb_free_datagram+0xc/0x40
       [<ffffffff813f7538>] ? sock_sendmsg+0x88/0xc0
       [<ffffffff813f7274>] ? move_addr_to_kernel.part.20+0x14/0x60
       [<ffffffff811c47c2>] ? __inode_wait_for_writeback+0x62/0xb0
       [<ffffffff813f7a91>] ? SYSC_sendto+0xf1/0x180
       [<ffffffff813f88f9>] ? __sys_recvmsg+0x39/0x70
       [<ffffffff8150066d>] ? system_call_fastpath+0x1a/0x1f
      ---[ end trace cc19a150d311fc63 ]---
     =20
      which was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=
=3D85691
     =20
      CC: <stable@vger.kernel.org> [3.13+]
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit a0855054e59b0c5b2b00237fdb5147f7bcc18efb
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Sun Oct 5 09:11:14 2014 +0300
 =20
      iwlwifi: dvm: drop non VO frames when flushing
     =20
      When mac80211 wants to ensure that a frame is sent, it calls
      the flush() callback. Until now, iwldvm implemented this by
      waiting that all the frames are sent (ACKed or timeout).
      In case of weak signal, this can take a significant amount
      of time, delaying the next connection (in case of roaming).
      Many users have reported that the flush would take too long
      leading to the following error messages to be printed:
     =20
      iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2
      iwlwifi 0000:03:00.0: Current SW read_ptr 161 write_ptr 201
      iwl data: 00000000: 00 00 00 00 00 00 00 00 fe ff 01 00 00 00 00 00
      [snip]
      iwlwifi 0000:03:00.0: FH TRBs(0) =3D 0x00000000
      [snip]
      iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x000=
0 [9,9]
      [snip]
     =20
      Instead of waiting for these packets, simply drop them. This
      significantly improves the responsiveness of the network.
      Note that all the queues are flushed, but the VO one. This
      is not typically used by the applications and it likely
      contains management frames that are useful for connection
      or roaming.
     =20
      This bug is tracked here:
      https://bugzilla.kernel.org/show_bug.cgi?id=3D56581
     =20
      But it is duplicated in distributions' trackers.
      A simple search in Ubuntu's database led to these bugs:
     =20
      https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1270808
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305406
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356236
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1360597
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361809
     =20
      Cc: <stable@vger.kernel.org>
      Depends-on: 77be2c54c5bd ("mac80211: add vif to flush call")
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit a6cc5163149532734b84c86cbffa4994e527074b
  Author: Matti Gottlieb <matti.gottlieb@intel.com>
  Date:   Mon Sep 29 11:46:04 2014 +0300
 =20
      iwlwifi: mvm: ROC - bug fixes around time events and locking
     =20
      Don't add the time event to the list. We added it several
      times the same time event, which leads to an infinite loop
      when walking the list.
     =20
      Since we (currently) don't support more than one ROC for STA
      vif at a time, enforce this and don't add the time event
      to any list.
     =20
      We were also missing the locking of the mutex which led to
      a lockdep splat - fix that.
     =20
      Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 79b7a69d730180d8bf535e52fe2b4f3dd5904007
  Author: Haim Dreyfuss <haim.dreyfuss@intel.com>
  Date:   Sun Sep 14 12:40:00 2014 +0300
 =20
      iwlwifi: mvm: Add tx power condition to bss_info_changed_ap_ibss
     =20
      The tx power should be limited from many reasons.
      currently, setting the tx power is available by the mvm only for
      station interface. Adding the tx power condition to
      bss_info_changed_ap_ibss make it available also for AP.
     =20
      Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 3856b78c1be32a2afe0618c7a84e05ff8c03cf10
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Sep 22 12:03:41 2014 +0300
 =20
      iwlwifi: mvm: BT coex - fix BT prio for probe requests
     =20
      The probe requests sent during scan must get BT prio 3.
      Fix that.
     =20
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit d14b28fd2c61af0bf310230472e342864d799c98
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Mon Sep 22 16:12:24 2014 +0300
 =20
      iwlwifi: mvm: BT Coex - update the MPLUT Boost register value
     =20
      Cc: <stable@vger.kernel.org> [3.16+]
      Fixes: 2adc8949efab ("iwlwifi: mvm: BT Coex - fix boost register / LU=
T values")
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 405b7338abc5ceac4a420ce7f49cc9b530d4e78b
  Author: Liad Kaufman <liad.kaufman@intel.com>
  Date:   Tue Sep 23 15:15:17 2014 +0300
 =20
      iwlwifi: 8000: fix string given to MODULE_FIRMWARE
     =20
      I changed the string but forgot to update the fix also to
      MODULE_FIRMWARE().
     =20
      Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 9180ac50716a097a407c6d7e7e4589754a922260
  Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Date:   Tue Sep 23 23:02:41 2014 +0300
 =20
      iwlwifi: configure the LTR
     =20
      The LTR is the handshake between the device and the root
      complex about the latency allowed when the bus exits power
      save. This configuration was missing and this led to high
      latency in the link power up. The end user could experience
      high latency in the network because of this.
     =20
      Cc: <stable@vger.kernel.org> [3.10+]
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
 =20
  commit 08054200117a95afc14c3d2ed3a38bf4e345bf78
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Thu Oct 23 11:27:09 2014 -0500
 =20
      rtlwifi: Add check for get_btc_status callback
     =20
      Drivers that do not use the get_btc_status() callback may not define =
a
      dummy routine. The caller needs to check before making the call.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
      Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
      Cc: Thadeu Cascardo <cascardo@cascardo.eti.br>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 763254516187015cb5b391553af35c6ed1f4bb36
  Author: Felix Fietkau <nbd@openwrt.org>
  Date:   Wed Oct 22 18:17:35 2014 +0200
 =20
      ath9k_common: always update value in ath9k_cmn_update_txpow
     =20
      In some cases the limit may be the same as reg->power_limit, but the
      actual value that the hardware uses is not up to date. In that case, =
a
      wrong value for current tx power is tracked internally.
      Fix this by unconditionally updating it.
     =20
      Signed-off-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 4f2b244c7d5b81ce4f0c6c0382f3a3b7c2dbec1c
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:34 2014 +0200
 =20
      rtl8192cu: Prevent Ooops under rtl92c_set_fw_rsvdpagepkt
     =20
      rtl92c_set_fw_rsvdpagepkt is used by rtl8192cu and its pci sibling rt=
l8192ce.
      rtl_cmd_send_packet crashes when called inside rtl8192cu because it w=
orks on
      memory allocated only by rtl8192ce.
      Fix the crash by calling a dummy function when used in rtl8192cu.
      Comparision with the realtek vendor driver makes me think, something =
is missing in
      the dummy function.
      Short test as WPA2 station show good results connected to an 802.11g =
basestation.
      Traffic stops after few MBytes as WPA2 station connected to an 802.11=
n basestation.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit cefe3dfdb9f5f498cae9871f7e52800f5e22c614
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:33 2014 +0200
 =20
      rtl8192cu: Call ieee80211_register_hw from rtl_usb_probe
     =20
      In a previous patch the call to ieee80211_register_hw was moved from =
the
      load firmware callback to the rtl_pci_probe only.
      rt8192cu also uses this callback. Currently it doesnt create a wlan%d=
 device.
      Fill in the call to ieee80211_register_hw in rtl_usb_probe.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit b2d624a5810203a1a8b7735e1ec5685109b22fc3
  Author: Karsten Wiese <fzuuzf@googlemail.com>
  Date:   Wed Oct 22 15:47:32 2014 +0200
 =20
      rtl8192cu: Fix for rtlwifi's bluetooth coexist functionality
     =20
      Initialize function pointer with a function indicating bt coexist is =
not there.
      Prevents Ooops.
     =20
      Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 94e05900770c0abe31200881df93e41d296fe8bd
  Author: Felix Fietkau <nbd@openwrt.org>
  Date:   Wed Oct 22 15:27:53 2014 +0200
 =20
      ath: use CTL region from cfg80211 if unset in EEPROM
     =20
      Many AP devices do not have the proper regulatory domain programmed i=
n
      EEPROM. Instead they expect the software to set the appropriate regio=
n.
      For these devices, the country code defaults to US, and the driver us=
es
      the US CTL tables as well.
      On devices bought in Europe this can lead to tx power being set too h=
igh
      on the band edges, even if the cfg80211 regdomain is set correctly.
      Fix this issue by taking into account the DFS region, but only when t=
he
      EEPROM regdomain is set to default.
     =20
      Signed-off-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit d514aefb8ce89562ef2d7dcddc530e5de6287c4b
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Tue Oct 21 10:52:51 2014 -0500
 =20
      rtlwifi: rtl8821ae: Fix possible array overrun
     =20
      The kbuild test robot reported a possible array overrun. The affected=
 code
      checks for overruns, but fails to take the steps necessary to fix the=
m.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 868caae3fe2e35e2353d86af95e03eeaa9439d97
  Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Date:   Tue Oct 21 19:23:02 2014 +0530
 =20
      ath9k: Enable HW queue control only for MCC
     =20
      Enabling HW queue control for normal (non-mcc) mode
      causes problems with queue management, resulting
      in traffic stall. Since it is mainly required for
      fairness in MCC mode, disable it for the general case.
     =20
      Bug: https://dev.openwrt.org/ticket/18164
     =20
      Cc: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 598a0df07fc6c4642f9b0497cef1233e41d4c987
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Oct 20 14:57:08 2014 -0700
 =20
      rtlwifi: prevent format string usage from leaking
     =20
      Use "%s" in the workqueue allocation to make sure the rtl_hal_cfg nam=
e
      can never accidentally leak information via a format string.
     =20
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 34b6d4299923ec9101bbf364440cee36420b3fc0
  Author: Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
  Date:   Wed Oct 15 07:51:44 2014 +0200
 =20
      bcma: add another PCI ID of device with BCM43228
     =20
      It was found attached to the BCM47081A0 SoC. Log:
      bcma: bus0: Found chip with id 43228, rev 0x00 and package 0x08
     =20
      Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 59dfdd92288e55bed374309a9944c3a95b4e13c9
  Author: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
  Date:   Sun Oct 12 13:42:14 2014 +0200
 =20
      brcmfmac: dhd_sdio.c: Cleaning up missing null-terminate in conjuncti=
on with strncpy
     =20
      Replacing strncpy with strlcpy to avoid strings that lacks null termi=
nate.
      And changed from using strncat to strlcat to simplify code.
     =20
      Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigit=
al.se>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 47481d977cb2987ab363202c68a79ec1bccd357c
  Author: Larry Finger <Larry.Finger@lwfinger.net>
  Date:   Sat Oct 11 12:59:53 2014 -0500
 =20
      rtlwifi: rtl8192ee: Prevent log spamming for switch statements
     =20
      The driver logs a message when the default branch of switch statement=
s are
      taken. Such information is useful when debugging, but these log items=
 should
      not be seen for standard usage.
     =20
      Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 78afe83c3b008e25123bd1be36ee4b6595e595d1
  Author: Hauke Mehrtens <hauke@hauke-m.de>
  Date:   Thu Oct 9 23:39:41 2014 +0200
 =20
      bcma: fix build when CONFIG_OF_ADDRESS is not set
     =20
      Commit 2101e533f41a ("bcma: register bcma as device tree driver")
      introduces a hard dependency on OF_ADDRESS into the bcma driver.
      OF_ADDRESS is specifically disabled for the sparc architecture.
      This results in the following error when building sparc64:allmodconfi=
g.
     =20
      drivers/bcma/main.c: In function 'bcma_of_find_child_device':
      drivers/bcma/main.c:150:3: error: implicit declaration of function 'o=
f_translate_address'
     =20
      Fixes: 2101e533f41a ("bcma: register bcma as device tree driver")
      Reported-by: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: John W. Linville <linville@tuxdriver.com>
 =20
  commit 942396b01989d54977120f3625e5ba31afe7a75c
  Author: Haiyang Zhang <haiyangz@microsoft.com>
  Date:   Wed Oct 22 13:47:18 2014 -0700
 =20
      hyperv: Fix the total_data_buflen in send path
     =20
      total_data_buflen is used by netvsc_send() to decide if a packet can =
be put
      into send buffer. It should also include the size of RNDIS message be=
fore the
      Ethernet frame. Otherwise, a messge with total size bigger than send_=
section_size
      may be copied into the send buffer, and cause data corruption.
     =20
      [Request to include this patch to the Stable branches]
     =20
      Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
      Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f765678e325b4ae3e2fbdb304fc2d5ee018aa860
  Merge: 81f35ff 55ca6bc
  Author: David S. Miller <davem@davemloft.net>
  Date:   Wed Oct 22 17:50:39 2014 -0400
 =20
      Merge branch 'amd-xgbe'
     =20
      Tom Lendacky says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      amd-xgbe: AMD XGBE driver fixes 2014-10-22
     =20
      The following series of patches includes fixes to the driver.
     =20
      - Properly handle feature changes via ethtool by using correctly size=
d
        variables
      - Perform proper napi packet counting and budget checking
     =20
      This patch series is based on net.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 55ca6bcd733b739d5667d48d7591899f376dcfb8
  Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Date:   Wed Oct 22 11:26:17 2014 -0500
 =20
      amd-xgbe: Fix napi Rx budget accounting
     =20
      Currently the amd-xgbe driver increments the packets processed counte=
r
      each time a descriptor is processed.  Since a packet can be represent=
ed
      by more than one descriptor incrementing the counter in this way is n=
ot
      appropriate.  Also, since multiple descriptors cause the budget check
      to be short circuited, sometimes the returned value from the poll
      function would be larger than the budget value resulting in a WARN_ON=
CE
      being triggered.
     =20
      Update the polling logic to properly account for the number of packet=
s
      processed and exit when the budget value is reached.
     =20
      Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 386f1c9650b7fe4849d2942bd42f41f0ca3aedfb
  Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
  Date:   Wed Oct 22 11:26:11 2014 -0500
 =20
      amd-xgbe: Properly handle feature changes via ethtool
     =20
      The ndo_set_features callback function was improperly using an unsign=
ed
      int to save the current feature value for features such as NETIF_F_RX=
CSUM.
      Since that feature is in the upper 32 bits of a 64 bit variable the
      result was always 0 making it not possible to actually turn off the
      hardware RX checksum support.  Change the unsigned int type to the
      netdev_features_t type in order to properly capture the current value
      and perform the proper operation.
     =20
      Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 81f35ffde0e95ee18de83646bbf93dda55d9cc8b
  Author: Philipp Zabel <p.zabel@pengutronix.de>
  Date:   Wed Oct 22 16:34:35 2014 +0200
 =20
      net: fec: ptp: fix NULL pointer dereference if ptp_clock is not set
     =20
      Since commit 278d24047891 (net: fec: ptp: Enable PPS output based on =
ptp clock)
      fec_enet_interrupt calls fec_ptp_check_pps_event unconditionally, whi=
ch calls
      into ptp_clock_event. If fep->ptp_clock is NULL, ptp_clock_event trie=
s to
      dereference the NULL pointer.
      Since on i.MX53 fep->bufdesc_ex is not set, fec_ptp_init is never cal=
led,
      and fep->ptp_clock is NULL, which reliably causes a kernel panic.
     =20
      This patch adds a check for fep->ptp_clock =3D=3D NULL in fec_enet_in=
terrupt.
     =20
      Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 9e7ceb060754f134231f68cb29d5db31419fe1ed
  Author: Sathya Perla <sathya.perla@emulex.com>
  Date:   Wed Oct 22 21:42:01 2014 +0530
 =20
      net: fix saving TX flow hash in sock for outgoing connections
     =20
      The commit "net: Save TX flow hash in sock and set in skbuf on xmit"
      introduced the inet_set_txhash() and ip6_set_txhash() routines to cal=
culate
      and record flow hash(sk_txhash) in the socket structure. sk_txhash is=
 used
      to set skb->hash which is used to spread flows across multiple TXQs.
     =20
      But, the above routines are invoked before the source port of the con=
nection
      is created. Because of this all outgoing connections that just differ=
 in the
      source port get hashed into the same TXQ.
     =20
      This patch fixes this problem for IPv4/6 by invoking the the above ro=
utines
      after the source port is available for the socket.
     =20
      Fixes: b73c3d0e4("net: Save TX flow hash in sock and set in skbuf on =
xmit")
     =20
      Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
      Acked-by: Eric Dumazet <edumazet@google.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 789f202326640814c52f82e80cef3584d8254623
  Author: Li RongQing <roy.qing.li@gmail.com>
  Date:   Wed Oct 22 17:09:53 2014 +0800
 =20
      xfrm6: fix a potential use after free in xfrm6_policy.c
     =20
      pskb_may_pull() maybe change skb->data and make nh and exthdr pointer
      oboslete, so recompute the nd and exthdr
     =20
      Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8751b12cd93cc37337256f650e309b8364d40b35
  Author: LEROY Christophe <christophe.leroy@c-s.fr>
  Date:   Wed Oct 22 09:05:47 2014 +0200
 =20
      net: fs_enet: set back promiscuity mode after restart
     =20
      After interface restart (eg: after link disconnection/reconnection), =
the bridge
      function doesn't work anymore. This is due to the promiscuous mode be=
ing cleared
      by the restart.
     =20
      The mac-fcc already includes code to set the promiscuous mode back du=
ring the restart.
      This patch adds the same handling to mac-fec and mac-scc.
     =20
      Tested with bridge function on MPC885 with FEC.
     =20
      Reported-by: Germain Montoies <germain.montoies@c-s.fr>
      Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit a63ba13eec092b70d4e5522d692eaeb2f9747387
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Tue Oct 21 16:06:05 2014 +0200
 =20
      net: tso: fix unaligned access to crafted TCP header in helper API
     =20
      The crafted header start address is from a driver supplied buffer, wh=
ich
      one can reasonably expect to be aligned on a 4-bytes boundary.
      However ATM the TSO helper API is only used by ethernet drivers and
      the tcp header will then be aligned to a 2-bytes only boundary from t=
he
      header start address.
     =20
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 8fc963515e893867330dec87464e9edc5204c024
  Author: Jon Cooper <jcooper@solarflare.com>
  Date:   Tue Oct 21 14:50:29 2014 +0100
 =20
      sfc: remove incorrect EFX_BUG_ON_PARANOID check
     =20
      write_count and insert_count can wrap around, making > check invalid.
     =20
      Fixes: 70b33fb0ddec827cbbd14cdc664fc27b2ef4a6b6 ("sfc: add support fo=
r
       skb->xmit_more").
     =20
      Signed-off-by: Edward Cree <ecree@solarflare.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit c123bb7163043bb8f33858cf8e45b01c17dbd171
  Author: Sabrina Dubroca <sd@queasysnail.net>
  Date:   Tue Oct 21 11:08:21 2014 +0200
 =20
      netfilter: nf_tables: check for NULL in nf_tables_newchain pcpu stats=
 allocation
     =20
      alloc_percpu returns NULL on failure, not a negative error code.
     =20
      Fixes: ff3cd7b3c922 ("netfilter: nf_tables: refactor chain statistic =
routines")
      Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 0f9f5e1b83abd2b37c67658e02a6fc9001831fa5
  Author: Dan Carpenter <dan.carpenter@oracle.com>
  Date:   Tue Oct 21 11:28:12 2014 +0300
 =20
      netfilter: ipset: off by one in ip_set_nfnl_get_byindex()
     =20
      The ->ip_set_list[] array is initialized in ip_set_net_init() and it
      has ->ip_set_max elements so this check should be >=3D instead of >
      otherwise we are off by one.
     =20
      Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
      Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit e37ad9fd636071e45368d1d9cc3b7b421281ce7f
  Author: Marcelo Leitner <mleitner@redhat.com>
  Date:   Mon Oct 13 13:09:28 2014 -0300
 =20
      netfilter: nf_conntrack: allow server to become a client in TW handli=
ng
     =20
      When a port that was used to listen for inbound connections gets clos=
ed
      and reused for outgoing connections (like rsh ends up doing for stder=
r
      flow), current we may reject the SYN/ACK packet for the new connectio=
n
      because tcp_conntracks states forbirds a port to become a client whil=
e
      there is still a TIME_WAIT entry in there for it.
     =20
      As TCP may expire the TIME_WAIT socket in 60s and conntrack's timeout
      for it is 120s, there is a ~60s window that the application can end u=
p
      opening a port that conntrack will end up blocking.
     =20
      This patch fixes this by simply allowing such state transition: if we
      see a SYN, in TIME_WAIT state, on REPLY direction, move it to sSS. No=
te
      that the rest of the code already handles this situation, more
      specificly in tcp_packet(), first switch clause.
     =20
      Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
      Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 7c1c97d54f9bfc810908d3903cb8bcacf734df18
  Author: Sabrina Dubroca <sd@queasysnail.net>
  Date:   Tue Oct 21 11:23:30 2014 +0200
 =20
      net: sched: initialize bstats syncp
     =20
      Use netdev_alloc_pcpu_stats to allocate percpu stats and initialize s=
yncp.
     =20
      Fixes: 22e0f8b9322c "net: sched: make bstats per cpu and estimator RC=
U safe"
      Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
      Acked-by: Cong Wang <cwang@twopensource.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 32bf08a6257b9c7380dcd040af3c0858eee3ef05
  Author: Alexei Starovoitov <ast@plumgrid.com>
  Date:   Mon Oct 20 14:54:57 2014 -0700
 =20
      bpf: fix bug in eBPF verifier
     =20
      while comparing for verifier state equivalency the comparison
      was missing a check for uninitialized register.
      Make sure it does so and add a testcase.
     =20
      Fixes: f1bca824dabb ("bpf: add search pruning optimization to verifie=
r")
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
      Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 78fd1d0ab072d4d9b5f0b7c14a1516665170b565
  Author: Thomas Graf <tgraf@suug.ch>
  Date:   Tue Oct 21 22:05:38 2014 +0200
 =20
      netlink: Re-add locking to netlink_lookup() and seq walker
     =20
      The synchronize_rcu() in netlink_release() introduces unacceptable
      latency. Reintroduce minimal lookup so we can drop the
      synchronize_rcu() until socket destruction has been RCUfied.
     =20
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
      Reported-and-tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: Thomas Graf <tgraf@suug.ch>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1a194c2d59c55c37cb4c0c459d5418071a141341
  Author: Ying Xue <ying.xue@windriver.com>
  Date:   Mon Oct 20 14:46:35 2014 +0800
 =20
      tipc: fix lockdep warning when intra-node messages are delivered
     =20
      When running tipcTC&tipcTS test suite, below lockdep unsafe locking
      scenario is reported:
     =20
      [ 1109.997854]
      [ 1109.997988] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      [ 1109.998290] [ INFO: inconsistent lock state ]
      [ 1109.998575] 3.17.0-rc1+ #113 Not tainted
      [ 1109.998762] ---------------------------------
      [ 1109.998762] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [ 1109.998762] swapper/7/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [ 1109.998762]  (slock-AF_TIPC){+.?...}, at: [<ffffffffa0011969>] tip=
c_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762] {SOFTIRQ-ON-W} state was registered at:
      [ 1109.998762]   [<ffffffff810a4770>] __lock_acquire+0x6a0/0x1d80
      [ 1109.998762]   [<ffffffff810a6555>] lock_acquire+0x95/0x1e0
      [ 1109.998762]   [<ffffffff81a2d1ce>] _raw_spin_lock+0x3e/0x80
      [ 1109.998762]   [<ffffffffa0011969>] tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]   [<ffffffffa0004fe8>] tipc_link_xmit+0xa8/0xc0 [tipc]
      [ 1109.998762]   [<ffffffffa000ec6f>] tipc_sendmsg+0x15f/0x550 [tipc]
      [ 1109.998762]   [<ffffffffa000f165>] tipc_connect+0x105/0x140 [tipc]
      [ 1109.998762]   [<ffffffff817676ee>] SYSC_connect+0xae/0xc0
      [ 1109.998762]   [<ffffffff81767b7e>] SyS_connect+0xe/0x10
      [ 1109.998762]   [<ffffffff817a9788>] compat_SyS_socketcall+0xb8/0x20=
0
      [ 1109.998762]   [<ffffffff81a306e5>] sysenter_dispatch+0x7/0x1f
      [ 1109.998762] irq event stamp: 241060
      [ 1109.998762] hardirqs last  enabled at (241060): [<ffffffff8105a4ad=
>] __local_bh_enable_ip+0x6d/0xd0
      [ 1109.998762] hardirqs last disabled at (241059): [<ffffffff8105a46f=
>] __local_bh_enable_ip+0x2f/0xd0
      [ 1109.998762] softirqs last  enabled at (241020): [<ffffffff81059a52=
>] _local_bh_enable+0x22/0x50
      [ 1109.998762] softirqs last disabled at (241021): [<ffffffff8105a626=
>] irq_exit+0x96/0xc0
      [ 1109.998762]
      [ 1109.998762] other info that might help us debug this:
      [ 1109.998762]  Possible unsafe locking scenario:
      [ 1109.998762]
      [ 1109.998762]        CPU0
      [ 1109.998762]        ----
      [ 1109.998762]   lock(slock-AF_TIPC);
      [ 1109.998762]   <Interrupt>
      [ 1109.998762]     lock(slock-AF_TIPC);
      [ 1109.998762]
      [ 1109.998762]  *** DEADLOCK ***
      [ 1109.998762]
      [ 1109.998762] 2 locks held by swapper/7/0:
      [ 1109.998762]  #0:  (rcu_read_lock){......}, at: [<ffffffff81782dc9>=
] __netif_receive_skb_core+0x69/0xb70
      [ 1109.998762]  #1:  (rcu_read_lock){......}, at: [<ffffffffa0001c90>=
] tipc_l2_rcv_msg+0x40/0x260 [tipc]
      [ 1109.998762]
      [ 1109.998762] stack backtrace:
      [ 1109.998762] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.17.0-rc1+ =
#113
      [ 1109.998762] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [ 1109.998762]  ffffffff82745830 ffff880016c03828 ffffffff81a209eb 00=
00000000000007
      [ 1109.998762]  ffff880017b3cac0 ffff880016c03888 ffffffff81a1c5ef 00=
00000000000001
      [ 1109.998762]  ffff880000000001 ffff880000000000 ffffffff81012d4f 00=
00000000000000
      [ 1109.998762] Call Trace:
      [ 1109.998762]  <IRQ>  [<ffffffff81a209eb>] dump_stack+0x4e/0x68
      [ 1109.998762]  [<ffffffff81a1c5ef>] print_usage_bug+0x1f1/0x202
      [ 1109.998762]  [<ffffffff81012d4f>] ? save_stack_trace+0x2f/0x50
      [ 1109.998762]  [<ffffffff810a406c>] mark_lock+0x28c/0x2f0
      [ 1109.998762]  [<ffffffff810a3440>] ? print_irq_inversion_bug.part.4=
6+0x1f0/0x1f0
      [ 1109.998762]  [<ffffffff810a467d>] __lock_acquire+0x5ad/0x1d80
      [ 1109.998762]  [<ffffffff810a70dd>] ? trace_hardirqs_on+0xd/0x10
      [ 1109.998762]  [<ffffffff8108ace8>] ? sched_clock_cpu+0x98/0xc0
      [ 1109.998762]  [<ffffffff8108ad2b>] ? local_clock+0x1b/0x30
      [ 1109.998762]  [<ffffffff810a10dc>] ? lock_release_holdtime.part.29+=
0x1c/0x1a0
      [ 1109.998762]  [<ffffffff8108aa05>] ? sched_clock_local+0x25/0x90
      [ 1109.998762]  [<ffffffffa000dec0>] ? tipc_sk_get+0x60/0x80 [tipc]
      [ 1109.998762]  [<ffffffff810a6555>] lock_acquire+0x95/0x1e0
      [ 1109.998762]  [<ffffffffa0011969>] ? tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffff810a6fb6>] ? trace_hardirqs_on_caller+0xa6/=
0x1c0
      [ 1109.998762]  [<ffffffff81a2d1ce>] _raw_spin_lock+0x3e/0x80
      [ 1109.998762]  [<ffffffffa0011969>] ? tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffffa000dec0>] ? tipc_sk_get+0x60/0x80 [tipc]
      [ 1109.998762]  [<ffffffffa0011969>] tipc_sk_rcv+0x49/0x2b0 [tipc]
      [ 1109.998762]  [<ffffffffa00076bd>] tipc_rcv+0x5ed/0x960 [tipc]
      [ 1109.998762]  [<ffffffffa0001d1c>] tipc_l2_rcv_msg+0xcc/0x260 [tipc=
]
      [ 1109.998762]  [<ffffffffa0001c90>] ? tipc_l2_rcv_msg+0x40/0x260 [ti=
pc]
      [ 1109.998762]  [<ffffffff81783345>] __netif_receive_skb_core+0x5e5/0=
xb70
      [ 1109.998762]  [<ffffffff81782dc9>] ? __netif_receive_skb_core+0x69/=
0xb70
      [ 1109.998762]  [<ffffffff81784eb9>] ? dev_gro_receive+0x259/0x4e0
      [ 1109.998762]  [<ffffffff817838f6>] __netif_receive_skb+0x26/0x70
      [ 1109.998762]  [<ffffffff81783acd>] netif_receive_skb_internal+0x2d/=
0x1f0
      [ 1109.998762]  [<ffffffff81785518>] napi_gro_receive+0xd8/0x240
      [ 1109.998762]  [<ffffffff815bf854>] e1000_clean_rx_irq+0x2c4/0x530
      [ 1109.998762]  [<ffffffff815c1a46>] e1000_clean+0x266/0x9c0
      [ 1109.998762]  [<ffffffff8108ad2b>] ? local_clock+0x1b/0x30
      [ 1109.998762]  [<ffffffff8108aa05>] ? sched_clock_local+0x25/0x90
      [ 1109.998762]  [<ffffffff817842b1>] net_rx_action+0x141/0x310
      [ 1109.998762]  [<ffffffff810bd710>] ? handle_fasteoi_irq+0xe0/0x150
      [ 1109.998762]  [<ffffffff81059fa6>] __do_softirq+0x116/0x4d0
      [ 1109.998762]  [<ffffffff8105a626>] irq_exit+0x96/0xc0
      [ 1109.998762]  [<ffffffff81a30d07>] do_IRQ+0x67/0x110
      [ 1109.998762]  [<ffffffff81a2ee2f>] common_interrupt+0x6f/0x6f
      [ 1109.998762]  <EOI>  [<ffffffff8100d2b7>] ? default_idle+0x37/0x250
      [ 1109.998762]  [<ffffffff8100d2b5>] ? default_idle+0x35/0x250
      [ 1109.998762]  [<ffffffff8100dd1f>] arch_cpu_idle+0xf/0x20
      [ 1109.998762]  [<ffffffff810999fd>] cpu_startup_entry+0x27d/0x4d0
      [ 1109.998762]  [<ffffffff81034c78>] start_secondary+0x188/0x1f0
     =20
      When intra-node messages are delivered from one process to another
      process, tipc_link_xmit() doesn't disable BH before it directly calls
      tipc_sk_rcv() on process context to forward messages to destination
      socket. Meanwhile, if messages delivered by remote node arrive at the
      node and their destinations are also the same socket, tipc_sk_rcv()
      running on process context might be preempted by tipc_sk_rcv() runnin=
g
      BH context. As a result, the latter cannot obtain the socket lock as
      the lock was obtained by the former, however, the former has no chanc=
e
      to be run as the latter is owning the CPU now, so headlock happens. T=
o
      avoid it, BH should be always disabled in tipc_sk_rcv().
     =20
      Signed-off-by: Ying Xue <ying.xue@windriver.com>
      Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 7b8613e0a1502b43b3b36c93c66f835c891f63b3
  Author: Ying Xue <ying.xue@windriver.com>
  Date:   Mon Oct 20 14:44:25 2014 +0800
 =20
      tipc: fix a potential deadlock
     =20
      Locking dependency detected below possible unsafe locking scenario:
     =20
                 CPU0                          CPU1
      T0:  tipc_named_rcv()                tipc_rcv()
      T1:  [grab nametble write lock]*     [grab node lock]*
      T2:  tipc_update_nametbl()           tipc_node_link_up()
      T3:  tipc_nodesub_subscribe()        tipc_nametbl_publish()
      T4:  [grab node lock]*               [grab nametble write lock]*
     =20
      The opposite order of holding nametbl write lock and node lock on
      above two different paths may result in a deadlock. If we move the
      the updating of the name table after link state named out of node
      lock, the reverse order of holding locks will be eliminated, and
      as a result, the deadlock risk.
     =20
      Signed-off-by: Ying Xue <ying.xue@windriver.com>
      Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 73829bf6fec70703f10e360676d81d327f21ebf6
  Merge: d10845f 39dc90c
  Author: David S. Miller <davem@davemloft.net>
  Date:   Tue Oct 21 15:24:30 2014 -0400
 =20
      Merge branch 'enic'
     =20
      Govindarajulu Varadarajan says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      enic: Bug fixes
     =20
      This series fixes the following problem.
     =20
      Please apply this to net.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 39dc90c159c1bcc0fdd42913a7d560b1a1cd3acf
  Author: Govindarajulu Varadarajan <_govind@gmx.com>
  Date:   Sun Oct 19 14:20:28 2014 +0530
 =20
      enic: Do not call napi_disable when preemption is disabled.
     =20
      In enic_stop, we disable preemption using local_bh_disable(). We disa=
ble
      preemption to wait for busy_poll to finish.
     =20
      napi_disable should not be called here as it might sleep.
     =20
      Moving napi_disable() call out side of local_bh_disable.
     =20
      BUG: sleeping function called from invalid context at include/linux/n=
etdevice.h:477
      in_atomic(): 1, irqs_disabled(): 0, pid: 443, name: ifconfig
      INFO: lockdep is turned off.
      Preemption disabled at:[<ffffffffa029c5c4>] enic_rfs_flw_tbl_free+0x3=
4/0xd0 [enic]
     =20
      CPU: 31 PID: 443 Comm: ifconfig Not tainted 3.17.0-netnext-05504-g59f=
35b8 #268
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       ffff8800dac10000 ffff88020b8dfcb8 ffffffff8148a57c 0000000000000000
       ffff88020b8dfcd0 ffffffff8107e253 ffff8800dac12a40 ffff88020b8dfd10
       ffffffffa029305b ffff88020b8dfd48 ffff8800dac10000 ffff88020b8dfd48
      Call Trace:
       [<ffffffff8148a57c>] dump_stack+0x4e/0x7a
       [<ffffffff8107e253>] __might_sleep+0x123/0x1a0
       [<ffffffffa029305b>] enic_stop+0xdb/0x4d0 [enic]
       [<ffffffff8138ed7d>] __dev_close_many+0x9d/0xf0
       [<ffffffff8138ef81>] __dev_close+0x31/0x50
       [<ffffffff813974a8>] __dev_change_flags+0x98/0x160
       [<ffffffff81397594>] dev_change_flags+0x24/0x60
       [<ffffffff814085fd>] devinet_ioctl+0x63d/0x710
       [<ffffffff81139c16>] ? might_fault+0x56/0xc0
       [<ffffffff81409ef5>] inet_ioctl+0x65/0x90
       [<ffffffff813768e0>] sock_do_ioctl+0x20/0x50
       [<ffffffff81376ebb>] sock_ioctl+0x20b/0x2e0
       [<ffffffff81197250>] do_vfs_ioctl+0x2e0/0x500
       [<ffffffff81492619>] ? sysret_check+0x22/0x5d
       [<ffffffff81285f23>] ? __this_cpu_preempt_check+0x13/0x20
       [<ffffffff8109fe19>] ? trace_hardirqs_on_caller+0x119/0x270
       [<ffffffff811974ac>] SyS_ioctl+0x3c/0x80
       [<ffffffff814925ed>] system_call_fastpath+0x1a/0x1f
     =20
      Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit b6931c9ba728d60c542c39ff037fe6f595c074a2
  Author: Govindarajulu Varadarajan <_govind@gmx.com>
  Date:   Sun Oct 19 14:20:27 2014 +0530
 =20
      enic: fix possible deadlock in enic_stop/ enic_rfs_flw_tbl_free
     =20
      The following warning is shown when spinlock debug is enabled.
     =20
      This occurs when enic_flow_may_expire timer function is running and
      enic_stop is called on same CPU.
     =20
      Fix this by using spink_lock_bh().
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      [ INFO: inconsistent lock state ]
      3.17.0-netnext-05504-g59f35b8 #268 Not tainted
      ---------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      ifconfig/443 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&enic->rfs_h.lock)->rlock){+.?...}, at:
      enic_rfs_flw_tbl_free+0x34/0xd0 [enic]
      {IN-SOFTIRQ-W} state was registered at:
        [<ffffffff810a25af>] __lock_acquire+0x83f/0x21c0
        [<ffffffff810a45f2>] lock_acquire+0xa2/0xd0
        [<ffffffff814913fc>] _raw_spin_lock+0x3c/0x80
        [<ffffffffa029c3d5>] enic_flow_may_expire+0x25/0x130[enic]
        [<ffffffff810bcd07>] call_timer_fn+0x77/0x100
        [<ffffffff810bd8e3>] run_timer_softirq+0x1e3/0x270
        [<ffffffff8105f9ae>] __do_softirq+0x14e/0x280
        [<ffffffff8105fdae>] irq_exit+0x8e/0xb0
        [<ffffffff8103da0f>] smp_apic_timer_interrupt+0x3f/0x50
        [<ffffffff81493742>] apic_timer_interrupt+0x72/0x80
        [<ffffffff81018143>] default_idle+0x13/0x20
        [<ffffffff81018a6a>] arch_cpu_idle+0xa/0x10
        [<ffffffff81097676>] cpu_startup_entry+0x2c6/0x330
        [<ffffffff8103b7ad>] start_secondary+0x21d/0x290
      irq event stamp: 2997
      hardirqs last  enabled at (2997): [<ffffffff81491865>] _raw_spin_unlo=
ck_irqrestore+0x65/0x90
      hardirqs last disabled at (2996): [<ffffffff814915e6>] _raw_spin_lock=
_irqsave+0x26/0x90
      softirqs last  enabled at (2968): [<ffffffff813b57a3>] dev_deactivate=
_many+0x213/0x260
      softirqs last disabled at (2966): [<ffffffff813b5783>] dev_deactivate=
_many+0x1f3/0x260
     =20
      other info that might help us debug this:
       Possible unsafe locking scenario:
     =20
             CPU0
             ----
        lock(&(&enic->rfs_h.lock)->rlock);
        <Interrupt>
          lock(&(&enic->rfs_h.lock)->rlock);
     =20
       *** DEADLOCK ***
     =20
      Reported-by: Jan Stancek <jstancek@redhat.com>
      Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit d10845fc85b2e690b5f6425c5ba4df33a073fbc9
  Merge: ce8ec48 f993bc2
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 20 12:38:19 2014 -0400
 =20
      Merge branch 'gso_encap_fixes'
     =20
      Florian Westphal says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      net: minor gso encapsulation fixes
     =20
      The following series fixes a minor bug in the gso segmentation handle=
rs
      when encapsulation offload is used.
     =20
      Theoretically this could cause kernel panic when the stack tries
      to software-segment such a GRE offload packet, but it looks like ther=
e
      is only one affected call site (tbf scheduler) and it handles NULL
      return value.
     =20
      I've included a followup patch to add IS_ERR_OR_NULL checks where nee=
ded.
     =20
      While looking into this, I also found that size computation of the in=
dividual
      segments is incorrect if skb->encapsulation is set.
     =20
      Please see individual patches for delta vs. v1.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit f993bc25e5196e60514c216d0bca0f600de64af8
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:18 2014 +0200
 =20
      net: core: handle encapsulation offloads when computing segment lengt=
hs
     =20
      if ->encapsulation is set we have to use inner_tcp_hdrlen and add the
      size of the inner network headers too.
     =20
      This is 'mostly harmless'; tbf might send skb that is slightly over
      quota or drop skb even if it would have fit.
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 330966e501ffe282d7184fde4518d5e0c24bc7f8
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:17 2014 +0200
 =20
      net: make skb_gso_segment error handling more robust
     =20
      skb_gso_segment has three possible return values:
      1. a pointer to the first segmented skb
      2. an errno value (IS_ERR())
      3. NULL.  This can happen when GSO is used for header verification.
     =20
      However, several callers currently test IS_ERR instead of IS_ERR_OR_N=
ULL
      and would oops when NULL is returned.
     =20
      Note that these call sites should never actually see such a NULL retu=
rn
      value; all callers mask out the GSO bits in the feature argument.
     =20
      However, there have been issues with some protocol handlers erronousl=
y not
      respecting the specified feature mask in some cases.
     =20
      It is preferable to get 'have to turn off hw offloading, else slow' r=
eports
      rather than 'kernel crashes'.
     =20
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e16aa3ddf863c6b9f37eddf52503230a62dedb3
  Author: Florian Westphal <fw@strlen.de>
  Date:   Mon Oct 20 13:49:16 2014 +0200
 =20
      net: gso: use feature flag argument in all protocol gso handlers
     =20
      skb_gso_segment() has a 'features' argument representing offload feat=
ures
      available to the output path.
     =20
      A few handlers, e.g. GRE, instead re-fetch the features of skb->dev a=
nd use
      those instead of the provided ones when handing encapsulation/tunnels=
.
     =20
      Depending on dev->hw_enc_features of the output device skb_gso_segmen=
t() can
      then return NULL even when the caller has disabled all GSO feature bi=
ts,
      as segmentation of inner header thinks device will take care of segme=
ntation.
     =20
      This e.g. affects the tbf scheduler, which will silently drop GRE-enc=
ap GSO skbs
      that did not fit the remaining token quota as the segmentation does n=
ot work
      when device supports corresponding hw offload capabilities.
     =20
      Cc: Pravin B Shelar <pshelar@nicira.com>
      Signed-off-by: Florian Westphal <fw@strlen.de>
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit ce8ec4896749783bd6cdc457e6012cfc18e09c8b
  Merge: 95ff886 1e2d56a
  Author: David S. Miller <davem@davemloft.net>
  Date:   Mon Oct 20 11:57:47 2014 -0400
 =20
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
     =20
      Pablo Neira Ayuso says:
     =20
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      netfilter fixes for net
     =20
      The following patchset contains netfilter fixes for your net tree,
      they are:
     =20
      1) Fix missing MODULE_LICENSE() in the new nf_reject_ipv{4,6} modules=
.
     =20
      2) Restrict nat and masq expressions to the nat chain type. Otherwise=
,
         users may crash their kernel if they attach a nat/masq rule to a n=
on
         nat chain.
     =20
      3) Fix hook validation in nft_compat when non-base chains are used.
         Basically, initialize hook_mask to zero.
     =20
      4) Make sure you use match/targets in nft_compat from the right chain
         type. The existing validation relies on the table name which can b=
e
         avoided by
     =20
      5) Better netlink attribute validation in nft_nat. This expression ha=
s
         to reject the configuration when no address and proto configuratio=
ns
         are specified.
     =20
      6) Interpret NFTA_NAT_REG_*_MAX if only if NFTA_NAT_REG_*_MIN is set.
         Yet another sanity check to reject incorrect configurations from
         userspace.
     =20
      7) Conditional NAT attribute dumping depending on the existing
         configuration.
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     =20
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 11b2357d5dbce999803e9055f8c09829a8a87db4
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Mon Oct 20 10:54:36 2014 +0200
 =20
      mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats
     =20
      ATM an HT rc_stats line is 106 chars.
      Times 8(MCS_GROUP_RATES)*3(SS)*2(GI)*2(BW) + CCK(4), i.e. x100, this =
is
      well above the current 8192 - sizeof(*ms) currently allocated.
     =20
      Fix this by squeezing the output as follows (not that we're short on
      memory but this also improves readability and range, the new format a=
dds
      one more digit to *ok/*cum and ok/cum):
     =20
      - Before (HT) (106 ch):
      type           rate     throughput  ewma prob   this prob  retry   th=
is succ/attempt   success    attempts
      CCK/LP          5.5M           0.0        0.0         0.0      0     =
         0(  0)         0           0
      HT20/LGI ABCDP MCS0            0.0        0.0         0.0      1     =
         0(  0)         0           0
      - After (75 ch):
      type           rate     tpt eprob *prob ret  *ok(*cum)        ok(    =
  cum)
      CCK/LP          5.5M    0.0   0.0   0.0   0    0(   0)         0(    =
    0)
      HT20/LGI ABCDP MCS0     0.0   0.0   0.0   1    0(   0)         0(    =
    0)
     =20
      - Align non-HT format Before (non-HT) (83 ch):
      rate      throughput  ewma prob  this prob  this succ/attempt   succe=
ss    attempts
      ABCDP  6         0.0        0.0        0.0             0(  0)        =
 0           0
            54         0.0        0.0        0.0             0(  0)        =
 0           0
      - After (61 ch):
      rate          tpt eprob *prob  *ok(*cum)        ok(      cum)
      ABCDP  1      0.0   0.0   0.0    0(   0)         0(        0)
            54      0.0   0.0   0.0    0(   0)         0(        0)
     =20
      *This also adds dynamic checks for overflow, lowers the size of the
      non-HT request (allowing > 30 entries) and replaces the buddy-rounded
      allocations (s/sizeof(*ms) + 8192/8192).
     =20
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Acked-by: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 95ff88688781db2f64042e69bd499e518bbb36e5
  Author: Ian Morgan <imorgan@primordial.ca>
  Date:   Sun Oct 19 08:05:13 2014 -0400
 =20
      ax88179_178a: fix bonding failure
     =20
      The following patch fixes a bug which causes the ax88179_178a driver =
to be
      incapable of being added to a bond.
     =20
      When I brought up the issue with the bonding maintainers, they indica=
ted
      that the real problem was with the NIC driver which must return zero =
for
      success (of setting the MAC address). I see that several other NIC dr=
ivers
      follow that pattern by either simply always returing zero, or by pass=
ing
      through a negative (error) result while rewriting any positive return=
 code
      to zero. With that same philisophy applied to the ax88179_178a driver=
, it
      allows it to work correctly with the bonding driver.
     =20
      I believe this is suitable for queuing in -stable, as it's a small, s=
imple,
      and obvious fix that corrects a defect with no other known workaround=
.
     =20
      This patch is against vanilla 3.17(.0).
     =20
      Signed-off-by: Ian Morgan <imorgan@primordial.ca>
     =20
       drivers/net/usb/ax88179_178a.c |    7 ++++++-
       1 file changed, 6 insertions(+), 1 deletion(-)
      Signed-off-by: David S. Miller <davem@davemloft.net>
 =20
  commit 1e2d56a5d33a7e1fcd21ed3859f52596d02708b0
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:24:14 2014 +0200
 =20
      netfilter: nft_nat: dump attributes if they are set
     =20
      Dump NFTA_NAT_REG_ADDR_MIN if this is non-zero. Same thing with
      NFTA_NAT_REG_PROTO_MIN.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 61cfac6b42af98ab46bcb3a47e150e7b20d5015e
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:19:35 2014 +0200
 =20
      netfilter: nft_nat: NFTA_NAT_REG_ADDR_MAX depends on NFTA_NAT_REG_ADD=
R_MIN
     =20
      Interpret NFTA_NAT_REG_ADDR_MAX if NFTA_NAT_REG_ADDR_MIN is present,
      otherwise, skip it. Same thing with NFTA_NAT_REG_PROTO_MAX.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 5c819a39753d6a3ae9c0092236f59730a369b619
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Thu Oct 16 00:16:57 2014 +0200
 =20
      netfilter: nft_nat: insufficient attribute validation
     =20
      We have to validate that we at least get an NFTA_NAT_REG_ADDR_MIN or
      NFTA_NFT_REG_PROTO_MIN attribute. Reject the configuration if none
      of them are present.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit f3f5ddeddd6aeadcef523d55ea9288e3d5c1cbc3
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Tue Oct 14 10:13:48 2014 +0200
 =20
      netfilter: nft_compat: validate chain type in match/target
     =20
      We have to validate the real chain type to ensure that matches/target=
s
      are not used out from their scope (eg. MASQUERADE in nat chain type).
      The existing validation relies on the table name, but this is not
      sufficient since userspace can fool us by using the appropriate table
      name with a different chain type.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 493618a92c6afdd3f6224ab586f169d6a259bb06
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Tue Oct 14 12:43:50 2014 +0200
 =20
      netfilter: nft_compat: fix hook validation for non-base chains
     =20
      Set hook_mask to zero for non-base chains, otherwise people may hit
      bogus errors from the xt_check_target() and xt_check_match() when
      validating the uninitialized hook_mask.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit c7abf25af0f41be4b50d44c5b185d52eea360cb8
  Author: Karl Beldan <karl.beldan@rivierawaves.com>
  Date:   Mon Oct 13 14:34:41 2014 +0200
 =20
      mac80211: fix typo in starting baserate for rts_cts_rate_idx
     =20
      It affects non-(V)HT rates and can lead to selecting an rts_cts rate
      that is not a basic rate or way superior to the reference rate (ATM
      rates[0] used for the 1st attempt of the protected frame data).
     =20
      E.g, assuming drivers register growing (bitrate) sorted tables of
      ieee80211_rate-s, having :
      - rates[0].idx =3D=3D d'2 and basic_rates =3D=3D b'10100
      will select rts_cts idx b'10011 & ~d'(BIT(2)-1), i.e. 1, likewise
      - rates[0].idx =3D=3D d'2 and basic_rates =3D=3D b'10001
      will select rts_cts idx b'10000
      The first is not a basic rate and the second is > rates[0].
     =20
      Also, wrt severity of the addressed misbehavior, ATM we only have one
      rts_cts_rate_idx rather than one per rate table entry, so this idx mi=
ght
      still point to bitrates > rates[1..MAX_RATES].
     =20
      Fixes: 5253ffb8c9e1 ("mac80211: always pick a basic rate to tx RTS/CT=
S for pre-HT rates")
      Cc: stable@vger.kernel.org
      Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 7210e4e38f945dfa173c4a4e59ad827c9ecad541
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Mon Oct 13 19:50:22 2014 +0200
 =20
      netfilter: nf_tables: restrict nat/masq expressions to nat chain type
     =20
      This adds the missing validation code to avoid the use of nat/masq fr=
om
      non-nat chains. The validation assumes two possible configuration
      scenarios:
     =20
      1) Use of nat from base chain that is not of nat type. Reject this
         configuration from the nft_*_init() path of the expression.
     =20
      2) Use of nat from non-base chain. In this case, we have to wait unti=
l
         the non-base chain is referenced by at least one base chain via
         jump/goto. This is resolved from the nft_*_validate() path which i=
s
         called from nf_tables_check_loops().
     =20
      The user gets an -EOPNOTSUPP in both cases.
     =20
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit ab2d7251d666995740da17b2a51ca545ac5dd037
  Author: Pablo Neira Ayuso <pablo@netfilter.org>
  Date:   Fri Oct 10 11:25:20 2014 +0200
 =20
      netfilter: missing module license in the nf_reject_ipvX modules
     =20
      [   23.545204] nf_reject_ipv4: module license 'unspecified' taints ke=
rnel.
     =20
      Fixes: c8d7b98 ("netfilter: move nf_send_resetX() code to nf_reject_i=
pvX modules")
      Reported-by: Dave Young <dyoung@redhat.com>
      Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
 =20
  commit 252e07ca5f64dd31fdfca8027287e7d75fefdab1
  Author: Luciano Coelho <luciano.coelho@intel.com>
  Date:   Wed Oct 8 09:48:34 2014 +0300
 =20
      nl80211: sanity check the channel switch counter value
     =20
      The nl80211 channel switch count attribute
      (NL80211_ATTR_CH_SWITCH_COUNT) is specified as u32, but the
      specification uses u8 for the counter.  To make sure strange things
      don't happen without informing the user, sanity check the value and
      return -EINVAL if it doesn't fit in u8.
     =20
      Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit bc37b16870a382e8b71d881444c19a16de1c1a7f
  Author: Fabian Frederick <fabf@skynet.be>
  Date:   Tue Oct 7 22:20:23 2014 +0200
 =20
      net: rfkill: kernel-doc warning fixes
     =20
      Correct the kernel-doc, the parameter is called "blocked" not "state"=
.
     =20
      Signed-off-by: Fabian Frederick <fabf@skynet.be>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit c12bc4885f4b3bab0ed779c69d5d7e3223fa5003
  Author: Luciano Coelho <luciano.coelho@intel.com>
  Date:   Tue Sep 30 07:08:02 2014 +0300
 =20
      mac80211: return the vif's chandef in ieee80211_cfg_get_channel()
     =20
      The chandef of the channel context a vif is using may be different
      than the chandef of the vif itself.  For instance, the bandwidth used
      by the vif may be narrower than the one configured in the channel
      context.  To avoid confusion, return the vif's chandef in
      ieee80211_cfg_get_channel() instead of the chandef of the channel
      context.
     =20
      Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 =20
  commit 8975ae88e137ea02a71b7a86af2f8eb790c2f1e7
  Author: Liad Kaufman <liad.kaufman@intel.com>
  Date:   Sun Sep 14 21:48:28 2014 +0300
 =20
      mac80211: fix warning on htmldocs for last_tdls_pkt_time
     =20
      Forgot to add an entry to the struct description of sta_info.
     =20
      Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
      Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Revision graph left in /home/xc_osstest/results/bisect.linux-linus.test-amd=
64-i386-rumpuserxen-i386.guest-start.{dot,ps,png,html}.
----------------------------------------
31424: tolerable FAIL

flight 31424 linux-linus real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31424/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline unte=
sted


jobs:
 build-i386-rumpuserxen                                       pass   =20
 test-amd64-i386-rumpuserxen-i386                             fail   =20


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=3Dosstest.git;a=3Dsummary



--===============6490934011355994455==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6490934011355994455==--

From xen-devel-bounces@lists.xen.org Thu Nov 06 19:05:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19:05:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmSN3-0006M7-A3; Thu, 06 Nov 2014 19:05:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1XmSN1-0006M0-NS
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 19:05:23 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AD/8F-09936-376CB545; Thu, 06 Nov 2014 19:05:23 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415300721!12046374!1
X-Originating-IP: [209.85.220.180]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10135 invoked from network); 6 Nov 2014 19:05:21 -0000
Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com)
	(209.85.220.180)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 19:05:21 -0000
Received: by mail-vc0-f180.google.com with SMTP id hy10so922896vcb.11
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 11:05:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=C20gKXMtloGQBPZdkZp8pIbf22djGrsAkYe9+/nF5CM=;
	b=svxfGvH8eWSMTKtZmeE0x1fFk68zvbEFSG5WAdfMthV0z2blKLt7y4BoxpoCKXG2sX
	y6A3+SARtaKwL4naCf21yGSl8CQKzzh4CIhTPbDYCnhyn5RTgZ9905gGGCqwxKx/OI/2
	GLfRw2oe8LHbaCKAfKofR6VNCQ0UHBNi84YQp+wru7rN+2DMdAo0fVk5yfHWsx2Ry1qz
	q6j22i7TGq/J9EI6EGhoHCwo5NCzaoZRH86ab6tSm2mXEne6haOcz8Bkrnj94pPGrCo9
	A37jmlxsc742qQlKr3+rGOu/3WbgQVCN+tjmAW1ZeWg8kBDIWXscQqHxCRSTSDSnhVIF
	/pjA==
MIME-Version: 1.0
X-Received: by 10.220.181.133 with SMTP id by5mr1194841vcb.44.1415300720789;
	Thu, 06 Nov 2014 11:05:20 -0800 (PST)
Received: by 10.52.160.129 with HTTP; Thu, 6 Nov 2014 11:05:20 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
	<alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
Date: Thu, 6 Nov 2014 19:05:20 +0000
Message-ID: <CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Frediano Ziglio <frediano.ziglio@huawei.com>,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
	xen_swiotlb_map_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: multipart/mixed; boundary="===============4269923558597403807=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4269923558597403807==
Content-Type: multipart/alternative; boundary=001a11c1be3cb691ad05073560be

--001a11c1be3cb691ad05073560be
Content-Type: text/plain; charset=UTF-8

2014-11-06 17:30 GMT+00:00 Stefano Stabellini <
stefano.stabellini@eu.citrix.com>:

> On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> > On ARM error code is not 0 so avoid to return it as error.
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
>
> Could you please fix the same error in lib/swiotlb.c too please?
>
>
Same patch or another ?

Frediano


> >  drivers/xen/swiotlb-xen.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ebd8f21..3b8d628 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev,
> struct page *page,
> >        */
> >       if (!dma_capable(dev, dev_addr, size)) {
> >               swiotlb_tbl_unmap_single(dev, map, size, dir);
> > -             dev_addr = 0;
> > +             dev_addr = DMA_ERROR_CODE;
> >       }
> >       return dev_addr;
> >  }
> > --
> > 1.9.1
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at
> http://secure-web.cisco.com/1cvjROyUxV6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpcxwEH-udGrGCCqkCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYcvWsOK5s3qg/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--001a11c1be3cb691ad05073560be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2014-11-06 17:30 GMT+00:00 Stefano Stabellini <span dir=3D=
"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.com" target=3D"_bl=
ank">stefano.stabellini@eu.citrix.com</a>&gt;</span>:<br><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">On Thu, 6 Nov 2014, Frediano Ziglio wrote:<br>
&gt; On ARM error code is not 0 so avoid to return it as error.<br>
&gt;<br>
&gt; Signed-off-by: Frediano Ziglio &lt;<a href=3D"mailto:frediano.ziglio@h=
uawei.com">frediano.ziglio@huawei.com</a>&gt;<br>
<br>
</span>Acked-by: Stefano Stabellini &lt;<a href=3D"mailto:stefano.stabellin=
i@eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt;<br>
<br>
<br>
Could you please fix the same error in lib/swiotlb.c too please?<br>
<span class=3D"im HOEnZb"><br></span></blockquote><div><br></div><div>Same =
patch or another ?<br><br></div><div>Frediano<br></div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><span class=3D"im HOEnZb">
&gt;=C2=A0 drivers/xen/swiotlb-xen.c | 2 +-<br>
&gt;=C2=A0 1 file changed, 1 insertion(+), 1 deletion(-)<br>
&gt;<br>
&gt; diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c<br>
&gt; index ebd8f21..3b8d628 100644<br>
&gt; --- a/drivers/xen/swiotlb-xen.c<br>
&gt; +++ b/drivers/xen/swiotlb-xen.c<br>
&gt; @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev=
, struct page *page,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 */<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!dma_capable(dev, dev_addr, size)) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0swiotlb_tbl_unma=
p_single(dev, map, size, dir);<br>
&gt; -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_addr =3D 0;<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_addr =3D DMA_ERRO=
R_CODE;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0return dev_addr;<br>
&gt;=C2=A0 }<br>
&gt; --<br>
&gt; 1.9.1<br>
&gt;<br>
&gt;<br>
</span><span class=3D"HOEnZb"><font color=3D"#888888">&gt; --<br>
&gt; To unsubscribe from this list: send the line &quot;unsubscribe linux-k=
ernel&quot; in<br>
&gt; the body of a message to <a href=3D"mailto:majordomo@vger.kernel.org">=
majordomo@vger.kernel.org</a><br>
&gt; More majordomo info at=C2=A0 <a href=3D"http://vger.kernel.org/majordo=
mo-info.html" target=3D"_blank">http://vger.kernel.org/majordomo-info.html<=
/a><br>
&gt; Please read the FAQ at=C2=A0 <a href=3D"http://secure-web.cisco.com/1c=
vjROyUxV6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH=
2_7-kpcxwEH-udGrGCCqkCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-Gsgxbep9QWPnIdypDPNf8H=
f5clxCMXYcvWsOK5s3qg/http%3A%2F%2Fwww.tux.org%2Flkml%2F" target=3D"_blank">=
http://secure-web.cisco.com/1cvjROyUxV6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaK=
Klt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpcxwEH-udGrGCCqkCLlH1-fLOo1X6Nlui6EwEVHU=
pB2r7gt-Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYcvWsOK5s3qg/http%3A%2F%2Fwww.tux.org=
%2Flkml%2F</a><br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">&gt;<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div><br></div></div>

--001a11c1be3cb691ad05073560be--


--===============4269923558597403807==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4269923558597403807==--


From xen-devel-bounces@lists.xen.org Thu Nov 06 19:05:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19:05:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmSN3-0006M7-A3; Thu, 06 Nov 2014 19:05:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1XmSN1-0006M0-NS
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 19:05:23 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AD/8F-09936-376CB545; Thu, 06 Nov 2014 19:05:23 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415300721!12046374!1
X-Originating-IP: [209.85.220.180]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10135 invoked from network); 6 Nov 2014 19:05:21 -0000
Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com)
	(209.85.220.180)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 19:05:21 -0000
Received: by mail-vc0-f180.google.com with SMTP id hy10so922896vcb.11
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 11:05:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=C20gKXMtloGQBPZdkZp8pIbf22djGrsAkYe9+/nF5CM=;
	b=svxfGvH8eWSMTKtZmeE0x1fFk68zvbEFSG5WAdfMthV0z2blKLt7y4BoxpoCKXG2sX
	y6A3+SARtaKwL4naCf21yGSl8CQKzzh4CIhTPbDYCnhyn5RTgZ9905gGGCqwxKx/OI/2
	GLfRw2oe8LHbaCKAfKofR6VNCQ0UHBNi84YQp+wru7rN+2DMdAo0fVk5yfHWsx2Ry1qz
	q6j22i7TGq/J9EI6EGhoHCwo5NCzaoZRH86ab6tSm2mXEne6haOcz8Bkrnj94pPGrCo9
	A37jmlxsc742qQlKr3+rGOu/3WbgQVCN+tjmAW1ZeWg8kBDIWXscQqHxCRSTSDSnhVIF
	/pjA==
MIME-Version: 1.0
X-Received: by 10.220.181.133 with SMTP id by5mr1194841vcb.44.1415300720789;
	Thu, 06 Nov 2014 11:05:20 -0800 (PST)
Received: by 10.52.160.129 with HTTP; Thu, 6 Nov 2014 11:05:20 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
	<alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
Date: Thu, 6 Nov 2014 19:05:20 +0000
Message-ID: <CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Frediano Ziglio <frediano.ziglio@huawei.com>,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
	xen_swiotlb_map_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: multipart/mixed; boundary="===============4269923558597403807=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4269923558597403807==
Content-Type: multipart/alternative; boundary=001a11c1be3cb691ad05073560be

--001a11c1be3cb691ad05073560be
Content-Type: text/plain; charset=UTF-8

2014-11-06 17:30 GMT+00:00 Stefano Stabellini <
stefano.stabellini@eu.citrix.com>:

> On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> > On ARM error code is not 0 so avoid to return it as error.
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
>
> Could you please fix the same error in lib/swiotlb.c too please?
>
>
Same patch or another ?

Frediano


> >  drivers/xen/swiotlb-xen.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ebd8f21..3b8d628 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev,
> struct page *page,
> >        */
> >       if (!dma_capable(dev, dev_addr, size)) {
> >               swiotlb_tbl_unmap_single(dev, map, size, dir);
> > -             dev_addr = 0;
> > +             dev_addr = DMA_ERROR_CODE;
> >       }
> >       return dev_addr;
> >  }
> > --
> > 1.9.1
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at
> http://secure-web.cisco.com/1cvjROyUxV6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpcxwEH-udGrGCCqkCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYcvWsOK5s3qg/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--001a11c1be3cb691ad05073560be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2014-11-06 17:30 GMT+00:00 Stefano Stabellini <span dir=3D=
"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.com" target=3D"_bl=
ank">stefano.stabellini@eu.citrix.com</a>&gt;</span>:<br><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">On Thu, 6 Nov 2014, Frediano Ziglio wrote:<br>
&gt; On ARM error code is not 0 so avoid to return it as error.<br>
&gt;<br>
&gt; Signed-off-by: Frediano Ziglio &lt;<a href=3D"mailto:frediano.ziglio@h=
uawei.com">frediano.ziglio@huawei.com</a>&gt;<br>
<br>
</span>Acked-by: Stefano Stabellini &lt;<a href=3D"mailto:stefano.stabellin=
i@eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt;<br>
<br>
<br>
Could you please fix the same error in lib/swiotlb.c too please?<br>
<span class=3D"im HOEnZb"><br></span></blockquote><div><br></div><div>Same =
patch or another ?<br><br></div><div>Frediano<br></div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><span class=3D"im HOEnZb">
&gt;=C2=A0 drivers/xen/swiotlb-xen.c | 2 +-<br>
&gt;=C2=A0 1 file changed, 1 insertion(+), 1 deletion(-)<br>
&gt;<br>
&gt; diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c<br>
&gt; index ebd8f21..3b8d628 100644<br>
&gt; --- a/drivers/xen/swiotlb-xen.c<br>
&gt; +++ b/drivers/xen/swiotlb-xen.c<br>
&gt; @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev=
, struct page *page,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 */<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!dma_capable(dev, dev_addr, size)) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0swiotlb_tbl_unma=
p_single(dev, map, size, dir);<br>
&gt; -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_addr =3D 0;<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_addr =3D DMA_ERRO=
R_CODE;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0return dev_addr;<br>
&gt;=C2=A0 }<br>
&gt; --<br>
&gt; 1.9.1<br>
&gt;<br>
&gt;<br>
</span><span class=3D"HOEnZb"><font color=3D"#888888">&gt; --<br>
&gt; To unsubscribe from this list: send the line &quot;unsubscribe linux-k=
ernel&quot; in<br>
&gt; the body of a message to <a href=3D"mailto:majordomo@vger.kernel.org">=
majordomo@vger.kernel.org</a><br>
&gt; More majordomo info at=C2=A0 <a href=3D"http://vger.kernel.org/majordo=
mo-info.html" target=3D"_blank">http://vger.kernel.org/majordomo-info.html<=
/a><br>
&gt; Please read the FAQ at=C2=A0 <a href=3D"http://secure-web.cisco.com/1c=
vjROyUxV6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH=
2_7-kpcxwEH-udGrGCCqkCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-Gsgxbep9QWPnIdypDPNf8H=
f5clxCMXYcvWsOK5s3qg/http%3A%2F%2Fwww.tux.org%2Flkml%2F" target=3D"_blank">=
http://secure-web.cisco.com/1cvjROyUxV6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaK=
Klt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpcxwEH-udGrGCCqkCLlH1-fLOo1X6Nlui6EwEVHU=
pB2r7gt-Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYcvWsOK5s3qg/http%3A%2F%2Fwww.tux.org=
%2Flkml%2F</a><br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">&gt;<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div><br></div></div>

--001a11c1be3cb691ad05073560be--


--===============4269923558597403807==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4269923558597403807==--


From xen-devel-bounces@lists.xen.org Thu Nov 06 19:15:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19:15:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmSWB-0006el-Mu; Thu, 06 Nov 2014 19:14:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XmSWA-0006eb-Bn
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 19:14:50 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	C5/EA-02576-9A8CB545; Thu, 06 Nov 2014 19:14:49 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415301287!11903528!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8912 invoked from network); 6 Nov 2014 19:14:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 19:14:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA6JEi25019597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Nov 2014 19:14:44 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JEhS8000140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 6 Nov 2014 19:14:43 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JEh0s014020; Thu, 6 Nov 2014 19:14:43 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Nov 2014 11:14:42 -0800
Message-ID: <545BC8A2.20604@oracle.com>
Date: Thu, 06 Nov 2014 14:14:42 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xenproject.org>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] xl list -l doesn't work for incoming 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

Hi,

While doing VM migration, in the destination side:

   # xl list -l
    libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
    [
        {
            "domid": 0,
            "config": {
                "c_info": {
                    "type": "pv",
                    "name": "Domain-0"
                },
                "b_info": {
                    "max_memkb": 876544,
                    "target_memkb": 876543,
                    "sched_params": {
    
                    },
                    "type.pv": {
    
                    }
                }
            }
        }
    ]
 
    # xl list
    Name                                          ID   Mem VCPUs      State   Time(s)
    Domain-0                                       0   856     4     r-----    2758.9
    0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0

Testing on:

    commit 816f5bb1f0740be8355e1be6cc24edf09547d984
    Author: Ian Campbell <ian.campbell@citrix.com>
    Date:   Fri Oct 24 10:58:33 2014 +0100

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 19:15:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19:15:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmSWB-0006el-Mu; Thu, 06 Nov 2014 19:14:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XmSWA-0006eb-Bn
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 19:14:50 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	C5/EA-02576-9A8CB545; Thu, 06 Nov 2014 19:14:49 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415301287!11903528!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8912 invoked from network); 6 Nov 2014 19:14:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 19:14:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA6JEi25019597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Nov 2014 19:14:44 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JEhS8000140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 6 Nov 2014 19:14:43 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JEh0s014020; Thu, 6 Nov 2014 19:14:43 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Nov 2014 11:14:42 -0800
Message-ID: <545BC8A2.20604@oracle.com>
Date: Thu, 06 Nov 2014 14:14:42 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xenproject.org>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] xl list -l doesn't work for incoming 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

Hi,

While doing VM migration, in the destination side:

   # xl list -l
    libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
    [
        {
            "domid": 0,
            "config": {
                "c_info": {
                    "type": "pv",
                    "name": "Domain-0"
                },
                "b_info": {
                    "max_memkb": 876544,
                    "target_memkb": 876543,
                    "sched_params": {
    
                    },
                    "type.pv": {
    
                    }
                }
            }
        }
    ]
 
    # xl list
    Name                                          ID   Mem VCPUs      State   Time(s)
    Domain-0                                       0   856     4     r-----    2758.9
    0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0

Testing on:

    commit 816f5bb1f0740be8355e1be6cc24edf09547d984
    Author: Ian Campbell <ian.campbell@citrix.com>
    Date:   Fri Oct 24 10:58:33 2014 +0100

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 19:15:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmSWP-0006gX-30; Thu, 06 Nov 2014 19:15:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmSWO-0006gG-GY
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 19:15:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	09/B8-09936-7B8CB545; Thu, 06 Nov 2014 19:15:03 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415301302!12017897!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30452 invoked from network); 6 Nov 2014 19:15:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 19:15:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="scan'208";a="190310907"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 14:15:00 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmSWK-0004Fy-1r;
	Thu, 06 Nov 2014 19:15:00 +0000
Date: Thu, 6 Nov 2014 19:14:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Frediano Ziglio <freddy77@gmail.com>
In-Reply-To: <CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
	<alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
	<CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-387728907-1415301291=:22875"
X-DLP: MIA2
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, Frediano Ziglio <frediano.ziglio@huawei.com>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Boris
	Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
 xen_swiotlb_map_page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-387728907-1415301291=:22875
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> 2014-11-06 17:30 GMT+00:00 Stefano Stabellini <stefano.stabellini@eu.citr=
ix.com>:
>       On Thu, 6 Nov 2014, Frediano Ziglio wrote:
>       > On ARM error code is not 0 so avoid to return it as error.
>       >
>       > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
>=20
>       Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>=20
>=20
>       Could you please fix the same error in lib/swiotlb.c too please?
>=20
>=20
> Same patch or another ?
>=20

Another

> =C2=A0
>       >=C2=A0 drivers/xen/swiotlb-xen.c | 2 +-
>       >=C2=A0 1 file changed, 1 insertion(+), 1 deletion(-)
>       >
>       > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.=
c
>       > index ebd8f21..3b8d628 100644
>       > --- a/drivers/xen/swiotlb-xen.c
>       > +++ b/drivers/xen/swiotlb-xen.c
>       > @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct device=
 *dev, struct page *page,
>       >=C2=A0 =C2=A0 =C2=A0 =C2=A0 */
>       >=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!dma_capable(dev, dev_addr, size)) =
{
>       >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0swiotlb_tbl=
_unmap_single(dev, map, size, dir);
>       > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_addr =3D 0;
>       > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_addr =3D DMA=
_ERROR_CODE;
>       >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>       >=C2=A0 =C2=A0 =C2=A0 =C2=A0return dev_addr;
>       >=C2=A0 }
>       > --
>       > 1.9.1
>       >
>       >
>       > --
>       > To unsubscribe from this list: send the line "unsubscribe linux-k=
ernel" in
>       > the body of a message to majordomo@vger.kernel.org
>       > More majordomo info at=C2=A0 http://vger.kernel.org/majordomo-inf=
o.html
>       > Please read the FAQ at=C2=A0http://secure-web.cisco.com/1cvjROyUx=
V6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpc=
xwEH-udGrGCCq
>       kCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYcvW=
sOK5s3qg/http%3A%2F%2Fwww.tux.org%2Flkml%2F
>       >
>=20
>       _______________________________________________
>       Xen-devel mailing list
>       Xen-devel@lists.xen.org
>       http://lists.xen.org/xen-devel
>=20
>=20
>=20
>=20
--1342847746-387728907-1415301291=:22875
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-387728907-1415301291=:22875--


From xen-devel-bounces@lists.xen.org Thu Nov 06 19:15:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 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.xen.org>)
	id 1XmSWP-0006gX-30; Thu, 06 Nov 2014 19:15:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmSWO-0006gG-GY
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 19:15:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	09/B8-09936-7B8CB545; Thu, 06 Nov 2014 19:15:03 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415301302!12017897!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30452 invoked from network); 6 Nov 2014 19:15:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 19:15:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="scan'208";a="190310907"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 6 Nov 2014 14:15:00 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmSWK-0004Fy-1r;
	Thu, 06 Nov 2014 19:15:00 +0000
Date: Thu, 6 Nov 2014 19:14:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Frediano Ziglio <freddy77@gmail.com>
In-Reply-To: <CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
	<alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
	<CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-387728907-1415301291=:22875"
X-DLP: MIA2
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, Frediano Ziglio <frediano.ziglio@huawei.com>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Boris
	Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
 xen_swiotlb_map_page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-387728907-1415301291=:22875
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> 2014-11-06 17:30 GMT+00:00 Stefano Stabellini <stefano.stabellini@eu.citr=
ix.com>:
>       On Thu, 6 Nov 2014, Frediano Ziglio wrote:
>       > On ARM error code is not 0 so avoid to return it as error.
>       >
>       > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
>=20
>       Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>=20
>=20
>       Could you please fix the same error in lib/swiotlb.c too please?
>=20
>=20
> Same patch or another ?
>=20

Another

> =C2=A0
>       >=C2=A0 drivers/xen/swiotlb-xen.c | 2 +-
>       >=C2=A0 1 file changed, 1 insertion(+), 1 deletion(-)
>       >
>       > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.=
c
>       > index ebd8f21..3b8d628 100644
>       > --- a/drivers/xen/swiotlb-xen.c
>       > +++ b/drivers/xen/swiotlb-xen.c
>       > @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct device=
 *dev, struct page *page,
>       >=C2=A0 =C2=A0 =C2=A0 =C2=A0 */
>       >=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!dma_capable(dev, dev_addr, size)) =
{
>       >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0swiotlb_tbl=
_unmap_single(dev, map, size, dir);
>       > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_addr =3D 0;
>       > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_addr =3D DMA=
_ERROR_CODE;
>       >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>       >=C2=A0 =C2=A0 =C2=A0 =C2=A0return dev_addr;
>       >=C2=A0 }
>       > --
>       > 1.9.1
>       >
>       >
>       > --
>       > To unsubscribe from this list: send the line "unsubscribe linux-k=
ernel" in
>       > the body of a message to majordomo@vger.kernel.org
>       > More majordomo info at=C2=A0 http://vger.kernel.org/majordomo-inf=
o.html
>       > Please read the FAQ at=C2=A0http://secure-web.cisco.com/1cvjROyUx=
V6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpc=
xwEH-udGrGCCq
>       kCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYcvW=
sOK5s3qg/http%3A%2F%2Fwww.tux.org%2Flkml%2F
>       >
>=20
>       _______________________________________________
>       Xen-devel mailing list
>       Xen-devel@lists.xen.org
>       http://lists.xen.org/xen-devel
>=20
>=20
>=20
>=20
--1342847746-387728907-1415301291=:22875
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-387728907-1415301291=:22875--


From xen-devel-bounces@lists.xen.org Thu Nov 06 19:33:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19: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 1XmSnp-0007FH-0X; Thu, 06 Nov 2014 19:33: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 1XmSnn-0007F8-N0
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 19:33:03 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	E3/0B-01660-FECCB545; Thu, 06 Nov 2014 19:33:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415302381!10955987!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12744 invoked from network); 6 Nov 2014 19:33:02 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Nov 2014 19:33:02 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA6JWssf030063
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Nov 2014 19:32:54 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JWqLi003541
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Nov 2014 19:32:53 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA6JWpi0001612; Thu, 6 Nov 2014 19:32:52 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Nov 2014 11:32:51 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EB89D111461; Thu,  6 Nov 2014 14:32:49 -0500 (EST)
Date: Thu, 6 Nov 2014 14:32:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20141106193249.GB5906@laptop.dumpdata.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 03:07:10PM +0000, Paul Durrant wrote:
> To perform certain hypercalls HVM guests need to use Xen's idea of

What are those 'certain'?

> vcpu id, which may well not match the guest OS idea of CPU id.

Can you elaborate more on the use case please? And why
only restrict this to HVM guests? Why not PV?

> This patch adds vcpu id to the HVM cpuid leaf allowing the guest
> to build a mapping.

Don't we have existing hypercalls to get this? Ah VCPUOP_get_physid
is what I was thinking of and that does not seem to be what
you want?
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>
> ---
>  xen/arch/x86/hvm/hvm.c              |    4 ++++
>  xen/include/public/arch-x86/cpuid.h |    5 +++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 78f519d..d9a5706 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t sub_idx,
>           * foreign pages) has valid IOMMU entries.
>           */
>          *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
> +
> +        /* Indicate presence of vcpu id and set it in ebx */
> +        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
> +        *ebx = current->vcpu_id;
>      }
>  }
>  
> diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
> index 6005dfe..8ccb6e1 100644
> --- a/xen/include/public/arch-x86/cpuid.h
> +++ b/xen/include/public/arch-x86/cpuid.h
> @@ -76,13 +76,14 @@
>  /*
>   * Leaf 5 (0x40000x04)
>   * HVM-specific features
> + * EAX: Features
> + * EBX: VCPU ID
>   */
> -
> -/* EAX Features */
>  #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized APIC registers */
>  #define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized x2APIC accesses */
>  /* Memory mapped from other domains has valid IOMMU entries */
>  #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
> +#define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu is present in EBX */
>  
>  #define XEN_CPUID_MAX_NUM_LEAVES 4
>  
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 19:33:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19: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 1XmSnp-0007FH-0X; Thu, 06 Nov 2014 19:33: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 1XmSnn-0007F8-N0
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 19:33:03 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	E3/0B-01660-FECCB545; Thu, 06 Nov 2014 19:33:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415302381!10955987!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12744 invoked from network); 6 Nov 2014 19:33:02 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Nov 2014 19:33:02 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA6JWssf030063
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Nov 2014 19:32:54 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JWqLi003541
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Nov 2014 19:32:53 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA6JWpi0001612; Thu, 6 Nov 2014 19:32:52 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Nov 2014 11:32:51 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EB89D111461; Thu,  6 Nov 2014 14:32:49 -0500 (EST)
Date: Thu, 6 Nov 2014 14:32:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20141106193249.GB5906@laptop.dumpdata.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 03:07:10PM +0000, Paul Durrant wrote:
> To perform certain hypercalls HVM guests need to use Xen's idea of

What are those 'certain'?

> vcpu id, which may well not match the guest OS idea of CPU id.

Can you elaborate more on the use case please? And why
only restrict this to HVM guests? Why not PV?

> This patch adds vcpu id to the HVM cpuid leaf allowing the guest
> to build a mapping.

Don't we have existing hypercalls to get this? Ah VCPUOP_get_physid
is what I was thinking of and that does not seem to be what
you want?
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>
> ---
>  xen/arch/x86/hvm/hvm.c              |    4 ++++
>  xen/include/public/arch-x86/cpuid.h |    5 +++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 78f519d..d9a5706 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4189,6 +4189,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t sub_idx,
>           * foreign pages) has valid IOMMU entries.
>           */
>          *eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
> +
> +        /* Indicate presence of vcpu id and set it in ebx */
> +        *eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
> +        *ebx = current->vcpu_id;
>      }
>  }
>  
> diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
> index 6005dfe..8ccb6e1 100644
> --- a/xen/include/public/arch-x86/cpuid.h
> +++ b/xen/include/public/arch-x86/cpuid.h
> @@ -76,13 +76,14 @@
>  /*
>   * Leaf 5 (0x40000x04)
>   * HVM-specific features
> + * EAX: Features
> + * EBX: VCPU ID
>   */
> -
> -/* EAX Features */
>  #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized APIC registers */
>  #define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized x2APIC accesses */
>  /* Memory mapped from other domains has valid IOMMU entries */
>  #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
> +#define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu is present in EBX */
>  
>  #define XEN_CPUID_MAX_NUM_LEAVES 4
>  
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 19:36:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19:36:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmSrW-0007PQ-Qp; Thu, 06 Nov 2014 19:36:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmSrU-0007PK-QY
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 19:36:52 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	14/70-24859-4DDCB545; Thu, 06 Nov 2014 19:36:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415302609!10955651!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2512 invoked from network); 6 Nov 2014 19:36:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 19:36:51 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA6JaIbV014796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Nov 2014 19:36:19 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JaGCo016856
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Nov 2014 19:36:17 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA6JaF8V015407; Thu, 6 Nov 2014 19:36:16 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Nov 2014 11:36:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4050F11146A; Thu,  6 Nov 2014 14:36:11 -0500 (EST)
Date: Thu, 6 Nov 2014 14:36:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141106193611.GC5906@laptop.dumpdata.com>
References: <1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
	<20141106113923.GA3182@type.bordeaux.inria.fr>
	<alpine.DEB.2.02.1411061543170.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411061543170.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>, netwiz@crc.id.au,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Nov 06, 2014 at 03:43:42PM +0000, Stefano Stabellini wrote:
> On Thu, 6 Nov 2014, Samuel Thibault wrote:
> > Stefano Stabellini, le Thu 06 Nov 2014 10:41:28 +0000, a =E9crit :
> > > When using pvgrub in graphical mode with vnc, the grub timeout doesn't
> > > work: the countdown doesn't even start. With a serial terminal the
> > > problem doesn't occur and the countdown works as expected.
> > > =

> > > It turns out that the problem is that when using a graphical terminal,
> > > checkkey () returns 0 instead of -1 when there is no activity on the
> > > mouse or keyboard. As a consequence grub thinks that the user typed
> > > something and interrupts the count down.
> > > =

> > > To fix the issue simply ignore keystrokes returning 0, that is the NUL
> > > character anyway. Add a patch to grub.patches to do that.
> > > =

> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Tested-by: Steven Haigh <netwiz@crc.id.au>
> > =

> > Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> =

> This being a bug fix, I guess it doesn't actually need a release
> exception to go in?

It should - but it depends on the on how risk averse the maintainer
of the particular subsystem is.

Regardless I believe this should go in. But more importantly - can
this also go upstream?
> =

> =

> > > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/=
grub.patches/11graphics-keyboard.diff
> > > new file mode 100644
> > > index 0000000..fe17b20
> > > --- /dev/null
> > > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> > > @@ -0,0 +1,13 @@
> > > +diff --git a/stage2/stage2.c b/stage2/stage2.c
> > > +index 9d9fcc3..8353a3b 100644
> > > +--- a/stage2/stage2.c
> > > ++++ b/stage2/stage2.c
> > > +@@ -395,7 +395,7 @@ restart:
> > > + 	 pressed.  =

> > > + 	 This avoids polling (relevant in the grub-shell and later on
> > > + 	 in grub if interrupt driven I/O is done).  */
> > > +-      if (checkkey () >=3D 0 || grub_timeout < 0)
> > > ++      if (checkkey () > 0 || grub_timeout < 0)
> > > + 	{
> > > + 	  /* Key was pressed, show which entry is selected before GETKEY,
> > > + 	     since we're comming in here also on GRUB_TIMEOUT =3D=3D -1 and
> > > =

> > =

> > -- =

> > Samuel
> > "And the next time you consider complaining that running Lucid Emacs
> > 19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
> > get the background colors right, you'll know who to thank."
> > (By Matt Welsh)
> > =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 19:36:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19:36:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmSrW-0007PQ-Qp; Thu, 06 Nov 2014 19:36:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmSrU-0007PK-QY
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 19:36:52 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	14/70-24859-4DDCB545; Thu, 06 Nov 2014 19:36:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415302609!10955651!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2512 invoked from network); 6 Nov 2014 19:36:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 19:36:51 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA6JaIbV014796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Nov 2014 19:36:19 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JaGCo016856
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Nov 2014 19:36:17 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA6JaF8V015407; Thu, 6 Nov 2014 19:36:16 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Nov 2014 11:36:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4050F11146A; Thu,  6 Nov 2014 14:36:11 -0500 (EST)
Date: Thu, 6 Nov 2014 14:36:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141106193611.GC5906@laptop.dumpdata.com>
References: <1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
	<20141106113923.GA3182@type.bordeaux.inria.fr>
	<alpine.DEB.2.02.1411061543170.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411061543170.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>, netwiz@crc.id.au,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Nov 06, 2014 at 03:43:42PM +0000, Stefano Stabellini wrote:
> On Thu, 6 Nov 2014, Samuel Thibault wrote:
> > Stefano Stabellini, le Thu 06 Nov 2014 10:41:28 +0000, a =E9crit :
> > > When using pvgrub in graphical mode with vnc, the grub timeout doesn't
> > > work: the countdown doesn't even start. With a serial terminal the
> > > problem doesn't occur and the countdown works as expected.
> > > =

> > > It turns out that the problem is that when using a graphical terminal,
> > > checkkey () returns 0 instead of -1 when there is no activity on the
> > > mouse or keyboard. As a consequence grub thinks that the user typed
> > > something and interrupts the count down.
> > > =

> > > To fix the issue simply ignore keystrokes returning 0, that is the NUL
> > > character anyway. Add a patch to grub.patches to do that.
> > > =

> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Tested-by: Steven Haigh <netwiz@crc.id.au>
> > =

> > Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> =

> This being a bug fix, I guess it doesn't actually need a release
> exception to go in?

It should - but it depends on the on how risk averse the maintainer
of the particular subsystem is.

Regardless I believe this should go in. But more importantly - can
this also go upstream?
> =

> =

> > > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/=
grub.patches/11graphics-keyboard.diff
> > > new file mode 100644
> > > index 0000000..fe17b20
> > > --- /dev/null
> > > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> > > @@ -0,0 +1,13 @@
> > > +diff --git a/stage2/stage2.c b/stage2/stage2.c
> > > +index 9d9fcc3..8353a3b 100644
> > > +--- a/stage2/stage2.c
> > > ++++ b/stage2/stage2.c
> > > +@@ -395,7 +395,7 @@ restart:
> > > + 	 pressed.  =

> > > + 	 This avoids polling (relevant in the grub-shell and later on
> > > + 	 in grub if interrupt driven I/O is done).  */
> > > +-      if (checkkey () >=3D 0 || grub_timeout < 0)
> > > ++      if (checkkey () > 0 || grub_timeout < 0)
> > > + 	{
> > > + 	  /* Key was pressed, show which entry is selected before GETKEY,
> > > + 	     since we're comming in here also on GRUB_TIMEOUT =3D=3D -1 and
> > > =

> > =

> > -- =

> > Samuel
> > "And the next time you consider complaining that running Lucid Emacs
> > 19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
> > get the background colors right, you'll know who to thank."
> > (By Matt Welsh)
> > =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 19:41:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19:41:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmSvZ-0007YM-GN; Thu, 06 Nov 2014 19:41:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1XmSvV-0007YH-W3
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 19:41:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F9/1E-09842-DCECB545; Thu, 06 Nov 2014 19:41:01 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415302860!11977403!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25056 invoked from network); 6 Nov 2014 19:41:00 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-6.tower-21.messagelabs.com with SMTP;
	6 Nov 2014 19:41:00 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id B4A1658142E;
	Thu,  6 Nov 2014 11:40:58 -0800 (PST)
Date: Thu, 06 Nov 2014 14:40:57 -0500 (EST)
Message-Id: <20141106.144057.541605315482589279.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Thu, 06 Nov 2014 11:40:59 -0800 (PST)
Cc: netdev@vger.kernel.org, malcolm.crossley@citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 5 Nov 2014 10:50:22 +0000

> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> 
> Unconditionally pulling 128 bytes into the linear area is not required
> for:
> 
> - security: Every protocol demux starts with pskb_may_pull() to pull
>   frag data into the linear area, if necessary, before looking at
>   headers.
> 
> - performance: Netback has already grant copied up-to 128 bytes from
>   the first slot of a packet into the linear area. The first slot
>   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> 
> The unconditional pull would often copy frag data unnecessarily.  This
> is a performance problem when running on a version of Xen where grant
> unmap avoids TLB flushes for pages which are not accessed.  TLB
> flushes can now be avoided for > 99% of unmaps (it was 0% before).
> 
> Grant unmap TLB flush avoidance will be available in a future version
> of Xen (probably 4.6).
> 
> Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 19:41:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19:41:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmSvZ-0007YM-GN; Thu, 06 Nov 2014 19:41:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1XmSvV-0007YH-W3
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 19:41:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F9/1E-09842-DCECB545; Thu, 06 Nov 2014 19:41:01 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415302860!11977403!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25056 invoked from network); 6 Nov 2014 19:41:00 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-6.tower-21.messagelabs.com with SMTP;
	6 Nov 2014 19:41:00 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id B4A1658142E;
	Thu,  6 Nov 2014 11:40:58 -0800 (PST)
Date: Thu, 06 Nov 2014 14:40:57 -0500 (EST)
Message-Id: <20141106.144057.541605315482589279.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
References: <1415184622-19421-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Thu, 06 Nov 2014 11:40:59 -0800 (PST)
Cc: netdev@vger.kernel.org, malcolm.crossley@citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
 unconditional __pskb_pull_tail() in guest Tx path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 5 Nov 2014 10:50:22 +0000

> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> 
> Unconditionally pulling 128 bytes into the linear area is not required
> for:
> 
> - security: Every protocol demux starts with pskb_may_pull() to pull
>   frag data into the linear area, if necessary, before looking at
>   headers.
> 
> - performance: Netback has already grant copied up-to 128 bytes from
>   the first slot of a packet into the linear area. The first slot
>   normally contain all the IPv4/IPv6 and TCP/UDP headers.
> 
> The unconditional pull would often copy frag data unnecessarily.  This
> is a performance problem when running on a version of Xen where grant
> unmap avoids TLB flushes for pages which are not accessed.  TLB
> flushes can now be avoided for > 99% of unmaps (it was 0% before).
> 
> Grant unmap TLB flush avoidance will be available in a future version
> of Xen (probably 4.6).
> 
> Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 19:43:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19: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 1XmSxd-0007ne-73; Thu, 06 Nov 2014 19:43:13 +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 1XmSxb-0007n0-Qz
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 19:43:12 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	C5/03-02702-F4FCB545; Thu, 06 Nov 2014 19:43:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415302985!11914373!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25495 invoked from network); 6 Nov 2014 19:43:06 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 19:43:06 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA6Jfq97021585
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Nov 2014 19:41:53 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JfpDt012360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 6 Nov 2014 19:41:51 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JfoVb026116; Thu, 6 Nov 2014 19:41:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Nov 2014 11:41:50 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D4D0D111477; Thu,  6 Nov 2014 14:41:48 -0500 (EST)
Date: Thu, 6 Nov 2014 14:41:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: manish jaggi <manishjaggi.oss@gmail.com>
Message-ID: <20141106194148.GD5906@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ryan Wilson <hap9@epoch.ncsc.mil>, Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>, JBeulich@suse.com
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 08:58:18PM +0530, manish jaggi wrote:
> On 20 October 2014 20:24, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 20 Oct 2014, manish jaggi wrote:
> >> On 8 October 2014 20:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
> >> >> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >> > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
> >> >> >> Thanks for replying. As detailed in this thread, I need to create a
> >> >> >> hypercall that would send the following information to Xen at the time
> >> >> >> of PCI attach
> >> >> >> { sbdf , domU sbdf, domainId }.
> >> >> >> I am not able to find a way to get the domU sbdf from dom0 at the time
> >> >> >> of pci-attach.
> >> >> >
> >> >> > I think it would need to be done by the pciback driver in the dom0
> >> >> > kernel, which AFAIK is the thing which consistently knows both physical
> >> >> > and virtual sbdf for a given assigned device.
> >> >> >
> >> >> > Ian.
> >> >> >
> >> >> Correct, can you point out which data structure holds the domU sbdf
> >> >> corresponding to the actual sbdf in pciback.
> >> >
> >> > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
> >> > is that what you are referring to?
> >>
> >> Xen docs also mention about xen-pciback.passthrough=1. If I set this
> >> in dom0 i see that the device is enumerated as the same sbdf in domU,
> >> but
> >> a) it is not shown in lspci
> >> b) no front-back communication is done for reading devices configuration space
> >> .
> >> Is option useful / fully implemented for ARM ?
> >
> > I don't think this option is very useful. I wouldn't worry about it for
> > now.
> 
> Stefano / Ian / Konard / Julien,
> 
> Attached is a first raw code FYI RFC Patches of PCI passthrough support on ARM.
> - Linux Patch (3.18)

I would move the code that arch/arm64/xen/xen_pci.c introduces
(which is also in arch/x86/pci/xen.c) in its own generic file - say
to drivers/xen/pci.c.

That way you share the code between those two platforms instead
of copying it.

> - Xen Patch  (4.5 staging)
> ---(Smmu changes not included, thats a separate patch altogether)
> This patches show the logic, at places need of improvements in code
> organization/quality. I wanted to share to get initial comments.
> This is working with SRIOV as well.

Fantastic!
> 
> Please have a look and let me know your positive comments





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 19:43:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 19: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 1XmSxd-0007ne-73; Thu, 06 Nov 2014 19:43:13 +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 1XmSxb-0007n0-Qz
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 19:43:12 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	C5/03-02702-F4FCB545; Thu, 06 Nov 2014 19:43:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415302985!11914373!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25495 invoked from network); 6 Nov 2014 19:43:06 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 19:43:06 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA6Jfq97021585
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Nov 2014 19:41:53 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JfpDt012360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 6 Nov 2014 19:41:51 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6JfoVb026116; Thu, 6 Nov 2014 19:41:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Nov 2014 11:41:50 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D4D0D111477; Thu,  6 Nov 2014 14:41:48 -0500 (EST)
Date: Thu, 6 Nov 2014 14:41:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: manish jaggi <manishjaggi.oss@gmail.com>
Message-ID: <20141106194148.GD5906@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>
	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>
	<20141008124657.GB13391@laptop.dumpdata.com>
	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>
	<1412775916.24894.15.camel@citrix.com>
	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>
	<20141008145107.GC18573@laptop.dumpdata.com>
	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>
	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>
	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ryan Wilson <hap9@epoch.ncsc.mil>, Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>, JBeulich@suse.com
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 08:58:18PM +0530, manish jaggi wrote:
> On 20 October 2014 20:24, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 20 Oct 2014, manish jaggi wrote:
> >> On 8 October 2014 20:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
> >> >> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >> > On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
> >> >> >> Thanks for replying. As detailed in this thread, I need to create a
> >> >> >> hypercall that would send the following information to Xen at the time
> >> >> >> of PCI attach
> >> >> >> { sbdf , domU sbdf, domainId }.
> >> >> >> I am not able to find a way to get the domU sbdf from dom0 at the time
> >> >> >> of pci-attach.
> >> >> >
> >> >> > I think it would need to be done by the pciback driver in the dom0
> >> >> > kernel, which AFAIK is the thing which consistently knows both physical
> >> >> > and virtual sbdf for a given assigned device.
> >> >> >
> >> >> > Ian.
> >> >> >
> >> >> Correct, can you point out which data structure holds the domU sbdf
> >> >> corresponding to the actual sbdf in pciback.
> >> >
> >> > See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
> >> > is that what you are referring to?
> >>
> >> Xen docs also mention about xen-pciback.passthrough=1. If I set this
> >> in dom0 i see that the device is enumerated as the same sbdf in domU,
> >> but
> >> a) it is not shown in lspci
> >> b) no front-back communication is done for reading devices configuration space
> >> .
> >> Is option useful / fully implemented for ARM ?
> >
> > I don't think this option is very useful. I wouldn't worry about it for
> > now.
> 
> Stefano / Ian / Konard / Julien,
> 
> Attached is a first raw code FYI RFC Patches of PCI passthrough support on ARM.
> - Linux Patch (3.18)

I would move the code that arch/arm64/xen/xen_pci.c introduces
(which is also in arch/x86/pci/xen.c) in its own generic file - say
to drivers/xen/pci.c.

That way you share the code between those two platforms instead
of copying it.

> - Xen Patch  (4.5 staging)
> ---(Smmu changes not included, thats a separate patch altogether)
> This patches show the logic, at places need of improvements in code
> organization/quality. I wanted to share to get initial comments.
> This is working with SRIOV as well.

Fantastic!
> 
> Please have a look and let me know your positive comments





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 21:28:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 21:28:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmUbA-0000ql-DG; Thu, 06 Nov 2014 21:28:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XmUb9-0000qd-QN
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 21:28:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	93/F9-09936-6E7EB545; Thu, 06 Nov 2014 21:28:06 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415309286!12016704!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10255 invoked from network); 6 Nov 2014 21:28:06 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 21:28:06 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-23-29-105.brhm.adsl.virginm.net ([86.23.29.105]:58283
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XmUb1-0003Eu-FI (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Thu, 06 Nov 2014 21:28:00 +0000
Message-ID: <545BE7DF.2090803@citrix.com>
Date: Thu, 06 Nov 2014 21:27:59 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Paul Durrant <paul.durrant@citrix.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
In-Reply-To: <20141106193249.GB5906@laptop.dumpdata.com>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/2014 19:32, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 06, 2014 at 03:07:10PM +0000, Paul Durrant wrote:
>> To perform certain hypercalls HVM guests need to use Xen's idea of
> What are those 'certain'?

Some HVM hypercalls take a vcpu_id as a parameter.  See the
functionally-unrelated-but-companion patch "x86/hvm: Add per-vcpu evtchn
upcalls".

HVM guests currently have no way of obtaining a xen vcpu_id for a given
vcpu, and therefore have no way of passing an appropriate parameter to
the hypercalls.

As it currently happens, HVM guests can (and sadly do) take their APIC
id, divide by 2, and end up with a number which happens to match the Xen
vcpu_id.  This only works because Xen's allocation of APIC IDs is wrong
on AMD hardware and Intel Hardware with hyperthreading, and is an issue
I plan to fix in the not too distant future.  (It is one of the quagmire
of issues relating to cpuid policies)

>
>> vcpu id, which may well not match the guest OS idea of CPU id.
> Can you elaborate more on the use case please? And why
> only restrict this to HVM guests? Why not PV?

PV guests unconditionally know their vcpu_id's right from the start, and
indeed need them to bring up APs.  HVM guests currently only know APIC IDs.

>
>> This patch adds vcpu id to the HVM cpuid leaf allowing the guest
>> to build a mapping.
> Don't we have existing hypercalls to get this? Ah VCPUOP_get_physid
> is what I was thinking of and that does not seem to be what
> you want?

This hypercall is only valid for pinned vcpus (i.e. only dom0 with
opt_dom0_vcpus_pin), and gives back the underlying APIC ID, and the ACPI
processor ID for that APIC ID.

The APIC ID can be obtained from cpuid as the vcpus are pinned, and the
ACPI ID can be obtained from the ACPI tables, as the domain is dom0. 
Ergo, this hypercall is quite redundant, has nothing at all to do with
the problem Paul is trying to solve, and appears buggy as it hands back
two 64bit values, shifted 32bits apart, in a 64bit integer.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 21:28:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 21:28:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmUbA-0000ql-DG; Thu, 06 Nov 2014 21:28:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XmUb9-0000qd-QN
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 21:28:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	93/F9-09936-6E7EB545; Thu, 06 Nov 2014 21:28:06 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415309286!12016704!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10255 invoked from network); 6 Nov 2014 21:28:06 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 21:28:06 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-23-29-105.brhm.adsl.virginm.net ([86.23.29.105]:58283
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XmUb1-0003Eu-FI (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Thu, 06 Nov 2014 21:28:00 +0000
Message-ID: <545BE7DF.2090803@citrix.com>
Date: Thu, 06 Nov 2014 21:27:59 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Paul Durrant <paul.durrant@citrix.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
In-Reply-To: <20141106193249.GB5906@laptop.dumpdata.com>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/2014 19:32, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 06, 2014 at 03:07:10PM +0000, Paul Durrant wrote:
>> To perform certain hypercalls HVM guests need to use Xen's idea of
> What are those 'certain'?

Some HVM hypercalls take a vcpu_id as a parameter.  See the
functionally-unrelated-but-companion patch "x86/hvm: Add per-vcpu evtchn
upcalls".

HVM guests currently have no way of obtaining a xen vcpu_id for a given
vcpu, and therefore have no way of passing an appropriate parameter to
the hypercalls.

As it currently happens, HVM guests can (and sadly do) take their APIC
id, divide by 2, and end up with a number which happens to match the Xen
vcpu_id.  This only works because Xen's allocation of APIC IDs is wrong
on AMD hardware and Intel Hardware with hyperthreading, and is an issue
I plan to fix in the not too distant future.  (It is one of the quagmire
of issues relating to cpuid policies)

>
>> vcpu id, which may well not match the guest OS idea of CPU id.
> Can you elaborate more on the use case please? And why
> only restrict this to HVM guests? Why not PV?

PV guests unconditionally know their vcpu_id's right from the start, and
indeed need them to bring up APs.  HVM guests currently only know APIC IDs.

>
>> This patch adds vcpu id to the HVM cpuid leaf allowing the guest
>> to build a mapping.
> Don't we have existing hypercalls to get this? Ah VCPUOP_get_physid
> is what I was thinking of and that does not seem to be what
> you want?

This hypercall is only valid for pinned vcpus (i.e. only dom0 with
opt_dom0_vcpus_pin), and gives back the underlying APIC ID, and the ACPI
processor ID for that APIC ID.

The APIC ID can be obtained from cpuid as the vcpus are pinned, and the
ACPI ID can be obtained from the ACPI tables, as the domain is dom0. 
Ergo, this hypercall is quite redundant, has nothing at all to do with
the problem Paul is trying to solve, and appears buggy as it hands back
two 64bit values, shifted 32bits apart, in a 64bit integer.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 21:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 21:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmV21-0001Ex-TM; Thu, 06 Nov 2014 21:55:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XmV20-0001Es-Pd
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 21:55:52 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	F4/0B-23865-76EEB545; Thu, 06 Nov 2014 21:55:51 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415310950!7236008!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31093 invoked from network); 6 Nov 2014 21:55:51 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-9.tower-31.messagelabs.com with SMTP;
	6 Nov 2014 21:55:51 -0000
X-TM-IMSS-Message-ID: <c76eee300007233e@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 c76eee300007233e ;
	Thu, 6 Nov 2014 16:55:12 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA6LtRbj002067; 
	Thu, 6 Nov 2014 16:55:37 -0500
Message-ID: <545BEE4F.3080305@tycho.nsa.gov>
Date: Thu, 06 Nov 2014 16:55:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Emil Condrea <emilcondrea@gmail.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>
In-Reply-To: <1415181601.11486.69.camel@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/05/2014 05:00 AM, Ian Campbell wrote:
> CCing Daniel.
>
> On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
>>
>> I am wondering if this is known issue that when I set locality!=0 to
>> vtpmmgr it does not start. It is a bit strange that every call to
>> tpm_tis_status returns 255 and device-id is also FFFF:
>> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
>> TPM interface capabilities (0xffffffff):
>>
>> I am configuring vtpmmgr using:
>>
>> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
>> memory=8
>> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
>> name="vtpmmgr"
>> iomem=["fed40,5"]
>> extra="tpmlocality=2"
>>
>>
>> I also tried using :
>> iomem=["fed40,1"]
>> extra="tpmlocality=0"//works well
>>
>> or
>> iomem=["fed42,1"]
>> extra="tpmlocality=2"
>> It seems that everything that is not mapped at fed40-fed41 is
>> FFFFFFFF.
>>
>> I have an Atmel TPM chipset.
>>
>> Could it be a chipset problem to not handle well different localities?
>>
>> When I use locality=0, the device driver info is correct and
>> everything works fine:
>> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
>> TPM interface capabilities (0xfd)

This may be an issue with locality 2 being unavailable unless a DRTM
launch (tboot) is performed.  Returning all-ones is the normal response
of the x86 chipset when unmapped MMIO regions are accessed; disabled
localities of the TPM may act like this.

Does your system support the DRTM launch?  If so, can you test it to see
if this is the issue?

In this case, to better support people who want to use the vTPM Manager
without a DRTM launch, the features of the vTPM Manager that use the TPM
1.2 PCRs may need to be disabled or implemented in an alternate manner
such as embedding the data in the quote instead of in PCRs.  The current
design was created with the assumption that systems using it would be
performing a DRTM launch in order to fully secure the boot process.

>> In linux kernel this information is obtained using locality 0 and
>> after that other commands execute using specified locality.
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/tpm/tpm_tis.c#n558

Have you tested that other localities work for your TPM under Linux?

>>
>> Thanks,
>>
>> Emil
>>

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 21:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 21:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmV21-0001Ex-TM; Thu, 06 Nov 2014 21:55:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XmV20-0001Es-Pd
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 21:55:52 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	F4/0B-23865-76EEB545; Thu, 06 Nov 2014 21:55:51 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415310950!7236008!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31093 invoked from network); 6 Nov 2014 21:55:51 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-9.tower-31.messagelabs.com with SMTP;
	6 Nov 2014 21:55:51 -0000
X-TM-IMSS-Message-ID: <c76eee300007233e@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 c76eee300007233e ;
	Thu, 6 Nov 2014 16:55:12 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA6LtRbj002067; 
	Thu, 6 Nov 2014 16:55:37 -0500
Message-ID: <545BEE4F.3080305@tycho.nsa.gov>
Date: Thu, 06 Nov 2014 16:55:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Emil Condrea <emilcondrea@gmail.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>
In-Reply-To: <1415181601.11486.69.camel@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/05/2014 05:00 AM, Ian Campbell wrote:
> CCing Daniel.
>
> On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
>>
>> I am wondering if this is known issue that when I set locality!=0 to
>> vtpmmgr it does not start. It is a bit strange that every call to
>> tpm_tis_status returns 255 and device-id is also FFFF:
>> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
>> TPM interface capabilities (0xffffffff):
>>
>> I am configuring vtpmmgr using:
>>
>> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
>> memory=8
>> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
>> name="vtpmmgr"
>> iomem=["fed40,5"]
>> extra="tpmlocality=2"
>>
>>
>> I also tried using :
>> iomem=["fed40,1"]
>> extra="tpmlocality=0"//works well
>>
>> or
>> iomem=["fed42,1"]
>> extra="tpmlocality=2"
>> It seems that everything that is not mapped at fed40-fed41 is
>> FFFFFFFF.
>>
>> I have an Atmel TPM chipset.
>>
>> Could it be a chipset problem to not handle well different localities?
>>
>> When I use locality=0, the device driver info is correct and
>> everything works fine:
>> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
>> TPM interface capabilities (0xfd)

This may be an issue with locality 2 being unavailable unless a DRTM
launch (tboot) is performed.  Returning all-ones is the normal response
of the x86 chipset when unmapped MMIO regions are accessed; disabled
localities of the TPM may act like this.

Does your system support the DRTM launch?  If so, can you test it to see
if this is the issue?

In this case, to better support people who want to use the vTPM Manager
without a DRTM launch, the features of the vTPM Manager that use the TPM
1.2 PCRs may need to be disabled or implemented in an alternate manner
such as embedding the data in the quote instead of in PCRs.  The current
design was created with the assumption that systems using it would be
performing a DRTM launch in order to fully secure the boot process.

>> In linux kernel this information is obtained using locality 0 and
>> after that other commands execute using specified locality.
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/tpm/tpm_tis.c#n558

Have you tested that other localities work for your TPM under Linux?

>>
>> Thanks,
>>
>> Emil
>>

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 22:02:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 22:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmV82-0001Xu-NC; Thu, 06 Nov 2014 22:02:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XmV81-0001Xp-9c
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 22:02:05 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	F2/DF-26858-CDFEB545; Thu, 06 Nov 2014 22:02:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415311323!11005035!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21732 invoked from network); 6 Nov 2014 22:02:03 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-5.tower-31.messagelabs.com with SMTP;
	6 Nov 2014 22:02:03 -0000
X-TM-IMSS-Message-ID: <c7749ca700072446@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 c7749ca700072446 ;
	Thu, 6 Nov 2014 17:01:25 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA6M1ee6002801; 
	Thu, 6 Nov 2014 17:01:50 -0500
Message-ID: <545BEFC5.3010803@tycho.nsa.gov>
Date: Thu, 06 Nov 2014 17:01:41 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Emil Condrea <emilcondrea@gmail.com>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>	
	<545235EE.4040000@citrix.com>	
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
	<1415096148.11486.11.camel@citrix.com>
In-Reply-To: <1415096148.11486.11.camel@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2014 05:15 AM, Ian Campbell wrote:
> On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
>> Of course we can use max, but I thought that it might be useful to
>> have a prink to inform the user that the timeout was adjusted.
>> In init_tpm_tis the default timeouts are set using:
>> /* Set default timeouts */ tpm->timeout_a =
>> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
>> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
>> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
>> MILLISECS(TIS_SHORT_TIMEOUT);
>>
>>
>>
>> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
>> So if we want to integrate kernel changes I think we should use
>> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
>> Also in kernel the default timeouts are initialized using
>> msecs_to_jiffies which is different from MILLISECS
>> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
>> Is there a certain reason for not using msecs_to_jiffies ?
>
> jiffies are a Linux specific concept which mini-os doesn't share.
>
> Daniel, do you have any opinion on this patch?
>
> It seems like the Linux fix is made only for the specifically broken
> platform. That seems to make sense to me since presumably other systems
> report short timeouts which they can indeed cope with. It's only Atmel
> which brokenly reports something it cannot handle.
>
> Ian.

I agree that an adjustment is needed when values are too short.  Adjusting
in all cases is not quite as nice as only fixing the broken TPMs, but it
is a lot simpler.  It also doesn't seem harmful to have the timeouts be
too large in the driver: a properly functioning TPM will not time out its
requests in any case, so the user won't notice normally, and the default
short timeout is 0.75 seconds - very few people will complain if they have
to wait that long to get a timeout instead of what their TPM actually uses.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 22:02:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 22:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmV82-0001Xu-NC; Thu, 06 Nov 2014 22:02:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XmV81-0001Xp-9c
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 22:02:05 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	F2/DF-26858-CDFEB545; Thu, 06 Nov 2014 22:02:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415311323!11005035!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21732 invoked from network); 6 Nov 2014 22:02:03 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-5.tower-31.messagelabs.com with SMTP;
	6 Nov 2014 22:02:03 -0000
X-TM-IMSS-Message-ID: <c7749ca700072446@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 c7749ca700072446 ;
	Thu, 6 Nov 2014 17:01:25 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA6M1ee6002801; 
	Thu, 6 Nov 2014 17:01:50 -0500
Message-ID: <545BEFC5.3010803@tycho.nsa.gov>
Date: Thu, 06 Nov 2014 17:01:41 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Emil Condrea <emilcondrea@gmail.com>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>	
	<545235EE.4040000@citrix.com>	
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
	<1415096148.11486.11.camel@citrix.com>
In-Reply-To: <1415096148.11486.11.camel@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2014 05:15 AM, Ian Campbell wrote:
> On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
>> Of course we can use max, but I thought that it might be useful to
>> have a prink to inform the user that the timeout was adjusted.
>> In init_tpm_tis the default timeouts are set using:
>> /* Set default timeouts */ tpm->timeout_a =
>> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
>> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
>> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
>> MILLISECS(TIS_SHORT_TIMEOUT);
>>
>>
>>
>> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
>> So if we want to integrate kernel changes I think we should use
>> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
>> Also in kernel the default timeouts are initialized using
>> msecs_to_jiffies which is different from MILLISECS
>> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
>> Is there a certain reason for not using msecs_to_jiffies ?
>
> jiffies are a Linux specific concept which mini-os doesn't share.
>
> Daniel, do you have any opinion on this patch?
>
> It seems like the Linux fix is made only for the specifically broken
> platform. That seems to make sense to me since presumably other systems
> report short timeouts which they can indeed cope with. It's only Atmel
> which brokenly reports something it cannot handle.
>
> Ian.

I agree that an adjustment is needed when values are too short.  Adjusting
in all cases is not quite as nice as only fixing the broken TPMs, but it
is a lot simpler.  It also doesn't seem harmful to have the timeouts be
too large in the driver: a properly functioning TPM will not time out its
requests in any case, so the user won't notice normally, and the default
short timeout is 0.75 seconds - very few people will complain if they have
to wait that long to get a timeout instead of what their TPM actually uses.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 22:05:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 22: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 1XmVBb-0001fh-AD; Thu, 06 Nov 2014 22:05: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@citrix.com>) id 1XmVBa-0001fb-6g
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 22:05:46 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	34/7E-09284-9B0FB545; Thu, 06 Nov 2014 22:05:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415311540!8520098!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11672 invoked from network); 6 Nov 2014 22:05:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 22:05:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,328,1413244800"; d="scan'208";a="188951832"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 6 Nov 2014 17:05:25 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmVBF-0005qf-BQ;
	Thu, 06 Nov 2014 22:05:25 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmVAn-0002ek-Qj;
	Thu, 06 Nov 2014 22:05:02 +0000
Date: Thu, 6 Nov 2014 22:04:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31406-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31406: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31406 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31406/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl            5 xen-boot                    fail pass in 31385
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-i386-i386-pv             5 xen-boot           fail in 31385 pass in 31406
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot   fail in 31385 pass in 31406
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31406
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31406
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31406

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 22:05:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 22: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 1XmVBb-0001fh-AD; Thu, 06 Nov 2014 22:05: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@citrix.com>) id 1XmVBa-0001fb-6g
	for xen-devel@lists.xensource.com; Thu, 06 Nov 2014 22:05:46 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	34/7E-09284-9B0FB545; Thu, 06 Nov 2014 22:05:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415311540!8520098!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11672 invoked from network); 6 Nov 2014 22:05:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 22:05:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,328,1413244800"; d="scan'208";a="188951832"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 6 Nov 2014 17:05:25 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmVBF-0005qf-BQ;
	Thu, 06 Nov 2014 22:05:25 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmVAn-0002ek-Qj;
	Thu, 06 Nov 2014 22:05:02 +0000
Date: Thu, 6 Nov 2014 22:04:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31406-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31406: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31406 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31406/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl            5 xen-boot                    fail pass in 31385
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-i386-i386-pv             5 xen-boot           fail in 31385 pass in 31406
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot   fail in 31385 pass in 31406
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31406
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31406
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31406

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 22:18:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 22:18:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmVNG-0001w6-PI; Thu, 06 Nov 2014 22:17:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XmVNF-0001w1-GM
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 22:17:49 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	65/19-23865-C83FB545; Thu, 06 Nov 2014 22:17:48 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415312266!11012220!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6874 invoked from network); 6 Nov 2014 22:17:48 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 22:17:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA6MHiO2005334
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Thu, 6 Nov 2014 22:17:45 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6MHiPq019436
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xenproject.org>; Thu, 6 Nov 2014 22:17:44 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA6MHhi0022079
	for <xen-devel@lists.xenproject.org>; Thu, 6 Nov 2014 22:17:44 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Nov 2014 14:17:43 -0800
Message-ID: <545BF386.1050106@oracle.com>
Date: Thu, 06 Nov 2014 17:17:42 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xenproject.org>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I get this error:

    # xl mem-max 3 700
    libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max
    : Success
    cannot set domid 3 static max memory to : 700

    # xenstore-ls -f
    ...
    /local/domain/3/memory = ""
    /local/domain/3/memory/static-max = "716800"
    /local/domain/3/memory/target = "716801"
    /local/domain/3/memory/videoram = "-1"

    # xl list -l 3
    [
        {
            "domid": 3,
            "config": {
                "c_info": {
                    "type": "pv",
                    "name": "0004fb0000060000834f0ecf044b2219",
                    "uuid": "0004fb00-0006-0000-834f-0ecf044b2219",
                    "run_hotplug_scripts": "True"
                },
                "b_info": {
                    "max_vcpus": 32,
                    "avail_vcpus": [
                        0,
                        1
                    ],
                    "max_memkb": 716800,
                    "target_memkb": 716800,
                    "shadow_memkb": 38368,
                    "sched_params": {
                        "weight": 55000
                    },
                    "claim_mode": "True",
                    "type.pv": {
                        "bootloader": "/usr/bin/pygrub"
                    }
                },
                "disks": [
                    {
                        "pdev_path": "/OVS/Repositories/0004fb0000030000abbd129258377a77/VirtualDisks/OVM_OL6U4_X86_64_PVM_2GB_UEK3_System.img",
                        "vdev": "xvda",
                        "format": "raw",
                        "readwrite": 1
                    }
                ],
                "nics": [
                    {
                        "devid": 0,
                        "mac": "00:21:f6:00:08:aa",
                        "bridge": "10f36ca5ec"
                    }
                ],
                "vfbs": [
                    {
                        "devid": 0,
                        "vnc": {
                            "listen": "127.0.0.1",
                            "findunused": "True"
                        },
                        "sdl": {
    
                        },
                        "keymap": "en-us"
                    }
                ],
                "vkbs": [
                    {
                        "devid": 0
                    }
                ],
                "on_reboot": "restart",
                "on_crash": "restart"
            }
        }
    ]

Another HVM guest::

    # xenstore-ls -f
    ...
    /local/domain/2/memory/static-max = "716800"
    /local/domain/2/memory/target = "708608"
    /local/domain/2/memory/videoram = "8192"

Testing on:

    commit 816f5bb1f0740be8355e1be6cc24edf09547d984
    Author: Ian Campbell <ian.campbell@citrix.com>
    Date:   Fri Oct 24 10:58:33 2014 +0100

It seems target_mem always bigger than max_mem. Looks wrong.

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 22:18:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 22:18:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmVNG-0001w6-PI; Thu, 06 Nov 2014 22:17:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XmVNF-0001w1-GM
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 22:17:49 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	65/19-23865-C83FB545; Thu, 06 Nov 2014 22:17:48 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415312266!11012220!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6874 invoked from network); 6 Nov 2014 22:17:48 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 22:17:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA6MHiO2005334
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Thu, 6 Nov 2014 22:17:45 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA6MHiPq019436
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xenproject.org>; Thu, 6 Nov 2014 22:17:44 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA6MHhi0022079
	for <xen-devel@lists.xenproject.org>; Thu, 6 Nov 2014 22:17:44 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Nov 2014 14:17:43 -0800
Message-ID: <545BF386.1050106@oracle.com>
Date: Thu, 06 Nov 2014 17:17:42 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xenproject.org>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I get this error:

    # xl mem-max 3 700
    libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max
    : Success
    cannot set domid 3 static max memory to : 700

    # xenstore-ls -f
    ...
    /local/domain/3/memory = ""
    /local/domain/3/memory/static-max = "716800"
    /local/domain/3/memory/target = "716801"
    /local/domain/3/memory/videoram = "-1"

    # xl list -l 3
    [
        {
            "domid": 3,
            "config": {
                "c_info": {
                    "type": "pv",
                    "name": "0004fb0000060000834f0ecf044b2219",
                    "uuid": "0004fb00-0006-0000-834f-0ecf044b2219",
                    "run_hotplug_scripts": "True"
                },
                "b_info": {
                    "max_vcpus": 32,
                    "avail_vcpus": [
                        0,
                        1
                    ],
                    "max_memkb": 716800,
                    "target_memkb": 716800,
                    "shadow_memkb": 38368,
                    "sched_params": {
                        "weight": 55000
                    },
                    "claim_mode": "True",
                    "type.pv": {
                        "bootloader": "/usr/bin/pygrub"
                    }
                },
                "disks": [
                    {
                        "pdev_path": "/OVS/Repositories/0004fb0000030000abbd129258377a77/VirtualDisks/OVM_OL6U4_X86_64_PVM_2GB_UEK3_System.img",
                        "vdev": "xvda",
                        "format": "raw",
                        "readwrite": 1
                    }
                ],
                "nics": [
                    {
                        "devid": 0,
                        "mac": "00:21:f6:00:08:aa",
                        "bridge": "10f36ca5ec"
                    }
                ],
                "vfbs": [
                    {
                        "devid": 0,
                        "vnc": {
                            "listen": "127.0.0.1",
                            "findunused": "True"
                        },
                        "sdl": {
    
                        },
                        "keymap": "en-us"
                    }
                ],
                "vkbs": [
                    {
                        "devid": 0
                    }
                ],
                "on_reboot": "restart",
                "on_crash": "restart"
            }
        }
    ]

Another HVM guest::

    # xenstore-ls -f
    ...
    /local/domain/2/memory/static-max = "716800"
    /local/domain/2/memory/target = "708608"
    /local/domain/2/memory/videoram = "8192"

Testing on:

    commit 816f5bb1f0740be8355e1be6cc24edf09547d984
    Author: Ian Campbell <ian.campbell@citrix.com>
    Date:   Fri Oct 24 10:58:33 2014 +0100

It seems target_mem always bigger than max_mem. Looks wrong.

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 23:14:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 23:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmWFL-0002yu-8O; Thu, 06 Nov 2014 23:13:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=NwjR=74=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1XmWFJ-0002yp-OG
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 23:13:41 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	F0/B4-02698-5A00C545; Thu, 06 Nov 2014 23:13:41 +0000
X-Env-Sender: SRS0=NwjR=74=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415315620!11927658!1
X-Originating-IP: [140.77.166.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18170 invoked from network); 6 Nov 2014 23:13:40 -0000
Received: from domu-toccata.ens-lyon.fr (HELO sonata.ens-lyon.org)
	(140.77.166.138)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 23:13:40 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id BF8CC200BB;
	Fri,  7 Nov 2014 00:13:39 +0100 (CET)
Received: from sonata.ens-lyon.org ([127.0.0.1])
	by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id FwBwUVekhL45; Fri,  7 Nov 2014 00:13:39 +0100 (CET)
Received: from type.youpi.perso.aquilenet.fr (youpi.perso.aquilenet.fr
	[80.67.176.89])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by sonata.ens-lyon.org (Postfix) with ESMTPSA id 91424200B4;
	Fri,  7 Nov 2014 00:13:39 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1XmWFF-0004rA-O7; Fri, 07 Nov 2014 00:13:37 +0100
Date: Fri, 7 Nov 2014 00:13:37 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141106231337.GN3072@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xen.org,
	netwiz@crc.id.au
References: <alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
	<20141106113923.GA3182@type.bordeaux.inria.fr>
	<alpine.DEB.2.02.1411061543170.22875@kaball.uk.xensource.com>
	<20141106193611.GC5906@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Length: 341
Content-Disposition: inline
In-Reply-To: <20141106193611.GC5906@laptop.dumpdata.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xen.org,
	netwiz@crc.id.au, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk, le Thu 06 Nov 2014 14:36:11 -0500, a =E9crit :
> Regardless I believe this should go in. But more importantly - can
> this also go upstream?

There is no upstream for grub1 any more.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 23:14:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 23:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmWFL-0002yu-8O; Thu, 06 Nov 2014 23:13:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=NwjR=74=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1XmWFJ-0002yp-OG
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 23:13:41 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	F0/B4-02698-5A00C545; Thu, 06 Nov 2014 23:13:41 +0000
X-Env-Sender: SRS0=NwjR=74=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415315620!11927658!1
X-Originating-IP: [140.77.166.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18170 invoked from network); 6 Nov 2014 23:13:40 -0000
Received: from domu-toccata.ens-lyon.fr (HELO sonata.ens-lyon.org)
	(140.77.166.138)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 23:13:40 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id BF8CC200BB;
	Fri,  7 Nov 2014 00:13:39 +0100 (CET)
Received: from sonata.ens-lyon.org ([127.0.0.1])
	by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id FwBwUVekhL45; Fri,  7 Nov 2014 00:13:39 +0100 (CET)
Received: from type.youpi.perso.aquilenet.fr (youpi.perso.aquilenet.fr
	[80.67.176.89])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by sonata.ens-lyon.org (Postfix) with ESMTPSA id 91424200B4;
	Fri,  7 Nov 2014 00:13:39 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1XmWFF-0004rA-O7; Fri, 07 Nov 2014 00:13:37 +0100
Date: Fri, 7 Nov 2014 00:13:37 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141106231337.GN3072@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xen.org,
	netwiz@crc.id.au
References: <alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
	<20141106113923.GA3182@type.bordeaux.inria.fr>
	<alpine.DEB.2.02.1411061543170.22875@kaball.uk.xensource.com>
	<20141106193611.GC5906@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Length: 341
Content-Disposition: inline
In-Reply-To: <20141106193611.GC5906@laptop.dumpdata.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xen.org,
	netwiz@crc.id.au, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk, le Thu 06 Nov 2014 14:36:11 -0500, a =E9crit :
> Regardless I believe this should go in. But more importantly - can
> this also go upstream?

There is no upstream for grub1 any more.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 23:20:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 23: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.xen.org>)
	id 1XmWLu-00037I-3t; Thu, 06 Nov 2014 23:20:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XmWLs-00037C-Bo
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 23:20:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	62/CF-24532-B320C545; Thu, 06 Nov 2014 23:20:27 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415316026!12093151!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2993 invoked from network); 6 Nov 2014 23:20:27 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 23:20:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415316025; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : Subject :
	References : In-Reply-To : Content-Type : Content-Transfer-Encoding;
	bh=S/Eddn14qYyyiwlb4kax6fFuaoDay02KqwnEAZ/6Og4=;
	b=TjCmwBu1ElZpKh30KeWRUoNrBYIlDBO/G+/a+TnojmNhqI/Vlm4NpNnb3kVK86GGULOhd5hoiJyoJgDnYgu7eZe453ezOLbYzwhhDQCCQUY6PVDVBLWN5h9KGMhi/+tU1+7ZkpL2CtpQwGvgb4jeZ416K0WmJO2twwSOxyIaR3g=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Thu, 06 Nov 2014 15:20:24 -0800
	id 00000000000305BD.545C0238.0000543E
Message-ID: <545C022B.5050601@ihonk.com>
Date: Thu, 06 Nov 2014 15:20:11 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org,
	=?windows-1252?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>,
	Jan Beulich <jbeulich@suse.com>
References: <5457F79B.2020300@ihonk.com> <5458E521.2030002@terremark.com>
In-Reply-To: <5458E521.2030002@terremark.com>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Don,

On 11/4/2014 6:39, Don Slutz wrote:
>
> I would also see if less guest ram (like 3.0 GiB) can still reproduce 
> the issue.

Still working on getting serial logging set up, but I was just able to 
verify that 3.0 GiB of guest RAM reproduces the issue.

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 06 23:20:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Nov 2014 23: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.xen.org>)
	id 1XmWLu-00037I-3t; Thu, 06 Nov 2014 23:20:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XmWLs-00037C-Bo
	for xen-devel@lists.xen.org; Thu, 06 Nov 2014 23:20:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	62/CF-24532-B320C545; Thu, 06 Nov 2014 23:20:27 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415316026!12093151!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2993 invoked from network); 6 Nov 2014 23:20:27 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Nov 2014 23:20:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415316025; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : Subject :
	References : In-Reply-To : Content-Type : Content-Transfer-Encoding;
	bh=S/Eddn14qYyyiwlb4kax6fFuaoDay02KqwnEAZ/6Og4=;
	b=TjCmwBu1ElZpKh30KeWRUoNrBYIlDBO/G+/a+TnojmNhqI/Vlm4NpNnb3kVK86GGULOhd5hoiJyoJgDnYgu7eZe453ezOLbYzwhhDQCCQUY6PVDVBLWN5h9KGMhi/+tU1+7ZkpL2CtpQwGvgb4jeZ416K0WmJO2twwSOxyIaR3g=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Thu, 06 Nov 2014 15:20:24 -0800
	id 00000000000305BD.545C0238.0000543E
Message-ID: <545C022B.5050601@ihonk.com>
Date: Thu, 06 Nov 2014 15:20:11 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org,
	=?windows-1252?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>,
	Jan Beulich <jbeulich@suse.com>
References: <5457F79B.2020300@ihonk.com> <5458E521.2030002@terremark.com>
In-Reply-To: <5458E521.2030002@terremark.com>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Don,

On 11/4/2014 6:39, Don Slutz wrote:
>
> I would also see if less guest ram (like 3.0 GiB) can still reproduce 
> the issue.

Still working on getting serial logging set up, but I was just able to 
verify that 3.0 GiB of guest RAM reproduces the issue.

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 01:47:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 01:47:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmYe4-0000eP-ON; Fri, 07 Nov 2014 01:47:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmYe3-0000eK-8Y
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 01:47:23 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	6A/30-14727-AA42C545; Fri, 07 Nov 2014 01:47:22 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415324841!5588697!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9478 invoked from network); 7 Nov 2014 01:47:21 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-14.tower-206.messagelabs.com with SMTP;
	7 Nov 2014 01:47:21 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 06 Nov 2014 17:45:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,329,1413270000"; d="scan'208";a="603862456"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 06 Nov 2014 17:47:18 -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.3.195.1; Fri, 7 Nov 2014 09:46:27 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.156]) with mapi id
	14.03.0195.001; Fri, 7 Nov 2014 09:46:26 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Emil Condrea
	<emilcondrea@gmail.com>
Thread-Topic: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
Thread-Index: AQHP+gyQogoroHdVBUOna8rL71CGzpxUYzsQ
Date: Fri, 7 Nov 2014 01:46:25 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com> <545BEE4F.3080305@tycho.nsa.gov>
In-Reply-To: <545BEE4F.3080305@tycho.nsa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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



> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Daniel De Graaf
> Sent: Friday, November 07, 2014 5:55 AM
> To: Emil Condrea
> Cc: Ian Campbell; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
> 
> On 11/05/2014 05:00 AM, Ian Campbell wrote:
> > CCing Daniel.
> >
> > On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
> >>
> >> I am wondering if this is known issue that when I set locality!=0 to
> >> vtpmmgr it does not start. It is a bit strange that every call to
> >> tpm_tis_status returns 255 and device-id is also FFFF:
> >> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
> >> TPM interface capabilities (0xffffffff):
> >>
> >> I am configuring vtpmmgr using:
> >>
> >> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
> >> memory=8
> >> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
> >> name="vtpmmgr"
> >> iomem=["fed40,5"]
> >> extra="tpmlocality=2"
> >>
> >>
> >> I also tried using :
> >> iomem=["fed40,1"]
> >> extra="tpmlocality=0"//works well
> >>
> >> or
> >> iomem=["fed42,1"]
> >> extra="tpmlocality=2"
> >> It seems that everything that is not mapped at fed40-fed41 is
> >> FFFFFFFF.
> >>
> >> I have an Atmel TPM chipset.
> >>
> >> Could it be a chipset problem to not handle well different localities?
> >>
> >> When I use locality=0, the device driver info is correct and
> >> everything works fine:
> >> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40) TPM interface
> >> capabilities (0xfd)
> 
> This may be an issue with locality 2 being unavailable unless a DRTM launch
> (tboot) is performed.  Returning all-ones is the normal response of the x86
> chipset when unmapped MMIO regions are accessed; disabled localities of
> the TPM may act like this.
> 
> Does your system support the DRTM launch?  If so, can you test it to see if
> this is the issue?


Emil,
tboot supports Intel and OEM systems that are Intel TXT-capable. 
If your system does not support DRTM launch, I can test it in next week. 


> 
> In this case, to better support people who want to use the vTPM Manager
> without a DRTM launch, the features of the vTPM Manager that use the TPM
> 1.2 PCRs may need to be disabled or implemented in an alternate manner
> such as embedding the data in the quote instead of in PCRs.  The current
> design was created with the assumption that systems using it would be
> performing a DRTM launch in order to fully secure the boot process.
> 
> >> In linux kernel this information is obtained using locality 0 and
> >> after that other commands execute using specified locality.
> >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/
> >> tree/drivers/char/tpm/tpm_tis.c#n558
> 
> Have you tested that other localities work for your TPM under Linux?
> 
> >>
> >> Thanks,
> >>
> >> Emil
> >>
> 
> --
> Daniel De Graaf
> National Security Agency
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 07 01:47:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 01:47:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmYe4-0000eP-ON; Fri, 07 Nov 2014 01:47:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XmYe3-0000eK-8Y
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 01:47:23 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	6A/30-14727-AA42C545; Fri, 07 Nov 2014 01:47:22 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415324841!5588697!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9478 invoked from network); 7 Nov 2014 01:47:21 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-14.tower-206.messagelabs.com with SMTP;
	7 Nov 2014 01:47:21 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 06 Nov 2014 17:45:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,329,1413270000"; d="scan'208";a="603862456"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 06 Nov 2014 17:47:18 -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.3.195.1; Fri, 7 Nov 2014 09:46:27 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.156]) with mapi id
	14.03.0195.001; Fri, 7 Nov 2014 09:46:26 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Emil Condrea
	<emilcondrea@gmail.com>
Thread-Topic: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
Thread-Index: AQHP+gyQogoroHdVBUOna8rL71CGzpxUYzsQ
Date: Fri, 7 Nov 2014 01:46:25 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com> <545BEE4F.3080305@tycho.nsa.gov>
In-Reply-To: <545BEE4F.3080305@tycho.nsa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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



> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Daniel De Graaf
> Sent: Friday, November 07, 2014 5:55 AM
> To: Emil Condrea
> Cc: Ian Campbell; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
> 
> On 11/05/2014 05:00 AM, Ian Campbell wrote:
> > CCing Daniel.
> >
> > On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
> >>
> >> I am wondering if this is known issue that when I set locality!=0 to
> >> vtpmmgr it does not start. It is a bit strange that every call to
> >> tpm_tis_status returns 255 and device-id is also FFFF:
> >> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
> >> TPM interface capabilities (0xffffffff):
> >>
> >> I am configuring vtpmmgr using:
> >>
> >> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
> >> memory=8
> >> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
> >> name="vtpmmgr"
> >> iomem=["fed40,5"]
> >> extra="tpmlocality=2"
> >>
> >>
> >> I also tried using :
> >> iomem=["fed40,1"]
> >> extra="tpmlocality=0"//works well
> >>
> >> or
> >> iomem=["fed42,1"]
> >> extra="tpmlocality=2"
> >> It seems that everything that is not mapped at fed40-fed41 is
> >> FFFFFFFF.
> >>
> >> I have an Atmel TPM chipset.
> >>
> >> Could it be a chipset problem to not handle well different localities?
> >>
> >> When I use locality=0, the device driver info is correct and
> >> everything works fine:
> >> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40) TPM interface
> >> capabilities (0xfd)
> 
> This may be an issue with locality 2 being unavailable unless a DRTM launch
> (tboot) is performed.  Returning all-ones is the normal response of the x86
> chipset when unmapped MMIO regions are accessed; disabled localities of
> the TPM may act like this.
> 
> Does your system support the DRTM launch?  If so, can you test it to see if
> this is the issue?


Emil,
tboot supports Intel and OEM systems that are Intel TXT-capable. 
If your system does not support DRTM launch, I can test it in next week. 


> 
> In this case, to better support people who want to use the vTPM Manager
> without a DRTM launch, the features of the vTPM Manager that use the TPM
> 1.2 PCRs may need to be disabled or implemented in an alternate manner
> such as embedding the data in the quote instead of in PCRs.  The current
> design was created with the assumption that systems using it would be
> performing a DRTM launch in order to fully secure the boot process.
> 
> >> In linux kernel this information is obtained using locality 0 and
> >> after that other commands execute using specified locality.
> >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/
> >> tree/drivers/char/tpm/tpm_tis.c#n558
> 
> Have you tested that other localities work for your TPM under Linux?
> 
> >>
> >> Thanks,
> >>
> >> Emil
> >>
> 
> --
> Daniel De Graaf
> National Security Agency
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 07 06:52:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 06:52:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmdOa-00032S-I6; Fri, 07 Nov 2014 06:51:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmdOZ-00032L-89
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 06:51:43 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	36/05-02699-EFB6C545; Fri, 07 Nov 2014 06:51:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415343100!11976692!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6404 invoked from network); 7 Nov 2014 06:51:41 -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;
	7 Nov 2014 06:51:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,330,1413244800"; d="scan'208";a="190473315"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 01:51:38 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmdOU-0008Qp-8J;
	Fri, 07 Nov 2014 06:51:38 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmdOU-0002r2-02;
	Fri, 07 Nov 2014 06:51:38 +0000
Date: Fri, 7 Nov 2014 06:51:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31411-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31411: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31411 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31411/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 06:52:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 06:52:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmdOa-00032S-I6; Fri, 07 Nov 2014 06:51:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmdOZ-00032L-89
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 06:51:43 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	36/05-02699-EFB6C545; Fri, 07 Nov 2014 06:51:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415343100!11976692!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6404 invoked from network); 7 Nov 2014 06:51:41 -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;
	7 Nov 2014 06:51:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,330,1413244800"; d="scan'208";a="190473315"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 01:51:38 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmdOU-0008Qp-8J;
	Fri, 07 Nov 2014 06:51:38 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmdOU-0002r2-02;
	Fri, 07 Nov 2014 06:51:38 +0000
Date: Fri, 7 Nov 2014 06:51:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31411-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31411: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31411 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31411/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 06:53:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 06:53:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmdQY-0003Am-Bm; Fri, 07 Nov 2014 06:53:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmdQW-0003Af-Uy
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 06:53:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EB/B8-09842-87C6C545; Fri, 07 Nov 2014 06:53:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415343222!11768493!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26490 invoked from network); 7 Nov 2014 06:53:43 -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;
	7 Nov 2014 06:53:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,330,1413244800"; d="scan'208";a="189047506"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 01:53:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmdQS-0008RQ-VB;
	Fri, 07 Nov 2014 06:53:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmdQS-0004Y6-Me;
	Fri, 07 Nov 2014 06:53:40 +0000
Date: Fri, 7 Nov 2014 06:53:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31419-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31419: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31419 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31419/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              5 kernel-build              fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Fri Nov 07 06:53:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 06:53:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmdQY-0003Am-Bm; Fri, 07 Nov 2014 06:53:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmdQW-0003Af-Uy
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 06:53:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EB/B8-09842-87C6C545; Fri, 07 Nov 2014 06:53:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415343222!11768493!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26490 invoked from network); 7 Nov 2014 06:53:43 -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;
	7 Nov 2014 06:53:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,330,1413244800"; d="scan'208";a="189047506"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 01:53:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmdQS-0008RQ-VB;
	Fri, 07 Nov 2014 06:53:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmdQS-0004Y6-Me;
	Fri, 07 Nov 2014 06:53:40 +0000
Date: Fri, 7 Nov 2014 06:53:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31419-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31419: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31419 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31419/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              5 kernel-build              fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Fri Nov 07 07:17:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 07:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmdnB-0003dp-9l; Fri, 07 Nov 2014 07:17:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xmdn9-0003dh-Iv
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 07:17:07 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	CC/6A-02698-2F17C545; Fri, 07 Nov 2014 07:17:06 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415344625!11980355!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2026 invoked from network); 7 Nov 2014 07:17:05 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-27.messagelabs.com with SMTP;
	7 Nov 2014 07:17:05 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 06 Nov 2014 23:15:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,330,1413270000"; d="scan'208";a="603966858"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 06 Nov 2014 23:17:02 -0800
Received: from pgsmsx106.gar.corp.intel.com (10.221.44.98) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 7 Nov 2014 15:15:09 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 7 Nov 2014 15:15:09 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.156]) with mapi id
	14.03.0195.001; Fri, 7 Nov 2014 15:15:08 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Thread-Topic: FW: [PATCH 1/6]  vTPM: event channel bind interdomain with
	para/hvm virtual machine
Thread-Index: AQHP9DbGM7cWOHWQDECdt6BGyNN1jZxIva0Q//+yl4CAC19FUIAA7NAw
Date: Fri, 7 Nov 2014 07:15:07 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820FCB@SHSMSX101.ccr.corp.intel.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<1414654731-32641-2-git-send-email-quan.xu@intel.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81D119@SHSMSX101.ccr.corp.intel.com>
	<54528379.5080107@tycho.nsa.gov>
	<945CA011AD5F084CBEA3E851C0AB28890E820D74@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E820D74@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: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] FW: [PATCH 1/6] vTPM: event channel bind
 interdomain with para/hvm virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Xu, Quan
> Sent: Friday, November 07, 2014 12:56 AM
> To: Daniel De Graaf
> Cc: samuel.thibault@ens-lyon.org; xen-devel@lists.xen.org; Xu, Quan
> Subject: RE: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> para/hvm virtual machine
> 
> 
> 
> > -----Original Message-----
> > From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> > Sent: Friday, October 31, 2014 2:29 AM
> > To: Xu, Quan
> > Cc: samuel.thibault@ens-lyon.org
> > Subject: Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> > para/hvm virtual machine
> >
> > On 10/30/2014 11:06 AM, Xu, Quan wrote:
> > [...]
> > >> +   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
> >
> > This seems to preclude the use of stub domain device models for HVM
> > domains; in that case, the event channel/grant page would need to be
> > mapped to the stub domain.  I think it may be better to pass in the
> > target domain ID in xenstore rather than overriding it based on PV vs
> > HVM.  In any case, in order to support HVM domains with PV drivers, an
> > additional backend/frontend pair is required for QEMU rather than
> > redirecting the existing vTPM to the device model's domain.
> >
> 
> Thanks Graaf.
> HVM domains are still runing tpm_tis.ko driver or Windows TPM 1.2 driver,
> as they run on physical machine.
> When I tried to enable vTPM for HVM domains, I pass in the target domain
> ID in XenStore too, but it is not working. because the vTPM frontend is
> implemented in QEMU.
> 
> For HVM domains, QEMU is running in Dom0 as usual. So the domid shoud
> be 0.
> some requirement from local ISV, they need vTPM for unmodified domain in
> virtual desktop infrastructure.
> 
> > I would suggest attaching the vTPM directly to domain 0, but that
> > would cause the vTPM to be picked up by the dom0 kernel instead of by
> > QEMU, so that is not helpful.  If there is an existing solution for
> > disk or network driver domains attached to HVM, the solution used
> > there should be mirrored here; I have not looked to see how (or if) it is
> solved in those drivers.
> >
> In this patch series, It is a solution for HVM domains.
> I am very pleased if we can collaborate to enhance / modify it in coming Xen
> version(4.7 or ..)
> 
> > A solution needs to be able to handle:
> >
> > 1. Existing PV domains
> 
> Yes, it is compatible with pv domains or non-vtpm domains.
> 
> > 2. HVM domain using TIS MMIO and no stubdom - without special casing
> > dom0 3. HVM domain using TIS MMIO via a stubdom
> 
> Now the TIS MMIO is registered in Qemu.
> 
> 
> >4. Linux HVM domain
> > with the PV vTPM driver (talks directly to the vTPM)
> 
> I did not have available physical machine. It is still building the domu kernel
> with PV vTPM driver.
> I guess, there may be /dev/tpm0 and /dev/tpm1 I will share the test result
> tomorrow

Graaf, the test result:
1. tpm_tis.ko / xen_tpmfront.ko are both enabled. 
  PV vTPM driver is running in guest domain.
# lsmod | grep xen_tpmfront
xen_tpmfront  6202  0

vtpm backend in xenstore:
backend = ""
    vtpm = ""
     9 = ""
      0 = ""
        [...]

Vtpm frontend in xenstore:
    vtpm = ""
     0 = ""
      [...]
      domain-type = "1"
      [...]
the domain type is 1, so HVM frontend vTPM driver is running.  
(  #define T_DOMAIN_TYPE_HVM 1
  #define T_DOMAIN_TYPE_PV  2
)




> 
> >
> > Similar to network and disk, when an OS that understands Xen devices
> > finds a vTPM interface, it should detach/ignore the MMIO TPM interface.
> > The vTPM domain is set up to handle this case: multiple connections to
> > a single vTPM domain are permitted and will all talk to the same TPM
> instance.
> 
> Yes, pv domains and hvm domains can talk to the same TPM instance.
> 
> > Locality restrictions are based on the event channel endpoint, and so
> > will still work even when tpmif->domid is incorrect; this is required
> > to properly implement the DRTM if it is to be emulated.
> 
> 
> Graaf, I will read your suggestion again and again. I have not read your new
> feature in Docs/misc/vtpm-platforms.txt.
> I am still committing some other features, And dealing with some review
> comments.
> BTW, could you share some document about disk_io in stubdom/vtpmmgr.
> I enabled vtpmmgr on TPM 2.0 based on Xen 4.3.0. try to get rooted trust on
> TPM 2.0 .
> it is not working now, as you changed disk io.
> 
> 
> 
> >
> > --
> > Daniel De Graaf
> > National Security Agency
> 
> 
> Thanks
> Quan Xu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 07:17:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 07:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmdnB-0003dp-9l; Fri, 07 Nov 2014 07:17:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xmdn9-0003dh-Iv
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 07:17:07 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	CC/6A-02698-2F17C545; Fri, 07 Nov 2014 07:17:06 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415344625!11980355!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2026 invoked from network); 7 Nov 2014 07:17:05 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-27.messagelabs.com with SMTP;
	7 Nov 2014 07:17:05 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 06 Nov 2014 23:15:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,330,1413270000"; d="scan'208";a="603966858"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 06 Nov 2014 23:17:02 -0800
Received: from pgsmsx106.gar.corp.intel.com (10.221.44.98) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 7 Nov 2014 15:15:09 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 7 Nov 2014 15:15:09 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.156]) with mapi id
	14.03.0195.001; Fri, 7 Nov 2014 15:15:08 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Thread-Topic: FW: [PATCH 1/6]  vTPM: event channel bind interdomain with
	para/hvm virtual machine
Thread-Index: AQHP9DbGM7cWOHWQDECdt6BGyNN1jZxIva0Q//+yl4CAC19FUIAA7NAw
Date: Fri, 7 Nov 2014 07:15:07 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E820FCB@SHSMSX101.ccr.corp.intel.com>
References: <1414654731-32641-1-git-send-email-quan.xu@intel.com>
	<1414654731-32641-2-git-send-email-quan.xu@intel.com>
	<945CA011AD5F084CBEA3E851C0AB28890E81D119@SHSMSX101.ccr.corp.intel.com>
	<54528379.5080107@tycho.nsa.gov>
	<945CA011AD5F084CBEA3E851C0AB28890E820D74@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E820D74@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: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] FW: [PATCH 1/6] vTPM: event channel bind
 interdomain with para/hvm virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Xu, Quan
> Sent: Friday, November 07, 2014 12:56 AM
> To: Daniel De Graaf
> Cc: samuel.thibault@ens-lyon.org; xen-devel@lists.xen.org; Xu, Quan
> Subject: RE: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> para/hvm virtual machine
> 
> 
> 
> > -----Original Message-----
> > From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> > Sent: Friday, October 31, 2014 2:29 AM
> > To: Xu, Quan
> > Cc: samuel.thibault@ens-lyon.org
> > Subject: Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> > para/hvm virtual machine
> >
> > On 10/30/2014 11:06 AM, Xu, Quan wrote:
> > [...]
> > >> +   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
> >
> > This seems to preclude the use of stub domain device models for HVM
> > domains; in that case, the event channel/grant page would need to be
> > mapped to the stub domain.  I think it may be better to pass in the
> > target domain ID in xenstore rather than overriding it based on PV vs
> > HVM.  In any case, in order to support HVM domains with PV drivers, an
> > additional backend/frontend pair is required for QEMU rather than
> > redirecting the existing vTPM to the device model's domain.
> >
> 
> Thanks Graaf.
> HVM domains are still runing tpm_tis.ko driver or Windows TPM 1.2 driver,
> as they run on physical machine.
> When I tried to enable vTPM for HVM domains, I pass in the target domain
> ID in XenStore too, but it is not working. because the vTPM frontend is
> implemented in QEMU.
> 
> For HVM domains, QEMU is running in Dom0 as usual. So the domid shoud
> be 0.
> some requirement from local ISV, they need vTPM for unmodified domain in
> virtual desktop infrastructure.
> 
> > I would suggest attaching the vTPM directly to domain 0, but that
> > would cause the vTPM to be picked up by the dom0 kernel instead of by
> > QEMU, so that is not helpful.  If there is an existing solution for
> > disk or network driver domains attached to HVM, the solution used
> > there should be mirrored here; I have not looked to see how (or if) it is
> solved in those drivers.
> >
> In this patch series, It is a solution for HVM domains.
> I am very pleased if we can collaborate to enhance / modify it in coming Xen
> version(4.7 or ..)
> 
> > A solution needs to be able to handle:
> >
> > 1. Existing PV domains
> 
> Yes, it is compatible with pv domains or non-vtpm domains.
> 
> > 2. HVM domain using TIS MMIO and no stubdom - without special casing
> > dom0 3. HVM domain using TIS MMIO via a stubdom
> 
> Now the TIS MMIO is registered in Qemu.
> 
> 
> >4. Linux HVM domain
> > with the PV vTPM driver (talks directly to the vTPM)
> 
> I did not have available physical machine. It is still building the domu kernel
> with PV vTPM driver.
> I guess, there may be /dev/tpm0 and /dev/tpm1 I will share the test result
> tomorrow

Graaf, the test result:
1. tpm_tis.ko / xen_tpmfront.ko are both enabled. 
  PV vTPM driver is running in guest domain.
# lsmod | grep xen_tpmfront
xen_tpmfront  6202  0

vtpm backend in xenstore:
backend = ""
    vtpm = ""
     9 = ""
      0 = ""
        [...]

Vtpm frontend in xenstore:
    vtpm = ""
     0 = ""
      [...]
      domain-type = "1"
      [...]
the domain type is 1, so HVM frontend vTPM driver is running.  
(  #define T_DOMAIN_TYPE_HVM 1
  #define T_DOMAIN_TYPE_PV  2
)




> 
> >
> > Similar to network and disk, when an OS that understands Xen devices
> > finds a vTPM interface, it should detach/ignore the MMIO TPM interface.
> > The vTPM domain is set up to handle this case: multiple connections to
> > a single vTPM domain are permitted and will all talk to the same TPM
> instance.
> 
> Yes, pv domains and hvm domains can talk to the same TPM instance.
> 
> > Locality restrictions are based on the event channel endpoint, and so
> > will still work even when tpmif->domid is incorrect; this is required
> > to properly implement the DRTM if it is to be emulated.
> 
> 
> Graaf, I will read your suggestion again and again. I have not read your new
> feature in Docs/misc/vtpm-platforms.txt.
> I am still committing some other features, And dealing with some review
> comments.
> BTW, could you share some document about disk_io in stubdom/vtpmmgr.
> I enabled vtpmmgr on TPM 2.0 based on Xen 4.3.0. try to get rooted trust on
> TPM 2.0 .
> it is not working now, as you changed disk io.
> 
> 
> 
> >
> > --
> > Daniel De Graaf
> > National Security Agency
> 
> 
> Thanks
> Quan Xu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 08:17:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 08:17:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmejM-0004VN-D4; Fri, 07 Nov 2014 08:17:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tomi.valkeinen@ti.com>) id 1XmejL-0004VI-4V
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 08:17:15 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	88/2F-17694-9008C545; Fri, 07 Nov 2014 08:17:13 +0000
X-Env-Sender: tomi.valkeinen@ti.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415348231!11029634!1
X-Originating-IP: [192.94.94.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQwID0+IDE3MDg0MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24837 invoked from network); 7 Nov 2014 08:17:13 -0000
Received: from arroyo.ext.ti.com (HELO arroyo.ext.ti.com) (192.94.94.40)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 08:17:13 -0000
Received: from dflxv15.itg.ti.com ([128.247.5.124])
	by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id sA78GqLa031743;
	Fri, 7 Nov 2014 02:16:52 -0600
Received: from DLEE71.ent.ti.com (dlee71.ent.ti.com [157.170.170.114])
	by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id sA78GqSh026341;
	Fri, 7 Nov 2014 02:16:52 -0600
Received: from dflp33.itg.ti.com (10.64.6.16) by DLEE71.ent.ti.com
	(157.170.170.114) with Microsoft SMTP Server id 14.3.174.1;
	Fri, 7 Nov 2014 02:16:51 -0600
Received: from [172.22.232.110] (ileax41-snat.itg.ti.com [10.172.224.153])	by
	dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id sA78GklH002236;
	Fri, 7 Nov 2014 02:16:47 -0600
Message-ID: <545C7FED.2000603@ti.com>
Date: Fri, 7 Nov 2014 10:16:45 +0200
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
	<1415019724-4317-4-git-send-email-jgross@suse.com>
In-Reply-To: <1415019724-4317-4-git-send-email-jgross@suse.com>
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	mingo@redhat.com, david.vrabel@citrix.com, jbeulich@suse.com,
	hpa@zytor.com, bhelgaas@google.com, tglx@linutronix.de,
	plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH V6 03/18] x86: Use new cache mode type in
	drivers/video/fbdev/gbefb.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7898846652664239496=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7898846652664239496==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="vsnfs2fmdA24VkTavR0IxXnQcai39ueTb"

--vsnfs2fmdA24VkTavR0IxXnQcai39ueTb
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 03/11/14 15:01, Juergen Gross wrote:
> Instead of directly using the cache mode bits in the pte switch to
> using the cache mode type.
>=20
> Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  drivers/video/fbdev/gbefb.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>=20
> diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
> index 4aa56ba..6d9ef39 100644
> --- a/drivers/video/fbdev/gbefb.c
> +++ b/drivers/video/fbdev/gbefb.c
> @@ -54,7 +54,8 @@ struct gbefb_par {
>  #endif
>  #endif
>  #ifdef CONFIG_X86
> -#define pgprot_fb(_prot) ((_prot) | _PAGE_PCD)
> +#define pgprot_fb(_prot) (((_prot) & ~_PAGE_CACHE_MASK) |	\
> +			  cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS))
>  #endif
> =20
>  /*
>=20

For this and vermilion fb:

Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

 Tomi



--vsnfs2fmdA24VkTavR0IxXnQcai39ueTb
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

iQIcBAEBAgAGBQJUXH/tAAoJEPo9qoy8lh71C00P/RaafIIgv9NRIVBW1APfzn6C
3dpdWIgoG0gJAAc6XfDYjKd/+WtNSEPK62WALB82FjP/W4z8xoAPEHXN8HKhhM11
PUGrnNRNqakaC7b0fmJRWWdvM4BYBD/r5es4PCHEVUeuUkJo0GEeBwaJBIUh62Qj
CBL2LAjDwSv0YCWaRQNKCPnkDVMOxGirZMY6tIIL+jsEQ6T+VTATodQwHxXN5jau
qT04+wHEEwN1/sQ9yLqDwW1lv1ja96hZgDpKDZnaJvdbRsDX5CZjKC3sRsx2M/iM
Rd6ZGOPPmCTtcGUo1pNTtgwooKLI7n4iQ+m+psma4lgfvjrU4MgUPM2bGsdb0Gb8
vo77EOIadWAPwiB6mLKiFd+52jZMEmA5lfsYQqE/+MuiZGkR5riM9M/pTfkI+8hB
4al4yYhC2bUe0wjzdMB4BNsJ1PcC/HAqq840tE1H4RTxll+uo423Xwy9EnwHRYtU
8Z9xuc0kWnm94CGUEc4BYxB4te8HbFHwOzbRHOS4RDdZZERY8yIjnvInrPSjJGaJ
DJN3/h0uVBMMpNdPREcnJcdLlxRvav1YEH60uckGDeIM1YS7e7P+GWLlk3isBWHP
vngArvlNt0XdAL39lDYJm2u5DXtIrqXxFRaxvf73OdMW68esgM+OscMzP5CNPeSU
q/wqrTHW0AL2adUHgvdr
=pT/u
-----END PGP SIGNATURE-----

--vsnfs2fmdA24VkTavR0IxXnQcai39ueTb--


--===============7898846652664239496==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7898846652664239496==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 08:17:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 08:17:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmejM-0004VN-D4; Fri, 07 Nov 2014 08:17:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tomi.valkeinen@ti.com>) id 1XmejL-0004VI-4V
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 08:17:15 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	88/2F-17694-9008C545; Fri, 07 Nov 2014 08:17:13 +0000
X-Env-Sender: tomi.valkeinen@ti.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415348231!11029634!1
X-Originating-IP: [192.94.94.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQwID0+IDE3MDg0MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24837 invoked from network); 7 Nov 2014 08:17:13 -0000
Received: from arroyo.ext.ti.com (HELO arroyo.ext.ti.com) (192.94.94.40)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 08:17:13 -0000
Received: from dflxv15.itg.ti.com ([128.247.5.124])
	by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id sA78GqLa031743;
	Fri, 7 Nov 2014 02:16:52 -0600
Received: from DLEE71.ent.ti.com (dlee71.ent.ti.com [157.170.170.114])
	by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id sA78GqSh026341;
	Fri, 7 Nov 2014 02:16:52 -0600
Received: from dflp33.itg.ti.com (10.64.6.16) by DLEE71.ent.ti.com
	(157.170.170.114) with Microsoft SMTP Server id 14.3.174.1;
	Fri, 7 Nov 2014 02:16:51 -0600
Received: from [172.22.232.110] (ileax41-snat.itg.ti.com [10.172.224.153])	by
	dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id sA78GklH002236;
	Fri, 7 Nov 2014 02:16:47 -0600
Message-ID: <545C7FED.2000603@ti.com>
Date: Fri, 7 Nov 2014 10:16:45 +0200
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
	<1415019724-4317-4-git-send-email-jgross@suse.com>
In-Reply-To: <1415019724-4317-4-git-send-email-jgross@suse.com>
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	mingo@redhat.com, david.vrabel@citrix.com, jbeulich@suse.com,
	hpa@zytor.com, bhelgaas@google.com, tglx@linutronix.de,
	plagnioj@jcrosoft.com, ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH V6 03/18] x86: Use new cache mode type in
	drivers/video/fbdev/gbefb.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7898846652664239496=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7898846652664239496==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="vsnfs2fmdA24VkTavR0IxXnQcai39ueTb"

--vsnfs2fmdA24VkTavR0IxXnQcai39ueTb
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 03/11/14 15:01, Juergen Gross wrote:
> Instead of directly using the cache mode bits in the pte switch to
> using the cache mode type.
>=20
> Based-on-patch-by: Stefan Bader <stefan.bader@canonical.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  drivers/video/fbdev/gbefb.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>=20
> diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
> index 4aa56ba..6d9ef39 100644
> --- a/drivers/video/fbdev/gbefb.c
> +++ b/drivers/video/fbdev/gbefb.c
> @@ -54,7 +54,8 @@ struct gbefb_par {
>  #endif
>  #endif
>  #ifdef CONFIG_X86
> -#define pgprot_fb(_prot) ((_prot) | _PAGE_PCD)
> +#define pgprot_fb(_prot) (((_prot) & ~_PAGE_CACHE_MASK) |	\
> +			  cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS))
>  #endif
> =20
>  /*
>=20

For this and vermilion fb:

Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

 Tomi



--vsnfs2fmdA24VkTavR0IxXnQcai39ueTb
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

iQIcBAEBAgAGBQJUXH/tAAoJEPo9qoy8lh71C00P/RaafIIgv9NRIVBW1APfzn6C
3dpdWIgoG0gJAAc6XfDYjKd/+WtNSEPK62WALB82FjP/W4z8xoAPEHXN8HKhhM11
PUGrnNRNqakaC7b0fmJRWWdvM4BYBD/r5es4PCHEVUeuUkJo0GEeBwaJBIUh62Qj
CBL2LAjDwSv0YCWaRQNKCPnkDVMOxGirZMY6tIIL+jsEQ6T+VTATodQwHxXN5jau
qT04+wHEEwN1/sQ9yLqDwW1lv1ja96hZgDpKDZnaJvdbRsDX5CZjKC3sRsx2M/iM
Rd6ZGOPPmCTtcGUo1pNTtgwooKLI7n4iQ+m+psma4lgfvjrU4MgUPM2bGsdb0Gb8
vo77EOIadWAPwiB6mLKiFd+52jZMEmA5lfsYQqE/+MuiZGkR5riM9M/pTfkI+8hB
4al4yYhC2bUe0wjzdMB4BNsJ1PcC/HAqq840tE1H4RTxll+uo423Xwy9EnwHRYtU
8Z9xuc0kWnm94CGUEc4BYxB4te8HbFHwOzbRHOS4RDdZZERY8yIjnvInrPSjJGaJ
DJN3/h0uVBMMpNdPREcnJcdLlxRvav1YEH60uckGDeIM1YS7e7P+GWLlk3isBWHP
vngArvlNt0XdAL39lDYJm2u5DXtIrqXxFRaxvf73OdMW68esgM+OscMzP5CNPeSU
q/wqrTHW0AL2adUHgvdr
=pT/u
-----END PGP SIGNATURE-----

--vsnfs2fmdA24VkTavR0IxXnQcai39ueTb--


--===============7898846652664239496==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7898846652664239496==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 08:24:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 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.xen.org>)
	id 1Xmeq2-0004fi-8S; Fri, 07 Nov 2014 08:24:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <seth.forshee@canonical.com>) id 1XmUw7-00018z-Gz
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 21:49:47 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	2C/35-27785-AFCEB545; Thu, 06 Nov 2014 21:49:46 +0000
X-Env-Sender: seth.forshee@canonical.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415310584!11930951!1
X-Originating-IP: [209.85.214.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32001 invoked from network); 6 Nov 2014 21:49:45 -0000
Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com)
	(209.85.214.174)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 21:49:45 -0000
Received: by mail-ob0-f174.google.com with SMTP id uz6so1606839obc.5
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 13:49:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id
	:mail-followup-to:mime-version:content-type:content-disposition
	:user-agent;
	bh=VW6VJKQAsMGLocCRVtYbwNdpIMS67vel4HB7z85fLUo=;
	b=YeOj3Mfcvz7koI43y9cT6Rcb8w1nbUrfGHuqnD23UpmrAnVyV/PdkuNoabjHOedWbV
	wglvCJIqX8PFbzb8N8wI6ZjYfzYNDU+g5/8HK9+eUsOnOJP85YuIWQidWoUDay/tYnuY
	q3oQVR4OVVX1P6lpRJ6OJ75VAI9UQZARRpMRHGUuuXaQL2dg/dY0sP9q3Sg41ZB4mSbM
	Y1DNbgssfTwn3De3jFQ3ZITjRKc4KhEEb8nsIJ0KwTkYPl00GynJ2OUhgaYXum5BX+HV
	4/5MevLw3Qos8YCXDw7B6rCTV6SqndUscpGAG8W5BXV4INpfx3BZSEs1Sd5yym+Nxu5d
	z6JA==
X-Gm-Message-State: ALoCoQlAwu+h3KctVZzb4+SipYxSX9+phIXKJ397JQEaEkFpTkc9lAftmo7yVpS0eQ5vB7lvQizx
X-Received: by 10.182.89.161 with SMTP id bp1mr5983026obb.19.1415310584401;
	Thu, 06 Nov 2014 13:49:44 -0800 (PST)
Received: from localhost (199-87-125-144.dyn.kc.surewest.net. [199.87.125.144])
	by mx.google.com with ESMTPSA id
	w139sm3089900oie.10.2014.11.06.13.49.43 for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Thu, 06 Nov 2014 13:49:44 -0800 (PST)
Date: Thu, 6 Nov 2014 15:49:40 -0600
From: Seth Forshee <seth.forshee@canonical.com>
To: netdev@vger.kernel.org
Message-ID: <20141106214940.GD44162@ubuntu-hedt>
Mail-Followup-To: netdev@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Fri, 07 Nov 2014 08:24:08 +0000
Cc: linux-kernel@vger.kernel.org, Stefan Bader <stefan.bader@canonical.com>,
	seth.forshee@canonical.com, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We've had several reports of hitting the following BUG_ON in
xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
results of testing with 3.17):

        /* Grant backend access to each skb fragment page. */
        for (i = 0; i < frags; i++) {
                skb_frag_t *frag = skb_shinfo(skb)->frags + i;
                struct page *page = skb_frag_page(frag);

                len = skb_frag_size(frag);
                offset = frag->page_offset;

                /* Data must not cross a page boundary. */
                BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));

When this happens the page in question is a "middle" page in a compound
page (i.e. it's a tail page but not the last tail page), and the data is
fully contained within the compound page. The data does however cross
the hardware page boundary, and since compound_order evaluates to 0 for
tail pages the check fails.

In going over this I've been unable to determine whether the BUG_ON in
xennet_make_frags is incorrect or the paged skb data is wrong. I can't
find that it's documented anywhere, and the networking code itself is a
bit ambiguous when it comes to compound pages. On the one hand
__skb_fill_page_desc specifically handles adding tail pages as paged
data, but on the other hand skb_copy_bits kmaps frag->page.p which could
fail with data that extends into another page.

Can anyone explain what the rules are here? My best guess based on
skb_copy_bits is that paged data should never cross the hardware page
boundary, but I'm not really sure how all of this works out when dealing
with compound pages.

Thanks,
Seth

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 08:24:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 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.xen.org>)
	id 1Xmeq2-0004fi-8S; Fri, 07 Nov 2014 08:24:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <seth.forshee@canonical.com>) id 1XmUw7-00018z-Gz
	for xen-devel@lists.xenproject.org; Thu, 06 Nov 2014 21:49:47 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	2C/35-27785-AFCEB545; Thu, 06 Nov 2014 21:49:46 +0000
X-Env-Sender: seth.forshee@canonical.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415310584!11930951!1
X-Originating-IP: [209.85.214.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32001 invoked from network); 6 Nov 2014 21:49:45 -0000
Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com)
	(209.85.214.174)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Nov 2014 21:49:45 -0000
Received: by mail-ob0-f174.google.com with SMTP id uz6so1606839obc.5
	for <xen-devel@lists.xenproject.org>;
	Thu, 06 Nov 2014 13:49:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id
	:mail-followup-to:mime-version:content-type:content-disposition
	:user-agent;
	bh=VW6VJKQAsMGLocCRVtYbwNdpIMS67vel4HB7z85fLUo=;
	b=YeOj3Mfcvz7koI43y9cT6Rcb8w1nbUrfGHuqnD23UpmrAnVyV/PdkuNoabjHOedWbV
	wglvCJIqX8PFbzb8N8wI6ZjYfzYNDU+g5/8HK9+eUsOnOJP85YuIWQidWoUDay/tYnuY
	q3oQVR4OVVX1P6lpRJ6OJ75VAI9UQZARRpMRHGUuuXaQL2dg/dY0sP9q3Sg41ZB4mSbM
	Y1DNbgssfTwn3De3jFQ3ZITjRKc4KhEEb8nsIJ0KwTkYPl00GynJ2OUhgaYXum5BX+HV
	4/5MevLw3Qos8YCXDw7B6rCTV6SqndUscpGAG8W5BXV4INpfx3BZSEs1Sd5yym+Nxu5d
	z6JA==
X-Gm-Message-State: ALoCoQlAwu+h3KctVZzb4+SipYxSX9+phIXKJ397JQEaEkFpTkc9lAftmo7yVpS0eQ5vB7lvQizx
X-Received: by 10.182.89.161 with SMTP id bp1mr5983026obb.19.1415310584401;
	Thu, 06 Nov 2014 13:49:44 -0800 (PST)
Received: from localhost (199-87-125-144.dyn.kc.surewest.net. [199.87.125.144])
	by mx.google.com with ESMTPSA id
	w139sm3089900oie.10.2014.11.06.13.49.43 for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Thu, 06 Nov 2014 13:49:44 -0800 (PST)
Date: Thu, 6 Nov 2014 15:49:40 -0600
From: Seth Forshee <seth.forshee@canonical.com>
To: netdev@vger.kernel.org
Message-ID: <20141106214940.GD44162@ubuntu-hedt>
Mail-Followup-To: netdev@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Fri, 07 Nov 2014 08:24:08 +0000
Cc: linux-kernel@vger.kernel.org, Stefan Bader <stefan.bader@canonical.com>,
	seth.forshee@canonical.com, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We've had several reports of hitting the following BUG_ON in
xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
results of testing with 3.17):

        /* Grant backend access to each skb fragment page. */
        for (i = 0; i < frags; i++) {
                skb_frag_t *frag = skb_shinfo(skb)->frags + i;
                struct page *page = skb_frag_page(frag);

                len = skb_frag_size(frag);
                offset = frag->page_offset;

                /* Data must not cross a page boundary. */
                BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));

When this happens the page in question is a "middle" page in a compound
page (i.e. it's a tail page but not the last tail page), and the data is
fully contained within the compound page. The data does however cross
the hardware page boundary, and since compound_order evaluates to 0 for
tail pages the check fails.

In going over this I've been unable to determine whether the BUG_ON in
xennet_make_frags is incorrect or the paged skb data is wrong. I can't
find that it's documented anywhere, and the networking code itself is a
bit ambiguous when it comes to compound pages. On the one hand
__skb_fill_page_desc specifically handles adding tail pages as paged
data, but on the other hand skb_copy_bits kmaps frag->page.p which could
fail with data that extends into another page.

Can anyone explain what the rules are here? My best guess based on
skb_copy_bits is that paged data should never cross the hardware page
boundary, but I'm not really sure how all of this works out when dealing
with compound pages.

Thanks,
Seth

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 08:52:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 08:52:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmfHF-0004vg-M6; Fri, 07 Nov 2014 08:52:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgorman@suse.de>) id 1XmfHE-0004vb-G6
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 08:52:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	72/8D-24532-F388C545; Fri, 07 Nov 2014 08:52:15 +0000
X-Env-Sender: mgorman@suse.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415350335!4837782!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15141 invoked from network); 7 Nov 2014 08:52:15 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 08:52:15 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 003D6AD56;
	Fri,  7 Nov 2014 08:52:13 +0000 (UTC)
Date: Fri, 7 Nov 2014 08:52:10 +0000
From: Mel Gorman <mgorman@suse.de>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141107085210.GW21422@suse.de>
References: <1415296096-22873-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415296096-22873-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Hugh Dickins <hughd@google.com>, linux-mm@kvack.org,
	David Vrabel <david.vrabel@citrix.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>, xen-devel@lists.xenproject.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH RFC] x86,
	mm: use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 05:48:16PM +0000, Wei Liu wrote:
> In b38af4721 ("x86,mm: fix pte_special versus pte_numa") pte_special()
> (SPECIAL with PRESENT or PROTNONE) was made to complement pte_numa()
> (SPECIAL with neither PRESENT nor PROTNONE). That broke Xen PV guest
> with NUMA balancing support.
> 
> That's because Xen hypervisor sets _PAGE_GLOBAL (_PAGE_GLOBAL /
> _PAGE_PROTNONE in Linux) for guest user space mapping. So in a Xen PV
> guest, when NUMA balancing is enabled, a NUMA hinted PTE ends up
> "SPECIAL (in fact NUMA) with PROTNONE but not PRESENT", which makes
> pte_special() returns true when it shouldn't.
> 
> Fundamentally we only need _PAGE_NUMA and _PAGE_PRESENT to tell
> difference between an unmapped entry and an entry protected for NUMA
> hinting fault. So use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA, adjust
> _PAGE_NUMA_MASK and SWP_OFFSET_SHIFT as needed.
> 
> Suggested-by: David Vrabel <david.vrabel@citrix.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

I suggest instead that you force automatic NUMA balancing to be disabled
on Xen PV guests until I or someone else finds time to implement Linus'
idea to remove _PAGE_NUMA entirely. It's been on my TODO list for a few
weeks but I still have not reached the point where I'm back working on
upstream material properly.
 
-- 
Mel Gorman
SUSE Labs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 08:52:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 08:52:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmfHF-0004vg-M6; Fri, 07 Nov 2014 08:52:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgorman@suse.de>) id 1XmfHE-0004vb-G6
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 08:52:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	72/8D-24532-F388C545; Fri, 07 Nov 2014 08:52:15 +0000
X-Env-Sender: mgorman@suse.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415350335!4837782!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15141 invoked from network); 7 Nov 2014 08:52:15 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 08:52:15 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 003D6AD56;
	Fri,  7 Nov 2014 08:52:13 +0000 (UTC)
Date: Fri, 7 Nov 2014 08:52:10 +0000
From: Mel Gorman <mgorman@suse.de>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141107085210.GW21422@suse.de>
References: <1415296096-22873-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415296096-22873-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Hugh Dickins <hughd@google.com>, linux-mm@kvack.org,
	David Vrabel <david.vrabel@citrix.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>, xen-devel@lists.xenproject.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH RFC] x86,
	mm: use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 05:48:16PM +0000, Wei Liu wrote:
> In b38af4721 ("x86,mm: fix pte_special versus pte_numa") pte_special()
> (SPECIAL with PRESENT or PROTNONE) was made to complement pte_numa()
> (SPECIAL with neither PRESENT nor PROTNONE). That broke Xen PV guest
> with NUMA balancing support.
> 
> That's because Xen hypervisor sets _PAGE_GLOBAL (_PAGE_GLOBAL /
> _PAGE_PROTNONE in Linux) for guest user space mapping. So in a Xen PV
> guest, when NUMA balancing is enabled, a NUMA hinted PTE ends up
> "SPECIAL (in fact NUMA) with PROTNONE but not PRESENT", which makes
> pte_special() returns true when it shouldn't.
> 
> Fundamentally we only need _PAGE_NUMA and _PAGE_PRESENT to tell
> difference between an unmapped entry and an entry protected for NUMA
> hinting fault. So use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA, adjust
> _PAGE_NUMA_MASK and SWP_OFFSET_SHIFT as needed.
> 
> Suggested-by: David Vrabel <david.vrabel@citrix.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

I suggest instead that you force automatic NUMA balancing to be disabled
on Xen PV guests until I or someone else finds time to implement Linus'
idea to remove _PAGE_NUMA entirely. It's been on my TODO list for a few
weeks but I still have not reached the point where I'm back working on
upstream material properly.
 
-- 
Mel Gorman
SUSE Labs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 09:26:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 09:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmfnd-0005Ty-Ff; Fri, 07 Nov 2014 09:25:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1Xmfnb-0005Tr-OG
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 09:25:43 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	69/E8-18267-7109C545; Fri, 07 Nov 2014 09:25:43 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415352342!11067292!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15268 invoked from network); 7 Nov 2014 09:25:42 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 09:25:42 -0000
Received: by mail-wi0-f178.google.com with SMTP id bs8so3925715wib.5
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 01:25:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=+O9SW/L6U/m7cdEeb8oKOn3i41Wr34ZlRRBYaPCQpBs=;
	b=eCyEWHNOxCvTNvLyj2Dt+6fdtuHoevC3HqbI83m0aps+aQso4sN7DjUo1PTyoPsF9t
	8pDOVuMaTwIkmitMlKnjNxMhdj5rVxyxr+BDqFn4eC4DIxIX4GtH1ovZFVJi3ZrfuSR+
	PQtqk0SvTHxfJdh+GXyTmgOlt8Dke09xSDY0GSgylEmwqfO6byGEdIj0Q3Yo1Flh1s8X
	WUxvIbdKgHugYjljPN22DmaMpnYeIrJmPiWQVxaKW5Rtjba6hNtu9BZQwVWO4VadL3UN
	6vuNMWrRnwT9u8C5AZWCDdzP5S5VBJJJzQX3aFAFm9J/4cc4f5+WF5wuTc33kViBjdWM
	idSg==
X-Gm-Message-State: ALoCoQnyd/1nVXIlFxxiGUluDBZX7k6xYOzR9AZqtM1w6oXmPchoXTwi/2PvUxDuix+Y+Gaqgk0W
X-Received: by 10.180.20.8 with SMTP id j8mr3218349wie.60.1415352341478;
	Fri, 07 Nov 2014 01:25:41 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id ce1sm11051094wjc.2.2014.11.07.01.25.40
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 01:25:40 -0800 (PST)
Message-ID: <545C9013.1090406@linaro.org>
Date: Fri, 07 Nov 2014 09:25:39 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	David Vrabel <david.vrabel@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>, 
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20141106214940.GD44162@ubuntu-hedt>
In-Reply-To: <20141106214940.GD44162@ubuntu-hedt>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

AFAIK in this scenario your skb frag is wrong. The page pointer should 
point to the original compound page (not a member of it), and offset 
should be set accordingly.
For example, if your compound page is 16K (4 page), then the page 
pointer should point to the first page, and if the data starts at the 
3rd page, then offset should be >8K

Zoli

On 06/11/14 21:49, Seth Forshee wrote:
> We've had several reports of hitting the following BUG_ON in
> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
> results of testing with 3.17):
>
>          /* Grant backend access to each skb fragment page. */
>          for (i = 0; i < frags; i++) {
>                  skb_frag_t *frag = skb_shinfo(skb)->frags + i;
>                  struct page *page = skb_frag_page(frag);
>
>                  len = skb_frag_size(frag);
>                  offset = frag->page_offset;
>
>                  /* Data must not cross a page boundary. */
>                  BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
>
> When this happens the page in question is a "middle" page in a compound
> page (i.e. it's a tail page but not the last tail page), and the data is
> fully contained within the compound page. The data does however cross
> the hardware page boundary, and since compound_order evaluates to 0 for
> tail pages the check fails.
>
> In going over this I've been unable to determine whether the BUG_ON in
> xennet_make_frags is incorrect or the paged skb data is wrong. I can't
> find that it's documented anywhere, and the networking code itself is a
> bit ambiguous when it comes to compound pages. On the one hand
> __skb_fill_page_desc specifically handles adding tail pages as paged
> data, but on the other hand skb_copy_bits kmaps frag->page.p which could
> fail with data that extends into another page.
>
> Can anyone explain what the rules are here? My best guess based on
> skb_copy_bits is that paged data should never cross the hardware page
> boundary, but I'm not really sure how all of this works out when dealing
> with compound pages.
>
> Thanks,
> Seth
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 07 09:26:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 09:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmfnd-0005Ty-Ff; Fri, 07 Nov 2014 09:25:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1Xmfnb-0005Tr-OG
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 09:25:43 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	69/E8-18267-7109C545; Fri, 07 Nov 2014 09:25:43 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415352342!11067292!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15268 invoked from network); 7 Nov 2014 09:25:42 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 09:25:42 -0000
Received: by mail-wi0-f178.google.com with SMTP id bs8so3925715wib.5
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 01:25:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=+O9SW/L6U/m7cdEeb8oKOn3i41Wr34ZlRRBYaPCQpBs=;
	b=eCyEWHNOxCvTNvLyj2Dt+6fdtuHoevC3HqbI83m0aps+aQso4sN7DjUo1PTyoPsF9t
	8pDOVuMaTwIkmitMlKnjNxMhdj5rVxyxr+BDqFn4eC4DIxIX4GtH1ovZFVJi3ZrfuSR+
	PQtqk0SvTHxfJdh+GXyTmgOlt8Dke09xSDY0GSgylEmwqfO6byGEdIj0Q3Yo1Flh1s8X
	WUxvIbdKgHugYjljPN22DmaMpnYeIrJmPiWQVxaKW5Rtjba6hNtu9BZQwVWO4VadL3UN
	6vuNMWrRnwT9u8C5AZWCDdzP5S5VBJJJzQX3aFAFm9J/4cc4f5+WF5wuTc33kViBjdWM
	idSg==
X-Gm-Message-State: ALoCoQnyd/1nVXIlFxxiGUluDBZX7k6xYOzR9AZqtM1w6oXmPchoXTwi/2PvUxDuix+Y+Gaqgk0W
X-Received: by 10.180.20.8 with SMTP id j8mr3218349wie.60.1415352341478;
	Fri, 07 Nov 2014 01:25:41 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id ce1sm11051094wjc.2.2014.11.07.01.25.40
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 01:25:40 -0800 (PST)
Message-ID: <545C9013.1090406@linaro.org>
Date: Fri, 07 Nov 2014 09:25:39 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	David Vrabel <david.vrabel@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>, 
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20141106214940.GD44162@ubuntu-hedt>
In-Reply-To: <20141106214940.GD44162@ubuntu-hedt>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

AFAIK in this scenario your skb frag is wrong. The page pointer should 
point to the original compound page (not a member of it), and offset 
should be set accordingly.
For example, if your compound page is 16K (4 page), then the page 
pointer should point to the first page, and if the data starts at the 
3rd page, then offset should be >8K

Zoli

On 06/11/14 21:49, Seth Forshee wrote:
> We've had several reports of hitting the following BUG_ON in
> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
> results of testing with 3.17):
>
>          /* Grant backend access to each skb fragment page. */
>          for (i = 0; i < frags; i++) {
>                  skb_frag_t *frag = skb_shinfo(skb)->frags + i;
>                  struct page *page = skb_frag_page(frag);
>
>                  len = skb_frag_size(frag);
>                  offset = frag->page_offset;
>
>                  /* Data must not cross a page boundary. */
>                  BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
>
> When this happens the page in question is a "middle" page in a compound
> page (i.e. it's a tail page but not the last tail page), and the data is
> fully contained within the compound page. The data does however cross
> the hardware page boundary, and since compound_order evaluates to 0 for
> tail pages the check fails.
>
> In going over this I've been unable to determine whether the BUG_ON in
> xennet_make_frags is incorrect or the paged skb data is wrong. I can't
> find that it's documented anywhere, and the networking code itself is a
> bit ambiguous when it comes to compound pages. On the one hand
> __skb_fill_page_desc specifically handles adding tail pages as paged
> data, but on the other hand skb_copy_bits kmaps frag->page.p which could
> fail with data that extends into another page.
>
> Can anyone explain what the rules are here? My best guess based on
> skb_copy_bits is that paged data should never cross the hardware page
> boundary, but I'm not really sure how all of this works out when dealing
> with compound pages.
>
> Thanks,
> Seth
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 07 09:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 09:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmg2I-0005hg-To; Fri, 07 Nov 2014 09:40: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 1Xmg2H-0005hb-JC
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 09:40:53 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A5/97-03148-5A39C545; Fri, 07 Nov 2014 09:40:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415353251!11911376!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24959 invoked from network); 7 Nov 2014 09:40:52 -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;
	7 Nov 2014 09:40:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="189074373"
Received: from localhost (10.80.16.47) by smtprelay.citrix.com (10.13.107.80)
	with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 04:40:49 -0500
Message-ID: <1415353248.2030.5.camel@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 7 Nov 2014 09:40:48 +0000
In-Reply-To: <21595.24771.302806.319751@mariner.uk.xensource.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
	<21595.24771.302806.319751@mariner.uk.xensource.com>
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 11:51 +0000, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> > so this continues to be a result of swiotlb issues on the source host.
> > Iirc you had indicated you took care of this - did that perhaps only
> > affect -unstable?
> 
> My change to the host property in the osstest hostdb didn't have the
> intended effect (or, any relevant effect).  I'm fixing this but it
> will involve a change to osstest.

FYI judging from
http://www.chiark.greenend.org.uk/~xensrcts/logs/31393/test-amd64-i386-pair/info.html
scape-moth (and presumably worm-moth) suffer from this issue too:

http://www.chiark.greenend.org.uk/~xensrcts/logs/31393/test-amd64-i386-pair/serial-scape-moth.log

Nov  6 04:20:06.066637 [ 1117.222426] sd 4:1:0:0: pci_map_sg failed: request for 8192 bytes!
Nov  6 04:20:06.066686 [ 1117.240332] mpt2sas 0000:05:00.0: swiotlb buffer is full
Nov  6 04:20:06.086629 [ 1117.240345] sd 4:1:0:0: pci_map_sg failed: request for 8192 bytes!
Nov  6 04:20:06.086680 [ 1117.258331] mpt2sas 0000:05:00.0: swiotlb buffer is full

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 09:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 09:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmg2I-0005hg-To; Fri, 07 Nov 2014 09:40: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 1Xmg2H-0005hb-JC
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 09:40:53 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A5/97-03148-5A39C545; Fri, 07 Nov 2014 09:40:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415353251!11911376!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24959 invoked from network); 7 Nov 2014 09:40:52 -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;
	7 Nov 2014 09:40:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="189074373"
Received: from localhost (10.80.16.47) by smtprelay.citrix.com (10.13.107.80)
	with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 04:40:49 -0500
Message-ID: <1415353248.2030.5.camel@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 7 Nov 2014 09:40:48 +0000
In-Reply-To: <21595.24771.302806.319751@mariner.uk.xensource.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
	<21595.24771.302806.319751@mariner.uk.xensource.com>
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 11:51 +0000, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> > so this continues to be a result of swiotlb issues on the source host.
> > Iirc you had indicated you took care of this - did that perhaps only
> > affect -unstable?
> 
> My change to the host property in the osstest hostdb didn't have the
> intended effect (or, any relevant effect).  I'm fixing this but it
> will involve a change to osstest.

FYI judging from
http://www.chiark.greenend.org.uk/~xensrcts/logs/31393/test-amd64-i386-pair/info.html
scape-moth (and presumably worm-moth) suffer from this issue too:

http://www.chiark.greenend.org.uk/~xensrcts/logs/31393/test-amd64-i386-pair/serial-scape-moth.log

Nov  6 04:20:06.066637 [ 1117.222426] sd 4:1:0:0: pci_map_sg failed: request for 8192 bytes!
Nov  6 04:20:06.066686 [ 1117.240332] mpt2sas 0000:05:00.0: swiotlb buffer is full
Nov  6 04:20:06.086629 [ 1117.240345] sd 4:1:0:0: pci_map_sg failed: request for 8192 bytes!
Nov  6 04:20:06.086680 [ 1117.258331] mpt2sas 0000:05:00.0: swiotlb buffer is full

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 09:57:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 09:57:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmgHi-0005vg-E6; Fri, 07 Nov 2014 09:56:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmgHg-0005vb-Ou
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 09:56:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C7/B0-24532-0679C545; Fri, 07 Nov 2014 09:56:48 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415354207!4858019!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27582 invoked from network); 7 Nov 2014 09:56:47 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 09:56:47 -0000
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BOM85091; Fri, 07 Nov 2014 09:56:41 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id
	14.03.0158.001; Fri, 7 Nov 2014 09:56:36 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Frediano Ziglio
	<freddy77@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] xen/arm: Return correct code error for
	xen_swiotlb_map_page
Thread-Index: AQHP+eQybFi0WqSOD0+2fx6E4sVCLJxT2xKAgAAaXQCAAAKpgIAA9P6w
Date: Fri, 7 Nov 2014 09:56:36 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17DF04@lhreml509-mbb>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
	<alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
	<CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
	<alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.66.6]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Boris
	Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
 xen_swiotlb_map_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiBPbiBUaHUsIDYgTm92IDIwMTQsIEZyZWRpYW5vIFppZ2xpbyB3cm90ZToNCj4gPiAyMDE0LTEx
LTA2IDE3OjMwIEdNVCswMDowMCBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHN0ZWZhbm8uc3RhYmVs
bGluaUBldS5jaXRyaXguY29tPjoNCj4gPiAgICAgICBPbiBUaHUsIDYgTm92IDIwMTQsIEZyZWRp
YW5vIFppZ2xpbyB3cm90ZToNCj4gPiAgICAgICA+IE9uIEFSTSBlcnJvciBjb2RlIGlzIG5vdCAw
IHNvIGF2b2lkIHRvIHJldHVybiBpdCBhcyBlcnJvci4NCj4gPiAgICAgICA+DQo+ID4gICAgICAg
PiBTaWduZWQtb2ZmLWJ5OiBGcmVkaWFubyBaaWdsaW8gPGZyZWRpYW5vLnppZ2xpb0BodWF3ZWku
Y29tPg0KPiA+DQo+ID4gICAgICAgQWNrZWQtYnk6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFu
by5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+DQo+ID4NCj4gPg0KPiA+ICAgICAgIENvdWxkIHlv
dSBwbGVhc2UgZml4IHRoZSBzYW1lIGVycm9yIGluIGxpYi9zd2lvdGxiLmMgdG9vIHBsZWFzZT8N
Cj4gPg0KPiA+DQo+ID4gU2FtZSBwYXRjaCBvciBhbm90aGVyID8NCj4gPg0KPiANCj4gQW5vdGhl
cg0KPiANCg0KbGliL3N3aW90bGIuYyBpcyBub3QgYWZmZWN0ZWQgYXQgYSBwaHlzaWNhbCBhZGRy
ZXNzIHRvIGlvX3RsYl9vdmVyZmxvd19idWZmZXIgaXMgcmV0dXJuZWQgaW4gY2FzZSBvZiBlcnJv
ci4NCkxvb2tzIGxpa2UgYSB3YXkgdG8gdHJhbnNmb3JtIHNpbGVudGx5IGFuIGFsbG9jYXRpb24g
ZXJyb3IgdG8gYSBtb3JlIHNlcmlvdXMgbWVtb3J5IGNvcnJ1cHRpb24uDQoNCkZyZWRpYW5vDQoN
Cj4gPg0KPiA+ICAgICAgID7CoCBkcml2ZXJzL3hlbi9zd2lvdGxiLXhlbi5jIHwgMiArLQ0KPiA+
ICAgICAgID7CoCAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDEgZGVsZXRpb24oLSkN
Cj4gPiAgICAgICA+DQo+ID4gICAgICAgPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vc3dpb3Rs
Yi14ZW4uYyBiL2RyaXZlcnMveGVuL3N3aW90bGItDQo+IHhlbi5jDQo+ID4gICAgICAgPiBpbmRl
eCBlYmQ4ZjIxLi4zYjhkNjI4IDEwMDY0NA0KPiA+ICAgICAgID4gLS0tIGEvZHJpdmVycy94ZW4v
c3dpb3RsYi14ZW4uYw0KPiA+ICAgICAgID4gKysrIGIvZHJpdmVycy94ZW4vc3dpb3RsYi14ZW4u
Yw0KPiA+ICAgICAgID4gQEAgLTQyNSw3ICs0MjUsNyBAQCBkbWFfYWRkcl90IHhlbl9zd2lvdGxi
X21hcF9wYWdlKHN0cnVjdA0KPiBkZXZpY2UgKmRldiwgc3RydWN0IHBhZ2UgKnBhZ2UsDQo+ID4g
ICAgICAgPsKgIMKgIMKgIMKgICovDQo+ID4gICAgICAgPsKgIMKgIMKgIMKgaWYgKCFkbWFfY2Fw
YWJsZShkZXYsIGRldl9hZGRyLCBzaXplKSkgew0KPiA+ICAgICAgID7CoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoHN3aW90bGJfdGJsX3VubWFwX3NpbmdsZShkZXYsIG1hcCwgc2l6ZSwgZGlyKTsNCj4g
PiAgICAgICA+IC3CoCDCoCDCoCDCoCDCoCDCoCDCoGRldl9hZGRyID0gMDsNCj4gPiAgICAgICA+
ICvCoCDCoCDCoCDCoCDCoCDCoCDCoGRldl9hZGRyID0gRE1BX0VSUk9SX0NPREU7DQo+ID4gICAg
ICAgPsKgIMKgIMKgIMKgfQ0KPiA+ICAgICAgID7CoCDCoCDCoCDCoHJldHVybiBkZXZfYWRkcjsN
Cj4gPiAgICAgICA+wqAgfQ0KPiA+ICAgICAgID4gLS0NCj4gPiAgICAgICA+IDEuOS4xDQo+ID4g
ICAgICAgPg0KPiA+ICAgICAgID4NCj4gPiAgICAgICA+IC0tDQo+ID4gICAgICAgPiBUbyB1bnN1
YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUNCj4gbGlu
dXgta2VybmVsIiBpbg0KPiA+ICAgICAgID4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9y
ZG9tb0B2Z2VyLmtlcm5lbC5vcmcNCj4gPiAgICAgICA+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXTC
oCBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby0NCj4gaW5mby5odG1sDQo+ID4gICAg
ICAgPiBQbGVhc2UgcmVhZCB0aGUgRkFRIGF0wqBodHRwOi8vc2VjdXJlLQ0KPiB3ZWIuY2lzY28u
Y29tLzFjdmpST3lVeFY2U25BMHVCVE1SdWJxclFXc2FYR2hwcy0NCj4gRldqWTN2bHk5QXhhS0ts
dDJEUFk3R2pMMEZDSGVQNHJzYmpLc2MtUDR6SDJfNy1rcGN4d0VILXVkR3JHQ0NxDQo+ID4gICAg
ICAga0NMbEgxLWZMT28xWDZObHVpNkV3RVZIVXBCMnI3Z3QtDQo+IEdzZ3hiZXA5UVdQbklkeXBE
UE5mOEhmNWNseENNWFljdldzT0s1czNxZy9odHRwJTNBJTJGJTJGd3d3LnR1eC5vcmclMkZsDQo+
IGttbCUyRg0KPiA+ICAgICAgID4NCj4gPg0KPiA+ICAgICAgIF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gICAgICAgWGVuLWRldmVsIG1haWxpbmcg
bGlzdA0KPiA+ICAgICAgIFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnDQo+ID4gICAgICAgaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsDQo+ID4NCj4gPg0KPiA+DQo+ID4NCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Fri Nov 07 09:57:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 09:57:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmgHi-0005vg-E6; Fri, 07 Nov 2014 09:56:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmgHg-0005vb-Ou
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 09:56:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C7/B0-24532-0679C545; Fri, 07 Nov 2014 09:56:48 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415354207!4858019!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27582 invoked from network); 7 Nov 2014 09:56:47 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 09:56:47 -0000
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BOM85091; Fri, 07 Nov 2014 09:56:41 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id
	14.03.0158.001; Fri, 7 Nov 2014 09:56:36 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Frediano Ziglio
	<freddy77@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] xen/arm: Return correct code error for
	xen_swiotlb_map_page
Thread-Index: AQHP+eQybFi0WqSOD0+2fx6E4sVCLJxT2xKAgAAaXQCAAAKpgIAA9P6w
Date: Fri, 7 Nov 2014 09:56:36 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17DF04@lhreml509-mbb>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
	<alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
	<CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
	<alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.66.6]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Boris
	Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
 xen_swiotlb_map_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiBPbiBUaHUsIDYgTm92IDIwMTQsIEZyZWRpYW5vIFppZ2xpbyB3cm90ZToNCj4gPiAyMDE0LTEx
LTA2IDE3OjMwIEdNVCswMDowMCBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHN0ZWZhbm8uc3RhYmVs
bGluaUBldS5jaXRyaXguY29tPjoNCj4gPiAgICAgICBPbiBUaHUsIDYgTm92IDIwMTQsIEZyZWRp
YW5vIFppZ2xpbyB3cm90ZToNCj4gPiAgICAgICA+IE9uIEFSTSBlcnJvciBjb2RlIGlzIG5vdCAw
IHNvIGF2b2lkIHRvIHJldHVybiBpdCBhcyBlcnJvci4NCj4gPiAgICAgICA+DQo+ID4gICAgICAg
PiBTaWduZWQtb2ZmLWJ5OiBGcmVkaWFubyBaaWdsaW8gPGZyZWRpYW5vLnppZ2xpb0BodWF3ZWku
Y29tPg0KPiA+DQo+ID4gICAgICAgQWNrZWQtYnk6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFu
by5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+DQo+ID4NCj4gPg0KPiA+ICAgICAgIENvdWxkIHlv
dSBwbGVhc2UgZml4IHRoZSBzYW1lIGVycm9yIGluIGxpYi9zd2lvdGxiLmMgdG9vIHBsZWFzZT8N
Cj4gPg0KPiA+DQo+ID4gU2FtZSBwYXRjaCBvciBhbm90aGVyID8NCj4gPg0KPiANCj4gQW5vdGhl
cg0KPiANCg0KbGliL3N3aW90bGIuYyBpcyBub3QgYWZmZWN0ZWQgYXQgYSBwaHlzaWNhbCBhZGRy
ZXNzIHRvIGlvX3RsYl9vdmVyZmxvd19idWZmZXIgaXMgcmV0dXJuZWQgaW4gY2FzZSBvZiBlcnJv
ci4NCkxvb2tzIGxpa2UgYSB3YXkgdG8gdHJhbnNmb3JtIHNpbGVudGx5IGFuIGFsbG9jYXRpb24g
ZXJyb3IgdG8gYSBtb3JlIHNlcmlvdXMgbWVtb3J5IGNvcnJ1cHRpb24uDQoNCkZyZWRpYW5vDQoN
Cj4gPg0KPiA+ICAgICAgID7CoCBkcml2ZXJzL3hlbi9zd2lvdGxiLXhlbi5jIHwgMiArLQ0KPiA+
ICAgICAgID7CoCAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDEgZGVsZXRpb24oLSkN
Cj4gPiAgICAgICA+DQo+ID4gICAgICAgPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vc3dpb3Rs
Yi14ZW4uYyBiL2RyaXZlcnMveGVuL3N3aW90bGItDQo+IHhlbi5jDQo+ID4gICAgICAgPiBpbmRl
eCBlYmQ4ZjIxLi4zYjhkNjI4IDEwMDY0NA0KPiA+ICAgICAgID4gLS0tIGEvZHJpdmVycy94ZW4v
c3dpb3RsYi14ZW4uYw0KPiA+ICAgICAgID4gKysrIGIvZHJpdmVycy94ZW4vc3dpb3RsYi14ZW4u
Yw0KPiA+ICAgICAgID4gQEAgLTQyNSw3ICs0MjUsNyBAQCBkbWFfYWRkcl90IHhlbl9zd2lvdGxi
X21hcF9wYWdlKHN0cnVjdA0KPiBkZXZpY2UgKmRldiwgc3RydWN0IHBhZ2UgKnBhZ2UsDQo+ID4g
ICAgICAgPsKgIMKgIMKgIMKgICovDQo+ID4gICAgICAgPsKgIMKgIMKgIMKgaWYgKCFkbWFfY2Fw
YWJsZShkZXYsIGRldl9hZGRyLCBzaXplKSkgew0KPiA+ICAgICAgID7CoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoHN3aW90bGJfdGJsX3VubWFwX3NpbmdsZShkZXYsIG1hcCwgc2l6ZSwgZGlyKTsNCj4g
PiAgICAgICA+IC3CoCDCoCDCoCDCoCDCoCDCoCDCoGRldl9hZGRyID0gMDsNCj4gPiAgICAgICA+
ICvCoCDCoCDCoCDCoCDCoCDCoCDCoGRldl9hZGRyID0gRE1BX0VSUk9SX0NPREU7DQo+ID4gICAg
ICAgPsKgIMKgIMKgIMKgfQ0KPiA+ICAgICAgID7CoCDCoCDCoCDCoHJldHVybiBkZXZfYWRkcjsN
Cj4gPiAgICAgICA+wqAgfQ0KPiA+ICAgICAgID4gLS0NCj4gPiAgICAgICA+IDEuOS4xDQo+ID4g
ICAgICAgPg0KPiA+ICAgICAgID4NCj4gPiAgICAgICA+IC0tDQo+ID4gICAgICAgPiBUbyB1bnN1
YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUNCj4gbGlu
dXgta2VybmVsIiBpbg0KPiA+ICAgICAgID4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9y
ZG9tb0B2Z2VyLmtlcm5lbC5vcmcNCj4gPiAgICAgICA+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXTC
oCBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby0NCj4gaW5mby5odG1sDQo+ID4gICAg
ICAgPiBQbGVhc2UgcmVhZCB0aGUgRkFRIGF0wqBodHRwOi8vc2VjdXJlLQ0KPiB3ZWIuY2lzY28u
Y29tLzFjdmpST3lVeFY2U25BMHVCVE1SdWJxclFXc2FYR2hwcy0NCj4gRldqWTN2bHk5QXhhS0ts
dDJEUFk3R2pMMEZDSGVQNHJzYmpLc2MtUDR6SDJfNy1rcGN4d0VILXVkR3JHQ0NxDQo+ID4gICAg
ICAga0NMbEgxLWZMT28xWDZObHVpNkV3RVZIVXBCMnI3Z3QtDQo+IEdzZ3hiZXA5UVdQbklkeXBE
UE5mOEhmNWNseENNWFljdldzT0s1czNxZy9odHRwJTNBJTJGJTJGd3d3LnR1eC5vcmclMkZsDQo+
IGttbCUyRg0KPiA+ICAgICAgID4NCj4gPg0KPiA+ICAgICAgIF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gICAgICAgWGVuLWRldmVsIG1haWxpbmcg
bGlzdA0KPiA+ICAgICAgIFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnDQo+ID4gICAgICAgaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsDQo+ID4NCj4gPg0KPiA+DQo+ID4NCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Fri Nov 07 10:28:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10: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 1Xmglc-0006G7-3K; Fri, 07 Nov 2014 10:27:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xmgla-0006G2-Jr
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:27:42 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2C/EF-09842-E9E9C545; Fri, 07 Nov 2014 10:27:42 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415356060!12142702!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29234 invoked from network); 7 Nov 2014 10:27:40 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-5.tower-21.messagelabs.com with SMTP;
	7 Nov 2014 10:27:40 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 07 Nov 2014 02:27:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,331,1413270000"; d="scan'208";a="618771741"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.176])
	([10.238.128.176])
	by fmsmga001.fm.intel.com with ESMTP; 07 Nov 2014 02:27:36 -0800
Message-ID: <545C9E97.4040800@intel.com>
Date: Fri, 07 Nov 2014 18:27:35 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
In-Reply-To: <545B562F02000078000453FB@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/6 18:06, Jan Beulich wrote:
>>>> On 06.11.14 at 10:28, <tiejun.chen@intel.com> wrote:
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -484,6 +484,14 @@ struct xen_domctl_assign_device {
>>    typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>>    DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
>>
>> +/* Control whether/how we check and reserve device memory. */
>> +struct xen_domctl_set_rdm {
>> +    uint32_t  pci_rdmforce;
>> +    uint32_t  pci_dev_bitmap;
>
> So this allows for 32 devices; considering that you index the bitmap

Sorry its my fault when I just focus on figuring out a doable way. We 
need to cover 256 x 32 x 8 = 65536.

> by BDF, all this covers are 0000:00:00.0 through 0000:00:03.7.
> Hardly enough to cover even a single pass through device (iirc the
> range above is fully used by emulated devices). And of course a

Are you saying Xen restrict some BDFs specific to emulate some devices? 
But I don't see these associated codes.

> much larger bitmap isn't a good solution either.

So I guess I need to reconstruct something new, please see the new draft 
codes.

>
> Nor am I really clear what you need the 32 bits of "pci_rdmforce"
> for, nor why this field isn't just being named "force". Without a

This variable can tell Xen to force check and reserve all RMRR ranges in 
that case the user is sure he's going to hotplug a device later but 
indeed, he really don't assign any device while creating a VM.

Please see the new draft codes as well.


> comment alongside the fields, it's remaining guesswork anyway
> when and how this domctl is to be used. Looking at your change
> to intel_iommu_get_reserved_device_memory() the field appears
> to be simply redundant.
>
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -158,14 +158,14 @@ struct iommu_ops {
>>        void (*crash_shutdown)(void);
>>        void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int page_count);
>>        void (*iotlb_flush_all)(struct domain *d);
>> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
>> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct domain *, void *);
>>        void (*dump_p2m_table)(struct domain *d);
>>    };
>>
>>    void iommu_suspend(void);
>>    void iommu_resume(void);
>>    void iommu_crash_shutdown(void);
>> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
>> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain *, void *);
>
> I don't see why these generic interfaces would need to change;
> the only thing that would seem to need changing is the callback
> function (and of course the context passed to it).
>

I'm not 100% sure if we can call current->domain in all scenarios. If 
you can help me confirm this I'd really like to remove this change :) 
Now I assume this should be true as follows:

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 30764b4..5957d2e 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2036,6 +2036,12 @@ int xc_assign_device(xc_interface *xch,
                       uint32_t domid,
                       uint32_t machine_bdf);

+int xc_domain_device_setrdm(xc_interface *xch,
+                            uint32_t domid,
+                            uint32_t num_pcidevs,
+                            uint32_t pci_rdmforce,
+                            struct xen_guest_pcidev_info *pcidevs);
+
  int xc_get_device_group(xc_interface *xch,
                       uint32_t domid,
                       uint32_t machine_bdf,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 009e351..f38b400 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1642,6 +1642,34 @@ int xc_assign_device(
      return do_domctl(xch, &domctl);
  }

+int xc_domain_device_setrdm(xc_interface *xch,
+                            uint32_t domid,
+                            uint32_t num_pcidevs,
+                            uint32_t pci_rdmforce,
+                            struct xen_guest_pcidev_info *pcidevs)
+{
+    int ret;
+    DECLARE_DOMCTL;
+    DECLARE_HYPERCALL_BOUNCE(pcidevs,
+                             num_pcidevs*sizeof(xen_guest_pcidev_info_t),
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+    if ( xc_hypercall_bounce_pre(xch, pcidevs) )
+        return -1;
+
+    domctl.cmd = XEN_DOMCTL_set_rdm;
+    domctl.domain = domid;
+    domctl.u.set_rdm.pci_rdmforce = pci_rdmforce;
+    domctl.u.set_rdm.num_pcidevs = num_pcidevs;
+    set_xen_guest_handle(domctl.u.set_rdm.pcidevs, pcidevs);
+
+    ret = do_domctl(xch, &domctl);
+
+    xc_hypercall_bounce_post(xch, pcidevs);
+
+    return ret;
+}
+
  int xc_get_device_group(
      xc_interface *xch,
      uint32_t domid,
diff --git a/tools/libxc/xc_domain_restore.c 
b/tools/libxc/xc_domain_restore.c
index d8bd9b3..ac48a82 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -2165,8 +2165,8 @@ int xc_domain_restore(xc_interface *xch, int 
io_fd, uint32_t dom,

          if ( !ext_vcpucontext )
              goto vcpu_ext_state_restore;
-        memcpy(&domctl.u.ext_vcpucontext, vcpup, 128);
-        vcpup += 128;
+        memcpy(&domctl.u.ext_vcpucontext, vcpup, 112);
+        vcpup += 112;
          domctl.cmd = XEN_DOMCTL_set_ext_vcpucontext;
          domctl.domain = dom;
          frc = xc_domctl(xch, &domctl);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..2429416 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -860,6 +860,9 @@ static void initiate_domain_create(libxl__egc *egc,
      ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
      if (ret) goto error_out;

+    ret = libxl__domain_device_setrdm(gc, d_config, domid);
+    if (ret) goto error_out;
+
      if (!sched_params_valid(gc, domid, &d_config->b_info.sched_params)) {
          LOG(ERROR, "Invalid scheduling parameters\n");
          ret = ERROR_INVAL;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..9e402d1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -90,6 +90,42 @@ const char *libxl__domain_device_model(libxl__gc *gc,
      return dm;
  }

+int libxl__domain_device_setrdm(libxl__gc *gc,
+                                libxl_domain_config *d_config,
+                                uint32_t dm_domid)
+{
+    int i, ret;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    struct xen_guest_pcidev_info *pcidevs = NULL;
+
+    if ( d_config->num_pcidevs )
+    {
+        pcidevs = 
malloc(d_config->num_pcidevs*sizeof(xen_guest_pcidev_info_t));
+        if ( pcidevs )
+        {
+            for (i = 0; i < d_config->num_pcidevs; i++)
+            {
+                pcidevs[i].func = d_config->pcidevs[i].func;
+                pcidevs[i].dev = d_config->pcidevs[i].dev;
+                pcidevs[i].bus = d_config->pcidevs[i].bus;
+                pcidevs[i].domain = d_config->pcidevs[i].domain;
+                pcidevs[i].rdmforce = d_config->pcidevs[i].rdmforce;
+            }
+        }
+        else
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                               "Can't allocate for pcidevs.");
+    }
+
+    ret = xc_domain_device_setrdm(ctx->xch, dm_domid,
+                                  (uint32_t)d_config->num_pcidevs,
+                                  d_config->b_info.pci_rdmforce,
+                                  pcidevs);
+    free(pcidevs);
+
+    return ret;
+}
+
  const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config 
*guest_config)
  {
      const libxl_vnc_info *vnc = NULL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..c48a0e6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1471,6 +1471,11 @@ _hidden int libxl__domain_build(libxl__gc *gc,
  /* for device model creation */
  _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                          const libxl_domain_build_info 
*info);
+
+_hidden int libxl__domain_device_setrdm(libxl__gc *gc,
+                                        libxl_domain_config *d_config,
+                                        uint32_t domid);
+
  _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
          int nr_consoles, libxl__device_console *consoles,
          int nr_vfbs, libxl_device_vfb *vfbs,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ca3f724..b700263 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -398,6 +398,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
      ("kernel",           string),
      ("cmdline",          string),
      ("ramdisk",          string),
+    ("pci_rdmforce",   uint32),
      ("u", KeyedUnion(None, libxl_domain_type, "type",
                  [("hvm", Struct(None, [("firmware",         string),
                                         ("bios", 
libxl_bios_type),
@@ -518,6 +519,7 @@ libxl_device_pci = Struct("device_pci", [
      ("power_mgmt", bool),
      ("permissive", bool),
      ("seize", bool),
+    ("rdmforce", bool),
      ])

  libxl_device_vtpm = Struct("device_vtpm", [
diff --git a/tools/libxl/libxlu_pci.c b/tools/libxl/libxlu_pci.c
index 26fb143..989eac8 100644
--- a/tools/libxl/libxlu_pci.c
+++ b/tools/libxl/libxlu_pci.c
@@ -143,6 +143,8 @@ int xlu_pci_parse_bdf(XLU_Config *cfg, 
libxl_device_pci *pcidev, const char *str
                      pcidev->permissive = atoi(tok);
                  }else if ( !strcmp(optkey, "seize") ) {
                      pcidev->seize = atoi(tok);
+                }else if ( !strcmp(optkey, "rdmforce") ) {
+                    pcidev->rdmforce = atoi(tok);
                  }else{
                      XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", 
optkey);
                  }
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..436b4f3 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -904,6 +904,7 @@ static void replace_string(char **str, const char *val)
      *str = xstrdup(val);
  }

+#define PCI_BDF(b,d,f) ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
  static void parse_config_data(const char *config_source,
                                const char *config_data,
                                int config_len,
@@ -919,6 +920,7 @@ static void parse_config_data(const char *config_source,
      int pci_msitranslate = 0;
      int pci_permissive = 0;
      int pci_seize = 0;
+    int pci_rdmforce = 0;
      int i, e;

      libxl_domain_create_info *c_info = &d_config->c_info;
@@ -1699,6 +1701,9 @@ skip_vfb:
      if (!xlu_cfg_get_long (config, "pci_seize", &l, 0))
          pci_seize = l;

+    if (!xlu_cfg_get_long (config, "pci_rdmforce", &l, 0))
+        pci_rdmforce = l;
+
      /* To be reworked (automatically enabled) once the auto ballooning
       * after guest starts is done (with PCI devices passed in). */
      if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
@@ -1719,9 +1724,11 @@ skip_vfb:
              pcidev->power_mgmt = pci_power_mgmt;
              pcidev->permissive = pci_permissive;
              pcidev->seize = pci_seize;
+            pcidev->rdmforce = pci_rdmforce;
              if (!xlu_pci_parse_bdf(config, pcidev, buf))
                  d_config->num_pcidevs++;
          }
+        d_config->b_info.pci_rdmforce = pci_rdmforce;
          if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
              libxl_defbool_set(&b_info->u.pv.e820_host, true);
      }
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1eba833..daf259e 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1540,6 +1540,34 @@ int iommu_do_pci_domctl(
          }
          break;

+    case XEN_DOMCTL_set_rdm:
+    {
+        struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
+        struct xen_guest_pcidev_info *pcidevs;
+        int i;
+
+        pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
+                                domctl->u.set_rdm.num_pcidevs);
+        if ( pcidevs == NULL )
+        {
+            return -ENOMEM;
+        }
+
+        for ( i = 0; i < xdsr->num_pcidevs; ++i )
+        {
+            if ( __copy_from_guest_offset(pcidevs, xdsr->pcidevs, i, 1) )
+            {
+                xfree(pcidevs);
+                return -EFAULT;
+            }
+        }
+
+        d->arch.hvm_domain.pci_rdmforce = domctl->u.set_rdm.pci_rdmforce;
+        d->arch.hvm_domain.num_pcidevs = domctl->u.set_rdm.num_pcidevs;
+        d->arch.hvm_domain.pcidevs = pcidevs;
+    }
+        break;
+
      case XEN_DOMCTL_assign_device:
          if ( unlikely(d->is_dying) )
          {
diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 546eca9..4b35c04 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -28,6 +28,7 @@
  #include <xen/xmalloc.h>
  #include <xen/pci.h>
  #include <xen/pci_regs.h>
+#include <xen/sched.h>
  #include <asm/string.h>
  #include "dmar.h"
  #include "iommu.h"
@@ -925,14 +926,37 @@ int 
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
      int rc = 0;
+    int i, j;
+    u16 bdf, pt_bdf;
+    struct domain *d = current->domain;

-    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+    for_each_rmrr_device ( rmrr, bdf, i )
      {
-        rc = func(PFN_DOWN(rmrr->base_address),
-                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
-                  ctxt);
-        if ( rc )
-            break;
+        if ( d->arch.hvm_domain.pci_rdmforce )
+        {
+            rc = func(PFN_DOWN(rmrr->base_address),
+                      PFN_UP(rmrr->end_address) -
+                      PFN_DOWN(rmrr->base_address),
+                      ctxt);
+            if ( rc )
+                break;
+        }
+        else
+        {
+            for ( j = 0; j < d->arch.hvm_domain.num_pcidevs; j++ )
+            {
+                pt_bdf = PCI_BDF(d->arch.hvm_domain.pcidevs[j].bus,
+                                 d->arch.hvm_domain.pcidevs[j].dev,
+                                 d->arch.hvm_domain.pcidevs[j].func);
+                if ( pt_bdf == bdf )
+                    rc = func(PFN_DOWN(rmrr->base_address),
+                              PFN_UP(rmrr->end_address) -
+                              PFN_DOWN(rmrr->base_address),
+                              ctxt);
+                if ( rc )
+                    break;
+            }
+        }
      }

      return rc;
diff --git a/xen/include/asm-x86/hvm/domain.h 
b/xen/include/asm-x86/hvm/domain.h
index 2757c7f..b18ce40 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -90,6 +90,10 @@ struct hvm_domain {
      /* Cached CF8 for guest PCI config cycles */
      uint32_t                pci_cf8;

+    uint32_t                pci_rdmforce;
+    uint32_t                num_pcidevs;
+    struct xen_guest_pcidev_info      *pcidevs;
+
      struct pl_time         pl_time;

      struct hvm_io_handler *io_handler;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 58b19e7..4e47fac 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -484,6 +484,24 @@ struct xen_domctl_assign_device {
  typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
  DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);

+struct xen_guest_pcidev_info {
+    uint8_t func;
+    uint8_t dev;
+    uint8_t bus;
+    int domain;
+    int rdmforce;
+};
+typedef struct xen_guest_pcidev_info xen_guest_pcidev_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_guest_pcidev_info_t);
+/* Control whether/how we check and reserve device memory. */
+struct xen_domctl_set_rdm {
+    uint32_t  pci_rdmforce;
+    uint32_t  num_pcidevs;
+    XEN_GUEST_HANDLE(xen_guest_pcidev_info_t) pcidevs;
+};
+typedef struct xen_domctl_set_rdm xen_domctl_set_rdm_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_rdm_t);
+
  /* Retrieve sibling devices infomation of machine_sbdf */
  /* XEN_DOMCTL_get_device_group */
  struct xen_domctl_get_device_group {
@@ -1056,6 +1074,7 @@ struct xen_domctl {
  #define XEN_DOMCTL_set_vcpu_msrs                 73
  #define XEN_DOMCTL_setvnumainfo                  74
  #define XEN_DOMCTL_psr_cmt_op                    75
+#define XEN_DOMCTL_set_rdm                       76
  #define XEN_DOMCTL_gdbsx_guestmemio            1000
  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1118,7 +1137,8 @@ struct xen_domctl {
          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
          struct xen_domctl_vnuma             vnuma;
          struct xen_domctl_psr_cmt_op        psr_cmt_op;
-        uint8_t                             pad[128];
+        struct xen_domctl_set_rdm           set_rdm;
+        uint8_t                             pad[112];
      } u;
  };
  typedef struct xen_domctl xen_domctl_t;


Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 10:28:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10: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 1Xmglc-0006G7-3K; Fri, 07 Nov 2014 10:27:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xmgla-0006G2-Jr
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:27:42 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2C/EF-09842-E9E9C545; Fri, 07 Nov 2014 10:27:42 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415356060!12142702!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29234 invoked from network); 7 Nov 2014 10:27:40 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-5.tower-21.messagelabs.com with SMTP;
	7 Nov 2014 10:27:40 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 07 Nov 2014 02:27:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,331,1413270000"; d="scan'208";a="618771741"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.176])
	([10.238.128.176])
	by fmsmga001.fm.intel.com with ESMTP; 07 Nov 2014 02:27:36 -0800
Message-ID: <545C9E97.4040800@intel.com>
Date: Fri, 07 Nov 2014 18:27:35 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
In-Reply-To: <545B562F02000078000453FB@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/6 18:06, Jan Beulich wrote:
>>>> On 06.11.14 at 10:28, <tiejun.chen@intel.com> wrote:
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -484,6 +484,14 @@ struct xen_domctl_assign_device {
>>    typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>>    DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
>>
>> +/* Control whether/how we check and reserve device memory. */
>> +struct xen_domctl_set_rdm {
>> +    uint32_t  pci_rdmforce;
>> +    uint32_t  pci_dev_bitmap;
>
> So this allows for 32 devices; considering that you index the bitmap

Sorry its my fault when I just focus on figuring out a doable way. We 
need to cover 256 x 32 x 8 = 65536.

> by BDF, all this covers are 0000:00:00.0 through 0000:00:03.7.
> Hardly enough to cover even a single pass through device (iirc the
> range above is fully used by emulated devices). And of course a

Are you saying Xen restrict some BDFs specific to emulate some devices? 
But I don't see these associated codes.

> much larger bitmap isn't a good solution either.

So I guess I need to reconstruct something new, please see the new draft 
codes.

>
> Nor am I really clear what you need the 32 bits of "pci_rdmforce"
> for, nor why this field isn't just being named "force". Without a

This variable can tell Xen to force check and reserve all RMRR ranges in 
that case the user is sure he's going to hotplug a device later but 
indeed, he really don't assign any device while creating a VM.

Please see the new draft codes as well.


> comment alongside the fields, it's remaining guesswork anyway
> when and how this domctl is to be used. Looking at your change
> to intel_iommu_get_reserved_device_memory() the field appears
> to be simply redundant.
>
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -158,14 +158,14 @@ struct iommu_ops {
>>        void (*crash_shutdown)(void);
>>        void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int page_count);
>>        void (*iotlb_flush_all)(struct domain *d);
>> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
>> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct domain *, void *);
>>        void (*dump_p2m_table)(struct domain *d);
>>    };
>>
>>    void iommu_suspend(void);
>>    void iommu_resume(void);
>>    void iommu_crash_shutdown(void);
>> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
>> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain *, void *);
>
> I don't see why these generic interfaces would need to change;
> the only thing that would seem to need changing is the callback
> function (and of course the context passed to it).
>

I'm not 100% sure if we can call current->domain in all scenarios. If 
you can help me confirm this I'd really like to remove this change :) 
Now I assume this should be true as follows:

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 30764b4..5957d2e 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2036,6 +2036,12 @@ int xc_assign_device(xc_interface *xch,
                       uint32_t domid,
                       uint32_t machine_bdf);

+int xc_domain_device_setrdm(xc_interface *xch,
+                            uint32_t domid,
+                            uint32_t num_pcidevs,
+                            uint32_t pci_rdmforce,
+                            struct xen_guest_pcidev_info *pcidevs);
+
  int xc_get_device_group(xc_interface *xch,
                       uint32_t domid,
                       uint32_t machine_bdf,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 009e351..f38b400 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1642,6 +1642,34 @@ int xc_assign_device(
      return do_domctl(xch, &domctl);
  }

+int xc_domain_device_setrdm(xc_interface *xch,
+                            uint32_t domid,
+                            uint32_t num_pcidevs,
+                            uint32_t pci_rdmforce,
+                            struct xen_guest_pcidev_info *pcidevs)
+{
+    int ret;
+    DECLARE_DOMCTL;
+    DECLARE_HYPERCALL_BOUNCE(pcidevs,
+                             num_pcidevs*sizeof(xen_guest_pcidev_info_t),
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+    if ( xc_hypercall_bounce_pre(xch, pcidevs) )
+        return -1;
+
+    domctl.cmd = XEN_DOMCTL_set_rdm;
+    domctl.domain = domid;
+    domctl.u.set_rdm.pci_rdmforce = pci_rdmforce;
+    domctl.u.set_rdm.num_pcidevs = num_pcidevs;
+    set_xen_guest_handle(domctl.u.set_rdm.pcidevs, pcidevs);
+
+    ret = do_domctl(xch, &domctl);
+
+    xc_hypercall_bounce_post(xch, pcidevs);
+
+    return ret;
+}
+
  int xc_get_device_group(
      xc_interface *xch,
      uint32_t domid,
diff --git a/tools/libxc/xc_domain_restore.c 
b/tools/libxc/xc_domain_restore.c
index d8bd9b3..ac48a82 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -2165,8 +2165,8 @@ int xc_domain_restore(xc_interface *xch, int 
io_fd, uint32_t dom,

          if ( !ext_vcpucontext )
              goto vcpu_ext_state_restore;
-        memcpy(&domctl.u.ext_vcpucontext, vcpup, 128);
-        vcpup += 128;
+        memcpy(&domctl.u.ext_vcpucontext, vcpup, 112);
+        vcpup += 112;
          domctl.cmd = XEN_DOMCTL_set_ext_vcpucontext;
          domctl.domain = dom;
          frc = xc_domctl(xch, &domctl);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..2429416 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -860,6 +860,9 @@ static void initiate_domain_create(libxl__egc *egc,
      ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
      if (ret) goto error_out;

+    ret = libxl__domain_device_setrdm(gc, d_config, domid);
+    if (ret) goto error_out;
+
      if (!sched_params_valid(gc, domid, &d_config->b_info.sched_params)) {
          LOG(ERROR, "Invalid scheduling parameters\n");
          ret = ERROR_INVAL;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..9e402d1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -90,6 +90,42 @@ const char *libxl__domain_device_model(libxl__gc *gc,
      return dm;
  }

+int libxl__domain_device_setrdm(libxl__gc *gc,
+                                libxl_domain_config *d_config,
+                                uint32_t dm_domid)
+{
+    int i, ret;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    struct xen_guest_pcidev_info *pcidevs = NULL;
+
+    if ( d_config->num_pcidevs )
+    {
+        pcidevs = 
malloc(d_config->num_pcidevs*sizeof(xen_guest_pcidev_info_t));
+        if ( pcidevs )
+        {
+            for (i = 0; i < d_config->num_pcidevs; i++)
+            {
+                pcidevs[i].func = d_config->pcidevs[i].func;
+                pcidevs[i].dev = d_config->pcidevs[i].dev;
+                pcidevs[i].bus = d_config->pcidevs[i].bus;
+                pcidevs[i].domain = d_config->pcidevs[i].domain;
+                pcidevs[i].rdmforce = d_config->pcidevs[i].rdmforce;
+            }
+        }
+        else
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                               "Can't allocate for pcidevs.");
+    }
+
+    ret = xc_domain_device_setrdm(ctx->xch, dm_domid,
+                                  (uint32_t)d_config->num_pcidevs,
+                                  d_config->b_info.pci_rdmforce,
+                                  pcidevs);
+    free(pcidevs);
+
+    return ret;
+}
+
  const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config 
*guest_config)
  {
      const libxl_vnc_info *vnc = NULL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..c48a0e6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1471,6 +1471,11 @@ _hidden int libxl__domain_build(libxl__gc *gc,
  /* for device model creation */
  _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                          const libxl_domain_build_info 
*info);
+
+_hidden int libxl__domain_device_setrdm(libxl__gc *gc,
+                                        libxl_domain_config *d_config,
+                                        uint32_t domid);
+
  _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
          int nr_consoles, libxl__device_console *consoles,
          int nr_vfbs, libxl_device_vfb *vfbs,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ca3f724..b700263 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -398,6 +398,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
      ("kernel",           string),
      ("cmdline",          string),
      ("ramdisk",          string),
+    ("pci_rdmforce",   uint32),
      ("u", KeyedUnion(None, libxl_domain_type, "type",
                  [("hvm", Struct(None, [("firmware",         string),
                                         ("bios", 
libxl_bios_type),
@@ -518,6 +519,7 @@ libxl_device_pci = Struct("device_pci", [
      ("power_mgmt", bool),
      ("permissive", bool),
      ("seize", bool),
+    ("rdmforce", bool),
      ])

  libxl_device_vtpm = Struct("device_vtpm", [
diff --git a/tools/libxl/libxlu_pci.c b/tools/libxl/libxlu_pci.c
index 26fb143..989eac8 100644
--- a/tools/libxl/libxlu_pci.c
+++ b/tools/libxl/libxlu_pci.c
@@ -143,6 +143,8 @@ int xlu_pci_parse_bdf(XLU_Config *cfg, 
libxl_device_pci *pcidev, const char *str
                      pcidev->permissive = atoi(tok);
                  }else if ( !strcmp(optkey, "seize") ) {
                      pcidev->seize = atoi(tok);
+                }else if ( !strcmp(optkey, "rdmforce") ) {
+                    pcidev->rdmforce = atoi(tok);
                  }else{
                      XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", 
optkey);
                  }
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..436b4f3 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -904,6 +904,7 @@ static void replace_string(char **str, const char *val)
      *str = xstrdup(val);
  }

+#define PCI_BDF(b,d,f) ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
  static void parse_config_data(const char *config_source,
                                const char *config_data,
                                int config_len,
@@ -919,6 +920,7 @@ static void parse_config_data(const char *config_source,
      int pci_msitranslate = 0;
      int pci_permissive = 0;
      int pci_seize = 0;
+    int pci_rdmforce = 0;
      int i, e;

      libxl_domain_create_info *c_info = &d_config->c_info;
@@ -1699,6 +1701,9 @@ skip_vfb:
      if (!xlu_cfg_get_long (config, "pci_seize", &l, 0))
          pci_seize = l;

+    if (!xlu_cfg_get_long (config, "pci_rdmforce", &l, 0))
+        pci_rdmforce = l;
+
      /* To be reworked (automatically enabled) once the auto ballooning
       * after guest starts is done (with PCI devices passed in). */
      if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
@@ -1719,9 +1724,11 @@ skip_vfb:
              pcidev->power_mgmt = pci_power_mgmt;
              pcidev->permissive = pci_permissive;
              pcidev->seize = pci_seize;
+            pcidev->rdmforce = pci_rdmforce;
              if (!xlu_pci_parse_bdf(config, pcidev, buf))
                  d_config->num_pcidevs++;
          }
+        d_config->b_info.pci_rdmforce = pci_rdmforce;
          if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
              libxl_defbool_set(&b_info->u.pv.e820_host, true);
      }
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1eba833..daf259e 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1540,6 +1540,34 @@ int iommu_do_pci_domctl(
          }
          break;

+    case XEN_DOMCTL_set_rdm:
+    {
+        struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
+        struct xen_guest_pcidev_info *pcidevs;
+        int i;
+
+        pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
+                                domctl->u.set_rdm.num_pcidevs);
+        if ( pcidevs == NULL )
+        {
+            return -ENOMEM;
+        }
+
+        for ( i = 0; i < xdsr->num_pcidevs; ++i )
+        {
+            if ( __copy_from_guest_offset(pcidevs, xdsr->pcidevs, i, 1) )
+            {
+                xfree(pcidevs);
+                return -EFAULT;
+            }
+        }
+
+        d->arch.hvm_domain.pci_rdmforce = domctl->u.set_rdm.pci_rdmforce;
+        d->arch.hvm_domain.num_pcidevs = domctl->u.set_rdm.num_pcidevs;
+        d->arch.hvm_domain.pcidevs = pcidevs;
+    }
+        break;
+
      case XEN_DOMCTL_assign_device:
          if ( unlikely(d->is_dying) )
          {
diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 546eca9..4b35c04 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -28,6 +28,7 @@
  #include <xen/xmalloc.h>
  #include <xen/pci.h>
  #include <xen/pci_regs.h>
+#include <xen/sched.h>
  #include <asm/string.h>
  #include "dmar.h"
  #include "iommu.h"
@@ -925,14 +926,37 @@ int 
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
      int rc = 0;
+    int i, j;
+    u16 bdf, pt_bdf;
+    struct domain *d = current->domain;

-    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+    for_each_rmrr_device ( rmrr, bdf, i )
      {
-        rc = func(PFN_DOWN(rmrr->base_address),
-                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
-                  ctxt);
-        if ( rc )
-            break;
+        if ( d->arch.hvm_domain.pci_rdmforce )
+        {
+            rc = func(PFN_DOWN(rmrr->base_address),
+                      PFN_UP(rmrr->end_address) -
+                      PFN_DOWN(rmrr->base_address),
+                      ctxt);
+            if ( rc )
+                break;
+        }
+        else
+        {
+            for ( j = 0; j < d->arch.hvm_domain.num_pcidevs; j++ )
+            {
+                pt_bdf = PCI_BDF(d->arch.hvm_domain.pcidevs[j].bus,
+                                 d->arch.hvm_domain.pcidevs[j].dev,
+                                 d->arch.hvm_domain.pcidevs[j].func);
+                if ( pt_bdf == bdf )
+                    rc = func(PFN_DOWN(rmrr->base_address),
+                              PFN_UP(rmrr->end_address) -
+                              PFN_DOWN(rmrr->base_address),
+                              ctxt);
+                if ( rc )
+                    break;
+            }
+        }
      }

      return rc;
diff --git a/xen/include/asm-x86/hvm/domain.h 
b/xen/include/asm-x86/hvm/domain.h
index 2757c7f..b18ce40 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -90,6 +90,10 @@ struct hvm_domain {
      /* Cached CF8 for guest PCI config cycles */
      uint32_t                pci_cf8;

+    uint32_t                pci_rdmforce;
+    uint32_t                num_pcidevs;
+    struct xen_guest_pcidev_info      *pcidevs;
+
      struct pl_time         pl_time;

      struct hvm_io_handler *io_handler;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 58b19e7..4e47fac 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -484,6 +484,24 @@ struct xen_domctl_assign_device {
  typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
  DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);

+struct xen_guest_pcidev_info {
+    uint8_t func;
+    uint8_t dev;
+    uint8_t bus;
+    int domain;
+    int rdmforce;
+};
+typedef struct xen_guest_pcidev_info xen_guest_pcidev_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_guest_pcidev_info_t);
+/* Control whether/how we check and reserve device memory. */
+struct xen_domctl_set_rdm {
+    uint32_t  pci_rdmforce;
+    uint32_t  num_pcidevs;
+    XEN_GUEST_HANDLE(xen_guest_pcidev_info_t) pcidevs;
+};
+typedef struct xen_domctl_set_rdm xen_domctl_set_rdm_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_rdm_t);
+
  /* Retrieve sibling devices infomation of machine_sbdf */
  /* XEN_DOMCTL_get_device_group */
  struct xen_domctl_get_device_group {
@@ -1056,6 +1074,7 @@ struct xen_domctl {
  #define XEN_DOMCTL_set_vcpu_msrs                 73
  #define XEN_DOMCTL_setvnumainfo                  74
  #define XEN_DOMCTL_psr_cmt_op                    75
+#define XEN_DOMCTL_set_rdm                       76
  #define XEN_DOMCTL_gdbsx_guestmemio            1000
  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1118,7 +1137,8 @@ struct xen_domctl {
          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
          struct xen_domctl_vnuma             vnuma;
          struct xen_domctl_psr_cmt_op        psr_cmt_op;
-        uint8_t                             pad[128];
+        struct xen_domctl_set_rdm           set_rdm;
+        uint8_t                             pad[112];
      } u;
  };
  typedef struct xen_domctl xen_domctl_t;


Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 10:30:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmgnp-0006NI-RC; Fri, 07 Nov 2014 10:30:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xmgno-0006N9-2Q
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:30:00 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	A9/78-27785-72F9C545; Fri, 07 Nov 2014 10:29:59 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415356198!12021993!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15392 invoked from network); 7 Nov 2014 10:29:58 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:29:58 -0000
Received: by mail-wg0-f54.google.com with SMTP id n12so3343701wgh.13
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:29:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=T6H7hpxj/6Kis21UUQZd7G5IdI2+PpdOFNcOtpfyKvM=;
	b=VFMyoudLjQEthJUVtqklZeycNDwAliSVizU738LJnMmz+IPqqCtBhC0NslJ3NGvz3u
	m3PDwEwJynmAjcZWbLh26XWBnIme958TWV7HS+mC/z/UxJJVvXfUCn0XEJMCxyxKZtNW
	dSTYTOCGn+Xk2ItfYaDQeqGf+jKFnYa5DFAlvNtmvg/jdFUuTKqoO+Y38Gnh0kBVwq+D
	b1GSLEK9gtE3kOUe7B4FT8dZbravClx8jIc3S7azHas5mhjqM3Qccfy/TlAs2+NJrCZu
	OQ/3/Bivydp5WvxrlPCKu5ZgOwj4TIlXDCYOeT5NI5tXdP1JvLWldt47I3O3VIz8+JeX
	ZelA==
X-Gm-Message-State: ALoCoQn2L8mzj//JWXnkF8AO6vMzSpQT5JzYesFzgDOtGHFCyj/yNfRaq1iAAQFK3H22FFsDKOY8
X-Received: by 10.195.13.114 with SMTP id ex18mr14298487wjd.111.1415356197363; 
	Fri, 07 Nov 2014 02:29:57 -0800 (PST)
Received: from [192.168.42.189] (92.40.248.106.threembb.co.uk. [92.40.248.106])
	by mx.google.com with ESMTPSA id m6sm1480201wiy.16.2014.11.07.02.29.54
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 02:29:56 -0800 (PST)
Message-ID: <545C9F20.5000702@linaro.org>
Date: Fri, 07 Nov 2014 10:29:52 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>	<20141008124657.GB13391@laptop.dumpdata.com>	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>	<1412775916.24894.15.camel@citrix.com>	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>	<20141008145107.GC18573@laptop.dumpdata.com>	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>	<alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>	<CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>	<545B9B96.6080102@linaro.org>	<alpine.DEB.2.02.1411061607150.22875@kaball.uk.xensource.com>
	<CAAiw7JmvYpzYsQzg40+bmLWu+6SPJk4J09fuiYStR3LF62bLZQ@mail.gmail.com>
In-Reply-To: <CAAiw7JmvYpzYsQzg40+bmLWu+6SPJk4J09fuiYStR3LF62bLZQ@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Ryan Wilson <hap9@epoch.ncsc.mil>,
	xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Manish,

On 06/11/2014 16:20, manish jaggi wrote:
> On 6 November 2014 21:37, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Thu, 6 Nov 2014, Julien Grall wrote:
>>> Hi Manish,
>>>
>>> On 06/11/2014 15:55, manish jaggi wrote:
>>>> On 6 November 2014 21:18, Stefano Stabellini
>>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>>> On Thu, 6 Nov 2014, manish jaggi wrote:
>>>>>> On 20 October 2014 20:24, Stefano Stabellini
>>>>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>>>>> On Mon, 20 Oct 2014, manish jaggi wrote:
>>>>>>>> On 8 October 2014 20:21, Konrad Rzeszutek Wilk
>>>>>>>> <konrad.wilk@oracle.com> wrote:
>>>>>>>>> On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
>>>>>>>>>> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
>>>>>>>>>>>> Thanks for replying. As detailed in this thread, I need to
>>>>>>>>>>>> create a
>>>>>>>>>>>> hypercall that would send the following information to Xen
>>>>>>>>>>>> at the time
>>>>>>>>>>>> of PCI attach
>>>>>>>>>>>> { sbdf , domU sbdf, domainId }.
>>>>>>>>>>>> I am not able to find a way to get the domU sbdf from dom0
>>>>>>>>>>>> at the time
>>>>>>>>>>>> of pci-attach.
>>>>>>>>>>>
>>>>>>>>>>> I think it would need to be done by the pciback driver in the
>>>>>>>>>>> dom0
>>>>>>>>>>> kernel, which AFAIK is the thing which consistently knows both
>>>>>>>>>>> physical
>>>>>>>>>>> and virtual sbdf for a given assigned device.
>>>>>>>>>>>
>>>>>>>>>>> Ian.
>>>>>>>>>>>
>>>>>>>>>> Correct, can you point out which data structure holds the domU
>>>>>>>>>> sbdf
>>>>>>>>>> corresponding to the actual sbdf in pciback.
>>>>>>>>>
>>>>>>>>> See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
>>>>>>>>> is that what you are referring to?
>>>>>>>>
>>>>>>>> Xen docs also mention about xen-pciback.passthrough=1. If I set this
>>>>>>>> in dom0 i see that the device is enumerated as the same sbdf in
>>>>>>>> domU,
>>>>>>>> but
>>>>>>>> a) it is not shown in lspci
>>>>>>>> b) no front-back communication is done for reading devices
>>>>>>>> configuration space
>>>>>>>> .
>>>>>>>> Is option useful / fully implemented for ARM ?
>>>>>>>
>>>>>>> I don't think this option is very useful. I wouldn't worry about it
>>>>>>> for
>>>>>>> now.
>>>>>>
>>>>>> Stefano / Ian / Konard / Julien,
>>>>>>
>>>>>> Attached is a first raw code FYI RFC Patches of PCI passthrough support
>>>>>> on ARM.
>>>>>> - Linux Patch (3.18)
>>>>>> - Xen Patch  (4.5 staging)
>>>>>> ---(Smmu changes not included, thats a separate patch altogether)
>>>>>> This patches show the logic, at places need of improvements in code
>>>>>> organization/quality. I wanted to share to get initial comments.
>>>>>> This is working with SRIOV as well.
>>>>>>
>>>>>> Please have a look and let me know your positive comments
>>>>>
>>>>> Please send as individual inline patches. not attachments.
>>>>> Please also add a proper description to each patch and an entry 0/N email
>>>>> with the high level explanation of your work.
>>>>>
>>>>> See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
>>>> Stefano I just wanted to share the patches as reference to our
>>>> discussion on the approach. Please recall I had shared in this mail a
>>>> design flow. These are just an extension to it. I wanted to move this
>>>> discussion to a conclusion
>>>> There are not patches which I am submitting to xen git.
>>>> If you are ok with the approach I will formally send the patches post
>>>> 4.5 release.
>>>
>>> In this case you can send the patch series tagged "[RFC]" in the subject.
>>
>> That's right. It is difficult to give even just an early feedback
>> without the patch descriptions.
>>
> I assumed that the context is preserved in this mail thread. I shared
> the flow in the first few mails and am sharing the code after a lot of
> discussion in this thread.

There is about 30 mails in this discussion. It's better if you give a 
summary, it will avoid us to read again all the mails to find the 
conclusion.

> Anyhow I will share the code as RFC in some time.

Thanks,

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 10:30:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmgnp-0006NI-RC; Fri, 07 Nov 2014 10:30:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xmgno-0006N9-2Q
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:30:00 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	A9/78-27785-72F9C545; Fri, 07 Nov 2014 10:29:59 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415356198!12021993!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15392 invoked from network); 7 Nov 2014 10:29:58 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:29:58 -0000
Received: by mail-wg0-f54.google.com with SMTP id n12so3343701wgh.13
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:29:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=T6H7hpxj/6Kis21UUQZd7G5IdI2+PpdOFNcOtpfyKvM=;
	b=VFMyoudLjQEthJUVtqklZeycNDwAliSVizU738LJnMmz+IPqqCtBhC0NslJ3NGvz3u
	m3PDwEwJynmAjcZWbLh26XWBnIme958TWV7HS+mC/z/UxJJVvXfUCn0XEJMCxyxKZtNW
	dSTYTOCGn+Xk2ItfYaDQeqGf+jKFnYa5DFAlvNtmvg/jdFUuTKqoO+Y38Gnh0kBVwq+D
	b1GSLEK9gtE3kOUe7B4FT8dZbravClx8jIc3S7azHas5mhjqM3Qccfy/TlAs2+NJrCZu
	OQ/3/Bivydp5WvxrlPCKu5ZgOwj4TIlXDCYOeT5NI5tXdP1JvLWldt47I3O3VIz8+JeX
	ZelA==
X-Gm-Message-State: ALoCoQn2L8mzj//JWXnkF8AO6vMzSpQT5JzYesFzgDOtGHFCyj/yNfRaq1iAAQFK3H22FFsDKOY8
X-Received: by 10.195.13.114 with SMTP id ex18mr14298487wjd.111.1415356197363; 
	Fri, 07 Nov 2014 02:29:57 -0800 (PST)
Received: from [192.168.42.189] (92.40.248.106.threembb.co.uk. [92.40.248.106])
	by mx.google.com with ESMTPSA id m6sm1480201wiy.16.2014.11.07.02.29.54
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 02:29:56 -0800 (PST)
Message-ID: <545C9F20.5000702@linaro.org>
Date: Fri, 07 Nov 2014 10:29:52 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAAiw7JnUfU1SQjnROrdNV0u2Z8_Fg68zkqJAh66Rwy9DB4LZsw@mail.gmail.com>	<alpine.DEB.2.02.1410071513060.17038@kaball.uk.xensource.com>	<CAAiw7JkEvJsiqos1FY1TFKhBhQ=_Mmq297ZWH2xXDbpbe5MYcQ@mail.gmail.com>	<20141008124657.GB13391@laptop.dumpdata.com>	<CAAiw7JmG-+vxRDvnHNZ90JkdayFLy+ELkuA8u6S7BqCEB3dm5w@mail.gmail.com>	<1412775916.24894.15.camel@citrix.com>	<CAAiw7JmEZaMgk32g+0zgp=o-uD3dXUvQaCFwUv6HkUW+Pict5Q@mail.gmail.com>	<20141008145107.GC18573@laptop.dumpdata.com>	<CAAiw7Jmq0zRHfv0VtyyFwJKzr5UsCd1wucSFDfY1d4xmisZ-zQ@mail.gmail.com>	<alpine.DEB.2.02.1410201554070.17038@kaball.uk.xensource.com>	<CAAiw7JkFmZVK80QO7ux2Sq0=6m5=-JZfGQf6FEDxgQ=ULpPVpA@mail.gmail.com>	<alpine.DEB.2.02.1411061546420.22875@kaball.uk.xensource.com>	<CAAiw7J=WHgkLz8ftL5cCG4+fdwPP=CKGdh0Jowv_Dan_h3bnmw@mail.gmail.com>	<545B9B96.6080102@linaro.org>	<alpine.DEB.2.02.1411061607150.22875@kaball.uk.xensource.com>
	<CAAiw7JmvYpzYsQzg40+bmLWu+6SPJk4J09fuiYStR3LF62bLZQ@mail.gmail.com>
In-Reply-To: <CAAiw7JmvYpzYsQzg40+bmLWu+6SPJk4J09fuiYStR3LF62bLZQ@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Prasun Kapoor <prasun.Kapoor@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, Ryan Wilson <hap9@epoch.ncsc.mil>,
	xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Manish,

On 06/11/2014 16:20, manish jaggi wrote:
> On 6 November 2014 21:37, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Thu, 6 Nov 2014, Julien Grall wrote:
>>> Hi Manish,
>>>
>>> On 06/11/2014 15:55, manish jaggi wrote:
>>>> On 6 November 2014 21:18, Stefano Stabellini
>>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>>> On Thu, 6 Nov 2014, manish jaggi wrote:
>>>>>> On 20 October 2014 20:24, Stefano Stabellini
>>>>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>>>>> On Mon, 20 Oct 2014, manish jaggi wrote:
>>>>>>>> On 8 October 2014 20:21, Konrad Rzeszutek Wilk
>>>>>>>> <konrad.wilk@oracle.com> wrote:
>>>>>>>>> On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
>>>>>>>>>> On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@citrix.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote:
>>>>>>>>>>>> Thanks for replying. As detailed in this thread, I need to
>>>>>>>>>>>> create a
>>>>>>>>>>>> hypercall that would send the following information to Xen
>>>>>>>>>>>> at the time
>>>>>>>>>>>> of PCI attach
>>>>>>>>>>>> { sbdf , domU sbdf, domainId }.
>>>>>>>>>>>> I am not able to find a way to get the domU sbdf from dom0
>>>>>>>>>>>> at the time
>>>>>>>>>>>> of pci-attach.
>>>>>>>>>>>
>>>>>>>>>>> I think it would need to be done by the pciback driver in the
>>>>>>>>>>> dom0
>>>>>>>>>>> kernel, which AFAIK is the thing which consistently knows both
>>>>>>>>>>> physical
>>>>>>>>>>> and virtual sbdf for a given assigned device.
>>>>>>>>>>>
>>>>>>>>>>> Ian.
>>>>>>>>>>>
>>>>>>>>>> Correct, can you point out which data structure holds the domU
>>>>>>>>>> sbdf
>>>>>>>>>> corresponding to the actual sbdf in pciback.
>>>>>>>>>
>>>>>>>>> See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root'
>>>>>>>>> is that what you are referring to?
>>>>>>>>
>>>>>>>> Xen docs also mention about xen-pciback.passthrough=1. If I set this
>>>>>>>> in dom0 i see that the device is enumerated as the same sbdf in
>>>>>>>> domU,
>>>>>>>> but
>>>>>>>> a) it is not shown in lspci
>>>>>>>> b) no front-back communication is done for reading devices
>>>>>>>> configuration space
>>>>>>>> .
>>>>>>>> Is option useful / fully implemented for ARM ?
>>>>>>>
>>>>>>> I don't think this option is very useful. I wouldn't worry about it
>>>>>>> for
>>>>>>> now.
>>>>>>
>>>>>> Stefano / Ian / Konard / Julien,
>>>>>>
>>>>>> Attached is a first raw code FYI RFC Patches of PCI passthrough support
>>>>>> on ARM.
>>>>>> - Linux Patch (3.18)
>>>>>> - Xen Patch  (4.5 staging)
>>>>>> ---(Smmu changes not included, thats a separate patch altogether)
>>>>>> This patches show the logic, at places need of improvements in code
>>>>>> organization/quality. I wanted to share to get initial comments.
>>>>>> This is working with SRIOV as well.
>>>>>>
>>>>>> Please have a look and let me know your positive comments
>>>>>
>>>>> Please send as individual inline patches. not attachments.
>>>>> Please also add a proper description to each patch and an entry 0/N email
>>>>> with the high level explanation of your work.
>>>>>
>>>>> See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
>>>> Stefano I just wanted to share the patches as reference to our
>>>> discussion on the approach. Please recall I had shared in this mail a
>>>> design flow. These are just an extension to it. I wanted to move this
>>>> discussion to a conclusion
>>>> There are not patches which I am submitting to xen git.
>>>> If you are ok with the approach I will formally send the patches post
>>>> 4.5 release.
>>>
>>> In this case you can send the patch series tagged "[RFC]" in the subject.
>>
>> That's right. It is difficult to give even just an early feedback
>> without the patch descriptions.
>>
> I assumed that the context is preserved in this mail thread. I shared
> the flow in the first few mails and am sharing the code after a lot of
> discussion in this thread.

There is about 30 mails in this discussion. It's better if you give a 
summary, it will avoid us to read again all the mails to find the 
conclusion.

> Anyhow I will share the code as RFC in some time.

Thanks,

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 10:38:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:38:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmgwE-0006a2-TC; Fri, 07 Nov 2014 10:38:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ug93tad@gmail.com>) id 1XmgwD-0006Zx-IL
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:38:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	23/69-09842-031AC545; Fri, 07 Nov 2014 10:38:40 +0000
X-Env-Sender: ug93tad@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415356719!11831467!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11242 invoked from network); 7 Nov 2014 10:38:40 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:38:40 -0000
Received: by mail-wi0-f173.google.com with SMTP id n3so4123925wiv.0
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=c+DoRW3wvAbm6zo822g+KbQWi3ZnY47Tn5q2yTf7haw=;
	b=YZG+EvMlXML9ZEIWddO2HxFrfnfot4EOABXrTpJd7Q8M8tBvTQUMThKO+IGrXisxlJ
	y5tUNqtyWVm97VyOwnrA19VSg/AkWUP5QzmtDnPhbPfwfTUmjDx3vJA8sb1EM4RBxLjd
	ouyMYYRv6TX9eSerD1StIt8FkG2jpJPi6lctlduYBdO1nTaO6/aQicXHOS+vn3wSQ/dZ
	cMk/cEy07ybGFe0Y1xj8aKuAu2/p+Qp3dIzyOuBthmPkkvwOq3BkgoqBcr0m4QFKeceR
	qfy/VUvmxj7KB915sUVSRrUjdNyHT6TD6nwdnZ4FlOV5Bqp1EhKB9I+25JXKvhirfAX5
	JpZQ==
MIME-Version: 1.0
X-Received: by 10.194.222.98 with SMTP id ql2mr15162867wjc.10.1415356719778;
	Fri, 07 Nov 2014 02:38:39 -0800 (PST)
Received: by 10.180.80.6 with HTTP; Fri, 7 Nov 2014 02:38:39 -0800 (PST)
Date: Fri, 7 Nov 2014 18:38:39 +0800
Message-ID: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
From: Anh Dinh <ug93tad@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] how to deal with copy_to_user returning non 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: multipart/mixed; boundary="===============4327351986682330799=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4327351986682330799==
Content-Type: multipart/alternative; boundary=001a11c27ac28355dc0507426a22

--001a11c27ac28355dc0507426a22
Content-Type: text/plain; charset=UTF-8

I'm testing out a hypercall that takes in large data (many MB) from the
user space and simply copy the data back.

For copying in, I call xmalloc_array() for about 4MB at a time and call
copy_from_user() successfully for the entire input.

The problem is with copy_to_user() which returns non-zero values. I tried
to vary the size of the data being copy, but still unable to copy the whole
data back.

What are the cause of copy_to_user() failure? I checked the source I got
quite lost at the code.

How could I make sure all data is copy back? Surely it is not a memory
limitation problem, because I copy_from_user() succeeds for over 100MB.


******
long do_test_copy(long n, unsigned char *in, unsigned char *out){
        unsigned char **tmp;
        long ret;
        int m = n/(MAX_ALLOC);
        tmp = xmalloc_array(unsigned char*,m);

        for (int i=0; i<m; i++){
                tmp[i] = xmalloc_array(unsigned char, MAX_ALLOC);
                copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_ALLOC);
        }

        for (int i=0; i<m; i++){
                if (tmp[i]){
                        ret =
copy_to_user(out+i*MAX_ALLOC,tmp[i],MAX_ALLOC);
                        xfree(tmp[i]);
                }
        }
        xfree(tmp);
        return 0;
}
****

--001a11c27ac28355dc0507426a22
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;m testing out a hypercall that takes in large data (=
many MB) from the user space and simply copy the data back.=C2=A0<div><br><=
/div><div>For copying in, I call xmalloc_array() for about 4MB at a time an=
d call copy_from_user() successfully for the entire input.=C2=A0</div><div>=
<br></div><div>The problem is with copy_to_user() which returns non-zero va=
lues. I tried to vary the size of the data being copy, but still unable to =
copy the whole data back.=C2=A0</div><div><br></div><div>What are the cause=
 of copy_to_user() failure? I checked the source I got quite lost at the co=
de.=C2=A0</div><div><br></div><div>How could I make sure all data is copy b=
ack? Surely it is not a memory limitation problem, because I copy_from_user=
() succeeds for over 100MB.=C2=A0</div><div><br></div><div><br></div><div>*=
*****</div><div><div>long do_test_copy(long n, unsigned char *in, unsigned =
char *out){</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 unsigned char **tmp;=C2=
=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 long ret;</div><div>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 int m =3D n/(MAX_ALLOC);=C2=A0</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 tmp =3D xmalloc_array(unsigned char*,m);=C2=A0</div><div><br></d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (int i=3D0; i&lt;m; i++){</div><div=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tmp[i] =3D xmalloc=
_array(unsigned char, MAX_ALLOC);=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_AL=
LOC);=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (int i=3D0; =
i&lt;m; i++){</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 if (tmp[i]){</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D copy_to_user(out+i*MAX_ALLOC=
,tmp[i],MAX_ALLOC); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 xfree(tmp[i]);=C2=A0</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 }</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xfree(tmp);</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 return 0; =C2=A0 =C2=A0 =C2=A0=C2=A0</div><div>}</div=
></div><div>****</div><div><br></div></div>

--001a11c27ac28355dc0507426a22--


--===============4327351986682330799==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4327351986682330799==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 10:38:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:38:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmgwE-0006a2-TC; Fri, 07 Nov 2014 10:38:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ug93tad@gmail.com>) id 1XmgwD-0006Zx-IL
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:38:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	23/69-09842-031AC545; Fri, 07 Nov 2014 10:38:40 +0000
X-Env-Sender: ug93tad@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415356719!11831467!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11242 invoked from network); 7 Nov 2014 10:38:40 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:38:40 -0000
Received: by mail-wi0-f173.google.com with SMTP id n3so4123925wiv.0
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=c+DoRW3wvAbm6zo822g+KbQWi3ZnY47Tn5q2yTf7haw=;
	b=YZG+EvMlXML9ZEIWddO2HxFrfnfot4EOABXrTpJd7Q8M8tBvTQUMThKO+IGrXisxlJ
	y5tUNqtyWVm97VyOwnrA19VSg/AkWUP5QzmtDnPhbPfwfTUmjDx3vJA8sb1EM4RBxLjd
	ouyMYYRv6TX9eSerD1StIt8FkG2jpJPi6lctlduYBdO1nTaO6/aQicXHOS+vn3wSQ/dZ
	cMk/cEy07ybGFe0Y1xj8aKuAu2/p+Qp3dIzyOuBthmPkkvwOq3BkgoqBcr0m4QFKeceR
	qfy/VUvmxj7KB915sUVSRrUjdNyHT6TD6nwdnZ4FlOV5Bqp1EhKB9I+25JXKvhirfAX5
	JpZQ==
MIME-Version: 1.0
X-Received: by 10.194.222.98 with SMTP id ql2mr15162867wjc.10.1415356719778;
	Fri, 07 Nov 2014 02:38:39 -0800 (PST)
Received: by 10.180.80.6 with HTTP; Fri, 7 Nov 2014 02:38:39 -0800 (PST)
Date: Fri, 7 Nov 2014 18:38:39 +0800
Message-ID: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
From: Anh Dinh <ug93tad@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] how to deal with copy_to_user returning non 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: multipart/mixed; boundary="===============4327351986682330799=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4327351986682330799==
Content-Type: multipart/alternative; boundary=001a11c27ac28355dc0507426a22

--001a11c27ac28355dc0507426a22
Content-Type: text/plain; charset=UTF-8

I'm testing out a hypercall that takes in large data (many MB) from the
user space and simply copy the data back.

For copying in, I call xmalloc_array() for about 4MB at a time and call
copy_from_user() successfully for the entire input.

The problem is with copy_to_user() which returns non-zero values. I tried
to vary the size of the data being copy, but still unable to copy the whole
data back.

What are the cause of copy_to_user() failure? I checked the source I got
quite lost at the code.

How could I make sure all data is copy back? Surely it is not a memory
limitation problem, because I copy_from_user() succeeds for over 100MB.


******
long do_test_copy(long n, unsigned char *in, unsigned char *out){
        unsigned char **tmp;
        long ret;
        int m = n/(MAX_ALLOC);
        tmp = xmalloc_array(unsigned char*,m);

        for (int i=0; i<m; i++){
                tmp[i] = xmalloc_array(unsigned char, MAX_ALLOC);
                copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_ALLOC);
        }

        for (int i=0; i<m; i++){
                if (tmp[i]){
                        ret =
copy_to_user(out+i*MAX_ALLOC,tmp[i],MAX_ALLOC);
                        xfree(tmp[i]);
                }
        }
        xfree(tmp);
        return 0;
}
****

--001a11c27ac28355dc0507426a22
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;m testing out a hypercall that takes in large data (=
many MB) from the user space and simply copy the data back.=C2=A0<div><br><=
/div><div>For copying in, I call xmalloc_array() for about 4MB at a time an=
d call copy_from_user() successfully for the entire input.=C2=A0</div><div>=
<br></div><div>The problem is with copy_to_user() which returns non-zero va=
lues. I tried to vary the size of the data being copy, but still unable to =
copy the whole data back.=C2=A0</div><div><br></div><div>What are the cause=
 of copy_to_user() failure? I checked the source I got quite lost at the co=
de.=C2=A0</div><div><br></div><div>How could I make sure all data is copy b=
ack? Surely it is not a memory limitation problem, because I copy_from_user=
() succeeds for over 100MB.=C2=A0</div><div><br></div><div><br></div><div>*=
*****</div><div><div>long do_test_copy(long n, unsigned char *in, unsigned =
char *out){</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 unsigned char **tmp;=C2=
=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 long ret;</div><div>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 int m =3D n/(MAX_ALLOC);=C2=A0</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 tmp =3D xmalloc_array(unsigned char*,m);=C2=A0</div><div><br></d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (int i=3D0; i&lt;m; i++){</div><div=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tmp[i] =3D xmalloc=
_array(unsigned char, MAX_ALLOC);=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_AL=
LOC);=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (int i=3D0; =
i&lt;m; i++){</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 if (tmp[i]){</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D copy_to_user(out+i*MAX_ALLOC=
,tmp[i],MAX_ALLOC); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 xfree(tmp[i]);=C2=A0</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 }</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xfree(tmp);</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 return 0; =C2=A0 =C2=A0 =C2=A0=C2=A0</div><div>}</div=
></div><div>****</div><div><br></div></div>

--001a11c27ac28355dc0507426a22--


--===============4327351986682330799==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4327351986682330799==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 10:40:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmgyJ-0006g6-Dw; Fri, 07 Nov 2014 10:40:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1XmgyI-0006g1-3A
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:40:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AF/1E-09842-1B1AC545; Fri, 07 Nov 2014 10:40:49 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415356848!12137608!1
X-Originating-IP: [74.125.82.52]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32352 invoked from network); 7 Nov 2014 10:40:48 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:40:48 -0000
Received: by mail-wg0-f52.google.com with SMTP id b13so3326312wgh.25
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:40:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=xlZRcFWhSa8UOM5Qon2BEdQQ12FpxWGCS2qKAbk0+5M=;
	b=OfBNmssJs0JYsYW/T2SwzHI/ouSFLqIWQjZZf/D3QZod1ayUlsTrRFhtkekjGz9Uhx
	bIHR9AZpCObDmrTXOVWEEOFvVKbRTxh1OPXM7mnDVCEsCl1ntpNUZFnBVI1KYwoiHK3t
	rxBbc4/NvKsqtmLvOgXbxbIqCaz8sEgvH5s5356qf+SfVfeVFrQviYMasUcr0J1Z8jw4
	1ShkTmrTGS9zH8bP59MRYAtO6FqN/oA8AqNUwWVUet5ZzzSPKbhvT9sEz1mZlKmsTTcF
	owuAfZJ9g/A+ywSV/tvzODOVEcLidCkEL1KAoBgqUd+t7oXr+bb4NfUr+s5xnB/i36ii
	T+pQ==
MIME-Version: 1.0
X-Received: by 10.194.219.138 with SMTP id po10mr14660467wjc.62.1415356846493; 
	Fri, 07 Nov 2014 02:40:46 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Fri, 7 Nov 2014 02:40:46 -0800 (PST)
In-Reply-To: <545BEE4F.3080305@tycho.nsa.gov>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>
	<545BEE4F.3080305@tycho.nsa.gov>
Date: Fri, 7 Nov 2014 12:40:46 +0200
Message-ID: <CAAULxKJwTAdVKGrb5p=j701dAO=PWLYsdX6LpYRbmrAUuAM86A@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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: multipart/mixed; boundary="===============7174357697983781878=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7174357697983781878==
Content-Type: multipart/alternative; boundary=001a11c27f7810d6a8050742728e

--001a11c27f7810d6a8050742728e
Content-Type: text/plain; charset=UTF-8

My system does not support DRTM so I can not test this. I am interested in
contributing to vtpm and making this to work without DRTM, can you give me
more details about PCRs that need to be implemented using an alternate
manner? When someone wants to use other locality than 0 it will run all
commands with PCRs disabled? Since the vtpmmgr is tying domU to hardware
TPM, deactivating PCRs will result that all commands issued by domU will
not use PCRs anymore, right?
Where should the new layer of PCR values stored? NVRAM ?


On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
wrote:

> On 11/05/2014 05:00 AM, Ian Campbell wrote:
>
>> CCing Daniel.
>>
>> On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
>>
>>>
>>> I am wondering if this is known issue that when I set locality!=0 to
>>> vtpmmgr it does not start. It is a bit strange that every call to
>>> tpm_tis_status returns 255 and device-id is also FFFF:
>>> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
>>> TPM interface capabilities (0xffffffff):
>>>
>>> I am configuring vtpmmgr using:
>>>
>>> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
>>> memory=8
>>> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
>>> name="vtpmmgr"
>>> iomem=["fed40,5"]
>>> extra="tpmlocality=2"
>>>
>>>
>>> I also tried using :
>>> iomem=["fed40,1"]
>>> extra="tpmlocality=0"//works well
>>>
>>> or
>>> iomem=["fed42,1"]
>>> extra="tpmlocality=2"
>>> It seems that everything that is not mapped at fed40-fed41 is
>>> FFFFFFFF.
>>>
>>> I have an Atmel TPM chipset.
>>>
>>> Could it be a chipset problem to not handle well different localities?
>>>
>>> When I use locality=0, the device driver info is correct and
>>> everything works fine:
>>> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
>>> TPM interface capabilities (0xfd)
>>>
>>
> This may be an issue with locality 2 being unavailable unless a DRTM
> launch (tboot) is performed.  Returning all-ones is the normal response
> of the x86 chipset when unmapped MMIO regions are accessed; disabled
> localities of the TPM may act like this.
>
> Does your system support the DRTM launch?  If so, can you test it to see
> if this is the issue?
>
> In this case, to better support people who want to use the vTPM Manager
> without a DRTM launch, the features of the vTPM Manager that use the TPM
> 1.2 PCRs may need to be disabled or implemented in an alternate manner
> such as embedding the data in the quote instead of in PCRs.  The current
> design was created with the assumption that systems using it would be
> performing a DRTM launch in order to fully secure the boot process.
>
>  In linux kernel this information is obtained using locality 0 and
>>> after that other commands execute using specified locality.
>>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-
>>> stable.git/tree/drivers/char/tpm/tpm_tis.c#n558
>>>
>>
> Have you tested that other localities work for your TPM under Linux?




>
>>> Thanks,
>>>
>>> Emil
>>>
>>>
> --
> Daniel De Graaf
> National Security Agency
>

--001a11c27f7810d6a8050742728e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My system does not support DRTM so I can not test this. I =
am interested in contributing to vtpm and making this to work without DRTM,=
 can you give me more details about PCRs that need to be implemented using =
an alternate manner? When someone wants to use other locality than 0 it wil=
l run all commands with PCRs disabled? Since the vtpmmgr is tying domU to h=
ardware TPM, deactivating PCRs will result that all commands issued by domU=
 will not use PCRs anymore, right?<div>Where should the new layer of PCR va=
lues stored? NVRAM ?<br><div><br><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dgdegra@tycho.nsa.gov" target=3D"_blank">dgd=
egra@tycho.nsa.gov</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>On 1=
1/05/2014 05:00 AM, Ian Campbell wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
CCing Daniel.<br>
<br>
On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<br>
I am wondering if this is known issue that when I set locality!=3D0 to<br>
vtpmmgr it does not start. It is a bit strange that every call to<br>
tpm_tis_status returns 255 and device-id is also FFFF:<br>
1.2 TPM (device-id=3D0xFFFF vendor-id =3D FFFF rev-id =3D FF).<br>
TPM interface capabilities (0xffffffff):<br>
<br>
I am configuring vtpmmgr using:<br>
<br>
kernel=3D&quot;/usr/local/lib/xen/<u></u>boot/vtpmmgr-stubdom.gz&quot;<br>
memory=3D8<br>
disk=3D[&quot;file:/var/vtpmmgr-<u></u>stubdom.img,hda,w&quot;]<br>
name=3D&quot;vtpmmgr&quot;<br>
iomem=3D[&quot;fed40,5&quot;]<br>
extra=3D&quot;tpmlocality=3D2&quot;<br>
<br>
<br>
I also tried using :<br>
iomem=3D[&quot;fed40,1&quot;]<br>
extra=3D&quot;tpmlocality=3D0&quot;//works well<br>
<br>
or<br>
iomem=3D[&quot;fed42,1&quot;]<br>
extra=3D&quot;tpmlocality=3D2&quot;<br>
It seems that everything that is not mapped at fed40-fed41 is<br>
FFFFFFFF.<br>
<br>
I have an Atmel TPM chipset.<br>
<br>
Could it be a chipset problem to not handle well different localities?<br>
<br>
When I use locality=3D0, the device driver info is correct and<br>
everything works fine:<br>
1.2 TPM (device-id=3D0x3204 vendor-id =3D 1114 rev-id =3D 40)<br>
TPM interface capabilities (0xfd)<br>
</blockquote></blockquote>
<br></div></div>
This may be an issue with locality 2 being unavailable unless a DRTM<br>
launch (tboot) is performed.=C2=A0 Returning all-ones is the normal respons=
e<br>
of the x86 chipset when unmapped MMIO regions are accessed; disabled<br>
localities of the TPM may act like this.<br>
<br>
Does your system support the DRTM launch?=C2=A0 If so, can you test it to s=
ee<br>
if this is the issue?<br>
<br>
In this case, to better support people who want to use the vTPM Manager<br>
without a DRTM launch, the features of the vTPM Manager that use the TPM<br=
>
1.2 PCRs may need to be disabled or implemented in an alternate manner<br>
such as embedding the data in the quote instead of in PCRs.=C2=A0 The curre=
nt<br>
design was created with the assumption that systems using it would be<br>
performing a DRTM launch in order to fully secure the boot process.<span><b=
r>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
In linux kernel this information is obtained using locality 0 and<br>
after that other commands execute using specified locality.<br>
<a href=3D"https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable=
.git/tree/drivers/char/tpm/tpm_tis.c#n558" target=3D"_blank">https://git.ke=
rnel.org/cgit/<u></u>linux/kernel/git/stable/linux-<u></u>stable.git/tree/d=
rivers/char/<u></u>tpm/tpm_tis.c#n558</a><br>
</blockquote></blockquote>
<br></span>
Have you tested that other localities work for your TPM under Linux?=C2=A0<=
/blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">=C2=A0</blockquote><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
Emil<br>
<br><span><font color=3D"#888888">
</font></span></blockquote></blockquote><span><font color=3D"#888888">
<br>
-- <br>
Daniel De Graaf<br>
National Security Agency<br>
</font></span></blockquote></div><br></div></div></div></div>

--001a11c27f7810d6a8050742728e--


--===============7174357697983781878==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7174357697983781878==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 10:40:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmgyJ-0006g6-Dw; Fri, 07 Nov 2014 10:40:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1XmgyI-0006g1-3A
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:40:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AF/1E-09842-1B1AC545; Fri, 07 Nov 2014 10:40:49 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415356848!12137608!1
X-Originating-IP: [74.125.82.52]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32352 invoked from network); 7 Nov 2014 10:40:48 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:40:48 -0000
Received: by mail-wg0-f52.google.com with SMTP id b13so3326312wgh.25
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:40:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=xlZRcFWhSa8UOM5Qon2BEdQQ12FpxWGCS2qKAbk0+5M=;
	b=OfBNmssJs0JYsYW/T2SwzHI/ouSFLqIWQjZZf/D3QZod1ayUlsTrRFhtkekjGz9Uhx
	bIHR9AZpCObDmrTXOVWEEOFvVKbRTxh1OPXM7mnDVCEsCl1ntpNUZFnBVI1KYwoiHK3t
	rxBbc4/NvKsqtmLvOgXbxbIqCaz8sEgvH5s5356qf+SfVfeVFrQviYMasUcr0J1Z8jw4
	1ShkTmrTGS9zH8bP59MRYAtO6FqN/oA8AqNUwWVUet5ZzzSPKbhvT9sEz1mZlKmsTTcF
	owuAfZJ9g/A+ywSV/tvzODOVEcLidCkEL1KAoBgqUd+t7oXr+bb4NfUr+s5xnB/i36ii
	T+pQ==
MIME-Version: 1.0
X-Received: by 10.194.219.138 with SMTP id po10mr14660467wjc.62.1415356846493; 
	Fri, 07 Nov 2014 02:40:46 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Fri, 7 Nov 2014 02:40:46 -0800 (PST)
In-Reply-To: <545BEE4F.3080305@tycho.nsa.gov>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>
	<545BEE4F.3080305@tycho.nsa.gov>
Date: Fri, 7 Nov 2014 12:40:46 +0200
Message-ID: <CAAULxKJwTAdVKGrb5p=j701dAO=PWLYsdX6LpYRbmrAUuAM86A@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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: multipart/mixed; boundary="===============7174357697983781878=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7174357697983781878==
Content-Type: multipart/alternative; boundary=001a11c27f7810d6a8050742728e

--001a11c27f7810d6a8050742728e
Content-Type: text/plain; charset=UTF-8

My system does not support DRTM so I can not test this. I am interested in
contributing to vtpm and making this to work without DRTM, can you give me
more details about PCRs that need to be implemented using an alternate
manner? When someone wants to use other locality than 0 it will run all
commands with PCRs disabled? Since the vtpmmgr is tying domU to hardware
TPM, deactivating PCRs will result that all commands issued by domU will
not use PCRs anymore, right?
Where should the new layer of PCR values stored? NVRAM ?


On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
wrote:

> On 11/05/2014 05:00 AM, Ian Campbell wrote:
>
>> CCing Daniel.
>>
>> On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
>>
>>>
>>> I am wondering if this is known issue that when I set locality!=0 to
>>> vtpmmgr it does not start. It is a bit strange that every call to
>>> tpm_tis_status returns 255 and device-id is also FFFF:
>>> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
>>> TPM interface capabilities (0xffffffff):
>>>
>>> I am configuring vtpmmgr using:
>>>
>>> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
>>> memory=8
>>> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
>>> name="vtpmmgr"
>>> iomem=["fed40,5"]
>>> extra="tpmlocality=2"
>>>
>>>
>>> I also tried using :
>>> iomem=["fed40,1"]
>>> extra="tpmlocality=0"//works well
>>>
>>> or
>>> iomem=["fed42,1"]
>>> extra="tpmlocality=2"
>>> It seems that everything that is not mapped at fed40-fed41 is
>>> FFFFFFFF.
>>>
>>> I have an Atmel TPM chipset.
>>>
>>> Could it be a chipset problem to not handle well different localities?
>>>
>>> When I use locality=0, the device driver info is correct and
>>> everything works fine:
>>> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
>>> TPM interface capabilities (0xfd)
>>>
>>
> This may be an issue with locality 2 being unavailable unless a DRTM
> launch (tboot) is performed.  Returning all-ones is the normal response
> of the x86 chipset when unmapped MMIO regions are accessed; disabled
> localities of the TPM may act like this.
>
> Does your system support the DRTM launch?  If so, can you test it to see
> if this is the issue?
>
> In this case, to better support people who want to use the vTPM Manager
> without a DRTM launch, the features of the vTPM Manager that use the TPM
> 1.2 PCRs may need to be disabled or implemented in an alternate manner
> such as embedding the data in the quote instead of in PCRs.  The current
> design was created with the assumption that systems using it would be
> performing a DRTM launch in order to fully secure the boot process.
>
>  In linux kernel this information is obtained using locality 0 and
>>> after that other commands execute using specified locality.
>>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-
>>> stable.git/tree/drivers/char/tpm/tpm_tis.c#n558
>>>
>>
> Have you tested that other localities work for your TPM under Linux?




>
>>> Thanks,
>>>
>>> Emil
>>>
>>>
> --
> Daniel De Graaf
> National Security Agency
>

--001a11c27f7810d6a8050742728e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My system does not support DRTM so I can not test this. I =
am interested in contributing to vtpm and making this to work without DRTM,=
 can you give me more details about PCRs that need to be implemented using =
an alternate manner? When someone wants to use other locality than 0 it wil=
l run all commands with PCRs disabled? Since the vtpmmgr is tying domU to h=
ardware TPM, deactivating PCRs will result that all commands issued by domU=
 will not use PCRs anymore, right?<div>Where should the new layer of PCR va=
lues stored? NVRAM ?<br><div><br><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dgdegra@tycho.nsa.gov" target=3D"_blank">dgd=
egra@tycho.nsa.gov</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>On 1=
1/05/2014 05:00 AM, Ian Campbell wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
CCing Daniel.<br>
<br>
On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<br>
I am wondering if this is known issue that when I set locality!=3D0 to<br>
vtpmmgr it does not start. It is a bit strange that every call to<br>
tpm_tis_status returns 255 and device-id is also FFFF:<br>
1.2 TPM (device-id=3D0xFFFF vendor-id =3D FFFF rev-id =3D FF).<br>
TPM interface capabilities (0xffffffff):<br>
<br>
I am configuring vtpmmgr using:<br>
<br>
kernel=3D&quot;/usr/local/lib/xen/<u></u>boot/vtpmmgr-stubdom.gz&quot;<br>
memory=3D8<br>
disk=3D[&quot;file:/var/vtpmmgr-<u></u>stubdom.img,hda,w&quot;]<br>
name=3D&quot;vtpmmgr&quot;<br>
iomem=3D[&quot;fed40,5&quot;]<br>
extra=3D&quot;tpmlocality=3D2&quot;<br>
<br>
<br>
I also tried using :<br>
iomem=3D[&quot;fed40,1&quot;]<br>
extra=3D&quot;tpmlocality=3D0&quot;//works well<br>
<br>
or<br>
iomem=3D[&quot;fed42,1&quot;]<br>
extra=3D&quot;tpmlocality=3D2&quot;<br>
It seems that everything that is not mapped at fed40-fed41 is<br>
FFFFFFFF.<br>
<br>
I have an Atmel TPM chipset.<br>
<br>
Could it be a chipset problem to not handle well different localities?<br>
<br>
When I use locality=3D0, the device driver info is correct and<br>
everything works fine:<br>
1.2 TPM (device-id=3D0x3204 vendor-id =3D 1114 rev-id =3D 40)<br>
TPM interface capabilities (0xfd)<br>
</blockquote></blockquote>
<br></div></div>
This may be an issue with locality 2 being unavailable unless a DRTM<br>
launch (tboot) is performed.=C2=A0 Returning all-ones is the normal respons=
e<br>
of the x86 chipset when unmapped MMIO regions are accessed; disabled<br>
localities of the TPM may act like this.<br>
<br>
Does your system support the DRTM launch?=C2=A0 If so, can you test it to s=
ee<br>
if this is the issue?<br>
<br>
In this case, to better support people who want to use the vTPM Manager<br>
without a DRTM launch, the features of the vTPM Manager that use the TPM<br=
>
1.2 PCRs may need to be disabled or implemented in an alternate manner<br>
such as embedding the data in the quote instead of in PCRs.=C2=A0 The curre=
nt<br>
design was created with the assumption that systems using it would be<br>
performing a DRTM launch in order to fully secure the boot process.<span><b=
r>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
In linux kernel this information is obtained using locality 0 and<br>
after that other commands execute using specified locality.<br>
<a href=3D"https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable=
.git/tree/drivers/char/tpm/tpm_tis.c#n558" target=3D"_blank">https://git.ke=
rnel.org/cgit/<u></u>linux/kernel/git/stable/linux-<u></u>stable.git/tree/d=
rivers/char/<u></u>tpm/tpm_tis.c#n558</a><br>
</blockquote></blockquote>
<br></span>
Have you tested that other localities work for your TPM under Linux?=C2=A0<=
/blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">=C2=A0</blockquote><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
Emil<br>
<br><span><font color=3D"#888888">
</font></span></blockquote></blockquote><span><font color=3D"#888888">
<br>
-- <br>
Daniel De Graaf<br>
National Security Agency<br>
</font></span></blockquote></div><br></div></div></div></div>

--001a11c27f7810d6a8050742728e--


--===============7174357697983781878==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7174357697983781878==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 10:42:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10: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 1Xmgzp-0006pM-Ti; Fri, 07 Nov 2014 10:42:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1Xmgzn-0006pC-Vp
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:42:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	20/31-09936-F02AC545; Fri, 07 Nov 2014 10:42:23 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415356941!12138133!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13629 invoked from network); 7 Nov 2014 10:42:22 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:42:22 -0000
Received: by mail-wg0-f44.google.com with SMTP id x12so3390020wgg.3
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:42:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=/UOs3hwDCMAdxhzxzlyx0I8iQlRQw7eWquKGQGARn6k=;
	b=r8sX2s/rKM9GvOeet4V7SAyVGQr47BCsXbrWb3oacjUzNVolnQCEilXlVMptTToU46
	QQACyVLL2v6TdTrpqNrLKMMlBICxwtXjAIWZlmBcYscj63fOYTzm4lQdr3q055cuxuWW
	dzeU7ZPjOclMgvQ06UYTg/QKqYcZqCJCcAYSvEcVXyz8EgPzfJRZnBm37CCBZGtrm6/N
	v5fa4C7QSrPyvlCOD5CKVHdxw6UjO0lRjvD2wmZmRXGdVNzrvgvFmcAVkVVeayi/p02x
	MKX12BFbBrlUrrEfQjukI/pKwnPdTwANazkKGzb5YsOkLqF+7nDt3Wr9wmnNqedQ9Wl1
	xWRA==
MIME-Version: 1.0
X-Received: by 10.194.219.138 with SMTP id po10mr14672864wjc.62.1415356939897; 
	Fri, 07 Nov 2014 02:42:19 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Fri, 7 Nov 2014 02:42:19 -0800 (PST)
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>
	<545BEE4F.3080305@tycho.nsa.gov>
	<945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
Date: Fri, 7 Nov 2014 12:42:19 +0200
Message-ID: <CAAULxKL+z_p_JcN5pBySiQzRBP5Jc-2w+oRcg81jgkTshAQDiw@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: "Xu, Quan" <quan.xu@intel.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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: multipart/mixed; boundary="===============5718198272142586792=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5718198272142586792==
Content-Type: multipart/alternative; boundary=001a11c27f78a219b20507427773

--001a11c27f78a219b20507427773
Content-Type: text/plain; charset=UTF-8

Xu, my system does not support DRTM launch so if you can test it next week
it would be great.
Thanks

On Fri, Nov 7, 2014 at 3:46 AM, Xu, Quan <quan.xu@intel.com> wrote:

>
>
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Daniel De Graaf
> > Sent: Friday, November 07, 2014 5:55 AM
> > To: Emil Condrea
> > Cc: Ian Campbell; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
> >
> > On 11/05/2014 05:00 AM, Ian Campbell wrote:
> > > CCing Daniel.
> > >
> > > On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
> > >>
> > >> I am wondering if this is known issue that when I set locality!=0 to
> > >> vtpmmgr it does not start. It is a bit strange that every call to
> > >> tpm_tis_status returns 255 and device-id is also FFFF:
> > >> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
> > >> TPM interface capabilities (0xffffffff):
> > >>
> > >> I am configuring vtpmmgr using:
> > >>
> > >> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
> > >> memory=8
> > >> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
> > >> name="vtpmmgr"
> > >> iomem=["fed40,5"]
> > >> extra="tpmlocality=2"
> > >>
> > >>
> > >> I also tried using :
> > >> iomem=["fed40,1"]
> > >> extra="tpmlocality=0"//works well
> > >>
> > >> or
> > >> iomem=["fed42,1"]
> > >> extra="tpmlocality=2"
> > >> It seems that everything that is not mapped at fed40-fed41 is
> > >> FFFFFFFF.
> > >>
> > >> I have an Atmel TPM chipset.
> > >>
> > >> Could it be a chipset problem to not handle well different localities?
> > >>
> > >> When I use locality=0, the device driver info is correct and
> > >> everything works fine:
> > >> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40) TPM interface
> > >> capabilities (0xfd)
> >
> > This may be an issue with locality 2 being unavailable unless a DRTM
> launch
> > (tboot) is performed.  Returning all-ones is the normal response of the
> x86
> > chipset when unmapped MMIO regions are accessed; disabled localities of
> > the TPM may act like this.
> >
> > Does your system support the DRTM launch?  If so, can you test it to see
> if
> > this is the issue?
>
>
> Emil,
> tboot supports Intel and OEM systems that are Intel TXT-capable.
> If your system does not support DRTM launch, I can test it in next week.
>
>
> >
> > In this case, to better support people who want to use the vTPM Manager
> > without a DRTM launch, the features of the vTPM Manager that use the TPM
> > 1.2 PCRs may need to be disabled or implemented in an alternate manner
> > such as embedding the data in the quote instead of in PCRs.  The current
> > design was created with the assumption that systems using it would be
> > performing a DRTM launch in order to fully secure the boot process.
> >
> > >> In linux kernel this information is obtained using locality 0 and
> > >> after that other commands execute using specified locality.
> > >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/
> > >> tree/drivers/char/tpm/tpm_tis.c#n558
> >
> > Have you tested that other localities work for your TPM under Linux?
> >
> > >>
> > >> Thanks,
> > >>
> > >> Emil
> > >>
> >
> > --
> > Daniel De Graaf
> > National Security Agency
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>

--001a11c27f78a219b20507427773
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Xu, my system does not support DRTM launch so if you can t=
est it next week it would be great.<div>Thanks</div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Fri, Nov 7, 2014 at 3:46 AM, Xu=
, Quan <span dir=3D"ltr">&lt;<a href=3D"mailto:quan.xu@intel.com" target=3D=
"_blank">quan.xu@intel.com</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"><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
&gt; -----Original Message-----<br>
&gt; From: <a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-bou=
nces@lists.xen.org</a><br>
&gt; [mailto:<a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-b=
ounces@lists.xen.org</a>] On Behalf Of Daniel De Graaf<br>
&gt; Sent: Friday, November 07, 2014 5:55 AM<br>
&gt; To: Emil Condrea<br>
&gt; Cc: Ian Campbell; <a href=3D"mailto:xen-devel@lists.xen.org">xen-devel=
@lists.xen.org</a><br>
&gt; Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=3D0<=
br>
&gt;<br>
&gt; On 11/05/2014 05:00 AM, Ian Campbell wrote:<br>
&gt; &gt; CCing Daniel.<br>
&gt; &gt;<br>
&gt; &gt; On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I am wondering if this is known issue that when I set localit=
y!=3D0 to<br>
&gt; &gt;&gt; vtpmmgr it does not start. It is a bit strange that every cal=
l to<br>
&gt; &gt;&gt; tpm_tis_status returns 255 and device-id is also FFFF:<br>
&gt; &gt;&gt; 1.2 TPM (device-id=3D0xFFFF vendor-id =3D FFFF rev-id =3D FF)=
.<br>
&gt; &gt;&gt; TPM interface capabilities (0xffffffff):<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I am configuring vtpmmgr using:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; kernel=3D&quot;/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz&quo=
t;<br>
&gt; &gt;&gt; memory=3D8<br>
&gt; &gt;&gt; disk=3D[&quot;file:/var/vtpmmgr-stubdom.img,hda,w&quot;]<br>
&gt; &gt;&gt; name=3D&quot;vtpmmgr&quot;<br>
&gt; &gt;&gt; iomem=3D[&quot;fed40,5&quot;]<br>
&gt; &gt;&gt; extra=3D&quot;tpmlocality=3D2&quot;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I also tried using :<br>
&gt; &gt;&gt; iomem=3D[&quot;fed40,1&quot;]<br>
&gt; &gt;&gt; extra=3D&quot;tpmlocality=3D0&quot;//works well<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; or<br>
&gt; &gt;&gt; iomem=3D[&quot;fed42,1&quot;]<br>
&gt; &gt;&gt; extra=3D&quot;tpmlocality=3D2&quot;<br>
&gt; &gt;&gt; It seems that everything that is not mapped at fed40-fed41 is=
<br>
&gt; &gt;&gt; FFFFFFFF.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I have an Atmel TPM chipset.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Could it be a chipset problem to not handle well different lo=
calities?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; When I use locality=3D0, the device driver info is correct an=
d<br>
&gt; &gt;&gt; everything works fine:<br>
&gt; &gt;&gt; 1.2 TPM (device-id=3D0x3204 vendor-id =3D 1114 rev-id =3D 40)=
 TPM interface<br>
&gt; &gt;&gt; capabilities (0xfd)<br>
&gt;<br>
&gt; This may be an issue with locality 2 being unavailable unless a DRTM l=
aunch<br>
&gt; (tboot) is performed.=C2=A0 Returning all-ones is the normal response =
of the x86<br>
&gt; chipset when unmapped MMIO regions are accessed; disabled localities o=
f<br>
&gt; the TPM may act like this.<br>
&gt;<br>
&gt; Does your system support the DRTM launch?=C2=A0 If so, can you test it=
 to see if<br>
&gt; this is the issue?<br>
<br>
<br>
</div></div>Emil,<br>
tboot supports Intel and OEM systems that are Intel TXT-capable.<br>
If your system does not support DRTM launch, I can test it in next week.<br=
>
<span class=3D"im HOEnZb"><br>
<br>
&gt;<br>
&gt; In this case, to better support people who want to use the vTPM Manage=
r<br>
&gt; without a DRTM launch, the features of the vTPM Manager that use the T=
PM<br>
&gt; 1.2 PCRs may need to be disabled or implemented in an alternate manner=
<br>
&gt; such as embedding the data in the quote instead of in PCRs.=C2=A0 The =
current<br>
&gt; design was created with the assumption that systems using it would be<=
br>
&gt; performing a DRTM launch in order to fully secure the boot process.<br=
>
&gt;<br>
&gt; &gt;&gt; In linux kernel this information is obtained using locality 0=
 and<br>
&gt; &gt;&gt; after that other commands execute using specified locality.<b=
r>
&gt; &gt;&gt; <a href=3D"https://git.kernel.org/cgit/linux/kernel/git/stabl=
e/linux-stable.git/" target=3D"_blank">https://git.kernel.org/cgit/linux/ke=
rnel/git/stable/linux-stable.git/</a><br>
&gt; &gt;&gt; tree/drivers/char/tpm/tpm_tis.c#n558<br>
&gt;<br>
&gt; Have you tested that other localities work for your TPM under Linux?<b=
r>
&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Thanks,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Emil<br>
&gt; &gt;&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Daniel De Graaf<br>
&gt; National Security Agency<br>
&gt;<br>
</span><div class=3D"HOEnZb"><div class=3D"h5">&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>
</div></div></blockquote></div><br></div>

--001a11c27f78a219b20507427773--


--===============5718198272142586792==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5718198272142586792==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 10:42:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10: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 1Xmgzp-0006pM-Ti; Fri, 07 Nov 2014 10:42:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1Xmgzn-0006pC-Vp
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:42:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	20/31-09936-F02AC545; Fri, 07 Nov 2014 10:42:23 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415356941!12138133!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13629 invoked from network); 7 Nov 2014 10:42:22 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:42:22 -0000
Received: by mail-wg0-f44.google.com with SMTP id x12so3390020wgg.3
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:42:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=/UOs3hwDCMAdxhzxzlyx0I8iQlRQw7eWquKGQGARn6k=;
	b=r8sX2s/rKM9GvOeet4V7SAyVGQr47BCsXbrWb3oacjUzNVolnQCEilXlVMptTToU46
	QQACyVLL2v6TdTrpqNrLKMMlBICxwtXjAIWZlmBcYscj63fOYTzm4lQdr3q055cuxuWW
	dzeU7ZPjOclMgvQ06UYTg/QKqYcZqCJCcAYSvEcVXyz8EgPzfJRZnBm37CCBZGtrm6/N
	v5fa4C7QSrPyvlCOD5CKVHdxw6UjO0lRjvD2wmZmRXGdVNzrvgvFmcAVkVVeayi/p02x
	MKX12BFbBrlUrrEfQjukI/pKwnPdTwANazkKGzb5YsOkLqF+7nDt3Wr9wmnNqedQ9Wl1
	xWRA==
MIME-Version: 1.0
X-Received: by 10.194.219.138 with SMTP id po10mr14672864wjc.62.1415356939897; 
	Fri, 07 Nov 2014 02:42:19 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Fri, 7 Nov 2014 02:42:19 -0800 (PST)
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>
	<545BEE4F.3080305@tycho.nsa.gov>
	<945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
Date: Fri, 7 Nov 2014 12:42:19 +0200
Message-ID: <CAAULxKL+z_p_JcN5pBySiQzRBP5Jc-2w+oRcg81jgkTshAQDiw@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: "Xu, Quan" <quan.xu@intel.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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: multipart/mixed; boundary="===============5718198272142586792=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5718198272142586792==
Content-Type: multipart/alternative; boundary=001a11c27f78a219b20507427773

--001a11c27f78a219b20507427773
Content-Type: text/plain; charset=UTF-8

Xu, my system does not support DRTM launch so if you can test it next week
it would be great.
Thanks

On Fri, Nov 7, 2014 at 3:46 AM, Xu, Quan <quan.xu@intel.com> wrote:

>
>
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Daniel De Graaf
> > Sent: Friday, November 07, 2014 5:55 AM
> > To: Emil Condrea
> > Cc: Ian Campbell; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
> >
> > On 11/05/2014 05:00 AM, Ian Campbell wrote:
> > > CCing Daniel.
> > >
> > > On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
> > >>
> > >> I am wondering if this is known issue that when I set locality!=0 to
> > >> vtpmmgr it does not start. It is a bit strange that every call to
> > >> tpm_tis_status returns 255 and device-id is also FFFF:
> > >> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
> > >> TPM interface capabilities (0xffffffff):
> > >>
> > >> I am configuring vtpmmgr using:
> > >>
> > >> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
> > >> memory=8
> > >> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
> > >> name="vtpmmgr"
> > >> iomem=["fed40,5"]
> > >> extra="tpmlocality=2"
> > >>
> > >>
> > >> I also tried using :
> > >> iomem=["fed40,1"]
> > >> extra="tpmlocality=0"//works well
> > >>
> > >> or
> > >> iomem=["fed42,1"]
> > >> extra="tpmlocality=2"
> > >> It seems that everything that is not mapped at fed40-fed41 is
> > >> FFFFFFFF.
> > >>
> > >> I have an Atmel TPM chipset.
> > >>
> > >> Could it be a chipset problem to not handle well different localities?
> > >>
> > >> When I use locality=0, the device driver info is correct and
> > >> everything works fine:
> > >> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40) TPM interface
> > >> capabilities (0xfd)
> >
> > This may be an issue with locality 2 being unavailable unless a DRTM
> launch
> > (tboot) is performed.  Returning all-ones is the normal response of the
> x86
> > chipset when unmapped MMIO regions are accessed; disabled localities of
> > the TPM may act like this.
> >
> > Does your system support the DRTM launch?  If so, can you test it to see
> if
> > this is the issue?
>
>
> Emil,
> tboot supports Intel and OEM systems that are Intel TXT-capable.
> If your system does not support DRTM launch, I can test it in next week.
>
>
> >
> > In this case, to better support people who want to use the vTPM Manager
> > without a DRTM launch, the features of the vTPM Manager that use the TPM
> > 1.2 PCRs may need to be disabled or implemented in an alternate manner
> > such as embedding the data in the quote instead of in PCRs.  The current
> > design was created with the assumption that systems using it would be
> > performing a DRTM launch in order to fully secure the boot process.
> >
> > >> In linux kernel this information is obtained using locality 0 and
> > >> after that other commands execute using specified locality.
> > >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/
> > >> tree/drivers/char/tpm/tpm_tis.c#n558
> >
> > Have you tested that other localities work for your TPM under Linux?
> >
> > >>
> > >> Thanks,
> > >>
> > >> Emil
> > >>
> >
> > --
> > Daniel De Graaf
> > National Security Agency
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>

--001a11c27f78a219b20507427773
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Xu, my system does not support DRTM launch so if you can t=
est it next week it would be great.<div>Thanks</div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Fri, Nov 7, 2014 at 3:46 AM, Xu=
, Quan <span dir=3D"ltr">&lt;<a href=3D"mailto:quan.xu@intel.com" target=3D=
"_blank">quan.xu@intel.com</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"><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
&gt; -----Original Message-----<br>
&gt; From: <a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-bou=
nces@lists.xen.org</a><br>
&gt; [mailto:<a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-b=
ounces@lists.xen.org</a>] On Behalf Of Daniel De Graaf<br>
&gt; Sent: Friday, November 07, 2014 5:55 AM<br>
&gt; To: Emil Condrea<br>
&gt; Cc: Ian Campbell; <a href=3D"mailto:xen-devel@lists.xen.org">xen-devel=
@lists.xen.org</a><br>
&gt; Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=3D0<=
br>
&gt;<br>
&gt; On 11/05/2014 05:00 AM, Ian Campbell wrote:<br>
&gt; &gt; CCing Daniel.<br>
&gt; &gt;<br>
&gt; &gt; On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I am wondering if this is known issue that when I set localit=
y!=3D0 to<br>
&gt; &gt;&gt; vtpmmgr it does not start. It is a bit strange that every cal=
l to<br>
&gt; &gt;&gt; tpm_tis_status returns 255 and device-id is also FFFF:<br>
&gt; &gt;&gt; 1.2 TPM (device-id=3D0xFFFF vendor-id =3D FFFF rev-id =3D FF)=
.<br>
&gt; &gt;&gt; TPM interface capabilities (0xffffffff):<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I am configuring vtpmmgr using:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; kernel=3D&quot;/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz&quo=
t;<br>
&gt; &gt;&gt; memory=3D8<br>
&gt; &gt;&gt; disk=3D[&quot;file:/var/vtpmmgr-stubdom.img,hda,w&quot;]<br>
&gt; &gt;&gt; name=3D&quot;vtpmmgr&quot;<br>
&gt; &gt;&gt; iomem=3D[&quot;fed40,5&quot;]<br>
&gt; &gt;&gt; extra=3D&quot;tpmlocality=3D2&quot;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I also tried using :<br>
&gt; &gt;&gt; iomem=3D[&quot;fed40,1&quot;]<br>
&gt; &gt;&gt; extra=3D&quot;tpmlocality=3D0&quot;//works well<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; or<br>
&gt; &gt;&gt; iomem=3D[&quot;fed42,1&quot;]<br>
&gt; &gt;&gt; extra=3D&quot;tpmlocality=3D2&quot;<br>
&gt; &gt;&gt; It seems that everything that is not mapped at fed40-fed41 is=
<br>
&gt; &gt;&gt; FFFFFFFF.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I have an Atmel TPM chipset.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Could it be a chipset problem to not handle well different lo=
calities?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; When I use locality=3D0, the device driver info is correct an=
d<br>
&gt; &gt;&gt; everything works fine:<br>
&gt; &gt;&gt; 1.2 TPM (device-id=3D0x3204 vendor-id =3D 1114 rev-id =3D 40)=
 TPM interface<br>
&gt; &gt;&gt; capabilities (0xfd)<br>
&gt;<br>
&gt; This may be an issue with locality 2 being unavailable unless a DRTM l=
aunch<br>
&gt; (tboot) is performed.=C2=A0 Returning all-ones is the normal response =
of the x86<br>
&gt; chipset when unmapped MMIO regions are accessed; disabled localities o=
f<br>
&gt; the TPM may act like this.<br>
&gt;<br>
&gt; Does your system support the DRTM launch?=C2=A0 If so, can you test it=
 to see if<br>
&gt; this is the issue?<br>
<br>
<br>
</div></div>Emil,<br>
tboot supports Intel and OEM systems that are Intel TXT-capable.<br>
If your system does not support DRTM launch, I can test it in next week.<br=
>
<span class=3D"im HOEnZb"><br>
<br>
&gt;<br>
&gt; In this case, to better support people who want to use the vTPM Manage=
r<br>
&gt; without a DRTM launch, the features of the vTPM Manager that use the T=
PM<br>
&gt; 1.2 PCRs may need to be disabled or implemented in an alternate manner=
<br>
&gt; such as embedding the data in the quote instead of in PCRs.=C2=A0 The =
current<br>
&gt; design was created with the assumption that systems using it would be<=
br>
&gt; performing a DRTM launch in order to fully secure the boot process.<br=
>
&gt;<br>
&gt; &gt;&gt; In linux kernel this information is obtained using locality 0=
 and<br>
&gt; &gt;&gt; after that other commands execute using specified locality.<b=
r>
&gt; &gt;&gt; <a href=3D"https://git.kernel.org/cgit/linux/kernel/git/stabl=
e/linux-stable.git/" target=3D"_blank">https://git.kernel.org/cgit/linux/ke=
rnel/git/stable/linux-stable.git/</a><br>
&gt; &gt;&gt; tree/drivers/char/tpm/tpm_tis.c#n558<br>
&gt;<br>
&gt; Have you tested that other localities work for your TPM under Linux?<b=
r>
&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Thanks,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Emil<br>
&gt; &gt;&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Daniel De Graaf<br>
&gt; National Security Agency<br>
&gt;<br>
</span><div class=3D"HOEnZb"><div class=3D"h5">&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>
</div></div></blockquote></div><br></div>

--001a11c27f78a219b20507427773--


--===============5718198272142586792==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5718198272142586792==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 10:44:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmh1h-0006z6-JR; Fri, 07 Nov 2014 10:44:21 +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 1Xmh1g-0006z0-Ey
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 10:44:20 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	CA/5D-22777-382AC545; Fri, 07 Nov 2014 10:44:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415357057!8195068!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17498 invoked from network); 7 Nov 2014 10:44:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:44:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="190513031"
Message-ID: <545CA27F.4070400@citrix.com>
Date: Fri, 7 Nov 2014 10:44:15 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>, Stefan Bader <stefan.bader@canonical.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>, <linux-kernel@vger.kernel.org>, 
	<xen-devel@lists.xenproject.org>
References: <20141106214940.GD44162@ubuntu-hedt>
In-Reply-To: <20141106214940.GD44162@ubuntu-hedt>
X-DLP: MIA1
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 21:49, Seth Forshee wrote:
> We've had several reports of hitting the following BUG_ON in
> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
> results of testing with 3.17):
> 
>         /* Grant backend access to each skb fragment page. */
>         for (i = 0; i < frags; i++) {
>                 skb_frag_t *frag = skb_shinfo(skb)->frags + i;
>                 struct page *page = skb_frag_page(frag);
> 
>                 len = skb_frag_size(frag);
>                 offset = frag->page_offset;
> 
>                 /* Data must not cross a page boundary. */
>                 BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
> 
> When this happens the page in question is a "middle" page in a compound
> page (i.e. it's a tail page but not the last tail page), and the data is
> fully contained within the compound page. The data does however cross
> the hardware page boundary, and since compound_order evaluates to 0 for
> tail pages the check fails.
> 
> In going over this I've been unable to determine whether the BUG_ON in
> xennet_make_frags is incorrect or the paged skb data is wrong. I can't
> find that it's documented anywhere, and the networking code itself is a
> bit ambiguous when it comes to compound pages. On the one hand
> __skb_fill_page_desc specifically handles adding tail pages as paged
> data, but on the other hand skb_copy_bits kmaps frag->page.p which could
> fail with data that extends into another page.

netfront will safely handle this case so you can remove this BUG_ON()
(and the one later on).  But it would be better to find out were these
funny-looking skbs are coming from and (if necessary) fixing the bug there.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 10:44:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmh1h-0006z6-JR; Fri, 07 Nov 2014 10:44:21 +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 1Xmh1g-0006z0-Ey
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 10:44:20 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	CA/5D-22777-382AC545; Fri, 07 Nov 2014 10:44:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415357057!8195068!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17498 invoked from network); 7 Nov 2014 10:44:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:44:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="190513031"
Message-ID: <545CA27F.4070400@citrix.com>
Date: Fri, 7 Nov 2014 10:44:15 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>, Stefan Bader <stefan.bader@canonical.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>, <linux-kernel@vger.kernel.org>, 
	<xen-devel@lists.xenproject.org>
References: <20141106214940.GD44162@ubuntu-hedt>
In-Reply-To: <20141106214940.GD44162@ubuntu-hedt>
X-DLP: MIA1
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 21:49, Seth Forshee wrote:
> We've had several reports of hitting the following BUG_ON in
> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
> results of testing with 3.17):
> 
>         /* Grant backend access to each skb fragment page. */
>         for (i = 0; i < frags; i++) {
>                 skb_frag_t *frag = skb_shinfo(skb)->frags + i;
>                 struct page *page = skb_frag_page(frag);
> 
>                 len = skb_frag_size(frag);
>                 offset = frag->page_offset;
> 
>                 /* Data must not cross a page boundary. */
>                 BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
> 
> When this happens the page in question is a "middle" page in a compound
> page (i.e. it's a tail page but not the last tail page), and the data is
> fully contained within the compound page. The data does however cross
> the hardware page boundary, and since compound_order evaluates to 0 for
> tail pages the check fails.
> 
> In going over this I've been unable to determine whether the BUG_ON in
> xennet_make_frags is incorrect or the paged skb data is wrong. I can't
> find that it's documented anywhere, and the networking code itself is a
> bit ambiguous when it comes to compound pages. On the one hand
> __skb_fill_page_desc specifically handles adding tail pages as paged
> data, but on the other hand skb_copy_bits kmaps frag->page.p which could
> fail with data that extends into another page.

netfront will safely handle this case so you can remove this BUG_ON()
(and the one later on).  But it would be better to find out were these
funny-looking skbs are coming from and (if necessary) fixing the bug there.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 10:44:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:44:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmh28-00072D-WC; Fri, 07 Nov 2014 10:44:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xmh27-00071z-Qc
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:44:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8D/A6-09842-F92AC545; Fri, 07 Nov 2014 10:44:47 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415357085!12148459!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23513 invoked from network); 7 Nov 2014 10:44:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:44:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; 
	d="scan'208,217";a="189086221"
Message-ID: <545CA29A.2040703@citrix.com>
Date: Fri, 7 Nov 2014 10:44:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Anh Dinh <ug93tad@gmail.com>, <xen-devel@lists.xen.org>
References: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
In-Reply-To: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] how to deal with copy_to_user returning non 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: multipart/mixed; boundary="===============9097860363784739315=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9097860363784739315==
Content-Type: multipart/alternative;
	boundary="------------020604080304060105040807"

--------------020604080304060105040807
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 07/11/14 10:38, Anh Dinh wrote:
> I'm testing out a hypercall that takes in large data (many MB) from
> the user space and simply copy the data back. 
>
> For copying in, I call xmalloc_array() for about 4MB at a time and
> call copy_from_user() successfully for the entire input. 
>
> The problem is with copy_to_user() which returns non-zero values. I
> tried to vary the size of the data being copy, but still unable to
> copy the whole data back. 
>
> What are the cause of copy_to_user() failure? I checked the source I
> got quite lost at the code. 
>
> How could I make sure all data is copy back? Surely it is not a memory
> limitation problem, because I copy_from_user() succeeds for over 100MB. 
>

copy_to_user() returns non-zero if it encounters a fault while moving
data, generally a pagefault.

>
> ******
> long do_test_copy(long n, unsigned char *in, unsigned char *out){

This looks quite bogus.  You should have XEN_GUEST_HANDLE() for a
pointer into guest memory.  A bare pointer like *in is completely wrong.

~Andrew

>         unsigned char **tmp; 
>         long ret;
>         int m = n/(MAX_ALLOC); 
>         tmp = xmalloc_array(unsigned char*,m); 
>
>         for (int i=0; i<m; i++){
>                 tmp[i] = xmalloc_array(unsigned char, MAX_ALLOC); 
>                 copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_ALLOC); 
>         }
>         
>         for (int i=0; i<m; i++){
>                 if (tmp[i]){
>                         ret =
> copy_to_user(out+i*MAX_ALLOC,tmp[i],MAX_ALLOC);                 
>                         xfree(tmp[i]); 
>                 }
>         }
>         xfree(tmp);
>         return 0;       
> }
> ****
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------020604080304060105040807
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07/11/14 10:38, Anh Dinh wrote:<br>
    </div>
    <blockquote
cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div dir="ltr">I'm testing out a hypercall that takes in large
        data (many MB) from the user space and simply copy the data
        back.&nbsp;
        <div><br>
        </div>
        <div>For copying in, I call xmalloc_array() for about 4MB at a
          time and call copy_from_user() successfully for the entire
          input.&nbsp;</div>
        <div><br>
        </div>
        <div>The problem is with copy_to_user() which returns non-zero
          values. I tried to vary the size of the data being copy, but
          still unable to copy the whole data back.&nbsp;</div>
        <div><br>
        </div>
        <div>What are the cause of copy_to_user() failure? I checked the
          source I got quite lost at the code.&nbsp;</div>
        <div><br>
        </div>
        <div>How could I make sure all data is copy back? Surely it is
          not a memory limitation problem, because I copy_from_user()
          succeeds for over 100MB.&nbsp;</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    copy_to_user() returns non-zero if it encounters a fault while
    moving data, generally a pagefault.<br>
    <br>
    <blockquote
cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>******</div>
        <div>
          <div>long do_test_copy(long n, unsigned char *in, unsigned
            char *out){</div>
        </div>
      </div>
    </blockquote>
    <br>
    This looks quite bogus.&nbsp; You should have XEN_GUEST_HANDLE() for a
    pointer into guest memory.&nbsp; A bare pointer like *in is completely
    wrong.<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote
cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; unsigned char **tmp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; long ret;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; int m = n/(MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; tmp = xmalloc_array(unsigned char*,m);&nbsp;</div>
          <div><br>
          </div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; for (int i=0; i&lt;m; i++){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tmp[i] = xmalloc_array(unsigned char,
            MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
            copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; for (int i=0; i&lt;m; i++){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if (tmp[i]){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ret =
            copy_to_user(out+i*MAX_ALLOC,tmp[i],MAX_ALLOC); &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
            &nbsp; &nbsp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xfree(tmp[i]);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; xfree(tmp);</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; return 0; &nbsp; &nbsp; &nbsp;&nbsp;</div>
          <div>}</div>
        </div>
        <div>****</div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------020604080304060105040807--


--===============9097860363784739315==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9097860363784739315==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 10:44:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:44:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmh28-00072D-WC; Fri, 07 Nov 2014 10:44:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xmh27-00071z-Qc
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:44:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8D/A6-09842-F92AC545; Fri, 07 Nov 2014 10:44:47 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415357085!12148459!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23513 invoked from network); 7 Nov 2014 10:44:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:44:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; 
	d="scan'208,217";a="189086221"
Message-ID: <545CA29A.2040703@citrix.com>
Date: Fri, 7 Nov 2014 10:44:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Anh Dinh <ug93tad@gmail.com>, <xen-devel@lists.xen.org>
References: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
In-Reply-To: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] how to deal with copy_to_user returning non 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: multipart/mixed; boundary="===============9097860363784739315=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9097860363784739315==
Content-Type: multipart/alternative;
	boundary="------------020604080304060105040807"

--------------020604080304060105040807
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 07/11/14 10:38, Anh Dinh wrote:
> I'm testing out a hypercall that takes in large data (many MB) from
> the user space and simply copy the data back. 
>
> For copying in, I call xmalloc_array() for about 4MB at a time and
> call copy_from_user() successfully for the entire input. 
>
> The problem is with copy_to_user() which returns non-zero values. I
> tried to vary the size of the data being copy, but still unable to
> copy the whole data back. 
>
> What are the cause of copy_to_user() failure? I checked the source I
> got quite lost at the code. 
>
> How could I make sure all data is copy back? Surely it is not a memory
> limitation problem, because I copy_from_user() succeeds for over 100MB. 
>

copy_to_user() returns non-zero if it encounters a fault while moving
data, generally a pagefault.

>
> ******
> long do_test_copy(long n, unsigned char *in, unsigned char *out){

This looks quite bogus.  You should have XEN_GUEST_HANDLE() for a
pointer into guest memory.  A bare pointer like *in is completely wrong.

~Andrew

>         unsigned char **tmp; 
>         long ret;
>         int m = n/(MAX_ALLOC); 
>         tmp = xmalloc_array(unsigned char*,m); 
>
>         for (int i=0; i<m; i++){
>                 tmp[i] = xmalloc_array(unsigned char, MAX_ALLOC); 
>                 copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_ALLOC); 
>         }
>         
>         for (int i=0; i<m; i++){
>                 if (tmp[i]){
>                         ret =
> copy_to_user(out+i*MAX_ALLOC,tmp[i],MAX_ALLOC);                 
>                         xfree(tmp[i]); 
>                 }
>         }
>         xfree(tmp);
>         return 0;       
> }
> ****
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------020604080304060105040807
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07/11/14 10:38, Anh Dinh wrote:<br>
    </div>
    <blockquote
cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div dir="ltr">I'm testing out a hypercall that takes in large
        data (many MB) from the user space and simply copy the data
        back.&nbsp;
        <div><br>
        </div>
        <div>For copying in, I call xmalloc_array() for about 4MB at a
          time and call copy_from_user() successfully for the entire
          input.&nbsp;</div>
        <div><br>
        </div>
        <div>The problem is with copy_to_user() which returns non-zero
          values. I tried to vary the size of the data being copy, but
          still unable to copy the whole data back.&nbsp;</div>
        <div><br>
        </div>
        <div>What are the cause of copy_to_user() failure? I checked the
          source I got quite lost at the code.&nbsp;</div>
        <div><br>
        </div>
        <div>How could I make sure all data is copy back? Surely it is
          not a memory limitation problem, because I copy_from_user()
          succeeds for over 100MB.&nbsp;</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    copy_to_user() returns non-zero if it encounters a fault while
    moving data, generally a pagefault.<br>
    <br>
    <blockquote
cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>******</div>
        <div>
          <div>long do_test_copy(long n, unsigned char *in, unsigned
            char *out){</div>
        </div>
      </div>
    </blockquote>
    <br>
    This looks quite bogus.&nbsp; You should have XEN_GUEST_HANDLE() for a
    pointer into guest memory.&nbsp; A bare pointer like *in is completely
    wrong.<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote
cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; unsigned char **tmp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; long ret;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; int m = n/(MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; tmp = xmalloc_array(unsigned char*,m);&nbsp;</div>
          <div><br>
          </div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; for (int i=0; i&lt;m; i++){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tmp[i] = xmalloc_array(unsigned char,
            MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
            copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; for (int i=0; i&lt;m; i++){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if (tmp[i]){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ret =
            copy_to_user(out+i*MAX_ALLOC,tmp[i],MAX_ALLOC); &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
            &nbsp; &nbsp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xfree(tmp[i]);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; xfree(tmp);</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; return 0; &nbsp; &nbsp; &nbsp;&nbsp;</div>
          <div>}</div>
        </div>
        <div>****</div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------020604080304060105040807--


--===============9097860363784739315==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9097860363784739315==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 10:45:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmh2v-0007AC-E4; Fri, 07 Nov 2014 10:45:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xmh2u-00079u-55
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 10:45:36 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	76/2C-31453-FC2AC545; Fri, 07 Nov 2014 10:45:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415357133!8195452!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27648 invoked from network); 7 Nov 2014 10:45:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:45:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="190513154"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 05:45:32 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xmh2q-0001LB-3c;
	Fri, 07 Nov 2014 10:45:32 +0000
Date: Fri, 7 Nov 2014 10:45:32 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Mel Gorman <mgorman@suse.de>
Message-ID: <20141107104531.GA28188@zion.uk.xensource.com>
References: <1415296096-22873-1-git-send-email-wei.liu2@citrix.com>
	<20141107085210.GW21422@suse.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141107085210.GW21422@suse.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Hugh Dickins <hughd@google.com>,
	linux-mm@kvack.org, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Cyrill Gorcunov <gorcunov@openvz.org>,
	xen-devel@lists.xenproject.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH RFC] x86,
	mm: use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 08:52:10AM +0000, Mel Gorman wrote:
> On Thu, Nov 06, 2014 at 05:48:16PM +0000, Wei Liu wrote:
> > In b38af4721 ("x86,mm: fix pte_special versus pte_numa") pte_special()
> > (SPECIAL with PRESENT or PROTNONE) was made to complement pte_numa()
> > (SPECIAL with neither PRESENT nor PROTNONE). That broke Xen PV guest
> > with NUMA balancing support.
> > 
> > That's because Xen hypervisor sets _PAGE_GLOBAL (_PAGE_GLOBAL /
> > _PAGE_PROTNONE in Linux) for guest user space mapping. So in a Xen PV
> > guest, when NUMA balancing is enabled, a NUMA hinted PTE ends up
> > "SPECIAL (in fact NUMA) with PROTNONE but not PRESENT", which makes
> > pte_special() returns true when it shouldn't.
> > 
> > Fundamentally we only need _PAGE_NUMA and _PAGE_PRESENT to tell
> > difference between an unmapped entry and an entry protected for NUMA
> > hinting fault. So use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA, adjust
> > _PAGE_NUMA_MASK and SWP_OFFSET_SHIFT as needed.
> > 
> > Suggested-by: David Vrabel <david.vrabel@citrix.com>
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> I suggest instead that you force automatic NUMA balancing to be disabled
> on Xen PV guests until I or someone else finds time to implement Linus'
> idea to remove _PAGE_NUMA entirely. It's been on my TODO list for a few
> weeks but I still have not reached the point where I'm back working on
> upstream material properly.
>  

No problem. Thanks for the suggestion.

Wei.

> -- 
> Mel Gorman
> SUSE Labs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 10:45:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmh2v-0007AC-E4; Fri, 07 Nov 2014 10:45:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xmh2u-00079u-55
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 10:45:36 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	76/2C-31453-FC2AC545; Fri, 07 Nov 2014 10:45:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415357133!8195452!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27648 invoked from network); 7 Nov 2014 10:45:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:45:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="190513154"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 05:45:32 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xmh2q-0001LB-3c;
	Fri, 07 Nov 2014 10:45:32 +0000
Date: Fri, 7 Nov 2014 10:45:32 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Mel Gorman <mgorman@suse.de>
Message-ID: <20141107104531.GA28188@zion.uk.xensource.com>
References: <1415296096-22873-1-git-send-email-wei.liu2@citrix.com>
	<20141107085210.GW21422@suse.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141107085210.GW21422@suse.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Hugh Dickins <hughd@google.com>,
	linux-mm@kvack.org, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Cyrill Gorcunov <gorcunov@openvz.org>,
	xen-devel@lists.xenproject.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH RFC] x86,
	mm: use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 08:52:10AM +0000, Mel Gorman wrote:
> On Thu, Nov 06, 2014 at 05:48:16PM +0000, Wei Liu wrote:
> > In b38af4721 ("x86,mm: fix pte_special versus pte_numa") pte_special()
> > (SPECIAL with PRESENT or PROTNONE) was made to complement pte_numa()
> > (SPECIAL with neither PRESENT nor PROTNONE). That broke Xen PV guest
> > with NUMA balancing support.
> > 
> > That's because Xen hypervisor sets _PAGE_GLOBAL (_PAGE_GLOBAL /
> > _PAGE_PROTNONE in Linux) for guest user space mapping. So in a Xen PV
> > guest, when NUMA balancing is enabled, a NUMA hinted PTE ends up
> > "SPECIAL (in fact NUMA) with PROTNONE but not PRESENT", which makes
> > pte_special() returns true when it shouldn't.
> > 
> > Fundamentally we only need _PAGE_NUMA and _PAGE_PRESENT to tell
> > difference between an unmapped entry and an entry protected for NUMA
> > hinting fault. So use _PAGE_BIT_SOFTW2 as _PAGE_BIT_NUMA, adjust
> > _PAGE_NUMA_MASK and SWP_OFFSET_SHIFT as needed.
> > 
> > Suggested-by: David Vrabel <david.vrabel@citrix.com>
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> I suggest instead that you force automatic NUMA balancing to be disabled
> on Xen PV guests until I or someone else finds time to implement Linus'
> idea to remove _PAGE_NUMA entirely. It's been on my TODO list for a few
> weeks but I still have not reached the point where I'm back working on
> upstream material properly.
>  

No problem. Thanks for the suggestion.

Wei.

> -- 
> Mel Gorman
> SUSE Labs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 10:45:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmh3E-0007Dx-Qu; Fri, 07 Nov 2014 10:45:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1Xmh3E-0007Dk-1B
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:45:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	45/A8-09936-3E2AC545; Fri, 07 Nov 2014 10:45:55 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415357154!4145117!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22349 invoked from network); 7 Nov 2014 10:45:54 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:45:54 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so4133806wib.13
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:45:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=UibbcGsyLsfhlbnukxEM9qqP1mCJM9OMOOlNeom5em4=;
	b=AiEcBC4Fe22aN5gHEEcS1Ywd8eCQUof3xz3K747vUgAxcBeNSf93bBOO5eWbXgTTi4
	oQxmhxOWRso9EQpUMMcgxcRwQr/oG1FB/IlhEyZPiPoaYvVTspH/QzR9CGAdigF16/l9
	n1qPuW1z6zjWr0JiRA5HWNT8aLMol9ZQ0h0/KJxpr3XDWActl0nwESaME25ZDJYkxARt
	R/Ju//KuOEXzcGKufKOLb60jaFIGiGIhPlwjEhUqz0U7wnzptsqg1voiqs/bz8hVuFuK
	2IXAyP2p1+Yx7EntL2I2HLx14o5hSUherliMrTsENry2YYB2lpuvGAZfZtOZbanO1MPM
	OYxw==
MIME-Version: 1.0
X-Received: by 10.194.184.75 with SMTP id es11mr14749176wjc.35.1415357154107; 
	Fri, 07 Nov 2014 02:45:54 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Fri, 7 Nov 2014 02:45:54 -0800 (PST)
In-Reply-To: <545BEFC5.3010803@tycho.nsa.gov>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>
	<545235EE.4040000@citrix.com>
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
	<1415096148.11486.11.camel@citrix.com>
	<545BEFC5.3010803@tycho.nsa.gov>
Date: Fri, 7 Nov 2014 12:45:54 +0200
Message-ID: <CAAULxKKT7RBxbG+03wcK-PGUCVF4eG55pQkHjEuFZA6v30FOng@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2179514982186648016=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2179514982186648016==
Content-Type: multipart/alternative; boundary=047d7b6da76666a8bd0507428475

--047d7b6da76666a8bd0507428475
Content-Type: text/plain; charset=UTF-8

Daniel,
So, is the patch going to be approved(adjusting all short timeouts) or it
needs to be modified?

On Fri, Nov 7, 2014 at 12:01 AM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
wrote:

> On 11/04/2014 05:15 AM, Ian Campbell wrote:
>
>> On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
>>
>>> Of course we can use max, but I thought that it might be useful to
>>> have a prink to inform the user that the timeout was adjusted.
>>> In init_tpm_tis the default timeouts are set using:
>>> /* Set default timeouts */ tpm->timeout_a =
>>> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
>>> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
>>> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
>>> MILLISECS(TIS_SHORT_TIMEOUT);
>>>
>>>
>>>
>>> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/
>>> linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
>>> So if we want to integrate kernel changes I think we should use
>>> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
>>> Also in kernel the default timeouts are initialized using
>>> msecs_to_jiffies which is different from MILLISECS
>>> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/
>>> linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
>>> Is there a certain reason for not using msecs_to_jiffies ?
>>>
>>
>> jiffies are a Linux specific concept which mini-os doesn't share.
>>
>> Daniel, do you have any opinion on this patch?
>>
>> It seems like the Linux fix is made only for the specifically broken
>> platform. That seems to make sense to me since presumably other systems
>> report short timeouts which they can indeed cope with. It's only Atmel
>> which brokenly reports something it cannot handle.
>>
>> Ian.
>>
>
> I agree that an adjustment is needed when values are too short.  Adjusting
> in all cases is not quite as nice as only fixing the broken TPMs, but it
> is a lot simpler.  It also doesn't seem harmful to have the timeouts be
> too large in the driver: a properly functioning TPM will not time out its
> requests in any case, so the user won't notice normally, and the default
> short timeout is 0.75 seconds - very few people will complain if they have
> to wait that long to get a timeout instead of what their TPM actually uses.
>
> --
> Daniel De Graaf
> National Security Agency
>

--047d7b6da76666a8bd0507428475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Daniel,<div>So, is the patch going to be approved(adjustin=
g all short timeouts) or it needs to be modified?</div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 7, 2014 at 12:01 AM=
, Daniel De Graaf <span dir=3D"ltr">&lt;<a href=3D"mailto:dgdegra@tycho.nsa=
.gov" target=3D"_blank">dgdegra@tycho.nsa.gov</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 11/04=
/2014 05:15 AM, Ian Campbell wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Of course we can use max, but I thought that it might be useful to<br>
have a prink to inform the user that the timeout was adjusted.<br>
In init_tpm_tis the default timeouts are set using:<br>
/* Set default timeouts */ tpm-&gt;timeout_a =3D<br>
MILLISECS(TIS_SHORT_TIMEOUT);/<u></u>/750*1000000UL tpm-&gt;timeout_b =3D<b=
r>
MILLISECS(TIS_LONG_TIMEOUT);//<u></u>2000*1000000UL tpm-&gt;timeout_c =3D<b=
r>
MILLISECS(TIS_SHORT_TIMEOUT); tpm-&gt;timeout_d =3D<br>
MILLISECS(TIS_SHORT_TIMEOUT);<br>
<br>
<br>
<br>
But in kernel fix they are set as 750*1000 instead of 750*1000000UL :<br>
<a href=3D"https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/=
tree/drivers/char/tpm/tpm_tis.c#n381" target=3D"_blank">https://git.kernel.=
org/cgit/<u></u>linux/kernel/git/torvalds/<u></u>linux.git/tree/drivers/cha=
r/<u></u>tpm/tpm_tis.c#n381</a><br>
So if we want to integrate kernel changes I think we should use<br>
MICROSECS(TIS_SHORT_TIMEOUT) which is 750000<br>
Also in kernel the default timeouts are initialized using<br>
msecs_to_jiffies which is different from MILLISECS<br>
macro.: <a href=3D"https://git.kernel.org/cgit/linux/kernel/git/torvalds/li=
nux.git/tree/drivers/char/tpm/tpm_tis.c#n548" target=3D"_blank">https://git=
.kernel.org/cgit/<u></u>linux/kernel/git/torvalds/<u></u>linux.git/tree/dri=
vers/char/<u></u>tpm/tpm_tis.c#n548</a><br>
Is there a certain reason for not using msecs_to_jiffies ?<br>
</blockquote>
<br>
jiffies are a Linux specific concept which mini-os doesn&#39;t share.<br>
<br>
Daniel, do you have any opinion on this patch?<br>
<br>
It seems like the Linux fix is made only for the specifically broken<br>
platform. That seems to make sense to me since presumably other systems<br>
report short timeouts which they can indeed cope with. It&#39;s only Atmel<=
br>
which brokenly reports something it cannot handle.<br>
<br>
Ian.<br>
</blockquote>
<br></div></div>
I agree that an adjustment is needed when values are too short.=C2=A0 Adjus=
ting<br>
in all cases is not quite as nice as only fixing the broken TPMs, but it<br=
>
is a lot simpler.=C2=A0 It also doesn&#39;t seem harmful to have the timeou=
ts be<br>
too large in the driver: a properly functioning TPM will not time out its<b=
r>
requests in any case, so the user won&#39;t notice normally, and the defaul=
t<br>
short timeout is 0.75 seconds - very few people will complain if they have<=
br>
to wait that long to get a timeout instead of what their TPM actually uses.=
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
Daniel De Graaf<br>
National Security Agency<br>
</font></span></blockquote></div><br></div>

--047d7b6da76666a8bd0507428475--


--===============2179514982186648016==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2179514982186648016==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 10:45:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmh3E-0007Dx-Qu; Fri, 07 Nov 2014 10:45:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1Xmh3E-0007Dk-1B
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:45:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	45/A8-09936-3E2AC545; Fri, 07 Nov 2014 10:45:55 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415357154!4145117!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22349 invoked from network); 7 Nov 2014 10:45:54 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:45:54 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so4133806wib.13
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:45:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=UibbcGsyLsfhlbnukxEM9qqP1mCJM9OMOOlNeom5em4=;
	b=AiEcBC4Fe22aN5gHEEcS1Ywd8eCQUof3xz3K747vUgAxcBeNSf93bBOO5eWbXgTTi4
	oQxmhxOWRso9EQpUMMcgxcRwQr/oG1FB/IlhEyZPiPoaYvVTspH/QzR9CGAdigF16/l9
	n1qPuW1z6zjWr0JiRA5HWNT8aLMol9ZQ0h0/KJxpr3XDWActl0nwESaME25ZDJYkxARt
	R/Ju//KuOEXzcGKufKOLb60jaFIGiGIhPlwjEhUqz0U7wnzptsqg1voiqs/bz8hVuFuK
	2IXAyP2p1+Yx7EntL2I2HLx14o5hSUherliMrTsENry2YYB2lpuvGAZfZtOZbanO1MPM
	OYxw==
MIME-Version: 1.0
X-Received: by 10.194.184.75 with SMTP id es11mr14749176wjc.35.1415357154107; 
	Fri, 07 Nov 2014 02:45:54 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Fri, 7 Nov 2014 02:45:54 -0800 (PST)
In-Reply-To: <545BEFC5.3010803@tycho.nsa.gov>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>
	<545235EE.4040000@citrix.com>
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
	<1415096148.11486.11.camel@citrix.com>
	<545BEFC5.3010803@tycho.nsa.gov>
Date: Fri, 7 Nov 2014 12:45:54 +0200
Message-ID: <CAAULxKKT7RBxbG+03wcK-PGUCVF4eG55pQkHjEuFZA6v30FOng@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2179514982186648016=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2179514982186648016==
Content-Type: multipart/alternative; boundary=047d7b6da76666a8bd0507428475

--047d7b6da76666a8bd0507428475
Content-Type: text/plain; charset=UTF-8

Daniel,
So, is the patch going to be approved(adjusting all short timeouts) or it
needs to be modified?

On Fri, Nov 7, 2014 at 12:01 AM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
wrote:

> On 11/04/2014 05:15 AM, Ian Campbell wrote:
>
>> On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
>>
>>> Of course we can use max, but I thought that it might be useful to
>>> have a prink to inform the user that the timeout was adjusted.
>>> In init_tpm_tis the default timeouts are set using:
>>> /* Set default timeouts */ tpm->timeout_a =
>>> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
>>> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
>>> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
>>> MILLISECS(TIS_SHORT_TIMEOUT);
>>>
>>>
>>>
>>> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/
>>> linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
>>> So if we want to integrate kernel changes I think we should use
>>> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
>>> Also in kernel the default timeouts are initialized using
>>> msecs_to_jiffies which is different from MILLISECS
>>> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/
>>> linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
>>> Is there a certain reason for not using msecs_to_jiffies ?
>>>
>>
>> jiffies are a Linux specific concept which mini-os doesn't share.
>>
>> Daniel, do you have any opinion on this patch?
>>
>> It seems like the Linux fix is made only for the specifically broken
>> platform. That seems to make sense to me since presumably other systems
>> report short timeouts which they can indeed cope with. It's only Atmel
>> which brokenly reports something it cannot handle.
>>
>> Ian.
>>
>
> I agree that an adjustment is needed when values are too short.  Adjusting
> in all cases is not quite as nice as only fixing the broken TPMs, but it
> is a lot simpler.  It also doesn't seem harmful to have the timeouts be
> too large in the driver: a properly functioning TPM will not time out its
> requests in any case, so the user won't notice normally, and the default
> short timeout is 0.75 seconds - very few people will complain if they have
> to wait that long to get a timeout instead of what their TPM actually uses.
>
> --
> Daniel De Graaf
> National Security Agency
>

--047d7b6da76666a8bd0507428475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Daniel,<div>So, is the patch going to be approved(adjustin=
g all short timeouts) or it needs to be modified?</div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 7, 2014 at 12:01 AM=
, Daniel De Graaf <span dir=3D"ltr">&lt;<a href=3D"mailto:dgdegra@tycho.nsa=
.gov" target=3D"_blank">dgdegra@tycho.nsa.gov</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 11/04=
/2014 05:15 AM, Ian Campbell wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Of course we can use max, but I thought that it might be useful to<br>
have a prink to inform the user that the timeout was adjusted.<br>
In init_tpm_tis the default timeouts are set using:<br>
/* Set default timeouts */ tpm-&gt;timeout_a =3D<br>
MILLISECS(TIS_SHORT_TIMEOUT);/<u></u>/750*1000000UL tpm-&gt;timeout_b =3D<b=
r>
MILLISECS(TIS_LONG_TIMEOUT);//<u></u>2000*1000000UL tpm-&gt;timeout_c =3D<b=
r>
MILLISECS(TIS_SHORT_TIMEOUT); tpm-&gt;timeout_d =3D<br>
MILLISECS(TIS_SHORT_TIMEOUT);<br>
<br>
<br>
<br>
But in kernel fix they are set as 750*1000 instead of 750*1000000UL :<br>
<a href=3D"https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/=
tree/drivers/char/tpm/tpm_tis.c#n381" target=3D"_blank">https://git.kernel.=
org/cgit/<u></u>linux/kernel/git/torvalds/<u></u>linux.git/tree/drivers/cha=
r/<u></u>tpm/tpm_tis.c#n381</a><br>
So if we want to integrate kernel changes I think we should use<br>
MICROSECS(TIS_SHORT_TIMEOUT) which is 750000<br>
Also in kernel the default timeouts are initialized using<br>
msecs_to_jiffies which is different from MILLISECS<br>
macro.: <a href=3D"https://git.kernel.org/cgit/linux/kernel/git/torvalds/li=
nux.git/tree/drivers/char/tpm/tpm_tis.c#n548" target=3D"_blank">https://git=
.kernel.org/cgit/<u></u>linux/kernel/git/torvalds/<u></u>linux.git/tree/dri=
vers/char/<u></u>tpm/tpm_tis.c#n548</a><br>
Is there a certain reason for not using msecs_to_jiffies ?<br>
</blockquote>
<br>
jiffies are a Linux specific concept which mini-os doesn&#39;t share.<br>
<br>
Daniel, do you have any opinion on this patch?<br>
<br>
It seems like the Linux fix is made only for the specifically broken<br>
platform. That seems to make sense to me since presumably other systems<br>
report short timeouts which they can indeed cope with. It&#39;s only Atmel<=
br>
which brokenly reports something it cannot handle.<br>
<br>
Ian.<br>
</blockquote>
<br></div></div>
I agree that an adjustment is needed when values are too short.=C2=A0 Adjus=
ting<br>
in all cases is not quite as nice as only fixing the broken TPMs, but it<br=
>
is a lot simpler.=C2=A0 It also doesn&#39;t seem harmful to have the timeou=
ts be<br>
too large in the driver: a properly functioning TPM will not time out its<b=
r>
requests in any case, so the user won&#39;t notice normally, and the defaul=
t<br>
short timeout is 0.75 seconds - very few people will complain if they have<=
br>
to wait that long to get a timeout instead of what their TPM actually uses.=
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
Daniel De Graaf<br>
National Security Agency<br>
</font></span></blockquote></div><br></div>

--047d7b6da76666a8bd0507428475--


--===============2179514982186648016==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2179514982186648016==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 10:47:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:47:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmh5B-0007TW-BI; Fri, 07 Nov 2014 10:47:57 +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 1Xmh5A-0007TL-5J
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 10:47:56 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	43/76-25714-B53AC545; Fri, 07 Nov 2014 10:47:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415357273!5668543!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19227 invoked from network); 7 Nov 2014 10:47:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:47:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="189086882"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 05:47:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xmh56-0001NH-EL;
	Fri, 07 Nov 2014 10:47:52 +0000
Date: Fri, 7 Nov 2014 10:47:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141107104752.GB28188@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545BC8A2.20604@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> Hi,
> 
> While doing VM migration, in the destination side:
> 
>    # xl list -l
>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
>     [
>         {
>             "domid": 0,
>             "config": {
>                 "c_info": {
>                     "type": "pv",
>                     "name": "Domain-0"
>                 },
>                 "b_info": {
>                     "max_memkb": 876544,
>                     "target_memkb": 876543,
>                     "sched_params": {
>     
>                     },
>                     "type.pv": {
>     
>                     }
>                 }
>             }
>         }
>     ]
>  
>     # xl list
>     Name                                          ID   Mem VCPUs      State   Time(s)
>     Domain-0                                       0   856     4     r-----    2758.9
>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> 
> Testing on:
> 

What's the rune you used to migrate the domain? xl migrate? Why is the
domain paused?

What's inside /var/lib/xen?

What's the content of xenstore?

Wei.

>     commit 816f5bb1f0740be8355e1be6cc24edf09547d984
>     Author: Ian Campbell <ian.campbell@citrix.com>
>     Date:   Fri Oct 24 10:58:33 2014 +0100
> 
> Thanks,
> 
> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 10:47:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:47:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmh5B-0007TW-BI; Fri, 07 Nov 2014 10:47:57 +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 1Xmh5A-0007TL-5J
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 10:47:56 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	43/76-25714-B53AC545; Fri, 07 Nov 2014 10:47:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415357273!5668543!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19227 invoked from network); 7 Nov 2014 10:47:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:47:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="189086882"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 05:47:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xmh56-0001NH-EL;
	Fri, 07 Nov 2014 10:47:52 +0000
Date: Fri, 7 Nov 2014 10:47:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141107104752.GB28188@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545BC8A2.20604@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> Hi,
> 
> While doing VM migration, in the destination side:
> 
>    # xl list -l
>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
>     [
>         {
>             "domid": 0,
>             "config": {
>                 "c_info": {
>                     "type": "pv",
>                     "name": "Domain-0"
>                 },
>                 "b_info": {
>                     "max_memkb": 876544,
>                     "target_memkb": 876543,
>                     "sched_params": {
>     
>                     },
>                     "type.pv": {
>     
>                     }
>                 }
>             }
>         }
>     ]
>  
>     # xl list
>     Name                                          ID   Mem VCPUs      State   Time(s)
>     Domain-0                                       0   856     4     r-----    2758.9
>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> 
> Testing on:
> 

What's the rune you used to migrate the domain? xl migrate? Why is the
domain paused?

What's inside /var/lib/xen?

What's the content of xenstore?

Wei.

>     commit 816f5bb1f0740be8355e1be6cc24edf09547d984
>     Author: Ian Campbell <ian.campbell@citrix.com>
>     Date:   Fri Oct 24 10:58:33 2014 +0100
> 
> Thanks,
> 
> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 10:57:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:57:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhE7-0007ik-Er; Fri, 07 Nov 2014 10:57:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ug93tad@gmail.com>) id 1XmhE6-0007if-0G
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:57:10 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	33/3F-03145-585AC545; Fri, 07 Nov 2014 10:57:09 +0000
X-Env-Sender: ug93tad@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415357825!8690543!1
X-Originating-IP: [209.85.220.48]
X-SpamReason: No, hits=0.5 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32044 invoked from network); 7 Nov 2014 10:57:06 -0000
Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com)
	(209.85.220.48)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:57:06 -0000
Received: by mail-pa0-f48.google.com with SMTP id ey11so3315484pad.7
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:57:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=VTKl2Zxs9JPE1NgRMpj65B5S+XoEc0yXKZgF7ArU46I=;
	b=Rvg2sm0qyQ99G5pVaRNPFq4KVheDN9+4G5eUKmigv+JG8FQu5Jlf5gZ9y4MWOlrfko
	nAA8N/WjprX4J+cpwMQcbvO0tXeHnn2vukanFuodyokGL3DOh+VkVbsD46Q25qqrGWtd
	GHm0ykoDDFxDH7FY5G1DECx7dOz0taRfDvnSGmLvjiXtw4pUj88ZPwn3KI6AlNgJJTLt
	TBrHI2amKCt18tvLuDUBNB970+5ctKN313duM0B4VYSKlxj5CRVPw8UgYIZuoIl96/y9
	879NZyct3jLNYT25Z43N3ju6b41/klEkqH0KRVpLgH9qEzr4I/eVCf6Ru22JjpNHV5pu
	k7OA==
X-Received: by 10.66.158.170 with SMTP id wv10mr9353802pab.64.1415357825038;
	Fri, 07 Nov 2014 02:57:05 -0800 (PST)
Received: from [10.148.222.139] ([180.255.240.18])
	by mx.google.com with ESMTPSA id y2sm8440867pdp.31.2014.11.07.02.57.03
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 07 Nov 2014 02:57:03 -0800 (PST)
Mime-Version: 1.0 (1.0)
From: And Dinh <ug93tad@gmail.com>
X-Mailer: iPhone Mail (12A405)
In-Reply-To: <545CA29A.2040703@citrix.com>
Date: Fri, 7 Nov 2014 18:57:02 +0800
Message-Id: <CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com>
References: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
	<545CA29A.2040703@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "<xen-devel@lists.xen.org>" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] how to deal with copy_to_user returning non 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: multipart/mixed; boundary="===============5883521013359692529=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5883521013359692529==
Content-Type: multipart/alternative;
	boundary=Apple-Mail-C8974F88-1590-476A-AA16-312565CB93FD
Content-Transfer-Encoding: 7bit


--Apple-Mail-C8974F88-1590-476A-AA16-312565CB93FD
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

how does it get page fault? I made sure the output buffer at the user space i=
s properly allocated with the correct  size.

When page fault, do I have no choice but abort? It seems calling the hyperca=
ll again does not solve it.




> On 7 Nov 2014, at 6:44 pm, Andrew Cooper <andrew.cooper3@citrix.com> wrote=
:
>=20
>> On 07/11/14 10:38, Anh Dinh wrote:
>> I'm testing out a hypercall that takes in large data (many MB) from the u=
ser space and simply copy the data back.=20
>>=20
>> For copying in, I call xmalloc_array() for about 4MB at a time and call c=
opy_from_user() successfully for the entire input.=20
>>=20
>> The problem is with copy_to_user() which returns non-zero values. I tried=
 to vary the size of the data being copy, but still unable to copy the whole=
 data back.=20
>>=20
>> What are the cause of copy_to_user() failure? I checked the source I got q=
uite lost at the code.=20
>>=20
>> How could I make sure all data is copy back? Surely it is not a memory li=
mitation problem, because I copy_from_user() succeeds for over 100MB.=20
>=20
> copy_to_user() returns non-zero if it encounters a fault while moving data=
, generally a pagefault.
>=20
>>=20
>> ******
>> long do_test_copy(long n, unsigned char *in, unsigned char *out){
>=20
> This looks quite bogus.  You should have XEN_GUEST_HANDLE() for a pointer i=
nto guest memory.  A bare pointer like *in is completely wrong.
>=20
> ~Andrew
>=20
>>         unsigned char **tmp;=20
>>         long ret;
>>         int m =3D n/(MAX_ALLOC);=20
>>         tmp =3D xmalloc_array(unsigned char*,m);=20
>>=20
>>         for (int i=3D0; i<m; i++){
>>                 tmp[i] =3D xmalloc_array(unsigned char, MAX_ALLOC);=20
>>                 copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_ALLOC);=20
>>         }
>>        =20
>>         for (int i=3D0; i<m; i++){
>>                 if (tmp[i]){
>>                         ret =3D copy_to_user(out+i*MAX_ALLOC,tmp[i],MAX_A=
LLOC);                =20
>>                         xfree(tmp[i]);=20
>>                 }
>>         }
>>         xfree(tmp);
>>         return 0;      =20
>> }
>> ****
>>=20
>>=20
>>=20
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>=20

--Apple-Mail-C8974F88-1590-476A-AA16-312565CB93FD
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>how does it get page fault? I made sure the output buffer at the user space is properly allocated with the correct &nbsp;size.</div><div><br></div><div>When page fault, do I have no choice but abort? It seems calling the hypercall again does not solve it.</div><div><br></div><div><br><br></div><div><br>On 7 Nov 2014, at 6:44 pm, Andrew Cooper &lt;<a href="mailto:andrew.cooper3@citrix.com">andrew.cooper3@citrix.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  
    <div class="moz-cite-prefix">On 07/11/14 10:38, Anh Dinh wrote:<br>
    </div>
    <blockquote cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div dir="ltr">I'm testing out a hypercall that takes in large
        data (many MB) from the user space and simply copy the data
        back.&nbsp;
        <div><br>
        </div>
        <div>For copying in, I call xmalloc_array() for about 4MB at a
          time and call copy_from_user() successfully for the entire
          input.&nbsp;</div>
        <div><br>
        </div>
        <div>The problem is with copy_to_user() which returns non-zero
          values. I tried to vary the size of the data being copy, but
          still unable to copy the whole data back.&nbsp;</div>
        <div><br>
        </div>
        <div>What are the cause of copy_to_user() failure? I checked the
          source I got quite lost at the code.&nbsp;</div>
        <div><br>
        </div>
        <div>How could I make sure all data is copy back? Surely it is
          not a memory limitation problem, because I copy_from_user()
          succeeds for over 100MB.&nbsp;</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    copy_to_user() returns non-zero if it encounters a fault while
    moving data, generally a pagefault.<br>
    <br>
    <blockquote cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com" type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>******</div>
        <div>
          <div>long do_test_copy(long n, unsigned char *in, unsigned
            char *out){</div>
        </div>
      </div>
    </blockquote>
    <br>
    This looks quite bogus.&nbsp; You should have XEN_GUEST_HANDLE() for a
    pointer into guest memory.&nbsp; A bare pointer like *in is completely
    wrong.<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com" type="cite">
      <div dir="ltr">
        <div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; unsigned char **tmp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; long ret;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; int m = n/(MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; tmp = xmalloc_array(unsigned char*,m);&nbsp;</div>
          <div><br>
          </div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; for (int i=0; i&lt;m; i++){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tmp[i] = xmalloc_array(unsigned char,
            MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
            copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; for (int i=0; i&lt;m; i++){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if (tmp[i]){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ret =
            copy_to_user(out+i*MAX_ALLOC,tmp[i],MAX_ALLOC); &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
            &nbsp; &nbsp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xfree(tmp[i]);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; xfree(tmp);</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; return 0; &nbsp; &nbsp; &nbsp;&nbsp;</div>
          <div>}</div>
        </div>
        <div>****</div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  

</div></blockquote></body></html>
--Apple-Mail-C8974F88-1590-476A-AA16-312565CB93FD--


--===============5883521013359692529==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5883521013359692529==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 10:57:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 10:57:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhE7-0007ik-Er; Fri, 07 Nov 2014 10:57:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ug93tad@gmail.com>) id 1XmhE6-0007if-0G
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 10:57:10 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	33/3F-03145-585AC545; Fri, 07 Nov 2014 10:57:09 +0000
X-Env-Sender: ug93tad@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415357825!8690543!1
X-Originating-IP: [209.85.220.48]
X-SpamReason: No, hits=0.5 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32044 invoked from network); 7 Nov 2014 10:57:06 -0000
Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com)
	(209.85.220.48)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 10:57:06 -0000
Received: by mail-pa0-f48.google.com with SMTP id ey11so3315484pad.7
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 02:57:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=VTKl2Zxs9JPE1NgRMpj65B5S+XoEc0yXKZgF7ArU46I=;
	b=Rvg2sm0qyQ99G5pVaRNPFq4KVheDN9+4G5eUKmigv+JG8FQu5Jlf5gZ9y4MWOlrfko
	nAA8N/WjprX4J+cpwMQcbvO0tXeHnn2vukanFuodyokGL3DOh+VkVbsD46Q25qqrGWtd
	GHm0ykoDDFxDH7FY5G1DECx7dOz0taRfDvnSGmLvjiXtw4pUj88ZPwn3KI6AlNgJJTLt
	TBrHI2amKCt18tvLuDUBNB970+5ctKN313duM0B4VYSKlxj5CRVPw8UgYIZuoIl96/y9
	879NZyct3jLNYT25Z43N3ju6b41/klEkqH0KRVpLgH9qEzr4I/eVCf6Ru22JjpNHV5pu
	k7OA==
X-Received: by 10.66.158.170 with SMTP id wv10mr9353802pab.64.1415357825038;
	Fri, 07 Nov 2014 02:57:05 -0800 (PST)
Received: from [10.148.222.139] ([180.255.240.18])
	by mx.google.com with ESMTPSA id y2sm8440867pdp.31.2014.11.07.02.57.03
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 07 Nov 2014 02:57:03 -0800 (PST)
Mime-Version: 1.0 (1.0)
From: And Dinh <ug93tad@gmail.com>
X-Mailer: iPhone Mail (12A405)
In-Reply-To: <545CA29A.2040703@citrix.com>
Date: Fri, 7 Nov 2014 18:57:02 +0800
Message-Id: <CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com>
References: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
	<545CA29A.2040703@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "<xen-devel@lists.xen.org>" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] how to deal with copy_to_user returning non 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: multipart/mixed; boundary="===============5883521013359692529=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5883521013359692529==
Content-Type: multipart/alternative;
	boundary=Apple-Mail-C8974F88-1590-476A-AA16-312565CB93FD
Content-Transfer-Encoding: 7bit


--Apple-Mail-C8974F88-1590-476A-AA16-312565CB93FD
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

how does it get page fault? I made sure the output buffer at the user space i=
s properly allocated with the correct  size.

When page fault, do I have no choice but abort? It seems calling the hyperca=
ll again does not solve it.




> On 7 Nov 2014, at 6:44 pm, Andrew Cooper <andrew.cooper3@citrix.com> wrote=
:
>=20
>> On 07/11/14 10:38, Anh Dinh wrote:
>> I'm testing out a hypercall that takes in large data (many MB) from the u=
ser space and simply copy the data back.=20
>>=20
>> For copying in, I call xmalloc_array() for about 4MB at a time and call c=
opy_from_user() successfully for the entire input.=20
>>=20
>> The problem is with copy_to_user() which returns non-zero values. I tried=
 to vary the size of the data being copy, but still unable to copy the whole=
 data back.=20
>>=20
>> What are the cause of copy_to_user() failure? I checked the source I got q=
uite lost at the code.=20
>>=20
>> How could I make sure all data is copy back? Surely it is not a memory li=
mitation problem, because I copy_from_user() succeeds for over 100MB.=20
>=20
> copy_to_user() returns non-zero if it encounters a fault while moving data=
, generally a pagefault.
>=20
>>=20
>> ******
>> long do_test_copy(long n, unsigned char *in, unsigned char *out){
>=20
> This looks quite bogus.  You should have XEN_GUEST_HANDLE() for a pointer i=
nto guest memory.  A bare pointer like *in is completely wrong.
>=20
> ~Andrew
>=20
>>         unsigned char **tmp;=20
>>         long ret;
>>         int m =3D n/(MAX_ALLOC);=20
>>         tmp =3D xmalloc_array(unsigned char*,m);=20
>>=20
>>         for (int i=3D0; i<m; i++){
>>                 tmp[i] =3D xmalloc_array(unsigned char, MAX_ALLOC);=20
>>                 copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_ALLOC);=20
>>         }
>>        =20
>>         for (int i=3D0; i<m; i++){
>>                 if (tmp[i]){
>>                         ret =3D copy_to_user(out+i*MAX_ALLOC,tmp[i],MAX_A=
LLOC);                =20
>>                         xfree(tmp[i]);=20
>>                 }
>>         }
>>         xfree(tmp);
>>         return 0;      =20
>> }
>> ****
>>=20
>>=20
>>=20
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>=20

--Apple-Mail-C8974F88-1590-476A-AA16-312565CB93FD
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>how does it get page fault? I made sure the output buffer at the user space is properly allocated with the correct &nbsp;size.</div><div><br></div><div>When page fault, do I have no choice but abort? It seems calling the hypercall again does not solve it.</div><div><br></div><div><br><br></div><div><br>On 7 Nov 2014, at 6:44 pm, Andrew Cooper &lt;<a href="mailto:andrew.cooper3@citrix.com">andrew.cooper3@citrix.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  
    <div class="moz-cite-prefix">On 07/11/14 10:38, Anh Dinh wrote:<br>
    </div>
    <blockquote cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div dir="ltr">I'm testing out a hypercall that takes in large
        data (many MB) from the user space and simply copy the data
        back.&nbsp;
        <div><br>
        </div>
        <div>For copying in, I call xmalloc_array() for about 4MB at a
          time and call copy_from_user() successfully for the entire
          input.&nbsp;</div>
        <div><br>
        </div>
        <div>The problem is with copy_to_user() which returns non-zero
          values. I tried to vary the size of the data being copy, but
          still unable to copy the whole data back.&nbsp;</div>
        <div><br>
        </div>
        <div>What are the cause of copy_to_user() failure? I checked the
          source I got quite lost at the code.&nbsp;</div>
        <div><br>
        </div>
        <div>How could I make sure all data is copy back? Surely it is
          not a memory limitation problem, because I copy_from_user()
          succeeds for over 100MB.&nbsp;</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    copy_to_user() returns non-zero if it encounters a fault while
    moving data, generally a pagefault.<br>
    <br>
    <blockquote cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com" type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>******</div>
        <div>
          <div>long do_test_copy(long n, unsigned char *in, unsigned
            char *out){</div>
        </div>
      </div>
    </blockquote>
    <br>
    This looks quite bogus.&nbsp; You should have XEN_GUEST_HANDLE() for a
    pointer into guest memory.&nbsp; A bare pointer like *in is completely
    wrong.<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote cite="mid:CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com" type="cite">
      <div dir="ltr">
        <div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; unsigned char **tmp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; long ret;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; int m = n/(MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; tmp = xmalloc_array(unsigned char*,m);&nbsp;</div>
          <div><br>
          </div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; for (int i=0; i&lt;m; i++){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tmp[i] = xmalloc_array(unsigned char,
            MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
            copy_from_user(tmp[i],in+i*MAX_ALLOC,MAX_ALLOC);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; for (int i=0; i&lt;m; i++){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if (tmp[i]){</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ret =
            copy_to_user(out+i*MAX_ALLOC,tmp[i],MAX_ALLOC); &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
            &nbsp; &nbsp;&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xfree(tmp[i]);&nbsp;</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; }</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; xfree(tmp);</div>
          <div>&nbsp; &nbsp; &nbsp; &nbsp; return 0; &nbsp; &nbsp; &nbsp;&nbsp;</div>
          <div>}</div>
        </div>
        <div>****</div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  

</div></blockquote></body></html>
--Apple-Mail-C8974F88-1590-476A-AA16-312565CB93FD--


--===============5883521013359692529==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5883521013359692529==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 11:01:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11: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 1XmhIU-0007u9-Co; Fri, 07 Nov 2014 11:01:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmhIT-0007u4-N6
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 11:01:41 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	0A/D2-22777-496AC545; Fri, 07 Nov 2014 11:01:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415358098!11063367!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25405 invoked from network); 7 Nov 2014 11:01:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:01:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; 
	d="scan'208,217";a="190515851"
Message-ID: <545CA690.8090507@citrix.com>
Date: Fri, 7 Nov 2014 11:01:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: And Dinh <ug93tad@gmail.com>
References: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
	<545CA29A.2040703@citrix.com>
	<CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com>
In-Reply-To: <CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com>
X-DLP: MIA2
Cc: "<xen-devel@lists.xen.org>" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] how to deal with copy_to_user returning non 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: multipart/mixed; boundary="===============6538728999317017695=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6538728999317017695==
Content-Type: multipart/alternative;
	boundary="------------020605050503080408000806"

--------------020605050503080408000806
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On 07/11/14 10:57, And Dinh wrote:
> how does it get page fault? I made sure the output buffer at the user
> space is properly allocated with the correct  size.
>
> When page fault, do I have no choice but abort? It seems calling the
> hypercall again does not solve it.
>

And nothing guarentees that your userspace process is in context when
Xen is running, or that the kernel hasn't played with the pagetables
behind your back.

You must use the hypercall buffer mechanism to avoid issues like this. 
See the hypercall implementations in libxc.  In Xen, you must have a
XEN_GUEST_HANDLE() which is an opaque reference to your buffer, and use
copy_{to,from}_guest() rather than {to/from}_user(), which is generally
only safe for kernel addresses.

~Andrew

--------------020605050503080408000806
Content-Type: text/html; charset="UTF-8"
Content-Length: 1400
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 07/11/14 10:57, And Dinh wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8">
      <div>how does it get page fault=3F I made sure the output buffer at
        the user space is properly allocated with the correct =C2=A0size.</div>
      <div><br>
      </div>
      <div>When page fault, do I have no choice but abort=3F It seems
        calling the hypercall again does not solve it.</div>
      <div><br>
      </div>
    </blockquote>
    <br>
    And nothing guarentees that your userspace process is in context
    when Xen is running, or that the kernel hasn't played with the
    pagetables behind your back.<br>
    <br>
    You must use the hypercall buffer mechanism to avoid issues like
    this.=C2=A0 See the hypercall implementations in libxc.=C2=A0 In Xen, you must
    have a XEN_GUEST_HANDLE() which is an opaque reference to your
    buffer, and use copy_{to,from}_guest() rather than {to/from}_user(),
    which is generally only safe for kernel addresses.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------020605050503080408000806--


--===============6538728999317017695==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6538728999317017695==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 11:01:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11: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 1XmhIU-0007u9-Co; Fri, 07 Nov 2014 11:01:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmhIT-0007u4-N6
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 11:01:41 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	0A/D2-22777-496AC545; Fri, 07 Nov 2014 11:01:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415358098!11063367!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25405 invoked from network); 7 Nov 2014 11:01:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:01:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; 
	d="scan'208,217";a="190515851"
Message-ID: <545CA690.8090507@citrix.com>
Date: Fri, 7 Nov 2014 11:01:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: And Dinh <ug93tad@gmail.com>
References: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
	<545CA29A.2040703@citrix.com>
	<CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com>
In-Reply-To: <CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com>
X-DLP: MIA2
Cc: "<xen-devel@lists.xen.org>" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] how to deal with copy_to_user returning non 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: multipart/mixed; boundary="===============6538728999317017695=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6538728999317017695==
Content-Type: multipart/alternative;
	boundary="------------020605050503080408000806"

--------------020605050503080408000806
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On 07/11/14 10:57, And Dinh wrote:
> how does it get page fault? I made sure the output buffer at the user
> space is properly allocated with the correct  size.
>
> When page fault, do I have no choice but abort? It seems calling the
> hypercall again does not solve it.
>

And nothing guarentees that your userspace process is in context when
Xen is running, or that the kernel hasn't played with the pagetables
behind your back.

You must use the hypercall buffer mechanism to avoid issues like this. 
See the hypercall implementations in libxc.  In Xen, you must have a
XEN_GUEST_HANDLE() which is an opaque reference to your buffer, and use
copy_{to,from}_guest() rather than {to/from}_user(), which is generally
only safe for kernel addresses.

~Andrew

--------------020605050503080408000806
Content-Type: text/html; charset="UTF-8"
Content-Length: 1400
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 07/11/14 10:57, And Dinh wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8">
      <div>how does it get page fault=3F I made sure the output buffer at
        the user space is properly allocated with the correct =C2=A0size.</div>
      <div><br>
      </div>
      <div>When page fault, do I have no choice but abort=3F It seems
        calling the hypercall again does not solve it.</div>
      <div><br>
      </div>
    </blockquote>
    <br>
    And nothing guarentees that your userspace process is in context
    when Xen is running, or that the kernel hasn't played with the
    pagetables behind your back.<br>
    <br>
    You must use the hypercall buffer mechanism to avoid issues like
    this.=C2=A0 See the hypercall implementations in libxc.=C2=A0 In Xen, you must
    have a XEN_GUEST_HANDLE() which is an opaque reference to your
    buffer, and use copy_{to,from}_guest() rather than {to/from}_user(),
    which is generally only safe for kernel addresses.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------020605050503080408000806--


--===============6538728999317017695==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6538728999317017695==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 11:05:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11: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 1XmhMM-000857-3s; Fri, 07 Nov 2014 11:05:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XmhMK-000852-Td
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:05:41 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	2B/18-19763-487AC545; Fri, 07 Nov 2014 11:05:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415358337!11065532!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21772 invoked from network); 7 Nov 2014 11:05:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:05:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="190516728"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 06:05:13 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XmhLs-0001fQ-SN;
	Fri, 07 Nov 2014 11:05:12 +0000
Date: Fri, 7 Nov 2014 11:05:12 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141107110512.GA12109@zion.uk.xensource.com>
References: <545BF386.1050106@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545BF386.1050106@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, wei.liu2@citrix.com
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 05:17:42PM -0500, Zhigang Wang wrote:
> Hi,
> 
> I get this error:
> 
>     # xl mem-max 3 700
>     libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max
>     : Success
>     cannot set domid 3 static max memory to : 700
> 

What's your expected behaviour? What's your end goal?

Can the behavior you expected be achieved by manipulating target memory
instead of maxmem?

ISTR Oracle has different view on how memory targets are managed. But
with no other information provided it's hard for me to figure out your
intent and start a conversation.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:05:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11: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 1XmhMM-000857-3s; Fri, 07 Nov 2014 11:05:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XmhMK-000852-Td
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:05:41 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	2B/18-19763-487AC545; Fri, 07 Nov 2014 11:05:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415358337!11065532!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21772 invoked from network); 7 Nov 2014 11:05:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:05:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="190516728"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 06:05:13 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XmhLs-0001fQ-SN;
	Fri, 07 Nov 2014 11:05:12 +0000
Date: Fri, 7 Nov 2014 11:05:12 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141107110512.GA12109@zion.uk.xensource.com>
References: <545BF386.1050106@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545BF386.1050106@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, wei.liu2@citrix.com
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 05:17:42PM -0500, Zhigang Wang wrote:
> Hi,
> 
> I get this error:
> 
>     # xl mem-max 3 700
>     libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max
>     : Success
>     cannot set domid 3 static max memory to : 700
> 

What's your expected behaviour? What's your end goal?

Can the behavior you expected be achieved by manipulating target memory
instead of maxmem?

ISTR Oracle has different view on how memory targets are managed. But
with no other information provided it's hard for me to figure out your
intent and start a conversation.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:05:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhMW-00086M-GO; Fri, 07 Nov 2014 11:05:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmhMV-000867-7i
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 11:05:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4A/41-09936-E87AC545; Fri, 07 Nov 2014 11:05:50 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415358349!8738512!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3629 invoked from network); 7 Nov 2014 11:05:49 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-16.tower-21.messagelabs.com with SMTP;
	7 Nov 2014 11:05:49 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id AB3F966;
	Fri,  7 Nov 2014 05:05:45 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 8A7515FAD7;
	Fri,  7 Nov 2014 05:05:42 -0600 (CST)
Received: from localhost (unknown [10.1.17.197])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 2DD7013F91E;
	Fri,  7 Nov 2014 05:05:32 -0600 (CST)
Date: Fri, 7 Nov 2014 11:05:25 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107110524.GA21875@localhost>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
Thread-Topic: [PATCH v7 3/8] arm64: introduce is_device_dma_coherent
Accept-Language: en-GB, en-US
Content-Language: en-US
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 12:22:13PM +0000, Stefano Stabellini wrote:
> On Thu, 6 Nov 2014, Catalin Marinas wrote:
> > On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> > > On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > > > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > > > standard cache maintenance would be enough (but that's a Xen problem,
> > > > not sure how to solve).
> > > 
> > > It is a thorny issue indeed.
> > > Xen would need to know how to do non-standard cache maintenance
> > > operations.
> > 
> > Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
> > just use the currently registered dma ops.
> 
> It is Xen, so El2 hypervisor.

So what is arch/arm/xen/mm32.c cache maintenance for? Doesn't it run in
dom0?

> > > Otherwise we would need to resurrect XENFEAT_grant_map_identity (that I
> > > am reverting in this series) and be content with having CONFIG_XEN_DOM0
> > > depend on CONFIG_ARM_LPAE.
> > 
> > So what does buy you? Is it just the hope that with LPAE you won't have
> > weird system caches?
> 
> Let me explain a bit more and let's assume there is no SMMU.
> 
> The problem is not normal dma originating in dom0, currently mapped 1:1
> (pseudo-physical == physical). The problem are dma operations that
> involve foreign pages (pages belonging to other virtual machines)
> currently mapped also in dom0 to do IO. It is common for the Xen PV
> network and block frontends to grant access to one or more pages to the
> network and block backends for IO. The backends, usually in dom0, map
> the pages and perform the actual IO. Sometimes the IO is a dma operation
> that involves one of the granted pages directly.
> 
> For these pages, the pseudo-physical address in dom0 is different from
> the physical address. Dom0 keeps track of the pseudo-physical to
> physical relationship (pfn_to_mfn in Xen terminology). The swiotlb-xen
> driver makes sure to return the right mfn from map_page and map_sg.

For my understanding, xen_dma_map_page() is called from dom0 and it
simply calls the __generic_dma_ops()->map_page(). The "page" argument
here is the dom0 page and it gets translated to dom0 phys and then to a
bus address via xen_phys_to_bus().

On arm64, __swiotlb_map_page() uses the page structure to get some
pseudo device address which gets converted back to a dom0 virtual
address. The latter is used for cache maintenance by VA in dom0. With
PIPT-like caches, that's fine, you don't need the actual machine PA
unless you have caches like PL310 (which are not compatible with
virtualisation anyway and the latest ARMv8 ARM even makes a clear
statement here).

(one potential problem here is the dma_capable() check in
swiotlb_map_page() (non-xen) which uses the pseudo device address)

The interesting part is that xen_swiotlb_map_page() returns the real
machine device address to dom0, which is different from what dom0 thinks
of a device address (phys_to_dma(phys_to_page(page))). Does dom0 use
such real/machine device address to program the device directly or there
is another layer where you could do the translation?

> However some of the dma_ops give you only a dma_addr_t handle
> (unmap_page and unmap_sg), that is the physical address of the page.

OK, I started to get it now, the __swiotlb_unmap_page() on arm64, if
called from dom0, would get the machine device address and dma_to_phys()
does not work.

> Dom0 doesn't know how to find the pseudo-physical address corresponding
> to it. Therefore it also doesn't know how to find the struct page for
> it. This is not a trivial problem to solve as the same page can be
> granted multiple times, therefore could have multiple pseudo-physical
> addresses and multiple struct pages corresponding to one physical
> address in dom0.

So what is mfn_to_pfn() and xen_bus_to_phys() used for? Isn't
mfn_to_pfn(pfn_to_mfn(x)) an identity function?

> Fortunately these dma_ops don't actually need to do much. In fact they
> only need to flush caches if the device is not dma-coherent. So the
> current proposed solution is to issue an hypercall to ask Xen to do the
> flushing, passing the physical address dom0 knows.

I really don't like the dma_cache_maint() duplication you added in
arch/arm/xen/mm32.c just because you cannot call the host dma_ops when
the page is not available.

You basically only need a VA that was mapped in dom0 when map_page() was
called and is still mapped when page_unmap() is called. You can free the
actual mapping after calling __generic_dma_ops()->unmap_page() in
xen_dma_unmap_page() (in xen_unmap_single()).

BTW, drivers/xen/swiotlb-xen.c needs something like:

        dma_addr_t dev_addr = xen_phys_to_bus(phys_to_dma(phys));

phys != bus address.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:05:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhMW-00086M-GO; Fri, 07 Nov 2014 11:05:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmhMV-000867-7i
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 11:05:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4A/41-09936-E87AC545; Fri, 07 Nov 2014 11:05:50 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415358349!8738512!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3629 invoked from network); 7 Nov 2014 11:05:49 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-16.tower-21.messagelabs.com with SMTP;
	7 Nov 2014 11:05:49 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id AB3F966;
	Fri,  7 Nov 2014 05:05:45 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 8A7515FAD7;
	Fri,  7 Nov 2014 05:05:42 -0600 (CST)
Received: from localhost (unknown [10.1.17.197])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 2DD7013F91E;
	Fri,  7 Nov 2014 05:05:32 -0600 (CST)
Date: Fri, 7 Nov 2014 11:05:25 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107110524.GA21875@localhost>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
Thread-Topic: [PATCH v7 3/8] arm64: introduce is_device_dma_coherent
Accept-Language: en-GB, en-US
Content-Language: en-US
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 12:22:13PM +0000, Stefano Stabellini wrote:
> On Thu, 6 Nov 2014, Catalin Marinas wrote:
> > On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> > > On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > > > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > > > standard cache maintenance would be enough (but that's a Xen problem,
> > > > not sure how to solve).
> > > 
> > > It is a thorny issue indeed.
> > > Xen would need to know how to do non-standard cache maintenance
> > > operations.
> > 
> > Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
> > just use the currently registered dma ops.
> 
> It is Xen, so El2 hypervisor.

So what is arch/arm/xen/mm32.c cache maintenance for? Doesn't it run in
dom0?

> > > Otherwise we would need to resurrect XENFEAT_grant_map_identity (that I
> > > am reverting in this series) and be content with having CONFIG_XEN_DOM0
> > > depend on CONFIG_ARM_LPAE.
> > 
> > So what does buy you? Is it just the hope that with LPAE you won't have
> > weird system caches?
> 
> Let me explain a bit more and let's assume there is no SMMU.
> 
> The problem is not normal dma originating in dom0, currently mapped 1:1
> (pseudo-physical == physical). The problem are dma operations that
> involve foreign pages (pages belonging to other virtual machines)
> currently mapped also in dom0 to do IO. It is common for the Xen PV
> network and block frontends to grant access to one or more pages to the
> network and block backends for IO. The backends, usually in dom0, map
> the pages and perform the actual IO. Sometimes the IO is a dma operation
> that involves one of the granted pages directly.
> 
> For these pages, the pseudo-physical address in dom0 is different from
> the physical address. Dom0 keeps track of the pseudo-physical to
> physical relationship (pfn_to_mfn in Xen terminology). The swiotlb-xen
> driver makes sure to return the right mfn from map_page and map_sg.

For my understanding, xen_dma_map_page() is called from dom0 and it
simply calls the __generic_dma_ops()->map_page(). The "page" argument
here is the dom0 page and it gets translated to dom0 phys and then to a
bus address via xen_phys_to_bus().

On arm64, __swiotlb_map_page() uses the page structure to get some
pseudo device address which gets converted back to a dom0 virtual
address. The latter is used for cache maintenance by VA in dom0. With
PIPT-like caches, that's fine, you don't need the actual machine PA
unless you have caches like PL310 (which are not compatible with
virtualisation anyway and the latest ARMv8 ARM even makes a clear
statement here).

(one potential problem here is the dma_capable() check in
swiotlb_map_page() (non-xen) which uses the pseudo device address)

The interesting part is that xen_swiotlb_map_page() returns the real
machine device address to dom0, which is different from what dom0 thinks
of a device address (phys_to_dma(phys_to_page(page))). Does dom0 use
such real/machine device address to program the device directly or there
is another layer where you could do the translation?

> However some of the dma_ops give you only a dma_addr_t handle
> (unmap_page and unmap_sg), that is the physical address of the page.

OK, I started to get it now, the __swiotlb_unmap_page() on arm64, if
called from dom0, would get the machine device address and dma_to_phys()
does not work.

> Dom0 doesn't know how to find the pseudo-physical address corresponding
> to it. Therefore it also doesn't know how to find the struct page for
> it. This is not a trivial problem to solve as the same page can be
> granted multiple times, therefore could have multiple pseudo-physical
> addresses and multiple struct pages corresponding to one physical
> address in dom0.

So what is mfn_to_pfn() and xen_bus_to_phys() used for? Isn't
mfn_to_pfn(pfn_to_mfn(x)) an identity function?

> Fortunately these dma_ops don't actually need to do much. In fact they
> only need to flush caches if the device is not dma-coherent. So the
> current proposed solution is to issue an hypercall to ask Xen to do the
> flushing, passing the physical address dom0 knows.

I really don't like the dma_cache_maint() duplication you added in
arch/arm/xen/mm32.c just because you cannot call the host dma_ops when
the page is not available.

You basically only need a VA that was mapped in dom0 when map_page() was
called and is still mapped when page_unmap() is called. You can free the
actual mapping after calling __generic_dma_ops()->unmap_page() in
xen_dma_unmap_page() (in xen_unmap_single()).

BTW, drivers/xen/swiotlb-xen.c needs something like:

        dma_addr_t dev_addr = xen_phys_to_bus(phys_to_dma(phys));

phys != bus address.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhP0-0008Ic-1w; Fri, 07 Nov 2014 11:08:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XmhOy-0008IQ-Sr
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:08:25 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B1/F9-27584-828AC545; Fri, 07 Nov 2014 11:08:24 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415358503!11072246!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 701 invoked from network); 7 Nov 2014 11:08:23 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-2.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Nov 2014 11:08:23 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XmhOu-0003Ns-F8; Fri, 07 Nov 2014 11:08:20 +0000
Message-ID: <545CA823.2080307@canonical.com>
Date: Fri, 07 Nov 2014 12:08:19 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, netdev@vger.kernel.org, 
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
References: <20141106214940.GD44162@ubuntu-hedt> <545CA27F.4070400@citrix.com>
In-Reply-To: <545CA27F.4070400@citrix.com>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8721980942217411242=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============8721980942217411242==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="bCvbWEJMulW7EirtrJbTqmj5j1SVXs2Fc"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--bCvbWEJMulW7EirtrJbTqmj5j1SVXs2Fc
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 07.11.2014 11:44, David Vrabel wrote:
> On 06/11/14 21:49, Seth Forshee wrote:
>> We've had several reports of hitting the following BUG_ON in
>> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
>> results of testing with 3.17):
>>
>>         /* Grant backend access to each skb fragment page. */
>>         for (i =3D 0; i < frags; i++) {
>>                 skb_frag_t *frag =3D skb_shinfo(skb)->frags + i;
>>                 struct page *page =3D skb_frag_page(frag);
>>
>>                 len =3D skb_frag_size(frag);
>>                 offset =3D frag->page_offset;
>>
>>                 /* Data must not cross a page boundary. */
>>                 BUG_ON(len + offset > PAGE_SIZE<<compound_order(page))=
;
>>
>> When this happens the page in question is a "middle" page in a compoun=
d
>> page (i.e. it's a tail page but not the last tail page), and the data =
is
>> fully contained within the compound page. The data does however cross
>> the hardware page boundary, and since compound_order evaluates to 0 fo=
r
>> tail pages the check fails.
>>
>> In going over this I've been unable to determine whether the BUG_ON in=

>> xennet_make_frags is incorrect or the paged skb data is wrong. I can't=

>> find that it's documented anywhere, and the networking code itself is =
a
>> bit ambiguous when it comes to compound pages. On the one hand
>> __skb_fill_page_desc specifically handles adding tail pages as paged
>> data, but on the other hand skb_copy_bits kmaps frag->page.p which cou=
ld
>> fail with data that extends into another page.
>=20
> netfront will safely handle this case so you can remove this BUG_ON()
> (and the one later on).  But it would be better to find out were these
> funny-looking skbs are coming from and (if necessary) fixing the bug th=
ere.

Right, in fact it does ignore pages from the start of a compound page in =
case
the offset is big enough. So there is no difference between that case and=
 the
one where the page pointer from the frag is adjusted the way it was obser=
ved.

It really boils down to the question what the real rules for the frags ar=
e. If
it is "only" that data may not cross the boundary of a hw or compound pag=
e this
leaves room for interpretation. The odd skb does not violate that but a c=
heck
for conformance would become a lot more complex. And netfront is not the =
only
place that expects the frag page to be pointing to the compound head (the=
re is
igb for example, though it does only a warn_on upon failing).

On the other hand the __skb_fill_page_desc is written in a way that seems=
 to
assume the frag page pointer may be pointing to a tail page. So before "b=
laming"
one piece of code or the other we need an authoritative answer to what we=
 are
supposed to expect.

-Stefan
>=20
> David
>=20



--bCvbWEJMulW7EirtrJbTqmj5j1SVXs2Fc
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

iQIcBAEBCgAGBQJUXKgjAAoJEOhnXe7L7s6jv00P/1h8nZmWti/L+ueiOit/Uv/u
2sBrwRi96T+9pi9dEFuDZruPCOqWEBcRjQnkdmL0Id0PwjjLwNd+pKfQuOgpGDmp
9GA1yO+yxFikHEgILlmPcvdEwAvMnRhm5BuBtthYuuJ+eWcKQfWJXswVB+769Vy+
hTYp01pqWay7XP5LMntzz7ZtShC3exOXs5nX1R/BmkxDWlm0WxlI/ALCmNCfuvpx
RkA3wfVHqC/azyzOiuyI+82MAx/0dah2kJddKbvwUr7oC3JYrCt+asOg19nB7RML
5505YPdp79SRB5vZa/bMS8QWh8x+xA5iVcTdbJxGGKix9Ms+OHk1KYC+qqKwm/yS
VdjQ5MJlp5woGDGtl04ExyOw1NXaqaMidExGktq7rl528wtn05tvn3PT6W7LdpwM
fook6Qs56Z6F+EVi1ZTY03d4aqp5NKhb5bFaKBsDJCtz+NpOSYxwa0BQZICYnKXy
ZXj8gN0s7dd9FfxGq+AVd5JKaXT18MxpIPW+pIw83ZL2QblH02L4imf9Lo5BkV7Z
0luMQMN3rsXNqINrbOa/JTrEyJwn0V2D4UwOrdJrsqN6Q1mx3Sqaa2QhVNYbBAtb
CdY8SyicB3sD8UaVlHqTB1jb2F6klst5ZTftxyDC9GT/088Zjb5AEqyeCUpItuI+
590GautyGVnF60sEHMK4
=VJCZ
-----END PGP SIGNATURE-----

--bCvbWEJMulW7EirtrJbTqmj5j1SVXs2Fc--


--===============8721980942217411242==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8721980942217411242==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 11:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhP0-0008Ic-1w; Fri, 07 Nov 2014 11:08:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XmhOy-0008IQ-Sr
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:08:25 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B1/F9-27584-828AC545; Fri, 07 Nov 2014 11:08:24 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415358503!11072246!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 701 invoked from network); 7 Nov 2014 11:08:23 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-2.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Nov 2014 11:08:23 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XmhOu-0003Ns-F8; Fri, 07 Nov 2014 11:08:20 +0000
Message-ID: <545CA823.2080307@canonical.com>
Date: Fri, 07 Nov 2014 12:08:19 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, netdev@vger.kernel.org, 
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
References: <20141106214940.GD44162@ubuntu-hedt> <545CA27F.4070400@citrix.com>
In-Reply-To: <545CA27F.4070400@citrix.com>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8721980942217411242=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============8721980942217411242==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="bCvbWEJMulW7EirtrJbTqmj5j1SVXs2Fc"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--bCvbWEJMulW7EirtrJbTqmj5j1SVXs2Fc
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 07.11.2014 11:44, David Vrabel wrote:
> On 06/11/14 21:49, Seth Forshee wrote:
>> We've had several reports of hitting the following BUG_ON in
>> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
>> results of testing with 3.17):
>>
>>         /* Grant backend access to each skb fragment page. */
>>         for (i =3D 0; i < frags; i++) {
>>                 skb_frag_t *frag =3D skb_shinfo(skb)->frags + i;
>>                 struct page *page =3D skb_frag_page(frag);
>>
>>                 len =3D skb_frag_size(frag);
>>                 offset =3D frag->page_offset;
>>
>>                 /* Data must not cross a page boundary. */
>>                 BUG_ON(len + offset > PAGE_SIZE<<compound_order(page))=
;
>>
>> When this happens the page in question is a "middle" page in a compoun=
d
>> page (i.e. it's a tail page but not the last tail page), and the data =
is
>> fully contained within the compound page. The data does however cross
>> the hardware page boundary, and since compound_order evaluates to 0 fo=
r
>> tail pages the check fails.
>>
>> In going over this I've been unable to determine whether the BUG_ON in=

>> xennet_make_frags is incorrect or the paged skb data is wrong. I can't=

>> find that it's documented anywhere, and the networking code itself is =
a
>> bit ambiguous when it comes to compound pages. On the one hand
>> __skb_fill_page_desc specifically handles adding tail pages as paged
>> data, but on the other hand skb_copy_bits kmaps frag->page.p which cou=
ld
>> fail with data that extends into another page.
>=20
> netfront will safely handle this case so you can remove this BUG_ON()
> (and the one later on).  But it would be better to find out were these
> funny-looking skbs are coming from and (if necessary) fixing the bug th=
ere.

Right, in fact it does ignore pages from the start of a compound page in =
case
the offset is big enough. So there is no difference between that case and=
 the
one where the page pointer from the frag is adjusted the way it was obser=
ved.

It really boils down to the question what the real rules for the frags ar=
e. If
it is "only" that data may not cross the boundary of a hw or compound pag=
e this
leaves room for interpretation. The odd skb does not violate that but a c=
heck
for conformance would become a lot more complex. And netfront is not the =
only
place that expects the frag page to be pointing to the compound head (the=
re is
igb for example, though it does only a warn_on upon failing).

On the other hand the __skb_fill_page_desc is written in a way that seems=
 to
assume the frag page pointer may be pointing to a tail page. So before "b=
laming"
one piece of code or the other we need an authoritative answer to what we=
 are
supposed to expect.

-Stefan
>=20
> David
>=20



--bCvbWEJMulW7EirtrJbTqmj5j1SVXs2Fc
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

iQIcBAEBCgAGBQJUXKgjAAoJEOhnXe7L7s6jv00P/1h8nZmWti/L+ueiOit/Uv/u
2sBrwRi96T+9pi9dEFuDZruPCOqWEBcRjQnkdmL0Id0PwjjLwNd+pKfQuOgpGDmp
9GA1yO+yxFikHEgILlmPcvdEwAvMnRhm5BuBtthYuuJ+eWcKQfWJXswVB+769Vy+
hTYp01pqWay7XP5LMntzz7ZtShC3exOXs5nX1R/BmkxDWlm0WxlI/ALCmNCfuvpx
RkA3wfVHqC/azyzOiuyI+82MAx/0dah2kJddKbvwUr7oC3JYrCt+asOg19nB7RML
5505YPdp79SRB5vZa/bMS8QWh8x+xA5iVcTdbJxGGKix9Ms+OHk1KYC+qqKwm/yS
VdjQ5MJlp5woGDGtl04ExyOw1NXaqaMidExGktq7rl528wtn05tvn3PT6W7LdpwM
fook6Qs56Z6F+EVi1ZTY03d4aqp5NKhb5bFaKBsDJCtz+NpOSYxwa0BQZICYnKXy
ZXj8gN0s7dd9FfxGq+AVd5JKaXT18MxpIPW+pIw83ZL2QblH02L4imf9Lo5BkV7Z
0luMQMN3rsXNqINrbOa/JTrEyJwn0V2D4UwOrdJrsqN6Q1mx3Sqaa2QhVNYbBAtb
CdY8SyicB3sD8UaVlHqTB1jb2F6klst5ZTftxyDC9GT/088Zjb5AEqyeCUpItuI+
590GautyGVnF60sEHMK4
=VJCZ
-----END PGP SIGNATURE-----

--bCvbWEJMulW7EirtrJbTqmj5j1SVXs2Fc--


--===============8721980942217411242==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8721980942217411242==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 11:08:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:08:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhPO-0008MJ-F0; Fri, 07 Nov 2014 11:08:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XmhPM-0008M2-Sq
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 11:08:49 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	B4/59-02698-048AC545; Fri, 07 Nov 2014 11:08:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415358525!12030044!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31505 invoked from network); 7 Nov 2014 11:08:45 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 11:08:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 07 Nov 2014 11:08:45 +0000
Message-Id: <545CB64E02000078000459CD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 07 Nov 2014 11:08:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
In-Reply-To: <545C9E97.4040800@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.11.14 at 11:27, <tiejun.chen@intel.com> wrote:
> Are you saying Xen restrict some BDFs specific to emulate some devices? 
> But I don't see these associated codes.

I didn't say so. All I said that some of the SBDFs are being used by
them.

>>> --- a/xen/include/xen/iommu.h
>>> +++ b/xen/include/xen/iommu.h
>>> @@ -158,14 +158,14 @@ struct iommu_ops {
>>>        void (*crash_shutdown)(void);
>>>        void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int page_count);
>>>        void (*iotlb_flush_all)(struct domain *d);
>>> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
>>> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct domain *, void *);
>>>        void (*dump_p2m_table)(struct domain *d);
>>>    };
>>>
>>>    void iommu_suspend(void);
>>>    void iommu_resume(void);
>>>    void iommu_crash_shutdown(void);
>>> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain *, void *);
>>
>> I don't see why these generic interfaces would need to change;
>> the only thing that would seem to need changing is the callback
>> function (and of course the context passed to it).
> 
> I'm not 100% sure if we can call current->domain in all scenarios. If 
> you can help me confirm this I'd really like to remove this change :) 
> Now I assume this should be true as follows:

Which is wrong, and not what I said. Instead you should pass the
domain as part of the context that gets made available to the
callback function.

> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1540,6 +1540,34 @@ int iommu_do_pci_domctl(
>           }
>           break;
> 
> +    case XEN_DOMCTL_set_rdm:
> +    {
> +        struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
> +        struct xen_guest_pcidev_info *pcidevs;
> +        int i;
> +
> +        pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
> +                                domctl->u.set_rdm.num_pcidevs);
> +        if ( pcidevs == NULL )
> +        {
> +            return -ENOMEM;
> +        }
> +
> +        for ( i = 0; i < xdsr->num_pcidevs; ++i )
> +        {
> +            if ( __copy_from_guest_offset(pcidevs, xdsr->pcidevs, i, 1) )
> +            {
> +                xfree(pcidevs);
> +                return -EFAULT;
> +            }
> +        }

I don't see the need for a loop here. And you definitely can't use the
double-underscore-prefixed variant the way you do.

> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -90,6 +90,10 @@ struct hvm_domain {
>       /* Cached CF8 for guest PCI config cycles */
>       uint32_t                pci_cf8;
> 
> +    uint32_t                pci_rdmforce;

I still don't see why this is a uint32_t.

> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -484,6 +484,24 @@ struct xen_domctl_assign_device {
>   typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
> 
> +struct xen_guest_pcidev_info {
> +    uint8_t func;
> +    uint8_t dev;
> +    uint8_t bus;
> +    int domain;
> +    int rdmforce;
> +};

Please see struct physdev_pci_device_add for how to properly and
space efficiently express what you need. And of course I'd expect
the code to actually use all fields you specify here - neither domain
(which really ought to be named segment if it is what I think it is
meant to be) nor rdmforce are being used anywhere. Plus - again -
just "force" would be sufficient as a name, provided the field is
needed at all.

> +struct xen_domctl_set_rdm {
> +    uint32_t  pci_rdmforce;

Same comment as on the field added to "struct hvm_domain".

> +    uint32_t  num_pcidevs;
> +    XEN_GUEST_HANDLE(xen_guest_pcidev_info_t) pcidevs;

Did you _at all_ look at any of the other domctls when adding this?
There's not a single use of XEN_GUEST_HANDLE() in the whole file.

> @@ -1118,7 +1137,8 @@ struct xen_domctl {
>           struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>           struct xen_domctl_vnuma             vnuma;
>           struct xen_domctl_psr_cmt_op        psr_cmt_op;
> -        uint8_t                             pad[128];
> +        struct xen_domctl_set_rdm           set_rdm;
> +        uint8_t                             pad[112];

Why are you altering the padding size here?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:08:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:08:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhPO-0008MJ-F0; Fri, 07 Nov 2014 11:08:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XmhPM-0008M2-Sq
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 11:08:49 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	B4/59-02698-048AC545; Fri, 07 Nov 2014 11:08:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415358525!12030044!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31505 invoked from network); 7 Nov 2014 11:08:45 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 11:08:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 07 Nov 2014 11:08:45 +0000
Message-Id: <545CB64E02000078000459CD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 07 Nov 2014 11:08:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<544F49F9.3070208@intel.com>
	<544F78B80200007800042B95@mail.emea.novell.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
In-Reply-To: <545C9E97.4040800@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.11.14 at 11:27, <tiejun.chen@intel.com> wrote:
> Are you saying Xen restrict some BDFs specific to emulate some devices? 
> But I don't see these associated codes.

I didn't say so. All I said that some of the SBDFs are being used by
them.

>>> --- a/xen/include/xen/iommu.h
>>> +++ b/xen/include/xen/iommu.h
>>> @@ -158,14 +158,14 @@ struct iommu_ops {
>>>        void (*crash_shutdown)(void);
>>>        void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int page_count);
>>>        void (*iotlb_flush_all)(struct domain *d);
>>> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
>>> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct domain *, void *);
>>>        void (*dump_p2m_table)(struct domain *d);
>>>    };
>>>
>>>    void iommu_suspend(void);
>>>    void iommu_resume(void);
>>>    void iommu_crash_shutdown(void);
>>> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain *, void *);
>>
>> I don't see why these generic interfaces would need to change;
>> the only thing that would seem to need changing is the callback
>> function (and of course the context passed to it).
> 
> I'm not 100% sure if we can call current->domain in all scenarios. If 
> you can help me confirm this I'd really like to remove this change :) 
> Now I assume this should be true as follows:

Which is wrong, and not what I said. Instead you should pass the
domain as part of the context that gets made available to the
callback function.

> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1540,6 +1540,34 @@ int iommu_do_pci_domctl(
>           }
>           break;
> 
> +    case XEN_DOMCTL_set_rdm:
> +    {
> +        struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
> +        struct xen_guest_pcidev_info *pcidevs;
> +        int i;
> +
> +        pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
> +                                domctl->u.set_rdm.num_pcidevs);
> +        if ( pcidevs == NULL )
> +        {
> +            return -ENOMEM;
> +        }
> +
> +        for ( i = 0; i < xdsr->num_pcidevs; ++i )
> +        {
> +            if ( __copy_from_guest_offset(pcidevs, xdsr->pcidevs, i, 1) )
> +            {
> +                xfree(pcidevs);
> +                return -EFAULT;
> +            }
> +        }

I don't see the need for a loop here. And you definitely can't use the
double-underscore-prefixed variant the way you do.

> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -90,6 +90,10 @@ struct hvm_domain {
>       /* Cached CF8 for guest PCI config cycles */
>       uint32_t                pci_cf8;
> 
> +    uint32_t                pci_rdmforce;

I still don't see why this is a uint32_t.

> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -484,6 +484,24 @@ struct xen_domctl_assign_device {
>   typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
> 
> +struct xen_guest_pcidev_info {
> +    uint8_t func;
> +    uint8_t dev;
> +    uint8_t bus;
> +    int domain;
> +    int rdmforce;
> +};

Please see struct physdev_pci_device_add for how to properly and
space efficiently express what you need. And of course I'd expect
the code to actually use all fields you specify here - neither domain
(which really ought to be named segment if it is what I think it is
meant to be) nor rdmforce are being used anywhere. Plus - again -
just "force" would be sufficient as a name, provided the field is
needed at all.

> +struct xen_domctl_set_rdm {
> +    uint32_t  pci_rdmforce;

Same comment as on the field added to "struct hvm_domain".

> +    uint32_t  num_pcidevs;
> +    XEN_GUEST_HANDLE(xen_guest_pcidev_info_t) pcidevs;

Did you _at all_ look at any of the other domctls when adding this?
There's not a single use of XEN_GUEST_HANDLE() in the whole file.

> @@ -1118,7 +1137,8 @@ struct xen_domctl {
>           struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>           struct xen_domctl_vnuma             vnuma;
>           struct xen_domctl_psr_cmt_op        psr_cmt_op;
> -        uint8_t                             pad[128];
> +        struct xen_domctl_set_rdm           set_rdm;
> +        uint8_t                             pad[112];

Why are you altering the padding size here?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:11:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:11:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhSL-00009c-1F; Fri, 07 Nov 2014 11:11:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmhSJ-00008z-UK
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 11:11:52 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	4D/6C-09284-7F8AC545; Fri, 07 Nov 2014 11:11:51 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415358710!7352668!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23528 invoked from network); 7 Nov 2014 11:11:50 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-9.tower-31.messagelabs.com with SMTP;
	7 Nov 2014 11:11:50 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 82A0766;
	Fri,  7 Nov 2014 05:11:40 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 359A95FAD7;
	Fri,  7 Nov 2014 05:11:38 -0600 (CST)
Received: from localhost (unknown [10.1.17.197])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id E010213F91E;
	Fri,  7 Nov 2014 05:11:33 -0600 (CST)
Date: Fri, 7 Nov 2014 11:11:28 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107111126.GB21875@localhost>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141107110524.GA21875@localhost>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 11:05:25AM +0000, Catalin Marinas wrote:
> BTW, drivers/xen/swiotlb-xen.c needs something like:
> 
>         dma_addr_t dev_addr = xen_phys_to_bus(phys_to_dma(phys));
> 
> phys != bus address.

Wrong place, what I meant is when calling:

        xen_dma_unmap_page(hwdev, phys_to_dma(paddr), size, dir, attrs);

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:11:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:11:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhSL-00009c-1F; Fri, 07 Nov 2014 11:11:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmhSJ-00008z-UK
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 11:11:52 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	4D/6C-09284-7F8AC545; Fri, 07 Nov 2014 11:11:51 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415358710!7352668!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23528 invoked from network); 7 Nov 2014 11:11:50 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-9.tower-31.messagelabs.com with SMTP;
	7 Nov 2014 11:11:50 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 82A0766;
	Fri,  7 Nov 2014 05:11:40 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 359A95FAD7;
	Fri,  7 Nov 2014 05:11:38 -0600 (CST)
Received: from localhost (unknown [10.1.17.197])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id E010213F91E;
	Fri,  7 Nov 2014 05:11:33 -0600 (CST)
Date: Fri, 7 Nov 2014 11:11:28 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107111126.GB21875@localhost>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141107110524.GA21875@localhost>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 11:05:25AM +0000, Catalin Marinas wrote:
> BTW, drivers/xen/swiotlb-xen.c needs something like:
> 
>         dma_addr_t dev_addr = xen_phys_to_bus(phys_to_dma(phys));
> 
> phys != bus address.

Wrong place, what I meant is when calling:

        xen_dma_unmap_page(hwdev, phys_to_dma(paddr), size, dir, attrs);

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:19:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhZU-0000MZ-4k; Fri, 07 Nov 2014 11:19: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@citrix.com>) id 1XmhZS-0000MT-1c
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 11:19:14 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	1B/62-22819-1BAAC545; Fri, 07 Nov 2014 11:19:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415359151!11069208!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29946 invoked from network); 7 Nov 2014 11:19:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:19:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="190519585"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 06:19:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmhZN-0001wP-UD;
	Fri, 07 Nov 2014 11:19:09 +0000
Date: Fri, 7 Nov 2014 11:19:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Steven Haigh <netwiz@crc.id.au>
In-Reply-To: <545BFBB3.9010303@crc.id.au>
Message-ID: <alpine.DEB.2.02.1411071111430.22875@kaball.uk.xensource.com>
References: <545BFBB3.9010303@crc.id.au>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] pv-grub and grub.conf locations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Steven Haigh wrote:
> Hi Stefano,
> 
> Sorry to hassle you directly - but I'm trying to figure out a use case
> of pv-grub to replace most pygrub configurations.

No worries. I CC'ed xen-devel, because I think that this is an
interesting question that could be useful to other people too.


> I have two main locations where the grub config may live:
> 	1) (hd0)/boot/grub/grub.conf or
> 	2) (hd0,0)/boot/grub/grub.conf
> 
> This depends if the DomU is created by something like the debian
> installer which refuses to install to a 'whole disk' - or say my EL6
> kickstart which installs to /dev/xvda as ext4 (which is easier to manage).
> 
> From what I've been reading, there is no way to pass both of these to
> pv-grub and let it deal with whichever one exists.
> 
> Interestingly, pygrub seems to search all paths to make this work - ie
> you only need to specify:
> 	bootloader = 'pygrub'
> 
> As I'm trying to generate generic config files, it makes life much
> harder to implement pv-grub as the loader (even though its preferred).
> 
> Any thoughts on this?

Unfortunately it doesn't look like there is a way to do that at the
moment. But I agree it would be useful and we might be able to make it
work for the next release (Xen 4.6).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:19:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhZU-0000MZ-4k; Fri, 07 Nov 2014 11:19: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@citrix.com>) id 1XmhZS-0000MT-1c
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 11:19:14 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	1B/62-22819-1BAAC545; Fri, 07 Nov 2014 11:19:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415359151!11069208!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29946 invoked from network); 7 Nov 2014 11:19:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:19:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="190519585"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 06:19:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmhZN-0001wP-UD;
	Fri, 07 Nov 2014 11:19:09 +0000
Date: Fri, 7 Nov 2014 11:19:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Steven Haigh <netwiz@crc.id.au>
In-Reply-To: <545BFBB3.9010303@crc.id.au>
Message-ID: <alpine.DEB.2.02.1411071111430.22875@kaball.uk.xensource.com>
References: <545BFBB3.9010303@crc.id.au>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] pv-grub and grub.conf locations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Steven Haigh wrote:
> Hi Stefano,
> 
> Sorry to hassle you directly - but I'm trying to figure out a use case
> of pv-grub to replace most pygrub configurations.

No worries. I CC'ed xen-devel, because I think that this is an
interesting question that could be useful to other people too.


> I have two main locations where the grub config may live:
> 	1) (hd0)/boot/grub/grub.conf or
> 	2) (hd0,0)/boot/grub/grub.conf
> 
> This depends if the DomU is created by something like the debian
> installer which refuses to install to a 'whole disk' - or say my EL6
> kickstart which installs to /dev/xvda as ext4 (which is easier to manage).
> 
> From what I've been reading, there is no way to pass both of these to
> pv-grub and let it deal with whichever one exists.
> 
> Interestingly, pygrub seems to search all paths to make this work - ie
> you only need to specify:
> 	bootloader = 'pygrub'
> 
> As I'm trying to generate generic config files, it makes life much
> harder to implement pv-grub as the loader (even though its preferred).
> 
> Any thoughts on this?

Unfortunately it doesn't look like there is a way to do that at the
moment. But I agree it would be useful and we might be able to make it
work for the next release (Xen 4.6).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:22:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhcE-0000Tu-N5; Fri, 07 Nov 2014 11:22:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1XmhcD-0000Tn-7o
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:22:05 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	62/BE-02696-C5BAC545; Fri, 07 Nov 2014 11:22:04 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415359322!8697348!1
X-Originating-IP: [209.85.223.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16849 invoked from network); 7 Nov 2014 11:22:03 -0000
Received: from mail-ie0-f176.google.com (HELO mail-ie0-f176.google.com)
	(209.85.223.176)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:22:03 -0000
Received: by mail-ie0-f176.google.com with SMTP id rd18so4787931iec.7
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 03:22:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:mime-version:content-transfer-encoding;
	bh=er0bTR6jIMLDk775ytUFqQhHscwf9lpXNe6QpckofBc=;
	b=w8wpgCg6Dkzki82u9teqCZO/p/bv+2ZSpeAFcBvx5w8puOro9dWDVzi5id04fCSs5o
	jAZmRdQCGxvZ3Kyq5r9rOLGWNfhrgJ77TdBA0aEYopzb3lg5bJ1VBCGswQVgR7FqrtpY
	CkNiThF4HPXWmWPlLjJZMSYnY1YRBHWVf5btAqzMqoJCKq55JJamhqAJlH9p0uA5QBk5
	yoA18qcdWnU0adydeY8WIQEbApK1z08GfMyQrNYzcm3X25n29Ol8eeodk/vODMLrvF1L
	E8yEeFLd+TO7UgIaJL6lyLryRYIOgDOBAbCzLhFisTJVT8hTVEhxmxQXSshq5UycbJC9
	eQ+w==
X-Received: by 10.107.136.94 with SMTP id k91mr12042235iod.43.1415359322566;
	Fri, 07 Nov 2014 03:22:02 -0800 (PST)
Received: from [172.26.52.131] ([172.26.52.131])
	by mx.google.com with ESMTPSA id v6sm543891igk.10.2014.11.07.03.22.01
	for <multiple recipients>
	(version=SSLv3 cipher=RC4-SHA bits=128/128);
	Fri, 07 Nov 2014 03:22:01 -0800 (PST)
Message-ID: <1415359320.13896.105.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Zoltan Kiss <zoltan.kiss@linaro.org>
Date: Fri, 07 Nov 2014 03:22:00 -0800
In-Reply-To: <545C9013.1090406@linaro.org>
References: <20141106214940.GD44162@ubuntu-hedt> <545C9013.1090406@linaro.org>
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Stefan Bader <stefan.bader@canonical.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-07 at 09:25 +0000, Zoltan Kiss wrote:

Please do not top post.

> Hi,
> 
> AFAIK in this scenario your skb frag is wrong. The page pointer should 
> point to the original compound page (not a member of it), and offset 
> should be set accordingly.
> For example, if your compound page is 16K (4 page), then the page 
> pointer should point to the first page, and if the data starts at the 
> 3rd page, then offset should be >8K

This is not accurate.

This BUG_ON() is wrong.

It should instead be :

BUG_ON(len + offset > PAGE_SIZE<<compound_order(compound_head(page)));

splice() code can generate such cases.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:22:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhcE-0000Tu-N5; Fri, 07 Nov 2014 11:22:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1XmhcD-0000Tn-7o
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:22:05 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	62/BE-02696-C5BAC545; Fri, 07 Nov 2014 11:22:04 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415359322!8697348!1
X-Originating-IP: [209.85.223.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16849 invoked from network); 7 Nov 2014 11:22:03 -0000
Received: from mail-ie0-f176.google.com (HELO mail-ie0-f176.google.com)
	(209.85.223.176)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:22:03 -0000
Received: by mail-ie0-f176.google.com with SMTP id rd18so4787931iec.7
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 03:22:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:mime-version:content-transfer-encoding;
	bh=er0bTR6jIMLDk775ytUFqQhHscwf9lpXNe6QpckofBc=;
	b=w8wpgCg6Dkzki82u9teqCZO/p/bv+2ZSpeAFcBvx5w8puOro9dWDVzi5id04fCSs5o
	jAZmRdQCGxvZ3Kyq5r9rOLGWNfhrgJ77TdBA0aEYopzb3lg5bJ1VBCGswQVgR7FqrtpY
	CkNiThF4HPXWmWPlLjJZMSYnY1YRBHWVf5btAqzMqoJCKq55JJamhqAJlH9p0uA5QBk5
	yoA18qcdWnU0adydeY8WIQEbApK1z08GfMyQrNYzcm3X25n29Ol8eeodk/vODMLrvF1L
	E8yEeFLd+TO7UgIaJL6lyLryRYIOgDOBAbCzLhFisTJVT8hTVEhxmxQXSshq5UycbJC9
	eQ+w==
X-Received: by 10.107.136.94 with SMTP id k91mr12042235iod.43.1415359322566;
	Fri, 07 Nov 2014 03:22:02 -0800 (PST)
Received: from [172.26.52.131] ([172.26.52.131])
	by mx.google.com with ESMTPSA id v6sm543891igk.10.2014.11.07.03.22.01
	for <multiple recipients>
	(version=SSLv3 cipher=RC4-SHA bits=128/128);
	Fri, 07 Nov 2014 03:22:01 -0800 (PST)
Message-ID: <1415359320.13896.105.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Zoltan Kiss <zoltan.kiss@linaro.org>
Date: Fri, 07 Nov 2014 03:22:00 -0800
In-Reply-To: <545C9013.1090406@linaro.org>
References: <20141106214940.GD44162@ubuntu-hedt> <545C9013.1090406@linaro.org>
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Stefan Bader <stefan.bader@canonical.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-07 at 09:25 +0000, Zoltan Kiss wrote:

Please do not top post.

> Hi,
> 
> AFAIK in this scenario your skb frag is wrong. The page pointer should 
> point to the original compound page (not a member of it), and offset 
> should be set accordingly.
> For example, if your compound page is 16K (4 page), then the page 
> pointer should point to the first page, and if the data starts at the 
> 3rd page, then offset should be >8K

This is not accurate.

This BUG_ON() is wrong.

It should instead be :

BUG_ON(len + offset > PAGE_SIZE<<compound_order(compound_head(page)));

splice() code can generate such cases.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:31:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11: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.xen.org>)
	id 1XmhlJ-0000g1-QK; Fri, 07 Nov 2014 11:31:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmhlI-0000fw-Ct
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:31:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2A/A4-24532-F8DAC545; Fri, 07 Nov 2014 11:31:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415359885!12163703!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10551 invoked from network); 7 Nov 2014 11:31:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:31:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="190521998"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 06:31:24 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmhlE-0002Aj-D0;
	Fri, 07 Nov 2014 11:31:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmhlE-0004a5-28;
	Fri, 07 Nov 2014 11:31:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21596.44427.832657.366011@mariner.uk.xensource.com>
Date: Fri, 7 Nov 2014 11:31:23 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1415353248.2030.5.camel@citrix.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
	<21595.24771.302806.319751@mariner.uk.xensource.com>
	<1415353248.2030.5.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> On Thu, 2014-11-06 at 11:51 +0000, Ian Jackson wrote:
> > My change to the host property in the osstest hostdb didn't have the
> > intended effect (or, any relevant effect).  I'm fixing this but it
> > will involve a change to osstest.
> 
> FYI judging from
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31393/test-amd64-i386-pair/info.html
> scape-moth (and presumably worm-moth) suffer from this issue too:

Hrm.  I have added the relevant host property to the moths too.  My
osstest change got a push so results should soon start to include the
`swiotlb=26422'.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:31:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11: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.xen.org>)
	id 1XmhlJ-0000g1-QK; Fri, 07 Nov 2014 11:31:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmhlI-0000fw-Ct
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:31:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2A/A4-24532-F8DAC545; Fri, 07 Nov 2014 11:31:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415359885!12163703!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10551 invoked from network); 7 Nov 2014 11:31:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:31:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="190521998"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 06:31:24 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmhlE-0002Aj-D0;
	Fri, 07 Nov 2014 11:31:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmhlE-0004a5-28;
	Fri, 07 Nov 2014 11:31:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21596.44427.832657.366011@mariner.uk.xensource.com>
Date: Fri, 7 Nov 2014 11:31:23 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1415353248.2030.5.camel@citrix.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
	<21595.24771.302806.319751@mariner.uk.xensource.com>
	<1415353248.2030.5.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> On Thu, 2014-11-06 at 11:51 +0000, Ian Jackson wrote:
> > My change to the host property in the osstest hostdb didn't have the
> > intended effect (or, any relevant effect).  I'm fixing this but it
> > will involve a change to osstest.
> 
> FYI judging from
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31393/test-amd64-i386-pair/info.html
> scape-moth (and presumably worm-moth) suffer from this issue too:

Hrm.  I have added the relevant host property to the moths too.  My
osstest change got a push so results should soon start to include the
`swiotlb=26422'.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:37:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:37:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhrE-0000qs-Jw; Fri, 07 Nov 2014 11:37:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmhrD-0000qn-DD
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:37:35 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	C7/EC-09284-EFEAC545; Fri, 07 Nov 2014 11:37:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415360252!11036609!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23744 invoked from network); 7 Nov 2014 11:37:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:37:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="189095969"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 06:37:24 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xmhr2-0002Fn-9E;
	Fri, 07 Nov 2014 11:37:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xmhr2-0004ae-0D;
	Fri, 07 Nov 2014 11:37:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21596.44787.649293.746269@mariner.uk.xensource.com>
Date: Fri, 7 Nov 2014 11:37:23 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Russ mentioned that he was expecting us to have a test day next week.
Is that still on; do you want to cut an RC soon ?  If you let me know
ASAP we can still do that today, I think.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:37:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:37:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmhrE-0000qs-Jw; Fri, 07 Nov 2014 11:37:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmhrD-0000qn-DD
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:37:35 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	C7/EC-09284-EFEAC545; Fri, 07 Nov 2014 11:37:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415360252!11036609!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23744 invoked from network); 7 Nov 2014 11:37:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 11:37:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="189095969"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 06:37:24 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xmhr2-0002Fn-9E;
	Fri, 07 Nov 2014 11:37:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xmhr2-0004ae-0D;
	Fri, 07 Nov 2014 11:37:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21596.44787.649293.746269@mariner.uk.xensource.com>
Date: Fri, 7 Nov 2014 11:37:23 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Russ mentioned that he was expecting us to have a test day next week.
Is that still on; do you want to cut an RC soon ?  If you let me know
ASAP we can still do that today, I think.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:41:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:41:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmhuq-0000yf-7b; Fri, 07 Nov 2014 11:41:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1Xmhun-0000yY-PM
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 11:41:18 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	01/F6-29352-DDFAC545; Fri, 07 Nov 2014 11:41:17 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415360466!11111404!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNjQ0OTUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23919 invoked from network); 7 Nov 2014 11:41:06 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-4.tower-206.messagelabs.com with SMTP;
	7 Nov 2014 11:41:06 -0000
Received: from [10.1.1.186] (dhcp-10-1-1-186.lan.crc.id.au [10.1.1.186])
	by mail.crc.id.au (Postfix) with ESMTPSA id DAC18367736;
	Fri,  7 Nov 2014 22:40:56 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1415360456; bh=Qyo8IxtqZCT8XS3ybn37RlRFW4Dtn17265T59rIwSOQ=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=JV832pUOMq7nlhlcTMLUSxN4Jx+FcmEMQUDStOspwLT5YFCP/M3E8htmzCl5F6BCE
	YuLHlugBI7Fw0iFDKaN8C+/39X6p4OpZU0HmY/WS61jeRkAltXkjMZ0iMQEvPterEb
	VEm8BI67VK/qv2WvcUwhGuD4ezojJOozFmWFdLWE=
Message-ID: <545CAFC7.20501@crc.id.au>
Date: Fri, 07 Nov 2014 22:40:55 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <545BFBB3.9010303@crc.id.au>
	<alpine.DEB.2.02.1411071111430.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411071111430.22875@kaball.uk.xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] pv-grub and grub.conf locations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5809313341831803676=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============5809313341831803676==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="Wjoho6aNJqOuQWEwaBaL2thTqmann8lQK"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Wjoho6aNJqOuQWEwaBaL2thTqmann8lQK
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 7/11/2014 10:19 PM, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Steven Haigh wrote:
>> Hi Stefano,
>>
>> Sorry to hassle you directly - but I'm trying to figure out a use case=

>> of pv-grub to replace most pygrub configurations.
>=20
> No worries. I CC'ed xen-devel, because I think that this is an
> interesting question that could be useful to other people too.
>=20
>=20
>> I have two main locations where the grub config may live:
>> 	1) (hd0)/boot/grub/grub.conf or
>> 	2) (hd0,0)/boot/grub/grub.conf
>>
>> This depends if the DomU is created by something like the debian
>> installer which refuses to install to a 'whole disk' - or say my EL6
>> kickstart which installs to /dev/xvda as ext4 (which is easier to mana=
ge).
>>
>> From what I've been reading, there is no way to pass both of these to
>> pv-grub and let it deal with whichever one exists.
>>
>> Interestingly, pygrub seems to search all paths to make this work - ie=

>> you only need to specify:
>> 	bootloader =3D 'pygrub'
>>
>> As I'm trying to generate generic config files, it makes life much
>> harder to implement pv-grub as the loader (even though its preferred).=

>>
>> Any thoughts on this?
>=20
> Unfortunately it doesn't look like there is a way to do that at the
> moment. But I agree it would be useful and we might be able to make it
> work for the next release (Xen 4.6).
>=20

Well, from digging through the grub 0.97 documentation, it *may* be
possible - however documentation on pv-grub seems to be very rare.

Interestingly, from the grub documentation:
13.3.11 find
=97 Command: find filename

    Search for the file name filename in all mountable partitions and
print the list of the devices which contain the file. The file name
filename should be an absolute file name like /boot/grub/stage1.

Also:
13.3.6 configfile
=97 Command: configfile file

    Load file as a configuration file.

It wouldn't be too hard to imagine a grub configuration script that
could be loaded (somehow) into the 'extra' section of the DomU config
that basically passes the output of 'find /boot/grub/grub.conf' to
configfile $result and uses that to boot.

This may actually be possible already - but I haven't found any
documentation that points to it or any configurations that have been
published.

Any further feedback from anyone who has seen this may help out...

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


--Wjoho6aNJqOuQWEwaBaL2thTqmann8lQK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJUXK/OAAoJEEGvNdV6fTHcSEYQAKdZMiTEdj/9He5TQaxlr1Ni
9LvctSEUYkFOJ0Wlzgh95XKhrpXidaDQ8lm481kC90KpgFrFvGU4H9WHPlvnDZ2f
BTwNP+NMHHP4hBjib85yE3dcWYFUNBbXDqtea2AYlcn6FWbaQYdyqrv2VAn04ebj
/NcYIb0HdnjdaYa7luasu2iDQ1YUt8mo2U/rDj8UXehIRxWvGqGbDrWbkHE6QHeY
N6eoB1gUcNfEKLycjQdretYM4zfMRsYlhn9GcyoNN3TJyjS/89zZOC1UP6yvUwfs
E1+GTiYQIaJ4DtoulMK21HKiFgAuQywNKKZqujSW3wqNbEptpe/5rQk7g9MVvwfM
a8N9ycFs8UhDuJY9QH2r9El9qfcwwWUXb3oAhHT1LRXOlmE1dCdo6DzF40ZorPMk
N69sWok+Ci2NOluZNbfs8jOv9KVqFqTLKOw4WFDsVZTshk/uhfEnVyhUah5BDnae
hFe2J6KkxgWWsrWB3bKPsCMtZekHDLheLWPk4+zl172uO9Yk1oST79B1s0ihv6Hr
EWRSV+ztJCWkufuwfLUL+7PfABMgzl/JQ+x4f/iFw10ILGyJelXaTjLQOvBVYfoy
ZGkNWXyzVMHgV9/XqU4zpcsYsLb7MVrVoAEUy/DFBsVuw7aJDi3+v/PeaWtXkiK8
Ns0lahRsBs1zS6nYo9yI
=BjMF
-----END PGP SIGNATURE-----

--Wjoho6aNJqOuQWEwaBaL2thTqmann8lQK--


--===============5809313341831803676==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5809313341831803676==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 11:41:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:41:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmhuq-0000yf-7b; Fri, 07 Nov 2014 11:41:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1Xmhun-0000yY-PM
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 11:41:18 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	01/F6-29352-DDFAC545; Fri, 07 Nov 2014 11:41:17 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415360466!11111404!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNjQ0OTUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23919 invoked from network); 7 Nov 2014 11:41:06 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-4.tower-206.messagelabs.com with SMTP;
	7 Nov 2014 11:41:06 -0000
Received: from [10.1.1.186] (dhcp-10-1-1-186.lan.crc.id.au [10.1.1.186])
	by mail.crc.id.au (Postfix) with ESMTPSA id DAC18367736;
	Fri,  7 Nov 2014 22:40:56 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1415360456; bh=Qyo8IxtqZCT8XS3ybn37RlRFW4Dtn17265T59rIwSOQ=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=JV832pUOMq7nlhlcTMLUSxN4Jx+FcmEMQUDStOspwLT5YFCP/M3E8htmzCl5F6BCE
	YuLHlugBI7Fw0iFDKaN8C+/39X6p4OpZU0HmY/WS61jeRkAltXkjMZ0iMQEvPterEb
	VEm8BI67VK/qv2WvcUwhGuD4ezojJOozFmWFdLWE=
Message-ID: <545CAFC7.20501@crc.id.au>
Date: Fri, 07 Nov 2014 22:40:55 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <545BFBB3.9010303@crc.id.au>
	<alpine.DEB.2.02.1411071111430.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411071111430.22875@kaball.uk.xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] pv-grub and grub.conf locations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5809313341831803676=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============5809313341831803676==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="Wjoho6aNJqOuQWEwaBaL2thTqmann8lQK"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Wjoho6aNJqOuQWEwaBaL2thTqmann8lQK
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 7/11/2014 10:19 PM, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Steven Haigh wrote:
>> Hi Stefano,
>>
>> Sorry to hassle you directly - but I'm trying to figure out a use case=

>> of pv-grub to replace most pygrub configurations.
>=20
> No worries. I CC'ed xen-devel, because I think that this is an
> interesting question that could be useful to other people too.
>=20
>=20
>> I have two main locations where the grub config may live:
>> 	1) (hd0)/boot/grub/grub.conf or
>> 	2) (hd0,0)/boot/grub/grub.conf
>>
>> This depends if the DomU is created by something like the debian
>> installer which refuses to install to a 'whole disk' - or say my EL6
>> kickstart which installs to /dev/xvda as ext4 (which is easier to mana=
ge).
>>
>> From what I've been reading, there is no way to pass both of these to
>> pv-grub and let it deal with whichever one exists.
>>
>> Interestingly, pygrub seems to search all paths to make this work - ie=

>> you only need to specify:
>> 	bootloader =3D 'pygrub'
>>
>> As I'm trying to generate generic config files, it makes life much
>> harder to implement pv-grub as the loader (even though its preferred).=

>>
>> Any thoughts on this?
>=20
> Unfortunately it doesn't look like there is a way to do that at the
> moment. But I agree it would be useful and we might be able to make it
> work for the next release (Xen 4.6).
>=20

Well, from digging through the grub 0.97 documentation, it *may* be
possible - however documentation on pv-grub seems to be very rare.

Interestingly, from the grub documentation:
13.3.11 find
=97 Command: find filename

    Search for the file name filename in all mountable partitions and
print the list of the devices which contain the file. The file name
filename should be an absolute file name like /boot/grub/stage1.

Also:
13.3.6 configfile
=97 Command: configfile file

    Load file as a configuration file.

It wouldn't be too hard to imagine a grub configuration script that
could be loaded (somehow) into the 'extra' section of the DomU config
that basically passes the output of 'find /boot/grub/grub.conf' to
configfile $result and uses that to boot.

This may actually be possible already - but I haven't found any
documentation that points to it or any configurations that have been
published.

Any further feedback from anyone who has seen this may help out...

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


--Wjoho6aNJqOuQWEwaBaL2thTqmann8lQK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJUXK/OAAoJEEGvNdV6fTHcSEYQAKdZMiTEdj/9He5TQaxlr1Ni
9LvctSEUYkFOJ0Wlzgh95XKhrpXidaDQ8lm481kC90KpgFrFvGU4H9WHPlvnDZ2f
BTwNP+NMHHP4hBjib85yE3dcWYFUNBbXDqtea2AYlcn6FWbaQYdyqrv2VAn04ebj
/NcYIb0HdnjdaYa7luasu2iDQ1YUt8mo2U/rDj8UXehIRxWvGqGbDrWbkHE6QHeY
N6eoB1gUcNfEKLycjQdretYM4zfMRsYlhn9GcyoNN3TJyjS/89zZOC1UP6yvUwfs
E1+GTiYQIaJ4DtoulMK21HKiFgAuQywNKKZqujSW3wqNbEptpe/5rQk7g9MVvwfM
a8N9ycFs8UhDuJY9QH2r9El9qfcwwWUXb3oAhHT1LRXOlmE1dCdo6DzF40ZorPMk
N69sWok+Ci2NOluZNbfs8jOv9KVqFqTLKOw4WFDsVZTshk/uhfEnVyhUah5BDnae
hFe2J6KkxgWWsrWB3bKPsCMtZekHDLheLWPk4+zl172uO9Yk1oST79B1s0ihv6Hr
EWRSV+ztJCWkufuwfLUL+7PfABMgzl/JQ+x4f/iFw10ILGyJelXaTjLQOvBVYfoy
ZGkNWXyzVMHgV9/XqU4zpcsYsLb7MVrVoAEUy/DFBsVuw7aJDi3+v/PeaWtXkiK8
Ns0lahRsBs1zS6nYo9yI
=BjMF
-----END PGP SIGNATURE-----

--Wjoho6aNJqOuQWEwaBaL2thTqmann8lQK--


--===============5809313341831803676==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5809313341831803676==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 11:48:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmi1M-0001AC-4E; Fri, 07 Nov 2014 11:48:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xmi1K-0001A7-V1
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 11:48:03 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	A4/8C-22737-271BC545; Fri, 07 Nov 2014 11:48:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415360881!11089535!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16233 invoked from network); 7 Nov 2014 11:48:01 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Nov 2014 11:48:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 07 Nov 2014 11:48:01 +0000
Message-Id: <545CBF820200007800045A27@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 07 Nov 2014 11:48:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <paul.durrant@citrix.com>
References: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.11.14 at 16:33, <paul.durrant@citrix.com> wrote:
> HVM guests have always been confined to using the domain callback
> via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
> which is an IOAPIC vector and is only used if the event channel is
> bound to vcpu 0.

Iirc the callback-via-vector method was specifically added to have a
way to spread the IRQ handling load. And even if this didn't work out
as intended, wouldn't simply setting a flag to avoid the restriction in


> This patch adds a new HVM op allowing a guest to specify a local
> APIC vector to use as an upcall notification for a specific vcpu.
> This therefore allows a guest which sets a vector for a vcpu
> other than 0 to then bind event channels to that vcpu.

So is there really a need for a per-vCPU vector value (rather than
a single domain wide one)?

> @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
>  
>      if ( is_hvm_pv_evtchn_vcpu(v) )
>          vcpu_kick(v);
> +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> +        hvm_set_upcall_irq(v);

The context code above your insertion is clearly not enforcing
vCPU 0 only; the code below this change is.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:48:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmi1M-0001AC-4E; Fri, 07 Nov 2014 11:48:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xmi1K-0001A7-V1
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 11:48:03 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	A4/8C-22737-271BC545; Fri, 07 Nov 2014 11:48:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415360881!11089535!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16233 invoked from network); 7 Nov 2014 11:48:01 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Nov 2014 11:48:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 07 Nov 2014 11:48:01 +0000
Message-Id: <545CBF820200007800045A27@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 07 Nov 2014 11:48:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <paul.durrant@citrix.com>
References: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.11.14 at 16:33, <paul.durrant@citrix.com> wrote:
> HVM guests have always been confined to using the domain callback
> via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
> which is an IOAPIC vector and is only used if the event channel is
> bound to vcpu 0.

Iirc the callback-via-vector method was specifically added to have a
way to spread the IRQ handling load. And even if this didn't work out
as intended, wouldn't simply setting a flag to avoid the restriction in


> This patch adds a new HVM op allowing a guest to specify a local
> APIC vector to use as an upcall notification for a specific vcpu.
> This therefore allows a guest which sets a vector for a vcpu
> other than 0 to then bind event channels to that vcpu.

So is there really a need for a per-vCPU vector value (rather than
a single domain wide one)?

> @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
>  
>      if ( is_hvm_pv_evtchn_vcpu(v) )
>          vcpu_kick(v);
> +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> +        hvm_set_upcall_irq(v);

The context code above your insertion is clearly not enforcing
vCPU 0 only; the code below this change is.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:59:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:59:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiBs-0001LL-92; Fri, 07 Nov 2014 11:58:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmiBr-0001LG-9a
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:58:55 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	FF/E4-02712-EF3BC545; Fri, 07 Nov 2014 11:58:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415361532!12025093!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20418 invoked from network); 7 Nov 2014 11:58:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 11:58:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7Bwl5X022655
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 11:58:48 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7Bwk1I021742
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Nov 2014 11:58:46 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA7Bwj8b011962; Fri, 7 Nov 2014 11:58:45 GMT
Received: from android-e228b54d98dcf47b.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 03:58:44 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <21596.44787.649293.746269@mariner.uk.xensource.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 07 Nov 2014 06:58:20 -0500
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <04F855BA-C5E1-4745-ADC6-ED04559755FC@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 7, 2014 6:37:23 AM EST, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>Russ mentioned that he was expecting us to have a test day next week.
>Is that still on; do you want to cut an RC soon ?  If you let me know
>ASAP we can still do that today, I think.
>

Yes or we can do it on Monday. I will be on IRC around 10am EST today - hopefully not too late for you.

>Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 11:59:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 11:59:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiBs-0001LL-92; Fri, 07 Nov 2014 11:58:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmiBr-0001LG-9a
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 11:58:55 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	FF/E4-02712-EF3BC545; Fri, 07 Nov 2014 11:58:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415361532!12025093!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20418 invoked from network); 7 Nov 2014 11:58:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 11:58:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7Bwl5X022655
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 11:58:48 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7Bwk1I021742
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Nov 2014 11:58:46 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA7Bwj8b011962; Fri, 7 Nov 2014 11:58:45 GMT
Received: from android-e228b54d98dcf47b.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 03:58:44 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <21596.44787.649293.746269@mariner.uk.xensource.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 07 Nov 2014 06:58:20 -0500
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <04F855BA-C5E1-4745-ADC6-ED04559755FC@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 7, 2014 6:37:23 AM EST, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>Russ mentioned that he was expecting us to have a test day next week.
>Is that still on; do you want to cut an RC soon ?  If you let me know
>ASAP we can still do that today, I think.
>

Yes or we can do it on Monday. I will be on IRC around 10am EST today - hopefully not too late for you.

>Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:00:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiCz-0001SI-03; Fri, 07 Nov 2014 12:00:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmiCv-0001PX-Tq
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:00:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E1/84-24532-144BC545; Fri, 07 Nov 2014 12:00:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415361599!12206365!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16890 invoked from network); 7 Nov 2014 12:00:00 -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;
	7 Nov 2014 12:00:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="189099616"
Message-ID: <545CB43D.4030404@citrix.com>
Date: Fri, 7 Nov 2014 11:59:57 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
In-Reply-To: <21596.44787.649293.746269@mariner.uk.xensource.com>
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/11/14 11:37, Ian Jackson wrote:
> Russ mentioned that he was expecting us to have a test day next week.
> Is that still on; do you want to cut an RC soon ?  If you let me know
> ASAP we can still do that today, I think.
>
> Ian.

Frankly, tagging an -RC2 before OSStest moves staging into master would
leave almost no delta between RC1 and RC2, and leave all of the pygrub
bugs still open.

My XenServer testing of all of this is currently on c/s 5c8dd034 (the
change to the MAINTAINERs file for hvmloader) and looking fine.

I would suggest waiting, (or force pushing, but I suspect that will be
objected-to).

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:00:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiCz-0001SX-Cm; Fri, 07 Nov 2014 12:00:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmiCx-0001RY-95
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:00:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AF/84-24532-244BC545; Fri, 07 Nov 2014 12:00:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415361599!12136777!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20271 invoked from network); 7 Nov 2014 12:00:00 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 12:00:00 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7BxsAm013174
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 11:59:54 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA7BxrvA014179
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Nov 2014 11:59:54 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7Bxri6023747; Fri, 7 Nov 2014 11:59:53 GMT
Received: from android-e228b54d98dcf47b.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 03:59:52 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <04F855BA-C5E1-4745-ADC6-ED04559755FC@oracle.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
	<04F855BA-C5E1-4745-ADC6-ED04559755FC@oracle.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 07 Nov 2014 06:59:31 -0500
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <BE059B0C-C22A-4290-B234-C6C3F4D6E803@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 7, 2014 6:58:20 AM EST, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>On November 7, 2014 6:37:23 AM EST, Ian Jackson
><Ian.Jackson@eu.citrix.com> wrote:
>>Russ mentioned that he was expecting us to have a test day next week.
>>Is that still on; do you want to cut an RC soon ?  If you let me know
>>ASAP we can still do that today, I think.
>>
>
>Yes or we can do it on Monday. I will be on IRC around 10am EST today -
>hopefully not too late for you.

And the Testday was to be on Wed the 12th.

>
>>Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:00:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiCz-0001SI-03; Fri, 07 Nov 2014 12:00:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XmiCv-0001PX-Tq
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:00:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E1/84-24532-144BC545; Fri, 07 Nov 2014 12:00:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415361599!12206365!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16890 invoked from network); 7 Nov 2014 12:00:00 -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;
	7 Nov 2014 12:00:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="189099616"
Message-ID: <545CB43D.4030404@citrix.com>
Date: Fri, 7 Nov 2014 11:59:57 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
In-Reply-To: <21596.44787.649293.746269@mariner.uk.xensource.com>
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/11/14 11:37, Ian Jackson wrote:
> Russ mentioned that he was expecting us to have a test day next week.
> Is that still on; do you want to cut an RC soon ?  If you let me know
> ASAP we can still do that today, I think.
>
> Ian.

Frankly, tagging an -RC2 before OSStest moves staging into master would
leave almost no delta between RC1 and RC2, and leave all of the pygrub
bugs still open.

My XenServer testing of all of this is currently on c/s 5c8dd034 (the
change to the MAINTAINERs file for hvmloader) and looking fine.

I would suggest waiting, (or force pushing, but I suspect that will be
objected-to).

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:00:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiCz-0001SX-Cm; Fri, 07 Nov 2014 12:00:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmiCx-0001RY-95
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:00:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AF/84-24532-244BC545; Fri, 07 Nov 2014 12:00:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415361599!12136777!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20271 invoked from network); 7 Nov 2014 12:00:00 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 12:00:00 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7BxsAm013174
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 11:59:54 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA7BxrvA014179
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Nov 2014 11:59:54 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7Bxri6023747; Fri, 7 Nov 2014 11:59:53 GMT
Received: from android-e228b54d98dcf47b.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 03:59:52 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <04F855BA-C5E1-4745-ADC6-ED04559755FC@oracle.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
	<04F855BA-C5E1-4745-ADC6-ED04559755FC@oracle.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 07 Nov 2014 06:59:31 -0500
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <BE059B0C-C22A-4290-B234-C6C3F4D6E803@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 7, 2014 6:58:20 AM EST, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>On November 7, 2014 6:37:23 AM EST, Ian Jackson
><Ian.Jackson@eu.citrix.com> wrote:
>>Russ mentioned that he was expecting us to have a test day next week.
>>Is that still on; do you want to cut an RC soon ?  If you let me know
>>ASAP we can still do that today, I think.
>>
>
>Yes or we can do it on Monday. I will be on IRC around 10am EST today -
>hopefully not too late for you.

And the Testday was to be on Wed the 12th.

>
>>Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:01:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:01:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiEa-0001kr-6J; Fri, 07 Nov 2014 12:01:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XmiEY-0001kc-Ou
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 12:01:42 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E9/7D-09842-6A4BC545; Fri, 07 Nov 2014 12:01:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415361700!4169400!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4649 invoked from network); 7 Nov 2014 12:01:41 -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;
	7 Nov 2014 12:01:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="189100125"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 07:01:35 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XmiER-0002fn-3u;
	Fri, 07 Nov 2014 12:01:35 +0000
Date: Fri, 7 Nov 2014 12:01:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Message-ID: <20141107120135.GB12109@zion.uk.xensource.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.campbell@eu.citrix.com, xen-devel@lists.xensource.com,
	wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] libxl: CODING_STYLE: Much new material
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 02:43:47PM +0000, Ian Jackson wrote:
[...]
> +  * Function calls which might fail (ie most function calls) are
> +    handled by putting the return/status value into a variable, and
> +    then checking it in a separate statement:
> +            evg->vdev = strdup(vdev);
> +            if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
> +
> +  * If a resource is freed in the main body of the function (for
> +    example, in a loop), the corresponding variable has to be reset to
> +    the sentinel at the point where it's freed.
> +

However useful this one is, in practice this looks very tedious to
enforce and easy to slip under reviewer's eyes.

> +Whether to use the `out' path for successful returns as well as error
> +returns is a matter of taste and convenience for the specific
> +function.  Not reusing the out path is fine if the duplicated function
> +exit code is only `CTX_UNLOCK; GC_FREE;' (or similar).
> +
> +If you reuse the `out' path for successful returns, there may be
> +resources which are to be returned to the caller rather than freed.
> +In that case you have to reset the local variable to `nothing here',
> +to avoid the resource being freed on the out path.  That resetting
> +should be done immediately after the resource value is stored at the
> +applicable _r function parameter (or equivalent).  Do not test `rc' in
> +the out section, to discover whether to free things.
> +
> +The uses of the single-line formatting in the examples above are
> +permitted exceptions to the usual libxl code formatting rules.
> +
> +
> +
> +IDEMPOTENT DATA STRUCTURE CONSTRUCTION/DESTRUCTION
> +--------------------------------------------------
> +
> +Nontrivial data structures (in structs) should come with an idempotent
> +_destroy function, which must free all resources associated with the

_dispose?

> +data structure (but not free the struct itself).
> +
> +Such a struct should also come with an _init function which
> +initialises the struct so that _destroy is a no-op.
> +

Is it worth mentioning that IDL-defined structures already have _dispose
and _init autogenerated, and _dispose is not idempotent at the moment?
In fact, the generated _dispose function explicitly poisons the
structure.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:01:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:01:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiEa-0001kr-6J; Fri, 07 Nov 2014 12:01:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XmiEY-0001kc-Ou
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 12:01:42 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E9/7D-09842-6A4BC545; Fri, 07 Nov 2014 12:01:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415361700!4169400!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4649 invoked from network); 7 Nov 2014 12:01:41 -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;
	7 Nov 2014 12:01:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,331,1413244800"; d="scan'208";a="189100125"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 07:01:35 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XmiER-0002fn-3u;
	Fri, 07 Nov 2014 12:01:35 +0000
Date: Fri, 7 Nov 2014 12:01:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Message-ID: <20141107120135.GB12109@zion.uk.xensource.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.campbell@eu.citrix.com, xen-devel@lists.xensource.com,
	wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] libxl: CODING_STYLE: Much new material
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 05, 2014 at 02:43:47PM +0000, Ian Jackson wrote:
[...]
> +  * Function calls which might fail (ie most function calls) are
> +    handled by putting the return/status value into a variable, and
> +    then checking it in a separate statement:
> +            evg->vdev = strdup(vdev);
> +            if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
> +
> +  * If a resource is freed in the main body of the function (for
> +    example, in a loop), the corresponding variable has to be reset to
> +    the sentinel at the point where it's freed.
> +

However useful this one is, in practice this looks very tedious to
enforce and easy to slip under reviewer's eyes.

> +Whether to use the `out' path for successful returns as well as error
> +returns is a matter of taste and convenience for the specific
> +function.  Not reusing the out path is fine if the duplicated function
> +exit code is only `CTX_UNLOCK; GC_FREE;' (or similar).
> +
> +If you reuse the `out' path for successful returns, there may be
> +resources which are to be returned to the caller rather than freed.
> +In that case you have to reset the local variable to `nothing here',
> +to avoid the resource being freed on the out path.  That resetting
> +should be done immediately after the resource value is stored at the
> +applicable _r function parameter (or equivalent).  Do not test `rc' in
> +the out section, to discover whether to free things.
> +
> +The uses of the single-line formatting in the examples above are
> +permitted exceptions to the usual libxl code formatting rules.
> +
> +
> +
> +IDEMPOTENT DATA STRUCTURE CONSTRUCTION/DESTRUCTION
> +--------------------------------------------------
> +
> +Nontrivial data structures (in structs) should come with an idempotent
> +_destroy function, which must free all resources associated with the

_dispose?

> +data structure (but not free the struct itself).
> +
> +Such a struct should also come with an _init function which
> +initialises the struct so that _destroy is a no-op.
> +

Is it worth mentioning that IDL-defined structures already have _dispose
and _init autogenerated, and _dispose is not idempotent at the moment?
In fact, the generated _dispose function explicitly poisons the
structure.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:16:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:16:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiST-00027V-Je; Fri, 07 Nov 2014 12:16:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XmiSS-00027Q-PQ
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:16:04 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	14/01-09284-308BC545; Fri, 07 Nov 2014 12:16:03 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415362563!11106814!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3329 invoked from network); 7 Nov 2014 12:16:03 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-16.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Nov 2014 12:16:03 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XmiSO-0005gY-Lp; Fri, 07 Nov 2014 12:16:00 +0000
Message-ID: <545CB7FF.8080003@canonical.com>
Date: Fri, 07 Nov 2014 13:15:59 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Eric Dumazet <eric.dumazet@gmail.com>, 
	Zoltan Kiss <zoltan.kiss@linaro.org>
References: <20141106214940.GD44162@ubuntu-hedt>	 <545C9013.1090406@linaro.org>
	<1415359320.13896.105.camel@edumazet-glaptop2.roam.corp.google.com>
In-Reply-To: <1415359320.13896.105.camel@edumazet-glaptop2.roam.corp.google.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3724587234809276439=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============3724587234809276439==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="opLDNHQ8k3gaC4DnE7Cxm0op4Sxl5uidl"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--opLDNHQ8k3gaC4DnE7Cxm0op4Sxl5uidl
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 07.11.2014 12:22, Eric Dumazet wrote:
> On Fri, 2014-11-07 at 09:25 +0000, Zoltan Kiss wrote:
>=20
> Please do not top post.
>=20
>> Hi,
>>
>> AFAIK in this scenario your skb frag is wrong. The page pointer should=
=20
>> point to the original compound page (not a member of it), and offset=20
>> should be set accordingly.
>> For example, if your compound page is 16K (4 page), then the page=20
>> pointer should point to the first page, and if the data starts at the =

>> 3rd page, then offset should be >8K
>=20
> This is not accurate.
>=20
> This BUG_ON() is wrong.
>=20
> It should instead be :
>=20
> BUG_ON(len + offset > PAGE_SIZE<<compound_order(compound_head(page)));

would that not have to be

BUG_ON((page-compound_head(page)*PAGE_SIZE)+offset+len >
PAGE_SIZE<<compound_order(compound_head(page)));

since offset is adjusted to start from the tail page in that case.
>=20
> splice() code can generate such cases.
>=20
>=20



--opLDNHQ8k3gaC4DnE7Cxm0op4Sxl5uidl
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

iQIcBAEBCgAGBQJUXLf/AAoJEOhnXe7L7s6jwO4QANXShxZX4Btb/XdJqqqOkOyZ
5yU4K4RucnZCx3x6XZp2QCRtNLThkUeIjQJg5n8SbGrAUYIPceuECAN4HeMIPKDC
GcV/g/o4fy/rklSNaHx+ovZo4fr6vvK6ddN8kdh9S2wydD3z6oLpBIvpFAG5zj2a
YfLa/VZJl/YBGcl/NgW02z+XsNyAn0chwVVk5sQiHY/+dQpbSW9t2sF9fKmevAlN
mmY2K+nTFSE5+urKuNZWBkbBdz+hJayyociJlD6E3OWWa6211LV+ZtUhdzJAX+6C
Galm0Tx18tSg3+RDIZkodUgup6D4rpCxR385CmXSllFT3ZO+ZY2qa6bQD0qGPBR+
KFQ3W4N66auQ/onV0RwxCMCC6oj0yIldCYjq+gQPPeJG2VPiSLAyw8vdr5tQalzD
auqXimkvj/9CsRyihQLbkq7qrhv5zeqb7THLxJQlG2SkKuwwZMGTkV5P9F4rYPxO
1ZKGoXe+5lPJgO18haH2fKNztD/dsR4OkTk6QHausxzRmKIe8d2AIuwJsAwG4X+V
mts94bySYCUY9lJUd6sh8qVtTRShg3QV2GtzTyZ0sU0srSaZEJkpWjHRJ4vqKexF
ovRi8EU5Mt4svRVi3nasM3knvG8ZWsdsxQ57HHIR6fQiPiDuke+9VfCZYl4WePNF
rWCPML3R458kxlDrhr0A
=Jb9a
-----END PGP SIGNATURE-----

--opLDNHQ8k3gaC4DnE7Cxm0op4Sxl5uidl--


--===============3724587234809276439==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3724587234809276439==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 12:16:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:16:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiST-00027V-Je; Fri, 07 Nov 2014 12:16:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XmiSS-00027Q-PQ
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:16:04 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	14/01-09284-308BC545; Fri, 07 Nov 2014 12:16:03 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415362563!11106814!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3329 invoked from network); 7 Nov 2014 12:16:03 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-16.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Nov 2014 12:16:03 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XmiSO-0005gY-Lp; Fri, 07 Nov 2014 12:16:00 +0000
Message-ID: <545CB7FF.8080003@canonical.com>
Date: Fri, 07 Nov 2014 13:15:59 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Eric Dumazet <eric.dumazet@gmail.com>, 
	Zoltan Kiss <zoltan.kiss@linaro.org>
References: <20141106214940.GD44162@ubuntu-hedt>	 <545C9013.1090406@linaro.org>
	<1415359320.13896.105.camel@edumazet-glaptop2.roam.corp.google.com>
In-Reply-To: <1415359320.13896.105.camel@edumazet-glaptop2.roam.corp.google.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3724587234809276439=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============3724587234809276439==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="opLDNHQ8k3gaC4DnE7Cxm0op4Sxl5uidl"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--opLDNHQ8k3gaC4DnE7Cxm0op4Sxl5uidl
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 07.11.2014 12:22, Eric Dumazet wrote:
> On Fri, 2014-11-07 at 09:25 +0000, Zoltan Kiss wrote:
>=20
> Please do not top post.
>=20
>> Hi,
>>
>> AFAIK in this scenario your skb frag is wrong. The page pointer should=
=20
>> point to the original compound page (not a member of it), and offset=20
>> should be set accordingly.
>> For example, if your compound page is 16K (4 page), then the page=20
>> pointer should point to the first page, and if the data starts at the =

>> 3rd page, then offset should be >8K
>=20
> This is not accurate.
>=20
> This BUG_ON() is wrong.
>=20
> It should instead be :
>=20
> BUG_ON(len + offset > PAGE_SIZE<<compound_order(compound_head(page)));

would that not have to be

BUG_ON((page-compound_head(page)*PAGE_SIZE)+offset+len >
PAGE_SIZE<<compound_order(compound_head(page)));

since offset is adjusted to start from the tail page in that case.
>=20
> splice() code can generate such cases.
>=20
>=20



--opLDNHQ8k3gaC4DnE7Cxm0op4Sxl5uidl
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

iQIcBAEBCgAGBQJUXLf/AAoJEOhnXe7L7s6jwO4QANXShxZX4Btb/XdJqqqOkOyZ
5yU4K4RucnZCx3x6XZp2QCRtNLThkUeIjQJg5n8SbGrAUYIPceuECAN4HeMIPKDC
GcV/g/o4fy/rklSNaHx+ovZo4fr6vvK6ddN8kdh9S2wydD3z6oLpBIvpFAG5zj2a
YfLa/VZJl/YBGcl/NgW02z+XsNyAn0chwVVk5sQiHY/+dQpbSW9t2sF9fKmevAlN
mmY2K+nTFSE5+urKuNZWBkbBdz+hJayyociJlD6E3OWWa6211LV+ZtUhdzJAX+6C
Galm0Tx18tSg3+RDIZkodUgup6D4rpCxR385CmXSllFT3ZO+ZY2qa6bQD0qGPBR+
KFQ3W4N66auQ/onV0RwxCMCC6oj0yIldCYjq+gQPPeJG2VPiSLAyw8vdr5tQalzD
auqXimkvj/9CsRyihQLbkq7qrhv5zeqb7THLxJQlG2SkKuwwZMGTkV5P9F4rYPxO
1ZKGoXe+5lPJgO18haH2fKNztD/dsR4OkTk6QHausxzRmKIe8d2AIuwJsAwG4X+V
mts94bySYCUY9lJUd6sh8qVtTRShg3QV2GtzTyZ0sU0srSaZEJkpWjHRJ4vqKexF
ovRi8EU5Mt4svRVi3nasM3knvG8ZWsdsxQ57HHIR6fQiPiDuke+9VfCZYl4WePNF
rWCPML3R458kxlDrhr0A
=Jb9a
-----END PGP SIGNATURE-----

--opLDNHQ8k3gaC4DnE7Cxm0op4Sxl5uidl--


--===============3724587234809276439==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3724587234809276439==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 12:18:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiUY-0002DU-4X; Fri, 07 Nov 2014 12:18:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1XmiUW-0002DN-Qm
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 12:18:13 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	7E/C9-08051-488BC545; Fri, 07 Nov 2014 12:18:12 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415362681!12059737!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDUyMTAgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23249 invoked from network); 7 Nov 2014 12:18:01 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-12.tower-27.messagelabs.com with SMTP;
	7 Nov 2014 12:18:01 -0000
Received: from [10.1.1.186] (dhcp-10-1-1-186.lan.crc.id.au [10.1.1.186])
	by mail.crc.id.au (Postfix) with ESMTPSA id 8794636773D;
	Fri,  7 Nov 2014 23:17:53 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1415362673; bh=4rQ4/y80JZZwjpDyyWktwFUZbR9lx6vJHU/W/8o3F4Y=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=BjTcj+91atB3IpvcdKXflROYwitvPYNm+uoUxVLm+/KfV8KlELDCZ/Lr/Inw1idVU
	GKhD1zc57IxBLoxRfq14TrhG7lyy3UzsIRrSzrp5xLXtLB+zi0RWZGzOFRjb3+vJdx
	/F1uBSh2Ee2PNJfa3/rWo3oSLSiwlU5RsSHuD3mQ=
Message-ID: <545CB877.4060807@crc.id.au>
Date: Fri, 07 Nov 2014 23:17:59 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <545BFBB3.9010303@crc.id.au>	<alpine.DEB.2.02.1411071111430.22875@kaball.uk.xensource.com>
	<545CAFC7.20501@crc.id.au>
In-Reply-To: <545CAFC7.20501@crc.id.au>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] pv-grub and grub.conf locations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0417105920607355346=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============0417105920607355346==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="4OnP8AraEDKmIrodTASDTwPXtSWQ8TIS6"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--4OnP8AraEDKmIrodTASDTwPXtSWQ8TIS6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On 7/11/2014 10:40 PM, Steven Haigh wrote:
> On 7/11/2014 10:19 PM, Stefano Stabellini wrote:
>> On Fri, 7 Nov 2014, Steven Haigh wrote:
>>> Hi Stefano,
>>>
>>> Sorry to hassle you directly - but I'm trying to figure out a use cas=
e
>>> of pv-grub to replace most pygrub configurations.
>>
>> No worries. I CC'ed xen-devel, because I think that this is an
>> interesting question that could be useful to other people too.
>>
>>
>>> I have two main locations where the grub config may live:
>>> 	1) (hd0)/boot/grub/grub.conf or
>>> 	2) (hd0,0)/boot/grub/grub.conf
>>>
>>> This depends if the DomU is created by something like the debian
>>> installer which refuses to install to a 'whole disk' - or say my EL6
>>> kickstart which installs to /dev/xvda as ext4 (which is easier to man=
age).
>>>
>>> From what I've been reading, there is no way to pass both of these to=

>>> pv-grub and let it deal with whichever one exists.
>>>
>>> Interestingly, pygrub seems to search all paths to make this work - i=
e
>>> you only need to specify:
>>> 	bootloader =3D 'pygrub'
>>>
>>> As I'm trying to generate generic config files, it makes life much
>>> harder to implement pv-grub as the loader (even though its preferred)=
=2E
>>>
>>> Any thoughts on this?
>>
>> Unfortunately it doesn't look like there is a way to do that at the
>> moment. But I agree it would be useful and we might be able to make it=

>> work for the next release (Xen 4.6).
>>
>=20
> Well, from digging through the grub 0.97 documentation, it *may* be
> possible - however documentation on pv-grub seems to be very rare.
>=20
> Interestingly, from the grub documentation:
> 13.3.11 find
> =97 Command: find filename
>=20
>     Search for the file name filename in all mountable partitions and
> print the list of the devices which contain the file. The file name
> filename should be an absolute file name like /boot/grub/stage1.
>=20
> Also:
> 13.3.6 configfile
> =97 Command: configfile file
>=20
>     Load file as a configuration file.
>=20
> It wouldn't be too hard to imagine a grub configuration script that
> could be loaded (somehow) into the 'extra' section of the DomU config
> that basically passes the output of 'find /boot/grub/grub.conf' to
> configfile $result and uses that to boot.
>=20
> This may actually be possible already - but I haven't found any
> documentation that points to it or any configurations that have been
> published.
>=20
> Any further feedback from anyone who has seen this may help out...

Interestingly, if this is a bug or not:

grubdom> debug
 Debug mode is turned on

grubdom> find /boot/grub/grub.conf

Error 15: File not found

grubdom>


--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


--4OnP8AraEDKmIrodTASDTwPXtSWQ8TIS6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJUXLh3AAoJEEGvNdV6fTHceV8QAINj4jsHB9PCf4AAw0dJi7/r
taZKOPN55BIihjfASCPdFHUCCyPXNPAUVt1NnRG3jai0K/O+1kr3rqOTaEqZUerT
xKuQzXlT6l3ORiPQxCAui9kqtAkdpcxI6jAPRnYBvQyUjW5QL4Ygy4owAtUCjtIn
wKZ1S7DV5Tmm3dDXQSfAU/LcrJzXw0EThPwIalcbFRsSkT4l/3OZMdXDYuJc07dQ
yT2xPN39/C4c4UGkkktFgk0EDX5fXacD5PCyCI7LRWRCQ9U/evahRqqQRj+hz6cD
DfccqXdGnqR13Ddpi6GolSO1fEz85oeXTRSIqDuu3+0SrlivfIVDf2cUwT3oq+VY
jOr7wbLkVzNd2gJw+5f3yusyxzksbR6R8J1FUo4iHySP3DIRaonqmnKApdYVJa65
a0DkxHKz+ErB1TJOHtML9RPe8RpCc6BBDcLYk6Psyx91ZH5S6laClSi3X2xXl0iP
bwQXZzr27h4+1tk6GESc/68UVqyxITVJStiwFNDGzeAYxm6sI8r3KAgULIlvbmj/
te0RYx6WXRfIy0SsPDumE+V+OGRwSYpcHyLodz2wSMtcx3wqDlh4jCpetKtMuElF
AVXq2iLKWy8to21p9eKFPzjRHANbVUrBXkCL/AQDT5EXlwVxXiAzY4sWT+wJOmKR
PPuhDZF1+DrPVD+QyAOj
=voLJ
-----END PGP SIGNATURE-----

--4OnP8AraEDKmIrodTASDTwPXtSWQ8TIS6--


--===============0417105920607355346==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0417105920607355346==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 12:18:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiUY-0002DU-4X; Fri, 07 Nov 2014 12:18:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1XmiUW-0002DN-Qm
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 12:18:13 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	7E/C9-08051-488BC545; Fri, 07 Nov 2014 12:18:12 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415362681!12059737!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDUyMTAgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23249 invoked from network); 7 Nov 2014 12:18:01 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-12.tower-27.messagelabs.com with SMTP;
	7 Nov 2014 12:18:01 -0000
Received: from [10.1.1.186] (dhcp-10-1-1-186.lan.crc.id.au [10.1.1.186])
	by mail.crc.id.au (Postfix) with ESMTPSA id 8794636773D;
	Fri,  7 Nov 2014 23:17:53 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1415362673; bh=4rQ4/y80JZZwjpDyyWktwFUZbR9lx6vJHU/W/8o3F4Y=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=BjTcj+91atB3IpvcdKXflROYwitvPYNm+uoUxVLm+/KfV8KlELDCZ/Lr/Inw1idVU
	GKhD1zc57IxBLoxRfq14TrhG7lyy3UzsIRrSzrp5xLXtLB+zi0RWZGzOFRjb3+vJdx
	/F1uBSh2Ee2PNJfa3/rWo3oSLSiwlU5RsSHuD3mQ=
Message-ID: <545CB877.4060807@crc.id.au>
Date: Fri, 07 Nov 2014 23:17:59 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <545BFBB3.9010303@crc.id.au>	<alpine.DEB.2.02.1411071111430.22875@kaball.uk.xensource.com>
	<545CAFC7.20501@crc.id.au>
In-Reply-To: <545CAFC7.20501@crc.id.au>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] pv-grub and grub.conf locations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0417105920607355346=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============0417105920607355346==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="4OnP8AraEDKmIrodTASDTwPXtSWQ8TIS6"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--4OnP8AraEDKmIrodTASDTwPXtSWQ8TIS6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On 7/11/2014 10:40 PM, Steven Haigh wrote:
> On 7/11/2014 10:19 PM, Stefano Stabellini wrote:
>> On Fri, 7 Nov 2014, Steven Haigh wrote:
>>> Hi Stefano,
>>>
>>> Sorry to hassle you directly - but I'm trying to figure out a use cas=
e
>>> of pv-grub to replace most pygrub configurations.
>>
>> No worries. I CC'ed xen-devel, because I think that this is an
>> interesting question that could be useful to other people too.
>>
>>
>>> I have two main locations where the grub config may live:
>>> 	1) (hd0)/boot/grub/grub.conf or
>>> 	2) (hd0,0)/boot/grub/grub.conf
>>>
>>> This depends if the DomU is created by something like the debian
>>> installer which refuses to install to a 'whole disk' - or say my EL6
>>> kickstart which installs to /dev/xvda as ext4 (which is easier to man=
age).
>>>
>>> From what I've been reading, there is no way to pass both of these to=

>>> pv-grub and let it deal with whichever one exists.
>>>
>>> Interestingly, pygrub seems to search all paths to make this work - i=
e
>>> you only need to specify:
>>> 	bootloader =3D 'pygrub'
>>>
>>> As I'm trying to generate generic config files, it makes life much
>>> harder to implement pv-grub as the loader (even though its preferred)=
=2E
>>>
>>> Any thoughts on this?
>>
>> Unfortunately it doesn't look like there is a way to do that at the
>> moment. But I agree it would be useful and we might be able to make it=

>> work for the next release (Xen 4.6).
>>
>=20
> Well, from digging through the grub 0.97 documentation, it *may* be
> possible - however documentation on pv-grub seems to be very rare.
>=20
> Interestingly, from the grub documentation:
> 13.3.11 find
> =97 Command: find filename
>=20
>     Search for the file name filename in all mountable partitions and
> print the list of the devices which contain the file. The file name
> filename should be an absolute file name like /boot/grub/stage1.
>=20
> Also:
> 13.3.6 configfile
> =97 Command: configfile file
>=20
>     Load file as a configuration file.
>=20
> It wouldn't be too hard to imagine a grub configuration script that
> could be loaded (somehow) into the 'extra' section of the DomU config
> that basically passes the output of 'find /boot/grub/grub.conf' to
> configfile $result and uses that to boot.
>=20
> This may actually be possible already - but I haven't found any
> documentation that points to it or any configurations that have been
> published.
>=20
> Any further feedback from anyone who has seen this may help out...

Interestingly, if this is a bug or not:

grubdom> debug
 Debug mode is turned on

grubdom> find /boot/grub/grub.conf

Error 15: File not found

grubdom>


--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


--4OnP8AraEDKmIrodTASDTwPXtSWQ8TIS6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJUXLh3AAoJEEGvNdV6fTHceV8QAINj4jsHB9PCf4AAw0dJi7/r
taZKOPN55BIihjfASCPdFHUCCyPXNPAUVt1NnRG3jai0K/O+1kr3rqOTaEqZUerT
xKuQzXlT6l3ORiPQxCAui9kqtAkdpcxI6jAPRnYBvQyUjW5QL4Ygy4owAtUCjtIn
wKZ1S7DV5Tmm3dDXQSfAU/LcrJzXw0EThPwIalcbFRsSkT4l/3OZMdXDYuJc07dQ
yT2xPN39/C4c4UGkkktFgk0EDX5fXacD5PCyCI7LRWRCQ9U/evahRqqQRj+hz6cD
DfccqXdGnqR13Ddpi6GolSO1fEz85oeXTRSIqDuu3+0SrlivfIVDf2cUwT3oq+VY
jOr7wbLkVzNd2gJw+5f3yusyxzksbR6R8J1FUo4iHySP3DIRaonqmnKApdYVJa65
a0DkxHKz+ErB1TJOHtML9RPe8RpCc6BBDcLYk6Psyx91ZH5S6laClSi3X2xXl0iP
bwQXZzr27h4+1tk6GESc/68UVqyxITVJStiwFNDGzeAYxm6sI8r3KAgULIlvbmj/
te0RYx6WXRfIy0SsPDumE+V+OGRwSYpcHyLodz2wSMtcx3wqDlh4jCpetKtMuElF
AVXq2iLKWy8to21p9eKFPzjRHANbVUrBXkCL/AQDT5EXlwVxXiAzY4sWT+wJOmKR
PPuhDZF1+DrPVD+QyAOj
=voLJ
-----END PGP SIGNATURE-----

--4OnP8AraEDKmIrodTASDTwPXtSWQ8TIS6--


--===============0417105920607355346==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0417105920607355346==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 12:21:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiXL-0002MG-NN; Fri, 07 Nov 2014 12:21:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XmiXJ-0002M3-UY
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:21:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CD/86-09842-139BC545; Fri, 07 Nov 2014 12:21:05 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415362864!12212756!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30248 invoked from network); 7 Nov 2014 12:21:04 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 12:21:04 -0000
Received: by mail-wg0-f48.google.com with SMTP id m15so3558533wgh.35
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 04:21:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=aC1MwzPFKqH0H7yx7g2FcjnH7A8HfEWEP8rMVKMZfvM=;
	b=QUGly1qazSA6C5l+3OD7xEKGUhUQHq1iq8mtmNf12npHiGti/0dulVxySkp7bgDWwk
	exosRei8tzHh7iAJ040ijRsIgwiTexeb1nzPGdlVNQ/AKq48EdM/HOnmJ2nLQShqADpK
	13q0viRNv+TKGF6JqU8fl/nQgbcfswWdY9WSRLJ6sqoyoLl8d82OYssTliwFE27/sZmG
	BmzdgLoKhkzEwr4ckguxDSTJbSvvS+DCbqfGU3GTq5Th9McTxiA6U4XURxBRnh9Oj+cl
	04FxRn7sGsTRCKxfMjezl4vlDdRR9T8LIoddWL+qniQQDup6ycPz0b9HYLkjQoRol+uG
	Jtlg==
X-Gm-Message-State: ALoCoQkBvPzHTcKJZmio1/K4mo2No+sqc4J87n7nRt4FSpMJNu3aYuWzjUpxw9HlLRohzVLmZ9BG
X-Received: by 10.180.91.137 with SMTP id ce9mr4603657wib.60.1415362864021;
	Fri, 07 Nov 2014 04:21:04 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id v10sm1836184wiy.21.2014.11.07.04.21.02
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 04:21:03 -0800 (PST)
Message-ID: <545CB92E.9050106@linaro.org>
Date: Fri, 07 Nov 2014 12:21:02 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>, 
	Eric Dumazet <eric.dumazet@gmail.com>
References: <20141106214940.GD44162@ubuntu-hedt>	 <545C9013.1090406@linaro.org>
	<1415359320.13896.105.camel@edumazet-glaptop2.roam.corp.google.com>
	<545CB7FF.8080003@canonical.com>
In-Reply-To: <545CB7FF.8080003@canonical.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 07/11/14 12:15, Stefan Bader wrote:
> On 07.11.2014 12:22, Eric Dumazet wrote:
>> On Fri, 2014-11-07 at 09:25 +0000, Zoltan Kiss wrote:
>>
>> Please do not top post.
>>
>>> Hi,
>>>
>>> AFAIK in this scenario your skb frag is wrong. The page pointer should
>>> point to the original compound page (not a member of it), and offset
>>> should be set accordingly.
>>> For example, if your compound page is 16K (4 page), then the page
>>> pointer should point to the first page, and if the data starts at the
>>> 3rd page, then offset should be >8K
>>
>> This is not accurate.
>>
>> This BUG_ON() is wrong.
>>
>> It should instead be :
>>
>> BUG_ON(len + offset > PAGE_SIZE<<compound_order(compound_head(page)));
>
> would that not have to be
>
> BUG_ON((page-compound_head(page)*PAGE_SIZE)+offset+len >
> PAGE_SIZE<<compound_order(compound_head(page)));

There should be a parentheses around "page-compound_head(page)".
>
> since offset is adjusted to start from the tail page in that case.
>>
>> splice() code can generate such cases.
>>
>>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:21:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmiXL-0002MG-NN; Fri, 07 Nov 2014 12:21:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XmiXJ-0002M3-UY
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:21:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CD/86-09842-139BC545; Fri, 07 Nov 2014 12:21:05 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415362864!12212756!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30248 invoked from network); 7 Nov 2014 12:21:04 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 12:21:04 -0000
Received: by mail-wg0-f48.google.com with SMTP id m15so3558533wgh.35
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 04:21:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=aC1MwzPFKqH0H7yx7g2FcjnH7A8HfEWEP8rMVKMZfvM=;
	b=QUGly1qazSA6C5l+3OD7xEKGUhUQHq1iq8mtmNf12npHiGti/0dulVxySkp7bgDWwk
	exosRei8tzHh7iAJ040ijRsIgwiTexeb1nzPGdlVNQ/AKq48EdM/HOnmJ2nLQShqADpK
	13q0viRNv+TKGF6JqU8fl/nQgbcfswWdY9WSRLJ6sqoyoLl8d82OYssTliwFE27/sZmG
	BmzdgLoKhkzEwr4ckguxDSTJbSvvS+DCbqfGU3GTq5Th9McTxiA6U4XURxBRnh9Oj+cl
	04FxRn7sGsTRCKxfMjezl4vlDdRR9T8LIoddWL+qniQQDup6ycPz0b9HYLkjQoRol+uG
	Jtlg==
X-Gm-Message-State: ALoCoQkBvPzHTcKJZmio1/K4mo2No+sqc4J87n7nRt4FSpMJNu3aYuWzjUpxw9HlLRohzVLmZ9BG
X-Received: by 10.180.91.137 with SMTP id ce9mr4603657wib.60.1415362864021;
	Fri, 07 Nov 2014 04:21:04 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id v10sm1836184wiy.21.2014.11.07.04.21.02
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 04:21:03 -0800 (PST)
Message-ID: <545CB92E.9050106@linaro.org>
Date: Fri, 07 Nov 2014 12:21:02 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>, 
	Eric Dumazet <eric.dumazet@gmail.com>
References: <20141106214940.GD44162@ubuntu-hedt>	 <545C9013.1090406@linaro.org>
	<1415359320.13896.105.camel@edumazet-glaptop2.roam.corp.google.com>
	<545CB7FF.8080003@canonical.com>
In-Reply-To: <545CB7FF.8080003@canonical.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 07/11/14 12:15, Stefan Bader wrote:
> On 07.11.2014 12:22, Eric Dumazet wrote:
>> On Fri, 2014-11-07 at 09:25 +0000, Zoltan Kiss wrote:
>>
>> Please do not top post.
>>
>>> Hi,
>>>
>>> AFAIK in this scenario your skb frag is wrong. The page pointer should
>>> point to the original compound page (not a member of it), and offset
>>> should be set accordingly.
>>> For example, if your compound page is 16K (4 page), then the page
>>> pointer should point to the first page, and if the data starts at the
>>> 3rd page, then offset should be >8K
>>
>> This is not accurate.
>>
>> This BUG_ON() is wrong.
>>
>> It should instead be :
>>
>> BUG_ON(len + offset > PAGE_SIZE<<compound_order(compound_head(page)));
>
> would that not have to be
>
> BUG_ON((page-compound_head(page)*PAGE_SIZE)+offset+len >
> PAGE_SIZE<<compound_order(compound_head(page)));

There should be a parentheses around "page-compound_head(page)".
>
> since offset is adjusted to start from the tail page in that case.
>>
>> splice() code can generate such cases.
>>
>>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:28:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:28:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmidt-0002Yj-JO; Fri, 07 Nov 2014 12:27:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xmids-0002Ye-LS
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:27:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C2/BA-24532-8CABC545; Fri, 07 Nov 2014 12:27:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415363270!12163575!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3252 invoked from network); 7 Nov 2014 12:27:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 12:27:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7CRira010541
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 12:27:45 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7CRh4s028008
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Nov 2014 12:27:44 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA7CRgnI001681; Fri, 7 Nov 2014 12:27:43 GMT
Received: from android-e228b54d98dcf47b.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 04:27:42 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <545CB43D.4030404@citrix.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
	<545CB43D.4030404@citrix.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 07 Nov 2014 07:27:20 -0500
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <280C1E5B-BBC8-4E62-9702-86B16E25103B@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 7, 2014 6:59:57 AM EST, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>On 07/11/14 11:37, Ian Jackson wrote:
>> Russ mentioned that he was expecting us to have a test day next week.
>> Is that still on; do you want to cut an RC soon ?  If you let me know
>> ASAP we can still do that today, I think.
>>
>> Ian.
>
>Frankly, tagging an -RC2 before OSStest moves staging into master would
>leave almost no delta between RC1 and RC2, and leave all of the pygrub
>bugs still open.

Good point!

>
>My XenServer testing of all of this is currently on c/s 5c8dd034 (the
>change to the MAINTAINERs file for hvmloader) and looking fine.
>

Thank you for keeping the tests warm..


>I would suggest waiting, (or force pushing, but I suspect that will be
>objected-to).

Let's wait as I believe the issues that are making osstest choke are the swiotlb related - and Ian has them queued up for the next run I believe?

Hopefully by Monday it will clear up and master = staging.

>
>~Andrew



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:28:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:28:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmidt-0002Yj-JO; Fri, 07 Nov 2014 12:27:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xmids-0002Ye-LS
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:27:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C2/BA-24532-8CABC545; Fri, 07 Nov 2014 12:27:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415363270!12163575!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3252 invoked from network); 7 Nov 2014 12:27:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 12:27:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7CRira010541
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 12:27:45 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7CRh4s028008
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Nov 2014 12:27:44 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA7CRgnI001681; Fri, 7 Nov 2014 12:27:43 GMT
Received: from android-e228b54d98dcf47b.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 04:27:42 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <545CB43D.4030404@citrix.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
	<545CB43D.4030404@citrix.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 07 Nov 2014 07:27:20 -0500
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <280C1E5B-BBC8-4E62-9702-86B16E25103B@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 7, 2014 6:59:57 AM EST, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>On 07/11/14 11:37, Ian Jackson wrote:
>> Russ mentioned that he was expecting us to have a test day next week.
>> Is that still on; do you want to cut an RC soon ?  If you let me know
>> ASAP we can still do that today, I think.
>>
>> Ian.
>
>Frankly, tagging an -RC2 before OSStest moves staging into master would
>leave almost no delta between RC1 and RC2, and leave all of the pygrub
>bugs still open.

Good point!

>
>My XenServer testing of all of this is currently on c/s 5c8dd034 (the
>change to the MAINTAINERs file for hvmloader) and looking fine.
>

Thank you for keeping the tests warm..


>I would suggest waiting, (or force pushing, but I suspect that will be
>objected-to).

Let's wait as I believe the issues that are making osstest choke are the swiotlb related - and Ian has them queued up for the next run I believe?

Hopefully by Monday it will clear up and master = staging.

>
>~Andrew



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:28:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 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 1Xmiec-0002cw-6T; Fri, 07 Nov 2014 12:28:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1Xmieb-0002cm-5Q
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:28:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	06/14-09842-4FABC545; Fri, 07 Nov 2014 12:28:36 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415363315!12214801!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15494 invoked from network); 7 Nov 2014 12:28:36 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-8.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Nov 2014 12:28:36 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XmieZ-0006Bb-23; Fri, 07 Nov 2014 12:28:35 +0000
Message-ID: <545CBAF1.4020207@canonical.com>
Date: Fri, 07 Nov 2014 13:28:33 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Zoltan Kiss <zoltan.kiss@linaro.org>, 
	Eric Dumazet <eric.dumazet@gmail.com>
References: <20141106214940.GD44162@ubuntu-hedt>	 <545C9013.1090406@linaro.org>
	<1415359320.13896.105.camel@edumazet-glaptop2.roam.corp.google.com>
	<545CB7FF.8080003@canonical.com> <545CB92E.9050106@linaro.org>
In-Reply-To: <545CB92E.9050106@linaro.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7795218471567528611=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============7795218471567528611==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="0ViuMnpe8U2G0Vr4XJacPpStuwjAKOr1S"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0ViuMnpe8U2G0Vr4XJacPpStuwjAKOr1S
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 07.11.2014 13:21, Zoltan Kiss wrote:
>=20
>=20
> On 07/11/14 12:15, Stefan Bader wrote:
>> On 07.11.2014 12:22, Eric Dumazet wrote:
>>> On Fri, 2014-11-07 at 09:25 +0000, Zoltan Kiss wrote:
>>>
>>> Please do not top post.
>>>
>>>> Hi,
>>>>
>>>> AFAIK in this scenario your skb frag is wrong. The page pointer shou=
ld
>>>> point to the original compound page (not a member of it), and offset=

>>>> should be set accordingly.
>>>> For example, if your compound page is 16K (4 page), then the page
>>>> pointer should point to the first page, and if the data starts at th=
e
>>>> 3rd page, then offset should be >8K
>>>
>>> This is not accurate.
>>>
>>> This BUG_ON() is wrong.
>>>
>>> It should instead be :
>>>
>>> BUG_ON(len + offset > PAGE_SIZE<<compound_order(compound_head(page)))=
;
>>
>> would that not have to be
>>
>> BUG_ON((page-compound_head(page)*PAGE_SIZE)+offset+len >
>> PAGE_SIZE<<compound_order(compound_head(page)));
>=20
> There should be a parentheses around "page-compound_head(page)".

*sigh* before submitting anything I'll have to make sure I run it past th=
e
compiler at least. I never manager to type the beast without some error.

But you got the drift...

>>
>> since offset is adjusted to start from the tail page in that case.
>>>
>>> splice() code can generate such cases.
>>>
>>>
>>
>>



--0ViuMnpe8U2G0Vr4XJacPpStuwjAKOr1S
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

iQIcBAEBCgAGBQJUXLrxAAoJEOhnXe7L7s6jWHkQALuMGqlxHCK1CKo30aofmUP9
hSqbVSEoqL8ahwPovgbA7aNsPfGgpoy1LM0xw1f/1nFWaGaN1YpMoS9MFqYOWK7n
SYl9sNztzG14uyQtGFyzLHhDkwCopkDqeDPYwcPbHN0knQfvZaTs47pR4Rgy6+Q+
bzvBN1aOe2wl1CC1h0Lbd8zkiXH29tGVJqgcWKnEo6Dwr/7SElujLCjXsAdm77AV
jdvdl2jEz6X2K4aXuHyUFkUtZ1DKkoHDP+RPNDxS9qyuS7UrjCMWf8n8Q0ieCWnl
0JLOA5mD79jj74md1N49XOieQMMivv/vjaJ9WrAN6u1SNpjM28ieqcXz85Yu9WXC
vQ2EkxEEWMJ7rN+Cqhk1kkFjKwL5ZEytlmtAFJhkoJbqn9Xyz+bUjG/Xsizyu+rK
JFgDYGqCd4iUl/JON4gPlk9Cclw2zeFb5yAD0rTv6tLakI3iJhnkP5z91cYPTICS
qZF0zWfhJQkgtZPKCeilTT8zWtrfpeNMK8awWUL9EAPzQ64LeJEgV9P7vo4mQNfG
XPGAbb/Rv4SKAsqTy7DYFNCnT0gEO/5Vr2LBD4/LXLtzpW9Lc1ZKzLs5IfYsYdGj
Jh6kIcAm4wWekaZqX61TKIjfwFVZ5buuZoZssmIKAtqsvxQGD+TcCgp601biRGP/
tcJMgLiZQiHGn6BCvZJl
=FOiu
-----END PGP SIGNATURE-----

--0ViuMnpe8U2G0Vr4XJacPpStuwjAKOr1S--


--===============7795218471567528611==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7795218471567528611==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 12:28:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 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 1Xmiec-0002cw-6T; Fri, 07 Nov 2014 12:28:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1Xmieb-0002cm-5Q
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:28:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	06/14-09842-4FABC545; Fri, 07 Nov 2014 12:28:36 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415363315!12214801!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15494 invoked from network); 7 Nov 2014 12:28:36 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-8.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Nov 2014 12:28:36 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XmieZ-0006Bb-23; Fri, 07 Nov 2014 12:28:35 +0000
Message-ID: <545CBAF1.4020207@canonical.com>
Date: Fri, 07 Nov 2014 13:28:33 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Zoltan Kiss <zoltan.kiss@linaro.org>, 
	Eric Dumazet <eric.dumazet@gmail.com>
References: <20141106214940.GD44162@ubuntu-hedt>	 <545C9013.1090406@linaro.org>
	<1415359320.13896.105.camel@edumazet-glaptop2.roam.corp.google.com>
	<545CB7FF.8080003@canonical.com> <545CB92E.9050106@linaro.org>
In-Reply-To: <545CB92E.9050106@linaro.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7795218471567528611=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============7795218471567528611==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="0ViuMnpe8U2G0Vr4XJacPpStuwjAKOr1S"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0ViuMnpe8U2G0Vr4XJacPpStuwjAKOr1S
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 07.11.2014 13:21, Zoltan Kiss wrote:
>=20
>=20
> On 07/11/14 12:15, Stefan Bader wrote:
>> On 07.11.2014 12:22, Eric Dumazet wrote:
>>> On Fri, 2014-11-07 at 09:25 +0000, Zoltan Kiss wrote:
>>>
>>> Please do not top post.
>>>
>>>> Hi,
>>>>
>>>> AFAIK in this scenario your skb frag is wrong. The page pointer shou=
ld
>>>> point to the original compound page (not a member of it), and offset=

>>>> should be set accordingly.
>>>> For example, if your compound page is 16K (4 page), then the page
>>>> pointer should point to the first page, and if the data starts at th=
e
>>>> 3rd page, then offset should be >8K
>>>
>>> This is not accurate.
>>>
>>> This BUG_ON() is wrong.
>>>
>>> It should instead be :
>>>
>>> BUG_ON(len + offset > PAGE_SIZE<<compound_order(compound_head(page)))=
;
>>
>> would that not have to be
>>
>> BUG_ON((page-compound_head(page)*PAGE_SIZE)+offset+len >
>> PAGE_SIZE<<compound_order(compound_head(page)));
>=20
> There should be a parentheses around "page-compound_head(page)".

*sigh* before submitting anything I'll have to make sure I run it past th=
e
compiler at least. I never manager to type the beast without some error.

But you got the drift...

>>
>> since offset is adjusted to start from the tail page in that case.
>>>
>>> splice() code can generate such cases.
>>>
>>>
>>
>>



--0ViuMnpe8U2G0Vr4XJacPpStuwjAKOr1S
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

iQIcBAEBCgAGBQJUXLrxAAoJEOhnXe7L7s6jWHkQALuMGqlxHCK1CKo30aofmUP9
hSqbVSEoqL8ahwPovgbA7aNsPfGgpoy1LM0xw1f/1nFWaGaN1YpMoS9MFqYOWK7n
SYl9sNztzG14uyQtGFyzLHhDkwCopkDqeDPYwcPbHN0knQfvZaTs47pR4Rgy6+Q+
bzvBN1aOe2wl1CC1h0Lbd8zkiXH29tGVJqgcWKnEo6Dwr/7SElujLCjXsAdm77AV
jdvdl2jEz6X2K4aXuHyUFkUtZ1DKkoHDP+RPNDxS9qyuS7UrjCMWf8n8Q0ieCWnl
0JLOA5mD79jj74md1N49XOieQMMivv/vjaJ9WrAN6u1SNpjM28ieqcXz85Yu9WXC
vQ2EkxEEWMJ7rN+Cqhk1kkFjKwL5ZEytlmtAFJhkoJbqn9Xyz+bUjG/Xsizyu+rK
JFgDYGqCd4iUl/JON4gPlk9Cclw2zeFb5yAD0rTv6tLakI3iJhnkP5z91cYPTICS
qZF0zWfhJQkgtZPKCeilTT8zWtrfpeNMK8awWUL9EAPzQ64LeJEgV9P7vo4mQNfG
XPGAbb/Rv4SKAsqTy7DYFNCnT0gEO/5Vr2LBD4/LXLtzpW9Lc1ZKzLs5IfYsYdGj
Jh6kIcAm4wWekaZqX61TKIjfwFVZ5buuZoZssmIKAtqsvxQGD+TcCgp601biRGP/
tcJMgLiZQiHGn6BCvZJl
=FOiu
-----END PGP SIGNATURE-----

--0ViuMnpe8U2G0Vr4XJacPpStuwjAKOr1S--


--===============7795218471567528611==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7795218471567528611==--


From xen-devel-bounces@lists.xen.org Fri Nov 07 12:33:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmiiz-0002td-VZ; Fri, 07 Nov 2014 12:33:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Xmiix-0002tY-VJ
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 12:33:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	98/D3-09936-30CBC545; Fri, 07 Nov 2014 12:33:07 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415363583!12146588!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4126 invoked from network); 7 Nov 2014 12:33:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 12:33:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="26633437"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
Thread-Index: AQHP+db+JFivzKZEXUWQa+JLJe8/D5xU/OwAgAAcQWA=
Date: Fri, 7 Nov 2014 12:33:02 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD01114800D@AMSPEX01CL01.citrite.net>
References: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
	<545CBF820200007800045A27@mail.emea.novell.com>
In-Reply-To: <545CBF820200007800045A27@mail.emea.novell.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: 07 November 2014 11:48
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; Keir (Xen.org)
> Subject: Re: [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
> 
> >>> On 06.11.14 at 16:33, <paul.durrant@citrix.com> wrote:
> > HVM guests have always been confined to using the domain callback
> > via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
> > which is an IOAPIC vector and is only used if the event channel is
> > bound to vcpu 0.
> 
> Iirc the callback-via-vector method was specifically added to have a
> way to spread the IRQ handling load. And even if this didn't work out
> as intended, wouldn't simply setting a flag to avoid the restriction in
> 
> 
> > This patch adds a new HVM op allowing a guest to specify a local
> > APIC vector to use as an upcall notification for a specific vcpu.
> > This therefore allows a guest which sets a vector for a vcpu
> > other than 0 to then bind event channels to that vcpu.
> 
> So is there really a need for a per-vCPU vector value (rather than
> a single domain wide one)?
> 

I can't stipulate that Windows gives me the same vector on every CPU, so yes.

> > @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
> >
> >      if ( is_hvm_pv_evtchn_vcpu(v) )
> >          vcpu_kick(v);
> > +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> > +        hvm_set_upcall_irq(v);
> 
> The context code above your insertion is clearly not enforcing
> vCPU 0 only; the code below this change is.
> 

Yes, the callback via is only allowed to be issued for events bound to vcpu 0, although nothing ensures that it only gets delivered to vcpu0. I don't know what the historical reason behind that is. The whole point of the new vectors though is that there is one per vcpu, not just one on vcpu 0, so why would I want to enforce vcpu 0 only? It would defeat the entire point of the patch.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:33:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmiiz-0002td-VZ; Fri, 07 Nov 2014 12:33:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Xmiix-0002tY-VJ
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 12:33:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	98/D3-09936-30CBC545; Fri, 07 Nov 2014 12:33:07 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415363583!12146588!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4126 invoked from network); 7 Nov 2014 12:33:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 12:33:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="26633437"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
Thread-Index: AQHP+db+JFivzKZEXUWQa+JLJe8/D5xU/OwAgAAcQWA=
Date: Fri, 7 Nov 2014 12:33:02 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD01114800D@AMSPEX01CL01.citrite.net>
References: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
	<545CBF820200007800045A27@mail.emea.novell.com>
In-Reply-To: <545CBF820200007800045A27@mail.emea.novell.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: 07 November 2014 11:48
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; Keir (Xen.org)
> Subject: Re: [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
> 
> >>> On 06.11.14 at 16:33, <paul.durrant@citrix.com> wrote:
> > HVM guests have always been confined to using the domain callback
> > via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications
> > which is an IOAPIC vector and is only used if the event channel is
> > bound to vcpu 0.
> 
> Iirc the callback-via-vector method was specifically added to have a
> way to spread the IRQ handling load. And even if this didn't work out
> as intended, wouldn't simply setting a flag to avoid the restriction in
> 
> 
> > This patch adds a new HVM op allowing a guest to specify a local
> > APIC vector to use as an upcall notification for a specific vcpu.
> > This therefore allows a guest which sets a vector for a vcpu
> > other than 0 to then bind event channels to that vcpu.
> 
> So is there really a need for a per-vCPU vector value (rather than
> a single domain wide one)?
> 

I can't stipulate that Windows gives me the same vector on every CPU, so yes.

> > @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
> >
> >      if ( is_hvm_pv_evtchn_vcpu(v) )
> >          vcpu_kick(v);
> > +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> > +        hvm_set_upcall_irq(v);
> 
> The context code above your insertion is clearly not enforcing
> vCPU 0 only; the code below this change is.
> 

Yes, the callback via is only allowed to be issued for events bound to vcpu 0, although nothing ensures that it only gets delivered to vcpu0. I don't know what the historical reason behind that is. The whole point of the new vectors though is that there is one per vcpu, not just one on vcpu 0, so why would I want to enforce vcpu 0 only? It would defeat the entire point of the patch.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:51:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:51:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmj06-00035z-KB; Fri, 07 Nov 2014 12:50:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xmj05-00035u-Hx
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:50:49 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	FC/08-11608-820CC545; Fri, 07 Nov 2014 12:50:48 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415364646!11048087!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15877 invoked from network); 7 Nov 2014 12:50:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 12:50:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="190539568"
Message-ID: <545CC002.80905@citrix.com>
Date: Fri, 7 Nov 2014 12:50:10 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
	<545CB43D.4030404@citrix.com>
	<280C1E5B-BBC8-4E62-9702-86B16E25103B@oracle.com>
In-Reply-To: <280C1E5B-BBC8-4E62-9702-86B16E25103B@oracle.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/11/14 12:27, Konrad Rzeszutek Wilk wrote:
> On November 7, 2014 6:59:57 AM EST, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 07/11/14 11:37, Ian Jackson wrote:
>>> Russ mentioned that he was expecting us to have a test day next week.
>>> Is that still on; do you want to cut an RC soon ?  If you let me know
>>> ASAP we can still do that today, I think.
>>>
>>> Ian.
>> Frankly, tagging an -RC2 before OSStest moves staging into master would
>> leave almost no delta between RC1 and RC2, and leave all of the pygrub
>> bugs still open.
> Good point!
>
>> My XenServer testing of all of this is currently on c/s 5c8dd034 (the
>> change to the MAINTAINERs file for hvmloader) and looking fine.
>>
> Thank you for keeping the tests warm..

It is no problem at all.  At the moment, it is literally just a git pull
and wait several hours for basic automatic testing to get back to me and
say "everything still fine".

I suppose it is worth stating that there are no outstanding patches for
bugs I am aware of.  All the bugs we have discovered have their fixes in
staging.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:51:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:51:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmj06-00035z-KB; Fri, 07 Nov 2014 12:50:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xmj05-00035u-Hx
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:50:49 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	FC/08-11608-820CC545; Fri, 07 Nov 2014 12:50:48 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415364646!11048087!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15877 invoked from network); 7 Nov 2014 12:50:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 12:50:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="190539568"
Message-ID: <545CC002.80905@citrix.com>
Date: Fri, 7 Nov 2014 12:50:10 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
	<545CB43D.4030404@citrix.com>
	<280C1E5B-BBC8-4E62-9702-86B16E25103B@oracle.com>
In-Reply-To: <280C1E5B-BBC8-4E62-9702-86B16E25103B@oracle.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/11/14 12:27, Konrad Rzeszutek Wilk wrote:
> On November 7, 2014 6:59:57 AM EST, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 07/11/14 11:37, Ian Jackson wrote:
>>> Russ mentioned that he was expecting us to have a test day next week.
>>> Is that still on; do you want to cut an RC soon ?  If you let me know
>>> ASAP we can still do that today, I think.
>>>
>>> Ian.
>> Frankly, tagging an -RC2 before OSStest moves staging into master would
>> leave almost no delta between RC1 and RC2, and leave all of the pygrub
>> bugs still open.
> Good point!
>
>> My XenServer testing of all of this is currently on c/s 5c8dd034 (the
>> change to the MAINTAINERs file for hvmloader) and looking fine.
>>
> Thank you for keeping the tests warm..

It is no problem at all.  At the moment, it is literally just a git pull
and wait several hours for basic automatic testing to get back to me and
say "everything still fine".

I suppose it is worth stating that there are no outstanding patches for
bugs I am aware of.  All the bugs we have discovered have their fixes in
staging.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:58:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:58:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmj7M-0003I6-JK; Fri, 07 Nov 2014 12:58:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek@citrix.com>) id 1Xmj7L-0003I1-QN
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:58:19 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	C7/CE-25714-BE1CC545; Fri, 07 Nov 2014 12:58:19 +0000
X-Env-Sender: russell.pavlicek@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415365097!3530902!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16579 invoked from network); 7 Nov 2014 12:58:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 12:58:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189113798"
From: Russell Pavlicek <russell.pavlicek@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Ian Jackson
	<Ian.Jackson@citrix.com>
Thread-Topic: RC today or Monday or something ?
Thread-Index: AQHP+n80cDfVqd3TqEKDqICvzCmbGZxVlV0AgAAAVID//4iAdQ==
Date: Fri, 7 Nov 2014 12:58:15 +0000
Message-ID: <55E78A57290FB64FA0D3CF672F9F3DA20509BFF6@SJCPEX01CL03.citrite.net>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
	<04F855BA-C5E1-4745-ADC6-ED04559755FC@oracle.com>,
	<BE059B0C-C22A-4290-B234-C6C3F4D6E803@oracle.com>
In-Reply-To: <BE059B0C-C22A-4290-B234-C6C3F4D6E803@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com]
>Sent: Friday, November 07, 2014 6:59 AM
>To: Ian Jackson
>Cc: Russell Pavlicek; Stefano Stabellini; xen-devel@lists.xenproject.org
>Subject: Re: RC today or Monday or something ?

>On November 7, 2014 6:58:20 AM EST, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>On November 7, 2014 6:37:23 AM EST, Ian Jackson
>><Ian.Jackson@eu.citrix.com> wrote:
>>>Russ mentioned that he was expecting us to have a test day next week.
>>>Is that still on; do you want to cut an RC soon ?  If you let me know
>>>ASAP we can still do that today, I think.
>>>
>>
>>Yes or we can do it on Monday. I will be on IRC around 10am EST today -
>>hopefully not too late for you.
>
>And the Testday was to be on Wed the 12th.

Konrad, last we chatted on IRC, you indicated a desire to delay Test Day to the 13th, which is what I currently have posted in the Wiki. If you want to stay with the earlier date of the 12th, please let me know so I can adjust the Wiki and events calendar accordingly.  I will also send out an announcement email as soon as you verify the date.

Thanks.

>
>>Ian.


Russ Pavlicek
Xen Project Evangelist, Citrix Systems
Home Office: +1-301-829-5327
Mobile: +1-240-397-0199
UK VoIP: +44 1223 852 894

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 12:58:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 12:58:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmj7M-0003I6-JK; Fri, 07 Nov 2014 12:58:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek@citrix.com>) id 1Xmj7L-0003I1-QN
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 12:58:19 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	C7/CE-25714-BE1CC545; Fri, 07 Nov 2014 12:58:19 +0000
X-Env-Sender: russell.pavlicek@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415365097!3530902!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16579 invoked from network); 7 Nov 2014 12:58:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 12:58:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189113798"
From: Russell Pavlicek <russell.pavlicek@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Ian Jackson
	<Ian.Jackson@citrix.com>
Thread-Topic: RC today or Monday or something ?
Thread-Index: AQHP+n80cDfVqd3TqEKDqICvzCmbGZxVlV0AgAAAVID//4iAdQ==
Date: Fri, 7 Nov 2014 12:58:15 +0000
Message-ID: <55E78A57290FB64FA0D3CF672F9F3DA20509BFF6@SJCPEX01CL03.citrite.net>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
	<04F855BA-C5E1-4745-ADC6-ED04559755FC@oracle.com>,
	<BE059B0C-C22A-4290-B234-C6C3F4D6E803@oracle.com>
In-Reply-To: <BE059B0C-C22A-4290-B234-C6C3F4D6E803@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com]
>Sent: Friday, November 07, 2014 6:59 AM
>To: Ian Jackson
>Cc: Russell Pavlicek; Stefano Stabellini; xen-devel@lists.xenproject.org
>Subject: Re: RC today or Monday or something ?

>On November 7, 2014 6:58:20 AM EST, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>On November 7, 2014 6:37:23 AM EST, Ian Jackson
>><Ian.Jackson@eu.citrix.com> wrote:
>>>Russ mentioned that he was expecting us to have a test day next week.
>>>Is that still on; do you want to cut an RC soon ?  If you let me know
>>>ASAP we can still do that today, I think.
>>>
>>
>>Yes or we can do it on Monday. I will be on IRC around 10am EST today -
>>hopefully not too late for you.
>
>And the Testday was to be on Wed the 12th.

Konrad, last we chatted on IRC, you indicated a desire to delay Test Day to the 13th, which is what I currently have posted in the Wiki. If you want to stay with the earlier date of the 12th, please let me know so I can adjust the Wiki and events calendar accordingly.  I will also send out an announcement email as soon as you verify the date.

Thanks.

>
>>Ian.


Russ Pavlicek
Xen Project Evangelist, Citrix Systems
Home Office: +1-301-829-5327
Mobile: +1-240-397-0199
UK VoIP: +44 1223 852 894

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:01:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:01:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmjAU-0003Qv-7j; Fri, 07 Nov 2014 13:01:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XmjAS-0003Qm-Bh
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 13:01:32 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	38/AC-22777-BA2CC545; Fri, 07 Nov 2014 13:01:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415365291!11129866!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31049 invoked from network); 7 Nov 2014 13:01:31 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Nov 2014 13:01:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 07 Nov 2014 13:01:30 +0000
Message-Id: <545CD0BB0200007800045ABC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 07 Nov 2014 13:01:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <Paul.Durrant@citrix.com>
References: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
	<545CBF820200007800045A27@mail.emea.novell.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114800D@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD01114800D@AMSPEX01CL01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.11.14 at 13:33, <Paul.Durrant@citrix.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 06.11.14 at 16:33, <paul.durrant@citrix.com> wrote:
>> So is there really a need for a per-vCPU vector value (rather than
>> a single domain wide one)?
>> 
> 
> I can't stipulate that Windows gives me the same vector on every CPU, so 
> yes.

So Windows has no concept of per-CPU vectors/IRQs? I'm somewhat
surprised, since for their Hyper-V drivers in Linux they were specifically
looking for how to do this under Linux, making me assume that they
try to keep their driver behavior as similar as possible to their native
equivalents.

>> > @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
>> >
>> >      if ( is_hvm_pv_evtchn_vcpu(v) )
>> >          vcpu_kick(v);
>> > +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
>> > +        hvm_set_upcall_irq(v);
>> 
>> The context code above your insertion is clearly not enforcing
>> vCPU 0 only; the code below this change is.
>> 
> 
> Yes, the callback via is only allowed to be issued for events bound to vcpu 
> 0, although nothing ensures that it only gets delivered to vcpu0. I don't 
> know what the historical reason behind that is. The whole point of the new 
> vectors though is that there is one per vcpu, not just one on vcpu 0, so why 
> would I want to enforce vcpu 0 only? It would defeat the entire point of the 
> patch.

I think you misunderstood what I tried to say; I wasn't suggesting
that you should limit yourself to vCPU 0. Instead I was asking why
the non-vCPU-0-bound mechanism visible in the patch context
doesn't suit your needs (in fact I think the answer to this should be
part of the commit message).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:01:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:01:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmjAU-0003Qv-7j; Fri, 07 Nov 2014 13:01:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XmjAS-0003Qm-Bh
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 13:01:32 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	38/AC-22777-BA2CC545; Fri, 07 Nov 2014 13:01:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415365291!11129866!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31049 invoked from network); 7 Nov 2014 13:01:31 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Nov 2014 13:01:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 07 Nov 2014 13:01:30 +0000
Message-Id: <545CD0BB0200007800045ABC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 07 Nov 2014 13:01:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <Paul.Durrant@citrix.com>
References: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
	<545CBF820200007800045A27@mail.emea.novell.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114800D@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD01114800D@AMSPEX01CL01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.11.14 at 13:33, <Paul.Durrant@citrix.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 06.11.14 at 16:33, <paul.durrant@citrix.com> wrote:
>> So is there really a need for a per-vCPU vector value (rather than
>> a single domain wide one)?
>> 
> 
> I can't stipulate that Windows gives me the same vector on every CPU, so 
> yes.

So Windows has no concept of per-CPU vectors/IRQs? I'm somewhat
surprised, since for their Hyper-V drivers in Linux they were specifically
looking for how to do this under Linux, making me assume that they
try to keep their driver behavior as similar as possible to their native
equivalents.

>> > @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
>> >
>> >      if ( is_hvm_pv_evtchn_vcpu(v) )
>> >          vcpu_kick(v);
>> > +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
>> > +        hvm_set_upcall_irq(v);
>> 
>> The context code above your insertion is clearly not enforcing
>> vCPU 0 only; the code below this change is.
>> 
> 
> Yes, the callback via is only allowed to be issued for events bound to vcpu 
> 0, although nothing ensures that it only gets delivered to vcpu0. I don't 
> know what the historical reason behind that is. The whole point of the new 
> vectors though is that there is one per vcpu, not just one on vcpu 0, so why 
> would I want to enforce vcpu 0 only? It would defeat the entire point of the 
> patch.

I think you misunderstood what I tried to say; I wasn't suggesting
that you should limit yourself to vCPU 0. Instead I was asking why
the non-vCPU-0-bound mechanism visible in the patch context
doesn't suit your needs (in fact I think the answer to this should be
part of the commit message).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:04:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmjD5-0003cB-Pd; Fri, 07 Nov 2014 13:04:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XmjD4-0003c5-IP
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 13:04:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	30/09-24532-D43CC545; Fri, 07 Nov 2014 13:04:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415365452!12215467!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10460 invoked from network); 7 Nov 2014 13:04:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:04:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="190544217"
Message-ID: <545CC349.8020006@citrix.com>
Date: Fri, 7 Nov 2014 13:04:09 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-3-git-send-email-jgross@suse.com>
In-Reply-To: <1415252853-7106-3-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH V2 2/5] xen: Delay m2p_override
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 05:47, Juergen Gross wrote:
> The m2p overrides are used to be able to find the local pfn for a
> foreign mfn mapped into the domain. They are used by driver backends
> having to access frontend data.
> 
> As this functionality isn't used in early boot it makes no sense to
> initialize the m2p override functions very early. It can be done
> later without doing any harm, removing the need for allocating memory
> via extend_brk().
> 
> While at it make some m2p override functions static as they are only
> used internally.
[...]
>  		}
>  		/* This should be the leafs allocated for identity from _brk. */
>  	}
> -	return (unsigned long)mfn_list;
>  
> +	m2p_override_init();
> +	return (unsigned long)mfn_list;
>  }
>  #else
>  unsigned long __init xen_revector_p2m_tree(void)
>  {
>  	use_brk = 0;
> +	m2p_override_init();
>  	return 0;
>  }

This is mentioned in the description...

>  #endif
> @@ -794,15 +794,16 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  #define M2P_OVERRIDE_HASH_SHIFT	10
>  #define M2P_OVERRIDE_HASH	(1 << M2P_OVERRIDE_HASH_SHIFT)
>  
> -static RESERVE_BRK_ARRAY(struct list_head, m2p_overrides, M2P_OVERRIDE_HASH);
> +static struct list_head *m2p_overrides;
>  static DEFINE_SPINLOCK(m2p_override_lock);
>  
>  static void __init m2p_override_init(void)
>  {
>  	unsigned i;
>  
> -	m2p_overrides = extend_brk(sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
> -				   sizeof(unsigned long));
> +	m2p_overrides = alloc_bootmem_align(
> +				sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
> +				sizeof(unsigned long));

...as is this.

> -int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
> -			    struct gnttab_map_grant_ref *kmap_ops,
> -			    struct page **pages, unsigned int count)
> -{
> -	int i, ret = 0;
> -	bool lazy = false;
> -	pte_t *pte;
> -
> -	if (xen_feature(XENFEAT_auto_translated_physmap))
> -		return 0;
> -
> -	if (kmap_ops &&
> -	    !in_interrupt() &&
> -	    paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
> -		arch_enter_lazy_mmu_mode();
> -		lazy = true;
> -	}

... but, what's going on here.  What are the rest of these changes?

I suppose this is the "make some functions static" but it's an
unreviewable mess.  If you can't do this with some one line changes
adding "static" and perhaps some forward declarations then please drop
this bit.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:04:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmjD5-0003cB-Pd; Fri, 07 Nov 2014 13:04:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XmjD4-0003c5-IP
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 13:04:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	30/09-24532-D43CC545; Fri, 07 Nov 2014 13:04:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415365452!12215467!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10460 invoked from network); 7 Nov 2014 13:04:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:04:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="190544217"
Message-ID: <545CC349.8020006@citrix.com>
Date: Fri, 7 Nov 2014 13:04:09 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-3-git-send-email-jgross@suse.com>
In-Reply-To: <1415252853-7106-3-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH V2 2/5] xen: Delay m2p_override
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 05:47, Juergen Gross wrote:
> The m2p overrides are used to be able to find the local pfn for a
> foreign mfn mapped into the domain. They are used by driver backends
> having to access frontend data.
> 
> As this functionality isn't used in early boot it makes no sense to
> initialize the m2p override functions very early. It can be done
> later without doing any harm, removing the need for allocating memory
> via extend_brk().
> 
> While at it make some m2p override functions static as they are only
> used internally.
[...]
>  		}
>  		/* This should be the leafs allocated for identity from _brk. */
>  	}
> -	return (unsigned long)mfn_list;
>  
> +	m2p_override_init();
> +	return (unsigned long)mfn_list;
>  }
>  #else
>  unsigned long __init xen_revector_p2m_tree(void)
>  {
>  	use_brk = 0;
> +	m2p_override_init();
>  	return 0;
>  }

This is mentioned in the description...

>  #endif
> @@ -794,15 +794,16 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  #define M2P_OVERRIDE_HASH_SHIFT	10
>  #define M2P_OVERRIDE_HASH	(1 << M2P_OVERRIDE_HASH_SHIFT)
>  
> -static RESERVE_BRK_ARRAY(struct list_head, m2p_overrides, M2P_OVERRIDE_HASH);
> +static struct list_head *m2p_overrides;
>  static DEFINE_SPINLOCK(m2p_override_lock);
>  
>  static void __init m2p_override_init(void)
>  {
>  	unsigned i;
>  
> -	m2p_overrides = extend_brk(sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
> -				   sizeof(unsigned long));
> +	m2p_overrides = alloc_bootmem_align(
> +				sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
> +				sizeof(unsigned long));

...as is this.

> -int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
> -			    struct gnttab_map_grant_ref *kmap_ops,
> -			    struct page **pages, unsigned int count)
> -{
> -	int i, ret = 0;
> -	bool lazy = false;
> -	pte_t *pte;
> -
> -	if (xen_feature(XENFEAT_auto_translated_physmap))
> -		return 0;
> -
> -	if (kmap_ops &&
> -	    !in_interrupt() &&
> -	    paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
> -		arch_enter_lazy_mmu_mode();
> -		lazy = true;
> -	}

... but, what's going on here.  What are the rest of these changes?

I suppose this is the "make some functions static" but it's an
unreviewable mess.  If you can't do this with some one line changes
adding "static" and perhaps some forward declarations then please drop
this bit.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:08:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13: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 1XmjHQ-0003lV-Kj; Fri, 07 Nov 2014 13:08:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmjHP-0003lO-0w
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 13:08:43 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	CE/23-03145-A54CC545; Fri, 07 Nov 2014 13:08:42 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415365721!6649865!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4919 invoked from network); 7 Nov 2014 13:08:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:08:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="26634614"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
Thread-Index: AQHP+db+JFivzKZEXUWQa+JLJe8/D5xU/OwAgAAcQWD///hHgIAAERWA
Date: Fri, 7 Nov 2014 13:08:40 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD011148232@AMSPEX01CL01.citrite.net>
References: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
	<545CBF820200007800045A27@mail.emea.novell.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114800D@AMSPEX01CL01.citrite.net>
	<545CD0BB0200007800045ABC@mail.emea.novell.com>
In-Reply-To: <545CD0BB0200007800045ABC@mail.emea.novell.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: 07 November 2014 13:02
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; Keir (Xen.org)
> Subject: RE: [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
> 
> >>> On 07.11.14 at 13:33, <Paul.Durrant@citrix.com> wrote:
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >>> On 06.11.14 at 16:33, <paul.durrant@citrix.com> wrote:
> >> So is there really a need for a per-vCPU vector value (rather than
> >> a single domain wide one)?
> >>
> >
> > I can't stipulate that Windows gives me the same vector on every CPU, so
> > yes.
> 
> So Windows has no concept of per-CPU vectors/IRQs?

All I can do is ask for an interrupt with a specific affinity to 1 or more CPUs. If I ask for one interrupt bound to all CPUs then I will get the same vector on as many CPUs an Windows can allocate it on, but that's not guaranteed to be all the CPUs in the affinity mask I asked for. Also, there will be a single lock protecting that interrupt so it's really not useful. Hence I need to ask for as many interrupts as there are CPUs, each with an affinity mask specifying the individual CPU. That way I avoid the big lock, but I cannot guarantee that I will get the same vector for each interrupt I allocate. Thus I need to be able to set each vcpu to upcall on a potentially differing vector.

> I'm somewhat
> surprised, since for their Hyper-V drivers in Linux they were specifically
> looking for how to do this under Linux, making me assume that they
> try to keep their driver behavior as similar as possible to their native
> equivalents.
> 
> >> > @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
> >> >
> >> >      if ( is_hvm_pv_evtchn_vcpu(v) )
> >> >          vcpu_kick(v);
> >> > +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> >> > +        hvm_set_upcall_irq(v);
> >>
> >> The context code above your insertion is clearly not enforcing
> >> vCPU 0 only; the code below this change is.
> >>
> >
> > Yes, the callback via is only allowed to be issued for events bound to vcpu
> > 0, although nothing ensures that it only gets delivered to vcpu0. I don't
> > know what the historical reason behind that is. The whole point of the new
> > vectors though is that there is one per vcpu, not just one on vcpu 0, so why
> > would I want to enforce vcpu 0 only? It would defeat the entire point of
> the
> > patch.
> 
> I think you misunderstood what I tried to say; I wasn't suggesting
> that you should limit yourself to vCPU 0. Instead I was asking why
> the non-vCPU-0-bound mechanism visible in the patch context
> doesn't suit your needs (in fact I think the answer to this should be
> part of the commit message).
> 

Oh, I see. Yes, I can add a comment as to why the 'vector' callback via is not suitable.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:08:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13: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 1XmjHQ-0003lV-Kj; Fri, 07 Nov 2014 13:08:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XmjHP-0003lO-0w
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 13:08:43 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	CE/23-03145-A54CC545; Fri, 07 Nov 2014 13:08:42 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415365721!6649865!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4919 invoked from network); 7 Nov 2014 13:08:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:08:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="26634614"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
Thread-Index: AQHP+db+JFivzKZEXUWQa+JLJe8/D5xU/OwAgAAcQWD///hHgIAAERWA
Date: Fri, 7 Nov 2014 13:08:40 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD011148232@AMSPEX01CL01.citrite.net>
References: <1415287995-11437-1-git-send-email-paul.durrant@citrix.com>
	<545CBF820200007800045A27@mail.emea.novell.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD01114800D@AMSPEX01CL01.citrite.net>
	<545CD0BB0200007800045ABC@mail.emea.novell.com>
In-Reply-To: <545CD0BB0200007800045ABC@mail.emea.novell.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: 07 November 2014 13:02
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; Keir (Xen.org)
> Subject: RE: [PATCH v2] x86/hvm: Add per-vcpu evtchn upcalls
> 
> >>> On 07.11.14 at 13:33, <Paul.Durrant@citrix.com> wrote:
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >>> On 06.11.14 at 16:33, <paul.durrant@citrix.com> wrote:
> >> So is there really a need for a per-vCPU vector value (rather than
> >> a single domain wide one)?
> >>
> >
> > I can't stipulate that Windows gives me the same vector on every CPU, so
> > yes.
> 
> So Windows has no concept of per-CPU vectors/IRQs?

All I can do is ask for an interrupt with a specific affinity to 1 or more CPUs. If I ask for one interrupt bound to all CPUs then I will get the same vector on as many CPUs an Windows can allocate it on, but that's not guaranteed to be all the CPUs in the affinity mask I asked for. Also, there will be a single lock protecting that interrupt so it's really not useful. Hence I need to ask for as many interrupts as there are CPUs, each with an affinity mask specifying the individual CPU. That way I avoid the big lock, but I cannot guarantee that I will get the same vector for each interrupt I allocate. Thus I need to be able to set each vcpu to upcall on a potentially differing vector.

> I'm somewhat
> surprised, since for their Hyper-V drivers in Linux they were specifically
> looking for how to do this under Linux, making me assume that they
> try to keep their driver behavior as similar as possible to their native
> equivalents.
> 
> >> > @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
> >> >
> >> >      if ( is_hvm_pv_evtchn_vcpu(v) )
> >> >          vcpu_kick(v);
> >> > +    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> >> > +        hvm_set_upcall_irq(v);
> >>
> >> The context code above your insertion is clearly not enforcing
> >> vCPU 0 only; the code below this change is.
> >>
> >
> > Yes, the callback via is only allowed to be issued for events bound to vcpu
> > 0, although nothing ensures that it only gets delivered to vcpu0. I don't
> > know what the historical reason behind that is. The whole point of the new
> > vectors though is that there is one per vcpu, not just one on vcpu 0, so why
> > would I want to enforce vcpu 0 only? It would defeat the entire point of
> the
> > patch.
> 
> I think you misunderstood what I tried to say; I wasn't suggesting
> that you should limit yourself to vCPU 0. Instead I was asking why
> the non-vCPU-0-bound mechanism visible in the patch context
> doesn't suit your needs (in fact I think the answer to this should be
> part of the commit message).
> 

Oh, I see. Yes, I can add a comment as to why the 'vector' callback via is not suitable.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:19:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:19:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmjRm-0003z4-6K; Fri, 07 Nov 2014 13:19:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmjRl-0003yz-7k
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 13:19:25 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F1/49-08051-CD6CC545; Fri, 07 Nov 2014 13:19:24 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415366363!11973082!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27992 invoked from network); 7 Nov 2014 13:19:23 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 13:19:23 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 78F52AC38;
	Fri,  7 Nov 2014 13:19:21 +0000 (UTC)
Message-ID: <545CC6D8.80100@suse.com>
Date: Fri, 07 Nov 2014 14:19:20 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-3-git-send-email-jgross@suse.com>
	<545CC349.8020006@citrix.com>
In-Reply-To: <545CC349.8020006@citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 2/5] xen: Delay m2p_override
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/07/2014 02:04 PM, David Vrabel wrote:
> On 06/11/14 05:47, Juergen Gross wrote:
>> The m2p overrides are used to be able to find the local pfn for a
>> foreign mfn mapped into the domain. They are used by driver backends
>> having to access frontend data.
>>
>> As this functionality isn't used in early boot it makes no sense to
>> initialize the m2p override functions very early. It can be done
>> later without doing any harm, removing the need for allocating memory
>> via extend_brk().
>>
>> While at it make some m2p override functions static as they are only
>> used internally.
> [...]
>>   		}
>>   		/* This should be the leafs allocated for identity from _brk. */
>>   	}
>> -	return (unsigned long)mfn_list;
>>
>> +	m2p_override_init();
>> +	return (unsigned long)mfn_list;
>>   }
>>   #else
>>   unsigned long __init xen_revector_p2m_tree(void)
>>   {
>>   	use_brk = 0;
>> +	m2p_override_init();
>>   	return 0;
>>   }
>
> This is mentioned in the description...
>
>>   #endif
>> @@ -794,15 +794,16 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>>   #define M2P_OVERRIDE_HASH_SHIFT	10
>>   #define M2P_OVERRIDE_HASH	(1 << M2P_OVERRIDE_HASH_SHIFT)
>>
>> -static RESERVE_BRK_ARRAY(struct list_head, m2p_overrides, M2P_OVERRIDE_HASH);
>> +static struct list_head *m2p_overrides;
>>   static DEFINE_SPINLOCK(m2p_override_lock);
>>
>>   static void __init m2p_override_init(void)
>>   {
>>   	unsigned i;
>>
>> -	m2p_overrides = extend_brk(sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
>> -				   sizeof(unsigned long));
>> +	m2p_overrides = alloc_bootmem_align(
>> +				sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
>> +				sizeof(unsigned long));
>
> ...as is this.
>
>> -int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
>> -			    struct gnttab_map_grant_ref *kmap_ops,
>> -			    struct page **pages, unsigned int count)
>> -{
>> -	int i, ret = 0;
>> -	bool lazy = false;
>> -	pte_t *pte;
>> -
>> -	if (xen_feature(XENFEAT_auto_translated_physmap))
>> -		return 0;
>> -
>> -	if (kmap_ops &&
>> -	    !in_interrupt() &&
>> -	    paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
>> -		arch_enter_lazy_mmu_mode();
>> -		lazy = true;
>> -	}
>
> ... but, what's going on here.  What are the rest of these changes?
>
> I suppose this is the "make some functions static" but it's an
> unreviewable mess.  If you can't do this with some one line changes
> adding "static" and perhaps some forward declarations then please drop
> this bit.

Do you really prefer forward declarations instead of pure code movement?
I can do as you request, but just want to make sure.

While I agree that the diff output is really ugly, comparing the old and
new code by looking at it in two editor windows side by side should show
the pure movement of functions easily.

Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:19:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:19:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmjRm-0003z4-6K; Fri, 07 Nov 2014 13:19:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmjRl-0003yz-7k
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 13:19:25 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F1/49-08051-CD6CC545; Fri, 07 Nov 2014 13:19:24 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415366363!11973082!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27992 invoked from network); 7 Nov 2014 13:19:23 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 13:19:23 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 78F52AC38;
	Fri,  7 Nov 2014 13:19:21 +0000 (UTC)
Message-ID: <545CC6D8.80100@suse.com>
Date: Fri, 07 Nov 2014 14:19:20 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-3-git-send-email-jgross@suse.com>
	<545CC349.8020006@citrix.com>
In-Reply-To: <545CC349.8020006@citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 2/5] xen: Delay m2p_override
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/07/2014 02:04 PM, David Vrabel wrote:
> On 06/11/14 05:47, Juergen Gross wrote:
>> The m2p overrides are used to be able to find the local pfn for a
>> foreign mfn mapped into the domain. They are used by driver backends
>> having to access frontend data.
>>
>> As this functionality isn't used in early boot it makes no sense to
>> initialize the m2p override functions very early. It can be done
>> later without doing any harm, removing the need for allocating memory
>> via extend_brk().
>>
>> While at it make some m2p override functions static as they are only
>> used internally.
> [...]
>>   		}
>>   		/* This should be the leafs allocated for identity from _brk. */
>>   	}
>> -	return (unsigned long)mfn_list;
>>
>> +	m2p_override_init();
>> +	return (unsigned long)mfn_list;
>>   }
>>   #else
>>   unsigned long __init xen_revector_p2m_tree(void)
>>   {
>>   	use_brk = 0;
>> +	m2p_override_init();
>>   	return 0;
>>   }
>
> This is mentioned in the description...
>
>>   #endif
>> @@ -794,15 +794,16 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>>   #define M2P_OVERRIDE_HASH_SHIFT	10
>>   #define M2P_OVERRIDE_HASH	(1 << M2P_OVERRIDE_HASH_SHIFT)
>>
>> -static RESERVE_BRK_ARRAY(struct list_head, m2p_overrides, M2P_OVERRIDE_HASH);
>> +static struct list_head *m2p_overrides;
>>   static DEFINE_SPINLOCK(m2p_override_lock);
>>
>>   static void __init m2p_override_init(void)
>>   {
>>   	unsigned i;
>>
>> -	m2p_overrides = extend_brk(sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
>> -				   sizeof(unsigned long));
>> +	m2p_overrides = alloc_bootmem_align(
>> +				sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
>> +				sizeof(unsigned long));
>
> ...as is this.
>
>> -int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
>> -			    struct gnttab_map_grant_ref *kmap_ops,
>> -			    struct page **pages, unsigned int count)
>> -{
>> -	int i, ret = 0;
>> -	bool lazy = false;
>> -	pte_t *pte;
>> -
>> -	if (xen_feature(XENFEAT_auto_translated_physmap))
>> -		return 0;
>> -
>> -	if (kmap_ops &&
>> -	    !in_interrupt() &&
>> -	    paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
>> -		arch_enter_lazy_mmu_mode();
>> -		lazy = true;
>> -	}
>
> ... but, what's going on here.  What are the rest of these changes?
>
> I suppose this is the "make some functions static" but it's an
> unreviewable mess.  If you can't do this with some one line changes
> adding "static" and perhaps some forward declarations then please drop
> this bit.

Do you really prefer forward declarations instead of pure code movement?
I can do as you request, but just want to make sure.

While I agree that the diff output is really ugly, comparing the old and
new code by looking at it in two editor windows side by side should show
the pure movement of functions easily.

Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:28:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:28:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmjah-0004Ad-7r; Fri, 07 Nov 2014 13:28:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xmjaf-0004AY-4x
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 13:28:37 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	F2/6B-02702-409CC545; Fri, 07 Nov 2014 13:28:36 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415366914!12047875!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27874 invoked from network); 7 Nov 2014 13:28:35 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:28:35 -0000
Received: by mail-wi0-f182.google.com with SMTP id d1so4538452wiv.3
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 05:28:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=2QBTMPIG76frSgIRdhCIiybvPVUkAM+nH6KacL5x8VQ=;
	b=NUrxwSJ4NJFeAw2uWkAoyCs6toLxv1JRcaek/hipfGtUYNH/gWcSQpJpKLyUhohzlG
	LKkWPljkViUkrbedh8a8XwuWRPrnKlZaU2NiASx0QsRq+O0Bv3dQXbGkRmvCE5EpZxsZ
	OIApLOxNVrY3xS1cyBUFenVU0SzuPalvtImrRNYaxn8lRlSERJao+RUR8FjWqIs3Q7xD
	yy+c8MYv9lulejrpJCMWGdHiCjDfBrMLSRK6Q6b7zJPsj00CY3sJKnWVGGZcKdbufR/0
	tDNvXrbK4/0GsSxHMsbYcONoF7IsemYWRhXn1QI/ffvFtWTASY8x3w86kjDzcHWMGYEH
	dBGw==
X-Gm-Message-State: ALoCoQnCkojO8WiZQKAfhk2KnSaTDwODR47nmTbdphUMWx6dfNWlFvGFHpkrViQRFKY9s1rIa4dc
X-Received: by 10.180.211.52 with SMTP id mz20mr5139992wic.15.1415366912910;
	Fri, 07 Nov 2014 05:28:32 -0800 (PST)
Received: from [192.168.42.189] (92.40.248.106.threembb.co.uk. [92.40.248.106])
	by mx.google.com with ESMTPSA id fr6sm2076846wic.1.2014.11.07.05.28.28
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 05:28:32 -0800 (PST)
Message-ID: <545CC8F9.2000902@linaro.org>
Date: Fri, 07 Nov 2014 13:28:25 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xenproject.org, konrad.wilk@oracle.com
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Konrad,

On 05/11/2014 13:04, Julien Grall wrote:
> The vGIC will emulate the same version as the hardware. The toolstack has
> to retrieve the version of the vGIC in order to be able to create the
> corresponding device tree node.
>
> A new DOMCTL has been introduced for ARM to configure the domain. For now
> it only allow the toolstack to retrieve the version of vGIC.
> This DOMCTL will be extend later to let the user choose the version of the
> emulated GIC.
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Wei Liu <wei.liu2@citrix.com>

I'd like to see this patch in rc2 or rc3. Do I have your release ack?

Regards,

> ---
> Stefano, I made one change in the guest memory layout, so I've dropped you
> Reviewed-by.
>
>      Changes in v3:
>          - Typo and update some comments
>          - Coding style
>          - Only reserve space for an 8 VCPUs redistributor in the guest
>          memory layout
>
>      Changes in v2:
>          - Use memcpu in xc_domain_configure
>          - Rename the DOMCTL into domctl_arm_configuredomain
>          - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>          and fold the code in arch_domain_init_hw_description
>          - Return -EOPNOTSUPP when the value of gic_version is not
>          supported
>
> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> defer the initialization of the vGIC [2].
>
> Xen 4.5 has already support for the hardware GICv3. While it's possible to
> boot and use DOM0, there is no guest support. The first version of this patch
> has been sent a couple of months ago, but has never reached unstable for
> various reasons (based on deferred series, lake of review at that time...).
> Without it, platform with GICv3 support won't be able to boot any guest.
>
> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
>
> Features such as adding a new config option to let the user choose the GIC
> version are deferred to Xen 4.6.
>
> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
>
> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> [2] https://patches.linaro.org/34664/
> ---
>   tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>   tools/libxc/include/xenctrl.h                |    6 ++
>   tools/libxc/xc_domain.c                      |   20 ++++++
>   tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
>   xen/arch/arm/domctl.c                        |   35 ++++++++++
>   xen/arch/arm/gic-v3.c                        |   16 ++++-
>   xen/include/public/arch-arm.h                |   16 +++++
>   xen/include/public/domctl.h                  |   17 +++++
>   xen/xsm/flask/hooks.c                        |    3 +
>   xen/xsm/flask/policy/access_vectors          |    2 +
>   10 files changed, 204 insertions(+), 8 deletions(-)
>
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> index 641c797..fa69c9d 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>   			getdomaininfo hypercall setvcpucontext setextvcpucontext
>   			getscheduler getvcpuinfo getvcpuextstate getaddrsize
>   			getaffinity setaffinity };
> -	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>   	allow $1 $2:security check_context;
>   	allow $1 $2:shadow enable;
>   	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 564e187..45e282c 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>                        uint32_t flags,
>                        uint32_t *pdomid);
>
> +#if defined(__arm__) || defined(__aarch64__)
> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> +
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config);
> +#endif
>
>   /* Functions to produce a dump of a given domain
>    *  xc_domain_dumpcore - produces a dump to a specified file
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index a9bcd4a..b071dea 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>       return 0;
>   }
>
> +#if defined(__arm__) || defined(__aarch64__)
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config)
> +{
> +    int rc;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> +    domctl.domain = (domid_t)domid;
> +    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
> +
> +    rc = do_domctl(xch, &domctl);
> +    if ( !rc )
> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> +
> +    return rc;
> +}
> +#endif
> +
>   int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
>                            xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
>   {
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index a122e4a..448ac07 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -23,6 +23,18 @@
>   #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
>   #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
>
> +static const char *gicv_to_string(uint8_t gic_version)
> +{
> +    switch (gic_version) {
> +    case XEN_DOMCTL_CONFIG_GIC_V2:
> +        return "V2";
> +    case XEN_DOMCTL_CONFIG_GIC_V3:
> +        return "V3";
> +    default:
> +        return "unknown";
> +    }
> +}
> +
>   int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>                                 uint32_t domid)
>   {
> @@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
>       return 0;
>   }
>
> -static int make_intc_node(libxl__gc *gc, void *fdt,
> -                          uint64_t gicd_base, uint64_t gicd_size,
> -                          uint64_t gicc_base, uint64_t gicc_size)
> +static int make_gicv2_node(libxl__gc *gc, void *fdt,
> +                           uint64_t gicd_base, uint64_t gicd_size,
> +                           uint64_t gicc_base, uint64_t gicc_size)
>   {
>       int res;
>       const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> @@ -350,6 +362,56 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
>       return 0;
>   }
>
> +static int make_gicv3_node(libxl__gc *gc, void *fdt)
> +{
> +    int res;
> +    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
> +    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
> +    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
> +    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
> +    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> +
> +    res = fdt_begin_node(fdt, name);
> +    if (res) return res;
> +
> +    res = fdt_property_compat(gc, fdt, 1, "arm,gic-v3");
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#address-cells", 0);
> +    if (res) return res;
> +
> +    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "redistributor-stride",
> +                            GUEST_GICV3_RDIST_STRIDE);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#redistributor-regions",
> +                            GUEST_GICV3_RDIST_REGIONS);
> +    if (res) return res;
> +
> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> +                            2,
> +                            gicd_base, gicd_size,
> +                            gicr0_base, gicr0_size);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_end_node(fdt);
> +    if (res) return res;
> +
> +    return 0;
> +}
> +
>   static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
>   {
>       int res;
> @@ -456,6 +518,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>                                              libxl_domain_build_info *info,
>                                              struct xc_dom_image *dom)
>   {
> +    xc_domain_configuration_t config;
>       void *fdt = NULL;
>       int rc, res;
>       size_t fdt_size = 0;
> @@ -471,8 +534,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>       ainfo = get_arch_info(gc, dom);
>       if (ainfo == NULL) return ERROR_FAIL;
>
> +    LOG(DEBUG, "configure the domain");
> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> +        LOG(ERROR, "couldn't configure the domain");
> +        return ERROR_FAIL;
> +    }
> +
>       LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
>           vers->xen_version_major, vers->xen_version_minor);
> +    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
>
>   /*
>    * Call "call" handling FDR_ERR_*. Will either:
> @@ -520,9 +591,21 @@ next_resize:
>           FDT( make_psci_node(gc, fdt) );
>
>           FDT( make_memory_nodes(gc, fdt, dom) );
> -        FDT( make_intc_node(gc, fdt,
> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> +
> +        switch (config.gic_version) {
> +        case XEN_DOMCTL_CONFIG_GIC_V2:
> +            FDT( make_gicv2_node(gc, fdt,
> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> +            break;
> +        case XEN_DOMCTL_CONFIG_GIC_V3:
> +            FDT( make_gicv3_node(gc, fdt) );
> +            break;
> +        default:
> +            LOG(ERROR, "Unknown GIC version %d", config.gic_version);
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
>
>           FDT( make_timer_node(gc, fdt, ainfo) );
>           FDT( make_hypervisor_node(gc, fdt, vers) );
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 45974e7..d246e84 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -10,6 +10,8 @@
>   #include <xen/errno.h>
>   #include <xen/sched.h>
>   #include <xen/hypercall.h>
> +#include <asm/gic.h>
> +#include <xen/guest_access.h>
>   #include <public/domctl.h>
>
>   long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>
>           return p2m_cache_flush(d, s, e);
>       }
> +    case XEN_DOMCTL_arm_configure_domain:
> +    {
> +        uint8_t gic_version;
> +
> +        /*
> +         * Currently the vGIC is emulating the same version of the
> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> +         * is allowed. The DOMCTL will return the actual version of the
> +         * GIC.
> +         */
> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> +            return -EOPNOTSUPP;
> +
> +        switch ( gic_hw_version() )
> +        {
> +        case GIC_V3:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> +            break;
> +        case GIC_V2:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> +            break;
> +        default:
> +            BUG();
> +        }
> +
> +        domctl->u.configuredomain.gic_version = gic_version;
> +
> +        /* TODO: Make the copy generic for all ARCH domctl */
> +        if ( __copy_to_guest(u_domctl, domctl, 1) )
> +            return -EFAULT;
> +
> +        return 0;
> +    }
>
>       default:
>           return subarch_do_domctl(domctl, d, u_domctl);
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 91161a2..076aa62 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
>           d->arch.vgic.rdist_count = gicv3.rdist_count;
>       }
>       else
> -        d->arch.vgic.dbase = GUEST_GICD_BASE;
> +    {
> +        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
> +        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
> +
> +        /* XXX: Only one Re-distributor region mapped for the guest */
> +        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
> +
> +        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
> +        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
> +
> +        /* The first redistributor should contain enough space for all CPUs */
> +        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
> +        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
> +        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
> +    }
>
>       d->arch.vgic.nr_lines = 0;
>
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index eecc561..72d641f 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
>    */
>
>   /* Physical Address Space */
> +
> +/* vGIC mappings: Only one set of mapping is used by the guest.
> + * Therefore they can overlap.
> + */
> +
> +/* vGIC v2 mappings */
>   #define GUEST_GICD_BASE   0x03001000ULL
>   #define GUEST_GICD_SIZE   0x00001000ULL
>   #define GUEST_GICC_BASE   0x03002000ULL
>   #define GUEST_GICC_SIZE   0x00000100ULL
>
> +/* vGIC v3 mappings */
> +#define GUEST_GICV3_GICD_BASE      0x03001000ULL
> +#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
> +
> +#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
> +#define GUEST_GICV3_RDIST_REGIONS  1
> +
> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU7 */
> +#define GUEST_GICV3_GICR0_SIZE     0x00100000ULL
> +
>   /* 16MB == 4096 pages reserved for guest to use as a region to map its
>    * grant table in.
>    */
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 58b19e7..8da204e 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
>   typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
>
> +#if defined(__arm__) || defined(__aarch64__)
> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
> +/* XEN_DOMCTL_configure_domain */
> +struct xen_domctl_arm_configuredomain {
> +    /* IN/OUT parameters */
> +    uint8_t gic_version;
> +};
> +typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
> +#endif
> +
>   /* XEN_DOMCTL_getdomaininfo */
>   struct xen_domctl_getdomaininfo {
>       /* OUT variables. */
> @@ -1056,6 +1069,7 @@ struct xen_domctl {
>   #define XEN_DOMCTL_set_vcpu_msrs                 73
>   #define XEN_DOMCTL_setvnumainfo                  74
>   #define XEN_DOMCTL_psr_cmt_op                    75
> +#define XEN_DOMCTL_arm_configure_domain          76
>   #define XEN_DOMCTL_gdbsx_guestmemio            1000
>   #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>   #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -1064,6 +1078,9 @@ struct xen_domctl {
>       domid_t  domain;
>       union {
>           struct xen_domctl_createdomain      createdomain;
> +#if defined(__arm__) || defined(__aarch64__)
> +        struct xen_domctl_arm_configuredomain configuredomain;
> +#endif
>           struct xen_domctl_getdomaininfo     getdomaininfo;
>           struct xen_domctl_getmemlist        getmemlist;
>           struct xen_domctl_getpageframeinfo  getpageframeinfo;
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 6d0fe72..846cf88 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
>       case XEN_DOMCTL_psr_cmt_op:
>           return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
>
> +    case XEN_DOMCTL_configure_domain:
> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
> +
>       default:
>           printk("flask_domctl: Unknown op %d\n", cmd);
>           return -EPERM;
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index de0c707..bfe2fa5 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -216,6 +216,8 @@ class domain2
>       get_vnumainfo
>   # XEN_DOMCTL_psr_cmt_op
>       psr_cmt_op
> +# XEN_DOMCTL_configure_domain
> +    configure_domain
>   }
>
>   # Similar to class domain, but primarily contains domctls related to HVM domains
>

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:28:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:28:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmjah-0004Ad-7r; Fri, 07 Nov 2014 13:28:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xmjaf-0004AY-4x
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 13:28:37 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	F2/6B-02702-409CC545; Fri, 07 Nov 2014 13:28:36 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415366914!12047875!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27874 invoked from network); 7 Nov 2014 13:28:35 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:28:35 -0000
Received: by mail-wi0-f182.google.com with SMTP id d1so4538452wiv.3
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 05:28:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=2QBTMPIG76frSgIRdhCIiybvPVUkAM+nH6KacL5x8VQ=;
	b=NUrxwSJ4NJFeAw2uWkAoyCs6toLxv1JRcaek/hipfGtUYNH/gWcSQpJpKLyUhohzlG
	LKkWPljkViUkrbedh8a8XwuWRPrnKlZaU2NiASx0QsRq+O0Bv3dQXbGkRmvCE5EpZxsZ
	OIApLOxNVrY3xS1cyBUFenVU0SzuPalvtImrRNYaxn8lRlSERJao+RUR8FjWqIs3Q7xD
	yy+c8MYv9lulejrpJCMWGdHiCjDfBrMLSRK6Q6b7zJPsj00CY3sJKnWVGGZcKdbufR/0
	tDNvXrbK4/0GsSxHMsbYcONoF7IsemYWRhXn1QI/ffvFtWTASY8x3w86kjDzcHWMGYEH
	dBGw==
X-Gm-Message-State: ALoCoQnCkojO8WiZQKAfhk2KnSaTDwODR47nmTbdphUMWx6dfNWlFvGFHpkrViQRFKY9s1rIa4dc
X-Received: by 10.180.211.52 with SMTP id mz20mr5139992wic.15.1415366912910;
	Fri, 07 Nov 2014 05:28:32 -0800 (PST)
Received: from [192.168.42.189] (92.40.248.106.threembb.co.uk. [92.40.248.106])
	by mx.google.com with ESMTPSA id fr6sm2076846wic.1.2014.11.07.05.28.28
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 05:28:32 -0800 (PST)
Message-ID: <545CC8F9.2000902@linaro.org>
Date: Fri, 07 Nov 2014 13:28:25 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xenproject.org, konrad.wilk@oracle.com
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Konrad,

On 05/11/2014 13:04, Julien Grall wrote:
> The vGIC will emulate the same version as the hardware. The toolstack has
> to retrieve the version of the vGIC in order to be able to create the
> corresponding device tree node.
>
> A new DOMCTL has been introduced for ARM to configure the domain. For now
> it only allow the toolstack to retrieve the version of vGIC.
> This DOMCTL will be extend later to let the user choose the version of the
> emulated GIC.
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Wei Liu <wei.liu2@citrix.com>

I'd like to see this patch in rc2 or rc3. Do I have your release ack?

Regards,

> ---
> Stefano, I made one change in the guest memory layout, so I've dropped you
> Reviewed-by.
>
>      Changes in v3:
>          - Typo and update some comments
>          - Coding style
>          - Only reserve space for an 8 VCPUs redistributor in the guest
>          memory layout
>
>      Changes in v2:
>          - Use memcpu in xc_domain_configure
>          - Rename the DOMCTL into domctl_arm_configuredomain
>          - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>          and fold the code in arch_domain_init_hw_description
>          - Return -EOPNOTSUPP when the value of gic_version is not
>          supported
>
> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> defer the initialization of the vGIC [2].
>
> Xen 4.5 has already support for the hardware GICv3. While it's possible to
> boot and use DOM0, there is no guest support. The first version of this patch
> has been sent a couple of months ago, but has never reached unstable for
> various reasons (based on deferred series, lake of review at that time...).
> Without it, platform with GICv3 support won't be able to boot any guest.
>
> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
>
> Features such as adding a new config option to let the user choose the GIC
> version are deferred to Xen 4.6.
>
> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
>
> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> [2] https://patches.linaro.org/34664/
> ---
>   tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>   tools/libxc/include/xenctrl.h                |    6 ++
>   tools/libxc/xc_domain.c                      |   20 ++++++
>   tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
>   xen/arch/arm/domctl.c                        |   35 ++++++++++
>   xen/arch/arm/gic-v3.c                        |   16 ++++-
>   xen/include/public/arch-arm.h                |   16 +++++
>   xen/include/public/domctl.h                  |   17 +++++
>   xen/xsm/flask/hooks.c                        |    3 +
>   xen/xsm/flask/policy/access_vectors          |    2 +
>   10 files changed, 204 insertions(+), 8 deletions(-)
>
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> index 641c797..fa69c9d 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>   			getdomaininfo hypercall setvcpucontext setextvcpucontext
>   			getscheduler getvcpuinfo getvcpuextstate getaddrsize
>   			getaffinity setaffinity };
> -	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>   	allow $1 $2:security check_context;
>   	allow $1 $2:shadow enable;
>   	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 564e187..45e282c 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>                        uint32_t flags,
>                        uint32_t *pdomid);
>
> +#if defined(__arm__) || defined(__aarch64__)
> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> +
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config);
> +#endif
>
>   /* Functions to produce a dump of a given domain
>    *  xc_domain_dumpcore - produces a dump to a specified file
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index a9bcd4a..b071dea 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>       return 0;
>   }
>
> +#if defined(__arm__) || defined(__aarch64__)
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config)
> +{
> +    int rc;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> +    domctl.domain = (domid_t)domid;
> +    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
> +
> +    rc = do_domctl(xch, &domctl);
> +    if ( !rc )
> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> +
> +    return rc;
> +}
> +#endif
> +
>   int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
>                            xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
>   {
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index a122e4a..448ac07 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -23,6 +23,18 @@
>   #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
>   #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
>
> +static const char *gicv_to_string(uint8_t gic_version)
> +{
> +    switch (gic_version) {
> +    case XEN_DOMCTL_CONFIG_GIC_V2:
> +        return "V2";
> +    case XEN_DOMCTL_CONFIG_GIC_V3:
> +        return "V3";
> +    default:
> +        return "unknown";
> +    }
> +}
> +
>   int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>                                 uint32_t domid)
>   {
> @@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
>       return 0;
>   }
>
> -static int make_intc_node(libxl__gc *gc, void *fdt,
> -                          uint64_t gicd_base, uint64_t gicd_size,
> -                          uint64_t gicc_base, uint64_t gicc_size)
> +static int make_gicv2_node(libxl__gc *gc, void *fdt,
> +                           uint64_t gicd_base, uint64_t gicd_size,
> +                           uint64_t gicc_base, uint64_t gicc_size)
>   {
>       int res;
>       const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> @@ -350,6 +362,56 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
>       return 0;
>   }
>
> +static int make_gicv3_node(libxl__gc *gc, void *fdt)
> +{
> +    int res;
> +    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
> +    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
> +    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
> +    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
> +    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> +
> +    res = fdt_begin_node(fdt, name);
> +    if (res) return res;
> +
> +    res = fdt_property_compat(gc, fdt, 1, "arm,gic-v3");
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#address-cells", 0);
> +    if (res) return res;
> +
> +    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "redistributor-stride",
> +                            GUEST_GICV3_RDIST_STRIDE);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#redistributor-regions",
> +                            GUEST_GICV3_RDIST_REGIONS);
> +    if (res) return res;
> +
> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> +                            2,
> +                            gicd_base, gicd_size,
> +                            gicr0_base, gicr0_size);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_end_node(fdt);
> +    if (res) return res;
> +
> +    return 0;
> +}
> +
>   static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
>   {
>       int res;
> @@ -456,6 +518,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>                                              libxl_domain_build_info *info,
>                                              struct xc_dom_image *dom)
>   {
> +    xc_domain_configuration_t config;
>       void *fdt = NULL;
>       int rc, res;
>       size_t fdt_size = 0;
> @@ -471,8 +534,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>       ainfo = get_arch_info(gc, dom);
>       if (ainfo == NULL) return ERROR_FAIL;
>
> +    LOG(DEBUG, "configure the domain");
> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> +        LOG(ERROR, "couldn't configure the domain");
> +        return ERROR_FAIL;
> +    }
> +
>       LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
>           vers->xen_version_major, vers->xen_version_minor);
> +    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
>
>   /*
>    * Call "call" handling FDR_ERR_*. Will either:
> @@ -520,9 +591,21 @@ next_resize:
>           FDT( make_psci_node(gc, fdt) );
>
>           FDT( make_memory_nodes(gc, fdt, dom) );
> -        FDT( make_intc_node(gc, fdt,
> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> +
> +        switch (config.gic_version) {
> +        case XEN_DOMCTL_CONFIG_GIC_V2:
> +            FDT( make_gicv2_node(gc, fdt,
> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> +            break;
> +        case XEN_DOMCTL_CONFIG_GIC_V3:
> +            FDT( make_gicv3_node(gc, fdt) );
> +            break;
> +        default:
> +            LOG(ERROR, "Unknown GIC version %d", config.gic_version);
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
>
>           FDT( make_timer_node(gc, fdt, ainfo) );
>           FDT( make_hypervisor_node(gc, fdt, vers) );
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 45974e7..d246e84 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -10,6 +10,8 @@
>   #include <xen/errno.h>
>   #include <xen/sched.h>
>   #include <xen/hypercall.h>
> +#include <asm/gic.h>
> +#include <xen/guest_access.h>
>   #include <public/domctl.h>
>
>   long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>
>           return p2m_cache_flush(d, s, e);
>       }
> +    case XEN_DOMCTL_arm_configure_domain:
> +    {
> +        uint8_t gic_version;
> +
> +        /*
> +         * Currently the vGIC is emulating the same version of the
> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> +         * is allowed. The DOMCTL will return the actual version of the
> +         * GIC.
> +         */
> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> +            return -EOPNOTSUPP;
> +
> +        switch ( gic_hw_version() )
> +        {
> +        case GIC_V3:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> +            break;
> +        case GIC_V2:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> +            break;
> +        default:
> +            BUG();
> +        }
> +
> +        domctl->u.configuredomain.gic_version = gic_version;
> +
> +        /* TODO: Make the copy generic for all ARCH domctl */
> +        if ( __copy_to_guest(u_domctl, domctl, 1) )
> +            return -EFAULT;
> +
> +        return 0;
> +    }
>
>       default:
>           return subarch_do_domctl(domctl, d, u_domctl);
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 91161a2..076aa62 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
>           d->arch.vgic.rdist_count = gicv3.rdist_count;
>       }
>       else
> -        d->arch.vgic.dbase = GUEST_GICD_BASE;
> +    {
> +        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
> +        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
> +
> +        /* XXX: Only one Re-distributor region mapped for the guest */
> +        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
> +
> +        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
> +        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
> +
> +        /* The first redistributor should contain enough space for all CPUs */
> +        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
> +        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
> +        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
> +    }
>
>       d->arch.vgic.nr_lines = 0;
>
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index eecc561..72d641f 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
>    */
>
>   /* Physical Address Space */
> +
> +/* vGIC mappings: Only one set of mapping is used by the guest.
> + * Therefore they can overlap.
> + */
> +
> +/* vGIC v2 mappings */
>   #define GUEST_GICD_BASE   0x03001000ULL
>   #define GUEST_GICD_SIZE   0x00001000ULL
>   #define GUEST_GICC_BASE   0x03002000ULL
>   #define GUEST_GICC_SIZE   0x00000100ULL
>
> +/* vGIC v3 mappings */
> +#define GUEST_GICV3_GICD_BASE      0x03001000ULL
> +#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
> +
> +#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
> +#define GUEST_GICV3_RDIST_REGIONS  1
> +
> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU7 */
> +#define GUEST_GICV3_GICR0_SIZE     0x00100000ULL
> +
>   /* 16MB == 4096 pages reserved for guest to use as a region to map its
>    * grant table in.
>    */
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 58b19e7..8da204e 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
>   typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
>
> +#if defined(__arm__) || defined(__aarch64__)
> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
> +/* XEN_DOMCTL_configure_domain */
> +struct xen_domctl_arm_configuredomain {
> +    /* IN/OUT parameters */
> +    uint8_t gic_version;
> +};
> +typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
> +#endif
> +
>   /* XEN_DOMCTL_getdomaininfo */
>   struct xen_domctl_getdomaininfo {
>       /* OUT variables. */
> @@ -1056,6 +1069,7 @@ struct xen_domctl {
>   #define XEN_DOMCTL_set_vcpu_msrs                 73
>   #define XEN_DOMCTL_setvnumainfo                  74
>   #define XEN_DOMCTL_psr_cmt_op                    75
> +#define XEN_DOMCTL_arm_configure_domain          76
>   #define XEN_DOMCTL_gdbsx_guestmemio            1000
>   #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>   #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -1064,6 +1078,9 @@ struct xen_domctl {
>       domid_t  domain;
>       union {
>           struct xen_domctl_createdomain      createdomain;
> +#if defined(__arm__) || defined(__aarch64__)
> +        struct xen_domctl_arm_configuredomain configuredomain;
> +#endif
>           struct xen_domctl_getdomaininfo     getdomaininfo;
>           struct xen_domctl_getmemlist        getmemlist;
>           struct xen_domctl_getpageframeinfo  getpageframeinfo;
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 6d0fe72..846cf88 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
>       case XEN_DOMCTL_psr_cmt_op:
>           return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
>
> +    case XEN_DOMCTL_configure_domain:
> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
> +
>       default:
>           printk("flask_domctl: Unknown op %d\n", cmd);
>           return -EPERM;
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index de0c707..bfe2fa5 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -216,6 +216,8 @@ class domain2
>       get_vnumainfo
>   # XEN_DOMCTL_psr_cmt_op
>       psr_cmt_op
> +# XEN_DOMCTL_configure_domain
> +    configure_domain
>   }
>
>   # Similar to class domain, but primarily contains domctls related to HVM domains
>

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:31:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmjcw-0004GQ-On; Fri, 07 Nov 2014 13:30:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xmjcv-0004GJ-MY
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 13:30:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BA/25-24532-099CC545; Fri, 07 Nov 2014 13:30:56 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415367055!8780934!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13356 invoked from network); 7 Nov 2014 13:30:55 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:30:55 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so3764787wgg.16
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 05:30:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=tS4UxOQk/DkiOwkZgYACXSupsVO8yPZ/r/fAd6H0Y/k=;
	b=JI+FRqhJ1LFgK2C8krtYqRZ9RU9P1d/LHiNNFxiAK2lOWsG7hiUtzOSntF9hDDL8+P
	9RtEURZAHI1XczOpMW5WUzNmR8gJAMyCIktnZCG0ltsT3p7lubHPyT8GolaJvVysqDaF
	14dUwLsFJA4BhT69JI9kbCfuej2dfCVrAaoArn+bKBeRIWdqHvI8j5IXrDAg19Uewwij
	xEqKZl8g+B2shYF1kZbXzUacTLGzpWnutFrdU+8pWx8i+XTB9Gybfx+TAK4KRkI8GLIL
	tXrAc1XVWyAbWZvSfk73NPS2trQVBXNq5IGgln/Mz361Bj7o8AjsQTaMc+hHbDHz6D/x
	5dJQ==
X-Gm-Message-State: ALoCoQn+oJqLIJZx75mWZnoJ/rI4JXP7fC79AStv65xYJ24SEW2K/BHnLtrb9cbrAE76V88D4MXN
X-Received: by 10.194.24.197 with SMTP id w5mr16573127wjf.71.1415367055264;
	Fri, 07 Nov 2014 05:30:55 -0800 (PST)
Received: from [192.168.42.189] (92.40.248.106.threembb.co.uk. [92.40.248.106])
	by mx.google.com with ESMTPSA id v10sm2055255wiy.21.2014.11.07.05.30.51
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 05:30:54 -0800 (PST)
Message-ID: <545CC988.5000000@linaro.org>
Date: Fri, 07 Nov 2014 13:30:48 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xenproject.org
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

On 05/11/2014 13:04, Julien Grall wrote:
> The vGIC will emulate the same version as the hardware. The toolstack has
> to retrieve the version of the vGIC in order to be able to create the
> corresponding device tree node.
>
> A new DOMCTL has been introduced for ARM to configure the domain. For now
> it only allow the toolstack to retrieve the version of vGIC.
> This DOMCTL will be extend later to let the user choose the version of the
> emulated GIC.
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>

I forgot to keep the Ack from Daniel on v2:

http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00230.html

Regards,

> Cc: Wei Liu <wei.liu2@citrix.com>
>
> ---
> Stefano, I made one change in the guest memory layout, so I've dropped you
> Reviewed-by.
>
>      Changes in v3:
>          - Typo and update some comments
>          - Coding style
>          - Only reserve space for an 8 VCPUs redistributor in the guest
>          memory layout
>
>      Changes in v2:
>          - Use memcpu in xc_domain_configure
>          - Rename the DOMCTL into domctl_arm_configuredomain
>          - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>          and fold the code in arch_domain_init_hw_description
>          - Return -EOPNOTSUPP when the value of gic_version is not
>          supported
>
> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> defer the initialization of the vGIC [2].
>
> Xen 4.5 has already support for the hardware GICv3. While it's possible to
> boot and use DOM0, there is no guest support. The first version of this patch
> has been sent a couple of months ago, but has never reached unstable for
> various reasons (based on deferred series, lake of review at that time...).
> Without it, platform with GICv3 support won't be able to boot any guest.
>
> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
>
> Features such as adding a new config option to let the user choose the GIC
> version are deferred to Xen 4.6.
>
> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
>
> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> [2] https://patches.linaro.org/34664/
> ---
>   tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>   tools/libxc/include/xenctrl.h                |    6 ++
>   tools/libxc/xc_domain.c                      |   20 ++++++
>   tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
>   xen/arch/arm/domctl.c                        |   35 ++++++++++
>   xen/arch/arm/gic-v3.c                        |   16 ++++-
>   xen/include/public/arch-arm.h                |   16 +++++
>   xen/include/public/domctl.h                  |   17 +++++
>   xen/xsm/flask/hooks.c                        |    3 +
>   xen/xsm/flask/policy/access_vectors          |    2 +
>   10 files changed, 204 insertions(+), 8 deletions(-)
>
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> index 641c797..fa69c9d 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>   			getdomaininfo hypercall setvcpucontext setextvcpucontext
>   			getscheduler getvcpuinfo getvcpuextstate getaddrsize
>   			getaffinity setaffinity };
> -	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>   	allow $1 $2:security check_context;
>   	allow $1 $2:shadow enable;
>   	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 564e187..45e282c 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>                        uint32_t flags,
>                        uint32_t *pdomid);
>
> +#if defined(__arm__) || defined(__aarch64__)
> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> +
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config);
> +#endif
>
>   /* Functions to produce a dump of a given domain
>    *  xc_domain_dumpcore - produces a dump to a specified file
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index a9bcd4a..b071dea 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>       return 0;
>   }
>
> +#if defined(__arm__) || defined(__aarch64__)
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config)
> +{
> +    int rc;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> +    domctl.domain = (domid_t)domid;
> +    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
> +
> +    rc = do_domctl(xch, &domctl);
> +    if ( !rc )
> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> +
> +    return rc;
> +}
> +#endif
> +
>   int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
>                            xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
>   {
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index a122e4a..448ac07 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -23,6 +23,18 @@
>   #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
>   #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
>
> +static const char *gicv_to_string(uint8_t gic_version)
> +{
> +    switch (gic_version) {
> +    case XEN_DOMCTL_CONFIG_GIC_V2:
> +        return "V2";
> +    case XEN_DOMCTL_CONFIG_GIC_V3:
> +        return "V3";
> +    default:
> +        return "unknown";
> +    }
> +}
> +
>   int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>                                 uint32_t domid)
>   {
> @@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
>       return 0;
>   }
>
> -static int make_intc_node(libxl__gc *gc, void *fdt,
> -                          uint64_t gicd_base, uint64_t gicd_size,
> -                          uint64_t gicc_base, uint64_t gicc_size)
> +static int make_gicv2_node(libxl__gc *gc, void *fdt,
> +                           uint64_t gicd_base, uint64_t gicd_size,
> +                           uint64_t gicc_base, uint64_t gicc_size)
>   {
>       int res;
>       const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> @@ -350,6 +362,56 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
>       return 0;
>   }
>
> +static int make_gicv3_node(libxl__gc *gc, void *fdt)
> +{
> +    int res;
> +    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
> +    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
> +    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
> +    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
> +    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> +
> +    res = fdt_begin_node(fdt, name);
> +    if (res) return res;
> +
> +    res = fdt_property_compat(gc, fdt, 1, "arm,gic-v3");
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#address-cells", 0);
> +    if (res) return res;
> +
> +    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "redistributor-stride",
> +                            GUEST_GICV3_RDIST_STRIDE);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#redistributor-regions",
> +                            GUEST_GICV3_RDIST_REGIONS);
> +    if (res) return res;
> +
> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> +                            2,
> +                            gicd_base, gicd_size,
> +                            gicr0_base, gicr0_size);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_end_node(fdt);
> +    if (res) return res;
> +
> +    return 0;
> +}
> +
>   static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
>   {
>       int res;
> @@ -456,6 +518,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>                                              libxl_domain_build_info *info,
>                                              struct xc_dom_image *dom)
>   {
> +    xc_domain_configuration_t config;
>       void *fdt = NULL;
>       int rc, res;
>       size_t fdt_size = 0;
> @@ -471,8 +534,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>       ainfo = get_arch_info(gc, dom);
>       if (ainfo == NULL) return ERROR_FAIL;
>
> +    LOG(DEBUG, "configure the domain");
> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> +        LOG(ERROR, "couldn't configure the domain");
> +        return ERROR_FAIL;
> +    }
> +
>       LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
>           vers->xen_version_major, vers->xen_version_minor);
> +    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
>
>   /*
>    * Call "call" handling FDR_ERR_*. Will either:
> @@ -520,9 +591,21 @@ next_resize:
>           FDT( make_psci_node(gc, fdt) );
>
>           FDT( make_memory_nodes(gc, fdt, dom) );
> -        FDT( make_intc_node(gc, fdt,
> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> +
> +        switch (config.gic_version) {
> +        case XEN_DOMCTL_CONFIG_GIC_V2:
> +            FDT( make_gicv2_node(gc, fdt,
> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> +            break;
> +        case XEN_DOMCTL_CONFIG_GIC_V3:
> +            FDT( make_gicv3_node(gc, fdt) );
> +            break;
> +        default:
> +            LOG(ERROR, "Unknown GIC version %d", config.gic_version);
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
>
>           FDT( make_timer_node(gc, fdt, ainfo) );
>           FDT( make_hypervisor_node(gc, fdt, vers) );
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 45974e7..d246e84 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -10,6 +10,8 @@
>   #include <xen/errno.h>
>   #include <xen/sched.h>
>   #include <xen/hypercall.h>
> +#include <asm/gic.h>
> +#include <xen/guest_access.h>
>   #include <public/domctl.h>
>
>   long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>
>           return p2m_cache_flush(d, s, e);
>       }
> +    case XEN_DOMCTL_arm_configure_domain:
> +    {
> +        uint8_t gic_version;
> +
> +        /*
> +         * Currently the vGIC is emulating the same version of the
> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> +         * is allowed. The DOMCTL will return the actual version of the
> +         * GIC.
> +         */
> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> +            return -EOPNOTSUPP;
> +
> +        switch ( gic_hw_version() )
> +        {
> +        case GIC_V3:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> +            break;
> +        case GIC_V2:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> +            break;
> +        default:
> +            BUG();
> +        }
> +
> +        domctl->u.configuredomain.gic_version = gic_version;
> +
> +        /* TODO: Make the copy generic for all ARCH domctl */
> +        if ( __copy_to_guest(u_domctl, domctl, 1) )
> +            return -EFAULT;
> +
> +        return 0;
> +    }
>
>       default:
>           return subarch_do_domctl(domctl, d, u_domctl);
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 91161a2..076aa62 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
>           d->arch.vgic.rdist_count = gicv3.rdist_count;
>       }
>       else
> -        d->arch.vgic.dbase = GUEST_GICD_BASE;
> +    {
> +        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
> +        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
> +
> +        /* XXX: Only one Re-distributor region mapped for the guest */
> +        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
> +
> +        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
> +        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
> +
> +        /* The first redistributor should contain enough space for all CPUs */
> +        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
> +        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
> +        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
> +    }
>
>       d->arch.vgic.nr_lines = 0;
>
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index eecc561..72d641f 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
>    */
>
>   /* Physical Address Space */
> +
> +/* vGIC mappings: Only one set of mapping is used by the guest.
> + * Therefore they can overlap.
> + */
> +
> +/* vGIC v2 mappings */
>   #define GUEST_GICD_BASE   0x03001000ULL
>   #define GUEST_GICD_SIZE   0x00001000ULL
>   #define GUEST_GICC_BASE   0x03002000ULL
>   #define GUEST_GICC_SIZE   0x00000100ULL
>
> +/* vGIC v3 mappings */
> +#define GUEST_GICV3_GICD_BASE      0x03001000ULL
> +#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
> +
> +#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
> +#define GUEST_GICV3_RDIST_REGIONS  1
> +
> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU7 */
> +#define GUEST_GICV3_GICR0_SIZE     0x00100000ULL
> +
>   /* 16MB == 4096 pages reserved for guest to use as a region to map its
>    * grant table in.
>    */
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 58b19e7..8da204e 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
>   typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
>
> +#if defined(__arm__) || defined(__aarch64__)
> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
> +/* XEN_DOMCTL_configure_domain */
> +struct xen_domctl_arm_configuredomain {
> +    /* IN/OUT parameters */
> +    uint8_t gic_version;
> +};
> +typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
> +#endif
> +
>   /* XEN_DOMCTL_getdomaininfo */
>   struct xen_domctl_getdomaininfo {
>       /* OUT variables. */
> @@ -1056,6 +1069,7 @@ struct xen_domctl {
>   #define XEN_DOMCTL_set_vcpu_msrs                 73
>   #define XEN_DOMCTL_setvnumainfo                  74
>   #define XEN_DOMCTL_psr_cmt_op                    75
> +#define XEN_DOMCTL_arm_configure_domain          76
>   #define XEN_DOMCTL_gdbsx_guestmemio            1000
>   #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>   #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -1064,6 +1078,9 @@ struct xen_domctl {
>       domid_t  domain;
>       union {
>           struct xen_domctl_createdomain      createdomain;
> +#if defined(__arm__) || defined(__aarch64__)
> +        struct xen_domctl_arm_configuredomain configuredomain;
> +#endif
>           struct xen_domctl_getdomaininfo     getdomaininfo;
>           struct xen_domctl_getmemlist        getmemlist;
>           struct xen_domctl_getpageframeinfo  getpageframeinfo;
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 6d0fe72..846cf88 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
>       case XEN_DOMCTL_psr_cmt_op:
>           return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
>
> +    case XEN_DOMCTL_configure_domain:
> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
> +
>       default:
>           printk("flask_domctl: Unknown op %d\n", cmd);
>           return -EPERM;
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index de0c707..bfe2fa5 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -216,6 +216,8 @@ class domain2
>       get_vnumainfo
>   # XEN_DOMCTL_psr_cmt_op
>       psr_cmt_op
> +# XEN_DOMCTL_configure_domain
> +    configure_domain
>   }
>
>   # Similar to class domain, but primarily contains domctls related to HVM domains
>

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:31:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmjcw-0004GQ-On; Fri, 07 Nov 2014 13:30:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xmjcv-0004GJ-MY
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 13:30:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BA/25-24532-099CC545; Fri, 07 Nov 2014 13:30:56 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415367055!8780934!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13356 invoked from network); 7 Nov 2014 13:30:55 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:30:55 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so3764787wgg.16
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 05:30:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=tS4UxOQk/DkiOwkZgYACXSupsVO8yPZ/r/fAd6H0Y/k=;
	b=JI+FRqhJ1LFgK2C8krtYqRZ9RU9P1d/LHiNNFxiAK2lOWsG7hiUtzOSntF9hDDL8+P
	9RtEURZAHI1XczOpMW5WUzNmR8gJAMyCIktnZCG0ltsT3p7lubHPyT8GolaJvVysqDaF
	14dUwLsFJA4BhT69JI9kbCfuej2dfCVrAaoArn+bKBeRIWdqHvI8j5IXrDAg19Uewwij
	xEqKZl8g+B2shYF1kZbXzUacTLGzpWnutFrdU+8pWx8i+XTB9Gybfx+TAK4KRkI8GLIL
	tXrAc1XVWyAbWZvSfk73NPS2trQVBXNq5IGgln/Mz361Bj7o8AjsQTaMc+hHbDHz6D/x
	5dJQ==
X-Gm-Message-State: ALoCoQn+oJqLIJZx75mWZnoJ/rI4JXP7fC79AStv65xYJ24SEW2K/BHnLtrb9cbrAE76V88D4MXN
X-Received: by 10.194.24.197 with SMTP id w5mr16573127wjf.71.1415367055264;
	Fri, 07 Nov 2014 05:30:55 -0800 (PST)
Received: from [192.168.42.189] (92.40.248.106.threembb.co.uk. [92.40.248.106])
	by mx.google.com with ESMTPSA id v10sm2055255wiy.21.2014.11.07.05.30.51
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 05:30:54 -0800 (PST)
Message-ID: <545CC988.5000000@linaro.org>
Date: Fri, 07 Nov 2014 13:30:48 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xenproject.org
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

On 05/11/2014 13:04, Julien Grall wrote:
> The vGIC will emulate the same version as the hardware. The toolstack has
> to retrieve the version of the vGIC in order to be able to create the
> corresponding device tree node.
>
> A new DOMCTL has been introduced for ARM to configure the domain. For now
> it only allow the toolstack to retrieve the version of vGIC.
> This DOMCTL will be extend later to let the user choose the version of the
> emulated GIC.
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>

I forgot to keep the Ack from Daniel on v2:

http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00230.html

Regards,

> Cc: Wei Liu <wei.liu2@citrix.com>
>
> ---
> Stefano, I made one change in the guest memory layout, so I've dropped you
> Reviewed-by.
>
>      Changes in v3:
>          - Typo and update some comments
>          - Coding style
>          - Only reserve space for an 8 VCPUs redistributor in the guest
>          memory layout
>
>      Changes in v2:
>          - Use memcpu in xc_domain_configure
>          - Rename the DOMCTL into domctl_arm_configuredomain
>          - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
>          and fold the code in arch_domain_init_hw_description
>          - Return -EOPNOTSUPP when the value of gic_version is not
>          supported
>
> This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> defer the initialization of the vGIC [2].
>
> Xen 4.5 has already support for the hardware GICv3. While it's possible to
> boot and use DOM0, there is no guest support. The first version of this patch
> has been sent a couple of months ago, but has never reached unstable for
> various reasons (based on deferred series, lake of review at that time...).
> Without it, platform with GICv3 support won't be able to boot any guest.
>
> The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
>
> Features such as adding a new config option to let the user choose the GIC
> version are deferred to Xen 4.6.
>
> It has been tested on both GICv2/GICv3 platform. And build tested for x86.
>
> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> [2] https://patches.linaro.org/34664/
> ---
>   tools/flask/policy/policy/modules/xen/xen.if |    2 +-
>   tools/libxc/include/xenctrl.h                |    6 ++
>   tools/libxc/xc_domain.c                      |   20 ++++++
>   tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
>   xen/arch/arm/domctl.c                        |   35 ++++++++++
>   xen/arch/arm/gic-v3.c                        |   16 ++++-
>   xen/include/public/arch-arm.h                |   16 +++++
>   xen/include/public/domctl.h                  |   17 +++++
>   xen/xsm/flask/hooks.c                        |    3 +
>   xen/xsm/flask/policy/access_vectors          |    2 +
>   10 files changed, 204 insertions(+), 8 deletions(-)
>
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> index 641c797..fa69c9d 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>   			getdomaininfo hypercall setvcpucontext setextvcpucontext
>   			getscheduler getvcpuinfo getvcpuextstate getaddrsize
>   			getaffinity setaffinity };
> -	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
>   	allow $1 $2:security check_context;
>   	allow $1 $2:shadow enable;
>   	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 564e187..45e282c 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
>                        uint32_t flags,
>                        uint32_t *pdomid);
>
> +#if defined(__arm__) || defined(__aarch64__)
> +typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> +
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config);
> +#endif
>
>   /* Functions to produce a dump of a given domain
>    *  xc_domain_dumpcore - produces a dump to a specified file
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index a9bcd4a..b071dea 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
>       return 0;
>   }
>
> +#if defined(__arm__) || defined(__aarch64__)
> +int xc_domain_configure(xc_interface *xch, uint32_t domid,
> +                        xc_domain_configuration_t *config)
> +{
> +    int rc;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> +    domctl.domain = (domid_t)domid;
> +    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
> +    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
> +
> +    rc = do_domctl(xch, &domctl);
> +    if ( !rc )
> +        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> +
> +    return rc;
> +}
> +#endif
> +
>   int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
>                            xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
>   {
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index a122e4a..448ac07 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -23,6 +23,18 @@
>   #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
>   #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
>
> +static const char *gicv_to_string(uint8_t gic_version)
> +{
> +    switch (gic_version) {
> +    case XEN_DOMCTL_CONFIG_GIC_V2:
> +        return "V2";
> +    case XEN_DOMCTL_CONFIG_GIC_V3:
> +        return "V3";
> +    default:
> +        return "unknown";
> +    }
> +}
> +
>   int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>                                 uint32_t domid)
>   {
> @@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
>       return 0;
>   }
>
> -static int make_intc_node(libxl__gc *gc, void *fdt,
> -                          uint64_t gicd_base, uint64_t gicd_size,
> -                          uint64_t gicc_base, uint64_t gicc_size)
> +static int make_gicv2_node(libxl__gc *gc, void *fdt,
> +                           uint64_t gicd_base, uint64_t gicd_size,
> +                           uint64_t gicc_base, uint64_t gicc_size)
>   {
>       int res;
>       const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> @@ -350,6 +362,56 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
>       return 0;
>   }
>
> +static int make_gicv3_node(libxl__gc *gc, void *fdt)
> +{
> +    int res;
> +    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
> +    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
> +    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
> +    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
> +    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> +
> +    res = fdt_begin_node(fdt, name);
> +    if (res) return res;
> +
> +    res = fdt_property_compat(gc, fdt, 1, "arm,gic-v3");
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#address-cells", 0);
> +    if (res) return res;
> +
> +    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "redistributor-stride",
> +                            GUEST_GICV3_RDIST_STRIDE);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "#redistributor-regions",
> +                            GUEST_GICV3_RDIST_REGIONS);
> +    if (res) return res;
> +
> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> +                            2,
> +                            gicd_base, gicd_size,
> +                            gicr0_base, gicr0_size);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
> +    if (res) return res;
> +
> +    res = fdt_end_node(fdt);
> +    if (res) return res;
> +
> +    return 0;
> +}
> +
>   static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
>   {
>       int res;
> @@ -456,6 +518,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>                                              libxl_domain_build_info *info,
>                                              struct xc_dom_image *dom)
>   {
> +    xc_domain_configuration_t config;
>       void *fdt = NULL;
>       int rc, res;
>       size_t fdt_size = 0;
> @@ -471,8 +534,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>       ainfo = get_arch_info(gc, dom);
>       if (ainfo == NULL) return ERROR_FAIL;
>
> +    LOG(DEBUG, "configure the domain");
> +    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> +    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> +        LOG(ERROR, "couldn't configure the domain");
> +        return ERROR_FAIL;
> +    }
> +
>       LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
>           vers->xen_version_major, vers->xen_version_minor);
> +    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
>
>   /*
>    * Call "call" handling FDR_ERR_*. Will either:
> @@ -520,9 +591,21 @@ next_resize:
>           FDT( make_psci_node(gc, fdt) );
>
>           FDT( make_memory_nodes(gc, fdt, dom) );
> -        FDT( make_intc_node(gc, fdt,
> -                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> -                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> +
> +        switch (config.gic_version) {
> +        case XEN_DOMCTL_CONFIG_GIC_V2:
> +            FDT( make_gicv2_node(gc, fdt,
> +                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> +                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> +            break;
> +        case XEN_DOMCTL_CONFIG_GIC_V3:
> +            FDT( make_gicv3_node(gc, fdt) );
> +            break;
> +        default:
> +            LOG(ERROR, "Unknown GIC version %d", config.gic_version);
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
>
>           FDT( make_timer_node(gc, fdt, ainfo) );
>           FDT( make_hypervisor_node(gc, fdt, vers) );
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 45974e7..d246e84 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -10,6 +10,8 @@
>   #include <xen/errno.h>
>   #include <xen/sched.h>
>   #include <xen/hypercall.h>
> +#include <asm/gic.h>
> +#include <xen/guest_access.h>
>   #include <public/domctl.h>
>
>   long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> @@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>
>           return p2m_cache_flush(d, s, e);
>       }
> +    case XEN_DOMCTL_arm_configure_domain:
> +    {
> +        uint8_t gic_version;
> +
> +        /*
> +         * Currently the vGIC is emulating the same version of the
> +         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> +         * is allowed. The DOMCTL will return the actual version of the
> +         * GIC.
> +         */
> +        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> +            return -EOPNOTSUPP;
> +
> +        switch ( gic_hw_version() )
> +        {
> +        case GIC_V3:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> +            break;
> +        case GIC_V2:
> +            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> +            break;
> +        default:
> +            BUG();
> +        }
> +
> +        domctl->u.configuredomain.gic_version = gic_version;
> +
> +        /* TODO: Make the copy generic for all ARCH domctl */
> +        if ( __copy_to_guest(u_domctl, domctl, 1) )
> +            return -EFAULT;
> +
> +        return 0;
> +    }
>
>       default:
>           return subarch_do_domctl(domctl, d, u_domctl);
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 91161a2..076aa62 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
>           d->arch.vgic.rdist_count = gicv3.rdist_count;
>       }
>       else
> -        d->arch.vgic.dbase = GUEST_GICD_BASE;
> +    {
> +        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
> +        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
> +
> +        /* XXX: Only one Re-distributor region mapped for the guest */
> +        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
> +
> +        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
> +        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
> +
> +        /* The first redistributor should contain enough space for all CPUs */
> +        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
> +        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
> +        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
> +    }
>
>       d->arch.vgic.nr_lines = 0;
>
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index eecc561..72d641f 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
>    */
>
>   /* Physical Address Space */
> +
> +/* vGIC mappings: Only one set of mapping is used by the guest.
> + * Therefore they can overlap.
> + */
> +
> +/* vGIC v2 mappings */
>   #define GUEST_GICD_BASE   0x03001000ULL
>   #define GUEST_GICD_SIZE   0x00001000ULL
>   #define GUEST_GICC_BASE   0x03002000ULL
>   #define GUEST_GICC_SIZE   0x00000100ULL
>
> +/* vGIC v3 mappings */
> +#define GUEST_GICV3_GICD_BASE      0x03001000ULL
> +#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
> +
> +#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
> +#define GUEST_GICV3_RDIST_REGIONS  1
> +
> +#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU7 */
> +#define GUEST_GICV3_GICR0_SIZE     0x00100000ULL
> +
>   /* 16MB == 4096 pages reserved for guest to use as a region to map its
>    * grant table in.
>    */
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 58b19e7..8da204e 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
>   typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
>
> +#if defined(__arm__) || defined(__aarch64__)
> +#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
> +#define XEN_DOMCTL_CONFIG_GIC_V2        1
> +#define XEN_DOMCTL_CONFIG_GIC_V3        2
> +/* XEN_DOMCTL_configure_domain */
> +struct xen_domctl_arm_configuredomain {
> +    /* IN/OUT parameters */
> +    uint8_t gic_version;
> +};
> +typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
> +#endif
> +
>   /* XEN_DOMCTL_getdomaininfo */
>   struct xen_domctl_getdomaininfo {
>       /* OUT variables. */
> @@ -1056,6 +1069,7 @@ struct xen_domctl {
>   #define XEN_DOMCTL_set_vcpu_msrs                 73
>   #define XEN_DOMCTL_setvnumainfo                  74
>   #define XEN_DOMCTL_psr_cmt_op                    75
> +#define XEN_DOMCTL_arm_configure_domain          76
>   #define XEN_DOMCTL_gdbsx_guestmemio            1000
>   #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>   #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -1064,6 +1078,9 @@ struct xen_domctl {
>       domid_t  domain;
>       union {
>           struct xen_domctl_createdomain      createdomain;
> +#if defined(__arm__) || defined(__aarch64__)
> +        struct xen_domctl_arm_configuredomain configuredomain;
> +#endif
>           struct xen_domctl_getdomaininfo     getdomaininfo;
>           struct xen_domctl_getmemlist        getmemlist;
>           struct xen_domctl_getpageframeinfo  getpageframeinfo;
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 6d0fe72..846cf88 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
>       case XEN_DOMCTL_psr_cmt_op:
>           return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
>
> +    case XEN_DOMCTL_configure_domain:
> +        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
> +
>       default:
>           printk("flask_domctl: Unknown op %d\n", cmd);
>           return -EPERM;
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index de0c707..bfe2fa5 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -216,6 +216,8 @@ class domain2
>       get_vnumainfo
>   # XEN_DOMCTL_psr_cmt_op
>       psr_cmt_op
> +# XEN_DOMCTL_configure_domain
> +    configure_domain
>   }
>
>   # Similar to class domain, but primarily contains domctls related to HVM domains
>

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:31:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmjd0-0004H7-AD; Fri, 07 Nov 2014 13:31:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xmjcz-0004Gy-5x
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 13:31:01 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	1C/BE-02559-499CC545; Fri, 07 Nov 2014 13:31:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415367059!12074780!1
X-Originating-IP: [81.169.146.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27075 invoked from network); 7 Nov 2014 13:30:59 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 13:30:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415367059; l=1956;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=QKZ2nyEWH037Xdl+G7FHTBkvKbM=;
	b=cHkjS9px2g4Fk99XkiG8ejw4yhWpA+aRZoE+vc5DiJXBDc4qS2pfCRGzRo5ediehfPO
	6f03oHdzFrgG3cHWpA3nUEhRPIOe4I6BsTivDy4AVzWm5T4H3hWh8d1+aXA2zdmBKTYz3
	pqWc4ZJFyYfkOtCGt4rQFy2jtdbuvoMOc6I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id z017e7qA7DUxWEu
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 7 Nov 2014 14:30:59 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 9C70350172; Fri,  7 Nov 2014 14:30:58 +0100 (CET)
Date: Fri, 7 Nov 2014 14:30:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141107133058.GA11146@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
	<CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
	<20141104104649.GA8479@aepfle.de>
	<CAFLBxZbm5sXPKM7312rjRojdhr9e8W5qGKuGjjH25_zoG1g+rg@mail.gmail.com>
	<1415099037.11486.25.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415099037.11486.25.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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

So how should we proceed here?!

Olaf

On Tue, Nov 04, Ian Campbell wrote:

> On Tue, 2014-11-04 at 11:00 +0000, George Dunlap wrote:
> > On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > > On Tue, Nov 04, George Dunlap wrote:
> > >
> > >> A number based on the time you happened to create the RPM, not based
> > >> on something intrinsic about the content of the RPM; that just seems
> > >> kind of hacky to me.  It happens to work well for your common
> > >> workflow, but you can certainly imagine other workflows or other
> > >> situations where you'd have to more manually override things anyway
> > >> (for instance, doing bisections, or comparing functionality in
> > >> different releases).  It seems like rather than having to remember
> > >> when you can skip the manual override bits, and when you can't, it
> > >> would be better to just use them all the time.
> > >
> > > George, the release number is and was never meant to describe the
> > > content of a package. It just means "its different". And it will even
> > > work for bisect because the package is always "newer", even if the
> > > content is different.
> > 
> > Not if you end up going to a previously built package for some reason.
> > 
> > I can see how this makes more sense if you do have an independent
> > package installed for every branch; but most people are not going to
> > do that.
> > 
> > Anyway, if I were a maintainer, I might decide to accept it, even
> > though I didn't like it, on the grounds that it doesn't do much harm
> > and somebody finds it useful.
> > 
> > Since I'm not a maintainer, I'm free to be opinionated. :-)
> 
> I don't think any of the formal maintainers of this code use RPM[0], and
> you are the original author of the tool... So I'm afraid I think you
> might have a more relevant opinion than you might like.
> 
> Ian.
> 
> [0] At least half happen to be Debian Maintainers...
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:31:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmjd0-0004H7-AD; Fri, 07 Nov 2014 13:31:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xmjcz-0004Gy-5x
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 13:31:01 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	1C/BE-02559-499CC545; Fri, 07 Nov 2014 13:31:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415367059!12074780!1
X-Originating-IP: [81.169.146.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27075 invoked from network); 7 Nov 2014 13:30:59 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 13:30:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415367059; l=1956;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=QKZ2nyEWH037Xdl+G7FHTBkvKbM=;
	b=cHkjS9px2g4Fk99XkiG8ejw4yhWpA+aRZoE+vc5DiJXBDc4qS2pfCRGzRo5ediehfPO
	6f03oHdzFrgG3cHWpA3nUEhRPIOe4I6BsTivDy4AVzWm5T4H3hWh8d1+aXA2zdmBKTYz3
	pqWc4ZJFyYfkOtCGt4rQFy2jtdbuvoMOc6I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.10 AUTH) with ESMTPSA id z017e7qA7DUxWEu
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 7 Nov 2014 14:30:59 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 9C70350172; Fri,  7 Nov 2014 14:30:58 +0100 (CET)
Date: Fri, 7 Nov 2014 14:30:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141107133058.GA11146@aepfle.de>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
	<CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
	<20141104104649.GA8479@aepfle.de>
	<CAFLBxZbm5sXPKM7312rjRojdhr9e8W5qGKuGjjH25_zoG1g+rg@mail.gmail.com>
	<1415099037.11486.25.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415099037.11486.25.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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

So how should we proceed here?!

Olaf

On Tue, Nov 04, Ian Campbell wrote:

> On Tue, 2014-11-04 at 11:00 +0000, George Dunlap wrote:
> > On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > > On Tue, Nov 04, George Dunlap wrote:
> > >
> > >> A number based on the time you happened to create the RPM, not based
> > >> on something intrinsic about the content of the RPM; that just seems
> > >> kind of hacky to me.  It happens to work well for your common
> > >> workflow, but you can certainly imagine other workflows or other
> > >> situations where you'd have to more manually override things anyway
> > >> (for instance, doing bisections, or comparing functionality in
> > >> different releases).  It seems like rather than having to remember
> > >> when you can skip the manual override bits, and when you can't, it
> > >> would be better to just use them all the time.
> > >
> > > George, the release number is and was never meant to describe the
> > > content of a package. It just means "its different". And it will even
> > > work for bisect because the package is always "newer", even if the
> > > content is different.
> > 
> > Not if you end up going to a previously built package for some reason.
> > 
> > I can see how this makes more sense if you do have an independent
> > package installed for every branch; but most people are not going to
> > do that.
> > 
> > Anyway, if I were a maintainer, I might decide to accept it, even
> > though I didn't like it, on the grounds that it doesn't do much harm
> > and somebody finds it useful.
> > 
> > Since I'm not a maintainer, I'm free to be opinionated. :-)
> 
> I don't think any of the formal maintainers of this code use RPM[0], and
> you are the original author of the tool... So I'm afraid I think you
> might have a more relevant opinion than you might like.
> 
> Ian.
> 
> [0] At least half happen to be Debian Maintainers...
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:36:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmji7-0004fC-Bc; Fri, 07 Nov 2014 13:36:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xmji6-0004f7-8a
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 13:36:18 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	54/F9-14214-1DACC545; Fri, 07 Nov 2014 13:36:17 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415367376!5712555!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8889 invoked from network); 7 Nov 2014 13:36:17 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:36:17 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so3742951wgg.33
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 05:36:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=0JzCAX2IRN7cPDqIfvu5O+CYdWaoAYtnOvPoH3Nxc74=;
	b=jUKxoJkP68GtiFzhpxICc8mFf6vsY4CKDn7B8AIA9mDuRZw0PL+RYm/0/XOSp69kbU
	Z2FzgH2XxFurD3lXeN7rfHi5nIhA30DSLIEtl4GTXs5YCZnak0ehJiyvmpeuVJ5NYXTc
	ycaELIGRaSU7166prifXYIv95BsOHxLHn0PI0YMT8wBsw+pcUiwlAbHg1ZQQlip6UyzL
	uZbdo1IIJ+1LcJcgLy8GGZDpgVlw4nsoCKhZe7TcuC+0ROil7Oq8QH/tJCmNAOtwTvR+
	HwHtFu6O74YBFhI4O069+cX1IFUZfKrZ3olTNlJJOp4EdyUqn6do2q1d0QhCoQuLuJRI
	xkvQ==
X-Gm-Message-State: ALoCoQlpTVptUOHy7HBS2e6jHy/za2GVpW6yi1JkdZg2iyuSD49U0WscRDEfitOpUebSgPXSLTSk
X-Received: by 10.194.184.75 with SMTP id es11mr16194603wjc.35.1415367376614; 
	Fri, 07 Nov 2014 05:36:16 -0800 (PST)
Received: from [192.168.42.189] (92.40.248.106.threembb.co.uk. [92.40.248.106])
	by mx.google.com with ESMTPSA id y5sm2086359wix.9.2014.11.07.05.36.14
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 05:36:15 -0800 (PST)
Message-ID: <545CCACA.7050406@linaro.org>
Date: Fri, 07 Nov 2014 13:36:10 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Zoltan Kiss <zoltan.kiss@linaro.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>	<545A2A96.8060105@linaro.org>
	<alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
	<545B4380.3050209@linaro.org>
In-Reply-To: <545B4380.3050209@linaro.org>
Cc: zoltan.kiss@huawei.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Zoltan,

On 06/11/2014 09:46, Zoltan Kiss wrote:
>
>
> On 05/11/14 14:52, Stefano Stabellini wrote:
>> On Wed, 5 Nov 2014, Julien Grall wrote:
>>> Hi Frediano,
>>>
>>> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
>>>> This name can appear in some Linux kernel repos. Not very fortunate,
>>>> but to avoid others spending an hour to spot that few characters
>>>> difference it worth to work around it.
>>>
>>> Linux upstream is using "hisilicon,hip04-intc" to detect the hisilicon
>>> interrupt controller. So it's not a workaround.
>>>
>>> Which kernel is using the "*,hip04-gic"?
>>
>> Good question, but what really matters is the string that u-boot (or any
>> other firmware/bootloader) is going to use, right? So, which one is it?
> We are using the DTB from the kernel source, even when loading a bare
> metal kernel. I've looked around, the *gic version seems to exist only
> in internal repos, as far as I can see. Including the one Frediano
> started to use for porting. Therefore, I don't insist to keep both, but
> as I mentioned in the commit message, it would still provide some
> benefit, and given that it's just a 3 line change which just extend a
> few listings, I think we should keep it.
> Of course with a different commit message, which clears that this is the
> official name of it.

If it's only used in your internal repo, we shouldn't support this 
compatible string in Xen.

Nothing prevent someone in the future to use this compatible for a 
completely different purpose (for instance a different GIC driver).

We aim to support only official bindings to avoid a such issue.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:36:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmji7-0004fC-Bc; Fri, 07 Nov 2014 13:36:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xmji6-0004f7-8a
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 13:36:18 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	54/F9-14214-1DACC545; Fri, 07 Nov 2014 13:36:17 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415367376!5712555!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8889 invoked from network); 7 Nov 2014 13:36:17 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:36:17 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so3742951wgg.33
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 05:36:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=0JzCAX2IRN7cPDqIfvu5O+CYdWaoAYtnOvPoH3Nxc74=;
	b=jUKxoJkP68GtiFzhpxICc8mFf6vsY4CKDn7B8AIA9mDuRZw0PL+RYm/0/XOSp69kbU
	Z2FzgH2XxFurD3lXeN7rfHi5nIhA30DSLIEtl4GTXs5YCZnak0ehJiyvmpeuVJ5NYXTc
	ycaELIGRaSU7166prifXYIv95BsOHxLHn0PI0YMT8wBsw+pcUiwlAbHg1ZQQlip6UyzL
	uZbdo1IIJ+1LcJcgLy8GGZDpgVlw4nsoCKhZe7TcuC+0ROil7Oq8QH/tJCmNAOtwTvR+
	HwHtFu6O74YBFhI4O069+cX1IFUZfKrZ3olTNlJJOp4EdyUqn6do2q1d0QhCoQuLuJRI
	xkvQ==
X-Gm-Message-State: ALoCoQlpTVptUOHy7HBS2e6jHy/za2GVpW6yi1JkdZg2iyuSD49U0WscRDEfitOpUebSgPXSLTSk
X-Received: by 10.194.184.75 with SMTP id es11mr16194603wjc.35.1415367376614; 
	Fri, 07 Nov 2014 05:36:16 -0800 (PST)
Received: from [192.168.42.189] (92.40.248.106.threembb.co.uk. [92.40.248.106])
	by mx.google.com with ESMTPSA id y5sm2086359wix.9.2014.11.07.05.36.14
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 05:36:15 -0800 (PST)
Message-ID: <545CCACA.7050406@linaro.org>
Date: Fri, 07 Nov 2014 13:36:10 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Zoltan Kiss <zoltan.kiss@linaro.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>	<545A2A96.8060105@linaro.org>
	<alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
	<545B4380.3050209@linaro.org>
In-Reply-To: <545B4380.3050209@linaro.org>
Cc: zoltan.kiss@huawei.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Frediano Ziglio <frediano.ziglio@huawei.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Zoltan,

On 06/11/2014 09:46, Zoltan Kiss wrote:
>
>
> On 05/11/14 14:52, Stefano Stabellini wrote:
>> On Wed, 5 Nov 2014, Julien Grall wrote:
>>> Hi Frediano,
>>>
>>> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
>>>> This name can appear in some Linux kernel repos. Not very fortunate,
>>>> but to avoid others spending an hour to spot that few characters
>>>> difference it worth to work around it.
>>>
>>> Linux upstream is using "hisilicon,hip04-intc" to detect the hisilicon
>>> interrupt controller. So it's not a workaround.
>>>
>>> Which kernel is using the "*,hip04-gic"?
>>
>> Good question, but what really matters is the string that u-boot (or any
>> other firmware/bootloader) is going to use, right? So, which one is it?
> We are using the DTB from the kernel source, even when loading a bare
> metal kernel. I've looked around, the *gic version seems to exist only
> in internal repos, as far as I can see. Including the one Frediano
> started to use for porting. Therefore, I don't insist to keep both, but
> as I mentioned in the commit message, it would still provide some
> benefit, and given that it's just a 3 line change which just extend a
> few listings, I think we should keep it.
> Of course with a different commit message, which clears that this is the
> official name of it.

If it's only used in your internal repo, we shouldn't support this 
compatible string in Xen.

Nothing prevent someone in the future to use this compatible for a 
completely different purpose (for instance a different GIC driver).

We aim to support only official bindings to avoid a such issue.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:44:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:44:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmjpr-0004qa-Ac; Fri, 07 Nov 2014 13:44:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xmjpq-0004qV-2V
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 13:44:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	40/E9-09842-1BCCC545; Fri, 07 Nov 2014 13:44:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415367855!4197825!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32692 invoked from network); 7 Nov 2014 13:44:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:44:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="190555434"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 08:44:13 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xmjpl-0001yz-Hz;
	Fri, 07 Nov 2014 13:44:13 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xmjpl-0004QY-6w;
	Fri, 07 Nov 2014 13:44:13 +0000
Date: Fri, 7 Nov 2014 13:44:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31426-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31426: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31426 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31426/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install      fail pass in 31406
 test-i386-i386-pair           7 xen-boot/src_host           fail pass in 31406
 test-amd64-i386-xl            5 xen-boot           fail in 31406 pass in 31426
 test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail in 31406 pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31426
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31426
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31426

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 31406 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:44:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13:44:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmjpr-0004qa-Ac; Fri, 07 Nov 2014 13:44:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xmjpq-0004qV-2V
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 13:44:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	40/E9-09842-1BCCC545; Fri, 07 Nov 2014 13:44:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415367855!4197825!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32692 invoked from network); 7 Nov 2014 13:44:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:44:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="190555434"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 08:44:13 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xmjpl-0001yz-Hz;
	Fri, 07 Nov 2014 13:44:13 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xmjpl-0004QY-6w;
	Fri, 07 Nov 2014 13:44:13 +0000
Date: Fri, 7 Nov 2014 13:44:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31426-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31426: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31426 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31426/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install      fail pass in 31406
 test-i386-i386-pair           7 xen-boot/src_host           fail pass in 31406
 test-amd64-i386-xl            5 xen-boot           fail in 31406 pass in 31426
 test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail in 31406 pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31426
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31426
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31426

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 31406 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:54:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13: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 1Xmjzq-00050r-Cb; Fri, 07 Nov 2014 13:54:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xmjzo-00050m-Kd
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 13:54:36 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	77/C0-19763-B1FCC545; Fri, 07 Nov 2014 13:54:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415368473!11114147!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12319 invoked from network); 7 Nov 2014 13:54:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:54:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189129741"
Message-ID: <545CCF15.4070402@citrix.com>
Date: Fri, 7 Nov 2014 13:54:29 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-6-git-send-email-jgross@suse.com>
In-Reply-To: <1415252853-7106-6-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 05:47, Juergen Gross wrote:
> At start of the day the Xen hypervisor presents a contiguous mfn list
> to a pv-domain. In order to support sparse memory this mfn list is
> accessed via a three level p2m tree built early in the boot process.
> Whenever the system needs the mfn associated with a pfn this tree is
> used to find the mfn.
> 
> Instead of using a software walked tree for accessing a specific mfn
> list entry this patch is creating a virtual address area for the
> entire possible mfn list including memory holes. The holes are
> covered by mapping a pre-defined  page consisting only of "invalid
> mfn" entries. Access to a mfn entry is possible by just using the
> virtual base address of the mfn list and the pfn as index into that
> list. This speeds up the (hot) path of determining the mfn of a
> pfn.
> 
> Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
> showed following improvements:
> 
> Elapsed time: 32:50 ->  32:35
> System:       18:07 ->  17:47
> User:        104:00 -> 103:30

After implementing my suggestions below, please provided updated figure.
 They should be better.

> Tested on 64 bit dom0 and 32 bit domU.
[...]
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -59,6 +59,23 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
>  				     struct page **pages, unsigned int count);
>  extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
>  
> +static inline unsigned long __pfn_to_mfn(unsigned long pfn)

These variations of pfn_to_mfn() (__pfn_to_mfn() and
get_phys_to_machine() and any others), need comments explaining their
differences.

Can you add __pfn_to_mfn() and the docs in a separate patch?

> +	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);

pr_info().

> @@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long pfn)
>  		return IDENTITY_FRAME(pfn);
>  	}
>  
> -	topidx = p2m_top_index(pfn);
> -	mididx = p2m_mid_index(pfn);
> -	idx = p2m_index(pfn);
> +	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
> +	BUG_ON(!ptep || level != PG_LEVEL_4K);
>  
>  	/*
>  	 * The INVALID_P2M_ENTRY is filled in both p2m_*identity
>  	 * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
>  	 * would be wrong.
>  	 */
> -	if (p2m_top[topidx][mididx] == p2m_identity)
> +	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
>  		return IDENTITY_FRAME(pfn);
>  
> -	return p2m_top[topidx][mididx][idx];
> +	return xen_p2m_addr[pfn];

You should test xen_p2m_addr[pfn] == INVALID_P2M_ENTRY before checking
if it's an identity entry.  This should skip the more expensive
lookup_address() in the common case.

>  bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)

I think you should map p2m_missing and p2m_identity as read-only and do
the new page allocation on a write fault.

set_phys_to_machine() is used every grant map and unmap and in the
common case (already allocated array page) it must be a fast and simple:

    xen_p2m_addr[pfn] = mfn;

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:54:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 13: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 1Xmjzq-00050r-Cb; Fri, 07 Nov 2014 13:54:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xmjzo-00050m-Kd
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 13:54:36 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	77/C0-19763-B1FCC545; Fri, 07 Nov 2014 13:54:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415368473!11114147!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12319 invoked from network); 7 Nov 2014 13:54:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:54:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189129741"
Message-ID: <545CCF15.4070402@citrix.com>
Date: Fri, 7 Nov 2014 13:54:29 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-6-git-send-email-jgross@suse.com>
In-Reply-To: <1415252853-7106-6-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/11/14 05:47, Juergen Gross wrote:
> At start of the day the Xen hypervisor presents a contiguous mfn list
> to a pv-domain. In order to support sparse memory this mfn list is
> accessed via a three level p2m tree built early in the boot process.
> Whenever the system needs the mfn associated with a pfn this tree is
> used to find the mfn.
> 
> Instead of using a software walked tree for accessing a specific mfn
> list entry this patch is creating a virtual address area for the
> entire possible mfn list including memory holes. The holes are
> covered by mapping a pre-defined  page consisting only of "invalid
> mfn" entries. Access to a mfn entry is possible by just using the
> virtual base address of the mfn list and the pfn as index into that
> list. This speeds up the (hot) path of determining the mfn of a
> pfn.
> 
> Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
> showed following improvements:
> 
> Elapsed time: 32:50 ->  32:35
> System:       18:07 ->  17:47
> User:        104:00 -> 103:30

After implementing my suggestions below, please provided updated figure.
 They should be better.

> Tested on 64 bit dom0 and 32 bit domU.
[...]
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -59,6 +59,23 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
>  				     struct page **pages, unsigned int count);
>  extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
>  
> +static inline unsigned long __pfn_to_mfn(unsigned long pfn)

These variations of pfn_to_mfn() (__pfn_to_mfn() and
get_phys_to_machine() and any others), need comments explaining their
differences.

Can you add __pfn_to_mfn() and the docs in a separate patch?

> +	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);

pr_info().

> @@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long pfn)
>  		return IDENTITY_FRAME(pfn);
>  	}
>  
> -	topidx = p2m_top_index(pfn);
> -	mididx = p2m_mid_index(pfn);
> -	idx = p2m_index(pfn);
> +	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
> +	BUG_ON(!ptep || level != PG_LEVEL_4K);
>  
>  	/*
>  	 * The INVALID_P2M_ENTRY is filled in both p2m_*identity
>  	 * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
>  	 * would be wrong.
>  	 */
> -	if (p2m_top[topidx][mididx] == p2m_identity)
> +	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
>  		return IDENTITY_FRAME(pfn);
>  
> -	return p2m_top[topidx][mididx][idx];
> +	return xen_p2m_addr[pfn];

You should test xen_p2m_addr[pfn] == INVALID_P2M_ENTRY before checking
if it's an identity entry.  This should skip the more expensive
lookup_address() in the common case.

>  bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)

I think you should map p2m_missing and p2m_identity as read-only and do
the new page allocation on a write fault.

set_phys_to_machine() is used every grant map and unmap and in the
common case (already allocated array page) it must be a fast and simple:

    xen_p2m_addr[pfn] = mfn;

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:58:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 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.xen.org>)
	id 1Xmk34-000588-Vn; Fri, 07 Nov 2014 13:57:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xmk32-000582-Vk
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 13:57:57 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	DC/29-26652-4EFCC545; Fri, 07 Nov 2014 13:57:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415368674!11110480!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2037 invoked from network); 7 Nov 2014 13:57:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189130667"
Message-ID: <545CCFDC.9020603@citrix.com>
Date: Fri, 7 Nov 2014 13:57:48 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<boris.ostrovsky@oracle.com>, <x86@kernel.org>, <tglx@linutronix.de>,
	<mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-4-git-send-email-jgross@suse.com>
In-Reply-To: <1415252853-7106-4-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V2 3/5] xen: Delay invalidating extra 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 06/11/14 05:47, Juergen Gross wrote:
> When the physical memory configuration is initialized the p2m entries
> for not pouplated memory pages are set to "invalid". As those pages
> are beyond the hypervisor built p2m list the p2m tree has to be
> extended.
> 
> This patch delays processing the extra memory related p2m entries
> during the boot process until some more basic memory management
> functions are callable. This removes the need to create new p2m
> entries until virtual memory management is available.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

But I would like a second reviewed by for all the patches in this series
since it's such a complex area.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 13:58:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 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.xen.org>)
	id 1Xmk34-000588-Vn; Fri, 07 Nov 2014 13:57:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xmk32-000582-Vk
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 13:57:57 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	DC/29-26652-4EFCC545; Fri, 07 Nov 2014 13:57:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415368674!11110480!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2037 invoked from network); 7 Nov 2014 13:57:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 13:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189130667"
Message-ID: <545CCFDC.9020603@citrix.com>
Date: Fri, 7 Nov 2014 13:57:48 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<boris.ostrovsky@oracle.com>, <x86@kernel.org>, <tglx@linutronix.de>,
	<mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-4-git-send-email-jgross@suse.com>
In-Reply-To: <1415252853-7106-4-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V2 3/5] xen: Delay invalidating extra 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 06/11/14 05:47, Juergen Gross wrote:
> When the physical memory configuration is initialized the p2m entries
> for not pouplated memory pages are set to "invalid". As those pages
> are beyond the hypervisor built p2m list the p2m tree has to be
> extended.
> 
> This patch delays processing the extra memory related p2m entries
> during the boot process until some more basic memory management
> functions are callable. This removes the need to create new p2m
> entries until virtual memory management is available.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

But I would like a second reviewed by for all the patches in this series
since it's such a complex area.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:10:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:10:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkEe-0005RV-Fx; Fri, 07 Nov 2014 14:09:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XmkEc-0005RQ-Ud
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:09:55 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	B9/5D-27623-2B2DC545; Fri, 07 Nov 2014 14:09:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415369392!11122526!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11689 invoked from network); 7 Nov 2014 14:09:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:09:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189135000"
Message-ID: <545CD26E.8040404@citrix.com>
Date: Fri, 7 Nov 2014 14:08:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, David Vrabel <david.vrabel@citrix.com>,
	<linux-kernel@vger.kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>	<1415252853-7106-3-git-send-email-jgross@suse.com>	<545CC349.8020006@citrix.com>
	<545CC6D8.80100@suse.com>
In-Reply-To: <545CC6D8.80100@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V2 2/5] xen: Delay m2p_override
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/11/14 13:19, Juergen Gross wrote:
> On 11/07/2014 02:04 PM, David Vrabel wrote:
>>
>> I suppose this is the "make some functions static" but it's an
>> unreviewable mess.  If you can't do this with some one line changes
>> adding "static" and perhaps some forward declarations then please drop
>> this bit.
> 
> Do you really prefer forward declarations instead of pure code movement?
> I can do as you request, but just want to make sure.

Normally I prefer not having forward declarations...  How about a patch
that does this and then a 2nd patch that does the pure code motion.
Maybe that will produce a better diff?

You can also try the --patience option for git diff (etc.).  This may
produce more readable diffs.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:10:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:10:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkEe-0005RV-Fx; Fri, 07 Nov 2014 14:09:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XmkEc-0005RQ-Ud
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:09:55 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	B9/5D-27623-2B2DC545; Fri, 07 Nov 2014 14:09:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415369392!11122526!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11689 invoked from network); 7 Nov 2014 14:09:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:09:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189135000"
Message-ID: <545CD26E.8040404@citrix.com>
Date: Fri, 7 Nov 2014 14:08:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, David Vrabel <david.vrabel@citrix.com>,
	<linux-kernel@vger.kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>	<1415252853-7106-3-git-send-email-jgross@suse.com>	<545CC349.8020006@citrix.com>
	<545CC6D8.80100@suse.com>
In-Reply-To: <545CC6D8.80100@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V2 2/5] xen: Delay m2p_override
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/11/14 13:19, Juergen Gross wrote:
> On 11/07/2014 02:04 PM, David Vrabel wrote:
>>
>> I suppose this is the "make some functions static" but it's an
>> unreviewable mess.  If you can't do this with some one line changes
>> adding "static" and perhaps some forward declarations then please drop
>> this bit.
> 
> Do you really prefer forward declarations instead of pure code movement?
> I can do as you request, but just want to make sure.

Normally I prefer not having forward declarations...  How about a patch
that does this and then a 2nd patch that does the pure code motion.
Maybe that will produce a better diff?

You can also try the --patience option for git diff (etc.).  This may
produce more readable diffs.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:11:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:11:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkG1-0005Vv-Uq; Fri, 07 Nov 2014 14:11:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmkG0-0005Vm-Jg
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:11:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6F/B9-24532-703DC545; Fri, 07 Nov 2014 14:11:19 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415369479!12173743!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22019 invoked from network); 7 Nov 2014 14:11:19 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 14:11:19 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id D6667AC38;
	Fri,  7 Nov 2014 14:11:18 +0000 (UTC)
Message-ID: <545CD306.90001@suse.com>
Date: Fri, 07 Nov 2014 15:11:18 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-6-git-send-email-jgross@suse.com>
	<545CCF15.4070402@citrix.com>
In-Reply-To: <545CCF15.4070402@citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped
 sparse p2m 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

On 11/07/2014 02:54 PM, David Vrabel wrote:
> On 06/11/14 05:47, Juergen Gross wrote:
>> At start of the day the Xen hypervisor presents a contiguous mfn list
>> to a pv-domain. In order to support sparse memory this mfn list is
>> accessed via a three level p2m tree built early in the boot process.
>> Whenever the system needs the mfn associated with a pfn this tree is
>> used to find the mfn.
>>
>> Instead of using a software walked tree for accessing a specific mfn
>> list entry this patch is creating a virtual address area for the
>> entire possible mfn list including memory holes. The holes are
>> covered by mapping a pre-defined  page consisting only of "invalid
>> mfn" entries. Access to a mfn entry is possible by just using the
>> virtual base address of the mfn list and the pfn as index into that
>> list. This speeds up the (hot) path of determining the mfn of a
>> pfn.
>>
>> Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
>> showed following improvements:
>>
>> Elapsed time: 32:50 ->  32:35
>> System:       18:07 ->  17:47
>> User:        104:00 -> 103:30
>
> After implementing my suggestions below, please provided updated figure.
>   They should be better.

In dom0? I don't think so.

>
>> Tested on 64 bit dom0 and 32 bit domU.
> [...]
>> --- a/arch/x86/include/asm/xen/page.h
>> +++ b/arch/x86/include/asm/xen/page.h
>> @@ -59,6 +59,23 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
>>   				     struct page **pages, unsigned int count);
>>   extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
>>
>> +static inline unsigned long __pfn_to_mfn(unsigned long pfn)
>
> These variations of pfn_to_mfn() (__pfn_to_mfn() and
> get_phys_to_machine() and any others), need comments explaining their
> differences.
>
> Can you add __pfn_to_mfn() and the docs in a separate patch?

Okay.

>
>> +	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);
>
> pr_info().
>
>> @@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long pfn)
>>   		return IDENTITY_FRAME(pfn);
>>   	}
>>
>> -	topidx = p2m_top_index(pfn);
>> -	mididx = p2m_mid_index(pfn);
>> -	idx = p2m_index(pfn);
>> +	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
>> +	BUG_ON(!ptep || level != PG_LEVEL_4K);
>>
>>   	/*
>>   	 * The INVALID_P2M_ENTRY is filled in both p2m_*identity
>>   	 * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
>>   	 * would be wrong.
>>   	 */
>> -	if (p2m_top[topidx][mididx] == p2m_identity)
>> +	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
>>   		return IDENTITY_FRAME(pfn);
>>
>> -	return p2m_top[topidx][mididx][idx];
>> +	return xen_p2m_addr[pfn];
>
> You should test xen_p2m_addr[pfn] == INVALID_P2M_ENTRY before checking
> if it's an identity entry.  This should skip the more expensive
> lookup_address() in the common case.

I do. The check is in __pfn_to_mfn(). get_phys_to_machine() is called in
this case only.

>
>>   bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>
> I think you should map p2m_missing and p2m_identity as read-only and do
> the new page allocation on a write fault.
>
> set_phys_to_machine() is used every grant map and unmap and in the
> common case (already allocated array page) it must be a fast and simple:
>
>      xen_p2m_addr[pfn] = mfn;

Nice idea. I'll try it.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:11:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:11:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkG1-0005Vv-Uq; Fri, 07 Nov 2014 14:11:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmkG0-0005Vm-Jg
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:11:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6F/B9-24532-703DC545; Fri, 07 Nov 2014 14:11:19 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415369479!12173743!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22019 invoked from network); 7 Nov 2014 14:11:19 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 14:11:19 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id D6667AC38;
	Fri,  7 Nov 2014 14:11:18 +0000 (UTC)
Message-ID: <545CD306.90001@suse.com>
Date: Fri, 07 Nov 2014 15:11:18 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-6-git-send-email-jgross@suse.com>
	<545CCF15.4070402@citrix.com>
In-Reply-To: <545CCF15.4070402@citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped
 sparse p2m 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

On 11/07/2014 02:54 PM, David Vrabel wrote:
> On 06/11/14 05:47, Juergen Gross wrote:
>> At start of the day the Xen hypervisor presents a contiguous mfn list
>> to a pv-domain. In order to support sparse memory this mfn list is
>> accessed via a three level p2m tree built early in the boot process.
>> Whenever the system needs the mfn associated with a pfn this tree is
>> used to find the mfn.
>>
>> Instead of using a software walked tree for accessing a specific mfn
>> list entry this patch is creating a virtual address area for the
>> entire possible mfn list including memory holes. The holes are
>> covered by mapping a pre-defined  page consisting only of "invalid
>> mfn" entries. Access to a mfn entry is possible by just using the
>> virtual base address of the mfn list and the pfn as index into that
>> list. This speeds up the (hot) path of determining the mfn of a
>> pfn.
>>
>> Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
>> showed following improvements:
>>
>> Elapsed time: 32:50 ->  32:35
>> System:       18:07 ->  17:47
>> User:        104:00 -> 103:30
>
> After implementing my suggestions below, please provided updated figure.
>   They should be better.

In dom0? I don't think so.

>
>> Tested on 64 bit dom0 and 32 bit domU.
> [...]
>> --- a/arch/x86/include/asm/xen/page.h
>> +++ b/arch/x86/include/asm/xen/page.h
>> @@ -59,6 +59,23 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
>>   				     struct page **pages, unsigned int count);
>>   extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
>>
>> +static inline unsigned long __pfn_to_mfn(unsigned long pfn)
>
> These variations of pfn_to_mfn() (__pfn_to_mfn() and
> get_phys_to_machine() and any others), need comments explaining their
> differences.
>
> Can you add __pfn_to_mfn() and the docs in a separate patch?

Okay.

>
>> +	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);
>
> pr_info().
>
>> @@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long pfn)
>>   		return IDENTITY_FRAME(pfn);
>>   	}
>>
>> -	topidx = p2m_top_index(pfn);
>> -	mididx = p2m_mid_index(pfn);
>> -	idx = p2m_index(pfn);
>> +	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
>> +	BUG_ON(!ptep || level != PG_LEVEL_4K);
>>
>>   	/*
>>   	 * The INVALID_P2M_ENTRY is filled in both p2m_*identity
>>   	 * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
>>   	 * would be wrong.
>>   	 */
>> -	if (p2m_top[topidx][mididx] == p2m_identity)
>> +	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
>>   		return IDENTITY_FRAME(pfn);
>>
>> -	return p2m_top[topidx][mididx][idx];
>> +	return xen_p2m_addr[pfn];
>
> You should test xen_p2m_addr[pfn] == INVALID_P2M_ENTRY before checking
> if it's an identity entry.  This should skip the more expensive
> lookup_address() in the common case.

I do. The check is in __pfn_to_mfn(). get_phys_to_machine() is called in
this case only.

>
>>   bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>
> I think you should map p2m_missing and p2m_identity as read-only and do
> the new page allocation on a write fault.
>
> set_phys_to_machine() is used every grant map and unmap and in the
> common case (already allocated array page) it must be a fast and simple:
>
>      xen_p2m_addr[pfn] = mfn;

Nice idea. I'll try it.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:12:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:12:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkGr-0005bz-DU; Fri, 07 Nov 2014 14:12:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmkGp-0005bh-HD
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:12:11 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	8A/2C-26858-A33DC545; Fri, 07 Nov 2014 14:12:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415369528!11070426!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25992 invoked from network); 7 Nov 2014 14:12:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:12:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="190564540"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 09:10:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmkFG-0004nD-4F;
	Fri, 07 Nov 2014 14:10:34 +0000
Date: Fri, 7 Nov 2014 14:10:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107110524.GA21875@localhost>
Message-ID: <alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> On Thu, Nov 06, 2014 at 12:22:13PM +0000, Stefano Stabellini wrote:
> > On Thu, 6 Nov 2014, Catalin Marinas wrote:
> > > On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> > > > On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > > > > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > > > > standard cache maintenance would be enough (but that's a Xen problem,
> > > > > not sure how to solve).
> > > > 
> > > > It is a thorny issue indeed.
> > > > Xen would need to know how to do non-standard cache maintenance
> > > > operations.
> > > 
> > > Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
> > > just use the currently registered dma ops.
> > 
> > It is Xen, so El2 hypervisor.
> 
> So what is arch/arm/xen/mm32.c cache maintenance for? Doesn't it run in
> dom0?

This patch series changes that code path specifically. As a matter of
fact it removes mm32.c.
Before this patch series, cache maintenance in dom0 was being done with
XENFEAT_grant_map_identity (see explanation in previous email).
After this patch series, an hypercall is made when foreign pages are
involved, see patch 8/8, the if(!pfn_valid(pfn)) code path. Local pages
are still flushed in dom0.


> > > > Otherwise we would need to resurrect XENFEAT_grant_map_identity (that I
> > > > am reverting in this series) and be content with having CONFIG_XEN_DOM0
> > > > depend on CONFIG_ARM_LPAE.
> > > 
> > > So what does buy you? Is it just the hope that with LPAE you won't have
> > > weird system caches?
> > 
> > Let me explain a bit more and let's assume there is no SMMU.
> > 
> > The problem is not normal dma originating in dom0, currently mapped 1:1
> > (pseudo-physical == physical). The problem are dma operations that
> > involve foreign pages (pages belonging to other virtual machines)
> > currently mapped also in dom0 to do IO. It is common for the Xen PV
> > network and block frontends to grant access to one or more pages to the
> > network and block backends for IO. The backends, usually in dom0, map
> > the pages and perform the actual IO. Sometimes the IO is a dma operation
> > that involves one of the granted pages directly.
> > 
> > For these pages, the pseudo-physical address in dom0 is different from
> > the physical address. Dom0 keeps track of the pseudo-physical to
> > physical relationship (pfn_to_mfn in Xen terminology). The swiotlb-xen
> > driver makes sure to return the right mfn from map_page and map_sg.
> 
> For my understanding, xen_dma_map_page() is called from dom0 and it
> simply calls the __generic_dma_ops()->map_page(). The "page" argument
> here is the dom0 page and it gets translated to dom0 phys and then to a
> bus address via xen_phys_to_bus().
> 
> On arm64, __swiotlb_map_page() uses the page structure to get some
> pseudo device address which gets converted back to a dom0 virtual
> address. The latter is used for cache maintenance by VA in dom0. With
> PIPT-like caches, that's fine, you don't need the actual machine PA
> unless you have caches like PL310 (which are not compatible with
> virtualisation anyway and the latest ARMv8 ARM even makes a clear
> statement here).
> 
> (one potential problem here is the dma_capable() check in
> swiotlb_map_page() (non-xen) which uses the pseudo device address)
> 
> The interesting part is that xen_swiotlb_map_page() returns the real
> machine device address to dom0, which is different from what dom0 thinks
> of a device address (phys_to_dma(phys_to_page(page))). Does dom0 use
> such real/machine device address to program the device directly or there
> is another layer where you could do the translation?

No other layer. Dom0 uses the real/machine device address returned by
xen_phys_to_bus to program the device directly.


> > However some of the dma_ops give you only a dma_addr_t handle
> > (unmap_page and unmap_sg), that is the physical address of the page.
> 
> OK, I started to get it now, the __swiotlb_unmap_page() on arm64, if
> called from dom0, would get the machine device address and dma_to_phys()
> does not work.

Right!


> > Dom0 doesn't know how to find the pseudo-physical address corresponding
> > to it. Therefore it also doesn't know how to find the struct page for
> > it. This is not a trivial problem to solve as the same page can be
> > granted multiple times, therefore could have multiple pseudo-physical
> > addresses and multiple struct pages corresponding to one physical
> > address in dom0.
> 
> So what is mfn_to_pfn() and xen_bus_to_phys() used for?

They are not used on ARM. But swiotlb-xen is not ARM specific and
xen_bus_to_phys is still important on x86. It works differently there.


> Isn't mfn_to_pfn(pfn_to_mfn(x)) an identity function?

Yes, it should be and it is for local pages.
However it is not an identity function for foreign pages, because
mfn_to_pfn is broken and just returns pfn on ARM, while pfn_to_mfn works
correctly.


> > Fortunately these dma_ops don't actually need to do much. In fact they
> > only need to flush caches if the device is not dma-coherent. So the
> > current proposed solution is to issue an hypercall to ask Xen to do the
> > flushing, passing the physical address dom0 knows.
> 
> I really don't like the dma_cache_maint() duplication you added in
> arch/arm/xen/mm32.c just because you cannot call the host dma_ops when
> the page is not available.

I agree is bad, but this patch series is a big step forward removing the
duplication. In fact now that I think about it, when a page is local (not a
foreign page) I could just call the host dma_ops. mm.c:dma_cache_maint
would only be used for foreign pages (pages for which !pfn_valid(pfn)).


> You basically only need a VA that was mapped in dom0 when map_page() was
> called and is still mapped when page_unmap() is called. You can free the
> actual mapping after calling __generic_dma_ops()->unmap_page() in
> xen_dma_unmap_page() (in xen_unmap_single()).

That is true, but where would I store the mapping?

I don't want to introduce another data structure to keep physical to va
or physical to struct page mappings that I need to modify at every
map_page and unmap_page. It wouldn't even be a trivial data structure as
multiple dma operations involving the same mfn but different struct page
can happen simultaneously.

The performance hit of maintaining such a data structure would be
significant.

It would negatively impact any dma operations involving any devices,
including dma coherent ones. While this series only requires special
handling of dma operations involving non-coherent devices (resulting in
an hypercall being made).

In a way this series rewards hardware that makes life easier to software
developers :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:12:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:12:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkGs-0005cQ-QW; Fri, 07 Nov 2014 14:12:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmkGr-0005bw-GL
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:12:13 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	84/4D-05632-C33DC545; Fri, 07 Nov 2014 14:12:12 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415369528!11070426!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26155 invoked from network); 7 Nov 2014 14:12:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:12:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="190564560"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 09:10:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmkFP-0004nQ-LW;
	Fri, 07 Nov 2014 14:10:43 +0000
Date: Fri, 7 Nov 2014 14:10:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107111126.GB21875@localhost>
Message-ID: <alpine.DEB.2.02.1411071239110.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<20141107111126.GB21875@localhost>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> On Fri, Nov 07, 2014 at 11:05:25AM +0000, Catalin Marinas wrote:
> > BTW, drivers/xen/swiotlb-xen.c needs something like:
> > 
> >         dma_addr_t dev_addr = xen_phys_to_bus(phys_to_dma(phys));
> > 
> > phys != bus address.
> 
> Wrong place, what I meant is when calling:
> 
>         xen_dma_unmap_page(hwdev, phys_to_dma(paddr), size, dir, attrs);

Well spotted! This is an actual mistake in the current code, independent
from the problem described before. Julien reported it a couple of days
ago and I have already queued a patch to fix it at the end of the
series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:12:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:12:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkGr-0005bz-DU; Fri, 07 Nov 2014 14:12:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmkGp-0005bh-HD
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:12:11 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	8A/2C-26858-A33DC545; Fri, 07 Nov 2014 14:12:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415369528!11070426!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25992 invoked from network); 7 Nov 2014 14:12:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:12:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="190564540"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 09:10:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmkFG-0004nD-4F;
	Fri, 07 Nov 2014 14:10:34 +0000
Date: Fri, 7 Nov 2014 14:10:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107110524.GA21875@localhost>
Message-ID: <alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> On Thu, Nov 06, 2014 at 12:22:13PM +0000, Stefano Stabellini wrote:
> > On Thu, 6 Nov 2014, Catalin Marinas wrote:
> > > On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> > > > On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > > > > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > > > > standard cache maintenance would be enough (but that's a Xen problem,
> > > > > not sure how to solve).
> > > > 
> > > > It is a thorny issue indeed.
> > > > Xen would need to know how to do non-standard cache maintenance
> > > > operations.
> > > 
> > > Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
> > > just use the currently registered dma ops.
> > 
> > It is Xen, so El2 hypervisor.
> 
> So what is arch/arm/xen/mm32.c cache maintenance for? Doesn't it run in
> dom0?

This patch series changes that code path specifically. As a matter of
fact it removes mm32.c.
Before this patch series, cache maintenance in dom0 was being done with
XENFEAT_grant_map_identity (see explanation in previous email).
After this patch series, an hypercall is made when foreign pages are
involved, see patch 8/8, the if(!pfn_valid(pfn)) code path. Local pages
are still flushed in dom0.


> > > > Otherwise we would need to resurrect XENFEAT_grant_map_identity (that I
> > > > am reverting in this series) and be content with having CONFIG_XEN_DOM0
> > > > depend on CONFIG_ARM_LPAE.
> > > 
> > > So what does buy you? Is it just the hope that with LPAE you won't have
> > > weird system caches?
> > 
> > Let me explain a bit more and let's assume there is no SMMU.
> > 
> > The problem is not normal dma originating in dom0, currently mapped 1:1
> > (pseudo-physical == physical). The problem are dma operations that
> > involve foreign pages (pages belonging to other virtual machines)
> > currently mapped also in dom0 to do IO. It is common for the Xen PV
> > network and block frontends to grant access to one or more pages to the
> > network and block backends for IO. The backends, usually in dom0, map
> > the pages and perform the actual IO. Sometimes the IO is a dma operation
> > that involves one of the granted pages directly.
> > 
> > For these pages, the pseudo-physical address in dom0 is different from
> > the physical address. Dom0 keeps track of the pseudo-physical to
> > physical relationship (pfn_to_mfn in Xen terminology). The swiotlb-xen
> > driver makes sure to return the right mfn from map_page and map_sg.
> 
> For my understanding, xen_dma_map_page() is called from dom0 and it
> simply calls the __generic_dma_ops()->map_page(). The "page" argument
> here is the dom0 page and it gets translated to dom0 phys and then to a
> bus address via xen_phys_to_bus().
> 
> On arm64, __swiotlb_map_page() uses the page structure to get some
> pseudo device address which gets converted back to a dom0 virtual
> address. The latter is used for cache maintenance by VA in dom0. With
> PIPT-like caches, that's fine, you don't need the actual machine PA
> unless you have caches like PL310 (which are not compatible with
> virtualisation anyway and the latest ARMv8 ARM even makes a clear
> statement here).
> 
> (one potential problem here is the dma_capable() check in
> swiotlb_map_page() (non-xen) which uses the pseudo device address)
> 
> The interesting part is that xen_swiotlb_map_page() returns the real
> machine device address to dom0, which is different from what dom0 thinks
> of a device address (phys_to_dma(phys_to_page(page))). Does dom0 use
> such real/machine device address to program the device directly or there
> is another layer where you could do the translation?

No other layer. Dom0 uses the real/machine device address returned by
xen_phys_to_bus to program the device directly.


> > However some of the dma_ops give you only a dma_addr_t handle
> > (unmap_page and unmap_sg), that is the physical address of the page.
> 
> OK, I started to get it now, the __swiotlb_unmap_page() on arm64, if
> called from dom0, would get the machine device address and dma_to_phys()
> does not work.

Right!


> > Dom0 doesn't know how to find the pseudo-physical address corresponding
> > to it. Therefore it also doesn't know how to find the struct page for
> > it. This is not a trivial problem to solve as the same page can be
> > granted multiple times, therefore could have multiple pseudo-physical
> > addresses and multiple struct pages corresponding to one physical
> > address in dom0.
> 
> So what is mfn_to_pfn() and xen_bus_to_phys() used for?

They are not used on ARM. But swiotlb-xen is not ARM specific and
xen_bus_to_phys is still important on x86. It works differently there.


> Isn't mfn_to_pfn(pfn_to_mfn(x)) an identity function?

Yes, it should be and it is for local pages.
However it is not an identity function for foreign pages, because
mfn_to_pfn is broken and just returns pfn on ARM, while pfn_to_mfn works
correctly.


> > Fortunately these dma_ops don't actually need to do much. In fact they
> > only need to flush caches if the device is not dma-coherent. So the
> > current proposed solution is to issue an hypercall to ask Xen to do the
> > flushing, passing the physical address dom0 knows.
> 
> I really don't like the dma_cache_maint() duplication you added in
> arch/arm/xen/mm32.c just because you cannot call the host dma_ops when
> the page is not available.

I agree is bad, but this patch series is a big step forward removing the
duplication. In fact now that I think about it, when a page is local (not a
foreign page) I could just call the host dma_ops. mm.c:dma_cache_maint
would only be used for foreign pages (pages for which !pfn_valid(pfn)).


> You basically only need a VA that was mapped in dom0 when map_page() was
> called and is still mapped when page_unmap() is called. You can free the
> actual mapping after calling __generic_dma_ops()->unmap_page() in
> xen_dma_unmap_page() (in xen_unmap_single()).

That is true, but where would I store the mapping?

I don't want to introduce another data structure to keep physical to va
or physical to struct page mappings that I need to modify at every
map_page and unmap_page. It wouldn't even be a trivial data structure as
multiple dma operations involving the same mfn but different struct page
can happen simultaneously.

The performance hit of maintaining such a data structure would be
significant.

It would negatively impact any dma operations involving any devices,
including dma coherent ones. While this series only requires special
handling of dma operations involving non-coherent devices (resulting in
an hypercall being made).

In a way this series rewards hardware that makes life easier to software
developers :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:12:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:12:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkGs-0005cQ-QW; Fri, 07 Nov 2014 14:12:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmkGr-0005bw-GL
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:12:13 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	84/4D-05632-C33DC545; Fri, 07 Nov 2014 14:12:12 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415369528!11070426!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26155 invoked from network); 7 Nov 2014 14:12:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:12:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="190564560"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 09:10:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmkFP-0004nQ-LW;
	Fri, 07 Nov 2014 14:10:43 +0000
Date: Fri, 7 Nov 2014 14:10:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107111126.GB21875@localhost>
Message-ID: <alpine.DEB.2.02.1411071239110.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<20141107111126.GB21875@localhost>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> On Fri, Nov 07, 2014 at 11:05:25AM +0000, Catalin Marinas wrote:
> > BTW, drivers/xen/swiotlb-xen.c needs something like:
> > 
> >         dma_addr_t dev_addr = xen_phys_to_bus(phys_to_dma(phys));
> > 
> > phys != bus address.
> 
> Wrong place, what I meant is when calling:
> 
>         xen_dma_unmap_page(hwdev, phys_to_dma(paddr), size, dir, attrs);

Well spotted! This is an actual mistake in the current code, independent
from the problem described before. Julien reported it a couple of days
ago and I have already queued a patch to fix it at the end of the
series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:16:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkLI-0005zH-Hj; Fri, 07 Nov 2014 14:16: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@citrix.com>) id 1XmkLH-0005zB-Gn
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 14:16:47 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B5/27-27584-E44DC545; Fri, 07 Nov 2014 14:16:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415369804!5722042!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22727 invoked from network); 7 Nov 2014 14:16:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:16:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189137960"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 09:16:36 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmkL5-0004uL-S6;
	Fri, 07 Nov 2014 14:16:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmkL5-0004ru-KY;
	Fri, 07 Nov 2014 14:16:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21596.54339.419631.476468@mariner.uk.xensource.com>
Date: Fri, 7 Nov 2014 14:16:35 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <280C1E5B-BBC8-4E62-9702-86B16E25103B@oracle.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
	<545CB43D.4030404@citrix.com>
	<280C1E5B-BBC8-4E62-9702-86B16E25103B@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] RC today or Monday or something ?"):
> Let's wait as I believe the issues that are making osstest choke are the swiotlb related - and Ian has them queued up for the next run I believe?
> 
> Hopefully by Monday it will clear up and master = staging.

Very possibly.  Certainly I think there's a reasonable chance.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:16:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkLI-0005zH-Hj; Fri, 07 Nov 2014 14:16: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@citrix.com>) id 1XmkLH-0005zB-Gn
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 14:16:47 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B5/27-27584-E44DC545; Fri, 07 Nov 2014 14:16:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415369804!5722042!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22727 invoked from network); 7 Nov 2014 14:16:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:16:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189137960"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 09:16:36 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmkL5-0004uL-S6;
	Fri, 07 Nov 2014 14:16:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmkL5-0004ru-KY;
	Fri, 07 Nov 2014 14:16:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21596.54339.419631.476468@mariner.uk.xensource.com>
Date: Fri, 7 Nov 2014 14:16:35 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <280C1E5B-BBC8-4E62-9702-86B16E25103B@oracle.com>
References: <21596.44787.649293.746269@mariner.uk.xensource.com>
	<545CB43D.4030404@citrix.com>
	<280C1E5B-BBC8-4E62-9702-86B16E25103B@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Russell Pavlicek <russell.pavlicek@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] RC today or Monday or something ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] RC today or Monday or something ?"):
> Let's wait as I believe the issues that are making osstest choke are the swiotlb related - and Ian has them queued up for the next run I believe?
> 
> Hopefully by Monday it will clear up and master = staging.

Very possibly.  Certainly I think there's a reasonable chance.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:21:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14: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 1XmkQ9-0006AU-CW; Fri, 07 Nov 2014 14:21:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XmkQ8-0006AP-5L
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 14:21:48 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	07/FA-02559-B75DC545; Fri, 07 Nov 2014 14:21:47 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415370105!12077784!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10684 invoked from network); 7 Nov 2014 14:21:46 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 14:21:46 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7ELedg017965
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 14:21:41 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA7ELeO8024776
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Nov 2014 14:21:40 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA7ELd9C024748; Fri, 7 Nov 2014 14:21:40 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 06:21:39 -0800
Message-ID: <545CD572.9040801@oracle.com>
Date: Fri, 07 Nov 2014 09:21:38 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
In-Reply-To: <20141107110512.GA12109@zion.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/07/2014 06:05 AM, Wei Liu wrote:
> On Thu, Nov 06, 2014 at 05:17:42PM -0500, Zhigang Wang wrote:
>> Hi,
>>
>> I get this error:
>>
>>     # xl mem-max 3 700
>>     libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max
>>     : Success
>>     cannot set domid 3 static max memory to : 700
>>
> 
> What's your expected behaviour? What's your end goal?

I expect: after start a VM with memory = 700, then I can do:

   # xl mem-max <domain> 700

In our code, we always check (libxl.c):


    if (max_memkb < memorykb) {
        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
        goto out;
    }

As target memory is always bigger than static-max in xenstore (from my test, for both pv and hvm):

    /local/domain/3/memory/static-max = "716800"
    /local/domain/3/memory/target = "716801

So it will not success.

Also I think target memory bigger than static-max seems not right.

Thanks,

Zhigang

> Can the behavior you expected be achieved by manipulating target memory
> instead of maxmem?
> 
> ISTR Oracle has different view on how memory targets are managed. But
> with no other information provided it's hard for me to figure out your
> intent and start a conversation.
> 
> Wei.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:21:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14: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 1XmkQ9-0006AU-CW; Fri, 07 Nov 2014 14:21:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XmkQ8-0006AP-5L
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 14:21:48 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	07/FA-02559-B75DC545; Fri, 07 Nov 2014 14:21:47 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415370105!12077784!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10684 invoked from network); 7 Nov 2014 14:21:46 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 14:21:46 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7ELedg017965
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 14:21:41 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sA7ELeO8024776
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Nov 2014 14:21:40 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA7ELd9C024748; Fri, 7 Nov 2014 14:21:40 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 06:21:39 -0800
Message-ID: <545CD572.9040801@oracle.com>
Date: Fri, 07 Nov 2014 09:21:38 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
In-Reply-To: <20141107110512.GA12109@zion.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/07/2014 06:05 AM, Wei Liu wrote:
> On Thu, Nov 06, 2014 at 05:17:42PM -0500, Zhigang Wang wrote:
>> Hi,
>>
>> I get this error:
>>
>>     # xl mem-max 3 700
>>     libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max
>>     : Success
>>     cannot set domid 3 static max memory to : 700
>>
> 
> What's your expected behaviour? What's your end goal?

I expect: after start a VM with memory = 700, then I can do:

   # xl mem-max <domain> 700

In our code, we always check (libxl.c):


    if (max_memkb < memorykb) {
        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
        goto out;
    }

As target memory is always bigger than static-max in xenstore (from my test, for both pv and hvm):

    /local/domain/3/memory/static-max = "716800"
    /local/domain/3/memory/target = "716801

So it will not success.

Also I think target memory bigger than static-max seems not right.

Thanks,

Zhigang

> Can the behavior you expected be achieved by manipulating target memory
> instead of maxmem?
> 
> ISTR Oracle has different view on how memory targets are managed. But
> with no other information provided it's hard for me to figure out your
> intent and start a conversation.
> 
> Wei.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:22:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkQd-0006Dm-Ty; Fri, 07 Nov 2014 14:22:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmkQc-0006Dd-Lv
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:22:18 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	BD/2D-26740-995DC545; Fri, 07 Nov 2014 14:22:17 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415370136!11073179!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30478 invoked from network); 7 Nov 2014 14:22:17 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-12.tower-31.messagelabs.com with SMTP;
	7 Nov 2014 14:22:17 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 821CA1AA;
	Fri,  7 Nov 2014 08:22:11 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 6D0075FAD7;
	Fri,  7 Nov 2014 08:22:09 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 1B2D313F91E;
	Fri,  7 Nov 2014 08:22:07 -0600 (CST)
Date: Fri, 7 Nov 2014 14:22:05 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107142205.GD29148@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-6-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1414422568-19103-6-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 6/8] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 27, 2014 at 03:09:26PM +0000, Stefano Stabellini wrote:
> Merge xen/mm32.c into xen/mm.c.
> As a consequence the code gets compiled on arm64 too: introduce a few
> compat functions to actually be able to compile it.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Since I missed the commit introducing mm32.c (340720be32d4 xen/arm:
reimplement xen_dma_unmap_page & friends), I'll add a retrospective NAK ;).

The main reason is the asymmetry between dma map and unmap. With host
swiotlb somehow getting !dma_capable(dev), you even risk leaking dom0
swiotlb bounce buffers (on arm64).

> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
[...]
> +/* functions called by SWIOTLB */
> +
> +static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
> +       size_t size, enum dma_data_direction dir,
> +       void (*op)(const void *, size_t, int))
> +{
> +       unsigned long pfn;
> +       size_t left = size;
> +
> +       pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
> +       offset %= PAGE_SIZE;
> +
> +       do {
> +               size_t len = left;
> +               void *vaddr;
> +
> +               if (!pfn_valid(pfn))

Is this the pfn or the mfn? As you said in the previous email, there is
no mfn_to_pfn() conversion, so that's actually in another address space
where dom0 pfn_valid() would not make sense.

Do you use this as a check for foreign pages? If yes, is the mfn for
such pages guaranteed to be different from any valid dom0 pfn?

> +               {
> +                       /* TODO: cache flush */

What does this TODO mean here? Which cases are not covered yet?

> +               } else {
> +                       struct page *page = pfn_to_page(pfn);

If the pfn here is correct, can you not just have something like:

void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
		size_t size, enum dma_data_direction dir,
		struct dma_attrs *attrs)

{
	unsigned long pfn = handle >> PAGE_SHIFT;	/* could use some macros */
	if (!pfn_valid(pfn)) {
		/* FIXME */
		return;
	}
	__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
}

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:22:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkQd-0006Dm-Ty; Fri, 07 Nov 2014 14:22:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmkQc-0006Dd-Lv
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:22:18 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	BD/2D-26740-995DC545; Fri, 07 Nov 2014 14:22:17 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415370136!11073179!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30478 invoked from network); 7 Nov 2014 14:22:17 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-12.tower-31.messagelabs.com with SMTP;
	7 Nov 2014 14:22:17 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 821CA1AA;
	Fri,  7 Nov 2014 08:22:11 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 6D0075FAD7;
	Fri,  7 Nov 2014 08:22:09 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 1B2D313F91E;
	Fri,  7 Nov 2014 08:22:07 -0600 (CST)
Date: Fri, 7 Nov 2014 14:22:05 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107142205.GD29148@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-6-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1414422568-19103-6-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 6/8] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 27, 2014 at 03:09:26PM +0000, Stefano Stabellini wrote:
> Merge xen/mm32.c into xen/mm.c.
> As a consequence the code gets compiled on arm64 too: introduce a few
> compat functions to actually be able to compile it.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Since I missed the commit introducing mm32.c (340720be32d4 xen/arm:
reimplement xen_dma_unmap_page & friends), I'll add a retrospective NAK ;).

The main reason is the asymmetry between dma map and unmap. With host
swiotlb somehow getting !dma_capable(dev), you even risk leaking dom0
swiotlb bounce buffers (on arm64).

> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
[...]
> +/* functions called by SWIOTLB */
> +
> +static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
> +       size_t size, enum dma_data_direction dir,
> +       void (*op)(const void *, size_t, int))
> +{
> +       unsigned long pfn;
> +       size_t left = size;
> +
> +       pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
> +       offset %= PAGE_SIZE;
> +
> +       do {
> +               size_t len = left;
> +               void *vaddr;
> +
> +               if (!pfn_valid(pfn))

Is this the pfn or the mfn? As you said in the previous email, there is
no mfn_to_pfn() conversion, so that's actually in another address space
where dom0 pfn_valid() would not make sense.

Do you use this as a check for foreign pages? If yes, is the mfn for
such pages guaranteed to be different from any valid dom0 pfn?

> +               {
> +                       /* TODO: cache flush */

What does this TODO mean here? Which cases are not covered yet?

> +               } else {
> +                       struct page *page = pfn_to_page(pfn);

If the pfn here is correct, can you not just have something like:

void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
		size_t size, enum dma_data_direction dir,
		struct dma_attrs *attrs)

{
	unsigned long pfn = handle >> PAGE_SHIFT;	/* could use some macros */
	if (!pfn_valid(pfn)) {
		/* FIXME */
		return;
	}
	__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
}

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:35:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkdI-0006an-G0; Fri, 07 Nov 2014 14:35:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmkdG-0006ai-NA
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 14:35:22 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	FD/9F-23865-9A8DC545; Fri, 07 Nov 2014 14:35:21 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415370920!11150705!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7226 invoked from network); 7 Nov 2014 14:35:20 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:35:20 -0000
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLJ59514; Fri, 07 Nov 2014 14:35:13 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Fri, 7 Nov 2014 14:34:49 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Zoltan Kiss
	<zoltan.kiss@linaro.org>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
Thread-Index: AQHP+Nzd4ugSrwBZ1kiv4kYRXsWoAZxSDIYAgAAR8oCAATzvAIAB0nQAgAAQACA=
Date: Fri, 7 Nov 2014 14:34:48 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17DF85@lhreml509-mbb>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
	<545A2A96.8060105@linaro.org>
	<alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
	<545B4380.3050209@linaro.org> <545CCACA.7050406@linaro.org>
In-Reply-To: <545CCACA.7050406@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.66.6]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Tim Deegan <tim@xen.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi Zoltan,
> 
> On 06/11/2014 09:46, Zoltan Kiss wrote:
> >
> >
> > On 05/11/14 14:52, Stefano Stabellini wrote:
> >> On Wed, 5 Nov 2014, Julien Grall wrote:
> >>> Hi Frediano,
> >>>
> >>> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> >>>> This name can appear in some Linux kernel repos. Not very
> >>>> fortunate, but to avoid others spending an hour to spot that few
> >>>> characters difference it worth to work around it.
> >>>
> >>> Linux upstream is using "hisilicon,hip04-intc" to detect the
> >>> hisilicon interrupt controller. So it's not a workaround.
> >>>
> >>> Which kernel is using the "*,hip04-gic"?
> >>
> >> Good question, but what really matters is the string that u-boot (or
> >> any other firmware/bootloader) is going to use, right? So, which one
> is it?
> > We are using the DTB from the kernel source, even when loading a bare
> > metal kernel. I've looked around, the *gic version seems to exist
> only
> > in internal repos, as far as I can see. Including the one Frediano
> > started to use for porting. Therefore, I don't insist to keep both,
> > but as I mentioned in the commit message, it would still provide some
> > benefit, and given that it's just a 3 line change which just extend a
> > few listings, I think we should keep it.
> > Of course with a different commit message, which clears that this is
> > the official name of it.
> 
> If it's only used in your internal repo, we shouldn't support this
> compatible string in Xen.
> 
> Nothing prevent someone in the future to use this compatible for a
> completely different purpose (for instance a different GIC driver).
> 
> We aim to support only official bindings to avoid a such issue.
> 
> Regards,
> 

Now all changes for old development compatible string are in a single patch so feel free to drop it.

Regards,
  Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:35:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkdI-0006an-G0; Fri, 07 Nov 2014 14:35:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XmkdG-0006ai-NA
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 14:35:22 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	FD/9F-23865-9A8DC545; Fri, 07 Nov 2014 14:35:21 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415370920!11150705!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7226 invoked from network); 7 Nov 2014 14:35:20 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:35:20 -0000
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLJ59514; Fri, 07 Nov 2014 14:35:13 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001;
	Fri, 7 Nov 2014 14:34:49 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Julien Grall <julien.grall@linaro.org>, Zoltan Kiss
	<zoltan.kiss@linaro.org>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
	strange names of Hip04 GICv2
Thread-Index: AQHP+Nzd4ugSrwBZ1kiv4kYRXsWoAZxSDIYAgAAR8oCAATzvAIAB0nQAgAAQACA=
Date: Fri, 7 Nov 2014 14:34:48 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17DF85@lhreml509-mbb>
References: <1415180475-8339-1-git-send-email-frediano.ziglio@huawei.com>
	<1415180475-8339-5-git-send-email-frediano.ziglio@huawei.com>
	<545A2A96.8060105@linaro.org>
	<alpine.DEB.2.02.1411051443130.22875@kaball.uk.xensource.com>
	<545B4380.3050209@linaro.org> <545CCACA.7050406@linaro.org>
In-Reply-To: <545CCACA.7050406@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.66.6]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Tim Deegan <tim@xen.org>, Zoltan Kiss <zoltan.kiss@huawei.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 4/8] xen/arm: Add support for DTBs with
 strange names of Hip04 GICv2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi Zoltan,
> 
> On 06/11/2014 09:46, Zoltan Kiss wrote:
> >
> >
> > On 05/11/14 14:52, Stefano Stabellini wrote:
> >> On Wed, 5 Nov 2014, Julien Grall wrote:
> >>> Hi Frediano,
> >>>
> >>> On 11/05/2014 09:41 AM, Frediano Ziglio wrote:
> >>>> This name can appear in some Linux kernel repos. Not very
> >>>> fortunate, but to avoid others spending an hour to spot that few
> >>>> characters difference it worth to work around it.
> >>>
> >>> Linux upstream is using "hisilicon,hip04-intc" to detect the
> >>> hisilicon interrupt controller. So it's not a workaround.
> >>>
> >>> Which kernel is using the "*,hip04-gic"?
> >>
> >> Good question, but what really matters is the string that u-boot (or
> >> any other firmware/bootloader) is going to use, right? So, which one
> is it?
> > We are using the DTB from the kernel source, even when loading a bare
> > metal kernel. I've looked around, the *gic version seems to exist
> only
> > in internal repos, as far as I can see. Including the one Frediano
> > started to use for porting. Therefore, I don't insist to keep both,
> > but as I mentioned in the commit message, it would still provide some
> > benefit, and given that it's just a 3 line change which just extend a
> > few listings, I think we should keep it.
> > Of course with a different commit message, which clears that this is
> > the official name of it.
> 
> If it's only used in your internal repo, we shouldn't support this
> compatible string in Xen.
> 
> Nothing prevent someone in the future to use this compatible for a
> completely different purpose (for instance a different GIC driver).
> 
> We aim to support only official bindings to avoid a such issue.
> 
> Regards,
> 

Now all changes for old development compatible string are in a single patch so feel free to drop it.

Regards,
  Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:41:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:41:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmkif-0006jM-9n; Fri, 07 Nov 2014 14:40:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xmkid-0006jH-C8
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:40:55 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	41/63-17694-6F9DC545; Fri, 07 Nov 2014 14:40:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415371252!11136374!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12033 invoked from network); 7 Nov 2014 14:40:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:40:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189146698"
Message-ID: <545CD9F2.80208@citrix.com>
Date: Fri, 7 Nov 2014 14:40:50 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<boris.ostrovsky@oracle.com>, <x86@kernel.org>, <tglx@linutronix.de>,
	<mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-6-git-send-email-jgross@suse.com>
	<545CCF15.4070402@citrix.com> <545CD306.90001@suse.com>
In-Reply-To: <545CD306.90001@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/11/14 14:11, Juergen Gross wrote:
> On 11/07/2014 02:54 PM, David Vrabel wrote:
>> On 06/11/14 05:47, Juergen Gross wrote:
>> [...]
>>> @@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long
>>> pfn)
>>>           return IDENTITY_FRAME(pfn);
>>>       }
>>>
>>> -    topidx = p2m_top_index(pfn);
>>> -    mididx = p2m_mid_index(pfn);
>>> -    idx = p2m_index(pfn);
>>> +    ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
>>> +    BUG_ON(!ptep || level != PG_LEVEL_4K);
>>>
>>>       /*
>>>        * The INVALID_P2M_ENTRY is filled in both p2m_*identity
>>>        * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
>>>        * would be wrong.
>>>        */
>>> -    if (p2m_top[topidx][mididx] == p2m_identity)
>>> +    if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
>>>           return IDENTITY_FRAME(pfn);
>>>
>>> -    return p2m_top[topidx][mididx][idx];
>>> +    return xen_p2m_addr[pfn];
>>
>> You should test xen_p2m_addr[pfn] == INVALID_P2M_ENTRY before checking
>> if it's an identity entry.  This should skip the more expensive
>> lookup_address() in the common case.
> 
> I do. The check is in __pfn_to_mfn(). get_phys_to_machine() is called in
> this case only.

So you do.  I missed that.

>>>   bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>>
>> I think you should map p2m_missing and p2m_identity as read-only and do
>> the new page allocation on a write fault.
>>
>> set_phys_to_machine() is used every grant map and unmap and in the
>> common case (already allocated array page) it must be a fast and simple:
>>
>>      xen_p2m_addr[pfn] = mfn;
> 
> Nice idea. I'll try it.

You probably want to try this with a custom exception fixup (or abuse
put_user()).

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:41:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:41:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmkif-0006jM-9n; Fri, 07 Nov 2014 14:40:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xmkid-0006jH-C8
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:40:55 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	41/63-17694-6F9DC545; Fri, 07 Nov 2014 14:40:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415371252!11136374!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12033 invoked from network); 7 Nov 2014 14:40:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:40:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189146698"
Message-ID: <545CD9F2.80208@citrix.com>
Date: Fri, 7 Nov 2014 14:40:50 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<boris.ostrovsky@oracle.com>, <x86@kernel.org>, <tglx@linutronix.de>,
	<mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-6-git-send-email-jgross@suse.com>
	<545CCF15.4070402@citrix.com> <545CD306.90001@suse.com>
In-Reply-To: <545CD306.90001@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/11/14 14:11, Juergen Gross wrote:
> On 11/07/2014 02:54 PM, David Vrabel wrote:
>> On 06/11/14 05:47, Juergen Gross wrote:
>> [...]
>>> @@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long
>>> pfn)
>>>           return IDENTITY_FRAME(pfn);
>>>       }
>>>
>>> -    topidx = p2m_top_index(pfn);
>>> -    mididx = p2m_mid_index(pfn);
>>> -    idx = p2m_index(pfn);
>>> +    ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
>>> +    BUG_ON(!ptep || level != PG_LEVEL_4K);
>>>
>>>       /*
>>>        * The INVALID_P2M_ENTRY is filled in both p2m_*identity
>>>        * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
>>>        * would be wrong.
>>>        */
>>> -    if (p2m_top[topidx][mididx] == p2m_identity)
>>> +    if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
>>>           return IDENTITY_FRAME(pfn);
>>>
>>> -    return p2m_top[topidx][mididx][idx];
>>> +    return xen_p2m_addr[pfn];
>>
>> You should test xen_p2m_addr[pfn] == INVALID_P2M_ENTRY before checking
>> if it's an identity entry.  This should skip the more expensive
>> lookup_address() in the common case.
> 
> I do. The check is in __pfn_to_mfn(). get_phys_to_machine() is called in
> this case only.

So you do.  I missed that.

>>>   bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>>
>> I think you should map p2m_missing and p2m_identity as read-only and do
>> the new page allocation on a write fault.
>>
>> set_phys_to_machine() is used every grant map and unmap and in the
>> common case (already allocated array page) it must be a fast and simple:
>>
>>      xen_p2m_addr[pfn] = mfn;
> 
> Nice idea. I'll try it.

You probably want to try this with a custom exception fixup (or abuse
put_user()).

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:43:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:43:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmklY-0006qc-Rs; Fri, 07 Nov 2014 14:43:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmklY-0006qV-03
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:43:56 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	91/62-11581-BAADC545; Fri, 07 Nov 2014 14:43:55 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415371434!11180631!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10203 invoked from network); 7 Nov 2014 14:43:54 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 14:43:54 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id E1D29AB08;
	Fri,  7 Nov 2014 14:43:53 +0000 (UTC)
Message-ID: <545CDAA8.4050803@suse.com>
Date: Fri, 07 Nov 2014 15:43:52 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-6-git-send-email-jgross@suse.com>
	<545CCF15.4070402@citrix.com> <545CD306.90001@suse.com>
	<545CD9F2.80208@citrix.com>
In-Reply-To: <545CD9F2.80208@citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped
 sparse p2m 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

On 11/07/2014 03:40 PM, David Vrabel wrote:
> On 07/11/14 14:11, Juergen Gross wrote:
>> On 11/07/2014 02:54 PM, David Vrabel wrote:
>>> On 06/11/14 05:47, Juergen Gross wrote:
>>> [...]
>>>> @@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long
>>>> pfn)
>>>>            return IDENTITY_FRAME(pfn);
>>>>        }
>>>>
>>>> -    topidx = p2m_top_index(pfn);
>>>> -    mididx = p2m_mid_index(pfn);
>>>> -    idx = p2m_index(pfn);
>>>> +    ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
>>>> +    BUG_ON(!ptep || level != PG_LEVEL_4K);
>>>>
>>>>        /*
>>>>         * The INVALID_P2M_ENTRY is filled in both p2m_*identity
>>>>         * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
>>>>         * would be wrong.
>>>>         */
>>>> -    if (p2m_top[topidx][mididx] == p2m_identity)
>>>> +    if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
>>>>            return IDENTITY_FRAME(pfn);
>>>>
>>>> -    return p2m_top[topidx][mididx][idx];
>>>> +    return xen_p2m_addr[pfn];
>>>
>>> You should test xen_p2m_addr[pfn] == INVALID_P2M_ENTRY before checking
>>> if it's an identity entry.  This should skip the more expensive
>>> lookup_address() in the common case.
>>
>> I do. The check is in __pfn_to_mfn(). get_phys_to_machine() is called in
>> this case only.
>
> So you do.  I missed that.
>
>>>>    bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>>>
>>> I think you should map p2m_missing and p2m_identity as read-only and do
>>> the new page allocation on a write fault.
>>>
>>> set_phys_to_machine() is used every grant map and unmap and in the
>>> common case (already allocated array page) it must be a fast and simple:
>>>
>>>       xen_p2m_addr[pfn] = mfn;
>>
>> Nice idea. I'll try it.
>
> You probably want to try this with a custom exception fixup (or abuse
> put_user()).

Yeah, that was my idea, too.

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:43:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:43:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmklY-0006qc-Rs; Fri, 07 Nov 2014 14:43:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XmklY-0006qV-03
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:43:56 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	91/62-11581-BAADC545; Fri, 07 Nov 2014 14:43:55 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415371434!11180631!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10203 invoked from network); 7 Nov 2014 14:43:54 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 14:43:54 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id E1D29AB08;
	Fri,  7 Nov 2014 14:43:53 +0000 (UTC)
Message-ID: <545CDAA8.4050803@suse.com>
Date: Fri, 07 Nov 2014 15:43:52 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-6-git-send-email-jgross@suse.com>
	<545CCF15.4070402@citrix.com> <545CD306.90001@suse.com>
	<545CD9F2.80208@citrix.com>
In-Reply-To: <545CD9F2.80208@citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped
 sparse p2m 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

On 11/07/2014 03:40 PM, David Vrabel wrote:
> On 07/11/14 14:11, Juergen Gross wrote:
>> On 11/07/2014 02:54 PM, David Vrabel wrote:
>>> On 06/11/14 05:47, Juergen Gross wrote:
>>> [...]
>>>> @@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long
>>>> pfn)
>>>>            return IDENTITY_FRAME(pfn);
>>>>        }
>>>>
>>>> -    topidx = p2m_top_index(pfn);
>>>> -    mididx = p2m_mid_index(pfn);
>>>> -    idx = p2m_index(pfn);
>>>> +    ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
>>>> +    BUG_ON(!ptep || level != PG_LEVEL_4K);
>>>>
>>>>        /*
>>>>         * The INVALID_P2M_ENTRY is filled in both p2m_*identity
>>>>         * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
>>>>         * would be wrong.
>>>>         */
>>>> -    if (p2m_top[topidx][mididx] == p2m_identity)
>>>> +    if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
>>>>            return IDENTITY_FRAME(pfn);
>>>>
>>>> -    return p2m_top[topidx][mididx][idx];
>>>> +    return xen_p2m_addr[pfn];
>>>
>>> You should test xen_p2m_addr[pfn] == INVALID_P2M_ENTRY before checking
>>> if it's an identity entry.  This should skip the more expensive
>>> lookup_address() in the common case.
>>
>> I do. The check is in __pfn_to_mfn(). get_phys_to_machine() is called in
>> this case only.
>
> So you do.  I missed that.
>
>>>>    bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>>>
>>> I think you should map p2m_missing and p2m_identity as read-only and do
>>> the new page allocation on a write fault.
>>>
>>> set_phys_to_machine() is used every grant map and unmap and in the
>>> common case (already allocated array page) it must be a fast and simple:
>>>
>>>       xen_p2m_addr[pfn] = mfn;
>>
>> Nice idea. I'll try it.
>
> You probably want to try this with a custom exception fixup (or abuse
> put_user()).

Yeah, that was my idea, too.

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:51:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14: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 1XmksS-00073G-PQ; Fri, 07 Nov 2014 14:51:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XmksR-00073B-9K
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 14:51:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7A/CA-09842-65CDC545; Fri, 07 Nov 2014 14:51:02 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415371862!12254383!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8942 invoked from network); 7 Nov 2014 14:51:02 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:51:02 -0000
Received: by mail-wg0-f41.google.com with SMTP id k14so3883591wgh.28
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 06:51:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=hJCQbM1t5ceuxSTm6VcgGGTvZmz/4AA2X8wok5TACoI=;
	b=izgqvKBwMuGrwMdPUsOJy9/it3NkUF13rxrL9zpb0tZWNWrv6v6ftK3RCBHREvNsE4
	ZKAeqnq6fVYXWGafb5u7EwxPXvAoi5lUwKafSjbbU4ik433XA78rBt5F7jMaXjaB3UPQ
	TWEeiMDl86tkTQl0B//hK6YstIG+nZ1w+z4I9mslg7ZbcNnDyCpSK8BL+xYRzV62trSb
	zBeOAnAYM0Lh6inmn5+E0guUMAvGjdoOLl+PgTj5sfH3+1W0U5LTOsW+Jly0mv7O8mkR
	KCybphdxoAAh2WVjkmQtzzGwfxLl3pI/E98bTOT36qL2SXlK3Vzt8kkED/eHjRDR6omn
	g2wQ==
X-Gm-Message-State: ALoCoQmIMsGvt4A2iwrNltqv8/9B95uUdQQz4QLULfiARita7QndQZEymPEZXEVnbq6Urh9dBBDt
X-Received: by 10.195.13.161 with SMTP id ez1mr14529946wjd.126.1415371861689; 
	Fri, 07 Nov 2014 06:51:01 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	da3sm12080083wjb.12.2014.11.07.06.51.00 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 06:51:01 -0800 (PST)
Message-ID: <545CDC54.9050305@linaro.org>
Date: Fri, 07 Nov 2014 14:51:00 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>, 
	David Vrabel <david.vrabel@citrix.com>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20141106214940.GD44162@ubuntu-hedt> <545CA27F.4070400@citrix.com>
	<545CA823.2080307@canonical.com>
In-Reply-To: <545CA823.2080307@canonical.com>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 07/11/14 11:08, Stefan Bader wrote:
> On 07.11.2014 11:44, David Vrabel wrote:
>> On 06/11/14 21:49, Seth Forshee wrote:
>>> We've had several reports of hitting the following BUG_ON in
>>> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
>>> results of testing with 3.17):
>>>
>>>          /* Grant backend access to each skb fragment page. */
>>>          for (i = 0; i < frags; i++) {
>>>                  skb_frag_t *frag = skb_shinfo(skb)->frags + i;
>>>                  struct page *page = skb_frag_page(frag);
>>>
>>>                  len = skb_frag_size(frag);
>>>                  offset = frag->page_offset;
>>>
>>>                  /* Data must not cross a page boundary. */
>>>                  BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
>>>
>>> When this happens the page in question is a "middle" page in a compound
>>> page (i.e. it's a tail page but not the last tail page), and the data is
>>> fully contained within the compound page. The data does however cross
>>> the hardware page boundary, and since compound_order evaluates to 0 for
>>> tail pages the check fails.
>>>
>>> In going over this I've been unable to determine whether the BUG_ON in
>>> xennet_make_frags is incorrect or the paged skb data is wrong. I can't
>>> find that it's documented anywhere, and the networking code itself is a
>>> bit ambiguous when it comes to compound pages. On the one hand
>>> __skb_fill_page_desc specifically handles adding tail pages as paged
>>> data, but on the other hand skb_copy_bits kmaps frag->page.p which could
>>> fail with data that extends into another page.
>>
>> netfront will safely handle this case so you can remove this BUG_ON()
>> (and the one later on).  But it would be better to find out were these
>> funny-looking skbs are coming from and (if necessary) fixing the bug there.
>
> Right, in fact it does ignore pages from the start of a compound page in case
> the offset is big enough. So there is no difference between that case and the
> one where the page pointer from the frag is adjusted the way it was observed.
>
> It really boils down to the question what the real rules for the frags are. If
> it is "only" that data may not cross the boundary of a hw or compound page this
> leaves room for interpretation. The odd skb does not violate that but a check
> for conformance would become a lot more complex. And netfront is not the only
> place that expects the frag page to be pointing to the compound head (there is
> igb for example, though it does only a warn_on upon failing).
>
> On the other hand the __skb_fill_page_desc is written in a way that seems to
> assume the frag page pointer may be pointing to a tail page. So before "blaming"
> one piece of code or the other we need an authoritative answer to what we are
> supposed to expect.

Looking at skb_copy_bits and kmap_atomic it looks confusing indeed. It 
seems kmap_atomic maps only the actual page, not the whole compound, and 
it doesn't matter whether you gave a head or a tail page to it. 
Therefore if skb_copy_bits comes over a frag where the buffer exceeds 
the page the pointer points to, it shouldn't work.
This raises a few question in me:

- I assume frags are allowed to have compound pages, where page.p points 
to the head, and the buffer can be anywhere in the compound, e.g. offset 
= 9000 and len = 4000 is allowed (if the compound is more than four 4k 
pages, of course). Is this assumption correct?
- Is it then allowed to have page.p pointed to a tail page of the 
compound? To use the above example: page.p points to the third page, and 
offset is 808. Or pointer points to the second page, and offset is 4904. 
(the answer to the above two question should be documented somewhere, or 
codified)
- how does it works with skb_copy_bits? kmap_atomic seems to map only 
the actual page, not the whole compound.

Zoli

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:51:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14: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 1XmksS-00073G-PQ; Fri, 07 Nov 2014 14:51:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XmksR-00073B-9K
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 14:51:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7A/CA-09842-65CDC545; Fri, 07 Nov 2014 14:51:02 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415371862!12254383!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8942 invoked from network); 7 Nov 2014 14:51:02 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:51:02 -0000
Received: by mail-wg0-f41.google.com with SMTP id k14so3883591wgh.28
	for <xen-devel@lists.xenproject.org>;
	Fri, 07 Nov 2014 06:51:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=hJCQbM1t5ceuxSTm6VcgGGTvZmz/4AA2X8wok5TACoI=;
	b=izgqvKBwMuGrwMdPUsOJy9/it3NkUF13rxrL9zpb0tZWNWrv6v6ftK3RCBHREvNsE4
	ZKAeqnq6fVYXWGafb5u7EwxPXvAoi5lUwKafSjbbU4ik433XA78rBt5F7jMaXjaB3UPQ
	TWEeiMDl86tkTQl0B//hK6YstIG+nZ1w+z4I9mslg7ZbcNnDyCpSK8BL+xYRzV62trSb
	zBeOAnAYM0Lh6inmn5+E0guUMAvGjdoOLl+PgTj5sfH3+1W0U5LTOsW+Jly0mv7O8mkR
	KCybphdxoAAh2WVjkmQtzzGwfxLl3pI/E98bTOT36qL2SXlK3Vzt8kkED/eHjRDR6omn
	g2wQ==
X-Gm-Message-State: ALoCoQmIMsGvt4A2iwrNltqv8/9B95uUdQQz4QLULfiARita7QndQZEymPEZXEVnbq6Urh9dBBDt
X-Received: by 10.195.13.161 with SMTP id ez1mr14529946wjd.126.1415371861689; 
	Fri, 07 Nov 2014 06:51:01 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	da3sm12080083wjb.12.2014.11.07.06.51.00 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 07 Nov 2014 06:51:01 -0800 (PST)
Message-ID: <545CDC54.9050305@linaro.org>
Date: Fri, 07 Nov 2014 14:51:00 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>, 
	David Vrabel <david.vrabel@citrix.com>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20141106214940.GD44162@ubuntu-hedt> <545CA27F.4070400@citrix.com>
	<545CA823.2080307@canonical.com>
In-Reply-To: <545CA823.2080307@canonical.com>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 07/11/14 11:08, Stefan Bader wrote:
> On 07.11.2014 11:44, David Vrabel wrote:
>> On 06/11/14 21:49, Seth Forshee wrote:
>>> We've had several reports of hitting the following BUG_ON in
>>> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
>>> results of testing with 3.17):
>>>
>>>          /* Grant backend access to each skb fragment page. */
>>>          for (i = 0; i < frags; i++) {
>>>                  skb_frag_t *frag = skb_shinfo(skb)->frags + i;
>>>                  struct page *page = skb_frag_page(frag);
>>>
>>>                  len = skb_frag_size(frag);
>>>                  offset = frag->page_offset;
>>>
>>>                  /* Data must not cross a page boundary. */
>>>                  BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
>>>
>>> When this happens the page in question is a "middle" page in a compound
>>> page (i.e. it's a tail page but not the last tail page), and the data is
>>> fully contained within the compound page. The data does however cross
>>> the hardware page boundary, and since compound_order evaluates to 0 for
>>> tail pages the check fails.
>>>
>>> In going over this I've been unable to determine whether the BUG_ON in
>>> xennet_make_frags is incorrect or the paged skb data is wrong. I can't
>>> find that it's documented anywhere, and the networking code itself is a
>>> bit ambiguous when it comes to compound pages. On the one hand
>>> __skb_fill_page_desc specifically handles adding tail pages as paged
>>> data, but on the other hand skb_copy_bits kmaps frag->page.p which could
>>> fail with data that extends into another page.
>>
>> netfront will safely handle this case so you can remove this BUG_ON()
>> (and the one later on).  But it would be better to find out were these
>> funny-looking skbs are coming from and (if necessary) fixing the bug there.
>
> Right, in fact it does ignore pages from the start of a compound page in case
> the offset is big enough. So there is no difference between that case and the
> one where the page pointer from the frag is adjusted the way it was observed.
>
> It really boils down to the question what the real rules for the frags are. If
> it is "only" that data may not cross the boundary of a hw or compound page this
> leaves room for interpretation. The odd skb does not violate that but a check
> for conformance would become a lot more complex. And netfront is not the only
> place that expects the frag page to be pointing to the compound head (there is
> igb for example, though it does only a warn_on upon failing).
>
> On the other hand the __skb_fill_page_desc is written in a way that seems to
> assume the frag page pointer may be pointing to a tail page. So before "blaming"
> one piece of code or the other we need an authoritative answer to what we are
> supposed to expect.

Looking at skb_copy_bits and kmap_atomic it looks confusing indeed. It 
seems kmap_atomic maps only the actual page, not the whole compound, and 
it doesn't matter whether you gave a head or a tail page to it. 
Therefore if skb_copy_bits comes over a frag where the buffer exceeds 
the page the pointer points to, it shouldn't work.
This raises a few question in me:

- I assume frags are allowed to have compound pages, where page.p points 
to the head, and the buffer can be anywhere in the compound, e.g. offset 
= 9000 and len = 4000 is allowed (if the compound is more than four 4k 
pages, of course). Is this assumption correct?
- Is it then allowed to have page.p pointed to a tail page of the 
compound? To use the above example: page.p points to the third page, and 
offset is 808. Or pointer points to the second page, and offset is 4904. 
(the answer to the above two question should be documented somewhere, or 
codified)
- how does it works with skb_copy_bits? kmap_atomic seems to map only 
the actual page, not the whole compound.

Zoli

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:58:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:58:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkzX-0007EM-NW; Fri, 07 Nov 2014 14:58:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XmkzW-0007EH-5K
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:58:22 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	F0/AB-22819-D0EDC545; Fri, 07 Nov 2014 14:58:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415372298!7788669!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1875 invoked from network); 7 Nov 2014 14:58:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:58:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189152120"
Message-ID: <545CDDF6.9080902@citrix.com>
Date: Fri, 7 Nov 2014 14:57:58 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-2-git-send-email-jgross@suse.com>
In-Reply-To: <1415252853-7106-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V2 1/5] Xen: Delay remapping memory of
	pv-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 06/11/14 05:47, Juergen Gross wrote:
> Early in the boot process the memory layout of a pv-domain is changed
> to match the E820 map (either the host one for Dom0 or the Xen one)
> regarding placement of RAM and PCI holes. This requires removing memory
> pages initially located at positions not suitable for RAM and adding
> them later at higher addresses where no restrictions apply.
> 
> To be able to operate on the hypervisor supported p2m list until a
> virtual mapped linear p2m list can be constructed, remapping must
> be delayed until virtual memory management is initialized, as the
> initial p2m list can't be extended unlimited at physical memory
> initialization time due to it's fixed structure.
> 
> A further advantage is the reduction in complexity and code volume as
> we don't have to be careful regarding memory restrictions during p2m
> updates.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

But I would like a second reviewed-by.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 14:58:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 14:58:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmkzX-0007EM-NW; Fri, 07 Nov 2014 14:58:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XmkzW-0007EH-5K
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 14:58:22 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	F0/AB-22819-D0EDC545; Fri, 07 Nov 2014 14:58:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415372298!7788669!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1875 invoked from network); 7 Nov 2014 14:58:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 14:58:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,332,1413244800"; d="scan'208";a="189152120"
Message-ID: <545CDDF6.9080902@citrix.com>
Date: Fri, 7 Nov 2014 14:57:58 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415252853-7106-1-git-send-email-jgross@suse.com>
	<1415252853-7106-2-git-send-email-jgross@suse.com>
In-Reply-To: <1415252853-7106-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V2 1/5] Xen: Delay remapping memory of
	pv-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 06/11/14 05:47, Juergen Gross wrote:
> Early in the boot process the memory layout of a pv-domain is changed
> to match the E820 map (either the host one for Dom0 or the Xen one)
> regarding placement of RAM and PCI holes. This requires removing memory
> pages initially located at positions not suitable for RAM and adding
> them later at higher addresses where no restrictions apply.
> 
> To be able to operate on the hypervisor supported p2m list until a
> virtual mapped linear p2m list can be constructed, remapping must
> be delayed until virtual memory management is initialized, as the
> initial p2m list can't be extended unlimited at physical memory
> initialization time due to it's fixed structure.
> 
> A further advantage is the reduction in complexity and code volume as
> we don't have to be careful regarding memory restrictions during p2m
> updates.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

But I would like a second reviewed-by.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 15:36:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 15:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmlaB-0007dh-VX; Fri, 07 Nov 2014 15:36:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmlaB-0007dc-F1
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 15:36:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6D/23-09936-EE6EC545; Fri, 07 Nov 2014 15:36:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415374570!12287080!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8414 invoked from network); 7 Nov 2014 15:36:13 -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;
	7 Nov 2014 15:36:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="190596674"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 10:36:07 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmlSx-0006A1-Py;
	Fri, 07 Nov 2014 15:28:47 +0000
Date: Fri, 7 Nov 2014 15:28:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107142205.GD29148@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411071523170.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141107142205.GD29148@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 6/8] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> On Mon, Oct 27, 2014 at 03:09:26PM +0000, Stefano Stabellini wrote:
> > Merge xen/mm32.c into xen/mm.c.
> > As a consequence the code gets compiled on arm64 too: introduce a few
> > compat functions to actually be able to compile it.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Since I missed the commit introducing mm32.c (340720be32d4 xen/arm:
> reimplement xen_dma_unmap_page & friends), I'll add a retrospective NAK ;).
> 
> The main reason is the asymmetry between dma map and unmap. With host
> swiotlb somehow getting !dma_capable(dev), you even risk leaking dom0
> swiotlb bounce buffers (on arm64).
> 
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> [...]
> > +/* functions called by SWIOTLB */
> > +
> > +static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
> > +       size_t size, enum dma_data_direction dir,
> > +       void (*op)(const void *, size_t, int))
> > +{
> > +       unsigned long pfn;
> > +       size_t left = size;
> > +
> > +       pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
> > +       offset %= PAGE_SIZE;
> > +
> > +       do {
> > +               size_t len = left;
> > +               void *vaddr;
> > +
> > +               if (!pfn_valid(pfn))
> 
> Is this the pfn or the mfn? As you said in the previous email, there is
> no mfn_to_pfn() conversion, so that's actually in another address space
> where dom0 pfn_valid() would not make sense.

That is actually the mfn. The check works because dom0 is mapped 1:1, so
if the mfn is a valid pfn, then it means that it is a local page.


> Do you use this as a check for foreign pages? If yes, is the mfn for
> such pages guaranteed to be different from any valid dom0 pfn?

Yes and yes


> > +               {
> > +                       /* TODO: cache flush */
> 
> What does this TODO mean here? Which cases are not covered yet?

We are going to fill in the cache flush implementation for foreign pages
later, in patch 8/8.


> > +               } else {
> > +                       struct page *page = pfn_to_page(pfn);
> 
> If the pfn here is correct, can you not just have something like:
> 
> void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
> 		size_t size, enum dma_data_direction dir,
> 		struct dma_attrs *attrs)
> 
> {
> 	unsigned long pfn = handle >> PAGE_SHIFT;	/* could use some macros */
> 	if (!pfn_valid(pfn)) {
> 		/* FIXME */
> 		return;
> 	}
> 	__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
> }

Yes, this is possible. Then in patch 8/8 I could remove the FIXME and
add a call to a function that issues the new GNTTABOP_cache_flush
hypercall. It would also remove the asymmetry you mentioned before
because we could do the same for map_page.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 15:36:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 15:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmlaB-0007dh-VX; Fri, 07 Nov 2014 15:36:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmlaB-0007dc-F1
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 15:36:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6D/23-09936-EE6EC545; Fri, 07 Nov 2014 15:36:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415374570!12287080!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8414 invoked from network); 7 Nov 2014 15:36:13 -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;
	7 Nov 2014 15:36:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="190596674"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 10:36:07 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmlSx-0006A1-Py;
	Fri, 07 Nov 2014 15:28:47 +0000
Date: Fri, 7 Nov 2014 15:28:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107142205.GD29148@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411071523170.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141107142205.GD29148@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 6/8] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> On Mon, Oct 27, 2014 at 03:09:26PM +0000, Stefano Stabellini wrote:
> > Merge xen/mm32.c into xen/mm.c.
> > As a consequence the code gets compiled on arm64 too: introduce a few
> > compat functions to actually be able to compile it.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Since I missed the commit introducing mm32.c (340720be32d4 xen/arm:
> reimplement xen_dma_unmap_page & friends), I'll add a retrospective NAK ;).
> 
> The main reason is the asymmetry between dma map and unmap. With host
> swiotlb somehow getting !dma_capable(dev), you even risk leaking dom0
> swiotlb bounce buffers (on arm64).
> 
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> [...]
> > +/* functions called by SWIOTLB */
> > +
> > +static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
> > +       size_t size, enum dma_data_direction dir,
> > +       void (*op)(const void *, size_t, int))
> > +{
> > +       unsigned long pfn;
> > +       size_t left = size;
> > +
> > +       pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
> > +       offset %= PAGE_SIZE;
> > +
> > +       do {
> > +               size_t len = left;
> > +               void *vaddr;
> > +
> > +               if (!pfn_valid(pfn))
> 
> Is this the pfn or the mfn? As you said in the previous email, there is
> no mfn_to_pfn() conversion, so that's actually in another address space
> where dom0 pfn_valid() would not make sense.

That is actually the mfn. The check works because dom0 is mapped 1:1, so
if the mfn is a valid pfn, then it means that it is a local page.


> Do you use this as a check for foreign pages? If yes, is the mfn for
> such pages guaranteed to be different from any valid dom0 pfn?

Yes and yes


> > +               {
> > +                       /* TODO: cache flush */
> 
> What does this TODO mean here? Which cases are not covered yet?

We are going to fill in the cache flush implementation for foreign pages
later, in patch 8/8.


> > +               } else {
> > +                       struct page *page = pfn_to_page(pfn);
> 
> If the pfn here is correct, can you not just have something like:
> 
> void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
> 		size_t size, enum dma_data_direction dir,
> 		struct dma_attrs *attrs)
> 
> {
> 	unsigned long pfn = handle >> PAGE_SHIFT;	/* could use some macros */
> 	if (!pfn_valid(pfn)) {
> 		/* FIXME */
> 		return;
> 	}
> 	__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
> }

Yes, this is possible. Then in patch 8/8 I could remove the FIXME and
add a call to a function that issues the new GNTTABOP_cache_flush
hypercall. It would also remove the asymmetry you mentioned before
because we could do the same for map_page.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 15:36:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 15: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 1Xmlai-0007gi-Ii; Fri, 07 Nov 2014 15:36:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xmlag-0007gJ-NY
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 15:36:46 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	7E/5A-25714-E07EC545; Fri, 07 Nov 2014 15:36:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415374600!11169159!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16963 invoked from network); 7 Nov 2014 15:36:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 15:36:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="189168691"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 10:36:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmlLS-00063k-2g;
	Fri, 07 Nov 2014 15:21:02 +0000
Date: Fri, 7 Nov 2014 15:20:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: =?UTF-8?Q?Vladimir_'=CF=86-coder=2Fphcoder'_Serbinenko?=
	<phcoder@gmail.com>
In-Reply-To: <52B434AC.7090905@gmail.com>
Message-ID: <alpine.DEB.2.02.1411071518280.22875@kaball.uk.xensource.com>
References: <527EA084.6000706@gmail.com> <52987A43.9070806@m2r.biz>
	<52987D7F.3050006@gmail.com> <52988F86.6050008@m2r.biz>
	<529DB2F1.4080509@m2r.biz> <529DB363.7080003@gmail.com>
	<529DBED9.80105@m2r.biz> <529DC07E.8000201@gmail.com>
	<529DE3FD.90002@m2r.biz>
	<529DF9D5.2060301@gmail.com> <529E03FB.90603@m2r.biz>
	<52A1B0CB.3000705@m2r.biz> <52A1B5E8.5090709@gmail.com>
	<52A1E2CD.9030002@m2r.biz> <52A1E56E.3070105@gmail.com>
	<52A1EBAB.5090006@m2r.biz> <52A2F341.9010606@gmail.com>
	<52A5961A.2010608@m2r.biz>
	<52B02B13.1000103@m2r.biz> <52B02F84.6070403@gmail.com>
	<52B04D6E.3070700@m2r.biz> <52B0527C.40104@gmail.com>
	<52B057BD.8070701@m2r.biz> <52B05AF1.1040508@gmail.com>
	<52B05B5C.1080901@m2r.biz> <52B06131.8040809@m2r.biz>
	<52B1B82D.9050501@gmail.com>
	<alpine.DEB.2.02.1312181936470.8667@kaball.uk.xensource.com>
	<52B20392.9090001@gmail.com>
	<alpine.DEB.2.02.1312191125450.8667@kaball.uk.xensource.com>
	<52B434AC.7090905@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-475817987-1415373653=:22875"
X-DLP: MIA1
Cc: The development of GRUB 2 <grub-devel@gnu.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] pvgrub2 is merged
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-475817987-1415373653=:22875
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hello Vladimir,
sorry to resurrect an old thread and to top-post, but I noticed that in
upstream grub the xenfb driver has been reverted. Is that because of
this bug?  If so, you should know that the bug has been fixed in QEMU.

Thanks,

Stefano

On Fri, 20 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote:
> On 19.12.2013 12:54, Stefano Stabellini wrote:
> > On Wed, 18 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote:
> >> On 18.12.2013 20:39, Stefano Stabellini wrote:
> >>> On Wed, 18 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote=
:
> >>>> On 17.12.2013 15:35, Fabio Fantoni wrote:
> >>>>> Il 17/12/2013 15:10, Fabio Fantoni ha scritto:
> >>>>>> Il 17/12/2013 15:08, Vladimir '=CF=86-coder/phcoder' Serbinenko ha=
 scritto:
> >>>>>>>> Thanks.
> >>>>>>>> Now there is another error, probably introduced by xenfb support=
:
> >>>>>>>>
> >>>>>>> doesn't look like related to xenfb. Is it 64-bit or PAE guest?
> >>>>>>
> >>>>>> 64 bit
> >>>>>
> >>>>> I did "git reset --hard" to commit "Remove grub_bios_interrupt on
> >>>>> coreboot." and then I applied only
> >>>>> "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation.=
"
> >>>>> commit.
> >>>>> Now the Sid domU boot correctly, therefore the regression is caused=
 by
> >>>>> "xenfb" or "xen grants to v1" commit, should I find the exact commi=
t
> >>>>> that causes that problem or these informations are enough for you?
> >>>>
> >>>> It's because of vfb. Apparently vfb framebuffer stays mapped as rw e=
ven
> >>>> after vfb shutdown
> >>>> phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls
> >>>> /local/domain/54/device/vfb
> >>>> 0 =3D ""
> >>>>  backend =3D "/local/domain/0/backend/vfb/54/0"
> >>>>  backend-id =3D "0"
> >>>>  state =3D "1"
> >>>> phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls
> >>>> /local/domain/0/backend/vfb/54/0
> >>>> frontend =3D "/local/domain/54/device/vfb/0"
> >>>> frontend-id =3D "54"
> >>>> online =3D "1"
> >>>> state =3D "2"
> >>>> domain =3D "grub"
> >>>> vnc =3D "1"
> >>>> vnclisten =3D "127.0.0.1"
> >>>> vncdisplay =3D "0"
> >>>> vncunused =3D "1"
> >>>> sdl =3D "0"
> >>>> opengl =3D "0"
> >>>> feature-resize =3D "1"
> >>>> hotplug-status =3D "connected"
> >>>>
> >>>> When I do "dry vfb": do everything except writing vfb state problem
> >>>> disappears. So my question would be:
> >>>> - how can I inspect how backend maps framebuffer pages?
> >>>
> >>> There is only one xenfb backend: hw/display/xenfb.c in the QEMU sourc=
e
> >>> tree.
> >>>
> >>>
> >>>> - Why does it map as rw and not ro? It doesn't need to write to fram=
ebuffer?
> >>>
> >>> Actually it is mapping it RO, see hw/display/xenfb.c:xenfb_map_fb
> >>>
> >> ./tools/qemu-xen-dir-remote/hw/xenfb.c:
> >>     xenfb->pixels =3D xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom=
,
> >> =09=09=09=09=09 PROT_READ | PROT_WRITE, fbmfns, xenfb->fbpages);
> >=20
> > You are right, my bad.
> > I did a quick test and it should be safe to modify it to PROT_READ only=
=2E
> >=20
> >=20
> >>>> - How do I force it to drop the mapping?
> >>>
> >>> Theoretically QEMU should drop the mapping at disconnect time:
> >>>
> >>> hw/display/xenfb.c:fb_disconnect
> >>>
> >>>     /*
> >>>      * FIXME: qemu can't un-init gfx display (yet?).
> >>>      *   Replacing the framebuffer with anonymous shared memory
> >>>      *   instead.  This releases the guest pages and keeps qemu happy=
=2E
> >>>      */
> >>>     fb->pixels =3D mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE,
> >>>                       PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON,
> >>>                       -1, 0);
> >>>
> >> Could this fail?
> >=20
> > Yes and we don't check for the return value (-1 in case of error). Well=
 spotted!
> > Do you want to submit a patch to fix both issues or should I do it?
> >=20
> I'm fine with you doing it.
>=20
>=20
--1342847746-475817987-1415373653=:22875
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-475817987-1415373653=:22875--


From xen-devel-bounces@lists.xen.org Fri Nov 07 15:36:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 15: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 1Xmlai-0007gi-Ii; Fri, 07 Nov 2014 15:36:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xmlag-0007gJ-NY
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 15:36:46 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	7E/5A-25714-E07EC545; Fri, 07 Nov 2014 15:36:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415374600!11169159!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16963 invoked from network); 7 Nov 2014 15:36:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 15:36:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="189168691"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 10:36:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmlLS-00063k-2g;
	Fri, 07 Nov 2014 15:21:02 +0000
Date: Fri, 7 Nov 2014 15:20:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: =?UTF-8?Q?Vladimir_'=CF=86-coder=2Fphcoder'_Serbinenko?=
	<phcoder@gmail.com>
In-Reply-To: <52B434AC.7090905@gmail.com>
Message-ID: <alpine.DEB.2.02.1411071518280.22875@kaball.uk.xensource.com>
References: <527EA084.6000706@gmail.com> <52987A43.9070806@m2r.biz>
	<52987D7F.3050006@gmail.com> <52988F86.6050008@m2r.biz>
	<529DB2F1.4080509@m2r.biz> <529DB363.7080003@gmail.com>
	<529DBED9.80105@m2r.biz> <529DC07E.8000201@gmail.com>
	<529DE3FD.90002@m2r.biz>
	<529DF9D5.2060301@gmail.com> <529E03FB.90603@m2r.biz>
	<52A1B0CB.3000705@m2r.biz> <52A1B5E8.5090709@gmail.com>
	<52A1E2CD.9030002@m2r.biz> <52A1E56E.3070105@gmail.com>
	<52A1EBAB.5090006@m2r.biz> <52A2F341.9010606@gmail.com>
	<52A5961A.2010608@m2r.biz>
	<52B02B13.1000103@m2r.biz> <52B02F84.6070403@gmail.com>
	<52B04D6E.3070700@m2r.biz> <52B0527C.40104@gmail.com>
	<52B057BD.8070701@m2r.biz> <52B05AF1.1040508@gmail.com>
	<52B05B5C.1080901@m2r.biz> <52B06131.8040809@m2r.biz>
	<52B1B82D.9050501@gmail.com>
	<alpine.DEB.2.02.1312181936470.8667@kaball.uk.xensource.com>
	<52B20392.9090001@gmail.com>
	<alpine.DEB.2.02.1312191125450.8667@kaball.uk.xensource.com>
	<52B434AC.7090905@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-475817987-1415373653=:22875"
X-DLP: MIA1
Cc: The development of GRUB 2 <grub-devel@gnu.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] pvgrub2 is merged
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-475817987-1415373653=:22875
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hello Vladimir,
sorry to resurrect an old thread and to top-post, but I noticed that in
upstream grub the xenfb driver has been reverted. Is that because of
this bug?  If so, you should know that the bug has been fixed in QEMU.

Thanks,

Stefano

On Fri, 20 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote:
> On 19.12.2013 12:54, Stefano Stabellini wrote:
> > On Wed, 18 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote:
> >> On 18.12.2013 20:39, Stefano Stabellini wrote:
> >>> On Wed, 18 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote=
:
> >>>> On 17.12.2013 15:35, Fabio Fantoni wrote:
> >>>>> Il 17/12/2013 15:10, Fabio Fantoni ha scritto:
> >>>>>> Il 17/12/2013 15:08, Vladimir '=CF=86-coder/phcoder' Serbinenko ha=
 scritto:
> >>>>>>>> Thanks.
> >>>>>>>> Now there is another error, probably introduced by xenfb support=
:
> >>>>>>>>
> >>>>>>> doesn't look like related to xenfb. Is it 64-bit or PAE guest?
> >>>>>>
> >>>>>> 64 bit
> >>>>>
> >>>>> I did "git reset --hard" to commit "Remove grub_bios_interrupt on
> >>>>> coreboot." and then I applied only
> >>>>> "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation.=
"
> >>>>> commit.
> >>>>> Now the Sid domU boot correctly, therefore the regression is caused=
 by
> >>>>> "xenfb" or "xen grants to v1" commit, should I find the exact commi=
t
> >>>>> that causes that problem or these informations are enough for you?
> >>>>
> >>>> It's because of vfb. Apparently vfb framebuffer stays mapped as rw e=
ven
> >>>> after vfb shutdown
> >>>> phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls
> >>>> /local/domain/54/device/vfb
> >>>> 0 =3D ""
> >>>>  backend =3D "/local/domain/0/backend/vfb/54/0"
> >>>>  backend-id =3D "0"
> >>>>  state =3D "1"
> >>>> phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls
> >>>> /local/domain/0/backend/vfb/54/0
> >>>> frontend =3D "/local/domain/54/device/vfb/0"
> >>>> frontend-id =3D "54"
> >>>> online =3D "1"
> >>>> state =3D "2"
> >>>> domain =3D "grub"
> >>>> vnc =3D "1"
> >>>> vnclisten =3D "127.0.0.1"
> >>>> vncdisplay =3D "0"
> >>>> vncunused =3D "1"
> >>>> sdl =3D "0"
> >>>> opengl =3D "0"
> >>>> feature-resize =3D "1"
> >>>> hotplug-status =3D "connected"
> >>>>
> >>>> When I do "dry vfb": do everything except writing vfb state problem
> >>>> disappears. So my question would be:
> >>>> - how can I inspect how backend maps framebuffer pages?
> >>>
> >>> There is only one xenfb backend: hw/display/xenfb.c in the QEMU sourc=
e
> >>> tree.
> >>>
> >>>
> >>>> - Why does it map as rw and not ro? It doesn't need to write to fram=
ebuffer?
> >>>
> >>> Actually it is mapping it RO, see hw/display/xenfb.c:xenfb_map_fb
> >>>
> >> ./tools/qemu-xen-dir-remote/hw/xenfb.c:
> >>     xenfb->pixels =3D xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom=
,
> >> =09=09=09=09=09 PROT_READ | PROT_WRITE, fbmfns, xenfb->fbpages);
> >=20
> > You are right, my bad.
> > I did a quick test and it should be safe to modify it to PROT_READ only=
=2E
> >=20
> >=20
> >>>> - How do I force it to drop the mapping?
> >>>
> >>> Theoretically QEMU should drop the mapping at disconnect time:
> >>>
> >>> hw/display/xenfb.c:fb_disconnect
> >>>
> >>>     /*
> >>>      * FIXME: qemu can't un-init gfx display (yet?).
> >>>      *   Replacing the framebuffer with anonymous shared memory
> >>>      *   instead.  This releases the guest pages and keeps qemu happy=
=2E
> >>>      */
> >>>     fb->pixels =3D mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE,
> >>>                       PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON,
> >>>                       -1, 0);
> >>>
> >> Could this fail?
> >=20
> > Yes and we don't check for the return value (-1 in case of error). Well=
 spotted!
> > Do you want to submit a patch to fix both issues or should I do it?
> >=20
> I'm fine with you doing it.
>=20
>=20
--1342847746-475817987-1415373653=:22875
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-475817987-1415373653=:22875--


From xen-devel-bounces@lists.xen.org Fri Nov 07 15:42:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 15:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmlfX-0007x5-A2; Fri, 07 Nov 2014 15:41:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XmlfV-0007wt-Tw
	for Xen-devel@lists.xen.org; Fri, 07 Nov 2014 15:41:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	79/66-09842-938EC545; Fri, 07 Nov 2014 15:41:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415374901!12290511!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25433 invoked from network); 7 Nov 2014 15:41:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 15:41:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="189170533"
Message-ID: <545CE831.7070409@citrix.com>
Date: Fri, 7 Nov 2014 15:41:37 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>
References: <544547F3.4000506@citrix.com>
	<20141023094619.GA89807@deinos.phlegethon.org>
In-Reply-To: <20141023094619.GA89807@deinos.phlegethon.org>
Content-Length: 3967
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Possible Xen grant table locking improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/14 10:46, Tim Deegan wrote:
> Hi,
> =

> At 18:35 +0100 on 20 Oct (1413826547), David Vrabel wrote:
>> Most guests do not map a grant reference more than twice (Linux, for
>> example, will typically map a gref once in the kernel address space, or
>> twice if a userspace mapping is required).  The maptrack entries for
>> these two mappings can be stored in the active entry (the "fast"
>> entries).  If more than two mappings are required, the existing maptrack
>> table can be used (the "slow" entries).
> =

> Sounds good, as long as the hit rate is indeed high.  Do you know if
> the BSD/windows client code behaves this way too?

I don't know about BSD but XenServer's Windows PV drivers don't support
mapping grants (only granting access).

>> A maptrack handle for a "fast" entry is encoded as:
>>
>>     31 30          16  15            0
>>   +---+---------------+---------------+
>>   | F | domid         | gref          |
>>   +---+---------------+---------------+
>>
>> F is set for a "fast" entry, and clear for a "slow" one. Grant
>> references above 2^16 will have to be tracked with "slow" entries.
> =

> How restricting is that limit?  Would 2^15=BD and also encoding
> which of the two entries to look at be good?

Oh,  I forgot about the bit for the entry index.

2^15 entries allows for (e.g.,) 8 multiqueue VIFs in a 8 VCPU guest.
Which is not a huge number and not a limit I would like to introduce.

One possibility would be guests wanting to use the fast path have to use
a new grant unmap hypercall that also passes the original grant ref and
domain.

>> We can omit taking the grant table lock to check the validity of a grant
>> ref or maptrack handle since these tables only grow and do not shrink.
> =

> Can you also avoid the lock for accessing the entry itself, with a bit
> of RCU magic?  Maybe that's overengineering things.

I don't think this will be necessary -- the active entry lock won't be
contended.

>> If strict IOMMU mode is used, IOMMU mappings are updated on every grant
>> map/unmap.  These are currently setup such that BFN =3D=3D MFN which
>> requires reference counting the IOMMU mappings so they are only torn
>> down when all grefs for that MFN are unmapped.  This requires an
>> expensive mapcount() operation that iterates over the whole maptrack tab=
le.
>>
>> There is no requirement for BFN =3D=3D MFN so each grant map can create =
its
>> own IOMMU mapping.  This will require a region of bus address space that
>> does not overlap with RAM.
> =

> Hrmn.  That could be tricky to arrange.  And the reference counting
> might end up being cheaper than the extra IOMMU flush operations.
> (Also, how much would you bet that clients actually use the returned
> BFN correctly?)

Hmm. Yes, if a guest has assumed that BFN =3D=3D MFN, it could read the PTE
and get the BFN that way.

> Would it be enough to optimise mapcount() a bit?  We could organise the
> in-use maptrack entries as a hash table instead of (or as well as) a
> single linked list.
> =

> On similar lines, would it be worth fragmenting the maptrack itself
> (e.g. with per-page locks) to reduce locking contention instead of
> moving maptrack entries into the active entry?  If might be Good
> Enough[tm], and simpler to build/maintain than this proposal.

A per maptrack page lock you would still need a per-domain maptrack lock
protecting the maptrack free list.

A better idea may be to hash the domain and grant ref and have a
maptrack table per-hash bucket.  Each maptrack table would have its own
maptrack lock.

The maptrack handle could be:

    31               16  15            0
    +-------------------+---------------+
    | bucket            | index         |
    +-------------------+---------------+

We should probably try something simpler like this before getting
carried away...

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 15:42:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 15:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmlfX-0007x5-A2; Fri, 07 Nov 2014 15:41:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XmlfV-0007wt-Tw
	for Xen-devel@lists.xen.org; Fri, 07 Nov 2014 15:41:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	79/66-09842-938EC545; Fri, 07 Nov 2014 15:41:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415374901!12290511!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25433 invoked from network); 7 Nov 2014 15:41:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 15:41:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="189170533"
Message-ID: <545CE831.7070409@citrix.com>
Date: Fri, 7 Nov 2014 15:41:37 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>
References: <544547F3.4000506@citrix.com>
	<20141023094619.GA89807@deinos.phlegethon.org>
In-Reply-To: <20141023094619.GA89807@deinos.phlegethon.org>
Content-Length: 3967
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Possible Xen grant table locking improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/14 10:46, Tim Deegan wrote:
> Hi,
> =

> At 18:35 +0100 on 20 Oct (1413826547), David Vrabel wrote:
>> Most guests do not map a grant reference more than twice (Linux, for
>> example, will typically map a gref once in the kernel address space, or
>> twice if a userspace mapping is required).  The maptrack entries for
>> these two mappings can be stored in the active entry (the "fast"
>> entries).  If more than two mappings are required, the existing maptrack
>> table can be used (the "slow" entries).
> =

> Sounds good, as long as the hit rate is indeed high.  Do you know if
> the BSD/windows client code behaves this way too?

I don't know about BSD but XenServer's Windows PV drivers don't support
mapping grants (only granting access).

>> A maptrack handle for a "fast" entry is encoded as:
>>
>>     31 30          16  15            0
>>   +---+---------------+---------------+
>>   | F | domid         | gref          |
>>   +---+---------------+---------------+
>>
>> F is set for a "fast" entry, and clear for a "slow" one. Grant
>> references above 2^16 will have to be tracked with "slow" entries.
> =

> How restricting is that limit?  Would 2^15=BD and also encoding
> which of the two entries to look at be good?

Oh,  I forgot about the bit for the entry index.

2^15 entries allows for (e.g.,) 8 multiqueue VIFs in a 8 VCPU guest.
Which is not a huge number and not a limit I would like to introduce.

One possibility would be guests wanting to use the fast path have to use
a new grant unmap hypercall that also passes the original grant ref and
domain.

>> We can omit taking the grant table lock to check the validity of a grant
>> ref or maptrack handle since these tables only grow and do not shrink.
> =

> Can you also avoid the lock for accessing the entry itself, with a bit
> of RCU magic?  Maybe that's overengineering things.

I don't think this will be necessary -- the active entry lock won't be
contended.

>> If strict IOMMU mode is used, IOMMU mappings are updated on every grant
>> map/unmap.  These are currently setup such that BFN =3D=3D MFN which
>> requires reference counting the IOMMU mappings so they are only torn
>> down when all grefs for that MFN are unmapped.  This requires an
>> expensive mapcount() operation that iterates over the whole maptrack tab=
le.
>>
>> There is no requirement for BFN =3D=3D MFN so each grant map can create =
its
>> own IOMMU mapping.  This will require a region of bus address space that
>> does not overlap with RAM.
> =

> Hrmn.  That could be tricky to arrange.  And the reference counting
> might end up being cheaper than the extra IOMMU flush operations.
> (Also, how much would you bet that clients actually use the returned
> BFN correctly?)

Hmm. Yes, if a guest has assumed that BFN =3D=3D MFN, it could read the PTE
and get the BFN that way.

> Would it be enough to optimise mapcount() a bit?  We could organise the
> in-use maptrack entries as a hash table instead of (or as well as) a
> single linked list.
> =

> On similar lines, would it be worth fragmenting the maptrack itself
> (e.g. with per-page locks) to reduce locking contention instead of
> moving maptrack entries into the active entry?  If might be Good
> Enough[tm], and simpler to build/maintain than this proposal.

A per maptrack page lock you would still need a per-domain maptrack lock
protecting the maptrack free list.

A better idea may be to hash the domain and grant ref and have a
maptrack table per-hash bucket.  Each maptrack table would have its own
maptrack lock.

The maptrack handle could be:

    31               16  15            0
    +-------------------+---------------+
    | bucket            | index         |
    +-------------------+---------------+

We should probably try something simpler like this before getting
carried away...

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 16:00:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 16:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmlxT-0008SR-9L; Fri, 07 Nov 2014 16:00:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmlxS-0008SM-AQ
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 16:00:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C8/29-09936-19CEC545; Fri, 07 Nov 2014 16:00:17 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415376016!12276251!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22245 invoked from network); 7 Nov 2014 16:00:16 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-7.tower-21.messagelabs.com with SMTP;
	7 Nov 2014 16:00:16 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id CC15A1AA;
	Fri,  7 Nov 2014 10:00:12 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 4B08B5FAD7;
	Fri,  7 Nov 2014 10:00:10 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id CF89813F78C;
	Fri,  7 Nov 2014 10:00:08 -0600 (CST)
Date: Fri, 7 Nov 2014 16:00:06 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107160006.GE29148@e104818-lin.cambridge.arm.com>
References: <1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(talking to Ian in person helped a bit ;))

On Fri, Nov 07, 2014 at 02:10:25PM +0000, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > On Thu, Nov 06, 2014 at 12:22:13PM +0000, Stefano Stabellini wrote:
> > > On Thu, 6 Nov 2014, Catalin Marinas wrote:
> > > > On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> > > > > On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > > > > > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > > > > > standard cache maintenance would be enough (but that's a Xen problem,
> > > > > > not sure how to solve).
> > > > > 
> > > > > It is a thorny issue indeed.
> > > > > Xen would need to know how to do non-standard cache maintenance
> > > > > operations.
> > > > 
> > > > Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
> > > > just use the currently registered dma ops.
> > > 
> > > It is Xen, so El2 hypervisor.
> > 
> > So what is arch/arm/xen/mm32.c cache maintenance for? Doesn't it run in
> > dom0?
> 
> This patch series changes that code path specifically. As a matter of
> fact it removes mm32.c.

Well, it actually merges it into another file, dma_cache_maint() still
remains.

> Before this patch series, cache maintenance in dom0 was being done with
> XENFEAT_grant_map_identity (see explanation in previous email).
> After this patch series, an hypercall is made when foreign pages are
> involved, see patch 8/8, the if(!pfn_valid(pfn)) code path. Local pages
> are still flushed in dom0.

OK. One question I had though is whether pfn_valid(mfn) is always false for
foreign pages. IIUC, dom0 uses a 1:1 pfn:mfn mapping, so it would work.
But from what I gather, there can be other guest, not necessarily dom0,
handling the DMA in which case, if it doesn't use a 1:1 pfn:mfn mapping,
your pfn_valid(mfn) check would no longer work for foreign pages.

> > > Fortunately these dma_ops don't actually need to do much. In fact they
> > > only need to flush caches if the device is not dma-coherent. So the
> > > current proposed solution is to issue an hypercall to ask Xen to do the
> > > flushing, passing the physical address dom0 knows.
> > 
> > I really don't like the dma_cache_maint() duplication you added in
> > arch/arm/xen/mm32.c just because you cannot call the host dma_ops when
> > the page is not available.
> 
> I agree is bad, but this patch series is a big step forward removing the
> duplication. In fact now that I think about it, when a page is local (not a
> foreign page) I could just call the host dma_ops. mm.c:dma_cache_maint
> would only be used for foreign pages (pages for which !pfn_valid(pfn)).

Indeed. I already replied to patch 6/8. This way I think you can remove
dma_cache_maint() duplication entirely, just add one specific to foreign
pages.

What I would like to see is xen_dma_map_page() also using hyp calls for
cache maintenance when !pfn_valid(), for symmetry with unmap. You would
need another argument to xen_dma_map_page() though to pass the real
device address or mfn (and on the map side you could simply check for
page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
bouncing so you don't need dom0 swiotlb involved as well.

> > You basically only need a VA that was mapped in dom0 when map_page() was
> > called and is still mapped when page_unmap() is called. You can free the
> > actual mapping after calling __generic_dma_ops()->unmap_page() in
> > xen_dma_unmap_page() (in xen_unmap_single()).
> 
> That is true, but where would I store the mapping?

dev_archdata ;).

> I don't want to introduce another data structure to keep physical to va
> or physical to struct page mappings that I need to modify at every
> map_page and unmap_page. It wouldn't even be a trivial data structure as
> multiple dma operations involving the same mfn but different struct page
> can happen simultaneously.
> 
> The performance hit of maintaining such a data structure would be
> significant.

There would indeed be a performance hit especially for sg ops.

> It would negatively impact any dma operations involving any devices,
> including dma coherent ones. While this series only requires special
> handling of dma operations involving non-coherent devices (resulting in
> an hypercall being made).
> 
> In a way this series rewards hardware that makes life easier to software
> developers :-)

I only need the pfn_valid() clarification now together with the
map/unmap symmetry fix.

I think for the time being is_device_dma_coherent() can stay as an
arch-only function as it is only used by Xen on arm/arm64. If we later
need this on other architectures, we can make it generic.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 16:00:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 16:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmlxT-0008SR-9L; Fri, 07 Nov 2014 16:00:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XmlxS-0008SM-AQ
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 16:00:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C8/29-09936-19CEC545; Fri, 07 Nov 2014 16:00:17 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415376016!12276251!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22245 invoked from network); 7 Nov 2014 16:00:16 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-7.tower-21.messagelabs.com with SMTP;
	7 Nov 2014 16:00:16 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id CC15A1AA;
	Fri,  7 Nov 2014 10:00:12 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 4B08B5FAD7;
	Fri,  7 Nov 2014 10:00:10 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id CF89813F78C;
	Fri,  7 Nov 2014 10:00:08 -0600 (CST)
Date: Fri, 7 Nov 2014 16:00:06 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107160006.GE29148@e104818-lin.cambridge.arm.com>
References: <1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(talking to Ian in person helped a bit ;))

On Fri, Nov 07, 2014 at 02:10:25PM +0000, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > On Thu, Nov 06, 2014 at 12:22:13PM +0000, Stefano Stabellini wrote:
> > > On Thu, 6 Nov 2014, Catalin Marinas wrote:
> > > > On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> > > > > On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > > > > > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > > > > > standard cache maintenance would be enough (but that's a Xen problem,
> > > > > > not sure how to solve).
> > > > > 
> > > > > It is a thorny issue indeed.
> > > > > Xen would need to know how to do non-standard cache maintenance
> > > > > operations.
> > > > 
> > > > Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
> > > > just use the currently registered dma ops.
> > > 
> > > It is Xen, so El2 hypervisor.
> > 
> > So what is arch/arm/xen/mm32.c cache maintenance for? Doesn't it run in
> > dom0?
> 
> This patch series changes that code path specifically. As a matter of
> fact it removes mm32.c.

Well, it actually merges it into another file, dma_cache_maint() still
remains.

> Before this patch series, cache maintenance in dom0 was being done with
> XENFEAT_grant_map_identity (see explanation in previous email).
> After this patch series, an hypercall is made when foreign pages are
> involved, see patch 8/8, the if(!pfn_valid(pfn)) code path. Local pages
> are still flushed in dom0.

OK. One question I had though is whether pfn_valid(mfn) is always false for
foreign pages. IIUC, dom0 uses a 1:1 pfn:mfn mapping, so it would work.
But from what I gather, there can be other guest, not necessarily dom0,
handling the DMA in which case, if it doesn't use a 1:1 pfn:mfn mapping,
your pfn_valid(mfn) check would no longer work for foreign pages.

> > > Fortunately these dma_ops don't actually need to do much. In fact they
> > > only need to flush caches if the device is not dma-coherent. So the
> > > current proposed solution is to issue an hypercall to ask Xen to do the
> > > flushing, passing the physical address dom0 knows.
> > 
> > I really don't like the dma_cache_maint() duplication you added in
> > arch/arm/xen/mm32.c just because you cannot call the host dma_ops when
> > the page is not available.
> 
> I agree is bad, but this patch series is a big step forward removing the
> duplication. In fact now that I think about it, when a page is local (not a
> foreign page) I could just call the host dma_ops. mm.c:dma_cache_maint
> would only be used for foreign pages (pages for which !pfn_valid(pfn)).

Indeed. I already replied to patch 6/8. This way I think you can remove
dma_cache_maint() duplication entirely, just add one specific to foreign
pages.

What I would like to see is xen_dma_map_page() also using hyp calls for
cache maintenance when !pfn_valid(), for symmetry with unmap. You would
need another argument to xen_dma_map_page() though to pass the real
device address or mfn (and on the map side you could simply check for
page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
bouncing so you don't need dom0 swiotlb involved as well.

> > You basically only need a VA that was mapped in dom0 when map_page() was
> > called and is still mapped when page_unmap() is called. You can free the
> > actual mapping after calling __generic_dma_ops()->unmap_page() in
> > xen_dma_unmap_page() (in xen_unmap_single()).
> 
> That is true, but where would I store the mapping?

dev_archdata ;).

> I don't want to introduce another data structure to keep physical to va
> or physical to struct page mappings that I need to modify at every
> map_page and unmap_page. It wouldn't even be a trivial data structure as
> multiple dma operations involving the same mfn but different struct page
> can happen simultaneously.
> 
> The performance hit of maintaining such a data structure would be
> significant.

There would indeed be a performance hit especially for sg ops.

> It would negatively impact any dma operations involving any devices,
> including dma coherent ones. While this series only requires special
> handling of dma operations involving non-coherent devices (resulting in
> an hypercall being made).
> 
> In a way this series rewards hardware that makes life easier to software
> developers :-)

I only need the pfn_valid() clarification now together with the
map/unmap symmetry fix.

I think for the time being is_device_dma_coherent() can stay as an
arch-only function as it is only used by Xen on arm/arm64. If we later
need this on other architectures, we can make it generic.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 16:03:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 16:03:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmm0O-0000Hm-LJ; Fri, 07 Nov 2014 16:03:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xmm0N-0000He-Cd
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 16:03:19 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	94/B4-29352-64DEC545; Fri, 07 Nov 2014 16:03:18 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415376197!5860791!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1721 invoked from network); 7 Nov 2014 16:03:17 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-10.tower-206.messagelabs.com with SMTP;
	7 Nov 2014 16:03:17 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 76C9A1AA;
	Fri,  7 Nov 2014 10:03:12 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 5EEDC5FAD7;
	Fri,  7 Nov 2014 10:03:10 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 0E1FF13F78C;
	Fri,  7 Nov 2014 10:03:08 -0600 (CST)
Date: Fri, 7 Nov 2014 16:03:06 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107160306.GF29148@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141107142205.GD29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071523170.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411071523170.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 6/8] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 03:28:38PM +0000, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > On Mon, Oct 27, 2014 at 03:09:26PM +0000, Stefano Stabellini wrote:
> > > Merge xen/mm32.c into xen/mm.c.
> > > As a consequence the code gets compiled on arm64 too: introduce a few
> > > compat functions to actually be able to compile it.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Since I missed the commit introducing mm32.c (340720be32d4 xen/arm:
> > reimplement xen_dma_unmap_page & friends), I'll add a retrospective NAK ;).
> > 
> > The main reason is the asymmetry between dma map and unmap. With host
> > swiotlb somehow getting !dma_capable(dev), you even risk leaking dom0
> > swiotlb bounce buffers (on arm64).
> > 
> > > --- a/arch/arm/xen/mm.c
> > > +++ b/arch/arm/xen/mm.c
> > [...]
> > > +/* functions called by SWIOTLB */
> > > +
> > > +static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
> > > +       size_t size, enum dma_data_direction dir,
> > > +       void (*op)(const void *, size_t, int))
> > > +{
> > > +       unsigned long pfn;
> > > +       size_t left = size;
> > > +
> > > +       pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
> > > +       offset %= PAGE_SIZE;
> > > +
> > > +       do {
> > > +               size_t len = left;
> > > +               void *vaddr;
> > > +
> > > +               if (!pfn_valid(pfn))
> > 
> > Is this the pfn or the mfn? As you said in the previous email, there is
> > no mfn_to_pfn() conversion, so that's actually in another address space
> > where dom0 pfn_valid() would not make sense.
> 
> That is actually the mfn. The check works because dom0 is mapped 1:1, so
> if the mfn is a valid pfn, then it means that it is a local page.

So the Xen DMA ops would never be called on anything other than dom0? If
that's correct, the pfn_valid() check would work. But add some big
comments as it's not clear at all to someone not familiar with Xen.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 16:03:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 16:03:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmm0O-0000Hm-LJ; Fri, 07 Nov 2014 16:03:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xmm0N-0000He-Cd
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 16:03:19 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	94/B4-29352-64DEC545; Fri, 07 Nov 2014 16:03:18 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415376197!5860791!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1721 invoked from network); 7 Nov 2014 16:03:17 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-10.tower-206.messagelabs.com with SMTP;
	7 Nov 2014 16:03:17 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 76C9A1AA;
	Fri,  7 Nov 2014 10:03:12 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 5EEDC5FAD7;
	Fri,  7 Nov 2014 10:03:10 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 0E1FF13F78C;
	Fri,  7 Nov 2014 10:03:08 -0600 (CST)
Date: Fri, 7 Nov 2014 16:03:06 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107160306.GF29148@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141107142205.GD29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071523170.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411071523170.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 6/8] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 03:28:38PM +0000, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > On Mon, Oct 27, 2014 at 03:09:26PM +0000, Stefano Stabellini wrote:
> > > Merge xen/mm32.c into xen/mm.c.
> > > As a consequence the code gets compiled on arm64 too: introduce a few
> > > compat functions to actually be able to compile it.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Since I missed the commit introducing mm32.c (340720be32d4 xen/arm:
> > reimplement xen_dma_unmap_page & friends), I'll add a retrospective NAK ;).
> > 
> > The main reason is the asymmetry between dma map and unmap. With host
> > swiotlb somehow getting !dma_capable(dev), you even risk leaking dom0
> > swiotlb bounce buffers (on arm64).
> > 
> > > --- a/arch/arm/xen/mm.c
> > > +++ b/arch/arm/xen/mm.c
> > [...]
> > > +/* functions called by SWIOTLB */
> > > +
> > > +static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
> > > +       size_t size, enum dma_data_direction dir,
> > > +       void (*op)(const void *, size_t, int))
> > > +{
> > > +       unsigned long pfn;
> > > +       size_t left = size;
> > > +
> > > +       pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
> > > +       offset %= PAGE_SIZE;
> > > +
> > > +       do {
> > > +               size_t len = left;
> > > +               void *vaddr;
> > > +
> > > +               if (!pfn_valid(pfn))
> > 
> > Is this the pfn or the mfn? As you said in the previous email, there is
> > no mfn_to_pfn() conversion, so that's actually in another address space
> > where dom0 pfn_valid() would not make sense.
> 
> That is actually the mfn. The check works because dom0 is mapped 1:1, so
> if the mfn is a valid pfn, then it means that it is a local page.

So the Xen DMA ops would never be called on anything other than dom0? If
that's correct, the pfn_valid() check would work. But add some big
comments as it's not clear at all to someone not familiar with Xen.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 16:35:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 16: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 1XmmUu-0000ch-Cy; Fri, 07 Nov 2014 16:34:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XmmUs-0000cc-I8
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 16:34:50 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	DD/29-22737-9A4FC545; Fri, 07 Nov 2014 16:34:49 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415378087!8280238!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4074 invoked from network); 7 Nov 2014 16:34:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Nov 2014 16:34:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7GYfOx005919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 16:34:42 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7GYe1j003279
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Nov 2014 16:34:41 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA7GYdxl009436; Fri, 7 Nov 2014 16:34:40 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 08:34:39 -0800
Message-ID: <545CF499.8080606@oracle.com>
Date: Fri, 07 Nov 2014 11:34:33 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
In-Reply-To: <20141107104752.GB28188@zion.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/07/2014 05:47 AM, Wei Liu wrote:
> On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
>> Hi,
>>
>> While doing VM migration, in the destination side:
>>
>>    # xl list -l
>>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
>>     [
>>         {
>>             "domid": 0,
>>             "config": {
>>                 "c_info": {
>>                     "type": "pv",
>>                     "name": "Domain-0"
>>                 },
>>                 "b_info": {
>>                     "max_memkb": 876544,
>>                     "target_memkb": 876543,
>>                     "sched_params": {
>>     
>>                     },
>>                     "type.pv": {
>>     
>>                     }
>>                 }
>>             }
>>         }
>>     ]
>>  
>>     # xl list
>>     Name                                          ID   Mem VCPUs      State   Time(s)
>>     Domain-0                                       0   856     4     r-----    2758.9
>>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
>>
>> Testing on:
>>
> 
> What's the rune you used to migrate the domain? xl migrate? Why is the
> domain paused?

The domain is under migrating, so the destination side it's paused. When migration finish,
it will become running.

FYI: the domain migration will success.

> What's inside /var/lib/xen?

# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0   856     4     r-----    1669.2
0004fb0000060000834f0ecf044b2219--incoming     3   700     0     --p---       0.0

# ls /var/lib/xen
qemu-resume.3  userdata-d.0.00000000-0000-0000-0000-000000000000.libxl-json  userdata-d.11.0004fb00-0006-0000-eadd-3c2eb729617a.libxl-json  xenpaging

It seems no userdata for this domain.

> What's the content of xenstore?

# xenstore-ls  -f
/local = ""
/local/domain = ""
/local/domain/0 = ""
/local/domain/0/domid = "0"
/local/domain/0/name = "Domain-0"
/local/domain/0/device-model = ""
/local/domain/0/device-model/0 = ""
/local/domain/0/device-model/0/state = "running"
/local/domain/0/memory = ""
/local/domain/0/memory/target = "876544"
/local/domain/0/memory/static-max = "876544"
/local/domain/0/memory/freemem-slack = "628980"
/local/domain/0/libxl = ""
/local/domain/0/libxl/disable_udev = "1"
/local/domain/3 = ""
/local/domain/3/vm = "/vm/0004fb00-0006-0000-834f-0ecf044b2219"
/local/domain/3/name = "0004fb0000060000834f0ecf044b2219--incoming"
/local/domain/3/cpu = ""
/local/domain/3/memory = ""
/local/domain/3/device = ""
/local/domain/3/device/suspend = ""
/local/domain/3/device/suspend/event-channel = ""
/local/domain/3/control = ""
/local/domain/3/control/shutdown = ""
/local/domain/3/control/platform-feature-multiprocessor-suspend = "1"
/local/domain/3/control/platform-feature-xs_reset_watches = "1"
/local/domain/3/data = ""
/vm = ""
/vm/0004fb00-0006-0000-834f-0ecf044b2219 = ""
/vm/0004fb00-0006-0000-834f-0ecf044b2219/uuid = "0004fb00-0006-0000-834f-0ecf044b2219"
/vm/0004fb00-0006-0000-834f-0ecf044b2219/name = "0004fb0000060000834f0ecf044b2219--incoming"
/libxl = ""
/libxl/3 = ""

Thanks,

Zhigang

> Wei.
> 
>>     commit 816f5bb1f0740be8355e1be6cc24edf09547d984
>>     Author: Ian Campbell <ian.campbell@citrix.com>
>>     Date:   Fri Oct 24 10:58:33 2014 +0100
>>
>> Thanks,
>>
>> Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 16:35:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 16: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 1XmmUu-0000ch-Cy; Fri, 07 Nov 2014 16:34:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XmmUs-0000cc-I8
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 16:34:50 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	DD/29-22737-9A4FC545; Fri, 07 Nov 2014 16:34:49 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415378087!8280238!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4074 invoked from network); 7 Nov 2014 16:34:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Nov 2014 16:34:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7GYfOx005919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 16:34:42 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7GYe1j003279
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Nov 2014 16:34:41 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA7GYdxl009436; Fri, 7 Nov 2014 16:34:40 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 08:34:39 -0800
Message-ID: <545CF499.8080606@oracle.com>
Date: Fri, 07 Nov 2014 11:34:33 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
In-Reply-To: <20141107104752.GB28188@zion.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/07/2014 05:47 AM, Wei Liu wrote:
> On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
>> Hi,
>>
>> While doing VM migration, in the destination side:
>>
>>    # xl list -l
>>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
>>     [
>>         {
>>             "domid": 0,
>>             "config": {
>>                 "c_info": {
>>                     "type": "pv",
>>                     "name": "Domain-0"
>>                 },
>>                 "b_info": {
>>                     "max_memkb": 876544,
>>                     "target_memkb": 876543,
>>                     "sched_params": {
>>     
>>                     },
>>                     "type.pv": {
>>     
>>                     }
>>                 }
>>             }
>>         }
>>     ]
>>  
>>     # xl list
>>     Name                                          ID   Mem VCPUs      State   Time(s)
>>     Domain-0                                       0   856     4     r-----    2758.9
>>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
>>
>> Testing on:
>>
> 
> What's the rune you used to migrate the domain? xl migrate? Why is the
> domain paused?

The domain is under migrating, so the destination side it's paused. When migration finish,
it will become running.

FYI: the domain migration will success.

> What's inside /var/lib/xen?

# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0   856     4     r-----    1669.2
0004fb0000060000834f0ecf044b2219--incoming     3   700     0     --p---       0.0

# ls /var/lib/xen
qemu-resume.3  userdata-d.0.00000000-0000-0000-0000-000000000000.libxl-json  userdata-d.11.0004fb00-0006-0000-eadd-3c2eb729617a.libxl-json  xenpaging

It seems no userdata for this domain.

> What's the content of xenstore?

# xenstore-ls  -f
/local = ""
/local/domain = ""
/local/domain/0 = ""
/local/domain/0/domid = "0"
/local/domain/0/name = "Domain-0"
/local/domain/0/device-model = ""
/local/domain/0/device-model/0 = ""
/local/domain/0/device-model/0/state = "running"
/local/domain/0/memory = ""
/local/domain/0/memory/target = "876544"
/local/domain/0/memory/static-max = "876544"
/local/domain/0/memory/freemem-slack = "628980"
/local/domain/0/libxl = ""
/local/domain/0/libxl/disable_udev = "1"
/local/domain/3 = ""
/local/domain/3/vm = "/vm/0004fb00-0006-0000-834f-0ecf044b2219"
/local/domain/3/name = "0004fb0000060000834f0ecf044b2219--incoming"
/local/domain/3/cpu = ""
/local/domain/3/memory = ""
/local/domain/3/device = ""
/local/domain/3/device/suspend = ""
/local/domain/3/device/suspend/event-channel = ""
/local/domain/3/control = ""
/local/domain/3/control/shutdown = ""
/local/domain/3/control/platform-feature-multiprocessor-suspend = "1"
/local/domain/3/control/platform-feature-xs_reset_watches = "1"
/local/domain/3/data = ""
/vm = ""
/vm/0004fb00-0006-0000-834f-0ecf044b2219 = ""
/vm/0004fb00-0006-0000-834f-0ecf044b2219/uuid = "0004fb00-0006-0000-834f-0ecf044b2219"
/vm/0004fb00-0006-0000-834f-0ecf044b2219/name = "0004fb0000060000834f0ecf044b2219--incoming"
/libxl = ""
/libxl/3 = ""

Thanks,

Zhigang

> Wei.
> 
>>     commit 816f5bb1f0740be8355e1be6cc24edf09547d984
>>     Author: Ian Campbell <ian.campbell@citrix.com>
>>     Date:   Fri Oct 24 10:58:33 2014 +0100
>>
>> Thanks,
>>
>> Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 16:48:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 16:48:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmmi7-0000sY-6E; Fri, 07 Nov 2014 16:48:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xmmi6-0000sT-Cf
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 16:48:30 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	C5/A7-02576-DD7FC545; Fri, 07 Nov 2014 16:48:29 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415378905!12112250!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9932 invoked from network); 7 Nov 2014 16:48:28 -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;
	7 Nov 2014 16:48:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="189206495"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 11:46:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xmmg3-0007iP-8Z;
	Fri, 07 Nov 2014 16:46:23 +0000
Date: Fri, 7 Nov 2014 16:46:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107160306.GF29148@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411071645480.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141107142205.GD29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071523170.22875@kaball.uk.xensource.com>
	<20141107160306.GF29148@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 6/8] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> On Fri, Nov 07, 2014 at 03:28:38PM +0000, Stefano Stabellini wrote:
> > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > On Mon, Oct 27, 2014 at 03:09:26PM +0000, Stefano Stabellini wrote:
> > > > Merge xen/mm32.c into xen/mm.c.
> > > > As a consequence the code gets compiled on arm64 too: introduce a few
> > > > compat functions to actually be able to compile it.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > Since I missed the commit introducing mm32.c (340720be32d4 xen/arm:
> > > reimplement xen_dma_unmap_page & friends), I'll add a retrospective NAK ;).
> > > 
> > > The main reason is the asymmetry between dma map and unmap. With host
> > > swiotlb somehow getting !dma_capable(dev), you even risk leaking dom0
> > > swiotlb bounce buffers (on arm64).
> > > 
> > > > --- a/arch/arm/xen/mm.c
> > > > +++ b/arch/arm/xen/mm.c
> > > [...]
> > > > +/* functions called by SWIOTLB */
> > > > +
> > > > +static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
> > > > +       size_t size, enum dma_data_direction dir,
> > > > +       void (*op)(const void *, size_t, int))
> > > > +{
> > > > +       unsigned long pfn;
> > > > +       size_t left = size;
> > > > +
> > > > +       pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
> > > > +       offset %= PAGE_SIZE;
> > > > +
> > > > +       do {
> > > > +               size_t len = left;
> > > > +               void *vaddr;
> > > > +
> > > > +               if (!pfn_valid(pfn))
> > > 
> > > Is this the pfn or the mfn? As you said in the previous email, there is
> > > no mfn_to_pfn() conversion, so that's actually in another address space
> > > where dom0 pfn_valid() would not make sense.
> > 
> > That is actually the mfn. The check works because dom0 is mapped 1:1, so
> > if the mfn is a valid pfn, then it means that it is a local page.
> 
> So the Xen DMA ops would never be called on anything other than dom0?

That's right.


> If that's correct, the pfn_valid() check would work. But add some big
> comments as it's not clear at all to someone not familiar with Xen.

Yeah...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 16:48:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 16:48:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmmi7-0000sY-6E; Fri, 07 Nov 2014 16:48:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xmmi6-0000sT-Cf
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 16:48:30 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	C5/A7-02576-DD7FC545; Fri, 07 Nov 2014 16:48:29 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415378905!12112250!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9932 invoked from network); 7 Nov 2014 16:48:28 -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;
	7 Nov 2014 16:48:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="189206495"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 11:46:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xmmg3-0007iP-8Z;
	Fri, 07 Nov 2014 16:46:23 +0000
Date: Fri, 7 Nov 2014 16:46:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107160306.GF29148@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411071645480.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1410261621200.22875@kaball.uk.xensource.com>
	<1414422568-19103-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141107142205.GD29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071523170.22875@kaball.uk.xensource.com>
	<20141107160306.GF29148@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 6/8] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> On Fri, Nov 07, 2014 at 03:28:38PM +0000, Stefano Stabellini wrote:
> > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > On Mon, Oct 27, 2014 at 03:09:26PM +0000, Stefano Stabellini wrote:
> > > > Merge xen/mm32.c into xen/mm.c.
> > > > As a consequence the code gets compiled on arm64 too: introduce a few
> > > > compat functions to actually be able to compile it.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > Since I missed the commit introducing mm32.c (340720be32d4 xen/arm:
> > > reimplement xen_dma_unmap_page & friends), I'll add a retrospective NAK ;).
> > > 
> > > The main reason is the asymmetry between dma map and unmap. With host
> > > swiotlb somehow getting !dma_capable(dev), you even risk leaking dom0
> > > swiotlb bounce buffers (on arm64).
> > > 
> > > > --- a/arch/arm/xen/mm.c
> > > > +++ b/arch/arm/xen/mm.c
> > > [...]
> > > > +/* functions called by SWIOTLB */
> > > > +
> > > > +static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
> > > > +       size_t size, enum dma_data_direction dir,
> > > > +       void (*op)(const void *, size_t, int))
> > > > +{
> > > > +       unsigned long pfn;
> > > > +       size_t left = size;
> > > > +
> > > > +       pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
> > > > +       offset %= PAGE_SIZE;
> > > > +
> > > > +       do {
> > > > +               size_t len = left;
> > > > +               void *vaddr;
> > > > +
> > > > +               if (!pfn_valid(pfn))
> > > 
> > > Is this the pfn or the mfn? As you said in the previous email, there is
> > > no mfn_to_pfn() conversion, so that's actually in another address space
> > > where dom0 pfn_valid() would not make sense.
> > 
> > That is actually the mfn. The check works because dom0 is mapped 1:1, so
> > if the mfn is a valid pfn, then it means that it is a local page.
> 
> So the Xen DMA ops would never be called on anything other than dom0?

That's right.


> If that's correct, the pfn_valid() check would work. But add some big
> comments as it's not clear at all to someone not familiar with Xen.

Yeah...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 17:38:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 17:38:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmnU2-0001L5-8A; Fri, 07 Nov 2014 17:38:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmnU1-0001L0-6j
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 17:38:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/9B-24532-8730D545; Fri, 07 Nov 2014 17:38:00 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415381877!12284169!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19170 invoked from network); 7 Nov 2014 17:37:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 17:37:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="190649722"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 12:24:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmnGu-0008Uc-FI;
	Fri, 07 Nov 2014 17:24:28 +0000
Date: Fri, 7 Nov 2014 17:24:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107160006.GE29148@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
References: <1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> (talking to Ian in person helped a bit ;))
> 
> On Fri, Nov 07, 2014 at 02:10:25PM +0000, Stefano Stabellini wrote:
> > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > On Thu, Nov 06, 2014 at 12:22:13PM +0000, Stefano Stabellini wrote:
> > > > On Thu, 6 Nov 2014, Catalin Marinas wrote:
> > > > > On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> > > > > > On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > > > > > > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > > > > > > standard cache maintenance would be enough (but that's a Xen problem,
> > > > > > > not sure how to solve).
> > > > > > 
> > > > > > It is a thorny issue indeed.
> > > > > > Xen would need to know how to do non-standard cache maintenance
> > > > > > operations.
> > > > > 
> > > > > Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
> > > > > just use the currently registered dma ops.
> > > > 
> > > > It is Xen, so El2 hypervisor.
> > > 
> > > So what is arch/arm/xen/mm32.c cache maintenance for? Doesn't it run in
> > > dom0?
> > 
> > This patch series changes that code path specifically. As a matter of
> > fact it removes mm32.c.
> 
> Well, it actually merges it into another file, dma_cache_maint() still
> remains.
> 
> > Before this patch series, cache maintenance in dom0 was being done with
> > XENFEAT_grant_map_identity (see explanation in previous email).
> > After this patch series, an hypercall is made when foreign pages are
> > involved, see patch 8/8, the if(!pfn_valid(pfn)) code path. Local pages
> > are still flushed in dom0.
> 
> OK. One question I had though is whether pfn_valid(mfn) is always false for
> foreign pages. IIUC, dom0 uses a 1:1 pfn:mfn mapping, so it would work.

Right


> But from what I gather, there can be other guest, not necessarily dom0,
> handling the DMA in which case, if it doesn't use a 1:1 pfn:mfn mapping,
> your pfn_valid(mfn) check would no longer work for foreign pages.

We don't support assigning devices to guests other than dom0 without an
SMMU. With an SMMU it should all be transparent. Either way the
pfn_valid check should always work.



> > > > Fortunately these dma_ops don't actually need to do much. In fact they
> > > > only need to flush caches if the device is not dma-coherent. So the
> > > > current proposed solution is to issue an hypercall to ask Xen to do the
> > > > flushing, passing the physical address dom0 knows.
> > > 
> > > I really don't like the dma_cache_maint() duplication you added in
> > > arch/arm/xen/mm32.c just because you cannot call the host dma_ops when
> > > the page is not available.
> > 
> > I agree is bad, but this patch series is a big step forward removing the
> > duplication. In fact now that I think about it, when a page is local (not a
> > foreign page) I could just call the host dma_ops. mm.c:dma_cache_maint
> > would only be used for foreign pages (pages for which !pfn_valid(pfn)).
> 
> Indeed. I already replied to patch 6/8. This way I think you can remove
> dma_cache_maint() duplication entirely, just add one specific to foreign
> pages.

Yes, that was a very good suggestion, the code is much cleaner now.
Thanks!


> What I would like to see is xen_dma_map_page() also using hyp calls for
> cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> need another argument to xen_dma_map_page() though to pass the real
> device address or mfn (and on the map side you could simply check for
> page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> bouncing so you don't need dom0 swiotlb involved as well.

I can see that it would be nice to have map_page and unmap_page be
symmetrical. However actually doing the map_page flush with an hypercall
would slow things down. Hypercalls are slower than function calls. It is
faster to do the cache flushing in dom0 if possible. In the map_page
case we have the struct page so we can easily do it by calling the
native dma_ops function.

Maybe I could just add a comment to explain the reason for the asymmetry?


> > > You basically only need a VA that was mapped in dom0 when map_page() was
> > > called and is still mapped when page_unmap() is called. You can free the
> > > actual mapping after calling __generic_dma_ops()->unmap_page() in
> > > xen_dma_unmap_page() (in xen_unmap_single()).
> > 
> > That is true, but where would I store the mapping?
> 
> dev_archdata ;).

Uhm... I haven't thought about using dev_archdata. It might simplify the
problem a bit. I'll have to think it over. It could be 3.19 or 3.20
material.


> > I don't want to introduce another data structure to keep physical to va
> > or physical to struct page mappings that I need to modify at every
> > map_page and unmap_page. It wouldn't even be a trivial data structure as
> > multiple dma operations involving the same mfn but different struct page
> > can happen simultaneously.
> > 
> > The performance hit of maintaining such a data structure would be
> > significant.
> 
> There would indeed be a performance hit especially for sg ops.
> 
> > It would negatively impact any dma operations involving any devices,
> > including dma coherent ones. While this series only requires special
> > handling of dma operations involving non-coherent devices (resulting in
> > an hypercall being made).
> > 
> > In a way this series rewards hardware that makes life easier to software
> > developers :-)
> 
> I only need the pfn_valid() clarification now together with the
> map/unmap symmetry fix.
>
> I think for the time being is_device_dma_coherent() can stay as an
> arch-only function as it is only used by Xen on arm/arm64. If we later
> need this on other architectures, we can make it generic.

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 17:38:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 17:38:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmnU2-0001L5-8A; Fri, 07 Nov 2014 17:38:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmnU1-0001L0-6j
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 17:38:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/9B-24532-8730D545; Fri, 07 Nov 2014 17:38:00 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415381877!12284169!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19170 invoked from network); 7 Nov 2014 17:37:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 17:37:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="190649722"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 12:24:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmnGu-0008Uc-FI;
	Fri, 07 Nov 2014 17:24:28 +0000
Date: Fri, 7 Nov 2014 17:24:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107160006.GE29148@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
References: <1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> (talking to Ian in person helped a bit ;))
> 
> On Fri, Nov 07, 2014 at 02:10:25PM +0000, Stefano Stabellini wrote:
> > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > On Thu, Nov 06, 2014 at 12:22:13PM +0000, Stefano Stabellini wrote:
> > > > On Thu, 6 Nov 2014, Catalin Marinas wrote:
> > > > > On Wed, Nov 05, 2014 at 06:15:38PM +0000, Stefano Stabellini wrote:
> > > > > > On Wed, 5 Nov 2014, Catalin Marinas wrote:
> > > > > > > Note that if !is_device_dma_coherent(), it doesn't always mean that
> > > > > > > standard cache maintenance would be enough (but that's a Xen problem,
> > > > > > > not sure how to solve).
> > > > > > 
> > > > > > It is a thorny issue indeed.
> > > > > > Xen would need to know how to do non-standard cache maintenance
> > > > > > operations.
> > > > > 
> > > > > Is EL2 hyp or EL1 dom0 doing such maintenance? If the latter, you could
> > > > > just use the currently registered dma ops.
> > > > 
> > > > It is Xen, so El2 hypervisor.
> > > 
> > > So what is arch/arm/xen/mm32.c cache maintenance for? Doesn't it run in
> > > dom0?
> > 
> > This patch series changes that code path specifically. As a matter of
> > fact it removes mm32.c.
> 
> Well, it actually merges it into another file, dma_cache_maint() still
> remains.
> 
> > Before this patch series, cache maintenance in dom0 was being done with
> > XENFEAT_grant_map_identity (see explanation in previous email).
> > After this patch series, an hypercall is made when foreign pages are
> > involved, see patch 8/8, the if(!pfn_valid(pfn)) code path. Local pages
> > are still flushed in dom0.
> 
> OK. One question I had though is whether pfn_valid(mfn) is always false for
> foreign pages. IIUC, dom0 uses a 1:1 pfn:mfn mapping, so it would work.

Right


> But from what I gather, there can be other guest, not necessarily dom0,
> handling the DMA in which case, if it doesn't use a 1:1 pfn:mfn mapping,
> your pfn_valid(mfn) check would no longer work for foreign pages.

We don't support assigning devices to guests other than dom0 without an
SMMU. With an SMMU it should all be transparent. Either way the
pfn_valid check should always work.



> > > > Fortunately these dma_ops don't actually need to do much. In fact they
> > > > only need to flush caches if the device is not dma-coherent. So the
> > > > current proposed solution is to issue an hypercall to ask Xen to do the
> > > > flushing, passing the physical address dom0 knows.
> > > 
> > > I really don't like the dma_cache_maint() duplication you added in
> > > arch/arm/xen/mm32.c just because you cannot call the host dma_ops when
> > > the page is not available.
> > 
> > I agree is bad, but this patch series is a big step forward removing the
> > duplication. In fact now that I think about it, when a page is local (not a
> > foreign page) I could just call the host dma_ops. mm.c:dma_cache_maint
> > would only be used for foreign pages (pages for which !pfn_valid(pfn)).
> 
> Indeed. I already replied to patch 6/8. This way I think you can remove
> dma_cache_maint() duplication entirely, just add one specific to foreign
> pages.

Yes, that was a very good suggestion, the code is much cleaner now.
Thanks!


> What I would like to see is xen_dma_map_page() also using hyp calls for
> cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> need another argument to xen_dma_map_page() though to pass the real
> device address or mfn (and on the map side you could simply check for
> page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> bouncing so you don't need dom0 swiotlb involved as well.

I can see that it would be nice to have map_page and unmap_page be
symmetrical. However actually doing the map_page flush with an hypercall
would slow things down. Hypercalls are slower than function calls. It is
faster to do the cache flushing in dom0 if possible. In the map_page
case we have the struct page so we can easily do it by calling the
native dma_ops function.

Maybe I could just add a comment to explain the reason for the asymmetry?


> > > You basically only need a VA that was mapped in dom0 when map_page() was
> > > called and is still mapped when page_unmap() is called. You can free the
> > > actual mapping after calling __generic_dma_ops()->unmap_page() in
> > > xen_dma_unmap_page() (in xen_unmap_single()).
> > 
> > That is true, but where would I store the mapping?
> 
> dev_archdata ;).

Uhm... I haven't thought about using dev_archdata. It might simplify the
problem a bit. I'll have to think it over. It could be 3.19 or 3.20
material.


> > I don't want to introduce another data structure to keep physical to va
> > or physical to struct page mappings that I need to modify at every
> > map_page and unmap_page. It wouldn't even be a trivial data structure as
> > multiple dma operations involving the same mfn but different struct page
> > can happen simultaneously.
> > 
> > The performance hit of maintaining such a data structure would be
> > significant.
> 
> There would indeed be a performance hit especially for sg ops.
> 
> > It would negatively impact any dma operations involving any devices,
> > including dma coherent ones. While this series only requires special
> > handling of dma operations involving non-coherent devices (resulting in
> > an hypercall being made).
> > 
> > In a way this series rewards hardware that makes life easier to software
> > developers :-)
> 
> I only need the pfn_valid() clarification now together with the
> map/unmap symmetry fix.
>
> I think for the time being is_device_dma_coherent() can stay as an
> arch-only function as it is only used by Xen on arm/arm64. If we later
> need this on other architectures, we can make it generic.

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 17:49:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 17:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmneM-0001Wz-D9; Fri, 07 Nov 2014 17:48:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmneL-0001Wu-Cn
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 17:48:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B5/36-09936-8F50D545; Fri, 07 Nov 2014 17:48:40 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415382518!4987417!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9227 invoked from network); 7 Nov 2014 17:48:39 -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;
	7 Nov 2014 17:48:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="190659684"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 12:48:26 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmnRu-0000Gq-R5;
	Fri, 07 Nov 2014 17:35:50 +0000
Date: Fri, 7 Nov 2014 17:35:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
References: <1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > What I would like to see is xen_dma_map_page() also using hyp calls for
> > cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> > need another argument to xen_dma_map_page() though to pass the real
> > device address or mfn (and on the map side you could simply check for
> > page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> > bouncing so you don't need dom0 swiotlb involved as well.
> 
> I can see that it would be nice to have map_page and unmap_page be
> symmetrical. However actually doing the map_page flush with an hypercall
> would slow things down. Hypercalls are slower than function calls. It is
> faster to do the cache flushing in dom0 if possible. In the map_page
> case we have the struct page so we can easily do it by calling the
> native dma_ops function.
> 
> Maybe I could just add a comment to explain the reason for the asymmetry?

Ah, but the problem is that map_page could allocate a swiotlb buffer
(actually it does on arm64) that without a corresponding unmap_page
call, would end up being leaked, right?

Oh well.. two hypercalls it is then :-/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 17:49:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 17:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmneM-0001Wz-D9; Fri, 07 Nov 2014 17:48:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmneL-0001Wu-Cn
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 17:48:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B5/36-09936-8F50D545; Fri, 07 Nov 2014 17:48:40 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415382518!4987417!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9227 invoked from network); 7 Nov 2014 17:48:39 -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;
	7 Nov 2014 17:48:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="190659684"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 12:48:26 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmnRu-0000Gq-R5;
	Fri, 07 Nov 2014 17:35:50 +0000
Date: Fri, 7 Nov 2014 17:35:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
References: <1414422568-19103-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411031045340.22875@kaball.uk.xensource.com>
	<20141103105716.GC23162@arm.com>
	<alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > What I would like to see is xen_dma_map_page() also using hyp calls for
> > cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> > need another argument to xen_dma_map_page() though to pass the real
> > device address or mfn (and on the map side you could simply check for
> > page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> > bouncing so you don't need dom0 swiotlb involved as well.
> 
> I can see that it would be nice to have map_page and unmap_page be
> symmetrical. However actually doing the map_page flush with an hypercall
> would slow things down. Hypercalls are slower than function calls. It is
> faster to do the cache flushing in dom0 if possible. In the map_page
> case we have the struct page so we can easily do it by calling the
> native dma_ops function.
> 
> Maybe I could just add a comment to explain the reason for the asymmetry?

Ah, but the problem is that map_page could allocate a swiotlb buffer
(actually it does on arm64) that without a corresponding unmap_page
call, would end up being leaked, right?

Oh well.. two hypercalls it is then :-/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 18:15:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 18:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmo3X-0001tD-NL; Fri, 07 Nov 2014 18:14:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xmo3X-0001t8-AM
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 18:14:43 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	56/6C-02696-21C0D545; Fri, 07 Nov 2014 18:14:42 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415384080!12129787!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30128 invoked from network); 7 Nov 2014 18:14:40 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-10.tower-27.messagelabs.com with SMTP;
	7 Nov 2014 18:14:40 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 8246A1AA;
	Fri,  7 Nov 2014 12:14:35 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 376385FAD7;
	Fri,  7 Nov 2014 12:14:34 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id BC08713F91E;
	Fri,  7 Nov 2014 12:14:32 -0600 (CST)
Date: Fri, 7 Nov 2014 18:14:30 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107181430.GH29148@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 05:35:41PM +0000, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Stefano Stabellini wrote:
> > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > What I would like to see is xen_dma_map_page() also using hyp calls for
> > > cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> > > need another argument to xen_dma_map_page() though to pass the real
> > > device address or mfn (and on the map side you could simply check for
> > > page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> > > bouncing so you don't need dom0 swiotlb involved as well.
> > 
> > I can see that it would be nice to have map_page and unmap_page be
> > symmetrical. However actually doing the map_page flush with an hypercall
> > would slow things down. Hypercalls are slower than function calls. It is
> > faster to do the cache flushing in dom0 if possible. In the map_page
> > case we have the struct page so we can easily do it by calling the
> > native dma_ops function.
> > 
> > Maybe I could just add a comment to explain the reason for the asymmetry?
> 
> Ah, but the problem is that map_page could allocate a swiotlb buffer
> (actually it does on arm64) that without a corresponding unmap_page
> call, would end up being leaked, right?

Yes. You could hack dma_capable() to always return true for dom0
(because the pfn/dma address here doesn't have anything to do with the
real mfn) but that's more of a hack assuming a lot about the swiotlb
implementation.

> Oh well.. two hypercalls it is then :-/

That looks cleaner to me (though I haven't seen the code yet ;)).

Alternatively, you could keep a permanent page (per-cpu) in dom0 that
you ask the hypervisor to point at the mfn just for the unmap cache
maintenance (similarly to the kernel kmap_atomic used for cache
maintenance on high pages). This could be more expensive but, OTOH, you
only need the hyp call on the unmap path. The is_device_dma_coherent()
would still remain to avoid any unnecessary map/unmap calls but for
non-coherent devices you use whatever the SoC provides.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 18:15:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 18:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmo3X-0001tD-NL; Fri, 07 Nov 2014 18:14:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xmo3X-0001t8-AM
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 18:14:43 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	56/6C-02696-21C0D545; Fri, 07 Nov 2014 18:14:42 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415384080!12129787!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30128 invoked from network); 7 Nov 2014 18:14:40 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-10.tower-27.messagelabs.com with SMTP;
	7 Nov 2014 18:14:40 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 8246A1AA;
	Fri,  7 Nov 2014 12:14:35 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 376385FAD7;
	Fri,  7 Nov 2014 12:14:34 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id BC08713F91E;
	Fri,  7 Nov 2014 12:14:32 -0600 (CST)
Date: Fri, 7 Nov 2014 18:14:30 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107181430.GH29148@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 05:35:41PM +0000, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Stefano Stabellini wrote:
> > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > What I would like to see is xen_dma_map_page() also using hyp calls for
> > > cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> > > need another argument to xen_dma_map_page() though to pass the real
> > > device address or mfn (and on the map side you could simply check for
> > > page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> > > bouncing so you don't need dom0 swiotlb involved as well.
> > 
> > I can see that it would be nice to have map_page and unmap_page be
> > symmetrical. However actually doing the map_page flush with an hypercall
> > would slow things down. Hypercalls are slower than function calls. It is
> > faster to do the cache flushing in dom0 if possible. In the map_page
> > case we have the struct page so we can easily do it by calling the
> > native dma_ops function.
> > 
> > Maybe I could just add a comment to explain the reason for the asymmetry?
> 
> Ah, but the problem is that map_page could allocate a swiotlb buffer
> (actually it does on arm64) that without a corresponding unmap_page
> call, would end up being leaked, right?

Yes. You could hack dma_capable() to always return true for dom0
(because the pfn/dma address here doesn't have anything to do with the
real mfn) but that's more of a hack assuming a lot about the swiotlb
implementation.

> Oh well.. two hypercalls it is then :-/

That looks cleaner to me (though I haven't seen the code yet ;)).

Alternatively, you could keep a permanent page (per-cpu) in dom0 that
you ask the hypervisor to point at the mfn just for the unmap cache
maintenance (similarly to the kernel kmap_atomic used for cache
maintenance on high pages). This could be more expensive but, OTOH, you
only need the hyp call on the unmap path. The is_device_dma_coherent()
would still remain to avoid any unnecessary map/unmap calls but for
non-coherent devices you use whatever the SoC provides.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 18:20:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 18: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 1Xmo90-00021v-Fx; Fri, 07 Nov 2014 18:20:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xmo8y-00021q-S5
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 18:20:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6C/2F-24532-46D0D545; Fri, 07 Nov 2014 18:20:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415384416!11951490!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30622 invoked from network); 7 Nov 2014 18:20:19 -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;
	7 Nov 2014 18:20:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,334,1413244800"; d="scan'208";a="189241124"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 13:20:12 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xmo8q-0003JR-HZ;
	Fri, 07 Nov 2014 18:20:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xmo8p-00028e-Fb;
	Fri, 07 Nov 2014 18:20:11 +0000
Date: Fri, 7 Nov 2014 18:20:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31429-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31429: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31429 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31429/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 18:20:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 18: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 1Xmo90-00021v-Fx; Fri, 07 Nov 2014 18:20:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xmo8y-00021q-S5
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 18:20:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6C/2F-24532-46D0D545; Fri, 07 Nov 2014 18:20:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415384416!11951490!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30622 invoked from network); 7 Nov 2014 18:20:19 -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;
	7 Nov 2014 18:20:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,334,1413244800"; d="scan'208";a="189241124"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 13:20:12 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xmo8q-0003JR-HZ;
	Fri, 07 Nov 2014 18:20:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xmo8p-00028e-Fb;
	Fri, 07 Nov 2014 18:20:11 +0000
Date: Fri, 7 Nov 2014 18:20:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31429-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31429: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31429 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31429/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 18:45:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 18:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmoXS-0002Ll-Re; Fri, 07 Nov 2014 18:45:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmoXQ-0002Lg-SW
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 18:45:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AE/51-09936-F431D545; Fri, 07 Nov 2014 18:45:35 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415385934!12325496!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28029 invoked from network); 7 Nov 2014 18:45:35 -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;
	7 Nov 2014 18:45:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,334,1413244800"; d="scan'208";a="190678429"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 13:45:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmoXM-0001rG-1c;
	Fri, 07 Nov 2014 18:45:32 +0000
Date: Fri, 7 Nov 2014 18:45:22 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107181430.GH29148@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411071834540.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
	<20141107181430.GH29148@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> On Fri, Nov 07, 2014 at 05:35:41PM +0000, Stefano Stabellini wrote:
> > On Fri, 7 Nov 2014, Stefano Stabellini wrote:
> > > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > > What I would like to see is xen_dma_map_page() also using hyp calls for
> > > > cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> > > > need another argument to xen_dma_map_page() though to pass the real
> > > > device address or mfn (and on the map side you could simply check for
> > > > page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> > > > bouncing so you don't need dom0 swiotlb involved as well.
> > > 
> > > I can see that it would be nice to have map_page and unmap_page be
> > > symmetrical. However actually doing the map_page flush with an hypercall
> > > would slow things down. Hypercalls are slower than function calls. It is
> > > faster to do the cache flushing in dom0 if possible. In the map_page
> > > case we have the struct page so we can easily do it by calling the
> > > native dma_ops function.
> > > 
> > > Maybe I could just add a comment to explain the reason for the asymmetry?
> > 
> > Ah, but the problem is that map_page could allocate a swiotlb buffer
> > (actually it does on arm64) that without a corresponding unmap_page
> > call, would end up being leaked, right?
> 
> Yes. You could hack dma_capable() to always return true for dom0
> (because the pfn/dma address here doesn't have anything to do with the
> real mfn) but that's more of a hack assuming a lot about the swiotlb
> implementation.

Another idea would be to avoid calling the native map_page for foreign
pages, but in the xen specific implementation instead of making the
hypercall, we could call __dma_map_area on arm64 and map_page on arm.

Something like this:


In arch/arm/include/asm/xen/page-coherent.h:

static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
	     dma_addr_t dev_addr, unsigned long offset, size_t size,
	     enum dma_data_direction dir, struct dma_attrs *attrs)
{
	if (pfn_valid(PFN_DOWN(dev_addr))) {
		if (__generic_dma_ops(hwdev)->map_page)
			__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
	} else
		__xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
}



In arch/arm/xen/mm.c:

void __xen_dma_map_page(struct device *hwdev, struct page *page,
	     dma_addr_t dev_addr, unsigned long offset, size_t size,
	     enum dma_data_direction dir, struct dma_attrs *attrs)
{
	if (is_device_dma_coherent(hwdev))
		return;
#ifdef CONFIG_ARM64
	__dma_map_area(page_to_phys(page) + offset, size, dir);
#else
	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
#endif
}


It wouldn't be as nice as using the hypercall but it would be faster and
wouldn't depend on the inner workings of the arm64 implementation of
map_page, except for __dma_map_area.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 18:45:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 18:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmoXS-0002Ll-Re; Fri, 07 Nov 2014 18:45:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XmoXQ-0002Lg-SW
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 18:45:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AE/51-09936-F431D545; Fri, 07 Nov 2014 18:45:35 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415385934!12325496!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28029 invoked from network); 7 Nov 2014 18:45:35 -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;
	7 Nov 2014 18:45:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,334,1413244800"; d="scan'208";a="190678429"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 7 Nov 2014 13:45:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XmoXM-0001rG-1c;
	Fri, 07 Nov 2014 18:45:32 +0000
Date: Fri, 7 Nov 2014 18:45:22 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141107181430.GH29148@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411071834540.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411031101400.22875@kaball.uk.xensource.com>
	<20141105165646.GN32700@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
	<20141107181430.GH29148@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Nov 2014, Catalin Marinas wrote:
> On Fri, Nov 07, 2014 at 05:35:41PM +0000, Stefano Stabellini wrote:
> > On Fri, 7 Nov 2014, Stefano Stabellini wrote:
> > > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > > What I would like to see is xen_dma_map_page() also using hyp calls for
> > > > cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> > > > need another argument to xen_dma_map_page() though to pass the real
> > > > device address or mfn (and on the map side you could simply check for
> > > > page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> > > > bouncing so you don't need dom0 swiotlb involved as well.
> > > 
> > > I can see that it would be nice to have map_page and unmap_page be
> > > symmetrical. However actually doing the map_page flush with an hypercall
> > > would slow things down. Hypercalls are slower than function calls. It is
> > > faster to do the cache flushing in dom0 if possible. In the map_page
> > > case we have the struct page so we can easily do it by calling the
> > > native dma_ops function.
> > > 
> > > Maybe I could just add a comment to explain the reason for the asymmetry?
> > 
> > Ah, but the problem is that map_page could allocate a swiotlb buffer
> > (actually it does on arm64) that without a corresponding unmap_page
> > call, would end up being leaked, right?
> 
> Yes. You could hack dma_capable() to always return true for dom0
> (because the pfn/dma address here doesn't have anything to do with the
> real mfn) but that's more of a hack assuming a lot about the swiotlb
> implementation.

Another idea would be to avoid calling the native map_page for foreign
pages, but in the xen specific implementation instead of making the
hypercall, we could call __dma_map_area on arm64 and map_page on arm.

Something like this:


In arch/arm/include/asm/xen/page-coherent.h:

static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
	     dma_addr_t dev_addr, unsigned long offset, size_t size,
	     enum dma_data_direction dir, struct dma_attrs *attrs)
{
	if (pfn_valid(PFN_DOWN(dev_addr))) {
		if (__generic_dma_ops(hwdev)->map_page)
			__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
	} else
		__xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
}



In arch/arm/xen/mm.c:

void __xen_dma_map_page(struct device *hwdev, struct page *page,
	     dma_addr_t dev_addr, unsigned long offset, size_t size,
	     enum dma_data_direction dir, struct dma_attrs *attrs)
{
	if (is_device_dma_coherent(hwdev))
		return;
#ifdef CONFIG_ARM64
	__dma_map_area(page_to_phys(page) + offset, size, dir);
#else
	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
#endif
}


It wouldn't be as nice as using the hypercall but it would be faster and
wouldn't depend on the inner workings of the arm64 implementation of
map_page, except for __dma_map_area.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 19:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 19:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmpUv-0002pf-Ne; Fri, 07 Nov 2014 19:47:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmpUu-0002pV-CZ
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 19:47:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E2/76-09936-7B12D545; Fri, 07 Nov 2014 19:47:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415389621!12315071!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24271 invoked from network); 7 Nov 2014 19:47:02 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 19:47:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7Jkppc016686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 19:46:51 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7Jkni0003969
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Nov 2014 19:46:50 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7JknRs017191; Fri, 7 Nov 2014 19:46:49 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 11:46:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8DEDA111708; Fri,  7 Nov 2014 09:52:01 -0500 (EST)
Date: Fri, 7 Nov 2014 09:52:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>, George.Dunlap@eu.citrix.com
Message-ID: <20141107145201.GE13259@laptop.dumpdata.com>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
	<CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
	<20141104104649.GA8479@aepfle.de>
	<CAFLBxZbm5sXPKM7312rjRojdhr9e8W5qGKuGjjH25_zoG1g+rg@mail.gmail.com>
	<1415099037.11486.25.camel@citrix.com>
	<20141107133058.GA11146@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141107133058.GA11146@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Fri, Nov 07, 2014 at 02:30:58PM +0100, Olaf Hering wrote:
> So how should we proceed here?!

George, any input on this since Ian just nominated you to
be the maintainer-pro-temp?

Thanks.
> 
> Olaf
> 
> On Tue, Nov 04, Ian Campbell wrote:
> 
> > On Tue, 2014-11-04 at 11:00 +0000, George Dunlap wrote:
> > > On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > > > On Tue, Nov 04, George Dunlap wrote:
> > > >
> > > >> A number based on the time you happened to create the RPM, not based
> > > >> on something intrinsic about the content of the RPM; that just seems
> > > >> kind of hacky to me.  It happens to work well for your common
> > > >> workflow, but you can certainly imagine other workflows or other
> > > >> situations where you'd have to more manually override things anyway
> > > >> (for instance, doing bisections, or comparing functionality in
> > > >> different releases).  It seems like rather than having to remember
> > > >> when you can skip the manual override bits, and when you can't, it
> > > >> would be better to just use them all the time.
> > > >
> > > > George, the release number is and was never meant to describe the
> > > > content of a package. It just means "its different". And it will even
> > > > work for bisect because the package is always "newer", even if the
> > > > content is different.
> > > 
> > > Not if you end up going to a previously built package for some reason.
> > > 
> > > I can see how this makes more sense if you do have an independent
> > > package installed for every branch; but most people are not going to
> > > do that.
> > > 
> > > Anyway, if I were a maintainer, I might decide to accept it, even
> > > though I didn't like it, on the grounds that it doesn't do much harm
> > > and somebody finds it useful.
> > > 
> > > Since I'm not a maintainer, I'm free to be opinionated. :-)
> > 
> > I don't think any of the formal maintainers of this code use RPM[0], and
> > you are the original author of the tool... So I'm afraid I think you
> > might have a more relevant opinion than you might like.
> > 
> > Ian.
> > 
> > [0] At least half happen to be Debian Maintainers...
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 07 19:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 19:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmpUw-0002pm-3M; Fri, 07 Nov 2014 19:47:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmpUv-0002pa-9C
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 19:47:05 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	24/57-17735-8B12D545; Fri, 07 Nov 2014 19:47:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415389622!11242954!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32417 invoked from network); 7 Nov 2014 19:47:03 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 19:47:03 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7JkoZm005973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 19:46:51 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7Jknpi003964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Nov 2014 19:46:50 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7JknPN023271; Fri, 7 Nov 2014 19:46:49 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 11:46:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 465251116F3; Fri,  7 Nov 2014 09:45:17 -0500 (EST)
Date: Fri, 7 Nov 2014 09:45:17 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107144517.GA13259@laptop.dumpdata.com>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
	<alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
	<CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
	<alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-kernel@vger.kernel.org, Frediano Ziglio <frediano.ziglio@huawei.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Frediano Ziglio <freddy77@gmail.com>
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
 xen_swiotlb_map_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="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, Nov 06, 2014 at 07:14:51PM +0000, Stefano Stabellini wrote:
> On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> > 2014-11-06 17:30 GMT+00:00 Stefano Stabellini <stefano.stabellini@eu.ci=
trix.com>:
> >       On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> >       > On ARM error code is not 0 so avoid to return it as error.
> >       >
> >       > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > =

> >       Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > =

> > =

> >       Could you please fix the same error in lib/swiotlb.c too please?
> > =

> > =

> > Same patch or another ?
> > =

> =

> Another

It might break the build. Please double-check that it does not affect
ia64.
> =

> > =A0
> >       >=A0 drivers/xen/swiotlb-xen.c | 2 +-
> >       >=A0 1 file changed, 1 insertion(+), 1 deletion(-)
> >       >
> >       > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xe=
n.c
> >       > index ebd8f21..3b8d628 100644
> >       > --- a/drivers/xen/swiotlb-xen.c
> >       > +++ b/drivers/xen/swiotlb-xen.c
> >       > @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct devi=
ce *dev, struct page *page,
> >       >=A0 =A0 =A0 =A0 */
> >       >=A0 =A0 =A0 =A0if (!dma_capable(dev, dev_addr, size)) {
> >       >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0swiotlb_tbl_unmap_single(dev, map=
, size, dir);
> >       > -=A0 =A0 =A0 =A0 =A0 =A0 =A0dev_addr =3D 0;
> >       > +=A0 =A0 =A0 =A0 =A0 =A0 =A0dev_addr =3D DMA_ERROR_CODE;

That looks Ok to me.

> >       >=A0 =A0 =A0 =A0}
> >       >=A0 =A0 =A0 =A0return dev_addr;
> >       >=A0 }
> >       > --
> >       > 1.9.1
> >       >
> >       >
> >       > --
> >       > To unsubscribe from this list: send the line "unsubscribe linux=
-kernel" in
> >       > the body of a message to majordomo@vger.kernel.org
> >       > More majordomo info at=A0 http://vger.kernel.org/majordomo-info=
.html
> >       > Please read the FAQ at=A0http://secure-web.cisco.com/1cvjROyUxV=
6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpcx=
wEH-udGrGCCq
> >       kCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYc=
vWsOK5s3qg/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> >       >
> > =

> >       _______________________________________________
> >       Xen-devel mailing list
> >       Xen-devel@lists.xen.org
> >       http://lists.xen.org/xen-devel
> > =

> > =

> > =

> > =


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 19:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 19:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmpUv-0002pf-Ne; Fri, 07 Nov 2014 19:47:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmpUu-0002pV-CZ
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 19:47:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E2/76-09936-7B12D545; Fri, 07 Nov 2014 19:47:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415389621!12315071!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24271 invoked from network); 7 Nov 2014 19:47:02 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 19:47:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7Jkppc016686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 19:46:51 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7Jkni0003969
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Nov 2014 19:46:50 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7JknRs017191; Fri, 7 Nov 2014 19:46:49 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 11:46:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8DEDA111708; Fri,  7 Nov 2014 09:52:01 -0500 (EST)
Date: Fri, 7 Nov 2014 09:52:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>, George.Dunlap@eu.citrix.com
Message-ID: <20141107145201.GE13259@laptop.dumpdata.com>
References: <1412694063-29616-1-git-send-email-olaf@aepfle.de>
	<CAFLBxZZKR5Z_nG2_7V_EQxcqgL44Hvo00uTd1gSVwxvo_SZY9g@mail.gmail.com>
	<20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com>
	<20141103144848.GB28870@aepfle.de>
	<CAFLBxZbCorLriYgAfzvCXENeA3dKsyc164WdcGbssgRX40RoEw@mail.gmail.com>
	<20141104104649.GA8479@aepfle.de>
	<CAFLBxZbm5sXPKM7312rjRojdhr9e8W5qGKuGjjH25_zoG1g+rg@mail.gmail.com>
	<1415099037.11486.25.camel@citrix.com>
	<20141107133058.GA11146@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141107133058.GA11146@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve
 version.release 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 Fri, Nov 07, 2014 at 02:30:58PM +0100, Olaf Hering wrote:
> So how should we proceed here?!

George, any input on this since Ian just nominated you to
be the maintainer-pro-temp?

Thanks.
> 
> Olaf
> 
> On Tue, Nov 04, Ian Campbell wrote:
> 
> > On Tue, 2014-11-04 at 11:00 +0000, George Dunlap wrote:
> > > On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > > > On Tue, Nov 04, George Dunlap wrote:
> > > >
> > > >> A number based on the time you happened to create the RPM, not based
> > > >> on something intrinsic about the content of the RPM; that just seems
> > > >> kind of hacky to me.  It happens to work well for your common
> > > >> workflow, but you can certainly imagine other workflows or other
> > > >> situations where you'd have to more manually override things anyway
> > > >> (for instance, doing bisections, or comparing functionality in
> > > >> different releases).  It seems like rather than having to remember
> > > >> when you can skip the manual override bits, and when you can't, it
> > > >> would be better to just use them all the time.
> > > >
> > > > George, the release number is and was never meant to describe the
> > > > content of a package. It just means "its different". And it will even
> > > > work for bisect because the package is always "newer", even if the
> > > > content is different.
> > > 
> > > Not if you end up going to a previously built package for some reason.
> > > 
> > > I can see how this makes more sense if you do have an independent
> > > package installed for every branch; but most people are not going to
> > > do that.
> > > 
> > > Anyway, if I were a maintainer, I might decide to accept it, even
> > > though I didn't like it, on the grounds that it doesn't do much harm
> > > and somebody finds it useful.
> > > 
> > > Since I'm not a maintainer, I'm free to be opinionated. :-)
> > 
> > I don't think any of the formal maintainers of this code use RPM[0], and
> > you are the original author of the tool... So I'm afraid I think you
> > might have a more relevant opinion than you might like.
> > 
> > Ian.
> > 
> > [0] At least half happen to be Debian Maintainers...
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 07 19:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 19:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmpUw-0002pm-3M; Fri, 07 Nov 2014 19:47:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmpUv-0002pa-9C
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 19:47:05 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	24/57-17735-8B12D545; Fri, 07 Nov 2014 19:47:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415389622!11242954!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32417 invoked from network); 7 Nov 2014 19:47:03 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 19:47:03 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7JkoZm005973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 19:46:51 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7Jknpi003964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Nov 2014 19:46:50 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7JknPN023271; Fri, 7 Nov 2014 19:46:49 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 11:46:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 465251116F3; Fri,  7 Nov 2014 09:45:17 -0500 (EST)
Date: Fri, 7 Nov 2014 09:45:17 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141107144517.GA13259@laptop.dumpdata.com>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
	<alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
	<CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
	<alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-kernel@vger.kernel.org, Frediano Ziglio <frediano.ziglio@huawei.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Frediano Ziglio <freddy77@gmail.com>
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
 xen_swiotlb_map_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="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, Nov 06, 2014 at 07:14:51PM +0000, Stefano Stabellini wrote:
> On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> > 2014-11-06 17:30 GMT+00:00 Stefano Stabellini <stefano.stabellini@eu.ci=
trix.com>:
> >       On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> >       > On ARM error code is not 0 so avoid to return it as error.
> >       >
> >       > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > =

> >       Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > =

> > =

> >       Could you please fix the same error in lib/swiotlb.c too please?
> > =

> > =

> > Same patch or another ?
> > =

> =

> Another

It might break the build. Please double-check that it does not affect
ia64.
> =

> > =A0
> >       >=A0 drivers/xen/swiotlb-xen.c | 2 +-
> >       >=A0 1 file changed, 1 insertion(+), 1 deletion(-)
> >       >
> >       > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xe=
n.c
> >       > index ebd8f21..3b8d628 100644
> >       > --- a/drivers/xen/swiotlb-xen.c
> >       > +++ b/drivers/xen/swiotlb-xen.c
> >       > @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct devi=
ce *dev, struct page *page,
> >       >=A0 =A0 =A0 =A0 */
> >       >=A0 =A0 =A0 =A0if (!dma_capable(dev, dev_addr, size)) {
> >       >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0swiotlb_tbl_unmap_single(dev, map=
, size, dir);
> >       > -=A0 =A0 =A0 =A0 =A0 =A0 =A0dev_addr =3D 0;
> >       > +=A0 =A0 =A0 =A0 =A0 =A0 =A0dev_addr =3D DMA_ERROR_CODE;

That looks Ok to me.

> >       >=A0 =A0 =A0 =A0}
> >       >=A0 =A0 =A0 =A0return dev_addr;
> >       >=A0 }
> >       > --
> >       > 1.9.1
> >       >
> >       >
> >       > --
> >       > To unsubscribe from this list: send the line "unsubscribe linux=
-kernel" in
> >       > the body of a message to majordomo@vger.kernel.org
> >       > More majordomo info at=A0 http://vger.kernel.org/majordomo-info=
.html
> >       > Please read the FAQ at=A0http://secure-web.cisco.com/1cvjROyUxV=
6SnA0uBTMRubqrQWsaXGhps-FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpcx=
wEH-udGrGCCq
> >       kCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYc=
vWsOK5s3qg/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> >       >
> > =

> >       _______________________________________________
> >       Xen-devel mailing list
> >       Xen-devel@lists.xen.org
> >       http://lists.xen.org/xen-devel
> > =

> > =

> > =

> > =


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 19:48:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 19:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmpVr-0002vb-Ua; Fri, 07 Nov 2014 19:48:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmpVq-0002uz-Kq
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 19:48:02 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	3B/0B-28296-1F12D545; Fri, 07 Nov 2014 19:48:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415389679!11189386!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6595 invoked from network); 7 Nov 2014 19:48:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 19:48:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7Jkofq005976
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 19:46:51 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7Jkms1003937
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Nov 2014 19:46:49 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7JkljA003901; Fri, 7 Nov 2014 19:46:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 11:46:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0EE581117C8; Fri,  7 Nov 2014 10:45:03 -0500 (EST)
Date: Fri, 7 Nov 2014 10:45:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141107154502.GC14076@laptop.dumpdata.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545B4D1D.4090000@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 10:27:41AM +0000, Julien Grall wrote:
> 
> 
> On 06/11/2014 10:11, Jan Beulich wrote:
> >>>>On 06.11.14 at 10:45, <julien.grall@linaro.org> wrote:
> >>Hi Jan,
> >>
> >>On 05/11/2014 17:15, Jan Beulich wrote:
> >>>>>>Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
> >>>>On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>It also needs Acks from Daniel and Jan.
> >>>>
> >>>>This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
> >>>>required. Would Ian C. ack be enough?
> >>>
> >>>Yes, it would.
> >>>
> >>>>Anyway, Jan do you have any objection on this patch?
> >>>
> >>>As said previously, I'm not particularly happy about it, but I also don't
> >>strongly
> >>>mind it going in in the current shape.
> >>
> >>May I ask what is wrong with the new approach to the a DOMCTL in this patch?
> >>
> >>The DOMCTL has been clearly identify as arm specific (there is "arm" in
> >>the name). Therefore it doesn't seem necessary to expose it for other
> >>architecture than ARM32 and ARM64.
> >
> >I didn't say there's anything actively wrong with it, all I said is that
> >I'm not particularly happy about it: Irrespective of its name it doesn't
> >look to be really arch-specific in the long run, plus it feels like the
> >data being set here should rather be specified right at domain
> >creation, or via a mechanism similar to x86'es HVM parameters (iirc
> >the value set here can't be changed once the domain got first
> >unpaused).
> 
> 
> TBH I choose this solution because I though you would be disagree with
> extending the domain create hypercall.
> 
> In long run, there will be more parameters such as the number of spis. All
> will be required at the same time. So the HVM parameters solution won't
> really help here.
> 
> However, I could give a look to extending the domain creation hypercall
> (xen_domctl_createdomain) to add arch specific field.
> 
> But I don't think it's Xen 4.5 material. So I would prefer to stay on this
> approach for this release because we'd like to have GICv3 guest support on
> Xen. Though I could rename the DOMCTL to DOMCTL_get_gic_version.

That is a bit unfortunate as it sounds like that for Xen 4.6 you will
then ditch this hypercall and focus on the new one? Won't this one then
be bitrotten?

> 
> Regards,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 19:48:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 19:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmpVr-0002vI-I7; Fri, 07 Nov 2014 19:48:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmpVp-0002us-6w
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 19:48:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	44/FB-09842-0F12D545; Fri, 07 Nov 2014 19:48:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415389678!11962729!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25280 invoked from network); 7 Nov 2014 19:47:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 19:47:59 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7JkpHb006001
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 19:46:52 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7JkogE004023
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Nov 2014 19:46:50 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA7Jkn4G023480; Fri, 7 Nov 2014 19:46:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 11:46:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4F00F111705; Fri,  7 Nov 2014 09:50:44 -0500 (EST)
Date: Fri, 7 Nov 2014 09:50:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141107145044.GD13259@laptop.dumpdata.com>
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
	<545CC988.5000000@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545CC988.5000000@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 01:30:48PM +0000, Julien Grall wrote:
> Hi all,
> 
> On 05/11/2014 13:04, Julien Grall wrote:
> >The vGIC will emulate the same version as the hardware. The toolstack has
> >to retrieve the version of the vGIC in order to be able to create the
> >corresponding device tree node.
> >
> >A new DOMCTL has been introduced for ARM to configure the domain. For now
> >it only allow the toolstack to retrieve the version of vGIC.
> >This DOMCTL will be extend later to let the user choose the version of the
> >emulated GIC.
> >
> >Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> >Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >Cc: Jan Beulich <jbeulich@suse.com>
> >Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> I forgot to keep the Ack from Daniel on v2:
> 
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00230.html

Right. If he is Ok then Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Regards,
> 
> >Cc: Wei Liu <wei.liu2@citrix.com>
> >
> >---
> >Stefano, I made one change in the guest memory layout, so I've dropped you
> >Reviewed-by.
> >
> >     Changes in v3:
> >         - Typo and update some comments
> >         - Coding style
> >         - Only reserve space for an 8 VCPUs redistributor in the guest
> >         memory layout
> >
> >     Changes in v2:
> >         - Use memcpu in xc_domain_configure
> >         - Rename the DOMCTL into domctl_arm_configuredomain
> >         - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
> >         and fold the code in arch_domain_init_hw_description
> >         - Return -EOPNOTSUPP when the value of gic_version is not
> >         supported
> >
> >This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> >defer the initialization of the vGIC [2].
> >
> >Xen 4.5 has already support for the hardware GICv3. While it's possible to
> >boot and use DOM0, there is no guest support. The first version of this patch
> >has been sent a couple of months ago, but has never reached unstable for
> >various reasons (based on deferred series, lake of review at that time...).
> >Without it, platform with GICv3 support won't be able to boot any guest.
> >
> >The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> >DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
> >
> >Features such as adding a new config option to let the user choose the GIC
> >version are deferred to Xen 4.6.
> >
> >It has been tested on both GICv2/GICv3 platform. And build tested for x86.
> >
> >[1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> >[2] https://patches.linaro.org/34664/
> >---
> >  tools/flask/policy/policy/modules/xen/xen.if |    2 +-
> >  tools/libxc/include/xenctrl.h                |    6 ++
> >  tools/libxc/xc_domain.c                      |   20 ++++++
> >  tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
> >  xen/arch/arm/domctl.c                        |   35 ++++++++++
> >  xen/arch/arm/gic-v3.c                        |   16 ++++-
> >  xen/include/public/arch-arm.h                |   16 +++++
> >  xen/include/public/domctl.h                  |   17 +++++
> >  xen/xsm/flask/hooks.c                        |    3 +
> >  xen/xsm/flask/policy/access_vectors          |    2 +
> >  10 files changed, 204 insertions(+), 8 deletions(-)
> >
> >diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> >index 641c797..fa69c9d 100644
> >--- a/tools/flask/policy/policy/modules/xen/xen.if
> >+++ b/tools/flask/policy/policy/modules/xen/xen.if
> >@@ -49,7 +49,7 @@ define(`create_domain_common', `
> >  			getdomaininfo hypercall setvcpucontext setextvcpucontext
> >  			getscheduler getvcpuinfo getvcpuextstate getaddrsize
> >  			getaffinity setaffinity };
> >-	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> >+	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
> >  	allow $1 $2:security check_context;
> >  	allow $1 $2:shadow enable;
> >  	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> >diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> >index 564e187..45e282c 100644
> >--- a/tools/libxc/include/xenctrl.h
> >+++ b/tools/libxc/include/xenctrl.h
> >@@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
> >                       uint32_t flags,
> >                       uint32_t *pdomid);
> >
> >+#if defined(__arm__) || defined(__aarch64__)
> >+typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> >+
> >+int xc_domain_configure(xc_interface *xch, uint32_t domid,
> >+                        xc_domain_configuration_t *config);
> >+#endif
> >
> >  /* Functions to produce a dump of a given domain
> >   *  xc_domain_dumpcore - produces a dump to a specified file
> >diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> >index a9bcd4a..b071dea 100644
> >--- a/tools/libxc/xc_domain.c
> >+++ b/tools/libxc/xc_domain.c
> >@@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
> >      return 0;
> >  }
> >
> >+#if defined(__arm__) || defined(__aarch64__)
> >+int xc_domain_configure(xc_interface *xch, uint32_t domid,
> >+                        xc_domain_configuration_t *config)
> >+{
> >+    int rc;
> >+    DECLARE_DOMCTL;
> >+
> >+    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> >+    domctl.domain = (domid_t)domid;
> >+    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
> >+    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
> >+
> >+    rc = do_domctl(xch, &domctl);
> >+    if ( !rc )
> >+        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> >+
> >+    return rc;
> >+}
> >+#endif
> >+
> >  int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
> >                           xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
> >  {
> >diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> >index a122e4a..448ac07 100644
> >--- a/tools/libxl/libxl_arm.c
> >+++ b/tools/libxl/libxl_arm.c
> >@@ -23,6 +23,18 @@
> >  #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
> >  #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
> >
> >+static const char *gicv_to_string(uint8_t gic_version)
> >+{
> >+    switch (gic_version) {
> >+    case XEN_DOMCTL_CONFIG_GIC_V2:
> >+        return "V2";
> >+    case XEN_DOMCTL_CONFIG_GIC_V3:
> >+        return "V3";
> >+    default:
> >+        return "unknown";
> >+    }
> >+}
> >+
> >  int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> >                                uint32_t domid)
> >  {
> >@@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
> >      return 0;
> >  }
> >
> >-static int make_intc_node(libxl__gc *gc, void *fdt,
> >-                          uint64_t gicd_base, uint64_t gicd_size,
> >-                          uint64_t gicc_base, uint64_t gicc_size)
> >+static int make_gicv2_node(libxl__gc *gc, void *fdt,
> >+                           uint64_t gicd_base, uint64_t gicd_size,
> >+                           uint64_t gicc_base, uint64_t gicc_size)
> >  {
> >      int res;
> >      const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> >@@ -350,6 +362,56 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
> >      return 0;
> >  }
> >
> >+static int make_gicv3_node(libxl__gc *gc, void *fdt)
> >+{
> >+    int res;
> >+    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
> >+    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
> >+    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
> >+    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
> >+    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> >+
> >+    res = fdt_begin_node(fdt, name);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_compat(gc, fdt, 1, "arm,gic-v3");
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "#address-cells", 0);
> >+    if (res) return res;
> >+
> >+    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "redistributor-stride",
> >+                            GUEST_GICV3_RDIST_STRIDE);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "#redistributor-regions",
> >+                            GUEST_GICV3_RDIST_REGIONS);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> >+                            2,
> >+                            gicd_base, gicd_size,
> >+                            gicr0_base, gicr0_size);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
> >+    if (res) return res;
> >+
> >+    res = fdt_end_node(fdt);
> >+    if (res) return res;
> >+
> >+    return 0;
> >+}
> >+
> >  static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
> >  {
> >      int res;
> >@@ -456,6 +518,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> >                                             libxl_domain_build_info *info,
> >                                             struct xc_dom_image *dom)
> >  {
> >+    xc_domain_configuration_t config;
> >      void *fdt = NULL;
> >      int rc, res;
> >      size_t fdt_size = 0;
> >@@ -471,8 +534,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> >      ainfo = get_arch_info(gc, dom);
> >      if (ainfo == NULL) return ERROR_FAIL;
> >
> >+    LOG(DEBUG, "configure the domain");
> >+    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> >+    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> >+        LOG(ERROR, "couldn't configure the domain");
> >+        return ERROR_FAIL;
> >+    }
> >+
> >      LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
> >          vers->xen_version_major, vers->xen_version_minor);
> >+    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
> >
> >  /*
> >   * Call "call" handling FDR_ERR_*. Will either:
> >@@ -520,9 +591,21 @@ next_resize:
> >          FDT( make_psci_node(gc, fdt) );
> >
> >          FDT( make_memory_nodes(gc, fdt, dom) );
> >-        FDT( make_intc_node(gc, fdt,
> >-                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> >-                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> >+
> >+        switch (config.gic_version) {
> >+        case XEN_DOMCTL_CONFIG_GIC_V2:
> >+            FDT( make_gicv2_node(gc, fdt,
> >+                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> >+                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> >+            break;
> >+        case XEN_DOMCTL_CONFIG_GIC_V3:
> >+            FDT( make_gicv3_node(gc, fdt) );
> >+            break;
> >+        default:
> >+            LOG(ERROR, "Unknown GIC version %d", config.gic_version);
> >+            rc = ERROR_FAIL;
> >+            goto out;
> >+        }
> >
> >          FDT( make_timer_node(gc, fdt, ainfo) );
> >          FDT( make_hypervisor_node(gc, fdt, vers) );
> >diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> >index 45974e7..d246e84 100644
> >--- a/xen/arch/arm/domctl.c
> >+++ b/xen/arch/arm/domctl.c
> >@@ -10,6 +10,8 @@
> >  #include <xen/errno.h>
> >  #include <xen/sched.h>
> >  #include <xen/hypercall.h>
> >+#include <asm/gic.h>
> >+#include <xen/guest_access.h>
> >  #include <public/domctl.h>
> >
> >  long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >@@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >
> >          return p2m_cache_flush(d, s, e);
> >      }
> >+    case XEN_DOMCTL_arm_configure_domain:
> >+    {
> >+        uint8_t gic_version;
> >+
> >+        /*
> >+         * Currently the vGIC is emulating the same version of the
> >+         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> >+         * is allowed. The DOMCTL will return the actual version of the
> >+         * GIC.
> >+         */
> >+        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> >+            return -EOPNOTSUPP;
> >+
> >+        switch ( gic_hw_version() )
> >+        {
> >+        case GIC_V3:
> >+            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> >+            break;
> >+        case GIC_V2:
> >+            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> >+            break;
> >+        default:
> >+            BUG();
> >+        }
> >+
> >+        domctl->u.configuredomain.gic_version = gic_version;
> >+
> >+        /* TODO: Make the copy generic for all ARCH domctl */
> >+        if ( __copy_to_guest(u_domctl, domctl, 1) )
> >+            return -EFAULT;
> >+
> >+        return 0;
> >+    }
> >
> >      default:
> >          return subarch_do_domctl(domctl, d, u_domctl);
> >diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> >index 91161a2..076aa62 100644
> >--- a/xen/arch/arm/gic-v3.c
> >+++ b/xen/arch/arm/gic-v3.c
> >@@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
> >          d->arch.vgic.rdist_count = gicv3.rdist_count;
> >      }
> >      else
> >-        d->arch.vgic.dbase = GUEST_GICD_BASE;
> >+    {
> >+        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
> >+        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
> >+
> >+        /* XXX: Only one Re-distributor region mapped for the guest */
> >+        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
> >+
> >+        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
> >+        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
> >+
> >+        /* The first redistributor should contain enough space for all CPUs */
> >+        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
> >+        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
> >+        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
> >+    }
> >
> >      d->arch.vgic.nr_lines = 0;
> >
> >diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> >index eecc561..72d641f 100644
> >--- a/xen/include/public/arch-arm.h
> >+++ b/xen/include/public/arch-arm.h
> >@@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
> >   */
> >
> >  /* Physical Address Space */
> >+
> >+/* vGIC mappings: Only one set of mapping is used by the guest.
> >+ * Therefore they can overlap.
> >+ */
> >+
> >+/* vGIC v2 mappings */
> >  #define GUEST_GICD_BASE   0x03001000ULL
> >  #define GUEST_GICD_SIZE   0x00001000ULL
> >  #define GUEST_GICC_BASE   0x03002000ULL
> >  #define GUEST_GICC_SIZE   0x00000100ULL
> >
> >+/* vGIC v3 mappings */
> >+#define GUEST_GICV3_GICD_BASE      0x03001000ULL
> >+#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
> >+
> >+#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
> >+#define GUEST_GICV3_RDIST_REGIONS  1
> >+
> >+#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU7 */
> >+#define GUEST_GICV3_GICR0_SIZE     0x00100000ULL
> >+
> >  /* 16MB == 4096 pages reserved for guest to use as a region to map its
> >   * grant table in.
> >   */
> >diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> >index 58b19e7..8da204e 100644
> >--- a/xen/include/public/domctl.h
> >+++ b/xen/include/public/domctl.h
> >@@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
> >  typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
> >
> >+#if defined(__arm__) || defined(__aarch64__)
> >+#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
> >+#define XEN_DOMCTL_CONFIG_GIC_V2        1
> >+#define XEN_DOMCTL_CONFIG_GIC_V3        2
> >+/* XEN_DOMCTL_configure_domain */
> >+struct xen_domctl_arm_configuredomain {
> >+    /* IN/OUT parameters */
> >+    uint8_t gic_version;
> >+};
> >+typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
> >+DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
> >+#endif
> >+
> >  /* XEN_DOMCTL_getdomaininfo */
> >  struct xen_domctl_getdomaininfo {
> >      /* OUT variables. */
> >@@ -1056,6 +1069,7 @@ struct xen_domctl {
> >  #define XEN_DOMCTL_set_vcpu_msrs                 73
> >  #define XEN_DOMCTL_setvnumainfo                  74
> >  #define XEN_DOMCTL_psr_cmt_op                    75
> >+#define XEN_DOMCTL_arm_configure_domain          76
> >  #define XEN_DOMCTL_gdbsx_guestmemio            1000
> >  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
> >  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> >@@ -1064,6 +1078,9 @@ struct xen_domctl {
> >      domid_t  domain;
> >      union {
> >          struct xen_domctl_createdomain      createdomain;
> >+#if defined(__arm__) || defined(__aarch64__)
> >+        struct xen_domctl_arm_configuredomain configuredomain;
> >+#endif
> >          struct xen_domctl_getdomaininfo     getdomaininfo;
> >          struct xen_domctl_getmemlist        getmemlist;
> >          struct xen_domctl_getpageframeinfo  getpageframeinfo;
> >diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> >index 6d0fe72..846cf88 100644
> >--- a/xen/xsm/flask/hooks.c
> >+++ b/xen/xsm/flask/hooks.c
> >@@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
> >      case XEN_DOMCTL_psr_cmt_op:
> >          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
> >
> >+    case XEN_DOMCTL_configure_domain:
> >+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
> >+
> >      default:
> >          printk("flask_domctl: Unknown op %d\n", cmd);
> >          return -EPERM;
> >diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> >index de0c707..bfe2fa5 100644
> >--- a/xen/xsm/flask/policy/access_vectors
> >+++ b/xen/xsm/flask/policy/access_vectors
> >@@ -216,6 +216,8 @@ class domain2
> >      get_vnumainfo
> >  # XEN_DOMCTL_psr_cmt_op
> >      psr_cmt_op
> >+# XEN_DOMCTL_configure_domain
> >+    configure_domain
> >  }
> >
> >  # Similar to class domain, but primarily contains domctls related to HVM domains
> >
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 19:48:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 19:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmpVr-0002vb-Ua; Fri, 07 Nov 2014 19:48:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmpVq-0002uz-Kq
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 19:48:02 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	3B/0B-28296-1F12D545; Fri, 07 Nov 2014 19:48:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415389679!11189386!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6595 invoked from network); 7 Nov 2014 19:48:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 19:48:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7Jkofq005976
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 19:46:51 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7Jkms1003937
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Nov 2014 19:46:49 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7JkljA003901; Fri, 7 Nov 2014 19:46:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 11:46:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0EE581117C8; Fri,  7 Nov 2014 10:45:03 -0500 (EST)
Date: Fri, 7 Nov 2014 10:45:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141107154502.GC14076@laptop.dumpdata.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545B4D1D.4090000@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 10:27:41AM +0000, Julien Grall wrote:
> 
> 
> On 06/11/2014 10:11, Jan Beulich wrote:
> >>>>On 06.11.14 at 10:45, <julien.grall@linaro.org> wrote:
> >>Hi Jan,
> >>
> >>On 05/11/2014 17:15, Jan Beulich wrote:
> >>>>>>Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
> >>>>On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>It also needs Acks from Daniel and Jan.
> >>>>
> >>>>This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
> >>>>required. Would Ian C. ack be enough?
> >>>
> >>>Yes, it would.
> >>>
> >>>>Anyway, Jan do you have any objection on this patch?
> >>>
> >>>As said previously, I'm not particularly happy about it, but I also don't
> >>strongly
> >>>mind it going in in the current shape.
> >>
> >>May I ask what is wrong with the new approach to the a DOMCTL in this patch?
> >>
> >>The DOMCTL has been clearly identify as arm specific (there is "arm" in
> >>the name). Therefore it doesn't seem necessary to expose it for other
> >>architecture than ARM32 and ARM64.
> >
> >I didn't say there's anything actively wrong with it, all I said is that
> >I'm not particularly happy about it: Irrespective of its name it doesn't
> >look to be really arch-specific in the long run, plus it feels like the
> >data being set here should rather be specified right at domain
> >creation, or via a mechanism similar to x86'es HVM parameters (iirc
> >the value set here can't be changed once the domain got first
> >unpaused).
> 
> 
> TBH I choose this solution because I though you would be disagree with
> extending the domain create hypercall.
> 
> In long run, there will be more parameters such as the number of spis. All
> will be required at the same time. So the HVM parameters solution won't
> really help here.
> 
> However, I could give a look to extending the domain creation hypercall
> (xen_domctl_createdomain) to add arch specific field.
> 
> But I don't think it's Xen 4.5 material. So I would prefer to stay on this
> approach for this release because we'd like to have GICv3 guest support on
> Xen. Though I could rename the DOMCTL to DOMCTL_get_gic_version.

That is a bit unfortunate as it sounds like that for Xen 4.6 you will
then ditch this hypercall and focus on the new one? Won't this one then
be bitrotten?

> 
> Regards,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 19:48:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 19:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmpVr-0002vI-I7; Fri, 07 Nov 2014 19:48:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XmpVp-0002us-6w
	for xen-devel@lists.xenproject.org; Fri, 07 Nov 2014 19:48:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	44/FB-09842-0F12D545; Fri, 07 Nov 2014 19:48:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415389678!11962729!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25280 invoked from network); 7 Nov 2014 19:47:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 19:47:59 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA7JkpHb006001
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Nov 2014 19:46:52 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA7JkogE004023
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Nov 2014 19:46:50 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sA7Jkn4G023480; Fri, 7 Nov 2014 19:46:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Nov 2014 11:46:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4F00F111705; Fri,  7 Nov 2014 09:50:44 -0500 (EST)
Date: Fri, 7 Nov 2014 09:50:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141107145044.GD13259@laptop.dumpdata.com>
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
	<545CC988.5000000@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545CC988.5000000@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 01:30:48PM +0000, Julien Grall wrote:
> Hi all,
> 
> On 05/11/2014 13:04, Julien Grall wrote:
> >The vGIC will emulate the same version as the hardware. The toolstack has
> >to retrieve the version of the vGIC in order to be able to create the
> >corresponding device tree node.
> >
> >A new DOMCTL has been introduced for ARM to configure the domain. For now
> >it only allow the toolstack to retrieve the version of vGIC.
> >This DOMCTL will be extend later to let the user choose the version of the
> >emulated GIC.
> >
> >Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> >Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >Cc: Jan Beulich <jbeulich@suse.com>
> >Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> I forgot to keep the Ack from Daniel on v2:
> 
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00230.html

Right. If he is Ok then Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Regards,
> 
> >Cc: Wei Liu <wei.liu2@citrix.com>
> >
> >---
> >Stefano, I made one change in the guest memory layout, so I've dropped you
> >Reviewed-by.
> >
> >     Changes in v3:
> >         - Typo and update some comments
> >         - Coding style
> >         - Only reserve space for an 8 VCPUs redistributor in the guest
> >         memory layout
> >
> >     Changes in v2:
> >         - Use memcpu in xc_domain_configure
> >         - Rename the DOMCTL into domctl_arm_configuredomain
> >         - Drop arch_domain_create_pre. Will be reintroduced in Xen 4.6
> >         and fold the code in arch_domain_init_hw_description
> >         - Return -EOPNOTSUPP when the value of gic_version is not
> >         supported
> >
> >This patch is based on Vijay's GICv3 guest support patch [1] and my patch to
> >defer the initialization of the vGIC [2].
> >
> >Xen 4.5 has already support for the hardware GICv3. While it's possible to
> >boot and use DOM0, there is no guest support. The first version of this patch
> >has been sent a couple of months ago, but has never reached unstable for
> >various reasons (based on deferred series, lake of review at that time...).
> >Without it, platform with GICv3 support won't be able to boot any guest.
> >
> >The patch has been reworked to make it acceptable for Xen 4.5. Except the new
> >DOMCTL to retrieve the GIC version and one check. The code is purely GICv3.
> >
> >Features such as adding a new config option to let the user choose the GIC
> >version are deferred to Xen 4.6.
> >
> >It has been tested on both GICv2/GICv3 platform. And build tested for x86.
> >
> >[1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg00583.html
> >[2] https://patches.linaro.org/34664/
> >---
> >  tools/flask/policy/policy/modules/xen/xen.if |    2 +-
> >  tools/libxc/include/xenctrl.h                |    6 ++
> >  tools/libxc/xc_domain.c                      |   20 ++++++
> >  tools/libxl/libxl_arm.c                      |   95 ++++++++++++++++++++++++--
> >  xen/arch/arm/domctl.c                        |   35 ++++++++++
> >  xen/arch/arm/gic-v3.c                        |   16 ++++-
> >  xen/include/public/arch-arm.h                |   16 +++++
> >  xen/include/public/domctl.h                  |   17 +++++
> >  xen/xsm/flask/hooks.c                        |    3 +
> >  xen/xsm/flask/policy/access_vectors          |    2 +
> >  10 files changed, 204 insertions(+), 8 deletions(-)
> >
> >diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> >index 641c797..fa69c9d 100644
> >--- a/tools/flask/policy/policy/modules/xen/xen.if
> >+++ b/tools/flask/policy/policy/modules/xen/xen.if
> >@@ -49,7 +49,7 @@ define(`create_domain_common', `
> >  			getdomaininfo hypercall setvcpucontext setextvcpucontext
> >  			getscheduler getvcpuinfo getvcpuextstate getaddrsize
> >  			getaffinity setaffinity };
> >-	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
> >+	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
> >  	allow $1 $2:security check_context;
> >  	allow $1 $2:shadow enable;
> >  	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
> >diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> >index 564e187..45e282c 100644
> >--- a/tools/libxc/include/xenctrl.h
> >+++ b/tools/libxc/include/xenctrl.h
> >@@ -483,6 +483,12 @@ int xc_domain_create(xc_interface *xch,
> >                       uint32_t flags,
> >                       uint32_t *pdomid);
> >
> >+#if defined(__arm__) || defined(__aarch64__)
> >+typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
> >+
> >+int xc_domain_configure(xc_interface *xch, uint32_t domid,
> >+                        xc_domain_configuration_t *config);
> >+#endif
> >
> >  /* Functions to produce a dump of a given domain
> >   *  xc_domain_dumpcore - produces a dump to a specified file
> >diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> >index a9bcd4a..b071dea 100644
> >--- a/tools/libxc/xc_domain.c
> >+++ b/tools/libxc/xc_domain.c
> >@@ -48,6 +48,26 @@ int xc_domain_create(xc_interface *xch,
> >      return 0;
> >  }
> >
> >+#if defined(__arm__) || defined(__aarch64__)
> >+int xc_domain_configure(xc_interface *xch, uint32_t domid,
> >+                        xc_domain_configuration_t *config)
> >+{
> >+    int rc;
> >+    DECLARE_DOMCTL;
> >+
> >+    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
> >+    domctl.domain = (domid_t)domid;
> >+    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
> >+    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
> >+
> >+    rc = do_domctl(xch, &domctl);
> >+    if ( !rc )
> >+        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
> >+
> >+    return rc;
> >+}
> >+#endif
> >+
> >  int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
> >                           xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
> >  {
> >diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> >index a122e4a..448ac07 100644
> >--- a/tools/libxl/libxl_arm.c
> >+++ b/tools/libxl/libxl_arm.c
> >@@ -23,6 +23,18 @@
> >  #define DT_IRQ_TYPE_LEVEL_HIGH     0x00000004
> >  #define DT_IRQ_TYPE_LEVEL_LOW      0x00000008
> >
> >+static const char *gicv_to_string(uint8_t gic_version)
> >+{
> >+    switch (gic_version) {
> >+    case XEN_DOMCTL_CONFIG_GIC_V2:
> >+        return "V2";
> >+    case XEN_DOMCTL_CONFIG_GIC_V3:
> >+        return "V3";
> >+    default:
> >+        return "unknown";
> >+    }
> >+}
> >+
> >  int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> >                                uint32_t domid)
> >  {
> >@@ -307,9 +319,9 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
> >      return 0;
> >  }
> >
> >-static int make_intc_node(libxl__gc *gc, void *fdt,
> >-                          uint64_t gicd_base, uint64_t gicd_size,
> >-                          uint64_t gicc_base, uint64_t gicc_size)
> >+static int make_gicv2_node(libxl__gc *gc, void *fdt,
> >+                           uint64_t gicd_base, uint64_t gicd_size,
> >+                           uint64_t gicc_base, uint64_t gicc_size)
> >  {
> >      int res;
> >      const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> >@@ -350,6 +362,56 @@ static int make_intc_node(libxl__gc *gc, void *fdt,
> >      return 0;
> >  }
> >
> >+static int make_gicv3_node(libxl__gc *gc, void *fdt)
> >+{
> >+    int res;
> >+    const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
> >+    const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
> >+    const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
> >+    const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
> >+    const char *name = GCSPRINTF("interrupt-controller@%"PRIx64, gicd_base);
> >+
> >+    res = fdt_begin_node(fdt, name);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_compat(gc, fdt, 1, "arm,gic-v3");
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "#interrupt-cells", 3);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "#address-cells", 0);
> >+    if (res) return res;
> >+
> >+    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "redistributor-stride",
> >+                            GUEST_GICV3_RDIST_STRIDE);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "#redistributor-regions",
> >+                            GUEST_GICV3_RDIST_REGIONS);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> >+                            2,
> >+                            gicd_base, gicd_size,
> >+                            gicr0_base, gicr0_size);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "linux,phandle", PHANDLE_GIC);
> >+    if (res) return res;
> >+
> >+    res = fdt_property_cell(fdt, "phandle", PHANDLE_GIC);
> >+    if (res) return res;
> >+
> >+    res = fdt_end_node(fdt);
> >+    if (res) return res;
> >+
> >+    return 0;
> >+}
> >+
> >  static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info *ainfo)
> >  {
> >      int res;
> >@@ -456,6 +518,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> >                                             libxl_domain_build_info *info,
> >                                             struct xc_dom_image *dom)
> >  {
> >+    xc_domain_configuration_t config;
> >      void *fdt = NULL;
> >      int rc, res;
> >      size_t fdt_size = 0;
> >@@ -471,8 +534,16 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> >      ainfo = get_arch_info(gc, dom);
> >      if (ainfo == NULL) return ERROR_FAIL;
> >
> >+    LOG(DEBUG, "configure the domain");
> >+    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
> >+    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
> >+        LOG(ERROR, "couldn't configure the domain");
> >+        return ERROR_FAIL;
> >+    }
> >+
> >      LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
> >          vers->xen_version_major, vers->xen_version_minor);
> >+    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
> >
> >  /*
> >   * Call "call" handling FDR_ERR_*. Will either:
> >@@ -520,9 +591,21 @@ next_resize:
> >          FDT( make_psci_node(gc, fdt) );
> >
> >          FDT( make_memory_nodes(gc, fdt, dom) );
> >-        FDT( make_intc_node(gc, fdt,
> >-                            GUEST_GICD_BASE, GUEST_GICD_SIZE,
> >-                            GUEST_GICC_BASE, GUEST_GICD_SIZE) );
> >+
> >+        switch (config.gic_version) {
> >+        case XEN_DOMCTL_CONFIG_GIC_V2:
> >+            FDT( make_gicv2_node(gc, fdt,
> >+                                 GUEST_GICD_BASE, GUEST_GICD_SIZE,
> >+                                 GUEST_GICC_BASE, GUEST_GICC_SIZE) );
> >+            break;
> >+        case XEN_DOMCTL_CONFIG_GIC_V3:
> >+            FDT( make_gicv3_node(gc, fdt) );
> >+            break;
> >+        default:
> >+            LOG(ERROR, "Unknown GIC version %d", config.gic_version);
> >+            rc = ERROR_FAIL;
> >+            goto out;
> >+        }
> >
> >          FDT( make_timer_node(gc, fdt, ainfo) );
> >          FDT( make_hypervisor_node(gc, fdt, vers) );
> >diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> >index 45974e7..d246e84 100644
> >--- a/xen/arch/arm/domctl.c
> >+++ b/xen/arch/arm/domctl.c
> >@@ -10,6 +10,8 @@
> >  #include <xen/errno.h>
> >  #include <xen/sched.h>
> >  #include <xen/hypercall.h>
> >+#include <asm/gic.h>
> >+#include <xen/guest_access.h>
> >  #include <public/domctl.h>
> >
> >  long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >@@ -30,6 +32,39 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >
> >          return p2m_cache_flush(d, s, e);
> >      }
> >+    case XEN_DOMCTL_arm_configure_domain:
> >+    {
> >+        uint8_t gic_version;
> >+
> >+        /*
> >+         * Currently the vGIC is emulating the same version of the
> >+         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
> >+         * is allowed. The DOMCTL will return the actual version of the
> >+         * GIC.
> >+         */
> >+        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
> >+            return -EOPNOTSUPP;
> >+
> >+        switch ( gic_hw_version() )
> >+        {
> >+        case GIC_V3:
> >+            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> >+            break;
> >+        case GIC_V2:
> >+            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> >+            break;
> >+        default:
> >+            BUG();
> >+        }
> >+
> >+        domctl->u.configuredomain.gic_version = gic_version;
> >+
> >+        /* TODO: Make the copy generic for all ARCH domctl */
> >+        if ( __copy_to_guest(u_domctl, domctl, 1) )
> >+            return -EFAULT;
> >+
> >+        return 0;
> >+    }
> >
> >      default:
> >          return subarch_do_domctl(domctl, d, u_domctl);
> >diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> >index 91161a2..076aa62 100644
> >--- a/xen/arch/arm/gic-v3.c
> >+++ b/xen/arch/arm/gic-v3.c
> >@@ -906,7 +906,21 @@ static int gicv_v3_init(struct domain *d)
> >          d->arch.vgic.rdist_count = gicv3.rdist_count;
> >      }
> >      else
> >-        d->arch.vgic.dbase = GUEST_GICD_BASE;
> >+    {
> >+        d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
> >+        d->arch.vgic.dbase_size = GUEST_GICV3_GICD_SIZE;
> >+
> >+        /* XXX: Only one Re-distributor region mapped for the guest */
> >+        BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
> >+
> >+        d->arch.vgic.rdist_count = GUEST_GICV3_RDIST_REGIONS;
> >+        d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
> >+
> >+        /* The first redistributor should contain enough space for all CPUs */
> >+        BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < MAX_VIRT_CPUS);
> >+        d->arch.vgic.rbase[0] = GUEST_GICV3_GICR0_BASE;
> >+        d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
> >+    }
> >
> >      d->arch.vgic.nr_lines = 0;
> >
> >diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> >index eecc561..72d641f 100644
> >--- a/xen/include/public/arch-arm.h
> >+++ b/xen/include/public/arch-arm.h
> >@@ -373,11 +373,27 @@ typedef uint64_t xen_callback_t;
> >   */
> >
> >  /* Physical Address Space */
> >+
> >+/* vGIC mappings: Only one set of mapping is used by the guest.
> >+ * Therefore they can overlap.
> >+ */
> >+
> >+/* vGIC v2 mappings */
> >  #define GUEST_GICD_BASE   0x03001000ULL
> >  #define GUEST_GICD_SIZE   0x00001000ULL
> >  #define GUEST_GICC_BASE   0x03002000ULL
> >  #define GUEST_GICC_SIZE   0x00000100ULL
> >
> >+/* vGIC v3 mappings */
> >+#define GUEST_GICV3_GICD_BASE      0x03001000ULL
> >+#define GUEST_GICV3_GICD_SIZE      0x00010000ULL
> >+
> >+#define GUEST_GICV3_RDIST_STRIDE   0x20000ULL
> >+#define GUEST_GICV3_RDIST_REGIONS  1
> >+
> >+#define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU7 */
> >+#define GUEST_GICV3_GICR0_SIZE     0x00100000ULL
> >+
> >  /* 16MB == 4096 pages reserved for guest to use as a region to map its
> >   * grant table in.
> >   */
> >diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> >index 58b19e7..8da204e 100644
> >--- a/xen/include/public/domctl.h
> >+++ b/xen/include/public/domctl.h
> >@@ -68,6 +68,19 @@ struct xen_domctl_createdomain {
> >  typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
> >
> >+#if defined(__arm__) || defined(__aarch64__)
> >+#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
> >+#define XEN_DOMCTL_CONFIG_GIC_V2        1
> >+#define XEN_DOMCTL_CONFIG_GIC_V3        2
> >+/* XEN_DOMCTL_configure_domain */
> >+struct xen_domctl_arm_configuredomain {
> >+    /* IN/OUT parameters */
> >+    uint8_t gic_version;
> >+};
> >+typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
> >+DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
> >+#endif
> >+
> >  /* XEN_DOMCTL_getdomaininfo */
> >  struct xen_domctl_getdomaininfo {
> >      /* OUT variables. */
> >@@ -1056,6 +1069,7 @@ struct xen_domctl {
> >  #define XEN_DOMCTL_set_vcpu_msrs                 73
> >  #define XEN_DOMCTL_setvnumainfo                  74
> >  #define XEN_DOMCTL_psr_cmt_op                    75
> >+#define XEN_DOMCTL_arm_configure_domain          76
> >  #define XEN_DOMCTL_gdbsx_guestmemio            1000
> >  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
> >  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> >@@ -1064,6 +1078,9 @@ struct xen_domctl {
> >      domid_t  domain;
> >      union {
> >          struct xen_domctl_createdomain      createdomain;
> >+#if defined(__arm__) || defined(__aarch64__)
> >+        struct xen_domctl_arm_configuredomain configuredomain;
> >+#endif
> >          struct xen_domctl_getdomaininfo     getdomaininfo;
> >          struct xen_domctl_getmemlist        getmemlist;
> >          struct xen_domctl_getpageframeinfo  getpageframeinfo;
> >diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> >index 6d0fe72..846cf88 100644
> >--- a/xen/xsm/flask/hooks.c
> >+++ b/xen/xsm/flask/hooks.c
> >@@ -727,6 +727,9 @@ static int flask_domctl(struct domain *d, int cmd)
> >      case XEN_DOMCTL_psr_cmt_op:
> >          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
> >
> >+    case XEN_DOMCTL_configure_domain:
> >+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
> >+
> >      default:
> >          printk("flask_domctl: Unknown op %d\n", cmd);
> >          return -EPERM;
> >diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> >index de0c707..bfe2fa5 100644
> >--- a/xen/xsm/flask/policy/access_vectors
> >+++ b/xen/xsm/flask/policy/access_vectors
> >@@ -216,6 +216,8 @@ class domain2
> >      get_vnumainfo
> >  # XEN_DOMCTL_psr_cmt_op
> >      psr_cmt_op
> >+# XEN_DOMCTL_configure_domain
> >+    configure_domain
> >  }
> >
> >  # Similar to class domain, but primarily contains domctls related to HVM domains
> >
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 22:10:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 22: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.xen.org>)
	id 1XmrjZ-0004AB-Hq; Fri, 07 Nov 2014 22:10: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@citrix.com>) id 1XmrjX-0004A6-IJ
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 22:10:19 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	64/17-02954-A434D545; Fri, 07 Nov 2014 22:10:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415398215!12170702!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6196 invoked from network); 7 Nov 2014 22:10:17 -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;
	7 Nov 2014 22:10:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,335,1413244800"; d="scan'208";a="190737908"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 17:10:13 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmrjQ-0004Pr-SW;
	Fri, 07 Nov 2014 22:10:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmrjQ-0001Le-NB;
	Fri, 07 Nov 2014 22:10:12 +0000
Date: Fri, 7 Nov 2014 22:10:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31430-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31430: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31430 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31430/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Fri Nov 07 22:10:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 22: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.xen.org>)
	id 1XmrjZ-0004AB-Hq; Fri, 07 Nov 2014 22:10: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@citrix.com>) id 1XmrjX-0004A6-IJ
	for xen-devel@lists.xensource.com; Fri, 07 Nov 2014 22:10:19 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	64/17-02954-A434D545; Fri, 07 Nov 2014 22:10:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415398215!12170702!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6196 invoked from network); 7 Nov 2014 22:10:17 -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;
	7 Nov 2014 22:10:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,335,1413244800"; d="scan'208";a="190737908"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 17:10:13 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmrjQ-0004Pr-SW;
	Fri, 07 Nov 2014 22:10:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmrjQ-0001Le-NB;
	Fri, 07 Nov 2014 22:10:12 +0000
Date: Fri, 7 Nov 2014 22:10:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31430-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31430: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31430 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31430/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Fri Nov 07 22:14:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 22:14:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmrnY-0004JQ-I9; Fri, 07 Nov 2014 22:14:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XmrnW-0004JH-Ln
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 22:14:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C0/D8-09936-2444D545; Fri, 07 Nov 2014 22:14:26 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415398463!12292040!1
X-Originating-IP: [209.85.192.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7384 invoked from network); 7 Nov 2014 22:14:24 -0000
Received: from mail-pd0-f178.google.com (HELO mail-pd0-f178.google.com)
	(209.85.192.178)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 22:14:24 -0000
Received: by mail-pd0-f178.google.com with SMTP id fp1so4054743pdb.23
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 14:14:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=zt44pGRdZUlW3AXLZP3ch0hpKb9q3kAv4AO/gC4pzOk=;
	b=kckylDBlVLiZUZB9AcftKfeEaXsV9caJO5k3KxHfahEHJOrezbh1ZIp1wtd+k3p21O
	Ufx5Je4IHZNmET0o/E9KUExi9QcTUmEH+6TK+W9nOy5hwXFZNEWNdafL4x6UwZrSYXzp
	O1e0Shp+19tAhjM9BZKvq6KEYWK8DyH9SR8JYenHdDM0zX1h+anZZRCrdO9utv+4U1gY
	z3B1i4VSI9/KqWr4CEU3+D48NfKGs8hBxiYBrGB81ztw6Loz7EMIP0h4LIJmn6wxtP0t
	oysGN7yrhJJ6VMzvpApUBH8ilaVXLz44pSeoYtuNcQMe2s9TQxem/gmWQkld6FpldeF7
	POmw==
X-Gm-Message-State: ALoCoQmhp+A575f0YpDVHr0iqwiEFHDs9DxTLW9f4BiIvwXPGSJUUsvLtgdnTaVyvwPcOhIAbyoP
X-Received: by 10.70.38.134 with SMTP id g6mr15399130pdk.124.1415398463041;
	Fri, 07 Nov 2014 14:14:23 -0800 (PST)
Received: from rfranz-t520.local (c-24-10-97-91.hsd1.ca.comcast.net.
	[24.10.97.91])
	by mx.google.com with ESMTPSA id mz5sm5740250pdb.35.2014.11.07.14.14.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 07 Nov 2014 14:14:22 -0800 (PST)
From: Roy Franz <roy.franz@linaro.org>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com, tim@xen.org, jbeulich@suse.com
Date: Fri,  7 Nov 2014 14:14:16 -0800
Message-Id: <1415398456-27423-1-git-send-email-roy.franz@linaro.org>
X-Mailer: git-send-email 2.1.1
Cc: Roy Franz <roy.franz@linaro.org>, daniel.kiper@oracle.com,
	fu.wei@linaro.org
Subject: [Xen-devel] [PATCH for-4.5 v3] EFI: Ignore EFI commandline,
	skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 EFI code to completely ignore the EFI comnandline when booted from GRUB.
Previusly it was parsed of EFI boot specific options, but these aren't used
when booted from GRUB.

Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
code does some console and video initialization to support native EFI boot from
the EFI boot manager or EFI shell.  This initlization should not be done when
booted using GRUB.

Update EFI documentation to indicate that it describes EFI native boot, and
does not apply at all when Xen is booted using GRUB.

Signed-off-by: Roy Franz <roy.franz@linaro.org>
---
---
This patch implements what I understand to be the desired behavior when booting
an EFI Xen image via GRUB based on the thread last week.  The EFI command line
is not used, and the Xen commandline comes via the multiboot protocol (and
in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
GRUB EFI boot cases into alignment in not using the EFI commandline.

The current state of the arm64 code takes the Xen commandline from the FDT,
but still looks in the EFI commandline for EFI boot specific options.  If
unexpected options are passed in the EFI commandline, it will generate
"unrecognized option" ouput for all unexpected options.

I think this should be considered for 4.5.

Changes since v2:
* Rephrased documentation update to avoid "multi-boot aware bootloader", as this
  is a more general concept that implies things not required for this patch.
Changes from v1:
* Fixed style, and removed blank line changes
* Reviewed scope of variables now that more code is in if ( use_cfg_file ) block
  

 docs/misc/efi.markdown |   5 ++
 xen/common/efi/boot.c  | 240 +++++++++++++++++++++++++------------------------
 2 files changed, 128 insertions(+), 117 deletions(-)

diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
index 5e48aa3..c3a0b0a 100644
--- a/docs/misc/efi.markdown
+++ b/docs/misc/efi.markdown
@@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
 (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
 try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
 order.) One can override this with a command line option (`-cfg=<filename>`).
+This configuration file and EFI commandline are only used for booting directly
+from EFI firmware, or when using an simple EFI application loader. When booting
+using a bootloader such as GRUB that loads the dom0 kernel and any other
+required modules, the EFI commandline is ignored.  In this case all information
+is passed to Xen using the multiboot2 protocol (x86), or using a FDT (arm64).
 
 The configuration file consists of one or more sections headed by a section
 name enclosed in square brackets, with individual values specified in each
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 4257341..471dff7 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -697,7 +697,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     EFI_STATUS status;
     unsigned int i, argc;
     CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
-    UINTN cols, rows, depth, size, map_key, info_size, gop_mode = ~0;
+    UINTN map_key, info_size, gop_mode = ~0;
     EFI_HANDLE *handles = NULL;
     EFI_SHIM_LOCK_PROTOCOL *shim_lock;
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
@@ -705,6 +705,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     union string section = { NULL }, name;
     bool_t base_video = 0;
     char *option_str;
+    bool_t use_cfg_file;
 
     efi_ih = ImageHandle;
     efi_bs = SystemTable->BootServices;
@@ -717,6 +718,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     StdOut = SystemTable->ConOut;
     StdErr = SystemTable->StdErr ?: StdOut;
+    use_cfg_file = efi_arch_use_config_file(SystemTable);
 
     status = efi_bs->HandleProtocol(ImageHandle, &loaded_image_guid,
                                     (void **)&loaded_image);
@@ -725,67 +727,71 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_load_addr_check(loaded_image);
 
-    argc = get_argv(0, NULL, loaded_image->LoadOptions,
-                    loaded_image->LoadOptionsSize, NULL);
-    if ( argc > 0 &&
-         efi_bs->AllocatePool(EfiLoaderData,
-                              (argc + 1) * sizeof(*argv) +
-                                  loaded_image->LoadOptionsSize,
-                              (void **)&argv) == EFI_SUCCESS )
-        get_argv(argc, argv, loaded_image->LoadOptions,
-                 loaded_image->LoadOptionsSize, &options);
-    else
-        argc = 0;
-    for ( i = 1; i < argc; ++i )
+    if ( use_cfg_file )
     {
-        CHAR16 *ptr = argv[i];
-
-        if ( !ptr )
-            break;
-        if ( *ptr == L'/' || *ptr == L'-' )
+        argc = get_argv(0, NULL, loaded_image->LoadOptions,
+                        loaded_image->LoadOptionsSize, NULL);
+        if ( argc > 0 &&
+             efi_bs->AllocatePool(EfiLoaderData,
+                                  (argc + 1) * sizeof(*argv) +
+                                      loaded_image->LoadOptionsSize,
+                                  (void **)&argv) == EFI_SUCCESS )
+            get_argv(argc, argv, loaded_image->LoadOptions,
+                     loaded_image->LoadOptionsSize, &options);
+        else
+            argc = 0;
+        for ( i = 1; i < argc; ++i )
         {
-            if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
-                base_video = 1;
-            else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
-                cfg_file_name = ptr + 5;
-            else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
-                cfg_file_name = argv[++i];
-            else if ( wstrcmp(ptr + 1, L"help") == 0 ||
-                      (ptr[1] == L'?' && !ptr[2]) )
+            CHAR16 *ptr = argv[i];
+
+            if ( !ptr )
+                break;
+            if ( *ptr == L'/' || *ptr == L'-' )
             {
-                PrintStr(L"Xen EFI Loader options:\r\n");
-                PrintStr(L"-basevideo   retain current video mode\r\n");
-                PrintStr(L"-cfg=<file>  specify configuration file\r\n");
-                PrintStr(L"-help, -?    display this help\r\n");
-                blexit(NULL);
+                if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
+                    base_video = 1;
+                else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
+                    cfg_file_name = ptr + 5;
+                else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
+                    cfg_file_name = argv[++i];
+                else if ( wstrcmp(ptr + 1, L"help") == 0 ||
+                          (ptr[1] == L'?' && !ptr[2]) )
+                {
+                    PrintStr(L"Xen EFI Loader options:\r\n");
+                    PrintStr(L"-basevideo   retain current video mode\r\n");
+                    PrintStr(L"-cfg=<file>  specify configuration file\r\n");
+                    PrintStr(L"-help, -?    display this help\r\n");
+                    blexit(NULL);
+                }
+                else
+                {
+                    PrintStr(L"WARNING: Unknown command line option '");
+                    PrintStr(ptr);
+                    PrintStr(L"' ignored\r\n");
+                }
             }
             else
-            {
-                PrintStr(L"WARNING: Unknown command line option '");
-                PrintStr(ptr);
-                PrintStr(L"' ignored\r\n");
-            }
+                section.w = ptr;
         }
-        else
-            section.w = ptr;
-    }
 
-    if ( !base_video )
-    {
-        unsigned int best;
-
-        for ( i = 0, size = 0, best = StdOut->Mode->Mode;
-              i < StdOut->Mode->MaxMode; ++i )
+        if ( !base_video )
         {
-            if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
-                 cols * rows > size )
+            unsigned int best;
+            UINTN cols, rows, size;
+
+            for ( i = 0, size = 0, best = StdOut->Mode->Mode;
+                  i < StdOut->Mode->MaxMode; ++i )
             {
-                size = cols * rows;
-                best = i;
+                if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
+                     cols * rows > size )
+                {
+                    size = cols * rows;
+                    best = i;
+                }
             }
+            if ( best != StdOut->Mode->Mode )
+                StdOut->SetMode(StdOut, best);
         }
-        if ( best != StdOut->Mode->Mode )
-            StdOut->SetMode(StdOut, best);
     }
 
     PrintStr(L"Xen " __stringify(XEN_VERSION) "." __stringify(XEN_SUBVERSION)
@@ -793,37 +799,38 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_relocate_image(0);
 
-    if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
-                           &cols, &rows) == EFI_SUCCESS )
-        efi_arch_console_init(cols, rows);
-
-    size = 0;
-    status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
-    if ( status == EFI_BUFFER_TOO_SMALL )
-        status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
-    if ( !EFI_ERROR(status) )
-        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
-                                      handles);
-    if ( EFI_ERROR(status) )
-        size = 0;
-    for ( i = 0; i < size / sizeof(*handles); ++i )
-    {
-        status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
-        if ( EFI_ERROR(status) )
-            continue;
-        status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
-        if ( !EFI_ERROR(status) )
-            break;
-    }
-    if ( handles )
-        efi_bs->FreePool(handles);
-    if ( EFI_ERROR(status) )
-        gop = NULL;
-
-    cols = rows = depth = 0;
-    if ( efi_arch_use_config_file(SystemTable) )
+    if ( use_cfg_file )
     {
         EFI_FILE_HANDLE dir_handle;
+        UINTN depth, cols, rows, size;
+
+        size = cols = rows = depth = 0;
+
+        if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
+                               &cols, &rows) == EFI_SUCCESS )
+            efi_arch_console_init(cols, rows);
+
+        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
+        if ( status == EFI_BUFFER_TOO_SMALL )
+            status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
+        if ( !EFI_ERROR(status) )
+            status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
+                                          handles);
+        if ( EFI_ERROR(status) )
+            size = 0;
+        for ( i = 0; i < size / sizeof(*handles); ++i )
+        {
+            status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
+            if ( EFI_ERROR(status) )
+                continue;
+            status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
+            if ( !EFI_ERROR(status) )
+                break;
+        }
+        if ( handles )
+            efi_bs->FreePool(handles);
+        if ( EFI_ERROR(status) )
+            gop = NULL;
 
         /* Get the file system interface. */
         dir_handle = get_parent_handle(loaded_image, &file_name);
@@ -931,45 +938,44 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
         dir_handle->Close(dir_handle);
 
-    }
-
-    if ( gop && !base_video )
-    {
-        for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
+        if ( gop && !base_video )
         {
-            unsigned int bpp = 0;
-
-            status = gop->QueryMode(gop, i, &info_size, &mode_info);
-            if ( EFI_ERROR(status) )
-                continue;
-            switch ( mode_info->PixelFormat )
-            {
-            case PixelBitMask:
-                bpp = hweight32(mode_info->PixelInformation.RedMask |
-                                mode_info->PixelInformation.GreenMask |
-                                mode_info->PixelInformation.BlueMask);
-                break;
-            case PixelRedGreenBlueReserved8BitPerColor:
-            case PixelBlueGreenRedReserved8BitPerColor:
-                bpp = 24;
-                break;
-            default:
-                continue;
-            }
-            if ( cols == mode_info->HorizontalResolution &&
-                 rows == mode_info->VerticalResolution &&
-                 (!depth || bpp == depth) )
+            for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
             {
-                gop_mode = i;
-                break;
-            }
-            if ( !cols && !rows &&
-                 mode_info->HorizontalResolution *
-                 mode_info->VerticalResolution > size )
-            {
-                size = mode_info->HorizontalResolution *
-                       mode_info->VerticalResolution;
-                gop_mode = i;
+                unsigned int bpp = 0;
+
+                status = gop->QueryMode(gop, i, &info_size, &mode_info);
+                if ( EFI_ERROR(status) )
+                    continue;
+                switch ( mode_info->PixelFormat )
+                {
+                case PixelBitMask:
+                    bpp = hweight32(mode_info->PixelInformation.RedMask |
+                                    mode_info->PixelInformation.GreenMask |
+                                    mode_info->PixelInformation.BlueMask);
+                    break;
+                case PixelRedGreenBlueReserved8BitPerColor:
+                case PixelBlueGreenRedReserved8BitPerColor:
+                    bpp = 24;
+                    break;
+                default:
+                    continue;
+                }
+                if ( cols == mode_info->HorizontalResolution &&
+                     rows == mode_info->VerticalResolution &&
+                     (!depth || bpp == depth) )
+                {
+                    gop_mode = i;
+                    break;
+                }
+                if ( !cols && !rows &&
+                     mode_info->HorizontalResolution *
+                     mode_info->VerticalResolution > size )
+                {
+                    size = mode_info->HorizontalResolution *
+                           mode_info->VerticalResolution;
+                    gop_mode = i;
+                }
             }
         }
     }
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 22:14:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 22:14:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmrnY-0004JQ-I9; Fri, 07 Nov 2014 22:14:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XmrnW-0004JH-Ln
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 22:14:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C0/D8-09936-2444D545; Fri, 07 Nov 2014 22:14:26 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415398463!12292040!1
X-Originating-IP: [209.85.192.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7384 invoked from network); 7 Nov 2014 22:14:24 -0000
Received: from mail-pd0-f178.google.com (HELO mail-pd0-f178.google.com)
	(209.85.192.178)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Nov 2014 22:14:24 -0000
Received: by mail-pd0-f178.google.com with SMTP id fp1so4054743pdb.23
	for <xen-devel@lists.xen.org>; Fri, 07 Nov 2014 14:14:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=zt44pGRdZUlW3AXLZP3ch0hpKb9q3kAv4AO/gC4pzOk=;
	b=kckylDBlVLiZUZB9AcftKfeEaXsV9caJO5k3KxHfahEHJOrezbh1ZIp1wtd+k3p21O
	Ufx5Je4IHZNmET0o/E9KUExi9QcTUmEH+6TK+W9nOy5hwXFZNEWNdafL4x6UwZrSYXzp
	O1e0Shp+19tAhjM9BZKvq6KEYWK8DyH9SR8JYenHdDM0zX1h+anZZRCrdO9utv+4U1gY
	z3B1i4VSI9/KqWr4CEU3+D48NfKGs8hBxiYBrGB81ztw6Loz7EMIP0h4LIJmn6wxtP0t
	oysGN7yrhJJ6VMzvpApUBH8ilaVXLz44pSeoYtuNcQMe2s9TQxem/gmWQkld6FpldeF7
	POmw==
X-Gm-Message-State: ALoCoQmhp+A575f0YpDVHr0iqwiEFHDs9DxTLW9f4BiIvwXPGSJUUsvLtgdnTaVyvwPcOhIAbyoP
X-Received: by 10.70.38.134 with SMTP id g6mr15399130pdk.124.1415398463041;
	Fri, 07 Nov 2014 14:14:23 -0800 (PST)
Received: from rfranz-t520.local (c-24-10-97-91.hsd1.ca.comcast.net.
	[24.10.97.91])
	by mx.google.com with ESMTPSA id mz5sm5740250pdb.35.2014.11.07.14.14.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 07 Nov 2014 14:14:22 -0800 (PST)
From: Roy Franz <roy.franz@linaro.org>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com, tim@xen.org, jbeulich@suse.com
Date: Fri,  7 Nov 2014 14:14:16 -0800
Message-Id: <1415398456-27423-1-git-send-email-roy.franz@linaro.org>
X-Mailer: git-send-email 2.1.1
Cc: Roy Franz <roy.franz@linaro.org>, daniel.kiper@oracle.com,
	fu.wei@linaro.org
Subject: [Xen-devel] [PATCH for-4.5 v3] EFI: Ignore EFI commandline,
	skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 EFI code to completely ignore the EFI comnandline when booted from GRUB.
Previusly it was parsed of EFI boot specific options, but these aren't used
when booted from GRUB.

Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
code does some console and video initialization to support native EFI boot from
the EFI boot manager or EFI shell.  This initlization should not be done when
booted using GRUB.

Update EFI documentation to indicate that it describes EFI native boot, and
does not apply at all when Xen is booted using GRUB.

Signed-off-by: Roy Franz <roy.franz@linaro.org>
---
---
This patch implements what I understand to be the desired behavior when booting
an EFI Xen image via GRUB based on the thread last week.  The EFI command line
is not used, and the Xen commandline comes via the multiboot protocol (and
in the ARM case the multiboot FDT bindings).  This brings the x86 and arm64
GRUB EFI boot cases into alignment in not using the EFI commandline.

The current state of the arm64 code takes the Xen commandline from the FDT,
but still looks in the EFI commandline for EFI boot specific options.  If
unexpected options are passed in the EFI commandline, it will generate
"unrecognized option" ouput for all unexpected options.

I think this should be considered for 4.5.

Changes since v2:
* Rephrased documentation update to avoid "multi-boot aware bootloader", as this
  is a more general concept that implies things not required for this patch.
Changes from v1:
* Fixed style, and removed blank line changes
* Reviewed scope of variables now that more code is in if ( use_cfg_file ) block
  

 docs/misc/efi.markdown |   5 ++
 xen/common/efi/boot.c  | 240 +++++++++++++++++++++++++------------------------
 2 files changed, 128 insertions(+), 117 deletions(-)

diff --git a/docs/misc/efi.markdown b/docs/misc/efi.markdown
index 5e48aa3..c3a0b0a 100644
--- a/docs/misc/efi.markdown
+++ b/docs/misc/efi.markdown
@@ -29,6 +29,11 @@ separators will be tried) to be present in the same directory as the binary.
 (To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
 try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
 order.) One can override this with a command line option (`-cfg=<filename>`).
+This configuration file and EFI commandline are only used for booting directly
+from EFI firmware, or when using an simple EFI application loader. When booting
+using a bootloader such as GRUB that loads the dom0 kernel and any other
+required modules, the EFI commandline is ignored.  In this case all information
+is passed to Xen using the multiboot2 protocol (x86), or using a FDT (arm64).
 
 The configuration file consists of one or more sections headed by a section
 name enclosed in square brackets, with individual values specified in each
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 4257341..471dff7 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -697,7 +697,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     EFI_STATUS status;
     unsigned int i, argc;
     CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
-    UINTN cols, rows, depth, size, map_key, info_size, gop_mode = ~0;
+    UINTN map_key, info_size, gop_mode = ~0;
     EFI_HANDLE *handles = NULL;
     EFI_SHIM_LOCK_PROTOCOL *shim_lock;
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
@@ -705,6 +705,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     union string section = { NULL }, name;
     bool_t base_video = 0;
     char *option_str;
+    bool_t use_cfg_file;
 
     efi_ih = ImageHandle;
     efi_bs = SystemTable->BootServices;
@@ -717,6 +718,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     StdOut = SystemTable->ConOut;
     StdErr = SystemTable->StdErr ?: StdOut;
+    use_cfg_file = efi_arch_use_config_file(SystemTable);
 
     status = efi_bs->HandleProtocol(ImageHandle, &loaded_image_guid,
                                     (void **)&loaded_image);
@@ -725,67 +727,71 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_load_addr_check(loaded_image);
 
-    argc = get_argv(0, NULL, loaded_image->LoadOptions,
-                    loaded_image->LoadOptionsSize, NULL);
-    if ( argc > 0 &&
-         efi_bs->AllocatePool(EfiLoaderData,
-                              (argc + 1) * sizeof(*argv) +
-                                  loaded_image->LoadOptionsSize,
-                              (void **)&argv) == EFI_SUCCESS )
-        get_argv(argc, argv, loaded_image->LoadOptions,
-                 loaded_image->LoadOptionsSize, &options);
-    else
-        argc = 0;
-    for ( i = 1; i < argc; ++i )
+    if ( use_cfg_file )
     {
-        CHAR16 *ptr = argv[i];
-
-        if ( !ptr )
-            break;
-        if ( *ptr == L'/' || *ptr == L'-' )
+        argc = get_argv(0, NULL, loaded_image->LoadOptions,
+                        loaded_image->LoadOptionsSize, NULL);
+        if ( argc > 0 &&
+             efi_bs->AllocatePool(EfiLoaderData,
+                                  (argc + 1) * sizeof(*argv) +
+                                      loaded_image->LoadOptionsSize,
+                                  (void **)&argv) == EFI_SUCCESS )
+            get_argv(argc, argv, loaded_image->LoadOptions,
+                     loaded_image->LoadOptionsSize, &options);
+        else
+            argc = 0;
+        for ( i = 1; i < argc; ++i )
         {
-            if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
-                base_video = 1;
-            else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
-                cfg_file_name = ptr + 5;
-            else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
-                cfg_file_name = argv[++i];
-            else if ( wstrcmp(ptr + 1, L"help") == 0 ||
-                      (ptr[1] == L'?' && !ptr[2]) )
+            CHAR16 *ptr = argv[i];
+
+            if ( !ptr )
+                break;
+            if ( *ptr == L'/' || *ptr == L'-' )
             {
-                PrintStr(L"Xen EFI Loader options:\r\n");
-                PrintStr(L"-basevideo   retain current video mode\r\n");
-                PrintStr(L"-cfg=<file>  specify configuration file\r\n");
-                PrintStr(L"-help, -?    display this help\r\n");
-                blexit(NULL);
+                if ( wstrcmp(ptr + 1, L"basevideo") == 0 )
+                    base_video = 1;
+                else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
+                    cfg_file_name = ptr + 5;
+                else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
+                    cfg_file_name = argv[++i];
+                else if ( wstrcmp(ptr + 1, L"help") == 0 ||
+                          (ptr[1] == L'?' && !ptr[2]) )
+                {
+                    PrintStr(L"Xen EFI Loader options:\r\n");
+                    PrintStr(L"-basevideo   retain current video mode\r\n");
+                    PrintStr(L"-cfg=<file>  specify configuration file\r\n");
+                    PrintStr(L"-help, -?    display this help\r\n");
+                    blexit(NULL);
+                }
+                else
+                {
+                    PrintStr(L"WARNING: Unknown command line option '");
+                    PrintStr(ptr);
+                    PrintStr(L"' ignored\r\n");
+                }
             }
             else
-            {
-                PrintStr(L"WARNING: Unknown command line option '");
-                PrintStr(ptr);
-                PrintStr(L"' ignored\r\n");
-            }
+                section.w = ptr;
         }
-        else
-            section.w = ptr;
-    }
 
-    if ( !base_video )
-    {
-        unsigned int best;
-
-        for ( i = 0, size = 0, best = StdOut->Mode->Mode;
-              i < StdOut->Mode->MaxMode; ++i )
+        if ( !base_video )
         {
-            if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
-                 cols * rows > size )
+            unsigned int best;
+            UINTN cols, rows, size;
+
+            for ( i = 0, size = 0, best = StdOut->Mode->Mode;
+                  i < StdOut->Mode->MaxMode; ++i )
             {
-                size = cols * rows;
-                best = i;
+                if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
+                     cols * rows > size )
+                {
+                    size = cols * rows;
+                    best = i;
+                }
             }
+            if ( best != StdOut->Mode->Mode )
+                StdOut->SetMode(StdOut, best);
         }
-        if ( best != StdOut->Mode->Mode )
-            StdOut->SetMode(StdOut, best);
     }
 
     PrintStr(L"Xen " __stringify(XEN_VERSION) "." __stringify(XEN_SUBVERSION)
@@ -793,37 +799,38 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_relocate_image(0);
 
-    if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
-                           &cols, &rows) == EFI_SUCCESS )
-        efi_arch_console_init(cols, rows);
-
-    size = 0;
-    status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
-    if ( status == EFI_BUFFER_TOO_SMALL )
-        status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
-    if ( !EFI_ERROR(status) )
-        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
-                                      handles);
-    if ( EFI_ERROR(status) )
-        size = 0;
-    for ( i = 0; i < size / sizeof(*handles); ++i )
-    {
-        status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
-        if ( EFI_ERROR(status) )
-            continue;
-        status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
-        if ( !EFI_ERROR(status) )
-            break;
-    }
-    if ( handles )
-        efi_bs->FreePool(handles);
-    if ( EFI_ERROR(status) )
-        gop = NULL;
-
-    cols = rows = depth = 0;
-    if ( efi_arch_use_config_file(SystemTable) )
+    if ( use_cfg_file )
     {
         EFI_FILE_HANDLE dir_handle;
+        UINTN depth, cols, rows, size;
+
+        size = cols = rows = depth = 0;
+
+        if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
+                               &cols, &rows) == EFI_SUCCESS )
+            efi_arch_console_init(cols, rows);
+
+        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
+        if ( status == EFI_BUFFER_TOO_SMALL )
+            status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
+        if ( !EFI_ERROR(status) )
+            status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
+                                          handles);
+        if ( EFI_ERROR(status) )
+            size = 0;
+        for ( i = 0; i < size / sizeof(*handles); ++i )
+        {
+            status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
+            if ( EFI_ERROR(status) )
+                continue;
+            status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
+            if ( !EFI_ERROR(status) )
+                break;
+        }
+        if ( handles )
+            efi_bs->FreePool(handles);
+        if ( EFI_ERROR(status) )
+            gop = NULL;
 
         /* Get the file system interface. */
         dir_handle = get_parent_handle(loaded_image, &file_name);
@@ -931,45 +938,44 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
         dir_handle->Close(dir_handle);
 
-    }
-
-    if ( gop && !base_video )
-    {
-        for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
+        if ( gop && !base_video )
         {
-            unsigned int bpp = 0;
-
-            status = gop->QueryMode(gop, i, &info_size, &mode_info);
-            if ( EFI_ERROR(status) )
-                continue;
-            switch ( mode_info->PixelFormat )
-            {
-            case PixelBitMask:
-                bpp = hweight32(mode_info->PixelInformation.RedMask |
-                                mode_info->PixelInformation.GreenMask |
-                                mode_info->PixelInformation.BlueMask);
-                break;
-            case PixelRedGreenBlueReserved8BitPerColor:
-            case PixelBlueGreenRedReserved8BitPerColor:
-                bpp = 24;
-                break;
-            default:
-                continue;
-            }
-            if ( cols == mode_info->HorizontalResolution &&
-                 rows == mode_info->VerticalResolution &&
-                 (!depth || bpp == depth) )
+            for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
             {
-                gop_mode = i;
-                break;
-            }
-            if ( !cols && !rows &&
-                 mode_info->HorizontalResolution *
-                 mode_info->VerticalResolution > size )
-            {
-                size = mode_info->HorizontalResolution *
-                       mode_info->VerticalResolution;
-                gop_mode = i;
+                unsigned int bpp = 0;
+
+                status = gop->QueryMode(gop, i, &info_size, &mode_info);
+                if ( EFI_ERROR(status) )
+                    continue;
+                switch ( mode_info->PixelFormat )
+                {
+                case PixelBitMask:
+                    bpp = hweight32(mode_info->PixelInformation.RedMask |
+                                    mode_info->PixelInformation.GreenMask |
+                                    mode_info->PixelInformation.BlueMask);
+                    break;
+                case PixelRedGreenBlueReserved8BitPerColor:
+                case PixelBlueGreenRedReserved8BitPerColor:
+                    bpp = 24;
+                    break;
+                default:
+                    continue;
+                }
+                if ( cols == mode_info->HorizontalResolution &&
+                     rows == mode_info->VerticalResolution &&
+                     (!depth || bpp == depth) )
+                {
+                    gop_mode = i;
+                    break;
+                }
+                if ( !cols && !rows &&
+                     mode_info->HorizontalResolution *
+                     mode_info->VerticalResolution > size )
+                {
+                    size = mode_info->HorizontalResolution *
+                           mode_info->VerticalResolution;
+                    gop_mode = i;
+                }
             }
         }
     }
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 22:40:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 22: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 1XmsCO-0004Zc-VI; Fri, 07 Nov 2014 22:40:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XmsCN-0004ZU-KZ
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 22:40:07 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	C8/52-02954-74A4D545; Fri, 07 Nov 2014 22:40:07 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415400006!12133301!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6996 invoked from network); 7 Nov 2014 22:40:06 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 22:40:06 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-23-29-105.brhm.adsl.virginm.net ([86.23.29.105]:49652
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XmsCK-00020d-Fh (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Fri, 07 Nov 2014 22:40:04 +0000
Message-ID: <545D4A48.10804@citrix.com>
Date: Fri, 07 Nov 2014 22:40:08 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Roy Franz <roy.franz@linaro.org>, xen-devel@lists.xen.org, 
	ian.campbell@citrix.com, stefano.stabellini@citrix.com, tim@xen.org, 
	jbeulich@suse.com
References: <1415398456-27423-1-git-send-email-roy.franz@linaro.org>
In-Reply-To: <1415398456-27423-1-git-send-email-roy.franz@linaro.org>
Cc: daniel.kiper@oracle.com, fu.wei@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v3] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/11/2014 22:14, Roy Franz wrote:
> Update EFI code to completely ignore the EFI comnandline when booted from GRUB.
> Previusly it was parsed of EFI boot specific options, but these aren't used
> when booted from GRUB.
>
> Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
> code does some console and video initialization to support native EFI boot from
> the EFI boot manager or EFI shell.  This initlization should not be done when
> booted using GRUB.
>
> Update EFI documentation to indicate that it describes EFI native boot, and
> does not apply at all when Xen is booted using GRUB.
>
> Signed-off-by: Roy Franz <roy.franz@linaro.org>

You do realise that v2 was already committed?  c/s c38cf865

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 22:40:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 22: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 1XmsCO-0004Zc-VI; Fri, 07 Nov 2014 22:40:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XmsCN-0004ZU-KZ
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 22:40:07 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	C8/52-02954-74A4D545; Fri, 07 Nov 2014 22:40:07 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415400006!12133301!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6996 invoked from network); 7 Nov 2014 22:40:06 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Nov 2014 22:40:06 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-23-29-105.brhm.adsl.virginm.net ([86.23.29.105]:49652
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XmsCK-00020d-Fh (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Fri, 07 Nov 2014 22:40:04 +0000
Message-ID: <545D4A48.10804@citrix.com>
Date: Fri, 07 Nov 2014 22:40:08 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Roy Franz <roy.franz@linaro.org>, xen-devel@lists.xen.org, 
	ian.campbell@citrix.com, stefano.stabellini@citrix.com, tim@xen.org, 
	jbeulich@suse.com
References: <1415398456-27423-1-git-send-email-roy.franz@linaro.org>
In-Reply-To: <1415398456-27423-1-git-send-email-roy.franz@linaro.org>
Cc: daniel.kiper@oracle.com, fu.wei@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v3] EFI: Ignore EFI commandline,
 skip console setup when booted from GRUB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/11/2014 22:14, Roy Franz wrote:
> Update EFI code to completely ignore the EFI comnandline when booted from GRUB.
> Previusly it was parsed of EFI boot specific options, but these aren't used
> when booted from GRUB.
>
> Don't do EFI console or video configuration when booted by GRUB.  The EFI boot
> code does some console and video initialization to support native EFI boot from
> the EFI boot manager or EFI shell.  This initlization should not be done when
> booted using GRUB.
>
> Update EFI documentation to indicate that it describes EFI native boot, and
> does not apply at all when Xen is booted using GRUB.
>
> Signed-off-by: Roy Franz <roy.franz@linaro.org>

You do realise that v2 was already committed?  c/s c38cf865

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 07 23:32:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 23:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmt0U-0004xJ-7f; Fri, 07 Nov 2014 23:31:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Xmt0T-0004xE-Dj
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 23:31:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3C/2B-09842-8665D545; Fri, 07 Nov 2014 23:31:52 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415403111!12337611!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32023 invoked from network); 7 Nov 2014 23:31:51 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-7.tower-21.messagelabs.com with SMTP;
	7 Nov 2014 23:31:51 -0000
X-TM-IMSS-Message-ID: <ccf344b5000867ae@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 ccf344b5000867ae ;
	Fri, 7 Nov 2014 18:31:58 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA7NVPSg030455; 
	Fri, 7 Nov 2014 18:31:35 -0500
Message-ID: <545D564E.4000106@tycho.nsa.gov>
Date: Fri, 07 Nov 2014 18:31:26 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Emil Condrea <emilcondrea@gmail.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>	<1415181601.11486.69.camel@citrix.com>	<545BEE4F.3080305@tycho.nsa.gov>
	<CAAULxKJwTAdVKGrb5p=j701dAO=PWLYsdX6LpYRbmrAUuAM86A@mail.gmail.com>
In-Reply-To: <CAAULxKJwTAdVKGrb5p=j701dAO=PWLYsdX6LpYRbmrAUuAM86A@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/07/2014 05:40 AM, Emil Condrea wrote:
> My system does not support DRTM so I can not test this. I am interested in
> contributing to vtpm and making this to work without DRTM, can you give me
> more details about PCRs that need to be implemented using an alternate
> manner? When someone wants to use other locality than 0 it will run all
> commands with PCRs disabled? Since the vtpmmgr is tying domU to hardware
> TPM, deactivating PCRs will result that all commands issued by domU will
> not use PCRs anymore, right?

The PCRs seen by the domU are emulated by the vTPM, and the vTPM Manager has no information on any of their values or updates.  Deep quotes may include a hash of the vTPM's PCR values, but the vTPM Manager is only asserting that the hash was given by the vTPM.

> Where should the new layer of PCR values stored? NVRAM ?

They will be stored in the vtpmmgr domain's RAM; in fact, they are already stored there (they just need to be used more directly).

The PCRs in question are PCR 20-23, used by the vTPM Manager to store information about the vTPM making a deep quote request.  In order to support more than one vTPM, the values of these PCRs need to be reset when a different client connects.  However, the reset operation for PCR 20-22 is limited to locality 2.

An alternative to this is to embed this information in the externData field that is signed by the quote operation.  This requires a bit more work to provide the same flexibility that the PCRs provided, but it can be made equivalently secure.

A deep quote request currently contains a PCR mask and a requestData value (20 bytes) from the vTPM.  On a deep quote request, the vTPM Manager:
  1. Reset PCR 20-23
  2. Extend information about the requesting vTPM to PCR 20-23
    - Different information is extended into each PCR
    - Some clients want all information, some only want selected PCRs
  3. Perform a Quote with externData=requestData on the requested PCRs
  4. Return the result to the requesting vTPM

The change I am suggesting requires:
  - Add a field to the request - extraInfoFlags
  - Compute externData = SHA1 (
	requestData
	extraInfoFlags
	[UUIDs if requested]
	[vTPM measurements if requested]
	[vTPM group update policy if requested]
   )
  - Perform deep quotes using the above externData value instead of the value provided by the vTPM.

This change also has the benefit of increasing the flexibility of the request - it is simple to define additional flags and add data to the hash if needed.

> On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
> wrote:
>
>> On 11/05/2014 05:00 AM, Ian Campbell wrote:
>>
>>> CCing Daniel.
>>>
>>> On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
>>>
>>>>
>>>> I am wondering if this is known issue that when I set locality!=0 to
>>>> vtpmmgr it does not start. It is a bit strange that every call to
>>>> tpm_tis_status returns 255 and device-id is also FFFF:
>>>> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
>>>> TPM interface capabilities (0xffffffff):
>>>>
>>>> I am configuring vtpmmgr using:
>>>>
>>>> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
>>>> memory=8
>>>> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
>>>> name="vtpmmgr"
>>>> iomem=["fed40,5"]
>>>> extra="tpmlocality=2"
>>>>
>>>>
>>>> I also tried using :
>>>> iomem=["fed40,1"]
>>>> extra="tpmlocality=0"//works well
>>>>
>>>> or
>>>> iomem=["fed42,1"]
>>>> extra="tpmlocality=2"
>>>> It seems that everything that is not mapped at fed40-fed41 is
>>>> FFFFFFFF.
>>>>
>>>> I have an Atmel TPM chipset.
>>>>
>>>> Could it be a chipset problem to not handle well different localities?
>>>>
>>>> When I use locality=0, the device driver info is correct and
>>>> everything works fine:
>>>> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
>>>> TPM interface capabilities (0xfd)
>>>>
>>>
>> This may be an issue with locality 2 being unavailable unless a DRTM
>> launch (tboot) is performed.  Returning all-ones is the normal response
>> of the x86 chipset when unmapped MMIO regions are accessed; disabled
>> localities of the TPM may act like this.
>>
>> Does your system support the DRTM launch?  If so, can you test it to see
>> if this is the issue?
>>
>> In this case, to better support people who want to use the vTPM Manager
>> without a DRTM launch, the features of the vTPM Manager that use the TPM
>> 1.2 PCRs may need to be disabled or implemented in an alternate manner
>> such as embedding the data in the quote instead of in PCRs.  The current
>> design was created with the assumption that systems using it would be
>> performing a DRTM launch in order to fully secure the boot process.
>>
>>   In linux kernel this information is obtained using locality 0 and
>>>> after that other commands execute using specified locality.
>>>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-
>>>> stable.git/tree/drivers/char/tpm/tpm_tis.c#n558
>>>>
>>>
>> Have you tested that other localities work for your TPM under Linux?
>
>
>
>
>>
>>>> Thanks,
>>>>
>>>> Emil
>>>>
>>>>
>> --
>> Daniel De Graaf
>> National Security Agency
>>
>


-- 
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 Fri Nov 07 23:32:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Nov 2014 23:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xmt0U-0004xJ-7f; Fri, 07 Nov 2014 23:31:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Xmt0T-0004xE-Dj
	for xen-devel@lists.xen.org; Fri, 07 Nov 2014 23:31:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3C/2B-09842-8665D545; Fri, 07 Nov 2014 23:31:52 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415403111!12337611!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32023 invoked from network); 7 Nov 2014 23:31:51 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-7.tower-21.messagelabs.com with SMTP;
	7 Nov 2014 23:31:51 -0000
X-TM-IMSS-Message-ID: <ccf344b5000867ae@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 ccf344b5000867ae ;
	Fri, 7 Nov 2014 18:31:58 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA7NVPSg030455; 
	Fri, 7 Nov 2014 18:31:35 -0500
Message-ID: <545D564E.4000106@tycho.nsa.gov>
Date: Fri, 07 Nov 2014 18:31:26 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Emil Condrea <emilcondrea@gmail.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>	<1415181601.11486.69.camel@citrix.com>	<545BEE4F.3080305@tycho.nsa.gov>
	<CAAULxKJwTAdVKGrb5p=j701dAO=PWLYsdX6LpYRbmrAUuAM86A@mail.gmail.com>
In-Reply-To: <CAAULxKJwTAdVKGrb5p=j701dAO=PWLYsdX6LpYRbmrAUuAM86A@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/07/2014 05:40 AM, Emil Condrea wrote:
> My system does not support DRTM so I can not test this. I am interested in
> contributing to vtpm and making this to work without DRTM, can you give me
> more details about PCRs that need to be implemented using an alternate
> manner? When someone wants to use other locality than 0 it will run all
> commands with PCRs disabled? Since the vtpmmgr is tying domU to hardware
> TPM, deactivating PCRs will result that all commands issued by domU will
> not use PCRs anymore, right?

The PCRs seen by the domU are emulated by the vTPM, and the vTPM Manager has no information on any of their values or updates.  Deep quotes may include a hash of the vTPM's PCR values, but the vTPM Manager is only asserting that the hash was given by the vTPM.

> Where should the new layer of PCR values stored? NVRAM ?

They will be stored in the vtpmmgr domain's RAM; in fact, they are already stored there (they just need to be used more directly).

The PCRs in question are PCR 20-23, used by the vTPM Manager to store information about the vTPM making a deep quote request.  In order to support more than one vTPM, the values of these PCRs need to be reset when a different client connects.  However, the reset operation for PCR 20-22 is limited to locality 2.

An alternative to this is to embed this information in the externData field that is signed by the quote operation.  This requires a bit more work to provide the same flexibility that the PCRs provided, but it can be made equivalently secure.

A deep quote request currently contains a PCR mask and a requestData value (20 bytes) from the vTPM.  On a deep quote request, the vTPM Manager:
  1. Reset PCR 20-23
  2. Extend information about the requesting vTPM to PCR 20-23
    - Different information is extended into each PCR
    - Some clients want all information, some only want selected PCRs
  3. Perform a Quote with externData=requestData on the requested PCRs
  4. Return the result to the requesting vTPM

The change I am suggesting requires:
  - Add a field to the request - extraInfoFlags
  - Compute externData = SHA1 (
	requestData
	extraInfoFlags
	[UUIDs if requested]
	[vTPM measurements if requested]
	[vTPM group update policy if requested]
   )
  - Perform deep quotes using the above externData value instead of the value provided by the vTPM.

This change also has the benefit of increasing the flexibility of the request - it is simple to define additional flags and add data to the hash if needed.

> On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
> wrote:
>
>> On 11/05/2014 05:00 AM, Ian Campbell wrote:
>>
>>> CCing Daniel.
>>>
>>> On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
>>>
>>>>
>>>> I am wondering if this is known issue that when I set locality!=0 to
>>>> vtpmmgr it does not start. It is a bit strange that every call to
>>>> tpm_tis_status returns 255 and device-id is also FFFF:
>>>> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
>>>> TPM interface capabilities (0xffffffff):
>>>>
>>>> I am configuring vtpmmgr using:
>>>>
>>>> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
>>>> memory=8
>>>> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
>>>> name="vtpmmgr"
>>>> iomem=["fed40,5"]
>>>> extra="tpmlocality=2"
>>>>
>>>>
>>>> I also tried using :
>>>> iomem=["fed40,1"]
>>>> extra="tpmlocality=0"//works well
>>>>
>>>> or
>>>> iomem=["fed42,1"]
>>>> extra="tpmlocality=2"
>>>> It seems that everything that is not mapped at fed40-fed41 is
>>>> FFFFFFFF.
>>>>
>>>> I have an Atmel TPM chipset.
>>>>
>>>> Could it be a chipset problem to not handle well different localities?
>>>>
>>>> When I use locality=0, the device driver info is correct and
>>>> everything works fine:
>>>> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
>>>> TPM interface capabilities (0xfd)
>>>>
>>>
>> This may be an issue with locality 2 being unavailable unless a DRTM
>> launch (tboot) is performed.  Returning all-ones is the normal response
>> of the x86 chipset when unmapped MMIO regions are accessed; disabled
>> localities of the TPM may act like this.
>>
>> Does your system support the DRTM launch?  If so, can you test it to see
>> if this is the issue?
>>
>> In this case, to better support people who want to use the vTPM Manager
>> without a DRTM launch, the features of the vTPM Manager that use the TPM
>> 1.2 PCRs may need to be disabled or implemented in an alternate manner
>> such as embedding the data in the quote instead of in PCRs.  The current
>> design was created with the assumption that systems using it would be
>> performing a DRTM launch in order to fully secure the boot process.
>>
>>   In linux kernel this information is obtained using locality 0 and
>>>> after that other commands execute using specified locality.
>>>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-
>>>> stable.git/tree/drivers/char/tpm/tpm_tis.c#n558
>>>>
>>>
>> Have you tested that other localities work for your TPM under Linux?
>
>
>
>
>>
>>>> Thanks,
>>>>
>>>> Emil
>>>>
>>>>
>> --
>> Daniel De Graaf
>> National Security Agency
>>
>


-- 
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 Sat Nov 08 02:16:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 02: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 1XmvYt-00023q-JI; Sat, 08 Nov 2014 02:15:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmvYq-00023l-Re
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 02:15:33 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	C0/C3-25727-3CC7D545; Sat, 08 Nov 2014 02:15:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415412929!11223126!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23775 invoked from network); 8 Nov 2014 02:15:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 02:15:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,336,1413244800"; d="scan'208";a="190775913"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 21:15:28 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmvYl-0005b7-Ui;
	Sat, 08 Nov 2014 02:15:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmvYl-0005o0-DW;
	Sat, 08 Nov 2014 02:15:27 +0000
Date: Sat, 8 Nov 2014 02:15:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31432-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31432: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31432 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31432/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31432
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31432
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31432

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 02:16:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 02: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 1XmvYt-00023q-JI; Sat, 08 Nov 2014 02:15:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmvYq-00023l-Re
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 02:15:33 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	C0/C3-25727-3CC7D545; Sat, 08 Nov 2014 02:15:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415412929!11223126!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23775 invoked from network); 8 Nov 2014 02:15:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 02:15:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,336,1413244800"; d="scan'208";a="190775913"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 7 Nov 2014 21:15:28 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmvYl-0005b7-Ui;
	Sat, 08 Nov 2014 02:15:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmvYl-0005o0-DW;
	Sat, 08 Nov 2014 02:15:27 +0000
Date: Sat, 8 Nov 2014 02:15:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31432-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31432: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31432 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31432/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31432
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31432
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31432

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 05:06:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 05:06:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmyDy-000387-Dq; Sat, 08 Nov 2014 05:06:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmyDw-000382-JY
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 05:06:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	50/09-24532-FB4AD545; Sat, 08 Nov 2014 05:06:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415423165!12381669!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3485 invoked from network); 8 Nov 2014 05:06:07 -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;
	8 Nov 2014 05:06:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,337,1413244800"; d="scan'208";a="190793438"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 00:06:04 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmyDs-0006Q2-1f;
	Sat, 08 Nov 2014 05:06:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmyDP-00016o-Dk;
	Sat, 08 Nov 2014 05:05:45 +0000
Date: Sat, 8 Nov 2014 05:05:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31433-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31433: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31433 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31433/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 08 05:06:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 05:06:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XmyDy-000387-Dq; Sat, 08 Nov 2014 05:06:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XmyDw-000382-JY
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 05:06:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	50/09-24532-FB4AD545; Sat, 08 Nov 2014 05:06:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415423165!12381669!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3485 invoked from network); 8 Nov 2014 05:06:07 -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;
	8 Nov 2014 05:06:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,337,1413244800"; d="scan'208";a="190793438"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 00:06:04 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XmyDs-0006Q2-1f;
	Sat, 08 Nov 2014 05:06:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XmyDP-00016o-Dk;
	Sat, 08 Nov 2014 05:05:45 +0000
Date: Sat, 8 Nov 2014 05:05:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31433-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31433: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31433 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31433/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 08 07:14:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 07: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 1Xn0E4-00041H-59; Sat, 08 Nov 2014 07:14:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xn0E2-00041C-O8
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 07:14:22 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	14/DD-09284-DC2CD545; Sat, 08 Nov 2014 07:14:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415430857!11195028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13335 invoked from network); 8 Nov 2014 07:14:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 07:14:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,338,1413244800"; d="scan'208";a="190811292"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 02:14:15 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xn0Dv-00074W-HJ;
	Sat, 08 Nov 2014 07:14:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xn0Du-0003Yu-B7;
	Sat, 08 Nov 2014 07:14:14 +0000
Date: Sat, 8 Nov 2014 07:14:14 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31437-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31437: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31437 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31437/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e
baseline version:
 rumpuserxen          3d8a59f98b15b625babcb8b19d1832d002cc98b0

------------------------------------------------------------
People who touched revisions under test:
  Antti Kantee <pooka@iki.fi>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=1eb3666b469e307b20262e856229d0bd5d06a59e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen 1eb3666b469e307b20262e856229d0bd5d06a59e
+ branch=rumpuserxen
+ revision=1eb3666b469e307b20262e856229d0bd5d06a59e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git 1eb3666b469e307b20262e856229d0bd5d06a59e:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   3d8a59f..1eb3666  1eb3666b469e307b20262e856229d0bd5d06a59e -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 07:14:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 07: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 1Xn0E4-00041H-59; Sat, 08 Nov 2014 07:14:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xn0E2-00041C-O8
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 07:14:22 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	14/DD-09284-DC2CD545; Sat, 08 Nov 2014 07:14:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415430857!11195028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13335 invoked from network); 8 Nov 2014 07:14:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 07:14:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,338,1413244800"; d="scan'208";a="190811292"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 02:14:15 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xn0Dv-00074W-HJ;
	Sat, 08 Nov 2014 07:14:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xn0Du-0003Yu-B7;
	Sat, 08 Nov 2014 07:14:14 +0000
Date: Sat, 8 Nov 2014 07:14:14 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31437-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31437: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31437 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31437/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e
baseline version:
 rumpuserxen          3d8a59f98b15b625babcb8b19d1832d002cc98b0

------------------------------------------------------------
People who touched revisions under test:
  Antti Kantee <pooka@iki.fi>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=1eb3666b469e307b20262e856229d0bd5d06a59e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen 1eb3666b469e307b20262e856229d0bd5d06a59e
+ branch=rumpuserxen
+ revision=1eb3666b469e307b20262e856229d0bd5d06a59e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git 1eb3666b469e307b20262e856229d0bd5d06a59e:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   3d8a59f..1eb3666  1eb3666b469e307b20262e856229d0bd5d06a59e -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 10:27:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 10:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xn3E2-0005Pp-QJ; Sat, 08 Nov 2014 10:26:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xn3E1-0005Pk-Pa
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 10:26:33 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	10/3A-02559-8DFED545; Sat, 08 Nov 2014 10:26:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415442380!12194298!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2945 invoked from network); 8 Nov 2014 10:26:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 10:26:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,339,1413244800"; d="scan'208";a="190833420"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 05:26:18 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xn3Dm-00080F-8R;
	Sat, 08 Nov 2014 10:26:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xn3Dl-0003BW-MZ;
	Sat, 08 Nov 2014 10:26:17 +0000
Date: Sat, 8 Nov 2014 10:26:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31435-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31435: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31435 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31435/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Sat Nov 08 10:27:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 10:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xn3E2-0005Pp-QJ; Sat, 08 Nov 2014 10:26:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xn3E1-0005Pk-Pa
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 10:26:33 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	10/3A-02559-8DFED545; Sat, 08 Nov 2014 10:26:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415442380!12194298!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2945 invoked from network); 8 Nov 2014 10:26:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 10:26:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,339,1413244800"; d="scan'208";a="190833420"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 05:26:18 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xn3Dm-00080F-8R;
	Sat, 08 Nov 2014 10:26:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xn3Dl-0003BW-MZ;
	Sat, 08 Nov 2014 10:26:17 +0000
Date: Sat, 8 Nov 2014 10:26:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31435-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31435: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31435 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31435/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Sat Nov 08 14:44:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 14:44:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xn7FR-0006iZ-4Y; Sat, 08 Nov 2014 14:44:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xn7FO-0006iU-TY
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 14:44:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F6/CE-09842-D3C2E545; Sat, 08 Nov 2014 14:44:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415457851!12381438!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19252 invoked from network); 8 Nov 2014 14:44:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 14:44:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,340,1413244800"; d="scan'208";a="190863228"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 09:44:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xn7FJ-0000o3-S0;
	Sat, 08 Nov 2014 14:44:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xn7FJ-0001dr-Gc;
	Sat, 08 Nov 2014 14:44:09 +0000
Date: Sat, 8 Nov 2014 14:44:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31436-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31436: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31436 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31436/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 31432 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 31432
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pair          7 xen-boot/src_host           fail pass in 31432
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31436
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31436

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31432 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 14:44:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 14:44:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xn7FR-0006iZ-4Y; Sat, 08 Nov 2014 14:44:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xn7FO-0006iU-TY
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 14:44:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F6/CE-09842-D3C2E545; Sat, 08 Nov 2014 14:44:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415457851!12381438!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19252 invoked from network); 8 Nov 2014 14:44:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 14:44:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,340,1413244800"; d="scan'208";a="190863228"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 09:44:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xn7FJ-0000o3-S0;
	Sat, 08 Nov 2014 14:44:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xn7FJ-0001dr-Gc;
	Sat, 08 Nov 2014 14:44:09 +0000
Date: Sat, 8 Nov 2014 14:44:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31436-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31436: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31436 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31436/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 31432 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 31432
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pair          7 xen-boot/src_host           fail pass in 31432
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31436
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31436

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31432 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 17:34:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 17:34:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xn9tZ-0007yE-3x; Sat, 08 Nov 2014 17:33:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xn9tX-0007y9-HC
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 17:33:51 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	28/AF-17735-EF35E545; Sat, 08 Nov 2014 17:33:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415468028!6863204!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29505 invoked from network); 8 Nov 2014 17:33:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 17:33:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,341,1413244800"; d="scan'208";a="189444657"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 12:33:47 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xn9tS-0001cv-Nf;
	Sat, 08 Nov 2014 17:33:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xn9tS-0002a9-F5;
	Sat, 08 Nov 2014 17:33:46 +0000
Date: Sat, 8 Nov 2014 17:33:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31438-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31438: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31438 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31438/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2       fail pass in 31433

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 08 17:34:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 17:34:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xn9tZ-0007yE-3x; Sat, 08 Nov 2014 17:33:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xn9tX-0007y9-HC
	for xen-devel@lists.xensource.com; Sat, 08 Nov 2014 17:33:51 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	28/AF-17735-EF35E545; Sat, 08 Nov 2014 17:33:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415468028!6863204!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29505 invoked from network); 8 Nov 2014 17:33:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 17:33:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,341,1413244800"; d="scan'208";a="189444657"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 12:33:47 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xn9tS-0001cv-Nf;
	Sat, 08 Nov 2014 17:33:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xn9tS-0002a9-F5;
	Sat, 08 Nov 2014 17:33:46 +0000
Date: Sat, 8 Nov 2014 17:33:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31438-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31438: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31438 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31438/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2       fail pass in 31433

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 08 18:01:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 18:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnAKI-0008FL-HL; Sat, 08 Nov 2014 18:01:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XnAKG-0008FG-HU
	for xen-devel@lists.xenproject.org; Sat, 08 Nov 2014 18:01:28 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	6B/67-23865-77A5E545; Sat, 08 Nov 2014 18:01:27 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415469686!11317240!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2122 invoked from network); 8 Nov 2014 18:01:26 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 18:01:26 -0000
Received: by mail-wi0-f177.google.com with SMTP id ex7so7175165wid.10
	for <xen-devel@lists.xenproject.org>;
	Sat, 08 Nov 2014 10:01:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=FH5KZ/h1Kxy3VsNM3uboMkNnY9bXwkA4kxPVicoAKNQ=;
	b=F3caITQTVmo9C0oS5gGgR+itWQPTPP95RY7N+HYpXzduamlbErItV748mro0uTQ46w
	iDWh2wwHUI3XSV3IusPeLe5SK3/lbjs9vNrd0gLWrWrhcuE+/ywKMzSLgSZKols058IX
	Y58qUPwBFYEkimxukXUV6z1+R6x5NAOJ9PeQ6GWArj4u+802azSNol8wlCAZKhVlRYF9
	TC2uYQkkD8ESufd/w0q8GoN0S58C0wxrjA1LTokjvQLeUHh6QEBataaHuN1+baBFE84z
	+HqyTpNrU1g/mX9bkjhnzBnRo2IEGqdhFNrDkPahhcPJw2ybQioCyRSX1w+GjG1QUhQ2
	UmYw==
X-Gm-Message-State: ALoCoQlRxjICnvq37uiXJnETCczYjrKGaYqz/rgdnz//ptA7nsM/J9y0QwpQIsQ5lnBsOa5CBXV7
X-Received: by 10.180.218.40 with SMTP id pd8mr9110501wic.9.1415469686541;
	Sat, 08 Nov 2014 10:01:26 -0800 (PST)
Received: from [192.168.1.31] ([62.34.2.189])
	by mx.google.com with ESMTPSA id ny6sm6446359wic.22.2014.11.08.10.01.15
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 08 Nov 2014 10:01:25 -0800 (PST)
Message-ID: <545E5A66.2000609@linaro.org>
Date: Sat, 08 Nov 2014 18:01:10 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
In-Reply-To: <20141107154502.GC14076@laptop.dumpdata.com>
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Konrad,

On 07/11/2014 15:45, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 06, 2014 at 10:27:41AM +0000, Julien Grall wrote:
>>
>>
>> On 06/11/2014 10:11, Jan Beulich wrote:
>>>>>> On 06.11.14 at 10:45, <julien.grall@linaro.org> wrote:
>>>> Hi Jan,
>>>>
>>>> On 05/11/2014 17:15, Jan Beulich wrote:
>>>>>>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>>>>>> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>> It also needs Acks from Daniel and Jan.
>>>>>>
>>>>>> This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
>>>>>> required. Would Ian C. ack be enough?
>>>>>
>>>>> Yes, it would.
>>>>>
>>>>>> Anyway, Jan do you have any objection on this patch?
>>>>>
>>>>> As said previously, I'm not particularly happy about it, but I also don't
>>>> strongly
>>>>> mind it going in in the current shape.
>>>>
>>>> May I ask what is wrong with the new approach to the a DOMCTL in this patch?
>>>>
>>>> The DOMCTL has been clearly identify as arm specific (there is "arm" in
>>>> the name). Therefore it doesn't seem necessary to expose it for other
>>>> architecture than ARM32 and ARM64.
>>>
>>> I didn't say there's anything actively wrong with it, all I said is that
>>> I'm not particularly happy about it: Irrespective of its name it doesn't
>>> look to be really arch-specific in the long run, plus it feels like the
>>> data being set here should rather be specified right at domain
>>> creation, or via a mechanism similar to x86'es HVM parameters (iirc
>>> the value set here can't be changed once the domain got first
>>> unpaused).
>>
>>
>> TBH I choose this solution because I though you would be disagree with
>> extending the domain create hypercall.
>>
>> In long run, there will be more parameters such as the number of spis. All
>> will be required at the same time. So the HVM parameters solution won't
>> really help here.
>>
>> However, I could give a look to extending the domain creation hypercall
>> (xen_domctl_createdomain) to add arch specific field.
>>
>> But I don't think it's Xen 4.5 material. So I would prefer to stay on this
>> approach for this release because we'd like to have GICv3 guest support on
>> Xen. Though I could rename the DOMCTL to DOMCTL_get_gic_version.
>
> That is a bit unfortunate as it sounds like that for Xen 4.6 you will
> then ditch this hypercall and focus on the new one? Won't this one then
> be bitrotten?

Unfortunately yes. Modifying the xen_domctl_createdomain hypercall at 
this time of the release is not safe. Even though I like challenge, I 
don't want do be blamed because of a bug that would slip the release date.

But, the DOMCTL interface is not considered as a stable ABI. I guess we
could kill this hypercall in Xen 4.6.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 18:01:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 18:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnAKI-0008FL-HL; Sat, 08 Nov 2014 18:01:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XnAKG-0008FG-HU
	for xen-devel@lists.xenproject.org; Sat, 08 Nov 2014 18:01:28 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	6B/67-23865-77A5E545; Sat, 08 Nov 2014 18:01:27 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415469686!11317240!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2122 invoked from network); 8 Nov 2014 18:01:26 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 18:01:26 -0000
Received: by mail-wi0-f177.google.com with SMTP id ex7so7175165wid.10
	for <xen-devel@lists.xenproject.org>;
	Sat, 08 Nov 2014 10:01:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=FH5KZ/h1Kxy3VsNM3uboMkNnY9bXwkA4kxPVicoAKNQ=;
	b=F3caITQTVmo9C0oS5gGgR+itWQPTPP95RY7N+HYpXzduamlbErItV748mro0uTQ46w
	iDWh2wwHUI3XSV3IusPeLe5SK3/lbjs9vNrd0gLWrWrhcuE+/ywKMzSLgSZKols058IX
	Y58qUPwBFYEkimxukXUV6z1+R6x5NAOJ9PeQ6GWArj4u+802azSNol8wlCAZKhVlRYF9
	TC2uYQkkD8ESufd/w0q8GoN0S58C0wxrjA1LTokjvQLeUHh6QEBataaHuN1+baBFE84z
	+HqyTpNrU1g/mX9bkjhnzBnRo2IEGqdhFNrDkPahhcPJw2ybQioCyRSX1w+GjG1QUhQ2
	UmYw==
X-Gm-Message-State: ALoCoQlRxjICnvq37uiXJnETCczYjrKGaYqz/rgdnz//ptA7nsM/J9y0QwpQIsQ5lnBsOa5CBXV7
X-Received: by 10.180.218.40 with SMTP id pd8mr9110501wic.9.1415469686541;
	Sat, 08 Nov 2014 10:01:26 -0800 (PST)
Received: from [192.168.1.31] ([62.34.2.189])
	by mx.google.com with ESMTPSA id ny6sm6446359wic.22.2014.11.08.10.01.15
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 08 Nov 2014 10:01:25 -0800 (PST)
Message-ID: <545E5A66.2000609@linaro.org>
Date: Sat, 08 Nov 2014 18:01:10 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
In-Reply-To: <20141107154502.GC14076@laptop.dumpdata.com>
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Konrad,

On 07/11/2014 15:45, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 06, 2014 at 10:27:41AM +0000, Julien Grall wrote:
>>
>>
>> On 06/11/2014 10:11, Jan Beulich wrote:
>>>>>> On 06.11.14 at 10:45, <julien.grall@linaro.org> wrote:
>>>> Hi Jan,
>>>>
>>>> On 05/11/2014 17:15, Jan Beulich wrote:
>>>>>>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>>>>>> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>> It also needs Acks from Daniel and Jan.
>>>>>>
>>>>>> This patch doesn't modify the x86 part. So I'm not sure if Jan ack is
>>>>>> required. Would Ian C. ack be enough?
>>>>>
>>>>> Yes, it would.
>>>>>
>>>>>> Anyway, Jan do you have any objection on this patch?
>>>>>
>>>>> As said previously, I'm not particularly happy about it, but I also don't
>>>> strongly
>>>>> mind it going in in the current shape.
>>>>
>>>> May I ask what is wrong with the new approach to the a DOMCTL in this patch?
>>>>
>>>> The DOMCTL has been clearly identify as arm specific (there is "arm" in
>>>> the name). Therefore it doesn't seem necessary to expose it for other
>>>> architecture than ARM32 and ARM64.
>>>
>>> I didn't say there's anything actively wrong with it, all I said is that
>>> I'm not particularly happy about it: Irrespective of its name it doesn't
>>> look to be really arch-specific in the long run, plus it feels like the
>>> data being set here should rather be specified right at domain
>>> creation, or via a mechanism similar to x86'es HVM parameters (iirc
>>> the value set here can't be changed once the domain got first
>>> unpaused).
>>
>>
>> TBH I choose this solution because I though you would be disagree with
>> extending the domain create hypercall.
>>
>> In long run, there will be more parameters such as the number of spis. All
>> will be required at the same time. So the HVM parameters solution won't
>> really help here.
>>
>> However, I could give a look to extending the domain creation hypercall
>> (xen_domctl_createdomain) to add arch specific field.
>>
>> But I don't think it's Xen 4.5 material. So I would prefer to stay on this
>> approach for this release because we'd like to have GICv3 guest support on
>> Xen. Though I could rename the DOMCTL to DOMCTL_get_gic_version.
>
> That is a bit unfortunate as it sounds like that for Xen 4.6 you will
> then ditch this hypercall and focus on the new one? Won't this one then
> be bitrotten?

Unfortunately yes. Modifying the xen_domctl_createdomain hypercall at 
this time of the release is not safe. Even though I like challenge, I 
don't want do be blamed because of a bug that would slip the release date.

But, the DOMCTL interface is not considered as a stable ABI. I guess we
could kill this hypercall in Xen 4.6.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 19:44:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 19:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnBv2-0000Pz-Uk; Sat, 08 Nov 2014 19:43: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 1XnBv1-0000Pu-OJ
	for xen-devel@lists.xen.org; Sat, 08 Nov 2014 19:43:31 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A5/B6-17735-2627E545; Sat, 08 Nov 2014 19:43:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415475808!11343285!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10136 invoked from network); 8 Nov 2014 19:43:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 19:43:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,341,1413244800"; d="scan'208";a="190892457"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Sat, 8 Nov 2014 14:43:27 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XnBux-0005gP-A3;
	Sat, 08 Nov 2014 19:43:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Sat, 8 Nov 2014 19:43:27 +0000
Message-ID: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode to
	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

This information is passed in in domctl hypercall but the guest
interface doesn't expose it to guest. PV NUMA-aware ballooning relies on
this piece of information to function properly.

Also fixed one typo while I was there.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
---
 xen/common/memory.c         |   13 +++++++++++--
 xen/include/public/memory.h |    4 ++++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index cc36e39..fde03dc 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1013,7 +1013,7 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         /*
          * Copied from guest values may differ from domain vnuma config.
          * Check here guest parameters make sure we dont overflow.
-         * Additionaly check padding.
+         * Additionally check padding.
          */
         if ( topology.nr_vnodes < dom_vnodes      ||
              topology.nr_vcpus < dom_vcpus        ||
@@ -1035,10 +1035,12 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         tmp.vdistance = xmalloc_array(unsigned int, dom_vnodes * dom_vnodes);
         tmp.vmemrange = xmalloc_array(vmemrange_t, dom_vranges);
         tmp.vcpu_to_vnode = xmalloc_array(unsigned int, dom_vcpus);
+        tmp.vnode_to_pnode = xmalloc_array(unsigned int, dom_vnodes);
 
         if ( tmp.vdistance == NULL ||
              tmp.vmemrange == NULL ||
-             tmp.vcpu_to_vnode == NULL )
+             tmp.vcpu_to_vnode == NULL ||
+             tmp.vnode_to_pnode == NULL )
         {
             rc = -ENOMEM;
             goto vnumainfo_out;
@@ -1069,6 +1071,8 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
                sizeof(*d->vnuma->vdistance) * dom_vnodes * dom_vnodes);
         memcpy(tmp.vcpu_to_vnode, d->vnuma->vcpu_to_vnode,
                sizeof(*d->vnuma->vcpu_to_vnode) * dom_vcpus);
+        memcpy(tmp.vnode_to_pnode, d->vnuma->vnode_to_pnode,
+               sizeof(*d->vnuma->vnode_to_pnode) * dom_vnodes);
 
         read_unlock(&d->vnuma_rwlock);
 
@@ -1086,6 +1090,10 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
                            dom_vcpus) != 0 )
             goto vnumainfo_out;
 
+        if ( copy_to_guest(topology.vnode_to_pnode.h, tmp.vnode_to_pnode,
+                           dom_vnodes) != 0 )
+            goto vnumainfo_out;
+
         topology.nr_vnodes = dom_vnodes;
         topology.nr_vcpus = dom_vcpus;
         topology.nr_vmemranges = dom_vranges;
@@ -1098,6 +1106,7 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         xfree(tmp.vdistance);
         xfree(tmp.vmemrange);
         xfree(tmp.vcpu_to_vnode);
+        xfree(tmp.vnode_to_pnode);
         break;
     }
 
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index f021958..9d8c27b 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -566,6 +566,10 @@ struct vnuma_topology_info {
         uint64_t pad;
     } vcpu_to_vnode;
     union {
+        XEN_GUEST_HANDLE(uint) h;
+        uint64_t pad;
+    } vnode_to_pnode;
+    union {
         XEN_GUEST_HANDLE(vmemrange_t) h;
         uint64_t pad;
     } vmemrange;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 19:44:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 19:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnBv2-0000Pz-Uk; Sat, 08 Nov 2014 19:43: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 1XnBv1-0000Pu-OJ
	for xen-devel@lists.xen.org; Sat, 08 Nov 2014 19:43:31 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A5/B6-17735-2627E545; Sat, 08 Nov 2014 19:43:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415475808!11343285!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10136 invoked from network); 8 Nov 2014 19:43:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 19:43:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,341,1413244800"; d="scan'208";a="190892457"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Sat, 8 Nov 2014 14:43:27 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XnBux-0005gP-A3;
	Sat, 08 Nov 2014 19:43:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Sat, 8 Nov 2014 19:43:27 +0000
Message-ID: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode to
	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

This information is passed in in domctl hypercall but the guest
interface doesn't expose it to guest. PV NUMA-aware ballooning relies on
this piece of information to function properly.

Also fixed one typo while I was there.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
---
 xen/common/memory.c         |   13 +++++++++++--
 xen/include/public/memory.h |    4 ++++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index cc36e39..fde03dc 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1013,7 +1013,7 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         /*
          * Copied from guest values may differ from domain vnuma config.
          * Check here guest parameters make sure we dont overflow.
-         * Additionaly check padding.
+         * Additionally check padding.
          */
         if ( topology.nr_vnodes < dom_vnodes      ||
              topology.nr_vcpus < dom_vcpus        ||
@@ -1035,10 +1035,12 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         tmp.vdistance = xmalloc_array(unsigned int, dom_vnodes * dom_vnodes);
         tmp.vmemrange = xmalloc_array(vmemrange_t, dom_vranges);
         tmp.vcpu_to_vnode = xmalloc_array(unsigned int, dom_vcpus);
+        tmp.vnode_to_pnode = xmalloc_array(unsigned int, dom_vnodes);
 
         if ( tmp.vdistance == NULL ||
              tmp.vmemrange == NULL ||
-             tmp.vcpu_to_vnode == NULL )
+             tmp.vcpu_to_vnode == NULL ||
+             tmp.vnode_to_pnode == NULL )
         {
             rc = -ENOMEM;
             goto vnumainfo_out;
@@ -1069,6 +1071,8 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
                sizeof(*d->vnuma->vdistance) * dom_vnodes * dom_vnodes);
         memcpy(tmp.vcpu_to_vnode, d->vnuma->vcpu_to_vnode,
                sizeof(*d->vnuma->vcpu_to_vnode) * dom_vcpus);
+        memcpy(tmp.vnode_to_pnode, d->vnuma->vnode_to_pnode,
+               sizeof(*d->vnuma->vnode_to_pnode) * dom_vnodes);
 
         read_unlock(&d->vnuma_rwlock);
 
@@ -1086,6 +1090,10 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
                            dom_vcpus) != 0 )
             goto vnumainfo_out;
 
+        if ( copy_to_guest(topology.vnode_to_pnode.h, tmp.vnode_to_pnode,
+                           dom_vnodes) != 0 )
+            goto vnumainfo_out;
+
         topology.nr_vnodes = dom_vnodes;
         topology.nr_vcpus = dom_vcpus;
         topology.nr_vmemranges = dom_vranges;
@@ -1098,6 +1106,7 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         xfree(tmp.vdistance);
         xfree(tmp.vmemrange);
         xfree(tmp.vcpu_to_vnode);
+        xfree(tmp.vnode_to_pnode);
         break;
     }
 
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index f021958..9d8c27b 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -566,6 +566,10 @@ struct vnuma_topology_info {
         uint64_t pad;
     } vcpu_to_vnode;
     union {
+        XEN_GUEST_HANDLE(uint) h;
+        uint64_t pad;
+    } vnode_to_pnode;
+    union {
         XEN_GUEST_HANDLE(vmemrange_t) h;
         uint64_t pad;
     } vmemrange;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 19:56:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 19:56:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnC7d-0000an-FN; Sat, 08 Nov 2014 19:56:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnC7c-0000ai-26
	for xen-devel@lists.xen.org; Sat, 08 Nov 2014 19:56:32 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	70/89-23865-F657E545; Sat, 08 Nov 2014 19:56:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415476589!11245411!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3619 invoked from network); 8 Nov 2014 19:56:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 19:56:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,341,1413244800"; d="scan'208";a="189458220"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Sat, 8 Nov 2014 14:56:28 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnC7Y-0005r9-5h;
	Sat, 08 Nov 2014 19:56:28 +0000
Date: Sat, 8 Nov 2014 19:56:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141108195628.GA22235@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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

Targeting this patch for 4.5 because I don't want to release an
incomplete interface.

Not sure if this topic has been discussed. If it has and the decision
was to not expose the mapping, please ignore this patch.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 19:56:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 19:56:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnC7d-0000an-FN; Sat, 08 Nov 2014 19:56:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnC7c-0000ai-26
	for xen-devel@lists.xen.org; Sat, 08 Nov 2014 19:56:32 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	70/89-23865-F657E545; Sat, 08 Nov 2014 19:56:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415476589!11245411!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3619 invoked from network); 8 Nov 2014 19:56:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Nov 2014 19:56:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,341,1413244800"; d="scan'208";a="189458220"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Sat, 8 Nov 2014 14:56:28 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnC7Y-0005r9-5h;
	Sat, 08 Nov 2014 19:56:28 +0000
Date: Sat, 8 Nov 2014 19:56:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141108195628.GA22235@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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

Targeting this patch for 4.5 because I don't want to release an
incomplete interface.

Not sure if this topic has been discussed. If it has and the decision
was to not expose the mapping, please ignore this patch.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 20:28:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 20:28:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnCce-0000vd-L6; Sat, 08 Nov 2014 20:28:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XnCcd-0000vY-M4
	for xen-devel@lists.xenproject.org; Sat, 08 Nov 2014 20:28:35 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	13/6D-25714-2FC7E545; Sat, 08 Nov 2014 20:28:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415478511!7945120!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29309 invoked from network); 8 Nov 2014 20:28:32 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Nov 2014 20:28:32 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA8KRKQc027221
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 8 Nov 2014 20:27:22 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA8KRGNF012838
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 8 Nov 2014 20:27:17 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA8KRGAl012833; Sat, 8 Nov 2014 20:27:16 GMT
Received: from [IPv6:2607:fb90:e17:1979:ed64:1eca:1170:91a4] (/208.54.36.234)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 08 Nov 2014 12:27:15 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <545E5A66.2000609@linaro.org>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 08 Nov 2014 15:26:51 -0500
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 8, 2014 1:01:10 PM EST, Julien Grall <julien.grall@linaro.org> wrote:
>Hi Konrad,
>
>On 07/11/2014 15:45, Konrad Rzeszutek Wilk wrote:
>> On Thu, Nov 06, 2014 at 10:27:41AM +0000, Julien Grall wrote:
>>>
>>>
>>> On 06/11/2014 10:11, Jan Beulich wrote:
>>>>>>> On 06.11.14 at 10:45, <julien.grall@linaro.org> wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 05/11/2014 17:15, Jan Beulich wrote:
>>>>>>>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>>>>>>> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>> It also needs Acks from Daniel and Jan.
>>>>>>>
>>>>>>> This patch doesn't modify the x86 part. So I'm not sure if Jan
>ack is
>>>>>>> required. Would Ian C. ack be enough?
>>>>>>
>>>>>> Yes, it would.
>>>>>>
>>>>>>> Anyway, Jan do you have any objection on this patch?
>>>>>>
>>>>>> As said previously, I'm not particularly happy about it, but I
>also don't
>>>>> strongly
>>>>>> mind it going in in the current shape.
>>>>>
>>>>> May I ask what is wrong with the new approach to the a DOMCTL in
>this patch?
>>>>>
>>>>> The DOMCTL has been clearly identify as arm specific (there is
>"arm" in
>>>>> the name). Therefore it doesn't seem necessary to expose it for
>other
>>>>> architecture than ARM32 and ARM64.
>>>>
>>>> I didn't say there's anything actively wrong with it, all I said is
>that
>>>> I'm not particularly happy about it: Irrespective of its name it
>doesn't
>>>> look to be really arch-specific in the long run, plus it feels like
>the
>>>> data being set here should rather be specified right at domain
>>>> creation, or via a mechanism similar to x86'es HVM parameters (iirc
>>>> the value set here can't be changed once the domain got first
>>>> unpaused).
>>>
>>>
>>> TBH I choose this solution because I though you would be disagree
>with
>>> extending the domain create hypercall.
>>>
>>> In long run, there will be more parameters such as the number of
>spis. All
>>> will be required at the same time. So the HVM parameters solution
>won't
>>> really help here.
>>>
>>> However, I could give a look to extending the domain creation
>hypercall
>>> (xen_domctl_createdomain) to add arch specific field.
>>>
>>> But I don't think it's Xen 4.5 material. So I would prefer to stay
>on this
>>> approach for this release because we'd like to have GICv3 guest
>support on
>>> Xen. Though I could rename the DOMCTL to DOMCTL_get_gic_version.
>>
>> That is a bit unfortunate as it sounds like that for Xen 4.6 you will
>> then ditch this hypercall and focus on the new one? Won't this one
>then
>> be bitrotten?
>
>Unfortunately yes. Modifying the xen_domctl_createdomain hypercall at 
>this time of the release is not safe. Even though I like challenge, I 
>don't want do be blamed because of a bug that would slip the release
>date.
>

<nods>

>But, the DOMCTL interface is not considered as a stable ABI. I guess we
>could kill this hypercall in Xen 4.6.

If that is the intent we should really wrap all of the functionality (in userspace) with Xen v4.5 version check such that it is not exposed to earlier or newer versions of tools.

That is to guard against somebody building against libxc or libxl and then becoming dependent on this and then complaining that it is not in Xen 4.6. 

Perhaps even add in headers a big warning that this is an band-aid!
>
>Regards,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 08 20:28:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Nov 2014 20:28:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnCce-0000vd-L6; Sat, 08 Nov 2014 20:28:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XnCcd-0000vY-M4
	for xen-devel@lists.xenproject.org; Sat, 08 Nov 2014 20:28:35 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	13/6D-25714-2FC7E545; Sat, 08 Nov 2014 20:28:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415478511!7945120!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29309 invoked from network); 8 Nov 2014 20:28:32 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Nov 2014 20:28:32 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sA8KRKQc027221
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 8 Nov 2014 20:27:22 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA8KRGNF012838
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 8 Nov 2014 20:27:17 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sA8KRGAl012833; Sat, 8 Nov 2014 20:27:16 GMT
Received: from [IPv6:2607:fb90:e17:1979:ed64:1eca:1170:91a4] (/208.54.36.234)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 08 Nov 2014 12:27:15 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <545E5A66.2000609@linaro.org>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 08 Nov 2014 15:26:51 -0500
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 8, 2014 1:01:10 PM EST, Julien Grall <julien.grall@linaro.org> wrote:
>Hi Konrad,
>
>On 07/11/2014 15:45, Konrad Rzeszutek Wilk wrote:
>> On Thu, Nov 06, 2014 at 10:27:41AM +0000, Julien Grall wrote:
>>>
>>>
>>> On 06/11/2014 10:11, Jan Beulich wrote:
>>>>>>> On 06.11.14 at 10:45, <julien.grall@linaro.org> wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 05/11/2014 17:15, Jan Beulich wrote:
>>>>>>>>> Julien Grall <julien.grall@linaro.org> 11/04/14 6:27 PM >>>
>>>>>>> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>> It also needs Acks from Daniel and Jan.
>>>>>>>
>>>>>>> This patch doesn't modify the x86 part. So I'm not sure if Jan
>ack is
>>>>>>> required. Would Ian C. ack be enough?
>>>>>>
>>>>>> Yes, it would.
>>>>>>
>>>>>>> Anyway, Jan do you have any objection on this patch?
>>>>>>
>>>>>> As said previously, I'm not particularly happy about it, but I
>also don't
>>>>> strongly
>>>>>> mind it going in in the current shape.
>>>>>
>>>>> May I ask what is wrong with the new approach to the a DOMCTL in
>this patch?
>>>>>
>>>>> The DOMCTL has been clearly identify as arm specific (there is
>"arm" in
>>>>> the name). Therefore it doesn't seem necessary to expose it for
>other
>>>>> architecture than ARM32 and ARM64.
>>>>
>>>> I didn't say there's anything actively wrong with it, all I said is
>that
>>>> I'm not particularly happy about it: Irrespective of its name it
>doesn't
>>>> look to be really arch-specific in the long run, plus it feels like
>the
>>>> data being set here should rather be specified right at domain
>>>> creation, or via a mechanism similar to x86'es HVM parameters (iirc
>>>> the value set here can't be changed once the domain got first
>>>> unpaused).
>>>
>>>
>>> TBH I choose this solution because I though you would be disagree
>with
>>> extending the domain create hypercall.
>>>
>>> In long run, there will be more parameters such as the number of
>spis. All
>>> will be required at the same time. So the HVM parameters solution
>won't
>>> really help here.
>>>
>>> However, I could give a look to extending the domain creation
>hypercall
>>> (xen_domctl_createdomain) to add arch specific field.
>>>
>>> But I don't think it's Xen 4.5 material. So I would prefer to stay
>on this
>>> approach for this release because we'd like to have GICv3 guest
>support on
>>> Xen. Though I could rename the DOMCTL to DOMCTL_get_gic_version.
>>
>> That is a bit unfortunate as it sounds like that for Xen 4.6 you will
>> then ditch this hypercall and focus on the new one? Won't this one
>then
>> be bitrotten?
>
>Unfortunately yes. Modifying the xen_domctl_createdomain hypercall at 
>this time of the release is not safe. Even though I like challenge, I 
>don't want do be blamed because of a bug that would slip the release
>date.
>

<nods>

>But, the DOMCTL interface is not considered as a stable ABI. I guess we
>could kill this hypercall in Xen 4.6.

If that is the intent we should really wrap all of the functionality (in userspace) with Xen v4.5 version check such that it is not exposed to earlier or newer versions of tools.

That is to guard against somebody building against libxc or libxl and then becoming dependent on this and then complaining that it is not in Xen 4.6. 

Perhaps even add in headers a big warning that this is an band-aid!
>
>Regards,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 00:10:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 00:10:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnG4P-0002YH-Pa; Sun, 09 Nov 2014 00:09:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnG4O-0002YC-Ss
	for xen-devel@lists.xensource.com; Sun, 09 Nov 2014 00:09:29 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	B7/AD-25547-8B0BE545; Sun, 09 Nov 2014 00:09:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415491766!11296875!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32477 invoked from network); 9 Nov 2014 00:09:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 00:09:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,342,1413244800"; d="scan'208";a="190913205"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 19:09:24 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnG4K-0003XJ-3H;
	Sun, 09 Nov 2014 00:09:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnG4J-0006iw-U8;
	Sun, 09 Nov 2014 00:09:23 +0000
Date: Sun, 9 Nov 2014 00:09:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31441-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31441: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31441 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31441/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  8 debian-fixup                fail pass in 31435

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Sun Nov 09 00:10:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 00:10:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnG4P-0002YH-Pa; Sun, 09 Nov 2014 00:09:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnG4O-0002YC-Ss
	for xen-devel@lists.xensource.com; Sun, 09 Nov 2014 00:09:29 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	B7/AD-25547-8B0BE545; Sun, 09 Nov 2014 00:09:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415491766!11296875!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32477 invoked from network); 9 Nov 2014 00:09:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 00:09:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,342,1413244800"; d="scan'208";a="190913205"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 19:09:24 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnG4K-0003XJ-3H;
	Sun, 09 Nov 2014 00:09:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnG4J-0006iw-U8;
	Sun, 09 Nov 2014 00:09:23 +0000
Date: Sun, 9 Nov 2014 00:09:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31441-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31441: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31441 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31441/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  8 debian-fixup                fail pass in 31435

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Sun Nov 09 01:22:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 01:22:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnHCl-0007JW-Jq; Sun, 09 Nov 2014 01:22:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ug93tad@gmail.com>) id 1XnHCk-0007JR-3D
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 01:22:10 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	28/2F-02699-1C1CE545; Sun, 09 Nov 2014 01:22:09 +0000
X-Env-Sender: ug93tad@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415496128!6851037!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20296 invoked from network); 9 Nov 2014 01:22:08 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 01:22:08 -0000
Received: by mail-wg0-f44.google.com with SMTP id x12so6360123wgg.3
	for <xen-devel@lists.xen.org>; Sat, 08 Nov 2014 17:22:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=t+YhbSQr7+8tnH7Z0jbs+ORusiQ4SNBZDESFonhsC9g=;
	b=R9BMz6F93kbaDC+F24eDn2TRf3f5jAtLPm+tJ/GwXbjWxFWyEs+svzuvbsjpMLIiyd
	lvGPdxc/5Cbn/k8ztV3+9Y+KuQdlgaghMPS0hrQ6QC9LCAhcI8pkPtXO5HSVRxiE1I5c
	g/0rk8CIAWxS515Lyp5x3Kl4ki23ZU0QydfK1F+fmLR6YJ232SIxD7TR5E0UpHzD4Omx
	f2bwDxO5VgYkbbPdZv4qddd+EiwiwLi+f9oheNw6R6YvoHbHkMPI8DCFG4cXhzo1kfMA
	+6OFGQUnl+MN+OkKA2u0bf26xLfFRrGN3AotoXdDAcgKKVHxgVJ3XMYvzL6rwxokvGwG
	Tv9Q==
MIME-Version: 1.0
X-Received: by 10.194.78.238 with SMTP id e14mr29339213wjx.106.1415496128051; 
	Sat, 08 Nov 2014 17:22:08 -0800 (PST)
Received: by 10.180.80.6 with HTTP; Sat, 8 Nov 2014 17:22:08 -0800 (PST)
In-Reply-To: <545CA690.8090507@citrix.com>
References: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
	<545CA29A.2040703@citrix.com>
	<CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com>
	<545CA690.8090507@citrix.com>
Date: Sun, 9 Nov 2014 09:22:08 +0800
Message-ID: <CAAbkU4SUrk0nRT97T0eBqNB7-Z7MVLGoWJtP+DwPijbZEphM0w@mail.gmail.com>
From: Anh Dinh <ug93tad@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "<xen-devel@lists.xen.org>" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] how to deal with copy_to_user returning non 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: multipart/mixed; boundary="===============7625624444877919394=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7625624444877919394==
Content-Type: multipart/alternative; boundary=047d7bfcf010e4c0f9050762df4e

--047d7bfcf010e4c0f9050762df4e
Content-Type: text/plain; charset=UTF-8

Thanks,

I've found out the reason it page-faulting is because I used malloc() to
allocate the output buffer, which turns out to allocate lazily. Therefore
the hypervisor page-fault because the memory is still waiting to be mapped
by the kernel.

I simply touched all the allocated memory, and it works fine now.

Cheers.


On 7 November 2014 19:01, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

>  On 07/11/14 10:57, And Dinh wrote:
>
> how does it get page fault? I made sure the output buffer at the user
> space is properly allocated with the correct  size.
>
>  When page fault, do I have no choice but abort? It seems calling the
> hypercall again does not solve it.
>
>
> And nothing guarentees that your userspace process is in context when Xen
> is running, or that the kernel hasn't played with the pagetables behind
> your back.
>
> You must use the hypercall buffer mechanism to avoid issues like this.
> See the hypercall implementations in libxc.  In Xen, you must have a
> XEN_GUEST_HANDLE() which is an opaque reference to your buffer, and use
> copy_{to,from}_guest() rather than {to/from}_user(), which is generally
> only safe for kernel addresses.
>
> ~Andrew
>

--047d7bfcf010e4c0f9050762df4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks,<div><br></div><div>I&#39;ve found out the reason i=
t page-faulting is because I used malloc() to allocate the output buffer, w=
hich turns out to allocate lazily. Therefore the hypervisor page-fault beca=
use the memory is still waiting to be mapped by the kernel.=C2=A0</div><div=
><br></div><div>I simply touched all the allocated memory, and it works fin=
e now.=C2=A0</div><div><br></div><div>Cheers.</div><div><br></div></div><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 7 November 2014 1=
9:01, 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> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    <div>On 07/11/14 10:57, And Dinh wrote:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div>how does it get page fault? I made sure the output buffer at
        the user space is properly allocated with the correct =C2=A0size.</=
div>
      <div><br>
      </div>
      <div>When page fault, do I have no choice but abort? It seems
        calling the hypercall again does not solve it.</div>
      <div><br>
      </div>
    </blockquote>
    <br></span>
    And nothing guarentees that your userspace process is in context
    when Xen is running, or that the kernel hasn&#39;t played with the
    pagetables behind your back.<br>
    <br>
    You must use the hypercall buffer mechanism to avoid issues like
    this.=C2=A0 See the hypercall implementations in libxc.=C2=A0 In Xen, y=
ou must
    have a XEN_GUEST_HANDLE() which is an opaque reference to your
    buffer, and use copy_{to,from}_guest() rather than {to/from}_user(),
    which is generally only safe for kernel addresses.<span class=3D"HOEnZb=
"><font color=3D"#888888"><br>
    <br>
    ~Andrew<br>
  </font></span></div>

</blockquote></div><br></div>

--047d7bfcf010e4c0f9050762df4e--


--===============7625624444877919394==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7625624444877919394==--


From xen-devel-bounces@lists.xen.org Sun Nov 09 01:22:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 01:22:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnHCl-0007JW-Jq; Sun, 09 Nov 2014 01:22:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ug93tad@gmail.com>) id 1XnHCk-0007JR-3D
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 01:22:10 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	28/2F-02699-1C1CE545; Sun, 09 Nov 2014 01:22:09 +0000
X-Env-Sender: ug93tad@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415496128!6851037!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20296 invoked from network); 9 Nov 2014 01:22:08 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 01:22:08 -0000
Received: by mail-wg0-f44.google.com with SMTP id x12so6360123wgg.3
	for <xen-devel@lists.xen.org>; Sat, 08 Nov 2014 17:22:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=t+YhbSQr7+8tnH7Z0jbs+ORusiQ4SNBZDESFonhsC9g=;
	b=R9BMz6F93kbaDC+F24eDn2TRf3f5jAtLPm+tJ/GwXbjWxFWyEs+svzuvbsjpMLIiyd
	lvGPdxc/5Cbn/k8ztV3+9Y+KuQdlgaghMPS0hrQ6QC9LCAhcI8pkPtXO5HSVRxiE1I5c
	g/0rk8CIAWxS515Lyp5x3Kl4ki23ZU0QydfK1F+fmLR6YJ232SIxD7TR5E0UpHzD4Omx
	f2bwDxO5VgYkbbPdZv4qddd+EiwiwLi+f9oheNw6R6YvoHbHkMPI8DCFG4cXhzo1kfMA
	+6OFGQUnl+MN+OkKA2u0bf26xLfFRrGN3AotoXdDAcgKKVHxgVJ3XMYvzL6rwxokvGwG
	Tv9Q==
MIME-Version: 1.0
X-Received: by 10.194.78.238 with SMTP id e14mr29339213wjx.106.1415496128051; 
	Sat, 08 Nov 2014 17:22:08 -0800 (PST)
Received: by 10.180.80.6 with HTTP; Sat, 8 Nov 2014 17:22:08 -0800 (PST)
In-Reply-To: <545CA690.8090507@citrix.com>
References: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
	<545CA29A.2040703@citrix.com>
	<CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com>
	<545CA690.8090507@citrix.com>
Date: Sun, 9 Nov 2014 09:22:08 +0800
Message-ID: <CAAbkU4SUrk0nRT97T0eBqNB7-Z7MVLGoWJtP+DwPijbZEphM0w@mail.gmail.com>
From: Anh Dinh <ug93tad@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "<xen-devel@lists.xen.org>" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] how to deal with copy_to_user returning non 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: multipart/mixed; boundary="===============7625624444877919394=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7625624444877919394==
Content-Type: multipart/alternative; boundary=047d7bfcf010e4c0f9050762df4e

--047d7bfcf010e4c0f9050762df4e
Content-Type: text/plain; charset=UTF-8

Thanks,

I've found out the reason it page-faulting is because I used malloc() to
allocate the output buffer, which turns out to allocate lazily. Therefore
the hypervisor page-fault because the memory is still waiting to be mapped
by the kernel.

I simply touched all the allocated memory, and it works fine now.

Cheers.


On 7 November 2014 19:01, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

>  On 07/11/14 10:57, And Dinh wrote:
>
> how does it get page fault? I made sure the output buffer at the user
> space is properly allocated with the correct  size.
>
>  When page fault, do I have no choice but abort? It seems calling the
> hypercall again does not solve it.
>
>
> And nothing guarentees that your userspace process is in context when Xen
> is running, or that the kernel hasn't played with the pagetables behind
> your back.
>
> You must use the hypercall buffer mechanism to avoid issues like this.
> See the hypercall implementations in libxc.  In Xen, you must have a
> XEN_GUEST_HANDLE() which is an opaque reference to your buffer, and use
> copy_{to,from}_guest() rather than {to/from}_user(), which is generally
> only safe for kernel addresses.
>
> ~Andrew
>

--047d7bfcf010e4c0f9050762df4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks,<div><br></div><div>I&#39;ve found out the reason i=
t page-faulting is because I used malloc() to allocate the output buffer, w=
hich turns out to allocate lazily. Therefore the hypervisor page-fault beca=
use the memory is still waiting to be mapped by the kernel.=C2=A0</div><div=
><br></div><div>I simply touched all the allocated memory, and it works fin=
e now.=C2=A0</div><div><br></div><div>Cheers.</div><div><br></div></div><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 7 November 2014 1=
9:01, 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> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    <div>On 07/11/14 10:57, And Dinh wrote:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div>how does it get page fault? I made sure the output buffer at
        the user space is properly allocated with the correct =C2=A0size.</=
div>
      <div><br>
      </div>
      <div>When page fault, do I have no choice but abort? It seems
        calling the hypercall again does not solve it.</div>
      <div><br>
      </div>
    </blockquote>
    <br></span>
    And nothing guarentees that your userspace process is in context
    when Xen is running, or that the kernel hasn&#39;t played with the
    pagetables behind your back.<br>
    <br>
    You must use the hypercall buffer mechanism to avoid issues like
    this.=C2=A0 See the hypercall implementations in libxc.=C2=A0 In Xen, y=
ou must
    have a XEN_GUEST_HANDLE() which is an opaque reference to your
    buffer, and use copy_{to,from}_guest() rather than {to/from}_user(),
    which is generally only safe for kernel addresses.<span class=3D"HOEnZb=
"><font color=3D"#888888"><br>
    <br>
    ~Andrew<br>
  </font></span></div>

</blockquote></div><br></div>

--047d7bfcf010e4c0f9050762df4e--


--===============7625624444877919394==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7625624444877919394==--


From xen-devel-bounces@lists.xen.org Sun Nov 09 04:57:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 04: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 1XnKYR-0000Ts-Vj; Sun, 09 Nov 2014 04:56: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@citrix.com>) id 1XnKYQ-0000Tn-L8
	for xen-devel@lists.xensource.com; Sun, 09 Nov 2014 04:56:46 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	5A/4C-25714-D04FE545; Sun, 09 Nov 2014 04:56:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415509003!11344604!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31637 invoked from network); 9 Nov 2014 04:56:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 04:56:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,345,1413244800"; d="scan'208";a="190935028"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 23:56:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnKYL-0004vP-Ef;
	Sun, 09 Nov 2014 04:56:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnKYL-0002kx-3U;
	Sun, 09 Nov 2014 04:56:41 +0000
Date: Sun, 9 Nov 2014 04:56:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31443-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31443: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31443 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31443/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31443
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31443
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31443

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 04:57:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 04: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 1XnKYR-0000Ts-Vj; Sun, 09 Nov 2014 04:56: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@citrix.com>) id 1XnKYQ-0000Tn-L8
	for xen-devel@lists.xensource.com; Sun, 09 Nov 2014 04:56:46 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	5A/4C-25714-D04FE545; Sun, 09 Nov 2014 04:56:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415509003!11344604!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31637 invoked from network); 9 Nov 2014 04:56:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 04:56:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,345,1413244800"; d="scan'208";a="190935028"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 8 Nov 2014 23:56:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnKYL-0004vP-Ef;
	Sun, 09 Nov 2014 04:56:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnKYL-0002kx-3U;
	Sun, 09 Nov 2014 04:56:41 +0000
Date: Sun, 9 Nov 2014 04:56:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31443-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31443: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31443 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31443/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31443
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31443
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31443

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 08:30:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 08:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnNt4-0002XQ-GL; Sun, 09 Nov 2014 08:30:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XnNt2-0002XL-PL
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 08:30:16 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	A7/E5-17958-8162F545; Sun, 09 Nov 2014 08:30:16 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415521814!11347205!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29003 invoked from network); 9 Nov 2014 08:30:14 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-31.messagelabs.com with SMTP;
	9 Nov 2014 08:30:14 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 09 Nov 2014 00:30:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,345,1413270000"; d="scan'208";a="619530635"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by fmsmga001.fm.intel.com with ESMTP; 09 Nov 2014 00:30:11 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Sun, 9 Nov 2014 16:30:10 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.130]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.62]) with mapi id
	14.03.0195.001; Sun, 9 Nov 2014 16:30:09 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Emil Condrea <emilcondrea@gmail.com>
Thread-Topic: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
Thread-Index: AQHP+gyQogoroHdVBUOna8rL71CGzpxUYzsQgAARkYCAA4WJQA==
Date: Sun, 9 Nov 2014 08:30:08 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8278EA@SHSMSX101.ccr.corp.intel.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>	<545BEE4F.3080305@tycho.nsa.gov>
	<945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
	<CAAULxKL+z_p_JcN5pBySiQzRBP5Jc-2w+oRcg81jgkTshAQDiw@mail.gmail.com>
In-Reply-To: <CAAULxKL+z_p_JcN5pBySiQzRBP5Jc-2w+oRcg81jgkTshAQDiw@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: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T2theSwgSSB3aWxsIHRlc3QgaXQgaW4gbmV4dCB3ZWVrLiANCg0KVGhhbmtzIA0KUXVhbiBYdQ0K
DQoNCkZyb206IHhlbi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbi5vcmcgW21haWx0bzp4ZW4tZGV2
ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnXSBPbiBCZWhhbGYgT2YgRW1pbCBDb25kcmVhDQpTZW50
OiBGcmlkYXksIE5vdmVtYmVyIDA3LCAyMDE0IDY6NDIgUE0NClRvOiBYdSwgUXVhbg0KQ2M6IERh
bmllbCBEZSBHcmFhZjsgSWFuIENhbXBiZWxsOyB4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZw0KU3Vi
amVjdDogUmU6IFtYZW4tZGV2ZWxdIHZ0cG1tZ3IgYnVnOiBmYWlscyB0byBzdGFydCBpZiBsb2Nh
bGl0eSE9MA0KDQpYdSwgbXkgc3lzdGVtIGRvZXMgbm90IHN1cHBvcnQgRFJUTSBsYXVuY2ggc28g
aWYgeW91IGNhbiB0ZXN0IGl0IG5leHQgd2VlayBpdCB3b3VsZCBiZSBncmVhdC4NClRoYW5rcw0K
DQpPbiBGcmksIE5vdiA3LCAyMDE0IGF0IDM6NDYgQU0sIFh1LCBRdWFuIDxxdWFuLnh1QGludGVs
LmNvbT4gd3JvdGU6DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB4
ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnDQo+IFttYWlsdG86eGVuLWRldmVsLWJvdW5j
ZXNAbGlzdHMueGVuLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBEZSBHcmFhZg0KPiBTZW50OiBG
cmlkYXksIE5vdmVtYmVyIDA3LCAyMDE0IDU6NTUgQU0NCj4gVG86IEVtaWwgQ29uZHJlYQ0KPiBD
YzogSWFuIENhbXBiZWxsOyB4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZw0KPiBTdWJqZWN0OiBSZTog
W1hlbi1kZXZlbF0gdnRwbW1nciBidWc6IGZhaWxzIHRvIHN0YXJ0IGlmIGxvY2FsaXR5IT0wDQo+
DQo+IE9uIDExLzA1LzIwMTQgMDU6MDAgQU0sIElhbiBDYW1wYmVsbCB3cm90ZToNCj4gPiBDQ2lu
ZyBEYW5pZWwuDQo+ID4NCj4gPiBPbiBGcmksIDIwMTQtMTAtMzEgYXQgMTc6MzcgKzAyMDAsIEVt
aWwgQ29uZHJlYSB3cm90ZToNCj4gPj4NCj4gPj4gSSBhbSB3b25kZXJpbmcgaWYgdGhpcyBpcyBr
bm93biBpc3N1ZSB0aGF0IHdoZW4gSSBzZXQgbG9jYWxpdHkhPTAgdG8NCj4gPj4gdnRwbW1nciBp
dCBkb2VzIG5vdCBzdGFydC4gSXQgaXMgYSBiaXQgc3RyYW5nZSB0aGF0IGV2ZXJ5IGNhbGwgdG8N
Cj4gPj4gdHBtX3Rpc19zdGF0dXMgcmV0dXJucyAyNTUgYW5kIGRldmljZS1pZCBpcyBhbHNvIEZG
RkY6DQo+ID4+IDEuMiBUUE0gKGRldmljZS1pZD0weEZGRkYgdmVuZG9yLWlkID0gRkZGRiByZXYt
aWQgPSBGRikuDQo+ID4+IFRQTSBpbnRlcmZhY2UgY2FwYWJpbGl0aWVzICgweGZmZmZmZmZmKToN
Cj4gPj4NCj4gPj4gSSBhbSBjb25maWd1cmluZyB2dHBtbWdyIHVzaW5nOg0KPiA+Pg0KPiA+PiBr
ZXJuZWw9Ii91c3IvbG9jYWwvbGliL3hlbi9ib290L3Z0cG1tZ3Itc3R1YmRvbS5neiINCj4gPj4g
bWVtb3J5PTgNCj4gPj4gZGlzaz1bImZpbGU6L3Zhci92dHBtbWdyLXN0dWJkb20uaW1nLGhkYSx3
Il0NCj4gPj4gbmFtZT0idnRwbW1nciINCj4gPj4gaW9tZW09WyJmZWQ0MCw1Il0NCj4gPj4gZXh0
cmE9InRwbWxvY2FsaXR5PTIiDQo+ID4+DQo+ID4+DQo+ID4+IEkgYWxzbyB0cmllZCB1c2luZyA6
DQo+ID4+IGlvbWVtPVsiZmVkNDAsMSJdDQo+ID4+IGV4dHJhPSJ0cG1sb2NhbGl0eT0wIi8vd29y
a3Mgd2VsbA0KPiA+Pg0KPiA+PiBvcg0KPiA+PiBpb21lbT1bImZlZDQyLDEiXQ0KPiA+PiBleHRy
YT0idHBtbG9jYWxpdHk9MiINCj4gPj4gSXQgc2VlbXMgdGhhdCBldmVyeXRoaW5nIHRoYXQgaXMg
bm90IG1hcHBlZCBhdCBmZWQ0MC1mZWQ0MSBpcw0KPiA+PiBGRkZGRkZGRi4NCj4gPj4NCj4gPj4g
SSBoYXZlIGFuIEF0bWVsIFRQTSBjaGlwc2V0Lg0KPiA+Pg0KPiA+PiBDb3VsZCBpdCBiZSBhIGNo
aXBzZXQgcHJvYmxlbSB0byBub3QgaGFuZGxlIHdlbGwgZGlmZmVyZW50IGxvY2FsaXRpZXM/DQo+
ID4+DQo+ID4+IFdoZW4gSSB1c2UgbG9jYWxpdHk9MCwgdGhlIGRldmljZSBkcml2ZXIgaW5mbyBp
cyBjb3JyZWN0IGFuZA0KPiA+PiBldmVyeXRoaW5nIHdvcmtzIGZpbmU6DQo+ID4+IDEuMiBUUE0g
KGRldmljZS1pZD0weDMyMDQgdmVuZG9yLWlkID0gMTExNCByZXYtaWQgPSA0MCkgVFBNIGludGVy
ZmFjZQ0KPiA+PiBjYXBhYmlsaXRpZXMgKDB4ZmQpDQo+DQo+IFRoaXMgbWF5IGJlIGFuIGlzc3Vl
IHdpdGggbG9jYWxpdHkgMiBiZWluZyB1bmF2YWlsYWJsZSB1bmxlc3MgYSBEUlRNIGxhdW5jaA0K
PiAodGJvb3QpIGlzIHBlcmZvcm1lZC7CoCBSZXR1cm5pbmcgYWxsLW9uZXMgaXMgdGhlIG5vcm1h
bCByZXNwb25zZSBvZiB0aGUgeDg2DQo+IGNoaXBzZXQgd2hlbiB1bm1hcHBlZCBNTUlPIHJlZ2lv
bnMgYXJlIGFjY2Vzc2VkOyBkaXNhYmxlZCBsb2NhbGl0aWVzIG9mDQo+IHRoZSBUUE0gbWF5IGFj
dCBsaWtlIHRoaXMuDQo+DQo+IERvZXMgeW91ciBzeXN0ZW0gc3VwcG9ydCB0aGUgRFJUTSBsYXVu
Y2g/wqAgSWYgc28sIGNhbiB5b3UgdGVzdCBpdCB0byBzZWUgaWYNCj4gdGhpcyBpcyB0aGUgaXNz
dWU/DQoNCkVtaWwsDQp0Ym9vdCBzdXBwb3J0cyBJbnRlbCBhbmQgT0VNIHN5c3RlbXMgdGhhdCBh
cmUgSW50ZWwgVFhULWNhcGFibGUuDQpJZiB5b3VyIHN5c3RlbSBkb2VzIG5vdCBzdXBwb3J0IERS
VE0gbGF1bmNoLCBJIGNhbiB0ZXN0IGl0IGluIG5leHQgd2Vlay4NCg0KDQo+DQo+IEluIHRoaXMg
Y2FzZSwgdG8gYmV0dGVyIHN1cHBvcnQgcGVvcGxlIHdobyB3YW50IHRvIHVzZSB0aGUgdlRQTSBN
YW5hZ2VyDQo+IHdpdGhvdXQgYSBEUlRNIGxhdW5jaCwgdGhlIGZlYXR1cmVzIG9mIHRoZSB2VFBN
IE1hbmFnZXIgdGhhdCB1c2UgdGhlIFRQTQ0KPiAxLjIgUENScyBtYXkgbmVlZCB0byBiZSBkaXNh
YmxlZCBvciBpbXBsZW1lbnRlZCBpbiBhbiBhbHRlcm5hdGUgbWFubmVyDQo+IHN1Y2ggYXMgZW1i
ZWRkaW5nIHRoZSBkYXRhIGluIHRoZSBxdW90ZSBpbnN0ZWFkIG9mIGluIFBDUnMuwqAgVGhlIGN1
cnJlbnQNCj4gZGVzaWduIHdhcyBjcmVhdGVkIHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCBzeXN0
ZW1zIHVzaW5nIGl0IHdvdWxkIGJlDQo+IHBlcmZvcm1pbmcgYSBEUlRNIGxhdW5jaCBpbiBvcmRl
ciB0byBmdWxseSBzZWN1cmUgdGhlIGJvb3QgcHJvY2Vzcy4NCj4NCj4gPj4gSW4gbGludXgga2Vy
bmVsIHRoaXMgaW5mb3JtYXRpb24gaXMgb2J0YWluZWQgdXNpbmcgbG9jYWxpdHkgMCBhbmQNCj4g
Pj4gYWZ0ZXIgdGhhdCBvdGhlciBjb21tYW5kcyBleGVjdXRlIHVzaW5nIHNwZWNpZmllZCBsb2Nh
bGl0eS4NCj4gPj4gaHR0cHM6Ly9naXQua2VybmVsLm9yZy9jZ2l0L2xpbnV4L2tlcm5lbC9naXQv
c3RhYmxlL2xpbnV4LXN0YWJsZS5naXQvDQo+ID4+IHRyZWUvZHJpdmVycy9jaGFyL3RwbS90cG1f
dGlzLmMjbjU1OA0KPg0KPiBIYXZlIHlvdSB0ZXN0ZWQgdGhhdCBvdGhlciBsb2NhbGl0aWVzIHdv
cmsgZm9yIHlvdXIgVFBNIHVuZGVyIExpbnV4Pw0KPg0KPiA+Pg0KPiA+PiBUaGFua3MsDQo+ID4+
DQo+ID4+IEVtaWwNCj4gPj4NCj4NCj4gLS0NCj4gRGFuaWVsIERlIEdyYWFmDQo+IE5hdGlvbmFs
IFNlY3VyaXR5IEFnZW5jeQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0DQo+IFhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnDQo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbA0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Sun Nov 09 08:30:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 08:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnNt4-0002XQ-GL; Sun, 09 Nov 2014 08:30:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XnNt2-0002XL-PL
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 08:30:16 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	A7/E5-17958-8162F545; Sun, 09 Nov 2014 08:30:16 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415521814!11347205!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29003 invoked from network); 9 Nov 2014 08:30:14 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-31.messagelabs.com with SMTP;
	9 Nov 2014 08:30:14 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 09 Nov 2014 00:30:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,345,1413270000"; d="scan'208";a="619530635"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by fmsmga001.fm.intel.com with ESMTP; 09 Nov 2014 00:30:11 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Sun, 9 Nov 2014 16:30:10 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.130]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.62]) with mapi id
	14.03.0195.001; Sun, 9 Nov 2014 16:30:09 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Emil Condrea <emilcondrea@gmail.com>
Thread-Topic: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
Thread-Index: AQHP+gyQogoroHdVBUOna8rL71CGzpxUYzsQgAARkYCAA4WJQA==
Date: Sun, 9 Nov 2014 08:30:08 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8278EA@SHSMSX101.ccr.corp.intel.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>	<545BEE4F.3080305@tycho.nsa.gov>
	<945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
	<CAAULxKL+z_p_JcN5pBySiQzRBP5Jc-2w+oRcg81jgkTshAQDiw@mail.gmail.com>
In-Reply-To: <CAAULxKL+z_p_JcN5pBySiQzRBP5Jc-2w+oRcg81jgkTshAQDiw@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: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T2theSwgSSB3aWxsIHRlc3QgaXQgaW4gbmV4dCB3ZWVrLiANCg0KVGhhbmtzIA0KUXVhbiBYdQ0K
DQoNCkZyb206IHhlbi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbi5vcmcgW21haWx0bzp4ZW4tZGV2
ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnXSBPbiBCZWhhbGYgT2YgRW1pbCBDb25kcmVhDQpTZW50
OiBGcmlkYXksIE5vdmVtYmVyIDA3LCAyMDE0IDY6NDIgUE0NClRvOiBYdSwgUXVhbg0KQ2M6IERh
bmllbCBEZSBHcmFhZjsgSWFuIENhbXBiZWxsOyB4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZw0KU3Vi
amVjdDogUmU6IFtYZW4tZGV2ZWxdIHZ0cG1tZ3IgYnVnOiBmYWlscyB0byBzdGFydCBpZiBsb2Nh
bGl0eSE9MA0KDQpYdSwgbXkgc3lzdGVtIGRvZXMgbm90IHN1cHBvcnQgRFJUTSBsYXVuY2ggc28g
aWYgeW91IGNhbiB0ZXN0IGl0IG5leHQgd2VlayBpdCB3b3VsZCBiZSBncmVhdC4NClRoYW5rcw0K
DQpPbiBGcmksIE5vdiA3LCAyMDE0IGF0IDM6NDYgQU0sIFh1LCBRdWFuIDxxdWFuLnh1QGludGVs
LmNvbT4gd3JvdGU6DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB4
ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnDQo+IFttYWlsdG86eGVuLWRldmVsLWJvdW5j
ZXNAbGlzdHMueGVuLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBEZSBHcmFhZg0KPiBTZW50OiBG
cmlkYXksIE5vdmVtYmVyIDA3LCAyMDE0IDU6NTUgQU0NCj4gVG86IEVtaWwgQ29uZHJlYQ0KPiBD
YzogSWFuIENhbXBiZWxsOyB4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZw0KPiBTdWJqZWN0OiBSZTog
W1hlbi1kZXZlbF0gdnRwbW1nciBidWc6IGZhaWxzIHRvIHN0YXJ0IGlmIGxvY2FsaXR5IT0wDQo+
DQo+IE9uIDExLzA1LzIwMTQgMDU6MDAgQU0sIElhbiBDYW1wYmVsbCB3cm90ZToNCj4gPiBDQ2lu
ZyBEYW5pZWwuDQo+ID4NCj4gPiBPbiBGcmksIDIwMTQtMTAtMzEgYXQgMTc6MzcgKzAyMDAsIEVt
aWwgQ29uZHJlYSB3cm90ZToNCj4gPj4NCj4gPj4gSSBhbSB3b25kZXJpbmcgaWYgdGhpcyBpcyBr
bm93biBpc3N1ZSB0aGF0IHdoZW4gSSBzZXQgbG9jYWxpdHkhPTAgdG8NCj4gPj4gdnRwbW1nciBp
dCBkb2VzIG5vdCBzdGFydC4gSXQgaXMgYSBiaXQgc3RyYW5nZSB0aGF0IGV2ZXJ5IGNhbGwgdG8N
Cj4gPj4gdHBtX3Rpc19zdGF0dXMgcmV0dXJucyAyNTUgYW5kIGRldmljZS1pZCBpcyBhbHNvIEZG
RkY6DQo+ID4+IDEuMiBUUE0gKGRldmljZS1pZD0weEZGRkYgdmVuZG9yLWlkID0gRkZGRiByZXYt
aWQgPSBGRikuDQo+ID4+IFRQTSBpbnRlcmZhY2UgY2FwYWJpbGl0aWVzICgweGZmZmZmZmZmKToN
Cj4gPj4NCj4gPj4gSSBhbSBjb25maWd1cmluZyB2dHBtbWdyIHVzaW5nOg0KPiA+Pg0KPiA+PiBr
ZXJuZWw9Ii91c3IvbG9jYWwvbGliL3hlbi9ib290L3Z0cG1tZ3Itc3R1YmRvbS5neiINCj4gPj4g
bWVtb3J5PTgNCj4gPj4gZGlzaz1bImZpbGU6L3Zhci92dHBtbWdyLXN0dWJkb20uaW1nLGhkYSx3
Il0NCj4gPj4gbmFtZT0idnRwbW1nciINCj4gPj4gaW9tZW09WyJmZWQ0MCw1Il0NCj4gPj4gZXh0
cmE9InRwbWxvY2FsaXR5PTIiDQo+ID4+DQo+ID4+DQo+ID4+IEkgYWxzbyB0cmllZCB1c2luZyA6
DQo+ID4+IGlvbWVtPVsiZmVkNDAsMSJdDQo+ID4+IGV4dHJhPSJ0cG1sb2NhbGl0eT0wIi8vd29y
a3Mgd2VsbA0KPiA+Pg0KPiA+PiBvcg0KPiA+PiBpb21lbT1bImZlZDQyLDEiXQ0KPiA+PiBleHRy
YT0idHBtbG9jYWxpdHk9MiINCj4gPj4gSXQgc2VlbXMgdGhhdCBldmVyeXRoaW5nIHRoYXQgaXMg
bm90IG1hcHBlZCBhdCBmZWQ0MC1mZWQ0MSBpcw0KPiA+PiBGRkZGRkZGRi4NCj4gPj4NCj4gPj4g
SSBoYXZlIGFuIEF0bWVsIFRQTSBjaGlwc2V0Lg0KPiA+Pg0KPiA+PiBDb3VsZCBpdCBiZSBhIGNo
aXBzZXQgcHJvYmxlbSB0byBub3QgaGFuZGxlIHdlbGwgZGlmZmVyZW50IGxvY2FsaXRpZXM/DQo+
ID4+DQo+ID4+IFdoZW4gSSB1c2UgbG9jYWxpdHk9MCwgdGhlIGRldmljZSBkcml2ZXIgaW5mbyBp
cyBjb3JyZWN0IGFuZA0KPiA+PiBldmVyeXRoaW5nIHdvcmtzIGZpbmU6DQo+ID4+IDEuMiBUUE0g
KGRldmljZS1pZD0weDMyMDQgdmVuZG9yLWlkID0gMTExNCByZXYtaWQgPSA0MCkgVFBNIGludGVy
ZmFjZQ0KPiA+PiBjYXBhYmlsaXRpZXMgKDB4ZmQpDQo+DQo+IFRoaXMgbWF5IGJlIGFuIGlzc3Vl
IHdpdGggbG9jYWxpdHkgMiBiZWluZyB1bmF2YWlsYWJsZSB1bmxlc3MgYSBEUlRNIGxhdW5jaA0K
PiAodGJvb3QpIGlzIHBlcmZvcm1lZC7CoCBSZXR1cm5pbmcgYWxsLW9uZXMgaXMgdGhlIG5vcm1h
bCByZXNwb25zZSBvZiB0aGUgeDg2DQo+IGNoaXBzZXQgd2hlbiB1bm1hcHBlZCBNTUlPIHJlZ2lv
bnMgYXJlIGFjY2Vzc2VkOyBkaXNhYmxlZCBsb2NhbGl0aWVzIG9mDQo+IHRoZSBUUE0gbWF5IGFj
dCBsaWtlIHRoaXMuDQo+DQo+IERvZXMgeW91ciBzeXN0ZW0gc3VwcG9ydCB0aGUgRFJUTSBsYXVu
Y2g/wqAgSWYgc28sIGNhbiB5b3UgdGVzdCBpdCB0byBzZWUgaWYNCj4gdGhpcyBpcyB0aGUgaXNz
dWU/DQoNCkVtaWwsDQp0Ym9vdCBzdXBwb3J0cyBJbnRlbCBhbmQgT0VNIHN5c3RlbXMgdGhhdCBh
cmUgSW50ZWwgVFhULWNhcGFibGUuDQpJZiB5b3VyIHN5c3RlbSBkb2VzIG5vdCBzdXBwb3J0IERS
VE0gbGF1bmNoLCBJIGNhbiB0ZXN0IGl0IGluIG5leHQgd2Vlay4NCg0KDQo+DQo+IEluIHRoaXMg
Y2FzZSwgdG8gYmV0dGVyIHN1cHBvcnQgcGVvcGxlIHdobyB3YW50IHRvIHVzZSB0aGUgdlRQTSBN
YW5hZ2VyDQo+IHdpdGhvdXQgYSBEUlRNIGxhdW5jaCwgdGhlIGZlYXR1cmVzIG9mIHRoZSB2VFBN
IE1hbmFnZXIgdGhhdCB1c2UgdGhlIFRQTQ0KPiAxLjIgUENScyBtYXkgbmVlZCB0byBiZSBkaXNh
YmxlZCBvciBpbXBsZW1lbnRlZCBpbiBhbiBhbHRlcm5hdGUgbWFubmVyDQo+IHN1Y2ggYXMgZW1i
ZWRkaW5nIHRoZSBkYXRhIGluIHRoZSBxdW90ZSBpbnN0ZWFkIG9mIGluIFBDUnMuwqAgVGhlIGN1
cnJlbnQNCj4gZGVzaWduIHdhcyBjcmVhdGVkIHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCBzeXN0
ZW1zIHVzaW5nIGl0IHdvdWxkIGJlDQo+IHBlcmZvcm1pbmcgYSBEUlRNIGxhdW5jaCBpbiBvcmRl
ciB0byBmdWxseSBzZWN1cmUgdGhlIGJvb3QgcHJvY2Vzcy4NCj4NCj4gPj4gSW4gbGludXgga2Vy
bmVsIHRoaXMgaW5mb3JtYXRpb24gaXMgb2J0YWluZWQgdXNpbmcgbG9jYWxpdHkgMCBhbmQNCj4g
Pj4gYWZ0ZXIgdGhhdCBvdGhlciBjb21tYW5kcyBleGVjdXRlIHVzaW5nIHNwZWNpZmllZCBsb2Nh
bGl0eS4NCj4gPj4gaHR0cHM6Ly9naXQua2VybmVsLm9yZy9jZ2l0L2xpbnV4L2tlcm5lbC9naXQv
c3RhYmxlL2xpbnV4LXN0YWJsZS5naXQvDQo+ID4+IHRyZWUvZHJpdmVycy9jaGFyL3RwbS90cG1f
dGlzLmMjbjU1OA0KPg0KPiBIYXZlIHlvdSB0ZXN0ZWQgdGhhdCBvdGhlciBsb2NhbGl0aWVzIHdv
cmsgZm9yIHlvdXIgVFBNIHVuZGVyIExpbnV4Pw0KPg0KPiA+Pg0KPiA+PiBUaGFua3MsDQo+ID4+
DQo+ID4+IEVtaWwNCj4gPj4NCj4NCj4gLS0NCj4gRGFuaWVsIERlIEdyYWFmDQo+IE5hdGlvbmFs
IFNlY3VyaXR5IEFnZW5jeQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0DQo+IFhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnDQo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbA0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Sun Nov 09 09:02:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 09: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 1XnONW-0002rp-3W; Sun, 09 Nov 2014 09:01: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@citrix.com>) id 1XnONU-0002q7-Mp
	for xen-devel@lists.xensource.com; Sun, 09 Nov 2014 09:01:44 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	2D/9A-01660-77D2F545; Sun, 09 Nov 2014 09:01:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415523701!11387949!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1669 invoked from network); 9 Nov 2014 09:01:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 09:01:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,345,1413244800"; d="scan'208";a="190954099"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 9 Nov 2014 04:01:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnONP-00069f-Of;
	Sun, 09 Nov 2014 09:01:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnONP-0005xE-IH;
	Sun, 09 Nov 2014 09:01:39 +0000
Date: Sun, 9 Nov 2014 09:01:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31444-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31444: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31444 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31444/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install      fail pass in 31438
 test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail in 31438 pass in 31444

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31438 never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 09 09:02:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 09: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 1XnONW-0002rp-3W; Sun, 09 Nov 2014 09:01: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@citrix.com>) id 1XnONU-0002q7-Mp
	for xen-devel@lists.xensource.com; Sun, 09 Nov 2014 09:01:44 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	2D/9A-01660-77D2F545; Sun, 09 Nov 2014 09:01:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415523701!11387949!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1669 invoked from network); 9 Nov 2014 09:01:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 09:01:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,345,1413244800"; d="scan'208";a="190954099"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 9 Nov 2014 04:01:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnONP-00069f-Of;
	Sun, 09 Nov 2014 09:01:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnONP-0005xE-IH;
	Sun, 09 Nov 2014 09:01:39 +0000
Date: Sun, 9 Nov 2014 09:01:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31444-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31444: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31444 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31444/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install      fail pass in 31438
 test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail in 31438 pass in 31444

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31438 never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 09 09:49:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 09:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnP7R-0003FX-3H; Sun, 09 Nov 2014 09:49:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnP7Q-0003FJ-4a
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 09:49:12 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	50/06-17958-7983F545; Sun, 09 Nov 2014 09:49:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415526549!11406239!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14967 invoked from network); 9 Nov 2014 09:49:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 09:49:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,345,1413244800"; d="scan'208";a="189517313"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Sun, 9 Nov 2014 04:49:03 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1XnP7H-0007Rl-37;
	Sun, 09 Nov 2014 09:49:04 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Sun, 09 Nov
	2014 09:49:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Sun, 9 Nov 2014 09:49:03 +0000
Message-ID: <1415526543-3465-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST] mg-debian-installer-update: Use
	Packages.gz
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jessie Packages.bz2 is replaced by Packages.xz. Rather than implementing
per-suite handling just fallback to lowest-common-denominator gzip.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 mg-debian-installer-update | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/mg-debian-installer-update b/mg-debian-installer-update
index 4af4a42..3ae50fb 100755
--- a/mg-debian-installer-update
+++ b/mg-debian-installer-update
@@ -49,7 +49,7 @@ case ${suite}_${arch} in
         ;;
 esac
 
-pfile=$sbase/non-free/binary-$arch/Packages.bz2
+pfile=$sbase/non-free/binary-$arch/Packages.gz
 
 dstroot=`getconfig TftpPath`/`getconfig TftpDiBase`/
 date=`date +%Y-%m-%d`-$suite
@@ -66,12 +66,12 @@ for f in $files; do
         curl -s $src/$s >$d.new
 done
 
-curl -s $pfile >Packages.bz2
+curl -s $pfile >Packages.gz
 
 for p in $packages; do
         set +e
         echo >&2 "collecting $p"
-        pkgfile=`bzcat Packages.bz2 | grep-dctrl -PX $p -nsFilename`
+        pkgfile=`zcat Packages.gz | grep-dctrl -PX $p -nsFilename`
         rc=$?
         set -e
         if [ $rc != 0 ]; then fail "package $p not found"; fi
@@ -89,13 +89,13 @@ done
 # wheezy-backports.
 if [ $arch = armhf ]; then
     bp="$sbase-backports"
-    pfile=$bp/main/binary-armhf/Packages.bz2
+    pfile=$bp/main/binary-armhf/Packages.gz
 
-    curl -s $pfile >Packages.bz2
+    curl -s $pfile >Packages.gz
 
     # Newer kernel often needs a newer initramfs-tools. Make that available
     echo >&2 "collecting backports initramfs-tools"
-    pkgfile=`bzcat Packages.bz2 | grep-dctrl -PX initramfs-tools -nsFilename | sort -n -r | head -n1`
+    pkgfile=`zcat Packages.gz | grep-dctrl -PX initramfs-tools -nsFilename | sort -n -r | head -n1`
     rc=$?
     set -e
     if [ $rc != 0 ]; then fail "initramfs-tools package not found"; fi
@@ -105,7 +105,7 @@ if [ $arch = armhf ]; then
     echo >&2 "collecting armmp kernel"
     # Be careful to pickup the actual kernel package from the 'linux'
     # source and not a meta package from 'linux-latest'
-    pkgfile=`bzcat Packages.bz2 | grep-dctrl -S linux | grep-dctrl -Pe ^linux-image-.*-armmp$ -nsFilename | sort -n -r | head -n1`
+    pkgfile=`zcat Packages.gz | grep-dctrl -S linux | grep-dctrl -Pe ^linux-image-.*-armmp$ -nsFilename | sort -n -r | head -n1`
     rc=$?
     set -e
     if [ $rc != 0 ]; then fail "armmp kernel package not found"; fi
@@ -150,7 +150,7 @@ for f in $files; do
         mv -f $d.new $d
 done
 
-rm Packages.bz2
+rm Packages.gz
 
 #cd $dstroot/$arch
 #rm -rf current.new
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 09:49:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 09:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnP76-0003Ef-N3; Sun, 09 Nov 2014 09:48: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 1XnP75-0003Ea-9l
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 09:48:51 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	33/7D-19763-2883F545; Sun, 09 Nov 2014 09:48:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415526528!11333911!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25939 invoked from network); 9 Nov 2014 09:48:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 09:48:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,345,1413244800"; d="scan'208";a="190957731"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Sun, 9 Nov 2014 04:48:47 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1XnP70-0007Ri-Kn;
	Sun, 09 Nov 2014 09:48:47 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Sun, 09 Nov
	2014 09:48:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Sun, 9 Nov 2014 09:48:46 +0000
Message-ID: <1415526526-3320-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST] Debian: Install ethtool on the hosts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 very useful when debugging network issues.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Debian.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8f80eb4..c8db601 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -492,7 +492,7 @@ d-i apt-setup/another boolean false
 d-i apt-setup/non-free boolean false
 d-i apt-setup/contrib boolean false
 
-d-i pkgsel/include string openssh-server, ntp, ntpdate, $extra_packages
+d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, $extra_packages
 
 $xopts{ExtraPreseed}
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 09:49:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 09:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnP7R-0003FX-3H; Sun, 09 Nov 2014 09:49:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnP7Q-0003FJ-4a
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 09:49:12 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	50/06-17958-7983F545; Sun, 09 Nov 2014 09:49:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415526549!11406239!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14967 invoked from network); 9 Nov 2014 09:49:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 09:49:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,345,1413244800"; d="scan'208";a="189517313"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Sun, 9 Nov 2014 04:49:03 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1XnP7H-0007Rl-37;
	Sun, 09 Nov 2014 09:49:04 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Sun, 09 Nov
	2014 09:49:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Sun, 9 Nov 2014 09:49:03 +0000
Message-ID: <1415526543-3465-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST] mg-debian-installer-update: Use
	Packages.gz
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jessie Packages.bz2 is replaced by Packages.xz. Rather than implementing
per-suite handling just fallback to lowest-common-denominator gzip.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 mg-debian-installer-update | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/mg-debian-installer-update b/mg-debian-installer-update
index 4af4a42..3ae50fb 100755
--- a/mg-debian-installer-update
+++ b/mg-debian-installer-update
@@ -49,7 +49,7 @@ case ${suite}_${arch} in
         ;;
 esac
 
-pfile=$sbase/non-free/binary-$arch/Packages.bz2
+pfile=$sbase/non-free/binary-$arch/Packages.gz
 
 dstroot=`getconfig TftpPath`/`getconfig TftpDiBase`/
 date=`date +%Y-%m-%d`-$suite
@@ -66,12 +66,12 @@ for f in $files; do
         curl -s $src/$s >$d.new
 done
 
-curl -s $pfile >Packages.bz2
+curl -s $pfile >Packages.gz
 
 for p in $packages; do
         set +e
         echo >&2 "collecting $p"
-        pkgfile=`bzcat Packages.bz2 | grep-dctrl -PX $p -nsFilename`
+        pkgfile=`zcat Packages.gz | grep-dctrl -PX $p -nsFilename`
         rc=$?
         set -e
         if [ $rc != 0 ]; then fail "package $p not found"; fi
@@ -89,13 +89,13 @@ done
 # wheezy-backports.
 if [ $arch = armhf ]; then
     bp="$sbase-backports"
-    pfile=$bp/main/binary-armhf/Packages.bz2
+    pfile=$bp/main/binary-armhf/Packages.gz
 
-    curl -s $pfile >Packages.bz2
+    curl -s $pfile >Packages.gz
 
     # Newer kernel often needs a newer initramfs-tools. Make that available
     echo >&2 "collecting backports initramfs-tools"
-    pkgfile=`bzcat Packages.bz2 | grep-dctrl -PX initramfs-tools -nsFilename | sort -n -r | head -n1`
+    pkgfile=`zcat Packages.gz | grep-dctrl -PX initramfs-tools -nsFilename | sort -n -r | head -n1`
     rc=$?
     set -e
     if [ $rc != 0 ]; then fail "initramfs-tools package not found"; fi
@@ -105,7 +105,7 @@ if [ $arch = armhf ]; then
     echo >&2 "collecting armmp kernel"
     # Be careful to pickup the actual kernel package from the 'linux'
     # source and not a meta package from 'linux-latest'
-    pkgfile=`bzcat Packages.bz2 | grep-dctrl -S linux | grep-dctrl -Pe ^linux-image-.*-armmp$ -nsFilename | sort -n -r | head -n1`
+    pkgfile=`zcat Packages.gz | grep-dctrl -S linux | grep-dctrl -Pe ^linux-image-.*-armmp$ -nsFilename | sort -n -r | head -n1`
     rc=$?
     set -e
     if [ $rc != 0 ]; then fail "armmp kernel package not found"; fi
@@ -150,7 +150,7 @@ for f in $files; do
         mv -f $d.new $d
 done
 
-rm Packages.bz2
+rm Packages.gz
 
 #cd $dstroot/$arch
 #rm -rf current.new
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 09:49:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 09:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnP76-0003Ef-N3; Sun, 09 Nov 2014 09:48: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 1XnP75-0003Ea-9l
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 09:48:51 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	33/7D-19763-2883F545; Sun, 09 Nov 2014 09:48:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415526528!11333911!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25939 invoked from network); 9 Nov 2014 09:48:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 09:48:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,345,1413244800"; d="scan'208";a="190957731"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Sun, 9 Nov 2014 04:48:47 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1XnP70-0007Ri-Kn;
	Sun, 09 Nov 2014 09:48:47 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Sun, 09 Nov
	2014 09:48:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Sun, 9 Nov 2014 09:48:46 +0000
Message-ID: <1415526526-3320-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST] Debian: Install ethtool on the hosts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 very useful when debugging network issues.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Debian.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8f80eb4..c8db601 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -492,7 +492,7 @@ d-i apt-setup/another boolean false
 d-i apt-setup/non-free boolean false
 d-i apt-setup/contrib boolean false
 
-d-i pkgsel/include string openssh-server, ntp, ntpdate, $extra_packages
+d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, $extra_packages
 
 $xopts{ExtraPreseed}
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 09:49:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 09:49:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnP7a-0003HU-Fr; Sun, 09 Nov 2014 09:49: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 1XnP7Y-0003Gf-Cb
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 09:49:20 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	DA/E8-29352-F983F545; Sun, 09 Nov 2014 09:49:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415526557!11364949!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31011 invoked from network); 9 Nov 2014 09:49:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 09:49:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,345,1413244800"; d="scan'208";a="190957755"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Sun, 9 Nov 2014 04:49:16 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1XnP7T-0007Sb-RQ;
	Sun, 09 Nov 2014 09:49:16 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Sun, 09 Nov
	2014 09:49:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Sun, 9 Nov 2014 09:49:15 +0000
Message-ID: <1415526555-3609-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST] ts-host-install: Ensure $dtbs is always
	a valid 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

Otherwise on non-ARM platforms we get warnings about uninitialised values.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-host-install | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ts-host-install b/ts-host-install
index 5840e27..c39c5e7 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -196,8 +196,9 @@ SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$ho->{Ether}", A
 END
     }
 
-    my $dtbs = "fdtdir /$d_i/dtbs"
-	if -e "$ho->{Tftp}{Path}/$d_i/dtbs";
+    my $dtbs = "";
+    $dtbs = "fdtdir /$d_i/dtbs"
+	if -e  "fdtdir /$d_i/dtbs""$ho->{Tftp}{Path}/$d_i/dtbs";
 
     file_simple_write_contents("$initrd_overlay.cpio", sub {
         contents_make_cpio($_[0], 'newc', "$initrd_overlay.d");
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 09:49:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 09:49:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnP7a-0003HU-Fr; Sun, 09 Nov 2014 09:49: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 1XnP7Y-0003Gf-Cb
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 09:49:20 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	DA/E8-29352-F983F545; Sun, 09 Nov 2014 09:49:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415526557!11364949!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31011 invoked from network); 9 Nov 2014 09:49:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 09:49:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,345,1413244800"; d="scan'208";a="190957755"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Sun, 9 Nov 2014 04:49:16 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1XnP7T-0007Sb-RQ;
	Sun, 09 Nov 2014 09:49:16 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Sun, 09 Nov
	2014 09:49:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Sun, 9 Nov 2014 09:49:15 +0000
Message-ID: <1415526555-3609-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST] ts-host-install: Ensure $dtbs is always
	a valid 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

Otherwise on non-ARM platforms we get warnings about uninitialised values.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-host-install | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ts-host-install b/ts-host-install
index 5840e27..c39c5e7 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -196,8 +196,9 @@ SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$ho->{Ether}", A
 END
     }
 
-    my $dtbs = "fdtdir /$d_i/dtbs"
-	if -e "$ho->{Tftp}{Path}/$d_i/dtbs";
+    my $dtbs = "";
+    $dtbs = "fdtdir /$d_i/dtbs"
+	if -e  "fdtdir /$d_i/dtbs""$ho->{Tftp}{Path}/$d_i/dtbs";
 
     file_simple_write_contents("$initrd_overlay.cpio", sub {
         contents_make_cpio($_[0], 'newc', "$initrd_overlay.d");
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 15:10:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 15:10:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnU81-0005al-DP; Sun, 09 Nov 2014 15:10:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiang.liu@linux.intel.com>) id 1XnU7z-0005aV-LX
	for xen-devel@lists.xenproject.org; Sun, 09 Nov 2014 15:10:07 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	EC/C3-17958-EC38F545; Sun, 09 Nov 2014 15:10:06 +0000
X-Env-Sender: jiang.liu@linux.intel.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415545804!11380471!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32082 invoked from network); 9 Nov 2014 15:10:06 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-31.messagelabs.com with SMTP;
	9 Nov 2014 15:10:06 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 09 Nov 2014 07:09:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,346,1413270000"; d="scan'208";a="604933294"
Received: from gerry-dev.bj.intel.com ([10.238.158.52])
	by orsmga001.jf.intel.com with ESMTP; 09 Nov 2014 07:09:41 -0800
From: Jiang Liu <jiang.liu@linux.intel.com>
To: Bjorn Helgaas <bhelgaas@google.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Randy Dunlap <rdunlap@infradead.org>, Yinghai Lu <yinghai@kernel.org>,
	Borislav Petkov <bp@alien8.de>, Grant Likely <grant.likely@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Yingjoe Chen <yingjoe.chen@mediatek.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Jiang Liu <jiang.liu@linux.intel.com>, Yijing Wang <wangyijing@huawei.com>,
	Alexander Gordeev <agordeev@redhat.com>
Date: Sun,  9 Nov 2014 23:10:34 +0800
Message-Id: <1415545839-28263-13-git-send-email-jiang.liu@linux.intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415545839-28263-1-git-send-email-jiang.liu@linux.intel.com>
References: <1415545839-28263-1-git-send-email-jiang.liu@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Joerg Roedel <joro@8bytes.org>, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org, Andrew Morton <akpm@linux-foundation.org>,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [RFC Part4 v1 12/17] PCI,
	MSI: Rename __write_msi_msg() as __pci_write_msi_msg()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rename __write_msi_msg() as __pci_write_msi_msg() to mark it as PCI
specific. Also define pci_write_msi_msg() as write_msi_msg() for easy
transition.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 arch/x86/pci/xen.c  |    2 +-
 drivers/pci/msi.c   |    9 ++++-----
 include/linux/msi.h |    3 ++-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index a48ca2f8b93e..1cfbe32c4b1c 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -240,7 +240,7 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 				goto error;
 			}
 			xen_msi_compose_msg(dev, pirq, &msg);
-			__write_msi_msg(msidesc, &msg);
+			__pci_write_msi_msg(msidesc, &msg);
 			dev_dbg(&dev->dev, "xen: msi bound to pirq=%d\n", pirq);
 		} else {
 			dev_dbg(&dev->dev,
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 6011dfb475a1..80be534df522 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -27,7 +27,6 @@ static int pci_msi_enable = 1;
 
 #define msix_table_size(flags)	((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
 
-
 /* Arch hooks */
 
 int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
@@ -115,7 +114,7 @@ static void default_restore_msi_irq(struct pci_dev *dev, int irq)
 	}
 
 	if (entry)
-		__write_msi_msg(entry, &entry->msg);
+		__pci_write_msi_msg(entry, &entry->msg);
 }
 
 void __weak arch_restore_msi_irqs(struct pci_dev *dev)
@@ -273,7 +272,7 @@ void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 	}
 }
 
-void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
+void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
 	if (entry->dev->current_state != PCI_D0) {
 		/* Don't touch the hardware now */
@@ -314,7 +313,7 @@ void write_msi_msg(unsigned int irq, struct msi_msg *msg)
 {
 	struct msi_desc *entry = irq_get_msi_desc(irq);
 
-	__write_msi_msg(entry, msg);
+	__pci_write_msi_msg(entry, msg);
 }
 EXPORT_SYMBOL_GPL(write_msi_msg);
 
@@ -1085,7 +1084,7 @@ void pci_msi_write_msg(struct irq_data *irq_data, struct msi_msg *msg)
 	 * MSI message denotes a contiguous group of IRQs, written for 0th IRQ.
 	 */
 	if (desc->irq == irq_data->irq)
-		__write_msi_msg(desc, msg);
+		__pci_write_msi_msg(desc, msg);
 }
 
 /*
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 4b0d070ff481..5639970db71d 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -62,8 +62,9 @@ void msi_domain_deactivate(struct irq_domain *domain,
 #ifdef CONFIG_PCI_MSI
 /* Helper functions */
 void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
-void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
+void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
 void write_msi_msg(unsigned int irq, struct msi_msg *msg);
+#define pci_write_msi_msg	write_msi_msg
 
 /*
  * The arch hooks to setup up msi irqs. Those functions are
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 15:10:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 15:10:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnU7Z-0005ZU-0Y; Sun, 09 Nov 2014 15:09:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiang.liu@linux.intel.com>) id 1XnU7X-0005ZP-V5
	for xen-devel@lists.xenproject.org; Sun, 09 Nov 2014 15:09:40 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	5A/05-02953-3B38F545; Sun, 09 Nov 2014 15:09:39 +0000
X-Env-Sender: jiang.liu@linux.intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415545777!12311946!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11963 invoked from network); 9 Nov 2014 15:09:38 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-2.tower-27.messagelabs.com with SMTP;
	9 Nov 2014 15:09:38 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 09 Nov 2014 07:07:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,346,1413270000"; d="scan'208";a="604933271"
Received: from gerry-dev.bj.intel.com ([10.238.158.52])
	by orsmga001.jf.intel.com with ESMTP; 09 Nov 2014 07:09:30 -0800
From: Jiang Liu <jiang.liu@linux.intel.com>
To: Bjorn Helgaas <bhelgaas@google.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Randy Dunlap <rdunlap@infradead.org>, Yinghai Lu <yinghai@kernel.org>,
	Borislav Petkov <bp@alien8.de>, Grant Likely <grant.likely@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Yingjoe Chen <yingjoe.chen@mediatek.com>,
	Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Alexander Gordeev <agordeev@redhat.com>, Anton Blanchard <anton@samba.org>,
	Jiang Liu <jiang.liu@linux.intel.com>, Yijing Wang <wangyijing@huawei.com>
Date: Sun,  9 Nov 2014 23:10:33 +0800
Message-Id: <1415545839-28263-12-git-send-email-jiang.liu@linux.intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415545839-28263-1-git-send-email-jiang.liu@linux.intel.com>
References: <1415545839-28263-1-git-send-email-jiang.liu@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Joerg Roedel <joro@8bytes.org>, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org, Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [RFC Part4 v1 11/17] PCI,
	MSI: Rename __read_msi_msg() as __pci_read_msi_msg()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rename __read_msi_msg() as __pci_read_msi_msg() and kill unused
read_msi_msg(). It's a preparation to separate generic MSI code
from PCI core.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 arch/powerpc/platforms/pseries/msi.c |    2 +-
 arch/x86/pci/xen.c                   |    2 +-
 drivers/pci/msi.c                    |    9 +--------
 include/linux/msi.h                  |    3 +--
 4 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c
index 8ab5add4ac82..90f756d0f58f 100644
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -476,7 +476,7 @@ again:
 		irq_set_msi_desc(virq, entry);
 
 		/* Read config space back so we can restore after reset */
-		__read_msi_msg(entry, &msg);
+		__pci_read_msi_msg(entry, &msg);
 		entry->msg = msg;
 	}
 
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 093f5f4272d3..a48ca2f8b93e 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -229,7 +229,7 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 		return 1;
 
 	list_for_each_entry(msidesc, &dev->msi_list, list) {
-		__read_msi_msg(msidesc, &msg);
+		__pci_read_msi_msg(msidesc, &msg);
 		pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
 			((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
 		if (msg.data != XEN_PIRQ_MSI_DATA ||
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index e1814f4be4b9..6011dfb475a1 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -243,7 +243,7 @@ void default_restore_msi_irqs(struct pci_dev *dev)
 		default_restore_msi_irq(dev, entry->irq);
 }
 
-void __read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
+void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
 	BUG_ON(entry->dev->current_state != PCI_D0);
 
@@ -273,13 +273,6 @@ void __read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 	}
 }
 
-void read_msi_msg(unsigned int irq, struct msi_msg *msg)
-{
-	struct msi_desc *entry = irq_get_msi_desc(irq);
-
-	__read_msi_msg(entry, msg);
-}
-
 void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
 	if (entry->dev->current_state != PCI_D0) {
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 19502186a64d..4b0d070ff481 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -61,9 +61,8 @@ void msi_domain_deactivate(struct irq_domain *domain,
 
 #ifdef CONFIG_PCI_MSI
 /* Helper functions */
-void __read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
+void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
 void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
-void read_msi_msg(unsigned int irq, struct msi_msg *msg);
 void write_msi_msg(unsigned int irq, struct msi_msg *msg);
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 15:10:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 15:10:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnU81-0005al-DP; Sun, 09 Nov 2014 15:10:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiang.liu@linux.intel.com>) id 1XnU7z-0005aV-LX
	for xen-devel@lists.xenproject.org; Sun, 09 Nov 2014 15:10:07 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	EC/C3-17958-EC38F545; Sun, 09 Nov 2014 15:10:06 +0000
X-Env-Sender: jiang.liu@linux.intel.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415545804!11380471!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32082 invoked from network); 9 Nov 2014 15:10:06 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-31.messagelabs.com with SMTP;
	9 Nov 2014 15:10:06 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 09 Nov 2014 07:09:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,346,1413270000"; d="scan'208";a="604933294"
Received: from gerry-dev.bj.intel.com ([10.238.158.52])
	by orsmga001.jf.intel.com with ESMTP; 09 Nov 2014 07:09:41 -0800
From: Jiang Liu <jiang.liu@linux.intel.com>
To: Bjorn Helgaas <bhelgaas@google.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Randy Dunlap <rdunlap@infradead.org>, Yinghai Lu <yinghai@kernel.org>,
	Borislav Petkov <bp@alien8.de>, Grant Likely <grant.likely@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Yingjoe Chen <yingjoe.chen@mediatek.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Jiang Liu <jiang.liu@linux.intel.com>, Yijing Wang <wangyijing@huawei.com>,
	Alexander Gordeev <agordeev@redhat.com>
Date: Sun,  9 Nov 2014 23:10:34 +0800
Message-Id: <1415545839-28263-13-git-send-email-jiang.liu@linux.intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415545839-28263-1-git-send-email-jiang.liu@linux.intel.com>
References: <1415545839-28263-1-git-send-email-jiang.liu@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Joerg Roedel <joro@8bytes.org>, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org, Andrew Morton <akpm@linux-foundation.org>,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [RFC Part4 v1 12/17] PCI,
	MSI: Rename __write_msi_msg() as __pci_write_msi_msg()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rename __write_msi_msg() as __pci_write_msi_msg() to mark it as PCI
specific. Also define pci_write_msi_msg() as write_msi_msg() for easy
transition.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 arch/x86/pci/xen.c  |    2 +-
 drivers/pci/msi.c   |    9 ++++-----
 include/linux/msi.h |    3 ++-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index a48ca2f8b93e..1cfbe32c4b1c 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -240,7 +240,7 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 				goto error;
 			}
 			xen_msi_compose_msg(dev, pirq, &msg);
-			__write_msi_msg(msidesc, &msg);
+			__pci_write_msi_msg(msidesc, &msg);
 			dev_dbg(&dev->dev, "xen: msi bound to pirq=%d\n", pirq);
 		} else {
 			dev_dbg(&dev->dev,
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 6011dfb475a1..80be534df522 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -27,7 +27,6 @@ static int pci_msi_enable = 1;
 
 #define msix_table_size(flags)	((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
 
-
 /* Arch hooks */
 
 int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
@@ -115,7 +114,7 @@ static void default_restore_msi_irq(struct pci_dev *dev, int irq)
 	}
 
 	if (entry)
-		__write_msi_msg(entry, &entry->msg);
+		__pci_write_msi_msg(entry, &entry->msg);
 }
 
 void __weak arch_restore_msi_irqs(struct pci_dev *dev)
@@ -273,7 +272,7 @@ void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 	}
 }
 
-void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
+void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
 	if (entry->dev->current_state != PCI_D0) {
 		/* Don't touch the hardware now */
@@ -314,7 +313,7 @@ void write_msi_msg(unsigned int irq, struct msi_msg *msg)
 {
 	struct msi_desc *entry = irq_get_msi_desc(irq);
 
-	__write_msi_msg(entry, msg);
+	__pci_write_msi_msg(entry, msg);
 }
 EXPORT_SYMBOL_GPL(write_msi_msg);
 
@@ -1085,7 +1084,7 @@ void pci_msi_write_msg(struct irq_data *irq_data, struct msi_msg *msg)
 	 * MSI message denotes a contiguous group of IRQs, written for 0th IRQ.
 	 */
 	if (desc->irq == irq_data->irq)
-		__write_msi_msg(desc, msg);
+		__pci_write_msi_msg(desc, msg);
 }
 
 /*
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 4b0d070ff481..5639970db71d 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -62,8 +62,9 @@ void msi_domain_deactivate(struct irq_domain *domain,
 #ifdef CONFIG_PCI_MSI
 /* Helper functions */
 void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
-void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
+void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
 void write_msi_msg(unsigned int irq, struct msi_msg *msg);
+#define pci_write_msi_msg	write_msi_msg
 
 /*
  * The arch hooks to setup up msi irqs. Those functions are
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 15:10:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 15:10:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnU7Z-0005ZU-0Y; Sun, 09 Nov 2014 15:09:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiang.liu@linux.intel.com>) id 1XnU7X-0005ZP-V5
	for xen-devel@lists.xenproject.org; Sun, 09 Nov 2014 15:09:40 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	5A/05-02953-3B38F545; Sun, 09 Nov 2014 15:09:39 +0000
X-Env-Sender: jiang.liu@linux.intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415545777!12311946!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11963 invoked from network); 9 Nov 2014 15:09:38 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-2.tower-27.messagelabs.com with SMTP;
	9 Nov 2014 15:09:38 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 09 Nov 2014 07:07:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,346,1413270000"; d="scan'208";a="604933271"
Received: from gerry-dev.bj.intel.com ([10.238.158.52])
	by orsmga001.jf.intel.com with ESMTP; 09 Nov 2014 07:09:30 -0800
From: Jiang Liu <jiang.liu@linux.intel.com>
To: Bjorn Helgaas <bhelgaas@google.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Randy Dunlap <rdunlap@infradead.org>, Yinghai Lu <yinghai@kernel.org>,
	Borislav Petkov <bp@alien8.de>, Grant Likely <grant.likely@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Yingjoe Chen <yingjoe.chen@mediatek.com>,
	Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Alexander Gordeev <agordeev@redhat.com>, Anton Blanchard <anton@samba.org>,
	Jiang Liu <jiang.liu@linux.intel.com>, Yijing Wang <wangyijing@huawei.com>
Date: Sun,  9 Nov 2014 23:10:33 +0800
Message-Id: <1415545839-28263-12-git-send-email-jiang.liu@linux.intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415545839-28263-1-git-send-email-jiang.liu@linux.intel.com>
References: <1415545839-28263-1-git-send-email-jiang.liu@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Joerg Roedel <joro@8bytes.org>, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org, Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [RFC Part4 v1 11/17] PCI,
	MSI: Rename __read_msi_msg() as __pci_read_msi_msg()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rename __read_msi_msg() as __pci_read_msi_msg() and kill unused
read_msi_msg(). It's a preparation to separate generic MSI code
from PCI core.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 arch/powerpc/platforms/pseries/msi.c |    2 +-
 arch/x86/pci/xen.c                   |    2 +-
 drivers/pci/msi.c                    |    9 +--------
 include/linux/msi.h                  |    3 +--
 4 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c
index 8ab5add4ac82..90f756d0f58f 100644
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -476,7 +476,7 @@ again:
 		irq_set_msi_desc(virq, entry);
 
 		/* Read config space back so we can restore after reset */
-		__read_msi_msg(entry, &msg);
+		__pci_read_msi_msg(entry, &msg);
 		entry->msg = msg;
 	}
 
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 093f5f4272d3..a48ca2f8b93e 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -229,7 +229,7 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 		return 1;
 
 	list_for_each_entry(msidesc, &dev->msi_list, list) {
-		__read_msi_msg(msidesc, &msg);
+		__pci_read_msi_msg(msidesc, &msg);
 		pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
 			((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
 		if (msg.data != XEN_PIRQ_MSI_DATA ||
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index e1814f4be4b9..6011dfb475a1 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -243,7 +243,7 @@ void default_restore_msi_irqs(struct pci_dev *dev)
 		default_restore_msi_irq(dev, entry->irq);
 }
 
-void __read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
+void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
 	BUG_ON(entry->dev->current_state != PCI_D0);
 
@@ -273,13 +273,6 @@ void __read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 	}
 }
 
-void read_msi_msg(unsigned int irq, struct msi_msg *msg)
-{
-	struct msi_desc *entry = irq_get_msi_desc(irq);
-
-	__read_msi_msg(entry, msg);
-}
-
 void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
 	if (entry->dev->current_state != PCI_D0) {
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 19502186a64d..4b0d070ff481 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -61,9 +61,8 @@ void msi_domain_deactivate(struct irq_domain *domain,
 
 #ifdef CONFIG_PCI_MSI
 /* Helper functions */
-void __read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
+void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
 void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
-void read_msi_msg(unsigned int irq, struct msi_msg *msg);
 void write_msi_msg(unsigned int irq, struct msi_msg *msg);
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 17:50:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 17:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnWd4-0006ya-SY; Sun, 09 Nov 2014 17:50: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@citrix.com>) id 1XnWd3-0006yV-Cu
	for xen-devel@lists.xensource.com; Sun, 09 Nov 2014 17:50:21 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	21/FF-28865-C59AF545; Sun, 09 Nov 2014 17:50:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415555418!11370487!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9537 invoked from network); 9 Nov 2014 17:50:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 17:50:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,346,1413244800"; d="scan'208";a="189562425"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 9 Nov 2014 12:49:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnWce-0000Gh-K7;
	Sun, 09 Nov 2014 17:49:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnWce-0004hE-F3;
	Sun, 09 Nov 2014 17:49:56 +0000
Date: Sun, 9 Nov 2014 17:49:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31448-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31448: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31448 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31448/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install              fail pass in 31441
 test-amd64-amd64-xl-sedf-pin  8 debian-fixup       fail in 31441 pass in 31435

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Sun Nov 09 17:50:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 17:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnWd4-0006ya-SY; Sun, 09 Nov 2014 17:50: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@citrix.com>) id 1XnWd3-0006yV-Cu
	for xen-devel@lists.xensource.com; Sun, 09 Nov 2014 17:50:21 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	21/FF-28865-C59AF545; Sun, 09 Nov 2014 17:50:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415555418!11370487!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9537 invoked from network); 9 Nov 2014 17:50:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 17:50:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,346,1413244800"; d="scan'208";a="189562425"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 9 Nov 2014 12:49:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnWce-0000Gh-K7;
	Sun, 09 Nov 2014 17:49:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnWce-0004hE-F3;
	Sun, 09 Nov 2014 17:49:56 +0000
Date: Sun, 9 Nov 2014 17:49:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31448-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31448: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31448 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31448/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install              fail pass in 31441
 test-amd64-amd64-xl-sedf-pin  8 debian-fixup       fail in 31441 pass in 31435

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Sun Nov 09 19:23:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 19:23:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnY4p-0007z0-FA; Sun, 09 Nov 2014 19:23:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amaro@gatech.edu>) id 1XnXyO-0007w4-55
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 19:16:28 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F9/7B-03145-B8DBF545; Sun, 09 Nov 2014 19:16:27 +0000
X-Env-Sender: amaro@gatech.edu
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415560585!12347827!1
X-Originating-IP: [157.56.110.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6056 invoked from network); 9 Nov 2014 19:16:26 -0000
Received: from mail-bn1on0115.outbound.protection.outlook.com (HELO
	na01-bn1-obe.outbound.protection.outlook.com) (157.56.110.115)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Nov 2014 19:16:26 -0000
Received: from CY1PR0701MB1097.namprd07.prod.outlook.com (25.160.145.16) by
	CY1PR0701MB1099.namprd07.prod.outlook.com (25.160.145.18) with
	Microsoft SMTP
	Server (TLS) id 15.1.16.15; Sun, 9 Nov 2014 19:16:23 +0000
Received: from CY1PR0701MB1097.namprd07.prod.outlook.com ([25.160.145.16]) by
	CY1PR0701MB1097.namprd07.prod.outlook.com ([25.160.145.16]) with
	mapi id 15.01.0016.006; Sun, 9 Nov 2014 19:16:23 +0000
From: "Amaro, Emmanuel" <amaro@gatech.edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Passing pointers to hypercalls
Thread-Index: AQHP/FGmdYH9wvi+VUqxQYzkRUaDKg==
Date: Sun, 9 Nov 2014 19:16:22 +0000
Message-ID: <0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.61.61.158]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1099;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1099;
x-forefront-prvs: 0390DB4BDA
x-forefront-antispam-report: SFV:NSPM;
	SFS:(10019020)(6009001)(199003)(189002)(40100003)(97736003)(88552001)(90282001)(110136001)(89122001)(83716003)(16236675004)(2656002)(33656002)(75432002)(54356999)(46102003)(87936001)(122556002)(50986999)(86362001)(92726001)(92566001)(120916001)(82746002)(31966008)(66066001)(21056001)(106356001)(101416001)(99396003)(106116001)(229853001)(107886001)(2351001)(107046002)(450100001)(20776003)(77096003)(77156002)(36756003)(4396001)(95666004)(99286002)(62966003)(64706001)(105586002)(104396001);
	DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1099;
	H:CY1PR0701MB1097.namprd07.prod.outlook.com; FPR:; MLV:sfv;
	PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
MIME-Version: 1.0
X-OriginatorOrg: gatech.edu
X-Mailman-Approved-At: Sun, 09 Nov 2014 19:23:06 +0000
Subject: [Xen-devel] Passing pointers to 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: multipart/mixed; boundary="===============8831963402641839385=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8831963402641839385==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_0D65FE405E544369BE0679EFAF9E3607gatechedu_"

--_000_0D65FE405E544369BE0679EFAF9E3607gatechedu_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGVsbG8sDQoNCkkgYW0gdHJ5aW5nIHRvIHBhc3MgYSBwb2ludGVyIHRvIGFuIGh5cGVyIGNhbGwg
aW4gdGhlIHNpbXBsZXN0IHBvc3NpYmxlIHdheSwgc2V0IGl04oCZcyB2YWx1ZSwgYW4gcmV0dXJu
IGl0IHRvIHRoZSBndWVzdC4NCg0KSSBoYXZlIHRyaWVkIDIgZGlmZmVyZW50IHdheXM6DQotIERp
cmVjdGx5IHdpdGggc2ltcGxlIHBvaW50ZXJzIChJIHJlYWQgc29tZXdoZXJlIHRoaXMgd291bGQg
d29yayBvbiB4ODYpLCBidXQgdGhlIHBvaW50ZXIgYWRkcmVzcyBpcyBzZXQgdG8gMHgwMDAwZGVh
ZGJlZWYsIHNvIGRlcmVmZXJlbmNpbmcgaXQgY2F1c2VzIGEgcGFuaWMuDQotIFdpdGggWEVOX0dV
RVNUX0hBTkRMRToNCmxvbmcgZG9fZHVtbXkoWEVOX0dVRVNUX0hBTkRMRSh1aW50NjRfdCkgcHRy
KQ0Kew0KICAgIHVpbnQ2NF90IHRtcCA9IDE7DQoNCiAgICBpZiAoY29weV90b19ndWVzdChwdHIs
ICZ0bXAsIDEpICE9IDApDQogICAgICAgIHJldHVybiAyOw0KDQogICAgcmV0dXJuIDA7DQp9DQoN
CkJ1dCBpbiB0aGlzIGNhc2UgY29weV90b19ndWVzdCgpIGRvZXMgbm90IHJldHVybiAwLCBzbyB0
aGlzIGZhaWxzIGFzIHdlbGwuIEkgY2FsbCB0aGUgaHlwZXIgY2FsbCBmcm9tIHRoaXMgTGludXgg
c3lzdGVtIGNhbGw6DQoNCmFzbWxpbmthZ2UgbG9uZyBzeXNfZHVtbXkodm9pZCkNCnsNCiAgICB1
aW50NjRfdCBwID0gMDsNCiAgICBpbnQgcmMgPSAwOw0KICAgIHJjID0gSFlQRVJWSVNPUl9kdW1t
eSgmcCk7DQoNCiAgICBpZiAocmMgIT0gMCkNCiAgICAgICAgcHJpbnRrKCJFUlJPUiwgaHlwZXJj
YWxsIHJldHVybmVkOiAlZFxuIiwgcmMpOw0KDQogICAgcmV0dXJuIDA7DQp9DQoNCkkgYW0gc3Vy
ZSBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIHN1cGVyIGVhc3ksIGJ1dCBJIGNhbuKAmXQgc2VlIHdo
YXQuDQoNClRoYW5rIHlvdSBmb3IgeW91ciBoZWxwLA0KRW1tYW51ZWwNCg==

--_000_0D65FE405E544369BE0679EFAF9E3607gatechedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <96E781EB5CF1B443AC36493AAF3DF727@namprd07.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8sDQo8ZGl2IGNsYXNzPSIi
PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFtIHRyeWluZyB0byBwYXNz
IGEgcG9pbnRlciB0byBhbiBoeXBlciBjYWxsIGluIHRoZSBzaW1wbGVzdCBwb3NzaWJsZSB3YXks
IHNldCBpdOKAmXMgdmFsdWUsIGFuIHJldHVybiBpdCB0byB0aGUgZ3Vlc3QuPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGhhdmUgdHJp
ZWQgMiBkaWZmZXJlbnQgd2F5czo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFw
cGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+LSBEaXJlY3RseSB3
aXRoIHNpbXBsZSBwb2ludGVycyAoSSByZWFkIHNvbWV3aGVyZSB0aGlzIHdvdWxkIHdvcmsgb24g
eDg2KSwgYnV0IHRoZSBwb2ludGVyIGFkZHJlc3MgaXMgc2V0IHRvIDB4MDAwMGRlYWRiZWVmLCBz
byBkZXJlZmVyZW5jaW5nIGl0IGNhdXNlcyBhIHBhbmljLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48
c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bh
bj4tIFdpdGggWEVOX0dVRVNUX0hBTkRMRTo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRp
bmc6IDBweDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+bG9uZyBk
b19kdW1teShYRU5fR1VFU1RfSEFORExFKHVpbnQ2NF90KSBwdHIpPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRl
cjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj
bGFzcz0iIj57PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9
IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHVpbnQ2NF90
IHRtcCA9IDE7PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9
IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAg
NDBweDsgYm9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9
IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgaWYgKGNvcHlfdG9fZ3Vlc3QocHRyLCAm
YW1wO3RtcCwgMSkgIT0gMCk8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7
IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyByZXR1cm4gMjs8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBub25lOyBwYWRkaW5n
OiAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRpbmc6IDBweDsiIGNsYXNzPSIi
Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyByZXR1cm4gMDs8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjog
MCAwIDAgNDBweDsgYm9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj59PC9ibG9j
a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBu
b25lOyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+
DQpCdXQgaW4gdGhpcyBjYXNlIGNvcHlfdG9fZ3Vlc3QoKSBkb2VzIG5vdCByZXR1cm4gMCwgc28g
dGhpcyBmYWlscyBhcyB3ZWxsLiBJIGNhbGwgdGhlIGh5cGVyIGNhbGwgZnJvbSB0aGlzIExpbnV4
IHN5c3RlbSBjYWxsOjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAg
MCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+PGJyIGNsYXNz
PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBw
eDsgYm9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xh
c3M9IiI+YXNtbGlua2FnZSBsb25nIHN5c19kdW1teSh2b2lkKTwvYmxvY2txdW90ZT4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzog
MHB4OyIgY2xhc3M9IiI+ezwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46
IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+Jm5ic3A7
ICZuYnNwOyB1aW50NjRfdCBwID0gMDs8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRpbmc6IDBweDsiIGNsYXNzPSIi
PiZuYnNwOyAmbmJzcDsgaW50IHJjID0gMDs8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRpbmc6IDBweDsiIGNsYXNz
PSIiPiZuYnNwOyAmbmJzcDsgcmMgPSBIWVBFUlZJU09SX2R1bW15KCZhbXA7cCk7PC9ibG9ja3F1
b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBub25l
OyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRp
bmc6IDBweDsiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgaWYgKHJjICE9IDApPC9ibG9ja3F1b3Rl
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBub25lOyBw
YWRkaW5nOiAwcHg7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJpbnRr
KCZxdW90O0VSUk9SLCBoeXBlcmNhbGwgcmV0dXJuZWQ6ICVkXG4mcXVvdDssIHJjKTs8L2Jsb2Nr
cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5v
bmU7IHBhZGRpbmc6IDBweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFk
ZGluZzogMHB4OyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyByZXR1cm4gMDs8L2Jsb2NrcXVvdGU+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBh
ZGRpbmc6IDBweDsiIGNsYXNzPSIiPn08L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRpbmc6
IDBweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCkkgYW0gc3VyZSBJ
IGFtIG1pc3Npbmcgc29tZXRoaW5nIHN1cGVyIGVhc3ksIGJ1dCBJIGNhbuKAmXQgc2VlIHdoYXQu
DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFu
ayB5b3UgZm9yIHlvdXIgaGVscCw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RW1tYW51ZWw8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_0D65FE405E544369BE0679EFAF9E3607gatechedu_--


--===============8831963402641839385==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8831963402641839385==--


From xen-devel-bounces@lists.xen.org Sun Nov 09 19:23:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 19:23:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnY4p-0007z0-FA; Sun, 09 Nov 2014 19:23:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amaro@gatech.edu>) id 1XnXyO-0007w4-55
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 19:16:28 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F9/7B-03145-B8DBF545; Sun, 09 Nov 2014 19:16:27 +0000
X-Env-Sender: amaro@gatech.edu
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415560585!12347827!1
X-Originating-IP: [157.56.110.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6056 invoked from network); 9 Nov 2014 19:16:26 -0000
Received: from mail-bn1on0115.outbound.protection.outlook.com (HELO
	na01-bn1-obe.outbound.protection.outlook.com) (157.56.110.115)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Nov 2014 19:16:26 -0000
Received: from CY1PR0701MB1097.namprd07.prod.outlook.com (25.160.145.16) by
	CY1PR0701MB1099.namprd07.prod.outlook.com (25.160.145.18) with
	Microsoft SMTP
	Server (TLS) id 15.1.16.15; Sun, 9 Nov 2014 19:16:23 +0000
Received: from CY1PR0701MB1097.namprd07.prod.outlook.com ([25.160.145.16]) by
	CY1PR0701MB1097.namprd07.prod.outlook.com ([25.160.145.16]) with
	mapi id 15.01.0016.006; Sun, 9 Nov 2014 19:16:23 +0000
From: "Amaro, Emmanuel" <amaro@gatech.edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Passing pointers to hypercalls
Thread-Index: AQHP/FGmdYH9wvi+VUqxQYzkRUaDKg==
Date: Sun, 9 Nov 2014 19:16:22 +0000
Message-ID: <0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.61.61.158]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1099;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1099;
x-forefront-prvs: 0390DB4BDA
x-forefront-antispam-report: SFV:NSPM;
	SFS:(10019020)(6009001)(199003)(189002)(40100003)(97736003)(88552001)(90282001)(110136001)(89122001)(83716003)(16236675004)(2656002)(33656002)(75432002)(54356999)(46102003)(87936001)(122556002)(50986999)(86362001)(92726001)(92566001)(120916001)(82746002)(31966008)(66066001)(21056001)(106356001)(101416001)(99396003)(106116001)(229853001)(107886001)(2351001)(107046002)(450100001)(20776003)(77096003)(77156002)(36756003)(4396001)(95666004)(99286002)(62966003)(64706001)(105586002)(104396001);
	DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1099;
	H:CY1PR0701MB1097.namprd07.prod.outlook.com; FPR:; MLV:sfv;
	PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
MIME-Version: 1.0
X-OriginatorOrg: gatech.edu
X-Mailman-Approved-At: Sun, 09 Nov 2014 19:23:06 +0000
Subject: [Xen-devel] Passing pointers to 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: multipart/mixed; boundary="===============8831963402641839385=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8831963402641839385==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_0D65FE405E544369BE0679EFAF9E3607gatechedu_"

--_000_0D65FE405E544369BE0679EFAF9E3607gatechedu_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGVsbG8sDQoNCkkgYW0gdHJ5aW5nIHRvIHBhc3MgYSBwb2ludGVyIHRvIGFuIGh5cGVyIGNhbGwg
aW4gdGhlIHNpbXBsZXN0IHBvc3NpYmxlIHdheSwgc2V0IGl04oCZcyB2YWx1ZSwgYW4gcmV0dXJu
IGl0IHRvIHRoZSBndWVzdC4NCg0KSSBoYXZlIHRyaWVkIDIgZGlmZmVyZW50IHdheXM6DQotIERp
cmVjdGx5IHdpdGggc2ltcGxlIHBvaW50ZXJzIChJIHJlYWQgc29tZXdoZXJlIHRoaXMgd291bGQg
d29yayBvbiB4ODYpLCBidXQgdGhlIHBvaW50ZXIgYWRkcmVzcyBpcyBzZXQgdG8gMHgwMDAwZGVh
ZGJlZWYsIHNvIGRlcmVmZXJlbmNpbmcgaXQgY2F1c2VzIGEgcGFuaWMuDQotIFdpdGggWEVOX0dV
RVNUX0hBTkRMRToNCmxvbmcgZG9fZHVtbXkoWEVOX0dVRVNUX0hBTkRMRSh1aW50NjRfdCkgcHRy
KQ0Kew0KICAgIHVpbnQ2NF90IHRtcCA9IDE7DQoNCiAgICBpZiAoY29weV90b19ndWVzdChwdHIs
ICZ0bXAsIDEpICE9IDApDQogICAgICAgIHJldHVybiAyOw0KDQogICAgcmV0dXJuIDA7DQp9DQoN
CkJ1dCBpbiB0aGlzIGNhc2UgY29weV90b19ndWVzdCgpIGRvZXMgbm90IHJldHVybiAwLCBzbyB0
aGlzIGZhaWxzIGFzIHdlbGwuIEkgY2FsbCB0aGUgaHlwZXIgY2FsbCBmcm9tIHRoaXMgTGludXgg
c3lzdGVtIGNhbGw6DQoNCmFzbWxpbmthZ2UgbG9uZyBzeXNfZHVtbXkodm9pZCkNCnsNCiAgICB1
aW50NjRfdCBwID0gMDsNCiAgICBpbnQgcmMgPSAwOw0KICAgIHJjID0gSFlQRVJWSVNPUl9kdW1t
eSgmcCk7DQoNCiAgICBpZiAocmMgIT0gMCkNCiAgICAgICAgcHJpbnRrKCJFUlJPUiwgaHlwZXJj
YWxsIHJldHVybmVkOiAlZFxuIiwgcmMpOw0KDQogICAgcmV0dXJuIDA7DQp9DQoNCkkgYW0gc3Vy
ZSBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIHN1cGVyIGVhc3ksIGJ1dCBJIGNhbuKAmXQgc2VlIHdo
YXQuDQoNClRoYW5rIHlvdSBmb3IgeW91ciBoZWxwLA0KRW1tYW51ZWwNCg==

--_000_0D65FE405E544369BE0679EFAF9E3607gatechedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <96E781EB5CF1B443AC36493AAF3DF727@namprd07.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8sDQo8ZGl2IGNsYXNzPSIi
PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFtIHRyeWluZyB0byBwYXNz
IGEgcG9pbnRlciB0byBhbiBoeXBlciBjYWxsIGluIHRoZSBzaW1wbGVzdCBwb3NzaWJsZSB3YXks
IHNldCBpdOKAmXMgdmFsdWUsIGFuIHJldHVybiBpdCB0byB0aGUgZ3Vlc3QuPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGhhdmUgdHJp
ZWQgMiBkaWZmZXJlbnQgd2F5czo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFw
cGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+LSBEaXJlY3RseSB3
aXRoIHNpbXBsZSBwb2ludGVycyAoSSByZWFkIHNvbWV3aGVyZSB0aGlzIHdvdWxkIHdvcmsgb24g
eDg2KSwgYnV0IHRoZSBwb2ludGVyIGFkZHJlc3MgaXMgc2V0IHRvIDB4MDAwMGRlYWRiZWVmLCBz
byBkZXJlZmVyZW5jaW5nIGl0IGNhdXNlcyBhIHBhbmljLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48
c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bh
bj4tIFdpdGggWEVOX0dVRVNUX0hBTkRMRTo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRp
bmc6IDBweDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+bG9uZyBk
b19kdW1teShYRU5fR1VFU1RfSEFORExFKHVpbnQ2NF90KSBwdHIpPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRl
cjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj
bGFzcz0iIj57PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9
IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHVpbnQ2NF90
IHRtcCA9IDE7PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9
IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAg
NDBweDsgYm9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9
IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgaWYgKGNvcHlfdG9fZ3Vlc3QocHRyLCAm
YW1wO3RtcCwgMSkgIT0gMCk8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7
IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyByZXR1cm4gMjs8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBub25lOyBwYWRkaW5n
OiAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRpbmc6IDBweDsiIGNsYXNzPSIi
Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyByZXR1cm4gMDs8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjog
MCAwIDAgNDBweDsgYm9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj59PC9ibG9j
a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBu
b25lOyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+
DQpCdXQgaW4gdGhpcyBjYXNlIGNvcHlfdG9fZ3Vlc3QoKSBkb2VzIG5vdCByZXR1cm4gMCwgc28g
dGhpcyBmYWlscyBhcyB3ZWxsLiBJIGNhbGwgdGhlIGh5cGVyIGNhbGwgZnJvbSB0aGlzIExpbnV4
IHN5c3RlbSBjYWxsOjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAg
MCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+PGJyIGNsYXNz
PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBw
eDsgYm9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xh
c3M9IiI+YXNtbGlua2FnZSBsb25nIHN5c19kdW1teSh2b2lkKTwvYmxvY2txdW90ZT4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzog
MHB4OyIgY2xhc3M9IiI+ezwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46
IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+Jm5ic3A7
ICZuYnNwOyB1aW50NjRfdCBwID0gMDs8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRpbmc6IDBweDsiIGNsYXNzPSIi
PiZuYnNwOyAmbmJzcDsgaW50IHJjID0gMDs8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRpbmc6IDBweDsiIGNsYXNz
PSIiPiZuYnNwOyAmbmJzcDsgcmMgPSBIWVBFUlZJU09SX2R1bW15KCZhbXA7cCk7PC9ibG9ja3F1
b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBub25l
OyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRp
bmc6IDBweDsiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgaWYgKHJjICE9IDApPC9ibG9ja3F1b3Rl
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBub25lOyBw
YWRkaW5nOiAwcHg7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJpbnRr
KCZxdW90O0VSUk9SLCBoeXBlcmNhbGwgcmV0dXJuZWQ6ICVkXG4mcXVvdDssIHJjKTs8L2Jsb2Nr
cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5v
bmU7IHBhZGRpbmc6IDBweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFk
ZGluZzogMHB4OyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyByZXR1cm4gMDs8L2Jsb2NrcXVvdGU+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBh
ZGRpbmc6IDBweDsiIGNsYXNzPSIiPn08L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRpbmc6
IDBweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCkkgYW0gc3VyZSBJ
IGFtIG1pc3Npbmcgc29tZXRoaW5nIHN1cGVyIGVhc3ksIGJ1dCBJIGNhbuKAmXQgc2VlIHdoYXQu
DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFu
ayB5b3UgZm9yIHlvdXIgaGVscCw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RW1tYW51ZWw8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_0D65FE405E544369BE0679EFAF9E3607gatechedu_--


--===============8831963402641839385==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8831963402641839385==--


From xen-devel-bounces@lists.xen.org Sun Nov 09 19:27:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 19:27:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnY8z-00088D-Dz; Sun, 09 Nov 2014 19:27:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XnY8x-000885-KK
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 19:27:23 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F2/D7-01660-A10CF545; Sun, 09 Nov 2014 19:27:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415561240!5976274!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2091 invoked from network); 9 Nov 2014 19:27:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 19:27:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,347,1413244800"; 
	d="scan'208,217";a="191016760"
Message-ID: <545FC016.7060509@citrix.com>
Date: Sun, 9 Nov 2014 19:27:18 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: "Amaro, Emmanuel" <amaro@gatech.edu>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu>
In-Reply-To: <0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu>
X-DLP: MIA2
Subject: Re: [Xen-devel] Passing pointers to 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: multipart/mixed; boundary="===============1126458322294664615=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1126458322294664615==
Content-Type: multipart/alternative;
	boundary="------------030803050909020807040606"

--------------030803050909020807040606
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 09/11/14 19:16, Amaro, Emmanuel wrote:
> Hello,
>
> I am trying to pass a pointer to an hyper call in the simplest
> possible way, set it's value, an return it to the guest.
>
> I have tried 2 different ways:
> - Directly with simple pointers (I read somewhere this would work on
> x86), but the pointer address is set to 0x0000deadbeef, so
> dereferencing it causes a panic.
> - With XEN_GUEST_HANDLE:
>
>         long do_dummy(XEN_GUEST_HANDLE(uint64_t) ptr)
>
>         {
>

It looks like you have introduced a new hypercall called dummy.

I presume from this code that you have filled in a new handler in the
hypercall_table, but have you set the expected number of args in the
hypercall_args_table?

The default number of args is 0, which cases a debug Xen to deliberately
clobber all the registers to 0xdeadbeef

~Andrew

--------------030803050909020807040606
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 09/11/14 19:16, Amaro, Emmanuel
      wrote:<br>
    </div>
    <blockquote
      cite="mid:0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      Hello,
      <div class=""><br class="">
      </div>
      <div class="">I am trying to pass a pointer to an hyper call in
        the simplest possible way, set it&#8217;s value, an return it to the
        guest.</div>
      <div class=""><br class="">
      </div>
      <div class="">I have tried 2 different ways:</div>
      <div class=""><span class="Apple-tab-span" style="white-space:pre"></span>-
        Directly with simple pointers (I read somewhere this would work
        on x86), but the pointer address is set to 0x0000deadbeef, so
        dereferencing it causes a panic.</div>
      <div class=""><span class="Apple-tab-span" style="white-space:pre"></span>-
        With XEN_GUEST_HANDLE:</div>
      <blockquote style="margin: 0 0 0 40px; border: none; padding:
        0px;" class="">
        <blockquote style="margin: 0 0 0 40px; border: none; padding:
          0px;" class="">
          <div class="">
            <div class="">long do_dummy(XEN_GUEST_HANDLE(uint64_t) ptr)</div>
          </div>
        </blockquote>
        <blockquote style="margin: 0 0 0 40px; border: none; padding:
          0px;" class="">
          <div class="">
            <div class="">{</div>
          </div>
        </blockquote>
      </blockquote>
    </blockquote>
    <br>
    It looks like you have introduced a new hypercall called dummy.<br>
    <br>
    I presume from this code that you have filled in a new handler in
    the hypercall_table, but have you set the expected number of args in
    the hypercall_args_table?<br>
    <br>
    The default number of args is 0, which cases a debug Xen to
    deliberately clobber all the registers to 0xdeadbeef<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------030803050909020807040606--


--===============1126458322294664615==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1126458322294664615==--


From xen-devel-bounces@lists.xen.org Sun Nov 09 19:27:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 19:27:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnY8z-00088D-Dz; Sun, 09 Nov 2014 19:27:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XnY8x-000885-KK
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 19:27:23 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F2/D7-01660-A10CF545; Sun, 09 Nov 2014 19:27:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415561240!5976274!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2091 invoked from network); 9 Nov 2014 19:27:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Nov 2014 19:27:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,347,1413244800"; 
	d="scan'208,217";a="191016760"
Message-ID: <545FC016.7060509@citrix.com>
Date: Sun, 9 Nov 2014 19:27:18 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: "Amaro, Emmanuel" <amaro@gatech.edu>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu>
In-Reply-To: <0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu>
X-DLP: MIA2
Subject: Re: [Xen-devel] Passing pointers to 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: multipart/mixed; boundary="===============1126458322294664615=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1126458322294664615==
Content-Type: multipart/alternative;
	boundary="------------030803050909020807040606"

--------------030803050909020807040606
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 09/11/14 19:16, Amaro, Emmanuel wrote:
> Hello,
>
> I am trying to pass a pointer to an hyper call in the simplest
> possible way, set it's value, an return it to the guest.
>
> I have tried 2 different ways:
> - Directly with simple pointers (I read somewhere this would work on
> x86), but the pointer address is set to 0x0000deadbeef, so
> dereferencing it causes a panic.
> - With XEN_GUEST_HANDLE:
>
>         long do_dummy(XEN_GUEST_HANDLE(uint64_t) ptr)
>
>         {
>

It looks like you have introduced a new hypercall called dummy.

I presume from this code that you have filled in a new handler in the
hypercall_table, but have you set the expected number of args in the
hypercall_args_table?

The default number of args is 0, which cases a debug Xen to deliberately
clobber all the registers to 0xdeadbeef

~Andrew

--------------030803050909020807040606
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 09/11/14 19:16, Amaro, Emmanuel
      wrote:<br>
    </div>
    <blockquote
      cite="mid:0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      Hello,
      <div class=""><br class="">
      </div>
      <div class="">I am trying to pass a pointer to an hyper call in
        the simplest possible way, set it&#8217;s value, an return it to the
        guest.</div>
      <div class=""><br class="">
      </div>
      <div class="">I have tried 2 different ways:</div>
      <div class=""><span class="Apple-tab-span" style="white-space:pre"></span>-
        Directly with simple pointers (I read somewhere this would work
        on x86), but the pointer address is set to 0x0000deadbeef, so
        dereferencing it causes a panic.</div>
      <div class=""><span class="Apple-tab-span" style="white-space:pre"></span>-
        With XEN_GUEST_HANDLE:</div>
      <blockquote style="margin: 0 0 0 40px; border: none; padding:
        0px;" class="">
        <blockquote style="margin: 0 0 0 40px; border: none; padding:
          0px;" class="">
          <div class="">
            <div class="">long do_dummy(XEN_GUEST_HANDLE(uint64_t) ptr)</div>
          </div>
        </blockquote>
        <blockquote style="margin: 0 0 0 40px; border: none; padding:
          0px;" class="">
          <div class="">
            <div class="">{</div>
          </div>
        </blockquote>
      </blockquote>
    </blockquote>
    <br>
    It looks like you have introduced a new hypercall called dummy.<br>
    <br>
    I presume from this code that you have filled in a new handler in
    the hypercall_table, but have you set the expected number of args in
    the hypercall_args_table?<br>
    <br>
    The default number of args is 0, which cases a debug Xen to
    deliberately clobber all the registers to 0xdeadbeef<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------030803050909020807040606--


--===============1126458322294664615==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1126458322294664615==--


From xen-devel-bounces@lists.xen.org Sun Nov 09 19:50:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 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.xen.org>)
	id 1XnYVH-0008O8-RL; Sun, 09 Nov 2014 19:50:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amaro@gatech.edu>) id 1XnYVG-0008O3-AV
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 19:50:26 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	B6/A0-25547-185CF545; Sun, 09 Nov 2014 19:50:25 +0000
X-Env-Sender: amaro@gatech.edu
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415562623!11404556!1
X-Originating-IP: [157.56.110.135]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27928 invoked from network); 9 Nov 2014 19:50:24 -0000
Received: from mail-bn1on0135.outbound.protection.outlook.com (HELO
	na01-bn1-obe.outbound.protection.outlook.com) (157.56.110.135)
	by server-7.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Nov 2014 19:50:24 -0000
Received: from CY1PR0701MB1097.namprd07.prod.outlook.com (25.160.145.16) by
	CY1PR0701MB1097.namprd07.prod.outlook.com (25.160.145.16) with
	Microsoft SMTP
	Server (TLS) id 15.1.16.15; Sun, 9 Nov 2014 19:50:22 +0000
Received: from CY1PR0701MB1097.namprd07.prod.outlook.com ([25.160.145.16]) by
	CY1PR0701MB1097.namprd07.prod.outlook.com ([25.160.145.16]) with
	mapi id 15.01.0016.006; Sun, 9 Nov 2014 19:50:22 +0000
From: "Amaro, Emmanuel" <amaro@gatech.edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Passing pointers to hypercalls
Thread-Index: AQHP/FGmdYH9wvi+VUqxQYzkRUaDKpxYrbYAgAAGbwA=
Date: Sun, 9 Nov 2014 19:50:21 +0000
Message-ID: <1FDFECBD-0E6B-4924-BFD5-B9EE6A680C3B@gatech.edu>
References: <0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu>
	<545FC016.7060509@citrix.com>
In-Reply-To: <545FC016.7060509@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.61.61.158]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1097;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1097;
x-forefront-prvs: 0390DB4BDA
x-forefront-antispam-report: SFV:NSPM;
	SFS:(10019020)(199003)(479174003)(377454003)(24454002)(41574002)(189002)(120916001)(99396003)(82746002)(66066001)(101416001)(64706001)(20776003)(89122001)(110136001)(50986999)(54356999)(76176999)(33656002)(31966008)(36756003)(105586002)(87936001)(2656002)(92726001)(92566001)(4396001)(83716003)(21056001)(19580405001)(19580395003)(122556002)(40100003)(107886001)(95666004)(107046002)(2351001)(106356001)(99286002)(106116001)(62966003)(88552001)(77156002)(77096003)(86362001)(97736003)(90282001)(75432002)(16236675004)(450100001)(46102003)(104396001);
	DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1097;
	H:CY1PR0701MB1097.namprd07.prod.outlook.com; FPR:; MLV:sfv;
	PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
MIME-Version: 1.0
X-OriginatorOrg: gatech.edu
Subject: Re: [Xen-devel] Passing pointers to 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: multipart/mixed; boundary="===============0993886851507768952=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0993886851507768952==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_1FDFECBD0E6B4924BFD5B9EE6A680C3Bgatechedu_"

--_000_1FDFECBD0E6B4924BFD5B9EE6A680C3Bgatechedu_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Of course. Agh, I forgot to change it to 1.

If someone else looks at this, in my case it means this file: xen/arch/x86/=
x86_64/entry.S

Thanks!


On Nov 9, 2014, at 2:27 PM, Andrew Cooper <andrew.cooper3@citrix.com<mailto=
:andrew.cooper3@citrix.com>> wrote:

On 09/11/14 19:16, Amaro, Emmanuel wrote:
Hello,

I am trying to pass a pointer to an hyper call in the simplest possible way=
, set it=92s value, an return it to the guest.

I have tried 2 different ways:
- Directly with simple pointers (I read somewhere this would work on x86), =
but the pointer address is set to 0x0000deadbeef, so dereferencing it cause=
s a panic.
- With XEN_GUEST_HANDLE:
long do_dummy(XEN_GUEST_HANDLE(uint64_t) ptr)
{

It looks like you have introduced a new hypercall called dummy.

I presume from this code that you have filled in a new handler in the hyper=
call_table, but have you set the expected number of args in the hypercall_a=
rgs_table?

The default number of args is 0, which cases a debug Xen to deliberately cl=
obber all the registers to 0xdeadbeef

~Andrew


--_000_1FDFECBD0E6B4924BFD5B9EE6A680C3Bgatechedu_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <6B8132375839C4469F1BA0B8D0F9D6AE@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space;" class=3D"">
<div class=3D"">
<div class=3D"">Of course. Agh, I forgot to change it to 1.</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">If someone else looks at this, in my case it means this fil=
e: xen/arch/x86/x86_64/entry.S</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">Thanks!</div>
</div>
<div class=3D""><br class=3D"">
</div>
<br class=3D"">
<div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">On Nov 9, 2014, at 2:27 PM, Andrew Cooper &lt;<a href=3D"ma=
ilto:andrew.cooper3@citrix.com" class=3D"">andrew.cooper3@citrix.com</a>&gt=
; wrote:</div>
<br class=3D"Apple-interchange-newline">
<div class=3D"">
<div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D"">
<div class=3D"moz-cite-prefix">On 09/11/14 19:16, Amaro, Emmanuel wrote:<br=
 class=3D"">
</div>
<blockquote cite=3D"mid:0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu" ty=
pe=3D"cite" class=3D"">
Hello,
<div class=3D""><br class=3D"">
</div>
<div class=3D"">I am trying to pass a pointer to an hyper call in the simpl=
est possible way, set it=92s value, an return it to the guest.</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">I have tried 2 different ways:</div>
<div class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre"></=
span>- Directly with simple pointers (I read somewhere this would work on x=
86), but the pointer address is set to 0x0000deadbeef, so dereferencing it =
causes a panic.</div>
<div class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre"></=
span>- With XEN_GUEST_HANDLE:</div>
<blockquote style=3D"margin: 0 0 0 40px; border: none; padding:
        0px;" class=3D"">
<blockquote style=3D"margin: 0 0 0 40px; border: none; padding:
          0px;" class=3D"">
<div class=3D"">
<div class=3D"">long do_dummy(XEN_GUEST_HANDLE(uint64_t) ptr)</div>
</div>
</blockquote>
<blockquote style=3D"margin: 0 0 0 40px; border: none; padding:
          0px;" class=3D"">
<div class=3D"">
<div class=3D"">{</div>
</div>
</blockquote>
</blockquote>
</blockquote>
<br class=3D"">
It looks like you have introduced a new hypercall called dummy.<br class=3D=
"">
<br class=3D"">
I presume from this code that you have filled in a new handler in the hyper=
call_table, but have you set the expected number of args in the hypercall_a=
rgs_table?<br class=3D"">
<br class=3D"">
The default number of args is 0, which cases a debug Xen to deliberately cl=
obber all the registers to 0xdeadbeef<br class=3D"">
<br class=3D"">
~Andrew<br class=3D"">
</div>
</div>
</blockquote>
</div>
<br class=3D"">
</body>
</html>

--_000_1FDFECBD0E6B4924BFD5B9EE6A680C3Bgatechedu_--


--===============0993886851507768952==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0993886851507768952==--


From xen-devel-bounces@lists.xen.org Sun Nov 09 19:50:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 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.xen.org>)
	id 1XnYVH-0008O8-RL; Sun, 09 Nov 2014 19:50:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amaro@gatech.edu>) id 1XnYVG-0008O3-AV
	for xen-devel@lists.xen.org; Sun, 09 Nov 2014 19:50:26 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	B6/A0-25547-185CF545; Sun, 09 Nov 2014 19:50:25 +0000
X-Env-Sender: amaro@gatech.edu
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415562623!11404556!1
X-Originating-IP: [157.56.110.135]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27928 invoked from network); 9 Nov 2014 19:50:24 -0000
Received: from mail-bn1on0135.outbound.protection.outlook.com (HELO
	na01-bn1-obe.outbound.protection.outlook.com) (157.56.110.135)
	by server-7.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Nov 2014 19:50:24 -0000
Received: from CY1PR0701MB1097.namprd07.prod.outlook.com (25.160.145.16) by
	CY1PR0701MB1097.namprd07.prod.outlook.com (25.160.145.16) with
	Microsoft SMTP
	Server (TLS) id 15.1.16.15; Sun, 9 Nov 2014 19:50:22 +0000
Received: from CY1PR0701MB1097.namprd07.prod.outlook.com ([25.160.145.16]) by
	CY1PR0701MB1097.namprd07.prod.outlook.com ([25.160.145.16]) with
	mapi id 15.01.0016.006; Sun, 9 Nov 2014 19:50:22 +0000
From: "Amaro, Emmanuel" <amaro@gatech.edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Passing pointers to hypercalls
Thread-Index: AQHP/FGmdYH9wvi+VUqxQYzkRUaDKpxYrbYAgAAGbwA=
Date: Sun, 9 Nov 2014 19:50:21 +0000
Message-ID: <1FDFECBD-0E6B-4924-BFD5-B9EE6A680C3B@gatech.edu>
References: <0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu>
	<545FC016.7060509@citrix.com>
In-Reply-To: <545FC016.7060509@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.61.61.158]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1097;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1097;
x-forefront-prvs: 0390DB4BDA
x-forefront-antispam-report: SFV:NSPM;
	SFS:(10019020)(199003)(479174003)(377454003)(24454002)(41574002)(189002)(120916001)(99396003)(82746002)(66066001)(101416001)(64706001)(20776003)(89122001)(110136001)(50986999)(54356999)(76176999)(33656002)(31966008)(36756003)(105586002)(87936001)(2656002)(92726001)(92566001)(4396001)(83716003)(21056001)(19580405001)(19580395003)(122556002)(40100003)(107886001)(95666004)(107046002)(2351001)(106356001)(99286002)(106116001)(62966003)(88552001)(77156002)(77096003)(86362001)(97736003)(90282001)(75432002)(16236675004)(450100001)(46102003)(104396001);
	DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1097;
	H:CY1PR0701MB1097.namprd07.prod.outlook.com; FPR:; MLV:sfv;
	PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
MIME-Version: 1.0
X-OriginatorOrg: gatech.edu
Subject: Re: [Xen-devel] Passing pointers to 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: multipart/mixed; boundary="===============0993886851507768952=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0993886851507768952==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_1FDFECBD0E6B4924BFD5B9EE6A680C3Bgatechedu_"

--_000_1FDFECBD0E6B4924BFD5B9EE6A680C3Bgatechedu_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Of course. Agh, I forgot to change it to 1.

If someone else looks at this, in my case it means this file: xen/arch/x86/=
x86_64/entry.S

Thanks!


On Nov 9, 2014, at 2:27 PM, Andrew Cooper <andrew.cooper3@citrix.com<mailto=
:andrew.cooper3@citrix.com>> wrote:

On 09/11/14 19:16, Amaro, Emmanuel wrote:
Hello,

I am trying to pass a pointer to an hyper call in the simplest possible way=
, set it=92s value, an return it to the guest.

I have tried 2 different ways:
- Directly with simple pointers (I read somewhere this would work on x86), =
but the pointer address is set to 0x0000deadbeef, so dereferencing it cause=
s a panic.
- With XEN_GUEST_HANDLE:
long do_dummy(XEN_GUEST_HANDLE(uint64_t) ptr)
{

It looks like you have introduced a new hypercall called dummy.

I presume from this code that you have filled in a new handler in the hyper=
call_table, but have you set the expected number of args in the hypercall_a=
rgs_table?

The default number of args is 0, which cases a debug Xen to deliberately cl=
obber all the registers to 0xdeadbeef

~Andrew


--_000_1FDFECBD0E6B4924BFD5B9EE6A680C3Bgatechedu_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <6B8132375839C4469F1BA0B8D0F9D6AE@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space;" class=3D"">
<div class=3D"">
<div class=3D"">Of course. Agh, I forgot to change it to 1.</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">If someone else looks at this, in my case it means this fil=
e: xen/arch/x86/x86_64/entry.S</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">Thanks!</div>
</div>
<div class=3D""><br class=3D"">
</div>
<br class=3D"">
<div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">On Nov 9, 2014, at 2:27 PM, Andrew Cooper &lt;<a href=3D"ma=
ilto:andrew.cooper3@citrix.com" class=3D"">andrew.cooper3@citrix.com</a>&gt=
; wrote:</div>
<br class=3D"Apple-interchange-newline">
<div class=3D"">
<div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D"">
<div class=3D"moz-cite-prefix">On 09/11/14 19:16, Amaro, Emmanuel wrote:<br=
 class=3D"">
</div>
<blockquote cite=3D"mid:0D65FE40-5E54-4369-BE06-79EFAF9E3607@gatech.edu" ty=
pe=3D"cite" class=3D"">
Hello,
<div class=3D""><br class=3D"">
</div>
<div class=3D"">I am trying to pass a pointer to an hyper call in the simpl=
est possible way, set it=92s value, an return it to the guest.</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">I have tried 2 different ways:</div>
<div class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre"></=
span>- Directly with simple pointers (I read somewhere this would work on x=
86), but the pointer address is set to 0x0000deadbeef, so dereferencing it =
causes a panic.</div>
<div class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre"></=
span>- With XEN_GUEST_HANDLE:</div>
<blockquote style=3D"margin: 0 0 0 40px; border: none; padding:
        0px;" class=3D"">
<blockquote style=3D"margin: 0 0 0 40px; border: none; padding:
          0px;" class=3D"">
<div class=3D"">
<div class=3D"">long do_dummy(XEN_GUEST_HANDLE(uint64_t) ptr)</div>
</div>
</blockquote>
<blockquote style=3D"margin: 0 0 0 40px; border: none; padding:
          0px;" class=3D"">
<div class=3D"">
<div class=3D"">{</div>
</div>
</blockquote>
</blockquote>
</blockquote>
<br class=3D"">
It looks like you have introduced a new hypercall called dummy.<br class=3D=
"">
<br class=3D"">
I presume from this code that you have filled in a new handler in the hyper=
call_table, but have you set the expected number of args in the hypercall_a=
rgs_table?<br class=3D"">
<br class=3D"">
The default number of args is 0, which cases a debug Xen to deliberately cl=
obber all the registers to 0xdeadbeef<br class=3D"">
<br class=3D"">
~Andrew<br class=3D"">
</div>
</div>
</blockquote>
</div>
<br class=3D"">
</body>
</html>

--_000_1FDFECBD0E6B4924BFD5B9EE6A680C3Bgatechedu_--


--===============0993886851507768952==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0993886851507768952==--


From xen-devel-bounces@lists.xen.org Sun Nov 09 22:51:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 22:51:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnbKD-0001AP-Ik; Sun, 09 Nov 2014 22:51:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnbKC-0001AK-6V
	for xen-devel@lists.xensource.com; Sun, 09 Nov 2014 22:51:12 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	9C/4F-27785-FDFEF545; Sun, 09 Nov 2014 22:51:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415573469!12313941!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26734 invoked from network); 9 Nov 2014 22:51:10 -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;
	9 Nov 2014 22:51:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,348,1413244800"; d="scan'208";a="189593877"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 9 Nov 2014 17:50:58 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnbJy-0001jC-Bg;
	Sun, 09 Nov 2014 22:50:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnbJy-00027U-0Z;
	Sun, 09 Nov 2014 22:50:58 +0000
Date: Sun, 9 Nov 2014 22:50:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31451-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31451: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31451 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31451/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   18 guest-migrate/dst_host/src_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv            7 debian-install              fail pass in 31443
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot              fail pass in 31443
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 31443 pass in 31451
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31451
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31451
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31451

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31443 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 22:51:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 22:51:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnbKD-0001AP-Ik; Sun, 09 Nov 2014 22:51:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnbKC-0001AK-6V
	for xen-devel@lists.xensource.com; Sun, 09 Nov 2014 22:51:12 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	9C/4F-27785-FDFEF545; Sun, 09 Nov 2014 22:51:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415573469!12313941!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26734 invoked from network); 9 Nov 2014 22:51:10 -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;
	9 Nov 2014 22:51:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,348,1413244800"; d="scan'208";a="189593877"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 9 Nov 2014 17:50:58 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnbJy-0001jC-Bg;
	Sun, 09 Nov 2014 22:50:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnbJy-00027U-0Z;
	Sun, 09 Nov 2014 22:50:58 +0000
Date: Sun, 9 Nov 2014 22:50:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31451-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31451: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31451 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31451/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   18 guest-migrate/dst_host/src_host fail REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv            7 debian-install              fail pass in 31443
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot              fail pass in 31443
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 31443 pass in 31451
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31451
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31451
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31451

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31443 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 09 23:04:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 23:04:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnbWR-0001PZ-2k; Sun, 09 Nov 2014 23:03:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XnbWP-0001PU-JP
	for xen-devel@lists.xenproject.org; Sun, 09 Nov 2014 23:03:49 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	1A/E6-16982-4D2FF545; Sun, 09 Nov 2014 23:03:48 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415574227!11368015!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23848 invoked from network); 9 Nov 2014 23:03:47 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Nov 2014 23:03:47 -0000
Received: from jarvis.univie.ac.at ([131.130.3.112] helo=jarvis.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XnbWL-0001xx-PJ; Mon, 10 Nov 2014 00:03:45 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.68])
	by jarvis.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XnbWK-0000Te-UT; Mon, 10 Nov 2014 00:03:45 +0100
Message-ID: <545FF2D2.4020202@web2web.at>
Date: Mon, 10 Nov 2014 00:03:46 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>	
	<1414493998.10206.3.camel@citrix.com> <544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>
In-Reply-To: <1414512266.10974.5.camel@citrix.com>
Content-Type: multipart/mixed; boundary="------------060301040209050003050701"
X-Univie-Virus-Scan: scanned by ClamAV on jarvis.univie.ac.at
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] segfault in xl create for HVM with 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------060301040209050003050701
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Am 28.10.14 um 17:04 schrieb Ian Campbell:
> On Tue, 2014-10-28 at 16:39 +0100, Atom2 wrote:
>>> Please can you run the command under gdb and grab a back trace.
>>>

I have now re-compiled a few more pieces with debugging support, namely 
gcc-8.4.3 and glibc and again run the command
	xl create pfsense -c
under gdb. The new (full) backtrace output is attached to this mail and 
might provide you with some more clues.

BTW the same problem also seems to exist for xen-4.4.1/gcc-4.8.3 and was 
found independent of my report - please see further details and a 
discussion at http://forums.gentoo.org/viewtopic-t-1003746.html and the 
related bug report at https://bugs.gentoo.org/show_bug.cgi?id=528690.

Ian - if you (or anybody else) could add any more insight into this, it 
would be very much appreciated.

Thanks again Atom2

--------------060301040209050003050701
Content-Type: text/plain; charset=windows-1252;
 name="backtrace-xen-4.3.3-r1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="backtrace-xen-4.3.3-r1"

dm0taG9zdCBhdXRvIFs1MTJdICMgZ2RiIC0tYXJncyB4bCBjcmVhdGUgcGZzZW5zZSAtYwpH
TlUgZ2RiIChHZW50b28gNy43LjEgcDEpIDcuNy4xCkNvcHlyaWdodCAoQykgMjAxNCBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KTGljZW5zZSBHUEx2Mys6IEdOVSBHUEwgdmVy
c2lvbiAzIG9yIGxhdGVyIDxodHRwOi8vZ251Lm9yZy9saWNlbnNlcy9ncGwuaHRtbD4KVGhp
cyBpcyBmcmVlIHNvZnR3YXJlOiB5b3UgYXJlIGZyZWUgdG8gY2hhbmdlIGFuZCByZWRpc3Ry
aWJ1dGUgaXQuClRoZXJlIGlzIE5PIFdBUlJBTlRZLCB0byB0aGUgZXh0ZW50IHBlcm1pdHRl
ZCBieSBsYXcuICBUeXBlICJzaG93IGNvcHlpbmciCmFuZCAic2hvdyB3YXJyYW50eSIgZm9y
IGRldGFpbHMuClRoaXMgR0RCIHdhcyBjb25maWd1cmVkIGFzICJ4ODZfNjQtcGMtbGludXgt
Z251Ii4KVHlwZSAic2hvdyBjb25maWd1cmF0aW9uIiBmb3IgY29uZmlndXJhdGlvbiBkZXRh
aWxzLgpGb3IgYnVnIHJlcG9ydGluZyBpbnN0cnVjdGlvbnMsIHBsZWFzZSBzZWU6CjxodHRw
Oi8vYnVncy5nZW50b28ub3JnLz4uCkZpbmQgdGhlIEdEQiBtYW51YWwgYW5kIG90aGVyIGRv
Y3VtZW50YXRpb24gcmVzb3VyY2VzIG9ubGluZSBhdDoKPGh0dHA6Ly93d3cuZ251Lm9yZy9z
b2Z0d2FyZS9nZGIvZG9jdW1lbnRhdGlvbi8+LgpGb3IgaGVscCwgdHlwZSAiaGVscCIuClR5
cGUgImFwcm9wb3Mgd29yZCIgdG8gc2VhcmNoIGZvciBjb21tYW5kcyByZWxhdGVkIHRvICJ3
b3JkIi4uLgpSZWFkaW5nIHN5bWJvbHMgZnJvbSB4bC4uLlJlYWRpbmcgc3ltYm9scyBmcm9t
IC91c3IvbGliNjQvZGVidWcvL3Vzci9zYmluL3hsLmRlYnVnLi4uZG9uZS4KZG9uZS4KKGdk
YikgcnVuClN0YXJ0aW5nIHByb2dyYW06IC91c3Ivc2Jpbi94bCBjcmVhdGUgcGZzZW5zZSAt
Ywp3YXJuaW5nOiBDb3VsZCBub3QgbG9hZCBzaGFyZWQgbGlicmFyeSBzeW1ib2xzIGZvciBs
aW51eC12ZHNvLnNvLjEuCkRvIHlvdSBuZWVkICJzZXQgc29saWItc2VhcmNoLXBhdGgiIG9y
ICJzZXQgc3lzcm9vdCI/CltUaHJlYWQgZGVidWdnaW5nIHVzaW5nIGxpYnRocmVhZF9kYiBl
bmFibGVkXQpVc2luZyBob3N0IGxpYnRocmVhZF9kYiBsaWJyYXJ5ICIvbGliNjQvbGlidGhy
ZWFkX2RiLnNvLjEiLgpQYXJzaW5nIGNvbmZpZyBmcm9tIHBmc2Vuc2UKeGM6IGluZm86IFZJ
UlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgogIExvYWRlcjogICAgICAgIDAwMDAwMDAwMDAx
MDAwMDAtPjAwMDAwMDAwMDAxYzEwYzQKICBNb2R1bGVzOiAgICAgICAwMDAwMDAwMDAwMDAw
MDAwLT4wMDAwMDAwMDAwMDAwMDAwCiAgVE9UQUw6ICAgICAgICAgMDAwMDAwMDAwMDAwMDAw
MC0+MDAwMDAwMDAxZjgwMDAwMAogIEVOVFJZIEFERFJFU1M6IDAwMDAwMDAwMDAxMDAwMDAK
eGM6IGluZm86IFBIWVNJQ0FMIE1FTU9SWSBBTExPQ0FUSU9OOgogIDRLQiBQQUdFUzogMHgw
MDAwMDAwMDAwMDAwMjAwCiAgMk1CIFBBR0VTOiAweDAwMDAwMDAwMDAwMDAwZmIKICAxR0Ig
UEFHRVM6IDB4MDAwMDAwMDAwMDAwMDAwMApbTmV3IFRocmVhZCAweDdmZmZmN2ZmNTcwMCAo
TFdQIDI0ODkpXQpbTmV3IFRocmVhZCAweDdmZmZmN2ZlNjcwMCAoTFdQIDI2MDEpXQoKUHJv
Z3JhbSByZWNlaXZlZCBzaWduYWwgU0lHU0VHViwgU2VnbWVudGF0aW9uIGZhdWx0LgpbU3dp
dGNoaW5nIHRvIFRocmVhZCAweDdmZmZmN2ZlNjcwMCAoTFdQIDI2MDEpXQoweDAwMDA3ZmZm
ZjU4OTI2MjQgaW4gZXhlY3V0ZV9zdGFja19vcCAob3BfcHRyPTB4N2ZmZmY3MzI5YjgzICJ3
XDI0MFwwMDFcMDA2XDAyMFxiXDAwMncoXDAyMFx0XDAwMncwXDAyMFxuXDAwMnc4XDAyMFx2
XDAwM3dcMzAwIiwKICAgIG9wX2VuZD0weDdmZmZmNzMyOWI4NyAiXDAyMFxiXDAwMncoXDAy
MFx0XDAwMncwXDAyMFxuXDAwMnc4XDAyMFx2XDAwM3dcMzAwIiwgY29udGV4dD1jb250ZXh0
QGVudHJ5PTB4N2ZmZmY3ZmU1MTkwLAogICAgaW5pdGlhbD1pbml0aWFsQGVudHJ5PTApIGF0
IC92YXIvdG1wL3BvcnRhZ2Uvc3lzLWRldmVsL2djYy00LjguMy93b3JrL2djYy00LjguMy9s
aWJnY2MvdW53aW5kLWR3Mi5jOjUxNgo1MTYgICAgIC92YXIvdG1wL3BvcnRhZ2Uvc3lzLWRl
dmVsL2djYy00LjguMy93b3JrL2djYy00LjguMy9saWJnY2MvdW53aW5kLWR3Mi5jOiBObyBz
dWNoIGZpbGUgb3IgZGlyZWN0b3J5LgooZ2RiKSBidCBmdWxsCiMwICAweDAwMDA3ZmZmZjU4
OTI2MjQgaW4gZXhlY3V0ZV9zdGFja19vcCAoCiAgICBvcF9wdHI9MHg3ZmZmZjczMjliODMg
IndcMjQwXDAwMVwwMDZcMDIwXGJcMDAydyhcMDIwXHRcMDAydzBcMDIwXG5cMDAydzhcMDIw
XHZcMDAzd1wzMDAiLAogICAgb3BfZW5kPTB4N2ZmZmY3MzI5Yjg3ICJcMDIwXGJcMDAydyhc
MDIwXHRcMDAydzBcMDIwXG5cMDAydzhcMDIwXHZcMDAzd1wzMDAiLCBjb250ZXh0PWNvbnRl
eHRAZW50cnk9MHg3ZmZmZjdmZTUxOTAsCiAgICBpbml0aWFsPWluaXRpYWxAZW50cnk9MCkg
YXQgL3Zhci90bXAvcG9ydGFnZS9zeXMtZGV2ZWwvZ2NjLTQuOC4zL3dvcmsvZ2NjLTQuOC4z
L2xpYmdjYy91bndpbmQtZHcyLmM6NTE2CiAgICAgICAgc3RhY2sgPSB7MCA8cmVwZWF0cyA0
NCB0aW1lcz4sIDE0MDczNzM1NDAyNzE2OCwgMTQwNzM3MzEyODAzNzMxLCAxNDA3MzczNTQw
MjcxODQsIDE0MDczNzM1NDAyNzQ4OCwgMTQwNzM3MzQwNjYwNzMyLAogICAgICAgICAgMTQw
NzM3MzQwNjYzMDE2LCAxNDA3MzczNTQwMjczMTIsIDE0MDczNzMxMjgwODc0NywgMTQwNzM3
MzU0MDI3MzI4LCAxNDA3MzMxOTMzODgwMzUsIDE0MDczNzM0MDY2MzU2MCwgMzUyLCAxMCwg
MTY3LCAyMjAsCiAgICAgICAgICAwLCAwLCAwLCAwLCAxNDA3MzczNTQxMjk3MzZ9CiAgICAg
ICAgc3RhY2tfZWx0ID0gPG9wdGltaXplZCBvdXQ+CiMxICAweDAwMDA3ZmZmZjU4OTMwOGMg
aW4gdXdfdXBkYXRlX2NvbnRleHRfMSAoY29udGV4dD1jb250ZXh0QGVudHJ5PTB4N2ZmZmY3
ZmU1NWEwLCBmcz1mc0BlbnRyeT0weDdmZmZmN2ZlNTJmMCkKICAgIGF0IC92YXIvdG1wL3Bv
cnRhZ2Uvc3lzLWRldmVsL2djYy00LjguMy93b3JrL2djYy00LjguMy9saWJnY2MvdW53aW5k
LWR3Mi5jOjE0MjQKICAgICAgICBleHAgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBsZW4g
PSA8b3B0aW1pemVkIG91dD4KICAgICAgICBvcmlnX2NvbnRleHQgPSB7cmVnID0gezB4N2Zm
ZmY3ZmU1Njk4LCAweDdmZmZmN2ZlNTZhMCwgMHgwLCAweDdmZmZmN2ZlNTZhOCwgMHgwLCAw
eDAsIDB4N2ZmZmY3ZmU1NmYwLCAweDdmZmZmN2ZlNTE4MCwgMHgwLAogICAgICAgICAgICAw
eDAsIDB4MCwgMHgwLCAweDdmZmZmN2ZlNTZiMCwgMHg3ZmZmZjdmZTU2YjgsIDB4N2ZmZmY3
ZmU1NmMwLCAweDdmZmZmN2ZlNTZjOCwgMHg3ZmZmZjdmZTU2ZjgsIDB4MH0sCiAgICAgICAg
ICBjZmEgPSAweDdmZmZmN2ZlNTcwMCwgcmEgPSAweDdmZmZmNzMyMmUwMCA8X19yZXN0b3Jl
X3J0PiwgbHNkYSA9IDB4MCwgYmFzZXMgPSB7dGJhc2UgPSAweDAsIGRiYXNlID0gMHgwLAog
ICAgICAgICAgICBmdW5jID0gMHg3ZmZmZjczMjJkZmZ9LCBmbGFncyA9IDQ2MTE2ODYwMTg0
MjczODc5MDQsIHZlcnNpb24gPSAwLCBhcmdzX3NpemUgPSAwLCBieV92YWx1ZSA9ICdcMDAw
JyA8cmVwZWF0cyAxNyB0aW1lcz59CiAgICAgICAgY2ZhID0gPG9wdGltaXplZCBvdXQ+CiAg
ICAgICAgaSA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIHRtcF9zcCA9IHtwdHIgPSAxNDA3
MzczNTQwMjg4MDAsIHdvcmQgPSAxNDA3MzczNTQwMjg4MDB9CiMyICAweDAwMDA3ZmZmZjU4
OTM0MDUgaW4gdXdfdXBkYXRlX2NvbnRleHQgKGNvbnRleHQ9Y29udGV4dEBlbnRyeT0weDdm
ZmZmN2ZlNTVhMCwgZnM9ZnNAZW50cnk9MHg3ZmZmZjdmZTUyZjApCiAgICBhdCAvdmFyL3Rt
cC9wb3J0YWdlL3N5cy1kZXZlbC9nY2MtNC44LjMvd29yay9nY2MtNC44LjMvbGliZ2NjL3Vu
d2luZC1kdzIuYzoxNTA2Ck5vIGxvY2Fscy4KIzMgIDB4MDAwMDdmZmZmNTg5NDA4NiBpbiB1
d19hZHZhbmNlX2NvbnRleHQgKGZzPTB4N2ZmZmY3ZmU1MmYwLCBjb250ZXh0PTB4N2ZmZmY3
ZmU1NWEwKQogICAgYXQgL3Zhci90bXAvcG9ydGFnZS9zeXMtZGV2ZWwvZ2NjLTQuOC4zL3dv
cmsvZ2NjLTQuOC4zL2xpYmdjYy91bndpbmQtZHcyLmM6MTUyOQpObyBsb2NhbHMuCiM0ICBf
VW53aW5kX0ZvcmNlZFVud2luZF9QaGFzZTIgKGV4Yz1leGNAZW50cnk9MHg3ZmZmZjdmZTZk
NzAsIGNvbnRleHQ9Y29udGV4dEBlbnRyeT0weDdmZmZmN2ZlNTVhMCkKICAgIGF0IC92YXIv
dG1wL3BvcnRhZ2Uvc3lzLWRldmVsL2djYy00LjguMy93b3JrL2djYy00LjguMy9saWJnY2Mv
dW53aW5kLmluYzoxODUKICAgICAgICBmcyA9IHtyZWdzID0ge3JlZyA9IHt7bG9jID0ge3Jl
ZyA9IDE0MDczNzM0MDY3NzA3Niwgb2Zmc2V0ID0gMTQwNzM3MzQwNjc3MDc2LAogICAgICAg
ICAgICAgICAgICBleHAgPSAweDdmZmZmNzMyOWJkNCAiXDAwM3dcMjIwXDAwMVwwMjBcMDAy
XDAwM3dcMjMwXDAwMVwwMjBcYVwwMDN3XDI0MFwwMDFcMDIwXDAyMFwwMDN3XDI1MFwwMDEi
fSwKICAgICAgICAgICAgICAgIGhvdyA9IFJFR19TQVZFRF9FWFB9LCB7bG9jID0ge3JlZyA9
IDE0MDczNzM0MDY3NzA3MCwgb2Zmc2V0ID0gMTQwNzM3MzQwNjc3MDcwLAogICAgICAgICAg
ICAgICAgICBleHAgPSAweDdmZmZmNzMyOWJjZSAiXDAwM3dcMjEwXDAwMVwwMjAifSwgaG93
ID0gUkVHX1NBVkVEX0VYUH0sIHtsb2MgPSB7cmVnID0gMTQwNzM3MzQwNjc3MDgyLAogICAg
ICAgICAgICAgICAgICBvZmZzZXQgPSAxNDA3MzczNDA2NzcwODIsIGV4cCA9IDB4N2ZmZmY3
MzI5YmRhICJcMDAzd1wyMzBcMDAxXDAyMFxhXDAwM3dcMjQwXDAwMVwwMjBcMDIwXDAwM3dc
MjUwXDAwMSJ9LAogICAgICAgICAgICAgICAgaG93ID0gUkVHX1NBVkVEX0VYUH0sIHtsb2Mg
PSB7cmVnID0gMTQwNzM3MzQwNjc3MDY0LCBvZmZzZXQgPSAxNDA3MzczNDA2NzcwNjQsCiAg
ICAgICAgICAgICAgICAgIGV4cCA9IDB4N2ZmZmY3MzI5YmM4ICJcMDAzd1wyMDBcMDAxXDAy
MFwwMDFcMDAzd1wyMTBcMDAxXDAyMCJ9LCBob3cgPSBSRUdfU0FWRURfRVhQfSwge2xvYyA9
IHsKICAgICAgICAgICAgICAgICAgcmVnID0gMTQwNzM3MzQwNjc3MDUyLCBvZmZzZXQgPSAx
NDA3MzczNDA2NzcwNTIsIGV4cCA9IDB4N2ZmZmY3MzI5YmJjICJcMDAzIiwgPGluY29tcGxl
dGUgc2VxdWVuY2UgXDM2MD59LAogICAgICAgICAgICAgICAgaG93ID0gUkVHX1NBVkVEX0VY
UH0sIHtsb2MgPSB7cmVnID0gMTQwNzM3MzQwNjc3MDQ2LCBvZmZzZXQgPSAxNDA3MzczNDA2
NzcwNDYsCiAgICAgICAgICAgICAgICAgIGV4cCA9IDB4N2ZmZmY3MzI5YmI2ICJcMDAzIiwg
PGluY29tcGxldGUgc2VxdWVuY2UgXDM1MD59LCBob3cgPSBSRUdfU0FWRURfRVhQfSwge2xv
YyA9IHtyZWcgPSAxNDA3MzczNDA2NzcwNTgsCiAgICAgICAgICAgICAgICAgIG9mZnNldCA9
IDE0MDczNzM0MDY3NzA1OCwgZXhwID0gMHg3ZmZmZjczMjliYzIgIlwwMDMiLCA8aW5jb21w
bGV0ZSBzZXF1ZW5jZSBcMzcwPn0sIGhvdyA9IFJFR19TQVZFRF9FWFB9LCB7CiAgICAgICAg
ICAgICAgICBsb2MgPSB7cmVnID0gMTQwNzM3MzQwNjc3MDg4LCBvZmZzZXQgPSAxNDA3Mzcz
NDA2NzcwODgsCiAgICAgICAgICAgICAgICAgIGV4cCA9IDB4N2ZmZmY3MzI5YmUwICJcMDAz
d1wyNDBcMDAxXDAyMFwwMjBcMDAzd1wyNTBcMDAxIn0sIGhvdyA9IFJFR19TQVZFRF9FWFB9
LCB7bG9jID0ge3JlZyA9IDE0MDczNzM0MDY3NzAwMSwKICAgICAgICAgICAgICAgICAgb2Zm
c2V0ID0gMTQwNzM3MzQwNjc3MDAxLCBleHAgPSAweDdmZmZmNzMyOWI4OSAiXDAwMncoXDAy
MFx0XDAwMncwXDAyMFxuXDAwMnc4XDAyMFx2XDAwM3dcMzAwIn0sCiAgICAgICAgICAgICAg
ICBob3cgPSBSRUdfU0FWRURfRVhQfSwge2xvYyA9IHtyZWcgPSAxNDA3MzczNDA2NzcwMDYs
IG9mZnNldCA9IDE0MDczNzM0MDY3NzAwNiwKICAgICAgICAgICAgICAgICAgZXhwID0gMHg3
ZmZmZjczMjliOGUgIlwwMDJ3MFwwMjBcblwwMDJ3OFwwMjBcdlwwMDN3XDMwMCJ9LCBob3cg
PSBSRUdfU0FWRURfRVhQfSwge2xvYyA9IHtyZWcgPSAxNDA3MzczNDA2NzcwMTEsCiAgICAg
ICAgICAgICAgICAgIG9mZnNldCA9IDE0MDczNzM0MDY3NzAxMSwgZXhwID0gMHg3ZmZmZjcz
MjliOTMgIlwwMDJ3OFwwMjBcdlwwMDN3XDMwMCJ9LCBob3cgPSBSRUdfU0FWRURfRVhQfSwg
e2xvYyA9IHsKICAgICAgICAgICAgICAgICAgcmVnID0gMTQwNzM3MzQwNjc3MDE2LCBvZmZz
ZXQgPSAxNDA3MzczNDA2NzcwMTYsIGV4cCA9IDB4N2ZmZmY3MzI5Yjk4ICJcMDAzd1wzMDAi
fSwgaG93ID0gUkVHX1NBVkVEX0VYUH0sIHsKICAgICAgICAgICAgICAgIGxvYyA9IHtyZWcg
PSAxNDA3MzczNDA2NzcwMjIsIG9mZnNldCA9IDE0MDczNzM0MDY3NzAyMiwgZXhwID0gMHg3
ZmZmZjczMjliOWUgIlwwMDMiLCA8aW5jb21wbGV0ZSBzZXF1ZW5jZSBcMzEwPn0sCiAgICAg
ICAgICAgICAgICBob3cgPSBSRUdfU0FWRURfRVhQfSwge2xvYyA9IHtyZWcgPSAxNDA3Mzcz
NDA2NzcwMjgsIG9mZnNldCA9IDE0MDczNzM0MDY3NzAyOCwKICAgICAgICAgICAgICAgICAg
ZXhwID0gMHg3ZmZmZjczMjliYTQgIlwwMDMiLCA8aW5jb21wbGV0ZSBzZXF1ZW5jZSBcMzIw
Pn0sIGhvdyA9IFJFR19TQVZFRF9FWFB9LCB7bG9jID0ge3JlZyA9IDE0MDczNzM0MDY3NzAz
NCwKICAgICAgICAgICAgICAgICAgb2Zmc2V0ID0gMTQwNzM3MzQwNjc3MDM0LCBleHAgPSAw
eDdmZmZmNzMyOWJhYSAiXDAwMyIsIDxpbmNvbXBsZXRlIHNlcXVlbmNlIFwzMzA+fSwgaG93
ID0gUkVHX1NBVkVEX0VYUH0sIHsKICAgICAgICAgICAgICAgIGxvYyA9IHtyZWcgPSAxNDA3
MzczNDA2NzcwNDAsIG9mZnNldCA9IDE0MDczNzM0MDY3NzA0MCwgZXhwID0gMHg3ZmZmZjcz
MjliYjAgIlwwMDMiLCA8aW5jb21wbGV0ZSBzZXF1ZW5jZSBcMzQwPn0sCiAgICAgICAgICAg
ICAgICBob3cgPSBSRUdfU0FWRURfRVhQfSwge2xvYyA9IHtyZWcgPSAxNDA3MzczNDA2Nzcw
OTQsIG9mZnNldCA9IDE0MDczNzM0MDY3NzA5NCwKICAgICAgICAgICAgICAgICAgZXhwID0g
MHg3ZmZmZjczMjliZTYgIlwwMDN3XDI1MFwwMDEifSwgaG93ID0gUkVHX1NBVkVEX0VYUH0s
IHtsb2MgPSB7cmVnID0gMCwgb2Zmc2V0ID0gMCwgZXhwID0gMHgwfSwKICAgICAgICAgICAg
ICAgIGhvdyA9IFJFR19VTlNBVkVEfX0sIHByZXYgPSAweDAsIGNmYV9vZmZzZXQgPSAwLCBj
ZmFfcmVnID0gMCwKICAgICAgICAgICAgY2ZhX2V4cCA9IDB4N2ZmZmY3MzI5YjgyICJcMDA0
d1wyNDBcMDAxXDAwNlwwMjBcYlwwMDJ3KFwwMjBcdFwwMDJ3MFwwMjBcblwwMDJ3OFwwMjBc
dlwwMDN3XDMwMCIsIGNmYV9ob3cgPSBDRkFfRVhQfSwKICAgICAgICAgIHBjID0gMHg3ZmZm
ZjczMjJkZmYsIHBlcnNvbmFsaXR5ID0gMHgwLCBkYXRhX2FsaWduID0gLTgsIGNvZGVfYWxp
Z24gPSAxLCByZXRhZGRyX2NvbHVtbiA9IDE2LCBmZGVfZW5jb2RpbmcgPSAyNyAnXDAzMycs
CiAgICAgICAgICBsc2RhX2VuY29kaW5nID0gMjU1ICdcMzc3Jywgc2F3X3ogPSAxICdcMDAx
Jywgc2lnbmFsX2ZyYW1lID0gMSAnXDAwMScsIGVoX3B0ciA9IDB4MH0KICAgICAgICBhY3Rp
b24gPSAxMAogICAgICAgIHN0b3AgPSAweDdmZmZmNzMyMTVlMCA8dW53aW5kX3N0b3A+CiAg
ICAgICAgc3RvcF9hcmd1bWVudCA9IDB4N2ZmZmY3ZmU1ZDMwCiAgICAgICAgY29kZSA9IDxv
cHRpbWl6ZWQgb3V0PgogICAgICAgIHN0b3BfY29kZSA9IDxvcHRpbWl6ZWQgb3V0PgojNSAg
MHgwMDAwN2ZmZmY1ODk0NDBjIGluIF9VbndpbmRfRm9yY2VkVW53aW5kIChleGM9MHg3ZmZm
ZjdmZTZkNzAsIHN0b3A9c3RvcEBlbnRyeT0weDdmZmZmNzMyMTVlMCA8dW53aW5kX3N0b3A+
LAogICAgc3RvcF9hcmd1bWVudD0weDdmZmZmN2ZlNWQzMCkgYXQgL3Zhci90bXAvcG9ydGFn
ZS9zeXMtZGV2ZWwvZ2NjLTQuOC4zL3dvcmsvZ2NjLTQuOC4zL2xpYmdjYy91bndpbmQuaW5j
OjIwNwogICAgICAgIHRoaXNfY29udGV4dCA9IHtyZWcgPSB7MHg3ZmZmZjdmZTU2OTgsIDB4
N2ZmZmY3ZmU1NmEwLCAweDAsIDB4N2ZmZmY3ZmU1NmE4LCAweDAsIDB4MCwgMHg3ZmZmZjdm
ZTU2ZDAsIDB4MCwgMHgwLCAweDAsIDB4MCwKICAgICAgICAgICAgMHgwLCAweDdmZmZmN2Zl
NTZiMCwgMHg3ZmZmZjdmZTU2YjgsIDB4N2ZmZmY3ZmU1NmMwLCAweDdmZmZmN2ZlNTZjOCwg
MHg3ZmZmZjdmZTU2ZDgsIDB4MH0sIGNmYSA9IDB4N2ZmZmY3ZmU1NmUwLAogICAgICAgICAg
cmEgPSAweDdmZmZmNzMyMTc3MyA8X19HSV9fX3B0aHJlYWRfdW53aW5kKzgzPiwgbHNkYSA9
IDB4MCwgYmFzZXMgPSB7dGJhc2UgPSAweDAsIGRiYXNlID0gMHgwLAogICAgICAgICAgICBm
dW5jID0gMHg3ZmZmZjU4OTQzYTAgPF9VbndpbmRfRm9yY2VkVW53aW5kPn0sIGZsYWdzID0g
NDYxMTY4NjAxODQyNzM4NzkwNCwgdmVyc2lvbiA9IDAsIGFyZ3Nfc2l6ZSA9IDAsCiAgICAg
ICAgICBieV92YWx1ZSA9ICdcMDAwJyA8cmVwZWF0cyAxNyB0aW1lcz59CiAgICAgICAgY3Vy
X2NvbnRleHQgPSB7cmVnID0gezB4N2ZmZmY3ZmU1Njk4LCAweDdmZmZmN2ZlNTZhMCwgMHgw
LCAweDdmZmZmN2ZlNTZhOCwgMHgwLCAweDAsIDB4N2ZmZmY3ZmU1NmYwLCAweDAsIDB4MCwg
MHgwLCAweDAsCiAgICAgICAgICAgIDB4MCwgMHg3ZmZmZjdmZTU2YjAsIDB4N2ZmZmY3ZmU1
NmI4LCAweDdmZmZmN2ZlNTZjMCwgMHg3ZmZmZjdmZTU2YzgsIDB4N2ZmZmY3ZmU1NmY4LCAw
eDB9LCBjZmEgPSAweDdmZmZmN2ZlNTcwMCwKICAgICAgICAgIHJhID0gMHg3ZmZmZjczMjJl
MDAgPF9fcmVzdG9yZV9ydD4sIGxzZGEgPSAweDAsIGJhc2VzID0ge3RiYXNlID0gMHgwLCBk
YmFzZSA9IDB4MCwgZnVuYyA9IDB4N2ZmZmY3MzIyZGZmfSwKICAgICAgICAgIGZsYWdzID0g
NDYxMTY4NjAxODQyNzM4NzkwNCwgdmVyc2lvbiA9IDAsIGFyZ3Nfc2l6ZSA9IDAsIGJ5X3Zh
bHVlID0gJ1wwMDAnIDxyZXBlYXRzIDE3IHRpbWVzPn0KICAgICAgICBjb2RlID0gPG9wdGlt
aXplZCBvdXQ+CiM2ICAweDAwMDA3ZmZmZjczMjE3NzMgaW4gX19HSV9fX3B0aHJlYWRfdW53
aW5kIChidWY9PG9wdGltaXplZCBvdXQ+KSBhdCB1bndpbmQuYzoxMjkKICAgICAgICBpYnVm
ID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgc2VsZiA9IDxvcHRpbWl6ZWQgb3V0PgojNyAg
MHgwMDAwN2ZmZmY3MzE4Yjg5IGluIF9fZG9fY2FuY2VsICgpIGF0IC4uL25wdGwvcHRocmVh
ZFAuaDoyODAKTm8gbG9jYWxzLgojOCAgc2lnY2FuY2VsX2hhbmRsZXIgKHNpZz08b3B0aW1p
emVkIG91dD4sIHNpPTxvcHRpbWl6ZWQgb3V0PiwgY3R4PTxvcHRpbWl6ZWQgb3V0PikgYXQg
bnB0bC1pbml0LmM6MjE0CiAgICAgICAgc2kgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBj
dHggPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBwaWQgPSA8b3B0aW1pemVkIG91dD4KICAg
ICAgICBvbGR2YWwgPSA8b3B0aW1pemVkIG91dD4KIzkgIDxzaWduYWwgaGFuZGxlciBjYWxs
ZWQ+Ck5vIGxvY2Fscy4KIzEwIDB4MDAwMDdmZmZmNzMyMWU4ZCBpbiByZWFkICgpIGF0IC4u
L3N5c2RlcHMvdW5peC9zeXNjYWxsLXRlbXBsYXRlLlM6ODEKTm8gbG9jYWxzLgojMTEgMHgw
MDAwN2ZmZmY2YjI0N2MzIGluIHJlYWQgKF9fbmJ5dGVzPTE2LCBfX2J1Zj0weDdmZmZlODAw
MDhkMCwgX19mZD0xNCkgYXQgL3Vzci9pbmNsdWRlL2JpdHMvdW5pc3RkLmg6NDQKTm8gbG9j
YWxzLgojMTIgcmVhZF9hbGwgKGZkPTE0LCBkYXRhPWRhdGFAZW50cnk9MHg3ZmZmZTgwMDA4
ZDAsIGxlbj1sZW5AZW50cnk9MTYsIG5vbmJsb2NraW5nPW5vbmJsb2NraW5nQGVudHJ5PTAp
IGF0IHhzLmM6Mzc0CiAgICAgICAgZG9uZSA9IDxvcHRpbWl6ZWQgb3V0PgojMTMgMHgwMDAw
N2ZmZmY2YjI0OTA0IGluIHJlYWRfbWVzc2FnZSAoaD1oQGVudHJ5PTB4NTU1NTU1Nzg0Mjgw
LCBub25ibG9ja2luZz1ub25ibG9ja2luZ0BlbnRyeT0wKSBhdCB4cy5jOjExMzkKICAgICAg
ICBfX2NhbmNlbF9idWYgPSB7X19jYW5jZWxfam1wX2J1ZiA9IHt7X19jYW5jZWxfam1wX2J1
ZiA9IHs5MzgyNDk5NDUyNTgyNCwgMTI4MjY0MzI0NTkwNjAwNzg1MSwgMSwgMTQwNzM3NDg4
MzQxMTIwLAogICAgICAgICAgICAgICAgOTM4MjQ5OTQ1MjQwNjQsIDE0MDczNzM1NDAzMjg5
NiwgMTI4MjY0MzI0NTg1Nzc3MzM1NSwgMTI4MjY0NTg5MjIwNjY5NjIzNX0sIF9fbWFza193
YXNfc2F2ZWQgPSAwfX0sIF9fcGFkID0gewogICAgICAgICAgICAweDdmZmZmN2ZlNWVlMCwg
MHgwLCAweDAsIDB4MH19CiAgICAgICAgX19jYW5jZWxfYXJnID0gMHg3ZmZmZTgwMDA4YzAK
ICAgICAgICBfX25vdF9maXJzdF9jYWxsID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgbXNn
ID0gMHg3ZmZmZTgwMDA4YzAKICAgICAgICBib2R5ID0gMHgwCiAgICAgICAgc2F2ZWRfZXJy
bm8gPSAwCiAgICAgICAgcmV0ID0gLTEKIzE0IDB4MDAwMDdmZmZmNmIyNTI5NiBpbiByZWFk
X3RocmVhZCAoYXJnPTB4NTU1NTU1Nzg0MjgwKSBhdCB4cy5jOjEyMTEKICAgICAgICBoID0g
MHg1NTU1NTU3ODQyODAKICAgICAgICBmZCA9IDxvcHRpbWl6ZWQgb3V0PgojMTUgMHgwMDAw
N2ZmZmY3MzFhMzZkIGluIHN0YXJ0X3RocmVhZCAoYXJnPTB4N2ZmZmY3ZmU2NzAwKSBhdCBw
dGhyZWFkX2NyZWF0ZS5jOjMwOQogICAgICAgIF9fcmVzID0gPG9wdGltaXplZCBvdXQ+CiAg
ICAgICAgcGQgPSAweDdmZmZmN2ZlNjcwMAogICAgICAgIG5vdyA9IDxvcHRpbWl6ZWQgb3V0
PgogICAgICAgIHVud2luZF9idWYgPSB7Y2FuY2VsX2ptcF9idWYgPSB7e2ptcF9idWYgPSB7
MTQwNzM3MzU0MDMyODk2LCAxMjgyNjQzMjQ1OTEwMjAyMTU1LCAxLCAxNDA3Mzc0ODgzNDEx
MjAsIDkzODI0OTk0NTI0MDY0LAogICAgICAgICAgICAgICAgMTQwNzM3MzU0MDMyODk2LCAx
MjgyNjQzMjQ1ODk3NjE5MjQzLCAxMjgyNjQyNTg4NjU0NjM4ODkxfSwgbWFza193YXNfc2F2
ZWQgPSAwfX0sIHByaXYgPSB7cGFkID0gezB4MCwgMHgwLCAweDAsCiAgICAgICAgICAgICAg
MHgwfSwgZGF0YSA9IHtwcmV2ID0gMHgwLCBjbGVhbnVwID0gMHgwLCBjYW5jZWx0eXBlID0g
MH19fQogICAgICAgIG5vdF9maXJzdF9jYWxsID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAg
cm9idXN0ID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgcGFnZXNpemVfbTEgPSA8b3B0aW1p
emVkIG91dD4KICAgICAgICBzcCA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIGZyZWVzaXpl
ID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgX19QUkVUVFlfRlVOQ1RJT05fXyA9ICJzdGFy
dF90aHJlYWQiCiMxNiAweDAwMDA3ZmZmZjcwNTJlMGQgaW4gY2xvbmUgKCkgYXQgLi4vc3lz
ZGVwcy91bml4L3N5c3YvbGludXgveDg2XzY0L2Nsb25lLlM6MTExCk5vIGxvY2Fscy4KKGdk
YikK
--------------060301040209050003050701
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060301040209050003050701--


From xen-devel-bounces@lists.xen.org Sun Nov 09 23:04:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Nov 2014 23:04:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnbWR-0001PZ-2k; Sun, 09 Nov 2014 23:03:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XnbWP-0001PU-JP
	for xen-devel@lists.xenproject.org; Sun, 09 Nov 2014 23:03:49 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	1A/E6-16982-4D2FF545; Sun, 09 Nov 2014 23:03:48 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415574227!11368015!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23848 invoked from network); 9 Nov 2014 23:03:47 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Nov 2014 23:03:47 -0000
Received: from jarvis.univie.ac.at ([131.130.3.112] helo=jarvis.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XnbWL-0001xx-PJ; Mon, 10 Nov 2014 00:03:45 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.68])
	by jarvis.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XnbWK-0000Te-UT; Mon, 10 Nov 2014 00:03:45 +0100
Message-ID: <545FF2D2.4020202@web2web.at>
Date: Mon, 10 Nov 2014 00:03:46 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>	
	<1414493998.10206.3.camel@citrix.com> <544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>
In-Reply-To: <1414512266.10974.5.camel@citrix.com>
Content-Type: multipart/mixed; boundary="------------060301040209050003050701"
X-Univie-Virus-Scan: scanned by ClamAV on jarvis.univie.ac.at
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] segfault in xl create for HVM with 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------060301040209050003050701
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Am 28.10.14 um 17:04 schrieb Ian Campbell:
> On Tue, 2014-10-28 at 16:39 +0100, Atom2 wrote:
>>> Please can you run the command under gdb and grab a back trace.
>>>

I have now re-compiled a few more pieces with debugging support, namely 
gcc-8.4.3 and glibc and again run the command
	xl create pfsense -c
under gdb. The new (full) backtrace output is attached to this mail and 
might provide you with some more clues.

BTW the same problem also seems to exist for xen-4.4.1/gcc-4.8.3 and was 
found independent of my report - please see further details and a 
discussion at http://forums.gentoo.org/viewtopic-t-1003746.html and the 
related bug report at https://bugs.gentoo.org/show_bug.cgi?id=528690.

Ian - if you (or anybody else) could add any more insight into this, it 
would be very much appreciated.

Thanks again Atom2

--------------060301040209050003050701
Content-Type: text/plain; charset=windows-1252;
 name="backtrace-xen-4.3.3-r1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="backtrace-xen-4.3.3-r1"

dm0taG9zdCBhdXRvIFs1MTJdICMgZ2RiIC0tYXJncyB4bCBjcmVhdGUgcGZzZW5zZSAtYwpH
TlUgZ2RiIChHZW50b28gNy43LjEgcDEpIDcuNy4xCkNvcHlyaWdodCAoQykgMjAxNCBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KTGljZW5zZSBHUEx2Mys6IEdOVSBHUEwgdmVy
c2lvbiAzIG9yIGxhdGVyIDxodHRwOi8vZ251Lm9yZy9saWNlbnNlcy9ncGwuaHRtbD4KVGhp
cyBpcyBmcmVlIHNvZnR3YXJlOiB5b3UgYXJlIGZyZWUgdG8gY2hhbmdlIGFuZCByZWRpc3Ry
aWJ1dGUgaXQuClRoZXJlIGlzIE5PIFdBUlJBTlRZLCB0byB0aGUgZXh0ZW50IHBlcm1pdHRl
ZCBieSBsYXcuICBUeXBlICJzaG93IGNvcHlpbmciCmFuZCAic2hvdyB3YXJyYW50eSIgZm9y
IGRldGFpbHMuClRoaXMgR0RCIHdhcyBjb25maWd1cmVkIGFzICJ4ODZfNjQtcGMtbGludXgt
Z251Ii4KVHlwZSAic2hvdyBjb25maWd1cmF0aW9uIiBmb3IgY29uZmlndXJhdGlvbiBkZXRh
aWxzLgpGb3IgYnVnIHJlcG9ydGluZyBpbnN0cnVjdGlvbnMsIHBsZWFzZSBzZWU6CjxodHRw
Oi8vYnVncy5nZW50b28ub3JnLz4uCkZpbmQgdGhlIEdEQiBtYW51YWwgYW5kIG90aGVyIGRv
Y3VtZW50YXRpb24gcmVzb3VyY2VzIG9ubGluZSBhdDoKPGh0dHA6Ly93d3cuZ251Lm9yZy9z
b2Z0d2FyZS9nZGIvZG9jdW1lbnRhdGlvbi8+LgpGb3IgaGVscCwgdHlwZSAiaGVscCIuClR5
cGUgImFwcm9wb3Mgd29yZCIgdG8gc2VhcmNoIGZvciBjb21tYW5kcyByZWxhdGVkIHRvICJ3
b3JkIi4uLgpSZWFkaW5nIHN5bWJvbHMgZnJvbSB4bC4uLlJlYWRpbmcgc3ltYm9scyBmcm9t
IC91c3IvbGliNjQvZGVidWcvL3Vzci9zYmluL3hsLmRlYnVnLi4uZG9uZS4KZG9uZS4KKGdk
YikgcnVuClN0YXJ0aW5nIHByb2dyYW06IC91c3Ivc2Jpbi94bCBjcmVhdGUgcGZzZW5zZSAt
Ywp3YXJuaW5nOiBDb3VsZCBub3QgbG9hZCBzaGFyZWQgbGlicmFyeSBzeW1ib2xzIGZvciBs
aW51eC12ZHNvLnNvLjEuCkRvIHlvdSBuZWVkICJzZXQgc29saWItc2VhcmNoLXBhdGgiIG9y
ICJzZXQgc3lzcm9vdCI/CltUaHJlYWQgZGVidWdnaW5nIHVzaW5nIGxpYnRocmVhZF9kYiBl
bmFibGVkXQpVc2luZyBob3N0IGxpYnRocmVhZF9kYiBsaWJyYXJ5ICIvbGliNjQvbGlidGhy
ZWFkX2RiLnNvLjEiLgpQYXJzaW5nIGNvbmZpZyBmcm9tIHBmc2Vuc2UKeGM6IGluZm86IFZJ
UlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgogIExvYWRlcjogICAgICAgIDAwMDAwMDAwMDAx
MDAwMDAtPjAwMDAwMDAwMDAxYzEwYzQKICBNb2R1bGVzOiAgICAgICAwMDAwMDAwMDAwMDAw
MDAwLT4wMDAwMDAwMDAwMDAwMDAwCiAgVE9UQUw6ICAgICAgICAgMDAwMDAwMDAwMDAwMDAw
MC0+MDAwMDAwMDAxZjgwMDAwMAogIEVOVFJZIEFERFJFU1M6IDAwMDAwMDAwMDAxMDAwMDAK
eGM6IGluZm86IFBIWVNJQ0FMIE1FTU9SWSBBTExPQ0FUSU9OOgogIDRLQiBQQUdFUzogMHgw
MDAwMDAwMDAwMDAwMjAwCiAgMk1CIFBBR0VTOiAweDAwMDAwMDAwMDAwMDAwZmIKICAxR0Ig
UEFHRVM6IDB4MDAwMDAwMDAwMDAwMDAwMApbTmV3IFRocmVhZCAweDdmZmZmN2ZmNTcwMCAo
TFdQIDI0ODkpXQpbTmV3IFRocmVhZCAweDdmZmZmN2ZlNjcwMCAoTFdQIDI2MDEpXQoKUHJv
Z3JhbSByZWNlaXZlZCBzaWduYWwgU0lHU0VHViwgU2VnbWVudGF0aW9uIGZhdWx0LgpbU3dp
dGNoaW5nIHRvIFRocmVhZCAweDdmZmZmN2ZlNjcwMCAoTFdQIDI2MDEpXQoweDAwMDA3ZmZm
ZjU4OTI2MjQgaW4gZXhlY3V0ZV9zdGFja19vcCAob3BfcHRyPTB4N2ZmZmY3MzI5YjgzICJ3
XDI0MFwwMDFcMDA2XDAyMFxiXDAwMncoXDAyMFx0XDAwMncwXDAyMFxuXDAwMnc4XDAyMFx2
XDAwM3dcMzAwIiwKICAgIG9wX2VuZD0weDdmZmZmNzMyOWI4NyAiXDAyMFxiXDAwMncoXDAy
MFx0XDAwMncwXDAyMFxuXDAwMnc4XDAyMFx2XDAwM3dcMzAwIiwgY29udGV4dD1jb250ZXh0
QGVudHJ5PTB4N2ZmZmY3ZmU1MTkwLAogICAgaW5pdGlhbD1pbml0aWFsQGVudHJ5PTApIGF0
IC92YXIvdG1wL3BvcnRhZ2Uvc3lzLWRldmVsL2djYy00LjguMy93b3JrL2djYy00LjguMy9s
aWJnY2MvdW53aW5kLWR3Mi5jOjUxNgo1MTYgICAgIC92YXIvdG1wL3BvcnRhZ2Uvc3lzLWRl
dmVsL2djYy00LjguMy93b3JrL2djYy00LjguMy9saWJnY2MvdW53aW5kLWR3Mi5jOiBObyBz
dWNoIGZpbGUgb3IgZGlyZWN0b3J5LgooZ2RiKSBidCBmdWxsCiMwICAweDAwMDA3ZmZmZjU4
OTI2MjQgaW4gZXhlY3V0ZV9zdGFja19vcCAoCiAgICBvcF9wdHI9MHg3ZmZmZjczMjliODMg
IndcMjQwXDAwMVwwMDZcMDIwXGJcMDAydyhcMDIwXHRcMDAydzBcMDIwXG5cMDAydzhcMDIw
XHZcMDAzd1wzMDAiLAogICAgb3BfZW5kPTB4N2ZmZmY3MzI5Yjg3ICJcMDIwXGJcMDAydyhc
MDIwXHRcMDAydzBcMDIwXG5cMDAydzhcMDIwXHZcMDAzd1wzMDAiLCBjb250ZXh0PWNvbnRl
eHRAZW50cnk9MHg3ZmZmZjdmZTUxOTAsCiAgICBpbml0aWFsPWluaXRpYWxAZW50cnk9MCkg
YXQgL3Zhci90bXAvcG9ydGFnZS9zeXMtZGV2ZWwvZ2NjLTQuOC4zL3dvcmsvZ2NjLTQuOC4z
L2xpYmdjYy91bndpbmQtZHcyLmM6NTE2CiAgICAgICAgc3RhY2sgPSB7MCA8cmVwZWF0cyA0
NCB0aW1lcz4sIDE0MDczNzM1NDAyNzE2OCwgMTQwNzM3MzEyODAzNzMxLCAxNDA3MzczNTQw
MjcxODQsIDE0MDczNzM1NDAyNzQ4OCwgMTQwNzM3MzQwNjYwNzMyLAogICAgICAgICAgMTQw
NzM3MzQwNjYzMDE2LCAxNDA3MzczNTQwMjczMTIsIDE0MDczNzMxMjgwODc0NywgMTQwNzM3
MzU0MDI3MzI4LCAxNDA3MzMxOTMzODgwMzUsIDE0MDczNzM0MDY2MzU2MCwgMzUyLCAxMCwg
MTY3LCAyMjAsCiAgICAgICAgICAwLCAwLCAwLCAwLCAxNDA3MzczNTQxMjk3MzZ9CiAgICAg
ICAgc3RhY2tfZWx0ID0gPG9wdGltaXplZCBvdXQ+CiMxICAweDAwMDA3ZmZmZjU4OTMwOGMg
aW4gdXdfdXBkYXRlX2NvbnRleHRfMSAoY29udGV4dD1jb250ZXh0QGVudHJ5PTB4N2ZmZmY3
ZmU1NWEwLCBmcz1mc0BlbnRyeT0weDdmZmZmN2ZlNTJmMCkKICAgIGF0IC92YXIvdG1wL3Bv
cnRhZ2Uvc3lzLWRldmVsL2djYy00LjguMy93b3JrL2djYy00LjguMy9saWJnY2MvdW53aW5k
LWR3Mi5jOjE0MjQKICAgICAgICBleHAgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBsZW4g
PSA8b3B0aW1pemVkIG91dD4KICAgICAgICBvcmlnX2NvbnRleHQgPSB7cmVnID0gezB4N2Zm
ZmY3ZmU1Njk4LCAweDdmZmZmN2ZlNTZhMCwgMHgwLCAweDdmZmZmN2ZlNTZhOCwgMHgwLCAw
eDAsIDB4N2ZmZmY3ZmU1NmYwLCAweDdmZmZmN2ZlNTE4MCwgMHgwLAogICAgICAgICAgICAw
eDAsIDB4MCwgMHgwLCAweDdmZmZmN2ZlNTZiMCwgMHg3ZmZmZjdmZTU2YjgsIDB4N2ZmZmY3
ZmU1NmMwLCAweDdmZmZmN2ZlNTZjOCwgMHg3ZmZmZjdmZTU2ZjgsIDB4MH0sCiAgICAgICAg
ICBjZmEgPSAweDdmZmZmN2ZlNTcwMCwgcmEgPSAweDdmZmZmNzMyMmUwMCA8X19yZXN0b3Jl
X3J0PiwgbHNkYSA9IDB4MCwgYmFzZXMgPSB7dGJhc2UgPSAweDAsIGRiYXNlID0gMHgwLAog
ICAgICAgICAgICBmdW5jID0gMHg3ZmZmZjczMjJkZmZ9LCBmbGFncyA9IDQ2MTE2ODYwMTg0
MjczODc5MDQsIHZlcnNpb24gPSAwLCBhcmdzX3NpemUgPSAwLCBieV92YWx1ZSA9ICdcMDAw
JyA8cmVwZWF0cyAxNyB0aW1lcz59CiAgICAgICAgY2ZhID0gPG9wdGltaXplZCBvdXQ+CiAg
ICAgICAgaSA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIHRtcF9zcCA9IHtwdHIgPSAxNDA3
MzczNTQwMjg4MDAsIHdvcmQgPSAxNDA3MzczNTQwMjg4MDB9CiMyICAweDAwMDA3ZmZmZjU4
OTM0MDUgaW4gdXdfdXBkYXRlX2NvbnRleHQgKGNvbnRleHQ9Y29udGV4dEBlbnRyeT0weDdm
ZmZmN2ZlNTVhMCwgZnM9ZnNAZW50cnk9MHg3ZmZmZjdmZTUyZjApCiAgICBhdCAvdmFyL3Rt
cC9wb3J0YWdlL3N5cy1kZXZlbC9nY2MtNC44LjMvd29yay9nY2MtNC44LjMvbGliZ2NjL3Vu
d2luZC1kdzIuYzoxNTA2Ck5vIGxvY2Fscy4KIzMgIDB4MDAwMDdmZmZmNTg5NDA4NiBpbiB1
d19hZHZhbmNlX2NvbnRleHQgKGZzPTB4N2ZmZmY3ZmU1MmYwLCBjb250ZXh0PTB4N2ZmZmY3
ZmU1NWEwKQogICAgYXQgL3Zhci90bXAvcG9ydGFnZS9zeXMtZGV2ZWwvZ2NjLTQuOC4zL3dv
cmsvZ2NjLTQuOC4zL2xpYmdjYy91bndpbmQtZHcyLmM6MTUyOQpObyBsb2NhbHMuCiM0ICBf
VW53aW5kX0ZvcmNlZFVud2luZF9QaGFzZTIgKGV4Yz1leGNAZW50cnk9MHg3ZmZmZjdmZTZk
NzAsIGNvbnRleHQ9Y29udGV4dEBlbnRyeT0weDdmZmZmN2ZlNTVhMCkKICAgIGF0IC92YXIv
dG1wL3BvcnRhZ2Uvc3lzLWRldmVsL2djYy00LjguMy93b3JrL2djYy00LjguMy9saWJnY2Mv
dW53aW5kLmluYzoxODUKICAgICAgICBmcyA9IHtyZWdzID0ge3JlZyA9IHt7bG9jID0ge3Jl
ZyA9IDE0MDczNzM0MDY3NzA3Niwgb2Zmc2V0ID0gMTQwNzM3MzQwNjc3MDc2LAogICAgICAg
ICAgICAgICAgICBleHAgPSAweDdmZmZmNzMyOWJkNCAiXDAwM3dcMjIwXDAwMVwwMjBcMDAy
XDAwM3dcMjMwXDAwMVwwMjBcYVwwMDN3XDI0MFwwMDFcMDIwXDAyMFwwMDN3XDI1MFwwMDEi
fSwKICAgICAgICAgICAgICAgIGhvdyA9IFJFR19TQVZFRF9FWFB9LCB7bG9jID0ge3JlZyA9
IDE0MDczNzM0MDY3NzA3MCwgb2Zmc2V0ID0gMTQwNzM3MzQwNjc3MDcwLAogICAgICAgICAg
ICAgICAgICBleHAgPSAweDdmZmZmNzMyOWJjZSAiXDAwM3dcMjEwXDAwMVwwMjAifSwgaG93
ID0gUkVHX1NBVkVEX0VYUH0sIHtsb2MgPSB7cmVnID0gMTQwNzM3MzQwNjc3MDgyLAogICAg
ICAgICAgICAgICAgICBvZmZzZXQgPSAxNDA3MzczNDA2NzcwODIsIGV4cCA9IDB4N2ZmZmY3
MzI5YmRhICJcMDAzd1wyMzBcMDAxXDAyMFxhXDAwM3dcMjQwXDAwMVwwMjBcMDIwXDAwM3dc
MjUwXDAwMSJ9LAogICAgICAgICAgICAgICAgaG93ID0gUkVHX1NBVkVEX0VYUH0sIHtsb2Mg
PSB7cmVnID0gMTQwNzM3MzQwNjc3MDY0LCBvZmZzZXQgPSAxNDA3MzczNDA2NzcwNjQsCiAg
ICAgICAgICAgICAgICAgIGV4cCA9IDB4N2ZmZmY3MzI5YmM4ICJcMDAzd1wyMDBcMDAxXDAy
MFwwMDFcMDAzd1wyMTBcMDAxXDAyMCJ9LCBob3cgPSBSRUdfU0FWRURfRVhQfSwge2xvYyA9
IHsKICAgICAgICAgICAgICAgICAgcmVnID0gMTQwNzM3MzQwNjc3MDUyLCBvZmZzZXQgPSAx
NDA3MzczNDA2NzcwNTIsIGV4cCA9IDB4N2ZmZmY3MzI5YmJjICJcMDAzIiwgPGluY29tcGxl
dGUgc2VxdWVuY2UgXDM2MD59LAogICAgICAgICAgICAgICAgaG93ID0gUkVHX1NBVkVEX0VY
UH0sIHtsb2MgPSB7cmVnID0gMTQwNzM3MzQwNjc3MDQ2LCBvZmZzZXQgPSAxNDA3MzczNDA2
NzcwNDYsCiAgICAgICAgICAgICAgICAgIGV4cCA9IDB4N2ZmZmY3MzI5YmI2ICJcMDAzIiwg
PGluY29tcGxldGUgc2VxdWVuY2UgXDM1MD59LCBob3cgPSBSRUdfU0FWRURfRVhQfSwge2xv
YyA9IHtyZWcgPSAxNDA3MzczNDA2NzcwNTgsCiAgICAgICAgICAgICAgICAgIG9mZnNldCA9
IDE0MDczNzM0MDY3NzA1OCwgZXhwID0gMHg3ZmZmZjczMjliYzIgIlwwMDMiLCA8aW5jb21w
bGV0ZSBzZXF1ZW5jZSBcMzcwPn0sIGhvdyA9IFJFR19TQVZFRF9FWFB9LCB7CiAgICAgICAg
ICAgICAgICBsb2MgPSB7cmVnID0gMTQwNzM3MzQwNjc3MDg4LCBvZmZzZXQgPSAxNDA3Mzcz
NDA2NzcwODgsCiAgICAgICAgICAgICAgICAgIGV4cCA9IDB4N2ZmZmY3MzI5YmUwICJcMDAz
d1wyNDBcMDAxXDAyMFwwMjBcMDAzd1wyNTBcMDAxIn0sIGhvdyA9IFJFR19TQVZFRF9FWFB9
LCB7bG9jID0ge3JlZyA9IDE0MDczNzM0MDY3NzAwMSwKICAgICAgICAgICAgICAgICAgb2Zm
c2V0ID0gMTQwNzM3MzQwNjc3MDAxLCBleHAgPSAweDdmZmZmNzMyOWI4OSAiXDAwMncoXDAy
MFx0XDAwMncwXDAyMFxuXDAwMnc4XDAyMFx2XDAwM3dcMzAwIn0sCiAgICAgICAgICAgICAg
ICBob3cgPSBSRUdfU0FWRURfRVhQfSwge2xvYyA9IHtyZWcgPSAxNDA3MzczNDA2NzcwMDYs
IG9mZnNldCA9IDE0MDczNzM0MDY3NzAwNiwKICAgICAgICAgICAgICAgICAgZXhwID0gMHg3
ZmZmZjczMjliOGUgIlwwMDJ3MFwwMjBcblwwMDJ3OFwwMjBcdlwwMDN3XDMwMCJ9LCBob3cg
PSBSRUdfU0FWRURfRVhQfSwge2xvYyA9IHtyZWcgPSAxNDA3MzczNDA2NzcwMTEsCiAgICAg
ICAgICAgICAgICAgIG9mZnNldCA9IDE0MDczNzM0MDY3NzAxMSwgZXhwID0gMHg3ZmZmZjcz
MjliOTMgIlwwMDJ3OFwwMjBcdlwwMDN3XDMwMCJ9LCBob3cgPSBSRUdfU0FWRURfRVhQfSwg
e2xvYyA9IHsKICAgICAgICAgICAgICAgICAgcmVnID0gMTQwNzM3MzQwNjc3MDE2LCBvZmZz
ZXQgPSAxNDA3MzczNDA2NzcwMTYsIGV4cCA9IDB4N2ZmZmY3MzI5Yjk4ICJcMDAzd1wzMDAi
fSwgaG93ID0gUkVHX1NBVkVEX0VYUH0sIHsKICAgICAgICAgICAgICAgIGxvYyA9IHtyZWcg
PSAxNDA3MzczNDA2NzcwMjIsIG9mZnNldCA9IDE0MDczNzM0MDY3NzAyMiwgZXhwID0gMHg3
ZmZmZjczMjliOWUgIlwwMDMiLCA8aW5jb21wbGV0ZSBzZXF1ZW5jZSBcMzEwPn0sCiAgICAg
ICAgICAgICAgICBob3cgPSBSRUdfU0FWRURfRVhQfSwge2xvYyA9IHtyZWcgPSAxNDA3Mzcz
NDA2NzcwMjgsIG9mZnNldCA9IDE0MDczNzM0MDY3NzAyOCwKICAgICAgICAgICAgICAgICAg
ZXhwID0gMHg3ZmZmZjczMjliYTQgIlwwMDMiLCA8aW5jb21wbGV0ZSBzZXF1ZW5jZSBcMzIw
Pn0sIGhvdyA9IFJFR19TQVZFRF9FWFB9LCB7bG9jID0ge3JlZyA9IDE0MDczNzM0MDY3NzAz
NCwKICAgICAgICAgICAgICAgICAgb2Zmc2V0ID0gMTQwNzM3MzQwNjc3MDM0LCBleHAgPSAw
eDdmZmZmNzMyOWJhYSAiXDAwMyIsIDxpbmNvbXBsZXRlIHNlcXVlbmNlIFwzMzA+fSwgaG93
ID0gUkVHX1NBVkVEX0VYUH0sIHsKICAgICAgICAgICAgICAgIGxvYyA9IHtyZWcgPSAxNDA3
MzczNDA2NzcwNDAsIG9mZnNldCA9IDE0MDczNzM0MDY3NzA0MCwgZXhwID0gMHg3ZmZmZjcz
MjliYjAgIlwwMDMiLCA8aW5jb21wbGV0ZSBzZXF1ZW5jZSBcMzQwPn0sCiAgICAgICAgICAg
ICAgICBob3cgPSBSRUdfU0FWRURfRVhQfSwge2xvYyA9IHtyZWcgPSAxNDA3MzczNDA2Nzcw
OTQsIG9mZnNldCA9IDE0MDczNzM0MDY3NzA5NCwKICAgICAgICAgICAgICAgICAgZXhwID0g
MHg3ZmZmZjczMjliZTYgIlwwMDN3XDI1MFwwMDEifSwgaG93ID0gUkVHX1NBVkVEX0VYUH0s
IHtsb2MgPSB7cmVnID0gMCwgb2Zmc2V0ID0gMCwgZXhwID0gMHgwfSwKICAgICAgICAgICAg
ICAgIGhvdyA9IFJFR19VTlNBVkVEfX0sIHByZXYgPSAweDAsIGNmYV9vZmZzZXQgPSAwLCBj
ZmFfcmVnID0gMCwKICAgICAgICAgICAgY2ZhX2V4cCA9IDB4N2ZmZmY3MzI5YjgyICJcMDA0
d1wyNDBcMDAxXDAwNlwwMjBcYlwwMDJ3KFwwMjBcdFwwMDJ3MFwwMjBcblwwMDJ3OFwwMjBc
dlwwMDN3XDMwMCIsIGNmYV9ob3cgPSBDRkFfRVhQfSwKICAgICAgICAgIHBjID0gMHg3ZmZm
ZjczMjJkZmYsIHBlcnNvbmFsaXR5ID0gMHgwLCBkYXRhX2FsaWduID0gLTgsIGNvZGVfYWxp
Z24gPSAxLCByZXRhZGRyX2NvbHVtbiA9IDE2LCBmZGVfZW5jb2RpbmcgPSAyNyAnXDAzMycs
CiAgICAgICAgICBsc2RhX2VuY29kaW5nID0gMjU1ICdcMzc3Jywgc2F3X3ogPSAxICdcMDAx
Jywgc2lnbmFsX2ZyYW1lID0gMSAnXDAwMScsIGVoX3B0ciA9IDB4MH0KICAgICAgICBhY3Rp
b24gPSAxMAogICAgICAgIHN0b3AgPSAweDdmZmZmNzMyMTVlMCA8dW53aW5kX3N0b3A+CiAg
ICAgICAgc3RvcF9hcmd1bWVudCA9IDB4N2ZmZmY3ZmU1ZDMwCiAgICAgICAgY29kZSA9IDxv
cHRpbWl6ZWQgb3V0PgogICAgICAgIHN0b3BfY29kZSA9IDxvcHRpbWl6ZWQgb3V0PgojNSAg
MHgwMDAwN2ZmZmY1ODk0NDBjIGluIF9VbndpbmRfRm9yY2VkVW53aW5kIChleGM9MHg3ZmZm
ZjdmZTZkNzAsIHN0b3A9c3RvcEBlbnRyeT0weDdmZmZmNzMyMTVlMCA8dW53aW5kX3N0b3A+
LAogICAgc3RvcF9hcmd1bWVudD0weDdmZmZmN2ZlNWQzMCkgYXQgL3Zhci90bXAvcG9ydGFn
ZS9zeXMtZGV2ZWwvZ2NjLTQuOC4zL3dvcmsvZ2NjLTQuOC4zL2xpYmdjYy91bndpbmQuaW5j
OjIwNwogICAgICAgIHRoaXNfY29udGV4dCA9IHtyZWcgPSB7MHg3ZmZmZjdmZTU2OTgsIDB4
N2ZmZmY3ZmU1NmEwLCAweDAsIDB4N2ZmZmY3ZmU1NmE4LCAweDAsIDB4MCwgMHg3ZmZmZjdm
ZTU2ZDAsIDB4MCwgMHgwLCAweDAsIDB4MCwKICAgICAgICAgICAgMHgwLCAweDdmZmZmN2Zl
NTZiMCwgMHg3ZmZmZjdmZTU2YjgsIDB4N2ZmZmY3ZmU1NmMwLCAweDdmZmZmN2ZlNTZjOCwg
MHg3ZmZmZjdmZTU2ZDgsIDB4MH0sIGNmYSA9IDB4N2ZmZmY3ZmU1NmUwLAogICAgICAgICAg
cmEgPSAweDdmZmZmNzMyMTc3MyA8X19HSV9fX3B0aHJlYWRfdW53aW5kKzgzPiwgbHNkYSA9
IDB4MCwgYmFzZXMgPSB7dGJhc2UgPSAweDAsIGRiYXNlID0gMHgwLAogICAgICAgICAgICBm
dW5jID0gMHg3ZmZmZjU4OTQzYTAgPF9VbndpbmRfRm9yY2VkVW53aW5kPn0sIGZsYWdzID0g
NDYxMTY4NjAxODQyNzM4NzkwNCwgdmVyc2lvbiA9IDAsIGFyZ3Nfc2l6ZSA9IDAsCiAgICAg
ICAgICBieV92YWx1ZSA9ICdcMDAwJyA8cmVwZWF0cyAxNyB0aW1lcz59CiAgICAgICAgY3Vy
X2NvbnRleHQgPSB7cmVnID0gezB4N2ZmZmY3ZmU1Njk4LCAweDdmZmZmN2ZlNTZhMCwgMHgw
LCAweDdmZmZmN2ZlNTZhOCwgMHgwLCAweDAsIDB4N2ZmZmY3ZmU1NmYwLCAweDAsIDB4MCwg
MHgwLCAweDAsCiAgICAgICAgICAgIDB4MCwgMHg3ZmZmZjdmZTU2YjAsIDB4N2ZmZmY3ZmU1
NmI4LCAweDdmZmZmN2ZlNTZjMCwgMHg3ZmZmZjdmZTU2YzgsIDB4N2ZmZmY3ZmU1NmY4LCAw
eDB9LCBjZmEgPSAweDdmZmZmN2ZlNTcwMCwKICAgICAgICAgIHJhID0gMHg3ZmZmZjczMjJl
MDAgPF9fcmVzdG9yZV9ydD4sIGxzZGEgPSAweDAsIGJhc2VzID0ge3RiYXNlID0gMHgwLCBk
YmFzZSA9IDB4MCwgZnVuYyA9IDB4N2ZmZmY3MzIyZGZmfSwKICAgICAgICAgIGZsYWdzID0g
NDYxMTY4NjAxODQyNzM4NzkwNCwgdmVyc2lvbiA9IDAsIGFyZ3Nfc2l6ZSA9IDAsIGJ5X3Zh
bHVlID0gJ1wwMDAnIDxyZXBlYXRzIDE3IHRpbWVzPn0KICAgICAgICBjb2RlID0gPG9wdGlt
aXplZCBvdXQ+CiM2ICAweDAwMDA3ZmZmZjczMjE3NzMgaW4gX19HSV9fX3B0aHJlYWRfdW53
aW5kIChidWY9PG9wdGltaXplZCBvdXQ+KSBhdCB1bndpbmQuYzoxMjkKICAgICAgICBpYnVm
ID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgc2VsZiA9IDxvcHRpbWl6ZWQgb3V0PgojNyAg
MHgwMDAwN2ZmZmY3MzE4Yjg5IGluIF9fZG9fY2FuY2VsICgpIGF0IC4uL25wdGwvcHRocmVh
ZFAuaDoyODAKTm8gbG9jYWxzLgojOCAgc2lnY2FuY2VsX2hhbmRsZXIgKHNpZz08b3B0aW1p
emVkIG91dD4sIHNpPTxvcHRpbWl6ZWQgb3V0PiwgY3R4PTxvcHRpbWl6ZWQgb3V0PikgYXQg
bnB0bC1pbml0LmM6MjE0CiAgICAgICAgc2kgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBj
dHggPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBwaWQgPSA8b3B0aW1pemVkIG91dD4KICAg
ICAgICBvbGR2YWwgPSA8b3B0aW1pemVkIG91dD4KIzkgIDxzaWduYWwgaGFuZGxlciBjYWxs
ZWQ+Ck5vIGxvY2Fscy4KIzEwIDB4MDAwMDdmZmZmNzMyMWU4ZCBpbiByZWFkICgpIGF0IC4u
L3N5c2RlcHMvdW5peC9zeXNjYWxsLXRlbXBsYXRlLlM6ODEKTm8gbG9jYWxzLgojMTEgMHgw
MDAwN2ZmZmY2YjI0N2MzIGluIHJlYWQgKF9fbmJ5dGVzPTE2LCBfX2J1Zj0weDdmZmZlODAw
MDhkMCwgX19mZD0xNCkgYXQgL3Vzci9pbmNsdWRlL2JpdHMvdW5pc3RkLmg6NDQKTm8gbG9j
YWxzLgojMTIgcmVhZF9hbGwgKGZkPTE0LCBkYXRhPWRhdGFAZW50cnk9MHg3ZmZmZTgwMDA4
ZDAsIGxlbj1sZW5AZW50cnk9MTYsIG5vbmJsb2NraW5nPW5vbmJsb2NraW5nQGVudHJ5PTAp
IGF0IHhzLmM6Mzc0CiAgICAgICAgZG9uZSA9IDxvcHRpbWl6ZWQgb3V0PgojMTMgMHgwMDAw
N2ZmZmY2YjI0OTA0IGluIHJlYWRfbWVzc2FnZSAoaD1oQGVudHJ5PTB4NTU1NTU1Nzg0Mjgw
LCBub25ibG9ja2luZz1ub25ibG9ja2luZ0BlbnRyeT0wKSBhdCB4cy5jOjExMzkKICAgICAg
ICBfX2NhbmNlbF9idWYgPSB7X19jYW5jZWxfam1wX2J1ZiA9IHt7X19jYW5jZWxfam1wX2J1
ZiA9IHs5MzgyNDk5NDUyNTgyNCwgMTI4MjY0MzI0NTkwNjAwNzg1MSwgMSwgMTQwNzM3NDg4
MzQxMTIwLAogICAgICAgICAgICAgICAgOTM4MjQ5OTQ1MjQwNjQsIDE0MDczNzM1NDAzMjg5
NiwgMTI4MjY0MzI0NTg1Nzc3MzM1NSwgMTI4MjY0NTg5MjIwNjY5NjIzNX0sIF9fbWFza193
YXNfc2F2ZWQgPSAwfX0sIF9fcGFkID0gewogICAgICAgICAgICAweDdmZmZmN2ZlNWVlMCwg
MHgwLCAweDAsIDB4MH19CiAgICAgICAgX19jYW5jZWxfYXJnID0gMHg3ZmZmZTgwMDA4YzAK
ICAgICAgICBfX25vdF9maXJzdF9jYWxsID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgbXNn
ID0gMHg3ZmZmZTgwMDA4YzAKICAgICAgICBib2R5ID0gMHgwCiAgICAgICAgc2F2ZWRfZXJy
bm8gPSAwCiAgICAgICAgcmV0ID0gLTEKIzE0IDB4MDAwMDdmZmZmNmIyNTI5NiBpbiByZWFk
X3RocmVhZCAoYXJnPTB4NTU1NTU1Nzg0MjgwKSBhdCB4cy5jOjEyMTEKICAgICAgICBoID0g
MHg1NTU1NTU3ODQyODAKICAgICAgICBmZCA9IDxvcHRpbWl6ZWQgb3V0PgojMTUgMHgwMDAw
N2ZmZmY3MzFhMzZkIGluIHN0YXJ0X3RocmVhZCAoYXJnPTB4N2ZmZmY3ZmU2NzAwKSBhdCBw
dGhyZWFkX2NyZWF0ZS5jOjMwOQogICAgICAgIF9fcmVzID0gPG9wdGltaXplZCBvdXQ+CiAg
ICAgICAgcGQgPSAweDdmZmZmN2ZlNjcwMAogICAgICAgIG5vdyA9IDxvcHRpbWl6ZWQgb3V0
PgogICAgICAgIHVud2luZF9idWYgPSB7Y2FuY2VsX2ptcF9idWYgPSB7e2ptcF9idWYgPSB7
MTQwNzM3MzU0MDMyODk2LCAxMjgyNjQzMjQ1OTEwMjAyMTU1LCAxLCAxNDA3Mzc0ODgzNDEx
MjAsIDkzODI0OTk0NTI0MDY0LAogICAgICAgICAgICAgICAgMTQwNzM3MzU0MDMyODk2LCAx
MjgyNjQzMjQ1ODk3NjE5MjQzLCAxMjgyNjQyNTg4NjU0NjM4ODkxfSwgbWFza193YXNfc2F2
ZWQgPSAwfX0sIHByaXYgPSB7cGFkID0gezB4MCwgMHgwLCAweDAsCiAgICAgICAgICAgICAg
MHgwfSwgZGF0YSA9IHtwcmV2ID0gMHgwLCBjbGVhbnVwID0gMHgwLCBjYW5jZWx0eXBlID0g
MH19fQogICAgICAgIG5vdF9maXJzdF9jYWxsID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAg
cm9idXN0ID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgcGFnZXNpemVfbTEgPSA8b3B0aW1p
emVkIG91dD4KICAgICAgICBzcCA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIGZyZWVzaXpl
ID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgX19QUkVUVFlfRlVOQ1RJT05fXyA9ICJzdGFy
dF90aHJlYWQiCiMxNiAweDAwMDA3ZmZmZjcwNTJlMGQgaW4gY2xvbmUgKCkgYXQgLi4vc3lz
ZGVwcy91bml4L3N5c3YvbGludXgveDg2XzY0L2Nsb25lLlM6MTExCk5vIGxvY2Fscy4KKGdk
YikK
--------------060301040209050003050701
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060301040209050003050701--


From xen-devel-bounces@lists.xen.org Mon Nov 10 01:36:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 01:36:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XndtD-0006mZ-55; Mon, 10 Nov 2014 01:35: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@citrix.com>) id 1XndtC-0006mU-2e
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 01:35:30 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	4F/11-24124-06610645; Mon, 10 Nov 2014 01:35:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415583326!6117174!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 941 invoked from network); 10 Nov 2014 01:35:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 01:35:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,349,1413244800"; d="scan'208";a="191057269"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 9 Nov 2014 20:35:24 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xndt6-0002fa-Bu;
	Mon, 10 Nov 2014 01:35:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xndt5-0001m4-U2;
	Mon, 10 Nov 2014 01:35:24 +0000
Date: Mon, 10 Nov 2014 01:35:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31452-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31452: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31452 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31452/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 10 01:36:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 01:36:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XndtD-0006mZ-55; Mon, 10 Nov 2014 01:35: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@citrix.com>) id 1XndtC-0006mU-2e
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 01:35:30 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	4F/11-24124-06610645; Mon, 10 Nov 2014 01:35:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415583326!6117174!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 941 invoked from network); 10 Nov 2014 01:35:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 01:35:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,349,1413244800"; d="scan'208";a="191057269"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 9 Nov 2014 20:35:24 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xndt6-0002fa-Bu;
	Mon, 10 Nov 2014 01:35:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xndt5-0001m4-U2;
	Mon, 10 Nov 2014 01:35:24 +0000
Date: Mon, 10 Nov 2014 01:35:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31452-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31452: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31452 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31452/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 10 01:45:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 01: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.xen.org>)
	id 1Xne2w-0006xN-Ho; Mon, 10 Nov 2014 01:45:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@roeck-us.net>) id 1Xne2u-0006xI-UI
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 01:45:33 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	99/70-02712-CB810645; Mon, 10 Nov 2014 01:45:32 +0000
X-Env-Sender: linux@roeck-us.net
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415583929!12346336!1
X-Originating-IP: [208.91.199.152]
X-SpamReason: No, hits=2.7 required=7.0 tests=BODY_RANDOM_LONG,
	SUSPICIOUS_RECIPS,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3999 invoked from network); 10 Nov 2014 01:45:30 -0000
Received: from bh-25.webhostbox.net (HELO bh-25.webhostbox.net)
	(208.91.199.152)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 01:45:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roeck-us.net;
	s=default; 
	h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=cHZZ9ehbHT9KuRkSB6KpCsrzlzh5bGiaCmG8fTZy42s=; 
	b=J6+AbJ2EFT1hVcHFlJgpy7IprT2xo6+ep0hs65MceTtTCYhjVCBIbsPyiExAMJE8r396XV84a/hBckUsy18zDMRDH9sFBx8V36Nvr9sBqf6OSC8VS53qEY+gCIUhgBULiOAleJQvAtWyu9WzsQu7wr4HY5pIyxkLpQBqQQnZ9o0=;
Received: from mailnull by bh-25.webhostbox.net with sa-checked (Exim 4.82)
	(envelope-from <linux@roeck-us.net>) id 1Xne2q-000XmS-Ln
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 01:45:28 +0000
Received: from 108-223-40-66.lightspeed.sntcca.sbcglobal.net
	([108.223.40.66]:36296 helo=localhost)
	by bh-25.webhostbox.net with esmtpa (Exim 4.82)
	(envelope-from <linux@roeck-us.net>)
	id 1Xne15-000TzJ-AY; Mon, 10 Nov 2014 01:43:41 +0000
From: Guenter Roeck <linux@roeck-us.net>
To: linux-kernel@vger.kernel.org
Date: Sun,  9 Nov 2014 17:42:25 -0800
Message-Id: <1415583785-6980-9-git-send-email-linux@roeck-us.net>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415583785-6980-1-git-send-email-linux@roeck-us.net>
References: <1415583785-6980-1-git-send-email-linux@roeck-us.net>
X-Authenticated_sender: guenter@roeck-us.net
X-OutGoing-Spam-Status: No, score=2.5
X-Spam-Checker-Version: spamc_ctasd client on
	localost
X-Spam-Level: *
X-Spam-Status: No, score=2.0 required=50.0 tests=SpamClass_Suspect,
	VirusClass_Unknown autolearn=disabled version=1.0.0
X-CTCH-PVer: 0000001
X-CTCH-Spam: Suspect
X-CTCH-VOD: Unknown
X-CTCH-Flags: 512
X-CTCH-RefID: str=0001.0A02020A.546018B8.0148, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=512, sb=0
X-CTCH-Score: 0.000
X-CTCH-ScoreCust: 0.000
X-CTCH-Rules: 
X-CTCH-SenderID: linux@roeck-us.net
X-CTCH-SenderID-Flags: 0
X-CTCH-SenderID-TotalMessages: 292
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 2
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-TotalRecipients: 0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - lists.xenproject.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from
	get_relayhosts_entry
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
	linux-sh@vger.kernel.org, linux@lists.openrisc.net,
	sparclinux@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-am33-list@redhat.com, linux-c6x-dev@linux-c6x.org,
	linux-hexagon@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xenproject.org, Guenter Roeck <linux@roeck-us.net>,
	linux-xtensa@linux-xtensa.org, user-mode-linux-devel@lists.sourceforge.net,
	linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net,
	linux-m68k@lists.linux-m68k.org,
	user-mode-linux-user@lists.sourceforge.net, linux-metag@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
	linux-alpha@vger.kernel.org, linux390@de.ibm.com,
	linuxppc-dev@lists.ozlabs.org
Subject: [Xen-devel] [PATCH v6 08/48] kernel: Move pm_power_off to common
	code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pm_power_off is defined for all architectures. Move it to common code.

Have all architectures call do_kernel_power_off instead of pm_power_off.
Some architectures point pm_power_off to machine_power_off. For those,
call do_kernel_power_off from machine_power_off instead.

Acked-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Hirokazu Takata <takata@linux-m32r.org>
Acked-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
Acked-by: Richard Weinberger <richard@nod.at>
Acked-by: Xuetao Guan <gxt@mprc.pku.edu.cn>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v6:
- No change.
v5:
- Rebase to v3.18-rc3
- Update powerpc code to reflect merged power-off handler changes
v4:
- No change
v3:
- Replace poweroff in all newly introduced variables and in text
  with power_off or power-off as appropriate
v2:
- do_kernel_poweroff -> do_kernel_power_off
- have_kernel_poweroff -> have_kernel_power_off

 arch/alpha/kernel/process.c        |  9 +++------
 arch/arc/kernel/reset.c            |  5 +----
 arch/arm/kernel/process.c          |  5 +----
 arch/arm64/kernel/process.c        |  5 +----
 arch/avr32/kernel/process.c        |  6 +-----
 arch/blackfin/kernel/process.c     |  3 ---
 arch/blackfin/kernel/reboot.c      |  2 ++
 arch/c6x/kernel/process.c          |  9 +--------
 arch/cris/kernel/process.c         |  4 +---
 arch/frv/kernel/process.c          |  5 ++---
 arch/hexagon/kernel/reset.c        |  5 ++---
 arch/ia64/kernel/process.c         |  5 +----
 arch/m32r/kernel/process.c         |  8 ++++----
 arch/m68k/kernel/process.c         |  6 +-----
 arch/metag/kernel/process.c        |  6 +-----
 arch/microblaze/kernel/process.c   |  3 ---
 arch/microblaze/kernel/reset.c     |  1 +
 arch/mips/kernel/reset.c           |  6 +-----
 arch/mn10300/kernel/process.c      |  8 ++------
 arch/openrisc/kernel/process.c     |  8 +++++---
 arch/parisc/kernel/process.c       |  8 ++++----
 arch/powerpc/kernel/setup-common.c |  6 +-----
 arch/powerpc/xmon/xmon.c           |  3 +--
 arch/s390/kernel/setup.c           |  8 ++------
 arch/score/kernel/process.c        |  8 ++++----
 arch/sh/kernel/reboot.c            |  6 +-----
 arch/sparc/kernel/process_32.c     | 10 ++--------
 arch/sparc/kernel/reboot.c         |  8 ++------
 arch/tile/kernel/reboot.c          |  7 +++----
 arch/um/kernel/reboot.c            |  2 --
 arch/unicore32/kernel/process.c    |  9 +--------
 arch/x86/kernel/reboot.c           | 11 +++--------
 arch/x86/xen/enlighten.c           |  3 +--
 arch/xtensa/kernel/process.c       |  4 ----
 drivers/parisc/power.c             |  3 +--
 kernel/power/power_off_handler.c   |  9 +++++++++
 kernel/reboot.c                    |  4 ++--
 37 files changed, 68 insertions(+), 150 deletions(-)

diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 1941a07..81c43f8 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -24,6 +24,7 @@
 #include <linux/vt.h>
 #include <linux/mman.h>
 #include <linux/elfcore.h>
+#include <linux/pm.h>
 #include <linux/reboot.h>
 #include <linux/tty.h>
 #include <linux/console.h>
@@ -40,12 +41,6 @@
 #include "proto.h"
 #include "pci_impl.h"
 
-/*
- * Power off function, if any
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 #ifdef CONFIG_ALPHA_WTINT
 /*
  * Sleep the CPU.
@@ -184,6 +179,8 @@ machine_halt(void)
 void
 machine_power_off(void)
 {
+	do_kernel_power_off();
+
 	common_shutdown(LINUX_REBOOT_CMD_POWER_OFF, NULL);
 }
 
diff --git a/arch/arc/kernel/reset.c b/arch/arc/kernel/reset.c
index 2768fa1..0758d9d 100644
--- a/arch/arc/kernel/reset.c
+++ b/arch/arc/kernel/reset.c
@@ -26,9 +26,6 @@ void machine_restart(char *__unused)
 
 void machine_power_off(void)
 {
-	/* FIXME ::  power off ??? */
+	do_kernel_power_off();
 	machine_halt();
 }
-
-void (*pm_power_off) (void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index fe972a2..aa3f656 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -117,8 +117,6 @@ void soft_restart(unsigned long addr)
 /*
  * Function pointers to optional machine specific functions
  */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 
@@ -205,8 +203,7 @@ void machine_power_off(void)
 	local_irq_disable();
 	smp_send_stop();
 
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index fde9923..6f623a0 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -68,8 +68,6 @@ void soft_restart(unsigned long addr)
 /*
  * Function pointers to optional machine specific functions
  */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL_GPL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 
@@ -129,8 +127,7 @@ void machine_power_off(void)
 {
 	local_irq_disable();
 	smp_send_stop();
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/avr32/kernel/process.c b/arch/avr32/kernel/process.c
index 42a53e74..529c1f6 100644
--- a/arch/avr32/kernel/process.c
+++ b/arch/avr32/kernel/process.c
@@ -23,9 +23,6 @@
 
 #include <mach/pm.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * This file handles the architecture-dependent parts of process handling..
  */
@@ -48,8 +45,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 void machine_restart(char *cmd)
diff --git a/arch/blackfin/kernel/process.c b/arch/blackfin/kernel/process.c
index 4aa5545..812dd83 100644
--- a/arch/blackfin/kernel/process.c
+++ b/arch/blackfin/kernel/process.c
@@ -39,9 +39,6 @@ int nr_l1stack_tasks;
 void *l1_stack_base;
 unsigned long l1_stack_len;
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * The idle loop on BFIN
  */
diff --git a/arch/blackfin/kernel/reboot.c b/arch/blackfin/kernel/reboot.c
index c4f50a3..387d610 100644
--- a/arch/blackfin/kernel/reboot.c
+++ b/arch/blackfin/kernel/reboot.c
@@ -7,6 +7,7 @@
  */
 
 #include <linux/interrupt.h>
+#include <linux/pm.h>
 #include <asm/bfin-global.h>
 #include <asm/reboot.h>
 #include <asm/bfrom.h>
@@ -106,6 +107,7 @@ void machine_halt(void)
 __attribute__((weak))
 void native_machine_power_off(void)
 {
+	do_kernel_power_off();
 	idle_with_irq_disabled();
 }
 
diff --git a/arch/c6x/kernel/process.c b/arch/c6x/kernel/process.c
index 57d2ea8..edf7e5a 100644
--- a/arch/c6x/kernel/process.c
+++ b/arch/c6x/kernel/process.c
@@ -27,12 +27,6 @@ void	(*c6x_halt)(void);
 extern asmlinkage void ret_from_fork(void);
 extern asmlinkage void ret_from_kernel_thread(void);
 
-/*
- * power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void arch_cpu_idle(void)
 {
 	unsigned long tmp;
@@ -73,8 +67,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	halt_loop();
 }
 
diff --git a/arch/cris/kernel/process.c b/arch/cris/kernel/process.c
index b78498e..9ebd76b 100644
--- a/arch/cris/kernel/process.c
+++ b/arch/cris/kernel/process.c
@@ -31,9 +31,6 @@
 
 extern void default_idle(void);
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void arch_cpu_idle(void)
 {
 	default_idle();
@@ -60,6 +57,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/frv/kernel/process.c b/arch/frv/kernel/process.c
index 5d40aeb77..502dabb 100644
--- a/arch/frv/kernel/process.c
+++ b/arch/frv/kernel/process.c
@@ -42,9 +42,6 @@ asmlinkage void ret_from_kernel_thread(void);
 
 #include <asm/pgalloc.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 static void core_sleep_idle(void)
 {
 #ifdef LED_DEBUG_SLEEP
@@ -107,6 +104,8 @@ void machine_power_off(void)
 	gdbstub_exit(0);
 #endif
 
+	do_kernel_power_off();
+
 	for (;;);
 }
 
diff --git a/arch/hexagon/kernel/reset.c b/arch/hexagon/kernel/reset.c
index 76483c1..6f607b6 100644
--- a/arch/hexagon/kernel/reset.c
+++ b/arch/hexagon/kernel/reset.c
@@ -16,11 +16,13 @@
  * 02110-1301, USA.
  */
 
+#include <linux/pm.h>
 #include <linux/smp.h>
 #include <asm/hexagon_vm.h>
 
 void machine_power_off(void)
 {
+	do_kernel_power_off();
 	smp_send_stop();
 	__vmstop();
 }
@@ -32,6 +34,3 @@ void machine_halt(void)
 void machine_restart(char *cmd)
 {
 }
-
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index b515149..88121a2 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -57,8 +57,6 @@ void (*ia64_mark_idle)(int);
 
 unsigned long boot_option_idle_override = IDLE_NO_OVERRIDE;
 EXPORT_SYMBOL(boot_option_idle_override);
-void (*pm_power_off) (void);
-EXPORT_SYMBOL(pm_power_off);
 
 void
 ia64_do_show_stack (struct unw_frame_info *info, void *arg)
@@ -675,8 +673,7 @@ machine_halt (void)
 void
 machine_power_off (void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	machine_halt();
 }
 
diff --git a/arch/m32r/kernel/process.c b/arch/m32r/kernel/process.c
index e69221d..65a037e 100644
--- a/arch/m32r/kernel/process.c
+++ b/arch/m32r/kernel/process.c
@@ -23,6 +23,7 @@
 #include <linux/fs.h>
 #include <linux/slab.h>
 #include <linux/module.h>
+#include <linux/pm.h>
 #include <linux/ptrace.h>
 #include <linux/unistd.h>
 #include <linux/hardirq.h>
@@ -44,9 +45,6 @@ unsigned long thread_saved_pc(struct task_struct *tsk)
 	return tsk->thread.lr;
 }
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_restart(char *__unused)
 {
 #if defined(CONFIG_PLAT_MAPPI3)
@@ -67,7 +65,9 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	/* M32R_FIXME */
+	do_kernel_power_off();
+	for (;;)
+		;
 }
 
 void show_regs(struct pt_regs * regs)
diff --git a/arch/m68k/kernel/process.c b/arch/m68k/kernel/process.c
index afe3d6e..bbc0a63 100644
--- a/arch/m68k/kernel/process.c
+++ b/arch/m68k/kernel/process.c
@@ -78,14 +78,10 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	for (;;);
 }
 
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 void show_regs(struct pt_regs * regs)
 {
 	printk("\n");
diff --git a/arch/metag/kernel/process.c b/arch/metag/kernel/process.c
index 483dff9..8d95773 100644
--- a/arch/metag/kernel/process.c
+++ b/arch/metag/kernel/process.c
@@ -67,9 +67,6 @@ void arch_cpu_idle_dead(void)
 }
 #endif
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void (*soc_restart)(char *cmd);
 void (*soc_halt)(void);
 
@@ -90,8 +87,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	smp_send_stop();
 	hard_processor_halt(HALT_OK);
 }
diff --git a/arch/microblaze/kernel/process.c b/arch/microblaze/kernel/process.c
index b2dd371..0ebca36 100644
--- a/arch/microblaze/kernel/process.c
+++ b/arch/microblaze/kernel/process.c
@@ -44,9 +44,6 @@ void show_regs(struct pt_regs *regs)
 				regs->msr, regs->ear, regs->esr, regs->fsr);
 }
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void flush_thread(void)
 {
 }
diff --git a/arch/microblaze/kernel/reset.c b/arch/microblaze/kernel/reset.c
index fbe58c6..2c6b32c 100644
--- a/arch/microblaze/kernel/reset.c
+++ b/arch/microblaze/kernel/reset.c
@@ -103,6 +103,7 @@ void machine_halt(void)
 void machine_power_off(void)
 {
 	pr_notice("Machine power off...\n");
+	do_kernel_power_off();
 	while (1)
 		;
 }
diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 07fc524..09e74d2 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -21,9 +21,6 @@
  */
 void (*_machine_restart)(char *command);
 void (*_machine_halt)(void);
-void (*pm_power_off)(void);
-
-EXPORT_SYMBOL(pm_power_off);
 
 void machine_restart(char *command)
 {
@@ -39,6 +36,5 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
diff --git a/arch/mn10300/kernel/process.c b/arch/mn10300/kernel/process.c
index 3707da5..c78b2eb 100644
--- a/arch/mn10300/kernel/process.c
+++ b/arch/mn10300/kernel/process.c
@@ -20,6 +20,7 @@
 #include <linux/user.h>
 #include <linux/interrupt.h>
 #include <linux/delay.h>
+#include <linux/pm.h>
 #include <linux/reboot.h>
 #include <linux/percpu.h>
 #include <linux/err.h>
@@ -45,12 +46,6 @@ unsigned long thread_saved_pc(struct task_struct *tsk)
 }
 
 /*
- * power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
-/*
  * On SMP it's slightly faster (but much more power-consuming!)
  * to poll the ->work.need_resched flag instead of waiting for the
  * cross-CPU IPI to arrive. Use this option with caution.
@@ -93,6 +88,7 @@ void machine_power_off(void)
 #ifdef CONFIG_KERNEL_DEBUGGER
 	gdbstub_exit(0);
 #endif
+	do_kernel_power_off();
 }
 
 void show_regs(struct pt_regs *regs)
diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
index 386af25..494afd2 100644
--- a/arch/openrisc/kernel/process.c
+++ b/arch/openrisc/kernel/process.c
@@ -25,6 +25,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/mm.h>
+#include <linux/pm.h>
 #include <linux/stddef.h>
 #include <linux/unistd.h>
 #include <linux/ptrace.h>
@@ -51,7 +52,7 @@
  */
 struct thread_info *current_thread_info_set[NR_CPUS] = { &init_thread_info, };
 
-void machine_restart(void)
+void machine_restart(char *cmd)
 {
 	printk(KERN_INFO "*** MACHINE RESTART ***\n");
 	__asm__("l.nop 1");
@@ -72,11 +73,12 @@ void machine_halt(void)
 void machine_power_off(void)
 {
 	printk(KERN_INFO "*** MACHINE POWER OFF ***\n");
+
+	do_kernel_power_off();
+
 	__asm__("l.nop 1");
 }
 
-void (*pm_power_off) (void) = machine_power_off;
-
 /*
  * When a process does an "exec", machine state like FPU and debug
  * registers need to be reset.  This is a hook function for that.
diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
index 0bbbf0d..3f5d14a 100644
--- a/arch/parisc/kernel/process.c
+++ b/arch/parisc/kernel/process.c
@@ -41,6 +41,7 @@
 #include <linux/fs.h>
 #include <linux/module.h>
 #include <linux/personality.h>
+#include <linux/pm.h>
 #include <linux/ptrace.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
@@ -133,7 +134,9 @@ void machine_power_off(void)
 	pdc_soft_power_button(0);
 	
 	pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN);
-		
+
+	do_kernel_power_off();
+
 	/* It seems we have no way to power the system off via
 	 * software. The user has to press the button himself. */
 
@@ -141,9 +144,6 @@ void machine_power_off(void)
 	       "Please power this system off now.");
 }
 
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * Free current thread data structures etc..
  */
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 44c8d03..a2efce7 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -139,8 +139,7 @@ void machine_restart(char *cmd)
 void machine_power_off(void)
 {
 	machine_shutdown();
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 #ifdef CONFIG_SMP
 	smp_send_stop();
 #endif
@@ -151,9 +150,6 @@ void machine_power_off(void)
 /* Used by the G5 thermal driver */
 EXPORT_SYMBOL_GPL(machine_power_off);
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL_GPL(pm_power_off);
-
 void machine_halt(void)
 {
 	machine_shutdown();
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 506d256..8780178 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -981,8 +981,7 @@ static void bootcmds(void)
 	else if (cmd == 'h')
 		ppc_md.halt();
 	else if (cmd == 'p')
-		if (pm_power_off)
-			pm_power_off();
+		do_kernel_power_off();
 }
 
 static int cpu_cmd(void)
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index e80d9ff..267e025 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -263,13 +263,9 @@ void machine_power_off(void)
 		 */
 		console_unblank();
 	_machine_power_off();
-}
 
-/*
- * Dummy power off function.
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL_GPL(pm_power_off);
+	do_kernel_power_off();
+}
 
 static int __init early_parse_mem(char *p)
 {
diff --git a/arch/score/kernel/process.c b/arch/score/kernel/process.c
index a1519ad3..b76ea67 100644
--- a/arch/score/kernel/process.c
+++ b/arch/score/kernel/process.c
@@ -29,9 +29,6 @@
 #include <linux/pm.h>
 #include <linux/rcupdate.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 /* If or when software machine-restart is implemented, add code here. */
 void machine_restart(char *command) {}
 
@@ -39,7 +36,10 @@ void machine_restart(char *command) {}
 void machine_halt(void) {}
 
 /* If or when software machine-power-off is implemented, add code here. */
-void machine_power_off(void) {}
+void machine_power_off(void)
+{
+	do_kernel_power_off();
+}
 
 void ret_from_fork(void);
 void ret_from_kernel_thread(void);
diff --git a/arch/sh/kernel/reboot.c b/arch/sh/kernel/reboot.c
index 04afe5b..065de12 100644
--- a/arch/sh/kernel/reboot.c
+++ b/arch/sh/kernel/reboot.c
@@ -11,9 +11,6 @@
 #include <asm/tlbflush.h>
 #include <asm/traps.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 #ifdef CONFIG_SUPERH32
 static void watchdog_trigger_immediate(void)
 {
@@ -51,8 +48,7 @@ static void native_machine_shutdown(void)
 
 static void native_machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 static void native_machine_halt(void)
diff --git a/arch/sparc/kernel/process_32.c b/arch/sparc/kernel/process_32.c
index 50e7b62..cb8148a 100644
--- a/arch/sparc/kernel/process_32.c
+++ b/arch/sparc/kernel/process_32.c
@@ -48,14 +48,6 @@
  */
 void (*sparc_idle)(void);
 
-/* 
- * Power-off handler instantiation for pm.h compliance
- * This is done via auxio, but could be used as a fallback
- * handler when auxio is not present-- unused for now...
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * sysctl - toggle power-off restriction for serial console 
  * systems in machine_power_off()
@@ -112,6 +104,8 @@ void machine_power_off(void)
 		sbus_writeb(power_register, auxio_power_register);
 	}
 
+	do_kernel_power_off();
+
 	machine_halt();
 }
 
diff --git a/arch/sparc/kernel/reboot.c b/arch/sparc/kernel/reboot.c
index eba7d91..3c0bb03 100644
--- a/arch/sparc/kernel/reboot.c
+++ b/arch/sparc/kernel/reboot.c
@@ -16,17 +16,13 @@
  */
 int scons_pwroff = 1;
 
-/* This isn't actually used, it exists merely to satisfy the
- * reference in kernel/sys.c
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_power_off(void)
 {
 	if (strcmp(of_console_device->type, "serial") || scons_pwroff)
 		prom_halt_power_off();
 
+	do_kernel_power_off();
+
 	prom_halt();
 }
 
diff --git a/arch/tile/kernel/reboot.c b/arch/tile/kernel/reboot.c
index 6c5d2c0..8ff4a7f 100644
--- a/arch/tile/kernel/reboot.c
+++ b/arch/tile/kernel/reboot.c
@@ -36,6 +36,9 @@ void machine_power_off(void)
 {
 	arch_local_irq_disable_all();
 	smp_send_stop();
+
+	do_kernel_power_off();
+
 	hv_power_off();
 }
 
@@ -45,7 +48,3 @@ void machine_restart(char *cmd)
 	smp_send_stop();
 	hv_restart((HV_VirtAddr) "vmlinux", (HV_VirtAddr) cmd);
 }
-
-/* No interesting distinction to be made here. */
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/um/kernel/reboot.c b/arch/um/kernel/reboot.c
index ced8903..a82ef28 100644
--- a/arch/um/kernel/reboot.c
+++ b/arch/um/kernel/reboot.c
@@ -11,8 +11,6 @@
 #include <os.h>
 #include <skas.h>
 
-void (*pm_power_off)(void);
-
 static void kill_off_processes(void)
 {
 	if (proc_mm)
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index b008e99..9490dd5 100644
--- a/arch/unicore32/kernel/process.c
+++ b/arch/unicore32/kernel/process.c
@@ -56,16 +56,9 @@ void machine_halt(void)
 	gpio_set_value(GPO_SOFT_OFF, 0);
 }
 
-/*
- * Function pointers to optional machine specific functions
- */
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	machine_halt();
 }
 
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 17962e6..5c09e28 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -30,12 +30,6 @@
 #include <asm/x86_init.h>
 #include <asm/efi.h>
 
-/*
- * Power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 static const struct desc_ptr no_idt = {};
 
 /*
@@ -647,11 +641,12 @@ static void native_machine_halt(void)
 
 static void native_machine_power_off(void)
 {
-	if (pm_power_off) {
+	if (have_kernel_power_off()) {
 		if (!reboot_force)
 			machine_shutdown();
-		pm_power_off();
+		do_kernel_power_off();
 	}
+
 	/* A fallback in case there is no PM info available */
 	tboot_shutdown(TB_SHUTDOWN_HALT);
 }
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index fac5e4f..bc08998 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1320,8 +1320,7 @@ static void xen_machine_halt(void)
 
 static void xen_machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	xen_reboot(SHUTDOWN_poweroff);
 }
 
diff --git a/arch/xtensa/kernel/process.c b/arch/xtensa/kernel/process.c
index 1c85323..c487296 100644
--- a/arch/xtensa/kernel/process.c
+++ b/arch/xtensa/kernel/process.c
@@ -49,10 +49,6 @@ extern void ret_from_kernel_thread(void);
 
 struct task_struct *current_set[NR_CPUS] = {&init_task, };
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
-
 #if XTENSA_HAVE_COPROCESSORS
 
 void coprocessor_release_all(struct thread_info *ti)
diff --git a/drivers/parisc/power.c b/drivers/parisc/power.c
index ef31b77..f10cf92 100644
--- a/drivers/parisc/power.c
+++ b/drivers/parisc/power.c
@@ -95,8 +95,7 @@ static void process_shutdown(void)
 		/* send kill signal */
 		if (kill_cad_pid(SIGINT, 1)) {
 			/* just in case killing init process failed */
-			if (pm_power_off)
-				pm_power_off();
+			kernel_power_off();
 		}
 	}
 }
diff --git a/kernel/power/power_off_handler.c b/kernel/power/power_off_handler.c
index c19e72b..d80a337 100644
--- a/kernel/power/power_off_handler.c
+++ b/kernel/power/power_off_handler.c
@@ -23,6 +23,12 @@
 #include <linux/types.h>
 
 /*
+ * If set, calling this function will power off the system immediately.
+ */
+void (*pm_power_off)(void);
+EXPORT_SYMBOL(pm_power_off);
+
+/*
  * List of handlers for kernel code which wants to be called
  * to power off the system.
  */
@@ -291,6 +297,9 @@ void do_kernel_power_off(void)
 	 * that risk.
 	 */
 
+	if (pm_power_off)
+		pm_power_off();
+
 	p = rcu_dereference_raw(power_off_handler_list);
 	while (p) {
 		next_p = rcu_dereference_raw(p->next);
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 5925f5a..d87d921 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -306,9 +306,9 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
 		return ret;
 
 	/* Instead of trying to make the power_off code look like
-	 * halt when pm_power_off is not set do it the easy way.
+	 * halt when no power-off handler exists do it the easy way.
 	 */
-	if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) && !pm_power_off)
+	if (cmd == LINUX_REBOOT_CMD_POWER_OFF && !have_kernel_power_off())
 		cmd = LINUX_REBOOT_CMD_HALT;
 
 	mutex_lock(&reboot_mutex);
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 01:45:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 01: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.xen.org>)
	id 1Xne2w-0006xN-Ho; Mon, 10 Nov 2014 01:45:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@roeck-us.net>) id 1Xne2u-0006xI-UI
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 01:45:33 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	99/70-02712-CB810645; Mon, 10 Nov 2014 01:45:32 +0000
X-Env-Sender: linux@roeck-us.net
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415583929!12346336!1
X-Originating-IP: [208.91.199.152]
X-SpamReason: No, hits=2.7 required=7.0 tests=BODY_RANDOM_LONG,
	SUSPICIOUS_RECIPS,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3999 invoked from network); 10 Nov 2014 01:45:30 -0000
Received: from bh-25.webhostbox.net (HELO bh-25.webhostbox.net)
	(208.91.199.152)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 01:45:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roeck-us.net;
	s=default; 
	h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=cHZZ9ehbHT9KuRkSB6KpCsrzlzh5bGiaCmG8fTZy42s=; 
	b=J6+AbJ2EFT1hVcHFlJgpy7IprT2xo6+ep0hs65MceTtTCYhjVCBIbsPyiExAMJE8r396XV84a/hBckUsy18zDMRDH9sFBx8V36Nvr9sBqf6OSC8VS53qEY+gCIUhgBULiOAleJQvAtWyu9WzsQu7wr4HY5pIyxkLpQBqQQnZ9o0=;
Received: from mailnull by bh-25.webhostbox.net with sa-checked (Exim 4.82)
	(envelope-from <linux@roeck-us.net>) id 1Xne2q-000XmS-Ln
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 01:45:28 +0000
Received: from 108-223-40-66.lightspeed.sntcca.sbcglobal.net
	([108.223.40.66]:36296 helo=localhost)
	by bh-25.webhostbox.net with esmtpa (Exim 4.82)
	(envelope-from <linux@roeck-us.net>)
	id 1Xne15-000TzJ-AY; Mon, 10 Nov 2014 01:43:41 +0000
From: Guenter Roeck <linux@roeck-us.net>
To: linux-kernel@vger.kernel.org
Date: Sun,  9 Nov 2014 17:42:25 -0800
Message-Id: <1415583785-6980-9-git-send-email-linux@roeck-us.net>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415583785-6980-1-git-send-email-linux@roeck-us.net>
References: <1415583785-6980-1-git-send-email-linux@roeck-us.net>
X-Authenticated_sender: guenter@roeck-us.net
X-OutGoing-Spam-Status: No, score=2.5
X-Spam-Checker-Version: spamc_ctasd client on
	localost
X-Spam-Level: *
X-Spam-Status: No, score=2.0 required=50.0 tests=SpamClass_Suspect,
	VirusClass_Unknown autolearn=disabled version=1.0.0
X-CTCH-PVer: 0000001
X-CTCH-Spam: Suspect
X-CTCH-VOD: Unknown
X-CTCH-Flags: 512
X-CTCH-RefID: str=0001.0A02020A.546018B8.0148, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=512, sb=0
X-CTCH-Score: 0.000
X-CTCH-ScoreCust: 0.000
X-CTCH-Rules: 
X-CTCH-SenderID: linux@roeck-us.net
X-CTCH-SenderID-Flags: 0
X-CTCH-SenderID-TotalMessages: 292
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 2
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-TotalRecipients: 0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - lists.xenproject.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from
	get_relayhosts_entry
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
	linux-sh@vger.kernel.org, linux@lists.openrisc.net,
	sparclinux@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-am33-list@redhat.com, linux-c6x-dev@linux-c6x.org,
	linux-hexagon@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xenproject.org, Guenter Roeck <linux@roeck-us.net>,
	linux-xtensa@linux-xtensa.org, user-mode-linux-devel@lists.sourceforge.net,
	linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net,
	linux-m68k@lists.linux-m68k.org,
	user-mode-linux-user@lists.sourceforge.net, linux-metag@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
	linux-alpha@vger.kernel.org, linux390@de.ibm.com,
	linuxppc-dev@lists.ozlabs.org
Subject: [Xen-devel] [PATCH v6 08/48] kernel: Move pm_power_off to common
	code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pm_power_off is defined for all architectures. Move it to common code.

Have all architectures call do_kernel_power_off instead of pm_power_off.
Some architectures point pm_power_off to machine_power_off. For those,
call do_kernel_power_off from machine_power_off instead.

Acked-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Hirokazu Takata <takata@linux-m32r.org>
Acked-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
Acked-by: Richard Weinberger <richard@nod.at>
Acked-by: Xuetao Guan <gxt@mprc.pku.edu.cn>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v6:
- No change.
v5:
- Rebase to v3.18-rc3
- Update powerpc code to reflect merged power-off handler changes
v4:
- No change
v3:
- Replace poweroff in all newly introduced variables and in text
  with power_off or power-off as appropriate
v2:
- do_kernel_poweroff -> do_kernel_power_off
- have_kernel_poweroff -> have_kernel_power_off

 arch/alpha/kernel/process.c        |  9 +++------
 arch/arc/kernel/reset.c            |  5 +----
 arch/arm/kernel/process.c          |  5 +----
 arch/arm64/kernel/process.c        |  5 +----
 arch/avr32/kernel/process.c        |  6 +-----
 arch/blackfin/kernel/process.c     |  3 ---
 arch/blackfin/kernel/reboot.c      |  2 ++
 arch/c6x/kernel/process.c          |  9 +--------
 arch/cris/kernel/process.c         |  4 +---
 arch/frv/kernel/process.c          |  5 ++---
 arch/hexagon/kernel/reset.c        |  5 ++---
 arch/ia64/kernel/process.c         |  5 +----
 arch/m32r/kernel/process.c         |  8 ++++----
 arch/m68k/kernel/process.c         |  6 +-----
 arch/metag/kernel/process.c        |  6 +-----
 arch/microblaze/kernel/process.c   |  3 ---
 arch/microblaze/kernel/reset.c     |  1 +
 arch/mips/kernel/reset.c           |  6 +-----
 arch/mn10300/kernel/process.c      |  8 ++------
 arch/openrisc/kernel/process.c     |  8 +++++---
 arch/parisc/kernel/process.c       |  8 ++++----
 arch/powerpc/kernel/setup-common.c |  6 +-----
 arch/powerpc/xmon/xmon.c           |  3 +--
 arch/s390/kernel/setup.c           |  8 ++------
 arch/score/kernel/process.c        |  8 ++++----
 arch/sh/kernel/reboot.c            |  6 +-----
 arch/sparc/kernel/process_32.c     | 10 ++--------
 arch/sparc/kernel/reboot.c         |  8 ++------
 arch/tile/kernel/reboot.c          |  7 +++----
 arch/um/kernel/reboot.c            |  2 --
 arch/unicore32/kernel/process.c    |  9 +--------
 arch/x86/kernel/reboot.c           | 11 +++--------
 arch/x86/xen/enlighten.c           |  3 +--
 arch/xtensa/kernel/process.c       |  4 ----
 drivers/parisc/power.c             |  3 +--
 kernel/power/power_off_handler.c   |  9 +++++++++
 kernel/reboot.c                    |  4 ++--
 37 files changed, 68 insertions(+), 150 deletions(-)

diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 1941a07..81c43f8 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -24,6 +24,7 @@
 #include <linux/vt.h>
 #include <linux/mman.h>
 #include <linux/elfcore.h>
+#include <linux/pm.h>
 #include <linux/reboot.h>
 #include <linux/tty.h>
 #include <linux/console.h>
@@ -40,12 +41,6 @@
 #include "proto.h"
 #include "pci_impl.h"
 
-/*
- * Power off function, if any
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 #ifdef CONFIG_ALPHA_WTINT
 /*
  * Sleep the CPU.
@@ -184,6 +179,8 @@ machine_halt(void)
 void
 machine_power_off(void)
 {
+	do_kernel_power_off();
+
 	common_shutdown(LINUX_REBOOT_CMD_POWER_OFF, NULL);
 }
 
diff --git a/arch/arc/kernel/reset.c b/arch/arc/kernel/reset.c
index 2768fa1..0758d9d 100644
--- a/arch/arc/kernel/reset.c
+++ b/arch/arc/kernel/reset.c
@@ -26,9 +26,6 @@ void machine_restart(char *__unused)
 
 void machine_power_off(void)
 {
-	/* FIXME ::  power off ??? */
+	do_kernel_power_off();
 	machine_halt();
 }
-
-void (*pm_power_off) (void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index fe972a2..aa3f656 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -117,8 +117,6 @@ void soft_restart(unsigned long addr)
 /*
  * Function pointers to optional machine specific functions
  */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 
@@ -205,8 +203,7 @@ void machine_power_off(void)
 	local_irq_disable();
 	smp_send_stop();
 
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index fde9923..6f623a0 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -68,8 +68,6 @@ void soft_restart(unsigned long addr)
 /*
  * Function pointers to optional machine specific functions
  */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL_GPL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 
@@ -129,8 +127,7 @@ void machine_power_off(void)
 {
 	local_irq_disable();
 	smp_send_stop();
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/avr32/kernel/process.c b/arch/avr32/kernel/process.c
index 42a53e74..529c1f6 100644
--- a/arch/avr32/kernel/process.c
+++ b/arch/avr32/kernel/process.c
@@ -23,9 +23,6 @@
 
 #include <mach/pm.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * This file handles the architecture-dependent parts of process handling..
  */
@@ -48,8 +45,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 void machine_restart(char *cmd)
diff --git a/arch/blackfin/kernel/process.c b/arch/blackfin/kernel/process.c
index 4aa5545..812dd83 100644
--- a/arch/blackfin/kernel/process.c
+++ b/arch/blackfin/kernel/process.c
@@ -39,9 +39,6 @@ int nr_l1stack_tasks;
 void *l1_stack_base;
 unsigned long l1_stack_len;
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * The idle loop on BFIN
  */
diff --git a/arch/blackfin/kernel/reboot.c b/arch/blackfin/kernel/reboot.c
index c4f50a3..387d610 100644
--- a/arch/blackfin/kernel/reboot.c
+++ b/arch/blackfin/kernel/reboot.c
@@ -7,6 +7,7 @@
  */
 
 #include <linux/interrupt.h>
+#include <linux/pm.h>
 #include <asm/bfin-global.h>
 #include <asm/reboot.h>
 #include <asm/bfrom.h>
@@ -106,6 +107,7 @@ void machine_halt(void)
 __attribute__((weak))
 void native_machine_power_off(void)
 {
+	do_kernel_power_off();
 	idle_with_irq_disabled();
 }
 
diff --git a/arch/c6x/kernel/process.c b/arch/c6x/kernel/process.c
index 57d2ea8..edf7e5a 100644
--- a/arch/c6x/kernel/process.c
+++ b/arch/c6x/kernel/process.c
@@ -27,12 +27,6 @@ void	(*c6x_halt)(void);
 extern asmlinkage void ret_from_fork(void);
 extern asmlinkage void ret_from_kernel_thread(void);
 
-/*
- * power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void arch_cpu_idle(void)
 {
 	unsigned long tmp;
@@ -73,8 +67,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	halt_loop();
 }
 
diff --git a/arch/cris/kernel/process.c b/arch/cris/kernel/process.c
index b78498e..9ebd76b 100644
--- a/arch/cris/kernel/process.c
+++ b/arch/cris/kernel/process.c
@@ -31,9 +31,6 @@
 
 extern void default_idle(void);
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void arch_cpu_idle(void)
 {
 	default_idle();
@@ -60,6 +57,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
+	do_kernel_power_off();
 }
 
 /*
diff --git a/arch/frv/kernel/process.c b/arch/frv/kernel/process.c
index 5d40aeb77..502dabb 100644
--- a/arch/frv/kernel/process.c
+++ b/arch/frv/kernel/process.c
@@ -42,9 +42,6 @@ asmlinkage void ret_from_kernel_thread(void);
 
 #include <asm/pgalloc.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 static void core_sleep_idle(void)
 {
 #ifdef LED_DEBUG_SLEEP
@@ -107,6 +104,8 @@ void machine_power_off(void)
 	gdbstub_exit(0);
 #endif
 
+	do_kernel_power_off();
+
 	for (;;);
 }
 
diff --git a/arch/hexagon/kernel/reset.c b/arch/hexagon/kernel/reset.c
index 76483c1..6f607b6 100644
--- a/arch/hexagon/kernel/reset.c
+++ b/arch/hexagon/kernel/reset.c
@@ -16,11 +16,13 @@
  * 02110-1301, USA.
  */
 
+#include <linux/pm.h>
 #include <linux/smp.h>
 #include <asm/hexagon_vm.h>
 
 void machine_power_off(void)
 {
+	do_kernel_power_off();
 	smp_send_stop();
 	__vmstop();
 }
@@ -32,6 +34,3 @@ void machine_halt(void)
 void machine_restart(char *cmd)
 {
 }
-
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index b515149..88121a2 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -57,8 +57,6 @@ void (*ia64_mark_idle)(int);
 
 unsigned long boot_option_idle_override = IDLE_NO_OVERRIDE;
 EXPORT_SYMBOL(boot_option_idle_override);
-void (*pm_power_off) (void);
-EXPORT_SYMBOL(pm_power_off);
 
 void
 ia64_do_show_stack (struct unw_frame_info *info, void *arg)
@@ -675,8 +673,7 @@ machine_halt (void)
 void
 machine_power_off (void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	machine_halt();
 }
 
diff --git a/arch/m32r/kernel/process.c b/arch/m32r/kernel/process.c
index e69221d..65a037e 100644
--- a/arch/m32r/kernel/process.c
+++ b/arch/m32r/kernel/process.c
@@ -23,6 +23,7 @@
 #include <linux/fs.h>
 #include <linux/slab.h>
 #include <linux/module.h>
+#include <linux/pm.h>
 #include <linux/ptrace.h>
 #include <linux/unistd.h>
 #include <linux/hardirq.h>
@@ -44,9 +45,6 @@ unsigned long thread_saved_pc(struct task_struct *tsk)
 	return tsk->thread.lr;
 }
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_restart(char *__unused)
 {
 #if defined(CONFIG_PLAT_MAPPI3)
@@ -67,7 +65,9 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	/* M32R_FIXME */
+	do_kernel_power_off();
+	for (;;)
+		;
 }
 
 void show_regs(struct pt_regs * regs)
diff --git a/arch/m68k/kernel/process.c b/arch/m68k/kernel/process.c
index afe3d6e..bbc0a63 100644
--- a/arch/m68k/kernel/process.c
+++ b/arch/m68k/kernel/process.c
@@ -78,14 +78,10 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	for (;;);
 }
 
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 void show_regs(struct pt_regs * regs)
 {
 	printk("\n");
diff --git a/arch/metag/kernel/process.c b/arch/metag/kernel/process.c
index 483dff9..8d95773 100644
--- a/arch/metag/kernel/process.c
+++ b/arch/metag/kernel/process.c
@@ -67,9 +67,6 @@ void arch_cpu_idle_dead(void)
 }
 #endif
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 void (*soc_restart)(char *cmd);
 void (*soc_halt)(void);
 
@@ -90,8 +87,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	smp_send_stop();
 	hard_processor_halt(HALT_OK);
 }
diff --git a/arch/microblaze/kernel/process.c b/arch/microblaze/kernel/process.c
index b2dd371..0ebca36 100644
--- a/arch/microblaze/kernel/process.c
+++ b/arch/microblaze/kernel/process.c
@@ -44,9 +44,6 @@ void show_regs(struct pt_regs *regs)
 				regs->msr, regs->ear, regs->esr, regs->fsr);
 }
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void flush_thread(void)
 {
 }
diff --git a/arch/microblaze/kernel/reset.c b/arch/microblaze/kernel/reset.c
index fbe58c6..2c6b32c 100644
--- a/arch/microblaze/kernel/reset.c
+++ b/arch/microblaze/kernel/reset.c
@@ -103,6 +103,7 @@ void machine_halt(void)
 void machine_power_off(void)
 {
 	pr_notice("Machine power off...\n");
+	do_kernel_power_off();
 	while (1)
 		;
 }
diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 07fc524..09e74d2 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -21,9 +21,6 @@
  */
 void (*_machine_restart)(char *command);
 void (*_machine_halt)(void);
-void (*pm_power_off)(void);
-
-EXPORT_SYMBOL(pm_power_off);
 
 void machine_restart(char *command)
 {
@@ -39,6 +36,5 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
diff --git a/arch/mn10300/kernel/process.c b/arch/mn10300/kernel/process.c
index 3707da5..c78b2eb 100644
--- a/arch/mn10300/kernel/process.c
+++ b/arch/mn10300/kernel/process.c
@@ -20,6 +20,7 @@
 #include <linux/user.h>
 #include <linux/interrupt.h>
 #include <linux/delay.h>
+#include <linux/pm.h>
 #include <linux/reboot.h>
 #include <linux/percpu.h>
 #include <linux/err.h>
@@ -45,12 +46,6 @@ unsigned long thread_saved_pc(struct task_struct *tsk)
 }
 
 /*
- * power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
-/*
  * On SMP it's slightly faster (but much more power-consuming!)
  * to poll the ->work.need_resched flag instead of waiting for the
  * cross-CPU IPI to arrive. Use this option with caution.
@@ -93,6 +88,7 @@ void machine_power_off(void)
 #ifdef CONFIG_KERNEL_DEBUGGER
 	gdbstub_exit(0);
 #endif
+	do_kernel_power_off();
 }
 
 void show_regs(struct pt_regs *regs)
diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
index 386af25..494afd2 100644
--- a/arch/openrisc/kernel/process.c
+++ b/arch/openrisc/kernel/process.c
@@ -25,6 +25,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/mm.h>
+#include <linux/pm.h>
 #include <linux/stddef.h>
 #include <linux/unistd.h>
 #include <linux/ptrace.h>
@@ -51,7 +52,7 @@
  */
 struct thread_info *current_thread_info_set[NR_CPUS] = { &init_thread_info, };
 
-void machine_restart(void)
+void machine_restart(char *cmd)
 {
 	printk(KERN_INFO "*** MACHINE RESTART ***\n");
 	__asm__("l.nop 1");
@@ -72,11 +73,12 @@ void machine_halt(void)
 void machine_power_off(void)
 {
 	printk(KERN_INFO "*** MACHINE POWER OFF ***\n");
+
+	do_kernel_power_off();
+
 	__asm__("l.nop 1");
 }
 
-void (*pm_power_off) (void) = machine_power_off;
-
 /*
  * When a process does an "exec", machine state like FPU and debug
  * registers need to be reset.  This is a hook function for that.
diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
index 0bbbf0d..3f5d14a 100644
--- a/arch/parisc/kernel/process.c
+++ b/arch/parisc/kernel/process.c
@@ -41,6 +41,7 @@
 #include <linux/fs.h>
 #include <linux/module.h>
 #include <linux/personality.h>
+#include <linux/pm.h>
 #include <linux/ptrace.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
@@ -133,7 +134,9 @@ void machine_power_off(void)
 	pdc_soft_power_button(0);
 	
 	pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN);
-		
+
+	do_kernel_power_off();
+
 	/* It seems we have no way to power the system off via
 	 * software. The user has to press the button himself. */
 
@@ -141,9 +144,6 @@ void machine_power_off(void)
 	       "Please power this system off now.");
 }
 
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * Free current thread data structures etc..
  */
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 44c8d03..a2efce7 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -139,8 +139,7 @@ void machine_restart(char *cmd)
 void machine_power_off(void)
 {
 	machine_shutdown();
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 #ifdef CONFIG_SMP
 	smp_send_stop();
 #endif
@@ -151,9 +150,6 @@ void machine_power_off(void)
 /* Used by the G5 thermal driver */
 EXPORT_SYMBOL_GPL(machine_power_off);
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL_GPL(pm_power_off);
-
 void machine_halt(void)
 {
 	machine_shutdown();
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 506d256..8780178 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -981,8 +981,7 @@ static void bootcmds(void)
 	else if (cmd == 'h')
 		ppc_md.halt();
 	else if (cmd == 'p')
-		if (pm_power_off)
-			pm_power_off();
+		do_kernel_power_off();
 }
 
 static int cpu_cmd(void)
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index e80d9ff..267e025 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -263,13 +263,9 @@ void machine_power_off(void)
 		 */
 		console_unblank();
 	_machine_power_off();
-}
 
-/*
- * Dummy power off function.
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL_GPL(pm_power_off);
+	do_kernel_power_off();
+}
 
 static int __init early_parse_mem(char *p)
 {
diff --git a/arch/score/kernel/process.c b/arch/score/kernel/process.c
index a1519ad3..b76ea67 100644
--- a/arch/score/kernel/process.c
+++ b/arch/score/kernel/process.c
@@ -29,9 +29,6 @@
 #include <linux/pm.h>
 #include <linux/rcupdate.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 /* If or when software machine-restart is implemented, add code here. */
 void machine_restart(char *command) {}
 
@@ -39,7 +36,10 @@ void machine_restart(char *command) {}
 void machine_halt(void) {}
 
 /* If or when software machine-power-off is implemented, add code here. */
-void machine_power_off(void) {}
+void machine_power_off(void)
+{
+	do_kernel_power_off();
+}
 
 void ret_from_fork(void);
 void ret_from_kernel_thread(void);
diff --git a/arch/sh/kernel/reboot.c b/arch/sh/kernel/reboot.c
index 04afe5b..065de12 100644
--- a/arch/sh/kernel/reboot.c
+++ b/arch/sh/kernel/reboot.c
@@ -11,9 +11,6 @@
 #include <asm/tlbflush.h>
 #include <asm/traps.h>
 
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 #ifdef CONFIG_SUPERH32
 static void watchdog_trigger_immediate(void)
 {
@@ -51,8 +48,7 @@ static void native_machine_shutdown(void)
 
 static void native_machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 }
 
 static void native_machine_halt(void)
diff --git a/arch/sparc/kernel/process_32.c b/arch/sparc/kernel/process_32.c
index 50e7b62..cb8148a 100644
--- a/arch/sparc/kernel/process_32.c
+++ b/arch/sparc/kernel/process_32.c
@@ -48,14 +48,6 @@
  */
 void (*sparc_idle)(void);
 
-/* 
- * Power-off handler instantiation for pm.h compliance
- * This is done via auxio, but could be used as a fallback
- * handler when auxio is not present-- unused for now...
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 /*
  * sysctl - toggle power-off restriction for serial console 
  * systems in machine_power_off()
@@ -112,6 +104,8 @@ void machine_power_off(void)
 		sbus_writeb(power_register, auxio_power_register);
 	}
 
+	do_kernel_power_off();
+
 	machine_halt();
 }
 
diff --git a/arch/sparc/kernel/reboot.c b/arch/sparc/kernel/reboot.c
index eba7d91..3c0bb03 100644
--- a/arch/sparc/kernel/reboot.c
+++ b/arch/sparc/kernel/reboot.c
@@ -16,17 +16,13 @@
  */
 int scons_pwroff = 1;
 
-/* This isn't actually used, it exists merely to satisfy the
- * reference in kernel/sys.c
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_power_off(void)
 {
 	if (strcmp(of_console_device->type, "serial") || scons_pwroff)
 		prom_halt_power_off();
 
+	do_kernel_power_off();
+
 	prom_halt();
 }
 
diff --git a/arch/tile/kernel/reboot.c b/arch/tile/kernel/reboot.c
index 6c5d2c0..8ff4a7f 100644
--- a/arch/tile/kernel/reboot.c
+++ b/arch/tile/kernel/reboot.c
@@ -36,6 +36,9 @@ void machine_power_off(void)
 {
 	arch_local_irq_disable_all();
 	smp_send_stop();
+
+	do_kernel_power_off();
+
 	hv_power_off();
 }
 
@@ -45,7 +48,3 @@ void machine_restart(char *cmd)
 	smp_send_stop();
 	hv_restart((HV_VirtAddr) "vmlinux", (HV_VirtAddr) cmd);
 }
-
-/* No interesting distinction to be made here. */
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/um/kernel/reboot.c b/arch/um/kernel/reboot.c
index ced8903..a82ef28 100644
--- a/arch/um/kernel/reboot.c
+++ b/arch/um/kernel/reboot.c
@@ -11,8 +11,6 @@
 #include <os.h>
 #include <skas.h>
 
-void (*pm_power_off)(void);
-
 static void kill_off_processes(void)
 {
 	if (proc_mm)
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index b008e99..9490dd5 100644
--- a/arch/unicore32/kernel/process.c
+++ b/arch/unicore32/kernel/process.c
@@ -56,16 +56,9 @@ void machine_halt(void)
 	gpio_set_value(GPO_SOFT_OFF, 0);
 }
 
-/*
- * Function pointers to optional machine specific functions
- */
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
 void machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	machine_halt();
 }
 
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 17962e6..5c09e28 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -30,12 +30,6 @@
 #include <asm/x86_init.h>
 #include <asm/efi.h>
 
-/*
- * Power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
 static const struct desc_ptr no_idt = {};
 
 /*
@@ -647,11 +641,12 @@ static void native_machine_halt(void)
 
 static void native_machine_power_off(void)
 {
-	if (pm_power_off) {
+	if (have_kernel_power_off()) {
 		if (!reboot_force)
 			machine_shutdown();
-		pm_power_off();
+		do_kernel_power_off();
 	}
+
 	/* A fallback in case there is no PM info available */
 	tboot_shutdown(TB_SHUTDOWN_HALT);
 }
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index fac5e4f..bc08998 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1320,8 +1320,7 @@ static void xen_machine_halt(void)
 
 static void xen_machine_power_off(void)
 {
-	if (pm_power_off)
-		pm_power_off();
+	do_kernel_power_off();
 	xen_reboot(SHUTDOWN_poweroff);
 }
 
diff --git a/arch/xtensa/kernel/process.c b/arch/xtensa/kernel/process.c
index 1c85323..c487296 100644
--- a/arch/xtensa/kernel/process.c
+++ b/arch/xtensa/kernel/process.c
@@ -49,10 +49,6 @@ extern void ret_from_kernel_thread(void);
 
 struct task_struct *current_set[NR_CPUS] = {&init_task, };
 
-void (*pm_power_off)(void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
-
-
 #if XTENSA_HAVE_COPROCESSORS
 
 void coprocessor_release_all(struct thread_info *ti)
diff --git a/drivers/parisc/power.c b/drivers/parisc/power.c
index ef31b77..f10cf92 100644
--- a/drivers/parisc/power.c
+++ b/drivers/parisc/power.c
@@ -95,8 +95,7 @@ static void process_shutdown(void)
 		/* send kill signal */
 		if (kill_cad_pid(SIGINT, 1)) {
 			/* just in case killing init process failed */
-			if (pm_power_off)
-				pm_power_off();
+			kernel_power_off();
 		}
 	}
 }
diff --git a/kernel/power/power_off_handler.c b/kernel/power/power_off_handler.c
index c19e72b..d80a337 100644
--- a/kernel/power/power_off_handler.c
+++ b/kernel/power/power_off_handler.c
@@ -23,6 +23,12 @@
 #include <linux/types.h>
 
 /*
+ * If set, calling this function will power off the system immediately.
+ */
+void (*pm_power_off)(void);
+EXPORT_SYMBOL(pm_power_off);
+
+/*
  * List of handlers for kernel code which wants to be called
  * to power off the system.
  */
@@ -291,6 +297,9 @@ void do_kernel_power_off(void)
 	 * that risk.
 	 */
 
+	if (pm_power_off)
+		pm_power_off();
+
 	p = rcu_dereference_raw(power_off_handler_list);
 	while (p) {
 		next_p = rcu_dereference_raw(p->next);
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 5925f5a..d87d921 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -306,9 +306,9 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
 		return ret;
 
 	/* Instead of trying to make the power_off code look like
-	 * halt when pm_power_off is not set do it the easy way.
+	 * halt when no power-off handler exists do it the easy way.
 	 */
-	if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) && !pm_power_off)
+	if (cmd == LINUX_REBOOT_CMD_POWER_OFF && !have_kernel_power_off())
 		cmd = LINUX_REBOOT_CMD_HALT;
 
 	mutex_lock(&reboot_mutex);
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 01:46:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 01:46:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xne3L-00070B-8N; Mon, 10 Nov 2014 01:45:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@roeck-us.net>) id 1Xne3J-0006zw-4J
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 01:45:57 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	5E/26-27623-4D810645; Mon, 10 Nov 2014 01:45:56 +0000
X-Env-Sender: linux@roeck-us.net
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415583953!6997874!1
X-Originating-IP: [208.91.199.152]
X-SpamReason: No, hits=2.2 required=7.0 tests=SUSPICIOUS_RECIPS,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7765 invoked from network); 10 Nov 2014 01:45:54 -0000
Received: from bh-25.webhostbox.net (HELO bh-25.webhostbox.net)
	(208.91.199.152)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 01:45:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roeck-us.net;
	s=default; 
	h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=Md2buJH4GRZCvo6akMqCEv2297VMrVgcCbcHaMlC7AM=; 
	b=Gi8frm75W/FFHU9N4e28BHEMzzqhyc6FqI14mGrzfNNm0TFJfKKoyEjnKhvg9v1ndCCeXGh1l4AiwhPcW+Q+i/hd99pnBzH4UzBzotw1VdJMg1rzNZ0cNlglknjgf6W19oYKRlzchPYHwFxDGm8ODA1eS8AzlPECHDWufIZQNN0=;
Received: from mailnull by bh-25.webhostbox.net with sa-checked (Exim 4.82)
	(envelope-from <linux@roeck-us.net>) id 1Xne3E-000YD3-PI
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 01:45:52 +0000
Received: from 108-223-40-66.lightspeed.sntcca.sbcglobal.net
	([108.223.40.66]:36324 helo=localhost)
	by bh-25.webhostbox.net with esmtpa (Exim 4.82)
	(envelope-from <linux@roeck-us.net>)
	id 1Xne28-000Veu-OE; Mon, 10 Nov 2014 01:44:46 +0000
From: Guenter Roeck <linux@roeck-us.net>
To: linux-kernel@vger.kernel.org
Date: Sun,  9 Nov 2014 17:42:52 -0800
Message-Id: <1415583785-6980-36-git-send-email-linux@roeck-us.net>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415583785-6980-1-git-send-email-linux@roeck-us.net>
References: <1415583785-6980-1-git-send-email-linux@roeck-us.net>
X-Authenticated_sender: guenter@roeck-us.net
X-OutGoing-Spam-Status: No, score=1.5
X-Spam-Checker-Version: spamc_ctasd client on
	localost
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=50.0 tests=SpamClass_Unknown,
	VirusClass_Unknown autolearn=disabled version=1.0.0
X-CTCH-PVer: 0000001
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-Flags: 0
X-CTCH-RefID: str=0001.0A020206.546018D0.019B, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-Score: 0.000
X-CTCH-ScoreCust: 0.000
X-CTCH-Rules: 
X-CTCH-SenderID: linux@roeck-us.net
X-CTCH-SenderID-Flags: 0
X-CTCH-SenderID-TotalMessages: 299
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 2
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-TotalRecipients: 0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - lists.xenproject.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from
	get_relayhosts_entry
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: linux-samsung-soc@vger.kernel.org, Russell King <linux@arm.linux.org.uk>,
	linux-pm@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com,
	Guenter Roeck <linux@roeck-us.net>,
	xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v6 35/48] arm: Register with kernel power-off
	handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Register with kernel power-off handler instead of setting pm_power_off
directly. Always use register_power_off_handler_simple as there is no
indication that more than one power-off handler is registered.

If the power-off handler only resets the system or puts the CPU in sleep mode,
select the fallback priority to indicate that the power-off handler is one
of last resort. If the power-off handler powers off the system, select the
default priority.

Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v6:
- This patch: No change.
  Global: Replaced priority defines with enum.
v5:
- Rebase to v3.18-rc3
v4:
- No change
v3:
- Replace poweroff in all newly introduced variables and in text
  with power_off or power-off as appropriate
- Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
v2:
- Use defines to specify poweroff handler priorities
- Drop changes in arch/arm/mach-at91/setup.c (file removed upstream)

 arch/arm/kernel/psci.c                         | 3 ++-
 arch/arm/mach-at91/board-gsia18s.c             | 3 ++-
 arch/arm/mach-bcm/board_bcm2835.c              | 3 ++-
 arch/arm/mach-cns3xxx/cns3420vb.c              | 3 ++-
 arch/arm/mach-cns3xxx/core.c                   | 3 ++-
 arch/arm/mach-highbank/highbank.c              | 3 ++-
 arch/arm/mach-imx/mach-mx31moboard.c           | 3 ++-
 arch/arm/mach-iop32x/em7210.c                  | 3 ++-
 arch/arm/mach-iop32x/glantank.c                | 3 ++-
 arch/arm/mach-iop32x/iq31244.c                 | 3 ++-
 arch/arm/mach-iop32x/n2100.c                   | 3 ++-
 arch/arm/mach-ixp4xx/dsmg600-setup.c           | 3 ++-
 arch/arm/mach-ixp4xx/nas100d-setup.c           | 3 ++-
 arch/arm/mach-ixp4xx/nslu2-setup.c             | 3 ++-
 arch/arm/mach-omap2/board-omap3touchbook.c     | 3 ++-
 arch/arm/mach-orion5x/board-mss2.c             | 3 ++-
 arch/arm/mach-orion5x/dns323-setup.c           | 9 ++++++---
 arch/arm/mach-orion5x/kurobox_pro-setup.c      | 3 ++-
 arch/arm/mach-orion5x/ls-chl-setup.c           | 3 ++-
 arch/arm/mach-orion5x/ls_hgl-setup.c           | 3 ++-
 arch/arm/mach-orion5x/lsmini-setup.c           | 3 ++-
 arch/arm/mach-orion5x/mv2120-setup.c           | 3 ++-
 arch/arm/mach-orion5x/net2big-setup.c          | 3 ++-
 arch/arm/mach-orion5x/terastation_pro2-setup.c | 3 ++-
 arch/arm/mach-orion5x/ts209-setup.c            | 3 ++-
 arch/arm/mach-orion5x/ts409-setup.c            | 3 ++-
 arch/arm/mach-pxa/corgi.c                      | 3 ++-
 arch/arm/mach-pxa/mioa701.c                    | 3 ++-
 arch/arm/mach-pxa/poodle.c                     | 3 ++-
 arch/arm/mach-pxa/spitz.c                      | 3 ++-
 arch/arm/mach-pxa/tosa.c                       | 3 ++-
 arch/arm/mach-pxa/viper.c                      | 3 ++-
 arch/arm/mach-pxa/z2.c                         | 7 ++++---
 arch/arm/mach-pxa/zeus.c                       | 7 ++++---
 arch/arm/mach-s3c24xx/mach-gta02.c             | 3 ++-
 arch/arm/mach-s3c24xx/mach-jive.c              | 3 ++-
 arch/arm/mach-s3c24xx/mach-vr1000.c            | 3 ++-
 arch/arm/mach-s3c64xx/mach-smartq.c            | 3 ++-
 arch/arm/mach-sa1100/generic.c                 | 3 ++-
 arch/arm/mach-sa1100/simpad.c                  | 3 ++-
 arch/arm/mach-u300/regulator.c                 | 3 ++-
 arch/arm/mach-vt8500/vt8500.c                  | 3 ++-
 arch/arm/xen/enlighten.c                       | 3 ++-
 43 files changed, 94 insertions(+), 49 deletions(-)

diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index f73891b..a7a2b4a 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -264,7 +264,8 @@ static int psci_0_2_init(struct device_node *np)
 
 	arm_pm_restart = psci_sys_reset;
 
-	pm_power_off = psci_sys_poweroff;
+	register_power_off_handler_simple(psci_sys_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 out_put_node:
 	of_node_put(np);
diff --git a/arch/arm/mach-at91/board-gsia18s.c b/arch/arm/mach-at91/board-gsia18s.c
index bf5cc55..e628c4a 100644
--- a/arch/arm/mach-at91/board-gsia18s.c
+++ b/arch/arm/mach-at91/board-gsia18s.c
@@ -521,7 +521,8 @@ static void gsia18s_power_off(void)
 
 static int __init gsia18s_power_off_init(void)
 {
-	pm_power_off = gsia18s_power_off;
+	register_power_off_handler_simple(gsia18s_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 	return 0;
 }
 
diff --git a/arch/arm/mach-bcm/board_bcm2835.c b/arch/arm/mach-bcm/board_bcm2835.c
index 70f2f39..1d75c76 100644
--- a/arch/arm/mach-bcm/board_bcm2835.c
+++ b/arch/arm/mach-bcm/board_bcm2835.c
@@ -111,7 +111,8 @@ static void __init bcm2835_init(void)
 
 	bcm2835_setup_restart();
 	if (wdt_regs)
-		pm_power_off = bcm2835_power_off;
+		register_power_off_handler_simple(bcm2835_power_off,
+						  POWER_OFF_PRIORITY_FALLBACK);
 
 	bcm2835_init_clocks();
 
diff --git a/arch/arm/mach-cns3xxx/cns3420vb.c b/arch/arm/mach-cns3xxx/cns3420vb.c
index 6428bcc7..5c50461 100644
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -224,7 +224,8 @@ static void __init cns3420_init(void)
 	cns3xxx_ahci_init();
 	cns3xxx_sdhci_init();
 
-	pm_power_off = cns3xxx_power_off;
+	register_power_off_handler_simple(cns3xxx_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 static struct map_desc cns3420_io_desc[] __initdata = {
diff --git a/arch/arm/mach-cns3xxx/core.c b/arch/arm/mach-cns3xxx/core.c
index 4e9837d..9c214cf 100644
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -386,7 +386,8 @@ static void __init cns3xxx_init(void)
 		cns3xxx_pwr_soft_rst(CNS3XXX_PWR_SOFTWARE_RST(SDIO));
 	}
 
-	pm_power_off = cns3xxx_power_off;
+	register_power_off_handler_simple(cns3xxx_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	of_platform_populate(NULL, of_default_bus_match_table,
                         cns3xxx_auxdata, NULL);
diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index 07a0957..6fbdc01 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -155,7 +155,8 @@ static void __init highbank_init(void)
 	sregs_base = of_iomap(np, 0);
 	WARN_ON(!sregs_base);
 
-	pm_power_off = highbank_power_off;
+	register_power_off_handler_simple(highbank_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	highbank_pm_init();
 
 	bus_register_notifier(&platform_bus_type, &highbank_platform_nb);
diff --git a/arch/arm/mach-imx/mach-mx31moboard.c b/arch/arm/mach-imx/mach-mx31moboard.c
index bb6f8a5..3001b14 100644
--- a/arch/arm/mach-imx/mach-mx31moboard.c
+++ b/arch/arm/mach-imx/mach-mx31moboard.c
@@ -559,7 +559,8 @@ static void __init mx31moboard_init(void)
 
 	imx_add_platform_device("imx_mc13783", 0, NULL, 0, NULL, 0);
 
-	pm_power_off = mx31moboard_poweroff;
+	register_power_off_handler_simple(mx31moboard_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	switch (mx31moboard_baseboard) {
 	case MX31NOBOARD:
diff --git a/arch/arm/mach-iop32x/em7210.c b/arch/arm/mach-iop32x/em7210.c
index 77e1ff0..fd3ad09 100644
--- a/arch/arm/mach-iop32x/em7210.c
+++ b/arch/arm/mach-iop32x/em7210.c
@@ -201,7 +201,8 @@ static int __init em7210_request_gpios(void)
 		return 0;
 	}
 
-	pm_power_off = em7210_power_off;
+	register_power_off_handler_simple(em7210_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return 0;
 }
diff --git a/arch/arm/mach-iop32x/glantank.c b/arch/arm/mach-iop32x/glantank.c
index 547b234..9298ea0 100644
--- a/arch/arm/mach-iop32x/glantank.c
+++ b/arch/arm/mach-iop32x/glantank.c
@@ -199,7 +199,8 @@ static void __init glantank_init_machine(void)
 	i2c_register_board_info(0, glantank_i2c_devices,
 		ARRAY_SIZE(glantank_i2c_devices));
 
-	pm_power_off = glantank_power_off;
+	register_power_off_handler_simple(glantank_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(GLANTANK, "GLAN Tank")
diff --git a/arch/arm/mach-iop32x/iq31244.c b/arch/arm/mach-iop32x/iq31244.c
index 0e1392b..50ba54b 100644
--- a/arch/arm/mach-iop32x/iq31244.c
+++ b/arch/arm/mach-iop32x/iq31244.c
@@ -293,7 +293,8 @@ static void __init iq31244_init_machine(void)
 	platform_device_register(&iop3xx_dma_1_channel);
 
 	if (is_ep80219())
-		pm_power_off = ep80219_power_off;
+		register_power_off_handler_simple(ep80219_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (!is_80219())
 		platform_device_register(&iop3xx_aau_channel);
diff --git a/arch/arm/mach-iop32x/n2100.c b/arch/arm/mach-iop32x/n2100.c
index c1cd80e..734a092 100644
--- a/arch/arm/mach-iop32x/n2100.c
+++ b/arch/arm/mach-iop32x/n2100.c
@@ -356,7 +356,8 @@ static void __init n2100_init_machine(void)
 	i2c_register_board_info(0, n2100_i2c_devices,
 		ARRAY_SIZE(n2100_i2c_devices));
 
-	pm_power_off = n2100_power_off;
+	register_power_off_handler_simple(n2100_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(N2100, "Thecus N2100")
diff --git a/arch/arm/mach-ixp4xx/dsmg600-setup.c b/arch/arm/mach-ixp4xx/dsmg600-setup.c
index 43ee06d..f34564d 100644
--- a/arch/arm/mach-ixp4xx/dsmg600-setup.c
+++ b/arch/arm/mach-ixp4xx/dsmg600-setup.c
@@ -281,7 +281,8 @@ static void __init dsmg600_init(void)
 
 	platform_add_devices(dsmg600_devices, ARRAY_SIZE(dsmg600_devices));
 
-	pm_power_off = dsmg600_power_off;
+	register_power_off_handler_simple(dsmg600_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(DSMG600, "D-Link DSM-G600 RevA")
diff --git a/arch/arm/mach-ixp4xx/nas100d-setup.c b/arch/arm/mach-ixp4xx/nas100d-setup.c
index 4e0f762..43a9333 100644
--- a/arch/arm/mach-ixp4xx/nas100d-setup.c
+++ b/arch/arm/mach-ixp4xx/nas100d-setup.c
@@ -292,7 +292,8 @@ static void __init nas100d_init(void)
 
 	platform_add_devices(nas100d_devices, ARRAY_SIZE(nas100d_devices));
 
-	pm_power_off = nas100d_power_off;
+	register_power_off_handler_simple(nas100d_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (request_irq(gpio_to_irq(NAS100D_RB_GPIO), &nas100d_reset_handler,
 		IRQF_TRIGGER_LOW, "NAS100D reset button", NULL) < 0) {
diff --git a/arch/arm/mach-ixp4xx/nslu2-setup.c b/arch/arm/mach-ixp4xx/nslu2-setup.c
index 88c025f..e094d5f 100644
--- a/arch/arm/mach-ixp4xx/nslu2-setup.c
+++ b/arch/arm/mach-ixp4xx/nslu2-setup.c
@@ -262,7 +262,8 @@ static void __init nslu2_init(void)
 
 	platform_add_devices(nslu2_devices, ARRAY_SIZE(nslu2_devices));
 
-	pm_power_off = nslu2_power_off;
+	register_power_off_handler_simple(nslu2_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (request_irq(gpio_to_irq(NSLU2_RB_GPIO), &nslu2_reset_handler,
 		IRQF_TRIGGER_LOW, "NSLU2 reset button", NULL) < 0) {
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
index a01993e..8abce2c 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -344,7 +344,8 @@ static void __init omap3_touchbook_init(void)
 {
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 
-	pm_power_off = omap3_touchbook_poweroff;
+	register_power_off_handler_simple(omap3_touchbook_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (system_rev >= 0x20 && system_rev <= 0x34301000) {
 		omap_mux_init_gpio(23, OMAP_PIN_INPUT);
diff --git a/arch/arm/mach-orion5x/board-mss2.c b/arch/arm/mach-orion5x/board-mss2.c
index 66f9c3b..cac2793 100644
--- a/arch/arm/mach-orion5x/board-mss2.c
+++ b/arch/arm/mach-orion5x/board-mss2.c
@@ -86,5 +86,6 @@ static void mss2_power_off(void)
 void __init mss2_init(void)
 {
 	/* register mss2 specific power-off method */
-	pm_power_off = mss2_power_off;
+	register_power_off_handler_simple(mss2_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 }
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index 09d2a26..9876509 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -669,7 +669,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323a_power_off;
+		register_power_off_handler_simple(dns323a_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 		break;
 	case DNS323_REV_B1:
 		/* 5182 built-in SATA init */
@@ -686,7 +687,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323b_power_off;
+		register_power_off_handler_simple(dns323b_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 		break;
 	case DNS323_REV_C1:
 		/* 5182 built-in SATA init */
@@ -696,7 +698,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323C_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323C_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323c_power_off;
+		register_power_off_handler_simple(dns323c_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 
 		/* Now, -this- should theorically be done by the sata_mv driver
 		 * once I figure out what's going on there. Maybe the behaviour
diff --git a/arch/arm/mach-orion5x/kurobox_pro-setup.c b/arch/arm/mach-orion5x/kurobox_pro-setup.c
index fe6a48a..872d4fe 100644
--- a/arch/arm/mach-orion5x/kurobox_pro-setup.c
+++ b/arch/arm/mach-orion5x/kurobox_pro-setup.c
@@ -376,7 +376,8 @@ static void __init kurobox_pro_init(void)
 	i2c_register_board_info(0, &kurobox_pro_i2c_rtc, 1);
 
 	/* register Kurobox Pro specific power-off method */
-	pm_power_off = kurobox_pro_power_off;
+	register_power_off_handler_simple(kurobox_pro_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 #ifdef CONFIG_MACH_KUROBOX_PRO
diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
index 028ea03..3f540d1 100644
--- a/arch/arm/mach-orion5x/ls-chl-setup.c
+++ b/arch/arm/mach-orion5x/ls-chl-setup.c
@@ -312,7 +312,8 @@ static void __init lschl_init(void)
 	gpio_set_value(LSCHL_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = lschl_power_off;
+	register_power_off_handler_simple(lschl_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c b/arch/arm/mach-orion5x/ls_hgl-setup.c
index 32b7129..699a5a1 100644
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion5x/ls_hgl-setup.c
@@ -259,7 +259,8 @@ static void __init ls_hgl_init(void)
 	gpio_set_value(LS_HGL_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = ls_hgl_power_off;
+	register_power_off_handler_simple(ls_hgl_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/lsmini-setup.c b/arch/arm/mach-orion5x/lsmini-setup.c
index a6493e7..c5712ff 100644
--- a/arch/arm/mach-orion5x/lsmini-setup.c
+++ b/arch/arm/mach-orion5x/lsmini-setup.c
@@ -260,7 +260,8 @@ static void __init lsmini_init(void)
 	gpio_set_value(LSMINI_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = lsmini_power_off;
+	register_power_off_handler_simple(lsmini_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c b/arch/arm/mach-orion5x/mv2120-setup.c
index e032f01..13efbec 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -225,7 +225,8 @@ static void __init mv2120_init(void)
 	if (gpio_request(MV2120_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 	    gpio_direction_output(MV2120_GPIO_POWER_OFF, 1) != 0)
 		pr_err("mv2120: failed to setup power-off GPIO\n");
-	pm_power_off = mv2120_power_off;
+	register_power_off_handler_simple(mv2120_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 /* Warning: HP uses a wrong mach-type (=526) in their bootloader */
diff --git a/arch/arm/mach-orion5x/net2big-setup.c b/arch/arm/mach-orion5x/net2big-setup.c
index ba73dc7..c7648f0 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -413,7 +413,8 @@ static void __init net2big_init(void)
 
 	if (gpio_request(NET2BIG_GPIO_POWER_OFF, "power-off") == 0 &&
 	    gpio_direction_output(NET2BIG_GPIO_POWER_OFF, 0) == 0)
-		pm_power_off = net2big_power_off;
+		register_power_off_handler_simple(net2big_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 	else
 		pr_err("net2big: failed to configure power-off GPIO\n");
 
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c b/arch/arm/mach-orion5x/terastation_pro2-setup.c
index 1208674..227ae91 100644
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
@@ -353,7 +353,8 @@ static void __init tsp2_init(void)
 	i2c_register_board_info(0, &tsp2_i2c_rtc, 1);
 
 	/* register Terastation Pro II specific power-off method */
-	pm_power_off = tsp2_power_off;
+	register_power_off_handler_simple(tsp2_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TERASTATION_PRO2, "Buffalo Terastation Pro II/Live")
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index c725b7c..540e3f3 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -318,7 +318,8 @@ static void __init qnap_ts209_init(void)
 	i2c_register_board_info(0, &qnap_ts209_i2c_rtc, 1);
 
 	/* register tsx09 specific power-off method */
-	pm_power_off = qnap_tsx09_power_off;
+	register_power_off_handler_simple(qnap_tsx09_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TS209, "QNAP TS-109/TS-209")
diff --git a/arch/arm/mach-orion5x/ts409-setup.c b/arch/arm/mach-orion5x/ts409-setup.c
index cf2ab53..40cbdd7 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -307,7 +307,8 @@ static void __init qnap_ts409_init(void)
 	platform_device_register(&ts409_leds);
 
 	/* register tsx09 specific power-off method */
-	pm_power_off = qnap_tsx09_power_off;
+	register_power_off_handler_simple(qnap_tsx09_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TS409, "QNAP TS-409")
diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index 06022b2..93b73a1 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -718,7 +718,8 @@ static void corgi_restart(enum reboot_mode mode, const char *cmd)
 
 static void __init corgi_init(void)
 {
-	pm_power_off = corgi_poweroff;
+	register_power_off_handler_simple(corgi_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	/* Stop 3.6MHz and drive HIGH to PCMCIA and CS */
 	PCFR |= PCFR_OPDE;
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 29997bd..5d318d4 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -750,7 +750,8 @@ static void __init mioa701_machine_init(void)
 	pxa_set_keypad_info(&mioa701_keypad_info);
 	pxa_set_udc_info(&mioa701_udc_info);
 	pxa_set_ac97_info(&mioa701_ac97_info);
-	pm_power_off = mioa701_poweroff;
+	register_power_off_handler_simple(mioa701_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	platform_add_devices(devices, ARRAY_SIZE(devices));
 	gsm_init();
 
diff --git a/arch/arm/mach-pxa/poodle.c b/arch/arm/mach-pxa/poodle.c
index 1319916..749d2af 100644
--- a/arch/arm/mach-pxa/poodle.c
+++ b/arch/arm/mach-pxa/poodle.c
@@ -432,7 +432,8 @@ static void __init poodle_init(void)
 {
 	int ret = 0;
 
-	pm_power_off = poodle_poweroff;
+	register_power_off_handler_simple(poodle_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PCFR |= PCFR_OPDE;
 
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 840c3a4..ab25b6c 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -944,7 +944,8 @@ static void spitz_restart(enum reboot_mode mode, const char *cmd)
 static void __init spitz_init(void)
 {
 	init_gpio_reset(SPITZ_GPIO_ON_RESET, 1, 0);
-	pm_power_off = spitz_poweroff;
+	register_power_off_handler_simple(spitz_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PMCR = 0x00;
 
diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
index c158a6e..8823448 100644
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -940,7 +940,8 @@ static void __init tosa_init(void)
 
 	init_gpio_reset(TOSA_GPIO_ON_RESET, 0, 0);
 
-	pm_power_off = tosa_poweroff;
+	register_power_off_handler_simple(tosa_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PCFR |= PCFR_OPDE;
 
diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index de3b080..6bb4de3 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -919,7 +919,8 @@ static void __init viper_init(void)
 {
 	u8 version;
 
-	pm_power_off = viper_power_off;
+	register_power_off_handler_simple(viper_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	pxa2xx_mfp_config(ARRAY_AND_SIZE(viper_pin_config));
 
diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
index e1a121b..0d0a6ae 100644
--- a/arch/arm/mach-pxa/z2.c
+++ b/arch/arm/mach-pxa/z2.c
@@ -693,8 +693,6 @@ static void z2_power_off(void)
 	pxa27x_set_pwrmode(PWRMODE_DEEPSLEEP);
 	pxa27x_cpu_pm_enter(PM_SUSPEND_MEM);
 }
-#else
-#define z2_power_off   NULL
 #endif
 
 /******************************************************************************
@@ -719,7 +717,10 @@ static void __init z2_init(void)
 	z2_keys_init();
 	z2_pmic_init();
 
-	pm_power_off = z2_power_off;
+#ifdef CONFIG_PM
+	register_power_off_handler_simple(z2_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
+#endif
 }
 
 MACHINE_START(ZIPIT2, "Zipit Z2")
diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index 205f9bf..457eed1 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -690,8 +690,6 @@ static void zeus_power_off(void)
 	local_irq_disable();
 	cpu_suspend(PWRMODE_DEEPSLEEP, pxa27x_finish_suspend);
 }
-#else
-#define zeus_power_off   NULL
 #endif
 
 #ifdef CONFIG_APM_EMULATION
@@ -847,7 +845,10 @@ static void __init zeus_init(void)
 	__raw_writel(msc0, MSC0);
 	__raw_writel(msc1, MSC1);
 
-	pm_power_off = zeus_power_off;
+#ifdef CONFIG_PM
+	register_power_off_handler_simple(zeus_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
+#endif
 	zeus_setup_apm();
 
 	pxa2xx_mfp_config(ARRAY_AND_SIZE(zeus_pin_config));
diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-s3c24xx/mach-gta02.c
index 6d1e0b9..8366b3e 100644
--- a/arch/arm/mach-s3c24xx/mach-gta02.c
+++ b/arch/arm/mach-s3c24xx/mach-gta02.c
@@ -579,7 +579,8 @@ static void __init gta02_machine_init(void)
 	i2c_register_board_info(0, gta02_i2c_devs, ARRAY_SIZE(gta02_i2c_devs));
 
 	platform_add_devices(gta02_devices, ARRAY_SIZE(gta02_devices));
-	pm_power_off = gta02_poweroff;
+	register_power_off_handler_simple(gta02_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	regulator_has_full_constraints();
 }
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c
index 7d99fe8..20beb39 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -657,7 +657,8 @@ static void __init jive_machine_init(void)
 	s3c_i2c0_set_platdata(&jive_i2c_cfg);
 	i2c_register_board_info(0, jive_i2c_devs, ARRAY_SIZE(jive_i2c_devs));
 
-	pm_power_off = jive_power_off;
+	register_power_off_handler_simple(jive_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	platform_add_devices(jive_devices, ARRAY_SIZE(jive_devices));
 }
diff --git a/arch/arm/mach-s3c24xx/mach-vr1000.c b/arch/arm/mach-s3c24xx/mach-vr1000.c
index 89f32bd..1f32ba7 100644
--- a/arch/arm/mach-s3c24xx/mach-vr1000.c
+++ b/arch/arm/mach-s3c24xx/mach-vr1000.c
@@ -306,7 +306,8 @@ static void vr1000_power_off(void)
 
 static void __init vr1000_map_io(void)
 {
-	pm_power_off = vr1000_power_off;
+	register_power_off_handler_simple(vr1000_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	s3c24xx_init_io(vr1000_iodesc, ARRAY_SIZE(vr1000_iodesc));
 	s3c24xx_init_uarts(vr1000_uartcfgs, ARRAY_SIZE(vr1000_uartcfgs));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c b/arch/arm/mach-s3c64xx/mach-smartq.c
index b3d1353..b30906f 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -291,7 +291,8 @@ static int __init smartq_power_off_init(void)
 	/* leave power on */
 	gpio_direction_output(S3C64XX_GPK(15), 0);
 
-	pm_power_off = smartq_power_off;
+	register_power_off_handler_simple(smartq_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return ret;
 }
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index d4ea142..371bffe 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -311,7 +311,8 @@ static struct platform_device *sa11x0_devices[] __initdata = {
 
 static int __init sa1100_init(void)
 {
-	pm_power_off = sa1100_power_off;
+	register_power_off_handler_simple(sa1100_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	return platform_add_devices(sa11x0_devices, ARRAY_SIZE(sa11x0_devices));
 }
 
diff --git a/arch/arm/mach-sa1100/simpad.c b/arch/arm/mach-sa1100/simpad.c
index 41e476e..fb85730 100644
--- a/arch/arm/mach-sa1100/simpad.c
+++ b/arch/arm/mach-sa1100/simpad.c
@@ -373,7 +373,8 @@ static int __init simpad_init(void)
 	if (ret)
 		printk(KERN_WARNING "simpad: Unable to register cs3 GPIO device");
 
-	pm_power_off = simpad_power_off;
+	register_power_off_handler_simple(simpad_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	sa11x0_ppc_configure_mcp();
 	sa11x0_register_mtd(&simpad_flash_data, simpad_flash_resources,
diff --git a/arch/arm/mach-u300/regulator.c b/arch/arm/mach-u300/regulator.c
index 0493a84..4ff09b0 100644
--- a/arch/arm/mach-u300/regulator.c
+++ b/arch/arm/mach-u300/regulator.c
@@ -98,7 +98,8 @@ static int __init __u300_init_boardpower(struct platform_device *pdev)
 			   U300_SYSCON_PMCR_DCON_ENABLE, 0);
 
 	/* Register globally exported PM poweroff hook */
-	pm_power_off = u300_pm_poweroff;
+	register_power_off_handler_simple(u300_pm_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return 0;
 }
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 3bc0dc9..48e4fbf 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -155,7 +155,8 @@ static void __init vt8500_init(void)
 			pr_err("%s:ioremap(power_off) failed\n", __func__);
 	}
 	if (pmc_base)
-		pm_power_off = &vt8500_power_off;
+		register_power_off_handler_simple(vt8500_power_off,
+						  POWER_OFF_PRIORITY_FALLBACK);
 	else
 		pr_err("%s: PMC Hibernation register could not be remapped, not enabling power off!\n", __func__);
 
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e15f01..1c8bce0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -336,7 +336,8 @@ static int __init xen_pm_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	pm_power_off = xen_power_off;
+	register_power_off_handler_simple(xen_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 	arm_pm_restart = xen_restart;
 
 	return 0;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 01:46:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 01:46:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xne3L-00070B-8N; Mon, 10 Nov 2014 01:45:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@roeck-us.net>) id 1Xne3J-0006zw-4J
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 01:45:57 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	5E/26-27623-4D810645; Mon, 10 Nov 2014 01:45:56 +0000
X-Env-Sender: linux@roeck-us.net
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415583953!6997874!1
X-Originating-IP: [208.91.199.152]
X-SpamReason: No, hits=2.2 required=7.0 tests=SUSPICIOUS_RECIPS,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7765 invoked from network); 10 Nov 2014 01:45:54 -0000
Received: from bh-25.webhostbox.net (HELO bh-25.webhostbox.net)
	(208.91.199.152)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 01:45:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roeck-us.net;
	s=default; 
	h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=Md2buJH4GRZCvo6akMqCEv2297VMrVgcCbcHaMlC7AM=; 
	b=Gi8frm75W/FFHU9N4e28BHEMzzqhyc6FqI14mGrzfNNm0TFJfKKoyEjnKhvg9v1ndCCeXGh1l4AiwhPcW+Q+i/hd99pnBzH4UzBzotw1VdJMg1rzNZ0cNlglknjgf6W19oYKRlzchPYHwFxDGm8ODA1eS8AzlPECHDWufIZQNN0=;
Received: from mailnull by bh-25.webhostbox.net with sa-checked (Exim 4.82)
	(envelope-from <linux@roeck-us.net>) id 1Xne3E-000YD3-PI
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 01:45:52 +0000
Received: from 108-223-40-66.lightspeed.sntcca.sbcglobal.net
	([108.223.40.66]:36324 helo=localhost)
	by bh-25.webhostbox.net with esmtpa (Exim 4.82)
	(envelope-from <linux@roeck-us.net>)
	id 1Xne28-000Veu-OE; Mon, 10 Nov 2014 01:44:46 +0000
From: Guenter Roeck <linux@roeck-us.net>
To: linux-kernel@vger.kernel.org
Date: Sun,  9 Nov 2014 17:42:52 -0800
Message-Id: <1415583785-6980-36-git-send-email-linux@roeck-us.net>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415583785-6980-1-git-send-email-linux@roeck-us.net>
References: <1415583785-6980-1-git-send-email-linux@roeck-us.net>
X-Authenticated_sender: guenter@roeck-us.net
X-OutGoing-Spam-Status: No, score=1.5
X-Spam-Checker-Version: spamc_ctasd client on
	localost
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=50.0 tests=SpamClass_Unknown,
	VirusClass_Unknown autolearn=disabled version=1.0.0
X-CTCH-PVer: 0000001
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-Flags: 0
X-CTCH-RefID: str=0001.0A020206.546018D0.019B, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-Score: 0.000
X-CTCH-ScoreCust: 0.000
X-CTCH-Rules: 
X-CTCH-SenderID: linux@roeck-us.net
X-CTCH-SenderID-Flags: 0
X-CTCH-SenderID-TotalMessages: 299
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 2
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-TotalRecipients: 0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - lists.xenproject.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from
	get_relayhosts_entry
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: linux-samsung-soc@vger.kernel.org, Russell King <linux@arm.linux.org.uk>,
	linux-pm@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com,
	Guenter Roeck <linux@roeck-us.net>,
	xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v6 35/48] arm: Register with kernel power-off
	handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Register with kernel power-off handler instead of setting pm_power_off
directly. Always use register_power_off_handler_simple as there is no
indication that more than one power-off handler is registered.

If the power-off handler only resets the system or puts the CPU in sleep mode,
select the fallback priority to indicate that the power-off handler is one
of last resort. If the power-off handler powers off the system, select the
default priority.

Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v6:
- This patch: No change.
  Global: Replaced priority defines with enum.
v5:
- Rebase to v3.18-rc3
v4:
- No change
v3:
- Replace poweroff in all newly introduced variables and in text
  with power_off or power-off as appropriate
- Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
v2:
- Use defines to specify poweroff handler priorities
- Drop changes in arch/arm/mach-at91/setup.c (file removed upstream)

 arch/arm/kernel/psci.c                         | 3 ++-
 arch/arm/mach-at91/board-gsia18s.c             | 3 ++-
 arch/arm/mach-bcm/board_bcm2835.c              | 3 ++-
 arch/arm/mach-cns3xxx/cns3420vb.c              | 3 ++-
 arch/arm/mach-cns3xxx/core.c                   | 3 ++-
 arch/arm/mach-highbank/highbank.c              | 3 ++-
 arch/arm/mach-imx/mach-mx31moboard.c           | 3 ++-
 arch/arm/mach-iop32x/em7210.c                  | 3 ++-
 arch/arm/mach-iop32x/glantank.c                | 3 ++-
 arch/arm/mach-iop32x/iq31244.c                 | 3 ++-
 arch/arm/mach-iop32x/n2100.c                   | 3 ++-
 arch/arm/mach-ixp4xx/dsmg600-setup.c           | 3 ++-
 arch/arm/mach-ixp4xx/nas100d-setup.c           | 3 ++-
 arch/arm/mach-ixp4xx/nslu2-setup.c             | 3 ++-
 arch/arm/mach-omap2/board-omap3touchbook.c     | 3 ++-
 arch/arm/mach-orion5x/board-mss2.c             | 3 ++-
 arch/arm/mach-orion5x/dns323-setup.c           | 9 ++++++---
 arch/arm/mach-orion5x/kurobox_pro-setup.c      | 3 ++-
 arch/arm/mach-orion5x/ls-chl-setup.c           | 3 ++-
 arch/arm/mach-orion5x/ls_hgl-setup.c           | 3 ++-
 arch/arm/mach-orion5x/lsmini-setup.c           | 3 ++-
 arch/arm/mach-orion5x/mv2120-setup.c           | 3 ++-
 arch/arm/mach-orion5x/net2big-setup.c          | 3 ++-
 arch/arm/mach-orion5x/terastation_pro2-setup.c | 3 ++-
 arch/arm/mach-orion5x/ts209-setup.c            | 3 ++-
 arch/arm/mach-orion5x/ts409-setup.c            | 3 ++-
 arch/arm/mach-pxa/corgi.c                      | 3 ++-
 arch/arm/mach-pxa/mioa701.c                    | 3 ++-
 arch/arm/mach-pxa/poodle.c                     | 3 ++-
 arch/arm/mach-pxa/spitz.c                      | 3 ++-
 arch/arm/mach-pxa/tosa.c                       | 3 ++-
 arch/arm/mach-pxa/viper.c                      | 3 ++-
 arch/arm/mach-pxa/z2.c                         | 7 ++++---
 arch/arm/mach-pxa/zeus.c                       | 7 ++++---
 arch/arm/mach-s3c24xx/mach-gta02.c             | 3 ++-
 arch/arm/mach-s3c24xx/mach-jive.c              | 3 ++-
 arch/arm/mach-s3c24xx/mach-vr1000.c            | 3 ++-
 arch/arm/mach-s3c64xx/mach-smartq.c            | 3 ++-
 arch/arm/mach-sa1100/generic.c                 | 3 ++-
 arch/arm/mach-sa1100/simpad.c                  | 3 ++-
 arch/arm/mach-u300/regulator.c                 | 3 ++-
 arch/arm/mach-vt8500/vt8500.c                  | 3 ++-
 arch/arm/xen/enlighten.c                       | 3 ++-
 43 files changed, 94 insertions(+), 49 deletions(-)

diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index f73891b..a7a2b4a 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -264,7 +264,8 @@ static int psci_0_2_init(struct device_node *np)
 
 	arm_pm_restart = psci_sys_reset;
 
-	pm_power_off = psci_sys_poweroff;
+	register_power_off_handler_simple(psci_sys_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 out_put_node:
 	of_node_put(np);
diff --git a/arch/arm/mach-at91/board-gsia18s.c b/arch/arm/mach-at91/board-gsia18s.c
index bf5cc55..e628c4a 100644
--- a/arch/arm/mach-at91/board-gsia18s.c
+++ b/arch/arm/mach-at91/board-gsia18s.c
@@ -521,7 +521,8 @@ static void gsia18s_power_off(void)
 
 static int __init gsia18s_power_off_init(void)
 {
-	pm_power_off = gsia18s_power_off;
+	register_power_off_handler_simple(gsia18s_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 	return 0;
 }
 
diff --git a/arch/arm/mach-bcm/board_bcm2835.c b/arch/arm/mach-bcm/board_bcm2835.c
index 70f2f39..1d75c76 100644
--- a/arch/arm/mach-bcm/board_bcm2835.c
+++ b/arch/arm/mach-bcm/board_bcm2835.c
@@ -111,7 +111,8 @@ static void __init bcm2835_init(void)
 
 	bcm2835_setup_restart();
 	if (wdt_regs)
-		pm_power_off = bcm2835_power_off;
+		register_power_off_handler_simple(bcm2835_power_off,
+						  POWER_OFF_PRIORITY_FALLBACK);
 
 	bcm2835_init_clocks();
 
diff --git a/arch/arm/mach-cns3xxx/cns3420vb.c b/arch/arm/mach-cns3xxx/cns3420vb.c
index 6428bcc7..5c50461 100644
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -224,7 +224,8 @@ static void __init cns3420_init(void)
 	cns3xxx_ahci_init();
 	cns3xxx_sdhci_init();
 
-	pm_power_off = cns3xxx_power_off;
+	register_power_off_handler_simple(cns3xxx_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 static struct map_desc cns3420_io_desc[] __initdata = {
diff --git a/arch/arm/mach-cns3xxx/core.c b/arch/arm/mach-cns3xxx/core.c
index 4e9837d..9c214cf 100644
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -386,7 +386,8 @@ static void __init cns3xxx_init(void)
 		cns3xxx_pwr_soft_rst(CNS3XXX_PWR_SOFTWARE_RST(SDIO));
 	}
 
-	pm_power_off = cns3xxx_power_off;
+	register_power_off_handler_simple(cns3xxx_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	of_platform_populate(NULL, of_default_bus_match_table,
                         cns3xxx_auxdata, NULL);
diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index 07a0957..6fbdc01 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -155,7 +155,8 @@ static void __init highbank_init(void)
 	sregs_base = of_iomap(np, 0);
 	WARN_ON(!sregs_base);
 
-	pm_power_off = highbank_power_off;
+	register_power_off_handler_simple(highbank_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	highbank_pm_init();
 
 	bus_register_notifier(&platform_bus_type, &highbank_platform_nb);
diff --git a/arch/arm/mach-imx/mach-mx31moboard.c b/arch/arm/mach-imx/mach-mx31moboard.c
index bb6f8a5..3001b14 100644
--- a/arch/arm/mach-imx/mach-mx31moboard.c
+++ b/arch/arm/mach-imx/mach-mx31moboard.c
@@ -559,7 +559,8 @@ static void __init mx31moboard_init(void)
 
 	imx_add_platform_device("imx_mc13783", 0, NULL, 0, NULL, 0);
 
-	pm_power_off = mx31moboard_poweroff;
+	register_power_off_handler_simple(mx31moboard_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	switch (mx31moboard_baseboard) {
 	case MX31NOBOARD:
diff --git a/arch/arm/mach-iop32x/em7210.c b/arch/arm/mach-iop32x/em7210.c
index 77e1ff0..fd3ad09 100644
--- a/arch/arm/mach-iop32x/em7210.c
+++ b/arch/arm/mach-iop32x/em7210.c
@@ -201,7 +201,8 @@ static int __init em7210_request_gpios(void)
 		return 0;
 	}
 
-	pm_power_off = em7210_power_off;
+	register_power_off_handler_simple(em7210_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return 0;
 }
diff --git a/arch/arm/mach-iop32x/glantank.c b/arch/arm/mach-iop32x/glantank.c
index 547b234..9298ea0 100644
--- a/arch/arm/mach-iop32x/glantank.c
+++ b/arch/arm/mach-iop32x/glantank.c
@@ -199,7 +199,8 @@ static void __init glantank_init_machine(void)
 	i2c_register_board_info(0, glantank_i2c_devices,
 		ARRAY_SIZE(glantank_i2c_devices));
 
-	pm_power_off = glantank_power_off;
+	register_power_off_handler_simple(glantank_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(GLANTANK, "GLAN Tank")
diff --git a/arch/arm/mach-iop32x/iq31244.c b/arch/arm/mach-iop32x/iq31244.c
index 0e1392b..50ba54b 100644
--- a/arch/arm/mach-iop32x/iq31244.c
+++ b/arch/arm/mach-iop32x/iq31244.c
@@ -293,7 +293,8 @@ static void __init iq31244_init_machine(void)
 	platform_device_register(&iop3xx_dma_1_channel);
 
 	if (is_ep80219())
-		pm_power_off = ep80219_power_off;
+		register_power_off_handler_simple(ep80219_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (!is_80219())
 		platform_device_register(&iop3xx_aau_channel);
diff --git a/arch/arm/mach-iop32x/n2100.c b/arch/arm/mach-iop32x/n2100.c
index c1cd80e..734a092 100644
--- a/arch/arm/mach-iop32x/n2100.c
+++ b/arch/arm/mach-iop32x/n2100.c
@@ -356,7 +356,8 @@ static void __init n2100_init_machine(void)
 	i2c_register_board_info(0, n2100_i2c_devices,
 		ARRAY_SIZE(n2100_i2c_devices));
 
-	pm_power_off = n2100_power_off;
+	register_power_off_handler_simple(n2100_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(N2100, "Thecus N2100")
diff --git a/arch/arm/mach-ixp4xx/dsmg600-setup.c b/arch/arm/mach-ixp4xx/dsmg600-setup.c
index 43ee06d..f34564d 100644
--- a/arch/arm/mach-ixp4xx/dsmg600-setup.c
+++ b/arch/arm/mach-ixp4xx/dsmg600-setup.c
@@ -281,7 +281,8 @@ static void __init dsmg600_init(void)
 
 	platform_add_devices(dsmg600_devices, ARRAY_SIZE(dsmg600_devices));
 
-	pm_power_off = dsmg600_power_off;
+	register_power_off_handler_simple(dsmg600_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(DSMG600, "D-Link DSM-G600 RevA")
diff --git a/arch/arm/mach-ixp4xx/nas100d-setup.c b/arch/arm/mach-ixp4xx/nas100d-setup.c
index 4e0f762..43a9333 100644
--- a/arch/arm/mach-ixp4xx/nas100d-setup.c
+++ b/arch/arm/mach-ixp4xx/nas100d-setup.c
@@ -292,7 +292,8 @@ static void __init nas100d_init(void)
 
 	platform_add_devices(nas100d_devices, ARRAY_SIZE(nas100d_devices));
 
-	pm_power_off = nas100d_power_off;
+	register_power_off_handler_simple(nas100d_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (request_irq(gpio_to_irq(NAS100D_RB_GPIO), &nas100d_reset_handler,
 		IRQF_TRIGGER_LOW, "NAS100D reset button", NULL) < 0) {
diff --git a/arch/arm/mach-ixp4xx/nslu2-setup.c b/arch/arm/mach-ixp4xx/nslu2-setup.c
index 88c025f..e094d5f 100644
--- a/arch/arm/mach-ixp4xx/nslu2-setup.c
+++ b/arch/arm/mach-ixp4xx/nslu2-setup.c
@@ -262,7 +262,8 @@ static void __init nslu2_init(void)
 
 	platform_add_devices(nslu2_devices, ARRAY_SIZE(nslu2_devices));
 
-	pm_power_off = nslu2_power_off;
+	register_power_off_handler_simple(nslu2_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (request_irq(gpio_to_irq(NSLU2_RB_GPIO), &nslu2_reset_handler,
 		IRQF_TRIGGER_LOW, "NSLU2 reset button", NULL) < 0) {
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
index a01993e..8abce2c 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -344,7 +344,8 @@ static void __init omap3_touchbook_init(void)
 {
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 
-	pm_power_off = omap3_touchbook_poweroff;
+	register_power_off_handler_simple(omap3_touchbook_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	if (system_rev >= 0x20 && system_rev <= 0x34301000) {
 		omap_mux_init_gpio(23, OMAP_PIN_INPUT);
diff --git a/arch/arm/mach-orion5x/board-mss2.c b/arch/arm/mach-orion5x/board-mss2.c
index 66f9c3b..cac2793 100644
--- a/arch/arm/mach-orion5x/board-mss2.c
+++ b/arch/arm/mach-orion5x/board-mss2.c
@@ -86,5 +86,6 @@ static void mss2_power_off(void)
 void __init mss2_init(void)
 {
 	/* register mss2 specific power-off method */
-	pm_power_off = mss2_power_off;
+	register_power_off_handler_simple(mss2_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 }
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index 09d2a26..9876509 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -669,7 +669,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323a_power_off;
+		register_power_off_handler_simple(dns323a_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 		break;
 	case DNS323_REV_B1:
 		/* 5182 built-in SATA init */
@@ -686,7 +687,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323b_power_off;
+		register_power_off_handler_simple(dns323b_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 		break;
 	case DNS323_REV_C1:
 		/* 5182 built-in SATA init */
@@ -696,7 +698,8 @@ static void __init dns323_init(void)
 		if (gpio_request(DNS323C_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 		    gpio_direction_output(DNS323C_GPIO_POWER_OFF, 0) != 0)
 			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323c_power_off;
+		register_power_off_handler_simple(dns323c_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 
 		/* Now, -this- should theorically be done by the sata_mv driver
 		 * once I figure out what's going on there. Maybe the behaviour
diff --git a/arch/arm/mach-orion5x/kurobox_pro-setup.c b/arch/arm/mach-orion5x/kurobox_pro-setup.c
index fe6a48a..872d4fe 100644
--- a/arch/arm/mach-orion5x/kurobox_pro-setup.c
+++ b/arch/arm/mach-orion5x/kurobox_pro-setup.c
@@ -376,7 +376,8 @@ static void __init kurobox_pro_init(void)
 	i2c_register_board_info(0, &kurobox_pro_i2c_rtc, 1);
 
 	/* register Kurobox Pro specific power-off method */
-	pm_power_off = kurobox_pro_power_off;
+	register_power_off_handler_simple(kurobox_pro_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 #ifdef CONFIG_MACH_KUROBOX_PRO
diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
index 028ea03..3f540d1 100644
--- a/arch/arm/mach-orion5x/ls-chl-setup.c
+++ b/arch/arm/mach-orion5x/ls-chl-setup.c
@@ -312,7 +312,8 @@ static void __init lschl_init(void)
 	gpio_set_value(LSCHL_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = lschl_power_off;
+	register_power_off_handler_simple(lschl_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c b/arch/arm/mach-orion5x/ls_hgl-setup.c
index 32b7129..699a5a1 100644
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion5x/ls_hgl-setup.c
@@ -259,7 +259,8 @@ static void __init ls_hgl_init(void)
 	gpio_set_value(LS_HGL_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = ls_hgl_power_off;
+	register_power_off_handler_simple(ls_hgl_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/lsmini-setup.c b/arch/arm/mach-orion5x/lsmini-setup.c
index a6493e7..c5712ff 100644
--- a/arch/arm/mach-orion5x/lsmini-setup.c
+++ b/arch/arm/mach-orion5x/lsmini-setup.c
@@ -260,7 +260,8 @@ static void __init lsmini_init(void)
 	gpio_set_value(LSMINI_GPIO_USB_POWER, 1);
 
 	/* register power-off method */
-	pm_power_off = lsmini_power_off;
+	register_power_off_handler_simple(lsmini_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	pr_info("%s: finished\n", __func__);
 }
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c b/arch/arm/mach-orion5x/mv2120-setup.c
index e032f01..13efbec 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -225,7 +225,8 @@ static void __init mv2120_init(void)
 	if (gpio_request(MV2120_GPIO_POWER_OFF, "POWEROFF") != 0 ||
 	    gpio_direction_output(MV2120_GPIO_POWER_OFF, 1) != 0)
 		pr_err("mv2120: failed to setup power-off GPIO\n");
-	pm_power_off = mv2120_power_off;
+	register_power_off_handler_simple(mv2120_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 /* Warning: HP uses a wrong mach-type (=526) in their bootloader */
diff --git a/arch/arm/mach-orion5x/net2big-setup.c b/arch/arm/mach-orion5x/net2big-setup.c
index ba73dc7..c7648f0 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -413,7 +413,8 @@ static void __init net2big_init(void)
 
 	if (gpio_request(NET2BIG_GPIO_POWER_OFF, "power-off") == 0 &&
 	    gpio_direction_output(NET2BIG_GPIO_POWER_OFF, 0) == 0)
-		pm_power_off = net2big_power_off;
+		register_power_off_handler_simple(net2big_power_off,
+						  POWER_OFF_PRIORITY_DEFAULT);
 	else
 		pr_err("net2big: failed to configure power-off GPIO\n");
 
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c b/arch/arm/mach-orion5x/terastation_pro2-setup.c
index 1208674..227ae91 100644
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
@@ -353,7 +353,8 @@ static void __init tsp2_init(void)
 	i2c_register_board_info(0, &tsp2_i2c_rtc, 1);
 
 	/* register Terastation Pro II specific power-off method */
-	pm_power_off = tsp2_power_off;
+	register_power_off_handler_simple(tsp2_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TERASTATION_PRO2, "Buffalo Terastation Pro II/Live")
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index c725b7c..540e3f3 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -318,7 +318,8 @@ static void __init qnap_ts209_init(void)
 	i2c_register_board_info(0, &qnap_ts209_i2c_rtc, 1);
 
 	/* register tsx09 specific power-off method */
-	pm_power_off = qnap_tsx09_power_off;
+	register_power_off_handler_simple(qnap_tsx09_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TS209, "QNAP TS-109/TS-209")
diff --git a/arch/arm/mach-orion5x/ts409-setup.c b/arch/arm/mach-orion5x/ts409-setup.c
index cf2ab53..40cbdd7 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -307,7 +307,8 @@ static void __init qnap_ts409_init(void)
 	platform_device_register(&ts409_leds);
 
 	/* register tsx09 specific power-off method */
-	pm_power_off = qnap_tsx09_power_off;
+	register_power_off_handler_simple(qnap_tsx09_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 }
 
 MACHINE_START(TS409, "QNAP TS-409")
diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index 06022b2..93b73a1 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -718,7 +718,8 @@ static void corgi_restart(enum reboot_mode mode, const char *cmd)
 
 static void __init corgi_init(void)
 {
-	pm_power_off = corgi_poweroff;
+	register_power_off_handler_simple(corgi_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	/* Stop 3.6MHz and drive HIGH to PCMCIA and CS */
 	PCFR |= PCFR_OPDE;
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 29997bd..5d318d4 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -750,7 +750,8 @@ static void __init mioa701_machine_init(void)
 	pxa_set_keypad_info(&mioa701_keypad_info);
 	pxa_set_udc_info(&mioa701_udc_info);
 	pxa_set_ac97_info(&mioa701_ac97_info);
-	pm_power_off = mioa701_poweroff;
+	register_power_off_handler_simple(mioa701_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	platform_add_devices(devices, ARRAY_SIZE(devices));
 	gsm_init();
 
diff --git a/arch/arm/mach-pxa/poodle.c b/arch/arm/mach-pxa/poodle.c
index 1319916..749d2af 100644
--- a/arch/arm/mach-pxa/poodle.c
+++ b/arch/arm/mach-pxa/poodle.c
@@ -432,7 +432,8 @@ static void __init poodle_init(void)
 {
 	int ret = 0;
 
-	pm_power_off = poodle_poweroff;
+	register_power_off_handler_simple(poodle_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PCFR |= PCFR_OPDE;
 
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 840c3a4..ab25b6c 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -944,7 +944,8 @@ static void spitz_restart(enum reboot_mode mode, const char *cmd)
 static void __init spitz_init(void)
 {
 	init_gpio_reset(SPITZ_GPIO_ON_RESET, 1, 0);
-	pm_power_off = spitz_poweroff;
+	register_power_off_handler_simple(spitz_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PMCR = 0x00;
 
diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
index c158a6e..8823448 100644
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -940,7 +940,8 @@ static void __init tosa_init(void)
 
 	init_gpio_reset(TOSA_GPIO_ON_RESET, 0, 0);
 
-	pm_power_off = tosa_poweroff;
+	register_power_off_handler_simple(tosa_poweroff,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	PCFR |= PCFR_OPDE;
 
diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index de3b080..6bb4de3 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -919,7 +919,8 @@ static void __init viper_init(void)
 {
 	u8 version;
 
-	pm_power_off = viper_power_off;
+	register_power_off_handler_simple(viper_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	pxa2xx_mfp_config(ARRAY_AND_SIZE(viper_pin_config));
 
diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
index e1a121b..0d0a6ae 100644
--- a/arch/arm/mach-pxa/z2.c
+++ b/arch/arm/mach-pxa/z2.c
@@ -693,8 +693,6 @@ static void z2_power_off(void)
 	pxa27x_set_pwrmode(PWRMODE_DEEPSLEEP);
 	pxa27x_cpu_pm_enter(PM_SUSPEND_MEM);
 }
-#else
-#define z2_power_off   NULL
 #endif
 
 /******************************************************************************
@@ -719,7 +717,10 @@ static void __init z2_init(void)
 	z2_keys_init();
 	z2_pmic_init();
 
-	pm_power_off = z2_power_off;
+#ifdef CONFIG_PM
+	register_power_off_handler_simple(z2_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
+#endif
 }
 
 MACHINE_START(ZIPIT2, "Zipit Z2")
diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index 205f9bf..457eed1 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -690,8 +690,6 @@ static void zeus_power_off(void)
 	local_irq_disable();
 	cpu_suspend(PWRMODE_DEEPSLEEP, pxa27x_finish_suspend);
 }
-#else
-#define zeus_power_off   NULL
 #endif
 
 #ifdef CONFIG_APM_EMULATION
@@ -847,7 +845,10 @@ static void __init zeus_init(void)
 	__raw_writel(msc0, MSC0);
 	__raw_writel(msc1, MSC1);
 
-	pm_power_off = zeus_power_off;
+#ifdef CONFIG_PM
+	register_power_off_handler_simple(zeus_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
+#endif
 	zeus_setup_apm();
 
 	pxa2xx_mfp_config(ARRAY_AND_SIZE(zeus_pin_config));
diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-s3c24xx/mach-gta02.c
index 6d1e0b9..8366b3e 100644
--- a/arch/arm/mach-s3c24xx/mach-gta02.c
+++ b/arch/arm/mach-s3c24xx/mach-gta02.c
@@ -579,7 +579,8 @@ static void __init gta02_machine_init(void)
 	i2c_register_board_info(0, gta02_i2c_devs, ARRAY_SIZE(gta02_i2c_devs));
 
 	platform_add_devices(gta02_devices, ARRAY_SIZE(gta02_devices));
-	pm_power_off = gta02_poweroff;
+	register_power_off_handler_simple(gta02_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	regulator_has_full_constraints();
 }
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c
index 7d99fe8..20beb39 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -657,7 +657,8 @@ static void __init jive_machine_init(void)
 	s3c_i2c0_set_platdata(&jive_i2c_cfg);
 	i2c_register_board_info(0, jive_i2c_devs, ARRAY_SIZE(jive_i2c_devs));
 
-	pm_power_off = jive_power_off;
+	register_power_off_handler_simple(jive_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	platform_add_devices(jive_devices, ARRAY_SIZE(jive_devices));
 }
diff --git a/arch/arm/mach-s3c24xx/mach-vr1000.c b/arch/arm/mach-s3c24xx/mach-vr1000.c
index 89f32bd..1f32ba7 100644
--- a/arch/arm/mach-s3c24xx/mach-vr1000.c
+++ b/arch/arm/mach-s3c24xx/mach-vr1000.c
@@ -306,7 +306,8 @@ static void vr1000_power_off(void)
 
 static void __init vr1000_map_io(void)
 {
-	pm_power_off = vr1000_power_off;
+	register_power_off_handler_simple(vr1000_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	s3c24xx_init_io(vr1000_iodesc, ARRAY_SIZE(vr1000_iodesc));
 	s3c24xx_init_uarts(vr1000_uartcfgs, ARRAY_SIZE(vr1000_uartcfgs));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c b/arch/arm/mach-s3c64xx/mach-smartq.c
index b3d1353..b30906f 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -291,7 +291,8 @@ static int __init smartq_power_off_init(void)
 	/* leave power on */
 	gpio_direction_output(S3C64XX_GPK(15), 0);
 
-	pm_power_off = smartq_power_off;
+	register_power_off_handler_simple(smartq_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return ret;
 }
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index d4ea142..371bffe 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -311,7 +311,8 @@ static struct platform_device *sa11x0_devices[] __initdata = {
 
 static int __init sa1100_init(void)
 {
-	pm_power_off = sa1100_power_off;
+	register_power_off_handler_simple(sa1100_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 	return platform_add_devices(sa11x0_devices, ARRAY_SIZE(sa11x0_devices));
 }
 
diff --git a/arch/arm/mach-sa1100/simpad.c b/arch/arm/mach-sa1100/simpad.c
index 41e476e..fb85730 100644
--- a/arch/arm/mach-sa1100/simpad.c
+++ b/arch/arm/mach-sa1100/simpad.c
@@ -373,7 +373,8 @@ static int __init simpad_init(void)
 	if (ret)
 		printk(KERN_WARNING "simpad: Unable to register cs3 GPIO device");
 
-	pm_power_off = simpad_power_off;
+	register_power_off_handler_simple(simpad_power_off,
+					  POWER_OFF_PRIORITY_FALLBACK);
 
 	sa11x0_ppc_configure_mcp();
 	sa11x0_register_mtd(&simpad_flash_data, simpad_flash_resources,
diff --git a/arch/arm/mach-u300/regulator.c b/arch/arm/mach-u300/regulator.c
index 0493a84..4ff09b0 100644
--- a/arch/arm/mach-u300/regulator.c
+++ b/arch/arm/mach-u300/regulator.c
@@ -98,7 +98,8 @@ static int __init __u300_init_boardpower(struct platform_device *pdev)
 			   U300_SYSCON_PMCR_DCON_ENABLE, 0);
 
 	/* Register globally exported PM poweroff hook */
-	pm_power_off = u300_pm_poweroff;
+	register_power_off_handler_simple(u300_pm_poweroff,
+					  POWER_OFF_PRIORITY_DEFAULT);
 
 	return 0;
 }
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 3bc0dc9..48e4fbf 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -155,7 +155,8 @@ static void __init vt8500_init(void)
 			pr_err("%s:ioremap(power_off) failed\n", __func__);
 	}
 	if (pmc_base)
-		pm_power_off = &vt8500_power_off;
+		register_power_off_handler_simple(vt8500_power_off,
+						  POWER_OFF_PRIORITY_FALLBACK);
 	else
 		pr_err("%s: PMC Hibernation register could not be remapped, not enabling power off!\n", __func__);
 
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e15f01..1c8bce0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -336,7 +336,8 @@ static int __init xen_pm_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	pm_power_off = xen_power_off;
+	register_power_off_handler_simple(xen_power_off,
+					  POWER_OFF_PRIORITY_DEFAULT);
 	arm_pm_restart = xen_restart;
 
 	return 0;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 05:12:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 05:12:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnhGi-000128-Dz; Mon, 10 Nov 2014 05:12:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1XnhGg-000123-9v
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 05:11:58 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	B8/2D-27785-D1940645; Mon, 10 Nov 2014 05:11:57 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415596314!12385118!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13295 invoked from network); 10 Nov 2014 05:11:55 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-27.messagelabs.com with SMTP;
	10 Nov 2014 05:11:55 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 09 Nov 2014 21:11:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,350,1413270000"; d="scan'208";a="619777192"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by fmsmga001.fm.intel.com with ESMTP; 09 Nov 2014 21:11:38 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 10 Nov 2014 13:08:12 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.62]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.130]) with mapi id
	14.03.0195.001; Mon, 10 Nov 2014 13:08:10 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jan Beulich
	<JBeulich@suse.com>
Thread-Topic: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
	disables it.
Thread-Index: AQHPEi3cJLkYs2VhL0qN3zw8dITRcJxbIWYA
Date: Mon, 10 Nov 2014 05:08:09 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABD8C46@SHSMSX104.ccr.corp.intel.com>
References: <20140110184151.GA20232@pegasus.dumpdata.com>
	<1389607803.8187.22.camel@kazak.uk.xensource.com>
	<52D3DC730200007800112FF6@nat28.tlf.novell.com>
	<1389613109.13654.43.camel@kazak.uk.xensource.com>
	<52D3E1500200007800113058@nat28.tlf.novell.com>
	<20140115200736.GB5201@phenom.dumpdata.com>
In-Reply-To: <20140115200736.GB5201@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: Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Li, Liang Z" <liang.z.li@intel.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables 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

Konrad Rzeszutek Wilk wrote on 2014-01-16:
> On Mon, Jan 13, 2014 at 11:51:28AM +0000, Jan Beulich wrote:
>>>>> On 13.01.14 at 12:38, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> On Mon, 2014-01-13 at 11:30 +0000, Jan Beulich wrote:
>>>> In fact I can't see where this would be forced off:
>>>> xc_cpuid_x86.c only does so in the PV case, and all
>>>> hvm_pse1gb_supported() is that the CPU supports it and the domain uses HAP.
>>> 
>>> Took me a while to spot it too:
>>> static void intel_xc_cpuid_policy( [...]
>>>             case 0x80000001: {
>>>                 int is_64bit = hypervisor_is_64bit(xch) && is_pae;
>>>                 
>>>                 /* Only a few features are advertised in Intel's
>>>                 0x80000001. */ regs[2] &= (is_64bit ?
> bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
>>> 
> bitmaskof(X86_FEATURE_ABM);
>>>                 regs[3] &= ((is_pae ? bitmaskof(X86_FEATURE_NX) :
>>> 0)
> |
>>>                             (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0)
>>>                             | (is_64bit ?
>>>                             bitmaskof(X86_FEATURE_SYSCALL) : 0) |
>>>                             (is_64bit ?
> bitmaskof(X86_FEATURE_RDTSCP) : 0));
>>>                 break;
>>>             }
>>> 
>>> Which masks anything which is not explicitly mentioned. (PAGE1GB
>>> is in regs[3], I think).
>> 
>> Ah, okay. The funs of white listing on HVM vs black listing on PV
>> again.
>> 
>>> The AMD version is more permissive:
>>> 
>>>         regs[3] &= (0x0183f3ff | /* features shared with
> 0x00000001:EDX */
>>>                     (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
>>>                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
>>>                     bitmaskof(X86_FEATURE_SYSCALL) |
>>>                     bitmaskof(X86_FEATURE_MP) |
>>>                     bitmaskof(X86_FEATURE_MMXEXT) |
>>>                     bitmaskof(X86_FEATURE_FFXSR) |
>>>                     bitmaskof(X86_FEATURE_3DNOW) |
>>>                     bitmaskof(X86_FEATURE_3DNOWEXT));
>>> (but I didn't check if PAGE1GB is in that magic number...)
>> 
>> It's not - it's bit 26.
> 
> So.. it sounds to me like everybody is in the agreement that this is
> the right thing to do (enable it if the hypervisor has it enabled)?
> 
> And the next thing is actually come up with a patch to do some of this
> plumbing - naturally for Xen 4.5?

Hi, Konrad,

Is there any patch to turn on the 1GB hugepages? If no, we are happy to give a patch to do it.

>> 
>> Jan
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 05:12:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 05:12:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnhGi-000128-Dz; Mon, 10 Nov 2014 05:12:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1XnhGg-000123-9v
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 05:11:58 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	B8/2D-27785-D1940645; Mon, 10 Nov 2014 05:11:57 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415596314!12385118!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13295 invoked from network); 10 Nov 2014 05:11:55 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-27.messagelabs.com with SMTP;
	10 Nov 2014 05:11:55 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 09 Nov 2014 21:11:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,350,1413270000"; d="scan'208";a="619777192"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by fmsmga001.fm.intel.com with ESMTP; 09 Nov 2014 21:11:38 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 10 Nov 2014 13:08:12 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.62]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.130]) with mapi id
	14.03.0195.001; Mon, 10 Nov 2014 13:08:10 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jan Beulich
	<JBeulich@suse.com>
Thread-Topic: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
	disables it.
Thread-Index: AQHPEi3cJLkYs2VhL0qN3zw8dITRcJxbIWYA
Date: Mon, 10 Nov 2014 05:08:09 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABD8C46@SHSMSX104.ccr.corp.intel.com>
References: <20140110184151.GA20232@pegasus.dumpdata.com>
	<1389607803.8187.22.camel@kazak.uk.xensource.com>
	<52D3DC730200007800112FF6@nat28.tlf.novell.com>
	<1389613109.13654.43.camel@kazak.uk.xensource.com>
	<52D3E1500200007800113058@nat28.tlf.novell.com>
	<20140115200736.GB5201@phenom.dumpdata.com>
In-Reply-To: <20140115200736.GB5201@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: Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Li, Liang Z" <liang.z.li@intel.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables 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

Konrad Rzeszutek Wilk wrote on 2014-01-16:
> On Mon, Jan 13, 2014 at 11:51:28AM +0000, Jan Beulich wrote:
>>>>> On 13.01.14 at 12:38, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> On Mon, 2014-01-13 at 11:30 +0000, Jan Beulich wrote:
>>>> In fact I can't see where this would be forced off:
>>>> xc_cpuid_x86.c only does so in the PV case, and all
>>>> hvm_pse1gb_supported() is that the CPU supports it and the domain uses HAP.
>>> 
>>> Took me a while to spot it too:
>>> static void intel_xc_cpuid_policy( [...]
>>>             case 0x80000001: {
>>>                 int is_64bit = hypervisor_is_64bit(xch) && is_pae;
>>>                 
>>>                 /* Only a few features are advertised in Intel's
>>>                 0x80000001. */ regs[2] &= (is_64bit ?
> bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
>>> 
> bitmaskof(X86_FEATURE_ABM);
>>>                 regs[3] &= ((is_pae ? bitmaskof(X86_FEATURE_NX) :
>>> 0)
> |
>>>                             (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0)
>>>                             | (is_64bit ?
>>>                             bitmaskof(X86_FEATURE_SYSCALL) : 0) |
>>>                             (is_64bit ?
> bitmaskof(X86_FEATURE_RDTSCP) : 0));
>>>                 break;
>>>             }
>>> 
>>> Which masks anything which is not explicitly mentioned. (PAGE1GB
>>> is in regs[3], I think).
>> 
>> Ah, okay. The funs of white listing on HVM vs black listing on PV
>> again.
>> 
>>> The AMD version is more permissive:
>>> 
>>>         regs[3] &= (0x0183f3ff | /* features shared with
> 0x00000001:EDX */
>>>                     (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
>>>                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
>>>                     bitmaskof(X86_FEATURE_SYSCALL) |
>>>                     bitmaskof(X86_FEATURE_MP) |
>>>                     bitmaskof(X86_FEATURE_MMXEXT) |
>>>                     bitmaskof(X86_FEATURE_FFXSR) |
>>>                     bitmaskof(X86_FEATURE_3DNOW) |
>>>                     bitmaskof(X86_FEATURE_3DNOWEXT));
>>> (but I didn't check if PAGE1GB is in that magic number...)
>> 
>> It's not - it's bit 26.
> 
> So.. it sounds to me like everybody is in the agreement that this is
> the right thing to do (enable it if the hypervisor has it enabled)?
> 
> And the next thing is actually come up with a patch to do some of this
> plumbing - naturally for Xen 4.5?

Hi, Konrad,

Is there any patch to turn on the 1GB hugepages? If no, we are happy to give a patch to do it.

>> 
>> Jan
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 05:27:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 05: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 1XnhVI-0001Dd-5Y; Mon, 10 Nov 2014 05:27:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1XnhVG-0001DY-Uy
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 05:27:03 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	36/94-02697-6AC40645; Mon, 10 Nov 2014 05:27:02 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415597220!11449295!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4432 invoked from network); 10 Nov 2014 05:27:01 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-13.tower-206.messagelabs.com with SMTP;
	10 Nov 2014 05:27:01 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43116062"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 10 Nov 2014 13:23:04 +0800
Received: from G08CNEXCHPEKD03.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAA5Q3xR000589
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 13:26:03 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 10 Nov 2014 13:26:15 +0800
Message-ID: <54604CEA.1060909@cn.fujitsu.com>
Date: Mon, 10 Nov 2014 13:28:10 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen devel <xen-devel@lists.xen.org>
X-Originating-IP: [10.167.226.91]
Subject: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 disable xen-platform-pci in the config file, but when I start the guest, I found
the following kernel message:
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled

Thanks
Wen Congyang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 05:27:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 05: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 1XnhVI-0001Dd-5Y; Mon, 10 Nov 2014 05:27:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1XnhVG-0001DY-Uy
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 05:27:03 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	36/94-02697-6AC40645; Mon, 10 Nov 2014 05:27:02 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415597220!11449295!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4432 invoked from network); 10 Nov 2014 05:27:01 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-13.tower-206.messagelabs.com with SMTP;
	10 Nov 2014 05:27:01 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43116062"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 10 Nov 2014 13:23:04 +0800
Received: from G08CNEXCHPEKD03.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAA5Q3xR000589
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 13:26:03 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 10 Nov 2014 13:26:15 +0800
Message-ID: <54604CEA.1060909@cn.fujitsu.com>
Date: Mon, 10 Nov 2014 13:28:10 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen devel <xen-devel@lists.xen.org>
X-Originating-IP: [10.167.226.91]
Subject: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 disable xen-platform-pci in the config file, but when I start the guest, I found
the following kernel message:
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled

Thanks
Wen Congyang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 07:16:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 07:16:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnjCl-0002B5-SG; Mon, 10 Nov 2014 07:16:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnjCj-0002B0-4T
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 07:16:02 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	27/CB-02702-03660645; Mon, 10 Nov 2014 07:16:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415603758!9059011!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25776 invoked from network); 10 Nov 2014 07:15:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 07:15:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="191096896"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 02:15:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnjCe-0004Lh-GC;
	Mon, 10 Nov 2014 07:15:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnjCe-0002cY-7J;
	Mon, 10 Nov 2014 07:15:56 +0000
Date: Mon, 10 Nov 2014 07:15:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31458-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31458: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31458 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31458/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Mon Nov 10 07:16:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 07:16:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnjCl-0002B5-SG; Mon, 10 Nov 2014 07:16:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnjCj-0002B0-4T
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 07:16:02 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	27/CB-02702-03660645; Mon, 10 Nov 2014 07:16:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415603758!9059011!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25776 invoked from network); 10 Nov 2014 07:15:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 07:15:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="191096896"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 02:15:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnjCe-0004Lh-GC;
	Mon, 10 Nov 2014 07:15:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnjCe-0002cY-7J;
	Mon, 10 Nov 2014 07:15:56 +0000
Date: Mon, 10 Nov 2014 07:15:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31458-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31458: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31458 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31458/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Mon Nov 10 08:04:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnjxA-00030F-TO; Mon, 10 Nov 2014 08:04:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xnjx9-00030A-7T
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:03:59 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	33/09-02953-E6170645; Mon, 10 Nov 2014 08:03:58 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415606636!12366027!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20160 invoked from network); 10 Nov 2014 08:03:57 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:03:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415606636; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=DjC1zHEWHSak6SARRmbbUYwYHt7TIcIw53Uk2Mh/enY=;
	b=xkSfoCetijzwwWPFMJzN8xnTyvfH3DyNTzeVTrfu/Ybr6RHhNUSXRBzM7N4Mv+qYesBh94K6vU+eCuJlFyQD1cN4bp6Jd7fCGGf4xtMwZ/iOejcq4twStCGdbZpWpMcY5zUS3MHkKjxSYvqFkGToI+NuIou96Yjgj9fj8Lqc6sY=
Received: from [10.0.0.112] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 10 Nov 2014 00:03:55 -0800
	id 00000000000305E3.5460716B.000056CD
Message-ID: <5460716A.7090905@ihonk.com>
Date: Mon, 10 Nov 2014 00:03:54 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>,
	=?windows-1252?Q?Pasi_K=E4rkk=E4in?= =?windows-1252?Q?en?= <pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
In-Reply-To: <5458B55C0200007800044B33@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2014 02:15 AM, Jan Beulich wrote:
> In fact this would not just be nice, but is strictly needed, and (as
> with any pass-through related problems) additionally requires
> running with "iommu=debug" alongside the usual need of setting
> the log levels to the maximum.
>

Hi all,

Sorry for the delay, took some debugging on another computer to get 
serial logging working. Due to its size, I've posted the entire log of a 
crashed session here: http://pastebin.com/AiPHUZRH In this case I used a 
3.0 gig memory size for the Windows domU.

As I mentioned before, sometimes it's the SATA that goes first, other 
times the tg3 ethernet driver. Also note that between 4.4.1 and 4.5rc1, 
the kernel I'm using (stock Debian Jessie) has not changed.

Please let me know if you need any other information. Thanks!

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:04:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnjxA-00030F-TO; Mon, 10 Nov 2014 08:04:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xnjx9-00030A-7T
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:03:59 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	33/09-02953-E6170645; Mon, 10 Nov 2014 08:03:58 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415606636!12366027!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20160 invoked from network); 10 Nov 2014 08:03:57 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:03:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415606636; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=DjC1zHEWHSak6SARRmbbUYwYHt7TIcIw53Uk2Mh/enY=;
	b=xkSfoCetijzwwWPFMJzN8xnTyvfH3DyNTzeVTrfu/Ybr6RHhNUSXRBzM7N4Mv+qYesBh94K6vU+eCuJlFyQD1cN4bp6Jd7fCGGf4xtMwZ/iOejcq4twStCGdbZpWpMcY5zUS3MHkKjxSYvqFkGToI+NuIou96Yjgj9fj8Lqc6sY=
Received: from [10.0.0.112] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 10 Nov 2014 00:03:55 -0800
	id 00000000000305E3.5460716B.000056CD
Message-ID: <5460716A.7090905@ihonk.com>
Date: Mon, 10 Nov 2014 00:03:54 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>,
	=?windows-1252?Q?Pasi_K=E4rkk=E4in?= =?windows-1252?Q?en?= <pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
In-Reply-To: <5458B55C0200007800044B33@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2014 02:15 AM, Jan Beulich wrote:
> In fact this would not just be nice, but is strictly needed, and (as
> with any pass-through related problems) additionally requires
> running with "iommu=debug" alongside the usual need of setting
> the log levels to the maximum.
>

Hi all,

Sorry for the delay, took some debugging on another computer to get 
serial logging working. Due to its size, I've posted the entire log of a 
crashed session here: http://pastebin.com/AiPHUZRH In this case I used a 
3.0 gig memory size for the Windows domU.

As I mentioned before, sometimes it's the SATA that goes first, other 
times the tg3 ethernet driver. Also note that between 4.4.1 and 4.5rc1, 
the kernel I'm using (stock Debian Jessie) has not changed.

Please let me know if you need any other information. Thanks!

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:18:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnkAS-0003CR-PA; Mon, 10 Nov 2014 08:17:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XnkAR-0003C6-W6
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:17:44 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	1B/6E-02702-7A470645; Mon, 10 Nov 2014 08:17:43 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415607459!12418302!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24811 invoked from network); 10 Nov 2014 08:17:42 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:17:42 -0000
Received: from linux-tt8j.gns.novell.com (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 10 Nov 2014 01:17:31 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:17:03 +0800
Message-Id: <1415607424-15920-3-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415607424-15920-1-git-send-email-cyliu@suse.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

changes to V7:
  * remove libxl_domain_snapshot_revert API
  * about libxl_domain_snapshot_delete, disk snapshot part
    could be extracted to libxlu if we would support many kinds of
    disk backendtypes in future. Add words to the docs, but not
    extended. Basic goal will support only raw and qcow2.
  * remove all disk-only descriptions. Won't support disk-only
    snapshot in xl and libxl.

===========================================================================
Libxl Domain Snapshot API

1. New Structures

libxl_disk_snapshot = Struct("disk_snapshot",[
    # target disk
    ("disk",            libxl_device_disk),

    # disk snapshot name
    ("name",            string),

    # internal/external disk snapshot?
    ("external",        bool),

    # for external disk snapshot, specify following two field
    ("external_format", string),
    ("external_path",   string),
    ])

libxl_domain_snapshot_args = Struct("domain_snapshot_args",[
    # memory state path
    ("memory_path",   string),

    # array to store disk snapshot info
    ("disks",         Array(libxl_disk_snapshot, "num_disks")),
    ]

2. New Functions

int libxl_domain_snapshot_create(libxl_ctx *ctx, int domid,
                                 libxl_domain_snapshot_args *snapshot,
                                 bool live)

    Creates a new snapshot of a domain based on the snapshot config contained
    in @snapshot. Save domain and do disk snapshot.

    ctx (INPUT): context
    domid (INPUT):  domain id
    snapshot (INPUT): configuration of domain snapshot
    live (INPUT):   live snapshot or not
    Returns: 0 on success, -1 on failure

    ctx:
       context.

    domid:
       domid of the domain.

    live:
       true or false.
       when live is 'true', domain is not paused while creating the snapshot,
       like live migration. This increases size of the memory dump file, but
       reducess downtime of the guest.

    snapshot:
       memory_path:
           path to save memory state.
       num_disks:
           number of disks that need to take disk snapshot.
       disks:
           array of disk snapshot configuration. Has num_disks members.
           libxl_device_disk:
               structure to represent which disk.
           name:
               snapshot name.
           external:
               true or flase.
               'false' means internal disk snapshot. external_format and
               external_path will be ignored.
               'true' means external disk snapshot, then external_format and
               external_path should be provided.
          external_format:
              Should be provided when 'external' is true. If not provided, will
              use default format proper to the backend file.
              Ignored when 'external' is false.
          external_path:
              Must be provided when 'external' is true.
              Ignored when 'external' is false.


int libxl_domain_snapshot_delete(libxl_ctx *ctx, int domid,
                                 libxl_domain_snapshot_args *snapshot);

    Delete a snapshot.
    This will delete the related memory state file and disk snapshots.

    ctx (INPUT): context
    domid (INPUT): domain id
    snapshot (INPUT): domain snapshot related info
    Returns: 0 on success, -1 on error.

    About each input, explanation is the same as libxl_domain_snapshot_create.


libxl_domain_snapshot_revert API will not be provided. Considering that:
    domain snapshot revert work could be done by destroying the domain
    and then restore a new domain from the snapshot. Application could
    do that by themselves. If wrapped as an libxl API, the new domain
    will not be awared by libvirt, causing problems in libvirt, worse
    than better.

3. Function Implementation

   libxl_domain_snapshot_create:
       1). check args validation
       2). save domain memory through save-domain
       3). take disk snapshot by qmp command (if domian is active) or qemu-img
           command (if domain is inactive).

   libxl_domain_snapshot_delete:
       1). check args validation
       2). remove memory state file.
       3). delete disk snapshot. (for internal disk snapshot, through qmp
           command or qemu-img command)

   To handle disk snapshot (disk snapshot create or delete) of different
   disk backend types, this work could be extracted to libxlu in future.
   (Base goal would support raw and qcow2 types only, as currently kvm does).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:18:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnkAS-0003CK-Cf; Mon, 10 Nov 2014 08:17:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XnkAR-0003C1-6e
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:17:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	92/7A-09936-6A470645; Mon, 10 Nov 2014 08:17:42 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415607460!12639027!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14793 invoked from network); 10 Nov 2014 08:17:41 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:17:41 -0000
Received: from linux-tt8j.gns.novell.com (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 10 Nov 2014 01:17:29 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:17:02 +0800
Message-Id: <1415607424-15920-2-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415607424-15920-1-git-send-email-cyliu@suse.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V8 1/3] libxl domain snapshot introduction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes to V7:
  * update the words a little to avoid confusing in v6.

===========================================================================
Domain snapshot includes disk snapshots and domain state saving. domain
could be resumed to the very state when the snapshot was created. This
kind of snapshot is also referred to as a domain checkpoint or system
checkpoint. It's consistent.

Disk snapshot is inconsistent if the domain is running. To libxl,
even domain is paused, there is no data flush to disk operation. So, for
active domain (domain is started), take a disk-only snapshot and then
resume, it is as if the guest had crashed. For this reason, we won't
support disk-only snapshot in libxl.

Within domain snapshot, disk snapshot could be "internal" (like in qcow2
format, snapshot and delta are both in one image file), or "external"
(snapshot in one file, delta in another).

Expected 4 types of operations:

"domain snapshot create":
    means saving domain state (if not disk-only) and doing disk snapshots.

"domain snapshot revert":
    means rolling back to the state of indicated snapshot.

"domain snapshot delete":
    delete indicated domain snapshot.

"domain snapshot list":
    list domain snapshot information.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:18:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnkAg-0003Ez-Aw; Mon, 10 Nov 2014 08:17:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XnkAf-0003EW-AL
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:17:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B7/2F-09842-4B470645; Mon, 10 Nov 2014 08:17:56 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415607474!12599709!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22516 invoked from network); 10 Nov 2014 08:17:55 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:17:55 -0000
Received: from linux-tt8j.gns.novell.com (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 10 Nov 2014 01:17:36 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:17:04 +0800
Message-Id: <1415607424-15920-4-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415607424-15920-1-git-send-email-cyliu@suse.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V8 3/3] xl snapshot-xxx Design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes to V7:
  * change wrong libxl_domain_snapshot_info naming to xl_domain_snapshot_info
  * remove all disk-only syntax
  * update xl snapshot-revert implementaion

===========================================================================
1. xl commandline interface design

xl snapshot-create:
  Create a snapshot (disk and RAM) of a domain.

  SYNOPSIS:
    snapshot-create <domain> [<cfgfile>] [--name <string>] [--live]

  OPTIONS:
    --name <string>  snapshot name
    --live           take a live snapshot

    If option includes --live, then the domain is not paused while creating
    the snapshot, like live migration. This increases size of the memory
    dump file, but reducess downtime of the guest.

    If option doens't include --name, a default name will be generated
    according to the creation time.

    If specify @cfgfile, cfgfile is prioritized. (e.g. if --name specifies
    a name, meanwhile there is name info in cfgfile, name in cfgfile will
    be used.)

xl snapshot-delete:
  Delete a snapshot (disk and RAM) of a domain.

  SYNOPSIS:
    snapshot-delete <domain> <snapshotname> [--children] [--children-only]

    By default, just this snapshot is deleted, and changes from this
    snapshot are automatically merged into children snapshots.

  OPTIONS:
    --children       delete snapshot and all children
    --children-only  delete children but not snapshot

    If option includes --children, then this snapshot and any descendant
    snapshots are deleted.

    If option include --children-only, only descendant snapshots are deleted,
    this snapshot is not deleted.

xl snapshot-revert:
  Revert domain to status of a snapshot.

  SYNOPSIS:
      snapshot-revert <domain> <snapshotname> [--running] [--paused] [--force]

  OPTIONS:
    --running        after reverting, change state to running
    --paused         after reverting, change state to paused
    --force          try harder on risky reverts

    Normally, the domain will revert to the same state the domain was in while
    the snapshot was taken (whether running, or paused).

    If option includes --running, then overrides the snapshot state to
    guarantee a running domain after the revert.

    If option includes --paused, then guarantees a paused domain after
    the revert.

xl snapshot-list:
  List snapshots for a domain.

  SYNOPSIS:
    snapshot-list <domain> [--parent] [--internal] [--external]
    [--tree] [--name]

  OPTIONS:
    --internal       filter by internal snapshots
    --external       filter by external snapshots
    --tree           list snapshots in a tree
    --parent         add a column showing parent snapshot
    --name           list snapshot names only

2. cfgfile syntax

"xl snapshot-create" supports creating a VM snapshot with user provided
configuration file. The configuration file syntax is as below:

#snapshot name. If user doesn't provide a VM snapshot name, xl will generate
#a name automatically by the creation time.
name=""

#snapshot description. Default is NULL.
description=""

#memory location. This field should be filled when memory=1. Default is NULL.
memory_path=""

#disk snapshot information
disks=['sda,1,qcow2,/tmp/sda_snapshot.qcow2','sdb,1,qcow2,/tmp/sda_snapshot.qcow2']
or
disks=['sda,0','sdb,0']

disk syntax:
'target device, external disk snapshot?, external format, external path'

3. xl structure to maintain VM snapshot info

xl_domain_snapshot_info = Struct("domain_snapshot_info",[
    # snapshot name
    ("name",          string)

    ("create_time",   string)
    ("description",   string)

    # memory path and disk snapshot info
    ("snapshot_args", libxl_domain_snapshot_args),

    # parent snapshot name
    ("parent",        string),

    # array to store all children snapshot name
    ("children",      Array(string, "num_children"),
    ]

According to xl_domain_snapshot_info, a json file will be saved on disk.

4. xl snapshot-xxx implementation details

"xl snapshot-create"

    1), parse args or domain snapshot configuration file.
    2), fill info in libxl_domain_snapshot_args struct according to
        options or config file.
    3), call libxl_domain_snapshot_create()
    4), fill info in xl_domain_snapshot_info.
    5), save snapshot info in json file under                                                             "/var/lib/xen/snapshots/domain_uuid"

"xl snapshot-list"

    1), read all domain snapshot related json file under
        "/var/lib/xen/snapshots/domain_uuid". Parse each file and fill in
        xl_domain_snapshot_info struct.
    2), display information from those xl_domain_snapshot_info(s)

"xl snapshot-delete"

    1), read snapshot json file from
        "/var/lib/xen/snapshots/domain_uuid/snapshotdata-<snapshot_name>\
        .libxl-json", parse the file and fill in xl_domain_snapshot_info
    2), according to parent/children info in xl_domain_snapshot_info
        and commandline options, decide which domain snapshot to be deleted.
        To delete each domain snapshot, fill in
        libxl_domain_snapshot_args and call libxl_domain_snapshot_delete().
    3), refresh parent/children relationship, delete json file for those
        already deleted snapshot.

"xl snapshot-revert"

    1), read snapshot json file from
        "/var/lib/xen/snapshots/domain_uuid/snapshotdata-<snapshot_name>\
        .libxl-json", parse the file and fill in xl_domain_snapshot_info.
    2), destroy current domain
    3). according to the info in xl_domain_snapshot_info, create a new
        domain from snapshot.

Interact with other operations:
All snapshots should be deleted before deleting a domain. This will
affact xl destroy/shutdown/save/migrate, adding related check and error
reporting.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:18:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnkAS-0003C9-1Y; Mon, 10 Nov 2014 08:17:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XnkAQ-0003Bw-Ae
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:17:42 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	82/B1-02697-5A470645; Mon, 10 Nov 2014 08:17:41 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415607459!6158586!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6242 invoked from network); 10 Nov 2014 08:17:41 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Nov 2014 08:17:41 -0000
Received: from linux-tt8j.gns.novell.com (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 10 Nov 2014 01:17:23 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:17:01 +0800
Message-Id: <1415607424-15920-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V8 0/3] domain snapshot document
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 high level document for domain snapshot design, including
libxl API design and basic xl interface design.

Changes to V7:
  - In libxl API:
    * remove libxl_domain_snapshot_revert, let application
      does the work by themselves.
    * remove disk-only support.
  - In xl interface:
    * modify wrong libxl_foo structure to xl_foo structure,
    * remove all disk-only syntax.
  - Other changes according to Ian's comment.

V7 is here:
  http://lists.xen.org/archives/html/xen-devel/2014-10/msg01163.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:18:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnkAS-0003CR-PA; Mon, 10 Nov 2014 08:17:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XnkAR-0003C6-W6
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:17:44 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	1B/6E-02702-7A470645; Mon, 10 Nov 2014 08:17:43 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415607459!12418302!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24811 invoked from network); 10 Nov 2014 08:17:42 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:17:42 -0000
Received: from linux-tt8j.gns.novell.com (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 10 Nov 2014 01:17:31 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:17:03 +0800
Message-Id: <1415607424-15920-3-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415607424-15920-1-git-send-email-cyliu@suse.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

changes to V7:
  * remove libxl_domain_snapshot_revert API
  * about libxl_domain_snapshot_delete, disk snapshot part
    could be extracted to libxlu if we would support many kinds of
    disk backendtypes in future. Add words to the docs, but not
    extended. Basic goal will support only raw and qcow2.
  * remove all disk-only descriptions. Won't support disk-only
    snapshot in xl and libxl.

===========================================================================
Libxl Domain Snapshot API

1. New Structures

libxl_disk_snapshot = Struct("disk_snapshot",[
    # target disk
    ("disk",            libxl_device_disk),

    # disk snapshot name
    ("name",            string),

    # internal/external disk snapshot?
    ("external",        bool),

    # for external disk snapshot, specify following two field
    ("external_format", string),
    ("external_path",   string),
    ])

libxl_domain_snapshot_args = Struct("domain_snapshot_args",[
    # memory state path
    ("memory_path",   string),

    # array to store disk snapshot info
    ("disks",         Array(libxl_disk_snapshot, "num_disks")),
    ]

2. New Functions

int libxl_domain_snapshot_create(libxl_ctx *ctx, int domid,
                                 libxl_domain_snapshot_args *snapshot,
                                 bool live)

    Creates a new snapshot of a domain based on the snapshot config contained
    in @snapshot. Save domain and do disk snapshot.

    ctx (INPUT): context
    domid (INPUT):  domain id
    snapshot (INPUT): configuration of domain snapshot
    live (INPUT):   live snapshot or not
    Returns: 0 on success, -1 on failure

    ctx:
       context.

    domid:
       domid of the domain.

    live:
       true or false.
       when live is 'true', domain is not paused while creating the snapshot,
       like live migration. This increases size of the memory dump file, but
       reducess downtime of the guest.

    snapshot:
       memory_path:
           path to save memory state.
       num_disks:
           number of disks that need to take disk snapshot.
       disks:
           array of disk snapshot configuration. Has num_disks members.
           libxl_device_disk:
               structure to represent which disk.
           name:
               snapshot name.
           external:
               true or flase.
               'false' means internal disk snapshot. external_format and
               external_path will be ignored.
               'true' means external disk snapshot, then external_format and
               external_path should be provided.
          external_format:
              Should be provided when 'external' is true. If not provided, will
              use default format proper to the backend file.
              Ignored when 'external' is false.
          external_path:
              Must be provided when 'external' is true.
              Ignored when 'external' is false.


int libxl_domain_snapshot_delete(libxl_ctx *ctx, int domid,
                                 libxl_domain_snapshot_args *snapshot);

    Delete a snapshot.
    This will delete the related memory state file and disk snapshots.

    ctx (INPUT): context
    domid (INPUT): domain id
    snapshot (INPUT): domain snapshot related info
    Returns: 0 on success, -1 on error.

    About each input, explanation is the same as libxl_domain_snapshot_create.


libxl_domain_snapshot_revert API will not be provided. Considering that:
    domain snapshot revert work could be done by destroying the domain
    and then restore a new domain from the snapshot. Application could
    do that by themselves. If wrapped as an libxl API, the new domain
    will not be awared by libvirt, causing problems in libvirt, worse
    than better.

3. Function Implementation

   libxl_domain_snapshot_create:
       1). check args validation
       2). save domain memory through save-domain
       3). take disk snapshot by qmp command (if domian is active) or qemu-img
           command (if domain is inactive).

   libxl_domain_snapshot_delete:
       1). check args validation
       2). remove memory state file.
       3). delete disk snapshot. (for internal disk snapshot, through qmp
           command or qemu-img command)

   To handle disk snapshot (disk snapshot create or delete) of different
   disk backend types, this work could be extracted to libxlu in future.
   (Base goal would support raw and qcow2 types only, as currently kvm does).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:18:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnkAS-0003CK-Cf; Mon, 10 Nov 2014 08:17:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XnkAR-0003C1-6e
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:17:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	92/7A-09936-6A470645; Mon, 10 Nov 2014 08:17:42 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415607460!12639027!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14793 invoked from network); 10 Nov 2014 08:17:41 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:17:41 -0000
Received: from linux-tt8j.gns.novell.com (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 10 Nov 2014 01:17:29 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:17:02 +0800
Message-Id: <1415607424-15920-2-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415607424-15920-1-git-send-email-cyliu@suse.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V8 1/3] libxl domain snapshot introduction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes to V7:
  * update the words a little to avoid confusing in v6.

===========================================================================
Domain snapshot includes disk snapshots and domain state saving. domain
could be resumed to the very state when the snapshot was created. This
kind of snapshot is also referred to as a domain checkpoint or system
checkpoint. It's consistent.

Disk snapshot is inconsistent if the domain is running. To libxl,
even domain is paused, there is no data flush to disk operation. So, for
active domain (domain is started), take a disk-only snapshot and then
resume, it is as if the guest had crashed. For this reason, we won't
support disk-only snapshot in libxl.

Within domain snapshot, disk snapshot could be "internal" (like in qcow2
format, snapshot and delta are both in one image file), or "external"
(snapshot in one file, delta in another).

Expected 4 types of operations:

"domain snapshot create":
    means saving domain state (if not disk-only) and doing disk snapshots.

"domain snapshot revert":
    means rolling back to the state of indicated snapshot.

"domain snapshot delete":
    delete indicated domain snapshot.

"domain snapshot list":
    list domain snapshot information.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:18:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnkAS-0003C9-1Y; Mon, 10 Nov 2014 08:17:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XnkAQ-0003Bw-Ae
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:17:42 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	82/B1-02697-5A470645; Mon, 10 Nov 2014 08:17:41 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415607459!6158586!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6242 invoked from network); 10 Nov 2014 08:17:41 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Nov 2014 08:17:41 -0000
Received: from linux-tt8j.gns.novell.com (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 10 Nov 2014 01:17:23 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:17:01 +0800
Message-Id: <1415607424-15920-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V8 0/3] domain snapshot document
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 high level document for domain snapshot design, including
libxl API design and basic xl interface design.

Changes to V7:
  - In libxl API:
    * remove libxl_domain_snapshot_revert, let application
      does the work by themselves.
    * remove disk-only support.
  - In xl interface:
    * modify wrong libxl_foo structure to xl_foo structure,
    * remove all disk-only syntax.
  - Other changes according to Ian's comment.

V7 is here:
  http://lists.xen.org/archives/html/xen-devel/2014-10/msg01163.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:18:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnkAg-0003Ez-Aw; Mon, 10 Nov 2014 08:17:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XnkAf-0003EW-AL
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:17:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B7/2F-09842-4B470645; Mon, 10 Nov 2014 08:17:56 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415607474!12599709!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22516 invoked from network); 10 Nov 2014 08:17:55 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:17:55 -0000
Received: from linux-tt8j.gns.novell.com (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 10 Nov 2014 01:17:36 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:17:04 +0800
Message-Id: <1415607424-15920-4-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1415607424-15920-1-git-send-email-cyliu@suse.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V8 3/3] xl snapshot-xxx Design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes to V7:
  * change wrong libxl_domain_snapshot_info naming to xl_domain_snapshot_info
  * remove all disk-only syntax
  * update xl snapshot-revert implementaion

===========================================================================
1. xl commandline interface design

xl snapshot-create:
  Create a snapshot (disk and RAM) of a domain.

  SYNOPSIS:
    snapshot-create <domain> [<cfgfile>] [--name <string>] [--live]

  OPTIONS:
    --name <string>  snapshot name
    --live           take a live snapshot

    If option includes --live, then the domain is not paused while creating
    the snapshot, like live migration. This increases size of the memory
    dump file, but reducess downtime of the guest.

    If option doens't include --name, a default name will be generated
    according to the creation time.

    If specify @cfgfile, cfgfile is prioritized. (e.g. if --name specifies
    a name, meanwhile there is name info in cfgfile, name in cfgfile will
    be used.)

xl snapshot-delete:
  Delete a snapshot (disk and RAM) of a domain.

  SYNOPSIS:
    snapshot-delete <domain> <snapshotname> [--children] [--children-only]

    By default, just this snapshot is deleted, and changes from this
    snapshot are automatically merged into children snapshots.

  OPTIONS:
    --children       delete snapshot and all children
    --children-only  delete children but not snapshot

    If option includes --children, then this snapshot and any descendant
    snapshots are deleted.

    If option include --children-only, only descendant snapshots are deleted,
    this snapshot is not deleted.

xl snapshot-revert:
  Revert domain to status of a snapshot.

  SYNOPSIS:
      snapshot-revert <domain> <snapshotname> [--running] [--paused] [--force]

  OPTIONS:
    --running        after reverting, change state to running
    --paused         after reverting, change state to paused
    --force          try harder on risky reverts

    Normally, the domain will revert to the same state the domain was in while
    the snapshot was taken (whether running, or paused).

    If option includes --running, then overrides the snapshot state to
    guarantee a running domain after the revert.

    If option includes --paused, then guarantees a paused domain after
    the revert.

xl snapshot-list:
  List snapshots for a domain.

  SYNOPSIS:
    snapshot-list <domain> [--parent] [--internal] [--external]
    [--tree] [--name]

  OPTIONS:
    --internal       filter by internal snapshots
    --external       filter by external snapshots
    --tree           list snapshots in a tree
    --parent         add a column showing parent snapshot
    --name           list snapshot names only

2. cfgfile syntax

"xl snapshot-create" supports creating a VM snapshot with user provided
configuration file. The configuration file syntax is as below:

#snapshot name. If user doesn't provide a VM snapshot name, xl will generate
#a name automatically by the creation time.
name=""

#snapshot description. Default is NULL.
description=""

#memory location. This field should be filled when memory=1. Default is NULL.
memory_path=""

#disk snapshot information
disks=['sda,1,qcow2,/tmp/sda_snapshot.qcow2','sdb,1,qcow2,/tmp/sda_snapshot.qcow2']
or
disks=['sda,0','sdb,0']

disk syntax:
'target device, external disk snapshot?, external format, external path'

3. xl structure to maintain VM snapshot info

xl_domain_snapshot_info = Struct("domain_snapshot_info",[
    # snapshot name
    ("name",          string)

    ("create_time",   string)
    ("description",   string)

    # memory path and disk snapshot info
    ("snapshot_args", libxl_domain_snapshot_args),

    # parent snapshot name
    ("parent",        string),

    # array to store all children snapshot name
    ("children",      Array(string, "num_children"),
    ]

According to xl_domain_snapshot_info, a json file will be saved on disk.

4. xl snapshot-xxx implementation details

"xl snapshot-create"

    1), parse args or domain snapshot configuration file.
    2), fill info in libxl_domain_snapshot_args struct according to
        options or config file.
    3), call libxl_domain_snapshot_create()
    4), fill info in xl_domain_snapshot_info.
    5), save snapshot info in json file under                                                             "/var/lib/xen/snapshots/domain_uuid"

"xl snapshot-list"

    1), read all domain snapshot related json file under
        "/var/lib/xen/snapshots/domain_uuid". Parse each file and fill in
        xl_domain_snapshot_info struct.
    2), display information from those xl_domain_snapshot_info(s)

"xl snapshot-delete"

    1), read snapshot json file from
        "/var/lib/xen/snapshots/domain_uuid/snapshotdata-<snapshot_name>\
        .libxl-json", parse the file and fill in xl_domain_snapshot_info
    2), according to parent/children info in xl_domain_snapshot_info
        and commandline options, decide which domain snapshot to be deleted.
        To delete each domain snapshot, fill in
        libxl_domain_snapshot_args and call libxl_domain_snapshot_delete().
    3), refresh parent/children relationship, delete json file for those
        already deleted snapshot.

"xl snapshot-revert"

    1), read snapshot json file from
        "/var/lib/xen/snapshots/domain_uuid/snapshotdata-<snapshot_name>\
        .libxl-json", parse the file and fill in xl_domain_snapshot_info.
    2), destroy current domain
    3). according to the info in xl_domain_snapshot_info, create a new
        domain from snapshot.

Interact with other operations:
All snapshots should be deleted before deleting a domain. This will
affact xl destroy/shutdown/save/migrate, adding related check and error
reporting.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:38:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:38:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnkU6-0003xQ-6F; Mon, 10 Nov 2014 08:38:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XnkU5-0003xL-1w
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 08:38:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	07/88-09936-86970645; Mon, 10 Nov 2014 08:38:00 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415608678!12612787!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6596 invoked from network); 10 Nov 2014 08:37:59 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:37:59 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 10 Nov 2014 01:37:57 -0700
Message-Id: <5460E9D80200006600078038@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 10 Nov 2014 01:37:44 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Bo Cao" <caobosimon@gmail.com>,<xen-devel@lists.xensource.com>
References: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
In-Reply-To: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
Mime-Version: 1.0
Content-Length: 4227
Content-Disposition: inline
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Lars Kurth <lars.kurth@citrix.com>
Subject: Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SXMgdGhlcmUgYW55IHByb2dyZXNzIG9uIHRoaXMgd29yaz8gSSBkaWRuJ3Qgc2VlIG5ldyB2ZXJz
aW9uIGFmdGVyIHRoaXMuCkFueW9uZSBrbm93cyB0aGUgc3RhdHVzPwoKVGhhbmtzLApDaHVueWFu
Cgo+Pj4gT24gOC8xMS8yMDE0IGF0IDA0OjIzIEFNLCBpbiBtZXNzYWdlCjwxNDA3NzAyMjM0LTIy
MzA5LTEtZ2l0LXNlbmQtZW1haWwtY2FvYm9zaW1vbkBnbWFpbC5jb20+LCBCbyBDYW8KPGNhb2Jv
c2ltb25AZ21haWwuY29tPiB3cm90ZTogCj4gRmluYWxseSBJIGhhdmUgYSB3b3JrYWJsZSB2ZXJz
aW9uIHhsL2xpYnhsIHN1cHBvcnQgZm9yIFBWVVNCLiBNb3N0IG9mIAo+IGl0cyBjb21tYW5kcyB3
b3JrIHByb3BlcnR5IG5vdywgYnV0IHRoZXJlIGFyZSBzdGlsbCBzb21lIHByb2JlbG0gdG8gYmUK
PiBzb2x2ZWQuIAo+IFBsZWFzZSB0YWtlIGEgbG9vdCBhbmQgZ2l2ZSBtZSBzb21lIGFkdmljZXMu
Cj4gIAo+ID09IFdoYXQgaGF2ZSBiZWVuIGltcGxlbWVudGVkID8gPT0gCj4gSSBoYXZlIGltcGxl
bWVudGVkIGxpYnhsIGZ1bmN0aW9ucyBmb3IgUFZVU0IgaW4gbGlieGxfdXNiLmMuIEl0IG1haW5s
eSAgCj4gY29uc2lzdHMgb2YgdHdvIHBhcnQ6IAo+IHVzYmN0cmxfYWRkL3JlbW92ZS9saXN0IGFu
ZCB1c2JfYWRkL3JlbW92ZS9saXN0IGluIHdoaWNoIHVzYmN0cmwgZGVub3RlIHVzYiAgCj4gY29u
dHJvbGxlciBpbiB3aGljaCAKPiB1c2QgZGV2aWNlIGNhbiBiZSBwbHVnZ2VkIGluLiBJIGRvbid0
IHVzZSAiYW9fZGV2IiBpbiAgCj4gbGlieGxfZGVpdmNlX3VzYmN0cmxfYWRkIHNpbmNlIHdlIGRv
bid0IG5lZWQgdG8gCj4gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdCBmb3IgdXNiY3RybCBhbmQgd2l0
aG91dCAiYW9fZGV2IiwgYWRkaW5nIGRlZmF1bHQgIAo+IHVzYmN0cmwgZm9yIHVzYiBkZXZpY2Ug
Cj4gd291bGQgYmUgZWFzaWVyLiAKPiAgCj4gRm9yIHRoZSBjYW1tYW5kcyB0byBtYW5pcHVsYXRl
IHVzYiBkZXZpY2Ugc3VjaCBhcyAieGwgdXNiLWF0dGFjaCIgYW5kICJ4bCAgCj4gdXNiLWRldGFj
aCIsIHRoaXMgcGF0Y2ggbm93IG9ubHkgCj4gc3VwcG9ydCB0byBzcGVjaWZ5IHVzYiBkZXZpY2Vz
IGJ5IHRoZWlyIGludGVyZmFjZSBpbiBzeXNmcy4gVXNpbmcgdGhpcyAgCj4gaW50ZXJmYWNlLCB3
ZSBjYW4gcmVhZCB1c2IgZGV2aWNlIAo+IGluZm9ybWF0aW9uIHRocm91Z2ggc3lzZnMgYW5kIGJp
bmQvdW5iaW5kIHVzYiBkZXZpY2UuIChUaGUgc3VwcG9ydCBmb3IgIAo+IG1hcHBpbmcgdGhlICJs
c3VzYiIgYnVzOmFkZHIgdG8gdGhlIAo+IHN5c2ZzIHVzYiBpbnRlcmZhY2Ugd2lsbCBjb21lIGxh
dGVyKS4gCj4gIAo+ID09IFdoYXQgbmVlZHMgdG8gZG8gbmV4dCA/ID09IAo+IFRoZXJlIGFyZSB0
d28gbWFpbiBwcm9ibGVtcyB0byBiZSBzb2x2ZWQuIAo+ICAKPiAxLiAgUFZVU0IgT3B0aW9ucyBp
biBWTSBHdWVzdCdzIENvbmZpZ3VyYXRpb24gRmlsZSAKPiAgICAgVGhlIGludGVyZmFjZSBpbiBW
TSBHdWVzdCdzIGNvbmZpZ3VyYXRpb24gZmlsZSB0byBhZGQgdXNiIGRldmljZSBpczogIAo+ICJ1
c2I9W2ludGVyZmFjZT0iMS0xIl0iLiAKPiBCdXQgdGhlIHByb2JsZW0gaXMgbm93IGlzIHRoYXQg
YWZ0ZXIgdGhlIGRlZmF1bHQgdXNiY3RybCBpcyBhZGRlZCwgdGhlIHN0YXRlICAKPiBvZiB1c2Jj
dHJsIGlzICIyIiwgZSxnLCAiWGVuYnVzU3RhdGVJbml0V2FpdCIsIAo+IHdhaXRpbmcgZm9yIHhl
bi11c2Jmcm9udCB0byBjb25uZWN0LiBUaGUgeGVuLXVzYmZyb250IGluIFZNIEd1ZXN0IGlzbid0
ICAKPiBsb2FkZWQuIFRoZXJlZm9yZSwgInN5c2ZzX2ludGZfd3JpdGUiIAo+IHdpbGwgcmVwb3J0
IGVycm9yLiBEb2VzIGFueW9uZSBoYXZlIGFueSBjbHVlIGhvdyB0byBzb2x2ZSB0aGlzPyAKPiAg
Cj4gMi4gc3lzZnNfaW50Zl93cml0ZSAKPiAgICAgSW4gdGhlIHByb2Nlc3Mgb2YgInhsIHVzYi1h
dHRhY2ggZG9taWQgaW50Zj0xLTEiLCBhZnRlciB3cml0aW5nICIxLTEiIHRvICAKPiBYZW5zdG9y
ZSBlbnRyeSwgd2UgbmVlZCB0byAKPiBiaW5kIHRoZSBjb250cm9sbGVyIG9mIHRoaXMgdXNiIGRl
dmljZSB0byB1c2JiYWNrIGRyaXZlciBzbyB0aGF0IGl0IGNhbiBiZSAgCj4gdXNlZCBieSBWTSBH
dWVzdC4gRm9yIGV4YW1wZWxlLCAKPiBmb3IgdXNiIGRldmljZSAiMS0xIiwgaXQncyBjb250cm9s
bGVyIGludGVyZmFjZSBtYXliZSAiMS0xOjEuMCIsIGFuZCB3ZSAgCj4gd3JpdGUgdGhpcyB2YWx1
ZSB0byAiL3N5cy9idXMvdXNiL2RyaXZlci91c2JiYWNrL2JpbmQiLiAKPiBCdXQgZm9yIHNvbWUg
ZGV2aWNlcywgdGhleSBoYXZlIHR3byBjb250cm9sbGVycywgZm9yIGV4YW1wbGUgIjEtMToxLjAi
IGFuZCAgCj4gIjEtMToxLjEiLiBJIHRoaW5rIHRoaXMgbWVhbnMgaXQgaGFzIHR3byBmdW5jdGlv
bnMsIAo+IHN1Y2ggYXMgdXNiaGlkIGFuZCB1c2Itc3RvcmFnZS4gU28gaW4gdGhpcyBjYXNlLCB3
ZSBiaW5kIHRoZSB0d28gY29udHJvbGxlciAgCj4gdG8gdXNiYmFjaz8gCj4gIAo+ID09PT09PT09
IAo+IFRoZXJlIG1heWJlIHNvbWUgZXJyb3JzIG9yIGJ1Z3MgaW4gdGhlIGNvZGVzLiBGZWVsIGZy
ZWUgdG8gdGVsbCBtZS4gCj4gIAo+IENoZWVycywgCj4gIAo+IC0gU2ltb24gCj4gIAo+IC0tLSAK
PiBDQzogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXguY29tPiAKPiBDQzog
SWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGNpdHJpeC5jb20+IAo+IENDOiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPiAKPiBDQzogUGFzaSBLw6Rya2vDpGluZW4gPHBhc2lr
QGlraS5maT4gCj4gQ0M6IExhcnMgS3VydGggPGxhcnMua3VydGhAY2l0cml4LmNvbT4gCj4gIAo+
ICAKPiAgCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g
Cj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdCAKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZyAKPiBo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwgCj4gIAoKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:38:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:38:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnkU6-0003xQ-6F; Mon, 10 Nov 2014 08:38:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XnkU5-0003xL-1w
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 08:38:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	07/88-09936-86970645; Mon, 10 Nov 2014 08:38:00 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415608678!12612787!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6596 invoked from network); 10 Nov 2014 08:37:59 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:37:59 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 10 Nov 2014 01:37:57 -0700
Message-Id: <5460E9D80200006600078038@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 10 Nov 2014 01:37:44 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Bo Cao" <caobosimon@gmail.com>,<xen-devel@lists.xensource.com>
References: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
In-Reply-To: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
Mime-Version: 1.0
Content-Length: 4227
Content-Disposition: inline
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Lars Kurth <lars.kurth@citrix.com>
Subject: Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SXMgdGhlcmUgYW55IHByb2dyZXNzIG9uIHRoaXMgd29yaz8gSSBkaWRuJ3Qgc2VlIG5ldyB2ZXJz
aW9uIGFmdGVyIHRoaXMuCkFueW9uZSBrbm93cyB0aGUgc3RhdHVzPwoKVGhhbmtzLApDaHVueWFu
Cgo+Pj4gT24gOC8xMS8yMDE0IGF0IDA0OjIzIEFNLCBpbiBtZXNzYWdlCjwxNDA3NzAyMjM0LTIy
MzA5LTEtZ2l0LXNlbmQtZW1haWwtY2FvYm9zaW1vbkBnbWFpbC5jb20+LCBCbyBDYW8KPGNhb2Jv
c2ltb25AZ21haWwuY29tPiB3cm90ZTogCj4gRmluYWxseSBJIGhhdmUgYSB3b3JrYWJsZSB2ZXJz
aW9uIHhsL2xpYnhsIHN1cHBvcnQgZm9yIFBWVVNCLiBNb3N0IG9mIAo+IGl0cyBjb21tYW5kcyB3
b3JrIHByb3BlcnR5IG5vdywgYnV0IHRoZXJlIGFyZSBzdGlsbCBzb21lIHByb2JlbG0gdG8gYmUK
PiBzb2x2ZWQuIAo+IFBsZWFzZSB0YWtlIGEgbG9vdCBhbmQgZ2l2ZSBtZSBzb21lIGFkdmljZXMu
Cj4gIAo+ID09IFdoYXQgaGF2ZSBiZWVuIGltcGxlbWVudGVkID8gPT0gCj4gSSBoYXZlIGltcGxl
bWVudGVkIGxpYnhsIGZ1bmN0aW9ucyBmb3IgUFZVU0IgaW4gbGlieGxfdXNiLmMuIEl0IG1haW5s
eSAgCj4gY29uc2lzdHMgb2YgdHdvIHBhcnQ6IAo+IHVzYmN0cmxfYWRkL3JlbW92ZS9saXN0IGFu
ZCB1c2JfYWRkL3JlbW92ZS9saXN0IGluIHdoaWNoIHVzYmN0cmwgZGVub3RlIHVzYiAgCj4gY29u
dHJvbGxlciBpbiB3aGljaCAKPiB1c2QgZGV2aWNlIGNhbiBiZSBwbHVnZ2VkIGluLiBJIGRvbid0
IHVzZSAiYW9fZGV2IiBpbiAgCj4gbGlieGxfZGVpdmNlX3VzYmN0cmxfYWRkIHNpbmNlIHdlIGRv
bid0IG5lZWQgdG8gCj4gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdCBmb3IgdXNiY3RybCBhbmQgd2l0
aG91dCAiYW9fZGV2IiwgYWRkaW5nIGRlZmF1bHQgIAo+IHVzYmN0cmwgZm9yIHVzYiBkZXZpY2Ug
Cj4gd291bGQgYmUgZWFzaWVyLiAKPiAgCj4gRm9yIHRoZSBjYW1tYW5kcyB0byBtYW5pcHVsYXRl
IHVzYiBkZXZpY2Ugc3VjaCBhcyAieGwgdXNiLWF0dGFjaCIgYW5kICJ4bCAgCj4gdXNiLWRldGFj
aCIsIHRoaXMgcGF0Y2ggbm93IG9ubHkgCj4gc3VwcG9ydCB0byBzcGVjaWZ5IHVzYiBkZXZpY2Vz
IGJ5IHRoZWlyIGludGVyZmFjZSBpbiBzeXNmcy4gVXNpbmcgdGhpcyAgCj4gaW50ZXJmYWNlLCB3
ZSBjYW4gcmVhZCB1c2IgZGV2aWNlIAo+IGluZm9ybWF0aW9uIHRocm91Z2ggc3lzZnMgYW5kIGJp
bmQvdW5iaW5kIHVzYiBkZXZpY2UuIChUaGUgc3VwcG9ydCBmb3IgIAo+IG1hcHBpbmcgdGhlICJs
c3VzYiIgYnVzOmFkZHIgdG8gdGhlIAo+IHN5c2ZzIHVzYiBpbnRlcmZhY2Ugd2lsbCBjb21lIGxh
dGVyKS4gCj4gIAo+ID09IFdoYXQgbmVlZHMgdG8gZG8gbmV4dCA/ID09IAo+IFRoZXJlIGFyZSB0
d28gbWFpbiBwcm9ibGVtcyB0byBiZSBzb2x2ZWQuIAo+ICAKPiAxLiAgUFZVU0IgT3B0aW9ucyBp
biBWTSBHdWVzdCdzIENvbmZpZ3VyYXRpb24gRmlsZSAKPiAgICAgVGhlIGludGVyZmFjZSBpbiBW
TSBHdWVzdCdzIGNvbmZpZ3VyYXRpb24gZmlsZSB0byBhZGQgdXNiIGRldmljZSBpczogIAo+ICJ1
c2I9W2ludGVyZmFjZT0iMS0xIl0iLiAKPiBCdXQgdGhlIHByb2JsZW0gaXMgbm93IGlzIHRoYXQg
YWZ0ZXIgdGhlIGRlZmF1bHQgdXNiY3RybCBpcyBhZGRlZCwgdGhlIHN0YXRlICAKPiBvZiB1c2Jj
dHJsIGlzICIyIiwgZSxnLCAiWGVuYnVzU3RhdGVJbml0V2FpdCIsIAo+IHdhaXRpbmcgZm9yIHhl
bi11c2Jmcm9udCB0byBjb25uZWN0LiBUaGUgeGVuLXVzYmZyb250IGluIFZNIEd1ZXN0IGlzbid0
ICAKPiBsb2FkZWQuIFRoZXJlZm9yZSwgInN5c2ZzX2ludGZfd3JpdGUiIAo+IHdpbGwgcmVwb3J0
IGVycm9yLiBEb2VzIGFueW9uZSBoYXZlIGFueSBjbHVlIGhvdyB0byBzb2x2ZSB0aGlzPyAKPiAg
Cj4gMi4gc3lzZnNfaW50Zl93cml0ZSAKPiAgICAgSW4gdGhlIHByb2Nlc3Mgb2YgInhsIHVzYi1h
dHRhY2ggZG9taWQgaW50Zj0xLTEiLCBhZnRlciB3cml0aW5nICIxLTEiIHRvICAKPiBYZW5zdG9y
ZSBlbnRyeSwgd2UgbmVlZCB0byAKPiBiaW5kIHRoZSBjb250cm9sbGVyIG9mIHRoaXMgdXNiIGRl
dmljZSB0byB1c2JiYWNrIGRyaXZlciBzbyB0aGF0IGl0IGNhbiBiZSAgCj4gdXNlZCBieSBWTSBH
dWVzdC4gRm9yIGV4YW1wZWxlLCAKPiBmb3IgdXNiIGRldmljZSAiMS0xIiwgaXQncyBjb250cm9s
bGVyIGludGVyZmFjZSBtYXliZSAiMS0xOjEuMCIsIGFuZCB3ZSAgCj4gd3JpdGUgdGhpcyB2YWx1
ZSB0byAiL3N5cy9idXMvdXNiL2RyaXZlci91c2JiYWNrL2JpbmQiLiAKPiBCdXQgZm9yIHNvbWUg
ZGV2aWNlcywgdGhleSBoYXZlIHR3byBjb250cm9sbGVycywgZm9yIGV4YW1wbGUgIjEtMToxLjAi
IGFuZCAgCj4gIjEtMToxLjEiLiBJIHRoaW5rIHRoaXMgbWVhbnMgaXQgaGFzIHR3byBmdW5jdGlv
bnMsIAo+IHN1Y2ggYXMgdXNiaGlkIGFuZCB1c2Itc3RvcmFnZS4gU28gaW4gdGhpcyBjYXNlLCB3
ZSBiaW5kIHRoZSB0d28gY29udHJvbGxlciAgCj4gdG8gdXNiYmFjaz8gCj4gIAo+ID09PT09PT09
IAo+IFRoZXJlIG1heWJlIHNvbWUgZXJyb3JzIG9yIGJ1Z3MgaW4gdGhlIGNvZGVzLiBGZWVsIGZy
ZWUgdG8gdGVsbCBtZS4gCj4gIAo+IENoZWVycywgCj4gIAo+IC0gU2ltb24gCj4gIAo+IC0tLSAK
PiBDQzogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXguY29tPiAKPiBDQzog
SWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGNpdHJpeC5jb20+IAo+IENDOiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPiAKPiBDQzogUGFzaSBLw6Rya2vDpGluZW4gPHBhc2lr
QGlraS5maT4gCj4gQ0M6IExhcnMgS3VydGggPGxhcnMua3VydGhAY2l0cml4LmNvbT4gCj4gIAo+
ICAKPiAgCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g
Cj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdCAKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZyAKPiBo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwgCj4gIAoKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Nov 10 08:51:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:51:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnkgr-0004HW-PB; Mon, 10 Nov 2014 08:51: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 1Xnkgq-0004HR-5K
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:51:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B4/80-24532-F7C70645; Mon, 10 Nov 2014 08:51:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415609470!12616113!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31015 invoked from network); 10 Nov 2014 08:51:11 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:51:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 10 Nov 2014 08:51:10 +0000
Message-Id: <54608A8B0200007800045E58@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 10 Nov 2014 08:51:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>,<pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
In-Reply-To: <5460716A.7090905@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.11.14 at 09:03, <sflist@ihonk.com> wrote:
> Sorry for the delay, took some debugging on another computer to get 
> serial logging working. Due to its size, I've posted the entire log of a 
> crashed session here: http://pastebin.com/AiPHUZRH In this case I used a 
> 3.0 gig memory size for the Windows domU.
> 
> As I mentioned before, sometimes it's the SATA that goes first, other 
> times the tg3 ethernet driver. Also note that between 4.4.1 and 4.5rc1, 
> the kernel I'm using (stock Debian Jessie) has not changed.
> 
> Please let me know if you need any other information. Thanks!

Raising the kernel log level to maximum too would have helped.

Regardless of that, the first device showing anomalies here appears
to be the UHCI controller:

    [  147.415713] usb 7-1: reset low-speed USB device number 2 using uhci_hcd

while booting the guest.

And these

    [  199.775209] pcieport 0000:00:03.0: AER: Multiple Corrected error received: id=0018
    [  199.775238] pcieport 0000:00:03.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID)
    [  199.775251] pcieport 0000:00:03.0:   device [8086:340a] error status/mask=00001100/00002000
    [  199.775255] pcieport 0000:00:03.0:    [ 8] RELAY_NUM Rollover    
    [  199.775258] pcieport 0000:00:03.0:    [12] Replay Timer Timeout  

hint at a problem in the system's design. 00:03.0 is the parent bridge
of 02:00.0 (and from what I can tell that's the only device behind that
bridge), and hence the above messages can only reasonably have
their origin at the passed through VGA device. IOW it may well be that
you were just lucky that things worked earlier on.

And btw - the title saying "host crash" seems to not match the provided
log, as there's no sign of a crash anywhere (the host may be hung from
what is visible). Was that just badly worded, or have you actually seen
crashes 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 Nov 10 08:51:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 08:51:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnkgr-0004HW-PB; Mon, 10 Nov 2014 08:51: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 1Xnkgq-0004HR-5K
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 08:51:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B4/80-24532-F7C70645; Mon, 10 Nov 2014 08:51:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415609470!12616113!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31015 invoked from network); 10 Nov 2014 08:51:11 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 08:51:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 10 Nov 2014 08:51:10 +0000
Message-Id: <54608A8B0200007800045E58@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 10 Nov 2014 08:51:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>,<pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
In-Reply-To: <5460716A.7090905@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.11.14 at 09:03, <sflist@ihonk.com> wrote:
> Sorry for the delay, took some debugging on another computer to get 
> serial logging working. Due to its size, I've posted the entire log of a 
> crashed session here: http://pastebin.com/AiPHUZRH In this case I used a 
> 3.0 gig memory size for the Windows domU.
> 
> As I mentioned before, sometimes it's the SATA that goes first, other 
> times the tg3 ethernet driver. Also note that between 4.4.1 and 4.5rc1, 
> the kernel I'm using (stock Debian Jessie) has not changed.
> 
> Please let me know if you need any other information. Thanks!

Raising the kernel log level to maximum too would have helped.

Regardless of that, the first device showing anomalies here appears
to be the UHCI controller:

    [  147.415713] usb 7-1: reset low-speed USB device number 2 using uhci_hcd

while booting the guest.

And these

    [  199.775209] pcieport 0000:00:03.0: AER: Multiple Corrected error received: id=0018
    [  199.775238] pcieport 0000:00:03.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID)
    [  199.775251] pcieport 0000:00:03.0:   device [8086:340a] error status/mask=00001100/00002000
    [  199.775255] pcieport 0000:00:03.0:    [ 8] RELAY_NUM Rollover    
    [  199.775258] pcieport 0000:00:03.0:    [12] Replay Timer Timeout  

hint at a problem in the system's design. 00:03.0 is the parent bridge
of 02:00.0 (and from what I can tell that's the only device behind that
bridge), and hence the above messages can only reasonably have
their origin at the passed through VGA device. IOW it may well be that
you were just lucky that things worked earlier on.

And btw - the title saying "host crash" seems to not match the provided
log, as there's no sign of a crash anywhere (the host may be hung from
what is visible). Was that just badly worded, or have you actually seen
crashes 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 Nov 10 09:21:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 09:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnlAB-0004dR-3r; Mon, 10 Nov 2014 09:21:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XnlA9-0004dM-Fd
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 09:21:29 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F8/3B-02984-89380645; Mon, 10 Nov 2014 09:21:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415611288!12430014!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2530 invoked from network); 10 Nov 2014 09:21:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 09:21:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 10 Nov 2014 09:21:27 +0000
Message-Id: <546091A40200007800045E86@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 10 Nov 2014 09:21:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: DarioFaggioli <dario.faggioli@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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 08.11.14 at 20:43, <wei.liu2@citrix.com> wrote:
> This information is passed in in domctl hypercall but the guest
> interface doesn't expose it to guest. PV NUMA-aware ballooning relies on
> this piece of information to function properly.

Considering that exposing this mapping is wrong from a conceptual
pov (as was discussed during the review of Elena's original series),
the desire to nevertheless expose it would need to be explained
much better than what you did above.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 09:21:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 09:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnlAB-0004dR-3r; Mon, 10 Nov 2014 09:21:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XnlA9-0004dM-Fd
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 09:21:29 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F8/3B-02984-89380645; Mon, 10 Nov 2014 09:21:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415611288!12430014!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2530 invoked from network); 10 Nov 2014 09:21:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 09:21:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 10 Nov 2014 09:21:27 +0000
Message-Id: <546091A40200007800045E86@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 10 Nov 2014 09:21:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: DarioFaggioli <dario.faggioli@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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 08.11.14 at 20:43, <wei.liu2@citrix.com> wrote:
> This information is passed in in domctl hypercall but the guest
> interface doesn't expose it to guest. PV NUMA-aware ballooning relies on
> this piece of information to function properly.

Considering that exposing this mapping is wrong from a conceptual
pov (as was discussed during the review of Elena's original series),
the desire to nevertheless expose it would need to be explained
much better than what you did above.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 09:23:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 09:23:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnlCS-0004lN-Li; Mon, 10 Nov 2014 09:23:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XnlCR-0004lG-4T
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 09:23:51 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	73/CC-22777-62480645; Mon, 10 Nov 2014 09:23:50 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415611429!3890546!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3637 invoked from network); 10 Nov 2014 09:23:49 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 09:23:49 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-23-29-105.brhm.adsl.virginm.net ([86.23.29.105]:59903
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XnlCP-00016i-E2 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Mon, 10 Nov 2014 09:23:49 +0000
Message-ID: <5460842A.6040204@citrix.com>
Date: Mon, 10 Nov 2014 09:23:54 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Wen Congyang <wency@cn.fujitsu.com>, xen devel <xen-devel@lists.xen.org>
References: <54604CEA.1060909@cn.fujitsu.com>
In-Reply-To: <54604CEA.1060909@cn.fujitsu.com>
Subject: Re: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/2014 05:28, Wen Congyang wrote:
> I disable xen-platform-pci in the config file, but when I start the guest, I found
> the following kernel message:
> [    0.000000] Booting paravirtualized kernel on Xen HVM
> [    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
>
> Thanks
> Wen Congyang

There is no current ability to do this.

Here, Linux will be detecting Xen using the hypervisor cpuid leaves at
0x40000000, but if you disable those in Xen, HVMLoader will fail due to
being unable to gain a hypercall page.

It might be a plausible thing to be able to make an HVM domain with no
paravirtual interfaces whatsoever, but it would require quite a bit of
re-architecting of the current HVM infrastructure.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 09:23:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 09:23:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnlCS-0004lN-Li; Mon, 10 Nov 2014 09:23:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XnlCR-0004lG-4T
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 09:23:51 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	73/CC-22777-62480645; Mon, 10 Nov 2014 09:23:50 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415611429!3890546!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3637 invoked from network); 10 Nov 2014 09:23:49 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 09:23:49 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-23-29-105.brhm.adsl.virginm.net ([86.23.29.105]:59903
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XnlCP-00016i-E2 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Mon, 10 Nov 2014 09:23:49 +0000
Message-ID: <5460842A.6040204@citrix.com>
Date: Mon, 10 Nov 2014 09:23:54 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Wen Congyang <wency@cn.fujitsu.com>, xen devel <xen-devel@lists.xen.org>
References: <54604CEA.1060909@cn.fujitsu.com>
In-Reply-To: <54604CEA.1060909@cn.fujitsu.com>
Subject: Re: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/2014 05:28, Wen Congyang wrote:
> I disable xen-platform-pci in the config file, but when I start the guest, I found
> the following kernel message:
> [    0.000000] Booting paravirtualized kernel on Xen HVM
> [    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
>
> Thanks
> Wen Congyang

There is no current ability to do this.

Here, Linux will be detecting Xen using the hypervisor cpuid leaves at
0x40000000, but if you disable those in Xen, HVMLoader will fail due to
being unable to gain a hypercall page.

It might be a plausible thing to be able to make an HVM domain with no
paravirtual interfaces whatsoever, but it would require quite a bit of
re-architecting of the current HVM infrastructure.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 09:28:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 09:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnlH2-0004wA-Eq; Mon, 10 Nov 2014 09:28:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XnlH1-0004w5-Re
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 09:28:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7E/D0-09842-34580645; Mon, 10 Nov 2014 09:28:35 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415611714!12658790!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20971 invoked from network); 10 Nov 2014 09:28:34 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 09:28:34 -0000
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLL55850; Mon, 10 Nov 2014 09:28:21 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id
	14.03.0158.001; Mon, 10 Nov 2014 09:27:49 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] xen/arm: Return correct code error for
	xen_swiotlb_map_page
Thread-Index: AQHP+eQybFi0WqSOD0+2fx6E4sVCLJxT2xKAgAAaXQCAAAKpgIABRwSAgARd4YA=
Date: Mon, 10 Nov 2014 09:27:49 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17E083@lhreml509-mbb>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
	<alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
	<CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
	<alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
	<20141107144517.GA13259@laptop.dumpdata.com>
In-Reply-To: <20141107144517.GA13259@laptop.dumpdata.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.131]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Boris
	Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Frediano Ziglio <freddy77@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
 xen_swiotlb_map_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="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, Nov 06, 2014 at 07:14:51PM +0000, Stefano Stabellini wrote:
> > On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> > > 2014-11-06 17:30 GMT+00:00 Stefano Stabellini
> <stefano.stabellini@eu.citrix.com>:
> > >       On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> > >       > On ARM error code is not 0 so avoid to return it as error.
> > >       >
> > >       > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > >
> > >       Acked-by: Stefano Stabellini
> > > <stefano.stabellini@eu.citrix.com>
> > >
> > >
> > >       Could you please fix the same error in lib/swiotlb.c too
> please?
> > >
> > >
> > > Same patch or another ?
> > >
> >
> > Another
> =

> It might break the build. Please double-check that it does not affect
> ia64.
> >

Code in lin/swiotlb.c does not require any changes as the error value is co=
mpletely different here (is the pa address of a static allocated buffer). O=
n ia64 the constant I used in my previous patch is 0 so it produce the same=
 assembly code.

Frediano

> > >
> > >       >=A0 drivers/xen/swiotlb-xen.c | 2 +-
> > >       >=A0 1 file changed, 1 insertion(+), 1 deletion(-)
> > >       >
> > >       > diff --git a/drivers/xen/swiotlb-xen.c
> b/drivers/xen/swiotlb-xen.c
> > >       > index ebd8f21..3b8d628 100644
> > >       > --- a/drivers/xen/swiotlb-xen.c
> > >       > +++ b/drivers/xen/swiotlb-xen.c
> > >       > @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct
> device *dev, struct page *page,
> > >       >=A0 =A0 =A0 =A0 */
> > >       >=A0 =A0 =A0 =A0if (!dma_capable(dev, dev_addr, size)) {
> > >       >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0swiotlb_tbl_unmap_single(dev, m=
ap, size, dir);
> > >       > -=A0 =A0 =A0 =A0 =A0 =A0 =A0dev_addr =3D 0;
> > >       > +=A0 =A0 =A0 =A0 =A0 =A0 =A0dev_addr =3D DMA_ERROR_CODE;
> =

> That looks Ok to me.
> =

> > >       >=A0 =A0 =A0 =A0}
> > >       >=A0 =A0 =A0 =A0return dev_addr;
> > >       >=A0 }
> > >       > --
> > >       > 1.9.1
> > >       >
> > >       >
> > >       > --
> > >       > To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> > >       > the body of a message to majordomo@vger.kernel.org
> > >       > More majordomo info at=A0 http://vger.kernel.org/majordomo-
> info.html
> > >       > Please read the FAQ at=A0http://secure-
> web.cisco.com/1cvjROyUxV6SnA0uBTMRubqrQWsaXGhps-
> FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpcxwEH-udGrGCCq
> > >       kCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-
> Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYcvWsOK5s3qg/http%3A%2F%2Fwww.tux.org%2Fl
> kml%2F
> > >       >
> > >
> > >       _______________________________________________
> > >       Xen-devel mailing list
> > >       Xen-devel@lists.xen.org
> > >       http://lists.xen.org/xen-devel
> > >
> > >
> > >
> > >
> =

> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 09:28:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 09:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnlH2-0004wA-Eq; Mon, 10 Nov 2014 09:28:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@huawei.com>) id 1XnlH1-0004w5-Re
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 09:28:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7E/D0-09842-34580645; Mon, 10 Nov 2014 09:28:35 +0000
X-Env-Sender: frediano.ziglio@huawei.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415611714!12658790!1
X-Originating-IP: [194.213.3.17]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20971 invoked from network); 10 Nov 2014 09:28:34 -0000
Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 09:28:34 -0000
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com)
	([172.18.7.190])
	by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id BLL55850; Mon, 10 Nov 2014 09:28:21 +0000 (GMT)
Received: from LHREML509-MBB.china.huawei.com ([10.201.4.152]) by
	lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id
	14.03.0158.001; Mon, 10 Nov 2014 09:27:49 +0000
From: Frediano Ziglio <frediano.ziglio@huawei.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] xen/arm: Return correct code error for
	xen_swiotlb_map_page
Thread-Index: AQHP+eQybFi0WqSOD0+2fx6E4sVCLJxT2xKAgAAaXQCAAAKpgIABRwSAgARd4YA=
Date: Mon, 10 Nov 2014 09:27:49 +0000
Message-ID: <B944B469BF5302468AC6EB05E56CC70D17E083@lhreml509-mbb>
References: <1415293651-13917-1-git-send-email-frediano.ziglio@huawei.com>
	<alpine.DEB.2.02.1411061730240.22875@kaball.uk.xensource.com>
	<CAHt6W4cDvgK=jdkMot5E4COoC=3aeZn8vPxiR5K5XS53g=+FXA@mail.gmail.com>
	<alpine.DEB.2.02.1411061914440.22875@kaball.uk.xensource.com>
	<20141107144517.GA13259@laptop.dumpdata.com>
In-Reply-To: <20141107144517.GA13259@laptop.dumpdata.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.68.131]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Boris
	Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Frediano Ziglio <freddy77@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/arm: Return correct code error for
 xen_swiotlb_map_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="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, Nov 06, 2014 at 07:14:51PM +0000, Stefano Stabellini wrote:
> > On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> > > 2014-11-06 17:30 GMT+00:00 Stefano Stabellini
> <stefano.stabellini@eu.citrix.com>:
> > >       On Thu, 6 Nov 2014, Frediano Ziglio wrote:
> > >       > On ARM error code is not 0 so avoid to return it as error.
> > >       >
> > >       > Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
> > >
> > >       Acked-by: Stefano Stabellini
> > > <stefano.stabellini@eu.citrix.com>
> > >
> > >
> > >       Could you please fix the same error in lib/swiotlb.c too
> please?
> > >
> > >
> > > Same patch or another ?
> > >
> >
> > Another
> =

> It might break the build. Please double-check that it does not affect
> ia64.
> >

Code in lin/swiotlb.c does not require any changes as the error value is co=
mpletely different here (is the pa address of a static allocated buffer). O=
n ia64 the constant I used in my previous patch is 0 so it produce the same=
 assembly code.

Frediano

> > >
> > >       >=A0 drivers/xen/swiotlb-xen.c | 2 +-
> > >       >=A0 1 file changed, 1 insertion(+), 1 deletion(-)
> > >       >
> > >       > diff --git a/drivers/xen/swiotlb-xen.c
> b/drivers/xen/swiotlb-xen.c
> > >       > index ebd8f21..3b8d628 100644
> > >       > --- a/drivers/xen/swiotlb-xen.c
> > >       > +++ b/drivers/xen/swiotlb-xen.c
> > >       > @@ -425,7 +425,7 @@ dma_addr_t xen_swiotlb_map_page(struct
> device *dev, struct page *page,
> > >       >=A0 =A0 =A0 =A0 */
> > >       >=A0 =A0 =A0 =A0if (!dma_capable(dev, dev_addr, size)) {
> > >       >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0swiotlb_tbl_unmap_single(dev, m=
ap, size, dir);
> > >       > -=A0 =A0 =A0 =A0 =A0 =A0 =A0dev_addr =3D 0;
> > >       > +=A0 =A0 =A0 =A0 =A0 =A0 =A0dev_addr =3D DMA_ERROR_CODE;
> =

> That looks Ok to me.
> =

> > >       >=A0 =A0 =A0 =A0}
> > >       >=A0 =A0 =A0 =A0return dev_addr;
> > >       >=A0 }
> > >       > --
> > >       > 1.9.1
> > >       >
> > >       >
> > >       > --
> > >       > To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> > >       > the body of a message to majordomo@vger.kernel.org
> > >       > More majordomo info at=A0 http://vger.kernel.org/majordomo-
> info.html
> > >       > Please read the FAQ at=A0http://secure-
> web.cisco.com/1cvjROyUxV6SnA0uBTMRubqrQWsaXGhps-
> FWjY3vly9AxaKKlt2DPY7GjL0FCHeP4rsbjKsc-P4zH2_7-kpcxwEH-udGrGCCq
> > >       kCLlH1-fLOo1X6Nlui6EwEVHUpB2r7gt-
> Gsgxbep9QWPnIdypDPNf8Hf5clxCMXYcvWsOK5s3qg/http%3A%2F%2Fwww.tux.org%2Fl
> kml%2F
> > >       >
> > >
> > >       _______________________________________________
> > >       Xen-devel mailing list
> > >       Xen-devel@lists.xen.org
> > >       http://lists.xen.org/xen-devel
> > >
> > >
> > >
> > >
> =

> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:00:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnllm-0005I2-KS; Mon, 10 Nov 2014 10:00:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xnllk-0005Hx-BQ
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 10:00:20 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	FF/AD-02954-3BC80645; Mon, 10 Nov 2014 10:00:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415613617!12396107!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28441 invoked from network); 10 Nov 2014 10:00:18 -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;
	10 Nov 2014 10:00:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="189688684"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 05:00:16 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xnllg-00013d-GQ;
	Mon, 10 Nov 2014 10:00:16 +0000
Date: Mon, 10 Nov 2014 10:00:16 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141110100016.GA17065@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546091A40200007800045E86@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: DarioFaggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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 Mon, Nov 10, 2014 at 09:21:24AM +0000, Jan Beulich wrote:
> >>> On 08.11.14 at 20:43, <wei.liu2@citrix.com> wrote:
> > This information is passed in in domctl hypercall but the guest
> > interface doesn't expose it to guest. PV NUMA-aware ballooning relies on
> > this piece of information to function properly.
> 
> Considering that exposing this mapping is wrong from a conceptual
> pov (as was discussed during the review of Elena's original series),
> the desire to nevertheless expose it would need to be explained
> much better than what you did above.
> 

My thought was that if a PV guest needs to do NUMA-aware ballooning, it
would be easier to have the mapping at hand to let the guest request
explicitly from what physical node it wants the page. It was based
on my vague memory of early version of Elena's series.

However, if this is conceptually wrong and has been discussed before,
(as I said in the other email) please just ignore this patch. I can try
to modify the hypervisor instead to make NUMA-aware ballooning happen
under the hood without guest knowing anything. That is, to make use of
the vmemrange structure to identify the vnode of a particular gpfn, then
with vnode_to_pnode map to identify the physical node of that gpfn, then
do NUMA-aware ballooning.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:00:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnllm-0005I2-KS; Mon, 10 Nov 2014 10:00:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xnllk-0005Hx-BQ
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 10:00:20 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	FF/AD-02954-3BC80645; Mon, 10 Nov 2014 10:00:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415613617!12396107!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28441 invoked from network); 10 Nov 2014 10:00:18 -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;
	10 Nov 2014 10:00:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="189688684"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 05:00:16 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xnllg-00013d-GQ;
	Mon, 10 Nov 2014 10:00:16 +0000
Date: Mon, 10 Nov 2014 10:00:16 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141110100016.GA17065@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546091A40200007800045E86@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: DarioFaggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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 Mon, Nov 10, 2014 at 09:21:24AM +0000, Jan Beulich wrote:
> >>> On 08.11.14 at 20:43, <wei.liu2@citrix.com> wrote:
> > This information is passed in in domctl hypercall but the guest
> > interface doesn't expose it to guest. PV NUMA-aware ballooning relies on
> > this piece of information to function properly.
> 
> Considering that exposing this mapping is wrong from a conceptual
> pov (as was discussed during the review of Elena's original series),
> the desire to nevertheless expose it would need to be explained
> much better than what you did above.
> 

My thought was that if a PV guest needs to do NUMA-aware ballooning, it
would be easier to have the mapping at hand to let the guest request
explicitly from what physical node it wants the page. It was based
on my vague memory of early version of Elena's series.

However, if this is conceptually wrong and has been discussed before,
(as I said in the other email) please just ignore this patch. I can try
to modify the hypervisor instead to make NUMA-aware ballooning happen
under the hood without guest knowing anything. That is, to make use of
the vmemrange structure to identify the vnode of a particular gpfn, then
with vnode_to_pnode map to identify the physical node of that gpfn, then
do NUMA-aware ballooning.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:03:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:03:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnloW-0005SJ-HG; Mon, 10 Nov 2014 10:03:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnloV-0005SC-2s
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 10:03:11 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A9/92-09936-E5D80645; Mon, 10 Nov 2014 10:03:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415613787!12687201!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13151 invoked from network); 10 Nov 2014 10:03:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 10:03:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="191126645"
Message-ID: <1415613783.27002.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 10 Nov 2014 10:03:03 +0000
In-Reply-To: <7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
	<7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	ian.jackson@eu.citrix.com, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2014-11-08 at 15:26 -0500, Konrad Rzeszutek Wilk wrote:
> That is to guard against somebody building against libxc or libxl and
> then becoming dependent on this and then complaining that it is not in
> Xen 4.6. 

libxc does not have a stable API and libxl doesn't expose this interface
at all. At the hypercall level this is a domctl which simliarly has no
stable interface.

So I don't think there is any need to wrap anything or guard against
anything.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:03:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:03:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnloW-0005SJ-HG; Mon, 10 Nov 2014 10:03:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnloV-0005SC-2s
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 10:03:11 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A9/92-09936-E5D80645; Mon, 10 Nov 2014 10:03:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415613787!12687201!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13151 invoked from network); 10 Nov 2014 10:03:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 10:03:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="191126645"
Message-ID: <1415613783.27002.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 10 Nov 2014 10:03:03 +0000
In-Reply-To: <7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
	<7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, vijay.kilari@gmail.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	ian.jackson@eu.citrix.com, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2014-11-08 at 15:26 -0500, Konrad Rzeszutek Wilk wrote:
> That is to guard against somebody building against libxc or libxl and
> then becoming dependent on this and then complaining that it is not in
> Xen 4.6. 

libxc does not have a stable API and libxl doesn't expose this interface
at all. At the hypercall level this is a domctl which simliarly has no
stable interface.

So I don't think there is any need to wrap anything or guard against
anything.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:03:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:03:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnloy-0005VV-U0; Mon, 10 Nov 2014 10:03:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1Xnlox-0005VK-AV
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 10:03:39 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	F4/E7-17735-A7D80645; Mon, 10 Nov 2014 10:03:38 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415613815!11522837!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12948 invoked from network); 10 Nov 2014 10:03:37 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-8.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 10:03:37 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43131471"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 10 Nov 2014 18:00:23 +0800
Received: from G08CNEXCHPEKD03.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAAA3M4o020456;
	Mon, 10 Nov 2014 18:03:22 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 10 Nov 2014 18:03:35 +0800
Message-ID: <54608DEA.2080607@cn.fujitsu.com>
Date: Mon, 10 Nov 2014 18:05:30 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen devel
	<xen-devel@lists.xen.org>
References: <54604CEA.1060909@cn.fujitsu.com> <5460842A.6040204@citrix.com>
In-Reply-To: <5460842A.6040204@citrix.com>
X-Originating-IP: [10.167.226.91]
Subject: Re: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 05:23 PM, Andrew Cooper wrote:
> On 10/11/2014 05:28, Wen Congyang wrote:
>> I disable xen-platform-pci in the config file, but when I start the guest, I found
>> the following kernel message:
>> [    0.000000] Booting paravirtualized kernel on Xen HVM
>> [    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
>>
>> Thanks
>> Wen Congyang
> 
> There is no current ability to do this.
> 
> Here, Linux will be detecting Xen using the hypervisor cpuid leaves at
> 0x40000000, but if you disable those in Xen, HVMLoader will fail due to
> being unable to gain a hypercall page.
> 
> It might be a plausible thing to be able to make an HVM domain with no
> paravirtual interfaces whatsoever, but it would require quite a bit of
> re-architecting of the current HVM infrastructure.

Thanks. The newest kernel has a new parameter: xen_nopv, but my guest
kernel is old....

> 
> ~Andrew
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:03:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:03:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnloy-0005VV-U0; Mon, 10 Nov 2014 10:03:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1Xnlox-0005VK-AV
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 10:03:39 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	F4/E7-17735-A7D80645; Mon, 10 Nov 2014 10:03:38 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415613815!11522837!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12948 invoked from network); 10 Nov 2014 10:03:37 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-8.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 10:03:37 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43131471"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 10 Nov 2014 18:00:23 +0800
Received: from G08CNEXCHPEKD03.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAAA3M4o020456;
	Mon, 10 Nov 2014 18:03:22 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 10 Nov 2014 18:03:35 +0800
Message-ID: <54608DEA.2080607@cn.fujitsu.com>
Date: Mon, 10 Nov 2014 18:05:30 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen devel
	<xen-devel@lists.xen.org>
References: <54604CEA.1060909@cn.fujitsu.com> <5460842A.6040204@citrix.com>
In-Reply-To: <5460842A.6040204@citrix.com>
X-Originating-IP: [10.167.226.91]
Subject: Re: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 05:23 PM, Andrew Cooper wrote:
> On 10/11/2014 05:28, Wen Congyang wrote:
>> I disable xen-platform-pci in the config file, but when I start the guest, I found
>> the following kernel message:
>> [    0.000000] Booting paravirtualized kernel on Xen HVM
>> [    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
>>
>> Thanks
>> Wen Congyang
> 
> There is no current ability to do this.
> 
> Here, Linux will be detecting Xen using the hypervisor cpuid leaves at
> 0x40000000, but if you disable those in Xen, HVMLoader will fail due to
> being unable to gain a hypercall page.
> 
> It might be a plausible thing to be able to make an HVM domain with no
> paravirtual interfaces whatsoever, but it would require quite a bit of
> re-architecting of the current HVM infrastructure.

Thanks. The newest kernel has a new parameter: xen_nopv, but my guest
kernel is old....

> 
> ~Andrew
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:04:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnlpW-0005ad-CH; Mon, 10 Nov 2014 10:04:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnlpV-0005aR-EX
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 10:04:13 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	30/CF-02699-C9D80645; Mon, 10 Nov 2014 10:04:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415613850!12450634!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28568 invoked from network); 10 Nov 2014 10:04:12 -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;
	10 Nov 2014 10:04:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="189689686"
Message-ID: <1415613848.27002.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anh Dinh <ug93tad@gmail.com>
Date: Mon, 10 Nov 2014 10:04:08 +0000
In-Reply-To: <CAAbkU4SUrk0nRT97T0eBqNB7-Z7MVLGoWJtP+DwPijbZEphM0w@mail.gmail.com>
References: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
	<545CA29A.2040703@citrix.com>
	<CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com>
	<545CA690.8090507@citrix.com>
	<CAAbkU4SUrk0nRT97T0eBqNB7-Z7MVLGoWJtP+DwPijbZEphM0w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"<xen-devel@lists.xen.org>" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] how to deal with copy_to_user returning non 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

On Sun, 2014-11-09 at 09:22 +0800, Anh Dinh wrote:
> Thanks,
> 
> 
> I've found out the reason it page-faulting is because I used malloc()
> to allocate the output buffer, which turns out to allocate lazily.
> Therefore the hypervisor page-fault because the memory is still
> waiting to be mapped by the kernel. 
> 
> 
> I simply touched all the allocated memory, and it works fine now. 

It might work, but unless it is using hypercall buffers and
XEN_GUEST_HANDLE then it is still subtly broken.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:04:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnlpW-0005ad-CH; Mon, 10 Nov 2014 10:04:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnlpV-0005aR-EX
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 10:04:13 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	30/CF-02699-C9D80645; Mon, 10 Nov 2014 10:04:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415613850!12450634!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28568 invoked from network); 10 Nov 2014 10:04:12 -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;
	10 Nov 2014 10:04:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="189689686"
Message-ID: <1415613848.27002.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anh Dinh <ug93tad@gmail.com>
Date: Mon, 10 Nov 2014 10:04:08 +0000
In-Reply-To: <CAAbkU4SUrk0nRT97T0eBqNB7-Z7MVLGoWJtP+DwPijbZEphM0w@mail.gmail.com>
References: <CAAbkU4TySi7UikFovn5tpa4zF=rjzwmzsg_q8FxyZfvCoO8e2w@mail.gmail.com>
	<545CA29A.2040703@citrix.com>
	<CCDC9DCF-3D97-42B9-97C3-225C936B3CCF@gmail.com>
	<545CA690.8090507@citrix.com>
	<CAAbkU4SUrk0nRT97T0eBqNB7-Z7MVLGoWJtP+DwPijbZEphM0w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"<xen-devel@lists.xen.org>" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] how to deal with copy_to_user returning non 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

On Sun, 2014-11-09 at 09:22 +0800, Anh Dinh wrote:
> Thanks,
> 
> 
> I've found out the reason it page-faulting is because I used malloc()
> to allocate the output buffer, which turns out to allocate lazily.
> Therefore the hypervisor page-fault because the memory is still
> waiting to be mapped by the kernel. 
> 
> 
> I simply touched all the allocated memory, and it works fine now. 

It might work, but unless it is using hypercall buffers and
XEN_GUEST_HANDLE then it is still subtly broken.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:07:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:07:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnlsx-0005rb-N7; Mon, 10 Nov 2014 10:07: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@citrix.com>) id 1Xnlsw-0005rU-DT
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 10:07:46 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	A4/D7-11581-17E80645; Mon, 10 Nov 2014 10:07:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415614063!8133612!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22088 invoked from network); 10 Nov 2014 10:07:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 10:07:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="189690330"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 05:07:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnlsM-0005Ai-DU;
	Mon, 10 Nov 2014 10:07:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnlsM-0002WB-2J;
	Mon, 10 Nov 2014 10:07:10 +0000
Date: Mon, 10 Nov 2014 10:07:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31392-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 5521
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31392: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4332266727829309796=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4332266727829309796==
Content-Type: text/plain
Content-Length: 5189
Content-Transfer-Encoding: quoted-printable

flight 31392 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31392/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt      4 xen-install               fail REGR. vs. 31372

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              7ead1a5d91a93b5614deeef7b0227bffcea9740d
baseline version:
 libvirt              4480cd28371ca328ed5561f3532f82d8cbc9f34d

------------------------------------------------------------
People who touched revisions under test:
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Weiwei Li <nuonuoli@tencent.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

------------------------------------------------------------
commit 7ead1a5d91a93b5614deeef7b0227bffcea9740d
Author: J=C3=A1n Tomko <jtomko@redhat.com>
Date:   Fri Oct 31 10:02:22 2014 +0100

    Do not probe for power mgmt capabilities in lxc emulator
    
    It fails after 30 seconds with this error:
    error : virDBusCall:1429 : error from service: CanSuspend:
    Did not receive a reply. Possible causes include: the remote
    application did not send a reply, the message bus security
    policy blocked the reply, the reply timeout expired, or the
    network connection was broken.
    
    Only probe for the power mgmt capabilities when driver is non-NULL.
    This speeds up domain startup by 30 seconds.
    
    https://bugzilla.redhat.com/show_bug.cgi=3Fid=3D1159227

commit 3f43bb832646588f57303f09fe5c7ac8ba7602d8
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Tue Nov 4 10:46:41 2014 +0100

    util: fix releasing pidfile in cleanup
    
    Coverity found out the very obvious problem in the code.  That is that
    virPidFileReleasePath() was called only if
    virPidFileAcquirePath() returned 0.  But virPidFileAcquirePath() doesn't
    return only 0 on success, but the FD that needs to be closed.
    
    Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

commit c3012a023f2ae5763027cafc1cf2881a3c7c4b45
Author: Weiwei Li <nuonuoli@tencent.com>
Date:   Tue Nov 4 10:52:10 2014 +0100

    qemu: stop NBD server after successful migration
    
    In qemuMigrationFinish mig->nbd can not be initialized by
    qemuMigrationEatCookie without the QEMU_MIGRATION_COOKIE_NBD flag.
    That causes qemuMigrationStopNBDServer to return early without
    stopping the NBD server properly.
    
    Signed-off-by: Weiwei Li <nuonuoli@tencent.com>
    Signed-off-by: J=C3=A1n Tomko <jtomko@redhat.com>

commit 5c8515620bd63b4f9fd848fdad275922928975c7
Author: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Date:   Tue Nov 4 10:44:41 2014 +0800

    virnuma: use virNumaNodesetIsAvailable checking nodeset in virNumaSetupMemoryPolicy
    
    Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>

commit 902864184efe91cd7bc9299da84a03628715779c
Author: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Date:   Tue Nov 4 10:44:40 2014 +0800

    numatune: add check for numatune nodeset range
    
    There was no check for 'nodeset' attribute in numatune-related
    elements.  This patch adds validation that any nodeset specified does
    not exceed maximum host node.
    
    Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>

commit d2460f85d3648607bf6119ee36a5d40546876d38
Author: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Date:   Tue Nov 4 10:44:39 2014 +0800

    bitmap: add virBitmapLastSetBit for finding the last bit position of bitmap
    
    Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>


--===============4332266727829309796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4332266727829309796==--

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:07:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:07:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnlsx-0005rb-N7; Mon, 10 Nov 2014 10:07: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@citrix.com>) id 1Xnlsw-0005rU-DT
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 10:07:46 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	A4/D7-11581-17E80645; Mon, 10 Nov 2014 10:07:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415614063!8133612!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22088 invoked from network); 10 Nov 2014 10:07:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 10:07:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="189690330"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 05:07:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnlsM-0005Ai-DU;
	Mon, 10 Nov 2014 10:07:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnlsM-0002WB-2J;
	Mon, 10 Nov 2014 10:07:10 +0000
Date: Mon, 10 Nov 2014 10:07:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31392-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 5521
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31392: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4332266727829309796=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4332266727829309796==
Content-Type: text/plain
Content-Length: 5189
Content-Transfer-Encoding: quoted-printable

flight 31392 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31392/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt      4 xen-install               fail REGR. vs. 31372

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              7ead1a5d91a93b5614deeef7b0227bffcea9740d
baseline version:
 libvirt              4480cd28371ca328ed5561f3532f82d8cbc9f34d

------------------------------------------------------------
People who touched revisions under test:
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Weiwei Li <nuonuoli@tencent.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

------------------------------------------------------------
commit 7ead1a5d91a93b5614deeef7b0227bffcea9740d
Author: J=C3=A1n Tomko <jtomko@redhat.com>
Date:   Fri Oct 31 10:02:22 2014 +0100

    Do not probe for power mgmt capabilities in lxc emulator
    
    It fails after 30 seconds with this error:
    error : virDBusCall:1429 : error from service: CanSuspend:
    Did not receive a reply. Possible causes include: the remote
    application did not send a reply, the message bus security
    policy blocked the reply, the reply timeout expired, or the
    network connection was broken.
    
    Only probe for the power mgmt capabilities when driver is non-NULL.
    This speeds up domain startup by 30 seconds.
    
    https://bugzilla.redhat.com/show_bug.cgi=3Fid=3D1159227

commit 3f43bb832646588f57303f09fe5c7ac8ba7602d8
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Tue Nov 4 10:46:41 2014 +0100

    util: fix releasing pidfile in cleanup
    
    Coverity found out the very obvious problem in the code.  That is that
    virPidFileReleasePath() was called only if
    virPidFileAcquirePath() returned 0.  But virPidFileAcquirePath() doesn't
    return only 0 on success, but the FD that needs to be closed.
    
    Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

commit c3012a023f2ae5763027cafc1cf2881a3c7c4b45
Author: Weiwei Li <nuonuoli@tencent.com>
Date:   Tue Nov 4 10:52:10 2014 +0100

    qemu: stop NBD server after successful migration
    
    In qemuMigrationFinish mig->nbd can not be initialized by
    qemuMigrationEatCookie without the QEMU_MIGRATION_COOKIE_NBD flag.
    That causes qemuMigrationStopNBDServer to return early without
    stopping the NBD server properly.
    
    Signed-off-by: Weiwei Li <nuonuoli@tencent.com>
    Signed-off-by: J=C3=A1n Tomko <jtomko@redhat.com>

commit 5c8515620bd63b4f9fd848fdad275922928975c7
Author: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Date:   Tue Nov 4 10:44:41 2014 +0800

    virnuma: use virNumaNodesetIsAvailable checking nodeset in virNumaSetupMemoryPolicy
    
    Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>

commit 902864184efe91cd7bc9299da84a03628715779c
Author: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Date:   Tue Nov 4 10:44:40 2014 +0800

    numatune: add check for numatune nodeset range
    
    There was no check for 'nodeset' attribute in numatune-related
    elements.  This patch adds validation that any nodeset specified does
    not exceed maximum host node.
    
    Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>

commit d2460f85d3648607bf6119ee36a5d40546876d38
Author: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Date:   Tue Nov 4 10:44:39 2014 +0800

    bitmap: add virBitmapLastSetBit for finding the last bit position of bitmap
    
    Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>


--===============4332266727829309796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4332266727829309796==--

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:17:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10: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 1Xnm1x-00063Z-SF; Mon, 10 Nov 2014 10:17:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xnm1w-00063U-1o
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 10:17:04 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	62/25-02576-F9090645; Mon, 10 Nov 2014 10:17:03 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415614621!12446075!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31705 invoked from network); 10 Nov 2014 10:17:02 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-13.tower-27.messagelabs.com with SMTP;
	10 Nov 2014 10:17:02 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id C51F8DA;
	Mon, 10 Nov 2014 04:16:56 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 8626E5FAD7;
	Mon, 10 Nov 2014 04:16:49 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 2AD3E13F8F4;
	Mon, 10 Nov 2014 04:16:48 -0600 (CST)
Date: Mon, 10 Nov 2014 10:16:46 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110101645.GA21366@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
	<20141107181430.GH29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071834540.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411071834540.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 06:45:22PM +0000, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > On Fri, Nov 07, 2014 at 05:35:41PM +0000, Stefano Stabellini wrote:
> > > On Fri, 7 Nov 2014, Stefano Stabellini wrote:
> > > > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > > > What I would like to see is xen_dma_map_page() also using hyp calls for
> > > > > cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> > > > > need another argument to xen_dma_map_page() though to pass the real
> > > > > device address or mfn (and on the map side you could simply check for
> > > > > page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> > > > > bouncing so you don't need dom0 swiotlb involved as well.
> > > > 
> > > > I can see that it would be nice to have map_page and unmap_page be
> > > > symmetrical. However actually doing the map_page flush with an hypercall
> > > > would slow things down. Hypercalls are slower than function calls. It is
> > > > faster to do the cache flushing in dom0 if possible. In the map_page
> > > > case we have the struct page so we can easily do it by calling the
> > > > native dma_ops function.
> > > > 
> > > > Maybe I could just add a comment to explain the reason for the asymmetry?
> > > 
> > > Ah, but the problem is that map_page could allocate a swiotlb buffer
> > > (actually it does on arm64) that without a corresponding unmap_page
> > > call, would end up being leaked, right?
> > 
> > Yes. You could hack dma_capable() to always return true for dom0
> > (because the pfn/dma address here doesn't have anything to do with the
> > real mfn) but that's more of a hack assuming a lot about the swiotlb
> > implementation.
> 
> Another idea would be to avoid calling the native map_page for foreign
> pages, but in the xen specific implementation instead of making the
> hypercall, we could call __dma_map_area on arm64 and map_page on arm.

The problem here is that you assume that for an SoC that is not fully
coherent all it needs is __dma_map_area. If you look at mach-mvebu, the
DMA is nearly cache coherent but it needs some specific synchronisation
barrier at the interconnect level. If we get something like this on a
platform with virtualisation, it would be implemented at the dom0 level
by SoC-specific DMA ops. Xen hypervisor I assume has its own BSP, hence
it could implement SoC specific cache flushing there. But with the mix
of cache flushing in dom0 on map and hypervisor on unmap such thing is
no longer be possible in a nice way.

> In arch/arm/include/asm/xen/page-coherent.h:
> 
> static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> 	     dma_addr_t dev_addr, unsigned long offset, size_t size,
> 	     enum dma_data_direction dir, struct dma_attrs *attrs)
> {
> 	if (pfn_valid(PFN_DOWN(dev_addr))) {

BTW, pfn_valid() is more expensive than simply comparing the mfn with
pfn for dom0. The calling code knows this already and it may be quicker
to simply pass a "bool foreign" argument.

> It wouldn't be as nice as using the hypercall but it would be faster and
> wouldn't depend on the inner workings of the arm64 implementation of
> map_page, except for __dma_map_area.

This "except" is big as we may at some point get some SoC like mvebu (I
would say less likely for arm64 than arm32).

BTW, does the Xen hypervisor already have a mapping of the mfn? If not
and it has to create one temporarily for the flush, you may not lose
much by using the dom0 ops for unmap with a hyper call for temporarily
mapping the foreign page in dom0's IPA space (you could do the unmapping
lazily).

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:17:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10: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 1Xnm1x-00063Z-SF; Mon, 10 Nov 2014 10:17:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xnm1w-00063U-1o
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 10:17:04 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	62/25-02576-F9090645; Mon, 10 Nov 2014 10:17:03 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415614621!12446075!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31705 invoked from network); 10 Nov 2014 10:17:02 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-13.tower-27.messagelabs.com with SMTP;
	10 Nov 2014 10:17:02 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id C51F8DA;
	Mon, 10 Nov 2014 04:16:56 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 8626E5FAD7;
	Mon, 10 Nov 2014 04:16:49 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 2AD3E13F8F4;
	Mon, 10 Nov 2014 04:16:48 -0600 (CST)
Date: Mon, 10 Nov 2014 10:16:46 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110101645.GA21366@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
	<20141107181430.GH29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071834540.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411071834540.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 06:45:22PM +0000, Stefano Stabellini wrote:
> On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > On Fri, Nov 07, 2014 at 05:35:41PM +0000, Stefano Stabellini wrote:
> > > On Fri, 7 Nov 2014, Stefano Stabellini wrote:
> > > > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > > > What I would like to see is xen_dma_map_page() also using hyp calls for
> > > > > cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> > > > > need another argument to xen_dma_map_page() though to pass the real
> > > > > device address or mfn (and on the map side you could simply check for
> > > > > page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> > > > > bouncing so you don't need dom0 swiotlb involved as well.
> > > > 
> > > > I can see that it would be nice to have map_page and unmap_page be
> > > > symmetrical. However actually doing the map_page flush with an hypercall
> > > > would slow things down. Hypercalls are slower than function calls. It is
> > > > faster to do the cache flushing in dom0 if possible. In the map_page
> > > > case we have the struct page so we can easily do it by calling the
> > > > native dma_ops function.
> > > > 
> > > > Maybe I could just add a comment to explain the reason for the asymmetry?
> > > 
> > > Ah, but the problem is that map_page could allocate a swiotlb buffer
> > > (actually it does on arm64) that without a corresponding unmap_page
> > > call, would end up being leaked, right?
> > 
> > Yes. You could hack dma_capable() to always return true for dom0
> > (because the pfn/dma address here doesn't have anything to do with the
> > real mfn) but that's more of a hack assuming a lot about the swiotlb
> > implementation.
> 
> Another idea would be to avoid calling the native map_page for foreign
> pages, but in the xen specific implementation instead of making the
> hypercall, we could call __dma_map_area on arm64 and map_page on arm.

The problem here is that you assume that for an SoC that is not fully
coherent all it needs is __dma_map_area. If you look at mach-mvebu, the
DMA is nearly cache coherent but it needs some specific synchronisation
barrier at the interconnect level. If we get something like this on a
platform with virtualisation, it would be implemented at the dom0 level
by SoC-specific DMA ops. Xen hypervisor I assume has its own BSP, hence
it could implement SoC specific cache flushing there. But with the mix
of cache flushing in dom0 on map and hypervisor on unmap such thing is
no longer be possible in a nice way.

> In arch/arm/include/asm/xen/page-coherent.h:
> 
> static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> 	     dma_addr_t dev_addr, unsigned long offset, size_t size,
> 	     enum dma_data_direction dir, struct dma_attrs *attrs)
> {
> 	if (pfn_valid(PFN_DOWN(dev_addr))) {

BTW, pfn_valid() is more expensive than simply comparing the mfn with
pfn for dom0. The calling code knows this already and it may be quicker
to simply pass a "bool foreign" argument.

> It wouldn't be as nice as using the hypercall but it would be faster and
> wouldn't depend on the inner workings of the arm64 implementation of
> map_page, except for __dma_map_area.

This "except" is big as we may at some point get some SoC like mvebu (I
would say less likely for arm64 than arm32).

BTW, does the Xen hypervisor already have a mapping of the mfn? If not
and it has to create one temporarily for the flush, you may not lose
much by using the dom0 ops for unmap with a hyper call for temporarily
mapping the foreign page in dom0's IPA space (you could do the unmapping
lazily).

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:52:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnmZ8-0006el-0d; Mon, 10 Nov 2014 10:51:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XnmZ6-0006eg-Is
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 10:51:20 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	24/3D-02954-7A890645; Mon, 10 Nov 2014 10:51:19 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415616669!12443005!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTkwMzkgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29198 invoked from network); 10 Nov 2014 10:51:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 10:51:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; 
	d="asc'?scan'208";a="189699454"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 05:51:07 -0500
Message-ID: <1415616688.3717.16.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 11:51:28 +0100
In-Reply-To: <20141110100016.GA17065@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Elena Ufimtseva <ufimtseva@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8046174122477965082=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8046174122477965082==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-BhSIc3fjd5+i1PeDaLSk"

--=-BhSIc3fjd5+i1PeDaLSk
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-10 at 10:00 +0000, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 09:21:24AM +0000, Jan Beulich wrote:
> > >>> On 08.11.14 at 20:43, <wei.liu2@citrix.com> wrote:
> > > This information is passed in in domctl hypercall but the guest
> > > interface doesn't expose it to guest. PV NUMA-aware ballooning relies=
 on
> > > this piece of information to function properly.
> >=20
> > Considering that exposing this mapping is wrong from a conceptual
> > pov (as was discussed during the review of Elena's original series),
> > the desire to nevertheless expose it would need to be explained
> > much better than what you did above.
> >=20
>=20
> My thought was that if a PV guest needs to do NUMA-aware ballooning, it
> would be easier to have the mapping at hand to let the guest request
> explicitly from what physical node it wants the page. It was based
> on my vague memory of early version of Elena's series.
>=20
Some discussion on this happened while talking about some early work on
NUMA-aware ballooning. This is a message from that thread:

http://lists.xenproject.org/archives/html/xen-devel/2013-08/msg01986.html

> However, if this is conceptually wrong and has been discussed before,
> (as I said in the other email) please just ignore this patch. I can try
> to modify the hypervisor instead to make NUMA-aware ballooning happen
> under the hood without guest knowing anything. That is, to make use of
> the vmemrange structure to identify the vnode of a particular gpfn, then
> with vnode_to_pnode map to identify the physical node of that gpfn, then
> do NUMA-aware ballooning.
>=20
I'm all for *not* exposing such information to the guest. However, a
quote from George, from that thread, with which I *totally* agree with,
is this one:

<<I would like to point out that to make this [NUMA aware ballooning]
  work for ballooning *up*, however, there will need to be a way for the
  guest to specify, "please allocate from vnode X", and have Xen
  translate the vnode into the appropriate pnode(s).>>

If this can be done without exposing the mapping, as Wei suggests, then
I agree we should go for it. If not, we'll have to introduce something
like this (along with proper documentation of how it should be used) at
some point.

I'm 100% ok to re-start that discussion here and now... however, how
stable should this interface be? Can't we deal with this when actually
implementing NUMA aware ballooning and add stuff at than point, if
necessary?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-BhSIc3fjd5+i1PeDaLSk
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 v2

iEYEABECAAYFAlRgmLAACgkQk4XaBE3IOsStUwCcCcHQGzN0yM2xTXdiFlRaoQ0M
TCIAnjaL+d6LzEj59TlkKiMB7RNWTEsn
=IFy0
-----END PGP SIGNATURE-----

--=-BhSIc3fjd5+i1PeDaLSk--


--===============8046174122477965082==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8046174122477965082==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 10:52:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnmZ8-0006el-0d; Mon, 10 Nov 2014 10:51:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XnmZ6-0006eg-Is
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 10:51:20 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	24/3D-02954-7A890645; Mon, 10 Nov 2014 10:51:19 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415616669!12443005!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTkwMzkgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29198 invoked from network); 10 Nov 2014 10:51:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 10:51:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; 
	d="asc'?scan'208";a="189699454"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 05:51:07 -0500
Message-ID: <1415616688.3717.16.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 11:51:28 +0100
In-Reply-To: <20141110100016.GA17065@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Elena Ufimtseva <ufimtseva@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8046174122477965082=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8046174122477965082==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-BhSIc3fjd5+i1PeDaLSk"

--=-BhSIc3fjd5+i1PeDaLSk
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-10 at 10:00 +0000, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 09:21:24AM +0000, Jan Beulich wrote:
> > >>> On 08.11.14 at 20:43, <wei.liu2@citrix.com> wrote:
> > > This information is passed in in domctl hypercall but the guest
> > > interface doesn't expose it to guest. PV NUMA-aware ballooning relies=
 on
> > > this piece of information to function properly.
> >=20
> > Considering that exposing this mapping is wrong from a conceptual
> > pov (as was discussed during the review of Elena's original series),
> > the desire to nevertheless expose it would need to be explained
> > much better than what you did above.
> >=20
>=20
> My thought was that if a PV guest needs to do NUMA-aware ballooning, it
> would be easier to have the mapping at hand to let the guest request
> explicitly from what physical node it wants the page. It was based
> on my vague memory of early version of Elena's series.
>=20
Some discussion on this happened while talking about some early work on
NUMA-aware ballooning. This is a message from that thread:

http://lists.xenproject.org/archives/html/xen-devel/2013-08/msg01986.html

> However, if this is conceptually wrong and has been discussed before,
> (as I said in the other email) please just ignore this patch. I can try
> to modify the hypervisor instead to make NUMA-aware ballooning happen
> under the hood without guest knowing anything. That is, to make use of
> the vmemrange structure to identify the vnode of a particular gpfn, then
> with vnode_to_pnode map to identify the physical node of that gpfn, then
> do NUMA-aware ballooning.
>=20
I'm all for *not* exposing such information to the guest. However, a
quote from George, from that thread, with which I *totally* agree with,
is this one:

<<I would like to point out that to make this [NUMA aware ballooning]
  work for ballooning *up*, however, there will need to be a way for the
  guest to specify, "please allocate from vnode X", and have Xen
  translate the vnode into the appropriate pnode(s).>>

If this can be done without exposing the mapping, as Wei suggests, then
I agree we should go for it. If not, we'll have to introduce something
like this (along with proper documentation of how it should be used) at
some point.

I'm 100% ok to re-start that discussion here and now... however, how
stable should this interface be? Can't we deal with this when actually
implementing NUMA aware ballooning and add stuff at than point, if
necessary?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-BhSIc3fjd5+i1PeDaLSk
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 v2

iEYEABECAAYFAlRgmLAACgkQk4XaBE3IOsStUwCcCcHQGzN0yM2xTXdiFlRaoQ0M
TCIAnjaL+d6LzEj59TlkKiMB7RNWTEsn
=IFy0
-----END PGP SIGNATURE-----

--=-BhSIc3fjd5+i1PeDaLSk--


--===============8046174122477965082==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8046174122477965082==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 10:58:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10: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 1Xnmg5-0006pi-0k; Mon, 10 Nov 2014 10:58: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@citrix.com>) id 1Xnmg3-0006pd-Bm
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 10:58:31 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	05/96-19763-65A90645; Mon, 10 Nov 2014 10:58:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415617107!8149002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21894 invoked from network); 10 Nov 2014 10:58:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 10:58:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191138456"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 05:58:26 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xnmfy-0005Q9-JF;
	Mon, 10 Nov 2014 10:58:26 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xnmfy-0005ee-D9;
	Mon, 10 Nov 2014 10:58:26 +0000
Date: Mon, 10 Nov 2014 10:58:26 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31395-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 10837
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31395: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2270286269749555895=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2270286269749555895==
Content-Type: text/plain
Content-Length: 10585
Content-Transfer-Encoding: quoted-printable

flight 31395 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31395/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                d5b4dc3b50175f0c34f3cf4b053e123fb37f5aed
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 10265 lines long.)


--===============2270286269749555895==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2270286269749555895==--

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:58:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10: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 1XnmgC-0006qk-It; Mon, 10 Nov 2014 10:58:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XnmgA-0006qS-N8
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 10:58:38 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	80/8B-02954-D5A90645; Mon, 10 Nov 2014 10:58:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415617117!12448876!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5925 invoked from network); 10 Nov 2014 10:58:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 10:58:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 10 Nov 2014 10:58:37 +0000
Message-Id: <5460A86A0200007800045F2E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 10 Nov 2014 10:58:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <dario.faggioli@citrix.com>,
	"Wei Liu" <wei.liu2@citrix.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
In-Reply-To: <1415616688.3717.16.camel@Abyss>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Elena Ufimtseva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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 10.11.14 at 11:51, <dario.faggioli@citrix.com> wrote:
> I'm 100% ok to re-start that discussion here and now... however, how
> stable should this interface be? Can't we deal with this when actually
> implementing NUMA aware ballooning and add stuff at than point, if
> necessary?

Wei's desire to have a stable interface for 4.5 and later is quite
reasonable, as we can't change the interface once a release got
shipped with it. If we were to discover additional needs later, only
backward compatible changes to the existing interface would be
allowed (and e.g. adding another field to the interface structure
would be out of scope).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:58:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10: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 1Xnmg5-0006pi-0k; Mon, 10 Nov 2014 10:58: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@citrix.com>) id 1Xnmg3-0006pd-Bm
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 10:58:31 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	05/96-19763-65A90645; Mon, 10 Nov 2014 10:58:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415617107!8149002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21894 invoked from network); 10 Nov 2014 10:58:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 10:58:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191138456"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 05:58:26 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xnmfy-0005Q9-JF;
	Mon, 10 Nov 2014 10:58:26 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xnmfy-0005ee-D9;
	Mon, 10 Nov 2014 10:58:26 +0000
Date: Mon, 10 Nov 2014 10:58:26 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31395-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 10837
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31395: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2270286269749555895=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2270286269749555895==
Content-Type: text/plain
Content-Length: 10585
Content-Transfer-Encoding: quoted-printable

flight 31395 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31395/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                d5b4dc3b50175f0c34f3cf4b053e123fb37f5aed
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 10265 lines long.)


--===============2270286269749555895==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2270286269749555895==--

From xen-devel-bounces@lists.xen.org Mon Nov 10 10:58:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 10: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 1XnmgC-0006qk-It; Mon, 10 Nov 2014 10:58:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XnmgA-0006qS-N8
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 10:58:38 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	80/8B-02954-D5A90645; Mon, 10 Nov 2014 10:58:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415617117!12448876!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5925 invoked from network); 10 Nov 2014 10:58:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 10:58:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 10 Nov 2014 10:58:37 +0000
Message-Id: <5460A86A0200007800045F2E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 10 Nov 2014 10:58:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <dario.faggioli@citrix.com>,
	"Wei Liu" <wei.liu2@citrix.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
In-Reply-To: <1415616688.3717.16.camel@Abyss>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Elena Ufimtseva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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 10.11.14 at 11:51, <dario.faggioli@citrix.com> wrote:
> I'm 100% ok to re-start that discussion here and now... however, how
> stable should this interface be? Can't we deal with this when actually
> implementing NUMA aware ballooning and add stuff at than point, if
> necessary?

Wei's desire to have a stable interface for 4.5 and later is quite
reasonable, as we can't change the interface once a release got
shipped with it. If we were to discover additional needs later, only
backward compatible changes to the existing interface would be
allowed (and e.g. adding another field to the interface structure
would be out of scope).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:10:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnmqz-0007Cd-Ub; Mon, 10 Nov 2014 11:09:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xnmqy-0007CY-Us
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:09:49 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	C7/42-02712-CFC90645; Mon, 10 Nov 2014 11:09:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415617777!7044520!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDg0OTEgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12350 invoked from network); 10 Nov 2014 11:09:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:09:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189703260"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:09:36 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xnmqm-0002RW-Om;
	Mon, 10 Nov 2014 11:09:36 +0000
Date: Mon, 10 Nov 2014 11:09:36 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141110110936.GA28360@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415616688.3717.16.camel@Abyss>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Elena Ufimtseva <ufimtseva@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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 Mon, Nov 10, 2014 at 11:51:28AM +0100, Dario Faggioli wrote:
> On Mon, 2014-11-10 at 10:00 +0000, Wei Liu wrote:
> > On Mon, Nov 10, 2014 at 09:21:24AM +0000, Jan Beulich wrote:
> > > >>> On 08.11.14 at 20:43, <wei.liu2@citrix.com> wrote:
> > > > This information is passed in in domctl hypercall but the guest
> > > > interface doesn't expose it to guest. PV NUMA-aware ballooning relies on
> > > > this piece of information to function properly.
> > > 
> > > Considering that exposing this mapping is wrong from a conceptual
> > > pov (as was discussed during the review of Elena's original series),
> > > the desire to nevertheless expose it would need to be explained
> > > much better than what you did above.
> > > 
> > 
> > My thought was that if a PV guest needs to do NUMA-aware ballooning, it
> > would be easier to have the mapping at hand to let the guest request
> > explicitly from what physical node it wants the page. It was based
> > on my vague memory of early version of Elena's series.
> > 
> Some discussion on this happened while talking about some early work on
> NUMA-aware ballooning. This is a message from that thread:
> 
> http://lists.xenproject.org/archives/html/xen-devel/2013-08/msg01986.html
> 

Phew! That's a year ago. No wonder I don't remember anything...

> > However, if this is conceptually wrong and has been discussed before,
> > (as I said in the other email) please just ignore this patch. I can try
> > to modify the hypervisor instead to make NUMA-aware ballooning happen
> > under the hood without guest knowing anything. That is, to make use of
> > the vmemrange structure to identify the vnode of a particular gpfn, then
> > with vnode_to_pnode map to identify the physical node of that gpfn, then
> > do NUMA-aware ballooning.
> > 
> I'm all for *not* exposing such information to the guest. However, a
> quote from George, from that thread, with which I *totally* agree with,
> is this one:
> 
> <<I would like to point out that to make this [NUMA aware ballooning]
>   work for ballooning *up*, however, there will need to be a way for the
>   guest to specify, "please allocate from vnode X", and have Xen
>   translate the vnode into the appropriate pnode(s).>>
> 
> If this can be done without exposing the mapping, as Wei suggests, then
> I agree we should go for it. If not, we'll have to introduce something
> like this (along with proper documentation of how it should be used) at
> some point.
> 
> I'm 100% ok to re-start that discussion here and now... however, how
> stable should this interface be? Can't we deal with this when actually
> implementing NUMA aware ballooning and add stuff at than point, if
> necessary?
> 

The risk would be any new guests with extended get_vnumainfo interface
won't be able to run on old hypervisor (4.5) without proper versioning.

So basically we have three choices:
1. Expose vnode_to_pnode in hypercall interface.
2. Expose the mapping in xenstore.
3. Don't expose anything, everything happens automagically without guest
   knowing anything.

I'm fine with any of those three. However, Jan suggested in that one
year old thread it would be wrong for the guest to know the mapping, so
I think he implicitly voted for the third option.

I only need to make sure that we don't miss option 1 and release
incomplete interface for 4.5. That's why I kick off this discussion.  If
we release the interface as it is now and find out we need to expose
mapping later, we would neither 1) do versioning 2) have yet another
interface to return mapping.

Wei.

> Regards,
> Dario
> 
> -- 
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:10:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnmqz-0007Cd-Ub; Mon, 10 Nov 2014 11:09:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xnmqy-0007CY-Us
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:09:49 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	C7/42-02712-CFC90645; Mon, 10 Nov 2014 11:09:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415617777!7044520!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDg0OTEgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12350 invoked from network); 10 Nov 2014 11:09:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:09:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189703260"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:09:36 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xnmqm-0002RW-Om;
	Mon, 10 Nov 2014 11:09:36 +0000
Date: Mon, 10 Nov 2014 11:09:36 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141110110936.GA28360@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415616688.3717.16.camel@Abyss>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Elena Ufimtseva <ufimtseva@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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 Mon, Nov 10, 2014 at 11:51:28AM +0100, Dario Faggioli wrote:
> On Mon, 2014-11-10 at 10:00 +0000, Wei Liu wrote:
> > On Mon, Nov 10, 2014 at 09:21:24AM +0000, Jan Beulich wrote:
> > > >>> On 08.11.14 at 20:43, <wei.liu2@citrix.com> wrote:
> > > > This information is passed in in domctl hypercall but the guest
> > > > interface doesn't expose it to guest. PV NUMA-aware ballooning relies on
> > > > this piece of information to function properly.
> > > 
> > > Considering that exposing this mapping is wrong from a conceptual
> > > pov (as was discussed during the review of Elena's original series),
> > > the desire to nevertheless expose it would need to be explained
> > > much better than what you did above.
> > > 
> > 
> > My thought was that if a PV guest needs to do NUMA-aware ballooning, it
> > would be easier to have the mapping at hand to let the guest request
> > explicitly from what physical node it wants the page. It was based
> > on my vague memory of early version of Elena's series.
> > 
> Some discussion on this happened while talking about some early work on
> NUMA-aware ballooning. This is a message from that thread:
> 
> http://lists.xenproject.org/archives/html/xen-devel/2013-08/msg01986.html
> 

Phew! That's a year ago. No wonder I don't remember anything...

> > However, if this is conceptually wrong and has been discussed before,
> > (as I said in the other email) please just ignore this patch. I can try
> > to modify the hypervisor instead to make NUMA-aware ballooning happen
> > under the hood without guest knowing anything. That is, to make use of
> > the vmemrange structure to identify the vnode of a particular gpfn, then
> > with vnode_to_pnode map to identify the physical node of that gpfn, then
> > do NUMA-aware ballooning.
> > 
> I'm all for *not* exposing such information to the guest. However, a
> quote from George, from that thread, with which I *totally* agree with,
> is this one:
> 
> <<I would like to point out that to make this [NUMA aware ballooning]
>   work for ballooning *up*, however, there will need to be a way for the
>   guest to specify, "please allocate from vnode X", and have Xen
>   translate the vnode into the appropriate pnode(s).>>
> 
> If this can be done without exposing the mapping, as Wei suggests, then
> I agree we should go for it. If not, we'll have to introduce something
> like this (along with proper documentation of how it should be used) at
> some point.
> 
> I'm 100% ok to re-start that discussion here and now... however, how
> stable should this interface be? Can't we deal with this when actually
> implementing NUMA aware ballooning and add stuff at than point, if
> necessary?
> 

The risk would be any new guests with extended get_vnumainfo interface
won't be able to run on old hypervisor (4.5) without proper versioning.

So basically we have three choices:
1. Expose vnode_to_pnode in hypercall interface.
2. Expose the mapping in xenstore.
3. Don't expose anything, everything happens automagically without guest
   knowing anything.

I'm fine with any of those three. However, Jan suggested in that one
year old thread it would be wrong for the guest to know the mapping, so
I think he implicitly voted for the third option.

I only need to make sure that we don't miss option 1 and release
incomplete interface for 4.5. That's why I kick off this discussion.  If
we release the interface as it is now and find out we need to expose
mapping later, we would neither 1) do versioning 2) have yet another
interface to return mapping.

Wei.

> Regards,
> Dario
> 
> -- 
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:13:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:13:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnmuR-0007MK-Ky; Mon, 10 Nov 2014 11:13:23 +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 1XnmuQ-0007ME-Am
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 11:13:22 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	3C/A4-22819-1DD90645; Mon, 10 Nov 2014 11:13:21 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415617999!7381767!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12909 invoked from network); 10 Nov 2014 11:13:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:13:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189704062"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:13:18 -0500
Received: from etemp.uk.xensource.com ([10.80.228.66]
	helo=etemp.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <paul.durrant@citrix.com>)	id 1XnmuM-0002W2-DQ;
	Mon, 10 Nov 2014 11:13:18 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Mon, 10 Nov 2014 11:13:16 +0000
Message-ID: <1415617996-18632-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Paul Durrant <paul.durrant@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH v3] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

HVM guests have always been confined to using the domain callback
via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications.
This is usually an IOAPIC vector and is only used if the event
channel is bound to vcpu 0.

PV-on-HVM Linux uses a local APIC vector for event channel upcall,
set using HVM_PARAM_CALLBACK_IRQ by ORing in a special bit (bit 57)
into the value (see params.h), but this mechanism is not suitable
in the general case since the vector must be the same on all vcpus
which cannot be guaranteed on some OS (e.g. Windows).

This patch adds a new HVM op allowing a guest to specify a local
APIC vector to use as an upcall notification for a specific vcpu
therefore coping with the case of differing vector numbers.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
v2:
 - Addressed comments from Andrew Cooper
   - Check vector >=16
   - Put hypercall in x86-specific section

v3:
 - Addressed comments from Jan Beulich
   - More verbose check-in comment

 xen/arch/x86/hvm/hvm.c          |   39 +++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/hvm/irq.c          |    9 +++++++++
 xen/include/asm-x86/hvm/vcpu.h  |    1 +
 xen/include/public/hvm/hvm_op.h |   20 ++++++++++++++++++++
 4 files changed, 69 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 330c722..a4bcb58 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5462,6 +5462,40 @@ static int hvmop_destroy_ioreq_server(
     return rc;
 }
 
+static int hvmop_set_evtchn_upcall_vector(
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t) uop)
+{
+    xen_hvm_set_evtchn_upcall_vector_t op;
+    struct domain *d;
+    struct vcpu *v;
+    int rc;
+
+    if ( copy_from_guest(&op, uop, 1) )
+        return -EFAULT;
+
+    d = rcu_lock_current_domain();
+
+    rc = -EINVAL;
+    if ( !is_hvm_domain(d) )
+        goto out;
+
+    if ( op.vector < 0x10 )
+        goto out;
+
+    rc = -ENOENT;
+    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
+        goto out;
+
+    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
+
+    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
+    rc = 0;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 #define HVMOP_op_mask 0xff
 
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
@@ -5503,6 +5537,11 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
             guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
         break;
     
+    case HVMOP_set_evtchn_upcall_vector:
+        rc = hvmop_set_evtchn_upcall_vector(
+            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
+        break;
+    
     case HVMOP_set_param:
     case HVMOP_get_param:
     {
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 35f4f94..3e4c0b4 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
     spin_unlock(&d->arch.hvm_domain.irq_lock);
 }
 
+static void hvm_set_upcall_irq(struct vcpu *v)
+{
+    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
+
+    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
+}
+
 static void hvm_set_callback_irq_level(struct vcpu *v)
 {
     struct domain *d = v->domain;
@@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
 
     if ( is_hvm_pv_evtchn_vcpu(v) )
         vcpu_kick(v);
+    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
+        hvm_set_upcall_irq(v);
     else if ( v->vcpu_id == 0 )
         hvm_set_callback_irq_level(v);
 }
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..edd4523 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -160,6 +160,7 @@ struct hvm_vcpu {
     } u;
 
     struct tasklet      assert_evtchn_irq_tasklet;
+    u8                  evtchn_upcall_vector;
 
     struct nestedvcpu   nvcpu;
 
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index eeb0a60..cfbf85d 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -369,6 +369,26 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
 
 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
 
+#if defined(__i386__) || defined(__x86_64__)
+
+/*
+ * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used for event
+ *                                 channel upcalls on the specified <vcpu>. If set,
+ *                                 this vector will be used in preference to the
+ *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
+ *                                 and hence allows HVM guests to bind event
+ *                                 event channels to a vcpu other than 0.
+ */
+#define HVMOP_set_evtchn_upcall_vector 23
+struct xen_hvm_set_evtchn_upcall_vector {
+    uint32_t vcpu;
+    uint8_t vector;
+};
+typedef struct xen_hvm_set_evtchn_upcall_vector xen_hvm_set_evtchn_upcall_vector_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
+
+#endif /* defined(__i386__) || defined(__x86_64__) */
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:13:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:13:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnmuR-0007MK-Ky; Mon, 10 Nov 2014 11:13:23 +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 1XnmuQ-0007ME-Am
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 11:13:22 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	3C/A4-22819-1DD90645; Mon, 10 Nov 2014 11:13:21 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415617999!7381767!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12909 invoked from network); 10 Nov 2014 11:13:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:13:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189704062"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:13:18 -0500
Received: from etemp.uk.xensource.com ([10.80.228.66]
	helo=etemp.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <paul.durrant@citrix.com>)	id 1XnmuM-0002W2-DQ;
	Mon, 10 Nov 2014 11:13:18 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Mon, 10 Nov 2014 11:13:16 +0000
Message-ID: <1415617996-18632-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Paul Durrant <paul.durrant@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH v3] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

HVM guests have always been confined to using the domain callback
via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications.
This is usually an IOAPIC vector and is only used if the event
channel is bound to vcpu 0.

PV-on-HVM Linux uses a local APIC vector for event channel upcall,
set using HVM_PARAM_CALLBACK_IRQ by ORing in a special bit (bit 57)
into the value (see params.h), but this mechanism is not suitable
in the general case since the vector must be the same on all vcpus
which cannot be guaranteed on some OS (e.g. Windows).

This patch adds a new HVM op allowing a guest to specify a local
APIC vector to use as an upcall notification for a specific vcpu
therefore coping with the case of differing vector numbers.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
v2:
 - Addressed comments from Andrew Cooper
   - Check vector >=16
   - Put hypercall in x86-specific section

v3:
 - Addressed comments from Jan Beulich
   - More verbose check-in comment

 xen/arch/x86/hvm/hvm.c          |   39 +++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/hvm/irq.c          |    9 +++++++++
 xen/include/asm-x86/hvm/vcpu.h  |    1 +
 xen/include/public/hvm/hvm_op.h |   20 ++++++++++++++++++++
 4 files changed, 69 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 330c722..a4bcb58 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5462,6 +5462,40 @@ static int hvmop_destroy_ioreq_server(
     return rc;
 }
 
+static int hvmop_set_evtchn_upcall_vector(
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t) uop)
+{
+    xen_hvm_set_evtchn_upcall_vector_t op;
+    struct domain *d;
+    struct vcpu *v;
+    int rc;
+
+    if ( copy_from_guest(&op, uop, 1) )
+        return -EFAULT;
+
+    d = rcu_lock_current_domain();
+
+    rc = -EINVAL;
+    if ( !is_hvm_domain(d) )
+        goto out;
+
+    if ( op.vector < 0x10 )
+        goto out;
+
+    rc = -ENOENT;
+    if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
+        goto out;
+
+    printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
+
+    v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
+    rc = 0;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 #define HVMOP_op_mask 0xff
 
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
@@ -5503,6 +5537,11 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
             guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
         break;
     
+    case HVMOP_set_evtchn_upcall_vector:
+        rc = hvmop_set_evtchn_upcall_vector(
+            guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
+        break;
+    
     case HVMOP_set_param:
     case HVMOP_get_param:
     {
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 35f4f94..3e4c0b4 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
     spin_unlock(&d->arch.hvm_domain.irq_lock);
 }
 
+static void hvm_set_upcall_irq(struct vcpu *v)
+{
+    uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
+
+    vlapic_set_irq(vcpu_vlapic(v), vector, 0);
+}
+
 static void hvm_set_callback_irq_level(struct vcpu *v)
 {
     struct domain *d = v->domain;
@@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
 
     if ( is_hvm_pv_evtchn_vcpu(v) )
         vcpu_kick(v);
+    else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
+        hvm_set_upcall_irq(v);
     else if ( v->vcpu_id == 0 )
         hvm_set_callback_irq_level(v);
 }
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..edd4523 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -160,6 +160,7 @@ struct hvm_vcpu {
     } u;
 
     struct tasklet      assert_evtchn_irq_tasklet;
+    u8                  evtchn_upcall_vector;
 
     struct nestedvcpu   nvcpu;
 
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index eeb0a60..cfbf85d 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -369,6 +369,26 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
 
 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
 
+#if defined(__i386__) || defined(__x86_64__)
+
+/*
+ * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used for event
+ *                                 channel upcalls on the specified <vcpu>. If set,
+ *                                 this vector will be used in preference to the
+ *                                 domain callback via (see HVM_PARAM_CALLBACK_IRQ)
+ *                                 and hence allows HVM guests to bind event
+ *                                 event channels to a vcpu other than 0.
+ */
+#define HVMOP_set_evtchn_upcall_vector 23
+struct xen_hvm_set_evtchn_upcall_vector {
+    uint32_t vcpu;
+    uint8_t vector;
+};
+typedef struct xen_hvm_set_evtchn_upcall_vector xen_hvm_set_evtchn_upcall_vector_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
+
+#endif /* defined(__i386__) || defined(__x86_64__) */
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:16:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:16:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnmxg-0007V7-9u; Mon, 10 Nov 2014 11:16: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 1Xnmxf-0007Uw-3o
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:16:43 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	22/85-29352-A9E90645; Mon, 10 Nov 2014 11:16:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415618200!11522351!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10012 invoked from network); 10 Nov 2014 11:16:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:16:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189705546"
Message-ID: <1415618193.28370.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Mon, 10 Nov 2014 11:16:33 +0000
In-Reply-To: <545B8FAE.9090608@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
	<1415180713.11486.61.camel@citrix.com> <545A118B.7040309@web2web.at>
	<1415191140.15317.11.camel@citrix.com> <545B8FAE.9090608@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 16:11 +0100, Atom2 wrote:

> It's probably also worth mentioning that gcc is (and also was with the 
> older gcc-4.7.3) the hardened gcc version of gentoo which forces 
> position-independent executables (PIE), stack smashing protection (SPP) 
> and compile time buffer checks (see 
> http://wiki.gentoo.org/wiki/Hardened_Gentoo). The rest of hardend (PAX, 
> grSecurity, SELinux is not (and never was) in use (so far). I don't know 
> whether any of this might have contributed to the problems I am 
> currently being faced with.

Is it at all possible to recompile at least the Xen toolstack bits with
these extra gcc features disabled? Either by using the old compiler or
somehow (CFLAGS?) disabling those features of the new one.

I'm afraid it's looking more and more like a toolchain issue. I'm not
expert on this side on things but it looks to me like you are hitting an
issue with some sort of buffer overflow check gone wrong? I think you'll
need a gcc hardening person for this one.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:16:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:16:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnmxg-0007V7-9u; Mon, 10 Nov 2014 11:16: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 1Xnmxf-0007Uw-3o
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:16:43 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	22/85-29352-A9E90645; Mon, 10 Nov 2014 11:16:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415618200!11522351!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10012 invoked from network); 10 Nov 2014 11:16:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:16:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189705546"
Message-ID: <1415618193.28370.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Mon, 10 Nov 2014 11:16:33 +0000
In-Reply-To: <545B8FAE.9090608@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
	<1415180713.11486.61.camel@citrix.com> <545A118B.7040309@web2web.at>
	<1415191140.15317.11.camel@citrix.com> <545B8FAE.9090608@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 16:11 +0100, Atom2 wrote:

> It's probably also worth mentioning that gcc is (and also was with the 
> older gcc-4.7.3) the hardened gcc version of gentoo which forces 
> position-independent executables (PIE), stack smashing protection (SPP) 
> and compile time buffer checks (see 
> http://wiki.gentoo.org/wiki/Hardened_Gentoo). The rest of hardend (PAX, 
> grSecurity, SELinux is not (and never was) in use (so far). I don't know 
> whether any of this might have contributed to the problems I am 
> currently being faced with.

Is it at all possible to recompile at least the Xen toolstack bits with
these extra gcc features disabled? Either by using the old compiler or
somehow (CFLAGS?) disabling those features of the new one.

I'm afraid it's looking more and more like a toolchain issue. I'm not
expert on this side on things but it looks to me like you are hitting an
issue with some sort of buffer overflow check gone wrong? I think you'll
need a gcc hardening person for this one.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:21:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11: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 1Xnn1p-0007e1-2v; Mon, 10 Nov 2014 11:21:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xnn1n-0007do-Op
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 11:20:59 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	06/47-22819-A9F90645; Mon, 10 Nov 2014 11:20:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415618456!6208807!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12877 invoked from network); 10 Nov 2014 11:20:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:20:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191144562"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 06:20:54 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xnn1i-0005X2-Rc;
	Mon, 10 Nov 2014 11:20:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xnn1i-0002dj-Lp;
	Mon, 10 Nov 2014 11:20:54 +0000
Date: Mon, 10 Nov 2014 11:20:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31397-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31397: 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 31397 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31397/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10  fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 build-i386                    5 xen-build               fail baseline untested
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10  fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 build-i386-pvops              5 kernel-build            fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 build-i386-rumpuserxen        1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                8e650107bb6961f82c81eac9161e80fa82ece56c
baseline version:
 linux                0df1f2487d2f0d04703f142813d53615d62a1da4

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       blocked 
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:21:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11: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 1Xnn1p-0007e1-2v; Mon, 10 Nov 2014 11:21:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xnn1n-0007do-Op
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 11:20:59 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	06/47-22819-A9F90645; Mon, 10 Nov 2014 11:20:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415618456!6208807!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12877 invoked from network); 10 Nov 2014 11:20:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:20:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191144562"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 06:20:54 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xnn1i-0005X2-Rc;
	Mon, 10 Nov 2014 11:20:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xnn1i-0002dj-Lp;
	Mon, 10 Nov 2014 11:20:54 +0000
Date: Mon, 10 Nov 2014 11:20:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31397-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31397: 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 31397 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31397/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10  fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 build-i386                    5 xen-build               fail baseline untested
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10  fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 build-i386-pvops              5 kernel-build            fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 build-i386-rumpuserxen        1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                8e650107bb6961f82c81eac9161e80fa82ece56c
baseline version:
 linux                0df1f2487d2f0d04703f142813d53615d62a1da4

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       blocked 
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:22:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnn2m-0007kN-NV; Mon, 10 Nov 2014 11:22:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xnn2l-0007kG-4r
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:21:59 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	10/97-02696-6DF90645; Mon, 10 Nov 2014 11:21:58 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415618516!12433250!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6279 invoked from network); 10 Nov 2014 11:21:57 -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;
	10 Nov 2014 11:21:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191144706"
Message-ID: <54609FC4.3010101@citrix.com>
Date: Mon, 10 Nov 2014 11:21:40 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, Dario Faggioli <dario.faggioli@citrix.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>	<546091A40200007800045E86@mail.emea.novell.com>	<20141110100016.GA17065@zion.uk.xensource.com>	<1415616688.3717.16.camel@Abyss>
	<20141110110936.GA28360@zion.uk.xensource.com>
In-Reply-To: <20141110110936.GA28360@zion.uk.xensource.com>
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
 to 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 10/11/14 11:09, Wei Liu wrote:
> 
> 3. Don't expose anything, everything happens automagically without guest
>    knowing anything.

This.  The vnode to pnode mapping can change on a save/restore.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:22:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnn2m-0007kN-NV; Mon, 10 Nov 2014 11:22:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xnn2l-0007kG-4r
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:21:59 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	10/97-02696-6DF90645; Mon, 10 Nov 2014 11:21:58 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415618516!12433250!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6279 invoked from network); 10 Nov 2014 11:21:57 -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;
	10 Nov 2014 11:21:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191144706"
Message-ID: <54609FC4.3010101@citrix.com>
Date: Mon, 10 Nov 2014 11:21:40 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, Dario Faggioli <dario.faggioli@citrix.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>	<546091A40200007800045E86@mail.emea.novell.com>	<20141110100016.GA17065@zion.uk.xensource.com>	<1415616688.3717.16.camel@Abyss>
	<20141110110936.GA28360@zion.uk.xensource.com>
In-Reply-To: <20141110110936.GA28360@zion.uk.xensource.com>
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
 to 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 10/11/14 11:09, Wei Liu wrote:
> 
> 3. Don't expose anything, everything happens automagically without guest
>    knowing anything.

This.  The vnode to pnode mapping can change on a save/restore.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11: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 1Xnn8i-0007z5-Kj; Mon, 10 Nov 2014 11:28:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xnn8g-0007yv-Gk
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:28:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FF/97-09842-541A0645; Mon, 10 Nov 2014 11:28:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415618884!12683224!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9504 invoked from network); 10 Nov 2014 11:28:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:28:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189707117"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:27:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xnn8S-0002nU-1B;
	Mon, 10 Nov 2014 11:27:52 +0000
Date: Mon, 10 Nov 2014 11:27:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141110112751.GB28360@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
	<20141110110936.GA28360@zion.uk.xensource.com>
	<54609FC4.3010101@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54609FC4.3010101@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
 to 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 Mon, Nov 10, 2014 at 11:21:40AM +0000, David Vrabel wrote:
> On 10/11/14 11:09, Wei Liu wrote:
> > 
> > 3. Don't expose anything, everything happens automagically without guest
> >    knowing anything.
> 
> This.  The vnode to pnode mapping can change on a save/restore.

I don't think this is the most decisive reasoning of this issue. The
other two options can also deal with this -- just retrieve the
up-to-date versions after migration.

Wei.

> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11: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 1Xnn8i-0007z5-Kj; Mon, 10 Nov 2014 11:28:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xnn8g-0007yv-Gk
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:28:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FF/97-09842-541A0645; Mon, 10 Nov 2014 11:28:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415618884!12683224!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9504 invoked from network); 10 Nov 2014 11:28:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:28:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189707117"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:27:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xnn8S-0002nU-1B;
	Mon, 10 Nov 2014 11:27:52 +0000
Date: Mon, 10 Nov 2014 11:27:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141110112751.GB28360@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
	<20141110110936.GA28360@zion.uk.xensource.com>
	<54609FC4.3010101@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54609FC4.3010101@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
 to 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 Mon, Nov 10, 2014 at 11:21:40AM +0000, David Vrabel wrote:
> On 10/11/14 11:09, Wei Liu wrote:
> > 
> > 3. Don't expose anything, everything happens automagically without guest
> >    knowing anything.
> 
> This.  The vnode to pnode mapping can change on a save/restore.

I don't think this is the most decisive reasoning of this issue. The
other two options can also deal with this -- just retrieve the
up-to-date versions after migration.

Wei.

> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:34:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:34:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnEz-0008Ag-JO; Mon, 10 Nov 2014 11:34:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnnEy-0008Ab-0N
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:34:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	47/C9-09936-BC2A0645; Mon, 10 Nov 2014 11:34:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415619273!12699445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27404 invoked from network); 10 Nov 2014 11:34:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:34:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191146658"
Message-ID: <1415619271.28370.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Mon, 10 Nov 2014 11:34:31 +0000
In-Reply-To: <545B6E2B.9030303@linaro.org>
References: <545B6E2B.9030303@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: Bootwrapper update to support PSCI and
	GICv3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 12:48 +0000, Julien Grall wrote:
> Hello all,
> 
> I've been working on updating our aarch64 bootwrapper
> to support new feature such as PSCI and GICv3.
> 
> Rather than porting the feature from the Linux bootwrapper [1].
> I've added support of Xen on top of the Linux repo.
> 
> Below an example to configure bootwrapper with GICv3 and PSCI for
> the foundation model:
> 
> 42sh> ./configure --host=aarch64-linux-gnu		\
> --with-kernel-dir=$HOME/linux-build/aarch64	\
> --with-dtb=$HOME/arm-trusted-firmware/fdts/fvp-foundation-gicv3-psci.dtb \
> --with-cmdline="console=hvc0 earlycon=pl011,0x1c090000 init=/root/init.sh root=/dev/vda" \
> --enable-psci --with-xen-cmdline="dtuart=serial0 console=dtuart no-bootscrub"		 \
> --with-xen="$HOME/xen" --enable-gicv3
> 42sh> make
> 
> Make will produce a xen-system.axf which is the image used to boot
> Xen on the model.
> 
> The branch with the new version is:
> git://xenbits.xen.org/people/julieng/boot-wrapper-aarch64.git branch xen
> 
> Ian, can you update your repo with this new version?

FWIW I've been happily using
https://git.linaro.org/people/christoffer.dall/boot-wrapper-aarch64.git/shortlog/refs/heads/xen-psci-support at 7e702c7892d0965f459a61d36e4c8f1a9d6ee6df plus the following fixup (which I've been remiss in not sending out).

Given that we are now in a state where the patches appear to be nicely
in keeping with the wrapper's architecture and therefore potentially
upstreamable I'd like to at least have that conversation with the
maintainers (probably via a patch set submission) before we carry on
with a fork.

Ian.

diff --git a/Makefile.am b/Makefile.am
index 9b6c7e3..6c2786e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -69,8 +69,9 @@ XEN_OFFSET	:= 0xA00000
 DOM0_OFFSET	:= $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
 XEN_BOOTARGS	:= xen,xen-bootargs = \"$(BOOTARGS)\";			\
 		   module@1 {						\
+			bootargs = \"$(CMDLINE)\";			\
 			compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
-			reg = <$(DOM0_OFFSET) 0x800000>;		\
+			reg = <0 $(DOM0_OFFSET) 0 0x800000>;		\
 		   };
 endif
 
@@ -97,7 +98,10 @@ all: $(IMAGE) $(XIMAGE)
 
 CLEANFILES = $(IMAGE) boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb
 
-$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
+if XEN
+XEN_IMAGE_DEP = $(XEN_IMAGE)
+endif
+$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE_DEP)
 	$(LD) -o $@ --script=model.lds
 
 %.o: %.S Makefile
diff --git a/configure.ac b/configure.ac
index 2f31fab..44b3bf0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -75,13 +75,14 @@ AC_ARG_WITH([initrd],
 AC_SUBST([FILESYSTEM], [$USE_INITRD])
 AM_CONDITIONAL([INITRD], [test "x$USE_INITRD" != "x"])
 
-C_CMDLINE="console=ttyAMA0 earlyprintk=pl011,0x1c090000"
+AS_IF([test "x$XEN_IMAGE" = "no"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
+C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c090000"
 AC_ARG_WITH([cmdline],
 	AS_HELP_STRING([--with-cmdline], [set a command line for the kernel]),
 	[C_CMDLINE=$withval])
 AC_SUBST([CMDLINE], [$C_CMDLINE])
 
-X_BOOTARGS="console=dtuart dtuart=serial0"
+X_BOOTARGS="console=dtuart dtuart=serial0 no-bootscrub"
 AC_ARG_WITH([xen-bootargs],
 	AS_HELP_STRING([--with-xen-bootargs], [set Xen bootargs]),
 	[X_BOOTARGS=$withval])



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:34:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:34:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnEz-0008Ag-JO; Mon, 10 Nov 2014 11:34:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnnEy-0008Ab-0N
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:34:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	47/C9-09936-BC2A0645; Mon, 10 Nov 2014 11:34:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415619273!12699445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27404 invoked from network); 10 Nov 2014 11:34:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:34:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191146658"
Message-ID: <1415619271.28370.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Mon, 10 Nov 2014 11:34:31 +0000
In-Reply-To: <545B6E2B.9030303@linaro.org>
References: <545B6E2B.9030303@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: Bootwrapper update to support PSCI and
	GICv3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 12:48 +0000, Julien Grall wrote:
> Hello all,
> 
> I've been working on updating our aarch64 bootwrapper
> to support new feature such as PSCI and GICv3.
> 
> Rather than porting the feature from the Linux bootwrapper [1].
> I've added support of Xen on top of the Linux repo.
> 
> Below an example to configure bootwrapper with GICv3 and PSCI for
> the foundation model:
> 
> 42sh> ./configure --host=aarch64-linux-gnu		\
> --with-kernel-dir=$HOME/linux-build/aarch64	\
> --with-dtb=$HOME/arm-trusted-firmware/fdts/fvp-foundation-gicv3-psci.dtb \
> --with-cmdline="console=hvc0 earlycon=pl011,0x1c090000 init=/root/init.sh root=/dev/vda" \
> --enable-psci --with-xen-cmdline="dtuart=serial0 console=dtuart no-bootscrub"		 \
> --with-xen="$HOME/xen" --enable-gicv3
> 42sh> make
> 
> Make will produce a xen-system.axf which is the image used to boot
> Xen on the model.
> 
> The branch with the new version is:
> git://xenbits.xen.org/people/julieng/boot-wrapper-aarch64.git branch xen
> 
> Ian, can you update your repo with this new version?

FWIW I've been happily using
https://git.linaro.org/people/christoffer.dall/boot-wrapper-aarch64.git/shortlog/refs/heads/xen-psci-support at 7e702c7892d0965f459a61d36e4c8f1a9d6ee6df plus the following fixup (which I've been remiss in not sending out).

Given that we are now in a state where the patches appear to be nicely
in keeping with the wrapper's architecture and therefore potentially
upstreamable I'd like to at least have that conversation with the
maintainers (probably via a patch set submission) before we carry on
with a fork.

Ian.

diff --git a/Makefile.am b/Makefile.am
index 9b6c7e3..6c2786e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -69,8 +69,9 @@ XEN_OFFSET	:= 0xA00000
 DOM0_OFFSET	:= $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
 XEN_BOOTARGS	:= xen,xen-bootargs = \"$(BOOTARGS)\";			\
 		   module@1 {						\
+			bootargs = \"$(CMDLINE)\";			\
 			compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
-			reg = <$(DOM0_OFFSET) 0x800000>;		\
+			reg = <0 $(DOM0_OFFSET) 0 0x800000>;		\
 		   };
 endif
 
@@ -97,7 +98,10 @@ all: $(IMAGE) $(XIMAGE)
 
 CLEANFILES = $(IMAGE) boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb
 
-$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
+if XEN
+XEN_IMAGE_DEP = $(XEN_IMAGE)
+endif
+$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE_DEP)
 	$(LD) -o $@ --script=model.lds
 
 %.o: %.S Makefile
diff --git a/configure.ac b/configure.ac
index 2f31fab..44b3bf0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -75,13 +75,14 @@ AC_ARG_WITH([initrd],
 AC_SUBST([FILESYSTEM], [$USE_INITRD])
 AM_CONDITIONAL([INITRD], [test "x$USE_INITRD" != "x"])
 
-C_CMDLINE="console=ttyAMA0 earlyprintk=pl011,0x1c090000"
+AS_IF([test "x$XEN_IMAGE" = "no"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
+C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c090000"
 AC_ARG_WITH([cmdline],
 	AS_HELP_STRING([--with-cmdline], [set a command line for the kernel]),
 	[C_CMDLINE=$withval])
 AC_SUBST([CMDLINE], [$C_CMDLINE])
 
-X_BOOTARGS="console=dtuart dtuart=serial0"
+X_BOOTARGS="console=dtuart dtuart=serial0 no-bootscrub"
 AC_ARG_WITH([xen-bootargs],
 	AS_HELP_STRING([--with-xen-bootargs], [set Xen bootargs]),
 	[X_BOOTARGS=$withval])



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:38:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:38:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnJ4-0008KJ-CH; Mon, 10 Nov 2014 11:38:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnnJ2-0008KC-Ja
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 11:38:48 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	C3/3E-17958-7C3A0645; Mon, 10 Nov 2014 11:38:47 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415619526!11531596!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24881 invoked from network); 10 Nov 2014 11:38:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:38:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191147312"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:38:44 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XnnIy-0002yM-TB;
	Mon, 10 Nov 2014 11:38:44 +0000
Date: Mon, 10 Nov 2014 11:38:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415613783.27002.2.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411101138020.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
	<7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
	<1415613783.27002.2.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, vijay.kilari@gmail.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	ian.jackson@eu.citrix.com, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Ian Campbell wrote:
> On Sat, 2014-11-08 at 15:26 -0500, Konrad Rzeszutek Wilk wrote:
> > That is to guard against somebody building against libxc or libxl and
> > then becoming dependent on this and then complaining that it is not in
> > Xen 4.6. 
> 
> libxc does not have a stable API and libxl doesn't expose this interface
> at all. At the hypercall level this is a domctl which simliarly has no
> stable interface.
> 
> So I don't think there is any need to wrap anything or guard against
> anything.

That's true. A comment in the header file wouldn't hurt though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:38:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:38:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnJ4-0008KJ-CH; Mon, 10 Nov 2014 11:38:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnnJ2-0008KC-Ja
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 11:38:48 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	C3/3E-17958-7C3A0645; Mon, 10 Nov 2014 11:38:47 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415619526!11531596!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24881 invoked from network); 10 Nov 2014 11:38:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:38:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191147312"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:38:44 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XnnIy-0002yM-TB;
	Mon, 10 Nov 2014 11:38:44 +0000
Date: Mon, 10 Nov 2014 11:38:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415613783.27002.2.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411101138020.22875@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
	<7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
	<1415613783.27002.2.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, vijay.kilari@gmail.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	ian.jackson@eu.citrix.com, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Ian Campbell wrote:
> On Sat, 2014-11-08 at 15:26 -0500, Konrad Rzeszutek Wilk wrote:
> > That is to guard against somebody building against libxc or libxl and
> > then becoming dependent on this and then complaining that it is not in
> > Xen 4.6. 
> 
> libxc does not have a stable API and libxl doesn't expose this interface
> at all. At the hypercall level this is a domctl which simliarly has no
> stable interface.
> 
> So I don't think there is any need to wrap anything or guard against
> anything.

That's true. A comment in the header file wouldn't hurt though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:41:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnLz-0008St-Vw; Mon, 10 Nov 2014 11:41:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XnnLy-0008Sj-UX
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:41:51 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	A4/AC-24859-E74A0645; Mon, 10 Nov 2014 11:41:50 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415619708!11535190!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12914 invoked from network); 10 Nov 2014 11:41:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:41:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; 
	d="asc'?scan'208";a="191147914"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:41:47 -0500
Message-ID: <1415619727.3717.28.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 12:42:07 +0100
In-Reply-To: <20141110110936.GA28360@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
	<20141110110936.GA28360@zion.uk.xensource.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
 to guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3747665096252345347=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3747665096252345347==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-yW/A62xvMkU68UCLArJ2"

--=-yW/A62xvMkU68UCLArJ2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-10 at 11:09 +0000, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 11:51:28AM +0100, Dario Faggioli wrote:
>
> > I'm 100% ok to re-start that discussion here and now... however, how
> > stable should this interface be? Can't we deal with this when actually
> > implementing NUMA aware ballooning and add stuff at than point, if
> > necessary?
> >=20
> The risk would be any new guests with extended get_vnumainfo interface
> won't be able to run on old hypervisor (4.5) without proper versioning.
>=20
Right.

> So basically we have three choices:
> 1. Expose vnode_to_pnode in hypercall interface.
> 2. Expose the mapping in xenstore.
> 3. Don't expose anything, everything happens automagically without guest
>    knowing anything.
>=20
> I'm fine with any of those three. However, Jan suggested in that one
> year old thread it would be wrong for the guest to know the mapping, so
> I think he implicitly voted for the third option.
>=20
Option 3 is the best IMO too. The guest, ideally, should know nothing
about how Xen mapped its virtual NUMA nodes onto the host RAM.

The question here is how effective that is. As of now, it's quite hard
to judge whether we'll be able to do everything automatically, I think.
I read your proposal, and it looks sensible, I'm just saying it's hard
to be conclusive at this stage.

> I only need to make sure that we don't miss option 1 and release
> incomplete interface for 4.5. That's why I kick off this discussion.  If
> we release the interface as it is now and find out we need to expose
> mapping later, we would neither 1) do versioning 2) have yet another
> interface to return mapping.
>=20
Exactly. Personally, I'd keep the mapping out of the interface we
already have checked in. If it will reveal impossible to do things
completely automatically, I don't think it will be too terrible to add a
new specific hypercall.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-yW/A62xvMkU68UCLArJ2
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 v2

iEYEABECAAYFAlRgpI8ACgkQk4XaBE3IOsRjBACcDOM8VMR9baM+DOo0pw46B9S/
dbkAnRJioDi9l9VRpoZTBIrd/xig2kpx
=FDaZ
-----END PGP SIGNATURE-----

--=-yW/A62xvMkU68UCLArJ2--


--===============3747665096252345347==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3747665096252345347==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 11:41:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnLz-0008St-Vw; Mon, 10 Nov 2014 11:41:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XnnLy-0008Sj-UX
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:41:51 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	A4/AC-24859-E74A0645; Mon, 10 Nov 2014 11:41:50 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415619708!11535190!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12914 invoked from network); 10 Nov 2014 11:41:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:41:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; 
	d="asc'?scan'208";a="191147914"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:41:47 -0500
Message-ID: <1415619727.3717.28.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 12:42:07 +0100
In-Reply-To: <20141110110936.GA28360@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
	<20141110110936.GA28360@zion.uk.xensource.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
 to guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3747665096252345347=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3747665096252345347==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-yW/A62xvMkU68UCLArJ2"

--=-yW/A62xvMkU68UCLArJ2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-10 at 11:09 +0000, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 11:51:28AM +0100, Dario Faggioli wrote:
>
> > I'm 100% ok to re-start that discussion here and now... however, how
> > stable should this interface be? Can't we deal with this when actually
> > implementing NUMA aware ballooning and add stuff at than point, if
> > necessary?
> >=20
> The risk would be any new guests with extended get_vnumainfo interface
> won't be able to run on old hypervisor (4.5) without proper versioning.
>=20
Right.

> So basically we have three choices:
> 1. Expose vnode_to_pnode in hypercall interface.
> 2. Expose the mapping in xenstore.
> 3. Don't expose anything, everything happens automagically without guest
>    knowing anything.
>=20
> I'm fine with any of those three. However, Jan suggested in that one
> year old thread it would be wrong for the guest to know the mapping, so
> I think he implicitly voted for the third option.
>=20
Option 3 is the best IMO too. The guest, ideally, should know nothing
about how Xen mapped its virtual NUMA nodes onto the host RAM.

The question here is how effective that is. As of now, it's quite hard
to judge whether we'll be able to do everything automatically, I think.
I read your proposal, and it looks sensible, I'm just saying it's hard
to be conclusive at this stage.

> I only need to make sure that we don't miss option 1 and release
> incomplete interface for 4.5. That's why I kick off this discussion.  If
> we release the interface as it is now and find out we need to expose
> mapping later, we would neither 1) do versioning 2) have yet another
> interface to return mapping.
>=20
Exactly. Personally, I'd keep the mapping out of the interface we
already have checked in. If it will reveal impossible to do things
completely automatically, I don't think it will be too terrible to add a
new specific hypercall.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-yW/A62xvMkU68UCLArJ2
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 v2

iEYEABECAAYFAlRgpI8ACgkQk4XaBE3IOsRjBACcDOM8VMR9baM+DOo0pw46B9S/
dbkAnRJioDi9l9VRpoZTBIrd/xig2kpx
=FDaZ
-----END PGP SIGNATURE-----

--=-yW/A62xvMkU68UCLArJ2--


--===============3747665096252345347==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3747665096252345347==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 11:43:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnNO-00008o-Ew; Mon, 10 Nov 2014 11:43: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@citrix.com>) id 1XnnNN-00008i-Pb
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:43:17 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	60/99-22777-5D4A0645; Mon, 10 Nov 2014 11:43:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415619795!11500505!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6897 invoked from network); 10 Nov 2014 11:43:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:43:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189709440"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:43:14 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnnNK-00033m-6e;
	Mon, 10 Nov 2014 11:43:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnnNJ-0002jY-Pr;
	Mon, 10 Nov 2014 11:43:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21600.42193.541875.658726@mariner.uk.xensource.com>
Date: Mon, 10 Nov 2014 11:43:13 +0000
To: Wen Congyang <wency@cn.fujitsu.com>
In-Reply-To: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch v2 0/3] Some bugfix patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wen Congyang writes ("[Patch v2 0/3] Some bugfix patches"):
> These bugs are found when we implement COLO, or rebase
> COLO to upstream xen. They are independent patches, so
> post them in separate series.

Thanks.  I can't seem to see any discussion of these bugfixes.  They
seem to have been dropped.  (I myself came across them while gardening
my inbox.)

IMO they should be considered for 4.5.  But they need review by the
relevant maintainers first.  I think the first patch need attention
from the x86 maintainers.  I will look at the other two.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:43:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnNO-00008o-Ew; Mon, 10 Nov 2014 11:43: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@citrix.com>) id 1XnnNN-00008i-Pb
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:43:17 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	60/99-22777-5D4A0645; Mon, 10 Nov 2014 11:43:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415619795!11500505!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6897 invoked from network); 10 Nov 2014 11:43:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:43:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189709440"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:43:14 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnnNK-00033m-6e;
	Mon, 10 Nov 2014 11:43:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnnNJ-0002jY-Pr;
	Mon, 10 Nov 2014 11:43:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21600.42193.541875.658726@mariner.uk.xensource.com>
Date: Mon, 10 Nov 2014 11:43:13 +0000
To: Wen Congyang <wency@cn.fujitsu.com>
In-Reply-To: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch v2 0/3] Some bugfix patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wen Congyang writes ("[Patch v2 0/3] Some bugfix patches"):
> These bugs are found when we implement COLO, or rebase
> COLO to upstream xen. They are independent patches, so
> post them in separate series.

Thanks.  I can't seem to see any discussion of these bugfixes.  They
seem to have been dropped.  (I myself came across them while gardening
my inbox.)

IMO they should be considered for 4.5.  But they need review by the
relevant maintainers first.  I think the first patch need attention
from the x86 maintainers.  I will look at the other two.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:44:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnOc-0000G8-T5; Mon, 10 Nov 2014 11:44:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XnnOb-0000G1-9y
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:44:33 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	92/B2-17735-025A0645; Mon, 10 Nov 2014 11:44:32 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415619871!11554338!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28946 invoked from network); 10 Nov 2014 11:44:32 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 11:44:32 -0000
Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XnnOZ-0004ve-IE; Mon, 10 Nov 2014 12:44:31 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.68])
	by justin.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XnnOZ-0003aT-6c; Mon, 10 Nov 2014 12:44:31 +0100
Message-ID: <5460A51E.9050401@web2web.at>
Date: Mon, 10 Nov 2014 12:44:30 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>							<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>						<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>					
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>				
	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>			
	<1415118690.11486.53.camel@citrix.com>
	<54590D4D.90300@web2web.at>		
	<1415180713.11486.61.camel@citrix.com>
	<545A118B.7040309@web2web.at>	
	<1415191140.15317.11.camel@citrix.com>
	<545B8FAE.9090608@web2web.at> <1415618193.28370.4.camel@citrix.com>
In-Reply-To: <1415618193.28370.4.camel@citrix.com>
X-Univie-Virus-Scan: scanned by ClamAV on justin.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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

Ian,
Thanks again for your reply.

Am 10.11.14 um 12:16 schrieb Ian Campbell:
> On Thu, 2014-11-06 at 16:11 +0100, Atom2 wrote:
>
> Is it at all possible to recompile at least the Xen toolstack bits with
> these extra gcc features disabled? Either by using the old compiler or
> somehow (CFLAGS?) disabling those features of the new one.
The old compiler (after I brought it in again) for reasons unknow to me 
still seemed to use the version of libgcc_s.so.1 from the newer compiler 
(which was part of the segfault issue - see my latest post from Sunday 
with debugging enabled for gcc and glibc and a full backtrace). But 
downgrading a compiler is anyways something that everybody warns from, 
so I then reverted back to gcc-4.8.3

Re disabling the hardened features for the compiler: I have also tested 
that over the weekend for xen-* stuff with the 4.8.3 compiler (I 
selected the vanilla variant of gcc for the compile process of the 
xen-bits) and that did not change anything - it was still segfaulting. 
But it's worth pointing out that test the rest of the system (including 
kernel, glibc and the rest of world) was still using the hardened toolchain.
>
> I'm afraid it's looking more and more like a toolchain issue. I'm not
> expert on this side on things but it looks to me like you are hitting an
> issue with some sort of buffer overflow check gone wrong? I think you'll
> need a gcc hardening person for this one.
The issue currently is with the guys at gentoo (for links please again 
see my latest post to the list from Sunday which also seems to confirm 
that the issue is not confined to 4.3.3 but also 4.4.1).

Thanks Atom2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:44:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnOc-0000G8-T5; Mon, 10 Nov 2014 11:44:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ariel.atom2@web2web.at>) id 1XnnOb-0000G1-9y
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:44:33 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	92/B2-17735-025A0645; Mon, 10 Nov 2014 11:44:32 +0000
X-Env-Sender: ariel.atom2@web2web.at
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415619871!11554338!1
X-Originating-IP: [131.130.3.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjEzMC4zLjExNSA9PiA0NTM2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28946 invoked from network); 10 Nov 2014 11:44:32 -0000
Received: from grace.univie.ac.at (HELO grace.univie.ac.at) (131.130.3.115)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 11:44:32 -0000
Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at)
	by grace.univie.ac.at with esmtps
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XnnOZ-0004ve-IE; Mon, 10 Nov 2014 12:44:31 +0100
Received: from zeus.herrenhauspark.com ([92.243.35.23] helo=[192.168.1.68])
	by justin.univie.ac.at with esmtpsa
	(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84)
	(envelope-from <ariel.atom2@web2web.at>)
	id 1XnnOZ-0003aT-6c; Mon, 10 Nov 2014 12:44:31 +0100
Message-ID: <5460A51E.9050401@web2web.at>
Date: Mon, 10 Nov 2014 12:44:30 +0100
From: Atom2 <ariel.atom2@web2web.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <544EB843.9060503@web2web.at>							<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>						<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>					
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>				
	<1415115868.11486.49.camel@citrix.com>
	<5458FB49.4040801@web2web.at>			
	<1415118690.11486.53.camel@citrix.com>
	<54590D4D.90300@web2web.at>		
	<1415180713.11486.61.camel@citrix.com>
	<545A118B.7040309@web2web.at>	
	<1415191140.15317.11.camel@citrix.com>
	<545B8FAE.9090608@web2web.at> <1415618193.28370.4.camel@citrix.com>
In-Reply-To: <1415618193.28370.4.camel@citrix.com>
X-Univie-Virus-Scan: scanned by ClamAV on justin.univie.ac.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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

Ian,
Thanks again for your reply.

Am 10.11.14 um 12:16 schrieb Ian Campbell:
> On Thu, 2014-11-06 at 16:11 +0100, Atom2 wrote:
>
> Is it at all possible to recompile at least the Xen toolstack bits with
> these extra gcc features disabled? Either by using the old compiler or
> somehow (CFLAGS?) disabling those features of the new one.
The old compiler (after I brought it in again) for reasons unknow to me 
still seemed to use the version of libgcc_s.so.1 from the newer compiler 
(which was part of the segfault issue - see my latest post from Sunday 
with debugging enabled for gcc and glibc and a full backtrace). But 
downgrading a compiler is anyways something that everybody warns from, 
so I then reverted back to gcc-4.8.3

Re disabling the hardened features for the compiler: I have also tested 
that over the weekend for xen-* stuff with the 4.8.3 compiler (I 
selected the vanilla variant of gcc for the compile process of the 
xen-bits) and that did not change anything - it was still segfaulting. 
But it's worth pointing out that test the rest of the system (including 
kernel, glibc and the rest of world) was still using the hardened toolchain.
>
> I'm afraid it's looking more and more like a toolchain issue. I'm not
> expert on this side on things but it looks to me like you are hitting an
> issue with some sort of buffer overflow check gone wrong? I think you'll
> need a gcc hardening person for this one.
The issue currently is with the guys at gentoo (for links please again 
see my latest post to the list from Sunday which also seems to confirm 
that the issue is not confined to 4.3.3 but also 4.4.1).

Thanks Atom2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:50:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnUZ-0000VW-Us; Mon, 10 Nov 2014 11:50:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnnUX-0000VP-ME
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:50:41 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	31/B1-26858-096A0645; Mon, 10 Nov 2014 11:50:40 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415620238!11556060!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20160 invoked from network); 10 Nov 2014 11:50:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:50:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191149834"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:50:13 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XnnU5-0003CV-7N;
	Mon, 10 Nov 2014 11:50:13 +0000
Date: Mon, 10 Nov 2014 11:50:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Wen Congyang <wency@cn.fujitsu.com>
In-Reply-To: <54604CEA.1060909@cn.fujitsu.com>
Message-ID: <alpine.DEB.2.02.1411101148300.22875@kaball.uk.xensource.com>
References: <54604CEA.1060909@cn.fujitsu.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Wen Congyang wrote:
> I disable xen-platform-pci in the config file, but when I start the guest, I found
> the following kernel message:
> [    0.000000] Booting paravirtualized kernel on Xen HVM
> [    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled

You can pass xen_nopv to the kernel command line

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:50:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnUZ-0000VW-Us; Mon, 10 Nov 2014 11:50:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnnUX-0000VP-ME
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:50:41 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	31/B1-26858-096A0645; Mon, 10 Nov 2014 11:50:40 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415620238!11556060!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20160 invoked from network); 10 Nov 2014 11:50:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:50:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191149834"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:50:13 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XnnU5-0003CV-7N;
	Mon, 10 Nov 2014 11:50:13 +0000
Date: Mon, 10 Nov 2014 11:50:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Wen Congyang <wency@cn.fujitsu.com>
In-Reply-To: <54604CEA.1060909@cn.fujitsu.com>
Message-ID: <alpine.DEB.2.02.1411101148300.22875@kaball.uk.xensource.com>
References: <54604CEA.1060909@cn.fujitsu.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Wen Congyang wrote:
> I disable xen-platform-pci in the config file, but when I start the guest, I found
> the following kernel message:
> [    0.000000] Booting paravirtualized kernel on Xen HVM
> [    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled

You can pass xen_nopv to the kernel command line

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 11:58:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnnbu-0000jB-5h; Mon, 10 Nov 2014 11:58: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@citrix.com>) id 1Xnnbt-0000j6-6V
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 11:58:17 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	80/96-14214-858A0645; Mon, 10 Nov 2014 11:58:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415620694!3933334!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26485 invoked from network); 10 Nov 2014 11:58:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:58:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191151166"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 06:58:13 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xnnbm-0005i0-Tj;
	Mon, 10 Nov 2014 11:58:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xnnbm-0003HB-MY;
	Mon, 10 Nov 2014 11:58:10 +0000
Date: Mon, 10 Nov 2014 11:58:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31399-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31399: 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 31399 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31399/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt       3 host-install(3)           broken pass in 31379
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10      fail pass in 31379
 test-armhf-armhf-xl           3 host-install(3)           broken pass in 31379

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail in 31379 like 28935-bisect
 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 leak-check/check fail in 31379 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-libvirt       9 guest-start           fail in 31379 never pass
 test-armhf-armhf-xl           5 xen-boot              fail in 31379 never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-libvirt host-install(3)
broken-step test-armhf-armhf-xl host-install(3)

Not pushing.

(No revision log; it would be 27231 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 Nov 10 11:58:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnnbu-0000jB-5h; Mon, 10 Nov 2014 11:58: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@citrix.com>) id 1Xnnbt-0000j6-6V
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 11:58:17 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	80/96-14214-858A0645; Mon, 10 Nov 2014 11:58:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415620694!3933334!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26485 invoked from network); 10 Nov 2014 11:58:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:58:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191151166"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 06:58:13 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xnnbm-0005i0-Tj;
	Mon, 10 Nov 2014 11:58:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xnnbm-0003HB-MY;
	Mon, 10 Nov 2014 11:58:10 +0000
Date: Mon, 10 Nov 2014 11:58:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31399-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31399: 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 31399 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31399/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt       3 host-install(3)           broken pass in 31379
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10      fail pass in 31379
 test-armhf-armhf-xl           3 host-install(3)           broken pass in 31379

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail in 31379 like 28935-bisect
 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 leak-check/check fail in 31379 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-libvirt       9 guest-start           fail in 31379 never pass
 test-armhf-armhf-xl           5 xen-boot              fail in 31379 never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-libvirt host-install(3)
broken-step test-armhf-armhf-xl host-install(3)

Not pushing.

(No revision log; it would be 27231 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 Nov 10 11:58:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnncN-0000kq-Ic; Mon, 10 Nov 2014 11:58:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XnncL-0000kh-Op
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:58:45 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	13/4D-17735-578A0645; Mon, 10 Nov 2014 11:58:45 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415620723!7807909!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21419 invoked from network); 10 Nov 2014 11:58:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:58:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; 
	d="asc'?scan'208";a="191151227"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:58:42 -0500
Message-ID: <1415620742.3717.39.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 12:59:02 +0100
In-Reply-To: <20141110112751.GB28360@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
	<20141110110936.GA28360@zion.uk.xensource.com>
	<54609FC4.3010101@citrix.com>
	<20141110112751.GB28360@zion.uk.xensource.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Elena Ufimtseva <ufimtseva@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
 to guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5974966226070142037=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5974966226070142037==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-2Th3vZBsvGKWRxOmGNX2"

--=-2Th3vZBsvGKWRxOmGNX2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-10 at 11:27 +0000, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 11:21:40AM +0000, David Vrabel wrote:
> > On 10/11/14 11:09, Wei Liu wrote:
> > >=20
> > > 3. Don't expose anything, everything happens automagically without gu=
est
> > >    knowing anything.
> >=20
> > This.  The vnode to pnode mapping can change on a save/restore.
>=20
> I don't think this is the most decisive reasoning of this issue. The
> other two options can also deal with this -- just retrieve the
> up-to-date versions after migration.
>=20
IMO, what's needed is an "on demand" "translation service". The guest
should not store the result of such translation and rely on it.

The opposite, actually: when ballooning up (i.e., the only legittimate
use case of this "service" I can think of right now), it should be
possible to let the hypervisor know from what physical NUMA node we want
a page, basing on which vnode such page belongs to.

This is probably another argument for not using option 1, and for going
for 3, if possible, or with something different, if not.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-2Th3vZBsvGKWRxOmGNX2
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 v2

iEYEABECAAYFAlRgqIYACgkQk4XaBE3IOsS4YwCdEtNXzrI7jgghSzrb8Z9v3JqW
DR8AoKNld9MfY1oz1yolOejaAJc59PwH
=iV2R
-----END PGP SIGNATURE-----

--=-2Th3vZBsvGKWRxOmGNX2--


--===============5974966226070142037==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5974966226070142037==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 11:58:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 11:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnncN-0000kq-Ic; Mon, 10 Nov 2014 11:58:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XnncL-0000kh-Op
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 11:58:45 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	13/4D-17735-578A0645; Mon, 10 Nov 2014 11:58:45 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415620723!7807909!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21419 invoked from network); 10 Nov 2014 11:58:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 11:58:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; 
	d="asc'?scan'208";a="191151227"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 06:58:42 -0500
Message-ID: <1415620742.3717.39.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 12:59:02 +0100
In-Reply-To: <20141110112751.GB28360@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
	<20141110110936.GA28360@zion.uk.xensource.com>
	<54609FC4.3010101@citrix.com>
	<20141110112751.GB28360@zion.uk.xensource.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Elena Ufimtseva <ufimtseva@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
 to guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5974966226070142037=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5974966226070142037==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-2Th3vZBsvGKWRxOmGNX2"

--=-2Th3vZBsvGKWRxOmGNX2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-10 at 11:27 +0000, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 11:21:40AM +0000, David Vrabel wrote:
> > On 10/11/14 11:09, Wei Liu wrote:
> > >=20
> > > 3. Don't expose anything, everything happens automagically without gu=
est
> > >    knowing anything.
> >=20
> > This.  The vnode to pnode mapping can change on a save/restore.
>=20
> I don't think this is the most decisive reasoning of this issue. The
> other two options can also deal with this -- just retrieve the
> up-to-date versions after migration.
>=20
IMO, what's needed is an "on demand" "translation service". The guest
should not store the result of such translation and rely on it.

The opposite, actually: when ballooning up (i.e., the only legittimate
use case of this "service" I can think of right now), it should be
possible to let the hypervisor know from what physical NUMA node we want
a page, basing on which vnode such page belongs to.

This is probably another argument for not using option 1, and for going
for 3, if possible, or with something different, if not.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-2Th3vZBsvGKWRxOmGNX2
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 v2

iEYEABECAAYFAlRgqIYACgkQk4XaBE3IOsS4YwCdEtNXzrI7jgghSzrb8Z9v3JqW
DR8AoKNld9MfY1oz1yolOejaAJc59PwH
=iV2R
-----END PGP SIGNATURE-----

--=-2Th3vZBsvGKWRxOmGNX2--


--===============5974966226070142037==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5974966226070142037==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 12:02:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:02:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnnfa-000177-9L; Mon, 10 Nov 2014 12:02:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnnfZ-00016y-1e
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:02:05 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	B9/30-11608-C39A0645; Mon, 10 Nov 2014 12:02:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415620922!11481600!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29003 invoked from network); 10 Nov 2014 12:02:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:02:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191152160"
Message-ID: <1415620919.28370.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Mon, 10 Nov 2014 12:01:59 +0000
In-Reply-To: <545BEFC5.3010803@tycho.nsa.gov>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>
	<545235EE.4040000@citrix.com>
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
	<1415096148.11486.11.camel@citrix.com> <545BEFC5.3010803@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Emil Condrea <emilcondrea@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 17:01 -0500, Daniel De Graaf wrote:
> On 11/04/2014 05:15 AM, Ian Campbell wrote:
> > On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
> >> Of course we can use max, but I thought that it might be useful to
> >> have a prink to inform the user that the timeout was adjusted.
> >> In init_tpm_tis the default timeouts are set using:
> >> /* Set default timeouts */ tpm->timeout_a =
> >> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
> >> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
> >> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
> >> MILLISECS(TIS_SHORT_TIMEOUT);
> >>
> >>
> >>
> >> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
> >> So if we want to integrate kernel changes I think we should use
> >> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
> >> Also in kernel the default timeouts are initialized using
> >> msecs_to_jiffies which is different from MILLISECS
> >> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
> >> Is there a certain reason for not using msecs_to_jiffies ?
> >
> > jiffies are a Linux specific concept which mini-os doesn't share.
> >
> > Daniel, do you have any opinion on this patch?
> >
> > It seems like the Linux fix is made only for the specifically broken
> > platform. That seems to make sense to me since presumably other systems
> > report short timeouts which they can indeed cope with. It's only Atmel
> > which brokenly reports something it cannot handle.
> >
> > Ian.
> 
> I agree that an adjustment is needed when values are too short.  Adjusting
> in all cases is not quite as nice as only fixing the broken TPMs, but it
> is a lot simpler.  It also doesn't seem harmful to have the timeouts be
> too large in the driver: a properly functioning TPM will not time out its
> requests in any case, so the user won't notice normally, and the default
> short timeout is 0.75 seconds - very few people will complain if they have
> to wait that long to get a timeout instead of what their TPM actually uses.

Can we take that as an ack?

Also needs the ok from Konrad as release manager. AIUI this is a bugfix
for a particular piece of h/w and as Daniel explains above the downside
is that sometimes someone might need to wait 0.75s for a timeout instead
of something shorter.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:02:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:02:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnnfa-000177-9L; Mon, 10 Nov 2014 12:02:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnnfZ-00016y-1e
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:02:05 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	B9/30-11608-C39A0645; Mon, 10 Nov 2014 12:02:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415620922!11481600!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29003 invoked from network); 10 Nov 2014 12:02:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:02:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191152160"
Message-ID: <1415620919.28370.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Mon, 10 Nov 2014 12:01:59 +0000
In-Reply-To: <545BEFC5.3010803@tycho.nsa.gov>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>
	<545235EE.4040000@citrix.com>
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
	<1415096148.11486.11.camel@citrix.com> <545BEFC5.3010803@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Emil Condrea <emilcondrea@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 17:01 -0500, Daniel De Graaf wrote:
> On 11/04/2014 05:15 AM, Ian Campbell wrote:
> > On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
> >> Of course we can use max, but I thought that it might be useful to
> >> have a prink to inform the user that the timeout was adjusted.
> >> In init_tpm_tis the default timeouts are set using:
> >> /* Set default timeouts */ tpm->timeout_a =
> >> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
> >> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
> >> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
> >> MILLISECS(TIS_SHORT_TIMEOUT);
> >>
> >>
> >>
> >> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
> >> So if we want to integrate kernel changes I think we should use
> >> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
> >> Also in kernel the default timeouts are initialized using
> >> msecs_to_jiffies which is different from MILLISECS
> >> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
> >> Is there a certain reason for not using msecs_to_jiffies ?
> >
> > jiffies are a Linux specific concept which mini-os doesn't share.
> >
> > Daniel, do you have any opinion on this patch?
> >
> > It seems like the Linux fix is made only for the specifically broken
> > platform. That seems to make sense to me since presumably other systems
> > report short timeouts which they can indeed cope with. It's only Atmel
> > which brokenly reports something it cannot handle.
> >
> > Ian.
> 
> I agree that an adjustment is needed when values are too short.  Adjusting
> in all cases is not quite as nice as only fixing the broken TPMs, but it
> is a lot simpler.  It also doesn't seem harmful to have the timeouts be
> too large in the driver: a properly functioning TPM will not time out its
> requests in any case, so the user won't notice normally, and the default
> short timeout is 0.75 seconds - very few people will complain if they have
> to wait that long to get a timeout instead of what their TPM actually uses.

Can we take that as an ack?

Also needs the ok from Konrad as release manager. AIUI this is a bugfix
for a particular piece of h/w and as Daniel explains above the downside
is that sometimes someone might need to wait 0.75s for a timeout instead
of something shorter.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:08:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnlI-0001NK-5M; Mon, 10 Nov 2014 12: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.liu2@citrix.com>) id 1XnnlG-0001NF-Oj
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:07:58 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	DF/B6-01660-E9AA0645; Mon, 10 Nov 2014 12:07:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415621274!11507703!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22897 invoked from network); 10 Nov 2014 12:07:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:07:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191153686"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:07:53 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnnlB-0003bx-A1;
	Mon, 10 Nov 2014 12:07:53 +0000
Date: Mon, 10 Nov 2014 12:07:53 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141110120753.GC28360@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
	<20141110110936.GA28360@zion.uk.xensource.com>
	<1415619727.3717.28.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415619727.3717.28.camel@Abyss>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
 to 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 Mon, Nov 10, 2014 at 12:42:07PM +0100, Dario Faggioli wrote:
> On Mon, 2014-11-10 at 11:09 +0000, Wei Liu wrote:
> > On Mon, Nov 10, 2014 at 11:51:28AM +0100, Dario Faggioli wrote:
> >
> > > I'm 100% ok to re-start that discussion here and now... however, how
> > > stable should this interface be? Can't we deal with this when actually
> > > implementing NUMA aware ballooning and add stuff at than point, if
> > > necessary?
> > > 
> > The risk would be any new guests with extended get_vnumainfo interface
> > won't be able to run on old hypervisor (4.5) without proper versioning.
> > 
> Right.
> 
> > So basically we have three choices:
> > 1. Expose vnode_to_pnode in hypercall interface.
> > 2. Expose the mapping in xenstore.
> > 3. Don't expose anything, everything happens automagically without guest
> >    knowing anything.
> > 
> > I'm fine with any of those three. However, Jan suggested in that one
> > year old thread it would be wrong for the guest to know the mapping, so
> > I think he implicitly voted for the third option.
> > 
> Option 3 is the best IMO too. The guest, ideally, should know nothing
> about how Xen mapped its virtual NUMA nodes onto the host RAM.
> 

Agreed. I would go for this approach personally.

> The question here is how effective that is. As of now, it's quite hard
> to judge whether we'll be able to do everything automatically, I think.
> I read your proposal, and it looks sensible, I'm just saying it's hard
> to be conclusive at this stage.
> 

I just checked the code. Unfortunately increase_reservation cannot cope
with my proposal.

Currently, the increase_reservation hypercall only allocates pages with
no prior knowledge of what part of guest physical address space those
pages will be added to.

So for NUMA-aware ballooning, we might need a increase_reservation2
hypercall that does the trick I mentioned.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:08:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnlI-0001NK-5M; Mon, 10 Nov 2014 12: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.liu2@citrix.com>) id 1XnnlG-0001NF-Oj
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:07:58 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	DF/B6-01660-E9AA0645; Mon, 10 Nov 2014 12:07:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415621274!11507703!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22897 invoked from network); 10 Nov 2014 12:07:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:07:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191153686"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:07:53 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnnlB-0003bx-A1;
	Mon, 10 Nov 2014 12:07:53 +0000
Date: Mon, 10 Nov 2014 12:07:53 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141110120753.GC28360@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<546091A40200007800045E86@mail.emea.novell.com>
	<20141110100016.GA17065@zion.uk.xensource.com>
	<1415616688.3717.16.camel@Abyss>
	<20141110110936.GA28360@zion.uk.xensource.com>
	<1415619727.3717.28.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415619727.3717.28.camel@Abyss>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
 to 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 Mon, Nov 10, 2014 at 12:42:07PM +0100, Dario Faggioli wrote:
> On Mon, 2014-11-10 at 11:09 +0000, Wei Liu wrote:
> > On Mon, Nov 10, 2014 at 11:51:28AM +0100, Dario Faggioli wrote:
> >
> > > I'm 100% ok to re-start that discussion here and now... however, how
> > > stable should this interface be? Can't we deal with this when actually
> > > implementing NUMA aware ballooning and add stuff at than point, if
> > > necessary?
> > > 
> > The risk would be any new guests with extended get_vnumainfo interface
> > won't be able to run on old hypervisor (4.5) without proper versioning.
> > 
> Right.
> 
> > So basically we have three choices:
> > 1. Expose vnode_to_pnode in hypercall interface.
> > 2. Expose the mapping in xenstore.
> > 3. Don't expose anything, everything happens automagically without guest
> >    knowing anything.
> > 
> > I'm fine with any of those three. However, Jan suggested in that one
> > year old thread it would be wrong for the guest to know the mapping, so
> > I think he implicitly voted for the third option.
> > 
> Option 3 is the best IMO too. The guest, ideally, should know nothing
> about how Xen mapped its virtual NUMA nodes onto the host RAM.
> 

Agreed. I would go for this approach personally.

> The question here is how effective that is. As of now, it's quite hard
> to judge whether we'll be able to do everything automatically, I think.
> I read your proposal, and it looks sensible, I'm just saying it's hard
> to be conclusive at this stage.
> 

I just checked the code. Unfortunately increase_reservation cannot cope
with my proposal.

Currently, the increase_reservation hypercall only allocates pages with
no prior knowledge of what part of guest physical address space those
pages will be added to.

So for NUMA-aware ballooning, we might need a increase_reservation2
hypercall that does the trick I mentioned.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:08:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnnm0-0001RJ-JY; Mon, 10 Nov 2014 12:08:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xnnlz-0001R5-9f
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:08:43 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	CE/0F-02696-ACAA0645; Mon, 10 Nov 2014 12:08:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415621318!12487395!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21618 invoked from network); 10 Nov 2014 12:08:41 -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 Nov 2014 12:08:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191153866"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:08:34 -0500
Received: from cosworth.uk.xensource.com	([10.80.16.52]
	helo=localhost.localdomain ident=ianc)	by ukmail1.uk.xensource.com with
	smtp (Exim 4.69)	(envelope-from <ian.campbell@citrix.com>)	id
	1Xnnlp-0003cm-Fk; Mon, 10 Nov 2014 12:08:34 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Mon, 10 Nov
	2014 12:08:33 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>, <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 12:08:33 +0000
Message-ID: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH for-4.5] libxc: don't leak buffer containing the
	uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
is freed by xc_dom_release. However the various xc_try_*_decode routines (other
than the gzip one) just use plain malloc/realloc and therefore the buffer ends
up leaked.

The memory pool currently supports mmap'd buffers as well as a directly
allocated buffers, however the try decode routines make use of realloc and do
not fit well into this model. Introduce a concept of an external memory block
to the memory pool and provide an interface to register such memory.

The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
mmap_ prefix since they are now also used for external memory blocks.

We are only seeing this now because the gzip decoder doesn't leak and it's only
relatively recently that kernels in the wild have switched to better
compression.

This is https://bugs.debian.org/767295

Reported by: Gedalya <gedalya@gedalya.net>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
This is a bug fix and should go into 4.5.

I have a sneaking suspicion this is going to need to backport a very long way...
---
 tools/libxc/include/xc_dom.h        |   10 ++++--
 tools/libxc/xc_dom_bzimageloader.c  |   18 +++++++++++
 tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
 tools/libxc/xc_dom_decompress_lz4.c |    5 +++
 4 files changed, 78 insertions(+), 16 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6ae6a9f..07d7224 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -33,8 +33,13 @@ struct xc_dom_seg {
 
 struct xc_dom_mem {
     struct xc_dom_mem *next;
-    void *mmap_ptr;
-    size_t mmap_len;
+    void *ptr;
+    enum {
+        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
+        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
+        XC_DOM_MEM_TYPE_MMAP,
+    } type;
+    size_t len;
     unsigned char memory[0];
 };
 
@@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
 /* --- simple memory pool ------------------------------------------ */
 
 void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
 void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
                             const char *filename, size_t * size,
diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
index 2225699..991a07b 100644
--- a/tools/libxc/xc_dom_bzimageloader.c
+++ b/tools/libxc/xc_dom_bzimageloader.c
@@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
 
     total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
 
+    if ( xc_dom_register_external(dom, out_buf, total) )
+    {
+        DOMPRINTF("BZIP2: Error registering stream output");
+        free(out_buf);
+        goto bzip2_cleanup;
+    }
+
     DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
               __FUNCTION__, *size, (long unsigned int) total);
 
@@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
         }
     }
 
+    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
+    {
+        DOMPRINTF("%s: Error registering stream output", what);
+        free(out_buf);
+        goto lzma_cleanup;
+    }
+
     DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
               __FUNCTION__, what, *size, (size_t)stream->total_out);
 
@@ -508,6 +522,10 @@ static int xc_try_lzo1x_decode(
             if ( out_len != dst_len )
                 break;
 
+            msg = "Error registering stream output";
+            if ( xc_dom_register_external(dom, out_buf, out_len) )
+                break;
+
             *blob = out_buf;
             *size += out_len;
             cur += src_len;
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index baa62a1..ecbf981 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
         return NULL;
     }
     memset(block, 0, sizeof(*block) + size);
+    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block) + size;
@@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
         return NULL;
     }
     memset(block, 0, sizeof(*block));
-    block->mmap_len = size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len,
-                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
-                           -1, 0);
-    if ( block->mmap_ptr == MAP_FAILED )
+    block->len = size;
+    block->ptr = mmap(NULL, block->len,
+                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
+                      -1, 0);
+    if ( block->ptr == MAP_FAILED )
     {
         DOMPRINTF("%s: mmap failed", __FUNCTION__);
         free(block);
         return NULL;
     }
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_mem_map += block->mmap_len;
+    dom->alloc_mem_map += block->len;
     if ( size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, size);
-    return block->mmap_ptr;
+    return block->ptr;
+}
+
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
+{
+    struct xc_dom_mem *block;
+
+    block = malloc(sizeof(*block));
+    if ( block == NULL )
+    {
+        DOMPRINTF("%s: allocation failed", __FUNCTION__);
+        return -1;
+    }
+    memset(block, 0, sizeof(*block));
+    block->ptr = ptr;
+    block->len = size;
+    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
+    block->next = dom->memblocks;
+    dom->memblocks = block;
+    dom->alloc_malloc += sizeof(*block);
+    dom->alloc_mem_map += block->len;
+    return 0;
 }
 
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
@@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
     }
 
     memset(block, 0, sizeof(*block));
-    block->mmap_len = *size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
+    block->len = *size;
+    block->ptr = mmap(NULL, block->len, PROT_READ,
                            MAP_SHARED, fd, 0);
-    if ( block->mmap_ptr == MAP_FAILED ) {
+    if ( block->ptr == MAP_FAILED ) {
         xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
                      "failed to mmap file: %s",
                      strerror(errno));
         goto err;
     }
 
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_file_map += block->mmap_len;
+    dom->alloc_file_map += block->len;
     close(fd);
     if ( *size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, *size);
-    return block->mmap_ptr;
+    return block->ptr;
 
  err:
     if ( fd != -1 )
@@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
     while ( (block = dom->memblocks) != NULL )
     {
         dom->memblocks = block->next;
-        if ( block->mmap_ptr )
-            munmap(block->mmap_ptr, block->mmap_len);
+        switch ( block->type )
+        {
+        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
+            break;
+        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
+            free(block->ptr);
+            break;
+        case XC_DOM_MEM_TYPE_MMAP:
+            munmap(block->ptr, block->len);
+            break;
+        }
         free(block);
     }
 }
diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
index 490ec56..b6a33f2 100644
--- a/tools/libxc/xc_dom_decompress_lz4.c
+++ b/tools/libxc/xc_dom_decompress_lz4.c
@@ -103,6 +103,11 @@ int xc_try_lz4_decode(
 
 		if (size == 0)
 		{
+			if ( xc_dom_register_external(dom, output, out_len) )
+			{
+				msg = "Error registering stream output";
+				goto exit_2;
+			}
 			*blob = output;
 			*psize = out_len;
 			return 0;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:08:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnnm0-0001RJ-JY; Mon, 10 Nov 2014 12:08:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xnnlz-0001R5-9f
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:08:43 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	CE/0F-02696-ACAA0645; Mon, 10 Nov 2014 12:08:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415621318!12487395!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21618 invoked from network); 10 Nov 2014 12:08:41 -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 Nov 2014 12:08:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191153866"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:08:34 -0500
Received: from cosworth.uk.xensource.com	([10.80.16.52]
	helo=localhost.localdomain ident=ianc)	by ukmail1.uk.xensource.com with
	smtp (Exim 4.69)	(envelope-from <ian.campbell@citrix.com>)	id
	1Xnnlp-0003cm-Fk; Mon, 10 Nov 2014 12:08:34 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Mon, 10 Nov
	2014 12:08:33 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>, <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 12:08:33 +0000
Message-ID: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH for-4.5] libxc: don't leak buffer containing the
	uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
is freed by xc_dom_release. However the various xc_try_*_decode routines (other
than the gzip one) just use plain malloc/realloc and therefore the buffer ends
up leaked.

The memory pool currently supports mmap'd buffers as well as a directly
allocated buffers, however the try decode routines make use of realloc and do
not fit well into this model. Introduce a concept of an external memory block
to the memory pool and provide an interface to register such memory.

The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
mmap_ prefix since they are now also used for external memory blocks.

We are only seeing this now because the gzip decoder doesn't leak and it's only
relatively recently that kernels in the wild have switched to better
compression.

This is https://bugs.debian.org/767295

Reported by: Gedalya <gedalya@gedalya.net>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
This is a bug fix and should go into 4.5.

I have a sneaking suspicion this is going to need to backport a very long way...
---
 tools/libxc/include/xc_dom.h        |   10 ++++--
 tools/libxc/xc_dom_bzimageloader.c  |   18 +++++++++++
 tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
 tools/libxc/xc_dom_decompress_lz4.c |    5 +++
 4 files changed, 78 insertions(+), 16 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6ae6a9f..07d7224 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -33,8 +33,13 @@ struct xc_dom_seg {
 
 struct xc_dom_mem {
     struct xc_dom_mem *next;
-    void *mmap_ptr;
-    size_t mmap_len;
+    void *ptr;
+    enum {
+        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
+        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
+        XC_DOM_MEM_TYPE_MMAP,
+    } type;
+    size_t len;
     unsigned char memory[0];
 };
 
@@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
 /* --- simple memory pool ------------------------------------------ */
 
 void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
 void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
                             const char *filename, size_t * size,
diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
index 2225699..991a07b 100644
--- a/tools/libxc/xc_dom_bzimageloader.c
+++ b/tools/libxc/xc_dom_bzimageloader.c
@@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
 
     total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
 
+    if ( xc_dom_register_external(dom, out_buf, total) )
+    {
+        DOMPRINTF("BZIP2: Error registering stream output");
+        free(out_buf);
+        goto bzip2_cleanup;
+    }
+
     DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
               __FUNCTION__, *size, (long unsigned int) total);
 
@@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
         }
     }
 
+    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
+    {
+        DOMPRINTF("%s: Error registering stream output", what);
+        free(out_buf);
+        goto lzma_cleanup;
+    }
+
     DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
               __FUNCTION__, what, *size, (size_t)stream->total_out);
 
@@ -508,6 +522,10 @@ static int xc_try_lzo1x_decode(
             if ( out_len != dst_len )
                 break;
 
+            msg = "Error registering stream output";
+            if ( xc_dom_register_external(dom, out_buf, out_len) )
+                break;
+
             *blob = out_buf;
             *size += out_len;
             cur += src_len;
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index baa62a1..ecbf981 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
         return NULL;
     }
     memset(block, 0, sizeof(*block) + size);
+    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block) + size;
@@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
         return NULL;
     }
     memset(block, 0, sizeof(*block));
-    block->mmap_len = size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len,
-                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
-                           -1, 0);
-    if ( block->mmap_ptr == MAP_FAILED )
+    block->len = size;
+    block->ptr = mmap(NULL, block->len,
+                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
+                      -1, 0);
+    if ( block->ptr == MAP_FAILED )
     {
         DOMPRINTF("%s: mmap failed", __FUNCTION__);
         free(block);
         return NULL;
     }
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_mem_map += block->mmap_len;
+    dom->alloc_mem_map += block->len;
     if ( size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, size);
-    return block->mmap_ptr;
+    return block->ptr;
+}
+
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
+{
+    struct xc_dom_mem *block;
+
+    block = malloc(sizeof(*block));
+    if ( block == NULL )
+    {
+        DOMPRINTF("%s: allocation failed", __FUNCTION__);
+        return -1;
+    }
+    memset(block, 0, sizeof(*block));
+    block->ptr = ptr;
+    block->len = size;
+    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
+    block->next = dom->memblocks;
+    dom->memblocks = block;
+    dom->alloc_malloc += sizeof(*block);
+    dom->alloc_mem_map += block->len;
+    return 0;
 }
 
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
@@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
     }
 
     memset(block, 0, sizeof(*block));
-    block->mmap_len = *size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
+    block->len = *size;
+    block->ptr = mmap(NULL, block->len, PROT_READ,
                            MAP_SHARED, fd, 0);
-    if ( block->mmap_ptr == MAP_FAILED ) {
+    if ( block->ptr == MAP_FAILED ) {
         xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
                      "failed to mmap file: %s",
                      strerror(errno));
         goto err;
     }
 
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_file_map += block->mmap_len;
+    dom->alloc_file_map += block->len;
     close(fd);
     if ( *size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, *size);
-    return block->mmap_ptr;
+    return block->ptr;
 
  err:
     if ( fd != -1 )
@@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
     while ( (block = dom->memblocks) != NULL )
     {
         dom->memblocks = block->next;
-        if ( block->mmap_ptr )
-            munmap(block->mmap_ptr, block->mmap_len);
+        switch ( block->type )
+        {
+        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
+            break;
+        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
+            free(block->ptr);
+            break;
+        case XC_DOM_MEM_TYPE_MMAP:
+            munmap(block->ptr, block->len);
+            break;
+        }
         free(block);
     }
 }
diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
index 490ec56..b6a33f2 100644
--- a/tools/libxc/xc_dom_decompress_lz4.c
+++ b/tools/libxc/xc_dom_decompress_lz4.c
@@ -103,6 +103,11 @@ int xc_try_lz4_decode(
 
 		if (size == 0)
 		{
+			if ( xc_dom_register_external(dom, output, out_len) )
+			{
+				msg = "Error registering stream output";
+				goto exit_2;
+			}
 			*blob = output;
 			*psize = out_len;
 			return 0;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:09:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnnmr-0001W8-1W; Mon, 10 Nov 2014 12:09:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xnnmq-0001Vz-JC
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:09:36 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	D6/3A-27785-FFAA0645; Mon, 10 Nov 2014 12:09:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415621373!12446873!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3902 invoked from network); 10 Nov 2014 12:09:34 -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;
	10 Nov 2014 12:09:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191154052"
Message-ID: <1415621371.28370.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Mon, 10 Nov 2014 12:09:31 +0000
In-Reply-To: <5460A51E.9050401@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
	<1415180713.11486.61.camel@citrix.com> <545A118B.7040309@web2web.at>
	<1415191140.15317.11.camel@citrix.com> <545B8FAE.9090608@web2web.at>
	<1415618193.28370.4.camel@citrix.com> <5460A51E.9050401@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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, 2014-11-10 at 12:44 +0100, Atom2 wrote:

> > I'm afraid it's looking more and more like a toolchain issue. I'm not
> > expert on this side on things but it looks to me like you are hitting an
> > issue with some sort of buffer overflow check gone wrong? I think you'll
> > need a gcc hardening person for this one.
> The issue currently is with the guys at gentoo (for links please again 
> see my latest post to the list from Sunday which also seems to confirm 
> that the issue is not confined to 4.3.3 but also 4.4.1).

OK, I'll wait and see what the gentoo folks have to say before looking
any close then, 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 Nov 10 12:09:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnnmr-0001W8-1W; Mon, 10 Nov 2014 12:09:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xnnmq-0001Vz-JC
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:09:36 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	D6/3A-27785-FFAA0645; Mon, 10 Nov 2014 12:09:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415621373!12446873!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3902 invoked from network); 10 Nov 2014 12:09:34 -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;
	10 Nov 2014 12:09:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191154052"
Message-ID: <1415621371.28370.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Atom2 <ariel.atom2@web2web.at>
Date: Mon, 10 Nov 2014 12:09:31 +0000
In-Reply-To: <5460A51E.9050401@web2web.at>
References: <544EB843.9060503@web2web.at>
	<1414493998.10206.3.camel@citrix.com>	<544FB8C4.9000102@web2web.at>
	<1414512266.10974.5.camel@citrix.com>	<54503440.3050302@web2web.at>
	<5452C43C.6050800@web2web.at> <5458ED27.8060502@web2web.at>
	<1415115868.11486.49.camel@citrix.com> <5458FB49.4040801@web2web.at>
	<1415118690.11486.53.camel@citrix.com> <54590D4D.90300@web2web.at>
	<1415180713.11486.61.camel@citrix.com> <545A118B.7040309@web2web.at>
	<1415191140.15317.11.camel@citrix.com> <545B8FAE.9090608@web2web.at>
	<1415618193.28370.4.camel@citrix.com> <5460A51E.9050401@web2web.at>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG] XEN 4.3.3 - segfault in xl create for HVM
 with 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, 2014-11-10 at 12:44 +0100, Atom2 wrote:

> > I'm afraid it's looking more and more like a toolchain issue. I'm not
> > expert on this side on things but it looks to me like you are hitting an
> > issue with some sort of buffer overflow check gone wrong? I think you'll
> > need a gcc hardening person for this one.
> The issue currently is with the guys at gentoo (for links please again 
> see my latest post to the list from Sunday which also seems to confirm 
> that the issue is not confined to 4.3.3 but also 4.4.1).

OK, I'll wait and see what the gentoo folks have to say before looking
any close then, 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 Nov 10 12:20:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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.xen.org>)
	id 1XnnxU-0001rZ-CB; Mon, 10 Nov 2014 12:20: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 1XnnxS-0001rT-T2
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:20:35 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A9/5F-26652-19DA0645; Mon, 10 Nov 2014 12:20:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415622031!7400460!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25427 invoked from network); 10 Nov 2014 12:20:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:20:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189717281"
Message-ID: <1415622029.28370.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Mon, 10 Nov 2014 12:20:29 +0000
In-Reply-To: <20141106113923.GA3182@type.bordeaux.inria.fr>
References: <1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
	<20141106113923.GA3182@type.bordeaux.inria.fr>
Organization: Citrix Systems, Inc.
Content-Length: 1545
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xen.org,
	netwiz@crc.id.au, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDE0LTExLTA2IGF0IDEyOjM5ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gU3RlZmFubyBTdGFiZWxsaW5pLCBsZSBUaHUgMDYgTm92IDIwMTQgMTA6NDE6MjggKzAwMDAs
IGEgw6ljcml0IDoKPiA+IFdoZW4gdXNpbmcgcHZncnViIGluIGdyYXBoaWNhbCBtb2RlIHdpdGgg
dm5jLCB0aGUgZ3J1YiB0aW1lb3V0IGRvZXNuJ3QKPiA+IHdvcms6IHRoZSBjb3VudGRvd24gZG9l
c24ndCBldmVuIHN0YXJ0LiBXaXRoIGEgc2VyaWFsIHRlcm1pbmFsIHRoZQo+ID4gcHJvYmxlbSBk
b2Vzbid0IG9jY3VyIGFuZCB0aGUgY291bnRkb3duIHdvcmtzIGFzIGV4cGVjdGVkLgo+ID4gCj4g
PiBJdCB0dXJucyBvdXQgdGhhdCB0aGUgcHJvYmxlbSBpcyB0aGF0IHdoZW4gdXNpbmcgYSBncmFw
aGljYWwgdGVybWluYWwsCj4gPiBjaGVja2tleSAoKSByZXR1cm5zIDAgaW5zdGVhZCBvZiAtMSB3
aGVuIHRoZXJlIGlzIG5vIGFjdGl2aXR5IG9uIHRoZQo+ID4gbW91c2Ugb3Iga2V5Ym9hcmQuIEFz
IGEgY29uc2VxdWVuY2UgZ3J1YiB0aGlua3MgdGhhdCB0aGUgdXNlciB0eXBlZAo+ID4gc29tZXRo
aW5nIGFuZCBpbnRlcnJ1cHRzIHRoZSBjb3VudCBkb3duLgo+ID4gCj4gPiBUbyBmaXggdGhlIGlz
c3VlIHNpbXBseSBpZ25vcmUga2V5c3Ryb2tlcyByZXR1cm5pbmcgMCwgdGhhdCBpcyB0aGUgTlVM
Cj4gPiBjaGFyYWN0ZXIgYW55d2F5LiBBZGQgYSBwYXRjaCB0byBncnViLnBhdGNoZXMgdG8gZG8g
dGhhdC4KPiA+IAo+ID4gU2lnbmVkLW9mZi1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5v
LnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT4KPiA+IFRlc3RlZC1ieTogU3RldmVuIEhhaWdoIDxu
ZXR3aXpAY3JjLmlkLmF1Pgo+IAo+IEFja2VkLWJ5OiBTYW11ZWwgVGhpYmF1bHQgPHNhbXVlbC50
aGliYXVsdEBlbnMtbHlvbi5vcmc+CgpJIHRoaW5rIHRoZSBjb25jbHVzaW9uIG9mIHRoZSBzdWJ0
aHJlYWQgd2FzIGEgcmVsZWFzZSBhY2sgc28gYXBwbGllZCwKdGhhbmtzLgoKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:20:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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.xen.org>)
	id 1XnnxU-0001rZ-CB; Mon, 10 Nov 2014 12:20: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 1XnnxS-0001rT-T2
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:20:35 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A9/5F-26652-19DA0645; Mon, 10 Nov 2014 12:20:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415622031!7400460!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25427 invoked from network); 10 Nov 2014 12:20:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:20:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189717281"
Message-ID: <1415622029.28370.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Mon, 10 Nov 2014 12:20:29 +0000
In-Reply-To: <20141106113923.GA3182@type.bordeaux.inria.fr>
References: <1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
	<20141106113923.GA3182@type.bordeaux.inria.fr>
Organization: Citrix Systems, Inc.
Content-Length: 1545
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xen.org,
	netwiz@crc.id.au, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDE0LTExLTA2IGF0IDEyOjM5ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gU3RlZmFubyBTdGFiZWxsaW5pLCBsZSBUaHUgMDYgTm92IDIwMTQgMTA6NDE6MjggKzAwMDAs
IGEgw6ljcml0IDoKPiA+IFdoZW4gdXNpbmcgcHZncnViIGluIGdyYXBoaWNhbCBtb2RlIHdpdGgg
dm5jLCB0aGUgZ3J1YiB0aW1lb3V0IGRvZXNuJ3QKPiA+IHdvcms6IHRoZSBjb3VudGRvd24gZG9l
c24ndCBldmVuIHN0YXJ0LiBXaXRoIGEgc2VyaWFsIHRlcm1pbmFsIHRoZQo+ID4gcHJvYmxlbSBk
b2Vzbid0IG9jY3VyIGFuZCB0aGUgY291bnRkb3duIHdvcmtzIGFzIGV4cGVjdGVkLgo+ID4gCj4g
PiBJdCB0dXJucyBvdXQgdGhhdCB0aGUgcHJvYmxlbSBpcyB0aGF0IHdoZW4gdXNpbmcgYSBncmFw
aGljYWwgdGVybWluYWwsCj4gPiBjaGVja2tleSAoKSByZXR1cm5zIDAgaW5zdGVhZCBvZiAtMSB3
aGVuIHRoZXJlIGlzIG5vIGFjdGl2aXR5IG9uIHRoZQo+ID4gbW91c2Ugb3Iga2V5Ym9hcmQuIEFz
IGEgY29uc2VxdWVuY2UgZ3J1YiB0aGlua3MgdGhhdCB0aGUgdXNlciB0eXBlZAo+ID4gc29tZXRo
aW5nIGFuZCBpbnRlcnJ1cHRzIHRoZSBjb3VudCBkb3duLgo+ID4gCj4gPiBUbyBmaXggdGhlIGlz
c3VlIHNpbXBseSBpZ25vcmUga2V5c3Ryb2tlcyByZXR1cm5pbmcgMCwgdGhhdCBpcyB0aGUgTlVM
Cj4gPiBjaGFyYWN0ZXIgYW55d2F5LiBBZGQgYSBwYXRjaCB0byBncnViLnBhdGNoZXMgdG8gZG8g
dGhhdC4KPiA+IAo+ID4gU2lnbmVkLW9mZi1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5v
LnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT4KPiA+IFRlc3RlZC1ieTogU3RldmVuIEhhaWdoIDxu
ZXR3aXpAY3JjLmlkLmF1Pgo+IAo+IEFja2VkLWJ5OiBTYW11ZWwgVGhpYmF1bHQgPHNhbXVlbC50
aGliYXVsdEBlbnMtbHlvbi5vcmc+CgpJIHRoaW5rIHRoZSBjb25jbHVzaW9uIG9mIHRoZSBzdWJ0
aHJlYWQgd2FzIGEgcmVsZWFzZSBhY2sgc28gYXBwbGllZCwKdGhhbmtzLgoKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:20:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnnxj-0001ss-PI; Mon, 10 Nov 2014 12:20:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xnnxh-0001sN-OJ
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:20:49 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	8E/A2-22737-1ADA0645; Mon, 10 Nov 2014 12:20:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415622047!6107545!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1749 invoked from network); 10 Nov 2014 12:20:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:20:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189717330"
Message-ID: <1415622044.25176.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 10 Nov 2014 12:20:44 +0000
In-Reply-To: <20141107145044.GD13259@laptop.dumpdata.com>
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
	<545CC988.5000000@linaro.org>
	<20141107145044.GD13259@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-07 at 09:50 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 07, 2014 at 01:30:48PM +0000, Julien Grall wrote:
> > Hi all,
> > 
> > On 05/11/2014 13:04, Julien Grall wrote:
> > >The vGIC will emulate the same version as the hardware. The toolstack has
> > >to retrieve the version of the vGIC in order to be able to create the
> > >corresponding device tree node.
> > >
> > >A new DOMCTL has been introduced for ARM to configure the domain. For now
> > >it only allow the toolstack to retrieve the version of vGIC.
> > >This DOMCTL will be extend later to let the user choose the version of the
> > >emulated GIC.
> > >
> > >Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> > >Signed-off-by: Julien Grall <julien.grall@linaro.org>
> > >Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > >Cc: Jan Beulich <jbeulich@suse.com>
> > >Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > 
> > I forgot to keep the Ack from Daniel on v2:
> > 
> > http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00230.html
> 
> Right. If he is Ok then Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks, acked by me too and applied.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:20:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnnxj-0001ss-PI; Mon, 10 Nov 2014 12:20:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xnnxh-0001sN-OJ
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:20:49 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	8E/A2-22737-1ADA0645; Mon, 10 Nov 2014 12:20:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415622047!6107545!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1749 invoked from network); 10 Nov 2014 12:20:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:20:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189717330"
Message-ID: <1415622044.25176.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 10 Nov 2014 12:20:44 +0000
In-Reply-To: <20141107145044.GD13259@laptop.dumpdata.com>
References: <1415192662-3353-1-git-send-email-julien.grall@linaro.org>
	<545CC988.5000000@linaro.org>
	<20141107145044.GD13259@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v3 for 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-07 at 09:50 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 07, 2014 at 01:30:48PM +0000, Julien Grall wrote:
> > Hi all,
> > 
> > On 05/11/2014 13:04, Julien Grall wrote:
> > >The vGIC will emulate the same version as the hardware. The toolstack has
> > >to retrieve the version of the vGIC in order to be able to create the
> > >corresponding device tree node.
> > >
> > >A new DOMCTL has been introduced for ARM to configure the domain. For now
> > >it only allow the toolstack to retrieve the version of vGIC.
> > >This DOMCTL will be extend later to let the user choose the version of the
> > >emulated GIC.
> > >
> > >Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> > >Signed-off-by: Julien Grall <julien.grall@linaro.org>
> > >Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > >Cc: Jan Beulich <jbeulich@suse.com>
> > >Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > 
> > I forgot to keep the Ack from Daniel on v2:
> > 
> > http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00230.html
> 
> Right. If he is Ok then Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks, acked by me too and applied.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:21:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnyF-0001z2-Cl; Mon, 10 Nov 2014 12:21:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnnyE-0001yk-Du
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:21:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3E/DE-09842-1CDA0645; Mon, 10 Nov 2014 12:21:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415622080!12731797!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6687 invoked from network); 10 Nov 2014 12:21:21 -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;
	10 Nov 2014 12:21:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191156514"
Message-ID: <1415622077.25176.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Mon, 10 Nov 2014 12:21:17 +0000
In-Reply-To: <20141106113923.GA3182@type.bordeaux.inria.fr>
References: <1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
	<20141106113923.GA3182@type.bordeaux.inria.fr>
Organization: Citrix Systems, Inc.
Content-Length: 1545
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xen.org,
	netwiz@crc.id.au, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDE0LTExLTA2IGF0IDEyOjM5ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gU3RlZmFubyBTdGFiZWxsaW5pLCBsZSBUaHUgMDYgTm92IDIwMTQgMTA6NDE6MjggKzAwMDAs
IGEgw6ljcml0IDoKPiA+IFdoZW4gdXNpbmcgcHZncnViIGluIGdyYXBoaWNhbCBtb2RlIHdpdGgg
dm5jLCB0aGUgZ3J1YiB0aW1lb3V0IGRvZXNuJ3QKPiA+IHdvcms6IHRoZSBjb3VudGRvd24gZG9l
c24ndCBldmVuIHN0YXJ0LiBXaXRoIGEgc2VyaWFsIHRlcm1pbmFsIHRoZQo+ID4gcHJvYmxlbSBk
b2Vzbid0IG9jY3VyIGFuZCB0aGUgY291bnRkb3duIHdvcmtzIGFzIGV4cGVjdGVkLgo+ID4gCj4g
PiBJdCB0dXJucyBvdXQgdGhhdCB0aGUgcHJvYmxlbSBpcyB0aGF0IHdoZW4gdXNpbmcgYSBncmFw
aGljYWwgdGVybWluYWwsCj4gPiBjaGVja2tleSAoKSByZXR1cm5zIDAgaW5zdGVhZCBvZiAtMSB3
aGVuIHRoZXJlIGlzIG5vIGFjdGl2aXR5IG9uIHRoZQo+ID4gbW91c2Ugb3Iga2V5Ym9hcmQuIEFz
IGEgY29uc2VxdWVuY2UgZ3J1YiB0aGlua3MgdGhhdCB0aGUgdXNlciB0eXBlZAo+ID4gc29tZXRo
aW5nIGFuZCBpbnRlcnJ1cHRzIHRoZSBjb3VudCBkb3duLgo+ID4gCj4gPiBUbyBmaXggdGhlIGlz
c3VlIHNpbXBseSBpZ25vcmUga2V5c3Ryb2tlcyByZXR1cm5pbmcgMCwgdGhhdCBpcyB0aGUgTlVM
Cj4gPiBjaGFyYWN0ZXIgYW55d2F5LiBBZGQgYSBwYXRjaCB0byBncnViLnBhdGNoZXMgdG8gZG8g
dGhhdC4KPiA+IAo+ID4gU2lnbmVkLW9mZi1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5v
LnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT4KPiA+IFRlc3RlZC1ieTogU3RldmVuIEhhaWdoIDxu
ZXR3aXpAY3JjLmlkLmF1Pgo+IAo+IEFja2VkLWJ5OiBTYW11ZWwgVGhpYmF1bHQgPHNhbXVlbC50
aGliYXVsdEBlbnMtbHlvbi5vcmc+CgpJIHRoaW5rIHRoZSBjb25jbHVzaW9uIG9mIHRoZSBzdWJ0
aHJlYWQgd2FzIGEgcmVsZWFzZSBhY2sgc28gYXBwbGllZCwKdGhhbmtzLgoKCgoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:21:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnnyF-0001z2-Cl; Mon, 10 Nov 2014 12:21:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnnyE-0001yk-Du
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:21:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3E/DE-09842-1CDA0645; Mon, 10 Nov 2014 12:21:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415622080!12731797!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6687 invoked from network); 10 Nov 2014 12:21:21 -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;
	10 Nov 2014 12:21:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191156514"
Message-ID: <1415622077.25176.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Mon, 10 Nov 2014 12:21:17 +0000
In-Reply-To: <20141106113923.GA3182@type.bordeaux.inria.fr>
References: <1413968436.20604.53.camel@citrix.com>
	<20141022095906.GG3659@type.bordeaux.inria.fr>
	<1413974439.18118.1.camel@citrix.com>
	<alpine.DEB.2.02.1410221250510.876@kaball.uk.xensource.com>
	<1413979542.19198.14.camel@citrix.com>
	<alpine.DEB.2.02.1410221313370.876@kaball.uk.xensource.com>
	<5447CBE4.6090104@crc.id.au> <1413992405.19198.24.camel@citrix.com>
	<5447D30A.4040704@crc.id.au>
	<alpine.DEB.2.02.1411061034440.22875@kaball.uk.xensource.com>
	<20141106113923.GA3182@type.bordeaux.inria.fr>
Organization: Citrix Systems, Inc.
Content-Length: 1545
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xen.org,
	netwiz@crc.id.au, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] pvgrub: ignore NUL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDE0LTExLTA2IGF0IDEyOjM5ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gU3RlZmFubyBTdGFiZWxsaW5pLCBsZSBUaHUgMDYgTm92IDIwMTQgMTA6NDE6MjggKzAwMDAs
IGEgw6ljcml0IDoKPiA+IFdoZW4gdXNpbmcgcHZncnViIGluIGdyYXBoaWNhbCBtb2RlIHdpdGgg
dm5jLCB0aGUgZ3J1YiB0aW1lb3V0IGRvZXNuJ3QKPiA+IHdvcms6IHRoZSBjb3VudGRvd24gZG9l
c24ndCBldmVuIHN0YXJ0LiBXaXRoIGEgc2VyaWFsIHRlcm1pbmFsIHRoZQo+ID4gcHJvYmxlbSBk
b2Vzbid0IG9jY3VyIGFuZCB0aGUgY291bnRkb3duIHdvcmtzIGFzIGV4cGVjdGVkLgo+ID4gCj4g
PiBJdCB0dXJucyBvdXQgdGhhdCB0aGUgcHJvYmxlbSBpcyB0aGF0IHdoZW4gdXNpbmcgYSBncmFw
aGljYWwgdGVybWluYWwsCj4gPiBjaGVja2tleSAoKSByZXR1cm5zIDAgaW5zdGVhZCBvZiAtMSB3
aGVuIHRoZXJlIGlzIG5vIGFjdGl2aXR5IG9uIHRoZQo+ID4gbW91c2Ugb3Iga2V5Ym9hcmQuIEFz
IGEgY29uc2VxdWVuY2UgZ3J1YiB0aGlua3MgdGhhdCB0aGUgdXNlciB0eXBlZAo+ID4gc29tZXRo
aW5nIGFuZCBpbnRlcnJ1cHRzIHRoZSBjb3VudCBkb3duLgo+ID4gCj4gPiBUbyBmaXggdGhlIGlz
c3VlIHNpbXBseSBpZ25vcmUga2V5c3Ryb2tlcyByZXR1cm5pbmcgMCwgdGhhdCBpcyB0aGUgTlVM
Cj4gPiBjaGFyYWN0ZXIgYW55d2F5LiBBZGQgYSBwYXRjaCB0byBncnViLnBhdGNoZXMgdG8gZG8g
dGhhdC4KPiA+IAo+ID4gU2lnbmVkLW9mZi1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5v
LnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT4KPiA+IFRlc3RlZC1ieTogU3RldmVuIEhhaWdoIDxu
ZXR3aXpAY3JjLmlkLmF1Pgo+IAo+IEFja2VkLWJ5OiBTYW11ZWwgVGhpYmF1bHQgPHNhbXVlbC50
aGliYXVsdEBlbnMtbHlvbi5vcmc+CgpJIHRoaW5rIHRoZSBjb25jbHVzaW9uIG9mIHRoZSBzdWJ0
aHJlYWQgd2FzIGEgcmVsZWFzZSBhY2sgc28gYXBwbGllZCwKdGhhbmtzLgoKCgoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:27:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:27:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xno4K-0002Le-D3; Mon, 10 Nov 2014 12:27:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xno4J-0002LZ-8i
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 12:27:39 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	07/C5-17735-A3FA0645; Mon, 10 Nov 2014 12:27:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415622456!11559104!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22941 invoked from network); 10 Nov 2014 12:27:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:27:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189718594"
Message-ID: <1415622453.25176.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 10 Nov 2014 12:27:33 +0000
In-Reply-To: <1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] libxl: CODING_STYLE: Much new material
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 14:43 +0000, Ian Jackson wrote:
> Discuss:
> 
>     Memory allocation
>     Conventional variable names
>     Convenience macros
>     Error handling
>     Idempotent data structure construction/destruction
>     Asynchronous/long-running operations
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  tools/libxl/CODING_STYLE |  169 +++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 168 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
> index 110a48f..3e72852 100644
> --- a/tools/libxl/CODING_STYLE
> +++ b/tools/libxl/CODING_STYLE
> @@ -1,6 +1,173 @@
> -Libxenlight Coding Style
> +LIBXENLIGHT CODING STYLE
>  ========================
>  
> +
> +MEMORY ALLOCATION
> +-----------------
> +
> +Memory allocation for libxl-internal purposes should normally be done
> +with the provided gc mechanisms; there is then no need to free.  See
> +"libxl memory management" in libxl.h.
> +
> +
> +CONVENTIONAL VARIABLE NAMES
> +---------------------------
> +
> +The following local variable names should be used where applicable:
> +
> +  int rc;    /* a libxl error code - and not anything else */
> +  int r;     /* the return value from a system call (or libxc call) */

Quite a bit more "ret" for this one. Probably quite a few are being
misused as rc too, which is perhaps why you omitted it?

> +ERROR HANDLING
> +--------------
> +
> +Unless, there are good reasons to do otherwise, the following error
> +handling and cleanup paradigm should be used:
> +
> +  * All local variables referring to resources which might need
> +    cleaning up are declared at the top of the function, and
> +    initialised to a sentinel value indicating "nothing allocated".
> +    For example,
> +            libxl_evgen_disk_eject *evg = NULL;
> +            int nullfd = -1;
> +
> +  * If the function is to return a libxl error value, `rc' is
> +    used to contain the error codem, but it is NOT initialised:

I suspect this is a typo? (but then I never studied latin...)

> +  * Function calls which might fail (ie most function calls) are
> +    handled by putting the return/status value into a variable, and
> +    then checking it in a separate statement:
> +            evg->vdev = strdup(vdev);
> +            if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }

A slightly dodgy example because this should be GCSTRDUP(NOGC, vdev) and
therefore can't fail ;-)

> +IDEMPOTENT DATA STRUCTURE CONSTRUCTION/DESTRUCTION
> +--------------------------------------------------
> +
> +Nontrivial data structures (in structs) should come with an idempotent
> +_destroy function, which must free all resources associated with the

_dispose.

> +data structure (but not free the struct itself).
> +
> +Such a struct should also come with an _init function which
> +initialises the struct so that _destroy is a no-op.

again




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:27:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:27:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xno4K-0002Le-D3; Mon, 10 Nov 2014 12:27:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xno4J-0002LZ-8i
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 12:27:39 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	07/C5-17735-A3FA0645; Mon, 10 Nov 2014 12:27:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415622456!11559104!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22941 invoked from network); 10 Nov 2014 12:27:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:27:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189718594"
Message-ID: <1415622453.25176.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 10 Nov 2014 12:27:33 +0000
In-Reply-To: <1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] libxl: CODING_STYLE: Much new material
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 14:43 +0000, Ian Jackson wrote:
> Discuss:
> 
>     Memory allocation
>     Conventional variable names
>     Convenience macros
>     Error handling
>     Idempotent data structure construction/destruction
>     Asynchronous/long-running operations
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  tools/libxl/CODING_STYLE |  169 +++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 168 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
> index 110a48f..3e72852 100644
> --- a/tools/libxl/CODING_STYLE
> +++ b/tools/libxl/CODING_STYLE
> @@ -1,6 +1,173 @@
> -Libxenlight Coding Style
> +LIBXENLIGHT CODING STYLE
>  ========================
>  
> +
> +MEMORY ALLOCATION
> +-----------------
> +
> +Memory allocation for libxl-internal purposes should normally be done
> +with the provided gc mechanisms; there is then no need to free.  See
> +"libxl memory management" in libxl.h.
> +
> +
> +CONVENTIONAL VARIABLE NAMES
> +---------------------------
> +
> +The following local variable names should be used where applicable:
> +
> +  int rc;    /* a libxl error code - and not anything else */
> +  int r;     /* the return value from a system call (or libxc call) */

Quite a bit more "ret" for this one. Probably quite a few are being
misused as rc too, which is perhaps why you omitted it?

> +ERROR HANDLING
> +--------------
> +
> +Unless, there are good reasons to do otherwise, the following error
> +handling and cleanup paradigm should be used:
> +
> +  * All local variables referring to resources which might need
> +    cleaning up are declared at the top of the function, and
> +    initialised to a sentinel value indicating "nothing allocated".
> +    For example,
> +            libxl_evgen_disk_eject *evg = NULL;
> +            int nullfd = -1;
> +
> +  * If the function is to return a libxl error value, `rc' is
> +    used to contain the error codem, but it is NOT initialised:

I suspect this is a typo? (but then I never studied latin...)

> +  * Function calls which might fail (ie most function calls) are
> +    handled by putting the return/status value into a variable, and
> +    then checking it in a separate statement:
> +            evg->vdev = strdup(vdev);
> +            if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }

A slightly dodgy example because this should be GCSTRDUP(NOGC, vdev) and
therefore can't fail ;-)

> +IDEMPOTENT DATA STRUCTURE CONSTRUCTION/DESTRUCTION
> +--------------------------------------------------
> +
> +Nontrivial data structures (in structs) should come with an idempotent
> +_destroy function, which must free all resources associated with the

_dispose.

> +data structure (but not free the struct itself).
> +
> +Such a struct should also come with an _init function which
> +initialises the struct so that _destroy is a no-op.

again




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:30:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:30:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xno72-0002SB-Vk; Mon, 10 Nov 2014 12:30:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xno72-0002S5-12
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 12:30:28 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	ED/8F-02696-3EFA0645; Mon, 10 Nov 2014 12:30:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415622624!12489608!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5232 invoked from network); 10 Nov 2014 12:30:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:30:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189719153"
Message-ID: <1415622619.25176.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 10 Nov 2014 12:30:19 +0000
In-Reply-To: <1415198630-29937-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415198630-29937-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4/4] libxl: CODING_STYLE: Discuss existing
	style problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 14:43 +0000, Ian Jackson wrote:
> +If it is not feasible to conform fully to the style while patching old
> +code, without doing substantial style reengineering first, we may
> +accept patches which contain nonconformant elements, provided that
> +they don't make the coding style problem worse overall.

I'd perhaps be a little more explicit and say that the exceptional code
should conform to the (probably implicit) prevailing style in the area
so far as that is possible.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:30:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:30:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xno72-0002SB-Vk; Mon, 10 Nov 2014 12:30:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xno72-0002S5-12
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 12:30:28 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	ED/8F-02696-3EFA0645; Mon, 10 Nov 2014 12:30:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415622624!12489608!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5232 invoked from network); 10 Nov 2014 12:30:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:30:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189719153"
Message-ID: <1415622619.25176.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 10 Nov 2014 12:30:19 +0000
In-Reply-To: <1415198630-29937-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415198630-29937-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4/4] libxl: CODING_STYLE: Discuss existing
	style problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-05 at 14:43 +0000, Ian Jackson wrote:
> +If it is not feasible to conform fully to the style while patching old
> +code, without doing substantial style reengineering first, we may
> +accept patches which contain nonconformant elements, provided that
> +they don't make the coding style problem worse overall.

I'd perhaps be a little more explicit and say that the exceptional code
should conform to the (probably implicit) prevailing style in the area
so far as that is possible.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:35:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:35:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoBq-0002fd-RP; Mon, 10 Nov 2014 12:35: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 1XnoBo-0002fY-RE
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:35:24 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	CC/D6-29352-C01B0645; Mon, 10 Nov 2014 12:35:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415622922!6228449!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15876 invoked from network); 10 Nov 2014 12:35:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:35:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189720850"
Message-ID: <1415622920.25176.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Date: Mon, 10 Nov 2014 12:35:20 +0000
In-Reply-To: <0E6C0A5F-0FE6-42A6-BD57-60ADB3D21B82@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<21586.10214.683512.296628@chiark.greenend.org.uk>
	<20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
	<1415186272.15317.5.camel@citrix.com>
	<0E6C0A5F-0FE6-42A6-BD57-60ADB3D21B82@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Matt Wilson <msw@linux.com>, Ian Jackson <ijackson@chiark.greenend.org.uk>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 16:01 +0000, Lars Kurth wrote:
> On 5 Nov 2014, at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
> >> I think that we should reduce any burden on the security team by
> >> making this a community decision that is discussed in public, rather
> >> than something that is handled exclusively in a closed manner as it is
> >> today. This way others who are active community participants can help
> >> with the decision making process can do the investigation and weigh in
> >> on the risk/benefit tradeoff to the security process and the
> >> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> >> or [1] if you are willing to visit a URL. ;-)
> >> 
> >> There's been a bit of talk about "delay" and so on. I'd rather not set
> >> expectations on how long the processing a petition to be added to the
> >> predisclosure list should take. Building community consensus takes
> >> time, just as it does for
> > 
> > I think regardless of who is processing the applications what is more
> > important is to have a concrete set of *objective* criteria. Anyone who
> > demonstrates that they meet those criteria must be allowed to join.
> 
> I don't think that having applications discussed and processed on a
> dedicated public list and objective criteria are mutually exclusive.

I didn't say otherwise. In fact I said the opposite.

My concern was about the criteria being objective and not subjective,
regardless of who is processing them.

Nobody should be doing a "risk/benefit tradeoff to the security process
and the project" when processing an application. They should be going
through a list ticking boxes to show that the applicant has(n't) met
various criteria.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:35:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:35:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoBq-0002fd-RP; Mon, 10 Nov 2014 12:35: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 1XnoBo-0002fY-RE
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:35:24 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	CC/D6-29352-C01B0645; Mon, 10 Nov 2014 12:35:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415622922!6228449!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15876 invoked from network); 10 Nov 2014 12:35:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:35:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189720850"
Message-ID: <1415622920.25176.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Date: Mon, 10 Nov 2014 12:35:20 +0000
In-Reply-To: <0E6C0A5F-0FE6-42A6-BD57-60ADB3D21B82@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<21586.10214.683512.296628@chiark.greenend.org.uk>
	<20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
	<1415186272.15317.5.camel@citrix.com>
	<0E6C0A5F-0FE6-42A6-BD57-60ADB3D21B82@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Matt Wilson <msw@linux.com>, Ian Jackson <ijackson@chiark.greenend.org.uk>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-06 at 16:01 +0000, Lars Kurth wrote:
> On 5 Nov 2014, at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
> >> I think that we should reduce any burden on the security team by
> >> making this a community decision that is discussed in public, rather
> >> than something that is handled exclusively in a closed manner as it is
> >> today. This way others who are active community participants can help
> >> with the decision making process can do the investigation and weigh in
> >> on the risk/benefit tradeoff to the security process and the
> >> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> >> or [1] if you are willing to visit a URL. ;-)
> >> 
> >> There's been a bit of talk about "delay" and so on. I'd rather not set
> >> expectations on how long the processing a petition to be added to the
> >> predisclosure list should take. Building community consensus takes
> >> time, just as it does for
> > 
> > I think regardless of who is processing the applications what is more
> > important is to have a concrete set of *objective* criteria. Anyone who
> > demonstrates that they meet those criteria must be allowed to join.
> 
> I don't think that having applications discussed and processed on a
> dedicated public list and objective criteria are mutually exclusive.

I didn't say otherwise. In fact I said the opposite.

My concern was about the criteria being objective and not subjective,
regardless of who is processing them.

Nobody should be doing a "risk/benefit tradeoff to the security process
and the project" when processing an application. They should be going
through a list ticking boxes to show that the applicant has(n't) met
various criteria.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:35:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12: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 1XnoCH-0002hm-8U; Mon, 10 Nov 2014 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 <Stefano.Stabellini@citrix.com>) id 1XnoCF-0002ha-OU
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 12:35:51 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	1A/F0-14214-721B0645; Mon, 10 Nov 2014 12:35:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415622948!11543896!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6482 invoked from network); 10 Nov 2014 12:35:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:35:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191159744"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:35:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XnoBi-00043i-Lv;
	Mon, 10 Nov 2014 12:35:18 +0000
Date: Mon, 10 Nov 2014 12:35:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141110101645.GA21366@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411101200080.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
	<20141107181430.GH29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071834540.22875@kaball.uk.xensource.com>
	<20141110101645.GA21366@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Catalin Marinas wrote:
> On Fri, Nov 07, 2014 at 06:45:22PM +0000, Stefano Stabellini wrote:
> > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > On Fri, Nov 07, 2014 at 05:35:41PM +0000, Stefano Stabellini wrote:
> > > > On Fri, 7 Nov 2014, Stefano Stabellini wrote:
> > > > > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > > > > What I would like to see is xen_dma_map_page() also using hyp calls for
> > > > > > cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> > > > > > need another argument to xen_dma_map_page() though to pass the real
> > > > > > device address or mfn (and on the map side you could simply check for
> > > > > > page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> > > > > > bouncing so you don't need dom0 swiotlb involved as well.
> > > > > 
> > > > > I can see that it would be nice to have map_page and unmap_page be
> > > > > symmetrical. However actually doing the map_page flush with an hypercall
> > > > > would slow things down. Hypercalls are slower than function calls. It is
> > > > > faster to do the cache flushing in dom0 if possible. In the map_page
> > > > > case we have the struct page so we can easily do it by calling the
> > > > > native dma_ops function.
> > > > > 
> > > > > Maybe I could just add a comment to explain the reason for the asymmetry?
> > > > 
> > > > Ah, but the problem is that map_page could allocate a swiotlb buffer
> > > > (actually it does on arm64) that without a corresponding unmap_page
> > > > call, would end up being leaked, right?
> > > 
> > > Yes. You could hack dma_capable() to always return true for dom0
> > > (because the pfn/dma address here doesn't have anything to do with the
> > > real mfn) but that's more of a hack assuming a lot about the swiotlb
> > > implementation.
> > 
> > Another idea would be to avoid calling the native map_page for foreign
> > pages, but in the xen specific implementation instead of making the
> > hypercall, we could call __dma_map_area on arm64 and map_page on arm.
> 
> The problem here is that you assume that for an SoC that is not fully
> coherent all it needs is __dma_map_area. If you look at mach-mvebu, the
> DMA is nearly cache coherent but it needs some specific synchronisation
> barrier at the interconnect level. If we get something like this on a
> platform with virtualisation, it would be implemented at the dom0 level
> by SoC-specific DMA ops. Xen hypervisor I assume has its own BSP, hence
> it could implement SoC specific cache flushing there. But with the mix
> of cache flushing in dom0 on map and hypervisor on unmap such thing is
> no longer be possible in a nice way.

Yes, Xen has its own little platform files.

I think you convinced me that having map in Linux and unmap in Xen is
not a long term solid solution.


> > In arch/arm/include/asm/xen/page-coherent.h:
> > 
> > static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> > 	     dma_addr_t dev_addr, unsigned long offset, size_t size,
> > 	     enum dma_data_direction dir, struct dma_attrs *attrs)
> > {
> > 	if (pfn_valid(PFN_DOWN(dev_addr))) {
> 
> BTW, pfn_valid() is more expensive than simply comparing the mfn with
> pfn for dom0. The calling code knows this already and it may be quicker
> to simply pass a "bool foreign" argument.

Good point, I can compare mfn and pfn here.
I cannot do the same in unmap_page and the various sync operations,
because there is no pfn available, but maybe I could use
set_page_private to set a flag. I'll think about it.


> > It wouldn't be as nice as using the hypercall but it would be faster and
> > wouldn't depend on the inner workings of the arm64 implementation of
> > map_page, except for __dma_map_area.
> 
> This "except" is big as we may at some point get some SoC like mvebu (I
> would say less likely for arm64 than arm32).
> 
> BTW, does the Xen hypervisor already have a mapping of the mfn?

On arm64, it does.
On arm32, we have a pool of mappings, when we run out we start
overwriting old mappings.


> If not
> and it has to create one temporarily for the flush, you may not lose
> much by using the dom0 ops for unmap with a hyper call for temporarily
> mapping the foreign page in dom0's IPA space (you could do the unmapping
> lazily).

That's true. Fortunately on arm64 we are OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:35:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12: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 1XnoCJ-0002i9-1s; Mon, 10 Nov 2014 12:35:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnoCH-0002hi-30
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:35:53 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	15/1D-27785-821B0645; Mon, 10 Nov 2014 12:35:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415622950!12495199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2876 invoked from network); 10 Nov 2014 12:35:51 -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 Nov 2014 12:35:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191159752"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:35:25 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnoBp-00043l-Aj;
	Mon, 10 Nov 2014 12:35:25 +0000
Date: Mon, 10 Nov 2014 12:35:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141110123525.GD28360@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545CF499.8080606@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 11:34:33AM -0500, Zhigang Wang wrote:
> On 11/07/2014 05:47 AM, Wei Liu wrote:
> > On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> >> Hi,
> >>
> >> While doing VM migration, in the destination side:
> >>
> >>    # xl list -l
> >>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
> >>     [
> >>         {
> >>             "domid": 0,
> >>             "config": {
> >>                 "c_info": {
> >>                     "type": "pv",
> >>                     "name": "Domain-0"
> >>                 },
> >>                 "b_info": {
> >>                     "max_memkb": 876544,
> >>                     "target_memkb": 876543,
> >>                     "sched_params": {
> >>     
> >>                     },
> >>                     "type.pv": {
> >>     
> >>                     }
> >>                 }
> >>             }
> >>         }
> >>     ]
> >>  
> >>     # xl list
> >>     Name                                          ID   Mem VCPUs      State   Time(s)
> >>     Domain-0                                       0   856     4     r-----    2758.9
> >>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> >>
> >> Testing on:
> >>
> > 
> > What's the rune you used to migrate the domain? xl migrate? Why is the
> > domain paused?
> 
> The domain is under migrating, so the destination side it's paused. When migration finish,
> it will become running.
> 
> FYI: the domain migration will success.
> 

I see. At that point the configuration was not available, yet. After the
domain is successfully migrated, the configuration should be available.

I think a domain under construction without domain configuration is a
valid state. What do you think?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:35:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12: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 1XnoCH-0002hm-8U; Mon, 10 Nov 2014 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 <Stefano.Stabellini@citrix.com>) id 1XnoCF-0002ha-OU
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 12:35:51 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	1A/F0-14214-721B0645; Mon, 10 Nov 2014 12:35:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415622948!11543896!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6482 invoked from network); 10 Nov 2014 12:35:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:35:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191159744"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:35:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XnoBi-00043i-Lv;
	Mon, 10 Nov 2014 12:35:18 +0000
Date: Mon, 10 Nov 2014 12:35:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141110101645.GA21366@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411101200080.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
	<20141107181430.GH29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071834540.22875@kaball.uk.xensource.com>
	<20141110101645.GA21366@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Catalin Marinas wrote:
> On Fri, Nov 07, 2014 at 06:45:22PM +0000, Stefano Stabellini wrote:
> > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > On Fri, Nov 07, 2014 at 05:35:41PM +0000, Stefano Stabellini wrote:
> > > > On Fri, 7 Nov 2014, Stefano Stabellini wrote:
> > > > > On Fri, 7 Nov 2014, Catalin Marinas wrote:
> > > > > > What I would like to see is xen_dma_map_page() also using hyp calls for
> > > > > > cache maintenance when !pfn_valid(), for symmetry with unmap. You would
> > > > > > need another argument to xen_dma_map_page() though to pass the real
> > > > > > device address or mfn (and on the map side you could simply check for
> > > > > > page_to_pfn(page) != mfn). For such cases, Xen swiotlb already handles
> > > > > > bouncing so you don't need dom0 swiotlb involved as well.
> > > > > 
> > > > > I can see that it would be nice to have map_page and unmap_page be
> > > > > symmetrical. However actually doing the map_page flush with an hypercall
> > > > > would slow things down. Hypercalls are slower than function calls. It is
> > > > > faster to do the cache flushing in dom0 if possible. In the map_page
> > > > > case we have the struct page so we can easily do it by calling the
> > > > > native dma_ops function.
> > > > > 
> > > > > Maybe I could just add a comment to explain the reason for the asymmetry?
> > > > 
> > > > Ah, but the problem is that map_page could allocate a swiotlb buffer
> > > > (actually it does on arm64) that without a corresponding unmap_page
> > > > call, would end up being leaked, right?
> > > 
> > > Yes. You could hack dma_capable() to always return true for dom0
> > > (because the pfn/dma address here doesn't have anything to do with the
> > > real mfn) but that's more of a hack assuming a lot about the swiotlb
> > > implementation.
> > 
> > Another idea would be to avoid calling the native map_page for foreign
> > pages, but in the xen specific implementation instead of making the
> > hypercall, we could call __dma_map_area on arm64 and map_page on arm.
> 
> The problem here is that you assume that for an SoC that is not fully
> coherent all it needs is __dma_map_area. If you look at mach-mvebu, the
> DMA is nearly cache coherent but it needs some specific synchronisation
> barrier at the interconnect level. If we get something like this on a
> platform with virtualisation, it would be implemented at the dom0 level
> by SoC-specific DMA ops. Xen hypervisor I assume has its own BSP, hence
> it could implement SoC specific cache flushing there. But with the mix
> of cache flushing in dom0 on map and hypervisor on unmap such thing is
> no longer be possible in a nice way.

Yes, Xen has its own little platform files.

I think you convinced me that having map in Linux and unmap in Xen is
not a long term solid solution.


> > In arch/arm/include/asm/xen/page-coherent.h:
> > 
> > static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> > 	     dma_addr_t dev_addr, unsigned long offset, size_t size,
> > 	     enum dma_data_direction dir, struct dma_attrs *attrs)
> > {
> > 	if (pfn_valid(PFN_DOWN(dev_addr))) {
> 
> BTW, pfn_valid() is more expensive than simply comparing the mfn with
> pfn for dom0. The calling code knows this already and it may be quicker
> to simply pass a "bool foreign" argument.

Good point, I can compare mfn and pfn here.
I cannot do the same in unmap_page and the various sync operations,
because there is no pfn available, but maybe I could use
set_page_private to set a flag. I'll think about it.


> > It wouldn't be as nice as using the hypercall but it would be faster and
> > wouldn't depend on the inner workings of the arm64 implementation of
> > map_page, except for __dma_map_area.
> 
> This "except" is big as we may at some point get some SoC like mvebu (I
> would say less likely for arm64 than arm32).
> 
> BTW, does the Xen hypervisor already have a mapping of the mfn?

On arm64, it does.
On arm32, we have a pool of mappings, when we run out we start
overwriting old mappings.


> If not
> and it has to create one temporarily for the flush, you may not lose
> much by using the dom0 ops for unmap with a hyper call for temporarily
> mapping the foreign page in dom0's IPA space (you could do the unmapping
> lazily).

That's true. Fortunately on arm64 we are OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:35:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12: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 1XnoCJ-0002i9-1s; Mon, 10 Nov 2014 12:35:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnoCH-0002hi-30
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:35:53 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	15/1D-27785-821B0645; Mon, 10 Nov 2014 12:35:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415622950!12495199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2876 invoked from network); 10 Nov 2014 12:35:51 -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 Nov 2014 12:35:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191159752"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:35:25 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnoBp-00043l-Aj;
	Mon, 10 Nov 2014 12:35:25 +0000
Date: Mon, 10 Nov 2014 12:35:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141110123525.GD28360@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545CF499.8080606@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 11:34:33AM -0500, Zhigang Wang wrote:
> On 11/07/2014 05:47 AM, Wei Liu wrote:
> > On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> >> Hi,
> >>
> >> While doing VM migration, in the destination side:
> >>
> >>    # xl list -l
> >>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
> >>     [
> >>         {
> >>             "domid": 0,
> >>             "config": {
> >>                 "c_info": {
> >>                     "type": "pv",
> >>                     "name": "Domain-0"
> >>                 },
> >>                 "b_info": {
> >>                     "max_memkb": 876544,
> >>                     "target_memkb": 876543,
> >>                     "sched_params": {
> >>     
> >>                     },
> >>                     "type.pv": {
> >>     
> >>                     }
> >>                 }
> >>             }
> >>         }
> >>     ]
> >>  
> >>     # xl list
> >>     Name                                          ID   Mem VCPUs      State   Time(s)
> >>     Domain-0                                       0   856     4     r-----    2758.9
> >>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> >>
> >> Testing on:
> >>
> > 
> > What's the rune you used to migrate the domain? xl migrate? Why is the
> > domain paused?
> 
> The domain is under migrating, so the destination side it's paused. When migration finish,
> it will become running.
> 
> FYI: the domain migration will success.
> 

I see. At that point the configuration was not available, yet. After the
domain is successfully migrated, the configuration should be available.

I think a domain under construction without domain configuration is a
valid state. What do you think?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:37:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12: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 1XnoEB-0002xW-JN; Mon, 10 Nov 2014 12:37:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnoEA-0002xN-Um
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:37:51 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	D7/45-23865-E91B0645; Mon, 10 Nov 2014 12:37:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415623068!9107111!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6043 invoked from network); 10 Nov 2014 12:37:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:37:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191160269"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:37:47 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnoE7-000470-Do;
	Mon, 10 Nov 2014 12:37:47 +0000
Date: Mon, 10 Nov 2014 12:37:47 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141110123747.GE28360@zion.uk.xensource.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545CD572.9040801@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 09:21:38AM -0500, Zhigang Wang wrote:
> On 11/07/2014 06:05 AM, Wei Liu wrote:
> > On Thu, Nov 06, 2014 at 05:17:42PM -0500, Zhigang Wang wrote:
> >> Hi,
> >>
> >> I get this error:
> >>
> >>     # xl mem-max 3 700
> >>     libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max
> >>     : Success
> >>     cannot set domid 3 static max memory to : 700
> >>
> > 
> > What's your expected behaviour? What's your end goal?
> 
> I expect: after start a VM with memory = 700, then I can do:
> 
>    # xl mem-max <domain> 700
> 
> In our code, we always check (libxl.c):
> 
> 
>     if (max_memkb < memorykb) {
>         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
>         goto out;
>     }
> 
> As target memory is always bigger than static-max in xenstore (from my test, for both pv and hvm):
> 
>     /local/domain/3/memory/static-max = "716800"
>     /local/domain/3/memory/target = "716801
> 
> So it will not success.
> 
> Also I think target memory bigger than static-max seems not right.
> 

This does look bogus, which may cause the guest to try to balloon up
over limit. At the very least, we should fix make target as big as
statix-max?

Ian and Ian, any thought how this bug came into being? I think we should
fix this for 4.5, but I don't think I know enough of how memory target
is expected to behave.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:37:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12: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 1XnoEB-0002xW-JN; Mon, 10 Nov 2014 12:37:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnoEA-0002xN-Um
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:37:51 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	D7/45-23865-E91B0645; Mon, 10 Nov 2014 12:37:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415623068!9107111!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6043 invoked from network); 10 Nov 2014 12:37:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:37:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191160269"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:37:47 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnoE7-000470-Do;
	Mon, 10 Nov 2014 12:37:47 +0000
Date: Mon, 10 Nov 2014 12:37:47 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141110123747.GE28360@zion.uk.xensource.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545CD572.9040801@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 09:21:38AM -0500, Zhigang Wang wrote:
> On 11/07/2014 06:05 AM, Wei Liu wrote:
> > On Thu, Nov 06, 2014 at 05:17:42PM -0500, Zhigang Wang wrote:
> >> Hi,
> >>
> >> I get this error:
> >>
> >>     # xl mem-max 3 700
> >>     libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max
> >>     : Success
> >>     cannot set domid 3 static max memory to : 700
> >>
> > 
> > What's your expected behaviour? What's your end goal?
> 
> I expect: after start a VM with memory = 700, then I can do:
> 
>    # xl mem-max <domain> 700
> 
> In our code, we always check (libxl.c):
> 
> 
>     if (max_memkb < memorykb) {
>         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
>         goto out;
>     }
> 
> As target memory is always bigger than static-max in xenstore (from my test, for both pv and hvm):
> 
>     /local/domain/3/memory/static-max = "716800"
>     /local/domain/3/memory/target = "716801
> 
> So it will not success.
> 
> Also I think target memory bigger than static-max seems not right.
> 

This does look bogus, which may cause the guest to try to balloon up
over limit. At the very least, we should fix make target as big as
statix-max?

Ian and Ian, any thought how this bug came into being? I think we should
fix this for 4.5, but I don't think I know enough of how memory target
is expected to behave.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:39:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:39:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoFH-00037N-67; Mon, 10 Nov 2014 12:38:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnoFG-000376-4B
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:38:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6E/72-24532-1E1B0645; Mon, 10 Nov 2014 12:38:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415623135!12369221!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4043 invoked from network); 10 Nov 2014 12:38:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:38:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191160459"
Message-ID: <1415623133.25176.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 12:38:53 +0000
In-Reply-To: <20141110123525.GD28360@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, 2014-11-10 at 12:35 +0000, Wei Liu wrote:
> On Fri, Nov 07, 2014 at 11:34:33AM -0500, Zhigang Wang wrote:
> > On 11/07/2014 05:47 AM, Wei Liu wrote:
> > > On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> > >> Hi,
> > >>
> > >> While doing VM migration, in the destination side:
> > >>
> > >>    # xl list -l
> > >>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
> > >>     [
> > >>         {
> > >>             "domid": 0,
> > >>             "config": {
> > >>                 "c_info": {
> > >>                     "type": "pv",
> > >>                     "name": "Domain-0"
> > >>                 },
> > >>                 "b_info": {
> > >>                     "max_memkb": 876544,
> > >>                     "target_memkb": 876543,
> > >>                     "sched_params": {
> > >>     
> > >>                     },
> > >>                     "type.pv": {
> > >>     
> > >>                     }
> > >>                 }
> > >>             }
> > >>         }
> > >>     ]
> > >>  
> > >>     # xl list
> > >>     Name                                          ID   Mem VCPUs      State   Time(s)
> > >>     Domain-0                                       0   856     4     r-----    2758.9
> > >>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> > >>
> > >> Testing on:
> > >>
> > > 
> > > What's the rune you used to migrate the domain? xl migrate? Why is the
> > > domain paused?
> > 
> > The domain is under migrating, so the destination side it's paused. When migration finish,
> > it will become running.
> > 
> > FYI: the domain migration will success.
> > 
> 
> I see. At that point the configuration was not available, yet. After the
> domain is successfully migrated, the configuration should be available.
> 
> I think a domain under construction without domain configuration is a
> valid state. What do you think?

Can we write a stub json file at the beginning of migrate receive, a bit
like we do on create?

Otherwise code like xl list is going to have start special casing
domains which have no json, which we've tried hard to avoid I think.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:39:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:39:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoFH-00037N-67; Mon, 10 Nov 2014 12:38:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnoFG-000376-4B
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:38:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6E/72-24532-1E1B0645; Mon, 10 Nov 2014 12:38:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415623135!12369221!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4043 invoked from network); 10 Nov 2014 12:38:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:38:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191160459"
Message-ID: <1415623133.25176.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 12:38:53 +0000
In-Reply-To: <20141110123525.GD28360@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, 2014-11-10 at 12:35 +0000, Wei Liu wrote:
> On Fri, Nov 07, 2014 at 11:34:33AM -0500, Zhigang Wang wrote:
> > On 11/07/2014 05:47 AM, Wei Liu wrote:
> > > On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> > >> Hi,
> > >>
> > >> While doing VM migration, in the destination side:
> > >>
> > >>    # xl list -l
> > >>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
> > >>     [
> > >>         {
> > >>             "domid": 0,
> > >>             "config": {
> > >>                 "c_info": {
> > >>                     "type": "pv",
> > >>                     "name": "Domain-0"
> > >>                 },
> > >>                 "b_info": {
> > >>                     "max_memkb": 876544,
> > >>                     "target_memkb": 876543,
> > >>                     "sched_params": {
> > >>     
> > >>                     },
> > >>                     "type.pv": {
> > >>     
> > >>                     }
> > >>                 }
> > >>             }
> > >>         }
> > >>     ]
> > >>  
> > >>     # xl list
> > >>     Name                                          ID   Mem VCPUs      State   Time(s)
> > >>     Domain-0                                       0   856     4     r-----    2758.9
> > >>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> > >>
> > >> Testing on:
> > >>
> > > 
> > > What's the rune you used to migrate the domain? xl migrate? Why is the
> > > domain paused?
> > 
> > The domain is under migrating, so the destination side it's paused. When migration finish,
> > it will become running.
> > 
> > FYI: the domain migration will success.
> > 
> 
> I see. At that point the configuration was not available, yet. After the
> domain is successfully migrated, the configuration should be available.
> 
> I think a domain under construction without domain configuration is a
> valid state. What do you think?

Can we write a stub json file at the beginning of migrate receive, a bit
like we do on create?

Otherwise code like xl list is going to have start special casing
domains which have no json, which we've tried hard to avoid I think.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:42:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:42:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoIQ-0003Lc-Rm; Mon, 10 Nov 2014 12:42:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnoIP-0003LX-RW
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 12:42:13 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	CE/EC-02954-5A2B0645; Mon, 10 Nov 2014 12:42:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415623331!12497002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24204 invoked from network); 10 Nov 2014 12:42:12 -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 Nov 2014 12:42:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191161107"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:42:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XnoIM-0004BD-Dg;
	Mon, 10 Nov 2014 12:42:10 +0000
Date: Mon, 10 Nov 2014 12:41:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411101200080.22875@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411101240290.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
	<20141107181430.GH29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071834540.22875@kaball.uk.xensource.com>
	<20141110101645.GA21366@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411101200080.22875@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Stefano Stabellini wrote:
> > BTW, pfn_valid() is more expensive than simply comparing the mfn with
> > pfn for dom0. The calling code knows this already and it may be quicker
> > to simply pass a "bool foreign" argument.
> 
> Good point, I can compare mfn and pfn here.
> I cannot do the same in unmap_page and the various sync operations,
> because there is no pfn available, but maybe I could use
> set_page_private to set a flag. I'll think about it.

But of course there is no struct page either so I think pfn_valid will
have to stay in unmap and sync

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:42:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:42:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoIQ-0003Lc-Rm; Mon, 10 Nov 2014 12:42:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnoIP-0003LX-RW
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 12:42:13 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	CE/EC-02954-5A2B0645; Mon, 10 Nov 2014 12:42:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415623331!12497002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24204 invoked from network); 10 Nov 2014 12:42:12 -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 Nov 2014 12:42:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191161107"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:42:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XnoIM-0004BD-Dg;
	Mon, 10 Nov 2014 12:42:10 +0000
Date: Mon, 10 Nov 2014 12:41:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411101200080.22875@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411101240290.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411051757140.22875@kaball.uk.xensource.com>
	<20141106103337.GA19702@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411061155200.22875@kaball.uk.xensource.com>
	<20141107110524.GA21875@localhost>
	<alpine.DEB.2.02.1411071212250.22875@kaball.uk.xensource.com>
	<20141107160006.GE29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071646170.22875@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411071732550.22875@kaball.uk.xensource.com>
	<20141107181430.GH29148@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411071834540.22875@kaball.uk.xensource.com>
	<20141110101645.GA21366@e104818-lin.cambridge.arm.com>
	<alpine.DEB.2.02.1411101200080.22875@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v7 3/8] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Stefano Stabellini wrote:
> > BTW, pfn_valid() is more expensive than simply comparing the mfn with
> > pfn for dom0. The calling code knows this already and it may be quicker
> > to simply pass a "bool foreign" argument.
> 
> Good point, I can compare mfn and pfn here.
> I cannot do the same in unmap_page and the various sync operations,
> because there is no pfn available, but maybe I could use
> set_page_private to set a flag. I'll think about it.

But of course there is no struct page either so I think pfn_valid will
have to stay in unmap and sync

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:44:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:44:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoKQ-0003Rx-Cw; Mon, 10 Nov 2014 12:44:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnoKP-0003Rq-7H
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:44:17 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	59/95-26652-023B0645; Mon, 10 Nov 2014 12:44:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415623451!11505080!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30258 invoked from network); 10 Nov 2014 12:44:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:44:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191161771"
Message-ID: <1415623447.25176.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 12:44:07 +0000
In-Reply-To: <20141110123747.GE28360@zion.uk.xensource.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 12:37 +0000, Wei Liu wrote:

> Ian and Ian, any thought how this bug came into being? I think we should
> fix this for 4.5, but I don't think I know enough of how memory target
> is expected to behave.
> 

I'm confused by the description of what's going on, in particular the
mixing of mem-max commands and target xenstore nodes (since the former
doesn't really affect the latter).

How was the domain started (memory= and maxmem=).

What were static-max and target at the point?

What did they change to when xl mem-max was issued? 

What did you expect them to change to instead?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:44:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:44:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoKQ-0003Rx-Cw; Mon, 10 Nov 2014 12:44:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnoKP-0003Rq-7H
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 12:44:17 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	59/95-26652-023B0645; Mon, 10 Nov 2014 12:44:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415623451!11505080!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30258 invoked from network); 10 Nov 2014 12:44:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:44:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191161771"
Message-ID: <1415623447.25176.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 12:44:07 +0000
In-Reply-To: <20141110123747.GE28360@zion.uk.xensource.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 12:37 +0000, Wei Liu wrote:

> Ian and Ian, any thought how this bug came into being? I think we should
> fix this for 4.5, but I don't think I know enough of how memory target
> is expected to behave.
> 

I'm confused by the description of what's going on, in particular the
mixing of mem-max commands and target xenstore nodes (since the former
doesn't really affect the latter).

How was the domain started (memory= and maxmem=).

What were static-max and target at the point?

What did they change to when xl mem-max was issued? 

What did you expect them to change to instead?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:53:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoTW-0003j2-Nc; Mon, 10 Nov 2014 12:53:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XnoTU-0003ix-RQ
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:53:40 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	E6/C5-02697-455B0645; Mon, 10 Nov 2014 12:53:40 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415624017!6116645!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7597 invoked from network); 10 Nov 2014 12:53:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:53:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191163783"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:53:36 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XnoTQ-0004QX-KA;
	Mon, 10 Nov 2014 12:53:36 +0000
Message-ID: <5460B550.9000306@eu.citrix.com>
Date: Mon, 10 Nov 2014 12:53:36 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Meng Xu <mengxu@cis.upenn.edu>, <xen-devel@lists.xen.org>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>
	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>
In-Reply-To: <1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>
X-DLP: MIA2
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	xumengpanda@gmail.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/2014 03:16 PM, Meng Xu wrote:
> Move call to rt_update_deadline from _alloc to _insert;
> Add lock in rt_vcpu_remove().
>
> Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>

This describes what the patch does, but not why.

While it's nice to  have a summary of the technical changes the patch  
makes, that's information I can get from the patch itself. What's 
critical is an explanation of *why* you are moving rt_update_deadline 
from _alloc to _insert.

Having the information in the cover letter isn't enough, because that 
probably won't be available to someone going through the git history and 
trying to figure out why you made this change.

  -George

> ---
>   xen/common/sched_rt.c |   12 +++++++-----
>   1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index b87c95b..f136724 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -508,7 +508,6 @@ static void *
>   rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
>   {
>       struct rt_vcpu *svc;
> -    s_time_t now = NOW();
>   
>       /* Allocate per-VCPU info */
>       svc = xzalloc(struct rt_vcpu);
> @@ -526,10 +525,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
>       if ( !is_idle_vcpu(vc) )
>           svc->budget = RTDS_DEFAULT_BUDGET;
>   
> -    ASSERT( now >= svc->cur_deadline );
> -
> -    rt_update_deadline(now, svc);
> -
>       return svc;
>   }
>   
> @@ -552,11 +547,15 @@ static void
>   rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
>   {
>       struct rt_vcpu *svc = rt_vcpu(vc);
> +    s_time_t now = NOW();
>   
>       /* not addlocate idle vcpu to dom vcpu list */
>       if ( is_idle_vcpu(vc) )
>           return;
>   
> +    if ( now >= svc->cur_deadline )
> +        rt_update_deadline(now, svc);
> +
>       if ( !__vcpu_on_q(svc) && vcpu_runnable(vc) && !vc->is_running )
>           __runq_insert(ops, svc);
>   
> @@ -573,11 +572,14 @@ rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
>   {
>       struct rt_vcpu * const svc = rt_vcpu(vc);
>       struct rt_dom * const sdom = svc->sdom;
> +    spinlock_t *lock;
>   
>       BUG_ON( sdom == NULL );
>   
> +    lock = vcpu_schedule_lock_irq(vc);
>       if ( __vcpu_on_q(svc) )
>           __q_remove(svc);
> +    vcpu_schedule_unlock_irq(lock, vc);
>   
>       if ( !is_idle_vcpu(vc) )
>           list_del_init(&svc->sdom_elem);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:53:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoTW-0003j2-Nc; Mon, 10 Nov 2014 12:53:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XnoTU-0003ix-RQ
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:53:40 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	E6/C5-02697-455B0645; Mon, 10 Nov 2014 12:53:40 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415624017!6116645!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7597 invoked from network); 10 Nov 2014 12:53:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:53:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191163783"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:53:36 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XnoTQ-0004QX-KA;
	Mon, 10 Nov 2014 12:53:36 +0000
Message-ID: <5460B550.9000306@eu.citrix.com>
Date: Mon, 10 Nov 2014 12:53:36 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Meng Xu <mengxu@cis.upenn.edu>, <xen-devel@lists.xen.org>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>
	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>
In-Reply-To: <1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>
X-DLP: MIA2
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	xumengpanda@gmail.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/2014 03:16 PM, Meng Xu wrote:
> Move call to rt_update_deadline from _alloc to _insert;
> Add lock in rt_vcpu_remove().
>
> Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>

This describes what the patch does, but not why.

While it's nice to  have a summary of the technical changes the patch  
makes, that's information I can get from the patch itself. What's 
critical is an explanation of *why* you are moving rt_update_deadline 
from _alloc to _insert.

Having the information in the cover letter isn't enough, because that 
probably won't be available to someone going through the git history and 
trying to figure out why you made this change.

  -George

> ---
>   xen/common/sched_rt.c |   12 +++++++-----
>   1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index b87c95b..f136724 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -508,7 +508,6 @@ static void *
>   rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
>   {
>       struct rt_vcpu *svc;
> -    s_time_t now = NOW();
>   
>       /* Allocate per-VCPU info */
>       svc = xzalloc(struct rt_vcpu);
> @@ -526,10 +525,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
>       if ( !is_idle_vcpu(vc) )
>           svc->budget = RTDS_DEFAULT_BUDGET;
>   
> -    ASSERT( now >= svc->cur_deadline );
> -
> -    rt_update_deadline(now, svc);
> -
>       return svc;
>   }
>   
> @@ -552,11 +547,15 @@ static void
>   rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
>   {
>       struct rt_vcpu *svc = rt_vcpu(vc);
> +    s_time_t now = NOW();
>   
>       /* not addlocate idle vcpu to dom vcpu list */
>       if ( is_idle_vcpu(vc) )
>           return;
>   
> +    if ( now >= svc->cur_deadline )
> +        rt_update_deadline(now, svc);
> +
>       if ( !__vcpu_on_q(svc) && vcpu_runnable(vc) && !vc->is_running )
>           __runq_insert(ops, svc);
>   
> @@ -573,11 +572,14 @@ rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
>   {
>       struct rt_vcpu * const svc = rt_vcpu(vc);
>       struct rt_dom * const sdom = svc->sdom;
> +    spinlock_t *lock;
>   
>       BUG_ON( sdom == NULL );
>   
> +    lock = vcpu_schedule_lock_irq(vc);
>       if ( __vcpu_on_q(svc) )
>           __q_remove(svc);
> +    vcpu_schedule_unlock_irq(lock, vc);
>   
>       if ( !is_idle_vcpu(vc) )
>           list_del_init(&svc->sdom_elem);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:54:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:54:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoUB-0003mC-4n; Mon, 10 Nov 2014 12:54:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XnoUA-0003m3-Ia
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:54:22 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	0D/FC-25714-D75B0645; Mon, 10 Nov 2014 12:54:21 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415624059!11548381!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11343 invoked from network); 10 Nov 2014 12:54:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:54:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189725282"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:54:18 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XnoU6-0004RV-OH;
	Mon, 10 Nov 2014 12:54:18 +0000
Message-ID: <5460B57A.5050601@eu.citrix.com>
Date: Mon, 10 Nov 2014 12:54:18 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Meng Xu <mengxu@cis.upenn.edu>, <xen-devel@lists.xen.org>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>
	<1414246599-3914-2-git-send-email-mengxu@cis.upenn.edu>
In-Reply-To: <1414246599-3914-2-git-send-email-mengxu@cis.upenn.edu>
X-DLP: MIA2
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	xumengpanda@gmail.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 1/2] xen: sanity check input
 and serialization in sched_rt.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/2014 03:16 PM, Meng Xu wrote:
> Sanity check input params in rt_dom_cntl();
> Serialize rt_dom_cntl() against the global lock.
>
> Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>

Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>

Thanks,
  -George

> ---
>   xen/common/sched_rt.c |    9 +++++++++
>   1 file changed, 9 insertions(+)
>
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 6c8faeb..b87c95b 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -1042,9 +1042,11 @@ rt_dom_cntl(
>       struct domain *d,
>       struct xen_domctl_scheduler_op *op)
>   {
> +    struct rt_private *prv = rt_priv(ops);
>       struct rt_dom * const sdom = rt_dom(d);
>       struct rt_vcpu *svc;
>       struct list_head *iter;
> +    unsigned long flags;
>       int rc = 0;
>   
>       switch ( op->cmd )
> @@ -1055,12 +1057,19 @@ rt_dom_cntl(
>           op->u.rtds.budget = svc->budget / MICROSECS(1);
>           break;
>       case XEN_DOMCTL_SCHEDOP_putinfo:
> +        if ( op->u.rtds.period == 0 || op->u.rtds.budget == 0 )
> +        {
> +            rc = -EINVAL;
> +            break;
> +        }
> +        spin_lock_irqsave(&prv->lock, flags);
>           list_for_each( iter, &sdom->vcpu )
>           {
>               struct rt_vcpu * svc = list_entry(iter, struct rt_vcpu, sdom_elem);
>               svc->period = MICROSECS(op->u.rtds.period); /* transfer to nanosec */
>               svc->budget = MICROSECS(op->u.rtds.budget);
>           }
> +        spin_unlock_irqrestore(&prv->lock, flags);
>           break;
>       }
>   


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:54:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:54:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoUB-0003mC-4n; Mon, 10 Nov 2014 12:54:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XnoUA-0003m3-Ia
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 12:54:22 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	0D/FC-25714-D75B0645; Mon, 10 Nov 2014 12:54:21 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415624059!11548381!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11343 invoked from network); 10 Nov 2014 12:54:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:54:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189725282"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 07:54:18 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XnoU6-0004RV-OH;
	Mon, 10 Nov 2014 12:54:18 +0000
Message-ID: <5460B57A.5050601@eu.citrix.com>
Date: Mon, 10 Nov 2014 12:54:18 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Meng Xu <mengxu@cis.upenn.edu>, <xen-devel@lists.xen.org>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>
	<1414246599-3914-2-git-send-email-mengxu@cis.upenn.edu>
In-Reply-To: <1414246599-3914-2-git-send-email-mengxu@cis.upenn.edu>
X-DLP: MIA2
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	xumengpanda@gmail.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 1/2] xen: sanity check input
 and serialization in sched_rt.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/2014 03:16 PM, Meng Xu wrote:
> Sanity check input params in rt_dom_cntl();
> Serialize rt_dom_cntl() against the global lock.
>
> Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>

Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>

Thanks,
  -George

> ---
>   xen/common/sched_rt.c |    9 +++++++++
>   1 file changed, 9 insertions(+)
>
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 6c8faeb..b87c95b 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -1042,9 +1042,11 @@ rt_dom_cntl(
>       struct domain *d,
>       struct xen_domctl_scheduler_op *op)
>   {
> +    struct rt_private *prv = rt_priv(ops);
>       struct rt_dom * const sdom = rt_dom(d);
>       struct rt_vcpu *svc;
>       struct list_head *iter;
> +    unsigned long flags;
>       int rc = 0;
>   
>       switch ( op->cmd )
> @@ -1055,12 +1057,19 @@ rt_dom_cntl(
>           op->u.rtds.budget = svc->budget / MICROSECS(1);
>           break;
>       case XEN_DOMCTL_SCHEDOP_putinfo:
> +        if ( op->u.rtds.period == 0 || op->u.rtds.budget == 0 )
> +        {
> +            rc = -EINVAL;
> +            break;
> +        }
> +        spin_lock_irqsave(&prv->lock, flags);
>           list_for_each( iter, &sdom->vcpu )
>           {
>               struct rt_vcpu * svc = list_entry(iter, struct rt_vcpu, sdom_elem);
>               svc->period = MICROSECS(op->u.rtds.period); /* transfer to nanosec */
>               svc->budget = MICROSECS(op->u.rtds.budget);
>           }
> +        spin_unlock_irqrestore(&prv->lock, flags);
>           break;
>       }
>   


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 12:57:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:57:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoWq-0003xV-PV; Mon, 10 Nov 2014 12:57:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnoWp-0003xC-4Q
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 12:57:07 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	35/24-18267-226B0645; Mon, 10 Nov 2014 12:57:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415624224!7123573!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25579 invoked from network); 10 Nov 2014 12:57:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:57:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189725826"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 07:57:03 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnoWk-0005zc-Mh;
	Mon, 10 Nov 2014 12:57:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnoWk-0004Rk-CG;
	Mon, 10 Nov 2014 12:57:02 +0000
Date: Mon, 10 Nov 2014 12:57:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31403-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31403: 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 31403 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31403/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-freebsd10-amd64  3 host-install(3)      broken REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                a1cff6e25e6e3b55183610dddca91546951b20e3
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
362 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-multivcpu host-install(3)
broken-step test-amd64-i386-freebsd10-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-win7-amd64 host-install(3)

Not pushing.

(No revision log; it would be 11963 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 Nov 10 12:57:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 12:57:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoWq-0003xV-PV; Mon, 10 Nov 2014 12:57:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnoWp-0003xC-4Q
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 12:57:07 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	35/24-18267-226B0645; Mon, 10 Nov 2014 12:57:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415624224!7123573!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25579 invoked from network); 10 Nov 2014 12:57:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 12:57:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="189725826"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 07:57:03 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnoWk-0005zc-Mh;
	Mon, 10 Nov 2014 12:57:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnoWk-0004Rk-CG;
	Mon, 10 Nov 2014 12:57:02 +0000
Date: Mon, 10 Nov 2014 12:57:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31403-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31403: 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 31403 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31403/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-freebsd10-amd64  3 host-install(3)      broken REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                a1cff6e25e6e3b55183610dddca91546951b20e3
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
362 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-multivcpu host-install(3)
broken-step test-amd64-i386-freebsd10-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-win7-amd64 host-install(3)

Not pushing.

(No revision log; it would be 11963 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 Nov 10 13:00:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoZu-00049s-N2; Mon, 10 Nov 2014 13:00:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1XnoZt-00049m-BA
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 13:00:17 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	6E/21-02702-0E6B0645; Mon, 10 Nov 2014 13:00:16 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415624414!12497532!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16566 invoked from network); 10 Nov 2014 13:00:15 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-12.tower-27.messagelabs.com with SMTP;
	10 Nov 2014 13:00:15 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43141117"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 10 Nov 2014 20:57:01 +0800
Received: from G08CNEXCHPEKD03.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAAC9mwv026839;
	Mon, 10 Nov 2014 20:10:08 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 10 Nov 2014 20:10:00 +0800
Message-ID: <5460AB8C.40504@cn.fujitsu.com>
Date: Mon, 10 Nov 2014 20:11:56 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <54604CEA.1060909@cn.fujitsu.com>
	<alpine.DEB.2.02.1411101148300.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411101148300.22875@kaball.uk.xensource.com>
X-Originating-IP: [10.167.226.91]
Cc: xen devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 07:50 PM, Stefano Stabellini wrote:
> On Mon, 10 Nov 2014, Wen Congyang wrote:
>> I disable xen-platform-pci in the config file, but when I start the guest, I found
>> the following kernel message:
>> [    0.000000] Booting paravirtualized kernel on Xen HVM
>> [    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
> 
> You can pass xen_nopv to the kernel command line
> 

Yes, but I don't use the newest kernel...

Thanks
Wen Congyang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 13:00:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnoZu-00049s-N2; Mon, 10 Nov 2014 13:00:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1XnoZt-00049m-BA
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 13:00:17 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	6E/21-02702-0E6B0645; Mon, 10 Nov 2014 13:00:16 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415624414!12497532!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16566 invoked from network); 10 Nov 2014 13:00:15 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-12.tower-27.messagelabs.com with SMTP;
	10 Nov 2014 13:00:15 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43141117"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 10 Nov 2014 20:57:01 +0800
Received: from G08CNEXCHPEKD03.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAAC9mwv026839;
	Mon, 10 Nov 2014 20:10:08 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 10 Nov 2014 20:10:00 +0800
Message-ID: <5460AB8C.40504@cn.fujitsu.com>
Date: Mon, 10 Nov 2014 20:11:56 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <54604CEA.1060909@cn.fujitsu.com>
	<alpine.DEB.2.02.1411101148300.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411101148300.22875@kaball.uk.xensource.com>
X-Originating-IP: [10.167.226.91]
Cc: xen devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 07:50 PM, Stefano Stabellini wrote:
> On Mon, 10 Nov 2014, Wen Congyang wrote:
>> I disable xen-platform-pci in the config file, but when I start the guest, I found
>> the following kernel message:
>> [    0.000000] Booting paravirtualized kernel on Xen HVM
>> [    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
> 
> You can pass xen_nopv to the kernel command line
> 

Yes, but I don't use the newest kernel...

Thanks
Wen Congyang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 13:11:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnokQ-0004O0-GG; Mon, 10 Nov 2014 13:11:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnokO-0004Ns-Bt
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 13:11:08 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	A9/21-02953-B69B0645; Mon, 10 Nov 2014 13:11:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415625065!12396417!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25609 invoked from network); 10 Nov 2014 13:11:06 -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;
	10 Nov 2014 13:11:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191168853"
Message-ID: <1415625050.25176.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 10 Nov 2014 13:10:50 +0000
In-Reply-To: <21596.44427.832657.366011@mariner.uk.xensource.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
	<21595.24771.302806.319751@mariner.uk.xensource.com>
	<1415353248.2030.5.camel@citrix.com>
	<21596.44427.832657.366011@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-07 at 11:31 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> > On Thu, 2014-11-06 at 11:51 +0000, Ian Jackson wrote:
> > > My change to the host property in the osstest hostdb didn't have the
> > > intended effect (or, any relevant effect).  I'm fixing this but it
> > > will involve a change to osstest.
> > 
> > FYI judging from
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/31393/test-amd64-i386-pair/info.html
> > scape-moth (and presumably worm-moth) suffer from this issue too:
> 
> Hrm.  I have added the relevant host property to the moths too.  My
> osstest change got a push so results should soon start to include the
> `swiotlb=26422'.

Looks like things are still failing even with this? :-/

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 13:11:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnokQ-0004O0-GG; Mon, 10 Nov 2014 13:11:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnokO-0004Ns-Bt
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 13:11:08 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	A9/21-02953-B69B0645; Mon, 10 Nov 2014 13:11:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415625065!12396417!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25609 invoked from network); 10 Nov 2014 13:11:06 -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;
	10 Nov 2014 13:11:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,352,1413244800"; d="scan'208";a="191168853"
Message-ID: <1415625050.25176.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 10 Nov 2014 13:10:50 +0000
In-Reply-To: <21596.44427.832657.366011@mariner.uk.xensource.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
	<21595.24771.302806.319751@mariner.uk.xensource.com>
	<1415353248.2030.5.camel@citrix.com>
	<21596.44427.832657.366011@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-07 at 11:31 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> > On Thu, 2014-11-06 at 11:51 +0000, Ian Jackson wrote:
> > > My change to the host property in the osstest hostdb didn't have the
> > > intended effect (or, any relevant effect).  I'm fixing this but it
> > > will involve a change to osstest.
> > 
> > FYI judging from
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/31393/test-amd64-i386-pair/info.html
> > scape-moth (and presumably worm-moth) suffer from this issue too:
> 
> Hrm.  I have added the relevant host property to the moths too.  My
> osstest change got a push so results should soon start to include the
> `swiotlb=26422'.

Looks like things are still failing even with this? :-/

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 13:34:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnp6h-00052U-3H; Mon, 10 Nov 2014 13:34: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@citrix.com>) id 1Xnp6f-00052P-JX
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 13:34:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	31/66-09842-0DEB0645; Mon, 10 Nov 2014 13:34:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415626446!9282868!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7078 invoked from network); 10 Nov 2014 13:34:08 -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;
	10 Nov 2014 13:34:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189736336"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 08:33:59 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xnp6U-0006Ax-S9;
	Mon, 10 Nov 2014 13:33:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xnp6U-00071I-JK;
	Mon, 10 Nov 2014 13:33:58 +0000
Date: Mon, 10 Nov 2014 13:33:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31409-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31409: 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 31409 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31409/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31358
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31358

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  816f5bb1f0740be8355e1be6cc24edf09547d984
baseline version:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  David Scott <dave.scott@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>
  Martin Pohlack <mpohlack@amazon.de>
  Razvan Cojocaru <rcojocaru@bitdefender.com>
  Rob Hoes <rob.hoes@citrix.com>
  Roy Franz <roy.franz@linaro.org>
  Simon Rowe <simon.rowe@eu.citrix.com>
  Willy Tarreau <w@1wt.eu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=816f5bb1f0740be8355e1be6cc24edf09547d984
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 816f5bb1f0740be8355e1be6cc24edf09547d984
+ branch=xen-unstable
+ revision=816f5bb1f0740be8355e1be6cc24edf09547d984
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 816f5bb1f0740be8355e1be6cc24edf09547d984:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   5283b31..816f5bb  816f5bb1f0740be8355e1be6cc24edf09547d984 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 13:34:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnp6h-00052U-3H; Mon, 10 Nov 2014 13:34: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@citrix.com>) id 1Xnp6f-00052P-JX
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 13:34:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	31/66-09842-0DEB0645; Mon, 10 Nov 2014 13:34:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415626446!9282868!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7078 invoked from network); 10 Nov 2014 13:34:08 -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;
	10 Nov 2014 13:34:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189736336"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 08:33:59 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xnp6U-0006Ax-S9;
	Mon, 10 Nov 2014 13:33:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xnp6U-00071I-JK;
	Mon, 10 Nov 2014 13:33:58 +0000
Date: Mon, 10 Nov 2014 13:33:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31409-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31409: 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 31409 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31409/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31358
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31358

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  816f5bb1f0740be8355e1be6cc24edf09547d984
baseline version:
 xen                  5283b310e14884341f51be35253cdd59c4cb034c

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  David Scott <dave.scott@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Markus Hauschild <Markus.Hauschild@rz.uni-regensburg.de>
  Martin Pohlack <mpohlack@amazon.de>
  Razvan Cojocaru <rcojocaru@bitdefender.com>
  Rob Hoes <rob.hoes@citrix.com>
  Roy Franz <roy.franz@linaro.org>
  Simon Rowe <simon.rowe@eu.citrix.com>
  Willy Tarreau <w@1wt.eu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=816f5bb1f0740be8355e1be6cc24edf09547d984
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 816f5bb1f0740be8355e1be6cc24edf09547d984
+ branch=xen-unstable
+ revision=816f5bb1f0740be8355e1be6cc24edf09547d984
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 816f5bb1f0740be8355e1be6cc24edf09547d984:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   5283b31..816f5bb  816f5bb1f0740be8355e1be6cc24edf09547d984 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 13:35:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnp7v-00056Z-Hz; Mon, 10 Nov 2014 13:35:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christoffer.dall@linaro.org>) id 1Xnp7u-00056N-FA
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 13:35:26 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B3/24-02696-D1FB0645; Mon, 10 Nov 2014 13:35:25 +0000
X-Env-Sender: christoffer.dall@linaro.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415626523!12402465!1
X-Originating-IP: [209.85.223.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31209 invoked from network); 10 Nov 2014 13:35:24 -0000
Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com)
	(209.85.223.182)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 13:35:24 -0000
Received: by mail-ie0-f182.google.com with SMTP id rd18so9191808iec.27
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 05:35:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=H2MvJrCddSr3f5FxEkEQ38lK4pHX3X/ulwEHtJIgVG8=;
	b=YimDlCYZK0kqAWQyI2GpeA4Jyu1kSHTlkm+6vckLTxKXjVuNZaIoy2H67WB5dL1UbI
	sXacLyweEQoliWyb0EoRirK/DF3LjU77OwfNFTmP8tJrc38ZlXabgej/9hznJfJMJ5uA
	vOP2dosEcol0DaW4TSsAL6z1g4DfsUzXZkwSstGT25goAD1WzL/NdTDN0bisgDGc6oOj
	M5L8ysfuSXgywObVo8MuIB//2GO/+5Jh8FYXL2Q0jzzgQRFHwEUmCyOJYRidv9ulZ1Nc
	mUKbGuSLm3HyDJbxsAXv/IarrqgvOiu+TEqcM08LgjZsMNwC6/GUfLAKzGyJryBWNAhB
	/i0Q==
X-Gm-Message-State: ALoCoQnzyO0gJRfh/WvJ/LfsYrx2t4kq1bGFM1QJe3Yng1+7IZZ5KZIobimeEemVe/VUlvIjo/SJ
MIME-Version: 1.0
X-Received: by 10.43.158.197 with SMTP id lv5mr1711567icc.88.1415626523409;
	Mon, 10 Nov 2014 05:35:23 -0800 (PST)
Received: by 10.64.134.195 with HTTP; Mon, 10 Nov 2014 05:35:23 -0800 (PST)
In-Reply-To: <1415619271.28370.6.camel@citrix.com>
References: <545B6E2B.9030303@linaro.org> <1415619271.28370.6.camel@citrix.com>
Date: Mon, 10 Nov 2014 14:35:23 +0100
Message-ID: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Julien Grall <julien.grall@linaro.org>, Will Deacon <will.deacon@arm.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: Bootwrapper update to support PSCI and
	GICv3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 12:34 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2014-11-06 at 12:48 +0000, Julien Grall wrote:
>> Hello all,
>>
>> I've been working on updating our aarch64 bootwrapper
>> to support new feature such as PSCI and GICv3.
>>
>> Rather than porting the feature from the Linux bootwrapper [1].
>> I've added support of Xen on top of the Linux repo.
>>
>> Below an example to configure bootwrapper with GICv3 and PSCI for
>> the foundation model:
>>
>> 42sh> ./configure --host=aarch64-linux-gnu            \
>> --with-kernel-dir=$HOME/linux-build/aarch64   \
>> --with-dtb=$HOME/arm-trusted-firmware/fdts/fvp-foundation-gicv3-psci.dtb \
>> --with-cmdline="console=hvc0 earlycon=pl011,0x1c090000 init=/root/init.sh root=/dev/vda" \
>> --enable-psci --with-xen-cmdline="dtuart=serial0 console=dtuart no-bootscrub"          \
>> --with-xen="$HOME/xen" --enable-gicv3
>> 42sh> make
>>
>> Make will produce a xen-system.axf which is the image used to boot
>> Xen on the model.
>>
>> The branch with the new version is:
>> git://xenbits.xen.org/people/julieng/boot-wrapper-aarch64.git branch xen
>>
>> Ian, can you update your repo with this new version?
>
> FWIW I've been happily using
> https://git.linaro.org/people/christoffer.dall/boot-wrapper-aarch64.git/shortlog/refs/heads/xen-psci-support at 7e702c7892d0965f459a61d36e4c8f1a9d6ee6df plus the following fixup (which I've been remiss in not sending out).

can you send this to me as a proper patch, then I'll include it in my
tree and test this out and send a patch set upstream?

>
> Given that we are now in a state where the patches appear to be nicely
> in keeping with the wrapper's architecture and therefore potentially
> upstreamable I'd like to at least have that conversation with the
> maintainers (probably via a patch set submission) before we carry on
> with a fork.
>
Agreed.

-Christoffer

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 13:35:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnp7v-00056Z-Hz; Mon, 10 Nov 2014 13:35:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christoffer.dall@linaro.org>) id 1Xnp7u-00056N-FA
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 13:35:26 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B3/24-02696-D1FB0645; Mon, 10 Nov 2014 13:35:25 +0000
X-Env-Sender: christoffer.dall@linaro.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415626523!12402465!1
X-Originating-IP: [209.85.223.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31209 invoked from network); 10 Nov 2014 13:35:24 -0000
Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com)
	(209.85.223.182)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 13:35:24 -0000
Received: by mail-ie0-f182.google.com with SMTP id rd18so9191808iec.27
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 05:35:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=H2MvJrCddSr3f5FxEkEQ38lK4pHX3X/ulwEHtJIgVG8=;
	b=YimDlCYZK0kqAWQyI2GpeA4Jyu1kSHTlkm+6vckLTxKXjVuNZaIoy2H67WB5dL1UbI
	sXacLyweEQoliWyb0EoRirK/DF3LjU77OwfNFTmP8tJrc38ZlXabgej/9hznJfJMJ5uA
	vOP2dosEcol0DaW4TSsAL6z1g4DfsUzXZkwSstGT25goAD1WzL/NdTDN0bisgDGc6oOj
	M5L8ysfuSXgywObVo8MuIB//2GO/+5Jh8FYXL2Q0jzzgQRFHwEUmCyOJYRidv9ulZ1Nc
	mUKbGuSLm3HyDJbxsAXv/IarrqgvOiu+TEqcM08LgjZsMNwC6/GUfLAKzGyJryBWNAhB
	/i0Q==
X-Gm-Message-State: ALoCoQnzyO0gJRfh/WvJ/LfsYrx2t4kq1bGFM1QJe3Yng1+7IZZ5KZIobimeEemVe/VUlvIjo/SJ
MIME-Version: 1.0
X-Received: by 10.43.158.197 with SMTP id lv5mr1711567icc.88.1415626523409;
	Mon, 10 Nov 2014 05:35:23 -0800 (PST)
Received: by 10.64.134.195 with HTTP; Mon, 10 Nov 2014 05:35:23 -0800 (PST)
In-Reply-To: <1415619271.28370.6.camel@citrix.com>
References: <545B6E2B.9030303@linaro.org> <1415619271.28370.6.camel@citrix.com>
Date: Mon, 10 Nov 2014 14:35:23 +0100
Message-ID: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Julien Grall <julien.grall@linaro.org>, Will Deacon <will.deacon@arm.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: Bootwrapper update to support PSCI and
	GICv3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 12:34 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2014-11-06 at 12:48 +0000, Julien Grall wrote:
>> Hello all,
>>
>> I've been working on updating our aarch64 bootwrapper
>> to support new feature such as PSCI and GICv3.
>>
>> Rather than porting the feature from the Linux bootwrapper [1].
>> I've added support of Xen on top of the Linux repo.
>>
>> Below an example to configure bootwrapper with GICv3 and PSCI for
>> the foundation model:
>>
>> 42sh> ./configure --host=aarch64-linux-gnu            \
>> --with-kernel-dir=$HOME/linux-build/aarch64   \
>> --with-dtb=$HOME/arm-trusted-firmware/fdts/fvp-foundation-gicv3-psci.dtb \
>> --with-cmdline="console=hvc0 earlycon=pl011,0x1c090000 init=/root/init.sh root=/dev/vda" \
>> --enable-psci --with-xen-cmdline="dtuart=serial0 console=dtuart no-bootscrub"          \
>> --with-xen="$HOME/xen" --enable-gicv3
>> 42sh> make
>>
>> Make will produce a xen-system.axf which is the image used to boot
>> Xen on the model.
>>
>> The branch with the new version is:
>> git://xenbits.xen.org/people/julieng/boot-wrapper-aarch64.git branch xen
>>
>> Ian, can you update your repo with this new version?
>
> FWIW I've been happily using
> https://git.linaro.org/people/christoffer.dall/boot-wrapper-aarch64.git/shortlog/refs/heads/xen-psci-support at 7e702c7892d0965f459a61d36e4c8f1a9d6ee6df plus the following fixup (which I've been remiss in not sending out).

can you send this to me as a proper patch, then I'll include it in my
tree and test this out and send a patch set upstream?

>
> Given that we are now in a state where the patches appear to be nicely
> in keeping with the wrapper's architecture and therefore potentially
> upstreamable I'd like to at least have that conversation with the
> maintainers (probably via a patch set submission) before we carry on
> with a fork.
>
Agreed.

-Christoffer

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 13:43:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:43:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnpFi-0005N9-Ru; Mon, 10 Nov 2014 13:43:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnpFi-0005N4-7o
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 13:43:30 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	25/B9-24124-101C0645; Mon, 10 Nov 2014 13:43:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415627007!11531788!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28703 invoked from network); 10 Nov 2014 13:43:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 13:43:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189738869"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 08:43:10 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnpFO-0005dS-6E;
	Mon, 10 Nov 2014 13:43:10 +0000
Date: Mon, 10 Nov 2014 13:43:10 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141110134310.GA32371@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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

To summarise this discussion so far.

Conceptually speaking, the guest should not need to know the mapping.
The translation from vnode to pnode should happen in hypervisor without
guest knowing.

Jan, Dario and David (and I) are all in favor of *not* exposing the
mapping (though starting from different angle). So we should go with
this approach. The hypercall interface is fine as it is now.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 13:43:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:43:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnpFi-0005N9-Ru; Mon, 10 Nov 2014 13:43:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnpFi-0005N4-7o
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 13:43:30 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	25/B9-24124-101C0645; Mon, 10 Nov 2014 13:43:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415627007!11531788!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28703 invoked from network); 10 Nov 2014 13:43:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 13:43:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189738869"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 08:43:10 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnpFO-0005dS-6E;
	Mon, 10 Nov 2014 13:43:10 +0000
Date: Mon, 10 Nov 2014 13:43:10 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141110134310.GA32371@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to 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

To summarise this discussion so far.

Conceptually speaking, the guest should not need to know the mapping.
The translation from vnode to pnode should happen in hypervisor without
guest knowing.

Jan, Dario and David (and I) are all in favor of *not* exposing the
mapping (though starting from different angle). So we should go with
this approach. The hypercall interface is fine as it is now.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 13:54:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnpQK-0005b8-8e; Mon, 10 Nov 2014 13:54:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnpQI-0005b3-Gs
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 13:54:26 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	DC/CD-14214-193C0645; Mon, 10 Nov 2014 13:54:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415627661!3964894!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9747 invoked from network); 10 Nov 2014 13:54:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 13:54:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189742283"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 08:54:20 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnpQC-0005uM-1X;
	Mon, 10 Nov 2014 13:54:20 +0000
Date: Mon, 10 Nov 2014 13:54:20 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141110135419.GB32371@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<1415623133.25176.10.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415623133.25176.10.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Zhigang Wang <zhigang.x.wang@oracle.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, Nov 10, 2014 at 12:38:53PM +0000, Ian Campbell wrote:
> On Mon, 2014-11-10 at 12:35 +0000, Wei Liu wrote:
> > On Fri, Nov 07, 2014 at 11:34:33AM -0500, Zhigang Wang wrote:
> > > On 11/07/2014 05:47 AM, Wei Liu wrote:
> > > > On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> > > >> Hi,
> > > >>
> > > >> While doing VM migration, in the destination side:
> > > >>
> > > >>    # xl list -l
> > > >>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
> > > >>     [
> > > >>         {
> > > >>             "domid": 0,
> > > >>             "config": {
> > > >>                 "c_info": {
> > > >>                     "type": "pv",
> > > >>                     "name": "Domain-0"
> > > >>                 },
> > > >>                 "b_info": {
> > > >>                     "max_memkb": 876544,
> > > >>                     "target_memkb": 876543,
> > > >>                     "sched_params": {
> > > >>     
> > > >>                     },
> > > >>                     "type.pv": {
> > > >>     
> > > >>                     }
> > > >>                 }
> > > >>             }
> > > >>         }
> > > >>     ]
> > > >>  
> > > >>     # xl list
> > > >>     Name                                          ID   Mem VCPUs      State   Time(s)
> > > >>     Domain-0                                       0   856     4     r-----    2758.9
> > > >>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> > > >>
> > > >> Testing on:
> > > >>
> > > > 
> > > > What's the rune you used to migrate the domain? xl migrate? Why is the
> > > > domain paused?
> > > 
> > > The domain is under migrating, so the destination side it's paused. When migration finish,
> > > it will become running.
> > > 
> > > FYI: the domain migration will success.
> > > 
> > 
> > I see. At that point the configuration was not available, yet. After the
> > domain is successfully migrated, the configuration should be available.
> > 
> > I think a domain under construction without domain configuration is a
> > valid state. What do you think?
> 
> Can we write a stub json file at the beginning of migrate receive, a bit
> like we do on create?
> 

No, we don't generate stub for normal domain at the moment.

Whether we should do it or not, it depends on whether we want libxl user
to see incomplete (and certainly incorrect) domain configuration. I
think not, because libxl user doesn't know how to distinguish stub
(invalid) configuration from a valid one.

> Otherwise code like xl list is going to have start special casing
> domains which have no json, which we've tried hard to avoid I think.
> 

>From xl's (and other tools on the same level) point of view, that means
invocation of library function fails, which it should always be ready to
cope with.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 13:54:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 13:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnpQK-0005b8-8e; Mon, 10 Nov 2014 13:54:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnpQI-0005b3-Gs
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 13:54:26 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	DC/CD-14214-193C0645; Mon, 10 Nov 2014 13:54:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415627661!3964894!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9747 invoked from network); 10 Nov 2014 13:54:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 13:54:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189742283"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 08:54:20 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnpQC-0005uM-1X;
	Mon, 10 Nov 2014 13:54:20 +0000
Date: Mon, 10 Nov 2014 13:54:20 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141110135419.GB32371@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<1415623133.25176.10.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415623133.25176.10.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Zhigang Wang <zhigang.x.wang@oracle.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, Nov 10, 2014 at 12:38:53PM +0000, Ian Campbell wrote:
> On Mon, 2014-11-10 at 12:35 +0000, Wei Liu wrote:
> > On Fri, Nov 07, 2014 at 11:34:33AM -0500, Zhigang Wang wrote:
> > > On 11/07/2014 05:47 AM, Wei Liu wrote:
> > > > On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> > > >> Hi,
> > > >>
> > > >> While doing VM migration, in the destination side:
> > > >>
> > > >>    # xl list -l
> > > >>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
> > > >>     [
> > > >>         {
> > > >>             "domid": 0,
> > > >>             "config": {
> > > >>                 "c_info": {
> > > >>                     "type": "pv",
> > > >>                     "name": "Domain-0"
> > > >>                 },
> > > >>                 "b_info": {
> > > >>                     "max_memkb": 876544,
> > > >>                     "target_memkb": 876543,
> > > >>                     "sched_params": {
> > > >>     
> > > >>                     },
> > > >>                     "type.pv": {
> > > >>     
> > > >>                     }
> > > >>                 }
> > > >>             }
> > > >>         }
> > > >>     ]
> > > >>  
> > > >>     # xl list
> > > >>     Name                                          ID   Mem VCPUs      State   Time(s)
> > > >>     Domain-0                                       0   856     4     r-----    2758.9
> > > >>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> > > >>
> > > >> Testing on:
> > > >>
> > > > 
> > > > What's the rune you used to migrate the domain? xl migrate? Why is the
> > > > domain paused?
> > > 
> > > The domain is under migrating, so the destination side it's paused. When migration finish,
> > > it will become running.
> > > 
> > > FYI: the domain migration will success.
> > > 
> > 
> > I see. At that point the configuration was not available, yet. After the
> > domain is successfully migrated, the configuration should be available.
> > 
> > I think a domain under construction without domain configuration is a
> > valid state. What do you think?
> 
> Can we write a stub json file at the beginning of migrate receive, a bit
> like we do on create?
> 

No, we don't generate stub for normal domain at the moment.

Whether we should do it or not, it depends on whether we want libxl user
to see incomplete (and certainly incorrect) domain configuration. I
think not, because libxl user doesn't know how to distinguish stub
(invalid) configuration from a valid one.

> Otherwise code like xl list is going to have start special casing
> domains which have no json, which we've tried hard to avoid I think.
> 

>From xl's (and other tools on the same level) point of view, that means
invocation of library function fails, which it should always be ready to
cope with.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:01:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:01:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnpWb-0005pi-CI; Mon, 10 Nov 2014 14:00:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnpWa-0005pd-0C
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:00:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CA/9C-24532-715C0645; Mon, 10 Nov 2014 14:00:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415628053!12394365!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3424 invoked from network); 10 Nov 2014 14:00:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:00:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189744280"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:00:53 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnpWW-00065G-Po;
	Mon, 10 Nov 2014 14:00:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnpWW-00032p-GK;
	Mon, 10 Nov 2014 14:00:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21600.50452.180179.809803@mariner.uk.xensource.com>
Date: Mon, 10 Nov 2014 14:00:52 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415625050.25176.16.camel@citrix.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
	<21595.24771.302806.319751@mariner.uk.xensource.com>
	<1415353248.2030.5.camel@citrix.com>
	<21596.44427.832657.366011@mariner.uk.xensource.com>
	<1415625050.25176.16.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> On Fri, 2014-11-07 at 11:31 +0000, Ian Jackson wrote:
> > Hrm.  I have added the relevant host property to the moths too.  My
> > osstest change got a push so results should soon start to include the
> > `swiotlb=26422'.
> 
> Looks like things are still failing even with this? :-/

>From serial-worm-moth.log:

Nov  5 14:10:40.550597 [    0.000000] Kernel command line: placeholder
root=/dev/mapper/worm--moth-root ro BOOTIF=01-78-2b-cb-73-42-c2
console=hvc0^M

Nov  5 14:10:40.578640 [    0.000000] software IO TLB [mem
0x1ba93000-0x1fa93000] (64MB) mapped at [dba93000-dfa92fff]^M

So the workaround still hasn't taken.  This is because we hadn't had a
push of osstest at the time that report was made.  Looking at the
database the first non-osstest-self-pushgate flight with the new
osstest was 31432.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:01:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:01:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnpWb-0005pi-CI; Mon, 10 Nov 2014 14:00:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnpWa-0005pd-0C
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:00:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CA/9C-24532-715C0645; Mon, 10 Nov 2014 14:00:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415628053!12394365!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3424 invoked from network); 10 Nov 2014 14:00:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:00:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189744280"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:00:53 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnpWW-00065G-Po;
	Mon, 10 Nov 2014 14:00:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnpWW-00032p-GK;
	Mon, 10 Nov 2014 14:00:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21600.50452.180179.809803@mariner.uk.xensource.com>
Date: Mon, 10 Nov 2014 14:00:52 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415625050.25176.16.camel@citrix.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
	<21595.24771.302806.319751@mariner.uk.xensource.com>
	<1415353248.2030.5.camel@citrix.com>
	<21596.44427.832657.366011@mariner.uk.xensource.com>
	<1415625050.25176.16.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> On Fri, 2014-11-07 at 11:31 +0000, Ian Jackson wrote:
> > Hrm.  I have added the relevant host property to the moths too.  My
> > osstest change got a push so results should soon start to include the
> > `swiotlb=26422'.
> 
> Looks like things are still failing even with this? :-/

>From serial-worm-moth.log:

Nov  5 14:10:40.550597 [    0.000000] Kernel command line: placeholder
root=/dev/mapper/worm--moth-root ro BOOTIF=01-78-2b-cb-73-42-c2
console=hvc0^M

Nov  5 14:10:40.578640 [    0.000000] software IO TLB [mem
0x1ba93000-0x1fa93000] (64MB) mapped at [dba93000-dfa92fff]^M

So the workaround still hasn't taken.  This is because we hadn't had a
push of osstest at the time that report was made.  Looking at the
database the first non-osstest-self-pushgate flight with the new
osstest was 31432.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:06:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:06:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnpbp-00061R-78; Mon, 10 Nov 2014 14:06:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xnpbn-00061M-Uk
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:06:20 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	0B/2A-14214-B56C0645; Mon, 10 Nov 2014 14:06:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415628376!11538659!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32373 invoked from network); 10 Nov 2014 14:06:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:06:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191186128"
Message-ID: <1415628349.25176.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 14:05:49 +0000
In-Reply-To: <20141110135419.GB32371@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<1415623133.25176.10.camel@citrix.com>
	<20141110135419.GB32371@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, 2014-11-10 at 13:54 +0000, Wei Liu wrote:
> > Can we write a stub json file at the beginning of migrate receive, a bit
> > like we do on create?
> > 
> 
> No, we don't generate stub for normal domain at the moment.

Oh, I thought we did.

SO what happens if someone runs "xl list" while a domain create is in
progress? 

> Whether we should do it or not, it depends on whether we want libxl user
> to see incomplete (and certainly incorrect) domain configuration. I
> think not, because libxl user doesn't know how to distinguish stub
> (invalid) configuration from a valid one.
> 
> > Otherwise code like xl list is going to have start special casing
> > domains which have no json, which we've tried hard to avoid I think.
> > 
> 
> From xl's (and other tools on the same level) point of view, that means
> invocation of library function fails, which it should always be ready to
> cope with.

So your opinion is that the bug is the "libxl: error:
libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain
configuration for domain 7" message which should be removed?

I'd be happy enough with domain 7 being listed with an empty cfg in that
case.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:06:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:06:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnpbp-00061R-78; Mon, 10 Nov 2014 14:06:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xnpbn-00061M-Uk
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:06:20 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	0B/2A-14214-B56C0645; Mon, 10 Nov 2014 14:06:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415628376!11538659!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32373 invoked from network); 10 Nov 2014 14:06:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:06:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191186128"
Message-ID: <1415628349.25176.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 14:05:49 +0000
In-Reply-To: <20141110135419.GB32371@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<1415623133.25176.10.camel@citrix.com>
	<20141110135419.GB32371@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, 2014-11-10 at 13:54 +0000, Wei Liu wrote:
> > Can we write a stub json file at the beginning of migrate receive, a bit
> > like we do on create?
> > 
> 
> No, we don't generate stub for normal domain at the moment.

Oh, I thought we did.

SO what happens if someone runs "xl list" while a domain create is in
progress? 

> Whether we should do it or not, it depends on whether we want libxl user
> to see incomplete (and certainly incorrect) domain configuration. I
> think not, because libxl user doesn't know how to distinguish stub
> (invalid) configuration from a valid one.
> 
> > Otherwise code like xl list is going to have start special casing
> > domains which have no json, which we've tried hard to avoid I think.
> > 
> 
> From xl's (and other tools on the same level) point of view, that means
> invocation of library function fails, which it should always be ready to
> cope with.

So your opinion is that the bug is the "libxl: error:
libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain
configuration for domain 7" message which should be removed?

I'd be happy enough with domain 7 being listed with an empty cfg in that
case.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:08:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14: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 1Xnpdw-00067i-PP; Mon, 10 Nov 2014 14:08:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xnpdv-00067b-6j
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:08:31 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	A3/46-22819-ED6C0645; Mon, 10 Nov 2014 14:08:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415628508!6253414!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25836 invoked from network); 10 Nov 2014 14:08:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:08:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191187098"
Message-ID: <1415628506.25176.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 10 Nov 2014 14:08:26 +0000
In-Reply-To: <21600.50452.180179.809803@mariner.uk.xensource.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
	<21595.24771.302806.319751@mariner.uk.xensource.com>
	<1415353248.2030.5.camel@citrix.com>
	<21596.44427.832657.366011@mariner.uk.xensource.com>
	<1415625050.25176.16.camel@citrix.com>
	<21600.50452.180179.809803@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 14:00 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> > On Fri, 2014-11-07 at 11:31 +0000, Ian Jackson wrote:
> > > Hrm.  I have added the relevant host property to the moths too.  My
> > > osstest change got a push so results should soon start to include the
> > > `swiotlb=26422'.
> > 
> > Looks like things are still failing even with this? :-/
> 
> From serial-worm-moth.log:
> 
> Nov  5 14:10:40.550597 [    0.000000] Kernel command line: placeholder
> root=/dev/mapper/worm--moth-root ro BOOTIF=01-78-2b-cb-73-42-c2
> console=hvc0^M
> 
> Nov  5 14:10:40.578640 [    0.000000] software IO TLB [mem
> 0x1ba93000-0x1fa93000] (64MB) mapped at [dba93000-dfa92fff]^M
> 
> So the workaround still hasn't taken.  This is because we hadn't had a
> push of osstest at the time that report was made.  Looking at the
> database the first non-osstest-self-pushgate flight with the new
> osstest was 31432.

http://www.chiark.greenend.org.uk/~xensrcts/logs/31458/test-amd64-i386-pair/info.html seems to have the swiotlb= and has failed with
Nov 10 04:12:11.050621 [  985.934464] sd 4:1:0:0: pci_map_sg failed: request for 4096 bytes!
Nov 10 04:12:11.050678 [  985.952455] mpt2sas 0000:05:00.0: swiotlb buffer is full

on scape-moth.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:08:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14: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 1Xnpdw-00067i-PP; Mon, 10 Nov 2014 14:08:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xnpdv-00067b-6j
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:08:31 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	A3/46-22819-ED6C0645; Mon, 10 Nov 2014 14:08:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415628508!6253414!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25836 invoked from network); 10 Nov 2014 14:08:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:08:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191187098"
Message-ID: <1415628506.25176.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 10 Nov 2014 14:08:26 +0000
In-Reply-To: <21600.50452.180179.809803@mariner.uk.xensource.com>
References: <osstest-31385-mainreport@xen.org>
	<545B6A2002000078000454EC@mail.emea.novell.com>
	<21595.24771.302806.319751@mariner.uk.xensource.com>
	<1415353248.2030.5.camel@citrix.com>
	<21596.44427.832657.366011@mariner.uk.xensource.com>
	<1415625050.25176.16.camel@citrix.com>
	<21600.50452.180179.809803@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 14:00 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-4.2-testing test] 31385: regressions - FAIL"):
> > On Fri, 2014-11-07 at 11:31 +0000, Ian Jackson wrote:
> > > Hrm.  I have added the relevant host property to the moths too.  My
> > > osstest change got a push so results should soon start to include the
> > > `swiotlb=26422'.
> > 
> > Looks like things are still failing even with this? :-/
> 
> From serial-worm-moth.log:
> 
> Nov  5 14:10:40.550597 [    0.000000] Kernel command line: placeholder
> root=/dev/mapper/worm--moth-root ro BOOTIF=01-78-2b-cb-73-42-c2
> console=hvc0^M
> 
> Nov  5 14:10:40.578640 [    0.000000] software IO TLB [mem
> 0x1ba93000-0x1fa93000] (64MB) mapped at [dba93000-dfa92fff]^M
> 
> So the workaround still hasn't taken.  This is because we hadn't had a
> push of osstest at the time that report was made.  Looking at the
> database the first non-osstest-self-pushgate flight with the new
> osstest was 31432.

http://www.chiark.greenend.org.uk/~xensrcts/logs/31458/test-amd64-i386-pair/info.html seems to have the swiotlb= and has failed with
Nov 10 04:12:11.050621 [  985.934464] sd 4:1:0:0: pci_map_sg failed: request for 4096 bytes!
Nov 10 04:12:11.050678 [  985.952455] mpt2sas 0000:05:00.0: swiotlb buffer is full

on scape-moth.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:10:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14: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 1XnpfT-0006FA-9h; Mon, 10 Nov 2014 14:10:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnpfR-0006Ew-Qx
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:10:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AD/84-09936-D37C0645; Mon, 10 Nov 2014 14:10:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415628603!12768613!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14300 invoked from network); 10 Nov 2014 14:10:04 -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;
	10 Nov 2014 14:10:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189748031"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:10:02 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XnpfN-0006Ju-HX;
	Mon, 10 Nov 2014 14:10:02 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Mon, 10 Nov
	2014 14:10:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 10 Nov 2014 14:09:58 +0000
Message-ID: <1415628601-31075-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/4] xen: Correction to module@1 (dom0 kernel)
	DT 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

- Include bootargs (kernel command line) property.
- Update reg property to match #address-cells and #size-cells in the DTB (both
  2).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Makefile.am |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 9b6c7e3..ed5acbb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -69,8 +69,9 @@ XEN_OFFSET	:= 0xA00000
 DOM0_OFFSET	:= $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
 XEN_BOOTARGS	:= xen,xen-bootargs = \"$(BOOTARGS)\";			\
 		   module@1 {						\
+			bootargs = \"$(CMDLINE)\";			\
 			compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
-			reg = <$(DOM0_OFFSET) 0x800000>;		\
+			reg = <0 $(DOM0_OFFSET) 0 0x800000>;		\
 		   };
 endif
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:10:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14: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 1XnpfV-0006Fo-0x; Mon, 10 Nov 2014 14:10:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnpfT-0006FJ-VX
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:10:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4E/54-24532-F37C0645; Mon, 10 Nov 2014 14:10:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415628603!12768613!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14800 invoked from network); 10 Nov 2014 14:10:06 -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;
	10 Nov 2014 14:10:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189748048"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:10:06 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XnpfQ-0006K2-Kp;
	Mon, 10 Nov 2014 14:10:05 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Mon, 10 Nov
	2014 14:10:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 10 Nov 2014 14:10:01 +0000
Message-ID: <1415628601-31075-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/4] xen: Disable boot scrub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 (really!) slow on models and the security concerns don't really
apply.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 configure.ac |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index d292f4d..44b3bf0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -82,7 +82,7 @@ AC_ARG_WITH([cmdline],
 	[C_CMDLINE=$withval])
 AC_SUBST([CMDLINE], [$C_CMDLINE])
 
-X_BOOTARGS="console=dtuart dtuart=serial0"
+X_BOOTARGS="console=dtuart dtuart=serial0 no-bootscrub"
 AC_ARG_WITH([xen-bootargs],
 	AS_HELP_STRING([--with-xen-bootargs], [set Xen bootargs]),
 	[X_BOOTARGS=$withval])
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:10:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14: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 1XnpfV-0006G7-D1; Mon, 10 Nov 2014 14:10:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnpfV-0006Fj-0N
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:10:09 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	4F/B4-26740-047C0645; Mon, 10 Nov 2014 14:10:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415628606!11619188!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32462 invoked from network); 10 Nov 2014 14:10:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:10:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191187511"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:10:04 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XnpfP-0006Jz-Js;
	Mon, 10 Nov 2014 14:10:04 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Mon, 10 Nov
	2014 14:10:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 10 Nov 2014 14:10:00 +0000
Message-ID: <1415628601-31075-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/4] Select correct dom0 console depending on
	whether Xen is enabled or not
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 configure.ac |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 2f31fab..d292f4d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -75,7 +75,8 @@ AC_ARG_WITH([initrd],
 AC_SUBST([FILESYSTEM], [$USE_INITRD])
 AM_CONDITIONAL([INITRD], [test "x$USE_INITRD" != "x"])
 
-C_CMDLINE="console=ttyAMA0 earlyprintk=pl011,0x1c090000"
+AS_IF([test "x$XEN_IMAGE" = "no"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
+C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c090000"
 AC_ARG_WITH([cmdline],
 	AS_HELP_STRING([--with-cmdline], [set a command line for the kernel]),
 	[C_CMDLINE=$withval])
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:10:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14: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 1XnpfT-0006FM-L6; Mon, 10 Nov 2014 14:10:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnpfS-0006Ez-Ik
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:10:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C8/B1-09842-D37C0645; Mon, 10 Nov 2014 14:10:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415628603!12768613!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14437 invoked from network); 10 Nov 2014 14:10:05 -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;
	10 Nov 2014 14:10:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189748038"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:10:03 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XnpfO-0006Jw-IZ;
	Mon, 10 Nov 2014 14:10:03 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Mon, 10 Nov
	2014 14:10:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 10 Nov 2014 14:09:59 +0000
Message-ID: <1415628601-31075-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/4] Fix build when Xen is not enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If Xen isn't enabled then XEN_IMAGE ends up as "no.o", which obviously doesn't
exist. Handle the dependency explicitly.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Makefile.am |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index ed5acbb..6c2786e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -98,7 +98,10 @@ all: $(IMAGE) $(XIMAGE)
 
 CLEANFILES = $(IMAGE) boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb
 
-$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
+if XEN
+XEN_IMAGE_DEP = $(XEN_IMAGE)
+endif
+$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE_DEP)
 	$(LD) -o $@ --script=model.lds
 
 %.o: %.S Makefile
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:10:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14: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 1XnpfT-0006FA-9h; Mon, 10 Nov 2014 14:10:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnpfR-0006Ew-Qx
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:10:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AD/84-09936-D37C0645; Mon, 10 Nov 2014 14:10:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415628603!12768613!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14300 invoked from network); 10 Nov 2014 14:10:04 -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;
	10 Nov 2014 14:10:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189748031"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:10:02 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XnpfN-0006Ju-HX;
	Mon, 10 Nov 2014 14:10:02 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Mon, 10 Nov
	2014 14:10:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 10 Nov 2014 14:09:58 +0000
Message-ID: <1415628601-31075-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/4] xen: Correction to module@1 (dom0 kernel)
	DT 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

- Include bootargs (kernel command line) property.
- Update reg property to match #address-cells and #size-cells in the DTB (both
  2).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Makefile.am |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 9b6c7e3..ed5acbb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -69,8 +69,9 @@ XEN_OFFSET	:= 0xA00000
 DOM0_OFFSET	:= $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
 XEN_BOOTARGS	:= xen,xen-bootargs = \"$(BOOTARGS)\";			\
 		   module@1 {						\
+			bootargs = \"$(CMDLINE)\";			\
 			compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
-			reg = <$(DOM0_OFFSET) 0x800000>;		\
+			reg = <0 $(DOM0_OFFSET) 0 0x800000>;		\
 		   };
 endif
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:10:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14: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 1XnpfV-0006G7-D1; Mon, 10 Nov 2014 14:10:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnpfV-0006Fj-0N
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:10:09 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	4F/B4-26740-047C0645; Mon, 10 Nov 2014 14:10:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415628606!11619188!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32462 invoked from network); 10 Nov 2014 14:10:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:10:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191187511"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:10:04 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XnpfP-0006Jz-Js;
	Mon, 10 Nov 2014 14:10:04 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Mon, 10 Nov
	2014 14:10:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 10 Nov 2014 14:10:00 +0000
Message-ID: <1415628601-31075-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/4] Select correct dom0 console depending on
	whether Xen is enabled or not
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 configure.ac |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 2f31fab..d292f4d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -75,7 +75,8 @@ AC_ARG_WITH([initrd],
 AC_SUBST([FILESYSTEM], [$USE_INITRD])
 AM_CONDITIONAL([INITRD], [test "x$USE_INITRD" != "x"])
 
-C_CMDLINE="console=ttyAMA0 earlyprintk=pl011,0x1c090000"
+AS_IF([test "x$XEN_IMAGE" = "no"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
+C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c090000"
 AC_ARG_WITH([cmdline],
 	AS_HELP_STRING([--with-cmdline], [set a command line for the kernel]),
 	[C_CMDLINE=$withval])
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:10:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14: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 1XnpfV-0006Fo-0x; Mon, 10 Nov 2014 14:10:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnpfT-0006FJ-VX
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:10:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4E/54-24532-F37C0645; Mon, 10 Nov 2014 14:10:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415628603!12768613!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14800 invoked from network); 10 Nov 2014 14:10:06 -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;
	10 Nov 2014 14:10:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189748048"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:10:06 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XnpfQ-0006K2-Kp;
	Mon, 10 Nov 2014 14:10:05 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Mon, 10 Nov
	2014 14:10:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 10 Nov 2014 14:10:01 +0000
Message-ID: <1415628601-31075-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/4] xen: Disable boot scrub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 (really!) slow on models and the security concerns don't really
apply.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 configure.ac |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index d292f4d..44b3bf0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -82,7 +82,7 @@ AC_ARG_WITH([cmdline],
 	[C_CMDLINE=$withval])
 AC_SUBST([CMDLINE], [$C_CMDLINE])
 
-X_BOOTARGS="console=dtuart dtuart=serial0"
+X_BOOTARGS="console=dtuart dtuart=serial0 no-bootscrub"
 AC_ARG_WITH([xen-bootargs],
 	AS_HELP_STRING([--with-xen-bootargs], [set Xen bootargs]),
 	[X_BOOTARGS=$withval])
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:10:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14: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 1XnpfT-0006FM-L6; Mon, 10 Nov 2014 14:10:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnpfS-0006Ez-Ik
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:10:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C8/B1-09842-D37C0645; Mon, 10 Nov 2014 14:10:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415628603!12768613!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14437 invoked from network); 10 Nov 2014 14:10:05 -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;
	10 Nov 2014 14:10:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189748038"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:10:03 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XnpfO-0006Jw-IZ;
	Mon, 10 Nov 2014 14:10:03 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Mon, 10 Nov
	2014 14:10:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 10 Nov 2014 14:09:59 +0000
Message-ID: <1415628601-31075-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/4] Fix build when Xen is not enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If Xen isn't enabled then XEN_IMAGE ends up as "no.o", which obviously doesn't
exist. Handle the dependency explicitly.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Makefile.am |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index ed5acbb..6c2786e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -98,7 +98,10 @@ all: $(IMAGE) $(XIMAGE)
 
 CLEANFILES = $(IMAGE) boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb
 
-$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
+if XEN
+XEN_IMAGE_DEP = $(XEN_IMAGE)
+endif
+$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE_DEP)
 	$(LD) -o $@ --script=model.lds
 
 %.o: %.S Makefile
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:10:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnpgC-0006Ub-AO; Mon, 10 Nov 2014 14:10:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnpgB-0006Tx-54
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:10:51 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	39/D8-03148-A67C0645; Mon, 10 Nov 2014 14:10:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415628648!7095744!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19497 invoked from network); 10 Nov 2014 14:10:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:10:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189748322"
Message-ID: <1415628645.25176.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 10 Nov 2014 14:10:45 +0000
In-Reply-To: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
References: <545B6E2B.9030303@linaro.org> <1415619271.28370.6.camel@citrix.com>
	<CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Mark Rutland <mark.rutland@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Julien Grall <julien.grall@linaro.org>, Will Deacon <will.deacon@arm.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: Bootwrapper update to support PSCI and
	GICv3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 14:35 +0100, Christoffer Dall wrote:

> can you send this to me as a proper patch, then I'll include it in my
> tree and test this out and send a patch set upstream?

I've just invoked git send-email, resulting in 4 patches.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:10:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnpgC-0006Ub-AO; Mon, 10 Nov 2014 14:10:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnpgB-0006Tx-54
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:10:51 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	39/D8-03148-A67C0645; Mon, 10 Nov 2014 14:10:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415628648!7095744!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19497 invoked from network); 10 Nov 2014 14:10:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:10:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189748322"
Message-ID: <1415628645.25176.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 10 Nov 2014 14:10:45 +0000
In-Reply-To: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
References: <545B6E2B.9030303@linaro.org> <1415619271.28370.6.camel@citrix.com>
	<CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Mark Rutland <mark.rutland@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Julien Grall <julien.grall@linaro.org>, Will Deacon <will.deacon@arm.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: Bootwrapper update to support PSCI and
	GICv3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 14:35 +0100, Christoffer Dall wrote:

> can you send this to me as a proper patch, then I'll include it in my
> tree and test this out and send a patch set upstream?

I've just invoked git send-email, resulting in 4 patches.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:13:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnpit-0006wk-0u; Mon, 10 Nov 2014 14:13:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xnpir-0006wZ-Ex
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 14:13:37 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	AF/29-27785-018C0645; Mon, 10 Nov 2014 14:13:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415628814!12501875!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23002 invoked from network); 10 Nov 2014 14:13:35 -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;
	10 Nov 2014 14:13:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189749029"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 09:13:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnpiG-0006MQ-U0;
	Mon, 10 Nov 2014 14:13:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnpiG-0005oP-Mn;
	Mon, 10 Nov 2014 14:13:00 +0000
Date: Mon, 10 Nov 2014 14:13:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31465-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8829
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31465: 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: multipart/mixed; boundary="===============0405517560504920129=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0405517560504920129==
Content-Type: text/plain
Content-Length: 8570
Content-Transfer-Encoding: quoted-printable

flight 31465 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31465/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              0396394f027edb5fa70514a0d11fa62ea7281bd9
baseline version:
 libvirt              4480cd28371ca328ed5561f3532f82d8cbc9f34d

------------------------------------------------------------
People who touched revisions under test:
  Anton Blanchard <anton@samba.org>
  Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  C=C3=A9dric Bosdonnat <cbosdonnat@suse.com>
  Daniel P. Berrange <berrange@redhat.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Hao Liu <hliu@redhat.com>
  Jiri Denemark <jdenemar@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Li Zhang <zhlcindy@linux.vnet.ibm.com>
  Luyao Huang <lhuang@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Matthias Bolte <matthias.bolte@googlemail.com>
  Michal Privoznik <mprivozn@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pradipta Kr. Banerjee <bpradip@in.ibm.com>
  Prerna Saxena <prerna@linux.vnet.ibm.com>
  Weiwei Li <nuonuoli@tencent.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3D0396394f027edb5fa70514a0d11fa62ea7281bd9
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 0396394f027edb5fa70514a0d11fa62ea7281bd9
+ branch=3Dlibvirt
+ revision=3D0396394f027edb5fa70514a0d11fa62ea7281bd9
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 0396394f027edb5fa70514a0d11fa62ea7281bd9:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   4480cd2..0396394  0396394f027edb5fa70514a0d11fa62ea7281bd9 -> xen-tested-master


--===============0405517560504920129==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0405517560504920129==--

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:13:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnpit-0006wk-0u; Mon, 10 Nov 2014 14:13:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xnpir-0006wZ-Ex
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 14:13:37 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	AF/29-27785-018C0645; Mon, 10 Nov 2014 14:13:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415628814!12501875!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23002 invoked from network); 10 Nov 2014 14:13:35 -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;
	10 Nov 2014 14:13:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189749029"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 09:13:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnpiG-0006MQ-U0;
	Mon, 10 Nov 2014 14:13:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnpiG-0005oP-Mn;
	Mon, 10 Nov 2014 14:13:00 +0000
Date: Mon, 10 Nov 2014 14:13:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31465-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8829
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31465: 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: multipart/mixed; boundary="===============0405517560504920129=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0405517560504920129==
Content-Type: text/plain
Content-Length: 8570
Content-Transfer-Encoding: quoted-printable

flight 31465 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31465/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              0396394f027edb5fa70514a0d11fa62ea7281bd9
baseline version:
 libvirt              4480cd28371ca328ed5561f3532f82d8cbc9f34d

------------------------------------------------------------
People who touched revisions under test:
  Anton Blanchard <anton@samba.org>
  Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  C=C3=A9dric Bosdonnat <cbosdonnat@suse.com>
  Daniel P. Berrange <berrange@redhat.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Hao Liu <hliu@redhat.com>
  Jiri Denemark <jdenemar@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Li Zhang <zhlcindy@linux.vnet.ibm.com>
  Luyao Huang <lhuang@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Matthias Bolte <matthias.bolte@googlemail.com>
  Michal Privoznik <mprivozn@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Pradipta Kr. Banerjee <bpradip@in.ibm.com>
  Prerna Saxena <prerna@linux.vnet.ibm.com>
  Weiwei Li <nuonuoli@tencent.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3D0396394f027edb5fa70514a0d11fa62ea7281bd9
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 0396394f027edb5fa70514a0d11fa62ea7281bd9
+ branch=3Dlibvirt
+ revision=3D0396394f027edb5fa70514a0d11fa62ea7281bd9
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 0396394f027edb5fa70514a0d11fa62ea7281bd9:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   4480cd2..0396394  0396394f027edb5fa70514a0d11fa62ea7281bd9 -> xen-tested-master


--===============0405517560504920129==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0405517560504920129==--

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:17:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:17:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnpm6-00078S-SD; Mon, 10 Nov 2014 14:16:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xnpm5-00078M-Dx
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:16:57 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B4/B6-02984-8D8C0645; Mon, 10 Nov 2014 14:16:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415629014!12489910!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28522 invoked from network); 10 Nov 2014 14:16:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:16:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191189819"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:16:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xnplz-0006Rv-Nr;
	Mon, 10 Nov 2014 14:16:51 +0000
Date: Mon, 10 Nov 2014 14:16:51 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141110141651.GC32371@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<1415623133.25176.10.camel@citrix.com>
	<20141110135419.GB32371@zion.uk.xensource.com>
	<1415628349.25176.19.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415628349.25176.19.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Zhigang Wang <zhigang.x.wang@oracle.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, Nov 10, 2014 at 02:05:49PM +0000, Ian Campbell wrote:
> On Mon, 2014-11-10 at 13:54 +0000, Wei Liu wrote:
> > > Can we write a stub json file at the beginning of migrate receive, a bit
> > > like we do on create?
> > > 
> > 
> > No, we don't generate stub for normal domain at the moment.
> 
> Oh, I thought we did.
> 

We only generate stub for Dom0.

> SO what happens if someone runs "xl list" while a domain create is in
> progress? 
> 

It works the same as before. The "short" list doesn't relies on
libxl_retrieve_domain_configuration.  Now it's only "xl list -l" doesn't
have output.

> > Whether we should do it or not, it depends on whether we want libxl user
> > to see incomplete (and certainly incorrect) domain configuration. I
> > think not, because libxl user doesn't know how to distinguish stub
> > (invalid) configuration from a valid one.
> > 
> > > Otherwise code like xl list is going to have start special casing
> > > domains which have no json, which we've tried hard to avoid I think.
> > > 
> > 
> > From xl's (and other tools on the same level) point of view, that means
> > invocation of library function fails, which it should always be ready to
> > cope with.
> 
> So your opinion is that the bug is the "libxl: error:
> libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain
> configuration for domain 7" message which should be removed?
> 

I think so. This error message is red-herring. The caller knows best
what to do with the error.

> I'd be happy enough with domain 7 being listed with an empty cfg in that
> case.
> 

OK.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:17:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:17:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnpm6-00078S-SD; Mon, 10 Nov 2014 14:16:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xnpm5-00078M-Dx
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:16:57 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B4/B6-02984-8D8C0645; Mon, 10 Nov 2014 14:16:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415629014!12489910!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28522 invoked from network); 10 Nov 2014 14:16:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:16:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191189819"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:16:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xnplz-0006Rv-Nr;
	Mon, 10 Nov 2014 14:16:51 +0000
Date: Mon, 10 Nov 2014 14:16:51 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141110141651.GC32371@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<1415623133.25176.10.camel@citrix.com>
	<20141110135419.GB32371@zion.uk.xensource.com>
	<1415628349.25176.19.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415628349.25176.19.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Zhigang Wang <zhigang.x.wang@oracle.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, Nov 10, 2014 at 02:05:49PM +0000, Ian Campbell wrote:
> On Mon, 2014-11-10 at 13:54 +0000, Wei Liu wrote:
> > > Can we write a stub json file at the beginning of migrate receive, a bit
> > > like we do on create?
> > > 
> > 
> > No, we don't generate stub for normal domain at the moment.
> 
> Oh, I thought we did.
> 

We only generate stub for Dom0.

> SO what happens if someone runs "xl list" while a domain create is in
> progress? 
> 

It works the same as before. The "short" list doesn't relies on
libxl_retrieve_domain_configuration.  Now it's only "xl list -l" doesn't
have output.

> > Whether we should do it or not, it depends on whether we want libxl user
> > to see incomplete (and certainly incorrect) domain configuration. I
> > think not, because libxl user doesn't know how to distinguish stub
> > (invalid) configuration from a valid one.
> > 
> > > Otherwise code like xl list is going to have start special casing
> > > domains which have no json, which we've tried hard to avoid I think.
> > > 
> > 
> > From xl's (and other tools on the same level) point of view, that means
> > invocation of library function fails, which it should always be ready to
> > cope with.
> 
> So your opinion is that the bug is the "libxl: error:
> libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain
> configuration for domain 7" message which should be removed?
> 

I think so. This error message is red-herring. The caller knows best
what to do with the error.

> I'd be happy enough with domain 7 being listed with an empty cfg in that
> case.
> 

OK.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:32:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnq0X-0007OB-JJ; Mon, 10 Nov 2014 14:31:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xnq0W-0007O6-4B
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:31:52 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	76/EC-19763-75CC0645; Mon, 10 Nov 2014 14:31:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415629909!7435998!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17731 invoked from network); 10 Nov 2014 14:31:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Nov 2014 14:31:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAEVe0a027964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 14:31:41 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAAEVdje023583
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Nov 2014 14:31:40 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAAEVcCT023266; Mon, 10 Nov 2014 14:31:38 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 06:31:38 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 729FA111F67; Mon, 10 Nov 2014 09:31:37 -0500 (EST)
Date: Mon, 10 Nov 2014 09:31:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Message-ID: <20141110143137.GC3783@laptop.dumpdata.com>
References: <54604CEA.1060909@cn.fujitsu.com>
	<alpine.DEB.2.02.1411101148300.22875@kaball.uk.xensource.com>
	<5460AB8C.40504@cn.fujitsu.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460AB8C.40504@cn.fujitsu.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 08:11:56PM +0800, Wen Congyang wrote:
> On 11/10/2014 07:50 PM, Stefano Stabellini wrote:
> > On Mon, 10 Nov 2014, Wen Congyang wrote:
> >> I disable xen-platform-pci in the config file, but when I start the guest, I found
> >> the following kernel message:
> >> [    0.000000] Booting paravirtualized kernel on Xen HVM
> >> [    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
> > 
> > You can pass xen_nopv to the kernel command line
> > 
> 
> Yes, but I don't use the newest kernel...

You can backport the patch. It is very small.
> 
> Thanks
> Wen Congyang
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 10 14:32:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnq0X-0007OB-JJ; Mon, 10 Nov 2014 14:31:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xnq0W-0007O6-4B
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:31:52 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	76/EC-19763-75CC0645; Mon, 10 Nov 2014 14:31:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415629909!7435998!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17731 invoked from network); 10 Nov 2014 14:31:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Nov 2014 14:31:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAEVe0a027964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 14:31:41 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAAEVdje023583
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Nov 2014 14:31:40 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAAEVcCT023266; Mon, 10 Nov 2014 14:31:38 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 06:31:38 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 729FA111F67; Mon, 10 Nov 2014 09:31:37 -0500 (EST)
Date: Mon, 10 Nov 2014 09:31:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Message-ID: <20141110143137.GC3783@laptop.dumpdata.com>
References: <54604CEA.1060909@cn.fujitsu.com>
	<alpine.DEB.2.02.1411101148300.22875@kaball.uk.xensource.com>
	<5460AB8C.40504@cn.fujitsu.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460AB8C.40504@cn.fujitsu.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] How to run a HVM guest without pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 08:11:56PM +0800, Wen Congyang wrote:
> On 11/10/2014 07:50 PM, Stefano Stabellini wrote:
> > On Mon, 10 Nov 2014, Wen Congyang wrote:
> >> I disable xen-platform-pci in the config file, but when I start the guest, I found
> >> the following kernel message:
> >> [    0.000000] Booting paravirtualized kernel on Xen HVM
> >> [    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
> > 
> > You can pass xen_nopv to the kernel command line
> > 
> 
> Yes, but I don't use the newest kernel...

You can backport the patch. It is very small.
> 
> Thanks
> Wen Congyang
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 10 14:35:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnq44-0007ZQ-8p; Mon, 10 Nov 2014 14:35:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <seth.forshee@canonical.com>) id 1Xnq42-0007ZK-Iq
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:35:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7A/13-24532-13DC0645; Mon, 10 Nov 2014 14:35:29 +0000
X-Env-Sender: seth.forshee@canonical.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415630128!4715564!1
X-Originating-IP: [209.85.218.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2842 invoked from network); 10 Nov 2014 14:35:29 -0000
Received: from mail-oi0-f47.google.com (HELO mail-oi0-f47.google.com)
	(209.85.218.47)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:35:29 -0000
Received: by mail-oi0-f47.google.com with SMTP id a3so5477299oib.34
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 06:35:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id
	:mail-followup-to:references:mime-version:content-type
	:content-disposition:in-reply-to:user-agent;
	bh=z9vgX9MmwXxEcIHkZP9U9tgSylnSNofvWvPHuSoMhAk=;
	b=bIp9j1zguD5Asv2FrZZ2IxjiHF1bOYUAUTkXvVdtLr4qtmrrchQ/EdCoJTZNSTmumR
	SnuJigZlgd4AzSvpVi4nyuS728TBJTJcoSqdNBJO6o5Pb1ZNNCID2R1Evj3Bk82LXITo
	WldvliEp7HBw+ch9SwU4PSSpUaukXw7eZbb4gIYI2PKAan+BDKQqSoNUVcT9NFSaja4e
	imn0sFFkp20yPI+9WHopLrC0ci0ATvE1/SwwSEC3WHQYztcwiYUpQ5/aWUqsB+37d+n8
	18SBdDXsZ5vTJiImq/FccqM+tC/WdvZcbVgdMjGaMRVQARyIDicAWjMcbGY9QQeQ7uiX
	1izw==
X-Gm-Message-State: ALoCoQmbW7Kk6W7oF2ZzqfRbj/z5JZSlmipSFBW7VX53F59++PfULIqWVBr6wj8/nvPEHIqrJQJg
X-Received: by 10.182.129.226 with SMTP id nz2mr26354896obb.5.1415630128145;
	Mon, 10 Nov 2014 06:35:28 -0800 (PST)
Received: from localhost (199-87-125-144.dyn.kc.surewest.net. [199.87.125.144])
	by mx.google.com with ESMTPSA id rm7sm6124551obc.14.2014.11.10.06.35.27
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Mon, 10 Nov 2014 06:35:27 -0800 (PST)
Date: Mon, 10 Nov 2014 08:35:17 -0600
From: Seth Forshee <seth.forshee@canonical.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141110143517.GA74005@ubuntu-hedt>
Mail-Followup-To: David Vrabel <david.vrabel@citrix.com>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20141106214940.GD44162@ubuntu-hedt> <545CA27F.4070400@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545CA27F.4070400@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Stefan Bader <stefan.bader@canonical.com>,
	seth.forshee@canonical.com, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 10:44:15AM +0000, David Vrabel wrote:
> On 06/11/14 21:49, Seth Forshee wrote:
> > We've had several reports of hitting the following BUG_ON in
> > xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
> > results of testing with 3.17):
> > 
> >         /* Grant backend access to each skb fragment page. */
> >         for (i = 0; i < frags; i++) {
> >                 skb_frag_t *frag = skb_shinfo(skb)->frags + i;
> >                 struct page *page = skb_frag_page(frag);
> > 
> >                 len = skb_frag_size(frag);
> >                 offset = frag->page_offset;
> > 
> >                 /* Data must not cross a page boundary. */
> >                 BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
> > 
> > When this happens the page in question is a "middle" page in a compound
> > page (i.e. it's a tail page but not the last tail page), and the data is
> > fully contained within the compound page. The data does however cross
> > the hardware page boundary, and since compound_order evaluates to 0 for
> > tail pages the check fails.
> > 
> > In going over this I've been unable to determine whether the BUG_ON in
> > xennet_make_frags is incorrect or the paged skb data is wrong. I can't
> > find that it's documented anywhere, and the networking code itself is a
> > bit ambiguous when it comes to compound pages. On the one hand
> > __skb_fill_page_desc specifically handles adding tail pages as paged
> > data, but on the other hand skb_copy_bits kmaps frag->page.p which could
> > fail with data that extends into another page.
> 
> netfront will safely handle this case so you can remove this BUG_ON()
> (and the one later on).  But it would be better to find out were these
> funny-looking skbs are coming from and (if necessary) fixing the bug there.

There still seems to be disagreement about whether the "funny" skb is
valid though - you imply it isn't, but Eric says it is. I've been trying
to track down where these skbs originate, and so far I've determined
that they come from a socket spliced to a pipe spliced to a socket. It
looks like the particular page/offset/len tuple originates at least as
far back as the first socket, as the tuple is simply copied from an skb
into the pipe and from the pipe into the final skb.

Anyway, it looks like at minimum it should be safe to change the first
BUG_ON to assert that the data is fully within the compound page as
Stefan suggested, then remove the second BUG_ON entirely. This is the
path I plan to pursue unless someone objects.

Thanks,
Seth

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:35:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnq44-0007ZQ-8p; Mon, 10 Nov 2014 14:35:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <seth.forshee@canonical.com>) id 1Xnq42-0007ZK-Iq
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:35:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7A/13-24532-13DC0645; Mon, 10 Nov 2014 14:35:29 +0000
X-Env-Sender: seth.forshee@canonical.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415630128!4715564!1
X-Originating-IP: [209.85.218.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2842 invoked from network); 10 Nov 2014 14:35:29 -0000
Received: from mail-oi0-f47.google.com (HELO mail-oi0-f47.google.com)
	(209.85.218.47)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:35:29 -0000
Received: by mail-oi0-f47.google.com with SMTP id a3so5477299oib.34
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 06:35:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id
	:mail-followup-to:references:mime-version:content-type
	:content-disposition:in-reply-to:user-agent;
	bh=z9vgX9MmwXxEcIHkZP9U9tgSylnSNofvWvPHuSoMhAk=;
	b=bIp9j1zguD5Asv2FrZZ2IxjiHF1bOYUAUTkXvVdtLr4qtmrrchQ/EdCoJTZNSTmumR
	SnuJigZlgd4AzSvpVi4nyuS728TBJTJcoSqdNBJO6o5Pb1ZNNCID2R1Evj3Bk82LXITo
	WldvliEp7HBw+ch9SwU4PSSpUaukXw7eZbb4gIYI2PKAan+BDKQqSoNUVcT9NFSaja4e
	imn0sFFkp20yPI+9WHopLrC0ci0ATvE1/SwwSEC3WHQYztcwiYUpQ5/aWUqsB+37d+n8
	18SBdDXsZ5vTJiImq/FccqM+tC/WdvZcbVgdMjGaMRVQARyIDicAWjMcbGY9QQeQ7uiX
	1izw==
X-Gm-Message-State: ALoCoQmbW7Kk6W7oF2ZzqfRbj/z5JZSlmipSFBW7VX53F59++PfULIqWVBr6wj8/nvPEHIqrJQJg
X-Received: by 10.182.129.226 with SMTP id nz2mr26354896obb.5.1415630128145;
	Mon, 10 Nov 2014 06:35:28 -0800 (PST)
Received: from localhost (199-87-125-144.dyn.kc.surewest.net. [199.87.125.144])
	by mx.google.com with ESMTPSA id rm7sm6124551obc.14.2014.11.10.06.35.27
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Mon, 10 Nov 2014 06:35:27 -0800 (PST)
Date: Mon, 10 Nov 2014 08:35:17 -0600
From: Seth Forshee <seth.forshee@canonical.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141110143517.GA74005@ubuntu-hedt>
Mail-Followup-To: David Vrabel <david.vrabel@citrix.com>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20141106214940.GD44162@ubuntu-hedt> <545CA27F.4070400@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545CA27F.4070400@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Stefan Bader <stefan.bader@canonical.com>,
	seth.forshee@canonical.com, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 07, 2014 at 10:44:15AM +0000, David Vrabel wrote:
> On 06/11/14 21:49, Seth Forshee wrote:
> > We've had several reports of hitting the following BUG_ON in
> > xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
> > results of testing with 3.17):
> > 
> >         /* Grant backend access to each skb fragment page. */
> >         for (i = 0; i < frags; i++) {
> >                 skb_frag_t *frag = skb_shinfo(skb)->frags + i;
> >                 struct page *page = skb_frag_page(frag);
> > 
> >                 len = skb_frag_size(frag);
> >                 offset = frag->page_offset;
> > 
> >                 /* Data must not cross a page boundary. */
> >                 BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
> > 
> > When this happens the page in question is a "middle" page in a compound
> > page (i.e. it's a tail page but not the last tail page), and the data is
> > fully contained within the compound page. The data does however cross
> > the hardware page boundary, and since compound_order evaluates to 0 for
> > tail pages the check fails.
> > 
> > In going over this I've been unable to determine whether the BUG_ON in
> > xennet_make_frags is incorrect or the paged skb data is wrong. I can't
> > find that it's documented anywhere, and the networking code itself is a
> > bit ambiguous when it comes to compound pages. On the one hand
> > __skb_fill_page_desc specifically handles adding tail pages as paged
> > data, but on the other hand skb_copy_bits kmaps frag->page.p which could
> > fail with data that extends into another page.
> 
> netfront will safely handle this case so you can remove this BUG_ON()
> (and the one later on).  But it would be better to find out were these
> funny-looking skbs are coming from and (if necessary) fixing the bug there.

There still seems to be disagreement about whether the "funny" skb is
valid though - you imply it isn't, but Eric says it is. I've been trying
to track down where these skbs originate, and so far I've determined
that they come from a socket spliced to a pipe spliced to a socket. It
looks like the particular page/offset/len tuple originates at least as
far back as the first socket, as the tuple is simply copied from an skb
into the pipe and from the pipe into the final skb.

Anyway, it looks like at minimum it should be safe to change the first
BUG_ON to assert that the data is fully within the compound page as
Stefan suggested, then remove the second BUG_ON entirely. This is the
path I plan to pursue unless someone objects.

Thanks,
Seth

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:35:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnq4F-0007b8-LB; Mon, 10 Nov 2014 14:35:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xnq4D-0007aq-Cx
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:35:41 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	51/3C-23865-C3DC0645; Mon, 10 Nov 2014 14:35:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415630138!7151678!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27395 invoked from network); 10 Nov 2014 14:35:39 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 14:35:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAEZX4i001157
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 14:35:33 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAEZVsJ025885
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 14:35:32 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAEZVEQ002394; Mon, 10 Nov 2014 14:35:31 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 06:35:31 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 49D57111F69; Mon, 10 Nov 2014 09:35:30 -0500 (EST)
Date: Mon, 10 Nov 2014 09:35:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141110143530.GD3783@laptop.dumpdata.com>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>
	<545235EE.4040000@citrix.com>
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
	<1415096148.11486.11.camel@citrix.com>
	<545BEFC5.3010803@tycho.nsa.gov>
	<1415620919.28370.14.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415620919.28370.14.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Emil Condrea <emilcondrea@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 12:01:59PM +0000, Ian Campbell wrote:
> On Thu, 2014-11-06 at 17:01 -0500, Daniel De Graaf wrote:
> > On 11/04/2014 05:15 AM, Ian Campbell wrote:
> > > On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
> > >> Of course we can use max, but I thought that it might be useful to
> > >> have a prink to inform the user that the timeout was adjusted.
> > >> In init_tpm_tis the default timeouts are set using:
> > >> /* Set default timeouts */ tpm->timeout_a =
> > >> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
> > >> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
> > >> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
> > >> MILLISECS(TIS_SHORT_TIMEOUT);
> > >>
> > >>
> > >>
> > >> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
> > >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
> > >> So if we want to integrate kernel changes I think we should use
> > >> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
> > >> Also in kernel the default timeouts are initialized using
> > >> msecs_to_jiffies which is different from MILLISECS
> > >> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
> > >> Is there a certain reason for not using msecs_to_jiffies ?
> > >
> > > jiffies are a Linux specific concept which mini-os doesn't share.
> > >
> > > Daniel, do you have any opinion on this patch?
> > >
> > > It seems like the Linux fix is made only for the specifically broken
> > > platform. That seems to make sense to me since presumably other systems
> > > report short timeouts which they can indeed cope with. It's only Atmel
> > > which brokenly reports something it cannot handle.
> > >
> > > Ian.
> > 
> > I agree that an adjustment is needed when values are too short.  Adjusting
> > in all cases is not quite as nice as only fixing the broken TPMs, but it
> > is a lot simpler.  It also doesn't seem harmful to have the timeouts be
> > too large in the driver: a properly functioning TPM will not time out its
> > requests in any case, so the user won't notice normally, and the default
> > short timeout is 0.75 seconds - very few people will complain if they have
> > to wait that long to get a timeout instead of what their TPM actually uses.
> 
> Can we take that as an ack?
> 
> Also needs the ok from Konrad as release manager. AIUI this is a bugfix
> for a particular piece of h/w and as Daniel explains above the downside
> is that sometimes someone might need to wait 0.75s for a timeout instead
> of something shorter.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:35:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnq4F-0007b8-LB; Mon, 10 Nov 2014 14:35:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xnq4D-0007aq-Cx
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:35:41 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	51/3C-23865-C3DC0645; Mon, 10 Nov 2014 14:35:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415630138!7151678!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27395 invoked from network); 10 Nov 2014 14:35:39 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 14:35:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAEZX4i001157
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 14:35:33 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAEZVsJ025885
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 14:35:32 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAEZVEQ002394; Mon, 10 Nov 2014 14:35:31 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 06:35:31 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 49D57111F69; Mon, 10 Nov 2014 09:35:30 -0500 (EST)
Date: Mon, 10 Nov 2014 09:35:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141110143530.GD3783@laptop.dumpdata.com>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>
	<545235EE.4040000@citrix.com>
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
	<1415096148.11486.11.camel@citrix.com>
	<545BEFC5.3010803@tycho.nsa.gov>
	<1415620919.28370.14.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415620919.28370.14.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Emil Condrea <emilcondrea@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 12:01:59PM +0000, Ian Campbell wrote:
> On Thu, 2014-11-06 at 17:01 -0500, Daniel De Graaf wrote:
> > On 11/04/2014 05:15 AM, Ian Campbell wrote:
> > > On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
> > >> Of course we can use max, but I thought that it might be useful to
> > >> have a prink to inform the user that the timeout was adjusted.
> > >> In init_tpm_tis the default timeouts are set using:
> > >> /* Set default timeouts */ tpm->timeout_a =
> > >> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
> > >> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
> > >> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
> > >> MILLISECS(TIS_SHORT_TIMEOUT);
> > >>
> > >>
> > >>
> > >> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
> > >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
> > >> So if we want to integrate kernel changes I think we should use
> > >> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
> > >> Also in kernel the default timeouts are initialized using
> > >> msecs_to_jiffies which is different from MILLISECS
> > >> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
> > >> Is there a certain reason for not using msecs_to_jiffies ?
> > >
> > > jiffies are a Linux specific concept which mini-os doesn't share.
> > >
> > > Daniel, do you have any opinion on this patch?
> > >
> > > It seems like the Linux fix is made only for the specifically broken
> > > platform. That seems to make sense to me since presumably other systems
> > > report short timeouts which they can indeed cope with. It's only Atmel
> > > which brokenly reports something it cannot handle.
> > >
> > > Ian.
> > 
> > I agree that an adjustment is needed when values are too short.  Adjusting
> > in all cases is not quite as nice as only fixing the broken TPMs, but it
> > is a lot simpler.  It also doesn't seem harmful to have the timeouts be
> > too large in the driver: a properly functioning TPM will not time out its
> > requests in any case, so the user won't notice normally, and the default
> > short timeout is 0.75 seconds - very few people will complain if they have
> > to wait that long to get a timeout instead of what their TPM actually uses.
> 
> Can we take that as an ack?
> 
> Also needs the ok from Konrad as release manager. AIUI this is a bugfix
> for a particular piece of h/w and as Daniel explains above the downside
> is that sometimes someone might need to wait 0.75s for a timeout instead
> of something shorter.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:42:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:42:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqAD-0007ry-JG; Mon, 10 Nov 2014 14:41:53 +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 1XnqAB-0007rn-Ir
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:41:51 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	A7/33-19763-EAEC0645; Mon, 10 Nov 2014 14:41:50 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415630506!6262341!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15595 invoked from network); 10 Nov 2014 14:41:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:41:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189760408"
Message-ID: <5460CEA5.3070201@citrix.com>
Date: Mon, 10 Nov 2014 14:41:41 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>, Eric
	Dumazet <eric.dumazet@gmail.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Stefan Bader <stefan.bader@canonical.com>, Jay Vosburgh
	<jay.vosburgh@canonical.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xenproject.org>
References: <20141106214940.GD44162@ubuntu-hedt> <545CA27F.4070400@citrix.com>
	<20141110143517.GA74005@ubuntu-hedt>
In-Reply-To: <20141110143517.GA74005@ubuntu-hedt>
X-DLP: MIA2
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/14 14:35, Seth Forshee wrote:
> On Fri, Nov 07, 2014 at 10:44:15AM +0000, David Vrabel wrote:
>> On 06/11/14 21:49, Seth Forshee wrote:
>>> We've had several reports of hitting the following BUG_ON in
>>> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
>>> results of testing with 3.17):
>>>
>>>         /* Grant backend access to each skb fragment page. */
>>>         for (i = 0; i < frags; i++) {
>>>                 skb_frag_t *frag = skb_shinfo(skb)->frags + i;
>>>                 struct page *page = skb_frag_page(frag);
>>>
>>>                 len = skb_frag_size(frag);
>>>                 offset = frag->page_offset;
>>>
>>>                 /* Data must not cross a page boundary. */
>>>                 BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
>>>
>>> When this happens the page in question is a "middle" page in a compound
>>> page (i.e. it's a tail page but not the last tail page), and the data is
>>> fully contained within the compound page. The data does however cross
>>> the hardware page boundary, and since compound_order evaluates to 0 for
>>> tail pages the check fails.
>>>
>>> In going over this I've been unable to determine whether the BUG_ON in
>>> xennet_make_frags is incorrect or the paged skb data is wrong. I can't
>>> find that it's documented anywhere, and the networking code itself is a
>>> bit ambiguous when it comes to compound pages. On the one hand
>>> __skb_fill_page_desc specifically handles adding tail pages as paged
>>> data, but on the other hand skb_copy_bits kmaps frag->page.p which could
>>> fail with data that extends into another page.
>>
>> netfront will safely handle this case so you can remove this BUG_ON()
>> (and the one later on).  But it would be better to find out were these
>> funny-looking skbs are coming from and (if necessary) fixing the bug there.
> 
> There still seems to be disagreement about whether the "funny" skb is
> valid though - you imply it isn't, but Eric says it is. I've been trying
> to track down where these skbs originate, and so far I've determined
> that they come from a socket spliced to a pipe spliced to a socket. It
> looks like the particular page/offset/len tuple originates at least as
> far back as the first socket, as the tuple is simply copied from an skb
> into the pipe and from the pipe into the final skb.

Apologies for the lack of clarity.  I meant either: a) fix the producer
if these skbs are invalid; or b) remove the BUG_ON()s.  Since Eric says
these are actually valid skbs, please do option (b).

i.e., remove both BUG_ON()s.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:42:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:42:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqAD-0007ry-JG; Mon, 10 Nov 2014 14:41:53 +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 1XnqAB-0007rn-Ir
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:41:51 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	A7/33-19763-EAEC0645; Mon, 10 Nov 2014 14:41:50 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415630506!6262341!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15595 invoked from network); 10 Nov 2014 14:41:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:41:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189760408"
Message-ID: <5460CEA5.3070201@citrix.com>
Date: Mon, 10 Nov 2014 14:41:41 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>, Eric
	Dumazet <eric.dumazet@gmail.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Stefan Bader <stefan.bader@canonical.com>, Jay Vosburgh
	<jay.vosburgh@canonical.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xenproject.org>
References: <20141106214940.GD44162@ubuntu-hedt> <545CA27F.4070400@citrix.com>
	<20141110143517.GA74005@ubuntu-hedt>
In-Reply-To: <20141110143517.GA74005@ubuntu-hedt>
X-DLP: MIA2
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/14 14:35, Seth Forshee wrote:
> On Fri, Nov 07, 2014 at 10:44:15AM +0000, David Vrabel wrote:
>> On 06/11/14 21:49, Seth Forshee wrote:
>>> We've had several reports of hitting the following BUG_ON in
>>> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
>>> results of testing with 3.17):
>>>
>>>         /* Grant backend access to each skb fragment page. */
>>>         for (i = 0; i < frags; i++) {
>>>                 skb_frag_t *frag = skb_shinfo(skb)->frags + i;
>>>                 struct page *page = skb_frag_page(frag);
>>>
>>>                 len = skb_frag_size(frag);
>>>                 offset = frag->page_offset;
>>>
>>>                 /* Data must not cross a page boundary. */
>>>                 BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
>>>
>>> When this happens the page in question is a "middle" page in a compound
>>> page (i.e. it's a tail page but not the last tail page), and the data is
>>> fully contained within the compound page. The data does however cross
>>> the hardware page boundary, and since compound_order evaluates to 0 for
>>> tail pages the check fails.
>>>
>>> In going over this I've been unable to determine whether the BUG_ON in
>>> xennet_make_frags is incorrect or the paged skb data is wrong. I can't
>>> find that it's documented anywhere, and the networking code itself is a
>>> bit ambiguous when it comes to compound pages. On the one hand
>>> __skb_fill_page_desc specifically handles adding tail pages as paged
>>> data, but on the other hand skb_copy_bits kmaps frag->page.p which could
>>> fail with data that extends into another page.
>>
>> netfront will safely handle this case so you can remove this BUG_ON()
>> (and the one later on).  But it would be better to find out were these
>> funny-looking skbs are coming from and (if necessary) fixing the bug there.
> 
> There still seems to be disagreement about whether the "funny" skb is
> valid though - you imply it isn't, but Eric says it is. I've been trying
> to track down where these skbs originate, and so far I've determined
> that they come from a socket spliced to a pipe spliced to a socket. It
> looks like the particular page/offset/len tuple originates at least as
> far back as the first socket, as the tuple is simply copied from an skb
> into the pipe and from the pipe into the final skb.

Apologies for the lack of clarity.  I meant either: a) fix the producer
if these skbs are invalid; or b) remove the BUG_ON()s.  Since Eric says
these are actually valid skbs, please do option (b).

i.e., remove both BUG_ON()s.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:43:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqBj-00082C-6W; Mon, 10 Nov 2014 14: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@citrix.com>) id 1XnqBh-000824-Mf
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:43:25 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	52/BF-17958-C0FC0645; Mon, 10 Nov 2014 14:43:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415630601!7153735!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21181 invoked from network); 10 Nov 2014 14:43:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:43:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191200169"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:43:19 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnqBa-00070z-TU;
	Mon, 10 Nov 2014 14:43:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnqBa-0003Bo-HX;
	Mon, 10 Nov 2014 14:43:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21600.52998.204908.811966@mariner.uk.xensource.com>
Date: Mon, 10 Nov 2014 14:43:18 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1415526526-3320-1-git-send-email-ian.campbell@citrix.com>,
	<1415526543-3465-1-git-send-email-ian.campbell@citrix.com>,
	<1415526555-3609-1-git-send-email-ian.campbell@citrix.com>
References: <1415526555-3609-1-git-send-email-ian.campbell@citrix.com>
	<1415526543-3465-1-git-send-email-ian.campbell@citrix.com>
	<1415526526-3320-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST] Debian: Install ethtool on the
	hosts [and 2 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH OSSTEST] Debian: Install ethtool on the hosts"):
> It's very useful when debugging network issues.

Ian Campbell writes ("[PATCH OSSTEST] mg-debian-installer-update: Use Packages.gz"):
> In Jessie Packages.bz2 is replaced by Packages.xz. Rather than implementing
> per-suite handling just fallback to lowest-common-denominator gzip.

Ian Campbell writes ("[PATCH OSSTEST] ts-host-install: Ensure $dtbs is always a valid string"):
> Otherwise on non-ARM platforms we get warnings about uninitialised values.

All three:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:43:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqBj-00082C-6W; Mon, 10 Nov 2014 14: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@citrix.com>) id 1XnqBh-000824-Mf
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 14:43:25 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	52/BF-17958-C0FC0645; Mon, 10 Nov 2014 14:43:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415630601!7153735!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21181 invoked from network); 10 Nov 2014 14:43:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 14:43:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191200169"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 09:43:19 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnqBa-00070z-TU;
	Mon, 10 Nov 2014 14:43:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnqBa-0003Bo-HX;
	Mon, 10 Nov 2014 14:43:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21600.52998.204908.811966@mariner.uk.xensource.com>
Date: Mon, 10 Nov 2014 14:43:18 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1415526526-3320-1-git-send-email-ian.campbell@citrix.com>,
	<1415526543-3465-1-git-send-email-ian.campbell@citrix.com>,
	<1415526555-3609-1-git-send-email-ian.campbell@citrix.com>
References: <1415526555-3609-1-git-send-email-ian.campbell@citrix.com>
	<1415526543-3465-1-git-send-email-ian.campbell@citrix.com>
	<1415526526-3320-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST] Debian: Install ethtool on the
	hosts [and 2 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH OSSTEST] Debian: Install ethtool on the hosts"):
> It's very useful when debugging network issues.

Ian Campbell writes ("[PATCH OSSTEST] mg-debian-installer-update: Use Packages.gz"):
> In Jessie Packages.bz2 is replaced by Packages.xz. Rather than implementing
> per-suite handling just fallback to lowest-common-denominator gzip.

Ian Campbell writes ("[PATCH OSSTEST] ts-host-install: Ensure $dtbs is always a valid string"):
> Otherwise on non-ARM platforms we get warnings about uninitialised values.

All three:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:55:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:55:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqNB-0008Iw-NK; Mon, 10 Nov 2014 14:55:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XnqN9-0008Ir-Ik
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:55:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	95/F5-09936-2D1D0645; Mon, 10 Nov 2014 14:55:14 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415631309!12763866!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13431 invoked from network); 10 Nov 2014 14:55:12 -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;
	10 Nov 2014 14:55:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191203759"
Message-ID: <5460D1CA.3090905@citrix.com>
Date: Mon, 10 Nov 2014 14:55:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1415617996-18632-1-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1415617996-18632-1-git-send-email-paul.durrant@citrix.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v3] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/14 11:13, Paul Durrant wrote:
> HVM guests have always been confined to using the domain callback
> via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications.
> This is usually an IOAPIC vector and is only used if the event
> channel is bound to vcpu 0.
> 
> PV-on-HVM Linux uses a local APIC vector for event channel upcall,
> set using HVM_PARAM_CALLBACK_IRQ by ORing in a special bit (bit 57)
> into the value (see params.h), but this mechanism is not suitable
> in the general case since the vector must be the same on all vcpus
> which cannot be guaranteed on some OS (e.g. Windows).

"local APIC vector" doesn't make much sense to me here since PVHVM Linux
bypasses the APIC entirely for event channels.

Reword to:

"PVHVM Linux uses a pre-defined interrupt vector for the event channel
upcall, set using HVM_PARAM_CALLBACK_IRQ by ORing in a special bit
(bit 57) into the value (see params.h), This mechanism does not assert
the interrupt via the local APIC.

This mechanism is not suitable in the general case since Windows (and
potentially other OSes):

- cannot guarantee the same vector for all VCPUs
- require the upcall to be asserted via the local APIC."

or similar.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:55:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:55:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqNB-0008Iw-NK; Mon, 10 Nov 2014 14:55:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XnqN9-0008Ir-Ik
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:55:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	95/F5-09936-2D1D0645; Mon, 10 Nov 2014 14:55:14 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415631309!12763866!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13431 invoked from network); 10 Nov 2014 14:55:12 -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;
	10 Nov 2014 14:55:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191203759"
Message-ID: <5460D1CA.3090905@citrix.com>
Date: Mon, 10 Nov 2014 14:55:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1415617996-18632-1-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1415617996-18632-1-git-send-email-paul.durrant@citrix.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v3] x86/hvm: Add per-vcpu evtchn upcalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/14 11:13, Paul Durrant wrote:
> HVM guests have always been confined to using the domain callback
> via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications.
> This is usually an IOAPIC vector and is only used if the event
> channel is bound to vcpu 0.
> 
> PV-on-HVM Linux uses a local APIC vector for event channel upcall,
> set using HVM_PARAM_CALLBACK_IRQ by ORing in a special bit (bit 57)
> into the value (see params.h), but this mechanism is not suitable
> in the general case since the vector must be the same on all vcpus
> which cannot be guaranteed on some OS (e.g. Windows).

"local APIC vector" doesn't make much sense to me here since PVHVM Linux
bypasses the APIC entirely for event channels.

Reword to:

"PVHVM Linux uses a pre-defined interrupt vector for the event channel
upcall, set using HVM_PARAM_CALLBACK_IRQ by ORing in a special bit
(bit 57) into the value (see params.h), This mechanism does not assert
the interrupt via the local APIC.

This mechanism is not suitable in the general case since Windows (and
potentially other OSes):

- cannot guarantee the same vector for all VCPUs
- require the upcall to be asserted via the local APIC."

or similar.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:57:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqPR-0008R2-Gj; Mon, 10 Nov 2014 14:57:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XnqPQ-0008Qt-5H
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:57:36 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	52/2A-17958-F52D0645; Mon, 10 Nov 2014 14:57:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415631452!11466207!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17634 invoked from network); 10 Nov 2014 14:57:34 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 14:57:34 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAEvNGH000415
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 14:57:24 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAEvMV6025352
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 14:57:23 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAEvLlZ008900; Mon, 10 Nov 2014 14:57:21 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 06:57:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 571AE111FD2; Mon, 10 Nov 2014 09:57:20 -0500 (EST)
Date: Mon, 10 Nov 2014 09:57:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20141110145720.GH3783@laptop.dumpdata.com>
References: <20140110184151.GA20232@pegasus.dumpdata.com>
	<1389607803.8187.22.camel@kazak.uk.xensource.com>
	<52D3DC730200007800112FF6@nat28.tlf.novell.com>
	<1389613109.13654.43.camel@kazak.uk.xensource.com>
	<52D3E1500200007800113058@nat28.tlf.novell.com>
	<20140115200736.GB5201@phenom.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABD8C46@SHSMSX104.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABD8C46@SHSMSX104.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Li, Liang Z" <liang.z.li@intel.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "Nakajima, Jun" <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 05:08:09AM +0000, Zhang, Yang Z wrote:
> Konrad Rzeszutek Wilk wrote on 2014-01-16:
> > On Mon, Jan 13, 2014 at 11:51:28AM +0000, Jan Beulich wrote:
> >>>>> On 13.01.14 at 12:38, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>> On Mon, 2014-01-13 at 11:30 +0000, Jan Beulich wrote:
> >>>> In fact I can't see where this would be forced off:
> >>>> xc_cpuid_x86.c only does so in the PV case, and all
> >>>> hvm_pse1gb_supported() is that the CPU supports it and the domain uses HAP.
> >>> 
> >>> Took me a while to spot it too:
> >>> static void intel_xc_cpuid_policy( [...]
> >>>             case 0x80000001: {
> >>>                 int is_64bit = hypervisor_is_64bit(xch) && is_pae;
> >>>                 
> >>>                 /* Only a few features are advertised in Intel's
> >>>                 0x80000001. */ regs[2] &= (is_64bit ?
> > bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
> >>> 
> > bitmaskof(X86_FEATURE_ABM);
> >>>                 regs[3] &= ((is_pae ? bitmaskof(X86_FEATURE_NX) :
> >>> 0)
> > |
> >>>                             (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0)
> >>>                             | (is_64bit ?
> >>>                             bitmaskof(X86_FEATURE_SYSCALL) : 0) |
> >>>                             (is_64bit ?
> > bitmaskof(X86_FEATURE_RDTSCP) : 0));
> >>>                 break;
> >>>             }
> >>> 
> >>> Which masks anything which is not explicitly mentioned. (PAGE1GB
> >>> is in regs[3], I think).
> >> 
> >> Ah, okay. The funs of white listing on HVM vs black listing on PV
> >> again.
> >> 
> >>> The AMD version is more permissive:
> >>> 
> >>>         regs[3] &= (0x0183f3ff | /* features shared with
> > 0x00000001:EDX */
> >>>                     (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
> >>>                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
> >>>                     bitmaskof(X86_FEATURE_SYSCALL) |
> >>>                     bitmaskof(X86_FEATURE_MP) |
> >>>                     bitmaskof(X86_FEATURE_MMXEXT) |
> >>>                     bitmaskof(X86_FEATURE_FFXSR) |
> >>>                     bitmaskof(X86_FEATURE_3DNOW) |
> >>>                     bitmaskof(X86_FEATURE_3DNOWEXT));
> >>> (but I didn't check if PAGE1GB is in that magic number...)
> >> 
> >> It's not - it's bit 26.
> > 
> > So.. it sounds to me like everybody is in the agreement that this is
> > the right thing to do (enable it if the hypervisor has it enabled)?
> > 
> > And the next thing is actually come up with a patch to do some of this
> > plumbing - naturally for Xen 4.5?
> 
> Hi, Konrad,
> 
> Is there any patch to turn on the 1GB hugepages? If no, we are happy to give a patch to do it.

I have not see a patch for this, and I would be quite happy to see patch
developed for this!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 14:57:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 14:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqPR-0008R2-Gj; Mon, 10 Nov 2014 14:57:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XnqPQ-0008Qt-5H
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 14:57:36 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	52/2A-17958-F52D0645; Mon, 10 Nov 2014 14:57:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415631452!11466207!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17634 invoked from network); 10 Nov 2014 14:57:34 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 14:57:34 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAEvNGH000415
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 14:57:24 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAEvMV6025352
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 14:57:23 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAEvLlZ008900; Mon, 10 Nov 2014 14:57:21 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 06:57:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 571AE111FD2; Mon, 10 Nov 2014 09:57:20 -0500 (EST)
Date: Mon, 10 Nov 2014 09:57:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20141110145720.GH3783@laptop.dumpdata.com>
References: <20140110184151.GA20232@pegasus.dumpdata.com>
	<1389607803.8187.22.camel@kazak.uk.xensource.com>
	<52D3DC730200007800112FF6@nat28.tlf.novell.com>
	<1389613109.13654.43.camel@kazak.uk.xensource.com>
	<52D3E1500200007800113058@nat28.tlf.novell.com>
	<20140115200736.GB5201@phenom.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABD8C46@SHSMSX104.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABD8C46@SHSMSX104.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Li, Liang Z" <liang.z.li@intel.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "Nakajima, Jun" <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 05:08:09AM +0000, Zhang, Yang Z wrote:
> Konrad Rzeszutek Wilk wrote on 2014-01-16:
> > On Mon, Jan 13, 2014 at 11:51:28AM +0000, Jan Beulich wrote:
> >>>>> On 13.01.14 at 12:38, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>> On Mon, 2014-01-13 at 11:30 +0000, Jan Beulich wrote:
> >>>> In fact I can't see where this would be forced off:
> >>>> xc_cpuid_x86.c only does so in the PV case, and all
> >>>> hvm_pse1gb_supported() is that the CPU supports it and the domain uses HAP.
> >>> 
> >>> Took me a while to spot it too:
> >>> static void intel_xc_cpuid_policy( [...]
> >>>             case 0x80000001: {
> >>>                 int is_64bit = hypervisor_is_64bit(xch) && is_pae;
> >>>                 
> >>>                 /* Only a few features are advertised in Intel's
> >>>                 0x80000001. */ regs[2] &= (is_64bit ?
> > bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
> >>> 
> > bitmaskof(X86_FEATURE_ABM);
> >>>                 regs[3] &= ((is_pae ? bitmaskof(X86_FEATURE_NX) :
> >>> 0)
> > |
> >>>                             (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0)
> >>>                             | (is_64bit ?
> >>>                             bitmaskof(X86_FEATURE_SYSCALL) : 0) |
> >>>                             (is_64bit ?
> > bitmaskof(X86_FEATURE_RDTSCP) : 0));
> >>>                 break;
> >>>             }
> >>> 
> >>> Which masks anything which is not explicitly mentioned. (PAGE1GB
> >>> is in regs[3], I think).
> >> 
> >> Ah, okay. The funs of white listing on HVM vs black listing on PV
> >> again.
> >> 
> >>> The AMD version is more permissive:
> >>> 
> >>>         regs[3] &= (0x0183f3ff | /* features shared with
> > 0x00000001:EDX */
> >>>                     (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
> >>>                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
> >>>                     bitmaskof(X86_FEATURE_SYSCALL) |
> >>>                     bitmaskof(X86_FEATURE_MP) |
> >>>                     bitmaskof(X86_FEATURE_MMXEXT) |
> >>>                     bitmaskof(X86_FEATURE_FFXSR) |
> >>>                     bitmaskof(X86_FEATURE_3DNOW) |
> >>>                     bitmaskof(X86_FEATURE_3DNOWEXT));
> >>> (but I didn't check if PAGE1GB is in that magic number...)
> >> 
> >> It's not - it's bit 26.
> > 
> > So.. it sounds to me like everybody is in the agreement that this is
> > the right thing to do (enable it if the hypervisor has it enabled)?
> > 
> > And the next thing is actually come up with a patch to do some of this
> > plumbing - naturally for Xen 4.5?
> 
> Hi, Konrad,
> 
> Is there any patch to turn on the 1GB hugepages? If no, we are happy to give a patch to do it.

I have not see a patch for this, and I would be quite happy to see patch
developed for this!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:01:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:01:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqTI-0000CP-Kp; Mon, 10 Nov 2014 15:01:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XnqTG-0000C8-RM
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:01:34 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	83/74-28296-E43D0645; Mon, 10 Nov 2014 15:01:34 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415631691!11545390!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17370 invoked from network); 10 Nov 2014 15:01:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 15:01:33 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAF1OLe007286
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 15:01:25 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAAF1O1Y010784
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Nov 2014 15:01:24 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAAF1NKn010701; Mon, 10 Nov 2014 15:01:23 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 07:01:23 -0800
Message-ID: <5460D342.9090308@oracle.com>
Date: Mon, 10 Nov 2014 10:01:22 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
In-Reply-To: <20141110123525.GD28360@zion.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/10/2014 07:35 AM, Wei Liu wrote:
> I see. At that point the configuration was not available, yet. After the
> domain is successfully migrated, the configuration should be available.
> 
> I think a domain under construction without domain configuration is a
> valid state. What do you think?

Here is my thought:

1. In this design, if I watch xenstore @introduceDomain, it will not been
   triggered until migration finish.

2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
   domain state, we need to define what does it mean by "VM started".

3. It looks like a inconsistent state and we may want to eliminate or keep
   it as short as possible.

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:01:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:01:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqT5-0000BJ-7N; Mon, 10 Nov 2014 15:01:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XnqT3-0000BC-Pc
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 15:01:21 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A8/D5-09842-143D0645; Mon, 10 Nov 2014 15:01:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415631679!12751205!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27378 invoked from network); 10 Nov 2014 15:01:20 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 15:01:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAF16P8031562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 15:01:06 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAF14ZY002392
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Nov 2014 15:01:04 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAAF12aV009195; Mon, 10 Nov 2014 15:01:03 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 07:01:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7BED4111FE3; Mon, 10 Nov 2014 10:01:00 -0500 (EST)
Date: Mon, 10 Nov 2014 10:01:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Chun Yan Liu <cyliu@suse.com>, jgross@suse.com, olaf@aepfle.de
Message-ID: <20141110150100.GK3783@laptop.dumpdata.com>
References: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
	<5460E9D80200006600078038@soto.provo.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460E9D80200006600078038@soto.provo.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Lars Kurth <lars.kurth@citrix.com>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>, Bo Cao <caobosimon@gmail.com>
Subject: Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Nov 10, 2014 at 01:37:44AM -0700, Chun Yan Liu wrote:
> Is there any progress on this work? I didn't see new version after this.
> Anyone knows the status?

I believe Olaf and Juergen were looking at this for Xen 4.6?

CC-ing them.
> =

> Thanks,
> Chunyan
> =

> >>> On 8/11/2014 at 04:23 AM, in message
> <1407702234-22309-1-git-send-email-caobosimon@gmail.com>, Bo Cao
> <caobosimon@gmail.com> wrote: =

> > Finally I have a workable version xl/libxl support for PVUSB. Most of =

> > its commands work property now, but there are still some probelm to be
> > solved. =

> > Please take a loot and give me some advices.
> >  =

> > =3D=3D What have been implemented ? =3D=3D =

> > I have implemented libxl functions for PVUSB in libxl_usb.c. It mainly  =

> > consists of two part: =

> > usbctrl_add/remove/list and usb_add/remove/list in which usbctrl denote=
 usb  =

> > controller in which =

> > usd device can be plugged in. I don't use "ao_dev" in  =

> > libxl_deivce_usbctrl_add since we don't need to =

> > execute hotplug script for usbctrl and without "ao_dev", adding default=
  =

> > usbctrl for usb device =

> > would be easier. =

> >  =

> > For the cammands to manipulate usb device such as "xl usb-attach" and "=
xl  =

> > usb-detach", this patch now only =

> > support to specify usb devices by their interface in sysfs. Using this  =

> > interface, we can read usb device =

> > information through sysfs and bind/unbind usb device. (The support for  =

> > mapping the "lsusb" bus:addr to the =

> > sysfs usb interface will come later). =

> >  =

> > =3D=3D What needs to do next ? =3D=3D =

> > There are two main problems to be solved. =

> >  =

> > 1.  PVUSB Options in VM Guest's Configuration File =

> >     The interface in VM Guest's configuration file to add usb device is=
:  =

> > "usb=3D[interface=3D"1-1"]". =

> > But the problem is now is that after the default usbctrl is added, the =
state  =

> > of usbctrl is "2", e,g, "XenbusStateInitWait", =

> > waiting for xen-usbfront to connect. The xen-usbfront in VM Guest isn't=
  =

> > loaded. Therefore, "sysfs_intf_write" =

> > will report error. Does anyone have any clue how to solve this? =

> >  =

> > 2. sysfs_intf_write =

> >     In the process of "xl usb-attach domid intf=3D1-1", after writing "=
1-1" to  =

> > Xenstore entry, we need to =

> > bind the controller of this usb device to usbback driver so that it can=
 be  =

> > used by VM Guest. For exampele, =

> > for usb device "1-1", it's controller interface maybe "1-1:1.0", and we=
  =

> > write this value to "/sys/bus/usb/driver/usbback/bind". =

> > But for some devices, they have two controllers, for example "1-1:1.0" =
and  =

> > "1-1:1.1". I think this means it has two functions, =

> > such as usbhid and usb-storage. So in this case, we bind the two contro=
ller  =

> > to usbback? =

> >  =

> > =3D=3D=3D=3D=3D=3D=3D=3D =

> > There maybe some errors or bugs in the codes. Feel free to tell me. =

> >  =

> > Cheers, =

> >  =

> > - Simon =

> >  =

> > --- =

> > CC: George Dunlap <george.dunlap@eu.citrix.com> =

> > CC: Ian Jackson <ian.jackson@citrix.com> =

> > CC: Ian Campbell <ian.campbell@citrix.com> =

> > CC: Pasi K=E4rkk=E4inen <pasik@iki.fi> =

> > CC: Lars Kurth <lars.kurth@citrix.com> =

> >  =

> >  =

> >  =

> > _______________________________________________ =

> > Xen-devel mailing list =

> > Xen-devel@lists.xen.org =

> > http://lists.xen.org/xen-devel =

> >  =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:01:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:01:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqTI-0000CP-Kp; Mon, 10 Nov 2014 15:01:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XnqTG-0000C8-RM
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:01:34 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	83/74-28296-E43D0645; Mon, 10 Nov 2014 15:01:34 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415631691!11545390!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17370 invoked from network); 10 Nov 2014 15:01:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 15:01:33 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAF1OLe007286
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 15:01:25 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAAF1O1Y010784
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Nov 2014 15:01:24 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAAF1NKn010701; Mon, 10 Nov 2014 15:01:23 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 07:01:23 -0800
Message-ID: <5460D342.9090308@oracle.com>
Date: Mon, 10 Nov 2014 10:01:22 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
In-Reply-To: <20141110123525.GD28360@zion.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/10/2014 07:35 AM, Wei Liu wrote:
> I see. At that point the configuration was not available, yet. After the
> domain is successfully migrated, the configuration should be available.
> 
> I think a domain under construction without domain configuration is a
> valid state. What do you think?

Here is my thought:

1. In this design, if I watch xenstore @introduceDomain, it will not been
   triggered until migration finish.

2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
   domain state, we need to define what does it mean by "VM started".

3. It looks like a inconsistent state and we may want to eliminate or keep
   it as short as possible.

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:01:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:01:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqT5-0000BJ-7N; Mon, 10 Nov 2014 15:01:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XnqT3-0000BC-Pc
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 15:01:21 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A8/D5-09842-143D0645; Mon, 10 Nov 2014 15:01:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415631679!12751205!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27378 invoked from network); 10 Nov 2014 15:01:20 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 15:01:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAF16P8031562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 15:01:06 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAF14ZY002392
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Nov 2014 15:01:04 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAAF12aV009195; Mon, 10 Nov 2014 15:01:03 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 07:01:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7BED4111FE3; Mon, 10 Nov 2014 10:01:00 -0500 (EST)
Date: Mon, 10 Nov 2014 10:01:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Chun Yan Liu <cyliu@suse.com>, jgross@suse.com, olaf@aepfle.de
Message-ID: <20141110150100.GK3783@laptop.dumpdata.com>
References: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
	<5460E9D80200006600078038@soto.provo.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460E9D80200006600078038@soto.provo.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Lars Kurth <lars.kurth@citrix.com>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>, Bo Cao <caobosimon@gmail.com>
Subject: Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Nov 10, 2014 at 01:37:44AM -0700, Chun Yan Liu wrote:
> Is there any progress on this work? I didn't see new version after this.
> Anyone knows the status?

I believe Olaf and Juergen were looking at this for Xen 4.6?

CC-ing them.
> =

> Thanks,
> Chunyan
> =

> >>> On 8/11/2014 at 04:23 AM, in message
> <1407702234-22309-1-git-send-email-caobosimon@gmail.com>, Bo Cao
> <caobosimon@gmail.com> wrote: =

> > Finally I have a workable version xl/libxl support for PVUSB. Most of =

> > its commands work property now, but there are still some probelm to be
> > solved. =

> > Please take a loot and give me some advices.
> >  =

> > =3D=3D What have been implemented ? =3D=3D =

> > I have implemented libxl functions for PVUSB in libxl_usb.c. It mainly  =

> > consists of two part: =

> > usbctrl_add/remove/list and usb_add/remove/list in which usbctrl denote=
 usb  =

> > controller in which =

> > usd device can be plugged in. I don't use "ao_dev" in  =

> > libxl_deivce_usbctrl_add since we don't need to =

> > execute hotplug script for usbctrl and without "ao_dev", adding default=
  =

> > usbctrl for usb device =

> > would be easier. =

> >  =

> > For the cammands to manipulate usb device such as "xl usb-attach" and "=
xl  =

> > usb-detach", this patch now only =

> > support to specify usb devices by their interface in sysfs. Using this  =

> > interface, we can read usb device =

> > information through sysfs and bind/unbind usb device. (The support for  =

> > mapping the "lsusb" bus:addr to the =

> > sysfs usb interface will come later). =

> >  =

> > =3D=3D What needs to do next ? =3D=3D =

> > There are two main problems to be solved. =

> >  =

> > 1.  PVUSB Options in VM Guest's Configuration File =

> >     The interface in VM Guest's configuration file to add usb device is=
:  =

> > "usb=3D[interface=3D"1-1"]". =

> > But the problem is now is that after the default usbctrl is added, the =
state  =

> > of usbctrl is "2", e,g, "XenbusStateInitWait", =

> > waiting for xen-usbfront to connect. The xen-usbfront in VM Guest isn't=
  =

> > loaded. Therefore, "sysfs_intf_write" =

> > will report error. Does anyone have any clue how to solve this? =

> >  =

> > 2. sysfs_intf_write =

> >     In the process of "xl usb-attach domid intf=3D1-1", after writing "=
1-1" to  =

> > Xenstore entry, we need to =

> > bind the controller of this usb device to usbback driver so that it can=
 be  =

> > used by VM Guest. For exampele, =

> > for usb device "1-1", it's controller interface maybe "1-1:1.0", and we=
  =

> > write this value to "/sys/bus/usb/driver/usbback/bind". =

> > But for some devices, they have two controllers, for example "1-1:1.0" =
and  =

> > "1-1:1.1". I think this means it has two functions, =

> > such as usbhid and usb-storage. So in this case, we bind the two contro=
ller  =

> > to usbback? =

> >  =

> > =3D=3D=3D=3D=3D=3D=3D=3D =

> > There maybe some errors or bugs in the codes. Feel free to tell me. =

> >  =

> > Cheers, =

> >  =

> > - Simon =

> >  =

> > --- =

> > CC: George Dunlap <george.dunlap@eu.citrix.com> =

> > CC: Ian Jackson <ian.jackson@citrix.com> =

> > CC: Ian Campbell <ian.campbell@citrix.com> =

> > CC: Pasi K=E4rkk=E4inen <pasik@iki.fi> =

> > CC: Lars Kurth <lars.kurth@citrix.com> =

> >  =

> >  =

> >  =

> > _______________________________________________ =

> > Xen-devel mailing list =

> > Xen-devel@lists.xen.org =

> > http://lists.xen.org/xen-devel =

> >  =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:21:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:21:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqmR-0000el-V7; Mon, 10 Nov 2014 15:21:23 +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 1XnqmQ-0000eg-Iv
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:21:22 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	7F/BA-02559-1F7D0645; Mon, 10 Nov 2014 15:21:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415632879!12525456!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 658 invoked from network); 10 Nov 2014 15:21:20 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 15:21:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAFLBJK029225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 15:21:11 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFL8AZ014562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 15:21:08 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFL7Ye018985; Mon, 10 Nov 2014 15:21:07 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 07:21:07 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C4B8A112010; Mon, 10 Nov 2014 10:21:06 -0500 (EST)
Date: Mon, 10 Nov 2014 10:21:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: russell.pavlicek@citrix.com, JBeulich@suse.com, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xenproject.org
Message-ID: <20141110152106.GL3783@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] Xen 4.5 RC2 (scheduled on the 12th). Committeers -
	please read.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey,

The 'staging' has four extra patches:

e6fa63d pvgrub: ignore NUL
fda1614 xen/arm: Add support for GICv3 for domU
5a430ec tools: libxl: do not overrun input buffer in libxl__parse_mac
379b351 tools: libxl: do not leak diskpath during local disk attach

where the ' xen/arm: Add support for GICv3 for domU' is pretty significant
and I would like to have that in RC2.

As such, to give OSSTest breathing room to do its testing I would like
to ask committers to not checkin until the the 'e6fa63d' has cleared
and then we can tag RC2 right away (and perhaps it be done before Wednesday!)

Or if OSSTest has issues we have some time to figure it out.

The tentative dates are:

* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
 <==== <WE ARE HERE> =====>
* RC2: Nov 12th
* RC2 Test-day: Nov 13th
* RC3: Nov 24th
* RC3 Test-day: Nov 25th
* Release: 10th December 2014

Thank you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:21:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:21:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqmR-0000el-V7; Mon, 10 Nov 2014 15:21:23 +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 1XnqmQ-0000eg-Iv
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:21:22 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	7F/BA-02559-1F7D0645; Mon, 10 Nov 2014 15:21:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415632879!12525456!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 658 invoked from network); 10 Nov 2014 15:21:20 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 15:21:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAFLBJK029225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 15:21:11 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFL8AZ014562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 15:21:08 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFL7Ye018985; Mon, 10 Nov 2014 15:21:07 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 07:21:07 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C4B8A112010; Mon, 10 Nov 2014 10:21:06 -0500 (EST)
Date: Mon, 10 Nov 2014 10:21:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: russell.pavlicek@citrix.com, JBeulich@suse.com, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xenproject.org
Message-ID: <20141110152106.GL3783@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] Xen 4.5 RC2 (scheduled on the 12th). Committeers -
	please read.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey,

The 'staging' has four extra patches:

e6fa63d pvgrub: ignore NUL
fda1614 xen/arm: Add support for GICv3 for domU
5a430ec tools: libxl: do not overrun input buffer in libxl__parse_mac
379b351 tools: libxl: do not leak diskpath during local disk attach

where the ' xen/arm: Add support for GICv3 for domU' is pretty significant
and I would like to have that in RC2.

As such, to give OSSTest breathing room to do its testing I would like
to ask committers to not checkin until the the 'e6fa63d' has cleared
and then we can tag RC2 right away (and perhaps it be done before Wednesday!)

Or if OSSTest has issues we have some time to figure it out.

The tentative dates are:

* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
 <==== <WE ARE HERE> =====>
* RC2: Nov 12th
* RC2 Test-day: Nov 13th
* RC3: Nov 24th
* RC3 Test-day: Nov 25th
* Release: 10th December 2014

Thank you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:25:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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.xen.org>)
	id 1Xnqqe-0000rE-PY; Mon, 10 Nov 2014 15:25: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 1Xnqqd-0000r7-VC
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:25:44 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	AA/E3-05632-7F8D0645; Mon, 10 Nov 2014 15:25:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415633139!11596352!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8276 invoked from network); 10 Nov 2014 15:25:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:25:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191217994"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 10:25:36 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnqqV-0007wA-S5;
	Mon, 10 Nov 2014 15:25:35 +0000
Date: Mon, 10 Nov 2014 15:25:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141110152535.GA6110@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460D342.9090308@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
> On 11/10/2014 07:35 AM, Wei Liu wrote:
> > I see. At that point the configuration was not available, yet. After the
> > domain is successfully migrated, the configuration should be available.
> > 
> > I think a domain under construction without domain configuration is a
> > valid state. What do you think?
> 
> Here is my thought:
> 
> 1. In this design, if I watch xenstore @introduceDomain, it will not been
>    triggered until migration finish.
> 

OK. What in this design makes behavior different than before? Are you
suggesting "xl list -l" has something to do with your xenstore watch? I
don't think I can get this.

My guess is that, you have some tool that watches @introduceDomain,
which happens *before* the domain creation is finished. And your tool
needs to get domain information once your watch fires.  Here with this
design, your tool cannot get the correct information until migration is
finished. Am I right?

However, in previous design, even if you manage to get configuration
before migration is finished, I don't think that configuration reflects
the true configuration of that domain. It's conceptually bogus.

In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
domain is started, so using it for that purpose would be wrong.

> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
>    domain state, we need to define what does it mean by "VM started".
> 

If my above analysis is correct, will some kind of @startDomain event solve
your problem?

But this involves making changes to Xenstore protocol. Let's not go into
details until we make sure your requirement is well understood.

Wei.

> 3. It looks like a inconsistent state and we may want to eliminate or keep
>    it as short as possible.
> 
> Thanks,
> 
> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:25:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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.xen.org>)
	id 1Xnqqe-0000rE-PY; Mon, 10 Nov 2014 15:25: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 1Xnqqd-0000r7-VC
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:25:44 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	AA/E3-05632-7F8D0645; Mon, 10 Nov 2014 15:25:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415633139!11596352!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8276 invoked from network); 10 Nov 2014 15:25:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:25:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191217994"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 10:25:36 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnqqV-0007wA-S5;
	Mon, 10 Nov 2014 15:25:35 +0000
Date: Mon, 10 Nov 2014 15:25:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141110152535.GA6110@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460D342.9090308@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
> On 11/10/2014 07:35 AM, Wei Liu wrote:
> > I see. At that point the configuration was not available, yet. After the
> > domain is successfully migrated, the configuration should be available.
> > 
> > I think a domain under construction without domain configuration is a
> > valid state. What do you think?
> 
> Here is my thought:
> 
> 1. In this design, if I watch xenstore @introduceDomain, it will not been
>    triggered until migration finish.
> 

OK. What in this design makes behavior different than before? Are you
suggesting "xl list -l" has something to do with your xenstore watch? I
don't think I can get this.

My guess is that, you have some tool that watches @introduceDomain,
which happens *before* the domain creation is finished. And your tool
needs to get domain information once your watch fires.  Here with this
design, your tool cannot get the correct information until migration is
finished. Am I right?

However, in previous design, even if you manage to get configuration
before migration is finished, I don't think that configuration reflects
the true configuration of that domain. It's conceptually bogus.

In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
domain is started, so using it for that purpose would be wrong.

> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
>    domain state, we need to define what does it mean by "VM started".
> 

If my above analysis is correct, will some kind of @startDomain event solve
your problem?

But this involves making changes to Xenstore protocol. Let's not go into
details until we make sure your requirement is well understood.

Wei.

> 3. It looks like a inconsistent state and we may want to eliminate or keep
>    it as short as possible.
> 
> Thanks,
> 
> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:29:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:29:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnquD-00010C-I2; Mon, 10 Nov 2014 15:29:25 +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 1XnquC-000107-0H
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:29:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	14/94-09936-3D9D0645; Mon, 10 Nov 2014 15:29:23 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415633361!12743867!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30746 invoked from network); 10 Nov 2014 15:29:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 15:29:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAFTBEj016774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 15:29:12 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFTAgl016086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 15:29:11 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFTAQA012013; Mon, 10 Nov 2014 15:29:10 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 07:29:10 -0800
Message-ID: <5460D9C5.4020905@oracle.com>
Date: Mon, 10 Nov 2014 10:29:09 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com>
In-Reply-To: <1415623447.25176.12.camel@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 07:44 AM, Ian Campbell wrote:
> On Mon, 2014-11-10 at 12:37 +0000, Wei Liu wrote:
> 
>> Ian and Ian, any thought how this bug came into being? I think we should
>> fix this for 4.5, but I don't think I know enough of how memory target
>> is expected to behave.
>>
> 
> I'm confused by the description of what's going on, in particular the
> mixing of mem-max commands and target xenstore nodes (since the former
> doesn't really affect the latter).
> 
> How was the domain started (memory= and maxmem=).
> 
> What were static-max and target at the point?
> 
> What did they change to when xl mem-max was issued? 
> 
> What did you expect them to change to instead?

Sorry for the confusion I made. Here is the problem I encountered:

1. Start a VM with 'memory = 700'.
2. Doing 'xl mem-max <domid> 700' will cause a error.

My expectation: after I start a VM with 'memory = 700', I can do 'xl mem-max <domid> 700'.

A little analysis of the problem:

1. Error: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"

2. I find static-max always less then target memory in xenstore:

    /local/domain/3/memory/static-max = "716800" (memory_static_max)
    /local/domain/3/memory/target = "716801"     (memory_dynamic_max)

   which looks bogus.

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:29:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:29:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnquD-00010C-I2; Mon, 10 Nov 2014 15:29:25 +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 1XnquC-000107-0H
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:29:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	14/94-09936-3D9D0645; Mon, 10 Nov 2014 15:29:23 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415633361!12743867!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30746 invoked from network); 10 Nov 2014 15:29:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 15:29:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAFTBEj016774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 15:29:12 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFTAgl016086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 15:29:11 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFTAQA012013; Mon, 10 Nov 2014 15:29:10 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 07:29:10 -0800
Message-ID: <5460D9C5.4020905@oracle.com>
Date: Mon, 10 Nov 2014 10:29:09 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com>
In-Reply-To: <1415623447.25176.12.camel@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 07:44 AM, Ian Campbell wrote:
> On Mon, 2014-11-10 at 12:37 +0000, Wei Liu wrote:
> 
>> Ian and Ian, any thought how this bug came into being? I think we should
>> fix this for 4.5, but I don't think I know enough of how memory target
>> is expected to behave.
>>
> 
> I'm confused by the description of what's going on, in particular the
> mixing of mem-max commands and target xenstore nodes (since the former
> doesn't really affect the latter).
> 
> How was the domain started (memory= and maxmem=).
> 
> What were static-max and target at the point?
> 
> What did they change to when xl mem-max was issued? 
> 
> What did you expect them to change to instead?

Sorry for the confusion I made. Here is the problem I encountered:

1. Start a VM with 'memory = 700'.
2. Doing 'xl mem-max <domid> 700' will cause a error.

My expectation: after I start a VM with 'memory = 700', I can do 'xl mem-max <domid> 700'.

A little analysis of the problem:

1. Error: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"

2. I find static-max always less then target memory in xenstore:

    /local/domain/3/memory/static-max = "716800" (memory_static_max)
    /local/domain/3/memory/target = "716801"     (memory_dynamic_max)

   which looks bogus.

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:29:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:29:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnquN-00011V-V3; Mon, 10 Nov 2014 15:29:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xumengpanda@gmail.com>) id 1XnquM-000117-Dw
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 15:29:34 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	9B/D0-02699-DD9D0645; Mon, 10 Nov 2014 15:29:33 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415633371!12532984!1
X-Originating-IP: [209.85.214.179]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7643 invoked from network); 10 Nov 2014 15:29:32 -0000
Received: from mail-ob0-f179.google.com (HELO mail-ob0-f179.google.com)
	(209.85.214.179)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:29:32 -0000
Received: by mail-ob0-f179.google.com with SMTP id m8so5799662obr.38
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 07:29:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=20cqRnKyHqZNxLtyJN8NMdEhYTFtnsAcwkP+s2OztpM=;
	b=JPY589Fn+uNV/b3ifi4PWisqnA6DsEl7d7m1AsrBJ4QZJm1GlpYaP2jhnQgQvJEfAi
	XQ7uW4GT0fMAZZJnK+EF3KknU8pXQSjRwpZEQoYSC7jXC8QCXMLCkIi+Agw3aO66Z4TS
	+GRt2JoVDH41yO6sG+oQ+G9/ckR+a3G8WsI3mycgAUQQJ5tjvufck9uULhc/V3pfZiEl
	qgooFsVPt+VORoYCqh6HjICnItjIpjOvBYerUR5AJF79XzaooT5Zw92p4rAv+LgJEQnP
	Ulc8hFmtngH2CltcFj1X/KPYrJXzewotA8pRIY0l5povn2RInw8zgAUiz08kGpKxXjpP
	u4gA==
MIME-Version: 1.0
X-Received: by 10.182.4.10 with SMTP id g10mr27606205obg.35.1415633370875;
	Mon, 10 Nov 2014 07:29:30 -0800 (PST)
Received: by 10.76.23.231 with HTTP; Mon, 10 Nov 2014 07:29:30 -0800 (PST)
In-Reply-To: <5460B550.9000306@eu.citrix.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>
	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>
	<5460B550.9000306@eu.citrix.com>
Date: Mon, 10 Nov 2014 10:29:30 -0500
Message-ID: <CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3461063681650920111=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3461063681650920111==
Content-Type: multipart/alternative; boundary=001a1134a152340e17050782d433

--001a1134a152340e17050782d433
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm not sure if I should resend the patch just to change the commit log and
add the reason of why doing this.

I want to first add the reason. If I should resend the patch set, please
let me know.

2014-11-10 7:53 GMT-05:00 George Dunlap <george.dunlap@eu.citrix.com>:

> On 10/25/2014 03:16 PM, Meng Xu wrote:
>
>> Move call to rt_update_deadline from _alloc to _insert;
>>
>
The runq queue lock is not grabbed when  =E2=80=8Brt_update_deadline is cal=
led
in rt_alloc_vdata
function, which may cause race condition.



> Add lock in rt_vcpu_remove().
>>
>
rt_vcpu_remove
=E2=80=8B should grab the runq lock before remove the vcpu from runq; other=
wise,
race condition may happen.

=E2=80=8B


>
>> Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
>>
>
> This describes what the patch does, but not why.
>
> While it's nice to  have a summary of the technical changes the patch
> makes, that's information I can get from the patch itself. What's critica=
l
> is an explanation of *why* you are moving rt_update_deadline from _alloc =
to
> _insert.
>
> Having the information in the cover letter isn't enough, because that
> probably won't be available to someone going through the git history and
> trying to figure out why you made this change.


George, if I should resend the patch set, please let me know.

Thanks,

Meng=E2=80=8B




>
>
>  -George
>
>
>  ---
>>   xen/common/sched_rt.c |   12 +++++++-----
>>   1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
>> index b87c95b..f136724 100644
>> --- a/xen/common/sched_rt.c
>> +++ b/xen/common/sched_rt.c
>> @@ -508,7 +508,6 @@ static void *
>>   rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
>>   {
>>       struct rt_vcpu *svc;
>> -    s_time_t now =3D NOW();
>>         /* Allocate per-VCPU info */
>>       svc =3D xzalloc(struct rt_vcpu);
>> @@ -526,10 +525,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct
>> vcpu *vc, void *dd)
>>       if ( !is_idle_vcpu(vc) )
>>           svc->budget =3D RTDS_DEFAULT_BUDGET;
>>   -    ASSERT( now >=3D svc->cur_deadline );
>> -
>> -    rt_update_deadline(now, svc);
>> -
>>       return svc;
>>   }
>>   @@ -552,11 +547,15 @@ static void
>>   rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
>>   {
>>       struct rt_vcpu *svc =3D rt_vcpu(vc);
>> +    s_time_t now =3D NOW();
>>         /* not addlocate idle vcpu to dom vcpu list */
>>       if ( is_idle_vcpu(vc) )
>>           return;
>>   +    if ( now >=3D svc->cur_deadline )
>> +        rt_update_deadline(now, svc);
>> +
>>       if ( !__vcpu_on_q(svc) && vcpu_runnable(vc) && !vc->is_running )
>>           __runq_insert(ops, svc);
>>   @@ -573,11 +572,14 @@ rt_vcpu_remove(const struct scheduler *ops,
>> struct vcpu *vc)
>>   {
>>       struct rt_vcpu * const svc =3D rt_vcpu(vc);
>>       struct rt_dom * const sdom =3D svc->sdom;
>> +    spinlock_t *lock;
>>         BUG_ON( sdom =3D=3D NULL );
>>   +    lock =3D vcpu_schedule_lock_irq(vc);
>>       if ( __vcpu_on_q(svc) )
>>           __q_remove(svc);
>> +    vcpu_schedule_unlock_irq(lock, vc);
>>         if ( !is_idle_vcpu(vc) )
>>           list_del_init(&svc->sdom_elem);
>>
>
>


--=20


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a1134a152340e17050782d433
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">I&#=
39;m not sure if I should resend the patch just to change the commit log an=
d add the reason of why doing this.=C2=A0</div><div class=3D"gmail_default"=
 style=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"=
font-size:small">I want to first add the reason. If I should resend the pat=
ch set, please let me know.=C2=A0</div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">2014-11-10 7:53 GMT-05:00 George Dunlap <span dir=3D"=
ltr">&lt;<a href=3D"mailto:george.dunlap@eu.citrix.com" target=3D"_blank">g=
eorge.dunlap@eu.citrix.com</a>&gt;</span>:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=
=3D"">On 10/25/2014 03:16 PM, Meng Xu wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
Move call to rt_update_deadline from _alloc to _insert;<br></blockquote></s=
pan></blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"=
font-size:small">The runq queue lock is not grabbed when =C2=A0=E2=80=8Brt_=
update_deadline is called in=C2=A0<span style=3D"font-family:arial,sans-ser=
if;font-size:14.3999996185303px">rt_alloc_vdata function, which may cause r=
ace condition.</span></div><br></div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><spa=
n class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
Add lock in rt_vcpu_remove().<br></blockquote></span></blockquote><div><br>=
</div><div><span style=3D"font-family:arial,sans-serif;font-size:14.3999996=
185303px">rt_vcpu_remove<div class=3D"gmail_default" style=3D"font-size:sma=
ll;display:inline">=E2=80=8B should grab the runq lock before remove the vc=
pu from runq; otherwise, race condition may happen.</div></span></div><div>=
<span style=3D"font-family:arial,sans-serif;font-size:14.3999996185303px"><=
div class=3D"gmail_default" style=3D"font-size:small;display:inline"><br></=
div></span></div><div><span style=3D"font-family:arial,sans-serif">=E2=80=
=8B</span><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><span class=3D""><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<br>
Signed-off-by: Meng Xu &lt;<a href=3D"mailto:mengxu@cis.upenn.edu" target=
=3D"_blank">mengxu@cis.upenn.edu</a>&gt;<br>
</blockquote>
<br></span>
This describes what the patch does, but not why.<br>
<br>
While it&#39;s nice to=C2=A0 have a summary of the technical changes the pa=
tch=C2=A0 makes, that&#39;s information I can get from the patch itself. Wh=
at&#39;s critical is an explanation of *why* you are moving rt_update_deadl=
ine from _alloc to _insert.<br>
<br>
Having the information in the cover letter isn&#39;t enough, because that p=
robably won&#39;t be available to someone going through the git history and=
 trying to figure out why you made this change.</blockquote><div><br></div>=
<div><div class=3D"gmail_default" style=3D"font-size:small">George, if I sh=
ould resend the patch set, please let me know.</div><div class=3D"gmail_def=
ault" style=3D"font-size:small"><br></div><div class=3D"gmail_default" styl=
e=3D"font-size:small">Thanks,</div><div class=3D"gmail_default" style=3D"fo=
nt-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:sm=
all">Meng=E2=80=8B</div><br></div><div><br></div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><span class=3D""><font color=3D"#888888"><br>
<br>
=C2=A0-George</font></span><div class=3D""><div class=3D"h5"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
---<br>
=C2=A0 xen/common/sched_rt.c |=C2=A0 =C2=A012 +++++++-----<br>
=C2=A0 1 file changed, 7 insertions(+), 5 deletions(-)<br>
<br>
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c<br>
index b87c95b..f136724 100644<br>
--- a/xen/common/sched_rt.c<br>
+++ b/xen/common/sched_rt.c<br>
@@ -508,7 +508,6 @@ static void *<br>
=C2=A0 rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *d=
d)<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 struct rt_vcpu *svc;<br>
-=C2=A0 =C2=A0 s_time_t now =3D NOW();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Allocate per-VCPU info */<br>
=C2=A0 =C2=A0 =C2=A0 svc =3D xzalloc(struct rt_vcpu);<br>
@@ -526,10 +525,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcp=
u *vc, void *dd)<br>
=C2=A0 =C2=A0 =C2=A0 if ( !is_idle_vcpu(vc) )<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 svc-&gt;budget =3D RTDS_DEFAULT_BUDGET;<=
br>
=C2=A0 -=C2=A0 =C2=A0 ASSERT( now &gt;=3D svc-&gt;cur_deadline );<br>
-<br>
-=C2=A0 =C2=A0 rt_update_deadline(now, svc);<br>
-<br>
=C2=A0 =C2=A0 =C2=A0 return svc;<br>
=C2=A0 }<br>
=C2=A0 @@ -552,11 +547,15 @@ static void<br>
=C2=A0 rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 struct rt_vcpu *svc =3D rt_vcpu(vc);<br>
+=C2=A0 =C2=A0 s_time_t now =3D NOW();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* not addlocate idle vcpu to dom vcpu list */<=
br>
=C2=A0 =C2=A0 =C2=A0 if ( is_idle_vcpu(vc) )<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return;<br>
=C2=A0 +=C2=A0 =C2=A0 if ( now &gt;=3D svc-&gt;cur_deadline )<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 rt_update_deadline(now, svc);<br>
+<br>
=C2=A0 =C2=A0 =C2=A0 if ( !__vcpu_on_q(svc) &amp;&amp; vcpu_runnable(vc) &a=
mp;&amp; !vc-&gt;is_running )<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 __runq_insert(ops, svc);<br>
=C2=A0 @@ -573,11 +572,14 @@ rt_vcpu_remove(const struct scheduler *ops, st=
ruct vcpu *vc)<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 struct rt_vcpu * const svc =3D rt_vcpu(vc);<br>
=C2=A0 =C2=A0 =C2=A0 struct rt_dom * const sdom =3D svc-&gt;sdom;<br>
+=C2=A0 =C2=A0 spinlock_t *lock;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 BUG_ON( sdom =3D=3D NULL );<br>
=C2=A0 +=C2=A0 =C2=A0 lock =3D vcpu_schedule_lock_irq(vc);<br>
=C2=A0 =C2=A0 =C2=A0 if ( __vcpu_on_q(svc) )<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 __q_remove(svc);<br>
+=C2=A0 =C2=A0 vcpu_schedule_unlock_irq(lock, vc);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( !is_idle_vcpu(vc) )<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list_del_init(&amp;svc-&gt;sdom_elem)<u>=
</u>;<br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr"><br><br>-----------<br>Meng=
 Xu<br>PhD Student in Computer and Information Science<br>University of Pen=
nsylvania</div></div>
</div></div>

--001a1134a152340e17050782d433--


--===============3461063681650920111==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3461063681650920111==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 15:29:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:29:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnquN-00011V-V3; Mon, 10 Nov 2014 15:29:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xumengpanda@gmail.com>) id 1XnquM-000117-Dw
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 15:29:34 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	9B/D0-02699-DD9D0645; Mon, 10 Nov 2014 15:29:33 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415633371!12532984!1
X-Originating-IP: [209.85.214.179]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7643 invoked from network); 10 Nov 2014 15:29:32 -0000
Received: from mail-ob0-f179.google.com (HELO mail-ob0-f179.google.com)
	(209.85.214.179)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:29:32 -0000
Received: by mail-ob0-f179.google.com with SMTP id m8so5799662obr.38
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 07:29:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=20cqRnKyHqZNxLtyJN8NMdEhYTFtnsAcwkP+s2OztpM=;
	b=JPY589Fn+uNV/b3ifi4PWisqnA6DsEl7d7m1AsrBJ4QZJm1GlpYaP2jhnQgQvJEfAi
	XQ7uW4GT0fMAZZJnK+EF3KknU8pXQSjRwpZEQoYSC7jXC8QCXMLCkIi+Agw3aO66Z4TS
	+GRt2JoVDH41yO6sG+oQ+G9/ckR+a3G8WsI3mycgAUQQJ5tjvufck9uULhc/V3pfZiEl
	qgooFsVPt+VORoYCqh6HjICnItjIpjOvBYerUR5AJF79XzaooT5Zw92p4rAv+LgJEQnP
	Ulc8hFmtngH2CltcFj1X/KPYrJXzewotA8pRIY0l5povn2RInw8zgAUiz08kGpKxXjpP
	u4gA==
MIME-Version: 1.0
X-Received: by 10.182.4.10 with SMTP id g10mr27606205obg.35.1415633370875;
	Mon, 10 Nov 2014 07:29:30 -0800 (PST)
Received: by 10.76.23.231 with HTTP; Mon, 10 Nov 2014 07:29:30 -0800 (PST)
In-Reply-To: <5460B550.9000306@eu.citrix.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>
	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>
	<5460B550.9000306@eu.citrix.com>
Date: Mon, 10 Nov 2014 10:29:30 -0500
Message-ID: <CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3461063681650920111=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3461063681650920111==
Content-Type: multipart/alternative; boundary=001a1134a152340e17050782d433

--001a1134a152340e17050782d433
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm not sure if I should resend the patch just to change the commit log and
add the reason of why doing this.

I want to first add the reason. If I should resend the patch set, please
let me know.

2014-11-10 7:53 GMT-05:00 George Dunlap <george.dunlap@eu.citrix.com>:

> On 10/25/2014 03:16 PM, Meng Xu wrote:
>
>> Move call to rt_update_deadline from _alloc to _insert;
>>
>
The runq queue lock is not grabbed when  =E2=80=8Brt_update_deadline is cal=
led
in rt_alloc_vdata
function, which may cause race condition.



> Add lock in rt_vcpu_remove().
>>
>
rt_vcpu_remove
=E2=80=8B should grab the runq lock before remove the vcpu from runq; other=
wise,
race condition may happen.

=E2=80=8B


>
>> Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
>>
>
> This describes what the patch does, but not why.
>
> While it's nice to  have a summary of the technical changes the patch
> makes, that's information I can get from the patch itself. What's critica=
l
> is an explanation of *why* you are moving rt_update_deadline from _alloc =
to
> _insert.
>
> Having the information in the cover letter isn't enough, because that
> probably won't be available to someone going through the git history and
> trying to figure out why you made this change.


George, if I should resend the patch set, please let me know.

Thanks,

Meng=E2=80=8B




>
>
>  -George
>
>
>  ---
>>   xen/common/sched_rt.c |   12 +++++++-----
>>   1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
>> index b87c95b..f136724 100644
>> --- a/xen/common/sched_rt.c
>> +++ b/xen/common/sched_rt.c
>> @@ -508,7 +508,6 @@ static void *
>>   rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
>>   {
>>       struct rt_vcpu *svc;
>> -    s_time_t now =3D NOW();
>>         /* Allocate per-VCPU info */
>>       svc =3D xzalloc(struct rt_vcpu);
>> @@ -526,10 +525,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct
>> vcpu *vc, void *dd)
>>       if ( !is_idle_vcpu(vc) )
>>           svc->budget =3D RTDS_DEFAULT_BUDGET;
>>   -    ASSERT( now >=3D svc->cur_deadline );
>> -
>> -    rt_update_deadline(now, svc);
>> -
>>       return svc;
>>   }
>>   @@ -552,11 +547,15 @@ static void
>>   rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
>>   {
>>       struct rt_vcpu *svc =3D rt_vcpu(vc);
>> +    s_time_t now =3D NOW();
>>         /* not addlocate idle vcpu to dom vcpu list */
>>       if ( is_idle_vcpu(vc) )
>>           return;
>>   +    if ( now >=3D svc->cur_deadline )
>> +        rt_update_deadline(now, svc);
>> +
>>       if ( !__vcpu_on_q(svc) && vcpu_runnable(vc) && !vc->is_running )
>>           __runq_insert(ops, svc);
>>   @@ -573,11 +572,14 @@ rt_vcpu_remove(const struct scheduler *ops,
>> struct vcpu *vc)
>>   {
>>       struct rt_vcpu * const svc =3D rt_vcpu(vc);
>>       struct rt_dom * const sdom =3D svc->sdom;
>> +    spinlock_t *lock;
>>         BUG_ON( sdom =3D=3D NULL );
>>   +    lock =3D vcpu_schedule_lock_irq(vc);
>>       if ( __vcpu_on_q(svc) )
>>           __q_remove(svc);
>> +    vcpu_schedule_unlock_irq(lock, vc);
>>         if ( !is_idle_vcpu(vc) )
>>           list_del_init(&svc->sdom_elem);
>>
>
>


--=20


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a1134a152340e17050782d433
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">I&#=
39;m not sure if I should resend the patch just to change the commit log an=
d add the reason of why doing this.=C2=A0</div><div class=3D"gmail_default"=
 style=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"=
font-size:small">I want to first add the reason. If I should resend the pat=
ch set, please let me know.=C2=A0</div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">2014-11-10 7:53 GMT-05:00 George Dunlap <span dir=3D"=
ltr">&lt;<a href=3D"mailto:george.dunlap@eu.citrix.com" target=3D"_blank">g=
eorge.dunlap@eu.citrix.com</a>&gt;</span>:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=
=3D"">On 10/25/2014 03:16 PM, Meng Xu wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
Move call to rt_update_deadline from _alloc to _insert;<br></blockquote></s=
pan></blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"=
font-size:small">The runq queue lock is not grabbed when =C2=A0=E2=80=8Brt_=
update_deadline is called in=C2=A0<span style=3D"font-family:arial,sans-ser=
if;font-size:14.3999996185303px">rt_alloc_vdata function, which may cause r=
ace condition.</span></div><br></div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><spa=
n class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
Add lock in rt_vcpu_remove().<br></blockquote></span></blockquote><div><br>=
</div><div><span style=3D"font-family:arial,sans-serif;font-size:14.3999996=
185303px">rt_vcpu_remove<div class=3D"gmail_default" style=3D"font-size:sma=
ll;display:inline">=E2=80=8B should grab the runq lock before remove the vc=
pu from runq; otherwise, race condition may happen.</div></span></div><div>=
<span style=3D"font-family:arial,sans-serif;font-size:14.3999996185303px"><=
div class=3D"gmail_default" style=3D"font-size:small;display:inline"><br></=
div></span></div><div><span style=3D"font-family:arial,sans-serif">=E2=80=
=8B</span><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><span class=3D""><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<br>
Signed-off-by: Meng Xu &lt;<a href=3D"mailto:mengxu@cis.upenn.edu" target=
=3D"_blank">mengxu@cis.upenn.edu</a>&gt;<br>
</blockquote>
<br></span>
This describes what the patch does, but not why.<br>
<br>
While it&#39;s nice to=C2=A0 have a summary of the technical changes the pa=
tch=C2=A0 makes, that&#39;s information I can get from the patch itself. Wh=
at&#39;s critical is an explanation of *why* you are moving rt_update_deadl=
ine from _alloc to _insert.<br>
<br>
Having the information in the cover letter isn&#39;t enough, because that p=
robably won&#39;t be available to someone going through the git history and=
 trying to figure out why you made this change.</blockquote><div><br></div>=
<div><div class=3D"gmail_default" style=3D"font-size:small">George, if I sh=
ould resend the patch set, please let me know.</div><div class=3D"gmail_def=
ault" style=3D"font-size:small"><br></div><div class=3D"gmail_default" styl=
e=3D"font-size:small">Thanks,</div><div class=3D"gmail_default" style=3D"fo=
nt-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:sm=
all">Meng=E2=80=8B</div><br></div><div><br></div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><span class=3D""><font color=3D"#888888"><br>
<br>
=C2=A0-George</font></span><div class=3D""><div class=3D"h5"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
---<br>
=C2=A0 xen/common/sched_rt.c |=C2=A0 =C2=A012 +++++++-----<br>
=C2=A0 1 file changed, 7 insertions(+), 5 deletions(-)<br>
<br>
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c<br>
index b87c95b..f136724 100644<br>
--- a/xen/common/sched_rt.c<br>
+++ b/xen/common/sched_rt.c<br>
@@ -508,7 +508,6 @@ static void *<br>
=C2=A0 rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *d=
d)<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 struct rt_vcpu *svc;<br>
-=C2=A0 =C2=A0 s_time_t now =3D NOW();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Allocate per-VCPU info */<br>
=C2=A0 =C2=A0 =C2=A0 svc =3D xzalloc(struct rt_vcpu);<br>
@@ -526,10 +525,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcp=
u *vc, void *dd)<br>
=C2=A0 =C2=A0 =C2=A0 if ( !is_idle_vcpu(vc) )<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 svc-&gt;budget =3D RTDS_DEFAULT_BUDGET;<=
br>
=C2=A0 -=C2=A0 =C2=A0 ASSERT( now &gt;=3D svc-&gt;cur_deadline );<br>
-<br>
-=C2=A0 =C2=A0 rt_update_deadline(now, svc);<br>
-<br>
=C2=A0 =C2=A0 =C2=A0 return svc;<br>
=C2=A0 }<br>
=C2=A0 @@ -552,11 +547,15 @@ static void<br>
=C2=A0 rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 struct rt_vcpu *svc =3D rt_vcpu(vc);<br>
+=C2=A0 =C2=A0 s_time_t now =3D NOW();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* not addlocate idle vcpu to dom vcpu list */<=
br>
=C2=A0 =C2=A0 =C2=A0 if ( is_idle_vcpu(vc) )<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return;<br>
=C2=A0 +=C2=A0 =C2=A0 if ( now &gt;=3D svc-&gt;cur_deadline )<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 rt_update_deadline(now, svc);<br>
+<br>
=C2=A0 =C2=A0 =C2=A0 if ( !__vcpu_on_q(svc) &amp;&amp; vcpu_runnable(vc) &a=
mp;&amp; !vc-&gt;is_running )<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 __runq_insert(ops, svc);<br>
=C2=A0 @@ -573,11 +572,14 @@ rt_vcpu_remove(const struct scheduler *ops, st=
ruct vcpu *vc)<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 struct rt_vcpu * const svc =3D rt_vcpu(vc);<br>
=C2=A0 =C2=A0 =C2=A0 struct rt_dom * const sdom =3D svc-&gt;sdom;<br>
+=C2=A0 =C2=A0 spinlock_t *lock;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 BUG_ON( sdom =3D=3D NULL );<br>
=C2=A0 +=C2=A0 =C2=A0 lock =3D vcpu_schedule_lock_irq(vc);<br>
=C2=A0 =C2=A0 =C2=A0 if ( __vcpu_on_q(svc) )<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 __q_remove(svc);<br>
+=C2=A0 =C2=A0 vcpu_schedule_unlock_irq(lock, vc);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( !is_idle_vcpu(vc) )<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list_del_init(&amp;svc-&gt;sdom_elem)<u>=
</u>;<br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr"><br><br>-----------<br>Meng=
 Xu<br>PhD Student in Computer and Information Science<br>University of Pen=
nsylvania</div></div>
</div></div>

--001a1134a152340e17050782d433--


--===============3461063681650920111==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3461063681650920111==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 15:30:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqvV-0001AK-If; Mon, 10 Nov 2014 15:30:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnqvU-0001AA-M5
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:30:44 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	D3/0B-02954-42AD0645; Mon, 10 Nov 2014 15:30:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415633440!12533300!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18280 invoked from network); 10 Nov 2014 15:30:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:30:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191219854"
Message-ID: <1415633435.25176.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Mon, 10 Nov 2014 15:30:35 +0000
In-Reply-To: <5460D9C5.4020905@oracle.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com> <5460D9C5.4020905@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 10:29 -0500, Zhigang Wang wrote:
> On 11/10/2014 07:44 AM, Ian Campbell wrote:
> > On Mon, 2014-11-10 at 12:37 +0000, Wei Liu wrote:
> > 
> >> Ian and Ian, any thought how this bug came into being? I think we should
> >> fix this for 4.5, but I don't think I know enough of how memory target
> >> is expected to behave.
> >>
> > 
> > I'm confused by the description of what's going on, in particular the
> > mixing of mem-max commands and target xenstore nodes (since the former
> > doesn't really affect the latter).
> > 
> > How was the domain started (memory= and maxmem=).
> > 
> > What were static-max and target at the point?
> > 
> > What did they change to when xl mem-max was issued? 
> > 
> > What did you expect them to change to instead?
> 
> Sorry for the confusion I made. Here is the problem I encountered:

This is just restating what was upthread, which, as I say, is confusing
to me.

Please can you just answer the 4 questions I asked and we can take it
from there.

> 
> 1. Start a VM with 'memory = 700'.
> 2. Doing 'xl mem-max <domid> 700' will cause a error.
> 
> My expectation: after I start a VM with 'memory = 700', I can do 'xl mem-max <domid> 700'.
> 
> A little analysis of the problem:
> 
> 1. Error: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"
> 
> 2. I find static-max always less then target memory in xenstore:
> 
>     /local/domain/3/memory/static-max = "716800" (memory_static_max)
>     /local/domain/3/memory/target = "716801"     (memory_dynamic_max)
> 
>    which looks bogus.
> 
> Thanks,
> 
> Zhigang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:30:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnqvV-0001AK-If; Mon, 10 Nov 2014 15:30:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XnqvU-0001AA-M5
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:30:44 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	D3/0B-02954-42AD0645; Mon, 10 Nov 2014 15:30:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415633440!12533300!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18280 invoked from network); 10 Nov 2014 15:30:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:30:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191219854"
Message-ID: <1415633435.25176.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Mon, 10 Nov 2014 15:30:35 +0000
In-Reply-To: <5460D9C5.4020905@oracle.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com> <5460D9C5.4020905@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 10:29 -0500, Zhigang Wang wrote:
> On 11/10/2014 07:44 AM, Ian Campbell wrote:
> > On Mon, 2014-11-10 at 12:37 +0000, Wei Liu wrote:
> > 
> >> Ian and Ian, any thought how this bug came into being? I think we should
> >> fix this for 4.5, but I don't think I know enough of how memory target
> >> is expected to behave.
> >>
> > 
> > I'm confused by the description of what's going on, in particular the
> > mixing of mem-max commands and target xenstore nodes (since the former
> > doesn't really affect the latter).
> > 
> > How was the domain started (memory= and maxmem=).
> > 
> > What were static-max and target at the point?
> > 
> > What did they change to when xl mem-max was issued? 
> > 
> > What did you expect them to change to instead?
> 
> Sorry for the confusion I made. Here is the problem I encountered:

This is just restating what was upthread, which, as I say, is confusing
to me.

Please can you just answer the 4 questions I asked and we can take it
from there.

> 
> 1. Start a VM with 'memory = 700'.
> 2. Doing 'xl mem-max <domid> 700' will cause a error.
> 
> My expectation: after I start a VM with 'memory = 700', I can do 'xl mem-max <domid> 700'.
> 
> A little analysis of the problem:
> 
> 1. Error: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"
> 
> 2. I find static-max always less then target memory in xenstore:
> 
>     /local/domain/3/memory/static-max = "716800" (memory_static_max)
>     /local/domain/3/memory/target = "716801"     (memory_dynamic_max)
> 
>    which looks bogus.
> 
> Thanks,
> 
> Zhigang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:37:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15: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 1Xnr1Y-0001W7-Bt; Mon, 10 Nov 2014 15:37:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1Xnr1X-0001W2-A1
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 15:36:59 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	07/3B-24859-A9BD0645; Mon, 10 Nov 2014 15:36:58 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415633805!11612965!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTk2MDcgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21054 invoked from network); 10 Nov 2014 15:36:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:36:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; 
	d="asc'?scan'208";a="189783105"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 10:36:41 -0500
Message-ID: <1415633819.3717.43.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Meng Xu <xumengpanda@gmail.com>
Date: Mon, 10 Nov 2014 16:36:59 +0100
In-Reply-To: <CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>
	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>
	<5460B550.9000306@eu.citrix.com>
	<CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
 in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1537386581569102566=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1537386581569102566==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Oxnsd6Zc8DIvaqpFnNKj"

--=-Oxnsd6Zc8DIvaqpFnNKj
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-10 at 10:29 -0500, Meng Xu wrote:
> I'm not sure if I should resend the patch just to change the commit
> log and add the reason of why doing this.=20
>=20
Yes, that is usually quite a good reason, as changelogs are really
important (for the reasons George pointed out already).

Sometimes, maintainers and committers do the edits themselves (after
asking or at least informing the mailing list), but this only happens
for minor and not substantial modifications.

In this case, the most correct thing is that you resend.


> George, if I should resend the patch set, please let me know.
>=20
I'm not George but, yes, please, do resend. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Oxnsd6Zc8DIvaqpFnNKj
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 v2

iEYEABECAAYFAlRg25wACgkQk4XaBE3IOsREbACgo65Oj7uHkx/H5Our90OeN1R2
/gkAnApNeaLCD5Ys3y6BkznJvGmzyDdm
=Do8J
-----END PGP SIGNATURE-----

--=-Oxnsd6Zc8DIvaqpFnNKj--


--===============1537386581569102566==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1537386581569102566==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 15:37:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15: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 1Xnr1Y-0001W7-Bt; Mon, 10 Nov 2014 15:37:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1Xnr1X-0001W2-A1
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 15:36:59 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	07/3B-24859-A9BD0645; Mon, 10 Nov 2014 15:36:58 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415633805!11612965!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTk2MDcgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21054 invoked from network); 10 Nov 2014 15:36:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:36:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; 
	d="asc'?scan'208";a="189783105"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 10:36:41 -0500
Message-ID: <1415633819.3717.43.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Meng Xu <xumengpanda@gmail.com>
Date: Mon, 10 Nov 2014 16:36:59 +0100
In-Reply-To: <CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>
	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>
	<5460B550.9000306@eu.citrix.com>
	<CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
 in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1537386581569102566=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1537386581569102566==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Oxnsd6Zc8DIvaqpFnNKj"

--=-Oxnsd6Zc8DIvaqpFnNKj
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-10 at 10:29 -0500, Meng Xu wrote:
> I'm not sure if I should resend the patch just to change the commit
> log and add the reason of why doing this.=20
>=20
Yes, that is usually quite a good reason, as changelogs are really
important (for the reasons George pointed out already).

Sometimes, maintainers and committers do the edits themselves (after
asking or at least informing the mailing list), but this only happens
for minor and not substantial modifications.

In this case, the most correct thing is that you resend.


> George, if I should resend the patch set, please let me know.
>=20
I'm not George but, yes, please, do resend. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Oxnsd6Zc8DIvaqpFnNKj
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 v2

iEYEABECAAYFAlRg25wACgkQk4XaBE3IOsREbACgo65Oj7uHkx/H5Our90OeN1R2
/gkAnApNeaLCD5Ys3y6BkznJvGmzyDdm
=Do8J
-----END PGP SIGNATURE-----

--=-Oxnsd6Zc8DIvaqpFnNKj--


--===============1537386581569102566==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1537386581569102566==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 15:38:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:38:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnr2x-0001aL-Sc; Mon, 10 Nov 2014 15:38:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xnr2w-0001aE-Kb
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 15:38:26 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	CC/5A-27623-1FBD0645; Mon, 10 Nov 2014 15:38:25 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415633901!7870359!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14813 invoked from network); 10 Nov 2014 15:38:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:38:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189783714"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 10:38:17 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xnr2n-0008CI-29;
	Mon, 10 Nov 2014 15:38:17 +0000
Message-ID: <5460DBE8.4060701@eu.citrix.com>
Date: Mon, 10 Nov 2014 15:38:16 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>, Meng Xu <xumengpanda@gmail.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>	
	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>	
	<5460B550.9000306@eu.citrix.com>	
	<CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
	<1415633819.3717.43.camel@Abyss>
In-Reply-To: <1415633819.3717.43.camel@Abyss>
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 03:36 PM, Dario Faggioli wrote:
> On Mon, 2014-11-10 at 10:29 -0500, Meng Xu wrote:
>> I'm not sure if I should resend the patch just to change the commit
>> log and add the reason of why doing this.
>>
> Yes, that is usually quite a good reason, as changelogs are really
> important (for the reasons George pointed out already).
>
> Sometimes, maintainers and committers do the edits themselves (after
> asking or at least informing the mailing list), but this only happens
> for minor and not substantial modifications.
>
> In this case, the most correct thing is that you resend.
>
>
>> George, if I should resend the patch set, please let me know.
>>
> I'm not George but, yes, please, do resend. :-)

What Dario said. :-)

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:38:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:38:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnr2x-0001aL-Sc; Mon, 10 Nov 2014 15:38:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xnr2w-0001aE-Kb
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 15:38:26 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	CC/5A-27623-1FBD0645; Mon, 10 Nov 2014 15:38:25 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415633901!7870359!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14813 invoked from network); 10 Nov 2014 15:38:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:38:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189783714"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 10:38:17 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xnr2n-0008CI-29;
	Mon, 10 Nov 2014 15:38:17 +0000
Message-ID: <5460DBE8.4060701@eu.citrix.com>
Date: Mon, 10 Nov 2014 15:38:16 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>, Meng Xu <xumengpanda@gmail.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>	
	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>	
	<5460B550.9000306@eu.citrix.com>	
	<CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
	<1415633819.3717.43.camel@Abyss>
In-Reply-To: <1415633819.3717.43.camel@Abyss>
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 03:36 PM, Dario Faggioli wrote:
> On Mon, 2014-11-10 at 10:29 -0500, Meng Xu wrote:
>> I'm not sure if I should resend the patch just to change the commit
>> log and add the reason of why doing this.
>>
> Yes, that is usually quite a good reason, as changelogs are really
> important (for the reasons George pointed out already).
>
> Sometimes, maintainers and committers do the edits themselves (after
> asking or at least informing the mailing list), but this only happens
> for minor and not substantial modifications.
>
> In this case, the most correct thing is that you resend.
>
>
>> George, if I should resend the patch set, please let me know.
>>
> I'm not George but, yes, please, do resend. :-)

What Dario said. :-)

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:38:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnr37-0001cA-7i; Mon, 10 Nov 2014 15:38:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1Xnr36-0001bv-R6
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 15:38:36 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	8B/2A-02697-CFBD0645; Mon, 10 Nov 2014 15:38:36 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415633903!11570705!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNjU1NDAgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4931 invoked from network); 10 Nov 2014 15:38:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:38:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; 
	d="asc'?scan'208";a="191223160"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 10:38:22 -0500
Message-ID: <1415633922.3717.44.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 16:38:42 +0100
In-Reply-To: <20141110134310.GA32371@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<20141110134310.GA32371@zion.uk.xensource.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jan Beulich <jbeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3259760887219070940=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3259760887219070940==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-bFbuxx1MbueT1xvssKYO"

--=-bFbuxx1MbueT1xvssKYO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-10 at 13:43 +0000, Wei Liu wrote:
> To summarise this discussion so far.
>=20
> Conceptually speaking, the guest should not need to know the mapping.
> The translation from vnode to pnode should happen in hypervisor without
> guest knowing.
>=20
> Jan, Dario and David (and I) are all in favor of *not* exposing the
> mapping (though starting from different angle). So we should go with
> this approach. The hypercall interface is fine as it is now.
>=20
+1

And thanks for the summary.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-bFbuxx1MbueT1xvssKYO
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 v2

iEYEABECAAYFAlRg3AIACgkQk4XaBE3IOsRR9ACcDKHzz2l8p5bNDFlHpzK9e7YA
SV4AnizI1JSSgE0BU1EvyDRfCGvftcln
=vqGw
-----END PGP SIGNATURE-----

--=-bFbuxx1MbueT1xvssKYO--


--===============3259760887219070940==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3259760887219070940==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 15:38:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnr37-0001cA-7i; Mon, 10 Nov 2014 15:38:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1Xnr36-0001bv-R6
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 15:38:36 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	8B/2A-02697-CFBD0645; Mon, 10 Nov 2014 15:38:36 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415633903!11570705!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNjU1NDAgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4931 invoked from network); 10 Nov 2014 15:38:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:38:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; 
	d="asc'?scan'208";a="191223160"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 10:38:22 -0500
Message-ID: <1415633922.3717.44.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 10 Nov 2014 16:38:42 +0100
In-Reply-To: <20141110134310.GA32371@zion.uk.xensource.com>
References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com>
	<20141110134310.GA32371@zion.uk.xensource.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jan Beulich <jbeulich@suse.com>, Elena Ufimtseva <ufimtseva@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode
	to guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3259760887219070940=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3259760887219070940==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-bFbuxx1MbueT1xvssKYO"

--=-bFbuxx1MbueT1xvssKYO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-10 at 13:43 +0000, Wei Liu wrote:
> To summarise this discussion so far.
>=20
> Conceptually speaking, the guest should not need to know the mapping.
> The translation from vnode to pnode should happen in hypervisor without
> guest knowing.
>=20
> Jan, Dario and David (and I) are all in favor of *not* exposing the
> mapping (though starting from different angle). So we should go with
> this approach. The hypercall interface is fine as it is now.
>=20
+1

And thanks for the summary.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-bFbuxx1MbueT1xvssKYO
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 v2

iEYEABECAAYFAlRg3AIACgkQk4XaBE3IOsRR9ACcDKHzz2l8p5bNDFlHpzK9e7YA
SV4AnizI1JSSgE0BU1EvyDRfCGvftcln
=vqGw
-----END PGP SIGNATURE-----

--=-bFbuxx1MbueT1xvssKYO--


--===============3259760887219070940==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3259760887219070940==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 15:38:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnr37-0001cP-Ka; Mon, 10 Nov 2014 15:38:37 +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 1Xnr37-0001by-0J
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:38:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/B6-24532-CFBD0645; Mon, 10 Nov 2014 15:38:36 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415633914!12777192!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32590 invoked from network); 10 Nov 2014 15:38:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 15:38:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAFcPeq031431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 15:38:26 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFcOU3021426
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 15:38:25 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFcORU021416; Mon, 10 Nov 2014 15:38:24 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 07:38:24 -0800
Message-ID: <5460DBEF.5000504@oracle.com>
Date: Mon, 10 Nov 2014 10:38:23 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com>
	<5460D9C5.4020905@oracle.com>
	<1415633435.25176.27.camel@citrix.com>
In-Reply-To: <1415633435.25176.27.camel@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max 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

OK. Let me try my best:

>>> I'm confused by the description of what's going on, in particular the
>>> mixing of mem-max commands and target xenstore nodes (since the former
>>> doesn't really affect the latter).
>>>
>>> How was the domain started (memory= and maxmem=).

xl create with 'memory = 700', no maxmem been set. I think it means maxmem = memory for this case.

>>> What were static-max and target at the point?

     /local/domain/3/memory/static-max = "716800"
     /local/domain/3/memory/target = "716801"

>>> What did they change to when xl mem-max was issued? 

When I issue 'xl mem-max <domid> 700', static-max and target in xenstore will not change, but it will cause the command to fail.

Because: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"

>>> What did you expect them to change to instead?

I expect I can set the maxmem to the same value I initially set (700).

Thanks,

Zhigang

>>
>> Sorry for the confusion I made. Here is the problem I encountered:
> 
> This is just restating what was upthread, which, as I say, is confusing
> to me.
> 
> Please can you just answer the 4 questions I asked and we can take it
> from there.
> 
>>
>> 1. Start a VM with 'memory = 700'.
>> 2. Doing 'xl mem-max <domid> 700' will cause a error.
>>
>> My expectation: after I start a VM with 'memory = 700', I can do 'xl mem-max <domid> 700'.
>>
>> A little analysis of the problem:
>>
>> 1. Error: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"
>>
>> 2. I find static-max always less then target memory in xenstore:
>>
>>     /local/domain/3/memory/static-max = "716800" (memory_static_max)
>>     /local/domain/3/memory/target = "716801"     (memory_dynamic_max)
>>
>>    which looks bogus.
>>
>> Thanks,
>>
>> Zhigang
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:38:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnr37-0001cP-Ka; Mon, 10 Nov 2014 15:38:37 +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 1Xnr37-0001by-0J
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 15:38:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/B6-24532-CFBD0645; Mon, 10 Nov 2014 15:38:36 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415633914!12777192!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32590 invoked from network); 10 Nov 2014 15:38:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 15:38:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAFcPeq031431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 15:38:26 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFcOU3021426
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 15:38:25 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAFcORU021416; Mon, 10 Nov 2014 15:38:24 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 07:38:24 -0800
Message-ID: <5460DBEF.5000504@oracle.com>
Date: Mon, 10 Nov 2014 10:38:23 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com>
	<5460D9C5.4020905@oracle.com>
	<1415633435.25176.27.camel@citrix.com>
In-Reply-To: <1415633435.25176.27.camel@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max 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

OK. Let me try my best:

>>> I'm confused by the description of what's going on, in particular the
>>> mixing of mem-max commands and target xenstore nodes (since the former
>>> doesn't really affect the latter).
>>>
>>> How was the domain started (memory= and maxmem=).

xl create with 'memory = 700', no maxmem been set. I think it means maxmem = memory for this case.

>>> What were static-max and target at the point?

     /local/domain/3/memory/static-max = "716800"
     /local/domain/3/memory/target = "716801"

>>> What did they change to when xl mem-max was issued? 

When I issue 'xl mem-max <domid> 700', static-max and target in xenstore will not change, but it will cause the command to fail.

Because: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"

>>> What did you expect them to change to instead?

I expect I can set the maxmem to the same value I initially set (700).

Thanks,

Zhigang

>>
>> Sorry for the confusion I made. Here is the problem I encountered:
> 
> This is just restating what was upthread, which, as I say, is confusing
> to me.
> 
> Please can you just answer the 4 questions I asked and we can take it
> from there.
> 
>>
>> 1. Start a VM with 'memory = 700'.
>> 2. Doing 'xl mem-max <domid> 700' will cause a error.
>>
>> My expectation: after I start a VM with 'memory = 700', I can do 'xl mem-max <domid> 700'.
>>
>> A little analysis of the problem:
>>
>> 1. Error: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"
>>
>> 2. I find static-max always less then target memory in xenstore:
>>
>>     /local/domain/3/memory/static-max = "716800" (memory_static_max)
>>     /local/domain/3/memory/target = "716801"     (memory_dynamic_max)
>>
>>    which looks bogus.
>>
>> Thanks,
>>
>> Zhigang
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 15:40:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnr52-0001uw-7B; Mon, 10 Nov 2014 15:40:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xnr51-0001uk-3P
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 15:40:35 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	ED/5A-26740-27CD0645; Mon, 10 Nov 2014 15:40:34 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415634030!11646032!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25537 invoked from network); 10 Nov 2014 15:40:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:40:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; 
	d="scan'208,217";a="191223830"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 10:40:22 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xnr4o-0008EA-BU;
	Mon, 10 Nov 2014 15:40:22 +0000
Message-ID: <5460DC65.8000909@eu.citrix.com>
Date: Mon, 10 Nov 2014 15:40:21 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Meng Xu <xumengpanda@gmail.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>	<5460B550.9000306@eu.citrix.com>
	<CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
In-Reply-To: <CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1813549635048471484=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1813549635048471484==
Content-Type: multipart/alternative;
	boundary="------------070602050202010107060601"

--------------070602050202010107060601
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Length: 933
Content-Transfer-Encoding: quoted-printable

On 11/10/2014 03:29 PM, Meng Xu wrote:
> I'm not sure if I should resend the patch just to change the commit 
> log and add the reason of why doing this.
>
> I want to first add the reason. If I should resend the patch set, 
> please let me know.
>
> 2014-11-10 7:53 GMT-05:00 George Dunlap <george.dunlap@eu.citrix.com 
> <mailto:george.dunlap@eu.citrix.com>>:
>
>     On 10/25/2014 03:16 PM, Meng Xu wrote:
>
>         Move call to rt_update_deadline from _alloc to _insert;
>
>
> The runq queue lock is not grabbed when  =E2=80=8Brt_update_deadline is called 
> in rt_alloc_vdata function, which may cause race condition.

Can you not grab the lock in rt_alloc_vdata=3F  Or do you think it's just 
more efficient to do all the work you need all at once=3F

(I'm not suggesting a change to the code, I'm just trying to clarify the 
motivation for moving the code rather than adding a lock.)

  -George


--------------070602050202010107060601
Content-Type: text/html; charset="utf-8"
Content-Length: 2794
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 11/10/2014 03:29 PM, Meng Xu wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=3DxoqUP9Sg@mail.gmail.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
      <div dir=3D"ltr">
        <div class=3D"gmail_default" style=3D"font-size:small">I'm not sure
          if I should resend the patch just to change the commit log and
          add the reason of why doing this.=C2=A0</div>
        <div class=3D"gmail_default" style=3D"font-size:small"><br>
        </div>
        <div class=3D"gmail_default" style=3D"font-size:small">I want to
          first add the reason. If I should resend the patch set, please
          let me know.=C2=A0</div>
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">2014-11-10 7:53 GMT-05:00 George
            Dunlap <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:george.dunlap@eu.citrix.com"
                target=3D"_blank">george.dunlap@eu.citrix.com</a>&gt;</span>:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
                class=3D"">On 10/25/2014 03:16 PM, Meng Xu wrote:<br>
                <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px
                  0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Move
                  call to rt_update_deadline from _alloc to _insert;<br>
                </blockquote>
              </span></blockquote>
            <div><br>
            </div>
            <div>
              <div class=3D"gmail_default" style=3D"font-size:small">The
                runq queue lock is not grabbed when =C2=A0=E2=80=8Brt_update_deadline
                is called in=C2=A0<span
                  style=3D"font-family:arial,sans-serif;font-size:14.3999996185303px">rt_alloc_vdata
                  function, which may cause race condition.</span></div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Can you not grab the lock in rt_alloc_vdata=3F=C2=A0 Or do you think it's
    just more efficient to do all the work you need all at once=3F<br>
    <br>
    (I'm not suggesting a change to the code, I'm just trying to clarify
    the motivation for moving the code rather than adding a lock.)<br>
    <br>
    =C2=A0-George<br>
    <br>
  </body>
</html>

--------------070602050202010107060601--


--===============1813549635048471484==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1813549635048471484==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 15:40:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 15:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnr52-0001uw-7B; Mon, 10 Nov 2014 15:40:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xnr51-0001uk-3P
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 15:40:35 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	ED/5A-26740-27CD0645; Mon, 10 Nov 2014 15:40:34 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415634030!11646032!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25537 invoked from network); 10 Nov 2014 15:40:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 15:40:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; 
	d="scan'208,217";a="191223830"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 10:40:22 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xnr4o-0008EA-BU;
	Mon, 10 Nov 2014 15:40:22 +0000
Message-ID: <5460DC65.8000909@eu.citrix.com>
Date: Mon, 10 Nov 2014 15:40:21 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Meng Xu <xumengpanda@gmail.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>	<5460B550.9000306@eu.citrix.com>
	<CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
In-Reply-To: <CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1813549635048471484=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1813549635048471484==
Content-Type: multipart/alternative;
	boundary="------------070602050202010107060601"

--------------070602050202010107060601
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Length: 933
Content-Transfer-Encoding: quoted-printable

On 11/10/2014 03:29 PM, Meng Xu wrote:
> I'm not sure if I should resend the patch just to change the commit 
> log and add the reason of why doing this.
>
> I want to first add the reason. If I should resend the patch set, 
> please let me know.
>
> 2014-11-10 7:53 GMT-05:00 George Dunlap <george.dunlap@eu.citrix.com 
> <mailto:george.dunlap@eu.citrix.com>>:
>
>     On 10/25/2014 03:16 PM, Meng Xu wrote:
>
>         Move call to rt_update_deadline from _alloc to _insert;
>
>
> The runq queue lock is not grabbed when  =E2=80=8Brt_update_deadline is called 
> in rt_alloc_vdata function, which may cause race condition.

Can you not grab the lock in rt_alloc_vdata=3F  Or do you think it's just 
more efficient to do all the work you need all at once=3F

(I'm not suggesting a change to the code, I'm just trying to clarify the 
motivation for moving the code rather than adding a lock.)

  -George


--------------070602050202010107060601
Content-Type: text/html; charset="utf-8"
Content-Length: 2794
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 11/10/2014 03:29 PM, Meng Xu wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=3DxoqUP9Sg@mail.gmail.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
      <div dir=3D"ltr">
        <div class=3D"gmail_default" style=3D"font-size:small">I'm not sure
          if I should resend the patch just to change the commit log and
          add the reason of why doing this.=C2=A0</div>
        <div class=3D"gmail_default" style=3D"font-size:small"><br>
        </div>
        <div class=3D"gmail_default" style=3D"font-size:small">I want to
          first add the reason. If I should resend the patch set, please
          let me know.=C2=A0</div>
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">2014-11-10 7:53 GMT-05:00 George
            Dunlap <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:george.dunlap@eu.citrix.com"
                target=3D"_blank">george.dunlap@eu.citrix.com</a>&gt;</span>:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
                class=3D"">On 10/25/2014 03:16 PM, Meng Xu wrote:<br>
                <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px
                  0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Move
                  call to rt_update_deadline from _alloc to _insert;<br>
                </blockquote>
              </span></blockquote>
            <div><br>
            </div>
            <div>
              <div class=3D"gmail_default" style=3D"font-size:small">The
                runq queue lock is not grabbed when =C2=A0=E2=80=8Brt_update_deadline
                is called in=C2=A0<span
                  style=3D"font-family:arial,sans-serif;font-size:14.3999996185303px">rt_alloc_vdata
                  function, which may cause race condition.</span></div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Can you not grab the lock in rt_alloc_vdata=3F=C2=A0 Or do you think it's
    just more efficient to do all the work you need all at once=3F<br>
    <br>
    (I'm not suggesting a change to the code, I'm just trying to clarify
    the motivation for moving the code rather than adding a lock.)<br>
    <br>
    =C2=A0-George<br>
    <br>
  </body>
</html>

--------------070602050202010107060601--


--===============1813549635048471484==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1813549635048471484==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 16:04:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:04:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnrS8-0002tL-M9; Mon, 10 Nov 2014 16:04:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xumengpanda@gmail.com>) id 1XnrS7-0002tG-5W
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 16:04:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C5/A8-09842-A02E0645; Mon, 10 Nov 2014 16:04:26 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415635464!12753268!1
X-Originating-IP: [209.85.214.180]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6054 invoked from network); 10 Nov 2014 16:04:25 -0000
Received: from mail-ob0-f180.google.com (HELO mail-ob0-f180.google.com)
	(209.85.214.180)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:04:25 -0000
Received: by mail-ob0-f180.google.com with SMTP id wp4so5914921obc.11
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 08:04:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=VBiaLg2b02rJ1b62Sj0SwGKR8MFoHaRyUvvWn9hfzUQ=;
	b=pTPfQ6E7N0kUohPEgJ4exHqF6BPcCrioPl8xc4ho6LVdFHdIvMdmU2QZbL1OtSMzgT
	TmbXfD9i3aObXss+UaE8b6Vvm/WYU3hC90BfPZ1L5axwlG2BNHwDhtdqOKrZxsvJXJRe
	CLBaSA/FhIY86GoiBQ4VG/+OEU6rLGws7osRKbqz9aYGLmzbUATrk1sc0WLvf34d42aM
	wyMrD04Uh7XMKrBprx4h2kiXBG9f10g6WpFTtsmS0FX76WMFjbTM91EZhDN6xyWNGzrr
	zYd2RXXFzXmFXUOyHcGXcuEfYfAPxvpsfjWCZOecSKBHZZjGkk4l7BbWSylZshq6GohF
	Py8A==
MIME-Version: 1.0
X-Received: by 10.182.4.10 with SMTP id g10mr27766924obg.35.1415635463029;
	Mon, 10 Nov 2014 08:04:23 -0800 (PST)
Received: by 10.76.23.231 with HTTP; Mon, 10 Nov 2014 08:04:22 -0800 (PST)
In-Reply-To: <5460DC65.8000909@eu.citrix.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>
	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>
	<5460B550.9000306@eu.citrix.com>
	<CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
	<5460DC65.8000909@eu.citrix.com>
Date: Mon, 10 Nov 2014 11:04:22 -0500
Message-ID: <CAENZ-+=-9VK7D+=nNdM+PP3OmJQmS=CDWKPQ6_uXzNG1qiHdxg@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7725632468854789298=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7725632468854789298==
Content-Type: multipart/alternative; boundary=001a1134a152e7ccbc05078350bf

--001a1134a152e7ccbc05078350bf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014-11-10 10:40 GMT-05:00 George Dunlap <george.dunlap@eu.citrix.com>:

>  On 11/10/2014 03:29 PM, Meng Xu wrote:
>
>  I'm not sure if I should resend the patch just to change the commit log
> and add the reason of why doing this.
>
>  I want to first add the reason. If I should resend the patch set, please
> let me know.
>
> 2014-11-10 7:53 GMT-05:00 George Dunlap <george.dunlap@eu.citrix.com>:
>
>> On 10/25/2014 03:16 PM, Meng Xu wrote:
>>
>>> Move call to rt_update_deadline from _alloc to _insert;
>>>
>>
>  The runq queue lock is not grabbed when  =E2=80=8Brt_update_deadline is =
called
> in rt_alloc_vdata function, which may cause race condition.
>
>
> Can you not grab the lock in rt_alloc_vdata?
>

=E2=80=8BYes. Because when we allocate a rt_vcpu, only one cpu will do that=
. In
addition, before the rt_vcpu is inserted into the runq, we won't have more
than one cpu operate on this rt_vcpu.=E2=80=8B



> Or do you think it's just more efficient to do all the work you need all
> at once?
>

=E2=80=8BI think =E2=80=8Bthe efficiency should be same. Actually, if we do=
n't insert the
rt_vcpu into a runq, we don't need the vcpu's deadline information because
the rt_vcpu is not scheduled by the rtds scheduler. So I think updating the
deadline info when we insert the rt_vcpu into the runq should make more
sense.

Thanks,

Meng


> (I'm not suggesting a change to the code, I'm just trying to clarify the
> motivation for moving the code rather than adding a lock.)=E2=80=8B
>



>
>
>  -George
>
>


--=20


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a1134a152e7ccbc05078350bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small"><br=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-11-10=
 10:40 GMT-05:00 George Dunlap <span dir=3D"ltr">&lt;<a href=3D"mailto:geor=
ge.dunlap@eu.citrix.com" target=3D"_blank">george.dunlap@eu.citrix.com</a>&=
gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    <div>On 11/10/2014 03:29 PM, Meng Xu wrote:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">
        <div style=3D"font-size:small">I&#39;m not sure
          if I should resend the patch just to change the commit log and
          add the reason of why doing this.=C2=A0</div>
        <div style=3D"font-size:small"><br>
        </div>
        <div style=3D"font-size:small">I want to
          first add the reason. If I should resend the patch set, please
          let me know.=C2=A0</div>
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">2014-11-10 7:53 GMT-05:00 George
            Dunlap <span dir=3D"ltr">&lt;<a href=3D"mailto:george.dunlap@eu=
.citrix.com" target=3D"_blank">george.dunlap@eu.citrix.com</a>&gt;</span>:<=
br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><span>On 10/25/2014 03:16 PM, Meng Xu wrote:<b=
r>
                <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex">Move
                  call to rt_update_deadline from _alloc to _insert;<br>
                </blockquote>
              </span></blockquote>
            <div><br>
            </div>
            <div>
              <div style=3D"font-size:small">The
                runq queue lock is not grabbed when =C2=A0=E2=80=8Brt_updat=
e_deadline
                is called in=C2=A0<span style=3D"font-family:arial,sans-ser=
if;font-size:14.3999996185303px">rt_alloc_vdata
                  function, which may cause race condition.</span></div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Can you not grab the lock in rt_alloc_vdata?=C2=A0</div></blockquote><d=
iv><br></div><div><div class=3D"gmail_default" style=3D"font-size:small">=
=E2=80=8BYes. Because when we allocate a rt_vcpu, only one cpu will do that=
. In addition, before the rt_vcpu is inserted into the runq, we won&#39;t h=
ave more than one cpu operate on this rt_vcpu.=E2=80=8B</div><br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000"> Or do you think it&#39;s
    just more efficient to do all the work you need all at once?<br></div><=
/blockquote><div><div class=3D"gmail_default" style=3D"font-size:small"><br=
></div><div class=3D"gmail_default" style=3D"font-size:small">=E2=80=8BI th=
ink =E2=80=8Bthe efficiency should be same. Actually, if we don&#39;t inser=
t the rt_vcpu into a runq, we don&#39;t need the vcpu&#39;s deadline inform=
ation because the rt_vcpu is not scheduled by the rtds scheduler. So I thin=
k updating the deadline info when we insert the rt_vcpu into the runq shoul=
d make more sense.=C2=A0</div></div><div class=3D"gmail_default" style=3D"f=
ont-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:s=
mall">Thanks,</div><div class=3D"gmail_default" style=3D"font-size:small"><=
br></div><div class=3D"gmail_default" style=3D"font-size:small">Meng</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000">
    <br>
    (I&#39;m not suggesting a change to the code, I&#39;m just trying to cl=
arify
    the motivation for moving the code rather than adding a lock.)=E2=80=8B=
</div></blockquote><div><br></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"HOEnZb"><fo=
nt color=3D"#888888"><br>
    <br>
    =C2=A0-George<br>
    <br>
  </font></span></div>

</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><br><br>-----------<br>Meng Xu<br>PhD=
 Student in Computer and Information Science<br>University of Pennsylvania<=
/div></div>
</div></div>

--001a1134a152e7ccbc05078350bf--


--===============7725632468854789298==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7725632468854789298==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 16:04:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:04:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnrS8-0002tL-M9; Mon, 10 Nov 2014 16:04:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xumengpanda@gmail.com>) id 1XnrS7-0002tG-5W
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 16:04:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C5/A8-09842-A02E0645; Mon, 10 Nov 2014 16:04:26 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415635464!12753268!1
X-Originating-IP: [209.85.214.180]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6054 invoked from network); 10 Nov 2014 16:04:25 -0000
Received: from mail-ob0-f180.google.com (HELO mail-ob0-f180.google.com)
	(209.85.214.180)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:04:25 -0000
Received: by mail-ob0-f180.google.com with SMTP id wp4so5914921obc.11
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 08:04:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=VBiaLg2b02rJ1b62Sj0SwGKR8MFoHaRyUvvWn9hfzUQ=;
	b=pTPfQ6E7N0kUohPEgJ4exHqF6BPcCrioPl8xc4ho6LVdFHdIvMdmU2QZbL1OtSMzgT
	TmbXfD9i3aObXss+UaE8b6Vvm/WYU3hC90BfPZ1L5axwlG2BNHwDhtdqOKrZxsvJXJRe
	CLBaSA/FhIY86GoiBQ4VG/+OEU6rLGws7osRKbqz9aYGLmzbUATrk1sc0WLvf34d42aM
	wyMrD04Uh7XMKrBprx4h2kiXBG9f10g6WpFTtsmS0FX76WMFjbTM91EZhDN6xyWNGzrr
	zYd2RXXFzXmFXUOyHcGXcuEfYfAPxvpsfjWCZOecSKBHZZjGkk4l7BbWSylZshq6GohF
	Py8A==
MIME-Version: 1.0
X-Received: by 10.182.4.10 with SMTP id g10mr27766924obg.35.1415635463029;
	Mon, 10 Nov 2014 08:04:23 -0800 (PST)
Received: by 10.76.23.231 with HTTP; Mon, 10 Nov 2014 08:04:22 -0800 (PST)
In-Reply-To: <5460DC65.8000909@eu.citrix.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>
	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>
	<5460B550.9000306@eu.citrix.com>
	<CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>
	<5460DC65.8000909@eu.citrix.com>
Date: Mon, 10 Nov 2014 11:04:22 -0500
Message-ID: <CAENZ-+=-9VK7D+=nNdM+PP3OmJQmS=CDWKPQ6_uXzNG1qiHdxg@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7725632468854789298=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7725632468854789298==
Content-Type: multipart/alternative; boundary=001a1134a152e7ccbc05078350bf

--001a1134a152e7ccbc05078350bf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014-11-10 10:40 GMT-05:00 George Dunlap <george.dunlap@eu.citrix.com>:

>  On 11/10/2014 03:29 PM, Meng Xu wrote:
>
>  I'm not sure if I should resend the patch just to change the commit log
> and add the reason of why doing this.
>
>  I want to first add the reason. If I should resend the patch set, please
> let me know.
>
> 2014-11-10 7:53 GMT-05:00 George Dunlap <george.dunlap@eu.citrix.com>:
>
>> On 10/25/2014 03:16 PM, Meng Xu wrote:
>>
>>> Move call to rt_update_deadline from _alloc to _insert;
>>>
>>
>  The runq queue lock is not grabbed when  =E2=80=8Brt_update_deadline is =
called
> in rt_alloc_vdata function, which may cause race condition.
>
>
> Can you not grab the lock in rt_alloc_vdata?
>

=E2=80=8BYes. Because when we allocate a rt_vcpu, only one cpu will do that=
. In
addition, before the rt_vcpu is inserted into the runq, we won't have more
than one cpu operate on this rt_vcpu.=E2=80=8B



> Or do you think it's just more efficient to do all the work you need all
> at once?
>

=E2=80=8BI think =E2=80=8Bthe efficiency should be same. Actually, if we do=
n't insert the
rt_vcpu into a runq, we don't need the vcpu's deadline information because
the rt_vcpu is not scheduled by the rtds scheduler. So I think updating the
deadline info when we insert the rt_vcpu into the runq should make more
sense.

Thanks,

Meng


> (I'm not suggesting a change to the code, I'm just trying to clarify the
> motivation for moving the code rather than adding a lock.)=E2=80=8B
>



>
>
>  -George
>
>


--=20


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a1134a152e7ccbc05078350bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small"><br=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-11-10=
 10:40 GMT-05:00 George Dunlap <span dir=3D"ltr">&lt;<a href=3D"mailto:geor=
ge.dunlap@eu.citrix.com" target=3D"_blank">george.dunlap@eu.citrix.com</a>&=
gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    <div>On 11/10/2014 03:29 PM, Meng Xu wrote:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">
        <div style=3D"font-size:small">I&#39;m not sure
          if I should resend the patch just to change the commit log and
          add the reason of why doing this.=C2=A0</div>
        <div style=3D"font-size:small"><br>
        </div>
        <div style=3D"font-size:small">I want to
          first add the reason. If I should resend the patch set, please
          let me know.=C2=A0</div>
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">2014-11-10 7:53 GMT-05:00 George
            Dunlap <span dir=3D"ltr">&lt;<a href=3D"mailto:george.dunlap@eu=
.citrix.com" target=3D"_blank">george.dunlap@eu.citrix.com</a>&gt;</span>:<=
br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><span>On 10/25/2014 03:16 PM, Meng Xu wrote:<b=
r>
                <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex">Move
                  call to rt_update_deadline from _alloc to _insert;<br>
                </blockquote>
              </span></blockquote>
            <div><br>
            </div>
            <div>
              <div style=3D"font-size:small">The
                runq queue lock is not grabbed when =C2=A0=E2=80=8Brt_updat=
e_deadline
                is called in=C2=A0<span style=3D"font-family:arial,sans-ser=
if;font-size:14.3999996185303px">rt_alloc_vdata
                  function, which may cause race condition.</span></div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Can you not grab the lock in rt_alloc_vdata?=C2=A0</div></blockquote><d=
iv><br></div><div><div class=3D"gmail_default" style=3D"font-size:small">=
=E2=80=8BYes. Because when we allocate a rt_vcpu, only one cpu will do that=
. In addition, before the rt_vcpu is inserted into the runq, we won&#39;t h=
ave more than one cpu operate on this rt_vcpu.=E2=80=8B</div><br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000"> Or do you think it&#39;s
    just more efficient to do all the work you need all at once?<br></div><=
/blockquote><div><div class=3D"gmail_default" style=3D"font-size:small"><br=
></div><div class=3D"gmail_default" style=3D"font-size:small">=E2=80=8BI th=
ink =E2=80=8Bthe efficiency should be same. Actually, if we don&#39;t inser=
t the rt_vcpu into a runq, we don&#39;t need the vcpu&#39;s deadline inform=
ation because the rt_vcpu is not scheduled by the rtds scheduler. So I thin=
k updating the deadline info when we insert the rt_vcpu into the runq shoul=
d make more sense.=C2=A0</div></div><div class=3D"gmail_default" style=3D"f=
ont-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:s=
mall">Thanks,</div><div class=3D"gmail_default" style=3D"font-size:small"><=
br></div><div class=3D"gmail_default" style=3D"font-size:small">Meng</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000">
    <br>
    (I&#39;m not suggesting a change to the code, I&#39;m just trying to cl=
arify
    the motivation for moving the code rather than adding a lock.)=E2=80=8B=
</div></blockquote><div><br></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"HOEnZb"><fo=
nt color=3D"#888888"><br>
    <br>
    =C2=A0-George<br>
    <br>
  </font></span></div>

</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><br><br>-----------<br>Meng Xu<br>PhD=
 Student in Computer and Information Science<br>University of Pennsylvania<=
/div></div>
</div></div>

--001a1134a152e7ccbc05078350bf--


--===============7725632468854789298==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7725632468854789298==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 16:13:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnraq-00038q-42; Mon, 10 Nov 2014 16:13:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xnrao-00038l-EE
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:13:26 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	04/5F-02954-524E0645; Mon, 10 Nov 2014 16:13:25 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415636002!12499058!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8842 invoked from network); 10 Nov 2014 16:13:24 -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;
	10 Nov 2014 16:13:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191237009"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:12:52 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XnraG-0000MC-6e;
	Mon, 10 Nov 2014 16:12:52 +0000
Date: Mon, 10 Nov 2014 16:12:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 0/13] introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series introduces support for GNTTABOP_cache_flush to perform
cache maintenance operation on foreign pages and reverts the current
code based on XENFEAT_grant_map_identity.

It also provides a very slow fallback by bouncing on the swiotlb buffer,
in case the hypercall is not available.

v7 introduces a flag named dma_coherent in dev_archdata and an accessor
function named is_device_dma_coherent in asm/dma-mapping.h under arm and
arm64.


Changes in v8:
- remove code duplication in mm32.c by moving the pfn_valid check in
page-coherent.h;
- add a dma_addr_t dev_addr argument to xen_dma_map_page;
- use hypercall to flush caches in map_page;
- pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu;
- remove BUG_ON in xen_bus_to_phys.

Changes in v7:
- rebased on 3.18-rc1;
- rename is_dma_coherent to is_device_dma_coherent and move it to
asm/dma-mapping.h on arm and arm64;
- introduce a dma_coherent flag on arm and arm64;
- set the flags from set_arch_dma_coherent_ops.

Changes in v6:
- rename xen_is_dma_coherent to is_dma_coherent;
- use of_dma_is_coherent to detect the dma coherency of a device;
- remove arch/arm64/include/asm/xen/page-coherent.h, include
../../arm/include/asm/xen/page-coherent.h instead;
- fix indentation.

Changes in v5:
- introduce xen_is_dma_coherent as a xen specific function;
- call xen_is_dma_coherent instead of is_dma_coherent;
- introduce xen_is_dma_coherent to
arch/arm64/include/asm/xen/page-coherent.h;
- do not remove arch/arm64/include/asm/xen/page-coherent.h, add
the missing dma_ops calls from it;
- fix indentation;
- rename hypercall_flush to hypercall_cflush;
- remove spurious change.

Changes in v4:
- remove outer_*_range call;
- introduce is_dma_coherent;
- use is_dma_coherent in arch/arm/xen/mm32.c;
- merge xen/mm32.c into xen/mm.c;
- xen/arm/arm64: introduce xen_arch_need_swiotlb;
- avoid bouncing dma map operations that involve foreign grants and
non-coherent devices if GNTTABOP_cache_flush is provided by Xen.

Changes in v3:
- fix the cache maintenance op call to match what Linux does natively;
- update the hypercall interface to match Xen.

Changes in v2:
- remove the definition of XENFEAT_grant_map_identity;
- update the hypercall interface to match Xen;
- call the interface on a single page at a time.


Stefano Stabellini (13):
      xen/arm: remove handling of XENFEAT_grant_map_identity
      xen/arm: remove outer_*_range call
      xen/arm: if(pfn_valid(pfn)) call native dma_ops
      arm64: introduce is_device_dma_coherent
      arm: introduce is_device_dma_coherent
      xen/arm: use is_device_dma_coherent
      xen: add a dma_addr_t dev_addr argument to xen_dma_map_page
      xen/arm: use hypercall to flush caches in map_page
      xen/arm/arm64: merge xen/mm32.c into xen/mm.c
      xen/arm/arm64: introduce xen_arch_need_swiotlb
      xen/arm: introduce GNTTABOP_cache_flush
      swiotlb-xen: pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu
      swiotlb-xen: remove BUG_ON in xen_bus_to_phys

 arch/arm/include/asm/device.h              |    1 +
 arch/arm/include/asm/dma-mapping.h         |    6 +
 arch/arm/include/asm/xen/page-coherent.h   |   56 +++++++-
 arch/arm/include/asm/xen/page.h            |    4 +
 arch/arm/xen/Makefile                      |    2 +-
 arch/arm/xen/enlighten.c                   |    5 -
 arch/arm/xen/mm.c                          |  123 +++++++++++++++++
 arch/arm/xen/mm32.c                        |  202 ----------------------------
 arch/arm64/include/asm/device.h            |    1 +
 arch/arm64/include/asm/dma-mapping.h       |    6 +
 arch/arm64/include/asm/xen/page-coherent.h |   44 +-----
 arch/x86/include/asm/xen/page-coherent.h   |    4 +-
 arch/x86/include/asm/xen/page.h            |    7 +
 drivers/xen/swiotlb-xen.c                  |   19 +--
 include/xen/interface/features.h           |    3 -
 include/xen/interface/grant_table.h        |   19 +++
 16 files changed, 232 insertions(+), 270 deletions(-)
 delete mode 100644 arch/arm/xen/mm32.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:13:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnraq-00038q-42; Mon, 10 Nov 2014 16:13:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xnrao-00038l-EE
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:13:26 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	04/5F-02954-524E0645; Mon, 10 Nov 2014 16:13:25 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415636002!12499058!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8842 invoked from network); 10 Nov 2014 16:13:24 -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;
	10 Nov 2014 16:13:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191237009"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:12:52 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XnraG-0000MC-6e;
	Mon, 10 Nov 2014 16:12:52 +0000
Date: Mon, 10 Nov 2014 16:12:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 0/13] introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series introduces support for GNTTABOP_cache_flush to perform
cache maintenance operation on foreign pages and reverts the current
code based on XENFEAT_grant_map_identity.

It also provides a very slow fallback by bouncing on the swiotlb buffer,
in case the hypercall is not available.

v7 introduces a flag named dma_coherent in dev_archdata and an accessor
function named is_device_dma_coherent in asm/dma-mapping.h under arm and
arm64.


Changes in v8:
- remove code duplication in mm32.c by moving the pfn_valid check in
page-coherent.h;
- add a dma_addr_t dev_addr argument to xen_dma_map_page;
- use hypercall to flush caches in map_page;
- pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu;
- remove BUG_ON in xen_bus_to_phys.

Changes in v7:
- rebased on 3.18-rc1;
- rename is_dma_coherent to is_device_dma_coherent and move it to
asm/dma-mapping.h on arm and arm64;
- introduce a dma_coherent flag on arm and arm64;
- set the flags from set_arch_dma_coherent_ops.

Changes in v6:
- rename xen_is_dma_coherent to is_dma_coherent;
- use of_dma_is_coherent to detect the dma coherency of a device;
- remove arch/arm64/include/asm/xen/page-coherent.h, include
../../arm/include/asm/xen/page-coherent.h instead;
- fix indentation.

Changes in v5:
- introduce xen_is_dma_coherent as a xen specific function;
- call xen_is_dma_coherent instead of is_dma_coherent;
- introduce xen_is_dma_coherent to
arch/arm64/include/asm/xen/page-coherent.h;
- do not remove arch/arm64/include/asm/xen/page-coherent.h, add
the missing dma_ops calls from it;
- fix indentation;
- rename hypercall_flush to hypercall_cflush;
- remove spurious change.

Changes in v4:
- remove outer_*_range call;
- introduce is_dma_coherent;
- use is_dma_coherent in arch/arm/xen/mm32.c;
- merge xen/mm32.c into xen/mm.c;
- xen/arm/arm64: introduce xen_arch_need_swiotlb;
- avoid bouncing dma map operations that involve foreign grants and
non-coherent devices if GNTTABOP_cache_flush is provided by Xen.

Changes in v3:
- fix the cache maintenance op call to match what Linux does natively;
- update the hypercall interface to match Xen.

Changes in v2:
- remove the definition of XENFEAT_grant_map_identity;
- update the hypercall interface to match Xen;
- call the interface on a single page at a time.


Stefano Stabellini (13):
      xen/arm: remove handling of XENFEAT_grant_map_identity
      xen/arm: remove outer_*_range call
      xen/arm: if(pfn_valid(pfn)) call native dma_ops
      arm64: introduce is_device_dma_coherent
      arm: introduce is_device_dma_coherent
      xen/arm: use is_device_dma_coherent
      xen: add a dma_addr_t dev_addr argument to xen_dma_map_page
      xen/arm: use hypercall to flush caches in map_page
      xen/arm/arm64: merge xen/mm32.c into xen/mm.c
      xen/arm/arm64: introduce xen_arch_need_swiotlb
      xen/arm: introduce GNTTABOP_cache_flush
      swiotlb-xen: pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu
      swiotlb-xen: remove BUG_ON in xen_bus_to_phys

 arch/arm/include/asm/device.h              |    1 +
 arch/arm/include/asm/dma-mapping.h         |    6 +
 arch/arm/include/asm/xen/page-coherent.h   |   56 +++++++-
 arch/arm/include/asm/xen/page.h            |    4 +
 arch/arm/xen/Makefile                      |    2 +-
 arch/arm/xen/enlighten.c                   |    5 -
 arch/arm/xen/mm.c                          |  123 +++++++++++++++++
 arch/arm/xen/mm32.c                        |  202 ----------------------------
 arch/arm64/include/asm/device.h            |    1 +
 arch/arm64/include/asm/dma-mapping.h       |    6 +
 arch/arm64/include/asm/xen/page-coherent.h |   44 +-----
 arch/x86/include/asm/xen/page-coherent.h   |    4 +-
 arch/x86/include/asm/xen/page.h            |    7 +
 drivers/xen/swiotlb-xen.c                  |   19 +--
 include/xen/interface/features.h           |    3 -
 include/xen/interface/grant_table.h        |   19 +++
 16 files changed, 232 insertions(+), 270 deletions(-)
 delete mode 100644 arch/arm/xen/mm32.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnrcX-0003ES-0R; Mon, 10 Nov 2014 16:15:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrcV-0003E7-OF
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:11 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	EA/FE-25547-E84E0645; Mon, 10 Nov 2014 16:15:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24319 invoked from network); 10 Nov 2014 16:15:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798975"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbd-0000Mx-W9;
	Mon, 10 Nov 2014 16:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:57 +0000
Message-ID: <1415636045-24669-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: linux@arm.linux.org.uk, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 05/13] arm: introduce is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a boolean flag and an accessor function to check whether a
device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
CC: linux@arm.linux.org.uk
CC: will.deacon@arm.com
---
 arch/arm/include/asm/device.h      |    1 +
 arch/arm/include/asm/dma-mapping.h |    6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index dc662fc..4111592 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -17,6 +17,7 @@ struct dev_archdata {
 #ifdef CONFIG_ARM_DMA_USE_IOMMU
 	struct dma_iommu_mapping	*mapping;
 #endif
+	bool dma_coherent;
 };
 
 struct omap_device;
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 85738b2..8c3b616 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -123,11 +123,17 @@ static inline unsigned long dma_max_pfn(struct device *dev)
 
 static inline int set_arch_dma_coherent_ops(struct device *dev)
 {
+	dev->archdata.dma_coherent = true;
 	set_dma_ops(dev, &arm_coherent_dma_ops);
 	return 0;
 }
 #define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
 
+static inline bool is_device_dma_coherent(struct device *dev)
+{
+	return dev->archdata.dma_coherent;
+}
+
 static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
 	unsigned int offset = paddr & ~PAGE_MASK;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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 1Xnrca-0003Fv-Ry; Mon, 10 Nov 2014 16:15:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrcX-0003ER-8i
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:13 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	EB/99-18267-094E0645; Mon, 10 Nov 2014 16:15:12 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415636108!11553432!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14632 invoked from network); 10 Nov 2014 16:15:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798981"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbd-0000Mx-V2;
	Mon, 10 Nov 2014 16:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:55 +0000
Message-ID: <1415636045-24669-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 03/13] xen/arm: if(pfn_valid(pfn)) call
	native dma_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove code duplication in mm32.c by calling the native dma_ops if the
page is a local page (not a foreign page). Use a simple pfn_valid(pfn)
check to figure out if the page is local, exploiting the fact that dom0
is mapped 1:1, therefore pfn_valid always returns false when called on a
foreign mfn.

Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/page-coherent.h |   43 ++++++++++++++++++++++--
 arch/arm/xen/mm32.c                      |   52 ++++++++----------------------
 2 files changed, 53 insertions(+), 42 deletions(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index e8275ea..d97b0b4 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -5,6 +5,15 @@
 #include <linux/dma-attrs.h>
 #include <linux/dma-mapping.h>
 
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir,
+		struct dma_attrs *attrs);
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+
+void __xen_dma_sync_single_for_device(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+
 static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
 		dma_addr_t *dma_handle, gfp_t flags,
 		struct dma_attrs *attrs)
@@ -28,12 +37,40 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 
 void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs);
+		struct dma_attrs *attrs)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	/* Dom0 is mapped 1:1, so calling pfn_valid on a foreign mfn will
+	 * always return false. If the page is local we can safely call the
+	 * native dma_ops function, otherwise we call the xen specific
+	 * function. */
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->unmap_page)
+			__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
+	} else
+		__xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
+}
 
 void xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->sync_single_for_cpu)
+			__generic_dma_ops(hwdev)->sync_single_for_cpu(hwdev, handle, size, dir);
+	} else
+		__xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
+}
 
 void xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->sync_single_for_device)
+			__generic_dma_ops(hwdev)->sync_single_for_device(hwdev, handle, size, dir);
+	} else
+		__xen_dma_sync_single_for_device(hwdev, handle, size, dir);
+}
 
 #endif /* _ASM_ARM_XEN_PAGE_COHERENT_H */
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 6153d61..b26bf84 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -4,13 +4,15 @@
 #include <linux/highmem.h>
 
 #include <xen/features.h>
-
+enum dma_cache_op {
+       DMA_UNMAP,
+       DMA_MAP,
+};
 
 /* functions called by SWIOTLB */
 
 static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
-	size_t size, enum dma_data_direction dir,
-	void (*op)(const void *, size_t, int))
+	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
 {
 	unsigned long pfn;
 	size_t left = size;
@@ -20,34 +22,10 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 
 	do {
 		size_t len = left;
-		void *vaddr;
 	
-		if (!pfn_valid(pfn))
-		{
-			/* TODO: cache flush */
-		} else {
-			struct page *page = pfn_to_page(pfn);
-
-			if (PageHighMem(page)) {
-				if (len + offset > PAGE_SIZE)
-					len = PAGE_SIZE - offset;
-
-				if (cache_is_vipt_nonaliasing()) {
-					vaddr = kmap_atomic(page);
-					op(vaddr + offset, len, dir);
-					kunmap_atomic(vaddr);
-				} else {
-					vaddr = kmap_high_get(page);
-					if (vaddr) {
-						op(vaddr + offset, len, dir);
-						kunmap_high(page);
-					}
-				}
-			} else {
-				vaddr = page_address(page) + offset;
-				op(vaddr, len, dir);
-			}
-		}
+		BUG_ON(pfn_valid(pfn));
+
+		/* TODO: cache flush */
 
 		offset = 0;
 		pfn++;
@@ -58,20 +36,16 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir)
 {
-	/* Cannot use __dma_page_dev_to_cpu because we don't have a
-	 * struct page for handle */
-
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_unmap_area);
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
 }
 
 static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir)
 {
-
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_map_area);
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
 }
 
-void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs)
 
@@ -84,7 +58,7 @@ void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
 
-void xen_dma_sync_single_for_cpu(struct device *hwdev,
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
 	if (!__generic_dma_ops(hwdev)->sync_single_for_cpu)
@@ -92,7 +66,7 @@ void xen_dma_sync_single_for_cpu(struct device *hwdev,
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
 
-void xen_dma_sync_single_for_device(struct device *hwdev,
+void __xen_dma_sync_single_for_device(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
 	if (!__generic_dma_ops(hwdev)->sync_single_for_device)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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 1XnrcV-0003E8-KZ; Mon, 10 Nov 2014 16:15:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrcU-0003E1-J8
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:10 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	24/A4-26740-D84E0645; Mon, 10 Nov 2014 16:15:09 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24005 invoked from network); 10 Nov 2014 16:15:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798974"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbd-0000Mx-UW;
	Mon, 10 Nov 2014 16:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:54 +0000
Message-ID: <1415636045-24669-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 02/13] xen/arm: remove outer_*_range call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0 is not actually capable of issuing outer_inv_range or
outer_clean_range calls.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 arch/arm/xen/mm32.c |    9 ---------
 1 file changed, 9 deletions(-)

diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index a5a93fc..6153d61 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -61,9 +61,6 @@ static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
 	/* Cannot use __dma_page_dev_to_cpu because we don't have a
 	 * struct page for handle */
 
-	if (dir != DMA_TO_DEVICE)
-		outer_inv_range(handle, handle + size);
-
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_unmap_area);
 }
 
@@ -72,12 +69,6 @@ static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 {
 
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_map_area);
-
-	if (dir == DMA_FROM_DEVICE) {
-		outer_inv_range(handle, handle + size);
-	} else {
-		outer_clean_range(handle, handle + size);
-	}
 }
 
 void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnrcX-0003ES-0R; Mon, 10 Nov 2014 16:15:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrcV-0003E7-OF
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:11 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	EA/FE-25547-E84E0645; Mon, 10 Nov 2014 16:15:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24319 invoked from network); 10 Nov 2014 16:15:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798975"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbd-0000Mx-W9;
	Mon, 10 Nov 2014 16:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:57 +0000
Message-ID: <1415636045-24669-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: linux@arm.linux.org.uk, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 05/13] arm: introduce is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a boolean flag and an accessor function to check whether a
device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
CC: linux@arm.linux.org.uk
CC: will.deacon@arm.com
---
 arch/arm/include/asm/device.h      |    1 +
 arch/arm/include/asm/dma-mapping.h |    6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index dc662fc..4111592 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -17,6 +17,7 @@ struct dev_archdata {
 #ifdef CONFIG_ARM_DMA_USE_IOMMU
 	struct dma_iommu_mapping	*mapping;
 #endif
+	bool dma_coherent;
 };
 
 struct omap_device;
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 85738b2..8c3b616 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -123,11 +123,17 @@ static inline unsigned long dma_max_pfn(struct device *dev)
 
 static inline int set_arch_dma_coherent_ops(struct device *dev)
 {
+	dev->archdata.dma_coherent = true;
 	set_dma_ops(dev, &arm_coherent_dma_ops);
 	return 0;
 }
 #define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
 
+static inline bool is_device_dma_coherent(struct device *dev)
+{
+	return dev->archdata.dma_coherent;
+}
+
 static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
 	unsigned int offset = paddr & ~PAGE_MASK;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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 1XnrcY-0003Eu-Dw; Mon, 10 Nov 2014 16:15:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrcW-0003ED-AJ
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:12 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	D7/62-28296-F84E0645; Mon, 10 Nov 2014 16:15:11 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24446 invoked from network); 10 Nov 2014 16:15:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798976"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbd-0000Mx-Tx;
	Mon, 10 Nov 2014 16:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:53 +0000
Message-ID: <1415636045-24669-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 01/13] xen/arm: remove handling of
	XENFEAT_grant_map_identity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 feature has been removed from Xen. Also Linux cannot use it on ARM32
without CONFIG_ARM_LPAE.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---
Changes in v2:

- remove the definition of XENFEAT_grant_map_identity.
---
 arch/arm/xen/enlighten.c         |    5 ---
 arch/arm/xen/mm32.c              |   85 +-------------------------------------
 include/xen/interface/features.h |    3 --
 3 files changed, 1 insertion(+), 92 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e15f01..c7ca936 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,11 +261,6 @@ static int __init xen_guest_init(void)
 
 	xen_setup_features();
 
-	if (!xen_feature(XENFEAT_grant_map_identity)) {
-		pr_warn("Please upgrade your Xen.\n"
-				"If your platform has any non-coherent DMA devices, they won't work properly.\n");
-	}
-
 	if (xen_feature(XENFEAT_dom0))
 		xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
 	else
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 3b99860..a5a93fc 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -5,70 +5,6 @@
 
 #include <xen/features.h>
 
-static DEFINE_PER_CPU(unsigned long, xen_mm32_scratch_virt);
-static DEFINE_PER_CPU(pte_t *, xen_mm32_scratch_ptep);
-
-static int alloc_xen_mm32_scratch_page(int cpu)
-{
-	struct page *page;
-	unsigned long virt;
-	pmd_t *pmdp;
-	pte_t *ptep;
-
-	if (per_cpu(xen_mm32_scratch_ptep, cpu) != NULL)
-		return 0;
-
-	page = alloc_page(GFP_KERNEL);
-	if (page == NULL) {
-		pr_warn("Failed to allocate xen_mm32_scratch_page for cpu %d\n", cpu);
-		return -ENOMEM;
-	}
-
-	virt = (unsigned long)__va(page_to_phys(page));
-	pmdp = pmd_offset(pud_offset(pgd_offset_k(virt), virt), virt);
-	ptep = pte_offset_kernel(pmdp, virt);
-
-	per_cpu(xen_mm32_scratch_virt, cpu) = virt;
-	per_cpu(xen_mm32_scratch_ptep, cpu) = ptep;
-
-	return 0;
-}
-
-static int xen_mm32_cpu_notify(struct notifier_block *self,
-				    unsigned long action, void *hcpu)
-{
-	int cpu = (long)hcpu;
-	switch (action) {
-	case CPU_UP_PREPARE:
-		if (alloc_xen_mm32_scratch_page(cpu))
-			return NOTIFY_BAD;
-		break;
-	default:
-		break;
-	}
-	return NOTIFY_OK;
-}
-
-static struct notifier_block xen_mm32_cpu_notifier = {
-	.notifier_call	= xen_mm32_cpu_notify,
-};
-
-static void* xen_mm32_remap_page(dma_addr_t handle)
-{
-	unsigned long virt = get_cpu_var(xen_mm32_scratch_virt);
-	pte_t *ptep = __get_cpu_var(xen_mm32_scratch_ptep);
-
-	*ptep = pfn_pte(handle >> PAGE_SHIFT, PAGE_KERNEL);
-	local_flush_tlb_kernel_page(virt);
-
-	return (void*)virt;
-}
-
-static void xen_mm32_unmap(void *vaddr)
-{
-	put_cpu_var(xen_mm32_scratch_virt);
-}
-
 
 /* functions called by SWIOTLB */
 
@@ -88,13 +24,7 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	
 		if (!pfn_valid(pfn))
 		{
-			/* Cannot map the page, we don't know its physical address.
-			 * Return and hope for the best */
-			if (!xen_feature(XENFEAT_grant_map_identity))
-				return;
-			vaddr = xen_mm32_remap_page(handle) + offset;
-			op(vaddr, len, dir);
-			xen_mm32_unmap(vaddr - offset);
+			/* TODO: cache flush */
 		} else {
 			struct page *page = pfn_to_page(pfn);
 
@@ -181,22 +111,9 @@ void xen_dma_sync_single_for_device(struct device *hwdev,
 
 int __init xen_mm32_init(void)
 {
-	int cpu;
-
 	if (!xen_initial_domain())
 		return 0;
 
-	register_cpu_notifier(&xen_mm32_cpu_notifier);
-	get_online_cpus();
-	for_each_online_cpu(cpu) {
-		if (alloc_xen_mm32_scratch_page(cpu)) {
-			put_online_cpus();
-			unregister_cpu_notifier(&xen_mm32_cpu_notifier);
-			return -ENOMEM;
-		}
-	}
-	put_online_cpus();
-
 	return 0;
 }
 arch_initcall(xen_mm32_init);
diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h
index 14334d0..131a6cc 100644
--- a/include/xen/interface/features.h
+++ b/include/xen/interface/features.h
@@ -53,9 +53,6 @@
 /* operation as Dom0 is supported */
 #define XENFEAT_dom0                      11
 
-/* Xen also maps grant references at pfn = mfn */
-#define XENFEAT_grant_map_identity        12
-
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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 1XnrcV-0003E8-KZ; Mon, 10 Nov 2014 16:15:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrcU-0003E1-J8
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:10 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	24/A4-26740-D84E0645; Mon, 10 Nov 2014 16:15:09 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24005 invoked from network); 10 Nov 2014 16:15:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798974"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbd-0000Mx-UW;
	Mon, 10 Nov 2014 16:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:54 +0000
Message-ID: <1415636045-24669-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 02/13] xen/arm: remove outer_*_range call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0 is not actually capable of issuing outer_inv_range or
outer_clean_range calls.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 arch/arm/xen/mm32.c |    9 ---------
 1 file changed, 9 deletions(-)

diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index a5a93fc..6153d61 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -61,9 +61,6 @@ static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
 	/* Cannot use __dma_page_dev_to_cpu because we don't have a
 	 * struct page for handle */
 
-	if (dir != DMA_TO_DEVICE)
-		outer_inv_range(handle, handle + size);
-
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_unmap_area);
 }
 
@@ -72,12 +69,6 @@ static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 {
 
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_map_area);
-
-	if (dir == DMA_FROM_DEVICE) {
-		outer_inv_range(handle, handle + size);
-	} else {
-		outer_clean_range(handle, handle + size);
-	}
 }
 
 void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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 1XnrcY-0003Eu-Dw; Mon, 10 Nov 2014 16:15:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrcW-0003ED-AJ
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:12 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	D7/62-28296-F84E0645; Mon, 10 Nov 2014 16:15:11 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24446 invoked from network); 10 Nov 2014 16:15:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798976"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbd-0000Mx-Tx;
	Mon, 10 Nov 2014 16:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:53 +0000
Message-ID: <1415636045-24669-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 01/13] xen/arm: remove handling of
	XENFEAT_grant_map_identity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 feature has been removed from Xen. Also Linux cannot use it on ARM32
without CONFIG_ARM_LPAE.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---
Changes in v2:

- remove the definition of XENFEAT_grant_map_identity.
---
 arch/arm/xen/enlighten.c         |    5 ---
 arch/arm/xen/mm32.c              |   85 +-------------------------------------
 include/xen/interface/features.h |    3 --
 3 files changed, 1 insertion(+), 92 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e15f01..c7ca936 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,11 +261,6 @@ static int __init xen_guest_init(void)
 
 	xen_setup_features();
 
-	if (!xen_feature(XENFEAT_grant_map_identity)) {
-		pr_warn("Please upgrade your Xen.\n"
-				"If your platform has any non-coherent DMA devices, they won't work properly.\n");
-	}
-
 	if (xen_feature(XENFEAT_dom0))
 		xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
 	else
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 3b99860..a5a93fc 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -5,70 +5,6 @@
 
 #include <xen/features.h>
 
-static DEFINE_PER_CPU(unsigned long, xen_mm32_scratch_virt);
-static DEFINE_PER_CPU(pte_t *, xen_mm32_scratch_ptep);
-
-static int alloc_xen_mm32_scratch_page(int cpu)
-{
-	struct page *page;
-	unsigned long virt;
-	pmd_t *pmdp;
-	pte_t *ptep;
-
-	if (per_cpu(xen_mm32_scratch_ptep, cpu) != NULL)
-		return 0;
-
-	page = alloc_page(GFP_KERNEL);
-	if (page == NULL) {
-		pr_warn("Failed to allocate xen_mm32_scratch_page for cpu %d\n", cpu);
-		return -ENOMEM;
-	}
-
-	virt = (unsigned long)__va(page_to_phys(page));
-	pmdp = pmd_offset(pud_offset(pgd_offset_k(virt), virt), virt);
-	ptep = pte_offset_kernel(pmdp, virt);
-
-	per_cpu(xen_mm32_scratch_virt, cpu) = virt;
-	per_cpu(xen_mm32_scratch_ptep, cpu) = ptep;
-
-	return 0;
-}
-
-static int xen_mm32_cpu_notify(struct notifier_block *self,
-				    unsigned long action, void *hcpu)
-{
-	int cpu = (long)hcpu;
-	switch (action) {
-	case CPU_UP_PREPARE:
-		if (alloc_xen_mm32_scratch_page(cpu))
-			return NOTIFY_BAD;
-		break;
-	default:
-		break;
-	}
-	return NOTIFY_OK;
-}
-
-static struct notifier_block xen_mm32_cpu_notifier = {
-	.notifier_call	= xen_mm32_cpu_notify,
-};
-
-static void* xen_mm32_remap_page(dma_addr_t handle)
-{
-	unsigned long virt = get_cpu_var(xen_mm32_scratch_virt);
-	pte_t *ptep = __get_cpu_var(xen_mm32_scratch_ptep);
-
-	*ptep = pfn_pte(handle >> PAGE_SHIFT, PAGE_KERNEL);
-	local_flush_tlb_kernel_page(virt);
-
-	return (void*)virt;
-}
-
-static void xen_mm32_unmap(void *vaddr)
-{
-	put_cpu_var(xen_mm32_scratch_virt);
-}
-
 
 /* functions called by SWIOTLB */
 
@@ -88,13 +24,7 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	
 		if (!pfn_valid(pfn))
 		{
-			/* Cannot map the page, we don't know its physical address.
-			 * Return and hope for the best */
-			if (!xen_feature(XENFEAT_grant_map_identity))
-				return;
-			vaddr = xen_mm32_remap_page(handle) + offset;
-			op(vaddr, len, dir);
-			xen_mm32_unmap(vaddr - offset);
+			/* TODO: cache flush */
 		} else {
 			struct page *page = pfn_to_page(pfn);
 
@@ -181,22 +111,9 @@ void xen_dma_sync_single_for_device(struct device *hwdev,
 
 int __init xen_mm32_init(void)
 {
-	int cpu;
-
 	if (!xen_initial_domain())
 		return 0;
 
-	register_cpu_notifier(&xen_mm32_cpu_notifier);
-	get_online_cpus();
-	for_each_online_cpu(cpu) {
-		if (alloc_xen_mm32_scratch_page(cpu)) {
-			put_online_cpus();
-			unregister_cpu_notifier(&xen_mm32_cpu_notifier);
-			return -ENOMEM;
-		}
-	}
-	put_online_cpus();
-
 	return 0;
 }
 arch_initcall(xen_mm32_init);
diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h
index 14334d0..131a6cc 100644
--- a/include/xen/interface/features.h
+++ b/include/xen/interface/features.h
@@ -53,9 +53,6 @@
 /* operation as Dom0 is supported */
 #define XENFEAT_dom0                      11
 
-/* Xen also maps grant references at pfn = mfn */
-#define XENFEAT_grant_map_identity        12
-
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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 1Xnrca-0003Fv-Ry; Mon, 10 Nov 2014 16:15:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrcX-0003ER-8i
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:13 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	EB/99-18267-094E0645; Mon, 10 Nov 2014 16:15:12 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415636108!11553432!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14632 invoked from network); 10 Nov 2014 16:15:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798981"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbd-0000Mx-V2;
	Mon, 10 Nov 2014 16:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:55 +0000
Message-ID: <1415636045-24669-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 03/13] xen/arm: if(pfn_valid(pfn)) call
	native dma_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove code duplication in mm32.c by calling the native dma_ops if the
page is a local page (not a foreign page). Use a simple pfn_valid(pfn)
check to figure out if the page is local, exploiting the fact that dom0
is mapped 1:1, therefore pfn_valid always returns false when called on a
foreign mfn.

Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/page-coherent.h |   43 ++++++++++++++++++++++--
 arch/arm/xen/mm32.c                      |   52 ++++++++----------------------
 2 files changed, 53 insertions(+), 42 deletions(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index e8275ea..d97b0b4 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -5,6 +5,15 @@
 #include <linux/dma-attrs.h>
 #include <linux/dma-mapping.h>
 
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir,
+		struct dma_attrs *attrs);
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+
+void __xen_dma_sync_single_for_device(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+
 static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
 		dma_addr_t *dma_handle, gfp_t flags,
 		struct dma_attrs *attrs)
@@ -28,12 +37,40 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 
 void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs);
+		struct dma_attrs *attrs)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	/* Dom0 is mapped 1:1, so calling pfn_valid on a foreign mfn will
+	 * always return false. If the page is local we can safely call the
+	 * native dma_ops function, otherwise we call the xen specific
+	 * function. */
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->unmap_page)
+			__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
+	} else
+		__xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
+}
 
 void xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->sync_single_for_cpu)
+			__generic_dma_ops(hwdev)->sync_single_for_cpu(hwdev, handle, size, dir);
+	} else
+		__xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
+}
 
 void xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->sync_single_for_device)
+			__generic_dma_ops(hwdev)->sync_single_for_device(hwdev, handle, size, dir);
+	} else
+		__xen_dma_sync_single_for_device(hwdev, handle, size, dir);
+}
 
 #endif /* _ASM_ARM_XEN_PAGE_COHERENT_H */
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 6153d61..b26bf84 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -4,13 +4,15 @@
 #include <linux/highmem.h>
 
 #include <xen/features.h>
-
+enum dma_cache_op {
+       DMA_UNMAP,
+       DMA_MAP,
+};
 
 /* functions called by SWIOTLB */
 
 static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
-	size_t size, enum dma_data_direction dir,
-	void (*op)(const void *, size_t, int))
+	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
 {
 	unsigned long pfn;
 	size_t left = size;
@@ -20,34 +22,10 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 
 	do {
 		size_t len = left;
-		void *vaddr;
 	
-		if (!pfn_valid(pfn))
-		{
-			/* TODO: cache flush */
-		} else {
-			struct page *page = pfn_to_page(pfn);
-
-			if (PageHighMem(page)) {
-				if (len + offset > PAGE_SIZE)
-					len = PAGE_SIZE - offset;
-
-				if (cache_is_vipt_nonaliasing()) {
-					vaddr = kmap_atomic(page);
-					op(vaddr + offset, len, dir);
-					kunmap_atomic(vaddr);
-				} else {
-					vaddr = kmap_high_get(page);
-					if (vaddr) {
-						op(vaddr + offset, len, dir);
-						kunmap_high(page);
-					}
-				}
-			} else {
-				vaddr = page_address(page) + offset;
-				op(vaddr, len, dir);
-			}
-		}
+		BUG_ON(pfn_valid(pfn));
+
+		/* TODO: cache flush */
 
 		offset = 0;
 		pfn++;
@@ -58,20 +36,16 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir)
 {
-	/* Cannot use __dma_page_dev_to_cpu because we don't have a
-	 * struct page for handle */
-
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_unmap_area);
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
 }
 
 static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir)
 {
-
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_map_area);
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
 }
 
-void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs)
 
@@ -84,7 +58,7 @@ void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
 
-void xen_dma_sync_single_for_cpu(struct device *hwdev,
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
 	if (!__generic_dma_ops(hwdev)->sync_single_for_cpu)
@@ -92,7 +66,7 @@ void xen_dma_sync_single_for_cpu(struct device *hwdev,
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
 
-void xen_dma_sync_single_for_device(struct device *hwdev,
+void __xen_dma_sync_single_for_device(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
 	if (!__generic_dma_ops(hwdev)->sync_single_for_device)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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 1XnrcZ-0003FJ-Cl; Mon, 10 Nov 2014 16:15:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrcX-0003EQ-5E
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:13 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	42/80-11608-094E0645; Mon, 10 Nov 2014 16:15:12 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24540 invoked from network); 10 Nov 2014 16:15:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798977"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbd-0000Mx-VZ;
	Mon, 10 Nov 2014 16:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:56 +0000
Message-ID: <1415636045-24669-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 04/13] arm64: introduce is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a boolean flag and an accessor function to check whether a
device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
CC: will.deacon@arm.com
---
 arch/arm64/include/asm/device.h      |    1 +
 arch/arm64/include/asm/dma-mapping.h |    6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index cf98b36..243ef25 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -21,6 +21,7 @@ struct dev_archdata {
 #ifdef CONFIG_IOMMU_API
 	void *iommu;			/* private IOMMU data */
 #endif
+	bool dma_coherent;
 };
 
 struct pdev_archdata {
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index adeae3f..e213dc4 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -54,11 +54,17 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
 
 static inline int set_arch_dma_coherent_ops(struct device *dev)
 {
+	dev->archdata.dma_coherent = true;
 	set_dma_ops(dev, &coherent_swiotlb_dma_ops);
 	return 0;
 }
 #define set_arch_dma_coherent_ops	set_arch_dma_coherent_ops
 
+static inline bool is_device_dma_coherent(struct device *dev)
+{
+	return dev->archdata.dma_coherent;
+}
+
 #include <asm-generic/dma-mapping-common.h>
 
 static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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 1XnrcZ-0003FJ-Cl; Mon, 10 Nov 2014 16:15:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrcX-0003EQ-5E
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:13 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	42/80-11608-094E0645; Mon, 10 Nov 2014 16:15:12 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24540 invoked from network); 10 Nov 2014 16:15:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798977"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbd-0000Mx-VZ;
	Mon, 10 Nov 2014 16:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:56 +0000
Message-ID: <1415636045-24669-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 04/13] arm64: introduce is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a boolean flag and an accessor function to check whether a
device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
CC: will.deacon@arm.com
---
 arch/arm64/include/asm/device.h      |    1 +
 arch/arm64/include/asm/dma-mapping.h |    6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index cf98b36..243ef25 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -21,6 +21,7 @@ struct dev_archdata {
 #ifdef CONFIG_IOMMU_API
 	void *iommu;			/* private IOMMU data */
 #endif
+	bool dma_coherent;
 };
 
 struct pdev_archdata {
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index adeae3f..e213dc4 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -54,11 +54,17 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
 
 static inline int set_arch_dma_coherent_ops(struct device *dev)
 {
+	dev->archdata.dma_coherent = true;
 	set_dma_ops(dev, &coherent_swiotlb_dma_ops);
 	return 0;
 }
 #define set_arch_dma_coherent_ops	set_arch_dma_coherent_ops
 
+static inline bool is_device_dma_coherent(struct device *dev)
+{
+	return dev->archdata.dma_coherent;
+}
+
 #include <asm-generic/dma-mapping-common.h>
 
 static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrce-0003Im-Sw; Mon, 10 Nov 2014 16:15: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@citrix.com>) id 1XnrcY-0003En-6D
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:14 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	BF/99-18267-194E0645; Mon, 10 Nov 2014 16:15:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24618 invoked from network); 10 Nov 2014 16:15:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798980"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-0v;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:59 +0000
Message-ID: <1415636045-24669-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 07/13] xen: add a dma_addr_t dev_addr
	argument to xen_dma_map_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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: david.vrabel@citrix.com
CC: konrad.wilk@oracle.com
---
 arch/arm/include/asm/xen/page-coherent.h   |    4 ++--
 arch/arm64/include/asm/xen/page-coherent.h |    4 ++--
 arch/x86/include/asm/xen/page-coherent.h   |    4 ++--
 drivers/xen/swiotlb-xen.c                  |    6 ++++--
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index d97b0b4..25d450c 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -29,8 +29,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs)
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
 	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
 }
diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
index dde3fc9..d7cd4c2 100644
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ b/arch/arm64/include/asm/xen/page-coherent.h
@@ -20,8 +20,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs)
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
 }
 
diff --git a/arch/x86/include/asm/xen/page-coherent.h b/arch/x86/include/asm/xen/page-coherent.h
index 7f02fe4..acd844c 100644
--- a/arch/x86/include/asm/xen/page-coherent.h
+++ b/arch/x86/include/asm/xen/page-coherent.h
@@ -22,8 +22,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs) { }
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs) { }
 
 static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..ad2c5eb 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -403,7 +403,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 		/* we are not interested in the dma_addr returned by
 		 * xen_dma_map_page, only in the potential cache flushes executed
 		 * by the function. */
-		xen_dma_map_page(dev, page, offset, size, dir, attrs);
+		xen_dma_map_page(dev, page, dev_addr, offset, size, dir, attrs);
 		return dev_addr;
 	}
 
@@ -417,7 +417,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 		return DMA_ERROR_CODE;
 
 	xen_dma_map_page(dev, pfn_to_page(map >> PAGE_SHIFT),
-					map & ~PAGE_MASK, size, dir, attrs);
+					dev_addr, map & ~PAGE_MASK, size, dir, attrs);
 	dev_addr = xen_phys_to_bus(map);
 
 	/*
@@ -574,6 +574,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 				return 0;
 			}
 			xen_dma_map_page(hwdev, pfn_to_page(map >> PAGE_SHIFT),
+						dev_addr,
 						map & ~PAGE_MASK,
 						sg->length,
 						dir,
@@ -584,6 +585,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 			 * xen_dma_map_page, only in the potential cache flushes executed
 			 * by the function. */
 			xen_dma_map_page(hwdev, pfn_to_page(paddr >> PAGE_SHIFT),
+						dev_addr,
 						paddr & ~PAGE_MASK,
 						sg->length,
 						dir,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrce-0003Im-Sw; Mon, 10 Nov 2014 16:15: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@citrix.com>) id 1XnrcY-0003En-6D
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:14 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	BF/99-18267-194E0645; Mon, 10 Nov 2014 16:15:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24618 invoked from network); 10 Nov 2014 16:15:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798980"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-0v;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:59 +0000
Message-ID: <1415636045-24669-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 07/13] xen: add a dma_addr_t dev_addr
	argument to xen_dma_map_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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: david.vrabel@citrix.com
CC: konrad.wilk@oracle.com
---
 arch/arm/include/asm/xen/page-coherent.h   |    4 ++--
 arch/arm64/include/asm/xen/page-coherent.h |    4 ++--
 arch/x86/include/asm/xen/page-coherent.h   |    4 ++--
 drivers/xen/swiotlb-xen.c                  |    6 ++++--
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index d97b0b4..25d450c 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -29,8 +29,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs)
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
 	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
 }
diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
index dde3fc9..d7cd4c2 100644
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ b/arch/arm64/include/asm/xen/page-coherent.h
@@ -20,8 +20,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs)
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
 }
 
diff --git a/arch/x86/include/asm/xen/page-coherent.h b/arch/x86/include/asm/xen/page-coherent.h
index 7f02fe4..acd844c 100644
--- a/arch/x86/include/asm/xen/page-coherent.h
+++ b/arch/x86/include/asm/xen/page-coherent.h
@@ -22,8 +22,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs) { }
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs) { }
 
 static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..ad2c5eb 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -403,7 +403,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 		/* we are not interested in the dma_addr returned by
 		 * xen_dma_map_page, only in the potential cache flushes executed
 		 * by the function. */
-		xen_dma_map_page(dev, page, offset, size, dir, attrs);
+		xen_dma_map_page(dev, page, dev_addr, offset, size, dir, attrs);
 		return dev_addr;
 	}
 
@@ -417,7 +417,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 		return DMA_ERROR_CODE;
 
 	xen_dma_map_page(dev, pfn_to_page(map >> PAGE_SHIFT),
-					map & ~PAGE_MASK, size, dir, attrs);
+					dev_addr, map & ~PAGE_MASK, size, dir, attrs);
 	dev_addr = xen_phys_to_bus(map);
 
 	/*
@@ -574,6 +574,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 				return 0;
 			}
 			xen_dma_map_page(hwdev, pfn_to_page(map >> PAGE_SHIFT),
+						dev_addr,
 						map & ~PAGE_MASK,
 						sg->length,
 						dir,
@@ -584,6 +585,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 			 * xen_dma_map_page, only in the potential cache flushes executed
 			 * by the function. */
 			xen_dma_map_page(hwdev, pfn_to_page(paddr >> PAGE_SHIFT),
+						dev_addr,
 						paddr & ~PAGE_MASK,
 						sg->length,
 						dir,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrcf-0003JW-MJ; Mon, 10 Nov 2014 16:15: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@citrix.com>) id 1XnrcZ-0003Ev-00
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:15 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	68/68-25727-294E0645; Mon, 10 Nov 2014 16:15:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415636108!11553432!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14846 invoked from network); 10 Nov 2014 16:15:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798983"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-4u;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:02 +0000
Message-ID: <1415636045-24669-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 10/13] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 function to find out whether a particular dma
mapping operation needs to bounce on the swiotlb buffer.

On ARM and ARM64, if the page involved is a foreign page and the device
is not coherent, we need to bounce because at unmap time we cannot
execute any required cache maintenance operations (we don't know how to
find the pfn from the mfn).

No change of behaviour for x86.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

Changes in v6:
- fix ts.

Changes in v5:
- fix indentation.
---
 arch/arm/include/asm/xen/page.h |    4 ++++
 arch/arm/xen/mm.c               |    7 +++++++
 arch/x86/include/asm/xen/page.h |    7 +++++++
 drivers/xen/swiotlb-xen.c       |    5 ++++-
 4 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 135c24a..68c739b 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
 #define xen_unmap(cookie) iounmap((cookie))
 
+bool xen_arch_need_swiotlb(struct device *dev,
+			   unsigned long pfn,
+			   unsigned long mfn);
+
 #endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 0e96023..1b087cd 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -102,6 +102,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
 	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
 }
 
+bool xen_arch_need_swiotlb(struct device *dev,
+			   unsigned long pfn,
+			   unsigned long mfn)
+{
+	return ((pfn != mfn) && !is_device_dma_coherent(dev));
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 				 unsigned int address_bits,
 				 dma_addr_t *dma_handle)
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c949923..f58ef6c 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
 #define xen_remap(cookie, size) ioremap((cookie), (size));
 #define xen_unmap(cookie) iounmap((cookie))
 
+static inline bool xen_arch_need_swiotlb(struct device *dev,
+					 unsigned long pfn,
+					 unsigned long mfn)
+{
+	return false;
+}
+
 #endif /* _ASM_X86_XEN_PAGE_H */
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ad2c5eb..3725ee4 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 	 * buffering it.
 	 */
 	if (dma_capable(dev, dev_addr, size) &&
-	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
+	    !range_straddles_page_boundary(phys, size) &&
+		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
+		!swiotlb_force) {
 		/* we are not interested in the dma_addr returned by
 		 * xen_dma_map_page, only in the potential cache flushes executed
 		 * by the function. */
@@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
 
 		if (swiotlb_force ||
+		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
 		    !dma_capable(hwdev, dev_addr, sg->length) ||
 		    range_straddles_page_boundary(paddr, sg->length)) {
 			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrcf-0003JW-MJ; Mon, 10 Nov 2014 16:15: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@citrix.com>) id 1XnrcZ-0003Ev-00
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:15 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	68/68-25727-294E0645; Mon, 10 Nov 2014 16:15:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415636108!11553432!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14846 invoked from network); 10 Nov 2014 16:15:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798983"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-4u;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:02 +0000
Message-ID: <1415636045-24669-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 10/13] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 function to find out whether a particular dma
mapping operation needs to bounce on the swiotlb buffer.

On ARM and ARM64, if the page involved is a foreign page and the device
is not coherent, we need to bounce because at unmap time we cannot
execute any required cache maintenance operations (we don't know how to
find the pfn from the mfn).

No change of behaviour for x86.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

Changes in v6:
- fix ts.

Changes in v5:
- fix indentation.
---
 arch/arm/include/asm/xen/page.h |    4 ++++
 arch/arm/xen/mm.c               |    7 +++++++
 arch/x86/include/asm/xen/page.h |    7 +++++++
 drivers/xen/swiotlb-xen.c       |    5 ++++-
 4 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 135c24a..68c739b 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
 #define xen_unmap(cookie) iounmap((cookie))
 
+bool xen_arch_need_swiotlb(struct device *dev,
+			   unsigned long pfn,
+			   unsigned long mfn);
+
 #endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 0e96023..1b087cd 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -102,6 +102,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
 	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
 }
 
+bool xen_arch_need_swiotlb(struct device *dev,
+			   unsigned long pfn,
+			   unsigned long mfn)
+{
+	return ((pfn != mfn) && !is_device_dma_coherent(dev));
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 				 unsigned int address_bits,
 				 dma_addr_t *dma_handle)
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c949923..f58ef6c 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
 #define xen_remap(cookie, size) ioremap((cookie), (size));
 #define xen_unmap(cookie) iounmap((cookie))
 
+static inline bool xen_arch_need_swiotlb(struct device *dev,
+					 unsigned long pfn,
+					 unsigned long mfn)
+{
+	return false;
+}
+
 #endif /* _ASM_X86_XEN_PAGE_H */
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ad2c5eb..3725ee4 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 	 * buffering it.
 	 */
 	if (dma_capable(dev, dev_addr, size) &&
-	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
+	    !range_straddles_page_boundary(phys, size) &&
+		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
+		!swiotlb_force) {
 		/* we are not interested in the dma_addr returned by
 		 * xen_dma_map_page, only in the potential cache flushes executed
 		 * by the function. */
@@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
 
 		if (swiotlb_force ||
+		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
 		    !dma_capable(hwdev, dev_addr, sg->length) ||
 		    range_straddles_page_boundary(paddr, sg->length)) {
 			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrcg-0003Kl-HL; Mon, 10 Nov 2014 16:15: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@citrix.com>) id 1XnrcZ-0003F8-BY
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:15 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	D7/41-23865-294E0645; Mon, 10 Nov 2014 16:15:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24722 invoked from network); 10 Nov 2014 16:15:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798982"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-3E;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:01 +0000
Message-ID: <1415636045-24669-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 09/13] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Merge xen/mm32.c into xen/mm.c.
As a consequence the code gets compiled on arm64 too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/Makefile                      |    2 +-
 arch/arm/xen/mm.c                          |   86 +++++++++++++++++++++++++
 arch/arm/xen/mm32.c                        |   96 ----------------------------
 arch/arm64/include/asm/xen/page-coherent.h |   44 +------------
 4 files changed, 88 insertions(+), 140 deletions(-)
 delete mode 100644 arch/arm/xen/mm32.c

diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1f85bfe..1296952 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o hypercall.o grant-table.o p2m.o mm.o mm32.o
+obj-y		:= enlighten.o hypercall.o grant-table.o p2m.o mm.o
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index b0e77de..0e96023 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -1,6 +1,10 @@
+#include <linux/cpu.h>
+#include <linux/dma-mapping.h>
 #include <linux/bootmem.h>
 #include <linux/gfp.h>
+#include <linux/highmem.h>
 #include <linux/export.h>
+#include <linux/of_address.h>
 #include <linux/slab.h>
 #include <linux/types.h>
 #include <linux/dma-mapping.h>
@@ -16,6 +20,88 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
+enum dma_cache_op {
+       DMA_UNMAP,
+       DMA_MAP,
+};
+
+/* functions called by SWIOTLB */
+
+static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
+	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
+{
+	unsigned long pfn;
+	size_t left = size;
+
+	pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
+	offset %= PAGE_SIZE;
+
+	do {
+		size_t len = left;
+	
+		BUG_ON(pfn_valid(pfn));
+
+		/* TODO: cache flush */
+
+		offset = 0;
+		pfn++;
+		left -= len;
+	} while (left);
+}
+
+static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir)
+{
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
+}
+
+static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir)
+{
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
+}
+
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
+}
+
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir,
+		struct dma_attrs *attrs)
+
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
+}
+
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
+}
+
+void __xen_dma_sync_single_for_device(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 				 unsigned int address_bits,
 				 dma_addr_t *dma_handle)
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
deleted file mode 100644
index d611c4b..0000000
--- a/arch/arm/xen/mm32.c
+++ /dev/null
@@ -1,96 +0,0 @@
-#include <linux/cpu.h>
-#include <linux/dma-mapping.h>
-#include <linux/gfp.h>
-#include <linux/highmem.h>
-
-#include <xen/features.h>
-enum dma_cache_op {
-       DMA_UNMAP,
-       DMA_MAP,
-};
-
-/* functions called by SWIOTLB */
-
-static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
-	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
-{
-	unsigned long pfn;
-	size_t left = size;
-
-	pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
-	offset %= PAGE_SIZE;
-
-	do {
-		size_t len = left;
-	
-		BUG_ON(pfn_valid(pfn));
-
-		/* TODO: cache flush */
-
-		offset = 0;
-		pfn++;
-		left -= len;
-	} while (left);
-}
-
-static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir)
-{
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
-}
-
-static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir)
-{
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
-}
-
-void __xen_dma_map_page(struct device *hwdev, struct page *page,
-	     dma_addr_t dev_addr, unsigned long offset, size_t size,
-	     enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		return;
-
-	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
-}
-
-void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs)
-
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		return;
-
-	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
-}
-
-int __init xen_mm32_init(void)
-{
-	if (!xen_initial_domain())
-		return 0;
-
-	return 0;
-}
-arch_initcall(xen_mm32_init);
diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
index d7cd4c2..2052102 100644
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ b/arch/arm64/include/asm/xen/page-coherent.h
@@ -1,43 +1 @@
-#ifndef _ASM_ARM64_XEN_PAGE_COHERENT_H
-#define _ASM_ARM64_XEN_PAGE_COHERENT_H
-
-#include <asm/page.h>
-#include <linux/dma-attrs.h>
-#include <linux/dma-mapping.h>
-
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
-		dma_addr_t *dma_handle, gfp_t flags,
-		struct dma_attrs *attrs)
-{
-	return __generic_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags, attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
-		void *cpu_addr, dma_addr_t dma_handle,
-		struct dma_attrs *attrs)
-{
-	__generic_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     dma_addr_t dev_addr, unsigned long offset, size_t size,
-	     enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-}
-
-static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs)
-{
-}
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-}
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-}
-#endif /* _ASM_ARM64_XEN_PAGE_COHERENT_H */
+#include <../../arm/include/asm/xen/page-coherent.h>
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrcg-0003Kl-HL; Mon, 10 Nov 2014 16:15: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@citrix.com>) id 1XnrcZ-0003F8-BY
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:15 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	D7/41-23865-294E0645; Mon, 10 Nov 2014 16:15:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24722 invoked from network); 10 Nov 2014 16:15:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798982"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-3E;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:01 +0000
Message-ID: <1415636045-24669-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 09/13] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Merge xen/mm32.c into xen/mm.c.
As a consequence the code gets compiled on arm64 too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/Makefile                      |    2 +-
 arch/arm/xen/mm.c                          |   86 +++++++++++++++++++++++++
 arch/arm/xen/mm32.c                        |   96 ----------------------------
 arch/arm64/include/asm/xen/page-coherent.h |   44 +------------
 4 files changed, 88 insertions(+), 140 deletions(-)
 delete mode 100644 arch/arm/xen/mm32.c

diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1f85bfe..1296952 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o hypercall.o grant-table.o p2m.o mm.o mm32.o
+obj-y		:= enlighten.o hypercall.o grant-table.o p2m.o mm.o
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index b0e77de..0e96023 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -1,6 +1,10 @@
+#include <linux/cpu.h>
+#include <linux/dma-mapping.h>
 #include <linux/bootmem.h>
 #include <linux/gfp.h>
+#include <linux/highmem.h>
 #include <linux/export.h>
+#include <linux/of_address.h>
 #include <linux/slab.h>
 #include <linux/types.h>
 #include <linux/dma-mapping.h>
@@ -16,6 +20,88 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
+enum dma_cache_op {
+       DMA_UNMAP,
+       DMA_MAP,
+};
+
+/* functions called by SWIOTLB */
+
+static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
+	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
+{
+	unsigned long pfn;
+	size_t left = size;
+
+	pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
+	offset %= PAGE_SIZE;
+
+	do {
+		size_t len = left;
+	
+		BUG_ON(pfn_valid(pfn));
+
+		/* TODO: cache flush */
+
+		offset = 0;
+		pfn++;
+		left -= len;
+	} while (left);
+}
+
+static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir)
+{
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
+}
+
+static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir)
+{
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
+}
+
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
+}
+
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir,
+		struct dma_attrs *attrs)
+
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
+}
+
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
+}
+
+void __xen_dma_sync_single_for_device(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 				 unsigned int address_bits,
 				 dma_addr_t *dma_handle)
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
deleted file mode 100644
index d611c4b..0000000
--- a/arch/arm/xen/mm32.c
+++ /dev/null
@@ -1,96 +0,0 @@
-#include <linux/cpu.h>
-#include <linux/dma-mapping.h>
-#include <linux/gfp.h>
-#include <linux/highmem.h>
-
-#include <xen/features.h>
-enum dma_cache_op {
-       DMA_UNMAP,
-       DMA_MAP,
-};
-
-/* functions called by SWIOTLB */
-
-static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
-	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
-{
-	unsigned long pfn;
-	size_t left = size;
-
-	pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
-	offset %= PAGE_SIZE;
-
-	do {
-		size_t len = left;
-	
-		BUG_ON(pfn_valid(pfn));
-
-		/* TODO: cache flush */
-
-		offset = 0;
-		pfn++;
-		left -= len;
-	} while (left);
-}
-
-static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir)
-{
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
-}
-
-static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir)
-{
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
-}
-
-void __xen_dma_map_page(struct device *hwdev, struct page *page,
-	     dma_addr_t dev_addr, unsigned long offset, size_t size,
-	     enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		return;
-
-	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
-}
-
-void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs)
-
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		return;
-
-	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
-}
-
-int __init xen_mm32_init(void)
-{
-	if (!xen_initial_domain())
-		return 0;
-
-	return 0;
-}
-arch_initcall(xen_mm32_init);
diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
index d7cd4c2..2052102 100644
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ b/arch/arm64/include/asm/xen/page-coherent.h
@@ -1,43 +1 @@
-#ifndef _ASM_ARM64_XEN_PAGE_COHERENT_H
-#define _ASM_ARM64_XEN_PAGE_COHERENT_H
-
-#include <asm/page.h>
-#include <linux/dma-attrs.h>
-#include <linux/dma-mapping.h>
-
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
-		dma_addr_t *dma_handle, gfp_t flags,
-		struct dma_attrs *attrs)
-{
-	return __generic_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags, attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
-		void *cpu_addr, dma_addr_t dma_handle,
-		struct dma_attrs *attrs)
-{
-	__generic_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     dma_addr_t dev_addr, unsigned long offset, size_t size,
-	     enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-}
-
-static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs)
-{
-}
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-}
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-}
-#endif /* _ASM_ARM64_XEN_PAGE_COHERENT_H */
+#include <../../arm/include/asm/xen/page-coherent.h>
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrch-0003Ln-9o; Mon, 10 Nov 2014 16:15:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xnrca-0003FT-Dy
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:16 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	56/82-28296-394E0645; Mon, 10 Nov 2014 16:15:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415636108!11553432!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14949 invoked from network); 10 Nov 2014 16:15:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798978"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-0O;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:58 +0000
Message-ID: <1415636045-24669-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 06/13] xen/arm: use is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use is_device_dma_coherent to check whether we need to issue cache
maintenance operations rather than checking on the existence of a
particular dma_ops function for the device.

This is correct because coherent devices don't need cache maintenance
operations - arm_coherent_dma_ops does not set the hooks that we
were previously checking for existance.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 arch/arm/xen/mm32.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index b26bf84..7824498 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -50,7 +50,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		struct dma_attrs *attrs)
 
 {
-	if (!__generic_dma_ops(hwdev)->unmap_page)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
 		return;
@@ -61,7 +61,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
-	if (!__generic_dma_ops(hwdev)->sync_single_for_cpu)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
@@ -69,7 +69,7 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 void __xen_dma_sync_single_for_device(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
-	if (!__generic_dma_ops(hwdev)->sync_single_for_device)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrch-0003Ln-9o; Mon, 10 Nov 2014 16:15:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xnrca-0003FT-Dy
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:16 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	56/82-28296-394E0645; Mon, 10 Nov 2014 16:15:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415636108!11553432!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14949 invoked from network); 10 Nov 2014 16:15:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798978"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-0O;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:13:58 +0000
Message-ID: <1415636045-24669-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 06/13] xen/arm: use is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use is_device_dma_coherent to check whether we need to issue cache
maintenance operations rather than checking on the existence of a
particular dma_ops function for the device.

This is correct because coherent devices don't need cache maintenance
operations - arm_coherent_dma_ops does not set the hooks that we
were previously checking for existance.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 arch/arm/xen/mm32.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index b26bf84..7824498 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -50,7 +50,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		struct dma_attrs *attrs)
 
 {
-	if (!__generic_dma_ops(hwdev)->unmap_page)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
 		return;
@@ -61,7 +61,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
-	if (!__generic_dma_ops(hwdev)->sync_single_for_cpu)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
@@ -69,7 +69,7 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 void __xen_dma_sync_single_for_device(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
-	if (!__generic_dma_ops(hwdev)->sync_single_for_device)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrci-0003NW-AW; Mon, 10 Nov 2014 16:15:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xnrca-0003Fh-HX
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:16 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	6B/56-17958-394E0645; Mon, 10 Nov 2014 16:15:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24824 invoked from network); 10 Nov 2014 16:15:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798979"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-1R;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:00 +0000
Message-ID: <1415636045-24669-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 08/13] xen/arm: use hypercall to flush caches
	in map_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

In xen_dma_map_page, if the page is a local page, call the native
map_page dma_ops. If the page is foreign, call __xen_dma_map_page that
issues any required cache maintenane operations via hypercall.

The reason for doing this is that the native dma_ops map_page could
allocate buffers than need to be freed. If the page is foreign we don't
call the native unmap_page dma_ops function, resulting in a memory leak.

Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/page-coherent.h |    9 ++++++++-
 arch/arm/xen/mm32.c                      |   12 ++++++++++++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index 25d450c..36b79a8 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -5,6 +5,9 @@
 #include <linux/dma-attrs.h>
 #include <linux/dma-mapping.h>
 
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs);
 void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs);
@@ -32,7 +35,11 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 	     dma_addr_t dev_addr, unsigned long offset, size_t size,
 	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
-	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
+	if (PFN_DOWN(dev_addr) == page_to_pfn(page)) {
+		if (__generic_dma_ops(hwdev)->map_page)
+			__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
+	} else
+		__xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
 }
 
 void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 7824498..d611c4b 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -45,6 +45,18 @@ static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
 }
 
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
+}
+
 void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrci-0003NW-AW; Mon, 10 Nov 2014 16:15:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xnrca-0003Fh-HX
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:15:16 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	6B/56-17958-394E0645; Mon, 10 Nov 2014 16:15:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415636105!11487291!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24824 invoked from network); 10 Nov 2014 16:15:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:15:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189798979"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-1R;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:00 +0000
Message-ID: <1415636045-24669-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 08/13] xen/arm: use hypercall to flush caches
	in map_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

In xen_dma_map_page, if the page is a local page, call the native
map_page dma_ops. If the page is foreign, call __xen_dma_map_page that
issues any required cache maintenane operations via hypercall.

The reason for doing this is that the native dma_ops map_page could
allocate buffers than need to be freed. If the page is foreign we don't
call the native unmap_page dma_ops function, resulting in a memory leak.

Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/page-coherent.h |    9 ++++++++-
 arch/arm/xen/mm32.c                      |   12 ++++++++++++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index 25d450c..36b79a8 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -5,6 +5,9 @@
 #include <linux/dma-attrs.h>
 #include <linux/dma-mapping.h>
 
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs);
 void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs);
@@ -32,7 +35,11 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 	     dma_addr_t dev_addr, unsigned long offset, size_t size,
 	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
-	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
+	if (PFN_DOWN(dev_addr) == page_to_pfn(page)) {
+		if (__generic_dma_ops(hwdev)->map_page)
+			__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
+	} else
+		__xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
 }
 
 void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 7824498..d611c4b 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -45,6 +45,18 @@ static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
 }
 
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
+}
+
 void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrcy-0003bh-A4; Mon, 10 Nov 2014 16:15:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xnrcx-0003al-59
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 16:15:39 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	DB/3C-27785-AA4E0645; Mon, 10 Nov 2014 16:15:38 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415636135!12554139!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24243 invoked from network); 10 Nov 2014 16:15:37 -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;
	10 Nov 2014 16:15:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; 
	d="scan'208,217";a="189799397"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:15:23 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xnrcg-0000O9-W9;
	Mon, 10 Nov 2014 16:15:22 +0000
Message-ID: <5460E49A.5020000@eu.citrix.com>
Date: Mon, 10 Nov 2014 16:15:22 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Meng Xu <xumengpanda@gmail.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>	<5460B550.9000306@eu.citrix.com>	<CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>	<5460DC65.8000909@eu.citrix.com>
	<CAENZ-+=-9VK7D+=nNdM+PP3OmJQmS=CDWKPQ6_uXzNG1qiHdxg@mail.gmail.com>
In-Reply-To: <CAENZ-+=-9VK7D+=nNdM+PP3OmJQmS=CDWKPQ6_uXzNG1qiHdxg@mail.gmail.com>
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4251999889006703399=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4251999889006703399==
Content-Type: multipart/alternative;
	boundary="------------020706070507000705090901"

--------------020706070507000705090901
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Length: 1300
Content-Transfer-Encoding: quoted-printable

On 11/10/2014 04:04 PM, Meng Xu wrote:
>
>
> 2014-11-10 10:40 GMT-05:00 George Dunlap <george.dunlap@eu.citrix.com 
> <mailto:george.dunlap@eu.citrix.com>>:
>
>     On 11/10/2014 03:29 PM, Meng Xu wrote:
>>     I'm not sure if I should resend the patch just to change the
>>     commit log and add the reason of why doing this.
>>
>>     I want to first add the reason. If I should resend the patch set,
>>     please let me know.
>>
>>     2014-11-10 7:53 GMT-05:00 George Dunlap
>>     <george.dunlap@eu.citrix.com <mailto:george.dunlap@eu.citrix.com>>:
>>
>>         On 10/25/2014 03:16 PM, Meng Xu wrote:
>>
>>             Move call to rt_update_deadline from _alloc to _insert;
>>
>>
>>     The runq queue lock is not grabbed when  =E2=80=8Brt_update_deadline is
>>     called in rt_alloc_vdata function, which may cause race condition.
>
>     Can you not grab the lock in rt_alloc_vdata=3F
>
>
> =E2=80=8BYes. Because when we allocate a rt_vcpu, only one cpu will do that. 
> In addition, before the rt_vcpu is inserted into the runq, we won't 
> have more than one cpu operate on this rt_vcpu.=E2=80=8B

Right, well that's important information to help someone reading the 
patch understand what's going on.

Thanks for being flexible. :-)

  -George


--------------020706070507000705090901
Content-Type: text/html; charset="utf-8"
Content-Length: 4598
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 11/10/2014 04:04 PM, Meng Xu wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAENZ-+=3D-9VK7D+=3DnNdM+PP3OmJQmS=3DCDWKPQ6_uXzNG1qiHdxg@mail.gmail.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
      <div dir=3D"ltr">
        <div class=3D"gmail_default" style=3D"font-size:small"><br>
        </div>
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">2014-11-10 10:40 GMT-05:00 George
            Dunlap <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:george.dunlap@eu.citrix.com"
                target=3D"_blank">george.dunlap@eu.citrix.com</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 bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
                  <div>On 11/10/2014 03:29 PM, Meng Xu wrote:<br>
                  </div>
                  <blockquote type=3D"cite">
                    <div dir=3D"ltr">
                      <div style=3D"font-size:small">I'm not sure if I
                        should resend the patch just to change the
                        commit log and add the reason of why doing
                        this.=C2=A0</div>
                      <div style=3D"font-size:small"><br>
                      </div>
                      <div style=3D"font-size:small">I want to first add
                        the reason. If I should resend the patch set,
                        please let me know.=C2=A0</div>
                      <div class=3D"gmail_extra"><br>
                        <div class=3D"gmail_quote">2014-11-10 7:53
                          GMT-05:00 George Dunlap <span dir=3D"ltr">&lt;<a
                              moz-do-not-send=3D"true"
                              href=3D"mailto:george.dunlap@eu.citrix.com"
                              target=3D"_blank">george.dunlap@eu.citrix.com</a>&gt;</span>:<br>
                          <blockquote class=3D"gmail_quote"
                            style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On
                              10/25/2014 03:16 PM, Meng Xu wrote:<br>
                              <blockquote class=3D"gmail_quote"
                                style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Move

                                call to rt_update_deadline from _alloc
                                to _insert;<br>
                              </blockquote>
                            </span></blockquote>
                          <div><br>
                          </div>
                          <div>
                            <div style=3D"font-size:small">The runq queue
                              lock is not grabbed when
                              =C2=A0=E2=80=8Brt_update_deadline is called in=C2=A0<span
                                style=3D"font-family:arial,sans-serif;font-size:14.3999996185303px">rt_alloc_vdata

                                function, which may cause race
                                condition.</span></div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                  <br>
                </span> Can you not grab the lock in rt_alloc_vdata=3F=C2=A0</div>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class=3D"gmail_default" style=3D"font-size:small">=E2=80=8BYes.
                Because when we allocate a rt_vcpu, only one cpu will do
                that. In addition, before the rt_vcpu is inserted into
                the runq, we won't have more than one cpu operate on
                this rt_vcpu.=E2=80=8B</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Right, well that's important information to help someone reading the
    patch understand what's going on.<br>
    <br>
    Thanks for being flexible. :-)<br>
    <br>
    =C2=A0-George<br>
    <br>
  </body>
</html>

--------------020706070507000705090901--


--===============4251999889006703399==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4251999889006703399==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 16:15:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnrcy-0003bh-A4; Mon, 10 Nov 2014 16:15:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xnrcx-0003al-59
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 16:15:39 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	DB/3C-27785-AA4E0645; Mon, 10 Nov 2014 16:15:38 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415636135!12554139!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24243 invoked from network); 10 Nov 2014 16:15:37 -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;
	10 Nov 2014 16:15:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; 
	d="scan'208,217";a="189799397"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:15:23 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xnrcg-0000O9-W9;
	Mon, 10 Nov 2014 16:15:22 +0000
Message-ID: <5460E49A.5020000@eu.citrix.com>
Date: Mon, 10 Nov 2014 16:15:22 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Meng Xu <xumengpanda@gmail.com>
References: <1414246599-3914-1-git-send-email-mengxu@cis.upenn.edu>	<1414246599-3914-3-git-send-email-mengxu@cis.upenn.edu>	<5460B550.9000306@eu.citrix.com>	<CAENZ-+ky2ZQGhHfyCJe2Yy+eVJqCfo-RQLxD-dDLJ=xoqUP9Sg@mail.gmail.com>	<5460DC65.8000909@eu.citrix.com>
	<CAENZ-+=-9VK7D+=nNdM+PP3OmJQmS=CDWKPQ6_uXzNG1qiHdxg@mail.gmail.com>
In-Reply-To: <CAENZ-+=-9VK7D+=nNdM+PP3OmJQmS=CDWKPQ6_uXzNG1qiHdxg@mail.gmail.com>
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data
	in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4251999889006703399=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4251999889006703399==
Content-Type: multipart/alternative;
	boundary="------------020706070507000705090901"

--------------020706070507000705090901
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Length: 1300
Content-Transfer-Encoding: quoted-printable

On 11/10/2014 04:04 PM, Meng Xu wrote:
>
>
> 2014-11-10 10:40 GMT-05:00 George Dunlap <george.dunlap@eu.citrix.com 
> <mailto:george.dunlap@eu.citrix.com>>:
>
>     On 11/10/2014 03:29 PM, Meng Xu wrote:
>>     I'm not sure if I should resend the patch just to change the
>>     commit log and add the reason of why doing this.
>>
>>     I want to first add the reason. If I should resend the patch set,
>>     please let me know.
>>
>>     2014-11-10 7:53 GMT-05:00 George Dunlap
>>     <george.dunlap@eu.citrix.com <mailto:george.dunlap@eu.citrix.com>>:
>>
>>         On 10/25/2014 03:16 PM, Meng Xu wrote:
>>
>>             Move call to rt_update_deadline from _alloc to _insert;
>>
>>
>>     The runq queue lock is not grabbed when  =E2=80=8Brt_update_deadline is
>>     called in rt_alloc_vdata function, which may cause race condition.
>
>     Can you not grab the lock in rt_alloc_vdata=3F
>
>
> =E2=80=8BYes. Because when we allocate a rt_vcpu, only one cpu will do that. 
> In addition, before the rt_vcpu is inserted into the runq, we won't 
> have more than one cpu operate on this rt_vcpu.=E2=80=8B

Right, well that's important information to help someone reading the 
patch understand what's going on.

Thanks for being flexible. :-)

  -George


--------------020706070507000705090901
Content-Type: text/html; charset="utf-8"
Content-Length: 4598
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 11/10/2014 04:04 PM, Meng Xu wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAENZ-+=3D-9VK7D+=3DnNdM+PP3OmJQmS=3DCDWKPQ6_uXzNG1qiHdxg@mail.gmail.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
      <div dir=3D"ltr">
        <div class=3D"gmail_default" style=3D"font-size:small"><br>
        </div>
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">2014-11-10 10:40 GMT-05:00 George
            Dunlap <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:george.dunlap@eu.citrix.com"
                target=3D"_blank">george.dunlap@eu.citrix.com</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 bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
                  <div>On 11/10/2014 03:29 PM, Meng Xu wrote:<br>
                  </div>
                  <blockquote type=3D"cite">
                    <div dir=3D"ltr">
                      <div style=3D"font-size:small">I'm not sure if I
                        should resend the patch just to change the
                        commit log and add the reason of why doing
                        this.=C2=A0</div>
                      <div style=3D"font-size:small"><br>
                      </div>
                      <div style=3D"font-size:small">I want to first add
                        the reason. If I should resend the patch set,
                        please let me know.=C2=A0</div>
                      <div class=3D"gmail_extra"><br>
                        <div class=3D"gmail_quote">2014-11-10 7:53
                          GMT-05:00 George Dunlap <span dir=3D"ltr">&lt;<a
                              moz-do-not-send=3D"true"
                              href=3D"mailto:george.dunlap@eu.citrix.com"
                              target=3D"_blank">george.dunlap@eu.citrix.com</a>&gt;</span>:<br>
                          <blockquote class=3D"gmail_quote"
                            style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On
                              10/25/2014 03:16 PM, Meng Xu wrote:<br>
                              <blockquote class=3D"gmail_quote"
                                style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Move

                                call to rt_update_deadline from _alloc
                                to _insert;<br>
                              </blockquote>
                            </span></blockquote>
                          <div><br>
                          </div>
                          <div>
                            <div style=3D"font-size:small">The runq queue
                              lock is not grabbed when
                              =C2=A0=E2=80=8Brt_update_deadline is called in=C2=A0<span
                                style=3D"font-family:arial,sans-serif;font-size:14.3999996185303px">rt_alloc_vdata

                                function, which may cause race
                                condition.</span></div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                  <br>
                </span> Can you not grab the lock in rt_alloc_vdata=3F=C2=A0</div>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class=3D"gmail_default" style=3D"font-size:small">=E2=80=8BYes.
                Because when we allocate a rt_vcpu, only one cpu will do
                that. In addition, before the rt_vcpu is inserted into
                the runq, we won't have more than one cpu operate on
                this rt_vcpu.=E2=80=8B</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Right, well that's important information to help someone reading the
    patch understand what's going on.<br>
    <br>
    Thanks for being flexible. :-)<br>
    <br>
    =C2=A0-George<br>
    <br>
  </body>
</html>

--------------020706070507000705090901--


--===============4251999889006703399==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4251999889006703399==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 16:18:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnrfS-0004b4-Un; Mon, 10 Nov 2014 16:18:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrfQ-0004aU-WD
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:18:13 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	7B/F0-22777-445E0645; Mon, 10 Nov 2014 16:18:12 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415636287!11579986!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2962 invoked from network); 10 Nov 2014 16:18:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:18:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189800779"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:18:00 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-6m;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:05 +0000
Message-ID: <1415636045-24669-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 13/13] swiotlb-xen: remove BUG_ON in
	xen_bus_to_phys
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On x86 truncation cannot occur because config XEN depends on X86_64 ||
(X86_32 && X86_PAE).

On ARM truncation can occur without CONFIG_ARM_LPAE, when the dma
operation involves foreign grants. However in that case the physical
address returned by xen_bus_to_phys is actually invalid (there is no mfn
to pfn tracking for foreign grants on ARM) and it is not used.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/swiotlb-xen.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 498b654..153cf14 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
 	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
 	phys_addr_t paddr = dma;
 
-	BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
-
 	paddr |= baddr & ~PAGE_MASK;
 
 	return paddr;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:18:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnrfS-0004b4-Un; Mon, 10 Nov 2014 16:18:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrfQ-0004aU-WD
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:18:13 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	7B/F0-22777-445E0645; Mon, 10 Nov 2014 16:18:12 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415636287!11579986!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2962 invoked from network); 10 Nov 2014 16:18:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:18:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="189800779"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:18:00 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-6m;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:05 +0000
Message-ID: <1415636045-24669-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 13/13] swiotlb-xen: remove BUG_ON in
	xen_bus_to_phys
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On x86 truncation cannot occur because config XEN depends on X86_64 ||
(X86_32 && X86_PAE).

On ARM truncation can occur without CONFIG_ARM_LPAE, when the dma
operation involves foreign grants. However in that case the physical
address returned by xen_bus_to_phys is actually invalid (there is no mfn
to pfn tracking for foreign grants on ARM) and it is not used.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/swiotlb-xen.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 498b654..153cf14 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
 	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
 	phys_addr_t paddr = dma;
 
-	BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
-
 	paddr |= baddr & ~PAGE_MASK;
 
 	return paddr;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:19:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:19:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnrgA-0004kY-Cw; Mon, 10 Nov 2014 16:18:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xnrg9-0004kI-GH
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:18:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/B2-09936-075E0645; Mon, 10 Nov 2014 16:18:56 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415636333!12434787!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32079 invoked from network); 10 Nov 2014 16:18:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:18:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191239752"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:17:52 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-5P;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:03 +0000
Message-ID: <1415636045-24669-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 11/13] xen/arm: introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce support for new hypercall GNTTABOP_cache_flush.
Use it to perform cache flashing on pages used for dma when necessary.

If GNTTABOP_cache_flush is supported by the hypervisor, we don't need to
bounce dma map operations that involve foreign grants and non-coherent
devices.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---

Changes in v5:
- rename hypercall_flush to hypercall_cflush;
- remove spurious change.

Changes in v4:
- add comment;
- avoid bouncing dma map operations that involve foreign grants and
non-coherent devices if GNTTABOP_cache_flush is provided by Xen.

Changes in v3:
- fix the cache maintenance op call to match what Linux does natively;
- update the hypercall interface to match Xen.

Changes in v2:
- update the hypercall interface to match Xen;
- call the interface on a single page at a time.
---
 arch/arm/xen/mm.c                   |   34 ++++++++++++++++++++++++++++++++--
 include/xen/interface/grant_table.h |   19 +++++++++++++++++++
 2 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 1b087cd..49bfec9 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -12,6 +12,7 @@
 #include <linux/swiotlb.h>
 
 #include <xen/xen.h>
+#include <xen/interface/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/swiotlb-xen.h>
 
@@ -24,12 +25,14 @@ enum dma_cache_op {
        DMA_UNMAP,
        DMA_MAP,
 };
+static bool hypercall_cflush = false;
 
 /* functions called by SWIOTLB */
 
 static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
 {
+	struct gnttab_cache_flush cflush;
 	unsigned long pfn;
 	size_t left = size;
 
@@ -41,7 +44,26 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	
 		BUG_ON(pfn_valid(pfn));
 
-		/* TODO: cache flush */
+		/* buffers in highmem or foreign pages cannot cross page
+		 * boundaries */
+		if (len + offset > PAGE_SIZE)
+			len = PAGE_SIZE - offset;
+
+		cflush.op = 0;
+		cflush.a.dev_bus_addr = pfn << PAGE_SHIFT;
+		cflush.offset = offset;
+		cflush.length = len;
+
+		if (op == DMA_UNMAP && dir != DMA_TO_DEVICE)
+			cflush.op = GNTTAB_CACHE_INVAL;
+		if (op == DMA_MAP) {
+			if (dir == DMA_FROM_DEVICE)
+				cflush.op = GNTTAB_CACHE_INVAL;
+			else
+				cflush.op = GNTTAB_CACHE_CLEAN;
+		}
+		if (cflush.op)
+			HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1);
 
 		offset = 0;
 		pfn++;
@@ -106,7 +128,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
 			   unsigned long pfn,
 			   unsigned long mfn)
 {
-	return ((pfn != mfn) && !is_device_dma_coherent(dev));
+	return (!hypercall_cflush && (pfn != mfn) && !is_device_dma_coherent(dev));
 }
 
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
@@ -149,10 +171,18 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 
 int __init xen_mm_init(void)
 {
+	struct gnttab_cache_flush cflush;
 	if (!xen_initial_domain())
 		return 0;
 	xen_swiotlb_init(1, false);
 	xen_dma_ops = &xen_swiotlb_dma_ops;
+
+	cflush.op = 0;
+	cflush.a.dev_bus_addr = 0;
+	cflush.offset = 0;
+	cflush.length = 0;
+	if (HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1) != -ENOSYS)
+		hypercall_cflush = true;
 	return 0;
 }
 arch_initcall(xen_mm_init);
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index e40fae9..bcce564 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -479,6 +479,25 @@ struct gnttab_get_version {
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_version);
 
 /*
+ * Issue one or more cache maintenance operations on a portion of a
+ * page granted to the calling domain by a foreign domain.
+ */
+#define GNTTABOP_cache_flush          12
+struct gnttab_cache_flush {
+    union {
+        uint64_t dev_bus_addr;
+        grant_ref_t ref;
+    } a;
+    uint16_t offset;   /* offset from start of grant */
+    uint16_t length;   /* size within the grant */
+#define GNTTAB_CACHE_CLEAN          (1<<0)
+#define GNTTAB_CACHE_INVAL          (1<<1)
+#define GNTTAB_CACHE_SOURCE_GREF    (1<<31)
+    uint32_t op;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_cache_flush);
+
+/*
  * Bitfield values for update_pin_status.flags.
  */
  /* Map the grant entry for access by I/O devices. */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:19:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:19:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnrgA-0004kY-Cw; Mon, 10 Nov 2014 16:18:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xnrg9-0004kI-GH
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:18:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/B2-09936-075E0645; Mon, 10 Nov 2014 16:18:56 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415636333!12434787!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32079 invoked from network); 10 Nov 2014 16:18:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:18:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191239752"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:17:52 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-5P;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:03 +0000
Message-ID: <1415636045-24669-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 11/13] xen/arm: introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce support for new hypercall GNTTABOP_cache_flush.
Use it to perform cache flashing on pages used for dma when necessary.

If GNTTABOP_cache_flush is supported by the hypervisor, we don't need to
bounce dma map operations that involve foreign grants and non-coherent
devices.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---

Changes in v5:
- rename hypercall_flush to hypercall_cflush;
- remove spurious change.

Changes in v4:
- add comment;
- avoid bouncing dma map operations that involve foreign grants and
non-coherent devices if GNTTABOP_cache_flush is provided by Xen.

Changes in v3:
- fix the cache maintenance op call to match what Linux does natively;
- update the hypercall interface to match Xen.

Changes in v2:
- update the hypercall interface to match Xen;
- call the interface on a single page at a time.
---
 arch/arm/xen/mm.c                   |   34 ++++++++++++++++++++++++++++++++--
 include/xen/interface/grant_table.h |   19 +++++++++++++++++++
 2 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 1b087cd..49bfec9 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -12,6 +12,7 @@
 #include <linux/swiotlb.h>
 
 #include <xen/xen.h>
+#include <xen/interface/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/swiotlb-xen.h>
 
@@ -24,12 +25,14 @@ enum dma_cache_op {
        DMA_UNMAP,
        DMA_MAP,
 };
+static bool hypercall_cflush = false;
 
 /* functions called by SWIOTLB */
 
 static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
 {
+	struct gnttab_cache_flush cflush;
 	unsigned long pfn;
 	size_t left = size;
 
@@ -41,7 +44,26 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	
 		BUG_ON(pfn_valid(pfn));
 
-		/* TODO: cache flush */
+		/* buffers in highmem or foreign pages cannot cross page
+		 * boundaries */
+		if (len + offset > PAGE_SIZE)
+			len = PAGE_SIZE - offset;
+
+		cflush.op = 0;
+		cflush.a.dev_bus_addr = pfn << PAGE_SHIFT;
+		cflush.offset = offset;
+		cflush.length = len;
+
+		if (op == DMA_UNMAP && dir != DMA_TO_DEVICE)
+			cflush.op = GNTTAB_CACHE_INVAL;
+		if (op == DMA_MAP) {
+			if (dir == DMA_FROM_DEVICE)
+				cflush.op = GNTTAB_CACHE_INVAL;
+			else
+				cflush.op = GNTTAB_CACHE_CLEAN;
+		}
+		if (cflush.op)
+			HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1);
 
 		offset = 0;
 		pfn++;
@@ -106,7 +128,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
 			   unsigned long pfn,
 			   unsigned long mfn)
 {
-	return ((pfn != mfn) && !is_device_dma_coherent(dev));
+	return (!hypercall_cflush && (pfn != mfn) && !is_device_dma_coherent(dev));
 }
 
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
@@ -149,10 +171,18 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 
 int __init xen_mm_init(void)
 {
+	struct gnttab_cache_flush cflush;
 	if (!xen_initial_domain())
 		return 0;
 	xen_swiotlb_init(1, false);
 	xen_dma_ops = &xen_swiotlb_dma_ops;
+
+	cflush.op = 0;
+	cflush.a.dev_bus_addr = 0;
+	cflush.offset = 0;
+	cflush.length = 0;
+	if (HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1) != -ENOSYS)
+		hypercall_cflush = true;
 	return 0;
 }
 arch_initcall(xen_mm_init);
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index e40fae9..bcce564 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -479,6 +479,25 @@ struct gnttab_get_version {
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_version);
 
 /*
+ * Issue one or more cache maintenance operations on a portion of a
+ * page granted to the calling domain by a foreign domain.
+ */
+#define GNTTABOP_cache_flush          12
+struct gnttab_cache_flush {
+    union {
+        uint64_t dev_bus_addr;
+        grant_ref_t ref;
+    } a;
+    uint16_t offset;   /* offset from start of grant */
+    uint16_t length;   /* size within the grant */
+#define GNTTAB_CACHE_CLEAN          (1<<0)
+#define GNTTAB_CACHE_INVAL          (1<<1)
+#define GNTTAB_CACHE_SOURCE_GREF    (1<<31)
+    uint32_t op;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_cache_flush);
+
+/*
  * Bitfield values for update_pin_status.flags.
  */
  /* Map the grant entry for access by I/O devices. */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:19:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16: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 1XnrgS-0004pX-QU; Mon, 10 Nov 2014 16:19:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrgR-0004pJ-Mi
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:19:15 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	17/F2-02696-385E0645; Mon, 10 Nov 2014 16:19:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415636352!12512986!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17188 invoked from network); 10 Nov 2014 16:19:14 -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;
	10 Nov 2014 16:19:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191239981"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:18:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-6A;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:04 +0000
Message-ID: <1415636045-24669-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 12/13] swiotlb-xen: pass dev_addr to
	xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
handle as argument, not a physical address.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/swiotlb-xen.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 3725ee4..498b654 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 
 	BUG_ON(dir == DMA_NONE);
 
-	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
+	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr)) {
@@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
 	BUG_ON(dir == DMA_NONE);
 
 	if (target == SYNC_FOR_CPU)
-		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
+		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr))
 		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
 
 	if (target == SYNC_FOR_DEVICE)
-		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
+		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
 
 	if (dir != DMA_FROM_DEVICE)
 		return;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:19:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16: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 1XnrgS-0004pX-QU; Mon, 10 Nov 2014 16:19:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XnrgR-0004pJ-Mi
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:19:15 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	17/F2-02696-385E0645; Mon, 10 Nov 2014 16:19:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415636352!12512986!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17188 invoked from network); 10 Nov 2014 16:19:14 -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;
	10 Nov 2014 16:19:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191239981"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 11:18:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xnrbe-0000Mx-6A;
	Mon, 10 Nov 2014 16:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 10 Nov 2014 16:14:04 +0000
Message-ID: <1415636045-24669-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v8 12/13] swiotlb-xen: pass dev_addr to
	xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
handle as argument, not a physical address.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/swiotlb-xen.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 3725ee4..498b654 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 
 	BUG_ON(dir == DMA_NONE);
 
-	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
+	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr)) {
@@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
 	BUG_ON(dir == DMA_NONE);
 
 	if (target == SYNC_FOR_CPU)
-		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
+		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr))
 		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
 
 	if (target == SYNC_FOR_DEVICE)
-		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
+		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
 
 	if (dir != DMA_FROM_DEVICE)
 		return;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:27:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:27:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnroQ-0005FE-Sy; Mon, 10 Nov 2014 16:27:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnroP-0005F9-58
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:27:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	66/65-24532-077E0645; Mon, 10 Nov 2014 16:27:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415636844!12436979!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29794 invoked from network); 10 Nov 2014 16:27:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:27:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191245014"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 11:26:51 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xnrnn-00070h-Hz;
	Mon, 10 Nov 2014 16:26:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xnrnn-0000qF-90;
	Mon, 10 Nov 2014 16:26:51 +0000
Date: Mon, 10 Nov 2014 16:26:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31461-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31461: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31461 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31461/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31461
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31461
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31461
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31461
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot     fail in 31451 pass in 31461

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:27:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:27:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnroQ-0005FE-Sy; Mon, 10 Nov 2014 16:27:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnroP-0005F9-58
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 16:27:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	66/65-24532-077E0645; Mon, 10 Nov 2014 16:27:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415636844!12436979!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29794 invoked from network); 10 Nov 2014 16:27:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:27:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191245014"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 11:26:51 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xnrnn-00070h-Hz;
	Mon, 10 Nov 2014 16:26:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xnrnn-0000qF-90;
	Mon, 10 Nov 2014 16:26:51 +0000
Date: Mon, 10 Nov 2014 16:26:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31461-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31461: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31461 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31461/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31461
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31461
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31461
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31461
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot     fail in 31451 pass in 31461

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:43:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:43:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xns3G-0005ZN-NA; Mon, 10 Nov 2014 16:42:50 +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 1Xns3F-0005ZI-Dm
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 16:42:49 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	2B/90-22819-80BE0645; Mon, 10 Nov 2014 16:42:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415637763!8240998!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10656 invoked from network); 10 Nov 2014 16:42:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:42:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191251201"
Message-ID: <5460EAF1.5020903@citrix.com>
Date: Mon, 10 Nov 2014 16:42:25 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Zoltan Kiss <zoltan.kiss@linaro.org>, <netdev@vger.kernel.org>, "David S.
	Miller" <davem@davemloft.net>, Eric Dumazet <eric.dumazet@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>, Stefan Bader <stefan.bader@canonical.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>, <linux-kernel@vger.kernel.org>, 
	<xen-devel@lists.xenproject.org>
References: <20141106214940.GD44162@ubuntu-hedt>
	<545CA27F.4070400@citrix.com>	<20141110143517.GA74005@ubuntu-hedt>
	<5460CEA5.3070201@citrix.com> <5460EA45.2080202@linaro.org>
In-Reply-To: <5460EA45.2080202@linaro.org>
X-DLP: MIA2
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/14 16:39, Zoltan Kiss wrote:
> 
> The BUG_ON suggested by Stefan would be still reasonable:
> 
> BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len >
> PAGE_SIZE<<compound_order(compound_head(page)));

Well, it wouldn't trigger but I don't think it is useful any more.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:43:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:43:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xns3G-0005ZN-NA; Mon, 10 Nov 2014 16:42:50 +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 1Xns3F-0005ZI-Dm
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 16:42:49 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	2B/90-22819-80BE0645; Mon, 10 Nov 2014 16:42:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415637763!8240998!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10656 invoked from network); 10 Nov 2014 16:42:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:42:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191251201"
Message-ID: <5460EAF1.5020903@citrix.com>
Date: Mon, 10 Nov 2014 16:42:25 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Zoltan Kiss <zoltan.kiss@linaro.org>, <netdev@vger.kernel.org>, "David S.
	Miller" <davem@davemloft.net>, Eric Dumazet <eric.dumazet@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>, Stefan Bader <stefan.bader@canonical.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>, <linux-kernel@vger.kernel.org>, 
	<xen-devel@lists.xenproject.org>
References: <20141106214940.GD44162@ubuntu-hedt>
	<545CA27F.4070400@citrix.com>	<20141110143517.GA74005@ubuntu-hedt>
	<5460CEA5.3070201@citrix.com> <5460EA45.2080202@linaro.org>
In-Reply-To: <5460EA45.2080202@linaro.org>
X-DLP: MIA2
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/14 16:39, Zoltan Kiss wrote:
> 
> The BUG_ON suggested by Stefan would be still reasonable:
> 
> BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len >
> PAGE_SIZE<<compound_order(compound_head(page)));

Well, it wouldn't trigger but I don't think it is useful any more.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:44:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xns56-0005fs-2K; Mon, 10 Nov 2014 16:44:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1Xns55-0005ff-2o
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 16:44:43 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	74/6B-17958-A7BE0645; Mon, 10 Nov 2014 16:44:42 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415637881!7886439!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24811 invoked from network); 10 Nov 2014 16:44:41 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:44:41 -0000
Received: by mail-wi0-f181.google.com with SMTP id n3so11036034wiv.8
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 08:44:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=LlSQC/cjSEffNTcEVDzb20Na8lYyek4ccBQGXwGLWeE=;
	b=kiyN2rC3LzYWwWiGj4IVzWm0UGy7UfS7RpZxs+bPryvsbPSrdLjJtzD3EirbahjEkW
	4LkayA6YMmdznwPrzDL4c74OTSj0RfIUdsUlRmAwl0PkXPMDxoBofVrZBFljjxMKnnSs
	I1vO3TnGWi/NBmnmCho7wJ4I6cVZ5e0qIwhr/4So2vh3msT3c3eTkhjkeguHnxajzNyL
	jVxPO1EsWN2V72O42URukhMto7egWUC77IKFZ7SjjVjEhB85fpp8dY8t2CSubIIoytGQ
	r8VZqNJY3fhhlyXjjQVZvvrQ8yeImKvgIEDFCb336aq1Fe7YShvPGLb1pmTOknDIsPp6
	PRjw==
X-Gm-Message-State: ALoCoQnX/D3g+xYkrvPyR2BYHJagszOExqwseuMmAfK6Z13FK7xEboPqHOztOY9+MuiKT5/ttw5D
X-Received: by 10.180.90.112 with SMTP id bv16mr32481266wib.53.1415637578089; 
	Mon, 10 Nov 2014 08:39:38 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id m6sm14038683wiy.16.2014.11.10.08.39.36
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 10 Nov 2014 08:39:37 -0800 (PST)
Message-ID: <5460EA45.2080202@linaro.org>
Date: Mon, 10 Nov 2014 16:39:33 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, netdev@vger.kernel.org, 
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Stefan Bader <stefan.bader@canonical.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
References: <20141106214940.GD44162@ubuntu-hedt>
	<545CA27F.4070400@citrix.com>	<20141110143517.GA74005@ubuntu-hedt>
	<5460CEA5.3070201@citrix.com>
In-Reply-To: <5460CEA5.3070201@citrix.com>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 10/11/14 14:41, David Vrabel wrote:
> On 10/11/14 14:35, Seth Forshee wrote:
>> On Fri, Nov 07, 2014 at 10:44:15AM +0000, David Vrabel wrote:
>>> On 06/11/14 21:49, Seth Forshee wrote:
>>>> We've had several reports of hitting the following BUG_ON in
>>>> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
>>>> results of testing with 3.17):
>>>>
>>>>          /* Grant backend access to each skb fragment page. */
>>>>          for (i = 0; i < frags; i++) {
>>>>                  skb_frag_t *frag = skb_shinfo(skb)->frags + i;
>>>>                  struct page *page = skb_frag_page(frag);
>>>>
>>>>                  len = skb_frag_size(frag);
>>>>                  offset = frag->page_offset;
>>>>
>>>>                  /* Data must not cross a page boundary. */
>>>>                  BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
>>>>
>>>> When this happens the page in question is a "middle" page in a compound
>>>> page (i.e. it's a tail page but not the last tail page), and the data is
>>>> fully contained within the compound page. The data does however cross
>>>> the hardware page boundary, and since compound_order evaluates to 0 for
>>>> tail pages the check fails.
>>>>
>>>> In going over this I've been unable to determine whether the BUG_ON in
>>>> xennet_make_frags is incorrect or the paged skb data is wrong. I can't
>>>> find that it's documented anywhere, and the networking code itself is a
>>>> bit ambiguous when it comes to compound pages. On the one hand
>>>> __skb_fill_page_desc specifically handles adding tail pages as paged
>>>> data, but on the other hand skb_copy_bits kmaps frag->page.p which could
>>>> fail with data that extends into another page.
>>>
>>> netfront will safely handle this case so you can remove this BUG_ON()
>>> (and the one later on).  But it would be better to find out were these
>>> funny-looking skbs are coming from and (if necessary) fixing the bug there.
>>
>> There still seems to be disagreement about whether the "funny" skb is
>> valid though - you imply it isn't, but Eric says it is. I've been trying
>> to track down where these skbs originate, and so far I've determined
>> that they come from a socket spliced to a pipe spliced to a socket. It
>> looks like the particular page/offset/len tuple originates at least as
>> far back as the first socket, as the tuple is simply copied from an skb
>> into the pipe and from the pipe into the final skb.
>
> Apologies for the lack of clarity.  I meant either: a) fix the producer
> if these skbs are invalid; or b) remove the BUG_ON()s.  Since Eric says
> these are actually valid skbs, please do option (b).
>
> i.e., remove both BUG_ON()s.

The BUG_ON suggested by Stefan would be still reasonable:

BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len >
PAGE_SIZE<<compound_order(compound_head(page)));
>
> David
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 16:44:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 16:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xns56-0005fs-2K; Mon, 10 Nov 2014 16:44:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1Xns55-0005ff-2o
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 16:44:43 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	74/6B-17958-A7BE0645; Mon, 10 Nov 2014 16:44:42 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415637881!7886439!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24811 invoked from network); 10 Nov 2014 16:44:41 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 16:44:41 -0000
Received: by mail-wi0-f181.google.com with SMTP id n3so11036034wiv.8
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 08:44:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=LlSQC/cjSEffNTcEVDzb20Na8lYyek4ccBQGXwGLWeE=;
	b=kiyN2rC3LzYWwWiGj4IVzWm0UGy7UfS7RpZxs+bPryvsbPSrdLjJtzD3EirbahjEkW
	4LkayA6YMmdznwPrzDL4c74OTSj0RfIUdsUlRmAwl0PkXPMDxoBofVrZBFljjxMKnnSs
	I1vO3TnGWi/NBmnmCho7wJ4I6cVZ5e0qIwhr/4So2vh3msT3c3eTkhjkeguHnxajzNyL
	jVxPO1EsWN2V72O42URukhMto7egWUC77IKFZ7SjjVjEhB85fpp8dY8t2CSubIIoytGQ
	r8VZqNJY3fhhlyXjjQVZvvrQ8yeImKvgIEDFCb336aq1Fe7YShvPGLb1pmTOknDIsPp6
	PRjw==
X-Gm-Message-State: ALoCoQnX/D3g+xYkrvPyR2BYHJagszOExqwseuMmAfK6Z13FK7xEboPqHOztOY9+MuiKT5/ttw5D
X-Received: by 10.180.90.112 with SMTP id bv16mr32481266wib.53.1415637578089; 
	Mon, 10 Nov 2014 08:39:38 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id m6sm14038683wiy.16.2014.11.10.08.39.36
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 10 Nov 2014 08:39:37 -0800 (PST)
Message-ID: <5460EA45.2080202@linaro.org>
Date: Mon, 10 Nov 2014 16:39:33 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, netdev@vger.kernel.org, 
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Stefan Bader <stefan.bader@canonical.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
References: <20141106214940.GD44162@ubuntu-hedt>
	<545CA27F.4070400@citrix.com>	<20141110143517.GA74005@ubuntu-hedt>
	<5460CEA5.3070201@citrix.com>
In-Reply-To: <5460CEA5.3070201@citrix.com>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 10/11/14 14:41, David Vrabel wrote:
> On 10/11/14 14:35, Seth Forshee wrote:
>> On Fri, Nov 07, 2014 at 10:44:15AM +0000, David Vrabel wrote:
>>> On 06/11/14 21:49, Seth Forshee wrote:
>>>> We've had several reports of hitting the following BUG_ON in
>>>> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
>>>> results of testing with 3.17):
>>>>
>>>>          /* Grant backend access to each skb fragment page. */
>>>>          for (i = 0; i < frags; i++) {
>>>>                  skb_frag_t *frag = skb_shinfo(skb)->frags + i;
>>>>                  struct page *page = skb_frag_page(frag);
>>>>
>>>>                  len = skb_frag_size(frag);
>>>>                  offset = frag->page_offset;
>>>>
>>>>                  /* Data must not cross a page boundary. */
>>>>                  BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
>>>>
>>>> When this happens the page in question is a "middle" page in a compound
>>>> page (i.e. it's a tail page but not the last tail page), and the data is
>>>> fully contained within the compound page. The data does however cross
>>>> the hardware page boundary, and since compound_order evaluates to 0 for
>>>> tail pages the check fails.
>>>>
>>>> In going over this I've been unable to determine whether the BUG_ON in
>>>> xennet_make_frags is incorrect or the paged skb data is wrong. I can't
>>>> find that it's documented anywhere, and the networking code itself is a
>>>> bit ambiguous when it comes to compound pages. On the one hand
>>>> __skb_fill_page_desc specifically handles adding tail pages as paged
>>>> data, but on the other hand skb_copy_bits kmaps frag->page.p which could
>>>> fail with data that extends into another page.
>>>
>>> netfront will safely handle this case so you can remove this BUG_ON()
>>> (and the one later on).  But it would be better to find out were these
>>> funny-looking skbs are coming from and (if necessary) fixing the bug there.
>>
>> There still seems to be disagreement about whether the "funny" skb is
>> valid though - you imply it isn't, but Eric says it is. I've been trying
>> to track down where these skbs originate, and so far I've determined
>> that they come from a socket spliced to a pipe spliced to a socket. It
>> looks like the particular page/offset/len tuple originates at least as
>> far back as the first socket, as the tuple is simply copied from an skb
>> into the pipe and from the pipe into the final skb.
>
> Apologies for the lack of clarity.  I meant either: a) fix the producer
> if these skbs are invalid; or b) remove the BUG_ON()s.  Since Eric says
> these are actually valid skbs, please do option (b).
>
> i.e., remove both BUG_ON()s.

The BUG_ON suggested by Stefan would be still reasonable:

BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len >
PAGE_SIZE<<compound_order(compound_head(page)));
>
> David
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:02:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:02:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnsMV-0006Q8-7W; Mon, 10 Nov 2014 17:02:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1XnsMT-0006Q3-2H
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:02:41 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	5F/1A-17958-0BFE0645; Mon, 10 Nov 2014 17:02:40 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415638958!11599103!1
X-Originating-IP: [209.85.223.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8866 invoked from network); 10 Nov 2014 17:02:39 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 17:02:39 -0000
Received: by mail-ie0-f177.google.com with SMTP id tp5so9582141ieb.22
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 09:02:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:mime-version:content-transfer-encoding;
	bh=1gBxtlT+5+E1Rm3LPBs8FUZ/abl0SKECLdKuCWDxqSg=;
	b=JENa7vCx01ykj6czdWC98plRexn5ZviCY1a0aeS+my/lRom6vWEyFJQxNHojxZ6AIl
	mYlEApdKSDlqSu7hojfnuyo1j+jwtboG3BvJI/X1saF803cuIemevg06X7Hl3idSH/f+
	iFARfYwgm3AoTfnfZHNKD8q0ObpGLT4NbcFg9Z8vxFkoVBaYhcnNUszt2HX9tsttw5sd
	yRDwUe4Vp+WfOodmmZEYmrRkSw6J+ahBWkHIxPVeWzTqZCgY1pDoGgPwPrxfjyyIgcNg
	ebfiwp8KCwA0c+FTNGI2B+GGfYmbw/6m4KG96qkZBTRfAM7SZMGhNh7gJSE+afJYKtp0
	eIUQ==
X-Received: by 10.107.133.78 with SMTP id h75mr34918316iod.47.1415638958232;
	Mon, 10 Nov 2014 09:02:38 -0800 (PST)
Received: from [172.19.248.46] ([172.19.248.46])
	by mx.google.com with ESMTPSA id v91sm8483281iov.15.2014.11.10.09.02.36
	for <multiple recipients>
	(version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128);
	Mon, 10 Nov 2014 09:02:37 -0800 (PST)
Message-ID: <1415638955.9613.4.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 10 Nov 2014 09:02:35 -0800
In-Reply-To: <5460EAF1.5020903@citrix.com>
References: <20141106214940.GD44162@ubuntu-hedt>
	<545CA27F.4070400@citrix.com>	<20141110143517.GA74005@ubuntu-hedt>
	<5460CEA5.3070201@citrix.com> <5460EA45.2080202@linaro.org>
	<5460EAF1.5020903@citrix.com>
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Stefan Bader <stefan.bader@canonical.com>,
	xen-devel@lists.xenproject.org, Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, "David S.
	Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 16:42 +0000, David Vrabel wrote:
> On 10/11/14 16:39, Zoltan Kiss wrote:
> > 
> > The BUG_ON suggested by Stefan would be still reasonable:
> > 
> > BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len >
> > PAGE_SIZE<<compound_order(compound_head(page)));
> 
> Well, it wouldn't trigger but I don't think it is useful any more.

Right.

This BUG_ON() does not make sense (its current implementation is
assuming a very precise layout anyway)

If we really wanted some debugging, we would need something more generic
and done in core networking stack, not in a particular driver.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:02:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:02:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnsMV-0006Q8-7W; Mon, 10 Nov 2014 17:02:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1XnsMT-0006Q3-2H
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:02:41 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	5F/1A-17958-0BFE0645; Mon, 10 Nov 2014 17:02:40 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415638958!11599103!1
X-Originating-IP: [209.85.223.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8866 invoked from network); 10 Nov 2014 17:02:39 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 17:02:39 -0000
Received: by mail-ie0-f177.google.com with SMTP id tp5so9582141ieb.22
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 09:02:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:mime-version:content-transfer-encoding;
	bh=1gBxtlT+5+E1Rm3LPBs8FUZ/abl0SKECLdKuCWDxqSg=;
	b=JENa7vCx01ykj6czdWC98plRexn5ZviCY1a0aeS+my/lRom6vWEyFJQxNHojxZ6AIl
	mYlEApdKSDlqSu7hojfnuyo1j+jwtboG3BvJI/X1saF803cuIemevg06X7Hl3idSH/f+
	iFARfYwgm3AoTfnfZHNKD8q0ObpGLT4NbcFg9Z8vxFkoVBaYhcnNUszt2HX9tsttw5sd
	yRDwUe4Vp+WfOodmmZEYmrRkSw6J+ahBWkHIxPVeWzTqZCgY1pDoGgPwPrxfjyyIgcNg
	ebfiwp8KCwA0c+FTNGI2B+GGfYmbw/6m4KG96qkZBTRfAM7SZMGhNh7gJSE+afJYKtp0
	eIUQ==
X-Received: by 10.107.133.78 with SMTP id h75mr34918316iod.47.1415638958232;
	Mon, 10 Nov 2014 09:02:38 -0800 (PST)
Received: from [172.19.248.46] ([172.19.248.46])
	by mx.google.com with ESMTPSA id v91sm8483281iov.15.2014.11.10.09.02.36
	for <multiple recipients>
	(version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128);
	Mon, 10 Nov 2014 09:02:37 -0800 (PST)
Message-ID: <1415638955.9613.4.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 10 Nov 2014 09:02:35 -0800
In-Reply-To: <5460EAF1.5020903@citrix.com>
References: <20141106214940.GD44162@ubuntu-hedt>
	<545CA27F.4070400@citrix.com>	<20141110143517.GA74005@ubuntu-hedt>
	<5460CEA5.3070201@citrix.com> <5460EA45.2080202@linaro.org>
	<5460EAF1.5020903@citrix.com>
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Stefan Bader <stefan.bader@canonical.com>,
	xen-devel@lists.xenproject.org, Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, "David S.
	Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 16:42 +0000, David Vrabel wrote:
> On 10/11/14 16:39, Zoltan Kiss wrote:
> > 
> > The BUG_ON suggested by Stefan would be still reasonable:
> > 
> > BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len >
> > PAGE_SIZE<<compound_order(compound_head(page)));
> 
> Well, it wouldn't trigger but I don't think it is useful any more.

Right.

This BUG_ON() does not make sense (its current implementation is
assuming a very precise layout anyway)

If we really wanted some debugging, we would need something more generic
and done in core networking stack, not in a particular driver.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:05:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:05:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnsOl-0006WE-PL; Mon, 10 Nov 2014 17:05:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XnsOk-0006W6-Nw
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 17:05:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DD/BE-24532-E30F0645; Mon, 10 Nov 2014 17:05:02 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415639101!12816039!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10534 invoked from network); 10 Nov 2014 17:05:01 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 17:05:01 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so9479420wgg.16
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 09:05:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=DqevrgWSPJt3kUTxIZaUJXqD2ZjURvkcQXWESC0KyEk=;
	b=jxRr+2wq/0gmK1GNref9s/L+E6saV0Lw8SP33ziKaFTJLMKfAPn0AG1kO/gcmExHvC
	Fm+aQu5MgOenbEtTGyyRPhGAopx8q0lYs4bWtF0EYomPMLiibs4McLRxmocEtaGuFKEL
	L+rhJNX8LXo1upiuqhN37z3+NoREkbXA3hIPmD/Oj1ivonYsB5z+g55+dLlbuJSjEpnG
	9oUqXSC1eHiJjGhU4raWL1cjvNrJAo0I9KFoYlnvjWSmCiNyuv04gxAEMvE6SQ6qyvsl
	/wu8p99PoUZ3/t+KsMWh/UUkfKaMAT46DvnLtCabPKnzKSGcx6JixLLYydAOd1ymkca9
	tO1Q==
MIME-Version: 1.0
X-Received: by 10.194.248.162 with SMTP id yn2mr45036412wjc.16.1415639099211; 
	Mon, 10 Nov 2014 09:04:59 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 10 Nov 2014 09:04:59 -0800 (PST)
In-Reply-To: <1415607424-15920-3-git-send-email-cyliu@suse.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
Date: Mon, 10 Nov 2014 17:04:59 +0000
X-Google-Sender-Auth: TRuxQTDstvL-quqINsi4tCBP-yI
Message-ID: <CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Chunyan Liu <cyliu@suse.com>
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Jim Fehlig <jfehlig@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 8:17 AM, Chunyan Liu <cyliu@suse.com> wrote:

>
> 3. Function Implementation
>
>    libxl_domain_snapshot_create:
>        1). check args validation
>        2). save domain memory through save-domain
>        3). take disk snapshot by qmp command (if domian is active) or qemu-img
>            command (if domain is inactive).

By "active" here, do you you mean "live" (vs paused)?

>    libxl_domain_snapshot_delete:
>        1). check args validation
>        2). remove memory state file.
>        3). delete disk snapshot. (for internal disk snapshot, through qmp
>            command or qemu-img command)

Out of curiosity, why is this necessary?  Is libxl keeping track of
the snapshots somewhere?  Or qemu?

Or to put it a different way, since the caller knows the filenames,
why can't the caller just erase the files themselves?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:05:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:05:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnsOl-0006WE-PL; Mon, 10 Nov 2014 17:05:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XnsOk-0006W6-Nw
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 17:05:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DD/BE-24532-E30F0645; Mon, 10 Nov 2014 17:05:02 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415639101!12816039!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10534 invoked from network); 10 Nov 2014 17:05:01 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 17:05:01 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so9479420wgg.16
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 09:05:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=DqevrgWSPJt3kUTxIZaUJXqD2ZjURvkcQXWESC0KyEk=;
	b=jxRr+2wq/0gmK1GNref9s/L+E6saV0Lw8SP33ziKaFTJLMKfAPn0AG1kO/gcmExHvC
	Fm+aQu5MgOenbEtTGyyRPhGAopx8q0lYs4bWtF0EYomPMLiibs4McLRxmocEtaGuFKEL
	L+rhJNX8LXo1upiuqhN37z3+NoREkbXA3hIPmD/Oj1ivonYsB5z+g55+dLlbuJSjEpnG
	9oUqXSC1eHiJjGhU4raWL1cjvNrJAo0I9KFoYlnvjWSmCiNyuv04gxAEMvE6SQ6qyvsl
	/wu8p99PoUZ3/t+KsMWh/UUkfKaMAT46DvnLtCabPKnzKSGcx6JixLLYydAOd1ymkca9
	tO1Q==
MIME-Version: 1.0
X-Received: by 10.194.248.162 with SMTP id yn2mr45036412wjc.16.1415639099211; 
	Mon, 10 Nov 2014 09:04:59 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 10 Nov 2014 09:04:59 -0800 (PST)
In-Reply-To: <1415607424-15920-3-git-send-email-cyliu@suse.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
Date: Mon, 10 Nov 2014 17:04:59 +0000
X-Google-Sender-Auth: TRuxQTDstvL-quqINsi4tCBP-yI
Message-ID: <CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Chunyan Liu <cyliu@suse.com>
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Jim Fehlig <jfehlig@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 8:17 AM, Chunyan Liu <cyliu@suse.com> wrote:

>
> 3. Function Implementation
>
>    libxl_domain_snapshot_create:
>        1). check args validation
>        2). save domain memory through save-domain
>        3). take disk snapshot by qmp command (if domian is active) or qemu-img
>            command (if domain is inactive).

By "active" here, do you you mean "live" (vs paused)?

>    libxl_domain_snapshot_delete:
>        1). check args validation
>        2). remove memory state file.
>        3). delete disk snapshot. (for internal disk snapshot, through qmp
>            command or qemu-img command)

Out of curiosity, why is this necessary?  Is libxl keeping track of
the snapshots somewhere?  Or qemu?

Or to put it a different way, since the caller knows the filenames,
why can't the caller just erase the files themselves?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:08:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnsS6-0006gh-9L; Mon, 10 Nov 2014 17:08:30 +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 1XnsS4-0006gZ-T2
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:08:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C9/94-24532-C01F0645; Mon, 10 Nov 2014 17:08:28 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415639306!12762642!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1675 invoked from network); 10 Nov 2014 17:08:27 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 17:08:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAH8LdZ004835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 17:08:22 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAH8J23010027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 17:08:19 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAH8JeO010017; Mon, 10 Nov 2014 17:08:19 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 09:08:19 -0800
Message-ID: <5460F102.9000100@oracle.com>
Date: Mon, 10 Nov 2014 12:08:18 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
In-Reply-To: <20141110152535.GA6110@zion.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/10/2014 10:25 AM, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
>> On 11/10/2014 07:35 AM, Wei Liu wrote:
>>> I see. At that point the configuration was not available, yet. After the
>>> domain is successfully migrated, the configuration should be available.
>>>
>>> I think a domain under construction without domain configuration is a
>>> valid state. What do you think?
>>
>> Here is my thought:
>>
>> 1. In this design, if I watch xenstore @introduceDomain, it will not been
>>    triggered until migration finish.
>>
> 
> OK. What in this design makes behavior different than before? Are you
> suggesting "xl list -l" has something to do with your xenstore watch? I
> don't think I can get this.
> 
> My guess is that, you have some tool that watches @introduceDomain,
> which happens *before* the domain creation is finished. And your tool
> needs to get domain information once your watch fires.  Here with this
> design, your tool cannot get the correct information until migration is
> finished. Am I right?
> 
> However, in previous design, even if you manage to get configuration
> before migration is finished, I don't think that configuration reflects
> the true configuration of that domain. It's conceptually bogus.
> 
> In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
> domain is started, so using it for that purpose would be wrong.
> 
>> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
>>    domain state, we need to define what does it mean by "VM started".
>>
> 
> If my above analysis is correct, will some kind of @startDomain event solve
> your problem?
> 
> But this involves making changes to Xenstore protocol. Let's not go into
> details until we make sure your requirement is well understood.

We do currently watch xenstore @introduceDomain for VM start.

I thought the @introduceDomain behavior is different than xm/xend,
but I just did a test and I was wrong.

xm/xend also trigger @introduceDomain until domain migration finish. (but before
@introduceDomain, all the VM xenstore entries are already there.)

Right now, I'm all set if we fix the xl list -l issue during migration.

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:08:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnsS6-0006gh-9L; Mon, 10 Nov 2014 17:08:30 +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 1XnsS4-0006gZ-T2
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:08:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C9/94-24532-C01F0645; Mon, 10 Nov 2014 17:08:28 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415639306!12762642!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1675 invoked from network); 10 Nov 2014 17:08:27 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 17:08:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAH8LdZ004835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 17:08:22 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAH8J23010027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 17:08:19 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAH8JeO010017; Mon, 10 Nov 2014 17:08:19 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 09:08:19 -0800
Message-ID: <5460F102.9000100@oracle.com>
Date: Mon, 10 Nov 2014 12:08:18 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
In-Reply-To: <20141110152535.GA6110@zion.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/10/2014 10:25 AM, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
>> On 11/10/2014 07:35 AM, Wei Liu wrote:
>>> I see. At that point the configuration was not available, yet. After the
>>> domain is successfully migrated, the configuration should be available.
>>>
>>> I think a domain under construction without domain configuration is a
>>> valid state. What do you think?
>>
>> Here is my thought:
>>
>> 1. In this design, if I watch xenstore @introduceDomain, it will not been
>>    triggered until migration finish.
>>
> 
> OK. What in this design makes behavior different than before? Are you
> suggesting "xl list -l" has something to do with your xenstore watch? I
> don't think I can get this.
> 
> My guess is that, you have some tool that watches @introduceDomain,
> which happens *before* the domain creation is finished. And your tool
> needs to get domain information once your watch fires.  Here with this
> design, your tool cannot get the correct information until migration is
> finished. Am I right?
> 
> However, in previous design, even if you manage to get configuration
> before migration is finished, I don't think that configuration reflects
> the true configuration of that domain. It's conceptually bogus.
> 
> In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
> domain is started, so using it for that purpose would be wrong.
> 
>> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
>>    domain state, we need to define what does it mean by "VM started".
>>
> 
> If my above analysis is correct, will some kind of @startDomain event solve
> your problem?
> 
> But this involves making changes to Xenstore protocol. Let's not go into
> details until we make sure your requirement is well understood.

We do currently watch xenstore @introduceDomain for VM start.

I thought the @introduceDomain behavior is different than xm/xend,
but I just did a test and I was wrong.

xm/xend also trigger @introduceDomain until domain migration finish. (but before
@introduceDomain, all the VM xenstore entries are already there.)

Right now, I'm all set if we fix the xl list -l issue during migration.

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:20:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:20:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnsdQ-0006wU-MM; Mon, 10 Nov 2014 17:20:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1XnsdK-0006wM-4X
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:20:11 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3F/6B-09936-5C3F0645; Mon, 10 Nov 2014 17:20:05 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415640004!12788803!1
X-Originating-IP: [209.85.220.181]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15032 invoked from network); 10 Nov 2014 17:20:04 -0000
Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com)
	(209.85.220.181)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 17:20:04 -0000
Received: by mail-vc0-f181.google.com with SMTP id hy10so4200565vcb.40
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 09:20:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=eXzFa2CShCcSS2SxDWMhcyp8vR7Chhp1CJEvW70JGAw=;
	b=ri7Z+2DsEi340SlD1LQ2VwGRyuVbuQXgEWzrDSddA/NdseA/9+yVEWxiaZzU5mtMXw
	ACMD30bPMvMvkfioPOyeQz8ItYwEDgYdt/nVIToB/Tg5Xo7yUOJAgUa/msurQx8Q/vMx
	L9+dkaDnD3PQpNuEVLkdiAaXw/cdYk703sHybKhW4UB2v1Te801QK+WLkSAgqYdf9Zwh
	to42DW8JkUooXs8lehThRz10VnX3QEKvke6b6/aIWCPwK7sBNH3YbBtRcwHUSOM7qUWD
	IxplpRJDFNCDTw818ONYVrbUj6+w9rCT/pnX0J4WuwzWzaLaElqS29/FBCZTQ9VAGmFC
	Va0Q==
MIME-Version: 1.0
X-Received: by 10.52.83.196 with SMTP id s4mr937000vdy.82.1415640003906; Mon,
	10 Nov 2014 09:20:03 -0800 (PST)
Received: by 10.52.160.129 with HTTP; Mon, 10 Nov 2014 09:20:03 -0800 (PST)
In-Reply-To: <5460EAF1.5020903@citrix.com>
References: <20141106214940.GD44162@ubuntu-hedt> <545CA27F.4070400@citrix.com>
	<20141110143517.GA74005@ubuntu-hedt> <5460CEA5.3070201@citrix.com>
	<5460EA45.2080202@linaro.org> <5460EAF1.5020903@citrix.com>
Date: Mon, 10 Nov 2014 17:20:03 +0000
Message-ID: <CAHt6W4fFd17y0gXO9o=rrc86ErYNe_gcvvuc94j31ZrpR4huog@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Eric Dumazet <eric.dumazet@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5083918228855888436=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5083918228855888436==
Content-Type: multipart/alternative; boundary=001a1136afd890138c0507845f7a

--001a1136afd890138c0507845f7a
Content-Type: text/plain; charset=UTF-8

2014-11-10 16:42 GMT+00:00 David Vrabel <david.vrabel@citrix.com>:

> On 10/11/14 16:39, Zoltan Kiss wrote:
> >
> > The BUG_ON suggested by Stefan would be still reasonable:
> >
> > BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len >
> > PAGE_SIZE<<compound_order(compound_head(page)));
>
> Well, it wouldn't trigger but I don't think it is useful any more.
>
> David
>
>
Looks like this structure was designed to just contains physical single
pages and was extended to support compound pages however there are still
some functions that assume the usage of single pages. Just for instance the
offset/size of fragments are computed from PAGE_SIZE. On x86 (4KB pages) if
your compound page is bigger than 64KB you cannot fully use for a fragment
as offset/size are 16 bits. Some functions in skbuff.c use kmap which is
limited to physical page.

Frediano

--001a1136afd890138c0507845f7a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2014=
-11-10 16:42 GMT+00:00 David Vrabel <span dir=3D"ltr">&lt;<a href=3D"mailto=
:david.vrabel@citrix.com" target=3D"_blank">david.vrabel@citrix.com</a>&gt;=
</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 10/11/14 16:=
39, Zoltan Kiss wrote:<br>
&gt;<br>
&gt; The BUG_ON suggested by Stefan would be still reasonable:<br>
&gt;<br>
&gt; BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len &gt;<br>
&gt; PAGE_SIZE&lt;&lt;compound_order(compound_head(page)));<br>
<br>
</span>Well, it wouldn&#39;t trigger but I don&#39;t think it is useful any=
 more.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
David<br>
<br></div></div></blockquote><div><br></div><div>Looks like this structure =
was designed to just contains physical single pages and was extended to sup=
port compound pages however there are still some functions that assume the =
usage of single pages. Just for instance the offset/size of fragments are c=
omputed from PAGE_SIZE. On x86 (4KB pages) if your compound page is bigger =
than 64KB you cannot fully use for a fragment as offset/size are 16 bits. S=
ome functions in skbuff.c use kmap which is limited to physical page.<br></=
div><div><br>Frediano<br><br></div></div></div></div>

--001a1136afd890138c0507845f7a--


--===============5083918228855888436==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5083918228855888436==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 17:20:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:20:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnsdQ-0006wU-MM; Mon, 10 Nov 2014 17:20:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1XnsdK-0006wM-4X
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:20:11 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3F/6B-09936-5C3F0645; Mon, 10 Nov 2014 17:20:05 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415640004!12788803!1
X-Originating-IP: [209.85.220.181]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15032 invoked from network); 10 Nov 2014 17:20:04 -0000
Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com)
	(209.85.220.181)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 17:20:04 -0000
Received: by mail-vc0-f181.google.com with SMTP id hy10so4200565vcb.40
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 09:20:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=eXzFa2CShCcSS2SxDWMhcyp8vR7Chhp1CJEvW70JGAw=;
	b=ri7Z+2DsEi340SlD1LQ2VwGRyuVbuQXgEWzrDSddA/NdseA/9+yVEWxiaZzU5mtMXw
	ACMD30bPMvMvkfioPOyeQz8ItYwEDgYdt/nVIToB/Tg5Xo7yUOJAgUa/msurQx8Q/vMx
	L9+dkaDnD3PQpNuEVLkdiAaXw/cdYk703sHybKhW4UB2v1Te801QK+WLkSAgqYdf9Zwh
	to42DW8JkUooXs8lehThRz10VnX3QEKvke6b6/aIWCPwK7sBNH3YbBtRcwHUSOM7qUWD
	IxplpRJDFNCDTw818ONYVrbUj6+w9rCT/pnX0J4WuwzWzaLaElqS29/FBCZTQ9VAGmFC
	Va0Q==
MIME-Version: 1.0
X-Received: by 10.52.83.196 with SMTP id s4mr937000vdy.82.1415640003906; Mon,
	10 Nov 2014 09:20:03 -0800 (PST)
Received: by 10.52.160.129 with HTTP; Mon, 10 Nov 2014 09:20:03 -0800 (PST)
In-Reply-To: <5460EAF1.5020903@citrix.com>
References: <20141106214940.GD44162@ubuntu-hedt> <545CA27F.4070400@citrix.com>
	<20141110143517.GA74005@ubuntu-hedt> <5460CEA5.3070201@citrix.com>
	<5460EA45.2080202@linaro.org> <5460EAF1.5020903@citrix.com>
Date: Mon, 10 Nov 2014 17:20:03 +0000
Message-ID: <CAHt6W4fFd17y0gXO9o=rrc86ErYNe_gcvvuc94j31ZrpR4huog@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Eric Dumazet <eric.dumazet@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xenproject.org,
	Jay Vosburgh <jay.vosburgh@canonical.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5083918228855888436=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5083918228855888436==
Content-Type: multipart/alternative; boundary=001a1136afd890138c0507845f7a

--001a1136afd890138c0507845f7a
Content-Type: text/plain; charset=UTF-8

2014-11-10 16:42 GMT+00:00 David Vrabel <david.vrabel@citrix.com>:

> On 10/11/14 16:39, Zoltan Kiss wrote:
> >
> > The BUG_ON suggested by Stefan would be still reasonable:
> >
> > BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len >
> > PAGE_SIZE<<compound_order(compound_head(page)));
>
> Well, it wouldn't trigger but I don't think it is useful any more.
>
> David
>
>
Looks like this structure was designed to just contains physical single
pages and was extended to support compound pages however there are still
some functions that assume the usage of single pages. Just for instance the
offset/size of fragments are computed from PAGE_SIZE. On x86 (4KB pages) if
your compound page is bigger than 64KB you cannot fully use for a fragment
as offset/size are 16 bits. Some functions in skbuff.c use kmap which is
limited to physical page.

Frediano

--001a1136afd890138c0507845f7a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2014=
-11-10 16:42 GMT+00:00 David Vrabel <span dir=3D"ltr">&lt;<a href=3D"mailto=
:david.vrabel@citrix.com" target=3D"_blank">david.vrabel@citrix.com</a>&gt;=
</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 10/11/14 16:=
39, Zoltan Kiss wrote:<br>
&gt;<br>
&gt; The BUG_ON suggested by Stefan would be still reasonable:<br>
&gt;<br>
&gt; BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len &gt;<br>
&gt; PAGE_SIZE&lt;&lt;compound_order(compound_head(page)));<br>
<br>
</span>Well, it wouldn&#39;t trigger but I don&#39;t think it is useful any=
 more.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
David<br>
<br></div></div></blockquote><div><br></div><div>Looks like this structure =
was designed to just contains physical single pages and was extended to sup=
port compound pages however there are still some functions that assume the =
usage of single pages. Just for instance the offset/size of fragments are c=
omputed from PAGE_SIZE. On x86 (4KB pages) if your compound page is bigger =
than 64KB you cannot fully use for a fragment as offset/size are 16 bits. S=
ome functions in skbuff.c use kmap which is limited to physical page.<br></=
div><div><br>Frediano<br><br></div></div></div></div>

--001a1136afd890138c0507845f7a--


--===============5083918228855888436==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5083918228855888436==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 17:21:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnses-00070h-6D; Mon, 10 Nov 2014 17:21:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1Xnser-00070a-4w
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:21:41 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	A7/D1-22777-424F0645; Mon, 10 Nov 2014 17:21:40 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415640099!11615435!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30765 invoked from network); 10 Nov 2014 17:21:40 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-13.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 17:21:40 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1Xnseo-0004rX-G8; Mon, 10 Nov 2014 17:21:38 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.62498.461291.217262@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:21:38 +0000
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <54380D8F020000780003DD5E@mail.emea.novell.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<54380D8F020000780003DD5E@mail.emea.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> There's one more thing I thought of btw: When we change the
> policy following whatever community input we gathered (not just
> now, but also in the future), people currently on the pre-disclosure
> list may (at least theoretically) end up no longer qualifying for
> being on the list. Shouldn't we
> - add some kind of statement to the effect of implicit agreement
>   to changed terms,
> - provide means for list members to be removed other than by
>   them asking for it?

Perhaps the right approach is to have a requalification process, where
each member's predisclosure list membership is reviewed periodically.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:21:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnses-00070h-6D; Mon, 10 Nov 2014 17:21:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1Xnser-00070a-4w
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:21:41 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	A7/D1-22777-424F0645; Mon, 10 Nov 2014 17:21:40 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415640099!11615435!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30765 invoked from network); 10 Nov 2014 17:21:40 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-13.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 17:21:40 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1Xnseo-0004rX-G8; Mon, 10 Nov 2014 17:21:38 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.62498.461291.217262@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:21:38 +0000
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <54380D8F020000780003DD5E@mail.emea.novell.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<54380D8F020000780003DD5E@mail.emea.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> There's one more thing I thought of btw: When we change the
> policy following whatever community input we gathered (not just
> now, but also in the future), people currently on the pre-disclosure
> list may (at least theoretically) end up no longer qualifying for
> being on the list. Shouldn't we
> - add some kind of statement to the effect of implicit agreement
>   to changed terms,
> - provide means for list members to be removed other than by
>   them asking for it?

Perhaps the right approach is to have a requalification process, where
each member's predisclosure list membership is reviewed periodically.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:25:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:25:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnsiR-0007F1-26; Mon, 10 Nov 2014 17:25:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XnsiP-0007Ew-IG
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:25:21 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B4/4C-17958-005F0645; Mon, 10 Nov 2014 17:25:20 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415640320!11674853!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10844 invoked from network); 10 Nov 2014 17:25:20 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-3.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 17:25:20 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XnsiK-0005HI-Mw; Mon, 10 Nov 2014 17:25:16 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.62716.692179.151697@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:25:16 +0000
To: Lars Kurth <lars.kurth.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4D7AD178-9E02-4C71-ADCC-6BF2E3DE3E80@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<54380D8F020000780003DD5E@mail.emea.novell.com>
	<4D7AD178-9E02-4C71-ADCC-6BF2E3DE3E80@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108
	process	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> I also was wondering whether it would make sense to put a time-limit
> on applications. For example, we could say that processing an
> application will take 2 weeks. By doing so, we avoid having to
> handle applications as a response to media speculation. If we get an
> application wrong, and allow somebody wrong on the list who then
> discloses information related to an embargo, we would create risks
> for others already on the list. This would be the worst possible
> outcome for the project. Just a thought

I can see that this is attractive, but on the other hand I think it
was very useful to the Xen community as a whole, that members were
able to join /during/ the last furore.  I think having an artificial
delay would generate ill-feeling.

Since IMO there should be clear objective criteria, these applications
should be routine, and we shouldn't have too much trouble with them.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:25:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:25:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnsiR-0007F1-26; Mon, 10 Nov 2014 17:25:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XnsiP-0007Ew-IG
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:25:21 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B4/4C-17958-005F0645; Mon, 10 Nov 2014 17:25:20 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415640320!11674853!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10844 invoked from network); 10 Nov 2014 17:25:20 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-3.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 17:25:20 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XnsiK-0005HI-Mw; Mon, 10 Nov 2014 17:25:16 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.62716.692179.151697@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:25:16 +0000
To: Lars Kurth <lars.kurth.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4D7AD178-9E02-4C71-ADCC-6BF2E3DE3E80@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<54380D8F020000780003DD5E@mail.emea.novell.com>
	<4D7AD178-9E02-4C71-ADCC-6BF2E3DE3E80@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108
	process	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> I also was wondering whether it would make sense to put a time-limit
> on applications. For example, we could say that processing an
> application will take 2 weeks. By doing so, we avoid having to
> handle applications as a response to media speculation. If we get an
> application wrong, and allow somebody wrong on the list who then
> discloses information related to an embargo, we would create risks
> for others already on the list. This would be the worst possible
> outcome for the project. Just a thought

I can see that this is attractive, but on the other hand I think it
was very useful to the Xen community as a whole, that members were
able to join /during/ the last furore.  I think having an artificial
delay would generate ill-feeling.

Since IMO there should be clear objective criteria, these applications
should be routine, and we shouldn't have too much trouble with them.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:27:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:27:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnskB-0007Jw-Ig; Mon, 10 Nov 2014 17:27:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnskA-0007Jq-22
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:27:10 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	38/2E-22819-D65F0645; Mon, 10 Nov 2014 17:27:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415640426!8249373!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17701 invoked from network); 10 Nov 2014 17:27:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 17:27:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191266011"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 12:24:08 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnshE-0001oZ-R6;
	Mon, 10 Nov 2014 17:24:08 +0000
Date: Mon, 10 Nov 2014 17:24:08 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141110172408.GA6588@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460F102.9000100@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, Nov 10, 2014 at 12:08:18PM -0500, Zhigang Wang wrote:
> On 11/10/2014 10:25 AM, Wei Liu wrote:
> > On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
> >> On 11/10/2014 07:35 AM, Wei Liu wrote:
> >>> I see. At that point the configuration was not available, yet. After the
> >>> domain is successfully migrated, the configuration should be available.
> >>>
> >>> I think a domain under construction without domain configuration is a
> >>> valid state. What do you think?
> >>
> >> Here is my thought:
> >>
> >> 1. In this design, if I watch xenstore @introduceDomain, it will not been
> >>    triggered until migration finish.
> >>
> > 
> > OK. What in this design makes behavior different than before? Are you
> > suggesting "xl list -l" has something to do with your xenstore watch? I
> > don't think I can get this.
> > 
> > My guess is that, you have some tool that watches @introduceDomain,
> > which happens *before* the domain creation is finished. And your tool
> > needs to get domain information once your watch fires.  Here with this
> > design, your tool cannot get the correct information until migration is
> > finished. Am I right?
> > 
> > However, in previous design, even if you manage to get configuration
> > before migration is finished, I don't think that configuration reflects
> > the true configuration of that domain. It's conceptually bogus.
> > 
> > In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
> > domain is started, so using it for that purpose would be wrong.
> > 
> >> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
> >>    domain state, we need to define what does it mean by "VM started".
> >>
> > 
> > If my above analysis is correct, will some kind of @startDomain event solve
> > your problem?
> > 
> > But this involves making changes to Xenstore protocol. Let's not go into
> > details until we make sure your requirement is well understood.
> 
> We do currently watch xenstore @introduceDomain for VM start.
> 
> I thought the @introduceDomain behavior is different than xm/xend,
> but I just did a test and I was wrong.
> 
> xm/xend also trigger @introduceDomain until domain migration finish. (but before
> @introduceDomain, all the VM xenstore entries are already there.)
> 
> Right now, I'm all set if we fix the xl list -l issue during migration.
> 

Just to be sure -- you're fine with "xl list -l" displaying no
configuration for an incoming domain, am I correct?

Wei.

> Thanks,
> 
> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:27:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:27:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnskB-0007Jw-Ig; Mon, 10 Nov 2014 17:27:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XnskA-0007Jq-22
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:27:10 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	38/2E-22819-D65F0645; Mon, 10 Nov 2014 17:27:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415640426!8249373!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17701 invoked from network); 10 Nov 2014 17:27:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 17:27:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,353,1413244800"; d="scan'208";a="191266011"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 10 Nov 2014 12:24:08 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XnshE-0001oZ-R6;
	Mon, 10 Nov 2014 17:24:08 +0000
Date: Mon, 10 Nov 2014 17:24:08 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141110172408.GA6588@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460F102.9000100@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, Nov 10, 2014 at 12:08:18PM -0500, Zhigang Wang wrote:
> On 11/10/2014 10:25 AM, Wei Liu wrote:
> > On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
> >> On 11/10/2014 07:35 AM, Wei Liu wrote:
> >>> I see. At that point the configuration was not available, yet. After the
> >>> domain is successfully migrated, the configuration should be available.
> >>>
> >>> I think a domain under construction without domain configuration is a
> >>> valid state. What do you think?
> >>
> >> Here is my thought:
> >>
> >> 1. In this design, if I watch xenstore @introduceDomain, it will not been
> >>    triggered until migration finish.
> >>
> > 
> > OK. What in this design makes behavior different than before? Are you
> > suggesting "xl list -l" has something to do with your xenstore watch? I
> > don't think I can get this.
> > 
> > My guess is that, you have some tool that watches @introduceDomain,
> > which happens *before* the domain creation is finished. And your tool
> > needs to get domain information once your watch fires.  Here with this
> > design, your tool cannot get the correct information until migration is
> > finished. Am I right?
> > 
> > However, in previous design, even if you manage to get configuration
> > before migration is finished, I don't think that configuration reflects
> > the true configuration of that domain. It's conceptually bogus.
> > 
> > In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
> > domain is started, so using it for that purpose would be wrong.
> > 
> >> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
> >>    domain state, we need to define what does it mean by "VM started".
> >>
> > 
> > If my above analysis is correct, will some kind of @startDomain event solve
> > your problem?
> > 
> > But this involves making changes to Xenstore protocol. Let's not go into
> > details until we make sure your requirement is well understood.
> 
> We do currently watch xenstore @introduceDomain for VM start.
> 
> I thought the @introduceDomain behavior is different than xm/xend,
> but I just did a test and I was wrong.
> 
> xm/xend also trigger @introduceDomain until domain migration finish. (but before
> @introduceDomain, all the VM xenstore entries are already there.)
> 
> Right now, I'm all set if we fix the xl list -l issue during migration.
> 

Just to be sure -- you're fine with "xl list -l" displaying no
configuration for an incoming domain, am I correct?

Wei.

> Thanks,
> 
> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:30:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnsms-0007Vd-6s; Mon, 10 Nov 2014 17:29:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1Xnsmr-0007VY-3f
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:29:57 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	38/BC-08051-416F0645; Mon, 10 Nov 2014 17:29:56 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415640595!12515446!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16521 invoked from network); 10 Nov 2014 17:29:56 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-7.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 17:29:56 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1Xnsml-0005h4-VA; Mon, 10 Nov 2014 17:29:51 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.62991.944718.921763@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:29:51 +0000
To: Matt Wilson <msw@linux.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xenproject.org, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On this point in particular, back in 2012 [1] I suggested that all
> membership requests should be discussed in public on a community email
> list like xen-devel, or another email list to avoid noise. The Xen
> Project Security Team shouldn't have to evaluate petitions for
> membership while managing an embargoed issue. I brought this up again
> in 2013 [2] regarding the Coverity process.

I agree that publishing applications, and the team's responses, would
be a jolly good idea.  I am 100% opposed, though, to any kind of
non-objective `community consensus' process.

Such a system would (a) be unworkable in practice, because no-one
really cares about this kind of tedious makework, and (b) at serious
risk of favouritism (or its opposite).

> This process works quite well for the distros email list, where
> requests for membership requests are discussion on oss-security (a
> public list). [...]

I don't want to criticise another community's process, but I strongly
feel that our arrangements should have broad eligibility based on
objective criteria.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:30:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnsms-0007Vd-6s; Mon, 10 Nov 2014 17:29:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1Xnsmr-0007VY-3f
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:29:57 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	38/BC-08051-416F0645; Mon, 10 Nov 2014 17:29:56 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415640595!12515446!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16521 invoked from network); 10 Nov 2014 17:29:56 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-7.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 17:29:56 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1Xnsml-0005h4-VA; Mon, 10 Nov 2014 17:29:51 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.62991.944718.921763@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:29:51 +0000
To: Matt Wilson <msw@linux.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xenproject.org, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On this point in particular, back in 2012 [1] I suggested that all
> membership requests should be discussed in public on a community email
> list like xen-devel, or another email list to avoid noise. The Xen
> Project Security Team shouldn't have to evaluate petitions for
> membership while managing an embargoed issue. I brought this up again
> in 2013 [2] regarding the Coverity process.

I agree that publishing applications, and the team's responses, would
be a jolly good idea.  I am 100% opposed, though, to any kind of
non-objective `community consensus' process.

Such a system would (a) be unworkable in practice, because no-one
really cares about this kind of tedious makework, and (b) at serious
risk of favouritism (or its opposite).

> This process works quite well for the distros email list, where
> requests for membership requests are discussion on oss-security (a
> public list). [...]

I don't want to criticise another community's process, but I strongly
feel that our arrangements should have broad eligibility based on
objective criteria.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:33:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:33:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnspl-0007ef-RG; Mon, 10 Nov 2014 17:32:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xnspk-0007eP-5y
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:32:56 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	C4/D9-17735-7C6F0645; Mon, 10 Nov 2014 17:32:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415640773!11676302!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17105 invoked from network); 10 Nov 2014 17:32:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 17:32:54 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAHWpbA003084
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 17:32:52 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAHWpvM026099
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Nov 2014 17:32:51 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAAHWnb4005093; Mon, 10 Nov 2014 17:32:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 09:32:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id ADB9C1121D3; Mon, 10 Nov 2014 12:32:48 -0500 (EST)
Date: Mon, 10 Nov 2014 12:32:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, jbeulich@suse.com
Message-ID: <20141110173248.GA13778@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug (BAR64
 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey,

With Xen 4.5 (today's staging), when I boot a guest and then do pci-attach
the BARs values are corrupt.

For example, with this guest config:

kernel=3D"hvmloader"
builder=3D"hvm"
serial=3D"pty"
memory =3D 2048
name =3D "XTT"
usb=3D1
usbdevice=3D'tablet'
vcpus=3D2
vga=3D"stdvga"
vif =3D [ 'mac=3D00:0f:4b:00:00:63,bridge=3Dxenbr0' ]
disk=3D ['file:/root/root_image.iso,hdc:cdrom,r']
vnc=3D1
vnclisten=3D"0.0.0.0"
boot =3D "dc"

And with this PCI card:
5:00.0 VGA compatible controller: NVIDIA Corporation GF104GLM [Quadro 4000M=
] (rev a1) (prog-if 00 [VGA controller])
 =A0=A0=A0=A0=A0=A0=A0Subsystem: Gigabyte Technology Co., Ltd Device 34fc
 =A0=A0=A0=A0=A0=A0=A0Flags: fast devsel, IRQ 20
 =A0=A0=A0=A0=A0=A0=A0Memory at fc000000 (32-bit, non-prefetchable) [size=
=3D32M]
 =A0=A0=A0=A0=A0=A0=A0Memory at d0000000 (64-bit, prefetchable) [size=3D128=
M]
 =A0=A0=A0=A0=A0=A0=A0Memory at d8000000 (64-bit, prefetchable) [size=3D64M]

which in dom0 is reported as:

4064] pci 0000:05:00.0: [10de:0e3b] type 00 class 0x030000
[ =A0=A022.834087] pci 0000:05:00.0: reg 0x10: [mem 0xfc000000-0xfdffffff]
[ =A0=A022.834109] pci 0000:05:00.0: reg 0x14: [mem 0xd0000000-0xd7ffffff 6=
4bit pref]
[ =A0=A022.834131] pci 0000:05:00.0: reg 0x1c: [mem 0xd8000000-0xdbffffff 6=
4bit pref]
[ =A0=A022.834144] pci 0000:05:00.0: reg 0x24: [io =A00xc000-0xc07f]
[ =A0=A022.834157] pci 0000:05:00.0: reg 0x30: [mem 0xfe000000-0xfe07ffff p=
ref]


When I assign said card (xl pci-attach XTT 05:00.0) the guest gives me:

     ... 498525] pci 0000:00:04.0: [10de:0e3b] type 00 class 0x030000
[  152.508612] pci 0000:00:04.0: reg 0x10: [mem 0x00000000-0x01ffffff]
[  152.518320] pci 0000:00:04.0: reg 0x14: [mem 0x00000000-0x07ffffff 64bit=
 preff ]
[  152.529301] pci 0000:00:04.0: reg 0x1c: [mem 0x00000000-0x03ffffff 64bit=
 preff ]
[  152.540095] pci 0000:00:04.0: reg 0x24: [io  0x0000-0x007f]
[  152.548497] pci 0000:00:04.0: reg 0x30: [mem 0x00000000-0x0007ffff pref]
[  152.561018] vgaarb: device added: PCI:0000:00:04.0,decodes=3Dio+mem,owns=
=3Dnone,llocks=3Dnone
[  152.572965] pci 0000:00:04.0: BAR 1: no space for [mem size 0x08000000 6=
4bit  pref]
[  152.583917] pci 0000:00:04.0: BAR 1: failed to assign [mem size 0x080000=
00 64 bit pref]
[  152.595528] pci 0000:00:04.0: BAR 3: assigned [mem 0xf4000000-0xf7ffffff=
 64bi t pref]

If I boot the guest with:
pci=3D["05:00.0"]
it works fine:

# dmesg | grep 05.0
[    0.000000] pcpu-alloc: [0] 000 001 002 003 004 005 006 007 008 009 010 =
011 012 013 014 015 =

[    0.905008] pci 0000:00:03.0: reg 0x10: [mem 0xef000000-0xefffffff pref]
[    0.944101] pci 0000:00:05.0: [10de:0e3b] type 00 class 0x030000
[    0.953013] pci 0000:00:05.0: reg 0x10: [mem 0xec000000-0xedffffff]
[    0.967016] pci 0000:00:05.0: reg 0x14: [mem 0xe0000000-0xe7ffffff 64bit=
 pref]
[    0.973016] pci 0000:00:05.0: reg 0x1c: [mem 0xe8000000-0xebffffff 64bit=
 pref]
[    0.981015] pci 0000:00:05.0: reg 0x24: [io  0xc200-0xc27f]
[    0.988016] pci 0000:00:05.0: reg 0x30: [mem 0xf0000000-0xf007ffff pref]
[    0.995083] vgaarb: device added: PCI:0000:00:05.0,decodes=3Dio+mem,owns=
=3Dio+mem,locks=3Dnone
[    0.997000] vgaarb: bridge control possible 0000:00:05.0
[    3.952023] nouveau  [  DEVICE][0000:00:05.0] BOOT0  : 0x0c4d80a1
[    3.952025] nouveau  [  DEVICE][0000:00:05.0] Chipset: GF104 (NVC4)
[    3.952027] nouveau  [  DEVICE][0000:00:05.0] Family : NVC0
[    3.952072] nouveau  [   VBIOS][0000:00:05.0] checking PRAMIN for image.=
..
[    3.952079] nouveau  [   VBIOS][0000:00:05.0] ... signature not found
[    3.952080] nouveau  [   VBIOS][0000:00:05.0] checking PROM for image...
[    4.096446] nouveau  [   VBIOS][0000:00:05.0] ... appears to be valid
[    4.104012] nouveau  [   VBIOS][0000:00:05.0] using image from PROM
[    4.111214] nouveau  [   VBIOS][0000:00:05.0] BIT signature found
[    4.118054] nouveau  [   VBIOS][0000:00:05.0] version 70.04.13.00.01
[    4.125248] nouveau  [ DEVINIT][0000:00:05.0] adaptor not initialised
[    4.131629] nouveau  [   VBIOS][0000:00:05.0] running init tables
[    4.227827] nouveau  [     PMC][0000:00:05.0] MSI interrupts enabled
[    4.234296] nouveau  [     PFB][0000:00:05.0] RAM type: GDDR5
[    4.240176] nouveau  [     PFB][0000:00:05.0] RAM size: 1024 MiB
[    4.245878] nouveau  [     PFB][0000:00:05.0]    ZCOMP: 0 tags
[    4.255523] nouveau  [    VOLT][0000:00:05.0] GPU voltage: 875000uv
[    4.291146] nouveau  [  PTHERM][0000:00:05.0] FAN control: PWM
[    4.296582] nouveau  [  PTHERM][0000:00:05.0] fan management: automatic
[    4.302668] nouveau  [  PTHERM][0000:00:05.0] internal sensor: yes
[    4.309465] nouveau  [     CLK][0000:00:05.0] 03: core 50 MHz memory 135=
 MHz =

[    4.317854] nouveau  [     CLK][0000:00:05.0] 07: core 405 MHz memory 32=
4 MHz =

[    4.326655] nouveau  [     CLK][0000:00:05.0] 0c: core 405 MHz memory 18=
00 MHz =

[    4.333742] nouveau  [     CLK][0000:00:05.0] 0f: core 715 MHz memory 18=
00 MHz =

[    4.341362] nouveau  [     CLK][0000:00:05.0] --: core 50 MHz memory 135=
 MHz =

[    4.749977] nouveau 0000:00:05.0: fb0: nouveaufb frame buffer device
[    4.756172] nouveau 0000:00:05.0: registered panic notifier
[    4.765041] [drm] Initialized nouveau 1.2.0 20120801 for 0000:00:05.0 on=
 minor 0



# lspci -s 00:05.0 -v
00:05.0 VGA compatible controller: nVidia Corporation Device 0e3b (rev a1) =
(prog-if 00 [VGA controller])
        Subsystem: Giga-byte Technology Device 34fc
        Physical Slot: 5
        Flags: bus master, fast devsel, latency 0, IRQ 67
        Memory at ec000000 (32-bit, non-prefetchable) [size=3D32M]
        Memory at e0000000 (64-bit, prefetchable) [size=3D128M]
        Memory at e8000000 (64-bit, prefetchable) [size=3D64M]
        I/O ports at c200 [size=3D128]
        Expansion ROM at f0000000 [disabled] [size=3D512K]


Interesting observation:

a) It does NOT make a different if I use qemu-traditinal or qemu-xen.
   In both cases I get the same BAR bogus numbers.

b) qemu-xen logging is not that great. When I used qemu-trad I discovered:


m-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 05:00.0 ...
register_real_device: Disable MSI translation via per device option
register_real_device: Disable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No =
such file or directory: 0x5:0x0.0x0
pt_register_regions: IO region registered (size=3D0x02000000 base_addr=3D0x=
fc000000)
pt_register_regions: IO region registered (size=3D0x08000000 base_addr=3D0x=
d000000c)
pt_register_regions: IO region registered (size=3D0x04000000 base_addr=3D0x=
d800000c)
pt_register_regions: IO region registered (size=3D0x00000080 base_addr=3D0x=
0000c001)
pt_register_regions: Expansion ROM registered (size=3D0x00080000 base_addr=
=3D0xfe000000)
pci_intx: intx=3D1
register_real_device: Real physical device 05:00.0 registered successfuly!
IRQ type =3D INTx
generate a sci for PHP.
deassert due to disable GPE bit.
ACPI:debug: write addr=3D0xb044, val=3D0x20.
ACPI:debug: write addr=3D0xb045, val=3D0x0.
ACPI:debug: write addr=3D0xb044, val=3D0x20.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x21.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x22.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x23.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x24.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x25.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x26.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x27.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
pt_iomem_map: e_phys=3Df2000000 maddr=3Dfc000000 type=3D0 len=3D33554432 in=
dex=3D0 first_map=3D1
pt_iomem_map: e_phys=3Df4000000 maddr=3Dd8000000 type=3D8 len=3D67108864 in=
dex=3D3 first_map=3D1
pt_ioport_map: e_phys=3D1000 pio_base=3Dc000 len=3D128 index=3D5 first_map=
=3D1
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: pt_msi_setup requested pirq =3D 87
pt_msi_setup: msi mapped with pirq 57
pt_msi_update: Update msi with pirq 57 gvec 0 gflags 3057
pci_intx: intx=3D1
pt_msi_disable: Unbind msi with pirq 57, gvec 0
pt_msi_disable: Unmap msi with pirq 57

Ideas which commit id I ought to look at?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:33:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:33:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnspl-0007ef-RG; Mon, 10 Nov 2014 17:32:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xnspk-0007eP-5y
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:32:56 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	C4/D9-17735-7C6F0645; Mon, 10 Nov 2014 17:32:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415640773!11676302!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17105 invoked from network); 10 Nov 2014 17:32:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 17:32:54 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAHWpbA003084
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 17:32:52 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAHWpvM026099
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Nov 2014 17:32:51 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAAHWnb4005093; Mon, 10 Nov 2014 17:32:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 09:32:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id ADB9C1121D3; Mon, 10 Nov 2014 12:32:48 -0500 (EST)
Date: Mon, 10 Nov 2014 12:32:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, jbeulich@suse.com
Message-ID: <20141110173248.GA13778@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug (BAR64
 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey,

With Xen 4.5 (today's staging), when I boot a guest and then do pci-attach
the BARs values are corrupt.

For example, with this guest config:

kernel=3D"hvmloader"
builder=3D"hvm"
serial=3D"pty"
memory =3D 2048
name =3D "XTT"
usb=3D1
usbdevice=3D'tablet'
vcpus=3D2
vga=3D"stdvga"
vif =3D [ 'mac=3D00:0f:4b:00:00:63,bridge=3Dxenbr0' ]
disk=3D ['file:/root/root_image.iso,hdc:cdrom,r']
vnc=3D1
vnclisten=3D"0.0.0.0"
boot =3D "dc"

And with this PCI card:
5:00.0 VGA compatible controller: NVIDIA Corporation GF104GLM [Quadro 4000M=
] (rev a1) (prog-if 00 [VGA controller])
 =A0=A0=A0=A0=A0=A0=A0Subsystem: Gigabyte Technology Co., Ltd Device 34fc
 =A0=A0=A0=A0=A0=A0=A0Flags: fast devsel, IRQ 20
 =A0=A0=A0=A0=A0=A0=A0Memory at fc000000 (32-bit, non-prefetchable) [size=
=3D32M]
 =A0=A0=A0=A0=A0=A0=A0Memory at d0000000 (64-bit, prefetchable) [size=3D128=
M]
 =A0=A0=A0=A0=A0=A0=A0Memory at d8000000 (64-bit, prefetchable) [size=3D64M]

which in dom0 is reported as:

4064] pci 0000:05:00.0: [10de:0e3b] type 00 class 0x030000
[ =A0=A022.834087] pci 0000:05:00.0: reg 0x10: [mem 0xfc000000-0xfdffffff]
[ =A0=A022.834109] pci 0000:05:00.0: reg 0x14: [mem 0xd0000000-0xd7ffffff 6=
4bit pref]
[ =A0=A022.834131] pci 0000:05:00.0: reg 0x1c: [mem 0xd8000000-0xdbffffff 6=
4bit pref]
[ =A0=A022.834144] pci 0000:05:00.0: reg 0x24: [io =A00xc000-0xc07f]
[ =A0=A022.834157] pci 0000:05:00.0: reg 0x30: [mem 0xfe000000-0xfe07ffff p=
ref]


When I assign said card (xl pci-attach XTT 05:00.0) the guest gives me:

     ... 498525] pci 0000:00:04.0: [10de:0e3b] type 00 class 0x030000
[  152.508612] pci 0000:00:04.0: reg 0x10: [mem 0x00000000-0x01ffffff]
[  152.518320] pci 0000:00:04.0: reg 0x14: [mem 0x00000000-0x07ffffff 64bit=
 preff ]
[  152.529301] pci 0000:00:04.0: reg 0x1c: [mem 0x00000000-0x03ffffff 64bit=
 preff ]
[  152.540095] pci 0000:00:04.0: reg 0x24: [io  0x0000-0x007f]
[  152.548497] pci 0000:00:04.0: reg 0x30: [mem 0x00000000-0x0007ffff pref]
[  152.561018] vgaarb: device added: PCI:0000:00:04.0,decodes=3Dio+mem,owns=
=3Dnone,llocks=3Dnone
[  152.572965] pci 0000:00:04.0: BAR 1: no space for [mem size 0x08000000 6=
4bit  pref]
[  152.583917] pci 0000:00:04.0: BAR 1: failed to assign [mem size 0x080000=
00 64 bit pref]
[  152.595528] pci 0000:00:04.0: BAR 3: assigned [mem 0xf4000000-0xf7ffffff=
 64bi t pref]

If I boot the guest with:
pci=3D["05:00.0"]
it works fine:

# dmesg | grep 05.0
[    0.000000] pcpu-alloc: [0] 000 001 002 003 004 005 006 007 008 009 010 =
011 012 013 014 015 =

[    0.905008] pci 0000:00:03.0: reg 0x10: [mem 0xef000000-0xefffffff pref]
[    0.944101] pci 0000:00:05.0: [10de:0e3b] type 00 class 0x030000
[    0.953013] pci 0000:00:05.0: reg 0x10: [mem 0xec000000-0xedffffff]
[    0.967016] pci 0000:00:05.0: reg 0x14: [mem 0xe0000000-0xe7ffffff 64bit=
 pref]
[    0.973016] pci 0000:00:05.0: reg 0x1c: [mem 0xe8000000-0xebffffff 64bit=
 pref]
[    0.981015] pci 0000:00:05.0: reg 0x24: [io  0xc200-0xc27f]
[    0.988016] pci 0000:00:05.0: reg 0x30: [mem 0xf0000000-0xf007ffff pref]
[    0.995083] vgaarb: device added: PCI:0000:00:05.0,decodes=3Dio+mem,owns=
=3Dio+mem,locks=3Dnone
[    0.997000] vgaarb: bridge control possible 0000:00:05.0
[    3.952023] nouveau  [  DEVICE][0000:00:05.0] BOOT0  : 0x0c4d80a1
[    3.952025] nouveau  [  DEVICE][0000:00:05.0] Chipset: GF104 (NVC4)
[    3.952027] nouveau  [  DEVICE][0000:00:05.0] Family : NVC0
[    3.952072] nouveau  [   VBIOS][0000:00:05.0] checking PRAMIN for image.=
..
[    3.952079] nouveau  [   VBIOS][0000:00:05.0] ... signature not found
[    3.952080] nouveau  [   VBIOS][0000:00:05.0] checking PROM for image...
[    4.096446] nouveau  [   VBIOS][0000:00:05.0] ... appears to be valid
[    4.104012] nouveau  [   VBIOS][0000:00:05.0] using image from PROM
[    4.111214] nouveau  [   VBIOS][0000:00:05.0] BIT signature found
[    4.118054] nouveau  [   VBIOS][0000:00:05.0] version 70.04.13.00.01
[    4.125248] nouveau  [ DEVINIT][0000:00:05.0] adaptor not initialised
[    4.131629] nouveau  [   VBIOS][0000:00:05.0] running init tables
[    4.227827] nouveau  [     PMC][0000:00:05.0] MSI interrupts enabled
[    4.234296] nouveau  [     PFB][0000:00:05.0] RAM type: GDDR5
[    4.240176] nouveau  [     PFB][0000:00:05.0] RAM size: 1024 MiB
[    4.245878] nouveau  [     PFB][0000:00:05.0]    ZCOMP: 0 tags
[    4.255523] nouveau  [    VOLT][0000:00:05.0] GPU voltage: 875000uv
[    4.291146] nouveau  [  PTHERM][0000:00:05.0] FAN control: PWM
[    4.296582] nouveau  [  PTHERM][0000:00:05.0] fan management: automatic
[    4.302668] nouveau  [  PTHERM][0000:00:05.0] internal sensor: yes
[    4.309465] nouveau  [     CLK][0000:00:05.0] 03: core 50 MHz memory 135=
 MHz =

[    4.317854] nouveau  [     CLK][0000:00:05.0] 07: core 405 MHz memory 32=
4 MHz =

[    4.326655] nouveau  [     CLK][0000:00:05.0] 0c: core 405 MHz memory 18=
00 MHz =

[    4.333742] nouveau  [     CLK][0000:00:05.0] 0f: core 715 MHz memory 18=
00 MHz =

[    4.341362] nouveau  [     CLK][0000:00:05.0] --: core 50 MHz memory 135=
 MHz =

[    4.749977] nouveau 0000:00:05.0: fb0: nouveaufb frame buffer device
[    4.756172] nouveau 0000:00:05.0: registered panic notifier
[    4.765041] [drm] Initialized nouveau 1.2.0 20120801 for 0000:00:05.0 on=
 minor 0



# lspci -s 00:05.0 -v
00:05.0 VGA compatible controller: nVidia Corporation Device 0e3b (rev a1) =
(prog-if 00 [VGA controller])
        Subsystem: Giga-byte Technology Device 34fc
        Physical Slot: 5
        Flags: bus master, fast devsel, latency 0, IRQ 67
        Memory at ec000000 (32-bit, non-prefetchable) [size=3D32M]
        Memory at e0000000 (64-bit, prefetchable) [size=3D128M]
        Memory at e8000000 (64-bit, prefetchable) [size=3D64M]
        I/O ports at c200 [size=3D128]
        Expansion ROM at f0000000 [disabled] [size=3D512K]


Interesting observation:

a) It does NOT make a different if I use qemu-traditinal or qemu-xen.
   In both cases I get the same BAR bogus numbers.

b) qemu-xen logging is not that great. When I used qemu-trad I discovered:


m-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 05:00.0 ...
register_real_device: Disable MSI translation via per device option
register_real_device: Disable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No =
such file or directory: 0x5:0x0.0x0
pt_register_regions: IO region registered (size=3D0x02000000 base_addr=3D0x=
fc000000)
pt_register_regions: IO region registered (size=3D0x08000000 base_addr=3D0x=
d000000c)
pt_register_regions: IO region registered (size=3D0x04000000 base_addr=3D0x=
d800000c)
pt_register_regions: IO region registered (size=3D0x00000080 base_addr=3D0x=
0000c001)
pt_register_regions: Expansion ROM registered (size=3D0x00080000 base_addr=
=3D0xfe000000)
pci_intx: intx=3D1
register_real_device: Real physical device 05:00.0 registered successfuly!
IRQ type =3D INTx
generate a sci for PHP.
deassert due to disable GPE bit.
ACPI:debug: write addr=3D0xb044, val=3D0x20.
ACPI:debug: write addr=3D0xb045, val=3D0x0.
ACPI:debug: write addr=3D0xb044, val=3D0x20.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x21.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x22.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x23.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x24.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x25.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x26.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x27.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
pt_iomem_map: e_phys=3Df2000000 maddr=3Dfc000000 type=3D0 len=3D33554432 in=
dex=3D0 first_map=3D1
pt_iomem_map: e_phys=3Df4000000 maddr=3Dd8000000 type=3D8 len=3D67108864 in=
dex=3D3 first_map=3D1
pt_ioport_map: e_phys=3D1000 pio_base=3Dc000 len=3D128 index=3D5 first_map=
=3D1
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: pt_msi_setup requested pirq =3D 87
pt_msi_setup: msi mapped with pirq 57
pt_msi_update: Update msi with pirq 57 gvec 0 gflags 3057
pci_intx: intx=3D1
pt_msi_disable: Unbind msi with pirq 57, gvec 0
pt_msi_disable: Unmap msi with pirq 57

Ideas which commit id I ought to look at?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:43:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17: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 1XnszQ-00084U-9Q; Mon, 10 Nov 2014 17:42:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XnszP-00084P-7F
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 17:42:55 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E3/3E-27584-E19F0645; Mon, 10 Nov 2014 17:42:54 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415641373!8711124!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26427 invoked from network); 10 Nov 2014 17:42:53 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 17:42:53 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XnszN-0007DH-1i; Mon, 10 Nov 2014 17:42:53 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.63773.32400.553359@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:42:53 +0000
To: Bastian Blank <bastian@waldi.eu.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20141022232354.GA27437@mail.waldi.eu.org>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<20141022232354.GA27437@mail.waldi.eu.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bastian Blank writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Thu, Oct 09, 2014 at 12:06:23AM +0100, Ian Jackson wrote:
> >   The -discuss list is moderated by the Xen Project Security Team.
> >   Announcements of private availability of fixed versions, and
> >   technical messages about embargoed advisories, will be approved.
> >   Messages dealing with policy matters will be rejected with a
> >   reference to the Security Team contact address and/or public Xen
> >   mailing lists.
> 
> Why do you think such a hypotetical list needs to be moderated?

Good question.  Primarily because I anticipate two potential failure
modes:

1. People posting non-password-protected URLs, or the like.  If the
   list is moderated we can notice this quickly and hopefully have
   things taken down.

2. Predisclosure list members using the embargoed-information-sharing
   forum as a venue for political consensus-building, planning, and
   pressurising.

Of these I am most worried about the 2nd.

We have already suffered from a few very dramatic incidents, where
predisclosure list members used their privileged informational
position to try to gain advantage in policymaking and policy
interpretation.

The idea that the predisclosure list members are somehow the most
proper or most real stakeholders and that it is their opinion which
ought to count is distressingly prevalent - especially, it appears,
amongst some of the senior management of some predisclosure list
members.  When a security crisis is in full swing, such management
often becomes involved.  As I say we have had multiple occasions
where intense political pressure was applied.

It would be a very bad idea to explicitly provide a forum which
predisclosure list members - whose interests are ill-aligned with
those of the public at large - could use for confidential lobbying,
political coordination, and networking.  (It might even be illegal;
private collusion by predisclosure list members to manipulate
policymaking might well sometimes be illegal in any case.)

If the list is to be unmoderated, at the very least, we would need an
automatic mechanism which would publish all of the exchanges on a
particular issue at the end of its embargo.  ATM we don't have
software to do that.


> >   List members who are service providers may deploy fixed versions
> >   during the embargo, PROVIDED THAT any action taken by the service
> >   provider gives no indication (to their users or anyone else) as to
> >   the nature of the vulnerability.
> 
> Why this constraint to "who are service providers"?

Thanks for pointing out this problem.

This was not intended to be a constraint; it was intended to mean
`_even_ those who are service providers'.  Since it was previously
`obvious' that people with private Xen deployments can deploy fixes
when they get them.

I will make a revised proposal for wording in this area.


> > The Security Team should be forbidden from trying to hunt down
> > eligibility information etc. and should instead be mandated to reject
> > incomplete requests.
> >   The Security Team has no discretion to accept applications which do
> >   not provide all of the information required above.
> 
> Is there are particular reason why do you want to restrict them?

As a member of the Security Team I would like to be able to say `sorry
your application did not qualify'.  I don't want to have to say `sorry
your application didn't quite meet the criteria and we have chosen not
to exercise our discretion'.

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 Nov 10 17:43:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17: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 1XnszQ-00084U-9Q; Mon, 10 Nov 2014 17:42:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XnszP-00084P-7F
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 17:42:55 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E3/3E-27584-E19F0645; Mon, 10 Nov 2014 17:42:54 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415641373!8711124!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26427 invoked from network); 10 Nov 2014 17:42:53 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 17:42:53 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XnszN-0007DH-1i; Mon, 10 Nov 2014 17:42:53 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.63773.32400.553359@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:42:53 +0000
To: Bastian Blank <bastian@waldi.eu.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20141022232354.GA27437@mail.waldi.eu.org>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<20141022232354.GA27437@mail.waldi.eu.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bastian Blank writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Thu, Oct 09, 2014 at 12:06:23AM +0100, Ian Jackson wrote:
> >   The -discuss list is moderated by the Xen Project Security Team.
> >   Announcements of private availability of fixed versions, and
> >   technical messages about embargoed advisories, will be approved.
> >   Messages dealing with policy matters will be rejected with a
> >   reference to the Security Team contact address and/or public Xen
> >   mailing lists.
> 
> Why do you think such a hypotetical list needs to be moderated?

Good question.  Primarily because I anticipate two potential failure
modes:

1. People posting non-password-protected URLs, or the like.  If the
   list is moderated we can notice this quickly and hopefully have
   things taken down.

2. Predisclosure list members using the embargoed-information-sharing
   forum as a venue for political consensus-building, planning, and
   pressurising.

Of these I am most worried about the 2nd.

We have already suffered from a few very dramatic incidents, where
predisclosure list members used their privileged informational
position to try to gain advantage in policymaking and policy
interpretation.

The idea that the predisclosure list members are somehow the most
proper or most real stakeholders and that it is their opinion which
ought to count is distressingly prevalent - especially, it appears,
amongst some of the senior management of some predisclosure list
members.  When a security crisis is in full swing, such management
often becomes involved.  As I say we have had multiple occasions
where intense political pressure was applied.

It would be a very bad idea to explicitly provide a forum which
predisclosure list members - whose interests are ill-aligned with
those of the public at large - could use for confidential lobbying,
political coordination, and networking.  (It might even be illegal;
private collusion by predisclosure list members to manipulate
policymaking might well sometimes be illegal in any case.)

If the list is to be unmoderated, at the very least, we would need an
automatic mechanism which would publish all of the exchanges on a
particular issue at the end of its embargo.  ATM we don't have
software to do that.


> >   List members who are service providers may deploy fixed versions
> >   during the embargo, PROVIDED THAT any action taken by the service
> >   provider gives no indication (to their users or anyone else) as to
> >   the nature of the vulnerability.
> 
> Why this constraint to "who are service providers"?

Thanks for pointing out this problem.

This was not intended to be a constraint; it was intended to mean
`_even_ those who are service providers'.  Since it was previously
`obvious' that people with private Xen deployments can deploy fixes
when they get them.

I will make a revised proposal for wording in this area.


> > The Security Team should be forbidden from trying to hunt down
> > eligibility information etc. and should instead be mandated to reject
> > incomplete requests.
> >   The Security Team has no discretion to accept applications which do
> >   not provide all of the information required above.
> 
> Is there are particular reason why do you want to restrict them?

As a member of the Security Team I would like to be able to say `sorry
your application did not qualify'.  I don't want to have to say `sorry
your application didn't quite meet the criteria and we have chosen not
to exercise our discretion'.

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 Nov 10 17:44:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnt0m-00088z-P8; Mon, 10 Nov 2014 17:44:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1Xnt0l-00088s-Kq
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:44:19 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	67/77-18267-279F0645; Mon, 10 Nov 2014 17:44:18 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415641458!9190373!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19690 invoked from network); 10 Nov 2014 17:44:18 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-14.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 17:44:18 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1Xnt0j-0007MD-71; Mon, 10 Nov 2014 17:44:17 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.63857.188648.848494@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:44:17 +0000
To: Matt Wilson <msw@linux.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20141022155331.GA26875@u109add4315675089e695.ant.amazon.com>
References: <F4F965CC-BC88-4D1C-9E19-BFD9E4298C18@gmail.com>
	<20141022003517.GA784@u109add4315675089e695.ant.amazon.com>
	<85CD9DFC-0DC1-4E70-ABDB-FE127C9F09DC@gmail.com>
	<20141022155331.GA26875@u109add4315675089e695.ant.amazon.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, xen-devel@lists.xenproject.org,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Wed, Oct 22, 2014 at 02:05:38PM +0100, Lars Kurth wrote:
> > The changes on the table are really more practical and aim at
> > demonstrating a) use of Xen and b) a mature security vulnerability
> > process. So I don't think there is a contradiction with having
> > criteria.
> 
> I don't think a) and b) are nearly enough. The bar needs to be set a
> lot higher. But this is something we can discuss in a different part
> of the thread.

I agree with Ian Campbell on this topic.  The predisclosure list ought
to remain very broad.  Like Ian, I would give very different answers
to all the other questions, if the membership criteria were narrowed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:44:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnt0m-00088z-P8; Mon, 10 Nov 2014 17:44:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1Xnt0l-00088s-Kq
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:44:19 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	67/77-18267-279F0645; Mon, 10 Nov 2014 17:44:18 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415641458!9190373!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19690 invoked from network); 10 Nov 2014 17:44:18 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-14.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 17:44:18 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1Xnt0j-0007MD-71; Mon, 10 Nov 2014 17:44:17 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.63857.188648.848494@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:44:17 +0000
To: Matt Wilson <msw@linux.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20141022155331.GA26875@u109add4315675089e695.ant.amazon.com>
References: <F4F965CC-BC88-4D1C-9E19-BFD9E4298C18@gmail.com>
	<20141022003517.GA784@u109add4315675089e695.ant.amazon.com>
	<85CD9DFC-0DC1-4E70-ABDB-FE127C9F09DC@gmail.com>
	<20141022155331.GA26875@u109add4315675089e695.ant.amazon.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, xen-devel@lists.xenproject.org,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
 post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Wed, Oct 22, 2014 at 02:05:38PM +0100, Lars Kurth wrote:
> > The changes on the table are really more practical and aim at
> > demonstrating a) use of Xen and b) a mature security vulnerability
> > process. So I don't think there is a contradiction with having
> > criteria.
> 
> I don't think a) and b) are nearly enough. The bar needs to be set a
> lot higher. But this is something we can discuss in a different part
> of the thread.

I agree with Ian Campbell on this topic.  The predisclosure list ought
to remain very broad.  Like Ian, I would give very different answers
to all the other questions, if the membership criteria were narrowed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:51:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:51:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnt7K-0008O4-Ru; Mon, 10 Nov 2014 17:51:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xnt7K-0008Nz-6t
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:51:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2C/B7-09842-90BF0645; Mon, 10 Nov 2014 17:51:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415641861!12827221!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19751 invoked from network); 10 Nov 2014 17:51:05 -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;
	10 Nov 2014 17:51:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,354,1413244800"; d="scan'208";a="189831988"
Message-ID: <5460F908.4040208@citrix.com>
Date: Mon, 10 Nov 2014 17:42:32 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	<xen-devel@lists.xenproject.org>, <jbeulich@suse.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
In-Reply-To: <20141110173248.GA13778@laptop.dumpdata.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> With Xen 4.5 (today's staging), when I boot a guest and then do pci-attach
> the BARs values are corrupt.

Corrupt?

> [  152.572965] pci 0000:00:04.0: BAR 1: no space for [mem size 0x08000000 64bit  pref]

Looks like the default MMIO hole isn't large enough for this device.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:51:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:51:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnt7K-0008O4-Ru; Mon, 10 Nov 2014 17:51:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xnt7K-0008Nz-6t
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:51:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2C/B7-09842-90BF0645; Mon, 10 Nov 2014 17:51:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415641861!12827221!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19751 invoked from network); 10 Nov 2014 17:51:05 -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;
	10 Nov 2014 17:51:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,354,1413244800"; d="scan'208";a="189831988"
Message-ID: <5460F908.4040208@citrix.com>
Date: Mon, 10 Nov 2014 17:42:32 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	<xen-devel@lists.xenproject.org>, <jbeulich@suse.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
In-Reply-To: <20141110173248.GA13778@laptop.dumpdata.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> With Xen 4.5 (today's staging), when I boot a guest and then do pci-attach
> the BARs values are corrupt.

Corrupt?

> [  152.572965] pci 0000:00:04.0: BAR 1: no space for [mem size 0x08000000 64bit  pref]

Looks like the default MMIO hole isn't large enough for this device.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:54:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:54:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntAc-00006w-I4; Mon, 10 Nov 2014 17:54:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XntAb-00006p-Bh
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:54:29 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	BE/8E-25714-4DBF0645; Mon, 10 Nov 2014 17:54:28 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415642066!11591799!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12895 invoked from network); 10 Nov 2014 17:54:28 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 17:54:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAHsKt5001001
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 17:54:21 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAHsJDV010128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 17:54:20 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAHsJME008842; Mon, 10 Nov 2014 17:54:19 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 09:54:19 -0800
Message-ID: <5460FBCA.5060302@oracle.com>
Date: Mon, 10 Nov 2014 12:54:18 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
In-Reply-To: <20141110172408.GA6588@zion.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/10/2014 12:24 PM, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 12:08:18PM -0500, Zhigang Wang wrote:
>> On 11/10/2014 10:25 AM, Wei Liu wrote:
>>> On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
>>>> On 11/10/2014 07:35 AM, Wei Liu wrote:
>>>>> I see. At that point the configuration was not available, yet. After the
>>>>> domain is successfully migrated, the configuration should be available.
>>>>>
>>>>> I think a domain under construction without domain configuration is a
>>>>> valid state. What do you think?
>>>>
>>>> Here is my thought:
>>>>
>>>> 1. In this design, if I watch xenstore @introduceDomain, it will not been
>>>>    triggered until migration finish.
>>>>
>>>
>>> OK. What in this design makes behavior different than before? Are you
>>> suggesting "xl list -l" has something to do with your xenstore watch? I
>>> don't think I can get this.
>>>
>>> My guess is that, you have some tool that watches @introduceDomain,
>>> which happens *before* the domain creation is finished. And your tool
>>> needs to get domain information once your watch fires.  Here with this
>>> design, your tool cannot get the correct information until migration is
>>> finished. Am I right?
>>>
>>> However, in previous design, even if you manage to get configuration
>>> before migration is finished, I don't think that configuration reflects
>>> the true configuration of that domain. It's conceptually bogus.
>>>
>>> In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
>>> domain is started, so using it for that purpose would be wrong.
>>>
>>>> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
>>>>    domain state, we need to define what does it mean by "VM started".
>>>>
>>>
>>> If my above analysis is correct, will some kind of @startDomain event solve
>>> your problem?
>>>
>>> But this involves making changes to Xenstore protocol. Let's not go into
>>> details until we make sure your requirement is well understood.
>>
>> We do currently watch xenstore @introduceDomain for VM start.
>>
>> I thought the @introduceDomain behavior is different than xm/xend,
>> but I just did a test and I was wrong.
>>
>> xm/xend also trigger @introduceDomain until domain migration finish. (but before
>> @introduceDomain, all the VM xenstore entries are already there.)
>>
>> Right now, I'm all set if we fix the xl list -l issue during migration.
>>
> 
> Just to be sure -- you're fine with "xl list -l" displaying no
> configuration for an incoming domain, am I correct?

Could you please explain what does "no configuration" means?

Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.

Or do you mean show some info of the domain, but lack some parts? If this the case,
here I attach an example and you can tell me which part will be missing:

# xl list -l
...

   {
        "domid": 4,
        "config": {
            "c_info": {
                "type": "pv",
                "name": "0004fb0000060000495324cb831d2664",
                "uuid": "0004fb00-0006-0000-4953-24cb831d2664",
                "run_hotplug_scripts": "True"
            },
            "b_info": {
                "max_vcpus": 2,
                "avail_vcpus": [
                    0,
                    1
                ],
                "max_memkb": 716800,
                "target_memkb": 716800,
                "shadow_memkb": 7648,
                "sched_params": {
                    "weight": 55000
                },
                "claim_mode": "True",
                "type.pv": {
                    "bootloader": "/usr/bin/pygrub"
                }
            },
            "disks": [
                {
                    "pdev_path": "/OVS/Repositories/0004fb0000030000abbd129258377a77/VirtualDisks/OVM_OL6U4_X86_64_PVM_2GB_UEK3_System.img",
                    "vdev": "xvda",
                    "format": "raw",
                    "readwrite": 1
                }
            ],
            "nics": [
                {
                    "devid": 0,
                    "mac": "00:21:f6:00:08:aa",
                    "bridge": "1011d6ac59"
                }
            ],
            "vfbs": [
                {
                    "devid": 0,
                    "vnc": {
                        "listen": "127.0.0.1",
                        "findunused": "True"
                    },
                    "sdl": {

                    },
                    "keymap": "en-us"
                }
            ],
            "vkbs": [
                {
                    "devid": 0
                }
            ],
            "on_reboot": "restart",
            "on_crash": "restart"
        }
    }

Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 17:54:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 17:54:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntAc-00006w-I4; Mon, 10 Nov 2014 17:54:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XntAb-00006p-Bh
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 17:54:29 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	BE/8E-25714-4DBF0645; Mon, 10 Nov 2014 17:54:28 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415642066!11591799!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12895 invoked from network); 10 Nov 2014 17:54:28 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 17:54:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAHsKt5001001
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 17:54:21 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAHsJDV010128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 17:54:20 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAHsJME008842; Mon, 10 Nov 2014 17:54:19 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 09:54:19 -0800
Message-ID: <5460FBCA.5060302@oracle.com>
Date: Mon, 10 Nov 2014 12:54:18 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
In-Reply-To: <20141110172408.GA6588@zion.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/10/2014 12:24 PM, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 12:08:18PM -0500, Zhigang Wang wrote:
>> On 11/10/2014 10:25 AM, Wei Liu wrote:
>>> On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
>>>> On 11/10/2014 07:35 AM, Wei Liu wrote:
>>>>> I see. At that point the configuration was not available, yet. After the
>>>>> domain is successfully migrated, the configuration should be available.
>>>>>
>>>>> I think a domain under construction without domain configuration is a
>>>>> valid state. What do you think?
>>>>
>>>> Here is my thought:
>>>>
>>>> 1. In this design, if I watch xenstore @introduceDomain, it will not been
>>>>    triggered until migration finish.
>>>>
>>>
>>> OK. What in this design makes behavior different than before? Are you
>>> suggesting "xl list -l" has something to do with your xenstore watch? I
>>> don't think I can get this.
>>>
>>> My guess is that, you have some tool that watches @introduceDomain,
>>> which happens *before* the domain creation is finished. And your tool
>>> needs to get domain information once your watch fires.  Here with this
>>> design, your tool cannot get the correct information until migration is
>>> finished. Am I right?
>>>
>>> However, in previous design, even if you manage to get configuration
>>> before migration is finished, I don't think that configuration reflects
>>> the true configuration of that domain. It's conceptually bogus.
>>>
>>> In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
>>> domain is started, so using it for that purpose would be wrong.
>>>
>>>> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
>>>>    domain state, we need to define what does it mean by "VM started".
>>>>
>>>
>>> If my above analysis is correct, will some kind of @startDomain event solve
>>> your problem?
>>>
>>> But this involves making changes to Xenstore protocol. Let's not go into
>>> details until we make sure your requirement is well understood.
>>
>> We do currently watch xenstore @introduceDomain for VM start.
>>
>> I thought the @introduceDomain behavior is different than xm/xend,
>> but I just did a test and I was wrong.
>>
>> xm/xend also trigger @introduceDomain until domain migration finish. (but before
>> @introduceDomain, all the VM xenstore entries are already there.)
>>
>> Right now, I'm all set if we fix the xl list -l issue during migration.
>>
> 
> Just to be sure -- you're fine with "xl list -l" displaying no
> configuration for an incoming domain, am I correct?

Could you please explain what does "no configuration" means?

Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.

Or do you mean show some info of the domain, but lack some parts? If this the case,
here I attach an example and you can tell me which part will be missing:

# xl list -l
...

   {
        "domid": 4,
        "config": {
            "c_info": {
                "type": "pv",
                "name": "0004fb0000060000495324cb831d2664",
                "uuid": "0004fb00-0006-0000-4953-24cb831d2664",
                "run_hotplug_scripts": "True"
            },
            "b_info": {
                "max_vcpus": 2,
                "avail_vcpus": [
                    0,
                    1
                ],
                "max_memkb": 716800,
                "target_memkb": 716800,
                "shadow_memkb": 7648,
                "sched_params": {
                    "weight": 55000
                },
                "claim_mode": "True",
                "type.pv": {
                    "bootloader": "/usr/bin/pygrub"
                }
            },
            "disks": [
                {
                    "pdev_path": "/OVS/Repositories/0004fb0000030000abbd129258377a77/VirtualDisks/OVM_OL6U4_X86_64_PVM_2GB_UEK3_System.img",
                    "vdev": "xvda",
                    "format": "raw",
                    "readwrite": 1
                }
            ],
            "nics": [
                {
                    "devid": 0,
                    "mac": "00:21:f6:00:08:aa",
                    "bridge": "1011d6ac59"
                }
            ],
            "vfbs": [
                {
                    "devid": 0,
                    "vnc": {
                        "listen": "127.0.0.1",
                        "findunused": "True"
                    },
                    "sdl": {

                    },
                    "keymap": "en-us"
                }
            ],
            "vkbs": [
                {
                    "devid": 0
                }
            ],
            "on_reboot": "restart",
            "on_crash": "restart"
        }
    }

Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:01:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:01:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntHO-0000Nu-M8; Mon, 10 Nov 2014 18:01:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XntHN-0000Np-Jr
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 18:01:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	67/F1-09842-87DF0645; Mon, 10 Nov 2014 18:01:28 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415642488!12811415!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18919 invoked from network); 10 Nov 2014 18:01:28 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 18:01:28 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XntHL-0000NK-Kt; Mon, 10 Nov 2014 18:01:27 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.64887.416522.656249@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 18:01:27 +0000
To: Lars Kurth <lars.kurth.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108
	process	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Having gone through the thread, I've prepared a three-part new
proposal email.

I. Deployment with Security Team Permission
II. Predisclosure list memembership
III. Information sharing
IV. Fixes which seem to have rough consensus as they were

Perhaps I should be checking the current web page out as a git tree
and preparing a patch series ?

Thanks,
Ian.


I. Deployment with Security Team Permission
===========================================

Permitting deployment during embargo seemed to have rough consensus on
the principle.  We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
set of patches.  So I suggest something like this:

  List members may deploy fixed versions during the embargo, only with
  permission from the Security Team.  The Security Team will normally
  permit such deployment, even for systems where VMs are managed or
  used by non-members of the predisclosure risk.  Permission for
  deployment, and any restrictions, will be stated in the embargoed
  advisory text.

  The Security Team will impose deployment restrictions only insofar
  as it is necessary to prevent the exposure of technicalities (for
  example, differences in behaviour) which present a significant risk
  of rediscovery of the vulnerability.  Such situations are expected
  to be rare.



II. Predisclosure list memembership
===================================

The idea of objective criteria seemed to find favour, and the general
scheme I proposed.

Lars suggested we should "test" this.  I think therefore that we
should invite a participants in this thread to write up and post
applications which we can then test against the proposed policy.  But
we should probably wait until we have rough consensus on the new
policy shape.

I have dropped the section about bad websites.  I don't think its lack
will make much difference to the way applications are processed in
practice, and I still think documenting the issue would be useful, but
it's clear that I'm not going to get consensus for it.

Changes that I have made are:
 - Applications to be made, and decisions sent, to a public mailing list
 - Explicitly say that the Security Team decide and that they have no
   discretion
 - Explicitly say that there is appeal to the project governance process
   (Lars: perhaps this should say something different or more specific?)


So as I said before, applicants should be required to:

  - Provide information on their public web pages which makes
    it clear that and why they are eligible;

  - Specifically, publicly state that and how they are using Xen
    (so that the Security Team can verify eligibility);

  - Provide a way for members of the public to responsibly report
    security problems to the applicant, just as the Xen Project does.

The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.

Specifically, I propose that the section on list membership
applications be entirely replaced with this:

  Organisations who meet the criteria should contact
  predisclosure-applications@xenproject if they wish to receive
  pre-disclosure of advisories.  That is a public mailing list.

  You must include in the e-mail:

    * The name of your organization.

    * Domain name(s) which you use to provide Xen software/services.

    * A brief description of why you fit the criteria.

    * If not all of your products/services use Xen, a list of (some
      of) your products/services (or categories thereof) which do.

    * Link(s) to current public web pages, belonging to your
      organisation, for each of following pieces of information:

      o Evidence of your status as a service/software provider:
        + If you are a public hosting provider, your public rates
          or how to get a quote
        + If you are a software provider, how your
          software can be downloaded or purchased
        + If you are an open-source project, a mailing list
          archive and/or version control repository, with
          active development

      o Evidence of your status as a user of Xen:
        + Statements about, or descriptions of, your eligible
          production services or released software, from which it is
          immediately evident that they use Xen.

      o Information about your handling of security problems:
        + Your invitation to members of the public, who discover
          security problems with your products/services, to report
          them in confidence to you;
        + Specifically, the contact information (email addresses or
          other contact instructions) which such a member of the
          public should use.

      Blog postings, conference presentations, social media pages,
      Flash presentations, videos, sites which require registration,
      anything password-protected, etc., are not acceptable.  PDFs of
      reasonable size are acceptable so long as the URL you provide is
      of a ordinary HTML page providing a link to the PDF.

      If the pages are long and/or PDFs are involved, your email
      should say which part of the pages and documents are relevant.

    * A statement to the effect that you have read this policy and
      agree to abide by the terms for inclusion in the list,
      specifically the requirements regarding confidentiality during
      an embargo period.

    * The single (non-personal) email alias you wish added to the
      predisclosure list.

  Your application will be determined by the Xen Project Security
  Team, and their decision posted to the list.  The Security Team has
  no discretion to accept applications which do not provide all of the
  information required above.

  If you are dissatisfied with the Security Team's decision you may
  appeal it via the Xen Project's governance processes.



III. Information-sharing
========================

Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have rough consensus in principle.  There was some
discussion about the details.  I remain convinced that my previous
proposal is correct and I think we should be able to get consensus for
it.

So I reproduce it (unchanged from my previous proposed wording):

  List members are allowed to share fixes to embargoed issues,
  analysis, etc., with the security teams of other list members.
  Technical measures must be taken to prevents non-list-member
  organisations, or unauthorised staff in list-member organisations,
  from obtaining the embargoed materials.

  The Xen Project provides the mailing list
     xen-security-issues-discuss@lists.xenproject.org
  for this purpose.  List members are encouraged to use it but
  may share with other list members' security teams via other
  channels.

  The -discuss list's distribution is identical to that of the primary
  predisclosure list xen-security-issues.  Recipient organisations who
  do not wish to receive all of the traffic on -discuss should use
  recipient-side email filtering based on the provided `List-Id'.

  The -discuss list is moderated by the Xen Project Security Team.
  Announcements of private availability of fixed versions, and
  technical messages about embargoed advisories, will be approved.
  Messages dealing with policy matters will be rejected with a
  reference to the Security Team contact address and/or public Xen
  mailing lists.


IV. Fixes which seem to have rough consensus as they were
=========================================================

(Reproduced unchanged from my previous proposed wording:)

The Security Team should not be invited to give permission
specifically for the release of patched software.  I think the rider
was mistakenly merged into the final the bullet point in the list.  It
should be separated out.  Also, the predisclosure list members should
not be invited to consult the discoverer.

The note about CVE numbers should be moved into the list of
forbidden-disclosures, as a new bullet point.  So overall I would
delete that whole paragraph about CVEs (we don't need the historical
information) and adjust the end of the forbidden disclosures to read:

    ...
    * patched software (even in binary form)
    * CVE number(s)

  without prior consultation with security@xenproject.


> Service announcements to non-list-member users during embargo

We should add just below the list of bullet points of things which may
be disclosed:

  Where the list member is a service provider who intends to take
  disruptive action such as rebooting as part of deploying a fix (see
  above): the list member's communications to its users about the
  service disruption may mention that the disruption is to correct a
  security issue, and relate it to the public information about the
  issue (as listed above).


-- 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:01:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:01:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntHO-0000Nu-M8; Mon, 10 Nov 2014 18:01:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XntHN-0000Np-Jr
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 18:01:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	67/F1-09842-87DF0645; Mon, 10 Nov 2014 18:01:28 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415642488!12811415!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18919 invoked from network); 10 Nov 2014 18:01:28 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 18:01:28 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XntHL-0000NK-Kt; Mon, 10 Nov 2014 18:01:27 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.64887.416522.656249@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 18:01:27 +0000
To: Lars Kurth <lars.kurth.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108
	process	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Having gone through the thread, I've prepared a three-part new
proposal email.

I. Deployment with Security Team Permission
II. Predisclosure list memembership
III. Information sharing
IV. Fixes which seem to have rough consensus as they were

Perhaps I should be checking the current web page out as a git tree
and preparing a patch series ?

Thanks,
Ian.


I. Deployment with Security Team Permission
===========================================

Permitting deployment during embargo seemed to have rough consensus on
the principle.  We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
set of patches.  So I suggest something like this:

  List members may deploy fixed versions during the embargo, only with
  permission from the Security Team.  The Security Team will normally
  permit such deployment, even for systems where VMs are managed or
  used by non-members of the predisclosure risk.  Permission for
  deployment, and any restrictions, will be stated in the embargoed
  advisory text.

  The Security Team will impose deployment restrictions only insofar
  as it is necessary to prevent the exposure of technicalities (for
  example, differences in behaviour) which present a significant risk
  of rediscovery of the vulnerability.  Such situations are expected
  to be rare.



II. Predisclosure list memembership
===================================

The idea of objective criteria seemed to find favour, and the general
scheme I proposed.

Lars suggested we should "test" this.  I think therefore that we
should invite a participants in this thread to write up and post
applications which we can then test against the proposed policy.  But
we should probably wait until we have rough consensus on the new
policy shape.

I have dropped the section about bad websites.  I don't think its lack
will make much difference to the way applications are processed in
practice, and I still think documenting the issue would be useful, but
it's clear that I'm not going to get consensus for it.

Changes that I have made are:
 - Applications to be made, and decisions sent, to a public mailing list
 - Explicitly say that the Security Team decide and that they have no
   discretion
 - Explicitly say that there is appeal to the project governance process
   (Lars: perhaps this should say something different or more specific?)


So as I said before, applicants should be required to:

  - Provide information on their public web pages which makes
    it clear that and why they are eligible;

  - Specifically, publicly state that and how they are using Xen
    (so that the Security Team can verify eligibility);

  - Provide a way for members of the public to responsibly report
    security problems to the applicant, just as the Xen Project does.

The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.

Specifically, I propose that the section on list membership
applications be entirely replaced with this:

  Organisations who meet the criteria should contact
  predisclosure-applications@xenproject if they wish to receive
  pre-disclosure of advisories.  That is a public mailing list.

  You must include in the e-mail:

    * The name of your organization.

    * Domain name(s) which you use to provide Xen software/services.

    * A brief description of why you fit the criteria.

    * If not all of your products/services use Xen, a list of (some
      of) your products/services (or categories thereof) which do.

    * Link(s) to current public web pages, belonging to your
      organisation, for each of following pieces of information:

      o Evidence of your status as a service/software provider:
        + If you are a public hosting provider, your public rates
          or how to get a quote
        + If you are a software provider, how your
          software can be downloaded or purchased
        + If you are an open-source project, a mailing list
          archive and/or version control repository, with
          active development

      o Evidence of your status as a user of Xen:
        + Statements about, or descriptions of, your eligible
          production services or released software, from which it is
          immediately evident that they use Xen.

      o Information about your handling of security problems:
        + Your invitation to members of the public, who discover
          security problems with your products/services, to report
          them in confidence to you;
        + Specifically, the contact information (email addresses or
          other contact instructions) which such a member of the
          public should use.

      Blog postings, conference presentations, social media pages,
      Flash presentations, videos, sites which require registration,
      anything password-protected, etc., are not acceptable.  PDFs of
      reasonable size are acceptable so long as the URL you provide is
      of a ordinary HTML page providing a link to the PDF.

      If the pages are long and/or PDFs are involved, your email
      should say which part of the pages and documents are relevant.

    * A statement to the effect that you have read this policy and
      agree to abide by the terms for inclusion in the list,
      specifically the requirements regarding confidentiality during
      an embargo period.

    * The single (non-personal) email alias you wish added to the
      predisclosure list.

  Your application will be determined by the Xen Project Security
  Team, and their decision posted to the list.  The Security Team has
  no discretion to accept applications which do not provide all of the
  information required above.

  If you are dissatisfied with the Security Team's decision you may
  appeal it via the Xen Project's governance processes.



III. Information-sharing
========================

Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have rough consensus in principle.  There was some
discussion about the details.  I remain convinced that my previous
proposal is correct and I think we should be able to get consensus for
it.

So I reproduce it (unchanged from my previous proposed wording):

  List members are allowed to share fixes to embargoed issues,
  analysis, etc., with the security teams of other list members.
  Technical measures must be taken to prevents non-list-member
  organisations, or unauthorised staff in list-member organisations,
  from obtaining the embargoed materials.

  The Xen Project provides the mailing list
     xen-security-issues-discuss@lists.xenproject.org
  for this purpose.  List members are encouraged to use it but
  may share with other list members' security teams via other
  channels.

  The -discuss list's distribution is identical to that of the primary
  predisclosure list xen-security-issues.  Recipient organisations who
  do not wish to receive all of the traffic on -discuss should use
  recipient-side email filtering based on the provided `List-Id'.

  The -discuss list is moderated by the Xen Project Security Team.
  Announcements of private availability of fixed versions, and
  technical messages about embargoed advisories, will be approved.
  Messages dealing with policy matters will be rejected with a
  reference to the Security Team contact address and/or public Xen
  mailing lists.


IV. Fixes which seem to have rough consensus as they were
=========================================================

(Reproduced unchanged from my previous proposed wording:)

The Security Team should not be invited to give permission
specifically for the release of patched software.  I think the rider
was mistakenly merged into the final the bullet point in the list.  It
should be separated out.  Also, the predisclosure list members should
not be invited to consult the discoverer.

The note about CVE numbers should be moved into the list of
forbidden-disclosures, as a new bullet point.  So overall I would
delete that whole paragraph about CVEs (we don't need the historical
information) and adjust the end of the forbidden disclosures to read:

    ...
    * patched software (even in binary form)
    * CVE number(s)

  without prior consultation with security@xenproject.


> Service announcements to non-list-member users during embargo

We should add just below the list of bullet points of things which may
be disclosed:

  Where the list member is a service provider who intends to take
  disruptive action such as rebooting as part of deploying a fix (see
  above): the list member's communications to its users about the
  service disruption may mention that the disruption is to correct a
  security issue, and relate it to the public information about the
  issue (as listed above).


-- 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:04:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:04:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntJy-0000ZH-Dv; Mon, 10 Nov 2014 18:04:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XntJx-0000ZA-76
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 18:04:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	68/B4-09842-81EF0645; Mon, 10 Nov 2014 18:04:08 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415642648!12756025!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31383 invoked from network); 10 Nov 2014 18:04:08 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 18:04:08 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XntJt-0000Zx-HQ; Mon, 10 Nov 2014 18:04:05 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.65045.512432.873464@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 18:04:05 +0000
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZbnsiuKzvSycXLz81H1XadQ9JoK8M7dr5QpYmQiDXW7eA@mail.gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
	<21600.62991.944718.921763@chiark.greenend.org.uk>
	<CAFLBxZbnsiuKzvSycXLz81H1XadQ9JoK8M7dr5QpYmQiDXW7eA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Matt Wilson <msw@linux.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Security policy ambiguities - XSA-108 process post-mortem"):
> On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson
> > Such a system would (a) be unworkable in practice, because no-one
> > really cares about this kind of tedious makework, and (b) at serious
> > risk of favouritism (or its opposite).
> 
> "It's opposite" meaning, "We all hate company X, so let's not let them
> join the list"?

Yes.

> > I don't want to criticise another community's process, but I strongly
> > feel that our arrangements should have broad eligibility based on
> > objective criteria.
> 
> Having black-and-white rules is nice and simple and safe; but in most
> reasonably "rich" domains, it's very difficult to come up with simple,
> objective criteria that cover all situations satisfactorily.  This is
> true in morality and law; my guess is that it's true here as well.
> 
> But I'd be willing to take a look at such a list; maybe I'm wrong
> about how objective we can make things. :-)

I think the spirit behind our previous criteria is objective.  The
problem we had was just that the rules didn't specify enough about the
*form of the predisclosure list application*.

That's why my proposed change doesn't actually touch the criteria part
of the policy.  It just formalises the application process.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:04:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:04:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntJy-0000ZH-Dv; Mon, 10 Nov 2014 18:04:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XntJx-0000ZA-76
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 18:04:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	68/B4-09842-81EF0645; Mon, 10 Nov 2014 18:04:08 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415642648!12756025!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31383 invoked from network); 10 Nov 2014 18:04:08 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Nov 2014 18:04:08 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XntJt-0000Zx-HQ; Mon, 10 Nov 2014 18:04:05 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21600.65045.512432.873464@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 18:04:05 +0000
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZbnsiuKzvSycXLz81H1XadQ9JoK8M7dr5QpYmQiDXW7eA@mail.gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
	<21600.62991.944718.921763@chiark.greenend.org.uk>
	<CAFLBxZbnsiuKzvSycXLz81H1XadQ9JoK8M7dr5QpYmQiDXW7eA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Matt Wilson <msw@linux.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Security policy ambiguities - XSA-108 process post-mortem"):
> On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson
> > Such a system would (a) be unworkable in practice, because no-one
> > really cares about this kind of tedious makework, and (b) at serious
> > risk of favouritism (or its opposite).
> 
> "It's opposite" meaning, "We all hate company X, so let's not let them
> join the list"?

Yes.

> > I don't want to criticise another community's process, but I strongly
> > feel that our arrangements should have broad eligibility based on
> > objective criteria.
> 
> Having black-and-white rules is nice and simple and safe; but in most
> reasonably "rich" domains, it's very difficult to come up with simple,
> objective criteria that cover all situations satisfactorily.  This is
> true in morality and law; my guess is that it's true here as well.
> 
> But I'd be willing to take a look at such a list; maybe I'm wrong
> about how objective we can make things. :-)

I think the spirit behind our previous criteria is objective.  The
problem we had was just that the rules didn't specify enough about the
*form of the predisclosure list application*.

That's why my proposed change doesn't actually touch the criteria part
of the policy.  It just formalises the application process.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:07:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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 1XntNJ-0000jA-3Y; Mon, 10 Nov 2014 18:07:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XntNH-0000j2-OF
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 18:07:35 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	9F/70-29352-7EEF0645; Mon, 10 Nov 2014 18:07:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415642853!11598471!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31178 invoked from network); 10 Nov 2014 18:07:34 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Nov 2014 18:07:34 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAI7OQx021623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 18:07:25 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAI7MQC013494
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 18:07:22 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAI7Lir025999; Mon, 10 Nov 2014 18:07:21 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 10:07:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2F675112249; Mon, 10 Nov 2014 13:07:20 -0500 (EST)
Date: Mon, 10 Nov 2014 13:07:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141110180720.GA15286@laptop.dumpdata.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460F908.4040208@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Nov 10, 2014 at 05:42:32PM +0000, David Vrabel wrote:
> On 10/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> > Hey,
> > =

> > With Xen 4.5 (today's staging), when I boot a guest and then do pci-att=
ach
> > the BARs values are corrupt.
> =

> Corrupt?
> =

> > [  152.572965] pci 0000:00:04.0: BAR 1: no space for [mem size 0x080000=
00 64bit  pref]
> =

> Looks like the default MMIO hole isn't large enough for this device.

The BARs are 32M, 64M, 128MB and the MMIO is 2GB.

It looks like the BAR value is corrupted as:

(dom0):
[ =A0=A022.834109] pci 0000:05:00.0: reg 0x14: [mem 0xd0000000-0xd7ffffff 6=
4bit pref]
                                                  ^ - here we have '0xd'
guest:
[ =A0152.518320] pci 0000:00:04.0: reg 0x14: [mem 0x00000000-0x07ffffff 64b=
it pref]


See that '0xd' gone in the guest?



> =

> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:07:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 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 1XntNJ-0000jA-3Y; Mon, 10 Nov 2014 18:07:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XntNH-0000j2-OF
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 18:07:35 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	9F/70-29352-7EEF0645; Mon, 10 Nov 2014 18:07:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415642853!11598471!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31178 invoked from network); 10 Nov 2014 18:07:34 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Nov 2014 18:07:34 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAI7OQx021623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 18:07:25 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAI7MQC013494
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 18:07:22 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAI7Lir025999; Mon, 10 Nov 2014 18:07:21 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 10:07:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2F675112249; Mon, 10 Nov 2014 13:07:20 -0500 (EST)
Date: Mon, 10 Nov 2014 13:07:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141110180720.GA15286@laptop.dumpdata.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460F908.4040208@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Nov 10, 2014 at 05:42:32PM +0000, David Vrabel wrote:
> On 10/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> > Hey,
> > =

> > With Xen 4.5 (today's staging), when I boot a guest and then do pci-att=
ach
> > the BARs values are corrupt.
> =

> Corrupt?
> =

> > [  152.572965] pci 0000:00:04.0: BAR 1: no space for [mem size 0x080000=
00 64bit  pref]
> =

> Looks like the default MMIO hole isn't large enough for this device.

The BARs are 32M, 64M, 128MB and the MMIO is 2GB.

It looks like the BAR value is corrupted as:

(dom0):
[ =A0=A022.834109] pci 0000:05:00.0: reg 0x14: [mem 0xd0000000-0xd7ffffff 6=
4bit pref]
                                                  ^ - here we have '0xd'
guest:
[ =A0152.518320] pci 0000:00:04.0: reg 0x14: [mem 0x00000000-0x07ffffff 64b=
it pref]


See that '0xd' gone in the guest?



> =

> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:24:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:24:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntdZ-00012g-Ic; Mon, 10 Nov 2014 18:24:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XntdY-00012R-50
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:24:24 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	FF/FB-02696-7D201645; Mon, 10 Nov 2014 18:24:23 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415643862!12544234!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15413 invoked from network); 10 Nov 2014 18:24:22 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-9.tower-27.messagelabs.com with SMTP;
	10 Nov 2014 18:24:22 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 8AAF766;
	Mon, 10 Nov 2014 12:24:17 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 45A615FAD7;
	Mon, 10 Nov 2014 12:24:15 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 112DA13F6EE;
	Mon, 10 Nov 2014 12:24:13 -0600 (CST)
Date: Mon, 10 Nov 2014 18:24:12 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110182411.GD25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-7-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-7-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 07/13] xen: add a dma_addr_t dev_addr
 argument to xen_dma_map_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 Mon, Nov 10, 2014 at 04:13:59PM +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: david.vrabel@citrix.com
> CC: konrad.wilk@oracle.com
> ---
>  arch/arm/include/asm/xen/page-coherent.h   |    4 ++--
>  arch/arm64/include/asm/xen/page-coherent.h |    4 ++--
>  arch/x86/include/asm/xen/page-coherent.h   |    4 ++--
>  drivers/xen/swiotlb-xen.c                  |    6 ++++--
>  4 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
> index d97b0b4..25d450c 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -29,8 +29,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
>  }
>  
>  static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> -	     unsigned long offset, size_t size, enum dma_data_direction dir,
> -	     struct dma_attrs *attrs)
> +	     dma_addr_t dev_addr, unsigned long offset, size_t size,
> +	     enum dma_data_direction dir, struct dma_attrs *attrs)

It works for me as well. But it would be good to add a comment for this
patch to explain why a new argument is needed (like dev_addr being the
actual machine address and not dom0 physical address).

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:24:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:24:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntdZ-00012g-Ic; Mon, 10 Nov 2014 18:24:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XntdY-00012R-50
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:24:24 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	FF/FB-02696-7D201645; Mon, 10 Nov 2014 18:24:23 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415643862!12544234!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15413 invoked from network); 10 Nov 2014 18:24:22 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-9.tower-27.messagelabs.com with SMTP;
	10 Nov 2014 18:24:22 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 8AAF766;
	Mon, 10 Nov 2014 12:24:17 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 45A615FAD7;
	Mon, 10 Nov 2014 12:24:15 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 112DA13F6EE;
	Mon, 10 Nov 2014 12:24:13 -0600 (CST)
Date: Mon, 10 Nov 2014 18:24:12 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110182411.GD25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-7-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-7-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 07/13] xen: add a dma_addr_t dev_addr
 argument to xen_dma_map_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 Mon, Nov 10, 2014 at 04:13:59PM +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: david.vrabel@citrix.com
> CC: konrad.wilk@oracle.com
> ---
>  arch/arm/include/asm/xen/page-coherent.h   |    4 ++--
>  arch/arm64/include/asm/xen/page-coherent.h |    4 ++--
>  arch/x86/include/asm/xen/page-coherent.h   |    4 ++--
>  drivers/xen/swiotlb-xen.c                  |    6 ++++--
>  4 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
> index d97b0b4..25d450c 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -29,8 +29,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
>  }
>  
>  static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> -	     unsigned long offset, size_t size, enum dma_data_direction dir,
> -	     struct dma_attrs *attrs)
> +	     dma_addr_t dev_addr, unsigned long offset, size_t size,
> +	     enum dma_data_direction dir, struct dma_attrs *attrs)

It works for me as well. But it would be good to add a comment for this
patch to explain why a new argument is needed (like dev_addr being the
actual machine address and not dom0 physical address).

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:27:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18: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 1XntgI-0001If-Bb; Mon, 10 Nov 2014 18:27:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XntgH-0001IX-5s
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:27:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C8/E3-24532-08301645; Mon, 10 Nov 2014 18:27:12 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415644029!12809169!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18075 invoked from network); 10 Nov 2014 18:27:10 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-8.tower-21.messagelabs.com with SMTP;
	10 Nov 2014 18:27:10 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id A57A066;
	Mon, 10 Nov 2014 12:27:05 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 5F3C35FAD7;
	Mon, 10 Nov 2014 12:27:03 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 23A9713F6EE;
	Mon, 10 Nov 2014 12:27:02 -0600 (CST)
Date: Mon, 10 Nov 2014 18:27:00 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110182659.GE25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-8-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-8-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 08/13] xen/arm: use hypercall to flush
 caches in map_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 Mon, Nov 10, 2014 at 04:14:00PM +0000, Stefano Stabellini wrote:
> In xen_dma_map_page, if the page is a local page, call the native
> map_page dma_ops. If the page is foreign, call __xen_dma_map_page that
> issues any required cache maintenane operations via hypercall.
> 
> The reason for doing this is that the native dma_ops map_page could
> allocate buffers than need to be freed. If the page is foreign we don't
> call the native unmap_page dma_ops function, resulting in a memory leak.
> 
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/arm/include/asm/xen/page-coherent.h |    9 ++++++++-
>  arch/arm/xen/mm32.c                      |   12 ++++++++++++
>  2 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
> index 25d450c..36b79a8 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -5,6 +5,9 @@
>  #include <linux/dma-attrs.h>
>  #include <linux/dma-mapping.h>
>  
> +void __xen_dma_map_page(struct device *hwdev, struct page *page,
> +	     dma_addr_t dev_addr, unsigned long offset, size_t size,
> +	     enum dma_data_direction dir, struct dma_attrs *attrs);
>  void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
>  		size_t size, enum dma_data_direction dir,
>  		struct dma_attrs *attrs);
> @@ -32,7 +35,11 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
>  	     dma_addr_t dev_addr, unsigned long offset, size_t size,
>  	     enum dma_data_direction dir, struct dma_attrs *attrs)
>  {
> -	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
> +	if (PFN_DOWN(dev_addr) == page_to_pfn(page)) {

Nitpick: you could write:

	bool foreign = PFN_DOWN(dev_addr) == page_to_pfn(page);

or even a static inline xen_foreign_page(page, dev_addr) function for
clarity. This code lacks comments.

> +		if (__generic_dma_ops(hwdev)->map_page)

I'm not sure we need to check map_page() here. I thought it's always
present as host DMA API does not check for it.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:27:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18: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 1XntgI-0001If-Bb; Mon, 10 Nov 2014 18:27:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XntgH-0001IX-5s
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:27:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C8/E3-24532-08301645; Mon, 10 Nov 2014 18:27:12 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415644029!12809169!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18075 invoked from network); 10 Nov 2014 18:27:10 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-8.tower-21.messagelabs.com with SMTP;
	10 Nov 2014 18:27:10 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id A57A066;
	Mon, 10 Nov 2014 12:27:05 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 5F3C35FAD7;
	Mon, 10 Nov 2014 12:27:03 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 23A9713F6EE;
	Mon, 10 Nov 2014 12:27:02 -0600 (CST)
Date: Mon, 10 Nov 2014 18:27:00 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110182659.GE25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-8-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-8-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 08/13] xen/arm: use hypercall to flush
 caches in map_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 Mon, Nov 10, 2014 at 04:14:00PM +0000, Stefano Stabellini wrote:
> In xen_dma_map_page, if the page is a local page, call the native
> map_page dma_ops. If the page is foreign, call __xen_dma_map_page that
> issues any required cache maintenane operations via hypercall.
> 
> The reason for doing this is that the native dma_ops map_page could
> allocate buffers than need to be freed. If the page is foreign we don't
> call the native unmap_page dma_ops function, resulting in a memory leak.
> 
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/arm/include/asm/xen/page-coherent.h |    9 ++++++++-
>  arch/arm/xen/mm32.c                      |   12 ++++++++++++
>  2 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
> index 25d450c..36b79a8 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -5,6 +5,9 @@
>  #include <linux/dma-attrs.h>
>  #include <linux/dma-mapping.h>
>  
> +void __xen_dma_map_page(struct device *hwdev, struct page *page,
> +	     dma_addr_t dev_addr, unsigned long offset, size_t size,
> +	     enum dma_data_direction dir, struct dma_attrs *attrs);
>  void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
>  		size_t size, enum dma_data_direction dir,
>  		struct dma_attrs *attrs);
> @@ -32,7 +35,11 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
>  	     dma_addr_t dev_addr, unsigned long offset, size_t size,
>  	     enum dma_data_direction dir, struct dma_attrs *attrs)
>  {
> -	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
> +	if (PFN_DOWN(dev_addr) == page_to_pfn(page)) {

Nitpick: you could write:

	bool foreign = PFN_DOWN(dev_addr) == page_to_pfn(page);

or even a static inline xen_foreign_page(page, dev_addr) function for
clarity. This code lacks comments.

> +		if (__generic_dma_ops(hwdev)->map_page)

I'm not sure we need to check map_page() here. I thought it's always
present as host DMA API does not check for it.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:32:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntlN-0001fe-64; Mon, 10 Nov 2014 18:32:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XntlM-0001fU-5N
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:32:28 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	5B/39-18267-BB401645; Mon, 10 Nov 2014 18:32:27 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415644346!11614187!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12932 invoked from network); 10 Nov 2014 18:32:26 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-10.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 18:32:26 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 787EC66;
	Mon, 10 Nov 2014 12:32:22 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 11E625FAD7;
	Mon, 10 Nov 2014 12:32:15 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id C690813F6EE;
	Mon, 10 Nov 2014 12:32:13 -0600 (CST)
Date: Mon, 10 Nov 2014 18:32:11 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110183211.GF25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-9-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-9-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 09/13] xen/arm/arm64: merge xen/mm32.c
	into xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 04:14:01PM +0000, Stefano Stabellini wrote:
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -1,6 +1,10 @@
> +#include <linux/cpu.h>
> +#include <linux/dma-mapping.h>
>  #include <linux/bootmem.h>
>  #include <linux/gfp.h>
> +#include <linux/highmem.h>
>  #include <linux/export.h>
> +#include <linux/of_address.h>
>  #include <linux/slab.h>
>  #include <linux/types.h>
>  #include <linux/dma-mapping.h>
> @@ -16,6 +20,88 @@
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/interface.h>
>  
> +enum dma_cache_op {
> +       DMA_UNMAP,
> +       DMA_MAP,
> +};
> +
> +/* functions called by SWIOTLB */
> +
> +static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
> +	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
> +{
> +	unsigned long pfn;
> +	size_t left = size;
> +
> +	pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
> +	offset %= PAGE_SIZE;
> +
> +	do {
> +		size_t len = left;
> +	
> +		BUG_ON(pfn_valid(pfn));

You probably don't need this in the loop.

> +
> +		/* TODO: cache flush */
> +
> +		offset = 0;
> +		pfn++;
> +		left -= len;
> +	} while (left);
> +}

That's smaller now ;). I have to finish reading the other patches to see
what ends up replacing TODO.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:32:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntlN-0001fe-64; Mon, 10 Nov 2014 18:32:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XntlM-0001fU-5N
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:32:28 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	5B/39-18267-BB401645; Mon, 10 Nov 2014 18:32:27 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415644346!11614187!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12932 invoked from network); 10 Nov 2014 18:32:26 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-10.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 18:32:26 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 787EC66;
	Mon, 10 Nov 2014 12:32:22 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 11E625FAD7;
	Mon, 10 Nov 2014 12:32:15 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id C690813F6EE;
	Mon, 10 Nov 2014 12:32:13 -0600 (CST)
Date: Mon, 10 Nov 2014 18:32:11 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110183211.GF25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-9-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-9-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 09/13] xen/arm/arm64: merge xen/mm32.c
	into xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 04:14:01PM +0000, Stefano Stabellini wrote:
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -1,6 +1,10 @@
> +#include <linux/cpu.h>
> +#include <linux/dma-mapping.h>
>  #include <linux/bootmem.h>
>  #include <linux/gfp.h>
> +#include <linux/highmem.h>
>  #include <linux/export.h>
> +#include <linux/of_address.h>
>  #include <linux/slab.h>
>  #include <linux/types.h>
>  #include <linux/dma-mapping.h>
> @@ -16,6 +20,88 @@
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/interface.h>
>  
> +enum dma_cache_op {
> +       DMA_UNMAP,
> +       DMA_MAP,
> +};
> +
> +/* functions called by SWIOTLB */
> +
> +static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
> +	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
> +{
> +	unsigned long pfn;
> +	size_t left = size;
> +
> +	pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
> +	offset %= PAGE_SIZE;
> +
> +	do {
> +		size_t len = left;
> +	
> +		BUG_ON(pfn_valid(pfn));

You probably don't need this in the loop.

> +
> +		/* TODO: cache flush */
> +
> +		offset = 0;
> +		pfn++;
> +		left -= len;
> +	} while (left);
> +}

That's smaller now ;). I have to finish reading the other patches to see
what ends up replacing TODO.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:35:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:35:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xntnw-0001nk-Pk; Mon, 10 Nov 2014 18:35:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xntnv-0001na-Qk
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:35:07 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	71/03-19763-B5501645; Mon, 10 Nov 2014 18:35:07 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415644505!11586738!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18530 invoked from network); 10 Nov 2014 18:35:06 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-8.tower-206.messagelabs.com with SMTP;
	10 Nov 2014 18:35:06 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 09A9866;
	Mon, 10 Nov 2014 12:35:01 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id B51D85FAD7;
	Mon, 10 Nov 2014 12:34:57 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 75B9613F6EE;
	Mon, 10 Nov 2014 12:34:56 -0600 (CST)
Date: Mon, 10 Nov 2014 18:34:54 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110183453.GG25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-10-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-10-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 10/13] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 04:14:02PM +0000, Stefano Stabellini wrote:
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn);
> +
>  #endif /* _ASM_ARM_XEN_PAGE_H */
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index 0e96023..1b087cd 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -102,6 +102,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
>  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
>  }
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn)
> +{
> +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> +}

Why not a static inline? It doesn't look like a big function.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:35:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:35:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xntnw-0001nk-Pk; Mon, 10 Nov 2014 18:35:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xntnv-0001na-Qk
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:35:07 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	71/03-19763-B5501645; Mon, 10 Nov 2014 18:35:07 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415644505!11586738!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18530 invoked from network); 10 Nov 2014 18:35:06 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-8.tower-206.messagelabs.com with SMTP;
	10 Nov 2014 18:35:06 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 09A9866;
	Mon, 10 Nov 2014 12:35:01 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id B51D85FAD7;
	Mon, 10 Nov 2014 12:34:57 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 75B9613F6EE;
	Mon, 10 Nov 2014 12:34:56 -0600 (CST)
Date: Mon, 10 Nov 2014 18:34:54 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110183453.GG25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-10-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-10-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 10/13] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 04:14:02PM +0000, Stefano Stabellini wrote:
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn);
> +
>  #endif /* _ASM_ARM_XEN_PAGE_H */
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index 0e96023..1b087cd 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -102,6 +102,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
>  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
>  }
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn)
> +{
> +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> +}

Why not a static inline? It doesn't look like a big function.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:35:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18: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 1Xnto6-0001p4-5k; Mon, 10 Nov 2014 18:35:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xnto4-0001oj-Er
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 18:35:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	46/2E-09842-36501645; Mon, 10 Nov 2014 18:35:15 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415644513!5503959!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15166 invoked from network); 10 Nov 2014 18:35:13 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 18:35:13 -0000
Received: by mail-wg0-f49.google.com with SMTP id x13so9650657wgg.36
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 10:35:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=5gRh360phC30bQFsIvRtu+l2uGZOJ2mknGZ68vt7vSs=;
	b=YZL468FbHYBHlXDTpnLBPz/+HvukxBU9tt7zbKq4Xp6f8JHmqyxpA3yo52sPs3ARfz
	CuzXVmeC7+Dt44/etYa++hwWHMHZpu0aPYPO9HsuDMhs2lhYfJbth/BfmfNZ76OrnsHq
	DELeK29pKd9EC5XaZUEq5untCQPU+e/dsGZElQ2C0/7wqxMuqvq8Cm0C1BjuVEPwhHMI
	fJcBmegu2KTvAkJch+FLotfp9h4fYdCpDOu+mPYzKJZ29NPf7RNOpx303QZaDV7nMoVZ
	vCE8P6hntQxFPJQbjbReRFWKL04CZWex1MaDPWGCA0tKz7dUYh/20+59NZ7+0rs3OwXf
	WqVA==
MIME-Version: 1.0
X-Received: by 10.180.12.136 with SMTP id y8mr32814378wib.73.1415641184069;
	Mon, 10 Nov 2014 09:39:44 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 10 Nov 2014 09:39:43 -0800 (PST)
In-Reply-To: <21600.62991.944718.921763@chiark.greenend.org.uk>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
	<21600.62991.944718.921763@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:39:43 +0000
X-Google-Sender-Auth: oullZL6WCtRxid88rEBYiFGe6AI
Message-ID: <CAFLBxZbnsiuKzvSycXLz81H1XadQ9JoK8M7dr5QpYmQiDXW7eA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Matt Wilson <msw@linux.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
>> On this point in particular, back in 2012 [1] I suggested that all
>> membership requests should be discussed in public on a community email
>> list like xen-devel, or another email list to avoid noise. The Xen
>> Project Security Team shouldn't have to evaluate petitions for
>> membership while managing an embargoed issue. I brought this up again
>> in 2013 [2] regarding the Coverity process.
>
> I agree that publishing applications, and the team's responses, would
> be a jolly good idea.  I am 100% opposed, though, to any kind of
> non-objective `community consensus' process.
>
> Such a system would (a) be unworkable in practice, because no-one
> really cares about this kind of tedious makework, and (b) at serious
> risk of favouritism (or its opposite).

"It's opposite" meaning, "We all hate company X, so let's not let them
join the list"?

>> This process works quite well for the distros email list, where
>> requests for membership requests are discussion on oss-security (a
>> public list). [...]
>
> I don't want to criticise another community's process, but I strongly
> feel that our arrangements should have broad eligibility based on
> objective criteria.

Having black-and-white rules is nice and simple and safe; but in most
reasonably "rich" domains, it's very difficult to come up with simple,
objective criteria that cover all situations satisfactorily.  This is
true in morality and law; my guess is that it's true here as well.

But I'd be willing to take a look at such a list; maybe I'm wrong
about how objective we can make things. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:35:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18: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 1Xnto6-0001p4-5k; Mon, 10 Nov 2014 18:35:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xnto4-0001oj-Er
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 18:35:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	46/2E-09842-36501645; Mon, 10 Nov 2014 18:35:15 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415644513!5503959!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15166 invoked from network); 10 Nov 2014 18:35:13 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 18:35:13 -0000
Received: by mail-wg0-f49.google.com with SMTP id x13so9650657wgg.36
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 10:35:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=5gRh360phC30bQFsIvRtu+l2uGZOJ2mknGZ68vt7vSs=;
	b=YZL468FbHYBHlXDTpnLBPz/+HvukxBU9tt7zbKq4Xp6f8JHmqyxpA3yo52sPs3ARfz
	CuzXVmeC7+Dt44/etYa++hwWHMHZpu0aPYPO9HsuDMhs2lhYfJbth/BfmfNZ76OrnsHq
	DELeK29pKd9EC5XaZUEq5untCQPU+e/dsGZElQ2C0/7wqxMuqvq8Cm0C1BjuVEPwhHMI
	fJcBmegu2KTvAkJch+FLotfp9h4fYdCpDOu+mPYzKJZ29NPf7RNOpx303QZaDV7nMoVZ
	vCE8P6hntQxFPJQbjbReRFWKL04CZWex1MaDPWGCA0tKz7dUYh/20+59NZ7+0rs3OwXf
	WqVA==
MIME-Version: 1.0
X-Received: by 10.180.12.136 with SMTP id y8mr32814378wib.73.1415641184069;
	Mon, 10 Nov 2014 09:39:44 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 10 Nov 2014 09:39:43 -0800 (PST)
In-Reply-To: <21600.62991.944718.921763@chiark.greenend.org.uk>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<1413894766.23337.34.camel@citrix.com>
	<20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
	<21600.62991.944718.921763@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 17:39:43 +0000
X-Google-Sender-Auth: oullZL6WCtRxid88rEBYiFGe6AI
Message-ID: <CAFLBxZbnsiuKzvSycXLz81H1XadQ9JoK8M7dr5QpYmQiDXW7eA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Matt Wilson <msw@linux.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
>> On this point in particular, back in 2012 [1] I suggested that all
>> membership requests should be discussed in public on a community email
>> list like xen-devel, or another email list to avoid noise. The Xen
>> Project Security Team shouldn't have to evaluate petitions for
>> membership while managing an embargoed issue. I brought this up again
>> in 2013 [2] regarding the Coverity process.
>
> I agree that publishing applications, and the team's responses, would
> be a jolly good idea.  I am 100% opposed, though, to any kind of
> non-objective `community consensus' process.
>
> Such a system would (a) be unworkable in practice, because no-one
> really cares about this kind of tedious makework, and (b) at serious
> risk of favouritism (or its opposite).

"It's opposite" meaning, "We all hate company X, so let's not let them
join the list"?

>> This process works quite well for the distros email list, where
>> requests for membership requests are discussion on oss-security (a
>> public list). [...]
>
> I don't want to criticise another community's process, but I strongly
> feel that our arrangements should have broad eligibility based on
> objective criteria.

Having black-and-white rules is nice and simple and safe; but in most
reasonably "rich" domains, it's very difficult to come up with simple,
objective criteria that cover all situations satisfactorily.  This is
true in morality and law; my guess is that it's true here as well.

But I'd be willing to take a look at such a list; maybe I'm wrong
about how objective we can make things. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:41:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:41:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnttz-00028n-7T; Mon, 10 Nov 2014 18:41:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xntty-00028i-KS
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:41:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	74/38-09936-2D601645; Mon, 10 Nov 2014 18:41:22 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415644881!12833279!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5414 invoked from network); 10 Nov 2014 18:41:21 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-9.tower-21.messagelabs.com with SMTP;
	10 Nov 2014 18:41:21 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 6288966;
	Mon, 10 Nov 2014 12:41:17 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 4D9FD5FAD7;
	Mon, 10 Nov 2014 12:41:15 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 11DDF13F6EE;
	Mon, 10 Nov 2014 12:41:13 -0600 (CST)
Date: Mon, 10 Nov 2014 18:41:11 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110184111.GH25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-3-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-3-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 03/13] xen/arm: if(pfn_valid(pfn)) call
	native dma_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 04:13:55PM +0000, Stefano Stabellini wrote:
>  void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
>  		size_t size, enum dma_data_direction dir,
> -		struct dma_attrs *attrs);
> +		struct dma_attrs *attrs)
> +{
> +	unsigned long pfn = PFN_DOWN(handle);
> +	/* Dom0 is mapped 1:1, so calling pfn_valid on a foreign mfn will
> +	 * always return false. If the page is local we can safely call the
> +	 * native dma_ops function, otherwise we call the xen specific
> +	 * function. */
> +	if (pfn_valid(pfn)) {
> +		if (__generic_dma_ops(hwdev)->unmap_page)
> +			__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);

Similarly here, do we need the unmap_page check? dma_map_page() does not
do it.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:41:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:41:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnttz-00028n-7T; Mon, 10 Nov 2014 18:41:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Xntty-00028i-KS
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:41:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	74/38-09936-2D601645; Mon, 10 Nov 2014 18:41:22 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415644881!12833279!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5414 invoked from network); 10 Nov 2014 18:41:21 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-9.tower-21.messagelabs.com with SMTP;
	10 Nov 2014 18:41:21 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 6288966;
	Mon, 10 Nov 2014 12:41:17 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 4D9FD5FAD7;
	Mon, 10 Nov 2014 12:41:15 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 11DDF13F6EE;
	Mon, 10 Nov 2014 12:41:13 -0600 (CST)
Date: Mon, 10 Nov 2014 18:41:11 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110184111.GH25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-3-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-3-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 03/13] xen/arm: if(pfn_valid(pfn)) call
	native dma_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 04:13:55PM +0000, Stefano Stabellini wrote:
>  void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
>  		size_t size, enum dma_data_direction dir,
> -		struct dma_attrs *attrs);
> +		struct dma_attrs *attrs)
> +{
> +	unsigned long pfn = PFN_DOWN(handle);
> +	/* Dom0 is mapped 1:1, so calling pfn_valid on a foreign mfn will
> +	 * always return false. If the page is local we can safely call the
> +	 * native dma_ops function, otherwise we call the xen specific
> +	 * function. */
> +	if (pfn_valid(pfn)) {
> +		if (__generic_dma_ops(hwdev)->unmap_page)
> +			__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);

Similarly here, do we need the unmap_page check? dma_map_page() does not
do it.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:42:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18: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 1XntvJ-0002JS-ND; Mon, 10 Nov 2014 18:42:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XntvI-0002JJ-Dl
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:42:44 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	E9/D6-16982-32701645; Mon, 10 Nov 2014 18:42:43 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415644962!11686515!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20415 invoked from network); 10 Nov 2014 18:42:42 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-3.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 18:42:42 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 8922866;
	Mon, 10 Nov 2014 12:42:33 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 13CC15FAD7;
	Mon, 10 Nov 2014 12:42:31 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id B90AB13F6EE;
	Mon, 10 Nov 2014 12:42:29 -0600 (CST)
Date: Mon, 10 Nov 2014 18:42:27 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110184226.GI25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-4-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-4-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 04/13] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 04:13:56PM +0000, Stefano Stabellini wrote:
> Introduce a boolean flag and an accessor function to check whether a
> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

BTW, why do I sign off this patch? As long as it's you as author, I
don't think you should add my sign-off.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:42:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18: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 1XntvJ-0002JS-ND; Mon, 10 Nov 2014 18:42:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XntvI-0002JJ-Dl
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:42:44 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	E9/D6-16982-32701645; Mon, 10 Nov 2014 18:42:43 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415644962!11686515!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20415 invoked from network); 10 Nov 2014 18:42:42 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-3.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 18:42:42 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 8922866;
	Mon, 10 Nov 2014 12:42:33 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 13CC15FAD7;
	Mon, 10 Nov 2014 12:42:31 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id B90AB13F6EE;
	Mon, 10 Nov 2014 12:42:29 -0600 (CST)
Date: Mon, 10 Nov 2014 18:42:27 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110184226.GI25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-4-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415636045-24669-4-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 04/13] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 04:13:56PM +0000, Stefano Stabellini wrote:
> Introduce a boolean flag and an accessor function to check whether a
> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

BTW, why do I sign off this patch? As long as it's you as author, I
don't think you should add my sign-off.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:45:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:45:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntxT-0002SM-9P; Mon, 10 Nov 2014 18:44:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XntxR-0002SG-P1
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:44:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	0C/58-07724-9A701645; Mon, 10 Nov 2014 18:44:57 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415645096!11660836!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7142 invoked from network); 10 Nov 2014 18:44:56 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-8.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 18:44:56 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 3ED2C66;
	Mon, 10 Nov 2014 12:44:52 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 264D05FAD7;
	Mon, 10 Nov 2014 12:44:50 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id E11B913F6EE;
	Mon, 10 Nov 2014 12:44:48 -0600 (CST)
Date: Mon, 10 Nov 2014 18:44:46 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110184446.GJ25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 0/13] introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 04:12:40PM +0000, Stefano Stabellini wrote:
> this patch series introduces support for GNTTABOP_cache_flush to perform
> cache maintenance operation on foreign pages and reverts the current
> code based on XENFEAT_grant_map_identity.
> 
> It also provides a very slow fallback by bouncing on the swiotlb buffer,
> in case the hypercall is not available.
> 
> v7 introduces a flag named dma_coherent in dev_archdata and an accessor
> function named is_device_dma_coherent in asm/dma-mapping.h under arm and
> arm64.

Apart from a few minor comments I gave already, the series looks fine to
me. Once addressed, you can add:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 18:45:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 18:45:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XntxT-0002SM-9P; Mon, 10 Nov 2014 18:44:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1XntxR-0002SG-P1
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 18:44:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	0C/58-07724-9A701645; Mon, 10 Nov 2014 18:44:57 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415645096!11660836!1
X-Originating-IP: [217.140.108.86]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7142 invoked from network); 10 Nov 2014 18:44:56 -0000
Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com)
	(217.140.108.86) by server-8.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 18:44:56 -0000
Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8])
	by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 3ED2C66;
	Mon, 10 Nov 2014 12:44:52 -0600 (CST)
Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com
	[10.112.81.134])
	by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 264D05FAD7;
	Mon, 10 Nov 2014 12:44:50 -0600 (CST)
Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com
	[10.1.203.148])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id E11B913F6EE;
	Mon, 10 Nov 2014 12:44:48 -0600 (CST)
Date: Mon, 10 Nov 2014 18:44:46 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141110184446.GJ25609@e104818-lin.cambridge.arm.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 0/13] introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 04:12:40PM +0000, Stefano Stabellini wrote:
> this patch series introduces support for GNTTABOP_cache_flush to perform
> cache maintenance operation on foreign pages and reverts the current
> code based on XENFEAT_grant_map_identity.
> 
> It also provides a very slow fallback by bouncing on the swiotlb buffer,
> in case the hypercall is not available.
> 
> v7 introduces a flag named dma_coherent in dev_archdata and an accessor
> function named is_device_dma_coherent in asm/dma-mapping.h under arm and
> arm64.

Apart from a few minor comments I gave already, the series looks fine to
me. Once addressed, you can add:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 19:21:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 19:21:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnuWY-0003JQ-FZ; Mon, 10 Nov 2014 19:21:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnuWX-0003JL-RX
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 19:21:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	21/65-09936-92011645; Mon, 10 Nov 2014 19:21:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415647270!12785282!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13137 invoked from network); 10 Nov 2014 19:21:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 19:21:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,354,1413244800"; d="scan'208";a="191310687"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 14:21:06 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnuWQ-0007qu-F2;
	Mon, 10 Nov 2014 19:21:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnuWQ-0006hL-8n;
	Mon, 10 Nov 2014 19:21:06 +0000
Date: Mon, 10 Nov 2014 19:21:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31468-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 10869
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31468: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3866187194285919356=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3866187194285919356==
Content-Type: text/plain
Content-Length: 10619
Content-Transfer-Encoding: quoted-printable

flight 31468 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31468/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                6e76d125f244e10676b917208f2a074729820246
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 10923 lines long.)


--===============3866187194285919356==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3866187194285919356==--

From xen-devel-bounces@lists.xen.org Mon Nov 10 19:21:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 19:21:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnuWY-0003JQ-FZ; Mon, 10 Nov 2014 19:21:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnuWX-0003JL-RX
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 19:21:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	21/65-09936-92011645; Mon, 10 Nov 2014 19:21:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415647270!12785282!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13137 invoked from network); 10 Nov 2014 19:21:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 19:21:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,354,1413244800"; d="scan'208";a="191310687"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 14:21:06 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnuWQ-0007qu-F2;
	Mon, 10 Nov 2014 19:21:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnuWQ-0006hL-8n;
	Mon, 10 Nov 2014 19:21:06 +0000
Date: Mon, 10 Nov 2014 19:21:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31468-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 10869
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31468: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3866187194285919356=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3866187194285919356==
Content-Type: text/plain
Content-Length: 10619
Content-Transfer-Encoding: quoted-printable

flight 31468 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31468/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                6e76d125f244e10676b917208f2a074729820246
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 10923 lines long.)


--===============3866187194285919356==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3866187194285919356==--

From xen-devel-bounces@lists.xen.org Mon Nov 10 19:49:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 19:49:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnuxp-0003lD-IP; Mon, 10 Nov 2014 19:49:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1Xnuxo-0003l8-6M
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 19:49:24 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	1C/C2-03148-3C611645; Mon, 10 Nov 2014 19:49:23 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415648962!7161748!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12462 invoked from network); 10 Nov 2014 19:49:22 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 19:49:22 -0000
Received: by mail-wi0-f175.google.com with SMTP id ex7so11678081wid.8
	for <multiple recipients>; Mon, 10 Nov 2014 11:49:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:subject:date:message-id:cc:to:mime-version;
	bh=JyG3H5+SLv2iYgplLthWRhbsm2ma2hfUvcdeLIREgS0=;
	b=MPEDBHGg+d/fzBJabMlN8bIYQfkYefijcNG5GrPHVoZNXbYnMDNvZH7uUybd7VWTQY
	XFVl9b83Ms5wHaPqcf9AW5Gxi4Mmku67rQ8JRgGsmRhy70UseYDGiW86vhK6WtnbdnFz
	Ex4Pl6CD5V/WQnkbkAx1XghspawothDAhMQWp27T60/hvX/m5kWgJD90ylCoK2aR7jhQ
	3uXTIv/I7/6GXs4aWYX9efMMtsj4bfZcSnGu/13gpklPMEOOeq4IGayLuc7bJnuw6Jy0
	4p/HHzQhRsVRKoO0sARuWCR5EiRJJKm76fGunQO5F0JPlDMFEbnwVf6/1bPDU1DXZAE/
	vkGQ==
X-Received: by 10.194.192.2 with SMTP id hc2mr30376003wjc.75.1415648960719;
	Mon, 10 Nov 2014 11:49:20 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id mu4sm14632764wib.2.2014.11.10.11.49.18
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 10 Nov 2014 11:49:19 -0800 (PST)
From: Lars Kurth <lars.kurth.xen@gmail.com>
Date: Mon, 10 Nov 2014 19:49:14 +0000
Message-Id: <E80C1438-6266-4297-932D-FF09899D39AE@gmail.com>
To: publicty@lists.xenproject.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: [Xen-devel] CfP for LF Collab Summit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1069170707993866265=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1069170707993866265==
Content-Type: multipart/alternative; boundary="Apple-Mail=_F49FEA8B-E166-4357-AFE0-1C016E79A978"


--Apple-Mail=_F49FEA8B-E166-4357-AFE0-1C016E79A978
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

See =
http://events.linuxfoundation.org/events/collaboration-summit/program/cfp

As an aside:
* I arranged for 1/2 day public Xen track=20
* And a 1/2 day of space for private meetings for members of the Xen =
community planning to come to Collab Summit

Regards
Lars=

--Apple-Mail=_F49FEA8B-E166-4357-AFE0-1C016E79A978
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">See&nbsp;<a href="http://events.linuxfoundation.org/events/collaboration-summit/program/cfp">http://events.linuxfoundation.org/events/collaboration-summit/program/cfp</a><div><br></div><div>As an aside:</div><div>* I arranged for 1/2 day public Xen track&nbsp;</div><div>* And a 1/2 day of space for private meetings for members of the Xen community planning to come to Collab Summit</div><div><br></div><div>Regards</div><div>Lars</div></body></html>
--Apple-Mail=_F49FEA8B-E166-4357-AFE0-1C016E79A978--


--===============1069170707993866265==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1069170707993866265==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 19:49:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 19:49:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnuxp-0003lD-IP; Mon, 10 Nov 2014 19:49:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1Xnuxo-0003l8-6M
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 19:49:24 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	1C/C2-03148-3C611645; Mon, 10 Nov 2014 19:49:23 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415648962!7161748!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12462 invoked from network); 10 Nov 2014 19:49:22 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 19:49:22 -0000
Received: by mail-wi0-f175.google.com with SMTP id ex7so11678081wid.8
	for <multiple recipients>; Mon, 10 Nov 2014 11:49:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:subject:date:message-id:cc:to:mime-version;
	bh=JyG3H5+SLv2iYgplLthWRhbsm2ma2hfUvcdeLIREgS0=;
	b=MPEDBHGg+d/fzBJabMlN8bIYQfkYefijcNG5GrPHVoZNXbYnMDNvZH7uUybd7VWTQY
	XFVl9b83Ms5wHaPqcf9AW5Gxi4Mmku67rQ8JRgGsmRhy70UseYDGiW86vhK6WtnbdnFz
	Ex4Pl6CD5V/WQnkbkAx1XghspawothDAhMQWp27T60/hvX/m5kWgJD90ylCoK2aR7jhQ
	3uXTIv/I7/6GXs4aWYX9efMMtsj4bfZcSnGu/13gpklPMEOOeq4IGayLuc7bJnuw6Jy0
	4p/HHzQhRsVRKoO0sARuWCR5EiRJJKm76fGunQO5F0JPlDMFEbnwVf6/1bPDU1DXZAE/
	vkGQ==
X-Received: by 10.194.192.2 with SMTP id hc2mr30376003wjc.75.1415648960719;
	Mon, 10 Nov 2014 11:49:20 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id mu4sm14632764wib.2.2014.11.10.11.49.18
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 10 Nov 2014 11:49:19 -0800 (PST)
From: Lars Kurth <lars.kurth.xen@gmail.com>
Date: Mon, 10 Nov 2014 19:49:14 +0000
Message-Id: <E80C1438-6266-4297-932D-FF09899D39AE@gmail.com>
To: publicty@lists.xenproject.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: [Xen-devel] CfP for LF Collab Summit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1069170707993866265=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1069170707993866265==
Content-Type: multipart/alternative; boundary="Apple-Mail=_F49FEA8B-E166-4357-AFE0-1C016E79A978"


--Apple-Mail=_F49FEA8B-E166-4357-AFE0-1C016E79A978
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

See =
http://events.linuxfoundation.org/events/collaboration-summit/program/cfp

As an aside:
* I arranged for 1/2 day public Xen track=20
* And a 1/2 day of space for private meetings for members of the Xen =
community planning to come to Collab Summit

Regards
Lars=

--Apple-Mail=_F49FEA8B-E166-4357-AFE0-1C016E79A978
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">See&nbsp;<a href="http://events.linuxfoundation.org/events/collaboration-summit/program/cfp">http://events.linuxfoundation.org/events/collaboration-summit/program/cfp</a><div><br></div><div>As an aside:</div><div>* I arranged for 1/2 day public Xen track&nbsp;</div><div>* And a 1/2 day of space for private meetings for members of the Xen community planning to come to Collab Summit</div><div><br></div><div>Regards</div><div>Lars</div></body></html>
--Apple-Mail=_F49FEA8B-E166-4357-AFE0-1C016E79A978--


--===============1069170707993866265==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1069170707993866265==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 20:05:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 20: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 1XnvD2-00049p-CL; Mon, 10 Nov 2014 20:05:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XnvD0-00049h-Sp
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 20:05:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/E7-24532-27A11645; Mon, 10 Nov 2014 20:05:06 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415649904!4786518!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26517 invoked from network); 10 Nov 2014 20:05:05 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 20:05:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415649903; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=X+A6ItQDV8zVbQpflvOcMZV3C0f+QJo0feKBhflyHao=;
	b=2UGBFtiCmMKYgZxrG/yRzDT7GzqXgH7uSwPFqDXKl3fMzd2BZ+yGBG8YI7B0K2cyD0qa3mw2Oj02zS9fkYWA0VzQ3INL/smeYMSOO57I0Kp3WgIlN4Bz6xAlY/ZbHkEEOMUUx+VC0SAk3qXrv+oO4HunkZ0p+yJixcdkWVLSIz0=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 10 Nov 2014 12:05:02 -0800
	id 00000000000305E9.54611A6E.0000441B
Message-ID: <54611A86.4000200@ihonk.com>
Date: Mon, 10 Nov 2014 12:05:26 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, pasik@iki.fi
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
In-Reply-To: <54608A8B0200007800045E58@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 0:51, Jan Beulich wrote:
>>>> On 10.11.14 at 09:03, <sflist@ihonk.com> wrote:
>> Sorry for the delay, took some debugging on another computer to get
>> serial logging working. Due to its size, I've posted the entire log of a
>> crashed session here: http://pastebin.com/AiPHUZRH In this case I used a
>> 3.0 gig memory size for the Windows domU.
>>
>> As I mentioned before, sometimes it's the SATA that goes first, other
>> times the tg3 ethernet driver. Also note that between 4.4.1 and 4.5rc1,
>> the kernel I'm using (stock Debian Jessie) has not changed.
>>
>> Please let me know if you need any other information. Thanks!
> Raising the kernel log level to maximum too would have helped.

Okay, I've done that and the output is here, let me know if you have any 
preferred logging flags instead:

http://pastebin.com/M3yvWNTT

> Regardless of that, the first device showing anomalies here appears
> to be the UHCI controller:
>
>      [  147.415713] usb 7-1: reset low-speed USB device number 2 using uhci_hcd
>
> while booting the guest.

I assume this is related to the USB device (a keyboard) I'm passing 
through to the domU.

> And these
>
>      [  199.775209] pcieport 0000:00:03.0: AER: Multiple Corrected error received: id=0018
>      [  199.775238] pcieport 0000:00:03.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID)
>      [  199.775251] pcieport 0000:00:03.0:   device [8086:340a] error status/mask=00001100/00002000
>      [  199.775255] pcieport 0000:00:03.0:    [ 8] RELAY_NUM Rollover
>      [  199.775258] pcieport 0000:00:03.0:    [12] Replay Timer Timeout
>
> hint at a problem in the system's design. 00:03.0 is the parent bridge
> of 02:00.0 (and from what I can tell that's the only device behind that
> bridge), and hence the above messages can only reasonably have
> their origin at the passed through VGA device.

You are correct that the VGA card is the only device on 03.0:

root@g2:~# lspci -tv
-[0000:00]-+-00.0  Intel Corporation 5520 I/O Hub to ESI Port
            +-01.0-[01]----00.0  Marvell Technology Group Ltd. 
MV64460/64461/64462 System Controller, Revision B
            +-03.0-[02]----00.0  NVIDIA Corporation GT200GL [Quadro FX 4800]
            +-07.0-[03]--
            +-14.0  Intel Corporation 7500/5520/5500/X58 I/O Hub System 
Management Registers
            +-14.1  Intel Corporation 7500/5520/5500/X58 I/O Hub GPIO 
and Scratch Pad Registers
            +-14.2  Intel Corporation 7500/5520/5500/X58 I/O Hub Control 
Status and RAS Registers
            +-16.0  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.1  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.2  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.3  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.4  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.5  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.6  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.7  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-1a.0  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #4
            +-1a.1  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #5
            +-1a.7  Intel Corporation 82801JI (ICH10 Family) USB2 EHCI 
Controller #2
            +-1b.0  Intel Corporation 82801JI (ICH10 Family) HD Audio 
Controller
            +-1c.0-[04]--
            +-1c.4-[05]----00.0  Broadcom Corporation NetXtreme BCM5755 
Gigabit Ethernet PCI Express
            +-1c.5-[06-09]----00.0-[07-09]--+-02.0-[08]--
            |                               \-03.0-[09]----00.0 Broadcom 
Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express
            +-1d.0  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #1
            +-1d.1  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #2
            +-1d.2  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #3
            +-1d.3  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #6
            +-1d.7  Intel Corporation 82801JI (ICH10 Family) USB2 EHCI 
Controller #1
            +-1e.0-[0a]----0e.0  Advanced Micro Devices, Inc. [AMD/ATI] 
RV100 [Radeon 7000 / Radeon VE]
            +-1f.0  Intel Corporation 82801JIB (ICH10) LPC Interface 
Controller
            +-1f.2  Intel Corporation 82801JI (ICH10 Family) SATA AHCI 
Controller
            \-1f.3  Intel Corporation 82801JI (ICH10 Family) SMBus 
Controller

What problem in the system's design does this hint at?

> IOW it may well be that
> you were just lucky that things worked earlier on.

Certainly possible but this is a very common machine in the corporate 
world -- a Lenovo ThinkStation D20 running the X58 chipset. If it's an 
inherent defect in the machine and somebody else hasn't already tripped 
over it I would be very surprised.

> And btw - the title saying "host crash" seems to not match the provided
> log, as there's no sign of a crash anywhere (the host may be hung from
> what is visible). Was that just badly worded, or have you actually seen
> crashes too?
>

Only seen hanging. Sorry for the lack of technical rigor on the title, 
but from the other end of the ethernet cable, it might as well have crashed.

If the expanded logging doesn't tell you anything useful, I'll see if I 
can bisect the problem.

Thanks very much for your time.

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 20:05:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 20: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 1XnvD2-00049p-CL; Mon, 10 Nov 2014 20:05:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XnvD0-00049h-Sp
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 20:05:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/E7-24532-27A11645; Mon, 10 Nov 2014 20:05:06 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415649904!4786518!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26517 invoked from network); 10 Nov 2014 20:05:05 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 20:05:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415649903; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=X+A6ItQDV8zVbQpflvOcMZV3C0f+QJo0feKBhflyHao=;
	b=2UGBFtiCmMKYgZxrG/yRzDT7GzqXgH7uSwPFqDXKl3fMzd2BZ+yGBG8YI7B0K2cyD0qa3mw2Oj02zS9fkYWA0VzQ3INL/smeYMSOO57I0Kp3WgIlN4Bz6xAlY/ZbHkEEOMUUx+VC0SAk3qXrv+oO4HunkZ0p+yJixcdkWVLSIz0=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 10 Nov 2014 12:05:02 -0800
	id 00000000000305E9.54611A6E.0000441B
Message-ID: <54611A86.4000200@ihonk.com>
Date: Mon, 10 Nov 2014 12:05:26 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, pasik@iki.fi
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
In-Reply-To: <54608A8B0200007800045E58@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 0:51, Jan Beulich wrote:
>>>> On 10.11.14 at 09:03, <sflist@ihonk.com> wrote:
>> Sorry for the delay, took some debugging on another computer to get
>> serial logging working. Due to its size, I've posted the entire log of a
>> crashed session here: http://pastebin.com/AiPHUZRH In this case I used a
>> 3.0 gig memory size for the Windows domU.
>>
>> As I mentioned before, sometimes it's the SATA that goes first, other
>> times the tg3 ethernet driver. Also note that between 4.4.1 and 4.5rc1,
>> the kernel I'm using (stock Debian Jessie) has not changed.
>>
>> Please let me know if you need any other information. Thanks!
> Raising the kernel log level to maximum too would have helped.

Okay, I've done that and the output is here, let me know if you have any 
preferred logging flags instead:

http://pastebin.com/M3yvWNTT

> Regardless of that, the first device showing anomalies here appears
> to be the UHCI controller:
>
>      [  147.415713] usb 7-1: reset low-speed USB device number 2 using uhci_hcd
>
> while booting the guest.

I assume this is related to the USB device (a keyboard) I'm passing 
through to the domU.

> And these
>
>      [  199.775209] pcieport 0000:00:03.0: AER: Multiple Corrected error received: id=0018
>      [  199.775238] pcieport 0000:00:03.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID)
>      [  199.775251] pcieport 0000:00:03.0:   device [8086:340a] error status/mask=00001100/00002000
>      [  199.775255] pcieport 0000:00:03.0:    [ 8] RELAY_NUM Rollover
>      [  199.775258] pcieport 0000:00:03.0:    [12] Replay Timer Timeout
>
> hint at a problem in the system's design. 00:03.0 is the parent bridge
> of 02:00.0 (and from what I can tell that's the only device behind that
> bridge), and hence the above messages can only reasonably have
> their origin at the passed through VGA device.

You are correct that the VGA card is the only device on 03.0:

root@g2:~# lspci -tv
-[0000:00]-+-00.0  Intel Corporation 5520 I/O Hub to ESI Port
            +-01.0-[01]----00.0  Marvell Technology Group Ltd. 
MV64460/64461/64462 System Controller, Revision B
            +-03.0-[02]----00.0  NVIDIA Corporation GT200GL [Quadro FX 4800]
            +-07.0-[03]--
            +-14.0  Intel Corporation 7500/5520/5500/X58 I/O Hub System 
Management Registers
            +-14.1  Intel Corporation 7500/5520/5500/X58 I/O Hub GPIO 
and Scratch Pad Registers
            +-14.2  Intel Corporation 7500/5520/5500/X58 I/O Hub Control 
Status and RAS Registers
            +-16.0  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.1  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.2  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.3  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.4  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.5  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.6  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-16.7  Intel Corporation 5520/5500/X58 Chipset QuickData 
Technology Device
            +-1a.0  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #4
            +-1a.1  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #5
            +-1a.7  Intel Corporation 82801JI (ICH10 Family) USB2 EHCI 
Controller #2
            +-1b.0  Intel Corporation 82801JI (ICH10 Family) HD Audio 
Controller
            +-1c.0-[04]--
            +-1c.4-[05]----00.0  Broadcom Corporation NetXtreme BCM5755 
Gigabit Ethernet PCI Express
            +-1c.5-[06-09]----00.0-[07-09]--+-02.0-[08]--
            |                               \-03.0-[09]----00.0 Broadcom 
Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express
            +-1d.0  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #1
            +-1d.1  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #2
            +-1d.2  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #3
            +-1d.3  Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #6
            +-1d.7  Intel Corporation 82801JI (ICH10 Family) USB2 EHCI 
Controller #1
            +-1e.0-[0a]----0e.0  Advanced Micro Devices, Inc. [AMD/ATI] 
RV100 [Radeon 7000 / Radeon VE]
            +-1f.0  Intel Corporation 82801JIB (ICH10) LPC Interface 
Controller
            +-1f.2  Intel Corporation 82801JI (ICH10 Family) SATA AHCI 
Controller
            \-1f.3  Intel Corporation 82801JI (ICH10 Family) SMBus 
Controller

What problem in the system's design does this hint at?

> IOW it may well be that
> you were just lucky that things worked earlier on.

Certainly possible but this is a very common machine in the corporate 
world -- a Lenovo ThinkStation D20 running the X58 chipset. If it's an 
inherent defect in the machine and somebody else hasn't already tripped 
over it I would be very surprised.

> And btw - the title saying "host crash" seems to not match the provided
> log, as there's no sign of a crash anywhere (the host may be hung from
> what is visible). Was that just badly worded, or have you actually seen
> crashes too?
>

Only seen hanging. Sorry for the lack of technical rigor on the title, 
but from the other end of the ethernet cable, it might as well have crashed.

If the expanded logging doesn't tell you anything useful, I'll see if I 
can bisect the problem.

Thanks very much for your time.

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 20:45:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 20:45:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnvpc-0004mU-2w; Mon, 10 Nov 2014 20:45:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xnvpa-0004mP-O2
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 20:44:58 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	6E/CA-24124-AC321645; Mon, 10 Nov 2014 20:44:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415652294!11667244!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25165 invoked from network); 10 Nov 2014 20:44:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 20:44:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,354,1413244800"; d="scan'208";a="191338560"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 15:44:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnvpC-0008Ff-LQ;
	Mon, 10 Nov 2014 20:44:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnvpC-0000kG-94;
	Mon, 10 Nov 2014 20:44:34 +0000
Date: Mon, 10 Nov 2014 20:44:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31462-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31462: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31462 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31462/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start           fail pass in 31452
 test-amd64-i386-xl-multivcpu  5 xen-boot                    fail pass in 31452
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot              fail pass in 31452

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31452 never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 10 20:45:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 20:45:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnvpc-0004mU-2w; Mon, 10 Nov 2014 20:45:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xnvpa-0004mP-O2
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 20:44:58 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	6E/CA-24124-AC321645; Mon, 10 Nov 2014 20:44:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415652294!11667244!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25165 invoked from network); 10 Nov 2014 20:44:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 20:44:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,354,1413244800"; d="scan'208";a="191338560"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 15:44:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnvpC-0008Ff-LQ;
	Mon, 10 Nov 2014 20:44:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnvpC-0000kG-94;
	Mon, 10 Nov 2014 20:44:34 +0000
Date: Mon, 10 Nov 2014 20:44:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31462-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31462: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31462 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31462/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start           fail pass in 31452
 test-amd64-i386-xl-multivcpu  5 xen-boot                    fail pass in 31452
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot              fail pass in 31452

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31452 never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 10 21:02:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21: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 1Xnw6d-0005As-3d; Mon, 10 Nov 2014 21:02:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xnw6b-0005An-9a
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 21:02:33 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	AF/D2-25547-8E721645; Mon, 10 Nov 2014 21:02:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415653349!11677072!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22538 invoked from network); 10 Nov 2014 21:02:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 21:02:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAL2JDL027767
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 21:02:20 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAAL2GPE025257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 21:02:17 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAL2GUs002357; Mon, 10 Nov 2014 21:02:16 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 13:02:16 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E4201113772; Mon, 10 Nov 2014 16:02:14 -0500 (EST)
Date: Mon, 10 Nov 2014 16:02:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141110210214.GA21090@laptop.dumpdata.com>
References: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
	<1415042078-8337-3-git-send-email-konrad.wilk@oracle.com>
	<5458BA790200007800044B58@mail.emea.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="MGYHOYXEY6WxJCY8"
Content-Disposition: inline
In-Reply-To: <5458BA790200007800044B58@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [for-xen-4.5 v9 2/2] dpci: Replace tasklet with an
	softirq (v12)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Nov 04, 2014 at 10:37:29AM +0000, Jan Beulich wrote:
> >>> On 03.11.14 at 20:14, <konrad.wilk@oracle.com> wrote:
> > +/*
> > + * Should only be called from hvm_do_IRQ_dpci. We use the
> 
> This statement together with the comment in pt_pirq_softirq_active()
> is at least confusing: If the function is to be called in only one place,
> there shouldn't be a second place where its use is being suggested.
> Plus, a function with such required limited use would very likely better
> not be a separate function at all.

Could you explain your rationale for it please?

I am of course OK changing it, but when reading this patch and having most of
the functions that deal with the new code in one place - makes it easier
to read.
> 
> > @@ -159,7 +279,16 @@ int pt_irq_create_bind(
> >              {
> >                  rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
> >                  if ( unlikely(rc) )
> > +                {
> >                      pirq_guest_unbind(d, info);
> > +                    /*
> > +                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
> > +                     * an interrupt can be scheduled. No more of them are going
> > +                     * to be scheduled but we must deal with the one that is in
> 
> s/ is / may be /?
> 
> > @@ -269,6 +398,10 @@ int pt_irq_create_bind(
> >              {
> >                  if ( pt_irq_need_timer(pirq_dpci->flags) )
> >                      kill_timer(&pirq_dpci->timer);
> > +                /*
> > +                 * There is no path for __do_IRQ to schedule softirq as
> > +                 * IRQ_GUEST is not set. As such we can reset 'dom' right away.
> 
> "right away" suggests the alternative handling defers it in any way.
> Maybe better "directly"?

Done. I've updated the patch and also removed/added some comments.See attached
and inline:

>From b4cdb5365d9d254c87b82bc3df794c935c682541 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 23 Oct 2014 20:41:24 -0400
Subject: [PATCH] dpci: Replace tasklet with an softirq (v13)

The existing tasklet mechanism has a single global
spinlock that is taken every-time the global list
is touched. And we use this lock quite a lot - when
we call do_tasklet_work which is called via an softirq
and from the idle loop. We take the lock on any
operation on the tasklet_list.

The problem we are facing is that there are quite a lot of
tasklets scheduled. The most common one that is invoked is
the one injecting the VIRQ_TIMER in the guest. Guests
are not insane and don't set the one-shot or periodic
clocks to be in sub 1ms intervals (causing said tasklet
to be scheduled for such small intervalls).

The problem appears when PCI passthrough devices are used
over many sockets and we have an mix of heavy-interrupt
guests and idle guests. The idle guests end up seeing
1/10 of its RUNNING timeslice eaten by the hypervisor
(and 40% steal time).

The mechanism by which we inject PCI interrupts is by
hvm_do_IRQ_dpci which schedules the hvm_dirq_assist
tasklet every time an interrupt is received.
The callchain is:

_asm_vmexit_handler
 -> vmx_vmexit_handler
    ->vmx_do_extint
        -> do_IRQ
            -> __do_IRQ_guest
                -> hvm_do_IRQ_dpci
                   tasklet_schedule(&dpci->dirq_tasklet);
                   [takes lock to put the tasklet on]

[later on the schedule_tail is invoked which is 'vmx_do_resume']

vmx_do_resume
 -> vmx_asm_do_vmentry
        -> call vmx_intr_assist
          -> vmx_process_softirqs
            -> do_softirq
              [executes the tasklet function, takes the
               lock again]

While on other CPUs they might be sitting in a idle loop
and invoked to deliver an VIRQ_TIMER, which also ends
up taking the lock twice: first to schedule the
v->arch.hvm_vcpu.assert_evtchn_irq_tasklet (accounted to
the guests' BLOCKED_state); then to execute it - which is
accounted for in the guest's RUNTIME_state.

The end result is that on a 8 socket machine with
PCI passthrough, where four sockets are busy with interrupts,
and the other sockets have idle guests - we end up with
the idle guests having around 40% steal time and 1/10
of its timeslice (3ms out of 30 ms) being tied up
taking the lock. The latency of the PCI interrupts delieved
to guest is also hindered.

With this patch the problem disappears completly.
That is removing the lock for the PCI passthrough use-case
(the 'hvm_dirq_assist' case) by not using tasklets at all.

The patch is simple - instead of scheduling an tasklet
we schedule our own softirq - HVM_DPCI_SOFTIRQ, which will
take care of running 'hvm_dirq_assist'. The information we need
on each CPU is which 'struct hvm_pirq_dpci' structure the
'hvm_dirq_assist' needs to run on. That is simple solved by
threading the 'struct hvm_pirq_dpci' through a linked list.
The rule of only running one 'hvm_dirq_assist' for only
one 'hvm_pirq_dpci' is also preserved by having
'schedule_dpci_for' ignore any subsequent calls for an domain
which has already been scheduled.

== Code details ==

Most of the code complexity comes from the '->dom' field
in the 'hvm_pirq_dpci' structure. We use it for ref-counting
and as such it MUST be valid as long as STATE_SCHED bit is
set. Whoever clears the STATE_SCHED bit does the ref-counting
and can also reset the '->dom' field.

To compound the complexity, there are multiple points where the
'hvm_pirq_dpci' structure is reset or re-used. Initially
(first time the domain uses the pirq), the 'hvm_pirq_dpci->dom'
field is set to NULL as it is allocated. On subsequent calls
in to 'pt_irq_create_bind' the ->dom is whatever it had last time.

As this is the initial call (which QEMU ends up calling when the
guest writes an vector value in the MSI field) we MUST set the
'->dom' to a the proper structure (otherwise we cannot do
proper ref-counting).

The mechanism to tear it down is more complex as there
are three ways it can be executed. To make it simpler
everything revolves around 'pt_pirq_softirq_active'. If it
returns -EAGAIN that means there is an outstanding softirq
that needs to finish running before we can continue tearing
down. With that in mind:

a) pci_clean_dpci_irq. This gets called when the guest is
   being destroyed. We end up calling 'pt_pirq_softirq_active'
   to see if it is OK to continue the destruction.

   The scenarios in which the 'struct pirq' (and subsequently
   the 'hvm_pirq_dpci') gets destroyed is when:

   - guest did not use the pirq at all after setup.
   - guest did use pirq, but decided to mask and left it in that
     state.
   - guest did use pirq, but crashed.

   In all of those scenarios we end up calling
   'pt_pirq_softirq_active' to check if the softirq is still
   active. Read below on the 'pt_pirq_softirq_active' loop.

b) pt_irq_destroy_bind (guest disables the MSI). We double-check
   that the softirq has run by piggy-backing on the existing
   'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
   We add the extra call to 'pt_pirq_softirq_active' in
   'pt_pirq_cleanup_check'.

   NOTE: Guests that use event channels unbind first the
   event channel from PIRQs, so the 'pt_pirq_cleanup_check'
   won't be called as 'event' is set to zero. In that case
   we either clean it up via the a) or c) mechanism.

   There is an extra scenario regardless of 'event' being
   set or not: the guest did 'pt_irq_destroy_bind' while an
   interrupt was triggered and softirq was scheduled (but had not
   been run). It is OK to still run the softirq as
   hvm_dirq_assist won't do anything (as the flags are
   set to zero). However we will try to deschedule the
   softirq if we can (by clearing the STATE_SCHED bit and us
   doing the ref-counting).

c) pt_irq_create_bind (not a typo). The scenarios are:

     - guest disables the MSI and then enables it
       (rmmod and modprobe in a loop). We call 'pt_pirq_reset'
       which checks to see if the softirq has been scheduled.
       Imagine the 'b)' with interrupts in flight and c) getting
       called in a loop.

We will spin up on 'pt_pirq_is_active' (at the start of the
'pt_irq_create_bind') with the event_lock spinlock dropped and
waiting (cpu_relax). We cannot call 'process_pending_softirqs' as it
might result in a dead-lock. hvm_dirq_assist will be executed
and then the softirq will clear 'state' which signals that that we
can re-use the 'hvm_pirq_dpci' structure. In case this softirq
is scheduled on a remote CPU the softirq will run on it as the
semantics behind an softirq is that it will execute within the
guest interruption.

     - we hit once the error paths in 'pt_irq_create_bind' while
       an interrupt was triggered and softirq was scheduled.

If the softirq is in STATE_RUN that means it is executing and we should
let it continue on. We can clear the '->dom' field as the softirq
has stashed it beforehand. If the softirq is STATE_SCHED and
we are successful in clearing it, we do the ref-counting and
clear the '->dom' field. Otherwise we let the softirq continue
on and the '->dom' field is left intact. The clearing of
the '->dom' is left to a), b) or again c) case.

Note that in both cases the 'flags' variable is cleared so
hvm_dirq_assist won't actually do anything.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: Jan Beulich <JBeulich@suse.com>

---
v2: On top of ref-cnts also have wait loop for the outstanding
    'struct domain' that need to be processed.
v3: Add -ERETRY, fix up StyleGuide issues
v4: Clean it up mode, redo per_cpu, this_cpu logic
v5: Instead of threading struct domain, use hvm_pirq_dpci.
v6: Ditch the 'state' bit, expand description, simplify
    softirq and teardown sequence.
v7: Flesh out the comments. Drop the use of domain refcounts
v8: Add two bits (STATE_[SCHED|RUN]) to allow refcounts.
v9: Use cmpxchg, ASSSERT, fix up comments per Jan.
v10: Fix up issues spotted by Jan.
v11: IPI the remote CPU (once) if it it has the softirq scheduled.
v12: Remove the IPI for the remote CPU as the sofitrq mechanism does that.
v13: Clarify comments.
---
 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 251 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  31 ++++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 254 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..73d01bb 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1965,7 +1965,9 @@ int domain_relinquish_resources(struct domain *d)
     switch ( d->arch.relmem )
     {
     case RELMEM_not_started:
-        pci_release_devices(d);
+        ret = pci_release_devices(d);
+        if ( ret )
+            return ret;
 
         /* Tear down paging-assistance stuff. */
         ret = paging_teardown(d);
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index dceb17e..b61dbd6 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -20,14 +20,116 @@
 
 #include <xen/event.h>
 #include <xen/iommu.h>
+#include <xen/cpu.h>
 #include <xen/irq.h>
 #include <asm/hvm/irq.h>
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
-#include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long arg);
+static DEFINE_PER_CPU(struct list_head, dpci_list);
+
+/*
+ * These two bit states help to safely schedule, deschedule, and wait until
+ * the softirq has finished.
+ *
+ * The semantics behind these two bits is as follow:
+ *  - STATE_SCHED - whoever modifies it has to ref-count the domain (->dom).
+ *  - STATE_RUN - only softirq is allowed to set and clear it. If it has
+ *      been set hvm_dirq_assist will RUN with a saved value of the
+ *      'struct domain' copied from 'pirq_dpci->dom' before STATE_RUN was set.
+ *
+ * The usual states are: STATE_SCHED(set) -> STATE_RUN(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(unset).
+ *
+ * However the states can also diverge such as: STATE_SCHED(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(set) -> STATE_RUN(unset). That means
+ * the 'hvm_dirq_assist' never run and that the softirq did not do any
+ * ref-counting.
+ */
+
+enum {
+    STATE_SCHED,
+    STATE_RUN
+};
+
+/*
+ * This can be called multiple times, but the softirq is only raised once.
+ * That is until the STATE_SCHED state has been cleared. The state can be
+ * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
+ * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
+ * the softirq had a chance to run).
+ */
+static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
+{
+    unsigned long flags;
+
+    if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+        return;
+
+    get_knownalive_domain(pirq_dpci->dom);
+
+    local_irq_save(flags);
+    list_add_tail(&pirq_dpci->softirq_list, &this_cpu(dpci_list));
+    local_irq_restore(flags);
+
+    raise_softirq(HVM_DPCI_SOFTIRQ);
+}
+
+/*
+ * If we are racing with softirq_dpci (STATE_SCHED) we return
+ * true. Otherwise we return false.
+ *
+ * If it is false, it is the callers responsibility to make sure
+ * that the softirq (with the event_lock dropped) has ran.
+ */
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
+{
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+        return 1;
+
+    /*
+     * If in the future we would call 'raise_softirq_for' right away
+     * after 'pt_pirq_softirq_active' we MUST reset the list (otherwise it
+     * might have stale data).
+     */
+    return 0;
+}
+
+/*
+ * Reset the pirq_dpci->dom parameter to NULL.
+ *
+ * This function checks the different states to make sure it can do it
+ * at the right time. If it unschedules the 'hvm_dirq_assist' from running
+ * it also refcounts (which is what the softirq would have done) properly.
+ */
+static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+{
+    struct domain *d = pirq_dpci->dom;
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    {
+    case (1 << STATE_SCHED):
+        /*
+         * We are going to try to de-schedule the softirq before it goes in
+         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
+         */
+        put_domain(d);
+        /* fallthrough. */
+    case (1 << STATE_RUN):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED):
+        /*
+         * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
+         * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
+         * in local variable before it sets STATE_RUN - and therefore will not
+         * dereference '->dom' which would crash.
+         */
+        pirq_dpci->dom = NULL;
+        break;
+    }
+}
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -40,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->masked = 0;
+        pirq_dpci->state = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -101,6 +203,7 @@ int pt_irq_create_bind(
     if ( pirq < 0 || pirq >= d->nr_pirqs )
         return -EINVAL;
 
+ restart:
     spin_lock(&d->event_lock);
 
     hvm_irq_dpci = domain_get_irq_dpci(d);
@@ -127,7 +230,20 @@ int pt_irq_create_bind(
         return -ENOMEM;
     }
     pirq_dpci = pirq_dpci(info);
-
+    /*
+     * A crude 'while' loop with us dropping the spinlock and giving
+     * the softirq_dpci a chance to run.
+     * We MUST check for this condition as the softirq could be scheduled
+     * and hasn't run yet. Note that this code replaced tasklet_kill which
+     * would have spun forever and would do the same thing (wait to flush out
+     * outstanding hvm_dirq_assist calls.
+     */
+    if ( pt_pirq_softirq_active(pirq_dpci) )
+    {
+        spin_unlock(&d->event_lock);
+        cpu_relax();
+        goto restart;
+    }
     switch ( pt_irq_bind->irq_type )
     {
     case PT_IRQ_TYPE_MSI:
@@ -159,7 +275,16 @@ int pt_irq_create_bind(
             {
                 rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
                 if ( unlikely(rc) )
+                {
                     pirq_guest_unbind(d, info);
+                    /*
+                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
+                     * an interrupt can be scheduled. No more of them are going
+                     * to be scheduled but we must deal with the one that may be
+                     * in the queue.
+                     */
+                    pt_pirq_softirq_reset(pirq_dpci);
+                }
             }
             if ( unlikely(rc) )
             {
@@ -269,6 +394,10 @@ int pt_irq_create_bind(
             {
                 if ( pt_irq_need_timer(pirq_dpci->flags) )
                     kill_timer(&pirq_dpci->timer);
+                /*
+                 * There is no path for __do_IRQ to schedule softirq as
+                 * IRQ_GUEST is not set. As such we can reset 'dom' directly.
+                 */
                 pirq_dpci->dom = NULL;
                 list_del(&girq->list);
                 list_del(&digl->list);
@@ -402,8 +531,13 @@ int pt_irq_destroy_bind(
         msixtbl_pt_unregister(d, pirq);
         if ( pt_irq_need_timer(pirq_dpci->flags) )
             kill_timer(&pirq_dpci->timer);
-        pirq_dpci->dom   = NULL;
         pirq_dpci->flags = 0;
+        /*
+         * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
+         * call to pt_pirq_softirq_reset.
+         */
+        pt_pirq_softirq_reset(pirq_dpci);
+
         pirq_cleanup_check(pirq, d);
     }
 
@@ -426,14 +560,12 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
-    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    if ( !dpci->flags )
+    if ( !dpci->flags && !pt_pirq_softirq_active(dpci) )
     {
-        tasklet_kill(&dpci->tasklet);
         dpci->dom = NULL;
         return 1;
     }
@@ -476,8 +608,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
-    pirq_dpci->masked = 1;
-    tasklet_schedule(&pirq_dpci->tasklet);
+    raise_softirq_for(pirq_dpci);
     return 1;
 }
 
@@ -531,28 +662,12 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static void hvm_dirq_assist(unsigned long arg)
+static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
 {
-    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
-    struct domain *d = pirq_dpci->dom;
-
-    /*
-     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
-     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
-     *
-     * And '->dom' gets cleared later in the destroy path. We exit and clear
-     * 'masked' - which is OK as later in this code we would
-     * do nothing except clear the ->masked field anyhow.
-     */
-    if ( !d )
-    {
-        pirq_dpci->masked = 0;
-        return;
-    }
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( test_and_clear_bool(pirq_dpci->masked) )
+    if ( pirq_dpci->state )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
@@ -654,3 +769,83 @@ void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
 unlock:
     spin_unlock(&d->event_lock);
 }
+
+/*
+ * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
+ * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
+ */
+static void dpci_softirq(void)
+{
+    unsigned int cpu = smp_processor_id();
+    LIST_HEAD(our_list);
+
+    local_irq_disable();
+    list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
+    local_irq_enable();
+
+    while ( !list_empty(&our_list) )
+    {
+        struct hvm_pirq_dpci *pirq_dpci;
+        struct domain *d;
+
+        pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
+        list_del(&pirq_dpci->softirq_list);
+
+        d = pirq_dpci->dom;
+        smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
+        if ( test_and_set_bit(STATE_RUN, &pirq_dpci->state) )
+            BUG();
+        /*
+         * The one who clears STATE_SCHED MUST refcount the domain.
+         */
+        if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )
+        {
+            hvm_dirq_assist(d, pirq_dpci);
+            put_domain(d);
+        }
+        clear_bit(STATE_RUN, &pirq_dpci->state);
+    }
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        /*
+         * On CPU_DYING this callback is called (on the CPU that is dying)
+         * with an possible HVM_DPIC_SOFTIRQ pending - at which point we can
+         * clear out any outstanding domains (by the virtue of the idle loop
+         * calling the softirq later). In CPU_DEAD case the CPU is deaf and
+         * there are no pending softirqs for us to handle so we can chill.
+         */
+        ASSERT(list_empty(&per_cpu(dpci_list, cpu)));
+        break;
+    }
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback,
+};
+
+static int __init setup_dpci_softirq(void)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu(cpu)
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+
+    open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+__initcall(setup_dpci_softirq);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 81e8a3a..78c6977 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,40 +767,51 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
-    tasklet_kill(&pirq_dpci->tasklet);
-
-    return 0;
+    return pt_pirq_softirq_active(pirq_dpci) ? -ERESTART : 0;
 }
 
-static void pci_clean_dpci_irqs(struct domain *d)
+static int pci_clean_dpci_irqs(struct domain *d)
 {
     struct hvm_irq_dpci *hvm_irq_dpci = NULL;
 
     if ( !iommu_enabled )
-        return;
+        return 0;
 
     if ( !is_hvm_domain(d) )
-        return;
+        return 0;
 
     spin_lock(&d->event_lock);
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+        int ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+
+        if ( ret )
+        {
+            spin_unlock(&d->event_lock);
+            return ret;
+        }
 
         d->arch.hvm_domain.irq.dpci = NULL;
         free_hvm_irq_dpci(hvm_irq_dpci);
     }
     spin_unlock(&d->event_lock);
+    return 0;
 }
 
-void pci_release_devices(struct domain *d)
+int pci_release_devices(struct domain *d)
 {
     struct pci_dev *pdev;
     u8 bus, devfn;
+    int ret;
 
     spin_lock(&pcidevs_lock);
-    pci_clean_dpci_irqs(d);
+    ret = pci_clean_dpci_irqs(d);
+    if ( ret )
+    {
+        spin_unlock(&pcidevs_lock);
+        return ret;
+    }
     while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
     {
         bus = pdev->bus;
@@ -811,6 +822,8 @@ void pci_release_devices(struct domain *d)
                    PCI_SLOT(devfn), PCI_FUNC(devfn));
     }
     spin_unlock(&pcidevs_lock);
+
+    return 0;
 }
 
 #define PCI_CLASS_BRIDGE_HOST    0x0600
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 7225dea..ec787d6 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -7,7 +7,8 @@
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
-#define NR_ARCH_SOFTIRQS       5
+#define HVM_DPCI_SOFTIRQ       (NR_COMMON_SOFTIRQS + 5)
+#define NR_ARCH_SOFTIRQS       6
 
 bool_t arch_skip_send_event_check(unsigned int cpu);
 
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 94a550a..9709397 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -93,13 +93,13 @@ struct hvm_irq_dpci {
 /* Machine IRQ to guest device/intx mapping. */
 struct hvm_pirq_dpci {
     uint32_t flags;
-    bool_t masked;
+    unsigned int state;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
-    struct tasklet tasklet;
+    struct list_head softirq_list;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
@@ -109,6 +109,7 @@ int pt_pirq_iterate(struct domain *d,
                               struct hvm_pirq_dpci *, void *arg),
                     void *arg);
 
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *);
 /* Modify state of a PCI INTx wire. */
 void hvm_pci_intx_assert(
     struct domain *d, unsigned int device, unsigned int intx);
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 91520bc..5f295f3 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -99,7 +99,7 @@ struct pci_dev *pci_lock_domain_pdev(
 
 void setup_hwdom_pci_devices(struct domain *,
                             int (*)(u8 devfn, struct pci_dev *));
-void pci_release_devices(struct domain *d);
+int pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
 const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
-- 
1.9.3

> 
> Jan
> 

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-dpci-Replace-tasklet-with-an-softirq-v13.patch"

>From b4cdb5365d9d254c87b82bc3df794c935c682541 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 23 Oct 2014 20:41:24 -0400
Subject: [PATCH] dpci: Replace tasklet with an softirq (v13)

The existing tasklet mechanism has a single global
spinlock that is taken every-time the global list
is touched. And we use this lock quite a lot - when
we call do_tasklet_work which is called via an softirq
and from the idle loop. We take the lock on any
operation on the tasklet_list.

The problem we are facing is that there are quite a lot of
tasklets scheduled. The most common one that is invoked is
the one injecting the VIRQ_TIMER in the guest. Guests
are not insane and don't set the one-shot or periodic
clocks to be in sub 1ms intervals (causing said tasklet
to be scheduled for such small intervalls).

The problem appears when PCI passthrough devices are used
over many sockets and we have an mix of heavy-interrupt
guests and idle guests. The idle guests end up seeing
1/10 of its RUNNING timeslice eaten by the hypervisor
(and 40% steal time).

The mechanism by which we inject PCI interrupts is by
hvm_do_IRQ_dpci which schedules the hvm_dirq_assist
tasklet every time an interrupt is received.
The callchain is:

_asm_vmexit_handler
 -> vmx_vmexit_handler
    ->vmx_do_extint
        -> do_IRQ
            -> __do_IRQ_guest
                -> hvm_do_IRQ_dpci
                   tasklet_schedule(&dpci->dirq_tasklet);
                   [takes lock to put the tasklet on]

[later on the schedule_tail is invoked which is 'vmx_do_resume']

vmx_do_resume
 -> vmx_asm_do_vmentry
        -> call vmx_intr_assist
          -> vmx_process_softirqs
            -> do_softirq
              [executes the tasklet function, takes the
               lock again]

While on other CPUs they might be sitting in a idle loop
and invoked to deliver an VIRQ_TIMER, which also ends
up taking the lock twice: first to schedule the
v->arch.hvm_vcpu.assert_evtchn_irq_tasklet (accounted to
the guests' BLOCKED_state); then to execute it - which is
accounted for in the guest's RUNTIME_state.

The end result is that on a 8 socket machine with
PCI passthrough, where four sockets are busy with interrupts,
and the other sockets have idle guests - we end up with
the idle guests having around 40% steal time and 1/10
of its timeslice (3ms out of 30 ms) being tied up
taking the lock. The latency of the PCI interrupts delieved
to guest is also hindered.

With this patch the problem disappears completly.
That is removing the lock for the PCI passthrough use-case
(the 'hvm_dirq_assist' case) by not using tasklets at all.

The patch is simple - instead of scheduling an tasklet
we schedule our own softirq - HVM_DPCI_SOFTIRQ, which will
take care of running 'hvm_dirq_assist'. The information we need
on each CPU is which 'struct hvm_pirq_dpci' structure the
'hvm_dirq_assist' needs to run on. That is simple solved by
threading the 'struct hvm_pirq_dpci' through a linked list.
The rule of only running one 'hvm_dirq_assist' for only
one 'hvm_pirq_dpci' is also preserved by having
'schedule_dpci_for' ignore any subsequent calls for an domain
which has already been scheduled.

== Code details ==

Most of the code complexity comes from the '->dom' field
in the 'hvm_pirq_dpci' structure. We use it for ref-counting
and as such it MUST be valid as long as STATE_SCHED bit is
set. Whoever clears the STATE_SCHED bit does the ref-counting
and can also reset the '->dom' field.

To compound the complexity, there are multiple points where the
'hvm_pirq_dpci' structure is reset or re-used. Initially
(first time the domain uses the pirq), the 'hvm_pirq_dpci->dom'
field is set to NULL as it is allocated. On subsequent calls
in to 'pt_irq_create_bind' the ->dom is whatever it had last time.

As this is the initial call (which QEMU ends up calling when the
guest writes an vector value in the MSI field) we MUST set the
'->dom' to a the proper structure (otherwise we cannot do
proper ref-counting).

The mechanism to tear it down is more complex as there
are three ways it can be executed. To make it simpler
everything revolves around 'pt_pirq_softirq_active'. If it
returns -EAGAIN that means there is an outstanding softirq
that needs to finish running before we can continue tearing
down. With that in mind:

a) pci_clean_dpci_irq. This gets called when the guest is
   being destroyed. We end up calling 'pt_pirq_softirq_active'
   to see if it is OK to continue the destruction.

   The scenarios in which the 'struct pirq' (and subsequently
   the 'hvm_pirq_dpci') gets destroyed is when:

   - guest did not use the pirq at all after setup.
   - guest did use pirq, but decided to mask and left it in that
     state.
   - guest did use pirq, but crashed.

   In all of those scenarios we end up calling
   'pt_pirq_softirq_active' to check if the softirq is still
   active. Read below on the 'pt_pirq_softirq_active' loop.

b) pt_irq_destroy_bind (guest disables the MSI). We double-check
   that the softirq has run by piggy-backing on the existing
   'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
   We add the extra call to 'pt_pirq_softirq_active' in
   'pt_pirq_cleanup_check'.

   NOTE: Guests that use event channels unbind first the
   event channel from PIRQs, so the 'pt_pirq_cleanup_check'
   won't be called as 'event' is set to zero. In that case
   we either clean it up via the a) or c) mechanism.

   There is an extra scenario regardless of 'event' being
   set or not: the guest did 'pt_irq_destroy_bind' while an
   interrupt was triggered and softirq was scheduled (but had not
   been run). It is OK to still run the softirq as
   hvm_dirq_assist won't do anything (as the flags are
   set to zero). However we will try to deschedule the
   softirq if we can (by clearing the STATE_SCHED bit and us
   doing the ref-counting).

c) pt_irq_create_bind (not a typo). The scenarios are:

     - guest disables the MSI and then enables it
       (rmmod and modprobe in a loop). We call 'pt_pirq_reset'
       which checks to see if the softirq has been scheduled.
       Imagine the 'b)' with interrupts in flight and c) getting
       called in a loop.

We will spin up on 'pt_pirq_is_active' (at the start of the
'pt_irq_create_bind') with the event_lock spinlock dropped and
waiting (cpu_relax). We cannot call 'process_pending_softirqs' as it
might result in a dead-lock. hvm_dirq_assist will be executed
and then the softirq will clear 'state' which signals that that we
can re-use the 'hvm_pirq_dpci' structure. In case this softirq
is scheduled on a remote CPU the softirq will run on it as the
semantics behind an softirq is that it will execute within the
guest interruption.

     - we hit once the error paths in 'pt_irq_create_bind' while
       an interrupt was triggered and softirq was scheduled.

If the softirq is in STATE_RUN that means it is executing and we should
let it continue on. We can clear the '->dom' field as the softirq
has stashed it beforehand. If the softirq is STATE_SCHED and
we are successful in clearing it, we do the ref-counting and
clear the '->dom' field. Otherwise we let the softirq continue
on and the '->dom' field is left intact. The clearing of
the '->dom' is left to a), b) or again c) case.

Note that in both cases the 'flags' variable is cleared so
hvm_dirq_assist won't actually do anything.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: Jan Beulich <JBeulich@suse.com>

---
v2: On top of ref-cnts also have wait loop for the outstanding
    'struct domain' that need to be processed.
v3: Add -ERETRY, fix up StyleGuide issues
v4: Clean it up mode, redo per_cpu, this_cpu logic
v5: Instead of threading struct domain, use hvm_pirq_dpci.
v6: Ditch the 'state' bit, expand description, simplify
    softirq and teardown sequence.
v7: Flesh out the comments. Drop the use of domain refcounts
v8: Add two bits (STATE_[SCHED|RUN]) to allow refcounts.
v9: Use cmpxchg, ASSSERT, fix up comments per Jan.
v10: Fix up issues spotted by Jan.
v11: IPI the remote CPU (once) if it it has the softirq scheduled.
v12: Remove the IPI for the remote CPU as the sofitrq mechanism does that.
v13: Clarify comments.
---
 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 251 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  31 ++++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 254 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..73d01bb 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1965,7 +1965,9 @@ int domain_relinquish_resources(struct domain *d)
     switch ( d->arch.relmem )
     {
     case RELMEM_not_started:
-        pci_release_devices(d);
+        ret = pci_release_devices(d);
+        if ( ret )
+            return ret;
 
         /* Tear down paging-assistance stuff. */
         ret = paging_teardown(d);
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index dceb17e..b61dbd6 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -20,14 +20,116 @@
 
 #include <xen/event.h>
 #include <xen/iommu.h>
+#include <xen/cpu.h>
 #include <xen/irq.h>
 #include <asm/hvm/irq.h>
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
-#include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long arg);
+static DEFINE_PER_CPU(struct list_head, dpci_list);
+
+/*
+ * These two bit states help to safely schedule, deschedule, and wait until
+ * the softirq has finished.
+ *
+ * The semantics behind these two bits is as follow:
+ *  - STATE_SCHED - whoever modifies it has to ref-count the domain (->dom).
+ *  - STATE_RUN - only softirq is allowed to set and clear it. If it has
+ *      been set hvm_dirq_assist will RUN with a saved value of the
+ *      'struct domain' copied from 'pirq_dpci->dom' before STATE_RUN was set.
+ *
+ * The usual states are: STATE_SCHED(set) -> STATE_RUN(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(unset).
+ *
+ * However the states can also diverge such as: STATE_SCHED(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(set) -> STATE_RUN(unset). That means
+ * the 'hvm_dirq_assist' never run and that the softirq did not do any
+ * ref-counting.
+ */
+
+enum {
+    STATE_SCHED,
+    STATE_RUN
+};
+
+/*
+ * This can be called multiple times, but the softirq is only raised once.
+ * That is until the STATE_SCHED state has been cleared. The state can be
+ * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
+ * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
+ * the softirq had a chance to run).
+ */
+static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
+{
+    unsigned long flags;
+
+    if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+        return;
+
+    get_knownalive_domain(pirq_dpci->dom);
+
+    local_irq_save(flags);
+    list_add_tail(&pirq_dpci->softirq_list, &this_cpu(dpci_list));
+    local_irq_restore(flags);
+
+    raise_softirq(HVM_DPCI_SOFTIRQ);
+}
+
+/*
+ * If we are racing with softirq_dpci (STATE_SCHED) we return
+ * true. Otherwise we return false.
+ *
+ * If it is false, it is the callers responsibility to make sure
+ * that the softirq (with the event_lock dropped) has ran.
+ */
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
+{
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+        return 1;
+
+    /*
+     * If in the future we would call 'raise_softirq_for' right away
+     * after 'pt_pirq_softirq_active' we MUST reset the list (otherwise it
+     * might have stale data).
+     */
+    return 0;
+}
+
+/*
+ * Reset the pirq_dpci->dom parameter to NULL.
+ *
+ * This function checks the different states to make sure it can do it
+ * at the right time. If it unschedules the 'hvm_dirq_assist' from running
+ * it also refcounts (which is what the softirq would have done) properly.
+ */
+static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+{
+    struct domain *d = pirq_dpci->dom;
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    {
+    case (1 << STATE_SCHED):
+        /*
+         * We are going to try to de-schedule the softirq before it goes in
+         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
+         */
+        put_domain(d);
+        /* fallthrough. */
+    case (1 << STATE_RUN):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED):
+        /*
+         * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
+         * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
+         * in local variable before it sets STATE_RUN - and therefore will not
+         * dereference '->dom' which would crash.
+         */
+        pirq_dpci->dom = NULL;
+        break;
+    }
+}
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -40,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->masked = 0;
+        pirq_dpci->state = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -101,6 +203,7 @@ int pt_irq_create_bind(
     if ( pirq < 0 || pirq >= d->nr_pirqs )
         return -EINVAL;
 
+ restart:
     spin_lock(&d->event_lock);
 
     hvm_irq_dpci = domain_get_irq_dpci(d);
@@ -127,7 +230,20 @@ int pt_irq_create_bind(
         return -ENOMEM;
     }
     pirq_dpci = pirq_dpci(info);
-
+    /*
+     * A crude 'while' loop with us dropping the spinlock and giving
+     * the softirq_dpci a chance to run.
+     * We MUST check for this condition as the softirq could be scheduled
+     * and hasn't run yet. Note that this code replaced tasklet_kill which
+     * would have spun forever and would do the same thing (wait to flush out
+     * outstanding hvm_dirq_assist calls.
+     */
+    if ( pt_pirq_softirq_active(pirq_dpci) )
+    {
+        spin_unlock(&d->event_lock);
+        cpu_relax();
+        goto restart;
+    }
     switch ( pt_irq_bind->irq_type )
     {
     case PT_IRQ_TYPE_MSI:
@@ -159,7 +275,16 @@ int pt_irq_create_bind(
             {
                 rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
                 if ( unlikely(rc) )
+                {
                     pirq_guest_unbind(d, info);
+                    /*
+                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
+                     * an interrupt can be scheduled. No more of them are going
+                     * to be scheduled but we must deal with the one that may be
+                     * in the queue.
+                     */
+                    pt_pirq_softirq_reset(pirq_dpci);
+                }
             }
             if ( unlikely(rc) )
             {
@@ -269,6 +394,10 @@ int pt_irq_create_bind(
             {
                 if ( pt_irq_need_timer(pirq_dpci->flags) )
                     kill_timer(&pirq_dpci->timer);
+                /*
+                 * There is no path for __do_IRQ to schedule softirq as
+                 * IRQ_GUEST is not set. As such we can reset 'dom' directly.
+                 */
                 pirq_dpci->dom = NULL;
                 list_del(&girq->list);
                 list_del(&digl->list);
@@ -402,8 +531,13 @@ int pt_irq_destroy_bind(
         msixtbl_pt_unregister(d, pirq);
         if ( pt_irq_need_timer(pirq_dpci->flags) )
             kill_timer(&pirq_dpci->timer);
-        pirq_dpci->dom   = NULL;
         pirq_dpci->flags = 0;
+        /*
+         * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
+         * call to pt_pirq_softirq_reset.
+         */
+        pt_pirq_softirq_reset(pirq_dpci);
+
         pirq_cleanup_check(pirq, d);
     }
 
@@ -426,14 +560,12 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
-    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    if ( !dpci->flags )
+    if ( !dpci->flags && !pt_pirq_softirq_active(dpci) )
     {
-        tasklet_kill(&dpci->tasklet);
         dpci->dom = NULL;
         return 1;
     }
@@ -476,8 +608,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
-    pirq_dpci->masked = 1;
-    tasklet_schedule(&pirq_dpci->tasklet);
+    raise_softirq_for(pirq_dpci);
     return 1;
 }
 
@@ -531,28 +662,12 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static void hvm_dirq_assist(unsigned long arg)
+static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
 {
-    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
-    struct domain *d = pirq_dpci->dom;
-
-    /*
-     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
-     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
-     *
-     * And '->dom' gets cleared later in the destroy path. We exit and clear
-     * 'masked' - which is OK as later in this code we would
-     * do nothing except clear the ->masked field anyhow.
-     */
-    if ( !d )
-    {
-        pirq_dpci->masked = 0;
-        return;
-    }
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( test_and_clear_bool(pirq_dpci->masked) )
+    if ( pirq_dpci->state )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
@@ -654,3 +769,83 @@ void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
 unlock:
     spin_unlock(&d->event_lock);
 }
+
+/*
+ * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
+ * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
+ */
+static void dpci_softirq(void)
+{
+    unsigned int cpu = smp_processor_id();
+    LIST_HEAD(our_list);
+
+    local_irq_disable();
+    list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
+    local_irq_enable();
+
+    while ( !list_empty(&our_list) )
+    {
+        struct hvm_pirq_dpci *pirq_dpci;
+        struct domain *d;
+
+        pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
+        list_del(&pirq_dpci->softirq_list);
+
+        d = pirq_dpci->dom;
+        smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
+        if ( test_and_set_bit(STATE_RUN, &pirq_dpci->state) )
+            BUG();
+        /*
+         * The one who clears STATE_SCHED MUST refcount the domain.
+         */
+        if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )
+        {
+            hvm_dirq_assist(d, pirq_dpci);
+            put_domain(d);
+        }
+        clear_bit(STATE_RUN, &pirq_dpci->state);
+    }
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        /*
+         * On CPU_DYING this callback is called (on the CPU that is dying)
+         * with an possible HVM_DPIC_SOFTIRQ pending - at which point we can
+         * clear out any outstanding domains (by the virtue of the idle loop
+         * calling the softirq later). In CPU_DEAD case the CPU is deaf and
+         * there are no pending softirqs for us to handle so we can chill.
+         */
+        ASSERT(list_empty(&per_cpu(dpci_list, cpu)));
+        break;
+    }
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback,
+};
+
+static int __init setup_dpci_softirq(void)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu(cpu)
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+
+    open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+__initcall(setup_dpci_softirq);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 81e8a3a..78c6977 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,40 +767,51 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
-    tasklet_kill(&pirq_dpci->tasklet);
-
-    return 0;
+    return pt_pirq_softirq_active(pirq_dpci) ? -ERESTART : 0;
 }
 
-static void pci_clean_dpci_irqs(struct domain *d)
+static int pci_clean_dpci_irqs(struct domain *d)
 {
     struct hvm_irq_dpci *hvm_irq_dpci = NULL;
 
     if ( !iommu_enabled )
-        return;
+        return 0;
 
     if ( !is_hvm_domain(d) )
-        return;
+        return 0;
 
     spin_lock(&d->event_lock);
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+        int ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+
+        if ( ret )
+        {
+            spin_unlock(&d->event_lock);
+            return ret;
+        }
 
         d->arch.hvm_domain.irq.dpci = NULL;
         free_hvm_irq_dpci(hvm_irq_dpci);
     }
     spin_unlock(&d->event_lock);
+    return 0;
 }
 
-void pci_release_devices(struct domain *d)
+int pci_release_devices(struct domain *d)
 {
     struct pci_dev *pdev;
     u8 bus, devfn;
+    int ret;
 
     spin_lock(&pcidevs_lock);
-    pci_clean_dpci_irqs(d);
+    ret = pci_clean_dpci_irqs(d);
+    if ( ret )
+    {
+        spin_unlock(&pcidevs_lock);
+        return ret;
+    }
     while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
     {
         bus = pdev->bus;
@@ -811,6 +822,8 @@ void pci_release_devices(struct domain *d)
                    PCI_SLOT(devfn), PCI_FUNC(devfn));
     }
     spin_unlock(&pcidevs_lock);
+
+    return 0;
 }
 
 #define PCI_CLASS_BRIDGE_HOST    0x0600
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 7225dea..ec787d6 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -7,7 +7,8 @@
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
-#define NR_ARCH_SOFTIRQS       5
+#define HVM_DPCI_SOFTIRQ       (NR_COMMON_SOFTIRQS + 5)
+#define NR_ARCH_SOFTIRQS       6
 
 bool_t arch_skip_send_event_check(unsigned int cpu);
 
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 94a550a..9709397 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -93,13 +93,13 @@ struct hvm_irq_dpci {
 /* Machine IRQ to guest device/intx mapping. */
 struct hvm_pirq_dpci {
     uint32_t flags;
-    bool_t masked;
+    unsigned int state;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
-    struct tasklet tasklet;
+    struct list_head softirq_list;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
@@ -109,6 +109,7 @@ int pt_pirq_iterate(struct domain *d,
                               struct hvm_pirq_dpci *, void *arg),
                     void *arg);
 
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *);
 /* Modify state of a PCI INTx wire. */
 void hvm_pci_intx_assert(
     struct domain *d, unsigned int device, unsigned int intx);
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 91520bc..5f295f3 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -99,7 +99,7 @@ struct pci_dev *pci_lock_domain_pdev(
 
 void setup_hwdom_pci_devices(struct domain *,
                             int (*)(u8 devfn, struct pci_dev *));
-void pci_release_devices(struct domain *d);
+int pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
 const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
-- 
1.9.3


--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--MGYHOYXEY6WxJCY8--


From xen-devel-bounces@lists.xen.org Mon Nov 10 21:02:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21: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 1Xnw6d-0005As-3d; Mon, 10 Nov 2014 21:02:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xnw6b-0005An-9a
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 21:02:33 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	AF/D2-25547-8E721645; Mon, 10 Nov 2014 21:02:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415653349!11677072!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22538 invoked from network); 10 Nov 2014 21:02:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 21:02:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAAL2JDL027767
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 21:02:20 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAAL2GPE025257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 21:02:17 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAAL2GUs002357; Mon, 10 Nov 2014 21:02:16 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 13:02:16 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E4201113772; Mon, 10 Nov 2014 16:02:14 -0500 (EST)
Date: Mon, 10 Nov 2014 16:02:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141110210214.GA21090@laptop.dumpdata.com>
References: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
	<1415042078-8337-3-git-send-email-konrad.wilk@oracle.com>
	<5458BA790200007800044B58@mail.emea.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="MGYHOYXEY6WxJCY8"
Content-Disposition: inline
In-Reply-To: <5458BA790200007800044B58@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [for-xen-4.5 v9 2/2] dpci: Replace tasklet with an
	softirq (v12)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Nov 04, 2014 at 10:37:29AM +0000, Jan Beulich wrote:
> >>> On 03.11.14 at 20:14, <konrad.wilk@oracle.com> wrote:
> > +/*
> > + * Should only be called from hvm_do_IRQ_dpci. We use the
> 
> This statement together with the comment in pt_pirq_softirq_active()
> is at least confusing: If the function is to be called in only one place,
> there shouldn't be a second place where its use is being suggested.
> Plus, a function with such required limited use would very likely better
> not be a separate function at all.

Could you explain your rationale for it please?

I am of course OK changing it, but when reading this patch and having most of
the functions that deal with the new code in one place - makes it easier
to read.
> 
> > @@ -159,7 +279,16 @@ int pt_irq_create_bind(
> >              {
> >                  rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
> >                  if ( unlikely(rc) )
> > +                {
> >                      pirq_guest_unbind(d, info);
> > +                    /*
> > +                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
> > +                     * an interrupt can be scheduled. No more of them are going
> > +                     * to be scheduled but we must deal with the one that is in
> 
> s/ is / may be /?
> 
> > @@ -269,6 +398,10 @@ int pt_irq_create_bind(
> >              {
> >                  if ( pt_irq_need_timer(pirq_dpci->flags) )
> >                      kill_timer(&pirq_dpci->timer);
> > +                /*
> > +                 * There is no path for __do_IRQ to schedule softirq as
> > +                 * IRQ_GUEST is not set. As such we can reset 'dom' right away.
> 
> "right away" suggests the alternative handling defers it in any way.
> Maybe better "directly"?

Done. I've updated the patch and also removed/added some comments.See attached
and inline:

>From b4cdb5365d9d254c87b82bc3df794c935c682541 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 23 Oct 2014 20:41:24 -0400
Subject: [PATCH] dpci: Replace tasklet with an softirq (v13)

The existing tasklet mechanism has a single global
spinlock that is taken every-time the global list
is touched. And we use this lock quite a lot - when
we call do_tasklet_work which is called via an softirq
and from the idle loop. We take the lock on any
operation on the tasklet_list.

The problem we are facing is that there are quite a lot of
tasklets scheduled. The most common one that is invoked is
the one injecting the VIRQ_TIMER in the guest. Guests
are not insane and don't set the one-shot or periodic
clocks to be in sub 1ms intervals (causing said tasklet
to be scheduled for such small intervalls).

The problem appears when PCI passthrough devices are used
over many sockets and we have an mix of heavy-interrupt
guests and idle guests. The idle guests end up seeing
1/10 of its RUNNING timeslice eaten by the hypervisor
(and 40% steal time).

The mechanism by which we inject PCI interrupts is by
hvm_do_IRQ_dpci which schedules the hvm_dirq_assist
tasklet every time an interrupt is received.
The callchain is:

_asm_vmexit_handler
 -> vmx_vmexit_handler
    ->vmx_do_extint
        -> do_IRQ
            -> __do_IRQ_guest
                -> hvm_do_IRQ_dpci
                   tasklet_schedule(&dpci->dirq_tasklet);
                   [takes lock to put the tasklet on]

[later on the schedule_tail is invoked which is 'vmx_do_resume']

vmx_do_resume
 -> vmx_asm_do_vmentry
        -> call vmx_intr_assist
          -> vmx_process_softirqs
            -> do_softirq
              [executes the tasklet function, takes the
               lock again]

While on other CPUs they might be sitting in a idle loop
and invoked to deliver an VIRQ_TIMER, which also ends
up taking the lock twice: first to schedule the
v->arch.hvm_vcpu.assert_evtchn_irq_tasklet (accounted to
the guests' BLOCKED_state); then to execute it - which is
accounted for in the guest's RUNTIME_state.

The end result is that on a 8 socket machine with
PCI passthrough, where four sockets are busy with interrupts,
and the other sockets have idle guests - we end up with
the idle guests having around 40% steal time and 1/10
of its timeslice (3ms out of 30 ms) being tied up
taking the lock. The latency of the PCI interrupts delieved
to guest is also hindered.

With this patch the problem disappears completly.
That is removing the lock for the PCI passthrough use-case
(the 'hvm_dirq_assist' case) by not using tasklets at all.

The patch is simple - instead of scheduling an tasklet
we schedule our own softirq - HVM_DPCI_SOFTIRQ, which will
take care of running 'hvm_dirq_assist'. The information we need
on each CPU is which 'struct hvm_pirq_dpci' structure the
'hvm_dirq_assist' needs to run on. That is simple solved by
threading the 'struct hvm_pirq_dpci' through a linked list.
The rule of only running one 'hvm_dirq_assist' for only
one 'hvm_pirq_dpci' is also preserved by having
'schedule_dpci_for' ignore any subsequent calls for an domain
which has already been scheduled.

== Code details ==

Most of the code complexity comes from the '->dom' field
in the 'hvm_pirq_dpci' structure. We use it for ref-counting
and as such it MUST be valid as long as STATE_SCHED bit is
set. Whoever clears the STATE_SCHED bit does the ref-counting
and can also reset the '->dom' field.

To compound the complexity, there are multiple points where the
'hvm_pirq_dpci' structure is reset or re-used. Initially
(first time the domain uses the pirq), the 'hvm_pirq_dpci->dom'
field is set to NULL as it is allocated. On subsequent calls
in to 'pt_irq_create_bind' the ->dom is whatever it had last time.

As this is the initial call (which QEMU ends up calling when the
guest writes an vector value in the MSI field) we MUST set the
'->dom' to a the proper structure (otherwise we cannot do
proper ref-counting).

The mechanism to tear it down is more complex as there
are three ways it can be executed. To make it simpler
everything revolves around 'pt_pirq_softirq_active'. If it
returns -EAGAIN that means there is an outstanding softirq
that needs to finish running before we can continue tearing
down. With that in mind:

a) pci_clean_dpci_irq. This gets called when the guest is
   being destroyed. We end up calling 'pt_pirq_softirq_active'
   to see if it is OK to continue the destruction.

   The scenarios in which the 'struct pirq' (and subsequently
   the 'hvm_pirq_dpci') gets destroyed is when:

   - guest did not use the pirq at all after setup.
   - guest did use pirq, but decided to mask and left it in that
     state.
   - guest did use pirq, but crashed.

   In all of those scenarios we end up calling
   'pt_pirq_softirq_active' to check if the softirq is still
   active. Read below on the 'pt_pirq_softirq_active' loop.

b) pt_irq_destroy_bind (guest disables the MSI). We double-check
   that the softirq has run by piggy-backing on the existing
   'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
   We add the extra call to 'pt_pirq_softirq_active' in
   'pt_pirq_cleanup_check'.

   NOTE: Guests that use event channels unbind first the
   event channel from PIRQs, so the 'pt_pirq_cleanup_check'
   won't be called as 'event' is set to zero. In that case
   we either clean it up via the a) or c) mechanism.

   There is an extra scenario regardless of 'event' being
   set or not: the guest did 'pt_irq_destroy_bind' while an
   interrupt was triggered and softirq was scheduled (but had not
   been run). It is OK to still run the softirq as
   hvm_dirq_assist won't do anything (as the flags are
   set to zero). However we will try to deschedule the
   softirq if we can (by clearing the STATE_SCHED bit and us
   doing the ref-counting).

c) pt_irq_create_bind (not a typo). The scenarios are:

     - guest disables the MSI and then enables it
       (rmmod and modprobe in a loop). We call 'pt_pirq_reset'
       which checks to see if the softirq has been scheduled.
       Imagine the 'b)' with interrupts in flight and c) getting
       called in a loop.

We will spin up on 'pt_pirq_is_active' (at the start of the
'pt_irq_create_bind') with the event_lock spinlock dropped and
waiting (cpu_relax). We cannot call 'process_pending_softirqs' as it
might result in a dead-lock. hvm_dirq_assist will be executed
and then the softirq will clear 'state' which signals that that we
can re-use the 'hvm_pirq_dpci' structure. In case this softirq
is scheduled on a remote CPU the softirq will run on it as the
semantics behind an softirq is that it will execute within the
guest interruption.

     - we hit once the error paths in 'pt_irq_create_bind' while
       an interrupt was triggered and softirq was scheduled.

If the softirq is in STATE_RUN that means it is executing and we should
let it continue on. We can clear the '->dom' field as the softirq
has stashed it beforehand. If the softirq is STATE_SCHED and
we are successful in clearing it, we do the ref-counting and
clear the '->dom' field. Otherwise we let the softirq continue
on and the '->dom' field is left intact. The clearing of
the '->dom' is left to a), b) or again c) case.

Note that in both cases the 'flags' variable is cleared so
hvm_dirq_assist won't actually do anything.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: Jan Beulich <JBeulich@suse.com>

---
v2: On top of ref-cnts also have wait loop for the outstanding
    'struct domain' that need to be processed.
v3: Add -ERETRY, fix up StyleGuide issues
v4: Clean it up mode, redo per_cpu, this_cpu logic
v5: Instead of threading struct domain, use hvm_pirq_dpci.
v6: Ditch the 'state' bit, expand description, simplify
    softirq and teardown sequence.
v7: Flesh out the comments. Drop the use of domain refcounts
v8: Add two bits (STATE_[SCHED|RUN]) to allow refcounts.
v9: Use cmpxchg, ASSSERT, fix up comments per Jan.
v10: Fix up issues spotted by Jan.
v11: IPI the remote CPU (once) if it it has the softirq scheduled.
v12: Remove the IPI for the remote CPU as the sofitrq mechanism does that.
v13: Clarify comments.
---
 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 251 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  31 ++++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 254 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..73d01bb 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1965,7 +1965,9 @@ int domain_relinquish_resources(struct domain *d)
     switch ( d->arch.relmem )
     {
     case RELMEM_not_started:
-        pci_release_devices(d);
+        ret = pci_release_devices(d);
+        if ( ret )
+            return ret;
 
         /* Tear down paging-assistance stuff. */
         ret = paging_teardown(d);
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index dceb17e..b61dbd6 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -20,14 +20,116 @@
 
 #include <xen/event.h>
 #include <xen/iommu.h>
+#include <xen/cpu.h>
 #include <xen/irq.h>
 #include <asm/hvm/irq.h>
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
-#include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long arg);
+static DEFINE_PER_CPU(struct list_head, dpci_list);
+
+/*
+ * These two bit states help to safely schedule, deschedule, and wait until
+ * the softirq has finished.
+ *
+ * The semantics behind these two bits is as follow:
+ *  - STATE_SCHED - whoever modifies it has to ref-count the domain (->dom).
+ *  - STATE_RUN - only softirq is allowed to set and clear it. If it has
+ *      been set hvm_dirq_assist will RUN with a saved value of the
+ *      'struct domain' copied from 'pirq_dpci->dom' before STATE_RUN was set.
+ *
+ * The usual states are: STATE_SCHED(set) -> STATE_RUN(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(unset).
+ *
+ * However the states can also diverge such as: STATE_SCHED(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(set) -> STATE_RUN(unset). That means
+ * the 'hvm_dirq_assist' never run and that the softirq did not do any
+ * ref-counting.
+ */
+
+enum {
+    STATE_SCHED,
+    STATE_RUN
+};
+
+/*
+ * This can be called multiple times, but the softirq is only raised once.
+ * That is until the STATE_SCHED state has been cleared. The state can be
+ * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
+ * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
+ * the softirq had a chance to run).
+ */
+static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
+{
+    unsigned long flags;
+
+    if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+        return;
+
+    get_knownalive_domain(pirq_dpci->dom);
+
+    local_irq_save(flags);
+    list_add_tail(&pirq_dpci->softirq_list, &this_cpu(dpci_list));
+    local_irq_restore(flags);
+
+    raise_softirq(HVM_DPCI_SOFTIRQ);
+}
+
+/*
+ * If we are racing with softirq_dpci (STATE_SCHED) we return
+ * true. Otherwise we return false.
+ *
+ * If it is false, it is the callers responsibility to make sure
+ * that the softirq (with the event_lock dropped) has ran.
+ */
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
+{
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+        return 1;
+
+    /*
+     * If in the future we would call 'raise_softirq_for' right away
+     * after 'pt_pirq_softirq_active' we MUST reset the list (otherwise it
+     * might have stale data).
+     */
+    return 0;
+}
+
+/*
+ * Reset the pirq_dpci->dom parameter to NULL.
+ *
+ * This function checks the different states to make sure it can do it
+ * at the right time. If it unschedules the 'hvm_dirq_assist' from running
+ * it also refcounts (which is what the softirq would have done) properly.
+ */
+static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+{
+    struct domain *d = pirq_dpci->dom;
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    {
+    case (1 << STATE_SCHED):
+        /*
+         * We are going to try to de-schedule the softirq before it goes in
+         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
+         */
+        put_domain(d);
+        /* fallthrough. */
+    case (1 << STATE_RUN):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED):
+        /*
+         * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
+         * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
+         * in local variable before it sets STATE_RUN - and therefore will not
+         * dereference '->dom' which would crash.
+         */
+        pirq_dpci->dom = NULL;
+        break;
+    }
+}
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -40,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->masked = 0;
+        pirq_dpci->state = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -101,6 +203,7 @@ int pt_irq_create_bind(
     if ( pirq < 0 || pirq >= d->nr_pirqs )
         return -EINVAL;
 
+ restart:
     spin_lock(&d->event_lock);
 
     hvm_irq_dpci = domain_get_irq_dpci(d);
@@ -127,7 +230,20 @@ int pt_irq_create_bind(
         return -ENOMEM;
     }
     pirq_dpci = pirq_dpci(info);
-
+    /*
+     * A crude 'while' loop with us dropping the spinlock and giving
+     * the softirq_dpci a chance to run.
+     * We MUST check for this condition as the softirq could be scheduled
+     * and hasn't run yet. Note that this code replaced tasklet_kill which
+     * would have spun forever and would do the same thing (wait to flush out
+     * outstanding hvm_dirq_assist calls.
+     */
+    if ( pt_pirq_softirq_active(pirq_dpci) )
+    {
+        spin_unlock(&d->event_lock);
+        cpu_relax();
+        goto restart;
+    }
     switch ( pt_irq_bind->irq_type )
     {
     case PT_IRQ_TYPE_MSI:
@@ -159,7 +275,16 @@ int pt_irq_create_bind(
             {
                 rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
                 if ( unlikely(rc) )
+                {
                     pirq_guest_unbind(d, info);
+                    /*
+                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
+                     * an interrupt can be scheduled. No more of them are going
+                     * to be scheduled but we must deal with the one that may be
+                     * in the queue.
+                     */
+                    pt_pirq_softirq_reset(pirq_dpci);
+                }
             }
             if ( unlikely(rc) )
             {
@@ -269,6 +394,10 @@ int pt_irq_create_bind(
             {
                 if ( pt_irq_need_timer(pirq_dpci->flags) )
                     kill_timer(&pirq_dpci->timer);
+                /*
+                 * There is no path for __do_IRQ to schedule softirq as
+                 * IRQ_GUEST is not set. As such we can reset 'dom' directly.
+                 */
                 pirq_dpci->dom = NULL;
                 list_del(&girq->list);
                 list_del(&digl->list);
@@ -402,8 +531,13 @@ int pt_irq_destroy_bind(
         msixtbl_pt_unregister(d, pirq);
         if ( pt_irq_need_timer(pirq_dpci->flags) )
             kill_timer(&pirq_dpci->timer);
-        pirq_dpci->dom   = NULL;
         pirq_dpci->flags = 0;
+        /*
+         * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
+         * call to pt_pirq_softirq_reset.
+         */
+        pt_pirq_softirq_reset(pirq_dpci);
+
         pirq_cleanup_check(pirq, d);
     }
 
@@ -426,14 +560,12 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
-    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    if ( !dpci->flags )
+    if ( !dpci->flags && !pt_pirq_softirq_active(dpci) )
     {
-        tasklet_kill(&dpci->tasklet);
         dpci->dom = NULL;
         return 1;
     }
@@ -476,8 +608,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
-    pirq_dpci->masked = 1;
-    tasklet_schedule(&pirq_dpci->tasklet);
+    raise_softirq_for(pirq_dpci);
     return 1;
 }
 
@@ -531,28 +662,12 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static void hvm_dirq_assist(unsigned long arg)
+static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
 {
-    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
-    struct domain *d = pirq_dpci->dom;
-
-    /*
-     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
-     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
-     *
-     * And '->dom' gets cleared later in the destroy path. We exit and clear
-     * 'masked' - which is OK as later in this code we would
-     * do nothing except clear the ->masked field anyhow.
-     */
-    if ( !d )
-    {
-        pirq_dpci->masked = 0;
-        return;
-    }
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( test_and_clear_bool(pirq_dpci->masked) )
+    if ( pirq_dpci->state )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
@@ -654,3 +769,83 @@ void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
 unlock:
     spin_unlock(&d->event_lock);
 }
+
+/*
+ * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
+ * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
+ */
+static void dpci_softirq(void)
+{
+    unsigned int cpu = smp_processor_id();
+    LIST_HEAD(our_list);
+
+    local_irq_disable();
+    list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
+    local_irq_enable();
+
+    while ( !list_empty(&our_list) )
+    {
+        struct hvm_pirq_dpci *pirq_dpci;
+        struct domain *d;
+
+        pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
+        list_del(&pirq_dpci->softirq_list);
+
+        d = pirq_dpci->dom;
+        smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
+        if ( test_and_set_bit(STATE_RUN, &pirq_dpci->state) )
+            BUG();
+        /*
+         * The one who clears STATE_SCHED MUST refcount the domain.
+         */
+        if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )
+        {
+            hvm_dirq_assist(d, pirq_dpci);
+            put_domain(d);
+        }
+        clear_bit(STATE_RUN, &pirq_dpci->state);
+    }
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        /*
+         * On CPU_DYING this callback is called (on the CPU that is dying)
+         * with an possible HVM_DPIC_SOFTIRQ pending - at which point we can
+         * clear out any outstanding domains (by the virtue of the idle loop
+         * calling the softirq later). In CPU_DEAD case the CPU is deaf and
+         * there are no pending softirqs for us to handle so we can chill.
+         */
+        ASSERT(list_empty(&per_cpu(dpci_list, cpu)));
+        break;
+    }
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback,
+};
+
+static int __init setup_dpci_softirq(void)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu(cpu)
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+
+    open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+__initcall(setup_dpci_softirq);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 81e8a3a..78c6977 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,40 +767,51 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
-    tasklet_kill(&pirq_dpci->tasklet);
-
-    return 0;
+    return pt_pirq_softirq_active(pirq_dpci) ? -ERESTART : 0;
 }
 
-static void pci_clean_dpci_irqs(struct domain *d)
+static int pci_clean_dpci_irqs(struct domain *d)
 {
     struct hvm_irq_dpci *hvm_irq_dpci = NULL;
 
     if ( !iommu_enabled )
-        return;
+        return 0;
 
     if ( !is_hvm_domain(d) )
-        return;
+        return 0;
 
     spin_lock(&d->event_lock);
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+        int ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+
+        if ( ret )
+        {
+            spin_unlock(&d->event_lock);
+            return ret;
+        }
 
         d->arch.hvm_domain.irq.dpci = NULL;
         free_hvm_irq_dpci(hvm_irq_dpci);
     }
     spin_unlock(&d->event_lock);
+    return 0;
 }
 
-void pci_release_devices(struct domain *d)
+int pci_release_devices(struct domain *d)
 {
     struct pci_dev *pdev;
     u8 bus, devfn;
+    int ret;
 
     spin_lock(&pcidevs_lock);
-    pci_clean_dpci_irqs(d);
+    ret = pci_clean_dpci_irqs(d);
+    if ( ret )
+    {
+        spin_unlock(&pcidevs_lock);
+        return ret;
+    }
     while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
     {
         bus = pdev->bus;
@@ -811,6 +822,8 @@ void pci_release_devices(struct domain *d)
                    PCI_SLOT(devfn), PCI_FUNC(devfn));
     }
     spin_unlock(&pcidevs_lock);
+
+    return 0;
 }
 
 #define PCI_CLASS_BRIDGE_HOST    0x0600
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 7225dea..ec787d6 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -7,7 +7,8 @@
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
-#define NR_ARCH_SOFTIRQS       5
+#define HVM_DPCI_SOFTIRQ       (NR_COMMON_SOFTIRQS + 5)
+#define NR_ARCH_SOFTIRQS       6
 
 bool_t arch_skip_send_event_check(unsigned int cpu);
 
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 94a550a..9709397 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -93,13 +93,13 @@ struct hvm_irq_dpci {
 /* Machine IRQ to guest device/intx mapping. */
 struct hvm_pirq_dpci {
     uint32_t flags;
-    bool_t masked;
+    unsigned int state;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
-    struct tasklet tasklet;
+    struct list_head softirq_list;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
@@ -109,6 +109,7 @@ int pt_pirq_iterate(struct domain *d,
                               struct hvm_pirq_dpci *, void *arg),
                     void *arg);
 
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *);
 /* Modify state of a PCI INTx wire. */
 void hvm_pci_intx_assert(
     struct domain *d, unsigned int device, unsigned int intx);
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 91520bc..5f295f3 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -99,7 +99,7 @@ struct pci_dev *pci_lock_domain_pdev(
 
 void setup_hwdom_pci_devices(struct domain *,
                             int (*)(u8 devfn, struct pci_dev *));
-void pci_release_devices(struct domain *d);
+int pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
 const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
-- 
1.9.3

> 
> Jan
> 

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-dpci-Replace-tasklet-with-an-softirq-v13.patch"

>From b4cdb5365d9d254c87b82bc3df794c935c682541 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 23 Oct 2014 20:41:24 -0400
Subject: [PATCH] dpci: Replace tasklet with an softirq (v13)

The existing tasklet mechanism has a single global
spinlock that is taken every-time the global list
is touched. And we use this lock quite a lot - when
we call do_tasklet_work which is called via an softirq
and from the idle loop. We take the lock on any
operation on the tasklet_list.

The problem we are facing is that there are quite a lot of
tasklets scheduled. The most common one that is invoked is
the one injecting the VIRQ_TIMER in the guest. Guests
are not insane and don't set the one-shot or periodic
clocks to be in sub 1ms intervals (causing said tasklet
to be scheduled for such small intervalls).

The problem appears when PCI passthrough devices are used
over many sockets and we have an mix of heavy-interrupt
guests and idle guests. The idle guests end up seeing
1/10 of its RUNNING timeslice eaten by the hypervisor
(and 40% steal time).

The mechanism by which we inject PCI interrupts is by
hvm_do_IRQ_dpci which schedules the hvm_dirq_assist
tasklet every time an interrupt is received.
The callchain is:

_asm_vmexit_handler
 -> vmx_vmexit_handler
    ->vmx_do_extint
        -> do_IRQ
            -> __do_IRQ_guest
                -> hvm_do_IRQ_dpci
                   tasklet_schedule(&dpci->dirq_tasklet);
                   [takes lock to put the tasklet on]

[later on the schedule_tail is invoked which is 'vmx_do_resume']

vmx_do_resume
 -> vmx_asm_do_vmentry
        -> call vmx_intr_assist
          -> vmx_process_softirqs
            -> do_softirq
              [executes the tasklet function, takes the
               lock again]

While on other CPUs they might be sitting in a idle loop
and invoked to deliver an VIRQ_TIMER, which also ends
up taking the lock twice: first to schedule the
v->arch.hvm_vcpu.assert_evtchn_irq_tasklet (accounted to
the guests' BLOCKED_state); then to execute it - which is
accounted for in the guest's RUNTIME_state.

The end result is that on a 8 socket machine with
PCI passthrough, where four sockets are busy with interrupts,
and the other sockets have idle guests - we end up with
the idle guests having around 40% steal time and 1/10
of its timeslice (3ms out of 30 ms) being tied up
taking the lock. The latency of the PCI interrupts delieved
to guest is also hindered.

With this patch the problem disappears completly.
That is removing the lock for the PCI passthrough use-case
(the 'hvm_dirq_assist' case) by not using tasklets at all.

The patch is simple - instead of scheduling an tasklet
we schedule our own softirq - HVM_DPCI_SOFTIRQ, which will
take care of running 'hvm_dirq_assist'. The information we need
on each CPU is which 'struct hvm_pirq_dpci' structure the
'hvm_dirq_assist' needs to run on. That is simple solved by
threading the 'struct hvm_pirq_dpci' through a linked list.
The rule of only running one 'hvm_dirq_assist' for only
one 'hvm_pirq_dpci' is also preserved by having
'schedule_dpci_for' ignore any subsequent calls for an domain
which has already been scheduled.

== Code details ==

Most of the code complexity comes from the '->dom' field
in the 'hvm_pirq_dpci' structure. We use it for ref-counting
and as such it MUST be valid as long as STATE_SCHED bit is
set. Whoever clears the STATE_SCHED bit does the ref-counting
and can also reset the '->dom' field.

To compound the complexity, there are multiple points where the
'hvm_pirq_dpci' structure is reset or re-used. Initially
(first time the domain uses the pirq), the 'hvm_pirq_dpci->dom'
field is set to NULL as it is allocated. On subsequent calls
in to 'pt_irq_create_bind' the ->dom is whatever it had last time.

As this is the initial call (which QEMU ends up calling when the
guest writes an vector value in the MSI field) we MUST set the
'->dom' to a the proper structure (otherwise we cannot do
proper ref-counting).

The mechanism to tear it down is more complex as there
are three ways it can be executed. To make it simpler
everything revolves around 'pt_pirq_softirq_active'. If it
returns -EAGAIN that means there is an outstanding softirq
that needs to finish running before we can continue tearing
down. With that in mind:

a) pci_clean_dpci_irq. This gets called when the guest is
   being destroyed. We end up calling 'pt_pirq_softirq_active'
   to see if it is OK to continue the destruction.

   The scenarios in which the 'struct pirq' (and subsequently
   the 'hvm_pirq_dpci') gets destroyed is when:

   - guest did not use the pirq at all after setup.
   - guest did use pirq, but decided to mask and left it in that
     state.
   - guest did use pirq, but crashed.

   In all of those scenarios we end up calling
   'pt_pirq_softirq_active' to check if the softirq is still
   active. Read below on the 'pt_pirq_softirq_active' loop.

b) pt_irq_destroy_bind (guest disables the MSI). We double-check
   that the softirq has run by piggy-backing on the existing
   'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
   We add the extra call to 'pt_pirq_softirq_active' in
   'pt_pirq_cleanup_check'.

   NOTE: Guests that use event channels unbind first the
   event channel from PIRQs, so the 'pt_pirq_cleanup_check'
   won't be called as 'event' is set to zero. In that case
   we either clean it up via the a) or c) mechanism.

   There is an extra scenario regardless of 'event' being
   set or not: the guest did 'pt_irq_destroy_bind' while an
   interrupt was triggered and softirq was scheduled (but had not
   been run). It is OK to still run the softirq as
   hvm_dirq_assist won't do anything (as the flags are
   set to zero). However we will try to deschedule the
   softirq if we can (by clearing the STATE_SCHED bit and us
   doing the ref-counting).

c) pt_irq_create_bind (not a typo). The scenarios are:

     - guest disables the MSI and then enables it
       (rmmod and modprobe in a loop). We call 'pt_pirq_reset'
       which checks to see if the softirq has been scheduled.
       Imagine the 'b)' with interrupts in flight and c) getting
       called in a loop.

We will spin up on 'pt_pirq_is_active' (at the start of the
'pt_irq_create_bind') with the event_lock spinlock dropped and
waiting (cpu_relax). We cannot call 'process_pending_softirqs' as it
might result in a dead-lock. hvm_dirq_assist will be executed
and then the softirq will clear 'state' which signals that that we
can re-use the 'hvm_pirq_dpci' structure. In case this softirq
is scheduled on a remote CPU the softirq will run on it as the
semantics behind an softirq is that it will execute within the
guest interruption.

     - we hit once the error paths in 'pt_irq_create_bind' while
       an interrupt was triggered and softirq was scheduled.

If the softirq is in STATE_RUN that means it is executing and we should
let it continue on. We can clear the '->dom' field as the softirq
has stashed it beforehand. If the softirq is STATE_SCHED and
we are successful in clearing it, we do the ref-counting and
clear the '->dom' field. Otherwise we let the softirq continue
on and the '->dom' field is left intact. The clearing of
the '->dom' is left to a), b) or again c) case.

Note that in both cases the 'flags' variable is cleared so
hvm_dirq_assist won't actually do anything.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: Jan Beulich <JBeulich@suse.com>

---
v2: On top of ref-cnts also have wait loop for the outstanding
    'struct domain' that need to be processed.
v3: Add -ERETRY, fix up StyleGuide issues
v4: Clean it up mode, redo per_cpu, this_cpu logic
v5: Instead of threading struct domain, use hvm_pirq_dpci.
v6: Ditch the 'state' bit, expand description, simplify
    softirq and teardown sequence.
v7: Flesh out the comments. Drop the use of domain refcounts
v8: Add two bits (STATE_[SCHED|RUN]) to allow refcounts.
v9: Use cmpxchg, ASSSERT, fix up comments per Jan.
v10: Fix up issues spotted by Jan.
v11: IPI the remote CPU (once) if it it has the softirq scheduled.
v12: Remove the IPI for the remote CPU as the sofitrq mechanism does that.
v13: Clarify comments.
---
 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 251 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  31 ++++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 254 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..73d01bb 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1965,7 +1965,9 @@ int domain_relinquish_resources(struct domain *d)
     switch ( d->arch.relmem )
     {
     case RELMEM_not_started:
-        pci_release_devices(d);
+        ret = pci_release_devices(d);
+        if ( ret )
+            return ret;
 
         /* Tear down paging-assistance stuff. */
         ret = paging_teardown(d);
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index dceb17e..b61dbd6 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -20,14 +20,116 @@
 
 #include <xen/event.h>
 #include <xen/iommu.h>
+#include <xen/cpu.h>
 #include <xen/irq.h>
 #include <asm/hvm/irq.h>
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
-#include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long arg);
+static DEFINE_PER_CPU(struct list_head, dpci_list);
+
+/*
+ * These two bit states help to safely schedule, deschedule, and wait until
+ * the softirq has finished.
+ *
+ * The semantics behind these two bits is as follow:
+ *  - STATE_SCHED - whoever modifies it has to ref-count the domain (->dom).
+ *  - STATE_RUN - only softirq is allowed to set and clear it. If it has
+ *      been set hvm_dirq_assist will RUN with a saved value of the
+ *      'struct domain' copied from 'pirq_dpci->dom' before STATE_RUN was set.
+ *
+ * The usual states are: STATE_SCHED(set) -> STATE_RUN(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(unset).
+ *
+ * However the states can also diverge such as: STATE_SCHED(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(set) -> STATE_RUN(unset). That means
+ * the 'hvm_dirq_assist' never run and that the softirq did not do any
+ * ref-counting.
+ */
+
+enum {
+    STATE_SCHED,
+    STATE_RUN
+};
+
+/*
+ * This can be called multiple times, but the softirq is only raised once.
+ * That is until the STATE_SCHED state has been cleared. The state can be
+ * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
+ * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
+ * the softirq had a chance to run).
+ */
+static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
+{
+    unsigned long flags;
+
+    if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+        return;
+
+    get_knownalive_domain(pirq_dpci->dom);
+
+    local_irq_save(flags);
+    list_add_tail(&pirq_dpci->softirq_list, &this_cpu(dpci_list));
+    local_irq_restore(flags);
+
+    raise_softirq(HVM_DPCI_SOFTIRQ);
+}
+
+/*
+ * If we are racing with softirq_dpci (STATE_SCHED) we return
+ * true. Otherwise we return false.
+ *
+ * If it is false, it is the callers responsibility to make sure
+ * that the softirq (with the event_lock dropped) has ran.
+ */
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
+{
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+        return 1;
+
+    /*
+     * If in the future we would call 'raise_softirq_for' right away
+     * after 'pt_pirq_softirq_active' we MUST reset the list (otherwise it
+     * might have stale data).
+     */
+    return 0;
+}
+
+/*
+ * Reset the pirq_dpci->dom parameter to NULL.
+ *
+ * This function checks the different states to make sure it can do it
+ * at the right time. If it unschedules the 'hvm_dirq_assist' from running
+ * it also refcounts (which is what the softirq would have done) properly.
+ */
+static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+{
+    struct domain *d = pirq_dpci->dom;
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    {
+    case (1 << STATE_SCHED):
+        /*
+         * We are going to try to de-schedule the softirq before it goes in
+         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
+         */
+        put_domain(d);
+        /* fallthrough. */
+    case (1 << STATE_RUN):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED):
+        /*
+         * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
+         * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
+         * in local variable before it sets STATE_RUN - and therefore will not
+         * dereference '->dom' which would crash.
+         */
+        pirq_dpci->dom = NULL;
+        break;
+    }
+}
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -40,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->masked = 0;
+        pirq_dpci->state = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -101,6 +203,7 @@ int pt_irq_create_bind(
     if ( pirq < 0 || pirq >= d->nr_pirqs )
         return -EINVAL;
 
+ restart:
     spin_lock(&d->event_lock);
 
     hvm_irq_dpci = domain_get_irq_dpci(d);
@@ -127,7 +230,20 @@ int pt_irq_create_bind(
         return -ENOMEM;
     }
     pirq_dpci = pirq_dpci(info);
-
+    /*
+     * A crude 'while' loop with us dropping the spinlock and giving
+     * the softirq_dpci a chance to run.
+     * We MUST check for this condition as the softirq could be scheduled
+     * and hasn't run yet. Note that this code replaced tasklet_kill which
+     * would have spun forever and would do the same thing (wait to flush out
+     * outstanding hvm_dirq_assist calls.
+     */
+    if ( pt_pirq_softirq_active(pirq_dpci) )
+    {
+        spin_unlock(&d->event_lock);
+        cpu_relax();
+        goto restart;
+    }
     switch ( pt_irq_bind->irq_type )
     {
     case PT_IRQ_TYPE_MSI:
@@ -159,7 +275,16 @@ int pt_irq_create_bind(
             {
                 rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
                 if ( unlikely(rc) )
+                {
                     pirq_guest_unbind(d, info);
+                    /*
+                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
+                     * an interrupt can be scheduled. No more of them are going
+                     * to be scheduled but we must deal with the one that may be
+                     * in the queue.
+                     */
+                    pt_pirq_softirq_reset(pirq_dpci);
+                }
             }
             if ( unlikely(rc) )
             {
@@ -269,6 +394,10 @@ int pt_irq_create_bind(
             {
                 if ( pt_irq_need_timer(pirq_dpci->flags) )
                     kill_timer(&pirq_dpci->timer);
+                /*
+                 * There is no path for __do_IRQ to schedule softirq as
+                 * IRQ_GUEST is not set. As such we can reset 'dom' directly.
+                 */
                 pirq_dpci->dom = NULL;
                 list_del(&girq->list);
                 list_del(&digl->list);
@@ -402,8 +531,13 @@ int pt_irq_destroy_bind(
         msixtbl_pt_unregister(d, pirq);
         if ( pt_irq_need_timer(pirq_dpci->flags) )
             kill_timer(&pirq_dpci->timer);
-        pirq_dpci->dom   = NULL;
         pirq_dpci->flags = 0;
+        /*
+         * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
+         * call to pt_pirq_softirq_reset.
+         */
+        pt_pirq_softirq_reset(pirq_dpci);
+
         pirq_cleanup_check(pirq, d);
     }
 
@@ -426,14 +560,12 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
-    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    if ( !dpci->flags )
+    if ( !dpci->flags && !pt_pirq_softirq_active(dpci) )
     {
-        tasklet_kill(&dpci->tasklet);
         dpci->dom = NULL;
         return 1;
     }
@@ -476,8 +608,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
-    pirq_dpci->masked = 1;
-    tasklet_schedule(&pirq_dpci->tasklet);
+    raise_softirq_for(pirq_dpci);
     return 1;
 }
 
@@ -531,28 +662,12 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static void hvm_dirq_assist(unsigned long arg)
+static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
 {
-    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
-    struct domain *d = pirq_dpci->dom;
-
-    /*
-     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
-     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
-     *
-     * And '->dom' gets cleared later in the destroy path. We exit and clear
-     * 'masked' - which is OK as later in this code we would
-     * do nothing except clear the ->masked field anyhow.
-     */
-    if ( !d )
-    {
-        pirq_dpci->masked = 0;
-        return;
-    }
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( test_and_clear_bool(pirq_dpci->masked) )
+    if ( pirq_dpci->state )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
@@ -654,3 +769,83 @@ void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
 unlock:
     spin_unlock(&d->event_lock);
 }
+
+/*
+ * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
+ * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
+ */
+static void dpci_softirq(void)
+{
+    unsigned int cpu = smp_processor_id();
+    LIST_HEAD(our_list);
+
+    local_irq_disable();
+    list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
+    local_irq_enable();
+
+    while ( !list_empty(&our_list) )
+    {
+        struct hvm_pirq_dpci *pirq_dpci;
+        struct domain *d;
+
+        pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
+        list_del(&pirq_dpci->softirq_list);
+
+        d = pirq_dpci->dom;
+        smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
+        if ( test_and_set_bit(STATE_RUN, &pirq_dpci->state) )
+            BUG();
+        /*
+         * The one who clears STATE_SCHED MUST refcount the domain.
+         */
+        if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )
+        {
+            hvm_dirq_assist(d, pirq_dpci);
+            put_domain(d);
+        }
+        clear_bit(STATE_RUN, &pirq_dpci->state);
+    }
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        /*
+         * On CPU_DYING this callback is called (on the CPU that is dying)
+         * with an possible HVM_DPIC_SOFTIRQ pending - at which point we can
+         * clear out any outstanding domains (by the virtue of the idle loop
+         * calling the softirq later). In CPU_DEAD case the CPU is deaf and
+         * there are no pending softirqs for us to handle so we can chill.
+         */
+        ASSERT(list_empty(&per_cpu(dpci_list, cpu)));
+        break;
+    }
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback,
+};
+
+static int __init setup_dpci_softirq(void)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu(cpu)
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+
+    open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+__initcall(setup_dpci_softirq);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 81e8a3a..78c6977 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,40 +767,51 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
-    tasklet_kill(&pirq_dpci->tasklet);
-
-    return 0;
+    return pt_pirq_softirq_active(pirq_dpci) ? -ERESTART : 0;
 }
 
-static void pci_clean_dpci_irqs(struct domain *d)
+static int pci_clean_dpci_irqs(struct domain *d)
 {
     struct hvm_irq_dpci *hvm_irq_dpci = NULL;
 
     if ( !iommu_enabled )
-        return;
+        return 0;
 
     if ( !is_hvm_domain(d) )
-        return;
+        return 0;
 
     spin_lock(&d->event_lock);
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+        int ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+
+        if ( ret )
+        {
+            spin_unlock(&d->event_lock);
+            return ret;
+        }
 
         d->arch.hvm_domain.irq.dpci = NULL;
         free_hvm_irq_dpci(hvm_irq_dpci);
     }
     spin_unlock(&d->event_lock);
+    return 0;
 }
 
-void pci_release_devices(struct domain *d)
+int pci_release_devices(struct domain *d)
 {
     struct pci_dev *pdev;
     u8 bus, devfn;
+    int ret;
 
     spin_lock(&pcidevs_lock);
-    pci_clean_dpci_irqs(d);
+    ret = pci_clean_dpci_irqs(d);
+    if ( ret )
+    {
+        spin_unlock(&pcidevs_lock);
+        return ret;
+    }
     while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
     {
         bus = pdev->bus;
@@ -811,6 +822,8 @@ void pci_release_devices(struct domain *d)
                    PCI_SLOT(devfn), PCI_FUNC(devfn));
     }
     spin_unlock(&pcidevs_lock);
+
+    return 0;
 }
 
 #define PCI_CLASS_BRIDGE_HOST    0x0600
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 7225dea..ec787d6 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -7,7 +7,8 @@
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
-#define NR_ARCH_SOFTIRQS       5
+#define HVM_DPCI_SOFTIRQ       (NR_COMMON_SOFTIRQS + 5)
+#define NR_ARCH_SOFTIRQS       6
 
 bool_t arch_skip_send_event_check(unsigned int cpu);
 
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 94a550a..9709397 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -93,13 +93,13 @@ struct hvm_irq_dpci {
 /* Machine IRQ to guest device/intx mapping. */
 struct hvm_pirq_dpci {
     uint32_t flags;
-    bool_t masked;
+    unsigned int state;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
-    struct tasklet tasklet;
+    struct list_head softirq_list;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
@@ -109,6 +109,7 @@ int pt_pirq_iterate(struct domain *d,
                               struct hvm_pirq_dpci *, void *arg),
                     void *arg);
 
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *);
 /* Modify state of a PCI INTx wire. */
 void hvm_pci_intx_assert(
     struct domain *d, unsigned int device, unsigned int intx);
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 91520bc..5f295f3 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -99,7 +99,7 @@ struct pci_dev *pci_lock_domain_pdev(
 
 void setup_hwdom_pci_devices(struct domain *,
                             int (*)(u8 devfn, struct pci_dev *));
-void pci_release_devices(struct domain *d);
+int pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
 const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
-- 
1.9.3


--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--MGYHOYXEY6WxJCY8--


From xen-devel-bounces@lists.xen.org Mon Nov 10 21:11:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21:11:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnwFG-0005MW-Mz; Mon, 10 Nov 2014 21:11:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mengxu@cis.upenn.edu>) id 1XnwFF-0005ML-8O
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 21:11:29 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	8D/AA-17694-00A21645; Mon, 10 Nov 2014 21:11:28 +0000
X-Env-Sender: mengxu@cis.upenn.edu
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415653887!9216839!1
X-Originating-IP: [158.130.68.118]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 835 invoked from network); 10 Nov 2014 21:11:27 -0000
Received: from renard.seas.upenn.edu (HELO fox.seas.upenn.edu) (158.130.68.118)
	by server-14.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 21:11:27 -0000
Received: from localhost.localdomain ([158.130.111.128]) (authenticated bits=0)
	by fox.seas.upenn.edu (8.14.5/8.14.5) with ESMTP id sAALBC9D004413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 10 Nov 2014 16:11:16 -0500
From: Meng Xu <mengxu@cis.upenn.edu>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:11:10 -0500
Message-Id: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
X-Mailer: git-send-email 1.7.9.5
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=5800
	signatures=585085
X-PP-Spam-Details: rule=add_spam_details policy=default score=0 spamscore=0
	ipscore=0
	suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam
	adjust=0 reason=mlx scancount=1 engine=7.0.1-1111160001
	definitions=main-1411100160
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	george.dunlap@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, konrad.r.wilk@gmail.com, xumengpanda@gmail.com
Subject: [Xen-devel] [PATCH for Xen 4.5 v3 0/2] Sanity check input and
	serialize vcpu data in sched_rt.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>
MIME-Version: 1.0
Content-Type: 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 solution is summarized by Dario Faggioli at http://lists.xen.org/archives/html/xen-devel/2014-09/msg03603.html.

Here is the solution:
     - sanity checking input params in rt_dom_cntl()
     - serialize rt_dom_cntl() itself against the global lock
     - move the call to rt_update_deadline() from _alloc to _insert

Here is a history of the patch set:
    v1: first patch to implement the solution by replying the thread; request for comment.
    v2: properly lock the data as proposed in the solution; 
    v3: add comments to the commit log to better explain the reason of the implementation.

The whole patch set is:
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

[PATCH for Xen 4.5 v3 1/2] xen: sanity check input and serialization
    Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
    Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
[PATCH for Xen 4.5 v3 2/2] xen: serialize vcpu data in sched_rt.c
    Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>


---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 21:11:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21:11:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnwFI-0005Mw-DT; Mon, 10 Nov 2014 21:11:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mengxu@cis.upenn.edu>) id 1XnwFH-0005MV-7b
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 21:11:31 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	26/1A-17958-20A21645; Mon, 10 Nov 2014 21:11:30 +0000
X-Env-Sender: mengxu@cis.upenn.edu
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415653889!11701203!1
X-Originating-IP: [158.130.68.118]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9577 invoked from network); 10 Nov 2014 21:11:29 -0000
Received: from renard.seas.upenn.edu (HELO fox.seas.upenn.edu) (158.130.68.118)
	by server-5.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 21:11:29 -0000
Received: from localhost.localdomain ([158.130.111.128]) (authenticated bits=0)
	by fox.seas.upenn.edu (8.14.5/8.14.5) with ESMTP id sAALBC9F004413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 10 Nov 2014 16:11:17 -0500
From: Meng Xu <mengxu@cis.upenn.edu>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:11:12 -0500
Message-Id: <1415653872-2232-3-git-send-email-mengxu@cis.upenn.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
References: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=5800
	signatures=585085
X-Proofpoint-Spam-Reason: safe
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	george.dunlap@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, konrad.r.wilk@gmail.com,
	xumengpanda@gmail.com, Meng Xu <mengxu@cis.upenn.edu>
Subject: [Xen-devel] [PATCH for Xen 4.5 v3 2/2] xen: serialize vcpu data in
	sched_rt.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fix the following two issues in rtds scheduler:
1) The runq queue lock is not grabbed when rt_update_deadline is
called in rt_alloc_vdata function, which may cause race condition;
Solution: Move call to rt_update_deadline from _alloc to _insert;
Note: rt_alloc_vdata does not need grab the runq lock, because only one
cpu will allocate the rt_vcpu; before the rt_vcpu is inserted into the
runq, no more than one cpu operates on the rt_vcpu.

2) rt_vcpu_remove should grab the runq lock before remove the vcpu
from runq; otherwise, race condition may happen.
Solution: Add lock in rt_vcpu_remove().

Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
---
 xen/common/sched_rt.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 8251e41..e70d6c7 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -508,7 +508,6 @@ static void *
 rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
 {
     struct rt_vcpu *svc;
-    s_time_t now = NOW();
 
     /* Allocate per-VCPU info */
     svc = xzalloc(struct rt_vcpu);
@@ -526,10 +525,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
     if ( !is_idle_vcpu(vc) )
         svc->budget = RTDS_DEFAULT_BUDGET;
 
-    ASSERT( now >= svc->cur_deadline );
-
-    rt_update_deadline(now, svc);
-
     return svc;
 }
 
@@ -552,11 +547,15 @@ static void
 rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
 {
     struct rt_vcpu *svc = rt_vcpu(vc);
+    s_time_t now = NOW();
 
     /* not addlocate idle vcpu to dom vcpu list */
     if ( is_idle_vcpu(vc) )
         return;
 
+    if ( now >= svc->cur_deadline )
+        rt_update_deadline(now, svc);
+
     if ( !__vcpu_on_q(svc) && vcpu_runnable(vc) && !vc->is_running )
         __runq_insert(ops, svc);
 
@@ -573,11 +572,14 @@ rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
 {
     struct rt_vcpu * const svc = rt_vcpu(vc);
     struct rt_dom * const sdom = svc->sdom;
+    spinlock_t *lock;
 
     BUG_ON( sdom == NULL );
 
+    lock = vcpu_schedule_lock_irq(vc);
     if ( __vcpu_on_q(svc) )
         __q_remove(svc);
+    vcpu_schedule_unlock_irq(lock, vc);
 
     if ( !is_idle_vcpu(vc) )
         list_del_init(&svc->sdom_elem);
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 21:11:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21:11:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnwFH-0005Md-1T; Mon, 10 Nov 2014 21:11:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mengxu@cis.upenn.edu>) id 1XnwFF-0005MM-Lp
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 21:11:29 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	B7/9F-27623-00A21645; Mon, 10 Nov 2014 21:11:28 +0000
X-Env-Sender: mengxu@cis.upenn.edu
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415653888!11704973!1
X-Originating-IP: [158.130.68.118]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 800 invoked from network); 10 Nov 2014 21:11:28 -0000
Received: from renard.seas.upenn.edu (HELO fox.seas.upenn.edu) (158.130.68.118)
	by server-3.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 21:11:28 -0000
Received: from localhost.localdomain ([158.130.111.128]) (authenticated bits=0)
	by fox.seas.upenn.edu (8.14.5/8.14.5) with ESMTP id sAALBC9E004413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 10 Nov 2014 16:11:16 -0500
From: Meng Xu <mengxu@cis.upenn.edu>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:11:11 -0500
Message-Id: <1415653872-2232-2-git-send-email-mengxu@cis.upenn.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
References: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=5800
	signatures=585085
X-Proofpoint-Spam-Reason: safe
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	george.dunlap@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, konrad.r.wilk@gmail.com,
	xumengpanda@gmail.com, Meng Xu <mengxu@cis.upenn.edu>
Subject: [Xen-devel] [PATCH for Xen 4.5 v3 1/2] xen: sanity check input and
	serialization in sched_rt.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sanity check input params in rt_dom_cntl();
Serialize rt_dom_cntl() against the global lock.

Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_rt.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 6c8faeb..8251e41 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -1042,25 +1042,36 @@ rt_dom_cntl(
     struct domain *d,
     struct xen_domctl_scheduler_op *op)
 {
+    struct rt_private *prv = rt_priv(ops);
     struct rt_dom * const sdom = rt_dom(d);
     struct rt_vcpu *svc;
     struct list_head *iter;
+    unsigned long flags;
     int rc = 0;
 
     switch ( op->cmd )
     {
     case XEN_DOMCTL_SCHEDOP_getinfo:
+        spin_lock_irqsave(&prv->lock, flags);
         svc = list_entry(sdom->vcpu.next, struct rt_vcpu, sdom_elem);
         op->u.rtds.period = svc->period / MICROSECS(1); /* transfer to us */
         op->u.rtds.budget = svc->budget / MICROSECS(1);
+        spin_unlock_irqrestore(&prv->lock, flags);
         break;
     case XEN_DOMCTL_SCHEDOP_putinfo:
+        if ( op->u.rtds.period == 0 || op->u.rtds.budget == 0 )
+        {
+            rc = -EINVAL;
+            break;
+        }
+        spin_lock_irqsave(&prv->lock, flags);
         list_for_each( iter, &sdom->vcpu )
         {
             struct rt_vcpu * svc = list_entry(iter, struct rt_vcpu, sdom_elem);
             svc->period = MICROSECS(op->u.rtds.period); /* transfer to nanosec */
             svc->budget = MICROSECS(op->u.rtds.budget);
         }
+        spin_unlock_irqrestore(&prv->lock, flags);
         break;
     }
 
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 21:11:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21:11:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnwFH-0005Md-1T; Mon, 10 Nov 2014 21:11:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mengxu@cis.upenn.edu>) id 1XnwFF-0005MM-Lp
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 21:11:29 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	B7/9F-27623-00A21645; Mon, 10 Nov 2014 21:11:28 +0000
X-Env-Sender: mengxu@cis.upenn.edu
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415653888!11704973!1
X-Originating-IP: [158.130.68.118]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 800 invoked from network); 10 Nov 2014 21:11:28 -0000
Received: from renard.seas.upenn.edu (HELO fox.seas.upenn.edu) (158.130.68.118)
	by server-3.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 21:11:28 -0000
Received: from localhost.localdomain ([158.130.111.128]) (authenticated bits=0)
	by fox.seas.upenn.edu (8.14.5/8.14.5) with ESMTP id sAALBC9E004413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 10 Nov 2014 16:11:16 -0500
From: Meng Xu <mengxu@cis.upenn.edu>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:11:11 -0500
Message-Id: <1415653872-2232-2-git-send-email-mengxu@cis.upenn.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
References: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=5800
	signatures=585085
X-Proofpoint-Spam-Reason: safe
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	george.dunlap@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, konrad.r.wilk@gmail.com,
	xumengpanda@gmail.com, Meng Xu <mengxu@cis.upenn.edu>
Subject: [Xen-devel] [PATCH for Xen 4.5 v3 1/2] xen: sanity check input and
	serialization in sched_rt.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sanity check input params in rt_dom_cntl();
Serialize rt_dom_cntl() against the global lock.

Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_rt.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 6c8faeb..8251e41 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -1042,25 +1042,36 @@ rt_dom_cntl(
     struct domain *d,
     struct xen_domctl_scheduler_op *op)
 {
+    struct rt_private *prv = rt_priv(ops);
     struct rt_dom * const sdom = rt_dom(d);
     struct rt_vcpu *svc;
     struct list_head *iter;
+    unsigned long flags;
     int rc = 0;
 
     switch ( op->cmd )
     {
     case XEN_DOMCTL_SCHEDOP_getinfo:
+        spin_lock_irqsave(&prv->lock, flags);
         svc = list_entry(sdom->vcpu.next, struct rt_vcpu, sdom_elem);
         op->u.rtds.period = svc->period / MICROSECS(1); /* transfer to us */
         op->u.rtds.budget = svc->budget / MICROSECS(1);
+        spin_unlock_irqrestore(&prv->lock, flags);
         break;
     case XEN_DOMCTL_SCHEDOP_putinfo:
+        if ( op->u.rtds.period == 0 || op->u.rtds.budget == 0 )
+        {
+            rc = -EINVAL;
+            break;
+        }
+        spin_lock_irqsave(&prv->lock, flags);
         list_for_each( iter, &sdom->vcpu )
         {
             struct rt_vcpu * svc = list_entry(iter, struct rt_vcpu, sdom_elem);
             svc->period = MICROSECS(op->u.rtds.period); /* transfer to nanosec */
             svc->budget = MICROSECS(op->u.rtds.budget);
         }
+        spin_unlock_irqrestore(&prv->lock, flags);
         break;
     }
 
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 21:11:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21:11:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnwFG-0005MW-Mz; Mon, 10 Nov 2014 21:11:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mengxu@cis.upenn.edu>) id 1XnwFF-0005ML-8O
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 21:11:29 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	8D/AA-17694-00A21645; Mon, 10 Nov 2014 21:11:28 +0000
X-Env-Sender: mengxu@cis.upenn.edu
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415653887!9216839!1
X-Originating-IP: [158.130.68.118]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 835 invoked from network); 10 Nov 2014 21:11:27 -0000
Received: from renard.seas.upenn.edu (HELO fox.seas.upenn.edu) (158.130.68.118)
	by server-14.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 21:11:27 -0000
Received: from localhost.localdomain ([158.130.111.128]) (authenticated bits=0)
	by fox.seas.upenn.edu (8.14.5/8.14.5) with ESMTP id sAALBC9D004413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 10 Nov 2014 16:11:16 -0500
From: Meng Xu <mengxu@cis.upenn.edu>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:11:10 -0500
Message-Id: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
X-Mailer: git-send-email 1.7.9.5
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=5800
	signatures=585085
X-PP-Spam-Details: rule=add_spam_details policy=default score=0 spamscore=0
	ipscore=0
	suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam
	adjust=0 reason=mlx scancount=1 engine=7.0.1-1111160001
	definitions=main-1411100160
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	george.dunlap@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, konrad.r.wilk@gmail.com, xumengpanda@gmail.com
Subject: [Xen-devel] [PATCH for Xen 4.5 v3 0/2] Sanity check input and
	serialize vcpu data in sched_rt.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>
MIME-Version: 1.0
Content-Type: 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 solution is summarized by Dario Faggioli at http://lists.xen.org/archives/html/xen-devel/2014-09/msg03603.html.

Here is the solution:
     - sanity checking input params in rt_dom_cntl()
     - serialize rt_dom_cntl() itself against the global lock
     - move the call to rt_update_deadline() from _alloc to _insert

Here is a history of the patch set:
    v1: first patch to implement the solution by replying the thread; request for comment.
    v2: properly lock the data as proposed in the solution; 
    v3: add comments to the commit log to better explain the reason of the implementation.

The whole patch set is:
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

[PATCH for Xen 4.5 v3 1/2] xen: sanity check input and serialization
    Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
    Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
[PATCH for Xen 4.5 v3 2/2] xen: serialize vcpu data in sched_rt.c
    Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>


---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 21:11:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21:11:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnwFI-0005Mw-DT; Mon, 10 Nov 2014 21:11:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mengxu@cis.upenn.edu>) id 1XnwFH-0005MV-7b
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 21:11:31 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	26/1A-17958-20A21645; Mon, 10 Nov 2014 21:11:30 +0000
X-Env-Sender: mengxu@cis.upenn.edu
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415653889!11701203!1
X-Originating-IP: [158.130.68.118]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9577 invoked from network); 10 Nov 2014 21:11:29 -0000
Received: from renard.seas.upenn.edu (HELO fox.seas.upenn.edu) (158.130.68.118)
	by server-5.tower-31.messagelabs.com with SMTP;
	10 Nov 2014 21:11:29 -0000
Received: from localhost.localdomain ([158.130.111.128]) (authenticated bits=0)
	by fox.seas.upenn.edu (8.14.5/8.14.5) with ESMTP id sAALBC9F004413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 10 Nov 2014 16:11:17 -0500
From: Meng Xu <mengxu@cis.upenn.edu>
To: xen-devel@lists.xen.org
Date: Mon, 10 Nov 2014 16:11:12 -0500
Message-Id: <1415653872-2232-3-git-send-email-mengxu@cis.upenn.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
References: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=5800
	signatures=585085
X-Proofpoint-Spam-Reason: safe
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	george.dunlap@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, konrad.r.wilk@gmail.com,
	xumengpanda@gmail.com, Meng Xu <mengxu@cis.upenn.edu>
Subject: [Xen-devel] [PATCH for Xen 4.5 v3 2/2] xen: serialize vcpu data in
	sched_rt.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fix the following two issues in rtds scheduler:
1) The runq queue lock is not grabbed when rt_update_deadline is
called in rt_alloc_vdata function, which may cause race condition;
Solution: Move call to rt_update_deadline from _alloc to _insert;
Note: rt_alloc_vdata does not need grab the runq lock, because only one
cpu will allocate the rt_vcpu; before the rt_vcpu is inserted into the
runq, no more than one cpu operates on the rt_vcpu.

2) rt_vcpu_remove should grab the runq lock before remove the vcpu
from runq; otherwise, race condition may happen.
Solution: Add lock in rt_vcpu_remove().

Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
---
 xen/common/sched_rt.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 8251e41..e70d6c7 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -508,7 +508,6 @@ static void *
 rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
 {
     struct rt_vcpu *svc;
-    s_time_t now = NOW();
 
     /* Allocate per-VCPU info */
     svc = xzalloc(struct rt_vcpu);
@@ -526,10 +525,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
     if ( !is_idle_vcpu(vc) )
         svc->budget = RTDS_DEFAULT_BUDGET;
 
-    ASSERT( now >= svc->cur_deadline );
-
-    rt_update_deadline(now, svc);
-
     return svc;
 }
 
@@ -552,11 +547,15 @@ static void
 rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
 {
     struct rt_vcpu *svc = rt_vcpu(vc);
+    s_time_t now = NOW();
 
     /* not addlocate idle vcpu to dom vcpu list */
     if ( is_idle_vcpu(vc) )
         return;
 
+    if ( now >= svc->cur_deadline )
+        rt_update_deadline(now, svc);
+
     if ( !__vcpu_on_q(svc) && vcpu_runnable(vc) && !vc->is_running )
         __runq_insert(ops, svc);
 
@@ -573,11 +572,14 @@ rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
 {
     struct rt_vcpu * const svc = rt_vcpu(vc);
     struct rt_dom * const sdom = svc->sdom;
+    spinlock_t *lock;
 
     BUG_ON( sdom == NULL );
 
+    lock = vcpu_schedule_lock_irq(vc);
     if ( __vcpu_on_q(svc) )
         __q_remove(svc);
+    vcpu_schedule_unlock_irq(lock, vc);
 
     if ( !is_idle_vcpu(vc) )
         list_del_init(&svc->sdom_elem);
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 21:13:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21: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 1XnwHU-0005kw-WA; Mon, 10 Nov 2014 21:13:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xumengpanda@gmail.com>) id 1XnwHT-0005ko-W1
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 21:13:48 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	99/75-03148-B8A21645; Mon, 10 Nov 2014 21:13:47 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415654024!12602677!1
X-Originating-IP: [209.85.218.48]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6415 invoked from network); 10 Nov 2014 21:13:45 -0000
Received: from mail-oi0-f48.google.com (HELO mail-oi0-f48.google.com)
	(209.85.218.48)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 21:13:45 -0000
Received: by mail-oi0-f48.google.com with SMTP id x69so6017074oia.21
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 13:13:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=od/tVGbecCIMdCNsBdznoHsmF3IAF7LZnwzIA9mHuEk=;
	b=UcluFk8z0Ukah3E6Yye3WYsTIrVIQ288pQPTHU0EOMemoOjJjNosm6w718nzIPvGe2
	Oqf2NM34sGFztFIpRSL84h4qMh8eDSeY4tiuONeJyUON9ioRvCICFf7AX3MRGzIUIHmS
	pnJJekwinB9FYKfmdbxGwCk/5mTJ+VPpEQuK5vdzt7yw7+vjt2hhThycXlfDQNe6TTG6
	g+ahHp2kfuXPfMwlEAWlcPE+hevrI3gof2nwRHbHiuDXBeia+e4Qbu/o5ru6AaoxZcnr
	/5Tv6y8yRFzjTBlMQ5GI5qbDiO4pfQTQD8boKx91jxmUPPa81vFzuTgKQ8m/d9BA0MHD
	SPBQ==
MIME-Version: 1.0
X-Received: by 10.60.50.97 with SMTP id b1mr28786143oeo.1.1415654024487; Mon,
	10 Nov 2014 13:13:44 -0800 (PST)
Received: by 10.76.23.231 with HTTP; Mon, 10 Nov 2014 13:13:44 -0800 (PST)
In-Reply-To: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
References: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
Date: Mon, 10 Nov 2014 16:13:44 -0500
Message-ID: <CAENZ-+kxAcS+UP0K8jLnwD3EefN8iVaTryXeOksJH5RBstJ3qg@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: Meng Xu <mengxu@cis.upenn.edu>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.r.wilk@gmail.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v3 0/2] Sanity check input and
 serialize vcpu data in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1486754002623091875=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1486754002623091875==
Content-Type: multipart/alternative; boundary=001a11c1ce14412c30050787a3d6

--001a11c1ce14412c30050787a3d6
Content-Type: text/plain; charset=UTF-8

Sorry, the cover letter missed one line. :-(

2014-11-10 16:11 GMT-05:00 Meng Xu <mengxu@cis.upenn.edu>:

These two patches are to solve the issues found by Jan Beulich at
http://lists.xen.org/archives/html/xen-devel/2014-09/msg03554.html.

The solution is summarized by Dario Faggioli at
> http://lists.xen.org/archives/html/xen-devel/2014-09/msg03603.html.
>
> Here is the solution:
>      - sanity checking input params in rt_dom_cntl()
>      - serialize rt_dom_cntl() itself against the global lock
>      - move the call to rt_update_deadline() from _alloc to _insert
>
> Here is a history of the patch set:
>     v1: first patch to implement the solution by replying the thread;
> request for comment.
>     v2: properly lock the data as proposed in the solution;
>     v3: add comments to the commit log to better explain the reason of the
> implementation.
>
> The whole patch set is:
>     Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> [PATCH for Xen 4.5 v3 1/2] xen: sanity check input and serialization
>     Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
>     Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
> [PATCH for Xen 4.5 v3 2/2] xen: serialize vcpu data in sched_rt.c
>     Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
>
>
> ---
> Meng Xu
> PhD Student in Computer and Information Science
> University of Pennsylvania
>



-- 


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a11c1ce14412c30050787a3d6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">Sor=
ry, the cover letter missed one line. :-(</div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">2014-11-10 16:11 GMT-05:00 Meng Xu <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mengxu@cis.upenn.edu" target=3D"_blank">meng=
xu@cis.upenn.edu</a>&gt;</span>:</div><div class=3D"gmail_quote"><br></div>=
<div class=3D"gmail_quote"><span style=3D"font-family:arial,sans-serif;font=
-size:14.3999996185303px">These two patches are to solve the issues found b=
y Jan Beulich at=C2=A0</span><a href=3D"http://lists.xen.org/archives/html/=
xen-devel/2014-09/msg03554.html" target=3D"_blank" style=3D"font-family:ari=
al,sans-serif;font-size:14.3999996185303px">http://lists.<span class=3D"">x=
en</span>.org/archives/html/<span class=3D"">xen</span>-devel/2014-09/msg03=
554.html</a><span style=3D"font-family:arial,sans-serif;font-size:14.399999=
6185303px">.</span><br></div><div class=3D"gmail_quote"><br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex=
">The solution is summarized by Dario Faggioli at <a href=3D"http://lists.x=
en.org/archives/html/xen-devel/2014-09/msg03603.html" target=3D"_blank">htt=
p://lists.xen.org/archives/html/xen-devel/2014-09/msg03603.html</a>.<br>
<br>
Here is the solution:<br>
=C2=A0 =C2=A0 =C2=A0- sanity checking input params in rt_dom_cntl()<br>
=C2=A0 =C2=A0 =C2=A0- serialize rt_dom_cntl() itself against the global loc=
k<br>
=C2=A0 =C2=A0 =C2=A0- move the call to rt_update_deadline() from _alloc to =
_insert<br>
<br>
Here is a history of the patch set:<br>
=C2=A0 =C2=A0 v1: first patch to implement the solution by replying the thr=
ead; request for comment.<br>
=C2=A0 =C2=A0 v2: properly lock the data as proposed in the solution;<br>
=C2=A0 =C2=A0 v3: add comments to the commit log to better explain the reas=
on of the implementation.<br>
<br>
The whole patch set is:<br>
=C2=A0 =C2=A0 Release-Acked-by: Konrad Rzeszutek Wilk &lt;<a href=3D"mailto=
:konrad.wilk@oracle.com">konrad.wilk@oracle.com</a>&gt;<br>
<br>
[PATCH for Xen 4.5 v3 1/2] xen: sanity check input and serialization<br>
=C2=A0 =C2=A0 Reviewed-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggi=
oli@citrix.com">dario.faggioli@citrix.com</a>&gt;<br>
=C2=A0 =C2=A0 Reviewed-by: George Dunlap &lt;<a href=3D"mailto:george.dunla=
p@eu.citrix.com">george.dunlap@eu.citrix.com</a>&gt;<br>
[PATCH for Xen 4.5 v3 2/2] xen: serialize vcpu data in sched_rt.c<br>
=C2=A0 =C2=A0 Reviewed-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggi=
oli@citrix.com">dario.faggioli@citrix.com</a>&gt;<br>
<br>
<br>
---<br>
Meng Xu<br>
PhD Student in Computer and Information Science<br>
University of Pennsylvania<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><br><br>-----------<br>Meng Xu<br>PhD=
 Student in Computer and Information Science<br>University of Pennsylvania<=
/div></div>
</div></div>

--001a11c1ce14412c30050787a3d6--


--===============1486754002623091875==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1486754002623091875==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 21:13:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21: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 1XnwHU-0005kw-WA; Mon, 10 Nov 2014 21:13:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xumengpanda@gmail.com>) id 1XnwHT-0005ko-W1
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 21:13:48 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	99/75-03148-B8A21645; Mon, 10 Nov 2014 21:13:47 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415654024!12602677!1
X-Originating-IP: [209.85.218.48]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6415 invoked from network); 10 Nov 2014 21:13:45 -0000
Received: from mail-oi0-f48.google.com (HELO mail-oi0-f48.google.com)
	(209.85.218.48)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 21:13:45 -0000
Received: by mail-oi0-f48.google.com with SMTP id x69so6017074oia.21
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 13:13:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=od/tVGbecCIMdCNsBdznoHsmF3IAF7LZnwzIA9mHuEk=;
	b=UcluFk8z0Ukah3E6Yye3WYsTIrVIQ288pQPTHU0EOMemoOjJjNosm6w718nzIPvGe2
	Oqf2NM34sGFztFIpRSL84h4qMh8eDSeY4tiuONeJyUON9ioRvCICFf7AX3MRGzIUIHmS
	pnJJekwinB9FYKfmdbxGwCk/5mTJ+VPpEQuK5vdzt7yw7+vjt2hhThycXlfDQNe6TTG6
	g+ahHp2kfuXPfMwlEAWlcPE+hevrI3gof2nwRHbHiuDXBeia+e4Qbu/o5ru6AaoxZcnr
	/5Tv6y8yRFzjTBlMQ5GI5qbDiO4pfQTQD8boKx91jxmUPPa81vFzuTgKQ8m/d9BA0MHD
	SPBQ==
MIME-Version: 1.0
X-Received: by 10.60.50.97 with SMTP id b1mr28786143oeo.1.1415654024487; Mon,
	10 Nov 2014 13:13:44 -0800 (PST)
Received: by 10.76.23.231 with HTTP; Mon, 10 Nov 2014 13:13:44 -0800 (PST)
In-Reply-To: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
References: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
Date: Mon, 10 Nov 2014 16:13:44 -0500
Message-ID: <CAENZ-+kxAcS+UP0K8jLnwD3EefN8iVaTryXeOksJH5RBstJ3qg@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: Meng Xu <mengxu@cis.upenn.edu>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.r.wilk@gmail.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v3 0/2] Sanity check input and
 serialize vcpu data in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1486754002623091875=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1486754002623091875==
Content-Type: multipart/alternative; boundary=001a11c1ce14412c30050787a3d6

--001a11c1ce14412c30050787a3d6
Content-Type: text/plain; charset=UTF-8

Sorry, the cover letter missed one line. :-(

2014-11-10 16:11 GMT-05:00 Meng Xu <mengxu@cis.upenn.edu>:

These two patches are to solve the issues found by Jan Beulich at
http://lists.xen.org/archives/html/xen-devel/2014-09/msg03554.html.

The solution is summarized by Dario Faggioli at
> http://lists.xen.org/archives/html/xen-devel/2014-09/msg03603.html.
>
> Here is the solution:
>      - sanity checking input params in rt_dom_cntl()
>      - serialize rt_dom_cntl() itself against the global lock
>      - move the call to rt_update_deadline() from _alloc to _insert
>
> Here is a history of the patch set:
>     v1: first patch to implement the solution by replying the thread;
> request for comment.
>     v2: properly lock the data as proposed in the solution;
>     v3: add comments to the commit log to better explain the reason of the
> implementation.
>
> The whole patch set is:
>     Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> [PATCH for Xen 4.5 v3 1/2] xen: sanity check input and serialization
>     Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
>     Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
> [PATCH for Xen 4.5 v3 2/2] xen: serialize vcpu data in sched_rt.c
>     Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
>
>
> ---
> Meng Xu
> PhD Student in Computer and Information Science
> University of Pennsylvania
>



-- 


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a11c1ce14412c30050787a3d6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">Sor=
ry, the cover letter missed one line. :-(</div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">2014-11-10 16:11 GMT-05:00 Meng Xu <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mengxu@cis.upenn.edu" target=3D"_blank">meng=
xu@cis.upenn.edu</a>&gt;</span>:</div><div class=3D"gmail_quote"><br></div>=
<div class=3D"gmail_quote"><span style=3D"font-family:arial,sans-serif;font=
-size:14.3999996185303px">These two patches are to solve the issues found b=
y Jan Beulich at=C2=A0</span><a href=3D"http://lists.xen.org/archives/html/=
xen-devel/2014-09/msg03554.html" target=3D"_blank" style=3D"font-family:ari=
al,sans-serif;font-size:14.3999996185303px">http://lists.<span class=3D"">x=
en</span>.org/archives/html/<span class=3D"">xen</span>-devel/2014-09/msg03=
554.html</a><span style=3D"font-family:arial,sans-serif;font-size:14.399999=
6185303px">.</span><br></div><div class=3D"gmail_quote"><br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex=
">The solution is summarized by Dario Faggioli at <a href=3D"http://lists.x=
en.org/archives/html/xen-devel/2014-09/msg03603.html" target=3D"_blank">htt=
p://lists.xen.org/archives/html/xen-devel/2014-09/msg03603.html</a>.<br>
<br>
Here is the solution:<br>
=C2=A0 =C2=A0 =C2=A0- sanity checking input params in rt_dom_cntl()<br>
=C2=A0 =C2=A0 =C2=A0- serialize rt_dom_cntl() itself against the global loc=
k<br>
=C2=A0 =C2=A0 =C2=A0- move the call to rt_update_deadline() from _alloc to =
_insert<br>
<br>
Here is a history of the patch set:<br>
=C2=A0 =C2=A0 v1: first patch to implement the solution by replying the thr=
ead; request for comment.<br>
=C2=A0 =C2=A0 v2: properly lock the data as proposed in the solution;<br>
=C2=A0 =C2=A0 v3: add comments to the commit log to better explain the reas=
on of the implementation.<br>
<br>
The whole patch set is:<br>
=C2=A0 =C2=A0 Release-Acked-by: Konrad Rzeszutek Wilk &lt;<a href=3D"mailto=
:konrad.wilk@oracle.com">konrad.wilk@oracle.com</a>&gt;<br>
<br>
[PATCH for Xen 4.5 v3 1/2] xen: sanity check input and serialization<br>
=C2=A0 =C2=A0 Reviewed-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggi=
oli@citrix.com">dario.faggioli@citrix.com</a>&gt;<br>
=C2=A0 =C2=A0 Reviewed-by: George Dunlap &lt;<a href=3D"mailto:george.dunla=
p@eu.citrix.com">george.dunlap@eu.citrix.com</a>&gt;<br>
[PATCH for Xen 4.5 v3 2/2] xen: serialize vcpu data in sched_rt.c<br>
=C2=A0 =C2=A0 Reviewed-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggi=
oli@citrix.com">dario.faggioli@citrix.com</a>&gt;<br>
<br>
<br>
---<br>
Meng Xu<br>
PhD Student in Computer and Information Science<br>
University of Pennsylvania<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><br><br>-----------<br>Meng Xu<br>PhD=
 Student in Computer and Information Science<br>University of Pennsylvania<=
/div></div>
</div></div>

--001a11c1ce14412c30050787a3d6--


--===============1486754002623091875==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1486754002623091875==--


From xen-devel-bounces@lists.xen.org Mon Nov 10 21:33:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21: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 1Xnwa3-0006Dk-2W; Mon, 10 Nov 2014 21:32:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xnwa1-0006Cs-SI
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 21:32:57 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	6F/87-17694-90F21645; Mon, 10 Nov 2014 21:32:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415655175!11537265!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3394 invoked from network); 10 Nov 2014 21:32:56 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 21:32:56 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAALWpDj031379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 21:32:51 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAALWn8D016332
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 21:32:50 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAALWnKU010109; Mon, 10 Nov 2014 21:32:49 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 13:32:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BAB72113847; Mon, 10 Nov 2014 16:32:48 -0500 (EST)
Date: Mon, 10 Nov 2014 16:32:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141110213248.GA23182@laptop.dumpdata.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141110180720.GA15286@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Nov 10, 2014 at 01:07:20PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 10, 2014 at 05:42:32PM +0000, David Vrabel wrote:
> > On 10/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> > > Hey,
> > > =

> > > With Xen 4.5 (today's staging), when I boot a guest and then do pci-a=
ttach
> > > the BARs values are corrupt.

I can reproduce this with Xen 4.4, Xen 4.3 and Xen 4.1.

A bit digging in and I realized that:

(XEN) memory_map:add: dom1 gfn=3Df4000 mfn=3Dd8000 nr=3D4000 [64M]
(XEN) AMD-Vi: update_paging_mode Try to access pdev_list without aquiring p=
cidevs_lock.
(XEN) memory_map:add: dom1 gfn=3Df8000 mfn=3Dfc000 nr=3D2000 [32M]
(XEN) ioport_map:add: dom1 gport=3D1000 mport=3Dc000 nr=3D80
(XEN) AMD-Vi: Disable: device id =3D 0x500, domain =3D 0, paging mode =3D 3
(XEN) AMD-Vi: Setup I/O page table: device id =3D 0x500, type =3D 0x1, root=
 table =3D 0x228b02000, domain =3D 1, paging mode =3D 3

The sizes are my own editing. This means QEMU is putting the
devices in the MMIO region - and doing it succesfully. But then:

> > =

> > =

> > > [  152.572965] pci 0000:00:04.0: BAR 1: no space for [mem size 0x0800=
0000 64bit  pref]
> [ =A0152.518320] pci 0000:00:04.0: reg 0x14: [mem 0x00000000-0x07ffffff 6=
4bit pref]

.. The guest computes the right size for them, but reads the wrong BAR value
that was set by QEMU and also created in the hypervisor.

Perhaps this is Linux kernel being on fritz. Will try another kernel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 21:33:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21: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 1Xnwa3-0006Dk-2W; Mon, 10 Nov 2014 21:32:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xnwa1-0006Cs-SI
	for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 21:32:57 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	6F/87-17694-90F21645; Mon, 10 Nov 2014 21:32:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415655175!11537265!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3394 invoked from network); 10 Nov 2014 21:32:56 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 21:32:56 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAALWpDj031379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 21:32:51 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAALWn8D016332
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 21:32:50 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAALWnKU010109; Mon, 10 Nov 2014 21:32:49 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 13:32:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BAB72113847; Mon, 10 Nov 2014 16:32:48 -0500 (EST)
Date: Mon, 10 Nov 2014 16:32:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141110213248.GA23182@laptop.dumpdata.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141110180720.GA15286@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Nov 10, 2014 at 01:07:20PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 10, 2014 at 05:42:32PM +0000, David Vrabel wrote:
> > On 10/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> > > Hey,
> > > =

> > > With Xen 4.5 (today's staging), when I boot a guest and then do pci-a=
ttach
> > > the BARs values are corrupt.

I can reproduce this with Xen 4.4, Xen 4.3 and Xen 4.1.

A bit digging in and I realized that:

(XEN) memory_map:add: dom1 gfn=3Df4000 mfn=3Dd8000 nr=3D4000 [64M]
(XEN) AMD-Vi: update_paging_mode Try to access pdev_list without aquiring p=
cidevs_lock.
(XEN) memory_map:add: dom1 gfn=3Df8000 mfn=3Dfc000 nr=3D2000 [32M]
(XEN) ioport_map:add: dom1 gport=3D1000 mport=3Dc000 nr=3D80
(XEN) AMD-Vi: Disable: device id =3D 0x500, domain =3D 0, paging mode =3D 3
(XEN) AMD-Vi: Setup I/O page table: device id =3D 0x500, type =3D 0x1, root=
 table =3D 0x228b02000, domain =3D 1, paging mode =3D 3

The sizes are my own editing. This means QEMU is putting the
devices in the MMIO region - and doing it succesfully. But then:

> > =

> > =

> > > [  152.572965] pci 0000:00:04.0: BAR 1: no space for [mem size 0x0800=
0000 64bit  pref]
> [ =A0152.518320] pci 0000:00:04.0: reg 0x14: [mem 0x00000000-0x07ffffff 6=
4bit pref]

.. The guest computes the right size for them, but reads the wrong BAR value
that was set by QEMU and also created in the hypervisor.

Perhaps this is Linux kernel being on fritz. Will try another kernel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 21:49:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21:49:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnwpU-0006V2-RN; Mon, 10 Nov 2014 21:48:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnwpU-0006Ux-6E
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 21:48:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4E/5B-09936-7C231645; Mon, 10 Nov 2014 21:48:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415656132!12489077!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25732 invoked from network); 10 Nov 2014 21:48:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 21:48:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,355,1413244800"; d="scan'208";a="191360098"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 16:48:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnwpM-00007R-Qc;
	Mon, 10 Nov 2014 21:48:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnwpM-0003o2-BN;
	Mon, 10 Nov 2014 21:48:48 +0000
Date: Mon, 10 Nov 2014 21:48:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31463-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31463: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31463 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31463/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767
 build-amd64-pvops             5 kernel-build              fail REGR. vs. 30767

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 31458

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-pair         1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 31458 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31458 never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop      fail in 31458 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31458 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31458 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 31458 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 31458 never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop            fail in 31458 never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         blocked 
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           blocked 
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Mon Nov 10 21:49:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 21:49:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnwpU-0006V2-RN; Mon, 10 Nov 2014 21:48:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnwpU-0006Ux-6E
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 21:48:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4E/5B-09936-7C231645; Mon, 10 Nov 2014 21:48:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415656132!12489077!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25732 invoked from network); 10 Nov 2014 21:48:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 21:48:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,355,1413244800"; d="scan'208";a="191360098"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 16:48:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnwpM-00007R-Qc;
	Mon, 10 Nov 2014 21:48:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnwpM-0003o2-BN;
	Mon, 10 Nov 2014 21:48:48 +0000
Date: Mon, 10 Nov 2014 21:48:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31463-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31463: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31463 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31463/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767
 build-amd64-pvops             5 kernel-build              fail REGR. vs. 30767

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 31458

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-pair         1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 31458 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31458 never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop      fail in 31458 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31458 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31458 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 31458 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 31458 never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop            fail in 31458 never pass

version targeted for testing:
 seabios              85230163bda80356fed5832336e4356ef56073c5
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         blocked 
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           blocked 
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 Mon Nov 10 22:15:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 22:15:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnxEO-000744-T5; Mon, 10 Nov 2014 22:14:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XnxEN-00073z-12
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 22:14:39 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	2F/FE-02953-EC831645; Mon, 10 Nov 2014 22:14:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415657677!12498368!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20765 invoked from network); 10 Nov 2014 22:14:37 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-3.tower-27.messagelabs.com with SMTP;
	10 Nov 2014 22:14:37 -0000
X-TM-IMSS-Message-ID: <dc19768e0008f2e9@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 dc19768e0008f2e9 ;
	Mon, 10 Nov 2014 17:13:52 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAAMEHmA015389; 
	Mon, 10 Nov 2014 17:14:28 -0500
Message-ID: <546137DD.2030801@tycho.nsa.gov>
Date: Mon, 10 Nov 2014 17:10:37 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>		
	<545235EE.4040000@citrix.com>		
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>	
	<1415096148.11486.11.camel@citrix.com>
	<545BEFC5.3010803@tycho.nsa.gov>
	<1415620919.28370.14.camel@citrix.com>
In-Reply-To: <1415620919.28370.14.camel@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Emil Condrea <emilcondrea@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 07:01 AM, Ian Campbell wrote:
> On Thu, 2014-11-06 at 17:01 -0500, Daniel De Graaf wrote:
>> On 11/04/2014 05:15 AM, Ian Campbell wrote:
>>> On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
>>>> Of course we can use max, but I thought that it might be useful to
>>>> have a prink to inform the user that the timeout was adjusted.
>>>> In init_tpm_tis the default timeouts are set using:
>>>> /* Set default timeouts */ tpm->timeout_a =
>>>> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
>>>> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
>>>> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
>>>> MILLISECS(TIS_SHORT_TIMEOUT);
>>>>
>>>>
>>>>
>>>> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
>>>> So if we want to integrate kernel changes I think we should use
>>>> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
>>>> Also in kernel the default timeouts are initialized using
>>>> msecs_to_jiffies which is different from MILLISECS
>>>> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
>>>> Is there a certain reason for not using msecs_to_jiffies ?
>>>
>>> jiffies are a Linux specific concept which mini-os doesn't share.
>>>
>>> Daniel, do you have any opinion on this patch?
>>>
>>> It seems like the Linux fix is made only for the specifically broken
>>> platform. That seems to make sense to me since presumably other systems
>>> report short timeouts which they can indeed cope with. It's only Atmel
>>> which brokenly reports something it cannot handle.
>>>
>>> Ian.
>>
>> I agree that an adjustment is needed when values are too short.  Adjusting
>> in all cases is not quite as nice as only fixing the broken TPMs, but it
>> is a lot simpler.  It also doesn't seem harmful to have the timeouts be
>> too large in the driver: a properly functioning TPM will not time out its
>> requests in any case, so the user won't notice normally, and the default
>> short timeout is 0.75 seconds - very few people will complain if they have
>> to wait that long to get a timeout instead of what their TPM actually uses.
>
> Can we take that as an ack?

Yes.  I was going to check to see if the printks would cause people to see
problems where the timeouts were already reasonable, but since the mini-os
driver is already quite verbose, this should not be a problem.  It might
be nice to output the old/new value of the timeout, but that's mostly for
the curious rather than actually necessary.

> Also needs the ok from Konrad as release manager. AIUI this is a bugfix
> for a particular piece of h/w and as Daniel explains above the downside
> is that sometimes someone might need to wait 0.75s for a timeout instead
> of something shorter.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 22:15:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 22:15:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnxEO-000744-T5; Mon, 10 Nov 2014 22:14:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XnxEN-00073z-12
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 22:14:39 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	2F/FE-02953-EC831645; Mon, 10 Nov 2014 22:14:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415657677!12498368!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20765 invoked from network); 10 Nov 2014 22:14:37 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-3.tower-27.messagelabs.com with SMTP;
	10 Nov 2014 22:14:37 -0000
X-TM-IMSS-Message-ID: <dc19768e0008f2e9@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 dc19768e0008f2e9 ;
	Mon, 10 Nov 2014 17:13:52 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAAMEHmA015389; 
	Mon, 10 Nov 2014 17:14:28 -0500
Message-ID: <546137DD.2030801@tycho.nsa.gov>
Date: Mon, 10 Nov 2014 17:10:37 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>		
	<545235EE.4040000@citrix.com>		
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>	
	<1415096148.11486.11.camel@citrix.com>
	<545BEFC5.3010803@tycho.nsa.gov>
	<1415620919.28370.14.camel@citrix.com>
In-Reply-To: <1415620919.28370.14.camel@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Emil Condrea <emilcondrea@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 07:01 AM, Ian Campbell wrote:
> On Thu, 2014-11-06 at 17:01 -0500, Daniel De Graaf wrote:
>> On 11/04/2014 05:15 AM, Ian Campbell wrote:
>>> On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
>>>> Of course we can use max, but I thought that it might be useful to
>>>> have a prink to inform the user that the timeout was adjusted.
>>>> In init_tpm_tis the default timeouts are set using:
>>>> /* Set default timeouts */ tpm->timeout_a =
>>>> MILLISECS(TIS_SHORT_TIMEOUT);//750*1000000UL tpm->timeout_b =
>>>> MILLISECS(TIS_LONG_TIMEOUT);//2000*1000000UL tpm->timeout_c =
>>>> MILLISECS(TIS_SHORT_TIMEOUT); tpm->timeout_d =
>>>> MILLISECS(TIS_SHORT_TIMEOUT);
>>>>
>>>>
>>>>
>>>> But in kernel fix they are set as 750*1000 instead of 750*1000000UL :
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n381
>>>> So if we want to integrate kernel changes I think we should use
>>>> MICROSECS(TIS_SHORT_TIMEOUT) which is 750000
>>>> Also in kernel the default timeouts are initialized using
>>>> msecs_to_jiffies which is different from MILLISECS
>>>> macro.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_tis.c#n548
>>>> Is there a certain reason for not using msecs_to_jiffies ?
>>>
>>> jiffies are a Linux specific concept which mini-os doesn't share.
>>>
>>> Daniel, do you have any opinion on this patch?
>>>
>>> It seems like the Linux fix is made only for the specifically broken
>>> platform. That seems to make sense to me since presumably other systems
>>> report short timeouts which they can indeed cope with. It's only Atmel
>>> which brokenly reports something it cannot handle.
>>>
>>> Ian.
>>
>> I agree that an adjustment is needed when values are too short.  Adjusting
>> in all cases is not quite as nice as only fixing the broken TPMs, but it
>> is a lot simpler.  It also doesn't seem harmful to have the timeouts be
>> too large in the driver: a properly functioning TPM will not time out its
>> requests in any case, so the user won't notice normally, and the default
>> short timeout is 0.75 seconds - very few people will complain if they have
>> to wait that long to get a timeout instead of what their TPM actually uses.
>
> Can we take that as an ack?

Yes.  I was going to check to see if the printks would cause people to see
problems where the timeouts were already reasonable, but since the mini-os
driver is already quite verbose, this should not be a problem.  It might
be nice to output the old/new value of the timeout, but that's mostly for
the curious rather than actually necessary.

> Also needs the ok from Konrad as release manager. AIUI this is a bugfix
> for a particular piece of h/w and as Daniel explains above the downside
> is that sometimes someone might need to wait 0.75s for a timeout instead
> of something shorter.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 23:19:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 23:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnyEk-0007w3-02; Mon, 10 Nov 2014 23:19:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XnyEj-0007vy-8V
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 23:19:05 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	81/DF-25547-8E741645; Mon, 10 Nov 2014 23:19:04 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415661540!11670856!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13101 invoked from network); 10 Nov 2014 23:19:02 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 23:19:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAANIqwU022602
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 23:18:53 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAANIpnK017424
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Nov 2014 23:18:52 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAANIoYQ013850; Mon, 10 Nov 2014 23:18:51 GMT
Received: from ovs105.us.oracle.com (/10.149.76.205)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 15:18:50 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
Date: Mon, 10 Nov 2014 18:16:48 -0500
Message-Id: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/2] Two fixes for libxl's PCI detach operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Two patches to fix 'xl pci-detach'/do_pci_remove() behavior.
* Prevent libxl from resetting device (and removing it from xenstore)
  before QEMU responded to the guest's 'eject' write
* Remove unnecessary calls to xc_physdev_unmap_pirq() and
  xc_domain_irq_permission()

If patches are acceptable I suggest including the first one in 4.5 as
it fixes a bug. The second patch is about removing harmless but annoying
error messages so it can wait.

This has been tested by Konrad for HVM guests. His tests failed with PV
guests. However, they failed in the same manner without these patches so
it's unlikely that these two introduced a regression. My PV tests worked
fine (except for a warning in the guest, but again, I had the same
warning before changes).

Boris Ostrovsky (2):
  libxl: Wait until QEMU removed the device before tearing it down
  libxl: Simplify cleanup in do_pci_remove()

 tools/libxl/libxl_internal.h |    1 +
 tools/libxl/libxl_pci.c      |   54 +++++++++++++++++++++++++----------
 tools/libxl/libxl_qmp.c      |   64 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 104 insertions(+), 15 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 23:19:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 23:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnyEh-0007vr-KU; Mon, 10 Nov 2014 23:19:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XnyEf-0007va-VI
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 23:19:02 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	0F/FC-26858-4E741645; Mon, 10 Nov 2014 23:19:00 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415661538!11647754!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21553 invoked from network); 10 Nov 2014 23:19:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 23:19:00 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAANIsal027577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 23:18:54 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAANIq8l007453
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 23:18:53 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAANIq79010524; Mon, 10 Nov 2014 23:18:52 GMT
Received: from ovs105.us.oracle.com (/10.149.76.205)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 15:18:51 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
Date: Mon, 10 Nov 2014 18:16:50 -0500
Message-Id: <1415661410-5191-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
In-Reply-To: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/2] libxl: Simplify cleanup in do_pci_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Calls to xc_physdev_unmap_pirq() will fail for HVM guests since QEMU
makes the same call earlier, during device removal.

In addition, guest's call to xc_domain_irq_permission() will also fail
since clearing permissions is part of hypervisor's unmap_domain_pirq().

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/libxl_pci.c |   32 +++++++++++++++++---------------
 1 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4c6a733..d5d7cc0 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1310,24 +1310,26 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
         }
         fclose(f);
 skip1:
-        sysfs_path = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/irq", pcidev->domain,
-                                   pcidev->bus, pcidev->dev, pcidev->func);
-        f = fopen(sysfs_path, "r");
-        if (f == NULL) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", sysfs_path);
-            goto out;
-        }
-        if ((fscanf(f, "%u", &irq) == 1) && irq) {
-            rc = xc_physdev_unmap_pirq(ctx->xch, domid, irq);
-            if (rc < 0) {
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_physdev_unmap_pirq irq=%d", irq);
+        if (!hvm) {
+            sysfs_path = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/irq",
+                                        pcidev->domain,
+                                        pcidev->bus, pcidev->dev,
+                                        pcidev->func);
+            f = fopen(sysfs_path, "r");
+            if (f == NULL) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                                 "Couldn't open %s", sysfs_path);
+                goto out;
             }
-            rc = xc_domain_irq_permission(ctx->xch, domid, irq, 0);
-            if (rc < 0) {
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_domain_irq_permission irq=%d", irq);
+            if ((fscanf(f, "%u", &irq) == 1) && irq) {
+                rc = xc_physdev_unmap_pirq(ctx->xch, domid, irq);
+                if (rc < 0) {
+                    LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                                     "xc_physdev_unmap_pirq irq=%d", irq);
+                }
             }
+            fclose(f);
         }
-        fclose(f);
     }
 out:
     /* don't do multiple resets while some functions are still passed through */
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 23:19:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 23:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnyEh-0007vk-9S; Mon, 10 Nov 2014 23:19:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XnyEf-0007vb-Ft
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 23:19:01 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	93/60-02702-4E741645; Mon, 10 Nov 2014 23:19:00 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415661538!12597489!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18738 invoked from network); 10 Nov 2014 23:18:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 23:18:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAANIq6L027561
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 23:18:53 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAANIqdC010520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 23:18:52 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAANIpR1007431; Mon, 10 Nov 2014 23:18:51 GMT
Received: from ovs105.us.oracle.com (/10.149.76.205)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 15:18:51 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
Date: Mon, 10 Nov 2014 18:16:49 -0500
Message-Id: <1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
In-Reply-To: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device
	before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When a device is hot-unplugged libxl sends QEMU a "device-del" message
(via QMP). This call returns after QEMU has initiated device removal by
sending an interrupt to the guest. At some point later QEMU is expected
to clean up after the device (such as unbind/unmap MSIs), which will
occur when the guest signals that the device has been ejected.

Before this happens, however, it is likely that libxl will try to unmap
the pirq itself (without first unbinding it) and then reset the device. The
unmapping will result in the hypervisor having to perform a forced unbind
and that, in turn, will cause any future binds (such as when we try to
hotplug the device back) to fail.

In addition, if the guest kernel had not had a chance to respond to QEMU's
interrupt before libxl resets the device it may fail to properly clean
up, e.g. with Linux igb driver:

[   26.976212] WARNING: CPU: 0 PID: 6 at lib/iomap.c:43 bad_io_access+0x3d/0x40()
[   26.985855] Bad IO access at port 0x0 ()
[   26.990303] Modules linked in: xt_REDIRECT iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack scsi_transport_iscsi igb i2c_algo_bit ptp pps_core i2c_core hwmon dca floppy
[   27.016289] CPU: 0 PID: 6 Comm: kworker/u256:0 Not tainted 3.18.0-rc2 #66
[   27.025154] Hardware name: Xen HVM domU, BIOS 4.5-unstable 10/24/2014
[   27.033357] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[   27.040638]  0000000000000009 ffff88003c2f3b38 ffffffff8169dbd1 0000000000000001
[   27.050884]  ffff88003c2f3b88 ffff88003c2f3b78 ffffffff8109149c ffff88003c2f3b88
[   27.060959]  ffff880039eb6000 ffff88003b8a8000 ffff880039eb6880 ffff88003b8a8098
[   27.071173] Call Trace:
[   27.074525]  [<ffffffff8169dbd1>] dump_stack+0x46/0x58
[   27.081411]  [<ffffffff8109149c>] warn_slowpath_common+0x8c/0xc0
[   27.089290]  [<ffffffff81091586>] warn_slowpath_fmt+0x46/0x50
[   27.096756]  [<ffffffffa00461c4>] ? igb_reset_interrupt_capability+0x64/0x80 [igb]
[   27.106651]  [<ffffffff8137bded>] bad_io_access+0x3d/0x40
[   27.113785]  [<ffffffff8137be1c>] pci_iounmap+0x2c/0x40
[   27.120619]  [<ffffffffa00489cf>] igb_remove+0xbf/0x160 [igb]
[   27.128161]  [<ffffffff813a0276>] pci_device_remove+0x46/0xc0
[   27.135895]  [<ffffffff81479f8f>] __device_release_driver+0x7f/0xf0
[   27.144748]  [<ffffffff8147a34c>] device_release_driver+0x2c/0x40
[   27.153123]  [<ffffffff81399b4c>] pci_stop_bus_device+0x9c/0xb0
[   27.160951]  [<ffffffff81399cc6>] pci_stop_and_remove_bus_device+0x16/0x30
[   27.170290]  [<ffffffff813b64a7>] disable_slot+0x57/0xb0
[   27.177610]  [<ffffffff813b6521>] acpiphp_disable_and_eject_slot+0x21/0x90
[   27.187063]  [<ffffffff813b7031>] acpiphp_hotplug_notify+0x141/0x220
[   27.195588]  [<ffffffff813b6ef0>] ? acpiphp_post_dock_fixup+0xd0/0xd0
[   27.204205]  [<ffffffff813deb6d>] acpi_device_hotplug+0x3a1/0x3f0
[   27.212677]  [<ffffffff813d8871>] acpi_hotplug_work_fn+0x1f/0x2b
[   27.220853]  [<ffffffff810a8b8c>] process_one_work+0x15c/0x410
[   27.228802]  [<ffffffff810a8f9d>] worker_thread+0x11d/0x520
[   27.238591]  [<ffffffff810a8e80>] ? process_scheduled_works+0x40/0x40
[   27.251911]  [<ffffffff810aed49>] kthread+0xc9/0xe0
[   27.262033]  [<ffffffff810aec80>] ? flush_kthread_worker+0x70/0x70
[   27.274774]  [<ffffffff816a62bc>] ret_from_fork+0x7c/0xb0
[   27.285985]  [<ffffffff810aec80>] ? flush_kthread_worker+0x70/0x70
[   27.298839] ---[ end trace e8838cc146d5f64c ]---

To avoid this we should wait until QEMU has completed device teardown (which, at least
for Linux, happens after the guest is done with its own cleanup).

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/libxl_internal.h |    1 +
 tools/libxl/libxl_pci.c      |   22 ++++++++++++++
 tools/libxl/libxl_qmp.c      |   64 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f61673c..139da3a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1589,6 +1589,7 @@ _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);
+_hidden int libxl__qmp_pci_test(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _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);
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 9f40100..4c6a733 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1246,6 +1246,28 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
             break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
             rc = libxl__qmp_pci_del(gc, domid, pcidev);
+            if (rc < 0)
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "libxl__qmp_pci_del");
+            else {
+                unsigned total_us = 0, wait_us = 100000;
+
+                rc = -ETIMEDOUT;
+                /* Wait (at most ~6 seconds) for device to disappear */
+                do {
+                    int err = libxl__qmp_pci_test(gc, domid, pcidev);
+                    if (err) {
+                        if (err == -ENODEV)
+                            rc = 0;
+                        else
+                            rc = err;
+                        break;
+                    }
+                    usleep(wait_us);
+                    total_us += wait_us;
+                    wait_us *= 2;
+                } while (total_us < 5000000);
+            }
+
             break;
         default:
             rc = ERROR_INVAL;
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index c7324e6..3235c83 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -739,6 +739,41 @@ static int qmp_query_vnc(libxl__qmp_handler *qmp)
                                 NULL, qmp->timeout);
 }
 
+static int pci_exists_callback(libxl__qmp_handler *qmp,
+                            const libxl__json_object *response, void *opaque)
+{
+    libxl_device_pci *pcidev = opaque;
+    const libxl__json_object *bus;
+    GC_INIT(qmp->ctx);
+    int i, j, rc = -ENODEV;
+    char *asked_id = GCSPRINTF(PCI_PT_QDEV_ID,
+                               pcidev->bus, pcidev->dev, pcidev->func);
+
+    for (i = 0; (bus = libxl__json_array_get(response, i)); i++) {
+        const libxl__json_object *devices = NULL;
+        const libxl__json_object *device = NULL;
+        const libxl__json_object *o = NULL;
+        const char *id = NULL;
+
+        devices = libxl__json_map_get("devices", bus, JSON_ARRAY);
+
+        for (j = 0; (device = libxl__json_array_get(devices, j)); j++) {
+             o = libxl__json_map_get("qdev_id", device, JSON_STRING);
+             id = libxl__json_object_get_string(o);
+
+             if (id && strcmp(asked_id, id) == 0) {
+                 rc = 0;
+                 goto out;
+             }
+        }
+    }
+
+out:
+    GC_FREE;
+    return rc;
+
+}
+
 static int pci_add_callback(libxl__qmp_handler *qmp,
                             const libxl__json_object *response, void *opaque)
 {
@@ -804,6 +839,35 @@ static int qmp_run_command(libxl__gc *gc, int domid,
     return rc;
 }
 
+int libxl__qmp_pci_test(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
+{
+    libxl__qmp_handler *qmp = NULL;
+    libxl__json_object *args = NULL;
+    char *hostaddr = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(gc, domid);
+    if (!qmp)
+        return -1;
+
+    hostaddr = GCSPRINTF("%04x:%02x:%02x.%01x", pcidev->domain,
+                         pcidev->bus, pcidev->dev, pcidev->func);
+    if (!hostaddr)
+        return -1;
+
+    qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough");
+    QMP_PARAMETERS_SPRINTF(&args, "id", PCI_PT_QDEV_ID,
+                           pcidev->bus, pcidev->dev, pcidev->func);
+    qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr);
+
+    rc = qmp_synchronous_send(qmp, "query-pci", NULL,
+                             pci_exists_callback, pcidev, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+
+}
+
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 23:19:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 23:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnyEk-0007w3-02; Mon, 10 Nov 2014 23:19:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XnyEj-0007vy-8V
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 23:19:05 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	81/DF-25547-8E741645; Mon, 10 Nov 2014 23:19:04 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415661540!11670856!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13101 invoked from network); 10 Nov 2014 23:19:02 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 23:19:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAANIqwU022602
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 23:18:53 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAANIpnK017424
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Nov 2014 23:18:52 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAANIoYQ013850; Mon, 10 Nov 2014 23:18:51 GMT
Received: from ovs105.us.oracle.com (/10.149.76.205)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 15:18:50 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
Date: Mon, 10 Nov 2014 18:16:48 -0500
Message-Id: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/2] Two fixes for libxl's PCI detach operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Two patches to fix 'xl pci-detach'/do_pci_remove() behavior.
* Prevent libxl from resetting device (and removing it from xenstore)
  before QEMU responded to the guest's 'eject' write
* Remove unnecessary calls to xc_physdev_unmap_pirq() and
  xc_domain_irq_permission()

If patches are acceptable I suggest including the first one in 4.5 as
it fixes a bug. The second patch is about removing harmless but annoying
error messages so it can wait.

This has been tested by Konrad for HVM guests. His tests failed with PV
guests. However, they failed in the same manner without these patches so
it's unlikely that these two introduced a regression. My PV tests worked
fine (except for a warning in the guest, but again, I had the same
warning before changes).

Boris Ostrovsky (2):
  libxl: Wait until QEMU removed the device before tearing it down
  libxl: Simplify cleanup in do_pci_remove()

 tools/libxl/libxl_internal.h |    1 +
 tools/libxl/libxl_pci.c      |   54 +++++++++++++++++++++++++----------
 tools/libxl/libxl_qmp.c      |   64 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 104 insertions(+), 15 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 23:19:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 23:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnyEh-0007vr-KU; Mon, 10 Nov 2014 23:19:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XnyEf-0007va-VI
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 23:19:02 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	0F/FC-26858-4E741645; Mon, 10 Nov 2014 23:19:00 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415661538!11647754!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21553 invoked from network); 10 Nov 2014 23:19:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 23:19:00 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAANIsal027577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 23:18:54 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAANIq8l007453
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 23:18:53 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAANIq79010524; Mon, 10 Nov 2014 23:18:52 GMT
Received: from ovs105.us.oracle.com (/10.149.76.205)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 15:18:51 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
Date: Mon, 10 Nov 2014 18:16:50 -0500
Message-Id: <1415661410-5191-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
In-Reply-To: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/2] libxl: Simplify cleanup in do_pci_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Calls to xc_physdev_unmap_pirq() will fail for HVM guests since QEMU
makes the same call earlier, during device removal.

In addition, guest's call to xc_domain_irq_permission() will also fail
since clearing permissions is part of hypervisor's unmap_domain_pirq().

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/libxl_pci.c |   32 +++++++++++++++++---------------
 1 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4c6a733..d5d7cc0 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1310,24 +1310,26 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
         }
         fclose(f);
 skip1:
-        sysfs_path = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/irq", pcidev->domain,
-                                   pcidev->bus, pcidev->dev, pcidev->func);
-        f = fopen(sysfs_path, "r");
-        if (f == NULL) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", sysfs_path);
-            goto out;
-        }
-        if ((fscanf(f, "%u", &irq) == 1) && irq) {
-            rc = xc_physdev_unmap_pirq(ctx->xch, domid, irq);
-            if (rc < 0) {
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_physdev_unmap_pirq irq=%d", irq);
+        if (!hvm) {
+            sysfs_path = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/irq",
+                                        pcidev->domain,
+                                        pcidev->bus, pcidev->dev,
+                                        pcidev->func);
+            f = fopen(sysfs_path, "r");
+            if (f == NULL) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                                 "Couldn't open %s", sysfs_path);
+                goto out;
             }
-            rc = xc_domain_irq_permission(ctx->xch, domid, irq, 0);
-            if (rc < 0) {
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_domain_irq_permission irq=%d", irq);
+            if ((fscanf(f, "%u", &irq) == 1) && irq) {
+                rc = xc_physdev_unmap_pirq(ctx->xch, domid, irq);
+                if (rc < 0) {
+                    LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                                     "xc_physdev_unmap_pirq irq=%d", irq);
+                }
             }
+            fclose(f);
         }
-        fclose(f);
     }
 out:
     /* don't do multiple resets while some functions are still passed through */
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 23:19:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 23:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnyEh-0007vk-9S; Mon, 10 Nov 2014 23:19:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XnyEf-0007vb-Ft
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 23:19:01 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	93/60-02702-4E741645; Mon, 10 Nov 2014 23:19:00 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415661538!12597489!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18738 invoked from network); 10 Nov 2014 23:18:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Nov 2014 23:18:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAANIq6L027561
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Nov 2014 23:18:53 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAANIqdC010520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Nov 2014 23:18:52 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAANIpR1007431; Mon, 10 Nov 2014 23:18:51 GMT
Received: from ovs105.us.oracle.com (/10.149.76.205)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Nov 2014 15:18:51 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
Date: Mon, 10 Nov 2014 18:16:49 -0500
Message-Id: <1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
In-Reply-To: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device
	before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When a device is hot-unplugged libxl sends QEMU a "device-del" message
(via QMP). This call returns after QEMU has initiated device removal by
sending an interrupt to the guest. At some point later QEMU is expected
to clean up after the device (such as unbind/unmap MSIs), which will
occur when the guest signals that the device has been ejected.

Before this happens, however, it is likely that libxl will try to unmap
the pirq itself (without first unbinding it) and then reset the device. The
unmapping will result in the hypervisor having to perform a forced unbind
and that, in turn, will cause any future binds (such as when we try to
hotplug the device back) to fail.

In addition, if the guest kernel had not had a chance to respond to QEMU's
interrupt before libxl resets the device it may fail to properly clean
up, e.g. with Linux igb driver:

[   26.976212] WARNING: CPU: 0 PID: 6 at lib/iomap.c:43 bad_io_access+0x3d/0x40()
[   26.985855] Bad IO access at port 0x0 ()
[   26.990303] Modules linked in: xt_REDIRECT iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack scsi_transport_iscsi igb i2c_algo_bit ptp pps_core i2c_core hwmon dca floppy
[   27.016289] CPU: 0 PID: 6 Comm: kworker/u256:0 Not tainted 3.18.0-rc2 #66
[   27.025154] Hardware name: Xen HVM domU, BIOS 4.5-unstable 10/24/2014
[   27.033357] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[   27.040638]  0000000000000009 ffff88003c2f3b38 ffffffff8169dbd1 0000000000000001
[   27.050884]  ffff88003c2f3b88 ffff88003c2f3b78 ffffffff8109149c ffff88003c2f3b88
[   27.060959]  ffff880039eb6000 ffff88003b8a8000 ffff880039eb6880 ffff88003b8a8098
[   27.071173] Call Trace:
[   27.074525]  [<ffffffff8169dbd1>] dump_stack+0x46/0x58
[   27.081411]  [<ffffffff8109149c>] warn_slowpath_common+0x8c/0xc0
[   27.089290]  [<ffffffff81091586>] warn_slowpath_fmt+0x46/0x50
[   27.096756]  [<ffffffffa00461c4>] ? igb_reset_interrupt_capability+0x64/0x80 [igb]
[   27.106651]  [<ffffffff8137bded>] bad_io_access+0x3d/0x40
[   27.113785]  [<ffffffff8137be1c>] pci_iounmap+0x2c/0x40
[   27.120619]  [<ffffffffa00489cf>] igb_remove+0xbf/0x160 [igb]
[   27.128161]  [<ffffffff813a0276>] pci_device_remove+0x46/0xc0
[   27.135895]  [<ffffffff81479f8f>] __device_release_driver+0x7f/0xf0
[   27.144748]  [<ffffffff8147a34c>] device_release_driver+0x2c/0x40
[   27.153123]  [<ffffffff81399b4c>] pci_stop_bus_device+0x9c/0xb0
[   27.160951]  [<ffffffff81399cc6>] pci_stop_and_remove_bus_device+0x16/0x30
[   27.170290]  [<ffffffff813b64a7>] disable_slot+0x57/0xb0
[   27.177610]  [<ffffffff813b6521>] acpiphp_disable_and_eject_slot+0x21/0x90
[   27.187063]  [<ffffffff813b7031>] acpiphp_hotplug_notify+0x141/0x220
[   27.195588]  [<ffffffff813b6ef0>] ? acpiphp_post_dock_fixup+0xd0/0xd0
[   27.204205]  [<ffffffff813deb6d>] acpi_device_hotplug+0x3a1/0x3f0
[   27.212677]  [<ffffffff813d8871>] acpi_hotplug_work_fn+0x1f/0x2b
[   27.220853]  [<ffffffff810a8b8c>] process_one_work+0x15c/0x410
[   27.228802]  [<ffffffff810a8f9d>] worker_thread+0x11d/0x520
[   27.238591]  [<ffffffff810a8e80>] ? process_scheduled_works+0x40/0x40
[   27.251911]  [<ffffffff810aed49>] kthread+0xc9/0xe0
[   27.262033]  [<ffffffff810aec80>] ? flush_kthread_worker+0x70/0x70
[   27.274774]  [<ffffffff816a62bc>] ret_from_fork+0x7c/0xb0
[   27.285985]  [<ffffffff810aec80>] ? flush_kthread_worker+0x70/0x70
[   27.298839] ---[ end trace e8838cc146d5f64c ]---

To avoid this we should wait until QEMU has completed device teardown (which, at least
for Linux, happens after the guest is done with its own cleanup).

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/libxl_internal.h |    1 +
 tools/libxl/libxl_pci.c      |   22 ++++++++++++++
 tools/libxl/libxl_qmp.c      |   64 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f61673c..139da3a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1589,6 +1589,7 @@ _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);
+_hidden int libxl__qmp_pci_test(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _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);
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 9f40100..4c6a733 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1246,6 +1246,28 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
             break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
             rc = libxl__qmp_pci_del(gc, domid, pcidev);
+            if (rc < 0)
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "libxl__qmp_pci_del");
+            else {
+                unsigned total_us = 0, wait_us = 100000;
+
+                rc = -ETIMEDOUT;
+                /* Wait (at most ~6 seconds) for device to disappear */
+                do {
+                    int err = libxl__qmp_pci_test(gc, domid, pcidev);
+                    if (err) {
+                        if (err == -ENODEV)
+                            rc = 0;
+                        else
+                            rc = err;
+                        break;
+                    }
+                    usleep(wait_us);
+                    total_us += wait_us;
+                    wait_us *= 2;
+                } while (total_us < 5000000);
+            }
+
             break;
         default:
             rc = ERROR_INVAL;
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index c7324e6..3235c83 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -739,6 +739,41 @@ static int qmp_query_vnc(libxl__qmp_handler *qmp)
                                 NULL, qmp->timeout);
 }
 
+static int pci_exists_callback(libxl__qmp_handler *qmp,
+                            const libxl__json_object *response, void *opaque)
+{
+    libxl_device_pci *pcidev = opaque;
+    const libxl__json_object *bus;
+    GC_INIT(qmp->ctx);
+    int i, j, rc = -ENODEV;
+    char *asked_id = GCSPRINTF(PCI_PT_QDEV_ID,
+                               pcidev->bus, pcidev->dev, pcidev->func);
+
+    for (i = 0; (bus = libxl__json_array_get(response, i)); i++) {
+        const libxl__json_object *devices = NULL;
+        const libxl__json_object *device = NULL;
+        const libxl__json_object *o = NULL;
+        const char *id = NULL;
+
+        devices = libxl__json_map_get("devices", bus, JSON_ARRAY);
+
+        for (j = 0; (device = libxl__json_array_get(devices, j)); j++) {
+             o = libxl__json_map_get("qdev_id", device, JSON_STRING);
+             id = libxl__json_object_get_string(o);
+
+             if (id && strcmp(asked_id, id) == 0) {
+                 rc = 0;
+                 goto out;
+             }
+        }
+    }
+
+out:
+    GC_FREE;
+    return rc;
+
+}
+
 static int pci_add_callback(libxl__qmp_handler *qmp,
                             const libxl__json_object *response, void *opaque)
 {
@@ -804,6 +839,35 @@ static int qmp_run_command(libxl__gc *gc, int domid,
     return rc;
 }
 
+int libxl__qmp_pci_test(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
+{
+    libxl__qmp_handler *qmp = NULL;
+    libxl__json_object *args = NULL;
+    char *hostaddr = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(gc, domid);
+    if (!qmp)
+        return -1;
+
+    hostaddr = GCSPRINTF("%04x:%02x:%02x.%01x", pcidev->domain,
+                         pcidev->bus, pcidev->dev, pcidev->func);
+    if (!hostaddr)
+        return -1;
+
+    qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough");
+    QMP_PARAMETERS_SPRINTF(&args, "id", PCI_PT_QDEV_ID,
+                           pcidev->bus, pcidev->dev, pcidev->func);
+    qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr);
+
+    rc = qmp_synchronous_send(qmp, "query-pci", NULL,
+                             pci_exists_callback, pcidev, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+
+}
+
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 10 23:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 23:43:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnybv-0000DJ-Dd; Mon, 10 Nov 2014 23:43:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xnybt-0000DE-BH
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 23:43:01 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	56/AA-25547-48D41645; Mon, 10 Nov 2014 23:43:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415662978!11614970!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12273 invoked from network); 10 Nov 2014 23:42:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 23:42:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,355,1413244800"; d="scan'208";a="189958160"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 18:42:37 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnybU-0000g0-Pu;
	Mon, 10 Nov 2014 23:42:36 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnybU-0005ZV-BS;
	Mon, 10 Nov 2014 23:42:36 +0000
Date: Mon, 10 Nov 2014 23:42:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31470-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31470: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31470 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31470/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 10 23:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Nov 2014 23:43:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xnybv-0000DJ-Dd; Mon, 10 Nov 2014 23:43:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xnybt-0000DE-BH
	for xen-devel@lists.xensource.com; Mon, 10 Nov 2014 23:43:01 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	56/AA-25547-48D41645; Mon, 10 Nov 2014 23:43:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415662978!11614970!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12273 invoked from network); 10 Nov 2014 23:42:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 23:42:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,355,1413244800"; d="scan'208";a="189958160"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 18:42:37 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnybU-0000g0-Pu;
	Mon, 10 Nov 2014 23:42:36 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnybU-0005ZV-BS;
	Mon, 10 Nov 2014 23:42:36 +0000
Date: Mon, 10 Nov 2014 23:42:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31470-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31470: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31470 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31470/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 11 00:05:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 00:05:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnyxE-000171-U4; Tue, 11 Nov 2014 00:05:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1XnyxD-00016w-VP
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 00:05:04 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	25/BA-24124-FA251645; Tue, 11 Nov 2014 00:05:03 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415664301!11638905!1
X-Originating-IP: [209.85.213.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19596 invoked from network); 11 Nov 2014 00:05:02 -0000
Received: from mail-ig0-f175.google.com (HELO mail-ig0-f175.google.com)
	(209.85.213.175)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 00:05:02 -0000
Received: by mail-ig0-f175.google.com with SMTP id h3so64848igd.2
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 16:05:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=Z1Zu6/tzwWog9VTjDtFobYbvzFVRBeDgXKmth/WugsU=;
	b=B2tMIV+r87pQPWjx8QkERih2DgUEURIFr603SXto6LNmMQ6HE5UFymmdX6wSp3FTVX
	dfdpBB8hgbLjZAN26CGBenSl+2Cqt3SC0XamY6BkI1qb4IB6pjLhTRA07ilg8o4UpOZg
	OTb5zQcjDME6UvpFiig0MJDlHkHh1ajl/8LjrNmkHghuDV+u8+LwZK3BQwszIeqsLmuJ
	z88Z5dI0JobL4eWolCGpkDk/Bat25pTLCZCrBWpG7BZInAhJFOMkCz2LqYCWn9qsmej3
	RP/K2gtXg5zDj92LbKOEi9QLU6HWDmGZso5A5b44eEAvKEmDWsAARQ6vROsDbk5Mmien
	F4dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=Z1Zu6/tzwWog9VTjDtFobYbvzFVRBeDgXKmth/WugsU=;
	b=gsEy1LJurddr1UA2MMki3cryJ0UkN89F1+UqA6VurfN1IEB1FaaaRlF/1A4ZhOYKlZ
	8xYnq33PzQDoCdQc9QrPuUCUFspopAWnnee1phlh/pS7xUrb5ftQEZiGeSdRTJ1taYrH
	0mukW55aqR23UgFr/mfw31zwjYinBbJsOj8R3WxDADDQMYTaNfrdVKcxN8gatlNNRobE
	M3xCKGd2WyeaEIkCxn3/ltD+e+HKAmjZm14xs44a+qNXG6hmAI+MYoQmEkehWzLSVuMA
	nIiyU3Ux0aJtTV5c3kAHWAdt5e3wv3XwIcsX7JPe2spqMWVIlGrxnjZw2zmvGUNmajns
	2kAg==
X-Gm-Message-State: ALoCoQkNAr1HSEqpIE/Q39K9GQv28oXcob6UF4McLkMnsbEWbH0iFDE+Hh9aWP4cd0OBQqyq7pdh
X-Received: by 10.107.135.37 with SMTP id j37mr13063046iod.56.1415664300816;
	Mon, 10 Nov 2014 16:05:00 -0800 (PST)
Received: from google.com ([172.26.48.152])
	by mx.google.com with ESMTPSA id rp5sm5502912igb.19.2014.11.10.16.04.59
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Mon, 10 Nov 2014 16:05:00 -0800 (PST)
Date: Mon, 10 Nov 2014 17:04:56 -0700
From: Bjorn Helgaas <bhelgaas@google.com>
To: Yijing Wang <wangyijing@huawei.com>
Message-ID: <20141111000456.GB21470@google.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<1414377878-23497-2-git-send-email-wangyijing@huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1414377878-23497-2-git-send-email-wangyijing@huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xenproject.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix
 the MSI mask bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> fixed MSI mask bug which may cause kernel crash. But the commit
> made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask"
> to ignore MSI/MSI-X to fix this issue, it's a cleaner solution.
> And the commit 0e4ccb1505a9 will be reverted in the later patch.

The 0e4ccb1505a9 changelog says Xen guests can't write to MSI-X BARs.
But it makes mask_irq a no-op for both MSI-X and MSI.  The MSI mask bit is
in config space, not in memory space.  So why does mask_irq need to be a
no-op for MSI as well?  Are Xen guests prohibited from writing to config
space, too?  (It's fine if they are; it's just that the changelog
specifically mentioned MSI-X memory space tables, and it didn't mention
config space at all.)

And I *assume* there's some Xen mechanism that accomplishes the mask_irq in
a different way, since the actual mask_irq interface does nothing?  (This
is really a question for 0e4ccb1505a9, since I don't think this particular
patch changes anything in that respect.)

> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> CC: David Vrabel <david.vrabel@citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: xen-devel@lists.xenproject.org
> ---
>  arch/x86/pci/xen.c  |    2 ++
>  drivers/pci/msi.c   |    7 ++++++-
>  include/linux/msi.h |    1 +
>  3 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 093f5f4..5ef62ed 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -427,6 +427,7 @@ int __init pci_xen_init(void)
>  	x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
>  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> +	pci_msi_ignore_mask = 1;
>  #endif
>  	return 0;
>  }
> @@ -508,6 +509,7 @@ int __init pci_xen_initial_domain(void)
>  	x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
>  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> +	pci_msi_ignore_mask = 1;
>  #endif
>  	xen_setup_acpi_sci();
>  	__acpi_register_gsi = acpi_register_gsi_xen;
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 38511d9..ecb5f54 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -23,6 +23,7 @@
>  #include "pci.h"
>  
>  static int pci_msi_enable = 1;
> +int pci_msi_ignore_mask;
>  
>  #define msix_table_size(flags)	((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
>  
> @@ -166,7 +167,7 @@ u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
>  {
>  	u32 mask_bits = desc->masked;
>  
> -	if (!desc->msi_attrib.maskbit)
> +	if (pci_msi_ignore_mask || !desc->msi_attrib.maskbit)
>  		return 0;
>  
>  	mask_bits &= ~mask;
> @@ -198,6 +199,10 @@ u32 default_msix_mask_irq(struct msi_desc *desc, u32 flag)
>  	u32 mask_bits = desc->masked;
>  	unsigned offset = desc->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
>  						PCI_MSIX_ENTRY_VECTOR_CTRL;
> +
> +	if (pci_msi_ignore_mask)
> +		return 0;
> +
>  	mask_bits &= ~PCI_MSIX_ENTRY_CTRL_MASKBIT;
>  	if (flag)
>  		mask_bits |= PCI_MSIX_ENTRY_CTRL_MASKBIT;
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 44f4746..86dc501 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -10,6 +10,7 @@ struct msi_msg {
>  	u32	data;		/* 16 bits of msi message data */
>  };
>  
> +extern int pci_msi_ignore_mask;
>  /* Helper functions */
>  struct irq_data;
>  struct msi_desc;
> -- 
> 1.7.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 00:05:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 00:05:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XnyxE-000171-U4; Tue, 11 Nov 2014 00:05:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1XnyxD-00016w-VP
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 00:05:04 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	25/BA-24124-FA251645; Tue, 11 Nov 2014 00:05:03 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415664301!11638905!1
X-Originating-IP: [209.85.213.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19596 invoked from network); 11 Nov 2014 00:05:02 -0000
Received: from mail-ig0-f175.google.com (HELO mail-ig0-f175.google.com)
	(209.85.213.175)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 00:05:02 -0000
Received: by mail-ig0-f175.google.com with SMTP id h3so64848igd.2
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 16:05:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=Z1Zu6/tzwWog9VTjDtFobYbvzFVRBeDgXKmth/WugsU=;
	b=B2tMIV+r87pQPWjx8QkERih2DgUEURIFr603SXto6LNmMQ6HE5UFymmdX6wSp3FTVX
	dfdpBB8hgbLjZAN26CGBenSl+2Cqt3SC0XamY6BkI1qb4IB6pjLhTRA07ilg8o4UpOZg
	OTb5zQcjDME6UvpFiig0MJDlHkHh1ajl/8LjrNmkHghuDV+u8+LwZK3BQwszIeqsLmuJ
	z88Z5dI0JobL4eWolCGpkDk/Bat25pTLCZCrBWpG7BZInAhJFOMkCz2LqYCWn9qsmej3
	RP/K2gtXg5zDj92LbKOEi9QLU6HWDmGZso5A5b44eEAvKEmDWsAARQ6vROsDbk5Mmien
	F4dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=Z1Zu6/tzwWog9VTjDtFobYbvzFVRBeDgXKmth/WugsU=;
	b=gsEy1LJurddr1UA2MMki3cryJ0UkN89F1+UqA6VurfN1IEB1FaaaRlF/1A4ZhOYKlZ
	8xYnq33PzQDoCdQc9QrPuUCUFspopAWnnee1phlh/pS7xUrb5ftQEZiGeSdRTJ1taYrH
	0mukW55aqR23UgFr/mfw31zwjYinBbJsOj8R3WxDADDQMYTaNfrdVKcxN8gatlNNRobE
	M3xCKGd2WyeaEIkCxn3/ltD+e+HKAmjZm14xs44a+qNXG6hmAI+MYoQmEkehWzLSVuMA
	nIiyU3Ux0aJtTV5c3kAHWAdt5e3wv3XwIcsX7JPe2spqMWVIlGrxnjZw2zmvGUNmajns
	2kAg==
X-Gm-Message-State: ALoCoQkNAr1HSEqpIE/Q39K9GQv28oXcob6UF4McLkMnsbEWbH0iFDE+Hh9aWP4cd0OBQqyq7pdh
X-Received: by 10.107.135.37 with SMTP id j37mr13063046iod.56.1415664300816;
	Mon, 10 Nov 2014 16:05:00 -0800 (PST)
Received: from google.com ([172.26.48.152])
	by mx.google.com with ESMTPSA id rp5sm5502912igb.19.2014.11.10.16.04.59
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Mon, 10 Nov 2014 16:05:00 -0800 (PST)
Date: Mon, 10 Nov 2014 17:04:56 -0700
From: Bjorn Helgaas <bhelgaas@google.com>
To: Yijing Wang <wangyijing@huawei.com>
Message-ID: <20141111000456.GB21470@google.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<1414377878-23497-2-git-send-email-wangyijing@huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1414377878-23497-2-git-send-email-wangyijing@huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xenproject.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix
 the MSI mask bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> fixed MSI mask bug which may cause kernel crash. But the commit
> made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask"
> to ignore MSI/MSI-X to fix this issue, it's a cleaner solution.
> And the commit 0e4ccb1505a9 will be reverted in the later patch.

The 0e4ccb1505a9 changelog says Xen guests can't write to MSI-X BARs.
But it makes mask_irq a no-op for both MSI-X and MSI.  The MSI mask bit is
in config space, not in memory space.  So why does mask_irq need to be a
no-op for MSI as well?  Are Xen guests prohibited from writing to config
space, too?  (It's fine if they are; it's just that the changelog
specifically mentioned MSI-X memory space tables, and it didn't mention
config space at all.)

And I *assume* there's some Xen mechanism that accomplishes the mask_irq in
a different way, since the actual mask_irq interface does nothing?  (This
is really a question for 0e4ccb1505a9, since I don't think this particular
patch changes anything in that respect.)

> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> CC: David Vrabel <david.vrabel@citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: xen-devel@lists.xenproject.org
> ---
>  arch/x86/pci/xen.c  |    2 ++
>  drivers/pci/msi.c   |    7 ++++++-
>  include/linux/msi.h |    1 +
>  3 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 093f5f4..5ef62ed 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -427,6 +427,7 @@ int __init pci_xen_init(void)
>  	x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
>  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> +	pci_msi_ignore_mask = 1;
>  #endif
>  	return 0;
>  }
> @@ -508,6 +509,7 @@ int __init pci_xen_initial_domain(void)
>  	x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
>  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> +	pci_msi_ignore_mask = 1;
>  #endif
>  	xen_setup_acpi_sci();
>  	__acpi_register_gsi = acpi_register_gsi_xen;
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 38511d9..ecb5f54 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -23,6 +23,7 @@
>  #include "pci.h"
>  
>  static int pci_msi_enable = 1;
> +int pci_msi_ignore_mask;
>  
>  #define msix_table_size(flags)	((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
>  
> @@ -166,7 +167,7 @@ u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
>  {
>  	u32 mask_bits = desc->masked;
>  
> -	if (!desc->msi_attrib.maskbit)
> +	if (pci_msi_ignore_mask || !desc->msi_attrib.maskbit)
>  		return 0;
>  
>  	mask_bits &= ~mask;
> @@ -198,6 +199,10 @@ u32 default_msix_mask_irq(struct msi_desc *desc, u32 flag)
>  	u32 mask_bits = desc->masked;
>  	unsigned offset = desc->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
>  						PCI_MSIX_ENTRY_VECTOR_CTRL;
> +
> +	if (pci_msi_ignore_mask)
> +		return 0;
> +
>  	mask_bits &= ~PCI_MSIX_ENTRY_CTRL_MASKBIT;
>  	if (flag)
>  		mask_bits |= PCI_MSIX_ENTRY_CTRL_MASKBIT;
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 44f4746..86dc501 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -10,6 +10,7 @@ struct msi_msg {
>  	u32	data;		/* 16 bits of msi message data */
>  };
>  
> +extern int pci_msi_ignore_mask;
>  /* Helper functions */
>  struct irq_data;
>  struct msi_desc;
> -- 
> 1.7.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 00:38:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 00: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 1XnzTE-0001Y3-Os; Tue, 11 Nov 2014 00:38:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnzTD-0001Xv-Fh
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 00:38:07 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	25/56-22777-E6A51645; Tue, 11 Nov 2014 00:38:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415666284!8757073!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15768 invoked from network); 11 Nov 2014 00:38:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 00:38:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,356,1413244800"; d="scan'208";a="189972790"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 19:38:03 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnzT9-0000wn-3r;
	Tue, 11 Nov 2014 00:38:03 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnzT6-0006MB-SO;
	Tue, 11 Nov 2014 00:38:00 +0000
Date: Tue, 11 Nov 2014 00:38:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31469-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31469: 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 31469 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31469/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10  fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10  fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 build-i386-pvops              5 kernel-build            fail baseline untested
 test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-winxpsp3  7 windows-install         fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a

version targeted for testing:
 linux                d54c9f9e6831cf1145b88af2dc4bdf272a254607
baseline version:
 linux                980d0d51b1c9617a472b2c0fcbe33d2d15eadc4c

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 00:38:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 00: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 1XnzTE-0001Y3-Os; Tue, 11 Nov 2014 00:38:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XnzTD-0001Xv-Fh
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 00:38:07 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	25/56-22777-E6A51645; Tue, 11 Nov 2014 00:38:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415666284!8757073!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15768 invoked from network); 11 Nov 2014 00:38:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 00:38:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,356,1413244800"; d="scan'208";a="189972790"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 19:38:03 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XnzT9-0000wn-3r;
	Tue, 11 Nov 2014 00:38:03 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XnzT6-0006MB-SO;
	Tue, 11 Nov 2014 00:38:00 +0000
Date: Tue, 11 Nov 2014 00:38:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31469-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31469: 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 31469 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31469/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10  fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10  fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 build-i386-pvops              5 kernel-build            fail baseline untested
 test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-winxpsp3  7 windows-install         fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a

version targeted for testing:
 linux                d54c9f9e6831cf1145b88af2dc4bdf272a254607
baseline version:
 linux                980d0d51b1c9617a472b2c0fcbe33d2d15eadc4c

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 01:50:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 01:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo0aU-0006Lz-KN; Tue, 11 Nov 2014 01:49:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangyijing@huawei.com>) id 1Xo0aT-0006Lu-40
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 01:49:41 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	8A/F8-02696-43B61645; Tue, 11 Nov 2014 01:49:40 +0000
X-Env-Sender: wangyijing@huawei.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415670575!7197993!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 749 invoked from network); 11 Nov 2014 01:49:39 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 01:49:39 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWX34890; Tue, 11 Nov 2014 09:49:30 +0800 (CST)
Received: from [127.0.0.1] (10.177.27.212) by szxeml460-hub.china.huawei.com
	(10.82.67.203) with Microsoft SMTP Server id 14.3.158.1;
	Tue, 11 Nov 2014 09:49:27 +0800
Message-ID: <54616B26.5000902@huawei.com>
Date: Tue, 11 Nov 2014 09:49:26 +0800
From: Yijing Wang <wangyijing@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Bjorn Helgaas <bhelgaas@google.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<1414377878-23497-2-git-send-email-wangyijing@huawei.com>
	<20141111000456.GB21470@google.com>
In-Reply-To: <20141111000456.GB21470@google.com>
X-Originating-IP: [10.177.27.212]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020207.54616B2B.0167, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 3bf67c94324343db3076463102d461a5
Cc: linux-pci@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix
 the MSI mask bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/11 8:04, Bjorn Helgaas wrote:
> On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
>> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
>> fixed MSI mask bug which may cause kernel crash. But the commit
>> made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask"
>> to ignore MSI/MSI-X to fix this issue, it's a cleaner solution.
>> And the commit 0e4ccb1505a9 will be reverted in the later patch.
> 
> The 0e4ccb1505a9 changelog says Xen guests can't write to MSI-X BARs.
> But it makes mask_irq a no-op for both MSI-X and MSI.  The MSI mask bit is
> in config space, not in memory space.  So why does mask_irq need to be a
> no-op for MSI as well?  Are Xen guests prohibited from writing to config
> space, too?  (It's fine if they are; it's just that the changelog
> specifically mentioned MSI-X memory space tables, and it didn't mention
> config space at all.)
> 
> And I *assume* there's some Xen mechanism that accomplishes the mask_irq in
> a different way, since the actual mask_irq interface does nothing?  (This
> is really a question for 0e4ccb1505a9, since I don't think this particular
> patch changes anything in that respect.)

Yes, it's another history problem, maybe Konrad know the detail.

> 
>> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
>> CC: David Vrabel <david.vrabel@citrix.com>
>> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> CC: xen-devel@lists.xenproject.org
>> ---
>>  arch/x86/pci/xen.c  |    2 ++
>>  drivers/pci/msi.c   |    7 ++++++-
>>  include/linux/msi.h |    1 +
>>  3 files changed, 9 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>> index 093f5f4..5ef62ed 100644
>> --- a/arch/x86/pci/xen.c
>> +++ b/arch/x86/pci/xen.c
>> @@ -427,6 +427,7 @@ int __init pci_xen_init(void)
>>  	x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
>>  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>>  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
>> +	pci_msi_ignore_mask = 1;
>>  #endif
>>  	return 0;
>>  }
>> @@ -508,6 +509,7 @@ int __init pci_xen_initial_domain(void)
>>  	x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
>>  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>>  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
>> +	pci_msi_ignore_mask = 1;
>>  #endif
>>  	xen_setup_acpi_sci();
>>  	__acpi_register_gsi = acpi_register_gsi_xen;
>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>> index 38511d9..ecb5f54 100644
>> --- a/drivers/pci/msi.c
>> +++ b/drivers/pci/msi.c
>> @@ -23,6 +23,7 @@
>>  #include "pci.h"
>>  
>>  static int pci_msi_enable = 1;
>> +int pci_msi_ignore_mask;
>>  
>>  #define msix_table_size(flags)	((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
>>  
>> @@ -166,7 +167,7 @@ u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
>>  {
>>  	u32 mask_bits = desc->masked;
>>  
>> -	if (!desc->msi_attrib.maskbit)
>> +	if (pci_msi_ignore_mask || !desc->msi_attrib.maskbit)
>>  		return 0;
>>  
>>  	mask_bits &= ~mask;
>> @@ -198,6 +199,10 @@ u32 default_msix_mask_irq(struct msi_desc *desc, u32 flag)
>>  	u32 mask_bits = desc->masked;
>>  	unsigned offset = desc->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
>>  						PCI_MSIX_ENTRY_VECTOR_CTRL;
>> +
>> +	if (pci_msi_ignore_mask)
>> +		return 0;
>> +
>>  	mask_bits &= ~PCI_MSIX_ENTRY_CTRL_MASKBIT;
>>  	if (flag)
>>  		mask_bits |= PCI_MSIX_ENTRY_CTRL_MASKBIT;
>> diff --git a/include/linux/msi.h b/include/linux/msi.h
>> index 44f4746..86dc501 100644
>> --- a/include/linux/msi.h
>> +++ b/include/linux/msi.h
>> @@ -10,6 +10,7 @@ struct msi_msg {
>>  	u32	data;		/* 16 bits of msi message data */
>>  };
>>  
>> +extern int pci_msi_ignore_mask;
>>  /* Helper functions */
>>  struct irq_data;
>>  struct msi_desc;
>> -- 
>> 1.7.1
>>
> 
> .
> 


-- 
Thanks!
Yijing


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 01:50:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 01:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo0aU-0006Lz-KN; Tue, 11 Nov 2014 01:49:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangyijing@huawei.com>) id 1Xo0aT-0006Lu-40
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 01:49:41 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	8A/F8-02696-43B61645; Tue, 11 Nov 2014 01:49:40 +0000
X-Env-Sender: wangyijing@huawei.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415670575!7197993!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 749 invoked from network); 11 Nov 2014 01:49:39 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 01:49:39 -0000
Received: from 172.24.2.119 (EHLO szxeml460-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AWX34890; Tue, 11 Nov 2014 09:49:30 +0800 (CST)
Received: from [127.0.0.1] (10.177.27.212) by szxeml460-hub.china.huawei.com
	(10.82.67.203) with Microsoft SMTP Server id 14.3.158.1;
	Tue, 11 Nov 2014 09:49:27 +0800
Message-ID: <54616B26.5000902@huawei.com>
Date: Tue, 11 Nov 2014 09:49:26 +0800
From: Yijing Wang <wangyijing@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Bjorn Helgaas <bhelgaas@google.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<1414377878-23497-2-git-send-email-wangyijing@huawei.com>
	<20141111000456.GB21470@google.com>
In-Reply-To: <20141111000456.GB21470@google.com>
X-Originating-IP: [10.177.27.212]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020207.54616B2B.0167, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 3bf67c94324343db3076463102d461a5
Cc: linux-pci@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix
 the MSI mask bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/11 8:04, Bjorn Helgaas wrote:
> On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
>> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
>> fixed MSI mask bug which may cause kernel crash. But the commit
>> made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask"
>> to ignore MSI/MSI-X to fix this issue, it's a cleaner solution.
>> And the commit 0e4ccb1505a9 will be reverted in the later patch.
> 
> The 0e4ccb1505a9 changelog says Xen guests can't write to MSI-X BARs.
> But it makes mask_irq a no-op for both MSI-X and MSI.  The MSI mask bit is
> in config space, not in memory space.  So why does mask_irq need to be a
> no-op for MSI as well?  Are Xen guests prohibited from writing to config
> space, too?  (It's fine if they are; it's just that the changelog
> specifically mentioned MSI-X memory space tables, and it didn't mention
> config space at all.)
> 
> And I *assume* there's some Xen mechanism that accomplishes the mask_irq in
> a different way, since the actual mask_irq interface does nothing?  (This
> is really a question for 0e4ccb1505a9, since I don't think this particular
> patch changes anything in that respect.)

Yes, it's another history problem, maybe Konrad know the detail.

> 
>> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
>> CC: David Vrabel <david.vrabel@citrix.com>
>> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> CC: xen-devel@lists.xenproject.org
>> ---
>>  arch/x86/pci/xen.c  |    2 ++
>>  drivers/pci/msi.c   |    7 ++++++-
>>  include/linux/msi.h |    1 +
>>  3 files changed, 9 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>> index 093f5f4..5ef62ed 100644
>> --- a/arch/x86/pci/xen.c
>> +++ b/arch/x86/pci/xen.c
>> @@ -427,6 +427,7 @@ int __init pci_xen_init(void)
>>  	x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
>>  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>>  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
>> +	pci_msi_ignore_mask = 1;
>>  #endif
>>  	return 0;
>>  }
>> @@ -508,6 +509,7 @@ int __init pci_xen_initial_domain(void)
>>  	x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
>>  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>>  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
>> +	pci_msi_ignore_mask = 1;
>>  #endif
>>  	xen_setup_acpi_sci();
>>  	__acpi_register_gsi = acpi_register_gsi_xen;
>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>> index 38511d9..ecb5f54 100644
>> --- a/drivers/pci/msi.c
>> +++ b/drivers/pci/msi.c
>> @@ -23,6 +23,7 @@
>>  #include "pci.h"
>>  
>>  static int pci_msi_enable = 1;
>> +int pci_msi_ignore_mask;
>>  
>>  #define msix_table_size(flags)	((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
>>  
>> @@ -166,7 +167,7 @@ u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
>>  {
>>  	u32 mask_bits = desc->masked;
>>  
>> -	if (!desc->msi_attrib.maskbit)
>> +	if (pci_msi_ignore_mask || !desc->msi_attrib.maskbit)
>>  		return 0;
>>  
>>  	mask_bits &= ~mask;
>> @@ -198,6 +199,10 @@ u32 default_msix_mask_irq(struct msi_desc *desc, u32 flag)
>>  	u32 mask_bits = desc->masked;
>>  	unsigned offset = desc->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
>>  						PCI_MSIX_ENTRY_VECTOR_CTRL;
>> +
>> +	if (pci_msi_ignore_mask)
>> +		return 0;
>> +
>>  	mask_bits &= ~PCI_MSIX_ENTRY_CTRL_MASKBIT;
>>  	if (flag)
>>  		mask_bits |= PCI_MSIX_ENTRY_CTRL_MASKBIT;
>> diff --git a/include/linux/msi.h b/include/linux/msi.h
>> index 44f4746..86dc501 100644
>> --- a/include/linux/msi.h
>> +++ b/include/linux/msi.h
>> @@ -10,6 +10,7 @@ struct msi_msg {
>>  	u32	data;		/* 16 bits of msi message data */
>>  };
>>  
>> +extern int pci_msi_ignore_mask;
>>  /* Helper functions */
>>  struct irq_data;
>>  struct msi_desc;
>> -- 
>> 1.7.1
>>
> 
> .
> 


-- 
Thanks!
Yijing


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 02:48:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 02: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 1Xo1VW-0007Pn-9i; Tue, 11 Nov 2014 02:48:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xo1VV-0007Pi-2L
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 02:48:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	63/61-24532-40971645; Tue, 11 Nov 2014 02:48:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415674114!12859648!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30657 invoked from network); 11 Nov 2014 02:48:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 02:48:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,357,1413244800"; d="scan'208";a="189991434"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 21:48:32 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xo1VQ-0001Zy-Gf;
	Tue, 11 Nov 2014 02:48:32 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xo1VQ-0001ir-BP;
	Tue, 11 Nov 2014 02:48:32 +0000
Date: Tue, 11 Nov 2014 02:48:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31471-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31471: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31471 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31471/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                206c5f60a3d902bc4b56dab2de3e88de5eb06108
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
430 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 14843 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 Nov 11 02:48:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 02: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 1Xo1VW-0007Pn-9i; Tue, 11 Nov 2014 02:48:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xo1VV-0007Pi-2L
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 02:48:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	63/61-24532-40971645; Tue, 11 Nov 2014 02:48:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415674114!12859648!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30657 invoked from network); 11 Nov 2014 02:48:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 02:48:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,357,1413244800"; d="scan'208";a="189991434"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 10 Nov 2014 21:48:32 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xo1VQ-0001Zy-Gf;
	Tue, 11 Nov 2014 02:48:32 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xo1VQ-0001ir-BP;
	Tue, 11 Nov 2014 02:48:32 +0000
Date: Tue, 11 Nov 2014 02:48:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31471-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31471: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31471 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31471/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                206c5f60a3d902bc4b56dab2de3e88de5eb06108
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
430 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 14843 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 Nov 11 03:32:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 03: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 1Xo2BK-00083V-3n; Tue, 11 Nov 2014 03:31:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Xo2BH-00081Z-W0
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 03:31:48 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	C4/2A-02712-32381645; Tue, 11 Nov 2014 03:31:47 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415676704!12623596!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28002 invoked from network); 11 Nov 2014 03:31:45 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-27.messagelabs.com with SMTP;
	11 Nov 2014 03:31:45 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Nov 2014 19:31:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,357,1413270000"; d="scan'208";a="634830788"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 10 Nov 2014 19:31:41 -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.3.195.1; Tue, 11 Nov 2014 11:30:55 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.62]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.136]) with mapi id
	14.03.0195.001; Tue, 11 Nov 2014 11:30:54 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
	disables it.
Thread-Index: AQHPEi3cJLkYs2VhL0qN3zw8dITRcJxbIWYAgAAhYgCAAViQ0A==
Date: Tue, 11 Nov 2014 03:30:54 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABDACCC@SHSMSX104.ccr.corp.intel.com>
References: <20140110184151.GA20232@pegasus.dumpdata.com>
	<1389607803.8187.22.camel@kazak.uk.xensource.com>
	<52D3DC730200007800112FF6@nat28.tlf.novell.com>
	<1389613109.13654.43.camel@kazak.uk.xensource.com>
	<52D3E1500200007800113058@nat28.tlf.novell.com>
	<20140115200736.GB5201@phenom.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABD8C46@SHSMSX104.ccr.corp.intel.com>
	<20141110145720.GH3783@laptop.dumpdata.com>
In-Reply-To: <20141110145720.GH3783@laptop.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: Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Li, Liang Z" <liang.z.li@intel.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "Nakajima, Jun" <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables 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

Konrad Rzeszutek Wilk wrote on 2014-11-10:
> On Mon, Nov 10, 2014 at 05:08:09AM +0000, Zhang, Yang Z wrote:
>> Konrad Rzeszutek Wilk wrote on 2014-01-16:
>>> On Mon, Jan 13, 2014 at 11:51:28AM +0000, Jan Beulich wrote:
>>>>>>> On 13.01.14 at 12:38, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
>>>>> On Mon, 2014-01-13 at 11:30 +0000, Jan Beulich wrote:
>>>>>> In fact I can't see where this would be forced off:
>>>>>> xc_cpuid_x86.c only does so in the PV case, and all
>>>>>> hvm_pse1gb_supported() is that the CPU supports it and the
>>>>>> domain
> uses HAP.
>>>>> 
>>>>> Took me a while to spot it too:
>>>>> static void intel_xc_cpuid_policy( [...]
>>>>>             case 0x80000001: {
>>>>>                 int is_64bit = hypervisor_is_64bit(xch) &&
>>>>> is_pae;
>>>>> 
>>>>>                 /* Only a few features are advertised in Intel's
>>>>>                 0x80000001. */ regs[2] &= (is_64bit ?
>>> bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
>>>>> 
>>> bitmaskof(X86_FEATURE_ABM);
>>>>>                 regs[3] &= ((is_pae ? bitmaskof(X86_FEATURE_NX) :
>>>>> 0)
>>> |
>>>>>                             (is_64bit ? bitmaskof(X86_FEATURE_LM) :
>>>>>                             0) | (is_64bit ?
>>>>>                             bitmaskof(X86_FEATURE_SYSCALL) : 0) |
>>>>>                             (is_64bit ?
>>> bitmaskof(X86_FEATURE_RDTSCP) : 0));
>>>>>                 break;
>>>>>             }
>>>>> Which masks anything which is not explicitly mentioned. (PAGE1GB
>>>>> is in regs[3], I think).
>>>> 
>>>> Ah, okay. The funs of white listing on HVM vs black listing on PV
>>>> again.
>>>> 
>>>>> The AMD version is more permissive:
>>>>> 
>>>>>         regs[3] &= (0x0183f3ff | /* features shared with
>>> 0x00000001:EDX */
>>>>>                     (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
>>>>>                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
>>>>>                     bitmaskof(X86_FEATURE_SYSCALL) |
>>>>>                     bitmaskof(X86_FEATURE_MP) |
>>>>>                     bitmaskof(X86_FEATURE_MMXEXT) |
>>>>>                     bitmaskof(X86_FEATURE_FFXSR) |
>>>>>                     bitmaskof(X86_FEATURE_3DNOW) |
>>>>>                     bitmaskof(X86_FEATURE_3DNOWEXT)); (but I
>>>>> didn't check if PAGE1GB is in that magic number...)
>>>> 
>>>> It's not - it's bit 26.
>>> 
>>> So.. it sounds to me like everybody is in the agreement that this
>>> is the right thing to do (enable it if the hypervisor has it enabled)?
>>> 
>>> And the next thing is actually come up with a patch to do some of
>>> this plumbing - naturally for Xen 4.5?
>> 
>> Hi, Konrad,
>> 
>> Is there any patch to turn on the 1GB hugepages? If no, we are happy
>> to give
> a patch to do it.
> 
> I have not see a patch for this, and I would be quite happy to see
> patch developed for this!

OK. We will provide a patch ASAP.

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 03:32:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 03: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 1Xo2BK-00083V-3n; Tue, 11 Nov 2014 03:31:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Xo2BH-00081Z-W0
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 03:31:48 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	C4/2A-02712-32381645; Tue, 11 Nov 2014 03:31:47 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415676704!12623596!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28002 invoked from network); 11 Nov 2014 03:31:45 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-27.messagelabs.com with SMTP;
	11 Nov 2014 03:31:45 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Nov 2014 19:31:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,357,1413270000"; d="scan'208";a="634830788"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 10 Nov 2014 19:31:41 -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.3.195.1; Tue, 11 Nov 2014 11:30:55 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.62]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.136]) with mapi id
	14.03.0195.001; Tue, 11 Nov 2014 11:30:54 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
	disables it.
Thread-Index: AQHPEi3cJLkYs2VhL0qN3zw8dITRcJxbIWYAgAAhYgCAAViQ0A==
Date: Tue, 11 Nov 2014 03:30:54 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABDACCC@SHSMSX104.ccr.corp.intel.com>
References: <20140110184151.GA20232@pegasus.dumpdata.com>
	<1389607803.8187.22.camel@kazak.uk.xensource.com>
	<52D3DC730200007800112FF6@nat28.tlf.novell.com>
	<1389613109.13654.43.camel@kazak.uk.xensource.com>
	<52D3E1500200007800113058@nat28.tlf.novell.com>
	<20140115200736.GB5201@phenom.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABD8C46@SHSMSX104.ccr.corp.intel.com>
	<20141110145720.GH3783@laptop.dumpdata.com>
In-Reply-To: <20141110145720.GH3783@laptop.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: Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Li, Liang Z" <liang.z.li@intel.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "Nakajima, Jun" <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables 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

Konrad Rzeszutek Wilk wrote on 2014-11-10:
> On Mon, Nov 10, 2014 at 05:08:09AM +0000, Zhang, Yang Z wrote:
>> Konrad Rzeszutek Wilk wrote on 2014-01-16:
>>> On Mon, Jan 13, 2014 at 11:51:28AM +0000, Jan Beulich wrote:
>>>>>>> On 13.01.14 at 12:38, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
>>>>> On Mon, 2014-01-13 at 11:30 +0000, Jan Beulich wrote:
>>>>>> In fact I can't see where this would be forced off:
>>>>>> xc_cpuid_x86.c only does so in the PV case, and all
>>>>>> hvm_pse1gb_supported() is that the CPU supports it and the
>>>>>> domain
> uses HAP.
>>>>> 
>>>>> Took me a while to spot it too:
>>>>> static void intel_xc_cpuid_policy( [...]
>>>>>             case 0x80000001: {
>>>>>                 int is_64bit = hypervisor_is_64bit(xch) &&
>>>>> is_pae;
>>>>> 
>>>>>                 /* Only a few features are advertised in Intel's
>>>>>                 0x80000001. */ regs[2] &= (is_64bit ?
>>> bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
>>>>> 
>>> bitmaskof(X86_FEATURE_ABM);
>>>>>                 regs[3] &= ((is_pae ? bitmaskof(X86_FEATURE_NX) :
>>>>> 0)
>>> |
>>>>>                             (is_64bit ? bitmaskof(X86_FEATURE_LM) :
>>>>>                             0) | (is_64bit ?
>>>>>                             bitmaskof(X86_FEATURE_SYSCALL) : 0) |
>>>>>                             (is_64bit ?
>>> bitmaskof(X86_FEATURE_RDTSCP) : 0));
>>>>>                 break;
>>>>>             }
>>>>> Which masks anything which is not explicitly mentioned. (PAGE1GB
>>>>> is in regs[3], I think).
>>>> 
>>>> Ah, okay. The funs of white listing on HVM vs black listing on PV
>>>> again.
>>>> 
>>>>> The AMD version is more permissive:
>>>>> 
>>>>>         regs[3] &= (0x0183f3ff | /* features shared with
>>> 0x00000001:EDX */
>>>>>                     (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
>>>>>                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
>>>>>                     bitmaskof(X86_FEATURE_SYSCALL) |
>>>>>                     bitmaskof(X86_FEATURE_MP) |
>>>>>                     bitmaskof(X86_FEATURE_MMXEXT) |
>>>>>                     bitmaskof(X86_FEATURE_FFXSR) |
>>>>>                     bitmaskof(X86_FEATURE_3DNOW) |
>>>>>                     bitmaskof(X86_FEATURE_3DNOWEXT)); (but I
>>>>> didn't check if PAGE1GB is in that magic number...)
>>>> 
>>>> It's not - it's bit 26.
>>> 
>>> So.. it sounds to me like everybody is in the agreement that this
>>> is the right thing to do (enable it if the hypervisor has it enabled)?
>>> 
>>> And the next thing is actually come up with a patch to do some of
>>> this plumbing - naturally for Xen 4.5?
>> 
>> Hi, Konrad,
>> 
>> Is there any patch to turn on the 1GB hugepages? If no, we are happy
>> to give
> a patch to do it.
> 
> I have not see a patch for this, and I would be quite happy to see
> patch developed for this!

OK. We will provide a patch ASAP.

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 04:07:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 04: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 1Xo2jm-00007T-N7; Tue, 11 Nov 2014 04:07:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1Xo2jk-00007O-Su
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 04:07:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E6/37-09936-C7B81645; Tue, 11 Nov 2014 04:07:24 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415678842!12842815!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9272 invoked from network); 11 Nov 2014 04:07:23 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 04:07:23 -0000
Received: by mail-ie0-f173.google.com with SMTP id tr6so10673575ieb.18
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 20:07:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=8+wzEfyc/r1NMzfv0uNtqJbpUGLpL7G3gCFYTG7A7t4=;
	b=dpIUOsIDbaSnL1neuiKluh3Kjo1JINxuB3bKgII4iFUiV4Q3KPSSog7eNsOGcoXR20
	yUZ6cthNVDvyUfR0DjzDrJ3EzjaFxK5DF8ixJuZFuZccaF7mt6kRFbZvLRcRFat6KJKo
	3Ictbhbl5iLalYLWvxUuy9u4os9h5N0IlbChxJPmTaN7pAyXKzbSwsuCtfed41fT3e2y
	PxFJWfqmnrruRdWit49IL3Jdn2NkP2Xa1+NolRAiF5FJKUcD4/Vna6nEy6znEtnaILwi
	6+SkYcOCAU0MBhnVrbI8gehh9qSLWWqAqYfnn2sbTF6tKuI1GbDyO0ISisfZdosNaxje
	gPnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=8+wzEfyc/r1NMzfv0uNtqJbpUGLpL7G3gCFYTG7A7t4=;
	b=Cm3PwQlpHhJUX4nIMJelmADeBv7EqdTv/HkZxJY86OL2zzdc2ObcVK4u5U2BDzhP7g
	uL5trxC1NW2mPnEfyJwLT183xVh8annuRqBDYwn1CHb56Hf6i9gbGDNDhRYsolnE10fM
	Zj+7bcApHZanYVZxAdYX+OIwFLYXFXo7i6MyswZ2YbchSoEAFpZBv9ZvNHA9jks7aI9R
	D1ZYketePiQlbpk7QF2MSkJ8Xh44DiJMgOZFAroFARCJKhkR7+2D2sSocgUy5bcY2jnp
	ZLp5SsCtRDwM/5ovAYHGgpe1a39Nh2iHyZ0pOan3uIDWBzlWZx2Oit+ztZ782IGaKdJw
	up7g==
X-Gm-Message-State: ALoCoQlvJ5Rf8fHYYLfJkMxZ3bvRVZjgq97+91z08FyLxsvHBuNFWsxGPRmS0g9RQ9lSS+lqWvdi
X-Received: by 10.107.41.199 with SMTP id p190mr39274120iop.10.1415678842145; 
	Mon, 10 Nov 2014 20:07:22 -0800 (PST)
Received: from google.com ([172.26.48.152])
	by mx.google.com with ESMTPSA id b32sm9267134ioj.26.2014.11.10.20.07.19
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Mon, 10 Nov 2014 20:07:21 -0800 (PST)
Date: Mon, 10 Nov 2014 21:07:17 -0700
From: Bjorn Helgaas <bhelgaas@google.com>
To: SF Markus Elfring <elfring@users.sourceforge.net>
Message-ID: <20141111040717.GD28161@google.com>
References: <530C5E18.1020800@users.sourceforge.net>
	<alpine.DEB.2.10.1402251014170.2080@hadrien>
	<530CD2C4.4050903@users.sourceforge.net>
	<alpine.DEB.2.10.1402251840450.7035@hadrien>
	<530CF8FF.8080600@users.sourceforge.net>
	<alpine.DEB.2.02.1402252117150.2047@localhost6.localdomain6>
	<530DD06F.4090703@users.sourceforge.net>
	<alpine.DEB.2.02.1402262129250.2221@localhost6.localdomain6>
	<5317A59D.4@users.sourceforge.net>
	<545649DE.80304@users.sourceforge.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545649DE.80304@users.sourceforge.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: kernel-janitors@vger.kernel.org, trivial@kernel.org,
	linux-pci@vger.kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Coccinelle <cocci@systeme.lip6.fr>, Len Brown <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] PCI: Deletion of unnecessary checks
 before three function calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Nov 02, 2014 at 04:12:30PM +0100, SF Markus Elfring wrote:
> The functions pci_dev_put(), pci_pme_wakeup_bus() and put_device() test
> whether their argument is NULL and then return immediately. Thus the test
> around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

Applied to pci/misc for v3.19, thanks!

> ---
>  drivers/pci/pci-acpi.c     | 3 +--
>  drivers/pci/probe.c        | 3 +--
>  drivers/pci/search.c       | 3 +--
>  drivers/pci/xen-pcifront.c | 3 +--
>  4 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> index 37263b0..a8fe5de 100644
> --- a/drivers/pci/pci-acpi.c
> +++ b/drivers/pci/pci-acpi.c
> @@ -60,8 +60,7 @@ static void pci_acpi_wake_dev(struct work_struct *work)
>  	pci_wakeup_event(pci_dev);
>  	pm_runtime_resume(&pci_dev->dev);
> 
> -	if (pci_dev->subordinate)
> -		pci_pme_wakeup_bus(pci_dev->subordinate);
> +	pci_pme_wakeup_bus(pci_dev->subordinate);
>  }
> 
>  /**
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 4170113..e93f16e 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -86,8 +86,7 @@ static void release_pcibus_dev(struct device *dev)
>  {
>  	struct pci_bus *pci_bus = to_pci_bus(dev);
> 
> -	if (pci_bus->bridge)
> -		put_device(pci_bus->bridge);
> +	put_device(pci_bus->bridge);
>  	pci_bus_remove_resources(pci_bus);
>  	pci_release_bus_of_node(pci_bus);
>  	kfree(pci_bus);
> diff --git a/drivers/pci/search.c b/drivers/pci/search.c
> index 827ad83..2d806bd 100644
> --- a/drivers/pci/search.c
> +++ b/drivers/pci/search.c
> @@ -305,8 +305,7 @@ static struct pci_dev *pci_get_dev_by_id(const struct
> pci_device_id *id,
>  			      match_pci_dev_by_id);
>  	if (dev)
>  		pdev = to_pci_dev(dev);
> -	if (from)
> -		pci_dev_put(from);
> +	pci_dev_put(from);
>  	return pdev;
>  }
> 
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index 53df39a..46664cc 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -596,8 +596,7 @@ static pci_ers_result_t pcifront_common_process(int cmd,
>  	pcidev = pci_get_bus_and_slot(bus, devfn);
>  	if (!pcidev || !pcidev->driver) {
>  		dev_err(&pdev->xdev->dev, "device or AER driver is NULL\n");
> -		if (pcidev)
> -			pci_dev_put(pcidev);
> +		pci_dev_put(pcidev);
>  		return result;
>  	}
>  	pdrv = pcidev->driver;
> -- 
> 2.1.3
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 04:07:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 04: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 1Xo2jm-00007T-N7; Tue, 11 Nov 2014 04:07:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1Xo2jk-00007O-Su
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 04:07:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E6/37-09936-C7B81645; Tue, 11 Nov 2014 04:07:24 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415678842!12842815!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9272 invoked from network); 11 Nov 2014 04:07:23 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 04:07:23 -0000
Received: by mail-ie0-f173.google.com with SMTP id tr6so10673575ieb.18
	for <xen-devel@lists.xenproject.org>;
	Mon, 10 Nov 2014 20:07:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=8+wzEfyc/r1NMzfv0uNtqJbpUGLpL7G3gCFYTG7A7t4=;
	b=dpIUOsIDbaSnL1neuiKluh3Kjo1JINxuB3bKgII4iFUiV4Q3KPSSog7eNsOGcoXR20
	yUZ6cthNVDvyUfR0DjzDrJ3EzjaFxK5DF8ixJuZFuZccaF7mt6kRFbZvLRcRFat6KJKo
	3Ictbhbl5iLalYLWvxUuy9u4os9h5N0IlbChxJPmTaN7pAyXKzbSwsuCtfed41fT3e2y
	PxFJWfqmnrruRdWit49IL3Jdn2NkP2Xa1+NolRAiF5FJKUcD4/Vna6nEy6znEtnaILwi
	6+SkYcOCAU0MBhnVrbI8gehh9qSLWWqAqYfnn2sbTF6tKuI1GbDyO0ISisfZdosNaxje
	gPnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=8+wzEfyc/r1NMzfv0uNtqJbpUGLpL7G3gCFYTG7A7t4=;
	b=Cm3PwQlpHhJUX4nIMJelmADeBv7EqdTv/HkZxJY86OL2zzdc2ObcVK4u5U2BDzhP7g
	uL5trxC1NW2mPnEfyJwLT183xVh8annuRqBDYwn1CHb56Hf6i9gbGDNDhRYsolnE10fM
	Zj+7bcApHZanYVZxAdYX+OIwFLYXFXo7i6MyswZ2YbchSoEAFpZBv9ZvNHA9jks7aI9R
	D1ZYketePiQlbpk7QF2MSkJ8Xh44DiJMgOZFAroFARCJKhkR7+2D2sSocgUy5bcY2jnp
	ZLp5SsCtRDwM/5ovAYHGgpe1a39Nh2iHyZ0pOan3uIDWBzlWZx2Oit+ztZ782IGaKdJw
	up7g==
X-Gm-Message-State: ALoCoQlvJ5Rf8fHYYLfJkMxZ3bvRVZjgq97+91z08FyLxsvHBuNFWsxGPRmS0g9RQ9lSS+lqWvdi
X-Received: by 10.107.41.199 with SMTP id p190mr39274120iop.10.1415678842145; 
	Mon, 10 Nov 2014 20:07:22 -0800 (PST)
Received: from google.com ([172.26.48.152])
	by mx.google.com with ESMTPSA id b32sm9267134ioj.26.2014.11.10.20.07.19
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Mon, 10 Nov 2014 20:07:21 -0800 (PST)
Date: Mon, 10 Nov 2014 21:07:17 -0700
From: Bjorn Helgaas <bhelgaas@google.com>
To: SF Markus Elfring <elfring@users.sourceforge.net>
Message-ID: <20141111040717.GD28161@google.com>
References: <530C5E18.1020800@users.sourceforge.net>
	<alpine.DEB.2.10.1402251014170.2080@hadrien>
	<530CD2C4.4050903@users.sourceforge.net>
	<alpine.DEB.2.10.1402251840450.7035@hadrien>
	<530CF8FF.8080600@users.sourceforge.net>
	<alpine.DEB.2.02.1402252117150.2047@localhost6.localdomain6>
	<530DD06F.4090703@users.sourceforge.net>
	<alpine.DEB.2.02.1402262129250.2221@localhost6.localdomain6>
	<5317A59D.4@users.sourceforge.net>
	<545649DE.80304@users.sourceforge.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545649DE.80304@users.sourceforge.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: kernel-janitors@vger.kernel.org, trivial@kernel.org,
	linux-pci@vger.kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Coccinelle <cocci@systeme.lip6.fr>, Len Brown <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] PCI: Deletion of unnecessary checks
 before three function calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Nov 02, 2014 at 04:12:30PM +0100, SF Markus Elfring wrote:
> The functions pci_dev_put(), pci_pme_wakeup_bus() and put_device() test
> whether their argument is NULL and then return immediately. Thus the test
> around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

Applied to pci/misc for v3.19, thanks!

> ---
>  drivers/pci/pci-acpi.c     | 3 +--
>  drivers/pci/probe.c        | 3 +--
>  drivers/pci/search.c       | 3 +--
>  drivers/pci/xen-pcifront.c | 3 +--
>  4 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> index 37263b0..a8fe5de 100644
> --- a/drivers/pci/pci-acpi.c
> +++ b/drivers/pci/pci-acpi.c
> @@ -60,8 +60,7 @@ static void pci_acpi_wake_dev(struct work_struct *work)
>  	pci_wakeup_event(pci_dev);
>  	pm_runtime_resume(&pci_dev->dev);
> 
> -	if (pci_dev->subordinate)
> -		pci_pme_wakeup_bus(pci_dev->subordinate);
> +	pci_pme_wakeup_bus(pci_dev->subordinate);
>  }
> 
>  /**
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 4170113..e93f16e 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -86,8 +86,7 @@ static void release_pcibus_dev(struct device *dev)
>  {
>  	struct pci_bus *pci_bus = to_pci_bus(dev);
> 
> -	if (pci_bus->bridge)
> -		put_device(pci_bus->bridge);
> +	put_device(pci_bus->bridge);
>  	pci_bus_remove_resources(pci_bus);
>  	pci_release_bus_of_node(pci_bus);
>  	kfree(pci_bus);
> diff --git a/drivers/pci/search.c b/drivers/pci/search.c
> index 827ad83..2d806bd 100644
> --- a/drivers/pci/search.c
> +++ b/drivers/pci/search.c
> @@ -305,8 +305,7 @@ static struct pci_dev *pci_get_dev_by_id(const struct
> pci_device_id *id,
>  			      match_pci_dev_by_id);
>  	if (dev)
>  		pdev = to_pci_dev(dev);
> -	if (from)
> -		pci_dev_put(from);
> +	pci_dev_put(from);
>  	return pdev;
>  }
> 
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index 53df39a..46664cc 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -596,8 +596,7 @@ static pci_ers_result_t pcifront_common_process(int cmd,
>  	pcidev = pci_get_bus_and_slot(bus, devfn);
>  	if (!pcidev || !pcidev->driver) {
>  		dev_err(&pdev->xdev->dev, "device or AER driver is NULL\n");
> -		if (pcidev)
> -			pci_dev_put(pcidev);
> +		pci_dev_put(pcidev);
>  		return result;
>  	}
>  	pdrv = pcidev->driver;
> -- 
> 2.1.3
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:07:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo3f1-00014B-9Z; Tue, 11 Nov 2014 05:06:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo3ez-000146-9M
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:06:33 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	39/57-25714-85991645; Tue, 11 Nov 2014 05:06:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415682391!11660117!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18454 invoked from network); 11 Nov 2014 05:06:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:06:31 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 6F8DEAAF1;
	Tue, 11 Nov 2014 05:06:29 +0000 (UTC)
Message-ID: <54619953.4000401@suse.com>
Date: Tue, 11 Nov 2014 06:06:27 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Chun Yan Liu <cyliu@suse.com>, olaf@aepfle.de
References: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
	<5460E9D80200006600078038@soto.provo.novell.com>
	<20141110150100.GK3783@laptop.dumpdata.com>
In-Reply-To: <20141110150100.GK3783@laptop.dumpdata.com>
Content-Length: 3648
Cc: Lars Kurth <lars.kurth@citrix.com>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>, Bo Cao <caobosimon@gmail.com>
Subject: Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 04:01 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 10, 2014 at 01:37:44AM -0700, Chun Yan Liu wrote:
>> Is there any progress on this work? I didn't see new version after this.
>> Anyone knows the status?
>
> I believe Olaf and Juergen were looking at this for Xen 4.6?

I'm working on the kernel pvusb drivers.

Juergen

>
> CC-ing them.
>>
>> Thanks,
>> Chunyan
>>
>>>>> On 8/11/2014 at 04:23 AM, in message
>> <1407702234-22309-1-git-send-email-caobosimon@gmail.com>, Bo Cao
>> <caobosimon@gmail.com> wrote:
>>> Finally I have a workable version xl/libxl support for PVUSB. Most of
>>> its commands work property now, but there are still some probelm to be
>>> solved.
>>> Please take a loot and give me some advices.
>>>
>>> =3D=3D What have been implemented ? =3D=3D
>>> I have implemented libxl functions for PVUSB in libxl_usb.c. It mainly
>>> consists of two part:
>>> usbctrl_add/remove/list and usb_add/remove/list in which usbctrl denote=
 usb
>>> controller in which
>>> usd device can be plugged in. I don't use "ao_dev" in
>>> libxl_deivce_usbctrl_add since we don't need to
>>> execute hotplug script for usbctrl and without "ao_dev", adding default
>>> usbctrl for usb device
>>> would be easier.
>>>
>>> For the cammands to manipulate usb device such as "xl usb-attach" and "=
xl
>>> usb-detach", this patch now only
>>> support to specify usb devices by their interface in sysfs. Using this
>>> interface, we can read usb device
>>> information through sysfs and bind/unbind usb device. (The support for
>>> mapping the "lsusb" bus:addr to the
>>> sysfs usb interface will come later).
>>>
>>> =3D=3D What needs to do next ? =3D=3D
>>> There are two main problems to be solved.
>>>
>>> 1.  PVUSB Options in VM Guest's Configuration File
>>>      The interface in VM Guest's configuration file to add usb device i=
s:
>>> "usb=3D[interface=3D"1-1"]".
>>> But the problem is now is that after the default usbctrl is added, the =
state
>>> of usbctrl is "2", e,g, "XenbusStateInitWait",
>>> waiting for xen-usbfront to connect. The xen-usbfront in VM Guest isn't
>>> loaded. Therefore, "sysfs_intf_write"
>>> will report error. Does anyone have any clue how to solve this?
>>>
>>> 2. sysfs_intf_write
>>>      In the process of "xl usb-attach domid intf=3D1-1", after writing =
"1-1" to
>>> Xenstore entry, we need to
>>> bind the controller of this usb device to usbback driver so that it can=
 be
>>> used by VM Guest. For exampele,
>>> for usb device "1-1", it's controller interface maybe "1-1:1.0", and we
>>> write this value to "/sys/bus/usb/driver/usbback/bind".
>>> But for some devices, they have two controllers, for example "1-1:1.0" =
and
>>> "1-1:1.1". I think this means it has two functions,
>>> such as usbhid and usb-storage. So in this case, we bind the two contro=
ller
>>> to usbback?
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D
>>> There maybe some errors or bugs in the codes. Feel free to tell me.
>>>
>>> Cheers,
>>>
>>> - Simon
>>>
>>> ---
>>> CC: George Dunlap <george.dunlap@eu.citrix.com>
>>> CC: Ian Jackson <ian.jackson@citrix.com>
>>> CC: Ian Campbell <ian.campbell@citrix.com>
>>> CC: Pasi K=E4rkk=E4inen <pasik@iki.fi>
>>> CC: Lars Kurth <lars.kurth@citrix.com>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:07:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo3f1-00014B-9Z; Tue, 11 Nov 2014 05:06:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo3ez-000146-9M
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:06:33 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	39/57-25714-85991645; Tue, 11 Nov 2014 05:06:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415682391!11660117!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18454 invoked from network); 11 Nov 2014 05:06:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:06:31 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 6F8DEAAF1;
	Tue, 11 Nov 2014 05:06:29 +0000 (UTC)
Message-ID: <54619953.4000401@suse.com>
Date: Tue, 11 Nov 2014 06:06:27 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Chun Yan Liu <cyliu@suse.com>, olaf@aepfle.de
References: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
	<5460E9D80200006600078038@soto.provo.novell.com>
	<20141110150100.GK3783@laptop.dumpdata.com>
In-Reply-To: <20141110150100.GK3783@laptop.dumpdata.com>
Content-Length: 3648
Cc: Lars Kurth <lars.kurth@citrix.com>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>, Bo Cao <caobosimon@gmail.com>
Subject: Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/10/2014 04:01 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 10, 2014 at 01:37:44AM -0700, Chun Yan Liu wrote:
>> Is there any progress on this work? I didn't see new version after this.
>> Anyone knows the status?
>
> I believe Olaf and Juergen were looking at this for Xen 4.6?

I'm working on the kernel pvusb drivers.

Juergen

>
> CC-ing them.
>>
>> Thanks,
>> Chunyan
>>
>>>>> On 8/11/2014 at 04:23 AM, in message
>> <1407702234-22309-1-git-send-email-caobosimon@gmail.com>, Bo Cao
>> <caobosimon@gmail.com> wrote:
>>> Finally I have a workable version xl/libxl support for PVUSB. Most of
>>> its commands work property now, but there are still some probelm to be
>>> solved.
>>> Please take a loot and give me some advices.
>>>
>>> =3D=3D What have been implemented ? =3D=3D
>>> I have implemented libxl functions for PVUSB in libxl_usb.c. It mainly
>>> consists of two part:
>>> usbctrl_add/remove/list and usb_add/remove/list in which usbctrl denote=
 usb
>>> controller in which
>>> usd device can be plugged in. I don't use "ao_dev" in
>>> libxl_deivce_usbctrl_add since we don't need to
>>> execute hotplug script for usbctrl and without "ao_dev", adding default
>>> usbctrl for usb device
>>> would be easier.
>>>
>>> For the cammands to manipulate usb device such as "xl usb-attach" and "=
xl
>>> usb-detach", this patch now only
>>> support to specify usb devices by their interface in sysfs. Using this
>>> interface, we can read usb device
>>> information through sysfs and bind/unbind usb device. (The support for
>>> mapping the "lsusb" bus:addr to the
>>> sysfs usb interface will come later).
>>>
>>> =3D=3D What needs to do next ? =3D=3D
>>> There are two main problems to be solved.
>>>
>>> 1.  PVUSB Options in VM Guest's Configuration File
>>>      The interface in VM Guest's configuration file to add usb device i=
s:
>>> "usb=3D[interface=3D"1-1"]".
>>> But the problem is now is that after the default usbctrl is added, the =
state
>>> of usbctrl is "2", e,g, "XenbusStateInitWait",
>>> waiting for xen-usbfront to connect. The xen-usbfront in VM Guest isn't
>>> loaded. Therefore, "sysfs_intf_write"
>>> will report error. Does anyone have any clue how to solve this?
>>>
>>> 2. sysfs_intf_write
>>>      In the process of "xl usb-attach domid intf=3D1-1", after writing =
"1-1" to
>>> Xenstore entry, we need to
>>> bind the controller of this usb device to usbback driver so that it can=
 be
>>> used by VM Guest. For exampele,
>>> for usb device "1-1", it's controller interface maybe "1-1:1.0", and we
>>> write this value to "/sys/bus/usb/driver/usbback/bind".
>>> But for some devices, they have two controllers, for example "1-1:1.0" =
and
>>> "1-1:1.1". I think this means it has two functions,
>>> such as usbhid and usb-storage. So in this case, we bind the two contro=
ller
>>> to usbback?
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D
>>> There maybe some errors or bugs in the codes. Feel free to tell me.
>>>
>>> Cheers,
>>>
>>> - Simon
>>>
>>> ---
>>> CC: George Dunlap <george.dunlap@eu.citrix.com>
>>> CC: Ian Jackson <ian.jackson@citrix.com>
>>> CC: Ian Campbell <ian.campbell@citrix.com>
>>> CC: Pasi K=E4rkk=E4inen <pasik@iki.fi>
>>> CC: Lars Kurth <lars.kurth@citrix.com>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FL-0001dN-IT; Tue, 11 Nov 2014 05:44:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FH-0001as-LL
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	08/AE-09842-222A1645; Tue, 11 Nov 2014 05:44:02 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415684640!12892037!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13876 invoked from network); 11 Nov 2014 05:44:00 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:44:00 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id EF5CCACF1;
	Tue, 11 Nov 2014 05:43:59 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:46 +0100
Message-Id: <1415684626-18590-9-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 8/8] xen: Speed up set_phys_to_machine() by
	using read-only mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of checking at each call of set_phys_to_machine() whether a
new p2m page has to be allocated due to writing an entry in a large
invalid or identity area, just map those areas read only and react
to a page fault on write by allocating the new page.

This change will make the common path with no allocation much
faster as it only requires a single write of the new mfn instead
of walking the address translation tables and checking for the
special cases.

Suggested-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/p2m.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 7df446d..58cf04c 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -70,6 +70,7 @@
 
 #include <asm/cache.h>
 #include <asm/setup.h>
+#include <asm/uaccess.h>
 
 #include <asm/xen/page.h>
 #include <asm/xen/hypercall.h>
@@ -313,9 +314,9 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
 	for (i = 0; i < PTRS_PER_PTE; i++) {
 		set_pte(p2m_missing_pte + i,
-			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
+			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL_RO));
 		set_pte(p2m_identity_pte + i,
-			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
+			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL_RO));
 	}
 
 	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
@@ -362,7 +363,7 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 				p2m_missing : p2m_identity;
 			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
 			set_pte(ptep,
-				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL_RO));
 			continue;
 		}
 
@@ -621,6 +622,9 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
+	if (likely(!__put_user(mfn, xen_p2m_addr + pfn)))
+		return true;
+
 	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
 	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
@@ -630,9 +634,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
 		return mfn == IDENTITY_FRAME(pfn);
 
-	xen_p2m_addr[pfn] = mfn;
-
-	return true;
+	return false;
 }
 
 bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FI-0001bL-Gf; Tue, 11 Nov 2014 05:44:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FF-0001aX-Lt
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	26/47-24532-022A1645; Tue, 11 Nov 2014 05:44:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415684639!12876546!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30037 invoked from network); 11 Nov 2014 05:43:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:59 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 5A011ACDE;
	Tue, 11 Nov 2014 05:43:59 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:44 +0100
Message-Id: <1415684626-18590-7-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 6/8] xen: Hide get_phys_to_machine() to be
	able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 get_phys_to_machine() is always called when the mfn for a pfn
is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
to be able to avoid calling get_phys_to_machine() when possible as
soon as the switch to a linear mapped p2m list has been done.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h | 27 +++++++++++++++++++++------
 arch/x86/xen/mmu.c              |  2 +-
 arch/x86/xen/p2m.c              |  6 +++---
 3 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 28fa795..07d8a7b 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -59,6 +59,22 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct page **pages, unsigned int count);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
+/*
+ * When to use pfn_to_mfn(), __pfn_to_mfn() or get_phys_to_machine():
+ * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. In case of an
+ *   identity entry the identity indicator will be cleared.
+ * - __pfn_to_mfn() returns the found entry of the p2m table. A possibly set
+ *   identity indicator will be still set. __pfn_to_mfn() is encapsulating
+ *   get_phys_to_machine() and might skip that function if possible to speed
+ *   up the common path.
+ * - get_phys_to_machine() is basically the same as __pfn_to_mfn(), but
+ *   without any short cuts for the common fast path.
+ */
+static inline unsigned long __pfn_to_mfn(unsigned long pfn)
+{
+	return get_phys_to_machine(pfn);
+}
+
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
 {
 	unsigned long mfn;
@@ -66,7 +82,7 @@ static inline unsigned long pfn_to_mfn(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return pfn;
 
-	mfn = get_phys_to_machine(pfn);
+	mfn = __pfn_to_mfn(pfn);
 
 	if (mfn != INVALID_P2M_ENTRY)
 		mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
@@ -79,7 +95,7 @@ static inline int phys_to_machine_mapping_valid(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return 1;
 
-	return get_phys_to_machine(pfn) != INVALID_P2M_ENTRY;
+	return __pfn_to_mfn(pfn) != INVALID_P2M_ENTRY;
 }
 
 static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
@@ -113,7 +129,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) != mfn) {
+	if (__pfn_to_mfn(pfn) != mfn) {
 		/*
 		 * If this appears to be a foreign mfn (because the pfn
 		 * doesn't map back to the mfn), then check the local override
@@ -129,8 +145,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 	 * entry doesn't map back to the mfn and m2p_override doesn't have a
 	 * valid entry for it.
 	 */
-	if (pfn == ~0 &&
-			get_phys_to_machine(mfn) == IDENTITY_FRAME(mfn))
+	if (pfn == ~0 && __pfn_to_mfn(mfn) == IDENTITY_FRAME(mfn))
 		pfn = mfn;
 
 	return pfn;
@@ -176,7 +191,7 @@ static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn(mfn);
-	if (get_phys_to_machine(pfn) != mfn)
+	if (__pfn_to_mfn(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
 }
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d3e492b..31ca515 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -387,7 +387,7 @@ static pteval_t pte_pfn_to_mfn(pteval_t val)
 		unsigned long mfn;
 
 		if (!xen_feature(XENFEAT_auto_translated_physmap))
-			mfn = get_phys_to_machine(pfn);
+			mfn = __pfn_to_mfn(pfn);
 		else
 			mfn = pfn;
 		/*
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 6a9dfa6..328875a 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -785,7 +785,7 @@ static int m2p_add_override(unsigned long mfn, struct page *page,
 	 * because mfn_to_pfn (that ends up being called by GUPF) will
 	 * return the backend pfn rather than the frontend pfn. */
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == mfn)
+	if (__pfn_to_mfn(pfn) == mfn)
 		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
 
 	return 0;
@@ -965,7 +965,7 @@ static int m2p_remove_override(struct page *page,
 	 * pfn again. */
 	mfn &= ~FOREIGN_FRAME_BIT;
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
+	if (__pfn_to_mfn(pfn) == FOREIGN_FRAME(mfn) &&
 			m2p_find_override(mfn) == NULL)
 		set_phys_to_machine(pfn, mfn);
 
@@ -990,7 +990,7 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 	}
 
 	for (i = 0; i < count; i++) {
-		unsigned long mfn = get_phys_to_machine(page_to_pfn(pages[i]));
+		unsigned long mfn = __pfn_to_mfn(page_to_pfn(pages[i]));
 		unsigned long pfn = page_to_pfn(pages[i]);
 
 		if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FH-0001aw-Ep; Tue, 11 Nov 2014 05:44:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FE-0001aF-1F
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6B/F0-09936-F12A1645; Tue, 11 Nov 2014 05:43:59 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415684638!12892046!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32677 invoked from network); 11 Nov 2014 05:43:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:58 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 54845AC95;
	Tue, 11 Nov 2014 05:43:58 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:41 +0100
Message-Id: <1415684626-18590-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 3/8] xen: Delay m2p_override initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 m2p overrides are used to be able to find the local pfn for a
foreign mfn mapped into the domain. They are used by driver backends
having to access frontend data.

As this functionality isn't used in early boot it makes no sense to
initialize the m2p override functions very early. It can be done
later without doing any harm, removing the need for allocating memory
via extend_brk().

While at it make some m2p override functions static as they are only
used internally.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/p2m.c | 33 +++++++++++++++++++--------------
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index f67f8cf..97252e3 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -426,8 +426,6 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		}
 		p2m_top[topidx][mididx] = &mfn_list[pfn];
 	}
-
-	m2p_override_init();
 }
 #ifdef CONFIG_X86_64
 unsigned long __init xen_revector_p2m_tree(void)
@@ -498,13 +496,15 @@ unsigned long __init xen_revector_p2m_tree(void)
 		}
 		/* This should be the leafs allocated for identity from _brk. */
 	}
-	return (unsigned long)mfn_list;
 
+	m2p_override_init();
+	return (unsigned long)mfn_list;
 }
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	m2p_override_init();
 	return 0;
 }
 #endif
@@ -794,15 +794,16 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 #define M2P_OVERRIDE_HASH_SHIFT	10
 #define M2P_OVERRIDE_HASH	(1 << M2P_OVERRIDE_HASH_SHIFT)
 
-static RESERVE_BRK_ARRAY(struct list_head, m2p_overrides, M2P_OVERRIDE_HASH);
+static struct list_head *m2p_overrides;
 static DEFINE_SPINLOCK(m2p_override_lock);
 
 static void __init m2p_override_init(void)
 {
 	unsigned i;
 
-	m2p_overrides = extend_brk(sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
-				   sizeof(unsigned long));
+	m2p_overrides = alloc_bootmem_align(
+				sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
+				sizeof(unsigned long));
 
 	for (i = 0; i < M2P_OVERRIDE_HASH; i++)
 		INIT_LIST_HEAD(&m2p_overrides[i]);
@@ -930,21 +931,25 @@ EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
 static struct page *m2p_find_override(unsigned long mfn)
 {
 	unsigned long flags;
-	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
+	struct list_head *bucket;
 	struct page *p, *ret;
 
 	ret = NULL;
 
-	spin_lock_irqsave(&m2p_override_lock, flags);
+	if (m2p_overrides) {
+		bucket = &m2p_overrides[mfn_hash(mfn)];
 
-	list_for_each_entry(p, bucket, lru) {
-		if (page_private(p) == mfn) {
-			ret = p;
-			break;
+		spin_lock_irqsave(&m2p_override_lock, flags);
+
+		list_for_each_entry(p, bucket, lru) {
+			if (page_private(p) == mfn) {
+				ret = p;
+				break;
+			}
 		}
-	}
 
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
+		spin_unlock_irqrestore(&m2p_override_lock, flags);
+	}
 
 	return ret;
 }
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FJ-0001bZ-8S; Tue, 11 Nov 2014 05:44:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FG-0001aZ-Om
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:02 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	62/E2-28296-222A1645; Tue, 11 Nov 2014 05:44:02 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415684639!9263860!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20673 invoked from network); 11 Nov 2014 05:43:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:59 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0D3A8ACAA;
	Tue, 11 Nov 2014 05:43:59 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:43 +0100
Message-Id: <1415684626-18590-6-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 5/8] x86: Introduce function to get pmd entry
	pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduces lookup_pmd_address() to get the address of the pmd entry
related to a virtual address in the current address space. This
function is needed for support of a virtual mapped sparse p2m list
in xen pv domains.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/pgtable_types.h |  1 +
 arch/x86/mm/pageattr.c               | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0778964..d83f5e7 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -396,6 +396,7 @@ static inline void update_page_count(int level, unsigned long pages) { }
 extern pte_t *lookup_address(unsigned long address, unsigned int *level);
 extern pte_t *lookup_address_in_pgd(pgd_t *pgd, unsigned long address,
 				    unsigned int *level);
+extern pmd_t *lookup_pmd_address(unsigned long address);
 extern phys_addr_t slow_virt_to_phys(void *__address);
 extern int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
 				   unsigned numpages, unsigned long page_flags);
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 36de293..1298108 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -384,6 +384,26 @@ static pte_t *_lookup_address_cpa(struct cpa_data *cpa, unsigned long address,
 }
 
 /*
+ * Lookup the PMD entry for a virtual address. Return a pointer to the entry
+ * or NULL if not present.
+ */
+pmd_t *lookup_pmd_address(unsigned long address)
+{
+	pgd_t *pgd;
+	pud_t *pud;
+
+	pgd = pgd_offset_k(address);
+	if (pgd_none(*pgd))
+		return NULL;
+
+	pud = pud_offset(pgd, address);
+	if (pud_none(*pud) || pud_large(*pud) || !pud_present(*pud))
+		return NULL;
+
+	return pmd_offset(pud, address);
+}
+
+/*
  * This is necessary because __pa() does not work on some
  * kinds of memory, like vmalloc() or the alloc_remap()
  * areas on 32-bit NUMA systems.  The percpu areas can
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FF-0001aV-4D; Tue, 11 Nov 2014 05:44:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FD-0001aA-3V
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:43:59 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	E6/A0-29352-E12A1645; Tue, 11 Nov 2014 05:43:58 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415684637!6373500!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22538 invoked from network); 11 Nov 2014 05:43:57 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 05:43:57 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 57668AAF1;
	Tue, 11 Nov 2014 05:43:57 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:38 +0100
Message-Id: <1415684626-18590-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 0/8] xen: Switch to virtual mapped linear p2m
	list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paravirtualized kernels running on Xen use a three level tree for
translation of guest specific physical addresses to machine global
addresses. This p2m tree is used for construction of page table
entries, so the p2m tree walk is performance critical.

By using a linear virtual mapped p2m list accesses to p2m elements
can be sped up while even simplifying code. To achieve this goal
some p2m related initializations have to be performed later in the
boot process, as the final p2m list can be set up only after basic
memory management functions are available.

Changes in V3:
- Carved out (new) patch 1 to make pure code movement more obvious
  as requested by David Vrabel
- New patch 6 introducing __pfn_to_mfn() (taken from patch 7) as
  requested by David Vrabel
- New patch 8 to speed up set_phys_to_machine() as suggested by
  David Vrabel

Changes in V2:
- splitted patch 2 in 4 smaller ones as requested by David Vrabel
- added highmem check when remapping kernel memory as requested by
  David Vrabel

Juergen Gross (8):
  xen: Make functions static
  xen: Delay remapping memory of pv-domain
  xen: Delay m2p_override initialization
  xen: Delay invalidating extra memory
  x86: Introduce function to get pmd entry pointer
  xen: Hide get_phys_to_machine() to be able to tune common path
  xen: switch to linear virtual mapped sparse p2m list
  xen: Speed up set_phys_to_machine() by using read-only mappings

 arch/x86/include/asm/pgtable_types.h |    1 +
 arch/x86/include/asm/xen/page.h      |   49 +-
 arch/x86/mm/pageattr.c               |   20 +
 arch/x86/xen/mmu.c                   |   38 +-
 arch/x86/xen/p2m.c                   | 1315 ++++++++++++++--------------------
 arch/x86/xen/setup.c                 |  460 ++++++------
 arch/x86/xen/xen-ops.h               |    6 +-
 7 files changed, 854 insertions(+), 1035 deletions(-)

-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FL-0001dN-IT; Tue, 11 Nov 2014 05:44:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FH-0001as-LL
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	08/AE-09842-222A1645; Tue, 11 Nov 2014 05:44:02 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415684640!12892037!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13876 invoked from network); 11 Nov 2014 05:44:00 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:44:00 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id EF5CCACF1;
	Tue, 11 Nov 2014 05:43:59 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:46 +0100
Message-Id: <1415684626-18590-9-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 8/8] xen: Speed up set_phys_to_machine() by
	using read-only mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of checking at each call of set_phys_to_machine() whether a
new p2m page has to be allocated due to writing an entry in a large
invalid or identity area, just map those areas read only and react
to a page fault on write by allocating the new page.

This change will make the common path with no allocation much
faster as it only requires a single write of the new mfn instead
of walking the address translation tables and checking for the
special cases.

Suggested-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/p2m.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 7df446d..58cf04c 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -70,6 +70,7 @@
 
 #include <asm/cache.h>
 #include <asm/setup.h>
+#include <asm/uaccess.h>
 
 #include <asm/xen/page.h>
 #include <asm/xen/hypercall.h>
@@ -313,9 +314,9 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
 	for (i = 0; i < PTRS_PER_PTE; i++) {
 		set_pte(p2m_missing_pte + i,
-			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
+			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL_RO));
 		set_pte(p2m_identity_pte + i,
-			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
+			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL_RO));
 	}
 
 	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
@@ -362,7 +363,7 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 				p2m_missing : p2m_identity;
 			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
 			set_pte(ptep,
-				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL_RO));
 			continue;
 		}
 
@@ -621,6 +622,9 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
+	if (likely(!__put_user(mfn, xen_p2m_addr + pfn)))
+		return true;
+
 	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
 	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
@@ -630,9 +634,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
 		return mfn == IDENTITY_FRAME(pfn);
 
-	xen_p2m_addr[pfn] = mfn;
-
-	return true;
+	return false;
 }
 
 bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FI-0001bS-TE; Tue, 11 Nov 2014 05:44:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FG-0001aY-EI
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	40/01-09936-122A1645; Tue, 11 Nov 2014 05:44:01 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415684639!12817146!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14163 invoked from network); 11 Nov 2014 05:43:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:59 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id AE546ACEE;
	Tue, 11 Nov 2014 05:43:59 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:45 +0100
Message-Id: <1415684626-18590-8-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
	sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At start of the day the Xen hypervisor presents a contiguous mfn list
to a pv-domain. In order to support sparse memory this mfn list is
accessed via a three level p2m tree built early in the boot process.
Whenever the system needs the mfn associated with a pfn this tree is
used to find the mfn.

Instead of using a software walked tree for accessing a specific mfn
list entry this patch is creating a virtual address area for the
entire possible mfn list including memory holes. The holes are
covered by mapping a pre-defined  page consisting only of "invalid
mfn" entries. Access to a mfn entry is possible by just using the
virtual base address of the mfn list and the pfn as index into that
list. This speeds up the (hot) path of determining the mfn of a
pfn.

Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
showed following improvements:

Elapsed time: 32:50 ->  32:35
System:       18:07 ->  17:47
User:        104:00 -> 103:30

Tested on 64 bit dom0 and 32 bit domU.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |  14 +-
 arch/x86/xen/mmu.c              |  32 +-
 arch/x86/xen/p2m.c              | 732 +++++++++++++++++-----------------------
 arch/x86/xen/xen-ops.h          |   2 +-
 4 files changed, 342 insertions(+), 438 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 07d8a7b..4a227ec 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -72,7 +72,19 @@ extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
  */
 static inline unsigned long __pfn_to_mfn(unsigned long pfn)
 {
-	return get_phys_to_machine(pfn);
+	unsigned long mfn;
+
+	if (pfn < xen_p2m_size)
+		mfn = xen_p2m_addr[pfn];
+	else if (unlikely(pfn < xen_max_p2m_pfn))
+		return get_phys_to_machine(pfn);
+	else
+		return IDENTITY_FRAME(pfn);
+
+	if (unlikely(mfn == INVALID_P2M_ENTRY))
+		return get_phys_to_machine(pfn);
+
+	return mfn;
 }
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 31ca515..0b43c45 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1158,20 +1158,16 @@ static void __init xen_cleanhighmap(unsigned long vaddr,
 	 * instead of somewhere later and be confusing. */
 	xen_mc_flush();
 }
-static void __init xen_pagetable_p2m_copy(void)
+
+static void __init xen_pagetable_p2m_free(void)
 {
 	unsigned long size;
 	unsigned long addr;
-	unsigned long new_mfn_list;
-
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return;
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 
-	new_mfn_list = xen_revector_p2m_tree();
 	/* No memory or already called. */
-	if (!new_mfn_list || new_mfn_list == xen_start_info->mfn_list)
+	if ((unsigned long)xen_p2m_addr == xen_start_info->mfn_list)
 		return;
 
 	/* using __ka address and sticking INVALID_P2M_ENTRY! */
@@ -1189,8 +1185,6 @@ static void __init xen_pagetable_p2m_copy(void)
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 	memblock_free(__pa(xen_start_info->mfn_list), size);
-	/* And revector! Bye bye old array */
-	xen_start_info->mfn_list = new_mfn_list;
 
 	/* At this stage, cleanup_highmap has already cleaned __ka space
 	 * from _brk_limit way up to the max_pfn_mapped (which is the end of
@@ -1214,12 +1208,26 @@ static void __init xen_pagetable_p2m_copy(void)
 }
 #endif
 
-static void __init xen_pagetable_init(void)
+static void __init xen_pagetable_p2m_setup(void)
 {
-	paging_init();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	xen_vmalloc_p2m_tree();
+
 #ifdef CONFIG_X86_64
-	xen_pagetable_p2m_copy();
+	xen_pagetable_p2m_free();
 #endif
+	/* And revector! Bye bye old array */
+	xen_start_info->mfn_list = (unsigned long)xen_p2m_addr;
+}
+
+static void __init xen_pagetable_init(void)
+{
+	paging_init();
+
+	xen_pagetable_p2m_setup();
+
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 328875a..7df446d 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -3,21 +3,22 @@
  * guests themselves, but it must also access and update the p2m array
  * during suspend/resume when all the pages are reallocated.
  *
- * The p2m table is logically a flat array, but we implement it as a
- * three-level tree to allow the address space to be sparse.
+ * The logical flat p2m table is mapped to a linear kernel memory area.
+ * For accesses by Xen a three-level tree linked via mfns only is set up to
+ * allow the address space to be sparse.
  *
- *                               Xen
- *                                |
- *     p2m_top              p2m_top_mfn
- *       /  \                   /   \
- * p2m_mid p2m_mid	p2m_mid_mfn p2m_mid_mfn
- *    / \      / \         /           /
- *  p2m p2m p2m p2m p2m p2m p2m ...
+ *               Xen
+ *                |
+ *          p2m_top_mfn
+ *              /   \
+ * p2m_mid_mfn p2m_mid_mfn
+ *         /           /
+ *  p2m p2m p2m ...
  *
  * The p2m_mid_mfn pages are mapped by p2m_top_mfn_p.
  *
- * The p2m_top and p2m_top_mfn levels are limited to 1 page, so the
- * maximum representable pseudo-physical address space is:
+ * The p2m_top_mfn level is limited to 1 page, so the maximum representable
+ * pseudo-physical address space is:
  *  P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * P2M_PER_PAGE pages
  *
  * P2M_PER_PAGE depends on the architecture, as a mfn is always
@@ -30,6 +31,9 @@
  * leaf entries, or for the top  root, or middle one, for which there is a void
  * entry, we assume it is  "missing". So (for example)
  *  pfn_to_mfn(0x90909090)=INVALID_P2M_ENTRY.
+ * We have a dedicated page p2m_missing with all entries being
+ * INVALID_P2M_ENTRY. This page may be referenced multiple times in the p2m
+ * list/tree in case there are multiple areas with P2M_PER_PAGE invalid pfns.
  *
  * We also have the possibility of setting 1-1 mappings on certain regions, so
  * that:
@@ -39,122 +43,20 @@
  * PCI BARs, or ACPI spaces), we can create mappings easily because we
  * get the PFN value to match the MFN.
  *
- * For this to work efficiently we have one new page p2m_identity and
- * allocate (via reserved_brk) any other pages we need to cover the sides
- * (1GB or 4MB boundary violations). All entries in p2m_identity are set to
- * INVALID_P2M_ENTRY type (Xen toolstack only recognizes that and MFNs,
- * no other fancy value).
+ * For this to work efficiently we have one new page p2m_identity. All entries
+ * in p2m_identity are set to INVALID_P2M_ENTRY type (Xen toolstack only
+ * recognizes that and MFNs, no other fancy value).
  *
  * On lookup we spot that the entry points to p2m_identity and return the
  * identity value instead of dereferencing and returning INVALID_P2M_ENTRY.
  * If the entry points to an allocated page, we just proceed as before and
- * return the PFN.  If the PFN has IDENTITY_FRAME_BIT set we unmask that in
+ * return the PFN. If the PFN has IDENTITY_FRAME_BIT set we unmask that in
  * appropriate functions (pfn_to_mfn).
  *
  * The reason for having the IDENTITY_FRAME_BIT instead of just returning the
  * PFN is that we could find ourselves where pfn_to_mfn(pfn)==pfn for a
  * non-identity pfn. To protect ourselves against we elect to set (and get) the
  * IDENTITY_FRAME_BIT on all identity mapped PFNs.
- *
- * This simplistic diagram is used to explain the more subtle piece of code.
- * There is also a digram of the P2M at the end that can help.
- * Imagine your E820 looking as so:
- *
- *                    1GB                                           2GB    4GB
- * /-------------------+---------\/----\         /----------\    /---+-----\
- * | System RAM        | Sys RAM ||ACPI|         | reserved |    | Sys RAM |
- * \-------------------+---------/\----/         \----------/    \---+-----/
- *                               ^- 1029MB                       ^- 2001MB
- *
- * [1029MB = 263424 (0x40500), 2001MB = 512256 (0x7D100),
- *  2048MB = 524288 (0x80000)]
- *
- * And dom0_mem=max:3GB,1GB is passed in to the guest, meaning memory past 1GB
- * is actually not present (would have to kick the balloon driver to put it in).
- *
- * When we are told to set the PFNs for identity mapping (see patch: "xen/setup:
- * Set identity mapping for non-RAM E820 and E820 gaps.") we pass in the start
- * of the PFN and the end PFN (263424 and 512256 respectively). The first step
- * is to reserve_brk a top leaf page if the p2m[1] is missing. The top leaf page
- * covers 512^2 of page estate (1GB) and in case the start or end PFN is not
- * aligned on 512^2*PAGE_SIZE (1GB) we reserve_brk new middle and leaf pages as
- * required to split any existing p2m_mid_missing middle pages.
- *
- * With the E820 example above, 263424 is not 1GB aligned so we allocate a
- * reserve_brk page which will cover the PFNs estate from 0x40000 to 0x80000.
- * Each entry in the allocate page is "missing" (points to p2m_missing).
- *
- * Next stage is to determine if we need to do a more granular boundary check
- * on the 4MB (or 2MB depending on architecture) off the start and end pfn's.
- * We check if the start pfn and end pfn violate that boundary check, and if
- * so reserve_brk a (p2m[x][y]) leaf page. This way we have a much finer
- * granularity of setting which PFNs are missing and which ones are identity.
- * In our example 263424 and 512256 both fail the check so we reserve_brk two
- * pages. Populate them with INVALID_P2M_ENTRY (so they both have "missing"
- * values) and assign them to p2m[1][2] and p2m[1][488] respectively.
- *
- * At this point we would at minimum reserve_brk one page, but could be up to
- * three. Each call to set_phys_range_identity has at maximum a three page
- * cost. If we were to query the P2M at this stage, all those entries from
- * start PFN through end PFN (so 1029MB -> 2001MB) would return
- * INVALID_P2M_ENTRY ("missing").
- *
- * The next step is to walk from the start pfn to the end pfn setting
- * the IDENTITY_FRAME_BIT on each PFN. This is done in set_phys_range_identity.
- * If we find that the middle entry is pointing to p2m_missing we can swap it
- * over to p2m_identity - this way covering 4MB (or 2MB) PFN space (and
- * similarly swapping p2m_mid_missing for p2m_mid_identity for larger regions).
- * At this point we do not need to worry about boundary aligment (so no need to
- * reserve_brk a middle page, figure out which PFNs are "missing" and which
- * ones are identity), as that has been done earlier.  If we find that the
- * middle leaf is not occupied by p2m_identity or p2m_missing, we dereference
- * that page (which covers 512 PFNs) and set the appropriate PFN with
- * IDENTITY_FRAME_BIT. In our example 263424 and 512256 end up there, and we
- * set from p2m[1][2][256->511] and p2m[1][488][0->256] with
- * IDENTITY_FRAME_BIT set.
- *
- * All other regions that are void (or not filled) either point to p2m_missing
- * (considered missing) or have the default value of INVALID_P2M_ENTRY (also
- * considered missing). In our case, p2m[1][2][0->255] and p2m[1][488][257->511]
- * contain the INVALID_P2M_ENTRY value and are considered "missing."
- *
- * Finally, the region beyond the end of of the E820 (4 GB in this example)
- * is set to be identity (in case there are MMIO regions placed here).
- *
- * This is what the p2m ends up looking (for the E820 above) with this
- * fabulous drawing:
- *
- *    p2m         /--------------\
- *  /-----\       | &mfn_list[0],|                           /-----------------\
- *  |  0  |------>| &mfn_list[1],|    /---------------\      | ~0, ~0, ..      |
- *  |-----|       |  ..., ~0, ~0 |    | ~0, ~0, [x]---+----->| IDENTITY [@256] |
- *  |  1  |---\   \--------------/    | [p2m_identity]+\     | IDENTITY [@257] |
- *  |-----|    \                      | [p2m_identity]+\\    | ....            |
- *  |  2  |--\  \-------------------->|  ...          | \\   \----------------/
- *  |-----|   \                       \---------------/  \\
- *  |  3  |-\  \                                          \\  p2m_identity [1]
- *  |-----|  \  \-------------------->/---------------\   /-----------------\
- *  | ..  |\  |                       | [p2m_identity]+-->| ~0, ~0, ~0, ... |
- *  \-----/ | |                       | [p2m_identity]+-->| ..., ~0         |
- *          | |                       | ....          |   \-----------------/
- *          | |                       +-[x], ~0, ~0.. +\
- *          | |                       \---------------/ \
- *          | |                                          \-> /---------------\
- *          | V  p2m_mid_missing       p2m_missing           | IDENTITY[@0]  |
- *          | /-----------------\     /------------\         | IDENTITY[@256]|
- *          | | [p2m_missing]   +---->| ~0, ~0, ...|         | ~0, ~0, ....  |
- *          | | [p2m_missing]   +---->| ..., ~0    |         \---------------/
- *          | | ...             |     \------------/
- *          | \-----------------/
- *          |
- *          |     p2m_mid_identity
- *          |   /-----------------\
- *          \-->| [p2m_identity]  +---->[1]
- *              | [p2m_identity]  +---->[1]
- *              | ...             |
- *              \-----------------/
- *
- * where ~0 is INVALID_P2M_ENTRY. IDENTITY is (PFN | IDENTITY_BIT)
  */
 
 #include <linux/init.h>
@@ -179,6 +81,8 @@
 #include "multicalls.h"
 #include "xen-ops.h"
 
+#define PMDS_PER_MID_PAGE	(P2M_MID_PER_PAGE / PTRS_PER_PTE)
+
 static void __init m2p_override_init(void);
 
 unsigned long *xen_p2m_addr __read_mostly;
@@ -188,22 +92,15 @@ EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
 EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
+static DEFINE_SPINLOCK(p2m_update_lock);
+
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
 static unsigned long **p2m_top_mfn_p;
-
-/* Placeholders for holes in the address space */
-static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long **, p2m_top, P2M_TOP_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long, p2m_identity, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
-
-RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
-
-static int use_brk = 1;
+static unsigned long *p2m_missing;
+static unsigned long *p2m_identity;
+static pte_t *p2m_missing_pte;
+static pte_t *p2m_identity_pte;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
@@ -221,14 +118,6 @@ static inline unsigned p2m_index(unsigned long pfn)
 	return pfn % P2M_PER_PAGE;
 }
 
-static void p2m_top_init(unsigned long ***top)
-{
-	unsigned i;
-
-	for (i = 0; i < P2M_TOP_PER_PAGE; i++)
-		top[i] = p2m_mid_missing;
-}
-
 static void p2m_top_mfn_init(unsigned long *top)
 {
 	unsigned i;
@@ -245,35 +134,32 @@ static void p2m_top_mfn_p_init(unsigned long **top)
 		top[i] = p2m_mid_missing_mfn;
 }
 
-static void p2m_mid_init(unsigned long **mid, unsigned long *leaf)
+static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
 {
 	unsigned i;
 
 	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = leaf;
+		mid[i] = virt_to_mfn(leaf);
 }
 
-static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
+static void p2m_init(unsigned long *p2m)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = virt_to_mfn(leaf);
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = INVALID_P2M_ENTRY;
 }
 
-static void p2m_init(unsigned long *p2m)
+static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		p2m[i] = INVALID_P2M_ENTRY;
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = IDENTITY_FRAME(pfn + i);
 }
 
 static void * __ref alloc_p2m_page(void)
 {
-	if (unlikely(use_brk))
-		return extend_brk(PAGE_SIZE, PAGE_SIZE);
-
 	if (unlikely(!slab_is_available()))
 		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
 
@@ -298,6 +184,9 @@ static void free_p2m_page(void *p)
 void __ref xen_build_mfn_list_list(void)
 {
 	unsigned long pfn;
+	pte_t *ptep;
+	unsigned int level, topidx, mididx;
+	unsigned long *mid_mfn_p;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
@@ -317,20 +206,22 @@ void __ref xen_build_mfn_list_list(void)
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 	}
 
-	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned long **mid;
-		unsigned long *mid_mfn_p;
+	for (pfn = 0; pfn < xen_max_p2m_pfn && pfn < MAX_P2M_PFN;
+	     pfn += P2M_PER_PAGE) {
+		topidx = p2m_top_index(pfn);
+		mididx = p2m_mid_index(pfn);
 
-		mid = p2m_top[topidx];
 		mid_mfn_p = p2m_top_mfn_p[topidx];
+		ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn),
+				      &level);
+		BUG_ON(!ptep || level != PG_LEVEL_4K);
+		ptep = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
 		/* Don't bother allocating any mfn mid levels if
 		 * they're just missing, just update the stored mfn,
 		 * since all could have changed over a migrate.
 		 */
-		if (mid == p2m_mid_missing) {
+		if (ptep == p2m_missing_pte || ptep == p2m_identity_pte) {
 			BUG_ON(mididx);
 			BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
 			p2m_top_mfn[topidx] = virt_to_mfn(p2m_mid_missing_mfn);
@@ -339,11 +230,6 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		if (mid_mfn_p == p2m_mid_missing_mfn) {
-			/*
-			 * XXX boot-time only!  We should never find
-			 * missing parts of the mfn tree after
-			 * runtime.
-			 */
 			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
@@ -351,7 +237,7 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
-		mid_mfn_p[mididx] = virt_to_mfn(mid[mididx]);
+		mid_mfn_p[mididx] = virt_to_mfn(xen_p2m_addr + pfn);
 	}
 }
 
@@ -370,154 +256,153 @@ void xen_setup_mfn_list_list(void)
 /* Set up p2m_top to point to the domain-builder provided p2m pages */
 void __init xen_build_dynamic_phys_to_machine(void)
 {
-	unsigned long *mfn_list;
-	unsigned long max_pfn;
 	unsigned long pfn;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
 	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
-	mfn_list = (unsigned long *)xen_start_info->mfn_list;
-	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
-	xen_max_p2m_pfn = max_pfn;
-	xen_p2m_size = max_pfn;
+	xen_p2m_size = ALIGN(xen_start_info->nr_pages, P2M_PER_PAGE);
 
-	p2m_missing = alloc_p2m_page();
-	p2m_init(p2m_missing);
-	p2m_identity = alloc_p2m_page();
-	p2m_init(p2m_identity);
+	for (pfn = xen_start_info->nr_pages; pfn < xen_p2m_size; pfn++)
+		xen_p2m_addr[pfn] = INVALID_P2M_ENTRY;
 
-	p2m_mid_missing = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_identity, p2m_identity);
+	xen_max_p2m_pfn = xen_p2m_size;
+}
 
-	p2m_top = alloc_p2m_page();
-	p2m_top_init(p2m_top);
+#define P2M_TYPE_IDENTITY	0
+#define P2M_TYPE_MISSING	1
+#define P2M_TYPE_PFN		2
+#define P2M_TYPE_UNKNOWN	3
 
-	/*
-	 * The domain builder gives us a pre-constructed p2m array in
-	 * mfn_list for all the pages initially given to us, so we just
-	 * need to graft that into our tree structure.
-	 */
-	for (pfn = 0; pfn < max_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
+static int xen_p2m_elem_type(unsigned long pfn)
+{
+	unsigned long mfn;
 
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = alloc_p2m_page();
-			p2m_mid_init(mid, p2m_missing);
+	if (pfn >= xen_p2m_size)
+		return P2M_TYPE_IDENTITY;
 
-			p2m_top[topidx] = mid;
-		}
+	mfn = xen_p2m_addr[pfn];
 
-		/*
-		 * As long as the mfn_list has enough entries to completely
-		 * fill a p2m page, pointing into the array is ok. But if
-		 * not the entries beyond the last pfn will be undefined.
-		 */
-		if (unlikely(pfn + P2M_PER_PAGE > max_pfn)) {
-			unsigned long p2midx;
+	if (mfn == INVALID_P2M_ENTRY)
+		return P2M_TYPE_MISSING;
 
-			p2midx = max_pfn % P2M_PER_PAGE;
-			for ( ; p2midx < P2M_PER_PAGE; p2midx++)
-				mfn_list[pfn + p2midx] = INVALID_P2M_ENTRY;
-		}
-		p2m_top[topidx][mididx] = &mfn_list[pfn];
-	}
+	if (mfn & IDENTITY_FRAME_BIT)
+		return P2M_TYPE_IDENTITY;
+
+	return P2M_TYPE_PFN;
 }
-#ifdef CONFIG_X86_64
-unsigned long __init xen_revector_p2m_tree(void)
+
+static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 {
-	unsigned long va_start;
-	unsigned long va_end;
+	unsigned int i, chunk;
 	unsigned long pfn;
-	unsigned long pfn_free = 0;
-	unsigned long *mfn_list = NULL;
-	unsigned long size;
-
-	use_brk = 0;
-	va_start = xen_start_info->mfn_list;
-	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
-	 * so make sure it is rounded up to that */
-	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
-	va_end = va_start + size;
-
-	/* If we were revectored already, don't do it again. */
-	if (va_start <= __START_KERNEL_map && va_start >= __PAGE_OFFSET)
-		return 0;
-
-	mfn_list = alloc_bootmem_align(size, PAGE_SIZE);
-	if (!mfn_list) {
-		pr_warn("Could not allocate space for a new P2M tree!\n");
-		return xen_start_info->mfn_list;
-	}
-	/* Fill it out with INVALID_P2M_ENTRY value */
-	memset(mfn_list, 0xFF, size);
-
-	for (pfn = 0; pfn < ALIGN(MAX_DOMAIN_PAGES, P2M_PER_PAGE); pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx;
-		unsigned long *mid_p;
+	unsigned long *mfns;
+	pte_t *ptep;
+	pmd_t *pmdp;
+	int type;
 
-		if (!p2m_top[topidx])
-			continue;
+	p2m_missing = alloc_p2m_page();
+	p2m_init(p2m_missing);
+	p2m_identity = alloc_p2m_page();
+	p2m_init(p2m_identity);
 
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
+	p2m_missing_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_missing_pte) >> PAGE_SHIFT);
+	p2m_identity_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
+	for (i = 0; i < PTRS_PER_PTE; i++) {
+		set_pte(p2m_missing_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
+		set_pte(p2m_identity_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
+	}
 
-		mididx = p2m_mid_index(pfn);
-		mid_p = p2m_top[topidx][mididx];
-		if (!mid_p)
-			continue;
-		if ((mid_p == p2m_missing) || (mid_p == p2m_identity))
+	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
+		/*
+		 * Try to map missing/identity PMDs or p2m-pages if possible.
+		 * We have to respect the structure of the mfn_list_list
+		 * which will be built a little bit later.
+		 * Chunk size to test is one p2m page if we are in the middle
+		 * of a mfn_list_list mid page and the complete mid page area
+		 * if we are at index 0 of the mid page. Please note that a
+		 * mid page might cover more than one PMD, e.g. on 32 bit PAE
+		 * kernels.
+		 */
+		chunk = (pfn & (P2M_PER_PAGE * P2M_MID_PER_PAGE - 1)) ?
+			P2M_PER_PAGE : P2M_PER_PAGE * P2M_MID_PER_PAGE;
+
+		type = xen_p2m_elem_type(pfn);
+		i = 0;
+		if (type != P2M_TYPE_PFN)
+			for (i = 1; i < chunk; i++)
+				if (xen_p2m_elem_type(pfn + i) != type)
+					break;
+		if (i < chunk)
+			/* Reset to minimal chunk size. */
+			chunk = P2M_PER_PAGE;
+
+		if (type == P2M_TYPE_PFN || i < chunk) {
+			/* Use initial p2m page contents. */
+#ifdef CONFIG_X86_64
+			mfns = alloc_p2m_page();
+			copy_page(mfns, xen_p2m_addr + pfn);
+#else
+			mfns = xen_p2m_addr + pfn;
+#endif
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		if ((unsigned long)mid_p == INVALID_P2M_ENTRY)
+		if (chunk == P2M_PER_PAGE) {
+			/* Map complete missing or identity p2m-page. */
+			mfns = (type == P2M_TYPE_MISSING) ?
+				p2m_missing : p2m_identity;
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		/* The old va. Rebase it on mfn_list */
-		if (mid_p >= (unsigned long *)va_start && mid_p <= (unsigned long *)va_end) {
-			unsigned long *new;
+		/* Complete missing or identity PMD(s) can be mapped. */
+		ptep = (type == P2M_TYPE_MISSING) ?
+			p2m_missing_pte : p2m_identity_pte;
+		for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+			pmdp = populate_extra_pmd(
+				(unsigned long)(p2m + pfn + i * PTRS_PER_PTE));
+			set_pmd(pmdp, __pmd(__pa(ptep) | _KERNPG_TABLE));
+		}
+	}
+}
 
-			if (pfn_free  > (size / sizeof(unsigned long))) {
-				WARN(1, "Only allocated for %ld pages, but we want %ld!\n",
-				     size / sizeof(unsigned long), pfn_free);
-				return 0;
-			}
-			new = &mfn_list[pfn_free];
+void __init xen_vmalloc_p2m_tree(void)
+{
+	static struct vm_struct vm;
 
-			copy_page(new, mid_p);
-			p2m_top[topidx][mididx] = &mfn_list[pfn_free];
+	vm.flags = VM_ALLOC;
+	vm.size = ALIGN(sizeof(unsigned long) * xen_max_p2m_pfn,
+			PMD_SIZE * PMDS_PER_MID_PAGE);
+	vm_area_register_early(&vm, PMD_SIZE * PMDS_PER_MID_PAGE);
+	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);
 
-			pfn_free += P2M_PER_PAGE;
+	xen_max_p2m_pfn = vm.size / sizeof(unsigned long);
 
-		}
-		/* This should be the leafs allocated for identity from _brk. */
-	}
+	xen_rebuild_p2m_list(vm.addr);
 
+	xen_p2m_addr = vm.addr;
 	xen_p2m_size = xen_max_p2m_pfn;
-	xen_p2m_addr = mfn_list;
 
 	xen_inv_extra_mem();
 
 	m2p_override_init();
-	return (unsigned long)mfn_list;
 }
-#else
-unsigned long __init xen_revector_p2m_tree(void)
-{
-	use_brk = 0;
-	xen_p2m_size = xen_max_p2m_pfn;
-	xen_inv_extra_mem();
-	m2p_override_init();
-	return 0;
-}
-#endif
+
 unsigned long get_phys_to_machine(unsigned long pfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	if (unlikely(pfn >= xen_p2m_size)) {
 		if (pfn < xen_max_p2m_pfn)
@@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 		return IDENTITY_FRAME(pfn);
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
 	/*
 	 * The INVALID_P2M_ENTRY is filled in both p2m_*identity
 	 * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
 	 * would be wrong.
 	 */
-	if (p2m_top[topidx][mididx] == p2m_identity)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
 		return IDENTITY_FRAME(pfn);
 
-	return p2m_top[topidx][mididx][idx];
+	return xen_p2m_addr[pfn];
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
 /*
+ * Allocate new pmd(s). It is checked whether the old pmd is still in place.
+ * If not, nothing is changed. This is okay as the only reason for allocating
+ * a new pmd is to replace p2m_missing_pte or p2m_identity_pte by a individual
+ * pmd. In case of PAE/x86-32 there are multiple pmds to allocate!
+ */
+static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t *ptep, pte_t *pte_pg)
+{
+	pte_t *ptechk;
+	pte_t *pteret = ptep;
+	pte_t *pte_newpg[PMDS_PER_MID_PAGE];
+	pmd_t *pmdp;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long vaddr;
+	int i;
+
+	/* Do all allocations first to bail out in error case. */
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		pte_newpg[i] = alloc_p2m_page();
+		if (!pte_newpg[i]) {
+			for (i--; i >= 0; i--)
+				free_p2m_page(pte_newpg[i]);
+
+			return NULL;
+		}
+	}
+
+	vaddr = addr & ~(PMD_SIZE * PMDS_PER_MID_PAGE - 1);
+
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		copy_page(pte_newpg[i], pte_pg);
+		paravirt_alloc_pte(&init_mm, __pa(pte_newpg[i]) >> PAGE_SHIFT);
+
+		pmdp = lookup_pmd_address(vaddr);
+		BUG_ON(!pmdp);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		ptechk = lookup_address(vaddr, &level);
+		if (ptechk == pte_pg) {
+			set_pmd(pmdp,
+				__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+			if (vaddr == (addr & ~(PMD_SIZE - 1)))
+				pteret = pte_offset_kernel(pmdp, addr);
+			pte_newpg[i] = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
+
+		if (pte_newpg[i]) {
+			paravirt_release_pte(__pa(pte_newpg[i]) >> PAGE_SHIFT);
+			free_p2m_page(pte_newpg[i]);
+		}
+
+		vaddr += PMD_SIZE;
+	}
+
+	return pteret;
+}
+
+/*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
  * parallel mfn tree is kept in sync.  We may race with other cpus, so
@@ -552,58 +497,62 @@ EXPORT_SYMBOL_GPL(get_phys_to_machine);
 static bool alloc_p2m(unsigned long pfn)
 {
 	unsigned topidx, mididx;
-	unsigned long ***top_p, **mid;
 	unsigned long *top_mfn_p, *mid_mfn;
-	unsigned long *p2m_orig;
+	pte_t *ptep, *pte_pg;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long addr = (unsigned long)(xen_p2m_addr + pfn);
+	unsigned long p2m_pfn;
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
 
-	top_p = &p2m_top[topidx];
-	mid = ACCESS_ONCE(*top_p);
+	ptep = lookup_address(addr, &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
+	pte_pg = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
-	if (mid == p2m_mid_missing) {
-		/* Mid level is missing, allocate a new one */
-		mid = alloc_p2m_page();
-		if (!mid)
+	if (pte_pg == p2m_missing_pte || pte_pg == p2m_identity_pte) {
+		/* PMD level is missing, allocate a new one */
+		ptep = alloc_p2m_pmd(addr, ptep, pte_pg);
+		if (!ptep)
 			return false;
-
-		p2m_mid_init(mid, p2m_missing);
-
-		if (cmpxchg(top_p, p2m_mid_missing, mid) != p2m_mid_missing)
-			free_p2m_page(mid);
 	}
 
-	top_mfn_p = &p2m_top_mfn[topidx];
-	mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
+	if (p2m_top_mfn) {
+		top_mfn_p = &p2m_top_mfn[topidx];
+		mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
 
-	BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
+		BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
 
-	if (mid_mfn == p2m_mid_missing_mfn) {
-		/* Separately check the mid mfn level */
-		unsigned long missing_mfn;
-		unsigned long mid_mfn_mfn;
-		unsigned long old_mfn;
+		if (mid_mfn == p2m_mid_missing_mfn) {
+			/* Separately check the mid mfn level */
+			unsigned long missing_mfn;
+			unsigned long mid_mfn_mfn;
+			unsigned long old_mfn;
 
-		mid_mfn = alloc_p2m_page();
-		if (!mid_mfn)
-			return false;
+			mid_mfn = alloc_p2m_page();
+			if (!mid_mfn)
+				return false;
 
-		p2m_mid_mfn_init(mid_mfn, p2m_missing);
+			p2m_mid_mfn_init(mid_mfn, p2m_missing);
 
-		missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
-		mid_mfn_mfn = virt_to_mfn(mid_mfn);
-		old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
-		if (old_mfn != missing_mfn) {
-			free_p2m_page(mid_mfn);
-			mid_mfn = mfn_to_virt(old_mfn);
-		} else {
-			p2m_top_mfn_p[topidx] = mid_mfn;
+			missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
+			mid_mfn_mfn = virt_to_mfn(mid_mfn);
+			old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
+			if (old_mfn != missing_mfn) {
+				free_p2m_page(mid_mfn);
+				mid_mfn = mfn_to_virt(old_mfn);
+			} else {
+				p2m_top_mfn_p[topidx] = mid_mfn;
+			}
 		}
+	} else {
+		mid_mfn = NULL;
 	}
 
-	p2m_orig = ACCESS_ONCE(p2m_top[topidx][mididx]);
-	if (p2m_orig == p2m_identity || p2m_orig == p2m_missing) {
+	p2m_pfn = pte_pfn(ACCESS_ONCE(*ptep));
+	if (p2m_pfn == PFN_DOWN(__pa(p2m_identity)) ||
+	    p2m_pfn == PFN_DOWN(__pa(p2m_missing))) {
 		/* p2m leaf page is missing */
 		unsigned long *p2m;
 
@@ -611,12 +560,25 @@ static bool alloc_p2m(unsigned long pfn)
 		if (!p2m)
 			return false;
 
-		p2m_init(p2m);
+		if (p2m_pfn == PFN_DOWN(__pa(p2m_missing)))
+			p2m_init(p2m);
+		else
+			p2m_init_identity(p2m, pfn);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		if (pte_pfn(*ptep) == p2m_pfn) {
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(p2m)), PAGE_KERNEL));
+			if (mid_mfn)
+				mid_mfn[mididx] = virt_to_mfn(p2m);
+			p2m = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
 
-		if (cmpxchg(&mid[mididx], p2m_orig, p2m) != p2m_orig)
+		if (p2m)
 			free_p2m_page(p2m);
-		else
-			mid_mfn[mididx] = virt_to_mfn(p2m);
 	}
 
 	return true;
@@ -645,10 +607,10 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	return pfn - pfn_s;
 }
 
-/* Try to install p2m mapping; fail if intermediate bits missing */
 bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	/* don't track P2M changes in autotranslate guests */
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -659,55 +621,27 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* For sparse holes were the p2m leaf has real PFN along with
-	 * PCI holes, stick in the PFN as the MFN value.
-	 *
-	 * set_phys_range_identity() will have allocated new middle
-	 * and leaf pages as required so an existing p2m_mid_missing
-	 * or p2m_missing mean that whole range will be identity so
-	 * these can be switched to p2m_mid_identity or p2m_identity.
-	 */
-	if (mfn != INVALID_P2M_ENTRY && (mfn & IDENTITY_FRAME_BIT)) {
-		if (p2m_top[topidx] == p2m_mid_identity)
-			return true;
-
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx], p2m_mid_missing,
-					p2m_mid_identity) != p2m_mid_missing);
-			return true;
-		}
-
-		if (p2m_top[topidx][mididx] == p2m_identity)
-			return true;
-
-		/* Swap over from MISSING to IDENTITY if needed. */
-		if (p2m_top[topidx][mididx] == p2m_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx][mididx], p2m_missing,
-				p2m_identity) != p2m_missing);
-			return true;
-		}
-	}
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
-	if (p2m_top[topidx][mididx] == p2m_missing)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_missing)))
 		return mfn == INVALID_P2M_ENTRY;
 
-	p2m_top[topidx][mididx][idx] = mfn;
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
+		return mfn == IDENTITY_FRAME(pfn);
+
+	xen_p2m_addr[pfn] = mfn;
 
 	return true;
 }
 
 bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
+	if (unlikely(!__set_phys_to_machine(pfn, mfn))) {
 		if (!alloc_p2m(pfn))
 			return false;
 
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
+		return __set_phys_to_machine(pfn, mfn);
 	}
 
 	return true;
@@ -1033,79 +967,29 @@ EXPORT_SYMBOL_GPL(m2p_find_override_pfn);
 #include "debugfs.h"
 static int p2m_dump_show(struct seq_file *m, void *v)
 {
-	static const char * const level_name[] = { "top", "middle",
-						"entry", "abnormal", "error"};
-#define TYPE_IDENTITY 0
-#define TYPE_MISSING 1
-#define TYPE_PFN 2
-#define TYPE_UNKNOWN 3
 	static const char * const type_name[] = {
-				[TYPE_IDENTITY] = "identity",
-				[TYPE_MISSING] = "missing",
-				[TYPE_PFN] = "pfn",
-				[TYPE_UNKNOWN] = "abnormal"};
-	unsigned long pfn, prev_pfn_type = 0, prev_pfn_level = 0;
-	unsigned int uninitialized_var(prev_level);
-	unsigned int uninitialized_var(prev_type);
-
-	if (!p2m_top)
-		return 0;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn++) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned idx = p2m_index(pfn);
-		unsigned lvl, type;
-
-		lvl = 4;
-		type = TYPE_UNKNOWN;
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			lvl = 0; type = TYPE_MISSING;
-		} else if (p2m_top[topidx] == NULL) {
-			lvl = 0; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == NULL) {
-			lvl = 1; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == p2m_identity) {
-			lvl = 1; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx] == p2m_missing) {
-			lvl = 1; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == 0) {
-			lvl = 2; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx][idx] == IDENTITY_FRAME(pfn)) {
-			lvl = 2; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx][idx] == INVALID_P2M_ENTRY) {
-			lvl = 2; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == pfn) {
-			lvl = 2; type = TYPE_PFN;
-		} else if (p2m_top[topidx][mididx][idx] != pfn) {
-			lvl = 2; type = TYPE_PFN;
-		}
-		if (pfn == 0) {
-			prev_level = lvl;
+				[P2M_TYPE_IDENTITY] = "identity",
+				[P2M_TYPE_MISSING] = "missing",
+				[P2M_TYPE_PFN] = "pfn",
+				[P2M_TYPE_UNKNOWN] = "abnormal"};
+	unsigned long pfn, first_pfn;
+	int type, prev_type;
+
+	prev_type = xen_p2m_elem_type(0);
+	first_pfn = 0;
+
+	for (pfn = 0; pfn < xen_p2m_size; pfn++) {
+		type = xen_p2m_elem_type(pfn);
+		if (type != prev_type) {
+			seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+				   type_name[prev_type]);
 			prev_type = type;
-		}
-		if (pfn == MAX_DOMAIN_PAGES-1) {
-			lvl = 3;
-			type = TYPE_UNKNOWN;
-		}
-		if (prev_type != type) {
-			seq_printf(m, " [0x%lx->0x%lx] %s\n",
-				prev_pfn_type, pfn, type_name[prev_type]);
-			prev_pfn_type = pfn;
-			prev_type = type;
-		}
-		if (prev_level != lvl) {
-			seq_printf(m, " [0x%lx->0x%lx] level %s\n",
-				prev_pfn_level, pfn, level_name[prev_level]);
-			prev_pfn_level = pfn;
-			prev_level = lvl;
+			first_pfn = pfn;
 		}
 	}
+	seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+		   type_name[prev_type]);
 	return 0;
-#undef TYPE_IDENTITY
-#undef TYPE_MISSING
-#undef TYPE_PFN
-#undef TYPE_UNKNOWN
 }
 
 static int p2m_dump_open(struct inode *inode, struct file *filp)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 02b0b0f..f92921f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -49,7 +49,7 @@ void xen_hvm_init_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-unsigned long __init xen_revector_p2m_tree(void);
+void __init xen_vmalloc_p2m_tree(void);
 
 void xen_init_irq_ops(void);
 void xen_setup_timer(int cpu);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FI-0001bS-TE; Tue, 11 Nov 2014 05:44:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FG-0001aY-EI
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	40/01-09936-122A1645; Tue, 11 Nov 2014 05:44:01 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415684639!12817146!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14163 invoked from network); 11 Nov 2014 05:43:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:59 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id AE546ACEE;
	Tue, 11 Nov 2014 05:43:59 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:45 +0100
Message-Id: <1415684626-18590-8-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
	sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At start of the day the Xen hypervisor presents a contiguous mfn list
to a pv-domain. In order to support sparse memory this mfn list is
accessed via a three level p2m tree built early in the boot process.
Whenever the system needs the mfn associated with a pfn this tree is
used to find the mfn.

Instead of using a software walked tree for accessing a specific mfn
list entry this patch is creating a virtual address area for the
entire possible mfn list including memory holes. The holes are
covered by mapping a pre-defined  page consisting only of "invalid
mfn" entries. Access to a mfn entry is possible by just using the
virtual base address of the mfn list and the pfn as index into that
list. This speeds up the (hot) path of determining the mfn of a
pfn.

Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
showed following improvements:

Elapsed time: 32:50 ->  32:35
System:       18:07 ->  17:47
User:        104:00 -> 103:30

Tested on 64 bit dom0 and 32 bit domU.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |  14 +-
 arch/x86/xen/mmu.c              |  32 +-
 arch/x86/xen/p2m.c              | 732 +++++++++++++++++-----------------------
 arch/x86/xen/xen-ops.h          |   2 +-
 4 files changed, 342 insertions(+), 438 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 07d8a7b..4a227ec 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -72,7 +72,19 @@ extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
  */
 static inline unsigned long __pfn_to_mfn(unsigned long pfn)
 {
-	return get_phys_to_machine(pfn);
+	unsigned long mfn;
+
+	if (pfn < xen_p2m_size)
+		mfn = xen_p2m_addr[pfn];
+	else if (unlikely(pfn < xen_max_p2m_pfn))
+		return get_phys_to_machine(pfn);
+	else
+		return IDENTITY_FRAME(pfn);
+
+	if (unlikely(mfn == INVALID_P2M_ENTRY))
+		return get_phys_to_machine(pfn);
+
+	return mfn;
 }
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 31ca515..0b43c45 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1158,20 +1158,16 @@ static void __init xen_cleanhighmap(unsigned long vaddr,
 	 * instead of somewhere later and be confusing. */
 	xen_mc_flush();
 }
-static void __init xen_pagetable_p2m_copy(void)
+
+static void __init xen_pagetable_p2m_free(void)
 {
 	unsigned long size;
 	unsigned long addr;
-	unsigned long new_mfn_list;
-
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return;
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 
-	new_mfn_list = xen_revector_p2m_tree();
 	/* No memory or already called. */
-	if (!new_mfn_list || new_mfn_list == xen_start_info->mfn_list)
+	if ((unsigned long)xen_p2m_addr == xen_start_info->mfn_list)
 		return;
 
 	/* using __ka address and sticking INVALID_P2M_ENTRY! */
@@ -1189,8 +1185,6 @@ static void __init xen_pagetable_p2m_copy(void)
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 	memblock_free(__pa(xen_start_info->mfn_list), size);
-	/* And revector! Bye bye old array */
-	xen_start_info->mfn_list = new_mfn_list;
 
 	/* At this stage, cleanup_highmap has already cleaned __ka space
 	 * from _brk_limit way up to the max_pfn_mapped (which is the end of
@@ -1214,12 +1208,26 @@ static void __init xen_pagetable_p2m_copy(void)
 }
 #endif
 
-static void __init xen_pagetable_init(void)
+static void __init xen_pagetable_p2m_setup(void)
 {
-	paging_init();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	xen_vmalloc_p2m_tree();
+
 #ifdef CONFIG_X86_64
-	xen_pagetable_p2m_copy();
+	xen_pagetable_p2m_free();
 #endif
+	/* And revector! Bye bye old array */
+	xen_start_info->mfn_list = (unsigned long)xen_p2m_addr;
+}
+
+static void __init xen_pagetable_init(void)
+{
+	paging_init();
+
+	xen_pagetable_p2m_setup();
+
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 328875a..7df446d 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -3,21 +3,22 @@
  * guests themselves, but it must also access and update the p2m array
  * during suspend/resume when all the pages are reallocated.
  *
- * The p2m table is logically a flat array, but we implement it as a
- * three-level tree to allow the address space to be sparse.
+ * The logical flat p2m table is mapped to a linear kernel memory area.
+ * For accesses by Xen a three-level tree linked via mfns only is set up to
+ * allow the address space to be sparse.
  *
- *                               Xen
- *                                |
- *     p2m_top              p2m_top_mfn
- *       /  \                   /   \
- * p2m_mid p2m_mid	p2m_mid_mfn p2m_mid_mfn
- *    / \      / \         /           /
- *  p2m p2m p2m p2m p2m p2m p2m ...
+ *               Xen
+ *                |
+ *          p2m_top_mfn
+ *              /   \
+ * p2m_mid_mfn p2m_mid_mfn
+ *         /           /
+ *  p2m p2m p2m ...
  *
  * The p2m_mid_mfn pages are mapped by p2m_top_mfn_p.
  *
- * The p2m_top and p2m_top_mfn levels are limited to 1 page, so the
- * maximum representable pseudo-physical address space is:
+ * The p2m_top_mfn level is limited to 1 page, so the maximum representable
+ * pseudo-physical address space is:
  *  P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * P2M_PER_PAGE pages
  *
  * P2M_PER_PAGE depends on the architecture, as a mfn is always
@@ -30,6 +31,9 @@
  * leaf entries, or for the top  root, or middle one, for which there is a void
  * entry, we assume it is  "missing". So (for example)
  *  pfn_to_mfn(0x90909090)=INVALID_P2M_ENTRY.
+ * We have a dedicated page p2m_missing with all entries being
+ * INVALID_P2M_ENTRY. This page may be referenced multiple times in the p2m
+ * list/tree in case there are multiple areas with P2M_PER_PAGE invalid pfns.
  *
  * We also have the possibility of setting 1-1 mappings on certain regions, so
  * that:
@@ -39,122 +43,20 @@
  * PCI BARs, or ACPI spaces), we can create mappings easily because we
  * get the PFN value to match the MFN.
  *
- * For this to work efficiently we have one new page p2m_identity and
- * allocate (via reserved_brk) any other pages we need to cover the sides
- * (1GB or 4MB boundary violations). All entries in p2m_identity are set to
- * INVALID_P2M_ENTRY type (Xen toolstack only recognizes that and MFNs,
- * no other fancy value).
+ * For this to work efficiently we have one new page p2m_identity. All entries
+ * in p2m_identity are set to INVALID_P2M_ENTRY type (Xen toolstack only
+ * recognizes that and MFNs, no other fancy value).
  *
  * On lookup we spot that the entry points to p2m_identity and return the
  * identity value instead of dereferencing and returning INVALID_P2M_ENTRY.
  * If the entry points to an allocated page, we just proceed as before and
- * return the PFN.  If the PFN has IDENTITY_FRAME_BIT set we unmask that in
+ * return the PFN. If the PFN has IDENTITY_FRAME_BIT set we unmask that in
  * appropriate functions (pfn_to_mfn).
  *
  * The reason for having the IDENTITY_FRAME_BIT instead of just returning the
  * PFN is that we could find ourselves where pfn_to_mfn(pfn)==pfn for a
  * non-identity pfn. To protect ourselves against we elect to set (and get) the
  * IDENTITY_FRAME_BIT on all identity mapped PFNs.
- *
- * This simplistic diagram is used to explain the more subtle piece of code.
- * There is also a digram of the P2M at the end that can help.
- * Imagine your E820 looking as so:
- *
- *                    1GB                                           2GB    4GB
- * /-------------------+---------\/----\         /----------\    /---+-----\
- * | System RAM        | Sys RAM ||ACPI|         | reserved |    | Sys RAM |
- * \-------------------+---------/\----/         \----------/    \---+-----/
- *                               ^- 1029MB                       ^- 2001MB
- *
- * [1029MB = 263424 (0x40500), 2001MB = 512256 (0x7D100),
- *  2048MB = 524288 (0x80000)]
- *
- * And dom0_mem=max:3GB,1GB is passed in to the guest, meaning memory past 1GB
- * is actually not present (would have to kick the balloon driver to put it in).
- *
- * When we are told to set the PFNs for identity mapping (see patch: "xen/setup:
- * Set identity mapping for non-RAM E820 and E820 gaps.") we pass in the start
- * of the PFN and the end PFN (263424 and 512256 respectively). The first step
- * is to reserve_brk a top leaf page if the p2m[1] is missing. The top leaf page
- * covers 512^2 of page estate (1GB) and in case the start or end PFN is not
- * aligned on 512^2*PAGE_SIZE (1GB) we reserve_brk new middle and leaf pages as
- * required to split any existing p2m_mid_missing middle pages.
- *
- * With the E820 example above, 263424 is not 1GB aligned so we allocate a
- * reserve_brk page which will cover the PFNs estate from 0x40000 to 0x80000.
- * Each entry in the allocate page is "missing" (points to p2m_missing).
- *
- * Next stage is to determine if we need to do a more granular boundary check
- * on the 4MB (or 2MB depending on architecture) off the start and end pfn's.
- * We check if the start pfn and end pfn violate that boundary check, and if
- * so reserve_brk a (p2m[x][y]) leaf page. This way we have a much finer
- * granularity of setting which PFNs are missing and which ones are identity.
- * In our example 263424 and 512256 both fail the check so we reserve_brk two
- * pages. Populate them with INVALID_P2M_ENTRY (so they both have "missing"
- * values) and assign them to p2m[1][2] and p2m[1][488] respectively.
- *
- * At this point we would at minimum reserve_brk one page, but could be up to
- * three. Each call to set_phys_range_identity has at maximum a three page
- * cost. If we were to query the P2M at this stage, all those entries from
- * start PFN through end PFN (so 1029MB -> 2001MB) would return
- * INVALID_P2M_ENTRY ("missing").
- *
- * The next step is to walk from the start pfn to the end pfn setting
- * the IDENTITY_FRAME_BIT on each PFN. This is done in set_phys_range_identity.
- * If we find that the middle entry is pointing to p2m_missing we can swap it
- * over to p2m_identity - this way covering 4MB (or 2MB) PFN space (and
- * similarly swapping p2m_mid_missing for p2m_mid_identity for larger regions).
- * At this point we do not need to worry about boundary aligment (so no need to
- * reserve_brk a middle page, figure out which PFNs are "missing" and which
- * ones are identity), as that has been done earlier.  If we find that the
- * middle leaf is not occupied by p2m_identity or p2m_missing, we dereference
- * that page (which covers 512 PFNs) and set the appropriate PFN with
- * IDENTITY_FRAME_BIT. In our example 263424 and 512256 end up there, and we
- * set from p2m[1][2][256->511] and p2m[1][488][0->256] with
- * IDENTITY_FRAME_BIT set.
- *
- * All other regions that are void (or not filled) either point to p2m_missing
- * (considered missing) or have the default value of INVALID_P2M_ENTRY (also
- * considered missing). In our case, p2m[1][2][0->255] and p2m[1][488][257->511]
- * contain the INVALID_P2M_ENTRY value and are considered "missing."
- *
- * Finally, the region beyond the end of of the E820 (4 GB in this example)
- * is set to be identity (in case there are MMIO regions placed here).
- *
- * This is what the p2m ends up looking (for the E820 above) with this
- * fabulous drawing:
- *
- *    p2m         /--------------\
- *  /-----\       | &mfn_list[0],|                           /-----------------\
- *  |  0  |------>| &mfn_list[1],|    /---------------\      | ~0, ~0, ..      |
- *  |-----|       |  ..., ~0, ~0 |    | ~0, ~0, [x]---+----->| IDENTITY [@256] |
- *  |  1  |---\   \--------------/    | [p2m_identity]+\     | IDENTITY [@257] |
- *  |-----|    \                      | [p2m_identity]+\\    | ....            |
- *  |  2  |--\  \-------------------->|  ...          | \\   \----------------/
- *  |-----|   \                       \---------------/  \\
- *  |  3  |-\  \                                          \\  p2m_identity [1]
- *  |-----|  \  \-------------------->/---------------\   /-----------------\
- *  | ..  |\  |                       | [p2m_identity]+-->| ~0, ~0, ~0, ... |
- *  \-----/ | |                       | [p2m_identity]+-->| ..., ~0         |
- *          | |                       | ....          |   \-----------------/
- *          | |                       +-[x], ~0, ~0.. +\
- *          | |                       \---------------/ \
- *          | |                                          \-> /---------------\
- *          | V  p2m_mid_missing       p2m_missing           | IDENTITY[@0]  |
- *          | /-----------------\     /------------\         | IDENTITY[@256]|
- *          | | [p2m_missing]   +---->| ~0, ~0, ...|         | ~0, ~0, ....  |
- *          | | [p2m_missing]   +---->| ..., ~0    |         \---------------/
- *          | | ...             |     \------------/
- *          | \-----------------/
- *          |
- *          |     p2m_mid_identity
- *          |   /-----------------\
- *          \-->| [p2m_identity]  +---->[1]
- *              | [p2m_identity]  +---->[1]
- *              | ...             |
- *              \-----------------/
- *
- * where ~0 is INVALID_P2M_ENTRY. IDENTITY is (PFN | IDENTITY_BIT)
  */
 
 #include <linux/init.h>
@@ -179,6 +81,8 @@
 #include "multicalls.h"
 #include "xen-ops.h"
 
+#define PMDS_PER_MID_PAGE	(P2M_MID_PER_PAGE / PTRS_PER_PTE)
+
 static void __init m2p_override_init(void);
 
 unsigned long *xen_p2m_addr __read_mostly;
@@ -188,22 +92,15 @@ EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
 EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
+static DEFINE_SPINLOCK(p2m_update_lock);
+
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
 static unsigned long **p2m_top_mfn_p;
-
-/* Placeholders for holes in the address space */
-static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long **, p2m_top, P2M_TOP_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long, p2m_identity, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
-
-RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
-
-static int use_brk = 1;
+static unsigned long *p2m_missing;
+static unsigned long *p2m_identity;
+static pte_t *p2m_missing_pte;
+static pte_t *p2m_identity_pte;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
@@ -221,14 +118,6 @@ static inline unsigned p2m_index(unsigned long pfn)
 	return pfn % P2M_PER_PAGE;
 }
 
-static void p2m_top_init(unsigned long ***top)
-{
-	unsigned i;
-
-	for (i = 0; i < P2M_TOP_PER_PAGE; i++)
-		top[i] = p2m_mid_missing;
-}
-
 static void p2m_top_mfn_init(unsigned long *top)
 {
 	unsigned i;
@@ -245,35 +134,32 @@ static void p2m_top_mfn_p_init(unsigned long **top)
 		top[i] = p2m_mid_missing_mfn;
 }
 
-static void p2m_mid_init(unsigned long **mid, unsigned long *leaf)
+static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
 {
 	unsigned i;
 
 	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = leaf;
+		mid[i] = virt_to_mfn(leaf);
 }
 
-static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
+static void p2m_init(unsigned long *p2m)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = virt_to_mfn(leaf);
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = INVALID_P2M_ENTRY;
 }
 
-static void p2m_init(unsigned long *p2m)
+static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		p2m[i] = INVALID_P2M_ENTRY;
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = IDENTITY_FRAME(pfn + i);
 }
 
 static void * __ref alloc_p2m_page(void)
 {
-	if (unlikely(use_brk))
-		return extend_brk(PAGE_SIZE, PAGE_SIZE);
-
 	if (unlikely(!slab_is_available()))
 		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
 
@@ -298,6 +184,9 @@ static void free_p2m_page(void *p)
 void __ref xen_build_mfn_list_list(void)
 {
 	unsigned long pfn;
+	pte_t *ptep;
+	unsigned int level, topidx, mididx;
+	unsigned long *mid_mfn_p;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
@@ -317,20 +206,22 @@ void __ref xen_build_mfn_list_list(void)
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 	}
 
-	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned long **mid;
-		unsigned long *mid_mfn_p;
+	for (pfn = 0; pfn < xen_max_p2m_pfn && pfn < MAX_P2M_PFN;
+	     pfn += P2M_PER_PAGE) {
+		topidx = p2m_top_index(pfn);
+		mididx = p2m_mid_index(pfn);
 
-		mid = p2m_top[topidx];
 		mid_mfn_p = p2m_top_mfn_p[topidx];
+		ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn),
+				      &level);
+		BUG_ON(!ptep || level != PG_LEVEL_4K);
+		ptep = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
 		/* Don't bother allocating any mfn mid levels if
 		 * they're just missing, just update the stored mfn,
 		 * since all could have changed over a migrate.
 		 */
-		if (mid == p2m_mid_missing) {
+		if (ptep == p2m_missing_pte || ptep == p2m_identity_pte) {
 			BUG_ON(mididx);
 			BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
 			p2m_top_mfn[topidx] = virt_to_mfn(p2m_mid_missing_mfn);
@@ -339,11 +230,6 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		if (mid_mfn_p == p2m_mid_missing_mfn) {
-			/*
-			 * XXX boot-time only!  We should never find
-			 * missing parts of the mfn tree after
-			 * runtime.
-			 */
 			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
@@ -351,7 +237,7 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
-		mid_mfn_p[mididx] = virt_to_mfn(mid[mididx]);
+		mid_mfn_p[mididx] = virt_to_mfn(xen_p2m_addr + pfn);
 	}
 }
 
@@ -370,154 +256,153 @@ void xen_setup_mfn_list_list(void)
 /* Set up p2m_top to point to the domain-builder provided p2m pages */
 void __init xen_build_dynamic_phys_to_machine(void)
 {
-	unsigned long *mfn_list;
-	unsigned long max_pfn;
 	unsigned long pfn;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
 	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
-	mfn_list = (unsigned long *)xen_start_info->mfn_list;
-	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
-	xen_max_p2m_pfn = max_pfn;
-	xen_p2m_size = max_pfn;
+	xen_p2m_size = ALIGN(xen_start_info->nr_pages, P2M_PER_PAGE);
 
-	p2m_missing = alloc_p2m_page();
-	p2m_init(p2m_missing);
-	p2m_identity = alloc_p2m_page();
-	p2m_init(p2m_identity);
+	for (pfn = xen_start_info->nr_pages; pfn < xen_p2m_size; pfn++)
+		xen_p2m_addr[pfn] = INVALID_P2M_ENTRY;
 
-	p2m_mid_missing = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_identity, p2m_identity);
+	xen_max_p2m_pfn = xen_p2m_size;
+}
 
-	p2m_top = alloc_p2m_page();
-	p2m_top_init(p2m_top);
+#define P2M_TYPE_IDENTITY	0
+#define P2M_TYPE_MISSING	1
+#define P2M_TYPE_PFN		2
+#define P2M_TYPE_UNKNOWN	3
 
-	/*
-	 * The domain builder gives us a pre-constructed p2m array in
-	 * mfn_list for all the pages initially given to us, so we just
-	 * need to graft that into our tree structure.
-	 */
-	for (pfn = 0; pfn < max_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
+static int xen_p2m_elem_type(unsigned long pfn)
+{
+	unsigned long mfn;
 
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = alloc_p2m_page();
-			p2m_mid_init(mid, p2m_missing);
+	if (pfn >= xen_p2m_size)
+		return P2M_TYPE_IDENTITY;
 
-			p2m_top[topidx] = mid;
-		}
+	mfn = xen_p2m_addr[pfn];
 
-		/*
-		 * As long as the mfn_list has enough entries to completely
-		 * fill a p2m page, pointing into the array is ok. But if
-		 * not the entries beyond the last pfn will be undefined.
-		 */
-		if (unlikely(pfn + P2M_PER_PAGE > max_pfn)) {
-			unsigned long p2midx;
+	if (mfn == INVALID_P2M_ENTRY)
+		return P2M_TYPE_MISSING;
 
-			p2midx = max_pfn % P2M_PER_PAGE;
-			for ( ; p2midx < P2M_PER_PAGE; p2midx++)
-				mfn_list[pfn + p2midx] = INVALID_P2M_ENTRY;
-		}
-		p2m_top[topidx][mididx] = &mfn_list[pfn];
-	}
+	if (mfn & IDENTITY_FRAME_BIT)
+		return P2M_TYPE_IDENTITY;
+
+	return P2M_TYPE_PFN;
 }
-#ifdef CONFIG_X86_64
-unsigned long __init xen_revector_p2m_tree(void)
+
+static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 {
-	unsigned long va_start;
-	unsigned long va_end;
+	unsigned int i, chunk;
 	unsigned long pfn;
-	unsigned long pfn_free = 0;
-	unsigned long *mfn_list = NULL;
-	unsigned long size;
-
-	use_brk = 0;
-	va_start = xen_start_info->mfn_list;
-	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
-	 * so make sure it is rounded up to that */
-	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
-	va_end = va_start + size;
-
-	/* If we were revectored already, don't do it again. */
-	if (va_start <= __START_KERNEL_map && va_start >= __PAGE_OFFSET)
-		return 0;
-
-	mfn_list = alloc_bootmem_align(size, PAGE_SIZE);
-	if (!mfn_list) {
-		pr_warn("Could not allocate space for a new P2M tree!\n");
-		return xen_start_info->mfn_list;
-	}
-	/* Fill it out with INVALID_P2M_ENTRY value */
-	memset(mfn_list, 0xFF, size);
-
-	for (pfn = 0; pfn < ALIGN(MAX_DOMAIN_PAGES, P2M_PER_PAGE); pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx;
-		unsigned long *mid_p;
+	unsigned long *mfns;
+	pte_t *ptep;
+	pmd_t *pmdp;
+	int type;
 
-		if (!p2m_top[topidx])
-			continue;
+	p2m_missing = alloc_p2m_page();
+	p2m_init(p2m_missing);
+	p2m_identity = alloc_p2m_page();
+	p2m_init(p2m_identity);
 
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
+	p2m_missing_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_missing_pte) >> PAGE_SHIFT);
+	p2m_identity_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
+	for (i = 0; i < PTRS_PER_PTE; i++) {
+		set_pte(p2m_missing_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
+		set_pte(p2m_identity_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
+	}
 
-		mididx = p2m_mid_index(pfn);
-		mid_p = p2m_top[topidx][mididx];
-		if (!mid_p)
-			continue;
-		if ((mid_p == p2m_missing) || (mid_p == p2m_identity))
+	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
+		/*
+		 * Try to map missing/identity PMDs or p2m-pages if possible.
+		 * We have to respect the structure of the mfn_list_list
+		 * which will be built a little bit later.
+		 * Chunk size to test is one p2m page if we are in the middle
+		 * of a mfn_list_list mid page and the complete mid page area
+		 * if we are at index 0 of the mid page. Please note that a
+		 * mid page might cover more than one PMD, e.g. on 32 bit PAE
+		 * kernels.
+		 */
+		chunk = (pfn & (P2M_PER_PAGE * P2M_MID_PER_PAGE - 1)) ?
+			P2M_PER_PAGE : P2M_PER_PAGE * P2M_MID_PER_PAGE;
+
+		type = xen_p2m_elem_type(pfn);
+		i = 0;
+		if (type != P2M_TYPE_PFN)
+			for (i = 1; i < chunk; i++)
+				if (xen_p2m_elem_type(pfn + i) != type)
+					break;
+		if (i < chunk)
+			/* Reset to minimal chunk size. */
+			chunk = P2M_PER_PAGE;
+
+		if (type == P2M_TYPE_PFN || i < chunk) {
+			/* Use initial p2m page contents. */
+#ifdef CONFIG_X86_64
+			mfns = alloc_p2m_page();
+			copy_page(mfns, xen_p2m_addr + pfn);
+#else
+			mfns = xen_p2m_addr + pfn;
+#endif
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		if ((unsigned long)mid_p == INVALID_P2M_ENTRY)
+		if (chunk == P2M_PER_PAGE) {
+			/* Map complete missing or identity p2m-page. */
+			mfns = (type == P2M_TYPE_MISSING) ?
+				p2m_missing : p2m_identity;
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		/* The old va. Rebase it on mfn_list */
-		if (mid_p >= (unsigned long *)va_start && mid_p <= (unsigned long *)va_end) {
-			unsigned long *new;
+		/* Complete missing or identity PMD(s) can be mapped. */
+		ptep = (type == P2M_TYPE_MISSING) ?
+			p2m_missing_pte : p2m_identity_pte;
+		for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+			pmdp = populate_extra_pmd(
+				(unsigned long)(p2m + pfn + i * PTRS_PER_PTE));
+			set_pmd(pmdp, __pmd(__pa(ptep) | _KERNPG_TABLE));
+		}
+	}
+}
 
-			if (pfn_free  > (size / sizeof(unsigned long))) {
-				WARN(1, "Only allocated for %ld pages, but we want %ld!\n",
-				     size / sizeof(unsigned long), pfn_free);
-				return 0;
-			}
-			new = &mfn_list[pfn_free];
+void __init xen_vmalloc_p2m_tree(void)
+{
+	static struct vm_struct vm;
 
-			copy_page(new, mid_p);
-			p2m_top[topidx][mididx] = &mfn_list[pfn_free];
+	vm.flags = VM_ALLOC;
+	vm.size = ALIGN(sizeof(unsigned long) * xen_max_p2m_pfn,
+			PMD_SIZE * PMDS_PER_MID_PAGE);
+	vm_area_register_early(&vm, PMD_SIZE * PMDS_PER_MID_PAGE);
+	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);
 
-			pfn_free += P2M_PER_PAGE;
+	xen_max_p2m_pfn = vm.size / sizeof(unsigned long);
 
-		}
-		/* This should be the leafs allocated for identity from _brk. */
-	}
+	xen_rebuild_p2m_list(vm.addr);
 
+	xen_p2m_addr = vm.addr;
 	xen_p2m_size = xen_max_p2m_pfn;
-	xen_p2m_addr = mfn_list;
 
 	xen_inv_extra_mem();
 
 	m2p_override_init();
-	return (unsigned long)mfn_list;
 }
-#else
-unsigned long __init xen_revector_p2m_tree(void)
-{
-	use_brk = 0;
-	xen_p2m_size = xen_max_p2m_pfn;
-	xen_inv_extra_mem();
-	m2p_override_init();
-	return 0;
-}
-#endif
+
 unsigned long get_phys_to_machine(unsigned long pfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	if (unlikely(pfn >= xen_p2m_size)) {
 		if (pfn < xen_max_p2m_pfn)
@@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 		return IDENTITY_FRAME(pfn);
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
 	/*
 	 * The INVALID_P2M_ENTRY is filled in both p2m_*identity
 	 * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
 	 * would be wrong.
 	 */
-	if (p2m_top[topidx][mididx] == p2m_identity)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
 		return IDENTITY_FRAME(pfn);
 
-	return p2m_top[topidx][mididx][idx];
+	return xen_p2m_addr[pfn];
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
 /*
+ * Allocate new pmd(s). It is checked whether the old pmd is still in place.
+ * If not, nothing is changed. This is okay as the only reason for allocating
+ * a new pmd is to replace p2m_missing_pte or p2m_identity_pte by a individual
+ * pmd. In case of PAE/x86-32 there are multiple pmds to allocate!
+ */
+static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t *ptep, pte_t *pte_pg)
+{
+	pte_t *ptechk;
+	pte_t *pteret = ptep;
+	pte_t *pte_newpg[PMDS_PER_MID_PAGE];
+	pmd_t *pmdp;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long vaddr;
+	int i;
+
+	/* Do all allocations first to bail out in error case. */
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		pte_newpg[i] = alloc_p2m_page();
+		if (!pte_newpg[i]) {
+			for (i--; i >= 0; i--)
+				free_p2m_page(pte_newpg[i]);
+
+			return NULL;
+		}
+	}
+
+	vaddr = addr & ~(PMD_SIZE * PMDS_PER_MID_PAGE - 1);
+
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		copy_page(pte_newpg[i], pte_pg);
+		paravirt_alloc_pte(&init_mm, __pa(pte_newpg[i]) >> PAGE_SHIFT);
+
+		pmdp = lookup_pmd_address(vaddr);
+		BUG_ON(!pmdp);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		ptechk = lookup_address(vaddr, &level);
+		if (ptechk == pte_pg) {
+			set_pmd(pmdp,
+				__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+			if (vaddr == (addr & ~(PMD_SIZE - 1)))
+				pteret = pte_offset_kernel(pmdp, addr);
+			pte_newpg[i] = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
+
+		if (pte_newpg[i]) {
+			paravirt_release_pte(__pa(pte_newpg[i]) >> PAGE_SHIFT);
+			free_p2m_page(pte_newpg[i]);
+		}
+
+		vaddr += PMD_SIZE;
+	}
+
+	return pteret;
+}
+
+/*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
  * parallel mfn tree is kept in sync.  We may race with other cpus, so
@@ -552,58 +497,62 @@ EXPORT_SYMBOL_GPL(get_phys_to_machine);
 static bool alloc_p2m(unsigned long pfn)
 {
 	unsigned topidx, mididx;
-	unsigned long ***top_p, **mid;
 	unsigned long *top_mfn_p, *mid_mfn;
-	unsigned long *p2m_orig;
+	pte_t *ptep, *pte_pg;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long addr = (unsigned long)(xen_p2m_addr + pfn);
+	unsigned long p2m_pfn;
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
 
-	top_p = &p2m_top[topidx];
-	mid = ACCESS_ONCE(*top_p);
+	ptep = lookup_address(addr, &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
+	pte_pg = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
-	if (mid == p2m_mid_missing) {
-		/* Mid level is missing, allocate a new one */
-		mid = alloc_p2m_page();
-		if (!mid)
+	if (pte_pg == p2m_missing_pte || pte_pg == p2m_identity_pte) {
+		/* PMD level is missing, allocate a new one */
+		ptep = alloc_p2m_pmd(addr, ptep, pte_pg);
+		if (!ptep)
 			return false;
-
-		p2m_mid_init(mid, p2m_missing);
-
-		if (cmpxchg(top_p, p2m_mid_missing, mid) != p2m_mid_missing)
-			free_p2m_page(mid);
 	}
 
-	top_mfn_p = &p2m_top_mfn[topidx];
-	mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
+	if (p2m_top_mfn) {
+		top_mfn_p = &p2m_top_mfn[topidx];
+		mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
 
-	BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
+		BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
 
-	if (mid_mfn == p2m_mid_missing_mfn) {
-		/* Separately check the mid mfn level */
-		unsigned long missing_mfn;
-		unsigned long mid_mfn_mfn;
-		unsigned long old_mfn;
+		if (mid_mfn == p2m_mid_missing_mfn) {
+			/* Separately check the mid mfn level */
+			unsigned long missing_mfn;
+			unsigned long mid_mfn_mfn;
+			unsigned long old_mfn;
 
-		mid_mfn = alloc_p2m_page();
-		if (!mid_mfn)
-			return false;
+			mid_mfn = alloc_p2m_page();
+			if (!mid_mfn)
+				return false;
 
-		p2m_mid_mfn_init(mid_mfn, p2m_missing);
+			p2m_mid_mfn_init(mid_mfn, p2m_missing);
 
-		missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
-		mid_mfn_mfn = virt_to_mfn(mid_mfn);
-		old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
-		if (old_mfn != missing_mfn) {
-			free_p2m_page(mid_mfn);
-			mid_mfn = mfn_to_virt(old_mfn);
-		} else {
-			p2m_top_mfn_p[topidx] = mid_mfn;
+			missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
+			mid_mfn_mfn = virt_to_mfn(mid_mfn);
+			old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
+			if (old_mfn != missing_mfn) {
+				free_p2m_page(mid_mfn);
+				mid_mfn = mfn_to_virt(old_mfn);
+			} else {
+				p2m_top_mfn_p[topidx] = mid_mfn;
+			}
 		}
+	} else {
+		mid_mfn = NULL;
 	}
 
-	p2m_orig = ACCESS_ONCE(p2m_top[topidx][mididx]);
-	if (p2m_orig == p2m_identity || p2m_orig == p2m_missing) {
+	p2m_pfn = pte_pfn(ACCESS_ONCE(*ptep));
+	if (p2m_pfn == PFN_DOWN(__pa(p2m_identity)) ||
+	    p2m_pfn == PFN_DOWN(__pa(p2m_missing))) {
 		/* p2m leaf page is missing */
 		unsigned long *p2m;
 
@@ -611,12 +560,25 @@ static bool alloc_p2m(unsigned long pfn)
 		if (!p2m)
 			return false;
 
-		p2m_init(p2m);
+		if (p2m_pfn == PFN_DOWN(__pa(p2m_missing)))
+			p2m_init(p2m);
+		else
+			p2m_init_identity(p2m, pfn);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		if (pte_pfn(*ptep) == p2m_pfn) {
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(p2m)), PAGE_KERNEL));
+			if (mid_mfn)
+				mid_mfn[mididx] = virt_to_mfn(p2m);
+			p2m = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
 
-		if (cmpxchg(&mid[mididx], p2m_orig, p2m) != p2m_orig)
+		if (p2m)
 			free_p2m_page(p2m);
-		else
-			mid_mfn[mididx] = virt_to_mfn(p2m);
 	}
 
 	return true;
@@ -645,10 +607,10 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	return pfn - pfn_s;
 }
 
-/* Try to install p2m mapping; fail if intermediate bits missing */
 bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	/* don't track P2M changes in autotranslate guests */
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -659,55 +621,27 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* For sparse holes were the p2m leaf has real PFN along with
-	 * PCI holes, stick in the PFN as the MFN value.
-	 *
-	 * set_phys_range_identity() will have allocated new middle
-	 * and leaf pages as required so an existing p2m_mid_missing
-	 * or p2m_missing mean that whole range will be identity so
-	 * these can be switched to p2m_mid_identity or p2m_identity.
-	 */
-	if (mfn != INVALID_P2M_ENTRY && (mfn & IDENTITY_FRAME_BIT)) {
-		if (p2m_top[topidx] == p2m_mid_identity)
-			return true;
-
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx], p2m_mid_missing,
-					p2m_mid_identity) != p2m_mid_missing);
-			return true;
-		}
-
-		if (p2m_top[topidx][mididx] == p2m_identity)
-			return true;
-
-		/* Swap over from MISSING to IDENTITY if needed. */
-		if (p2m_top[topidx][mididx] == p2m_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx][mididx], p2m_missing,
-				p2m_identity) != p2m_missing);
-			return true;
-		}
-	}
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
-	if (p2m_top[topidx][mididx] == p2m_missing)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_missing)))
 		return mfn == INVALID_P2M_ENTRY;
 
-	p2m_top[topidx][mididx][idx] = mfn;
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
+		return mfn == IDENTITY_FRAME(pfn);
+
+	xen_p2m_addr[pfn] = mfn;
 
 	return true;
 }
 
 bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
+	if (unlikely(!__set_phys_to_machine(pfn, mfn))) {
 		if (!alloc_p2m(pfn))
 			return false;
 
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
+		return __set_phys_to_machine(pfn, mfn);
 	}
 
 	return true;
@@ -1033,79 +967,29 @@ EXPORT_SYMBOL_GPL(m2p_find_override_pfn);
 #include "debugfs.h"
 static int p2m_dump_show(struct seq_file *m, void *v)
 {
-	static const char * const level_name[] = { "top", "middle",
-						"entry", "abnormal", "error"};
-#define TYPE_IDENTITY 0
-#define TYPE_MISSING 1
-#define TYPE_PFN 2
-#define TYPE_UNKNOWN 3
 	static const char * const type_name[] = {
-				[TYPE_IDENTITY] = "identity",
-				[TYPE_MISSING] = "missing",
-				[TYPE_PFN] = "pfn",
-				[TYPE_UNKNOWN] = "abnormal"};
-	unsigned long pfn, prev_pfn_type = 0, prev_pfn_level = 0;
-	unsigned int uninitialized_var(prev_level);
-	unsigned int uninitialized_var(prev_type);
-
-	if (!p2m_top)
-		return 0;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn++) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned idx = p2m_index(pfn);
-		unsigned lvl, type;
-
-		lvl = 4;
-		type = TYPE_UNKNOWN;
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			lvl = 0; type = TYPE_MISSING;
-		} else if (p2m_top[topidx] == NULL) {
-			lvl = 0; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == NULL) {
-			lvl = 1; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == p2m_identity) {
-			lvl = 1; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx] == p2m_missing) {
-			lvl = 1; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == 0) {
-			lvl = 2; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx][idx] == IDENTITY_FRAME(pfn)) {
-			lvl = 2; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx][idx] == INVALID_P2M_ENTRY) {
-			lvl = 2; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == pfn) {
-			lvl = 2; type = TYPE_PFN;
-		} else if (p2m_top[topidx][mididx][idx] != pfn) {
-			lvl = 2; type = TYPE_PFN;
-		}
-		if (pfn == 0) {
-			prev_level = lvl;
+				[P2M_TYPE_IDENTITY] = "identity",
+				[P2M_TYPE_MISSING] = "missing",
+				[P2M_TYPE_PFN] = "pfn",
+				[P2M_TYPE_UNKNOWN] = "abnormal"};
+	unsigned long pfn, first_pfn;
+	int type, prev_type;
+
+	prev_type = xen_p2m_elem_type(0);
+	first_pfn = 0;
+
+	for (pfn = 0; pfn < xen_p2m_size; pfn++) {
+		type = xen_p2m_elem_type(pfn);
+		if (type != prev_type) {
+			seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+				   type_name[prev_type]);
 			prev_type = type;
-		}
-		if (pfn == MAX_DOMAIN_PAGES-1) {
-			lvl = 3;
-			type = TYPE_UNKNOWN;
-		}
-		if (prev_type != type) {
-			seq_printf(m, " [0x%lx->0x%lx] %s\n",
-				prev_pfn_type, pfn, type_name[prev_type]);
-			prev_pfn_type = pfn;
-			prev_type = type;
-		}
-		if (prev_level != lvl) {
-			seq_printf(m, " [0x%lx->0x%lx] level %s\n",
-				prev_pfn_level, pfn, level_name[prev_level]);
-			prev_pfn_level = pfn;
-			prev_level = lvl;
+			first_pfn = pfn;
 		}
 	}
+	seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+		   type_name[prev_type]);
 	return 0;
-#undef TYPE_IDENTITY
-#undef TYPE_MISSING
-#undef TYPE_PFN
-#undef TYPE_UNKNOWN
 }
 
 static int p2m_dump_open(struct inode *inode, struct file *filp)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 02b0b0f..f92921f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -49,7 +49,7 @@ void xen_hvm_init_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-unsigned long __init xen_revector_p2m_tree(void);
+void __init xen_vmalloc_p2m_tree(void);
 
 void xen_init_irq_ops(void);
 void xen_setup_timer(int cpu);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FJ-0001bs-Pf; Tue, 11 Nov 2014 05:44:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FF-0001aM-Md
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	55/AE-09842-022A1645; Tue, 11 Nov 2014 05:44:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415684638!12817143!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14105 invoked from network); 11 Nov 2014 05:43:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:59 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B1080ACA0;
	Tue, 11 Nov 2014 05:43:58 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:42 +0100
Message-Id: <1415684626-18590-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 4/8] xen: Delay invalidating extra memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When the physical memory configuration is initialized the p2m entries
for not pouplated memory pages are set to "invalid". As those pages
are beyond the hypervisor built p2m list the p2m tree has to be
extended.

This patch delays processing the extra memory related p2m entries
during the boot process until some more basic memory management
functions are callable. This removes the need to create new p2m
entries until virtual memory management is available.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/xen/page.h |   3 +
 arch/x86/xen/p2m.c              | 130 ++++++++--------------------------------
 arch/x86/xen/setup.c            | 103 ++++++++++++++++++++++---------
 arch/x86/xen/xen-ops.h          |   3 +-
 4 files changed, 107 insertions(+), 132 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index b475297..28fa795 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -41,6 +41,9 @@ typedef struct xpaddr {
 
 extern unsigned long *machine_to_phys_mapping;
 extern unsigned long  machine_to_phys_nr;
+extern unsigned long *xen_p2m_addr;
+extern unsigned long  xen_p2m_size;
+extern unsigned long  xen_max_p2m_pfn;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 97252e3..6a9dfa6 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -181,7 +181,12 @@
 
 static void __init m2p_override_init(void);
 
+unsigned long *xen_p2m_addr __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_addr);
+unsigned long xen_p2m_size __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
+EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
@@ -198,13 +203,6 @@ static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
 
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
 
-/* For each I/O range remapped we may lose up to two leaf pages for the boundary
- * violations and three mid pages to cover up to 3GB. With
- * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
- * remapped region.
- */
-RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
-
 static int use_brk = 1;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
@@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	unsigned long max_pfn;
 	unsigned long pfn;
 
-	 if (xen_feature(XENFEAT_auto_translated_physmap))
+	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
+	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
 	mfn_list = (unsigned long *)xen_start_info->mfn_list;
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
+	xen_p2m_size = max_pfn;
 
 	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
@@ -497,6 +497,11 @@ unsigned long __init xen_revector_p2m_tree(void)
 		/* This should be the leafs allocated for identity from _brk. */
 	}
 
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_p2m_addr = mfn_list;
+
+	xen_inv_extra_mem();
+
 	m2p_override_init();
 	return (unsigned long)mfn_list;
 }
@@ -504,6 +509,8 @@ unsigned long __init xen_revector_p2m_tree(void)
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_inv_extra_mem();
 	m2p_override_init();
 	return 0;
 }
@@ -512,8 +519,12 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(pfn >= MAX_P2M_PFN))
+	if (unlikely(pfn >= xen_p2m_size)) {
+		if (pfn < xen_max_p2m_pfn)
+			return xen_chk_extra_mem(pfn);
+
 		return IDENTITY_FRAME(pfn);
+	}
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
@@ -611,78 +622,12 @@ static bool alloc_p2m(unsigned long pfn)
 	return true;
 }
 
-static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
-{
-	unsigned topidx, mididx, idx;
-	unsigned long *p2m;
-
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* Pfff.. No boundary cross-over, lets get out. */
-	if (!idx && check_boundary)
-		return false;
-
-	WARN(p2m_top[topidx][mididx] == p2m_identity,
-		"P2M[%d][%d] == IDENTITY, should be MISSING (or alloced)!\n",
-		topidx, mididx);
-
-	/*
-	 * Could be done by xen_build_dynamic_phys_to_machine..
-	 */
-	if (p2m_top[topidx][mididx] != p2m_missing)
-		return false;
-
-	/* Boundary cross-over for the edges: */
-	p2m = alloc_p2m_page();
-
-	p2m_init(p2m);
-
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-
-static bool __init early_alloc_p2m_middle(unsigned long pfn)
-{
-	unsigned topidx = p2m_top_index(pfn);
-	unsigned long **mid;
-
-	mid = p2m_top[topidx];
-	if (mid == p2m_mid_missing) {
-		mid = alloc_p2m_page();
-
-		p2m_mid_init(mid, p2m_missing);
-
-		p2m_top[topidx] = mid;
-	}
-	return true;
-}
-
-static void __init early_split_p2m(unsigned long pfn)
-{
-	unsigned long mididx, idx;
-
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/*
-	 * Allocate new middle and leaf pages if this pfn lies in the
-	 * middle of one.
-	 */
-	if (mididx || idx)
-		early_alloc_p2m_middle(pfn);
-	if (idx)
-		early_alloc_p2m(pfn, false);
-}
-
 unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 				      unsigned long pfn_e)
 {
 	unsigned long pfn;
 
-	if (unlikely(pfn_s >= MAX_P2M_PFN))
+	if (unlikely(pfn_s >= xen_p2m_size))
 		return 0;
 
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -691,34 +636,11 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	if (pfn_s > pfn_e)
 		return 0;
 
-	if (pfn_e > MAX_P2M_PFN)
-		pfn_e = MAX_P2M_PFN;
-
-	early_split_p2m(pfn_s);
-	early_split_p2m(pfn_e);
-
-	for (pfn = pfn_s; pfn < pfn_e;) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-
-		if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
-			break;
-		pfn++;
-
-		/*
-		 * If the PFN was set to a middle or leaf identity
-		 * page the remainder must also be identity, so skip
-		 * ahead to the next middle or leaf entry.
-		 */
-		if (p2m_top[topidx] == p2m_mid_identity)
-			pfn = ALIGN(pfn, P2M_MID_PER_PAGE * P2M_PER_PAGE);
-		else if (p2m_top[topidx][mididx] == p2m_identity)
-			pfn = ALIGN(pfn, P2M_PER_PAGE);
-	}
+	if (pfn_e > xen_p2m_size)
+		pfn_e = xen_p2m_size;
 
-	WARN((pfn - pfn_s) != (pfn_e - pfn_s),
-		"Identity mapping failed. We are %ld short of 1-1 mappings!\n",
-		(pfn_e - pfn_s) - (pfn - pfn_s));
+	for (pfn = pfn_s; pfn < pfn_e; pfn++)
+		xen_p2m_addr[pfn] = IDENTITY_FRAME(pfn);
 
 	return pfn - pfn_s;
 }
@@ -732,7 +654,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
 		return true;
 
-	if (unlikely(pfn >= MAX_P2M_PFN)) {
+	if (unlikely(pfn >= xen_p2m_size)) {
 		BUG_ON(mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 0e5f9b6..8d5985b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -75,7 +75,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 static void __init xen_add_extra_mem(u64 start, u64 size)
 {
-	unsigned long pfn;
 	int i;
 
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
@@ -95,17 +94,74 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
 
 	memblock_reserve(start, size);
+}
 
-	xen_max_p2m_pfn = PFN_DOWN(start + size);
-	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
-		unsigned long mfn = pfn_to_mfn(pfn);
+static void __init xen_del_extra_mem(u64 start, u64 size)
+{
+	int i;
+	u64 start_r, size_r;
 
-		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
-			continue;
-		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
-			  pfn, mfn);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		start_r = xen_extra_mem[i].start;
+		size_r = xen_extra_mem[i].size;
+
+		/* Start of region. */
+		if (start_r == start) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].start += size;
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* End of region. */
+		if (start_r + size_r == start + size) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* Mid of region. */
+		if (start > start_r && start < start_r + size_r) {
+			BUG_ON(start + size > start_r + size_r);
+			xen_extra_mem[i].size = start - start_r;
+			xen_add_extra_mem(start + size, start_r + size_r -
+					  (start + size));
+			break;
+		}
+	}
+	memblock_free(start, size);
+}
+
+/*
+ * Called during boot before the p2m list can take entries beyond the
+ * hypervisor supplied p2m list. Entries in extra mem are to be regarded as
+ * invalid.
+ */
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
+{
+	int i;
+	unsigned long addr = PFN_PHYS(pfn);
 
-		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		if (addr >= xen_extra_mem[i].start &&
+		    addr < xen_extra_mem[i].start + xen_extra_mem[i].size)
+			return INVALID_P2M_ENTRY;
+	}
+
+	return IDENTITY_FRAME(pfn);
+}
+
+/*
+ * Mark all pfns of extra mem as invalid in p2m list.
+ */
+void __init xen_inv_extra_mem(void)
+{
+	unsigned long pfn, pfn_s, pfn_e;
+	int i;
+
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		pfn_s = PFN_DOWN(xen_extra_mem[i].start);
+		pfn_e = PFN_UP(xen_extra_mem[i].start + xen_extra_mem[i].size);
+		for (pfn = pfn_s; pfn < pfn_e; pfn++)
+			set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 	}
 }
 
@@ -269,9 +325,6 @@ static void __init xen_do_set_identity_and_remap_chunk(
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/* Don't use memory until remapped */
-	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
-
 	mfn_save = virt_to_mfn(buf);
 
 	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
@@ -315,7 +368,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
  * pages. In the case of an error the underlying memory is simply released back
  * to Xen and not remapped.
  */
-static unsigned long __init xen_set_identity_and_remap_chunk(
+static unsigned long xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
 	unsigned long *identity, unsigned long *released)
@@ -372,7 +425,7 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 	return remap_pfn;
 }
 
-static unsigned long __init xen_set_identity_and_remap(
+static void __init xen_set_identity_and_remap(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages,
 	unsigned long *released)
 {
@@ -416,8 +469,6 @@ static unsigned long __init xen_set_identity_and_remap(
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
 	pr_info("Released %ld page(s)\n", num_released);
-
-	return last_pfn;
 }
 
 /*
@@ -449,8 +500,9 @@ void __init xen_remap_memory(void)
 			} else {
 				if (!released) {
 					if (pfn_s != ~0UL && len)
-						memblock_free(PFN_PHYS(pfn_s),
-							      PFN_PHYS(len));
+						xen_del_extra_mem(
+							PFN_PHYS(pfn_s),
+							PFN_PHYS(len));
 					pfn_s = xen_remap_buf.target_pfn;
 					len = i;
 				}
@@ -470,7 +522,8 @@ void __init xen_remap_memory(void)
 			} else if (pfn_s + len == xen_remap_buf.target_pfn) {
 				len += xen_remap_buf.size;
 			} else {
-				memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+				xen_del_extra_mem(PFN_PHYS(pfn_s),
+						  PFN_PHYS(len));
 				pfn_s = xen_remap_buf.target_pfn;
 				len = xen_remap_buf.size;
 			}
@@ -484,7 +537,7 @@ void __init xen_remap_memory(void)
 	}
 
 	if (pfn_s != ~0UL && len)
-		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+		xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
 
 	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 
@@ -553,7 +606,6 @@ char * __init xen_memory_setup(void)
 	int rc;
 	struct xen_memory_map memmap;
 	unsigned long max_pages;
-	unsigned long last_pfn = 0;
 	unsigned long extra_pages = 0;
 	int i;
 	int op;
@@ -603,15 +655,11 @@ char * __init xen_memory_setup(void)
 	 * Set identity map on non-RAM pages and prepare remapping the
 	 * underlying RAM.
 	 */
-	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
-					      &xen_released_pages);
+	xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
+				   &xen_released_pages);
 
 	extra_pages += xen_released_pages;
 
-	if (last_pfn > max_pfn) {
-		max_pfn = min(MAX_DOMAIN_PAGES, last_pfn);
-		mem_end = PFN_PHYS(max_pfn);
-	}
 	/*
 	 * Clamp the amount of extra memory to a EXTRA_MEM_RATIO
 	 * factor the base size.  On non-highmem systems, the base
@@ -638,6 +686,7 @@ char * __init xen_memory_setup(void)
 				size = min(size, (u64)extra_pages * PAGE_SIZE);
 				extra_pages -= size / PAGE_SIZE;
 				xen_add_extra_mem(addr, size);
+				xen_max_p2m_pfn = PFN_DOWN(addr + size);
 			} else
 				type = E820_UNUSABLE;
 		}
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 5b72a06..02b0b0f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -29,12 +29,13 @@ void xen_build_mfn_list_list(void);
 void xen_setup_machphys_mapping(void);
 void xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn);
 void xen_reserve_top(void);
-extern unsigned long xen_max_p2m_pfn;
 
 void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn);
+void __init xen_inv_extra_mem(void);
 void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FH-0001b4-Q3; Tue, 11 Nov 2014 05:44:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FE-0001aG-FU
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:00 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	A7/10-02698-F12A1645; Tue, 11 Nov 2014 05:43:59 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415684638!7989166!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10614 invoked from network); 11 Nov 2014 05:43:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:58 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A5AF5AB07;
	Tue, 11 Nov 2014 05:43:57 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:39 +0100
Message-Id: <1415684626-18590-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 1/8] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some functions in arch/x86/xen/p2m.c are used locally only. Make them
static. Rearrange the functions in p2m.c to avoid forward declarations.

While at it correct some style issues (long lines, use pr_warn()).

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |   6 -
 arch/x86/xen/p2m.c              | 347 ++++++++++++++++++++--------------------
 2 files changed, 172 insertions(+), 181 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c949923..6c16451 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -52,15 +52,9 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 				   struct gnttab_map_grant_ref *kmap_ops,
 				   struct page **pages, unsigned int count);
-extern int m2p_add_override(unsigned long mfn, struct page *page,
-			    struct gnttab_map_grant_ref *kmap_op);
 extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct gnttab_map_grant_ref *kmap_ops,
 				     struct page **pages, unsigned int count);
-extern int m2p_remove_override(struct page *page,
-			       struct gnttab_map_grant_ref *kmap_op,
-			       unsigned long mfn);
-extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 9201a38..fa75842 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -896,6 +896,61 @@ static unsigned long mfn_hash(unsigned long mfn)
 	return hash_long(mfn, M2P_OVERRIDE_HASH_SHIFT);
 }
 
+/* Add an MFN override for a particular page */
+static int m2p_add_override(unsigned long mfn, struct page *page,
+			    struct gnttab_map_grant_ref *kmap_op)
+{
+	unsigned long flags;
+	unsigned long pfn;
+	unsigned long uninitialized_var(address);
+	unsigned level;
+	pte_t *ptep = NULL;
+
+	pfn = page_to_pfn(page);
+	if (!PageHighMem(page)) {
+		address = (unsigned long)__va(pfn << PAGE_SHIFT);
+		ptep = lookup_address(address, &level);
+		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
+			 "m2p_add_override: pfn %lx not mapped", pfn))
+			return -EINVAL;
+	}
+
+	if (kmap_op != NULL) {
+		if (!PageHighMem(page)) {
+			struct multicall_space mcs =
+				xen_mc_entry(sizeof(*kmap_op));
+
+			MULTI_grant_table_op(mcs.mc,
+					GNTTABOP_map_grant_ref, kmap_op, 1);
+
+			xen_mc_issue(PARAVIRT_LAZY_MMU);
+		}
+	}
+	spin_lock_irqsave(&m2p_override_lock, flags);
+	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	/* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in
+	 * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other
+	 * pfn so that the following mfn_to_pfn(mfn) calls will return the
+	 * pfn from the m2p_override (the backend pfn) instead.
+	 * We need to do this because the pages shared by the frontend
+	 * (xen-blkfront) can be already locked (lock_page, called by
+	 * do_read_cache_page); when the userspace backend tries to use them
+	 * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
+	 * do_blockdev_direct_IO is going to try to lock the same pages
+	 * again resulting in a deadlock.
+	 * As a side effect get_user_pages_fast might not be safe on the
+	 * frontend pages while they are being shared with the backend,
+	 * because mfn_to_pfn (that ends up being called by GUPF) will
+	 * return the backend pfn rather than the frontend pfn. */
+	pfn = mfn_to_pfn_no_overrides(mfn);
+	if (get_phys_to_machine(pfn) == mfn)
+		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
+
+	return 0;
+}
+
 int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 			    struct gnttab_map_grant_ref *kmap_ops,
 			    struct page **pages, unsigned int count)
@@ -955,61 +1010,123 @@ out:
 }
 EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
 
-/* Add an MFN override for a particular page */
-int m2p_add_override(unsigned long mfn, struct page *page,
-		struct gnttab_map_grant_ref *kmap_op)
-{
-	unsigned long flags;
-	unsigned long pfn;
-	unsigned long uninitialized_var(address);
-	unsigned level;
-	pte_t *ptep = NULL;
-
-	pfn = page_to_pfn(page);
-	if (!PageHighMem(page)) {
-		address = (unsigned long)__va(pfn << PAGE_SHIFT);
-		ptep = lookup_address(address, &level);
-		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-					"m2p_add_override: pfn %lx not mapped", pfn))
-			return -EINVAL;
-	}
-
-	if (kmap_op != NULL) {
-		if (!PageHighMem(page)) {
-			struct multicall_space mcs =
-				xen_mc_entry(sizeof(*kmap_op));
-
-			MULTI_grant_table_op(mcs.mc,
-					GNTTABOP_map_grant_ref, kmap_op, 1);
-
-			xen_mc_issue(PARAVIRT_LAZY_MMU);
-		}
-	}
-	spin_lock_irqsave(&m2p_override_lock, flags);
-	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	/* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in
-	 * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other
-	 * pfn so that the following mfn_to_pfn(mfn) calls will return the
-	 * pfn from the m2p_override (the backend pfn) instead.
-	 * We need to do this because the pages shared by the frontend
-	 * (xen-blkfront) can be already locked (lock_page, called by
-	 * do_read_cache_page); when the userspace backend tries to use them
-	 * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
-	 * do_blockdev_direct_IO is going to try to lock the same pages
-	 * again resulting in a deadlock.
-	 * As a side effect get_user_pages_fast might not be safe on the
-	 * frontend pages while they are being shared with the backend,
-	 * because mfn_to_pfn (that ends up being called by GUPF) will
-	 * return the backend pfn rather than the frontend pfn. */
-	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == mfn)
-		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(m2p_add_override);
+static struct page *m2p_find_override(unsigned long mfn)
+{
+	unsigned long flags;
+	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
+	struct page *p, *ret;
+
+	ret = NULL;
+
+	spin_lock_irqsave(&m2p_override_lock, flags);
+
+	list_for_each_entry(p, bucket, lru) {
+		if (page_private(p) == mfn) {
+			ret = p;
+			break;
+		}
+	}
+
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	return ret;
+}
+
+static int m2p_remove_override(struct page *page,
+			       struct gnttab_map_grant_ref *kmap_op,
+			       unsigned long mfn)
+{
+	unsigned long flags;
+	unsigned long pfn;
+	unsigned long uninitialized_var(address);
+	unsigned level;
+	pte_t *ptep = NULL;
+
+	pfn = page_to_pfn(page);
+
+	if (!PageHighMem(page)) {
+		address = (unsigned long)__va(pfn << PAGE_SHIFT);
+		ptep = lookup_address(address, &level);
+
+		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
+			 "m2p_remove_override: pfn %lx not mapped", pfn))
+			return -EINVAL;
+	}
+
+	spin_lock_irqsave(&m2p_override_lock, flags);
+	list_del(&page->lru);
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	if (kmap_op != NULL) {
+		if (!PageHighMem(page)) {
+			struct multicall_space mcs;
+			struct gnttab_unmap_and_replace *unmap_op;
+			struct page *scratch_page = get_balloon_scratch_page();
+			unsigned long scratch_page_address = (unsigned long)
+				__va(page_to_pfn(scratch_page) << PAGE_SHIFT);
+
+			/*
+			 * It might be that we queued all the m2p grant table
+			 * hypercalls in a multicall, then m2p_remove_override
+			 * get called before the multicall has actually been
+			 * issued. In this case handle is going to -1 because
+			 * it hasn't been modified yet.
+			 */
+			if (kmap_op->handle == -1)
+				xen_mc_flush();
+			/*
+			 * Now if kmap_op->handle is negative it means that the
+			 * hypercall actually returned an error.
+			 */
+			if (kmap_op->handle == GNTST_general_error) {
+				pr_warn("m2p_remove_override: pfn %lx mfn %lx, failed to modify kernel mappings",
+					pfn, mfn);
+				put_balloon_scratch_page();
+				return -1;
+			}
+
+			xen_mc_batch();
+
+			mcs = __xen_mc_entry(
+				sizeof(struct gnttab_unmap_and_replace));
+			unmap_op = mcs.args;
+			unmap_op->host_addr = kmap_op->host_addr;
+			unmap_op->new_addr = scratch_page_address;
+			unmap_op->handle = kmap_op->handle;
+
+			MULTI_grant_table_op(mcs.mc,
+				GNTTABOP_unmap_and_replace, unmap_op, 1);
+
+			mcs = __xen_mc_entry(0);
+			MULTI_update_va_mapping(mcs.mc, scratch_page_address,
+					pfn_pte(page_to_pfn(scratch_page),
+					PAGE_KERNEL_RO), 0);
+
+			xen_mc_issue(PARAVIRT_LAZY_MMU);
+
+			kmap_op->host_addr = 0;
+			put_balloon_scratch_page();
+		}
+	}
+
+	/* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present
+	 * somewhere in this domain, even before being added to the
+	 * m2p_override (see comment above in m2p_add_override).
+	 * If there are no other entries in the m2p_override corresponding
+	 * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for
+	 * the original pfn (the one shared by the frontend): the backend
+	 * cannot do any IO on this page anymore because it has been
+	 * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of
+	 * the original pfn causes mfn_to_pfn(mfn) to return the frontend
+	 * pfn again. */
+	mfn &= ~FOREIGN_FRAME_BIT;
+	pfn = mfn_to_pfn_no_overrides(mfn);
+	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
+			m2p_find_override(mfn) == NULL)
+		set_phys_to_machine(pfn, mfn);
+
+	return 0;
+}
 
 int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 			      struct gnttab_map_grant_ref *kmap_ops,
@@ -1055,126 +1172,6 @@ out:
 }
 EXPORT_SYMBOL_GPL(clear_foreign_p2m_mapping);
 
-int m2p_remove_override(struct page *page,
-			struct gnttab_map_grant_ref *kmap_op,
-			unsigned long mfn)
-{
-	unsigned long flags;
-	unsigned long pfn;
-	unsigned long uninitialized_var(address);
-	unsigned level;
-	pte_t *ptep = NULL;
-
-	pfn = page_to_pfn(page);
-
-	if (!PageHighMem(page)) {
-		address = (unsigned long)__va(pfn << PAGE_SHIFT);
-		ptep = lookup_address(address, &level);
-
-		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-					"m2p_remove_override: pfn %lx not mapped", pfn))
-			return -EINVAL;
-	}
-
-	spin_lock_irqsave(&m2p_override_lock, flags);
-	list_del(&page->lru);
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	if (kmap_op != NULL) {
-		if (!PageHighMem(page)) {
-			struct multicall_space mcs;
-			struct gnttab_unmap_and_replace *unmap_op;
-			struct page *scratch_page = get_balloon_scratch_page();
-			unsigned long scratch_page_address = (unsigned long)
-				__va(page_to_pfn(scratch_page) << PAGE_SHIFT);
-
-			/*
-			 * It might be that we queued all the m2p grant table
-			 * hypercalls in a multicall, then m2p_remove_override
-			 * get called before the multicall has actually been
-			 * issued. In this case handle is going to -1 because
-			 * it hasn't been modified yet.
-			 */
-			if (kmap_op->handle == -1)
-				xen_mc_flush();
-			/*
-			 * Now if kmap_op->handle is negative it means that the
-			 * hypercall actually returned an error.
-			 */
-			if (kmap_op->handle == GNTST_general_error) {
-				printk(KERN_WARNING "m2p_remove_override: "
-						"pfn %lx mfn %lx, failed to modify kernel mappings",
-						pfn, mfn);
-				put_balloon_scratch_page();
-				return -1;
-			}
-
-			xen_mc_batch();
-
-			mcs = __xen_mc_entry(
-					sizeof(struct gnttab_unmap_and_replace));
-			unmap_op = mcs.args;
-			unmap_op->host_addr = kmap_op->host_addr;
-			unmap_op->new_addr = scratch_page_address;
-			unmap_op->handle = kmap_op->handle;
-
-			MULTI_grant_table_op(mcs.mc,
-					GNTTABOP_unmap_and_replace, unmap_op, 1);
-
-			mcs = __xen_mc_entry(0);
-			MULTI_update_va_mapping(mcs.mc, scratch_page_address,
-					pfn_pte(page_to_pfn(scratch_page),
-					PAGE_KERNEL_RO), 0);
-
-			xen_mc_issue(PARAVIRT_LAZY_MMU);
-
-			kmap_op->host_addr = 0;
-			put_balloon_scratch_page();
-		}
-	}
-
-	/* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present
-	 * somewhere in this domain, even before being added to the
-	 * m2p_override (see comment above in m2p_add_override).
-	 * If there are no other entries in the m2p_override corresponding
-	 * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for
-	 * the original pfn (the one shared by the frontend): the backend
-	 * cannot do any IO on this page anymore because it has been
-	 * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of
-	 * the original pfn causes mfn_to_pfn(mfn) to return the frontend
-	 * pfn again. */
-	mfn &= ~FOREIGN_FRAME_BIT;
-	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
-			m2p_find_override(mfn) == NULL)
-		set_phys_to_machine(pfn, mfn);
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(m2p_remove_override);
-
-struct page *m2p_find_override(unsigned long mfn)
-{
-	unsigned long flags;
-	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
-	struct page *p, *ret;
-
-	ret = NULL;
-
-	spin_lock_irqsave(&m2p_override_lock, flags);
-
-	list_for_each_entry(p, bucket, lru) {
-		if (page_private(p) == mfn) {
-			ret = p;
-			break;
-		}
-	}
-
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	return ret;
-}
-
 unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
 {
 	struct page *p = m2p_find_override(mfn);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FI-0001bL-Gf; Tue, 11 Nov 2014 05:44:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FF-0001aX-Lt
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	26/47-24532-022A1645; Tue, 11 Nov 2014 05:44:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415684639!12876546!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30037 invoked from network); 11 Nov 2014 05:43:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:59 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 5A011ACDE;
	Tue, 11 Nov 2014 05:43:59 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:44 +0100
Message-Id: <1415684626-18590-7-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 6/8] xen: Hide get_phys_to_machine() to be
	able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 get_phys_to_machine() is always called when the mfn for a pfn
is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
to be able to avoid calling get_phys_to_machine() when possible as
soon as the switch to a linear mapped p2m list has been done.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h | 27 +++++++++++++++++++++------
 arch/x86/xen/mmu.c              |  2 +-
 arch/x86/xen/p2m.c              |  6 +++---
 3 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 28fa795..07d8a7b 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -59,6 +59,22 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct page **pages, unsigned int count);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
+/*
+ * When to use pfn_to_mfn(), __pfn_to_mfn() or get_phys_to_machine():
+ * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. In case of an
+ *   identity entry the identity indicator will be cleared.
+ * - __pfn_to_mfn() returns the found entry of the p2m table. A possibly set
+ *   identity indicator will be still set. __pfn_to_mfn() is encapsulating
+ *   get_phys_to_machine() and might skip that function if possible to speed
+ *   up the common path.
+ * - get_phys_to_machine() is basically the same as __pfn_to_mfn(), but
+ *   without any short cuts for the common fast path.
+ */
+static inline unsigned long __pfn_to_mfn(unsigned long pfn)
+{
+	return get_phys_to_machine(pfn);
+}
+
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
 {
 	unsigned long mfn;
@@ -66,7 +82,7 @@ static inline unsigned long pfn_to_mfn(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return pfn;
 
-	mfn = get_phys_to_machine(pfn);
+	mfn = __pfn_to_mfn(pfn);
 
 	if (mfn != INVALID_P2M_ENTRY)
 		mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
@@ -79,7 +95,7 @@ static inline int phys_to_machine_mapping_valid(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return 1;
 
-	return get_phys_to_machine(pfn) != INVALID_P2M_ENTRY;
+	return __pfn_to_mfn(pfn) != INVALID_P2M_ENTRY;
 }
 
 static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
@@ -113,7 +129,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) != mfn) {
+	if (__pfn_to_mfn(pfn) != mfn) {
 		/*
 		 * If this appears to be a foreign mfn (because the pfn
 		 * doesn't map back to the mfn), then check the local override
@@ -129,8 +145,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 	 * entry doesn't map back to the mfn and m2p_override doesn't have a
 	 * valid entry for it.
 	 */
-	if (pfn == ~0 &&
-			get_phys_to_machine(mfn) == IDENTITY_FRAME(mfn))
+	if (pfn == ~0 && __pfn_to_mfn(mfn) == IDENTITY_FRAME(mfn))
 		pfn = mfn;
 
 	return pfn;
@@ -176,7 +191,7 @@ static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn(mfn);
-	if (get_phys_to_machine(pfn) != mfn)
+	if (__pfn_to_mfn(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
 }
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d3e492b..31ca515 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -387,7 +387,7 @@ static pteval_t pte_pfn_to_mfn(pteval_t val)
 		unsigned long mfn;
 
 		if (!xen_feature(XENFEAT_auto_translated_physmap))
-			mfn = get_phys_to_machine(pfn);
+			mfn = __pfn_to_mfn(pfn);
 		else
 			mfn = pfn;
 		/*
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 6a9dfa6..328875a 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -785,7 +785,7 @@ static int m2p_add_override(unsigned long mfn, struct page *page,
 	 * because mfn_to_pfn (that ends up being called by GUPF) will
 	 * return the backend pfn rather than the frontend pfn. */
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == mfn)
+	if (__pfn_to_mfn(pfn) == mfn)
 		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
 
 	return 0;
@@ -965,7 +965,7 @@ static int m2p_remove_override(struct page *page,
 	 * pfn again. */
 	mfn &= ~FOREIGN_FRAME_BIT;
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
+	if (__pfn_to_mfn(pfn) == FOREIGN_FRAME(mfn) &&
 			m2p_find_override(mfn) == NULL)
 		set_phys_to_machine(pfn, mfn);
 
@@ -990,7 +990,7 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 	}
 
 	for (i = 0; i < count; i++) {
-		unsigned long mfn = get_phys_to_machine(page_to_pfn(pages[i]));
+		unsigned long mfn = __pfn_to_mfn(page_to_pfn(pages[i]));
 		unsigned long pfn = page_to_pfn(pages[i]);
 
 		if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FI-0001bE-4x; Tue, 11 Nov 2014 05:44:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FE-0001aL-P3
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E5/47-24532-022A1645; Tue, 11 Nov 2014 05:44:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415684638!12836176!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29492 invoked from network); 11 Nov 2014 05:43:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:58 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 014C2ABC6;
	Tue, 11 Nov 2014 05:43:58 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:40 +0100
Message-Id: <1415684626-18590-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of pv-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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Early in the boot process the memory layout of a pv-domain is changed
to match the E820 map (either the host one for Dom0 or the Xen one)
regarding placement of RAM and PCI holes. This requires removing memory
pages initially located at positions not suitable for RAM and adding
them later at higher addresses where no restrictions apply.

To be able to operate on the hypervisor supported p2m list until a
virtual mapped linear p2m list can be constructed, remapping must
be delayed until virtual memory management is initialized, as the
initial p2m list can't be extended unlimited at physical memory
initialization time due to it's fixed structure.

A further advantage is the reduction in complexity and code volume as
we don't have to be careful regarding memory restrictions during p2m
updates.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/xen/page.h |   1 -
 arch/x86/xen/mmu.c              |   4 +
 arch/x86/xen/p2m.c              | 149 ++++------------
 arch/x86/xen/setup.c            | 385 +++++++++++++++++++---------------------
 arch/x86/xen/xen-ops.h          |   1 +
 5 files changed, 223 insertions(+), 317 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 6c16451..b475297 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -44,7 +44,6 @@ extern unsigned long  machine_to_phys_nr;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
-extern bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 					     unsigned long pfn_e);
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a8a1a3d..d3e492b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1223,6 +1223,10 @@ static void __init xen_pagetable_init(void)
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
+	/* Remap memory freed because of conflicts with E820 map */
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_remap_memory();
+
 	xen_setup_shared_info();
 	xen_post_allocator_init();
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index fa75842..f67f8cf 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -164,6 +164,7 @@
 #include <linux/sched.h>
 #include <linux/seq_file.h>
 #include <linux/bootmem.h>
+#include <linux/slab.h>
 
 #include <asm/cache.h>
 #include <asm/setup.h>
@@ -204,6 +205,8 @@ RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER
  */
 RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
+static int use_brk = 1;
+
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
 	BUG_ON(pfn >= MAX_P2M_PFN);
@@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
 		p2m[i] = INVALID_P2M_ENTRY;
 }
 
+static void * __ref alloc_p2m_page(void)
+{
+	if (unlikely(use_brk))
+		return extend_brk(PAGE_SIZE, PAGE_SIZE);
+
+	if (unlikely(!slab_is_available()))
+		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+
+	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static void free_p2m_page(void *p)
+{
+	free_page((unsigned long)p);
+}
+
 /*
  * Build the parallel p2m_top_mfn and p2m_mid_mfn structures
  *
@@ -287,13 +306,13 @@ void __ref xen_build_mfn_list_list(void)
 
 	/* Pre-initialize p2m_top_mfn to be completely missing */
 	if (p2m_top_mfn == NULL) {
-		p2m_mid_missing_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_mid_missing_mfn = alloc_p2m_page();
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 
-		p2m_top_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn_p = alloc_p2m_page();
 		p2m_top_mfn_p_init(p2m_top_mfn_p);
 
-		p2m_top_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn = alloc_p2m_page();
 		p2m_top_mfn_init(p2m_top_mfn);
 	} else {
 		/* Reinitialise, mfn's all change after migration */
@@ -327,7 +346,7 @@ void __ref xen_build_mfn_list_list(void)
 			 * missing parts of the mfn tree after
 			 * runtime.
 			 */
-			mid_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
 			p2m_top_mfn_p[topidx] = mid_mfn_p;
@@ -364,17 +383,17 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
 
-	p2m_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
-	p2m_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_identity = alloc_p2m_page();
 	p2m_init(p2m_identity);
 
-	p2m_mid_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_missing = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_identity = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_identity, p2m_identity);
 
-	p2m_top = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_top = alloc_p2m_page();
 	p2m_top_init(p2m_top);
 
 	/*
@@ -387,7 +406,7 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		unsigned mididx = p2m_mid_index(pfn);
 
 		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+			unsigned long **mid = alloc_p2m_page();
 			p2m_mid_init(mid, p2m_missing);
 
 			p2m_top[topidx] = mid;
@@ -420,6 +439,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 	unsigned long *mfn_list = NULL;
 	unsigned long size;
 
+	use_brk = 0;
 	va_start = xen_start_info->mfn_list;
 	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
 	 * so make sure it is rounded up to that */
@@ -484,6 +504,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
+	use_brk = 0;
 	return 0;
 }
 #endif
@@ -510,16 +531,6 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
-static void *alloc_p2m_page(void)
-{
-	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
-}
-
-static void free_p2m_page(void *p)
-{
-	free_page((unsigned long)p);
-}
-
 /*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
@@ -624,7 +635,7 @@ static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
 		return false;
 
 	/* Boundary cross-over for the edges: */
-	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m = alloc_p2m_page();
 
 	p2m_init(p2m);
 
@@ -640,7 +651,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 
 	mid = p2m_top[topidx];
 	if (mid == p2m_mid_missing) {
-		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+		mid = alloc_p2m_page();
 
 		p2m_mid_init(mid, p2m_missing);
 
@@ -649,100 +660,6 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 	return true;
 }
 
-/*
- * Skim over the P2M tree looking at pages that are either filled with
- * INVALID_P2M_ENTRY or with 1:1 PFNs. If found, re-use that page and
- * replace the P2M leaf with a p2m_missing or p2m_identity.
- * Stick the old page in the new P2M tree location.
- */
-static bool __init early_can_reuse_p2m_middle(unsigned long set_pfn)
-{
-	unsigned topidx;
-	unsigned mididx;
-	unsigned ident_pfns;
-	unsigned inv_pfns;
-	unsigned long *p2m;
-	unsigned idx;
-	unsigned long pfn;
-
-	/* We only look when this entails a P2M middle layer */
-	if (p2m_index(set_pfn))
-		return false;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
-		topidx = p2m_top_index(pfn);
-
-		if (!p2m_top[topidx])
-			continue;
-
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
-
-		mididx = p2m_mid_index(pfn);
-		p2m = p2m_top[topidx][mididx];
-		if (!p2m)
-			continue;
-
-		if ((p2m == p2m_missing) || (p2m == p2m_identity))
-			continue;
-
-		if ((unsigned long)p2m == INVALID_P2M_ENTRY)
-			continue;
-
-		ident_pfns = 0;
-		inv_pfns = 0;
-		for (idx = 0; idx < P2M_PER_PAGE; idx++) {
-			/* IDENTITY_PFNs are 1:1 */
-			if (p2m[idx] == IDENTITY_FRAME(pfn + idx))
-				ident_pfns++;
-			else if (p2m[idx] == INVALID_P2M_ENTRY)
-				inv_pfns++;
-			else
-				break;
-		}
-		if ((ident_pfns == P2M_PER_PAGE) || (inv_pfns == P2M_PER_PAGE))
-			goto found;
-	}
-	return false;
-found:
-	/* Found one, replace old with p2m_identity or p2m_missing */
-	p2m_top[topidx][mididx] = (ident_pfns ? p2m_identity : p2m_missing);
-
-	/* Reset where we want to stick the old page in. */
-	topidx = p2m_top_index(set_pfn);
-	mididx = p2m_mid_index(set_pfn);
-
-	/* This shouldn't happen */
-	if (WARN_ON(p2m_top[topidx] == p2m_mid_missing))
-		early_alloc_p2m_middle(set_pfn);
-
-	if (WARN_ON(p2m_top[topidx][mididx] != p2m_missing))
-		return false;
-
-	p2m_init(p2m);
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn)
-{
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
-		if (!early_alloc_p2m_middle(pfn))
-			return false;
-
-		if (early_can_reuse_p2m_middle(pfn))
-			return __set_phys_to_machine(pfn, mfn);
-
-		if (!early_alloc_p2m(pfn, false /* boundary crossover OK!*/))
-			return false;
-
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
-	}
-
-	return true;
-}
-
 static void __init early_split_p2m(unsigned long pfn)
 {
 	unsigned long mididx, idx;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 29834b3..0e5f9b6 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -30,6 +30,7 @@
 #include "xen-ops.h"
 #include "vdso.h"
 #include "p2m.h"
+#include "mmu.h"
 
 /* These are code, but not functions.  Defined in entry.S */
 extern const char xen_hypervisor_callback[];
@@ -47,8 +48,18 @@ struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 /* Number of pages released from the initial allocation. */
 unsigned long xen_released_pages;
 
-/* Buffer used to remap identity mapped pages */
-unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
+/*
+ * Buffer used to remap identity mapped pages. We only need the virtual space.
+ * The physical memory for each buffer page is remapped as needed.
+ */
+#define REMAP_SIZE	(P2M_PER_PAGE - 3)
+static struct {
+	unsigned long	next_area_mfn;
+	unsigned long	target_pfn;
+	unsigned long	size;
+	unsigned long	mfns[REMAP_SIZE];
+} xen_remap_buf __initdata __aligned(PAGE_SIZE);
+static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 /* 
  * The maximum amount of extra memory compared to the base size.  The
@@ -98,63 +109,6 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 	}
 }
 
-static unsigned long __init xen_do_chunk(unsigned long start,
-					 unsigned long end, bool release)
-{
-	struct xen_memory_reservation reservation = {
-		.address_bits = 0,
-		.extent_order = 0,
-		.domid        = DOMID_SELF
-	};
-	unsigned long len = 0;
-	unsigned long pfn;
-	int ret;
-
-	for (pfn = start; pfn < end; pfn++) {
-		unsigned long frame;
-		unsigned long mfn = pfn_to_mfn(pfn);
-
-		if (release) {
-			/* Make sure pfn exists to start with */
-			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
-				continue;
-			frame = mfn;
-		} else {
-			if (mfn != INVALID_P2M_ENTRY)
-				continue;
-			frame = pfn;
-		}
-		set_xen_guest_handle(reservation.extent_start, &frame);
-		reservation.nr_extents = 1;
-
-		ret = HYPERVISOR_memory_op(release ? XENMEM_decrease_reservation : XENMEM_populate_physmap,
-					   &reservation);
-		WARN(ret != 1, "Failed to %s pfn %lx err=%d\n",
-		     release ? "release" : "populate", pfn, ret);
-
-		if (ret == 1) {
-			if (!early_set_phys_to_machine(pfn, release ? INVALID_P2M_ENTRY : frame)) {
-				if (release)
-					break;
-				set_xen_guest_handle(reservation.extent_start, &frame);
-				reservation.nr_extents = 1;
-				ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
-							   &reservation);
-				break;
-			}
-			len++;
-		} else
-			break;
-	}
-	if (len)
-		printk(KERN_INFO "%s %lx-%lx pfn range: %lu pages %s\n",
-		       release ? "Freeing" : "Populating",
-		       start, end, len,
-		       release ? "freed" : "added");
-
-	return len;
-}
-
 /*
  * Finds the next RAM pfn available in the E820 map after min_pfn.
  * This function updates min_pfn with the pfn found and returns
@@ -198,23 +152,60 @@ static unsigned long __init xen_find_pfn_range(
 	return done;
 }
 
+static int __init xen_free_mfn(unsigned long mfn)
+{
+	struct xen_memory_reservation reservation = {
+		.address_bits = 0,
+		.extent_order = 0,
+		.domid        = DOMID_SELF
+	};
+
+	set_xen_guest_handle(reservation.extent_start, &mfn);
+	reservation.nr_extents = 1;
+
+	return HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation);
+}
+
 /*
- * This releases a chunk of memory and then does the identity map. It's used as
+ * This releases a chunk of memory and then does the identity map. It's used
  * as a fallback if the remapping fails.
  */
 static void __init xen_set_identity_and_release_chunk(unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long *identity,
 	unsigned long *released)
 {
+	unsigned long len = 0;
+	unsigned long pfn, end;
+	int ret;
+
 	WARN_ON(start_pfn > end_pfn);
 
+	end = min(end_pfn, nr_pages);
+	for (pfn = start_pfn; pfn < end; pfn++) {
+		unsigned long mfn = pfn_to_mfn(pfn);
+
+		/* Make sure pfn exists to start with */
+		if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+			continue;
+
+		ret = xen_free_mfn(mfn);
+		WARN(ret != 1, "Failed to release pfn %lx err=%d\n", pfn, ret);
+
+		if (ret == 1) {
+			if (!__set_phys_to_machine(pfn, INVALID_P2M_ENTRY))
+				break;
+			len++;
+		} else
+			break;
+	}
+
 	/* Need to release pages first */
-	*released += xen_do_chunk(start_pfn, min(end_pfn, nr_pages), true);
+	*released += len;
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
 /*
- * Helper function to update both the p2m and m2p tables.
+ * Helper function to update the p2m and m2p tables and kernel mapping.
  */
 static unsigned long __init xen_update_mem_tables(unsigned long pfn,
 						  unsigned long mfn)
@@ -225,161 +216,92 @@ static unsigned long __init xen_update_mem_tables(unsigned long pfn,
 	};
 
 	/* Update p2m */
-	if (!early_set_phys_to_machine(pfn, mfn)) {
+	if (!set_phys_to_machine(pfn, mfn)) {
 		WARN(1, "Failed to set p2m mapping for pfn=%ld mfn=%ld\n",
 		     pfn, mfn);
-		return false;
+		return 0;
 	}
 
 	/* Update m2p */
 	if (HYPERVISOR_mmu_update(&update, 1, NULL, DOMID_SELF) < 0) {
 		WARN(1, "Failed to set m2p mapping for mfn=%ld pfn=%ld\n",
 		     mfn, pfn);
-		return false;
+		return 0;
+	}
+
+	/* Update kernel mapping, but not for highmem. */
+	if ((pfn << PAGE_SHIFT) >= __pa(high_memory))
+		return 1;
+
+	if (HYPERVISOR_update_va_mapping((unsigned long)__va(pfn << PAGE_SHIFT),
+					 mfn_pte(mfn, PAGE_KERNEL), 0)) {
+		WARN(1, "Failed to update kernel mapping for mfn=%ld pfn=%ld\n",
+		      mfn, pfn);
+		return 0;
 	}
 
-	return true;
+	return 1;
 }
 
 /*
  * This function updates the p2m and m2p tables with an identity map from
- * start_pfn to start_pfn+size and remaps the underlying RAM of the original
- * allocation at remap_pfn. It must do so carefully in P2M_PER_PAGE sized blocks
- * to not exhaust the reserved brk space. Doing it in properly aligned blocks
- * ensures we only allocate the minimum required leaf pages in the p2m table. It
- * copies the existing mfns from the p2m table under the 1:1 map, overwrites
- * them with the identity map and then updates the p2m and m2p tables with the
- * remapped memory.
+ * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the
+ * original allocation at remap_pfn. The information needed for remapping is
+ * saved in the memory itself to avoid the need for allocating buffers. The
+ * complete remap information is contained in a list of MFNs each containing
+ * up to REMAP_SIZE MFNs and the start target PFN for doing the remap.
+ * This enables to preserve the original mfn sequence while doing the remapping
+ * at a time when the memory management is capable of allocating virtual and
+ * physical memory in arbitrary amounts.
  */
-static unsigned long __init xen_do_set_identity_and_remap_chunk(
+static void __init xen_do_set_identity_and_remap_chunk(
         unsigned long start_pfn, unsigned long size, unsigned long remap_pfn)
 {
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn;
 	unsigned long ident_pfn_iter, remap_pfn_iter;
-	unsigned long ident_start_pfn_align, remap_start_pfn_align;
-	unsigned long ident_end_pfn_align, remap_end_pfn_align;
-	unsigned long ident_boundary_pfn, remap_boundary_pfn;
-	unsigned long ident_cnt = 0;
-	unsigned long remap_cnt = 0;
+	unsigned long ident_end_pfn = start_pfn + size;
 	unsigned long left = size;
-	unsigned long mod;
-	int i;
+	unsigned long ident_cnt = 0;
+	unsigned int i, chunk;
 
 	WARN_ON(size == 0);
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/*
-	 * Determine the proper alignment to remap memory in P2M_PER_PAGE sized
-	 * blocks. We need to keep track of both the existing pfn mapping and
-	 * the new pfn remapping.
-	 */
-	mod = start_pfn % P2M_PER_PAGE;
-	ident_start_pfn_align =
-		mod ? (start_pfn - mod + P2M_PER_PAGE) : start_pfn;
-	mod = remap_pfn % P2M_PER_PAGE;
-	remap_start_pfn_align =
-		mod ? (remap_pfn - mod + P2M_PER_PAGE) : remap_pfn;
-	mod = (start_pfn + size) % P2M_PER_PAGE;
-	ident_end_pfn_align = start_pfn + size - mod;
-	mod = (remap_pfn + size) % P2M_PER_PAGE;
-	remap_end_pfn_align = remap_pfn + size - mod;
-
-	/* Iterate over each p2m leaf node in each range */
-	for (ident_pfn_iter = ident_start_pfn_align, remap_pfn_iter = remap_start_pfn_align;
-	     ident_pfn_iter < ident_end_pfn_align && remap_pfn_iter < remap_end_pfn_align;
-	     ident_pfn_iter += P2M_PER_PAGE, remap_pfn_iter += P2M_PER_PAGE) {
-		/* Check we aren't past the end */
-		BUG_ON(ident_pfn_iter + P2M_PER_PAGE > start_pfn + size);
-		BUG_ON(remap_pfn_iter + P2M_PER_PAGE > remap_pfn + size);
-
-		/* Save p2m mappings */
-		for (i = 0; i < P2M_PER_PAGE; i++)
-			xen_remap_buf[i] = pfn_to_mfn(ident_pfn_iter + i);
-
-		/* Set identity map which will free a p2m leaf */
-		ident_cnt += set_phys_range_identity(ident_pfn_iter,
-			ident_pfn_iter + P2M_PER_PAGE);
-
-#ifdef DEBUG
-		/* Helps verify a p2m leaf has been freed */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned int pfn = ident_pfn_iter + i;
-			BUG_ON(pfn_to_mfn(pfn) != pfn);
-		}
-#endif
-		/* Now remap memory */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned long mfn = xen_remap_buf[i];
-
-			/* This will use the p2m leaf freed above */
-			if (!xen_update_mem_tables(remap_pfn_iter + i, mfn)) {
-				WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-					remap_pfn_iter + i, mfn);
-				return 0;
-			}
-
-			remap_cnt++;
-		}
-
-		left -= P2M_PER_PAGE;
-	}
+	/* Don't use memory until remapped */
+	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
 
-	/* Max boundary space possible */
-	BUG_ON(left > (P2M_PER_PAGE - 1) * 2);
+	mfn_save = virt_to_mfn(buf);
 
-	/* Now handle the boundary conditions */
-	ident_boundary_pfn = start_pfn;
-	remap_boundary_pfn = remap_pfn;
-	for (i = 0; i < left; i++) {
-		unsigned long mfn;
+	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
+	     ident_pfn_iter < ident_end_pfn;
+	     ident_pfn_iter += REMAP_SIZE, remap_pfn_iter += REMAP_SIZE) {
+		chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE;
 
-		/* These two checks move from the start to end boundaries */
-		if (ident_boundary_pfn == ident_start_pfn_align)
-			ident_boundary_pfn = ident_pfn_iter;
-		if (remap_boundary_pfn == remap_start_pfn_align)
-			remap_boundary_pfn = remap_pfn_iter;
+		/* Map first pfn to xen_remap_buf */
+		mfn = pfn_to_mfn(ident_pfn_iter);
+		set_pte_mfn(buf, mfn, PAGE_KERNEL);
 
-		/* Check we aren't past the end */
-		BUG_ON(ident_boundary_pfn >= start_pfn + size);
-		BUG_ON(remap_boundary_pfn >= remap_pfn + size);
+		/* Save mapping information in page */
+		xen_remap_buf.next_area_mfn = xen_remap_mfn;
+		xen_remap_buf.target_pfn = remap_pfn_iter;
+		xen_remap_buf.size = chunk;
+		for (i = 0; i < chunk; i++)
+			xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i);
 
-		mfn = pfn_to_mfn(ident_boundary_pfn);
+		/* New element first in list */
+		xen_remap_mfn = mfn;
 
-		if (!xen_update_mem_tables(remap_boundary_pfn, mfn)) {
-			WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-				remap_pfn_iter + i, mfn);
-			return 0;
-		}
-		remap_cnt++;
-
-		ident_boundary_pfn++;
-		remap_boundary_pfn++;
-	}
+		/* Set identity map */
+		ident_cnt += set_phys_range_identity(ident_pfn_iter,
+			ident_pfn_iter + chunk);
 
-	/* Finish up the identity map */
-	if (ident_start_pfn_align >= ident_end_pfn_align) {
-		/*
-                 * In this case we have an identity range which does not span an
-                 * aligned block so everything needs to be identity mapped here.
-                 * If we didn't check this we might remap too many pages since
-                 * the align boundaries are not meaningful in this case.
-	         */
-		ident_cnt += set_phys_range_identity(start_pfn,
-			start_pfn + size);
-	} else {
-		/* Remapped above so check each end of the chunk */
-		if (start_pfn < ident_start_pfn_align)
-			ident_cnt += set_phys_range_identity(start_pfn,
-				ident_start_pfn_align);
-		if (start_pfn + size > ident_pfn_iter)
-			ident_cnt += set_phys_range_identity(ident_pfn_iter,
-				start_pfn + size);
+		left -= chunk;
 	}
 
-	BUG_ON(ident_cnt != size);
-	BUG_ON(remap_cnt != size);
-
-	return size;
+	/* Restore old xen_remap_buf mapping */
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 }
 
 /*
@@ -396,8 +318,7 @@ static unsigned long __init xen_do_set_identity_and_remap_chunk(
 static unsigned long __init xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
-	unsigned long *identity, unsigned long *remapped,
-	unsigned long *released)
+	unsigned long *identity, unsigned long *released)
 {
 	unsigned long pfn;
 	unsigned long i = 0;
@@ -431,19 +352,12 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 		if (size > remap_range_size)
 			size = remap_range_size;
 
-		if (!xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn)) {
-			WARN(1, "Failed to remap 1:1 memory cur_pfn=%ld size=%ld remap_pfn=%ld\n",
-				cur_pfn, size, remap_pfn);
-			xen_set_identity_and_release_chunk(cur_pfn,
-				cur_pfn + left, nr_pages, identity, released);
-			break;
-		}
+		xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn);
 
 		/* Update variables to reflect new mappings. */
 		i += size;
 		remap_pfn += size;
 		*identity += size;
-		*remapped += size;
 	}
 
 	/*
@@ -464,7 +378,6 @@ static unsigned long __init xen_set_identity_and_remap(
 {
 	phys_addr_t start = 0;
 	unsigned long identity = 0;
-	unsigned long remapped = 0;
 	unsigned long last_pfn = nr_pages;
 	const struct e820entry *entry;
 	unsigned long num_released = 0;
@@ -494,8 +407,7 @@ static unsigned long __init xen_set_identity_and_remap(
 				last_pfn = xen_set_identity_and_remap_chunk(
 						list, map_size, start_pfn,
 						end_pfn, nr_pages, last_pfn,
-						&identity, &remapped,
-						&num_released);
+						&identity, &num_released);
 			start = end;
 		}
 	}
@@ -503,12 +415,84 @@ static unsigned long __init xen_set_identity_and_remap(
 	*released = num_released;
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
-	pr_info("Remapped %ld page(s), last_pfn=%ld\n", remapped,
-		last_pfn);
 	pr_info("Released %ld page(s)\n", num_released);
 
 	return last_pfn;
 }
+
+/*
+ * Remap the memory prepared in xen_do_set_identity_and_remap_chunk().
+ */
+void __init xen_remap_memory(void)
+{
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn, pfn;
+	unsigned long remapped = 0, released = 0;
+	unsigned int i, free;
+	unsigned long pfn_s = ~0UL;
+	unsigned long len = 0;
+
+	mfn_save = virt_to_mfn(buf);
+
+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
+		/* Map the remap information */
+		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
+
+		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
+
+		free = 0;
+		pfn = xen_remap_buf.target_pfn;
+		for (i = 0; i < xen_remap_buf.size; i++) {
+			mfn = xen_remap_buf.mfns[i];
+			if (!released && xen_update_mem_tables(pfn, mfn)) {
+				remapped++;
+			} else {
+				if (!released) {
+					if (pfn_s != ~0UL && len)
+						memblock_free(PFN_PHYS(pfn_s),
+							      PFN_PHYS(len));
+					pfn_s = xen_remap_buf.target_pfn;
+					len = i;
+				}
+				/* Don't free the page with our mfn list! */
+				if (i)
+					xen_free_mfn(mfn);
+				else
+					free = 1;
+				released++;
+			}
+			pfn++;
+		}
+		if (!released) {
+			if (pfn_s == ~0UL || pfn == pfn_s) {
+				pfn_s = xen_remap_buf.target_pfn;
+				len += xen_remap_buf.size;
+			} else if (pfn_s + len == xen_remap_buf.target_pfn) {
+				len += xen_remap_buf.size;
+			} else {
+				memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+				pfn_s = xen_remap_buf.target_pfn;
+				len = xen_remap_buf.size;
+			}
+		}
+
+		mfn = xen_remap_mfn;
+		xen_remap_mfn = xen_remap_buf.next_area_mfn;
+		/* Now it's save to free the page holding our data. */
+		if (free)
+			xen_free_mfn(mfn);
+	}
+
+	if (pfn_s != ~0UL && len)
+		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
+
+	pr_info("Remapped %ld page(s)\n", remapped);
+	if (released)
+		pr_info("Released %ld page(s)\n", released);
+}
+
 static unsigned long __init xen_get_max_pages(void)
 {
 	unsigned long max_pages = MAX_DOMAIN_PAGES;
@@ -616,7 +600,8 @@ char * __init xen_memory_setup(void)
 		extra_pages += max_pages - max_pfn;
 
 	/*
-	 * Set identity map on non-RAM pages and remap the underlying RAM.
+	 * Set identity map on non-RAM pages and prepare remapping the
+	 * underlying RAM.
 	 */
 	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
 					      &xen_released_pages);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 28c7e0b..5b72a06 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,6 +35,7 @@ void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
 void __init xen_arch_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FJ-0001bs-Pf; Tue, 11 Nov 2014 05:44:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FF-0001aM-Md
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	55/AE-09842-022A1645; Tue, 11 Nov 2014 05:44:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415684638!12817143!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14105 invoked from network); 11 Nov 2014 05:43:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:59 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B1080ACA0;
	Tue, 11 Nov 2014 05:43:58 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:42 +0100
Message-Id: <1415684626-18590-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 4/8] xen: Delay invalidating extra memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When the physical memory configuration is initialized the p2m entries
for not pouplated memory pages are set to "invalid". As those pages
are beyond the hypervisor built p2m list the p2m tree has to be
extended.

This patch delays processing the extra memory related p2m entries
during the boot process until some more basic memory management
functions are callable. This removes the need to create new p2m
entries until virtual memory management is available.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/xen/page.h |   3 +
 arch/x86/xen/p2m.c              | 130 ++++++++--------------------------------
 arch/x86/xen/setup.c            | 103 ++++++++++++++++++++++---------
 arch/x86/xen/xen-ops.h          |   3 +-
 4 files changed, 107 insertions(+), 132 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index b475297..28fa795 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -41,6 +41,9 @@ typedef struct xpaddr {
 
 extern unsigned long *machine_to_phys_mapping;
 extern unsigned long  machine_to_phys_nr;
+extern unsigned long *xen_p2m_addr;
+extern unsigned long  xen_p2m_size;
+extern unsigned long  xen_max_p2m_pfn;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 97252e3..6a9dfa6 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -181,7 +181,12 @@
 
 static void __init m2p_override_init(void);
 
+unsigned long *xen_p2m_addr __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_addr);
+unsigned long xen_p2m_size __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
+EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
@@ -198,13 +203,6 @@ static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
 
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
 
-/* For each I/O range remapped we may lose up to two leaf pages for the boundary
- * violations and three mid pages to cover up to 3GB. With
- * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
- * remapped region.
- */
-RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
-
 static int use_brk = 1;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
@@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	unsigned long max_pfn;
 	unsigned long pfn;
 
-	 if (xen_feature(XENFEAT_auto_translated_physmap))
+	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
+	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
 	mfn_list = (unsigned long *)xen_start_info->mfn_list;
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
+	xen_p2m_size = max_pfn;
 
 	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
@@ -497,6 +497,11 @@ unsigned long __init xen_revector_p2m_tree(void)
 		/* This should be the leafs allocated for identity from _brk. */
 	}
 
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_p2m_addr = mfn_list;
+
+	xen_inv_extra_mem();
+
 	m2p_override_init();
 	return (unsigned long)mfn_list;
 }
@@ -504,6 +509,8 @@ unsigned long __init xen_revector_p2m_tree(void)
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_inv_extra_mem();
 	m2p_override_init();
 	return 0;
 }
@@ -512,8 +519,12 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(pfn >= MAX_P2M_PFN))
+	if (unlikely(pfn >= xen_p2m_size)) {
+		if (pfn < xen_max_p2m_pfn)
+			return xen_chk_extra_mem(pfn);
+
 		return IDENTITY_FRAME(pfn);
+	}
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
@@ -611,78 +622,12 @@ static bool alloc_p2m(unsigned long pfn)
 	return true;
 }
 
-static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
-{
-	unsigned topidx, mididx, idx;
-	unsigned long *p2m;
-
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* Pfff.. No boundary cross-over, lets get out. */
-	if (!idx && check_boundary)
-		return false;
-
-	WARN(p2m_top[topidx][mididx] == p2m_identity,
-		"P2M[%d][%d] == IDENTITY, should be MISSING (or alloced)!\n",
-		topidx, mididx);
-
-	/*
-	 * Could be done by xen_build_dynamic_phys_to_machine..
-	 */
-	if (p2m_top[topidx][mididx] != p2m_missing)
-		return false;
-
-	/* Boundary cross-over for the edges: */
-	p2m = alloc_p2m_page();
-
-	p2m_init(p2m);
-
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-
-static bool __init early_alloc_p2m_middle(unsigned long pfn)
-{
-	unsigned topidx = p2m_top_index(pfn);
-	unsigned long **mid;
-
-	mid = p2m_top[topidx];
-	if (mid == p2m_mid_missing) {
-		mid = alloc_p2m_page();
-
-		p2m_mid_init(mid, p2m_missing);
-
-		p2m_top[topidx] = mid;
-	}
-	return true;
-}
-
-static void __init early_split_p2m(unsigned long pfn)
-{
-	unsigned long mididx, idx;
-
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/*
-	 * Allocate new middle and leaf pages if this pfn lies in the
-	 * middle of one.
-	 */
-	if (mididx || idx)
-		early_alloc_p2m_middle(pfn);
-	if (idx)
-		early_alloc_p2m(pfn, false);
-}
-
 unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 				      unsigned long pfn_e)
 {
 	unsigned long pfn;
 
-	if (unlikely(pfn_s >= MAX_P2M_PFN))
+	if (unlikely(pfn_s >= xen_p2m_size))
 		return 0;
 
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -691,34 +636,11 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	if (pfn_s > pfn_e)
 		return 0;
 
-	if (pfn_e > MAX_P2M_PFN)
-		pfn_e = MAX_P2M_PFN;
-
-	early_split_p2m(pfn_s);
-	early_split_p2m(pfn_e);
-
-	for (pfn = pfn_s; pfn < pfn_e;) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-
-		if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
-			break;
-		pfn++;
-
-		/*
-		 * If the PFN was set to a middle or leaf identity
-		 * page the remainder must also be identity, so skip
-		 * ahead to the next middle or leaf entry.
-		 */
-		if (p2m_top[topidx] == p2m_mid_identity)
-			pfn = ALIGN(pfn, P2M_MID_PER_PAGE * P2M_PER_PAGE);
-		else if (p2m_top[topidx][mididx] == p2m_identity)
-			pfn = ALIGN(pfn, P2M_PER_PAGE);
-	}
+	if (pfn_e > xen_p2m_size)
+		pfn_e = xen_p2m_size;
 
-	WARN((pfn - pfn_s) != (pfn_e - pfn_s),
-		"Identity mapping failed. We are %ld short of 1-1 mappings!\n",
-		(pfn_e - pfn_s) - (pfn - pfn_s));
+	for (pfn = pfn_s; pfn < pfn_e; pfn++)
+		xen_p2m_addr[pfn] = IDENTITY_FRAME(pfn);
 
 	return pfn - pfn_s;
 }
@@ -732,7 +654,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
 		return true;
 
-	if (unlikely(pfn >= MAX_P2M_PFN)) {
+	if (unlikely(pfn >= xen_p2m_size)) {
 		BUG_ON(mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 0e5f9b6..8d5985b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -75,7 +75,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 static void __init xen_add_extra_mem(u64 start, u64 size)
 {
-	unsigned long pfn;
 	int i;
 
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
@@ -95,17 +94,74 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
 
 	memblock_reserve(start, size);
+}
 
-	xen_max_p2m_pfn = PFN_DOWN(start + size);
-	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
-		unsigned long mfn = pfn_to_mfn(pfn);
+static void __init xen_del_extra_mem(u64 start, u64 size)
+{
+	int i;
+	u64 start_r, size_r;
 
-		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
-			continue;
-		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
-			  pfn, mfn);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		start_r = xen_extra_mem[i].start;
+		size_r = xen_extra_mem[i].size;
+
+		/* Start of region. */
+		if (start_r == start) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].start += size;
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* End of region. */
+		if (start_r + size_r == start + size) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* Mid of region. */
+		if (start > start_r && start < start_r + size_r) {
+			BUG_ON(start + size > start_r + size_r);
+			xen_extra_mem[i].size = start - start_r;
+			xen_add_extra_mem(start + size, start_r + size_r -
+					  (start + size));
+			break;
+		}
+	}
+	memblock_free(start, size);
+}
+
+/*
+ * Called during boot before the p2m list can take entries beyond the
+ * hypervisor supplied p2m list. Entries in extra mem are to be regarded as
+ * invalid.
+ */
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
+{
+	int i;
+	unsigned long addr = PFN_PHYS(pfn);
 
-		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		if (addr >= xen_extra_mem[i].start &&
+		    addr < xen_extra_mem[i].start + xen_extra_mem[i].size)
+			return INVALID_P2M_ENTRY;
+	}
+
+	return IDENTITY_FRAME(pfn);
+}
+
+/*
+ * Mark all pfns of extra mem as invalid in p2m list.
+ */
+void __init xen_inv_extra_mem(void)
+{
+	unsigned long pfn, pfn_s, pfn_e;
+	int i;
+
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		pfn_s = PFN_DOWN(xen_extra_mem[i].start);
+		pfn_e = PFN_UP(xen_extra_mem[i].start + xen_extra_mem[i].size);
+		for (pfn = pfn_s; pfn < pfn_e; pfn++)
+			set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 	}
 }
 
@@ -269,9 +325,6 @@ static void __init xen_do_set_identity_and_remap_chunk(
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/* Don't use memory until remapped */
-	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
-
 	mfn_save = virt_to_mfn(buf);
 
 	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
@@ -315,7 +368,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
  * pages. In the case of an error the underlying memory is simply released back
  * to Xen and not remapped.
  */
-static unsigned long __init xen_set_identity_and_remap_chunk(
+static unsigned long xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
 	unsigned long *identity, unsigned long *released)
@@ -372,7 +425,7 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 	return remap_pfn;
 }
 
-static unsigned long __init xen_set_identity_and_remap(
+static void __init xen_set_identity_and_remap(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages,
 	unsigned long *released)
 {
@@ -416,8 +469,6 @@ static unsigned long __init xen_set_identity_and_remap(
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
 	pr_info("Released %ld page(s)\n", num_released);
-
-	return last_pfn;
 }
 
 /*
@@ -449,8 +500,9 @@ void __init xen_remap_memory(void)
 			} else {
 				if (!released) {
 					if (pfn_s != ~0UL && len)
-						memblock_free(PFN_PHYS(pfn_s),
-							      PFN_PHYS(len));
+						xen_del_extra_mem(
+							PFN_PHYS(pfn_s),
+							PFN_PHYS(len));
 					pfn_s = xen_remap_buf.target_pfn;
 					len = i;
 				}
@@ -470,7 +522,8 @@ void __init xen_remap_memory(void)
 			} else if (pfn_s + len == xen_remap_buf.target_pfn) {
 				len += xen_remap_buf.size;
 			} else {
-				memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+				xen_del_extra_mem(PFN_PHYS(pfn_s),
+						  PFN_PHYS(len));
 				pfn_s = xen_remap_buf.target_pfn;
 				len = xen_remap_buf.size;
 			}
@@ -484,7 +537,7 @@ void __init xen_remap_memory(void)
 	}
 
 	if (pfn_s != ~0UL && len)
-		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+		xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
 
 	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 
@@ -553,7 +606,6 @@ char * __init xen_memory_setup(void)
 	int rc;
 	struct xen_memory_map memmap;
 	unsigned long max_pages;
-	unsigned long last_pfn = 0;
 	unsigned long extra_pages = 0;
 	int i;
 	int op;
@@ -603,15 +655,11 @@ char * __init xen_memory_setup(void)
 	 * Set identity map on non-RAM pages and prepare remapping the
 	 * underlying RAM.
 	 */
-	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
-					      &xen_released_pages);
+	xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
+				   &xen_released_pages);
 
 	extra_pages += xen_released_pages;
 
-	if (last_pfn > max_pfn) {
-		max_pfn = min(MAX_DOMAIN_PAGES, last_pfn);
-		mem_end = PFN_PHYS(max_pfn);
-	}
 	/*
 	 * Clamp the amount of extra memory to a EXTRA_MEM_RATIO
 	 * factor the base size.  On non-highmem systems, the base
@@ -638,6 +686,7 @@ char * __init xen_memory_setup(void)
 				size = min(size, (u64)extra_pages * PAGE_SIZE);
 				extra_pages -= size / PAGE_SIZE;
 				xen_add_extra_mem(addr, size);
+				xen_max_p2m_pfn = PFN_DOWN(addr + size);
 			} else
 				type = E820_UNUSABLE;
 		}
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 5b72a06..02b0b0f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -29,12 +29,13 @@ void xen_build_mfn_list_list(void);
 void xen_setup_machphys_mapping(void);
 void xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn);
 void xen_reserve_top(void);
-extern unsigned long xen_max_p2m_pfn;
 
 void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn);
+void __init xen_inv_extra_mem(void);
 void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FH-0001aw-Ep; Tue, 11 Nov 2014 05:44:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FE-0001aF-1F
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6B/F0-09936-F12A1645; Tue, 11 Nov 2014 05:43:59 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415684638!12892046!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32677 invoked from network); 11 Nov 2014 05:43:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:58 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 54845AC95;
	Tue, 11 Nov 2014 05:43:58 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:41 +0100
Message-Id: <1415684626-18590-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 3/8] xen: Delay m2p_override initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 m2p overrides are used to be able to find the local pfn for a
foreign mfn mapped into the domain. They are used by driver backends
having to access frontend data.

As this functionality isn't used in early boot it makes no sense to
initialize the m2p override functions very early. It can be done
later without doing any harm, removing the need for allocating memory
via extend_brk().

While at it make some m2p override functions static as they are only
used internally.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/p2m.c | 33 +++++++++++++++++++--------------
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index f67f8cf..97252e3 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -426,8 +426,6 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		}
 		p2m_top[topidx][mididx] = &mfn_list[pfn];
 	}
-
-	m2p_override_init();
 }
 #ifdef CONFIG_X86_64
 unsigned long __init xen_revector_p2m_tree(void)
@@ -498,13 +496,15 @@ unsigned long __init xen_revector_p2m_tree(void)
 		}
 		/* This should be the leafs allocated for identity from _brk. */
 	}
-	return (unsigned long)mfn_list;
 
+	m2p_override_init();
+	return (unsigned long)mfn_list;
 }
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	m2p_override_init();
 	return 0;
 }
 #endif
@@ -794,15 +794,16 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 #define M2P_OVERRIDE_HASH_SHIFT	10
 #define M2P_OVERRIDE_HASH	(1 << M2P_OVERRIDE_HASH_SHIFT)
 
-static RESERVE_BRK_ARRAY(struct list_head, m2p_overrides, M2P_OVERRIDE_HASH);
+static struct list_head *m2p_overrides;
 static DEFINE_SPINLOCK(m2p_override_lock);
 
 static void __init m2p_override_init(void)
 {
 	unsigned i;
 
-	m2p_overrides = extend_brk(sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
-				   sizeof(unsigned long));
+	m2p_overrides = alloc_bootmem_align(
+				sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
+				sizeof(unsigned long));
 
 	for (i = 0; i < M2P_OVERRIDE_HASH; i++)
 		INIT_LIST_HEAD(&m2p_overrides[i]);
@@ -930,21 +931,25 @@ EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
 static struct page *m2p_find_override(unsigned long mfn)
 {
 	unsigned long flags;
-	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
+	struct list_head *bucket;
 	struct page *p, *ret;
 
 	ret = NULL;
 
-	spin_lock_irqsave(&m2p_override_lock, flags);
+	if (m2p_overrides) {
+		bucket = &m2p_overrides[mfn_hash(mfn)];
 
-	list_for_each_entry(p, bucket, lru) {
-		if (page_private(p) == mfn) {
-			ret = p;
-			break;
+		spin_lock_irqsave(&m2p_override_lock, flags);
+
+		list_for_each_entry(p, bucket, lru) {
+			if (page_private(p) == mfn) {
+				ret = p;
+				break;
+			}
 		}
-	}
 
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
+		spin_unlock_irqrestore(&m2p_override_lock, flags);
+	}
 
 	return ret;
 }
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FF-0001aV-4D; Tue, 11 Nov 2014 05:44:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FD-0001aA-3V
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:43:59 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	E6/A0-29352-E12A1645; Tue, 11 Nov 2014 05:43:58 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415684637!6373500!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22538 invoked from network); 11 Nov 2014 05:43:57 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 05:43:57 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 57668AAF1;
	Tue, 11 Nov 2014 05:43:57 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:38 +0100
Message-Id: <1415684626-18590-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 0/8] xen: Switch to virtual mapped linear p2m
	list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paravirtualized kernels running on Xen use a three level tree for
translation of guest specific physical addresses to machine global
addresses. This p2m tree is used for construction of page table
entries, so the p2m tree walk is performance critical.

By using a linear virtual mapped p2m list accesses to p2m elements
can be sped up while even simplifying code. To achieve this goal
some p2m related initializations have to be performed later in the
boot process, as the final p2m list can be set up only after basic
memory management functions are available.

Changes in V3:
- Carved out (new) patch 1 to make pure code movement more obvious
  as requested by David Vrabel
- New patch 6 introducing __pfn_to_mfn() (taken from patch 7) as
  requested by David Vrabel
- New patch 8 to speed up set_phys_to_machine() as suggested by
  David Vrabel

Changes in V2:
- splitted patch 2 in 4 smaller ones as requested by David Vrabel
- added highmem check when remapping kernel memory as requested by
  David Vrabel

Juergen Gross (8):
  xen: Make functions static
  xen: Delay remapping memory of pv-domain
  xen: Delay m2p_override initialization
  xen: Delay invalidating extra memory
  x86: Introduce function to get pmd entry pointer
  xen: Hide get_phys_to_machine() to be able to tune common path
  xen: switch to linear virtual mapped sparse p2m list
  xen: Speed up set_phys_to_machine() by using read-only mappings

 arch/x86/include/asm/pgtable_types.h |    1 +
 arch/x86/include/asm/xen/page.h      |   49 +-
 arch/x86/mm/pageattr.c               |   20 +
 arch/x86/xen/mmu.c                   |   38 +-
 arch/x86/xen/p2m.c                   | 1315 ++++++++++++++--------------------
 arch/x86/xen/setup.c                 |  460 ++++++------
 arch/x86/xen/xen-ops.h               |    6 +-
 7 files changed, 854 insertions(+), 1035 deletions(-)

-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FI-0001bE-4x; Tue, 11 Nov 2014 05:44:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FE-0001aL-P3
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E5/47-24532-022A1645; Tue, 11 Nov 2014 05:44:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415684638!12836176!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29492 invoked from network); 11 Nov 2014 05:43:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:58 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 014C2ABC6;
	Tue, 11 Nov 2014 05:43:58 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:40 +0100
Message-Id: <1415684626-18590-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of pv-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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Early in the boot process the memory layout of a pv-domain is changed
to match the E820 map (either the host one for Dom0 or the Xen one)
regarding placement of RAM and PCI holes. This requires removing memory
pages initially located at positions not suitable for RAM and adding
them later at higher addresses where no restrictions apply.

To be able to operate on the hypervisor supported p2m list until a
virtual mapped linear p2m list can be constructed, remapping must
be delayed until virtual memory management is initialized, as the
initial p2m list can't be extended unlimited at physical memory
initialization time due to it's fixed structure.

A further advantage is the reduction in complexity and code volume as
we don't have to be careful regarding memory restrictions during p2m
updates.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/xen/page.h |   1 -
 arch/x86/xen/mmu.c              |   4 +
 arch/x86/xen/p2m.c              | 149 ++++------------
 arch/x86/xen/setup.c            | 385 +++++++++++++++++++---------------------
 arch/x86/xen/xen-ops.h          |   1 +
 5 files changed, 223 insertions(+), 317 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 6c16451..b475297 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -44,7 +44,6 @@ extern unsigned long  machine_to_phys_nr;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
-extern bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 					     unsigned long pfn_e);
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a8a1a3d..d3e492b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1223,6 +1223,10 @@ static void __init xen_pagetable_init(void)
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
+	/* Remap memory freed because of conflicts with E820 map */
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_remap_memory();
+
 	xen_setup_shared_info();
 	xen_post_allocator_init();
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index fa75842..f67f8cf 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -164,6 +164,7 @@
 #include <linux/sched.h>
 #include <linux/seq_file.h>
 #include <linux/bootmem.h>
+#include <linux/slab.h>
 
 #include <asm/cache.h>
 #include <asm/setup.h>
@@ -204,6 +205,8 @@ RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER
  */
 RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
+static int use_brk = 1;
+
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
 	BUG_ON(pfn >= MAX_P2M_PFN);
@@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
 		p2m[i] = INVALID_P2M_ENTRY;
 }
 
+static void * __ref alloc_p2m_page(void)
+{
+	if (unlikely(use_brk))
+		return extend_brk(PAGE_SIZE, PAGE_SIZE);
+
+	if (unlikely(!slab_is_available()))
+		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+
+	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static void free_p2m_page(void *p)
+{
+	free_page((unsigned long)p);
+}
+
 /*
  * Build the parallel p2m_top_mfn and p2m_mid_mfn structures
  *
@@ -287,13 +306,13 @@ void __ref xen_build_mfn_list_list(void)
 
 	/* Pre-initialize p2m_top_mfn to be completely missing */
 	if (p2m_top_mfn == NULL) {
-		p2m_mid_missing_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_mid_missing_mfn = alloc_p2m_page();
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 
-		p2m_top_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn_p = alloc_p2m_page();
 		p2m_top_mfn_p_init(p2m_top_mfn_p);
 
-		p2m_top_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn = alloc_p2m_page();
 		p2m_top_mfn_init(p2m_top_mfn);
 	} else {
 		/* Reinitialise, mfn's all change after migration */
@@ -327,7 +346,7 @@ void __ref xen_build_mfn_list_list(void)
 			 * missing parts of the mfn tree after
 			 * runtime.
 			 */
-			mid_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
 			p2m_top_mfn_p[topidx] = mid_mfn_p;
@@ -364,17 +383,17 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
 
-	p2m_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
-	p2m_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_identity = alloc_p2m_page();
 	p2m_init(p2m_identity);
 
-	p2m_mid_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_missing = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_identity = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_identity, p2m_identity);
 
-	p2m_top = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_top = alloc_p2m_page();
 	p2m_top_init(p2m_top);
 
 	/*
@@ -387,7 +406,7 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		unsigned mididx = p2m_mid_index(pfn);
 
 		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+			unsigned long **mid = alloc_p2m_page();
 			p2m_mid_init(mid, p2m_missing);
 
 			p2m_top[topidx] = mid;
@@ -420,6 +439,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 	unsigned long *mfn_list = NULL;
 	unsigned long size;
 
+	use_brk = 0;
 	va_start = xen_start_info->mfn_list;
 	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
 	 * so make sure it is rounded up to that */
@@ -484,6 +504,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
+	use_brk = 0;
 	return 0;
 }
 #endif
@@ -510,16 +531,6 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
-static void *alloc_p2m_page(void)
-{
-	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
-}
-
-static void free_p2m_page(void *p)
-{
-	free_page((unsigned long)p);
-}
-
 /*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
@@ -624,7 +635,7 @@ static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
 		return false;
 
 	/* Boundary cross-over for the edges: */
-	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m = alloc_p2m_page();
 
 	p2m_init(p2m);
 
@@ -640,7 +651,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 
 	mid = p2m_top[topidx];
 	if (mid == p2m_mid_missing) {
-		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+		mid = alloc_p2m_page();
 
 		p2m_mid_init(mid, p2m_missing);
 
@@ -649,100 +660,6 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 	return true;
 }
 
-/*
- * Skim over the P2M tree looking at pages that are either filled with
- * INVALID_P2M_ENTRY or with 1:1 PFNs. If found, re-use that page and
- * replace the P2M leaf with a p2m_missing or p2m_identity.
- * Stick the old page in the new P2M tree location.
- */
-static bool __init early_can_reuse_p2m_middle(unsigned long set_pfn)
-{
-	unsigned topidx;
-	unsigned mididx;
-	unsigned ident_pfns;
-	unsigned inv_pfns;
-	unsigned long *p2m;
-	unsigned idx;
-	unsigned long pfn;
-
-	/* We only look when this entails a P2M middle layer */
-	if (p2m_index(set_pfn))
-		return false;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
-		topidx = p2m_top_index(pfn);
-
-		if (!p2m_top[topidx])
-			continue;
-
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
-
-		mididx = p2m_mid_index(pfn);
-		p2m = p2m_top[topidx][mididx];
-		if (!p2m)
-			continue;
-
-		if ((p2m == p2m_missing) || (p2m == p2m_identity))
-			continue;
-
-		if ((unsigned long)p2m == INVALID_P2M_ENTRY)
-			continue;
-
-		ident_pfns = 0;
-		inv_pfns = 0;
-		for (idx = 0; idx < P2M_PER_PAGE; idx++) {
-			/* IDENTITY_PFNs are 1:1 */
-			if (p2m[idx] == IDENTITY_FRAME(pfn + idx))
-				ident_pfns++;
-			else if (p2m[idx] == INVALID_P2M_ENTRY)
-				inv_pfns++;
-			else
-				break;
-		}
-		if ((ident_pfns == P2M_PER_PAGE) || (inv_pfns == P2M_PER_PAGE))
-			goto found;
-	}
-	return false;
-found:
-	/* Found one, replace old with p2m_identity or p2m_missing */
-	p2m_top[topidx][mididx] = (ident_pfns ? p2m_identity : p2m_missing);
-
-	/* Reset where we want to stick the old page in. */
-	topidx = p2m_top_index(set_pfn);
-	mididx = p2m_mid_index(set_pfn);
-
-	/* This shouldn't happen */
-	if (WARN_ON(p2m_top[topidx] == p2m_mid_missing))
-		early_alloc_p2m_middle(set_pfn);
-
-	if (WARN_ON(p2m_top[topidx][mididx] != p2m_missing))
-		return false;
-
-	p2m_init(p2m);
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn)
-{
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
-		if (!early_alloc_p2m_middle(pfn))
-			return false;
-
-		if (early_can_reuse_p2m_middle(pfn))
-			return __set_phys_to_machine(pfn, mfn);
-
-		if (!early_alloc_p2m(pfn, false /* boundary crossover OK!*/))
-			return false;
-
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
-	}
-
-	return true;
-}
-
 static void __init early_split_p2m(unsigned long pfn)
 {
 	unsigned long mididx, idx;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 29834b3..0e5f9b6 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -30,6 +30,7 @@
 #include "xen-ops.h"
 #include "vdso.h"
 #include "p2m.h"
+#include "mmu.h"
 
 /* These are code, but not functions.  Defined in entry.S */
 extern const char xen_hypervisor_callback[];
@@ -47,8 +48,18 @@ struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 /* Number of pages released from the initial allocation. */
 unsigned long xen_released_pages;
 
-/* Buffer used to remap identity mapped pages */
-unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
+/*
+ * Buffer used to remap identity mapped pages. We only need the virtual space.
+ * The physical memory for each buffer page is remapped as needed.
+ */
+#define REMAP_SIZE	(P2M_PER_PAGE - 3)
+static struct {
+	unsigned long	next_area_mfn;
+	unsigned long	target_pfn;
+	unsigned long	size;
+	unsigned long	mfns[REMAP_SIZE];
+} xen_remap_buf __initdata __aligned(PAGE_SIZE);
+static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 /* 
  * The maximum amount of extra memory compared to the base size.  The
@@ -98,63 +109,6 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 	}
 }
 
-static unsigned long __init xen_do_chunk(unsigned long start,
-					 unsigned long end, bool release)
-{
-	struct xen_memory_reservation reservation = {
-		.address_bits = 0,
-		.extent_order = 0,
-		.domid        = DOMID_SELF
-	};
-	unsigned long len = 0;
-	unsigned long pfn;
-	int ret;
-
-	for (pfn = start; pfn < end; pfn++) {
-		unsigned long frame;
-		unsigned long mfn = pfn_to_mfn(pfn);
-
-		if (release) {
-			/* Make sure pfn exists to start with */
-			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
-				continue;
-			frame = mfn;
-		} else {
-			if (mfn != INVALID_P2M_ENTRY)
-				continue;
-			frame = pfn;
-		}
-		set_xen_guest_handle(reservation.extent_start, &frame);
-		reservation.nr_extents = 1;
-
-		ret = HYPERVISOR_memory_op(release ? XENMEM_decrease_reservation : XENMEM_populate_physmap,
-					   &reservation);
-		WARN(ret != 1, "Failed to %s pfn %lx err=%d\n",
-		     release ? "release" : "populate", pfn, ret);
-
-		if (ret == 1) {
-			if (!early_set_phys_to_machine(pfn, release ? INVALID_P2M_ENTRY : frame)) {
-				if (release)
-					break;
-				set_xen_guest_handle(reservation.extent_start, &frame);
-				reservation.nr_extents = 1;
-				ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
-							   &reservation);
-				break;
-			}
-			len++;
-		} else
-			break;
-	}
-	if (len)
-		printk(KERN_INFO "%s %lx-%lx pfn range: %lu pages %s\n",
-		       release ? "Freeing" : "Populating",
-		       start, end, len,
-		       release ? "freed" : "added");
-
-	return len;
-}
-
 /*
  * Finds the next RAM pfn available in the E820 map after min_pfn.
  * This function updates min_pfn with the pfn found and returns
@@ -198,23 +152,60 @@ static unsigned long __init xen_find_pfn_range(
 	return done;
 }
 
+static int __init xen_free_mfn(unsigned long mfn)
+{
+	struct xen_memory_reservation reservation = {
+		.address_bits = 0,
+		.extent_order = 0,
+		.domid        = DOMID_SELF
+	};
+
+	set_xen_guest_handle(reservation.extent_start, &mfn);
+	reservation.nr_extents = 1;
+
+	return HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation);
+}
+
 /*
- * This releases a chunk of memory and then does the identity map. It's used as
+ * This releases a chunk of memory and then does the identity map. It's used
  * as a fallback if the remapping fails.
  */
 static void __init xen_set_identity_and_release_chunk(unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long *identity,
 	unsigned long *released)
 {
+	unsigned long len = 0;
+	unsigned long pfn, end;
+	int ret;
+
 	WARN_ON(start_pfn > end_pfn);
 
+	end = min(end_pfn, nr_pages);
+	for (pfn = start_pfn; pfn < end; pfn++) {
+		unsigned long mfn = pfn_to_mfn(pfn);
+
+		/* Make sure pfn exists to start with */
+		if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+			continue;
+
+		ret = xen_free_mfn(mfn);
+		WARN(ret != 1, "Failed to release pfn %lx err=%d\n", pfn, ret);
+
+		if (ret == 1) {
+			if (!__set_phys_to_machine(pfn, INVALID_P2M_ENTRY))
+				break;
+			len++;
+		} else
+			break;
+	}
+
 	/* Need to release pages first */
-	*released += xen_do_chunk(start_pfn, min(end_pfn, nr_pages), true);
+	*released += len;
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
 /*
- * Helper function to update both the p2m and m2p tables.
+ * Helper function to update the p2m and m2p tables and kernel mapping.
  */
 static unsigned long __init xen_update_mem_tables(unsigned long pfn,
 						  unsigned long mfn)
@@ -225,161 +216,92 @@ static unsigned long __init xen_update_mem_tables(unsigned long pfn,
 	};
 
 	/* Update p2m */
-	if (!early_set_phys_to_machine(pfn, mfn)) {
+	if (!set_phys_to_machine(pfn, mfn)) {
 		WARN(1, "Failed to set p2m mapping for pfn=%ld mfn=%ld\n",
 		     pfn, mfn);
-		return false;
+		return 0;
 	}
 
 	/* Update m2p */
 	if (HYPERVISOR_mmu_update(&update, 1, NULL, DOMID_SELF) < 0) {
 		WARN(1, "Failed to set m2p mapping for mfn=%ld pfn=%ld\n",
 		     mfn, pfn);
-		return false;
+		return 0;
+	}
+
+	/* Update kernel mapping, but not for highmem. */
+	if ((pfn << PAGE_SHIFT) >= __pa(high_memory))
+		return 1;
+
+	if (HYPERVISOR_update_va_mapping((unsigned long)__va(pfn << PAGE_SHIFT),
+					 mfn_pte(mfn, PAGE_KERNEL), 0)) {
+		WARN(1, "Failed to update kernel mapping for mfn=%ld pfn=%ld\n",
+		      mfn, pfn);
+		return 0;
 	}
 
-	return true;
+	return 1;
 }
 
 /*
  * This function updates the p2m and m2p tables with an identity map from
- * start_pfn to start_pfn+size and remaps the underlying RAM of the original
- * allocation at remap_pfn. It must do so carefully in P2M_PER_PAGE sized blocks
- * to not exhaust the reserved brk space. Doing it in properly aligned blocks
- * ensures we only allocate the minimum required leaf pages in the p2m table. It
- * copies the existing mfns from the p2m table under the 1:1 map, overwrites
- * them with the identity map and then updates the p2m and m2p tables with the
- * remapped memory.
+ * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the
+ * original allocation at remap_pfn. The information needed for remapping is
+ * saved in the memory itself to avoid the need for allocating buffers. The
+ * complete remap information is contained in a list of MFNs each containing
+ * up to REMAP_SIZE MFNs and the start target PFN for doing the remap.
+ * This enables to preserve the original mfn sequence while doing the remapping
+ * at a time when the memory management is capable of allocating virtual and
+ * physical memory in arbitrary amounts.
  */
-static unsigned long __init xen_do_set_identity_and_remap_chunk(
+static void __init xen_do_set_identity_and_remap_chunk(
         unsigned long start_pfn, unsigned long size, unsigned long remap_pfn)
 {
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn;
 	unsigned long ident_pfn_iter, remap_pfn_iter;
-	unsigned long ident_start_pfn_align, remap_start_pfn_align;
-	unsigned long ident_end_pfn_align, remap_end_pfn_align;
-	unsigned long ident_boundary_pfn, remap_boundary_pfn;
-	unsigned long ident_cnt = 0;
-	unsigned long remap_cnt = 0;
+	unsigned long ident_end_pfn = start_pfn + size;
 	unsigned long left = size;
-	unsigned long mod;
-	int i;
+	unsigned long ident_cnt = 0;
+	unsigned int i, chunk;
 
 	WARN_ON(size == 0);
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/*
-	 * Determine the proper alignment to remap memory in P2M_PER_PAGE sized
-	 * blocks. We need to keep track of both the existing pfn mapping and
-	 * the new pfn remapping.
-	 */
-	mod = start_pfn % P2M_PER_PAGE;
-	ident_start_pfn_align =
-		mod ? (start_pfn - mod + P2M_PER_PAGE) : start_pfn;
-	mod = remap_pfn % P2M_PER_PAGE;
-	remap_start_pfn_align =
-		mod ? (remap_pfn - mod + P2M_PER_PAGE) : remap_pfn;
-	mod = (start_pfn + size) % P2M_PER_PAGE;
-	ident_end_pfn_align = start_pfn + size - mod;
-	mod = (remap_pfn + size) % P2M_PER_PAGE;
-	remap_end_pfn_align = remap_pfn + size - mod;
-
-	/* Iterate over each p2m leaf node in each range */
-	for (ident_pfn_iter = ident_start_pfn_align, remap_pfn_iter = remap_start_pfn_align;
-	     ident_pfn_iter < ident_end_pfn_align && remap_pfn_iter < remap_end_pfn_align;
-	     ident_pfn_iter += P2M_PER_PAGE, remap_pfn_iter += P2M_PER_PAGE) {
-		/* Check we aren't past the end */
-		BUG_ON(ident_pfn_iter + P2M_PER_PAGE > start_pfn + size);
-		BUG_ON(remap_pfn_iter + P2M_PER_PAGE > remap_pfn + size);
-
-		/* Save p2m mappings */
-		for (i = 0; i < P2M_PER_PAGE; i++)
-			xen_remap_buf[i] = pfn_to_mfn(ident_pfn_iter + i);
-
-		/* Set identity map which will free a p2m leaf */
-		ident_cnt += set_phys_range_identity(ident_pfn_iter,
-			ident_pfn_iter + P2M_PER_PAGE);
-
-#ifdef DEBUG
-		/* Helps verify a p2m leaf has been freed */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned int pfn = ident_pfn_iter + i;
-			BUG_ON(pfn_to_mfn(pfn) != pfn);
-		}
-#endif
-		/* Now remap memory */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned long mfn = xen_remap_buf[i];
-
-			/* This will use the p2m leaf freed above */
-			if (!xen_update_mem_tables(remap_pfn_iter + i, mfn)) {
-				WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-					remap_pfn_iter + i, mfn);
-				return 0;
-			}
-
-			remap_cnt++;
-		}
-
-		left -= P2M_PER_PAGE;
-	}
+	/* Don't use memory until remapped */
+	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
 
-	/* Max boundary space possible */
-	BUG_ON(left > (P2M_PER_PAGE - 1) * 2);
+	mfn_save = virt_to_mfn(buf);
 
-	/* Now handle the boundary conditions */
-	ident_boundary_pfn = start_pfn;
-	remap_boundary_pfn = remap_pfn;
-	for (i = 0; i < left; i++) {
-		unsigned long mfn;
+	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
+	     ident_pfn_iter < ident_end_pfn;
+	     ident_pfn_iter += REMAP_SIZE, remap_pfn_iter += REMAP_SIZE) {
+		chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE;
 
-		/* These two checks move from the start to end boundaries */
-		if (ident_boundary_pfn == ident_start_pfn_align)
-			ident_boundary_pfn = ident_pfn_iter;
-		if (remap_boundary_pfn == remap_start_pfn_align)
-			remap_boundary_pfn = remap_pfn_iter;
+		/* Map first pfn to xen_remap_buf */
+		mfn = pfn_to_mfn(ident_pfn_iter);
+		set_pte_mfn(buf, mfn, PAGE_KERNEL);
 
-		/* Check we aren't past the end */
-		BUG_ON(ident_boundary_pfn >= start_pfn + size);
-		BUG_ON(remap_boundary_pfn >= remap_pfn + size);
+		/* Save mapping information in page */
+		xen_remap_buf.next_area_mfn = xen_remap_mfn;
+		xen_remap_buf.target_pfn = remap_pfn_iter;
+		xen_remap_buf.size = chunk;
+		for (i = 0; i < chunk; i++)
+			xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i);
 
-		mfn = pfn_to_mfn(ident_boundary_pfn);
+		/* New element first in list */
+		xen_remap_mfn = mfn;
 
-		if (!xen_update_mem_tables(remap_boundary_pfn, mfn)) {
-			WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-				remap_pfn_iter + i, mfn);
-			return 0;
-		}
-		remap_cnt++;
-
-		ident_boundary_pfn++;
-		remap_boundary_pfn++;
-	}
+		/* Set identity map */
+		ident_cnt += set_phys_range_identity(ident_pfn_iter,
+			ident_pfn_iter + chunk);
 
-	/* Finish up the identity map */
-	if (ident_start_pfn_align >= ident_end_pfn_align) {
-		/*
-                 * In this case we have an identity range which does not span an
-                 * aligned block so everything needs to be identity mapped here.
-                 * If we didn't check this we might remap too many pages since
-                 * the align boundaries are not meaningful in this case.
-	         */
-		ident_cnt += set_phys_range_identity(start_pfn,
-			start_pfn + size);
-	} else {
-		/* Remapped above so check each end of the chunk */
-		if (start_pfn < ident_start_pfn_align)
-			ident_cnt += set_phys_range_identity(start_pfn,
-				ident_start_pfn_align);
-		if (start_pfn + size > ident_pfn_iter)
-			ident_cnt += set_phys_range_identity(ident_pfn_iter,
-				start_pfn + size);
+		left -= chunk;
 	}
 
-	BUG_ON(ident_cnt != size);
-	BUG_ON(remap_cnt != size);
-
-	return size;
+	/* Restore old xen_remap_buf mapping */
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 }
 
 /*
@@ -396,8 +318,7 @@ static unsigned long __init xen_do_set_identity_and_remap_chunk(
 static unsigned long __init xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
-	unsigned long *identity, unsigned long *remapped,
-	unsigned long *released)
+	unsigned long *identity, unsigned long *released)
 {
 	unsigned long pfn;
 	unsigned long i = 0;
@@ -431,19 +352,12 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 		if (size > remap_range_size)
 			size = remap_range_size;
 
-		if (!xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn)) {
-			WARN(1, "Failed to remap 1:1 memory cur_pfn=%ld size=%ld remap_pfn=%ld\n",
-				cur_pfn, size, remap_pfn);
-			xen_set_identity_and_release_chunk(cur_pfn,
-				cur_pfn + left, nr_pages, identity, released);
-			break;
-		}
+		xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn);
 
 		/* Update variables to reflect new mappings. */
 		i += size;
 		remap_pfn += size;
 		*identity += size;
-		*remapped += size;
 	}
 
 	/*
@@ -464,7 +378,6 @@ static unsigned long __init xen_set_identity_and_remap(
 {
 	phys_addr_t start = 0;
 	unsigned long identity = 0;
-	unsigned long remapped = 0;
 	unsigned long last_pfn = nr_pages;
 	const struct e820entry *entry;
 	unsigned long num_released = 0;
@@ -494,8 +407,7 @@ static unsigned long __init xen_set_identity_and_remap(
 				last_pfn = xen_set_identity_and_remap_chunk(
 						list, map_size, start_pfn,
 						end_pfn, nr_pages, last_pfn,
-						&identity, &remapped,
-						&num_released);
+						&identity, &num_released);
 			start = end;
 		}
 	}
@@ -503,12 +415,84 @@ static unsigned long __init xen_set_identity_and_remap(
 	*released = num_released;
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
-	pr_info("Remapped %ld page(s), last_pfn=%ld\n", remapped,
-		last_pfn);
 	pr_info("Released %ld page(s)\n", num_released);
 
 	return last_pfn;
 }
+
+/*
+ * Remap the memory prepared in xen_do_set_identity_and_remap_chunk().
+ */
+void __init xen_remap_memory(void)
+{
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn, pfn;
+	unsigned long remapped = 0, released = 0;
+	unsigned int i, free;
+	unsigned long pfn_s = ~0UL;
+	unsigned long len = 0;
+
+	mfn_save = virt_to_mfn(buf);
+
+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
+		/* Map the remap information */
+		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
+
+		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
+
+		free = 0;
+		pfn = xen_remap_buf.target_pfn;
+		for (i = 0; i < xen_remap_buf.size; i++) {
+			mfn = xen_remap_buf.mfns[i];
+			if (!released && xen_update_mem_tables(pfn, mfn)) {
+				remapped++;
+			} else {
+				if (!released) {
+					if (pfn_s != ~0UL && len)
+						memblock_free(PFN_PHYS(pfn_s),
+							      PFN_PHYS(len));
+					pfn_s = xen_remap_buf.target_pfn;
+					len = i;
+				}
+				/* Don't free the page with our mfn list! */
+				if (i)
+					xen_free_mfn(mfn);
+				else
+					free = 1;
+				released++;
+			}
+			pfn++;
+		}
+		if (!released) {
+			if (pfn_s == ~0UL || pfn == pfn_s) {
+				pfn_s = xen_remap_buf.target_pfn;
+				len += xen_remap_buf.size;
+			} else if (pfn_s + len == xen_remap_buf.target_pfn) {
+				len += xen_remap_buf.size;
+			} else {
+				memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+				pfn_s = xen_remap_buf.target_pfn;
+				len = xen_remap_buf.size;
+			}
+		}
+
+		mfn = xen_remap_mfn;
+		xen_remap_mfn = xen_remap_buf.next_area_mfn;
+		/* Now it's save to free the page holding our data. */
+		if (free)
+			xen_free_mfn(mfn);
+	}
+
+	if (pfn_s != ~0UL && len)
+		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
+
+	pr_info("Remapped %ld page(s)\n", remapped);
+	if (released)
+		pr_info("Released %ld page(s)\n", released);
+}
+
 static unsigned long __init xen_get_max_pages(void)
 {
 	unsigned long max_pages = MAX_DOMAIN_PAGES;
@@ -616,7 +600,8 @@ char * __init xen_memory_setup(void)
 		extra_pages += max_pages - max_pfn;
 
 	/*
-	 * Set identity map on non-RAM pages and remap the underlying RAM.
+	 * Set identity map on non-RAM pages and prepare remapping the
+	 * underlying RAM.
 	 */
 	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
 					      &xen_released_pages);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 28c7e0b..5b72a06 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,6 +35,7 @@ void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
 void __init xen_arch_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FH-0001b4-Q3; Tue, 11 Nov 2014 05:44:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FE-0001aG-FU
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:00 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	A7/10-02698-F12A1645; Tue, 11 Nov 2014 05:43:59 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415684638!7989166!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10614 invoked from network); 11 Nov 2014 05:43:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:58 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A5AF5AB07;
	Tue, 11 Nov 2014 05:43:57 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:39 +0100
Message-Id: <1415684626-18590-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 1/8] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some functions in arch/x86/xen/p2m.c are used locally only. Make them
static. Rearrange the functions in p2m.c to avoid forward declarations.

While at it correct some style issues (long lines, use pr_warn()).

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |   6 -
 arch/x86/xen/p2m.c              | 347 ++++++++++++++++++++--------------------
 2 files changed, 172 insertions(+), 181 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c949923..6c16451 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -52,15 +52,9 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 				   struct gnttab_map_grant_ref *kmap_ops,
 				   struct page **pages, unsigned int count);
-extern int m2p_add_override(unsigned long mfn, struct page *page,
-			    struct gnttab_map_grant_ref *kmap_op);
 extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct gnttab_map_grant_ref *kmap_ops,
 				     struct page **pages, unsigned int count);
-extern int m2p_remove_override(struct page *page,
-			       struct gnttab_map_grant_ref *kmap_op,
-			       unsigned long mfn);
-extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 9201a38..fa75842 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -896,6 +896,61 @@ static unsigned long mfn_hash(unsigned long mfn)
 	return hash_long(mfn, M2P_OVERRIDE_HASH_SHIFT);
 }
 
+/* Add an MFN override for a particular page */
+static int m2p_add_override(unsigned long mfn, struct page *page,
+			    struct gnttab_map_grant_ref *kmap_op)
+{
+	unsigned long flags;
+	unsigned long pfn;
+	unsigned long uninitialized_var(address);
+	unsigned level;
+	pte_t *ptep = NULL;
+
+	pfn = page_to_pfn(page);
+	if (!PageHighMem(page)) {
+		address = (unsigned long)__va(pfn << PAGE_SHIFT);
+		ptep = lookup_address(address, &level);
+		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
+			 "m2p_add_override: pfn %lx not mapped", pfn))
+			return -EINVAL;
+	}
+
+	if (kmap_op != NULL) {
+		if (!PageHighMem(page)) {
+			struct multicall_space mcs =
+				xen_mc_entry(sizeof(*kmap_op));
+
+			MULTI_grant_table_op(mcs.mc,
+					GNTTABOP_map_grant_ref, kmap_op, 1);
+
+			xen_mc_issue(PARAVIRT_LAZY_MMU);
+		}
+	}
+	spin_lock_irqsave(&m2p_override_lock, flags);
+	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	/* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in
+	 * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other
+	 * pfn so that the following mfn_to_pfn(mfn) calls will return the
+	 * pfn from the m2p_override (the backend pfn) instead.
+	 * We need to do this because the pages shared by the frontend
+	 * (xen-blkfront) can be already locked (lock_page, called by
+	 * do_read_cache_page); when the userspace backend tries to use them
+	 * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
+	 * do_blockdev_direct_IO is going to try to lock the same pages
+	 * again resulting in a deadlock.
+	 * As a side effect get_user_pages_fast might not be safe on the
+	 * frontend pages while they are being shared with the backend,
+	 * because mfn_to_pfn (that ends up being called by GUPF) will
+	 * return the backend pfn rather than the frontend pfn. */
+	pfn = mfn_to_pfn_no_overrides(mfn);
+	if (get_phys_to_machine(pfn) == mfn)
+		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
+
+	return 0;
+}
+
 int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 			    struct gnttab_map_grant_ref *kmap_ops,
 			    struct page **pages, unsigned int count)
@@ -955,61 +1010,123 @@ out:
 }
 EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
 
-/* Add an MFN override for a particular page */
-int m2p_add_override(unsigned long mfn, struct page *page,
-		struct gnttab_map_grant_ref *kmap_op)
-{
-	unsigned long flags;
-	unsigned long pfn;
-	unsigned long uninitialized_var(address);
-	unsigned level;
-	pte_t *ptep = NULL;
-
-	pfn = page_to_pfn(page);
-	if (!PageHighMem(page)) {
-		address = (unsigned long)__va(pfn << PAGE_SHIFT);
-		ptep = lookup_address(address, &level);
-		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-					"m2p_add_override: pfn %lx not mapped", pfn))
-			return -EINVAL;
-	}
-
-	if (kmap_op != NULL) {
-		if (!PageHighMem(page)) {
-			struct multicall_space mcs =
-				xen_mc_entry(sizeof(*kmap_op));
-
-			MULTI_grant_table_op(mcs.mc,
-					GNTTABOP_map_grant_ref, kmap_op, 1);
-
-			xen_mc_issue(PARAVIRT_LAZY_MMU);
-		}
-	}
-	spin_lock_irqsave(&m2p_override_lock, flags);
-	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	/* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in
-	 * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other
-	 * pfn so that the following mfn_to_pfn(mfn) calls will return the
-	 * pfn from the m2p_override (the backend pfn) instead.
-	 * We need to do this because the pages shared by the frontend
-	 * (xen-blkfront) can be already locked (lock_page, called by
-	 * do_read_cache_page); when the userspace backend tries to use them
-	 * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
-	 * do_blockdev_direct_IO is going to try to lock the same pages
-	 * again resulting in a deadlock.
-	 * As a side effect get_user_pages_fast might not be safe on the
-	 * frontend pages while they are being shared with the backend,
-	 * because mfn_to_pfn (that ends up being called by GUPF) will
-	 * return the backend pfn rather than the frontend pfn. */
-	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == mfn)
-		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(m2p_add_override);
+static struct page *m2p_find_override(unsigned long mfn)
+{
+	unsigned long flags;
+	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
+	struct page *p, *ret;
+
+	ret = NULL;
+
+	spin_lock_irqsave(&m2p_override_lock, flags);
+
+	list_for_each_entry(p, bucket, lru) {
+		if (page_private(p) == mfn) {
+			ret = p;
+			break;
+		}
+	}
+
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	return ret;
+}
+
+static int m2p_remove_override(struct page *page,
+			       struct gnttab_map_grant_ref *kmap_op,
+			       unsigned long mfn)
+{
+	unsigned long flags;
+	unsigned long pfn;
+	unsigned long uninitialized_var(address);
+	unsigned level;
+	pte_t *ptep = NULL;
+
+	pfn = page_to_pfn(page);
+
+	if (!PageHighMem(page)) {
+		address = (unsigned long)__va(pfn << PAGE_SHIFT);
+		ptep = lookup_address(address, &level);
+
+		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
+			 "m2p_remove_override: pfn %lx not mapped", pfn))
+			return -EINVAL;
+	}
+
+	spin_lock_irqsave(&m2p_override_lock, flags);
+	list_del(&page->lru);
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	if (kmap_op != NULL) {
+		if (!PageHighMem(page)) {
+			struct multicall_space mcs;
+			struct gnttab_unmap_and_replace *unmap_op;
+			struct page *scratch_page = get_balloon_scratch_page();
+			unsigned long scratch_page_address = (unsigned long)
+				__va(page_to_pfn(scratch_page) << PAGE_SHIFT);
+
+			/*
+			 * It might be that we queued all the m2p grant table
+			 * hypercalls in a multicall, then m2p_remove_override
+			 * get called before the multicall has actually been
+			 * issued. In this case handle is going to -1 because
+			 * it hasn't been modified yet.
+			 */
+			if (kmap_op->handle == -1)
+				xen_mc_flush();
+			/*
+			 * Now if kmap_op->handle is negative it means that the
+			 * hypercall actually returned an error.
+			 */
+			if (kmap_op->handle == GNTST_general_error) {
+				pr_warn("m2p_remove_override: pfn %lx mfn %lx, failed to modify kernel mappings",
+					pfn, mfn);
+				put_balloon_scratch_page();
+				return -1;
+			}
+
+			xen_mc_batch();
+
+			mcs = __xen_mc_entry(
+				sizeof(struct gnttab_unmap_and_replace));
+			unmap_op = mcs.args;
+			unmap_op->host_addr = kmap_op->host_addr;
+			unmap_op->new_addr = scratch_page_address;
+			unmap_op->handle = kmap_op->handle;
+
+			MULTI_grant_table_op(mcs.mc,
+				GNTTABOP_unmap_and_replace, unmap_op, 1);
+
+			mcs = __xen_mc_entry(0);
+			MULTI_update_va_mapping(mcs.mc, scratch_page_address,
+					pfn_pte(page_to_pfn(scratch_page),
+					PAGE_KERNEL_RO), 0);
+
+			xen_mc_issue(PARAVIRT_LAZY_MMU);
+
+			kmap_op->host_addr = 0;
+			put_balloon_scratch_page();
+		}
+	}
+
+	/* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present
+	 * somewhere in this domain, even before being added to the
+	 * m2p_override (see comment above in m2p_add_override).
+	 * If there are no other entries in the m2p_override corresponding
+	 * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for
+	 * the original pfn (the one shared by the frontend): the backend
+	 * cannot do any IO on this page anymore because it has been
+	 * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of
+	 * the original pfn causes mfn_to_pfn(mfn) to return the frontend
+	 * pfn again. */
+	mfn &= ~FOREIGN_FRAME_BIT;
+	pfn = mfn_to_pfn_no_overrides(mfn);
+	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
+			m2p_find_override(mfn) == NULL)
+		set_phys_to_machine(pfn, mfn);
+
+	return 0;
+}
 
 int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 			      struct gnttab_map_grant_ref *kmap_ops,
@@ -1055,126 +1172,6 @@ out:
 }
 EXPORT_SYMBOL_GPL(clear_foreign_p2m_mapping);
 
-int m2p_remove_override(struct page *page,
-			struct gnttab_map_grant_ref *kmap_op,
-			unsigned long mfn)
-{
-	unsigned long flags;
-	unsigned long pfn;
-	unsigned long uninitialized_var(address);
-	unsigned level;
-	pte_t *ptep = NULL;
-
-	pfn = page_to_pfn(page);
-
-	if (!PageHighMem(page)) {
-		address = (unsigned long)__va(pfn << PAGE_SHIFT);
-		ptep = lookup_address(address, &level);
-
-		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-					"m2p_remove_override: pfn %lx not mapped", pfn))
-			return -EINVAL;
-	}
-
-	spin_lock_irqsave(&m2p_override_lock, flags);
-	list_del(&page->lru);
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	if (kmap_op != NULL) {
-		if (!PageHighMem(page)) {
-			struct multicall_space mcs;
-			struct gnttab_unmap_and_replace *unmap_op;
-			struct page *scratch_page = get_balloon_scratch_page();
-			unsigned long scratch_page_address = (unsigned long)
-				__va(page_to_pfn(scratch_page) << PAGE_SHIFT);
-
-			/*
-			 * It might be that we queued all the m2p grant table
-			 * hypercalls in a multicall, then m2p_remove_override
-			 * get called before the multicall has actually been
-			 * issued. In this case handle is going to -1 because
-			 * it hasn't been modified yet.
-			 */
-			if (kmap_op->handle == -1)
-				xen_mc_flush();
-			/*
-			 * Now if kmap_op->handle is negative it means that the
-			 * hypercall actually returned an error.
-			 */
-			if (kmap_op->handle == GNTST_general_error) {
-				printk(KERN_WARNING "m2p_remove_override: "
-						"pfn %lx mfn %lx, failed to modify kernel mappings",
-						pfn, mfn);
-				put_balloon_scratch_page();
-				return -1;
-			}
-
-			xen_mc_batch();
-
-			mcs = __xen_mc_entry(
-					sizeof(struct gnttab_unmap_and_replace));
-			unmap_op = mcs.args;
-			unmap_op->host_addr = kmap_op->host_addr;
-			unmap_op->new_addr = scratch_page_address;
-			unmap_op->handle = kmap_op->handle;
-
-			MULTI_grant_table_op(mcs.mc,
-					GNTTABOP_unmap_and_replace, unmap_op, 1);
-
-			mcs = __xen_mc_entry(0);
-			MULTI_update_va_mapping(mcs.mc, scratch_page_address,
-					pfn_pte(page_to_pfn(scratch_page),
-					PAGE_KERNEL_RO), 0);
-
-			xen_mc_issue(PARAVIRT_LAZY_MMU);
-
-			kmap_op->host_addr = 0;
-			put_balloon_scratch_page();
-		}
-	}
-
-	/* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present
-	 * somewhere in this domain, even before being added to the
-	 * m2p_override (see comment above in m2p_add_override).
-	 * If there are no other entries in the m2p_override corresponding
-	 * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for
-	 * the original pfn (the one shared by the frontend): the backend
-	 * cannot do any IO on this page anymore because it has been
-	 * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of
-	 * the original pfn causes mfn_to_pfn(mfn) to return the frontend
-	 * pfn again. */
-	mfn &= ~FOREIGN_FRAME_BIT;
-	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
-			m2p_find_override(mfn) == NULL)
-		set_phys_to_machine(pfn, mfn);
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(m2p_remove_override);
-
-struct page *m2p_find_override(unsigned long mfn)
-{
-	unsigned long flags;
-	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
-	struct page *p, *ret;
-
-	ret = NULL;
-
-	spin_lock_irqsave(&m2p_override_lock, flags);
-
-	list_for_each_entry(p, bucket, lru) {
-		if (page_private(p) == mfn) {
-			ret = p;
-			break;
-		}
-	}
-
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	return ret;
-}
-
 unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
 {
 	struct page *p = m2p_find_override(mfn);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 05:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 05:44:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo4FJ-0001bZ-8S; Tue, 11 Nov 2014 05:44:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo4FG-0001aZ-Om
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 05:44:02 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	62/E2-28296-222A1645; Tue, 11 Nov 2014 05:44:02 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415684639!9263860!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20673 invoked from network); 11 Nov 2014 05:43:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 05:43:59 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0D3A8ACAA;
	Tue, 11 Nov 2014 05:43:59 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com
Date: Tue, 11 Nov 2014 06:43:43 +0100
Message-Id: <1415684626-18590-6-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V3 5/8] x86: Introduce function to get pmd entry
	pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduces lookup_pmd_address() to get the address of the pmd entry
related to a virtual address in the current address space. This
function is needed for support of a virtual mapped sparse p2m list
in xen pv domains.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/pgtable_types.h |  1 +
 arch/x86/mm/pageattr.c               | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0778964..d83f5e7 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -396,6 +396,7 @@ static inline void update_page_count(int level, unsigned long pages) { }
 extern pte_t *lookup_address(unsigned long address, unsigned int *level);
 extern pte_t *lookup_address_in_pgd(pgd_t *pgd, unsigned long address,
 				    unsigned int *level);
+extern pmd_t *lookup_pmd_address(unsigned long address);
 extern phys_addr_t slow_virt_to_phys(void *__address);
 extern int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
 				   unsigned numpages, unsigned long page_flags);
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 36de293..1298108 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -384,6 +384,26 @@ static pte_t *_lookup_address_cpa(struct cpa_data *cpa, unsigned long address,
 }
 
 /*
+ * Lookup the PMD entry for a virtual address. Return a pointer to the entry
+ * or NULL if not present.
+ */
+pmd_t *lookup_pmd_address(unsigned long address)
+{
+	pgd_t *pgd;
+	pud_t *pud;
+
+	pgd = pgd_offset_k(address);
+	if (pgd_none(*pgd))
+		return NULL;
+
+	pud = pud_offset(pgd, address);
+	if (pud_none(*pud) || pud_large(*pud) || !pud_present(*pud))
+		return NULL;
+
+	return pmd_offset(pud, address);
+}
+
+/*
  * This is necessary because __pa() does not work on some
  * kinds of memory, like vmalloc() or the alloc_remap()
  * areas on 32-bit NUMA systems.  The percpu areas can
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 06:33:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 06:33:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo50f-0003R2-1o; Tue, 11 Nov 2014 06:33:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xo50d-0003Qx-Dj
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 06:32:59 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	39/EA-14727-A9DA1645; Tue, 11 Nov 2014 06:32:58 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415687577!7555128!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3491 invoked from network); 11 Nov 2014 06:32:57 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-206.messagelabs.com with SMTP;
	11 Nov 2014 06:32:57 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Nov 2014 22:32:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,359,1413270000"; d="scan'208";a="634887888"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.131.43])
	([10.238.131.43])
	by orsmga002.jf.intel.com with ESMTP; 10 Nov 2014 22:32:54 -0800
Message-ID: <5461AD94.2070008@intel.com>
Date: Tue, 11 Nov 2014 14:32:52 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
In-Reply-To: <545CB64E02000078000459CD@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/7 19:08, Jan Beulich wrote:
>>>> On 07.11.14 at 11:27, <tiejun.chen@intel.com> wrote:
>> Are you saying Xen restrict some BDFs specific to emulate some devices?
>> But I don't see these associated codes.
>
> I didn't say so. All I said that some of the SBDFs are being used by
> them.
>
>>>> --- a/xen/include/xen/iommu.h
>>>> +++ b/xen/include/xen/iommu.h
>>>> @@ -158,14 +158,14 @@ struct iommu_ops {
>>>>         void (*crash_shutdown)(void);
>>>>         void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int page_count);
>>>>         void (*iotlb_flush_all)(struct domain *d);
>>>> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
>>>> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct domain *, void *);
>>>>         void (*dump_p2m_table)(struct domain *d);
>>>>     };
>>>>
>>>>     void iommu_suspend(void);
>>>>     void iommu_resume(void);
>>>>     void iommu_crash_shutdown(void);
>>>> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain *, void *);
>>>
>>> I don't see why these generic interfaces would need to change;
>>> the only thing that would seem to need changing is the callback
>>> function (and of course the context passed to it).
>>
>> I'm not 100% sure if we can call current->domain in all scenarios. If
>> you can help me confirm this I'd really like to remove this change :)
>> Now I assume this should be true as follows:
>
> Which is wrong, and not what I said. Instead you should pass the
> domain as part of the context that gets made available to the
> callback function.

Okay I will try to go there.

>
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -1540,6 +1540,34 @@ int iommu_do_pci_domctl(
>>            }
>>            break;
>>
>> +    case XEN_DOMCTL_set_rdm:
>> +    {
>> +        struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
>> +        struct xen_guest_pcidev_info *pcidevs;
>> +        int i;
>> +
>> +        pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>> +                                domctl->u.set_rdm.num_pcidevs);
>> +        if ( pcidevs == NULL )
>> +        {
>> +            return -ENOMEM;
>> +        }
>> +
>> +        for ( i = 0; i < xdsr->num_pcidevs; ++i )
>> +        {
>> +            if ( __copy_from_guest_offset(pcidevs, xdsr->pcidevs, i, 1) )
>> +            {
>> +                xfree(pcidevs);
>> +                return -EFAULT;
>> +            }
>> +        }
>
> I don't see the need for a loop here. And you definitely can't use the
> double-underscore-prefixed variant the way you do.

Do you mean this line?

copy_from_guest_offset(pcidevs, xdsr->pcidevs, 0, 
xdsr->num_pcidevs*sizeof(xen_guest_pcidev_info_t))

>
>> --- a/xen/include/asm-x86/hvm/domain.h
>> +++ b/xen/include/asm-x86/hvm/domain.h
>> @@ -90,6 +90,10 @@ struct hvm_domain {
>>        /* Cached CF8 for guest PCI config cycles */
>>        uint32_t                pci_cf8;
>>
>> +    uint32_t                pci_rdmforce;
>
> I still don't see why this is a uint32_t.

How about bool_t?

>
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -484,6 +484,24 @@ struct xen_domctl_assign_device {
>>    typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>>    DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
>>
>> +struct xen_guest_pcidev_info {
>> +    uint8_t func;
>> +    uint8_t dev;
>> +    uint8_t bus;
>> +    int domain;
>> +    int rdmforce;
>> +};
>
> Please see struct physdev_pci_device_add for how to properly and
> space efficiently express what you need. And of course I'd expect

Yes. Actually I ever considered this point but I just think we may need 
to keep a complete set of fields.

You're right and anywhere what we should do is focusing on on-demand.

> the code to actually use all fields you specify here - neither domain
> (which really ought to be named segment if it is what I think it is
> meant to be) nor rdmforce are being used anywhere. Plus - again -
> just "force" would be sufficient as a name, provided the field is
> needed at all.

Okay I can use 'force' directly.

In Xen side we have 'bool_t', but we have 'bool' in tools side. So how 
to define this in xen/include/public/domctl.h?

>
>> +struct xen_domctl_set_rdm {
>> +    uint32_t  pci_rdmforce;
>
> Same comment as on the field added to "struct hvm_domain".

Ditto.

>
>> +    uint32_t  num_pcidevs;
>> +    XEN_GUEST_HANDLE(xen_guest_pcidev_info_t) pcidevs;
>
> Did you _at all_ look at any of the other domctls when adding this?
> There's not a single use of XEN_GUEST_HANDLE() in the whole file.

Looks I should do this,

XEN_GUEST_HANDLE_64(xen_guest_pcidev_info_t) pcidevs;

>
>> @@ -1118,7 +1137,8 @@ struct xen_domctl {
>>            struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>>            struct xen_domctl_vnuma             vnuma;
>>            struct xen_domctl_psr_cmt_op        psr_cmt_op;
>> -        uint8_t                             pad[128];
>> +        struct xen_domctl_set_rdm           set_rdm;
>> +        uint8_t                             pad[112];
>
> Why are you altering the padding size here?

As I understand we should shrink this pad when we introduce new filed, 
shouldn't we?

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 06:33:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 06:33:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo50f-0003R2-1o; Tue, 11 Nov 2014 06:33:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xo50d-0003Qx-Dj
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 06:32:59 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	39/EA-14727-A9DA1645; Tue, 11 Nov 2014 06:32:58 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415687577!7555128!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3491 invoked from network); 11 Nov 2014 06:32:57 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-206.messagelabs.com with SMTP;
	11 Nov 2014 06:32:57 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Nov 2014 22:32:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,359,1413270000"; d="scan'208";a="634887888"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.131.43])
	([10.238.131.43])
	by orsmga002.jf.intel.com with ESMTP; 10 Nov 2014 22:32:54 -0800
Message-ID: <5461AD94.2070008@intel.com>
Date: Tue, 11 Nov 2014 14:32:52 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
In-Reply-To: <545CB64E02000078000459CD@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/7 19:08, Jan Beulich wrote:
>>>> On 07.11.14 at 11:27, <tiejun.chen@intel.com> wrote:
>> Are you saying Xen restrict some BDFs specific to emulate some devices?
>> But I don't see these associated codes.
>
> I didn't say so. All I said that some of the SBDFs are being used by
> them.
>
>>>> --- a/xen/include/xen/iommu.h
>>>> +++ b/xen/include/xen/iommu.h
>>>> @@ -158,14 +158,14 @@ struct iommu_ops {
>>>>         void (*crash_shutdown)(void);
>>>>         void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int page_count);
>>>>         void (*iotlb_flush_all)(struct domain *d);
>>>> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
>>>> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct domain *, void *);
>>>>         void (*dump_p2m_table)(struct domain *d);
>>>>     };
>>>>
>>>>     void iommu_suspend(void);
>>>>     void iommu_resume(void);
>>>>     void iommu_crash_shutdown(void);
>>>> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain *, void *);
>>>
>>> I don't see why these generic interfaces would need to change;
>>> the only thing that would seem to need changing is the callback
>>> function (and of course the context passed to it).
>>
>> I'm not 100% sure if we can call current->domain in all scenarios. If
>> you can help me confirm this I'd really like to remove this change :)
>> Now I assume this should be true as follows:
>
> Which is wrong, and not what I said. Instead you should pass the
> domain as part of the context that gets made available to the
> callback function.

Okay I will try to go there.

>
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -1540,6 +1540,34 @@ int iommu_do_pci_domctl(
>>            }
>>            break;
>>
>> +    case XEN_DOMCTL_set_rdm:
>> +    {
>> +        struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
>> +        struct xen_guest_pcidev_info *pcidevs;
>> +        int i;
>> +
>> +        pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>> +                                domctl->u.set_rdm.num_pcidevs);
>> +        if ( pcidevs == NULL )
>> +        {
>> +            return -ENOMEM;
>> +        }
>> +
>> +        for ( i = 0; i < xdsr->num_pcidevs; ++i )
>> +        {
>> +            if ( __copy_from_guest_offset(pcidevs, xdsr->pcidevs, i, 1) )
>> +            {
>> +                xfree(pcidevs);
>> +                return -EFAULT;
>> +            }
>> +        }
>
> I don't see the need for a loop here. And you definitely can't use the
> double-underscore-prefixed variant the way you do.

Do you mean this line?

copy_from_guest_offset(pcidevs, xdsr->pcidevs, 0, 
xdsr->num_pcidevs*sizeof(xen_guest_pcidev_info_t))

>
>> --- a/xen/include/asm-x86/hvm/domain.h
>> +++ b/xen/include/asm-x86/hvm/domain.h
>> @@ -90,6 +90,10 @@ struct hvm_domain {
>>        /* Cached CF8 for guest PCI config cycles */
>>        uint32_t                pci_cf8;
>>
>> +    uint32_t                pci_rdmforce;
>
> I still don't see why this is a uint32_t.

How about bool_t?

>
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -484,6 +484,24 @@ struct xen_domctl_assign_device {
>>    typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>>    DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
>>
>> +struct xen_guest_pcidev_info {
>> +    uint8_t func;
>> +    uint8_t dev;
>> +    uint8_t bus;
>> +    int domain;
>> +    int rdmforce;
>> +};
>
> Please see struct physdev_pci_device_add for how to properly and
> space efficiently express what you need. And of course I'd expect

Yes. Actually I ever considered this point but I just think we may need 
to keep a complete set of fields.

You're right and anywhere what we should do is focusing on on-demand.

> the code to actually use all fields you specify here - neither domain
> (which really ought to be named segment if it is what I think it is
> meant to be) nor rdmforce are being used anywhere. Plus - again -
> just "force" would be sufficient as a name, provided the field is
> needed at all.

Okay I can use 'force' directly.

In Xen side we have 'bool_t', but we have 'bool' in tools side. So how 
to define this in xen/include/public/domctl.h?

>
>> +struct xen_domctl_set_rdm {
>> +    uint32_t  pci_rdmforce;
>
> Same comment as on the field added to "struct hvm_domain".

Ditto.

>
>> +    uint32_t  num_pcidevs;
>> +    XEN_GUEST_HANDLE(xen_guest_pcidev_info_t) pcidevs;
>
> Did you _at all_ look at any of the other domctls when adding this?
> There's not a single use of XEN_GUEST_HANDLE() in the whole file.

Looks I should do this,

XEN_GUEST_HANDLE_64(xen_guest_pcidev_info_t) pcidevs;

>
>> @@ -1118,7 +1137,8 @@ struct xen_domctl {
>>            struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>>            struct xen_domctl_vnuma             vnuma;
>>            struct xen_domctl_psr_cmt_op        psr_cmt_op;
>> -        uint8_t                             pad[128];
>> +        struct xen_domctl_set_rdm           set_rdm;
>> +        uint8_t                             pad[112];
>
> Why are you altering the padding size here?

As I understand we should shrink this pad when we introduce new filed, 
shouldn't we?

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 07:50:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 07:50:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo6D0-0004Tw-OG; Tue, 11 Nov 2014 07:49:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xo6Cz-0004Tr-0I
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 07:49:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B1/E7-09842-C9FB1645; Tue, 11 Nov 2014 07:49:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415692186!11790238!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26056 invoked from network); 11 Nov 2014 07:49:47 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-21.messagelabs.com with SMTP;
	11 Nov 2014 07:49:47 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 10 Nov 2014 23:47:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,359,1413270000"; d="scan'208";a="634913811"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.131.43])
	([10.238.131.43])
	by orsmga002.jf.intel.com with ESMTP; 10 Nov 2014 23:49:44 -0800
Message-ID: <5461BF97.1070709@intel.com>
Date: Tue, 11 Nov 2014 15:49:43 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>	<5450BE27020000780004304A@mail.emea.novell.com>	<5451AC56.7010303@intel.com>	<54521100020000780004363A@mail.emea.novell.com>	<545320F2.5030103@intel.com>	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>	<545354500200007800043D94@mail.emea.novell.com>	<5457174C.8020400@intel.com>	<5457515102000078000443B0@mail.emea.novell.com>	<54574D8F.8060407@intel.com>	<54575E2D0200007800044443@mail.emea.novell.com>	<545767C4.7070806@intel.com>	<5457787002000078000445C7@mail.emea.novell.com>	<54576DF7.8060408@intel.com>	<545784830200007800044627@mail.emea.novell.com>	<54585EAA.20904@intel.com>	<545894610200007800044A5B@mail.emea.novell.com>	<545992A2.8070309@intel.com>	<545A57AD02000078000C1037@mail.emea.novell.com>	<545B3F4A.5070808@intel.com>	<545B562F02000078000453FB@mail.emea.novell.com>	<545C9E97.4040800@intel.com>	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com>
In-Reply-To: <5461AD94.2070008@intel.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>>>> --- a/xen/include/xen/iommu.h
>>>>> +++ b/xen/include/xen/iommu.h
>>>>> @@ -158,14 +158,14 @@ struct iommu_ops {
>>>>>         void (*crash_shutdown)(void);
>>>>>         void (*iotlb_flush)(struct domain *d, unsigned long gfn,
>>>>> unsigned int page_count);
>>>>>         void (*iotlb_flush_all)(struct domain *d);
>>>>> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
>>>>> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct
>>>>> domain *, void *);
>>>>>         void (*dump_p2m_table)(struct domain *d);
>>>>>     };
>>>>>
>>>>>     void iommu_suspend(void);
>>>>>     void iommu_resume(void);
>>>>>     void iommu_crash_shutdown(void);
>>>>> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
>>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain
>>>>> *, void *);
>>>>
>>>> I don't see why these generic interfaces would need to change;
>>>> the only thing that would seem to need changing is the callback
>>>> function (and of course the context passed to it).
>>>
>>> I'm not 100% sure if we can call current->domain in all scenarios. If
>>> you can help me confirm this I'd really like to remove this change :)
>>> Now I assume this should be true as follows:
>>
>> Which is wrong, and not what I said. Instead you should pass the
>> domain as part of the context that gets made available to the
>> callback function.
>
> Okay I will try to go there.
>

Are you saying this change?

@@ -898,14 +899,36 @@ int 
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
      int rc = 0;
+    int i, j;
+    u16 bdf, pt_bdf;
+    struct domain *d = ctxt->domain;

-    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+    for_each_rmrr_device ( rmrr, bdf, i )
      {
-        rc = func(PFN_DOWN(rmrr->base_address),
-                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
-                  ctxt);
-        if ( rc )
-            break;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            rc = func(PFN_DOWN(rmrr->base_address),
+                      PFN_UP(rmrr->end_address) -
+                      PFN_DOWN(rmrr->base_address),
+                      ctxt);
+            if ( rc )
+                break;
+        }
+        else
+        {
+            for ( j = 0; j < d->arch.hvm_domain.num_pcidevs; j++ )
+            {

But,

dmar.c: In function 'intel_iommu_get_reserved_device_memory'"
dmar.c:904:28: error: dereferencing 'void *' pointer [-Werror]
      struct domain *d = ctxt->domain;
                             ^
dmar.c:904:28: error: request for member 'domain' in something not a 
structure or union
cc1: all warnings being treated as errors
make[6]: *** [dmar.o] Error 1
make[6]: *** Waiting for unfinished jobs.

Unless we move all check inside each callback functions.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 07:50:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 07:50:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo6D0-0004Tw-OG; Tue, 11 Nov 2014 07:49:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xo6Cz-0004Tr-0I
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 07:49:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B1/E7-09842-C9FB1645; Tue, 11 Nov 2014 07:49:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415692186!11790238!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26056 invoked from network); 11 Nov 2014 07:49:47 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-21.messagelabs.com with SMTP;
	11 Nov 2014 07:49:47 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 10 Nov 2014 23:47:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,359,1413270000"; d="scan'208";a="634913811"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.131.43])
	([10.238.131.43])
	by orsmga002.jf.intel.com with ESMTP; 10 Nov 2014 23:49:44 -0800
Message-ID: <5461BF97.1070709@intel.com>
Date: Tue, 11 Nov 2014 15:49:43 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>	<5450BE27020000780004304A@mail.emea.novell.com>	<5451AC56.7010303@intel.com>	<54521100020000780004363A@mail.emea.novell.com>	<545320F2.5030103@intel.com>	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>	<545354500200007800043D94@mail.emea.novell.com>	<5457174C.8020400@intel.com>	<5457515102000078000443B0@mail.emea.novell.com>	<54574D8F.8060407@intel.com>	<54575E2D0200007800044443@mail.emea.novell.com>	<545767C4.7070806@intel.com>	<5457787002000078000445C7@mail.emea.novell.com>	<54576DF7.8060408@intel.com>	<545784830200007800044627@mail.emea.novell.com>	<54585EAA.20904@intel.com>	<545894610200007800044A5B@mail.emea.novell.com>	<545992A2.8070309@intel.com>	<545A57AD02000078000C1037@mail.emea.novell.com>	<545B3F4A.5070808@intel.com>	<545B562F02000078000453FB@mail.emea.novell.com>	<545C9E97.4040800@intel.com>	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com>
In-Reply-To: <5461AD94.2070008@intel.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>>>> --- a/xen/include/xen/iommu.h
>>>>> +++ b/xen/include/xen/iommu.h
>>>>> @@ -158,14 +158,14 @@ struct iommu_ops {
>>>>>         void (*crash_shutdown)(void);
>>>>>         void (*iotlb_flush)(struct domain *d, unsigned long gfn,
>>>>> unsigned int page_count);
>>>>>         void (*iotlb_flush_all)(struct domain *d);
>>>>> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
>>>>> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct
>>>>> domain *, void *);
>>>>>         void (*dump_p2m_table)(struct domain *d);
>>>>>     };
>>>>>
>>>>>     void iommu_suspend(void);
>>>>>     void iommu_resume(void);
>>>>>     void iommu_crash_shutdown(void);
>>>>> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
>>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain
>>>>> *, void *);
>>>>
>>>> I don't see why these generic interfaces would need to change;
>>>> the only thing that would seem to need changing is the callback
>>>> function (and of course the context passed to it).
>>>
>>> I'm not 100% sure if we can call current->domain in all scenarios. If
>>> you can help me confirm this I'd really like to remove this change :)
>>> Now I assume this should be true as follows:
>>
>> Which is wrong, and not what I said. Instead you should pass the
>> domain as part of the context that gets made available to the
>> callback function.
>
> Okay I will try to go there.
>

Are you saying this change?

@@ -898,14 +899,36 @@ int 
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
      int rc = 0;
+    int i, j;
+    u16 bdf, pt_bdf;
+    struct domain *d = ctxt->domain;

-    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+    for_each_rmrr_device ( rmrr, bdf, i )
      {
-        rc = func(PFN_DOWN(rmrr->base_address),
-                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
-                  ctxt);
-        if ( rc )
-            break;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            rc = func(PFN_DOWN(rmrr->base_address),
+                      PFN_UP(rmrr->end_address) -
+                      PFN_DOWN(rmrr->base_address),
+                      ctxt);
+            if ( rc )
+                break;
+        }
+        else
+        {
+            for ( j = 0; j < d->arch.hvm_domain.num_pcidevs; j++ )
+            {

But,

dmar.c: In function 'intel_iommu_get_reserved_device_memory'"
dmar.c:904:28: error: dereferencing 'void *' pointer [-Werror]
      struct domain *d = ctxt->domain;
                             ^
dmar.c:904:28: error: request for member 'domain' in something not a 
structure or union
cc1: all warnings being treated as errors
make[6]: *** [dmar.o] Error 1
make[6]: *** Waiting for unfinished jobs.

Unless we move all check inside each callback functions.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 07:58:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 07:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo6La-0004i9-TH; Tue, 11 Nov 2014 07:58:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hanjiunit@gmail.com>) id 1XnwDJ-0005LW-1d
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 21:09:29 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	91/69-17694-88921645; Mon, 10 Nov 2014 21:09:28 +0000
X-Env-Sender: hanjiunit@gmail.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415653767!11634070!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22408 invoked from network); 10 Nov 2014 21:09:27 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 21:09:27 -0000
Received: by mail-wg0-f42.google.com with SMTP id k14so9937490wgh.1
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 13:09:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=xoPy3cP9c+H4h+0DfrDVT9fR5thExYASxNfyDNSA5Vo=;
	b=oQQ8g5EXTBMy3In/z/gZMBq8qAoI8hAsA+vy0xRfw7ym4GMZaQnCLDp3x+rEdtw/NZ
	2eY/gxjgwq/DkVOO+S+qwQL//dM9tIKYuQBfRayAtiCy/yoWWiweL2NncZJlLoVSgzjJ
	V5ZDVAenQBSWVBrvDaszrdbgP4pQ9H+et380E9Z0yJ6ibS8meVTpMeaEzPLL2nzQwHbk
	6eUFk2EIsVh3dg5/jBbyRDP1zshosGelqiAlvEQQW4PuTEFBkvebNrHHuwb0VHBoJrY7
	Kh8MBn+XCm4LnD14tH3WOFxm1OFWl9+UUYsbsu26I3sgaar0cBKN3ouD9CSQNqCZC4q9
	gZtw==
MIME-Version: 1.0
X-Received: by 10.181.8.72 with SMTP id di8mr43334667wid.1.1415653766911; Mon,
	10 Nov 2014 13:09:26 -0800 (PST)
Received: by 10.216.179.65 with HTTP; Mon, 10 Nov 2014 13:09:26 -0800 (PST)
In-Reply-To: <CA+J4q6eSw0RCaK3WSAbSVOXx3s6ErTq-CmgijjyiJqNjQgrVQg@mail.gmail.com>
References: <CA+J4q6eSw0RCaK3WSAbSVOXx3s6ErTq-CmgijjyiJqNjQgrVQg@mail.gmail.com>
Date: Mon, 10 Nov 2014 13:09:26 -0800
Message-ID: <CA+J4q6fLSzA+Rw51r7FYy2o6x8+ZTpX6W7U7G526Q-OSgSHtGA@mail.gmail.com>
From: hanji unit <hanjiunit@gmail.com>
To: win-pv-devel@lists.xenproject.org, xen-devel@lists.xen.org
X-Mailman-Approved-At: Tue, 11 Nov 2014 07:58:41 +0000
Subject: Re: [Xen-devel] Windows Paravirtualization for Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4548300889961879979=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4548300889961879979==
Content-Type: multipart/alternative; boundary=001a1134cdeee6db7c0507879366

--001a1134cdeee6db7c0507879366
Content-Type: text/plain; charset=UTF-8

Adding main Xen development list too.

On Mon, Nov 10, 2014 at 1:00 PM, hanji unit <hanjiunit@gmail.com> wrote:

> Hello. I am looking at windows Paravirtualization support and I've seen a
> few projects including:
>
> 1) win-pvdrivers by James Harper (
> http://wiki.xen.org/wiki/Xen_Windows_GplPv)
> 2) Windows PV-Driver Subproject (
> http://wiki.xen.org/wiki/Xen_FAQ_Drivers,_Windows#What_is_the_Windows_PV_Driver_Subproject.2Fteam.3F
> )
> 3) Open Sourced XenServer Windows PV Drivers (https://github.com/xenserver
> )
>
> Are these 3 projects all different or do any of them refer to the same
> projects? If different, which is the one that is most widely supported and
> used that has future support plans? I am trying to write to XenStore from
> Windows and looking to modify some of these drivers if needed, but dont
> want to work on a dead project.
>
> Thanks.
>

--001a1134cdeee6db7c0507879366
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Adding main Xen development list too.<br><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Mon, Nov 10, 2014 at 1:00 PM, h=
anji unit <span dir=3D"ltr">&lt;<a href=3D"mailto:hanjiunit@gmail.com" targ=
et=3D"_blank">hanjiunit@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div><div><div><div>Hello. I am lookin=
g at windows Paravirtualization support and I&#39;ve seen a few projects in=
cluding:<br><br></div>1) win-pvdrivers by James Harper (<a href=3D"http://w=
iki.xen.org/wiki/Xen_Windows_GplPv" target=3D"_blank">http://wiki.xen.org/w=
iki/Xen_Windows_GplPv</a>)<br></div>2)
 Windows PV-Driver Subproject=20
(<a href=3D"http://wiki.xen.org/wiki/Xen_FAQ_Drivers,_Windows#What_is_the_W=
indows_PV_Driver_Subproject.2Fteam.3F" target=3D"_blank">http://wiki.xen.or=
g/wiki/Xen_FAQ_Drivers,_Windows#What_is_the_Windows_PV_Driver_Subproject.2F=
team.3F</a>)<br></div>3) Open Sourced XenServer Windows PV Drivers (<a href=
=3D"https://github.com/xenserver" target=3D"_blank">https://github.com/xens=
erver</a>)<br><br></div>Are
 these 3 projects all different or do any of them refer to the same=20
projects? If different, which is the one that is most widely supported=20
and used that has future support plans? I am trying to write to XenStore
 from Windows and looking to modify some of these drivers if needed, but
 dont want to work on a dead project.<br><br></div>Thanks.</div>
</blockquote></div><br></div></div>

--001a1134cdeee6db7c0507879366--


--===============4548300889961879979==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4548300889961879979==--


From xen-devel-bounces@lists.xen.org Tue Nov 11 07:58:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 07:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo6La-0004i9-TH; Tue, 11 Nov 2014 07:58:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hanjiunit@gmail.com>) id 1XnwDJ-0005LW-1d
	for xen-devel@lists.xen.org; Mon, 10 Nov 2014 21:09:29 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	91/69-17694-88921645; Mon, 10 Nov 2014 21:09:28 +0000
X-Env-Sender: hanjiunit@gmail.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415653767!11634070!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22408 invoked from network); 10 Nov 2014 21:09:27 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Nov 2014 21:09:27 -0000
Received: by mail-wg0-f42.google.com with SMTP id k14so9937490wgh.1
	for <xen-devel@lists.xen.org>; Mon, 10 Nov 2014 13:09:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=xoPy3cP9c+H4h+0DfrDVT9fR5thExYASxNfyDNSA5Vo=;
	b=oQQ8g5EXTBMy3In/z/gZMBq8qAoI8hAsA+vy0xRfw7ym4GMZaQnCLDp3x+rEdtw/NZ
	2eY/gxjgwq/DkVOO+S+qwQL//dM9tIKYuQBfRayAtiCy/yoWWiweL2NncZJlLoVSgzjJ
	V5ZDVAenQBSWVBrvDaszrdbgP4pQ9H+et380E9Z0yJ6ibS8meVTpMeaEzPLL2nzQwHbk
	6eUFk2EIsVh3dg5/jBbyRDP1zshosGelqiAlvEQQW4PuTEFBkvebNrHHuwb0VHBoJrY7
	Kh8MBn+XCm4LnD14tH3WOFxm1OFWl9+UUYsbsu26I3sgaar0cBKN3ouD9CSQNqCZC4q9
	gZtw==
MIME-Version: 1.0
X-Received: by 10.181.8.72 with SMTP id di8mr43334667wid.1.1415653766911; Mon,
	10 Nov 2014 13:09:26 -0800 (PST)
Received: by 10.216.179.65 with HTTP; Mon, 10 Nov 2014 13:09:26 -0800 (PST)
In-Reply-To: <CA+J4q6eSw0RCaK3WSAbSVOXx3s6ErTq-CmgijjyiJqNjQgrVQg@mail.gmail.com>
References: <CA+J4q6eSw0RCaK3WSAbSVOXx3s6ErTq-CmgijjyiJqNjQgrVQg@mail.gmail.com>
Date: Mon, 10 Nov 2014 13:09:26 -0800
Message-ID: <CA+J4q6fLSzA+Rw51r7FYy2o6x8+ZTpX6W7U7G526Q-OSgSHtGA@mail.gmail.com>
From: hanji unit <hanjiunit@gmail.com>
To: win-pv-devel@lists.xenproject.org, xen-devel@lists.xen.org
X-Mailman-Approved-At: Tue, 11 Nov 2014 07:58:41 +0000
Subject: Re: [Xen-devel] Windows Paravirtualization for Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4548300889961879979=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4548300889961879979==
Content-Type: multipart/alternative; boundary=001a1134cdeee6db7c0507879366

--001a1134cdeee6db7c0507879366
Content-Type: text/plain; charset=UTF-8

Adding main Xen development list too.

On Mon, Nov 10, 2014 at 1:00 PM, hanji unit <hanjiunit@gmail.com> wrote:

> Hello. I am looking at windows Paravirtualization support and I've seen a
> few projects including:
>
> 1) win-pvdrivers by James Harper (
> http://wiki.xen.org/wiki/Xen_Windows_GplPv)
> 2) Windows PV-Driver Subproject (
> http://wiki.xen.org/wiki/Xen_FAQ_Drivers,_Windows#What_is_the_Windows_PV_Driver_Subproject.2Fteam.3F
> )
> 3) Open Sourced XenServer Windows PV Drivers (https://github.com/xenserver
> )
>
> Are these 3 projects all different or do any of them refer to the same
> projects? If different, which is the one that is most widely supported and
> used that has future support plans? I am trying to write to XenStore from
> Windows and looking to modify some of these drivers if needed, but dont
> want to work on a dead project.
>
> Thanks.
>

--001a1134cdeee6db7c0507879366
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Adding main Xen development list too.<br><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Mon, Nov 10, 2014 at 1:00 PM, h=
anji unit <span dir=3D"ltr">&lt;<a href=3D"mailto:hanjiunit@gmail.com" targ=
et=3D"_blank">hanjiunit@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div><div><div><div>Hello. I am lookin=
g at windows Paravirtualization support and I&#39;ve seen a few projects in=
cluding:<br><br></div>1) win-pvdrivers by James Harper (<a href=3D"http://w=
iki.xen.org/wiki/Xen_Windows_GplPv" target=3D"_blank">http://wiki.xen.org/w=
iki/Xen_Windows_GplPv</a>)<br></div>2)
 Windows PV-Driver Subproject=20
(<a href=3D"http://wiki.xen.org/wiki/Xen_FAQ_Drivers,_Windows#What_is_the_W=
indows_PV_Driver_Subproject.2Fteam.3F" target=3D"_blank">http://wiki.xen.or=
g/wiki/Xen_FAQ_Drivers,_Windows#What_is_the_Windows_PV_Driver_Subproject.2F=
team.3F</a>)<br></div>3) Open Sourced XenServer Windows PV Drivers (<a href=
=3D"https://github.com/xenserver" target=3D"_blank">https://github.com/xens=
erver</a>)<br><br></div>Are
 these 3 projects all different or do any of them refer to the same=20
projects? If different, which is the one that is most widely supported=20
and used that has future support plans? I am trying to write to XenStore
 from Windows and looking to modify some of these drivers if needed, but
 dont want to work on a dead project.<br><br></div>Thanks.</div>
</blockquote></div><br></div></div>

--001a1134cdeee6db7c0507879366--


--===============4548300889961879979==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4548300889961879979==--


From xen-devel-bounces@lists.xen.org Tue Nov 11 08:03:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo6QK-0005Ud-Np; Tue, 11 Nov 2014 08:03:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xo6QJ-0005UY-Bo
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 08:03:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	17/EC-09842-6D2C1645; Tue, 11 Nov 2014 08:03:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415693012!3782630!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19797 invoked from network); 11 Nov 2014 08:03:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 08:03:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,359,1413244800"; d="scan'208";a="191478926"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 03:03:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xo6QF-00038n-CD;
	Tue, 11 Nov 2014 08:03:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xo6QF-0006wi-5K;
	Tue, 11 Nov 2014 08:03:31 +0000
Date: Tue, 11 Nov 2014 08:03:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31473-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31473: 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 31473 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31473/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31409
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31409

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
baseline version:
 xen                  816f5bb1f0740be8355e1be6cc24edf09547d984

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Julien Grall <julien.grall@linaro.org>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Steven Haigh <netwiz@crc.id.au>
  Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
+ branch=xen-unstable
+ revision=e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   816f5bb..e6fa63d  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 08:03:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo6QK-0005Ud-Np; Tue, 11 Nov 2014 08:03:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xo6QJ-0005UY-Bo
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 08:03:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	17/EC-09842-6D2C1645; Tue, 11 Nov 2014 08:03:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415693012!3782630!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19797 invoked from network); 11 Nov 2014 08:03:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 08:03:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,359,1413244800"; d="scan'208";a="191478926"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 03:03:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xo6QF-00038n-CD;
	Tue, 11 Nov 2014 08:03:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xo6QF-0006wi-5K;
	Tue, 11 Nov 2014 08:03:31 +0000
Date: Tue, 11 Nov 2014 08:03:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31473-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31473: 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 31473 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31473/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31409
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31409

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
baseline version:
 xen                  816f5bb1f0740be8355e1be6cc24edf09547d984

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Julien Grall <julien.grall@linaro.org>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Steven Haigh <netwiz@crc.id.au>
  Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
+ branch=xen-unstable
+ revision=e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   816f5bb..e6fa63d  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 08:05:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo6SI-0005bA-Df; Tue, 11 Nov 2014 08:05: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 1Xo6SG-0005b3-5Q
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 08:05:36 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	09/A1-16982-F43C1645; Tue, 11 Nov 2014 08:05:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415693134!11738725!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31924 invoked from network); 11 Nov 2014 08:05:34 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 08:05:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 08:05:34 +0000
Message-Id: <5461D15C02000078000464D7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 08:05:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>,<pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
In-Reply-To: <54611A86.4000200@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.11.14 at 21:05, <sflist@ihonk.com> wrote:
> On 11/10/2014 0:51, Jan Beulich wrote:
>> Raising the kernel log level to maximum too would have helped.
> 
> Okay, I've done that and the output is here, let me know if you have any 
> preferred logging flags instead:
> 
> http://pastebin.com/M3yvWNTT 

Hmm, I can't spot any further useful messages there, which may be
due to the log having got partly garbled.

>> Regardless of that, the first device showing anomalies here appears
>> to be the UHCI controller:
>>
>>      [  147.415713] usb 7-1: reset low-speed USB device number 2 using 
> uhci_hcd
>>
>> while booting the guest.
> 
> I assume this is related to the USB device (a keyboard) I'm passing 
> through to the domU.

But not by passing through the HCD I assume, since the log only
shows the VGA card being consumed by pciback?

>> And these
>>
>>      [  199.775209] pcieport 0000:00:03.0: AER: Multiple Corrected error 
> received: id=0018
>>      [  199.775238] pcieport 0000:00:03.0: PCIe Bus Error: 
> severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID)
>>      [  199.775251] pcieport 0000:00:03.0:   device [8086:340a] error 
> status/mask=00001100/00002000
>>      [  199.775255] pcieport 0000:00:03.0:    [ 8] RELAY_NUM Rollover
>>      [  199.775258] pcieport 0000:00:03.0:    [12] Replay Timer Timeout
>>
>> hint at a problem in the system's design. 00:03.0 is the parent bridge
>> of 02:00.0 (and from what I can tell that's the only device behind that
>> bridge), and hence the above messages can only reasonably have
>> their origin at the passed through VGA device.
> 
> You are correct that the VGA card is the only device on 03.0:
> [...]
> What problem in the system's design does this hint at?

It's not the topology that I referred to, but last events reported in
the quoted log lines above. Such should not be happening repeatedly
on a properly functioning system.

>> IOW it may well be that
>> you were just lucky that things worked earlier on.
> 
> Certainly possible but this is a very common machine in the corporate 
> world -- a Lenovo ThinkStation D20 running the X58 chipset. If it's an 
> inherent defect in the machine and somebody else hasn't already tripped 
> over it I would be very surprised.

Except that pass-through, and especially VGA pass-through, aren't
being used by that many people.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 08:05:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo6SI-0005bA-Df; Tue, 11 Nov 2014 08:05: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 1Xo6SG-0005b3-5Q
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 08:05:36 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	09/A1-16982-F43C1645; Tue, 11 Nov 2014 08:05:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415693134!11738725!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31924 invoked from network); 11 Nov 2014 08:05:34 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 08:05:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 08:05:34 +0000
Message-Id: <5461D15C02000078000464D7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 08:05:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>,<pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
In-Reply-To: <54611A86.4000200@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.11.14 at 21:05, <sflist@ihonk.com> wrote:
> On 11/10/2014 0:51, Jan Beulich wrote:
>> Raising the kernel log level to maximum too would have helped.
> 
> Okay, I've done that and the output is here, let me know if you have any 
> preferred logging flags instead:
> 
> http://pastebin.com/M3yvWNTT 

Hmm, I can't spot any further useful messages there, which may be
due to the log having got partly garbled.

>> Regardless of that, the first device showing anomalies here appears
>> to be the UHCI controller:
>>
>>      [  147.415713] usb 7-1: reset low-speed USB device number 2 using 
> uhci_hcd
>>
>> while booting the guest.
> 
> I assume this is related to the USB device (a keyboard) I'm passing 
> through to the domU.

But not by passing through the HCD I assume, since the log only
shows the VGA card being consumed by pciback?

>> And these
>>
>>      [  199.775209] pcieport 0000:00:03.0: AER: Multiple Corrected error 
> received: id=0018
>>      [  199.775238] pcieport 0000:00:03.0: PCIe Bus Error: 
> severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID)
>>      [  199.775251] pcieport 0000:00:03.0:   device [8086:340a] error 
> status/mask=00001100/00002000
>>      [  199.775255] pcieport 0000:00:03.0:    [ 8] RELAY_NUM Rollover
>>      [  199.775258] pcieport 0000:00:03.0:    [12] Replay Timer Timeout
>>
>> hint at a problem in the system's design. 00:03.0 is the parent bridge
>> of 02:00.0 (and from what I can tell that's the only device behind that
>> bridge), and hence the above messages can only reasonably have
>> their origin at the passed through VGA device.
> 
> You are correct that the VGA card is the only device on 03.0:
> [...]
> What problem in the system's design does this hint at?

It's not the topology that I referred to, but last events reported in
the quoted log lines above. Such should not be happening repeatedly
on a properly functioning system.

>> IOW it may well be that
>> you were just lucky that things worked earlier on.
> 
> Certainly possible but this is a very common machine in the corporate 
> world -- a Lenovo ThinkStation D20 running the X58 chipset. If it's an 
> inherent defect in the machine and somebody else hasn't already tripped 
> over it I would be very surprised.

Except that pass-through, and especially VGA pass-through, aren't
being used by that many people.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 08:10:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08:10:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo6WL-0005mW-5q; Tue, 11 Nov 2014 08:09:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xo6WJ-0005mQ-S2
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 08:09:47 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	78/FE-28296-A44C1645; Tue, 11 Nov 2014 08:09:46 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415693383!11728637!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3295 invoked from network); 11 Nov 2014 08:09:45 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 08:09:45 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 01:09:42 -0700
Message-Id: <5462343C020000660007880A@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 01:07:24 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "George Dunlap" <dunlapg@umich.edu>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
In-Reply-To: <CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 11/11/2014 at 01:04 AM, in message
<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>, George
Dunlap <dunlapg@umich.edu> wrote: 
> On Mon, Nov 10, 2014 at 8:17 AM, Chunyan Liu <cyliu@suse.com> wrote: 
>  
> > 
> > 3. Function Implementation 
> > 
> >    libxl_domain_snapshot_create: 
> >        1). check args validation 
> >        2). save domain memory through save-domain 
> >        3). take disk snapshot by qmp command (if domian is active) or
> qemu-img 
> >            command (if domain is inactive). 
>  
> By "active" here, do you you mean "live" (vs paused)?
Means the domain is started (no matter is running or paused).
vs (libvirt defines a domain but not started).
Here,  I should update this to:
3). take disk snapshot by qmp command
libxl only handles active domain.

>  
> >    libxl_domain_snapshot_delete: 
> >        1). check args validation 
> >        2). remove memory state file. 
> >        3). delete disk snapshot. (for internal disk snapshot, through qmp 
> >            command or qemu-img command) 
>  
> Out of curiosity, why is this necessary?  Is libxl keeping track of 
> the snapshots somewhere?  Or qemu? 
>  
> Or to put it a different way, since the caller knows the filenames, 
> why can't the caller just erase the files themselves?

Ian asks the same question. The only reason I propose an API is:
xl and libvirt can share the code. And in future, when support many other disk
backend types, there is much repeated code. But as Ian mentioned in
last version, for handling many disk backend types, maybe better placed in
libxlu. Well, if both of you object, I'll remove this API.

- Chunyan

>  
>  -George 
>  
> _______________________________________________ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 08:10:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08:10:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo6WL-0005mW-5q; Tue, 11 Nov 2014 08:09:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xo6WJ-0005mQ-S2
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 08:09:47 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	78/FE-28296-A44C1645; Tue, 11 Nov 2014 08:09:46 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415693383!11728637!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3295 invoked from network); 11 Nov 2014 08:09:45 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 08:09:45 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 01:09:42 -0700
Message-Id: <5462343C020000660007880A@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 01:07:24 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "George Dunlap" <dunlapg@umich.edu>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
In-Reply-To: <CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 11/11/2014 at 01:04 AM, in message
<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>, George
Dunlap <dunlapg@umich.edu> wrote: 
> On Mon, Nov 10, 2014 at 8:17 AM, Chunyan Liu <cyliu@suse.com> wrote: 
>  
> > 
> > 3. Function Implementation 
> > 
> >    libxl_domain_snapshot_create: 
> >        1). check args validation 
> >        2). save domain memory through save-domain 
> >        3). take disk snapshot by qmp command (if domian is active) or
> qemu-img 
> >            command (if domain is inactive). 
>  
> By "active" here, do you you mean "live" (vs paused)?
Means the domain is started (no matter is running or paused).
vs (libvirt defines a domain but not started).
Here,  I should update this to:
3). take disk snapshot by qmp command
libxl only handles active domain.

>  
> >    libxl_domain_snapshot_delete: 
> >        1). check args validation 
> >        2). remove memory state file. 
> >        3). delete disk snapshot. (for internal disk snapshot, through qmp 
> >            command or qemu-img command) 
>  
> Out of curiosity, why is this necessary?  Is libxl keeping track of 
> the snapshots somewhere?  Or qemu? 
>  
> Or to put it a different way, since the caller knows the filenames, 
> why can't the caller just erase the files themselves?

Ian asks the same question. The only reason I propose an API is:
xl and libvirt can share the code. And in future, when support many other disk
backend types, there is much repeated code. But as Ian mentioned in
last version, for handling many disk backend types, maybe better placed in
libxlu. Well, if both of you object, I'll remove this API.

- Chunyan

>  
>  -George 
>  
> _______________________________________________ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 08:47:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08: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 1Xo76H-0006Ly-Og; Tue, 11 Nov 2014 08:46:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo76G-0006Lt-Sb
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 08:46:56 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	60/22-14727-FFCC1645; Tue, 11 Nov 2014 08:46:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415695614!8353134!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10420 invoked from network); 11 Nov 2014 08:46:55 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 08:46:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 08:46:54 +0000
Message-Id: <5461DB0C02000078000464FF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 08:46:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
	<1415042078-8337-3-git-send-email-konrad.wilk@oracle.com>
	<5458BA790200007800044B58@mail.emea.novell.com>
	<20141110210214.GA21090@laptop.dumpdata.com>
In-Reply-To: <20141110210214.GA21090@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [for-xen-4.5 v9 2/2] dpci: Replace tasklet with an
 softirq (v12)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.11.14 at 22:02, <konrad.wilk@oracle.com> wrote:
> On Tue, Nov 04, 2014 at 10:37:29AM +0000, Jan Beulich wrote:
>> >>> On 03.11.14 at 20:14, <konrad.wilk@oracle.com> wrote:
>> > +/*
>> > + * Should only be called from hvm_do_IRQ_dpci. We use the
>> 
>> This statement together with the comment in pt_pirq_softirq_active()
>> is at least confusing: If the function is to be called in only one place,
>> there shouldn't be a second place where its use is being suggested.
>> Plus, a function with such required limited use would very likely better
>> not be a separate function at all.
> 
> Could you explain your rationale for it please?

I explained the why in what is still being quoted above.

> I am of course OK changing it, but when reading this patch and having most 
> of the functions that deal with the new code in one place - makes it easier
> to read.

Some pieces of code are necessarily scattered around, so one more
wouldn't be a big deal. But I see you re-worded that comment now,
and with that I don't mind the function remaining where it is.

Hence
Reviewed-by: Jan Beulich <jbeulich@suse.com>

But please re-send properly paired with patch 1/2, to avoid mixing
up versions when committing (it's already confusing that this one
says v9 and v12 in the subject, while the patch history is at v13).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 08:47:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08: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 1Xo76H-0006Ly-Og; Tue, 11 Nov 2014 08:46:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo76G-0006Lt-Sb
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 08:46:56 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	60/22-14727-FFCC1645; Tue, 11 Nov 2014 08:46:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415695614!8353134!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10420 invoked from network); 11 Nov 2014 08:46:55 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 08:46:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 08:46:54 +0000
Message-Id: <5461DB0C02000078000464FF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 08:46:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415042078-8337-1-git-send-email-konrad.wilk@oracle.com>
	<1415042078-8337-3-git-send-email-konrad.wilk@oracle.com>
	<5458BA790200007800044B58@mail.emea.novell.com>
	<20141110210214.GA21090@laptop.dumpdata.com>
In-Reply-To: <20141110210214.GA21090@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [for-xen-4.5 v9 2/2] dpci: Replace tasklet with an
 softirq (v12)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.11.14 at 22:02, <konrad.wilk@oracle.com> wrote:
> On Tue, Nov 04, 2014 at 10:37:29AM +0000, Jan Beulich wrote:
>> >>> On 03.11.14 at 20:14, <konrad.wilk@oracle.com> wrote:
>> > +/*
>> > + * Should only be called from hvm_do_IRQ_dpci. We use the
>> 
>> This statement together with the comment in pt_pirq_softirq_active()
>> is at least confusing: If the function is to be called in only one place,
>> there shouldn't be a second place where its use is being suggested.
>> Plus, a function with such required limited use would very likely better
>> not be a separate function at all.
> 
> Could you explain your rationale for it please?

I explained the why in what is still being quoted above.

> I am of course OK changing it, but when reading this patch and having most 
> of the functions that deal with the new code in one place - makes it easier
> to read.

Some pieces of code are necessarily scattered around, so one more
wouldn't be a big deal. But I see you re-worded that comment now,
and with that I don't mind the function remaining where it is.

Hence
Reviewed-by: Jan Beulich <jbeulich@suse.com>

But please re-send properly paired with patch 1/2, to avoid mixing
up versions when committing (it's already confusing that this one
says v9 and v12 in the subject, while the patch history is at v13).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 08:56:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08:56:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7F9-0006a6-Ri; Tue, 11 Nov 2014 08:56:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xo7F7-0006Zy-8A
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 08:56:07 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	EE/E0-28865-42FC1645; Tue, 11 Nov 2014 08:56:04 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415696162!8355208!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11144 invoked from network); 11 Nov 2014 08:56:03 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 08:56:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415696162; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : Subject :
	Content-Type : Content-Transfer-Encoding;
	bh=XWZnxqEbQPwIWIyid64K1gqBrTBXjXYC5qFS57G2J5o=;
	b=psiuRL8cG8Xm1m9YCa/RCTift4ZsPzy2+/d0iKFmttO8H6aWKN1J/SAslKReb6zyzYlfFGwGe6L+g3bXKXaZ/qVOUttZXaqRV+IU2cpBFALObNs/tSymP2L2X8cZVoP+FCS5rUpLOuYcDsCHahe606fiaAiEQjLbczTy5FYDSJs=
Received: from [10.0.0.112] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Tue, 11 Nov 2014 00:56:01 -0800
	id 00000000000305F4.5461CF21.00007C9C
Message-ID: <5461CF21.7050206@ihonk.com>
Date: Tue, 11 Nov 2014 00:56:01 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] configure: error: Unable to find Python development
	headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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'm trying to do some bisection to find the cause of my VGA passthrough 
issues, but gcc 4.9 is throwing too many warnings, all of which are 
interpreted as errors, which kills the build. So I'm trying to compile 
with 4.8. Unfortunately, ./configure chokes because it says it can't 
find Python.h. However, I do have it installed on my system. (Indeed, I 
have no problem building RELEASE-4.4.1 and 4.5rc-1 with gcc 4.9, it's 
just problematic at various points between those two versions.)

steve@g2:~/git/xen$ ./configure APPEND_INCLUDES=/usr/include/python2.7/
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
Will build the following subsystems:
   xen
   kernels
   tools
   stubdom
   docs
configure: creating ./config.status
config.status: creating ./config/Toplevel.mk
=== configuring in tools (/home/steve/git/xen/tools)
configure: running /bin/bash ./configure --disable-option-checking 
'--prefix=/usr/local'  'APPEND_INCLUDES=/usr/include/python2.7/' 
--cache-file=/dev/null --srcdir=.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for bison... /usr/bin/bison
checking for flex... /usr/bin/flex
checking for perl... /usr/bin/perl
checking for ocamlc... no
checking for ocaml... no
checking for ocamldep... no
checking for ocamlmktop... no
checking for ocamlmklib... no
checking for ocamldoc... no
checking for ocamlbuild... no
checking for ocamlfind... ocamlfind
checking for checkpolicy... no
checking for bash... /bin/bash
checking for python... /usr/bin/python
checking for python version >= 2.3 ... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for python-config... /usr/bin/python-config
checking Python.h usability... no
checking Python.h presence... no
checking for Python.h... no
configure: error: Unable to find Python development headers
configure: error: ./configure failed for tools

steve@g2:~/git/xen$ ll /usr/include/python2.7/Python.h
-rw-r--r-- 1 root root 4329 Oct  7 11:48 /usr/include/python2.7/Python.h

I'm on Debian Jessie. Any idea what I might be doing wrong?

Thanks!

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 08:56:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08:56:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7F9-0006a6-Ri; Tue, 11 Nov 2014 08:56:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xo7F7-0006Zy-8A
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 08:56:07 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	EE/E0-28865-42FC1645; Tue, 11 Nov 2014 08:56:04 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415696162!8355208!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11144 invoked from network); 11 Nov 2014 08:56:03 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 08:56:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1415696162; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : Subject :
	Content-Type : Content-Transfer-Encoding;
	bh=XWZnxqEbQPwIWIyid64K1gqBrTBXjXYC5qFS57G2J5o=;
	b=psiuRL8cG8Xm1m9YCa/RCTift4ZsPzy2+/d0iKFmttO8H6aWKN1J/SAslKReb6zyzYlfFGwGe6L+g3bXKXaZ/qVOUttZXaqRV+IU2cpBFALObNs/tSymP2L2X8cZVoP+FCS5rUpLOuYcDsCHahe606fiaAiEQjLbczTy5FYDSJs=
Received: from [10.0.0.112] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Tue, 11 Nov 2014 00:56:01 -0800
	id 00000000000305F4.5461CF21.00007C9C
Message-ID: <5461CF21.7050206@ihonk.com>
Date: Tue, 11 Nov 2014 00:56:01 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] configure: error: Unable to find Python development
	headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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'm trying to do some bisection to find the cause of my VGA passthrough 
issues, but gcc 4.9 is throwing too many warnings, all of which are 
interpreted as errors, which kills the build. So I'm trying to compile 
with 4.8. Unfortunately, ./configure chokes because it says it can't 
find Python.h. However, I do have it installed on my system. (Indeed, I 
have no problem building RELEASE-4.4.1 and 4.5rc-1 with gcc 4.9, it's 
just problematic at various points between those two versions.)

steve@g2:~/git/xen$ ./configure APPEND_INCLUDES=/usr/include/python2.7/
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
Will build the following subsystems:
   xen
   kernels
   tools
   stubdom
   docs
configure: creating ./config.status
config.status: creating ./config/Toplevel.mk
=== configuring in tools (/home/steve/git/xen/tools)
configure: running /bin/bash ./configure --disable-option-checking 
'--prefix=/usr/local'  'APPEND_INCLUDES=/usr/include/python2.7/' 
--cache-file=/dev/null --srcdir=.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for bison... /usr/bin/bison
checking for flex... /usr/bin/flex
checking for perl... /usr/bin/perl
checking for ocamlc... no
checking for ocaml... no
checking for ocamldep... no
checking for ocamlmktop... no
checking for ocamlmklib... no
checking for ocamldoc... no
checking for ocamlbuild... no
checking for ocamlfind... ocamlfind
checking for checkpolicy... no
checking for bash... /bin/bash
checking for python... /usr/bin/python
checking for python version >= 2.3 ... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for python-config... /usr/bin/python-config
checking Python.h usability... no
checking Python.h presence... no
checking for Python.h... no
configure: error: Unable to find Python development headers
configure: error: ./configure failed for tools

steve@g2:~/git/xen$ ll /usr/include/python2.7/Python.h
-rw-r--r-- 1 root root 4329 Oct  7 11:48 /usr/include/python2.7/Python.h

I'm on Debian Jessie. Any idea what I might be doing wrong?

Thanks!

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 08:59:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7IN-0006h7-GR; Tue, 11 Nov 2014 08:59:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo7IM-0006h2-88
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 08:59:26 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	0E/FA-17694-DEFC1645; Tue, 11 Nov 2014 08:59:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415696364!11740210!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31797 invoked from network); 11 Nov 2014 08:59:24 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 08:59:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 08:59:24 +0000
Message-Id: <5461DDFB020000780004650C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 08:59:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com>
In-Reply-To: <5461AD94.2070008@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 07:32, <tiejun.chen@intel.com> wrote:
> On 2014/11/7 19:08, Jan Beulich wrote:
>>>>> On 07.11.14 at 11:27, <tiejun.chen@intel.com> wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -1540,6 +1540,34 @@ int iommu_do_pci_domctl(
>>>            }
>>>            break;
>>>
>>> +    case XEN_DOMCTL_set_rdm:
>>> +    {
>>> +        struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
>>> +        struct xen_guest_pcidev_info *pcidevs;
>>> +        int i;
>>> +
>>> +        pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>>> +                                domctl->u.set_rdm.num_pcidevs);
>>> +        if ( pcidevs == NULL )
>>> +        {
>>> +            return -ENOMEM;
>>> +        }
>>> +
>>> +        for ( i = 0; i < xdsr->num_pcidevs; ++i )
>>> +        {
>>> +            if ( __copy_from_guest_offset(pcidevs, xdsr->pcidevs, i, 1) )
>>> +            {
>>> +                xfree(pcidevs);
>>> +                return -EFAULT;
>>> +            }
>>> +        }
>>
>> I don't see the need for a loop here. And you definitely can't use the
>> double-underscore-prefixed variant the way you do.
> 
> Do you mean this line?
> 
> copy_from_guest_offset(pcidevs, xdsr->pcidevs, 0, 
> xdsr->num_pcidevs*sizeof(xen_guest_pcidev_info_t))

Almost:

    copy_from_guest(pcidevs, xdsr->pcidevs, xdsr->num_pcidevs * sizeof(*pcidevs))

>>> --- a/xen/include/asm-x86/hvm/domain.h
>>> +++ b/xen/include/asm-x86/hvm/domain.h
>>> @@ -90,6 +90,10 @@ struct hvm_domain {
>>>        /* Cached CF8 for guest PCI config cycles */
>>>        uint32_t                pci_cf8;
>>>
>>> +    uint32_t                pci_rdmforce;
>>
>> I still don't see why this is a uint32_t.
> 
> How about bool_t?

Exactly.

> In Xen side we have 'bool_t', but we have 'bool' in tools side. So how 
> to define this in xen/include/public/domctl.h?

Have a structure field named e.g. "flags" and a #define consuming
exactly one bit of it. Just like it's being done everywhere else.

>>> @@ -1118,7 +1137,8 @@ struct xen_domctl {
>>>            struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>>>            struct xen_domctl_vnuma             vnuma;
>>>            struct xen_domctl_psr_cmt_op        psr_cmt_op;
>>> -        uint8_t                             pad[128];
>>> +        struct xen_domctl_set_rdm           set_rdm;
>>> +        uint8_t                             pad[112];
>>
>> Why are you altering the padding size here?
> 
> As I understand we should shrink this pad when we introduce new filed, 
> shouldn't we?

You realize that this is inside a union?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 08:59:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 08:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7IN-0006h7-GR; Tue, 11 Nov 2014 08:59:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo7IM-0006h2-88
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 08:59:26 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	0E/FA-17694-DEFC1645; Tue, 11 Nov 2014 08:59:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415696364!11740210!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31797 invoked from network); 11 Nov 2014 08:59:24 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 08:59:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 08:59:24 +0000
Message-Id: <5461DDFB020000780004650C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 08:59:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54509A8A.9060606@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com>
In-Reply-To: <5461AD94.2070008@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 07:32, <tiejun.chen@intel.com> wrote:
> On 2014/11/7 19:08, Jan Beulich wrote:
>>>>> On 07.11.14 at 11:27, <tiejun.chen@intel.com> wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -1540,6 +1540,34 @@ int iommu_do_pci_domctl(
>>>            }
>>>            break;
>>>
>>> +    case XEN_DOMCTL_set_rdm:
>>> +    {
>>> +        struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
>>> +        struct xen_guest_pcidev_info *pcidevs;
>>> +        int i;
>>> +
>>> +        pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>>> +                                domctl->u.set_rdm.num_pcidevs);
>>> +        if ( pcidevs == NULL )
>>> +        {
>>> +            return -ENOMEM;
>>> +        }
>>> +
>>> +        for ( i = 0; i < xdsr->num_pcidevs; ++i )
>>> +        {
>>> +            if ( __copy_from_guest_offset(pcidevs, xdsr->pcidevs, i, 1) )
>>> +            {
>>> +                xfree(pcidevs);
>>> +                return -EFAULT;
>>> +            }
>>> +        }
>>
>> I don't see the need for a loop here. And you definitely can't use the
>> double-underscore-prefixed variant the way you do.
> 
> Do you mean this line?
> 
> copy_from_guest_offset(pcidevs, xdsr->pcidevs, 0, 
> xdsr->num_pcidevs*sizeof(xen_guest_pcidev_info_t))

Almost:

    copy_from_guest(pcidevs, xdsr->pcidevs, xdsr->num_pcidevs * sizeof(*pcidevs))

>>> --- a/xen/include/asm-x86/hvm/domain.h
>>> +++ b/xen/include/asm-x86/hvm/domain.h
>>> @@ -90,6 +90,10 @@ struct hvm_domain {
>>>        /* Cached CF8 for guest PCI config cycles */
>>>        uint32_t                pci_cf8;
>>>
>>> +    uint32_t                pci_rdmforce;
>>
>> I still don't see why this is a uint32_t.
> 
> How about bool_t?

Exactly.

> In Xen side we have 'bool_t', but we have 'bool' in tools side. So how 
> to define this in xen/include/public/domctl.h?

Have a structure field named e.g. "flags" and a #define consuming
exactly one bit of it. Just like it's being done everywhere else.

>>> @@ -1118,7 +1137,8 @@ struct xen_domctl {
>>>            struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>>>            struct xen_domctl_vnuma             vnuma;
>>>            struct xen_domctl_psr_cmt_op        psr_cmt_op;
>>> -        uint8_t                             pad[128];
>>> +        struct xen_domctl_set_rdm           set_rdm;
>>> +        uint8_t                             pad[112];
>>
>> Why are you altering the padding size here?
> 
> As I understand we should shrink this pad when we introduce new filed, 
> shouldn't we?

You realize that this is inside a union?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:03:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:03:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7Lt-0006xv-Eg; Tue, 11 Nov 2014 09:03:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo7Ls-0006xq-Dy
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:03:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FE/92-24532-7C0D1645; Tue, 11 Nov 2014 09:03:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415696583!3798398!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10015 invoked from network); 11 Nov 2014 09:03:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 09:03:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 09:03:02 +0000
Message-Id: <5461DED50200007800046520@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 09:03:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
In-Reply-To: <5461BF97.1070709@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 08:49, <tiejun.chen@intel.com> wrote:
>>>>>> --- a/xen/include/xen/iommu.h
>>>>>> +++ b/xen/include/xen/iommu.h
>>>>>> @@ -158,14 +158,14 @@ struct iommu_ops {
>>>>>>         void (*crash_shutdown)(void);
>>>>>>         void (*iotlb_flush)(struct domain *d, unsigned long gfn,
>>>>>> unsigned int page_count);
>>>>>>         void (*iotlb_flush_all)(struct domain *d);
>>>>>> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
>>>>>> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct
>>>>>> domain *, void *);
>>>>>>         void (*dump_p2m_table)(struct domain *d);
>>>>>>     };
>>>>>>
>>>>>>     void iommu_suspend(void);
>>>>>>     void iommu_resume(void);
>>>>>>     void iommu_crash_shutdown(void);
>>>>>> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
>>>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain
>>>>>> *, void *);
>>>>>
>>>>> I don't see why these generic interfaces would need to change;
>>>>> the only thing that would seem to need changing is the callback
>>>>> function (and of course the context passed to it).
>>>>
>>>> I'm not 100% sure if we can call current->domain in all scenarios. If
>>>> you can help me confirm this I'd really like to remove this change :)
>>>> Now I assume this should be true as follows:
>>>
>>> Which is wrong, and not what I said. Instead you should pass the
>>> domain as part of the context that gets made available to the
>>> callback function.
>>
>> Okay I will try to go there.
>>
> 
> Are you saying this change?
> 
> @@ -898,14 +899,36 @@ int 
> intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>   {
>       struct acpi_rmrr_unit *rmrr;
>       int rc = 0;
> +    int i, j;
> +    u16 bdf, pt_bdf;
> +    struct domain *d = ctxt->domain;
> 
> -    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
> +    for_each_rmrr_device ( rmrr, bdf, i )
>       {
> -        rc = func(PFN_DOWN(rmrr->base_address),
> -                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
> -                  ctxt);
> -        if ( rc )
> -            break;
> +        if ( d->arch.hvm_domain.pci_force )
> +        {
> +            rc = func(PFN_DOWN(rmrr->base_address),
> +                      PFN_UP(rmrr->end_address) -
> +                      PFN_DOWN(rmrr->base_address),
> +                      ctxt);
> +            if ( rc )
> +                break;
> +        }
> +        else
> +        {
> +            for ( j = 0; j < d->arch.hvm_domain.num_pcidevs; j++ )
> +            {
> 
> But,
> 
> dmar.c: In function 'intel_iommu_get_reserved_device_memory'"
> dmar.c:904:28: error: dereferencing 'void *' pointer [-Werror]
>       struct domain *d = ctxt->domain;
>                              ^
> dmar.c:904:28: error: request for member 'domain' in something not a 
> structure or union
> cc1: all warnings being treated as errors
> make[6]: *** [dmar.o] Error 1
> make[6]: *** Waiting for unfinished jobs.
> 
> Unless we move all check inside each callback functions.

That's what you should do imo, albeit I realize that the comparing
of the specific SBDFs will need additional consideration.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:03:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:03:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7Lt-0006xv-Eg; Tue, 11 Nov 2014 09:03:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo7Ls-0006xq-Dy
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:03:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FE/92-24532-7C0D1645; Tue, 11 Nov 2014 09:03:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415696583!3798398!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10015 invoked from network); 11 Nov 2014 09:03:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 09:03:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 09:03:02 +0000
Message-Id: <5461DED50200007800046520@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 09:03:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
In-Reply-To: <5461BF97.1070709@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 08:49, <tiejun.chen@intel.com> wrote:
>>>>>> --- a/xen/include/xen/iommu.h
>>>>>> +++ b/xen/include/xen/iommu.h
>>>>>> @@ -158,14 +158,14 @@ struct iommu_ops {
>>>>>>         void (*crash_shutdown)(void);
>>>>>>         void (*iotlb_flush)(struct domain *d, unsigned long gfn,
>>>>>> unsigned int page_count);
>>>>>>         void (*iotlb_flush_all)(struct domain *d);
>>>>>> -    int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
>>>>>> +    int (*get_reserved_device_memory)(iommu_grdm_t *, struct
>>>>>> domain *, void *);
>>>>>>         void (*dump_p2m_table)(struct domain *d);
>>>>>>     };
>>>>>>
>>>>>>     void iommu_suspend(void);
>>>>>>     void iommu_resume(void);
>>>>>>     void iommu_crash_shutdown(void);
>>>>>> -int iommu_get_reserved_device_memory(iommu_grdm_t *, void *);
>>>>>> +int iommu_get_reserved_device_memory(iommu_grdm_t *, struct domain
>>>>>> *, void *);
>>>>>
>>>>> I don't see why these generic interfaces would need to change;
>>>>> the only thing that would seem to need changing is the callback
>>>>> function (and of course the context passed to it).
>>>>
>>>> I'm not 100% sure if we can call current->domain in all scenarios. If
>>>> you can help me confirm this I'd really like to remove this change :)
>>>> Now I assume this should be true as follows:
>>>
>>> Which is wrong, and not what I said. Instead you should pass the
>>> domain as part of the context that gets made available to the
>>> callback function.
>>
>> Okay I will try to go there.
>>
> 
> Are you saying this change?
> 
> @@ -898,14 +899,36 @@ int 
> intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>   {
>       struct acpi_rmrr_unit *rmrr;
>       int rc = 0;
> +    int i, j;
> +    u16 bdf, pt_bdf;
> +    struct domain *d = ctxt->domain;
> 
> -    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
> +    for_each_rmrr_device ( rmrr, bdf, i )
>       {
> -        rc = func(PFN_DOWN(rmrr->base_address),
> -                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
> -                  ctxt);
> -        if ( rc )
> -            break;
> +        if ( d->arch.hvm_domain.pci_force )
> +        {
> +            rc = func(PFN_DOWN(rmrr->base_address),
> +                      PFN_UP(rmrr->end_address) -
> +                      PFN_DOWN(rmrr->base_address),
> +                      ctxt);
> +            if ( rc )
> +                break;
> +        }
> +        else
> +        {
> +            for ( j = 0; j < d->arch.hvm_domain.num_pcidevs; j++ )
> +            {
> 
> But,
> 
> dmar.c: In function 'intel_iommu_get_reserved_device_memory'"
> dmar.c:904:28: error: dereferencing 'void *' pointer [-Werror]
>       struct domain *d = ctxt->domain;
>                              ^
> dmar.c:904:28: error: request for member 'domain' in something not a 
> structure or union
> cc1: all warnings being treated as errors
> make[6]: *** [dmar.o] Error 1
> make[6]: *** Waiting for unfinished jobs.
> 
> Unless we move all check inside each callback functions.

That's what you should do imo, albeit I realize that the comparing
of the specific SBDFs will need additional consideration.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:06:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:06:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7PR-00076G-4Y; Tue, 11 Nov 2014 09:06:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo7PP-000769-Us
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:06:44 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	E1/69-07724-3A1D1645; Tue, 11 Nov 2014 09:06:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415696802!11742662!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 531 invoked from network); 11 Nov 2014 09:06:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 09:06:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 09:06:42 +0000
Message-Id: <5461DFAF020000780004652B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 09:06:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
In-Reply-To: <5461DED50200007800046520@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 10:03, <JBeulich@suse.com> wrote:
>>>> On 11.11.14 at 08:49, <tiejun.chen@intel.com> wrote:
>> Unless we move all check inside each callback functions.
> 
> That's what you should do imo, albeit I realize that the comparing
> of the specific SBDFs will need additional consideration.

Part of which would involve re-considering whether device
assignment shouldn't be done before memory population in the
tool stack.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:06:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:06:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7PR-00076G-4Y; Tue, 11 Nov 2014 09:06:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo7PP-000769-Us
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:06:44 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	E1/69-07724-3A1D1645; Tue, 11 Nov 2014 09:06:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415696802!11742662!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 531 invoked from network); 11 Nov 2014 09:06:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 09:06:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 09:06:42 +0000
Message-Id: <5461DFAF020000780004652B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 09:06:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5450BE27020000780004304A@mail.emea.novell.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
In-Reply-To: <5461DED50200007800046520@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 10:03, <JBeulich@suse.com> wrote:
>>>> On 11.11.14 at 08:49, <tiejun.chen@intel.com> wrote:
>> Unless we move all check inside each callback functions.
> 
> That's what you should do imo, albeit I realize that the comparing
> of the specific SBDFs will need additional consideration.

Part of which would involve re-considering whether device
assignment shouldn't be done before memory population in the
tool stack.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:17:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7a2-0007MM-DM; Tue, 11 Nov 2014 09:17:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gang.chen.5i5j@gmail.com>) id 1Xo7a0-0007MH-VR
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 09:17:41 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	BD/52-28296-434D1645; Tue, 11 Nov 2014 09:17:40 +0000
X-Env-Sender: gang.chen.5i5j@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415697458!11790266!1
X-Originating-IP: [209.85.220.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14227 invoked from network); 11 Nov 2014 09:17:39 -0000
Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com)
	(209.85.220.48)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 09:17:39 -0000
Received: by mail-pa0-f48.google.com with SMTP id ey11so10247656pad.21
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Nov 2014 01:17:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:content-type:content-transfer-encoding;
	bh=MH4YQzi7h2NA4iXBmxUj3tNdKaE797GBP71CVqTPYZk=;
	b=ajR4PKOU6cGChUACNyGyjlTNb/8l9C+dX5ESxmJBf4ymUynCKNzNodFARsxsUjHbo7
	doyxUWADT2q/ha6f3MtKFEZQqwdKpeb02k2IRrbkUKRMzXFQk5sEUe5OgZFlK4ObArip
	dU/jjZFX34Rj1NJDGUikIohu9utT/lFAEMNzUTJeQiLubANlBrbkf/6ys1gfb8w+Zvvx
	hQxvpQJDQc5CwFt7T9fJ3nsSXQF06gmHZHVTy9FP0c/mwXRY0ZiTdkZwdu7qTSPJ2QVb
	J8YHD2flwDHj1H1hbpwSJru0J/CCB9MJX0MrDp+HoE07BRuJGdZO/IVzND7f5t+3jEKu
	3ouw==
X-Received: by 10.70.52.98 with SMTP id s2mr38166399pdo.5.1415697457899;
	Tue, 11 Nov 2014 01:17:37 -0800 (PST)
Received: from ShengShiZhuChengdeMacBook-Pro.local ([124.127.118.42])
	by mx.google.com with ESMTPSA id a10sm18823039pdp.0.2014.11.11.01.17.29
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 11 Nov 2014 01:17:36 -0800 (PST)
Message-ID: <5461D59C.5020106@gmail.com>
Date: Tue, 11 Nov 2014 17:23:40 +0800
From: Chen Gang <gang.chen.5i5j@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH trivial] xen-hvm: Remove redandant varialbe
	'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 xen_hvm_change_state_handler(), can pass 'opaque' with type cast to
xen_main_loop_prepare() directly, need not use additional variable for
it.

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
 xen-hvm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen-hvm.c b/xen-hvm.c
index 21f1cbb..7548794 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -993,9 +993,8 @@ static void xen_main_loop_prepare(XenIOState *state)
 static void xen_hvm_change_state_handler(void *opaque, int running,
                                          RunState rstate)
 {
-    XenIOState *xstate = opaque;
     if (running) {
-        xen_main_loop_prepare(xstate);
+        xen_main_loop_prepare((XenIOState *)opaque);
     }
 }
 
-- 
1.8.5.2 (Apple Git-48)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:17:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7a2-0007MM-DM; Tue, 11 Nov 2014 09:17:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gang.chen.5i5j@gmail.com>) id 1Xo7a0-0007MH-VR
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 09:17:41 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	BD/52-28296-434D1645; Tue, 11 Nov 2014 09:17:40 +0000
X-Env-Sender: gang.chen.5i5j@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415697458!11790266!1
X-Originating-IP: [209.85.220.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14227 invoked from network); 11 Nov 2014 09:17:39 -0000
Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com)
	(209.85.220.48)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 09:17:39 -0000
Received: by mail-pa0-f48.google.com with SMTP id ey11so10247656pad.21
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Nov 2014 01:17:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:content-type:content-transfer-encoding;
	bh=MH4YQzi7h2NA4iXBmxUj3tNdKaE797GBP71CVqTPYZk=;
	b=ajR4PKOU6cGChUACNyGyjlTNb/8l9C+dX5ESxmJBf4ymUynCKNzNodFARsxsUjHbo7
	doyxUWADT2q/ha6f3MtKFEZQqwdKpeb02k2IRrbkUKRMzXFQk5sEUe5OgZFlK4ObArip
	dU/jjZFX34Rj1NJDGUikIohu9utT/lFAEMNzUTJeQiLubANlBrbkf/6ys1gfb8w+Zvvx
	hQxvpQJDQc5CwFt7T9fJ3nsSXQF06gmHZHVTy9FP0c/mwXRY0ZiTdkZwdu7qTSPJ2QVb
	J8YHD2flwDHj1H1hbpwSJru0J/CCB9MJX0MrDp+HoE07BRuJGdZO/IVzND7f5t+3jEKu
	3ouw==
X-Received: by 10.70.52.98 with SMTP id s2mr38166399pdo.5.1415697457899;
	Tue, 11 Nov 2014 01:17:37 -0800 (PST)
Received: from ShengShiZhuChengdeMacBook-Pro.local ([124.127.118.42])
	by mx.google.com with ESMTPSA id a10sm18823039pdp.0.2014.11.11.01.17.29
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 11 Nov 2014 01:17:36 -0800 (PST)
Message-ID: <5461D59C.5020106@gmail.com>
Date: Tue, 11 Nov 2014 17:23:40 +0800
From: Chen Gang <gang.chen.5i5j@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH trivial] xen-hvm: Remove redandant varialbe
	'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 xen_hvm_change_state_handler(), can pass 'opaque' with type cast to
xen_main_loop_prepare() directly, need not use additional variable for
it.

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
 xen-hvm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen-hvm.c b/xen-hvm.c
index 21f1cbb..7548794 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -993,9 +993,8 @@ static void xen_main_loop_prepare(XenIOState *state)
 static void xen_hvm_change_state_handler(void *opaque, int running,
                                          RunState rstate)
 {
-    XenIOState *xstate = opaque;
     if (running) {
-        xen_main_loop_prepare(xstate);
+        xen_main_loop_prepare((XenIOState *)opaque);
     }
 }
 
-- 
1.8.5.2 (Apple Git-48)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:35:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:35:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7qu-0007jf-F9; Tue, 11 Nov 2014 09:35:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xo7qr-0007jX-Vj
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:35:07 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	D3/C4-27785-948D1645; Tue, 11 Nov 2014 09:35:05 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415698503!11734430!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26137 invoked from network); 11 Nov 2014 09:35:04 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-27.messagelabs.com with SMTP;
	11 Nov 2014 09:35:04 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 11 Nov 2014 01:32:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,359,1413270000"; d="scan'208";a="634954784"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.131.43])
	([10.238.131.43])
	by orsmga002.jf.intel.com with ESMTP; 11 Nov 2014 01:35:00 -0800
Message-ID: <5461D844.7090702@intel.com>
Date: Tue, 11 Nov 2014 17:35:00 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com>
	<5461DDFB020000780004650C@mail.emea.novell.com>
In-Reply-To: <5461DDFB020000780004650C@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> Do you mean this line?
>>
>> copy_from_guest_offset(pcidevs, xdsr->pcidevs, 0,
>> xdsr->num_pcidevs*sizeof(xen_guest_pcidev_info_t))
>
> Almost:
>
>      copy_from_guest(pcidevs, xdsr->pcidevs, xdsr->num_pcidevs * sizeof(*pcidevs))

Fixed.

>
>>>> --- a/xen/include/asm-x86/hvm/domain.h
>>>> +++ b/xen/include/asm-x86/hvm/domain.h
>>>> @@ -90,6 +90,10 @@ struct hvm_domain {
>>>>         /* Cached CF8 for guest PCI config cycles */
>>>>         uint32_t                pci_cf8;
>>>>
>>>> +    uint32_t                pci_rdmforce;
>>>
>>> I still don't see why this is a uint32_t.
>>
>> How about bool_t?
>
> Exactly.
>
>> In Xen side we have 'bool_t', but we have 'bool' in tools side. So how
>> to define this in xen/include/public/domctl.h?
>
> Have a structure field named e.g. "flags" and a #define consuming
> exactly one bit of it. Just like it's being done everywhere else.

Like this?

  typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
  DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);

+struct xen_guest_pcidev_info {
+    uint8_t bus;
+    uint8_t devfn;
+    struct {
+        uint32_t    force           : 1,
+                    reserved        : 31;
+    }flags;
+};
+typedef struct xen_guest_pcidev_info xen_guest_pcidev_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_guest_pcidev_info_t);
+/* Control whether/how we check and reserve device memory. */
+struct xen_domctl_set_rdm {
+    struct {
+        uint32_t    force           : 1,
+                    reserved        : 31;
+    }flags;
+    uint32_t    num_pcidevs;
+    XEN_GUEST_HANDLE_64(xen_guest_pcidev_info_t) pcidevs;
+};
+typedef struct xen_domctl_set_rdm xen_domctl_set_rdm_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_rdm_t);
+
  /* Retrieve sibling devices infomation of machine_sbdf */
  /* XEN_DOMCTL_get_device_group */
  struct xen_domctl_get_device_group {


>
>>>> @@ -1118,7 +1137,8 @@ struct xen_domctl {
>>>>             struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>>>>             struct xen_domctl_vnuma             vnuma;
>>>>             struct xen_domctl_psr_cmt_op        psr_cmt_op;
>>>> -        uint8_t                             pad[128];
>>>> +        struct xen_domctl_set_rdm           set_rdm;
>>>> +        uint8_t                             pad[112];
>>>
>>> Why are you altering the padding size here?
>>
>> As I understand we should shrink this pad when we introduce new filed,
>> shouldn't we?
>
> You realize that this is inside a union?

Sorry I didn't realize this point.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:35:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:35:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7qu-0007jf-F9; Tue, 11 Nov 2014 09:35:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xo7qr-0007jX-Vj
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:35:07 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	D3/C4-27785-948D1645; Tue, 11 Nov 2014 09:35:05 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415698503!11734430!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26137 invoked from network); 11 Nov 2014 09:35:04 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-27.messagelabs.com with SMTP;
	11 Nov 2014 09:35:04 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 11 Nov 2014 01:32:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,359,1413270000"; d="scan'208";a="634954784"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.131.43])
	([10.238.131.43])
	by orsmga002.jf.intel.com with ESMTP; 11 Nov 2014 01:35:00 -0800
Message-ID: <5461D844.7090702@intel.com>
Date: Tue, 11 Nov 2014 17:35:00 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com>
	<5461DDFB020000780004650C@mail.emea.novell.com>
In-Reply-To: <5461DDFB020000780004650C@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> Do you mean this line?
>>
>> copy_from_guest_offset(pcidevs, xdsr->pcidevs, 0,
>> xdsr->num_pcidevs*sizeof(xen_guest_pcidev_info_t))
>
> Almost:
>
>      copy_from_guest(pcidevs, xdsr->pcidevs, xdsr->num_pcidevs * sizeof(*pcidevs))

Fixed.

>
>>>> --- a/xen/include/asm-x86/hvm/domain.h
>>>> +++ b/xen/include/asm-x86/hvm/domain.h
>>>> @@ -90,6 +90,10 @@ struct hvm_domain {
>>>>         /* Cached CF8 for guest PCI config cycles */
>>>>         uint32_t                pci_cf8;
>>>>
>>>> +    uint32_t                pci_rdmforce;
>>>
>>> I still don't see why this is a uint32_t.
>>
>> How about bool_t?
>
> Exactly.
>
>> In Xen side we have 'bool_t', but we have 'bool' in tools side. So how
>> to define this in xen/include/public/domctl.h?
>
> Have a structure field named e.g. "flags" and a #define consuming
> exactly one bit of it. Just like it's being done everywhere else.

Like this?

  typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
  DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);

+struct xen_guest_pcidev_info {
+    uint8_t bus;
+    uint8_t devfn;
+    struct {
+        uint32_t    force           : 1,
+                    reserved        : 31;
+    }flags;
+};
+typedef struct xen_guest_pcidev_info xen_guest_pcidev_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_guest_pcidev_info_t);
+/* Control whether/how we check and reserve device memory. */
+struct xen_domctl_set_rdm {
+    struct {
+        uint32_t    force           : 1,
+                    reserved        : 31;
+    }flags;
+    uint32_t    num_pcidevs;
+    XEN_GUEST_HANDLE_64(xen_guest_pcidev_info_t) pcidevs;
+};
+typedef struct xen_domctl_set_rdm xen_domctl_set_rdm_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_rdm_t);
+
  /* Retrieve sibling devices infomation of machine_sbdf */
  /* XEN_DOMCTL_get_device_group */
  struct xen_domctl_get_device_group {


>
>>>> @@ -1118,7 +1137,8 @@ struct xen_domctl {
>>>>             struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>>>>             struct xen_domctl_vnuma             vnuma;
>>>>             struct xen_domctl_psr_cmt_op        psr_cmt_op;
>>>> -        uint8_t                             pad[128];
>>>> +        struct xen_domctl_set_rdm           set_rdm;
>>>> +        uint8_t                             pad[112];
>>>
>>> Why are you altering the padding size here?
>>
>> As I understand we should shrink this pad when we introduce new filed,
>> shouldn't we?
>
> You realize that this is inside a union?

Sorry I didn't realize this point.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:43:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:43:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7yT-0007uP-GW; Tue, 11 Nov 2014 09:42:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo7yS-0007uK-9A
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:42:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	26/2F-24532-F1AD1645; Tue, 11 Nov 2014 09:42:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415698975!11852137!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2898 invoked from network); 11 Nov 2014 09:42:55 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 09:42:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 09:42:55 +0000
Message-Id: <5461E82D020000780004656E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 09:42:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com>
	<5461DDFB020000780004650C@mail.emea.novell.com>
	<5461D844.7090702@intel.com>
In-Reply-To: <5461D844.7090702@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 10:35, <tiejun.chen@intel.com> wrote:
>> Have a structure field named e.g. "flags" and a #define consuming
>> exactly one bit of it. Just like it's being done everywhere else.
> 
> Like this?
> 
>   typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
> 
> +struct xen_guest_pcidev_info {
> +    uint8_t bus;
> +    uint8_t devfn;
> +    struct {
> +        uint32_t    force           : 1,
> +                    reserved        : 31;
> +    }flags;
> +};

I said #define for a reason - with a few exceptions we try to avoid
using bit fields in the public interface.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:43:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:43:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7yT-0007uP-GW; Tue, 11 Nov 2014 09:42:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo7yS-0007uK-9A
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:42:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	26/2F-24532-F1AD1645; Tue, 11 Nov 2014 09:42:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415698975!11852137!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2898 invoked from network); 11 Nov 2014 09:42:55 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 09:42:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 09:42:55 +0000
Message-Id: <5461E82D020000780004656E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 09:42:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5451AC56.7010303@intel.com>
	<54521100020000780004363A@mail.emea.novell.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com>
	<5461DDFB020000780004650C@mail.emea.novell.com>
	<5461D844.7090702@intel.com>
In-Reply-To: <5461D844.7090702@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 10:35, <tiejun.chen@intel.com> wrote:
>> Have a structure field named e.g. "flags" and a #define consuming
>> exactly one bit of it. Just like it's being done everywhere else.
> 
> Like this?
> 
>   typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
> 
> +struct xen_guest_pcidev_info {
> +    uint8_t bus;
> +    uint8_t devfn;
> +    struct {
> +        uint32_t    force           : 1,
> +                    reserved        : 31;
> +    }flags;
> +};

I said #define for a reason - with a few exceptions we try to avoid
using bit fields in the public interface.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:43:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:43:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7yb-0007vX-Se; Tue, 11 Nov 2014 09:43:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xo7ya-0007ur-MB
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:43:04 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	A4/63-28296-72AD1645; Tue, 11 Nov 2014 09:43:03 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415698982!11773754!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27183 invoked from network); 11 Nov 2014 09:43:03 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-31.messagelabs.com with SMTP;
	11 Nov 2014 09:43:03 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 11 Nov 2014 01:41:09 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,359,1413270000"; d="scan'208";a="634957465"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.131.43])
	([10.238.131.43])
	by orsmga002.jf.intel.com with ESMTP; 11 Nov 2014 01:43:00 -0800
Message-ID: <5461DA23.6020105@intel.com>
Date: Tue, 11 Nov 2014 17:42:59 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
In-Reply-To: <5461DFAF020000780004652B@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/11 17:06, Jan Beulich wrote:
>>>> On 11.11.14 at 10:03, <JBeulich@suse.com> wrote:
>>>>> On 11.11.14 at 08:49, <tiejun.chen@intel.com> wrote:
>>> Unless we move all check inside each callback functions.
>>
>> That's what you should do imo, albeit I realize that the comparing

Yes, I can do this in all existing callback functions but I'm somewhat 
afraid when other guys want to introduce new callback function, who can 
guarantee this should be done as well?

>> of the specific SBDFs will need additional consideration.
>
> Part of which would involve re-considering whether device
> assignment shouldn't be done before memory population in the
> tool stack.
>

Yes, after we introduce this new domctl, we just make sure this domctl 
should be called before memory population no matter when we do assign a 
device as passthrough.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:43:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:43:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo7yb-0007vX-Se; Tue, 11 Nov 2014 09:43:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xo7ya-0007ur-MB
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:43:04 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	A4/63-28296-72AD1645; Tue, 11 Nov 2014 09:43:03 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415698982!11773754!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27183 invoked from network); 11 Nov 2014 09:43:03 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-31.messagelabs.com with SMTP;
	11 Nov 2014 09:43:03 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 11 Nov 2014 01:41:09 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,359,1413270000"; d="scan'208";a="634957465"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.131.43])
	([10.238.131.43])
	by orsmga002.jf.intel.com with ESMTP; 11 Nov 2014 01:43:00 -0800
Message-ID: <5461DA23.6020105@intel.com>
Date: Tue, 11 Nov 2014 17:42:59 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
In-Reply-To: <5461DFAF020000780004652B@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/11 17:06, Jan Beulich wrote:
>>>> On 11.11.14 at 10:03, <JBeulich@suse.com> wrote:
>>>>> On 11.11.14 at 08:49, <tiejun.chen@intel.com> wrote:
>>> Unless we move all check inside each callback functions.
>>
>> That's what you should do imo, albeit I realize that the comparing

Yes, I can do this in all existing callback functions but I'm somewhat 
afraid when other guys want to introduce new callback function, who can 
guarantee this should be done as well?

>> of the specific SBDFs will need additional consideration.
>
> Part of which would involve re-considering whether device
> assignment shouldn't be done before memory population in the
> tool stack.
>

Yes, after we introduce this new domctl, we just make sure this domctl 
should be called before memory population no matter when we do assign a 
device as passthrough.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:52:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo874-0008Ki-7W; Tue, 11 Nov 2014 09:51:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xo873-0008KR-N9
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:51:49 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	6E/95-22777-53CD1645; Tue, 11 Nov 2014 09:51:49 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415699506!8371932!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26576 invoked from network); 11 Nov 2014 09:51:47 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-206.messagelabs.com with SMTP;
	11 Nov 2014 09:51:47 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 11 Nov 2014 01:51:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,359,1413270000"; d="scan'208";a="605837102"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.131.43])
	([10.238.131.43])
	by orsmga001.jf.intel.com with ESMTP; 11 Nov 2014 01:51:08 -0800
Message-ID: <5461DC0B.40101@intel.com>
Date: Tue, 11 Nov 2014 17:51:07 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com>
	<5461DDFB020000780004650C@mail.emea.novell.com>
	<5461D844.7090702@intel.com>
	<5461E82D020000780004656E@mail.emea.novell.com>
In-Reply-To: <5461E82D020000780004656E@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/11 17:42, Jan Beulich wrote:
>>>> On 11.11.14 at 10:35, <tiejun.chen@intel.com> wrote:
>>> Have a structure field named e.g. "flags" and a #define consuming
>>> exactly one bit of it. Just like it's being done everywhere else.
>>
>> Like this?
>>
>>    typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>>    DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
>>
>> +struct xen_guest_pcidev_info {
>> +    uint8_t bus;
>> +    uint8_t devfn;
>> +    struct {
>> +        uint32_t    force           : 1,
>> +                    reserved        : 31;
>> +    }flags;
>> +};
>
> I said #define for a reason - with a few exceptions we try to avoid
> using bit fields in the public interface.
>

Ok,

  typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
  DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);

+/* Currently just one bit to indicate force to check Reserved Device 
Memory. */
+#define PCI_DEV_RDM_CHECK   0x1
+struct xen_guest_pcidev_info {
+    uint8_t bus;
+    uint8_t devfn;
+    uint32_t    flags;
+};
+typedef struct xen_guest_pcidev_info xen_guest_pcidev_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_guest_pcidev_info_t);
+/* Control whether/how we check and reserve device memory. */
+struct xen_domctl_set_rdm {
+    uint32_t    flags;
+    uint32_t    num_pcidevs;
+    XEN_GUEST_HANDLE_64(xen_guest_pcidev_info_t) pcidevs;
+};
+typedef struct xen_domctl_set_rdm xen_domctl_set_rdm_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_rdm_t);
+
  /* Retrieve sibling devices infomation of machine_sbdf */
  /* XEN_DOMCTL_get_device_group */
  struct xen_domctl_get_device_group {

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:52:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo874-0008Ki-7W; Tue, 11 Nov 2014 09:51:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xo873-0008KR-N9
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:51:49 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	6E/95-22777-53CD1645; Tue, 11 Nov 2014 09:51:49 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415699506!8371932!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26576 invoked from network); 11 Nov 2014 09:51:47 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-206.messagelabs.com with SMTP;
	11 Nov 2014 09:51:47 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 11 Nov 2014 01:51:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,359,1413270000"; d="scan'208";a="605837102"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.131.43])
	([10.238.131.43])
	by orsmga001.jf.intel.com with ESMTP; 11 Nov 2014 01:51:08 -0800
Message-ID: <5461DC0B.40101@intel.com>
Date: Tue, 11 Nov 2014 17:51:07 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com>
	<5461DDFB020000780004650C@mail.emea.novell.com>
	<5461D844.7090702@intel.com>
	<5461E82D020000780004656E@mail.emea.novell.com>
In-Reply-To: <5461E82D020000780004656E@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/11 17:42, Jan Beulich wrote:
>>>> On 11.11.14 at 10:35, <tiejun.chen@intel.com> wrote:
>>> Have a structure field named e.g. "flags" and a #define consuming
>>> exactly one bit of it. Just like it's being done everywhere else.
>>
>> Like this?
>>
>>    typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
>>    DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);
>>
>> +struct xen_guest_pcidev_info {
>> +    uint8_t bus;
>> +    uint8_t devfn;
>> +    struct {
>> +        uint32_t    force           : 1,
>> +                    reserved        : 31;
>> +    }flags;
>> +};
>
> I said #define for a reason - with a few exceptions we try to avoid
> using bit fields in the public interface.
>

Ok,

  typedef struct xen_domctl_assign_device xen_domctl_assign_device_t;
  DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t);

+/* Currently just one bit to indicate force to check Reserved Device 
Memory. */
+#define PCI_DEV_RDM_CHECK   0x1
+struct xen_guest_pcidev_info {
+    uint8_t bus;
+    uint8_t devfn;
+    uint32_t    flags;
+};
+typedef struct xen_guest_pcidev_info xen_guest_pcidev_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_guest_pcidev_info_t);
+/* Control whether/how we check and reserve device memory. */
+struct xen_domctl_set_rdm {
+    uint32_t    flags;
+    uint32_t    num_pcidevs;
+    XEN_GUEST_HANDLE_64(xen_guest_pcidev_info_t) pcidevs;
+};
+typedef struct xen_domctl_set_rdm xen_domctl_set_rdm_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_rdm_t);
+
  /* Retrieve sibling devices infomation of machine_sbdf */
  /* XEN_DOMCTL_get_device_group */
  struct xen_domctl_get_device_group {

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:53:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09: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 1Xo88J-0008Qf-Mx; Tue, 11 Nov 2014 09:53:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xo88I-0008Qa-7b
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:53:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A7/CB-09936-18CD1645; Tue, 11 Nov 2014 09:53:05 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415699581!11818647!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10440 invoked from network); 11 Nov 2014 09:53:01 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 09:53:01 -0000
Received: by mail-wi0-f182.google.com with SMTP id d1so1053206wiv.3
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 01:53:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=gKQ0W4ECwy285WS7XAFX6Hn9h+Jg94XNXe1ZAlYerYk=;
	b=OGO3q6txaJhGRUqv1svlnbV9XdoXnsNhhFjetjJjwmYdeq+VWWQjWy+T2gK57XTEuY
	Z48zsiAZjkXGrOKbqiZX7XP27YN2okItyHr4Wry3vIneiX7JKrWNNfeSfy39hbU7BVy1
	6n1kGLQWLMytaR0NGQrUidtwqpNlszK2vwcwzAggrVV330m3cA6rk0S11Z17allj3Tie
	skGogtcJGHihYTnqs5X3S8mmhnJZtdJ/oX2WRbPF94dtvkFI6YqvEDDCb8svHqgtfRg3
	/kpiq/DjcY4J47EBK8f6elB1tvvjGlT88nn0i0aQailmSmuTXX5ByWnR9/3geZNI0a2J
	x15A==
MIME-Version: 1.0
X-Received: by 10.180.12.136 with SMTP id y8mr39509836wib.73.1415699581722;
	Tue, 11 Nov 2014 01:53:01 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Tue, 11 Nov 2014 01:53:01 -0800 (PST)
In-Reply-To: <1415653872-2232-3-git-send-email-mengxu@cis.upenn.edu>
References: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
	<1415653872-2232-3-git-send-email-mengxu@cis.upenn.edu>
Date: Tue, 11 Nov 2014 09:53:01 +0000
X-Google-Sender-Auth: 94D0JDcScT5RrFcH7l6NGtPW_ts
Message-ID: <CAFLBxZbBU3+AEto65Cnhp-oOcA+VnOuQ7cs4-4f6AWJDCC2Yig@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Meng Xu <mengxu@cis.upenn.edu>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.r.wilk@gmail.com>,
	Meng Xu <xumengpanda@gmail.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v3 2/2] xen: serialize vcpu data
 in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 9:11 PM, Meng Xu <mengxu@cis.upenn.edu> wrote:
> Fix the following two issues in rtds scheduler:
> 1) The runq queue lock is not grabbed when rt_update_deadline is
> called in rt_alloc_vdata function, which may cause race condition;
> Solution: Move call to rt_update_deadline from _alloc to _insert;
> Note: rt_alloc_vdata does not need grab the runq lock, because only one
> cpu will allocate the rt_vcpu; before the rt_vcpu is inserted into the
> runq, no more than one cpu operates on the rt_vcpu.
>
> 2) rt_vcpu_remove should grab the runq lock before remove the vcpu
> from runq; otherwise, race condition may happen.
> Solution: Add lock in rt_vcpu_remove().
>
> Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

Great, thanks Meng!

Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>



> ---
>  xen/common/sched_rt.c |   12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 8251e41..e70d6c7 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -508,7 +508,6 @@ static void *
>  rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
>  {
>      struct rt_vcpu *svc;
> -    s_time_t now = NOW();
>
>      /* Allocate per-VCPU info */
>      svc = xzalloc(struct rt_vcpu);
> @@ -526,10 +525,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
>      if ( !is_idle_vcpu(vc) )
>          svc->budget = RTDS_DEFAULT_BUDGET;
>
> -    ASSERT( now >= svc->cur_deadline );
> -
> -    rt_update_deadline(now, svc);
> -
>      return svc;
>  }
>
> @@ -552,11 +547,15 @@ static void
>  rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
>  {
>      struct rt_vcpu *svc = rt_vcpu(vc);
> +    s_time_t now = NOW();
>
>      /* not addlocate idle vcpu to dom vcpu list */
>      if ( is_idle_vcpu(vc) )
>          return;
>
> +    if ( now >= svc->cur_deadline )
> +        rt_update_deadline(now, svc);
> +
>      if ( !__vcpu_on_q(svc) && vcpu_runnable(vc) && !vc->is_running )
>          __runq_insert(ops, svc);
>
> @@ -573,11 +572,14 @@ rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
>  {
>      struct rt_vcpu * const svc = rt_vcpu(vc);
>      struct rt_dom * const sdom = svc->sdom;
> +    spinlock_t *lock;
>
>      BUG_ON( sdom == NULL );
>
> +    lock = vcpu_schedule_lock_irq(vc);
>      if ( __vcpu_on_q(svc) )
>          __q_remove(svc);
> +    vcpu_schedule_unlock_irq(lock, vc);
>
>      if ( !is_idle_vcpu(vc) )
>          list_del_init(&svc->sdom_elem);
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 09:53:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 09: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 1Xo88J-0008Qf-Mx; Tue, 11 Nov 2014 09:53:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xo88I-0008Qa-7b
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 09:53:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A7/CB-09936-18CD1645; Tue, 11 Nov 2014 09:53:05 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415699581!11818647!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10440 invoked from network); 11 Nov 2014 09:53:01 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 09:53:01 -0000
Received: by mail-wi0-f182.google.com with SMTP id d1so1053206wiv.3
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 01:53:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=gKQ0W4ECwy285WS7XAFX6Hn9h+Jg94XNXe1ZAlYerYk=;
	b=OGO3q6txaJhGRUqv1svlnbV9XdoXnsNhhFjetjJjwmYdeq+VWWQjWy+T2gK57XTEuY
	Z48zsiAZjkXGrOKbqiZX7XP27YN2okItyHr4Wry3vIneiX7JKrWNNfeSfy39hbU7BVy1
	6n1kGLQWLMytaR0NGQrUidtwqpNlszK2vwcwzAggrVV330m3cA6rk0S11Z17allj3Tie
	skGogtcJGHihYTnqs5X3S8mmhnJZtdJ/oX2WRbPF94dtvkFI6YqvEDDCb8svHqgtfRg3
	/kpiq/DjcY4J47EBK8f6elB1tvvjGlT88nn0i0aQailmSmuTXX5ByWnR9/3geZNI0a2J
	x15A==
MIME-Version: 1.0
X-Received: by 10.180.12.136 with SMTP id y8mr39509836wib.73.1415699581722;
	Tue, 11 Nov 2014 01:53:01 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Tue, 11 Nov 2014 01:53:01 -0800 (PST)
In-Reply-To: <1415653872-2232-3-git-send-email-mengxu@cis.upenn.edu>
References: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
	<1415653872-2232-3-git-send-email-mengxu@cis.upenn.edu>
Date: Tue, 11 Nov 2014 09:53:01 +0000
X-Google-Sender-Auth: 94D0JDcScT5RrFcH7l6NGtPW_ts
Message-ID: <CAFLBxZbBU3+AEto65Cnhp-oOcA+VnOuQ7cs4-4f6AWJDCC2Yig@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Meng Xu <mengxu@cis.upenn.edu>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.r.wilk@gmail.com>,
	Meng Xu <xumengpanda@gmail.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v3 2/2] xen: serialize vcpu data
 in sched_rt.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 9:11 PM, Meng Xu <mengxu@cis.upenn.edu> wrote:
> Fix the following two issues in rtds scheduler:
> 1) The runq queue lock is not grabbed when rt_update_deadline is
> called in rt_alloc_vdata function, which may cause race condition;
> Solution: Move call to rt_update_deadline from _alloc to _insert;
> Note: rt_alloc_vdata does not need grab the runq lock, because only one
> cpu will allocate the rt_vcpu; before the rt_vcpu is inserted into the
> runq, no more than one cpu operates on the rt_vcpu.
>
> 2) rt_vcpu_remove should grab the runq lock before remove the vcpu
> from runq; otherwise, race condition may happen.
> Solution: Add lock in rt_vcpu_remove().
>
> Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

Great, thanks Meng!

Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>



> ---
>  xen/common/sched_rt.c |   12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 8251e41..e70d6c7 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -508,7 +508,6 @@ static void *
>  rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
>  {
>      struct rt_vcpu *svc;
> -    s_time_t now = NOW();
>
>      /* Allocate per-VCPU info */
>      svc = xzalloc(struct rt_vcpu);
> @@ -526,10 +525,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
>      if ( !is_idle_vcpu(vc) )
>          svc->budget = RTDS_DEFAULT_BUDGET;
>
> -    ASSERT( now >= svc->cur_deadline );
> -
> -    rt_update_deadline(now, svc);
> -
>      return svc;
>  }
>
> @@ -552,11 +547,15 @@ static void
>  rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
>  {
>      struct rt_vcpu *svc = rt_vcpu(vc);
> +    s_time_t now = NOW();
>
>      /* not addlocate idle vcpu to dom vcpu list */
>      if ( is_idle_vcpu(vc) )
>          return;
>
> +    if ( now >= svc->cur_deadline )
> +        rt_update_deadline(now, svc);
> +
>      if ( !__vcpu_on_q(svc) && vcpu_runnable(vc) && !vc->is_running )
>          __runq_insert(ops, svc);
>
> @@ -573,11 +572,14 @@ rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
>  {
>      struct rt_vcpu * const svc = rt_vcpu(vc);
>      struct rt_dom * const sdom = svc->sdom;
> +    spinlock_t *lock;
>
>      BUG_ON( sdom == NULL );
>
> +    lock = vcpu_schedule_lock_irq(vc);
>      if ( __vcpu_on_q(svc) )
>          __q_remove(svc);
> +    vcpu_schedule_unlock_irq(lock, vc);
>
>      if ( !is_idle_vcpu(vc) )
>          list_del_init(&svc->sdom_elem);
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:01:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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 1Xo8Fe-0000Fq-O9; Tue, 11 Nov 2014 10:00:42 +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 1Xo8Fc-0000Fd-US
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 10:00:41 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	08/F8-28865-84ED1645; Tue, 11 Nov 2014 10:00:40 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415700039!11718601!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16296 invoked from network); 11 Nov 2014 10:00:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 10:00:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="26696407"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: hanji unit <hanjiunit@gmail.com>, "win-pv-devel@lists.xenproject.org"
	<win-pv-devel@lists.xenproject.org>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Windows Paravirtualization for Xen
Thread-Index: AQHP/YWa0ApY9KYiqkSs6r4iYKHxB5xbL/ug
Date: Tue, 11 Nov 2014 10:00:36 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD01114A95C@AMSPEX01CL01.citrite.net>
References: <CA+J4q6eSw0RCaK3WSAbSVOXx3s6ErTq-CmgijjyiJqNjQgrVQg@mail.gmail.com>
	<CA+J4q6fLSzA+Rw51r7FYy2o6x8+ZTpX6W7U7G526Q-OSgSHtGA@mail.gmail.com>
In-Reply-To: <CA+J4q6fLSzA+Rw51r7FYy2o6x8+ZTpX6W7U7G526Q-OSgSHtGA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Subject: Re: [Xen-devel] Windows Paravirtualization for Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't use HTML...

From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of hanji unit
Sent: 10 November 2014 21:09
To: win-pv-devel@lists.xenproject.org; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Windows Paravirtualization for Xen

Adding main Xen development list too.

On Mon, Nov 10, 2014 at 1:00 PM, hanji unit <hanjiunit@gmail.com> wrote:
Hello. I am looking at windows Paravirtualization support and I've seen a few projects including:
1) win-pvdrivers by James Harper (http://wiki.xen.org/wiki/Xen_Windows_GplPv)
2) Windows PV-Driver Subproject (http://wiki.xen.org/wiki/Xen_FAQ_Drivers,_Windows#What_is_the_Windows_PV_Driver_Subproject.2Fteam.3F)
3) Open Sourced XenServer Windows PV Drivers (https://github.com/xenserver)
Are these 3 projects all different or do any of them refer to the same projects? If different, which is the one that is most widely supported and used that has future support plans? I am trying to write to XenStore from Windows and looking to modify some of these drivers if needed, but dont want to work on a dead project.
Thanks.

-----

3 supercedes 2, and 1 is a different set of open source drivers that preceded the open-sourcing of the XenServer drivers.

If you want to try to access xenstore from Windows user space then the XENIFACE driver in 2 will already allow you to do that via WMI. See http://xenbits.xen.org/gitweb/?p=pvdrivers/win/xeniface.git;a=blob;f=WmiDocumentation.txt. If you don't want to use WMI then there are also basic read/write/directory IOCTLS too (see http://xenbits.xen.org/gitweb/?p=pvdrivers/win/xeniface.git;a=blob;f=src/xeniface/ioctls.c).

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:01:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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 1Xo8Fe-0000Fq-O9; Tue, 11 Nov 2014 10:00:42 +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 1Xo8Fc-0000Fd-US
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 10:00:41 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	08/F8-28865-84ED1645; Tue, 11 Nov 2014 10:00:40 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415700039!11718601!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16296 invoked from network); 11 Nov 2014 10:00:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 10:00:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="26696407"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: hanji unit <hanjiunit@gmail.com>, "win-pv-devel@lists.xenproject.org"
	<win-pv-devel@lists.xenproject.org>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Windows Paravirtualization for Xen
Thread-Index: AQHP/YWa0ApY9KYiqkSs6r4iYKHxB5xbL/ug
Date: Tue, 11 Nov 2014 10:00:36 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD01114A95C@AMSPEX01CL01.citrite.net>
References: <CA+J4q6eSw0RCaK3WSAbSVOXx3s6ErTq-CmgijjyiJqNjQgrVQg@mail.gmail.com>
	<CA+J4q6fLSzA+Rw51r7FYy2o6x8+ZTpX6W7U7G526Q-OSgSHtGA@mail.gmail.com>
In-Reply-To: <CA+J4q6fLSzA+Rw51r7FYy2o6x8+ZTpX6W7U7G526Q-OSgSHtGA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Subject: Re: [Xen-devel] Windows Paravirtualization for Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't use HTML...

From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of hanji unit
Sent: 10 November 2014 21:09
To: win-pv-devel@lists.xenproject.org; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Windows Paravirtualization for Xen

Adding main Xen development list too.

On Mon, Nov 10, 2014 at 1:00 PM, hanji unit <hanjiunit@gmail.com> wrote:
Hello. I am looking at windows Paravirtualization support and I've seen a few projects including:
1) win-pvdrivers by James Harper (http://wiki.xen.org/wiki/Xen_Windows_GplPv)
2) Windows PV-Driver Subproject (http://wiki.xen.org/wiki/Xen_FAQ_Drivers,_Windows#What_is_the_Windows_PV_Driver_Subproject.2Fteam.3F)
3) Open Sourced XenServer Windows PV Drivers (https://github.com/xenserver)
Are these 3 projects all different or do any of them refer to the same projects? If different, which is the one that is most widely supported and used that has future support plans? I am trying to write to XenStore from Windows and looking to modify some of these drivers if needed, but dont want to work on a dead project.
Thanks.

-----

3 supercedes 2, and 1 is a different set of open source drivers that preceded the open-sourcing of the XenServer drivers.

If you want to try to access xenstore from Windows user space then the XENIFACE driver in 2 will already allow you to do that via WMI. See http://xenbits.xen.org/gitweb/?p=pvdrivers/win/xeniface.git;a=blob;f=WmiDocumentation.txt. If you don't want to use WMI then there are also basic read/write/directory IOCTLS too (see http://xenbits.xen.org/gitweb/?p=pvdrivers/win/xeniface.git;a=blob;f=src/xeniface/ioctls.c).

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:07:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:07:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo8Lt-0000Vc-LZ; Tue, 11 Nov 2014 10:07:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo8Lr-0000VT-QI
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 10:07:07 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	66/0E-17694-ACFD1645; Tue, 11 Nov 2014 10:07:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415700426!11811066!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24790 invoked from network); 11 Nov 2014 10:07:06 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 10:07:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 10:07:06 +0000
Message-Id: <5461EDD702000078000465C3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 10:07:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
In-Reply-To: <5461DA23.6020105@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 10:42, <tiejun.chen@intel.com> wrote:
> On 2014/11/11 17:06, Jan Beulich wrote:
>> Part of which would involve re-considering whether device
>> assignment shouldn't be done before memory population in the
>> tool stack.
>>
> 
> Yes, after we introduce this new domctl, we just make sure this domctl 
> should be called before memory population no matter when we do assign a 
> device as passthrough.

You didn't think through the implications then: If device assignment
happens early enough, there's no need to report SBDF tuples via a
new domctl (or only if we want to still allow for post-boot assignment
of affected devices without using the global enforcement flag, in
which case assigning devices early at boot time is pointless).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:07:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:07:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo8Lt-0000Vc-LZ; Tue, 11 Nov 2014 10:07:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo8Lr-0000VT-QI
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 10:07:07 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	66/0E-17694-ACFD1645; Tue, 11 Nov 2014 10:07:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415700426!11811066!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24790 invoked from network); 11 Nov 2014 10:07:06 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 10:07:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 10:07:06 +0000
Message-Id: <5461EDD702000078000465C3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 10:07:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545320F2.5030103@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
In-Reply-To: <5461DA23.6020105@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 10:42, <tiejun.chen@intel.com> wrote:
> On 2014/11/11 17:06, Jan Beulich wrote:
>> Part of which would involve re-considering whether device
>> assignment shouldn't be done before memory population in the
>> tool stack.
>>
> 
> Yes, after we introduce this new domctl, we just make sure this domctl 
> should be called before memory population no matter when we do assign a 
> device as passthrough.

You didn't think through the implications then: If device assignment
happens early enough, there's no need to report SBDF tuples via a
new domctl (or only if we want to still allow for post-boot assignment
of affected devices without using the global enforcement flag, in
which case assigning devices early at boot time is pointless).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:21:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo8ZT-0000n5-CP; Tue, 11 Nov 2014 10:21:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xo8ZR-0000n0-Os
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:21:09 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	54/EA-02953-513E1645; Tue, 11 Nov 2014 10:21:09 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415701267!11740989!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3189 invoked from network); 11 Nov 2014 10:21:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 10:21:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191505328"
Message-ID: <5461E310.4070803@citrix.com>
Date: Tue, 11 Nov 2014 10:21:04 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-2-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 1/8] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 05:43, Juergen Gross wrote:
> Some functions in arch/x86/xen/p2m.c are used locally only. Make them
> static. Rearrange the functions in p2m.c to avoid forward declarations.
> 
> While at it correct some style issues (long lines, use pr_warn()).

Please don't add extra stuff like this.  In general if you feel yourself
wring "while at it..." or "also..." then you need another patch.

I also don't care about long lines if they are under 100 characters.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:21:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo8ZT-0000n5-CP; Tue, 11 Nov 2014 10:21:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xo8ZR-0000n0-Os
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:21:09 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	54/EA-02953-513E1645; Tue, 11 Nov 2014 10:21:09 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415701267!11740989!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3189 invoked from network); 11 Nov 2014 10:21:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 10:21:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191505328"
Message-ID: <5461E310.4070803@citrix.com>
Date: Tue, 11 Nov 2014 10:21:04 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-2-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 1/8] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 05:43, Juergen Gross wrote:
> Some functions in arch/x86/xen/p2m.c are used locally only. Make them
> static. Rearrange the functions in p2m.c to avoid forward declarations.
> 
> While at it correct some style issues (long lines, use pr_warn()).

Please don't add extra stuff like this.  In general if you feel yourself
wring "while at it..." or "also..." then you need another patch.

I also don't care about long lines if they are under 100 characters.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:29:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:29:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo8he-00011k-EA; Tue, 11 Nov 2014 10:29:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xo8hd-00011f-Ii
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:29:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E1/48-09842-015E1645; Tue, 11 Nov 2014 10:29:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415701775!11819387!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26208 invoked from network); 11 Nov 2014 10:29:36 -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;
	11 Nov 2014 10:29:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="190062960"
Message-ID: <5461E50C.4040309@citrix.com>
Date: Tue, 11 Nov 2014 10:29:32 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-4-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-4-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 3/8] xen: Delay m2p_override
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 05:43, Juergen Gross wrote:
> The m2p overrides are used to be able to find the local pfn for a
> foreign mfn mapped into the domain. They are used by driver backends
> having to access frontend data.
> 
> As this functionality isn't used in early boot it makes no sense to
> initialize the m2p override functions very early. It can be done
> later without doing any harm, removing the need for allocating memory
> via extend_brk().
> 
> While at it make some m2p override functions static as they are only
> used internally.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

But...

>  static struct page *m2p_find_override(unsigned long mfn)
>  {
>  	unsigned long flags;
> -	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
> +	struct list_head *bucket;
>  	struct page *p, *ret;


    if (unlikely(!m2p_overrides))
        return NULL;

Would be preferred,

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:29:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:29:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo8he-00011k-EA; Tue, 11 Nov 2014 10:29:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xo8hd-00011f-Ii
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:29:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E1/48-09842-015E1645; Tue, 11 Nov 2014 10:29:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415701775!11819387!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26208 invoked from network); 11 Nov 2014 10:29:36 -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;
	11 Nov 2014 10:29:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="190062960"
Message-ID: <5461E50C.4040309@citrix.com>
Date: Tue, 11 Nov 2014 10:29:32 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-4-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-4-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 3/8] xen: Delay m2p_override
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 05:43, Juergen Gross wrote:
> The m2p overrides are used to be able to find the local pfn for a
> foreign mfn mapped into the domain. They are used by driver backends
> having to access frontend data.
> 
> As this functionality isn't used in early boot it makes no sense to
> initialize the m2p override functions very early. It can be done
> later without doing any harm, removing the need for allocating memory
> via extend_brk().
> 
> While at it make some m2p override functions static as they are only
> used internally.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

But...

>  static struct page *m2p_find_override(unsigned long mfn)
>  {
>  	unsigned long flags;
> -	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
> +	struct list_head *bucket;
>  	struct page *p, *ret;


    if (unlikely(!m2p_overrides))
        return NULL;

Would be preferred,

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:36:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:36:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo8o0-0001GX-VA; Tue, 11 Nov 2014 10:36:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo8nz-0001GS-7n
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:36:11 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0E/BA-09936-A96E1645; Tue, 11 Nov 2014 10:36:10 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415702169!11870066!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29730 invoked from network); 11 Nov 2014 10:36:10 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 10:36:10 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 91FF6AB07;
	Tue, 11 Nov 2014 10:36:09 +0000 (UTC)
Message-ID: <5461E698.9060904@suse.com>
Date: Tue, 11 Nov 2014 11:36:08 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-2-git-send-email-jgross@suse.com>
	<5461E310.4070803@citrix.com>
In-Reply-To: <5461E310.4070803@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/8] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/2014 11:21 AM, David Vrabel wrote:
> On 11/11/14 05:43, Juergen Gross wrote:
>> Some functions in arch/x86/xen/p2m.c are used locally only. Make them
>> static. Rearrange the functions in p2m.c to avoid forward declarations.
>>
>> While at it correct some style issues (long lines, use pr_warn()).
>
> Please don't add extra stuff like this.  In general if you feel yourself
> wring "while at it..." or "also..." then you need another patch.

I applied the changes only to functions I was moving, as checkpatch was
complaining. Documentation says this should be avoided only when moving
functions between files.

If you still think I should omit these changes I'll throw them out.

>
> I also don't care about long lines if they are under 100 characters.

I do. :-)

But same again: either no style corrections or all.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:36:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:36:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo8o0-0001GX-VA; Tue, 11 Nov 2014 10:36:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo8nz-0001GS-7n
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:36:11 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0E/BA-09936-A96E1645; Tue, 11 Nov 2014 10:36:10 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415702169!11870066!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29730 invoked from network); 11 Nov 2014 10:36:10 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 10:36:10 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 91FF6AB07;
	Tue, 11 Nov 2014 10:36:09 +0000 (UTC)
Message-ID: <5461E698.9060904@suse.com>
Date: Tue, 11 Nov 2014 11:36:08 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-2-git-send-email-jgross@suse.com>
	<5461E310.4070803@citrix.com>
In-Reply-To: <5461E310.4070803@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/8] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/2014 11:21 AM, David Vrabel wrote:
> On 11/11/14 05:43, Juergen Gross wrote:
>> Some functions in arch/x86/xen/p2m.c are used locally only. Make them
>> static. Rearrange the functions in p2m.c to avoid forward declarations.
>>
>> While at it correct some style issues (long lines, use pr_warn()).
>
> Please don't add extra stuff like this.  In general if you feel yourself
> wring "while at it..." or "also..." then you need another patch.

I applied the changes only to functions I was moving, as checkpatch was
complaining. Documentation says this should be avoided only when moving
functions between files.

If you still think I should omit these changes I'll throw them out.

>
> I also don't care about long lines if they are under 100 characters.

I do. :-)

But same again: either no style corrections or all.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:40:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:40:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo8sL-0001Ow-Nr; Tue, 11 Nov 2014 10:40:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo8sK-0001Op-Tf
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 10:40:41 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	99/02-11581-8A7E1645; Tue, 11 Nov 2014 10:40:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415702439!8386737!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28247 invoked from network); 11 Nov 2014 10:40:39 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 10:40:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 10:40:39 +0000
Message-Id: <5461F5B502000078000465F2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 10:40:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Meng Xu" <mengxu@cis.upenn.edu>,"Meng Xu" <xumengpanda@gmail.com>
References: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
	<CAENZ-+kxAcS+UP0K8jLnwD3EefN8iVaTryXeOksJH5RBstJ3qg@mail.gmail.com>
In-Reply-To: <CAENZ-+kxAcS+UP0K8jLnwD3EefN8iVaTryXeOksJH5RBstJ3qg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.r.wilk@gmail.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v3 0/2] Sanity check input and
 serialize vcpu data in sched_rt.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 10.11.14 at 22:13, <xumengpanda@gmail.com> wrote:
> Sorry, the cover letter missed one line. :-(
> 
> 2014-11-10 16:11 GMT-05:00 Meng Xu <mengxu@cis.upenn.edu>:
> 
> These two patches are to solve the issues found by Jan Beulich at
> http://lists.xen.org/archives/html/xen-devel/2014-09/msg03554.html.

Such information would normally be communicated via Reported-by
tags.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:40:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:40:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo8sL-0001Ow-Nr; Tue, 11 Nov 2014 10:40:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xo8sK-0001Op-Tf
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 10:40:41 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	99/02-11581-8A7E1645; Tue, 11 Nov 2014 10:40:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415702439!8386737!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28247 invoked from network); 11 Nov 2014 10:40:39 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 10:40:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2014 10:40:39 +0000
Message-Id: <5461F5B502000078000465F2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 11 Nov 2014 10:40:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Meng Xu" <mengxu@cis.upenn.edu>,"Meng Xu" <xumengpanda@gmail.com>
References: <1415653872-2232-1-git-send-email-mengxu@cis.upenn.edu>
	<CAENZ-+kxAcS+UP0K8jLnwD3EefN8iVaTryXeOksJH5RBstJ3qg@mail.gmail.com>
In-Reply-To: <CAENZ-+kxAcS+UP0K8jLnwD3EefN8iVaTryXeOksJH5RBstJ3qg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.r.wilk@gmail.com>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5 v3 0/2] Sanity check input and
 serialize vcpu data in sched_rt.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 10.11.14 at 22:13, <xumengpanda@gmail.com> wrote:
> Sorry, the cover letter missed one line. :-(
> 
> 2014-11-10 16:11 GMT-05:00 Meng Xu <mengxu@cis.upenn.edu>:
> 
> These two patches are to solve the issues found by Jan Beulich at
> http://lists.xen.org/archives/html/xen-devel/2014-09/msg03554.html.

Such information would normally be communicated via Reported-by
tags.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:51:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo928-0001fW-W4; Tue, 11 Nov 2014 10:50:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xo927-0001fR-KL
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:50:47 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	0D/9D-05632-60AE1645; Tue, 11 Nov 2014 10:50:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415703045!11719869!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13203 invoked from network); 11 Nov 2014 10:50:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 10:50:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191510545"
Message-ID: <5461EA02.3020400@citrix.com>
Date: Tue, 11 Nov 2014 10:50:42 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<boris.ostrovsky@oracle.com>, <x86@kernel.org>, <tglx@linutronix.de>,
	<mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-2-git-send-email-jgross@suse.com>
	<5461E310.4070803@citrix.com> <5461E698.9060904@suse.com>
In-Reply-To: <5461E698.9060904@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 1/8] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 10:36, Juergen Gross wrote:
> On 11/11/2014 11:21 AM, David Vrabel wrote:
>> On 11/11/14 05:43, Juergen Gross wrote:
>>> Some functions in arch/x86/xen/p2m.c are used locally only. Make them
>>> static. Rearrange the functions in p2m.c to avoid forward declarations.
>>>
>>> While at it correct some style issues (long lines, use pr_warn()).
>>
>> Please don't add extra stuff like this.  In general if you feel yourself
>> wring "while at it..." or "also..." then you need another patch.
> 
> I applied the changes only to functions I was moving, as checkpatch was
> complaining. Documentation says this should be avoided only when moving
> functions between files.

If the documentation says that then it is wrong.  Fix the style issues
in one patch and then move the functions in another.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:51:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo928-0001fW-W4; Tue, 11 Nov 2014 10:50:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xo927-0001fR-KL
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:50:47 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	0D/9D-05632-60AE1645; Tue, 11 Nov 2014 10:50:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415703045!11719869!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13203 invoked from network); 11 Nov 2014 10:50:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 10:50:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191510545"
Message-ID: <5461EA02.3020400@citrix.com>
Date: Tue, 11 Nov 2014 10:50:42 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<boris.ostrovsky@oracle.com>, <x86@kernel.org>, <tglx@linutronix.de>,
	<mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-2-git-send-email-jgross@suse.com>
	<5461E310.4070803@citrix.com> <5461E698.9060904@suse.com>
In-Reply-To: <5461E698.9060904@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 1/8] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 10:36, Juergen Gross wrote:
> On 11/11/2014 11:21 AM, David Vrabel wrote:
>> On 11/11/14 05:43, Juergen Gross wrote:
>>> Some functions in arch/x86/xen/p2m.c are used locally only. Make them
>>> static. Rearrange the functions in p2m.c to avoid forward declarations.
>>>
>>> While at it correct some style issues (long lines, use pr_warn()).
>>
>> Please don't add extra stuff like this.  In general if you feel yourself
>> wring "while at it..." or "also..." then you need another patch.
> 
> I applied the changes only to functions I was moving, as checkpatch was
> complaining. Documentation says this should be avoided only when moving
> functions between files.

If the documentation says that then it is wrong.  Fix the style issues
in one patch and then move the functions in another.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:53:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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 1Xo94Z-0001rr-IL; Tue, 11 Nov 2014 10:53:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xo94Y-0001rm-6z
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:53:18 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	4D/04-22737-D9AE1645; Tue, 11 Nov 2014 10:53:17 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415703195!11733235!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14436 invoked from network); 11 Nov 2014 10:53:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 10:53:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191510880"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 05:53:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo94U-0001RY-AS;
	Tue, 11 Nov 2014 10:53:14 +0000
Date: Tue, 11 Nov 2014 10:53:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Chen Gang <gang.chen.5i5j@gmail.com>
In-Reply-To: <5461D59C.5020106@gmail.com>
Message-ID: <alpine.DEB.2.02.1411111052280.26318@kaball.uk.xensource.com>
References: <5461D59C.5020106@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	Michael Tokarev <mjt@tls.msk.ru>, qemu-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH trivial] xen-hvm: Remove redandant varialbe
	'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Nov 2014, Chen Gang wrote:
> In xen_hvm_change_state_handler(), can pass 'opaque' with type cast to
> xen_main_loop_prepare() directly, need not use additional variable for
> it.
> 
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  xen-hvm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 21f1cbb..7548794 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -993,9 +993,8 @@ static void xen_main_loop_prepare(XenIOState *state)
>  static void xen_hvm_change_state_handler(void *opaque, int running,
>                                           RunState rstate)
>  {
> -    XenIOState *xstate = opaque;
>      if (running) {
> -        xen_main_loop_prepare(xstate);
> +        xen_main_loop_prepare((XenIOState *)opaque);
>      }
>  }
>  
> -- 
> 1.8.5.2 (Apple Git-48)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:53:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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 1Xo94Z-0001rr-IL; Tue, 11 Nov 2014 10:53:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xo94Y-0001rm-6z
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:53:18 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	4D/04-22737-D9AE1645; Tue, 11 Nov 2014 10:53:17 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415703195!11733235!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14436 invoked from network); 11 Nov 2014 10:53:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 10:53:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191510880"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 05:53:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo94U-0001RY-AS;
	Tue, 11 Nov 2014 10:53:14 +0000
Date: Tue, 11 Nov 2014 10:53:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Chen Gang <gang.chen.5i5j@gmail.com>
In-Reply-To: <5461D59C.5020106@gmail.com>
Message-ID: <alpine.DEB.2.02.1411111052280.26318@kaball.uk.xensource.com>
References: <5461D59C.5020106@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	Michael Tokarev <mjt@tls.msk.ru>, qemu-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH trivial] xen-hvm: Remove redandant varialbe
	'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Nov 2014, Chen Gang wrote:
> In xen_hvm_change_state_handler(), can pass 'opaque' with type cast to
> xen_main_loop_prepare() directly, need not use additional variable for
> it.
> 
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  xen-hvm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 21f1cbb..7548794 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -993,9 +993,8 @@ static void xen_main_loop_prepare(XenIOState *state)
>  static void xen_hvm_change_state_handler(void *opaque, int running,
>                                           RunState rstate)
>  {
> -    XenIOState *xstate = opaque;
>      if (running) {
> -        xen_main_loop_prepare(xstate);
> +        xen_main_loop_prepare((XenIOState *)opaque);
>      }
>  }
>  
> -- 
> 1.8.5.2 (Apple Git-48)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:56:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo975-00020b-4H; Tue, 11 Nov 2014 10:55:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo974-00020U-CY
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:55:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A4/92-09936-93BE1645; Tue, 11 Nov 2014 10:55:53 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415703352!11876574!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11059 invoked from network); 11 Nov 2014 10:55:53 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 10:55:53 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 75F12ABE7;
	Tue, 11 Nov 2014 10:55:52 +0000 (UTC)
Message-ID: <5461EB37.4010603@suse.com>
Date: Tue, 11 Nov 2014 11:55:51 +0100
From: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-2-git-send-email-jgross@suse.com>
	<5461E310.4070803@citrix.com> <5461E698.9060904@suse.com>
	<5461EA02.3020400@citrix.com>
In-Reply-To: <5461EA02.3020400@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/8] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/2014 11:50 AM, David Vrabel wrote:
> On 11/11/14 10:36, Juergen Gross wrote:
>> On 11/11/2014 11:21 AM, David Vrabel wrote:
>>> On 11/11/14 05:43, Juergen Gross wrote:
>>>> Some functions in arch/x86/xen/p2m.c are used locally only. Make them
>>>> static. Rearrange the functions in p2m.c to avoid forward declarations.
>>>>
>>>> While at it correct some style issues (long lines, use pr_warn()).
>>>
>>> Please don't add extra stuff like this.  In general if you feel yourself
>>> wring "while at it..." or "also..." then you need another patch.
>>
>> I applied the changes only to functions I was moving, as checkpatch was
>> complaining. Documentation says this should be avoided only when moving
>> functions between files.
>
> If the documentation says that then it is wrong.  Fix the style issues
> in one patch and then move the functions in another.

Okay.

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 10:56:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 10:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo975-00020b-4H; Tue, 11 Nov 2014 10:55:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xo974-00020U-CY
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 10:55:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A4/92-09936-93BE1645; Tue, 11 Nov 2014 10:55:53 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415703352!11876574!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11059 invoked from network); 11 Nov 2014 10:55:53 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 10:55:53 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 75F12ABE7;
	Tue, 11 Nov 2014 10:55:52 +0000 (UTC)
Message-ID: <5461EB37.4010603@suse.com>
Date: Tue, 11 Nov 2014 11:55:51 +0100
From: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-2-git-send-email-jgross@suse.com>
	<5461E310.4070803@citrix.com> <5461E698.9060904@suse.com>
	<5461EA02.3020400@citrix.com>
In-Reply-To: <5461EA02.3020400@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/8] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/2014 11:50 AM, David Vrabel wrote:
> On 11/11/14 10:36, Juergen Gross wrote:
>> On 11/11/2014 11:21 AM, David Vrabel wrote:
>>> On 11/11/14 05:43, Juergen Gross wrote:
>>>> Some functions in arch/x86/xen/p2m.c are used locally only. Make them
>>>> static. Rearrange the functions in p2m.c to avoid forward declarations.
>>>>
>>>> While at it correct some style issues (long lines, use pr_warn()).
>>>
>>> Please don't add extra stuff like this.  In general if you feel yourself
>>> wring "while at it..." or "also..." then you need another patch.
>>
>> I applied the changes only to functions I was moving, as checkpatch was
>> complaining. Documentation says this should be avoided only when moving
>> functions between files.
>
> If the documentation says that then it is wrong.  Fix the style issues
> in one patch and then move the functions in another.

Okay.

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:02:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 11:02:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo9Cz-0002Dm-C2; Tue, 11 Nov 2014 11:02:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xo9Cx-0002Dh-Oh
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 11:01:59 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	95/1E-02953-7ACE1645; Tue, 11 Nov 2014 11:01:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415703717!11664420!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17727 invoked from network); 11 Nov 2014 11:01:58 -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;
	11 Nov 2014 11:01:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="190070233"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 06:01:56 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xo9Cu-0001dF-Fb;
	Tue, 11 Nov 2014 11:01:56 +0000
Date: Tue, 11 Nov 2014 11:01:56 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141111110156.GA12465@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460FBCA.5060302@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
[...]
> Could you please explain what does "no configuration" means?
> 
> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
> 

That means no configuration at all. I think a skeleton can be provided
at best (in xl level) to be consistent with "xl list", which should
include domid and domain name etc. Since nothing else exists in
xenstore yet, there's no point poking there.

[...]
> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
> 

Hmm... I don't think poking around in different places is a good idea.
This is prone to breakage in the future.

Since xenstore is not filled in when your tool looks at it, what makes
it different to wait a bit until migration finishes?

And, from your earlier reply, you're implying Xend fires
@introduceDomain at the same point as xl, but your tool can work with
it?

Wei.

> Thanks,
> 
> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:02:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 11:02:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo9Cz-0002Dm-C2; Tue, 11 Nov 2014 11:02:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xo9Cx-0002Dh-Oh
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 11:01:59 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	95/1E-02953-7ACE1645; Tue, 11 Nov 2014 11:01:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415703717!11664420!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17727 invoked from network); 11 Nov 2014 11:01:58 -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;
	11 Nov 2014 11:01:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="190070233"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 06:01:56 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xo9Cu-0001dF-Fb;
	Tue, 11 Nov 2014 11:01:56 +0000
Date: Tue, 11 Nov 2014 11:01:56 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141111110156.GA12465@zion.uk.xensource.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5460FBCA.5060302@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
[...]
> Could you please explain what does "no configuration" means?
> 
> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
> 

That means no configuration at all. I think a skeleton can be provided
at best (in xl level) to be consistent with "xl list", which should
include domid and domain name etc. Since nothing else exists in
xenstore yet, there's no point poking there.

[...]
> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
> 

Hmm... I don't think poking around in different places is a good idea.
This is prone to breakage in the future.

Since xenstore is not filled in when your tool looks at it, what makes
it different to wait a bit until migration finishes?

And, from your earlier reply, you're implying Xend fires
@introduceDomain at the same point as xl, but your tool can work with
it?

Wei.

> Thanks,
> 
> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:08:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 11: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 1Xo9Ig-0002ST-TB; Tue, 11 Nov 2014 11:07:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xo9Ie-0002SI-LF
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 11:07:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2D/FE-09842-80EE1645; Tue, 11 Nov 2014 11:07:52 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415704067!8427952!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14041 invoked from network); 11 Nov 2014 11:07:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 11:07:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191513721"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 06:07:45 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo9IX-0001j6-Eq;
	Tue, 11 Nov 2014 11:07:45 +0000
Date: Tue, 11 Nov 2014 11:07:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141110184111.GH25609@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411111106320.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141110184111.GH25609@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 03/13] xen/arm: if(pfn_valid(pfn)) call
 native dma_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Catalin Marinas wrote:
> On Mon, Nov 10, 2014 at 04:13:55PM +0000, Stefano Stabellini wrote:
> >  void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
> >  		size_t size, enum dma_data_direction dir,
> > -		struct dma_attrs *attrs);
> > +		struct dma_attrs *attrs)
> > +{
> > +	unsigned long pfn = PFN_DOWN(handle);
> > +	/* Dom0 is mapped 1:1, so calling pfn_valid on a foreign mfn will
> > +	 * always return false. If the page is local we can safely call the
> > +	 * native dma_ops function, otherwise we call the xen specific
> > +	 * function. */
> > +	if (pfn_valid(pfn)) {
> > +		if (__generic_dma_ops(hwdev)->unmap_page)
> > +			__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
> 
> Similarly here, do we need the unmap_page check? dma_map_page() does not
> do it.

I think we do not need the map_page check, because that's always
implemented, but we need the unmap_page check. In fact
arm_coherent_dma_ops doesn't have unmap_page for example.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:08:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 11: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 1Xo9Ig-0002ST-TB; Tue, 11 Nov 2014 11:07:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xo9Ie-0002SI-LF
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 11:07:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2D/FE-09842-80EE1645; Tue, 11 Nov 2014 11:07:52 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415704067!8427952!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14041 invoked from network); 11 Nov 2014 11:07:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 11:07:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191513721"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 06:07:45 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo9IX-0001j6-Eq;
	Tue, 11 Nov 2014 11:07:45 +0000
Date: Tue, 11 Nov 2014 11:07:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141110184111.GH25609@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411111106320.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141110184111.GH25609@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 03/13] xen/arm: if(pfn_valid(pfn)) call
 native dma_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Catalin Marinas wrote:
> On Mon, Nov 10, 2014 at 04:13:55PM +0000, Stefano Stabellini wrote:
> >  void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
> >  		size_t size, enum dma_data_direction dir,
> > -		struct dma_attrs *attrs);
> > +		struct dma_attrs *attrs)
> > +{
> > +	unsigned long pfn = PFN_DOWN(handle);
> > +	/* Dom0 is mapped 1:1, so calling pfn_valid on a foreign mfn will
> > +	 * always return false. If the page is local we can safely call the
> > +	 * native dma_ops function, otherwise we call the xen specific
> > +	 * function. */
> > +	if (pfn_valid(pfn)) {
> > +		if (__generic_dma_ops(hwdev)->unmap_page)
> > +			__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
> 
> Similarly here, do we need the unmap_page check? dma_map_page() does not
> do it.

I think we do not need the map_page check, because that's always
implemented, but we need the unmap_page check. In fact
arm_coherent_dma_ops doesn't have unmap_page for example.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:14:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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.xen.org>)
	id 1Xo9P2-0002o9-0W; Tue, 11 Nov 2014 11:14:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xo9P0-0002o4-NA
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 11:14:26 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	99/47-02699-29FE1645; Tue, 11 Nov 2014 11:14:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415704464!11756560!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22457 invoked from network); 11 Nov 2014 11:14:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 11:14:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191515218"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 06:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo9Ox-0001r4-6b;
	Tue, 11 Nov 2014 11:14:23 +0000
Date: Tue, 11 Nov 2014 11:14:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141110184226.GI25609@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411111110090.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141110184226.GI25609@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 04/13] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Catalin Marinas wrote:
> On Mon, Nov 10, 2014 at 04:13:56PM +0000, Stefano Stabellini wrote:
> > Introduce a boolean flag and an accessor function to check whether a
> > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> 
> BTW, why do I sign off this patch? As long as it's you as author, I
> don't think you should add my sign-off.

IANAL but as you wrote most of the code in the patch, I think that your
Signed-off-by is required because the lines you wrote are under your
copyright, not mine. TBH for such a small patch, it probably doesn't
matter (there is a limit to what one can claim copyright on).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:14:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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.xen.org>)
	id 1Xo9P2-0002o9-0W; Tue, 11 Nov 2014 11:14:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xo9P0-0002o4-NA
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 11:14:26 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	99/47-02699-29FE1645; Tue, 11 Nov 2014 11:14:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415704464!11756560!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22457 invoked from network); 11 Nov 2014 11:14:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 11:14:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191515218"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 06:14:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo9Ox-0001r4-6b;
	Tue, 11 Nov 2014 11:14:23 +0000
Date: Tue, 11 Nov 2014 11:14:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141110184226.GI25609@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411111110090.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141110184226.GI25609@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 04/13] arm64: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Catalin Marinas wrote:
> On Mon, Nov 10, 2014 at 04:13:56PM +0000, Stefano Stabellini wrote:
> > Introduce a boolean flag and an accessor function to check whether a
> > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> 
> BTW, why do I sign off this patch? As long as it's you as author, I
> don't think you should add my sign-off.

IANAL but as you wrote most of the code in the patch, I think that your
Signed-off-by is required because the lines you wrote are under your
copyright, not mine. TBH for such a small patch, it probably doesn't
matter (there is a limit to what one can claim copyright on).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:16:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 11:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo9Qr-0002ty-JC; Tue, 11 Nov 2014 11:16:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xo9Qp-0002tp-OE
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 11:16:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B4/3E-09936-300F1645; Tue, 11 Nov 2014 11:16:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415704577!3842688!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22233 invoked from network); 11 Nov 2014 11:16:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 11:16:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191515657"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 06:16:16 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo9Qm-0001tI-60;
	Tue, 11 Nov 2014 11:16:16 +0000
Date: Tue, 11 Nov 2014 11:16:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141110184446.GJ25609@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411111115400.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<20141110184446.GJ25609@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 0/13] introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Catalin Marinas wrote:
> On Mon, Nov 10, 2014 at 04:12:40PM +0000, Stefano Stabellini wrote:
> > this patch series introduces support for GNTTABOP_cache_flush to perform
> > cache maintenance operation on foreign pages and reverts the current
> > code based on XENFEAT_grant_map_identity.
> > 
> > It also provides a very slow fallback by bouncing on the swiotlb buffer,
> > in case the hypercall is not available.
> > 
> > v7 introduces a flag named dma_coherent in dev_archdata and an accessor
> > function named is_device_dma_coherent in asm/dma-mapping.h under arm and
> > arm64.
> 
> Apart from a few minor comments I gave already, the series looks fine to
> me. Once addressed, you can add:
> 
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

Thank you very much for your help!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:16:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 11:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo9Qr-0002ty-JC; Tue, 11 Nov 2014 11:16:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xo9Qp-0002tp-OE
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 11:16:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B4/3E-09936-300F1645; Tue, 11 Nov 2014 11:16:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415704577!3842688!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22233 invoked from network); 11 Nov 2014 11:16:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 11:16:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191515657"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 06:16:16 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo9Qm-0001tI-60;
	Tue, 11 Nov 2014 11:16:16 +0000
Date: Tue, 11 Nov 2014 11:16:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141110184446.GJ25609@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411111115400.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<20141110184446.GJ25609@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 0/13] introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Catalin Marinas wrote:
> On Mon, Nov 10, 2014 at 04:12:40PM +0000, Stefano Stabellini wrote:
> > this patch series introduces support for GNTTABOP_cache_flush to perform
> > cache maintenance operation on foreign pages and reverts the current
> > code based on XENFEAT_grant_map_identity.
> > 
> > It also provides a very slow fallback by bouncing on the swiotlb buffer,
> > in case the hypercall is not available.
> > 
> > v7 introduces a flag named dma_coherent in dev_archdata and an accessor
> > function named is_device_dma_coherent in asm/dma-mapping.h under arm and
> > arm64.
> 
> Apart from a few minor comments I gave already, the series looks fine to
> me. Once addressed, you can add:
> 
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

Thank you very much for your help!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:26:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 11:26:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo9aF-00036o-VE; Tue, 11 Nov 2014 11:26:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xo9aD-00036j-JO
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 11:26:02 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	30/7C-17694-842F1645; Tue, 11 Nov 2014 11:26:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415705158!11796417!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21447 invoked from network); 11 Nov 2014 11:26:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 11:26:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191517637"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 06:25:55 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xo9a7-00021r-NK;
	Tue, 11 Nov 2014 11:25:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xo9a7-0005Nf-8H;
	Tue, 11 Nov 2014 11:25:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21601.62017.850578.139091@mariner.uk.xensource.com>
Date: Tue, 11 Nov 2014 11:25:53 +0000
To: Konrad Rzeszutek Wilk <konrad.r.wilk@gmail.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
In-Reply-To: <osstest-31473-mainreport@xen.org>
References: <osstest-31473-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 31473: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-unstable test] 31473: tolerable FAIL - PUSHED"):
> flight 31473 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31473/
> 
> Failures :-/ but no regressions.
...
> version targeted for testing:
>  xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

Jolly good.  Konrad, I assume that you would like to release this as
RC2.

So, Stefano, would you please tag your qemu tree.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:26:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 11:26:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo9aF-00036o-VE; Tue, 11 Nov 2014 11:26:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xo9aD-00036j-JO
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 11:26:02 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	30/7C-17694-842F1645; Tue, 11 Nov 2014 11:26:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415705158!11796417!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21447 invoked from network); 11 Nov 2014 11:26:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 11:26:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191517637"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 06:25:55 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xo9a7-00021r-NK;
	Tue, 11 Nov 2014 11:25:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xo9a7-0005Nf-8H;
	Tue, 11 Nov 2014 11:25:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21601.62017.850578.139091@mariner.uk.xensource.com>
Date: Tue, 11 Nov 2014 11:25:53 +0000
To: Konrad Rzeszutek Wilk <konrad.r.wilk@gmail.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
In-Reply-To: <osstest-31473-mainreport@xen.org>
References: <osstest-31473-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 31473: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-unstable test] 31473: tolerable FAIL - PUSHED"):
> flight 31473 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31473/
> 
> Failures :-/ but no regressions.
...
> version targeted for testing:
>  xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

Jolly good.  Konrad, I assume that you would like to release this as
RC2.

So, Stefano, would you please tag your qemu tree.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:45:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 11:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo9st-0003d4-4K; Tue, 11 Nov 2014 11:45:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xo9sr-0003cz-1w
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 11:45:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	94/A2-09842-CC6F1645; Tue, 11 Nov 2014 11:45:16 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415706314!11881439!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19458 invoked from network); 11 Nov 2014 11:45:15 -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;
	11 Nov 2014 11:45:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191521836"
Message-ID: <5461F6C7.9070500@citrix.com>
Date: Tue, 11 Nov 2014 11:45:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-3-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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 11/11/14 05:43, Juergen Gross wrote:
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index fa75842..f67f8cf 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
>  		p2m[i] = INVALID_P2M_ENTRY;
>  }
>  
> +static void * __ref alloc_p2m_page(void)
> +{
> +	if (unlikely(use_brk))
> +		return extend_brk(PAGE_SIZE, PAGE_SIZE);
> +
> +	if (unlikely(!slab_is_available()))
> +		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +
> +	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
> +}
> +
> +static void free_p2m_page(void *p)
> +{
> +	free_page((unsigned long)p);
> +}
> +

What guarantees are there that free_p2m_page() is only called on p2m
pages allocated using __get_free_page() ?  I can see from this diff that
this is the case, but that doesn't help someone coming along in the future.

At the very least, a comment is warranted about the apparent mismatch
between {alloc,free}_p2m_page().

> @@ -420,6 +439,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>  	unsigned long *mfn_list = NULL;
>  	unsigned long size;
>  
> +	use_brk = 0;
>  	va_start = xen_start_info->mfn_list;
>  	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
>  	 * so make sure it is rounded up to that */
> @@ -484,6 +504,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>  #else
>  unsigned long __init xen_revector_p2m_tree(void)
>  {
> +	use_brk = 0;
>  	return 0;
>  }
>  #endif

This appears to be a completely orphaned function.

It has a split definition based on CONFIG_X86_64, but the sole caller is
xen_pagetable_p2m_copy() which is X86_64 only.

How does use_brk get cleared for 32bit PV guests?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 11:45:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 11:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xo9st-0003d4-4K; Tue, 11 Nov 2014 11:45:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xo9sr-0003cz-1w
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 11:45:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	94/A2-09842-CC6F1645; Tue, 11 Nov 2014 11:45:16 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415706314!11881439!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19458 invoked from network); 11 Nov 2014 11:45:15 -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;
	11 Nov 2014 11:45:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191521836"
Message-ID: <5461F6C7.9070500@citrix.com>
Date: Tue, 11 Nov 2014 11:45:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-3-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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 11/11/14 05:43, Juergen Gross wrote:
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index fa75842..f67f8cf 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
>  		p2m[i] = INVALID_P2M_ENTRY;
>  }
>  
> +static void * __ref alloc_p2m_page(void)
> +{
> +	if (unlikely(use_brk))
> +		return extend_brk(PAGE_SIZE, PAGE_SIZE);
> +
> +	if (unlikely(!slab_is_available()))
> +		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +
> +	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
> +}
> +
> +static void free_p2m_page(void *p)
> +{
> +	free_page((unsigned long)p);
> +}
> +

What guarantees are there that free_p2m_page() is only called on p2m
pages allocated using __get_free_page() ?  I can see from this diff that
this is the case, but that doesn't help someone coming along in the future.

At the very least, a comment is warranted about the apparent mismatch
between {alloc,free}_p2m_page().

> @@ -420,6 +439,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>  	unsigned long *mfn_list = NULL;
>  	unsigned long size;
>  
> +	use_brk = 0;
>  	va_start = xen_start_info->mfn_list;
>  	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
>  	 * so make sure it is rounded up to that */
> @@ -484,6 +504,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>  #else
>  unsigned long __init xen_revector_p2m_tree(void)
>  {
> +	use_brk = 0;
>  	return 0;
>  }
>  #endif

This appears to be a completely orphaned function.

It has a split definition based on CONFIG_X86_64, but the sole caller is
xen_pagetable_p2m_copy() which is X86_64 only.

How does use_brk get cleared for 32bit PV guests?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:03:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoA9z-0004Be-Cb; Tue, 11 Nov 2014 12:02:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoA9y-0004BV-Jo
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 12:02:58 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	65/C2-02698-1FAF1645; Tue, 11 Nov 2014 12:02:57 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415707375!11758827!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23506 invoked from network); 11 Nov 2014 12:02:57 -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;
	11 Nov 2014 12:02:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191525219"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 07:02:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo9xK-0002RS-CK;
	Tue, 11 Nov 2014 11:49:54 +0000
Date: Tue, 11 Nov 2014 11:49:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <21601.62017.850578.139091@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411111149370.26318@kaball.uk.xensource.com>
References: <osstest-31473-mainreport@xen.org>
	<21601.62017.850578.139091@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Konrad Rzeszutek Wilk <konrad.r.wilk@gmail.com>,
	xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 31473: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Nov 2014, Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 31473: tolerable FAIL - PUSHED"):
> > flight 31473 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/31473/
> > 
> > Failures :-/ but no regressions.
> ...
> > version targeted for testing:
> >  xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
> 
> Jolly good.  Konrad, I assume that you would like to release this as
> RC2.
> 
> So, Stefano, would you please tag your qemu tree.

Done

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:03:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoA9o-0004Aw-0H; Tue, 11 Nov 2014 12:02:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoA9m-0004Ar-Rg
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 12:02:46 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	44/CA-28296-6EAF1645; Tue, 11 Nov 2014 12:02:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415707364!11849346!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7194 invoked from network); 11 Nov 2014 12:02:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 12:02:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="190082680"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 07:02:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo9zy-0002U5-5G;
	Tue, 11 Nov 2014 11:52:38 +0000
Date: Tue, 11 Nov 2014 11:52:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141110183453.GG25609@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411111151030.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141110183453.GG25609@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 10/13] xen/arm/arm64: introduce
 xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Catalin Marinas wrote:
> On Mon, Nov 10, 2014 at 04:14:02PM +0000, Stefano Stabellini wrote:
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> >  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
> >  #define xen_unmap(cookie) iounmap((cookie))
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn);
> > +
> >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> > index 0e96023..1b087cd 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -102,6 +102,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
> >  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
> >  }
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn)
> > +{
> > +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> > +}
> 
> Why not a static inline? It doesn't look like a big function.

Because the next patch is going to make this change:

-   return ((pfn != mfn) && !is_device_dma_coherent(dev));
+   return (!hypercall_cflush && (pfn != mfn) && !is_device_dma_coherent(dev));

and I think it makes sense to keep hypercall_cflush as a static variable
within arch/arm/xen/mm.c (avoid exporting it in page.h).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:03:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoA9z-0004Be-Cb; Tue, 11 Nov 2014 12:02:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoA9y-0004BV-Jo
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 12:02:58 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	65/C2-02698-1FAF1645; Tue, 11 Nov 2014 12:02:57 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415707375!11758827!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23506 invoked from network); 11 Nov 2014 12:02:57 -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;
	11 Nov 2014 12:02:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="191525219"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 07:02:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo9xK-0002RS-CK;
	Tue, 11 Nov 2014 11:49:54 +0000
Date: Tue, 11 Nov 2014 11:49:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <21601.62017.850578.139091@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411111149370.26318@kaball.uk.xensource.com>
References: <osstest-31473-mainreport@xen.org>
	<21601.62017.850578.139091@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Konrad Rzeszutek Wilk <konrad.r.wilk@gmail.com>,
	xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 31473: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Nov 2014, Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 31473: tolerable FAIL - PUSHED"):
> > flight 31473 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/31473/
> > 
> > Failures :-/ but no regressions.
> ...
> > version targeted for testing:
> >  xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
> 
> Jolly good.  Konrad, I assume that you would like to release this as
> RC2.
> 
> So, Stefano, would you please tag your qemu tree.

Done

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:03:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoA9o-0004Aw-0H; Tue, 11 Nov 2014 12:02:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoA9m-0004Ar-Rg
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 12:02:46 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	44/CA-28296-6EAF1645; Tue, 11 Nov 2014 12:02:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415707364!11849346!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7194 invoked from network); 11 Nov 2014 12:02:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 12:02:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="190082680"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 07:02:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xo9zy-0002U5-5G;
	Tue, 11 Nov 2014 11:52:38 +0000
Date: Tue, 11 Nov 2014 11:52:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <20141110183453.GG25609@e104818-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1411111151030.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411101607130.22875@kaball.uk.xensource.com>
	<1415636045-24669-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141110183453.GG25609@e104818-lin.cambridge.arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v8 10/13] xen/arm/arm64: introduce
 xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Nov 2014, Catalin Marinas wrote:
> On Mon, Nov 10, 2014 at 04:14:02PM +0000, Stefano Stabellini wrote:
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> >  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
> >  #define xen_unmap(cookie) iounmap((cookie))
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn);
> > +
> >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> > index 0e96023..1b087cd 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -102,6 +102,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
> >  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
> >  }
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn)
> > +{
> > +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> > +}
> 
> Why not a static inline? It doesn't look like a big function.

Because the next patch is going to make this change:

-   return ((pfn != mfn) && !is_device_dma_coherent(dev));
+   return (!hypercall_cflush && (pfn != mfn) && !is_device_dma_coherent(dev));

and I think it makes sense to keep hypercall_cflush as a static variable
within arch/arm/xen/mm.c (avoid exporting it in page.h).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:03:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoAAd-0004HZ-Q8; Tue, 11 Nov 2014 12:03:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoAAb-0004HC-Vj
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 12:03:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1A/6C-09842-91BF1645; Tue, 11 Nov 2014 12:03:37 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415707413!11900272!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10554 invoked from network); 11 Nov 2014 12:03:36 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 12:03:36 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4DE43ABE7;
	Tue, 11 Nov 2014 12:03:33 +0000 (UTC)
Message-ID: <5461FB14.6090908@suse.com>
Date: Tue, 11 Nov 2014 13:03:32 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, 
	konrad.wilk@oracle.com, david.vrabel@citrix.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<5461F6C7.9070500@citrix.com>
In-Reply-To: <5461F6C7.9070500@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

On 11/11/2014 12:45 PM, Andrew Cooper wrote:
> On 11/11/14 05:43, Juergen Gross wrote:
>> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
>> index fa75842..f67f8cf 100644
>> --- a/arch/x86/xen/p2m.c
>> +++ b/arch/x86/xen/p2m.c
>> @@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
>>   		p2m[i] = INVALID_P2M_ENTRY;
>>   }
>>
>> +static void * __ref alloc_p2m_page(void)
>> +{
>> +	if (unlikely(use_brk))
>> +		return extend_brk(PAGE_SIZE, PAGE_SIZE);
>> +
>> +	if (unlikely(!slab_is_available()))
>> +		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
>> +
>> +	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
>> +}
>> +
>> +static void free_p2m_page(void *p)
>> +{
>> +	free_page((unsigned long)p);
>> +}
>> +
>
> What guarantees are there that free_p2m_page() is only called on p2m
> pages allocated using __get_free_page() ?  I can see from this diff that
> this is the case, but that doesn't help someone coming along in the future.
>
> At the very least, a comment is warranted about the apparent mismatch
> between {alloc,free}_p2m_page().

Okay, I'll add a comment.

>
>> @@ -420,6 +439,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>>   	unsigned long *mfn_list = NULL;
>>   	unsigned long size;
>>
>> +	use_brk = 0;
>>   	va_start = xen_start_info->mfn_list;
>>   	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
>>   	 * so make sure it is rounded up to that */
>> @@ -484,6 +504,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>>   #else
>>   unsigned long __init xen_revector_p2m_tree(void)
>>   {
>> +	use_brk = 0;
>>   	return 0;
>>   }
>>   #endif
>
> This appears to be a completely orphaned function.
>
> It has a split definition based on CONFIG_X86_64, but the sole caller is
> xen_pagetable_p2m_copy() which is X86_64 only.
>
> How does use_brk get cleared for 32bit PV guests?

Good catch. use_brk is removed in a later patch and I have to admit I
didn't test each patch with 32 bit guests, just some of them (including
the final one, of course).

I'll change (and test) the patch accordingly.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:03:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoAAd-0004HZ-Q8; Tue, 11 Nov 2014 12:03:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoAAb-0004HC-Vj
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 12:03:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1A/6C-09842-91BF1645; Tue, 11 Nov 2014 12:03:37 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415707413!11900272!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10554 invoked from network); 11 Nov 2014 12:03:36 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 12:03:36 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4DE43ABE7;
	Tue, 11 Nov 2014 12:03:33 +0000 (UTC)
Message-ID: <5461FB14.6090908@suse.com>
Date: Tue, 11 Nov 2014 13:03:32 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, 
	konrad.wilk@oracle.com, david.vrabel@citrix.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<5461F6C7.9070500@citrix.com>
In-Reply-To: <5461F6C7.9070500@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

On 11/11/2014 12:45 PM, Andrew Cooper wrote:
> On 11/11/14 05:43, Juergen Gross wrote:
>> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
>> index fa75842..f67f8cf 100644
>> --- a/arch/x86/xen/p2m.c
>> +++ b/arch/x86/xen/p2m.c
>> @@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
>>   		p2m[i] = INVALID_P2M_ENTRY;
>>   }
>>
>> +static void * __ref alloc_p2m_page(void)
>> +{
>> +	if (unlikely(use_brk))
>> +		return extend_brk(PAGE_SIZE, PAGE_SIZE);
>> +
>> +	if (unlikely(!slab_is_available()))
>> +		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
>> +
>> +	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
>> +}
>> +
>> +static void free_p2m_page(void *p)
>> +{
>> +	free_page((unsigned long)p);
>> +}
>> +
>
> What guarantees are there that free_p2m_page() is only called on p2m
> pages allocated using __get_free_page() ?  I can see from this diff that
> this is the case, but that doesn't help someone coming along in the future.
>
> At the very least, a comment is warranted about the apparent mismatch
> between {alloc,free}_p2m_page().

Okay, I'll add a comment.

>
>> @@ -420,6 +439,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>>   	unsigned long *mfn_list = NULL;
>>   	unsigned long size;
>>
>> +	use_brk = 0;
>>   	va_start = xen_start_info->mfn_list;
>>   	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
>>   	 * so make sure it is rounded up to that */
>> @@ -484,6 +504,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>>   #else
>>   unsigned long __init xen_revector_p2m_tree(void)
>>   {
>> +	use_brk = 0;
>>   	return 0;
>>   }
>>   #endif
>
> This appears to be a completely orphaned function.
>
> It has a split definition based on CONFIG_X86_64, but the sole caller is
> xen_pagetable_p2m_copy() which is X86_64 only.
>
> How does use_brk get cleared for 32bit PV guests?

Good catch. use_brk is removed in a later patch and I have to admit I
didn't test each patch with 32 bit guests, just some of them (including
the final one, of course).

I'll change (and test) the patch accordingly.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:19:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12: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 1XoAPL-0004kN-GP; Tue, 11 Nov 2014 12:18:51 +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 1XoAPK-0004kI-OR
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 12:18:50 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	2D/14-22819-AAEF1645; Tue, 11 Nov 2014 12:18:50 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415708329!6353385!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI5MDUzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4010 invoked from network); 11 Nov 2014 12:18:49 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 12:18:49 -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=hBH9ksWnXEchVC7Dr8A2v2E7msNf50QBYOBVBRnjMlmp97IdlGGaGDuU
	2nvqH1Wm+ybgLSJJEwPIX1seHCltrAtReULNdT5kWsDKPxg1Da9WsVE2p
	mhLjW069d/h5ErUEESpQNHjo8r7itShMA69a+20beMlw+YFzCdNHGaB6u
	wx8vduJvoUtTMP7Ea0B596iaILhAkp5+9NqTC9fmqkLi9JNTjWt1Tk8gQ
	+VJwkkpVvAzIHGY2t0VCP//pRBlHM;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1415708329; x=1447244329;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=HSKnSp8B5Lg9k//EK+1IZE7+vN06g2rAmEw9X06rO64=;
	b=GeUMj+f5dQ8eBnbnZvAj+x4x3Vr02H8jBv+ZN/zuobtjDvtA1wv3YYak
	q1YtI5pphD0goi+MMP+5nyL8dFheqYM3l08eQMU+pQZuf+OBvYH0oJ3wG
	crX5ahKxXqUiWT45plV2iixQxxJqnQmMPRdUocFBxZD1xF7cNfpxIkP6o
	nPshEflW//8aPRrO7SuUVinFT9W/Te+7tmkg+g9QkbhsSVXjlCluk56sM
	aDDLGATiZtSaP3LjCCwf4wv+34o2R;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="5.07,360,1413237600"; d="scan'208";a="212844328"
Received: from unknown (HELO abgdgate60u.abg.fsc.net) ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 11 Nov 2014 13:18:49 +0100
X-IronPort-AV: E=Sophos;i="5.07,360,1413237600"; d="scan'208";a="96034079"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate60u.abg.fsc.net with ESMTP; 11 Nov 2014 13:18:48 +0100
Received: from amur.localnet (amur.mch.fsc.net [10.172.102.32])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id CA704A6EFF1;
	Tue, 11 Nov 2014 13:18:48 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Tue, 11 Nov 2014 13:18:48 +0100
Message-ID: <19147765.FEreuxd8Ya@amur>
User-Agent: KMail/4.11.5 (Linux/3.11.10-21-xen; KDE/4.11.5; x86_64; ; )
MIME-Version: 1.0
Cc: jgross@suse.com
Subject: [Xen-devel] Wrong cpupool 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

Hi list,

When creating a cpupool, starting and destroying a guest within this pool,
then removing this pool doesn't work because of EBUSY.

It seems the cause of this behavior is the commit
bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.

In domain_kill() the function sched_move_domain() gets called changing the
d->cpupool pointer to the new cpupool without incrementing/decrementing the
counters "n_dom" of the new/old cpupool.

This leads to decrementing the wrong  cpupool0->n_dom counter when
cpupool_rm_domain() gets called at the end and my own cpupool can't be
destroyed because n_dom = 1!

I don't have a fast patch because I'am not enough familiar with the code
this time but I think it should be fixed for 4.5.

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:19:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12: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 1XoAPL-0004kN-GP; Tue, 11 Nov 2014 12:18:51 +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 1XoAPK-0004kI-OR
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 12:18:50 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	2D/14-22819-AAEF1645; Tue, 11 Nov 2014 12:18:50 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415708329!6353385!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI5MDUzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4010 invoked from network); 11 Nov 2014 12:18:49 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 12:18:49 -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=hBH9ksWnXEchVC7Dr8A2v2E7msNf50QBYOBVBRnjMlmp97IdlGGaGDuU
	2nvqH1Wm+ybgLSJJEwPIX1seHCltrAtReULNdT5kWsDKPxg1Da9WsVE2p
	mhLjW069d/h5ErUEESpQNHjo8r7itShMA69a+20beMlw+YFzCdNHGaB6u
	wx8vduJvoUtTMP7Ea0B596iaILhAkp5+9NqTC9fmqkLi9JNTjWt1Tk8gQ
	+VJwkkpVvAzIHGY2t0VCP//pRBlHM;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1415708329; x=1447244329;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=HSKnSp8B5Lg9k//EK+1IZE7+vN06g2rAmEw9X06rO64=;
	b=GeUMj+f5dQ8eBnbnZvAj+x4x3Vr02H8jBv+ZN/zuobtjDvtA1wv3YYak
	q1YtI5pphD0goi+MMP+5nyL8dFheqYM3l08eQMU+pQZuf+OBvYH0oJ3wG
	crX5ahKxXqUiWT45plV2iixQxxJqnQmMPRdUocFBxZD1xF7cNfpxIkP6o
	nPshEflW//8aPRrO7SuUVinFT9W/Te+7tmkg+g9QkbhsSVXjlCluk56sM
	aDDLGATiZtSaP3LjCCwf4wv+34o2R;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="5.07,360,1413237600"; d="scan'208";a="212844328"
Received: from unknown (HELO abgdgate60u.abg.fsc.net) ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 11 Nov 2014 13:18:49 +0100
X-IronPort-AV: E=Sophos;i="5.07,360,1413237600"; d="scan'208";a="96034079"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate60u.abg.fsc.net with ESMTP; 11 Nov 2014 13:18:48 +0100
Received: from amur.localnet (amur.mch.fsc.net [10.172.102.32])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id CA704A6EFF1;
	Tue, 11 Nov 2014 13:18:48 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Tue, 11 Nov 2014 13:18:48 +0100
Message-ID: <19147765.FEreuxd8Ya@amur>
User-Agent: KMail/4.11.5 (Linux/3.11.10-21-xen; KDE/4.11.5; x86_64; ; )
MIME-Version: 1.0
Cc: jgross@suse.com
Subject: [Xen-devel] Wrong cpupool 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

Hi list,

When creating a cpupool, starting and destroying a guest within this pool,
then removing this pool doesn't work because of EBUSY.

It seems the cause of this behavior is the commit
bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.

In domain_kill() the function sched_move_domain() gets called changing the
d->cpupool pointer to the new cpupool without incrementing/decrementing the
counters "n_dom" of the new/old cpupool.

This leads to decrementing the wrong  cpupool0->n_dom counter when
cpupool_rm_domain() gets called at the end and my own cpupool can't be
destroyed because n_dom = 1!

I don't have a fast patch because I'am not enough familiar with the code
this time but I think it should be fixed for 4.5.

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:28:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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.xen.org>)
	id 1XoAYB-00050c-KL; Tue, 11 Nov 2014 12:27:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1XoAYA-00050X-HY
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 12:27:58 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	6A/C9-16982-DC002645; Tue, 11 Nov 2014 12:27:57 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415708876!11856605!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4805 invoked from network); 11 Nov 2014 12:27:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 12:27:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="26701991"
From: Thanos Makatos <thanos.makatos@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Thread-Topic: [Xen-devel] [PATCH] introduce grant copy for user land
Thread-Index: AQHP95BvMwOS2+bnLkC54UJZVlEzjpxbZgBw
Date: Tue, 11 Nov 2014 12:27:55 +0000
Message-ID: <2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
	<5457C35F.50504@citrix.com>
In-Reply-To: <5457C35F.50504@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 arbitrary limitations in number of ops and page alignment should be
> removed.  I think both can be removed relatively easily by consuming page
> aligned chunks of segments and doign the hypercall when a batch of ops is
> filled.

Wouldn't this lead to multiple calls to gnttab_batch_copy(), potentially hurting performance?

> > +#define IOCTL_GNTDEV_GRANT_COPY \
> > +_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
> > +struct ioctl_gntdev_grant_copy {
> > +	/*
> > +	 * copy direction: 0 to copy to guest, 1 to copy from guest
> > +	 */
> > +	int dir;
> 
> I think this dir should be per-segment and use the GNTCPY_source_gref and
> GNTCOPY_dest_gref flags, since per-op direction is what the hypercall
> provides.

OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:28:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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.xen.org>)
	id 1XoAYB-00050c-KL; Tue, 11 Nov 2014 12:27:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1XoAYA-00050X-HY
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 12:27:58 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	6A/C9-16982-DC002645; Tue, 11 Nov 2014 12:27:57 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415708876!11856605!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4805 invoked from network); 11 Nov 2014 12:27:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 12:27:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,360,1413244800"; d="scan'208";a="26701991"
From: Thanos Makatos <thanos.makatos@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Thread-Topic: [Xen-devel] [PATCH] introduce grant copy for user land
Thread-Index: AQHP95BvMwOS2+bnLkC54UJZVlEzjpxbZgBw
Date: Tue, 11 Nov 2014 12:27:55 +0000
Message-ID: <2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
	<5457C35F.50504@citrix.com>
In-Reply-To: <5457C35F.50504@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 arbitrary limitations in number of ops and page alignment should be
> removed.  I think both can be removed relatively easily by consuming page
> aligned chunks of segments and doign the hypercall when a batch of ops is
> filled.

Wouldn't this lead to multiple calls to gnttab_batch_copy(), potentially hurting performance?

> > +#define IOCTL_GNTDEV_GRANT_COPY \
> > +_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
> > +struct ioctl_gntdev_grant_copy {
> > +	/*
> > +	 * copy direction: 0 to copy to guest, 1 to copy from guest
> > +	 */
> > +	int dir;
> 
> I think this dir should be per-segment and use the GNTCPY_source_gref and
> GNTCOPY_dest_gref flags, since per-op direction is what the hypercall
> provides.

OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:39:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12:39:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoAjV-0005HE-1W; Tue, 11 Nov 2014 12:39:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.haxby@oracle.com>) id 1XoAjT-0005H9-9y
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 12:39:39 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	DE/47-22777-A8302645; Tue, 11 Nov 2014 12:39:38 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415709576!8421364!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8700 invoked from network); 11 Nov 2014 12:39:37 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 12:39:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABCdYhP006518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 12:39:35 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABCdXwt011581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 12:39:34 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABCdXxh025058
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 12:39:33 GMT
Received: from sheep.uk.oracle.com (/10.175.220.126)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 04:39:33 -0800
Message-ID: <54620381.6060503@oracle.com>
Date: Tue, 11 Nov 2014 12:39:29 +0000
From: John Haxby <john.haxby@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <21557.24142.873029.148164@mariner.uk.xensource.com>	<21557.50031.783473.873273@chiark.greenend.org.uk>	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
In-Reply-To: <21600.64887.416522.656249@chiark.greenend.org.uk>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/14 18:01, Ian Jackson wrote:
>     * Domain name(s) which you use to provide Xen software/services.

This makes sense for a services provider but I'm not sure what it means
for a distro.   Is this intended to mean a download location for an
installation image and updates?    If it's a download location wouldn't
a URL make more sense?

jch

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:39:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12:39:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoAjV-0005HE-1W; Tue, 11 Nov 2014 12:39:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.haxby@oracle.com>) id 1XoAjT-0005H9-9y
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 12:39:39 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	DE/47-22777-A8302645; Tue, 11 Nov 2014 12:39:38 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415709576!8421364!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8700 invoked from network); 11 Nov 2014 12:39:37 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 12:39:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABCdYhP006518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 12:39:35 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABCdXwt011581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 12:39:34 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABCdXxh025058
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 12:39:33 GMT
Received: from sheep.uk.oracle.com (/10.175.220.126)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 04:39:33 -0800
Message-ID: <54620381.6060503@oracle.com>
Date: Tue, 11 Nov 2014 12:39:29 +0000
From: John Haxby <john.haxby@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <21557.24142.873029.148164@mariner.uk.xensource.com>	<21557.50031.783473.873273@chiark.greenend.org.uk>	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
In-Reply-To: <21600.64887.416522.656249@chiark.greenend.org.uk>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/14 18:01, Ian Jackson wrote:
>     * Domain name(s) which you use to provide Xen software/services.

This makes sense for a services provider but I'm not sure what it means
for a distro.   Is this intended to mean a download location for an
installation image and updates?    If it's a download location wouldn't
a URL make more sense?

jch

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:52:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12:52:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoAvZ-0005Zn-IF; Tue, 11 Nov 2014 12:52:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1XoApU-0005Wr-Qe
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 12:45:52 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	AF/EE-11581-00502645; Tue, 11 Nov 2014 12:45:52 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415709947!8423145!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24392 invoked from network); 11 Nov 2014 12:45:51 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 12:45:51 -0000
Received: from 172.24.2.119 (EHLO SZXEMA408-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CCE76088; Tue, 11 Nov 2014 20:45:46 +0800 (CST)
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.174]) by
	SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id
	14.03.0158.001; Tue, 11 Nov 2014 20:45:36 +0800
From: Liuyongan <liuyongan@huawei.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: ioreq process conflict when  EVTCHNOP_bind_interdomain
	hypercall and vcpu pio occur concurrently
Thread-Index: Ac/9rVq1IRZuUMpZQbCRp6vd6elF1A==
Date: Tue, 11 Nov 2014 12:45:35 +0000
Message-ID: <E4ABEE53CC34664FA3F0BD8AEAF50A1958CCA4D2@SZXEMA512-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: A4p3 A4wo CQZr C3ZO EBNb E924 FEtQ F2Nu GwOb Kj2/ LzEF
	L3Q3 M42H OXJA QkF1 S2xW; 2;
	agBiAGUAdQBsAGkAYwBoAEAAcwB1AHMAZQAuAGMAbwBtADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgAuAG8AcgBnAA==;
	Sosha1_v1; 7; {DE791CC9-11B1-4C8F-BAAC-C81555FFC447};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Tue,
	11 Nov 2014 12:45:27 GMT;
	aQBvAHIAZQBxACAAcAByAG8AYwBlAHMAcwAgAGMAbwBuAGYAbABpAGMAdAAgAHcAaABlAG4AIAAgAEUAVgBUAEMASABOAE8AUABfAGIAaQBuAGQAXwBpAG4AdABlAHIAZABvAG0AYQBpAG4AIABoAHkAcABlAHIAYwBhAGwAbAAgAGEAbgBkACAAdgBjAHAAdQAgAHAAaQBvACAAbwBjAGMAdQByACAAYwBvAG4AYwB1AHIAcgBlAG4AdABsAHkA
x-cr-puzzleid: {DE791CC9-11B1-4C8F-BAAC-C81555FFC447}
x-originating-ip: [10.177.20.146]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Tue, 11 Nov 2014 12:52:08 +0000
Cc: Qianhuibin <qianhuibin@huawei.com>, zhangyuexi <zhangyuexi@huawei.com>,
	"Shanhaitao \(Tony\)" <shanhaitao1@huawei.com>,
	Fanhenglong <fanhenglong@huawei.com>,
	Huangzhichao <huangzhichao@huawei.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: [Xen-devel] ioreq process conflict when EVTCHNOP_bind_interdomain
 hypercall and vcpu pio occur concurrently
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 it is necessary for xen to trigger the event channel pending when the port related a vcpu port io.

Suppose a scenario as follows:

1)  Qemu make a hypercall using codes:
     for (i = 0; i < smp_cpus; i++) {
        rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
                                        xen_vcpu_eport(state->shared_page, i));
        if (rc == -1) {
            fprintf(stderr, "bind interdomain ioctl(shared_page) error %d\n", errno);
            return -1;
        }
        state->ioreq_local_port[i] = rc;
        ...
     }

2)  Xen do_event_channel_op allocate a free port and call evtchn_set_pending to trigger a evtchn event.

3)  Qemu enters main_loop and begin the evtchn event (pio event).

4)  The vcpus of a vm begin to trigger real pio exit,  and this ioreq_t will conflict with the one triggered in step 2.

This will certainly cause failures of real port io.  

Does anyone here have any suggestions? 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 12:52:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 12:52:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoAvZ-0005Zn-IF; Tue, 11 Nov 2014 12:52:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1XoApU-0005Wr-Qe
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 12:45:52 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	AF/EE-11581-00502645; Tue, 11 Nov 2014 12:45:52 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415709947!8423145!1
X-Originating-IP: [119.145.14.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NSA9PiA3NzQ2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24392 invoked from network); 11 Nov 2014 12:45:51 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 12:45:51 -0000
Received: from 172.24.2.119 (EHLO SZXEMA408-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CCE76088; Tue, 11 Nov 2014 20:45:46 +0800 (CST)
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.174]) by
	SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id
	14.03.0158.001; Tue, 11 Nov 2014 20:45:36 +0800
From: Liuyongan <liuyongan@huawei.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: ioreq process conflict when  EVTCHNOP_bind_interdomain
	hypercall and vcpu pio occur concurrently
Thread-Index: Ac/9rVq1IRZuUMpZQbCRp6vd6elF1A==
Date: Tue, 11 Nov 2014 12:45:35 +0000
Message-ID: <E4ABEE53CC34664FA3F0BD8AEAF50A1958CCA4D2@SZXEMA512-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: A4p3 A4wo CQZr C3ZO EBNb E924 FEtQ F2Nu GwOb Kj2/ LzEF
	L3Q3 M42H OXJA QkF1 S2xW; 2;
	agBiAGUAdQBsAGkAYwBoAEAAcwB1AHMAZQAuAGMAbwBtADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgAuAG8AcgBnAA==;
	Sosha1_v1; 7; {DE791CC9-11B1-4C8F-BAAC-C81555FFC447};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Tue,
	11 Nov 2014 12:45:27 GMT;
	aQBvAHIAZQBxACAAcAByAG8AYwBlAHMAcwAgAGMAbwBuAGYAbABpAGMAdAAgAHcAaABlAG4AIAAgAEUAVgBUAEMASABOAE8AUABfAGIAaQBuAGQAXwBpAG4AdABlAHIAZABvAG0AYQBpAG4AIABoAHkAcABlAHIAYwBhAGwAbAAgAGEAbgBkACAAdgBjAHAAdQAgAHAAaQBvACAAbwBjAGMAdQByACAAYwBvAG4AYwB1AHIAcgBlAG4AdABsAHkA
x-cr-puzzleid: {DE791CC9-11B1-4C8F-BAAC-C81555FFC447}
x-originating-ip: [10.177.20.146]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Tue, 11 Nov 2014 12:52:08 +0000
Cc: Qianhuibin <qianhuibin@huawei.com>, zhangyuexi <zhangyuexi@huawei.com>,
	"Shanhaitao \(Tony\)" <shanhaitao1@huawei.com>,
	Fanhenglong <fanhenglong@huawei.com>,
	Huangzhichao <huangzhichao@huawei.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: [Xen-devel] ioreq process conflict when EVTCHNOP_bind_interdomain
 hypercall and vcpu pio occur concurrently
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 it is necessary for xen to trigger the event channel pending when the port related a vcpu port io.

Suppose a scenario as follows:

1)  Qemu make a hypercall using codes:
     for (i = 0; i < smp_cpus; i++) {
        rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
                                        xen_vcpu_eport(state->shared_page, i));
        if (rc == -1) {
            fprintf(stderr, "bind interdomain ioctl(shared_page) error %d\n", errno);
            return -1;
        }
        state->ioreq_local_port[i] = rc;
        ...
     }

2)  Xen do_event_channel_op allocate a free port and call evtchn_set_pending to trigger a evtchn event.

3)  Qemu enters main_loop and begin the evtchn event (pio event).

4)  The vcpus of a vm begin to trigger real pio exit,  and this ioreq_t will conflict with the one triggered in step 2.

This will certainly cause failures of real port io.  

Does anyone here have any suggestions? 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKG-0006At-Tx; Tue, 11 Nov 2014 13:17:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKF-0006A3-RS
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:40 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	72/5A-25727-37C02645; Tue, 11 Nov 2014 13:17:39 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415711855!11763558!1
X-Originating-IP: [64.18.0.188]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11468 invoked from network); 11 Nov 2014 13:17:37 -0000
Received: from exprod5og109.obsmtp.com (HELO exprod5og109.obsmtp.com)
	(64.18.0.188)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:37 -0000
Received: from mail-lb0-f170.google.com ([209.85.217.170]) (using TLSv1) by
	exprod5ob109.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMb9twkL/yGGdZA0MBN9LP/H7JlJmS@postini.com;
	Tue, 11 Nov 2014 05:17:37 PST
Received: by mail-lb0-f170.google.com with SMTP id p9so4397649lbv.29
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=TEp0XXM33rjuFXHRkECxmQNY/0lo/sUJ1ABQu6H7wAI=;
	b=PJTNGrqANwEK/cszSWGsCZN4g3CGQdTaJ65HLkIuyqR2oPeeqKnd4nEpVCWND+GR/z
	mezDjOVqj6ScNC2rCHfaZ1KC/7Dk0i7QbdHO8ohbzuyNvjOaLcua9HvWrp21P742+CON
	iqypXLa58jR6Sz2y/Vq1+aC/x4aeGUCQEqA1Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=TEp0XXM33rjuFXHRkECxmQNY/0lo/sUJ1ABQu6H7wAI=;
	b=mea6IXV/I++7hZZ17bviVclvUdo1vFSZJUY+Wc1/0TFmd7yuTpiIMVk5ad+bZURATN
	z5ij60xCEk9IbYEYED1aPHP4d/GLL0xhxLR29grjyMs0zrjEtCRWCQ78gJAJkiDV3E+s
	2lhqoFDJdN5JOGynC+mPVxTziDveZylsuE2+BT+0SR6Nz5LLikFkSUafDaJyBCPU6CGz
	vvBf9gU14Fj+DVY6rXKsiuHqyMPHkeXpiXXcn7kM0Hl7FxAywwMX+BdKTZ5bGY5uIfrY
	EVNmWO8RT1hCraXJLqxc5E8n6/+sbyVjoDV6fVwc5cm69haxYL977ys5d1wrxc0DXTmn
	ixmQ==
X-Gm-Message-State: ALoCoQmTmMmOrPTH89DTkd9F7fjDyPDt5MsFtNutDN+uQv8udr5c7inl4hSxfGii4DJxZjVh2Wmpcso2WtDK4kEhkqQrjP2kMlbQ4Vb76743ROxbgefbwjbEGgn0JGuFi/tJ6Ai2dO1y+7TCvXdeBmsFmFCY4SYJJw==
X-Received: by 10.152.29.8 with SMTP id f8mr36199479lah.56.1415711853856;
	Tue, 11 Nov 2014 05:17:33 -0800 (PST)
X-Received: by 10.152.29.8 with SMTP id f8mr36199468lah.56.1415711853769;
	Tue, 11 Nov 2014 05:17:33 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id kl4sm1022963lbc.22.2014.11.11.05.17.32
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:32 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:08 +0200
Message-Id: <1415711834-1740-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 06/12] cpufreq: make cpufreq driver more
	generalizable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

First implementation of the cpufreq driver has been
written with x86 in mind. This patch makes possible
the cpufreq driver be working on both x86 and arm
architectures.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                     |  1 +
 xen/drivers/cpufreq/cpufreq.c    | 80 +++++++++++++++++++++++++++++++++++++---
 xen/include/public/platform.h    |  1 +
 xen/include/xen/processor_perf.h |  7 ++++
 4 files changed, 83 insertions(+), 6 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 5953152..3b0b89b 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -55,6 +55,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
 CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index f5f4d75..1644096 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -43,7 +43,6 @@
 #include <asm/io.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
-#include <acpi/acpi.h>
 #include <xen/cpufreq.h>
 
 static unsigned int __read_mostly usr_min_freq;
@@ -192,6 +191,7 @@ int cpufreq_add_cpu(unsigned int cpu)
     } else {
         /* domain sanity check under whatever coordination type */
         firstcpu = cpumask_first(cpufreq_dom->map);
+#ifdef CONFIG_ACPI
         if ((perf->domain_info.coord_type !=
             processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
             (perf->domain_info.num_processors !=
@@ -207,6 +207,18 @@ int cpufreq_add_cpu(unsigned int cpu)
                 );
             return -EINVAL;
         }
+#else /* CONFIG_ACPI */
+        if ((perf->domain_info.num_processors !=
+            processor_pminfo[firstcpu]->perf.domain_info.num_processors)) {
+
+            printk(KERN_WARNING "cpufreq fail to add CPU%d:"
+                   "incorrect num processors (%"PRIu64"), expect(%"PRIu64")\n",
+                   cpu, perf->domain_info.num_processors,
+                   processor_pminfo[firstcpu]->perf.domain_info.num_processors
+                );
+            return -EINVAL;
+        }
+#endif /* CONFIG_ACPI */
     }
 
     if (!domexist || hw_all) {
@@ -363,6 +375,7 @@ int cpufreq_del_cpu(unsigned int cpu)
     return 0;
 }
 
+#ifdef CONFIG_ACPI
 static void print_PCT(struct xen_pct_register *ptr)
 {
     printk("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
@@ -370,12 +383,14 @@ static void print_PCT(struct xen_pct_register *ptr)
            ptr->descriptor, ptr->length, ptr->space_id, ptr->bit_width,
            ptr->bit_offset, ptr->reserved, ptr->address);
 }
+#endif
 
 static void print_PSS(struct xen_processor_px *ptr, int count)
 {
     int i;
     printk("\t_PSS: state_count=%d\n", count);
     for (i=0; i<count; i++){
+#ifdef CONFIG_ACPI
         printk("\tState%d: %"PRId64"MHz %"PRId64"mW %"PRId64"us "
                "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",
                i,
@@ -385,15 +400,26 @@ static void print_PSS(struct xen_processor_px *ptr, int count)
                ptr[i].bus_master_latency,
                ptr[i].control,
                ptr[i].status);
+#else /* CONFIG_ACPI */
+        printk("\tState%d: %"PRId64"MHz %"PRId64"us\n",
+               i,
+               ptr[i].core_frequency,
+               ptr[i].transition_latency);
+#endif /* CONFIG_ACPI */
     }
 }
 
 static void print_PSD( struct xen_psd_package *ptr)
 {
+#ifdef CONFIG_ACPI
     printk("\t_PSD: num_entries=%"PRId64" rev=%"PRId64
            " domain=%"PRId64" coord_type=%"PRId64" num_processors=%"PRId64"\n",
            ptr->num_entries, ptr->revision, ptr->domain, ptr->coord_type,
            ptr->num_processors);
+#else /* CONFIG_ACPI */
+    printk("\t_PSD:  domain=%"PRId64" num_processors=%"PRId64"\n",
+           ptr->domain, ptr->num_processors);
+#endif /* CONFIG_ACPI */
 }
 
 static void print_PPC(unsigned int platform_limit)
@@ -401,13 +427,53 @@ static void print_PPC(unsigned int platform_limit)
     printk("\t_PPC: %d\n", platform_limit);
 }
 
+static inline uint32_t is_pss_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PSS;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_psd_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PSD;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_ppc_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PPC;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_all_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags == ( XEN_PX_PCT | XEN_PX_PSS | XEN_PX_PSD | XEN_PX_PPC );
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
 int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_info)
 {
     int ret=0, cpuid;
     struct processor_pminfo *pmpt;
     struct processor_performance *pxpt;
 
+#ifdef CONFIG_ACPI
     cpuid = get_cpu_id(acpi_id);
+#else
+    cpuid = acpi_id;
+#endif
     if ( cpuid < 0 || !dom0_px_info)
     {
         ret = -EINVAL;
@@ -429,6 +495,8 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
         processor_pminfo[cpuid] = pmpt;
     }
     pxpt = &pmpt->perf;
+
+#ifdef CONFIG_ACPI
     pmpt->acpi_id = acpi_id;
     pmpt->id = cpuid;
 
@@ -455,8 +523,9 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PCT(&pxpt->status_register);
         }
     }
+#endif /* CONFIG_ACPI */
 
-    if ( dom0_px_info->flags & XEN_PX_PSS ) 
+    if ( is_pss_data(dom0_px_info) )
     {
         /* capability check */
         if (dom0_px_info->state_count <= 1)
@@ -483,7 +552,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PSS(pxpt->states,pxpt->state_count);
     }
 
-    if ( dom0_px_info->flags & XEN_PX_PSD )
+    if ( is_psd_data(dom0_px_info) )
     {
         /* check domain coordination */
         if (dom0_px_info->shared_type != CPUFREQ_SHARED_TYPE_ALL &&
@@ -503,7 +572,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PSD(&pxpt->domain_info);
     }
 
-    if ( dom0_px_info->flags & XEN_PX_PPC )
+    if ( is_ppc_data(dom0_px_info) )
     {
         pxpt->platform_limit = dom0_px_info->platform_limit;
 
@@ -517,8 +586,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
         }
     }
 
-    if ( dom0_px_info->flags == ( XEN_PX_PCT | XEN_PX_PSS |
-                XEN_PX_PSD | XEN_PX_PPC ) )
+    if ( is_all_data(dom0_px_info) )
     {
         pxpt->init = XEN_PX_INIT;
 
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 4341f54..ccb7969 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -358,6 +358,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t);
 #define XEN_PX_PSS   2
 #define XEN_PX_PPC   4
 #define XEN_PX_PSD   8
+#define XEN_PX_DATA  16
 
 struct xen_power_register {
     uint32_t     space_id;
diff --git a/xen/include/xen/processor_perf.h b/xen/include/xen/processor_perf.h
index d8a1ba6..6c1279d 100644
--- a/xen/include/xen/processor_perf.h
+++ b/xen/include/xen/processor_perf.h
@@ -3,7 +3,10 @@
 
 #include <public/platform.h>
 #include <public/sysctl.h>
+
+#ifdef CONFIG_ACPI
 #include <xen/acpi.h>
+#endif
 
 #define XEN_PX_INIT 0x80000000
 
@@ -24,8 +27,10 @@ int  cpufreq_del_cpu(unsigned int);
 struct processor_performance {
     uint32_t state;
     uint32_t platform_limit;
+#ifdef CONFIG_ACPI
     struct xen_pct_register control_register;
     struct xen_pct_register status_register;
+#endif
     uint32_t state_count;
     struct xen_processor_px *states;
     struct xen_psd_package domain_info;
@@ -35,8 +40,10 @@ struct processor_performance {
 };
 
 struct processor_pminfo {
+#ifdef CONFIG_ACPI
     uint32_t acpi_id;
     uint32_t id;
+#endif
     struct processor_performance    perf;
 };
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBK6-000672-54; Tue, 11 Nov 2014 13:17:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBK4-00066p-D4
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:28 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	61/27-24124-76C02645; Tue, 11 Nov 2014 13:17:27 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415711844!6368681!1
X-Originating-IP: [64.18.0.189]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12008 invoked from network); 11 Nov 2014 13:17:26 -0000
Received: from exprod5og119.obsmtp.com (HELO exprod5og119.obsmtp.com)
	(64.18.0.189)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 13:17:26 -0000
Received: from mail-la0-f43.google.com ([209.85.215.43]) (using TLSv1) by
	exprod5ob119.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMZIV5bwv8La6XVuA71vpNR/ivALsX@postini.com;
	Tue, 11 Nov 2014 05:17:26 PST
Received: by mail-la0-f43.google.com with SMTP id ge10so9627793lab.16
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=D1leJIJzsTzTSyc0hUuYcZ38eLO7gkRqvj/NBqjScY8=;
	b=htNoTlcbbI8rUfou+PtbGZnZQhxuCE/7pCOdQ2joIjZALZXIMliLMgucqwB+asWdAJ
	zZ3GrhBNAg9Ms5lN2sSrUGYG5zku2+3tFs61souDnokeW7sz8I/CchLPYOMQ+iPLLdCk
	bXmVg4ti3oK1rE8e1OcU/S2lYcmPGHzVNUEdw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=D1leJIJzsTzTSyc0hUuYcZ38eLO7gkRqvj/NBqjScY8=;
	b=iaHgfxURhP1qeBlK5yrqp6YvJkVvvLhkYi1OAvqDD8kyTX0CsOG1iTvLEiOj6HMDVV
	x5wB5a1hpmhXzOT8pGbx9YntMEHywLKavEjxbUYTGqeIv+Js91yWx8e9AwQFJN22OO51
	QO5YXcHBXGHyRf2NzPoqigvAi6c183ItRh4rsF8MXhgjNZcP4Zqpqq9kn9Q31jb/l2NM
	4Bid1H42nZU4pV9n9WHMj6Tv718+H1+p7G6wE4XlE0PJIucF6WT1BuN6tgv/OwmrQso0
	aaSy2rIBE7sfX+KKRwHlWcLXxxt2t2CcyDVFVrejs+jTETzCd78VYKvOrA4+w1vuvpiX
	Y3MA==
X-Gm-Message-State: ALoCoQlFO4YHglD2vbq9SFZVg43mM8U7GBd3cTHkwIreD7gwfRIij+0me1CJuIhIvO4vAihhuSxqXDma6AE82OBpnvlrgSyGTovt8OR6VLVI41LVFUBh4pjNfSUTveyQlfO7H0JiqIT7KBtMyhqtruSAKvy2ay1S/w==
X-Received: by 10.152.21.9 with SMTP id r9mr10043505lae.76.1415711842967;
	Tue, 11 Nov 2014 05:17:22 -0800 (PST)
X-Received: by 10.152.21.9 with SMTP id r9mr10043495lae.76.1415711842887;
	Tue, 11 Nov 2014 05:17:22 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id lu5sm4829050lac.0.2014.11.11.05.17.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:22 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:04 +0200
Message-Id: <1415711834-1740-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 02/12] pm: move processor_perf.h file to
	the xen/include/xen location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 MAINTAINERS                                        | 2 +-
 xen/arch/x86/platform_hypercall.c                  | 2 +-
 xen/include/xen/cpufreq.h                          | 2 +-
 xen/include/{acpi/cpufreq => xen}/processor_perf.h | 0
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename xen/include/{acpi/cpufreq => xen}/processor_perf.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 49f56a1..f4d916e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -234,8 +234,8 @@ F:	xen/arch/x86/acpi/
 X:	xen/arch/x86/acpi/boot.c
 X:	xen/arch/x86/acpi/lib.c
 F:	xen/drivers/cpufreq/
-F:	xen/include/acpi/cpufreq/
 F:	xen/include/xen/cpufreq.h
+F:	xen/include/xen/processor_perf.h
 
 QEMU-DM
 M:	Ian Jackson <ian.jackson@eu.citrix.com>
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 2162811..7ce8592 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -25,7 +25,7 @@
 #include <xen/irq.h>
 #include <asm/current.h>
 #include <public/platform.h>
-#include <acpi/cpufreq/processor_perf.h>
+#include <xen/processor_perf.h>
 #include <asm/edd.h>
 #include <asm/mtrr.h>
 #include <asm/io_apic.h>
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index fa653ef..82dc4dc 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -21,7 +21,7 @@
 #include <xen/errno.h>
 #include <xen/cpumask.h>
 
-#include <acpi/cpufreq/processor_perf.h>
+#include <xen/processor_perf.h>
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
diff --git a/xen/include/acpi/cpufreq/processor_perf.h b/xen/include/xen/processor_perf.h
similarity index 100%
rename from xen/include/acpi/cpufreq/processor_perf.h
rename to xen/include/xen/processor_perf.h
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKJ-0006CZ-B8; Tue, 11 Nov 2014 13:17:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKI-0006Bf-CL
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:42 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	9D/C1-17694-57C02645; Tue, 11 Nov 2014 13:17:41 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415711858!11833149!1
X-Originating-IP: [64.18.0.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18466 invoked from network); 11 Nov 2014 13:17:40 -0000
Received: from exprod5og118.obsmtp.com (HELO exprod5og118.obsmtp.com)
	(64.18.0.160)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:40 -0000
Received: from mail-lb0-f173.google.com ([209.85.217.173]) (using TLSv1) by
	exprod5ob118.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMccAVFPp2J/MjPWkQoubGFE95RfL3@postini.com;
	Tue, 11 Nov 2014 05:17:40 PST
Received: by mail-lb0-f173.google.com with SMTP id n15so7691056lbi.18
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=+oiOKckGVDosptw1S7D6HF8HmwOpIZSsoFCNbEeDF1Y=;
	b=iWCRI/Y0nkdoVDuDuFbcUNpKg8RzRc90RQ4G0JESFk+C9JHNoI0cxR4y0d3cZBsnbe
	GNfyrCe3CqkY58bsqQkEb++7+O7TT3WQHcF/G5Ws6Pdj+0YgqMHBfkCOtGxAlKHMshIJ
	0vlCaSWCsKlUcxP4U9O5ZfeNK+g4ilK6SzCq0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=+oiOKckGVDosptw1S7D6HF8HmwOpIZSsoFCNbEeDF1Y=;
	b=Ris5AZucqYBla8SrRIVPxmOPdl469Tny7JwxqKvLMTrSrx09fRMoniiBSfuwsCzQTN
	Uz9/XPBpdFuLUDrYItwyjAPkZyMumv6Spi9hcOJgXRFKlDgCZVFFC23BAG9gWaGdjYKw
	QVVzEHd8o7InHqtLu9mqHXWOizPhZTBPYC1cdCRaWtLqiw8YGYpHdO5AYes6XkHxjJQ/
	9+NzJyuQA9JY5Mu2nm4Kt2L4LW78xuOD2Q4IIw0dWiUkZ4gOVn92ghQyDtI9SdfQP4QX
	6rg2X/e/+HBrwHwuu/EUpCkuTdk4BDAfIqGpuDIhEb6R1gEZq/G0MKVUcl7Z1mf88dSx
	Ua+Q==
X-Gm-Message-State: ALoCoQkuKDnCWbi2pna8UISHhrsijqdIQ+WHwei+DXSR4lksfcjQzMWAoycKl4h0sFYnpjdZmvbijdkspHHjt8xTuOSPygfOSc0k3xbstqkA5o7LpDXLDUw0Rl34lKMAwh6dsJCt85qbZ2+ABq918+1QPboiFu015Q==
X-Received: by 10.152.88.69 with SMTP id be5mr36404093lab.36.1415711856506;
	Tue, 11 Nov 2014 05:17:36 -0800 (PST)
X-Received: by 10.152.88.69 with SMTP id be5mr36404081lab.36.1415711856440;
	Tue, 11 Nov 2014 05:17:36 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id j2sm5980607lbp.16.2014.11.11.05.17.35
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:35 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:09 +0200
Message-Id: <1415711834-1740-8-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 07/12] arch/arm: create device tree nodes
	for hwdom cpufreq cpu driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch copies all cpu@0..cpu@N nodes (from input
device tree) with properties to /hypervisor/pcpus
node (device tree for hwdom). Thus we can give all
information about all physical CPUs in the pcpus node.
Driver in hwdom should parse /hypervisor/pcpus path
instead of the /cpus path in the device tree.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/domain_build.c | 78 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 70 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2db0236..87e05c7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -326,8 +326,64 @@ static int make_memory_node(const struct domain *d,
     return res;
 }
 
-static int make_hypervisor_node(struct domain *d,
-                                void *fdt, const struct dt_device_node *parent)
+#ifdef HAS_HWDOM_CPUFREQ
+static int fdt_copy_phys_cpus_nodes(struct domain *d, struct kernel_info *kinfo)
+{
+    int res;
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *npcpu;
+    char *node_name;
+
+    if ( !cpus )
+    {
+        dprintk(XENLOG_ERR, "Missing /cpus node in the device tree?\n");
+        return -ENOENT;
+    }
+
+    /*
+     * create pcpus node and copy to it
+     * original cpu@0..cpu@N nodes with its properties.
+     * This is needed for the cpufreq cpu driver in Dom0
+     */
+    DPRINT("Create pcpus node\n");
+
+    res = fdt_begin_node(kinfo->fdt, "pcpus");
+    if ( res )
+        return res;
+
+    dt_for_each_child_node( cpus, npcpu )
+    {
+        if ( dt_device_type_is_equal(npcpu, "cpu") )
+        {
+            node_name = strrchr(dt_node_full_name(npcpu), '/');
+            ASSERT(node_name);
+
+            node_name++;
+            ASSERT(*node_name);
+
+            DPRINT("Copy %s node to the pcpus\n", node_name);
+
+            res = fdt_begin_node(kinfo->fdt, node_name);
+            if ( res )
+                return res;
+
+            res = write_properties(d, kinfo, npcpu);
+            if ( res )
+                return res;
+
+            res = fdt_end_node(kinfo->fdt);
+            if ( res )
+                return res;
+        }
+    }
+
+    res = fdt_end_node(kinfo->fdt);
+    return res;
+}
+#endif /* HAS_HWDOM_CPUFREQ */
+
+static int make_hypervisor_node(struct domain *d, struct kernel_info *kinfo,
+                                const struct dt_device_node *parent)
 {
     const char compat[] =
         "xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
@@ -351,12 +407,12 @@ static int make_hypervisor_node(struct domain *d,
         panic("Cannot cope with this size");
 
     /* See linux Documentation/devicetree/bindings/arm/xen.txt */
-    res = fdt_begin_node(fdt, "hypervisor");
+    res = fdt_begin_node(kinfo->fdt, "hypervisor");
     if ( res )
         return res;
 
     /* Cannot use fdt_property_string due to embedded nulls */
-    res = fdt_property(fdt, "compatible", compat, sizeof(compat));
+    res = fdt_property(kinfo->fdt, "compatible", compat, sizeof(compat));
     if ( res )
         return res;
 
@@ -366,7 +422,7 @@ static int make_hypervisor_node(struct domain *d,
     /* reg 0 is grant table space */
     cells = &reg[0];
     dt_set_range(&cells, parent, gnttab_start, gnttab_size);
-    res = fdt_property(fdt, "reg", reg,
+    res = fdt_property(kinfo->fdt, "reg", reg,
                        dt_cells_to_size(addrcells + sizecells));
     if ( res )
         return res;
@@ -382,11 +438,17 @@ static int make_hypervisor_node(struct domain *d,
     set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf,
                    DT_IRQ_TYPE_LEVEL_LOW);
 
-    res = fdt_property_interrupts(fdt, &intr, 1);
+    res = fdt_property_interrupts(kinfo->fdt, &intr, 1);
     if ( res )
         return res;
 
-    res = fdt_end_node(fdt);
+    #ifdef HAS_HWDOM_CPUFREQ
+    res = fdt_copy_phys_cpus_nodes(d, kinfo);
+    if ( res )
+        return res;
+    #endif
+
+    res = fdt_end_node(kinfo->fdt);
 
     return res;
 }
@@ -863,7 +925,7 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo,
 
     if ( node == dt_host )
     {
-        res = make_hypervisor_node(d, kinfo->fdt, node);
+        res = make_hypervisor_node(d, kinfo, node);
         if ( res )
             return res;
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKG-0006At-Tx; Tue, 11 Nov 2014 13:17:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKF-0006A3-RS
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:40 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	72/5A-25727-37C02645; Tue, 11 Nov 2014 13:17:39 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415711855!11763558!1
X-Originating-IP: [64.18.0.188]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11468 invoked from network); 11 Nov 2014 13:17:37 -0000
Received: from exprod5og109.obsmtp.com (HELO exprod5og109.obsmtp.com)
	(64.18.0.188)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:37 -0000
Received: from mail-lb0-f170.google.com ([209.85.217.170]) (using TLSv1) by
	exprod5ob109.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMb9twkL/yGGdZA0MBN9LP/H7JlJmS@postini.com;
	Tue, 11 Nov 2014 05:17:37 PST
Received: by mail-lb0-f170.google.com with SMTP id p9so4397649lbv.29
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=TEp0XXM33rjuFXHRkECxmQNY/0lo/sUJ1ABQu6H7wAI=;
	b=PJTNGrqANwEK/cszSWGsCZN4g3CGQdTaJ65HLkIuyqR2oPeeqKnd4nEpVCWND+GR/z
	mezDjOVqj6ScNC2rCHfaZ1KC/7Dk0i7QbdHO8ohbzuyNvjOaLcua9HvWrp21P742+CON
	iqypXLa58jR6Sz2y/Vq1+aC/x4aeGUCQEqA1Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=TEp0XXM33rjuFXHRkECxmQNY/0lo/sUJ1ABQu6H7wAI=;
	b=mea6IXV/I++7hZZ17bviVclvUdo1vFSZJUY+Wc1/0TFmd7yuTpiIMVk5ad+bZURATN
	z5ij60xCEk9IbYEYED1aPHP4d/GLL0xhxLR29grjyMs0zrjEtCRWCQ78gJAJkiDV3E+s
	2lhqoFDJdN5JOGynC+mPVxTziDveZylsuE2+BT+0SR6Nz5LLikFkSUafDaJyBCPU6CGz
	vvBf9gU14Fj+DVY6rXKsiuHqyMPHkeXpiXXcn7kM0Hl7FxAywwMX+BdKTZ5bGY5uIfrY
	EVNmWO8RT1hCraXJLqxc5E8n6/+sbyVjoDV6fVwc5cm69haxYL977ys5d1wrxc0DXTmn
	ixmQ==
X-Gm-Message-State: ALoCoQmTmMmOrPTH89DTkd9F7fjDyPDt5MsFtNutDN+uQv8udr5c7inl4hSxfGii4DJxZjVh2Wmpcso2WtDK4kEhkqQrjP2kMlbQ4Vb76743ROxbgefbwjbEGgn0JGuFi/tJ6Ai2dO1y+7TCvXdeBmsFmFCY4SYJJw==
X-Received: by 10.152.29.8 with SMTP id f8mr36199479lah.56.1415711853856;
	Tue, 11 Nov 2014 05:17:33 -0800 (PST)
X-Received: by 10.152.29.8 with SMTP id f8mr36199468lah.56.1415711853769;
	Tue, 11 Nov 2014 05:17:33 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id kl4sm1022963lbc.22.2014.11.11.05.17.32
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:32 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:08 +0200
Message-Id: <1415711834-1740-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 06/12] cpufreq: make cpufreq driver more
	generalizable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

First implementation of the cpufreq driver has been
written with x86 in mind. This patch makes possible
the cpufreq driver be working on both x86 and arm
architectures.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                     |  1 +
 xen/drivers/cpufreq/cpufreq.c    | 80 +++++++++++++++++++++++++++++++++++++---
 xen/include/public/platform.h    |  1 +
 xen/include/xen/processor_perf.h |  7 ++++
 4 files changed, 83 insertions(+), 6 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 5953152..3b0b89b 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -55,6 +55,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
 CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index f5f4d75..1644096 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -43,7 +43,6 @@
 #include <asm/io.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
-#include <acpi/acpi.h>
 #include <xen/cpufreq.h>
 
 static unsigned int __read_mostly usr_min_freq;
@@ -192,6 +191,7 @@ int cpufreq_add_cpu(unsigned int cpu)
     } else {
         /* domain sanity check under whatever coordination type */
         firstcpu = cpumask_first(cpufreq_dom->map);
+#ifdef CONFIG_ACPI
         if ((perf->domain_info.coord_type !=
             processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
             (perf->domain_info.num_processors !=
@@ -207,6 +207,18 @@ int cpufreq_add_cpu(unsigned int cpu)
                 );
             return -EINVAL;
         }
+#else /* CONFIG_ACPI */
+        if ((perf->domain_info.num_processors !=
+            processor_pminfo[firstcpu]->perf.domain_info.num_processors)) {
+
+            printk(KERN_WARNING "cpufreq fail to add CPU%d:"
+                   "incorrect num processors (%"PRIu64"), expect(%"PRIu64")\n",
+                   cpu, perf->domain_info.num_processors,
+                   processor_pminfo[firstcpu]->perf.domain_info.num_processors
+                );
+            return -EINVAL;
+        }
+#endif /* CONFIG_ACPI */
     }
 
     if (!domexist || hw_all) {
@@ -363,6 +375,7 @@ int cpufreq_del_cpu(unsigned int cpu)
     return 0;
 }
 
+#ifdef CONFIG_ACPI
 static void print_PCT(struct xen_pct_register *ptr)
 {
     printk("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
@@ -370,12 +383,14 @@ static void print_PCT(struct xen_pct_register *ptr)
            ptr->descriptor, ptr->length, ptr->space_id, ptr->bit_width,
            ptr->bit_offset, ptr->reserved, ptr->address);
 }
+#endif
 
 static void print_PSS(struct xen_processor_px *ptr, int count)
 {
     int i;
     printk("\t_PSS: state_count=%d\n", count);
     for (i=0; i<count; i++){
+#ifdef CONFIG_ACPI
         printk("\tState%d: %"PRId64"MHz %"PRId64"mW %"PRId64"us "
                "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",
                i,
@@ -385,15 +400,26 @@ static void print_PSS(struct xen_processor_px *ptr, int count)
                ptr[i].bus_master_latency,
                ptr[i].control,
                ptr[i].status);
+#else /* CONFIG_ACPI */
+        printk("\tState%d: %"PRId64"MHz %"PRId64"us\n",
+               i,
+               ptr[i].core_frequency,
+               ptr[i].transition_latency);
+#endif /* CONFIG_ACPI */
     }
 }
 
 static void print_PSD( struct xen_psd_package *ptr)
 {
+#ifdef CONFIG_ACPI
     printk("\t_PSD: num_entries=%"PRId64" rev=%"PRId64
            " domain=%"PRId64" coord_type=%"PRId64" num_processors=%"PRId64"\n",
            ptr->num_entries, ptr->revision, ptr->domain, ptr->coord_type,
            ptr->num_processors);
+#else /* CONFIG_ACPI */
+    printk("\t_PSD:  domain=%"PRId64" num_processors=%"PRId64"\n",
+           ptr->domain, ptr->num_processors);
+#endif /* CONFIG_ACPI */
 }
 
 static void print_PPC(unsigned int platform_limit)
@@ -401,13 +427,53 @@ static void print_PPC(unsigned int platform_limit)
     printk("\t_PPC: %d\n", platform_limit);
 }
 
+static inline uint32_t is_pss_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PSS;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_psd_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PSD;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_ppc_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags & XEN_PX_PPC;
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline uint32_t is_all_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+    return px->flags == ( XEN_PX_PCT | XEN_PX_PSS | XEN_PX_PSD | XEN_PX_PPC );
+#else
+    return px->flags == XEN_PX_DATA;
+#endif
+}
+
 int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_info)
 {
     int ret=0, cpuid;
     struct processor_pminfo *pmpt;
     struct processor_performance *pxpt;
 
+#ifdef CONFIG_ACPI
     cpuid = get_cpu_id(acpi_id);
+#else
+    cpuid = acpi_id;
+#endif
     if ( cpuid < 0 || !dom0_px_info)
     {
         ret = -EINVAL;
@@ -429,6 +495,8 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
         processor_pminfo[cpuid] = pmpt;
     }
     pxpt = &pmpt->perf;
+
+#ifdef CONFIG_ACPI
     pmpt->acpi_id = acpi_id;
     pmpt->id = cpuid;
 
@@ -455,8 +523,9 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PCT(&pxpt->status_register);
         }
     }
+#endif /* CONFIG_ACPI */
 
-    if ( dom0_px_info->flags & XEN_PX_PSS ) 
+    if ( is_pss_data(dom0_px_info) )
     {
         /* capability check */
         if (dom0_px_info->state_count <= 1)
@@ -483,7 +552,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PSS(pxpt->states,pxpt->state_count);
     }
 
-    if ( dom0_px_info->flags & XEN_PX_PSD )
+    if ( is_psd_data(dom0_px_info) )
     {
         /* check domain coordination */
         if (dom0_px_info->shared_type != CPUFREQ_SHARED_TYPE_ALL &&
@@ -503,7 +572,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
             print_PSD(&pxpt->domain_info);
     }
 
-    if ( dom0_px_info->flags & XEN_PX_PPC )
+    if ( is_ppc_data(dom0_px_info) )
     {
         pxpt->platform_limit = dom0_px_info->platform_limit;
 
@@ -517,8 +586,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *dom0_px_in
         }
     }
 
-    if ( dom0_px_info->flags == ( XEN_PX_PCT | XEN_PX_PSS |
-                XEN_PX_PSD | XEN_PX_PPC ) )
+    if ( is_all_data(dom0_px_info) )
     {
         pxpt->init = XEN_PX_INIT;
 
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 4341f54..ccb7969 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -358,6 +358,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t);
 #define XEN_PX_PSS   2
 #define XEN_PX_PPC   4
 #define XEN_PX_PSD   8
+#define XEN_PX_DATA  16
 
 struct xen_power_register {
     uint32_t     space_id;
diff --git a/xen/include/xen/processor_perf.h b/xen/include/xen/processor_perf.h
index d8a1ba6..6c1279d 100644
--- a/xen/include/xen/processor_perf.h
+++ b/xen/include/xen/processor_perf.h
@@ -3,7 +3,10 @@
 
 #include <public/platform.h>
 #include <public/sysctl.h>
+
+#ifdef CONFIG_ACPI
 #include <xen/acpi.h>
+#endif
 
 #define XEN_PX_INIT 0x80000000
 
@@ -24,8 +27,10 @@ int  cpufreq_del_cpu(unsigned int);
 struct processor_performance {
     uint32_t state;
     uint32_t platform_limit;
+#ifdef CONFIG_ACPI
     struct xen_pct_register control_register;
     struct xen_pct_register status_register;
+#endif
     uint32_t state_count;
     struct xen_processor_px *states;
     struct xen_psd_package domain_info;
@@ -35,8 +40,10 @@ struct processor_performance {
 };
 
 struct processor_pminfo {
+#ifdef CONFIG_ACPI
     uint32_t acpi_id;
     uint32_t id;
+#endif
     struct processor_performance    perf;
 };
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBK8-00067g-H9; Tue, 11 Nov 2014 13:17:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBK7-000679-0x
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:31 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	E5/7B-14214-A6C02645; Tue, 11 Nov 2014 13:17:30 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415711847!11777470!1
X-Originating-IP: [64.18.0.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24524 invoked from network); 11 Nov 2014 13:17:29 -0000
Received: from exprod5og117.obsmtp.com (HELO exprod5og117.obsmtp.com)
	(64.18.0.149)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 13:17:29 -0000
Received: from mail-la0-f42.google.com ([209.85.215.42]) (using TLSv1) by
	exprod5ob117.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMZip/5KRBakthBhgBJ8N0+W0ZD9iK@postini.com;
	Tue, 11 Nov 2014 05:17:29 PST
Received: by mail-la0-f42.google.com with SMTP id gq15so9660151lab.1
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=mDypeJq6Xfd/WvShiqJmfitzjHxkYyoecdy+64EqB4U=;
	b=WHoU6U7LnwTFQdXjxCh2Egx9w9QLqXhx1q8uJmnKuQgP2msjGwatZvOeY5J/Rdrbju
	0rEsTxXFdUpxmTRygq27DkST/FqNHyslgYbDwOTdwpiBUx1+d6juUrHmT7/jPDeUkqOk
	2Y61Qpaa8WmlBath/PtVZdOMfwIvJMmH1g67E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=mDypeJq6Xfd/WvShiqJmfitzjHxkYyoecdy+64EqB4U=;
	b=C45CfOxaJjL0iN8zP0FnU7hc5w040vanTCoezqmMXjJfwPbAkIh4PlTEiG60pXhXz/
	TPtlcqHov/pUVF0q/jpQi4Sb7H/finCkBUxrI68G20oiBnoheii6NRPhZu4t63v2+GbG
	KC2q5zkwI1UAfAimouX5VPRVLht3kHt3VHfSGVk75+Ke5HrWrMq0ZriDq2yweRcQoUgm
	nb/IWImFMNaYtN90INWUzUezsHLfEwC/AW614CL8BpPkCKGov/IoUUK6ivZszYL1XeeY
	wcKLoXrJ2W2TdJa5GTv2/FfnUUUZjXB/tbcGOBHcos834GCqRFVPgygVdi6QaT1A/lE6
	0HVg==
X-Gm-Message-State: ALoCoQm3+lPfafpWZZ0PfCuoJ5e2cHPUg3a3ZzD1T26a6wqt2ABfm0jYMuRcDCb1CVo+7tuW/e3evR7UFTEuaAN+CTZk4Sm0Cwkg/yPUZ2PQMIZK+iViT8nq6wZSjTyDVnx34wTN57ZSGPixz2bdU3gzO1OH2nYI3g==
X-Received: by 10.112.168.97 with SMTP id zv1mr36690031lbb.6.1415711845584;
	Tue, 11 Nov 2014 05:17:25 -0800 (PST)
X-Received: by 10.112.168.97 with SMTP id zv1mr36690022lbb.6.1415711845522;
	Tue, 11 Nov 2014 05:17:25 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id dq5sm5981579lbc.11.2014.11.11.05.17.24
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:24 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:05 +0200
Message-Id: <1415711834-1740-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 03/12] pmstat: move pmstat.c file to the
	xen/drivers/pm/stat.c location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                             | 1 +
 xen/arch/x86/Rules.mk                    | 1 +
 xen/common/sysctl.c                      | 2 +-
 xen/drivers/Makefile                     | 1 +
 xen/drivers/acpi/Makefile                | 1 -
 xen/drivers/pm/Makefile                  | 1 +
 xen/drivers/{acpi/pmstat.c => pm/stat.c} | 0
 7 files changed, 5 insertions(+), 2 deletions(-)
 create mode 100644 xen/drivers/pm/Makefile
 rename xen/drivers/{acpi/pmstat.c => pm/stat.c} (100%)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3a6cec5..b7caab6 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -55,6 +55,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 576985e..9e9fbf1 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,7 @@
 
 HAS_IOPORTS := y
 HAS_ACPI := y
+HAS_PM := y
 HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0cb6ee1..0dcf06a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -170,7 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         op->u.availheap.avail_bytes <<= PAGE_SHIFT;
         break;
 
-#ifdef HAS_ACPI
+#ifdef HAS_PM
     case XEN_SYSCTL_get_pmstat:
         ret = do_get_pm_info(&op->u.get_pmstat);
         break;
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 9c70f20..ee4fd4d 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -4,3 +4,4 @@ subdir-$(HAS_PCI) += pci
 subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VIDEO) += video
+subdir-$(HAS_PM) += pm
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index bbb06a7..0505742 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -5,7 +5,6 @@ subdir-$(x86) += apei
 obj-bin-y += tables.init.o
 obj-y += numa.o
 obj-y += osl.o
-obj-y += pmstat.o
 
 obj-$(x86) += hwregs.o
 obj-$(x86) += reboot.o
diff --git a/xen/drivers/pm/Makefile b/xen/drivers/pm/Makefile
new file mode 100644
index 0000000..2073683
--- /dev/null
+++ b/xen/drivers/pm/Makefile
@@ -0,0 +1 @@
+obj-y += stat.o
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/pm/stat.c
similarity index 100%
rename from xen/drivers/acpi/pmstat.c
rename to xen/drivers/pm/stat.c
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKN-0006Eb-17; Tue, 11 Nov 2014 13:17:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKK-0006DK-SI
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:45 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	70/2E-09284-87C02645; Tue, 11 Nov 2014 13:17:44 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415711860!11822811!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21356 invoked from network); 11 Nov 2014 13:17:43 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:43 -0000
Received: from mail-lb0-f177.google.com ([209.85.217.177]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMdO/HoIbSybosfWVNWpyFkafUfEW9@postini.com;
	Tue, 11 Nov 2014 05:17:42 PST
Received: by mail-lb0-f177.google.com with SMTP id z12so823573lbi.22
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=EFIS12KyxsCwv9kQH84nHK59oU6tRkfcIXPnJNzPRhA=;
	b=BU+XhZVaSZa2UH3YPZgILZUGGMOzeVRBBcwNACiHOuY/qiVrnuW+H6lnVN8hl49Pe/
	nCwbSo/ht5wztu3vBG6GoANf7sZVQEgJmj6u4ZI/rU9IgO8iczzY2+XElzeOekhGb1fh
	rdmVgpDuSnIMefc2Avw7//OiaE5hAQWmoRNZw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=EFIS12KyxsCwv9kQH84nHK59oU6tRkfcIXPnJNzPRhA=;
	b=NbBRDvL8Yx/JB/LPLTfiTxfbZ6UL40TlhuuChn40AxMtaQKTFqidqBi08uSpfuCbYM
	R6o5TT9waTsIg6ER/kQ5krXVKHJlZWvFEoOWu+Fou3cJx6dWeVSuyjWLLkRQZVuGl6/L
	u9Jar1mfUdzgM3oZo6vKo6GbdfS7PKw9TKG/0s5Ivdc0QWDGFRfnoh1mbHQ2HEp23DVN
	PFtLqYv2f0Grf77orQY88OujiEuoIrL+X5HD+Z7XykZwcUNxxXzpcaWpDE0LB1VbGwd0
	1XG3i8ZrllrsTds570RyTuTK52Bm/CLkbmnm5FBPOrSBAkM0TLUL6wWugI8tnXHT3nar
	kBYw==
X-Gm-Message-State: ALoCoQkhO/MdoNKJV/EMvBW3covCGq5zBYfXQ/Yzsx2XfjfJPkvXgsAf3N4FchorqPEKd849O6FOn8dOTvjN1uv5I/wRgM7oASmZcKgRrN1CLjRKHIszTE5IFMr6jf4G64PdgFOtVTj8q82tWqsTMX/J0XNcUgchvA==
X-Received: by 10.112.189.10 with SMTP id ge10mr35778269lbc.23.1415711858835; 
	Tue, 11 Nov 2014 05:17:38 -0800 (PST)
X-Received: by 10.112.189.10 with SMTP id ge10mr35778257lbc.23.1415711858772; 
	Tue, 11 Nov 2014 05:17:38 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id l7sm5966470lah.27.2014.11.11.05.17.37
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:37 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:10 +0200
Message-Id: <1415711834-1740-9-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 08/12] xen: arm: implement platform
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch enables xsm_platform_op hook for all architectures
and implements platform hypercall for ARM.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/Makefile             |  1 +
 xen/arch/arm/platform_hypercall.c | 84 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c              |  1 +
 xen/include/xsm/dummy.h           | 12 +++---
 xen/include/xsm/xsm.h             | 10 ++---
 xen/xsm/flask/hooks.c             |  3 +-
 6 files changed, 99 insertions(+), 12 deletions(-)
 create mode 100644 xen/arch/arm/platform_hypercall.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index d70f6d5..54d8258 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -32,6 +32,7 @@ obj-y += vuart.o
 obj-y += hvm.o
 obj-y += device.o
 obj-y += decode.o
+obj-y += platform_hypercall.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/platform_hypercall.c b/xen/arch/arm/platform_hypercall.c
new file mode 100644
index 0000000..f14641b
--- /dev/null
+++ b/xen/arch/arm/platform_hypercall.c
@@ -0,0 +1,84 @@
+/******************************************************************************
+ * platform_hypercall.c
+ *
+ * Hardware platform operations. Intended for use by domain-0 kernel.
+ *
+ * Copyright (c) 2014 GlobalLogic Inc.
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/sched.h>
+#include <xen/event.h>
+#include <xen/guest_access.h>
+#include <xen/pmstat.h>
+#include <xen/irq.h>
+#include <public/platform.h>
+#include <xsm/xsm.h>
+
+static DEFINE_SPINLOCK(xenpf_lock);
+
+long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
+{
+    long ret = 0;
+    struct xen_platform_op curop, *op = &curop;
+
+    if ( copy_from_guest(op, u_xenpf_op, 1) )
+        return -EFAULT;
+
+    if ( op->interface_version != XENPF_INTERFACE_VERSION )
+        return -EACCES;
+
+    ret = xsm_platform_op(XSM_PRIV, op->cmd);
+    if ( ret )
+        return ret;
+
+    /*
+     * Trylock here avoids deadlock with an existing platform critical section
+     * which might (for some current or future reason) want to synchronise
+     * with this vcpu.
+     */
+    while ( !spin_trylock(&xenpf_lock) )
+        if ( hypercall_preempt_check() )
+            return hypercall_create_continuation(
+                __HYPERVISOR_platform_op, "h", u_xenpf_op);
+
+    switch ( op->cmd )
+    {
+    case XENPF_set_processor_pminfo:
+        switch ( op->u.set_pminfo.type )
+        {
+        case XEN_PM_PX:
+            if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
+            {
+                ret = -ENOSYS;
+                break;
+           }
+#ifdef HAS_CPUFREQ
+            ret = set_px_pminfo(op->u.set_pminfo.id, &op->u.set_pminfo.u.perf);
+#else
+            ret = -EINVAL;
+#endif
+            break;
+
+        default:
+            ret = -EINVAL;
+            break;
+        }
+        break;
+    }
+
+    spin_unlock(&xenpf_lock);
+
+    return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 21c7b26..d1b0014 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1012,6 +1012,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
     HYPERCALL(hvm_op, 2),
     HYPERCALL(grant_table_op, 3),
     HYPERCALL_ARM(vcpu_op, 3),
+    HYPERCALL(platform_op, 1),
 };
 
 typedef int (*arm_psci_fn_t)(uint32_t, register_t);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index eb9e1a1..911fb5d 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -491,6 +491,12 @@ static XSM_INLINE int xsm_hvm_param_nested(XSM_DEFAULT_ARG struct domain *d)
     return xsm_default_action(action, current->domain, d);
 }
 
+static XSM_INLINE int xsm_platform_op(XSM_DEFAULT_ARG uint32_t op)
+{
+    XSM_ASSERT_ACTION(XSM_PRIV);
+    return xsm_default_action(action, current->domain, NULL);
+}
+
 #ifdef CONFIG_X86
 static XSM_INLINE int xsm_shadow_control(XSM_DEFAULT_ARG struct domain *d, uint32_t op)
 {
@@ -546,12 +552,6 @@ static XSM_INLINE int xsm_apic(XSM_DEFAULT_ARG struct domain *d, int cmd)
     return xsm_default_action(action, d, NULL);
 }
 
-static XSM_INLINE int xsm_platform_op(XSM_DEFAULT_ARG uint32_t op)
-{
-    XSM_ASSERT_ACTION(XSM_PRIV);
-    return xsm_default_action(action, current->domain, NULL);
-}
-
 static XSM_INLINE int xsm_machine_memory_map(XSM_DEFAULT_VOID)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 1939453..5cb1e0d 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -509,6 +509,11 @@ static inline int xsm_hvm_param_nested (xsm_default_t def, struct domain *d)
     return xsm_ops->hvm_param_nested(d);
 }
 
+static inline int xsm_platform_op (xsm_default_t def, uint32_t op)
+{
+    return xsm_ops->platform_op(op);
+}
+
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (xsm_default_t def, struct domain *d, uint32_t op)
 {
@@ -560,11 +565,6 @@ static inline int xsm_memtype (xsm_default_t def, uint32_t access)
     return xsm_ops->memtype(access);
 }
 
-static inline int xsm_platform_op (xsm_default_t def, uint32_t op)
-{
-    return xsm_ops->platform_op(op);
-}
-
 static inline int xsm_machine_memory_map(xsm_default_t def)
 {
     return xsm_ops->machine_memory_map();
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d94ab77..29126ec 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1542,6 +1542,8 @@ static struct xsm_operations flask_ops = {
     .add_to_physmap = flask_add_to_physmap,
     .remove_from_physmap = flask_remove_from_physmap,
 
+    .platform_op = flask_platform_op,
+
 #ifdef CONFIG_X86
     .shadow_control = flask_shadow_control,
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
@@ -1552,7 +1554,6 @@ static struct xsm_operations flask_ops = {
     .mem_event_op = flask_mem_event_op,
     .mem_sharing_op = flask_mem_sharing_op,
     .apic = flask_apic,
-    .platform_op = flask_platform_op,
     .machine_memory_map = flask_machine_memory_map,
     .domain_memory_map = flask_domain_memory_map,
     .mmu_update = flask_mmu_update,
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKO-0006GF-9k; Tue, 11 Nov 2014 13:17:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKN-0006Ea-3D
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:47 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	50/A6-17735-A7C02645; Tue, 11 Nov 2014 13:17:46 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415711863!8091002!1
X-Originating-IP: [64.18.0.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30402 invoked from network); 11 Nov 2014 13:17:45 -0000
Received: from exprod5og109.obsmtp.com (HELO exprod5og109.obsmtp.com)
	(64.18.0.188)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:45 -0000
Received: from mail-lb0-f179.google.com ([209.85.217.179]) (using TLSv1) by
	exprod5ob109.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMd4eLqkQzp/GkUt9qzWl+C2cw1Dqf@postini.com;
	Tue, 11 Nov 2014 05:17:45 PST
Received: by mail-lb0-f179.google.com with SMTP id l4so7538326lbv.24
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=1iCFdRRi7ziCcSGlVnf/IGNJN2aXeU0zyXK2eCZt3hg=;
	b=f95UNAnPjPrvirjbid5c1JY0PBoppRHRQI2dawsyRuO3m/fHDMYIrSlHqgzfCa02Uk
	SKKbLNcyZ+Z2B6KKaXxfefU+AHoRjmsSWFWmaCqjio63IWPGGBX3VuvkOIF4j2O+UW8z
	dT+3P6Go/SfK6YTXzQr8phjIGfkeKUpd4Zrp8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=1iCFdRRi7ziCcSGlVnf/IGNJN2aXeU0zyXK2eCZt3hg=;
	b=CEx11Hy9Bhkj/UXk6jyrTp/uod2WExNhMml7WxG2snlLCfH7Gp8+A2x2gqObAqrrme
	kWYE9vAJdZyQF+BTR0bbZllC6sMJBcprusd1Ej5JtK7ZtGs4ouE6cim76jjbFDat3gcr
	4rGnA5FP3Ji6YXsYYqqz4hMvYvm+v0u5hC6VYi8ZgUhHRJ68Sx0qV5KRExcTvt5V7uZI
	oOD4fV1XoK+vaqcCZ6CB5zq75kT6FUMgnwJUWXDUyYy0Hq0jGyBZoXdVYOh8EJmcWILR
	ir5lW1BZAbmPTuEXqW1g36m0WnRpB/nKQUr85PQP9m4JncQ+XJbfnBwHqQU9pVbbd+qr
	ypyQ==
X-Gm-Message-State: ALoCoQnIMo0UL8oRKFQa0ia7+daA3yZnUck4jeW/1jC1X+FgBSpwM/1mv328SgPph2GYHYY1zPXA6q19Rxo461pnVO8GXy8c5vBOTe/MdmPBhRjTdcy5OdBgGvNMjcvvlCvAHqC7YhAreWYO/35Hye2DE139Rkqugw==
X-Received: by 10.112.148.199 with SMTP id tu7mr36583100lbb.7.1415711861719;
	Tue, 11 Nov 2014 05:17:41 -0800 (PST)
X-Received: by 10.112.148.199 with SMTP id tu7mr36583095lbb.7.1415711861674;
	Tue, 11 Nov 2014 05:17:41 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id qk3sm5979954lbb.19.2014.11.11.05.17.40
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:40 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:11 +0200
Message-Id: <1415711834-1740-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 09/12] xen: arm: add cpufreq shared info
	definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This shared info will be used by hwdom-cpufreq driver
to send commands to the cpufreq driver in the hwdom.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/include/asm-arm/shared.h  | 14 ++++++++++++++
 xen/include/public/arch-arm.h | 12 ++++++++++++
 2 files changed, 26 insertions(+)
 create mode 100644 xen/include/asm-arm/shared.h

diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
new file mode 100644
index 0000000..4906f38
--- /dev/null
+++ b/xen/include/asm-arm/shared.h
@@ -0,0 +1,14 @@
+#ifndef __XEN_ARM_SHARED_H__
+#define __XEN_ARM_SHARED_H__
+
+#define GET_SET_SHARED(type, field)                                 \
+static inline type *arch_get_##field##_addr(const struct domain *d) \
+{                                                                   \
+   return &d->shared_info->arch.field;                              \
+}
+
+GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
+
+#undef GET_SET_SHARED
+
+#endif /* __XEN_ARM_SHARED_H__ */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 7496556..2f6ea66 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -309,7 +309,19 @@ struct arch_vcpu_info {
 };
 typedef struct arch_vcpu_info arch_vcpu_info_t;
 
+#define CPUFREQ_CMD_idle            0
+#define CPUFREQ_CMD_change_freq     1
+
+struct cpufreq_sh_info {
+    uint32_t cmd;       /* CPUFREQ_CMD_* */
+    uint32_t cpu;       /* Physical CPU number */
+    uint32_t freq;      /* Frequency in KHz */
+    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
+    int32_t result;     /* Returned result of the operation */
+};
+
 struct arch_shared_info {
+    struct cpufreq_sh_info cpufreq;
 };
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKJ-0006CZ-B8; Tue, 11 Nov 2014 13:17:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKI-0006Bf-CL
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:42 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	9D/C1-17694-57C02645; Tue, 11 Nov 2014 13:17:41 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415711858!11833149!1
X-Originating-IP: [64.18.0.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18466 invoked from network); 11 Nov 2014 13:17:40 -0000
Received: from exprod5og118.obsmtp.com (HELO exprod5og118.obsmtp.com)
	(64.18.0.160)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:40 -0000
Received: from mail-lb0-f173.google.com ([209.85.217.173]) (using TLSv1) by
	exprod5ob118.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMccAVFPp2J/MjPWkQoubGFE95RfL3@postini.com;
	Tue, 11 Nov 2014 05:17:40 PST
Received: by mail-lb0-f173.google.com with SMTP id n15so7691056lbi.18
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=+oiOKckGVDosptw1S7D6HF8HmwOpIZSsoFCNbEeDF1Y=;
	b=iWCRI/Y0nkdoVDuDuFbcUNpKg8RzRc90RQ4G0JESFk+C9JHNoI0cxR4y0d3cZBsnbe
	GNfyrCe3CqkY58bsqQkEb++7+O7TT3WQHcF/G5Ws6Pdj+0YgqMHBfkCOtGxAlKHMshIJ
	0vlCaSWCsKlUcxP4U9O5ZfeNK+g4ilK6SzCq0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=+oiOKckGVDosptw1S7D6HF8HmwOpIZSsoFCNbEeDF1Y=;
	b=Ris5AZucqYBla8SrRIVPxmOPdl469Tny7JwxqKvLMTrSrx09fRMoniiBSfuwsCzQTN
	Uz9/XPBpdFuLUDrYItwyjAPkZyMumv6Spi9hcOJgXRFKlDgCZVFFC23BAG9gWaGdjYKw
	QVVzEHd8o7InHqtLu9mqHXWOizPhZTBPYC1cdCRaWtLqiw8YGYpHdO5AYes6XkHxjJQ/
	9+NzJyuQA9JY5Mu2nm4Kt2L4LW78xuOD2Q4IIw0dWiUkZ4gOVn92ghQyDtI9SdfQP4QX
	6rg2X/e/+HBrwHwuu/EUpCkuTdk4BDAfIqGpuDIhEb6R1gEZq/G0MKVUcl7Z1mf88dSx
	Ua+Q==
X-Gm-Message-State: ALoCoQkuKDnCWbi2pna8UISHhrsijqdIQ+WHwei+DXSR4lksfcjQzMWAoycKl4h0sFYnpjdZmvbijdkspHHjt8xTuOSPygfOSc0k3xbstqkA5o7LpDXLDUw0Rl34lKMAwh6dsJCt85qbZ2+ABq918+1QPboiFu015Q==
X-Received: by 10.152.88.69 with SMTP id be5mr36404093lab.36.1415711856506;
	Tue, 11 Nov 2014 05:17:36 -0800 (PST)
X-Received: by 10.152.88.69 with SMTP id be5mr36404081lab.36.1415711856440;
	Tue, 11 Nov 2014 05:17:36 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id j2sm5980607lbp.16.2014.11.11.05.17.35
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:35 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:09 +0200
Message-Id: <1415711834-1740-8-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 07/12] arch/arm: create device tree nodes
	for hwdom cpufreq cpu driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch copies all cpu@0..cpu@N nodes (from input
device tree) with properties to /hypervisor/pcpus
node (device tree for hwdom). Thus we can give all
information about all physical CPUs in the pcpus node.
Driver in hwdom should parse /hypervisor/pcpus path
instead of the /cpus path in the device tree.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/domain_build.c | 78 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 70 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2db0236..87e05c7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -326,8 +326,64 @@ static int make_memory_node(const struct domain *d,
     return res;
 }
 
-static int make_hypervisor_node(struct domain *d,
-                                void *fdt, const struct dt_device_node *parent)
+#ifdef HAS_HWDOM_CPUFREQ
+static int fdt_copy_phys_cpus_nodes(struct domain *d, struct kernel_info *kinfo)
+{
+    int res;
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *npcpu;
+    char *node_name;
+
+    if ( !cpus )
+    {
+        dprintk(XENLOG_ERR, "Missing /cpus node in the device tree?\n");
+        return -ENOENT;
+    }
+
+    /*
+     * create pcpus node and copy to it
+     * original cpu@0..cpu@N nodes with its properties.
+     * This is needed for the cpufreq cpu driver in Dom0
+     */
+    DPRINT("Create pcpus node\n");
+
+    res = fdt_begin_node(kinfo->fdt, "pcpus");
+    if ( res )
+        return res;
+
+    dt_for_each_child_node( cpus, npcpu )
+    {
+        if ( dt_device_type_is_equal(npcpu, "cpu") )
+        {
+            node_name = strrchr(dt_node_full_name(npcpu), '/');
+            ASSERT(node_name);
+
+            node_name++;
+            ASSERT(*node_name);
+
+            DPRINT("Copy %s node to the pcpus\n", node_name);
+
+            res = fdt_begin_node(kinfo->fdt, node_name);
+            if ( res )
+                return res;
+
+            res = write_properties(d, kinfo, npcpu);
+            if ( res )
+                return res;
+
+            res = fdt_end_node(kinfo->fdt);
+            if ( res )
+                return res;
+        }
+    }
+
+    res = fdt_end_node(kinfo->fdt);
+    return res;
+}
+#endif /* HAS_HWDOM_CPUFREQ */
+
+static int make_hypervisor_node(struct domain *d, struct kernel_info *kinfo,
+                                const struct dt_device_node *parent)
 {
     const char compat[] =
         "xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
@@ -351,12 +407,12 @@ static int make_hypervisor_node(struct domain *d,
         panic("Cannot cope with this size");
 
     /* See linux Documentation/devicetree/bindings/arm/xen.txt */
-    res = fdt_begin_node(fdt, "hypervisor");
+    res = fdt_begin_node(kinfo->fdt, "hypervisor");
     if ( res )
         return res;
 
     /* Cannot use fdt_property_string due to embedded nulls */
-    res = fdt_property(fdt, "compatible", compat, sizeof(compat));
+    res = fdt_property(kinfo->fdt, "compatible", compat, sizeof(compat));
     if ( res )
         return res;
 
@@ -366,7 +422,7 @@ static int make_hypervisor_node(struct domain *d,
     /* reg 0 is grant table space */
     cells = &reg[0];
     dt_set_range(&cells, parent, gnttab_start, gnttab_size);
-    res = fdt_property(fdt, "reg", reg,
+    res = fdt_property(kinfo->fdt, "reg", reg,
                        dt_cells_to_size(addrcells + sizecells));
     if ( res )
         return res;
@@ -382,11 +438,17 @@ static int make_hypervisor_node(struct domain *d,
     set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf,
                    DT_IRQ_TYPE_LEVEL_LOW);
 
-    res = fdt_property_interrupts(fdt, &intr, 1);
+    res = fdt_property_interrupts(kinfo->fdt, &intr, 1);
     if ( res )
         return res;
 
-    res = fdt_end_node(fdt);
+    #ifdef HAS_HWDOM_CPUFREQ
+    res = fdt_copy_phys_cpus_nodes(d, kinfo);
+    if ( res )
+        return res;
+    #endif
+
+    res = fdt_end_node(kinfo->fdt);
 
     return res;
 }
@@ -863,7 +925,7 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo,
 
     if ( node == dt_host )
     {
-        res = make_hypervisor_node(d, kinfo->fdt, node);
+        res = make_hypervisor_node(d, kinfo, node);
         if ( res )
             return res;
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBK6-000672-54; Tue, 11 Nov 2014 13:17:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBK4-00066p-D4
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:28 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	61/27-24124-76C02645; Tue, 11 Nov 2014 13:17:27 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415711844!6368681!1
X-Originating-IP: [64.18.0.189]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12008 invoked from network); 11 Nov 2014 13:17:26 -0000
Received: from exprod5og119.obsmtp.com (HELO exprod5og119.obsmtp.com)
	(64.18.0.189)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 13:17:26 -0000
Received: from mail-la0-f43.google.com ([209.85.215.43]) (using TLSv1) by
	exprod5ob119.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMZIV5bwv8La6XVuA71vpNR/ivALsX@postini.com;
	Tue, 11 Nov 2014 05:17:26 PST
Received: by mail-la0-f43.google.com with SMTP id ge10so9627793lab.16
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=D1leJIJzsTzTSyc0hUuYcZ38eLO7gkRqvj/NBqjScY8=;
	b=htNoTlcbbI8rUfou+PtbGZnZQhxuCE/7pCOdQ2joIjZALZXIMliLMgucqwB+asWdAJ
	zZ3GrhBNAg9Ms5lN2sSrUGYG5zku2+3tFs61souDnokeW7sz8I/CchLPYOMQ+iPLLdCk
	bXmVg4ti3oK1rE8e1OcU/S2lYcmPGHzVNUEdw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=D1leJIJzsTzTSyc0hUuYcZ38eLO7gkRqvj/NBqjScY8=;
	b=iaHgfxURhP1qeBlK5yrqp6YvJkVvvLhkYi1OAvqDD8kyTX0CsOG1iTvLEiOj6HMDVV
	x5wB5a1hpmhXzOT8pGbx9YntMEHywLKavEjxbUYTGqeIv+Js91yWx8e9AwQFJN22OO51
	QO5YXcHBXGHyRf2NzPoqigvAi6c183ItRh4rsF8MXhgjNZcP4Zqpqq9kn9Q31jb/l2NM
	4Bid1H42nZU4pV9n9WHMj6Tv718+H1+p7G6wE4XlE0PJIucF6WT1BuN6tgv/OwmrQso0
	aaSy2rIBE7sfX+KKRwHlWcLXxxt2t2CcyDVFVrejs+jTETzCd78VYKvOrA4+w1vuvpiX
	Y3MA==
X-Gm-Message-State: ALoCoQlFO4YHglD2vbq9SFZVg43mM8U7GBd3cTHkwIreD7gwfRIij+0me1CJuIhIvO4vAihhuSxqXDma6AE82OBpnvlrgSyGTovt8OR6VLVI41LVFUBh4pjNfSUTveyQlfO7H0JiqIT7KBtMyhqtruSAKvy2ay1S/w==
X-Received: by 10.152.21.9 with SMTP id r9mr10043505lae.76.1415711842967;
	Tue, 11 Nov 2014 05:17:22 -0800 (PST)
X-Received: by 10.152.21.9 with SMTP id r9mr10043495lae.76.1415711842887;
	Tue, 11 Nov 2014 05:17:22 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id lu5sm4829050lac.0.2014.11.11.05.17.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:22 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:04 +0200
Message-Id: <1415711834-1740-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 02/12] pm: move processor_perf.h file to
	the xen/include/xen location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 MAINTAINERS                                        | 2 +-
 xen/arch/x86/platform_hypercall.c                  | 2 +-
 xen/include/xen/cpufreq.h                          | 2 +-
 xen/include/{acpi/cpufreq => xen}/processor_perf.h | 0
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename xen/include/{acpi/cpufreq => xen}/processor_perf.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 49f56a1..f4d916e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -234,8 +234,8 @@ F:	xen/arch/x86/acpi/
 X:	xen/arch/x86/acpi/boot.c
 X:	xen/arch/x86/acpi/lib.c
 F:	xen/drivers/cpufreq/
-F:	xen/include/acpi/cpufreq/
 F:	xen/include/xen/cpufreq.h
+F:	xen/include/xen/processor_perf.h
 
 QEMU-DM
 M:	Ian Jackson <ian.jackson@eu.citrix.com>
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 2162811..7ce8592 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -25,7 +25,7 @@
 #include <xen/irq.h>
 #include <asm/current.h>
 #include <public/platform.h>
-#include <acpi/cpufreq/processor_perf.h>
+#include <xen/processor_perf.h>
 #include <asm/edd.h>
 #include <asm/mtrr.h>
 #include <asm/io_apic.h>
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index fa653ef..82dc4dc 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -21,7 +21,7 @@
 #include <xen/errno.h>
 #include <xen/cpumask.h>
 
-#include <acpi/cpufreq/processor_perf.h>
+#include <xen/processor_perf.h>
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
diff --git a/xen/include/acpi/cpufreq/processor_perf.h b/xen/include/xen/processor_perf.h
similarity index 100%
rename from xen/include/acpi/cpufreq/processor_perf.h
rename to xen/include/xen/processor_perf.h
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBK1-00066G-3c; Tue, 11 Nov 2014 13:17:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBJz-00066B-2I
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BC/12-09842-26C02645; Tue, 11 Nov 2014 13:17:22 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415711839!11886888!1
X-Originating-IP: [64.18.0.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10052 invoked from network); 11 Nov 2014 13:17:21 -0000
Received: from exprod5og101.obsmtp.com (HELO exprod5og101.obsmtp.com)
	(64.18.0.141)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:21 -0000
Received: from mail-la0-f48.google.com ([209.85.215.48]) (using TLSv1) by
	exprod5ob101.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMXm2YNU0kWo0/3y9gzg9FEvxaLycB@postini.com;
	Tue, 11 Nov 2014 05:17:20 PST
Received: by mail-la0-f48.google.com with SMTP id gq15so9398292lab.21
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id;
	bh=cioK/u/9Quu+QdGwX4P0Cg6IZ5xOM1EKcuzy8zBNUW8=;
	b=JOhwKWOHVOOlSiBES8T844ZBgVlN75icXS2VPrFHZhArISVHksq1kLbG6hOC9qlGqj
	03vNmzv800XwzFGo02csoXLpLJGwFAsFag8poo4F2npT2ScIa4gB5tUtXU8Bc4JpuYhu
	Apjc6PSkO8DvLOYNeH4R4vnCZSexxKVC2ckfE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=cioK/u/9Quu+QdGwX4P0Cg6IZ5xOM1EKcuzy8zBNUW8=;
	b=NqLiVoWI8U+w7oIMEfax1JyhAg/T8nZHPmKTGaeWMbpPJOjA6gHXzkAHYd2LcG5C1C
	pFPEg3Q5EvX45q5/HTUP8UI0HGpgXahnnOxGU/CYAuZWdlt3OXLJGQB6Ed36CJdMTaVx
	NHhjPPD9SZdbaDW+OcHdhN6ScpLlEmSJiqMnQnZiexks8KyjFaZ9hmiWnDHkIaN6LyuQ
	cCNXKd/TorinIjjhwp2K7rSo7r5gtOj8hIpd4GzWjy+7DR+5VP0Q5YJBjcuxf2heQoMb
	TUU1Bs0PM1NjzeL+5IHggl+cIFGGyyYIeG+8s6vczXwePOGOr8Hp1CagSzEQw5Q930op
	aSHw==
X-Gm-Message-State: ALoCoQkHbweOTomKHD6OA6kzb3LloqVAHUmjJZNnaA+PmzCxGu1eEAx71uzTnOYRa3Jtk4hDx6sRPdmKLjjlloAwJqD4rGYayPocsDg2pM4hCJqW3unWJzyF4CxpyUmi8TRPYpyyKwPIgBlfdqt5unYUY+iZAHyX5g==
X-Received: by 10.152.28.6 with SMTP id x6mr1309391lag.12.1415711837427;
	Tue, 11 Nov 2014 05:17:17 -0800 (PST)
X-Received: by 10.152.28.6 with SMTP id x6mr1309379lag.12.1415711837300;
	Tue, 11 Nov 2014 05:17:17 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id z5sm5968671lae.21.2014.11.11.05.17.15
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:16 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:02 +0200
Message-Id: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 00/12] xen_cpufreq implementation in Xen
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi to all.

Next series of patches implements xen-cpufreq driver in Xen hypervisor.

Cpufreq core and registered cpufreq governors are located in xen. Hwdom has CPU
driver which can only change frequency of the physical CPUs. In addition this
driver can change CPUs regulator voltage. At start time xen-cpufreq driver
in hwdom reads an information about physical CPUs number and uploads to Xen
information about those physical cpus. Then hwdon uses XEN_SYSCTL_cpufreq_op
operation to start events from hwdom-cpufreq ddriver in Xen.
Changing frequency workflow:
 * hwdom-cpufreq driver in Xen wants to change the
   frequency of the physical CPU
 * hwdom-cpufreq in Xen sets parameters in the shared
   memory
 * hwdom-cpufreq driver in Xen sends an event via event channel
   to notify the xen-cpufreq driver in hwdom
 * xen-cpufreq driver in hwdom reads parameters from the shared
   memory, changes frequency and copies the result of
   the operation to the shared memory
 * xen-cpufreq driver in hwdom sends an event via event channel
   to notify the cpufreq driver in Xen


Changed since v1:
 * use /xen/include/xen/ instead of the  /xen/include/cpufreq/
   for included files
 * move pmstat.c file to the xen/drivers/pm/stat.c instead of the
   xen/drivers/pm/pmstat.c
 * updated ./MAINTAINERS accordingly to new files location
 * introduce HAS_CPU_TURBO config and use it
 * move ACPI-specific pmstat functions under the CONFIG_ACPI config
   instead of the CONFIG_X86 config
 * correct info message in cpufreq_add_cpu() function (remove _PSD
   prefix for NON ACPI configuration)
 * dropped patch "[RFC PATCH 07/13] xen/arm: enable cpu hotplug"
 * dropped patch "[RFC PATCH 08/13] xen/dts: make the dt_find_property
   function to be global"
 * create PCPUs device tree node in /hypervisor/pcpus node instead
   of the /cpus/cpu@0/private_date/ node
 * reworked platform hypercall implementation (used XSM check
   for ARM architecture) and moved common code to the common
   place.
 * xen-cpufreq driver to the dom0-cpufreq

Changed since v2:
 * corrected comment in xen/drivers/pm/stat.c
 * restored blank line in xen/drivers/pm/stat.c
 * corrected #ifdef in xen/drivers/cpufreq/cpufreq.c
 * removed common file for platform_hypercall implementation
 * renamed dom0-cpufreq.c to hwdom-cpufreq.c
 * slightly reworked file hwdom-cpufreq.c
 * used VIRQ_CPUFREQ with number 14 instead of the 13
 
Changed since v3:
 * some fixes in creating device tree nodes for hwdom cpufreq cpu driver
 * some fixes in hwdom-cpufreq driver
 * removed XEN_SYSCTL_cpufreq_op implementation
 * added cpufreq shared info definition to send commands to the
   hwdom cpufreq driver

Changed since v4:
 * implemented an event channel between Xen and hwdom
 * restored XEN_SYSCTL_cpufreq_op definition (start/stop hwdom-cpufreq
   driver events)
 * added timer to the hwdom-cpufreq driver (sending command timeout)
 * slihgtly reworked hwdom-cpufreq driver
 * removed VIRQ_CPUFREQ

Oleksandr Dmytryshyn (12):
  cpufreq: move cpufreq.h file to the xen/include/xen location
  pm: move processor_perf.h file to the xen/include/xen location
  pmstat: move pmstat.c file to the xen/drivers/pm/stat.c location
  cpufreq: make turbo settings to be configurable
  pmstat: make pmstat functions more generalizable
  cpufreq: make cpufreq driver more generalizable
  arch/arm: create device tree nodes for hwdom cpufreq cpu driver
  xen: arm: implement platform hypercall
  xen: arm: add cpufreq shared info definition
  xen: arm: add XEN_SYSCTL_cpufreq_op definition
  cpufreq: add hwdom-cpufreq driver
  xen/arm: enable cpufreq functionality for ARM

 MAINTAINERS                                        |   3 +-
 xen/Rules.mk                                       |   4 +
 xen/arch/arm/Makefile                              |   1 +
 xen/arch/arm/Rules.mk                              |   3 +
 xen/arch/arm/domain_build.c                        |  78 +++-
 xen/arch/arm/platform_hypercall.c                  |  84 ++++
 xen/arch/arm/traps.c                               |   1 +
 xen/arch/x86/Rules.mk                              |   2 +
 xen/arch/x86/acpi/cpu_idle.c                       |   2 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c                |   2 +-
 xen/arch/x86/acpi/cpufreq/powernow.c               |   2 +-
 xen/arch/x86/acpi/power.c                          |   2 +-
 xen/arch/x86/cpu/mwait-idle.c                      |   2 +-
 xen/arch/x86/platform_hypercall.c                  |   2 +-
 xen/common/sysctl.c                                |  10 +-
 xen/drivers/Makefile                               |   1 +
 xen/drivers/acpi/Makefile                          |   1 -
 xen/drivers/cpufreq/Makefile                       |   1 +
 xen/drivers/cpufreq/cpufreq.c                      |  82 +++-
 xen/drivers/cpufreq/cpufreq_misc_governors.c       |   2 +-
 xen/drivers/cpufreq/cpufreq_ondemand.c             |   4 +-
 xen/drivers/cpufreq/hwdom-cpufreq.c                | 422 +++++++++++++++++++++
 xen/drivers/cpufreq/utility.c                      |  13 +-
 xen/drivers/pm/Makefile                            |   1 +
 xen/drivers/{acpi/pmstat.c => pm/stat.c}           |  16 +-
 xen/include/asm-arm/shared.h                       |  14 +
 xen/include/public/arch-arm.h                      |  12 +
 xen/include/public/platform.h                      |   1 +
 xen/include/public/sysctl.h                        |  11 +
 xen/include/{acpi/cpufreq => xen}/cpufreq.h        |  15 +-
 xen/include/{acpi/cpufreq => xen}/processor_perf.h |   7 +
 xen/include/xsm/dummy.h                            |  12 +-
 xen/include/xsm/xsm.h                              |  10 +-
 xen/xsm/flask/hooks.c                              |   3 +-
 34 files changed, 781 insertions(+), 45 deletions(-)
 create mode 100644 xen/arch/arm/platform_hypercall.c
 create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c
 create mode 100644 xen/drivers/pm/Makefile
 rename xen/drivers/{acpi/pmstat.c => pm/stat.c} (97%)
 create mode 100644 xen/include/asm-arm/shared.h
 rename xen/include/{acpi/cpufreq => xen}/cpufreq.h (96%)
 rename xen/include/{acpi/cpufreq => xen}/processor_perf.h (95%)

-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBK2-00066e-La; Tue, 11 Nov 2014 13:17:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBK1-00066K-Nv
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:25 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	25/B4-22819-56C02645; Tue, 11 Nov 2014 13:17:25 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415711841!11769494!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22130 invoked from network); 11 Nov 2014 13:17:23 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:23 -0000
Received: from mail-la0-f51.google.com ([209.85.215.51]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMYTFHaVt9i+kgUOQfWxGk1tAnQCh7@postini.com;
	Tue, 11 Nov 2014 05:17:23 PST
Received: by mail-la0-f51.google.com with SMTP id q1so9440603lam.24
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=yq+IZOoRvlhSfvUKFGvEYFfEBhiAIEO4mv3FB1acvV8=;
	b=HGDsxT6YGZueYSOvOc/M5R8BUrbgQOJuOhzpdh9MHPDuKk3zDExOcDMSHBhA8H/Y0f
	OpZwX18JCMF2HS319eawJugaYsXy7H6Ian0i/68L5lj2/803vROHHtVg/7Iel74Xa3hk
	CRFX0yaenfxFLkcsx1RYfpnOvpIuwKSXNJUBA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=yq+IZOoRvlhSfvUKFGvEYFfEBhiAIEO4mv3FB1acvV8=;
	b=iATxbb7AOXNF1Zkoxz4wigkwPIposN4i/M5srT4DkATgUWlXWB/SNvabYU65QO9JX6
	hQNo4JJvo1BljYwvqdvxMcwpGJnbOb7eeAZglveeyCpMLmzkWyXdcE2UIhdnGEHfRiS8
	IIerv4RBHmaaI4G/uDMWct8pRBzgn8gRkrx9IE9jdodsWBgnDV6q8jRK4yY7rfPTu5CM
	FcAdRbPWL3pGGOZkTIRCRSkBRuUF1eZqn59h6nP9UkYz/YUWk6F7qCsKBw9VuTjbWZ5d
	VEuwncUAyCs7AEkD8thjxT7ngJTntfwM6R4qoMVxRe0phv53UyBxsDiKiU0grNy66Z1F
	3j2A==
X-Gm-Message-State: ALoCoQl+fBcSz7ImhyXV3+jN8WYR9pCULyVoOuiGLs/TNEzRuYCLS8QhWogfMPUEuqN9PnerLpg/hzrrPNF3crpUgkZUxVfCkAZm2m6N7yWhpwud/2LVHfeDF8Iwm9g3mXc2+8U7+TRW4usDLvRdWYbiujOiBhQIzQ==
X-Received: by 10.112.63.70 with SMTP id e6mr2466049lbs.93.1415711839844;
	Tue, 11 Nov 2014 05:17:19 -0800 (PST)
X-Received: by 10.112.63.70 with SMTP id e6mr2466041lbs.93.1415711839772;
	Tue, 11 Nov 2014 05:17:19 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id tl8sm5967667lbb.47.2014.11.11.05.17.18
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:19 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:03 +0200
Message-Id: <1415711834-1740-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 01/12] cpufreq: move cpufreq.h file to
	the xen/include/xen location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 MAINTAINERS                                  | 1 +
 xen/arch/x86/acpi/cpu_idle.c                 | 2 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c          | 2 +-
 xen/arch/x86/acpi/cpufreq/powernow.c         | 2 +-
 xen/arch/x86/acpi/power.c                    | 2 +-
 xen/arch/x86/cpu/mwait-idle.c                | 2 +-
 xen/drivers/acpi/pmstat.c                    | 2 +-
 xen/drivers/cpufreq/cpufreq.c                | 2 +-
 xen/drivers/cpufreq/cpufreq_misc_governors.c | 2 +-
 xen/drivers/cpufreq/cpufreq_ondemand.c       | 4 ++--
 xen/drivers/cpufreq/utility.c                | 2 +-
 xen/include/{acpi/cpufreq => xen}/cpufreq.h  | 7 +++++--
 12 files changed, 17 insertions(+), 13 deletions(-)
 rename xen/include/{acpi/cpufreq => xen}/cpufreq.h (98%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7757cdd..49f56a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -235,6 +235,7 @@ X:	xen/arch/x86/acpi/boot.c
 X:	xen/arch/x86/acpi/lib.c
 F:	xen/drivers/cpufreq/
 F:	xen/include/acpi/cpufreq/
+F:	xen/include/xen/cpufreq.h
 
 QEMU-DM
 M:	Ian Jackson <ian.jackson@eu.citrix.com>
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 597befa..d773955 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -51,7 +51,7 @@
 #include <xen/softirq.h>
 #include <public/platform.h>
 #include <public/sysctl.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <asm/apic.h>
 #include <asm/cpuidle.h>
 #include <asm/mwait.h>
diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 4a6aeb3..5d22257 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -42,7 +42,7 @@
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 enum {
     UNDEFINED_CAPABLE = 0,
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c b/xen/arch/x86/acpi/cpufreq/powernow.c
index 2c9fea2..4961d55 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -36,7 +36,7 @@
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define CPUID_6_ECX_APERFMPERF_CAPABILITY       (0x1)
 #define CPUID_FREQ_VOLT_CAPABILITIES    0x80000007
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index f41f0de..f4a87e3 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -29,7 +29,7 @@
 #include <asm/tboot.h>
 #include <asm/apic.h>
 #include <asm/io_apic.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 uint32_t system_reset_counter = 1;
 
diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index 85179f2..c72219a 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -59,7 +59,7 @@
 #include <asm/hpet.h>
 #include <asm/mwait.h>
 #include <asm/msr.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define MWAIT_IDLE_VERSION "0.4"
 #undef PREFIX
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index daac2da..3486148 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -40,7 +40,7 @@
 #include <xen/acpi.h>
 
 #include <public/sysctl.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <xen/pmstat.h>
 
 DEFINE_PER_CPU_READ_MOSTLY(struct pm_px *, cpufreq_statistic_data);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index ab66884..f5f4d75 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -44,7 +44,7 @@
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 static unsigned int __read_mostly usr_min_freq;
 static unsigned int __read_mostly usr_max_freq;
diff --git a/xen/drivers/cpufreq/cpufreq_misc_governors.c b/xen/drivers/cpufreq/cpufreq_misc_governors.c
index 746bbcd..4a5510c 100644
--- a/xen/drivers/cpufreq/cpufreq_misc_governors.c
+++ b/xen/drivers/cpufreq/cpufreq_misc_governors.c
@@ -18,7 +18,7 @@
 #include <xen/init.h>
 #include <xen/percpu.h>
 #include <xen/sched.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 /*
  * cpufreq userspace governor
diff --git a/xen/drivers/cpufreq/cpufreq_ondemand.c b/xen/drivers/cpufreq/cpufreq_ondemand.c
index 7fdba03..d490c8a 100644
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
@@ -1,5 +1,5 @@
 /*
- *  xen/arch/x86/acpi/cpufreq/cpufreq_ondemand.c
+ *  xen/drivers/cpufreq/cpufreq_ondemand.c
  *
  *  Copyright (C)  2001 Russell King
  *            (C)  2003 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>.
@@ -18,7 +18,7 @@
 #include <xen/types.h>
 #include <xen/sched.h>
 #include <xen/timer.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define DEF_FREQUENCY_UP_THRESHOLD              (80)
 #define MIN_FREQUENCY_UP_THRESHOLD              (11)
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 519f862..3cb0b3e 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -28,7 +28,7 @@
 #include <xen/sched.h>
 #include <xen/timer.h>
 #include <xen/trace.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <public/sysctl.h>
 
 struct cpufreq_driver   *cpufreq_driver;
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/xen/cpufreq.h
similarity index 98%
rename from xen/include/acpi/cpufreq/cpufreq.h
rename to xen/include/xen/cpufreq.h
index f96c3e4..fa653ef 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -1,5 +1,5 @@
 /*
- *  xen/include/acpi/cpufreq/cpufreq.h
+ *  xen/include/xen/cpufreq.h
  *
  *  Copyright (C) 2001 Russell King
  *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
@@ -16,9 +16,12 @@
 
 #include <xen/types.h>
 #include <xen/list.h>
+#include <xen/percpu.h>
+#include <xen/spinlock.h>
+#include <xen/errno.h>
 #include <xen/cpumask.h>
 
-#include "processor_perf.h"
+#include <acpi/cpufreq/processor_perf.h>
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKN-0006Eb-17; Tue, 11 Nov 2014 13:17:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKK-0006DK-SI
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:45 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	70/2E-09284-87C02645; Tue, 11 Nov 2014 13:17:44 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415711860!11822811!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21356 invoked from network); 11 Nov 2014 13:17:43 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:43 -0000
Received: from mail-lb0-f177.google.com ([209.85.217.177]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMdO/HoIbSybosfWVNWpyFkafUfEW9@postini.com;
	Tue, 11 Nov 2014 05:17:42 PST
Received: by mail-lb0-f177.google.com with SMTP id z12so823573lbi.22
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=EFIS12KyxsCwv9kQH84nHK59oU6tRkfcIXPnJNzPRhA=;
	b=BU+XhZVaSZa2UH3YPZgILZUGGMOzeVRBBcwNACiHOuY/qiVrnuW+H6lnVN8hl49Pe/
	nCwbSo/ht5wztu3vBG6GoANf7sZVQEgJmj6u4ZI/rU9IgO8iczzY2+XElzeOekhGb1fh
	rdmVgpDuSnIMefc2Avw7//OiaE5hAQWmoRNZw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=EFIS12KyxsCwv9kQH84nHK59oU6tRkfcIXPnJNzPRhA=;
	b=NbBRDvL8Yx/JB/LPLTfiTxfbZ6UL40TlhuuChn40AxMtaQKTFqidqBi08uSpfuCbYM
	R6o5TT9waTsIg6ER/kQ5krXVKHJlZWvFEoOWu+Fou3cJx6dWeVSuyjWLLkRQZVuGl6/L
	u9Jar1mfUdzgM3oZo6vKo6GbdfS7PKw9TKG/0s5Ivdc0QWDGFRfnoh1mbHQ2HEp23DVN
	PFtLqYv2f0Grf77orQY88OujiEuoIrL+X5HD+Z7XykZwcUNxxXzpcaWpDE0LB1VbGwd0
	1XG3i8ZrllrsTds570RyTuTK52Bm/CLkbmnm5FBPOrSBAkM0TLUL6wWugI8tnXHT3nar
	kBYw==
X-Gm-Message-State: ALoCoQkhO/MdoNKJV/EMvBW3covCGq5zBYfXQ/Yzsx2XfjfJPkvXgsAf3N4FchorqPEKd849O6FOn8dOTvjN1uv5I/wRgM7oASmZcKgRrN1CLjRKHIszTE5IFMr6jf4G64PdgFOtVTj8q82tWqsTMX/J0XNcUgchvA==
X-Received: by 10.112.189.10 with SMTP id ge10mr35778269lbc.23.1415711858835; 
	Tue, 11 Nov 2014 05:17:38 -0800 (PST)
X-Received: by 10.112.189.10 with SMTP id ge10mr35778257lbc.23.1415711858772; 
	Tue, 11 Nov 2014 05:17:38 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id l7sm5966470lah.27.2014.11.11.05.17.37
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:37 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:10 +0200
Message-Id: <1415711834-1740-9-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 08/12] xen: arm: implement platform
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch enables xsm_platform_op hook for all architectures
and implements platform hypercall for ARM.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/Makefile             |  1 +
 xen/arch/arm/platform_hypercall.c | 84 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c              |  1 +
 xen/include/xsm/dummy.h           | 12 +++---
 xen/include/xsm/xsm.h             | 10 ++---
 xen/xsm/flask/hooks.c             |  3 +-
 6 files changed, 99 insertions(+), 12 deletions(-)
 create mode 100644 xen/arch/arm/platform_hypercall.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index d70f6d5..54d8258 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -32,6 +32,7 @@ obj-y += vuart.o
 obj-y += hvm.o
 obj-y += device.o
 obj-y += decode.o
+obj-y += platform_hypercall.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/platform_hypercall.c b/xen/arch/arm/platform_hypercall.c
new file mode 100644
index 0000000..f14641b
--- /dev/null
+++ b/xen/arch/arm/platform_hypercall.c
@@ -0,0 +1,84 @@
+/******************************************************************************
+ * platform_hypercall.c
+ *
+ * Hardware platform operations. Intended for use by domain-0 kernel.
+ *
+ * Copyright (c) 2014 GlobalLogic Inc.
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/sched.h>
+#include <xen/event.h>
+#include <xen/guest_access.h>
+#include <xen/pmstat.h>
+#include <xen/irq.h>
+#include <public/platform.h>
+#include <xsm/xsm.h>
+
+static DEFINE_SPINLOCK(xenpf_lock);
+
+long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
+{
+    long ret = 0;
+    struct xen_platform_op curop, *op = &curop;
+
+    if ( copy_from_guest(op, u_xenpf_op, 1) )
+        return -EFAULT;
+
+    if ( op->interface_version != XENPF_INTERFACE_VERSION )
+        return -EACCES;
+
+    ret = xsm_platform_op(XSM_PRIV, op->cmd);
+    if ( ret )
+        return ret;
+
+    /*
+     * Trylock here avoids deadlock with an existing platform critical section
+     * which might (for some current or future reason) want to synchronise
+     * with this vcpu.
+     */
+    while ( !spin_trylock(&xenpf_lock) )
+        if ( hypercall_preempt_check() )
+            return hypercall_create_continuation(
+                __HYPERVISOR_platform_op, "h", u_xenpf_op);
+
+    switch ( op->cmd )
+    {
+    case XENPF_set_processor_pminfo:
+        switch ( op->u.set_pminfo.type )
+        {
+        case XEN_PM_PX:
+            if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
+            {
+                ret = -ENOSYS;
+                break;
+           }
+#ifdef HAS_CPUFREQ
+            ret = set_px_pminfo(op->u.set_pminfo.id, &op->u.set_pminfo.u.perf);
+#else
+            ret = -EINVAL;
+#endif
+            break;
+
+        default:
+            ret = -EINVAL;
+            break;
+        }
+        break;
+    }
+
+    spin_unlock(&xenpf_lock);
+
+    return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 21c7b26..d1b0014 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1012,6 +1012,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
     HYPERCALL(hvm_op, 2),
     HYPERCALL(grant_table_op, 3),
     HYPERCALL_ARM(vcpu_op, 3),
+    HYPERCALL(platform_op, 1),
 };
 
 typedef int (*arm_psci_fn_t)(uint32_t, register_t);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index eb9e1a1..911fb5d 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -491,6 +491,12 @@ static XSM_INLINE int xsm_hvm_param_nested(XSM_DEFAULT_ARG struct domain *d)
     return xsm_default_action(action, current->domain, d);
 }
 
+static XSM_INLINE int xsm_platform_op(XSM_DEFAULT_ARG uint32_t op)
+{
+    XSM_ASSERT_ACTION(XSM_PRIV);
+    return xsm_default_action(action, current->domain, NULL);
+}
+
 #ifdef CONFIG_X86
 static XSM_INLINE int xsm_shadow_control(XSM_DEFAULT_ARG struct domain *d, uint32_t op)
 {
@@ -546,12 +552,6 @@ static XSM_INLINE int xsm_apic(XSM_DEFAULT_ARG struct domain *d, int cmd)
     return xsm_default_action(action, d, NULL);
 }
 
-static XSM_INLINE int xsm_platform_op(XSM_DEFAULT_ARG uint32_t op)
-{
-    XSM_ASSERT_ACTION(XSM_PRIV);
-    return xsm_default_action(action, current->domain, NULL);
-}
-
 static XSM_INLINE int xsm_machine_memory_map(XSM_DEFAULT_VOID)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 1939453..5cb1e0d 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -509,6 +509,11 @@ static inline int xsm_hvm_param_nested (xsm_default_t def, struct domain *d)
     return xsm_ops->hvm_param_nested(d);
 }
 
+static inline int xsm_platform_op (xsm_default_t def, uint32_t op)
+{
+    return xsm_ops->platform_op(op);
+}
+
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (xsm_default_t def, struct domain *d, uint32_t op)
 {
@@ -560,11 +565,6 @@ static inline int xsm_memtype (xsm_default_t def, uint32_t access)
     return xsm_ops->memtype(access);
 }
 
-static inline int xsm_platform_op (xsm_default_t def, uint32_t op)
-{
-    return xsm_ops->platform_op(op);
-}
-
 static inline int xsm_machine_memory_map(xsm_default_t def)
 {
     return xsm_ops->machine_memory_map();
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d94ab77..29126ec 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1542,6 +1542,8 @@ static struct xsm_operations flask_ops = {
     .add_to_physmap = flask_add_to_physmap,
     .remove_from_physmap = flask_remove_from_physmap,
 
+    .platform_op = flask_platform_op,
+
 #ifdef CONFIG_X86
     .shadow_control = flask_shadow_control,
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
@@ -1552,7 +1554,6 @@ static struct xsm_operations flask_ops = {
     .mem_event_op = flask_mem_event_op,
     .mem_sharing_op = flask_mem_sharing_op,
     .apic = flask_apic,
-    .platform_op = flask_platform_op,
     .machine_memory_map = flask_machine_memory_map,
     .domain_memory_map = flask_domain_memory_map,
     .mmu_update = flask_mmu_update,
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBK8-00067g-H9; Tue, 11 Nov 2014 13:17:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBK7-000679-0x
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:31 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	E5/7B-14214-A6C02645; Tue, 11 Nov 2014 13:17:30 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415711847!11777470!1
X-Originating-IP: [64.18.0.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24524 invoked from network); 11 Nov 2014 13:17:29 -0000
Received: from exprod5og117.obsmtp.com (HELO exprod5og117.obsmtp.com)
	(64.18.0.149)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 13:17:29 -0000
Received: from mail-la0-f42.google.com ([209.85.215.42]) (using TLSv1) by
	exprod5ob117.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMZip/5KRBakthBhgBJ8N0+W0ZD9iK@postini.com;
	Tue, 11 Nov 2014 05:17:29 PST
Received: by mail-la0-f42.google.com with SMTP id gq15so9660151lab.1
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=mDypeJq6Xfd/WvShiqJmfitzjHxkYyoecdy+64EqB4U=;
	b=WHoU6U7LnwTFQdXjxCh2Egx9w9QLqXhx1q8uJmnKuQgP2msjGwatZvOeY5J/Rdrbju
	0rEsTxXFdUpxmTRygq27DkST/FqNHyslgYbDwOTdwpiBUx1+d6juUrHmT7/jPDeUkqOk
	2Y61Qpaa8WmlBath/PtVZdOMfwIvJMmH1g67E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=mDypeJq6Xfd/WvShiqJmfitzjHxkYyoecdy+64EqB4U=;
	b=C45CfOxaJjL0iN8zP0FnU7hc5w040vanTCoezqmMXjJfwPbAkIh4PlTEiG60pXhXz/
	TPtlcqHov/pUVF0q/jpQi4Sb7H/finCkBUxrI68G20oiBnoheii6NRPhZu4t63v2+GbG
	KC2q5zkwI1UAfAimouX5VPRVLht3kHt3VHfSGVk75+Ke5HrWrMq0ZriDq2yweRcQoUgm
	nb/IWImFMNaYtN90INWUzUezsHLfEwC/AW614CL8BpPkCKGov/IoUUK6ivZszYL1XeeY
	wcKLoXrJ2W2TdJa5GTv2/FfnUUUZjXB/tbcGOBHcos834GCqRFVPgygVdi6QaT1A/lE6
	0HVg==
X-Gm-Message-State: ALoCoQm3+lPfafpWZZ0PfCuoJ5e2cHPUg3a3ZzD1T26a6wqt2ABfm0jYMuRcDCb1CVo+7tuW/e3evR7UFTEuaAN+CTZk4Sm0Cwkg/yPUZ2PQMIZK+iViT8nq6wZSjTyDVnx34wTN57ZSGPixz2bdU3gzO1OH2nYI3g==
X-Received: by 10.112.168.97 with SMTP id zv1mr36690031lbb.6.1415711845584;
	Tue, 11 Nov 2014 05:17:25 -0800 (PST)
X-Received: by 10.112.168.97 with SMTP id zv1mr36690022lbb.6.1415711845522;
	Tue, 11 Nov 2014 05:17:25 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id dq5sm5981579lbc.11.2014.11.11.05.17.24
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:24 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:05 +0200
Message-Id: <1415711834-1740-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 03/12] pmstat: move pmstat.c file to the
	xen/drivers/pm/stat.c location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                             | 1 +
 xen/arch/x86/Rules.mk                    | 1 +
 xen/common/sysctl.c                      | 2 +-
 xen/drivers/Makefile                     | 1 +
 xen/drivers/acpi/Makefile                | 1 -
 xen/drivers/pm/Makefile                  | 1 +
 xen/drivers/{acpi/pmstat.c => pm/stat.c} | 0
 7 files changed, 5 insertions(+), 2 deletions(-)
 create mode 100644 xen/drivers/pm/Makefile
 rename xen/drivers/{acpi/pmstat.c => pm/stat.c} (100%)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3a6cec5..b7caab6 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -55,6 +55,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 576985e..9e9fbf1 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,7 @@
 
 HAS_IOPORTS := y
 HAS_ACPI := y
+HAS_PM := y
 HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0cb6ee1..0dcf06a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -170,7 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         op->u.availheap.avail_bytes <<= PAGE_SHIFT;
         break;
 
-#ifdef HAS_ACPI
+#ifdef HAS_PM
     case XEN_SYSCTL_get_pmstat:
         ret = do_get_pm_info(&op->u.get_pmstat);
         break;
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 9c70f20..ee4fd4d 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -4,3 +4,4 @@ subdir-$(HAS_PCI) += pci
 subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VIDEO) += video
+subdir-$(HAS_PM) += pm
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index bbb06a7..0505742 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -5,7 +5,6 @@ subdir-$(x86) += apei
 obj-bin-y += tables.init.o
 obj-y += numa.o
 obj-y += osl.o
-obj-y += pmstat.o
 
 obj-$(x86) += hwregs.o
 obj-$(x86) += reboot.o
diff --git a/xen/drivers/pm/Makefile b/xen/drivers/pm/Makefile
new file mode 100644
index 0000000..2073683
--- /dev/null
+++ b/xen/drivers/pm/Makefile
@@ -0,0 +1 @@
+obj-y += stat.o
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/pm/stat.c
similarity index 100%
rename from xen/drivers/acpi/pmstat.c
rename to xen/drivers/pm/stat.c
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKE-00069N-GB; Tue, 11 Nov 2014 13:17:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKC-00068W-Qf
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1A/82-09842-07C02645; Tue, 11 Nov 2014 13:17:36 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415711853!3882624!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3196 invoked from network); 11 Nov 2014 13:17:35 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:35 -0000
Received: from mail-la0-f46.google.com ([209.85.215.46]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMbVO/vbr9eS9IHffqLgJv7KyAs/bd@postini.com;
	Tue, 11 Nov 2014 05:17:35 PST
Received: by mail-la0-f46.google.com with SMTP id gm9so9325130lab.5
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=JgXU4x7QJOvEpUbbuKilOBLEpUATJDI4xA7NawUjB3k=;
	b=fpzYWOnrzBRiAMVnMe9PO7tfIu2ppqU2XviyK2Fk8VLJF/HSJKYf0ECdj5VoB4/BLH
	MtYL1C4aISbRNak6Fn2GuTqPITRWBMsaC6RZZcinzAlZahOIK8V4wadgeYuDGKg9eQ/1
	8knD+yQ1s2IVIzfxQEQCrlnl6Uy0IP4tYhFUQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=JgXU4x7QJOvEpUbbuKilOBLEpUATJDI4xA7NawUjB3k=;
	b=CYMvy1Qv3cUajBlaKhZ98S0l4CGPWNmlvlrApSXZqPO2ZPU+73q86JJGdMYr9TIwCU
	+YjXC8biLnx5tNTx60cumFFGtMhWSUrpkZmVYY84Epbzf2Kk3LJMvjtfElJjHg55zRxK
	MmoS3Hk7oDpM2oxUvEV2p/VuP363/1BE7tn7SYIzW/uEeDDo9ZgolUpCzbx4OEPOUP5N
	wEo5wzgS55sVbvOwFxOAc+jZwx2ygHScKC/6xM9zM5njQu2ZhDXM2OqSxwAdP2d77wf+
	cshLrMdJEKVSxhCdURIIX4iRiBpYKMWaC0bsJ5WCYTxnjmQZvdRjHkn/0zzFjOeVhdEj
	p8SQ==
X-Gm-Message-State: ALoCoQnsl9TBFozM16yb5cGLar3eqyAMl71MiP92GPQEMentS0ksRsr2WvNx5PvBtfziQVtIFL6jJsAIn+fJIesVPfm2ZTHY4L+jv+2zi/3oazQQfJftbIbcqpx0eSWbvn7KvTWQ9GLW4FXr0d9vOX9dYwWDaoLj1A==
X-Received: by 10.112.235.135 with SMTP id um7mr333753lbc.96.1415711851966;
	Tue, 11 Nov 2014 05:17:31 -0800 (PST)
X-Received: by 10.112.235.135 with SMTP id um7mr333679lbc.96.1415711851002;
	Tue, 11 Nov 2014 05:17:31 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id gm5sm4026722lbc.30.2014.11.11.05.17.29
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:30 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:07 +0200
Message-Id: <1415711834-1740-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 05/12] pmstat: make pmstat functions more
	generalizable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ACPI-specific parts are moved under appropriate ifdefs.
Now pmstat functions can be used in ARM platform.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/drivers/pm/stat.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
index 3154051..1d13805 100644
--- a/xen/drivers/pm/stat.c
+++ b/xen/drivers/pm/stat.c
@@ -37,7 +37,6 @@
 #include <asm/processor.h>
 #include <xen/percpu.h>
 #include <xen/domain.h>
-#include <xen/acpi.h>
 
 #include <public/sysctl.h>
 #include <xen/cpufreq.h>
@@ -134,6 +133,8 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
         break;
     }
 
+/* For now those operations can be used only when ACPI is enabled */
+#ifdef CONFIG_ACPI
     case PMSTAT_get_max_cx:
     {
         op->u.getcx.nr = pmstat_get_cx_nr(op->cpuid);
@@ -152,6 +153,7 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
         ret = pmstat_reset_cx_stat(op->cpuid);
         break;
     }
+#endif /* CONFIG_ACPI */
 
     default:
         printk("not defined sub-hypercall @ do_get_pm_info\n");
@@ -467,6 +469,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         break;
     }
 
+#ifdef CONFIG_ACPI
     case XEN_SYSCTL_pm_op_get_max_cstate:
     {
         op->u.get_max_cstate = acpi_get_cstate_limit();
@@ -478,6 +481,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         acpi_set_cstate_limit(op->u.set_max_cstate);
         break;
     }
+#endif /* CONFIG_ACPI */
 
 #ifdef HAS_CPU_TURBO
     case XEN_SYSCTL_pm_op_enable_turbo:
@@ -502,6 +506,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
     return ret;
 }
 
+#ifdef CONFIG_ACPI
 int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 {
     u32 bits[3];
@@ -532,3 +537,4 @@ int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 
     return ret;
 }
+#endif /* CONFIG_ACPI */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKB-00068H-TI; Tue, 11 Nov 2014 13:17:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKA-000682-Bw
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:34 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	97/96-26652-D6C02645; Tue, 11 Nov 2014 13:17:33 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415711850!11769541!1
X-Originating-IP: [64.18.0.198]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23101 invoked from network); 11 Nov 2014 13:17:32 -0000
Received: from exprod5og123.obsmtp.com (HELO exprod5og123.obsmtp.com)
	(64.18.0.198)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:32 -0000
Received: from mail-lb0-f178.google.com ([209.85.217.178]) (using TLSv1) by
	exprod5ob123.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMaU8JD6imb+PycSRFXRdDL6rUCXIc@postini.com;
	Tue, 11 Nov 2014 05:17:32 PST
Received: by mail-lb0-f178.google.com with SMTP id f15so8369911lbj.37
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=713bit2g0RhvBKeHzo9XWlypOoemnEZ6Rrwf4CVZRDY=;
	b=MmIDGYE7B+9AR8smiQYOQicHRDmeku2pD3smxkRSDTHIRUxwHuzDWSV9Le0yT8vnue
	LvRILHvRAFPNmFIovw64PeJ0IZckPD1c8+OHhAaahsWdqv/CIDy14acKdCTCy1e2FoaK
	SQ59Q4LBFtvEOnfWnYhAlLO/H/JPFsjK5ntpg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=713bit2g0RhvBKeHzo9XWlypOoemnEZ6Rrwf4CVZRDY=;
	b=dcWUU+8HBXmlxjB/Tfb7E7BjbScs0a9nFyvSmhn66sX9A/8p8p6RoWfUDgx2JyG4WP
	XCyEf+ctc5AUEz1wbOJrmlo5+kxz3ph3QLhQqMExp7C/pJ1SDRckosW6VcOioWULE3Cu
	5KgtO2q7lhj9SRr+1X7IJFldErk454HqRd+d2cXOYgfJqfofTe/Isp+nlovmUgwFQW9B
	kAyETrQrj9vLjFeSIOYPgq9WivDEV0U/5Ek0DOin88FiPrwkHSWod/T7k4SjIOJNwsVH
	jBcmxnwnrVIdvDkJ1C2wsYrmVb5pdGufMyf/O/68aE9pZ4JqodPbicxLj6fRACTUbjjP
	t0YA==
X-Gm-Message-State: ALoCoQkv6KGs2AWk9vTlR2LkFIiFeNDEskKxaEZA2Q0CJwU8yrQMVRBeMKXSyOUmwsP6egJ/0RNPu6nj91egsFewDlGc1qI7Ae2cOHlRekyi/MVWfiewXLTUWFJALhpXeI6fUVFnm2mJcvRsvr5u0AlJgzhSgcpHHw==
X-Received: by 10.112.136.164 with SMTP id qb4mr36426821lbb.62.1415711848397; 
	Tue, 11 Nov 2014 05:17:28 -0800 (PST)
X-Received: by 10.112.136.164 with SMTP id qb4mr36426811lbb.62.1415711848329; 
	Tue, 11 Nov 2014 05:17:28 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id pm3sm5980759lbb.15.2014.11.11.05.17.26
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:27 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:06 +0200
Message-Id: <1415711834-1740-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 04/12] cpufreq: make turbo settings to be
	configurable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This settings is not needed for some architectures.
So make it to be configurable and use it for x86
architecture.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                  |  1 +
 xen/arch/x86/Rules.mk         |  1 +
 xen/drivers/cpufreq/utility.c | 11 ++++++++++-
 xen/drivers/pm/stat.c         |  6 ++++++
 xen/include/xen/cpufreq.h     |  6 ++++++
 5 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index b7caab6..5953152 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_PM)        += -DHAS_PM
+CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 9e9fbf1..cfe4f90 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -4,6 +4,7 @@
 HAS_IOPORTS := y
 HAS_ACPI := y
 HAS_PM := y
+HAS_CPU_TURBO := y
 HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 3cb0b3e..e92cf17 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -209,7 +209,9 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
 {
     unsigned int min_freq = ~0;
     unsigned int max_freq = 0;
+#ifdef HAS_CPU_TURBO
     unsigned int second_max_freq = 0;
+#endif
     unsigned int i;
 
     for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
@@ -221,6 +223,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
         if (freq > max_freq)
             max_freq = freq;
     }
+#ifdef HAS_CPU_TURBO
     for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
         unsigned int freq = table[i].frequency;
         if (freq == CPUFREQ_ENTRY_INVALID || freq == max_freq)
@@ -234,9 +237,13 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
         printk("max_freq: %u    second_max_freq: %u\n",
                max_freq, second_max_freq);
 
+    policy->cpuinfo.second_max_freq = second_max_freq;
+#else
+    if (cpufreq_verbose)
+        printk("max_freq: %u\n", max_freq);
+#endif
     policy->min = policy->cpuinfo.min_freq = min_freq;
     policy->max = policy->cpuinfo.max_freq = max_freq;
-    policy->cpuinfo.second_max_freq = second_max_freq;
 
     if (policy->min == ~0)
         return -EINVAL;
@@ -390,6 +397,7 @@ int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag)
     return policy->cur;
 }
 
+#ifdef HAS_CPU_TURBO
 int cpufreq_update_turbo(int cpuid, int new_state)
 {
     struct cpufreq_policy *policy;
@@ -430,6 +438,7 @@ int cpufreq_get_turbo_status(int cpuid)
     policy = per_cpu(cpufreq_cpu_policy, cpuid);
     return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
 }
+#endif /* HAS_CPU_TURBO */
 
 /*********************************************************************
  *                 POLICY                                            *
diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
index 3486148..3154051 100644
--- a/xen/drivers/pm/stat.c
+++ b/xen/drivers/pm/stat.c
@@ -292,7 +292,11 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
             &op->u.get_para.u.ondemand.sampling_rate,
             &op->u.get_para.u.ondemand.up_threshold);
     }
+#ifdef HAS_CPU_TURBO
     op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid);
+#else
+    op->u.get_para.turbo_enabled = 0;
+#endif
 
     return ret;
 }
@@ -475,6 +479,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         break;
     }
 
+#ifdef HAS_CPU_TURBO
     case XEN_SYSCTL_pm_op_enable_turbo:
     {
         ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
@@ -486,6 +491,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
         break;
     }
+#endif /* HAS_CPU_TURBO */
 
     default:
         printk("not defined sub-hypercall @ do_pm_op\n");
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index 82dc4dc..d7b6c34 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -39,7 +39,9 @@ extern struct acpi_cpufreq_data *cpufreq_drv_data[NR_CPUS];
 
 struct cpufreq_cpuinfo {
     unsigned int        max_freq;
+#ifdef HAS_CPU_TURBO
     unsigned int        second_max_freq;    /* P1 if Turbo Mode is on */
+#endif
     unsigned int        min_freq;
     unsigned int        transition_latency; /* in 10^(-9) s = nanoseconds */
 };
@@ -59,10 +61,12 @@ struct cpufreq_policy {
 
     bool_t              resume; /* flag for cpufreq 1st run
                                  * S3 wakeup, hotplug cpu, etc */
+#ifdef HAS_CPU_TURBO
     s8                  turbo;  /* tristate flag: 0 for unsupported
                                  * -1 for disable, 1 for enabled
                                  * See CPUFREQ_TURBO_* below for defines */
     bool_t              aperf_mperf; /* CPU has APERF/MPERF MSRs */
+#endif
 };
 DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy);
 
@@ -127,8 +131,10 @@ extern int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag);
 #define CPUFREQ_TURBO_UNSUPPORTED   0
 #define CPUFREQ_TURBO_ENABLED       1
 
+#ifdef HAS_CPU_TURBO
 extern int cpufreq_update_turbo(int cpuid, int new_state);
 extern int cpufreq_get_turbo_status(int cpuid);
+#endif
 
 static __inline__ int 
 __cpufreq_governor(struct cpufreq_policy *policy, unsigned int event)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKO-0006GF-9k; Tue, 11 Nov 2014 13:17:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKN-0006Ea-3D
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:47 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	50/A6-17735-A7C02645; Tue, 11 Nov 2014 13:17:46 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415711863!8091002!1
X-Originating-IP: [64.18.0.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30402 invoked from network); 11 Nov 2014 13:17:45 -0000
Received: from exprod5og109.obsmtp.com (HELO exprod5og109.obsmtp.com)
	(64.18.0.188)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:45 -0000
Received: from mail-lb0-f179.google.com ([209.85.217.179]) (using TLSv1) by
	exprod5ob109.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMd4eLqkQzp/GkUt9qzWl+C2cw1Dqf@postini.com;
	Tue, 11 Nov 2014 05:17:45 PST
Received: by mail-lb0-f179.google.com with SMTP id l4so7538326lbv.24
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=1iCFdRRi7ziCcSGlVnf/IGNJN2aXeU0zyXK2eCZt3hg=;
	b=f95UNAnPjPrvirjbid5c1JY0PBoppRHRQI2dawsyRuO3m/fHDMYIrSlHqgzfCa02Uk
	SKKbLNcyZ+Z2B6KKaXxfefU+AHoRjmsSWFWmaCqjio63IWPGGBX3VuvkOIF4j2O+UW8z
	dT+3P6Go/SfK6YTXzQr8phjIGfkeKUpd4Zrp8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=1iCFdRRi7ziCcSGlVnf/IGNJN2aXeU0zyXK2eCZt3hg=;
	b=CEx11Hy9Bhkj/UXk6jyrTp/uod2WExNhMml7WxG2snlLCfH7Gp8+A2x2gqObAqrrme
	kWYE9vAJdZyQF+BTR0bbZllC6sMJBcprusd1Ej5JtK7ZtGs4ouE6cim76jjbFDat3gcr
	4rGnA5FP3Ji6YXsYYqqz4hMvYvm+v0u5hC6VYi8ZgUhHRJ68Sx0qV5KRExcTvt5V7uZI
	oOD4fV1XoK+vaqcCZ6CB5zq75kT6FUMgnwJUWXDUyYy0Hq0jGyBZoXdVYOh8EJmcWILR
	ir5lW1BZAbmPTuEXqW1g36m0WnRpB/nKQUr85PQP9m4JncQ+XJbfnBwHqQU9pVbbd+qr
	ypyQ==
X-Gm-Message-State: ALoCoQnIMo0UL8oRKFQa0ia7+daA3yZnUck4jeW/1jC1X+FgBSpwM/1mv328SgPph2GYHYY1zPXA6q19Rxo461pnVO8GXy8c5vBOTe/MdmPBhRjTdcy5OdBgGvNMjcvvlCvAHqC7YhAreWYO/35Hye2DE139Rkqugw==
X-Received: by 10.112.148.199 with SMTP id tu7mr36583100lbb.7.1415711861719;
	Tue, 11 Nov 2014 05:17:41 -0800 (PST)
X-Received: by 10.112.148.199 with SMTP id tu7mr36583095lbb.7.1415711861674;
	Tue, 11 Nov 2014 05:17:41 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id qk3sm5979954lbb.19.2014.11.11.05.17.40
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:40 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:11 +0200
Message-Id: <1415711834-1740-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 09/12] xen: arm: add cpufreq shared info
	definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This shared info will be used by hwdom-cpufreq driver
to send commands to the cpufreq driver in the hwdom.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/include/asm-arm/shared.h  | 14 ++++++++++++++
 xen/include/public/arch-arm.h | 12 ++++++++++++
 2 files changed, 26 insertions(+)
 create mode 100644 xen/include/asm-arm/shared.h

diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
new file mode 100644
index 0000000..4906f38
--- /dev/null
+++ b/xen/include/asm-arm/shared.h
@@ -0,0 +1,14 @@
+#ifndef __XEN_ARM_SHARED_H__
+#define __XEN_ARM_SHARED_H__
+
+#define GET_SET_SHARED(type, field)                                 \
+static inline type *arch_get_##field##_addr(const struct domain *d) \
+{                                                                   \
+   return &d->shared_info->arch.field;                              \
+}
+
+GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
+
+#undef GET_SET_SHARED
+
+#endif /* __XEN_ARM_SHARED_H__ */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 7496556..2f6ea66 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -309,7 +309,19 @@ struct arch_vcpu_info {
 };
 typedef struct arch_vcpu_info arch_vcpu_info_t;
 
+#define CPUFREQ_CMD_idle            0
+#define CPUFREQ_CMD_change_freq     1
+
+struct cpufreq_sh_info {
+    uint32_t cmd;       /* CPUFREQ_CMD_* */
+    uint32_t cpu;       /* Physical CPU number */
+    uint32_t freq;      /* Frequency in KHz */
+    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
+    int32_t result;     /* Returned result of the operation */
+};
+
 struct arch_shared_info {
+    struct cpufreq_sh_info cpufreq;
 };
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBK2-00066e-La; Tue, 11 Nov 2014 13:17:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBK1-00066K-Nv
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:25 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	25/B4-22819-56C02645; Tue, 11 Nov 2014 13:17:25 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415711841!11769494!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22130 invoked from network); 11 Nov 2014 13:17:23 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:23 -0000
Received: from mail-la0-f51.google.com ([209.85.215.51]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMYTFHaVt9i+kgUOQfWxGk1tAnQCh7@postini.com;
	Tue, 11 Nov 2014 05:17:23 PST
Received: by mail-la0-f51.google.com with SMTP id q1so9440603lam.24
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=yq+IZOoRvlhSfvUKFGvEYFfEBhiAIEO4mv3FB1acvV8=;
	b=HGDsxT6YGZueYSOvOc/M5R8BUrbgQOJuOhzpdh9MHPDuKk3zDExOcDMSHBhA8H/Y0f
	OpZwX18JCMF2HS319eawJugaYsXy7H6Ian0i/68L5lj2/803vROHHtVg/7Iel74Xa3hk
	CRFX0yaenfxFLkcsx1RYfpnOvpIuwKSXNJUBA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=yq+IZOoRvlhSfvUKFGvEYFfEBhiAIEO4mv3FB1acvV8=;
	b=iATxbb7AOXNF1Zkoxz4wigkwPIposN4i/M5srT4DkATgUWlXWB/SNvabYU65QO9JX6
	hQNo4JJvo1BljYwvqdvxMcwpGJnbOb7eeAZglveeyCpMLmzkWyXdcE2UIhdnGEHfRiS8
	IIerv4RBHmaaI4G/uDMWct8pRBzgn8gRkrx9IE9jdodsWBgnDV6q8jRK4yY7rfPTu5CM
	FcAdRbPWL3pGGOZkTIRCRSkBRuUF1eZqn59h6nP9UkYz/YUWk6F7qCsKBw9VuTjbWZ5d
	VEuwncUAyCs7AEkD8thjxT7ngJTntfwM6R4qoMVxRe0phv53UyBxsDiKiU0grNy66Z1F
	3j2A==
X-Gm-Message-State: ALoCoQl+fBcSz7ImhyXV3+jN8WYR9pCULyVoOuiGLs/TNEzRuYCLS8QhWogfMPUEuqN9PnerLpg/hzrrPNF3crpUgkZUxVfCkAZm2m6N7yWhpwud/2LVHfeDF8Iwm9g3mXc2+8U7+TRW4usDLvRdWYbiujOiBhQIzQ==
X-Received: by 10.112.63.70 with SMTP id e6mr2466049lbs.93.1415711839844;
	Tue, 11 Nov 2014 05:17:19 -0800 (PST)
X-Received: by 10.112.63.70 with SMTP id e6mr2466041lbs.93.1415711839772;
	Tue, 11 Nov 2014 05:17:19 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id tl8sm5967667lbb.47.2014.11.11.05.17.18
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:19 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:03 +0200
Message-Id: <1415711834-1740-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 01/12] cpufreq: move cpufreq.h file to
	the xen/include/xen location
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 MAINTAINERS                                  | 1 +
 xen/arch/x86/acpi/cpu_idle.c                 | 2 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c          | 2 +-
 xen/arch/x86/acpi/cpufreq/powernow.c         | 2 +-
 xen/arch/x86/acpi/power.c                    | 2 +-
 xen/arch/x86/cpu/mwait-idle.c                | 2 +-
 xen/drivers/acpi/pmstat.c                    | 2 +-
 xen/drivers/cpufreq/cpufreq.c                | 2 +-
 xen/drivers/cpufreq/cpufreq_misc_governors.c | 2 +-
 xen/drivers/cpufreq/cpufreq_ondemand.c       | 4 ++--
 xen/drivers/cpufreq/utility.c                | 2 +-
 xen/include/{acpi/cpufreq => xen}/cpufreq.h  | 7 +++++--
 12 files changed, 17 insertions(+), 13 deletions(-)
 rename xen/include/{acpi/cpufreq => xen}/cpufreq.h (98%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7757cdd..49f56a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -235,6 +235,7 @@ X:	xen/arch/x86/acpi/boot.c
 X:	xen/arch/x86/acpi/lib.c
 F:	xen/drivers/cpufreq/
 F:	xen/include/acpi/cpufreq/
+F:	xen/include/xen/cpufreq.h
 
 QEMU-DM
 M:	Ian Jackson <ian.jackson@eu.citrix.com>
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 597befa..d773955 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -51,7 +51,7 @@
 #include <xen/softirq.h>
 #include <public/platform.h>
 #include <public/sysctl.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <asm/apic.h>
 #include <asm/cpuidle.h>
 #include <asm/mwait.h>
diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 4a6aeb3..5d22257 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -42,7 +42,7 @@
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 enum {
     UNDEFINED_CAPABLE = 0,
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c b/xen/arch/x86/acpi/cpufreq/powernow.c
index 2c9fea2..4961d55 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -36,7 +36,7 @@
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define CPUID_6_ECX_APERFMPERF_CAPABILITY       (0x1)
 #define CPUID_FREQ_VOLT_CAPABILITIES    0x80000007
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index f41f0de..f4a87e3 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -29,7 +29,7 @@
 #include <asm/tboot.h>
 #include <asm/apic.h>
 #include <asm/io_apic.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 uint32_t system_reset_counter = 1;
 
diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index 85179f2..c72219a 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -59,7 +59,7 @@
 #include <asm/hpet.h>
 #include <asm/mwait.h>
 #include <asm/msr.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define MWAIT_IDLE_VERSION "0.4"
 #undef PREFIX
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index daac2da..3486148 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -40,7 +40,7 @@
 #include <xen/acpi.h>
 
 #include <public/sysctl.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <xen/pmstat.h>
 
 DEFINE_PER_CPU_READ_MOSTLY(struct pm_px *, cpufreq_statistic_data);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index ab66884..f5f4d75 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -44,7 +44,7 @@
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <acpi/acpi.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 static unsigned int __read_mostly usr_min_freq;
 static unsigned int __read_mostly usr_max_freq;
diff --git a/xen/drivers/cpufreq/cpufreq_misc_governors.c b/xen/drivers/cpufreq/cpufreq_misc_governors.c
index 746bbcd..4a5510c 100644
--- a/xen/drivers/cpufreq/cpufreq_misc_governors.c
+++ b/xen/drivers/cpufreq/cpufreq_misc_governors.c
@@ -18,7 +18,7 @@
 #include <xen/init.h>
 #include <xen/percpu.h>
 #include <xen/sched.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 /*
  * cpufreq userspace governor
diff --git a/xen/drivers/cpufreq/cpufreq_ondemand.c b/xen/drivers/cpufreq/cpufreq_ondemand.c
index 7fdba03..d490c8a 100644
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
@@ -1,5 +1,5 @@
 /*
- *  xen/arch/x86/acpi/cpufreq/cpufreq_ondemand.c
+ *  xen/drivers/cpufreq/cpufreq_ondemand.c
  *
  *  Copyright (C)  2001 Russell King
  *            (C)  2003 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>.
@@ -18,7 +18,7 @@
 #include <xen/types.h>
 #include <xen/sched.h>
 #include <xen/timer.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 
 #define DEF_FREQUENCY_UP_THRESHOLD              (80)
 #define MIN_FREQUENCY_UP_THRESHOLD              (11)
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 519f862..3cb0b3e 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -28,7 +28,7 @@
 #include <xen/sched.h>
 #include <xen/timer.h>
 #include <xen/trace.h>
-#include <acpi/cpufreq/cpufreq.h>
+#include <xen/cpufreq.h>
 #include <public/sysctl.h>
 
 struct cpufreq_driver   *cpufreq_driver;
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/xen/cpufreq.h
similarity index 98%
rename from xen/include/acpi/cpufreq/cpufreq.h
rename to xen/include/xen/cpufreq.h
index f96c3e4..fa653ef 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -1,5 +1,5 @@
 /*
- *  xen/include/acpi/cpufreq/cpufreq.h
+ *  xen/include/xen/cpufreq.h
  *
  *  Copyright (C) 2001 Russell King
  *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
@@ -16,9 +16,12 @@
 
 #include <xen/types.h>
 #include <xen/list.h>
+#include <xen/percpu.h>
+#include <xen/spinlock.h>
+#include <xen/errno.h>
 #include <xen/cpumask.h>
 
-#include "processor_perf.h"
+#include <acpi/cpufreq/processor_perf.h>
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBK1-00066G-3c; Tue, 11 Nov 2014 13:17:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBJz-00066B-2I
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BC/12-09842-26C02645; Tue, 11 Nov 2014 13:17:22 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415711839!11886888!1
X-Originating-IP: [64.18.0.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10052 invoked from network); 11 Nov 2014 13:17:21 -0000
Received: from exprod5og101.obsmtp.com (HELO exprod5og101.obsmtp.com)
	(64.18.0.141)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:21 -0000
Received: from mail-la0-f48.google.com ([209.85.215.48]) (using TLSv1) by
	exprod5ob101.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMXm2YNU0kWo0/3y9gzg9FEvxaLycB@postini.com;
	Tue, 11 Nov 2014 05:17:20 PST
Received: by mail-la0-f48.google.com with SMTP id gq15so9398292lab.21
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id;
	bh=cioK/u/9Quu+QdGwX4P0Cg6IZ5xOM1EKcuzy8zBNUW8=;
	b=JOhwKWOHVOOlSiBES8T844ZBgVlN75icXS2VPrFHZhArISVHksq1kLbG6hOC9qlGqj
	03vNmzv800XwzFGo02csoXLpLJGwFAsFag8poo4F2npT2ScIa4gB5tUtXU8Bc4JpuYhu
	Apjc6PSkO8DvLOYNeH4R4vnCZSexxKVC2ckfE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=cioK/u/9Quu+QdGwX4P0Cg6IZ5xOM1EKcuzy8zBNUW8=;
	b=NqLiVoWI8U+w7oIMEfax1JyhAg/T8nZHPmKTGaeWMbpPJOjA6gHXzkAHYd2LcG5C1C
	pFPEg3Q5EvX45q5/HTUP8UI0HGpgXahnnOxGU/CYAuZWdlt3OXLJGQB6Ed36CJdMTaVx
	NHhjPPD9SZdbaDW+OcHdhN6ScpLlEmSJiqMnQnZiexks8KyjFaZ9hmiWnDHkIaN6LyuQ
	cCNXKd/TorinIjjhwp2K7rSo7r5gtOj8hIpd4GzWjy+7DR+5VP0Q5YJBjcuxf2heQoMb
	TUU1Bs0PM1NjzeL+5IHggl+cIFGGyyYIeG+8s6vczXwePOGOr8Hp1CagSzEQw5Q930op
	aSHw==
X-Gm-Message-State: ALoCoQkHbweOTomKHD6OA6kzb3LloqVAHUmjJZNnaA+PmzCxGu1eEAx71uzTnOYRa3Jtk4hDx6sRPdmKLjjlloAwJqD4rGYayPocsDg2pM4hCJqW3unWJzyF4CxpyUmi8TRPYpyyKwPIgBlfdqt5unYUY+iZAHyX5g==
X-Received: by 10.152.28.6 with SMTP id x6mr1309391lag.12.1415711837427;
	Tue, 11 Nov 2014 05:17:17 -0800 (PST)
X-Received: by 10.152.28.6 with SMTP id x6mr1309379lag.12.1415711837300;
	Tue, 11 Nov 2014 05:17:17 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id z5sm5968671lae.21.2014.11.11.05.17.15
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:16 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:02 +0200
Message-Id: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 00/12] xen_cpufreq implementation in Xen
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi to all.

Next series of patches implements xen-cpufreq driver in Xen hypervisor.

Cpufreq core and registered cpufreq governors are located in xen. Hwdom has CPU
driver which can only change frequency of the physical CPUs. In addition this
driver can change CPUs regulator voltage. At start time xen-cpufreq driver
in hwdom reads an information about physical CPUs number and uploads to Xen
information about those physical cpus. Then hwdon uses XEN_SYSCTL_cpufreq_op
operation to start events from hwdom-cpufreq ddriver in Xen.
Changing frequency workflow:
 * hwdom-cpufreq driver in Xen wants to change the
   frequency of the physical CPU
 * hwdom-cpufreq in Xen sets parameters in the shared
   memory
 * hwdom-cpufreq driver in Xen sends an event via event channel
   to notify the xen-cpufreq driver in hwdom
 * xen-cpufreq driver in hwdom reads parameters from the shared
   memory, changes frequency and copies the result of
   the operation to the shared memory
 * xen-cpufreq driver in hwdom sends an event via event channel
   to notify the cpufreq driver in Xen


Changed since v1:
 * use /xen/include/xen/ instead of the  /xen/include/cpufreq/
   for included files
 * move pmstat.c file to the xen/drivers/pm/stat.c instead of the
   xen/drivers/pm/pmstat.c
 * updated ./MAINTAINERS accordingly to new files location
 * introduce HAS_CPU_TURBO config and use it
 * move ACPI-specific pmstat functions under the CONFIG_ACPI config
   instead of the CONFIG_X86 config
 * correct info message in cpufreq_add_cpu() function (remove _PSD
   prefix for NON ACPI configuration)
 * dropped patch "[RFC PATCH 07/13] xen/arm: enable cpu hotplug"
 * dropped patch "[RFC PATCH 08/13] xen/dts: make the dt_find_property
   function to be global"
 * create PCPUs device tree node in /hypervisor/pcpus node instead
   of the /cpus/cpu@0/private_date/ node
 * reworked platform hypercall implementation (used XSM check
   for ARM architecture) and moved common code to the common
   place.
 * xen-cpufreq driver to the dom0-cpufreq

Changed since v2:
 * corrected comment in xen/drivers/pm/stat.c
 * restored blank line in xen/drivers/pm/stat.c
 * corrected #ifdef in xen/drivers/cpufreq/cpufreq.c
 * removed common file for platform_hypercall implementation
 * renamed dom0-cpufreq.c to hwdom-cpufreq.c
 * slightly reworked file hwdom-cpufreq.c
 * used VIRQ_CPUFREQ with number 14 instead of the 13
 
Changed since v3:
 * some fixes in creating device tree nodes for hwdom cpufreq cpu driver
 * some fixes in hwdom-cpufreq driver
 * removed XEN_SYSCTL_cpufreq_op implementation
 * added cpufreq shared info definition to send commands to the
   hwdom cpufreq driver

Changed since v4:
 * implemented an event channel between Xen and hwdom
 * restored XEN_SYSCTL_cpufreq_op definition (start/stop hwdom-cpufreq
   driver events)
 * added timer to the hwdom-cpufreq driver (sending command timeout)
 * slihgtly reworked hwdom-cpufreq driver
 * removed VIRQ_CPUFREQ

Oleksandr Dmytryshyn (12):
  cpufreq: move cpufreq.h file to the xen/include/xen location
  pm: move processor_perf.h file to the xen/include/xen location
  pmstat: move pmstat.c file to the xen/drivers/pm/stat.c location
  cpufreq: make turbo settings to be configurable
  pmstat: make pmstat functions more generalizable
  cpufreq: make cpufreq driver more generalizable
  arch/arm: create device tree nodes for hwdom cpufreq cpu driver
  xen: arm: implement platform hypercall
  xen: arm: add cpufreq shared info definition
  xen: arm: add XEN_SYSCTL_cpufreq_op definition
  cpufreq: add hwdom-cpufreq driver
  xen/arm: enable cpufreq functionality for ARM

 MAINTAINERS                                        |   3 +-
 xen/Rules.mk                                       |   4 +
 xen/arch/arm/Makefile                              |   1 +
 xen/arch/arm/Rules.mk                              |   3 +
 xen/arch/arm/domain_build.c                        |  78 +++-
 xen/arch/arm/platform_hypercall.c                  |  84 ++++
 xen/arch/arm/traps.c                               |   1 +
 xen/arch/x86/Rules.mk                              |   2 +
 xen/arch/x86/acpi/cpu_idle.c                       |   2 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c                |   2 +-
 xen/arch/x86/acpi/cpufreq/powernow.c               |   2 +-
 xen/arch/x86/acpi/power.c                          |   2 +-
 xen/arch/x86/cpu/mwait-idle.c                      |   2 +-
 xen/arch/x86/platform_hypercall.c                  |   2 +-
 xen/common/sysctl.c                                |  10 +-
 xen/drivers/Makefile                               |   1 +
 xen/drivers/acpi/Makefile                          |   1 -
 xen/drivers/cpufreq/Makefile                       |   1 +
 xen/drivers/cpufreq/cpufreq.c                      |  82 +++-
 xen/drivers/cpufreq/cpufreq_misc_governors.c       |   2 +-
 xen/drivers/cpufreq/cpufreq_ondemand.c             |   4 +-
 xen/drivers/cpufreq/hwdom-cpufreq.c                | 422 +++++++++++++++++++++
 xen/drivers/cpufreq/utility.c                      |  13 +-
 xen/drivers/pm/Makefile                            |   1 +
 xen/drivers/{acpi/pmstat.c => pm/stat.c}           |  16 +-
 xen/include/asm-arm/shared.h                       |  14 +
 xen/include/public/arch-arm.h                      |  12 +
 xen/include/public/platform.h                      |   1 +
 xen/include/public/sysctl.h                        |  11 +
 xen/include/{acpi/cpufreq => xen}/cpufreq.h        |  15 +-
 xen/include/{acpi/cpufreq => xen}/processor_perf.h |   7 +
 xen/include/xsm/dummy.h                            |  12 +-
 xen/include/xsm/xsm.h                              |  10 +-
 xen/xsm/flask/hooks.c                              |   3 +-
 34 files changed, 781 insertions(+), 45 deletions(-)
 create mode 100644 xen/arch/arm/platform_hypercall.c
 create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c
 create mode 100644 xen/drivers/pm/Makefile
 rename xen/drivers/{acpi/pmstat.c => pm/stat.c} (97%)
 create mode 100644 xen/include/asm-arm/shared.h
 rename xen/include/{acpi/cpufreq => xen}/cpufreq.h (96%)
 rename xen/include/{acpi/cpufreq => xen}/processor_perf.h (95%)

-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKE-00069N-GB; Tue, 11 Nov 2014 13:17:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKC-00068W-Qf
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1A/82-09842-07C02645; Tue, 11 Nov 2014 13:17:36 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415711853!3882624!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3196 invoked from network); 11 Nov 2014 13:17:35 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:35 -0000
Received: from mail-la0-f46.google.com ([209.85.215.46]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMbVO/vbr9eS9IHffqLgJv7KyAs/bd@postini.com;
	Tue, 11 Nov 2014 05:17:35 PST
Received: by mail-la0-f46.google.com with SMTP id gm9so9325130lab.5
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=JgXU4x7QJOvEpUbbuKilOBLEpUATJDI4xA7NawUjB3k=;
	b=fpzYWOnrzBRiAMVnMe9PO7tfIu2ppqU2XviyK2Fk8VLJF/HSJKYf0ECdj5VoB4/BLH
	MtYL1C4aISbRNak6Fn2GuTqPITRWBMsaC6RZZcinzAlZahOIK8V4wadgeYuDGKg9eQ/1
	8knD+yQ1s2IVIzfxQEQCrlnl6Uy0IP4tYhFUQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=JgXU4x7QJOvEpUbbuKilOBLEpUATJDI4xA7NawUjB3k=;
	b=CYMvy1Qv3cUajBlaKhZ98S0l4CGPWNmlvlrApSXZqPO2ZPU+73q86JJGdMYr9TIwCU
	+YjXC8biLnx5tNTx60cumFFGtMhWSUrpkZmVYY84Epbzf2Kk3LJMvjtfElJjHg55zRxK
	MmoS3Hk7oDpM2oxUvEV2p/VuP363/1BE7tn7SYIzW/uEeDDo9ZgolUpCzbx4OEPOUP5N
	wEo5wzgS55sVbvOwFxOAc+jZwx2ygHScKC/6xM9zM5njQu2ZhDXM2OqSxwAdP2d77wf+
	cshLrMdJEKVSxhCdURIIX4iRiBpYKMWaC0bsJ5WCYTxnjmQZvdRjHkn/0zzFjOeVhdEj
	p8SQ==
X-Gm-Message-State: ALoCoQnsl9TBFozM16yb5cGLar3eqyAMl71MiP92GPQEMentS0ksRsr2WvNx5PvBtfziQVtIFL6jJsAIn+fJIesVPfm2ZTHY4L+jv+2zi/3oazQQfJftbIbcqpx0eSWbvn7KvTWQ9GLW4FXr0d9vOX9dYwWDaoLj1A==
X-Received: by 10.112.235.135 with SMTP id um7mr333753lbc.96.1415711851966;
	Tue, 11 Nov 2014 05:17:31 -0800 (PST)
X-Received: by 10.112.235.135 with SMTP id um7mr333679lbc.96.1415711851002;
	Tue, 11 Nov 2014 05:17:31 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id gm5sm4026722lbc.30.2014.11.11.05.17.29
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:30 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:07 +0200
Message-Id: <1415711834-1740-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 05/12] pmstat: make pmstat functions more
	generalizable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ACPI-specific parts are moved under appropriate ifdefs.
Now pmstat functions can be used in ARM platform.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/drivers/pm/stat.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
index 3154051..1d13805 100644
--- a/xen/drivers/pm/stat.c
+++ b/xen/drivers/pm/stat.c
@@ -37,7 +37,6 @@
 #include <asm/processor.h>
 #include <xen/percpu.h>
 #include <xen/domain.h>
-#include <xen/acpi.h>
 
 #include <public/sysctl.h>
 #include <xen/cpufreq.h>
@@ -134,6 +133,8 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
         break;
     }
 
+/* For now those operations can be used only when ACPI is enabled */
+#ifdef CONFIG_ACPI
     case PMSTAT_get_max_cx:
     {
         op->u.getcx.nr = pmstat_get_cx_nr(op->cpuid);
@@ -152,6 +153,7 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
         ret = pmstat_reset_cx_stat(op->cpuid);
         break;
     }
+#endif /* CONFIG_ACPI */
 
     default:
         printk("not defined sub-hypercall @ do_get_pm_info\n");
@@ -467,6 +469,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         break;
     }
 
+#ifdef CONFIG_ACPI
     case XEN_SYSCTL_pm_op_get_max_cstate:
     {
         op->u.get_max_cstate = acpi_get_cstate_limit();
@@ -478,6 +481,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         acpi_set_cstate_limit(op->u.set_max_cstate);
         break;
     }
+#endif /* CONFIG_ACPI */
 
 #ifdef HAS_CPU_TURBO
     case XEN_SYSCTL_pm_op_enable_turbo:
@@ -502,6 +506,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
     return ret;
 }
 
+#ifdef CONFIG_ACPI
 int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 {
     u32 bits[3];
@@ -532,3 +537,4 @@ int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 
     return ret;
 }
+#endif /* CONFIG_ACPI */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKR-0006IF-OT; Tue, 11 Nov 2014 13:17:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKP-0006Gk-2I
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:49 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	EE/DC-09936-C7C02645; Tue, 11 Nov 2014 13:17:48 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415711865!11910694!1
X-Originating-IP: [64.18.0.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2362 invoked from network); 11 Nov 2014 13:17:47 -0000
Received: from exprod5og126.obsmtp.com (HELO exprod5og126.obsmtp.com)
	(64.18.0.251)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:47 -0000
Received: from mail-la0-f43.google.com ([209.85.215.43]) (using TLSv1) by
	exprod5ob126.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMebTrRp9hEMOnWTffdxeNcGh1LOeg@postini.com;
	Tue, 11 Nov 2014 05:17:47 PST
Received: by mail-la0-f43.google.com with SMTP id ge10so9529671lab.2
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=AGqWxqz/IXczJz1Mn8/51FDJd7tjV4OUCkaydNfGSnI=;
	b=A/OLz3YEujKUJi3NFn6jP9/bVvDZ0IVHG92NQrxSRTxxjfCqFeFUJ99/FZF4JiAqyY
	e1O7F/LMQkaeIBFa60dxEWoZDY27Zt+MTU2WbqOYb6tzqEOFE1fvXeP3o3DquqzTal9p
	r7BptIoKCbp65WVkaUz4hPEx8Ymx5T3B7UvHg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=AGqWxqz/IXczJz1Mn8/51FDJd7tjV4OUCkaydNfGSnI=;
	b=RG/AoOKkHKTgy7DApwYPAq9YjLH7zLLaXYdnTbAg0kwM+n752ZGxlI9ppn/GhFibcI
	+fJK1jQSTTE7gmS3LPL7kAzQG/dHkXFBmfbVWn1gG9jgpJ7z51OK8FB3lNZwPb3Q/Mrg
	xVUSBJVc4L1ngUyHLIqkQKn2gdu9v0HLhLrTB8kpz5YhJ9s+nsvXO+uxIyfiQeQW4BUn
	wlSnv+ySjoX1Ya2DETTsK4uV358TdH8LaowJGdhaxCfeAJPdeyEwG2buO3wRNwRdTGUw
	H7Q3eGlfMhMH+iNx7sxIrgqV34/fiQ3aYB/aN0XSarHxWSDpHMhVqaqnNSl1+CZuzz0d
	7WJw==
X-Gm-Message-State: ALoCoQlj9HgFWjAMkJF7ljZOjnM1FCGz4mYjxOTAMtvadNMEFkU2+93EbH4p0Us60uW+5d5L/d7Xh6SYuDsxhMEw9E0/3TnXFZnjlHOjw7h3201Wp35ISBZOyFtIkUuclk30UpQ+o7Ir/GHjMK/XYL7G9iLEqIfYfQ==
X-Received: by 10.152.88.8 with SMTP id bc8mr1706228lab.64.1415711863971;
	Tue, 11 Nov 2014 05:17:43 -0800 (PST)
X-Received: by 10.152.88.8 with SMTP id bc8mr1706219lab.64.1415711863917;
	Tue, 11 Nov 2014 05:17:43 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id j2sm5980688lbp.16.2014.11.11.05.17.42
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:43 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:12 +0200
Message-Id: <1415711834-1740-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 10/12] xen: arm: add
	XEN_SYSCTL_cpufreq_op definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Kernel uses this op to start/stop cpufreq notification
events sending.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/include/public/sysctl.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 8437d31..35188d7 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -632,6 +632,15 @@ struct xen_sysctl_coverage_op {
 typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
 
+#define XEN_SYSCTL_CPUFREQ_event_start     0
+#define XEN_SYSCTL_CPUFREQ_event_stop      1
+
+struct xen_sysctl_cpufreq_op {
+    uint32_t cmd;         /* XEN_SYSCTL_CPUFREQ_* */
+    uint32_t port;        /* OUT: event channel for notifications */
+};
+typedef struct xen_sysctl_cpufreq_op xen_sysctl_cpufreq_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpufreq_op_t);
 
 struct xen_sysctl {
     uint32_t cmd;
@@ -654,6 +663,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
 #define XEN_SYSCTL_coverage_op                   20
+#define XEN_SYSCTL_cpufreq_op                    21
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -675,6 +685,7 @@ struct xen_sysctl {
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
         struct xen_sysctl_coverage_op       coverage_op;
+        struct xen_sysctl_cpufreq_op        cpufreq_op;
         uint8_t                             pad[128];
     } u;
 };
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKB-00068H-TI; Tue, 11 Nov 2014 13:17:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKA-000682-Bw
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:34 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	97/96-26652-D6C02645; Tue, 11 Nov 2014 13:17:33 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415711850!11769541!1
X-Originating-IP: [64.18.0.198]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23101 invoked from network); 11 Nov 2014 13:17:32 -0000
Received: from exprod5og123.obsmtp.com (HELO exprod5og123.obsmtp.com)
	(64.18.0.198)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:32 -0000
Received: from mail-lb0-f178.google.com ([209.85.217.178]) (using TLSv1) by
	exprod5ob123.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMaU8JD6imb+PycSRFXRdDL6rUCXIc@postini.com;
	Tue, 11 Nov 2014 05:17:32 PST
Received: by mail-lb0-f178.google.com with SMTP id f15so8369911lbj.37
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=713bit2g0RhvBKeHzo9XWlypOoemnEZ6Rrwf4CVZRDY=;
	b=MmIDGYE7B+9AR8smiQYOQicHRDmeku2pD3smxkRSDTHIRUxwHuzDWSV9Le0yT8vnue
	LvRILHvRAFPNmFIovw64PeJ0IZckPD1c8+OHhAaahsWdqv/CIDy14acKdCTCy1e2FoaK
	SQ59Q4LBFtvEOnfWnYhAlLO/H/JPFsjK5ntpg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=713bit2g0RhvBKeHzo9XWlypOoemnEZ6Rrwf4CVZRDY=;
	b=dcWUU+8HBXmlxjB/Tfb7E7BjbScs0a9nFyvSmhn66sX9A/8p8p6RoWfUDgx2JyG4WP
	XCyEf+ctc5AUEz1wbOJrmlo5+kxz3ph3QLhQqMExp7C/pJ1SDRckosW6VcOioWULE3Cu
	5KgtO2q7lhj9SRr+1X7IJFldErk454HqRd+d2cXOYgfJqfofTe/Isp+nlovmUgwFQW9B
	kAyETrQrj9vLjFeSIOYPgq9WivDEV0U/5Ek0DOin88FiPrwkHSWod/T7k4SjIOJNwsVH
	jBcmxnwnrVIdvDkJ1C2wsYrmVb5pdGufMyf/O/68aE9pZ4JqodPbicxLj6fRACTUbjjP
	t0YA==
X-Gm-Message-State: ALoCoQkv6KGs2AWk9vTlR2LkFIiFeNDEskKxaEZA2Q0CJwU8yrQMVRBeMKXSyOUmwsP6egJ/0RNPu6nj91egsFewDlGc1qI7Ae2cOHlRekyi/MVWfiewXLTUWFJALhpXeI6fUVFnm2mJcvRsvr5u0AlJgzhSgcpHHw==
X-Received: by 10.112.136.164 with SMTP id qb4mr36426821lbb.62.1415711848397; 
	Tue, 11 Nov 2014 05:17:28 -0800 (PST)
X-Received: by 10.112.136.164 with SMTP id qb4mr36426811lbb.62.1415711848329; 
	Tue, 11 Nov 2014 05:17:28 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id pm3sm5980759lbb.15.2014.11.11.05.17.26
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:27 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:06 +0200
Message-Id: <1415711834-1740-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 04/12] cpufreq: make turbo settings to be
	configurable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This settings is not needed for some architectures.
So make it to be configurable and use it for x86
architecture.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                  |  1 +
 xen/arch/x86/Rules.mk         |  1 +
 xen/drivers/cpufreq/utility.c | 11 ++++++++++-
 xen/drivers/pm/stat.c         |  6 ++++++
 xen/include/xen/cpufreq.h     |  6 ++++++
 5 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index b7caab6..5953152 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_PM)        += -DHAS_PM
+CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 9e9fbf1..cfe4f90 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -4,6 +4,7 @@
 HAS_IOPORTS := y
 HAS_ACPI := y
 HAS_PM := y
+HAS_CPU_TURBO := y
 HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 3cb0b3e..e92cf17 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -209,7 +209,9 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
 {
     unsigned int min_freq = ~0;
     unsigned int max_freq = 0;
+#ifdef HAS_CPU_TURBO
     unsigned int second_max_freq = 0;
+#endif
     unsigned int i;
 
     for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
@@ -221,6 +223,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
         if (freq > max_freq)
             max_freq = freq;
     }
+#ifdef HAS_CPU_TURBO
     for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
         unsigned int freq = table[i].frequency;
         if (freq == CPUFREQ_ENTRY_INVALID || freq == max_freq)
@@ -234,9 +237,13 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
         printk("max_freq: %u    second_max_freq: %u\n",
                max_freq, second_max_freq);
 
+    policy->cpuinfo.second_max_freq = second_max_freq;
+#else
+    if (cpufreq_verbose)
+        printk("max_freq: %u\n", max_freq);
+#endif
     policy->min = policy->cpuinfo.min_freq = min_freq;
     policy->max = policy->cpuinfo.max_freq = max_freq;
-    policy->cpuinfo.second_max_freq = second_max_freq;
 
     if (policy->min == ~0)
         return -EINVAL;
@@ -390,6 +397,7 @@ int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag)
     return policy->cur;
 }
 
+#ifdef HAS_CPU_TURBO
 int cpufreq_update_turbo(int cpuid, int new_state)
 {
     struct cpufreq_policy *policy;
@@ -430,6 +438,7 @@ int cpufreq_get_turbo_status(int cpuid)
     policy = per_cpu(cpufreq_cpu_policy, cpuid);
     return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
 }
+#endif /* HAS_CPU_TURBO */
 
 /*********************************************************************
  *                 POLICY                                            *
diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
index 3486148..3154051 100644
--- a/xen/drivers/pm/stat.c
+++ b/xen/drivers/pm/stat.c
@@ -292,7 +292,11 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
             &op->u.get_para.u.ondemand.sampling_rate,
             &op->u.get_para.u.ondemand.up_threshold);
     }
+#ifdef HAS_CPU_TURBO
     op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid);
+#else
+    op->u.get_para.turbo_enabled = 0;
+#endif
 
     return ret;
 }
@@ -475,6 +479,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         break;
     }
 
+#ifdef HAS_CPU_TURBO
     case XEN_SYSCTL_pm_op_enable_turbo:
     {
         ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
@@ -486,6 +491,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
         break;
     }
+#endif /* HAS_CPU_TURBO */
 
     default:
         printk("not defined sub-hypercall @ do_pm_op\n");
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index 82dc4dc..d7b6c34 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -39,7 +39,9 @@ extern struct acpi_cpufreq_data *cpufreq_drv_data[NR_CPUS];
 
 struct cpufreq_cpuinfo {
     unsigned int        max_freq;
+#ifdef HAS_CPU_TURBO
     unsigned int        second_max_freq;    /* P1 if Turbo Mode is on */
+#endif
     unsigned int        min_freq;
     unsigned int        transition_latency; /* in 10^(-9) s = nanoseconds */
 };
@@ -59,10 +61,12 @@ struct cpufreq_policy {
 
     bool_t              resume; /* flag for cpufreq 1st run
                                  * S3 wakeup, hotplug cpu, etc */
+#ifdef HAS_CPU_TURBO
     s8                  turbo;  /* tristate flag: 0 for unsupported
                                  * -1 for disable, 1 for enabled
                                  * See CPUFREQ_TURBO_* below for defines */
     bool_t              aperf_mperf; /* CPU has APERF/MPERF MSRs */
+#endif
 };
 DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy);
 
@@ -127,8 +131,10 @@ extern int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag);
 #define CPUFREQ_TURBO_UNSUPPORTED   0
 #define CPUFREQ_TURBO_ENABLED       1
 
+#ifdef HAS_CPU_TURBO
 extern int cpufreq_update_turbo(int cpuid, int new_state);
 extern int cpufreq_get_turbo_status(int cpuid);
+#endif
 
 static __inline__ int 
 __cpufreq_governor(struct cpufreq_policy *policy, unsigned int event)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKR-0006IF-OT; Tue, 11 Nov 2014 13:17:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKP-0006Gk-2I
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:49 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	EE/DC-09936-C7C02645; Tue, 11 Nov 2014 13:17:48 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415711865!11910694!1
X-Originating-IP: [64.18.0.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2362 invoked from network); 11 Nov 2014 13:17:47 -0000
Received: from exprod5og126.obsmtp.com (HELO exprod5og126.obsmtp.com)
	(64.18.0.251)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:47 -0000
Received: from mail-la0-f43.google.com ([209.85.215.43]) (using TLSv1) by
	exprod5ob126.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMebTrRp9hEMOnWTffdxeNcGh1LOeg@postini.com;
	Tue, 11 Nov 2014 05:17:47 PST
Received: by mail-la0-f43.google.com with SMTP id ge10so9529671lab.2
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=AGqWxqz/IXczJz1Mn8/51FDJd7tjV4OUCkaydNfGSnI=;
	b=A/OLz3YEujKUJi3NFn6jP9/bVvDZ0IVHG92NQrxSRTxxjfCqFeFUJ99/FZF4JiAqyY
	e1O7F/LMQkaeIBFa60dxEWoZDY27Zt+MTU2WbqOYb6tzqEOFE1fvXeP3o3DquqzTal9p
	r7BptIoKCbp65WVkaUz4hPEx8Ymx5T3B7UvHg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=AGqWxqz/IXczJz1Mn8/51FDJd7tjV4OUCkaydNfGSnI=;
	b=RG/AoOKkHKTgy7DApwYPAq9YjLH7zLLaXYdnTbAg0kwM+n752ZGxlI9ppn/GhFibcI
	+fJK1jQSTTE7gmS3LPL7kAzQG/dHkXFBmfbVWn1gG9jgpJ7z51OK8FB3lNZwPb3Q/Mrg
	xVUSBJVc4L1ngUyHLIqkQKn2gdu9v0HLhLrTB8kpz5YhJ9s+nsvXO+uxIyfiQeQW4BUn
	wlSnv+ySjoX1Ya2DETTsK4uV358TdH8LaowJGdhaxCfeAJPdeyEwG2buO3wRNwRdTGUw
	H7Q3eGlfMhMH+iNx7sxIrgqV34/fiQ3aYB/aN0XSarHxWSDpHMhVqaqnNSl1+CZuzz0d
	7WJw==
X-Gm-Message-State: ALoCoQlj9HgFWjAMkJF7ljZOjnM1FCGz4mYjxOTAMtvadNMEFkU2+93EbH4p0Us60uW+5d5L/d7Xh6SYuDsxhMEw9E0/3TnXFZnjlHOjw7h3201Wp35ISBZOyFtIkUuclk30UpQ+o7Ir/GHjMK/XYL7G9iLEqIfYfQ==
X-Received: by 10.152.88.8 with SMTP id bc8mr1706228lab.64.1415711863971;
	Tue, 11 Nov 2014 05:17:43 -0800 (PST)
X-Received: by 10.152.88.8 with SMTP id bc8mr1706219lab.64.1415711863917;
	Tue, 11 Nov 2014 05:17:43 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id j2sm5980688lbp.16.2014.11.11.05.17.42
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:43 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:12 +0200
Message-Id: <1415711834-1740-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 10/12] xen: arm: add
	XEN_SYSCTL_cpufreq_op definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Kernel uses this op to start/stop cpufreq notification
events sending.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/include/public/sysctl.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 8437d31..35188d7 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -632,6 +632,15 @@ struct xen_sysctl_coverage_op {
 typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
 
+#define XEN_SYSCTL_CPUFREQ_event_start     0
+#define XEN_SYSCTL_CPUFREQ_event_stop      1
+
+struct xen_sysctl_cpufreq_op {
+    uint32_t cmd;         /* XEN_SYSCTL_CPUFREQ_* */
+    uint32_t port;        /* OUT: event channel for notifications */
+};
+typedef struct xen_sysctl_cpufreq_op xen_sysctl_cpufreq_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpufreq_op_t);
 
 struct xen_sysctl {
     uint32_t cmd;
@@ -654,6 +663,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
 #define XEN_SYSCTL_coverage_op                   20
+#define XEN_SYSCTL_cpufreq_op                    21
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -675,6 +685,7 @@ struct xen_sysctl {
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
         struct xen_sysctl_coverage_op       coverage_op;
+        struct xen_sysctl_cpufreq_op        cpufreq_op;
         uint8_t                             pad[128];
     } u;
 };
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKV-0006Ms-59; Tue, 11 Nov 2014 13:17:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKS-0006IV-C8
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8B/63-24532-F7C02645; Tue, 11 Nov 2014 13:17:51 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415711868!11923772!1
X-Originating-IP: [64.18.0.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4811 invoked from network); 11 Nov 2014 13:17:50 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:50 -0000
Received: from mail-la0-f51.google.com ([209.85.215.51]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMe7mvB0kOkhiecx8PKB65Vm+Av5U1@postini.com;
	Tue, 11 Nov 2014 05:17:49 PST
Received: by mail-la0-f51.google.com with SMTP id q1so9553232lam.38
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=4X7atMnN2ReQb+MysCcU8mvgQizAecowd1NcbQJT8BY=;
	b=iYepA5tTaKLVG3Xru8U4hKr2XkoITkvpjgP0Ol1XhHuRlOZFFyKZWTqtP87jwZ8I5t
	sWUoMa9mAlLWHACvIch6v13U+X6GKP9NFfm7JKaYdkdEFgOy37Y0X8xyr0Fr/Sz/aNnL
	M1rBR3+w7Dt2dt0yhvPr2OiRD1QpyszbZXD4c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=4X7atMnN2ReQb+MysCcU8mvgQizAecowd1NcbQJT8BY=;
	b=MVogxraRXOQksjT81Z5FFZbFG33NEgjkml+5rI4yOxNdo/UPAKln+zshTvHJjrW5WT
	wVYXmLDmeYCL6ha3FP2rgPKRvOumoupXnNlGbl+6r/QxuIXNCYpoqqqW91SmsuVCrvaI
	uYaJNXFVx0pk3hHru7XoVOYsLad/DQhy8YDUpQk1FshnJqtOGymhzpWN0sbOsPzlp+c8
	1NKB4yht3Q4uv+8ij8JprFUN32FnnMiGgufoIqf4pTA+bZ9NoHy1jLopIvLv6jK1AKei
	LRCKmPCgxWipix3op4BooXc8Rzq2MVuYRzkL0qUScgp8EX+NhZssTA9n53iaICTaY+up
	f7SA==
X-Gm-Message-State: ALoCoQlH+Min7xIGr1qPgC6TI38YkR9bZm1JvrLHg4FBn8Vd7/ZR6n+APvFkNKqIvGlDN2rG2FAbhElgJ3Ey9qVBFiohlPi1b4rWdODHmgtMX200WOKixcs2bYoP3hKHqB30K+rWTXTEXe0fwrDmM/q82jIuBOOi3Q==
X-Received: by 10.152.5.6 with SMTP id o6mr15163640lao.8.1415711866320;
	Tue, 11 Nov 2014 05:17:46 -0800 (PST)
X-Received: by 10.152.5.6 with SMTP id o6mr15163634lao.8.1415711866237;
	Tue, 11 Nov 2014 05:17:46 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id wp1sm1137879lbb.40.2014.11.11.05.17.44
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:45 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:13 +0200
Message-Id: <1415711834-1740-12-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 11/12] cpufreq: add hwdom-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This driver uses hwdom to change frequencies on physical
CPUs.
Workflow:
 * cpufreq governor driver in Xen wants to change the
   frequency of the physical CPU
 * hwdom-cpufreq driver sets parameters in the shared
   memory
 * hwdom-cpufreq driver sends an event via event channel
   to notify the hardware domain
 * cpufreq driver in the hardware domain reads parameters
   from the shared memory, changes frequency and copies
   the result of the operation to the shared memory
 * cpufreq driver in the hwdom sends an event via event
   channel to notify the hwdom-cpufreq driver

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                        |   1 +
 xen/common/sysctl.c                 |   8 +
 xen/drivers/cpufreq/Makefile        |   1 +
 xen/drivers/cpufreq/hwdom-cpufreq.c | 422 ++++++++++++++++++++++++++++++++++++
 xen/include/xen/cpufreq.h           |   2 +
 5 files changed, 434 insertions(+)
 create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3b0b89b..cccbc72 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
+CFLAGS-$(HAS_HWDOM_CPUFREQ) += -DHAS_HWDOM_CPUFREQ
 CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0dcf06a..fd0cd0d 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -27,6 +27,7 @@
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
 #include <xen/gcov.h>
+#include <xen/cpufreq.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -362,6 +363,13 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         break;
 #endif
 
+#ifdef HAS_HWDOM_CPUFREQ
+    case XEN_SYSCTL_cpufreq_op:
+        ret = sysctl_cpufreq_op(&op->u.cpufreq_op);
+        copyback = 1;
+        break;
+#endif
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/drivers/cpufreq/Makefile b/xen/drivers/cpufreq/Makefile
index b87d127..891997c 100644
--- a/xen/drivers/cpufreq/Makefile
+++ b/xen/drivers/cpufreq/Makefile
@@ -2,3 +2,4 @@ obj-y += cpufreq.o
 obj-y += cpufreq_ondemand.o
 obj-y += cpufreq_misc_governors.o
 obj-y += utility.o
+obj-$(HAS_HWDOM_CPUFREQ) += hwdom-cpufreq.o
diff --git a/xen/drivers/cpufreq/hwdom-cpufreq.c b/xen/drivers/cpufreq/hwdom-cpufreq.c
new file mode 100644
index 0000000..3932dca
--- /dev/null
+++ b/xen/drivers/cpufreq/hwdom-cpufreq.c
@@ -0,0 +1,422 @@
+/*
+ *  Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
+ *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
+ *  Copyright (C) 2002 - 2004 Dominik Brodowski <linux@brodo.de>
+ *  Copyright (C) 2006        Denis Sadykov <denis.m.sadykov@intel.com>
+ *
+ *  Feb 2008 - Liu Jinsong <jinsong.liu@intel.com>
+ *      porting acpi-cpufreq.c from Linux 2.6.23 to Xen hypervisor
+ *
+ *  Copyright (C) 2014 GlobalLogic Inc.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <xen/types.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/event.h>
+#include <xen/irq.h>
+#include <xen/spinlock.h>
+#include <xen/cpufreq.h>
+#include <xen/err.h>
+#include <xen/timer.h>
+#include <asm/shared.h>
+#include <asm/current.h>
+#include <asm/system.h>
+
+#define WAIT_HWDOM_ANSWER_TOUT          (2000)  /* ms */
+
+struct hwdom_cpufreq_cpu_data {
+    struct processor_performance *perf_data;
+    struct cpufreq_frequency_table *freq_table;
+};
+
+struct hwdom_cpufreq {
+    struct hwdom_cpufreq_cpu_data *cpu_data[NR_CPUS];
+    struct domain *domain;
+    spinlock_t drv_lock;
+    spinlock_t hwdom_res_lock;
+    bool_t is_timer_active;
+    spinlock_t timer_lock;
+    struct timer timer;
+    uint32_t port;
+    int32_t hwdom_res;
+};
+
+static struct hwdom_cpufreq hwdom_cpufreq;
+
+int cpufreq_cpu_init(unsigned int cpuid)
+{
+    return cpufreq_add_cpu(cpuid);
+}
+
+/* Notify the hwdom (to do some command) */
+static void notify_cpufreq_domain(void)
+{
+    uint32_t port;
+    struct domain *domain;
+
+    spin_lock(&hwdom_cpufreq.drv_lock);
+    port = hwdom_cpufreq.port;
+    domain = hwdom_cpufreq.domain;
+    spin_unlock(&hwdom_cpufreq.drv_lock);
+
+    notify_via_xen_event_channel(domain, port);
+}
+
+static void cpufreq_hwdom_idle(void)
+{
+    struct cpufreq_sh_info *cpufreq_info;
+
+    stop_timer(&hwdom_cpufreq.timer);
+
+    spin_lock(&hwdom_cpufreq.timer_lock);
+    hwdom_cpufreq.is_timer_active = false;
+    spin_unlock(&hwdom_cpufreq.timer_lock);
+
+    cpufreq_info = arch_get_cpufreq_addr(dom0);
+
+    cpufreq_info->cmd = CPUFREQ_CMD_idle;
+
+    smp_wmb(); /* above must be visible before notify_cpufreq_domain() */
+
+    /* Notification is not needed in case CPUFREQ_CMD_idle */
+}
+
+static void cpufreq_hwdom_change_freq(uint32_t cpu, uint32_t freq,
+                                      uint32_t relation)
+{
+    struct cpufreq_sh_info *cpufreq_info;
+
+    spin_lock(&hwdom_cpufreq.timer_lock);
+    hwdom_cpufreq.is_timer_active = true;
+    spin_unlock(&hwdom_cpufreq.timer_lock);
+
+    set_timer(&hwdom_cpufreq.timer, NOW() + MILLISECS(WAIT_HWDOM_ANSWER_TOUT));
+
+    cpufreq_info = arch_get_cpufreq_addr(dom0);
+
+    cpufreq_info->cpu = cpu;
+    cpufreq_info->freq = freq;
+    cpufreq_info->relation = relation;
+    cpufreq_info->cmd = CPUFREQ_CMD_change_freq;
+
+    smp_wmb(); /* above must be visible before notify_cpufreq_domain() */
+
+    notify_cpufreq_domain();
+}
+
+static bool_t cpufreq_is_waiting_answer(void)
+{
+    bool_t ret;
+
+    spin_lock(&hwdom_cpufreq.timer_lock);
+    ret = hwdom_cpufreq.is_timer_active;
+    spin_unlock(&hwdom_cpufreq.timer_lock);
+
+    return ret;
+}
+
+static void cpufreq_set_hwdom_res(int32_t result)
+{
+    spin_lock(&hwdom_cpufreq.hwdom_res_lock);
+    hwdom_cpufreq.hwdom_res = result;
+    spin_unlock(&hwdom_cpufreq.hwdom_res_lock);
+}
+
+static int32_t cpufreq_get_hwdom_res(void)
+{
+    int32_t ret;
+
+    spin_lock(&hwdom_cpufreq.hwdom_res_lock);
+    ret = hwdom_cpufreq.hwdom_res;
+    spin_unlock(&hwdom_cpufreq.hwdom_res_lock);
+
+    return ret;
+}
+
+static void cpufreq_hwdom_answer_tout(void *data)
+{
+    cpufreq_hwdom_idle();
+    cpufreq_set_hwdom_res(-ETIME);
+}
+
+/* Notification from the hwdom (frequency changed) */
+static void cpufreq_notification(struct vcpu *v, unsigned int port)
+{
+    struct cpufreq_sh_info *cpufreq_info;
+
+    /* if we are not waiting answer just skip strange notifications */
+    if ( !cpufreq_is_waiting_answer() )
+        return;
+
+    cpufreq_hwdom_idle();
+
+    cpufreq_info = arch_get_cpufreq_addr(dom0);
+
+    /* Set previous result in the Hardware domain then read it */
+    smp_rmb();
+    cpufreq_set_hwdom_res(cpufreq_info->result);
+}
+
+int sysctl_cpufreq_op(xen_sysctl_cpufreq_op_t *op)
+{
+    int ret = 0;
+    uint32_t domain_id = current->domain->domain_id;
+    uint32_t port;
+    struct domain *d;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_CPUFREQ_event_start:
+    case XEN_SYSCTL_CPUFREQ_event_stop:
+        d = rcu_lock_domain_by_id(domain_id);
+        if ( d == NULL )
+            return -ESRCH;
+        break;
+
+    default:
+        return -EOPNOTSUPP;
+    }
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_CPUFREQ_event_start:
+        /* Allocate event channel */
+        ret = alloc_unbound_xen_event_channel(d->vcpu[0], domain_id,
+                                              cpufreq_notification);
+        if (ret < 0)
+            goto out;
+
+        op->port = ret;
+
+        spin_lock(&hwdom_cpufreq.drv_lock);
+        hwdom_cpufreq.port = ret;
+        hwdom_cpufreq.domain = d;
+        spin_unlock(&hwdom_cpufreq.drv_lock);
+
+        ret = 0;
+        break;
+
+    case XEN_SYSCTL_CPUFREQ_event_stop:
+        spin_lock(&hwdom_cpufreq.drv_lock);
+        port = hwdom_cpufreq.port;
+        hwdom_cpufreq.port = 0;
+        hwdom_cpufreq.domain = NULL;
+        spin_unlock(&hwdom_cpufreq.drv_lock);
+
+        /* Free hwdom's event channel and leave the other one unbound */
+        free_xen_event_channel(d->vcpu[0], port);
+        break;
+    }
+out:
+    rcu_unlock_domain(d);
+    return ret;
+}
+
+static int hwdom_cpufreq_verify(struct cpufreq_policy *policy)
+{
+    struct hwdom_cpufreq_cpu_data *data;
+    struct processor_performance *perf;
+
+    if ( !policy || !(data = hwdom_cpufreq.cpu_data[policy->cpu]) ||
+         !processor_pminfo[policy->cpu] )
+        return -EINVAL;
+
+    perf = &processor_pminfo[policy->cpu]->perf;
+
+    cpufreq_verify_within_limits(policy, 0,
+        perf->states[perf->platform_limit].core_frequency * 1000);
+
+    return cpufreq_frequency_table_verify(policy, data->freq_table);
+}
+
+static int hwdom_cpufreq_target(struct cpufreq_policy *policy,
+                               unsigned int target_freq, unsigned int relation)
+{
+    struct hwdom_cpufreq_cpu_data *data = hwdom_cpufreq.cpu_data[policy->cpu];
+    struct processor_performance *perf;
+    struct cpufreq_freqs freqs;
+    cpumask_t online_policy_cpus;
+    unsigned int next_state = 0; /* Index into freq_table */
+    unsigned int next_perf_state = 0; /* Index into perf table */
+    unsigned int j;
+    int ret = 0;
+
+    if ( unlikely(data == NULL ||
+         data->perf_data == NULL || data->freq_table == NULL) )
+        return -ENODEV;
+
+    perf = data->perf_data;
+    ret = cpufreq_frequency_table_target(policy,
+                                         data->freq_table,
+                                         target_freq,
+                                         relation, &next_state);
+    if ( unlikely(ret) )
+        return -ENODEV;
+
+    cpumask_and(&online_policy_cpus, &cpu_online_map, policy->cpus);
+
+    next_perf_state = data->freq_table[next_state].index;
+    if ( perf->state == next_perf_state )
+    {
+        if ( unlikely(policy->resume) )
+            policy->resume = 0;
+        else
+            return 0;
+    }
+
+    freqs.old = perf->states[perf->state].core_frequency * 1000;
+    freqs.new = data->freq_table[next_state].frequency;
+
+    if ( cpufreq_is_waiting_answer() )
+        return -EAGAIN;
+
+     /* return previous result */
+    ret = cpufreq_get_hwdom_res();
+
+     /* Do send cmd for Hardware domain */
+    cpufreq_hwdom_change_freq(policy->cpu, freqs.new, (uint32_t)relation);
+
+    for_each_cpu( j, &online_policy_cpus )
+        cpufreq_statistic_update(j, perf->state, next_perf_state);
+
+    perf->state = next_perf_state;
+    policy->cur = freqs.new;
+
+    return ret;
+}
+
+static int hwdom_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+    struct processor_performance *perf;
+    struct hwdom_cpufreq_cpu_data *data;
+    unsigned int cpu = policy->cpu;
+    unsigned int valid_states = 0;
+    int i;
+    int ret = 0;
+
+    data = xzalloc(struct hwdom_cpufreq_cpu_data);
+    if ( !data )
+        return -ENOMEM;
+
+    hwdom_cpufreq.cpu_data[cpu] = data;
+
+    data->perf_data = &processor_pminfo[cpu]->perf;
+
+    perf = data->perf_data;
+    policy->shared_type = perf->shared_type;
+
+    data->freq_table = xmalloc_array(struct cpufreq_frequency_table,
+                                     (perf->state_count+1));
+    if ( !data->freq_table )
+    {
+        ret = -ENOMEM;
+        goto err_unreg;
+    }
+
+    /* detect transition latency */
+    policy->cpuinfo.transition_latency = 0;
+    for ( i = 0; i < perf->state_count; i++ )
+    {
+        if ( (perf->states[i].transition_latency * 1000) >
+             policy->cpuinfo.transition_latency )
+            policy->cpuinfo.transition_latency =
+                perf->states[i].transition_latency * 1000;
+    }
+
+    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
+
+    /* table init */
+    for ( i = 0; i < perf->state_count; i++ )
+    {
+        if ( i > 0 && perf->states[i].core_frequency >=
+            data->freq_table[valid_states-1].frequency / 1000 )
+            continue;
+
+        data->freq_table[valid_states].index = i;
+        data->freq_table[valid_states].frequency =
+            perf->states[i].core_frequency * 1000;
+        valid_states++;
+    }
+    data->freq_table[valid_states].frequency = CPUFREQ_TABLE_END;
+    perf->state = 0;
+
+    ret = cpufreq_frequency_table_cpuinfo(policy, data->freq_table);
+    if ( ret )
+        goto err_freqfree;
+
+
+    /* We will set the minimal frequency now. So set policy->resume to 0 */
+    policy->resume = 0;
+
+    /* Set the minimal frequency */
+    return hwdom_cpufreq_target(policy, policy->min, CPUFREQ_RELATION_L);
+
+ err_freqfree:
+    xfree(data->freq_table);
+ err_unreg:
+    xfree(data);
+    hwdom_cpufreq.cpu_data[cpu] = NULL;
+
+    return ret;
+}
+
+static int hwdom_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+{
+    struct hwdom_cpufreq_cpu_data *data = hwdom_cpufreq.cpu_data[policy->cpu];
+
+    if ( data )
+    {
+        hwdom_cpufreq.cpu_data[policy->cpu] = NULL;
+        xfree(data->freq_table);
+        xfree(data);
+    }
+
+    return 0;
+}
+
+static struct cpufreq_driver hwdom_cpufreq_driver = {
+    .name   = "hwdom-cpufreq",
+    .verify = hwdom_cpufreq_verify,
+    .target = hwdom_cpufreq_target,
+    .init   = hwdom_cpufreq_cpu_init,
+    .exit   = hwdom_cpufreq_cpu_exit,
+};
+
+static int __init hwdom_cpufreq_driver_init(void)
+{
+    int ret = 0;
+
+    if ( cpufreq_controller != FREQCTL_xen )
+        return 0;
+
+    spin_lock_init(&hwdom_cpufreq.drv_lock);
+    spin_lock_init(&hwdom_cpufreq.hwdom_res_lock);
+
+    ret = cpufreq_register_driver(&hwdom_cpufreq_driver);
+    if ( ret )
+        return ret;
+
+    init_timer(&hwdom_cpufreq.timer, cpufreq_hwdom_answer_tout, NULL, 0);
+
+    return ret;
+}
+
+__initcall(hwdom_cpufreq_driver_init);
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index d7b6c34..0c8c19d 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -264,4 +264,6 @@ int write_userspace_scaling_setspeed(unsigned int cpu, unsigned int freq);
 void cpufreq_dbs_timer_suspend(void);
 void cpufreq_dbs_timer_resume(void);
 
+int sysctl_cpufreq_op(xen_sysctl_cpufreq_op_t *op);
+
 #endif /* __XEN_CPUFREQ_PM_H__ */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKV-0006Ms-59; Tue, 11 Nov 2014 13:17:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKS-0006IV-C8
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8B/63-24532-F7C02645; Tue, 11 Nov 2014 13:17:51 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415711868!11923772!1
X-Originating-IP: [64.18.0.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4811 invoked from network); 11 Nov 2014 13:17:50 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:50 -0000
Received: from mail-la0-f51.google.com ([209.85.215.51]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMe7mvB0kOkhiecx8PKB65Vm+Av5U1@postini.com;
	Tue, 11 Nov 2014 05:17:49 PST
Received: by mail-la0-f51.google.com with SMTP id q1so9553232lam.38
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=4X7atMnN2ReQb+MysCcU8mvgQizAecowd1NcbQJT8BY=;
	b=iYepA5tTaKLVG3Xru8U4hKr2XkoITkvpjgP0Ol1XhHuRlOZFFyKZWTqtP87jwZ8I5t
	sWUoMa9mAlLWHACvIch6v13U+X6GKP9NFfm7JKaYdkdEFgOy37Y0X8xyr0Fr/Sz/aNnL
	M1rBR3+w7Dt2dt0yhvPr2OiRD1QpyszbZXD4c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=4X7atMnN2ReQb+MysCcU8mvgQizAecowd1NcbQJT8BY=;
	b=MVogxraRXOQksjT81Z5FFZbFG33NEgjkml+5rI4yOxNdo/UPAKln+zshTvHJjrW5WT
	wVYXmLDmeYCL6ha3FP2rgPKRvOumoupXnNlGbl+6r/QxuIXNCYpoqqqW91SmsuVCrvaI
	uYaJNXFVx0pk3hHru7XoVOYsLad/DQhy8YDUpQk1FshnJqtOGymhzpWN0sbOsPzlp+c8
	1NKB4yht3Q4uv+8ij8JprFUN32FnnMiGgufoIqf4pTA+bZ9NoHy1jLopIvLv6jK1AKei
	LRCKmPCgxWipix3op4BooXc8Rzq2MVuYRzkL0qUScgp8EX+NhZssTA9n53iaICTaY+up
	f7SA==
X-Gm-Message-State: ALoCoQlH+Min7xIGr1qPgC6TI38YkR9bZm1JvrLHg4FBn8Vd7/ZR6n+APvFkNKqIvGlDN2rG2FAbhElgJ3Ey9qVBFiohlPi1b4rWdODHmgtMX200WOKixcs2bYoP3hKHqB30K+rWTXTEXe0fwrDmM/q82jIuBOOi3Q==
X-Received: by 10.152.5.6 with SMTP id o6mr15163640lao.8.1415711866320;
	Tue, 11 Nov 2014 05:17:46 -0800 (PST)
X-Received: by 10.152.5.6 with SMTP id o6mr15163634lao.8.1415711866237;
	Tue, 11 Nov 2014 05:17:46 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id wp1sm1137879lbb.40.2014.11.11.05.17.44
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:45 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:13 +0200
Message-Id: <1415711834-1740-12-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 11/12] cpufreq: add hwdom-cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This driver uses hwdom to change frequencies on physical
CPUs.
Workflow:
 * cpufreq governor driver in Xen wants to change the
   frequency of the physical CPU
 * hwdom-cpufreq driver sets parameters in the shared
   memory
 * hwdom-cpufreq driver sends an event via event channel
   to notify the hardware domain
 * cpufreq driver in the hardware domain reads parameters
   from the shared memory, changes frequency and copies
   the result of the operation to the shared memory
 * cpufreq driver in the hwdom sends an event via event
   channel to notify the hwdom-cpufreq driver

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/Rules.mk                        |   1 +
 xen/common/sysctl.c                 |   8 +
 xen/drivers/cpufreq/Makefile        |   1 +
 xen/drivers/cpufreq/hwdom-cpufreq.c | 422 ++++++++++++++++++++++++++++++++++++
 xen/include/xen/cpufreq.h           |   2 +
 5 files changed, 434 insertions(+)
 create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3b0b89b..cccbc72 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
+CFLAGS-$(HAS_HWDOM_CPUFREQ) += -DHAS_HWDOM_CPUFREQ
 CFLAGS-$(HAS_PM)        += -DHAS_PM
 CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0dcf06a..fd0cd0d 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -27,6 +27,7 @@
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
 #include <xen/gcov.h>
+#include <xen/cpufreq.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -362,6 +363,13 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         break;
 #endif
 
+#ifdef HAS_HWDOM_CPUFREQ
+    case XEN_SYSCTL_cpufreq_op:
+        ret = sysctl_cpufreq_op(&op->u.cpufreq_op);
+        copyback = 1;
+        break;
+#endif
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/drivers/cpufreq/Makefile b/xen/drivers/cpufreq/Makefile
index b87d127..891997c 100644
--- a/xen/drivers/cpufreq/Makefile
+++ b/xen/drivers/cpufreq/Makefile
@@ -2,3 +2,4 @@ obj-y += cpufreq.o
 obj-y += cpufreq_ondemand.o
 obj-y += cpufreq_misc_governors.o
 obj-y += utility.o
+obj-$(HAS_HWDOM_CPUFREQ) += hwdom-cpufreq.o
diff --git a/xen/drivers/cpufreq/hwdom-cpufreq.c b/xen/drivers/cpufreq/hwdom-cpufreq.c
new file mode 100644
index 0000000..3932dca
--- /dev/null
+++ b/xen/drivers/cpufreq/hwdom-cpufreq.c
@@ -0,0 +1,422 @@
+/*
+ *  Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
+ *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
+ *  Copyright (C) 2002 - 2004 Dominik Brodowski <linux@brodo.de>
+ *  Copyright (C) 2006        Denis Sadykov <denis.m.sadykov@intel.com>
+ *
+ *  Feb 2008 - Liu Jinsong <jinsong.liu@intel.com>
+ *      porting acpi-cpufreq.c from Linux 2.6.23 to Xen hypervisor
+ *
+ *  Copyright (C) 2014 GlobalLogic Inc.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <xen/types.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/event.h>
+#include <xen/irq.h>
+#include <xen/spinlock.h>
+#include <xen/cpufreq.h>
+#include <xen/err.h>
+#include <xen/timer.h>
+#include <asm/shared.h>
+#include <asm/current.h>
+#include <asm/system.h>
+
+#define WAIT_HWDOM_ANSWER_TOUT          (2000)  /* ms */
+
+struct hwdom_cpufreq_cpu_data {
+    struct processor_performance *perf_data;
+    struct cpufreq_frequency_table *freq_table;
+};
+
+struct hwdom_cpufreq {
+    struct hwdom_cpufreq_cpu_data *cpu_data[NR_CPUS];
+    struct domain *domain;
+    spinlock_t drv_lock;
+    spinlock_t hwdom_res_lock;
+    bool_t is_timer_active;
+    spinlock_t timer_lock;
+    struct timer timer;
+    uint32_t port;
+    int32_t hwdom_res;
+};
+
+static struct hwdom_cpufreq hwdom_cpufreq;
+
+int cpufreq_cpu_init(unsigned int cpuid)
+{
+    return cpufreq_add_cpu(cpuid);
+}
+
+/* Notify the hwdom (to do some command) */
+static void notify_cpufreq_domain(void)
+{
+    uint32_t port;
+    struct domain *domain;
+
+    spin_lock(&hwdom_cpufreq.drv_lock);
+    port = hwdom_cpufreq.port;
+    domain = hwdom_cpufreq.domain;
+    spin_unlock(&hwdom_cpufreq.drv_lock);
+
+    notify_via_xen_event_channel(domain, port);
+}
+
+static void cpufreq_hwdom_idle(void)
+{
+    struct cpufreq_sh_info *cpufreq_info;
+
+    stop_timer(&hwdom_cpufreq.timer);
+
+    spin_lock(&hwdom_cpufreq.timer_lock);
+    hwdom_cpufreq.is_timer_active = false;
+    spin_unlock(&hwdom_cpufreq.timer_lock);
+
+    cpufreq_info = arch_get_cpufreq_addr(dom0);
+
+    cpufreq_info->cmd = CPUFREQ_CMD_idle;
+
+    smp_wmb(); /* above must be visible before notify_cpufreq_domain() */
+
+    /* Notification is not needed in case CPUFREQ_CMD_idle */
+}
+
+static void cpufreq_hwdom_change_freq(uint32_t cpu, uint32_t freq,
+                                      uint32_t relation)
+{
+    struct cpufreq_sh_info *cpufreq_info;
+
+    spin_lock(&hwdom_cpufreq.timer_lock);
+    hwdom_cpufreq.is_timer_active = true;
+    spin_unlock(&hwdom_cpufreq.timer_lock);
+
+    set_timer(&hwdom_cpufreq.timer, NOW() + MILLISECS(WAIT_HWDOM_ANSWER_TOUT));
+
+    cpufreq_info = arch_get_cpufreq_addr(dom0);
+
+    cpufreq_info->cpu = cpu;
+    cpufreq_info->freq = freq;
+    cpufreq_info->relation = relation;
+    cpufreq_info->cmd = CPUFREQ_CMD_change_freq;
+
+    smp_wmb(); /* above must be visible before notify_cpufreq_domain() */
+
+    notify_cpufreq_domain();
+}
+
+static bool_t cpufreq_is_waiting_answer(void)
+{
+    bool_t ret;
+
+    spin_lock(&hwdom_cpufreq.timer_lock);
+    ret = hwdom_cpufreq.is_timer_active;
+    spin_unlock(&hwdom_cpufreq.timer_lock);
+
+    return ret;
+}
+
+static void cpufreq_set_hwdom_res(int32_t result)
+{
+    spin_lock(&hwdom_cpufreq.hwdom_res_lock);
+    hwdom_cpufreq.hwdom_res = result;
+    spin_unlock(&hwdom_cpufreq.hwdom_res_lock);
+}
+
+static int32_t cpufreq_get_hwdom_res(void)
+{
+    int32_t ret;
+
+    spin_lock(&hwdom_cpufreq.hwdom_res_lock);
+    ret = hwdom_cpufreq.hwdom_res;
+    spin_unlock(&hwdom_cpufreq.hwdom_res_lock);
+
+    return ret;
+}
+
+static void cpufreq_hwdom_answer_tout(void *data)
+{
+    cpufreq_hwdom_idle();
+    cpufreq_set_hwdom_res(-ETIME);
+}
+
+/* Notification from the hwdom (frequency changed) */
+static void cpufreq_notification(struct vcpu *v, unsigned int port)
+{
+    struct cpufreq_sh_info *cpufreq_info;
+
+    /* if we are not waiting answer just skip strange notifications */
+    if ( !cpufreq_is_waiting_answer() )
+        return;
+
+    cpufreq_hwdom_idle();
+
+    cpufreq_info = arch_get_cpufreq_addr(dom0);
+
+    /* Set previous result in the Hardware domain then read it */
+    smp_rmb();
+    cpufreq_set_hwdom_res(cpufreq_info->result);
+}
+
+int sysctl_cpufreq_op(xen_sysctl_cpufreq_op_t *op)
+{
+    int ret = 0;
+    uint32_t domain_id = current->domain->domain_id;
+    uint32_t port;
+    struct domain *d;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_CPUFREQ_event_start:
+    case XEN_SYSCTL_CPUFREQ_event_stop:
+        d = rcu_lock_domain_by_id(domain_id);
+        if ( d == NULL )
+            return -ESRCH;
+        break;
+
+    default:
+        return -EOPNOTSUPP;
+    }
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_CPUFREQ_event_start:
+        /* Allocate event channel */
+        ret = alloc_unbound_xen_event_channel(d->vcpu[0], domain_id,
+                                              cpufreq_notification);
+        if (ret < 0)
+            goto out;
+
+        op->port = ret;
+
+        spin_lock(&hwdom_cpufreq.drv_lock);
+        hwdom_cpufreq.port = ret;
+        hwdom_cpufreq.domain = d;
+        spin_unlock(&hwdom_cpufreq.drv_lock);
+
+        ret = 0;
+        break;
+
+    case XEN_SYSCTL_CPUFREQ_event_stop:
+        spin_lock(&hwdom_cpufreq.drv_lock);
+        port = hwdom_cpufreq.port;
+        hwdom_cpufreq.port = 0;
+        hwdom_cpufreq.domain = NULL;
+        spin_unlock(&hwdom_cpufreq.drv_lock);
+
+        /* Free hwdom's event channel and leave the other one unbound */
+        free_xen_event_channel(d->vcpu[0], port);
+        break;
+    }
+out:
+    rcu_unlock_domain(d);
+    return ret;
+}
+
+static int hwdom_cpufreq_verify(struct cpufreq_policy *policy)
+{
+    struct hwdom_cpufreq_cpu_data *data;
+    struct processor_performance *perf;
+
+    if ( !policy || !(data = hwdom_cpufreq.cpu_data[policy->cpu]) ||
+         !processor_pminfo[policy->cpu] )
+        return -EINVAL;
+
+    perf = &processor_pminfo[policy->cpu]->perf;
+
+    cpufreq_verify_within_limits(policy, 0,
+        perf->states[perf->platform_limit].core_frequency * 1000);
+
+    return cpufreq_frequency_table_verify(policy, data->freq_table);
+}
+
+static int hwdom_cpufreq_target(struct cpufreq_policy *policy,
+                               unsigned int target_freq, unsigned int relation)
+{
+    struct hwdom_cpufreq_cpu_data *data = hwdom_cpufreq.cpu_data[policy->cpu];
+    struct processor_performance *perf;
+    struct cpufreq_freqs freqs;
+    cpumask_t online_policy_cpus;
+    unsigned int next_state = 0; /* Index into freq_table */
+    unsigned int next_perf_state = 0; /* Index into perf table */
+    unsigned int j;
+    int ret = 0;
+
+    if ( unlikely(data == NULL ||
+         data->perf_data == NULL || data->freq_table == NULL) )
+        return -ENODEV;
+
+    perf = data->perf_data;
+    ret = cpufreq_frequency_table_target(policy,
+                                         data->freq_table,
+                                         target_freq,
+                                         relation, &next_state);
+    if ( unlikely(ret) )
+        return -ENODEV;
+
+    cpumask_and(&online_policy_cpus, &cpu_online_map, policy->cpus);
+
+    next_perf_state = data->freq_table[next_state].index;
+    if ( perf->state == next_perf_state )
+    {
+        if ( unlikely(policy->resume) )
+            policy->resume = 0;
+        else
+            return 0;
+    }
+
+    freqs.old = perf->states[perf->state].core_frequency * 1000;
+    freqs.new = data->freq_table[next_state].frequency;
+
+    if ( cpufreq_is_waiting_answer() )
+        return -EAGAIN;
+
+     /* return previous result */
+    ret = cpufreq_get_hwdom_res();
+
+     /* Do send cmd for Hardware domain */
+    cpufreq_hwdom_change_freq(policy->cpu, freqs.new, (uint32_t)relation);
+
+    for_each_cpu( j, &online_policy_cpus )
+        cpufreq_statistic_update(j, perf->state, next_perf_state);
+
+    perf->state = next_perf_state;
+    policy->cur = freqs.new;
+
+    return ret;
+}
+
+static int hwdom_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+    struct processor_performance *perf;
+    struct hwdom_cpufreq_cpu_data *data;
+    unsigned int cpu = policy->cpu;
+    unsigned int valid_states = 0;
+    int i;
+    int ret = 0;
+
+    data = xzalloc(struct hwdom_cpufreq_cpu_data);
+    if ( !data )
+        return -ENOMEM;
+
+    hwdom_cpufreq.cpu_data[cpu] = data;
+
+    data->perf_data = &processor_pminfo[cpu]->perf;
+
+    perf = data->perf_data;
+    policy->shared_type = perf->shared_type;
+
+    data->freq_table = xmalloc_array(struct cpufreq_frequency_table,
+                                     (perf->state_count+1));
+    if ( !data->freq_table )
+    {
+        ret = -ENOMEM;
+        goto err_unreg;
+    }
+
+    /* detect transition latency */
+    policy->cpuinfo.transition_latency = 0;
+    for ( i = 0; i < perf->state_count; i++ )
+    {
+        if ( (perf->states[i].transition_latency * 1000) >
+             policy->cpuinfo.transition_latency )
+            policy->cpuinfo.transition_latency =
+                perf->states[i].transition_latency * 1000;
+    }
+
+    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
+
+    /* table init */
+    for ( i = 0; i < perf->state_count; i++ )
+    {
+        if ( i > 0 && perf->states[i].core_frequency >=
+            data->freq_table[valid_states-1].frequency / 1000 )
+            continue;
+
+        data->freq_table[valid_states].index = i;
+        data->freq_table[valid_states].frequency =
+            perf->states[i].core_frequency * 1000;
+        valid_states++;
+    }
+    data->freq_table[valid_states].frequency = CPUFREQ_TABLE_END;
+    perf->state = 0;
+
+    ret = cpufreq_frequency_table_cpuinfo(policy, data->freq_table);
+    if ( ret )
+        goto err_freqfree;
+
+
+    /* We will set the minimal frequency now. So set policy->resume to 0 */
+    policy->resume = 0;
+
+    /* Set the minimal frequency */
+    return hwdom_cpufreq_target(policy, policy->min, CPUFREQ_RELATION_L);
+
+ err_freqfree:
+    xfree(data->freq_table);
+ err_unreg:
+    xfree(data);
+    hwdom_cpufreq.cpu_data[cpu] = NULL;
+
+    return ret;
+}
+
+static int hwdom_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+{
+    struct hwdom_cpufreq_cpu_data *data = hwdom_cpufreq.cpu_data[policy->cpu];
+
+    if ( data )
+    {
+        hwdom_cpufreq.cpu_data[policy->cpu] = NULL;
+        xfree(data->freq_table);
+        xfree(data);
+    }
+
+    return 0;
+}
+
+static struct cpufreq_driver hwdom_cpufreq_driver = {
+    .name   = "hwdom-cpufreq",
+    .verify = hwdom_cpufreq_verify,
+    .target = hwdom_cpufreq_target,
+    .init   = hwdom_cpufreq_cpu_init,
+    .exit   = hwdom_cpufreq_cpu_exit,
+};
+
+static int __init hwdom_cpufreq_driver_init(void)
+{
+    int ret = 0;
+
+    if ( cpufreq_controller != FREQCTL_xen )
+        return 0;
+
+    spin_lock_init(&hwdom_cpufreq.drv_lock);
+    spin_lock_init(&hwdom_cpufreq.hwdom_res_lock);
+
+    ret = cpufreq_register_driver(&hwdom_cpufreq_driver);
+    if ( ret )
+        return ret;
+
+    init_timer(&hwdom_cpufreq.timer, cpufreq_hwdom_answer_tout, NULL, 0);
+
+    return ret;
+}
+
+__initcall(hwdom_cpufreq_driver_init);
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index d7b6c34..0c8c19d 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -264,4 +264,6 @@ int write_userspace_scaling_setspeed(unsigned int cpu, unsigned int freq);
 void cpufreq_dbs_timer_suspend(void);
 void cpufreq_dbs_timer_resume(void);
 
+int sysctl_cpufreq_op(xen_sysctl_cpufreq_op_t *op);
+
 #endif /* __XEN_CPUFREQ_PM_H__ */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKV-0006NI-OZ; Tue, 11 Nov 2014 13:17:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKT-0006Ll-NP
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A7/13-09842-18C02645; Tue, 11 Nov 2014 13:17:53 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415711870!11887035!1
X-Originating-IP: [64.18.0.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13988 invoked from network); 11 Nov 2014 13:17:52 -0000
Received: from exprod5og110.obsmtp.com (HELO exprod5og110.obsmtp.com)
	(64.18.0.20)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:52 -0000
Received: from mail-la0-f49.google.com ([209.85.215.49]) (using TLSv1) by
	exprod5ob110.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMfkCBUr3Q6S2yM+iCDvjai7WSMo8i@postini.com;
	Tue, 11 Nov 2014 05:17:52 PST
Received: by mail-la0-f49.google.com with SMTP id ge10so9569013lab.36
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=yVYv1meKvPCY5NIU/Q6JtMaVTiuJj0WgDlvxj87tI2U=;
	b=B8RfOWL+WkDtp8bs/7xQqxcHNl1dyZEjg7UReDVLV5DTCIv+VMLTRknLhPUrvF/06T
	fuTGef1+6sPhPd+Gt+NGKRWyNoFy6gHCt4y41Pie7MzfkHk19dOLWjQTKvZcmyZrDFp7
	EIxki7Wb3Y0yclGh6Wbv50z6rOt7CnHXk8vpE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=yVYv1meKvPCY5NIU/Q6JtMaVTiuJj0WgDlvxj87tI2U=;
	b=UEppZxZmLLoehK91X02bZuqwL1J5qhzyxVYBocXRODEfzsiKfYuRhuyupAtTLmwdBR
	EhorYkayV1YeLangxkBj2DRonfAOpq38UY0MrQlkUAcc0x6+Th+7NNh0ZuwcgOqwbyMH
	MWAWAvbd1OCbh8gyyzTsT2gcP1wnjMQdDM8ITX1+MJpvy/tLbMgvRajqkk5bqD6Odp6e
	Dnu0hYe4AA0ZfsAQXnti7kt8DbZxjeLgLiw+EXQi+krdqzicqeH51XPgPYmU0BBi+oGv
	9/9OKG4/oZNE4zd/lRJPBWfX9uFF44SdErfr7bs0YT9HjR4ZNU2HDu+E2Nc5edfuYujx
	b9sw==
X-Gm-Message-State: ALoCoQl2QI2+S9CW2b7xmeox/shCq0bLfZYGMRquqK02UOXr5jL2GzvzScRVdQk+bmoeshXDhiOXOBkLw0pbQBsyhaInRzkn0vd0PVqgXshrE7r+M5rh3A7LkNOvlSlsU+mkmsPaeyzXaBdvzoxDlRf2wTZfVCNS4Q==
X-Received: by 10.152.87.18 with SMTP id t18mr36379713laz.0.1415711868834;
	Tue, 11 Nov 2014 05:17:48 -0800 (PST)
X-Received: by 10.152.87.18 with SMTP id t18mr36379702laz.0.1415711868772;
	Tue, 11 Nov 2014 05:17:48 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id kw6sm139818lac.43.2014.11.11.05.17.47
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:48 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:14 +0200
Message-Id: <1415711834-1740-13-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 12/12] xen/arm: enable cpufreq
	functionality for ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/Rules.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 718cd8a..1484b55 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -9,6 +9,9 @@
 HAS_DEVICE_TREE := y
 HAS_VIDEO := y
 HAS_ARM_HDLCD := y
+HAS_CPUFREQ := y
+HAS_HWDOM_CPUFREQ := y
+HAS_PM := y
 
 CFLAGS += -I$(BASEDIR)/include
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:17:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBKV-0006NI-OZ; Tue, 11 Nov 2014 13:17:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBKT-0006Ll-NP
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:17:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A7/13-09842-18C02645; Tue, 11 Nov 2014 13:17:53 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415711870!11887035!1
X-Originating-IP: [64.18.0.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13988 invoked from network); 11 Nov 2014 13:17:52 -0000
Received: from exprod5og110.obsmtp.com (HELO exprod5og110.obsmtp.com)
	(64.18.0.20)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:17:52 -0000
Received: from mail-la0-f49.google.com ([209.85.215.49]) (using TLSv1) by
	exprod5ob110.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMfkCBUr3Q6S2yM+iCDvjai7WSMo8i@postini.com;
	Tue, 11 Nov 2014 05:17:52 PST
Received: by mail-la0-f49.google.com with SMTP id ge10so9569013lab.36
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:17:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=yVYv1meKvPCY5NIU/Q6JtMaVTiuJj0WgDlvxj87tI2U=;
	b=B8RfOWL+WkDtp8bs/7xQqxcHNl1dyZEjg7UReDVLV5DTCIv+VMLTRknLhPUrvF/06T
	fuTGef1+6sPhPd+Gt+NGKRWyNoFy6gHCt4y41Pie7MzfkHk19dOLWjQTKvZcmyZrDFp7
	EIxki7Wb3Y0yclGh6Wbv50z6rOt7CnHXk8vpE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=yVYv1meKvPCY5NIU/Q6JtMaVTiuJj0WgDlvxj87tI2U=;
	b=UEppZxZmLLoehK91X02bZuqwL1J5qhzyxVYBocXRODEfzsiKfYuRhuyupAtTLmwdBR
	EhorYkayV1YeLangxkBj2DRonfAOpq38UY0MrQlkUAcc0x6+Th+7NNh0ZuwcgOqwbyMH
	MWAWAvbd1OCbh8gyyzTsT2gcP1wnjMQdDM8ITX1+MJpvy/tLbMgvRajqkk5bqD6Odp6e
	Dnu0hYe4AA0ZfsAQXnti7kt8DbZxjeLgLiw+EXQi+krdqzicqeH51XPgPYmU0BBi+oGv
	9/9OKG4/oZNE4zd/lRJPBWfX9uFF44SdErfr7bs0YT9HjR4ZNU2HDu+E2Nc5edfuYujx
	b9sw==
X-Gm-Message-State: ALoCoQl2QI2+S9CW2b7xmeox/shCq0bLfZYGMRquqK02UOXr5jL2GzvzScRVdQk+bmoeshXDhiOXOBkLw0pbQBsyhaInRzkn0vd0PVqgXshrE7r+M5rh3A7LkNOvlSlsU+mkmsPaeyzXaBdvzoxDlRf2wTZfVCNS4Q==
X-Received: by 10.152.87.18 with SMTP id t18mr36379713laz.0.1415711868834;
	Tue, 11 Nov 2014 05:17:48 -0800 (PST)
X-Received: by 10.152.87.18 with SMTP id t18mr36379702laz.0.1415711868772;
	Tue, 11 Nov 2014 05:17:48 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id kw6sm139818lac.43.2014.11.11.05.17.47
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:17:48 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:17:14 +0200
Message-Id: <1415711834-1740-13-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [RFC PATCH v5 12/12] xen/arm: enable cpufreq
	functionality for ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/arch/arm/Rules.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 718cd8a..1484b55 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -9,6 +9,9 @@
 HAS_DEVICE_TREE := y
 HAS_VIDEO := y
 HAS_ARM_HDLCD := y
+HAS_CPUFREQ := y
+HAS_HWDOM_CPUFREQ := y
+HAS_PM := y
 
 CFLAGS += -I$(BASEDIR)/include
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLE-0006wk-LQ; Tue, 11 Nov 2014 13:18:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLD-0006vj-DL
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9B/B4-24532-EAC02645; Tue, 11 Nov 2014 13:18:38 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415711916!11910961!1
X-Originating-IP: [64.18.0.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9283 invoked from network); 11 Nov 2014 13:18:37 -0000
Received: from exprod5og126.obsmtp.com (HELO exprod5og126.obsmtp.com)
	(64.18.0.251)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:37 -0000
Received: from mail-lb0-f175.google.com ([209.85.217.175]) (using TLSv1) by
	exprod5ob126.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMq3Q+kmuEDY7oCrRJ1+cdavOdkW+z@postini.com;
	Tue, 11 Nov 2014 05:18:37 PST
Received: by mail-lb0-f175.google.com with SMTP id n15so7517792lbi.6
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id;
	bh=SpA7PKfbGoJBXaRc+SCETQ7rTo7ahsGRIFQgIDPeF9E=;
	b=PXD14Ij6lj+1msNcrJo9iwZkOacR/l6ukagSWgei+JdIjnGz14YFhX3EJfh2Ijp68I
	46y1T7XwMIKTtlilh7lpsUR1uc+7I5FVHpjU6VuLhoM81wFAv/RV5e1lxmSUmwFFOmzG
	kIJQki55nku6BfiLGmdRJmEs/bl8Ha0bz+Z2U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=SpA7PKfbGoJBXaRc+SCETQ7rTo7ahsGRIFQgIDPeF9E=;
	b=c3doGqoAwUQYRtFbE2jYPzYv6zZCwACkQZVlejl4MtXqQsNOAadb1C81TG4SO3uaRi
	9gmsVisZTEGPTJ+fSmSSy2cWHzYRdiwCqdAY+52CxmRwwqB+gvx143O1tDlo9LzEmiyl
	eYOnDxTL61gZRXELux+IkgA1erw4EI4pTUhAOohMA87C73VCQxUDqWFZZIodL5P04akQ
	FURcDylkdFhGNuvNqa6KWNUM2DS+3HDD/Z8T6Eank61SGpG+08TWZ1E3CmjNjLq/OOqc
	lYG+CxuRY9avpeba4Zh9V7+EmpTdaPmF5tVbFc7hYfq5/NKwJdeflm703lTFbnncO44z
	ewFg==
X-Gm-Message-State: ALoCoQmwqdBvJrQK/9Wa8gYYsuTSV6M5qVAQ50hYbxW8qk2eqQRqaxX5MGQ5+tQDFuyvT7MVToUOPb+JdRfmBlK9sRKaE2+wMCB0PUERfuqBrWRtQmVhBCcDkQxT3FNVlrCIKIUTpsg6nFBubHcGtljKaj5fki4ccA==
X-Received: by 10.112.36.197 with SMTP id s5mr36557404lbj.30.1415711914322;
	Tue, 11 Nov 2014 05:18:34 -0800 (PST)
X-Received: by 10.112.36.197 with SMTP id s5mr36557396lbj.30.1415711914264;
	Tue, 11 Nov 2014 05:18:34 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id h2sm5970656laa.17.2014.11.11.05.18.32
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:33 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:21 +0200
Message-Id: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 00/10] xen_cpufreq implementation in
	kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi to all.

Next series of patches implements xen-cpufreq driver in kernel.

Cpufreq core and registered cpufreq governors are located in xen. Hwdom has CPU
driver which can only change frequency of the physical CPUs. In addition this
driver can change CPUs regulator voltage. At start time xen-cpufreq driver
in hwdom reads an information about physical CPUs number and uploads to Xen
information about those physical cpus. Then hwdon uses XEN_SYSCTL_cpufreq_op
operation to start events from hwdom-cpufreq ddriver in Xen.
Changing frequency workflow:
 * hwdom-cpufreq driver in Xen wants to change the
   frequency of the physical CPU
 * hwdom-cpufreq in Xen sets parameters in the shared
   memory
 * hwdom-cpufreq driver in Xen sends an event via event channel
   to notify the xen-cpufreq driver in hwdom
 * xen-cpufreq driver in hwdom reads parameters from the shared
   memory, changes frequency and copies the result of
   the operation to the shared memory
 * xen-cpufreq driver in hwdom sends an event via event channel
   to notify the cpufreq driver in Xen

Next configs should be enabled to use xen-cpufreq driver:
CONFIG_GENERIC_CPUFREQ_CPU0
CONFIG_XEN_CPUFREQ

Changed since v1:
 * added cpufreq_drv_ops which allows to use more than one high-level
   cpufreq driver
 * reworked xen-cpufreq and drivers so the same kernel is able to run
   on bare metal and within Xen.

Changed since v2:
 * used VIRQ_CPUFREQ with number 14 instead of the 13
 * slightly reworked xen-cpufreq driver

Changed since v3:
 * documented /hypervisor/pcpus/ node
 * added cpufreq shared info definition to receive commands from the
   Xen cpufreq driver
 * config CONFIG_CPUMASK_OFFSTACK now is checked in the Kconfig

Changed since v4:
 * implemented an event channel between Xen and hwdom
 * restored XEN_SYSCTL_cpufreq_op definition (start/stop hwdom-cpufreq
   driver events)
 * extended comments for some patches (adding hypercalls, adding xen-cpufreq
   driver)
 * removed VIRQ_CPUFREQ

Oleksandr Dmytryshyn (10):
  PM / OPP: make cpufreq functions dependent on CONFIG_CPU_FREQ_TABLE
  xen/arm: add sysctl hypercall
  xen/arm: add dom0_op hypercall
  docs: Xen ARM DT bindings: document pcpus property
  cpufreq: cpufreq-cpu0: change cpus data path in devtree for hwdom
    kernel
  cpufreq: introduce cpufreq_drv_ops
  cpufreq: make cpufreq low-level drivers visible for CPUFREQ_DRV_OPS
    config
  xen: arm: add cpufreq shared info definition
  xen/arm: add XEN_SYSCTL_cpufreq_op definition
  xen/arm: cpufreq: add xen-cpufreq driver

 Documentation/devicetree/bindings/arm/xen.txt |  20 +-
 arch/arm/include/asm/xen/hypercall.h          |   2 +
 arch/arm/include/asm/xen/interface.h          |  17 +-
 arch/arm/xen/enlighten.c                      |   2 +
 arch/arm/xen/hypercall.S                      |   2 +
 drivers/Makefile                              |   2 +-
 drivers/base/power/opp.c                      |   4 +-
 drivers/cpufreq/Kconfig                       |  40 +-
 drivers/cpufreq/Makefile                      |   2 +
 drivers/cpufreq/acpi-cpufreq.c                |   5 +-
 drivers/cpufreq/cpufreq-cpu0.c                |   8 +-
 drivers/cpufreq/cpufreq.c                     | 116 ++--
 drivers/cpufreq/cpufreq_drv_ops.c             | 196 ++++++
 drivers/cpufreq/cpufreq_drv_ops.h             |  54 ++
 drivers/cpufreq/cpufreq_governor.c            |   4 +-
 drivers/cpufreq/xen-cpufreq.c                 | 917 ++++++++++++++++++++++++++
 include/linux/cpufreq.h                       |   2 +-
 include/linux/opp.h                           |   2 +-
 include/xen/interface/platform.h              |   1 +
 include/xen/interface/sysctl.h                |  89 +++
 include/xen/interface/xen.h                   |   6 +
 21 files changed, 1423 insertions(+), 68 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h
 create mode 100644 drivers/cpufreq/xen-cpufreq.c
 create mode 100644 include/xen/interface/sysctl.h

-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLE-0006wk-LQ; Tue, 11 Nov 2014 13:18:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLD-0006vj-DL
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9B/B4-24532-EAC02645; Tue, 11 Nov 2014 13:18:38 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415711916!11910961!1
X-Originating-IP: [64.18.0.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9283 invoked from network); 11 Nov 2014 13:18:37 -0000
Received: from exprod5og126.obsmtp.com (HELO exprod5og126.obsmtp.com)
	(64.18.0.251)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:37 -0000
Received: from mail-lb0-f175.google.com ([209.85.217.175]) (using TLSv1) by
	exprod5ob126.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMq3Q+kmuEDY7oCrRJ1+cdavOdkW+z@postini.com;
	Tue, 11 Nov 2014 05:18:37 PST
Received: by mail-lb0-f175.google.com with SMTP id n15so7517792lbi.6
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id;
	bh=SpA7PKfbGoJBXaRc+SCETQ7rTo7ahsGRIFQgIDPeF9E=;
	b=PXD14Ij6lj+1msNcrJo9iwZkOacR/l6ukagSWgei+JdIjnGz14YFhX3EJfh2Ijp68I
	46y1T7XwMIKTtlilh7lpsUR1uc+7I5FVHpjU6VuLhoM81wFAv/RV5e1lxmSUmwFFOmzG
	kIJQki55nku6BfiLGmdRJmEs/bl8Ha0bz+Z2U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=SpA7PKfbGoJBXaRc+SCETQ7rTo7ahsGRIFQgIDPeF9E=;
	b=c3doGqoAwUQYRtFbE2jYPzYv6zZCwACkQZVlejl4MtXqQsNOAadb1C81TG4SO3uaRi
	9gmsVisZTEGPTJ+fSmSSy2cWHzYRdiwCqdAY+52CxmRwwqB+gvx143O1tDlo9LzEmiyl
	eYOnDxTL61gZRXELux+IkgA1erw4EI4pTUhAOohMA87C73VCQxUDqWFZZIodL5P04akQ
	FURcDylkdFhGNuvNqa6KWNUM2DS+3HDD/Z8T6Eank61SGpG+08TWZ1E3CmjNjLq/OOqc
	lYG+CxuRY9avpeba4Zh9V7+EmpTdaPmF5tVbFc7hYfq5/NKwJdeflm703lTFbnncO44z
	ewFg==
X-Gm-Message-State: ALoCoQmwqdBvJrQK/9Wa8gYYsuTSV6M5qVAQ50hYbxW8qk2eqQRqaxX5MGQ5+tQDFuyvT7MVToUOPb+JdRfmBlK9sRKaE2+wMCB0PUERfuqBrWRtQmVhBCcDkQxT3FNVlrCIKIUTpsg6nFBubHcGtljKaj5fki4ccA==
X-Received: by 10.112.36.197 with SMTP id s5mr36557404lbj.30.1415711914322;
	Tue, 11 Nov 2014 05:18:34 -0800 (PST)
X-Received: by 10.112.36.197 with SMTP id s5mr36557396lbj.30.1415711914264;
	Tue, 11 Nov 2014 05:18:34 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id h2sm5970656laa.17.2014.11.11.05.18.32
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:33 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:21 +0200
Message-Id: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 00/10] xen_cpufreq implementation in
	kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi to all.

Next series of patches implements xen-cpufreq driver in kernel.

Cpufreq core and registered cpufreq governors are located in xen. Hwdom has CPU
driver which can only change frequency of the physical CPUs. In addition this
driver can change CPUs regulator voltage. At start time xen-cpufreq driver
in hwdom reads an information about physical CPUs number and uploads to Xen
information about those physical cpus. Then hwdon uses XEN_SYSCTL_cpufreq_op
operation to start events from hwdom-cpufreq ddriver in Xen.
Changing frequency workflow:
 * hwdom-cpufreq driver in Xen wants to change the
   frequency of the physical CPU
 * hwdom-cpufreq in Xen sets parameters in the shared
   memory
 * hwdom-cpufreq driver in Xen sends an event via event channel
   to notify the xen-cpufreq driver in hwdom
 * xen-cpufreq driver in hwdom reads parameters from the shared
   memory, changes frequency and copies the result of
   the operation to the shared memory
 * xen-cpufreq driver in hwdom sends an event via event channel
   to notify the cpufreq driver in Xen

Next configs should be enabled to use xen-cpufreq driver:
CONFIG_GENERIC_CPUFREQ_CPU0
CONFIG_XEN_CPUFREQ

Changed since v1:
 * added cpufreq_drv_ops which allows to use more than one high-level
   cpufreq driver
 * reworked xen-cpufreq and drivers so the same kernel is able to run
   on bare metal and within Xen.

Changed since v2:
 * used VIRQ_CPUFREQ with number 14 instead of the 13
 * slightly reworked xen-cpufreq driver

Changed since v3:
 * documented /hypervisor/pcpus/ node
 * added cpufreq shared info definition to receive commands from the
   Xen cpufreq driver
 * config CONFIG_CPUMASK_OFFSTACK now is checked in the Kconfig

Changed since v4:
 * implemented an event channel between Xen and hwdom
 * restored XEN_SYSCTL_cpufreq_op definition (start/stop hwdom-cpufreq
   driver events)
 * extended comments for some patches (adding hypercalls, adding xen-cpufreq
   driver)
 * removed VIRQ_CPUFREQ

Oleksandr Dmytryshyn (10):
  PM / OPP: make cpufreq functions dependent on CONFIG_CPU_FREQ_TABLE
  xen/arm: add sysctl hypercall
  xen/arm: add dom0_op hypercall
  docs: Xen ARM DT bindings: document pcpus property
  cpufreq: cpufreq-cpu0: change cpus data path in devtree for hwdom
    kernel
  cpufreq: introduce cpufreq_drv_ops
  cpufreq: make cpufreq low-level drivers visible for CPUFREQ_DRV_OPS
    config
  xen: arm: add cpufreq shared info definition
  xen/arm: add XEN_SYSCTL_cpufreq_op definition
  xen/arm: cpufreq: add xen-cpufreq driver

 Documentation/devicetree/bindings/arm/xen.txt |  20 +-
 arch/arm/include/asm/xen/hypercall.h          |   2 +
 arch/arm/include/asm/xen/interface.h          |  17 +-
 arch/arm/xen/enlighten.c                      |   2 +
 arch/arm/xen/hypercall.S                      |   2 +
 drivers/Makefile                              |   2 +-
 drivers/base/power/opp.c                      |   4 +-
 drivers/cpufreq/Kconfig                       |  40 +-
 drivers/cpufreq/Makefile                      |   2 +
 drivers/cpufreq/acpi-cpufreq.c                |   5 +-
 drivers/cpufreq/cpufreq-cpu0.c                |   8 +-
 drivers/cpufreq/cpufreq.c                     | 116 ++--
 drivers/cpufreq/cpufreq_drv_ops.c             | 196 ++++++
 drivers/cpufreq/cpufreq_drv_ops.h             |  54 ++
 drivers/cpufreq/cpufreq_governor.c            |   4 +-
 drivers/cpufreq/xen-cpufreq.c                 | 917 ++++++++++++++++++++++++++
 include/linux/cpufreq.h                       |   2 +-
 include/linux/opp.h                           |   2 +-
 include/xen/interface/platform.h              |   1 +
 include/xen/interface/sysctl.h                |  89 +++
 include/xen/interface/xen.h                   |   6 +
 21 files changed, 1423 insertions(+), 68 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h
 create mode 100644 drivers/cpufreq/xen-cpufreq.c
 create mode 100644 include/xen/interface/sysctl.h

-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLI-0006z5-CR; Tue, 11 Nov 2014 13:18:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLG-0006xk-Tp
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:43 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	E3/3B-03145-1BC02645; Tue, 11 Nov 2014 13:18:41 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415711918!11792238!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25133 invoked from network); 11 Nov 2014 13:18:40 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:40 -0000
Received: from mail-lb0-f176.google.com ([209.85.217.176]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMruepgvynqlVDabej1hTvvstOwAnd@postini.com;
	Tue, 11 Nov 2014 05:18:40 PST
Received: by mail-lb0-f176.google.com with SMTP id 10so7667467lbg.35
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=Tn9M0rWmNjsmwYZUdRC0mijqbiyYFAXMgaxiSTg3FH0=;
	b=gqkmkLrno3mQ1Ah2NAyfLGExoWnXXzBUb7dpuNam1wvn15/72XwLIdANzxdcw2PYd+
	4yEuQze4WhwsEfj8Ko1NbgLJK2/MT1CesR58df0r2EdrGgqWwrmRnuouK4sgeZ6LzNpx
	j09St1UCXHCf8WWVvZ1MuQt6achLUlJQMvIlc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=Tn9M0rWmNjsmwYZUdRC0mijqbiyYFAXMgaxiSTg3FH0=;
	b=O2CVVEo9ObWHk0BSrgQGZbVw3hNt/GjDu6vCazgPvPfVxgbC5ZzxlAvpi25JRp0Klo
	zKB1vHCmronySBxTorv7S+wfzIMn9BLsbivNa2f5p7jS91FNTjiBC6EfBEwhNyYHinUT
	kxhtYZealDFwImKBXXUv8GS4LM8K6zwjt61LVlmDbjt9ZG0emncjqtRhrNPGIIuyWEcU
	VGg/116kJo27Trio3d8uYxVOuooNDs87w6Hywu5g45AVdCKNbJU4SIQb1GBrTGoSrIR4
	OTF/ANBekpNh1ByJGv/01gSs4EbwourjaeRtqREcMgE+B7DH+TsHZ18dhjRp6SvvKPl3
	eJtA==
X-Gm-Message-State: ALoCoQn6cfAbyMwUQwicazJy5WQ6wXkbw66jvtTpfAUWCt2y5Qi8t5MQ4NudOE0jenMWcf7twEqT9EcSEjWyIWYsXhZEcQTt5xZ8evE0A4FxIDpqFQ05HqsqiMDmCpodGANIJqsoa6OBzqOhVtA8jUvbf+4pIsw0kw==
X-Received: by 10.112.148.130 with SMTP id ts2mr36413545lbb.43.1415711917004; 
	Tue, 11 Nov 2014 05:18:37 -0800 (PST)
X-Received: by 10.112.148.130 with SMTP id ts2mr36413537lbb.43.1415711916938; 
	Tue, 11 Nov 2014 05:18:36 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id nb7sm5970755lbb.43.2014.11.11.05.18.35
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:35 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:22 +0200
Message-Id: <1415711911-1807-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 01/10] PM / OPP: make cpufreq functions
	dependent on CONFIG_CPU_FREQ_TABLE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Those functions should be dependent on CONFIG_CPU_FREQ_TABLE
instead of the CONFIG_CPU_FREQ.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/base/power/opp.c | 4 ++--
 include/linux/opp.h      | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 32ee0fc..17c5bc5 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -592,7 +592,7 @@ int opp_disable(struct device *dev, unsigned long freq)
 }
 EXPORT_SYMBOL_GPL(opp_disable);
 
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_CPU_FREQ_TABLE
 /**
  * opp_init_cpufreq_table() - create a cpufreq table for a device
  * @dev:	device for which we do this operation
@@ -680,7 +680,7 @@ void opp_free_cpufreq_table(struct device *dev,
 	*table = NULL;
 }
 EXPORT_SYMBOL_GPL(opp_free_cpufreq_table);
-#endif		/* CONFIG_CPU_FREQ */
+#endif		/* CONFIG_CPU_FREQ_TABLE */
 
 /**
  * opp_get_notifier() - find notifier_head of the device with opp
diff --git a/include/linux/opp.h b/include/linux/opp.h
index 214e0ebc..35c98f3 100644
--- a/include/linux/opp.h
+++ b/include/linux/opp.h
@@ -112,7 +112,7 @@ static inline struct srcu_notifier_head *opp_get_notifier(struct device *dev)
 }
 #endif		/* CONFIG_PM_OPP */
 
-#if defined(CONFIG_CPU_FREQ) && defined(CONFIG_PM_OPP)
+#if defined(CONFIG_CPU_FREQ_TABLE) && defined(CONFIG_PM_OPP)
 int opp_init_cpufreq_table(struct device *dev,
 			    struct cpufreq_frequency_table **table);
 void opp_free_cpufreq_table(struct device *dev,
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLI-0006z5-CR; Tue, 11 Nov 2014 13:18:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLG-0006xk-Tp
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:43 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	E3/3B-03145-1BC02645; Tue, 11 Nov 2014 13:18:41 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415711918!11792238!1
X-Originating-IP: [64.18.0.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25133 invoked from network); 11 Nov 2014 13:18:40 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:40 -0000
Received: from mail-lb0-f176.google.com ([209.85.217.176]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMruepgvynqlVDabej1hTvvstOwAnd@postini.com;
	Tue, 11 Nov 2014 05:18:40 PST
Received: by mail-lb0-f176.google.com with SMTP id 10so7667467lbg.35
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=Tn9M0rWmNjsmwYZUdRC0mijqbiyYFAXMgaxiSTg3FH0=;
	b=gqkmkLrno3mQ1Ah2NAyfLGExoWnXXzBUb7dpuNam1wvn15/72XwLIdANzxdcw2PYd+
	4yEuQze4WhwsEfj8Ko1NbgLJK2/MT1CesR58df0r2EdrGgqWwrmRnuouK4sgeZ6LzNpx
	j09St1UCXHCf8WWVvZ1MuQt6achLUlJQMvIlc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=Tn9M0rWmNjsmwYZUdRC0mijqbiyYFAXMgaxiSTg3FH0=;
	b=O2CVVEo9ObWHk0BSrgQGZbVw3hNt/GjDu6vCazgPvPfVxgbC5ZzxlAvpi25JRp0Klo
	zKB1vHCmronySBxTorv7S+wfzIMn9BLsbivNa2f5p7jS91FNTjiBC6EfBEwhNyYHinUT
	kxhtYZealDFwImKBXXUv8GS4LM8K6zwjt61LVlmDbjt9ZG0emncjqtRhrNPGIIuyWEcU
	VGg/116kJo27Trio3d8uYxVOuooNDs87w6Hywu5g45AVdCKNbJU4SIQb1GBrTGoSrIR4
	OTF/ANBekpNh1ByJGv/01gSs4EbwourjaeRtqREcMgE+B7DH+TsHZ18dhjRp6SvvKPl3
	eJtA==
X-Gm-Message-State: ALoCoQn6cfAbyMwUQwicazJy5WQ6wXkbw66jvtTpfAUWCt2y5Qi8t5MQ4NudOE0jenMWcf7twEqT9EcSEjWyIWYsXhZEcQTt5xZ8evE0A4FxIDpqFQ05HqsqiMDmCpodGANIJqsoa6OBzqOhVtA8jUvbf+4pIsw0kw==
X-Received: by 10.112.148.130 with SMTP id ts2mr36413545lbb.43.1415711917004; 
	Tue, 11 Nov 2014 05:18:37 -0800 (PST)
X-Received: by 10.112.148.130 with SMTP id ts2mr36413537lbb.43.1415711916938; 
	Tue, 11 Nov 2014 05:18:36 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id nb7sm5970755lbb.43.2014.11.11.05.18.35
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:35 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:22 +0200
Message-Id: <1415711911-1807-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 01/10] PM / OPP: make cpufreq functions
	dependent on CONFIG_CPU_FREQ_TABLE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Those functions should be dependent on CONFIG_CPU_FREQ_TABLE
instead of the CONFIG_CPU_FREQ.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/base/power/opp.c | 4 ++--
 include/linux/opp.h      | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 32ee0fc..17c5bc5 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -592,7 +592,7 @@ int opp_disable(struct device *dev, unsigned long freq)
 }
 EXPORT_SYMBOL_GPL(opp_disable);
 
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_CPU_FREQ_TABLE
 /**
  * opp_init_cpufreq_table() - create a cpufreq table for a device
  * @dev:	device for which we do this operation
@@ -680,7 +680,7 @@ void opp_free_cpufreq_table(struct device *dev,
 	*table = NULL;
 }
 EXPORT_SYMBOL_GPL(opp_free_cpufreq_table);
-#endif		/* CONFIG_CPU_FREQ */
+#endif		/* CONFIG_CPU_FREQ_TABLE */
 
 /**
  * opp_get_notifier() - find notifier_head of the device with opp
diff --git a/include/linux/opp.h b/include/linux/opp.h
index 214e0ebc..35c98f3 100644
--- a/include/linux/opp.h
+++ b/include/linux/opp.h
@@ -112,7 +112,7 @@ static inline struct srcu_notifier_head *opp_get_notifier(struct device *dev)
 }
 #endif		/* CONFIG_PM_OPP */
 
-#if defined(CONFIG_CPU_FREQ) && defined(CONFIG_PM_OPP)
+#if defined(CONFIG_CPU_FREQ_TABLE) && defined(CONFIG_PM_OPP)
 int opp_init_cpufreq_table(struct device *dev,
 			    struct cpufreq_frequency_table **table);
 void opp_free_cpufreq_table(struct device *dev,
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLM-00072q-Cc; Tue, 11 Nov 2014 13:18:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLK-000715-Vi
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:47 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	55/BE-14727-6BC02645; Tue, 11 Nov 2014 13:18:46 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415711921!11773891!1
X-Originating-IP: [64.18.0.147]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30539 invoked from network); 11 Nov 2014 13:18:43 -0000
Received: from exprod5og116.obsmtp.com (HELO exprod5og116.obsmtp.com)
	(64.18.0.147)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:43 -0000
Received: from mail-lb0-f180.google.com ([209.85.217.180]) (using TLSv1) by
	exprod5ob116.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMsVbkQ+7TXUe9KwgBc/oFA3l9z+46@postini.com;
	Tue, 11 Nov 2014 05:18:43 PST
Received: by mail-lb0-f180.google.com with SMTP id z11so825672lbi.39
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=nuuO7fC6kNUVNv7nWCXQQ+27d8/SRovGxv3dmZx1oaM=;
	b=GqphfO8gXLAoV3ku7JmDoX2nqWnXgNISaz/uw7EMnaeeoqiCrGsoYjwH3QfaQSy8Iv
	e6ROhbfnUpnBrPLS+r+1C+EzdgWG6GqSQhLtQ42FG+ZEc5uZmRErL5yg6P6VvOxf56uR
	59g+SpA+6ZxicTxWtXdD5XB4poNv79mIRW/4A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=nuuO7fC6kNUVNv7nWCXQQ+27d8/SRovGxv3dmZx1oaM=;
	b=JKJBHgkQp2l0lFy0/h+r+fi6fFUb74Jlm4L+fYhf+WTKzf26BOODM4aVo4gkS6nzb6
	ZlCrFJa2x+TukDIhBz+69sDFBYiUYlQv6On3QiLt6kRZCna8tYZ2GWUT1AfBUSB01ImV
	TFZDk6Z2mPGK495nDdNsQeFLgkFqplqBTJO5ski5qpLpIusPC2cAbuGFJbIEey9OxMHg
	wSbsUvAgywroaVsNAZ6UJNWAxS/zF8icOhx3jB/cN9PCQfDEJVo/n+61urEO/Olw8C9i
	iZtWMT3MrP3U2MEzhbg6iSHA2Dy2Y/5/CLvzMzvM2Wo1DiIujCD3ibVtJpZ0ws+fDncm
	Qamg==
X-Gm-Message-State: ALoCoQnGvnFhE6IbCU5UyhkDShyDl0SXhdnZSnZ3balOvL/+mf7scfRV93XYF2eGJZzSGuKWeY8mp1GOHGGP7JIm9LOOH31sKL8HofGHV5CGk9cIMZO6K/PxYeG8AEH68MWr8x4eW9diYaZnK9GOkZ7/O7cENO5O1A==
X-Received: by 10.152.206.11 with SMTP id lk11mr36827486lac.42.1415711919466; 
	Tue, 11 Nov 2014 05:18:39 -0800 (PST)
X-Received: by 10.152.206.11 with SMTP id lk11mr36827473lac.42.1415711919410; 
	Tue, 11 Nov 2014 05:18:39 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id or5sm5970728lbb.42.2014.11.11.05.18.38
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:38 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:23 +0200
Message-Id: <1415711911-1807-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 02/10] xen/arm: add sysctl hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 will be used by xen-cpufreq driver
to get real number of physical CPUs.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
CC: Keir Fraser <keir@xen.org>
---
 arch/arm/include/asm/xen/hypercall.h |  1 +
 arch/arm/include/asm/xen/interface.h |  2 +
 arch/arm/xen/enlighten.c             |  1 +
 arch/arm/xen/hypercall.S             |  1 +
 include/xen/interface/sysctl.h       | 79 ++++++++++++++++++++++++++++++++++++
 include/xen/interface/xen.h          |  6 +++
 6 files changed, 90 insertions(+)
 create mode 100644 include/xen/interface/sysctl.h

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index c817c56..751869eb 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_sysctl(void *arg);
 
 static inline void
 MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 1151188..acf4b7a 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -19,6 +19,7 @@
 	__DEFINE_GUEST_HANDLE(name, struct name)
 #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
 #define GUEST_HANDLE(name)        __guest_handle_ ## name
+#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
 
 #define set_xen_guest_handle(hnd, val)			\
 	do {						\
@@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(uint8_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 DEFINE_GUEST_HANDLE(xen_ulong_t);
 
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index eb0d851..675f17a 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index d1cf7b7..a1276df 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
+HYPERCALL1(sysctl);
 
 ENTRY(privcmd_call)
 	stmdb sp!, {r4}
diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
new file mode 100644
index 0000000..97c91b0
--- /dev/null
+++ b/include/xen/interface/sysctl.h
@@ -0,0 +1,79 @@
+/******************************************************************************
+ * sysctl.h
+ *
+ * System management operations. For use by node control stack.
+ *
+ * Reused from xen: xen/include/public/sysctl.h
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2002-2006, K Fraser
+ * Copyright (c) 2014, GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_SYSCTL_H__
+#define __XEN_PUBLIC_SYSCTL_H__
+
+#include <xen/interface/xen.h>
+
+#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
+
+/*
+ * Get physical information about the host machine
+ */
+/* XEN_SYSCTL_physinfo */
+ /* (x86) The platform supports HVM guests. */
+#define _XEN_SYSCTL_PHYSCAP_hvm          0
+#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
+ /* (x86) The platform supports HVM-guest direct access to I/O devices. */
+#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
+#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
+struct xen_sysctl_physinfo {
+	uint32_t threads_per_core;
+	uint32_t cores_per_socket;
+	uint32_t nr_cpus;     /* # CPUs currently online */
+	uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
+	uint32_t nr_nodes;    /* # nodes currently online */
+	uint32_t max_node_id; /* Largest possible node ID on this host */
+	uint32_t cpu_khz;
+	uint64_aligned_t total_pages;
+	uint64_aligned_t free_pages;
+	uint64_aligned_t scrub_pages;
+	uint64_aligned_t outstanding_pages;
+	uint32_t hw_cap[8];
+
+	/* XEN_SYSCTL_PHYSCAP_??? */
+	uint32_t capabilities;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
+
+
+
+struct xen_sysctl {
+	uint32_t cmd;
+#define XEN_SYSCTL_physinfo                       3
+	uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
+	union {
+		struct xen_sysctl_physinfo          physinfo;
+		uint8_t                             pad[128];
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
+
+#endif /* __XEN_PUBLIC_SYSCTL_H__ */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 53ec416..cf64566 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -57,6 +57,7 @@
 #define __HYPERVISOR_event_channel_op     32
 #define __HYPERVISOR_physdev_op           33
 #define __HYPERVISOR_hvm_op               34
+#define __HYPERVISOR_sysctl               35
 #define __HYPERVISOR_tmem_op              38
 
 /* Architecture-specific hypercall definitions. */
@@ -526,6 +527,11 @@ struct tmem_op {
 
 DEFINE_GUEST_HANDLE(u64);
 
+struct xenctl_bitmap {
+	GUEST_HANDLE_64(uint8_t) bitmap;
+	uint32_t nr_bits;
+};
+
 #else /* __ASSEMBLY__ */
 
 /* In assembly code we cannot use C numeric constant suffixes. */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLM-00072q-Cc; Tue, 11 Nov 2014 13:18:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLK-000715-Vi
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:47 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	55/BE-14727-6BC02645; Tue, 11 Nov 2014 13:18:46 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415711921!11773891!1
X-Originating-IP: [64.18.0.147]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30539 invoked from network); 11 Nov 2014 13:18:43 -0000
Received: from exprod5og116.obsmtp.com (HELO exprod5og116.obsmtp.com)
	(64.18.0.147)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:43 -0000
Received: from mail-lb0-f180.google.com ([209.85.217.180]) (using TLSv1) by
	exprod5ob116.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMsVbkQ+7TXUe9KwgBc/oFA3l9z+46@postini.com;
	Tue, 11 Nov 2014 05:18:43 PST
Received: by mail-lb0-f180.google.com with SMTP id z11so825672lbi.39
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=nuuO7fC6kNUVNv7nWCXQQ+27d8/SRovGxv3dmZx1oaM=;
	b=GqphfO8gXLAoV3ku7JmDoX2nqWnXgNISaz/uw7EMnaeeoqiCrGsoYjwH3QfaQSy8Iv
	e6ROhbfnUpnBrPLS+r+1C+EzdgWG6GqSQhLtQ42FG+ZEc5uZmRErL5yg6P6VvOxf56uR
	59g+SpA+6ZxicTxWtXdD5XB4poNv79mIRW/4A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=nuuO7fC6kNUVNv7nWCXQQ+27d8/SRovGxv3dmZx1oaM=;
	b=JKJBHgkQp2l0lFy0/h+r+fi6fFUb74Jlm4L+fYhf+WTKzf26BOODM4aVo4gkS6nzb6
	ZlCrFJa2x+TukDIhBz+69sDFBYiUYlQv6On3QiLt6kRZCna8tYZ2GWUT1AfBUSB01ImV
	TFZDk6Z2mPGK495nDdNsQeFLgkFqplqBTJO5ski5qpLpIusPC2cAbuGFJbIEey9OxMHg
	wSbsUvAgywroaVsNAZ6UJNWAxS/zF8icOhx3jB/cN9PCQfDEJVo/n+61urEO/Olw8C9i
	iZtWMT3MrP3U2MEzhbg6iSHA2Dy2Y/5/CLvzMzvM2Wo1DiIujCD3ibVtJpZ0ws+fDncm
	Qamg==
X-Gm-Message-State: ALoCoQnGvnFhE6IbCU5UyhkDShyDl0SXhdnZSnZ3balOvL/+mf7scfRV93XYF2eGJZzSGuKWeY8mp1GOHGGP7JIm9LOOH31sKL8HofGHV5CGk9cIMZO6K/PxYeG8AEH68MWr8x4eW9diYaZnK9GOkZ7/O7cENO5O1A==
X-Received: by 10.152.206.11 with SMTP id lk11mr36827486lac.42.1415711919466; 
	Tue, 11 Nov 2014 05:18:39 -0800 (PST)
X-Received: by 10.152.206.11 with SMTP id lk11mr36827473lac.42.1415711919410; 
	Tue, 11 Nov 2014 05:18:39 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id or5sm5970728lbb.42.2014.11.11.05.18.38
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:38 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:23 +0200
Message-Id: <1415711911-1807-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 02/10] xen/arm: add sysctl hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 will be used by xen-cpufreq driver
to get real number of physical CPUs.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
CC: Keir Fraser <keir@xen.org>
---
 arch/arm/include/asm/xen/hypercall.h |  1 +
 arch/arm/include/asm/xen/interface.h |  2 +
 arch/arm/xen/enlighten.c             |  1 +
 arch/arm/xen/hypercall.S             |  1 +
 include/xen/interface/sysctl.h       | 79 ++++++++++++++++++++++++++++++++++++
 include/xen/interface/xen.h          |  6 +++
 6 files changed, 90 insertions(+)
 create mode 100644 include/xen/interface/sysctl.h

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index c817c56..751869eb 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_sysctl(void *arg);
 
 static inline void
 MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 1151188..acf4b7a 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -19,6 +19,7 @@
 	__DEFINE_GUEST_HANDLE(name, struct name)
 #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
 #define GUEST_HANDLE(name)        __guest_handle_ ## name
+#define GUEST_HANDLE_64(name)     GUEST_HANDLE(name)
 
 #define set_xen_guest_handle(hnd, val)			\
 	do {						\
@@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(uint8_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 DEFINE_GUEST_HANDLE(xen_ulong_t);
 
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index eb0d851..675f17a 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index d1cf7b7..a1276df 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
+HYPERCALL1(sysctl);
 
 ENTRY(privcmd_call)
 	stmdb sp!, {r4}
diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
new file mode 100644
index 0000000..97c91b0
--- /dev/null
+++ b/include/xen/interface/sysctl.h
@@ -0,0 +1,79 @@
+/******************************************************************************
+ * sysctl.h
+ *
+ * System management operations. For use by node control stack.
+ *
+ * Reused from xen: xen/include/public/sysctl.h
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2002-2006, K Fraser
+ * Copyright (c) 2014, GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_SYSCTL_H__
+#define __XEN_PUBLIC_SYSCTL_H__
+
+#include <xen/interface/xen.h>
+
+#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000A
+
+/*
+ * Get physical information about the host machine
+ */
+/* XEN_SYSCTL_physinfo */
+ /* (x86) The platform supports HVM guests. */
+#define _XEN_SYSCTL_PHYSCAP_hvm          0
+#define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
+ /* (x86) The platform supports HVM-guest direct access to I/O devices. */
+#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
+#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
+struct xen_sysctl_physinfo {
+	uint32_t threads_per_core;
+	uint32_t cores_per_socket;
+	uint32_t nr_cpus;     /* # CPUs currently online */
+	uint32_t max_cpu_id;  /* Largest possible CPU ID on this host */
+	uint32_t nr_nodes;    /* # nodes currently online */
+	uint32_t max_node_id; /* Largest possible node ID on this host */
+	uint32_t cpu_khz;
+	uint64_aligned_t total_pages;
+	uint64_aligned_t free_pages;
+	uint64_aligned_t scrub_pages;
+	uint64_aligned_t outstanding_pages;
+	uint32_t hw_cap[8];
+
+	/* XEN_SYSCTL_PHYSCAP_??? */
+	uint32_t capabilities;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
+
+
+
+struct xen_sysctl {
+	uint32_t cmd;
+#define XEN_SYSCTL_physinfo                       3
+	uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
+	union {
+		struct xen_sysctl_physinfo          physinfo;
+		uint8_t                             pad[128];
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl);
+
+#endif /* __XEN_PUBLIC_SYSCTL_H__ */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 53ec416..cf64566 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -57,6 +57,7 @@
 #define __HYPERVISOR_event_channel_op     32
 #define __HYPERVISOR_physdev_op           33
 #define __HYPERVISOR_hvm_op               34
+#define __HYPERVISOR_sysctl               35
 #define __HYPERVISOR_tmem_op              38
 
 /* Architecture-specific hypercall definitions. */
@@ -526,6 +527,11 @@ struct tmem_op {
 
 DEFINE_GUEST_HANDLE(u64);
 
+struct xenctl_bitmap {
+	GUEST_HANDLE_64(uint8_t) bitmap;
+	uint32_t nr_bits;
+};
+
 #else /* __ASSEMBLY__ */
 
 /* In assembly code we cannot use C numeric constant suffixes. */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLN-000755-Rw; Tue, 11 Nov 2014 13:18:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLM-00072Q-C4
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:48 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	C4/D9-24124-7BC02645; Tue, 11 Nov 2014 13:18:47 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415711923!11762294!1
X-Originating-IP: [64.18.0.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4460 invoked from network); 11 Nov 2014 13:18:45 -0000
Received: from exprod5og126.obsmtp.com (HELO exprod5og126.obsmtp.com)
	(64.18.0.251)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:45 -0000
Received: from mail-lb0-f182.google.com ([209.85.217.182]) (using TLSv1) by
	exprod5ob126.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMsweZda1K68ASQFfhZ6SQYeb3I0x6@postini.com;
	Tue, 11 Nov 2014 05:18:45 PST
Received: by mail-lb0-f182.google.com with SMTP id f15so8198683lbj.41
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=ZYYjPj7rgMzkF810wyCXzGzqCRzKR2IiIFE5K5+qcE8=;
	b=I4pZ9L0AB+udn+nrrRHRVavVdf4P5/Oxf20LJu8ymS2wpvijVunL64iyDDQ3thBK0j
	M+yOgR9bS3tfcBUKAPKgZQHAcBP2UHkWpa4bxjl9MnhFGmYRmDoWUWe5LH9EnhsGpKfX
	keJvs+7HfbgLnuLlixy0c1OQHHMGJEbFRiXyY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=ZYYjPj7rgMzkF810wyCXzGzqCRzKR2IiIFE5K5+qcE8=;
	b=MFqQMlUyTlBdg05cVdXkcS4E8dOqFNKDyMaIF1nCC7QEyDFbHPpa0G9eFipbh2Y0zg
	woT2PqmmssKr77Nwq4OizNLxQIGzOCWkLVz7zLuDj+QfklS8wAfsJrBS+r2wgx54Ww46
	AdWunE5+IT5bS0OmoVZ3c5UjAqsVpu2JXolZV2/bd8asLQ1f8Pdh/nLwiBxQ92THgNnb
	cVG6v3TnMPE0lgQnZejqSoOzTtwyN6OO3MtVh00TbGw/3BA/lumeFMuUS7W5FRo9Papk
	0rzBcMWW/23pomZtWij/wjv2ZHthH7MyytT1NUtcFlEtHQmftKpqKezdkXBOLQNQ2yY6
	oqMA==
X-Gm-Message-State: ALoCoQkABlcohfJ1HHQwdqeeOvxnI11mMP3R2qtTspjFyhtFxGpS8MyQ6qdzCdxt0D4kgNlubNigxNKsyymgzp2Av11NrhSp9tQNTp+9vKGpQNlpmAYZYteKUqeGSk5pzxWLecnY9jfzi/YQqqvOFPKLPeAe5IWj7g==
X-Received: by 10.112.173.100 with SMTP id bj4mr9575823lbc.78.1415711921676;
	Tue, 11 Nov 2014 05:18:41 -0800 (PST)
X-Received: by 10.112.173.100 with SMTP id bj4mr9575813lbc.78.1415711921606;
	Tue, 11 Nov 2014 05:18:41 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id rd3sm3537637lbc.27.2014.11.11.05.18.40
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:40 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:24 +0200
Message-Id: <1415711911-1807-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 03/10] xen/arm: add dom0_op hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 will be used by xen-cpufreq driver
to upload CPUs PM data from Kernel to Xen.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 arch/arm/include/asm/xen/hypercall.h | 1 +
 arch/arm/xen/enlighten.c             | 1 +
 arch/arm/xen/hypercall.S             | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 751869eb..383c174 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_dom0_op(void *arg);
 int HYPERVISOR_sysctl(void *arg);
 
 static inline void
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 675f17a..f757c57 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index a1276df..99e2254 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
+HYPERCALL1(dom0_op);
 HYPERCALL1(sysctl);
 
 ENTRY(privcmd_call)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLN-000755-Rw; Tue, 11 Nov 2014 13:18:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLM-00072Q-C4
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:48 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	C4/D9-24124-7BC02645; Tue, 11 Nov 2014 13:18:47 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415711923!11762294!1
X-Originating-IP: [64.18.0.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4460 invoked from network); 11 Nov 2014 13:18:45 -0000
Received: from exprod5og126.obsmtp.com (HELO exprod5og126.obsmtp.com)
	(64.18.0.251)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:45 -0000
Received: from mail-lb0-f182.google.com ([209.85.217.182]) (using TLSv1) by
	exprod5ob126.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMsweZda1K68ASQFfhZ6SQYeb3I0x6@postini.com;
	Tue, 11 Nov 2014 05:18:45 PST
Received: by mail-lb0-f182.google.com with SMTP id f15so8198683lbj.41
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=ZYYjPj7rgMzkF810wyCXzGzqCRzKR2IiIFE5K5+qcE8=;
	b=I4pZ9L0AB+udn+nrrRHRVavVdf4P5/Oxf20LJu8ymS2wpvijVunL64iyDDQ3thBK0j
	M+yOgR9bS3tfcBUKAPKgZQHAcBP2UHkWpa4bxjl9MnhFGmYRmDoWUWe5LH9EnhsGpKfX
	keJvs+7HfbgLnuLlixy0c1OQHHMGJEbFRiXyY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=ZYYjPj7rgMzkF810wyCXzGzqCRzKR2IiIFE5K5+qcE8=;
	b=MFqQMlUyTlBdg05cVdXkcS4E8dOqFNKDyMaIF1nCC7QEyDFbHPpa0G9eFipbh2Y0zg
	woT2PqmmssKr77Nwq4OizNLxQIGzOCWkLVz7zLuDj+QfklS8wAfsJrBS+r2wgx54Ww46
	AdWunE5+IT5bS0OmoVZ3c5UjAqsVpu2JXolZV2/bd8asLQ1f8Pdh/nLwiBxQ92THgNnb
	cVG6v3TnMPE0lgQnZejqSoOzTtwyN6OO3MtVh00TbGw/3BA/lumeFMuUS7W5FRo9Papk
	0rzBcMWW/23pomZtWij/wjv2ZHthH7MyytT1NUtcFlEtHQmftKpqKezdkXBOLQNQ2yY6
	oqMA==
X-Gm-Message-State: ALoCoQkABlcohfJ1HHQwdqeeOvxnI11mMP3R2qtTspjFyhtFxGpS8MyQ6qdzCdxt0D4kgNlubNigxNKsyymgzp2Av11NrhSp9tQNTp+9vKGpQNlpmAYZYteKUqeGSk5pzxWLecnY9jfzi/YQqqvOFPKLPeAe5IWj7g==
X-Received: by 10.112.173.100 with SMTP id bj4mr9575823lbc.78.1415711921676;
	Tue, 11 Nov 2014 05:18:41 -0800 (PST)
X-Received: by 10.112.173.100 with SMTP id bj4mr9575813lbc.78.1415711921606;
	Tue, 11 Nov 2014 05:18:41 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id rd3sm3537637lbc.27.2014.11.11.05.18.40
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:40 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:24 +0200
Message-Id: <1415711911-1807-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 03/10] xen/arm: add dom0_op hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 will be used by xen-cpufreq driver
to upload CPUs PM data from Kernel to Xen.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 arch/arm/include/asm/xen/hypercall.h | 1 +
 arch/arm/xen/enlighten.c             | 1 +
 arch/arm/xen/hypercall.S             | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 751869eb..383c174 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_dom0_op(void *arg);
 int HYPERVISOR_sysctl(void *arg);
 
 static inline void
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 675f17a..f757c57 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -350,5 +350,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index a1276df..99e2254 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
+HYPERCALL1(dom0_op);
 HYPERCALL1(sysctl);
 
 ENTRY(privcmd_call)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLO-00076H-F3; Tue, 11 Nov 2014 13:18:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLN-00073s-9c
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:49 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	8E/34-25714-8BC02645; Tue, 11 Nov 2014 13:18:48 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415711925!4197905!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8871 invoked from network); 11 Nov 2014 13:18:47 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:47 -0000
Received: from mail-la0-f51.google.com ([209.85.215.51]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMtUy8r8fmUwPcZgVGd3eLHVIw/uch@postini.com;
	Tue, 11 Nov 2014 05:18:47 PST
Received: by mail-la0-f51.google.com with SMTP id q1so9442552lam.24
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=gKTFGR/vD2gQW4H3yYfKSHBCATxgsx2Eusf3gNw/PG4=;
	b=YAKNOOy4lh2yHJqIMEU8KUHvcnXL+ATxx8m5BkprAkxULWnHuziHSP7X4Tz7vYc5Do
	SRv5BR3E6GVi7nCJC+38MYYOPWRtNFl18YxGZCyeSP7695y+Rh+0SEKlK9Y9adOr/HJt
	iQkcXka7K3DKcCeI+LPvJ8ASgMt/M3SR6WPtk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=gKTFGR/vD2gQW4H3yYfKSHBCATxgsx2Eusf3gNw/PG4=;
	b=iPw51ztv3mGs59KXNKzSybE6SxfJnKKOm+N7t+cHfdY6Iy+14fh8K0yZKql4zBzFO7
	PxKTRxQ3xkn9vksQ/k8DGxuyu3PMIDLNG7M7ac7Gxv/7vHeDi+wOXkU25KLvLOorAMzN
	Xm+a4EBo2TYKqTd6lBbMqh09+xTAR7rd4UYA3TE766SSpQ3KVTplYMTi/xK5cvmoQKmZ
	+DoU1EbhKeX1YWjYRuclJhZVU3iNRG4YqG9Jok3uCD3JPEGsH72tlWrfQjvUywNToiER
	CgPAfBk2GtgzzDPQVz7F70qQzPZE5oMkfZKCHafvlxsGPK2IZRXQkRqYxa4S9knrAdXz
	TjYg==
X-Gm-Message-State: ALoCoQnsk62emuXxCIcn7k5hi7AxHPqMef3YA15F2sbvO6G/7al20+Qv06o0AuR8z3AerJB9yTgMy4m38iP6CMwjVZ9KVV/VdkYLuE+yCxXS3FUZ/2zQOm6EOUEK92SOhPb9W7P2dF3qD+ZaLSvhmLeDNyfS0h7FWA==
X-Received: by 10.112.133.138 with SMTP id pc10mr36348596lbb.48.1415711923893; 
	Tue, 11 Nov 2014 05:18:43 -0800 (PST)
X-Received: by 10.112.133.138 with SMTP id pc10mr36348587lbb.48.1415711923836; 
	Tue, 11 Nov 2014 05:18:43 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id pr7sm5980319lbc.18.2014.11.11.05.18.42
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:43 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:25 +0200
Message-Id: <1415711911-1807-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 04/10] docs: Xen ARM DT bindings:
	document pcpus property
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 Documentation/devicetree/bindings/arm/xen.txt | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..1d7aea3 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,11 +15,29 @@ the following properties:
 - interrupts: the interrupt used by Xen to inject event notifications.
   A GIC node is also required.
 
+- pcpus: this property is optional. It contains an information about physical
+  CPUs. This information is used by xen-cpufreq driver. The structure of
+  nodes which are inside of this property is the same as in the /cpus/ node.
 
-Example (assuming #address-cells = <2> and #size-cells = <2>):
+Xen also copies all properties from cpus/ node to the hypervisor/pcpus/ node
+in the device tree which is created for the hwdom in case if HAS_HWDOM_CPUFREQ
+config is defined.
+
+Example (assuming #address-cells = <2> and #size-cells = <2>) whith pcpus
+property:
 
 hypervisor {
 	compatible = "xen,xen-4.3", "xen,xen";
 	reg = <0 0xb0000000 0 0x20000>;
 	interrupts = <1 15 0xf08>;
+	pcpus {
+		cpu@0 {
+			device_type = "cpu";
+			reg = <0>;
+		};
+		cpu@1 {
+			device_type = "cpu";
+			reg = <1>;
+		};
+	};
 };
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLO-00076H-F3; Tue, 11 Nov 2014 13:18:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLN-00073s-9c
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:49 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	8E/34-25714-8BC02645; Tue, 11 Nov 2014 13:18:48 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415711925!4197905!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8871 invoked from network); 11 Nov 2014 13:18:47 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:47 -0000
Received: from mail-la0-f51.google.com ([209.85.215.51]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMtUy8r8fmUwPcZgVGd3eLHVIw/uch@postini.com;
	Tue, 11 Nov 2014 05:18:47 PST
Received: by mail-la0-f51.google.com with SMTP id q1so9442552lam.24
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=gKTFGR/vD2gQW4H3yYfKSHBCATxgsx2Eusf3gNw/PG4=;
	b=YAKNOOy4lh2yHJqIMEU8KUHvcnXL+ATxx8m5BkprAkxULWnHuziHSP7X4Tz7vYc5Do
	SRv5BR3E6GVi7nCJC+38MYYOPWRtNFl18YxGZCyeSP7695y+Rh+0SEKlK9Y9adOr/HJt
	iQkcXka7K3DKcCeI+LPvJ8ASgMt/M3SR6WPtk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=gKTFGR/vD2gQW4H3yYfKSHBCATxgsx2Eusf3gNw/PG4=;
	b=iPw51ztv3mGs59KXNKzSybE6SxfJnKKOm+N7t+cHfdY6Iy+14fh8K0yZKql4zBzFO7
	PxKTRxQ3xkn9vksQ/k8DGxuyu3PMIDLNG7M7ac7Gxv/7vHeDi+wOXkU25KLvLOorAMzN
	Xm+a4EBo2TYKqTd6lBbMqh09+xTAR7rd4UYA3TE766SSpQ3KVTplYMTi/xK5cvmoQKmZ
	+DoU1EbhKeX1YWjYRuclJhZVU3iNRG4YqG9Jok3uCD3JPEGsH72tlWrfQjvUywNToiER
	CgPAfBk2GtgzzDPQVz7F70qQzPZE5oMkfZKCHafvlxsGPK2IZRXQkRqYxa4S9knrAdXz
	TjYg==
X-Gm-Message-State: ALoCoQnsk62emuXxCIcn7k5hi7AxHPqMef3YA15F2sbvO6G/7al20+Qv06o0AuR8z3AerJB9yTgMy4m38iP6CMwjVZ9KVV/VdkYLuE+yCxXS3FUZ/2zQOm6EOUEK92SOhPb9W7P2dF3qD+ZaLSvhmLeDNyfS0h7FWA==
X-Received: by 10.112.133.138 with SMTP id pc10mr36348596lbb.48.1415711923893; 
	Tue, 11 Nov 2014 05:18:43 -0800 (PST)
X-Received: by 10.112.133.138 with SMTP id pc10mr36348587lbb.48.1415711923836; 
	Tue, 11 Nov 2014 05:18:43 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id pr7sm5980319lbc.18.2014.11.11.05.18.42
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:43 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:25 +0200
Message-Id: <1415711911-1807-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 04/10] docs: Xen ARM DT bindings:
	document pcpus property
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 Documentation/devicetree/bindings/arm/xen.txt | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..1d7aea3 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,11 +15,29 @@ the following properties:
 - interrupts: the interrupt used by Xen to inject event notifications.
   A GIC node is also required.
 
+- pcpus: this property is optional. It contains an information about physical
+  CPUs. This information is used by xen-cpufreq driver. The structure of
+  nodes which are inside of this property is the same as in the /cpus/ node.
 
-Example (assuming #address-cells = <2> and #size-cells = <2>):
+Xen also copies all properties from cpus/ node to the hypervisor/pcpus/ node
+in the device tree which is created for the hwdom in case if HAS_HWDOM_CPUFREQ
+config is defined.
+
+Example (assuming #address-cells = <2> and #size-cells = <2>) whith pcpus
+property:
 
 hypervisor {
 	compatible = "xen,xen-4.3", "xen,xen";
 	reg = <0 0xb0000000 0 0x20000>;
 	interrupts = <1 15 0xf08>;
+	pcpus {
+		cpu@0 {
+			device_type = "cpu";
+			reg = <0>;
+		};
+		cpu@1 {
+			device_type = "cpu";
+			reg = <1>;
+		};
+	};
 };
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13: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 1XoBLR-0007B9-V0; Tue, 11 Nov 2014 13:18:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLQ-00078d-9l
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:52 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	A9/E5-22737-BBC02645; Tue, 11 Nov 2014 13:18:51 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415711928!11762312!1
X-Originating-IP: [64.18.0.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5382 invoked from network); 11 Nov 2014 13:18:50 -0000
Received: from exprod5og118.obsmtp.com (HELO exprod5og118.obsmtp.com)
	(64.18.0.160)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:50 -0000
Received: from mail-lb0-f181.google.com ([209.85.217.181]) (using TLSv1) by
	exprod5ob118.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMuAmD0Zh2HR04A4nLNVO/u1jTzKlV@postini.com;
	Tue, 11 Nov 2014 05:18:50 PST
Received: by mail-lb0-f181.google.com with SMTP id l4so7516905lbv.26
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=t5qiHalss/9a65Pk5bbi/DKUmx++7BV0i7nCWcSRafo=;
	b=M8hiUKhZLYN6dSdygOBbE0JwOZmgTtDWba5WdbqU7Rtdul/9zLb3IPHJLwucyrI9ul
	5tKVvJvkFoxQLdZvs2E4IfkWbLarsE+4WIkj8an6I9nd8/7W/Iz4gSowwIwL3cMpB2UT
	sCvAqR9crys0P+Foa77OFfd0HrSYWVY5fgcf0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=t5qiHalss/9a65Pk5bbi/DKUmx++7BV0i7nCWcSRafo=;
	b=NVOvOQ9LTqiCQdA/6F9nMpTCrssokrOAsbg1C/ASCkMg+yW0SkE31PA3HA0IECCMqs
	g5oPgJ5yOAanLhzBhql700gb+ekFwSwDMnpj+WW+g3FOJa0x3ZlmJzWvAgtFqcegS+2r
	KkGJfazqYYq4T0WVZ+4T4R1m5BPQtmYE6ENaAsXpQuKqO5X8NwBOqsR/14uz+659GI25
	EDjV36WWx++J1tvCrfFjvcs8aDFxewZpV7EtACiV2sX1FlolIPDW/iBt6H746piahcNw
	If2PYMtLA4sY/msdEcWQURj+oPkc/4Wa/FUm/CW0ueX1KUEColw+jFjdv4eC/W2IIFFc
	dbLw==
X-Gm-Message-State: ALoCoQnNtUsWJaa6DXp61+vUPo9hyW/gzgK0dycNMLAfwPmWzlQ59VmO/jqWRIClsOFXJZPmqpDSMOs+pBUseye2CVUEu2S8GmncAI0l56Qbn2mYXeKLII9tyANOqLqlCFbqJzQS5uPoGyJjAAPoXMi2TF6AeQIJtw==
X-Received: by 10.112.189.10 with SMTP id ge10mr35783723lbc.23.1415711926746; 
	Tue, 11 Nov 2014 05:18:46 -0800 (PST)
X-Received: by 10.112.189.10 with SMTP id ge10mr35783710lbc.23.1415711926694; 
	Tue, 11 Nov 2014 05:18:46 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id kg9sm5969698lbc.45.2014.11.11.05.18.45
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:45 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:26 +0200
Message-Id: <1415711911-1807-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 05/10] cpufreq: cpufreq-cpu0: change cpus
	data path in devtree for hwdom kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hypervisor creates standard cpus nodes for virtual cpus.
All information needed for this driver about physical cpus
now located in /hypervisor/pcpus node instead of the
/cpus node in case if kernel is running as hardware domain.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/cpufreq-cpu0.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ef4fbc4..356a439 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -21,6 +21,8 @@
 #include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 
+#include <xen/xen.h>
+
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
 
@@ -182,7 +184,11 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 	struct device_node *np;
 	int ret;
 
-	np = of_find_node_by_path("/cpus/cpu@0");
+	if (xen_initial_domain())
+		np = of_find_node_by_path("/hypervisor/pcpus/cpu@0");
+	else
+		np = of_find_node_by_path("/cpus/cpu@0");
+
 	if (!np) {
 		pr_err("failed to find cpu0 node\n");
 		return -ENOENT;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13: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 1XoBLR-0007B9-V0; Tue, 11 Nov 2014 13:18:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLQ-00078d-9l
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:52 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	A9/E5-22737-BBC02645; Tue, 11 Nov 2014 13:18:51 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415711928!11762312!1
X-Originating-IP: [64.18.0.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5382 invoked from network); 11 Nov 2014 13:18:50 -0000
Received: from exprod5og118.obsmtp.com (HELO exprod5og118.obsmtp.com)
	(64.18.0.160)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:50 -0000
Received: from mail-lb0-f181.google.com ([209.85.217.181]) (using TLSv1) by
	exprod5ob118.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMuAmD0Zh2HR04A4nLNVO/u1jTzKlV@postini.com;
	Tue, 11 Nov 2014 05:18:50 PST
Received: by mail-lb0-f181.google.com with SMTP id l4so7516905lbv.26
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=t5qiHalss/9a65Pk5bbi/DKUmx++7BV0i7nCWcSRafo=;
	b=M8hiUKhZLYN6dSdygOBbE0JwOZmgTtDWba5WdbqU7Rtdul/9zLb3IPHJLwucyrI9ul
	5tKVvJvkFoxQLdZvs2E4IfkWbLarsE+4WIkj8an6I9nd8/7W/Iz4gSowwIwL3cMpB2UT
	sCvAqR9crys0P+Foa77OFfd0HrSYWVY5fgcf0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=t5qiHalss/9a65Pk5bbi/DKUmx++7BV0i7nCWcSRafo=;
	b=NVOvOQ9LTqiCQdA/6F9nMpTCrssokrOAsbg1C/ASCkMg+yW0SkE31PA3HA0IECCMqs
	g5oPgJ5yOAanLhzBhql700gb+ekFwSwDMnpj+WW+g3FOJa0x3ZlmJzWvAgtFqcegS+2r
	KkGJfazqYYq4T0WVZ+4T4R1m5BPQtmYE6ENaAsXpQuKqO5X8NwBOqsR/14uz+659GI25
	EDjV36WWx++J1tvCrfFjvcs8aDFxewZpV7EtACiV2sX1FlolIPDW/iBt6H746piahcNw
	If2PYMtLA4sY/msdEcWQURj+oPkc/4Wa/FUm/CW0ueX1KUEColw+jFjdv4eC/W2IIFFc
	dbLw==
X-Gm-Message-State: ALoCoQnNtUsWJaa6DXp61+vUPo9hyW/gzgK0dycNMLAfwPmWzlQ59VmO/jqWRIClsOFXJZPmqpDSMOs+pBUseye2CVUEu2S8GmncAI0l56Qbn2mYXeKLII9tyANOqLqlCFbqJzQS5uPoGyJjAAPoXMi2TF6AeQIJtw==
X-Received: by 10.112.189.10 with SMTP id ge10mr35783723lbc.23.1415711926746; 
	Tue, 11 Nov 2014 05:18:46 -0800 (PST)
X-Received: by 10.112.189.10 with SMTP id ge10mr35783710lbc.23.1415711926694; 
	Tue, 11 Nov 2014 05:18:46 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id kg9sm5969698lbc.45.2014.11.11.05.18.45
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:45 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:26 +0200
Message-Id: <1415711911-1807-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 05/10] cpufreq: cpufreq-cpu0: change cpus
	data path in devtree for hwdom kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hypervisor creates standard cpus nodes for virtual cpus.
All information needed for this driver about physical cpus
now located in /hypervisor/pcpus node instead of the
/cpus node in case if kernel is running as hardware domain.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/cpufreq-cpu0.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ef4fbc4..356a439 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -21,6 +21,8 @@
 #include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 
+#include <xen/xen.h>
+
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
 
@@ -182,7 +184,11 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 	struct device_node *np;
 	int ret;
 
-	np = of_find_node_by_path("/cpus/cpu@0");
+	if (xen_initial_domain())
+		np = of_find_node_by_path("/hypervisor/pcpus/cpu@0");
+	else
+		np = of_find_node_by_path("/cpus/cpu@0");
+
 	if (!np) {
 		pr_err("failed to find cpu0 node\n");
 		return -ENOENT;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLW-0007Gh-CX; Tue, 11 Nov 2014 13:18:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLU-0007E4-I6
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:56 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	7A/43-03148-FBC02645; Tue, 11 Nov 2014 13:18:55 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415711931!11817272!1
X-Originating-IP: [64.18.0.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16185 invoked from network); 11 Nov 2014 13:18:53 -0000
Received: from exprod5og110.obsmtp.com (HELO exprod5og110.obsmtp.com)
	(64.18.0.20)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:53 -0000
Received: from mail-lb0-f180.google.com ([209.85.217.180]) (using TLSv1) by
	exprod5ob110.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMu9v8Te6wqNJVD7QBRKNI6wgPDnUx@postini.com;
	Tue, 11 Nov 2014 05:18:53 PST
Received: by mail-lb0-f180.google.com with SMTP id z11so825924lbi.39
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=gVJwFOtiAwX5Z9Bpr0eyVz/DyuTpkwU8Hw+q47XTq+s=;
	b=Rs0+T+7vXFWPmKvkLS6isHoMIYlnZKdBqYbIzo1lZeNH+WvEKvH8jRCGClXAiJSvmb
	/95ADkGJ0FgcOJ503KUbd2eMTb3cBvS4c27ZrGfIFVGdjgC1MaaDVLSmaFMHWX8PjfQv
	aOmVdDqFgvv6hcMQm4sAQcHdyn2PLpjNgtMIA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=gVJwFOtiAwX5Z9Bpr0eyVz/DyuTpkwU8Hw+q47XTq+s=;
	b=M+aLGvtMDn7Vbli0ovsTCoLo7ptU4wZ2O/YII1Z2L94gJkMjT5sNVYWYxo9QJ/+sdS
	l4OTPImbV3cbQLYC5a5ByPLF4/dHmRB5kWsrInInnvRYafCn+0FawvWjaR9tBvW6e/xf
	/+e4Pe1liFz8Mtay01cOTQmgroBj+3sEqQNHIXHSN/T0O1IEGTogjIDnQURUSq3gPHLf
	d2qYIs7FkbOLQbGiOwz/JobRKKceHe+pLSF6mkNaq5yZ/MHxt1n7LbvtiojCg3ruGayd
	Vn7OnoTtC/8gMwsM9o9oHa2uDAeIOi670goRZpU5D2s9cjODXjGHEi3LrswkTO/VbTNj
	tyQg==
X-Gm-Message-State: ALoCoQkrXZrqtl4Fk3obqgEklrz5VQ+OMkFBu8XbtE/peEvEkNi/X7fxwbPgI+cL9Q9hty/S3BTSZ5aTopK9zPPXUrWNNHvRY/ezAWOTjRMIGGaUsOCydVVmcKUZXTy3pr5Ep+2wWOd6cf9dbvGkBFGbDgNYCmmheg==
X-Received: by 10.112.135.197 with SMTP id pu5mr36116054lbb.22.1415711929784; 
	Tue, 11 Nov 2014 05:18:49 -0800 (PST)
X-Received: by 10.112.135.197 with SMTP id pu5mr36116039lbb.22.1415711929713; 
	Tue, 11 Nov 2014 05:18:49 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id s5sm2795072laa.9.2014.11.11.05.18.48
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:48 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:27 +0200
Message-Id: <1415711911-1807-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 06/10] cpufreq: introduce cpufreq_drv_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch allows to use more than one high-level
cpufreq driver. This patch is needed for implementation
xen-based high-level cpufreq driver.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/Kconfig            |   4 +
 drivers/cpufreq/Makefile           |   1 +
 drivers/cpufreq/acpi-cpufreq.c     |   5 +-
 drivers/cpufreq/cpufreq.c          | 116 ++++++++++++-----------
 drivers/cpufreq/cpufreq_drv_ops.c  | 187 +++++++++++++++++++++++++++++++++++++
 drivers/cpufreq/cpufreq_drv_ops.h  |  50 ++++++++++
 drivers/cpufreq/cpufreq_governor.c |   4 +-
 include/linux/cpufreq.h            |   2 +-
 8 files changed, 312 insertions(+), 57 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index cbcb21e..42a1aed 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -1,7 +1,11 @@
 menu "CPU Frequency scaling"
 
+config CPUFREQ_DRV_OPS
+	bool
+
 config CPU_FREQ
 	bool "CPU Frequency scaling"
+	select CPUFREQ_DRV_OPS
 	help
 	  CPU Frequency scaling allows you to change the clock speed of 
 	  CPUs on the fly. This is a nice method to save power, because 
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index fadc4d4..f12a0d3 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -1,5 +1,6 @@
 # CPUfreq core
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
+obj-$(CONFIG_CPUFREQ_DRV_OPS)		+= cpufreq_drv_ops.o
 # CPUfreq stats
 obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
 
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 7b0d49d..2c2a33f 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -950,7 +950,8 @@ static void __init acpi_cpufreq_boost_init(void)
 	/* We create the boost file in any case, though for systems without
 	 * hardware support it will be read-only and hardwired to return 0.
 	 */
-	if (sysfs_create_file(cpufreq_global_kobject, &(global_boost.attr)))
+	if (sysfs_create_file(get_cpufreq_global_kobject(),
+			      &(global_boost.attr)))
 		pr_warn(PFX "could not register global boost sysfs file\n");
 	else
 		pr_debug("registered global boost sysfs file\n");
@@ -958,7 +959,7 @@ static void __init acpi_cpufreq_boost_init(void)
 
 static void __exit acpi_cpufreq_boost_exit(void)
 {
-	sysfs_remove_file(cpufreq_global_kobject, &(global_boost.attr));
+	sysfs_remove_file(get_cpufreq_global_kobject(), &(global_boost.attr));
 
 	if (msrs) {
 		unregister_cpu_notifier(&boost_nb);
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6ed3c13..1b24bc3e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -33,6 +33,7 @@
 #include <linux/syscore_ops.h>
 
 #include <trace/events/power.h>
+#include "cpufreq_drv_ops.h"
 
 /**
  * The "cpufreq driver" - the arch- or hardware-dependent low
@@ -178,11 +179,10 @@ err_out:
 	return NULL;
 }
 
-struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+struct cpufreq_policy *kern_cpufreq_cpu_get(unsigned int cpu)
 {
 	return __cpufreq_cpu_get(cpu, false);
 }
-EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
 
 static struct cpufreq_policy *cpufreq_cpu_get_sysfs(unsigned int cpu)
 {
@@ -196,11 +196,10 @@ static void __cpufreq_cpu_put(struct cpufreq_policy *data, bool sysfs)
 	module_put(cpufreq_driver->owner);
 }
 
-void cpufreq_cpu_put(struct cpufreq_policy *data)
+void kern_cpufreq_cpu_put(struct cpufreq_policy *data)
 {
 	__cpufreq_cpu_put(data, false);
 }
-EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
 
 static void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data)
 {
@@ -258,7 +257,8 @@ static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
  * function. It is called twice on all CPU frequency changes that have
  * external effects.
  */
-void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
+void kern_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
+				    unsigned int state)
 {
 	struct cpufreq_policy *policy;
 
@@ -303,9 +303,6 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
 		break;
 	}
 }
-EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
-
-
 
 /*********************************************************************
  *                          SYSFS INTERFACE                          *
@@ -628,7 +625,10 @@ static struct attribute *default_attrs[] = {
 };
 
 struct kobject *cpufreq_global_kobject;
-EXPORT_SYMBOL(cpufreq_global_kobject);
+struct kobject *get_kern_cpufreq_global_kobject(void)
+{
+	return cpufreq_global_kobject;
+}
 
 #define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
 #define to_attr(a) container_of(a, struct freq_attr, attr)
@@ -1214,7 +1214,7 @@ static void cpufreq_out_of_sync(unsigned int cpu, unsigned int old_freq,
  * This is the last known freq, without actually getting it from the driver.
  * Return value will be same as what is shown in scaling_cur_freq in sysfs.
  */
-unsigned int cpufreq_quick_get(unsigned int cpu)
+unsigned int kern_cpufreq_quick_get(unsigned int cpu)
 {
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
 	unsigned int ret_freq = 0;
@@ -1226,7 +1226,7 @@ unsigned int cpufreq_quick_get(unsigned int cpu)
 
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_quick_get);
+EXPORT_SYMBOL(kern_cpufreq_quick_get);
 
 /**
  * cpufreq_quick_get_max - get the max reported CPU frequency for this CPU
@@ -1234,7 +1234,7 @@ EXPORT_SYMBOL(cpufreq_quick_get);
  *
  * Just return the max possible frequency for a given CPU.
  */
-unsigned int cpufreq_quick_get_max(unsigned int cpu)
+unsigned int kern_cpufreq_quick_get_max(unsigned int cpu)
 {
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
 	unsigned int ret_freq = 0;
@@ -1246,7 +1246,7 @@ unsigned int cpufreq_quick_get_max(unsigned int cpu)
 
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_quick_get_max);
+EXPORT_SYMBOL(kern_cpufreq_quick_get_max);
 
 
 static unsigned int __cpufreq_get(unsigned int cpu)
@@ -1278,7 +1278,7 @@ static unsigned int __cpufreq_get(unsigned int cpu)
  *
  * Get the CPU current (static) CPU frequency
  */
-unsigned int cpufreq_get(unsigned int cpu)
+unsigned int kern_cpufreq_get(unsigned int cpu)
 {
 	unsigned int ret_freq = 0;
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
@@ -1298,7 +1298,7 @@ out_policy:
 out:
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_get);
+EXPORT_SYMBOL(kern_cpufreq_get);
 
 static struct subsys_interface cpufreq_interface = {
 	.name		= "cpufreq",
@@ -1387,26 +1387,25 @@ static struct syscore_ops cpufreq_syscore_ops = {
 };
 
 /**
- *	cpufreq_get_current_driver - return current driver's name
+ *	kern_cpufreq_get_current_driver - return current driver's name
  *
  *	Return the name string of the currently loaded cpufreq driver
  *	or NULL, if none.
  */
-const char *cpufreq_get_current_driver(void)
+const char *kern_cpufreq_get_current_driver(void)
 {
 	if (cpufreq_driver)
 		return cpufreq_driver->name;
 
 	return NULL;
 }
-EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
 
 /*********************************************************************
  *                     NOTIFIER LISTS INTERFACE                      *
  *********************************************************************/
 
 /**
- *	cpufreq_register_notifier - register a driver with cpufreq
+ *	kern_cpufreq_register_notifier - register a driver with cpufreq
  *	@nb: notifier function to register
  *      @list: CPUFREQ_TRANSITION_NOTIFIER or CPUFREQ_POLICY_NOTIFIER
  *
@@ -1418,7 +1417,7 @@ EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
  *	This function may sleep, and has the same return conditions as
  *	blocking_notifier_chain_register.
  */
-int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
+int kern_cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
 {
 	int ret;
 
@@ -1439,11 +1438,11 @@ int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_register_notifier);
+EXPORT_SYMBOL(kern_cpufreq_register_notifier);
 
 
 /**
- *	cpufreq_unregister_notifier - unregister a driver with cpufreq
+ *	kern_cpufreq_unregister_notifier - unregister a driver with cpufreq
  *	@nb: notifier block to be unregistered
  *      @list: CPUFREQ_TRANSITION_NOTIFIER or CPUFREQ_POLICY_NOTIFIER
  *
@@ -1452,7 +1451,8 @@ EXPORT_SYMBOL(cpufreq_register_notifier);
  *	This function may sleep, and has the same return conditions as
  *	blocking_notifier_chain_unregister.
  */
-int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
+int kern_cpufreq_unregister_notifier(struct notifier_block *nb,
+				     unsigned int list)
 {
 	int ret;
 
@@ -1471,7 +1471,7 @@ int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_unregister_notifier);
+EXPORT_SYMBOL(kern_cpufreq_unregister_notifier);
 
 
 /*********************************************************************
@@ -1479,7 +1479,7 @@ EXPORT_SYMBOL(cpufreq_unregister_notifier);
  *********************************************************************/
 
 
-int __cpufreq_driver_target(struct cpufreq_policy *policy,
+int __kern_cpufreq_driver_target(struct cpufreq_policy *policy,
 			    unsigned int target_freq,
 			    unsigned int relation)
 {
@@ -1506,9 +1506,8 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
 
 	return retval;
 }
-EXPORT_SYMBOL_GPL(__cpufreq_driver_target);
 
-int cpufreq_driver_target(struct cpufreq_policy *policy,
+int kern_cpufreq_driver_target(struct cpufreq_policy *policy,
 			  unsigned int target_freq,
 			  unsigned int relation)
 {
@@ -1530,9 +1529,9 @@ fail:
 no_policy:
 	return ret;
 }
-EXPORT_SYMBOL_GPL(cpufreq_driver_target);
 
-int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
+int __kern_cpufreq_driver_getavg(struct cpufreq_policy *policy,
+				 unsigned int cpu)
 {
 	int ret = 0;
 
@@ -1548,7 +1547,6 @@ int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
 	cpufreq_cpu_put(policy);
 	return ret;
 }
-EXPORT_SYMBOL_GPL(__cpufreq_driver_getavg);
 
 /*
  * when "event" is CPUFREQ_GOV_LIMITS
@@ -1602,7 +1600,7 @@ static int __cpufreq_governor(struct cpufreq_policy *policy,
 }
 
 
-int cpufreq_register_governor(struct cpufreq_governor *governor)
+int kern_cpufreq_register_governor(struct cpufreq_governor *governor)
 {
 	int err;
 
@@ -1623,10 +1621,8 @@ int cpufreq_register_governor(struct cpufreq_governor *governor)
 	mutex_unlock(&cpufreq_governor_mutex);
 	return err;
 }
-EXPORT_SYMBOL_GPL(cpufreq_register_governor);
-
 
-void cpufreq_unregister_governor(struct cpufreq_governor *governor)
+void kern_cpufreq_unregister_governor(struct cpufreq_governor *governor)
 {
 #ifdef CONFIG_HOTPLUG_CPU
 	int cpu;
@@ -1652,22 +1648,19 @@ void cpufreq_unregister_governor(struct cpufreq_governor *governor)
 	mutex_unlock(&cpufreq_governor_mutex);
 	return;
 }
-EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
-
-
 
 /*********************************************************************
  *                          POLICY INTERFACE                         *
  *********************************************************************/
 
 /**
- * cpufreq_get_policy - get the current cpufreq_policy
+ * kern_cpufreq_get_policy - get the current cpufreq_policy
  * @policy: struct cpufreq_policy into which the current cpufreq_policy
  *	is written
  *
  * Reads the current cpufreq policy.
  */
-int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
+int kern_cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
 {
 	struct cpufreq_policy *cpu_policy;
 	if (!policy)
@@ -1682,7 +1675,7 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
 	cpufreq_cpu_put(cpu_policy);
 	return 0;
 }
-EXPORT_SYMBOL(cpufreq_get_policy);
+EXPORT_SYMBOL(kern_cpufreq_get_policy);
 
 
 /*
@@ -1774,13 +1767,13 @@ error_out:
 }
 
 /**
- *	cpufreq_update_policy - re-evaluate an existing cpufreq policy
+ *	kern_cpufreq_update_policy - re-evaluate an existing cpufreq policy
  *	@cpu: CPU which shall be re-evaluated
  *
  *	Useful for policy notifiers which have different necessities
  *	at different times.
  */
-int cpufreq_update_policy(unsigned int cpu)
+int kern_cpufreq_update_policy(unsigned int cpu)
 {
 	struct cpufreq_policy *data = cpufreq_cpu_get(cpu);
 	struct cpufreq_policy policy;
@@ -1826,7 +1819,7 @@ fail:
 no_policy:
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_update_policy);
+EXPORT_SYMBOL(kern_cpufreq_update_policy);
 
 static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb,
 					unsigned long action, void *hcpu)
@@ -1866,7 +1859,7 @@ static struct notifier_block __refdata cpufreq_cpu_notifier = {
  *********************************************************************/
 
 /**
- * cpufreq_register_driver - register a CPU Frequency driver
+ * kern_cpufreq_register_driver - register a CPU Frequency driver
  * @driver_data: A struct cpufreq_driver containing the values#
  * submitted by the CPU Frequency driver.
  *
@@ -1875,7 +1868,7 @@ static struct notifier_block __refdata cpufreq_cpu_notifier = {
  * (and isn't unregistered in the meantime).
  *
  */
-int cpufreq_register_driver(struct cpufreq_driver *driver_data)
+int kern_cpufreq_register_driver(struct cpufreq_driver *driver_data)
 {
 	unsigned long flags;
 	int ret;
@@ -1935,18 +1928,16 @@ err_null_driver:
 	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
 	return ret;
 }
-EXPORT_SYMBOL_GPL(cpufreq_register_driver);
-
 
 /**
- * cpufreq_unregister_driver - unregister the current CPUFreq driver
+ * kern_cpufreq_unregister_driver - unregister the current CPUFreq driver
  *
  *    Unregister the current CPUFreq driver. Only call this if you have
  * the right to do so, i.e. if you have succeeded in initialising before!
  * Returns zero if successful, and -EINVAL if the cpufreq_driver is
  * currently not initialised.
  */
-int cpufreq_unregister_driver(struct cpufreq_driver *driver)
+int kern_cpufreq_unregister_driver(struct cpufreq_driver *driver)
 {
 	unsigned long flags;
 
@@ -1964,9 +1955,30 @@ int cpufreq_unregister_driver(struct cpufreq_driver *driver)
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
 
-static int __init cpufreq_core_init(void)
+struct cpufreq_drv_ops kern_cpufreq_drv_ops = {
+	.get_global_kobject = get_kern_cpufreq_global_kobject,
+	.cpu_get = kern_cpufreq_cpu_get,
+	.cpu_put = kern_cpufreq_cpu_put,
+	.notify_transition = kern_cpufreq_notify_transition,
+	.quick_get = kern_cpufreq_quick_get,
+	.quick_get_max = kern_cpufreq_quick_get_max,
+	.get = kern_cpufreq_get,
+	.register_notifier = kern_cpufreq_register_notifier,
+	.unregister_notifier = kern_cpufreq_unregister_notifier,
+	.get_current_driver = kern_cpufreq_get_current_driver,
+	.__driver_target = __kern_cpufreq_driver_target,
+	.driver_target = kern_cpufreq_driver_target,
+	.__driver_getavg = __kern_cpufreq_driver_getavg,
+	.register_governor = kern_cpufreq_register_governor,
+	.unregister_governor = kern_cpufreq_unregister_governor,
+	.get_policy = kern_cpufreq_get_policy,
+	.update_policy = kern_cpufreq_update_policy,
+	.register_driver = kern_cpufreq_register_driver,
+	.unregister_driver = kern_cpufreq_unregister_driver,
+};
+
+static int __init kern_cpufreq_core_init(void)
 {
 	int cpu;
 
@@ -1984,4 +1996,4 @@ static int __init cpufreq_core_init(void)
 
 	return 0;
 }
-core_initcall(cpufreq_core_init);
+core_initcall(kern_cpufreq_core_init);
diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
new file mode 100644
index 0000000..c971442
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_drv_ops.c
@@ -0,0 +1,187 @@
+/*
+ *  Copyright (C) 2014 GlobalLogic 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include "cpufreq_drv_ops.h"
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/export.h>
+
+static struct cpufreq_drv_ops *ops;
+
+struct kobject *get_cpufreq_global_kobject(void)
+{
+	if (ops && ops->get_global_kobject)
+		return ops->get_global_kobject();
+	return NULL;
+}
+EXPORT_SYMBOL(get_cpufreq_global_kobject);
+
+struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+{
+	if (ops && ops->cpu_get)
+		return ops->cpu_get(cpu);
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
+
+void cpufreq_cpu_put(struct cpufreq_policy *data)
+{
+	if (ops && ops->cpu_put)
+		ops->cpu_put(data);
+}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
+
+void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
+{
+	if (ops && ops->notify_transition)
+		ops->notify_transition(freqs, state);
+}
+EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
+
+#ifdef CONFIG_CPU_FREQ
+unsigned int cpufreq_quick_get(unsigned int cpu)
+{
+	if (ops && ops->quick_get)
+		return ops->quick_get(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_quick_get);
+
+unsigned int cpufreq_quick_get_max(unsigned int cpu)
+{
+	if (ops && ops->quick_get_max)
+		return ops->quick_get_max(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_quick_get_max);
+
+unsigned int cpufreq_get(unsigned int cpu)
+{
+	if (ops && ops->get)
+		return ops->get(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_get);
+
+int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
+{
+	if (ops && ops->register_notifier)
+		return ops->register_notifier(nb, list);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_register_notifier);
+
+int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
+{
+	if (ops && ops->unregister_notifier)
+		return ops->unregister_notifier(nb, list);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_unregister_notifier);
+#endif
+
+const char *cpufreq_get_current_driver(void)
+{
+	if (ops && ops->get_current_driver)
+		return ops->get_current_driver();
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
+
+int __cpufreq_driver_target(struct cpufreq_policy *policy,
+			    unsigned int target_freq,
+			    unsigned int relation)
+{
+	if (ops && ops->__driver_target)
+		return ops->__driver_target(policy, target_freq, relation);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(__cpufreq_driver_target);
+
+int cpufreq_driver_target(struct cpufreq_policy *policy,
+			  unsigned int target_freq,
+			  unsigned int relation)
+{
+	if (ops && ops->driver_target)
+		return ops->driver_target(policy, target_freq, relation);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_driver_target);
+
+int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
+{
+	if (ops && ops->__driver_getavg)
+		return ops->__driver_getavg(policy, cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(__cpufreq_driver_getavg);
+
+int cpufreq_register_governor(struct cpufreq_governor *governor)
+{
+	if (ops && ops->register_governor)
+		return ops->register_governor(governor);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_register_governor);
+
+void cpufreq_unregister_governor(struct cpufreq_governor *governor)
+{
+	if (ops && ops->unregister_governor)
+		ops->unregister_governor(governor);
+}
+EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
+
+int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
+{
+	if (ops && ops->get_policy)
+		return ops->get_policy(policy, cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_get_policy);
+
+int cpufreq_update_policy(unsigned int cpu)
+{
+	if (ops && ops->update_policy)
+		return ops->update_policy(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_update_policy);
+
+int cpufreq_register_driver(struct cpufreq_driver *driver_data)
+{
+	if (ops && ops->register_driver)
+		return ops->register_driver(driver_data);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_register_driver);
+
+int cpufreq_unregister_driver(struct cpufreq_driver *driver)
+{
+	if (ops && ops->unregister_driver)
+		return ops->unregister_driver(driver);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
+
+static int __init cpufreq_drv_ops_init(void)
+{
+#ifdef CONFIG_CPU_FREQ
+	ops = &kern_cpufreq_drv_ops;
+	pr_debug("using kern_cpufreq_drv_ops\n");
+#endif
+
+	return 0;
+}
+core_initcall(cpufreq_drv_ops_init);
diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
new file mode 100644
index 0000000..5cc8e05
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_drv_ops.h
@@ -0,0 +1,50 @@
+/*
+ *  Copyright (C) 2014 GlobalLogic 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.
+ */
+
+#ifndef _CPUFREQ_DRV_OPS_H
+#define _CPUFREQ_DRV_OPS_H
+
+#include <linux/types.h>
+#include <linux/cpufreq.h>
+
+struct cpufreq_drv_ops {
+	struct kobject *(*get_global_kobject)(void);
+	struct cpufreq_policy *(*cpu_get)(unsigned int);
+	void (*cpu_put)(struct cpufreq_policy *);
+	void (*notify_transition)(struct cpufreq_freqs *, unsigned int);
+#ifdef CONFIG_CPU_FREQ
+	unsigned int (*quick_get)(unsigned int);
+	unsigned int (*quick_get_max)(unsigned int);
+	unsigned int (*get)(unsigned int);
+	int (*register_notifier)(struct notifier_block *, unsigned int);
+	int (*unregister_notifier)(struct notifier_block *, unsigned int);
+#endif
+	const char *(*get_current_driver)(void);
+	int (*__driver_target)(struct cpufreq_policy *,
+			       unsigned int, unsigned int);
+	int (*driver_target)(struct cpufreq_policy *,
+			     unsigned int, unsigned int);
+	int (*__driver_getavg)(struct cpufreq_policy *, unsigned int);
+	int (*register_governor)(struct cpufreq_governor *);
+	void (*unregister_governor)(struct cpufreq_governor *);
+	int (*get_policy)(struct cpufreq_policy *, unsigned int);
+	int (*update_policy)(unsigned int);
+	int (*register_driver)(struct cpufreq_driver *);
+	int (*unregister_driver)(struct cpufreq_driver *);
+};
+
+#ifdef CONFIG_CPU_FREQ
+extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
+#endif
+
+#endif /* _CPUFREQ_DRV_OPS_H */
diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 6c5f1d3..731fa0d 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -226,7 +226,7 @@ int cpufreq_governor_dbs(struct dbs_data *dbs_data,
 		if (dbs_data->enable != 1)
 			goto second_time;
 
-		rc = sysfs_create_group(cpufreq_global_kobject,
+		rc = sysfs_create_group(get_cpufreq_global_kobject(),
 				dbs_data->attr_group);
 		if (rc) {
 			mutex_unlock(&dbs_data->mutex);
@@ -291,7 +291,7 @@ second_time:
 		if (!dbs_data->enable) {
 			struct cs_ops *ops = dbs_data->gov_ops;
 
-			sysfs_remove_group(cpufreq_global_kobject,
+			sysfs_remove_group(get_cpufreq_global_kobject(),
 					dbs_data->attr_group);
 			if (dbs_data->governor == GOV_CONSERVATIVE)
 				cpufreq_unregister_notifier(ops->notifier_block,
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 3d919ea..2852bb23 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -70,7 +70,7 @@ static inline void disable_cpufreq(void) { }
 struct cpufreq_governor;
 
 /* /sys/devices/system/cpu/cpufreq: entry point for global variables */
-extern struct kobject *cpufreq_global_kobject;
+struct kobject *get_cpufreq_global_kobject(void);
 
 #define CPUFREQ_ETERNAL			(-1)
 struct cpufreq_cpuinfo {
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLW-0007Gh-CX; Tue, 11 Nov 2014 13:18:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLU-0007E4-I6
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:56 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	7A/43-03148-FBC02645; Tue, 11 Nov 2014 13:18:55 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415711931!11817272!1
X-Originating-IP: [64.18.0.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16185 invoked from network); 11 Nov 2014 13:18:53 -0000
Received: from exprod5og110.obsmtp.com (HELO exprod5og110.obsmtp.com)
	(64.18.0.20)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:53 -0000
Received: from mail-lb0-f180.google.com ([209.85.217.180]) (using TLSv1) by
	exprod5ob110.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMu9v8Te6wqNJVD7QBRKNI6wgPDnUx@postini.com;
	Tue, 11 Nov 2014 05:18:53 PST
Received: by mail-lb0-f180.google.com with SMTP id z11so825924lbi.39
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=gVJwFOtiAwX5Z9Bpr0eyVz/DyuTpkwU8Hw+q47XTq+s=;
	b=Rs0+T+7vXFWPmKvkLS6isHoMIYlnZKdBqYbIzo1lZeNH+WvEKvH8jRCGClXAiJSvmb
	/95ADkGJ0FgcOJ503KUbd2eMTb3cBvS4c27ZrGfIFVGdjgC1MaaDVLSmaFMHWX8PjfQv
	aOmVdDqFgvv6hcMQm4sAQcHdyn2PLpjNgtMIA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=gVJwFOtiAwX5Z9Bpr0eyVz/DyuTpkwU8Hw+q47XTq+s=;
	b=M+aLGvtMDn7Vbli0ovsTCoLo7ptU4wZ2O/YII1Z2L94gJkMjT5sNVYWYxo9QJ/+sdS
	l4OTPImbV3cbQLYC5a5ByPLF4/dHmRB5kWsrInInnvRYafCn+0FawvWjaR9tBvW6e/xf
	/+e4Pe1liFz8Mtay01cOTQmgroBj+3sEqQNHIXHSN/T0O1IEGTogjIDnQURUSq3gPHLf
	d2qYIs7FkbOLQbGiOwz/JobRKKceHe+pLSF6mkNaq5yZ/MHxt1n7LbvtiojCg3ruGayd
	Vn7OnoTtC/8gMwsM9o9oHa2uDAeIOi670goRZpU5D2s9cjODXjGHEi3LrswkTO/VbTNj
	tyQg==
X-Gm-Message-State: ALoCoQkrXZrqtl4Fk3obqgEklrz5VQ+OMkFBu8XbtE/peEvEkNi/X7fxwbPgI+cL9Q9hty/S3BTSZ5aTopK9zPPXUrWNNHvRY/ezAWOTjRMIGGaUsOCydVVmcKUZXTy3pr5Ep+2wWOd6cf9dbvGkBFGbDgNYCmmheg==
X-Received: by 10.112.135.197 with SMTP id pu5mr36116054lbb.22.1415711929784; 
	Tue, 11 Nov 2014 05:18:49 -0800 (PST)
X-Received: by 10.112.135.197 with SMTP id pu5mr36116039lbb.22.1415711929713; 
	Tue, 11 Nov 2014 05:18:49 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id s5sm2795072laa.9.2014.11.11.05.18.48
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:48 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:27 +0200
Message-Id: <1415711911-1807-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 06/10] cpufreq: introduce cpufreq_drv_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch allows to use more than one high-level
cpufreq driver. This patch is needed for implementation
xen-based high-level cpufreq driver.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/Kconfig            |   4 +
 drivers/cpufreq/Makefile           |   1 +
 drivers/cpufreq/acpi-cpufreq.c     |   5 +-
 drivers/cpufreq/cpufreq.c          | 116 ++++++++++++-----------
 drivers/cpufreq/cpufreq_drv_ops.c  | 187 +++++++++++++++++++++++++++++++++++++
 drivers/cpufreq/cpufreq_drv_ops.h  |  50 ++++++++++
 drivers/cpufreq/cpufreq_governor.c |   4 +-
 include/linux/cpufreq.h            |   2 +-
 8 files changed, 312 insertions(+), 57 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index cbcb21e..42a1aed 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -1,7 +1,11 @@
 menu "CPU Frequency scaling"
 
+config CPUFREQ_DRV_OPS
+	bool
+
 config CPU_FREQ
 	bool "CPU Frequency scaling"
+	select CPUFREQ_DRV_OPS
 	help
 	  CPU Frequency scaling allows you to change the clock speed of 
 	  CPUs on the fly. This is a nice method to save power, because 
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index fadc4d4..f12a0d3 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -1,5 +1,6 @@
 # CPUfreq core
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
+obj-$(CONFIG_CPUFREQ_DRV_OPS)		+= cpufreq_drv_ops.o
 # CPUfreq stats
 obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
 
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 7b0d49d..2c2a33f 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -950,7 +950,8 @@ static void __init acpi_cpufreq_boost_init(void)
 	/* We create the boost file in any case, though for systems without
 	 * hardware support it will be read-only and hardwired to return 0.
 	 */
-	if (sysfs_create_file(cpufreq_global_kobject, &(global_boost.attr)))
+	if (sysfs_create_file(get_cpufreq_global_kobject(),
+			      &(global_boost.attr)))
 		pr_warn(PFX "could not register global boost sysfs file\n");
 	else
 		pr_debug("registered global boost sysfs file\n");
@@ -958,7 +959,7 @@ static void __init acpi_cpufreq_boost_init(void)
 
 static void __exit acpi_cpufreq_boost_exit(void)
 {
-	sysfs_remove_file(cpufreq_global_kobject, &(global_boost.attr));
+	sysfs_remove_file(get_cpufreq_global_kobject(), &(global_boost.attr));
 
 	if (msrs) {
 		unregister_cpu_notifier(&boost_nb);
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6ed3c13..1b24bc3e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -33,6 +33,7 @@
 #include <linux/syscore_ops.h>
 
 #include <trace/events/power.h>
+#include "cpufreq_drv_ops.h"
 
 /**
  * The "cpufreq driver" - the arch- or hardware-dependent low
@@ -178,11 +179,10 @@ err_out:
 	return NULL;
 }
 
-struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+struct cpufreq_policy *kern_cpufreq_cpu_get(unsigned int cpu)
 {
 	return __cpufreq_cpu_get(cpu, false);
 }
-EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
 
 static struct cpufreq_policy *cpufreq_cpu_get_sysfs(unsigned int cpu)
 {
@@ -196,11 +196,10 @@ static void __cpufreq_cpu_put(struct cpufreq_policy *data, bool sysfs)
 	module_put(cpufreq_driver->owner);
 }
 
-void cpufreq_cpu_put(struct cpufreq_policy *data)
+void kern_cpufreq_cpu_put(struct cpufreq_policy *data)
 {
 	__cpufreq_cpu_put(data, false);
 }
-EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
 
 static void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data)
 {
@@ -258,7 +257,8 @@ static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
  * function. It is called twice on all CPU frequency changes that have
  * external effects.
  */
-void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
+void kern_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
+				    unsigned int state)
 {
 	struct cpufreq_policy *policy;
 
@@ -303,9 +303,6 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
 		break;
 	}
 }
-EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
-
-
 
 /*********************************************************************
  *                          SYSFS INTERFACE                          *
@@ -628,7 +625,10 @@ static struct attribute *default_attrs[] = {
 };
 
 struct kobject *cpufreq_global_kobject;
-EXPORT_SYMBOL(cpufreq_global_kobject);
+struct kobject *get_kern_cpufreq_global_kobject(void)
+{
+	return cpufreq_global_kobject;
+}
 
 #define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
 #define to_attr(a) container_of(a, struct freq_attr, attr)
@@ -1214,7 +1214,7 @@ static void cpufreq_out_of_sync(unsigned int cpu, unsigned int old_freq,
  * This is the last known freq, without actually getting it from the driver.
  * Return value will be same as what is shown in scaling_cur_freq in sysfs.
  */
-unsigned int cpufreq_quick_get(unsigned int cpu)
+unsigned int kern_cpufreq_quick_get(unsigned int cpu)
 {
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
 	unsigned int ret_freq = 0;
@@ -1226,7 +1226,7 @@ unsigned int cpufreq_quick_get(unsigned int cpu)
 
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_quick_get);
+EXPORT_SYMBOL(kern_cpufreq_quick_get);
 
 /**
  * cpufreq_quick_get_max - get the max reported CPU frequency for this CPU
@@ -1234,7 +1234,7 @@ EXPORT_SYMBOL(cpufreq_quick_get);
  *
  * Just return the max possible frequency for a given CPU.
  */
-unsigned int cpufreq_quick_get_max(unsigned int cpu)
+unsigned int kern_cpufreq_quick_get_max(unsigned int cpu)
 {
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
 	unsigned int ret_freq = 0;
@@ -1246,7 +1246,7 @@ unsigned int cpufreq_quick_get_max(unsigned int cpu)
 
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_quick_get_max);
+EXPORT_SYMBOL(kern_cpufreq_quick_get_max);
 
 
 static unsigned int __cpufreq_get(unsigned int cpu)
@@ -1278,7 +1278,7 @@ static unsigned int __cpufreq_get(unsigned int cpu)
  *
  * Get the CPU current (static) CPU frequency
  */
-unsigned int cpufreq_get(unsigned int cpu)
+unsigned int kern_cpufreq_get(unsigned int cpu)
 {
 	unsigned int ret_freq = 0;
 	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
@@ -1298,7 +1298,7 @@ out_policy:
 out:
 	return ret_freq;
 }
-EXPORT_SYMBOL(cpufreq_get);
+EXPORT_SYMBOL(kern_cpufreq_get);
 
 static struct subsys_interface cpufreq_interface = {
 	.name		= "cpufreq",
@@ -1387,26 +1387,25 @@ static struct syscore_ops cpufreq_syscore_ops = {
 };
 
 /**
- *	cpufreq_get_current_driver - return current driver's name
+ *	kern_cpufreq_get_current_driver - return current driver's name
  *
  *	Return the name string of the currently loaded cpufreq driver
  *	or NULL, if none.
  */
-const char *cpufreq_get_current_driver(void)
+const char *kern_cpufreq_get_current_driver(void)
 {
 	if (cpufreq_driver)
 		return cpufreq_driver->name;
 
 	return NULL;
 }
-EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
 
 /*********************************************************************
  *                     NOTIFIER LISTS INTERFACE                      *
  *********************************************************************/
 
 /**
- *	cpufreq_register_notifier - register a driver with cpufreq
+ *	kern_cpufreq_register_notifier - register a driver with cpufreq
  *	@nb: notifier function to register
  *      @list: CPUFREQ_TRANSITION_NOTIFIER or CPUFREQ_POLICY_NOTIFIER
  *
@@ -1418,7 +1417,7 @@ EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
  *	This function may sleep, and has the same return conditions as
  *	blocking_notifier_chain_register.
  */
-int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
+int kern_cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
 {
 	int ret;
 
@@ -1439,11 +1438,11 @@ int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_register_notifier);
+EXPORT_SYMBOL(kern_cpufreq_register_notifier);
 
 
 /**
- *	cpufreq_unregister_notifier - unregister a driver with cpufreq
+ *	kern_cpufreq_unregister_notifier - unregister a driver with cpufreq
  *	@nb: notifier block to be unregistered
  *      @list: CPUFREQ_TRANSITION_NOTIFIER or CPUFREQ_POLICY_NOTIFIER
  *
@@ -1452,7 +1451,8 @@ EXPORT_SYMBOL(cpufreq_register_notifier);
  *	This function may sleep, and has the same return conditions as
  *	blocking_notifier_chain_unregister.
  */
-int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
+int kern_cpufreq_unregister_notifier(struct notifier_block *nb,
+				     unsigned int list)
 {
 	int ret;
 
@@ -1471,7 +1471,7 @@ int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_unregister_notifier);
+EXPORT_SYMBOL(kern_cpufreq_unregister_notifier);
 
 
 /*********************************************************************
@@ -1479,7 +1479,7 @@ EXPORT_SYMBOL(cpufreq_unregister_notifier);
  *********************************************************************/
 
 
-int __cpufreq_driver_target(struct cpufreq_policy *policy,
+int __kern_cpufreq_driver_target(struct cpufreq_policy *policy,
 			    unsigned int target_freq,
 			    unsigned int relation)
 {
@@ -1506,9 +1506,8 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
 
 	return retval;
 }
-EXPORT_SYMBOL_GPL(__cpufreq_driver_target);
 
-int cpufreq_driver_target(struct cpufreq_policy *policy,
+int kern_cpufreq_driver_target(struct cpufreq_policy *policy,
 			  unsigned int target_freq,
 			  unsigned int relation)
 {
@@ -1530,9 +1529,9 @@ fail:
 no_policy:
 	return ret;
 }
-EXPORT_SYMBOL_GPL(cpufreq_driver_target);
 
-int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
+int __kern_cpufreq_driver_getavg(struct cpufreq_policy *policy,
+				 unsigned int cpu)
 {
 	int ret = 0;
 
@@ -1548,7 +1547,6 @@ int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
 	cpufreq_cpu_put(policy);
 	return ret;
 }
-EXPORT_SYMBOL_GPL(__cpufreq_driver_getavg);
 
 /*
  * when "event" is CPUFREQ_GOV_LIMITS
@@ -1602,7 +1600,7 @@ static int __cpufreq_governor(struct cpufreq_policy *policy,
 }
 
 
-int cpufreq_register_governor(struct cpufreq_governor *governor)
+int kern_cpufreq_register_governor(struct cpufreq_governor *governor)
 {
 	int err;
 
@@ -1623,10 +1621,8 @@ int cpufreq_register_governor(struct cpufreq_governor *governor)
 	mutex_unlock(&cpufreq_governor_mutex);
 	return err;
 }
-EXPORT_SYMBOL_GPL(cpufreq_register_governor);
-
 
-void cpufreq_unregister_governor(struct cpufreq_governor *governor)
+void kern_cpufreq_unregister_governor(struct cpufreq_governor *governor)
 {
 #ifdef CONFIG_HOTPLUG_CPU
 	int cpu;
@@ -1652,22 +1648,19 @@ void cpufreq_unregister_governor(struct cpufreq_governor *governor)
 	mutex_unlock(&cpufreq_governor_mutex);
 	return;
 }
-EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
-
-
 
 /*********************************************************************
  *                          POLICY INTERFACE                         *
  *********************************************************************/
 
 /**
- * cpufreq_get_policy - get the current cpufreq_policy
+ * kern_cpufreq_get_policy - get the current cpufreq_policy
  * @policy: struct cpufreq_policy into which the current cpufreq_policy
  *	is written
  *
  * Reads the current cpufreq policy.
  */
-int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
+int kern_cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
 {
 	struct cpufreq_policy *cpu_policy;
 	if (!policy)
@@ -1682,7 +1675,7 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
 	cpufreq_cpu_put(cpu_policy);
 	return 0;
 }
-EXPORT_SYMBOL(cpufreq_get_policy);
+EXPORT_SYMBOL(kern_cpufreq_get_policy);
 
 
 /*
@@ -1774,13 +1767,13 @@ error_out:
 }
 
 /**
- *	cpufreq_update_policy - re-evaluate an existing cpufreq policy
+ *	kern_cpufreq_update_policy - re-evaluate an existing cpufreq policy
  *	@cpu: CPU which shall be re-evaluated
  *
  *	Useful for policy notifiers which have different necessities
  *	at different times.
  */
-int cpufreq_update_policy(unsigned int cpu)
+int kern_cpufreq_update_policy(unsigned int cpu)
 {
 	struct cpufreq_policy *data = cpufreq_cpu_get(cpu);
 	struct cpufreq_policy policy;
@@ -1826,7 +1819,7 @@ fail:
 no_policy:
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_update_policy);
+EXPORT_SYMBOL(kern_cpufreq_update_policy);
 
 static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb,
 					unsigned long action, void *hcpu)
@@ -1866,7 +1859,7 @@ static struct notifier_block __refdata cpufreq_cpu_notifier = {
  *********************************************************************/
 
 /**
- * cpufreq_register_driver - register a CPU Frequency driver
+ * kern_cpufreq_register_driver - register a CPU Frequency driver
  * @driver_data: A struct cpufreq_driver containing the values#
  * submitted by the CPU Frequency driver.
  *
@@ -1875,7 +1868,7 @@ static struct notifier_block __refdata cpufreq_cpu_notifier = {
  * (and isn't unregistered in the meantime).
  *
  */
-int cpufreq_register_driver(struct cpufreq_driver *driver_data)
+int kern_cpufreq_register_driver(struct cpufreq_driver *driver_data)
 {
 	unsigned long flags;
 	int ret;
@@ -1935,18 +1928,16 @@ err_null_driver:
 	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
 	return ret;
 }
-EXPORT_SYMBOL_GPL(cpufreq_register_driver);
-
 
 /**
- * cpufreq_unregister_driver - unregister the current CPUFreq driver
+ * kern_cpufreq_unregister_driver - unregister the current CPUFreq driver
  *
  *    Unregister the current CPUFreq driver. Only call this if you have
  * the right to do so, i.e. if you have succeeded in initialising before!
  * Returns zero if successful, and -EINVAL if the cpufreq_driver is
  * currently not initialised.
  */
-int cpufreq_unregister_driver(struct cpufreq_driver *driver)
+int kern_cpufreq_unregister_driver(struct cpufreq_driver *driver)
 {
 	unsigned long flags;
 
@@ -1964,9 +1955,30 @@ int cpufreq_unregister_driver(struct cpufreq_driver *driver)
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
 
-static int __init cpufreq_core_init(void)
+struct cpufreq_drv_ops kern_cpufreq_drv_ops = {
+	.get_global_kobject = get_kern_cpufreq_global_kobject,
+	.cpu_get = kern_cpufreq_cpu_get,
+	.cpu_put = kern_cpufreq_cpu_put,
+	.notify_transition = kern_cpufreq_notify_transition,
+	.quick_get = kern_cpufreq_quick_get,
+	.quick_get_max = kern_cpufreq_quick_get_max,
+	.get = kern_cpufreq_get,
+	.register_notifier = kern_cpufreq_register_notifier,
+	.unregister_notifier = kern_cpufreq_unregister_notifier,
+	.get_current_driver = kern_cpufreq_get_current_driver,
+	.__driver_target = __kern_cpufreq_driver_target,
+	.driver_target = kern_cpufreq_driver_target,
+	.__driver_getavg = __kern_cpufreq_driver_getavg,
+	.register_governor = kern_cpufreq_register_governor,
+	.unregister_governor = kern_cpufreq_unregister_governor,
+	.get_policy = kern_cpufreq_get_policy,
+	.update_policy = kern_cpufreq_update_policy,
+	.register_driver = kern_cpufreq_register_driver,
+	.unregister_driver = kern_cpufreq_unregister_driver,
+};
+
+static int __init kern_cpufreq_core_init(void)
 {
 	int cpu;
 
@@ -1984,4 +1996,4 @@ static int __init cpufreq_core_init(void)
 
 	return 0;
 }
-core_initcall(cpufreq_core_init);
+core_initcall(kern_cpufreq_core_init);
diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
new file mode 100644
index 0000000..c971442
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_drv_ops.c
@@ -0,0 +1,187 @@
+/*
+ *  Copyright (C) 2014 GlobalLogic 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include "cpufreq_drv_ops.h"
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/export.h>
+
+static struct cpufreq_drv_ops *ops;
+
+struct kobject *get_cpufreq_global_kobject(void)
+{
+	if (ops && ops->get_global_kobject)
+		return ops->get_global_kobject();
+	return NULL;
+}
+EXPORT_SYMBOL(get_cpufreq_global_kobject);
+
+struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+{
+	if (ops && ops->cpu_get)
+		return ops->cpu_get(cpu);
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
+
+void cpufreq_cpu_put(struct cpufreq_policy *data)
+{
+	if (ops && ops->cpu_put)
+		ops->cpu_put(data);
+}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
+
+void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
+{
+	if (ops && ops->notify_transition)
+		ops->notify_transition(freqs, state);
+}
+EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
+
+#ifdef CONFIG_CPU_FREQ
+unsigned int cpufreq_quick_get(unsigned int cpu)
+{
+	if (ops && ops->quick_get)
+		return ops->quick_get(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_quick_get);
+
+unsigned int cpufreq_quick_get_max(unsigned int cpu)
+{
+	if (ops && ops->quick_get_max)
+		return ops->quick_get_max(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_quick_get_max);
+
+unsigned int cpufreq_get(unsigned int cpu)
+{
+	if (ops && ops->get)
+		return ops->get(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_get);
+
+int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
+{
+	if (ops && ops->register_notifier)
+		return ops->register_notifier(nb, list);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_register_notifier);
+
+int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list)
+{
+	if (ops && ops->unregister_notifier)
+		return ops->unregister_notifier(nb, list);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_unregister_notifier);
+#endif
+
+const char *cpufreq_get_current_driver(void)
+{
+	if (ops && ops->get_current_driver)
+		return ops->get_current_driver();
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(cpufreq_get_current_driver);
+
+int __cpufreq_driver_target(struct cpufreq_policy *policy,
+			    unsigned int target_freq,
+			    unsigned int relation)
+{
+	if (ops && ops->__driver_target)
+		return ops->__driver_target(policy, target_freq, relation);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(__cpufreq_driver_target);
+
+int cpufreq_driver_target(struct cpufreq_policy *policy,
+			  unsigned int target_freq,
+			  unsigned int relation)
+{
+	if (ops && ops->driver_target)
+		return ops->driver_target(policy, target_freq, relation);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_driver_target);
+
+int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
+{
+	if (ops && ops->__driver_getavg)
+		return ops->__driver_getavg(policy, cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(__cpufreq_driver_getavg);
+
+int cpufreq_register_governor(struct cpufreq_governor *governor)
+{
+	if (ops && ops->register_governor)
+		return ops->register_governor(governor);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_register_governor);
+
+void cpufreq_unregister_governor(struct cpufreq_governor *governor)
+{
+	if (ops && ops->unregister_governor)
+		ops->unregister_governor(governor);
+}
+EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
+
+int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
+{
+	if (ops && ops->get_policy)
+		return ops->get_policy(policy, cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_get_policy);
+
+int cpufreq_update_policy(unsigned int cpu)
+{
+	if (ops && ops->update_policy)
+		return ops->update_policy(cpu);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(cpufreq_update_policy);
+
+int cpufreq_register_driver(struct cpufreq_driver *driver_data)
+{
+	if (ops && ops->register_driver)
+		return ops->register_driver(driver_data);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_register_driver);
+
+int cpufreq_unregister_driver(struct cpufreq_driver *driver)
+{
+	if (ops && ops->unregister_driver)
+		return ops->unregister_driver(driver);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
+
+static int __init cpufreq_drv_ops_init(void)
+{
+#ifdef CONFIG_CPU_FREQ
+	ops = &kern_cpufreq_drv_ops;
+	pr_debug("using kern_cpufreq_drv_ops\n");
+#endif
+
+	return 0;
+}
+core_initcall(cpufreq_drv_ops_init);
diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
new file mode 100644
index 0000000..5cc8e05
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_drv_ops.h
@@ -0,0 +1,50 @@
+/*
+ *  Copyright (C) 2014 GlobalLogic 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.
+ */
+
+#ifndef _CPUFREQ_DRV_OPS_H
+#define _CPUFREQ_DRV_OPS_H
+
+#include <linux/types.h>
+#include <linux/cpufreq.h>
+
+struct cpufreq_drv_ops {
+	struct kobject *(*get_global_kobject)(void);
+	struct cpufreq_policy *(*cpu_get)(unsigned int);
+	void (*cpu_put)(struct cpufreq_policy *);
+	void (*notify_transition)(struct cpufreq_freqs *, unsigned int);
+#ifdef CONFIG_CPU_FREQ
+	unsigned int (*quick_get)(unsigned int);
+	unsigned int (*quick_get_max)(unsigned int);
+	unsigned int (*get)(unsigned int);
+	int (*register_notifier)(struct notifier_block *, unsigned int);
+	int (*unregister_notifier)(struct notifier_block *, unsigned int);
+#endif
+	const char *(*get_current_driver)(void);
+	int (*__driver_target)(struct cpufreq_policy *,
+			       unsigned int, unsigned int);
+	int (*driver_target)(struct cpufreq_policy *,
+			     unsigned int, unsigned int);
+	int (*__driver_getavg)(struct cpufreq_policy *, unsigned int);
+	int (*register_governor)(struct cpufreq_governor *);
+	void (*unregister_governor)(struct cpufreq_governor *);
+	int (*get_policy)(struct cpufreq_policy *, unsigned int);
+	int (*update_policy)(unsigned int);
+	int (*register_driver)(struct cpufreq_driver *);
+	int (*unregister_driver)(struct cpufreq_driver *);
+};
+
+#ifdef CONFIG_CPU_FREQ
+extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
+#endif
+
+#endif /* _CPUFREQ_DRV_OPS_H */
diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 6c5f1d3..731fa0d 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -226,7 +226,7 @@ int cpufreq_governor_dbs(struct dbs_data *dbs_data,
 		if (dbs_data->enable != 1)
 			goto second_time;
 
-		rc = sysfs_create_group(cpufreq_global_kobject,
+		rc = sysfs_create_group(get_cpufreq_global_kobject(),
 				dbs_data->attr_group);
 		if (rc) {
 			mutex_unlock(&dbs_data->mutex);
@@ -291,7 +291,7 @@ second_time:
 		if (!dbs_data->enable) {
 			struct cs_ops *ops = dbs_data->gov_ops;
 
-			sysfs_remove_group(cpufreq_global_kobject,
+			sysfs_remove_group(get_cpufreq_global_kobject(),
 					dbs_data->attr_group);
 			if (dbs_data->governor == GOV_CONSERVATIVE)
 				cpufreq_unregister_notifier(ops->notifier_block,
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 3d919ea..2852bb23 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -70,7 +70,7 @@ static inline void disable_cpufreq(void) { }
 struct cpufreq_governor;
 
 /* /sys/devices/system/cpu/cpufreq: entry point for global variables */
-extern struct kobject *cpufreq_global_kobject;
+struct kobject *get_cpufreq_global_kobject(void);
 
 #define CPUFREQ_ETERNAL			(-1)
 struct cpufreq_cpuinfo {
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLW-0007HT-Qq; Tue, 11 Nov 2014 13:18:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLU-0007Ec-Uz
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	89/E4-09842-0CC02645; Tue, 11 Nov 2014 13:18:56 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415711933!11887300!1
X-Originating-IP: [64.18.0.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21224 invoked from network); 11 Nov 2014 13:18:55 -0000
Received: from exprod5og117.obsmtp.com (HELO exprod5og117.obsmtp.com)
	(64.18.0.149)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:55 -0000
Received: from mail-lb0-f182.google.com ([209.85.217.182]) (using TLSv1) by
	exprod5ob117.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMvWDeYRywqUnOC3DLTM/fK2VDgknG@postini.com;
	Tue, 11 Nov 2014 05:18:55 PST
Received: by mail-lb0-f182.google.com with SMTP id f15so8413855lbj.27
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=g3prLPODM12AnRCU2EXsG1/H2DA+fj+tOLcjTNgvWYg=;
	b=Ja4Mx8U+GzpKliQjiJODRTXbcfFobODtMcqZnJzK1QU+cC+OnGZe/V9oygwYs16MvG
	nqxOx9EXCI8ujN1v8dsDcojxlMAY6EWF6XVUA5vaRTPgbAIqn5TyZR/+HbAmllJln8m/
	qDc33gAQfoxFnUiwpVngYl/tRSOamZsKOxj4Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=g3prLPODM12AnRCU2EXsG1/H2DA+fj+tOLcjTNgvWYg=;
	b=XvkN5r5GmWqNBAwST20MnVA5uhQBzkEmbCwd6OLS4SSlL5pgae1KG95NVUsY7ZGRUw
	MN98eqiN3aYUlmJ49+PsoRVk/kraYXpBwuQEEiif6K//AJPGP+0QuV2wpxyErSL5uhCj
	ruHeVMZ7eWUCjbKCk6Izj8rXSJ0CBIo50EWJ9GPEP+4LKvfxKcx6W4nGDiJsVjICTlEK
	QFVIkABshSsMTR9NyDc5UnzpXSDXM6TOMSpSclC+Nksjkmib2Naid6leucZAiQmkRvyb
	PUgZNo7KtHuY04vg5xIOpuY81hzR7InCCZKOPqGbIuWu+LJic+rXo9hi89FF6/oUp/Ib
	2wxw==
X-Gm-Message-State: ALoCoQkrkrGYE7wo5kpU0Jop+iaqTSyHBiGLBvj0hJr3moS8TEBs6fDrke79bvp+5IFPtSGG7dHDG4Eayi7pxOv9zdoBRggS3NEza9l/8W8ZFDdZv6aLtrndlwCC0yW27nfKh3JlKePORNzN8uZPQKUD63yFLP1Hxw==
X-Received: by 10.112.56.134 with SMTP id a6mr36389024lbq.25.1415711932044;
	Tue, 11 Nov 2014 05:18:52 -0800 (PST)
X-Received: by 10.112.56.134 with SMTP id a6mr36389016lbq.25.1415711931992;
	Tue, 11 Nov 2014 05:18:51 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id k10sm5960469lae.42.2014.11.11.05.18.50
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:51 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:28 +0200
Message-Id: <1415711911-1807-8-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 07/10] cpufreq: make cpufreq low-level
	drivers visible for CPUFREQ_DRV_OPS config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Low-level cpufreq drivers should depend from CPUFREQ_DRV_OPS
config instead of the CPU_FREQ config in case if we want
to use additional high-level cpufreq driver. This patch
is needed for implementation xen-based high-level cpufreq
driver.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/Makefile        |  2 +-
 drivers/cpufreq/Kconfig | 16 ++++++++++++----
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index f8c79ae..58ef715 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -107,7 +107,7 @@ obj-$(CONFIG_ISDN)		+= isdn/
 obj-$(CONFIG_EDAC)		+= edac/
 obj-$(CONFIG_EISA)		+= eisa/
 obj-y				+= lguest/
-obj-$(CONFIG_CPU_FREQ)		+= cpufreq/
+obj-$(CONFIG_CPUFREQ_DRV_OPS)	+= cpufreq/
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle/
 obj-y				+= mmc/
 obj-$(CONFIG_MEMSTICK)		+= memstick/
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 42a1aed..f5a8f84 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -19,14 +19,11 @@ config CPU_FREQ
 
 	  If in doubt, say N.
 
-if CPU_FREQ
+if CPUFREQ_DRV_OPS
 
 config CPU_FREQ_TABLE
 	tristate
 
-config CPU_FREQ_GOV_COMMON
-	bool
-
 config CPU_FREQ_STAT
 	tristate "CPU frequency translation statistics"
 	select CPU_FREQ_TABLE
@@ -49,6 +46,13 @@ config CPU_FREQ_STAT_DETAILS
 
 	  If in doubt, say N.
 
+endif
+
+if CPU_FREQ
+
+config CPU_FREQ_GOV_COMMON
+	bool
+
 choice
 	prompt "Default CPUFreq governor"
 	default CPU_FREQ_DEFAULT_GOV_USERSPACE if CPU_FREQ_SA1100 || CPU_FREQ_SA1110
@@ -188,6 +192,10 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 	  If in doubt, say N.
 
+endif
+
+if CPUFREQ_DRV_OPS
+
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
 	depends on HAVE_CLK && REGULATOR && PM_OPP && OF
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:18:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLW-0007HT-Qq; Tue, 11 Nov 2014 13:18:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLU-0007Ec-Uz
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:18:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	89/E4-09842-0CC02645; Tue, 11 Nov 2014 13:18:56 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415711933!11887300!1
X-Originating-IP: [64.18.0.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21224 invoked from network); 11 Nov 2014 13:18:55 -0000
Received: from exprod5og117.obsmtp.com (HELO exprod5og117.obsmtp.com)
	(64.18.0.149)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:18:55 -0000
Received: from mail-lb0-f182.google.com ([209.85.217.182]) (using TLSv1) by
	exprod5ob117.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMvWDeYRywqUnOC3DLTM/fK2VDgknG@postini.com;
	Tue, 11 Nov 2014 05:18:55 PST
Received: by mail-lb0-f182.google.com with SMTP id f15so8413855lbj.27
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=g3prLPODM12AnRCU2EXsG1/H2DA+fj+tOLcjTNgvWYg=;
	b=Ja4Mx8U+GzpKliQjiJODRTXbcfFobODtMcqZnJzK1QU+cC+OnGZe/V9oygwYs16MvG
	nqxOx9EXCI8ujN1v8dsDcojxlMAY6EWF6XVUA5vaRTPgbAIqn5TyZR/+HbAmllJln8m/
	qDc33gAQfoxFnUiwpVngYl/tRSOamZsKOxj4Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=g3prLPODM12AnRCU2EXsG1/H2DA+fj+tOLcjTNgvWYg=;
	b=XvkN5r5GmWqNBAwST20MnVA5uhQBzkEmbCwd6OLS4SSlL5pgae1KG95NVUsY7ZGRUw
	MN98eqiN3aYUlmJ49+PsoRVk/kraYXpBwuQEEiif6K//AJPGP+0QuV2wpxyErSL5uhCj
	ruHeVMZ7eWUCjbKCk6Izj8rXSJ0CBIo50EWJ9GPEP+4LKvfxKcx6W4nGDiJsVjICTlEK
	QFVIkABshSsMTR9NyDc5UnzpXSDXM6TOMSpSclC+Nksjkmib2Naid6leucZAiQmkRvyb
	PUgZNo7KtHuY04vg5xIOpuY81hzR7InCCZKOPqGbIuWu+LJic+rXo9hi89FF6/oUp/Ib
	2wxw==
X-Gm-Message-State: ALoCoQkrkrGYE7wo5kpU0Jop+iaqTSyHBiGLBvj0hJr3moS8TEBs6fDrke79bvp+5IFPtSGG7dHDG4Eayi7pxOv9zdoBRggS3NEza9l/8W8ZFDdZv6aLtrndlwCC0yW27nfKh3JlKePORNzN8uZPQKUD63yFLP1Hxw==
X-Received: by 10.112.56.134 with SMTP id a6mr36389024lbq.25.1415711932044;
	Tue, 11 Nov 2014 05:18:52 -0800 (PST)
X-Received: by 10.112.56.134 with SMTP id a6mr36389016lbq.25.1415711931992;
	Tue, 11 Nov 2014 05:18:51 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id k10sm5960469lae.42.2014.11.11.05.18.50
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:51 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:28 +0200
Message-Id: <1415711911-1807-8-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 07/10] cpufreq: make cpufreq low-level
	drivers visible for CPUFREQ_DRV_OPS config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Low-level cpufreq drivers should depend from CPUFREQ_DRV_OPS
config instead of the CPU_FREQ config in case if we want
to use additional high-level cpufreq driver. This patch
is needed for implementation xen-based high-level cpufreq
driver.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/Makefile        |  2 +-
 drivers/cpufreq/Kconfig | 16 ++++++++++++----
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index f8c79ae..58ef715 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -107,7 +107,7 @@ obj-$(CONFIG_ISDN)		+= isdn/
 obj-$(CONFIG_EDAC)		+= edac/
 obj-$(CONFIG_EISA)		+= eisa/
 obj-y				+= lguest/
-obj-$(CONFIG_CPU_FREQ)		+= cpufreq/
+obj-$(CONFIG_CPUFREQ_DRV_OPS)	+= cpufreq/
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle/
 obj-y				+= mmc/
 obj-$(CONFIG_MEMSTICK)		+= memstick/
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 42a1aed..f5a8f84 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -19,14 +19,11 @@ config CPU_FREQ
 
 	  If in doubt, say N.
 
-if CPU_FREQ
+if CPUFREQ_DRV_OPS
 
 config CPU_FREQ_TABLE
 	tristate
 
-config CPU_FREQ_GOV_COMMON
-	bool
-
 config CPU_FREQ_STAT
 	tristate "CPU frequency translation statistics"
 	select CPU_FREQ_TABLE
@@ -49,6 +46,13 @@ config CPU_FREQ_STAT_DETAILS
 
 	  If in doubt, say N.
 
+endif
+
+if CPU_FREQ
+
+config CPU_FREQ_GOV_COMMON
+	bool
+
 choice
 	prompt "Default CPUFreq governor"
 	default CPU_FREQ_DEFAULT_GOV_USERSPACE if CPU_FREQ_SA1100 || CPU_FREQ_SA1110
@@ -188,6 +192,10 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 	  If in doubt, say N.
 
+endif
+
+if CPUFREQ_DRV_OPS
+
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
 	depends on HAVE_CLK && REGULATOR && PM_OPP && OF
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:19:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:19:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLa-0007MK-L3; Tue, 11 Nov 2014 13:19:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLY-0007JK-9T
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:19:00 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	49/32-31453-3CC02645; Tue, 11 Nov 2014 13:18:59 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415711936!8892523!1
X-Originating-IP: [64.18.0.147]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23173 invoked from network); 11 Nov 2014 13:18:58 -0000
Received: from exprod5og116.obsmtp.com (HELO exprod5og116.obsmtp.com)
	(64.18.0.147)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 13:18:58 -0000
Received: from mail-la0-f43.google.com ([209.85.215.43]) (using TLSv1) by
	exprod5ob116.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMwPAAAUzlpsVC86Eix/HK6JnymOAQ@postini.com;
	Tue, 11 Nov 2014 05:18:58 PST
Received: by mail-la0-f43.google.com with SMTP id ge10so9531469lab.2
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=2lWxv/IYXGTI+wgv1DsxE1jqIBJ2pWdROXVXMtDoLq4=;
	b=ksWqglaKSsVrJHmK346xWyY5fC5yC1b3N7XNFhxb/bcCfcMaSPin9yGjuimog76qFt
	o6/AaJLlmHaxmVY0B2B/+j/0Th0XpZ4xVnJGaK+jYnqYdlw0JIkpHVtHJhxy2gFJMkjm
	FC/E9lk0jRctc4wKlGYEj07QcppZgd5pD0wS4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=2lWxv/IYXGTI+wgv1DsxE1jqIBJ2pWdROXVXMtDoLq4=;
	b=G/w/ZdxYgm1Tk/RqUaXyqUBx/K5NzJxl5H2eygmYCZkKVrcrOydF4RsHncwY3EkWOS
	y1m579O1HHw2IXq8V/wPMRsby4Jll3nCGXy/JZyKAq0BwSp5DCF94Y1dK40uOOl0hWzt
	MCEebSlC4YNITS+j9AnDz79VjKb846qieqq/t4NHNM4zC05oOp7vpXaoEoQGHNJeR41E
	tv9JG0KnHrwcg+stgbCHZ4QGu4N/d0Yh8p9euBTJCzi405xN3/C+XsgPbNI0nrlLEwn1
	TPKmyP4KeniF6icc2uz7NKOn+e4iJZ8g9ir3UGjICLkoVr/SIniGH26fgxv0AzrCDx+X
	FfVQ==
X-Gm-Message-State: ALoCoQk6wxgQ4Q0XYTADujc4pWuLDNdhtJrNNky4brxBICEaHNub9EVyRYTL2YyUVUTqSfTVb9ij37G/bV3aJVjQaCdO3zrNbBnDigLJW2cOSWZ1nmAEBqhSFODV9DgoAEnuxvoPdfHaaVB8bCHGx+mXKS5p2FN2Hg==
X-Received: by 10.112.150.71 with SMTP id ug7mr10895011lbb.73.1415711934951;
	Tue, 11 Nov 2014 05:18:54 -0800 (PST)
X-Received: by 10.112.150.71 with SMTP id ug7mr10895001lbb.73.1415711934895;
	Tue, 11 Nov 2014 05:18:54 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id t6sm5978508lbb.23.2014.11.11.05.18.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:54 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:29 +0200
Message-Id: <1415711911-1807-9-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 08/10] xen: arm: add cpufreq shared info
	definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This shared info will be used by xen-cpufreq driver
to receive commands from the cpufreq driver in xen.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 arch/arm/include/asm/xen/interface.h | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index acf4b7a..e189977 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -56,8 +56,21 @@ DEFINE_GUEST_HANDLE(xen_ulong_t);
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
 
+#define CPUFREQ_CMD_idle		0
+#define CPUFREQ_CMD_change_freq		1
+
+struct cpufreq_sh_info {
+	uint32_t cmd;       /* CPUFREQ_CMD_* */
+	uint32_t cpu;       /* Physical CPU number */
+	uint32_t freq;      /* Frequency in KHz */
+	uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
+	int32_t result;     /* Returned result of the operation */
+};
+
 struct arch_vcpu_info { };
-struct arch_shared_info { };
+struct arch_shared_info {
+	struct cpufreq_sh_info cpufreq;
+};
 
 /* TODO: Move pvclock definitions some place arch independent */
 struct pvclock_vcpu_time_info {
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:19:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:19:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBLa-0007MK-L3; Tue, 11 Nov 2014 13:19:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLY-0007JK-9T
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:19:00 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	49/32-31453-3CC02645; Tue, 11 Nov 2014 13:18:59 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415711936!8892523!1
X-Originating-IP: [64.18.0.147]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23173 invoked from network); 11 Nov 2014 13:18:58 -0000
Received: from exprod5og116.obsmtp.com (HELO exprod5og116.obsmtp.com)
	(64.18.0.147)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 13:18:58 -0000
Received: from mail-la0-f43.google.com ([209.85.215.43]) (using TLSv1) by
	exprod5ob116.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMwPAAAUzlpsVC86Eix/HK6JnymOAQ@postini.com;
	Tue, 11 Nov 2014 05:18:58 PST
Received: by mail-la0-f43.google.com with SMTP id ge10so9531469lab.2
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=2lWxv/IYXGTI+wgv1DsxE1jqIBJ2pWdROXVXMtDoLq4=;
	b=ksWqglaKSsVrJHmK346xWyY5fC5yC1b3N7XNFhxb/bcCfcMaSPin9yGjuimog76qFt
	o6/AaJLlmHaxmVY0B2B/+j/0Th0XpZ4xVnJGaK+jYnqYdlw0JIkpHVtHJhxy2gFJMkjm
	FC/E9lk0jRctc4wKlGYEj07QcppZgd5pD0wS4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=2lWxv/IYXGTI+wgv1DsxE1jqIBJ2pWdROXVXMtDoLq4=;
	b=G/w/ZdxYgm1Tk/RqUaXyqUBx/K5NzJxl5H2eygmYCZkKVrcrOydF4RsHncwY3EkWOS
	y1m579O1HHw2IXq8V/wPMRsby4Jll3nCGXy/JZyKAq0BwSp5DCF94Y1dK40uOOl0hWzt
	MCEebSlC4YNITS+j9AnDz79VjKb846qieqq/t4NHNM4zC05oOp7vpXaoEoQGHNJeR41E
	tv9JG0KnHrwcg+stgbCHZ4QGu4N/d0Yh8p9euBTJCzi405xN3/C+XsgPbNI0nrlLEwn1
	TPKmyP4KeniF6icc2uz7NKOn+e4iJZ8g9ir3UGjICLkoVr/SIniGH26fgxv0AzrCDx+X
	FfVQ==
X-Gm-Message-State: ALoCoQk6wxgQ4Q0XYTADujc4pWuLDNdhtJrNNky4brxBICEaHNub9EVyRYTL2YyUVUTqSfTVb9ij37G/bV3aJVjQaCdO3zrNbBnDigLJW2cOSWZ1nmAEBqhSFODV9DgoAEnuxvoPdfHaaVB8bCHGx+mXKS5p2FN2Hg==
X-Received: by 10.112.150.71 with SMTP id ug7mr10895011lbb.73.1415711934951;
	Tue, 11 Nov 2014 05:18:54 -0800 (PST)
X-Received: by 10.112.150.71 with SMTP id ug7mr10895001lbb.73.1415711934895;
	Tue, 11 Nov 2014 05:18:54 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id t6sm5978508lbb.23.2014.11.11.05.18.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:54 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:29 +0200
Message-Id: <1415711911-1807-9-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 08/10] xen: arm: add cpufreq shared info
	definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This shared info will be used by xen-cpufreq driver
to receive commands from the cpufreq driver in xen.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 arch/arm/include/asm/xen/interface.h | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index acf4b7a..e189977 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -56,8 +56,21 @@ DEFINE_GUEST_HANDLE(xen_ulong_t);
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
 
+#define CPUFREQ_CMD_idle		0
+#define CPUFREQ_CMD_change_freq		1
+
+struct cpufreq_sh_info {
+	uint32_t cmd;       /* CPUFREQ_CMD_* */
+	uint32_t cpu;       /* Physical CPU number */
+	uint32_t freq;      /* Frequency in KHz */
+	uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
+	int32_t result;     /* Returned result of the operation */
+};
+
 struct arch_vcpu_info { };
-struct arch_shared_info { };
+struct arch_shared_info {
+	struct cpufreq_sh_info cpufreq;
+};
 
 /* TODO: Move pvclock definitions some place arch independent */
 struct pvclock_vcpu_time_info {
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:19:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13: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 1XoBLd-0007QC-88; Tue, 11 Nov 2014 13:19:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLa-0007M9-Ti
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:19:03 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	0D/6A-29352-6CC02645; Tue, 11 Nov 2014 13:19:02 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415711939!11767663!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11142 invoked from network); 11 Nov 2014 13:19:01 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:19:01 -0000
Received: from mail-la0-f54.google.com ([209.85.215.54]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMwnUDDeS7aaL9ObKf0MjcmmwI8bOw@postini.com;
	Tue, 11 Nov 2014 05:19:01 PST
Received: by mail-la0-f54.google.com with SMTP id s18so9636198lam.13
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=WmEUOtFCC5iipHh2nynMtmUizmOJi8yKZI+dhDOjwpQ=;
	b=Su32bEtnOK9zE3yjzKltImEyeCVbYYU8qtLmWbrSXQJ7+mrWvM3wPrTqiOhz0z3APK
	u4xpy1w8cxvwm9DBUUFvgzHc0UVL2PzexCT595VJkmEPUeo3pwFuKUvGpnIxtXhiePBf
	34qkuVvr7u7YibYM1lku0u1EDxVAtIjvgmT0Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=WmEUOtFCC5iipHh2nynMtmUizmOJi8yKZI+dhDOjwpQ=;
	b=R2W57q2hZ8DxAb5zoE6Km51TmRDUSPwUfLyL9fiG6Flx9ClNVVLuogKqogyKkSfCds
	ixyz2LGI9QnYc1Ka0kgt/nUuvEZbgSMOf3dA2nYahu/fQh2O23v+cp1/QWs3JqQAS7QV
	pPNaASdBuS1G23UVQtUIhYXyDj/nTMcvpI3qVJlL44vLjEbcHTuz+TWcFV0z/HO5LiPX
	JbvtRWrQpFEZhBoF+rwvfWz0UwdO+sOoZqGpMbXxD8QwE14EV5Il16YTMD4kGGWdaxWW
	af1hwsgyuR5dSgMWZ5YzVuMCtfIqdx30mzbyZu7XaAKcZRPq3uNbOe0WruUpR37L8V5z
	fZFA==
X-Gm-Message-State: ALoCoQnckFY4ihBAp2aInalj8eD6xi6nVtdfY8Y+9f5iZRubr/DfAPNfrFQKEnyPOkvOEY1ObtkuHaR2aI3s/LsiJ+Io2kysW3L5/Gtu+U8AaTrK4+oC5CPSAp9l0BjYRT9z2zkA52kuIfPQXsjjFE/TkPwiKoWZog==
X-Received: by 10.112.25.73 with SMTP id a9mr36869776lbg.10.1415711937614;
	Tue, 11 Nov 2014 05:18:57 -0800 (PST)
X-Received: by 10.112.25.73 with SMTP id a9mr36869763lbg.10.1415711937519;
	Tue, 11 Nov 2014 05:18:57 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id qs2sm5975981lbb.28.2014.11.11.05.18.55
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:56 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:30 +0200
Message-Id: <1415711911-1807-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 09/10] xen/arm: add XEN_SYSCTL_cpufreq_op
	definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Kernel uses this op to start/stop cpufreq notification
events sending.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 include/xen/interface/sysctl.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
index 97c91b0..a4d52e5 100644
--- a/include/xen/interface/sysctl.h
+++ b/include/xen/interface/sysctl.h
@@ -63,14 +63,24 @@ struct xen_sysctl_physinfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
 
+#define XEN_SYSCTL_CPUFREQ_event_start     0
+#define XEN_SYSCTL_CPUFREQ_event_stop      1
+
+struct xen_sysctl_cpufreq_op {
+	uint32_t cmd;         /* XEN_SYSCTL_CPUFREQ_* */
+	uint32_t port;        /* OUT: event channel for notifications */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpufreq_op);
 
 
 struct xen_sysctl {
 	uint32_t cmd;
 #define XEN_SYSCTL_physinfo                       3
+#define XEN_SYSCTL_cpufreq_op                    21
 	uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
 	union {
 		struct xen_sysctl_physinfo          physinfo;
+		struct xen_sysctl_cpufreq_op        cpufreq_op;
 		uint8_t                             pad[128];
 	} u;
 };
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:19:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13: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 1XoBLd-0007QC-88; Tue, 11 Nov 2014 13:19:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLa-0007M9-Ti
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:19:03 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	0D/6A-29352-6CC02645; Tue, 11 Nov 2014 13:19:02 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415711939!11767663!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11142 invoked from network); 11 Nov 2014 13:19:01 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:19:01 -0000
Received: from mail-la0-f54.google.com ([209.85.215.54]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMwnUDDeS7aaL9ObKf0MjcmmwI8bOw@postini.com;
	Tue, 11 Nov 2014 05:19:01 PST
Received: by mail-la0-f54.google.com with SMTP id s18so9636198lam.13
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:18:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=WmEUOtFCC5iipHh2nynMtmUizmOJi8yKZI+dhDOjwpQ=;
	b=Su32bEtnOK9zE3yjzKltImEyeCVbYYU8qtLmWbrSXQJ7+mrWvM3wPrTqiOhz0z3APK
	u4xpy1w8cxvwm9DBUUFvgzHc0UVL2PzexCT595VJkmEPUeo3pwFuKUvGpnIxtXhiePBf
	34qkuVvr7u7YibYM1lku0u1EDxVAtIjvgmT0Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=WmEUOtFCC5iipHh2nynMtmUizmOJi8yKZI+dhDOjwpQ=;
	b=R2W57q2hZ8DxAb5zoE6Km51TmRDUSPwUfLyL9fiG6Flx9ClNVVLuogKqogyKkSfCds
	ixyz2LGI9QnYc1Ka0kgt/nUuvEZbgSMOf3dA2nYahu/fQh2O23v+cp1/QWs3JqQAS7QV
	pPNaASdBuS1G23UVQtUIhYXyDj/nTMcvpI3qVJlL44vLjEbcHTuz+TWcFV0z/HO5LiPX
	JbvtRWrQpFEZhBoF+rwvfWz0UwdO+sOoZqGpMbXxD8QwE14EV5Il16YTMD4kGGWdaxWW
	af1hwsgyuR5dSgMWZ5YzVuMCtfIqdx30mzbyZu7XaAKcZRPq3uNbOe0WruUpR37L8V5z
	fZFA==
X-Gm-Message-State: ALoCoQnckFY4ihBAp2aInalj8eD6xi6nVtdfY8Y+9f5iZRubr/DfAPNfrFQKEnyPOkvOEY1ObtkuHaR2aI3s/LsiJ+Io2kysW3L5/Gtu+U8AaTrK4+oC5CPSAp9l0BjYRT9z2zkA52kuIfPQXsjjFE/TkPwiKoWZog==
X-Received: by 10.112.25.73 with SMTP id a9mr36869776lbg.10.1415711937614;
	Tue, 11 Nov 2014 05:18:57 -0800 (PST)
X-Received: by 10.112.25.73 with SMTP id a9mr36869763lbg.10.1415711937519;
	Tue, 11 Nov 2014 05:18:57 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id qs2sm5975981lbb.28.2014.11.11.05.18.55
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:56 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:30 +0200
Message-Id: <1415711911-1807-10-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 09/10] xen/arm: add XEN_SYSCTL_cpufreq_op
	definition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Kernel uses this op to start/stop cpufreq notification
events sending.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 include/xen/interface/sysctl.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
index 97c91b0..a4d52e5 100644
--- a/include/xen/interface/sysctl.h
+++ b/include/xen/interface/sysctl.h
@@ -63,14 +63,24 @@ struct xen_sysctl_physinfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
 
+#define XEN_SYSCTL_CPUFREQ_event_start     0
+#define XEN_SYSCTL_CPUFREQ_event_stop      1
+
+struct xen_sysctl_cpufreq_op {
+	uint32_t cmd;         /* XEN_SYSCTL_CPUFREQ_* */
+	uint32_t port;        /* OUT: event channel for notifications */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpufreq_op);
 
 
 struct xen_sysctl {
 	uint32_t cmd;
 #define XEN_SYSCTL_physinfo                       3
+#define XEN_SYSCTL_cpufreq_op                    21
 	uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
 	union {
 		struct xen_sysctl_physinfo          physinfo;
+		struct xen_sysctl_cpufreq_op        cpufreq_op;
 		uint8_t                             pad[128];
 	} u;
 };
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:19:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13: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 1XoBLg-0007VD-NP; Tue, 11 Nov 2014 13:19:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLf-0007TH-LT
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:19:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1E/0F-09936-BCC02645; Tue, 11 Nov 2014 13:19:07 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415711942!11942381!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4033 invoked from network); 11 Nov 2014 13:19:04 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:19:04 -0000
Received: from mail-la0-f41.google.com ([209.85.215.41]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMxXNP5ptXtIKBk6UKh7H5mCrA5d0A@postini.com;
	Tue, 11 Nov 2014 05:19:03 PST
Received: by mail-la0-f41.google.com with SMTP id s18so9509744lam.14
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:19:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=iljwN3Gt9PXS72M2Bql/vUVf7aUa5CWT2561zvM3vhc=;
	b=hqvCGK0SQxtYQi1W5160ZnGOs823EaAxXX7ZE0Lxsa4hKmx0mnxz5zq7cri8hxvh8R
	ePdzQjoENxBrMk7W3K8H4W6FtJvIOSxmHPlHUIzFjP6ix8k7pTba6raKnIB161ipmSQs
	I/GaMHQkEGoNdzenppHpPOTdpoiHz+yJ2Ezwg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=iljwN3Gt9PXS72M2Bql/vUVf7aUa5CWT2561zvM3vhc=;
	b=E5wzoJXWbDvcKV2Win0fXkie0bpjuUykiW6xophTtBpiUdum3Q4Casy0ll/0bqaGW7
	TjznRjDGaEGhHBTu1g5GIOhrazF8Me8opXgC2Mnxwf52U+7fqgoO4zBqRTrPvyFVur4z
	7enkgsdJLCAqpN8DBFbL72BG5EHomr3Fbt9pcBAoWafwtfDvuLXpRsY5VQu+/JLYnUO5
	RhAp6EiU+LOIcxuviHb1RIiYTvcrXp+Gp0KkzpNBTLKyUP6x+G4XRMwIpYQp+AqLx9OL
	MOVWgt7HC4428E1R6UAncTPWhQw40aRNLB5jC5qarmNYPO7mer0b7HSUeFFj0bHl+jmi
	LAqg==
X-Gm-Message-State: ALoCoQkH98IW1sug1aKAhJVCLe1JzCqI5D05J/0FkfJh4Y/sttG5xdmHgBv52P401GURzpzsw4B3HGY+k17j7r305pUW+dJ012zIwvLibkiXDSLEhuDlJl2qitvMi8Ka3v7Mt8X+bph2F2RUz+aXJnKR93EWwcZUOQ==
X-Received: by 10.152.23.73 with SMTP id k9mr10581278laf.14.1415711940446;
	Tue, 11 Nov 2014 05:19:00 -0800 (PST)
X-Received: by 10.152.23.73 with SMTP id k9mr10581266laf.14.1415711940325;
	Tue, 11 Nov 2014 05:19:00 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id r3sm1612837lae.25.2014.11.11.05.18.58
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:59 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:31 +0200
Message-Id: <1415711911-1807-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 10/10] xen/arm: cpufreq: add xen-cpufreq
	driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 changes frequencies on physical CPUs using this
high-level cpufreq driver.
Workflow:
 * cpufreq governor driver in Xen wants to change the
   frequency of the physical CPU
 * cpufreq driver in Xen sets parameters in the shared
   memory
 * cpufreq driver in Xen sends an event via event channel
   to notify the xen-cpufreq driver
 * xen-cpufreq driver reads parameters from the shared
   memory, changes frequency and copies the result of
   the operation to the shared memory
 * xen-cpufreq driver sends an event via event channel
   to notify the cpufreq driver in Xen

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/Kconfig           |  20 +
 drivers/cpufreq/Makefile          |   1 +
 drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
 drivers/cpufreq/cpufreq_drv_ops.h |   4 +
 drivers/cpufreq/xen-cpufreq.c     | 917 ++++++++++++++++++++++++++++++++++++++
 include/xen/interface/platform.h  |   1 +
 6 files changed, 954 insertions(+), 2 deletions(-)
 create mode 100644 drivers/cpufreq/xen-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index f5a8f84..4847d8a 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -19,6 +19,26 @@ config CPU_FREQ
 
 	  If in doubt, say N.
 
+config XEN_CPUFREQ
+	bool "Xen Cpufreq driver"
+	depends on XEN_DOM0
+	depends on !CPUMASK_OFFSTACK
+	default n
+	select CPUFREQ_DRV_OPS
+	help
+	  This driver uploads Power Management information to the Xen
+	  hypervisor and changes CPUs frequency using CPU Frequency scaling
+	  drivers.
+
+	  To do that the driver uses CPU Frequency scaling drivers to parse
+	  the Power Management data and uploads said information to the Xen
+	  hypervisor. Then the Xen hypervisor can select the proper Pxx states.
+
+	  Then the Xen hypervisor can change CPUs frequency by giving commands
+	  via this driver to the CPU Frequency scaling driver.
+
+	  If in doubt, say N.
+
 if CPUFREQ_DRV_OPS
 
 config CPU_FREQ_TABLE
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index f12a0d3..c8d5037 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -1,5 +1,6 @@
 # CPUfreq core
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
+obj-$(CONFIG_XEN_CPUFREQ)		+= xen-cpufreq.o
 obj-$(CONFIG_CPUFREQ_DRV_OPS)		+= cpufreq_drv_ops.o
 # CPUfreq stats
 obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
index c971442..71c3357 100644
--- a/drivers/cpufreq/cpufreq_drv_ops.c
+++ b/drivers/cpufreq/cpufreq_drv_ops.c
@@ -18,6 +18,8 @@
 #include <linux/init.h>
 #include <linux/export.h>
 
+#include <xen/xen.h>
+
 static struct cpufreq_drv_ops *ops;
 
 struct kobject *get_cpufreq_global_kobject(void)
@@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
 
 static int __init cpufreq_drv_ops_init(void)
 {
+	if (xen_initial_domain()) {
+#ifdef CONFIG_XEN_CPUFREQ
+		ops = &xen_cpufreq_drv_ops;
+		pr_debug("using xen_cpufreq_drv_ops\n");
+#endif
+	} else {
 #ifdef CONFIG_CPU_FREQ
-	ops = &kern_cpufreq_drv_ops;
-	pr_debug("using kern_cpufreq_drv_ops\n");
+		ops = &kern_cpufreq_drv_ops;
+		pr_debug("using kern_cpufreq_drv_ops\n");
 #endif
+	}
 
 	return 0;
 }
diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
index 5cc8e05..d02d509 100644
--- a/drivers/cpufreq/cpufreq_drv_ops.h
+++ b/drivers/cpufreq/cpufreq_drv_ops.h
@@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
 extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
 #endif
 
+#ifdef CONFIG_XEN_CPUFREQ
+extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
+#endif
+
 #endif /* _CPUFREQ_DRV_OPS_H */
diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
new file mode 100644
index 0000000..b19d726
--- /dev/null
+++ b/drivers/cpufreq/xen-cpufreq.c
@@ -0,0 +1,917 @@
+/*
+ *  Copyright (C) 2001 Russell King
+ *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
+ *
+ *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
+ *	Added handling for CPU hotplug
+ *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
+ *	Fix handling for CPU hotplug -- affected CPUs
+ *
+ *           (C) 2014 GlobalLogic Inc.
+ *
+ * Based on drivers/cpufreq/cpufreq.c
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/notifier.h>
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+#include <linux/irq.h>
+#include <linux/workqueue.h>
+#include <linux/cpufreq.h>
+
+#include <trace/events/power.h>
+
+#include <xen/xen.h>
+#include <xen/events.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/platform.h>
+#include <xen/interface/sysctl.h>
+#include <asm/xen/hypercall.h>
+#include <asm/xen/hypervisor.h>
+
+#include "cpufreq_drv_ops.h"
+
+static int xen_nr_cpus;
+static int xen_irq;
+
+#define for_each_xen_cpu(cpu, mask)			\
+	for ((cpu) = -1;				\
+		(cpu) = cpumask_next((cpu), (mask)),	\
+		(cpu) < xen_nr_cpus;)
+
+static struct cpufreq_driver *cpufreq_driver;
+static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
+
+static DEFINE_SPINLOCK(cpufreq_driver_lock);
+
+/*
+ * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
+ * all cpufreq/hotplug/workqueue/etc related lock issues.
+ *
+ * The rules for this semaphore:
+ * - Any routine that wants to read from the policy structure will
+ *   do a down_read on this semaphore.
+ * - Any routine that will write to the policy structure and/or may take away
+ *   the policy altogether (eg. CPU hotplug), will hold this lock in write
+ *   mode before doing so.
+ *
+ * Additional rules:
+ * - Governor routines that can be called in cpufreq hotplug path should not
+ *   take this sem as top level hotplug notifier handler takes this.
+ * - Lock should not be held across
+ *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
+ */
+static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
+static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
+
+#define lock_policy_rwsem(mode, cpu)				\
+static int lock_policy_rwsem_##mode				\
+(int cpu)							\
+{								\
+	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);	\
+	BUG_ON(policy_cpu == -1);				\
+	down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));	\
+								\
+	return 0;						\
+}
+
+lock_policy_rwsem(write, cpu);
+
+static void unlock_policy_rwsem_write(int cpu)
+{
+	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
+	BUG_ON(policy_cpu == -1);
+	up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
+}
+
+/**
+ * The "transition" notifier list for kernel code that needs to handle
+ * changes to devices when the CPU clock speed changes.
+ * The mutex locks this list.
+ */
+static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
+
+static bool init_cpufreq_transition_notifier_list_called;
+static int __init init_cpufreq_transition_notifier_list(void)
+{
+	srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
+	init_cpufreq_transition_notifier_list_called = true;
+	return 0;
+}
+pure_initcall(init_cpufreq_transition_notifier_list);
+
+static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
+{
+	struct cpufreq_policy *data = NULL;
+	unsigned long flags;
+
+	if (cpu >= xen_nr_cpus)
+		goto err_out;
+
+	/* get the cpufreq driver */
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+
+	if (!cpufreq_driver)
+		goto err_out_unlock;
+
+	/* get the CPU */
+	data = per_cpu(cpufreq_cpu_data, cpu);
+
+err_out_unlock:
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+err_out:
+	return data;
+}
+
+static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
+{
+	module_put(cpufreq_driver->owner);
+}
+
+static int push_data_to_hypervisor(struct cpufreq_policy *policy,
+				   struct cpufreq_frequency_table *table)
+{
+	int ret = 0;
+	unsigned int i;
+	unsigned int cpu;
+	uint32_t platform_limit = 0;
+	unsigned int max_freq = 0;
+	unsigned int state_count = 0;
+	unsigned int prev_freq = 0;
+	struct xen_processor_px *dst_states;
+	struct xen_processor_performance *dst_perf;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+
+	dst_perf = &op.u.set_pminfo.perf;
+
+	/* Check freq table and find max frequency */
+	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
+		unsigned int freq = table[i].frequency;
+		if (freq == CPUFREQ_ENTRY_INVALID)
+			continue;
+
+		if (table[i].index != state_count || freq <= prev_freq) {
+			pr_err("Frequency table format error\n");
+			return -EINVAL;
+		}
+
+		prev_freq = freq;
+		state_count++;
+		if (freq > max_freq)
+			max_freq = freq;
+	}
+
+	if (!state_count)
+		return -EINVAL;
+
+	dst_perf->state_count = state_count;
+
+	dst_states = kcalloc(state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+
+	if (!dst_states)
+		return -ENOMEM;
+
+	set_xen_guest_handle(dst_perf->states, dst_states);
+
+	/*
+	 * Freq table should start from lower values
+	 * dst_states should start from higer values
+	 */
+	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
+		unsigned int freq = table[i].frequency;
+		unsigned int tbl_index = state_count - 1 - table[i].index;
+		if (freq == CPUFREQ_ENTRY_INVALID)
+			continue;
+
+		if (freq == max_freq)
+			platform_limit = tbl_index;
+
+		dst_states[tbl_index].core_frequency = freq / 1000;
+		dst_states[tbl_index].transition_latency =
+				policy->cpuinfo.transition_latency / 1000;
+	}
+
+	dst_perf->shared_type = policy->shared_type;
+	dst_perf->platform_limit = platform_limit;
+	dst_perf->domain_info.domain = policy->cpu;
+	dst_perf->domain_info.num_processors = xen_nr_cpus;
+	dst_perf->flags = XEN_PX_DATA;
+
+	for_each_xen_cpu(cpu, policy->cpus) {
+		op.u.set_pminfo.id = cpu;
+		ret = HYPERVISOR_dom0_op(&op);
+		if (ret) {
+			pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
+			goto err_free_states;
+		}
+		pr_debug("CPU%u - P-states uploaded\n", cpu);
+
+		for (i = 0; i < dst_perf->state_count; i++) {
+			pr_debug("    state %d: %d MHz, %d uS\n",
+				 i, (u32) dst_states[i].core_frequency,
+				 (u32) dst_states[i].transition_latency);
+		}
+	}
+
+err_free_states:
+	kfree(dst_states);
+	return ret;
+}
+
+/*
+ * Returns:
+ *   Negative: Failure
+ *   0:        Success
+ *   Positive: When we have a managed CPU and the sysfs got symlinked
+ */
+static int xen_cpufreq_add_dev_policy(unsigned int cpu,
+				  struct cpufreq_policy *policy)
+{
+	int ret = 0;
+#ifdef CONFIG_SMP
+	unsigned long flags;
+	unsigned int j;
+
+	for_each_cpu(j, policy->cpus) {
+		struct cpufreq_policy *managed_policy;
+
+		if (cpu == j)
+			continue;
+
+		/* Check for existing affected CPUs.
+		 * They may not be aware of it due to CPU Hotplug.
+		 * cpufreq_cpu_put is called when the device is removed
+		 * in __cpufreq_remove_dev()
+		 */
+		managed_policy = xen_cpufreq_cpu_get(j);
+		if (unlikely(managed_policy)) {
+			/* Set proper policy_cpu */
+			unlock_policy_rwsem_write(cpu);
+			per_cpu(cpufreq_policy_cpu, cpu) =
+						managed_policy->cpu;
+
+			if (lock_policy_rwsem_write(cpu) < 0) {
+				/* Should not go through policy unlock path */
+				if (cpufreq_driver->exit)
+					cpufreq_driver->exit(policy);
+				xen_cpufreq_cpu_put(managed_policy);
+				return -EBUSY;
+			}
+
+			spin_lock_irqsave(&cpufreq_driver_lock, flags);
+			cpumask_copy(managed_policy->cpus, policy->cpus);
+			per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
+			spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+			pr_debug("CPU already managed, adding link\n");
+
+			/*
+			 * Success. We only needed to be added to the mask.
+			 * Call driver->exit() because only the cpu parent of
+			 * the kobj needed to call init().
+			 */
+			if (cpufreq_driver->exit)
+				cpufreq_driver->exit(policy);
+
+			return 1;
+		}
+	}
+#endif
+	return ret;
+}
+
+/**
+ * xen_cpufreq_add_dev - add a CPU device
+ *
+ * Adds the cpufreq interface for a CPU device.
+ */
+static int xen_cpufreq_add_dev(unsigned int cpu)
+{
+	int ret = 0;
+	struct cpufreq_policy *policy;
+	unsigned long flags;
+	unsigned int j;
+
+	pr_debug("adding CPU %u\n", cpu);
+
+#ifdef CONFIG_SMP
+	/* check whether a different CPU already registered this
+	 * CPU because it is in the same boat. */
+	policy = xen_cpufreq_cpu_get(cpu);
+	if (unlikely(policy)) {
+		xen_cpufreq_cpu_put(policy);
+		return 0;
+	}
+#endif
+
+	if (!try_module_get(cpufreq_driver->owner)) {
+		ret = -EINVAL;
+		goto module_out;
+	}
+
+	ret = -ENOMEM;
+	policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
+	if (!policy)
+		goto nomem_out;
+
+	if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
+		goto err_free_policy;
+
+	if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
+		goto err_free_cpumask;
+
+	policy->cpu = cpu;
+	cpumask_copy(policy->cpus, cpumask_of(cpu));
+
+	/* Initially set CPU itself as the policy_cpu */
+	per_cpu(cpufreq_policy_cpu, cpu) = cpu;
+	ret = (lock_policy_rwsem_write(cpu) < 0);
+	WARN_ON(ret);
+
+	/* call driver. From then on the cpufreq must be able
+	 * to accept all calls to ->verify and ->setpolicy for this CPU
+	 */
+	ret = cpufreq_driver->init(policy);
+	if (ret) {
+		pr_debug("initialization failed\n");
+		goto err_unlock_policy;
+	}
+	ret = xen_cpufreq_add_dev_policy(cpu, policy);
+	if (ret) {
+		if (ret > 0)
+			/* This is a managed cpu, symlink created,
+			   exit with 0 */
+			ret = 0;
+		goto err_unlock_policy;
+	}
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	for_each_cpu(j, policy->cpus) {
+		per_cpu(cpufreq_cpu_data, j) = policy;
+		per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
+	}
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	unlock_policy_rwsem_write(cpu);
+
+	module_put(cpufreq_driver->owner);
+	pr_debug("initialization complete\n");
+
+	return 0;
+
+err_unlock_policy:
+	unlock_policy_rwsem_write(cpu);
+	free_cpumask_var(policy->related_cpus);
+err_free_cpumask:
+	free_cpumask_var(policy->cpus);
+err_free_policy:
+	kfree(policy);
+nomem_out:
+	module_put(cpufreq_driver->owner);
+module_out:
+	return ret;
+}
+
+/**
+ * __cpufreq_remove_dev - remove a CPU device
+ *
+ * Removes the cpufreq interface for a CPU device.
+ * Caller should already have policy_rwsem in write mode for this CPU.
+ * This routine frees the rwsem before returning.
+ */
+static int __cpufreq_remove_dev(unsigned int cpu)
+{
+	unsigned long flags;
+	struct cpufreq_policy *data;
+#ifdef CONFIG_SMP
+	unsigned int j;
+#endif
+
+	pr_debug("unregistering CPU %u\n", cpu);
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	data = per_cpu(cpufreq_cpu_data, cpu);
+
+	if (!data) {
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		unlock_policy_rwsem_write(cpu);
+		return -EINVAL;
+	}
+	per_cpu(cpufreq_cpu_data, cpu) = NULL;
+
+
+#ifdef CONFIG_SMP
+	/* if this isn't the CPU which is the parent of the kobj, we
+	 * only need to unlink, put and exit
+	 */
+	if (unlikely(cpu != data->cpu)) {
+		pr_debug("removing link\n");
+		cpumask_clear_cpu(cpu, data->cpus);
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		xen_cpufreq_cpu_put(data);
+		unlock_policy_rwsem_write(cpu);
+		return 0;
+	}
+#endif
+
+#ifdef CONFIG_SMP
+
+	/* if we have other CPUs still registered, we need to unlink them,
+	 * or else wait_for_completion below will lock up. Clean the
+	 * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
+	 * the sysfs links afterwards.
+	 */
+	if (unlikely(cpumask_weight(data->cpus) > 1)) {
+		for_each_cpu(j, data->cpus) {
+			if (j == cpu)
+				continue;
+			per_cpu(cpufreq_cpu_data, j) = NULL;
+		}
+	}
+
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	if (unlikely(cpumask_weight(data->cpus) > 1)) {
+		for_each_cpu(j, data->cpus) {
+			if (j == cpu)
+				continue;
+			pr_debug("removing link for cpu %u\n", j);
+			unlock_policy_rwsem_write(cpu);
+			lock_policy_rwsem_write(cpu);
+			xen_cpufreq_cpu_put(data);
+		}
+	}
+#else
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+#endif
+
+	unlock_policy_rwsem_write(cpu);
+
+	lock_policy_rwsem_write(cpu);
+	if (cpufreq_driver->exit)
+		cpufreq_driver->exit(data);
+	unlock_policy_rwsem_write(cpu);
+
+	free_cpumask_var(data->related_cpus);
+	free_cpumask_var(data->cpus);
+	kfree(data);
+
+	return 0;
+}
+
+static int cpufreq_remove_dev(unsigned int cpu)
+{
+	int retval;
+
+	if (unlikely(lock_policy_rwsem_write(cpu)))
+		BUG();
+
+	retval = __cpufreq_remove_dev(cpu);
+	return retval;
+}
+
+/*********************************************************************
+ *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
+ *********************************************************************/
+
+/**
+ * adjust_jiffies - adjust the system "loops_per_jiffy"
+ *
+ * This function alters the system "loops_per_jiffy" for the clock
+ * speed change. Note that loops_per_jiffy cannot be updated on SMP
+ * systems as each CPU might be scaled differently. So, use the arch
+ * per-CPU loops_per_jiffy value wherever possible.
+ */
+#ifndef CONFIG_SMP
+static unsigned long l_p_j_ref;
+static unsigned int  l_p_j_ref_freq;
+
+static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
+{
+	if (ci->flags & CPUFREQ_CONST_LOOPS)
+		return;
+
+	if (!l_p_j_ref_freq) {
+		l_p_j_ref = loops_per_jiffy;
+		l_p_j_ref_freq = ci->old;
+		pr_debug("saving %lu as reference value for loops_per_jiffy; "
+			"freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
+	}
+	if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
+	    (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
+		loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
+								ci->new);
+		pr_debug("scaling loops_per_jiffy to %lu "
+			"for frequency %u kHz\n", loops_per_jiffy, ci->new);
+	}
+}
+#else
+static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
+{
+	return;
+}
+#endif
+
+
+/**
+ * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
+ * on frequency transition.
+ *
+ * This function calls the transition notifiers and the "adjust_jiffies"
+ * function. It is called twice on all CPU frequency changes that have
+ * external effects.
+ */
+void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
+				   unsigned int state)
+{
+	struct cpufreq_policy *policy;
+
+	BUG_ON(irqs_disabled());
+
+	freqs->flags = cpufreq_driver->flags;
+	pr_debug("notification %u of frequency transition to %u kHz\n",
+		 state, freqs->new);
+
+	policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
+	switch (state) {
+	case CPUFREQ_PRECHANGE:
+		/* detect if the driver reported a value as "old frequency"
+		 * which is not equal to what the cpufreq core thinks is
+		 * "old frequency".
+		 */
+		if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
+			if ((policy) && (policy->cpu == freqs->cpu) &&
+			    (policy->cur) && (policy->cur != freqs->old)) {
+				pr_debug("Warning: CPU frequency is"
+					 " %u, cpufreq assumed %u kHz.\n",
+					 freqs->old, policy->cur);
+				freqs->old = policy->cur;
+			}
+		}
+		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
+					 CPUFREQ_PRECHANGE, freqs);
+		adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
+		break;
+
+	case CPUFREQ_POSTCHANGE:
+		adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
+		pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
+			 (unsigned long)freqs->cpu);
+		trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
+		trace_cpu_frequency(freqs->new, freqs->cpu);
+		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
+					 CPUFREQ_POSTCHANGE, freqs);
+		if (likely(policy) && likely(policy->cpu == freqs->cpu))
+			policy->cur = freqs->new;
+		break;
+	}
+}
+
+/*********************************************************************
+ *                              GOVERNORS                            *
+ *********************************************************************/
+
+int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
+				unsigned int target_freq,
+				unsigned int relation)
+{
+	int retval = -EINVAL;
+	unsigned int old_target_freq = target_freq;
+
+	/* Make sure that target_freq is within supported range */
+	if (target_freq > policy->max)
+		target_freq = policy->max;
+	if (target_freq < policy->min)
+		target_freq = policy->min;
+
+	pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
+		 policy->cpu, target_freq, relation, old_target_freq);
+
+	if (target_freq == policy->cur)
+		return 0;
+
+	if (cpufreq_driver->target)
+		retval = cpufreq_driver->target(policy, target_freq,
+						    relation);
+
+	return retval;
+}
+
+int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
+			      unsigned int target_freq,
+			      unsigned int relation)
+{
+	int ret = -EINVAL;
+
+	if (!policy)
+		goto no_policy;
+
+	if (unlikely(lock_policy_rwsem_write(policy->cpu)))
+		goto fail;
+
+	ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
+
+	unlock_policy_rwsem_write(policy->cpu);
+
+fail:
+	xen_cpufreq_cpu_put(policy);
+no_policy:
+	return ret;
+}
+
+/*********************************************************************
+ *                    HANDLE COMMANDS FROM XEN                       *
+ *********************************************************************/
+static void cpufreq_work_hnd(struct work_struct *w);
+
+static struct workqueue_struct *cpufreq_wq;
+static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
+
+static void cpufreq_work_hnd(struct work_struct *w)
+{
+	int ret;
+	struct cpufreq_policy *policy;
+	struct cpufreq_sh_info *cpufreq_info;
+
+	cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
+
+	policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
+
+	/* Set parameters in the Xen then read it */
+	smp_rmb();
+
+	/* accept only CPUFREQ_CMD_change_freq */
+	if (cpufreq_info->cmd != CPUFREQ_CMD_change_freq)
+		return;
+
+	ret = xen_cpufreq_driver_target(policy,
+					cpufreq_info->freq,
+					cpufreq_info->relation);
+
+	cpufreq_info->result = ret;
+	smp_wmb(); /* above must be visible before notify_remote_via_irq() */
+
+	notify_remote_via_irq(xen_irq);
+}
+
+static irqreturn_t cpufreq_interrupt(int irq, void *data)
+{
+	queue_work(cpufreq_wq, &cpufreq_work);
+	return IRQ_HANDLED;
+}
+
+/*********************************************************************
+ *                    XEN CPUFREQ EVENTS                             *
+ *********************************************************************/
+static int xen_start_cpufreq_event(uint32_t *port)
+{
+	int ret;
+	struct xen_sysctl op = {
+		.cmd = XEN_SYSCTL_cpufreq_op,
+		.interface_version = XEN_SYSCTL_INTERFACE_VERSION,
+		.u.cpufreq_op.cmd = XEN_SYSCTL_CPUFREQ_event_start,
+	};
+
+	ret = HYPERVISOR_sysctl(&op);
+	if (unlikely(ret))
+		pr_err("Hypervisor cpufreq strart event error (%d)\n", ret);
+	else
+		*port = op.u.cpufreq_op.port;
+
+	return ret;
+}
+
+static int xen_stop_cpufreq_event(void)
+{
+	int ret;
+	struct xen_sysctl op = {
+		.cmd = XEN_SYSCTL_cpufreq_op,
+		.interface_version = XEN_SYSCTL_INTERFACE_VERSION,
+		.u.cpufreq_op.cmd = XEN_SYSCTL_CPUFREQ_event_stop,
+	};
+
+	ret = HYPERVISOR_sysctl(&op);
+	if (ret)
+		pr_err("Hypervisor cpufreq stop event error (%d)\n", ret);
+
+	return ret;
+}
+
+/*********************************************************************
+ *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
+ *********************************************************************/
+
+/**
+ * xen_cpufreq_register_driver - register a CPU Frequency driver
+ * @driver_data: A struct cpufreq_driver containing the values#
+ * submitted by the CPU Frequency driver.
+ *
+ *   Registers a CPU Frequency driver to this core code. This code
+ * returns zero on success, -EBUSY when another driver got here first
+ * (and isn't unregistered in the meantime).
+ *
+ */
+int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
+{
+	unsigned long flags;
+	int ret;
+	unsigned int cpu;
+	struct cpufreq_frequency_table *table;
+	struct cpufreq_policy *policy;
+	cpumask_var_t pushed_cpus;
+	uint32_t port;
+	int irq;
+
+	if (!xen_nr_cpus)
+		return -EPROBE_DEFER;
+
+	if (!driver_data || !driver_data->verify || !driver_data->init ||
+	    (!driver_data->target))
+		return -EINVAL;
+
+	pr_debug("trying to register driver %s\n", driver_data->name);
+
+	if (driver_data->setpolicy)
+		driver_data->flags |= CPUFREQ_CONST_LOOPS;
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+
+	if (cpufreq_driver) {
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		return -EBUSY;
+	}
+	cpufreq_driver = driver_data;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	ret = xen_start_cpufreq_event(&port);
+	if (ret)
+		goto err_remove_drv;
+
+	irq = bind_interdomain_evtchn_to_irqhandler(DOMID_SELF, port,
+						    cpufreq_interrupt, 0,
+						    "xen_cpufreq", NULL);
+
+	if (irq < 0) {
+		pr_err("bind interdomain evtchn to irqhandler error (%d)\n",
+		       irq);
+		ret = irq;
+		goto err_stop_cpufreq_event;
+	}
+	xen_irq = irq;
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
+		ret = xen_cpufreq_add_dev(cpu);
+		if (ret)
+			goto err_remove_cpu;
+	}
+
+	if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
+		goto err_remove_cpu;
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
+		if (cpumask_test_cpu(cpu, pushed_cpus))
+			continue;
+
+		policy = xen_cpufreq_cpu_get(cpu);
+		if (!policy) {
+			ret = -EINVAL;
+			goto err_free_cpumask;
+		}
+
+		cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
+		table = cpufreq_frequency_get_table(policy->cpu);
+		if (!table) {
+			ret = -EINVAL;
+			goto err_free_cpumask;
+		}
+
+		ret = push_data_to_hypervisor(policy, table);
+		if (ret)
+			goto err_free_cpumask;
+	}
+
+	free_cpumask_var(pushed_cpus);
+
+	pr_debug("driver %s up and running\n", driver_data->name);
+
+	return 0;
+
+err_free_cpumask:
+	free_cpumask_var(pushed_cpus);
+err_remove_cpu:
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
+		cpufreq_remove_dev(cpu);
+	unbind_from_irqhandler(irq, NULL);
+err_stop_cpufreq_event:
+	xen_stop_cpufreq_event();
+err_remove_drv:
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	cpufreq_driver = NULL;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+	return ret;
+}
+
+/**
+ * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
+ *
+ *    Unregister the current CPUFreq driver. Only call this if you have
+ * the right to do so, i.e. if you have succeeded in initialising before!
+ * Returns zero if successful, and -EINVAL if the cpufreq_driver is
+ * currently not initialised.
+ */
+int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
+{
+	unsigned long flags;
+	unsigned int cpu;
+
+	if (!cpufreq_driver || (driver != cpufreq_driver))
+		return -EINVAL;
+
+	pr_debug("unregistering driver %s\n", driver->name);
+
+	unbind_from_irqhandler(xen_irq, NULL);
+	xen_stop_cpufreq_event();
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
+		cpufreq_remove_dev(cpu);
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	cpufreq_driver = NULL;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	return 0;
+}
+
+struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
+	.notify_transition = xen_cpufreq_notify_transition,
+	.register_driver = xen_cpufreq_register_driver,
+	.unregister_driver = xen_cpufreq_unregister_driver,
+};
+
+static int __init xen_cpufreq_init(void)
+{
+	int ret;
+	int i;
+
+	struct xen_sysctl op = {
+		.cmd			= XEN_SYSCTL_physinfo,
+		.interface_version	= XEN_SYSCTL_INTERFACE_VERSION,
+	};
+
+	ret = HYPERVISOR_sysctl(&op);
+	if (ret) {
+		pr_err("Hypervisor get physinfo error (%d)\n", ret);
+		return ret;
+	}
+
+	xen_nr_cpus = op.u.physinfo.nr_cpus;
+	if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
+		xen_nr_cpus = 0;
+		pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < xen_nr_cpus; i++) {
+		per_cpu(cpufreq_policy_cpu, i) = -1;
+		init_rwsem(&per_cpu(cpu_policy_rwsem, i));
+	}
+
+	cpufreq_wq = create_singlethread_workqueue("xen_cpufreq");
+	if (!cpufreq_wq) {
+		pr_err("Create workqueue error\n");
+		ret = -ENOMEM;
+		goto err_create_wq;
+	}
+
+	return 0;
+
+err_create_wq:
+	xen_nr_cpus = 0;
+	return ret;
+}
+
+MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
+MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+core_initcall(xen_cpufreq_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c57d5f6..ee3b154 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
 #define XEN_PX_PSS   2
 #define XEN_PX_PPC   4
 #define XEN_PX_PSD   8
+#define XEN_PX_DATA  16
 
 struct xen_power_register {
 	uint32_t     space_id;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:19:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13: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 1XoBLg-0007VD-NP; Tue, 11 Nov 2014 13:19:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oleksandr.dmytryshyn@globallogic.com>)
	id 1XoBLf-0007TH-LT
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:19:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1E/0F-09936-BCC02645; Tue, 11 Nov 2014 13:19:07 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415711942!11942381!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4033 invoked from network); 11 Nov 2014 13:19:04 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 13:19:04 -0000
Received: from mail-la0-f41.google.com ([209.85.215.41]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGIMxXNP5ptXtIKBk6UKh7H5mCrA5d0A@postini.com;
	Tue, 11 Nov 2014 05:19:03 PST
Received: by mail-la0-f41.google.com with SMTP id s18so9509744lam.14
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 05:19:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=from:to:cc:subject:date:message-id:in-reply-to:references;
	bh=iljwN3Gt9PXS72M2Bql/vUVf7aUa5CWT2561zvM3vhc=;
	b=hqvCGK0SQxtYQi1W5160ZnGOs823EaAxXX7ZE0Lxsa4hKmx0mnxz5zq7cri8hxvh8R
	ePdzQjoENxBrMk7W3K8H4W6FtJvIOSxmHPlHUIzFjP6ix8k7pTba6raKnIB161ipmSQs
	I/GaMHQkEGoNdzenppHpPOTdpoiHz+yJ2Ezwg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=iljwN3Gt9PXS72M2Bql/vUVf7aUa5CWT2561zvM3vhc=;
	b=E5wzoJXWbDvcKV2Win0fXkie0bpjuUykiW6xophTtBpiUdum3Q4Casy0ll/0bqaGW7
	TjznRjDGaEGhHBTu1g5GIOhrazF8Me8opXgC2Mnxwf52U+7fqgoO4zBqRTrPvyFVur4z
	7enkgsdJLCAqpN8DBFbL72BG5EHomr3Fbt9pcBAoWafwtfDvuLXpRsY5VQu+/JLYnUO5
	RhAp6EiU+LOIcxuviHb1RIiYTvcrXp+Gp0KkzpNBTLKyUP6x+G4XRMwIpYQp+AqLx9OL
	MOVWgt7HC4428E1R6UAncTPWhQw40aRNLB5jC5qarmNYPO7mer0b7HSUeFFj0bHl+jmi
	LAqg==
X-Gm-Message-State: ALoCoQkH98IW1sug1aKAhJVCLe1JzCqI5D05J/0FkfJh4Y/sttG5xdmHgBv52P401GURzpzsw4B3HGY+k17j7r305pUW+dJ012zIwvLibkiXDSLEhuDlJl2qitvMi8Ka3v7Mt8X+bph2F2RUz+aXJnKR93EWwcZUOQ==
X-Received: by 10.152.23.73 with SMTP id k9mr10581278laf.14.1415711940446;
	Tue, 11 Nov 2014 05:19:00 -0800 (PST)
X-Received: by 10.152.23.73 with SMTP id k9mr10581266laf.14.1415711940325;
	Tue, 11 Nov 2014 05:19:00 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id r3sm1612837lae.25.2014.11.11.05.18.58
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 05:18:59 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Tue, 11 Nov 2014 15:18:31 +0200
Message-Id: <1415711911-1807-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1415711911-1807-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [RFC PATCH v5 10/10] xen/arm: cpufreq: add xen-cpufreq
	driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 changes frequencies on physical CPUs using this
high-level cpufreq driver.
Workflow:
 * cpufreq governor driver in Xen wants to change the
   frequency of the physical CPU
 * cpufreq driver in Xen sets parameters in the shared
   memory
 * cpufreq driver in Xen sends an event via event channel
   to notify the xen-cpufreq driver
 * xen-cpufreq driver reads parameters from the shared
   memory, changes frequency and copies the result of
   the operation to the shared memory
 * xen-cpufreq driver sends an event via event channel
   to notify the cpufreq driver in Xen

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 drivers/cpufreq/Kconfig           |  20 +
 drivers/cpufreq/Makefile          |   1 +
 drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
 drivers/cpufreq/cpufreq_drv_ops.h |   4 +
 drivers/cpufreq/xen-cpufreq.c     | 917 ++++++++++++++++++++++++++++++++++++++
 include/xen/interface/platform.h  |   1 +
 6 files changed, 954 insertions(+), 2 deletions(-)
 create mode 100644 drivers/cpufreq/xen-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index f5a8f84..4847d8a 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -19,6 +19,26 @@ config CPU_FREQ
 
 	  If in doubt, say N.
 
+config XEN_CPUFREQ
+	bool "Xen Cpufreq driver"
+	depends on XEN_DOM0
+	depends on !CPUMASK_OFFSTACK
+	default n
+	select CPUFREQ_DRV_OPS
+	help
+	  This driver uploads Power Management information to the Xen
+	  hypervisor and changes CPUs frequency using CPU Frequency scaling
+	  drivers.
+
+	  To do that the driver uses CPU Frequency scaling drivers to parse
+	  the Power Management data and uploads said information to the Xen
+	  hypervisor. Then the Xen hypervisor can select the proper Pxx states.
+
+	  Then the Xen hypervisor can change CPUs frequency by giving commands
+	  via this driver to the CPU Frequency scaling driver.
+
+	  If in doubt, say N.
+
 if CPUFREQ_DRV_OPS
 
 config CPU_FREQ_TABLE
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index f12a0d3..c8d5037 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -1,5 +1,6 @@
 # CPUfreq core
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
+obj-$(CONFIG_XEN_CPUFREQ)		+= xen-cpufreq.o
 obj-$(CONFIG_CPUFREQ_DRV_OPS)		+= cpufreq_drv_ops.o
 # CPUfreq stats
 obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
diff --git a/drivers/cpufreq/cpufreq_drv_ops.c b/drivers/cpufreq/cpufreq_drv_ops.c
index c971442..71c3357 100644
--- a/drivers/cpufreq/cpufreq_drv_ops.c
+++ b/drivers/cpufreq/cpufreq_drv_ops.c
@@ -18,6 +18,8 @@
 #include <linux/init.h>
 #include <linux/export.h>
 
+#include <xen/xen.h>
+
 static struct cpufreq_drv_ops *ops;
 
 struct kobject *get_cpufreq_global_kobject(void)
@@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
 
 static int __init cpufreq_drv_ops_init(void)
 {
+	if (xen_initial_domain()) {
+#ifdef CONFIG_XEN_CPUFREQ
+		ops = &xen_cpufreq_drv_ops;
+		pr_debug("using xen_cpufreq_drv_ops\n");
+#endif
+	} else {
 #ifdef CONFIG_CPU_FREQ
-	ops = &kern_cpufreq_drv_ops;
-	pr_debug("using kern_cpufreq_drv_ops\n");
+		ops = &kern_cpufreq_drv_ops;
+		pr_debug("using kern_cpufreq_drv_ops\n");
 #endif
+	}
 
 	return 0;
 }
diff --git a/drivers/cpufreq/cpufreq_drv_ops.h b/drivers/cpufreq/cpufreq_drv_ops.h
index 5cc8e05..d02d509 100644
--- a/drivers/cpufreq/cpufreq_drv_ops.h
+++ b/drivers/cpufreq/cpufreq_drv_ops.h
@@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
 extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
 #endif
 
+#ifdef CONFIG_XEN_CPUFREQ
+extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
+#endif
+
 #endif /* _CPUFREQ_DRV_OPS_H */
diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
new file mode 100644
index 0000000..b19d726
--- /dev/null
+++ b/drivers/cpufreq/xen-cpufreq.c
@@ -0,0 +1,917 @@
+/*
+ *  Copyright (C) 2001 Russell King
+ *            (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
+ *
+ *  Oct 2005 - Ashok Raj <ashok.raj@intel.com>
+ *	Added handling for CPU hotplug
+ *  Feb 2006 - Jacob Shin <jacob.shin@amd.com>
+ *	Fix handling for CPU hotplug -- affected CPUs
+ *
+ *           (C) 2014 GlobalLogic Inc.
+ *
+ * Based on drivers/cpufreq/cpufreq.c
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/notifier.h>
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+#include <linux/irq.h>
+#include <linux/workqueue.h>
+#include <linux/cpufreq.h>
+
+#include <trace/events/power.h>
+
+#include <xen/xen.h>
+#include <xen/events.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/platform.h>
+#include <xen/interface/sysctl.h>
+#include <asm/xen/hypercall.h>
+#include <asm/xen/hypervisor.h>
+
+#include "cpufreq_drv_ops.h"
+
+static int xen_nr_cpus;
+static int xen_irq;
+
+#define for_each_xen_cpu(cpu, mask)			\
+	for ((cpu) = -1;				\
+		(cpu) = cpumask_next((cpu), (mask)),	\
+		(cpu) < xen_nr_cpus;)
+
+static struct cpufreq_driver *cpufreq_driver;
+static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
+
+static DEFINE_SPINLOCK(cpufreq_driver_lock);
+
+/*
+ * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
+ * all cpufreq/hotplug/workqueue/etc related lock issues.
+ *
+ * The rules for this semaphore:
+ * - Any routine that wants to read from the policy structure will
+ *   do a down_read on this semaphore.
+ * - Any routine that will write to the policy structure and/or may take away
+ *   the policy altogether (eg. CPU hotplug), will hold this lock in write
+ *   mode before doing so.
+ *
+ * Additional rules:
+ * - Governor routines that can be called in cpufreq hotplug path should not
+ *   take this sem as top level hotplug notifier handler takes this.
+ * - Lock should not be held across
+ *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
+ */
+static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
+static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
+
+#define lock_policy_rwsem(mode, cpu)				\
+static int lock_policy_rwsem_##mode				\
+(int cpu)							\
+{								\
+	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);	\
+	BUG_ON(policy_cpu == -1);				\
+	down_##mode(&per_cpu(cpu_policy_rwsem, policy_cpu));	\
+								\
+	return 0;						\
+}
+
+lock_policy_rwsem(write, cpu);
+
+static void unlock_policy_rwsem_write(int cpu)
+{
+	int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);
+	BUG_ON(policy_cpu == -1);
+	up_write(&per_cpu(cpu_policy_rwsem, policy_cpu));
+}
+
+/**
+ * The "transition" notifier list for kernel code that needs to handle
+ * changes to devices when the CPU clock speed changes.
+ * The mutex locks this list.
+ */
+static struct srcu_notifier_head xen_cpufreq_transition_notifier_list;
+
+static bool init_cpufreq_transition_notifier_list_called;
+static int __init init_cpufreq_transition_notifier_list(void)
+{
+	srcu_init_notifier_head(&xen_cpufreq_transition_notifier_list);
+	init_cpufreq_transition_notifier_list_called = true;
+	return 0;
+}
+pure_initcall(init_cpufreq_transition_notifier_list);
+
+static struct cpufreq_policy *xen_cpufreq_cpu_get(unsigned int cpu)
+{
+	struct cpufreq_policy *data = NULL;
+	unsigned long flags;
+
+	if (cpu >= xen_nr_cpus)
+		goto err_out;
+
+	/* get the cpufreq driver */
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+
+	if (!cpufreq_driver)
+		goto err_out_unlock;
+
+	/* get the CPU */
+	data = per_cpu(cpufreq_cpu_data, cpu);
+
+err_out_unlock:
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+err_out:
+	return data;
+}
+
+static void xen_cpufreq_cpu_put(struct cpufreq_policy *data)
+{
+	module_put(cpufreq_driver->owner);
+}
+
+static int push_data_to_hypervisor(struct cpufreq_policy *policy,
+				   struct cpufreq_frequency_table *table)
+{
+	int ret = 0;
+	unsigned int i;
+	unsigned int cpu;
+	uint32_t platform_limit = 0;
+	unsigned int max_freq = 0;
+	unsigned int state_count = 0;
+	unsigned int prev_freq = 0;
+	struct xen_processor_px *dst_states;
+	struct xen_processor_performance *dst_perf;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+
+	dst_perf = &op.u.set_pminfo.perf;
+
+	/* Check freq table and find max frequency */
+	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
+		unsigned int freq = table[i].frequency;
+		if (freq == CPUFREQ_ENTRY_INVALID)
+			continue;
+
+		if (table[i].index != state_count || freq <= prev_freq) {
+			pr_err("Frequency table format error\n");
+			return -EINVAL;
+		}
+
+		prev_freq = freq;
+		state_count++;
+		if (freq > max_freq)
+			max_freq = freq;
+	}
+
+	if (!state_count)
+		return -EINVAL;
+
+	dst_perf->state_count = state_count;
+
+	dst_states = kcalloc(state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+
+	if (!dst_states)
+		return -ENOMEM;
+
+	set_xen_guest_handle(dst_perf->states, dst_states);
+
+	/*
+	 * Freq table should start from lower values
+	 * dst_states should start from higer values
+	 */
+	for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
+		unsigned int freq = table[i].frequency;
+		unsigned int tbl_index = state_count - 1 - table[i].index;
+		if (freq == CPUFREQ_ENTRY_INVALID)
+			continue;
+
+		if (freq == max_freq)
+			platform_limit = tbl_index;
+
+		dst_states[tbl_index].core_frequency = freq / 1000;
+		dst_states[tbl_index].transition_latency =
+				policy->cpuinfo.transition_latency / 1000;
+	}
+
+	dst_perf->shared_type = policy->shared_type;
+	dst_perf->platform_limit = platform_limit;
+	dst_perf->domain_info.domain = policy->cpu;
+	dst_perf->domain_info.num_processors = xen_nr_cpus;
+	dst_perf->flags = XEN_PX_DATA;
+
+	for_each_xen_cpu(cpu, policy->cpus) {
+		op.u.set_pminfo.id = cpu;
+		ret = HYPERVISOR_dom0_op(&op);
+		if (ret) {
+			pr_debug("Hypervisor error(%d) for CPU%u\n", ret, cpu);
+			goto err_free_states;
+		}
+		pr_debug("CPU%u - P-states uploaded\n", cpu);
+
+		for (i = 0; i < dst_perf->state_count; i++) {
+			pr_debug("    state %d: %d MHz, %d uS\n",
+				 i, (u32) dst_states[i].core_frequency,
+				 (u32) dst_states[i].transition_latency);
+		}
+	}
+
+err_free_states:
+	kfree(dst_states);
+	return ret;
+}
+
+/*
+ * Returns:
+ *   Negative: Failure
+ *   0:        Success
+ *   Positive: When we have a managed CPU and the sysfs got symlinked
+ */
+static int xen_cpufreq_add_dev_policy(unsigned int cpu,
+				  struct cpufreq_policy *policy)
+{
+	int ret = 0;
+#ifdef CONFIG_SMP
+	unsigned long flags;
+	unsigned int j;
+
+	for_each_cpu(j, policy->cpus) {
+		struct cpufreq_policy *managed_policy;
+
+		if (cpu == j)
+			continue;
+
+		/* Check for existing affected CPUs.
+		 * They may not be aware of it due to CPU Hotplug.
+		 * cpufreq_cpu_put is called when the device is removed
+		 * in __cpufreq_remove_dev()
+		 */
+		managed_policy = xen_cpufreq_cpu_get(j);
+		if (unlikely(managed_policy)) {
+			/* Set proper policy_cpu */
+			unlock_policy_rwsem_write(cpu);
+			per_cpu(cpufreq_policy_cpu, cpu) =
+						managed_policy->cpu;
+
+			if (lock_policy_rwsem_write(cpu) < 0) {
+				/* Should not go through policy unlock path */
+				if (cpufreq_driver->exit)
+					cpufreq_driver->exit(policy);
+				xen_cpufreq_cpu_put(managed_policy);
+				return -EBUSY;
+			}
+
+			spin_lock_irqsave(&cpufreq_driver_lock, flags);
+			cpumask_copy(managed_policy->cpus, policy->cpus);
+			per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
+			spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+			pr_debug("CPU already managed, adding link\n");
+
+			/*
+			 * Success. We only needed to be added to the mask.
+			 * Call driver->exit() because only the cpu parent of
+			 * the kobj needed to call init().
+			 */
+			if (cpufreq_driver->exit)
+				cpufreq_driver->exit(policy);
+
+			return 1;
+		}
+	}
+#endif
+	return ret;
+}
+
+/**
+ * xen_cpufreq_add_dev - add a CPU device
+ *
+ * Adds the cpufreq interface for a CPU device.
+ */
+static int xen_cpufreq_add_dev(unsigned int cpu)
+{
+	int ret = 0;
+	struct cpufreq_policy *policy;
+	unsigned long flags;
+	unsigned int j;
+
+	pr_debug("adding CPU %u\n", cpu);
+
+#ifdef CONFIG_SMP
+	/* check whether a different CPU already registered this
+	 * CPU because it is in the same boat. */
+	policy = xen_cpufreq_cpu_get(cpu);
+	if (unlikely(policy)) {
+		xen_cpufreq_cpu_put(policy);
+		return 0;
+	}
+#endif
+
+	if (!try_module_get(cpufreq_driver->owner)) {
+		ret = -EINVAL;
+		goto module_out;
+	}
+
+	ret = -ENOMEM;
+	policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
+	if (!policy)
+		goto nomem_out;
+
+	if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
+		goto err_free_policy;
+
+	if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
+		goto err_free_cpumask;
+
+	policy->cpu = cpu;
+	cpumask_copy(policy->cpus, cpumask_of(cpu));
+
+	/* Initially set CPU itself as the policy_cpu */
+	per_cpu(cpufreq_policy_cpu, cpu) = cpu;
+	ret = (lock_policy_rwsem_write(cpu) < 0);
+	WARN_ON(ret);
+
+	/* call driver. From then on the cpufreq must be able
+	 * to accept all calls to ->verify and ->setpolicy for this CPU
+	 */
+	ret = cpufreq_driver->init(policy);
+	if (ret) {
+		pr_debug("initialization failed\n");
+		goto err_unlock_policy;
+	}
+	ret = xen_cpufreq_add_dev_policy(cpu, policy);
+	if (ret) {
+		if (ret > 0)
+			/* This is a managed cpu, symlink created,
+			   exit with 0 */
+			ret = 0;
+		goto err_unlock_policy;
+	}
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	for_each_cpu(j, policy->cpus) {
+		per_cpu(cpufreq_cpu_data, j) = policy;
+		per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
+	}
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	unlock_policy_rwsem_write(cpu);
+
+	module_put(cpufreq_driver->owner);
+	pr_debug("initialization complete\n");
+
+	return 0;
+
+err_unlock_policy:
+	unlock_policy_rwsem_write(cpu);
+	free_cpumask_var(policy->related_cpus);
+err_free_cpumask:
+	free_cpumask_var(policy->cpus);
+err_free_policy:
+	kfree(policy);
+nomem_out:
+	module_put(cpufreq_driver->owner);
+module_out:
+	return ret;
+}
+
+/**
+ * __cpufreq_remove_dev - remove a CPU device
+ *
+ * Removes the cpufreq interface for a CPU device.
+ * Caller should already have policy_rwsem in write mode for this CPU.
+ * This routine frees the rwsem before returning.
+ */
+static int __cpufreq_remove_dev(unsigned int cpu)
+{
+	unsigned long flags;
+	struct cpufreq_policy *data;
+#ifdef CONFIG_SMP
+	unsigned int j;
+#endif
+
+	pr_debug("unregistering CPU %u\n", cpu);
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	data = per_cpu(cpufreq_cpu_data, cpu);
+
+	if (!data) {
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		unlock_policy_rwsem_write(cpu);
+		return -EINVAL;
+	}
+	per_cpu(cpufreq_cpu_data, cpu) = NULL;
+
+
+#ifdef CONFIG_SMP
+	/* if this isn't the CPU which is the parent of the kobj, we
+	 * only need to unlink, put and exit
+	 */
+	if (unlikely(cpu != data->cpu)) {
+		pr_debug("removing link\n");
+		cpumask_clear_cpu(cpu, data->cpus);
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		xen_cpufreq_cpu_put(data);
+		unlock_policy_rwsem_write(cpu);
+		return 0;
+	}
+#endif
+
+#ifdef CONFIG_SMP
+
+	/* if we have other CPUs still registered, we need to unlink them,
+	 * or else wait_for_completion below will lock up. Clean the
+	 * per_cpu(cpufreq_cpu_data) while holding the lock, and remove
+	 * the sysfs links afterwards.
+	 */
+	if (unlikely(cpumask_weight(data->cpus) > 1)) {
+		for_each_cpu(j, data->cpus) {
+			if (j == cpu)
+				continue;
+			per_cpu(cpufreq_cpu_data, j) = NULL;
+		}
+	}
+
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	if (unlikely(cpumask_weight(data->cpus) > 1)) {
+		for_each_cpu(j, data->cpus) {
+			if (j == cpu)
+				continue;
+			pr_debug("removing link for cpu %u\n", j);
+			unlock_policy_rwsem_write(cpu);
+			lock_policy_rwsem_write(cpu);
+			xen_cpufreq_cpu_put(data);
+		}
+	}
+#else
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+#endif
+
+	unlock_policy_rwsem_write(cpu);
+
+	lock_policy_rwsem_write(cpu);
+	if (cpufreq_driver->exit)
+		cpufreq_driver->exit(data);
+	unlock_policy_rwsem_write(cpu);
+
+	free_cpumask_var(data->related_cpus);
+	free_cpumask_var(data->cpus);
+	kfree(data);
+
+	return 0;
+}
+
+static int cpufreq_remove_dev(unsigned int cpu)
+{
+	int retval;
+
+	if (unlikely(lock_policy_rwsem_write(cpu)))
+		BUG();
+
+	retval = __cpufreq_remove_dev(cpu);
+	return retval;
+}
+
+/*********************************************************************
+ *            EXTERNALLY AFFECTING FREQUENCY CHANGES                 *
+ *********************************************************************/
+
+/**
+ * adjust_jiffies - adjust the system "loops_per_jiffy"
+ *
+ * This function alters the system "loops_per_jiffy" for the clock
+ * speed change. Note that loops_per_jiffy cannot be updated on SMP
+ * systems as each CPU might be scaled differently. So, use the arch
+ * per-CPU loops_per_jiffy value wherever possible.
+ */
+#ifndef CONFIG_SMP
+static unsigned long l_p_j_ref;
+static unsigned int  l_p_j_ref_freq;
+
+static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
+{
+	if (ci->flags & CPUFREQ_CONST_LOOPS)
+		return;
+
+	if (!l_p_j_ref_freq) {
+		l_p_j_ref = loops_per_jiffy;
+		l_p_j_ref_freq = ci->old;
+		pr_debug("saving %lu as reference value for loops_per_jiffy; "
+			"freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
+	}
+	if ((val == CPUFREQ_POSTCHANGE  && ci->old != ci->new) ||
+	    (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
+		loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
+								ci->new);
+		pr_debug("scaling loops_per_jiffy to %lu "
+			"for frequency %u kHz\n", loops_per_jiffy, ci->new);
+	}
+}
+#else
+static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
+{
+	return;
+}
+#endif
+
+
+/**
+ * xen_cpufreq_notify_transition - call notifier chain and adjust_jiffies
+ * on frequency transition.
+ *
+ * This function calls the transition notifiers and the "adjust_jiffies"
+ * function. It is called twice on all CPU frequency changes that have
+ * external effects.
+ */
+void xen_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
+				   unsigned int state)
+{
+	struct cpufreq_policy *policy;
+
+	BUG_ON(irqs_disabled());
+
+	freqs->flags = cpufreq_driver->flags;
+	pr_debug("notification %u of frequency transition to %u kHz\n",
+		 state, freqs->new);
+
+	policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
+	switch (state) {
+	case CPUFREQ_PRECHANGE:
+		/* detect if the driver reported a value as "old frequency"
+		 * which is not equal to what the cpufreq core thinks is
+		 * "old frequency".
+		 */
+		if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
+			if ((policy) && (policy->cpu == freqs->cpu) &&
+			    (policy->cur) && (policy->cur != freqs->old)) {
+				pr_debug("Warning: CPU frequency is"
+					 " %u, cpufreq assumed %u kHz.\n",
+					 freqs->old, policy->cur);
+				freqs->old = policy->cur;
+			}
+		}
+		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
+					 CPUFREQ_PRECHANGE, freqs);
+		adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
+		break;
+
+	case CPUFREQ_POSTCHANGE:
+		adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
+		pr_debug("FREQ: %lu - CPU: %lu\n", (unsigned long)freqs->new,
+			 (unsigned long)freqs->cpu);
+		trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
+		trace_cpu_frequency(freqs->new, freqs->cpu);
+		srcu_notifier_call_chain(&xen_cpufreq_transition_notifier_list,
+					 CPUFREQ_POSTCHANGE, freqs);
+		if (likely(policy) && likely(policy->cpu == freqs->cpu))
+			policy->cur = freqs->new;
+		break;
+	}
+}
+
+/*********************************************************************
+ *                              GOVERNORS                            *
+ *********************************************************************/
+
+int __xen_cpufreq_driver_target(struct cpufreq_policy *policy,
+				unsigned int target_freq,
+				unsigned int relation)
+{
+	int retval = -EINVAL;
+	unsigned int old_target_freq = target_freq;
+
+	/* Make sure that target_freq is within supported range */
+	if (target_freq > policy->max)
+		target_freq = policy->max;
+	if (target_freq < policy->min)
+		target_freq = policy->min;
+
+	pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
+		 policy->cpu, target_freq, relation, old_target_freq);
+
+	if (target_freq == policy->cur)
+		return 0;
+
+	if (cpufreq_driver->target)
+		retval = cpufreq_driver->target(policy, target_freq,
+						    relation);
+
+	return retval;
+}
+
+int xen_cpufreq_driver_target(struct cpufreq_policy *policy,
+			      unsigned int target_freq,
+			      unsigned int relation)
+{
+	int ret = -EINVAL;
+
+	if (!policy)
+		goto no_policy;
+
+	if (unlikely(lock_policy_rwsem_write(policy->cpu)))
+		goto fail;
+
+	ret = __xen_cpufreq_driver_target(policy, target_freq, relation);
+
+	unlock_policy_rwsem_write(policy->cpu);
+
+fail:
+	xen_cpufreq_cpu_put(policy);
+no_policy:
+	return ret;
+}
+
+/*********************************************************************
+ *                    HANDLE COMMANDS FROM XEN                       *
+ *********************************************************************/
+static void cpufreq_work_hnd(struct work_struct *w);
+
+static struct workqueue_struct *cpufreq_wq;
+static DECLARE_WORK(cpufreq_work, cpufreq_work_hnd);
+
+static void cpufreq_work_hnd(struct work_struct *w)
+{
+	int ret;
+	struct cpufreq_policy *policy;
+	struct cpufreq_sh_info *cpufreq_info;
+
+	cpufreq_info = &HYPERVISOR_shared_info->arch.cpufreq;
+
+	policy = xen_cpufreq_cpu_get(cpufreq_info->cpu);
+
+	/* Set parameters in the Xen then read it */
+	smp_rmb();
+
+	/* accept only CPUFREQ_CMD_change_freq */
+	if (cpufreq_info->cmd != CPUFREQ_CMD_change_freq)
+		return;
+
+	ret = xen_cpufreq_driver_target(policy,
+					cpufreq_info->freq,
+					cpufreq_info->relation);
+
+	cpufreq_info->result = ret;
+	smp_wmb(); /* above must be visible before notify_remote_via_irq() */
+
+	notify_remote_via_irq(xen_irq);
+}
+
+static irqreturn_t cpufreq_interrupt(int irq, void *data)
+{
+	queue_work(cpufreq_wq, &cpufreq_work);
+	return IRQ_HANDLED;
+}
+
+/*********************************************************************
+ *                    XEN CPUFREQ EVENTS                             *
+ *********************************************************************/
+static int xen_start_cpufreq_event(uint32_t *port)
+{
+	int ret;
+	struct xen_sysctl op = {
+		.cmd = XEN_SYSCTL_cpufreq_op,
+		.interface_version = XEN_SYSCTL_INTERFACE_VERSION,
+		.u.cpufreq_op.cmd = XEN_SYSCTL_CPUFREQ_event_start,
+	};
+
+	ret = HYPERVISOR_sysctl(&op);
+	if (unlikely(ret))
+		pr_err("Hypervisor cpufreq strart event error (%d)\n", ret);
+	else
+		*port = op.u.cpufreq_op.port;
+
+	return ret;
+}
+
+static int xen_stop_cpufreq_event(void)
+{
+	int ret;
+	struct xen_sysctl op = {
+		.cmd = XEN_SYSCTL_cpufreq_op,
+		.interface_version = XEN_SYSCTL_INTERFACE_VERSION,
+		.u.cpufreq_op.cmd = XEN_SYSCTL_CPUFREQ_event_stop,
+	};
+
+	ret = HYPERVISOR_sysctl(&op);
+	if (ret)
+		pr_err("Hypervisor cpufreq stop event error (%d)\n", ret);
+
+	return ret;
+}
+
+/*********************************************************************
+ *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
+ *********************************************************************/
+
+/**
+ * xen_cpufreq_register_driver - register a CPU Frequency driver
+ * @driver_data: A struct cpufreq_driver containing the values#
+ * submitted by the CPU Frequency driver.
+ *
+ *   Registers a CPU Frequency driver to this core code. This code
+ * returns zero on success, -EBUSY when another driver got here first
+ * (and isn't unregistered in the meantime).
+ *
+ */
+int xen_cpufreq_register_driver(struct cpufreq_driver *driver_data)
+{
+	unsigned long flags;
+	int ret;
+	unsigned int cpu;
+	struct cpufreq_frequency_table *table;
+	struct cpufreq_policy *policy;
+	cpumask_var_t pushed_cpus;
+	uint32_t port;
+	int irq;
+
+	if (!xen_nr_cpus)
+		return -EPROBE_DEFER;
+
+	if (!driver_data || !driver_data->verify || !driver_data->init ||
+	    (!driver_data->target))
+		return -EINVAL;
+
+	pr_debug("trying to register driver %s\n", driver_data->name);
+
+	if (driver_data->setpolicy)
+		driver_data->flags |= CPUFREQ_CONST_LOOPS;
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+
+	if (cpufreq_driver) {
+		spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+		return -EBUSY;
+	}
+	cpufreq_driver = driver_data;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	ret = xen_start_cpufreq_event(&port);
+	if (ret)
+		goto err_remove_drv;
+
+	irq = bind_interdomain_evtchn_to_irqhandler(DOMID_SELF, port,
+						    cpufreq_interrupt, 0,
+						    "xen_cpufreq", NULL);
+
+	if (irq < 0) {
+		pr_err("bind interdomain evtchn to irqhandler error (%d)\n",
+		       irq);
+		ret = irq;
+		goto err_stop_cpufreq_event;
+	}
+	xen_irq = irq;
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
+		ret = xen_cpufreq_add_dev(cpu);
+		if (ret)
+			goto err_remove_cpu;
+	}
+
+	if (!zalloc_cpumask_var(&pushed_cpus, GFP_KERNEL))
+		goto err_remove_cpu;
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++) {
+		if (cpumask_test_cpu(cpu, pushed_cpus))
+			continue;
+
+		policy = xen_cpufreq_cpu_get(cpu);
+		if (!policy) {
+			ret = -EINVAL;
+			goto err_free_cpumask;
+		}
+
+		cpumask_or(pushed_cpus, pushed_cpus, policy->cpus);
+		table = cpufreq_frequency_get_table(policy->cpu);
+		if (!table) {
+			ret = -EINVAL;
+			goto err_free_cpumask;
+		}
+
+		ret = push_data_to_hypervisor(policy, table);
+		if (ret)
+			goto err_free_cpumask;
+	}
+
+	free_cpumask_var(pushed_cpus);
+
+	pr_debug("driver %s up and running\n", driver_data->name);
+
+	return 0;
+
+err_free_cpumask:
+	free_cpumask_var(pushed_cpus);
+err_remove_cpu:
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
+		cpufreq_remove_dev(cpu);
+	unbind_from_irqhandler(irq, NULL);
+err_stop_cpufreq_event:
+	xen_stop_cpufreq_event();
+err_remove_drv:
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	cpufreq_driver = NULL;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+	return ret;
+}
+
+/**
+ * xen_cpufreq_unregister_driver - unregister the current CPUFreq driver
+ *
+ *    Unregister the current CPUFreq driver. Only call this if you have
+ * the right to do so, i.e. if you have succeeded in initialising before!
+ * Returns zero if successful, and -EINVAL if the cpufreq_driver is
+ * currently not initialised.
+ */
+int xen_cpufreq_unregister_driver(struct cpufreq_driver *driver)
+{
+	unsigned long flags;
+	unsigned int cpu;
+
+	if (!cpufreq_driver || (driver != cpufreq_driver))
+		return -EINVAL;
+
+	pr_debug("unregistering driver %s\n", driver->name);
+
+	unbind_from_irqhandler(xen_irq, NULL);
+	xen_stop_cpufreq_event();
+
+	for (cpu = 0; cpu < xen_nr_cpus; cpu++)
+		cpufreq_remove_dev(cpu);
+
+	spin_lock_irqsave(&cpufreq_driver_lock, flags);
+	cpufreq_driver = NULL;
+	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	return 0;
+}
+
+struct cpufreq_drv_ops xen_cpufreq_drv_ops = {
+	.notify_transition = xen_cpufreq_notify_transition,
+	.register_driver = xen_cpufreq_register_driver,
+	.unregister_driver = xen_cpufreq_unregister_driver,
+};
+
+static int __init xen_cpufreq_init(void)
+{
+	int ret;
+	int i;
+
+	struct xen_sysctl op = {
+		.cmd			= XEN_SYSCTL_physinfo,
+		.interface_version	= XEN_SYSCTL_INTERFACE_VERSION,
+	};
+
+	ret = HYPERVISOR_sysctl(&op);
+	if (ret) {
+		pr_err("Hypervisor get physinfo error (%d)\n", ret);
+		return ret;
+	}
+
+	xen_nr_cpus = op.u.physinfo.nr_cpus;
+	if (xen_nr_cpus == 0 || xen_nr_cpus > NR_CPUS) {
+		xen_nr_cpus = 0;
+		pr_err("Wrong CPUs amount (%d)\n", xen_nr_cpus);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < xen_nr_cpus; i++) {
+		per_cpu(cpufreq_policy_cpu, i) = -1;
+		init_rwsem(&per_cpu(cpu_policy_rwsem, i));
+	}
+
+	cpufreq_wq = create_singlethread_workqueue("xen_cpufreq");
+	if (!cpufreq_wq) {
+		pr_err("Create workqueue error\n");
+		ret = -ENOMEM;
+		goto err_create_wq;
+	}
+
+	return 0;
+
+err_create_wq:
+	xen_nr_cpus = 0;
+	return ret;
+}
+
+MODULE_AUTHOR("Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>");
+MODULE_DESCRIPTION("Xen cpufreq driver which uploads PM data to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+core_initcall(xen_cpufreq_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c57d5f6..ee3b154 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -209,6 +209,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
 #define XEN_PX_PSS   2
 #define XEN_PX_PPC   4
 #define XEN_PX_PSD   8
+#define XEN_PX_DATA  16
 
 struct xen_power_register {
 	uint32_t     space_id;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:34:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:34:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBaR-0001E8-Uk; Tue, 11 Nov 2014 13:34:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoBaQ-0001E3-Tw
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 13:34:23 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E3/F0-17694-E5012645; Tue, 11 Nov 2014 13:34:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415712860!8095350!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14225 invoked from network); 11 Nov 2014 13:34:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 13:34:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,361,1413244800"; d="scan'208";a="191554668"
Message-ID: <5462105A.6020100@citrix.com>
Date: Tue, 11 Nov 2014 13:34:18 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
	<5457C35F.50504@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
In-Reply-To: <2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
X-DLP: MIA2
Cc: "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 12:27, Thanos Makatos wrote:
>> The arbitrary limitations in number of ops and page alignment should be
>> removed.  I think both can be removed relatively easily by consuming page
>> aligned chunks of segments and doign the hypercall when a batch of ops is
>> filled.
> 
> Wouldn't this lead to multiple calls to gnttab_batch_copy(), potentially hurting performance?

The incremental benefits of batching diminishes as the batch size increase.

We also don't want multi-page allocations in this driver, so the batch
size should be set accordingly.

>>> +#define IOCTL_GNTDEV_GRANT_COPY \
>>> +_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
>>> +struct ioctl_gntdev_grant_copy {
>>> +	/*
>>> +	 * copy direction: 0 to copy to guest, 1 to copy from guest
>>> +	 */
>>> +	int dir;
>>
>> I think this dir should be per-segment and use the GNTCPY_source_gref and
>> GNTCOPY_dest_gref flags, since per-op direction is what the hypercall
>> provides.
> 
> OK.

The interface should also support grant to grant copies.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:34:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:34:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBaR-0001E8-Uk; Tue, 11 Nov 2014 13:34:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoBaQ-0001E3-Tw
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 13:34:23 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E3/F0-17694-E5012645; Tue, 11 Nov 2014 13:34:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415712860!8095350!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14225 invoked from network); 11 Nov 2014 13:34:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 13:34:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,361,1413244800"; d="scan'208";a="191554668"
Message-ID: <5462105A.6020100@citrix.com>
Date: Tue, 11 Nov 2014 13:34:18 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
	<5457C35F.50504@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
In-Reply-To: <2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
X-DLP: MIA2
Cc: "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 12:27, Thanos Makatos wrote:
>> The arbitrary limitations in number of ops and page alignment should be
>> removed.  I think both can be removed relatively easily by consuming page
>> aligned chunks of segments and doign the hypercall when a batch of ops is
>> filled.
> 
> Wouldn't this lead to multiple calls to gnttab_batch_copy(), potentially hurting performance?

The incremental benefits of batching diminishes as the batch size increase.

We also don't want multi-page allocations in this driver, so the batch
size should be set accordingly.

>>> +#define IOCTL_GNTDEV_GRANT_COPY \
>>> +_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
>>> +struct ioctl_gntdev_grant_copy {
>>> +	/*
>>> +	 * copy direction: 0 to copy to guest, 1 to copy from guest
>>> +	 */
>>> +	int dir;
>>
>> I think this dir should be per-segment and use the GNTCPY_source_gref and
>> GNTCOPY_dest_gref flags, since per-op direction is what the hypercall
>> provides.
> 
> OK.

The interface should also support grant to grant copies.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:47:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBmT-0001Ug-Fc; Tue, 11 Nov 2014 13:46:49 +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 1XoBmR-0001Ua-CG
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:46:47 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	C6/42-26858-64312645; Tue, 11 Nov 2014 13:46:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415713604!11868343!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17011 invoked from network); 11 Nov 2014 13:46:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 13:46:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,361,1413244800"; d="scan'208";a="191559451"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 08:46:43 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XoBmN-0004c5-Kl;
	Tue, 11 Nov 2014 13:46:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 11 Nov 2014 13:46:43 +0000
Message-ID: <1415713603-14611-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
---
This is a simple enough bug fix I think it should just go in.
---
 tools/libxl/libxl.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..de23fec 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
                                                                         \
         GCNEW(aodev);                                                   \
         libxl__prepare_ao_device(ao, aodev);                            \
+        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
         aodev->callback = device_addrm_aocomplete;                      \
         aodev->update_json = true;                                      \
         libxl__device_##type##_add(egc, domid, type, aodev);            \
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 13:47:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 13:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoBmT-0001Ug-Fc; Tue, 11 Nov 2014 13:46:49 +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 1XoBmR-0001Ua-CG
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 13:46:47 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	C6/42-26858-64312645; Tue, 11 Nov 2014 13:46:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415713604!11868343!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17011 invoked from network); 11 Nov 2014 13:46:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 13:46:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,361,1413244800"; d="scan'208";a="191559451"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 08:46:43 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XoBmN-0004c5-Kl;
	Tue, 11 Nov 2014 13:46:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 11 Nov 2014 13:46:43 +0000
Message-ID: <1415713603-14611-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
---
This is a simple enough bug fix I think it should just go in.
---
 tools/libxl/libxl.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..de23fec 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
                                                                         \
         GCNEW(aodev);                                                   \
         libxl__prepare_ao_device(ao, aodev);                            \
+        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
         aodev->callback = device_addrm_aocomplete;                      \
         aodev->update_json = true;                                      \
         libxl__device_##type##_add(egc, domid, type, aodev);            \
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:18:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:18:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCGU-0002Pd-RA; Tue, 11 Nov 2014 14:17:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoCGT-0002PY-P0
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:17:49 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	36/A7-22819-D8A12645; Tue, 11 Nov 2014 14:17:49 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415715468!11784418!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16909 invoked from network); 11 Nov 2014 14:17:48 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 14:17:48 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id F40E7AB07;
	Tue, 11 Nov 2014 14:17:47 +0000 (UTC)
Message-ID: <54621A8B.6080206@suse.com>
Date: Tue, 11 Nov 2014 15:17:47 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, xen-devel@lists.xensource.com
References: <19147765.FEreuxd8Ya@amur>
In-Reply-To: <19147765.FEreuxd8Ya@amur>
Content-Type: multipart/mixed; boundary="------------020805050402090407040208"
Subject: Re: [Xen-devel] Wrong cpupool handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------020805050402090407040208
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dietmar,

On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
> Hi list,
>
> When creating a cpupool, starting and destroying a guest within this pool,
> then removing this pool doesn't work because of EBUSY.
>
> It seems the cause of this behavior is the commit
> bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
>
> In domain_kill() the function sched_move_domain() gets called changing the
> d->cpupool pointer to the new cpupool without incrementing/decrementing the
> counters "n_dom" of the new/old cpupool.
>
> This leads to decrementing the wrong  cpupool0->n_dom counter when
> cpupool_rm_domain() gets called at the end and my own cpupool can't be
> destroyed because n_dom = 1!
>
> I don't have a fast patch because I'am not enough familiar with the code
> this time but I think it should be fixed for 4.5.

Could you try the attached (untested) patch? Should apply to HEAD.

Juergen


--------------020805050402090407040208
Content-Type: text/x-patch;
 name="0001-Adjust-number-of-domains-in-cpupools-when-destroying.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0001-Adjust-number-of-domains-in-cpupools-when-destroying.pa";
 filename*1="tch"

>From f231f837b6dffd071c59517286562ccde7c5b5bc Mon Sep 17 00:00:00 2001
From: Juergen Gross <jgross@suse.com>
Date: Tue, 11 Nov 2014 15:03:33 +0100
Subject: [PATCH] Adjust number of domains in cpupools when destroying domain

Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of domains
is nor adjusted when a domain is moved to cpupool0 in kill_domain().

Correct this by introducing a cpupool function doing the move
instead of open coding it by calling sched_move_domain().

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/common/cpupool.c    | 46 +++++++++++++++++++++++++++++++++-------------
 xen/common/domain.c     |  2 +-
 xen/include/xen/sched.h |  1 +
 3 files changed, 35 insertions(+), 14 deletions(-)

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 73249d3..552d791 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
 }
 
 /*
+ * Move domain to another cpupool
+ */
+static int cpupool_move_domain_unlocked(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    d->cpupool->n_dom--;
+    ret = sched_move_domain(d, c);
+    if ( ret )
+        d->cpupool->n_dom++;
+    else
+        c->n_dom++;
+
+    return ret;
+}
+int cpupool_move_domain(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    spin_lock(&cpupool_lock);
+
+    ret = cpupool_move_domain_unlocked(d, c);
+
+    spin_unlock(&cpupool_lock);
+
+    return ret;
+}
+
+/*
  * assign a specific cpu to a cpupool
  * cpupool_lock must be held
  */
@@ -338,13 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
                 ret = -EBUSY;
                 break;
             }
-            c->n_dom--;
-            ret = sched_move_domain(d, cpupool0);
+            ret = cpupool_move_domain_unlocked(d, cpupool0);
             if ( ret )
-            {
-                c->n_dom++;
                 break;
-            }
             cpupool0->n_dom++;
         }
         rcu_read_unlock(&domlist_read_lock);
@@ -613,16 +638,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
                         d->domain_id, op->cpupool_id);
         ret = -ENOENT;
         spin_lock(&cpupool_lock);
+
         c = cpupool_find_by_id(op->cpupool_id);
         if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
-        {
-            d->cpupool->n_dom--;
-            ret = sched_move_domain(d, c);
-            if ( ret )
-                d->cpupool->n_dom++;
-            else
-                c->n_dom++;
-        }
+            ret = cpupool_move_domain_unlocked(d, c);
+
         spin_unlock(&cpupool_lock);
         cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
                         d->domain_id, op->cpupool_id, ret);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index a3f51ec..4a62c1d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
                 rc = -EAGAIN;
             break;
         }
-        if ( sched_move_domain(d, cpupool0) )
+        if ( cpupool_move_domain(d, cpupool0) )
             return -EAGAIN;
         for_each_vcpu ( d, v )
             unmap_vcpu_info(v);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index c5157e6..46fc6e3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
 void cpupool_put(struct cpupool *pool);
 int cpupool_add_domain(struct domain *d, int poolid);
 void cpupool_rm_domain(struct domain *d);
+int cpupool_move_domain(struct domain *d, struct cpupool *c);
 int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
 void schedule_dump(struct cpupool *c);
 extern void dump_runq(unsigned char key);
-- 
2.1.2


--------------020805050402090407040208
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020805050402090407040208--


From xen-devel-bounces@lists.xen.org Tue Nov 11 14:18:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:18:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCGU-0002Pd-RA; Tue, 11 Nov 2014 14:17:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoCGT-0002PY-P0
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:17:49 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	36/A7-22819-D8A12645; Tue, 11 Nov 2014 14:17:49 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415715468!11784418!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16909 invoked from network); 11 Nov 2014 14:17:48 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 14:17:48 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id F40E7AB07;
	Tue, 11 Nov 2014 14:17:47 +0000 (UTC)
Message-ID: <54621A8B.6080206@suse.com>
Date: Tue, 11 Nov 2014 15:17:47 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, xen-devel@lists.xensource.com
References: <19147765.FEreuxd8Ya@amur>
In-Reply-To: <19147765.FEreuxd8Ya@amur>
Content-Type: multipart/mixed; boundary="------------020805050402090407040208"
Subject: Re: [Xen-devel] Wrong cpupool handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------020805050402090407040208
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dietmar,

On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
> Hi list,
>
> When creating a cpupool, starting and destroying a guest within this pool,
> then removing this pool doesn't work because of EBUSY.
>
> It seems the cause of this behavior is the commit
> bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
>
> In domain_kill() the function sched_move_domain() gets called changing the
> d->cpupool pointer to the new cpupool without incrementing/decrementing the
> counters "n_dom" of the new/old cpupool.
>
> This leads to decrementing the wrong  cpupool0->n_dom counter when
> cpupool_rm_domain() gets called at the end and my own cpupool can't be
> destroyed because n_dom = 1!
>
> I don't have a fast patch because I'am not enough familiar with the code
> this time but I think it should be fixed for 4.5.

Could you try the attached (untested) patch? Should apply to HEAD.

Juergen


--------------020805050402090407040208
Content-Type: text/x-patch;
 name="0001-Adjust-number-of-domains-in-cpupools-when-destroying.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0001-Adjust-number-of-domains-in-cpupools-when-destroying.pa";
 filename*1="tch"

>From f231f837b6dffd071c59517286562ccde7c5b5bc Mon Sep 17 00:00:00 2001
From: Juergen Gross <jgross@suse.com>
Date: Tue, 11 Nov 2014 15:03:33 +0100
Subject: [PATCH] Adjust number of domains in cpupools when destroying domain

Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of domains
is nor adjusted when a domain is moved to cpupool0 in kill_domain().

Correct this by introducing a cpupool function doing the move
instead of open coding it by calling sched_move_domain().

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/common/cpupool.c    | 46 +++++++++++++++++++++++++++++++++-------------
 xen/common/domain.c     |  2 +-
 xen/include/xen/sched.h |  1 +
 3 files changed, 35 insertions(+), 14 deletions(-)

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 73249d3..552d791 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
 }
 
 /*
+ * Move domain to another cpupool
+ */
+static int cpupool_move_domain_unlocked(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    d->cpupool->n_dom--;
+    ret = sched_move_domain(d, c);
+    if ( ret )
+        d->cpupool->n_dom++;
+    else
+        c->n_dom++;
+
+    return ret;
+}
+int cpupool_move_domain(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    spin_lock(&cpupool_lock);
+
+    ret = cpupool_move_domain_unlocked(d, c);
+
+    spin_unlock(&cpupool_lock);
+
+    return ret;
+}
+
+/*
  * assign a specific cpu to a cpupool
  * cpupool_lock must be held
  */
@@ -338,13 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
                 ret = -EBUSY;
                 break;
             }
-            c->n_dom--;
-            ret = sched_move_domain(d, cpupool0);
+            ret = cpupool_move_domain_unlocked(d, cpupool0);
             if ( ret )
-            {
-                c->n_dom++;
                 break;
-            }
             cpupool0->n_dom++;
         }
         rcu_read_unlock(&domlist_read_lock);
@@ -613,16 +638,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
                         d->domain_id, op->cpupool_id);
         ret = -ENOENT;
         spin_lock(&cpupool_lock);
+
         c = cpupool_find_by_id(op->cpupool_id);
         if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
-        {
-            d->cpupool->n_dom--;
-            ret = sched_move_domain(d, c);
-            if ( ret )
-                d->cpupool->n_dom++;
-            else
-                c->n_dom++;
-        }
+            ret = cpupool_move_domain_unlocked(d, c);
+
         spin_unlock(&cpupool_lock);
         cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
                         d->domain_id, op->cpupool_id, ret);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index a3f51ec..4a62c1d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
                 rc = -EAGAIN;
             break;
         }
-        if ( sched_move_domain(d, cpupool0) )
+        if ( cpupool_move_domain(d, cpupool0) )
             return -EAGAIN;
         for_each_vcpu ( d, v )
             unmap_vcpu_info(v);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index c5157e6..46fc6e3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
 void cpupool_put(struct cpupool *pool);
 int cpupool_add_domain(struct domain *d, int poolid);
 void cpupool_rm_domain(struct domain *d);
+int cpupool_move_domain(struct domain *d, struct cpupool *c);
 int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
 void schedule_dump(struct cpupool *c);
 extern void dump_runq(unsigned char key);
-- 
2.1.2


--------------020805050402090407040208
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020805050402090407040208--


From xen-devel-bounces@lists.xen.org Tue Nov 11 14:21:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:21:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCJd-0002Vz-FR; Tue, 11 Nov 2014 14:21:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoCJb-0002Vt-Hv
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:21:04 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	5F/29-17694-E4B12645; Tue, 11 Nov 2014 14:21:02 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415715661!11782875!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4947 invoked from network); 11 Nov 2014 14:21:02 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 14:21:02 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id BCC64AB07;
	Tue, 11 Nov 2014 14:21:01 +0000 (UTC)
Message-ID: <54621B4D.7000408@suse.com>
Date: Tue, 11 Nov 2014 15:21:01 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, xen-devel@lists.xensource.com
References: <19147765.FEreuxd8Ya@amur>
In-Reply-To: <19147765.FEreuxd8Ya@amur>
Content-Type: multipart/mixed; boundary="------------070605070108000505020609"
Subject: Re: [Xen-devel] Wrong cpupool handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------070605070108000505020609
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi again,

On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
> Hi list,
>
> When creating a cpupool, starting and destroying a guest within this pool,
> then removing this pool doesn't work because of EBUSY.
>
> It seems the cause of this behavior is the commit
> bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
>
> In domain_kill() the function sched_move_domain() gets called changing the
> d->cpupool pointer to the new cpupool without incrementing/decrementing the
> counters "n_dom" of the new/old cpupool.
>
> This leads to decrementing the wrong  cpupool0->n_dom counter when
> cpupool_rm_domain() gets called at the end and my own cpupool can't be
> destroyed because n_dom = 1!
>
> I don't have a fast patch because I'am not enough familiar with the code
> this time but I think it should be fixed for 4.5.

Please discard previous patch, try this one.

Juergen


--------------070605070108000505020609
Content-Type: text/x-patch;
 name="0001-Adjust-number-of-domains-in-cpupools-when-destroying.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0001-Adjust-number-of-domains-in-cpupools-when-destroying.pa";
 filename*1="tch"

>From 629a7fe8ed07a13304d9378d357420ec885f59e3 Mon Sep 17 00:00:00 2001
From: Juergen Gross <jgross@suse.com>
Date: Tue, 11 Nov 2014 15:03:33 +0100
Subject: [PATCH] Adjust number of domains in cpupools when destroying domain

Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of domains
is nor adjusted when a domain is moved to cpupool0 in kill_domain().

Correct this by introducing a cpupool function doing the move
instead of open coding it by calling sched_move_domain().

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
 xen/common/domain.c     |  2 +-
 xen/include/xen/sched.h |  1 +
 3 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 73249d3..c6e3869 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
 }
 
 /*
+ * Move domain to another cpupool
+ */
+static int cpupool_move_domain_unlocked(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    d->cpupool->n_dom--;
+    ret = sched_move_domain(d, c);
+    if ( ret )
+        d->cpupool->n_dom++;
+    else
+        c->n_dom++;
+
+    return ret;
+}
+int cpupool_move_domain(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    spin_lock(&cpupool_lock);
+
+    ret = cpupool_move_domain_unlocked(d, c);
+
+    spin_unlock(&cpupool_lock);
+
+    return ret;
+}
+
+/*
  * assign a specific cpu to a cpupool
  * cpupool_lock must be held
  */
@@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
                 ret = -EBUSY;
                 break;
             }
-            c->n_dom--;
-            ret = sched_move_domain(d, cpupool0);
+            ret = cpupool_move_domain_unlocked(d, cpupool0);
             if ( ret )
-            {
-                c->n_dom++;
                 break;
-            }
-            cpupool0->n_dom++;
         }
         rcu_read_unlock(&domlist_read_lock);
         if ( ret )
@@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
                         d->domain_id, op->cpupool_id);
         ret = -ENOENT;
         spin_lock(&cpupool_lock);
+
         c = cpupool_find_by_id(op->cpupool_id);
         if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
-        {
-            d->cpupool->n_dom--;
-            ret = sched_move_domain(d, c);
-            if ( ret )
-                d->cpupool->n_dom++;
-            else
-                c->n_dom++;
-        }
+            ret = cpupool_move_domain_unlocked(d, c);
+
         spin_unlock(&cpupool_lock);
         cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
                         d->domain_id, op->cpupool_id, ret);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index a3f51ec..4a62c1d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
                 rc = -EAGAIN;
             break;
         }
-        if ( sched_move_domain(d, cpupool0) )
+        if ( cpupool_move_domain(d, cpupool0) )
             return -EAGAIN;
         for_each_vcpu ( d, v )
             unmap_vcpu_info(v);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index c5157e6..46fc6e3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
 void cpupool_put(struct cpupool *pool);
 int cpupool_add_domain(struct domain *d, int poolid);
 void cpupool_rm_domain(struct domain *d);
+int cpupool_move_domain(struct domain *d, struct cpupool *c);
 int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
 void schedule_dump(struct cpupool *c);
 extern void dump_runq(unsigned char key);
-- 
2.1.2


--------------070605070108000505020609
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------070605070108000505020609--


From xen-devel-bounces@lists.xen.org Tue Nov 11 14:21:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:21:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCJd-0002Vz-FR; Tue, 11 Nov 2014 14:21:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoCJb-0002Vt-Hv
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:21:04 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	5F/29-17694-E4B12645; Tue, 11 Nov 2014 14:21:02 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415715661!11782875!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4947 invoked from network); 11 Nov 2014 14:21:02 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 14:21:02 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id BCC64AB07;
	Tue, 11 Nov 2014 14:21:01 +0000 (UTC)
Message-ID: <54621B4D.7000408@suse.com>
Date: Tue, 11 Nov 2014 15:21:01 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, xen-devel@lists.xensource.com
References: <19147765.FEreuxd8Ya@amur>
In-Reply-To: <19147765.FEreuxd8Ya@amur>
Content-Type: multipart/mixed; boundary="------------070605070108000505020609"
Subject: Re: [Xen-devel] Wrong cpupool handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------070605070108000505020609
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi again,

On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
> Hi list,
>
> When creating a cpupool, starting and destroying a guest within this pool,
> then removing this pool doesn't work because of EBUSY.
>
> It seems the cause of this behavior is the commit
> bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
>
> In domain_kill() the function sched_move_domain() gets called changing the
> d->cpupool pointer to the new cpupool without incrementing/decrementing the
> counters "n_dom" of the new/old cpupool.
>
> This leads to decrementing the wrong  cpupool0->n_dom counter when
> cpupool_rm_domain() gets called at the end and my own cpupool can't be
> destroyed because n_dom = 1!
>
> I don't have a fast patch because I'am not enough familiar with the code
> this time but I think it should be fixed for 4.5.

Please discard previous patch, try this one.

Juergen


--------------070605070108000505020609
Content-Type: text/x-patch;
 name="0001-Adjust-number-of-domains-in-cpupools-when-destroying.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0001-Adjust-number-of-domains-in-cpupools-when-destroying.pa";
 filename*1="tch"

>From 629a7fe8ed07a13304d9378d357420ec885f59e3 Mon Sep 17 00:00:00 2001
From: Juergen Gross <jgross@suse.com>
Date: Tue, 11 Nov 2014 15:03:33 +0100
Subject: [PATCH] Adjust number of domains in cpupools when destroying domain

Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of domains
is nor adjusted when a domain is moved to cpupool0 in kill_domain().

Correct this by introducing a cpupool function doing the move
instead of open coding it by calling sched_move_domain().

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
 xen/common/domain.c     |  2 +-
 xen/include/xen/sched.h |  1 +
 3 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 73249d3..c6e3869 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
 }
 
 /*
+ * Move domain to another cpupool
+ */
+static int cpupool_move_domain_unlocked(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    d->cpupool->n_dom--;
+    ret = sched_move_domain(d, c);
+    if ( ret )
+        d->cpupool->n_dom++;
+    else
+        c->n_dom++;
+
+    return ret;
+}
+int cpupool_move_domain(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    spin_lock(&cpupool_lock);
+
+    ret = cpupool_move_domain_unlocked(d, c);
+
+    spin_unlock(&cpupool_lock);
+
+    return ret;
+}
+
+/*
  * assign a specific cpu to a cpupool
  * cpupool_lock must be held
  */
@@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
                 ret = -EBUSY;
                 break;
             }
-            c->n_dom--;
-            ret = sched_move_domain(d, cpupool0);
+            ret = cpupool_move_domain_unlocked(d, cpupool0);
             if ( ret )
-            {
-                c->n_dom++;
                 break;
-            }
-            cpupool0->n_dom++;
         }
         rcu_read_unlock(&domlist_read_lock);
         if ( ret )
@@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
                         d->domain_id, op->cpupool_id);
         ret = -ENOENT;
         spin_lock(&cpupool_lock);
+
         c = cpupool_find_by_id(op->cpupool_id);
         if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
-        {
-            d->cpupool->n_dom--;
-            ret = sched_move_domain(d, c);
-            if ( ret )
-                d->cpupool->n_dom++;
-            else
-                c->n_dom++;
-        }
+            ret = cpupool_move_domain_unlocked(d, c);
+
         spin_unlock(&cpupool_lock);
         cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
                         d->domain_id, op->cpupool_id, ret);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index a3f51ec..4a62c1d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
                 rc = -EAGAIN;
             break;
         }
-        if ( sched_move_domain(d, cpupool0) )
+        if ( cpupool_move_domain(d, cpupool0) )
             return -EAGAIN;
         for_each_vcpu ( d, v )
             unmap_vcpu_info(v);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index c5157e6..46fc6e3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
 void cpupool_put(struct cpupool *pool);
 int cpupool_add_domain(struct domain *d, int poolid);
 void cpupool_rm_domain(struct domain *d);
+int cpupool_move_domain(struct domain *d, struct cpupool *c);
 int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
 void schedule_dump(struct cpupool *c);
 extern void dump_runq(unsigned char key);
-- 
2.1.2


--------------070605070108000505020609
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------070605070108000505020609--


From xen-devel-bounces@lists.xen.org Tue Nov 11 14:24:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCMl-0002oB-4w; Tue, 11 Nov 2014 14:24:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoCMi-0002nx-5V
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:24:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B2/68-24532-F0C12645; Tue, 11 Nov 2014 14:24:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415715853!11960149!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15472 invoked from network); 11 Nov 2014 14:24:14 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 14:24:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABEO4J4002999
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 14:24:07 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABEO2Ev028136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 14:24:03 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABEO21F001075; Tue, 11 Nov 2014 14:24:02 GMT
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 06:24:02 -0800
Date: Tue, 11 Nov 2014 09:24:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141111142359.GB8751@konrad-lan.dumpdata.com>
References: <5461D59C.5020106@gmail.com>
	<alpine.DEB.2.02.1411111052280.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411111052280.26318@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	Michael Tokarev <mjt@tls.msk.ru>, Chen Gang <gang.chen.5i5j@gmail.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH trivial] xen-hvm: Remove redandant varialbe
 'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 10:53:01AM +0000, Stefano Stabellini wrote:
> On Tue, 11 Nov 2014, Chen Gang wrote:
> > In xen_hvm_change_state_handler(), can pass 'opaque' with type cast to
> > xen_main_loop_prepare() directly, need not use additional variable for
> > it.

The title of your patch should say 'variable'.
> > 
> > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> 
> >  xen-hvm.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 21f1cbb..7548794 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -993,9 +993,8 @@ static void xen_main_loop_prepare(XenIOState *state)
> >  static void xen_hvm_change_state_handler(void *opaque, int running,
> >                                           RunState rstate)
> >  {
> > -    XenIOState *xstate = opaque;
> >      if (running) {
> > -        xen_main_loop_prepare(xstate);
> > +        xen_main_loop_prepare((XenIOState *)opaque);
> >      }
> >  }
> >  
> > -- 
> > 1.8.5.2 (Apple Git-48)
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 11 14:24:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCMl-0002oB-4w; Tue, 11 Nov 2014 14:24:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoCMi-0002nx-5V
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:24:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B2/68-24532-F0C12645; Tue, 11 Nov 2014 14:24:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415715853!11960149!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15472 invoked from network); 11 Nov 2014 14:24:14 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 14:24:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABEO4J4002999
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 14:24:07 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABEO2Ev028136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 14:24:03 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABEO21F001075; Tue, 11 Nov 2014 14:24:02 GMT
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 06:24:02 -0800
Date: Tue, 11 Nov 2014 09:24:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141111142359.GB8751@konrad-lan.dumpdata.com>
References: <5461D59C.5020106@gmail.com>
	<alpine.DEB.2.02.1411111052280.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411111052280.26318@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	Michael Tokarev <mjt@tls.msk.ru>, Chen Gang <gang.chen.5i5j@gmail.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH trivial] xen-hvm: Remove redandant varialbe
 'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 10:53:01AM +0000, Stefano Stabellini wrote:
> On Tue, 11 Nov 2014, Chen Gang wrote:
> > In xen_hvm_change_state_handler(), can pass 'opaque' with type cast to
> > xen_main_loop_prepare() directly, need not use additional variable for
> > it.

The title of your patch should say 'variable'.
> > 
> > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> 
> >  xen-hvm.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 21f1cbb..7548794 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -993,9 +993,8 @@ static void xen_main_loop_prepare(XenIOState *state)
> >  static void xen_hvm_change_state_handler(void *opaque, int running,
> >                                           RunState rstate)
> >  {
> > -    XenIOState *xstate = opaque;
> >      if (running) {
> > -        xen_main_loop_prepare(xstate);
> > +        xen_main_loop_prepare((XenIOState *)opaque);
> >      }
> >  }
> >  
> > -- 
> > 1.8.5.2 (Apple Git-48)
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 11 14:25:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:25:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCOI-0002ui-LS; Tue, 11 Nov 2014 14:25:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gang.chen.5i5j@gmail.com>) id 1XoCOH-0002ub-Di
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:25:53 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	49/8C-25714-07C12645; Tue, 11 Nov 2014 14:25:52 +0000
X-Env-Sender: gang.chen.5i5j@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415715950!8912075!1
X-Originating-IP: [209.85.220.54]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22405 invoked from network); 11 Nov 2014 14:25:51 -0000
Received: from mail-pa0-f54.google.com (HELO mail-pa0-f54.google.com)
	(209.85.220.54)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 14:25:51 -0000
Received: by mail-pa0-f54.google.com with SMTP id rd3so10773324pab.27
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Nov 2014 06:25:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=bvXgjcy7m75LrutWhJo+/jpqPQzOYRyEhiptdFPpIes=;
	b=k8WhlLYO+aERigtXkr8cyRrfuwJYx7vPuEXtqllfpEggl+R2jg9nC7fjOzy2+RGN6o
	FAcOX4OBdKdGEjsLhZHb7H23zYsMv00C691ZDx6Jx5FyfPpDRI08ZxrbLH9vr7A1ec31
	K2zXbGvw8MpduKjVSPm6HXuJcoq3Z+RQ7ttp5URgrGKhKhclG1n8MnZDhWsN7XQM9WPU
	KZau0TUV8ZgGswFjqVXhOpbznrRxv3elwfbfbq5tRj8pHBL7SXP3RjWmdgmbn6ddbpWZ
	XvUYp4PdwYbpLIdW9jNfUabUzaBJ4QMad1kihJ7Tb0SX/eYt6gx8/b/y7CkDsDqif4xi
	dvAA==
X-Received: by 10.68.241.10 with SMTP id we10mr39818095pbc.101.1415715950111; 
	Tue, 11 Nov 2014 06:25:50 -0800 (PST)
Received: from ShengShiZhuChengdeMacBook-Pro.local ([223.72.65.118])
	by mx.google.com with ESMTPSA id o6sm19587604pdl.3.2014.11.11.06.25.46
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 11 Nov 2014 06:25:49 -0800 (PST)
Message-ID: <54621DE6.60108@gmail.com>
Date: Tue, 11 Nov 2014 22:32:06 +0800
From: Chen Gang <gang.chen.5i5j@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <5461D59C.5020106@gmail.com>
	<alpine.DEB.2.02.1411111052280.26318@kaball.uk.xensource.com>
	<20141111142359.GB8751@konrad-lan.dumpdata.com>
In-Reply-To: <20141111142359.GB8751@konrad-lan.dumpdata.com>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	Michael Tokarev <mjt@tls.msk.ru>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH trivial] xen-hvm: Remove redandant varialbe
 'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/11/14 22:24, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 10:53:01AM +0000, Stefano Stabellini wrote:
>> On Tue, 11 Nov 2014, Chen Gang wrote:
>>> In xen_hvm_change_state_handler(), can pass 'opaque' with type cast to
>>> xen_main_loop_prepare() directly, need not use additional variable for
>>> it.
> 
> The title of your patch should say 'variable'.

Oh, yes, thanks. If necessary to send patch v2 for it, please let me
know.

Thanks.

>>>
>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>
>> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>
>>
>>>  xen-hvm.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/xen-hvm.c b/xen-hvm.c
>>> index 21f1cbb..7548794 100644
>>> --- a/xen-hvm.c
>>> +++ b/xen-hvm.c
>>> @@ -993,9 +993,8 @@ static void xen_main_loop_prepare(XenIOState *state)
>>>  static void xen_hvm_change_state_handler(void *opaque, int running,
>>>                                           RunState rstate)
>>>  {
>>> -    XenIOState *xstate = opaque;
>>>      if (running) {
>>> -        xen_main_loop_prepare(xstate);
>>> +        xen_main_loop_prepare((XenIOState *)opaque);
>>>      }
>>>  }
>>>  
>>> -- 
>>> 1.8.5.2 (Apple Git-48)
>>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:25:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:25:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCOI-0002ui-LS; Tue, 11 Nov 2014 14:25:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gang.chen.5i5j@gmail.com>) id 1XoCOH-0002ub-Di
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:25:53 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	49/8C-25714-07C12645; Tue, 11 Nov 2014 14:25:52 +0000
X-Env-Sender: gang.chen.5i5j@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415715950!8912075!1
X-Originating-IP: [209.85.220.54]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22405 invoked from network); 11 Nov 2014 14:25:51 -0000
Received: from mail-pa0-f54.google.com (HELO mail-pa0-f54.google.com)
	(209.85.220.54)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 14:25:51 -0000
Received: by mail-pa0-f54.google.com with SMTP id rd3so10773324pab.27
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Nov 2014 06:25:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=bvXgjcy7m75LrutWhJo+/jpqPQzOYRyEhiptdFPpIes=;
	b=k8WhlLYO+aERigtXkr8cyRrfuwJYx7vPuEXtqllfpEggl+R2jg9nC7fjOzy2+RGN6o
	FAcOX4OBdKdGEjsLhZHb7H23zYsMv00C691ZDx6Jx5FyfPpDRI08ZxrbLH9vr7A1ec31
	K2zXbGvw8MpduKjVSPm6HXuJcoq3Z+RQ7ttp5URgrGKhKhclG1n8MnZDhWsN7XQM9WPU
	KZau0TUV8ZgGswFjqVXhOpbznrRxv3elwfbfbq5tRj8pHBL7SXP3RjWmdgmbn6ddbpWZ
	XvUYp4PdwYbpLIdW9jNfUabUzaBJ4QMad1kihJ7Tb0SX/eYt6gx8/b/y7CkDsDqif4xi
	dvAA==
X-Received: by 10.68.241.10 with SMTP id we10mr39818095pbc.101.1415715950111; 
	Tue, 11 Nov 2014 06:25:50 -0800 (PST)
Received: from ShengShiZhuChengdeMacBook-Pro.local ([223.72.65.118])
	by mx.google.com with ESMTPSA id o6sm19587604pdl.3.2014.11.11.06.25.46
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 11 Nov 2014 06:25:49 -0800 (PST)
Message-ID: <54621DE6.60108@gmail.com>
Date: Tue, 11 Nov 2014 22:32:06 +0800
From: Chen Gang <gang.chen.5i5j@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <5461D59C.5020106@gmail.com>
	<alpine.DEB.2.02.1411111052280.26318@kaball.uk.xensource.com>
	<20141111142359.GB8751@konrad-lan.dumpdata.com>
In-Reply-To: <20141111142359.GB8751@konrad-lan.dumpdata.com>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	Michael Tokarev <mjt@tls.msk.ru>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH trivial] xen-hvm: Remove redandant varialbe
 'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/11/14 22:24, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 10:53:01AM +0000, Stefano Stabellini wrote:
>> On Tue, 11 Nov 2014, Chen Gang wrote:
>>> In xen_hvm_change_state_handler(), can pass 'opaque' with type cast to
>>> xen_main_loop_prepare() directly, need not use additional variable for
>>> it.
> 
> The title of your patch should say 'variable'.

Oh, yes, thanks. If necessary to send patch v2 for it, please let me
know.

Thanks.

>>>
>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>
>> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>
>>
>>>  xen-hvm.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/xen-hvm.c b/xen-hvm.c
>>> index 21f1cbb..7548794 100644
>>> --- a/xen-hvm.c
>>> +++ b/xen-hvm.c
>>> @@ -993,9 +993,8 @@ static void xen_main_loop_prepare(XenIOState *state)
>>>  static void xen_hvm_change_state_handler(void *opaque, int running,
>>>                                           RunState rstate)
>>>  {
>>> -    XenIOState *xstate = opaque;
>>>      if (running) {
>>> -        xen_main_loop_prepare(xstate);
>>> +        xen_main_loop_prepare((XenIOState *)opaque);
>>>      }
>>>  }
>>>  
>>> -- 
>>> 1.8.5.2 (Apple Git-48)
>>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:26:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCP7-00030p-9x; Tue, 11 Nov 2014 14:26:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mjt@tls.msk.ru>) id 1XoCP6-00030a-0e
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:26:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7A/04-09842-3AC12645; Tue, 11 Nov 2014 14:26:43 +0000
X-Env-Sender: mjt@tls.msk.ru
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415716002!11905658!1
X-Originating-IP: [86.62.121.231]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29823 invoked from network); 11 Nov 2014 14:26:43 -0000
Received: from isrv.corpit.ru (HELO isrv.corpit.ru) (86.62.121.231)
	by server-11.tower-21.messagelabs.com with SMTP;
	11 Nov 2014 14:26:43 -0000
Received: from [192.168.88.2] (mjt.vpn.tls.msk.ru [192.168.177.99])
	by isrv.corpit.ru (Postfix) with ESMTP id 22CC041DE3;
	Tue, 11 Nov 2014 17:26:41 +0300 (MSK)
Message-ID: <54621CA1.9090801@msgid.tls.msk.ru>
Date: Tue, 11 Nov 2014 17:26:41 +0300
From: Michael Tokarev <mjt@tls.msk.ru>
Organization: Telecom Service, JSC
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Chen Gang <gang.chen.5i5j@gmail.com>
References: <5461D59C.5020106@gmail.com>
In-Reply-To: <5461D59C.5020106@gmail.com>
OpenPGP: id=804465C5
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-trivial] [PATCH trivial] xen-hvm: Remove
 redandant varialbe 'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

11.11.2014 12:23, Chen Gang wrote:
> In xen_hvm_change_state_handler(), can pass 'opaque' with type cast to
> xen_main_loop_prepare() directly, need not use additional variable for
> it.

gcc most likely eliminates it anyway, but heck, why not?
Applied to -trivial, thank you!

/mjt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:26:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCP7-00030p-9x; Tue, 11 Nov 2014 14:26:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mjt@tls.msk.ru>) id 1XoCP6-00030a-0e
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:26:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7A/04-09842-3AC12645; Tue, 11 Nov 2014 14:26:43 +0000
X-Env-Sender: mjt@tls.msk.ru
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415716002!11905658!1
X-Originating-IP: [86.62.121.231]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29823 invoked from network); 11 Nov 2014 14:26:43 -0000
Received: from isrv.corpit.ru (HELO isrv.corpit.ru) (86.62.121.231)
	by server-11.tower-21.messagelabs.com with SMTP;
	11 Nov 2014 14:26:43 -0000
Received: from [192.168.88.2] (mjt.vpn.tls.msk.ru [192.168.177.99])
	by isrv.corpit.ru (Postfix) with ESMTP id 22CC041DE3;
	Tue, 11 Nov 2014 17:26:41 +0300 (MSK)
Message-ID: <54621CA1.9090801@msgid.tls.msk.ru>
Date: Tue, 11 Nov 2014 17:26:41 +0300
From: Michael Tokarev <mjt@tls.msk.ru>
Organization: Telecom Service, JSC
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Chen Gang <gang.chen.5i5j@gmail.com>
References: <5461D59C.5020106@gmail.com>
In-Reply-To: <5461D59C.5020106@gmail.com>
OpenPGP: id=804465C5
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-trivial] [PATCH trivial] xen-hvm: Remove
 redandant varialbe 'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

11.11.2014 12:23, Chen Gang wrote:
> In xen_hvm_change_state_handler(), can pass 'opaque' with type cast to
> xen_main_loop_prepare() directly, need not use additional variable for
> it.

gcc most likely eliminates it anyway, but heck, why not?
Applied to -trivial, thank you!

/mjt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:37:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCZC-0003Qe-7U; Tue, 11 Nov 2014 14:37:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mjt@tls.msk.ru>) id 1XoCZ5-0003QW-Jl
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:37:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D8/58-09842-E0F12645; Tue, 11 Nov 2014 14:37:02 +0000
X-Env-Sender: mjt@tls.msk.ru
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415716622!11910854!1
X-Originating-IP: [86.62.121.231]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1218 invoked from network); 11 Nov 2014 14:37:02 -0000
Received: from isrv.corpit.ru (HELO isrv.corpit.ru) (86.62.121.231)
	by server-5.tower-21.messagelabs.com with SMTP;
	11 Nov 2014 14:37:02 -0000
Received: from [192.168.88.2] (mjt.vpn.tls.msk.ru [192.168.177.99])
	by isrv.corpit.ru (Postfix) with ESMTP id 0E9CF41DE5;
	Tue, 11 Nov 2014 17:37:02 +0300 (MSK)
Message-ID: <54621F0D.8080401@msgid.tls.msk.ru>
Date: Tue, 11 Nov 2014 17:37:01 +0300
From: Michael Tokarev <mjt@tls.msk.ru>
Organization: Telecom Service, JSC
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Chen Gang <gang.chen.5i5j@gmail.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <5461D59C.5020106@gmail.com>	<alpine.DEB.2.02.1411111052280.26318@kaball.uk.xensource.com>	<20141111142359.GB8751@konrad-lan.dumpdata.com>
	<54621DE6.60108@gmail.com>
In-Reply-To: <54621DE6.60108@gmail.com>
OpenPGP: id=804465C5
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-trivial] [PATCH trivial] xen-hvm: Remove
 redandant varialbe 'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

11.11.2014 17:32, Chen Gang wrote:
>> The title of your patch should say 'variable'.
> 
> Oh, yes, thanks. If necessary to send patch v2 for it, please let me
> know.

Not only 'varialbe', but also 'redandant'.  I fixed both on commit, plus
fixed grammar in commit message.

Thanks,

/mjt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:37:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCZC-0003Qe-7U; Tue, 11 Nov 2014 14:37:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mjt@tls.msk.ru>) id 1XoCZ5-0003QW-Jl
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:37:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D8/58-09842-E0F12645; Tue, 11 Nov 2014 14:37:02 +0000
X-Env-Sender: mjt@tls.msk.ru
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415716622!11910854!1
X-Originating-IP: [86.62.121.231]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1218 invoked from network); 11 Nov 2014 14:37:02 -0000
Received: from isrv.corpit.ru (HELO isrv.corpit.ru) (86.62.121.231)
	by server-5.tower-21.messagelabs.com with SMTP;
	11 Nov 2014 14:37:02 -0000
Received: from [192.168.88.2] (mjt.vpn.tls.msk.ru [192.168.177.99])
	by isrv.corpit.ru (Postfix) with ESMTP id 0E9CF41DE5;
	Tue, 11 Nov 2014 17:37:02 +0300 (MSK)
Message-ID: <54621F0D.8080401@msgid.tls.msk.ru>
Date: Tue, 11 Nov 2014 17:37:01 +0300
From: Michael Tokarev <mjt@tls.msk.ru>
Organization: Telecom Service, JSC
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Chen Gang <gang.chen.5i5j@gmail.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <5461D59C.5020106@gmail.com>	<alpine.DEB.2.02.1411111052280.26318@kaball.uk.xensource.com>	<20141111142359.GB8751@konrad-lan.dumpdata.com>
	<54621DE6.60108@gmail.com>
In-Reply-To: <54621DE6.60108@gmail.com>
OpenPGP: id=804465C5
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, xen-devel@lists.xensource.com,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-trivial] [PATCH trivial] xen-hvm: Remove
 redandant varialbe 'xstate'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

11.11.2014 17:32, Chen Gang wrote:
>> The title of your patch should say 'variable'.
> 
> Oh, yes, thanks. If necessary to send patch v2 for it, please let me
> know.

Not only 'varialbe', but also 'redandant'.  I fixed both on commit, plus
fixed grammar in commit message.

Thanks,

/mjt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:38:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:38:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCav-0003Vw-NZ; Tue, 11 Nov 2014 14:38:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoCau-0003Vr-7O
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:38:56 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	37/63-02712-F7F12645; Tue, 11 Nov 2014 14:38:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415716733!6412296!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25747 invoked from network); 11 Nov 2014 14:38:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 14:38:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,361,1413244800"; d="scan'208";a="190138903"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 09:38:46 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoCaj-00053L-Vm;
	Tue, 11 Nov 2014 14:38:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoCaj-0004OV-QX;
	Tue, 11 Nov 2014 14:38:45 +0000
Date: Tue, 11 Nov 2014 14:38:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31478-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11252
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31478: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2995358703397135958=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2995358703397135958==
Content-Type: text/plain
Content-Length: 11010
Content-Transfer-Encoding: quoted-printable

flight 31478 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31478/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops             4 host-build-prep           fail REGR. vs. 30603
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 30603

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install            fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                7a8dda7e5d8035a10812bb9e852576c91de2dcdc
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 11248 lines long.)


--===============2995358703397135958==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2995358703397135958==--

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:38:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:38:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCav-0003Vw-NZ; Tue, 11 Nov 2014 14:38:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoCau-0003Vr-7O
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 14:38:56 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	37/63-02712-F7F12645; Tue, 11 Nov 2014 14:38:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415716733!6412296!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25747 invoked from network); 11 Nov 2014 14:38:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 14:38:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,361,1413244800"; d="scan'208";a="190138903"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 09:38:46 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoCaj-00053L-Vm;
	Tue, 11 Nov 2014 14:38:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoCaj-0004OV-QX;
	Tue, 11 Nov 2014 14:38:45 +0000
Date: Tue, 11 Nov 2014 14:38:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31478-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11252
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31478: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2995358703397135958=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2995358703397135958==
Content-Type: text/plain
Content-Length: 11010
Content-Transfer-Encoding: quoted-printable

flight 31478 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31478/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops             4 host-build-prep           fail REGR. vs. 30603
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 30603

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install            fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                7a8dda7e5d8035a10812bb9e852576c91de2dcdc
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 11248 lines long.)


--===============2995358703397135958==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2995358703397135958==--

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:41:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14: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 1XoCdZ-0003fP-CS; Tue, 11 Nov 2014 14:41:41 +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 1XoCdX-0003fH-RS
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 14:41:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D7/71-09936-32022645; Tue, 11 Nov 2014 14:41:39 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415716897!11900294!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7033 invoked from network); 11 Nov 2014 14:41:38 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 14:41:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABEfYic032764
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 14:41:35 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABEfXQ6025070
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 14:41:34 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABEfXpI005881; Tue, 11 Nov 2014 14:41:33 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 06:41:32 -0800
Message-ID: <5462201C.302@oracle.com>
Date: Tue, 11 Nov 2014 09:41:32 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
In-Reply-To: <20141111110156.GA12465@zion.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/11/2014 06:01 AM, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
> [...]
>> Could you please explain what does "no configuration" means?
>>
>> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
>>
> 
> That means no configuration at all. I think a skeleton can be provided
> at best (in xl level) to be consistent with "xl list", which should
> include domid and domain name etc. Since nothing else exists in
> xenstore yet, there's no point poking there.

This approach should works for me.

> [...]
>> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
>>
> 
> Hmm... I don't think poking around in different places is a good idea.
> This is prone to breakage in the future.

I agree.
 
> Since xenstore is not filled in when your tool looks at it, what makes
> it different to wait a bit until migration finishes?

The logic is: when migration started, high level management console will check
destination side to make sure the VM is running there 
(currently call xl list -l <domain>).

If I can get enough runtime info (even some are missing), I think it should be OK.

> And, from your earlier reply, you're implying Xend fires
> @introduceDomain at the same point as xl, but your tool can work with
> it?

For xm/xend, VM xenstore entries already populated before @introduceDomain.
"xm list -l" will show the right information.

Anyone knows what prevents us from populating VM xenstore entries during migration in libxl?

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:41:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14: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 1XoCdZ-0003fP-CS; Tue, 11 Nov 2014 14:41:41 +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 1XoCdX-0003fH-RS
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 14:41:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D7/71-09936-32022645; Tue, 11 Nov 2014 14:41:39 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415716897!11900294!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7033 invoked from network); 11 Nov 2014 14:41:38 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 14:41:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABEfYic032764
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 14:41:35 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABEfXQ6025070
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 14:41:34 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABEfXpI005881; Tue, 11 Nov 2014 14:41:33 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 06:41:32 -0800
Message-ID: <5462201C.302@oracle.com>
Date: Tue, 11 Nov 2014 09:41:32 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <545BC8A2.20604@oracle.com>
	<20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
In-Reply-To: <20141111110156.GA12465@zion.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/11/2014 06:01 AM, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
> [...]
>> Could you please explain what does "no configuration" means?
>>
>> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
>>
> 
> That means no configuration at all. I think a skeleton can be provided
> at best (in xl level) to be consistent with "xl list", which should
> include domid and domain name etc. Since nothing else exists in
> xenstore yet, there's no point poking there.

This approach should works for me.

> [...]
>> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
>>
> 
> Hmm... I don't think poking around in different places is a good idea.
> This is prone to breakage in the future.

I agree.
 
> Since xenstore is not filled in when your tool looks at it, what makes
> it different to wait a bit until migration finishes?

The logic is: when migration started, high level management console will check
destination side to make sure the VM is running there 
(currently call xl list -l <domain>).

If I can get enough runtime info (even some are missing), I think it should be OK.

> And, from your earlier reply, you're implying Xend fires
> @introduceDomain at the same point as xl, but your tool can work with
> it?

For xm/xend, VM xenstore entries already populated before @introduceDomain.
"xm list -l" will show the right information.

Anyone knows what prevents us from populating VM xenstore entries during migration in libxl?

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:42:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:42:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCec-0003vN-RV; Tue, 11 Nov 2014 14:42:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1XoCeb-0003vG-A4
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 14:42:45 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	D5/EC-26858-46022645; Tue, 11 Nov 2014 14:42:44 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415716964!11788722!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4363 invoked from network); 11 Nov 2014 14:42:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 14:42:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,361,1413244800"; d="scan'208";a="26706815"
From: Thanos Makatos <thanos.makatos@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Thread-Topic: [Xen-devel] [PATCH] introduce grant copy for user land
Thread-Index: AQHP95BvMwOS2+bnLkC54UJZVlEzjpxbZgBwgAACfgCAACOTQA==
Date: Tue, 11 Nov 2014 14:42:42 +0000
Message-ID: <2368A3FCF9F7214298E53C823B0A48EC0428962A@AMSPEX01CL02.citrite.net>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
	<5457C35F.50504@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
	<5462105A.6020100@citrix.com>
In-Reply-To: <5462105A.6020100@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On 11/11/14 12:27, Thanos Makatos wrote:
> >> The arbitrary limitations in number of ops and page alignment should
> >> be removed.  I think both can be removed relatively easily by
> >> consuming page aligned chunks of segments and doign the hypercall
> >> when a batch of ops is filled.
> >
> > Wouldn't this lead to multiple calls to gnttab_batch_copy(), potentially
> hurting performance?
> 
> The incremental benefits of batching diminishes as the batch size increase.

To overcome the page alignment limitation, struct gntdev_grant_copy_segment
will have to contain a set of grant refs instead of just one grant ref,
correct?
 
> We also don't want multi-page allocations in this driver, so the batch size
> should be set accordingly.

Why not?

> The interface should also support grant to grant copies.

To support grant to grant copies, struct gntdev_grant_copy_segment will have
to contain an additional set of grant refs, correct?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 14:42:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 14:42:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoCec-0003vN-RV; Tue, 11 Nov 2014 14:42:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1XoCeb-0003vG-A4
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 14:42:45 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	D5/EC-26858-46022645; Tue, 11 Nov 2014 14:42:44 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415716964!11788722!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4363 invoked from network); 11 Nov 2014 14:42:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 14:42:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,361,1413244800"; d="scan'208";a="26706815"
From: Thanos Makatos <thanos.makatos@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Thread-Topic: [Xen-devel] [PATCH] introduce grant copy for user land
Thread-Index: AQHP95BvMwOS2+bnLkC54UJZVlEzjpxbZgBwgAACfgCAACOTQA==
Date: Tue, 11 Nov 2014 14:42:42 +0000
Message-ID: <2368A3FCF9F7214298E53C823B0A48EC0428962A@AMSPEX01CL02.citrite.net>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
	<5457C35F.50504@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
	<5462105A.6020100@citrix.com>
In-Reply-To: <5462105A.6020100@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On 11/11/14 12:27, Thanos Makatos wrote:
> >> The arbitrary limitations in number of ops and page alignment should
> >> be removed.  I think both can be removed relatively easily by
> >> consuming page aligned chunks of segments and doign the hypercall
> >> when a batch of ops is filled.
> >
> > Wouldn't this lead to multiple calls to gnttab_batch_copy(), potentially
> hurting performance?
> 
> The incremental benefits of batching diminishes as the batch size increase.

To overcome the page alignment limitation, struct gntdev_grant_copy_segment
will have to contain a set of grant refs instead of just one grant ref,
correct?
 
> We also don't want multi-page allocations in this driver, so the batch size
> should be set accordingly.

Why not?

> The interface should also support grant to grant copies.

To support grant to grant copies, struct gntdev_grant_copy_segment will have
to contain an additional set of grant refs, correct?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:09:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoD4O-0004Vl-JW; Tue, 11 Nov 2014 15:09:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoD4N-0004Vg-14
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 15:09:23 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	9C/C8-17694-1A622645; Tue, 11 Nov 2014 15:09:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415718559!8121592!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10800 invoked from network); 11 Nov 2014 15:09:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 15:09:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190152434"
Message-ID: <54622604.40807@citrix.com>
Date: Tue, 11 Nov 2014 15:06:44 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
	<5457C35F.50504@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
	<5462105A.6020100@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC0428962A@AMSPEX01CL02.citrite.net>
In-Reply-To: <2368A3FCF9F7214298E53C823B0A48EC0428962A@AMSPEX01CL02.citrite.net>
X-DLP: MIA2
Cc: "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 14:42, Thanos Makatos wrote:
>> On 11/11/14 12:27, Thanos Makatos wrote:
>>>> The arbitrary limitations in number of ops and page alignment should
>>>> be removed.  I think both can be removed relatively easily by
>>>> consuming page aligned chunks of segments and doign the hypercall
>>>> when a batch of ops is filled.
>>>
>>> Wouldn't this lead to multiple calls to gnttab_batch_copy(), potentially
>> hurting performance?
>>
>> The incremental benefits of batching diminishes as the batch size increase.
> 
> To overcome the page alignment limitation, struct gntdev_grant_copy_segment
> will have to contain a set of grant refs instead of just one grant ref,
> correct?

Oh, that would be awkward.  Keeping the alignment requirement would be best.

>> We also don't want multi-page allocations in this driver, so the batch size
>> should be set accordingly.
> 
> Why not?

Multi-page allocations are more likely to fail because of memory
fragmentation.

>> The interface should also support grant to grant copies.
> 
> To support grant to grant copies, struct gntdev_grant_copy_segment will have
> to contain an additional set of grant refs, correct?

The hypervisor ABI uses a union of handle and grant ref.  Perhaps
something similar for the kernel interface?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:09:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoD4O-0004Vl-JW; Tue, 11 Nov 2014 15:09:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoD4N-0004Vg-14
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 15:09:23 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	9C/C8-17694-1A622645; Tue, 11 Nov 2014 15:09:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415718559!8121592!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10800 invoked from network); 11 Nov 2014 15:09:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 15:09:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190152434"
Message-ID: <54622604.40807@citrix.com>
Date: Tue, 11 Nov 2014 15:06:44 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
	<5457C35F.50504@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
	<5462105A.6020100@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC0428962A@AMSPEX01CL02.citrite.net>
In-Reply-To: <2368A3FCF9F7214298E53C823B0A48EC0428962A@AMSPEX01CL02.citrite.net>
X-DLP: MIA2
Cc: "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 14:42, Thanos Makatos wrote:
>> On 11/11/14 12:27, Thanos Makatos wrote:
>>>> The arbitrary limitations in number of ops and page alignment should
>>>> be removed.  I think both can be removed relatively easily by
>>>> consuming page aligned chunks of segments and doign the hypercall
>>>> when a batch of ops is filled.
>>>
>>> Wouldn't this lead to multiple calls to gnttab_batch_copy(), potentially
>> hurting performance?
>>
>> The incremental benefits of batching diminishes as the batch size increase.
> 
> To overcome the page alignment limitation, struct gntdev_grant_copy_segment
> will have to contain a set of grant refs instead of just one grant ref,
> correct?

Oh, that would be awkward.  Keeping the alignment requirement would be best.

>> We also don't want multi-page allocations in this driver, so the batch size
>> should be set accordingly.
> 
> Why not?

Multi-page allocations are more likely to fail because of memory
fragmentation.

>> The interface should also support grant to grant copies.
> 
> To support grant to grant copies, struct gntdev_grant_copy_segment will have
> to contain an additional set of grant refs, correct?

The hypervisor ABI uses a union of handle and grant ref.  Perhaps
something similar for the kernel interface?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:23:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:23:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoDHo-00050B-Ms; Tue, 11 Nov 2014 15:23:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoDHn-000506-Ij
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 15:23:15 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	F3/56-28296-2E922645; Tue, 11 Nov 2014 15:23:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415719391!8125534!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9131 invoked from network); 11 Nov 2014 15:23:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 15:23:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190160438"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 10:20:11 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoDEp-0006SF-GN;
	Tue, 11 Nov 2014 15:20:11 +0000
Date: Tue, 11 Nov 2014 15:20:11 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141111152011.GA21312@zion.uk.xensource.com>
References: <20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5462201C.302@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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, Nov 11, 2014 at 09:41:32AM -0500, Zhigang Wang wrote:
> On 11/11/2014 06:01 AM, Wei Liu wrote:
> > On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
> > [...]
> >> Could you please explain what does "no configuration" means?
> >>
> >> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
> >>
> > 
> > That means no configuration at all. I think a skeleton can be provided
> > at best (in xl level) to be consistent with "xl list", which should
> > include domid and domain name etc. Since nothing else exists in
> > xenstore yet, there's no point poking there.
> 
> This approach should works for me.
> 
> > [...]
> >> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
> >>
> > 
> > Hmm... I don't think poking around in different places is a good idea.
> > This is prone to breakage in the future.
> 
> I agree.
>  
> > Since xenstore is not filled in when your tool looks at it, what makes
> > it different to wait a bit until migration finishes?
> 
> The logic is: when migration started, high level management console will check
> destination side to make sure the VM is running there 
> (currently call xl list -l <domain>).
> 
> If I can get enough runtime info (even some are missing), I think it should be OK.
> 

What runtime info do you need?

As I understand it's something in the long output -- otherwise you would
have used the short output already if you only need to check the
existence and / or state of a domain.

> > And, from your earlier reply, you're implying Xend fires
> > @introduceDomain at the same point as xl, but your tool can work with
> > it?
> 
> For xm/xend, VM xenstore entries already populated before @introduceDomain.
> "xm list -l" will show the right information.
> 
> Anyone knows what prevents us from populating VM xenstore entries during migration in libxl?
> 

FWIW in libxl @introduceDomain is fired after domain is built, before
adding devices. If you're after device information, it's a bit late.

Xend might have done it in different order. I don't know.

Whether we can change libxl to do so, I'm not sure. But it's definitely
not 4.5 material.

Wei.

> Thanks,
> 
> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:23:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:23:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoDI5-000516-2n; Tue, 11 Nov 2014 15:23:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1XoDI3-00050t-RY
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 15:23:31 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	33/B3-09842-3F922645; Tue, 11 Nov 2014 15:23:31 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415719410!11961857!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18925 invoked from network); 11 Nov 2014 15:23:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 15:23:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="26709079"
From: Thanos Makatos <thanos.makatos@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Thread-Topic: [Xen-devel] [PATCH] introduce grant copy for user land
Thread-Index: AQHP95BvMwOS2+bnLkC54UJZVlEzjpxbZgBwgAACfgCAACOTQP//9kAAgAAUEzA=
Date: Tue, 11 Nov 2014 15:23:29 +0000
Message-ID: <2368A3FCF9F7214298E53C823B0A48EC042896F9@AMSPEX01CL02.citrite.net>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
	<5457C35F.50504@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
	<5462105A.6020100@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC0428962A@AMSPEX01CL02.citrite.net>
	<54622604.40807@citrix.com>
In-Reply-To: <54622604.40807@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 also don't want multi-page allocations in this driver, so the
> >> batch size should be set accordingly.
> >
> > Why not?
> 
> Multi-page allocations are more likely to fail because of memory
> fragmentation.

Since we're keeping the alignment restriction, the code stays pretty much the same. Therefore what we need is to
pick the correct value for GNTDEV_GRANT_COPY_MAX_OPS such that sizeof(struct gcopy_cb) < PAGE_SIZE, correct?

> >> The interface should also support grant to grant copies.
> >
> > To support grant to grant copies, struct gntdev_grant_copy_segment
> > will have to contain an additional set of grant refs, correct?
> 
> The hypervisor ABI uses a union of handle and grant ref.  Perhaps something
> similar for the kernel interface?

Indeed, this is what I had in mind.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:23:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:23:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoDHo-00050B-Ms; Tue, 11 Nov 2014 15:23:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoDHn-000506-Ij
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 15:23:15 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	F3/56-28296-2E922645; Tue, 11 Nov 2014 15:23:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415719391!8125534!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9131 invoked from network); 11 Nov 2014 15:23:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 15:23:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190160438"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 10:20:11 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoDEp-0006SF-GN;
	Tue, 11 Nov 2014 15:20:11 +0000
Date: Tue, 11 Nov 2014 15:20:11 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141111152011.GA21312@zion.uk.xensource.com>
References: <20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5462201C.302@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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, Nov 11, 2014 at 09:41:32AM -0500, Zhigang Wang wrote:
> On 11/11/2014 06:01 AM, Wei Liu wrote:
> > On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
> > [...]
> >> Could you please explain what does "no configuration" means?
> >>
> >> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
> >>
> > 
> > That means no configuration at all. I think a skeleton can be provided
> > at best (in xl level) to be consistent with "xl list", which should
> > include domid and domain name etc. Since nothing else exists in
> > xenstore yet, there's no point poking there.
> 
> This approach should works for me.
> 
> > [...]
> >> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
> >>
> > 
> > Hmm... I don't think poking around in different places is a good idea.
> > This is prone to breakage in the future.
> 
> I agree.
>  
> > Since xenstore is not filled in when your tool looks at it, what makes
> > it different to wait a bit until migration finishes?
> 
> The logic is: when migration started, high level management console will check
> destination side to make sure the VM is running there 
> (currently call xl list -l <domain>).
> 
> If I can get enough runtime info (even some are missing), I think it should be OK.
> 

What runtime info do you need?

As I understand it's something in the long output -- otherwise you would
have used the short output already if you only need to check the
existence and / or state of a domain.

> > And, from your earlier reply, you're implying Xend fires
> > @introduceDomain at the same point as xl, but your tool can work with
> > it?
> 
> For xm/xend, VM xenstore entries already populated before @introduceDomain.
> "xm list -l" will show the right information.
> 
> Anyone knows what prevents us from populating VM xenstore entries during migration in libxl?
> 

FWIW in libxl @introduceDomain is fired after domain is built, before
adding devices. If you're after device information, it's a bit late.

Xend might have done it in different order. I don't know.

Whether we can change libxl to do so, I'm not sure. But it's definitely
not 4.5 material.

Wei.

> Thanks,
> 
> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:23:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:23:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoDI5-000516-2n; Tue, 11 Nov 2014 15:23:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1XoDI3-00050t-RY
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 15:23:31 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	33/B3-09842-3F922645; Tue, 11 Nov 2014 15:23:31 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415719410!11961857!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18925 invoked from network); 11 Nov 2014 15:23:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 15:23:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="26709079"
From: Thanos Makatos <thanos.makatos@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Thread-Topic: [Xen-devel] [PATCH] introduce grant copy for user land
Thread-Index: AQHP95BvMwOS2+bnLkC54UJZVlEzjpxbZgBwgAACfgCAACOTQP//9kAAgAAUEzA=
Date: Tue, 11 Nov 2014 15:23:29 +0000
Message-ID: <2368A3FCF9F7214298E53C823B0A48EC042896F9@AMSPEX01CL02.citrite.net>
References: <1412262916-22596-1-git-send-email-thanos.makatos@citrix.com>
	<5457C35F.50504@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC04289299@AMSPEX01CL02.citrite.net>
	<5462105A.6020100@citrix.com>
	<2368A3FCF9F7214298E53C823B0A48EC0428962A@AMSPEX01CL02.citrite.net>
	<54622604.40807@citrix.com>
In-Reply-To: <54622604.40807@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] introduce grant copy for user land
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 also don't want multi-page allocations in this driver, so the
> >> batch size should be set accordingly.
> >
> > Why not?
> 
> Multi-page allocations are more likely to fail because of memory
> fragmentation.

Since we're keeping the alignment restriction, the code stays pretty much the same. Therefore what we need is to
pick the correct value for GNTDEV_GRANT_COPY_MAX_OPS such that sizeof(struct gcopy_cb) < PAGE_SIZE, correct?

> >> The interface should also support grant to grant copies.
> >
> > To support grant to grant copies, struct gntdev_grant_copy_segment
> > will have to contain an additional set of grant refs, correct?
> 
> The hypervisor ABI uses a union of handle and grant ref.  Perhaps something
> similar for the kernel interface?

Indeed, this is what I had in mind.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:46:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoDe2-0005cZ-P5; Tue, 11 Nov 2014 15:46:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoDe1-0005cT-Lu
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 15:46:13 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	8F/22-19763-44F22645; Tue, 11 Nov 2014 15:46:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415720770!11817070!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12856 invoked from network); 11 Nov 2014 15:46:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 15:46:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABFjxLD029262
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 15:45:59 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sABFjvZh027014
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 15:45:58 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABFjvFZ011600; Tue, 11 Nov 2014 15:45:57 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 07:45:57 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7B929113DAB; Tue, 11 Nov 2014 10:45:56 -0500 (EST)
Date: Tue, 11 Nov 2014 10:45:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20141111154556.GD6597@laptop.dumpdata.com>
References: <20140110184151.GA20232@pegasus.dumpdata.com>
	<1389607803.8187.22.camel@kazak.uk.xensource.com>
	<52D3DC730200007800112FF6@nat28.tlf.novell.com>
	<1389613109.13654.43.camel@kazak.uk.xensource.com>
	<52D3E1500200007800113058@nat28.tlf.novell.com>
	<20140115200736.GB5201@phenom.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABD8C46@SHSMSX104.ccr.corp.intel.com>
	<20141110145720.GH3783@laptop.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABDACCC@SHSMSX104.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABDACCC@SHSMSX104.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Li, Liang Z" <liang.z.li@intel.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "Nakajima, Jun" <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 03:30:54AM +0000, Zhang, Yang Z wrote:
> Konrad Rzeszutek Wilk wrote on 2014-11-10:
> > On Mon, Nov 10, 2014 at 05:08:09AM +0000, Zhang, Yang Z wrote:
> >> Konrad Rzeszutek Wilk wrote on 2014-01-16:
> >>> On Mon, Jan 13, 2014 at 11:51:28AM +0000, Jan Beulich wrote:
> >>>>>>> On 13.01.14 at 12:38, Ian Campbell <Ian.Campbell@citrix.com>
> > wrote:
> >>>>> On Mon, 2014-01-13 at 11:30 +0000, Jan Beulich wrote:
> >>>>>> In fact I can't see where this would be forced off:
> >>>>>> xc_cpuid_x86.c only does so in the PV case, and all
> >>>>>> hvm_pse1gb_supported() is that the CPU supports it and the
> >>>>>> domain
> > uses HAP.
> >>>>> 
> >>>>> Took me a while to spot it too:
> >>>>> static void intel_xc_cpuid_policy( [...]
> >>>>>             case 0x80000001: {
> >>>>>                 int is_64bit = hypervisor_is_64bit(xch) &&
> >>>>> is_pae;
> >>>>> 
> >>>>>                 /* Only a few features are advertised in Intel's
> >>>>>                 0x80000001. */ regs[2] &= (is_64bit ?
> >>> bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
> >>>>> 
> >>> bitmaskof(X86_FEATURE_ABM);
> >>>>>                 regs[3] &= ((is_pae ? bitmaskof(X86_FEATURE_NX) :
> >>>>> 0)
> >>> |
> >>>>>                             (is_64bit ? bitmaskof(X86_FEATURE_LM) :
> >>>>>                             0) | (is_64bit ?
> >>>>>                             bitmaskof(X86_FEATURE_SYSCALL) : 0) |
> >>>>>                             (is_64bit ?
> >>> bitmaskof(X86_FEATURE_RDTSCP) : 0));
> >>>>>                 break;
> >>>>>             }
> >>>>> Which masks anything which is not explicitly mentioned. (PAGE1GB
> >>>>> is in regs[3], I think).
> >>>> 
> >>>> Ah, okay. The funs of white listing on HVM vs black listing on PV
> >>>> again.
> >>>> 
> >>>>> The AMD version is more permissive:
> >>>>> 
> >>>>>         regs[3] &= (0x0183f3ff | /* features shared with
> >>> 0x00000001:EDX */
> >>>>>                     (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
> >>>>>                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
> >>>>>                     bitmaskof(X86_FEATURE_SYSCALL) |
> >>>>>                     bitmaskof(X86_FEATURE_MP) |
> >>>>>                     bitmaskof(X86_FEATURE_MMXEXT) |
> >>>>>                     bitmaskof(X86_FEATURE_FFXSR) |
> >>>>>                     bitmaskof(X86_FEATURE_3DNOW) |
> >>>>>                     bitmaskof(X86_FEATURE_3DNOWEXT)); (but I
> >>>>> didn't check if PAGE1GB is in that magic number...)
> >>>> 
> >>>> It's not - it's bit 26.
> >>> 
> >>> So.. it sounds to me like everybody is in the agreement that this
> >>> is the right thing to do (enable it if the hypervisor has it enabled)?
> >>> 
> >>> And the next thing is actually come up with a patch to do some of
> >>> this plumbing - naturally for Xen 4.5?
> >> 
> >> Hi, Konrad,
> >> 
> >> Is there any patch to turn on the 1GB hugepages? If no, we are happy
> >> to give
> > a patch to do it.
> > 
> > I have not see a patch for this, and I would be quite happy to see
> > patch developed for this!
> 
> OK. We will provide a patch ASAP.

Excellent. Looking forward to it!
> 
> Best regards,
> Yang
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:46:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoDdu-0005cB-DA; Tue, 11 Nov 2014 15:46:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoDdt-0005c6-5V
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 15:46:05 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	65/0C-26740-C3F22645; Tue, 11 Nov 2014 15:46:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415720762!11865363!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1359 invoked from network); 11 Nov 2014 15:46:03 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 15:46:03 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABFjfEO030762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 15:45:42 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABFjeGr026060
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 15:45:41 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABFje9l010719; Tue, 11 Nov 2014 15:45:40 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 07:45:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E5915113DA8; Tue, 11 Nov 2014 10:45:38 -0500 (EST)
Date: Tue, 11 Nov 2014 10:45:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Message-ID: <20141111154538.GC6597@laptop.dumpdata.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<1414377878-23497-2-git-send-email-wangyijing@huawei.com>
	<20141111000456.GB21470@google.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141111000456.GB21470@google.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Yijing Wang <wangyijing@huawei.com>, linux-pci@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix
 the MSI mask bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 05:04:56PM -0700, Bjorn Helgaas wrote:
> On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
> > Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> > fixed MSI mask bug which may cause kernel crash. But the commit
> > made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask"
> > to ignore MSI/MSI-X to fix this issue, it's a cleaner solution.
> > And the commit 0e4ccb1505a9 will be reverted in the later patch.
> 
> The 0e4ccb1505a9 changelog says Xen guests can't write to MSI-X BARs.
> But it makes mask_irq a no-op for both MSI-X and MSI.  The MSI mask bit is
> in config space, not in memory space.  So why does mask_irq need to be a
> no-op for MSI as well?  Are Xen guests prohibited from writing to config

The PV guests it refers do not do write to config space. They have
an PCI frontend and backend driver which communicates to the backend (the
trusted domain) to setup the MSI and MSI-X. The 'pci_xen_init' (arch/x86/pci/xen.c)
is the one that sets up the overrides. When an MSI or MSI-X is requested
it is done via the request_irq which ends up calling 'xen_setup_msi_irqs'.
If you look there you can see:

173         if (type == PCI_CAP_ID_MSIX)                                            
174                 ret = xen_pci_frontend_enable_msix(dev, v, nvec);               
175         else                                                                    
176                 ret = xen_pci_frontend_enable_msi(dev, v);                      
177         if (ret)                                                                
178                 goto error;                                                     

Which are the calls to the Xen PCI driver to communicate with the
backend to setup the MSI.

> space, too?  (It's fine if they are; it's just that the changelog
> specifically mentioned MSI-X memory space tables, and it didn't mention
> config space at all.)

Correct. The config space is accessible to the guest but if it writes
to it - all of those values are ignored by the hypervisor - and that
is because the backend is suppose to communicate to the hypervisor
whether the guest can indeed setup MSI or MSI-X.

> 
> And I *assume* there's some Xen mechanism that accomplishes the mask_irq in
> a different way, since the actual mask_irq interface does nothing?  (This
> is really a question for 0e4ccb1505a9, since I don't think this particular
> patch changes anything in that respect.)

Correct. 'request_irq' ends up doing that. Or rather it ends up
calling xen_setup_msi_irqs which takes care of that.

The Xen PV guests (not to be confused with Xen HVM guests) run without
any emulated devices. That means most of the x86 platform things - ioports,
VGA, etc - are removed. Instead that functionality is provided via 
frontend drivers that communicate to the backend via a ring.

Hopefully this clarifies it?
> 
> > Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> > CC: David Vrabel <david.vrabel@citrix.com>
> > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > CC: xen-devel@lists.xenproject.org
> > ---
> >  arch/x86/pci/xen.c  |    2 ++
> >  drivers/pci/msi.c   |    7 ++++++-
> >  include/linux/msi.h |    1 +
> >  3 files changed, 9 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> > index 093f5f4..5ef62ed 100644
> > --- a/arch/x86/pci/xen.c
> > +++ b/arch/x86/pci/xen.c
> > @@ -427,6 +427,7 @@ int __init pci_xen_init(void)
> >  	x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
> >  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
> >  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> > +	pci_msi_ignore_mask = 1;
> >  #endif
> >  	return 0;
> >  }
> > @@ -508,6 +509,7 @@ int __init pci_xen_initial_domain(void)
> >  	x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
> >  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
> >  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> > +	pci_msi_ignore_mask = 1;
> >  #endif
> >  	xen_setup_acpi_sci();
> >  	__acpi_register_gsi = acpi_register_gsi_xen;
> > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> > index 38511d9..ecb5f54 100644
> > --- a/drivers/pci/msi.c
> > +++ b/drivers/pci/msi.c
> > @@ -23,6 +23,7 @@
> >  #include "pci.h"
> >  
> >  static int pci_msi_enable = 1;
> > +int pci_msi_ignore_mask;
> >  
> >  #define msix_table_size(flags)	((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
> >  
> > @@ -166,7 +167,7 @@ u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> >  {
> >  	u32 mask_bits = desc->masked;
> >  
> > -	if (!desc->msi_attrib.maskbit)
> > +	if (pci_msi_ignore_mask || !desc->msi_attrib.maskbit)
> >  		return 0;
> >  
> >  	mask_bits &= ~mask;
> > @@ -198,6 +199,10 @@ u32 default_msix_mask_irq(struct msi_desc *desc, u32 flag)
> >  	u32 mask_bits = desc->masked;
> >  	unsigned offset = desc->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
> >  						PCI_MSIX_ENTRY_VECTOR_CTRL;
> > +
> > +	if (pci_msi_ignore_mask)
> > +		return 0;
> > +
> >  	mask_bits &= ~PCI_MSIX_ENTRY_CTRL_MASKBIT;
> >  	if (flag)
> >  		mask_bits |= PCI_MSIX_ENTRY_CTRL_MASKBIT;
> > diff --git a/include/linux/msi.h b/include/linux/msi.h
> > index 44f4746..86dc501 100644
> > --- a/include/linux/msi.h
> > +++ b/include/linux/msi.h
> > @@ -10,6 +10,7 @@ struct msi_msg {
> >  	u32	data;		/* 16 bits of msi message data */
> >  };
> >  
> > +extern int pci_msi_ignore_mask;
> >  /* Helper functions */
> >  struct irq_data;
> >  struct msi_desc;
> > -- 
> > 1.7.1
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:46:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoDdu-0005cB-DA; Tue, 11 Nov 2014 15:46:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoDdt-0005c6-5V
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 15:46:05 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	65/0C-26740-C3F22645; Tue, 11 Nov 2014 15:46:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415720762!11865363!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1359 invoked from network); 11 Nov 2014 15:46:03 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 15:46:03 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABFjfEO030762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 15:45:42 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABFjeGr026060
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 15:45:41 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABFje9l010719; Tue, 11 Nov 2014 15:45:40 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 07:45:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E5915113DA8; Tue, 11 Nov 2014 10:45:38 -0500 (EST)
Date: Tue, 11 Nov 2014 10:45:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Message-ID: <20141111154538.GC6597@laptop.dumpdata.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<1414377878-23497-2-git-send-email-wangyijing@huawei.com>
	<20141111000456.GB21470@google.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141111000456.GB21470@google.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Yijing Wang <wangyijing@huawei.com>, linux-pci@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix
 the MSI mask bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 05:04:56PM -0700, Bjorn Helgaas wrote:
> On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
> > Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> > fixed MSI mask bug which may cause kernel crash. But the commit
> > made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask"
> > to ignore MSI/MSI-X to fix this issue, it's a cleaner solution.
> > And the commit 0e4ccb1505a9 will be reverted in the later patch.
> 
> The 0e4ccb1505a9 changelog says Xen guests can't write to MSI-X BARs.
> But it makes mask_irq a no-op for both MSI-X and MSI.  The MSI mask bit is
> in config space, not in memory space.  So why does mask_irq need to be a
> no-op for MSI as well?  Are Xen guests prohibited from writing to config

The PV guests it refers do not do write to config space. They have
an PCI frontend and backend driver which communicates to the backend (the
trusted domain) to setup the MSI and MSI-X. The 'pci_xen_init' (arch/x86/pci/xen.c)
is the one that sets up the overrides. When an MSI or MSI-X is requested
it is done via the request_irq which ends up calling 'xen_setup_msi_irqs'.
If you look there you can see:

173         if (type == PCI_CAP_ID_MSIX)                                            
174                 ret = xen_pci_frontend_enable_msix(dev, v, nvec);               
175         else                                                                    
176                 ret = xen_pci_frontend_enable_msi(dev, v);                      
177         if (ret)                                                                
178                 goto error;                                                     

Which are the calls to the Xen PCI driver to communicate with the
backend to setup the MSI.

> space, too?  (It's fine if they are; it's just that the changelog
> specifically mentioned MSI-X memory space tables, and it didn't mention
> config space at all.)

Correct. The config space is accessible to the guest but if it writes
to it - all of those values are ignored by the hypervisor - and that
is because the backend is suppose to communicate to the hypervisor
whether the guest can indeed setup MSI or MSI-X.

> 
> And I *assume* there's some Xen mechanism that accomplishes the mask_irq in
> a different way, since the actual mask_irq interface does nothing?  (This
> is really a question for 0e4ccb1505a9, since I don't think this particular
> patch changes anything in that respect.)

Correct. 'request_irq' ends up doing that. Or rather it ends up
calling xen_setup_msi_irqs which takes care of that.

The Xen PV guests (not to be confused with Xen HVM guests) run without
any emulated devices. That means most of the x86 platform things - ioports,
VGA, etc - are removed. Instead that functionality is provided via 
frontend drivers that communicate to the backend via a ring.

Hopefully this clarifies it?
> 
> > Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> > CC: David Vrabel <david.vrabel@citrix.com>
> > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > CC: xen-devel@lists.xenproject.org
> > ---
> >  arch/x86/pci/xen.c  |    2 ++
> >  drivers/pci/msi.c   |    7 ++++++-
> >  include/linux/msi.h |    1 +
> >  3 files changed, 9 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> > index 093f5f4..5ef62ed 100644
> > --- a/arch/x86/pci/xen.c
> > +++ b/arch/x86/pci/xen.c
> > @@ -427,6 +427,7 @@ int __init pci_xen_init(void)
> >  	x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
> >  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
> >  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> > +	pci_msi_ignore_mask = 1;
> >  #endif
> >  	return 0;
> >  }
> > @@ -508,6 +509,7 @@ int __init pci_xen_initial_domain(void)
> >  	x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
> >  	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
> >  	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> > +	pci_msi_ignore_mask = 1;
> >  #endif
> >  	xen_setup_acpi_sci();
> >  	__acpi_register_gsi = acpi_register_gsi_xen;
> > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> > index 38511d9..ecb5f54 100644
> > --- a/drivers/pci/msi.c
> > +++ b/drivers/pci/msi.c
> > @@ -23,6 +23,7 @@
> >  #include "pci.h"
> >  
> >  static int pci_msi_enable = 1;
> > +int pci_msi_ignore_mask;
> >  
> >  #define msix_table_size(flags)	((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
> >  
> > @@ -166,7 +167,7 @@ u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> >  {
> >  	u32 mask_bits = desc->masked;
> >  
> > -	if (!desc->msi_attrib.maskbit)
> > +	if (pci_msi_ignore_mask || !desc->msi_attrib.maskbit)
> >  		return 0;
> >  
> >  	mask_bits &= ~mask;
> > @@ -198,6 +199,10 @@ u32 default_msix_mask_irq(struct msi_desc *desc, u32 flag)
> >  	u32 mask_bits = desc->masked;
> >  	unsigned offset = desc->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
> >  						PCI_MSIX_ENTRY_VECTOR_CTRL;
> > +
> > +	if (pci_msi_ignore_mask)
> > +		return 0;
> > +
> >  	mask_bits &= ~PCI_MSIX_ENTRY_CTRL_MASKBIT;
> >  	if (flag)
> >  		mask_bits |= PCI_MSIX_ENTRY_CTRL_MASKBIT;
> > diff --git a/include/linux/msi.h b/include/linux/msi.h
> > index 44f4746..86dc501 100644
> > --- a/include/linux/msi.h
> > +++ b/include/linux/msi.h
> > @@ -10,6 +10,7 @@ struct msi_msg {
> >  	u32	data;		/* 16 bits of msi message data */
> >  };
> >  
> > +extern int pci_msi_ignore_mask;
> >  /* Helper functions */
> >  struct irq_data;
> >  struct msi_desc;
> > -- 
> > 1.7.1
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:46:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoDe2-0005cZ-P5; Tue, 11 Nov 2014 15:46:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoDe1-0005cT-Lu
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 15:46:13 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	8F/22-19763-44F22645; Tue, 11 Nov 2014 15:46:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415720770!11817070!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12856 invoked from network); 11 Nov 2014 15:46:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Nov 2014 15:46:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABFjxLD029262
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 15:45:59 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sABFjvZh027014
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 15:45:58 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABFjvFZ011600; Tue, 11 Nov 2014 15:45:57 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 07:45:57 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7B929113DAB; Tue, 11 Nov 2014 10:45:56 -0500 (EST)
Date: Tue, 11 Nov 2014 10:45:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20141111154556.GD6597@laptop.dumpdata.com>
References: <20140110184151.GA20232@pegasus.dumpdata.com>
	<1389607803.8187.22.camel@kazak.uk.xensource.com>
	<52D3DC730200007800112FF6@nat28.tlf.novell.com>
	<1389613109.13654.43.camel@kazak.uk.xensource.com>
	<52D3E1500200007800113058@nat28.tlf.novell.com>
	<20140115200736.GB5201@phenom.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABD8C46@SHSMSX104.ccr.corp.intel.com>
	<20141110145720.GH3783@laptop.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABDACCC@SHSMSX104.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABDACCC@SHSMSX104.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Li, Liang Z" <liang.z.li@intel.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "Nakajima, Jun" <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 03:30:54AM +0000, Zhang, Yang Z wrote:
> Konrad Rzeszutek Wilk wrote on 2014-11-10:
> > On Mon, Nov 10, 2014 at 05:08:09AM +0000, Zhang, Yang Z wrote:
> >> Konrad Rzeszutek Wilk wrote on 2014-01-16:
> >>> On Mon, Jan 13, 2014 at 11:51:28AM +0000, Jan Beulich wrote:
> >>>>>>> On 13.01.14 at 12:38, Ian Campbell <Ian.Campbell@citrix.com>
> > wrote:
> >>>>> On Mon, 2014-01-13 at 11:30 +0000, Jan Beulich wrote:
> >>>>>> In fact I can't see where this would be forced off:
> >>>>>> xc_cpuid_x86.c only does so in the PV case, and all
> >>>>>> hvm_pse1gb_supported() is that the CPU supports it and the
> >>>>>> domain
> > uses HAP.
> >>>>> 
> >>>>> Took me a while to spot it too:
> >>>>> static void intel_xc_cpuid_policy( [...]
> >>>>>             case 0x80000001: {
> >>>>>                 int is_64bit = hypervisor_is_64bit(xch) &&
> >>>>> is_pae;
> >>>>> 
> >>>>>                 /* Only a few features are advertised in Intel's
> >>>>>                 0x80000001. */ regs[2] &= (is_64bit ?
> >>> bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
> >>>>> 
> >>> bitmaskof(X86_FEATURE_ABM);
> >>>>>                 regs[3] &= ((is_pae ? bitmaskof(X86_FEATURE_NX) :
> >>>>> 0)
> >>> |
> >>>>>                             (is_64bit ? bitmaskof(X86_FEATURE_LM) :
> >>>>>                             0) | (is_64bit ?
> >>>>>                             bitmaskof(X86_FEATURE_SYSCALL) : 0) |
> >>>>>                             (is_64bit ?
> >>> bitmaskof(X86_FEATURE_RDTSCP) : 0));
> >>>>>                 break;
> >>>>>             }
> >>>>> Which masks anything which is not explicitly mentioned. (PAGE1GB
> >>>>> is in regs[3], I think).
> >>>> 
> >>>> Ah, okay. The funs of white listing on HVM vs black listing on PV
> >>>> again.
> >>>> 
> >>>>> The AMD version is more permissive:
> >>>>> 
> >>>>>         regs[3] &= (0x0183f3ff | /* features shared with
> >>> 0x00000001:EDX */
> >>>>>                     (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
> >>>>>                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
> >>>>>                     bitmaskof(X86_FEATURE_SYSCALL) |
> >>>>>                     bitmaskof(X86_FEATURE_MP) |
> >>>>>                     bitmaskof(X86_FEATURE_MMXEXT) |
> >>>>>                     bitmaskof(X86_FEATURE_FFXSR) |
> >>>>>                     bitmaskof(X86_FEATURE_3DNOW) |
> >>>>>                     bitmaskof(X86_FEATURE_3DNOWEXT)); (but I
> >>>>> didn't check if PAGE1GB is in that magic number...)
> >>>> 
> >>>> It's not - it's bit 26.
> >>> 
> >>> So.. it sounds to me like everybody is in the agreement that this
> >>> is the right thing to do (enable it if the hypervisor has it enabled)?
> >>> 
> >>> And the next thing is actually come up with a patch to do some of
> >>> this plumbing - naturally for Xen 4.5?
> >> 
> >> Hi, Konrad,
> >> 
> >> Is there any patch to turn on the 1GB hugepages? If no, we are happy
> >> to give
> > a patch to do it.
> > 
> > I have not see a patch for this, and I would be quite happy to see
> > patch developed for this!
> 
> OK. We will provide a patch ASAP.

Excellent. Looking forward to it!
> 
> Best regards,
> Yang
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:50:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoDia-0005sR-Ta; Tue, 11 Nov 2014 15:50:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bugs@bugs.xenproject.org>)
	id 1XoDiY-0005sM-IT
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 15:50:54 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	60/8F-02698-D5032645; Tue, 11 Nov 2014 15:50:53 +0000
X-Env-Sender: xen-devel-bugs@bugs.xenproject.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415721052!11833535!1
X-Originating-IP: [50.56.82.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12051 invoked from network); 11 Nov 2014 15:50:53 -0000
Received: from bugs.xenproject.org (HELO bugs.xenproject.org) (50.56.82.209)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 11 Nov 2014 15:50:53 -0000
Received: from xen-devel-bugs by bugs.xenproject.org with local (Exim 4.80)
	(envelope-from <xen-devel-bugs@bugs.xenproject.org>)
	id 1XoDrO-0004gt-DB; Tue, 11 Nov 2014 16:00:02 +0000
Content-Disposition: inline
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
From: xen@bugs.xenproject.org
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org
Message-ID: <control-reply-1415721602.18033@bugs.xenproject.org>
References: <20141111150258.GA11580@laptop.dumpdata.com>
In-Reply-To: <20141111150258.GA11580@laptop.dumpdata.com>
X-Emesinae-Message: control
X-Emesinae-Control-From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Emesinae-Control-Number-Commands: 1
Date: Tue, 11 Nov 2014 16:00:02 +0000
Subject: [Xen-devel] Processed: close 6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Processing commands for xen@bugs.xenproject.org:

> close 6
Closing bug #6
> 

Modified/created Bugs:
 - 6: http://bugs.xenproject.org/xen/bug/6

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs
Contact xen-bugs-owner@bugs.xenproject.org with any infrastructure issues

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 15:50:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 15:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoDia-0005sR-Ta; Tue, 11 Nov 2014 15:50:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bugs@bugs.xenproject.org>)
	id 1XoDiY-0005sM-IT
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 15:50:54 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	60/8F-02698-D5032645; Tue, 11 Nov 2014 15:50:53 +0000
X-Env-Sender: xen-devel-bugs@bugs.xenproject.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415721052!11833535!1
X-Originating-IP: [50.56.82.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12051 invoked from network); 11 Nov 2014 15:50:53 -0000
Received: from bugs.xenproject.org (HELO bugs.xenproject.org) (50.56.82.209)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 11 Nov 2014 15:50:53 -0000
Received: from xen-devel-bugs by bugs.xenproject.org with local (Exim 4.80)
	(envelope-from <xen-devel-bugs@bugs.xenproject.org>)
	id 1XoDrO-0004gt-DB; Tue, 11 Nov 2014 16:00:02 +0000
Content-Disposition: inline
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
From: xen@bugs.xenproject.org
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org
Message-ID: <control-reply-1415721602.18033@bugs.xenproject.org>
References: <20141111150258.GA11580@laptop.dumpdata.com>
In-Reply-To: <20141111150258.GA11580@laptop.dumpdata.com>
X-Emesinae-Message: control
X-Emesinae-Control-From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Emesinae-Control-Number-Commands: 1
Date: Tue, 11 Nov 2014 16:00:02 +0000
Subject: [Xen-devel] Processed: close 6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Processing commands for xen@bugs.xenproject.org:

> close 6
Closing bug #6
> 

Modified/created Bugs:
 - 6: http://bugs.xenproject.org/xen/bug/6

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs
Contact xen-bugs-owner@bugs.xenproject.org with any infrastructure issues

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:39:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoESy-0007Lr-Sq; Tue, 11 Nov 2014 16:38:52 +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 1XoESx-0007Lm-NH
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 16:38:52 +0000
Content-Length: 17943
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	2B/95-03145-B9B32645; Tue, 11 Nov 2014 16:38:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415723928!11830000!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14234 invoked from network); 11 Nov 2014 16:38:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 16:38:49 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABGafOd010091
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 16:36:41 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sABGacjA027391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 16:36:39 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABGacMj019865; Tue, 11 Nov 2014 16:36:38 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 08:36:37 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EC31A113DFB; Tue, 11 Nov 2014 11:36:33 -0500 (EST)
From: konrad.wilk@oracle.com
To: <tiejun.chen@intel.com>, <avanzini.arianna@gmail.com>,
	<boris.ostrovsky@oracle.com>, <ufimtseva@gmail.com>,
	<guijianfeng@cn.fujitsu.com>, <eddie.dong@intel.com>,
	<jgross@suse.com>, <roger.pau@citrix.com>,
	<artem.mygaiev@globallogic.com>, <ian.jackson@eu.citrix.com>,
	<daniel.kiper@oracle.com>, <ian.campbell@citrix.com>,
	<Ian.Jackson@eu.citrix.com>, <Kelly.Zytaruk@amd.com>,
	<anthony.perard@citrix.com>, <mukesh.rathor@oracle.com>,
	<dslutz@verizon.com>, <aravindp@cisco.com>,
	<josh.whitehead@dornerworks.com>, <robert.vanvossen@dornerworks.com>,
	<Paul.Skentzos@dornerworks.com>, <Steve.VanderLeest@dornerworks.com>,
	<andrii.tseglytskyi@globallogic.com>, <yang.z.zhang@intel.com>,
	<ross.lagerwall@citrix.com>, <malcolm.crossley@citrix.com>,
	<george.dunlap@eu.citrix.com>, <bob.liu@oracle.com>,
	<yjhyun.yoo@samsung.com>, <serge.broslavsky@linaro.org>,
	<christoffer.dall@linaro.org>, <julien.grall@linaro.org>,
	<manishjaggi.oss@gmail.com>, <olaf@aepfle.de>, <wency@cn.fujitsu.com>, 
	<dave.scott@citrix.com>, <andrew.cooper3@citrix.com>,
	<david.vrabel@citrix.com>, <yanghy@cn.fujitsu.com>,
	<zhigang.x.wang@oracle.com>, <msw@amazon.com>,
	<xen-devel@lists.xenproject.org>, <stefano.stabellini@eu.citrix.com>,
	<tklengyel@sec.in.tum.de>, <suriyan.r@gmail.com>,
	<vijay.kilari@gmail.com>, <Vijaya.Kumar@caviumnetworks.com>,
	<talex5@gmail.com>, <parth.dixit@linaro.org>,
	<Ian.Campbell@citrix.com>, <roy.franz@linaro.org>,
	<chao.p.peng@linux.intel.com>, <mengxu@cis.upenn.edu>,
	<rcojocaru@bitdefender.com>, <feng.wu@intel.com>,
	<Aravind.Gopalakrishnan@amd.com>, <Suravee.Suthikulpanit@amd.com>,
	<Paul.Durrant@citrix.com>, <dario.faggioli@citrix.com>,
	<Wei.Liu2@citrix.com>, <m.a.young@durham.ac.uk>, <mcgrof@suse.com>
Message-Id: <20141111163633.EC31A113DFB@laptop.dumpdata.com>
Date: Tue, 11 Nov 2014 11:36:33 -0500 (EST)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] Xen 4.5-rc2 update (RC2 is out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4042808384627024036=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4042808384627024036==
Content-Length: 18126
Content-Transfer-Encoding: quoted-printable

Feature patchsets that did not make it in by today have been put
on the deferred list. If you think your feature should make it by Xen 4.5-RC3
please make your case.

Xen 4.5-rc2 is out today (one day early!). There is one known issue
(see 'Known Issues' below) which are to be fixed by RC3 - if:
 - The maintainers are fine with it,
 - The risk is minimal to common code paths.

The official test-day is on Thursday (Nov 13th)
but if you want to start testing it today - please do!

Details for the test-day are at

http://wiki.xen.org/wiki/Xen_4.5_RC2_test_instructions

In terms of bugs, we have:

#11 qxl hypervisor support
#13 Re: [Xen-devel] man page example: xm block-attach
#18 xl improve support for migration over non-sshlike tunnels
#19 xl migrate transport improvements
#22 xl does not support specifying virtual function for passthrough device
#23 Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks
#24 xl missing support for encrypted VNC
#27 Re: [Xen-devel] xend vs xl with pci=3D['<bdf'] wherein the '<bdf>' are not owned by pciback or pcistub will still launch.
#28 support PCI hole resize in qemu-xen

[Isn't this fixed by Don's 'mmio_hole' patches=3F]

#30 libxl should implement non-suspend-cancel based resume path
#36 credit2 only uses one runqueue instead of one runq per socket
#38 Implement VT-d large pages so we can avoid sharing between EPT
#40 linux pvops: fpu corruption due to incorrect assumptions
#42 "linux, S3 resume of PVHVM fails - missing call to xen_arch_post_suspend=3F"
#43 "30s delay loading xenfb driver on some systems"
#44 Security policy ambiguities - XSA-108 process post-mortem
#45 arm: domain 0 disables clocks which are in fact being used


=3D Timeline =3D

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:


* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
* RC2: Nov 11th <=3D=3D=3D=3D <WE ARE HERE> (was Nov 12th originally)
* RC2 Test-day: Nov 13th
* RC3: Nov 24th
* RC3 Test-day: Nov 25th
* Release: 10th December 2014

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  The feature freeze may be
slipped for especially important features which are near completion.

Bug-fixes, if Acked-by by maintainer, can go anytime before the First
RC. Later on we will need to figure out the risk of regression/reward
to eliminate the possiblity of a bug introducing another bug.

=3D Prognosis =3D

The states are: none -> fair -> ok -> good -> done

none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok   - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs

=3D Feature freeze exception =3D

Remember our goal for the release:
  1. A bug-free release
  2. An awesome release
  3. An on-time release

Accepting a new feature may make Xen more awesome; but it also
introduces a risk that it will introduce more bugs.  That bug may be
found before the release (threatening #3), or it may not be found
until after the release (threatening #1).  Each freeze exception
request will attempt to balance the benefits (how awesome the
exception is) vs the risks (will it cause the release to slip, or
worse, cause a bug which goes un-noticed into the final release).

The idea is that today we will be pretty permissive, but that we will
become progressively more conservative until the first RC, which was
scheduled for 3 weeks' time (October 25).  After that, we will only
accept bug fixes.

Bug fixes can be checked in without a freeze exception throughout the
code freeze, unless the maintainer thinks they are particularly high
risk.  In later RC's, we may even begin rejecting bug fixes if the
broken functionality is small and the risk to other functionality is
high.

Features which are currently marked "experimental" or do not at the
moment work at all cannot be broken really; so changes to code only
used by those features should be able to get a freeze exception
easily.

Features which change or add new interfaces which will need to be
supported in a backwards-compatible way (for instance, vNUMA) will
need freeze exceptions to make sure that the interface itself has
enough time to be considered stable.

These are guidelines and principles to give you an idea where we're
coming from; if you think there's a good reason why making an
exception for you will help us achieve goals 1-3 above better than not
doing so, feel free to make your case.

=3D Open =3D

=3D=3D Known issues =3D=3D 

*  xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/RAM (good)
   RFC v6
   Treating pieces as bug-fixes only.
  -  Tiejun Chen

=3D=3D Linux =3D=3D 

*  Linux block multiqueue (ok)
   v2 posted.
  -  Arianna Avanzini

*  VPMU - 'perf' support in Linux (ok)
   Depends on Xen patches
   Acked by David Vrabel
  -  Boris Ostrovsky

*  vNUMA in Linux (ok)
   v6 posted
   git://gitorious.org/vnuma/linux_vnuma.git
  -  Elena Ufimtseva

*  vsyscall in Linux (fair)
  -  Konrad Rzeszutek Wilk

*  COLO Agent in Linux (fair)
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  vAPIC in PVHVM guests (Linux side) (none)
  -  Boris Ostrovsky

*  Fix PAT in Linux kernel (aka Full support for PAT) (good)
   Acked and reposted for v3.18. Waiting for x86 maintainers.
   Ingo has been giving advice.
  -  Juergen Gross

=3D=3D FreeBSD =3D=3D 

*  PVH FreeBSD dom0 (ok)
   FreeBSD 11 goal. Toolstack side done in Xen 4.5
  -  Roger Pau Monn=C3=A9

=3D=3D Other OSes (MiniOS, QNX) =3D=3D 

*  PV drivers for automotive kernels (fair)
  -  Artem Mygaiev

*  mini-os: xenbus changes for rump kernels (ok)
   git://xenbits.xen.org/people/iwj/rumpuser-xen.git
   branch: base.dev-xen-xenbus.v1..dev-xen-xenbus.v1
   v2 posted
  -  Ian Jackson

=3D=3D GRUB2 =3D=3D 

*  GRUB2 multiboot2 (fair)
  -  Daniel Kiper

=3D=3D OSSTEST =3D=3D 

*  OSSTest: libvirt (good)
  -  Ian Campbell

=3D=3D Deferred to QEMU v2.next =3D=3D 

*  Using qemu-upstream in a stubdomain (fair)
   Will use rump kernels.
  -  Ian Jackson

*  AMD Radeon PCI GPU passthrough (none)
   Focusing on Xen 4.2 and qemu-traditional
  -  Kelly Zytaruk

*  Intel IGD PCI GPU passthrough (ok)
   v5 posted
  -  Chen, Tiejun

*  Update Xen tree to use upstream OVMF (fair)
  -  Anthony PERARD

=3D=3D Deferred to Xen hypervisor 4.6 =3D=3D 

*  VPMU - 'perf' support in Xen (good)
   v14 posted
   Need reviews/final ack.
  -  Boris Ostrovsky

*  Xen Boot Information (xbi) (ok)
   Dependency for GRUB2 + EFI work
   http://lists.xen.org/archives/html/xen-devel/2014-10/msg02068.html
   v4, No go for full patchset. Only some of the patches.
   No ARM EFI hardware (yet) available to test them.
  -  Daniel Kiper

*  PVH - AMD hardware support. (fair)
   Posted.
  -  Mukesh Rathor

*  VMware backdoor (hypercall) (ok)
   v5 posted.
  -  Don Slutz

*  extending mem_access support to PV domain (fair)
   RFC v2
  -  Aravindh Puthiyaparambil (aravindp)

*  Repurpose SEDF Scheduler for Real-time (fair)
   RFC patch posted (v2)
  -  Joshua Whitehead, Robert VanVossen

*  ARM remote processor iommu module (GPUs + IPUs) (fair)
   v3 posted
  -  Andrii Tseglytskyi

*  dirty vram / IOMMU bug (fair)
   http://bugs.xenproject.org/xen/bug/38
  -  Zhang, Yang Z

*  Xen multiboot2-EFI support (fair)
   Needed for GrUB2
   Depends on Xen Boot info (rework multiboot and other structs)
   See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html
   RFC posted
  -  Daniel Kiper

*  Support controlling the max C-state sub-state (fair)
   v3 posted
   Hadn't see the patch reposted.
  -  Ross Lagerwall

*  IOMMU ABI for guests to map their DMA regions (fair)
  -  Malcolm Crossley

*  Default to credit2 (none)
   cpu pinning, numa affinity and cpu reservation
  -  George Dunlap

*  Convert tasklet to per-cpu tasklets (fair)
   RFC posted
  -  Konrad Rzeszutek Wilk

*  Further tmem cleanups/fixes (16TB etc) (fair)
  -  Bob Liu

*  1TB slow destruction (ok)
  -  Bob Liu

*  ARM VM save/restore/live migration (none)
   Need to rebased against migrationv2 - no code posted.
  -  Junghyun Yoo

*  ARM GICv2m support (none)
  -  Linaro (unknown)

*  ARM - SMMU resync of Linux's one (none)
  -  Julien Grall

*  ARM - passthrough of non-PCI (none)
  -  Julien Grall

*  ARM64 (Cavium Thunder)  PCI passthrough (fair)
  -  Manish Jaggi

=3D=3D Deferred to Xen toolstack 4.6 =3D=3D 

*  vNUMA in Xen toolstack (ok)
   v11 posted
   Hypervisor part in
   git://gitorious.org/vnuma/xen_vnuma.git:v11
  -  Elena Ufimtseva

*  pvscsi in libxl (fair)
  -  Juergen Gross and Olaf

*  COarse-grain LOck-stepping Virtual Machines in Xen (fair)
   RFC v3 posted, based on remus-v19
  -  Wen Congyang
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  extend the xenstore ring with a 'closing' signal (fair)
   RFC patch posted
  -  David Scott

*  New Migration (v2). (good)
   v7 (libxc and libxl)
   git://xenbits.xen.org/people/andrewcoop/xen.git
   Seems that it might need to slip or we run v1 alongside v2.
  -  Andrew Cooper & David Vrabel

*  libxl migrationv2 patches. (none)
  -  Andrew Cooper & David Vrabel

*  tmem migrationv2 patches. (none)
  -  Bob Liu & Andrew Cooper & David Vrabel

*  Remus using migration-v2 (fair)
   RFC posted - depends on v6 of 'New Migration'
  -  Yang Hongyang

*  snapshot API extension (checkpointing disk) (ok)
   v5
   His email bounces.
  -  Bamvor Jian Zhang

*  Rearrange and cleanup installation destination directories (/var -> var/lib/xen) (fair)
  -  Daniel Kiper

*  libxl/xl - xm compatibility mode for mem-max and mem-set; (ok)
  -  Daniel Kiper

*  xl list --long (and some related xl commands) have some bugs (none)
  -  Zhigang Wang

*  Xen HPET interrupt fixes (fair)
   behind migration v2
  -  Andrew Cooper

*  cpuid leveling (none)
   http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-D.pdf
  -  Andrew Cooper

*  live migration knobs, there is no suitable code yet, just ideas (none)
    http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html
  -  Olaf Hering

*  xl does not handle migrate interruption gracefully (none)
   If you start a localhost migrate, and press "Ctrl-C" in the middle, you get two hung domains
  -  Ian Jackson

*  IO-NUMA - hwloc and xl (none)
   Andrew Cooper had an RFC patch for hwloc
   add restrictions  as to which devices cannot safely/functionally be split apart.
  -  Boris Ostrovsky

*  HVM guest NUMA (none)
  -  Matt Wilson

*  PVH - Migration of PVH DomUs. (none)
   Depends on migration2 code
  -  Roger Pau Monn=C3=A9

*  PVH - Migration of guests from a PVH dom0  (none)
   Depends on migration2 code
  -  Roger Pau Monn=C3=A9

=3D=3D Deferred to Linux's after Xen 4.6 =3D=3D 

*  Linux ARM - Device assigment usage in Linux code (arch/arm) non-PCI (none)
   Depends on Xen pieces which are on the Xen 4.6 list.
  -  Julien Grall

*  Linux ARM - Device assigment (PCI) (none)
   Depends on Xen pieces which are on the Xen 4.6 list.
  -  Manish Jaggi

*  pvUSB in Linux (fronted and backend) (Fair)
  -  Juergen Gross

=3D=3D Up for grabs =3D=3D 

*  OSSTest - also test Linux PVH guests

*  PoD fixes
   if you boot with memory <=3D maxmem we have a size estimation bug

*  TLB flushing without locks in Xen

*  xl does not support specifying virtual function for passthrough device
   http://bugs.xenproject.org/xen/bug/22

*  PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with PCI/GPU passthrough
   http://bugs.xenproject.org/xen/bug/28

*  libx{c,l} error handling cleanup 

*  Adding missing 'xend' features in libxl

*  xl list -l on a dom0-only system

*  xl list -l doesn't contain tty console port

*  xl: passing more defaults in configuration in xl.conf
   There are a number of options for which it might be useful to pass a default in xl.conf.  For example, if we could have a default "backend" parameter for vifs, then it would be easy to switch back and forth between a backend in a driver domain and a backend in dom0.

*  PVH - PVH working with shadow.
   Based on Tim's work

*  PVH - PCI passthrough for DomU.

*  AMD performance regressions

*  Performance due to hypercall preemption. More preemptions - slower. (none)

=3D=3D Completed =3D=3D 

=3D=3D Hypervisor =3D=3D 

*  ARM - introduce GNTTABOP_cache_flush (ok)
   v11
  -  Stefano Stabellini

*  ARM - VGIC emulation (done)
   Reposted as gic and vgic fixes and improvements
   v12
  -  Stefano Stabellini

*  ARM implement mem_access (done)
   v12, two patches for Xen 4.6
   https://github.com/tklengyel/xen/tree arm_memaccess_12-for-4.5
  -  Tamas K Lengyel

*  ARM - Add Odroid-XU (Exynos5410) support (done)
   v6
  -  Suriyan Ramasami

*  ARM GICv3 support (done)
   v11 posted
  -  Vijay Kilari

*  ARM implement mem_access (done)
   v12, two patches for Xen 4.6
   https://github.com/tklengyel/xen/tree arm_memaccess_12-for-4.5
  -  Tamas K Lengyel

*  ARM - MiniOS (done)
   v7 posted
  -  Thomas Leonard

*  ARM XEN_DOMCTL_memory_mapping hypercall for ARM (done)
   v12 posted.
  -  Arianna Avanzini

*  ARM - XENFEAT_grant_map_11 (aka map grants refs at pfn =3D mfn) (done)
   Provide kernels an grant->MFN lookup
   v4
  -  Stefano Stabellini

*  ARM PSCI v0.2 (done)
   v11 posted
  -  Parth Dixit

*  ARM  - IOMMU support (done)
  -  Julien Grall

*  ARM Interrupt latency reduction (no maintenance interrupts) (done)
  -  Stefano Stabellini

*  ARM DRA7 support (done)
   v3 posted
   v3 with comments applied
  -  Andrii Tseglytskyi

*  ARM: Use super pages in p2m (done)
   v5 posted
  -  Ian Campbell

*  ARM Xen UEFI booting on ARM (done)
   v5
  -  Roy Franz

*  Cache QoS Monitoring - hypercalls (done)
   Just hypercalls - no toolstack changes.
   v15
   Hit a snag with rdmsr/IPI/wrmsr/IPI, possible redesign
  -  Chao Peng, Dongxiao Xu, and Shantong Kang

*  XenRT (Preemptive Global Earliest Deadline First) (done)
   v3
  -  Meng Xu

*  Introspection of HVM guests (done)
   v10, split out in for 4.5 (smaller subset)
  -  Razvan Cojocaru

*  alternative_asm in Xen (done)
  -  Feng Wu

*  SMAP (done)
  -  Feng Wu

*  Re-write of vHPET (done)
   aka hvm/hpet: Detect comparator values in the past
  -  Don Slutz

*  vAPIC in PVHVM guests (Xen side) (done)
  -  Boris Ostrovsky

*  Xen PVH dom0 (done)
  -  Mukesh Rathor

*  amd_ucode cleanups, verify patch size(enhancement) (mostly in master except one patch)

*  Data breakpoint Extension support (new-feat) (in master)

*  Feature masking MSR support (enhancement) (in master)

*  Support BRCM TruManage chip (Serial over LAN support) (new-feat) (in master)

*  fix vmce_amd* functions, unify mce_amd mcheck initialization (fixes/cleanups)

*  multiple AMD container files appended together in initrd (early initramfs)
  -  Aravind and Suravee

*  NUMA memory scrubbing (done)
  -  Konrad Rzeszutek Wilk

*  ioreq-server, aka secondary emulators (done)
  -  Paul Durrant

*  Soft affinity for vcpus (was NUMA affinity for vcpus) (good)
   v11 posted
  -  Dario Faggioli

*  HT enabled, virtualization overhead is high (Xen 4.4) (done)
   kernbench demonstrated it
   Looking and tracing
   http://www.gossamer-threads.com/lists/xen/devel/339409
   False alarm.
  -  Dario Faggioli

=3D=3D lib{xc,xl} and toolstack =3D=3D 

*  Systemd integration (done)
   Affects CentOS7, SLES12, Fedora Core 21 and Debian Jessie. Xen source contains systemd files that can be used to configure the various run-time services. In the past the distributions would carry their own version of it - but now we host them. This is not yet complete - [[http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg03064.html patches]] for this are being worked on for RC2.
  -  Wei and Olaf

*  Stubdomains build issues (done)
   stubdomains will not build. Fix is in staging (and will make RC2) or [[http://lists.xen.org/archives/html/xen-devel/2014-10/msg02925.html stubdom/Makefile should use QEMU_TRADITIONAL_LOC]]
  -  Michael Young

*  Building against libxl (outside code) (done)
   If you are building against libxl for any APIs before Xen 4.5 you will encounter building errors.
  -  Andrew Cooper

*  Build systems fixes/improvements (done)
  -  Andrew Cooper

*  libxl work - JSON to keep track of guest configs (done)
   Some patches merged, need to post more.
  -  Wei Liu

*  Remus in Xen (libxl) (done)
   v19
   url:  https://github.com/macrosheep/xen/tree/remus-v19
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  libvirt and xl discard support, so that libvirt can start using it (done)
  -  Olaf Hering

*  OSSTest: upstream QEMU (done)
  -  Ian Campbell

*  rework VM Generation ID (done)
   v7 posted
  -  David Vrabel

*  systemd support (done)
   v11
  -  Luis R. Rodriguez

*  Soft affinity for vcpus libxl/xl changes (done)
   v13 posted
  -  Dario Faggioli

=3D=3D QEMU =3D=3D 

*  Bigger PCI hole in QEMU (done)
   Needs to be rebased
  -  Don Slutz

*  QEMU 2.0 branch for qemu-upstream (done)
   It is v2.0 with 2.1 Xen backports.
  -  Stefano Stabellini

*  Xen PV block driver in OVMF (UEFI in guest) (done)
   v3
   In OVMF upstream. Not part of Xen 4.5
  -  Anthony PERARD

=3D=3D Linux 3.18 and earlier =3D=3D 

*  pvSCSI in Linux (fronted and backend) (done)
   v6
  -  Juergen Gross

*  Linux PVH dom0 (done)
  -  Mukesh Rathor

*  Netback multiqueue (good)
  -  Wei Liu

*  Linux pvops of Xen EFI hypercall support (done)
  -  Daniel Kiper

*  "Short" grant copy (just header) of packets. (done)
  -  Zoltan Kiss



--===============4042808384627024036==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4042808384627024036==--

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:39:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoETC-0007Md-PN; Tue, 11 Nov 2014 16:39:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoET5-0007MN-Ci
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 16:38:59 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	C7/B0-22777-2AB32645; Tue, 11 Nov 2014 16:38:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415723936!11814812!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13654 invoked from network); 11 Nov 2014 16:38:58 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 16:38:58 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABGcmqN012972
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 16:38:49 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sABGcmRQ005779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 16:38:48 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABGclFr019083; Tue, 11 Nov 2014 16:38:47 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 08:38:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 245B2113E01; Tue, 11 Nov 2014 11:38:46 -0500 (EST)
Date: Tue, 11 Nov 2014 11:38:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: russell.pavlicek@citrix.com, JBeulich@suse.com, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xenproject.org
Message-ID: <20141111163846.GA14979@laptop.dumpdata.com>
References: <20141110152106.GL3783@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141110152106.GL3783@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] Is: staging open for checkins. Was:Re: Xen 4.5 RC2
 (scheduled on the 12th). Committeers - please read.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 10:21:06AM -0500, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> The 'staging' has four extra patches:
> 
> e6fa63d pvgrub: ignore NUL
> fda1614 xen/arm: Add support for GICv3 for domU
> 5a430ec tools: libxl: do not overrun input buffer in libxl__parse_mac
> 379b351 tools: libxl: do not leak diskpath during local disk attach
.. snip..

All good. staging == master and we have RC2 out today.

Thank you for taking a short break from checking in code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:39:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoESy-0007Lr-Sq; Tue, 11 Nov 2014 16:38:52 +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 1XoESx-0007Lm-NH
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 16:38:52 +0000
Content-Length: 17943
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	2B/95-03145-B9B32645; Tue, 11 Nov 2014 16:38:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415723928!11830000!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14234 invoked from network); 11 Nov 2014 16:38:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 16:38:49 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABGafOd010091
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 16:36:41 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sABGacjA027391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 16:36:39 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABGacMj019865; Tue, 11 Nov 2014 16:36:38 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 08:36:37 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EC31A113DFB; Tue, 11 Nov 2014 11:36:33 -0500 (EST)
From: konrad.wilk@oracle.com
To: <tiejun.chen@intel.com>, <avanzini.arianna@gmail.com>,
	<boris.ostrovsky@oracle.com>, <ufimtseva@gmail.com>,
	<guijianfeng@cn.fujitsu.com>, <eddie.dong@intel.com>,
	<jgross@suse.com>, <roger.pau@citrix.com>,
	<artem.mygaiev@globallogic.com>, <ian.jackson@eu.citrix.com>,
	<daniel.kiper@oracle.com>, <ian.campbell@citrix.com>,
	<Ian.Jackson@eu.citrix.com>, <Kelly.Zytaruk@amd.com>,
	<anthony.perard@citrix.com>, <mukesh.rathor@oracle.com>,
	<dslutz@verizon.com>, <aravindp@cisco.com>,
	<josh.whitehead@dornerworks.com>, <robert.vanvossen@dornerworks.com>,
	<Paul.Skentzos@dornerworks.com>, <Steve.VanderLeest@dornerworks.com>,
	<andrii.tseglytskyi@globallogic.com>, <yang.z.zhang@intel.com>,
	<ross.lagerwall@citrix.com>, <malcolm.crossley@citrix.com>,
	<george.dunlap@eu.citrix.com>, <bob.liu@oracle.com>,
	<yjhyun.yoo@samsung.com>, <serge.broslavsky@linaro.org>,
	<christoffer.dall@linaro.org>, <julien.grall@linaro.org>,
	<manishjaggi.oss@gmail.com>, <olaf@aepfle.de>, <wency@cn.fujitsu.com>, 
	<dave.scott@citrix.com>, <andrew.cooper3@citrix.com>,
	<david.vrabel@citrix.com>, <yanghy@cn.fujitsu.com>,
	<zhigang.x.wang@oracle.com>, <msw@amazon.com>,
	<xen-devel@lists.xenproject.org>, <stefano.stabellini@eu.citrix.com>,
	<tklengyel@sec.in.tum.de>, <suriyan.r@gmail.com>,
	<vijay.kilari@gmail.com>, <Vijaya.Kumar@caviumnetworks.com>,
	<talex5@gmail.com>, <parth.dixit@linaro.org>,
	<Ian.Campbell@citrix.com>, <roy.franz@linaro.org>,
	<chao.p.peng@linux.intel.com>, <mengxu@cis.upenn.edu>,
	<rcojocaru@bitdefender.com>, <feng.wu@intel.com>,
	<Aravind.Gopalakrishnan@amd.com>, <Suravee.Suthikulpanit@amd.com>,
	<Paul.Durrant@citrix.com>, <dario.faggioli@citrix.com>,
	<Wei.Liu2@citrix.com>, <m.a.young@durham.ac.uk>, <mcgrof@suse.com>
Message-Id: <20141111163633.EC31A113DFB@laptop.dumpdata.com>
Date: Tue, 11 Nov 2014 11:36:33 -0500 (EST)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] Xen 4.5-rc2 update (RC2 is out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4042808384627024036=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4042808384627024036==
Content-Length: 18126
Content-Transfer-Encoding: quoted-printable

Feature patchsets that did not make it in by today have been put
on the deferred list. If you think your feature should make it by Xen 4.5-RC3
please make your case.

Xen 4.5-rc2 is out today (one day early!). There is one known issue
(see 'Known Issues' below) which are to be fixed by RC3 - if:
 - The maintainers are fine with it,
 - The risk is minimal to common code paths.

The official test-day is on Thursday (Nov 13th)
but if you want to start testing it today - please do!

Details for the test-day are at

http://wiki.xen.org/wiki/Xen_4.5_RC2_test_instructions

In terms of bugs, we have:

#11 qxl hypervisor support
#13 Re: [Xen-devel] man page example: xm block-attach
#18 xl improve support for migration over non-sshlike tunnels
#19 xl migrate transport improvements
#22 xl does not support specifying virtual function for passthrough device
#23 Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks
#24 xl missing support for encrypted VNC
#27 Re: [Xen-devel] xend vs xl with pci=3D['<bdf'] wherein the '<bdf>' are not owned by pciback or pcistub will still launch.
#28 support PCI hole resize in qemu-xen

[Isn't this fixed by Don's 'mmio_hole' patches=3F]

#30 libxl should implement non-suspend-cancel based resume path
#36 credit2 only uses one runqueue instead of one runq per socket
#38 Implement VT-d large pages so we can avoid sharing between EPT
#40 linux pvops: fpu corruption due to incorrect assumptions
#42 "linux, S3 resume of PVHVM fails - missing call to xen_arch_post_suspend=3F"
#43 "30s delay loading xenfb driver on some systems"
#44 Security policy ambiguities - XSA-108 process post-mortem
#45 arm: domain 0 disables clocks which are in fact being used


=3D Timeline =3D

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:


* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
* RC2: Nov 11th <=3D=3D=3D=3D <WE ARE HERE> (was Nov 12th originally)
* RC2 Test-day: Nov 13th
* RC3: Nov 24th
* RC3 Test-day: Nov 25th
* Release: 10th December 2014

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  The feature freeze may be
slipped for especially important features which are near completion.

Bug-fixes, if Acked-by by maintainer, can go anytime before the First
RC. Later on we will need to figure out the risk of regression/reward
to eliminate the possiblity of a bug introducing another bug.

=3D Prognosis =3D

The states are: none -> fair -> ok -> good -> done

none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok   - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs

=3D Feature freeze exception =3D

Remember our goal for the release:
  1. A bug-free release
  2. An awesome release
  3. An on-time release

Accepting a new feature may make Xen more awesome; but it also
introduces a risk that it will introduce more bugs.  That bug may be
found before the release (threatening #3), or it may not be found
until after the release (threatening #1).  Each freeze exception
request will attempt to balance the benefits (how awesome the
exception is) vs the risks (will it cause the release to slip, or
worse, cause a bug which goes un-noticed into the final release).

The idea is that today we will be pretty permissive, but that we will
become progressively more conservative until the first RC, which was
scheduled for 3 weeks' time (October 25).  After that, we will only
accept bug fixes.

Bug fixes can be checked in without a freeze exception throughout the
code freeze, unless the maintainer thinks they are particularly high
risk.  In later RC's, we may even begin rejecting bug fixes if the
broken functionality is small and the risk to other functionality is
high.

Features which are currently marked "experimental" or do not at the
moment work at all cannot be broken really; so changes to code only
used by those features should be able to get a freeze exception
easily.

Features which change or add new interfaces which will need to be
supported in a backwards-compatible way (for instance, vNUMA) will
need freeze exceptions to make sure that the interface itself has
enough time to be considered stable.

These are guidelines and principles to give you an idea where we're
coming from; if you think there's a good reason why making an
exception for you will help us achieve goals 1-3 above better than not
doing so, feel free to make your case.

=3D Open =3D

=3D=3D Known issues =3D=3D 

*  xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/RAM (good)
   RFC v6
   Treating pieces as bug-fixes only.
  -  Tiejun Chen

=3D=3D Linux =3D=3D 

*  Linux block multiqueue (ok)
   v2 posted.
  -  Arianna Avanzini

*  VPMU - 'perf' support in Linux (ok)
   Depends on Xen patches
   Acked by David Vrabel
  -  Boris Ostrovsky

*  vNUMA in Linux (ok)
   v6 posted
   git://gitorious.org/vnuma/linux_vnuma.git
  -  Elena Ufimtseva

*  vsyscall in Linux (fair)
  -  Konrad Rzeszutek Wilk

*  COLO Agent in Linux (fair)
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  vAPIC in PVHVM guests (Linux side) (none)
  -  Boris Ostrovsky

*  Fix PAT in Linux kernel (aka Full support for PAT) (good)
   Acked and reposted for v3.18. Waiting for x86 maintainers.
   Ingo has been giving advice.
  -  Juergen Gross

=3D=3D FreeBSD =3D=3D 

*  PVH FreeBSD dom0 (ok)
   FreeBSD 11 goal. Toolstack side done in Xen 4.5
  -  Roger Pau Monn=C3=A9

=3D=3D Other OSes (MiniOS, QNX) =3D=3D 

*  PV drivers for automotive kernels (fair)
  -  Artem Mygaiev

*  mini-os: xenbus changes for rump kernels (ok)
   git://xenbits.xen.org/people/iwj/rumpuser-xen.git
   branch: base.dev-xen-xenbus.v1..dev-xen-xenbus.v1
   v2 posted
  -  Ian Jackson

=3D=3D GRUB2 =3D=3D 

*  GRUB2 multiboot2 (fair)
  -  Daniel Kiper

=3D=3D OSSTEST =3D=3D 

*  OSSTest: libvirt (good)
  -  Ian Campbell

=3D=3D Deferred to QEMU v2.next =3D=3D 

*  Using qemu-upstream in a stubdomain (fair)
   Will use rump kernels.
  -  Ian Jackson

*  AMD Radeon PCI GPU passthrough (none)
   Focusing on Xen 4.2 and qemu-traditional
  -  Kelly Zytaruk

*  Intel IGD PCI GPU passthrough (ok)
   v5 posted
  -  Chen, Tiejun

*  Update Xen tree to use upstream OVMF (fair)
  -  Anthony PERARD

=3D=3D Deferred to Xen hypervisor 4.6 =3D=3D 

*  VPMU - 'perf' support in Xen (good)
   v14 posted
   Need reviews/final ack.
  -  Boris Ostrovsky

*  Xen Boot Information (xbi) (ok)
   Dependency for GRUB2 + EFI work
   http://lists.xen.org/archives/html/xen-devel/2014-10/msg02068.html
   v4, No go for full patchset. Only some of the patches.
   No ARM EFI hardware (yet) available to test them.
  -  Daniel Kiper

*  PVH - AMD hardware support. (fair)
   Posted.
  -  Mukesh Rathor

*  VMware backdoor (hypercall) (ok)
   v5 posted.
  -  Don Slutz

*  extending mem_access support to PV domain (fair)
   RFC v2
  -  Aravindh Puthiyaparambil (aravindp)

*  Repurpose SEDF Scheduler for Real-time (fair)
   RFC patch posted (v2)
  -  Joshua Whitehead, Robert VanVossen

*  ARM remote processor iommu module (GPUs + IPUs) (fair)
   v3 posted
  -  Andrii Tseglytskyi

*  dirty vram / IOMMU bug (fair)
   http://bugs.xenproject.org/xen/bug/38
  -  Zhang, Yang Z

*  Xen multiboot2-EFI support (fair)
   Needed for GrUB2
   Depends on Xen Boot info (rework multiboot and other structs)
   See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html
   RFC posted
  -  Daniel Kiper

*  Support controlling the max C-state sub-state (fair)
   v3 posted
   Hadn't see the patch reposted.
  -  Ross Lagerwall

*  IOMMU ABI for guests to map their DMA regions (fair)
  -  Malcolm Crossley

*  Default to credit2 (none)
   cpu pinning, numa affinity and cpu reservation
  -  George Dunlap

*  Convert tasklet to per-cpu tasklets (fair)
   RFC posted
  -  Konrad Rzeszutek Wilk

*  Further tmem cleanups/fixes (16TB etc) (fair)
  -  Bob Liu

*  1TB slow destruction (ok)
  -  Bob Liu

*  ARM VM save/restore/live migration (none)
   Need to rebased against migrationv2 - no code posted.
  -  Junghyun Yoo

*  ARM GICv2m support (none)
  -  Linaro (unknown)

*  ARM - SMMU resync of Linux's one (none)
  -  Julien Grall

*  ARM - passthrough of non-PCI (none)
  -  Julien Grall

*  ARM64 (Cavium Thunder)  PCI passthrough (fair)
  -  Manish Jaggi

=3D=3D Deferred to Xen toolstack 4.6 =3D=3D 

*  vNUMA in Xen toolstack (ok)
   v11 posted
   Hypervisor part in
   git://gitorious.org/vnuma/xen_vnuma.git:v11
  -  Elena Ufimtseva

*  pvscsi in libxl (fair)
  -  Juergen Gross and Olaf

*  COarse-grain LOck-stepping Virtual Machines in Xen (fair)
   RFC v3 posted, based on remus-v19
  -  Wen Congyang
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  extend the xenstore ring with a 'closing' signal (fair)
   RFC patch posted
  -  David Scott

*  New Migration (v2). (good)
   v7 (libxc and libxl)
   git://xenbits.xen.org/people/andrewcoop/xen.git
   Seems that it might need to slip or we run v1 alongside v2.
  -  Andrew Cooper & David Vrabel

*  libxl migrationv2 patches. (none)
  -  Andrew Cooper & David Vrabel

*  tmem migrationv2 patches. (none)
  -  Bob Liu & Andrew Cooper & David Vrabel

*  Remus using migration-v2 (fair)
   RFC posted - depends on v6 of 'New Migration'
  -  Yang Hongyang

*  snapshot API extension (checkpointing disk) (ok)
   v5
   His email bounces.
  -  Bamvor Jian Zhang

*  Rearrange and cleanup installation destination directories (/var -> var/lib/xen) (fair)
  -  Daniel Kiper

*  libxl/xl - xm compatibility mode for mem-max and mem-set; (ok)
  -  Daniel Kiper

*  xl list --long (and some related xl commands) have some bugs (none)
  -  Zhigang Wang

*  Xen HPET interrupt fixes (fair)
   behind migration v2
  -  Andrew Cooper

*  cpuid leveling (none)
   http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-D.pdf
  -  Andrew Cooper

*  live migration knobs, there is no suitable code yet, just ideas (none)
    http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html
  -  Olaf Hering

*  xl does not handle migrate interruption gracefully (none)
   If you start a localhost migrate, and press "Ctrl-C" in the middle, you get two hung domains
  -  Ian Jackson

*  IO-NUMA - hwloc and xl (none)
   Andrew Cooper had an RFC patch for hwloc
   add restrictions  as to which devices cannot safely/functionally be split apart.
  -  Boris Ostrovsky

*  HVM guest NUMA (none)
  -  Matt Wilson

*  PVH - Migration of PVH DomUs. (none)
   Depends on migration2 code
  -  Roger Pau Monn=C3=A9

*  PVH - Migration of guests from a PVH dom0  (none)
   Depends on migration2 code
  -  Roger Pau Monn=C3=A9

=3D=3D Deferred to Linux's after Xen 4.6 =3D=3D 

*  Linux ARM - Device assigment usage in Linux code (arch/arm) non-PCI (none)
   Depends on Xen pieces which are on the Xen 4.6 list.
  -  Julien Grall

*  Linux ARM - Device assigment (PCI) (none)
   Depends on Xen pieces which are on the Xen 4.6 list.
  -  Manish Jaggi

*  pvUSB in Linux (fronted and backend) (Fair)
  -  Juergen Gross

=3D=3D Up for grabs =3D=3D 

*  OSSTest - also test Linux PVH guests

*  PoD fixes
   if you boot with memory <=3D maxmem we have a size estimation bug

*  TLB flushing without locks in Xen

*  xl does not support specifying virtual function for passthrough device
   http://bugs.xenproject.org/xen/bug/22

*  PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with PCI/GPU passthrough
   http://bugs.xenproject.org/xen/bug/28

*  libx{c,l} error handling cleanup 

*  Adding missing 'xend' features in libxl

*  xl list -l on a dom0-only system

*  xl list -l doesn't contain tty console port

*  xl: passing more defaults in configuration in xl.conf
   There are a number of options for which it might be useful to pass a default in xl.conf.  For example, if we could have a default "backend" parameter for vifs, then it would be easy to switch back and forth between a backend in a driver domain and a backend in dom0.

*  PVH - PVH working with shadow.
   Based on Tim's work

*  PVH - PCI passthrough for DomU.

*  AMD performance regressions

*  Performance due to hypercall preemption. More preemptions - slower. (none)

=3D=3D Completed =3D=3D 

=3D=3D Hypervisor =3D=3D 

*  ARM - introduce GNTTABOP_cache_flush (ok)
   v11
  -  Stefano Stabellini

*  ARM - VGIC emulation (done)
   Reposted as gic and vgic fixes and improvements
   v12
  -  Stefano Stabellini

*  ARM implement mem_access (done)
   v12, two patches for Xen 4.6
   https://github.com/tklengyel/xen/tree arm_memaccess_12-for-4.5
  -  Tamas K Lengyel

*  ARM - Add Odroid-XU (Exynos5410) support (done)
   v6
  -  Suriyan Ramasami

*  ARM GICv3 support (done)
   v11 posted
  -  Vijay Kilari

*  ARM implement mem_access (done)
   v12, two patches for Xen 4.6
   https://github.com/tklengyel/xen/tree arm_memaccess_12-for-4.5
  -  Tamas K Lengyel

*  ARM - MiniOS (done)
   v7 posted
  -  Thomas Leonard

*  ARM XEN_DOMCTL_memory_mapping hypercall for ARM (done)
   v12 posted.
  -  Arianna Avanzini

*  ARM - XENFEAT_grant_map_11 (aka map grants refs at pfn =3D mfn) (done)
   Provide kernels an grant->MFN lookup
   v4
  -  Stefano Stabellini

*  ARM PSCI v0.2 (done)
   v11 posted
  -  Parth Dixit

*  ARM  - IOMMU support (done)
  -  Julien Grall

*  ARM Interrupt latency reduction (no maintenance interrupts) (done)
  -  Stefano Stabellini

*  ARM DRA7 support (done)
   v3 posted
   v3 with comments applied
  -  Andrii Tseglytskyi

*  ARM: Use super pages in p2m (done)
   v5 posted
  -  Ian Campbell

*  ARM Xen UEFI booting on ARM (done)
   v5
  -  Roy Franz

*  Cache QoS Monitoring - hypercalls (done)
   Just hypercalls - no toolstack changes.
   v15
   Hit a snag with rdmsr/IPI/wrmsr/IPI, possible redesign
  -  Chao Peng, Dongxiao Xu, and Shantong Kang

*  XenRT (Preemptive Global Earliest Deadline First) (done)
   v3
  -  Meng Xu

*  Introspection of HVM guests (done)
   v10, split out in for 4.5 (smaller subset)
  -  Razvan Cojocaru

*  alternative_asm in Xen (done)
  -  Feng Wu

*  SMAP (done)
  -  Feng Wu

*  Re-write of vHPET (done)
   aka hvm/hpet: Detect comparator values in the past
  -  Don Slutz

*  vAPIC in PVHVM guests (Xen side) (done)
  -  Boris Ostrovsky

*  Xen PVH dom0 (done)
  -  Mukesh Rathor

*  amd_ucode cleanups, verify patch size(enhancement) (mostly in master except one patch)

*  Data breakpoint Extension support (new-feat) (in master)

*  Feature masking MSR support (enhancement) (in master)

*  Support BRCM TruManage chip (Serial over LAN support) (new-feat) (in master)

*  fix vmce_amd* functions, unify mce_amd mcheck initialization (fixes/cleanups)

*  multiple AMD container files appended together in initrd (early initramfs)
  -  Aravind and Suravee

*  NUMA memory scrubbing (done)
  -  Konrad Rzeszutek Wilk

*  ioreq-server, aka secondary emulators (done)
  -  Paul Durrant

*  Soft affinity for vcpus (was NUMA affinity for vcpus) (good)
   v11 posted
  -  Dario Faggioli

*  HT enabled, virtualization overhead is high (Xen 4.4) (done)
   kernbench demonstrated it
   Looking and tracing
   http://www.gossamer-threads.com/lists/xen/devel/339409
   False alarm.
  -  Dario Faggioli

=3D=3D lib{xc,xl} and toolstack =3D=3D 

*  Systemd integration (done)
   Affects CentOS7, SLES12, Fedora Core 21 and Debian Jessie. Xen source contains systemd files that can be used to configure the various run-time services. In the past the distributions would carry their own version of it - but now we host them. This is not yet complete - [[http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg03064.html patches]] for this are being worked on for RC2.
  -  Wei and Olaf

*  Stubdomains build issues (done)
   stubdomains will not build. Fix is in staging (and will make RC2) or [[http://lists.xen.org/archives/html/xen-devel/2014-10/msg02925.html stubdom/Makefile should use QEMU_TRADITIONAL_LOC]]
  -  Michael Young

*  Building against libxl (outside code) (done)
   If you are building against libxl for any APIs before Xen 4.5 you will encounter building errors.
  -  Andrew Cooper

*  Build systems fixes/improvements (done)
  -  Andrew Cooper

*  libxl work - JSON to keep track of guest configs (done)
   Some patches merged, need to post more.
  -  Wei Liu

*  Remus in Xen (libxl) (done)
   v19
   url:  https://github.com/macrosheep/xen/tree/remus-v19
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  libvirt and xl discard support, so that libvirt can start using it (done)
  -  Olaf Hering

*  OSSTest: upstream QEMU (done)
  -  Ian Campbell

*  rework VM Generation ID (done)
   v7 posted
  -  David Vrabel

*  systemd support (done)
   v11
  -  Luis R. Rodriguez

*  Soft affinity for vcpus libxl/xl changes (done)
   v13 posted
  -  Dario Faggioli

=3D=3D QEMU =3D=3D 

*  Bigger PCI hole in QEMU (done)
   Needs to be rebased
  -  Don Slutz

*  QEMU 2.0 branch for qemu-upstream (done)
   It is v2.0 with 2.1 Xen backports.
  -  Stefano Stabellini

*  Xen PV block driver in OVMF (UEFI in guest) (done)
   v3
   In OVMF upstream. Not part of Xen 4.5
  -  Anthony PERARD

=3D=3D Linux 3.18 and earlier =3D=3D 

*  pvSCSI in Linux (fronted and backend) (done)
   v6
  -  Juergen Gross

*  Linux PVH dom0 (done)
  -  Mukesh Rathor

*  Netback multiqueue (good)
  -  Wei Liu

*  Linux pvops of Xen EFI hypercall support (done)
  -  Daniel Kiper

*  "Short" grant copy (just header) of packets. (done)
  -  Zoltan Kiss



--===============4042808384627024036==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4042808384627024036==--

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:39:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoETC-0007Md-PN; Tue, 11 Nov 2014 16:39:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoET5-0007MN-Ci
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 16:38:59 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	C7/B0-22777-2AB32645; Tue, 11 Nov 2014 16:38:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415723936!11814812!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13654 invoked from network); 11 Nov 2014 16:38:58 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 16:38:58 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABGcmqN012972
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 16:38:49 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sABGcmRQ005779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 16:38:48 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABGclFr019083; Tue, 11 Nov 2014 16:38:47 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 08:38:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 245B2113E01; Tue, 11 Nov 2014 11:38:46 -0500 (EST)
Date: Tue, 11 Nov 2014 11:38:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: russell.pavlicek@citrix.com, JBeulich@suse.com, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xenproject.org
Message-ID: <20141111163846.GA14979@laptop.dumpdata.com>
References: <20141110152106.GL3783@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141110152106.GL3783@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] Is: staging open for checkins. Was:Re: Xen 4.5 RC2
 (scheduled on the 12th). Committeers - please read.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 10:21:06AM -0500, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> The 'staging' has four extra patches:
> 
> e6fa63d pvgrub: ignore NUL
> fda1614 xen/arm: Add support for GICv3 for domU
> 5a430ec tools: libxl: do not overrun input buffer in libxl__parse_mac
> 379b351 tools: libxl: do not leak diskpath during local disk attach
.. snip..

All good. staging == master and we have RC2 out today.

Thank you for taking a short break from checking in code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:41:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16: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.xen.org>)
	id 1XoEVv-0007jZ-Fv; Tue, 11 Nov 2014 16:41:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XoEVt-0007jR-Nb
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 16:41:53 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	05/11-09936-15C32645; Tue, 11 Nov 2014 16:41:53 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415724112!11969646!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15794 invoked from network); 11 Nov 2014 16:41:52 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 16:41:52 -0000
Received: by mail-wi0-f170.google.com with SMTP id r20so2357327wiv.1
	for <xen-devel@lists.xenproject.org>;
	Tue, 11 Nov 2014 08:41:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=6zDxIw1bzw0Oh+EcTAT0qKvXteM0zGjFcklnq06oRjI=;
	b=ABsoQdJmk71+I9ecY/uZ/5vw6u9YajWV6f/zD3ZzTNzZCHzUeJCNo0wnXcMiPqj5wP
	a347kqL+DYGfbPbyfgHxuYcaLXHn9n0SY1Q0u2Xy4JJOlDAxPBqBTJ5+Udb/BNt0UBC0
	mxh/retV0a0enIxLR2QC8evmcO/NeLLTR3t81v/7wo1/8nsMx5ZH/K4Wp+h2DU/pqlrp
	F6SMGGhnqn8ZmQDThey5/RPRxYu+akBKLQTECQhhSe8tlTybeHvv1dE3Jn/N08w/+ZcV
	3cB42xmIy0SKp9AmdMg8ogm9RFSU3SA5xf15yHNtVPoVYqlTZF6+1fIF0BcrhUWMOSVc
	SiQg==
X-Gm-Message-State: ALoCoQm99nbNpQgNi3Llc2dHNARnsFeqImRIGH8F9uYE9E3lvJTAf7CXw4JptL876RQymSmtDWM1
X-Received: by 10.180.87.196 with SMTP id ba4mr42817507wib.40.1415724112259;
	Tue, 11 Nov 2014 08:41:52 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.134])
	by mx.google.com with ESMTPSA id
	lm9sm27910214wjc.45.2014.11.11.08.41.51 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 11 Nov 2014 08:41:51 -0800 (PST)
Message-ID: <54623C4E.2000209@linaro.org>
Date: Tue, 11 Nov 2014 17:41:50 +0100
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
	<7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
	<1415613783.27002.2.camel@citrix.com>
	<alpine.DEB.2.02.1411101138020.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411101138020.22875@kaball.uk.xensource.com>
Cc: wei.liu2@citrix.com, vijay.kilari@gmail.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Stefano,

On 10/11/2014 12:38, Stefano Stabellini wrote:
> On Mon, 10 Nov 2014, Ian Campbell wrote:
>> On Sat, 2014-11-08 at 15:26 -0500, Konrad Rzeszutek Wilk wrote:
>>> That is to guard against somebody building against libxc or libxl and
>>> then becoming dependent on this and then complaining that it is not in
>>> Xen 4.6.
>>
>> libxc does not have a stable API and libxl doesn't expose this interface
>> at all. At the hypercall level this is a domctl which simliarly has no
>> stable interface.
>>
>> So I don't think there is any need to wrap anything or guard against
>> anything.
>
> That's true. A comment in the header file wouldn't hurt though.

It looks like that Ian has already pushed the patch. Do I need to send a 
follow-up?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:41:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16: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.xen.org>)
	id 1XoEVv-0007jZ-Fv; Tue, 11 Nov 2014 16:41:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XoEVt-0007jR-Nb
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 16:41:53 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	05/11-09936-15C32645; Tue, 11 Nov 2014 16:41:53 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415724112!11969646!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15794 invoked from network); 11 Nov 2014 16:41:52 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 16:41:52 -0000
Received: by mail-wi0-f170.google.com with SMTP id r20so2357327wiv.1
	for <xen-devel@lists.xenproject.org>;
	Tue, 11 Nov 2014 08:41:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=6zDxIw1bzw0Oh+EcTAT0qKvXteM0zGjFcklnq06oRjI=;
	b=ABsoQdJmk71+I9ecY/uZ/5vw6u9YajWV6f/zD3ZzTNzZCHzUeJCNo0wnXcMiPqj5wP
	a347kqL+DYGfbPbyfgHxuYcaLXHn9n0SY1Q0u2Xy4JJOlDAxPBqBTJ5+Udb/BNt0UBC0
	mxh/retV0a0enIxLR2QC8evmcO/NeLLTR3t81v/7wo1/8nsMx5ZH/K4Wp+h2DU/pqlrp
	F6SMGGhnqn8ZmQDThey5/RPRxYu+akBKLQTECQhhSe8tlTybeHvv1dE3Jn/N08w/+ZcV
	3cB42xmIy0SKp9AmdMg8ogm9RFSU3SA5xf15yHNtVPoVYqlTZF6+1fIF0BcrhUWMOSVc
	SiQg==
X-Gm-Message-State: ALoCoQm99nbNpQgNi3Llc2dHNARnsFeqImRIGH8F9uYE9E3lvJTAf7CXw4JptL876RQymSmtDWM1
X-Received: by 10.180.87.196 with SMTP id ba4mr42817507wib.40.1415724112259;
	Tue, 11 Nov 2014 08:41:52 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.134])
	by mx.google.com with ESMTPSA id
	lm9sm27910214wjc.45.2014.11.11.08.41.51 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 11 Nov 2014 08:41:51 -0800 (PST)
Message-ID: <54623C4E.2000209@linaro.org>
Date: Tue, 11 Nov 2014 17:41:50 +0100
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
	<7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
	<1415613783.27002.2.camel@citrix.com>
	<alpine.DEB.2.02.1411101138020.22875@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411101138020.22875@kaball.uk.xensource.com>
Cc: wei.liu2@citrix.com, vijay.kilari@gmail.com, tim@xen.org,
	Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Stefano,

On 10/11/2014 12:38, Stefano Stabellini wrote:
> On Mon, 10 Nov 2014, Ian Campbell wrote:
>> On Sat, 2014-11-08 at 15:26 -0500, Konrad Rzeszutek Wilk wrote:
>>> That is to guard against somebody building against libxc or libxl and
>>> then becoming dependent on this and then complaining that it is not in
>>> Xen 4.6.
>>
>> libxc does not have a stable API and libxl doesn't expose this interface
>> at all. At the hypercall level this is a domctl which simliarly has no
>> stable interface.
>>
>> So I don't think there is any need to wrap anything or guard against
>> anything.
>
> That's true. A comment in the header file wouldn't hurt though.

It looks like that Ian has already pushed the patch. Do I need to send a 
follow-up?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:42:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16:42:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoEWI-0007mM-SZ; Tue, 11 Nov 2014 16:42:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XoEWG-0007m4-Vd
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 16:42:17 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	8A/5F-25547-86C32645; Tue, 11 Nov 2014 16:42:16 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415724131!9430755!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4553 invoked from network); 11 Nov 2014 16:42:13 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 16:42:13 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABGg6kG017534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 16:42:07 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABGg5gT010403
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 16:42:06 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABGg5Ka001044; Tue, 11 Nov 2014 16:42:05 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 08:42:05 -0800
Message-ID: <54623C5C.6010504@oracle.com>
Date: Tue, 11 Nov 2014 11:42:04 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
In-Reply-To: <20141111152011.GA21312@zion.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/11/2014 10:20 AM, Wei Liu wrote:
> On Tue, Nov 11, 2014 at 09:41:32AM -0500, Zhigang Wang wrote:
>> On 11/11/2014 06:01 AM, Wei Liu wrote:
>>> On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
>>> [...]
>>>> Could you please explain what does "no configuration" means?
>>>>
>>>> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
>>>>
>>>
>>> That means no configuration at all. I think a skeleton can be provided
>>> at best (in xl level) to be consistent with "xl list", which should
>>> include domid and domain name etc. Since nothing else exists in
>>> xenstore yet, there's no point poking there.
>>
>> This approach should works for me.
>>
>>> [...]
>>>> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
>>>>
>>>
>>> Hmm... I don't think poking around in different places is a good idea.
>>> This is prone to breakage in the future.
>>
>> I agree.
>>  
>>> Since xenstore is not filled in when your tool looks at it, what makes
>>> it different to wait a bit until migration finishes?
>>
>> The logic is: when migration started, high level management console will check
>> destination side to make sure the VM is running there 
>> (currently call xl list -l <domain>).
>>
>> If I can get enough runtime info (even some are missing), I think it should be OK.
>>
> 
> What runtime info do you need?

Currently we need:

  info['domid']
  info['config']['b_info']['avail_vcpus']
  info['config']['c_info']['uuid']
  info['config']['b_info']['target_memkb']

Also read vnc port from xenstore.  

We may add more.

But during migration, I believe it's OK if some info is missing. Our high level
management stack will handle it.

Thanks,

Zhigang

> As I understand it's something in the long output -- otherwise you would
> have used the short output already if you only need to check the
> existence and / or state of a domain.
> 
>>> And, from your earlier reply, you're implying Xend fires
>>> @introduceDomain at the same point as xl, but your tool can work with
>>> it?
>>
>> For xm/xend, VM xenstore entries already populated before @introduceDomain.
>> "xm list -l" will show the right information.
>>
>> Anyone knows what prevents us from populating VM xenstore entries during migration in libxl?
>>
> 
> FWIW in libxl @introduceDomain is fired after domain is built, before
> adding devices. If you're after device information, it's a bit late.
> 
> Xend might have done it in different order. I don't know.
> 
> Whether we can change libxl to do so, I'm not sure. But it's definitely
> not 4.5 material.
> 
> Wei.
> 
>> Thanks,
>>
>> Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:42:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16:42:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoEWI-0007mM-SZ; Tue, 11 Nov 2014 16:42:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XoEWG-0007m4-Vd
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 16:42:17 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	8A/5F-25547-86C32645; Tue, 11 Nov 2014 16:42:16 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415724131!9430755!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4553 invoked from network); 11 Nov 2014 16:42:13 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 16:42:13 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABGg6kG017534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 16:42:07 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABGg5gT010403
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 16:42:06 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABGg5Ka001044; Tue, 11 Nov 2014 16:42:05 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 08:42:05 -0800
Message-ID: <54623C5C.6010504@oracle.com>
Date: Tue, 11 Nov 2014 11:42:04 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <20141107104752.GB28188@zion.uk.xensource.com>
	<545CF499.8080606@oracle.com>
	<20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
In-Reply-To: <20141111152011.GA21312@zion.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/11/2014 10:20 AM, Wei Liu wrote:
> On Tue, Nov 11, 2014 at 09:41:32AM -0500, Zhigang Wang wrote:
>> On 11/11/2014 06:01 AM, Wei Liu wrote:
>>> On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
>>> [...]
>>>> Could you please explain what does "no configuration" means?
>>>>
>>>> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
>>>>
>>>
>>> That means no configuration at all. I think a skeleton can be provided
>>> at best (in xl level) to be consistent with "xl list", which should
>>> include domid and domain name etc. Since nothing else exists in
>>> xenstore yet, there's no point poking there.
>>
>> This approach should works for me.
>>
>>> [...]
>>>> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
>>>>
>>>
>>> Hmm... I don't think poking around in different places is a good idea.
>>> This is prone to breakage in the future.
>>
>> I agree.
>>  
>>> Since xenstore is not filled in when your tool looks at it, what makes
>>> it different to wait a bit until migration finishes?
>>
>> The logic is: when migration started, high level management console will check
>> destination side to make sure the VM is running there 
>> (currently call xl list -l <domain>).
>>
>> If I can get enough runtime info (even some are missing), I think it should be OK.
>>
> 
> What runtime info do you need?

Currently we need:

  info['domid']
  info['config']['b_info']['avail_vcpus']
  info['config']['c_info']['uuid']
  info['config']['b_info']['target_memkb']

Also read vnc port from xenstore.  

We may add more.

But during migration, I believe it's OK if some info is missing. Our high level
management stack will handle it.

Thanks,

Zhigang

> As I understand it's something in the long output -- otherwise you would
> have used the short output already if you only need to check the
> existence and / or state of a domain.
> 
>>> And, from your earlier reply, you're implying Xend fires
>>> @introduceDomain at the same point as xl, but your tool can work with
>>> it?
>>
>> For xm/xend, VM xenstore entries already populated before @introduceDomain.
>> "xm list -l" will show the right information.
>>
>> Anyone knows what prevents us from populating VM xenstore entries during migration in libxl?
>>
> 
> FWIW in libxl @introduceDomain is fired after domain is built, before
> adding devices. If you're after device information, it's a bit late.
> 
> Xend might have done it in different order. I don't know.
> 
> Whether we can change libxl to do so, I'm not sure. But it's definitely
> not 4.5 material.
> 
> Wei.
> 
>> Thanks,
>>
>> Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:43:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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.xen.org>)
	id 1XoEXZ-0007xd-Ci; Tue, 11 Nov 2014 16:43:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoEXY-0007xU-Cr
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 16:43:36 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	0D/01-25714-7BC32645; Tue, 11 Nov 2014 16:43:35 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415724208!11819945!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11076 invoked from network); 11 Nov 2014 16:43:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 16:43:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191647545"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 11:43:22 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoEXJ-0007y0-W4;
	Tue, 11 Nov 2014 16:43:21 +0000
Date: Tue, 11 Nov 2014 16:43:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <54623C4E.2000209@linaro.org>
Message-ID: <alpine.DEB.2.02.1411111642551.26318@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
	<7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
	<1415613783.27002.2.camel@citrix.com>
	<alpine.DEB.2.02.1411101138020.22875@kaball.uk.xensource.com>
	<54623C4E.2000209@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	vijay.kilari@gmail.com, tim@xen.org, Vijaya.Kumar@caviumnetworks.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	ian.jackson@eu.citrix.com, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Nov 2014, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/11/2014 12:38, Stefano Stabellini wrote:
> > On Mon, 10 Nov 2014, Ian Campbell wrote:
> > > On Sat, 2014-11-08 at 15:26 -0500, Konrad Rzeszutek Wilk wrote:
> > > > That is to guard against somebody building against libxc or libxl and
> > > > then becoming dependent on this and then complaining that it is not in
> > > > Xen 4.6.
> > > 
> > > libxc does not have a stable API and libxl doesn't expose this interface
> > > at all. At the hypercall level this is a domctl which simliarly has no
> > > stable interface.
> > > 
> > > So I don't think there is any need to wrap anything or guard against
> > > anything.
> > 
> > That's true. A comment in the header file wouldn't hurt though.
> 
> It looks like that Ian has already pushed the patch. Do I need to send a
> follow-up?

No need for just a comment

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:43:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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.xen.org>)
	id 1XoEXZ-0007xd-Ci; Tue, 11 Nov 2014 16:43:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoEXY-0007xU-Cr
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 16:43:36 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	0D/01-25714-7BC32645; Tue, 11 Nov 2014 16:43:35 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415724208!11819945!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11076 invoked from network); 11 Nov 2014 16:43:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 16:43:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191647545"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 11:43:22 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoEXJ-0007y0-W4;
	Tue, 11 Nov 2014 16:43:21 +0000
Date: Tue, 11 Nov 2014 16:43:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <54623C4E.2000209@linaro.org>
Message-ID: <alpine.DEB.2.02.1411111642551.26318@kaball.uk.xensource.com>
References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1411031100100.22875@kaball.uk.xensource.com>
	<CALicx6v0QgedkA3UV9CJkM8jdkV_k-=3LirAC3_vWSAWfc5-fw@mail.gmail.com>
	<20141103163904.GF1638@laptop.dumpdata.com>
	<54590C48.4080100@linaro.org>
	<545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
	<7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
	<1415613783.27002.2.camel@citrix.com>
	<alpine.DEB.2.02.1411101138020.22875@kaball.uk.xensource.com>
	<54623C4E.2000209@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	vijay.kilari@gmail.com, tim@xen.org, Vijaya.Kumar@caviumnetworks.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	ian.jackson@eu.citrix.com, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Nov 2014, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/11/2014 12:38, Stefano Stabellini wrote:
> > On Mon, 10 Nov 2014, Ian Campbell wrote:
> > > On Sat, 2014-11-08 at 15:26 -0500, Konrad Rzeszutek Wilk wrote:
> > > > That is to guard against somebody building against libxc or libxl and
> > > > then becoming dependent on this and then complaining that it is not in
> > > > Xen 4.6.
> > > 
> > > libxc does not have a stable API and libxl doesn't expose this interface
> > > at all. At the hypercall level this is a domctl which simliarly has no
> > > stable interface.
> > > 
> > > So I don't think there is any need to wrap anything or guard against
> > > anything.
> > 
> > That's true. A comment in the header file wouldn't hurt though.
> 
> It looks like that Ian has already pushed the patch. Do I need to send a
> follow-up?

No need for just a comment

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:49:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16:49:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoEd3-0008DE-E9; Tue, 11 Nov 2014 16:49:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>)
	id 1XoEd2-0008Cq-4i; Tue, 11 Nov 2014 16:49:16 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	BC/91-18267-B0E32645; Tue, 11 Nov 2014 16:49:15 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415724554!11917371!1
X-Originating-IP: [209.85.215.50]
X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP,
  SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31188 invoked from network); 11 Nov 2014 16:49:14 -0000
Received: from mail-la0-f50.google.com (HELO mail-la0-f50.google.com)
	(209.85.215.50)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 16:49:14 -0000
Received: by mail-la0-f50.google.com with SMTP id hs14so3610768lab.37
	for <multiple recipients>; Tue, 11 Nov 2014 08:49:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:message-id:subject:from:to:content-type;
	bh=3/ob64fYO835zsD3Ny3mCP9n1D2adwrACwqj9F9AFoY=;
	b=qcAG/+T9NM9OPvNmGqNAdMXBzZTtyPlush2G/YWhdp5XSWGfm/pcCagniPpVAHdXav
	FCwKD0IhvxfepuODPc4jNzymGjHNqJLDv/Slo/oSQMu1rhi5yAuwWkSTslwnQbmAfUfC
	cyTPbJ4VDEXor37fPnPnNvhAA4+FeHdK/9239af2Q0p73RPLRm2vLGTZEaPjVU78NSZd
	lKIcez5R0ddeRQYmlDJuMprav3ydDNa+Yb7P6mD/wjKdRwwRQq+ALm70URgIAJxVZuPF
	2jEDEq9jF6qckiV/egvC8VgZX54nMG5q+XXcSfNgWD9bT9YlpkAyFV5yG9HaYY28PzGx
	seOQ==
MIME-Version: 1.0
X-Received: by 10.152.116.102 with SMTP id jv6mr17293588lab.40.1415724554031; 
	Tue, 11 Nov 2014 08:49:14 -0800 (PST)
Received: by 10.112.225.11 with HTTP; Tue, 11 Nov 2014 08:49:13 -0800 (PST)
Date: Tue, 11 Nov 2014 11:49:13 -0500
X-Google-Sender-Auth: agbyrR8dhEIcJtXpoLv-kNJscso
Message-ID: <CAHehzX0ZS_U95-6TdgS9qz4vxpcSLfeNFmR+EZArkvj0qB35iQ@mail.gmail.com>
From: Russ Pavlicek <russell.pavlicek@xenproject.org>
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel@lists.xen.org, xen-api@lists.xen.org, 
	xen-announce@lists.xenproject.org, xs-devel@lists.xenserver.org, 
	mirageos-devel@lists.xenproject.org
Subject: [Xen-devel] Announcing Xen Project Test Day for 4.5 RC2 on November
	13
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Folks,

This Thursday, November 13, is our second Test Day for the 4.5 release
cycle. Release Candidate 2 is now available for assessment.  Now is
the time to see if the upcoming release of the Xen Project Hypervisor
will work in your environment.

Information about testing this release can be found here:
http://wiki.xenproject.org/wiki/Xen_4.5_RC2_test_instructions

To learn more about Test Days, check out:
http://wiki.xenproject.org/wiki/Xen_Project_Test_Days

See you in #xentest on IRC this Thursday for Test Day!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:49:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16:49:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoEd3-0008DE-E9; Tue, 11 Nov 2014 16:49:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>)
	id 1XoEd2-0008Cq-4i; Tue, 11 Nov 2014 16:49:16 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	BC/91-18267-B0E32645; Tue, 11 Nov 2014 16:49:15 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415724554!11917371!1
X-Originating-IP: [209.85.215.50]
X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP,
  SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31188 invoked from network); 11 Nov 2014 16:49:14 -0000
Received: from mail-la0-f50.google.com (HELO mail-la0-f50.google.com)
	(209.85.215.50)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 16:49:14 -0000
Received: by mail-la0-f50.google.com with SMTP id hs14so3610768lab.37
	for <multiple recipients>; Tue, 11 Nov 2014 08:49:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:message-id:subject:from:to:content-type;
	bh=3/ob64fYO835zsD3Ny3mCP9n1D2adwrACwqj9F9AFoY=;
	b=qcAG/+T9NM9OPvNmGqNAdMXBzZTtyPlush2G/YWhdp5XSWGfm/pcCagniPpVAHdXav
	FCwKD0IhvxfepuODPc4jNzymGjHNqJLDv/Slo/oSQMu1rhi5yAuwWkSTslwnQbmAfUfC
	cyTPbJ4VDEXor37fPnPnNvhAA4+FeHdK/9239af2Q0p73RPLRm2vLGTZEaPjVU78NSZd
	lKIcez5R0ddeRQYmlDJuMprav3ydDNa+Yb7P6mD/wjKdRwwRQq+ALm70URgIAJxVZuPF
	2jEDEq9jF6qckiV/egvC8VgZX54nMG5q+XXcSfNgWD9bT9YlpkAyFV5yG9HaYY28PzGx
	seOQ==
MIME-Version: 1.0
X-Received: by 10.152.116.102 with SMTP id jv6mr17293588lab.40.1415724554031; 
	Tue, 11 Nov 2014 08:49:14 -0800 (PST)
Received: by 10.112.225.11 with HTTP; Tue, 11 Nov 2014 08:49:13 -0800 (PST)
Date: Tue, 11 Nov 2014 11:49:13 -0500
X-Google-Sender-Auth: agbyrR8dhEIcJtXpoLv-kNJscso
Message-ID: <CAHehzX0ZS_U95-6TdgS9qz4vxpcSLfeNFmR+EZArkvj0qB35iQ@mail.gmail.com>
From: Russ Pavlicek <russell.pavlicek@xenproject.org>
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel@lists.xen.org, xen-api@lists.xen.org, 
	xen-announce@lists.xenproject.org, xs-devel@lists.xenserver.org, 
	mirageos-devel@lists.xenproject.org
Subject: [Xen-devel] Announcing Xen Project Test Day for 4.5 RC2 on November
	13
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Folks,

This Thursday, November 13, is our second Test Day for the 4.5 release
cycle. Release Candidate 2 is now available for assessment.  Now is
the time to see if the upcoming release of the Xen Project Hypervisor
will work in your environment.

Information about testing this release can be found here:
http://wiki.xenproject.org/wiki/Xen_4.5_RC2_test_instructions

To learn more about Test Days, check out:
http://wiki.xenproject.org/wiki/Xen_Project_Test_Days

See you in #xentest on IRC this Thursday for Test Day!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:50:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16:50:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoEdu-0008Lc-LH; Tue, 11 Nov 2014 16:50:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XoEds-0008LK-Qa
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 16:50:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4E/80-24532-04E32645; Tue, 11 Nov 2014 16:50:08 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415724607!11981307!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21658 invoked from network); 11 Nov 2014 16:50:07 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 16:50:07 -0000
Received: by mail-wg0-f42.google.com with SMTP id k14so11974860wgh.1
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 08:50:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=Jk3IdSAToHYebBbPd7eR57KyUU1EgeuUyyQDi+F67JE=;
	b=iM9ENRQGRcLmdXXOtz/dyjUcmJujmDg2HMxZJOefwCqeEmpdzeKgHeTyVoLAkOqeT2
	EDf2XFyX5VlnSDkZNr0C50s/qp/NRft4+U8mthQ4i9O8ZKKZfZXdT6F253GeoXXe9I88
	B/vd9/AkR8D3E7+5m0BWOPzbxoCEhcKf51tNMcIz6bBuJXSnXdgI5p6MvCux/CqttLiU
	593LWPNP3Fx0bZOPS9FljX8LFfsFVBvpcX5i7VcSNZ0OWiVNVXtkdibih1P/eSIDrRkx
	/ahjNQ4Sv5iX0gzWNWs0uIs4OASKjDHIPWgiSoadjn568yZtHg8FxDcc886CwcIe7wDx
	m7Ug==
X-Gm-Message-State: ALoCoQkhRkv34MRlerEBx4cPEEne3BP/9dygJP9xIDbeFHoM4KDgnSntIgH/vwI/dC5Vzbc57Gjc
X-Received: by 10.194.250.68 with SMTP id za4mr56662902wjc.92.1415724607322;
	Tue, 11 Nov 2014 08:50:07 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.134])
	by mx.google.com with ESMTPSA id
	d14sm27963938wjz.26.2014.11.11.08.50.06 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 11 Nov 2014 08:50:06 -0800 (PST)
Message-ID: <54623E3D.4060803@linaro.org>
Date: Tue, 11 Nov 2014 17:50:05 +0100
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1414579268.29975.13.camel@citrix.com>	<1414579302-6692-18-git-send-email-ian.campbell@citrix.com>	<21585.6188.366311.80971@mariner.uk.xensource.com>
	<1414672390.2064.31.camel@citrix.com>
In-Reply-To: <1414672390.2064.31.camel@citrix.com>
Cc: xen-devel@lists.xen.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH OSSTEST v2 18/20] Osstest/Debian: Add
 "clk_ignore_unused" to default 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-Transfer-Encoding: 7bit
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,

Somehow I missed this email.

On 30/10/2014 13:33, Ian Campbell wrote:
> create !
> title it arm: domain 0 disables clocks which are in fact being used
> thanks
>
> On Wed, 2014-10-29 at 16:39 +0000, Ian Jackson wrote:
>> Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
>>> This stops dom0 from messing with clocks which it should and is required on
>>> some platforms. It's harmless even when not needed.
>>
>> This is pretty odd.  Doesn't this correspond to some kind of bug, in
>> the dom0 kernel perhaps ?
>
> dom0 is not aware that some clocks are actually in use (e.g. by the
> hypervisor), so the bug is probably in the lack of some interface to
> communicate this from Xen to dom0, or some other mechanism to gate this.

In reality, Xen is only using the clock of the UART. Even though, I 
think this would also happen with platform device passthrough.

For the latter, it would be fairly easy via a PV drivers. But for 
UART... gating the clock could be a nightmare because every platform 
have their own way to enable/disable the clock. Futhermore, the clock 
could be shared with multiple device...

I'm wondering if we could expose the UART to DOM0 without marking as 
disabled. It would avoid DOM0 to mess up the clock while everything 
would be catch via the vuart implementation in Xen.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 16:50:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 16:50:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoEdu-0008Lc-LH; Tue, 11 Nov 2014 16:50:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XoEds-0008LK-Qa
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 16:50:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4E/80-24532-04E32645; Tue, 11 Nov 2014 16:50:08 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415724607!11981307!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21658 invoked from network); 11 Nov 2014 16:50:07 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 16:50:07 -0000
Received: by mail-wg0-f42.google.com with SMTP id k14so11974860wgh.1
	for <xen-devel@lists.xen.org>; Tue, 11 Nov 2014 08:50:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=Jk3IdSAToHYebBbPd7eR57KyUU1EgeuUyyQDi+F67JE=;
	b=iM9ENRQGRcLmdXXOtz/dyjUcmJujmDg2HMxZJOefwCqeEmpdzeKgHeTyVoLAkOqeT2
	EDf2XFyX5VlnSDkZNr0C50s/qp/NRft4+U8mthQ4i9O8ZKKZfZXdT6F253GeoXXe9I88
	B/vd9/AkR8D3E7+5m0BWOPzbxoCEhcKf51tNMcIz6bBuJXSnXdgI5p6MvCux/CqttLiU
	593LWPNP3Fx0bZOPS9FljX8LFfsFVBvpcX5i7VcSNZ0OWiVNVXtkdibih1P/eSIDrRkx
	/ahjNQ4Sv5iX0gzWNWs0uIs4OASKjDHIPWgiSoadjn568yZtHg8FxDcc886CwcIe7wDx
	m7Ug==
X-Gm-Message-State: ALoCoQkhRkv34MRlerEBx4cPEEne3BP/9dygJP9xIDbeFHoM4KDgnSntIgH/vwI/dC5Vzbc57Gjc
X-Received: by 10.194.250.68 with SMTP id za4mr56662902wjc.92.1415724607322;
	Tue, 11 Nov 2014 08:50:07 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.134])
	by mx.google.com with ESMTPSA id
	d14sm27963938wjz.26.2014.11.11.08.50.06 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 11 Nov 2014 08:50:06 -0800 (PST)
Message-ID: <54623E3D.4060803@linaro.org>
Date: Tue, 11 Nov 2014 17:50:05 +0100
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1414579268.29975.13.camel@citrix.com>	<1414579302-6692-18-git-send-email-ian.campbell@citrix.com>	<21585.6188.366311.80971@mariner.uk.xensource.com>
	<1414672390.2064.31.camel@citrix.com>
In-Reply-To: <1414672390.2064.31.camel@citrix.com>
Cc: xen-devel@lists.xen.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH OSSTEST v2 18/20] Osstest/Debian: Add
 "clk_ignore_unused" to default 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-Transfer-Encoding: 7bit
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,

Somehow I missed this email.

On 30/10/2014 13:33, Ian Campbell wrote:
> create !
> title it arm: domain 0 disables clocks which are in fact being used
> thanks
>
> On Wed, 2014-10-29 at 16:39 +0000, Ian Jackson wrote:
>> Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
>>> This stops dom0 from messing with clocks which it should and is required on
>>> some platforms. It's harmless even when not needed.
>>
>> This is pretty odd.  Doesn't this correspond to some kind of bug, in
>> the dom0 kernel perhaps ?
>
> dom0 is not aware that some clocks are actually in use (e.g. by the
> hypervisor), so the bug is probably in the lack of some interface to
> communicate this from Xen to dom0, or some other mechanism to gate this.

In reality, Xen is only using the clock of the UART. Even though, I 
think this would also happen with platform device passthrough.

For the latter, it would be fairly easy via a PV drivers. But for 
UART... gating the clock could be a nightmare because every platform 
have their own way to enable/disable the clock. Futhermore, the clock 
could be shared with multiple device...

I'm wondering if we could expose the UART to DOM0 without marking as 
disabled. It would avoid DOM0 to mess up the clock while everything 
would be catch via the vuart implementation in Xen.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:12:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 17:12:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoEzB-00014J-Pg; Tue, 11 Nov 2014 17:12:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoEzA-00014C-TV
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 17:12:09 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	F7/FD-26858-86342645; Tue, 11 Nov 2014 17:12:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415725926!8151935!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30943 invoked from network); 11 Nov 2014 17:12:07 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 17:12:07 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABHAtUK027027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 17:10:55 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sABHAspa005115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Nov 2014 17:10:54 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sABHAq6t005066; Tue, 11 Nov 2014 17:10:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 09:10:52 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2378B11422E; Tue, 11 Nov 2014 12:10:51 -0500 (EST)
Date: Tue, 11 Nov 2014 12:10:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141111171051.GB15019@laptop.dumpdata.com>
References: <545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
	<7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
	<1415613783.27002.2.camel@citrix.com>
	<alpine.DEB.2.02.1411101138020.22875@kaball.uk.xensource.com>
	<54623C4E.2000209@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54623C4E.2000209@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	vijay.kilari@gmail.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, Vijaya.Kumar@caviumnetworks.com,
	ian.jackson@eu.citrix.com, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 05:41:50PM +0100, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/11/2014 12:38, Stefano Stabellini wrote:
> >On Mon, 10 Nov 2014, Ian Campbell wrote:
> >>On Sat, 2014-11-08 at 15:26 -0500, Konrad Rzeszutek Wilk wrote:
> >>>That is to guard against somebody building against libxc or libxl and
> >>>then becoming dependent on this and then complaining that it is not in
> >>>Xen 4.6.
> >>
> >>libxc does not have a stable API and libxl doesn't expose this interface
> >>at all. At the hypercall level this is a domctl which simliarly has no
> >>stable interface.
> >>
> >>So I don't think there is any need to wrap anything or guard against
> >>anything.
> >
> >That's true. A comment in the header file wouldn't hurt though.
> 
> It looks like that Ian has already pushed the patch. Do I need to send a
> follow-up?

Nah, I just need to put it the Xen 4.6 todo list with your name on it :-)

.. Done.
> 
> Regards,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:12:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 17:12:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoEzB-00014J-Pg; Tue, 11 Nov 2014 17:12:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoEzA-00014C-TV
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 17:12:09 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	F7/FD-26858-86342645; Tue, 11 Nov 2014 17:12:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415725926!8151935!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30943 invoked from network); 11 Nov 2014 17:12:07 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 17:12:07 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABHAtUK027027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 17:10:55 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sABHAspa005115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Nov 2014 17:10:54 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sABHAq6t005066; Tue, 11 Nov 2014 17:10:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 09:10:52 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2378B11422E; Tue, 11 Nov 2014 12:10:51 -0500 (EST)
Date: Tue, 11 Nov 2014 12:10:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141111171051.GB15019@laptop.dumpdata.com>
References: <545A5B4F02000078000C1073@mail.emea.novell.com>
	<545B4325.9000801@linaro.org>
	<545B577D0200007800045407@mail.emea.novell.com>
	<545B4D1D.4090000@linaro.org>
	<20141107154502.GC14076@laptop.dumpdata.com>
	<545E5A66.2000609@linaro.org>
	<7EFC68C5-25FF-47E8-83B3-0600246D8937@oracle.com>
	<1415613783.27002.2.camel@citrix.com>
	<alpine.DEB.2.02.1411101138020.22875@kaball.uk.xensource.com>
	<54623C4E.2000209@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54623C4E.2000209@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	vijay.kilari@gmail.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, Vijaya.Kumar@caviumnetworks.com,
	ian.jackson@eu.citrix.com, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 05:41:50PM +0100, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/11/2014 12:38, Stefano Stabellini wrote:
> >On Mon, 10 Nov 2014, Ian Campbell wrote:
> >>On Sat, 2014-11-08 at 15:26 -0500, Konrad Rzeszutek Wilk wrote:
> >>>That is to guard against somebody building against libxc or libxl and
> >>>then becoming dependent on this and then complaining that it is not in
> >>>Xen 4.6.
> >>
> >>libxc does not have a stable API and libxl doesn't expose this interface
> >>at all. At the hypercall level this is a domctl which simliarly has no
> >>stable interface.
> >>
> >>So I don't think there is any need to wrap anything or guard against
> >>anything.
> >
> >That's true. A comment in the header file wouldn't hurt though.
> 
> It looks like that Ian has already pushed the patch. Do I need to send a
> follow-up?

Nah, I just need to put it the Xen 4.6 todo list with your name on it :-)

.. Done.
> 
> Regards,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:22:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 17:22:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoF9P-0001bQ-0J; Tue, 11 Nov 2014 17:22:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoF9N-0001bJ-IH
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 17:22:41 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D2/A7-02696-0E542645; Tue, 11 Nov 2014 17:22:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415726558!11852909!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6820 invoked from network); 11 Nov 2014 17:22:39 -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;
	11 Nov 2014 17:22:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190223281"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 12:20:04 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoF6p-0005pq-WE;
	Tue, 11 Nov 2014 17:20:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoF6p-0000JW-Qt;
	Tue, 11 Nov 2014 17:20:03 +0000
Date: Tue, 11 Nov 2014 17:20:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31476-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31476: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31476 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31476/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu  5 xen-boot                    fail pass in 31461
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot              fail pass in 31461
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 31461
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31476
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31476
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31476

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31461 never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31461 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:22:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 17:22:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoF9P-0001bQ-0J; Tue, 11 Nov 2014 17:22:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoF9N-0001bJ-IH
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 17:22:41 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D2/A7-02696-0E542645; Tue, 11 Nov 2014 17:22:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415726558!11852909!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6820 invoked from network); 11 Nov 2014 17:22:39 -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;
	11 Nov 2014 17:22:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190223281"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 12:20:04 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoF6p-0005pq-WE;
	Tue, 11 Nov 2014 17:20:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoF6p-0000JW-Qt;
	Tue, 11 Nov 2014 17:20:03 +0000
Date: Tue, 11 Nov 2014 17:20:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31476-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31476: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31476 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31476/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu  5 xen-boot                    fail pass in 31461
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot              fail pass in 31461
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 31461
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31476
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31476
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31476

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31461 never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31461 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:37:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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 1XoFN7-000203-KB; Tue, 11 Nov 2014 17:36:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoFN5-0001zy-I8
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 17:36:51 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	E2/A4-25727-23942645; Tue, 11 Nov 2014 17:36:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415727406!11767188!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13914 invoked from network); 11 Nov 2014 17:36:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 17:36:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190230823"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 12:36:07 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoFMM-0000Tm-RE;
	Tue, 11 Nov 2014 17:36:06 +0000
Date: Tue, 11 Nov 2014 17:36:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141111173606.GC21312@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# What's already implemented?

PV vNUMA support in libxl/xl and Linux kernel.

# What's planned but yet implemented?

NUMA-aware ballooning, HVM vNUMA

# How is vNUMA used in toolstack and Xen?

On libxl level, user (xl and other higher level toolstack) can specify
number of vnodes, size of a vnode, vnode to pnode mapping, vcpu to vnode
mapping, and distances for local and remote node.

Then libxl will generate one or more vmemranges for each node. The
need to generate more than one vmemranges is to accommodate memory
holes. One example is to have e820_host=1 in PV guest config file and
allocate to guest more than 4G RAM.

The generated information will also be stored in Xen. It will be
used in two scenarios: to be retrieved by PV guest; to implement
NUMA-aware ballooning.

# How is vNUMA used in guest?

When PV guest boots up, it issues hypercall to retrieve vNUMA
information. Guest is able to retrieve the number of vnodes, size of
each vnode, vcpu to vnode mapping and finally an array of vmemranges.
Guest can massage these pieces of information for its own use.

HVM guest will still use ACPI to initialise NUMA. ACPI table is
arranged by hvmloader.

# NUMA-aware ballooning

It's agreed that NUMA-aware ballooning should be achieved solely in
hypervisor. Everything should happen under the hood without guest
knowing vnode to pnode mapping.

As far as I can tell, existing guests (Linux and FreeBSD) use
XENMEM_populate_physmap to balloon up. There's a hypercall
called XENMEM_increase_reservation but it's not used
by Linux and FreeBSD.

I can think of two options to implement NUMA-aware ballooning:

1. Modify XENMEM_populate_physmap to take into account vNUMA hint
   when it tries to allocate a page for guest.
2. Introduce a new hypercall dedicated to vNUMA ballooning. Its
   functionality is similar to XENMEM_populate_physmap but it's only
   used in ballooning so that we don't break XENMEM_populate_physmap.

Option #1 requires less modification to guest, because guest won't
need to switch to new hypercall. It's unclear at this point if a guest
asks to populate a gpfn that doesn't belong to any vnode, what Xen
should do about it. Should it be permissive or strict? 

If Xen is strict (say, refuse to populate gpfn that doesn't belong to
a vnode), it imposes difficulty in implementing HVM vNUMA. Hvmloader
may try to populate firmware pages which are in a memory hole, and
memory hole doesn't belong to a node.

Option #2, the question would be should Xen be permissive or strict
on guest that uses vNUMA but doesn't use the new hypercall to balloon
up.

# HVM vNUMA

HVM vNUMA is implemented as followed:

1. Libxl generates vNUMA information and passes it to hvmloader.
2. Hvmloader build SRAT table.

Note that hvmloader is capable of relocating memory. This means
toolstack and guest can have different ideas of the memory layout.

This makes NUMA-aware ballooning for HVM guest tricky to implement,
due to the fact toolstack to hvmloader communication is one way, and
hypervisor shares the same view of guest memory layout as
toolstack. Hvmloader should not be allowed to adjust memory layout;
otherwise Xen will use the wrong hinting information and the end
result is certainly wrong.

To have basic HVM vNUMA support, we should disallow memory relocation
and discourage ballooning if vNUMA is enabled in HVM guest. We also
need to disable populate-on-demand as PoD pool in Xen is not
NUMA-aware.

We then can gradually lift these limits when we deicde what to do
about them.

# Planning

There are many moving parts that don't fit well together. I think a
valid strategy is to impose some limitations on vNUMA and other
features, either by restricting in toolstack or in documentation. Then
lift these limitations in different stages.

First stage:

           Basic     PoD   Ballooning  Mem_relocation
PV/PVH       Y       na       X         na
HVM          Y       X        X         X

Implement basic functionality of vNUMA. That is, to boot a guest
(PV/HVM) with vNUMA support.

Second stage:

           Basic     PoD   Ballooning  Mem_relocation
PV/PVH       Y       na       Y         na
HVM          Y       X        Y         X

Implement NUMA-aware ballooning.

Third stage:

           Basic     PoD   Ballooning  Mem_relocation
PV/PVH       Y       na       Y         na
HVM          Y       Y        Y         X

NUMA-aware PoD?

Fourth stage:

           Basic     PoD   Ballooning  Mem_relocation
PV/PVH       Y       na       Y         na
HVM          Y       Y        Y         Y

Implement bi-direction communication mechanism so that we can
allow memory relocation in hvmloader?

Third stages onward are less concrete at this point.

Thoughts?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:37:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 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 1XoFN7-000203-KB; Tue, 11 Nov 2014 17:36:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoFN5-0001zy-I8
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 17:36:51 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	E2/A4-25727-23942645; Tue, 11 Nov 2014 17:36:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415727406!11767188!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13914 invoked from network); 11 Nov 2014 17:36:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 17:36:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190230823"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 12:36:07 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoFMM-0000Tm-RE;
	Tue, 11 Nov 2014 17:36:06 +0000
Date: Tue, 11 Nov 2014 17:36:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141111173606.GC21312@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# What's already implemented?

PV vNUMA support in libxl/xl and Linux kernel.

# What's planned but yet implemented?

NUMA-aware ballooning, HVM vNUMA

# How is vNUMA used in toolstack and Xen?

On libxl level, user (xl and other higher level toolstack) can specify
number of vnodes, size of a vnode, vnode to pnode mapping, vcpu to vnode
mapping, and distances for local and remote node.

Then libxl will generate one or more vmemranges for each node. The
need to generate more than one vmemranges is to accommodate memory
holes. One example is to have e820_host=1 in PV guest config file and
allocate to guest more than 4G RAM.

The generated information will also be stored in Xen. It will be
used in two scenarios: to be retrieved by PV guest; to implement
NUMA-aware ballooning.

# How is vNUMA used in guest?

When PV guest boots up, it issues hypercall to retrieve vNUMA
information. Guest is able to retrieve the number of vnodes, size of
each vnode, vcpu to vnode mapping and finally an array of vmemranges.
Guest can massage these pieces of information for its own use.

HVM guest will still use ACPI to initialise NUMA. ACPI table is
arranged by hvmloader.

# NUMA-aware ballooning

It's agreed that NUMA-aware ballooning should be achieved solely in
hypervisor. Everything should happen under the hood without guest
knowing vnode to pnode mapping.

As far as I can tell, existing guests (Linux and FreeBSD) use
XENMEM_populate_physmap to balloon up. There's a hypercall
called XENMEM_increase_reservation but it's not used
by Linux and FreeBSD.

I can think of two options to implement NUMA-aware ballooning:

1. Modify XENMEM_populate_physmap to take into account vNUMA hint
   when it tries to allocate a page for guest.
2. Introduce a new hypercall dedicated to vNUMA ballooning. Its
   functionality is similar to XENMEM_populate_physmap but it's only
   used in ballooning so that we don't break XENMEM_populate_physmap.

Option #1 requires less modification to guest, because guest won't
need to switch to new hypercall. It's unclear at this point if a guest
asks to populate a gpfn that doesn't belong to any vnode, what Xen
should do about it. Should it be permissive or strict? 

If Xen is strict (say, refuse to populate gpfn that doesn't belong to
a vnode), it imposes difficulty in implementing HVM vNUMA. Hvmloader
may try to populate firmware pages which are in a memory hole, and
memory hole doesn't belong to a node.

Option #2, the question would be should Xen be permissive or strict
on guest that uses vNUMA but doesn't use the new hypercall to balloon
up.

# HVM vNUMA

HVM vNUMA is implemented as followed:

1. Libxl generates vNUMA information and passes it to hvmloader.
2. Hvmloader build SRAT table.

Note that hvmloader is capable of relocating memory. This means
toolstack and guest can have different ideas of the memory layout.

This makes NUMA-aware ballooning for HVM guest tricky to implement,
due to the fact toolstack to hvmloader communication is one way, and
hypervisor shares the same view of guest memory layout as
toolstack. Hvmloader should not be allowed to adjust memory layout;
otherwise Xen will use the wrong hinting information and the end
result is certainly wrong.

To have basic HVM vNUMA support, we should disallow memory relocation
and discourage ballooning if vNUMA is enabled in HVM guest. We also
need to disable populate-on-demand as PoD pool in Xen is not
NUMA-aware.

We then can gradually lift these limits when we deicde what to do
about them.

# Planning

There are many moving parts that don't fit well together. I think a
valid strategy is to impose some limitations on vNUMA and other
features, either by restricting in toolstack or in documentation. Then
lift these limitations in different stages.

First stage:

           Basic     PoD   Ballooning  Mem_relocation
PV/PVH       Y       na       X         na
HVM          Y       X        X         X

Implement basic functionality of vNUMA. That is, to boot a guest
(PV/HVM) with vNUMA support.

Second stage:

           Basic     PoD   Ballooning  Mem_relocation
PV/PVH       Y       na       Y         na
HVM          Y       X        Y         X

Implement NUMA-aware ballooning.

Third stage:

           Basic     PoD   Ballooning  Mem_relocation
PV/PVH       Y       na       Y         na
HVM          Y       Y        Y         X

NUMA-aware PoD?

Fourth stage:

           Basic     PoD   Ballooning  Mem_relocation
PV/PVH       Y       na       Y         na
HVM          Y       Y        Y         Y

Implement bi-direction communication mechanism so that we can
allow memory relocation in hvmloader?

Third stages onward are less concrete at this point.

Thoughts?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:38:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 17:38:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoFOX-00024r-3p; Tue, 11 Nov 2014 17:38:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoFOW-00024g-BZ
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 17:38:20 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	E4/B1-26740-B8942645; Tue, 11 Nov 2014 17:38:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415727497!7458511!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1524 invoked from network); 11 Nov 2014 17:38:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 17:38:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190231776"
Message-ID: <5462497A.1080806@citrix.com>
Date: Tue, 11 Nov 2014 17:38:02 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-7-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-7-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH V3 6/8] xen: Hide get_phys_to_machine() to
 be able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 05:43, Juergen Gross wrote:
> Today get_phys_to_machine() is always called when the mfn for a pfn
> is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
> to be able to avoid calling get_phys_to_machine() when possible as
> soon as the switch to a linear mapped p2m list has been done.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:38:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 17:38:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoFOX-00024r-3p; Tue, 11 Nov 2014 17:38:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoFOW-00024g-BZ
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 17:38:20 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	E4/B1-26740-B8942645; Tue, 11 Nov 2014 17:38:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415727497!7458511!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1524 invoked from network); 11 Nov 2014 17:38:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 17:38:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190231776"
Message-ID: <5462497A.1080806@citrix.com>
Date: Tue, 11 Nov 2014 17:38:02 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-7-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-7-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH V3 6/8] xen: Hide get_phys_to_machine() to
 be able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 05:43, Juergen Gross wrote:
> Today get_phys_to_machine() is always called when the mfn for a pfn
> is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
> to be able to avoid calling get_phys_to_machine() when possible as
> soon as the switch to a linear mapped p2m list has been done.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:48:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 17:48:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoFXz-0002Sx-E3; Tue, 11 Nov 2014 17:48:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoFXw-0002Sp-AX
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 17:48:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	80/D0-09936-3DB42645; Tue, 11 Nov 2014 17:48:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415728080!11921619!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 767 invoked from network); 11 Nov 2014 17:48: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;
	11 Nov 2014 17:48:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191676575"
Message-ID: <54624BCB.9040300@citrix.com>
Date: Tue, 11 Nov 2014 17:47:55 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-8-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-8-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 05:43, Juergen Gross wrote:
> At start of the day the Xen hypervisor presents a contiguous mfn list
> to a pv-domain. In order to support sparse memory this mfn list is
> accessed via a three level p2m tree built early in the boot process.
> Whenever the system needs the mfn associated with a pfn this tree is
> used to find the mfn.
> 
> Instead of using a software walked tree for accessing a specific mfn
> list entry this patch is creating a virtual address area for the
> entire possible mfn list including memory holes. The holes are
> covered by mapping a pre-defined  page consisting only of "invalid
> mfn" entries. Access to a mfn entry is possible by just using the
> virtual base address of the mfn list and the pfn as index into that
> list. This speeds up the (hot) path of determining the mfn of a
> pfn.
> 
> Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
> showed following improvements:
> 
> Elapsed time: 32:50 ->  32:35
> System:       18:07 ->  17:47
> User:        104:00 -> 103:30
> 
> Tested on 64 bit dom0 and 32 bit domU.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

Can you please test this with the following guests/scenarios.

* 64 bit dom0 with PCI devices with high MMIO BARs.
* 32 bit domU with PCI devices assigned.
* 32 bit domU with 64 GiB of memory.
* domU that starts pre-ballooned and is subsequently ballooned up.
* 64 bit domU that is saved and restored (or local host migration)
* 32 bit domU that is saved and restored (or local host migration)

Thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:48:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 17:48:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoFXz-0002Sx-E3; Tue, 11 Nov 2014 17:48:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoFXw-0002Sp-AX
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 17:48:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	80/D0-09936-3DB42645; Tue, 11 Nov 2014 17:48:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415728080!11921619!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 767 invoked from network); 11 Nov 2014 17:48: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;
	11 Nov 2014 17:48:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191676575"
Message-ID: <54624BCB.9040300@citrix.com>
Date: Tue, 11 Nov 2014 17:47:55 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-8-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-8-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 05:43, Juergen Gross wrote:
> At start of the day the Xen hypervisor presents a contiguous mfn list
> to a pv-domain. In order to support sparse memory this mfn list is
> accessed via a three level p2m tree built early in the boot process.
> Whenever the system needs the mfn associated with a pfn this tree is
> used to find the mfn.
> 
> Instead of using a software walked tree for accessing a specific mfn
> list entry this patch is creating a virtual address area for the
> entire possible mfn list including memory holes. The holes are
> covered by mapping a pre-defined  page consisting only of "invalid
> mfn" entries. Access to a mfn entry is possible by just using the
> virtual base address of the mfn list and the pfn as index into that
> list. This speeds up the (hot) path of determining the mfn of a
> pfn.
> 
> Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
> showed following improvements:
> 
> Elapsed time: 32:50 ->  32:35
> System:       18:07 ->  17:47
> User:        104:00 -> 103:30
> 
> Tested on 64 bit dom0 and 32 bit domU.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

Can you please test this with the following guests/scenarios.

* 64 bit dom0 with PCI devices with high MMIO BARs.
* 32 bit domU with PCI devices assigned.
* 32 bit domU with 64 GiB of memory.
* domU that starts pre-ballooned and is subsequently ballooned up.
* 64 bit domU that is saved and restored (or local host migration)
* 32 bit domU that is saved and restored (or local host migration)

Thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:48:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 17:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoFYj-0002Vy-Rx; Tue, 11 Nov 2014 17:48:53 +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 1XoFYj-0002Vn-9v
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 17:48:53 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	4D/55-14727-40C42645; Tue, 11 Nov 2014 17:48:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415728129!7720140!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31884 invoked from network); 11 Nov 2014 17:48:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 17:48:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190235669"
Message-ID: <54624BFC.6000205@citrix.com>
Date: Tue, 11 Nov 2014 17:48:44 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-9-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-9-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 8/8] xen: Speed up set_phys_to_machine()
 by using read-only mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 05:43, Juergen Gross wrote:
> Instead of checking at each call of set_phys_to_machine() whether a
> new p2m page has to be allocated due to writing an entry in a large
> invalid or identity area, just map those areas read only and react
> to a page fault on write by allocating the new page.
> 
> This change will make the common path with no allocation much
> faster as it only requires a single write of the new mfn instead
> of walking the address translation tables and checking for the
> special cases.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 17:48:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 17:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoFYj-0002Vy-Rx; Tue, 11 Nov 2014 17:48:53 +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 1XoFYj-0002Vn-9v
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 17:48:53 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	4D/55-14727-40C42645; Tue, 11 Nov 2014 17:48:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415728129!7720140!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31884 invoked from network); 11 Nov 2014 17:48:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 17:48:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190235669"
Message-ID: <54624BFC.6000205@citrix.com>
Date: Tue, 11 Nov 2014 17:48:44 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>, 
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-9-git-send-email-jgross@suse.com>
In-Reply-To: <1415684626-18590-9-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 8/8] xen: Speed up set_phys_to_machine()
 by using read-only mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 05:43, Juergen Gross wrote:
> Instead of checking at each call of set_phys_to_machine() whether a
> new p2m page has to be allocated due to writing an entry in a large
> invalid or identity area, just map those areas read only and react
> to a page fault on write by allocating the new page.
> 
> This change will make the common path with no allocation much
> faster as it only requires a single write of the new mfn instead
> of walking the address translation tables and checking for the
> special cases.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 18:03:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 18: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 1XoFn4-0003E9-Ol; Tue, 11 Nov 2014 18:03:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoFn3-0003E4-DU
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 18:03:41 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	FC/DB-23865-C7F42645; Tue, 11 Nov 2014 18:03:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415729017!11771706!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23511 invoked from network); 11 Nov 2014 18:03:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 18:03:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191682295"
Message-ID: <54624F6A.40002@citrix.com>
Date: Tue, 11 Nov 2014 18:03:22 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, <xen-devel@lists.xen.org>
References: <20141111173606.GC21312@zion.uk.xensource.com>
In-Reply-To: <20141111173606.GC21312@zion.uk.xensource.com>
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 17:36, Wei Liu wrote:
> # What's already implemented?
> 
> PV vNUMA support in libxl/xl and Linux kernel.

Linux doesn't have vnuma yet, although the last set of patches I saw
looked fine and were waiting for acks from x86 maintainers I think.

> # NUMA-aware ballooning
> 
> It's agreed that NUMA-aware ballooning should be achieved solely in
> hypervisor. Everything should happen under the hood without guest
> knowing vnode to pnode mapping.
> 
> As far as I can tell, existing guests (Linux and FreeBSD) use
> XENMEM_populate_physmap to balloon up. There's a hypercall
> called XENMEM_increase_reservation but it's not used
> by Linux and FreeBSD.
> 
> I can think of two options to implement NUMA-aware ballooning:
> 
> 1. Modify XENMEM_populate_physmap to take into account vNUMA hint
>    when it tries to allocate a page for guest.
[...]
> Option #1 requires less modification to guest, because guest won't
> need to switch to new hypercall. It's unclear at this point if a guest
> asks to populate a gpfn that doesn't belong to any vnode, what Xen
> should do about it. Should it be permissive or strict? 

There are XENMEMF flags to request exact node or not  -- leave it up to
the balloon driver.  The Linux balloon driver could try exact on all
nodes before falling back to permissive or just always try inexact.

Perhaps a XENMEMF_vnode bit to indicate the node is virtual?

> 
> # HVM vNUMA
> 
> HVM vNUMA is implemented as followed:
> 
> 1. Libxl generates vNUMA information and passes it to hvmloader.
> 2. Hvmloader build SRAT table.
> 
> Note that hvmloader is capable of relocating memory. This means
> toolstack and guest can have different ideas of the memory layout.

Why can't hvmloader update the vnuma tables after it has relocated memory?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 18:03:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 18: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 1XoFn4-0003E9-Ol; Tue, 11 Nov 2014 18:03:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoFn3-0003E4-DU
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 18:03:41 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	FC/DB-23865-C7F42645; Tue, 11 Nov 2014 18:03:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415729017!11771706!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23511 invoked from network); 11 Nov 2014 18:03:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 18:03:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191682295"
Message-ID: <54624F6A.40002@citrix.com>
Date: Tue, 11 Nov 2014 18:03:22 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, <xen-devel@lists.xen.org>
References: <20141111173606.GC21312@zion.uk.xensource.com>
In-Reply-To: <20141111173606.GC21312@zion.uk.xensource.com>
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/14 17:36, Wei Liu wrote:
> # What's already implemented?
> 
> PV vNUMA support in libxl/xl and Linux kernel.

Linux doesn't have vnuma yet, although the last set of patches I saw
looked fine and were waiting for acks from x86 maintainers I think.

> # NUMA-aware ballooning
> 
> It's agreed that NUMA-aware ballooning should be achieved solely in
> hypervisor. Everything should happen under the hood without guest
> knowing vnode to pnode mapping.
> 
> As far as I can tell, existing guests (Linux and FreeBSD) use
> XENMEM_populate_physmap to balloon up. There's a hypercall
> called XENMEM_increase_reservation but it's not used
> by Linux and FreeBSD.
> 
> I can think of two options to implement NUMA-aware ballooning:
> 
> 1. Modify XENMEM_populate_physmap to take into account vNUMA hint
>    when it tries to allocate a page for guest.
[...]
> Option #1 requires less modification to guest, because guest won't
> need to switch to new hypercall. It's unclear at this point if a guest
> asks to populate a gpfn that doesn't belong to any vnode, what Xen
> should do about it. Should it be permissive or strict? 

There are XENMEMF flags to request exact node or not  -- leave it up to
the balloon driver.  The Linux balloon driver could try exact on all
nodes before falling back to permissive or just always try inexact.

Perhaps a XENMEMF_vnode bit to indicate the node is virtual?

> 
> # HVM vNUMA
> 
> HVM vNUMA is implemented as followed:
> 
> 1. Libxl generates vNUMA information and passes it to hvmloader.
> 2. Hvmloader build SRAT table.
> 
> Note that hvmloader is capable of relocating memory. This means
> toolstack and guest can have different ideas of the memory layout.

Why can't hvmloader update the vnuma tables after it has relocated memory?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKK-0005jp-3A; Tue, 11 Nov 2014 19:42:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKH-0005j0-1g
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	C3/2B-05632-C8662645; Tue, 11 Nov 2014 19:42:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415734918!11917886!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10534 invoked from network); 11 Nov 2014 19:42:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:42:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191720028"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0003O6-DM;
	Tue, 11 Nov 2014 19:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0001EZ-61;
	Tue, 11 Nov 2014 19:41:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:49 +0000
Message-ID: <1415734910-4647-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 8/9] ts-hosts-allocate-Executive: Redo
	variation_bonus scoring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use a logarithmic scale.  Cap the bonus at 12h rather than 5d/30 = 4h.
When we have previously failed, make sure we apply a reverse bonus,
rather than a penalty.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 24f78d3..590fe98 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -537,19 +537,25 @@ sub hid_recurse ($$) {
     if ($jobinfo->{recipe} =~ m/build/) {
         $variation_age= 0;
 	$duration_for_cost= $duration + $duration_rightaway_adjust;
-    } elsif ($variation_age > 5*86400) {
-	$variation_age= 5*86400;
     }
 
+    my $log_variation_age = log(1+$variation_age/86400);
+    my $variation_bonus = $log_variation_age * 3600*2;
+    my $max_variation_bonus = 12*86400;
+    $variation_bonus=$max_variation_bonus
+	if $variation_bonus>$max_variation_bonus;
+
     my $cost= $start_time
 	+ $duration_for_cost
         - ($previously_failed      ==@hids ? 366*86400 :
 	   $previously_failed_equiv==@hids ? 365*86400 :
 	   0)
-        + ($previously_failed ? + $variation_age * 10 : - $variation_age / 30)
+        + ($previously_failed || $previously_failed_equiv
+	   ? (-$max_variation_bonus+$variation_bonus) : -$variation_bonus)
 	- $share_reuse * 10000;
     
     print DEBUG "$dbg FINAL start=$start_time va=$variation_age".
+	" variation_bonus=$variation_bonus".
         " previously_failed=$previously_failed".
 	" previously_failed_equiv=$previously_failed_equiv cost=$cost\n";
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKK-0005jz-FR; Tue, 11 Nov 2014 19:42:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKE-0005iv-7f
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	59/87-17694-98662645; Tue, 11 Nov 2014 19:42:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415734918!11917886!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10356 invoked from network); 11 Nov 2014 19:42:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:42:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191719999"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:54 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0003O9-Jw;
	Tue, 11 Nov 2014 19:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0001Ee-Cv;
	Tue, 11 Nov 2014 19:41:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:50 +0000
Message-ID: <1415734910-4647-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 9/9] ts-hosts-allocate-Executive:
	Radically reduce the previously_failed bonus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 osstest less obsessive about sticking to failing hosts if they
are persistently unavailable.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 590fe98..1378f25 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -547,8 +547,12 @@ sub hid_recurse ($$) {
 
     my $cost= $start_time
 	+ $duration_for_cost
-        - ($previously_failed      ==@hids ? 366*86400 :
-	   $previously_failed_equiv==@hids ? 365*86400 :
+        - ($previously_failed      ==@hids ?   7*86400 :
+	   $previously_failed_equiv==@hids ? 6.5*86400 :
+	   # We wait 7d extra to try a failing test on the same
+	   # hardware, or 6.5d on `equivalent' hardware (as defined by
+	   # equiv-* flags).  Compared to `equivalent' hardware, we
+	   # wait 12h to try it on exactly the same.
 	   0)
         + ($previously_failed || $previously_failed_equiv
 	   ? (-$max_variation_bonus+$variation_bonus) : -$variation_bonus)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKK-0005jp-3A; Tue, 11 Nov 2014 19:42:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKH-0005j0-1g
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	C3/2B-05632-C8662645; Tue, 11 Nov 2014 19:42:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415734918!11917886!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10534 invoked from network); 11 Nov 2014 19:42:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:42:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191720028"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0003O6-DM;
	Tue, 11 Nov 2014 19:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0001EZ-61;
	Tue, 11 Nov 2014 19:41:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:49 +0000
Message-ID: <1415734910-4647-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 8/9] ts-hosts-allocate-Executive: Redo
	variation_bonus scoring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use a logarithmic scale.  Cap the bonus at 12h rather than 5d/30 = 4h.
When we have previously failed, make sure we apply a reverse bonus,
rather than a penalty.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 24f78d3..590fe98 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -537,19 +537,25 @@ sub hid_recurse ($$) {
     if ($jobinfo->{recipe} =~ m/build/) {
         $variation_age= 0;
 	$duration_for_cost= $duration + $duration_rightaway_adjust;
-    } elsif ($variation_age > 5*86400) {
-	$variation_age= 5*86400;
     }
 
+    my $log_variation_age = log(1+$variation_age/86400);
+    my $variation_bonus = $log_variation_age * 3600*2;
+    my $max_variation_bonus = 12*86400;
+    $variation_bonus=$max_variation_bonus
+	if $variation_bonus>$max_variation_bonus;
+
     my $cost= $start_time
 	+ $duration_for_cost
         - ($previously_failed      ==@hids ? 366*86400 :
 	   $previously_failed_equiv==@hids ? 365*86400 :
 	   0)
-        + ($previously_failed ? + $variation_age * 10 : - $variation_age / 30)
+        + ($previously_failed || $previously_failed_equiv
+	   ? (-$max_variation_bonus+$variation_bonus) : -$variation_bonus)
 	- $share_reuse * 10000;
     
     print DEBUG "$dbg FINAL start=$start_time va=$variation_age".
+	" variation_bonus=$variation_bonus".
         " previously_failed=$previously_failed".
 	" previously_failed_equiv=$previously_failed_equiv cost=$cost\n";
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKL-0005kD-5z; Tue, 11 Nov 2014 19:42:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKF-0005iy-Bw
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	7D/58-17735-A8662645; Tue, 11 Nov 2014 19:42:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415734918!11917886!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10468 invoked from network); 11 Nov 2014 19:42:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:42:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191720025"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0003O0-02;
	Tue, 11 Nov 2014 19:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0001EP-PW;
	Tue, 11 Nov 2014 19:41:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:47 +0000
Message-ID: <1415734910-4647-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 6/9] ts-hosts-allocate-Executive:
	Clarify an expression with //
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 change.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index fc54cda..9562a0a 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -464,8 +464,7 @@ sub hid_recurse ($$) {
 	    !defined($duration) ||
 	    defined($cand->{Duration}) && $cand->{Duration} >= $duration;
         $previously_failed++ if
-	    defined $cand->{MostRecentStatus} &&
-	    $cand->{MostRecentStatus} eq 'fail';
+	    ($cand->{MostRecentStatus} // '') eq 'fail';
     }
     my $duration_rightaway_adjust= 0;
     
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKL-0005kD-5z; Tue, 11 Nov 2014 19:42:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKF-0005iy-Bw
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	7D/58-17735-A8662645; Tue, 11 Nov 2014 19:42:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415734918!11917886!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10468 invoked from network); 11 Nov 2014 19:42:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:42:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191720025"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0003O0-02;
	Tue, 11 Nov 2014 19:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0001EP-PW;
	Tue, 11 Nov 2014 19:41:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:47 +0000
Message-ID: <1415734910-4647-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 6/9] ts-hosts-allocate-Executive:
	Clarify an expression with //
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 change.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index fc54cda..9562a0a 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -464,8 +464,7 @@ sub hid_recurse ($$) {
 	    !defined($duration) ||
 	    defined($cand->{Duration}) && $cand->{Duration} >= $duration;
         $previously_failed++ if
-	    defined $cand->{MostRecentStatus} &&
-	    $cand->{MostRecentStatus} eq 'fail';
+	    ($cand->{MostRecentStatus} // '') eq 'fail';
     }
     my $duration_rightaway_adjust= 0;
     
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKM-0005kq-9v; Tue, 11 Nov 2014 19:42:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKG-0005iz-8h
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	B3/7D-18267-B8662645; Tue, 11 Nov 2014 19:42:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415734918!11917886!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10502 invoked from network); 11 Nov 2014 19:42:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:42:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191720026"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0003O3-6V;
	Tue, 11 Nov 2014 19:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0001EU-Vi;
	Tue, 11 Nov 2014 19:41:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:48 +0000
Message-ID: <1415734910-4647-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 7/9] ts-hosts-allocate-Executive: Score
	for equivalent previous failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Look to see whether the last run on any hosts which are equivalent to
the ones we're looking at, failed.  This means that when host X is
failing and we are considering host Y which is equivalent to X, we
give Y a selection bonus.

This means that osstest will be less obsessive about sticking to the
very same failing host.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |   45 +++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 43 insertions(+), 2 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 9562a0a..24f78d3 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -284,6 +284,29 @@ END
         $findhostsq->execute("blessed-$fi->{intended}");
     }
 
+    my $equivstatusq= $dbh_tests->prepare(<<END);
+            SELECT flight, job, val, status
+	      FROM flights f
+	      JOIN jobs j USING (flight)
+	      JOIN runvars r USING (flight,job)
+             WHERE j.job=?
+               AND f.blessing=?
+	       AND f.branch=?
+               AND r.name=?
+	       AND r.val IN (
+		   SELECT hostname
+		     FROM hostflags
+		    WHERE hostflag IN (
+			  SELECT hostflag
+			    FROM hostflags
+			   WHERE hostname=?
+			     AND hostflag LIKE 'equiv-%'
+		       )
+		   )
+	  ORDER BY f.started DESC
+	     LIMIT 1;
+END
+
     my @candidates;
     my $any=0;
 
@@ -342,6 +365,17 @@ END
 
         find_recent_duration($dbg,$hid,$candrow);
 
+	if ($candrow->{restype} eq 'host') {
+	    $equivstatusq->execute($job,$fi->{intended},$fi->{branch},
+				   $hid->{Ident},$candrow->{resname});
+	    my $esrow = $equivstatusq->fetchrow_hashref();
+	    $candrow->{EquivMostRecentStatus} = $esrow->{status};
+	    print DEBUG "$dbg EQUIV-MOST-RECENT ";
+	    print DEBUG ("$esrow->{flight}.$esrow->{job}".
+			 " $esrow->{val} $esrow->{status}") if $esrow;
+	    print DEBUG ".\n";
+	}
+
         foreach my $kcomb (qw(Shared-Max-Wear Shared-Max-Tasks)) {
             my $kdb= $kcomb;  $kdb =~ y/-A-Z/ a-z/;
             my $khash= $kcomb;  $khash =~ y/-//d;
@@ -362,6 +396,7 @@ END
 	print DEBUG "$dbg CANDIDATE.\n";
     }
     $findhostsq->finish();
+    $equivstatusq->finish();
 
     if (!@candidates) {
         if (defined $use) {
@@ -455,6 +490,7 @@ sub hid_recurse ($$) {
     my $variation_age= 0;
     my $duration= undef;
     my $previously_failed = 0;
+    my $previously_failed_equiv = 0;
     foreach my $hid (@hids) {
 	my $cand= $hid->{Selected};
 	my $recentstarted= $cand->{MostRecentStarted};
@@ -465,6 +501,8 @@ sub hid_recurse ($$) {
 	    defined($cand->{Duration}) && $cand->{Duration} >= $duration;
         $previously_failed++ if
 	    ($cand->{MostRecentStatus} // '') eq 'fail';
+	$previously_failed_equiv++ if
+	    ($cand->{EquivMostRecentStatus} // '') eq 'fail';
     }
     my $duration_rightaway_adjust= 0;
     
@@ -505,12 +543,15 @@ sub hid_recurse ($$) {
 
     my $cost= $start_time
 	+ $duration_for_cost
-        - $previously_failed * 366*86400
+        - ($previously_failed      ==@hids ? 366*86400 :
+	   $previously_failed_equiv==@hids ? 365*86400 :
+	   0)
         + ($previously_failed ? + $variation_age * 10 : - $variation_age / 30)
 	- $share_reuse * 10000;
     
     print DEBUG "$dbg FINAL start=$start_time va=$variation_age".
-        " previously_failed=$previously_failed cost=$cost\n";
+        " previously_failed=$previously_failed".
+	" previously_failed_equiv=$previously_failed_equiv cost=$cost\n";
 
     if (!defined $best || $cost < $best->{Cost}) {
         print DEBUG "$dbg FINAL BEST: ".
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKK-0005jz-FR; Tue, 11 Nov 2014 19:42:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKE-0005iv-7f
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	59/87-17694-98662645; Tue, 11 Nov 2014 19:42:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415734918!11917886!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10356 invoked from network); 11 Nov 2014 19:42:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:42:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191719999"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:54 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0003O9-Jw;
	Tue, 11 Nov 2014 19:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0001Ee-Cv;
	Tue, 11 Nov 2014 19:41:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:50 +0000
Message-ID: <1415734910-4647-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 9/9] ts-hosts-allocate-Executive:
	Radically reduce the previously_failed bonus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 osstest less obsessive about sticking to failing hosts if they
are persistently unavailable.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 590fe98..1378f25 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -547,8 +547,12 @@ sub hid_recurse ($$) {
 
     my $cost= $start_time
 	+ $duration_for_cost
-        - ($previously_failed      ==@hids ? 366*86400 :
-	   $previously_failed_equiv==@hids ? 365*86400 :
+        - ($previously_failed      ==@hids ?   7*86400 :
+	   $previously_failed_equiv==@hids ? 6.5*86400 :
+	   # We wait 7d extra to try a failing test on the same
+	   # hardware, or 6.5d on `equivalent' hardware (as defined by
+	   # equiv-* flags).  Compared to `equivalent' hardware, we
+	   # wait 12h to try it on exactly the same.
 	   0)
         + ($previously_failed || $previously_failed_equiv
 	   ? (-$max_variation_bonus+$variation_bonus) : -$variation_bonus)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKL-0005kR-SS; Tue, 11 Nov 2014 19:42:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKD-0005iq-Hk
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:01 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	E9/5D-02953-88662645; Tue, 11 Nov 2014 19:42:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415734916!11890203!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14393 invoked from network); 11 Nov 2014 19:42:00 -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;
	11 Nov 2014 19:42:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190280467"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:58 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK4-0003Nl-Sx;
	Tue, 11 Nov 2014 19:41:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK4-0001E0-Ko;
	Tue, 11 Nov 2014 19:41:52 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:42 +0000
Message-ID: <1415734910-4647-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 1/9] cs-adjust-flight: Fix doc about
	/<pcre> to match implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 cs-adjust-flight |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cs-adjust-flight b/cs-adjust-flight
index 663ca6f..7ec17e3 100755
--- a/cs-adjust-flight
+++ b/cs-adjust-flight
@@ -18,7 +18,7 @@
 #   <foo-name>
 #   .                 means all jobs
 #   ^<pcre>           means $foo =~ m/^<pcre>/
-#   /<pcre>/          means $foo =~ m/<pcre>/
+#   /<pcre>           means $foo =~ m/<pcre>/
 
 # This is part of "osstest", an automated testing framework for Xen.
 # Copyright (C) 2009-2013 Citrix Inc.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKK-0005k6-QS; Tue, 11 Nov 2014 19:42:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKE-0005ix-Te
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	C8/A5-07724-A8662645; Tue, 11 Nov 2014 19:42:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415734918!11917886!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10403 invoked from network); 11 Nov 2014 19:42:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:42:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191720023"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0003Nx-Py;
	Tue, 11 Nov 2014 19:41:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0001EK-JO;
	Tue, 11 Nov 2014 19:41:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:46 +0000
Message-ID: <1415734910-4647-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 5/9] ts-hosts-allocate-Executive: Do not
	prefer fast hosts for 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

Introduce $duration_for_cost and set it to the previous formula for
build jobs, or 0 for test jobs.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 67b8891..fc54cda 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -496,15 +496,16 @@ sub hid_recurse ($$) {
 
     $duration_rightaway_adjust=0 if $start_time;
 
+    my $duration_for_cost = 0;
     if ($jobinfo->{recipe} =~ m/build/) {
         $variation_age= 0;
+	$duration_for_cost= $duration + $duration_rightaway_adjust;
     } elsif ($variation_age > 5*86400) {
 	$variation_age= 5*86400;
     }
 
     my $cost= $start_time
-	+ $duration
-	+ $duration_rightaway_adjust
+	+ $duration_for_cost
         - $previously_failed * 366*86400
         + ($previously_failed ? + $variation_age * 10 : - $variation_age / 30)
 	- $share_reuse * 10000;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKD-0005ir-Aa; Tue, 11 Nov 2014 19:42:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKC-0005ig-AG
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:00 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	1B/4B-02559-78662645; Tue, 11 Nov 2014 19:41:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415734916!11890203!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14012 invoked from network); 11 Nov 2014 19:41:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:41:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190280450"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:52 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK4-0003Ni-LK;
	Tue, 11 Nov 2014 19:41:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK4-0001Dx-DI;
	Tue, 11 Nov 2014 19:41:52 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:41 +0000
Message-ID: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 0/9] Host allocation scoring 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

Here, I'm trying to fix the way that osstest gets far too obsessed
about particular failing hosts.

 1/9 cs-adjust-flight: Fix doc about /<pcre> to match
 2/9 ts-hosts-allocate-Executive: allow uncompressed
 3/9 Osstest/Executive.pm: Debug log same-host status
 4/9 ts-hosts-allocate-Executive: Move $variation_age
 5/9 ts-hosts-allocate-Executive: Do not prefer fast
 6/9 ts-hosts-allocate-Executive: Clarify an
 7/9 ts-hosts-allocate-Executive: Score for
 8/9 ts-hosts-allocate-Executive: Redo
 9/9 ts-hosts-allocate-Executive: Radically reduce


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKJ-0005ji-Nj; Tue, 11 Nov 2014 19:42:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKE-0005iw-PU
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	7B/BA-02712-A8662645; Tue, 11 Nov 2014 19:42:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415734916!11890203!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14429 invoked from network); 11 Nov 2014 19:42:01 -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;
	11 Nov 2014 19:42:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190280473"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:58 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0003Nu-Jm;
	Tue, 11 Nov 2014 19:41:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0001EF-DF;
	Tue, 11 Nov 2014 19:41:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:45 +0000
Message-ID: <1415734910-4647-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 4/9] ts-hosts-allocate-Executive: Move
	$variation_age setting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are going to want to put more stuff in here which depends on
$duration_rightaway_adjust.

No functional change in this commit.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 73c1a45..67b8891 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -478,12 +478,6 @@ sub hid_recurse ($$) {
 
     print DEBUG "$dbg EVAL DURATION $duration va=$variation_age\n";
 
-    if ($jobinfo->{recipe} =~ m/build/) {
-        $variation_age= 0;
-    } elsif ($variation_age > 5*86400) {
-	$variation_age= 5*86400;
-    }	
-
     my @requestlist;
     foreach my $hid (@hids) {
         my $req= {
@@ -502,6 +496,12 @@ sub hid_recurse ($$) {
 
     $duration_rightaway_adjust=0 if $start_time;
 
+    if ($jobinfo->{recipe} =~ m/build/) {
+        $variation_age= 0;
+    } elsif ($variation_age > 5*86400) {
+	$variation_age= 5*86400;
+    }
+
     my $cost= $start_time
 	+ $duration
 	+ $duration_rightaway_adjust
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKL-0005kR-SS; Tue, 11 Nov 2014 19:42:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKD-0005iq-Hk
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:01 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	E9/5D-02953-88662645; Tue, 11 Nov 2014 19:42:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415734916!11890203!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14393 invoked from network); 11 Nov 2014 19:42:00 -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;
	11 Nov 2014 19:42:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190280467"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:58 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK4-0003Nl-Sx;
	Tue, 11 Nov 2014 19:41:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK4-0001E0-Ko;
	Tue, 11 Nov 2014 19:41:52 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:42 +0000
Message-ID: <1415734910-4647-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 1/9] cs-adjust-flight: Fix doc about
	/<pcre> to match implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 cs-adjust-flight |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cs-adjust-flight b/cs-adjust-flight
index 663ca6f..7ec17e3 100755
--- a/cs-adjust-flight
+++ b/cs-adjust-flight
@@ -18,7 +18,7 @@
 #   <foo-name>
 #   .                 means all jobs
 #   ^<pcre>           means $foo =~ m/^<pcre>/
-#   /<pcre>/          means $foo =~ m/<pcre>/
+#   /<pcre>           means $foo =~ m/<pcre>/
 
 # This is part of "osstest", an automated testing framework for Xen.
 # Copyright (C) 2009-2013 Citrix Inc.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKM-0005kq-9v; Tue, 11 Nov 2014 19:42:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKG-0005iz-8h
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	B3/7D-18267-B8662645; Tue, 11 Nov 2014 19:42:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415734918!11917886!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10502 invoked from network); 11 Nov 2014 19:42:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:42:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191720026"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK6-0003O3-6V;
	Tue, 11 Nov 2014 19:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0001EU-Vi;
	Tue, 11 Nov 2014 19:41:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:48 +0000
Message-ID: <1415734910-4647-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 7/9] ts-hosts-allocate-Executive: Score
	for equivalent previous failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Look to see whether the last run on any hosts which are equivalent to
the ones we're looking at, failed.  This means that when host X is
failing and we are considering host Y which is equivalent to X, we
give Y a selection bonus.

This means that osstest will be less obsessive about sticking to the
very same failing host.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |   45 +++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 43 insertions(+), 2 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 9562a0a..24f78d3 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -284,6 +284,29 @@ END
         $findhostsq->execute("blessed-$fi->{intended}");
     }
 
+    my $equivstatusq= $dbh_tests->prepare(<<END);
+            SELECT flight, job, val, status
+	      FROM flights f
+	      JOIN jobs j USING (flight)
+	      JOIN runvars r USING (flight,job)
+             WHERE j.job=?
+               AND f.blessing=?
+	       AND f.branch=?
+               AND r.name=?
+	       AND r.val IN (
+		   SELECT hostname
+		     FROM hostflags
+		    WHERE hostflag IN (
+			  SELECT hostflag
+			    FROM hostflags
+			   WHERE hostname=?
+			     AND hostflag LIKE 'equiv-%'
+		       )
+		   )
+	  ORDER BY f.started DESC
+	     LIMIT 1;
+END
+
     my @candidates;
     my $any=0;
 
@@ -342,6 +365,17 @@ END
 
         find_recent_duration($dbg,$hid,$candrow);
 
+	if ($candrow->{restype} eq 'host') {
+	    $equivstatusq->execute($job,$fi->{intended},$fi->{branch},
+				   $hid->{Ident},$candrow->{resname});
+	    my $esrow = $equivstatusq->fetchrow_hashref();
+	    $candrow->{EquivMostRecentStatus} = $esrow->{status};
+	    print DEBUG "$dbg EQUIV-MOST-RECENT ";
+	    print DEBUG ("$esrow->{flight}.$esrow->{job}".
+			 " $esrow->{val} $esrow->{status}") if $esrow;
+	    print DEBUG ".\n";
+	}
+
         foreach my $kcomb (qw(Shared-Max-Wear Shared-Max-Tasks)) {
             my $kdb= $kcomb;  $kdb =~ y/-A-Z/ a-z/;
             my $khash= $kcomb;  $khash =~ y/-//d;
@@ -362,6 +396,7 @@ END
 	print DEBUG "$dbg CANDIDATE.\n";
     }
     $findhostsq->finish();
+    $equivstatusq->finish();
 
     if (!@candidates) {
         if (defined $use) {
@@ -455,6 +490,7 @@ sub hid_recurse ($$) {
     my $variation_age= 0;
     my $duration= undef;
     my $previously_failed = 0;
+    my $previously_failed_equiv = 0;
     foreach my $hid (@hids) {
 	my $cand= $hid->{Selected};
 	my $recentstarted= $cand->{MostRecentStarted};
@@ -465,6 +501,8 @@ sub hid_recurse ($$) {
 	    defined($cand->{Duration}) && $cand->{Duration} >= $duration;
         $previously_failed++ if
 	    ($cand->{MostRecentStatus} // '') eq 'fail';
+	$previously_failed_equiv++ if
+	    ($cand->{EquivMostRecentStatus} // '') eq 'fail';
     }
     my $duration_rightaway_adjust= 0;
     
@@ -505,12 +543,15 @@ sub hid_recurse ($$) {
 
     my $cost= $start_time
 	+ $duration_for_cost
-        - $previously_failed * 366*86400
+        - ($previously_failed      ==@hids ? 366*86400 :
+	   $previously_failed_equiv==@hids ? 365*86400 :
+	   0)
         + ($previously_failed ? + $variation_age * 10 : - $variation_age / 30)
 	- $share_reuse * 10000;
     
     print DEBUG "$dbg FINAL start=$start_time va=$variation_age".
-        " previously_failed=$previously_failed cost=$cost\n";
+        " previously_failed=$previously_failed".
+	" previously_failed_equiv=$previously_failed_equiv cost=$cost\n";
 
     if (!defined $best || $cost < $best->{Cost}) {
         print DEBUG "$dbg FINAL BEST: ".
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKI-0005jb-Bl; Tue, 11 Nov 2014 19:42:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKC-0005ih-Of
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:00 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	96/DE-02698-88662645; Tue, 11 Nov 2014 19:42:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415734916!11890203!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14346 invoked from network); 11 Nov 2014 19: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;
	11 Nov 2014 19:41:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190280451"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:53 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0003Nr-Da;
	Tue, 11 Nov 2014 19:41:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0001EA-6T;
	Tue, 11 Nov 2014 19:41:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:44 +0000
Message-ID: <1415734910-4647-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 3/9] Osstest/Executive.pm: Debug log
	same-host status (in duration estimator)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
 Osstest/Executive.pm |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 2a3cc7c..3dc37d1 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -733,7 +733,8 @@ END
             my ($duration) = $duration_duration_q->fetchrow_array();
             $duration_duration_q->finish();
             if ($duration) {
-                $dbg->("REF $ref->{flight} DURATION $duration");
+                $dbg->("REF $ref->{flight} DURATION $duration ".
+		       ($ref->{status} // ''));
                 $duration_max= $duration
                     if $duration > $duration_max;
             }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKL-0005kK-H1; Tue, 11 Nov 2014 19:42:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKE-0005iu-4f
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	5A/10-02576-98662645; Tue, 11 Nov 2014 19:42:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415734916!11890203!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14406 invoked from network); 11 Nov 2014 19:42:00 -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;
	11 Nov 2014 19:42:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190280470"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:58 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0003No-6s;
	Tue, 11 Nov 2014 19:41:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK4-0001E5-SN;
	Tue, 11 Nov 2014 19:41:52 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:43 +0000
Message-ID: <1415734910-4647-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 2/9] ts-hosts-allocate-Executive: allow
	uncompressed log
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |   20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 0e9c193..73c1a45 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -29,12 +29,14 @@ tsreadconfig();
 
 open DEBUG, ">/dev/null" or die $!;
 
+our $compressdebug=1;
+
 while (@ARGV and $ARGV[0] =~ m/^-/) {
     $_= shift @ARGV;
     last if m/^--$/;
     while (m/^-./) {
-        if (0) {
-	    # no options
+        if (s/^-U/-/) {
+	    $compressdebug=0;
         } else {
             die "$_ ?";
         }
@@ -60,12 +62,16 @@ sub setup () {
 
     $taskid= findtask();
 
-    my $logbase = "hosts-allocate.debug.gz";
+    my $logbase = "hosts-allocate.debug".($compressdebug?".gz":"");
     my $logfh = open_unique_stashfile \$logbase;
-    my $logchild = open DEBUG, "|-";  defined $logchild or die $!;
-    if (!$logchild) {
-	open STDOUT, ">&", $logfh or die $!;
-	exec "gzip" or die $!;
+    if ($compressdebug) {
+	my $logchild = open DEBUG, "|-";  defined $logchild or die $!;
+	if (!$logchild) {
+	    open STDOUT, ">&", $logfh or die $!;
+	    exec "gzip" or die $!;
+	}
+    } else {
+	open DEBUG, ">&", $logfh or die $!;
     }
     DEBUG->autoflush(1);
     logm("host allocation debug log in $logbase");
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKK-0005k6-QS; Tue, 11 Nov 2014 19:42:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKE-0005ix-Te
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	C8/A5-07724-A8662645; Tue, 11 Nov 2014 19:42:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415734918!11917886!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10403 invoked from network); 11 Nov 2014 19:42:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:42:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191720023"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0003Nx-Py;
	Tue, 11 Nov 2014 19:41:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0001EK-JO;
	Tue, 11 Nov 2014 19:41:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:46 +0000
Message-ID: <1415734910-4647-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 5/9] ts-hosts-allocate-Executive: Do not
	prefer fast hosts for 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

Introduce $duration_for_cost and set it to the previous formula for
build jobs, or 0 for test jobs.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 67b8891..fc54cda 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -496,15 +496,16 @@ sub hid_recurse ($$) {
 
     $duration_rightaway_adjust=0 if $start_time;
 
+    my $duration_for_cost = 0;
     if ($jobinfo->{recipe} =~ m/build/) {
         $variation_age= 0;
+	$duration_for_cost= $duration + $duration_rightaway_adjust;
     } elsif ($variation_age > 5*86400) {
 	$variation_age= 5*86400;
     }
 
     my $cost= $start_time
-	+ $duration
-	+ $duration_rightaway_adjust
+	+ $duration_for_cost
         - $previously_failed * 366*86400
         + ($previously_failed ? + $variation_age * 10 : - $variation_age / 30)
 	- $share_reuse * 10000;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKD-0005ir-Aa; Tue, 11 Nov 2014 19:42:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKC-0005ig-AG
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:00 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	1B/4B-02559-78662645; Tue, 11 Nov 2014 19:41:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415734916!11890203!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14012 invoked from network); 11 Nov 2014 19:41:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 19:41:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190280450"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:52 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK4-0003Ni-LK;
	Tue, 11 Nov 2014 19:41:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK4-0001Dx-DI;
	Tue, 11 Nov 2014 19:41:52 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:41 +0000
Message-ID: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 0/9] Host allocation scoring 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

Here, I'm trying to fix the way that osstest gets far too obsessed
about particular failing hosts.

 1/9 cs-adjust-flight: Fix doc about /<pcre> to match
 2/9 ts-hosts-allocate-Executive: allow uncompressed
 3/9 Osstest/Executive.pm: Debug log same-host status
 4/9 ts-hosts-allocate-Executive: Move $variation_age
 5/9 ts-hosts-allocate-Executive: Do not prefer fast
 6/9 ts-hosts-allocate-Executive: Clarify an
 7/9 ts-hosts-allocate-Executive: Score for
 8/9 ts-hosts-allocate-Executive: Redo
 9/9 ts-hosts-allocate-Executive: Radically reduce


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKJ-0005ji-Nj; Tue, 11 Nov 2014 19:42:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKE-0005iw-PU
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	7B/BA-02712-A8662645; Tue, 11 Nov 2014 19:42:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415734916!11890203!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14429 invoked from network); 11 Nov 2014 19:42:01 -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;
	11 Nov 2014 19:42:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190280473"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:58 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0003Nu-Jm;
	Tue, 11 Nov 2014 19:41:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0001EF-DF;
	Tue, 11 Nov 2014 19:41:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:45 +0000
Message-ID: <1415734910-4647-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 4/9] ts-hosts-allocate-Executive: Move
	$variation_age setting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are going to want to put more stuff in here which depends on
$duration_rightaway_adjust.

No functional change in this commit.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 73c1a45..67b8891 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -478,12 +478,6 @@ sub hid_recurse ($$) {
 
     print DEBUG "$dbg EVAL DURATION $duration va=$variation_age\n";
 
-    if ($jobinfo->{recipe} =~ m/build/) {
-        $variation_age= 0;
-    } elsif ($variation_age > 5*86400) {
-	$variation_age= 5*86400;
-    }	
-
     my @requestlist;
     foreach my $hid (@hids) {
         my $req= {
@@ -502,6 +496,12 @@ sub hid_recurse ($$) {
 
     $duration_rightaway_adjust=0 if $start_time;
 
+    if ($jobinfo->{recipe} =~ m/build/) {
+        $variation_age= 0;
+    } elsif ($variation_age > 5*86400) {
+	$variation_age= 5*86400;
+    }
+
     my $cost= $start_time
 	+ $duration
 	+ $duration_rightaway_adjust
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKI-0005jb-Bl; Tue, 11 Nov 2014 19:42:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKC-0005ih-Of
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:00 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	96/DE-02698-88662645; Tue, 11 Nov 2014 19:42:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415734916!11890203!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14346 invoked from network); 11 Nov 2014 19: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;
	11 Nov 2014 19:41:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190280451"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:53 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0003Nr-Da;
	Tue, 11 Nov 2014 19:41:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0001EA-6T;
	Tue, 11 Nov 2014 19:41:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:44 +0000
Message-ID: <1415734910-4647-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 3/9] Osstest/Executive.pm: Debug log
	same-host status (in duration estimator)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
 Osstest/Executive.pm |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 2a3cc7c..3dc37d1 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -733,7 +733,8 @@ END
             my ($duration) = $duration_duration_q->fetchrow_array();
             $duration_duration_q->finish();
             if ($duration) {
-                $dbg->("REF $ref->{flight} DURATION $duration");
+                $dbg->("REF $ref->{flight} DURATION $duration ".
+		       ($ref->{status} // ''));
                 $duration_max= $duration
                     if $duration > $duration_max;
             }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 19:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 19:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHKL-0005kK-H1; Tue, 11 Nov 2014 19:42:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoHKE-0005iu-4f
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 19:42:05 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	5A/10-02576-98662645; Tue, 11 Nov 2014 19:42:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415734916!11890203!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14406 invoked from network); 11 Nov 2014 19:42:00 -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;
	11 Nov 2014 19:42:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190280470"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 11 Nov 2014 14:41:58 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoHK5-0003No-6s;
	Tue, 11 Nov 2014 19:41:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoHK4-0001E5-SN;
	Tue, 11 Nov 2014 19:41:52 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 11 Nov 2014 19:41:43 +0000
Message-ID: <1415734910-4647-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 2/9] ts-hosts-allocate-Executive: allow
	uncompressed log
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-hosts-allocate-Executive |   20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 0e9c193..73c1a45 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -29,12 +29,14 @@ tsreadconfig();
 
 open DEBUG, ">/dev/null" or die $!;
 
+our $compressdebug=1;
+
 while (@ARGV and $ARGV[0] =~ m/^-/) {
     $_= shift @ARGV;
     last if m/^--$/;
     while (m/^-./) {
-        if (0) {
-	    # no options
+        if (s/^-U/-/) {
+	    $compressdebug=0;
         } else {
             die "$_ ?";
         }
@@ -60,12 +62,16 @@ sub setup () {
 
     $taskid= findtask();
 
-    my $logbase = "hosts-allocate.debug.gz";
+    my $logbase = "hosts-allocate.debug".($compressdebug?".gz":"");
     my $logfh = open_unique_stashfile \$logbase;
-    my $logchild = open DEBUG, "|-";  defined $logchild or die $!;
-    if (!$logchild) {
-	open STDOUT, ">&", $logfh or die $!;
-	exec "gzip" or die $!;
+    if ($compressdebug) {
+	my $logchild = open DEBUG, "|-";  defined $logchild or die $!;
+	if (!$logchild) {
+	    open STDOUT, ">&", $logfh or die $!;
+	    exec "gzip" or die $!;
+	}
+    } else {
+	open DEBUG, ">&", $logfh or die $!;
     }
     DEBUG->autoflush(1);
     logm("host allocation debug log in $logbase");
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 20:24:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 20:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHzT-0007jz-Uv; Tue, 11 Nov 2014 20:24:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1XoHzS-0007ju-Bb
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 20:24:38 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	43/F3-02712-58072645; Tue, 11 Nov 2014 20:24:37 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415737475!11863061!1
X-Originating-IP: [209.85.223.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16597 invoked from network); 11 Nov 2014 20:24:36 -0000
Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com)
	(209.85.223.170)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 20:24:36 -0000
Received: by mail-ie0-f170.google.com with SMTP id tp5so12366866ieb.1
	for <xen-devel@lists.xenproject.org>;
	Tue, 11 Nov 2014 12:24:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=r+67+OU62rqqNuXmduBAwTfE1Fw3Hz0y1brAZi1sxH4=;
	b=K/ssJrrLYwZRXrb17T7JlKEwvH5gcetx7Xz42hK5HA+3vbmbdoEGlloP5EyI6v/VFD
	gfWIcXqrS0+EE/Ph4ZYBYM+XJLWBW0F4K75SXUt/13cxDFrugkRgyXX4B4RsbPdQJB57
	R++Ek7jZLdhrfChvgDT5IteBDhfgY7s4lJ2c73NyP+62IKcTQh2Mdrwji879NaDcj6Ym
	UjEpeQzJ7UZx5oWC+6GvDhH0OlvXUnKwEK2k82SM8Wwzd25jEi0xvv/Od/v3XqEbPoci
	jmW3dOOlF3f6zrHEVuSOT9gGli22/b8GQgac0M7RB0kWK9txqep3rD9MdUjF+mRTW+r3
	TfVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=r+67+OU62rqqNuXmduBAwTfE1Fw3Hz0y1brAZi1sxH4=;
	b=Ul6TaoR4yMY4oGhq0Mvm9icw3dKO3sq9GHu/thkPtPYkj3k+Hgvv4JLPHPuyuFerlh
	AKZFQ9ARrPUPbXCWbLxbLr+9ug3IyOxfb5vYiDhHIKgecisDVm6i8uV9cRi+/zMz3w5a
	KNlvN3YbQQoEOf2FAOUjy1h12wuI2cP4wA9jQd33iNuzMAYGMGopy03BdRojj1cFtdYw
	ccv+2qD+nqcIPjnpyhCnB/PKDZ31pklkRoIA4N/B0K0+xKDZahM/NRYO95tLjQLNdRZc
	kKjjxgsyz9eL92XIAxOuR8vtXT7OM3N3CvXhlpuIC24PRq1fMqgjk7jzOv32ARCncaPd
	C8Fw==
X-Gm-Message-State: ALoCoQlW6jFMs+mxmKftoTo4NfLf0WkmGm9s6D2tw+X0PJa3nDgi5ogT/g9buCl/wBfQbn65vfia
X-Received: by 10.50.30.132 with SMTP id s4mr34674027igh.24.1415737475080;
	Tue, 11 Nov 2014 12:24:35 -0800 (PST)
Received: from google.com ([172.26.48.152])
	by mx.google.com with ESMTPSA id v84sm7321925ioe.41.2014.11.11.12.24.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 12:24:34 -0800 (PST)
Date: Tue, 11 Nov 2014 13:24:30 -0700
From: Bjorn Helgaas <bhelgaas@google.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141111202430.GH28161@google.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<1414377878-23497-2-git-send-email-wangyijing@huawei.com>
	<20141111000456.GB21470@google.com>
	<20141111154538.GC6597@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141111154538.GC6597@laptop.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Yijing Wang <wangyijing@huawei.com>, linux-pci@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix
 the MSI mask bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 10:45:38AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 10, 2014 at 05:04:56PM -0700, Bjorn Helgaas wrote:
> > On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
> > > Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> > > fixed MSI mask bug which may cause kernel crash. But the commit
> > > made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask"
> > > to ignore MSI/MSI-X to fix this issue, it's a cleaner solution.
> > > And the commit 0e4ccb1505a9 will be reverted in the later patch.
> > 
> > The 0e4ccb1505a9 changelog says Xen guests can't write to MSI-X BARs.
> > But it makes mask_irq a no-op for both MSI-X and MSI.  The MSI mask bit is
> > in config space, not in memory space.  So why does mask_irq need to be a
> > no-op for MSI as well?  Are Xen guests prohibited from writing to config
> 
> The PV guests it refers do not do write to config space. They have
> an PCI frontend and backend driver which communicates to the backend (the
> trusted domain) to setup the MSI and MSI-X. The 'pci_xen_init' (arch/x86/pci/xen.c)
> is the one that sets up the overrides. When an MSI or MSI-X is requested
> it is done via the request_irq which ends up calling 'xen_setup_msi_irqs'.
> If you look there you can see:
> 
> 173         if (type == PCI_CAP_ID_MSIX)
> 174                 ret = xen_pci_frontend_enable_msix(dev, v, nvec);
> 175         else
> 176                 ret = xen_pci_frontend_enable_msi(dev, v);
> 177         if (ret)
> 178                 goto error;
> 
> Which are the calls to the Xen PCI driver to communicate with the
> backend to setup the MSI.
> 
> > space, too?  (It's fine if they are; it's just that the changelog
> > specifically mentioned MSI-X memory space tables, and it didn't mention
> > config space at all.)
> 
> Correct. The config space is accessible to the guest but if it writes
> to it - all of those values are ignored by the hypervisor - and that
> is because the backend is suppose to communicate to the hypervisor
> whether the guest can indeed setup MSI or MSI-X.
> 
> > 
> > And I *assume* there's some Xen mechanism that accomplishes the mask_irq in
> > a different way, since the actual mask_irq interface does nothing?  (This
> > is really a question for 0e4ccb1505a9, since I don't think this particular
> > patch changes anything in that respect.)
> 
> Correct. 'request_irq' ends up doing that. Or rather it ends up
> calling xen_setup_msi_irqs which takes care of that.
> 
> The Xen PV guests (not to be confused with Xen HVM guests) run without
> any emulated devices. That means most of the x86 platform things - ioports,
> VGA, etc - are removed. Instead that functionality is provided via 
> frontend drivers that communicate to the backend via a ring.
> 
> Hopefully this clarifies it?

I think so.  I propose the following changelog.  Let me know if it's still
inaccurate:

  PCI/MSI: Add pci_msi_ignore_mask to prevent MSI/MSI-X BAR writes

  MSI-X vector Mask Bits are in MSI-X Tables in PCI memory space.  Xen guests
  can't write to those tables.  MSI vector Mask Bits are in PCI configuration
  space.  Xen guests can write to config space, but those writes are ignored.

  Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and
  msix_mask_irq()") added a way to override default_mask_msi_irqs() and
  default_mask_msix_irqs() so they can be no-ops in Xen guests, but this is
  more complicated than necessary.

  Add "pci_msi_ignore_mask" in the core PCI MSI code.  If set,
  default_mask_msi_irqs() and default_mask_msix_irqs() return without doing
  anything.  This is less flexible, but much simpler.

I guess you mentioned PV and HVM guests, and it sounds like all this only
applies to HVM guests.

Bjorn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 20:24:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 20:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoHzT-0007jz-Uv; Tue, 11 Nov 2014 20:24:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1XoHzS-0007ju-Bb
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 20:24:38 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	43/F3-02712-58072645; Tue, 11 Nov 2014 20:24:37 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415737475!11863061!1
X-Originating-IP: [209.85.223.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16597 invoked from network); 11 Nov 2014 20:24:36 -0000
Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com)
	(209.85.223.170)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 20:24:36 -0000
Received: by mail-ie0-f170.google.com with SMTP id tp5so12366866ieb.1
	for <xen-devel@lists.xenproject.org>;
	Tue, 11 Nov 2014 12:24:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=r+67+OU62rqqNuXmduBAwTfE1Fw3Hz0y1brAZi1sxH4=;
	b=K/ssJrrLYwZRXrb17T7JlKEwvH5gcetx7Xz42hK5HA+3vbmbdoEGlloP5EyI6v/VFD
	gfWIcXqrS0+EE/Ph4ZYBYM+XJLWBW0F4K75SXUt/13cxDFrugkRgyXX4B4RsbPdQJB57
	R++Ek7jZLdhrfChvgDT5IteBDhfgY7s4lJ2c73NyP+62IKcTQh2Mdrwji879NaDcj6Ym
	UjEpeQzJ7UZx5oWC+6GvDhH0OlvXUnKwEK2k82SM8Wwzd25jEi0xvv/Od/v3XqEbPoci
	jmW3dOOlF3f6zrHEVuSOT9gGli22/b8GQgac0M7RB0kWK9txqep3rD9MdUjF+mRTW+r3
	TfVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=r+67+OU62rqqNuXmduBAwTfE1Fw3Hz0y1brAZi1sxH4=;
	b=Ul6TaoR4yMY4oGhq0Mvm9icw3dKO3sq9GHu/thkPtPYkj3k+Hgvv4JLPHPuyuFerlh
	AKZFQ9ARrPUPbXCWbLxbLr+9ug3IyOxfb5vYiDhHIKgecisDVm6i8uV9cRi+/zMz3w5a
	KNlvN3YbQQoEOf2FAOUjy1h12wuI2cP4wA9jQd33iNuzMAYGMGopy03BdRojj1cFtdYw
	ccv+2qD+nqcIPjnpyhCnB/PKDZ31pklkRoIA4N/B0K0+xKDZahM/NRYO95tLjQLNdRZc
	kKjjxgsyz9eL92XIAxOuR8vtXT7OM3N3CvXhlpuIC24PRq1fMqgjk7jzOv32ARCncaPd
	C8Fw==
X-Gm-Message-State: ALoCoQlW6jFMs+mxmKftoTo4NfLf0WkmGm9s6D2tw+X0PJa3nDgi5ogT/g9buCl/wBfQbn65vfia
X-Received: by 10.50.30.132 with SMTP id s4mr34674027igh.24.1415737475080;
	Tue, 11 Nov 2014 12:24:35 -0800 (PST)
Received: from google.com ([172.26.48.152])
	by mx.google.com with ESMTPSA id v84sm7321925ioe.41.2014.11.11.12.24.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 12:24:34 -0800 (PST)
Date: Tue, 11 Nov 2014 13:24:30 -0700
From: Bjorn Helgaas <bhelgaas@google.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141111202430.GH28161@google.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<1414377878-23497-2-git-send-email-wangyijing@huawei.com>
	<20141111000456.GB21470@google.com>
	<20141111154538.GC6597@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141111154538.GC6597@laptop.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Yijing Wang <wangyijing@huawei.com>, linux-pci@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix
 the MSI mask bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 10:45:38AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 10, 2014 at 05:04:56PM -0700, Bjorn Helgaas wrote:
> > On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
> > > Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> > > fixed MSI mask bug which may cause kernel crash. But the commit
> > > made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask"
> > > to ignore MSI/MSI-X to fix this issue, it's a cleaner solution.
> > > And the commit 0e4ccb1505a9 will be reverted in the later patch.
> > 
> > The 0e4ccb1505a9 changelog says Xen guests can't write to MSI-X BARs.
> > But it makes mask_irq a no-op for both MSI-X and MSI.  The MSI mask bit is
> > in config space, not in memory space.  So why does mask_irq need to be a
> > no-op for MSI as well?  Are Xen guests prohibited from writing to config
> 
> The PV guests it refers do not do write to config space. They have
> an PCI frontend and backend driver which communicates to the backend (the
> trusted domain) to setup the MSI and MSI-X. The 'pci_xen_init' (arch/x86/pci/xen.c)
> is the one that sets up the overrides. When an MSI or MSI-X is requested
> it is done via the request_irq which ends up calling 'xen_setup_msi_irqs'.
> If you look there you can see:
> 
> 173         if (type == PCI_CAP_ID_MSIX)
> 174                 ret = xen_pci_frontend_enable_msix(dev, v, nvec);
> 175         else
> 176                 ret = xen_pci_frontend_enable_msi(dev, v);
> 177         if (ret)
> 178                 goto error;
> 
> Which are the calls to the Xen PCI driver to communicate with the
> backend to setup the MSI.
> 
> > space, too?  (It's fine if they are; it's just that the changelog
> > specifically mentioned MSI-X memory space tables, and it didn't mention
> > config space at all.)
> 
> Correct. The config space is accessible to the guest but if it writes
> to it - all of those values are ignored by the hypervisor - and that
> is because the backend is suppose to communicate to the hypervisor
> whether the guest can indeed setup MSI or MSI-X.
> 
> > 
> > And I *assume* there's some Xen mechanism that accomplishes the mask_irq in
> > a different way, since the actual mask_irq interface does nothing?  (This
> > is really a question for 0e4ccb1505a9, since I don't think this particular
> > patch changes anything in that respect.)
> 
> Correct. 'request_irq' ends up doing that. Or rather it ends up
> calling xen_setup_msi_irqs which takes care of that.
> 
> The Xen PV guests (not to be confused with Xen HVM guests) run without
> any emulated devices. That means most of the x86 platform things - ioports,
> VGA, etc - are removed. Instead that functionality is provided via 
> frontend drivers that communicate to the backend via a ring.
> 
> Hopefully this clarifies it?

I think so.  I propose the following changelog.  Let me know if it's still
inaccurate:

  PCI/MSI: Add pci_msi_ignore_mask to prevent MSI/MSI-X BAR writes

  MSI-X vector Mask Bits are in MSI-X Tables in PCI memory space.  Xen guests
  can't write to those tables.  MSI vector Mask Bits are in PCI configuration
  space.  Xen guests can write to config space, but those writes are ignored.

  Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and
  msix_mask_irq()") added a way to override default_mask_msi_irqs() and
  default_mask_msix_irqs() so they can be no-ops in Xen guests, but this is
  more complicated than necessary.

  Add "pci_msi_ignore_mask" in the core PCI MSI code.  If set,
  default_mask_msi_irqs() and default_mask_msix_irqs() return without doing
  anything.  This is less flexible, but much simpler.

I guess you mentioned PV and HVM guests, and it sounds like all this only
applies to HVM guests.

Bjorn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 20:30:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 20:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoI4i-0007sT-OH; Tue, 11 Nov 2014 20:30:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XoI4e-0007sO-JF
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 20:30:00 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	03/C2-17958-7C172645; Tue, 11 Nov 2014 20:29:59 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415737798!8180528!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11395 invoked from network); 11 Nov 2014 20:29:59 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 20:29:59 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sABKSj8n018959;
	Tue, 11 Nov 2014 20:28:49 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sABKSeS3008598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Nov 2014 20:28:40 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sABKSeVK024810;
	Tue, 11 Nov 2014 20:28:40 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sABKScmN024806; Tue, 11 Nov 2014 20:28:38 GMT
Date: Tue, 11 Nov 2014 20:28:38 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; boundary="8323329-246335390-1415733708=:25402"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sABKSj8n018959
Cc: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] fix commit xen/arm: Add support for GICv3 for
	domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-246335390-1415733708=:25402
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

The build of xen-4.5.0-rc2 fails if XSM_ENABLE=y due to an inconsistency 
in commit fda1614 "xen/arm: Add support for GICv3 for domU" which uses 
XEN_DOMCTL_configure_domain in xen/xsm/flask/hooks.c and 
xen/xsm/flask/policy/access_vectors but XEN_DOMCTL_arm_configure_domain 
elsewhere.

 	Michael Young
--8323329-246335390-1415733708=:25402
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xen.flask.arm.fix.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xen.flask.arm.fix.patch

SW4gZmRhMTYxNCAoInhlbi9hcm06IEFkZCBzdXBwb3J0IGZvciBHSUN2MyBmb3IgZG9tVSIpDQpY
RU5fRE9NQ1RMX2NvbmZpZ3VyZV9kb21haW4gaXMgdXNlZCBpbiB4ZW4veHNtL2ZsYXNrL2hvb2tz
LmMgYW5kDQp4ZW4veHNtL2ZsYXNrL3BvbGljeS9hY2Nlc3NfdmVjdG9ycyBidXQgWEVOX0RPTUNU
TF9hcm1fY29uZmlndXJlX2RvbWFpbg0KaXMgdXNlZCBlbHNld2hlcmUuDQoNClNpZ25lZC1vZmYt
Ynk6IE1pY2hhZWwgWW91bmcgPG0uYS55b3VuZ0BkdXJoYW0uYWMudWs+DQoNCi0tLSB4ZW4tNC41
LjAtcmMyL3hlbi94c20vZmxhc2svaG9va3MuYy5vcmlnCTIwMTQtMTEtMTEgMTQ6NDA6MjAuMDAw
MDAwMDAwICswMDAwDQorKysgeGVuLTQuNS4wLXJjMi94ZW4veHNtL2ZsYXNrL2hvb2tzLmMJMjAx
NC0xMS0xMSAxODo0Njo1Mi45MjYyMDI5MTkgKzAwMDANCkBAIC03MjcsNyArNzI3LDcgQEANCiAg
ICAgY2FzZSBYRU5fRE9NQ1RMX3Bzcl9jbXRfb3A6DQogICAgICAgICByZXR1cm4gY3VycmVudF9o
YXNfcGVybShkLCBTRUNDTEFTU19ET01BSU4yLCBET01BSU4yX19QU1JfQ01UX09QKTsNCiANCi0g
ICAgY2FzZSBYRU5fRE9NQ1RMX2NvbmZpZ3VyZV9kb21haW46DQorICAgIGNhc2UgWEVOX0RPTUNU
TF9hcm1fY29uZmlndXJlX2RvbWFpbjoNCiAgICAgICAgIHJldHVybiBjdXJyZW50X2hhc19wZXJt
KGQsIFNFQ0NMQVNTX0RPTUFJTjIsIERPTUFJTjJfX0NPTkZJR1VSRV9ET01BSU4pOw0KIA0KICAg
ICBkZWZhdWx0Og0KLS0tIHhlbi00LjUuMC1yYzIveGVuL3hzbS9mbGFzay9wb2xpY3kvYWNjZXNz
X3ZlY3RvcnMub3JpZwkyMDE0LTExLTExIDE0OjQwOjIwLjAwMDAwMDAwMCArMDAwMA0KKysrIHhl
bi00LjUuMC1yYzIveGVuL3hzbS9mbGFzay9wb2xpY3kvYWNjZXNzX3ZlY3RvcnMJMjAxNC0xMS0x
MSAxOToyMDo0MS4wNTgxNzUzMDIgKzAwMDANCkBAIC0xMDIsNyArMTAyLDcgQEANCiAgICAgdW5w
YXVzZQ0KICMgWEVOX0RPTUNUTF9yZXN1bWVkb21haW4NCiAgICAgcmVzdW1lDQotIyBYRU5fRE9N
Q1RMX2NyZWF0ZWRvbWFpbg0KKyMgWEVOX0RPTUNUTF9hcm1fY3JlYXRlZG9tYWluDQogICAgIGNy
ZWF0ZQ0KICMgY2hlY2tlZCBpbiBGTEFTS19SRUxBQkVMX0RPTUFJTiBmb3IgYW55IHJlbGFiZWwg
b3BlcmF0aW9uOg0KICMgIHNvdXJjZSA9IHRoZSBvbGQgbGFiZWwgb2YgdGhlIGRvbWFpbg0K

--8323329-246335390-1415733708=:25402
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-246335390-1415733708=:25402--


From xen-devel-bounces@lists.xen.org Tue Nov 11 20:30:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 20:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoI4i-0007sT-OH; Tue, 11 Nov 2014 20:30:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XoI4e-0007sO-JF
	for xen-devel@lists.xen.org; Tue, 11 Nov 2014 20:30:00 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	03/C2-17958-7C172645; Tue, 11 Nov 2014 20:29:59 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415737798!8180528!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11395 invoked from network); 11 Nov 2014 20:29:59 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 20:29:59 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sABKSj8n018959;
	Tue, 11 Nov 2014 20:28:49 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sABKSeS3008598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Nov 2014 20:28:40 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sABKSeVK024810;
	Tue, 11 Nov 2014 20:28:40 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sABKScmN024806; Tue, 11 Nov 2014 20:28:38 GMT
Date: Tue, 11 Nov 2014 20:28:38 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; boundary="8323329-246335390-1415733708=:25402"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sABKSj8n018959
Cc: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] fix commit xen/arm: Add support for GICv3 for
	domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-246335390-1415733708=:25402
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

The build of xen-4.5.0-rc2 fails if XSM_ENABLE=y due to an inconsistency 
in commit fda1614 "xen/arm: Add support for GICv3 for domU" which uses 
XEN_DOMCTL_configure_domain in xen/xsm/flask/hooks.c and 
xen/xsm/flask/policy/access_vectors but XEN_DOMCTL_arm_configure_domain 
elsewhere.

 	Michael Young
--8323329-246335390-1415733708=:25402
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xen.flask.arm.fix.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xen.flask.arm.fix.patch

SW4gZmRhMTYxNCAoInhlbi9hcm06IEFkZCBzdXBwb3J0IGZvciBHSUN2MyBmb3IgZG9tVSIpDQpY
RU5fRE9NQ1RMX2NvbmZpZ3VyZV9kb21haW4gaXMgdXNlZCBpbiB4ZW4veHNtL2ZsYXNrL2hvb2tz
LmMgYW5kDQp4ZW4veHNtL2ZsYXNrL3BvbGljeS9hY2Nlc3NfdmVjdG9ycyBidXQgWEVOX0RPTUNU
TF9hcm1fY29uZmlndXJlX2RvbWFpbg0KaXMgdXNlZCBlbHNld2hlcmUuDQoNClNpZ25lZC1vZmYt
Ynk6IE1pY2hhZWwgWW91bmcgPG0uYS55b3VuZ0BkdXJoYW0uYWMudWs+DQoNCi0tLSB4ZW4tNC41
LjAtcmMyL3hlbi94c20vZmxhc2svaG9va3MuYy5vcmlnCTIwMTQtMTEtMTEgMTQ6NDA6MjAuMDAw
MDAwMDAwICswMDAwDQorKysgeGVuLTQuNS4wLXJjMi94ZW4veHNtL2ZsYXNrL2hvb2tzLmMJMjAx
NC0xMS0xMSAxODo0Njo1Mi45MjYyMDI5MTkgKzAwMDANCkBAIC03MjcsNyArNzI3LDcgQEANCiAg
ICAgY2FzZSBYRU5fRE9NQ1RMX3Bzcl9jbXRfb3A6DQogICAgICAgICByZXR1cm4gY3VycmVudF9o
YXNfcGVybShkLCBTRUNDTEFTU19ET01BSU4yLCBET01BSU4yX19QU1JfQ01UX09QKTsNCiANCi0g
ICAgY2FzZSBYRU5fRE9NQ1RMX2NvbmZpZ3VyZV9kb21haW46DQorICAgIGNhc2UgWEVOX0RPTUNU
TF9hcm1fY29uZmlndXJlX2RvbWFpbjoNCiAgICAgICAgIHJldHVybiBjdXJyZW50X2hhc19wZXJt
KGQsIFNFQ0NMQVNTX0RPTUFJTjIsIERPTUFJTjJfX0NPTkZJR1VSRV9ET01BSU4pOw0KIA0KICAg
ICBkZWZhdWx0Og0KLS0tIHhlbi00LjUuMC1yYzIveGVuL3hzbS9mbGFzay9wb2xpY3kvYWNjZXNz
X3ZlY3RvcnMub3JpZwkyMDE0LTExLTExIDE0OjQwOjIwLjAwMDAwMDAwMCArMDAwMA0KKysrIHhl
bi00LjUuMC1yYzIveGVuL3hzbS9mbGFzay9wb2xpY3kvYWNjZXNzX3ZlY3RvcnMJMjAxNC0xMS0x
MSAxOToyMDo0MS4wNTgxNzUzMDIgKzAwMDANCkBAIC0xMDIsNyArMTAyLDcgQEANCiAgICAgdW5w
YXVzZQ0KICMgWEVOX0RPTUNUTF9yZXN1bWVkb21haW4NCiAgICAgcmVzdW1lDQotIyBYRU5fRE9N
Q1RMX2NyZWF0ZWRvbWFpbg0KKyMgWEVOX0RPTUNUTF9hcm1fY3JlYXRlZG9tYWluDQogICAgIGNy
ZWF0ZQ0KICMgY2hlY2tlZCBpbiBGTEFTS19SRUxBQkVMX0RPTUFJTiBmb3IgYW55IHJlbGFiZWwg
b3BlcmF0aW9uOg0KICMgIHNvdXJjZSA9IHRoZSBvbGQgbGFiZWwgb2YgdGhlIGRvbWFpbg0K

--8323329-246335390-1415733708=:25402
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-246335390-1415733708=:25402--


From xen-devel-bounces@lists.xen.org Tue Nov 11 21:24:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 21:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoIux-0000HM-54; Tue, 11 Nov 2014 21:24:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1XoIuv-0000HH-P4
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 21:24:01 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	63/2F-25714-07E72645; Tue, 11 Nov 2014 21:24:00 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415741038!7746766!1
X-Originating-IP: [209.85.223.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5543 invoked from network); 11 Nov 2014 21:23:59 -0000
Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com)
	(209.85.223.169)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 21:23:59 -0000
Received: by mail-ie0-f169.google.com with SMTP id tr6so12336293ieb.0
	for <xen-devel@lists.xenproject.org>;
	Tue, 11 Nov 2014 13:23:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=zf0HyGNUSwhI2RWGhSTYb/uDuOWHLmlJfpYw1YPXQPI=;
	b=f+qsafTtAjeCW9yDkMao+tCx5+rDQTmvOsqe/5kLgUW6/Z4uuEpPd05sYnIzoUXK24
	2NOB78wx6xXVtpWpQa5IxZTNf2ym5dcVwHv5CIDRLFDLITph+H3YF/lCyyftW5RzSc/q
	p0D+mIwZwxeZvOX47kC2E7ZpgayEUHHorUoN/u5Kkus3MxEf5ICjzInAqZPOqgIIex5s
	8Btwz20T086Vy9sRBDB7P+aqXZbFsM+6WsarkkSLXeAfZq55miRqOTDWZtFXuhWRKmg0
	zKza8kOjVFU2hkUCOI45Ovdra352yhKkDHzNBByJ47U3H1ovsCOxtG9H4VUTRqW+Vi/c
	MlxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=zf0HyGNUSwhI2RWGhSTYb/uDuOWHLmlJfpYw1YPXQPI=;
	b=RtOpsDXgjXRpVUXj5grn/2soKdACQgQZXdw9b+PZzLyjGOTTV4Kl8w8lm4lHkW2PoQ
	Qi2lRPmGb2XYMCly8o1K7A2sdvnIDS07h5HeUI3Q3A3cDaXbnvxxvTiQ2r8dwH17Kqg/
	xFem4qJMcoXLuyLypAxDTI5AWFGrN/vwGM4lEkvhTNUsNw62m0nNHS6TpWef6XK61G11
	6dn/t48kOnXnLSn7aoN8vblH4E350WczDK8iNSXISgW8402NvW7Yo9Cf2xPaTLzdLCRO
	S/6oBtANBJPkJF+ouhIenqBQE45ZCNhKEK2VOGIwgJR+WzXILTxP2wDh44C1lnjopbt3
	m9FQ==
X-Gm-Message-State: ALoCoQk76J9P84p5XqtNw09v2q6EXSQUpReKpSIfRHzSQ7NYFPYnWWXJdAtJ0rS6Pa1bc3qoTqk1
X-Received: by 10.107.132.168 with SMTP id o40mr44862145ioi.50.1415741038347; 
	Tue, 11 Nov 2014 13:23:58 -0800 (PST)
Received: from google.com ([172.26.48.152])
	by mx.google.com with ESMTPSA id q3sm5431592ioi.22.2014.11.11.13.23.56
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 13:23:57 -0800 (PST)
Date: Tue, 11 Nov 2014 14:23:53 -0700
From: Bjorn Helgaas <bhelgaas@google.com>
To: Yijing Wang <wangyijing@huawei.com>
Message-ID: <20141111212353.GJ28161@google.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: linux-s390@vger.kernel.org, linux-pci@vger.kernel.org,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 0/3] xen MSI code clean up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[+cc Sebastian, linux-s390, David, Konrad, xen-devel]

On Mon, Oct 27, 2014 at 10:44:35AM +0800, Yijing Wang wrote:
> 
> Yijing Wang (3):
>   x86/xen: Introduce a global flag to fix the MSI mask bug
>   x86/xen: Revert "PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()"
>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()

I applied these with David's reviewed-by and ack to pci/msi for v3.19.

I'd like to see an ack from Sebastian for the s390 part, but I guess that
one is pretty trivial.

>  arch/s390/pci/pci.c             |    4 ++--
>  arch/x86/include/asm/x86_init.h |    3 ---
>  arch/x86/kernel/x86_init.c      |   10 ----------
>  arch/x86/pci/xen.c              |   15 +++------------
>  drivers/pci/msi.c               |   29 ++++++++++++-----------------
>  include/linux/msi.h             |    5 +++--
>  6 files changed, 20 insertions(+), 46 deletions(-)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 21:24:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 21:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoIux-0000HM-54; Tue, 11 Nov 2014 21:24:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1XoIuv-0000HH-P4
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 21:24:01 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	63/2F-25714-07E72645; Tue, 11 Nov 2014 21:24:00 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415741038!7746766!1
X-Originating-IP: [209.85.223.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5543 invoked from network); 11 Nov 2014 21:23:59 -0000
Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com)
	(209.85.223.169)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 21:23:59 -0000
Received: by mail-ie0-f169.google.com with SMTP id tr6so12336293ieb.0
	for <xen-devel@lists.xenproject.org>;
	Tue, 11 Nov 2014 13:23:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=zf0HyGNUSwhI2RWGhSTYb/uDuOWHLmlJfpYw1YPXQPI=;
	b=f+qsafTtAjeCW9yDkMao+tCx5+rDQTmvOsqe/5kLgUW6/Z4uuEpPd05sYnIzoUXK24
	2NOB78wx6xXVtpWpQa5IxZTNf2ym5dcVwHv5CIDRLFDLITph+H3YF/lCyyftW5RzSc/q
	p0D+mIwZwxeZvOX47kC2E7ZpgayEUHHorUoN/u5Kkus3MxEf5ICjzInAqZPOqgIIex5s
	8Btwz20T086Vy9sRBDB7P+aqXZbFsM+6WsarkkSLXeAfZq55miRqOTDWZtFXuhWRKmg0
	zKza8kOjVFU2hkUCOI45Ovdra352yhKkDHzNBByJ47U3H1ovsCOxtG9H4VUTRqW+Vi/c
	MlxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=zf0HyGNUSwhI2RWGhSTYb/uDuOWHLmlJfpYw1YPXQPI=;
	b=RtOpsDXgjXRpVUXj5grn/2soKdACQgQZXdw9b+PZzLyjGOTTV4Kl8w8lm4lHkW2PoQ
	Qi2lRPmGb2XYMCly8o1K7A2sdvnIDS07h5HeUI3Q3A3cDaXbnvxxvTiQ2r8dwH17Kqg/
	xFem4qJMcoXLuyLypAxDTI5AWFGrN/vwGM4lEkvhTNUsNw62m0nNHS6TpWef6XK61G11
	6dn/t48kOnXnLSn7aoN8vblH4E350WczDK8iNSXISgW8402NvW7Yo9Cf2xPaTLzdLCRO
	S/6oBtANBJPkJF+ouhIenqBQE45ZCNhKEK2VOGIwgJR+WzXILTxP2wDh44C1lnjopbt3
	m9FQ==
X-Gm-Message-State: ALoCoQk76J9P84p5XqtNw09v2q6EXSQUpReKpSIfRHzSQ7NYFPYnWWXJdAtJ0rS6Pa1bc3qoTqk1
X-Received: by 10.107.132.168 with SMTP id o40mr44862145ioi.50.1415741038347; 
	Tue, 11 Nov 2014 13:23:58 -0800 (PST)
Received: from google.com ([172.26.48.152])
	by mx.google.com with ESMTPSA id q3sm5431592ioi.22.2014.11.11.13.23.56
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 11 Nov 2014 13:23:57 -0800 (PST)
Date: Tue, 11 Nov 2014 14:23:53 -0700
From: Bjorn Helgaas <bhelgaas@google.com>
To: Yijing Wang <wangyijing@huawei.com>
Message-ID: <20141111212353.GJ28161@google.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: linux-s390@vger.kernel.org, linux-pci@vger.kernel.org,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 0/3] xen MSI code clean up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[+cc Sebastian, linux-s390, David, Konrad, xen-devel]

On Mon, Oct 27, 2014 at 10:44:35AM +0800, Yijing Wang wrote:
> 
> Yijing Wang (3):
>   x86/xen: Introduce a global flag to fix the MSI mask bug
>   x86/xen: Revert "PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()"
>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()

I applied these with David's reviewed-by and ack to pci/msi for v3.19.

I'd like to see an ack from Sebastian for the s390 part, but I guess that
one is pretty trivial.

>  arch/s390/pci/pci.c             |    4 ++--
>  arch/x86/include/asm/x86_init.h |    3 ---
>  arch/x86/kernel/x86_init.c      |   10 ----------
>  arch/x86/pci/xen.c              |   15 +++------------
>  drivers/pci/msi.c               |   29 ++++++++++++-----------------
>  include/linux/msi.h             |    5 +++--
>  6 files changed, 20 insertions(+), 46 deletions(-)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 21:35:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 21:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoJ5Z-0000VX-AM; Tue, 11 Nov 2014 21:35:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoJ5X-0000VS-DP
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 21:34:59 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	2D/D3-02696-20182645; Tue, 11 Nov 2014 21:34:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415741695!11898101!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10988 invoked from network); 11 Nov 2014 21:34:57 -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;
	11 Nov 2014 21:34:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191760876"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 16:34:52 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoJ5Q-000740-NV;
	Tue, 11 Nov 2014 21:34:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoJ5Q-0003zL-52;
	Tue, 11 Nov 2014 21:34:52 +0000
Date: Tue, 11 Nov 2014 21:34:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31479-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31479: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31479 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31479/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 11 21:35:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 21:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoJ5Z-0000VX-AM; Tue, 11 Nov 2014 21:35:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoJ5X-0000VS-DP
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 21:34:59 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	2D/D3-02696-20182645; Tue, 11 Nov 2014 21:34:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415741695!11898101!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10988 invoked from network); 11 Nov 2014 21:34:57 -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;
	11 Nov 2014 21:34:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="191760876"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 16:34:52 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoJ5Q-000740-NV;
	Tue, 11 Nov 2014 21:34:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoJ5Q-0003zL-52;
	Tue, 11 Nov 2014 21:34:52 +0000
Date: Tue, 11 Nov 2014 21:34:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31479-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31479: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31479 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31479/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 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 Nov 11 22:05:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 22:05:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoJYK-0000w9-5n; Tue, 11 Nov 2014 22:04:44 +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 1XoJYJ-0000w2-CY
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 22:04:43 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	15/3B-02698-AF782645; Tue, 11 Nov 2014 22:04:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415743480!11898135!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17353 invoked from network); 11 Nov 2014 22:04:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 22:04:41 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABM4Ma5005570
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 22:04:23 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABM4Lmk024852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 22:04:22 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABM4LkD022033; Tue, 11 Nov 2014 22:04:21 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 14:04:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 85127114793; Tue, 11 Nov 2014 17:04:20 -0500 (EST)
Date: Tue, 11 Nov 2014 17:04:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Message-ID: <20141111220420.GA30289@laptop.dumpdata.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<1414377878-23497-2-git-send-email-wangyijing@huawei.com>
	<20141111000456.GB21470@google.com>
	<20141111154538.GC6597@laptop.dumpdata.com>
	<20141111202430.GH28161@google.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141111202430.GH28161@google.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Yijing Wang <wangyijing@huawei.com>, linux-pci@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix
 the MSI mask bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 01:24:30PM -0700, Bjorn Helgaas wrote:
> On Tue, Nov 11, 2014 at 10:45:38AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 10, 2014 at 05:04:56PM -0700, Bjorn Helgaas wrote:
> > > On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
> > > > Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> > > > fixed MSI mask bug which may cause kernel crash. But the commit
> > > > made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask"
> > > > to ignore MSI/MSI-X to fix this issue, it's a cleaner solution.
> > > > And the commit 0e4ccb1505a9 will be reverted in the later patch.
> > > 
> > > The 0e4ccb1505a9 changelog says Xen guests can't write to MSI-X BARs.
> > > But it makes mask_irq a no-op for both MSI-X and MSI.  The MSI mask bit is
> > > in config space, not in memory space.  So why does mask_irq need to be a
> > > no-op for MSI as well?  Are Xen guests prohibited from writing to config
> > 
> > The PV guests it refers do not do write to config space. They have
> > an PCI frontend and backend driver which communicates to the backend (the
> > trusted domain) to setup the MSI and MSI-X. The 'pci_xen_init' (arch/x86/pci/xen.c)
> > is the one that sets up the overrides. When an MSI or MSI-X is requested
> > it is done via the request_irq which ends up calling 'xen_setup_msi_irqs'.
> > If you look there you can see:
> > 
> > 173         if (type == PCI_CAP_ID_MSIX)
> > 174                 ret = xen_pci_frontend_enable_msix(dev, v, nvec);
> > 175         else
> > 176                 ret = xen_pci_frontend_enable_msi(dev, v);
> > 177         if (ret)
> > 178                 goto error;
> > 
> > Which are the calls to the Xen PCI driver to communicate with the
> > backend to setup the MSI.
> > 
> > > space, too?  (It's fine if they are; it's just that the changelog
> > > specifically mentioned MSI-X memory space tables, and it didn't mention
> > > config space at all.)
> > 
> > Correct. The config space is accessible to the guest but if it writes
> > to it - all of those values are ignored by the hypervisor - and that
> > is because the backend is suppose to communicate to the hypervisor
> > whether the guest can indeed setup MSI or MSI-X.
> > 
> > > 
> > > And I *assume* there's some Xen mechanism that accomplishes the mask_irq in
> > > a different way, since the actual mask_irq interface does nothing?  (This
> > > is really a question for 0e4ccb1505a9, since I don't think this particular
> > > patch changes anything in that respect.)
> > 
> > Correct. 'request_irq' ends up doing that. Or rather it ends up
> > calling xen_setup_msi_irqs which takes care of that.
> > 
> > The Xen PV guests (not to be confused with Xen HVM guests) run without
> > any emulated devices. That means most of the x86 platform things - ioports,
> > VGA, etc - are removed. Instead that functionality is provided via 
> > frontend drivers that communicate to the backend via a ring.
> > 
> > Hopefully this clarifies it?
> 
> I think so.  I propose the following changelog.  Let me know if it's still
> inaccurate:
> 
>   PCI/MSI: Add pci_msi_ignore_mask to prevent MSI/MSI-X BAR writes
> 
>   MSI-X vector Mask Bits are in MSI-X Tables in PCI memory space.  Xen guests

Xen PV
>   can't write to those tables.  MSI vector Mask Bits are in PCI configuration
>   space.  Xen guests can write to config space, but those writes are ignored.
> 
>   Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and
>   msix_mask_irq()") added a way to override default_mask_msi_irqs() and
>   default_mask_msix_irqs() so they can be no-ops in Xen guests, but this is

Xen PV guests
>   more complicated than necessary.
> 
>   Add "pci_msi_ignore_mask" in the core PCI MSI code.  If set,
>   default_mask_msi_irqs() and default_mask_msix_irqs() return without doing
>   anything.  This is less flexible, but much simpler.
> 
> I guess you mentioned PV and HVM guests, and it sounds like all this only
> applies to HVM guests.

No, PV guests :-)

HVM guests will do the normal x86 type machinery.
> 
> Bjorn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 22:05:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 22:05:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoJYK-0000w9-5n; Tue, 11 Nov 2014 22:04:44 +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 1XoJYJ-0000w2-CY
	for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 22:04:43 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	15/3B-02698-AF782645; Tue, 11 Nov 2014 22:04:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415743480!11898135!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17353 invoked from network); 11 Nov 2014 22:04:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Nov 2014 22:04:41 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sABM4Ma5005570
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Nov 2014 22:04:23 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABM4Lmk024852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Nov 2014 22:04:22 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sABM4LkD022033; Tue, 11 Nov 2014 22:04:21 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 14:04:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 85127114793; Tue, 11 Nov 2014 17:04:20 -0500 (EST)
Date: Tue, 11 Nov 2014 17:04:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Message-ID: <20141111220420.GA30289@laptop.dumpdata.com>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<1414377878-23497-2-git-send-email-wangyijing@huawei.com>
	<20141111000456.GB21470@google.com>
	<20141111154538.GC6597@laptop.dumpdata.com>
	<20141111202430.GH28161@google.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141111202430.GH28161@google.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Yijing Wang <wangyijing@huawei.com>, linux-pci@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 1/3] x86/xen: Introduce a global flag to fix
 the MSI mask bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 01:24:30PM -0700, Bjorn Helgaas wrote:
> On Tue, Nov 11, 2014 at 10:45:38AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 10, 2014 at 05:04:56PM -0700, Bjorn Helgaas wrote:
> > > On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
> > > > Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> > > > fixed MSI mask bug which may cause kernel crash. But the commit
> > > > made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask"
> > > > to ignore MSI/MSI-X to fix this issue, it's a cleaner solution.
> > > > And the commit 0e4ccb1505a9 will be reverted in the later patch.
> > > 
> > > The 0e4ccb1505a9 changelog says Xen guests can't write to MSI-X BARs.
> > > But it makes mask_irq a no-op for both MSI-X and MSI.  The MSI mask bit is
> > > in config space, not in memory space.  So why does mask_irq need to be a
> > > no-op for MSI as well?  Are Xen guests prohibited from writing to config
> > 
> > The PV guests it refers do not do write to config space. They have
> > an PCI frontend and backend driver which communicates to the backend (the
> > trusted domain) to setup the MSI and MSI-X. The 'pci_xen_init' (arch/x86/pci/xen.c)
> > is the one that sets up the overrides. When an MSI or MSI-X is requested
> > it is done via the request_irq which ends up calling 'xen_setup_msi_irqs'.
> > If you look there you can see:
> > 
> > 173         if (type == PCI_CAP_ID_MSIX)
> > 174                 ret = xen_pci_frontend_enable_msix(dev, v, nvec);
> > 175         else
> > 176                 ret = xen_pci_frontend_enable_msi(dev, v);
> > 177         if (ret)
> > 178                 goto error;
> > 
> > Which are the calls to the Xen PCI driver to communicate with the
> > backend to setup the MSI.
> > 
> > > space, too?  (It's fine if they are; it's just that the changelog
> > > specifically mentioned MSI-X memory space tables, and it didn't mention
> > > config space at all.)
> > 
> > Correct. The config space is accessible to the guest but if it writes
> > to it - all of those values are ignored by the hypervisor - and that
> > is because the backend is suppose to communicate to the hypervisor
> > whether the guest can indeed setup MSI or MSI-X.
> > 
> > > 
> > > And I *assume* there's some Xen mechanism that accomplishes the mask_irq in
> > > a different way, since the actual mask_irq interface does nothing?  (This
> > > is really a question for 0e4ccb1505a9, since I don't think this particular
> > > patch changes anything in that respect.)
> > 
> > Correct. 'request_irq' ends up doing that. Or rather it ends up
> > calling xen_setup_msi_irqs which takes care of that.
> > 
> > The Xen PV guests (not to be confused with Xen HVM guests) run without
> > any emulated devices. That means most of the x86 platform things - ioports,
> > VGA, etc - are removed. Instead that functionality is provided via 
> > frontend drivers that communicate to the backend via a ring.
> > 
> > Hopefully this clarifies it?
> 
> I think so.  I propose the following changelog.  Let me know if it's still
> inaccurate:
> 
>   PCI/MSI: Add pci_msi_ignore_mask to prevent MSI/MSI-X BAR writes
> 
>   MSI-X vector Mask Bits are in MSI-X Tables in PCI memory space.  Xen guests

Xen PV
>   can't write to those tables.  MSI vector Mask Bits are in PCI configuration
>   space.  Xen guests can write to config space, but those writes are ignored.
> 
>   Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and
>   msix_mask_irq()") added a way to override default_mask_msi_irqs() and
>   default_mask_msix_irqs() so they can be no-ops in Xen guests, but this is

Xen PV guests
>   more complicated than necessary.
> 
>   Add "pci_msi_ignore_mask" in the core PCI MSI code.  If set,
>   default_mask_msi_irqs() and default_mask_msix_irqs() return without doing
>   anything.  This is less flexible, but much simpler.
> 
> I guess you mentioned PV and HVM guests, and it sounds like all this only
> applies to HVM guests.

No, PV guests :-)

HVM guests will do the normal x86 type machinery.
> 
> Bjorn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 23:02:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 23:02:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoKRy-0001oV-CT; Tue, 11 Nov 2014 23:02:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoKRw-0001oQ-8Q
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 23:02:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0A/E6-24532-37592645; Tue, 11 Nov 2014 23:02:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415746929!4725400!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16844 invoked from network); 11 Nov 2014 23:02:10 -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;
	11 Nov 2014 23:02:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190345428"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 18:02:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoKRr-0007UC-Lk;
	Tue, 11 Nov 2014 23:02:07 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoKRr-0006dj-5D;
	Tue, 11 Nov 2014 23:02:07 +0000
Date: Tue, 11 Nov 2014 23:02:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31482-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31482: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31482 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31482/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 11 23:02:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 23:02:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoKRy-0001oV-CT; Tue, 11 Nov 2014 23:02:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoKRw-0001oQ-8Q
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 23:02:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0A/E6-24532-37592645; Tue, 11 Nov 2014 23:02:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415746929!4725400!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16844 invoked from network); 11 Nov 2014 23:02:10 -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;
	11 Nov 2014 23:02:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190345428"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 18:02:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoKRr-0007UC-Lk;
	Tue, 11 Nov 2014 23:02:07 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoKRr-0006dj-5D;
	Tue, 11 Nov 2014 23:02:07 +0000
Date: Tue, 11 Nov 2014 23:02:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31482-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31482: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31482 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31482/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 11 23:28:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 23:28:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoKqi-00025w-Li; Tue, 11 Nov 2014 23:27: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@citrix.com>) id 1XoKqh-00025r-42
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 23:27:47 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	C4/32-31453-27B92645; Tue, 11 Nov 2014 23:27:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415748463!11878391!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11605 invoked from network); 11 Nov 2014 23:27:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 23:27:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190350972"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 18:27:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoKqa-0007bg-Fk;
	Tue, 11 Nov 2014 23:27:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoKqZ-0007l4-Va;
	Tue, 11 Nov 2014 23:27:40 +0000
Date: Tue, 11 Nov 2014 23:27:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31485-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31485: 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 31485 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31485/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              72f808c41fcc01f1eb01bde25538638ab7b115a3
baseline version:
 libvirt              0396394f027edb5fa70514a0d11fa62ea7281bd9

------------------------------------------------------------
People who touched revisions under test:
  Jincheng Miao <jmiao@redhat.com>
  Matthias Gatto <matthias.gatto@outscale.com>
  Michal Privoznik <mprivozn@redhat.com>
  Prerna Saxena <prerna@linux.vnet.ibm.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=72f808c41fcc01f1eb01bde25538638ab7b115a3
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 72f808c41fcc01f1eb01bde25538638ab7b115a3
+ branch=libvirt
+ revision=72f808c41fcc01f1eb01bde25538638ab7b115a3
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 72f808c41fcc01f1eb01bde25538638ab7b115a3:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   0396394..72f808c  72f808c41fcc01f1eb01bde25538638ab7b115a3 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 11 23:28:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Nov 2014 23:28:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoKqi-00025w-Li; Tue, 11 Nov 2014 23:27: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@citrix.com>) id 1XoKqh-00025r-42
	for xen-devel@lists.xensource.com; Tue, 11 Nov 2014 23:27:47 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	C4/32-31453-27B92645; Tue, 11 Nov 2014 23:27:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415748463!11878391!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11605 invoked from network); 11 Nov 2014 23:27:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Nov 2014 23:27:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="190350972"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 18:27:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoKqa-0007bg-Fk;
	Tue, 11 Nov 2014 23:27:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoKqZ-0007l4-Va;
	Tue, 11 Nov 2014 23:27:40 +0000
Date: Tue, 11 Nov 2014 23:27:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31485-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31485: 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 31485 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31485/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              72f808c41fcc01f1eb01bde25538638ab7b115a3
baseline version:
 libvirt              0396394f027edb5fa70514a0d11fa62ea7281bd9

------------------------------------------------------------
People who touched revisions under test:
  Jincheng Miao <jmiao@redhat.com>
  Matthias Gatto <matthias.gatto@outscale.com>
  Michal Privoznik <mprivozn@redhat.com>
  Prerna Saxena <prerna@linux.vnet.ibm.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=72f808c41fcc01f1eb01bde25538638ab7b115a3
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 72f808c41fcc01f1eb01bde25538638ab7b115a3
+ branch=libvirt
+ revision=72f808c41fcc01f1eb01bde25538638ab7b115a3
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 72f808c41fcc01f1eb01bde25538638ab7b115a3:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   0396394..72f808c  72f808c41fcc01f1eb01bde25538638ab7b115a3 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 01:37:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 01: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 1XoMra-0007Sk-IZ; Wed, 12 Nov 2014 01:36:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoMrZ-0007Sf-CM
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 01:36:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	76/B6-09842-0B9B2645; Wed, 12 Nov 2014 01:36:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415756207!8600279!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18685 invoked from network); 12 Nov 2014 01:36:48 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-21.messagelabs.com with SMTP;
	12 Nov 2014 01:36:48 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 11 Nov 2014 17:36:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="415111614"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by FMSMGA003.fm.intel.com with ESMTP; 11 Nov 2014 17:27:49 -0800
Message-ID: <5462B9AC.6050704@intel.com>
Date: Wed, 12 Nov 2014 09:36:44 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
In-Reply-To: <5461EDD702000078000465C3@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/11 18:07, Jan Beulich wrote:
>>>> On 11.11.14 at 10:42, <tiejun.chen@intel.com> wrote:
>> On 2014/11/11 17:06, Jan Beulich wrote:
>>> Part of which would involve re-considering whether device
>>> assignment shouldn't be done before memory population in the
>>> tool stack.
>>>
>>
>> Yes, after we introduce this new domctl, we just make sure this domctl
>> should be called before memory population no matter when we do assign a
>> device as passthrough.
>
> You didn't think through the implications then: If device assignment
> happens early enough, there's no need to report SBDF tuples via a

In the present the device assignment is always after memory population. 
And I also mentioned previously I double checked this sequence with printk.

> new domctl (or only if we want to still allow for post-boot assignment
> of affected devices without using the global enforcement flag, in
> which case assigning devices early at boot time is pointless).

The global enforcement flag is mainly used to provide such an approach 
the user know exactly he/she may need a hotplug later, we'd better check 
to reserve all RMRR ranges in advance.

So I guess you mean we need to separate this interface from our original 
device assignment like this,

#1 pci_force as a global variable would control whether we force to 
check/reserve __all__ RMRR ranges.

#2 flags field in each specific device of new domctl would control 
whether this device need to check/reserve its own RMRR range. But its 
not dependent on current device assignment domctl, so the user can use 
them to control which devices need to work as hotplug later, separately. 
This means we should introduce new parameters just like current 'pci' 
construction, right? Or extend current device assignment to be 
compatible with this case, for instance, new field to indicate if we 
really want to do device assignment in boot time.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 01:37:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 01: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 1XoMra-0007Sk-IZ; Wed, 12 Nov 2014 01:36:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoMrZ-0007Sf-CM
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 01:36:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	76/B6-09842-0B9B2645; Wed, 12 Nov 2014 01:36:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415756207!8600279!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18685 invoked from network); 12 Nov 2014 01:36:48 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-21.messagelabs.com with SMTP;
	12 Nov 2014 01:36:48 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 11 Nov 2014 17:36:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="415111614"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by FMSMGA003.fm.intel.com with ESMTP; 11 Nov 2014 17:27:49 -0800
Message-ID: <5462B9AC.6050704@intel.com>
Date: Wed, 12 Nov 2014 09:36:44 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
In-Reply-To: <5461EDD702000078000465C3@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/11 18:07, Jan Beulich wrote:
>>>> On 11.11.14 at 10:42, <tiejun.chen@intel.com> wrote:
>> On 2014/11/11 17:06, Jan Beulich wrote:
>>> Part of which would involve re-considering whether device
>>> assignment shouldn't be done before memory population in the
>>> tool stack.
>>>
>>
>> Yes, after we introduce this new domctl, we just make sure this domctl
>> should be called before memory population no matter when we do assign a
>> device as passthrough.
>
> You didn't think through the implications then: If device assignment
> happens early enough, there's no need to report SBDF tuples via a

In the present the device assignment is always after memory population. 
And I also mentioned previously I double checked this sequence with printk.

> new domctl (or only if we want to still allow for post-boot assignment
> of affected devices without using the global enforcement flag, in
> which case assigning devices early at boot time is pointless).

The global enforcement flag is mainly used to provide such an approach 
the user know exactly he/she may need a hotplug later, we'd better check 
to reserve all RMRR ranges in advance.

So I guess you mean we need to separate this interface from our original 
device assignment like this,

#1 pci_force as a global variable would control whether we force to 
check/reserve __all__ RMRR ranges.

#2 flags field in each specific device of new domctl would control 
whether this device need to check/reserve its own RMRR range. But its 
not dependent on current device assignment domctl, so the user can use 
them to control which devices need to work as hotplug later, separately. 
This means we should introduce new parameters just like current 'pci' 
construction, right? Or extend current device assignment to be 
compatible with this case, for instance, new field to indicate if we 
really want to do device assignment in boot time.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 01:38:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 01:38:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoMso-0007XX-DW; Wed, 12 Nov 2014 01:38:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoMsn-0007XO-Bi
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 01:38:05 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	29/97-28865-CF9B2645; Wed, 12 Nov 2014 01:38:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415756282!7771003!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28088 invoked from network); 12 Nov 2014 01:38:03 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 01:38:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAC1bxTM021876
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 01:38:00 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC1bwAg029877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 01:37:59 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC1bwTE029872; Wed, 12 Nov 2014 01:37:58 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 17:37:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A6991114860; Tue, 11 Nov 2014 20:37:57 -0500 (EST)
Date: Tue, 11 Nov 2014 20:37:57 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>, zhenzhong.duan@oracle.com
Message-ID: <20141112013757.GC2593@laptop.dumpdata.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141110213248.GA23182@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Nov 10, 2014 at 04:32:48PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 10, 2014 at 01:07:20PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 10, 2014 at 05:42:32PM +0000, David Vrabel wrote:
> > > On 10/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> > > > Hey,
> > > > =

> > > > With Xen 4.5 (today's staging), when I boot a guest and then do pci=
-attach
> > > > the BARs values are corrupt.
> =

> I can reproduce this with Xen 4.4, Xen 4.3 and Xen 4.1.
> =

> A bit digging in and I realized that:
> =

> (XEN) memory_map:add: dom1 gfn=3Df4000 mfn=3Dd8000 nr=3D4000 [64M]
> (XEN) AMD-Vi: update_paging_mode Try to access pdev_list without aquiring=
 pcidevs_lock.
> (XEN) memory_map:add: dom1 gfn=3Df8000 mfn=3Dfc000 nr=3D2000 [32M]
> (XEN) ioport_map:add: dom1 gport=3D1000 mport=3Dc000 nr=3D80
> (XEN) AMD-Vi: Disable: device id =3D 0x500, domain =3D 0, paging mode =3D=
 3
> (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x500, type =3D 0x1, ro=
ot table =3D 0x228b02000, domain =3D 1, paging mode =3D 3
> =

> The sizes are my own editing. This means QEMU is putting the
> devices in the MMIO region - and doing it succesfully. But then:
> =

> > > =

> > > =

> > > > [  152.572965] pci 0000:00:04.0: BAR 1: no space for [mem size 0x08=
000000 64bit  pref]
> > [ =A0152.518320] pci 0000:00:04.0: reg 0x14: [mem 0x00000000-0x07ffffff=
 64bit pref]
> =

> .. The guest computes the right size for them, but reads the wrong BAR va=
lue
> that was set by QEMU and also created in the hypervisor.
> =

> Perhaps this is Linux kernel being on fritz. Will try another kernel.

I figured this out.


When we pass in the device at bootup, the hvmloader does:

(d4) pci dev 05:0 bar 14 size 008000000: 0e000000c
(d4) pci dev 05:0 bar 1c size 004000000: 0e800000c
(d4) pci dev 05:0 bar 10 size 002000000: 0ec000000
(d4) pci dev 05:0 bar 24 size 000000080: 00000c201

That is - it finds the size, and then it sets the BARs to fit within
the MMIO region. QEMU is not involved in this.

When we PCI insert an device, the BARs are not set at all - and hence
the Linux kernel is the one that tries to set the BARs in. The
reason it cannot fit the device in the MMIO region is due to the
_CRS only having certain ranges (even thought the MMIO region can
cover 2GB). See:

Without any devices (and me doing PCI insertion after that):
# dmesg | grep "bus resource"
[    0.366000] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.366000] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.366000] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.366000] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bfff=
f]
[    0.366000] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbfffff=
f]

With the device (my GPU card) inserted so that hvmloader can enumerate it:
 dmesg | grep 'resource'     =

[    0.455006] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.459006] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.462006] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.466006] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bfff=
f]
[    0.469006] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbfffff=
f]

I chatted with Bjorn and Rafeal on IRC about how PCI insertion works
on baremetal and it sounds like Thunderbolt device insertion is an
interesting case. The SMM sets the BAR regions to fit within the MMIO
(which is advertised by the _CRS) and it then pokes the OS to enumerate
the BARs. The OS is free to use what the firmware has set or renumber
it. The end result is that since the SMM 'fits' the BAR inside the
pre-set _CRS window it all works. We do not do that.

The two ways I could think of making this work are:
 - QEMU tracks BAR enumeration. When a new device is inserted it would
   set the BAR to fit within the E820 "HOLE" region. If it can't
   (because the MMIO is too small) it puts it at the end of the memory.
   Naturally the 'end of the memory' part would require adding
   _CRS to cover end of GPFN to never never land. And also the _CRS
   region for the MMIO under 4GB would have to be expanded so QEMU
   can jam things in there.

 - Or add in dsdt.asl another _CRS region controlled by the hvmloader.
   This one would start at the end of GPFN + delta of maxmem - mem and
   continue to never never land. The hvmloader would just write the
   the values in the BIOS OperationRegion (0xFC000000) and let the
   AML code take care of parsing it and constructing the #9 _CRS region.
   This will allow kernels who are picky about BARs not being in _CRS
   region to deal with cards that are hot-plugged past BIOS boot.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 01:38:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 01:38:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoMso-0007XX-DW; Wed, 12 Nov 2014 01:38:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoMsn-0007XO-Bi
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 01:38:05 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	29/97-28865-CF9B2645; Wed, 12 Nov 2014 01:38:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415756282!7771003!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28088 invoked from network); 12 Nov 2014 01:38:03 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 01:38:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAC1bxTM021876
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 01:38:00 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC1bwAg029877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 01:37:59 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC1bwTE029872; Wed, 12 Nov 2014 01:37:58 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 17:37:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A6991114860; Tue, 11 Nov 2014 20:37:57 -0500 (EST)
Date: Tue, 11 Nov 2014 20:37:57 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>, zhenzhong.duan@oracle.com
Message-ID: <20141112013757.GC2593@laptop.dumpdata.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141110213248.GA23182@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Nov 10, 2014 at 04:32:48PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 10, 2014 at 01:07:20PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 10, 2014 at 05:42:32PM +0000, David Vrabel wrote:
> > > On 10/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> > > > Hey,
> > > > =

> > > > With Xen 4.5 (today's staging), when I boot a guest and then do pci=
-attach
> > > > the BARs values are corrupt.
> =

> I can reproduce this with Xen 4.4, Xen 4.3 and Xen 4.1.
> =

> A bit digging in and I realized that:
> =

> (XEN) memory_map:add: dom1 gfn=3Df4000 mfn=3Dd8000 nr=3D4000 [64M]
> (XEN) AMD-Vi: update_paging_mode Try to access pdev_list without aquiring=
 pcidevs_lock.
> (XEN) memory_map:add: dom1 gfn=3Df8000 mfn=3Dfc000 nr=3D2000 [32M]
> (XEN) ioport_map:add: dom1 gport=3D1000 mport=3Dc000 nr=3D80
> (XEN) AMD-Vi: Disable: device id =3D 0x500, domain =3D 0, paging mode =3D=
 3
> (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x500, type =3D 0x1, ro=
ot table =3D 0x228b02000, domain =3D 1, paging mode =3D 3
> =

> The sizes are my own editing. This means QEMU is putting the
> devices in the MMIO region - and doing it succesfully. But then:
> =

> > > =

> > > =

> > > > [  152.572965] pci 0000:00:04.0: BAR 1: no space for [mem size 0x08=
000000 64bit  pref]
> > [ =A0152.518320] pci 0000:00:04.0: reg 0x14: [mem 0x00000000-0x07ffffff=
 64bit pref]
> =

> .. The guest computes the right size for them, but reads the wrong BAR va=
lue
> that was set by QEMU and also created in the hypervisor.
> =

> Perhaps this is Linux kernel being on fritz. Will try another kernel.

I figured this out.


When we pass in the device at bootup, the hvmloader does:

(d4) pci dev 05:0 bar 14 size 008000000: 0e000000c
(d4) pci dev 05:0 bar 1c size 004000000: 0e800000c
(d4) pci dev 05:0 bar 10 size 002000000: 0ec000000
(d4) pci dev 05:0 bar 24 size 000000080: 00000c201

That is - it finds the size, and then it sets the BARs to fit within
the MMIO region. QEMU is not involved in this.

When we PCI insert an device, the BARs are not set at all - and hence
the Linux kernel is the one that tries to set the BARs in. The
reason it cannot fit the device in the MMIO region is due to the
_CRS only having certain ranges (even thought the MMIO region can
cover 2GB). See:

Without any devices (and me doing PCI insertion after that):
# dmesg | grep "bus resource"
[    0.366000] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.366000] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.366000] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.366000] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bfff=
f]
[    0.366000] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbfffff=
f]

With the device (my GPU card) inserted so that hvmloader can enumerate it:
 dmesg | grep 'resource'     =

[    0.455006] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.459006] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.462006] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.466006] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bfff=
f]
[    0.469006] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbfffff=
f]

I chatted with Bjorn and Rafeal on IRC about how PCI insertion works
on baremetal and it sounds like Thunderbolt device insertion is an
interesting case. The SMM sets the BAR regions to fit within the MMIO
(which is advertised by the _CRS) and it then pokes the OS to enumerate
the BARs. The OS is free to use what the firmware has set or renumber
it. The end result is that since the SMM 'fits' the BAR inside the
pre-set _CRS window it all works. We do not do that.

The two ways I could think of making this work are:
 - QEMU tracks BAR enumeration. When a new device is inserted it would
   set the BAR to fit within the E820 "HOLE" region. If it can't
   (because the MMIO is too small) it puts it at the end of the memory.
   Naturally the 'end of the memory' part would require adding
   _CRS to cover end of GPFN to never never land. And also the _CRS
   region for the MMIO under 4GB would have to be expanded so QEMU
   can jam things in there.

 - Or add in dsdt.asl another _CRS region controlled by the hvmloader.
   This one would start at the end of GPFN + delta of maxmem - mem and
   continue to never never land. The hvmloader would just write the
   the values in the BIOS OperationRegion (0xFC000000) and let the
   AML code take care of parsing it and constructing the #9 _CRS region.
   This will allow kernels who are picky about BARs not being in _CRS
   region to deal with cards that are hot-plugged past BIOS boot.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 02:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 02:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoNay-0008RS-1H; Wed, 12 Nov 2014 02:23:44 +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 1XoNaw-0008R6-5n
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 02:23:42 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	23/30-27785-DA4C2645; Wed, 12 Nov 2014 02:23:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415759019!11925137!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24564 invoked from network); 12 Nov 2014 02:23:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 02:23:40 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAC2NWPZ010156
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 02:23:33 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC2NVtR002621
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 02:23:32 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC2NUNo003238; Wed, 12 Nov 2014 02:23:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 18:23:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6595B11489E; Tue, 11 Nov 2014 21:23:29 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Tue, 11 Nov 2014 21:23:24 -0500
Message-Id: <1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet with
	an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The existing tasklet mechanism has a single global
spinlock that is taken every-time the global list
is touched. And we use this lock quite a lot - when
we call do_tasklet_work which is called via an softirq
and from the idle loop. We take the lock on any
operation on the tasklet_list.

The problem we are facing is that there are quite a lot of
tasklets scheduled. The most common one that is invoked is
the one injecting the VIRQ_TIMER in the guest. Guests
are not insane and don't set the one-shot or periodic
clocks to be in sub 1ms intervals (causing said tasklet
to be scheduled for such small intervalls).

The problem appears when PCI passthrough devices are used
over many sockets and we have an mix of heavy-interrupt
guests and idle guests. The idle guests end up seeing
1/10 of its RUNNING timeslice eaten by the hypervisor
(and 40% steal time).

The mechanism by which we inject PCI interrupts is by
hvm_do_IRQ_dpci which schedules the hvm_dirq_assist
tasklet every time an interrupt is received.
The callchain is:

_asm_vmexit_handler
 -> vmx_vmexit_handler
    ->vmx_do_extint
        -> do_IRQ
            -> __do_IRQ_guest
                -> hvm_do_IRQ_dpci
                   tasklet_schedule(&dpci->dirq_tasklet);
                   [takes lock to put the tasklet on]

[later on the schedule_tail is invoked which is 'vmx_do_resume']

vmx_do_resume
 -> vmx_asm_do_vmentry
        -> call vmx_intr_assist
          -> vmx_process_softirqs
            -> do_softirq
              [executes the tasklet function, takes the
               lock again]

While on other CPUs they might be sitting in a idle loop
and invoked to deliver an VIRQ_TIMER, which also ends
up taking the lock twice: first to schedule the
v->arch.hvm_vcpu.assert_evtchn_irq_tasklet (accounted to
the guests' BLOCKED_state); then to execute it - which is
accounted for in the guest's RUNTIME_state.

The end result is that on a 8 socket machine with
PCI passthrough, where four sockets are busy with interrupts,
and the other sockets have idle guests - we end up with
the idle guests having around 40% steal time and 1/10
of its timeslice (3ms out of 30 ms) being tied up
taking the lock. The latency of the PCI interrupts delieved
to guest is also hindered.

With this patch the problem disappears completly.
That is removing the lock for the PCI passthrough use-case
(the 'hvm_dirq_assist' case) by not using tasklets at all.

The patch is simple - instead of scheduling an tasklet
we schedule our own softirq - HVM_DPCI_SOFTIRQ, which will
take care of running 'hvm_dirq_assist'. The information we need
on each CPU is which 'struct hvm_pirq_dpci' structure the
'hvm_dirq_assist' needs to run on. That is simple solved by
threading the 'struct hvm_pirq_dpci' through a linked list.
The rule of only running one 'hvm_dirq_assist' for only
one 'hvm_pirq_dpci' is also preserved by having
'schedule_dpci_for' ignore any subsequent calls for an domain
which has already been scheduled.

== Code details ==

Most of the code complexity comes from the '->dom' field
in the 'hvm_pirq_dpci' structure. We use it for ref-counting
and as such it MUST be valid as long as STATE_SCHED bit is
set. Whoever clears the STATE_SCHED bit does the ref-counting
and can also reset the '->dom' field.

To compound the complexity, there are multiple points where the
'hvm_pirq_dpci' structure is reset or re-used. Initially
(first time the domain uses the pirq), the 'hvm_pirq_dpci->dom'
field is set to NULL as it is allocated. On subsequent calls
in to 'pt_irq_create_bind' the ->dom is whatever it had last time.

As this is the initial call (which QEMU ends up calling when the
guest writes an vector value in the MSI field) we MUST set the
'->dom' to a the proper structure (otherwise we cannot do
proper ref-counting).

The mechanism to tear it down is more complex as there
are three ways it can be executed. To make it simpler
everything revolves around 'pt_pirq_softirq_active'. If it
returns -EAGAIN that means there is an outstanding softirq
that needs to finish running before we can continue tearing
down. With that in mind:

a) pci_clean_dpci_irq. This gets called when the guest is
   being destroyed. We end up calling 'pt_pirq_softirq_active'
   to see if it is OK to continue the destruction.

   The scenarios in which the 'struct pirq' (and subsequently
   the 'hvm_pirq_dpci') gets destroyed is when:

   - guest did not use the pirq at all after setup.
   - guest did use pirq, but decided to mask and left it in that
     state.
   - guest did use pirq, but crashed.

   In all of those scenarios we end up calling
   'pt_pirq_softirq_active' to check if the softirq is still
   active. Read below on the 'pt_pirq_softirq_active' loop.

b) pt_irq_destroy_bind (guest disables the MSI). We double-check
   that the softirq has run by piggy-backing on the existing
   'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
   We add the extra call to 'pt_pirq_softirq_active' in
   'pt_pirq_cleanup_check'.

   NOTE: Guests that use event channels unbind first the
   event channel from PIRQs, so the 'pt_pirq_cleanup_check'
   won't be called as 'event' is set to zero. In that case
   we either clean it up via the a) or c) mechanism.

   There is an extra scenario regardless of 'event' being
   set or not: the guest did 'pt_irq_destroy_bind' while an
   interrupt was triggered and softirq was scheduled (but had not
   been run). It is OK to still run the softirq as
   hvm_dirq_assist won't do anything (as the flags are
   set to zero). However we will try to deschedule the
   softirq if we can (by clearing the STATE_SCHED bit and us
   doing the ref-counting).

c) pt_irq_create_bind (not a typo). The scenarios are:

     - guest disables the MSI and then enables it
       (rmmod and modprobe in a loop). We call 'pt_pirq_reset'
       which checks to see if the softirq has been scheduled.
       Imagine the 'b)' with interrupts in flight and c) getting
       called in a loop.

We will spin up on 'pt_pirq_is_active' (at the start of the
'pt_irq_create_bind') with the event_lock spinlock dropped and
waiting (cpu_relax). We cannot call 'process_pending_softirqs' as it
might result in a dead-lock. hvm_dirq_assist will be executed
and then the softirq will clear 'state' which signals that that we
can re-use the 'hvm_pirq_dpci' structure. In case this softirq
is scheduled on a remote CPU the softirq will run on it as the
semantics behind an softirq is that it will execute within the
guest interruption.

     - we hit once the error paths in 'pt_irq_create_bind' while
       an interrupt was triggered and softirq was scheduled.

If the softirq is in STATE_RUN that means it is executing and we should
let it continue on. We can clear the '->dom' field as the softirq
has stashed it beforehand. If the softirq is STATE_SCHED and
we are successful in clearing it, we do the ref-counting and
clear the '->dom' field. Otherwise we let the softirq continue
on and the '->dom' field is left intact. The clearing of
the '->dom' is left to a), b) or again c) case.

Note that in both cases the 'flags' variable is cleared so
hvm_dirq_assist won't actually do anything.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: Jan Beulich <JBeulich@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

---
v2: On top of ref-cnts also have wait loop for the outstanding
    'struct domain' that need to be processed.
v3: Add -ERETRY, fix up StyleGuide issues
v4: Clean it up mode, redo per_cpu, this_cpu logic
v5: Instead of threading struct domain, use hvm_pirq_dpci.
v6: Ditch the 'state' bit, expand description, simplify
    softirq and teardown sequence.
v7: Flesh out the comments. Drop the use of domain refcounts
v8: Add two bits (STATE_[SCHED|RUN]) to allow refcounts.
v9: Use cmpxchg, ASSSERT, fix up comments per Jan.
v10: Fix up issues spotted by Jan.
v11: IPI the remote CPU (once) if it it has the softirq scheduled.
v12: Remove the IPI for the remote CPU as the sofitrq mechanism does that.
v13: Clarify comments.
v14: Add Reviewed-by
---
 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 251 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  31 ++++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 254 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..73d01bb 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1965,7 +1965,9 @@ int domain_relinquish_resources(struct domain *d)
     switch ( d->arch.relmem )
     {
     case RELMEM_not_started:
-        pci_release_devices(d);
+        ret = pci_release_devices(d);
+        if ( ret )
+            return ret;
 
         /* Tear down paging-assistance stuff. */
         ret = paging_teardown(d);
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index dceb17e..b61dbd6 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -20,14 +20,116 @@
 
 #include <xen/event.h>
 #include <xen/iommu.h>
+#include <xen/cpu.h>
 #include <xen/irq.h>
 #include <asm/hvm/irq.h>
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
-#include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long arg);
+static DEFINE_PER_CPU(struct list_head, dpci_list);
+
+/*
+ * These two bit states help to safely schedule, deschedule, and wait until
+ * the softirq has finished.
+ *
+ * The semantics behind these two bits is as follow:
+ *  - STATE_SCHED - whoever modifies it has to ref-count the domain (->dom).
+ *  - STATE_RUN - only softirq is allowed to set and clear it. If it has
+ *      been set hvm_dirq_assist will RUN with a saved value of the
+ *      'struct domain' copied from 'pirq_dpci->dom' before STATE_RUN was set.
+ *
+ * The usual states are: STATE_SCHED(set) -> STATE_RUN(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(unset).
+ *
+ * However the states can also diverge such as: STATE_SCHED(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(set) -> STATE_RUN(unset). That means
+ * the 'hvm_dirq_assist' never run and that the softirq did not do any
+ * ref-counting.
+ */
+
+enum {
+    STATE_SCHED,
+    STATE_RUN
+};
+
+/*
+ * This can be called multiple times, but the softirq is only raised once.
+ * That is until the STATE_SCHED state has been cleared. The state can be
+ * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
+ * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
+ * the softirq had a chance to run).
+ */
+static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
+{
+    unsigned long flags;
+
+    if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+        return;
+
+    get_knownalive_domain(pirq_dpci->dom);
+
+    local_irq_save(flags);
+    list_add_tail(&pirq_dpci->softirq_list, &this_cpu(dpci_list));
+    local_irq_restore(flags);
+
+    raise_softirq(HVM_DPCI_SOFTIRQ);
+}
+
+/*
+ * If we are racing with softirq_dpci (STATE_SCHED) we return
+ * true. Otherwise we return false.
+ *
+ * If it is false, it is the callers responsibility to make sure
+ * that the softirq (with the event_lock dropped) has ran.
+ */
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
+{
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+        return 1;
+
+    /*
+     * If in the future we would call 'raise_softirq_for' right away
+     * after 'pt_pirq_softirq_active' we MUST reset the list (otherwise it
+     * might have stale data).
+     */
+    return 0;
+}
+
+/*
+ * Reset the pirq_dpci->dom parameter to NULL.
+ *
+ * This function checks the different states to make sure it can do it
+ * at the right time. If it unschedules the 'hvm_dirq_assist' from running
+ * it also refcounts (which is what the softirq would have done) properly.
+ */
+static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+{
+    struct domain *d = pirq_dpci->dom;
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    {
+    case (1 << STATE_SCHED):
+        /*
+         * We are going to try to de-schedule the softirq before it goes in
+         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
+         */
+        put_domain(d);
+        /* fallthrough. */
+    case (1 << STATE_RUN):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED):
+        /*
+         * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
+         * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
+         * in local variable before it sets STATE_RUN - and therefore will not
+         * dereference '->dom' which would crash.
+         */
+        pirq_dpci->dom = NULL;
+        break;
+    }
+}
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -40,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->masked = 0;
+        pirq_dpci->state = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -101,6 +203,7 @@ int pt_irq_create_bind(
     if ( pirq < 0 || pirq >= d->nr_pirqs )
         return -EINVAL;
 
+ restart:
     spin_lock(&d->event_lock);
 
     hvm_irq_dpci = domain_get_irq_dpci(d);
@@ -127,7 +230,20 @@ int pt_irq_create_bind(
         return -ENOMEM;
     }
     pirq_dpci = pirq_dpci(info);
-
+    /*
+     * A crude 'while' loop with us dropping the spinlock and giving
+     * the softirq_dpci a chance to run.
+     * We MUST check for this condition as the softirq could be scheduled
+     * and hasn't run yet. Note that this code replaced tasklet_kill which
+     * would have spun forever and would do the same thing (wait to flush out
+     * outstanding hvm_dirq_assist calls.
+     */
+    if ( pt_pirq_softirq_active(pirq_dpci) )
+    {
+        spin_unlock(&d->event_lock);
+        cpu_relax();
+        goto restart;
+    }
     switch ( pt_irq_bind->irq_type )
     {
     case PT_IRQ_TYPE_MSI:
@@ -159,7 +275,16 @@ int pt_irq_create_bind(
             {
                 rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
                 if ( unlikely(rc) )
+                {
                     pirq_guest_unbind(d, info);
+                    /*
+                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
+                     * an interrupt can be scheduled. No more of them are going
+                     * to be scheduled but we must deal with the one that may be
+                     * in the queue.
+                     */
+                    pt_pirq_softirq_reset(pirq_dpci);
+                }
             }
             if ( unlikely(rc) )
             {
@@ -269,6 +394,10 @@ int pt_irq_create_bind(
             {
                 if ( pt_irq_need_timer(pirq_dpci->flags) )
                     kill_timer(&pirq_dpci->timer);
+                /*
+                 * There is no path for __do_IRQ to schedule softirq as
+                 * IRQ_GUEST is not set. As such we can reset 'dom' directly.
+                 */
                 pirq_dpci->dom = NULL;
                 list_del(&girq->list);
                 list_del(&digl->list);
@@ -402,8 +531,13 @@ int pt_irq_destroy_bind(
         msixtbl_pt_unregister(d, pirq);
         if ( pt_irq_need_timer(pirq_dpci->flags) )
             kill_timer(&pirq_dpci->timer);
-        pirq_dpci->dom   = NULL;
         pirq_dpci->flags = 0;
+        /*
+         * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
+         * call to pt_pirq_softirq_reset.
+         */
+        pt_pirq_softirq_reset(pirq_dpci);
+
         pirq_cleanup_check(pirq, d);
     }
 
@@ -426,14 +560,12 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
-    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    if ( !dpci->flags )
+    if ( !dpci->flags && !pt_pirq_softirq_active(dpci) )
     {
-        tasklet_kill(&dpci->tasklet);
         dpci->dom = NULL;
         return 1;
     }
@@ -476,8 +608,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
-    pirq_dpci->masked = 1;
-    tasklet_schedule(&pirq_dpci->tasklet);
+    raise_softirq_for(pirq_dpci);
     return 1;
 }
 
@@ -531,28 +662,12 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static void hvm_dirq_assist(unsigned long arg)
+static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
 {
-    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
-    struct domain *d = pirq_dpci->dom;
-
-    /*
-     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
-     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
-     *
-     * And '->dom' gets cleared later in the destroy path. We exit and clear
-     * 'masked' - which is OK as later in this code we would
-     * do nothing except clear the ->masked field anyhow.
-     */
-    if ( !d )
-    {
-        pirq_dpci->masked = 0;
-        return;
-    }
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( test_and_clear_bool(pirq_dpci->masked) )
+    if ( pirq_dpci->state )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
@@ -654,3 +769,83 @@ void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
 unlock:
     spin_unlock(&d->event_lock);
 }
+
+/*
+ * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
+ * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
+ */
+static void dpci_softirq(void)
+{
+    unsigned int cpu = smp_processor_id();
+    LIST_HEAD(our_list);
+
+    local_irq_disable();
+    list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
+    local_irq_enable();
+
+    while ( !list_empty(&our_list) )
+    {
+        struct hvm_pirq_dpci *pirq_dpci;
+        struct domain *d;
+
+        pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
+        list_del(&pirq_dpci->softirq_list);
+
+        d = pirq_dpci->dom;
+        smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
+        if ( test_and_set_bit(STATE_RUN, &pirq_dpci->state) )
+            BUG();
+        /*
+         * The one who clears STATE_SCHED MUST refcount the domain.
+         */
+        if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )
+        {
+            hvm_dirq_assist(d, pirq_dpci);
+            put_domain(d);
+        }
+        clear_bit(STATE_RUN, &pirq_dpci->state);
+    }
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        /*
+         * On CPU_DYING this callback is called (on the CPU that is dying)
+         * with an possible HVM_DPIC_SOFTIRQ pending - at which point we can
+         * clear out any outstanding domains (by the virtue of the idle loop
+         * calling the softirq later). In CPU_DEAD case the CPU is deaf and
+         * there are no pending softirqs for us to handle so we can chill.
+         */
+        ASSERT(list_empty(&per_cpu(dpci_list, cpu)));
+        break;
+    }
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback,
+};
+
+static int __init setup_dpci_softirq(void)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu(cpu)
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+
+    open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+__initcall(setup_dpci_softirq);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 81e8a3a..78c6977 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,40 +767,51 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
-    tasklet_kill(&pirq_dpci->tasklet);
-
-    return 0;
+    return pt_pirq_softirq_active(pirq_dpci) ? -ERESTART : 0;
 }
 
-static void pci_clean_dpci_irqs(struct domain *d)
+static int pci_clean_dpci_irqs(struct domain *d)
 {
     struct hvm_irq_dpci *hvm_irq_dpci = NULL;
 
     if ( !iommu_enabled )
-        return;
+        return 0;
 
     if ( !is_hvm_domain(d) )
-        return;
+        return 0;
 
     spin_lock(&d->event_lock);
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+        int ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+
+        if ( ret )
+        {
+            spin_unlock(&d->event_lock);
+            return ret;
+        }
 
         d->arch.hvm_domain.irq.dpci = NULL;
         free_hvm_irq_dpci(hvm_irq_dpci);
     }
     spin_unlock(&d->event_lock);
+    return 0;
 }
 
-void pci_release_devices(struct domain *d)
+int pci_release_devices(struct domain *d)
 {
     struct pci_dev *pdev;
     u8 bus, devfn;
+    int ret;
 
     spin_lock(&pcidevs_lock);
-    pci_clean_dpci_irqs(d);
+    ret = pci_clean_dpci_irqs(d);
+    if ( ret )
+    {
+        spin_unlock(&pcidevs_lock);
+        return ret;
+    }
     while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
     {
         bus = pdev->bus;
@@ -811,6 +822,8 @@ void pci_release_devices(struct domain *d)
                    PCI_SLOT(devfn), PCI_FUNC(devfn));
     }
     spin_unlock(&pcidevs_lock);
+
+    return 0;
 }
 
 #define PCI_CLASS_BRIDGE_HOST    0x0600
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 7225dea..ec787d6 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -7,7 +7,8 @@
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
-#define NR_ARCH_SOFTIRQS       5
+#define HVM_DPCI_SOFTIRQ       (NR_COMMON_SOFTIRQS + 5)
+#define NR_ARCH_SOFTIRQS       6
 
 bool_t arch_skip_send_event_check(unsigned int cpu);
 
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 94a550a..9709397 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -93,13 +93,13 @@ struct hvm_irq_dpci {
 /* Machine IRQ to guest device/intx mapping. */
 struct hvm_pirq_dpci {
     uint32_t flags;
-    bool_t masked;
+    unsigned int state;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
-    struct tasklet tasklet;
+    struct list_head softirq_list;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
@@ -109,6 +109,7 @@ int pt_pirq_iterate(struct domain *d,
                               struct hvm_pirq_dpci *, void *arg),
                     void *arg);
 
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *);
 /* Modify state of a PCI INTx wire. */
 void hvm_pci_intx_assert(
     struct domain *d, unsigned int device, unsigned int intx);
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 91520bc..5f295f3 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -99,7 +99,7 @@ struct pci_dev *pci_lock_domain_pdev(
 
 void setup_hwdom_pci_devices(struct domain *,
                             int (*)(u8 devfn, struct pci_dev *));
-void pci_release_devices(struct domain *d);
+int pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
 const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 02:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 02:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoNax-0008RK-IQ; Wed, 12 Nov 2014 02:23:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoNaw-0008R5-72
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 02:23:42 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	25/92-22737-DA4C2645; Wed, 12 Nov 2014 02:23:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415759019!7774831!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10704 invoked from network); 12 Nov 2014 02:23:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 02:23:40 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAC2NWG3010155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 02:23:33 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC2NVsC009781
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 02:23:32 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC2NUcg002598; Wed, 12 Nov 2014 02:23:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 18:23:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 32C6511489A; Tue, 11 Nov 2014 21:23:29 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Tue, 11 Nov 2014 21:23:22 -0500
Message-Id: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [PATCH v10 for-xen-4.5] Fix interrupt latency of HVM
	PCI passthrough 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Changelog:
since v9 [http://lists.xen.org/archives/html/xen-devel/2014-11/msg00224.html]
 - Fixed up comments,
 - Added Reviewed-by
since v8 (http://lists.xen.org/archives/html/xen-devel/2014-10/msg02564.html)
 - Went back-n-forth on remote softirq, fixed styleguide violations.
 - Moved call to pt_pirq_softirq_reset in pt_irq_create_bind
 - Removed 'case default'
 - Streamlined 'pci_clean_dpci_irqs' return usage.
since v7 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg04385.html)
 - Put ref-counting back, added two bits to allow ref-counting from other places.
since v6 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg03208.html)
 - Squashed #1 + #2.
 - Added more comments, redid it based on Jan's feedback.
since v5 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg02868.html)
 - Redid the series based on Jan's feedback
since v4
(http://lists.xen.org/archives/html/xen-devel/2014-09/msg01676.html):
 - Ditch the domain centric mechansim.
 - Fix issues raised by Jan.


The patches are an performance bug-fixes for PCI passthrough for machines
with many sockets. On those machines we have observed awful latency issues
with interrupts and with high steal time on idle guests. The root cause
was that the tasklet lock which was shared across all sockets. Each interrupt
that was to be delivered to a guest took the tasket lock - and with many
guests and many PCI passthrough devices - the performance and latency were
atrocious. These two patches fix the outstanding issues.

These patches are also available on my git tree:

 git://xenbits.xen.org/people/konradwilk/xen.git dpci.v10


 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 282 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  29 +++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 283 insertions(+), 42 deletions(-)

Konrad Rzeszutek Wilk (2):
      dpci: Move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model.
      dpci: Replace tasklet with an softirq



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 02:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 02:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoNay-0008RS-1H; Wed, 12 Nov 2014 02:23:44 +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 1XoNaw-0008R6-5n
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 02:23:42 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	23/30-27785-DA4C2645; Wed, 12 Nov 2014 02:23:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415759019!11925137!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24564 invoked from network); 12 Nov 2014 02:23:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 02:23:40 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAC2NWPZ010156
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 02:23:33 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC2NVtR002621
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 02:23:32 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC2NUNo003238; Wed, 12 Nov 2014 02:23:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 18:23:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6595B11489E; Tue, 11 Nov 2014 21:23:29 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Tue, 11 Nov 2014 21:23:24 -0500
Message-Id: <1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet with
	an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The existing tasklet mechanism has a single global
spinlock that is taken every-time the global list
is touched. And we use this lock quite a lot - when
we call do_tasklet_work which is called via an softirq
and from the idle loop. We take the lock on any
operation on the tasklet_list.

The problem we are facing is that there are quite a lot of
tasklets scheduled. The most common one that is invoked is
the one injecting the VIRQ_TIMER in the guest. Guests
are not insane and don't set the one-shot or periodic
clocks to be in sub 1ms intervals (causing said tasklet
to be scheduled for such small intervalls).

The problem appears when PCI passthrough devices are used
over many sockets and we have an mix of heavy-interrupt
guests and idle guests. The idle guests end up seeing
1/10 of its RUNNING timeslice eaten by the hypervisor
(and 40% steal time).

The mechanism by which we inject PCI interrupts is by
hvm_do_IRQ_dpci which schedules the hvm_dirq_assist
tasklet every time an interrupt is received.
The callchain is:

_asm_vmexit_handler
 -> vmx_vmexit_handler
    ->vmx_do_extint
        -> do_IRQ
            -> __do_IRQ_guest
                -> hvm_do_IRQ_dpci
                   tasklet_schedule(&dpci->dirq_tasklet);
                   [takes lock to put the tasklet on]

[later on the schedule_tail is invoked which is 'vmx_do_resume']

vmx_do_resume
 -> vmx_asm_do_vmentry
        -> call vmx_intr_assist
          -> vmx_process_softirqs
            -> do_softirq
              [executes the tasklet function, takes the
               lock again]

While on other CPUs they might be sitting in a idle loop
and invoked to deliver an VIRQ_TIMER, which also ends
up taking the lock twice: first to schedule the
v->arch.hvm_vcpu.assert_evtchn_irq_tasklet (accounted to
the guests' BLOCKED_state); then to execute it - which is
accounted for in the guest's RUNTIME_state.

The end result is that on a 8 socket machine with
PCI passthrough, where four sockets are busy with interrupts,
and the other sockets have idle guests - we end up with
the idle guests having around 40% steal time and 1/10
of its timeslice (3ms out of 30 ms) being tied up
taking the lock. The latency of the PCI interrupts delieved
to guest is also hindered.

With this patch the problem disappears completly.
That is removing the lock for the PCI passthrough use-case
(the 'hvm_dirq_assist' case) by not using tasklets at all.

The patch is simple - instead of scheduling an tasklet
we schedule our own softirq - HVM_DPCI_SOFTIRQ, which will
take care of running 'hvm_dirq_assist'. The information we need
on each CPU is which 'struct hvm_pirq_dpci' structure the
'hvm_dirq_assist' needs to run on. That is simple solved by
threading the 'struct hvm_pirq_dpci' through a linked list.
The rule of only running one 'hvm_dirq_assist' for only
one 'hvm_pirq_dpci' is also preserved by having
'schedule_dpci_for' ignore any subsequent calls for an domain
which has already been scheduled.

== Code details ==

Most of the code complexity comes from the '->dom' field
in the 'hvm_pirq_dpci' structure. We use it for ref-counting
and as such it MUST be valid as long as STATE_SCHED bit is
set. Whoever clears the STATE_SCHED bit does the ref-counting
and can also reset the '->dom' field.

To compound the complexity, there are multiple points where the
'hvm_pirq_dpci' structure is reset or re-used. Initially
(first time the domain uses the pirq), the 'hvm_pirq_dpci->dom'
field is set to NULL as it is allocated. On subsequent calls
in to 'pt_irq_create_bind' the ->dom is whatever it had last time.

As this is the initial call (which QEMU ends up calling when the
guest writes an vector value in the MSI field) we MUST set the
'->dom' to a the proper structure (otherwise we cannot do
proper ref-counting).

The mechanism to tear it down is more complex as there
are three ways it can be executed. To make it simpler
everything revolves around 'pt_pirq_softirq_active'. If it
returns -EAGAIN that means there is an outstanding softirq
that needs to finish running before we can continue tearing
down. With that in mind:

a) pci_clean_dpci_irq. This gets called when the guest is
   being destroyed. We end up calling 'pt_pirq_softirq_active'
   to see if it is OK to continue the destruction.

   The scenarios in which the 'struct pirq' (and subsequently
   the 'hvm_pirq_dpci') gets destroyed is when:

   - guest did not use the pirq at all after setup.
   - guest did use pirq, but decided to mask and left it in that
     state.
   - guest did use pirq, but crashed.

   In all of those scenarios we end up calling
   'pt_pirq_softirq_active' to check if the softirq is still
   active. Read below on the 'pt_pirq_softirq_active' loop.

b) pt_irq_destroy_bind (guest disables the MSI). We double-check
   that the softirq has run by piggy-backing on the existing
   'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
   We add the extra call to 'pt_pirq_softirq_active' in
   'pt_pirq_cleanup_check'.

   NOTE: Guests that use event channels unbind first the
   event channel from PIRQs, so the 'pt_pirq_cleanup_check'
   won't be called as 'event' is set to zero. In that case
   we either clean it up via the a) or c) mechanism.

   There is an extra scenario regardless of 'event' being
   set or not: the guest did 'pt_irq_destroy_bind' while an
   interrupt was triggered and softirq was scheduled (but had not
   been run). It is OK to still run the softirq as
   hvm_dirq_assist won't do anything (as the flags are
   set to zero). However we will try to deschedule the
   softirq if we can (by clearing the STATE_SCHED bit and us
   doing the ref-counting).

c) pt_irq_create_bind (not a typo). The scenarios are:

     - guest disables the MSI and then enables it
       (rmmod and modprobe in a loop). We call 'pt_pirq_reset'
       which checks to see if the softirq has been scheduled.
       Imagine the 'b)' with interrupts in flight and c) getting
       called in a loop.

We will spin up on 'pt_pirq_is_active' (at the start of the
'pt_irq_create_bind') with the event_lock spinlock dropped and
waiting (cpu_relax). We cannot call 'process_pending_softirqs' as it
might result in a dead-lock. hvm_dirq_assist will be executed
and then the softirq will clear 'state' which signals that that we
can re-use the 'hvm_pirq_dpci' structure. In case this softirq
is scheduled on a remote CPU the softirq will run on it as the
semantics behind an softirq is that it will execute within the
guest interruption.

     - we hit once the error paths in 'pt_irq_create_bind' while
       an interrupt was triggered and softirq was scheduled.

If the softirq is in STATE_RUN that means it is executing and we should
let it continue on. We can clear the '->dom' field as the softirq
has stashed it beforehand. If the softirq is STATE_SCHED and
we are successful in clearing it, we do the ref-counting and
clear the '->dom' field. Otherwise we let the softirq continue
on and the '->dom' field is left intact. The clearing of
the '->dom' is left to a), b) or again c) case.

Note that in both cases the 'flags' variable is cleared so
hvm_dirq_assist won't actually do anything.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: Jan Beulich <JBeulich@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

---
v2: On top of ref-cnts also have wait loop for the outstanding
    'struct domain' that need to be processed.
v3: Add -ERETRY, fix up StyleGuide issues
v4: Clean it up mode, redo per_cpu, this_cpu logic
v5: Instead of threading struct domain, use hvm_pirq_dpci.
v6: Ditch the 'state' bit, expand description, simplify
    softirq and teardown sequence.
v7: Flesh out the comments. Drop the use of domain refcounts
v8: Add two bits (STATE_[SCHED|RUN]) to allow refcounts.
v9: Use cmpxchg, ASSSERT, fix up comments per Jan.
v10: Fix up issues spotted by Jan.
v11: IPI the remote CPU (once) if it it has the softirq scheduled.
v12: Remove the IPI for the remote CPU as the sofitrq mechanism does that.
v13: Clarify comments.
v14: Add Reviewed-by
---
 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 251 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  31 ++++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 254 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..73d01bb 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1965,7 +1965,9 @@ int domain_relinquish_resources(struct domain *d)
     switch ( d->arch.relmem )
     {
     case RELMEM_not_started:
-        pci_release_devices(d);
+        ret = pci_release_devices(d);
+        if ( ret )
+            return ret;
 
         /* Tear down paging-assistance stuff. */
         ret = paging_teardown(d);
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index dceb17e..b61dbd6 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -20,14 +20,116 @@
 
 #include <xen/event.h>
 #include <xen/iommu.h>
+#include <xen/cpu.h>
 #include <xen/irq.h>
 #include <asm/hvm/irq.h>
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
-#include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long arg);
+static DEFINE_PER_CPU(struct list_head, dpci_list);
+
+/*
+ * These two bit states help to safely schedule, deschedule, and wait until
+ * the softirq has finished.
+ *
+ * The semantics behind these two bits is as follow:
+ *  - STATE_SCHED - whoever modifies it has to ref-count the domain (->dom).
+ *  - STATE_RUN - only softirq is allowed to set and clear it. If it has
+ *      been set hvm_dirq_assist will RUN with a saved value of the
+ *      'struct domain' copied from 'pirq_dpci->dom' before STATE_RUN was set.
+ *
+ * The usual states are: STATE_SCHED(set) -> STATE_RUN(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(unset).
+ *
+ * However the states can also diverge such as: STATE_SCHED(set) ->
+ * STATE_SCHED(unset) -> STATE_RUN(set) -> STATE_RUN(unset). That means
+ * the 'hvm_dirq_assist' never run and that the softirq did not do any
+ * ref-counting.
+ */
+
+enum {
+    STATE_SCHED,
+    STATE_RUN
+};
+
+/*
+ * This can be called multiple times, but the softirq is only raised once.
+ * That is until the STATE_SCHED state has been cleared. The state can be
+ * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
+ * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
+ * the softirq had a chance to run).
+ */
+static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
+{
+    unsigned long flags;
+
+    if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+        return;
+
+    get_knownalive_domain(pirq_dpci->dom);
+
+    local_irq_save(flags);
+    list_add_tail(&pirq_dpci->softirq_list, &this_cpu(dpci_list));
+    local_irq_restore(flags);
+
+    raise_softirq(HVM_DPCI_SOFTIRQ);
+}
+
+/*
+ * If we are racing with softirq_dpci (STATE_SCHED) we return
+ * true. Otherwise we return false.
+ *
+ * If it is false, it is the callers responsibility to make sure
+ * that the softirq (with the event_lock dropped) has ran.
+ */
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
+{
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+        return 1;
+
+    /*
+     * If in the future we would call 'raise_softirq_for' right away
+     * after 'pt_pirq_softirq_active' we MUST reset the list (otherwise it
+     * might have stale data).
+     */
+    return 0;
+}
+
+/*
+ * Reset the pirq_dpci->dom parameter to NULL.
+ *
+ * This function checks the different states to make sure it can do it
+ * at the right time. If it unschedules the 'hvm_dirq_assist' from running
+ * it also refcounts (which is what the softirq would have done) properly.
+ */
+static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+{
+    struct domain *d = pirq_dpci->dom;
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    {
+    case (1 << STATE_SCHED):
+        /*
+         * We are going to try to de-schedule the softirq before it goes in
+         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
+         */
+        put_domain(d);
+        /* fallthrough. */
+    case (1 << STATE_RUN):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED):
+        /*
+         * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
+         * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
+         * in local variable before it sets STATE_RUN - and therefore will not
+         * dereference '->dom' which would crash.
+         */
+        pirq_dpci->dom = NULL;
+        break;
+    }
+}
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -40,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->masked = 0;
+        pirq_dpci->state = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -101,6 +203,7 @@ int pt_irq_create_bind(
     if ( pirq < 0 || pirq >= d->nr_pirqs )
         return -EINVAL;
 
+ restart:
     spin_lock(&d->event_lock);
 
     hvm_irq_dpci = domain_get_irq_dpci(d);
@@ -127,7 +230,20 @@ int pt_irq_create_bind(
         return -ENOMEM;
     }
     pirq_dpci = pirq_dpci(info);
-
+    /*
+     * A crude 'while' loop with us dropping the spinlock and giving
+     * the softirq_dpci a chance to run.
+     * We MUST check for this condition as the softirq could be scheduled
+     * and hasn't run yet. Note that this code replaced tasklet_kill which
+     * would have spun forever and would do the same thing (wait to flush out
+     * outstanding hvm_dirq_assist calls.
+     */
+    if ( pt_pirq_softirq_active(pirq_dpci) )
+    {
+        spin_unlock(&d->event_lock);
+        cpu_relax();
+        goto restart;
+    }
     switch ( pt_irq_bind->irq_type )
     {
     case PT_IRQ_TYPE_MSI:
@@ -159,7 +275,16 @@ int pt_irq_create_bind(
             {
                 rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
                 if ( unlikely(rc) )
+                {
                     pirq_guest_unbind(d, info);
+                    /*
+                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
+                     * an interrupt can be scheduled. No more of them are going
+                     * to be scheduled but we must deal with the one that may be
+                     * in the queue.
+                     */
+                    pt_pirq_softirq_reset(pirq_dpci);
+                }
             }
             if ( unlikely(rc) )
             {
@@ -269,6 +394,10 @@ int pt_irq_create_bind(
             {
                 if ( pt_irq_need_timer(pirq_dpci->flags) )
                     kill_timer(&pirq_dpci->timer);
+                /*
+                 * There is no path for __do_IRQ to schedule softirq as
+                 * IRQ_GUEST is not set. As such we can reset 'dom' directly.
+                 */
                 pirq_dpci->dom = NULL;
                 list_del(&girq->list);
                 list_del(&digl->list);
@@ -402,8 +531,13 @@ int pt_irq_destroy_bind(
         msixtbl_pt_unregister(d, pirq);
         if ( pt_irq_need_timer(pirq_dpci->flags) )
             kill_timer(&pirq_dpci->timer);
-        pirq_dpci->dom   = NULL;
         pirq_dpci->flags = 0;
+        /*
+         * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
+         * call to pt_pirq_softirq_reset.
+         */
+        pt_pirq_softirq_reset(pirq_dpci);
+
         pirq_cleanup_check(pirq, d);
     }
 
@@ -426,14 +560,12 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
-    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    if ( !dpci->flags )
+    if ( !dpci->flags && !pt_pirq_softirq_active(dpci) )
     {
-        tasklet_kill(&dpci->tasklet);
         dpci->dom = NULL;
         return 1;
     }
@@ -476,8 +608,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
-    pirq_dpci->masked = 1;
-    tasklet_schedule(&pirq_dpci->tasklet);
+    raise_softirq_for(pirq_dpci);
     return 1;
 }
 
@@ -531,28 +662,12 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static void hvm_dirq_assist(unsigned long arg)
+static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
 {
-    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
-    struct domain *d = pirq_dpci->dom;
-
-    /*
-     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
-     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
-     *
-     * And '->dom' gets cleared later in the destroy path. We exit and clear
-     * 'masked' - which is OK as later in this code we would
-     * do nothing except clear the ->masked field anyhow.
-     */
-    if ( !d )
-    {
-        pirq_dpci->masked = 0;
-        return;
-    }
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( test_and_clear_bool(pirq_dpci->masked) )
+    if ( pirq_dpci->state )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
@@ -654,3 +769,83 @@ void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
 unlock:
     spin_unlock(&d->event_lock);
 }
+
+/*
+ * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
+ * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
+ */
+static void dpci_softirq(void)
+{
+    unsigned int cpu = smp_processor_id();
+    LIST_HEAD(our_list);
+
+    local_irq_disable();
+    list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
+    local_irq_enable();
+
+    while ( !list_empty(&our_list) )
+    {
+        struct hvm_pirq_dpci *pirq_dpci;
+        struct domain *d;
+
+        pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
+        list_del(&pirq_dpci->softirq_list);
+
+        d = pirq_dpci->dom;
+        smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
+        if ( test_and_set_bit(STATE_RUN, &pirq_dpci->state) )
+            BUG();
+        /*
+         * The one who clears STATE_SCHED MUST refcount the domain.
+         */
+        if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )
+        {
+            hvm_dirq_assist(d, pirq_dpci);
+            put_domain(d);
+        }
+        clear_bit(STATE_RUN, &pirq_dpci->state);
+    }
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        /*
+         * On CPU_DYING this callback is called (on the CPU that is dying)
+         * with an possible HVM_DPIC_SOFTIRQ pending - at which point we can
+         * clear out any outstanding domains (by the virtue of the idle loop
+         * calling the softirq later). In CPU_DEAD case the CPU is deaf and
+         * there are no pending softirqs for us to handle so we can chill.
+         */
+        ASSERT(list_empty(&per_cpu(dpci_list, cpu)));
+        break;
+    }
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback,
+};
+
+static int __init setup_dpci_softirq(void)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu(cpu)
+        INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+
+    open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+__initcall(setup_dpci_softirq);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 81e8a3a..78c6977 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,40 +767,51 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
-    tasklet_kill(&pirq_dpci->tasklet);
-
-    return 0;
+    return pt_pirq_softirq_active(pirq_dpci) ? -ERESTART : 0;
 }
 
-static void pci_clean_dpci_irqs(struct domain *d)
+static int pci_clean_dpci_irqs(struct domain *d)
 {
     struct hvm_irq_dpci *hvm_irq_dpci = NULL;
 
     if ( !iommu_enabled )
-        return;
+        return 0;
 
     if ( !is_hvm_domain(d) )
-        return;
+        return 0;
 
     spin_lock(&d->event_lock);
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+        int ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
+
+        if ( ret )
+        {
+            spin_unlock(&d->event_lock);
+            return ret;
+        }
 
         d->arch.hvm_domain.irq.dpci = NULL;
         free_hvm_irq_dpci(hvm_irq_dpci);
     }
     spin_unlock(&d->event_lock);
+    return 0;
 }
 
-void pci_release_devices(struct domain *d)
+int pci_release_devices(struct domain *d)
 {
     struct pci_dev *pdev;
     u8 bus, devfn;
+    int ret;
 
     spin_lock(&pcidevs_lock);
-    pci_clean_dpci_irqs(d);
+    ret = pci_clean_dpci_irqs(d);
+    if ( ret )
+    {
+        spin_unlock(&pcidevs_lock);
+        return ret;
+    }
     while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
     {
         bus = pdev->bus;
@@ -811,6 +822,8 @@ void pci_release_devices(struct domain *d)
                    PCI_SLOT(devfn), PCI_FUNC(devfn));
     }
     spin_unlock(&pcidevs_lock);
+
+    return 0;
 }
 
 #define PCI_CLASS_BRIDGE_HOST    0x0600
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 7225dea..ec787d6 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -7,7 +7,8 @@
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
-#define NR_ARCH_SOFTIRQS       5
+#define HVM_DPCI_SOFTIRQ       (NR_COMMON_SOFTIRQS + 5)
+#define NR_ARCH_SOFTIRQS       6
 
 bool_t arch_skip_send_event_check(unsigned int cpu);
 
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 94a550a..9709397 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -93,13 +93,13 @@ struct hvm_irq_dpci {
 /* Machine IRQ to guest device/intx mapping. */
 struct hvm_pirq_dpci {
     uint32_t flags;
-    bool_t masked;
+    unsigned int state;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
-    struct tasklet tasklet;
+    struct list_head softirq_list;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
@@ -109,6 +109,7 @@ int pt_pirq_iterate(struct domain *d,
                               struct hvm_pirq_dpci *, void *arg),
                     void *arg);
 
+bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *);
 /* Modify state of a PCI INTx wire. */
 void hvm_pci_intx_assert(
     struct domain *d, unsigned int device, unsigned int intx);
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 91520bc..5f295f3 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -99,7 +99,7 @@ struct pci_dev *pci_lock_domain_pdev(
 
 void setup_hwdom_pci_devices(struct domain *,
                             int (*)(u8 devfn, struct pci_dev *));
-void pci_release_devices(struct domain *d);
+int pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
 const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 02:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 02:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoNay-0008Ra-Fd; Wed, 12 Nov 2014 02:23:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoNaw-0008R7-8E
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 02:23:42 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	8A/F5-09284-DA4C2645; Wed, 12 Nov 2014 02:23:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415759019!11948794!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2551 invoked from network); 12 Nov 2014 02:23:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 02:23:40 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAC2NW6s010154
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 02:23:33 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAC2NVO7022978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 02:23:32 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC2NUfQ002607; Wed, 12 Nov 2014 02:23:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 18:23:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3D46E11489C; Tue, 11 Nov 2014 21:23:29 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Tue, 11 Nov 2014 21:23:23 -0500
Message-Id: <1415759004-11903-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v10 for-xen-4.5 1/2] dpci: Move from an
	hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 an interrupt for an PCI (or PCIe) passthrough device
is to be sent to a guest, we find the appropiate
'hvm_dirq_dpci' structure for the interrupt (PIRQ), set
a bit (masked), and schedule an tasklet.

Then the 'hvm_dirq_assist' tasklet gets called with the 'struct
domain' from where it iterates over the the radix-tree of
'hvm_dirq_dpci' (from zero to the number of PIRQs allocated)
which are masked to the guest and calls each 'hvm_pirq_assist'.
If the PIRQ has a bit set (masked) it figures out how to
inject the PIRQ to the guest.

This is inefficient and not fair as:
 - We iterate starting at PIRQ 0 and up every time. That means
   the PCIe devices that have lower PIRQs get to be called
   first.
 - If we have many PCIe devices passed in with many PIRQs and
   if most of the time only the highest numbered PIRQ get an
   interrupt (as the initial ones are for control) we end up
   iterating over many PIRQs.

But we could do beter - the 'hvm_dirq_dpci' has the field for
'struct domain', which we can use instead of having to pass in the
'struct domain'.

As such this patch moves the tasklet to the 'struct hvm_dirq_dpci'
and sets the 'dom' field to the domain. We also double-check
that the '->dom' is not reset before using it.

We have to be careful with this as that means we MUST have
'dom' set before pirq_guest_bind() is called. As such
we add the 'pirq_dpci->dom = d;' to cover for such
cases.

The mechanism to tear it down is more complex as there
are two ways it can be executed:

 a) pci_clean_dpci_irq. This gets called when the guest is
    being destroyed. We end up calling 'tasklet_kill'.

    The scenarios in which the 'struct pirq' (and subsequently
    the 'hvm_pirq_dpci') gets destroyed is when:

    - guest did not use the pirq at all after setup.
    - guest did use pirq, but decided to mask and left it in that
      state.
    - guest did use pirq, but crashed.

    In all of those scenarios we end up calling 'tasklet_kill'
    which will spin on the tasklet if it is running.

 b) pt_irq_destroy_bind (guest disables the MSI). We double-check
    that the softirq has run by piggy-backing on the existing
    'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
    We add the extra call to 'pt_pirq_softirq_active' in
    'pt_pirq_cleanup_check'.

    NOTE: Guests that use event channels unbind first the
    event channel from PIRQs, so the 'pt_pirq_cleanup_check'
    won't be called as event is set to zero. In that case
    we either clean it up via the a) mechanism. It is OK
    to re-use the tasklet when 'pt_irq_create_bind' is called
    afterwards.

    There is an extra scenario regardless of event being
    set or not: the guest did 'pt_irq_destroy_bind' while an
    interrupt was triggered and tasklet was scheduled (but had not
    been run). It is OK to still run the tasklet as
    hvm_dirq_assist won't do anything (as the flags are
    set to zero). As such we can exit out of hvm_dirq_assist
    without doing anything.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c  | 75 ++++++++++++++++++++++++++++++-------------
 xen/drivers/passthrough/pci.c |  4 +--
 xen/include/xen/hvm/irq.h     |  2 +-
 3 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 4cd32b5..dceb17e 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -27,7 +27,7 @@
 #include <xen/hvm/irq.h>
 #include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long _d);
+static void hvm_dirq_assist(unsigned long arg);
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -114,9 +114,6 @@ int pt_irq_create_bind(
             spin_unlock(&d->event_lock);
             return -ENOMEM;
         }
-        softirq_tasklet_init(
-            &hvm_irq_dpci->dirq_tasklet,
-            hvm_dirq_assist, (unsigned long)d);
         for ( i = 0; i < NR_HVM_IRQS; i++ )
             INIT_LIST_HEAD(&hvm_irq_dpci->girq[i]);
 
@@ -144,6 +141,18 @@ int pt_irq_create_bind(
                                HVM_IRQ_DPCI_GUEST_MSI;
             pirq_dpci->gmsi.gvec = pt_irq_bind->u.msi.gvec;
             pirq_dpci->gmsi.gflags = pt_irq_bind->u.msi.gflags;
+            /*
+             * 'pt_irq_create_bind' can be called after 'pt_irq_destroy_bind'.
+             * The 'pirq_cleanup_check' which would free the structure is only
+             * called if the event channel for the PIRQ is active. However
+             * OS-es that use event channels usually bind PIRQs to eventds
+             * and unbind them before calling 'pt_irq_destroy_bind' - with the
+             * result that we re-use the 'dpci' structure. This can be
+             * reproduced with unloading and loading the driver for a device.
+             *
+             * As such on every 'pt_irq_create_bind' call we MUST set it.
+             */
+            pirq_dpci->dom = d;
             /* bind after hvm_irq_dpci is setup to avoid race with irq handler*/
             rc = pirq_guest_bind(d->vcpu[0], info, 0);
             if ( rc == 0 && pt_irq_bind->u.msi.gtable )
@@ -156,6 +165,7 @@ int pt_irq_create_bind(
             {
                 pirq_dpci->gmsi.gflags = 0;
                 pirq_dpci->gmsi.gvec = 0;
+                pirq_dpci->dom = NULL;
                 pirq_dpci->flags = 0;
                 pirq_cleanup_check(info, d);
                 spin_unlock(&d->event_lock);
@@ -232,6 +242,7 @@ int pt_irq_create_bind(
         {
             unsigned int share;
 
+            /* MUST be set, as the pirq_dpci can be re-used. */
             pirq_dpci->dom = d;
             if ( pt_irq_bind->irq_type == PT_IRQ_TYPE_MSI_TRANSLATE )
             {
@@ -415,11 +426,18 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
+    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    return !dpci->flags;
+    if ( !dpci->flags )
+    {
+        tasklet_kill(&dpci->tasklet);
+        dpci->dom = NULL;
+        return 1;
+    }
+    return 0;
 }
 
 int pt_pirq_iterate(struct domain *d,
@@ -459,7 +477,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
         return 0;
 
     pirq_dpci->masked = 1;
-    tasklet_schedule(&dpci->dirq_tasklet);
+    tasklet_schedule(&pirq_dpci->tasklet);
     return 1;
 }
 
@@ -513,9 +531,27 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
-                            void *arg)
+static void hvm_dirq_assist(unsigned long arg)
 {
+    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
+    struct domain *d = pirq_dpci->dom;
+
+    /*
+     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
+     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
+     *
+     * And '->dom' gets cleared later in the destroy path. We exit and clear
+     * 'masked' - which is OK as later in this code we would
+     * do nothing except clear the ->masked field anyhow.
+     */
+    if ( !d )
+    {
+        pirq_dpci->masked = 0;
+        return;
+    }
+    ASSERT(d->arch.hvm_domain.irq.dpci);
+
+    spin_lock(&d->event_lock);
     if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
@@ -526,13 +562,17 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
             send_guest_pirq(d, pirq);
 
             if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
-                return 0;
+            {
+                spin_unlock(&d->event_lock);
+                return;
+            }
         }
 
         if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
         {
             vmsi_deliver_pirq(d, pirq_dpci);
-            return 0;
+            spin_unlock(&d->event_lock);
+            return;
         }
 
         list_for_each_entry ( digl, &pirq_dpci->digl_list, list )
@@ -545,7 +585,8 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
         {
             /* for translated MSI to INTx interrupt, eoi as early as possible */
             __msi_pirq_eoi(pirq_dpci);
-            return 0;
+            spin_unlock(&d->event_lock);
+            return;
         }
 
         /*
@@ -558,18 +599,6 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
         ASSERT(pt_irq_need_timer(pirq_dpci->flags));
         set_timer(&pirq_dpci->timer, NOW() + PT_IRQ_TIME_OUT);
     }
-
-    return 0;
-}
-
-static void hvm_dirq_assist(unsigned long _d)
-{
-    struct domain *d = (struct domain *)_d;
-
-    ASSERT(d->arch.hvm_domain.irq.dpci);
-
-    spin_lock(&d->event_lock);
-    pt_pirq_iterate(d, _hvm_dirq_assist, NULL);
     spin_unlock(&d->event_lock);
 }
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1eba833..81e8a3a 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,6 +767,8 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
+    tasklet_kill(&pirq_dpci->tasklet);
+
     return 0;
 }
 
@@ -784,8 +786,6 @@ static void pci_clean_dpci_irqs(struct domain *d)
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        tasklet_kill(&hvm_irq_dpci->dirq_tasklet);
-
         pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
 
         d->arch.hvm_domain.irq.dpci = NULL;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index c89f4b1..94a550a 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -88,7 +88,6 @@ struct hvm_irq_dpci {
     DECLARE_BITMAP(isairq_map, NR_ISAIRQS);
     /* Record of mapped Links */
     uint8_t link_cnt[NR_LINK];
-    struct tasklet dirq_tasklet;
 };
 
 /* Machine IRQ to guest device/intx mapping. */
@@ -100,6 +99,7 @@ struct hvm_pirq_dpci {
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
+    struct tasklet tasklet;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 02:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 02:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoNay-0008Ra-Fd; Wed, 12 Nov 2014 02:23:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoNaw-0008R7-8E
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 02:23:42 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	8A/F5-09284-DA4C2645; Wed, 12 Nov 2014 02:23:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415759019!11948794!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2551 invoked from network); 12 Nov 2014 02:23:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 02:23:40 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAC2NW6s010154
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 02:23:33 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAC2NVO7022978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 02:23:32 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC2NUfQ002607; Wed, 12 Nov 2014 02:23:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 18:23:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3D46E11489C; Tue, 11 Nov 2014 21:23:29 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Tue, 11 Nov 2014 21:23:23 -0500
Message-Id: <1415759004-11903-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v10 for-xen-4.5 1/2] dpci: Move from an
	hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 an interrupt for an PCI (or PCIe) passthrough device
is to be sent to a guest, we find the appropiate
'hvm_dirq_dpci' structure for the interrupt (PIRQ), set
a bit (masked), and schedule an tasklet.

Then the 'hvm_dirq_assist' tasklet gets called with the 'struct
domain' from where it iterates over the the radix-tree of
'hvm_dirq_dpci' (from zero to the number of PIRQs allocated)
which are masked to the guest and calls each 'hvm_pirq_assist'.
If the PIRQ has a bit set (masked) it figures out how to
inject the PIRQ to the guest.

This is inefficient and not fair as:
 - We iterate starting at PIRQ 0 and up every time. That means
   the PCIe devices that have lower PIRQs get to be called
   first.
 - If we have many PCIe devices passed in with many PIRQs and
   if most of the time only the highest numbered PIRQ get an
   interrupt (as the initial ones are for control) we end up
   iterating over many PIRQs.

But we could do beter - the 'hvm_dirq_dpci' has the field for
'struct domain', which we can use instead of having to pass in the
'struct domain'.

As such this patch moves the tasklet to the 'struct hvm_dirq_dpci'
and sets the 'dom' field to the domain. We also double-check
that the '->dom' is not reset before using it.

We have to be careful with this as that means we MUST have
'dom' set before pirq_guest_bind() is called. As such
we add the 'pirq_dpci->dom = d;' to cover for such
cases.

The mechanism to tear it down is more complex as there
are two ways it can be executed:

 a) pci_clean_dpci_irq. This gets called when the guest is
    being destroyed. We end up calling 'tasklet_kill'.

    The scenarios in which the 'struct pirq' (and subsequently
    the 'hvm_pirq_dpci') gets destroyed is when:

    - guest did not use the pirq at all after setup.
    - guest did use pirq, but decided to mask and left it in that
      state.
    - guest did use pirq, but crashed.

    In all of those scenarios we end up calling 'tasklet_kill'
    which will spin on the tasklet if it is running.

 b) pt_irq_destroy_bind (guest disables the MSI). We double-check
    that the softirq has run by piggy-backing on the existing
    'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
    We add the extra call to 'pt_pirq_softirq_active' in
    'pt_pirq_cleanup_check'.

    NOTE: Guests that use event channels unbind first the
    event channel from PIRQs, so the 'pt_pirq_cleanup_check'
    won't be called as event is set to zero. In that case
    we either clean it up via the a) mechanism. It is OK
    to re-use the tasklet when 'pt_irq_create_bind' is called
    afterwards.

    There is an extra scenario regardless of event being
    set or not: the guest did 'pt_irq_destroy_bind' while an
    interrupt was triggered and tasklet was scheduled (but had not
    been run). It is OK to still run the tasklet as
    hvm_dirq_assist won't do anything (as the flags are
    set to zero). As such we can exit out of hvm_dirq_assist
    without doing anything.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c  | 75 ++++++++++++++++++++++++++++++-------------
 xen/drivers/passthrough/pci.c |  4 +--
 xen/include/xen/hvm/irq.h     |  2 +-
 3 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 4cd32b5..dceb17e 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -27,7 +27,7 @@
 #include <xen/hvm/irq.h>
 #include <xen/tasklet.h>
 
-static void hvm_dirq_assist(unsigned long _d);
+static void hvm_dirq_assist(unsigned long arg);
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
@@ -114,9 +114,6 @@ int pt_irq_create_bind(
             spin_unlock(&d->event_lock);
             return -ENOMEM;
         }
-        softirq_tasklet_init(
-            &hvm_irq_dpci->dirq_tasklet,
-            hvm_dirq_assist, (unsigned long)d);
         for ( i = 0; i < NR_HVM_IRQS; i++ )
             INIT_LIST_HEAD(&hvm_irq_dpci->girq[i]);
 
@@ -144,6 +141,18 @@ int pt_irq_create_bind(
                                HVM_IRQ_DPCI_GUEST_MSI;
             pirq_dpci->gmsi.gvec = pt_irq_bind->u.msi.gvec;
             pirq_dpci->gmsi.gflags = pt_irq_bind->u.msi.gflags;
+            /*
+             * 'pt_irq_create_bind' can be called after 'pt_irq_destroy_bind'.
+             * The 'pirq_cleanup_check' which would free the structure is only
+             * called if the event channel for the PIRQ is active. However
+             * OS-es that use event channels usually bind PIRQs to eventds
+             * and unbind them before calling 'pt_irq_destroy_bind' - with the
+             * result that we re-use the 'dpci' structure. This can be
+             * reproduced with unloading and loading the driver for a device.
+             *
+             * As such on every 'pt_irq_create_bind' call we MUST set it.
+             */
+            pirq_dpci->dom = d;
             /* bind after hvm_irq_dpci is setup to avoid race with irq handler*/
             rc = pirq_guest_bind(d->vcpu[0], info, 0);
             if ( rc == 0 && pt_irq_bind->u.msi.gtable )
@@ -156,6 +165,7 @@ int pt_irq_create_bind(
             {
                 pirq_dpci->gmsi.gflags = 0;
                 pirq_dpci->gmsi.gvec = 0;
+                pirq_dpci->dom = NULL;
                 pirq_dpci->flags = 0;
                 pirq_cleanup_check(info, d);
                 spin_unlock(&d->event_lock);
@@ -232,6 +242,7 @@ int pt_irq_create_bind(
         {
             unsigned int share;
 
+            /* MUST be set, as the pirq_dpci can be re-used. */
             pirq_dpci->dom = d;
             if ( pt_irq_bind->irq_type == PT_IRQ_TYPE_MSI_TRANSLATE )
             {
@@ -415,11 +426,18 @@ void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
     INIT_LIST_HEAD(&dpci->digl_list);
     dpci->gmsi.dest_vcpu_id = -1;
+    softirq_tasklet_init(&dpci->tasklet, hvm_dirq_assist, (unsigned long)dpci);
 }
 
 bool_t pt_pirq_cleanup_check(struct hvm_pirq_dpci *dpci)
 {
-    return !dpci->flags;
+    if ( !dpci->flags )
+    {
+        tasklet_kill(&dpci->tasklet);
+        dpci->dom = NULL;
+        return 1;
+    }
+    return 0;
 }
 
 int pt_pirq_iterate(struct domain *d,
@@ -459,7 +477,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
         return 0;
 
     pirq_dpci->masked = 1;
-    tasklet_schedule(&dpci->dirq_tasklet);
+    tasklet_schedule(&pirq_dpci->tasklet);
     return 1;
 }
 
@@ -513,9 +531,27 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
     spin_unlock(&d->event_lock);
 }
 
-static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
-                            void *arg)
+static void hvm_dirq_assist(unsigned long arg)
 {
+    struct hvm_pirq_dpci *pirq_dpci = (struct hvm_pirq_dpci *)arg;
+    struct domain *d = pirq_dpci->dom;
+
+    /*
+     * We can be racing with 'pt_irq_destroy_bind' - with us being scheduled
+     * right before 'pirq_guest_unbind' gets called - but us not yet executed.
+     *
+     * And '->dom' gets cleared later in the destroy path. We exit and clear
+     * 'masked' - which is OK as later in this code we would
+     * do nothing except clear the ->masked field anyhow.
+     */
+    if ( !d )
+    {
+        pirq_dpci->masked = 0;
+        return;
+    }
+    ASSERT(d->arch.hvm_domain.irq.dpci);
+
+    spin_lock(&d->event_lock);
     if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
@@ -526,13 +562,17 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
             send_guest_pirq(d, pirq);
 
             if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
-                return 0;
+            {
+                spin_unlock(&d->event_lock);
+                return;
+            }
         }
 
         if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
         {
             vmsi_deliver_pirq(d, pirq_dpci);
-            return 0;
+            spin_unlock(&d->event_lock);
+            return;
         }
 
         list_for_each_entry ( digl, &pirq_dpci->digl_list, list )
@@ -545,7 +585,8 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
         {
             /* for translated MSI to INTx interrupt, eoi as early as possible */
             __msi_pirq_eoi(pirq_dpci);
-            return 0;
+            spin_unlock(&d->event_lock);
+            return;
         }
 
         /*
@@ -558,18 +599,6 @@ static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
         ASSERT(pt_irq_need_timer(pirq_dpci->flags));
         set_timer(&pirq_dpci->timer, NOW() + PT_IRQ_TIME_OUT);
     }
-
-    return 0;
-}
-
-static void hvm_dirq_assist(unsigned long _d)
-{
-    struct domain *d = (struct domain *)_d;
-
-    ASSERT(d->arch.hvm_domain.irq.dpci);
-
-    spin_lock(&d->event_lock);
-    pt_pirq_iterate(d, _hvm_dirq_assist, NULL);
     spin_unlock(&d->event_lock);
 }
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1eba833..81e8a3a 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,6 +767,8 @@ static int pci_clean_dpci_irq(struct domain *d,
         xfree(digl);
     }
 
+    tasklet_kill(&pirq_dpci->tasklet);
+
     return 0;
 }
 
@@ -784,8 +786,6 @@ static void pci_clean_dpci_irqs(struct domain *d)
     hvm_irq_dpci = domain_get_irq_dpci(d);
     if ( hvm_irq_dpci != NULL )
     {
-        tasklet_kill(&hvm_irq_dpci->dirq_tasklet);
-
         pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
 
         d->arch.hvm_domain.irq.dpci = NULL;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index c89f4b1..94a550a 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -88,7 +88,6 @@ struct hvm_irq_dpci {
     DECLARE_BITMAP(isairq_map, NR_ISAIRQS);
     /* Record of mapped Links */
     uint8_t link_cnt[NR_LINK];
-    struct tasklet dirq_tasklet;
 };
 
 /* Machine IRQ to guest device/intx mapping. */
@@ -100,6 +99,7 @@ struct hvm_pirq_dpci {
     struct domain *dom;
     struct hvm_gmsi_info gmsi;
     struct timer timer;
+    struct tasklet tasklet;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 02:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 02:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoNax-0008RK-IQ; Wed, 12 Nov 2014 02:23:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoNaw-0008R5-72
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 02:23:42 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	25/92-22737-DA4C2645; Wed, 12 Nov 2014 02:23:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415759019!7774831!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10704 invoked from network); 12 Nov 2014 02:23:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 02:23:40 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAC2NWG3010155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 02:23:33 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC2NVsC009781
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 02:23:32 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAC2NUcg002598; Wed, 12 Nov 2014 02:23:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 18:23:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 32C6511489A; Tue, 11 Nov 2014 21:23:29 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: andrew.cooper3@citrix.com, JBeulich@suse.com,
	xen-devel@lists.xenproject.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Date: Tue, 11 Nov 2014 21:23:22 -0500
Message-Id: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [PATCH v10 for-xen-4.5] Fix interrupt latency of HVM
	PCI passthrough 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Changelog:
since v9 [http://lists.xen.org/archives/html/xen-devel/2014-11/msg00224.html]
 - Fixed up comments,
 - Added Reviewed-by
since v8 (http://lists.xen.org/archives/html/xen-devel/2014-10/msg02564.html)
 - Went back-n-forth on remote softirq, fixed styleguide violations.
 - Moved call to pt_pirq_softirq_reset in pt_irq_create_bind
 - Removed 'case default'
 - Streamlined 'pci_clean_dpci_irqs' return usage.
since v7 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg04385.html)
 - Put ref-counting back, added two bits to allow ref-counting from other places.
since v6 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg03208.html)
 - Squashed #1 + #2.
 - Added more comments, redid it based on Jan's feedback.
since v5 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg02868.html)
 - Redid the series based on Jan's feedback
since v4
(http://lists.xen.org/archives/html/xen-devel/2014-09/msg01676.html):
 - Ditch the domain centric mechansim.
 - Fix issues raised by Jan.


The patches are an performance bug-fixes for PCI passthrough for machines
with many sockets. On those machines we have observed awful latency issues
with interrupts and with high steal time on idle guests. The root cause
was that the tasklet lock which was shared across all sockets. Each interrupt
that was to be delivered to a guest took the tasket lock - and with many
guests and many PCI passthrough devices - the performance and latency were
atrocious. These two patches fix the outstanding issues.

These patches are also available on my git tree:

 git://xenbits.xen.org/people/konradwilk/xen.git dpci.v10


 xen/arch/x86/domain.c         |   4 +-
 xen/drivers/passthrough/io.c  | 282 +++++++++++++++++++++++++++++++++++++-----
 xen/drivers/passthrough/pci.c |  29 +++--
 xen/include/asm-x86/softirq.h |   3 +-
 xen/include/xen/hvm/irq.h     |   5 +-
 xen/include/xen/pci.h         |   2 +-
 6 files changed, 283 insertions(+), 42 deletions(-)

Konrad Rzeszutek Wilk (2):
      dpci: Move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model.
      dpci: Replace tasklet with an softirq



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 02:25:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 02:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoNcy-0000HG-EC; Wed, 12 Nov 2014 02:25:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoNcx-0000Gw-2K
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 02:25:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	97/1F-09842-A25C2645; Wed, 12 Nov 2014 02:25:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415759144!4746739!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24451 invoked from network); 12 Nov 2014 02:25:45 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 02:25:45 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAC2OP9p011034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 02:24:26 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAC2OOFT025224
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 02:24:24 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAC2ON5n025203; Wed, 12 Nov 2014 02:24:23 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 18:24:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D58A41148A1; Tue, 11 Nov 2014 21:24:21 -0500 (EST)
Date: Tue, 11 Nov 2014 21:24:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141112022421.GA11959@laptop.dumpdata.com>
References: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix commit xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 08:28:38PM +0000, M A Young wrote:
> The build of xen-4.5.0-rc2 fails if XSM_ENABLE=y due to an inconsistency in
> commit fda1614 "xen/arm: Add support for GICv3 for domU" which uses
> XEN_DOMCTL_configure_domain in xen/xsm/flask/hooks.c and
> xen/xsm/flask/policy/access_vectors but XEN_DOMCTL_arm_configure_domain
> elsewhere.

Ouch! Thank you for catching that.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> 	Michael Young

> In fda1614 ("xen/arm: Add support for GICv3 for domU")
> XEN_DOMCTL_configure_domain is used in xen/xsm/flask/hooks.c and
> xen/xsm/flask/policy/access_vectors but XEN_DOMCTL_arm_configure_domain
> is used elsewhere.
> 
> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
> 
> --- xen-4.5.0-rc2/xen/xsm/flask/hooks.c.orig	2014-11-11 14:40:20.000000000 +0000
> +++ xen-4.5.0-rc2/xen/xsm/flask/hooks.c	2014-11-11 18:46:52.926202919 +0000
> @@ -727,7 +727,7 @@
>      case XEN_DOMCTL_psr_cmt_op:
>          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
>  
> -    case XEN_DOMCTL_configure_domain:
> +    case XEN_DOMCTL_arm_configure_domain:
>          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
>  
>      default:
> --- xen-4.5.0-rc2/xen/xsm/flask/policy/access_vectors.orig	2014-11-11 14:40:20.000000000 +0000
> +++ xen-4.5.0-rc2/xen/xsm/flask/policy/access_vectors	2014-11-11 19:20:41.058175302 +0000
> @@ -102,7 +102,7 @@
>      unpause
>  # XEN_DOMCTL_resumedomain
>      resume
> -# XEN_DOMCTL_createdomain
> +# XEN_DOMCTL_arm_createdomain
>      create
>  # checked in FLASK_RELABEL_DOMAIN for any relabel operation:
>  #  source = the old label of the domain

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 12 02:25:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 02:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoNcy-0000HG-EC; Wed, 12 Nov 2014 02:25:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoNcx-0000Gw-2K
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 02:25:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	97/1F-09842-A25C2645; Wed, 12 Nov 2014 02:25:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415759144!4746739!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24451 invoked from network); 12 Nov 2014 02:25:45 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 02:25:45 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAC2OP9p011034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 02:24:26 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAC2OOFT025224
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 02:24:24 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAC2ON5n025203; Wed, 12 Nov 2014 02:24:23 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Nov 2014 18:24:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D58A41148A1; Tue, 11 Nov 2014 21:24:21 -0500 (EST)
Date: Tue, 11 Nov 2014 21:24:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141112022421.GA11959@laptop.dumpdata.com>
References: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix commit xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 08:28:38PM +0000, M A Young wrote:
> The build of xen-4.5.0-rc2 fails if XSM_ENABLE=y due to an inconsistency in
> commit fda1614 "xen/arm: Add support for GICv3 for domU" which uses
> XEN_DOMCTL_configure_domain in xen/xsm/flask/hooks.c and
> xen/xsm/flask/policy/access_vectors but XEN_DOMCTL_arm_configure_domain
> elsewhere.

Ouch! Thank you for catching that.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> 	Michael Young

> In fda1614 ("xen/arm: Add support for GICv3 for domU")
> XEN_DOMCTL_configure_domain is used in xen/xsm/flask/hooks.c and
> xen/xsm/flask/policy/access_vectors but XEN_DOMCTL_arm_configure_domain
> is used elsewhere.
> 
> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
> 
> --- xen-4.5.0-rc2/xen/xsm/flask/hooks.c.orig	2014-11-11 14:40:20.000000000 +0000
> +++ xen-4.5.0-rc2/xen/xsm/flask/hooks.c	2014-11-11 18:46:52.926202919 +0000
> @@ -727,7 +727,7 @@
>      case XEN_DOMCTL_psr_cmt_op:
>          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
>  
> -    case XEN_DOMCTL_configure_domain:
> +    case XEN_DOMCTL_arm_configure_domain:
>          return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
>  
>      default:
> --- xen-4.5.0-rc2/xen/xsm/flask/policy/access_vectors.orig	2014-11-11 14:40:20.000000000 +0000
> +++ xen-4.5.0-rc2/xen/xsm/flask/policy/access_vectors	2014-11-11 19:20:41.058175302 +0000
> @@ -102,7 +102,7 @@
>      unpause
>  # XEN_DOMCTL_resumedomain
>      resume
> -# XEN_DOMCTL_createdomain
> +# XEN_DOMCTL_arm_createdomain
>      create
>  # checked in FLASK_RELABEL_DOMAIN for any relabel operation:
>  #  source = the old label of the domain

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 12 03:05:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 03: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 1XoOFD-0000qq-Bg; Wed, 12 Nov 2014 03:05:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoOFC-0000ql-7T
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 03:05:18 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	E9/FD-28296-D6EC2645; Wed, 12 Nov 2014 03:05:17 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415761515!7521887!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5263 invoked from network); 12 Nov 2014 03:05:16 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-6.tower-31.messagelabs.com with SMTP;
	12 Nov 2014 03:05:16 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 11 Nov 2014 18:58:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,365,1413270000"; d="scan'208";a="620918797"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by fmsmga001.fm.intel.com with ESMTP; 11 Nov 2014 19:05:13 -0800
Message-ID: <5462CE68.6010709@intel.com>
Date: Wed, 12 Nov 2014 11:05:12 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>	<545354500200007800043D94@mail.emea.novell.com>	<5457174C.8020400@intel.com>	<5457515102000078000443B0@mail.emea.novell.com>	<54574D8F.8060407@intel.com>	<54575E2D0200007800044443@mail.emea.novell.com>	<545767C4.7070806@intel.com>	<5457787002000078000445C7@mail.emea.novell.com>	<54576DF7.8060408@intel.com>	<545784830200007800044627@mail.emea.novell.com>	<54585EAA.20904@intel.com>	<545894610200007800044A5B@mail.emea.novell.com>	<545992A2.8070309@intel.com>	<545A57AD02000078000C1037@mail.emea.novell.com>	<545B3F4A.5070808@intel.com>	<545B562F02000078000453FB@mail.emea.novell.com>	<545C9E97.4040800@intel.com>	<545CB64E02000078000459CD@mail.emea.novell.com>	<5461AD94.2070008@intel.com>
	<5461BF97.1070709@intel.com>	<5461DED50200007800046520@mail.emea.novell.com>	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
In-Reply-To: <5461DA23.6020105@intel.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/11 17:42, Chen, Tiejun wrote:
> On 2014/11/11 17:06, Jan Beulich wrote:
>>>>> On 11.11.14 at 10:03, <JBeulich@suse.com> wrote:
>>>>>> On 11.11.14 at 08:49, <tiejun.chen@intel.com> wrote:
>>>> Unless we move all check inside each callback functions.
>>>
>>> That's what you should do imo, albeit I realize that the comparing
>
> Yes, I can do this in all existing callback functions but I'm somewhat
> afraid when other guys want to introduce new callback function, who can
> guarantee this should be done as well?
>

I don't see any feedback to this point, so I think you still prefer we 
should do all check in the callback function.

I tried to address this but obviously we have to pass each 'pdf' to 
callback functions,

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index af613b9..db4b90f 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -20,12 +20,16 @@ CHECK_mem_access_op;
  struct get_reserved_device_memory {
      struct compat_reserved_device_memory_map map;
      unsigned int used_entries;
+    struct domain *domain;
  };

-static int get_reserved_device_memory(xen_pfn_t start,
-                                      xen_ulong_t nr, void *ctxt)
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+                                      u16 bdf, void *ctxt)
  {
      struct get_reserved_device_memory *grdm = ctxt;
+    u16 pt_bdf;
+    int i;
+    struct domain *d = grdm->domain;

      if ( grdm->used_entries < grdm->map.nr_entries )
      {
@@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
          if ( rdm.start_pfn != start || rdm.nr_pages != nr )
              return -ERANGE;

-        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
-                                     &rdm, 1) )
-            return -EFAULT;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( __copy_to_compat_offset(grdm->map.buffer, 
grdm->used_entries,
+                                         &rdm, 1) )
+                return -EFAULT;
+        }
+        else
+        {
+            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
+            {
+                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
+                                  d->arch.hvm_domain.pcidevs[i].devfn);
+                if ( pt_bdf == bdf )
+                    if ( __copy_to_compat_offset(grdm->map.buffer, 
grdm->used_entries,
+                                                 &rdm, 1) )
+                        return -EFAULT;
+            }
+        }
      }

      ++grdm->used_entries;
@@ -314,6 +333,7 @@ int compat_memory_op(unsigned int cmd, 
XEN_GUEST_HANDLE_PARAM(void) compat)
                  return -EFAULT;

              grdm.used_entries = 0;
+            grdm.domain = current->domain;
              rc = 
iommu_get_reserved_device_memory(get_reserved_device_memory,
                                                    &grdm);

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 2177c56..f5e9c1f 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -696,12 +696,16 @@ out:
  struct get_reserved_device_memory {
      struct xen_reserved_device_memory_map map;
      unsigned int used_entries;
+    struct domain *domain;
  };

-static int get_reserved_device_memory(xen_pfn_t start,
-                                      xen_ulong_t nr, void *ctxt)
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+                                      u16 bdf, void *ctxt)
  {
      struct get_reserved_device_memory *grdm = ctxt;
+    u16 pt_bdf;
+    int i;
+    struct domain *d = grdm->domain;

      if ( grdm->used_entries < grdm->map.nr_entries )
      {
@@ -709,9 +713,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
              .start_pfn = start, .nr_pages = nr
          };

-        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
-                                    &rdm, 1) )
-            return -EFAULT;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( __copy_to_guest_offset(grdm->map.buffer, 
grdm->used_entries,
+                                        &rdm, 1) )
+                return -EFAULT;
+        }
+        else
+        {
+            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
+            {
+                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
+                                  d->arch.hvm_domain.pcidevs[i].devfn);
+                if ( pt_bdf == bdf )
+                    if ( __copy_to_guest_offset(grdm->map.buffer, 
grdm->used_entries,
+                                                &rdm, 1) )
+                        return -EFAULT;
+            }
+        }
      }

      ++grdm->used_entries;
@@ -1139,6 +1158,7 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
              return -EFAULT;

          grdm.used_entries = 0;
+        grdm.domain = current->domain;
          rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
                                                &grdm);

diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 141e735..68da9d0 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -898,11 +898,14 @@ int 
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
      int rc = 0;
+    int i;
+    u16 bdf;

-    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+    for_each_rmrr_device ( rmrr, bdf, i )
      {
          rc = func(PFN_DOWN(rmrr->base_address),
                    PFN_UP(rmrr->end_address) - 
PFN_DOWN(rmrr->base_address),
+                  bdf,
                    ctxt);
          if ( rc )
              break;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 409f6f8..ddea0be 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -120,7 +120,7 @@ void iommu_dt_domain_destroy(struct domain *d);

  struct page_info;

-typedef int iommu_grdm_t(xen_pfn_t start, xen_ulong_t nr, void *ctxt);
+typedef int iommu_grdm_t(xen_pfn_t start, xen_ulong_t nr, u16 bdf, void 
*ctxt);

  struct iommu_ops {
      int (*init)(struct domain *d);

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 03:05:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 03: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 1XoOFD-0000qq-Bg; Wed, 12 Nov 2014 03:05:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoOFC-0000ql-7T
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 03:05:18 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	E9/FD-28296-D6EC2645; Wed, 12 Nov 2014 03:05:17 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415761515!7521887!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5263 invoked from network); 12 Nov 2014 03:05:16 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-6.tower-31.messagelabs.com with SMTP;
	12 Nov 2014 03:05:16 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 11 Nov 2014 18:58:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,365,1413270000"; d="scan'208";a="620918797"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by fmsmga001.fm.intel.com with ESMTP; 11 Nov 2014 19:05:13 -0800
Message-ID: <5462CE68.6010709@intel.com>
Date: Wed, 12 Nov 2014 11:05:12 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>	<545354500200007800043D94@mail.emea.novell.com>	<5457174C.8020400@intel.com>	<5457515102000078000443B0@mail.emea.novell.com>	<54574D8F.8060407@intel.com>	<54575E2D0200007800044443@mail.emea.novell.com>	<545767C4.7070806@intel.com>	<5457787002000078000445C7@mail.emea.novell.com>	<54576DF7.8060408@intel.com>	<545784830200007800044627@mail.emea.novell.com>	<54585EAA.20904@intel.com>	<545894610200007800044A5B@mail.emea.novell.com>	<545992A2.8070309@intel.com>	<545A57AD02000078000C1037@mail.emea.novell.com>	<545B3F4A.5070808@intel.com>	<545B562F02000078000453FB@mail.emea.novell.com>	<545C9E97.4040800@intel.com>	<545CB64E02000078000459CD@mail.emea.novell.com>	<5461AD94.2070008@intel.com>
	<5461BF97.1070709@intel.com>	<5461DED50200007800046520@mail.emea.novell.com>	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
In-Reply-To: <5461DA23.6020105@intel.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/11 17:42, Chen, Tiejun wrote:
> On 2014/11/11 17:06, Jan Beulich wrote:
>>>>> On 11.11.14 at 10:03, <JBeulich@suse.com> wrote:
>>>>>> On 11.11.14 at 08:49, <tiejun.chen@intel.com> wrote:
>>>> Unless we move all check inside each callback functions.
>>>
>>> That's what you should do imo, albeit I realize that the comparing
>
> Yes, I can do this in all existing callback functions but I'm somewhat
> afraid when other guys want to introduce new callback function, who can
> guarantee this should be done as well?
>

I don't see any feedback to this point, so I think you still prefer we 
should do all check in the callback function.

I tried to address this but obviously we have to pass each 'pdf' to 
callback functions,

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index af613b9..db4b90f 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -20,12 +20,16 @@ CHECK_mem_access_op;
  struct get_reserved_device_memory {
      struct compat_reserved_device_memory_map map;
      unsigned int used_entries;
+    struct domain *domain;
  };

-static int get_reserved_device_memory(xen_pfn_t start,
-                                      xen_ulong_t nr, void *ctxt)
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+                                      u16 bdf, void *ctxt)
  {
      struct get_reserved_device_memory *grdm = ctxt;
+    u16 pt_bdf;
+    int i;
+    struct domain *d = grdm->domain;

      if ( grdm->used_entries < grdm->map.nr_entries )
      {
@@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
          if ( rdm.start_pfn != start || rdm.nr_pages != nr )
              return -ERANGE;

-        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
-                                     &rdm, 1) )
-            return -EFAULT;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( __copy_to_compat_offset(grdm->map.buffer, 
grdm->used_entries,
+                                         &rdm, 1) )
+                return -EFAULT;
+        }
+        else
+        {
+            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
+            {
+                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
+                                  d->arch.hvm_domain.pcidevs[i].devfn);
+                if ( pt_bdf == bdf )
+                    if ( __copy_to_compat_offset(grdm->map.buffer, 
grdm->used_entries,
+                                                 &rdm, 1) )
+                        return -EFAULT;
+            }
+        }
      }

      ++grdm->used_entries;
@@ -314,6 +333,7 @@ int compat_memory_op(unsigned int cmd, 
XEN_GUEST_HANDLE_PARAM(void) compat)
                  return -EFAULT;

              grdm.used_entries = 0;
+            grdm.domain = current->domain;
              rc = 
iommu_get_reserved_device_memory(get_reserved_device_memory,
                                                    &grdm);

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 2177c56..f5e9c1f 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -696,12 +696,16 @@ out:
  struct get_reserved_device_memory {
      struct xen_reserved_device_memory_map map;
      unsigned int used_entries;
+    struct domain *domain;
  };

-static int get_reserved_device_memory(xen_pfn_t start,
-                                      xen_ulong_t nr, void *ctxt)
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+                                      u16 bdf, void *ctxt)
  {
      struct get_reserved_device_memory *grdm = ctxt;
+    u16 pt_bdf;
+    int i;
+    struct domain *d = grdm->domain;

      if ( grdm->used_entries < grdm->map.nr_entries )
      {
@@ -709,9 +713,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
              .start_pfn = start, .nr_pages = nr
          };

-        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
-                                    &rdm, 1) )
-            return -EFAULT;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( __copy_to_guest_offset(grdm->map.buffer, 
grdm->used_entries,
+                                        &rdm, 1) )
+                return -EFAULT;
+        }
+        else
+        {
+            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
+            {
+                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
+                                  d->arch.hvm_domain.pcidevs[i].devfn);
+                if ( pt_bdf == bdf )
+                    if ( __copy_to_guest_offset(grdm->map.buffer, 
grdm->used_entries,
+                                                &rdm, 1) )
+                        return -EFAULT;
+            }
+        }
      }

      ++grdm->used_entries;
@@ -1139,6 +1158,7 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
              return -EFAULT;

          grdm.used_entries = 0;
+        grdm.domain = current->domain;
          rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
                                                &grdm);

diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 141e735..68da9d0 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -898,11 +898,14 @@ int 
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
      int rc = 0;
+    int i;
+    u16 bdf;

-    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+    for_each_rmrr_device ( rmrr, bdf, i )
      {
          rc = func(PFN_DOWN(rmrr->base_address),
                    PFN_UP(rmrr->end_address) - 
PFN_DOWN(rmrr->base_address),
+                  bdf,
                    ctxt);
          if ( rc )
              break;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 409f6f8..ddea0be 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -120,7 +120,7 @@ void iommu_dt_domain_destroy(struct domain *d);

  struct page_info;

-typedef int iommu_grdm_t(xen_pfn_t start, xen_ulong_t nr, void *ctxt);
+typedef int iommu_grdm_t(xen_pfn_t start, xen_ulong_t nr, u16 bdf, void 
*ctxt);

  struct iommu_ops {
      int (*init)(struct domain *d);

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 03:22:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 03:22:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoOVQ-00017T-56; Wed, 12 Nov 2014 03:22: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@citrix.com>) id 1XoOVP-00017O-3s
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 03:22:03 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	36/F0-11581-A52D2645; Wed, 12 Nov 2014 03:22:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415762520!7779551!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28983 invoked from network); 12 Nov 2014 03:22:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 03:22:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,366,1413244800"; d="scan'208";a="190390762"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 22:21:58 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoOVK-0000J3-G5;
	Wed, 12 Nov 2014 03:21:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoOVJ-0002NY-W4;
	Wed, 12 Nov 2014 03:21:58 +0000
Date: Wed, 12 Nov 2014 03:21:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31484-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31484: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31484 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31484/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt      4 xen-install                 fail pass in 31471
 test-amd64-i386-xl           14 guest-localmigrate.2        fail pass in 31471
 test-amd64-amd64-xl-winxpsp3 13 guest-localmigrate/x10      fail pass in 31471

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-armhf-armhf-libvirt      9 guest-start           fail in 31471 never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop            fail in 31471 never pass

version targeted for testing:
 linux                206c5f60a3d902bc4b56dab2de3e88de5eb06108
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
430 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 14843 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 Nov 12 03:22:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 03:22:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoOVQ-00017T-56; Wed, 12 Nov 2014 03:22: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@citrix.com>) id 1XoOVP-00017O-3s
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 03:22:03 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	36/F0-11581-A52D2645; Wed, 12 Nov 2014 03:22:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415762520!7779551!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28983 invoked from network); 12 Nov 2014 03:22:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 03:22:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,366,1413244800"; d="scan'208";a="190390762"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 22:21:58 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoOVK-0000J3-G5;
	Wed, 12 Nov 2014 03:21:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoOVJ-0002NY-W4;
	Wed, 12 Nov 2014 03:21:58 +0000
Date: Wed, 12 Nov 2014 03:21:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31484-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31484: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31484 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31484/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt      4 xen-install                 fail pass in 31471
 test-amd64-i386-xl           14 guest-localmigrate.2        fail pass in 31471
 test-amd64-amd64-xl-winxpsp3 13 guest-localmigrate/x10      fail pass in 31471

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-armhf-armhf-libvirt      9 guest-start           fail in 31471 never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop            fail in 31471 never pass

version targeted for testing:
 linux                206c5f60a3d902bc4b56dab2de3e88de5eb06108
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
430 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 14843 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 Nov 12 03:34:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 03: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 1XoOgs-0001Lo-He; Wed, 12 Nov 2014 03:33:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoOgr-0001Lj-1U
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 03:33:53 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	28/BD-08051-025D2645; Wed, 12 Nov 2014 03:33:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415763230!11896413!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19204 invoked from network); 12 Nov 2014 03:33:51 -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;
	12 Nov 2014 03:33:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,366,1413244800"; d="scan'208";a="191836790"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 22:33:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoOgm-0000Mw-Ui;
	Wed, 12 Nov 2014 03:33:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoOgm-0004rA-Kx;
	Wed, 12 Nov 2014 03:33:48 +0000
Date: Wed, 12 Nov 2014 03:33:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31481-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31481: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31481 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31481/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail like 30761

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 seabios              09f876f11743c1143c73a52eb889ae9231f7a5b3
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Hannes Reinecke <hare@suse.de>
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 337 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 Nov 12 03:34:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 03: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 1XoOgs-0001Lo-He; Wed, 12 Nov 2014 03:33:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoOgr-0001Lj-1U
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 03:33:53 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	28/BD-08051-025D2645; Wed, 12 Nov 2014 03:33:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415763230!11896413!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19204 invoked from network); 12 Nov 2014 03:33:51 -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;
	12 Nov 2014 03:33:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,366,1413244800"; d="scan'208";a="191836790"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 11 Nov 2014 22:33:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoOgm-0000Mw-Ui;
	Wed, 12 Nov 2014 03:33:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoOgm-0004rA-Kx;
	Wed, 12 Nov 2014 03:33:48 +0000
Date: Wed, 12 Nov 2014 03:33:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31481-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31481: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31481 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31481/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail like 30761

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 seabios              09f876f11743c1143c73a52eb889ae9231f7a5b3
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Hannes Reinecke <hare@suse.de>
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 337 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 Nov 12 06:24:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 06:24:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoRLk-0002za-1i; Wed, 12 Nov 2014 06:24:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XoRLi-0002zV-0Y
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 06:24:14 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	78/22-25727-D0DF2645; Wed, 12 Nov 2014 06:24:13 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415773452!6321492!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25430 invoked from network); 12 Nov 2014 06:24:12 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-31.messagelabs.com with SMTP;
	12 Nov 2014 06:24:12 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 11 Nov 2014 22:24:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,367,1413270000"; d="scan'208";a="620992444"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 11 Nov 2014 22:24:09 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 12 Nov 2014 14:24:08 +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.3.195.1; Wed, 12 Nov 2014 14:24:08 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.241]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.3]) with mapi id
	14.03.0195.001; Wed, 12 Nov 2014 14:24:06 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [TestDay] Xen-4.5.0 RC1 bug: with "xen_platform_pci=0" option,
	the guest with VT-d device fails to boot up
Thread-Index: Ac/+QTl94+tnk9mnSjC8y2KkymCnJw==
Date: Wed, 12 Nov 2014 06:24:06 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A4C76C@SHSMSX103.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: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: [Xen-devel] [TestDay] Xen-4.5.0 RC1 bug: with "xen_platform_pci=0"
 option, the guest with VT-d device fails to boot up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQoNCkJlc3QgUmVnYXJkcywNClJvYmVydCBIbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KRnJvbTogYnVnemlsbGEtZGFlbW9uQGJ1Z3ppbGxhLnhlbi5vcmcgW21haWx0bzpidWd6aWxs
YS1kYWVtb25AYnVnemlsbGEueGVuLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEy
LCAyMDE0IDk6MjQgQU0NClRvOiBIdSwgUm9iZXJ0DQpTdWJqZWN0OiBbw5DCkcORworDkMKzIDE4
OTNdIMOQwp3DkMK+w5DCsjogd2l0aCAieGVuX3BsYXRmb3JtX3BjaT0wIiBvcHRpb24sIHRoZSBn
dWVzdCB3aXRoIFZULWQgZGV2aWNlIGZhaWxzIHRvIGJvb3QgdXANCg0KL2J1Z3ppbGxhL3Nob3df
YnVnLmNnaT9pZD0xODkzDQoNCiAgICAgICAgICAgU3VtbWFyeTogd2l0aCAieGVuX3BsYXRmb3Jt
X3BjaT0wIiBvcHRpb24sIHRoZSBndWVzdCB3aXRoIFZULWQNCiAgICAgICAgICAgICAgICAgICAg
ZGV2aWNlIGZhaWxzIHRvIGJvb3QgdXANCiAgICAgICAgICAgUHJvZHVjdDogWGVuDQogICAgICAg
ICAgIFZlcnNpb246IHVuc3RhYmxlDQogICAgICAgICAgUGxhdGZvcm06IHg4Ni02NA0KICAgICAg
ICBPUy9WZXJzaW9uOiBMaW51eC0yLjYNCiAgICAgICAgICAgIFN0YXR1czogTkVXDQogICAgICAg
ICAgU2V2ZXJpdHk6IG5vcm1hbA0KICAgICAgICAgIFByaW9yaXR5OiBQMg0KICAgICAgICAgQ29t
cG9uZW50OiBIYXJkd2FyZSBTdXBwb3J0DQogICAgICAgIEFzc2lnbmVkVG86IHhlbi1idWdzQGxp
c3RzLnhlbnNvdXJjZS5jb20NCiAgICAgICAgUmVwb3J0ZWRCeTogc29uZ3Rhb3gubGl1QGludGVs
LmNvbQ0KICAgICAgICAgICAgICAgIENDOiBSb2JlcnQuSHVAaW50ZWwuY29tLCBsb25ndGFveC5w
YW5nQGludGVsLmNvbSwNCiAgICAgICAgICAgICAgICAgICAgZGkuemhlbmdAaW50ZWwuY29tDQog
ICBFc3RpbWF0ZWQgSG91cnM6IDAuMA0KDQoNCkVudmlyb25tZW50Og0KLS0tLS0tLS0tLS0tDQpT
ZXJ2aWNlIEFyY2ggKGlhMzIvaWEzMmUvSUE2NCk6IGlhMzJlDQpHdWVzdCBBcmNoIChpYTMyL2lh
MzJlL0lBNjQpOiBpYTMyZQ0KR3Vlc3QgT1MgVHlwZSAoTGludXgvV2luZG93cyk6aWEzMmVfcmhl
bDZ1Ng0KQ2hhbmdlIFNldDogeGVuLTQuNS1yYzENCkhhcmR3YXJlOiBIU1ctRVANCg0KDQpCdWcg
ZGV0YWlsZWQgZGVzY3JpcHRpb246DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KV2l0aCAi
eGVuX3BsYXRmb3JtX3BjaT0wIiBvcHRpb24sIHRoZSBndWVzdCB3aXRoIFZULWQgZGV2aWNlIGZh
aWxzIHRvIGJvb3QgdXAuDQpXaXRob3V0ICJ4ZW5fcGxhdGZvcm1fcGNpPTAiIG9wdGlvbiwgdGhl
IGd1ZXN0IHdpdGggVlQtZCBkZXZpY2UgYm9vdHMgdXAgd2VsbC4NCnRoZSBjb25zb2xlIHNob3dz
IHRoZSAiQnVzIGRvZXNuJ3QgaGF2ZSBwcm9wZXJ0eSAnYWNwaS1wY2locC1ic2VsJyBzZXQiLg0K
DQoNClJlcHJvZHVjZSBzdGVwczoNCi0tLS0tLS0tLS0tLS0tLS0NCjEuIGJvb3QgdXAgYW4gaWEz
MmVfcmhlbDZ1NiBndWVzdCB3aXRoICJ4ZW5fcGxhdGZvcm1fcGNpPTAgICBwY2k9Wyc4NTowMC4x
J10iDQoyLiB0aGUgZ3Vlc3QgZmFpbHMgdG8gYm9vdCB1cA0KDQpDdXJyZW50IHJlc3VsdDoNCi0t
LS0tLS0tLS0tLS0tLS0NCmd1ZXN0IHdpdGggVlQtZCBmYWlscyB0byBib290IHVwIHdpdGggInhl
bl9wbGF0Zm9ybV9wY2k9MCINCg0KRXhwZWN0ZWQgcmVzdWx0Og0KLS0tLS0tLS0tLS0tLS0tLQ0K
Z3Vlc3Qgd2l0aCBWVC1kIGJvb3QgdXAgd2VsbCB3aXRoICJ4ZW5fcGxhdGZvcm1fcGNpPTAiDQoN
CkJhc2ljIHJvb3QtY2F1c2luZyBsb2c6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbcm9vdEB2
dC1oc3cxIGNhcmxdIyB4bCBjciB4bGV4YW1wbGUuaHZtIA0KUGFyc2luZyBjb25maWcgZnJvbSB4
bGV4YW1wbGUuaHZtDQpsaWJ4bDogZXJyb3I6IGxpYnhsX3FtcC5jOjI4NzpxbXBfaGFuZGxlX2Vy
cm9yX3Jlc3BvbnNlOiByZWNlaXZlZCBhbiBlcnJvcg0KbWVzc2FnZSBmcm9tIFFNUCBzZXJ2ZXI6
IFVuc3VwcG9ydGVkIGJ1cy4gQnVzIGRvZXNuJ3QgaGF2ZSBwcm9wZXJ0eQ0KJ2FjcGktcGNpaHAt
YnNlbCcgc2V0DQpsaWJ4bDogZXJyb3I6IGxpYnhsX2NyZWF0ZS5jOjEzODU6ZG9tY3JlYXRlX2F0
dGFjaF9wY2k6IGxpYnhsX2RldmljZV9wY2lfYWRkDQpmYWlsZWQ6IC0zDQoNCi0tIA0K0J3QsNGB
0YLRgNC+0LnQstCw0L3QtSDQvdCwINCx0YrQs9C/0L7RidCwOiAvYnVnemlsbGEvdXNlcnByZWZz
LmNnaT90YWI9ZW1haWwNCi0tLS0tLS0g0J/QvtC70YPRh9Cw0LLQsNGC0LUg0YLQsNCy0LAg0L/Q
uNGB0LzQviDQt9Cw0YnQvtGC0L46IC0tLS0tLS0NCtCh0YLQtSDQsiDRgdC/0LjRgdGK0LrQsCDQ
otCaINC90LAg0LHRitCzLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Nov 12 06:24:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 06:24:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoRLk-0002za-1i; Wed, 12 Nov 2014 06:24:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XoRLi-0002zV-0Y
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 06:24:14 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	78/22-25727-D0DF2645; Wed, 12 Nov 2014 06:24:13 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415773452!6321492!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25430 invoked from network); 12 Nov 2014 06:24:12 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-31.messagelabs.com with SMTP;
	12 Nov 2014 06:24:12 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 11 Nov 2014 22:24:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,367,1413270000"; d="scan'208";a="620992444"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 11 Nov 2014 22:24:09 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 12 Nov 2014 14:24:08 +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.3.195.1; Wed, 12 Nov 2014 14:24:08 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.241]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.3]) with mapi id
	14.03.0195.001; Wed, 12 Nov 2014 14:24:06 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [TestDay] Xen-4.5.0 RC1 bug: with "xen_platform_pci=0" option,
	the guest with VT-d device fails to boot up
Thread-Index: Ac/+QTl94+tnk9mnSjC8y2KkymCnJw==
Date: Wed, 12 Nov 2014 06:24:06 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A4C76C@SHSMSX103.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: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: [Xen-devel] [TestDay] Xen-4.5.0 RC1 bug: with "xen_platform_pci=0"
 option, the guest with VT-d device fails to boot up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQoNCkJlc3QgUmVnYXJkcywNClJvYmVydCBIbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KRnJvbTogYnVnemlsbGEtZGFlbW9uQGJ1Z3ppbGxhLnhlbi5vcmcgW21haWx0bzpidWd6aWxs
YS1kYWVtb25AYnVnemlsbGEueGVuLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEy
LCAyMDE0IDk6MjQgQU0NClRvOiBIdSwgUm9iZXJ0DQpTdWJqZWN0OiBbw5DCkcORworDkMKzIDE4
OTNdIMOQwp3DkMK+w5DCsjogd2l0aCAieGVuX3BsYXRmb3JtX3BjaT0wIiBvcHRpb24sIHRoZSBn
dWVzdCB3aXRoIFZULWQgZGV2aWNlIGZhaWxzIHRvIGJvb3QgdXANCg0KL2J1Z3ppbGxhL3Nob3df
YnVnLmNnaT9pZD0xODkzDQoNCiAgICAgICAgICAgU3VtbWFyeTogd2l0aCAieGVuX3BsYXRmb3Jt
X3BjaT0wIiBvcHRpb24sIHRoZSBndWVzdCB3aXRoIFZULWQNCiAgICAgICAgICAgICAgICAgICAg
ZGV2aWNlIGZhaWxzIHRvIGJvb3QgdXANCiAgICAgICAgICAgUHJvZHVjdDogWGVuDQogICAgICAg
ICAgIFZlcnNpb246IHVuc3RhYmxlDQogICAgICAgICAgUGxhdGZvcm06IHg4Ni02NA0KICAgICAg
ICBPUy9WZXJzaW9uOiBMaW51eC0yLjYNCiAgICAgICAgICAgIFN0YXR1czogTkVXDQogICAgICAg
ICAgU2V2ZXJpdHk6IG5vcm1hbA0KICAgICAgICAgIFByaW9yaXR5OiBQMg0KICAgICAgICAgQ29t
cG9uZW50OiBIYXJkd2FyZSBTdXBwb3J0DQogICAgICAgIEFzc2lnbmVkVG86IHhlbi1idWdzQGxp
c3RzLnhlbnNvdXJjZS5jb20NCiAgICAgICAgUmVwb3J0ZWRCeTogc29uZ3Rhb3gubGl1QGludGVs
LmNvbQ0KICAgICAgICAgICAgICAgIENDOiBSb2JlcnQuSHVAaW50ZWwuY29tLCBsb25ndGFveC5w
YW5nQGludGVsLmNvbSwNCiAgICAgICAgICAgICAgICAgICAgZGkuemhlbmdAaW50ZWwuY29tDQog
ICBFc3RpbWF0ZWQgSG91cnM6IDAuMA0KDQoNCkVudmlyb25tZW50Og0KLS0tLS0tLS0tLS0tDQpT
ZXJ2aWNlIEFyY2ggKGlhMzIvaWEzMmUvSUE2NCk6IGlhMzJlDQpHdWVzdCBBcmNoIChpYTMyL2lh
MzJlL0lBNjQpOiBpYTMyZQ0KR3Vlc3QgT1MgVHlwZSAoTGludXgvV2luZG93cyk6aWEzMmVfcmhl
bDZ1Ng0KQ2hhbmdlIFNldDogeGVuLTQuNS1yYzENCkhhcmR3YXJlOiBIU1ctRVANCg0KDQpCdWcg
ZGV0YWlsZWQgZGVzY3JpcHRpb246DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KV2l0aCAi
eGVuX3BsYXRmb3JtX3BjaT0wIiBvcHRpb24sIHRoZSBndWVzdCB3aXRoIFZULWQgZGV2aWNlIGZh
aWxzIHRvIGJvb3QgdXAuDQpXaXRob3V0ICJ4ZW5fcGxhdGZvcm1fcGNpPTAiIG9wdGlvbiwgdGhl
IGd1ZXN0IHdpdGggVlQtZCBkZXZpY2UgYm9vdHMgdXAgd2VsbC4NCnRoZSBjb25zb2xlIHNob3dz
IHRoZSAiQnVzIGRvZXNuJ3QgaGF2ZSBwcm9wZXJ0eSAnYWNwaS1wY2locC1ic2VsJyBzZXQiLg0K
DQoNClJlcHJvZHVjZSBzdGVwczoNCi0tLS0tLS0tLS0tLS0tLS0NCjEuIGJvb3QgdXAgYW4gaWEz
MmVfcmhlbDZ1NiBndWVzdCB3aXRoICJ4ZW5fcGxhdGZvcm1fcGNpPTAgICBwY2k9Wyc4NTowMC4x
J10iDQoyLiB0aGUgZ3Vlc3QgZmFpbHMgdG8gYm9vdCB1cA0KDQpDdXJyZW50IHJlc3VsdDoNCi0t
LS0tLS0tLS0tLS0tLS0NCmd1ZXN0IHdpdGggVlQtZCBmYWlscyB0byBib290IHVwIHdpdGggInhl
bl9wbGF0Zm9ybV9wY2k9MCINCg0KRXhwZWN0ZWQgcmVzdWx0Og0KLS0tLS0tLS0tLS0tLS0tLQ0K
Z3Vlc3Qgd2l0aCBWVC1kIGJvb3QgdXAgd2VsbCB3aXRoICJ4ZW5fcGxhdGZvcm1fcGNpPTAiDQoN
CkJhc2ljIHJvb3QtY2F1c2luZyBsb2c6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbcm9vdEB2
dC1oc3cxIGNhcmxdIyB4bCBjciB4bGV4YW1wbGUuaHZtIA0KUGFyc2luZyBjb25maWcgZnJvbSB4
bGV4YW1wbGUuaHZtDQpsaWJ4bDogZXJyb3I6IGxpYnhsX3FtcC5jOjI4NzpxbXBfaGFuZGxlX2Vy
cm9yX3Jlc3BvbnNlOiByZWNlaXZlZCBhbiBlcnJvcg0KbWVzc2FnZSBmcm9tIFFNUCBzZXJ2ZXI6
IFVuc3VwcG9ydGVkIGJ1cy4gQnVzIGRvZXNuJ3QgaGF2ZSBwcm9wZXJ0eQ0KJ2FjcGktcGNpaHAt
YnNlbCcgc2V0DQpsaWJ4bDogZXJyb3I6IGxpYnhsX2NyZWF0ZS5jOjEzODU6ZG9tY3JlYXRlX2F0
dGFjaF9wY2k6IGxpYnhsX2RldmljZV9wY2lfYWRkDQpmYWlsZWQ6IC0zDQoNCi0tIA0K0J3QsNGB
0YLRgNC+0LnQstCw0L3QtSDQvdCwINCx0YrQs9C/0L7RidCwOiAvYnVnemlsbGEvdXNlcnByZWZz
LmNnaT90YWI9ZW1haWwNCi0tLS0tLS0g0J/QvtC70YPRh9Cw0LLQsNGC0LUg0YLQsNCy0LAg0L/Q
uNGB0LzQviDQt9Cw0YnQvtGC0L46IC0tLS0tLS0NCtCh0YLQtSDQsiDRgdC/0LjRgdGK0LrQsCDQ
otCaINC90LAg0LHRitCzLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Nov 12 06:57:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 06:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoRrC-0003bZ-Ni; Wed, 12 Nov 2014 06:56:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoRrB-0003bU-GG
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 06:56:45 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	D7/C0-08051-CA403645; Wed, 12 Nov 2014 06:56:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415775402!11939297!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6241 invoked from network); 12 Nov 2014 06:56:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 06:56:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="190421446"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 01:56:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoRr7-0001Nu-21;
	Wed, 12 Nov 2014 06:56:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoRr6-0007OE-Pd;
	Wed, 12 Nov 2014 06:56:40 +0000
Date: Wed, 12 Nov 2014 06:56:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31491-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31491: 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 31491 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31491/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf      9 guest-start             fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 build-i386-pvops              5 kernel-build            fail baseline untested
 test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-winxpsp3  7 windows-install         fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a

version targeted for testing:
 linux                b0187bd33fba065ec736dc33085914a137d390d3
baseline version:
 linux                206c5f60a3d902bc4b56dab2de3e88de5eb06108

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 06:57:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 06:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoRrC-0003bZ-Ni; Wed, 12 Nov 2014 06:56:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoRrB-0003bU-GG
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 06:56:45 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	D7/C0-08051-CA403645; Wed, 12 Nov 2014 06:56:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415775402!11939297!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6241 invoked from network); 12 Nov 2014 06:56:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 06:56:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="190421446"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 01:56:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoRr7-0001Nu-21;
	Wed, 12 Nov 2014 06:56:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoRr6-0007OE-Pd;
	Wed, 12 Nov 2014 06:56:40 +0000
Date: Wed, 12 Nov 2014 06:56:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31491-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31491: 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 31491 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31491/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf      9 guest-start             fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 build-i386-pvops              5 kernel-build            fail baseline untested
 test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-winxpsp3  7 windows-install         fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a

version targeted for testing:
 linux                b0187bd33fba065ec736dc33085914a137d390d3
baseline version:
 linux                206c5f60a3d902bc4b56dab2de3e88de5eb06108

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 07:00:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 07:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoRup-0003kS-Bt; Wed, 12 Nov 2014 07:00:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XoRun-0003kM-99
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 07:00:29 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A2/A3-08051-C8503645; Wed, 12 Nov 2014 07:00:28 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415775627!11916551!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22906 invoked from network); 12 Nov 2014 07:00:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-27.messagelabs.com with SMTP;
	12 Nov 2014 07:00:27 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 11 Nov 2014 23:00:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="415228435"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by FMSMGA003.fm.intel.com with ESMTP; 11 Nov 2014 22:51:29 -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.3.195.1; Wed, 12 Nov 2014 14:58:50 +0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 12 Nov 2014 14:58:51 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.241]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.242]) with mapi id
	14.03.0195.001; Wed, 12 Nov 2014 14:58:49 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [TestDay] VMX test report for Xen 4.5.0-rc1 
Thread-Index: Ac/+RfUnlQMHJ/IXSw25UV92M40btw==
Date: Wed, 12 Nov 2014 06:58:49 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.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: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi All,

This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.

Test environment:
Xen: Xen 4.5-rc1 
Dom0: Linux kernel 3.17.0
Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP

New bugs(9):
1. with "xen_platform_pci=0" option, the guest with VT-d device fails to boot up
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1893
2. Failed to hotplug a VT-d device with XEN4.5-RC1
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
3. Fail to hot add multi devices to guest
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895
4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
5. Dom0 failed to resume from S3 power state
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897
6. Networking is unavailable after save&restore Windows guest
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
7. Error msg occurred after attaching multi SR-IOV VF device to running guest
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899
8. "xl vcpu-set " will report error when adding vcpus number
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1900
9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901

1 old legacy bug(1):
1. Guest hang after resume from S3
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1828


Best Regards,
Robert

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 07:00:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 07:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoRup-0003kS-Bt; Wed, 12 Nov 2014 07:00:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XoRun-0003kM-99
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 07:00:29 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A2/A3-08051-C8503645; Wed, 12 Nov 2014 07:00:28 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415775627!11916551!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22906 invoked from network); 12 Nov 2014 07:00:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-27.messagelabs.com with SMTP;
	12 Nov 2014 07:00:27 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 11 Nov 2014 23:00:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="415228435"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by FMSMGA003.fm.intel.com with ESMTP; 11 Nov 2014 22:51:29 -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.3.195.1; Wed, 12 Nov 2014 14:58:50 +0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 12 Nov 2014 14:58:51 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.241]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.242]) with mapi id
	14.03.0195.001; Wed, 12 Nov 2014 14:58:49 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [TestDay] VMX test report for Xen 4.5.0-rc1 
Thread-Index: Ac/+RfUnlQMHJ/IXSw25UV92M40btw==
Date: Wed, 12 Nov 2014 06:58:49 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.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: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi All,

This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.

Test environment:
Xen: Xen 4.5-rc1 
Dom0: Linux kernel 3.17.0
Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP

New bugs(9):
1. with "xen_platform_pci=0" option, the guest with VT-d device fails to boot up
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1893
2. Failed to hotplug a VT-d device with XEN4.5-RC1
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
3. Fail to hot add multi devices to guest
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895
4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
5. Dom0 failed to resume from S3 power state
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897
6. Networking is unavailable after save&restore Windows guest
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
7. Error msg occurred after attaching multi SR-IOV VF device to running guest
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899
8. "xl vcpu-set " will report error when adding vcpus number
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1900
9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901

1 old legacy bug(1):
1. Guest hang after resume from S3
  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1828


Best Regards,
Robert

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 08:27:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 08:27:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTGM-00057F-N7; Wed, 12 Nov 2014 08:26:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoTGK-00057A-Tl
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 08:26:49 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	0A/4D-16982-8C913645; Wed, 12 Nov 2014 08:26:48 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415780805!10787021!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10830 invoked from network); 12 Nov 2014 08:26:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 08:26:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="191882131"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 03:26:43 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoTGF-0001ov-Qd;
	Wed, 12 Nov 2014 08:26:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoTGF-0001u8-DP;
	Wed, 12 Nov 2014 08:26:43 +0000
Date: Wed, 12 Nov 2014 08:26:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31489-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31489: 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 31489 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31489/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31473
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31473

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
baseline version:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 08:27:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 08:27:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTGM-00057F-N7; Wed, 12 Nov 2014 08:26:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoTGK-00057A-Tl
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 08:26:49 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	0A/4D-16982-8C913645; Wed, 12 Nov 2014 08:26:48 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415780805!10787021!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10830 invoked from network); 12 Nov 2014 08:26:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 08:26:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="191882131"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 03:26:43 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoTGF-0001ov-Qd;
	Wed, 12 Nov 2014 08:26:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoTGF-0001u8-DP;
	Wed, 12 Nov 2014 08:26:43 +0000
Date: Wed, 12 Nov 2014 08:26:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31489-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31489: 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 31489 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31489/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31473
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31473

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
baseline version:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 08:38:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 08:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTRE-0005Kv-1t; Wed, 12 Nov 2014 08:38:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoTRC-0005Kq-4h
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 08:38:02 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	7E/3B-17958-96C13645; Wed, 12 Nov 2014 08:38:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415781480!10819527!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3064 invoked from network); 12 Nov 2014 08:38:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 08:38:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 08:37:59 +0000
Message-Id: <54632A760200007800046ACC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 08:37:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
In-Reply-To: <5462B9AC.6050704@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 02:36, <tiejun.chen@intel.com> wrote:
> On 2014/11/11 18:07, Jan Beulich wrote:
>>>>> On 11.11.14 at 10:42, <tiejun.chen@intel.com> wrote:
>>> On 2014/11/11 17:06, Jan Beulich wrote:
>>>> Part of which would involve re-considering whether device
>>>> assignment shouldn't be done before memory population in the
>>>> tool stack.
>>>
>>> Yes, after we introduce this new domctl, we just make sure this domctl
>>> should be called before memory population no matter when we do assign a
>>> device as passthrough.
>>
>> You didn't think through the implications then: If device assignment
>> happens early enough, there's no need to report SBDF tuples via a
> 
> In the present the device assignment is always after memory population. 
> And I also mentioned previously I double checked this sequence with printk.

And I didn't question that; instead I suggested to re-consider whether
that should be changed.

>> new domctl (or only if we want to still allow for post-boot assignment
>> of affected devices without using the global enforcement flag, in
>> which case assigning devices early at boot time is pointless).
> 
> The global enforcement flag is mainly used to provide such an approach 
> the user know exactly he/she may need a hotplug later, we'd better check 
> to reserve all RMRR ranges in advance.
> 
> So I guess you mean we need to separate this interface from our original 
> device assignment like this,
> 
> #1 pci_force as a global variable would control whether we force to 
> check/reserve __all__ RMRR ranges.

Yes.

> #2 flags field in each specific device of new domctl would control 
> whether this device need to check/reserve its own RMRR range. But its 
> not dependent on current device assignment domctl, so the user can use 
> them to control which devices need to work as hotplug later, separately. 

And this could be left as a second step, in order for what needs to
be done now to not get more complicated that necessary.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 08:38:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 08:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTRE-0005Kv-1t; Wed, 12 Nov 2014 08:38:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoTRC-0005Kq-4h
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 08:38:02 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	7E/3B-17958-96C13645; Wed, 12 Nov 2014 08:38:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415781480!10819527!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3064 invoked from network); 12 Nov 2014 08:38:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 08:38:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 08:37:59 +0000
Message-Id: <54632A760200007800046ACC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 08:37:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
In-Reply-To: <5462B9AC.6050704@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 02:36, <tiejun.chen@intel.com> wrote:
> On 2014/11/11 18:07, Jan Beulich wrote:
>>>>> On 11.11.14 at 10:42, <tiejun.chen@intel.com> wrote:
>>> On 2014/11/11 17:06, Jan Beulich wrote:
>>>> Part of which would involve re-considering whether device
>>>> assignment shouldn't be done before memory population in the
>>>> tool stack.
>>>
>>> Yes, after we introduce this new domctl, we just make sure this domctl
>>> should be called before memory population no matter when we do assign a
>>> device as passthrough.
>>
>> You didn't think through the implications then: If device assignment
>> happens early enough, there's no need to report SBDF tuples via a
> 
> In the present the device assignment is always after memory population. 
> And I also mentioned previously I double checked this sequence with printk.

And I didn't question that; instead I suggested to re-consider whether
that should be changed.

>> new domctl (or only if we want to still allow for post-boot assignment
>> of affected devices without using the global enforcement flag, in
>> which case assigning devices early at boot time is pointless).
> 
> The global enforcement flag is mainly used to provide such an approach 
> the user know exactly he/she may need a hotplug later, we'd better check 
> to reserve all RMRR ranges in advance.
> 
> So I guess you mean we need to separate this interface from our original 
> device assignment like this,
> 
> #1 pci_force as a global variable would control whether we force to 
> check/reserve __all__ RMRR ranges.

Yes.

> #2 flags field in each specific device of new domctl would control 
> whether this device need to check/reserve its own RMRR range. But its 
> not dependent on current device assignment domctl, so the user can use 
> them to control which devices need to work as hotplug later, separately. 

And this could be left as a second step, in order for what needs to
be done now to not get more complicated that necessary.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 08:46:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 08:46:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTZ3-0005Wv-0b; Wed, 12 Nov 2014 08:46:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoTZ1-0005Wq-VU
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 08:46:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3F/EE-09842-F4E13645; Wed, 12 Nov 2014 08:46:07 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415781966!12114697!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4090 invoked from network); 12 Nov 2014 08:46:06 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-7.tower-21.messagelabs.com with SMTP;
	12 Nov 2014 08:46:06 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 12 Nov 2014 00:43:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,367,1413270000"; d="scan'208";a="606451770"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by orsmga001.jf.intel.com with ESMTP; 12 Nov 2014 00:45:47 -0800
Message-ID: <54631E3A.2020909@intel.com>
Date: Wed, 12 Nov 2014 16:45:46 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
In-Reply-To: <54632A760200007800046ACC@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> #2 flags field in each specific device of new domctl would control
>> whether this device need to check/reserve its own RMRR range. But its
>> not dependent on current device assignment domctl, so the user can use
>> them to control which devices need to work as hotplug later, separately.
>
> And this could be left as a second step, in order for what needs to
> be done now to not get more complicated that necessary.
>

Do you mean currently we still rely on the device assignment domctl to 
provide SBDF? So looks nothing should be changed in our policy.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 08:46:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 08:46:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTZ3-0005Wv-0b; Wed, 12 Nov 2014 08:46:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoTZ1-0005Wq-VU
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 08:46:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3F/EE-09842-F4E13645; Wed, 12 Nov 2014 08:46:07 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415781966!12114697!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4090 invoked from network); 12 Nov 2014 08:46:06 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-7.tower-21.messagelabs.com with SMTP;
	12 Nov 2014 08:46:06 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 12 Nov 2014 00:43:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,367,1413270000"; d="scan'208";a="606451770"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by orsmga001.jf.intel.com with ESMTP; 12 Nov 2014 00:45:47 -0800
Message-ID: <54631E3A.2020909@intel.com>
Date: Wed, 12 Nov 2014 16:45:46 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
In-Reply-To: <54632A760200007800046ACC@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> #2 flags field in each specific device of new domctl would control
>> whether this device need to check/reserve its own RMRR range. But its
>> not dependent on current device assignment domctl, so the user can use
>> them to control which devices need to work as hotplug later, separately.
>
> And this could be left as a second step, in order for what needs to
> be done now to not get more complicated that necessary.
>

Do you mean currently we still rely on the device assignment domctl to 
provide SBDF? So looks nothing should be changed in our policy.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 08:56:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 08:56:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTiY-0005j1-3K; Wed, 12 Nov 2014 08:55:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoTiW-0005iw-Qf
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 08:55:56 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	C4/F2-28296-C9023645; Wed, 12 Nov 2014 08:55:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415782555!10757961!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11254 invoked from network); 12 Nov 2014 08:55:55 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 08:55:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 08:55:54 +0000
Message-Id: <54632EA80200007800046AE5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 08:55:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
In-Reply-To: <5462CE68.6010709@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
> I don't see any feedback to this point, so I think you still prefer we 
> should do all check in the callback function.

As a draft this looks reasonable, but there are various bugs to be
dealt with along with cosmetic issues (I'll point out the former, but
I'm tired of pointing out the latter once again - please go back to
earlier reviews of patches to refresh e.g. what types to use for
loop variables).

> I tried to address this but obviously we have to pass each 'pdf' to 
> callback functions,

Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
but something more neutral (maybe "id"). And you again lost the
segment there.

> @@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
>           if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>               return -ERANGE;
> 
> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
> -                                     &rdm, 1) )
> -            return -EFAULT;
> +        if ( d->arch.hvm_domain.pci_force )
> +        {
> +            if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
> +                                         &rdm, 1) )
> +                return -EFAULT;
> +        }
> +        else
> +        {
> +            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
> +            {
> +                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
> +                                  d->arch.hvm_domain.pcidevs[i].devfn);
> +                if ( pt_bdf == bdf )
> +                    if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
> +                                                 &rdm, 1) )
> +                        return -EFAULT;

I think d->arch.hvm_domain.pcidevs[] shouldn't contain duplicates,
and hence there's no point continuing the loop if you found a match.

> +            }
> +        }
>       }
> 
>       ++grdm->used_entries;

This should no longer get incremented unconditionally.

> @@ -314,6 +333,7 @@ int compat_memory_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) compat)
>                   return -EFAULT;
> 
>               grdm.used_entries = 0;
> +            grdm.domain = current->domain;
>               rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
>                                                     &grdm);
> 

Maybe I misguided you with an earlier response, or maybe the
earlier reply was in a different context: There's no point
communicating current->domain to the callback function; there
would be a point communicating the domain if it was _not_
always current->domain.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 08:56:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 08:56:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTiY-0005j1-3K; Wed, 12 Nov 2014 08:55:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoTiW-0005iw-Qf
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 08:55:56 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	C4/F2-28296-C9023645; Wed, 12 Nov 2014 08:55:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415782555!10757961!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11254 invoked from network); 12 Nov 2014 08:55:55 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 08:55:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 08:55:54 +0000
Message-Id: <54632EA80200007800046AE5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 08:55:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260D1047@SHSMSX101.ccr.corp.intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
In-Reply-To: <5462CE68.6010709@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
> I don't see any feedback to this point, so I think you still prefer we 
> should do all check in the callback function.

As a draft this looks reasonable, but there are various bugs to be
dealt with along with cosmetic issues (I'll point out the former, but
I'm tired of pointing out the latter once again - please go back to
earlier reviews of patches to refresh e.g. what types to use for
loop variables).

> I tried to address this but obviously we have to pass each 'pdf' to 
> callback functions,

Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
but something more neutral (maybe "id"). And you again lost the
segment there.

> @@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
>           if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>               return -ERANGE;
> 
> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
> -                                     &rdm, 1) )
> -            return -EFAULT;
> +        if ( d->arch.hvm_domain.pci_force )
> +        {
> +            if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
> +                                         &rdm, 1) )
> +                return -EFAULT;
> +        }
> +        else
> +        {
> +            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
> +            {
> +                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
> +                                  d->arch.hvm_domain.pcidevs[i].devfn);
> +                if ( pt_bdf == bdf )
> +                    if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
> +                                                 &rdm, 1) )
> +                        return -EFAULT;

I think d->arch.hvm_domain.pcidevs[] shouldn't contain duplicates,
and hence there's no point continuing the loop if you found a match.

> +            }
> +        }
>       }
> 
>       ++grdm->used_entries;

This should no longer get incremented unconditionally.

> @@ -314,6 +333,7 @@ int compat_memory_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) compat)
>                   return -EFAULT;
> 
>               grdm.used_entries = 0;
> +            grdm.domain = current->domain;
>               rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
>                                                     &grdm);
> 

Maybe I misguided you with an earlier response, or maybe the
earlier reply was in a different context: There's no point
communicating current->domain to the callback function; there
would be a point communicating the domain if it was _not_
always current->domain.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTor-0005wQ-22; Wed, 12 Nov 2014 09:02:29 +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 1XoTop-0005wL-Cp
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:02:27 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	2B/08-02559-22223645; Wed, 12 Nov 2014 09:02:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415782946!11973335!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29242 invoked from network); 12 Nov 2014 09:02:26 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 09:02:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 09:02:25 +0000
Message-Id: <5463302F0200007800046AF8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 09:02:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
In-Reply-To: <54631E3A.2020909@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
>> > #2 flags field in each specific device of new domctl would control
>>> whether this device need to check/reserve its own RMRR range. But its
>>> not dependent on current device assignment domctl, so the user can use
>>> them to control which devices need to work as hotplug later, separately.
>>
>> And this could be left as a second step, in order for what needs to
>> be done now to not get more complicated that necessary.
>>
> 
> Do you mean currently we still rely on the device assignment domctl to 
> provide SBDF? So looks nothing should be changed in our policy.

I can't connect your question to what I said. What I tried to tell you
was that I don't currently see a need to make this overly complicated:
Having the option to punch holes for all devices and (by default)
dealing with just the devices assigned at boot may be sufficient as a
first step. Yet (repeating just to avoid any misunderstanding) that
makes things easier only if we decide to require device assignment to
happen before memory getting populated (since in that case there's
no need for a new domctl to communicate SBDFs, as devices needing
holes will be known to the hypervisor already).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTor-0005wQ-22; Wed, 12 Nov 2014 09:02:29 +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 1XoTop-0005wL-Cp
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:02:27 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	2B/08-02559-22223645; Wed, 12 Nov 2014 09:02:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415782946!11973335!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29242 invoked from network); 12 Nov 2014 09:02:26 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 09:02:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 09:02:25 +0000
Message-Id: <5463302F0200007800046AF8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 09:02:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
In-Reply-To: <54631E3A.2020909@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
>> > #2 flags field in each specific device of new domctl would control
>>> whether this device need to check/reserve its own RMRR range. But its
>>> not dependent on current device assignment domctl, so the user can use
>>> them to control which devices need to work as hotplug later, separately.
>>
>> And this could be left as a second step, in order for what needs to
>> be done now to not get more complicated that necessary.
>>
> 
> Do you mean currently we still rely on the device assignment domctl to 
> provide SBDF? So looks nothing should be changed in our policy.

I can't connect your question to what I said. What I tried to tell you
was that I don't currently see a need to make this overly complicated:
Having the option to punch holes for all devices and (by default)
dealing with just the devices assigned at boot may be sufficient as a
first step. Yet (repeating just to avoid any misunderstanding) that
makes things easier only if we decide to require device assignment to
happen before memory getting populated (since in that case there's
no need for a new domctl to communicate SBDFs, as devices needing
holes will be known to the hypervisor already).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:13:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTzR-00069M-6y; Wed, 12 Nov 2014 09:13:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoTzP-00069H-Rw
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:13:23 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	DA/37-05632-3B423645; Wed, 12 Nov 2014 09:13:23 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415783600!10810333!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5698 invoked from network); 12 Nov 2014 09:13:21 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-11.tower-31.messagelabs.com with SMTP;
	12 Nov 2014 09:13:21 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 12 Nov 2014 01:06:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="415281181"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by FMSMGA003.fm.intel.com with ESMTP; 12 Nov 2014 01:04:21 -0800
Message-ID: <546324AC.1010306@intel.com>
Date: Wed, 12 Nov 2014 17:13:16 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
In-Reply-To: <5463302F0200007800046AF8@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/12 17:02, Jan Beulich wrote:
>>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
>>>> #2 flags field in each specific device of new domctl would control
>>>> whether this device need to check/reserve its own RMRR range. But its
>>>> not dependent on current device assignment domctl, so the user can use
>>>> them to control which devices need to work as hotplug later, separately.
>>>
>>> And this could be left as a second step, in order for what needs to
>>> be done now to not get more complicated that necessary.
>>>
>>
>> Do you mean currently we still rely on the device assignment domctl to
>> provide SBDF? So looks nothing should be changed in our policy.
>
> I can't connect your question to what I said. What I tried to tell you

Something is misunderstanding to me.

> was that I don't currently see a need to make this overly complicated:
> Having the option to punch holes for all devices and (by default)
> dealing with just the devices assigned at boot may be sufficient as a
> first step. Yet (repeating just to avoid any misunderstanding) that
> makes things easier only if we decide to require device assignment to
> happen before memory getting populated (since in that case there's

Here what do you mean, 'if we decide to require device assignment to 
happen before memory getting populated'?

Because -quote-
"
In the present the device assignment is always after memory population. 
And I also mentioned previously I double checked this sequence with printk.
"

Or you already plan or deciede to change this sequence?

Thanks
Tiejun

> no need for a new domctl to communicate SBDFs, as devices needing
> holes will be known to the hypervisor already).
>
> Jan
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:13:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoTzR-00069M-6y; Wed, 12 Nov 2014 09:13:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoTzP-00069H-Rw
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:13:23 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	DA/37-05632-3B423645; Wed, 12 Nov 2014 09:13:23 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415783600!10810333!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5698 invoked from network); 12 Nov 2014 09:13:21 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-11.tower-31.messagelabs.com with SMTP;
	12 Nov 2014 09:13:21 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 12 Nov 2014 01:06:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="415281181"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by FMSMGA003.fm.intel.com with ESMTP; 12 Nov 2014 01:04:21 -0800
Message-ID: <546324AC.1010306@intel.com>
Date: Wed, 12 Nov 2014 17:13:16 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
In-Reply-To: <5463302F0200007800046AF8@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/12 17:02, Jan Beulich wrote:
>>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
>>>> #2 flags field in each specific device of new domctl would control
>>>> whether this device need to check/reserve its own RMRR range. But its
>>>> not dependent on current device assignment domctl, so the user can use
>>>> them to control which devices need to work as hotplug later, separately.
>>>
>>> And this could be left as a second step, in order for what needs to
>>> be done now to not get more complicated that necessary.
>>>
>>
>> Do you mean currently we still rely on the device assignment domctl to
>> provide SBDF? So looks nothing should be changed in our policy.
>
> I can't connect your question to what I said. What I tried to tell you

Something is misunderstanding to me.

> was that I don't currently see a need to make this overly complicated:
> Having the option to punch holes for all devices and (by default)
> dealing with just the devices assigned at boot may be sufficient as a
> first step. Yet (repeating just to avoid any misunderstanding) that
> makes things easier only if we decide to require device assignment to
> happen before memory getting populated (since in that case there's

Here what do you mean, 'if we decide to require device assignment to 
happen before memory getting populated'?

Because -quote-
"
In the present the device assignment is always after memory population. 
And I also mentioned previously I double checked this sequence with printk.
"

Or you already plan or deciede to change this sequence?

Thanks
Tiejun

> no need for a new domctl to communicate SBDFs, as devices needing
> holes will be known to the hypervisor already).
>
> Jan
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:24:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUAE-0006Lk-Dk; Wed, 12 Nov 2014 09:24:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoUAD-0006Lf-A1
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 09:24:33 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	33/CB-09936-05723645; Wed, 12 Nov 2014 09:24:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415784268!8672536!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28146 invoked from network); 12 Nov 2014 09:24:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 09:24:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 09:24:27 +0000
Message-Id: <5463355B0200007800046B17@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 09:24:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
	<20141112013757.GC2593@laptop.dumpdata.com>
In-Reply-To: <20141112013757.GC2593@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, David Vrabel <david.vrabel@citrix.com>,
	zhenzhong.duan@oracle.com
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 02:37, <konrad.wilk@oracle.com> wrote:
> When we PCI insert an device, the BARs are not set at all - and hence
> the Linux kernel is the one that tries to set the BARs in. The
> reason it cannot fit the device in the MMIO region is due to the
> _CRS only having certain ranges (even thought the MMIO region can
> cover 2GB). See:
> 
> Without any devices (and me doing PCI insertion after that):
> # dmesg | grep "bus resource"
> [    0.366000] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> [    0.366000] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> [    0.366000] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
> 
> With the device (my GPU card) inserted so that hvmloader can enumerate it:
>  dmesg | grep 'resource'     
> [    0.455006] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    0.459006] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> [    0.462006] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> [    0.466006] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> [    0.469006] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbffffff]
> 
> I chatted with Bjorn and Rafeal on IRC about how PCI insertion works
> on baremetal and it sounds like Thunderbolt device insertion is an
> interesting case. The SMM sets the BAR regions to fit within the MMIO
> (which is advertised by the _CRS) and it then pokes the OS to enumerate
> the BARs. The OS is free to use what the firmware has set or renumber
> it. The end result is that since the SMM 'fits' the BAR inside the
> pre-set _CRS window it all works. We do not do that.

Who does the BAR assignment is pretty much orthogonal to the
problem at hand: If the region reserved for MMIO is too small,
no-one will be able to fit a device in there. Plus, what is being
reported as root bus resource doesn't have to have a
connection to the ranges usable for MMIO at all, at least if I
assume that the (Dell) system I'm right now looking at isn't
completely screwed:

pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x00000000-0x3fffffffff]

(i.e. it simply reports the full usable 38 bits wide address space)

Looking at another (Intel) one, there is no mention of regions
above the 4G boundary at all:

pci_bus 0000:00: root bus resource [bus 00-3d]
pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000cbfff]
pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfedfffff]
pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff]

Not sure how the OS would know it is safe to assign BARs above
4Gb here.

In any event, what you need is an equivalent of the frequently
seen BIOS option controlling the size of the space to be reserved
for MMIO (often allowing it to be 1, 2, or 3 Gb). I.e. an alternative
(or extension) to the dynamic lowering of pci_mem_start in
hvmloader.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:24:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUAE-0006Lk-Dk; Wed, 12 Nov 2014 09:24:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoUAD-0006Lf-A1
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 09:24:33 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	33/CB-09936-05723645; Wed, 12 Nov 2014 09:24:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415784268!8672536!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28146 invoked from network); 12 Nov 2014 09:24:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 09:24:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 09:24:27 +0000
Message-Id: <5463355B0200007800046B17@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 09:24:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
	<20141112013757.GC2593@laptop.dumpdata.com>
In-Reply-To: <20141112013757.GC2593@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, David Vrabel <david.vrabel@citrix.com>,
	zhenzhong.duan@oracle.com
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 02:37, <konrad.wilk@oracle.com> wrote:
> When we PCI insert an device, the BARs are not set at all - and hence
> the Linux kernel is the one that tries to set the BARs in. The
> reason it cannot fit the device in the MMIO region is due to the
> _CRS only having certain ranges (even thought the MMIO region can
> cover 2GB). See:
> 
> Without any devices (and me doing PCI insertion after that):
> # dmesg | grep "bus resource"
> [    0.366000] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> [    0.366000] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> [    0.366000] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
> 
> With the device (my GPU card) inserted so that hvmloader can enumerate it:
>  dmesg | grep 'resource'     
> [    0.455006] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    0.459006] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> [    0.462006] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> [    0.466006] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> [    0.469006] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbffffff]
> 
> I chatted with Bjorn and Rafeal on IRC about how PCI insertion works
> on baremetal and it sounds like Thunderbolt device insertion is an
> interesting case. The SMM sets the BAR regions to fit within the MMIO
> (which is advertised by the _CRS) and it then pokes the OS to enumerate
> the BARs. The OS is free to use what the firmware has set or renumber
> it. The end result is that since the SMM 'fits' the BAR inside the
> pre-set _CRS window it all works. We do not do that.

Who does the BAR assignment is pretty much orthogonal to the
problem at hand: If the region reserved for MMIO is too small,
no-one will be able to fit a device in there. Plus, what is being
reported as root bus resource doesn't have to have a
connection to the ranges usable for MMIO at all, at least if I
assume that the (Dell) system I'm right now looking at isn't
completely screwed:

pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x00000000-0x3fffffffff]

(i.e. it simply reports the full usable 38 bits wide address space)

Looking at another (Intel) one, there is no mention of regions
above the 4G boundary at all:

pci_bus 0000:00: root bus resource [bus 00-3d]
pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000cbfff]
pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfedfffff]
pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff]

Not sure how the OS would know it is safe to assign BARs above
4Gb here.

In any event, what you need is an equivalent of the frequently
seen BIOS option controlling the size of the space to be reserved
for MMIO (often allowing it to be 1, 2, or 3 Gb). I.e. an alternative
(or extension) to the dynamic lowering of pci_mem_start in
hvmloader.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:24:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUAb-0006Nc-QA; Wed, 12 Nov 2014 09:24:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sebott@linux.vnet.ibm.com>) id 1XoUAa-0006NR-7l
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 09:24:56 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	8B/0F-02699-76723645; Wed, 12 Nov 2014 09:24:55 +0000
X-Env-Sender: sebott@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415784294!8646382!1
X-Originating-IP: [195.75.94.110]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk1Ljc1Ljk0LjExMCA9PiA0MDE3Mzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13244 invoked from network); 12 Nov 2014 09:24:55 -0000
Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 09:24:55 -0000
Received: from /spool/local
	by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xenproject.org> from <sebott@linux.vnet.ibm.com>; 
	Wed, 12 Nov 2014 09:24:54 -0000
Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13)
	by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 12 Nov 2014 09:24:52 -0000
Received: from b06cxnps4074.portsmouth.uk.ibm.com
	(d06relay11.portsmouth.uk.ibm.com [9.149.109.196])
	by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id A179D17D805A
	for <xen-devel@lists.xenproject.org>;
	Wed, 12 Nov 2014 09:25:01 +0000 (GMT)
Received: from d06av12.portsmouth.uk.ibm.com (d06av12.portsmouth.uk.ibm.com
	[9.149.37.247])
	by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with
	ESMTP id sAC9Oqgp9830794
	for <xen-devel@lists.xenproject.org>; Wed, 12 Nov 2014 09:24:52 GMT
Received: from d06av12.portsmouth.uk.ibm.com (localhost [127.0.0.1])
	by d06av12.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with
	ESMTP id sAC9OjVX004243
	for <xen-devel@lists.xenproject.org>; Wed, 12 Nov 2014 02:24:51 -0700
Received: from dyn-9-152-212-106.boeblingen.de.ibm.com
	(dyn-9-152-212-106.boeblingen.de.ibm.com [9.152.212.106])
	by d06av12.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with
	ESMTP id sAC9OPGV003886
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 02:24:33 -0700
Date: Wed, 12 Nov 2014 10:24:24 +0100 (CET)
From: Sebastian Ott <sebott@linux.vnet.ibm.com>
X-X-Sender: sebott@denkbrett
To: Bjorn Helgaas <bhelgaas@google.com>
In-Reply-To: <20141111212353.GJ28161@google.com>
Message-ID: <alpine.LFD.2.11.1411121023020.1596@denkbrett>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<20141111212353.GJ28161@google.com>
User-Agent: Alpine 2.11 (LFD 23 2013-08-11)
Organization: =?ISO-8859-15?Q?=22IBM_Deutschland_Research_&_Development_GmbH_=2F_Vorsitzende_des_Aufsichtsrats=3A_Martina_Koederitz_Gesch=E4ftsf=FChrung=3A_Dirk_Wittkopp_Sitz_der_Gesellschaft=3A_B=F6blingen_=2F_Registergericht?=
	=?ISO-8859-15?Q?=3A_Amtsgericht_Stuttgart=2C_HRB_243294=22?=
MIME-Version: 1.0
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14111209-0017-0000-0000-000001CE5E40
Cc: linux-s390@vger.kernel.org, linux-pci@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	Yijing Wang <wangyijing@huawei.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 0/3] xen MSI code clean up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Nov 2014, Bjorn Helgaas wrote:
> [+cc Sebastian, linux-s390, David, Konrad, xen-devel]
> 
> On Mon, Oct 27, 2014 at 10:44:35AM +0800, Yijing Wang wrote:
> > 
> > Yijing Wang (3):
> >   x86/xen: Introduce a global flag to fix the MSI mask bug
> >   x86/xen: Revert "PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()"
> >   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
> 
> I applied these with David's reviewed-by and ack to pci/msi for v3.19.
> 
> I'd like to see an ack from Sebastian for the s390 part, but I guess that
> one is pretty trivial.

> >   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()

Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>

Regards,
Sebastian

> 
> >  arch/s390/pci/pci.c             |    4 ++--
> >  arch/x86/include/asm/x86_init.h |    3 ---
> >  arch/x86/kernel/x86_init.c      |   10 ----------
> >  arch/x86/pci/xen.c              |   15 +++------------
> >  drivers/pci/msi.c               |   29 ++++++++++++-----------------
> >  include/linux/msi.h             |    5 +++--
> >  6 files changed, 20 insertions(+), 46 deletions(-)
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:24:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUAb-0006Nc-QA; Wed, 12 Nov 2014 09:24:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sebott@linux.vnet.ibm.com>) id 1XoUAa-0006NR-7l
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 09:24:56 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	8B/0F-02699-76723645; Wed, 12 Nov 2014 09:24:55 +0000
X-Env-Sender: sebott@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415784294!8646382!1
X-Originating-IP: [195.75.94.110]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk1Ljc1Ljk0LjExMCA9PiA0MDE3Mzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13244 invoked from network); 12 Nov 2014 09:24:55 -0000
Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 09:24:55 -0000
Received: from /spool/local
	by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xenproject.org> from <sebott@linux.vnet.ibm.com>; 
	Wed, 12 Nov 2014 09:24:54 -0000
Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13)
	by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 12 Nov 2014 09:24:52 -0000
Received: from b06cxnps4074.portsmouth.uk.ibm.com
	(d06relay11.portsmouth.uk.ibm.com [9.149.109.196])
	by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id A179D17D805A
	for <xen-devel@lists.xenproject.org>;
	Wed, 12 Nov 2014 09:25:01 +0000 (GMT)
Received: from d06av12.portsmouth.uk.ibm.com (d06av12.portsmouth.uk.ibm.com
	[9.149.37.247])
	by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with
	ESMTP id sAC9Oqgp9830794
	for <xen-devel@lists.xenproject.org>; Wed, 12 Nov 2014 09:24:52 GMT
Received: from d06av12.portsmouth.uk.ibm.com (localhost [127.0.0.1])
	by d06av12.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with
	ESMTP id sAC9OjVX004243
	for <xen-devel@lists.xenproject.org>; Wed, 12 Nov 2014 02:24:51 -0700
Received: from dyn-9-152-212-106.boeblingen.de.ibm.com
	(dyn-9-152-212-106.boeblingen.de.ibm.com [9.152.212.106])
	by d06av12.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with
	ESMTP id sAC9OPGV003886
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 02:24:33 -0700
Date: Wed, 12 Nov 2014 10:24:24 +0100 (CET)
From: Sebastian Ott <sebott@linux.vnet.ibm.com>
X-X-Sender: sebott@denkbrett
To: Bjorn Helgaas <bhelgaas@google.com>
In-Reply-To: <20141111212353.GJ28161@google.com>
Message-ID: <alpine.LFD.2.11.1411121023020.1596@denkbrett>
References: <1414377878-23497-1-git-send-email-wangyijing@huawei.com>
	<20141111212353.GJ28161@google.com>
User-Agent: Alpine 2.11 (LFD 23 2013-08-11)
Organization: =?ISO-8859-15?Q?=22IBM_Deutschland_Research_&_Development_GmbH_=2F_Vorsitzende_des_Aufsichtsrats=3A_Martina_Koederitz_Gesch=E4ftsf=FChrung=3A_Dirk_Wittkopp_Sitz_der_Gesellschaft=3A_B=F6blingen_=2F_Registergericht?=
	=?ISO-8859-15?Q?=3A_Amtsgericht_Stuttgart=2C_HRB_243294=22?=
MIME-Version: 1.0
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14111209-0017-0000-0000-000001CE5E40
Cc: linux-s390@vger.kernel.org, linux-pci@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	Yijing Wang <wangyijing@huawei.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH 0/3] xen MSI code clean up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Nov 2014, Bjorn Helgaas wrote:
> [+cc Sebastian, linux-s390, David, Konrad, xen-devel]
> 
> On Mon, Oct 27, 2014 at 10:44:35AM +0800, Yijing Wang wrote:
> > 
> > Yijing Wang (3):
> >   x86/xen: Introduce a global flag to fix the MSI mask bug
> >   x86/xen: Revert "PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()"
> >   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
> 
> I applied these with David's reviewed-by and ack to pci/msi for v3.19.
> 
> I'd like to see an ack from Sebastian for the s390 part, but I guess that
> one is pretty trivial.

> >   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()

Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>

Regards,
Sebastian

> 
> >  arch/s390/pci/pci.c             |    4 ++--
> >  arch/x86/include/asm/x86_init.h |    3 ---
> >  arch/x86/kernel/x86_init.c      |   10 ----------
> >  arch/x86/pci/xen.c              |   15 +++------------
> >  drivers/pci/msi.c               |   29 ++++++++++++-----------------
> >  include/linux/msi.h             |    5 +++--
> >  6 files changed, 20 insertions(+), 46 deletions(-)
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:35:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUKR-0006hv-2e; Wed, 12 Nov 2014 09:35:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoUKP-0006hq-1g
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:35:05 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	38/9C-22819-8C923645; Wed, 12 Nov 2014 09:35:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415784903!7942853!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25860 invoked from network); 12 Nov 2014 09:35:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 09:35:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 09:35:03 +0000
Message-Id: <546337D50200007800046B2F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 09:35:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Wei Liu" <wei.liu2@citrix.com>,<xen-devel@lists.xen.org>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
In-Reply-To: <54624F6A.40002@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
> On 11/11/14 17:36, Wei Liu wrote:
>> Option #1 requires less modification to guest, because guest won't
>> need to switch to new hypercall. It's unclear at this point if a guest
>> asks to populate a gpfn that doesn't belong to any vnode, what Xen
>> should do about it. Should it be permissive or strict? 
> 
> There are XENMEMF flags to request exact node or not  -- leave it up to
> the balloon driver.  The Linux balloon driver could try exact on all
> nodes before falling back to permissive or just always try inexact.
> 
> Perhaps a XENMEMF_vnode bit to indicate the node is virtual?

Yes. The only bad thing here is that we don't currently check in the
hypervisor that unknown bits are zero, i.e. code using the new flag
will need to have a separate means to find out whether the bit is
supported. Not a big deal of course.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:35:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUKR-0006hv-2e; Wed, 12 Nov 2014 09:35:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoUKP-0006hq-1g
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:35:05 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	38/9C-22819-8C923645; Wed, 12 Nov 2014 09:35:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415784903!7942853!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25860 invoked from network); 12 Nov 2014 09:35:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 09:35:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 09:35:03 +0000
Message-Id: <546337D50200007800046B2F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 09:35:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Wei Liu" <wei.liu2@citrix.com>,<xen-devel@lists.xen.org>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
In-Reply-To: <54624F6A.40002@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
> On 11/11/14 17:36, Wei Liu wrote:
>> Option #1 requires less modification to guest, because guest won't
>> need to switch to new hypercall. It's unclear at this point if a guest
>> asks to populate a gpfn that doesn't belong to any vnode, what Xen
>> should do about it. Should it be permissive or strict? 
> 
> There are XENMEMF flags to request exact node or not  -- leave it up to
> the balloon driver.  The Linux balloon driver could try exact on all
> nodes before falling back to permissive or just always try inexact.
> 
> Perhaps a XENMEMF_vnode bit to indicate the node is virtual?

Yes. The only bad thing here is that we don't currently check in the
hypervisor that unknown bits are zero, i.e. code using the new flag
will need to have a separate means to find out whether the bit is
supported. Not a big deal of course.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:49:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1XoUY7-0006um-Fq; Wed, 12 Nov 2014 09:49:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoUY6-0006uh-6d
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:49:14 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	38/44-17958-91D23645; Wed, 12 Nov 2014 09:49:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415785752!10679440!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6444 invoked from network); 12 Nov 2014 09:49:12 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 09:49:12 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 09:49:11 +0000
Message-Id: <54633B260200007800046B39@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 09:49:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Robert Hu" <robert.hu@intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 07:58, <robert.hu@intel.com> wrote:
> 2. Failed to hotplug a VT-d device with XEN4.5-RC1
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894 

First of all I'm not sure it is really useful to use the old, discontinued
bugzilla to report bugs. I think it would be much easier if you reported
them directly (and individually) to the mailing list, with or without
triggering the creation of bugs in the new tracking system.

As to the specific bug above - nothing is being said on whether a
driver was still attached to the device at the time it was being
hot-unplugged; if there was, I'm not sure what the expected
behavior would be (i.e. on real hardware).

> 3. Fail to hot add multi devices to guest
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895 

The description in contradicting itself - title and parts of it say
the operation failed, but "Bug detailed description" says "Checking
inside guest VM, the VT-D device is attached to guest VM actually,
and works fine."

> 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896 

I think we were told the other day that pass-through of PFs is
not being supported by Intel. What's the purpose of reporting
bugs there?

> 7. Error msg occurred after attaching multi SR-IOV VF device to running guest
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899 

This reads (except for the title) the same as 1895. Am I overlooking
something here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:49:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1XoUY7-0006um-Fq; Wed, 12 Nov 2014 09:49:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoUY6-0006uh-6d
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:49:14 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	38/44-17958-91D23645; Wed, 12 Nov 2014 09:49:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415785752!10679440!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6444 invoked from network); 12 Nov 2014 09:49:12 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 09:49:12 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 09:49:11 +0000
Message-Id: <54633B260200007800046B39@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 09:49:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Robert Hu" <robert.hu@intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 07:58, <robert.hu@intel.com> wrote:
> 2. Failed to hotplug a VT-d device with XEN4.5-RC1
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894 

First of all I'm not sure it is really useful to use the old, discontinued
bugzilla to report bugs. I think it would be much easier if you reported
them directly (and individually) to the mailing list, with or without
triggering the creation of bugs in the new tracking system.

As to the specific bug above - nothing is being said on whether a
driver was still attached to the device at the time it was being
hot-unplugged; if there was, I'm not sure what the expected
behavior would be (i.e. on real hardware).

> 3. Fail to hot add multi devices to guest
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895 

The description in contradicting itself - title and parts of it say
the operation failed, but "Bug detailed description" says "Checking
inside guest VM, the VT-D device is attached to guest VM actually,
and works fine."

> 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896 

I think we were told the other day that pass-through of PFs is
not being supported by Intel. What's the purpose of reporting
bugs there?

> 7. Error msg occurred after attaching multi SR-IOV VF device to running guest
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899 

This reads (except for the title) the same as 1895. Am I overlooking
something here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:53:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:53:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUcG-00075z-5z; Wed, 12 Nov 2014 09:53:32 +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 1XoUcE-00075s-Vx
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:53:31 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	7A/41-11581-A1E23645; Wed, 12 Nov 2014 09:53:30 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415786009!7476673!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI5MDUzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10494 invoked from network); 12 Nov 2014 09:53:29 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 09:53:29 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=XtJIop4WGY5LDk29AX4W2sb+R5hAx6jAXkBD44r2XbL+4VXTHW1F6wfo
	fL1/okb4k4X1Jp0wyK8RZyLEVXNgTXFcZ6IewX/2TY1MK/u8jEIWoPJvW
	Df9c+Zia3ZS3VxYZqPNJ77KrYchjjG3nxlTYsgMTqa4GHBMjboToHzcAU
	yQfKWFJWaOwAfqGZWEijJsOu0tP4oJVVI/PF3k64s8RFCt5OTxkhmu3ks
	2uTkg7gegalQQfW+5mpwIIfHOoQr7;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1415786010; x=1447322010;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=U0zaSobR0nslxyE4hJa8Ka/dCGzBNmLjuQcGbm1TLqs=;
	b=vXZhovAp/5krv7Z97wqn+BE6nCnKD8M2w3GDaK7csKkrpCl0N24RjyLO
	vnOEaBOQzCGRu7srwWhxQZlDtMejVmX5fu2lmguUzpi9idsq4I/j9bAuq
	lpWwF5uH/c7dA3FwsMDtDXhrmgQWbW+FP91uHRr4v3+kNnOObwd1ZLdmS
	NLP8YDKPaVktwIPeVvW05XGXTZItBDQcRUFIpoRqLboouSxnDebwnOGZr
	iMbwxE7zKq0OFWt+GzDEBwuntUK5p;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="5.07,367,1413237600"; d="scan'208";a="212940865"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 12 Nov 2014 10:53:26 +0100
X-IronPort-AV: E=Sophos;i="5.07,367,1413237600"; d="scan'208";a="54205997"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with ESMTP; 12 Nov 2014 10:53:25 +0100
Received: from amur.localnet (amur.mch.fsc.net [10.172.102.32])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 4ED6CA9EC83;
	Wed, 12 Nov 2014 10:53:25 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 10:53:24 +0100
Message-ID: <3016118.gIEEAtXxHA@amur>
User-Agent: KMail/4.11.5 (Linux/3.11.10-21-xen; KDE/4.11.5; x86_64; ; )
In-Reply-To: <54621B4D.7000408@suse.com>
References: <19147765.FEreuxd8Ya@amur> <54621B4D.7000408@suse.com>
MIME-Version: 1.0
Cc: Juergen Gross <jgross@suse.com>
Subject: Re: [Xen-devel] Wrong cpupool 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

Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross:
> Hi again,
> 
> On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
> > Hi list,
> >
> > When creating a cpupool, starting and destroying a guest within this pool,
> > then removing this pool doesn't work because of EBUSY.
> >
> > It seems the cause of this behavior is the commit
> > bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
> >
> > In domain_kill() the function sched_move_domain() gets called changing the
> > d->cpupool pointer to the new cpupool without incrementing/decrementing the
> > counters "n_dom" of the new/old cpupool.
> >
> > This leads to decrementing the wrong  cpupool0->n_dom counter when
> > cpupool_rm_domain() gets called at the end and my own cpupool can't be
> > destroyed because n_dom = 1!
> >
> > I don't have a fast patch because I'am not enough familiar with the code
> > this time but I think it should be fixed for 4.5.
> 
> Please discard previous patch, try this one.

Yes this patch works.
But I think in general a better solution would be to have the changing of the
cpupool pointer in sched_move_domain() together with the increment/decrement
of the counters but I see the locking problem.
Thanks.

Dietmar.

> 
> Juergen
> 

-- 
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 Nov 12 09:53:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:53:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUcG-00075z-5z; Wed, 12 Nov 2014 09:53:32 +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 1XoUcE-00075s-Vx
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:53:31 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	7A/41-11581-A1E23645; Wed, 12 Nov 2014 09:53:30 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415786009!7476673!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI5MDUzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10494 invoked from network); 12 Nov 2014 09:53:29 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 09:53:29 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=XtJIop4WGY5LDk29AX4W2sb+R5hAx6jAXkBD44r2XbL+4VXTHW1F6wfo
	fL1/okb4k4X1Jp0wyK8RZyLEVXNgTXFcZ6IewX/2TY1MK/u8jEIWoPJvW
	Df9c+Zia3ZS3VxYZqPNJ77KrYchjjG3nxlTYsgMTqa4GHBMjboToHzcAU
	yQfKWFJWaOwAfqGZWEijJsOu0tP4oJVVI/PF3k64s8RFCt5OTxkhmu3ks
	2uTkg7gegalQQfW+5mpwIIfHOoQr7;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1415786010; x=1447322010;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=U0zaSobR0nslxyE4hJa8Ka/dCGzBNmLjuQcGbm1TLqs=;
	b=vXZhovAp/5krv7Z97wqn+BE6nCnKD8M2w3GDaK7csKkrpCl0N24RjyLO
	vnOEaBOQzCGRu7srwWhxQZlDtMejVmX5fu2lmguUzpi9idsq4I/j9bAuq
	lpWwF5uH/c7dA3FwsMDtDXhrmgQWbW+FP91uHRr4v3+kNnOObwd1ZLdmS
	NLP8YDKPaVktwIPeVvW05XGXTZItBDQcRUFIpoRqLboouSxnDebwnOGZr
	iMbwxE7zKq0OFWt+GzDEBwuntUK5p;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="5.07,367,1413237600"; d="scan'208";a="212940865"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 12 Nov 2014 10:53:26 +0100
X-IronPort-AV: E=Sophos;i="5.07,367,1413237600"; d="scan'208";a="54205997"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with ESMTP; 12 Nov 2014 10:53:25 +0100
Received: from amur.localnet (amur.mch.fsc.net [10.172.102.32])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 4ED6CA9EC83;
	Wed, 12 Nov 2014 10:53:25 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 10:53:24 +0100
Message-ID: <3016118.gIEEAtXxHA@amur>
User-Agent: KMail/4.11.5 (Linux/3.11.10-21-xen; KDE/4.11.5; x86_64; ; )
In-Reply-To: <54621B4D.7000408@suse.com>
References: <19147765.FEreuxd8Ya@amur> <54621B4D.7000408@suse.com>
MIME-Version: 1.0
Cc: Juergen Gross <jgross@suse.com>
Subject: Re: [Xen-devel] Wrong cpupool 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

Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross:
> Hi again,
> 
> On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
> > Hi list,
> >
> > When creating a cpupool, starting and destroying a guest within this pool,
> > then removing this pool doesn't work because of EBUSY.
> >
> > It seems the cause of this behavior is the commit
> > bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
> >
> > In domain_kill() the function sched_move_domain() gets called changing the
> > d->cpupool pointer to the new cpupool without incrementing/decrementing the
> > counters "n_dom" of the new/old cpupool.
> >
> > This leads to decrementing the wrong  cpupool0->n_dom counter when
> > cpupool_rm_domain() gets called at the end and my own cpupool can't be
> > destroyed because n_dom = 1!
> >
> > I don't have a fast patch because I'am not enough familiar with the code
> > this time but I think it should be fixed for 4.5.
> 
> Please discard previous patch, try this one.

Yes this patch works.
But I think in general a better solution would be to have the changing of the
cpupool pointer in sched_move_domain() together with the increment/decrement
of the counters but I see the locking problem.
Thanks.

Dietmar.

> 
> Juergen
> 

-- 
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 Nov 12 09:57:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUfe-0007Eh-TV; Wed, 12 Nov 2014 09:57:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoUfd-0007EW-Ay
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:57:01 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	EF/1D-01660-CEE23645; Wed, 12 Nov 2014 09:57:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415786219!10819243!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20017 invoked from network); 12 Nov 2014 09:56:59 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 09:56:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 09:56:59 +0000
Message-Id: <54633CF90200007800046B44@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 09:56:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
In-Reply-To: <546324AC.1010306@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 10:13, <tiejun.chen@intel.com> wrote:
> On 2014/11/12 17:02, Jan Beulich wrote:
>>>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
>>>>> #2 flags field in each specific device of new domctl would control
>>>>> whether this device need to check/reserve its own RMRR range. But its
>>>>> not dependent on current device assignment domctl, so the user can use
>>>>> them to control which devices need to work as hotplug later, separately.
>>>>
>>>> And this could be left as a second step, in order for what needs to
>>>> be done now to not get more complicated that necessary.
>>>>
>>>
>>> Do you mean currently we still rely on the device assignment domctl to
>>> provide SBDF? So looks nothing should be changed in our policy.
>>
>> I can't connect your question to what I said. What I tried to tell you
> 
> Something is misunderstanding to me.
> 
>> was that I don't currently see a need to make this overly complicated:
>> Having the option to punch holes for all devices and (by default)
>> dealing with just the devices assigned at boot may be sufficient as a
>> first step. Yet (repeating just to avoid any misunderstanding) that
>> makes things easier only if we decide to require device assignment to
>> happen before memory getting populated (since in that case there's
> 
> Here what do you mean, 'if we decide to require device assignment to 
> happen before memory getting populated'?
> 
> Because -quote-
> "
> In the present the device assignment is always after memory population. 
> And I also mentioned previously I double checked this sequence with printk.
> "
> 
> Or you already plan or deciede to change this sequence?

So it is now the 3rd time that I'm telling you that part of your
decision making as to which route to follow should be to
re-consider whether the current sequence of operations shouldn't
be changed. Please also consult with the VT-d maintainers (hint to
them: participating in this discussion publicly would be really nice)
on _all_ decisions to be made here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:57:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUfe-0007Eh-TV; Wed, 12 Nov 2014 09:57:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoUfd-0007EW-Ay
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:57:01 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	EF/1D-01660-CEE23645; Wed, 12 Nov 2014 09:57:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415786219!10819243!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20017 invoked from network); 12 Nov 2014 09:56:59 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 09:56:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 09:56:59 +0000
Message-Id: <54633CF90200007800046B44@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 09:56:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
In-Reply-To: <546324AC.1010306@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 10:13, <tiejun.chen@intel.com> wrote:
> On 2014/11/12 17:02, Jan Beulich wrote:
>>>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
>>>>> #2 flags field in each specific device of new domctl would control
>>>>> whether this device need to check/reserve its own RMRR range. But its
>>>>> not dependent on current device assignment domctl, so the user can use
>>>>> them to control which devices need to work as hotplug later, separately.
>>>>
>>>> And this could be left as a second step, in order for what needs to
>>>> be done now to not get more complicated that necessary.
>>>>
>>>
>>> Do you mean currently we still rely on the device assignment domctl to
>>> provide SBDF? So looks nothing should be changed in our policy.
>>
>> I can't connect your question to what I said. What I tried to tell you
> 
> Something is misunderstanding to me.
> 
>> was that I don't currently see a need to make this overly complicated:
>> Having the option to punch holes for all devices and (by default)
>> dealing with just the devices assigned at boot may be sufficient as a
>> first step. Yet (repeating just to avoid any misunderstanding) that
>> makes things easier only if we decide to require device assignment to
>> happen before memory getting populated (since in that case there's
> 
> Here what do you mean, 'if we decide to require device assignment to 
> happen before memory getting populated'?
> 
> Because -quote-
> "
> In the present the device assignment is always after memory population. 
> And I also mentioned previously I double checked this sequence with printk.
> "
> 
> Or you already plan or deciede to change this sequence?

So it is now the 3rd time that I'm telling you that part of your
decision making as to which route to follow should be to
re-consider whether the current sequence of operations shouldn't
be changed. Please also consult with the VT-d maintainers (hint to
them: participating in this discussion publicly would be really nice)
on _all_ decisions to be made here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 09:59:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:59:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUhn-0007QU-1r; Wed, 12 Nov 2014 09:59:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XoUhl-0007QE-G5
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:59:13 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	CD/B0-22777-07F23645; Wed, 12 Nov 2014 09:59:12 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415786351!3244236!1
X-Originating-IP: [74.125.82.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27351 invoked from network); 12 Nov 2014 09:59:11 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 09:59:11 -0000
Received: by mail-wg0-f45.google.com with SMTP id x12so13710111wgg.4
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 01:59:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=zNTcHLQAaT0eT1M1UoxADkQME5UBfd02mrNF8Ss4eTY=;
	b=Hhjb45IX+YALHoEwyFDrOwv0OUEOSyPy5x/Gr54NxjmUIJBJ5/yjq653qK3g3hYnJT
	mzhwPKPriEyqxJTmCL/jgf8BCInYp0poWulMxCdd+Da9KG2sRA2JeLVa++CTDpjRau5a
	R7sBGP10JmoMWaDS8lMtl7aUzcpK2hfiVhl7bkWEpqNgH/c/EnIgnqJ+eERJhtyshoNX
	8SKLSdhNuG+Zk9Bl3KI6xBPBZdyvTWbR5+nmc8syS7H46lu5fZIsi59tJLUXFUVOZhkl
	cZgaoNN0zvYaRt+ctfkMwh25XwlHTg7TKWHWGtkkiBMq1X4gk7uYGo0fUlKnqp6tqf7I
	IYXg==
X-Gm-Message-State: ALoCoQncPfA/WTeDFOU71iNE5sU1hfEsdWhrD0E3hA007JzUls5Kd8ztEy23bAkJON0zSQQtfuZa
X-Received: by 10.194.77.4 with SMTP id o4mr62718773wjw.41.1415786350970;
	Wed, 12 Nov 2014 01:59:10 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id b6sm20942540wiy.22.2014.11.12.01.59.09
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 12 Nov 2014 01:59:10 -0800 (PST)
Message-ID: <54632F72.7020509@m2r.biz>
Date: Wed, 12 Nov 2014 10:59:14 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Hu, Robert" <robert.hu@intel.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
Cc: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 12/11/2014 07:58, Hu, Robert ha scritto:
> Hi All,
>
> This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
>
> Test environment:
> Xen: Xen 4.5-rc1
> Dom0: Linux kernel 3.17.0
> Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP
>
> New bugs(9):
> 1. with "xen_platform_pci=0" option, the guest with VT-d device fails to boot up
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1893

Have you tried with recent domU's kernel that contain this commit?
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a3bbaca868043cc45b3ad3786dd48a90235
If I remember good there is a critical boot problem with 
"xen_platform_pci=0" and without it.

> 2. Failed to hotplug a VT-d device with XEN4.5-RC1
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> 3. Fail to hot add multi devices to guest
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895
> 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
> 5. Dom0 failed to resume from S3 power state
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897
> 6. Networking is unavailable after save&restore Windows guest
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898

Should be the same problem I reported 1 year ago or more and still 
present, the workaround is use fixed mac address in domUs xl cfg :(
http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html

> 7. Error msg occurred after attaching multi SR-IOV VF device to running guest
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899
> 8. "xl vcpu-set " will report error when adding vcpus number
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1900
> 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
>
> 1 old legacy bug(1):
> 1. Guest hang after resume from S3
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1828
>
>
> Best Regards,
> Robert
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 12 09:59:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 09:59:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUhn-0007QU-1r; Wed, 12 Nov 2014 09:59:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XoUhl-0007QE-G5
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 09:59:13 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	CD/B0-22777-07F23645; Wed, 12 Nov 2014 09:59:12 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415786351!3244236!1
X-Originating-IP: [74.125.82.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27351 invoked from network); 12 Nov 2014 09:59:11 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 09:59:11 -0000
Received: by mail-wg0-f45.google.com with SMTP id x12so13710111wgg.4
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 01:59:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=zNTcHLQAaT0eT1M1UoxADkQME5UBfd02mrNF8Ss4eTY=;
	b=Hhjb45IX+YALHoEwyFDrOwv0OUEOSyPy5x/Gr54NxjmUIJBJ5/yjq653qK3g3hYnJT
	mzhwPKPriEyqxJTmCL/jgf8BCInYp0poWulMxCdd+Da9KG2sRA2JeLVa++CTDpjRau5a
	R7sBGP10JmoMWaDS8lMtl7aUzcpK2hfiVhl7bkWEpqNgH/c/EnIgnqJ+eERJhtyshoNX
	8SKLSdhNuG+Zk9Bl3KI6xBPBZdyvTWbR5+nmc8syS7H46lu5fZIsi59tJLUXFUVOZhkl
	cZgaoNN0zvYaRt+ctfkMwh25XwlHTg7TKWHWGtkkiBMq1X4gk7uYGo0fUlKnqp6tqf7I
	IYXg==
X-Gm-Message-State: ALoCoQncPfA/WTeDFOU71iNE5sU1hfEsdWhrD0E3hA007JzUls5Kd8ztEy23bAkJON0zSQQtfuZa
X-Received: by 10.194.77.4 with SMTP id o4mr62718773wjw.41.1415786350970;
	Wed, 12 Nov 2014 01:59:10 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id b6sm20942540wiy.22.2014.11.12.01.59.09
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 12 Nov 2014 01:59:10 -0800 (PST)
Message-ID: <54632F72.7020509@m2r.biz>
Date: Wed, 12 Nov 2014 10:59:14 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Hu, Robert" <robert.hu@intel.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
Cc: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 12/11/2014 07:58, Hu, Robert ha scritto:
> Hi All,
>
> This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
>
> Test environment:
> Xen: Xen 4.5-rc1
> Dom0: Linux kernel 3.17.0
> Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP
>
> New bugs(9):
> 1. with "xen_platform_pci=0" option, the guest with VT-d device fails to boot up
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1893

Have you tried with recent domU's kernel that contain this commit?
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a3bbaca868043cc45b3ad3786dd48a90235
If I remember good there is a critical boot problem with 
"xen_platform_pci=0" and without it.

> 2. Failed to hotplug a VT-d device with XEN4.5-RC1
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> 3. Fail to hot add multi devices to guest
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895
> 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
> 5. Dom0 failed to resume from S3 power state
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897
> 6. Networking is unavailable after save&restore Windows guest
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898

Should be the same problem I reported 1 year ago or more and still 
present, the workaround is use fixed mac address in domUs xl cfg :(
http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html

> 7. Error msg occurred after attaching multi SR-IOV VF device to running guest
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899
> 8. "xl vcpu-set " will report error when adding vcpus number
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1900
> 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
>
> 1 old legacy bug(1):
> 1. Guest hang after resume from S3
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1828
>
>
> Best Regards,
> Robert
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 12 10:01:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoUk7-0007gk-49; Wed, 12 Nov 2014 10:01:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoUk6-0007gV-LP
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:01:38 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	B0/6F-03145-20033645; Wed, 12 Nov 2014 10:01:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415786495!11969938!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11591 invoked from network); 12 Nov 2014 10:01:37 -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;
	12 Nov 2014 10:01:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="190455006"
Message-ID: <1415786484.25176.45.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 12 Nov 2014 10:01:24 +0000
In-Reply-To: <1415713603-14611-1-git-send-email-wei.liu2@citrix.com>
References: <1415713603-14611-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 13:46 +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Konrad Wilk <konrad.wilk@oracle.com>
> ---
> This is a simple enough bug fix I think it should just go in.

Probably, but can you explain in the commit log what the symptoms of not
doing it are, IOW why it is required.

> ---
>  tools/libxl/libxl.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..de23fec 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
>                                                                          \
>          GCNEW(aodev);                                                   \
>          libxl__prepare_ao_device(ao, aodev);                            \
> +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
>          aodev->callback = device_addrm_aocomplete;                      \
>          aodev->update_json = true;                                      \
>          libxl__device_##type##_add(egc, domid, type, aodev);            \



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:01:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoUk1-0007ff-JI; Wed, 12 Nov 2014 10:01:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1XoUjz-0007fU-Tn
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:01:32 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	02/42-08051-BFF23645; Wed, 12 Nov 2014 10:01:31 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415786489!11993215!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16534 invoked from network); 12 Nov 2014 10:01:30 -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;
	12 Nov 2014 10:01:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="191900600"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 05:01:28 -0500
Received: from malcolmc.uk.xensource.com ([10.80.2.69])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<malcolm.crossley@citrix.com>)	id 1XoUjw-0000jr-BZ	for
	xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:01:28 +0000
Message-ID: <54632FF8.7020508@citrix.com>
Date: Wed, 12 Nov 2014 10:01:28 +0000
From: Malcolm Crossley <malcolm.crossley@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <20141110173248.GA13778@laptop.dumpdata.com>	<5460F908.4040208@citrix.com>	<20141110180720.GA15286@laptop.dumpdata.com>	<20141110213248.GA23182@laptop.dumpdata.com>	<20141112013757.GC2593@laptop.dumpdata.com>
	<5463355B0200007800046B17@mail.emea.novell.com>
In-Reply-To: <5463355B0200007800046B17@mail.emea.novell.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 09:24, Jan Beulich wrote:
>>>> On 12.11.14 at 02:37, <konrad.wilk@oracle.com> wrote:
>> When we PCI insert an device, the BARs are not set at all - and hence
>> the Linux kernel is the one that tries to set the BARs in. The
>> reason it cannot fit the device in the MMIO region is due to the
>> _CRS only having certain ranges (even thought the MMIO region can
>> cover 2GB). See:
>>
>> Without any devices (and me doing PCI insertion after that):
>> # dmesg | grep "bus resource"
>> [    0.366000] pci_bus 0000:00: root bus resource [bus 00-ff]
>> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
>> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
>> [    0.366000] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
>> [    0.366000] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
>>
>> With the device (my GPU card) inserted so that hvmloader can enumerate it:
>>  dmesg | grep 'resource'     
>> [    0.455006] pci_bus 0000:00: root bus resource [bus 00-ff]
>> [    0.459006] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
>> [    0.462006] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
>> [    0.466006] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
>> [    0.469006] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbffffff]
>>
>> I chatted with Bjorn and Rafeal on IRC about how PCI insertion works
>> on baremetal and it sounds like Thunderbolt device insertion is an
>> interesting case. The SMM sets the BAR regions to fit within the MMIO
>> (which is advertised by the _CRS) and it then pokes the OS to enumerate
>> the BARs. The OS is free to use what the firmware has set or renumber
>> it. The end result is that since the SMM 'fits' the BAR inside the
>> pre-set _CRS window it all works. We do not do that.
> 
> Who does the BAR assignment is pretty much orthogonal to the
> problem at hand: If the region reserved for MMIO is too small,
> no-one will be able to fit a device in there. Plus, what is being
> reported as root bus resource doesn't have to have a
> connection to the ranges usable for MMIO at all, at least if I
> assume that the (Dell) system I'm right now looking at isn't
> completely screwed:
> 
> pci_bus 0000:00: root bus resource [bus 00-ff]
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> pci_bus 0000:00: root bus resource [mem 0x00000000-0x3fffffffff]
> 
> (i.e. it simply reports the full usable 38 bits wide address space)
> 
> Looking at another (Intel) one, there is no mention of regions
> above the 4G boundary at all:
> 
> pci_bus 0000:00: root bus resource [bus 00-3d]
> pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000cbfff]
> pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfedfffff]
> pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff]
> 
> Not sure how the OS would know it is safe to assign BARs above
> 4Gb here.
> 
> In any event, what you need is an equivalent of the frequently
> seen BIOS option controlling the size of the space to be reserved
> for MMIO (often allowing it to be 1, 2, or 3 Gb). I.e. an alternative
> (or extension) to the dynamic lowering of pci_mem_start in
> hvmloader.
> 

I agree with Jan. By using xl pci-attach you are effectively hotplugging
a PCI device (in the bare metal case). The only way this will work
reliably is if you reserve some MMIO space for the device you are about
to attach. You cannot just use space above the 4G boundary because the
PCI device may have 32 bit only BAR's and thus it's MMIO cannot be
placed at addresses above 4G.

The problem you have is that you cannot predict how much MMIO space to
reserve because you don't know in advance how many PCI device's you are
going to hotplug and how much MMIO space is required per device.

As for the CRS regions: These typically describe the BIOS set limits in
hardware configuration for the MMIO hole itself. On single socket
systems anything which isn't RAM or another predefined region decodes to
MMIO. This is probably why Jan's Dell system has a CRS region which
covers the entire address space.

On multi socket systems the CRS is very important because the chipset is
configured to only decode certain regions to the PCI express ports, if
you use an address out side of those regions then accessing that address
will go "nowhere" and the machine will crash.

Typically you will see a separate high MMIO CRS region if 64bit BAR
support is enabled in BIOS.


To do HVM pci hotplug properly we need to reserve MMIO space below 4G
and emulate a PCI hotplug capable PCI-PCI bridge device. The bridge
device will know the maximum size of the MMIO behind it (as allocated at
boot time) and so we can calculate if the device we are hotplugging can
fit. If it doesn't fit then we fail the hotplug otherwise we allow it
and the OS will correct allocate the BAR behind the bridge.

BTW, calculating the required MMIO for multi BAR PCI device's is not
easy because all the BAR's need to be aligned to their size (naturally
aligned).

Malcolm


> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:01:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoUk7-0007gk-49; Wed, 12 Nov 2014 10:01:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoUk6-0007gV-LP
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:01:38 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	B0/6F-03145-20033645; Wed, 12 Nov 2014 10:01:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415786495!11969938!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11591 invoked from network); 12 Nov 2014 10:01:37 -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;
	12 Nov 2014 10:01:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="190455006"
Message-ID: <1415786484.25176.45.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 12 Nov 2014 10:01:24 +0000
In-Reply-To: <1415713603-14611-1-git-send-email-wei.liu2@citrix.com>
References: <1415713603-14611-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 13:46 +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Konrad Wilk <konrad.wilk@oracle.com>
> ---
> This is a simple enough bug fix I think it should just go in.

Probably, but can you explain in the commit log what the symptoms of not
doing it are, IOW why it is required.

> ---
>  tools/libxl/libxl.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..de23fec 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
>                                                                          \
>          GCNEW(aodev);                                                   \
>          libxl__prepare_ao_device(ao, aodev);                            \
> +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
>          aodev->callback = device_addrm_aocomplete;                      \
>          aodev->update_json = true;                                      \
>          libxl__device_##type##_add(egc, domid, type, aodev);            \



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:01:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoUk1-0007ff-JI; Wed, 12 Nov 2014 10:01:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1XoUjz-0007fU-Tn
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:01:32 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	02/42-08051-BFF23645; Wed, 12 Nov 2014 10:01:31 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415786489!11993215!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16534 invoked from network); 12 Nov 2014 10:01:30 -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;
	12 Nov 2014 10:01:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="191900600"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 05:01:28 -0500
Received: from malcolmc.uk.xensource.com ([10.80.2.69])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<malcolm.crossley@citrix.com>)	id 1XoUjw-0000jr-BZ	for
	xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:01:28 +0000
Message-ID: <54632FF8.7020508@citrix.com>
Date: Wed, 12 Nov 2014 10:01:28 +0000
From: Malcolm Crossley <malcolm.crossley@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <20141110173248.GA13778@laptop.dumpdata.com>	<5460F908.4040208@citrix.com>	<20141110180720.GA15286@laptop.dumpdata.com>	<20141110213248.GA23182@laptop.dumpdata.com>	<20141112013757.GC2593@laptop.dumpdata.com>
	<5463355B0200007800046B17@mail.emea.novell.com>
In-Reply-To: <5463355B0200007800046B17@mail.emea.novell.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 09:24, Jan Beulich wrote:
>>>> On 12.11.14 at 02:37, <konrad.wilk@oracle.com> wrote:
>> When we PCI insert an device, the BARs are not set at all - and hence
>> the Linux kernel is the one that tries to set the BARs in. The
>> reason it cannot fit the device in the MMIO region is due to the
>> _CRS only having certain ranges (even thought the MMIO region can
>> cover 2GB). See:
>>
>> Without any devices (and me doing PCI insertion after that):
>> # dmesg | grep "bus resource"
>> [    0.366000] pci_bus 0000:00: root bus resource [bus 00-ff]
>> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
>> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
>> [    0.366000] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
>> [    0.366000] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
>>
>> With the device (my GPU card) inserted so that hvmloader can enumerate it:
>>  dmesg | grep 'resource'     
>> [    0.455006] pci_bus 0000:00: root bus resource [bus 00-ff]
>> [    0.459006] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
>> [    0.462006] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
>> [    0.466006] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
>> [    0.469006] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbffffff]
>>
>> I chatted with Bjorn and Rafeal on IRC about how PCI insertion works
>> on baremetal and it sounds like Thunderbolt device insertion is an
>> interesting case. The SMM sets the BAR regions to fit within the MMIO
>> (which is advertised by the _CRS) and it then pokes the OS to enumerate
>> the BARs. The OS is free to use what the firmware has set or renumber
>> it. The end result is that since the SMM 'fits' the BAR inside the
>> pre-set _CRS window it all works. We do not do that.
> 
> Who does the BAR assignment is pretty much orthogonal to the
> problem at hand: If the region reserved for MMIO is too small,
> no-one will be able to fit a device in there. Plus, what is being
> reported as root bus resource doesn't have to have a
> connection to the ranges usable for MMIO at all, at least if I
> assume that the (Dell) system I'm right now looking at isn't
> completely screwed:
> 
> pci_bus 0000:00: root bus resource [bus 00-ff]
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> pci_bus 0000:00: root bus resource [mem 0x00000000-0x3fffffffff]
> 
> (i.e. it simply reports the full usable 38 bits wide address space)
> 
> Looking at another (Intel) one, there is no mention of regions
> above the 4G boundary at all:
> 
> pci_bus 0000:00: root bus resource [bus 00-3d]
> pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000cbfff]
> pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfedfffff]
> pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff]
> 
> Not sure how the OS would know it is safe to assign BARs above
> 4Gb here.
> 
> In any event, what you need is an equivalent of the frequently
> seen BIOS option controlling the size of the space to be reserved
> for MMIO (often allowing it to be 1, 2, or 3 Gb). I.e. an alternative
> (or extension) to the dynamic lowering of pci_mem_start in
> hvmloader.
> 

I agree with Jan. By using xl pci-attach you are effectively hotplugging
a PCI device (in the bare metal case). The only way this will work
reliably is if you reserve some MMIO space for the device you are about
to attach. You cannot just use space above the 4G boundary because the
PCI device may have 32 bit only BAR's and thus it's MMIO cannot be
placed at addresses above 4G.

The problem you have is that you cannot predict how much MMIO space to
reserve because you don't know in advance how many PCI device's you are
going to hotplug and how much MMIO space is required per device.

As for the CRS regions: These typically describe the BIOS set limits in
hardware configuration for the MMIO hole itself. On single socket
systems anything which isn't RAM or another predefined region decodes to
MMIO. This is probably why Jan's Dell system has a CRS region which
covers the entire address space.

On multi socket systems the CRS is very important because the chipset is
configured to only decode certain regions to the PCI express ports, if
you use an address out side of those regions then accessing that address
will go "nowhere" and the machine will crash.

Typically you will see a separate high MMIO CRS region if 64bit BAR
support is enabled in BIOS.


To do HVM pci hotplug properly we need to reserve MMIO space below 4G
and emulate a PCI hotplug capable PCI-PCI bridge device. The bridge
device will know the maximum size of the MMIO behind it (as allocated at
boot time) and so we can calculate if the device we are hotplugging can
fit. If it doesn't fit then we fail the hotplug otherwise we allow it
and the OS will correct allocate the BAR behind the bridge.

BTW, calculating the required MMIO for multi BAR PCI device's is not
easy because all the BAR's need to be aligned to their size (naturally
aligned).

Malcolm


> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:08:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUqJ-00087f-Uk; Wed, 12 Nov 2014 10:08:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoUqH-00087X-OH
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:08:03 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	E1/3E-26740-18133645; Wed, 12 Nov 2014 10:08:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415786879!10810291!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20710 invoked from network); 12 Nov 2014 10:08:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:08:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="191902285"
Message-ID: <1415786876.25176.49.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 12 Nov 2014 10:07:56 +0000
In-Reply-To: <54623E3D.4060803@linaro.org>
References: <1414579268.29975.13.camel@citrix.com>
	<1414579302-6692-18-git-send-email-ian.campbell@citrix.com>
	<21585.6188.366311.80971@mariner.uk.xensource.com>
	<1414672390.2064.31.camel@citrix.com> <54623E3D.4060803@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH OSSTEST v2 18/20] Osstest/Debian: Add
 "clk_ignore_unused" to default command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 17:50 +0100, Julien Grall wrote:
> Hi,
> 
> Somehow I missed this email.
> 
> On 30/10/2014 13:33, Ian Campbell wrote:
> > create !
> > title it arm: domain 0 disables clocks which are in fact being used
> > thanks
> >
> > On Wed, 2014-10-29 at 16:39 +0000, Ian Jackson wrote:
> >> Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
> >>> This stops dom0 from messing with clocks which it should and is required on
> >>> some platforms. It's harmless even when not needed.
> >>
> >> This is pretty odd.  Doesn't this correspond to some kind of bug, in
> >> the dom0 kernel perhaps ?
> >
> > dom0 is not aware that some clocks are actually in use (e.g. by the
> > hypervisor), so the bug is probably in the lack of some interface to
> > communicate this from Xen to dom0, or some other mechanism to gate this.
> 
> In reality, Xen is only using the clock of the UART. Even though, I 
> think this would also happen with platform device passthrough.
> 
> For the latter, it would be fairly easy via a PV drivers. But for 
> UART... gating the clock could be a nightmare because every platform 
> have their own way to enable/disable the clock. Futhermore, the clock 
> could be shared with multiple device...
> 
> I'm wondering if we could expose the UART to DOM0 without marking as 
> disabled. It would avoid DOM0 to mess up the clock while everything 
> would be catch via the vuart implementation in Xen.

Perhaps we could propagate any clock related properties from the UART
node into the Xen hypervisor node (or a subnode)? The Xen Linux code
would then consume those and mark the relevant clocks as in use. I've
not looked into the clock bindings to know how plausible this might be.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:08:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUqJ-00087f-Uk; Wed, 12 Nov 2014 10:08:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoUqH-00087X-OH
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:08:03 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	E1/3E-26740-18133645; Wed, 12 Nov 2014 10:08:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415786879!10810291!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20710 invoked from network); 12 Nov 2014 10:08:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:08:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="191902285"
Message-ID: <1415786876.25176.49.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 12 Nov 2014 10:07:56 +0000
In-Reply-To: <54623E3D.4060803@linaro.org>
References: <1414579268.29975.13.camel@citrix.com>
	<1414579302-6692-18-git-send-email-ian.campbell@citrix.com>
	<21585.6188.366311.80971@mariner.uk.xensource.com>
	<1414672390.2064.31.camel@citrix.com> <54623E3D.4060803@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH OSSTEST v2 18/20] Osstest/Debian: Add
 "clk_ignore_unused" to default command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 17:50 +0100, Julien Grall wrote:
> Hi,
> 
> Somehow I missed this email.
> 
> On 30/10/2014 13:33, Ian Campbell wrote:
> > create !
> > title it arm: domain 0 disables clocks which are in fact being used
> > thanks
> >
> > On Wed, 2014-10-29 at 16:39 +0000, Ian Jackson wrote:
> >> Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
> >>> This stops dom0 from messing with clocks which it should and is required on
> >>> some platforms. It's harmless even when not needed.
> >>
> >> This is pretty odd.  Doesn't this correspond to some kind of bug, in
> >> the dom0 kernel perhaps ?
> >
> > dom0 is not aware that some clocks are actually in use (e.g. by the
> > hypervisor), so the bug is probably in the lack of some interface to
> > communicate this from Xen to dom0, or some other mechanism to gate this.
> 
> In reality, Xen is only using the clock of the UART. Even though, I 
> think this would also happen with platform device passthrough.
> 
> For the latter, it would be fairly easy via a PV drivers. But for 
> UART... gating the clock could be a nightmare because every platform 
> have their own way to enable/disable the clock. Futhermore, the clock 
> could be shared with multiple device...
> 
> I'm wondering if we could expose the UART to DOM0 without marking as 
> disabled. It would avoid DOM0 to mess up the clock while everything 
> would be catch via the vuart implementation in Xen.

Perhaps we could propagate any clock related properties from the UART
node into the Xen hypervisor node (or a subnode)? The Xen Linux code
would then consume those and mark the relevant clocks as in use. I've
not looked into the clock bindings to know how plausible this might be.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:11:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:11:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUts-0008Pk-I1; Wed, 12 Nov 2014 10:11:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoUtr-0008PX-CC
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:11:43 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B4/99-31453-E5233645; Wed, 12 Nov 2014 10:11:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415787101!7482501!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21739 invoked from network); 12 Nov 2014 10:11:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 10:11:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 10:11:41 +0000
Message-Id: <5463406C0200007800046B6F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 10:11:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Malcolm Crossley" <malcolm.crossley@citrix.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
	<20141112013757.GC2593@laptop.dumpdata.com>
	<5463355B0200007800046B17@mail.emea.novell.com>
	<54632FF8.7020508@citrix.com>
In-Reply-To: <54632FF8.7020508@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 11:01, <malcolm.crossley@citrix.com> wrote:
> As for the CRS regions: These typically describe the BIOS set limits in
> hardware configuration for the MMIO hole itself. On single socket
> systems anything which isn't RAM or another predefined region decodes to
> MMIO. This is probably why Jan's Dell system has a CRS region which
> covers the entire address space.
> 
> On multi socket systems the CRS is very important because the chipset is
> configured to only decode certain regions to the PCI express ports, if
> you use an address out side of those regions then accessing that address
> will go "nowhere" and the machine will crash.

Don't you mean multi-node instead of multi-socket here? Since what
matters is how the I/O subsystem is organized; the CPU topology is
pretty uninteresting for this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:11:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:11:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoUts-0008Pk-I1; Wed, 12 Nov 2014 10:11:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoUtr-0008PX-CC
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:11:43 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B4/99-31453-E5233645; Wed, 12 Nov 2014 10:11:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415787101!7482501!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21739 invoked from network); 12 Nov 2014 10:11:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 10:11:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 10:11:41 +0000
Message-Id: <5463406C0200007800046B6F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 10:11:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Malcolm Crossley" <malcolm.crossley@citrix.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
	<20141112013757.GC2593@laptop.dumpdata.com>
	<5463355B0200007800046B17@mail.emea.novell.com>
	<54632FF8.7020508@citrix.com>
In-Reply-To: <54632FF8.7020508@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 11:01, <malcolm.crossley@citrix.com> wrote:
> As for the CRS regions: These typically describe the BIOS set limits in
> hardware configuration for the MMIO hole itself. On single socket
> systems anything which isn't RAM or another predefined region decodes to
> MMIO. This is probably why Jan's Dell system has a CRS region which
> covers the entire address space.
> 
> On multi socket systems the CRS is very important because the chipset is
> configured to only decode certain regions to the PCI express ports, if
> you use an address out side of those regions then accessing that address
> will go "nowhere" and the machine will crash.

Don't you mean multi-node instead of multi-socket here? Since what
matters is how the I/O subsystem is organized; the CPU topology is
pretty uninteresting for this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:18:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoV0k-0000Ky-UO; Wed, 12 Nov 2014 10:18:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoV0i-0000Kf-T1
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:18:49 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0E/74-09936-80433645; Wed, 12 Nov 2014 10:18:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415787526!4833221!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15996 invoked from network); 12 Nov 2014 10:18:46 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-21.messagelabs.com with SMTP;
	12 Nov 2014 10:18:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 12 Nov 2014 02:16:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,367,1413270000"; d="scan'208";a="635609283"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by orsmga002.jf.intel.com with ESMTP; 12 Nov 2014 02:18:43 -0800
Message-ID: <54633402.7040205@intel.com>
Date: Wed, 12 Nov 2014 18:18:42 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
In-Reply-To: <54632EA80200007800046AE5@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/12 16:55, Jan Beulich wrote:
>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>> I don't see any feedback to this point, so I think you still prefer we
>> should do all check in the callback function.
>
> As a draft this looks reasonable, but there are various bugs to be
> dealt with along with cosmetic issues (I'll point out the former, but
> I'm tired of pointing out the latter once again - please go back to
> earlier reviews of patches to refresh e.g. what types to use for
> loop variables).
>
>> I tried to address this but obviously we have to pass each 'pdf' to
>> callback functions,
>
> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
> but something more neutral (maybe "id"). And you again lost the

Okay.

> segment there.

I think we don't need segment since when we passthrough a device, that 
domain doesn't matter with the real segment in phydev.

>
>> @@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
>>            if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>>                return -ERANGE;
>>
>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> -                                     &rdm, 1) )
>> -            return -EFAULT;
>> +        if ( d->arch.hvm_domain.pci_force )
>> +        {
>> +            if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                         &rdm, 1) )
>> +                return -EFAULT;
>> +        }
>> +        else
>> +        {
>> +            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
>> +            {
>> +                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
>> +                                  d->arch.hvm_domain.pcidevs[i].devfn);
>> +                if ( pt_bdf == bdf )
>> +                    if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                                 &rdm, 1) )
>> +                        return -EFAULT;
>
> I think d->arch.hvm_domain.pcidevs[] shouldn't contain duplicates,
> and hence there's no point continuing the loop if you found a match.

You're right.

>
>> +            }
>> +        }
>>        }
>>
>>        ++grdm->used_entries;
>
> This should no longer get incremented unconditionally.

Yes.

>
>> @@ -314,6 +333,7 @@ int compat_memory_op(unsigned int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>                    return -EFAULT;
>>
>>                grdm.used_entries = 0;
>> +            grdm.domain = current->domain;
>>                rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
>>                                                      &grdm);
>>
>
> Maybe I misguided you with an earlier response, or maybe the
> earlier reply was in a different context: There's no point
> communicating current->domain to the callback function; there
> would be a point communicating the domain if it was _not_
> always current->domain.
>

I will look into this.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:18:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoV0g-0000KW-IL; Wed, 12 Nov 2014 10:18:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoV0e-0000KR-Vg
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:18:45 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	DD/1B-02699-40433645; Wed, 12 Nov 2014 10:18:44 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415787520!12001953!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26918 invoked from network); 12 Nov 2014 10:18:42 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-27.messagelabs.com with SMTP;
	12 Nov 2014 10:18:42 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 12 Nov 2014 02:18:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,367,1413270000"; d="scan'208";a="635609207"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by orsmga002.jf.intel.com with ESMTP; 12 Nov 2014 02:18:30 -0800
Message-ID: <546333F5.6060307@intel.com>
Date: Wed, 12 Nov 2014 18:18:29 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, kevin.tian@intel.com, 
	yang.z.zhang@intel.com
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
In-Reply-To: <54633CF90200007800046B44@mail.emea.novell.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 2014/11/12 17:56, Jan Beulich wrote:
>>>> On 12.11.14 at 10:13, <tiejun.chen@intel.com> wrote:
>> On 2014/11/12 17:02, Jan Beulich wrote:
>>>>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
>>>>>> #2 flags field in each specific device of new domctl would control
>>>>>> whether this device need to check/reserve its own RMRR range. But its
>>>>>> not dependent on current device assignment domctl, so the user can use
>>>>>> them to control which devices need to work as hotplug later, separately.
>>>>>
>>>>> And this could be left as a second step, in order for what needs to
>>>>> be done now to not get more complicated that necessary.
>>>>>
>>>>
>>>> Do you mean currently we still rely on the device assignment domctl to
>>>> provide SBDF? So looks nothing should be changed in our policy.
>>>
>>> I can't connect your question to what I said. What I tried to tell you
>>
>> Something is misunderstanding to me.
>>
>>> was that I don't currently see a need to make this overly complicated:
>>> Having the option to punch holes for all devices and (by default)
>>> dealing with just the devices assigned at boot may be sufficient as a
>>> first step. Yet (repeating just to avoid any misunderstanding) that
>>> makes things easier only if we decide to require device assignment to
>>> happen before memory getting populated (since in that case there's
>>
>> Here what do you mean, 'if we decide to require device assignment to
>> happen before memory getting populated'?
>>
>> Because -quote-
>> "
>> In the present the device assignment is always after memory population.
>> And I also mentioned previously I double checked this sequence with printk.
>> "
>>
>> Or you already plan or deciede to change this sequence?
>
> So it is now the 3rd time that I'm telling you that part of your
> decision making as to which route to follow should be to
> re-consider whether the current sequence of operations shouldn't

As I said previously it may corrupt some existing frameworks to move 
device assignment codes.

Anyway, who can determine formally this approach? Let me ping actively them.

> be changed. Please also consult with the VT-d maintainers (hint to

Especially, Yang and Kevin are always included in this thread.

> them: participating in this discussion publicly would be really nice)

Also in public.

Thanks
Tiejun

> on _all_ decisions to be made here.
>
> Jan
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:18:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoV0k-0000Ky-UO; Wed, 12 Nov 2014 10:18:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoV0i-0000Kf-T1
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:18:49 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0E/74-09936-80433645; Wed, 12 Nov 2014 10:18:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415787526!4833221!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15996 invoked from network); 12 Nov 2014 10:18:46 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-21.messagelabs.com with SMTP;
	12 Nov 2014 10:18:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 12 Nov 2014 02:16:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,367,1413270000"; d="scan'208";a="635609283"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by orsmga002.jf.intel.com with ESMTP; 12 Nov 2014 02:18:43 -0800
Message-ID: <54633402.7040205@intel.com>
Date: Wed, 12 Nov 2014 18:18:42 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
In-Reply-To: <54632EA80200007800046AE5@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/12 16:55, Jan Beulich wrote:
>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>> I don't see any feedback to this point, so I think you still prefer we
>> should do all check in the callback function.
>
> As a draft this looks reasonable, but there are various bugs to be
> dealt with along with cosmetic issues (I'll point out the former, but
> I'm tired of pointing out the latter once again - please go back to
> earlier reviews of patches to refresh e.g. what types to use for
> loop variables).
>
>> I tried to address this but obviously we have to pass each 'pdf' to
>> callback functions,
>
> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
> but something more neutral (maybe "id"). And you again lost the

Okay.

> segment there.

I think we don't need segment since when we passthrough a device, that 
domain doesn't matter with the real segment in phydev.

>
>> @@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
>>            if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>>                return -ERANGE;
>>
>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> -                                     &rdm, 1) )
>> -            return -EFAULT;
>> +        if ( d->arch.hvm_domain.pci_force )
>> +        {
>> +            if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                         &rdm, 1) )
>> +                return -EFAULT;
>> +        }
>> +        else
>> +        {
>> +            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
>> +            {
>> +                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
>> +                                  d->arch.hvm_domain.pcidevs[i].devfn);
>> +                if ( pt_bdf == bdf )
>> +                    if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                                 &rdm, 1) )
>> +                        return -EFAULT;
>
> I think d->arch.hvm_domain.pcidevs[] shouldn't contain duplicates,
> and hence there's no point continuing the loop if you found a match.

You're right.

>
>> +            }
>> +        }
>>        }
>>
>>        ++grdm->used_entries;
>
> This should no longer get incremented unconditionally.

Yes.

>
>> @@ -314,6 +333,7 @@ int compat_memory_op(unsigned int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>                    return -EFAULT;
>>
>>                grdm.used_entries = 0;
>> +            grdm.domain = current->domain;
>>                rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
>>                                                      &grdm);
>>
>
> Maybe I misguided you with an earlier response, or maybe the
> earlier reply was in a different context: There's no point
> communicating current->domain to the callback function; there
> would be a point communicating the domain if it was _not_
> always current->domain.
>

I will look into this.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:18:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoV0g-0000KW-IL; Wed, 12 Nov 2014 10:18:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoV0e-0000KR-Vg
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:18:45 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	DD/1B-02699-40433645; Wed, 12 Nov 2014 10:18:44 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415787520!12001953!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26918 invoked from network); 12 Nov 2014 10:18:42 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-27.messagelabs.com with SMTP;
	12 Nov 2014 10:18:42 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 12 Nov 2014 02:18:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,367,1413270000"; d="scan'208";a="635609207"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by orsmga002.jf.intel.com with ESMTP; 12 Nov 2014 02:18:30 -0800
Message-ID: <546333F5.6060307@intel.com>
Date: Wed, 12 Nov 2014 18:18:29 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, kevin.tian@intel.com, 
	yang.z.zhang@intel.com
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
In-Reply-To: <54633CF90200007800046B44@mail.emea.novell.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 2014/11/12 17:56, Jan Beulich wrote:
>>>> On 12.11.14 at 10:13, <tiejun.chen@intel.com> wrote:
>> On 2014/11/12 17:02, Jan Beulich wrote:
>>>>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
>>>>>> #2 flags field in each specific device of new domctl would control
>>>>>> whether this device need to check/reserve its own RMRR range. But its
>>>>>> not dependent on current device assignment domctl, so the user can use
>>>>>> them to control which devices need to work as hotplug later, separately.
>>>>>
>>>>> And this could be left as a second step, in order for what needs to
>>>>> be done now to not get more complicated that necessary.
>>>>>
>>>>
>>>> Do you mean currently we still rely on the device assignment domctl to
>>>> provide SBDF? So looks nothing should be changed in our policy.
>>>
>>> I can't connect your question to what I said. What I tried to tell you
>>
>> Something is misunderstanding to me.
>>
>>> was that I don't currently see a need to make this overly complicated:
>>> Having the option to punch holes for all devices and (by default)
>>> dealing with just the devices assigned at boot may be sufficient as a
>>> first step. Yet (repeating just to avoid any misunderstanding) that
>>> makes things easier only if we decide to require device assignment to
>>> happen before memory getting populated (since in that case there's
>>
>> Here what do you mean, 'if we decide to require device assignment to
>> happen before memory getting populated'?
>>
>> Because -quote-
>> "
>> In the present the device assignment is always after memory population.
>> And I also mentioned previously I double checked this sequence with printk.
>> "
>>
>> Or you already plan or deciede to change this sequence?
>
> So it is now the 3rd time that I'm telling you that part of your
> decision making as to which route to follow should be to
> re-consider whether the current sequence of operations shouldn't

As I said previously it may corrupt some existing frameworks to move 
device assignment codes.

Anyway, who can determine formally this approach? Let me ping actively them.

> be changed. Please also consult with the VT-d maintainers (hint to

Especially, Yang and Kevin are always included in this thread.

> them: participating in this discussion publicly would be really nice)

Also in public.

Thanks
Tiejun

> on _all_ decisions to be made here.
>
> Jan
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:24:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:24:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoV6H-0000hL-O0; Wed, 12 Nov 2014 10:24:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoV6G-0000hG-Ii
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:24:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	83/C5-24532-F5533645; Wed, 12 Nov 2014 10:24:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415787871!4835195!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10839 invoked from network); 12 Nov 2014 10:24:31 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 10:24:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 10:24:31 +0000
Message-Id: <5463436E0200007800046B92@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 10:24:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<54633402.7040205@intel.com>
In-Reply-To: <54633402.7040205@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 11:18, <tiejun.chen@intel.com> wrote:
> On 2014/11/12 16:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>>> I don't see any feedback to this point, so I think you still prefer we
>>> should do all check in the callback function.
>>
>> As a draft this looks reasonable, but there are various bugs to be
>> dealt with along with cosmetic issues (I'll point out the former, but
>> I'm tired of pointing out the latter once again - please go back to
>> earlier reviews of patches to refresh e.g. what types to use for
>> loop variables).
>>
>>> I tried to address this but obviously we have to pass each 'pdf' to
>>> callback functions,
>>
>> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
>> but something more neutral (maybe "id"). And you again lost the
> 
> Okay.
> 
>> segment there.
> 
> I think we don't need segment since when we passthrough a device, that 
> domain doesn't matter with the real segment in phydev.

How can this not matter? If 0001:bb:dd.f is associated with an RMRR
but 0000:bb:dd.f isn't, it's quite relevant which one is being handed
to a guest.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:24:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:24:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoV6H-0000hL-O0; Wed, 12 Nov 2014 10:24:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoV6G-0000hG-Ii
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:24:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	83/C5-24532-F5533645; Wed, 12 Nov 2014 10:24:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415787871!4835195!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10839 invoked from network); 12 Nov 2014 10:24:31 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 10:24:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 10:24:31 +0000
Message-Id: <5463436E0200007800046B92@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 10:24:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<54633402.7040205@intel.com>
In-Reply-To: <54633402.7040205@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 11:18, <tiejun.chen@intel.com> wrote:
> On 2014/11/12 16:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>>> I don't see any feedback to this point, so I think you still prefer we
>>> should do all check in the callback function.
>>
>> As a draft this looks reasonable, but there are various bugs to be
>> dealt with along with cosmetic issues (I'll point out the former, but
>> I'm tired of pointing out the latter once again - please go back to
>> earlier reviews of patches to refresh e.g. what types to use for
>> loop variables).
>>
>>> I tried to address this but obviously we have to pass each 'pdf' to
>>> callback functions,
>>
>> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
>> but something more neutral (maybe "id"). And you again lost the
> 
> Okay.
> 
>> segment there.
> 
> I think we don't need segment since when we passthrough a device, that 
> domain doesn't matter with the real segment in phydev.

How can this not matter? If 0001:bb:dd.f is associated with an RMRR
but 0000:bb:dd.f isn't, it's quite relevant which one is being handed
to a guest.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:25:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:25:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoV71-0000ke-6O; Wed, 12 Nov 2014 10:25:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoV6z-0000kT-Aj
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:25:17 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	CC/A2-01660-C8533645; Wed, 12 Nov 2014 10:25:16 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415787915!10834905!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14447 invoked from network); 12 Nov 2014 10:25:16 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 10:25:16 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9B3C2AAF1;
	Wed, 12 Nov 2014 10:25:14 +0000 (UTC)
Message-ID: <5463358A.7000108@suse.com>
Date: Wed, 12 Nov 2014 11:25:14 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, xen-devel@lists.xen.org
References: <19147765.FEreuxd8Ya@amur> <54621B4D.7000408@suse.com>
	<3016118.gIEEAtXxHA@amur>
In-Reply-To: <3016118.gIEEAtXxHA@amur>
Subject: Re: [Xen-devel] Wrong cpupool handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 10:53 AM, Dietmar Hahn wrote:
> Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross:
>> Hi again,
>>
>> On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
>>> Hi list,
>>>
>>> When creating a cpupool, starting and destroying a guest within this pool,
>>> then removing this pool doesn't work because of EBUSY.
>>>
>>> It seems the cause of this behavior is the commit
>>> bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
>>>
>>> In domain_kill() the function sched_move_domain() gets called changing the
>>> d->cpupool pointer to the new cpupool without incrementing/decrementing the
>>> counters "n_dom" of the new/old cpupool.
>>>
>>> This leads to decrementing the wrong  cpupool0->n_dom counter when
>>> cpupool_rm_domain() gets called at the end and my own cpupool can't be
>>> destroyed because n_dom = 1!
>>>
>>> I don't have a fast patch because I'am not enough familiar with the code
>>> this time but I think it should be fixed for 4.5.
>>
>> Please discard previous patch, try this one.
>
> Yes this patch works.

Thanks. Can I add your "tested-by:"?

> But I think in general a better solution would be to have the changing of the
> cpupool pointer in sched_move_domain() together with the increment/decrement
> of the counters but I see the locking problem.

The scheduler should never change cpupool owned data. The cpupool
pointer is domain data, so changing this is okay.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:25:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:25:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoV71-0000ke-6O; Wed, 12 Nov 2014 10:25:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoV6z-0000kT-Aj
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:25:17 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	CC/A2-01660-C8533645; Wed, 12 Nov 2014 10:25:16 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415787915!10834905!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14447 invoked from network); 12 Nov 2014 10:25:16 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 10:25:16 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9B3C2AAF1;
	Wed, 12 Nov 2014 10:25:14 +0000 (UTC)
Message-ID: <5463358A.7000108@suse.com>
Date: Wed, 12 Nov 2014 11:25:14 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, xen-devel@lists.xen.org
References: <19147765.FEreuxd8Ya@amur> <54621B4D.7000408@suse.com>
	<3016118.gIEEAtXxHA@amur>
In-Reply-To: <3016118.gIEEAtXxHA@amur>
Subject: Re: [Xen-devel] Wrong cpupool handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 10:53 AM, Dietmar Hahn wrote:
> Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross:
>> Hi again,
>>
>> On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
>>> Hi list,
>>>
>>> When creating a cpupool, starting and destroying a guest within this pool,
>>> then removing this pool doesn't work because of EBUSY.
>>>
>>> It seems the cause of this behavior is the commit
>>> bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
>>>
>>> In domain_kill() the function sched_move_domain() gets called changing the
>>> d->cpupool pointer to the new cpupool without incrementing/decrementing the
>>> counters "n_dom" of the new/old cpupool.
>>>
>>> This leads to decrementing the wrong  cpupool0->n_dom counter when
>>> cpupool_rm_domain() gets called at the end and my own cpupool can't be
>>> destroyed because n_dom = 1!
>>>
>>> I don't have a fast patch because I'am not enough familiar with the code
>>> this time but I think it should be fixed for 4.5.
>>
>> Please discard previous patch, try this one.
>
> Yes this patch works.

Thanks. Can I add your "tested-by:"?

> But I think in general a better solution would be to have the changing of the
> cpupool pointer in sched_move_domain() together with the increment/decrement
> of the counters but I see the locking problem.

The scheduler should never change cpupool owned data. The cpupool
pointer is domain data, so changing this is okay.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:32:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVE1-00017h-Rv; Wed, 12 Nov 2014 10:32:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XoVE0-000173-7l
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 10:32:32 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	8D/F0-22777-F3733645; Wed, 12 Nov 2014 10:32:31 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415788350!5549061!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9431 invoked from network); 12 Nov 2014 10:32:30 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:32:30 -0000
Received: by mail-wi0-f182.google.com with SMTP id d1so4371107wiv.3
	for <xen-devel@lists.xenproject.org>;
	Wed, 12 Nov 2014 02:32:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=DqQRuNhUs6PrzUKBnxVSVluZOa8RRfT3MRaratY0K98=;
	b=JareqkNNA6CrjkbbCmCAhBLc67fV2Qwz6Sj1RwKkC+5n4qLapg13YXKpzJs598O+YJ
	WS8GI74C1mE7ztptq0sIzuTygbOi4UeAHAZE1u6QNPt4n5EPNVJzOkOaQ3YxMb6qczL6
	OlW+ZgZ+Jh+c8TrK3JkP8fah/g42S6vjmgnv2cqFH9Ve6YaxMoonZ2tzqETrSHJk56PK
	KXztIREFvPMR3Z+tcBfOINcMsenkwt2J4uAD/h2fVXtjXgKawignoV5dnoDLvVgLp6Ha
	HG6T9We1jT423CeMlZcikOI0uBZk9xR5t9Z/F+0uN8QwhKRb69PriEnzq2OWVW30MVyf
	jeYg==
X-Gm-Message-State: ALoCoQl0NNn/KFc0+Au6zx59anYPNgWuaQNinQi/yyfhdo0OyYHpwtF1FJl/LmFHsFXRkN9WeOWZ
X-Received: by 10.194.178.231 with SMTP id db7mr60961964wjc.112.1415788350211; 
	Wed, 12 Nov 2014 02:32:30 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id gw6sm21082873wib.8.2014.11.12.02.32.23
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 12 Nov 2014 02:32:29 -0800 (PST)
Message-ID: <5463373C.2090602@m2r.biz>
Date: Wed, 12 Nov 2014 11:32:28 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<544B5AF5.7050103@m2r.biz>
	<20141027161542.GK4050@laptop.dumpdata.com>
	<544F987E.5060508@m2r.biz>
	<20141028171811.GA27336@laptop.dumpdata.com>
	<CABMPFziN9eM6_0_mfQcamOqyQBXVOOD5amom+7JTv=LorbbTeQ@mail.gmail.com>
	<20141031143338.GB6913@laptop.dumpdata.com>
	<54576188.9050500@m2r.biz>
	<20141103160347.GD1638@laptop.dumpdata.com>
	<545B8FCE.60902@m2r.biz>
In-Reply-To: <545B8FCE.60902@m2r.biz>
Cc: Artem Mygaiev <artem.mygaiev@globallogic.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, mengxu@cis.upenn.edu,
	M A Young <m.a.young@durham.ac.uk>, chao.p.peng@linux.intel.com,
	zhigang.x.wang@oracle.com, Parth Dixit <parth.dixit@linaro.org>,
	davi.d.vrabel@citrix.com, Paul.Skentzos@dornerworks.com,
	wency@cn.fujitsu.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, Daniel Kiper <daniel.kiper@oracle.com>,
	josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	yjhyun.yoo@samsung.com, Olaf Hering <olaf@aepfle.de>,
	Ian Campbell <ian.campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mcgrof@suse.com, Julien Grall <julien.grall@linaro.org>,
	Dave Scott <dave.scott@citrix.com>, robert.vanvossen@dornerworks.com,
	Roy Franz <roy.franz@linaro.org>, Yang Z Zhang <yang.z.zhang@intel.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Matt Wilson <msw@amazon.com>, spice-devel@lists.freedesktop.org,
	boris.ostrovsky@oracle.com, andrii.tseglytskyi@globallogic.com,
	Juergen Gross <jgross@suse.com>,
	Thomas Leonard <talex5@gmail.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, aravindp@cisco.com,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Suriyan Ramasami <suriyan.r@gmail.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Steve.VanderLeest@dornerworks.com, Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	Don Slutz <dslutz@verizon.com>, tklengyel@sec.in.tum.de,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Suravee.Suthikulpanit@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tiejun Chen <tiejun.chen@intel.com>, malcolm.crossley@citrix.com,
	yanghy@cn.fujitsu.com, Vijaya.Kumar@caviumnetworks.com,
	feng.wu@intel.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Is: QXL in Xen (busted) Was :Re: Xen 4.5-rc1 update
 (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 06/11/2014 16:12, Fabio Fantoni ha scritto:
> Il 03/11/2014 17:03, Konrad Rzeszutek Wilk ha scritto:
>> On Mon, Nov 03, 2014 at 12:05:44PM +0100, Fabio Fantoni wrote:
>>> Il 31/10/2014 15:33, Konrad Rzeszutek Wilk ha scritto:
>>>>> I always posted all versions of the patch in xen-devel, the latest 
>>>>> was long
>>>>> time ago.
>>>> Sometimes you need to poke the maintainers. They (at least
>>>> I do) have mailboxes so packed that sometimes emails end up
>>>> going missing. But I think their arguments is going to be:
>>>> lets figure out what is broken before putting this in the source.
>>>>
>>>> .. snip..
>>>>>> Does SPICE always have to be enabled to use QXL?
>>>>>>
>>>> .. snip ..
>>>>> Xen with spice full working on both windows and linux (including
>>>>> save/restore) used for both vkvm and thin client I think would be 
>>>>> perfect.
>>>> Right. But there is some work needed in that area (figure out what
>>>> is happening on Linux).
>>>>
>>>> ..snip..
>>>>>> OK, looking at how the driver is setup - it seems that there is 
>>>>>> an QXL
>>>>>> KMS driver. If you boot without Xorg running but just with in the 
>>>>>> console
>>>>>> can
>>>>>> you use 'fbset' or any other framebuffer tools (linux-fb-tools)?
>>>>>> That is I am curious to see whether the 'FB' is working properly 
>>>>>> first
>>>>>> before figuring out whether Xorg is working.
>>>>>>
>>>>> Some tests ago I tried without xorg to see if kernel parts is ok 
>>>>> (advice of
>>>>> other developer) and seems was ok.
>>>> What did you test? There is an 'drm-test' tool that was floating 
>>>> around?
>>>> (http://cgit.freedesktop.org/mesa/drm/)
>>>>
>>>> It allows you to run most (if not all) of the Xorg functionality - but
>>>> using an tool from user-space - and with much more exposure of what
>>>> went wrong.
>>>>
>>>> Could you try the following (without having Xorg in either guest):
>>>>   1). Boot up your KVM guest, install said tool - run it. Record what
>>>>      works and what does not.
>>>>
>>>>   2). Boot up your Xen guest, and do the same thing.
>>>>
>>>> That should narrow down which of the hundreds' of DRM ioctls is 
>>>> failing
>>>> when using spice under Xen. And that ought to help narrow down this 
>>>> further.
>>>>
>>>> I can help you a bit by sending you some debug patches, thought I do
>>>> have to warn you that I am under a lot of time-pressure so my response
>>>> is not as fast as I would want it to be.
>>>>
>>> I tested only without xorg, just console with drm without particular 
>>> tests.
>>>
>>> I can't find the drm-test tool you mentioned, is it available in debian
>>> and/or fedora repositories an what is it called?
>>> I also did a quick google search and found only something about 
>>> wayland and
>>> not about X.org.
>> I mentioned the URL in the email, but here it is again:
>>
>> http://cgit.freedesktop.org/mesa/drm/
>>
>> You will need to compile it, etc.
>
> Thanks for your reply, sorry for my late reply, I was busy.
> I prepared 2 Trusty (ubuntu 14.04) vm minimal for the tests (one on 
> kvm and one on xen).
> Started and both arrive to console login successfull and they have qxl 
> kernel module active:
>
> lsmod
> ...
> qxl
> drm_kms_helper qxl
> drm qxl,ttm,drm_kms_helper
> ...
>
> I downloaded compile and installed mesa/drm from git master brach
> ./configure
> make
> sudo make install
>
> After I tried to execute the tests binary I found under test but all 
> fails:
> sudo ./modetest
> ...
> no device found.
>
> sudo ./vbltest
> ...
> failed to load any modules, aborting.
>
> sudo ./kmstest
> main: Could not open device (Operation not permitted)
>
> Same result on both xen and kvm.
> Seems that there is any module in mesa/drm about qxl even if kernel 
> modules is present and active and qxl xorg driver use it FWIK.
>
> I did another fast search on google without found how to test qxl drm 
> to find the difference between xen and kvm.
> Someone can tell me what I must do to take useful data about xen and 
> kvm difference for qxl problem?
>
> I added also spice-devel to cc.
>
> Thanks for any reply and sorry for my bad english.

Ping...
Is there nobody that can help me please?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:32:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVE1-00017h-Rv; Wed, 12 Nov 2014 10:32:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XoVE0-000173-7l
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 10:32:32 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	8D/F0-22777-F3733645; Wed, 12 Nov 2014 10:32:31 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415788350!5549061!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9431 invoked from network); 12 Nov 2014 10:32:30 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:32:30 -0000
Received: by mail-wi0-f182.google.com with SMTP id d1so4371107wiv.3
	for <xen-devel@lists.xenproject.org>;
	Wed, 12 Nov 2014 02:32:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=DqQRuNhUs6PrzUKBnxVSVluZOa8RRfT3MRaratY0K98=;
	b=JareqkNNA6CrjkbbCmCAhBLc67fV2Qwz6Sj1RwKkC+5n4qLapg13YXKpzJs598O+YJ
	WS8GI74C1mE7ztptq0sIzuTygbOi4UeAHAZE1u6QNPt4n5EPNVJzOkOaQ3YxMb6qczL6
	OlW+ZgZ+Jh+c8TrK3JkP8fah/g42S6vjmgnv2cqFH9Ve6YaxMoonZ2tzqETrSHJk56PK
	KXztIREFvPMR3Z+tcBfOINcMsenkwt2J4uAD/h2fVXtjXgKawignoV5dnoDLvVgLp6Ha
	HG6T9We1jT423CeMlZcikOI0uBZk9xR5t9Z/F+0uN8QwhKRb69PriEnzq2OWVW30MVyf
	jeYg==
X-Gm-Message-State: ALoCoQl0NNn/KFc0+Au6zx59anYPNgWuaQNinQi/yyfhdo0OyYHpwtF1FJl/LmFHsFXRkN9WeOWZ
X-Received: by 10.194.178.231 with SMTP id db7mr60961964wjc.112.1415788350211; 
	Wed, 12 Nov 2014 02:32:30 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id gw6sm21082873wib.8.2014.11.12.02.32.23
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 12 Nov 2014 02:32:29 -0800 (PST)
Message-ID: <5463373C.2090602@m2r.biz>
Date: Wed, 12 Nov 2014 11:32:28 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141024180843.EA0DF10D709@laptop.dumpdata.com>
	<544B5AF5.7050103@m2r.biz>
	<20141027161542.GK4050@laptop.dumpdata.com>
	<544F987E.5060508@m2r.biz>
	<20141028171811.GA27336@laptop.dumpdata.com>
	<CABMPFziN9eM6_0_mfQcamOqyQBXVOOD5amom+7JTv=LorbbTeQ@mail.gmail.com>
	<20141031143338.GB6913@laptop.dumpdata.com>
	<54576188.9050500@m2r.biz>
	<20141103160347.GD1638@laptop.dumpdata.com>
	<545B8FCE.60902@m2r.biz>
In-Reply-To: <545B8FCE.60902@m2r.biz>
Cc: Artem Mygaiev <artem.mygaiev@globallogic.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, mengxu@cis.upenn.edu,
	M A Young <m.a.young@durham.ac.uk>, chao.p.peng@linux.intel.com,
	zhigang.x.wang@oracle.com, Parth Dixit <parth.dixit@linaro.org>,
	davi.d.vrabel@citrix.com, Paul.Skentzos@dornerworks.com,
	wency@cn.fujitsu.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, Daniel Kiper <daniel.kiper@oracle.com>,
	josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	yjhyun.yoo@samsung.com, Olaf Hering <olaf@aepfle.de>,
	Ian Campbell <ian.campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mcgrof@suse.com, Julien Grall <julien.grall@linaro.org>,
	Dave Scott <dave.scott@citrix.com>, robert.vanvossen@dornerworks.com,
	Roy Franz <roy.franz@linaro.org>, Yang Z Zhang <yang.z.zhang@intel.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Matt Wilson <msw@amazon.com>, spice-devel@lists.freedesktop.org,
	boris.ostrovsky@oracle.com, andrii.tseglytskyi@globallogic.com,
	Juergen Gross <jgross@suse.com>,
	Thomas Leonard <talex5@gmail.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, aravindp@cisco.com,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Suriyan Ramasami <suriyan.r@gmail.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Steve.VanderLeest@dornerworks.com, Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	Don Slutz <dslutz@verizon.com>, tklengyel@sec.in.tum.de,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Suravee.Suthikulpanit@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tiejun Chen <tiejun.chen@intel.com>, malcolm.crossley@citrix.com,
	yanghy@cn.fujitsu.com, Vijaya.Kumar@caviumnetworks.com,
	feng.wu@intel.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Is: QXL in Xen (busted) Was :Re: Xen 4.5-rc1 update
 (RC1 is out 2014-Oct-24th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 06/11/2014 16:12, Fabio Fantoni ha scritto:
> Il 03/11/2014 17:03, Konrad Rzeszutek Wilk ha scritto:
>> On Mon, Nov 03, 2014 at 12:05:44PM +0100, Fabio Fantoni wrote:
>>> Il 31/10/2014 15:33, Konrad Rzeszutek Wilk ha scritto:
>>>>> I always posted all versions of the patch in xen-devel, the latest 
>>>>> was long
>>>>> time ago.
>>>> Sometimes you need to poke the maintainers. They (at least
>>>> I do) have mailboxes so packed that sometimes emails end up
>>>> going missing. But I think their arguments is going to be:
>>>> lets figure out what is broken before putting this in the source.
>>>>
>>>> .. snip..
>>>>>> Does SPICE always have to be enabled to use QXL?
>>>>>>
>>>> .. snip ..
>>>>> Xen with spice full working on both windows and linux (including
>>>>> save/restore) used for both vkvm and thin client I think would be 
>>>>> perfect.
>>>> Right. But there is some work needed in that area (figure out what
>>>> is happening on Linux).
>>>>
>>>> ..snip..
>>>>>> OK, looking at how the driver is setup - it seems that there is 
>>>>>> an QXL
>>>>>> KMS driver. If you boot without Xorg running but just with in the 
>>>>>> console
>>>>>> can
>>>>>> you use 'fbset' or any other framebuffer tools (linux-fb-tools)?
>>>>>> That is I am curious to see whether the 'FB' is working properly 
>>>>>> first
>>>>>> before figuring out whether Xorg is working.
>>>>>>
>>>>> Some tests ago I tried without xorg to see if kernel parts is ok 
>>>>> (advice of
>>>>> other developer) and seems was ok.
>>>> What did you test? There is an 'drm-test' tool that was floating 
>>>> around?
>>>> (http://cgit.freedesktop.org/mesa/drm/)
>>>>
>>>> It allows you to run most (if not all) of the Xorg functionality - but
>>>> using an tool from user-space - and with much more exposure of what
>>>> went wrong.
>>>>
>>>> Could you try the following (without having Xorg in either guest):
>>>>   1). Boot up your KVM guest, install said tool - run it. Record what
>>>>      works and what does not.
>>>>
>>>>   2). Boot up your Xen guest, and do the same thing.
>>>>
>>>> That should narrow down which of the hundreds' of DRM ioctls is 
>>>> failing
>>>> when using spice under Xen. And that ought to help narrow down this 
>>>> further.
>>>>
>>>> I can help you a bit by sending you some debug patches, thought I do
>>>> have to warn you that I am under a lot of time-pressure so my response
>>>> is not as fast as I would want it to be.
>>>>
>>> I tested only without xorg, just console with drm without particular 
>>> tests.
>>>
>>> I can't find the drm-test tool you mentioned, is it available in debian
>>> and/or fedora repositories an what is it called?
>>> I also did a quick google search and found only something about 
>>> wayland and
>>> not about X.org.
>> I mentioned the URL in the email, but here it is again:
>>
>> http://cgit.freedesktop.org/mesa/drm/
>>
>> You will need to compile it, etc.
>
> Thanks for your reply, sorry for my late reply, I was busy.
> I prepared 2 Trusty (ubuntu 14.04) vm minimal for the tests (one on 
> kvm and one on xen).
> Started and both arrive to console login successfull and they have qxl 
> kernel module active:
>
> lsmod
> ...
> qxl
> drm_kms_helper qxl
> drm qxl,ttm,drm_kms_helper
> ...
>
> I downloaded compile and installed mesa/drm from git master brach
> ./configure
> make
> sudo make install
>
> After I tried to execute the tests binary I found under test but all 
> fails:
> sudo ./modetest
> ...
> no device found.
>
> sudo ./vbltest
> ...
> failed to load any modules, aborting.
>
> sudo ./kmstest
> main: Could not open device (Operation not permitted)
>
> Same result on both xen and kvm.
> Seems that there is any module in mesa/drm about qxl even if kernel 
> modules is present and active and qxl xorg driver use it FWIK.
>
> I did another fast search on google without found how to test qxl drm 
> to find the difference between xen and kvm.
> Someone can tell me what I must do to take useful data about xen and 
> kvm difference for qxl problem?
>
> I added also spice-devel to cc.
>
> Thanks for any reply and sorry for my bad english.

Ping...
Is there nobody that can help me please?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:32:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVEM-0001Ax-9E; Wed, 12 Nov 2014 10:32:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoVEL-0001Aj-8c
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:32:53 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	95/C1-22777-45733645; Wed, 12 Nov 2014 10:32:52 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415788370!10861972!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26343 invoked from network); 12 Nov 2014 10:32:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-206.messagelabs.com with SMTP;
	12 Nov 2014 10:32:51 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 12 Nov 2014 02:30:27 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,368,1413270000"; d="scan'208";a="635614123"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by orsmga002.jf.intel.com with ESMTP; 12 Nov 2014 02:32:48 -0800
Message-ID: <54633750.4040602@intel.com>
Date: Wed, 12 Nov 2014 18:32:48 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<54633402.7040205@intel.com>
	<5463436E0200007800046B92@mail.emea.novell.com>
In-Reply-To: <5463436E0200007800046B92@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/12 18:24, Jan Beulich wrote:
>>>> On 12.11.14 at 11:18, <tiejun.chen@intel.com> wrote:
>> On 2014/11/12 16:55, Jan Beulich wrote:
>>>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>>>> I don't see any feedback to this point, so I think you still prefer we
>>>> should do all check in the callback function.
>>>
>>> As a draft this looks reasonable, but there are various bugs to be
>>> dealt with along with cosmetic issues (I'll point out the former, but
>>> I'm tired of pointing out the latter once again - please go back to
>>> earlier reviews of patches to refresh e.g. what types to use for
>>> loop variables).
>>>
>>>> I tried to address this but obviously we have to pass each 'pdf' to
>>>> callback functions,
>>>
>>> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
>>> but something more neutral (maybe "id"). And you again lost the
>>
>> Okay.
>>
>>> segment there.
>>
>> I think we don't need segment since when we passthrough a device, that
>> domain doesn't matter with the real segment in phydev.
>
> How can this not matter? If 0001:bb:dd.f is associated with an RMRR
> but 0000:bb:dd.f isn't, it's quite relevant which one is being handed
> to a guest.
>

In passthrough case this is needed so I will add this.

Thanks
Tiejun



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:32:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVEM-0001Ax-9E; Wed, 12 Nov 2014 10:32:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XoVEL-0001Aj-8c
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:32:53 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	95/C1-22777-45733645; Wed, 12 Nov 2014 10:32:52 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415788370!10861972!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26343 invoked from network); 12 Nov 2014 10:32:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-206.messagelabs.com with SMTP;
	12 Nov 2014 10:32:51 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 12 Nov 2014 02:30:27 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,368,1413270000"; d="scan'208";a="635614123"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.166])
	([10.238.128.166])
	by orsmga002.jf.intel.com with ESMTP; 12 Nov 2014 02:32:48 -0800
Message-ID: <54633750.4040602@intel.com>
Date: Wed, 12 Nov 2014 18:32:48 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<54633402.7040205@intel.com>
	<5463436E0200007800046B92@mail.emea.novell.com>
In-Reply-To: <5463436E0200007800046B92@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/12 18:24, Jan Beulich wrote:
>>>> On 12.11.14 at 11:18, <tiejun.chen@intel.com> wrote:
>> On 2014/11/12 16:55, Jan Beulich wrote:
>>>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>>>> I don't see any feedback to this point, so I think you still prefer we
>>>> should do all check in the callback function.
>>>
>>> As a draft this looks reasonable, but there are various bugs to be
>>> dealt with along with cosmetic issues (I'll point out the former, but
>>> I'm tired of pointing out the latter once again - please go back to
>>> earlier reviews of patches to refresh e.g. what types to use for
>>> loop variables).
>>>
>>>> I tried to address this but obviously we have to pass each 'pdf' to
>>>> callback functions,
>>>
>>> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
>>> but something more neutral (maybe "id"). And you again lost the
>>
>> Okay.
>>
>>> segment there.
>>
>> I think we don't need segment since when we passthrough a device, that
>> domain doesn't matter with the real segment in phydev.
>
> How can this not matter? If 0001:bb:dd.f is associated with an RMRR
> but 0000:bb:dd.f isn't, it's quite relevant which one is being handed
> to a guest.
>

In passthrough case this is needed so I will add this.

Thanks
Tiejun



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:36:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoVHv-0001dy-Ju; Wed, 12 Nov 2014 10:36:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoVHu-0001di-A1
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:36:34 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9F/E1-24532-13833645; Wed, 12 Nov 2014 10:36:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415788592!12102174!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3324 invoked from network); 12 Nov 2014 10:36:33 -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;
	12 Nov 2014 10:36:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190462672"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 05:36:11 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoVHW-0001Vn-UL;
	Wed, 12 Nov 2014 10:36:10 +0000
Date: Wed, 12 Nov 2014 10:36:10 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141112103610.GA25821@zion.uk.xensource.com>
References: <1415713603-14611-1-git-send-email-wei.liu2@citrix.com>
	<1415786484.25176.45.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415786484.25176.45.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 10:01:24AM +0000, Ian Campbell wrote:
> On Tue, 2014-11-11 at 13:46 +0000, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: George Dunlap <george.dunlap@eu.citrix.com>
> > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > ---
> > This is a simple enough bug fix I think it should just go in.
> 
> Probably, but can you explain in the commit log what the symptoms of not
> doing it are, IOW why it is required.
> 

OK, I will resubmit with updated commit log.

> > ---
> >  tools/libxl/libxl.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..de23fec 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
> >                                                                          \
> >          GCNEW(aodev);                                                   \
> >          libxl__prepare_ao_device(ao, aodev);                            \
> > +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
> >          aodev->callback = device_addrm_aocomplete;                      \
> >          aodev->update_json = true;                                      \
> >          libxl__device_##type##_add(egc, domid, type, aodev);            \
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:36:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoVHv-0001e6-Uy; Wed, 12 Nov 2014 10:36:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoVHu-0001dr-VX
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 10:36:35 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	5C/29-28296-23833645; Wed, 12 Nov 2014 10:36:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415788591!10757448!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23771 invoked from network); 12 Nov 2014 10:36:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:36:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191908350"
Message-ID: <1415788588.25176.56.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 12 Nov 2014 10:36:28 +0000
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/9] Host allocation scoring
	improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> Here, I'm trying to fix the way that osstest gets far too obsessed
> about particular failing hosts.

All fine by me, not that I've really grokked the bits towards the end.
(I will try to if you want)

> 
>  1/9 cs-adjust-flight: Fix doc about /<pcre> to match
>  2/9 ts-hosts-allocate-Executive: allow uncompressed
>  3/9 Osstest/Executive.pm: Debug log same-host status
>  4/9 ts-hosts-allocate-Executive: Move $variation_age
>  5/9 ts-hosts-allocate-Executive: Do not prefer fast
>  6/9 ts-hosts-allocate-Executive: Clarify an
>  7/9 ts-hosts-allocate-Executive: Score for
>  8/9 ts-hosts-allocate-Executive: Redo
>  9/9 ts-hosts-allocate-Executive: Radically reduce
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:36:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoVHv-0001dy-Ju; Wed, 12 Nov 2014 10:36:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoVHu-0001di-A1
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:36:34 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9F/E1-24532-13833645; Wed, 12 Nov 2014 10:36:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415788592!12102174!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3324 invoked from network); 12 Nov 2014 10:36:33 -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;
	12 Nov 2014 10:36:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190462672"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 05:36:11 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoVHW-0001Vn-UL;
	Wed, 12 Nov 2014 10:36:10 +0000
Date: Wed, 12 Nov 2014 10:36:10 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141112103610.GA25821@zion.uk.xensource.com>
References: <1415713603-14611-1-git-send-email-wei.liu2@citrix.com>
	<1415786484.25176.45.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415786484.25176.45.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 10:01:24AM +0000, Ian Campbell wrote:
> On Tue, 2014-11-11 at 13:46 +0000, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: George Dunlap <george.dunlap@eu.citrix.com>
> > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > ---
> > This is a simple enough bug fix I think it should just go in.
> 
> Probably, but can you explain in the commit log what the symptoms of not
> doing it are, IOW why it is required.
> 

OK, I will resubmit with updated commit log.

> > ---
> >  tools/libxl/libxl.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..de23fec 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
> >                                                                          \
> >          GCNEW(aodev);                                                   \
> >          libxl__prepare_ao_device(ao, aodev);                            \
> > +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
> >          aodev->callback = device_addrm_aocomplete;                      \
> >          aodev->update_json = true;                                      \
> >          libxl__device_##type##_add(egc, domid, type, aodev);            \
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:36:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10: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 1XoVHv-0001e6-Uy; Wed, 12 Nov 2014 10:36:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoVHu-0001dr-VX
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 10:36:35 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	5C/29-28296-23833645; Wed, 12 Nov 2014 10:36:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415788591!10757448!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23771 invoked from network); 12 Nov 2014 10:36:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:36:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191908350"
Message-ID: <1415788588.25176.56.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 12 Nov 2014 10:36:28 +0000
In-Reply-To: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/9] Host allocation scoring
	improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> Here, I'm trying to fix the way that osstest gets far too obsessed
> about particular failing hosts.

All fine by me, not that I've really grokked the bits towards the end.
(I will try to if you want)

> 
>  1/9 cs-adjust-flight: Fix doc about /<pcre> to match
>  2/9 ts-hosts-allocate-Executive: allow uncompressed
>  3/9 Osstest/Executive.pm: Debug log same-host status
>  4/9 ts-hosts-allocate-Executive: Move $variation_age
>  5/9 ts-hosts-allocate-Executive: Do not prefer fast
>  6/9 ts-hosts-allocate-Executive: Clarify an
>  7/9 ts-hosts-allocate-Executive: Score for
>  8/9 ts-hosts-allocate-Executive: Redo
>  9/9 ts-hosts-allocate-Executive: Radically reduce
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:38:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVJM-0001tE-3r; Wed, 12 Nov 2014 10:38:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1XoVJI-0001t0-HN
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:38:00 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	20/95-17735-78833645; Wed, 12 Nov 2014 10:37:59 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415788678!10815892!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI5MDUzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16479 invoked from network); 12 Nov 2014 10:37:59 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 10:37:59 -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=spMSVRsYCVf8qj9d886L0OXxwwPRRiyNm09BdBKLJv3zgoArpOTYt536
	o+VhIKWs+TsPZFrARpvrKTI/vYs3CwTqauMf9NO/p8594DUD/SNENC9oE
	iqQKuy6EQtzR4jH9PdsVxELQFz9NxDp4Gs7lnPgFCFkVc9kFaNpWq0oWK
	GQm9hJSV59gOHZmQ/x7SSAjiDrZSOviBzcSrLm0OCvgmsDIeQ0nUN8xkj
	Yg6KmtpmyaFPlcBo/7848AlE5+Rdh;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1415788678; x=1447324678;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=Ldr/POgEkBn5oPO1rqAhnQZbQz41WFBlCsbtFq1bsNw=;
	b=n/z1CRkxi/AiIKLLTIvtCttbLPWOJ71v1paby/W0HzKE6KUmhX4ONb9U
	pb5qKx7nDP/SIlIPIkwyvBFmKvqiq7tlH7cnfjaFj8c8FRGKjppt8mSfi
	WjbylNIbHXzCMf7ae+rvmM8JokKAW4jiTpor9N0ycHHhweTclwoOxqwLE
	KKzKJSjBxZRDHr3AOKGKMzJnDa7P2tv9Rvn/8myzRe4lZp0X22VynpLTX
	1uhs4p0Fo+lblbI2A2B9TUke4S83V;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="5.07,368,1413237600"; d="scan'208";a="212949439"
Received: from unknown (HELO abgdgate60u.abg.fsc.net) ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 12 Nov 2014 11:37:57 +0100
X-IronPort-AV: E=Sophos;i="5.07,368,1413237600"; d="scan'208";a="96091725"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate60u.abg.fsc.net with ESMTP; 12 Nov 2014 11:37:57 +0100
Received: from amur.localnet (amur.mch.fsc.net [10.172.102.32])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 1150DA93F14;
	Wed, 12 Nov 2014 11:37:58 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 11:37:57 +0100
Message-ID: <1470153.1jGKfzL4FX@amur>
User-Agent: KMail/4.11.5 (Linux/3.11.10-21-xen; KDE/4.11.5; x86_64; ; )
In-Reply-To: <5463358A.7000108@suse.com>
References: <19147765.FEreuxd8Ya@amur> <3016118.gIEEAtXxHA@amur>
	<5463358A.7000108@suse.com>
MIME-Version: 1.0
Cc: Juergen Gross <jgross@suse.com>
Subject: Re: [Xen-devel] Wrong cpupool 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

Am Mittwoch 12 November 2014, 11:25:14 schrieb Juergen Gross:
> On 11/12/2014 10:53 AM, Dietmar Hahn wrote:
> > Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross:
> >> Hi again,
> >>
> >> On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
> >>> Hi list,
> >>>
> >>> When creating a cpupool, starting and destroying a guest within this pool,
> >>> then removing this pool doesn't work because of EBUSY.
> >>>
> >>> It seems the cause of this behavior is the commit
> >>> bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
> >>>
> >>> In domain_kill() the function sched_move_domain() gets called changing the
> >>> d->cpupool pointer to the new cpupool without incrementing/decrementing the
> >>> counters "n_dom" of the new/old cpupool.
> >>>
> >>> This leads to decrementing the wrong  cpupool0->n_dom counter when
> >>> cpupool_rm_domain() gets called at the end and my own cpupool can't be
> >>> destroyed because n_dom = 1!
> >>>
> >>> I don't have a fast patch because I'am not enough familiar with the code
> >>> this time but I think it should be fixed for 4.5.
> >>
> >> Please discard previous patch, try this one.
> >
> > Yes this patch works.
> 
> Thanks. Can I add your "tested-by:"?

Sorry forgot it!

Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

> 
> > But I think in general a better solution would be to have the changing of the
> > cpupool pointer in sched_move_domain() together with the increment/decrement
> > of the counters but I see the locking problem.
> 
> The scheduler should never change cpupool owned data. The cpupool
> pointer is domain data, so changing this is okay.
> 
> 
> Juergen
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:38:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVJM-0001tE-3r; Wed, 12 Nov 2014 10:38:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1XoVJI-0001t0-HN
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:38:00 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	20/95-17735-78833645; Wed, 12 Nov 2014 10:37:59 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415788678!10815892!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI5MDUzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16479 invoked from network); 12 Nov 2014 10:37:59 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 10:37:59 -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=spMSVRsYCVf8qj9d886L0OXxwwPRRiyNm09BdBKLJv3zgoArpOTYt536
	o+VhIKWs+TsPZFrARpvrKTI/vYs3CwTqauMf9NO/p8594DUD/SNENC9oE
	iqQKuy6EQtzR4jH9PdsVxELQFz9NxDp4Gs7lnPgFCFkVc9kFaNpWq0oWK
	GQm9hJSV59gOHZmQ/x7SSAjiDrZSOviBzcSrLm0OCvgmsDIeQ0nUN8xkj
	Yg6KmtpmyaFPlcBo/7848AlE5+Rdh;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1415788678; x=1447324678;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=Ldr/POgEkBn5oPO1rqAhnQZbQz41WFBlCsbtFq1bsNw=;
	b=n/z1CRkxi/AiIKLLTIvtCttbLPWOJ71v1paby/W0HzKE6KUmhX4ONb9U
	pb5qKx7nDP/SIlIPIkwyvBFmKvqiq7tlH7cnfjaFj8c8FRGKjppt8mSfi
	WjbylNIbHXzCMf7ae+rvmM8JokKAW4jiTpor9N0ycHHhweTclwoOxqwLE
	KKzKJSjBxZRDHr3AOKGKMzJnDa7P2tv9Rvn/8myzRe4lZp0X22VynpLTX
	1uhs4p0Fo+lblbI2A2B9TUke4S83V;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="5.07,368,1413237600"; d="scan'208";a="212949439"
Received: from unknown (HELO abgdgate60u.abg.fsc.net) ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 12 Nov 2014 11:37:57 +0100
X-IronPort-AV: E=Sophos;i="5.07,368,1413237600"; d="scan'208";a="96091725"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate60u.abg.fsc.net with ESMTP; 12 Nov 2014 11:37:57 +0100
Received: from amur.localnet (amur.mch.fsc.net [10.172.102.32])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 1150DA93F14;
	Wed, 12 Nov 2014 11:37:58 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 11:37:57 +0100
Message-ID: <1470153.1jGKfzL4FX@amur>
User-Agent: KMail/4.11.5 (Linux/3.11.10-21-xen; KDE/4.11.5; x86_64; ; )
In-Reply-To: <5463358A.7000108@suse.com>
References: <19147765.FEreuxd8Ya@amur> <3016118.gIEEAtXxHA@amur>
	<5463358A.7000108@suse.com>
MIME-Version: 1.0
Cc: Juergen Gross <jgross@suse.com>
Subject: Re: [Xen-devel] Wrong cpupool 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

Am Mittwoch 12 November 2014, 11:25:14 schrieb Juergen Gross:
> On 11/12/2014 10:53 AM, Dietmar Hahn wrote:
> > Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross:
> >> Hi again,
> >>
> >> On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
> >>> Hi list,
> >>>
> >>> When creating a cpupool, starting and destroying a guest within this pool,
> >>> then removing this pool doesn't work because of EBUSY.
> >>>
> >>> It seems the cause of this behavior is the commit
> >>> bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
> >>>
> >>> In domain_kill() the function sched_move_domain() gets called changing the
> >>> d->cpupool pointer to the new cpupool without incrementing/decrementing the
> >>> counters "n_dom" of the new/old cpupool.
> >>>
> >>> This leads to decrementing the wrong  cpupool0->n_dom counter when
> >>> cpupool_rm_domain() gets called at the end and my own cpupool can't be
> >>> destroyed because n_dom = 1!
> >>>
> >>> I don't have a fast patch because I'am not enough familiar with the code
> >>> this time but I think it should be fixed for 4.5.
> >>
> >> Please discard previous patch, try this one.
> >
> > Yes this patch works.
> 
> Thanks. Can I add your "tested-by:"?

Sorry forgot it!

Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

> 
> > But I think in general a better solution would be to have the changing of the
> > cpupool pointer in sched_move_domain() together with the increment/decrement
> > of the counters but I see the locking problem.
> 
> The scheduler should never change cpupool owned data. The cpupool
> pointer is domain data, so changing this is okay.
> 
> 
> Juergen
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:39:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVKq-00025u-5v; Wed, 12 Nov 2014 10:39:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoVKo-00025e-Rh
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:39:34 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	E4/C9-05632-6E833645; Wed, 12 Nov 2014 10:39:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415788772!10835622!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12135 invoked from network); 12 Nov 2014 10:39:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:39:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190463241"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 05:39:31 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XoVKl-0001bs-9r;
	Wed, 12 Nov 2014 10:39:31 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 10:39:31 +0000
Message-ID: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

... otherwise when device add operation fails, the error message looks
like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
device", which is not very helpful.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..de23fec 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
                                                                         \
         GCNEW(aodev);                                                   \
         libxl__prepare_ao_device(ao, aodev);                            \
+        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
         aodev->callback = device_addrm_aocomplete;                      \
         aodev->update_json = true;                                      \
         libxl__device_##type##_add(egc, domid, type, aodev);            \
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:39:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVKq-00025u-5v; Wed, 12 Nov 2014 10:39:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoVKo-00025e-Rh
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:39:34 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	E4/C9-05632-6E833645; Wed, 12 Nov 2014 10:39:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415788772!10835622!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12135 invoked from network); 12 Nov 2014 10:39:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:39:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190463241"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 05:39:31 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XoVKl-0001bs-9r;
	Wed, 12 Nov 2014 10:39:31 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 10:39:31 +0000
Message-ID: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

... otherwise when device add operation fails, the error message looks
like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
device", which is not very helpful.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..de23fec 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
                                                                         \
         GCNEW(aodev);                                                   \
         libxl__prepare_ao_device(ao, aodev);                            \
+        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
         aodev->callback = device_addrm_aocomplete;                      \
         aodev->update_json = true;                                      \
         libxl__device_##type##_add(egc, domid, type, aodev);            \
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:40:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:40:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVM3-0002M0-Tj; Wed, 12 Nov 2014 10:40:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoVM2-0002Lg-Dx
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:40:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B0/F4-09936-13933645; Wed, 12 Nov 2014 10:40:49 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415788848!12113053!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16138 invoked from network); 12 Nov 2014 10:40:49 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 10:40:49 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3A410AAC3;
	Wed, 12 Nov 2014 10:40:48 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xen.org,
	jbeulich@suse.com,
	dietmar.hahn@ts.fujitsu.com
Date: Wed, 12 Nov 2014 11:40:40 +0100
Message-Id: <1415788840-19497-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
	destroying 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of domains
is nor adjusted when a domain is moved to cpupool0 in kill_domain().

Correct this by introducing a cpupool function doing the move
instead of open coding it by calling sched_move_domain().

Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
 xen/common/domain.c     |  2 +-
 xen/include/xen/sched.h |  1 +
 3 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 73249d3..c6e3869 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
 }
 
 /*
+ * Move domain to another cpupool
+ */
+static int cpupool_move_domain_unlocked(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    d->cpupool->n_dom--;
+    ret = sched_move_domain(d, c);
+    if ( ret )
+        d->cpupool->n_dom++;
+    else
+        c->n_dom++;
+
+    return ret;
+}
+int cpupool_move_domain(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    spin_lock(&cpupool_lock);
+
+    ret = cpupool_move_domain_unlocked(d, c);
+
+    spin_unlock(&cpupool_lock);
+
+    return ret;
+}
+
+/*
  * assign a specific cpu to a cpupool
  * cpupool_lock must be held
  */
@@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
                 ret = -EBUSY;
                 break;
             }
-            c->n_dom--;
-            ret = sched_move_domain(d, cpupool0);
+            ret = cpupool_move_domain_unlocked(d, cpupool0);
             if ( ret )
-            {
-                c->n_dom++;
                 break;
-            }
-            cpupool0->n_dom++;
         }
         rcu_read_unlock(&domlist_read_lock);
         if ( ret )
@@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
                         d->domain_id, op->cpupool_id);
         ret = -ENOENT;
         spin_lock(&cpupool_lock);
+
         c = cpupool_find_by_id(op->cpupool_id);
         if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
-        {
-            d->cpupool->n_dom--;
-            ret = sched_move_domain(d, c);
-            if ( ret )
-                d->cpupool->n_dom++;
-            else
-                c->n_dom++;
-        }
+            ret = cpupool_move_domain_unlocked(d, c);
+
         spin_unlock(&cpupool_lock);
         cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
                         d->domain_id, op->cpupool_id, ret);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index a3f51ec..4a62c1d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
                 rc = -EAGAIN;
             break;
         }
-        if ( sched_move_domain(d, cpupool0) )
+        if ( cpupool_move_domain(d, cpupool0) )
             return -EAGAIN;
         for_each_vcpu ( d, v )
             unmap_vcpu_info(v);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index c5157e6..46fc6e3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
 void cpupool_put(struct cpupool *pool);
 int cpupool_add_domain(struct domain *d, int poolid);
 void cpupool_rm_domain(struct domain *d);
+int cpupool_move_domain(struct domain *d, struct cpupool *c);
 int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
 void schedule_dump(struct cpupool *c);
 extern void dump_runq(unsigned char key);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:40:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:40:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVM3-0002M0-Tj; Wed, 12 Nov 2014 10:40:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoVM2-0002Lg-Dx
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:40:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B0/F4-09936-13933645; Wed, 12 Nov 2014 10:40:49 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415788848!12113053!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16138 invoked from network); 12 Nov 2014 10:40:49 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 10:40:49 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3A410AAC3;
	Wed, 12 Nov 2014 10:40:48 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xen.org,
	jbeulich@suse.com,
	dietmar.hahn@ts.fujitsu.com
Date: Wed, 12 Nov 2014 11:40:40 +0100
Message-Id: <1415788840-19497-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
	destroying 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of domains
is nor adjusted when a domain is moved to cpupool0 in kill_domain().

Correct this by introducing a cpupool function doing the move
instead of open coding it by calling sched_move_domain().

Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
 xen/common/domain.c     |  2 +-
 xen/include/xen/sched.h |  1 +
 3 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 73249d3..c6e3869 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
 }
 
 /*
+ * Move domain to another cpupool
+ */
+static int cpupool_move_domain_unlocked(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    d->cpupool->n_dom--;
+    ret = sched_move_domain(d, c);
+    if ( ret )
+        d->cpupool->n_dom++;
+    else
+        c->n_dom++;
+
+    return ret;
+}
+int cpupool_move_domain(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    spin_lock(&cpupool_lock);
+
+    ret = cpupool_move_domain_unlocked(d, c);
+
+    spin_unlock(&cpupool_lock);
+
+    return ret;
+}
+
+/*
  * assign a specific cpu to a cpupool
  * cpupool_lock must be held
  */
@@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
                 ret = -EBUSY;
                 break;
             }
-            c->n_dom--;
-            ret = sched_move_domain(d, cpupool0);
+            ret = cpupool_move_domain_unlocked(d, cpupool0);
             if ( ret )
-            {
-                c->n_dom++;
                 break;
-            }
-            cpupool0->n_dom++;
         }
         rcu_read_unlock(&domlist_read_lock);
         if ( ret )
@@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
                         d->domain_id, op->cpupool_id);
         ret = -ENOENT;
         spin_lock(&cpupool_lock);
+
         c = cpupool_find_by_id(op->cpupool_id);
         if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
-        {
-            d->cpupool->n_dom--;
-            ret = sched_move_domain(d, c);
-            if ( ret )
-                d->cpupool->n_dom++;
-            else
-                c->n_dom++;
-        }
+            ret = cpupool_move_domain_unlocked(d, c);
+
         spin_unlock(&cpupool_lock);
         cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
                         d->domain_id, op->cpupool_id, ret);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index a3f51ec..4a62c1d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
                 rc = -EAGAIN;
             break;
         }
-        if ( sched_move_domain(d, cpupool0) )
+        if ( cpupool_move_domain(d, cpupool0) )
             return -EAGAIN;
         for_each_vcpu ( d, v )
             unmap_vcpu_info(v);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index c5157e6..46fc6e3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
 void cpupool_put(struct cpupool *pool);
 int cpupool_add_domain(struct domain *d, int poolid);
 void cpupool_rm_domain(struct domain *d);
+int cpupool_move_domain(struct domain *d, struct cpupool *c);
 int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
 void schedule_dump(struct cpupool *c);
 extern void dump_runq(unsigned char key);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:41:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:41:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVMp-0002VG-I7; Wed, 12 Nov 2014 10:41:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1XoVMo-0002Up-2F
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:41:38 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	1F/E0-17958-16933645; Wed, 12 Nov 2014 10:41:37 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415788895!10789933!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26004 invoked from network); 12 Nov 2014 10:41:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:41:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191909369"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 05:41:34 -0500
Received: from malcolmc.uk.xensource.com ([10.80.2.69])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<malcolm.crossley@citrix.com>)	id 1XoVMk-0001el-FI;
	Wed, 12 Nov 2014 10:41:34 +0000
Message-ID: <5463395E.7030905@citrix.com>
Date: Wed, 12 Nov 2014 10:41:34 +0000
From: Malcolm Crossley <malcolm.crossley@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
	<20141112013757.GC2593@laptop.dumpdata.com>
	<5463355B0200007800046B17@mail.emea.novell.com>
	<54632FF8.7020508@citrix.com>
	<5463406C0200007800046B6F@mail.emea.novell.com>
In-Reply-To: <5463406C0200007800046B6F@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 10:11, Jan Beulich wrote:
>>>> On 12.11.14 at 11:01, <malcolm.crossley@citrix.com> wrote:
>> As for the CRS regions: These typically describe the BIOS set limits in
>> hardware configuration for the MMIO hole itself. On single socket
>> systems anything which isn't RAM or another predefined region decodes to
>> MMIO. This is probably why Jan's Dell system has a CRS region which
>> covers the entire address space.
>>
>> On multi socket systems the CRS is very important because the chipset is
>> configured to only decode certain regions to the PCI express ports, if
>> you use an address out side of those regions then accessing that address
>> will go "nowhere" and the machine will crash.
> 
> Don't you mean multi-node instead of multi-socket here? Since what
> matters is how the I/O subsystem is organized; the CPU topology is
> pretty uninteresting for this.
> 

Yes, multi-IO-node would be the correct description (I used socket
because most people would understand that more clearly). I don't like
using the term "node" on it's own because IO and memory node's can be
quite different. The specific hardware dictating the address space
partitioning is the coherency fabric (QPI links/HT links).

Malcolm

> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:41:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:41:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVMp-0002VG-I7; Wed, 12 Nov 2014 10:41:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1XoVMo-0002Up-2F
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:41:38 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	1F/E0-17958-16933645; Wed, 12 Nov 2014 10:41:37 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415788895!10789933!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26004 invoked from network); 12 Nov 2014 10:41:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:41:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191909369"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 05:41:34 -0500
Received: from malcolmc.uk.xensource.com ([10.80.2.69])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<malcolm.crossley@citrix.com>)	id 1XoVMk-0001el-FI;
	Wed, 12 Nov 2014 10:41:34 +0000
Message-ID: <5463395E.7030905@citrix.com>
Date: Wed, 12 Nov 2014 10:41:34 +0000
From: Malcolm Crossley <malcolm.crossley@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
	<20141112013757.GC2593@laptop.dumpdata.com>
	<5463355B0200007800046B17@mail.emea.novell.com>
	<54632FF8.7020508@citrix.com>
	<5463406C0200007800046B6F@mail.emea.novell.com>
In-Reply-To: <5463406C0200007800046B6F@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 10:11, Jan Beulich wrote:
>>>> On 12.11.14 at 11:01, <malcolm.crossley@citrix.com> wrote:
>> As for the CRS regions: These typically describe the BIOS set limits in
>> hardware configuration for the MMIO hole itself. On single socket
>> systems anything which isn't RAM or another predefined region decodes to
>> MMIO. This is probably why Jan's Dell system has a CRS region which
>> covers the entire address space.
>>
>> On multi socket systems the CRS is very important because the chipset is
>> configured to only decode certain regions to the PCI express ports, if
>> you use an address out side of those regions then accessing that address
>> will go "nowhere" and the machine will crash.
> 
> Don't you mean multi-node instead of multi-socket here? Since what
> matters is how the I/O subsystem is organized; the CPU topology is
> pretty uninteresting for this.
> 

Yes, multi-IO-node would be the correct description (I used socket
because most people would understand that more clearly). I don't like
using the term "node" on it's own because IO and memory node's can be
quite different. The specific hardware dictating the address space
partitioning is the coherency fabric (QPI links/HT links).

Malcolm

> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:46:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVRn-00036d-T2; Wed, 12 Nov 2014 10:46:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XoVRm-00036G-2D
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:46:46 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	A3/42-27785-49A33645; Wed, 12 Nov 2014 10:46:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415789202!11917943!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16101 invoked from network); 12 Nov 2014 10:46:43 -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;
	12 Nov 2014 10:46:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191910374"
Message-ID: <54633A90.8040302@citrix.com>
Date: Wed, 12 Nov 2014 10:46:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xen.org>,
	<jbeulich@suse.com>, <dietmar.hahn@ts.fujitsu.com>
References: <1415788840-19497-1-git-send-email-jgross@suse.com>
In-Reply-To: <1415788840-19497-1-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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 12/11/14 10:40, Juergen Gross wrote:
> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> cpupool0 before destroying it) introduced an error in the accounting
> of cpupools regarding the number of domains. The number of domains
> is nor adjusted when a domain is moved to cpupool0 in kill_domain().
>
> Correct this by introducing a cpupool function doing the move
> instead of open coding it by calling sched_move_domain().
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> ---
>  xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
>  xen/common/domain.c     |  2 +-
>  xen/include/xen/sched.h |  1 +
>  3 files changed, 35 insertions(+), 15 deletions(-)
>
> diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
> index 73249d3..c6e3869 100644
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
>  }
>  
>  /*
> + * Move domain to another cpupool
> + */
> +static int cpupool_move_domain_unlocked(struct domain *d, struct cpupool *c)

This isn't an unlocked function.  It is strictly called with the
cpupool_lock held.  Per prevailing style, it should be named
"__cpupool_move_domain()".

> +{
> +    int ret;
> +
> +    d->cpupool->n_dom--;
> +    ret = sched_move_domain(d, c);
> +    if ( ret )
> +        d->cpupool->n_dom++;
> +    else
> +        c->n_dom++;
> +
> +    return ret;
> +}

Newline here please.

Once these two issues are fixed, content Reviewed-by: Andrew Cooper
<andrew.cooper3@citrix.com>

> +int cpupool_move_domain(struct domain *d, struct cpupool *c)
> +{
> +    int ret;
> +
> +    spin_lock(&cpupool_lock);
> +
> +    ret = cpupool_move_domain_unlocked(d, c);
> +
> +    spin_unlock(&cpupool_lock);
> +
> +    return ret;
> +}
> +
> +/*
>   * assign a specific cpu to a cpupool
>   * cpupool_lock must be held
>   */
> @@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
>                  ret = -EBUSY;
>                  break;
>              }
> -            c->n_dom--;
> -            ret = sched_move_domain(d, cpupool0);
> +            ret = cpupool_move_domain_unlocked(d, cpupool0);
>              if ( ret )
> -            {
> -                c->n_dom++;
>                  break;
> -            }
> -            cpupool0->n_dom++;
>          }
>          rcu_read_unlock(&domlist_read_lock);
>          if ( ret )
> @@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
>                          d->domain_id, op->cpupool_id);
>          ret = -ENOENT;
>          spin_lock(&cpupool_lock);
> +
>          c = cpupool_find_by_id(op->cpupool_id);
>          if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
> -        {
> -            d->cpupool->n_dom--;
> -            ret = sched_move_domain(d, c);
> -            if ( ret )
> -                d->cpupool->n_dom++;
> -            else
> -                c->n_dom++;
> -        }
> +            ret = cpupool_move_domain_unlocked(d, c);
> +
>          spin_unlock(&cpupool_lock);
>          cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
>                          d->domain_id, op->cpupool_id, ret);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index a3f51ec..4a62c1d 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
>                  rc = -EAGAIN;
>              break;
>          }
> -        if ( sched_move_domain(d, cpupool0) )
> +        if ( cpupool_move_domain(d, cpupool0) )
>              return -EAGAIN;
>          for_each_vcpu ( d, v )
>              unmap_vcpu_info(v);
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index c5157e6..46fc6e3 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
>  void cpupool_put(struct cpupool *pool);
>  int cpupool_add_domain(struct domain *d, int poolid);
>  void cpupool_rm_domain(struct domain *d);
> +int cpupool_move_domain(struct domain *d, struct cpupool *c);
>  int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
>  void schedule_dump(struct cpupool *c);
>  extern void dump_runq(unsigned char key);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:46:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVRn-00036d-T2; Wed, 12 Nov 2014 10:46:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XoVRm-00036G-2D
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:46:46 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	A3/42-27785-49A33645; Wed, 12 Nov 2014 10:46:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415789202!11917943!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16101 invoked from network); 12 Nov 2014 10:46:43 -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;
	12 Nov 2014 10:46:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191910374"
Message-ID: <54633A90.8040302@citrix.com>
Date: Wed, 12 Nov 2014 10:46:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xen.org>,
	<jbeulich@suse.com>, <dietmar.hahn@ts.fujitsu.com>
References: <1415788840-19497-1-git-send-email-jgross@suse.com>
In-Reply-To: <1415788840-19497-1-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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 12/11/14 10:40, Juergen Gross wrote:
> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> cpupool0 before destroying it) introduced an error in the accounting
> of cpupools regarding the number of domains. The number of domains
> is nor adjusted when a domain is moved to cpupool0 in kill_domain().
>
> Correct this by introducing a cpupool function doing the move
> instead of open coding it by calling sched_move_domain().
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> ---
>  xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
>  xen/common/domain.c     |  2 +-
>  xen/include/xen/sched.h |  1 +
>  3 files changed, 35 insertions(+), 15 deletions(-)
>
> diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
> index 73249d3..c6e3869 100644
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
>  }
>  
>  /*
> + * Move domain to another cpupool
> + */
> +static int cpupool_move_domain_unlocked(struct domain *d, struct cpupool *c)

This isn't an unlocked function.  It is strictly called with the
cpupool_lock held.  Per prevailing style, it should be named
"__cpupool_move_domain()".

> +{
> +    int ret;
> +
> +    d->cpupool->n_dom--;
> +    ret = sched_move_domain(d, c);
> +    if ( ret )
> +        d->cpupool->n_dom++;
> +    else
> +        c->n_dom++;
> +
> +    return ret;
> +}

Newline here please.

Once these two issues are fixed, content Reviewed-by: Andrew Cooper
<andrew.cooper3@citrix.com>

> +int cpupool_move_domain(struct domain *d, struct cpupool *c)
> +{
> +    int ret;
> +
> +    spin_lock(&cpupool_lock);
> +
> +    ret = cpupool_move_domain_unlocked(d, c);
> +
> +    spin_unlock(&cpupool_lock);
> +
> +    return ret;
> +}
> +
> +/*
>   * assign a specific cpu to a cpupool
>   * cpupool_lock must be held
>   */
> @@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
>                  ret = -EBUSY;
>                  break;
>              }
> -            c->n_dom--;
> -            ret = sched_move_domain(d, cpupool0);
> +            ret = cpupool_move_domain_unlocked(d, cpupool0);
>              if ( ret )
> -            {
> -                c->n_dom++;
>                  break;
> -            }
> -            cpupool0->n_dom++;
>          }
>          rcu_read_unlock(&domlist_read_lock);
>          if ( ret )
> @@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
>                          d->domain_id, op->cpupool_id);
>          ret = -ENOENT;
>          spin_lock(&cpupool_lock);
> +
>          c = cpupool_find_by_id(op->cpupool_id);
>          if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
> -        {
> -            d->cpupool->n_dom--;
> -            ret = sched_move_domain(d, c);
> -            if ( ret )
> -                d->cpupool->n_dom++;
> -            else
> -                c->n_dom++;
> -        }
> +            ret = cpupool_move_domain_unlocked(d, c);
> +
>          spin_unlock(&cpupool_lock);
>          cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
>                          d->domain_id, op->cpupool_id, ret);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index a3f51ec..4a62c1d 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
>                  rc = -EAGAIN;
>              break;
>          }
> -        if ( sched_move_domain(d, cpupool0) )
> +        if ( cpupool_move_domain(d, cpupool0) )
>              return -EAGAIN;
>          for_each_vcpu ( d, v )
>              unmap_vcpu_info(v);
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index c5157e6..46fc6e3 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
>  void cpupool_put(struct cpupool *pool);
>  int cpupool_add_domain(struct domain *d, int poolid);
>  void cpupool_rm_domain(struct domain *d);
> +int cpupool_move_domain(struct domain *d, struct cpupool *c);
>  int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
>  void schedule_dump(struct cpupool *c);
>  extern void dump_runq(unsigned char key);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:54:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVYw-0003WG-QK; Wed, 12 Nov 2014 10:54:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XoVYv-0003WA-Pr
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:54:09 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	8C/BB-14214-15C33645; Wed, 12 Nov 2014 10:54:09 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415789642!5437620!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22818 invoked from network); 12 Nov 2014 10:54:03 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-14.tower-206.messagelabs.com with SMTP;
	12 Nov 2014 10:54:03 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 12 Nov 2014 02:52:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,368,1413270000"; d="scan'208";a="606500674"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 12 Nov 2014 02:54:00 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 12 Nov 2014 18:53:51 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.241]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.62]) with mapi id
	14.03.0195.001; Wed, 12 Nov 2014 18:53:44 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/l4Q40PTqL8t5UqwE/iHSFjzzpxcwHVQ
Date: Wed, 12 Nov 2014 10:53:44 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A4CD95@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54633B260200007800046B39@mail.emea.novell.com>
In-Reply-To: <54633B260200007800046B39@mail.emea.novell.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



Best Regards,
Robert Ho

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, November 12, 2014 5:49 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; Konrad Rzeszutek Wilk
> Subject: Re: [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> >>> On 12.11.14 at 07:58, <robert.hu@intel.com> wrote:
> > 2. Failed to hotplug a VT-d device with XEN4.5-RC1
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> 
> First of all I'm not sure it is really useful to use the old, discontinued
> bugzilla to report bugs. I think it would be much easier if you reported
> them directly (and individually) to the mailing list, with or without
> triggering the creation of bugs in the new tracking system.
> 
First of all, thanks for your attention.
I think it shall be stored somewhere and be tracked, rather than one by one mail thread. To follow your suggestion, I would next time in addition send each bug per mail, with descriptions contained.
> As to the specific bug above - nothing is being said on whether a
> driver was still attached to the device at the time it was being
> hot-unplugged; if there was, I'm not sure what the expected
> behavior would be (i.e. on real hardware).
As http://wiki.xen.org/wiki/Xen_4.5_RC1_test_instructions says, we as QA engineer "Report any bugs / missing functionality / unexpected results. " Of course, we would help provide as much debug information as we can. 
The expected behavior shall be no error output observed here.
> 
> > 3. Fail to hot add multi devices to guest
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895
> 
> The description in contradicting itself - title and parts of it say
> the operation failed, but "Bug detailed description" says "Checking
> inside guest VM, the VT-D device is attached to guest VM actually,
> and works fine."
Yes, it looks ambiguous. Shall have refined the description title more precisely.
> 
> > 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
> 
> I think we were told the other day that pass-through of PFs is
> not being supported by Intel. What's the purpose of reporting
> bugs there?
This bug was filed before the certainness about PF issue, so this one still follow previous perception. I shall have redefined this bug. Sorry for confusing you. You can ignore this bug itself.
But there is still another issue incurred if we follow the new perception, i.e. xl tool stack should forbid user to assign PF or if you decide to allow user doing so, some further supporting work shall be done.
> 
> > 7. Error msg occurred after attaching multi SR-IOV VF device to running guest
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899
> 
> This reads (except for the title) the same as 1895. Am I overlooking
> something here?
The 2 are very similar, this bug is of VF assignment, 1895 refers to similar operation on PFs (only vt-d device, no SR-IOV VFs involved).
>From perspective of QA bug reporting, we encourage tester to report bug as specific/concrete as possible; such situation is allowed that 2 (or more) bugs are finally found same root cause after developer looking into; but it is out of reporter's scope to assert this.
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:54:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVYw-0003WG-QK; Wed, 12 Nov 2014 10:54:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XoVYv-0003WA-Pr
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:54:09 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	8C/BB-14214-15C33645; Wed, 12 Nov 2014 10:54:09 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415789642!5437620!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22818 invoked from network); 12 Nov 2014 10:54:03 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-14.tower-206.messagelabs.com with SMTP;
	12 Nov 2014 10:54:03 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 12 Nov 2014 02:52:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,368,1413270000"; d="scan'208";a="606500674"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 12 Nov 2014 02:54:00 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 12 Nov 2014 18:53:51 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.241]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.62]) with mapi id
	14.03.0195.001; Wed, 12 Nov 2014 18:53:44 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/l4Q40PTqL8t5UqwE/iHSFjzzpxcwHVQ
Date: Wed, 12 Nov 2014 10:53:44 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A4CD95@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54633B260200007800046B39@mail.emea.novell.com>
In-Reply-To: <54633B260200007800046B39@mail.emea.novell.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



Best Regards,
Robert Ho

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, November 12, 2014 5:49 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; Konrad Rzeszutek Wilk
> Subject: Re: [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> >>> On 12.11.14 at 07:58, <robert.hu@intel.com> wrote:
> > 2. Failed to hotplug a VT-d device with XEN4.5-RC1
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> 
> First of all I'm not sure it is really useful to use the old, discontinued
> bugzilla to report bugs. I think it would be much easier if you reported
> them directly (and individually) to the mailing list, with or without
> triggering the creation of bugs in the new tracking system.
> 
First of all, thanks for your attention.
I think it shall be stored somewhere and be tracked, rather than one by one mail thread. To follow your suggestion, I would next time in addition send each bug per mail, with descriptions contained.
> As to the specific bug above - nothing is being said on whether a
> driver was still attached to the device at the time it was being
> hot-unplugged; if there was, I'm not sure what the expected
> behavior would be (i.e. on real hardware).
As http://wiki.xen.org/wiki/Xen_4.5_RC1_test_instructions says, we as QA engineer "Report any bugs / missing functionality / unexpected results. " Of course, we would help provide as much debug information as we can. 
The expected behavior shall be no error output observed here.
> 
> > 3. Fail to hot add multi devices to guest
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895
> 
> The description in contradicting itself - title and parts of it say
> the operation failed, but "Bug detailed description" says "Checking
> inside guest VM, the VT-D device is attached to guest VM actually,
> and works fine."
Yes, it looks ambiguous. Shall have refined the description title more precisely.
> 
> > 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
> 
> I think we were told the other day that pass-through of PFs is
> not being supported by Intel. What's the purpose of reporting
> bugs there?
This bug was filed before the certainness about PF issue, so this one still follow previous perception. I shall have redefined this bug. Sorry for confusing you. You can ignore this bug itself.
But there is still another issue incurred if we follow the new perception, i.e. xl tool stack should forbid user to assign PF or if you decide to allow user doing so, some further supporting work shall be done.
> 
> > 7. Error msg occurred after attaching multi SR-IOV VF device to running guest
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899
> 
> This reads (except for the title) the same as 1895. Am I overlooking
> something here?
The 2 are very similar, this bug is of VF assignment, 1895 refers to similar operation on PFs (only vt-d device, no SR-IOV VFs involved).
>From perspective of QA bug reporting, we encourage tester to report bug as specific/concrete as possible; such situation is allowed that 2 (or more) bugs are finally found same root cause after developer looking into; but it is out of reporter's scope to assert this.
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:56:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVbF-0003dy-Sg; Wed, 12 Nov 2014 10:56:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoVbE-0003do-LB
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:56:32 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	AE/E0-25547-FDC33645; Wed, 12 Nov 2014 10:56:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415789785!10794957!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9015 invoked from network); 12 Nov 2014 10:56:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:56:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190466282"
Message-ID: <1415789784.25176.67.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 12 Nov 2014 10:56:24 +0000
In-Reply-To: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 10:39 +0000, Wei Liu wrote:
> ... otherwise when device add operation fails, the error message looks
> like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
> device", which is not very helpful.

Thanks.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..de23fec 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
>                                                                          \
>          GCNEW(aodev);                                                   \
>          libxl__prepare_ao_device(ao, aodev);                            \
> +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
>          aodev->callback = device_addrm_aocomplete;                      \
>          aodev->update_json = true;                                      \
>          libxl__device_##type##_add(egc, domid, type, aodev);            \



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:56:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVbF-0003dy-Sg; Wed, 12 Nov 2014 10:56:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoVbE-0003do-LB
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:56:32 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	AE/E0-25547-FDC33645; Wed, 12 Nov 2014 10:56:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415789785!10794957!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9015 invoked from network); 12 Nov 2014 10:56:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 10:56:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190466282"
Message-ID: <1415789784.25176.67.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 12 Nov 2014 10:56:24 +0000
In-Reply-To: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 10:39 +0000, Wei Liu wrote:
> ... otherwise when device add operation fails, the error message looks
> like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
> device", which is not very helpful.

Thanks.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..de23fec 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
>                                                                          \
>          GCNEW(aodev);                                                   \
>          libxl__prepare_ao_device(ao, aodev);                            \
> +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
>          aodev->callback = device_addrm_aocomplete;                      \
>          aodev->update_json = true;                                      \
>          libxl__device_##type##_add(egc, domid, type, aodev);            \



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 10:59:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVe1-0003wR-GF; Wed, 12 Nov 2014 10:59:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoVe0-0003wI-Mf
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:59:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3E/59-09936-C8D33645; Wed, 12 Nov 2014 10:59:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415789962!4117407!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30101 invoked from network); 12 Nov 2014 10:59:23 -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;
	12 Nov 2014 10:59:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190466705"
Message-ID: <1415789960.25176.71.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 12 Nov 2014 10:59:20 +0000
In-Reply-To: <20141112022421.GA11959@laptop.dumpdata.com>
References: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
	<20141112022421.GA11959@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, xen-devel@lists.xen.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] fix commit xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 21:24 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 08:28:38PM +0000, M A Young wrote:
> > The build of xen-4.5.0-rc2 fails if XSM_ENABLE=y due to an inconsistency in
> > commit fda1614 "xen/arm: Add support for GICv3 for domU" which uses
> > XEN_DOMCTL_configure_domain in xen/xsm/flask/hooks.c and
> > xen/xsm/flask/policy/access_vectors but XEN_DOMCTL_arm_configure_domain
> > elsewhere.
> 
> Ouch! Thank you for catching that.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked + applied, good catch, 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 Nov 12 10:59:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 10:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVe1-0003wR-GF; Wed, 12 Nov 2014 10:59:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoVe0-0003wI-Mf
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:59:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3E/59-09936-C8D33645; Wed, 12 Nov 2014 10:59:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415789962!4117407!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30101 invoked from network); 12 Nov 2014 10:59:23 -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;
	12 Nov 2014 10:59:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190466705"
Message-ID: <1415789960.25176.71.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 12 Nov 2014 10:59:20 +0000
In-Reply-To: <20141112022421.GA11959@laptop.dumpdata.com>
References: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
	<20141112022421.GA11959@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Julien Grall <julien.grall@linaro.org>, xen-devel@lists.xen.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] fix commit xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 21:24 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 08:28:38PM +0000, M A Young wrote:
> > The build of xen-4.5.0-rc2 fails if XSM_ENABLE=y due to an inconsistency in
> > commit fda1614 "xen/arm: Add support for GICv3 for domU" which uses
> > XEN_DOMCTL_configure_domain in xen/xsm/flask/hooks.c and
> > xen/xsm/flask/policy/access_vectors but XEN_DOMCTL_arm_configure_domain
> > elsewhere.
> 
> Ouch! Thank you for catching that.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked + applied, good catch, 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 Nov 12 11:01:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVfa-00045W-0U; Wed, 12 Nov 2014 11:01:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoVfY-00045H-5O
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:01:00 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	51/BB-02698-BED33645; Wed, 12 Nov 2014 11:00:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415790057!12008847!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13211 invoked from network); 12 Nov 2014 11:00:58 -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;
	12 Nov 2014 11:00:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191912774"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:00:57 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoVa4-0001xZ-2R;
	Wed, 12 Nov 2014 10:55:20 +0000
Date: Wed, 12 Nov 2014 10:55:20 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141112105519.GB25821@zion.uk.xensource.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And of course this is v2 of this patch. Sorry for not having added that
in the subject line.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:01:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVfa-00045W-0U; Wed, 12 Nov 2014 11:01:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoVfY-00045H-5O
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:01:00 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	51/BB-02698-BED33645; Wed, 12 Nov 2014 11:00:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415790057!12008847!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13211 invoked from network); 12 Nov 2014 11:00:58 -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;
	12 Nov 2014 11:00:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191912774"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:00:57 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoVa4-0001xZ-2R;
	Wed, 12 Nov 2014 10:55:20 +0000
Date: Wed, 12 Nov 2014 10:55:20 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141112105519.GB25821@zion.uk.xensource.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
	DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And of course this is v2 of this patch. Sorry for not having added that
in the subject line.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:03:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:03:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoViA-0004Qe-Qx; Wed, 12 Nov 2014 11:03:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoVi8-0004QT-U3
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:03:41 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	82/95-25727-C8E33645; Wed, 12 Nov 2014 11:03:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415790219!10843507!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9317 invoked from network); 12 Nov 2014 11:03:39 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:03:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 11:03:39 +0000
Message-Id: <54634C9A0200007800046C11@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 11:03:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Juergen Gross" <JGross@suse.com>
References: <1415788840-19497-1-git-send-email-jgross@suse.com>
	<54633A90.8040302@citrix.com>
In-Reply-To: <54633A90.8040302@citrix.com>
Mime-Version: 1.0
Content-Length: 1585
Content-Disposition: inline
Cc: dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDEyLjExLjE0IGF0IDExOjQ2LCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTIvMTEvMTQgMTA6NDAsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6Cj4+IC0tLSBhL3hl
bi9jb21tb24vY3B1cG9vbC5jCj4+ICsrKyBiL3hlbi9jb21tb24vY3B1cG9vbC5jCj4+IEBAIC0y
MjUsNiArMjI1LDM1IEBAIHN0YXRpYyBpbnQgY3B1cG9vbF9kZXN0cm95KHN0cnVjdCBjcHVwb29s
ICpjKQo+PiAgfQo+PiAgCj4+ICAvKgo+PiArICogTW92ZSBkb21haW4gdG8gYW5vdGhlciBjcHVw
b29sCj4+ICsgKi8KPj4gK3N0YXRpYyBpbnQgY3B1cG9vbF9tb3ZlX2RvbWFpbl91bmxvY2tlZChz
dHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgY3B1cG9vbCAqYykKPiAKPiBUaGlzIGlzbid0IGFuIHVu
bG9ja2VkIGZ1bmN0aW9uLiAgSXQgaXMgc3RyaWN0bHkgY2FsbGVkIHdpdGggdGhlCj4gY3B1cG9v
bF9sb2NrIGhlbGQuICBQZXIgcHJldmFpbGluZyBzdHlsZSwgaXQgc2hvdWxkIGJlIG5hbWVkCj4g
Il9fY3B1cG9vbF9tb3ZlX2RvbWFpbigpIi4KCkkgZ2VuZXJhbGx5IGRpc2FncmVlIHRvIHRoaXMs
IGV2ZW4gaWYgdGhpcyBpcyB0aGUgcHJldmFpbGluZyBzdHlsZS4KRG91YmxlLXVuZGVyc2NvcmUg
cHJlZml4ZWQgbmFtZXMgc2hvdWxkbid0IGJlIHVzZWQgYXQgYWxsIGluIG91cgpjb2RlLCBhcyB0
aGV5J3JlIGJlaW5nIHJlc2VydmVkIGJ5IHRoZSBDIGxpYnJhcnkgc3RhbmRhcmQgKGFuZAp0aGUg
Y29tcGlsZXIgaXMgZnJlZSB0byBpbnRyb2R1Y2UgbGlicmFyeSBjYWxscyBuYW1lZCBzdWNoKS4g
QnV0CnRoZSBxdWVzdGlvbiBvZiBjb3Vyc2UgaXMgdmFsaWQgd2h5IHRoZSBmdW5jdGlvbiBuYW1l
IHNheXMKInVubG9ja2VkIiB3aGVuIGl0J3MgYWx3YXlzIGJlaW5nIGNhbGxlZCB3aXRoIHRoZSBs
b2NrIGhlbGQgLQoibG9ja2VkIiB3b3VsZCBzZWVtIG1vcmUgbmF0dXJhbCBpbiB0aGlzIGNhc2Uu
IEJ1dCBpbiB0aGUgZW5kCkrDvHJnZW4gaXMgdGhlIG1haW50YWluZXIgb2YgdGhhdCBjb2RlLCBz
byBoZSBkZWNpZGVzLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:03:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:03:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoViA-0004Qe-Qx; Wed, 12 Nov 2014 11:03:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoVi8-0004QT-U3
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:03:41 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	82/95-25727-C8E33645; Wed, 12 Nov 2014 11:03:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415790219!10843507!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9317 invoked from network); 12 Nov 2014 11:03:39 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:03:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 11:03:39 +0000
Message-Id: <54634C9A0200007800046C11@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 11:03:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Juergen Gross" <JGross@suse.com>
References: <1415788840-19497-1-git-send-email-jgross@suse.com>
	<54633A90.8040302@citrix.com>
In-Reply-To: <54633A90.8040302@citrix.com>
Mime-Version: 1.0
Content-Length: 1585
Content-Disposition: inline
Cc: dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDEyLjExLjE0IGF0IDExOjQ2LCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTIvMTEvMTQgMTA6NDAsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6Cj4+IC0tLSBhL3hl
bi9jb21tb24vY3B1cG9vbC5jCj4+ICsrKyBiL3hlbi9jb21tb24vY3B1cG9vbC5jCj4+IEBAIC0y
MjUsNiArMjI1LDM1IEBAIHN0YXRpYyBpbnQgY3B1cG9vbF9kZXN0cm95KHN0cnVjdCBjcHVwb29s
ICpjKQo+PiAgfQo+PiAgCj4+ICAvKgo+PiArICogTW92ZSBkb21haW4gdG8gYW5vdGhlciBjcHVw
b29sCj4+ICsgKi8KPj4gK3N0YXRpYyBpbnQgY3B1cG9vbF9tb3ZlX2RvbWFpbl91bmxvY2tlZChz
dHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgY3B1cG9vbCAqYykKPiAKPiBUaGlzIGlzbid0IGFuIHVu
bG9ja2VkIGZ1bmN0aW9uLiAgSXQgaXMgc3RyaWN0bHkgY2FsbGVkIHdpdGggdGhlCj4gY3B1cG9v
bF9sb2NrIGhlbGQuICBQZXIgcHJldmFpbGluZyBzdHlsZSwgaXQgc2hvdWxkIGJlIG5hbWVkCj4g
Il9fY3B1cG9vbF9tb3ZlX2RvbWFpbigpIi4KCkkgZ2VuZXJhbGx5IGRpc2FncmVlIHRvIHRoaXMs
IGV2ZW4gaWYgdGhpcyBpcyB0aGUgcHJldmFpbGluZyBzdHlsZS4KRG91YmxlLXVuZGVyc2NvcmUg
cHJlZml4ZWQgbmFtZXMgc2hvdWxkbid0IGJlIHVzZWQgYXQgYWxsIGluIG91cgpjb2RlLCBhcyB0
aGV5J3JlIGJlaW5nIHJlc2VydmVkIGJ5IHRoZSBDIGxpYnJhcnkgc3RhbmRhcmQgKGFuZAp0aGUg
Y29tcGlsZXIgaXMgZnJlZSB0byBpbnRyb2R1Y2UgbGlicmFyeSBjYWxscyBuYW1lZCBzdWNoKS4g
QnV0CnRoZSBxdWVzdGlvbiBvZiBjb3Vyc2UgaXMgdmFsaWQgd2h5IHRoZSBmdW5jdGlvbiBuYW1l
IHNheXMKInVubG9ja2VkIiB3aGVuIGl0J3MgYWx3YXlzIGJlaW5nIGNhbGxlZCB3aXRoIHRoZSBs
b2NrIGhlbGQgLQoibG9ja2VkIiB3b3VsZCBzZWVtIG1vcmUgbmF0dXJhbCBpbiB0aGlzIGNhc2Uu
IEJ1dCBpbiB0aGUgZW5kCkrDvHJnZW4gaXMgdGhlIG1haW50YWluZXIgb2YgdGhhdCBjb2RlLCBz
byBoZSBkZWNpZGVzLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:05:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:05:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVjL-0004Xo-De; Wed, 12 Nov 2014 11:04:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoVjK-0004Xg-2l
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:04:54 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	E6/FF-02696-5DE33645; Wed, 12 Nov 2014 11:04:53 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415790292!12029435!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31837 invoked from network); 12 Nov 2014 11:04:52 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:04:52 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 23B7AAAC3;
	Wed, 12 Nov 2014 11:04:52 +0000 (UTC)
Message-ID: <54633ED3.7030600@suse.com>
Date: Wed, 12 Nov 2014 12:04:51 +0100
From: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org, 
	jbeulich@suse.com, dietmar.hahn@ts.fujitsu.com
References: <1415788840-19497-1-git-send-email-jgross@suse.com>
	<54633A90.8040302@citrix.com>
In-Reply-To: <54633A90.8040302@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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

On 11/12/2014 11:46 AM, Andrew Cooper wrote:
> On 12/11/14 10:40, Juergen Gross wrote:
>> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
>> cpupool0 before destroying it) introduced an error in the accounting
>> of cpupools regarding the number of domains. The number of domains
>> is nor adjusted when a domain is moved to cpupool0 in kill_domain().
>>
>> Correct this by introducing a cpupool function doing the move
>> instead of open coding it by calling sched_move_domain().
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
>> ---
>>   xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
>>   xen/common/domain.c     |  2 +-
>>   xen/include/xen/sched.h |  1 +
>>   3 files changed, 35 insertions(+), 15 deletions(-)
>>
>> diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
>> index 73249d3..c6e3869 100644
>> --- a/xen/common/cpupool.c
>> +++ b/xen/common/cpupool.c
>> @@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
>>   }
>>
>>   /*
>> + * Move domain to another cpupool
>> + */
>> +static int cpupool_move_domain_unlocked(struct domain *d, struct cpupool *c)
>
> This isn't an unlocked function.  It is strictly called with the
> cpupool_lock held.  Per prevailing style, it should be named
> "__cpupool_move_domain()".

Umpf. Fingers faster than brain. :-)

>
>> +{
>> +    int ret;
>> +
>> +    d->cpupool->n_dom--;
>> +    ret = sched_move_domain(d, c);
>> +    if ( ret )
>> +        d->cpupool->n_dom++;
>> +    else
>> +        c->n_dom++;
>> +
>> +    return ret;
>> +}
>
> Newline here please.
>
> Once these two issues are fixed, content Reviewed-by: Andrew Cooper
> <andrew.cooper3@citrix.com>
>
>> +int cpupool_move_domain(struct domain *d, struct cpupool *c)
>> +{
>> +    int ret;
>> +
>> +    spin_lock(&cpupool_lock);
>> +
>> +    ret = cpupool_move_domain_unlocked(d, c);
>> +
>> +    spin_unlock(&cpupool_lock);
>> +
>> +    return ret;
>> +}
>> +
>> +/*
>>    * assign a specific cpu to a cpupool
>>    * cpupool_lock must be held
>>    */
>> @@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
>>                   ret = -EBUSY;
>>                   break;
>>               }
>> -            c->n_dom--;
>> -            ret = sched_move_domain(d, cpupool0);
>> +            ret = cpupool_move_domain_unlocked(d, cpupool0);
>>               if ( ret )
>> -            {
>> -                c->n_dom++;
>>                   break;
>> -            }
>> -            cpupool0->n_dom++;
>>           }
>>           rcu_read_unlock(&domlist_read_lock);
>>           if ( ret )
>> @@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
>>                           d->domain_id, op->cpupool_id);
>>           ret = -ENOENT;
>>           spin_lock(&cpupool_lock);
>> +
>>           c = cpupool_find_by_id(op->cpupool_id);
>>           if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
>> -        {
>> -            d->cpupool->n_dom--;
>> -            ret = sched_move_domain(d, c);
>> -            if ( ret )
>> -                d->cpupool->n_dom++;
>> -            else
>> -                c->n_dom++;
>> -        }
>> +            ret = cpupool_move_domain_unlocked(d, c);
>> +
>>           spin_unlock(&cpupool_lock);
>>           cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
>>                           d->domain_id, op->cpupool_id, ret);
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index a3f51ec..4a62c1d 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
>>                   rc = -EAGAIN;
>>               break;
>>           }
>> -        if ( sched_move_domain(d, cpupool0) )
>> +        if ( cpupool_move_domain(d, cpupool0) )
>>               return -EAGAIN;
>>           for_each_vcpu ( d, v )
>>               unmap_vcpu_info(v);
>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>> index c5157e6..46fc6e3 100644
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
>>   void cpupool_put(struct cpupool *pool);
>>   int cpupool_add_domain(struct domain *d, int poolid);
>>   void cpupool_rm_domain(struct domain *d);
>> +int cpupool_move_domain(struct domain *d, struct cpupool *c);
>>   int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
>>   void schedule_dump(struct cpupool *c);
>>   extern void dump_runq(unsigned char key);
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 12 11:05:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:05:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVjL-0004Xo-De; Wed, 12 Nov 2014 11:04:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoVjK-0004Xg-2l
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:04:54 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	E6/FF-02696-5DE33645; Wed, 12 Nov 2014 11:04:53 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415790292!12029435!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31837 invoked from network); 12 Nov 2014 11:04:52 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:04:52 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 23B7AAAC3;
	Wed, 12 Nov 2014 11:04:52 +0000 (UTC)
Message-ID: <54633ED3.7030600@suse.com>
Date: Wed, 12 Nov 2014 12:04:51 +0100
From: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org, 
	jbeulich@suse.com, dietmar.hahn@ts.fujitsu.com
References: <1415788840-19497-1-git-send-email-jgross@suse.com>
	<54633A90.8040302@citrix.com>
In-Reply-To: <54633A90.8040302@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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

On 11/12/2014 11:46 AM, Andrew Cooper wrote:
> On 12/11/14 10:40, Juergen Gross wrote:
>> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
>> cpupool0 before destroying it) introduced an error in the accounting
>> of cpupools regarding the number of domains. The number of domains
>> is nor adjusted when a domain is moved to cpupool0 in kill_domain().
>>
>> Correct this by introducing a cpupool function doing the move
>> instead of open coding it by calling sched_move_domain().
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
>> ---
>>   xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
>>   xen/common/domain.c     |  2 +-
>>   xen/include/xen/sched.h |  1 +
>>   3 files changed, 35 insertions(+), 15 deletions(-)
>>
>> diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
>> index 73249d3..c6e3869 100644
>> --- a/xen/common/cpupool.c
>> +++ b/xen/common/cpupool.c
>> @@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
>>   }
>>
>>   /*
>> + * Move domain to another cpupool
>> + */
>> +static int cpupool_move_domain_unlocked(struct domain *d, struct cpupool *c)
>
> This isn't an unlocked function.  It is strictly called with the
> cpupool_lock held.  Per prevailing style, it should be named
> "__cpupool_move_domain()".

Umpf. Fingers faster than brain. :-)

>
>> +{
>> +    int ret;
>> +
>> +    d->cpupool->n_dom--;
>> +    ret = sched_move_domain(d, c);
>> +    if ( ret )
>> +        d->cpupool->n_dom++;
>> +    else
>> +        c->n_dom++;
>> +
>> +    return ret;
>> +}
>
> Newline here please.
>
> Once these two issues are fixed, content Reviewed-by: Andrew Cooper
> <andrew.cooper3@citrix.com>
>
>> +int cpupool_move_domain(struct domain *d, struct cpupool *c)
>> +{
>> +    int ret;
>> +
>> +    spin_lock(&cpupool_lock);
>> +
>> +    ret = cpupool_move_domain_unlocked(d, c);
>> +
>> +    spin_unlock(&cpupool_lock);
>> +
>> +    return ret;
>> +}
>> +
>> +/*
>>    * assign a specific cpu to a cpupool
>>    * cpupool_lock must be held
>>    */
>> @@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
>>                   ret = -EBUSY;
>>                   break;
>>               }
>> -            c->n_dom--;
>> -            ret = sched_move_domain(d, cpupool0);
>> +            ret = cpupool_move_domain_unlocked(d, cpupool0);
>>               if ( ret )
>> -            {
>> -                c->n_dom++;
>>                   break;
>> -            }
>> -            cpupool0->n_dom++;
>>           }
>>           rcu_read_unlock(&domlist_read_lock);
>>           if ( ret )
>> @@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
>>                           d->domain_id, op->cpupool_id);
>>           ret = -ENOENT;
>>           spin_lock(&cpupool_lock);
>> +
>>           c = cpupool_find_by_id(op->cpupool_id);
>>           if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
>> -        {
>> -            d->cpupool->n_dom--;
>> -            ret = sched_move_domain(d, c);
>> -            if ( ret )
>> -                d->cpupool->n_dom++;
>> -            else
>> -                c->n_dom++;
>> -        }
>> +            ret = cpupool_move_domain_unlocked(d, c);
>> +
>>           spin_unlock(&cpupool_lock);
>>           cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
>>                           d->domain_id, op->cpupool_id, ret);
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index a3f51ec..4a62c1d 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
>>                   rc = -EAGAIN;
>>               break;
>>           }
>> -        if ( sched_move_domain(d, cpupool0) )
>> +        if ( cpupool_move_domain(d, cpupool0) )
>>               return -EAGAIN;
>>           for_each_vcpu ( d, v )
>>               unmap_vcpu_info(v);
>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>> index c5157e6..46fc6e3 100644
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
>>   void cpupool_put(struct cpupool *pool);
>>   int cpupool_add_domain(struct domain *d, int poolid);
>>   void cpupool_rm_domain(struct domain *d);
>> +int cpupool_move_domain(struct domain *d, struct cpupool *c);
>>   int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
>>   void schedule_dump(struct cpupool *c);
>>   extern void dump_runq(unsigned char key);
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 12 11:05:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVjr-0004c6-Pw; Wed, 12 Nov 2014 11:05:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoVjq-0004bw-TT
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:05:27 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	51/2E-02712-6FE33645; Wed, 12 Nov 2014 11:05:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415790325!11924178!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6097 invoked from network); 12 Nov 2014 11:05:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:05:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 11:05:25 +0000
Message-Id: <54634D040200007800046C14@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 11:05:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Robert Hu" <robert.hu@intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54633B260200007800046B39@mail.emea.novell.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A4CD95@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4CD95@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 11:53, <robert.hu@intel.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 12.11.14 at 07:58, <robert.hu@intel.com> wrote:
>> > 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
>> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896 
>> 
>> I think we were told the other day that pass-through of PFs is
>> not being supported by Intel. What's the purpose of reporting
>> bugs there?
> This bug was filed before the certainness about PF issue, so this one still 
> follow previous perception. I shall have redefined this bug. Sorry for 
> confusing you. You can ignore this bug itself.
> But there is still another issue incurred if we follow the new perception, 
> i.e. xl tool stack should forbid user to assign PF or if you decide to allow 
> user doing so, some further supporting work shall be done.

Why would the tool stack want to enforce such an Intel(-only?)
policy?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:05:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVjr-0004c6-Pw; Wed, 12 Nov 2014 11:05:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoVjq-0004bw-TT
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:05:27 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	51/2E-02712-6FE33645; Wed, 12 Nov 2014 11:05:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415790325!11924178!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6097 invoked from network); 12 Nov 2014 11:05:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:05:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 11:05:25 +0000
Message-Id: <54634D040200007800046C14@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 11:05:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Robert Hu" <robert.hu@intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54633B260200007800046B39@mail.emea.novell.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A4CD95@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4CD95@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 11:53, <robert.hu@intel.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 12.11.14 at 07:58, <robert.hu@intel.com> wrote:
>> > 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
>> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896 
>> 
>> I think we were told the other day that pass-through of PFs is
>> not being supported by Intel. What's the purpose of reporting
>> bugs there?
> This bug was filed before the certainness about PF issue, so this one still 
> follow previous perception. I shall have redefined this bug. Sorry for 
> confusing you. You can ignore this bug itself.
> But there is still another issue incurred if we follow the new perception, 
> i.e. xl tool stack should forbid user to assign PF or if you decide to allow 
> user doing so, some further supporting work shall be done.

Why would the tool stack want to enforce such an Intel(-only?)
policy?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:06:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVkR-0004i4-7q; Wed, 12 Nov 2014 11:06:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoVkQ-0004hs-Cq
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:06:02 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	51/12-02699-91F33645; Wed, 12 Nov 2014 11:06:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415790360!12005525!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3354 invoked from network); 12 Nov 2014 11:06:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:06:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191914259"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:05:59 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XoVkN-0002M9-0Q;
	Wed, 12 Nov 2014 11:05:59 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 11:05:58 +0000
Message-ID: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
	libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The `if' statement considered return value 0 from libxl_domain_info an
error, while 0 actually means success.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
This is a bug fix for PSR feature. This feature was added recently and it's
not an regression. However, it would be good to have it working correctly
since the beginning, and the fix is straightforward, which should be of
very low risk.
---
 tools/libxl/xl_cmdimpl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..9afef3f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7908,7 +7908,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
     /* Each domain */
     if (domid != INVALID_DOMID) {
         libxl_dominfo dominfo;
-        if (!libxl_domain_info(ctx, &dominfo, domid)) {
+        if (libxl_domain_info(ctx, &dominfo, domid)) {
             fprintf(stderr, "Failed to get domain info for %d\n", domid);
             return -1;
         }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:06:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVkR-0004i4-7q; Wed, 12 Nov 2014 11:06:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoVkQ-0004hs-Cq
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:06:02 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	51/12-02699-91F33645; Wed, 12 Nov 2014 11:06:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415790360!12005525!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3354 invoked from network); 12 Nov 2014 11:06:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:06:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191914259"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:05:59 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XoVkN-0002M9-0Q;
	Wed, 12 Nov 2014 11:05:59 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 11:05:58 +0000
Message-ID: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
	libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The `if' statement considered return value 0 from libxl_domain_info an
error, while 0 actually means success.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
This is a bug fix for PSR feature. This feature was added recently and it's
not an regression. However, it would be good to have it working correctly
since the beginning, and the fix is straightforward, which should be of
very low risk.
---
 tools/libxl/xl_cmdimpl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..9afef3f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7908,7 +7908,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
     /* Each domain */
     if (domid != INVALID_DOMID) {
         libxl_dominfo dominfo;
-        if (!libxl_domain_info(ctx, &dominfo, domid)) {
+        if (libxl_domain_info(ctx, &dominfo, domid)) {
             fprintf(stderr, "Failed to get domain info for %d\n", domid);
             return -1;
         }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:06:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:06:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVl6-0004qH-Lj; Wed, 12 Nov 2014 11:06:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XoVl5-0004pu-4a
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:06:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	DE/66-02702-24F33645; Wed, 12 Nov 2014 11:06:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415790401!12014047!1
X-Originating-IP: [81.169.146.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25214 invoked from network); 12 Nov 2014 11:06:41 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:06:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415790401; l=4912;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=QU3VWuC6iPzqyyBIW4pi9zsONCg=;
	b=RXdg8xc7sgYfrN8zMQ9mRTzBfHbzWGBNokK8meTSpg5Z5NMb3zT8NHAmW3Uj5DdMubK
	UPN7oOkfAzwAiDqUGTcRmEkxzwWKjVgT0CNSjZoyo54tb9V1nI42+6WCa/Tzv48QsF8T1
	fgYNhRgBtxPGzal0uS96eisr/a/sQhUVHos=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.11 AUTH) with ESMTPSA id j03fbbqACB6fUa6
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 12 Nov 2014 12:06:41 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 9CF9F50172; Wed, 12 Nov 2014 12:06:40 +0100 (CET)
Date: Wed, 12 Nov 2014 12:06:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20141112110640.GA26748@aepfle.de>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?


> ... instead of hardcoding values and guess where they config files may
> be. Also use the result of --with-sysconfig-leaf-dir.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
>  tools/hotplug/Linux/init.d/xencommons.in                          | 6 +-----
>  tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 3 +--
>  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 3 +--
>  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 3 +--
>  tools/hotplug/Linux/systemd/xenstored.service.in                  | 3 +--
>  tools/hotplug/Linux/xendomains.in                                 | 6 +-----
>  6 files changed, 6 insertions(+), 18 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
> index d53a1f3..a1095c2 100644
> --- a/tools/hotplug/Linux/init.d/xencommons.in
> +++ b/tools/hotplug/Linux/init.d/xencommons.in
> @@ -23,11 +23,7 @@ BACKEND_MODULES="@LINUX_BACKEND_MODULES@"
>  
>  . @XEN_SCRIPT_DIR@/hotplugpath.sh
>  
> -if [ -d /etc/sysconfig ]; then
> -	xencommons_config=/etc/sysconfig
> -else
> -	xencommons_config=/etc/default
> -fi
> +xencommons_config=@CONFIG_DIR@/@CONFIG_LEAF_DIR@
>  
>  test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
>  
> diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> index 44dfce8..1e930ed 100644
> --- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> +++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> @@ -5,8 +5,7 @@ RefuseManualStop=true
>  
>  [Mount]
>  Environment=XENSTORED_MOUNT_CTX=none
> -EnvironmentFile=-/etc/sysconfig/xenstored
> -EnvironmentFile=-/etc/default/xenstored
> +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
>  What=xenstore
>  Where=@XEN_LIB_STORED@
>  Type=tmpfs
> diff --git a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> index d3470fc..2282923 100644
> --- a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> +++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> @@ -8,8 +8,7 @@ ConditionVirtualization=xen
>  
>  [Service]
>  Type=simple
> -EnvironmentFile=-/etc/default/xenstored
> -EnvironmentFile=-/etc/sysconfig/xenstored
> +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
>  PIDFile=@XEN_RUN_DIR@/qemu-dom0.pid
>  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
>  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> index 7ca0264..377f131 100644
> --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> @@ -9,8 +9,7 @@ Type=simple
>  Environment=XENCONSOLED_ARGS=
>  Environment=XENCONSOLED_LOG=none
>  Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
> -EnvironmentFile=-/etc/default/xenconsoled
> -EnvironmentFile=-/etc/sysconfig/xenconsoled
> +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
>  PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
>  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
>  ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
> diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
> index 013e69e..f85b37d 100644
> --- a/tools/hotplug/Linux/systemd/xenstored.service.in
> +++ b/tools/hotplug/Linux/systemd/xenstored.service.in
> @@ -11,8 +11,7 @@ Type=notify
>  Environment=XENSTORED_ARGS=
>  Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
>  Environment=XENSTORED=@XENSTORED@
> -EnvironmentFile=-/etc/default/xencommons
> -EnvironmentFile=-/etc/sysconfig/xencommons
> +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
>  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
>  ExecStartPre=-/bin/rm -f @XEN_LIB_STORED@/tdb*
>  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> diff --git a/tools/hotplug/Linux/xendomains.in b/tools/hotplug/Linux/xendomains.in
> index de711b7..2e65ac6 100644
> --- a/tools/hotplug/Linux/xendomains.in
> +++ b/tools/hotplug/Linux/xendomains.in
> @@ -51,11 +51,7 @@ fi
>  
>  LOCKFILE=${XEN_LOCK_DIR}/xendomains
>  
> -if [ -d /etc/sysconfig ]; then
> -	XENDOM_CONFIG=/etc/sysconfig/xendomains
> -else
> -	XENDOM_CONFIG=/etc/default/xendomains
> -fi
> +XENDOM_CONFIG=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xendomains
>  
>  test -r $XENDOM_CONFIG || { echo "$XENDOM_CONFIG not existing";
>  	if [ "$1" = "stop" ]; then exit 0;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:06:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:06:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVl6-0004qH-Lj; Wed, 12 Nov 2014 11:06:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XoVl5-0004pu-4a
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:06:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	DE/66-02702-24F33645; Wed, 12 Nov 2014 11:06:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415790401!12014047!1
X-Originating-IP: [81.169.146.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25214 invoked from network); 12 Nov 2014 11:06:41 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:06:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415790401; l=4912;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=QU3VWuC6iPzqyyBIW4pi9zsONCg=;
	b=RXdg8xc7sgYfrN8zMQ9mRTzBfHbzWGBNokK8meTSpg5Z5NMb3zT8NHAmW3Uj5DdMubK
	UPN7oOkfAzwAiDqUGTcRmEkxzwWKjVgT0CNSjZoyo54tb9V1nI42+6WCa/Tzv48QsF8T1
	fgYNhRgBtxPGzal0uS96eisr/a/sQhUVHos=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.11 AUTH) with ESMTPSA id j03fbbqACB6fUa6
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 12 Nov 2014 12:06:41 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 9CF9F50172; Wed, 12 Nov 2014 12:06:40 +0100 (CET)
Date: Wed, 12 Nov 2014 12:06:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20141112110640.GA26748@aepfle.de>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?


> ... instead of hardcoding values and guess where they config files may
> be. Also use the result of --with-sysconfig-leaf-dir.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
>  tools/hotplug/Linux/init.d/xencommons.in                          | 6 +-----
>  tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 3 +--
>  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 3 +--
>  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 3 +--
>  tools/hotplug/Linux/systemd/xenstored.service.in                  | 3 +--
>  tools/hotplug/Linux/xendomains.in                                 | 6 +-----
>  6 files changed, 6 insertions(+), 18 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
> index d53a1f3..a1095c2 100644
> --- a/tools/hotplug/Linux/init.d/xencommons.in
> +++ b/tools/hotplug/Linux/init.d/xencommons.in
> @@ -23,11 +23,7 @@ BACKEND_MODULES="@LINUX_BACKEND_MODULES@"
>  
>  . @XEN_SCRIPT_DIR@/hotplugpath.sh
>  
> -if [ -d /etc/sysconfig ]; then
> -	xencommons_config=/etc/sysconfig
> -else
> -	xencommons_config=/etc/default
> -fi
> +xencommons_config=@CONFIG_DIR@/@CONFIG_LEAF_DIR@
>  
>  test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
>  
> diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> index 44dfce8..1e930ed 100644
> --- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> +++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> @@ -5,8 +5,7 @@ RefuseManualStop=true
>  
>  [Mount]
>  Environment=XENSTORED_MOUNT_CTX=none
> -EnvironmentFile=-/etc/sysconfig/xenstored
> -EnvironmentFile=-/etc/default/xenstored
> +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
>  What=xenstore
>  Where=@XEN_LIB_STORED@
>  Type=tmpfs
> diff --git a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> index d3470fc..2282923 100644
> --- a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> +++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> @@ -8,8 +8,7 @@ ConditionVirtualization=xen
>  
>  [Service]
>  Type=simple
> -EnvironmentFile=-/etc/default/xenstored
> -EnvironmentFile=-/etc/sysconfig/xenstored
> +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
>  PIDFile=@XEN_RUN_DIR@/qemu-dom0.pid
>  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
>  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> index 7ca0264..377f131 100644
> --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> @@ -9,8 +9,7 @@ Type=simple
>  Environment=XENCONSOLED_ARGS=
>  Environment=XENCONSOLED_LOG=none
>  Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
> -EnvironmentFile=-/etc/default/xenconsoled
> -EnvironmentFile=-/etc/sysconfig/xenconsoled
> +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
>  PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
>  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
>  ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
> diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
> index 013e69e..f85b37d 100644
> --- a/tools/hotplug/Linux/systemd/xenstored.service.in
> +++ b/tools/hotplug/Linux/systemd/xenstored.service.in
> @@ -11,8 +11,7 @@ Type=notify
>  Environment=XENSTORED_ARGS=
>  Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
>  Environment=XENSTORED=@XENSTORED@
> -EnvironmentFile=-/etc/default/xencommons
> -EnvironmentFile=-/etc/sysconfig/xencommons
> +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
>  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
>  ExecStartPre=-/bin/rm -f @XEN_LIB_STORED@/tdb*
>  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> diff --git a/tools/hotplug/Linux/xendomains.in b/tools/hotplug/Linux/xendomains.in
> index de711b7..2e65ac6 100644
> --- a/tools/hotplug/Linux/xendomains.in
> +++ b/tools/hotplug/Linux/xendomains.in
> @@ -51,11 +51,7 @@ fi
>  
>  LOCKFILE=${XEN_LOCK_DIR}/xendomains
>  
> -if [ -d /etc/sysconfig ]; then
> -	XENDOM_CONFIG=/etc/sysconfig/xendomains
> -else
> -	XENDOM_CONFIG=/etc/default/xendomains
> -fi
> +XENDOM_CONFIG=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xendomains
>  
>  test -r $XENDOM_CONFIG || { echo "$XENDOM_CONFIG not existing";
>  	if [ "$1" = "stop" ]; then exit 0;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:07:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVlo-0004yD-4l; Wed, 12 Nov 2014 11:07:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoVlm-0004xk-8T
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:07:26 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	66/58-02954-D6F33645; Wed, 12 Nov 2014 11:07:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415790443!6601249!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31527 invoked from network); 12 Nov 2014 11:07:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:07:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190468822"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:07:23 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoVli-0002QF-QA;
	Wed, 12 Nov 2014 11:07:22 +0000
Date: Wed, 12 Nov 2014 11:07:22 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141112110722.GC25821@zion.uk.xensource.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> Hi All,
> 
> This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> 

> 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901

See <1415790358-16787-1-git-send-email-wei.liu2@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 Nov 12 11:07:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVlo-0004yD-4l; Wed, 12 Nov 2014 11:07:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoVlm-0004xk-8T
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:07:26 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	66/58-02954-D6F33645; Wed, 12 Nov 2014 11:07:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415790443!6601249!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31527 invoked from network); 12 Nov 2014 11:07:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:07:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190468822"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:07:23 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoVli-0002QF-QA;
	Wed, 12 Nov 2014 11:07:22 +0000
Date: Wed, 12 Nov 2014 11:07:22 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141112110722.GC25821@zion.uk.xensource.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> Hi All,
> 
> This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> 

> 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901

See <1415790358-16787-1-git-send-email-wei.liu2@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 Nov 12 11:10:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:10:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVoM-0005GO-Pk; Wed, 12 Nov 2014 11:10:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoVoM-0005GH-3I
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:10:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	32/73-09936-D0043645; Wed, 12 Nov 2014 11:10:05 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415790604!12178235!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27400 invoked from network); 12 Nov 2014 11:10:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:10:04 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 668D4AAC3;
	Wed, 12 Nov 2014 11:10:04 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xen.org, jbeulich@suse.com, dietmar.hahn@ts.fujitsu.com,
	Andrew.Cooper3@citrix.com
Date: Wed, 12 Nov 2014 12:10:02 +0100
Message-Id: <1415790602-25779-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
	destroying 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of domains
is nor adjusted when a domain is moved to cpupool0 in kill_domain().

Correct this by introducing a cpupool function doing the move
instead of open coding it by calling sched_move_domain().

Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Reviewed-by: Andrew Cooper <Andrew.Cooper3@citrix.com>
---
 xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
 xen/common/domain.c     |  2 +-
 xen/include/xen/sched.h |  1 +
 3 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 73249d3..a758a8b 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
 }
 
 /*
+ * Move domain to another cpupool
+ */
+static int cpupool_move_domain_locked(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    d->cpupool->n_dom--;
+    ret = sched_move_domain(d, c);
+    if ( ret )
+        d->cpupool->n_dom++;
+    else
+        c->n_dom++;
+
+    return ret;
+}
+int cpupool_move_domain(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    spin_lock(&cpupool_lock);
+
+    ret = cpupool_move_domain_locked(d, c);
+
+    spin_unlock(&cpupool_lock);
+
+    return ret;
+}
+
+/*
  * assign a specific cpu to a cpupool
  * cpupool_lock must be held
  */
@@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
                 ret = -EBUSY;
                 break;
             }
-            c->n_dom--;
-            ret = sched_move_domain(d, cpupool0);
+            ret = cpupool_move_domain_locked(d, cpupool0);
             if ( ret )
-            {
-                c->n_dom++;
                 break;
-            }
-            cpupool0->n_dom++;
         }
         rcu_read_unlock(&domlist_read_lock);
         if ( ret )
@@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
                         d->domain_id, op->cpupool_id);
         ret = -ENOENT;
         spin_lock(&cpupool_lock);
+
         c = cpupool_find_by_id(op->cpupool_id);
         if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
-        {
-            d->cpupool->n_dom--;
-            ret = sched_move_domain(d, c);
-            if ( ret )
-                d->cpupool->n_dom++;
-            else
-                c->n_dom++;
-        }
+            ret = cpupool_move_domain_locked(d, c);
+
         spin_unlock(&cpupool_lock);
         cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
                         d->domain_id, op->cpupool_id, ret);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index a3f51ec..4a62c1d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
                 rc = -EAGAIN;
             break;
         }
-        if ( sched_move_domain(d, cpupool0) )
+        if ( cpupool_move_domain(d, cpupool0) )
             return -EAGAIN;
         for_each_vcpu ( d, v )
             unmap_vcpu_info(v);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index c5157e6..46fc6e3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
 void cpupool_put(struct cpupool *pool);
 int cpupool_add_domain(struct domain *d, int poolid);
 void cpupool_rm_domain(struct domain *d);
+int cpupool_move_domain(struct domain *d, struct cpupool *c);
 int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
 void schedule_dump(struct cpupool *c);
 extern void dump_runq(unsigned char key);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:10:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:10:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVoM-0005GO-Pk; Wed, 12 Nov 2014 11:10:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoVoM-0005GH-3I
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:10:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	32/73-09936-D0043645; Wed, 12 Nov 2014 11:10:05 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415790604!12178235!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27400 invoked from network); 12 Nov 2014 11:10:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:10:04 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 668D4AAC3;
	Wed, 12 Nov 2014 11:10:04 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xen.org, jbeulich@suse.com, dietmar.hahn@ts.fujitsu.com,
	Andrew.Cooper3@citrix.com
Date: Wed, 12 Nov 2014 12:10:02 +0100
Message-Id: <1415790602-25779-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
	destroying 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
cpupool0 before destroying it) introduced an error in the accounting
of cpupools regarding the number of domains. The number of domains
is nor adjusted when a domain is moved to cpupool0 in kill_domain().

Correct this by introducing a cpupool function doing the move
instead of open coding it by calling sched_move_domain().

Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Reviewed-by: Andrew Cooper <Andrew.Cooper3@citrix.com>
---
 xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
 xen/common/domain.c     |  2 +-
 xen/include/xen/sched.h |  1 +
 3 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 73249d3..a758a8b 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
 }
 
 /*
+ * Move domain to another cpupool
+ */
+static int cpupool_move_domain_locked(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    d->cpupool->n_dom--;
+    ret = sched_move_domain(d, c);
+    if ( ret )
+        d->cpupool->n_dom++;
+    else
+        c->n_dom++;
+
+    return ret;
+}
+int cpupool_move_domain(struct domain *d, struct cpupool *c)
+{
+    int ret;
+
+    spin_lock(&cpupool_lock);
+
+    ret = cpupool_move_domain_locked(d, c);
+
+    spin_unlock(&cpupool_lock);
+
+    return ret;
+}
+
+/*
  * assign a specific cpu to a cpupool
  * cpupool_lock must be held
  */
@@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
                 ret = -EBUSY;
                 break;
             }
-            c->n_dom--;
-            ret = sched_move_domain(d, cpupool0);
+            ret = cpupool_move_domain_locked(d, cpupool0);
             if ( ret )
-            {
-                c->n_dom++;
                 break;
-            }
-            cpupool0->n_dom++;
         }
         rcu_read_unlock(&domlist_read_lock);
         if ( ret )
@@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
                         d->domain_id, op->cpupool_id);
         ret = -ENOENT;
         spin_lock(&cpupool_lock);
+
         c = cpupool_find_by_id(op->cpupool_id);
         if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
-        {
-            d->cpupool->n_dom--;
-            ret = sched_move_domain(d, c);
-            if ( ret )
-                d->cpupool->n_dom++;
-            else
-                c->n_dom++;
-        }
+            ret = cpupool_move_domain_locked(d, c);
+
         spin_unlock(&cpupool_lock);
         cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
                         d->domain_id, op->cpupool_id, ret);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index a3f51ec..4a62c1d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
                 rc = -EAGAIN;
             break;
         }
-        if ( sched_move_domain(d, cpupool0) )
+        if ( cpupool_move_domain(d, cpupool0) )
             return -EAGAIN;
         for_each_vcpu ( d, v )
             unmap_vcpu_info(v);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index c5157e6..46fc6e3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
 void cpupool_put(struct cpupool *pool);
 int cpupool_add_domain(struct domain *d, int poolid);
 void cpupool_rm_domain(struct domain *d);
+int cpupool_move_domain(struct domain *d, struct cpupool *c);
 int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
 void schedule_dump(struct cpupool *c);
 extern void dump_runq(unsigned char key);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:10:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:10:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVoe-0005JJ-H1; Wed, 12 Nov 2014 11:10:24 +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 1XoVod-0005J5-Bz
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:10:23 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	9B/B3-02953-E1043645; Wed, 12 Nov 2014 11:10:22 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415790621!12018907!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12880 invoked from network); 12 Nov 2014 11:10:21 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:10:21 -0000
Received: by mail-wi0-f178.google.com with SMTP id bs8so4463151wib.5
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 03:10:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=nSOPJ3qu5HHyWscA6mWRaK61TN72nxz9mkjbjZp+Jlw=;
	b=vlCFaxQw83aqQ101vjrqXf1RgdVD8mWQA7NUrvHsFiZtIN0+gnyZG2tVaGyPCg8LmP
	kV0AYxlN5Q8ruPqjLSFcx858Fyz+OZm1T612D1OFjx9B+Zib0sMkN0ra4/U9MSgZcY1S
	FzVn0ulsy8m6pojCMMjxaimwzsWW/cptsQ5as1PAAHIme7VoZ04MWA50b0AZsZLRY2bV
	gdufPws9IszRcpBCtoXp5cSsJsX99oWXTphUzzGrm9o9csNNiSIWfzAJBkU5/EcDmj2x
	lUU2384ntWxePBEdKuBMJrCSfl6yMXNuj2aHDfLZz/41yoT6POnvK6k2ic5nwvsjiOYW
	LKzw==
MIME-Version: 1.0
X-Received: by 10.180.82.4 with SMTP id e4mr48059814wiy.42.1415790621273; Wed,
	12 Nov 2014 03:10:21 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Wed, 12 Nov 2014 03:10:21 -0800 (PST)
In-Reply-To: <1415788840-19497-1-git-send-email-jgross@suse.com>
References: <1415788840-19497-1-git-send-email-jgross@suse.com>
Date: Wed, 12 Nov 2014 11:10:21 +0000
X-Google-Sender-Auth: bqphBZTOPQIYpOyJMMxBLQq7TkE
Message-ID: <CAFLBxZb+5prz8uTWrJzt-ZYLNTQv3W1g-oGg0ZsgzeNbkE+xLw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Juergen Gross <jgross@suse.com>
Cc: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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 Wed, Nov 12, 2014 at 10:40 AM, Juergen Gross <jgross@suse.com> wrote:
> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> cpupool0 before destroying it) introduced an error in the accounting
> of cpupools regarding the number of domains. The number of domains
> is nor adjusted when a domain is moved to cpupool0 in kill_domain().
>
> Correct this by introducing a cpupool function doing the move
> instead of open coding it by calling sched_move_domain().
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

Juergen / Dietmar -- do either of you have a reasonably complete set
of tests for cpupools?  It seems like even basic corner cases (like
shutting down a domain in a pool and then destroying a pool) aren't
being tested.

It would be really good if someone could try to do a more thorough
test before the 4.5 release.  It shouldn't be too hard to write a
script to test a lot of this functionality programmatically.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:10:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:10:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVoe-0005JJ-H1; Wed, 12 Nov 2014 11:10:24 +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 1XoVod-0005J5-Bz
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:10:23 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	9B/B3-02953-E1043645; Wed, 12 Nov 2014 11:10:22 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415790621!12018907!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12880 invoked from network); 12 Nov 2014 11:10:21 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:10:21 -0000
Received: by mail-wi0-f178.google.com with SMTP id bs8so4463151wib.5
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 03:10:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=nSOPJ3qu5HHyWscA6mWRaK61TN72nxz9mkjbjZp+Jlw=;
	b=vlCFaxQw83aqQ101vjrqXf1RgdVD8mWQA7NUrvHsFiZtIN0+gnyZG2tVaGyPCg8LmP
	kV0AYxlN5Q8ruPqjLSFcx858Fyz+OZm1T612D1OFjx9B+Zib0sMkN0ra4/U9MSgZcY1S
	FzVn0ulsy8m6pojCMMjxaimwzsWW/cptsQ5as1PAAHIme7VoZ04MWA50b0AZsZLRY2bV
	gdufPws9IszRcpBCtoXp5cSsJsX99oWXTphUzzGrm9o9csNNiSIWfzAJBkU5/EcDmj2x
	lUU2384ntWxePBEdKuBMJrCSfl6yMXNuj2aHDfLZz/41yoT6POnvK6k2ic5nwvsjiOYW
	LKzw==
MIME-Version: 1.0
X-Received: by 10.180.82.4 with SMTP id e4mr48059814wiy.42.1415790621273; Wed,
	12 Nov 2014 03:10:21 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Wed, 12 Nov 2014 03:10:21 -0800 (PST)
In-Reply-To: <1415788840-19497-1-git-send-email-jgross@suse.com>
References: <1415788840-19497-1-git-send-email-jgross@suse.com>
Date: Wed, 12 Nov 2014 11:10:21 +0000
X-Google-Sender-Auth: bqphBZTOPQIYpOyJMMxBLQq7TkE
Message-ID: <CAFLBxZb+5prz8uTWrJzt-ZYLNTQv3W1g-oGg0ZsgzeNbkE+xLw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Juergen Gross <jgross@suse.com>
Cc: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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 Wed, Nov 12, 2014 at 10:40 AM, Juergen Gross <jgross@suse.com> wrote:
> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> cpupool0 before destroying it) introduced an error in the accounting
> of cpupools regarding the number of domains. The number of domains
> is nor adjusted when a domain is moved to cpupool0 in kill_domain().
>
> Correct this by introducing a cpupool function doing the move
> instead of open coding it by calling sched_move_domain().
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

Juergen / Dietmar -- do either of you have a reasonably complete set
of tests for cpupools?  It seems like even basic corner cases (like
shutting down a domain in a pool and then destroying a pool) aren't
being tested.

It would be really good if someone could try to do a more thorough
test before the 4.5 release.  It shouldn't be too hard to write a
script to test a lot of this functionality programmatically.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:11:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11: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 1XoVpX-0005Sb-0N; Wed, 12 Nov 2014 11:11:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XoVpV-0005SJ-Py
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:11:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	67/76-09842-55043645; Wed, 12 Nov 2014 11:11:17 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415790676!12178614!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4054 invoked from network); 12 Nov 2014 11:11:16 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:11:16 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so3072635wgg.35
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 03:11:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=WuFcZOv+GKqQb0ehzAiEAoPGDjw0EYnIU6apltC8lp8=;
	b=1F/ajdcCKKVz2PNFfeREzTcn1dTRZ2vWa/8/gPAE/Wzd8/htQdhaUQj8qPGkQRSM8I
	fPKJpW5joFu8SB9ab6HIqkdHI1dZtRd0ZBEueVSHIyZ5Na2CTUod/g+FAN7nirsD6xBt
	HE1WMsJwRIUWZKpeipB3H3mxIcntQ/XK4Vuk/RAbo1Cd+oHx+IEwuF8ylneO6OKFIiQK
	VCY2TYCycnBfLnkNYiT8rV0Xi3TfFuvLF2vsysf9VDidAZMFV8VP987qRhnkFOQUOgyM
	FxShBgnL+IBlX2MQqVV38HA66nHrpFTAd7zPkkRFr34fXFmOX7VKpkXXK/ej5WIjS15Z
	/ShA==
MIME-Version: 1.0
X-Received: by 10.194.250.41 with SMTP id yz9mr63974341wjc.34.1415790675540;
	Wed, 12 Nov 2014 03:11:15 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Wed, 12 Nov 2014 03:11:15 -0800 (PST)
In-Reply-To: <1415790602-25779-1-git-send-email-jgross@suse.com>
References: <1415790602-25779-1-git-send-email-jgross@suse.com>
Date: Wed, 12 Nov 2014 11:11:15 +0000
X-Google-Sender-Auth: r39yzT1gqujcvA7_MESEIkTaPk0
Message-ID: <CAFLBxZbtXBEdG5gWYgGOeAB1zJr=E7hLVd4f4=bXFQ7juLWvPg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>,
	Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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 Wed, Nov 12, 2014 at 11:10 AM, Juergen Gross <jgross@suse.com> wrote:
> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> cpupool0 before destroying it) introduced an error in the accounting
> of cpupools regarding the number of domains. The number of domains
> is nor adjusted when a domain is moved to cpupool0 in kill_domain().
>
> Correct this by introducing a cpupool function doing the move
> instead of open coding it by calling sched_move_domain().
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> Reviewed-by: Andrew Cooper <Andrew.Cooper3@citrix.com>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:11:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11: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 1XoVpX-0005Sb-0N; Wed, 12 Nov 2014 11:11:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XoVpV-0005SJ-Py
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:11:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	67/76-09842-55043645; Wed, 12 Nov 2014 11:11:17 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415790676!12178614!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4054 invoked from network); 12 Nov 2014 11:11:16 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:11:16 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so3072635wgg.35
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 03:11:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=WuFcZOv+GKqQb0ehzAiEAoPGDjw0EYnIU6apltC8lp8=;
	b=1F/ajdcCKKVz2PNFfeREzTcn1dTRZ2vWa/8/gPAE/Wzd8/htQdhaUQj8qPGkQRSM8I
	fPKJpW5joFu8SB9ab6HIqkdHI1dZtRd0ZBEueVSHIyZ5Na2CTUod/g+FAN7nirsD6xBt
	HE1WMsJwRIUWZKpeipB3H3mxIcntQ/XK4Vuk/RAbo1Cd+oHx+IEwuF8ylneO6OKFIiQK
	VCY2TYCycnBfLnkNYiT8rV0Xi3TfFuvLF2vsysf9VDidAZMFV8VP987qRhnkFOQUOgyM
	FxShBgnL+IBlX2MQqVV38HA66nHrpFTAd7zPkkRFr34fXFmOX7VKpkXXK/ej5WIjS15Z
	/ShA==
MIME-Version: 1.0
X-Received: by 10.194.250.41 with SMTP id yz9mr63974341wjc.34.1415790675540;
	Wed, 12 Nov 2014 03:11:15 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Wed, 12 Nov 2014 03:11:15 -0800 (PST)
In-Reply-To: <1415790602-25779-1-git-send-email-jgross@suse.com>
References: <1415790602-25779-1-git-send-email-jgross@suse.com>
Date: Wed, 12 Nov 2014 11:11:15 +0000
X-Google-Sender-Auth: r39yzT1gqujcvA7_MESEIkTaPk0
Message-ID: <CAFLBxZbtXBEdG5gWYgGOeAB1zJr=E7hLVd4f4=bXFQ7juLWvPg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>,
	Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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 Wed, Nov 12, 2014 at 11:10 AM, Juergen Gross <jgross@suse.com> wrote:
> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> cpupool0 before destroying it) introduced an error in the accounting
> of cpupools regarding the number of domains. The number of domains
> is nor adjusted when a domain is moved to cpupool0 in kill_domain().
>
> Correct this by introducing a cpupool function doing the move
> instead of open coding it by calling sched_move_domain().
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> Reviewed-by: Andrew Cooper <Andrew.Cooper3@citrix.com>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:11:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:11:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVph-0005V2-Cn; Wed, 12 Nov 2014 11:11: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 1XoVpg-0005Un-JX
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:11:28 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	E6/4B-02699-06043645; Wed, 12 Nov 2014 11:11:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415790686!12031556!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29437 invoked from network); 12 Nov 2014 11:11: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;
	12 Nov 2014 11:11:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190469500"
Message-ID: <1415790652.29592.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 12 Nov 2014 11:10:52 +0000
In-Reply-To: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Chao Peng <chao.p.peng@linux.intel.com>,
	Dongxiao Xu <dongxiao.xu@intel.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
	libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CCing the folks who signed-of-by is on the original patch

On Wed, 2014-11-12 at 11:05 +0000, Wei Liu wrote:
> The `if' statement considered return value 0 from libxl_domain_info an
> error, while 0 actually means success.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
> This is a bug fix for PSR feature. This feature was added recently and it's
> not an regression. However, it would be good to have it working correctly
> since the beginning, and the fix is straightforward, which should be of
> very low risk.

Ack.

> ---
>  tools/libxl/xl_cmdimpl.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3c9f146..9afef3f 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -7908,7 +7908,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
>      /* Each domain */
>      if (domid != INVALID_DOMID) {
>          libxl_dominfo dominfo;
> -        if (!libxl_domain_info(ctx, &dominfo, domid)) {
> +        if (libxl_domain_info(ctx, &dominfo, domid)) {
>              fprintf(stderr, "Failed to get domain info for %d\n", domid);
>              return -1;
>          }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:11:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:11:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVph-0005V2-Cn; Wed, 12 Nov 2014 11:11: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 1XoVpg-0005Un-JX
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:11:28 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	E6/4B-02699-06043645; Wed, 12 Nov 2014 11:11:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415790686!12031556!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29437 invoked from network); 12 Nov 2014 11:11: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;
	12 Nov 2014 11:11:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190469500"
Message-ID: <1415790652.29592.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 12 Nov 2014 11:10:52 +0000
In-Reply-To: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Chao Peng <chao.p.peng@linux.intel.com>,
	Dongxiao Xu <dongxiao.xu@intel.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
	libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CCing the folks who signed-of-by is on the original patch

On Wed, 2014-11-12 at 11:05 +0000, Wei Liu wrote:
> The `if' statement considered return value 0 from libxl_domain_info an
> error, while 0 actually means success.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
> This is a bug fix for PSR feature. This feature was added recently and it's
> not an regression. However, it would be good to have it working correctly
> since the beginning, and the fix is straightforward, which should be of
> very low risk.

Ack.

> ---
>  tools/libxl/xl_cmdimpl.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3c9f146..9afef3f 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -7908,7 +7908,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
>      /* Each domain */
>      if (domid != INVALID_DOMID) {
>          libxl_dominfo dominfo;
> -        if (!libxl_domain_info(ctx, &dominfo, domid)) {
> +        if (libxl_domain_info(ctx, &dominfo, domid)) {
>              fprintf(stderr, "Failed to get domain info for %d\n", domid);
>              return -1;
>          }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:12:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:12:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVqP-0005h2-Rw; Wed, 12 Nov 2014 11:12: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 1XoVqO-0005ge-AG
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:12:12 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	91/98-28865-B8043645; Wed, 12 Nov 2014 11:12:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415790729!7501268!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16960 invoked from network); 12 Nov 2014 11:12:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:12:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190469701"
Message-ID: <1415790726.29592.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 12 Nov 2014 11:12:06 +0000
In-Reply-To: <20141112110640.GA26748@aepfle.de>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

You forgot to add the release manager... I've done that for you.

In <1413279117.1497.25.camel@citrix.com> I said:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Is this a bug fix or a feature? What are the risks? IsLKonrad OK with
> it?

On Wed, 2014-11-12 at 12:06 +0100, Olaf Hering wrote:
> Ping?
> 
> 
> > ... instead of hardcoding values and guess where they config files may
> > be. Also use the result of --with-sysconfig-leaf-dir.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  tools/hotplug/Linux/init.d/xencommons.in                          | 6 +-----
> >  tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 3 +--
> >  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 3 +--
> >  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 3 +--
> >  tools/hotplug/Linux/systemd/xenstored.service.in                  | 3 +--
> >  tools/hotplug/Linux/xendomains.in                                 | 6 +-----
> >  6 files changed, 6 insertions(+), 18 deletions(-)
> > 
> > diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
> > index d53a1f3..a1095c2 100644
> > --- a/tools/hotplug/Linux/init.d/xencommons.in
> > +++ b/tools/hotplug/Linux/init.d/xencommons.in
> > @@ -23,11 +23,7 @@ BACKEND_MODULES="@LINUX_BACKEND_MODULES@"
> >  
> >  . @XEN_SCRIPT_DIR@/hotplugpath.sh
> >  
> > -if [ -d /etc/sysconfig ]; then
> > -	xencommons_config=/etc/sysconfig
> > -else
> > -	xencommons_config=/etc/default
> > -fi
> > +xencommons_config=@CONFIG_DIR@/@CONFIG_LEAF_DIR@
> >  
> >  test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
> >  
> > diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > index 44dfce8..1e930ed 100644
> > --- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > +++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > @@ -5,8 +5,7 @@ RefuseManualStop=true
> >  
> >  [Mount]
> >  Environment=XENSTORED_MOUNT_CTX=none
> > -EnvironmentFile=-/etc/sysconfig/xenstored
> > -EnvironmentFile=-/etc/default/xenstored
> > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> >  What=xenstore
> >  Where=@XEN_LIB_STORED@
> >  Type=tmpfs
> > diff --git a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > index d3470fc..2282923 100644
> > --- a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > +++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > @@ -8,8 +8,7 @@ ConditionVirtualization=xen
> >  
> >  [Service]
> >  Type=simple
> > -EnvironmentFile=-/etc/default/xenstored
> > -EnvironmentFile=-/etc/sysconfig/xenstored
> > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> >  PIDFile=@XEN_RUN_DIR@/qemu-dom0.pid
> >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> >  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> > diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > index 7ca0264..377f131 100644
> > --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > @@ -9,8 +9,7 @@ Type=simple
> >  Environment=XENCONSOLED_ARGS=
> >  Environment=XENCONSOLED_LOG=none
> >  Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
> > -EnvironmentFile=-/etc/default/xenconsoled
> > -EnvironmentFile=-/etc/sysconfig/xenconsoled
> > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
> >  PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
> >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> >  ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
> > diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
> > index 013e69e..f85b37d 100644
> > --- a/tools/hotplug/Linux/systemd/xenstored.service.in
> > +++ b/tools/hotplug/Linux/systemd/xenstored.service.in
> > @@ -11,8 +11,7 @@ Type=notify
> >  Environment=XENSTORED_ARGS=
> >  Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
> >  Environment=XENSTORED=@XENSTORED@
> > -EnvironmentFile=-/etc/default/xencommons
> > -EnvironmentFile=-/etc/sysconfig/xencommons
> > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
> >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> >  ExecStartPre=-/bin/rm -f @XEN_LIB_STORED@/tdb*
> >  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> > diff --git a/tools/hotplug/Linux/xendomains.in b/tools/hotplug/Linux/xendomains.in
> > index de711b7..2e65ac6 100644
> > --- a/tools/hotplug/Linux/xendomains.in
> > +++ b/tools/hotplug/Linux/xendomains.in
> > @@ -51,11 +51,7 @@ fi
> >  
> >  LOCKFILE=${XEN_LOCK_DIR}/xendomains
> >  
> > -if [ -d /etc/sysconfig ]; then
> > -	XENDOM_CONFIG=/etc/sysconfig/xendomains
> > -else
> > -	XENDOM_CONFIG=/etc/default/xendomains
> > -fi
> > +XENDOM_CONFIG=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xendomains
> >  
> >  test -r $XENDOM_CONFIG || { echo "$XENDOM_CONFIG not existing";
> >  	if [ "$1" = "stop" ]; then exit 0;
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:12:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:12:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVqP-0005h2-Rw; Wed, 12 Nov 2014 11:12: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 1XoVqO-0005ge-AG
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:12:12 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	91/98-28865-B8043645; Wed, 12 Nov 2014 11:12:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415790729!7501268!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16960 invoked from network); 12 Nov 2014 11:12:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:12:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190469701"
Message-ID: <1415790726.29592.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 12 Nov 2014 11:12:06 +0000
In-Reply-To: <20141112110640.GA26748@aepfle.de>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

You forgot to add the release manager... I've done that for you.

In <1413279117.1497.25.camel@citrix.com> I said:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Is this a bug fix or a feature? What are the risks? IsLKonrad OK with
> it?

On Wed, 2014-11-12 at 12:06 +0100, Olaf Hering wrote:
> Ping?
> 
> 
> > ... instead of hardcoding values and guess where they config files may
> > be. Also use the result of --with-sysconfig-leaf-dir.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  tools/hotplug/Linux/init.d/xencommons.in                          | 6 +-----
> >  tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 3 +--
> >  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 3 +--
> >  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 3 +--
> >  tools/hotplug/Linux/systemd/xenstored.service.in                  | 3 +--
> >  tools/hotplug/Linux/xendomains.in                                 | 6 +-----
> >  6 files changed, 6 insertions(+), 18 deletions(-)
> > 
> > diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
> > index d53a1f3..a1095c2 100644
> > --- a/tools/hotplug/Linux/init.d/xencommons.in
> > +++ b/tools/hotplug/Linux/init.d/xencommons.in
> > @@ -23,11 +23,7 @@ BACKEND_MODULES="@LINUX_BACKEND_MODULES@"
> >  
> >  . @XEN_SCRIPT_DIR@/hotplugpath.sh
> >  
> > -if [ -d /etc/sysconfig ]; then
> > -	xencommons_config=/etc/sysconfig
> > -else
> > -	xencommons_config=/etc/default
> > -fi
> > +xencommons_config=@CONFIG_DIR@/@CONFIG_LEAF_DIR@
> >  
> >  test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
> >  
> > diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > index 44dfce8..1e930ed 100644
> > --- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > +++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > @@ -5,8 +5,7 @@ RefuseManualStop=true
> >  
> >  [Mount]
> >  Environment=XENSTORED_MOUNT_CTX=none
> > -EnvironmentFile=-/etc/sysconfig/xenstored
> > -EnvironmentFile=-/etc/default/xenstored
> > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> >  What=xenstore
> >  Where=@XEN_LIB_STORED@
> >  Type=tmpfs
> > diff --git a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > index d3470fc..2282923 100644
> > --- a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > +++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > @@ -8,8 +8,7 @@ ConditionVirtualization=xen
> >  
> >  [Service]
> >  Type=simple
> > -EnvironmentFile=-/etc/default/xenstored
> > -EnvironmentFile=-/etc/sysconfig/xenstored
> > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> >  PIDFile=@XEN_RUN_DIR@/qemu-dom0.pid
> >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> >  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> > diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > index 7ca0264..377f131 100644
> > --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > @@ -9,8 +9,7 @@ Type=simple
> >  Environment=XENCONSOLED_ARGS=
> >  Environment=XENCONSOLED_LOG=none
> >  Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
> > -EnvironmentFile=-/etc/default/xenconsoled
> > -EnvironmentFile=-/etc/sysconfig/xenconsoled
> > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
> >  PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
> >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> >  ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
> > diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
> > index 013e69e..f85b37d 100644
> > --- a/tools/hotplug/Linux/systemd/xenstored.service.in
> > +++ b/tools/hotplug/Linux/systemd/xenstored.service.in
> > @@ -11,8 +11,7 @@ Type=notify
> >  Environment=XENSTORED_ARGS=
> >  Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
> >  Environment=XENSTORED=@XENSTORED@
> > -EnvironmentFile=-/etc/default/xencommons
> > -EnvironmentFile=-/etc/sysconfig/xencommons
> > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
> >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> >  ExecStartPre=-/bin/rm -f @XEN_LIB_STORED@/tdb*
> >  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> > diff --git a/tools/hotplug/Linux/xendomains.in b/tools/hotplug/Linux/xendomains.in
> > index de711b7..2e65ac6 100644
> > --- a/tools/hotplug/Linux/xendomains.in
> > +++ b/tools/hotplug/Linux/xendomains.in
> > @@ -51,11 +51,7 @@ fi
> >  
> >  LOCKFILE=${XEN_LOCK_DIR}/xendomains
> >  
> > -if [ -d /etc/sysconfig ]; then
> > -	XENDOM_CONFIG=/etc/sysconfig/xendomains
> > -else
> > -	XENDOM_CONFIG=/etc/default/xendomains
> > -fi
> > +XENDOM_CONFIG=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xendomains
> >  
> >  test -r $XENDOM_CONFIG || { echo "$XENDOM_CONFIG not existing";
> >  	if [ "$1" = "stop" ]; then exit 0;
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:21:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:21:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVz2-00066G-Sx; Wed, 12 Nov 2014 11:21:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoVz1-000668-2T
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:21:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	28/39-09936-2A243645; Wed, 12 Nov 2014 11:21:06 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415791265!12181649!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16128 invoked from network); 12 Nov 2014 11:21:05 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:21:05 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8385EAAC3;
	Wed, 12 Nov 2014 11:21:05 +0000 (UTC)
Message-ID: <546342A0.2080501@suse.com>
Date: Wed, 12 Nov 2014 12:21:04 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>, 
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
References: <1415788840-19497-1-git-send-email-jgross@suse.com>
	<CAFLBxZb+5prz8uTWrJzt-ZYLNTQv3W1g-oGg0ZsgzeNbkE+xLw@mail.gmail.com>
In-Reply-To: <CAFLBxZb+5prz8uTWrJzt-ZYLNTQv3W1g-oGg0ZsgzeNbkE+xLw@mail.gmail.com>
Cc: lutz.dube@ts.fujitsu.com, Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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

On 11/12/2014 12:10 PM, George Dunlap wrote:
> On Wed, Nov 12, 2014 at 10:40 AM, Juergen Gross <jgross@suse.com> wrote:
>> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
>> cpupool0 before destroying it) introduced an error in the accounting
>> of cpupools regarding the number of domains. The number of domains
>> is nor adjusted when a domain is moved to cpupool0 in kill_domain().
>>
>> Correct this by introducing a cpupool function doing the move
>> instead of open coding it by calling sched_move_domain().
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
>
> Juergen / Dietmar -- do either of you have a reasonably complete set
> of tests for cpupools?  It seems like even basic corner cases (like
> shutting down a domain in a pool and then destroying a pool) aren't
> being tested.
>
> It would be really good if someone could try to do a more thorough
> test before the 4.5 release.  It shouldn't be too hard to write a
> script to test a lot of this functionality programmatically.

For the xm toolstack we had some tests at Fujitsu. Dietmar, you could
ask Lutz for advice. He might still have the scripts somewhere. They
should be easily adaptable to xl. In case you don't have time to try
them would you send them to me?

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:21:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:21:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoVz2-00066G-Sx; Wed, 12 Nov 2014 11:21:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoVz1-000668-2T
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:21:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	28/39-09936-2A243645; Wed, 12 Nov 2014 11:21:06 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415791265!12181649!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16128 invoked from network); 12 Nov 2014 11:21:05 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 11:21:05 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8385EAAC3;
	Wed, 12 Nov 2014 11:21:05 +0000 (UTC)
Message-ID: <546342A0.2080501@suse.com>
Date: Wed, 12 Nov 2014 12:21:04 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>, 
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
References: <1415788840-19497-1-git-send-email-jgross@suse.com>
	<CAFLBxZb+5prz8uTWrJzt-ZYLNTQv3W1g-oGg0ZsgzeNbkE+xLw@mail.gmail.com>
In-Reply-To: <CAFLBxZb+5prz8uTWrJzt-ZYLNTQv3W1g-oGg0ZsgzeNbkE+xLw@mail.gmail.com>
Cc: lutz.dube@ts.fujitsu.com, Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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

On 11/12/2014 12:10 PM, George Dunlap wrote:
> On Wed, Nov 12, 2014 at 10:40 AM, Juergen Gross <jgross@suse.com> wrote:
>> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
>> cpupool0 before destroying it) introduced an error in the accounting
>> of cpupools regarding the number of domains. The number of domains
>> is nor adjusted when a domain is moved to cpupool0 in kill_domain().
>>
>> Correct this by introducing a cpupool function doing the move
>> instead of open coding it by calling sched_move_domain().
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
>
> Juergen / Dietmar -- do either of you have a reasonably complete set
> of tests for cpupools?  It seems like even basic corner cases (like
> shutting down a domain in a pool and then destroying a pool) aren't
> being tested.
>
> It would be really good if someone could try to do a more thorough
> test before the 4.5 release.  It shouldn't be too hard to write a
> script to test a lot of this functionality programmatically.

For the xm toolstack we had some tests at Fujitsu. Dietmar, you could
ask Lutz for advice. He might still have the scripts somewhere. They
should be easily adaptable to xl. In case you don't have time to try
them would you send them to me?

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:32:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:32:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoW9c-0006Nv-6q; Wed, 12 Nov 2014 11:32:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoW9a-0006Nq-3m
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 11:32:02 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	44/3C-14214-13543645; Wed, 12 Nov 2014 11:32:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415791918!10849684!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29335 invoked from network); 12 Nov 2014 11:31:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:31:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191919199"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:31:57 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoW9U-00034C-PW;
	Wed, 12 Nov 2014 11:31:56 +0000
Date: Wed, 12 Nov 2014 11:31:56 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141112113156.GA28075@zion.uk.xensource.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54623C5C.6010504@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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, Nov 11, 2014 at 11:42:04AM -0500, Zhigang Wang wrote:
> On 11/11/2014 10:20 AM, Wei Liu wrote:
> > On Tue, Nov 11, 2014 at 09:41:32AM -0500, Zhigang Wang wrote:
> >> On 11/11/2014 06:01 AM, Wei Liu wrote:
> >>> On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
> >>> [...]
> >>>> Could you please explain what does "no configuration" means?
> >>>>
> >>>> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
> >>>>
> >>>
> >>> That means no configuration at all. I think a skeleton can be provided
> >>> at best (in xl level) to be consistent with "xl list", which should
> >>> include domid and domain name etc. Since nothing else exists in
> >>> xenstore yet, there's no point poking there.
> >>
> >> This approach should works for me.
> >>
> >>> [...]
> >>>> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
> >>>>
> >>>
> >>> Hmm... I don't think poking around in different places is a good idea.
> >>> This is prone to breakage in the future.
> >>
> >> I agree.
> >>  
> >>> Since xenstore is not filled in when your tool looks at it, what makes
> >>> it different to wait a bit until migration finishes?
> >>
> >> The logic is: when migration started, high level management console will check
> >> destination side to make sure the VM is running there 
> >> (currently call xl list -l <domain>).
> >>
> >> If I can get enough runtime info (even some are missing), I think it should be OK.
> >>
> > 
> > What runtime info do you need?
> 
> Currently we need:
> 
>   info['domid']
>   info['config']['b_info']['avail_vcpus']
>   info['config']['c_info']['uuid']
>   info['config']['b_info']['target_memkb']
> 
> Also read vnc port from xenstore.  
> 

Unfortunately this won't work, as not everything you need is in xenstore
at that point (see the xenstore entries you posted). It's not something
that can be easily worked around in xl by creating a stub -- even the
stub needs to get its information from somewhere.

> We may add more.
> 

This also means even if we create a stub now, it's still prone to
breakage in the future.

I think the root cause of your problem is xend and libxl fires
@introduceDomain at different point (correct me if I'm wrong, because I
haven't looked at xend code, only inferred from your reply). It should
be fixed there, not patching xl.

Wei.

> But during migration, I believe it's OK if some info is missing. Our high level
> management stack will handle it.
> 
> Thanks,
> 
> Zhigang
> 
> > As I understand it's something in the long output -- otherwise you would
> > have used the short output already if you only need to check the
> > existence and / or state of a domain.
> > 
> >>> And, from your earlier reply, you're implying Xend fires
> >>> @introduceDomain at the same point as xl, but your tool can work with
> >>> it?
> >>
> >> For xm/xend, VM xenstore entries already populated before @introduceDomain.
> >> "xm list -l" will show the right information.
> >>
> >> Anyone knows what prevents us from populating VM xenstore entries during migration in libxl?
> >>
> > 
> > FWIW in libxl @introduceDomain is fired after domain is built, before
> > adding devices. If you're after device information, it's a bit late.
> > 
> > Xend might have done it in different order. I don't know.
> > 
> > Whether we can change libxl to do so, I'm not sure. But it's definitely
> > not 4.5 material.
> > 
> > Wei.
> > 
> >> Thanks,
> >>
> >> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:32:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:32:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoW9c-0006Nv-6q; Wed, 12 Nov 2014 11:32:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoW9a-0006Nq-3m
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 11:32:02 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	44/3C-14214-13543645; Wed, 12 Nov 2014 11:32:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415791918!10849684!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29335 invoked from network); 12 Nov 2014 11:31:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:31:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191919199"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:31:57 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoW9U-00034C-PW;
	Wed, 12 Nov 2014 11:31:56 +0000
Date: Wed, 12 Nov 2014 11:31:56 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141112113156.GA28075@zion.uk.xensource.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54623C5C.6010504@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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, Nov 11, 2014 at 11:42:04AM -0500, Zhigang Wang wrote:
> On 11/11/2014 10:20 AM, Wei Liu wrote:
> > On Tue, Nov 11, 2014 at 09:41:32AM -0500, Zhigang Wang wrote:
> >> On 11/11/2014 06:01 AM, Wei Liu wrote:
> >>> On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
> >>> [...]
> >>>> Could you please explain what does "no configuration" means?
> >>>>
> >>>> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
> >>>>
> >>>
> >>> That means no configuration at all. I think a skeleton can be provided
> >>> at best (in xl level) to be consistent with "xl list", which should
> >>> include domid and domain name etc. Since nothing else exists in
> >>> xenstore yet, there's no point poking there.
> >>
> >> This approach should works for me.
> >>
> >>> [...]
> >>>> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
> >>>>
> >>>
> >>> Hmm... I don't think poking around in different places is a good idea.
> >>> This is prone to breakage in the future.
> >>
> >> I agree.
> >>  
> >>> Since xenstore is not filled in when your tool looks at it, what makes
> >>> it different to wait a bit until migration finishes?
> >>
> >> The logic is: when migration started, high level management console will check
> >> destination side to make sure the VM is running there 
> >> (currently call xl list -l <domain>).
> >>
> >> If I can get enough runtime info (even some are missing), I think it should be OK.
> >>
> > 
> > What runtime info do you need?
> 
> Currently we need:
> 
>   info['domid']
>   info['config']['b_info']['avail_vcpus']
>   info['config']['c_info']['uuid']
>   info['config']['b_info']['target_memkb']
> 
> Also read vnc port from xenstore.  
> 

Unfortunately this won't work, as not everything you need is in xenstore
at that point (see the xenstore entries you posted). It's not something
that can be easily worked around in xl by creating a stub -- even the
stub needs to get its information from somewhere.

> We may add more.
> 

This also means even if we create a stub now, it's still prone to
breakage in the future.

I think the root cause of your problem is xend and libxl fires
@introduceDomain at different point (correct me if I'm wrong, because I
haven't looked at xend code, only inferred from your reply). It should
be fixed there, not patching xl.

Wei.

> But during migration, I believe it's OK if some info is missing. Our high level
> management stack will handle it.
> 
> Thanks,
> 
> Zhigang
> 
> > As I understand it's something in the long output -- otherwise you would
> > have used the short output already if you only need to check the
> > existence and / or state of a domain.
> > 
> >>> And, from your earlier reply, you're implying Xend fires
> >>> @introduceDomain at the same point as xl, but your tool can work with
> >>> it?
> >>
> >> For xm/xend, VM xenstore entries already populated before @introduceDomain.
> >> "xm list -l" will show the right information.
> >>
> >> Anyone knows what prevents us from populating VM xenstore entries during migration in libxl?
> >>
> > 
> > FWIW in libxl @introduceDomain is fired after domain is built, before
> > adding devices. If you're after device information, it's a bit late.
> > 
> > Xend might have done it in different order. I don't know.
> > 
> > Whether we can change libxl to do so, I'm not sure. But it's definitely
> > not 4.5 material.
> > 
> > Wei.
> > 
> >> Thanks,
> >>
> >> Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:40:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11: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 1XoWHR-0006f7-6E; Wed, 12 Nov 2014 11:40:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWHQ-0006f2-DN
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:40:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	82/B5-09842-71743645; Wed, 12 Nov 2014 11:40:07 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415792406!12097064!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6085 invoked from network); 12 Nov 2014 11:40:07 -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;
	12 Nov 2014 11:40:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920751"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:40:05 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWHN-0003FQ-Bv;
	Wed, 12 Nov 2014 11:40:05 +0000
Date: Wed, 12 Nov 2014 11:39:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 0/13] introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series introduces support for GNTTABOP_cache_flush to perform
cache maintenance operation on foreign pages and reverts the current
code based on XENFEAT_grant_map_identity.

It also provides a very slow fallback by bouncing on the swiotlb buffer,
in case the hypercall is not available.

v7 introduces a flag named dma_coherent in dev_archdata and an accessor
function named is_device_dma_coherent in asm/dma-mapping.h under arm and
arm64.


Changes in v9:
- remove BUG_ON from the loop in dma_cache_maint;
- add static inline for xen_dma_unmap_page, xen_dma_sync_single_for_cpu,
  xen_dma_sync_single_for_device;
- map_page is always present, don't check whether it's implemented;
- use bool local for clarity;
- add an in-code comment.

Changes in v8:
- remove code duplication in mm32.c by moving the pfn_valid check in
page-coherent.h;
- add a dma_addr_t dev_addr argument to xen_dma_map_page;
- use hypercall to flush caches in map_page;
- pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu;
- remove BUG_ON in xen_bus_to_phys.

Changes in v7:
- rebased on 3.18-rc1;
- rename is_dma_coherent to is_device_dma_coherent and move it to
asm/dma-mapping.h on arm and arm64;
- introduce a dma_coherent flag on arm and arm64;
- set the flags from set_arch_dma_coherent_ops.

Changes in v6:
- rename xen_is_dma_coherent to is_dma_coherent;
- use of_dma_is_coherent to detect the dma coherency of a device;
- remove arch/arm64/include/asm/xen/page-coherent.h, include
../../arm/include/asm/xen/page-coherent.h instead;
- fix indentation.

Changes in v5:
- introduce xen_is_dma_coherent as a xen specific function;
- call xen_is_dma_coherent instead of is_dma_coherent;
- introduce xen_is_dma_coherent to
arch/arm64/include/asm/xen/page-coherent.h;
- do not remove arch/arm64/include/asm/xen/page-coherent.h, add
the missing dma_ops calls from it;
- fix indentation;
- rename hypercall_flush to hypercall_cflush;
- remove spurious change.

Changes in v4:
- remove outer_*_range call;
- introduce is_dma_coherent;
- use is_dma_coherent in arch/arm/xen/mm32.c;
- merge xen/mm32.c into xen/mm.c;
- xen/arm/arm64: introduce xen_arch_need_swiotlb;
- avoid bouncing dma map operations that involve foreign grants and
non-coherent devices if GNTTABOP_cache_flush is provided by Xen.

Changes in v3:
- fix the cache maintenance op call to match what Linux does natively;
- update the hypercall interface to match Xen.

Changes in v2:
- remove the definition of XENFEAT_grant_map_identity;
- update the hypercall interface to match Xen;
- call the interface on a single page at a time.



git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git cache_flush_v9

Stefano Stabellini (13):
      xen/arm: remove handling of XENFEAT_grant_map_identity
      xen/arm: remove outer_*_range call
      xen/arm: if(pfn_valid(pfn)) call native dma_ops
      arm64: introduce is_device_dma_coherent
      arm: introduce is_device_dma_coherent
      xen/arm: use is_device_dma_coherent
      xen: add a dma_addr_t dev_addr argument to xen_dma_map_page
      xen/arm: use hypercall to flush caches in map_page
      xen/arm/arm64: merge xen/mm32.c into xen/mm.c
      xen/arm/arm64: introduce xen_arch_need_swiotlb
      xen/arm: introduce GNTTABOP_cache_flush
      swiotlb-xen: pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu
      swiotlb-xen: remove BUG_ON in xen_bus_to_phys

 arch/arm/include/asm/device.h              |    1 +
 arch/arm/include/asm/dma-mapping.h         |    6 +
 arch/arm/include/asm/xen/page-coherent.h   |   66 +++++++--
 arch/arm/include/asm/xen/page.h            |    4 +
 arch/arm/xen/Makefile                      |    2 +-
 arch/arm/xen/enlighten.c                   |    5 -
 arch/arm/xen/mm.c                          |  121 +++++++++++++++++
 arch/arm/xen/mm32.c                        |  202 ----------------------------
 arch/arm64/include/asm/device.h            |    1 +
 arch/arm64/include/asm/dma-mapping.h       |    6 +
 arch/arm64/include/asm/xen/page-coherent.h |   44 +-----
 arch/x86/include/asm/xen/page-coherent.h   |    4 +-
 arch/x86/include/asm/xen/page.h            |    7 +
 drivers/xen/swiotlb-xen.c                  |   19 +--
 include/xen/interface/features.h           |    3 -
 include/xen/interface/grant_table.h        |   19 +++
 16 files changed, 237 insertions(+), 273 deletions(-)
 delete mode 100644 arch/arm/xen/mm32.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:40:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11: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 1XoWHR-0006f7-6E; Wed, 12 Nov 2014 11:40:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWHQ-0006f2-DN
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:40:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	82/B5-09842-71743645; Wed, 12 Nov 2014 11:40:07 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415792406!12097064!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6085 invoked from network); 12 Nov 2014 11:40:07 -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;
	12 Nov 2014 11:40:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920751"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:40:05 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWHN-0003FQ-Bv;
	Wed, 12 Nov 2014 11:40:05 +0000
Date: Wed, 12 Nov 2014 11:39:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 0/13] introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series introduces support for GNTTABOP_cache_flush to perform
cache maintenance operation on foreign pages and reverts the current
code based on XENFEAT_grant_map_identity.

It also provides a very slow fallback by bouncing on the swiotlb buffer,
in case the hypercall is not available.

v7 introduces a flag named dma_coherent in dev_archdata and an accessor
function named is_device_dma_coherent in asm/dma-mapping.h under arm and
arm64.


Changes in v9:
- remove BUG_ON from the loop in dma_cache_maint;
- add static inline for xen_dma_unmap_page, xen_dma_sync_single_for_cpu,
  xen_dma_sync_single_for_device;
- map_page is always present, don't check whether it's implemented;
- use bool local for clarity;
- add an in-code comment.

Changes in v8:
- remove code duplication in mm32.c by moving the pfn_valid check in
page-coherent.h;
- add a dma_addr_t dev_addr argument to xen_dma_map_page;
- use hypercall to flush caches in map_page;
- pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu;
- remove BUG_ON in xen_bus_to_phys.

Changes in v7:
- rebased on 3.18-rc1;
- rename is_dma_coherent to is_device_dma_coherent and move it to
asm/dma-mapping.h on arm and arm64;
- introduce a dma_coherent flag on arm and arm64;
- set the flags from set_arch_dma_coherent_ops.

Changes in v6:
- rename xen_is_dma_coherent to is_dma_coherent;
- use of_dma_is_coherent to detect the dma coherency of a device;
- remove arch/arm64/include/asm/xen/page-coherent.h, include
../../arm/include/asm/xen/page-coherent.h instead;
- fix indentation.

Changes in v5:
- introduce xen_is_dma_coherent as a xen specific function;
- call xen_is_dma_coherent instead of is_dma_coherent;
- introduce xen_is_dma_coherent to
arch/arm64/include/asm/xen/page-coherent.h;
- do not remove arch/arm64/include/asm/xen/page-coherent.h, add
the missing dma_ops calls from it;
- fix indentation;
- rename hypercall_flush to hypercall_cflush;
- remove spurious change.

Changes in v4:
- remove outer_*_range call;
- introduce is_dma_coherent;
- use is_dma_coherent in arch/arm/xen/mm32.c;
- merge xen/mm32.c into xen/mm.c;
- xen/arm/arm64: introduce xen_arch_need_swiotlb;
- avoid bouncing dma map operations that involve foreign grants and
non-coherent devices if GNTTABOP_cache_flush is provided by Xen.

Changes in v3:
- fix the cache maintenance op call to match what Linux does natively;
- update the hypercall interface to match Xen.

Changes in v2:
- remove the definition of XENFEAT_grant_map_identity;
- update the hypercall interface to match Xen;
- call the interface on a single page at a time.



git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git cache_flush_v9

Stefano Stabellini (13):
      xen/arm: remove handling of XENFEAT_grant_map_identity
      xen/arm: remove outer_*_range call
      xen/arm: if(pfn_valid(pfn)) call native dma_ops
      arm64: introduce is_device_dma_coherent
      arm: introduce is_device_dma_coherent
      xen/arm: use is_device_dma_coherent
      xen: add a dma_addr_t dev_addr argument to xen_dma_map_page
      xen/arm: use hypercall to flush caches in map_page
      xen/arm/arm64: merge xen/mm32.c into xen/mm.c
      xen/arm/arm64: introduce xen_arch_need_swiotlb
      xen/arm: introduce GNTTABOP_cache_flush
      swiotlb-xen: pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu
      swiotlb-xen: remove BUG_ON in xen_bus_to_phys

 arch/arm/include/asm/device.h              |    1 +
 arch/arm/include/asm/dma-mapping.h         |    6 +
 arch/arm/include/asm/xen/page-coherent.h   |   66 +++++++--
 arch/arm/include/asm/xen/page.h            |    4 +
 arch/arm/xen/Makefile                      |    2 +-
 arch/arm/xen/enlighten.c                   |    5 -
 arch/arm/xen/mm.c                          |  121 +++++++++++++++++
 arch/arm/xen/mm32.c                        |  202 ----------------------------
 arch/arm64/include/asm/device.h            |    1 +
 arch/arm64/include/asm/dma-mapping.h       |    6 +
 arch/arm64/include/asm/xen/page-coherent.h |   44 +-----
 arch/x86/include/asm/xen/page-coherent.h   |    4 +-
 arch/x86/include/asm/xen/page.h            |    7 +
 drivers/xen/swiotlb-xen.c                  |   19 +--
 include/xen/interface/features.h           |    3 -
 include/xen/interface/grant_table.h        |   19 +++
 16 files changed, 237 insertions(+), 273 deletions(-)
 delete mode 100644 arch/arm/xen/mm32.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIY-0006l3-RT; Wed, 12 Nov 2014 11:41: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@citrix.com>) id 1XoWIX-0006ku-SE
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:17 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	5C/58-27584-D5743645; Wed, 12 Nov 2014 11:41:17 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792475!10883655!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4307 invoked from network); 12 Nov 2014 11:41:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920925"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-U1;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:45 +0000
Message-ID: <1415792454-23161-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 04/13] arm64: introduce is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a boolean flag and an accessor function to check whether a
device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm64/include/asm/device.h      |    1 +
 arch/arm64/include/asm/dma-mapping.h |    6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index cf98b36..243ef25 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -21,6 +21,7 @@ struct dev_archdata {
 #ifdef CONFIG_IOMMU_API
 	void *iommu;			/* private IOMMU data */
 #endif
+	bool dma_coherent;
 };
 
 struct pdev_archdata {
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index adeae3f..e213dc4 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -54,11 +54,17 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
 
 static inline int set_arch_dma_coherent_ops(struct device *dev)
 {
+	dev->archdata.dma_coherent = true;
 	set_dma_ops(dev, &coherent_swiotlb_dma_ops);
 	return 0;
 }
 #define set_arch_dma_coherent_ops	set_arch_dma_coherent_ops
 
+static inline bool is_device_dma_coherent(struct device *dev)
+{
+	return dev->archdata.dma_coherent;
+}
+
 #include <asm-generic/dma-mapping-common.h>
 
 static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIY-0006l3-RT; Wed, 12 Nov 2014 11:41: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@citrix.com>) id 1XoWIX-0006ku-SE
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:17 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	5C/58-27584-D5743645; Wed, 12 Nov 2014 11:41:17 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792475!10883655!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4307 invoked from network); 12 Nov 2014 11:41:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920925"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-U1;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:45 +0000
Message-ID: <1415792454-23161-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 04/13] arm64: introduce is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a boolean flag and an accessor function to check whether a
device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm64/include/asm/device.h      |    1 +
 arch/arm64/include/asm/dma-mapping.h |    6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index cf98b36..243ef25 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -21,6 +21,7 @@ struct dev_archdata {
 #ifdef CONFIG_IOMMU_API
 	void *iommu;			/* private IOMMU data */
 #endif
+	bool dma_coherent;
 };
 
 struct pdev_archdata {
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index adeae3f..e213dc4 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -54,11 +54,17 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
 
 static inline int set_arch_dma_coherent_ops(struct device *dev)
 {
+	dev->archdata.dma_coherent = true;
 	set_dma_ops(dev, &coherent_swiotlb_dma_ops);
 	return 0;
 }
 #define set_arch_dma_coherent_ops	set_arch_dma_coherent_ops
 
+static inline bool is_device_dma_coherent(struct device *dev)
+{
+	return dev->archdata.dma_coherent;
+}
+
 #include <asm-generic/dma-mapping-common.h>
 
 static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIb-0006lw-7M; Wed, 12 Nov 2014 11:41: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@citrix.com>) id 1XoWIZ-0006l8-IO
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:19 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	5A/BC-22819-E5743645; Wed, 12 Nov 2014 11:41:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792475!10883655!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4541 invoked from network); 12 Nov 2014 11:41:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920926"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-Sq;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:43 +0000
Message-ID: <1415792454-23161-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 02/13] xen/arm: remove outer_*_range call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0 is not actually capable of issuing outer_inv_range or
outer_clean_range calls.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/xen/mm32.c |    9 ---------
 1 file changed, 9 deletions(-)

diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index a5a93fc..6153d61 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -61,9 +61,6 @@ static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
 	/* Cannot use __dma_page_dev_to_cpu because we don't have a
 	 * struct page for handle */
 
-	if (dir != DMA_TO_DEVICE)
-		outer_inv_range(handle, handle + size);
-
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_unmap_area);
 }
 
@@ -72,12 +69,6 @@ static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 {
 
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_map_area);
-
-	if (dir == DMA_FROM_DEVICE) {
-		outer_inv_range(handle, handle + size);
-	} else {
-		outer_clean_range(handle, handle + size);
-	}
 }
 
 void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIb-0006lw-7M; Wed, 12 Nov 2014 11:41: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@citrix.com>) id 1XoWIZ-0006l8-IO
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:19 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	5A/BC-22819-E5743645; Wed, 12 Nov 2014 11:41:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792475!10883655!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4541 invoked from network); 12 Nov 2014 11:41:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920926"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-Sq;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:43 +0000
Message-ID: <1415792454-23161-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 02/13] xen/arm: remove outer_*_range call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0 is not actually capable of issuing outer_inv_range or
outer_clean_range calls.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/xen/mm32.c |    9 ---------
 1 file changed, 9 deletions(-)

diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index a5a93fc..6153d61 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -61,9 +61,6 @@ static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
 	/* Cannot use __dma_page_dev_to_cpu because we don't have a
 	 * struct page for handle */
 
-	if (dir != DMA_TO_DEVICE)
-		outer_inv_range(handle, handle + size);
-
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_unmap_area);
 }
 
@@ -72,12 +69,6 @@ static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 {
 
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_map_area);
-
-	if (dir == DMA_FROM_DEVICE) {
-		outer_inv_range(handle, handle + size);
-	} else {
-		outer_clean_range(handle, handle + size);
-	}
 }
 
 void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIb-0006mS-Lo; Wed, 12 Nov 2014 11:41: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@citrix.com>) id 1XoWIZ-0006l9-JE
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:19 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	46/CA-17694-E5743645; Wed, 12 Nov 2014 11:41:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415792477!10881519!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7495 invoked from network); 12 Nov 2014 11:41:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920927"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-Uc;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:46 +0000
Message-ID: <1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: linux@arm.linux.org.uk, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 05/13] arm: introduce is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a boolean flag and an accessor function to check whether a
device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
CC: linux@arm.linux.org.uk
---
 arch/arm/include/asm/device.h      |    1 +
 arch/arm/include/asm/dma-mapping.h |    6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index dc662fc..4111592 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -17,6 +17,7 @@ struct dev_archdata {
 #ifdef CONFIG_ARM_DMA_USE_IOMMU
 	struct dma_iommu_mapping	*mapping;
 #endif
+	bool dma_coherent;
 };
 
 struct omap_device;
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 85738b2..8c3b616 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -123,11 +123,17 @@ static inline unsigned long dma_max_pfn(struct device *dev)
 
 static inline int set_arch_dma_coherent_ops(struct device *dev)
 {
+	dev->archdata.dma_coherent = true;
 	set_dma_ops(dev, &arm_coherent_dma_ops);
 	return 0;
 }
 #define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
 
+static inline bool is_device_dma_coherent(struct device *dev)
+{
+	return dev->archdata.dma_coherent;
+}
+
 static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
 	unsigned int offset = paddr & ~PAGE_MASK;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIb-0006mS-Lo; Wed, 12 Nov 2014 11:41: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@citrix.com>) id 1XoWIZ-0006l9-JE
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:19 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	46/CA-17694-E5743645; Wed, 12 Nov 2014 11:41:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415792477!10881519!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7495 invoked from network); 12 Nov 2014 11:41:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920927"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-Uc;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:46 +0000
Message-ID: <1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: linux@arm.linux.org.uk, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 05/13] arm: introduce is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a boolean flag and an accessor function to check whether a
device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
CC: linux@arm.linux.org.uk
---
 arch/arm/include/asm/device.h      |    1 +
 arch/arm/include/asm/dma-mapping.h |    6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index dc662fc..4111592 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -17,6 +17,7 @@ struct dev_archdata {
 #ifdef CONFIG_ARM_DMA_USE_IOMMU
 	struct dma_iommu_mapping	*mapping;
 #endif
+	bool dma_coherent;
 };
 
 struct omap_device;
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 85738b2..8c3b616 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -123,11 +123,17 @@ static inline unsigned long dma_max_pfn(struct device *dev)
 
 static inline int set_arch_dma_coherent_ops(struct device *dev)
 {
+	dev->archdata.dma_coherent = true;
 	set_dma_ops(dev, &arm_coherent_dma_ops);
 	return 0;
 }
 #define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
 
+static inline bool is_device_dma_coherent(struct device *dev)
+{
+	return dev->archdata.dma_coherent;
+}
+
 static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
 	unsigned int offset = paddr & ~PAGE_MASK;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIc-0006nI-6P; Wed, 12 Nov 2014 11:41:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIa-0006lS-Cn
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:20 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	F2/EE-02697-F5743645; Wed, 12 Nov 2014 11:41:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792475!10883655!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4859 invoked from network); 12 Nov 2014 11:41:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920929"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-VC;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:47 +0000
Message-ID: <1415792454-23161-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 06/13] xen/arm: use is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use is_device_dma_coherent to check whether we need to issue cache
maintenance operations rather than checking on the existence of a
particular dma_ops function for the device.

This is correct because coherent devices don't need cache maintenance
operations - arm_coherent_dma_ops does not set the hooks that we
were previously checking for existance.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 arch/arm/xen/mm32.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 5bb8391..3ce9dc1 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -48,7 +48,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		struct dma_attrs *attrs)
 
 {
-	if (!__generic_dma_ops(hwdev)->unmap_page)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
 		return;
@@ -59,7 +59,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
-	if (!__generic_dma_ops(hwdev)->sync_single_for_cpu)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
@@ -67,7 +67,7 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 void __xen_dma_sync_single_for_device(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
-	if (!__generic_dma_ops(hwdev)->sync_single_for_device)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIc-0006nI-6P; Wed, 12 Nov 2014 11:41:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIa-0006lS-Cn
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:20 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	F2/EE-02697-F5743645; Wed, 12 Nov 2014 11:41:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792475!10883655!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4859 invoked from network); 12 Nov 2014 11:41:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920929"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-VC;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:47 +0000
Message-ID: <1415792454-23161-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 06/13] xen/arm: use is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use is_device_dma_coherent to check whether we need to issue cache
maintenance operations rather than checking on the existence of a
particular dma_ops function for the device.

This is correct because coherent devices don't need cache maintenance
operations - arm_coherent_dma_ops does not set the hooks that we
were previously checking for existance.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 arch/arm/xen/mm32.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 5bb8391..3ce9dc1 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -48,7 +48,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		struct dma_attrs *attrs)
 
 {
-	if (!__generic_dma_ops(hwdev)->unmap_page)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
 		return;
@@ -59,7 +59,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
-	if (!__generic_dma_ops(hwdev)->sync_single_for_cpu)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
@@ -67,7 +67,7 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 void __xen_dma_sync_single_for_device(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
-	if (!__generic_dma_ops(hwdev)->sync_single_for_device)
+	if (is_device_dma_coherent(hwdev))
 		return;
 	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIc-0006nz-L5; Wed, 12 Nov 2014 11:41: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@citrix.com>) id 1XoWIa-0006lR-DA
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:20 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	71/28-17735-F5743645; Wed, 12 Nov 2014 11:41:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415792477!10881519!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7629 invoked from network); 12 Nov 2014 11:41:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920928"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-SG;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:42 +0000
Message-ID: <1415792454-23161-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 01/13] xen/arm: remove handling of
	XENFEAT_grant_map_identity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 feature has been removed from Xen. Also Linux cannot use it on ARM32
without CONFIG_ARM_LPAE.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

---
Changes in v2:

- remove the definition of XENFEAT_grant_map_identity.
---
 arch/arm/xen/enlighten.c         |    5 ---
 arch/arm/xen/mm32.c              |   85 +-------------------------------------
 include/xen/interface/features.h |    3 --
 3 files changed, 1 insertion(+), 92 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e15f01..c7ca936 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,11 +261,6 @@ static int __init xen_guest_init(void)
 
 	xen_setup_features();
 
-	if (!xen_feature(XENFEAT_grant_map_identity)) {
-		pr_warn("Please upgrade your Xen.\n"
-				"If your platform has any non-coherent DMA devices, they won't work properly.\n");
-	}
-
 	if (xen_feature(XENFEAT_dom0))
 		xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
 	else
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 3b99860..a5a93fc 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -5,70 +5,6 @@
 
 #include <xen/features.h>
 
-static DEFINE_PER_CPU(unsigned long, xen_mm32_scratch_virt);
-static DEFINE_PER_CPU(pte_t *, xen_mm32_scratch_ptep);
-
-static int alloc_xen_mm32_scratch_page(int cpu)
-{
-	struct page *page;
-	unsigned long virt;
-	pmd_t *pmdp;
-	pte_t *ptep;
-
-	if (per_cpu(xen_mm32_scratch_ptep, cpu) != NULL)
-		return 0;
-
-	page = alloc_page(GFP_KERNEL);
-	if (page == NULL) {
-		pr_warn("Failed to allocate xen_mm32_scratch_page for cpu %d\n", cpu);
-		return -ENOMEM;
-	}
-
-	virt = (unsigned long)__va(page_to_phys(page));
-	pmdp = pmd_offset(pud_offset(pgd_offset_k(virt), virt), virt);
-	ptep = pte_offset_kernel(pmdp, virt);
-
-	per_cpu(xen_mm32_scratch_virt, cpu) = virt;
-	per_cpu(xen_mm32_scratch_ptep, cpu) = ptep;
-
-	return 0;
-}
-
-static int xen_mm32_cpu_notify(struct notifier_block *self,
-				    unsigned long action, void *hcpu)
-{
-	int cpu = (long)hcpu;
-	switch (action) {
-	case CPU_UP_PREPARE:
-		if (alloc_xen_mm32_scratch_page(cpu))
-			return NOTIFY_BAD;
-		break;
-	default:
-		break;
-	}
-	return NOTIFY_OK;
-}
-
-static struct notifier_block xen_mm32_cpu_notifier = {
-	.notifier_call	= xen_mm32_cpu_notify,
-};
-
-static void* xen_mm32_remap_page(dma_addr_t handle)
-{
-	unsigned long virt = get_cpu_var(xen_mm32_scratch_virt);
-	pte_t *ptep = __get_cpu_var(xen_mm32_scratch_ptep);
-
-	*ptep = pfn_pte(handle >> PAGE_SHIFT, PAGE_KERNEL);
-	local_flush_tlb_kernel_page(virt);
-
-	return (void*)virt;
-}
-
-static void xen_mm32_unmap(void *vaddr)
-{
-	put_cpu_var(xen_mm32_scratch_virt);
-}
-
 
 /* functions called by SWIOTLB */
 
@@ -88,13 +24,7 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	
 		if (!pfn_valid(pfn))
 		{
-			/* Cannot map the page, we don't know its physical address.
-			 * Return and hope for the best */
-			if (!xen_feature(XENFEAT_grant_map_identity))
-				return;
-			vaddr = xen_mm32_remap_page(handle) + offset;
-			op(vaddr, len, dir);
-			xen_mm32_unmap(vaddr - offset);
+			/* TODO: cache flush */
 		} else {
 			struct page *page = pfn_to_page(pfn);
 
@@ -181,22 +111,9 @@ void xen_dma_sync_single_for_device(struct device *hwdev,
 
 int __init xen_mm32_init(void)
 {
-	int cpu;
-
 	if (!xen_initial_domain())
 		return 0;
 
-	register_cpu_notifier(&xen_mm32_cpu_notifier);
-	get_online_cpus();
-	for_each_online_cpu(cpu) {
-		if (alloc_xen_mm32_scratch_page(cpu)) {
-			put_online_cpus();
-			unregister_cpu_notifier(&xen_mm32_cpu_notifier);
-			return -ENOMEM;
-		}
-	}
-	put_online_cpus();
-
 	return 0;
 }
 arch_initcall(xen_mm32_init);
diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h
index 14334d0..131a6cc 100644
--- a/include/xen/interface/features.h
+++ b/include/xen/interface/features.h
@@ -53,9 +53,6 @@
 /* operation as Dom0 is supported */
 #define XENFEAT_dom0                      11
 
-/* Xen also maps grant references at pfn = mfn */
-#define XENFEAT_grant_map_identity        12
-
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIc-0006nz-L5; Wed, 12 Nov 2014 11:41: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@citrix.com>) id 1XoWIa-0006lR-DA
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:20 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	71/28-17735-F5743645; Wed, 12 Nov 2014 11:41:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415792477!10881519!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7629 invoked from network); 12 Nov 2014 11:41:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920928"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-SG;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:42 +0000
Message-ID: <1415792454-23161-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 01/13] xen/arm: remove handling of
	XENFEAT_grant_map_identity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 feature has been removed from Xen. Also Linux cannot use it on ARM32
without CONFIG_ARM_LPAE.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

---
Changes in v2:

- remove the definition of XENFEAT_grant_map_identity.
---
 arch/arm/xen/enlighten.c         |    5 ---
 arch/arm/xen/mm32.c              |   85 +-------------------------------------
 include/xen/interface/features.h |    3 --
 3 files changed, 1 insertion(+), 92 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e15f01..c7ca936 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,11 +261,6 @@ static int __init xen_guest_init(void)
 
 	xen_setup_features();
 
-	if (!xen_feature(XENFEAT_grant_map_identity)) {
-		pr_warn("Please upgrade your Xen.\n"
-				"If your platform has any non-coherent DMA devices, they won't work properly.\n");
-	}
-
 	if (xen_feature(XENFEAT_dom0))
 		xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
 	else
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 3b99860..a5a93fc 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -5,70 +5,6 @@
 
 #include <xen/features.h>
 
-static DEFINE_PER_CPU(unsigned long, xen_mm32_scratch_virt);
-static DEFINE_PER_CPU(pte_t *, xen_mm32_scratch_ptep);
-
-static int alloc_xen_mm32_scratch_page(int cpu)
-{
-	struct page *page;
-	unsigned long virt;
-	pmd_t *pmdp;
-	pte_t *ptep;
-
-	if (per_cpu(xen_mm32_scratch_ptep, cpu) != NULL)
-		return 0;
-
-	page = alloc_page(GFP_KERNEL);
-	if (page == NULL) {
-		pr_warn("Failed to allocate xen_mm32_scratch_page for cpu %d\n", cpu);
-		return -ENOMEM;
-	}
-
-	virt = (unsigned long)__va(page_to_phys(page));
-	pmdp = pmd_offset(pud_offset(pgd_offset_k(virt), virt), virt);
-	ptep = pte_offset_kernel(pmdp, virt);
-
-	per_cpu(xen_mm32_scratch_virt, cpu) = virt;
-	per_cpu(xen_mm32_scratch_ptep, cpu) = ptep;
-
-	return 0;
-}
-
-static int xen_mm32_cpu_notify(struct notifier_block *self,
-				    unsigned long action, void *hcpu)
-{
-	int cpu = (long)hcpu;
-	switch (action) {
-	case CPU_UP_PREPARE:
-		if (alloc_xen_mm32_scratch_page(cpu))
-			return NOTIFY_BAD;
-		break;
-	default:
-		break;
-	}
-	return NOTIFY_OK;
-}
-
-static struct notifier_block xen_mm32_cpu_notifier = {
-	.notifier_call	= xen_mm32_cpu_notify,
-};
-
-static void* xen_mm32_remap_page(dma_addr_t handle)
-{
-	unsigned long virt = get_cpu_var(xen_mm32_scratch_virt);
-	pte_t *ptep = __get_cpu_var(xen_mm32_scratch_ptep);
-
-	*ptep = pfn_pte(handle >> PAGE_SHIFT, PAGE_KERNEL);
-	local_flush_tlb_kernel_page(virt);
-
-	return (void*)virt;
-}
-
-static void xen_mm32_unmap(void *vaddr)
-{
-	put_cpu_var(xen_mm32_scratch_virt);
-}
-
 
 /* functions called by SWIOTLB */
 
@@ -88,13 +24,7 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	
 		if (!pfn_valid(pfn))
 		{
-			/* Cannot map the page, we don't know its physical address.
-			 * Return and hope for the best */
-			if (!xen_feature(XENFEAT_grant_map_identity))
-				return;
-			vaddr = xen_mm32_remap_page(handle) + offset;
-			op(vaddr, len, dir);
-			xen_mm32_unmap(vaddr - offset);
+			/* TODO: cache flush */
 		} else {
 			struct page *page = pfn_to_page(pfn);
 
@@ -181,22 +111,9 @@ void xen_dma_sync_single_for_device(struct device *hwdev,
 
 int __init xen_mm32_init(void)
 {
-	int cpu;
-
 	if (!xen_initial_domain())
 		return 0;
 
-	register_cpu_notifier(&xen_mm32_cpu_notifier);
-	get_online_cpus();
-	for_each_online_cpu(cpu) {
-		if (alloc_xen_mm32_scratch_page(cpu)) {
-			put_online_cpus();
-			unregister_cpu_notifier(&xen_mm32_cpu_notifier);
-			return -ENOMEM;
-		}
-	}
-	put_online_cpus();
-
 	return 0;
 }
 arch_initcall(xen_mm32_init);
diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h
index 14334d0..131a6cc 100644
--- a/include/xen/interface/features.h
+++ b/include/xen/interface/features.h
@@ -53,9 +53,6 @@
 /* operation as Dom0 is supported */
 #define XENFEAT_dom0                      11
 
-/* Xen also maps grant references at pfn = mfn */
-#define XENFEAT_grant_map_identity        12
-
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWId-0006ox-6g; Wed, 12 Nov 2014 11:41:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIb-0006ls-EP
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:21 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	7C/84-26858-06743645; Wed, 12 Nov 2014 11:41:20 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415792477!10881519!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7789 invoked from network); 12 Nov 2014 11:41:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920930"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-TP;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:44 +0000
Message-ID: <1415792454-23161-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 03/13] xen/arm: if(pfn_valid(pfn)) call
	native dma_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove code duplication in mm32.c by calling the native dma_ops if the
page is a local page (not a foreign page). Use a simple pfn_valid(pfn)
check to figure out if the page is local, exploiting the fact that dom0
is mapped 1:1, therefore pfn_valid always returns false when called on a
foreign mfn.

Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

---

Changes in v9:

- remove BUG_ON from the loop;
- add static inline for xen_dma_unmap_page, xen_dma_sync_single_for_cpu,
  xen_dma_sync_single_for_device.
---
 arch/arm/include/asm/xen/page-coherent.h |   49 +++++++++++++++++++++++++----
 arch/arm/xen/mm32.c                      |   50 +++++++-----------------------
 2 files changed, 54 insertions(+), 45 deletions(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index e8275ea..9cfd895 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -5,6 +5,15 @@
 #include <linux/dma-attrs.h>
 #include <linux/dma-mapping.h>
 
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir,
+		struct dma_attrs *attrs);
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+
+void __xen_dma_sync_single_for_device(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+
 static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
 		dma_addr_t *dma_handle, gfp_t flags,
 		struct dma_attrs *attrs)
@@ -26,14 +35,42 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
 }
 
-void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs);
+		struct dma_attrs *attrs)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	/* Dom0 is mapped 1:1, so calling pfn_valid on a foreign mfn will
+	 * always return false. If the page is local we can safely call the
+	 * native dma_ops function, otherwise we call the xen specific
+	 * function. */
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->unmap_page)
+			__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
+	} else
+		__xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
+}
 
-void xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->sync_single_for_cpu)
+			__generic_dma_ops(hwdev)->sync_single_for_cpu(hwdev, handle, size, dir);
+	} else
+		__xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
+}
 
-void xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+static inline void xen_dma_sync_single_for_device(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->sync_single_for_device)
+			__generic_dma_ops(hwdev)->sync_single_for_device(hwdev, handle, size, dir);
+	} else
+		__xen_dma_sync_single_for_device(hwdev, handle, size, dir);
+}
 
 #endif /* _ASM_ARM_XEN_PAGE_COHERENT_H */
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 6153d61..5bb8391 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -4,13 +4,15 @@
 #include <linux/highmem.h>
 
 #include <xen/features.h>
-
+enum dma_cache_op {
+       DMA_UNMAP,
+       DMA_MAP,
+};
 
 /* functions called by SWIOTLB */
 
 static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
-	size_t size, enum dma_data_direction dir,
-	void (*op)(const void *, size_t, int))
+	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
 {
 	unsigned long pfn;
 	size_t left = size;
@@ -20,34 +22,8 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 
 	do {
 		size_t len = left;
-		void *vaddr;
 	
-		if (!pfn_valid(pfn))
-		{
-			/* TODO: cache flush */
-		} else {
-			struct page *page = pfn_to_page(pfn);
-
-			if (PageHighMem(page)) {
-				if (len + offset > PAGE_SIZE)
-					len = PAGE_SIZE - offset;
-
-				if (cache_is_vipt_nonaliasing()) {
-					vaddr = kmap_atomic(page);
-					op(vaddr + offset, len, dir);
-					kunmap_atomic(vaddr);
-				} else {
-					vaddr = kmap_high_get(page);
-					if (vaddr) {
-						op(vaddr + offset, len, dir);
-						kunmap_high(page);
-					}
-				}
-			} else {
-				vaddr = page_address(page) + offset;
-				op(vaddr, len, dir);
-			}
-		}
+		/* TODO: cache flush */
 
 		offset = 0;
 		pfn++;
@@ -58,20 +34,16 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir)
 {
-	/* Cannot use __dma_page_dev_to_cpu because we don't have a
-	 * struct page for handle */
-
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_unmap_area);
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
 }
 
 static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir)
 {
-
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_map_area);
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
 }
 
-void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs)
 
@@ -84,7 +56,7 @@ void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
 
-void xen_dma_sync_single_for_cpu(struct device *hwdev,
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
 	if (!__generic_dma_ops(hwdev)->sync_single_for_cpu)
@@ -92,7 +64,7 @@ void xen_dma_sync_single_for_cpu(struct device *hwdev,
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
 
-void xen_dma_sync_single_for_device(struct device *hwdev,
+void __xen_dma_sync_single_for_device(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
 	if (!__generic_dma_ops(hwdev)->sync_single_for_device)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWId-0006ox-6g; Wed, 12 Nov 2014 11:41:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIb-0006ls-EP
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:21 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	7C/84-26858-06743645; Wed, 12 Nov 2014 11:41:20 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415792477!10881519!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7789 invoked from network); 12 Nov 2014 11:41:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920930"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-TP;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:44 +0000
Message-ID: <1415792454-23161-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 03/13] xen/arm: if(pfn_valid(pfn)) call
	native dma_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove code duplication in mm32.c by calling the native dma_ops if the
page is a local page (not a foreign page). Use a simple pfn_valid(pfn)
check to figure out if the page is local, exploiting the fact that dom0
is mapped 1:1, therefore pfn_valid always returns false when called on a
foreign mfn.

Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

---

Changes in v9:

- remove BUG_ON from the loop;
- add static inline for xen_dma_unmap_page, xen_dma_sync_single_for_cpu,
  xen_dma_sync_single_for_device.
---
 arch/arm/include/asm/xen/page-coherent.h |   49 +++++++++++++++++++++++++----
 arch/arm/xen/mm32.c                      |   50 +++++++-----------------------
 2 files changed, 54 insertions(+), 45 deletions(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index e8275ea..9cfd895 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -5,6 +5,15 @@
 #include <linux/dma-attrs.h>
 #include <linux/dma-mapping.h>
 
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir,
+		struct dma_attrs *attrs);
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+
+void __xen_dma_sync_single_for_device(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+
 static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
 		dma_addr_t *dma_handle, gfp_t flags,
 		struct dma_attrs *attrs)
@@ -26,14 +35,42 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
 }
 
-void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs);
+		struct dma_attrs *attrs)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	/* Dom0 is mapped 1:1, so calling pfn_valid on a foreign mfn will
+	 * always return false. If the page is local we can safely call the
+	 * native dma_ops function, otherwise we call the xen specific
+	 * function. */
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->unmap_page)
+			__generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
+	} else
+		__xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
+}
 
-void xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->sync_single_for_cpu)
+			__generic_dma_ops(hwdev)->sync_single_for_cpu(hwdev, handle, size, dir);
+	} else
+		__xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
+}
 
-void xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir);
+static inline void xen_dma_sync_single_for_device(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	unsigned long pfn = PFN_DOWN(handle);
+	if (pfn_valid(pfn)) {
+		if (__generic_dma_ops(hwdev)->sync_single_for_device)
+			__generic_dma_ops(hwdev)->sync_single_for_device(hwdev, handle, size, dir);
+	} else
+		__xen_dma_sync_single_for_device(hwdev, handle, size, dir);
+}
 
 #endif /* _ASM_ARM_XEN_PAGE_COHERENT_H */
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 6153d61..5bb8391 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -4,13 +4,15 @@
 #include <linux/highmem.h>
 
 #include <xen/features.h>
-
+enum dma_cache_op {
+       DMA_UNMAP,
+       DMA_MAP,
+};
 
 /* functions called by SWIOTLB */
 
 static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
-	size_t size, enum dma_data_direction dir,
-	void (*op)(const void *, size_t, int))
+	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
 {
 	unsigned long pfn;
 	size_t left = size;
@@ -20,34 +22,8 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 
 	do {
 		size_t len = left;
-		void *vaddr;
 	
-		if (!pfn_valid(pfn))
-		{
-			/* TODO: cache flush */
-		} else {
-			struct page *page = pfn_to_page(pfn);
-
-			if (PageHighMem(page)) {
-				if (len + offset > PAGE_SIZE)
-					len = PAGE_SIZE - offset;
-
-				if (cache_is_vipt_nonaliasing()) {
-					vaddr = kmap_atomic(page);
-					op(vaddr + offset, len, dir);
-					kunmap_atomic(vaddr);
-				} else {
-					vaddr = kmap_high_get(page);
-					if (vaddr) {
-						op(vaddr + offset, len, dir);
-						kunmap_high(page);
-					}
-				}
-			} else {
-				vaddr = page_address(page) + offset;
-				op(vaddr, len, dir);
-			}
-		}
+		/* TODO: cache flush */
 
 		offset = 0;
 		pfn++;
@@ -58,20 +34,16 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir)
 {
-	/* Cannot use __dma_page_dev_to_cpu because we don't have a
-	 * struct page for handle */
-
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_unmap_area);
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
 }
 
 static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir)
 {
-
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, dmac_map_area);
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
 }
 
-void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs)
 
@@ -84,7 +56,7 @@ void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
 
-void xen_dma_sync_single_for_cpu(struct device *hwdev,
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
 	if (!__generic_dma_ops(hwdev)->sync_single_for_cpu)
@@ -92,7 +64,7 @@ void xen_dma_sync_single_for_cpu(struct device *hwdev,
 	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
 
-void xen_dma_sync_single_for_device(struct device *hwdev,
+void __xen_dma_sync_single_for_device(struct device *hwdev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
 	if (!__generic_dma_ops(hwdev)->sync_single_for_device)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIe-0006r0-SW; Wed, 12 Nov 2014 11:41:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIc-0006n2-G6
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:22 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	3A/0C-29352-16743645; Wed, 12 Nov 2014 11:41:21 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792475!10883655!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5003 invoked from network); 12 Nov 2014 11:41:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920931"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-Vl;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:48 +0000
Message-ID: <1415792454-23161-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 07/13] xen: add a dma_addr_t dev_addr
	argument to xen_dma_map_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

dev_addr is the machine address of the page.

The new parameter can be used by the ARM and ARM64 implementations of
xen_dma_map_page to find out if the page is a local page (pfn == mfn) or
a foreign page (pfn != mfn).

dev_addr could be retrieved again from the physical address, using
pfn_to_mfn, but it requires accessing an rbtree. Since we already have
the dev_addr in our hands at the call site there is no need to get the
mfn twice.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/include/asm/xen/page-coherent.h   |    4 ++--
 arch/arm64/include/asm/xen/page-coherent.h |    4 ++--
 arch/x86/include/asm/xen/page-coherent.h   |    4 ++--
 drivers/xen/swiotlb-xen.c                  |    6 ++++--
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index 9cfd895..a309f42 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -29,8 +29,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs)
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
 	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
 }
diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
index dde3fc9..d7cd4c2 100644
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ b/arch/arm64/include/asm/xen/page-coherent.h
@@ -20,8 +20,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs)
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
 }
 
diff --git a/arch/x86/include/asm/xen/page-coherent.h b/arch/x86/include/asm/xen/page-coherent.h
index 7f02fe4..acd844c 100644
--- a/arch/x86/include/asm/xen/page-coherent.h
+++ b/arch/x86/include/asm/xen/page-coherent.h
@@ -22,8 +22,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs) { }
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs) { }
 
 static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..ad2c5eb 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -403,7 +403,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 		/* we are not interested in the dma_addr returned by
 		 * xen_dma_map_page, only in the potential cache flushes executed
 		 * by the function. */
-		xen_dma_map_page(dev, page, offset, size, dir, attrs);
+		xen_dma_map_page(dev, page, dev_addr, offset, size, dir, attrs);
 		return dev_addr;
 	}
 
@@ -417,7 +417,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 		return DMA_ERROR_CODE;
 
 	xen_dma_map_page(dev, pfn_to_page(map >> PAGE_SHIFT),
-					map & ~PAGE_MASK, size, dir, attrs);
+					dev_addr, map & ~PAGE_MASK, size, dir, attrs);
 	dev_addr = xen_phys_to_bus(map);
 
 	/*
@@ -574,6 +574,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 				return 0;
 			}
 			xen_dma_map_page(hwdev, pfn_to_page(map >> PAGE_SHIFT),
+						dev_addr,
 						map & ~PAGE_MASK,
 						sg->length,
 						dir,
@@ -584,6 +585,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 			 * xen_dma_map_page, only in the potential cache flushes executed
 			 * by the function. */
 			xen_dma_map_page(hwdev, pfn_to_page(paddr >> PAGE_SHIFT),
+						dev_addr,
 						paddr & ~PAGE_MASK,
 						sg->length,
 						dir,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIe-0006r0-SW; Wed, 12 Nov 2014 11:41:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIc-0006n2-G6
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:22 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	3A/0C-29352-16743645; Wed, 12 Nov 2014 11:41:21 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792475!10883655!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5003 invoked from network); 12 Nov 2014 11:41:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:41:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191920931"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIO-0003Gl-Vl;
	Wed, 12 Nov 2014 11:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:48 +0000
Message-ID: <1415792454-23161-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 07/13] xen: add a dma_addr_t dev_addr
	argument to xen_dma_map_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

dev_addr is the machine address of the page.

The new parameter can be used by the ARM and ARM64 implementations of
xen_dma_map_page to find out if the page is a local page (pfn == mfn) or
a foreign page (pfn != mfn).

dev_addr could be retrieved again from the physical address, using
pfn_to_mfn, but it requires accessing an rbtree. Since we already have
the dev_addr in our hands at the call site there is no need to get the
mfn twice.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/include/asm/xen/page-coherent.h   |    4 ++--
 arch/arm64/include/asm/xen/page-coherent.h |    4 ++--
 arch/x86/include/asm/xen/page-coherent.h   |    4 ++--
 drivers/xen/swiotlb-xen.c                  |    6 ++++--
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index 9cfd895..a309f42 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -29,8 +29,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs)
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
 	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
 }
diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
index dde3fc9..d7cd4c2 100644
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ b/arch/arm64/include/asm/xen/page-coherent.h
@@ -20,8 +20,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs)
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
 }
 
diff --git a/arch/x86/include/asm/xen/page-coherent.h b/arch/x86/include/asm/xen/page-coherent.h
index 7f02fe4..acd844c 100644
--- a/arch/x86/include/asm/xen/page-coherent.h
+++ b/arch/x86/include/asm/xen/page-coherent.h
@@ -22,8 +22,8 @@ static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs) { }
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs) { }
 
 static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..ad2c5eb 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -403,7 +403,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 		/* we are not interested in the dma_addr returned by
 		 * xen_dma_map_page, only in the potential cache flushes executed
 		 * by the function. */
-		xen_dma_map_page(dev, page, offset, size, dir, attrs);
+		xen_dma_map_page(dev, page, dev_addr, offset, size, dir, attrs);
 		return dev_addr;
 	}
 
@@ -417,7 +417,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 		return DMA_ERROR_CODE;
 
 	xen_dma_map_page(dev, pfn_to_page(map >> PAGE_SHIFT),
-					map & ~PAGE_MASK, size, dir, attrs);
+					dev_addr, map & ~PAGE_MASK, size, dir, attrs);
 	dev_addr = xen_phys_to_bus(map);
 
 	/*
@@ -574,6 +574,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 				return 0;
 			}
 			xen_dma_map_page(hwdev, pfn_to_page(map >> PAGE_SHIFT),
+						dev_addr,
 						map & ~PAGE_MASK,
 						sg->length,
 						dir,
@@ -584,6 +585,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 			 * xen_dma_map_page, only in the potential cache flushes executed
 			 * by the function. */
 			xen_dma_map_page(hwdev, pfn_to_page(paddr >> PAGE_SHIFT),
+						dev_addr,
 						paddr & ~PAGE_MASK,
 						sg->length,
 						dir,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1XoWIp-0006zn-Ar; Wed, 12 Nov 2014 11:41:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIo-0006yf-5V
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:34 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	CC/6E-02702-D6743645; Wed, 12 Nov 2014 11:41:33 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415792491!11999399!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22834 invoked from network); 12 Nov 2014 11:41:32 -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;
	12 Nov 2014 11:41:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190474975"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-05;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:49 +0000
Message-ID: <1415792454-23161-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 08/13] xen/arm: use hypercall to flush caches
	in map_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

In xen_dma_map_page, if the page is a local page, call the native
map_page dma_ops. If the page is foreign, call __xen_dma_map_page that
issues any required cache maintenane operations via hypercall.

The reason for doing this is that the native dma_ops map_page could
allocate buffers than need to be freed. If the page is foreign we don't
call the native unmap_page dma_ops function, resulting in a memory leak.

Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

---

Changes in v9:
- map_page is always present;
- use bool local for clarity;
- add a comment.
---
 arch/arm/include/asm/xen/page-coherent.h |   13 ++++++++++++-
 arch/arm/xen/mm32.c                      |   12 ++++++++++++
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index a309f42..efd5624 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -5,6 +5,9 @@
 #include <linux/dma-attrs.h>
 #include <linux/dma-mapping.h>
 
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs);
 void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs);
@@ -32,7 +35,15 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 	     dma_addr_t dev_addr, unsigned long offset, size_t size,
 	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
-	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
+	bool local = PFN_DOWN(dev_addr) == page_to_pfn(page);
+	/* Dom0 is mapped 1:1, so if pfn == mfn the page is local otherwise
+	 * is a foreign page grant-mapped in dom0. If the page is local we
+	 * can safely call the native dma_ops function, otherwise we call
+	 * the xen specific function. */
+	if (local)
+		__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
+	else
+		__xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
 }
 
 static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 3ce9dc1..c86919b 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -43,6 +43,18 @@ static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
 }
 
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
+}
+
 void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1XoWIp-000706-N5; Wed, 12 Nov 2014 11:41:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIo-0006z1-LX
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:34 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	36/4F-02576-E6743645; Wed, 12 Nov 2014 11:41:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415792491!11999399!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22940 invoked from network); 12 Nov 2014 11:41:33 -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;
	12 Nov 2014 11:41:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190474976"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-3s;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:51 +0000
Message-ID: <1415792454-23161-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 10/13] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 function to find out whether a particular dma
mapping operation needs to bounce on the swiotlb buffer.

On ARM and ARM64, if the page involved is a foreign page and the device
is not coherent, we need to bounce because at unmap time we cannot
execute any required cache maintenance operations (we don't know how to
find the pfn from the mfn).

No change of behaviour for x86.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

Changes in v6:
- fix ts.

Changes in v5:
- fix indentation.
---
 arch/arm/include/asm/xen/page.h |    4 ++++
 arch/arm/xen/mm.c               |    7 +++++++
 arch/x86/include/asm/xen/page.h |    7 +++++++
 drivers/xen/swiotlb-xen.c       |    5 ++++-
 4 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 135c24a..68c739b 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
 #define xen_unmap(cookie) iounmap((cookie))
 
+bool xen_arch_need_swiotlb(struct device *dev,
+			   unsigned long pfn,
+			   unsigned long mfn);
+
 #endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index ab700e1..28ebf3e 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -100,6 +100,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
 	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
 }
 
+bool xen_arch_need_swiotlb(struct device *dev,
+			   unsigned long pfn,
+			   unsigned long mfn)
+{
+	return ((pfn != mfn) && !is_device_dma_coherent(dev));
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 				 unsigned int address_bits,
 				 dma_addr_t *dma_handle)
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c949923..f58ef6c 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
 #define xen_remap(cookie, size) ioremap((cookie), (size));
 #define xen_unmap(cookie) iounmap((cookie))
 
+static inline bool xen_arch_need_swiotlb(struct device *dev,
+					 unsigned long pfn,
+					 unsigned long mfn)
+{
+	return false;
+}
+
 #endif /* _ASM_X86_XEN_PAGE_H */
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ad2c5eb..3725ee4 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 	 * buffering it.
 	 */
 	if (dma_capable(dev, dev_addr, size) &&
-	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
+	    !range_straddles_page_boundary(phys, size) &&
+		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
+		!swiotlb_force) {
 		/* we are not interested in the dma_addr returned by
 		 * xen_dma_map_page, only in the potential cache flushes executed
 		 * by the function. */
@@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
 
 		if (swiotlb_force ||
+		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
 		    !dma_capable(hwdev, dev_addr, sg->length) ||
 		    range_straddles_page_boundary(paddr, sg->length)) {
 			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1XoWIp-0006zn-Ar; Wed, 12 Nov 2014 11:41:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIo-0006yf-5V
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:34 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	CC/6E-02702-D6743645; Wed, 12 Nov 2014 11:41:33 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415792491!11999399!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22834 invoked from network); 12 Nov 2014 11:41:32 -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;
	12 Nov 2014 11:41:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190474975"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-05;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:49 +0000
Message-ID: <1415792454-23161-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 08/13] xen/arm: use hypercall to flush caches
	in map_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

In xen_dma_map_page, if the page is a local page, call the native
map_page dma_ops. If the page is foreign, call __xen_dma_map_page that
issues any required cache maintenane operations via hypercall.

The reason for doing this is that the native dma_ops map_page could
allocate buffers than need to be freed. If the page is foreign we don't
call the native unmap_page dma_ops function, resulting in a memory leak.

Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

---

Changes in v9:
- map_page is always present;
- use bool local for clarity;
- add a comment.
---
 arch/arm/include/asm/xen/page-coherent.h |   13 ++++++++++++-
 arch/arm/xen/mm32.c                      |   12 ++++++++++++
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index a309f42..efd5624 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -5,6 +5,9 @@
 #include <linux/dma-attrs.h>
 #include <linux/dma-mapping.h>
 
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs);
 void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs);
@@ -32,7 +35,15 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 	     dma_addr_t dev_addr, unsigned long offset, size_t size,
 	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
-	__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
+	bool local = PFN_DOWN(dev_addr) == page_to_pfn(page);
+	/* Dom0 is mapped 1:1, so if pfn == mfn the page is local otherwise
+	 * is a foreign page grant-mapped in dom0. If the page is local we
+	 * can safely call the native dma_ops function, otherwise we call
+	 * the xen specific function. */
+	if (local)
+		__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
+	else
+		__xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
 }
 
 static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index 3ce9dc1..c86919b 100644
--- a/arch/arm/xen/mm32.c
+++ b/arch/arm/xen/mm32.c
@@ -43,6 +43,18 @@ static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
 }
 
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
+}
+
 void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir,
 		struct dma_attrs *attrs)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1XoWIp-000706-N5; Wed, 12 Nov 2014 11:41:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIo-0006z1-LX
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:34 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	36/4F-02576-E6743645; Wed, 12 Nov 2014 11:41:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415792491!11999399!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22940 invoked from network); 12 Nov 2014 11:41:33 -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;
	12 Nov 2014 11:41:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190474976"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-3s;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:51 +0000
Message-ID: <1415792454-23161-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 10/13] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 function to find out whether a particular dma
mapping operation needs to bounce on the swiotlb buffer.

On ARM and ARM64, if the page involved is a foreign page and the device
is not coherent, we need to bounce because at unmap time we cannot
execute any required cache maintenance operations (we don't know how to
find the pfn from the mfn).

No change of behaviour for x86.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

Changes in v6:
- fix ts.

Changes in v5:
- fix indentation.
---
 arch/arm/include/asm/xen/page.h |    4 ++++
 arch/arm/xen/mm.c               |    7 +++++++
 arch/x86/include/asm/xen/page.h |    7 +++++++
 drivers/xen/swiotlb-xen.c       |    5 ++++-
 4 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 135c24a..68c739b 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
 #define xen_unmap(cookie) iounmap((cookie))
 
+bool xen_arch_need_swiotlb(struct device *dev,
+			   unsigned long pfn,
+			   unsigned long mfn);
+
 #endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index ab700e1..28ebf3e 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -100,6 +100,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
 	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
 }
 
+bool xen_arch_need_swiotlb(struct device *dev,
+			   unsigned long pfn,
+			   unsigned long mfn)
+{
+	return ((pfn != mfn) && !is_device_dma_coherent(dev));
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 				 unsigned int address_bits,
 				 dma_addr_t *dma_handle)
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c949923..f58ef6c 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
 #define xen_remap(cookie, size) ioremap((cookie), (size));
 #define xen_unmap(cookie) iounmap((cookie))
 
+static inline bool xen_arch_need_swiotlb(struct device *dev,
+					 unsigned long pfn,
+					 unsigned long mfn)
+{
+	return false;
+}
+
 #endif /* _ASM_X86_XEN_PAGE_H */
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ad2c5eb..3725ee4 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 	 * buffering it.
 	 */
 	if (dma_capable(dev, dev_addr, size) &&
-	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
+	    !range_straddles_page_boundary(phys, size) &&
+		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
+		!swiotlb_force) {
 		/* we are not interested in the dma_addr returned by
 		 * xen_dma_map_page, only in the potential cache flushes executed
 		 * by the function. */
@@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
 
 		if (swiotlb_force ||
+		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
 		    !dma_capable(hwdev, dev_addr, sg->length) ||
 		    range_straddles_page_boundary(paddr, sg->length)) {
 			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIr-00071u-4A; Wed, 12 Nov 2014 11:41:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIp-0006zd-EN
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:35 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	C9/99-03145-E6743645; Wed, 12 Nov 2014 11:41:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415792491!11999399!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23035 invoked from network); 12 Nov 2014 11:41:33 -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;
	12 Nov 2014 11:41:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190474977"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-1x;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:50 +0000
Message-ID: <1415792454-23161-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 09/13] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Merge xen/mm32.c into xen/mm.c.
As a consequence the code gets compiled on arm64 too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/xen/Makefile                      |    2 +-
 arch/arm/xen/mm.c                          |   84 +++++++++++++++++++++++++
 arch/arm/xen/mm32.c                        |   94 ----------------------------
 arch/arm64/include/asm/xen/page-coherent.h |   44 +------------
 4 files changed, 86 insertions(+), 138 deletions(-)
 delete mode 100644 arch/arm/xen/mm32.c

diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1f85bfe..1296952 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o hypercall.o grant-table.o p2m.o mm.o mm32.o
+obj-y		:= enlighten.o hypercall.o grant-table.o p2m.o mm.o
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index b0e77de..ab700e1 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -1,6 +1,10 @@
+#include <linux/cpu.h>
+#include <linux/dma-mapping.h>
 #include <linux/bootmem.h>
 #include <linux/gfp.h>
+#include <linux/highmem.h>
 #include <linux/export.h>
+#include <linux/of_address.h>
 #include <linux/slab.h>
 #include <linux/types.h>
 #include <linux/dma-mapping.h>
@@ -16,6 +20,86 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
+enum dma_cache_op {
+       DMA_UNMAP,
+       DMA_MAP,
+};
+
+/* functions called by SWIOTLB */
+
+static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
+	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
+{
+	unsigned long pfn;
+	size_t left = size;
+
+	pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
+	offset %= PAGE_SIZE;
+
+	do {
+		size_t len = left;
+	
+		/* TODO: cache flush */
+
+		offset = 0;
+		pfn++;
+		left -= len;
+	} while (left);
+}
+
+static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir)
+{
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
+}
+
+static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir)
+{
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
+}
+
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
+}
+
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir,
+		struct dma_attrs *attrs)
+
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
+}
+
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
+}
+
+void __xen_dma_sync_single_for_device(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 				 unsigned int address_bits,
 				 dma_addr_t *dma_handle)
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
deleted file mode 100644
index c86919b..0000000
--- a/arch/arm/xen/mm32.c
+++ /dev/null
@@ -1,94 +0,0 @@
-#include <linux/cpu.h>
-#include <linux/dma-mapping.h>
-#include <linux/gfp.h>
-#include <linux/highmem.h>
-
-#include <xen/features.h>
-enum dma_cache_op {
-       DMA_UNMAP,
-       DMA_MAP,
-};
-
-/* functions called by SWIOTLB */
-
-static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
-	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
-{
-	unsigned long pfn;
-	size_t left = size;
-
-	pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
-	offset %= PAGE_SIZE;
-
-	do {
-		size_t len = left;
-	
-		/* TODO: cache flush */
-
-		offset = 0;
-		pfn++;
-		left -= len;
-	} while (left);
-}
-
-static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir)
-{
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
-}
-
-static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir)
-{
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
-}
-
-void __xen_dma_map_page(struct device *hwdev, struct page *page,
-	     dma_addr_t dev_addr, unsigned long offset, size_t size,
-	     enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		return;
-
-	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
-}
-
-void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs)
-
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		return;
-
-	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
-}
-
-int __init xen_mm32_init(void)
-{
-	if (!xen_initial_domain())
-		return 0;
-
-	return 0;
-}
-arch_initcall(xen_mm32_init);
diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
index d7cd4c2..2052102 100644
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ b/arch/arm64/include/asm/xen/page-coherent.h
@@ -1,43 +1 @@
-#ifndef _ASM_ARM64_XEN_PAGE_COHERENT_H
-#define _ASM_ARM64_XEN_PAGE_COHERENT_H
-
-#include <asm/page.h>
-#include <linux/dma-attrs.h>
-#include <linux/dma-mapping.h>
-
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
-		dma_addr_t *dma_handle, gfp_t flags,
-		struct dma_attrs *attrs)
-{
-	return __generic_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags, attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
-		void *cpu_addr, dma_addr_t dma_handle,
-		struct dma_attrs *attrs)
-{
-	__generic_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     dma_addr_t dev_addr, unsigned long offset, size_t size,
-	     enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-}
-
-static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs)
-{
-}
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-}
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-}
-#endif /* _ASM_ARM64_XEN_PAGE_COHERENT_H */
+#include <../../arm/include/asm/xen/page-coherent.h>
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:41:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:41:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWIr-00071u-4A; Wed, 12 Nov 2014 11:41:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWIp-0006zd-EN
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:41:35 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	C9/99-03145-E6743645; Wed, 12 Nov 2014 11:41:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415792491!11999399!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23035 invoked from network); 12 Nov 2014 11:41:33 -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;
	12 Nov 2014 11:41:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190474977"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:41:14 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-1x;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:50 +0000
Message-ID: <1415792454-23161-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 09/13] xen/arm/arm64: merge xen/mm32.c into
	xen/mm.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Merge xen/mm32.c into xen/mm.c.
As a consequence the code gets compiled on arm64 too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/xen/Makefile                      |    2 +-
 arch/arm/xen/mm.c                          |   84 +++++++++++++++++++++++++
 arch/arm/xen/mm32.c                        |   94 ----------------------------
 arch/arm64/include/asm/xen/page-coherent.h |   44 +------------
 4 files changed, 86 insertions(+), 138 deletions(-)
 delete mode 100644 arch/arm/xen/mm32.c

diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1f85bfe..1296952 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o hypercall.o grant-table.o p2m.o mm.o mm32.o
+obj-y		:= enlighten.o hypercall.o grant-table.o p2m.o mm.o
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index b0e77de..ab700e1 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -1,6 +1,10 @@
+#include <linux/cpu.h>
+#include <linux/dma-mapping.h>
 #include <linux/bootmem.h>
 #include <linux/gfp.h>
+#include <linux/highmem.h>
 #include <linux/export.h>
+#include <linux/of_address.h>
 #include <linux/slab.h>
 #include <linux/types.h>
 #include <linux/dma-mapping.h>
@@ -16,6 +20,86 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
+enum dma_cache_op {
+       DMA_UNMAP,
+       DMA_MAP,
+};
+
+/* functions called by SWIOTLB */
+
+static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
+	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
+{
+	unsigned long pfn;
+	size_t left = size;
+
+	pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
+	offset %= PAGE_SIZE;
+
+	do {
+		size_t len = left;
+	
+		/* TODO: cache flush */
+
+		offset = 0;
+		pfn++;
+		left -= len;
+	} while (left);
+}
+
+static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir)
+{
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
+}
+
+static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir)
+{
+	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
+}
+
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+	     dma_addr_t dev_addr, unsigned long offset, size_t size,
+	     enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
+}
+
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+		size_t size, enum dma_data_direction dir,
+		struct dma_attrs *attrs)
+
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		return;
+
+	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
+}
+
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
+}
+
+void __xen_dma_sync_single_for_device(struct device *hwdev,
+		dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+	if (is_device_dma_coherent(hwdev))
+		return;
+	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 				 unsigned int address_bits,
 				 dma_addr_t *dma_handle)
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
deleted file mode 100644
index c86919b..0000000
--- a/arch/arm/xen/mm32.c
+++ /dev/null
@@ -1,94 +0,0 @@
-#include <linux/cpu.h>
-#include <linux/dma-mapping.h>
-#include <linux/gfp.h>
-#include <linux/highmem.h>
-
-#include <xen/features.h>
-enum dma_cache_op {
-       DMA_UNMAP,
-       DMA_MAP,
-};
-
-/* functions called by SWIOTLB */
-
-static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
-	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
-{
-	unsigned long pfn;
-	size_t left = size;
-
-	pfn = (handle >> PAGE_SHIFT) + offset / PAGE_SIZE;
-	offset %= PAGE_SIZE;
-
-	do {
-		size_t len = left;
-	
-		/* TODO: cache flush */
-
-		offset = 0;
-		pfn++;
-		left -= len;
-	} while (left);
-}
-
-static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir)
-{
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
-}
-
-static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir)
-{
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
-}
-
-void __xen_dma_map_page(struct device *hwdev, struct page *page,
-	     dma_addr_t dev_addr, unsigned long offset, size_t size,
-	     enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		return;
-
-	__xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
-}
-
-void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs)
-
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		return;
-
-	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-	if (is_device_dma_coherent(hwdev))
-		return;
-	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
-}
-
-int __init xen_mm32_init(void)
-{
-	if (!xen_initial_domain())
-		return 0;
-
-	return 0;
-}
-arch_initcall(xen_mm32_init);
diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
index d7cd4c2..2052102 100644
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ b/arch/arm64/include/asm/xen/page-coherent.h
@@ -1,43 +1 @@
-#ifndef _ASM_ARM64_XEN_PAGE_COHERENT_H
-#define _ASM_ARM64_XEN_PAGE_COHERENT_H
-
-#include <asm/page.h>
-#include <linux/dma-attrs.h>
-#include <linux/dma-mapping.h>
-
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
-		dma_addr_t *dma_handle, gfp_t flags,
-		struct dma_attrs *attrs)
-{
-	return __generic_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags, attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
-		void *cpu_addr, dma_addr_t dma_handle,
-		struct dma_attrs *attrs)
-{
-	__generic_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-	     dma_addr_t dev_addr, unsigned long offset, size_t size,
-	     enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-}
-
-static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs)
-{
-}
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-}
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-}
-#endif /* _ASM_ARM64_XEN_PAGE_COHERENT_H */
+#include <../../arm/include/asm/xen/page-coherent.h>
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:48:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:48:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWOz-0008JT-9S; Wed, 12 Nov 2014 11:47:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWOx-0008JO-TW
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:47:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7A/45-24532-BE843645; Wed, 12 Nov 2014 11:47:55 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415792873!12175512!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19068 invoked from network); 12 Nov 2014 11:47:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:47:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190476323"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:47:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-5b;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:54 +0000
Message-ID: <1415792454-23161-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 13/13] swiotlb-xen: remove BUG_ON in
	xen_bus_to_phys
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On x86 truncation cannot occur because config XEN depends on X86_64 ||
(X86_32 && X86_PAE).

On ARM truncation can occur without CONFIG_ARM_LPAE, when the dma
operation involves foreign grants. However in that case the physical
address returned by xen_bus_to_phys is actually invalid (there is no mfn
to pfn tracking for foreign grants on ARM) and it is not used.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 drivers/xen/swiotlb-xen.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 498b654..153cf14 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
 	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
 	phys_addr_t paddr = dma;
 
-	BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
-
 	paddr |= baddr & ~PAGE_MASK;
 
 	return paddr;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:48:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:48:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWP8-0008Ki-Ql; Wed, 12 Nov 2014 11:48:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWP7-0008KO-DE
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:48:05 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	7C/B2-01660-4F843645; Wed, 12 Nov 2014 11:48:04 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792882!10885822!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28754 invoked from network); 12 Nov 2014 11:48:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:48:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191922247"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:48:01 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-4R;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:52 +0000
Message-ID: <1415792454-23161-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 11/13] xen/arm: introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce support for new hypercall GNTTABOP_cache_flush.
Use it to perform cache flashing on pages used for dma when necessary.

If GNTTABOP_cache_flush is supported by the hypervisor, we don't need to
bounce dma map operations that involve foreign grants and non-coherent
devices.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---

Changes in v5:
- rename hypercall_flush to hypercall_cflush;
- remove spurious change.

Changes in v4:
- add comment;
- avoid bouncing dma map operations that involve foreign grants and
non-coherent devices if GNTTABOP_cache_flush is provided by Xen.

Changes in v3:
- fix the cache maintenance op call to match what Linux does natively;
- update the hypercall interface to match Xen.

Changes in v2:
- update the hypercall interface to match Xen;
- call the interface on a single page at a time.
---
 arch/arm/xen/mm.c                   |   34 ++++++++++++++++++++++++++++++++--
 include/xen/interface/grant_table.h |   19 +++++++++++++++++++
 2 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 28ebf3e..351b24a 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -12,6 +12,7 @@
 #include <linux/swiotlb.h>
 
 #include <xen/xen.h>
+#include <xen/interface/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/swiotlb-xen.h>
 
@@ -24,12 +25,14 @@ enum dma_cache_op {
        DMA_UNMAP,
        DMA_MAP,
 };
+static bool hypercall_cflush = false;
 
 /* functions called by SWIOTLB */
 
 static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
 {
+	struct gnttab_cache_flush cflush;
 	unsigned long pfn;
 	size_t left = size;
 
@@ -39,7 +42,26 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	do {
 		size_t len = left;
 	
-		/* TODO: cache flush */
+		/* buffers in highmem or foreign pages cannot cross page
+		 * boundaries */
+		if (len + offset > PAGE_SIZE)
+			len = PAGE_SIZE - offset;
+
+		cflush.op = 0;
+		cflush.a.dev_bus_addr = pfn << PAGE_SHIFT;
+		cflush.offset = offset;
+		cflush.length = len;
+
+		if (op == DMA_UNMAP && dir != DMA_TO_DEVICE)
+			cflush.op = GNTTAB_CACHE_INVAL;
+		if (op == DMA_MAP) {
+			if (dir == DMA_FROM_DEVICE)
+				cflush.op = GNTTAB_CACHE_INVAL;
+			else
+				cflush.op = GNTTAB_CACHE_CLEAN;
+		}
+		if (cflush.op)
+			HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1);
 
 		offset = 0;
 		pfn++;
@@ -104,7 +126,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
 			   unsigned long pfn,
 			   unsigned long mfn)
 {
-	return ((pfn != mfn) && !is_device_dma_coherent(dev));
+	return (!hypercall_cflush && (pfn != mfn) && !is_device_dma_coherent(dev));
 }
 
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
@@ -147,10 +169,18 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 
 int __init xen_mm_init(void)
 {
+	struct gnttab_cache_flush cflush;
 	if (!xen_initial_domain())
 		return 0;
 	xen_swiotlb_init(1, false);
 	xen_dma_ops = &xen_swiotlb_dma_ops;
+
+	cflush.op = 0;
+	cflush.a.dev_bus_addr = 0;
+	cflush.offset = 0;
+	cflush.length = 0;
+	if (HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1) != -ENOSYS)
+		hypercall_cflush = true;
 	return 0;
 }
 arch_initcall(xen_mm_init);
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index e40fae9..bcce564 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -479,6 +479,25 @@ struct gnttab_get_version {
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_version);
 
 /*
+ * Issue one or more cache maintenance operations on a portion of a
+ * page granted to the calling domain by a foreign domain.
+ */
+#define GNTTABOP_cache_flush          12
+struct gnttab_cache_flush {
+    union {
+        uint64_t dev_bus_addr;
+        grant_ref_t ref;
+    } a;
+    uint16_t offset;   /* offset from start of grant */
+    uint16_t length;   /* size within the grant */
+#define GNTTAB_CACHE_CLEAN          (1<<0)
+#define GNTTAB_CACHE_INVAL          (1<<1)
+#define GNTTAB_CACHE_SOURCE_GREF    (1<<31)
+    uint32_t op;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_cache_flush);
+
+/*
  * Bitfield values for update_pin_status.flags.
  */
  /* Map the grant entry for access by I/O devices. */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:48:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:48:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWOz-0008JT-9S; Wed, 12 Nov 2014 11:47:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWOx-0008JO-TW
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:47:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7A/45-24532-BE843645; Wed, 12 Nov 2014 11:47:55 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415792873!12175512!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19068 invoked from network); 12 Nov 2014 11:47:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:47:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190476323"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:47:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-5b;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:54 +0000
Message-ID: <1415792454-23161-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 13/13] swiotlb-xen: remove BUG_ON in
	xen_bus_to_phys
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On x86 truncation cannot occur because config XEN depends on X86_64 ||
(X86_32 && X86_PAE).

On ARM truncation can occur without CONFIG_ARM_LPAE, when the dma
operation involves foreign grants. However in that case the physical
address returned by xen_bus_to_phys is actually invalid (there is no mfn
to pfn tracking for foreign grants on ARM) and it is not used.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 drivers/xen/swiotlb-xen.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 498b654..153cf14 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
 	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
 	phys_addr_t paddr = dma;
 
-	BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
-
 	paddr |= baddr & ~PAGE_MASK;
 
 	return paddr;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:48:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:48:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWP8-0008Ki-Ql; Wed, 12 Nov 2014 11:48:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWP7-0008KO-DE
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:48:05 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	7C/B2-01660-4F843645; Wed, 12 Nov 2014 11:48:04 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792882!10885822!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28754 invoked from network); 12 Nov 2014 11:48:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:48:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191922247"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:48:01 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-4R;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:52 +0000
Message-ID: <1415792454-23161-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 11/13] xen/arm: introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce support for new hypercall GNTTABOP_cache_flush.
Use it to perform cache flashing on pages used for dma when necessary.

If GNTTABOP_cache_flush is supported by the hypervisor, we don't need to
bounce dma map operations that involve foreign grants and non-coherent
devices.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---

Changes in v5:
- rename hypercall_flush to hypercall_cflush;
- remove spurious change.

Changes in v4:
- add comment;
- avoid bouncing dma map operations that involve foreign grants and
non-coherent devices if GNTTABOP_cache_flush is provided by Xen.

Changes in v3:
- fix the cache maintenance op call to match what Linux does natively;
- update the hypercall interface to match Xen.

Changes in v2:
- update the hypercall interface to match Xen;
- call the interface on a single page at a time.
---
 arch/arm/xen/mm.c                   |   34 ++++++++++++++++++++++++++++++++--
 include/xen/interface/grant_table.h |   19 +++++++++++++++++++
 2 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 28ebf3e..351b24a 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -12,6 +12,7 @@
 #include <linux/swiotlb.h>
 
 #include <xen/xen.h>
+#include <xen/interface/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/swiotlb-xen.h>
 
@@ -24,12 +25,14 @@ enum dma_cache_op {
        DMA_UNMAP,
        DMA_MAP,
 };
+static bool hypercall_cflush = false;
 
 /* functions called by SWIOTLB */
 
 static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
 {
+	struct gnttab_cache_flush cflush;
 	unsigned long pfn;
 	size_t left = size;
 
@@ -39,7 +42,26 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
 	do {
 		size_t len = left;
 	
-		/* TODO: cache flush */
+		/* buffers in highmem or foreign pages cannot cross page
+		 * boundaries */
+		if (len + offset > PAGE_SIZE)
+			len = PAGE_SIZE - offset;
+
+		cflush.op = 0;
+		cflush.a.dev_bus_addr = pfn << PAGE_SHIFT;
+		cflush.offset = offset;
+		cflush.length = len;
+
+		if (op == DMA_UNMAP && dir != DMA_TO_DEVICE)
+			cflush.op = GNTTAB_CACHE_INVAL;
+		if (op == DMA_MAP) {
+			if (dir == DMA_FROM_DEVICE)
+				cflush.op = GNTTAB_CACHE_INVAL;
+			else
+				cflush.op = GNTTAB_CACHE_CLEAN;
+		}
+		if (cflush.op)
+			HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1);
 
 		offset = 0;
 		pfn++;
@@ -104,7 +126,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
 			   unsigned long pfn,
 			   unsigned long mfn)
 {
-	return ((pfn != mfn) && !is_device_dma_coherent(dev));
+	return (!hypercall_cflush && (pfn != mfn) && !is_device_dma_coherent(dev));
 }
 
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
@@ -147,10 +169,18 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 
 int __init xen_mm_init(void)
 {
+	struct gnttab_cache_flush cflush;
 	if (!xen_initial_domain())
 		return 0;
 	xen_swiotlb_init(1, false);
 	xen_dma_ops = &xen_swiotlb_dma_ops;
+
+	cflush.op = 0;
+	cflush.a.dev_bus_addr = 0;
+	cflush.offset = 0;
+	cflush.length = 0;
+	if (HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1) != -ENOSYS)
+		hypercall_cflush = true;
 	return 0;
 }
 arch_initcall(xen_mm_init);
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index e40fae9..bcce564 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -479,6 +479,25 @@ struct gnttab_get_version {
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_version);
 
 /*
+ * Issue one or more cache maintenance operations on a portion of a
+ * page granted to the calling domain by a foreign domain.
+ */
+#define GNTTABOP_cache_flush          12
+struct gnttab_cache_flush {
+    union {
+        uint64_t dev_bus_addr;
+        grant_ref_t ref;
+    } a;
+    uint16_t offset;   /* offset from start of grant */
+    uint16_t length;   /* size within the grant */
+#define GNTTAB_CACHE_CLEAN          (1<<0)
+#define GNTTAB_CACHE_INVAL          (1<<1)
+#define GNTTAB_CACHE_SOURCE_GREF    (1<<31)
+    uint32_t op;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_cache_flush);
+
+/*
  * Bitfield values for update_pin_status.flags.
  */
  /* Map the grant entry for access by I/O devices. */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:48:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWPE-0008Mf-8b; Wed, 12 Nov 2014 11:48:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWPC-0008M9-Ub
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:48:11 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	FC/FD-19763-AF843645; Wed, 12 Nov 2014 11:48:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792882!10885822!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29506 invoked from network); 12 Nov 2014 11:48:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:48:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191922266"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:48:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-53;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:53 +0000
Message-ID: <1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 12/13] swiotlb-xen: pass dev_addr to
	xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
handle as argument, not a physical address.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 drivers/xen/swiotlb-xen.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 3725ee4..498b654 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 
 	BUG_ON(dir == DMA_NONE);
 
-	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
+	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr)) {
@@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
 	BUG_ON(dir == DMA_NONE);
 
 	if (target == SYNC_FOR_CPU)
-		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
+		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr))
 		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
 
 	if (target == SYNC_FOR_DEVICE)
-		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
+		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
 
 	if (dir != DMA_FROM_DEVICE)
 		return;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:48:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWPE-0008Mf-8b; Wed, 12 Nov 2014 11:48:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XoWPC-0008M9-Ub
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 11:48:11 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	FC/FD-19763-AF843645; Wed, 12 Nov 2014 11:48:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415792882!10885822!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29506 invoked from network); 12 Nov 2014 11:48:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:48:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191922266"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 06:48:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XoWIP-0003Gl-53;
	Wed, 12 Nov 2014 11:41:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 12 Nov 2014 11:40:53 +0000
Message-ID: <1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v9 12/13] swiotlb-xen: pass dev_addr to
	xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
handle as argument, not a physical address.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 drivers/xen/swiotlb-xen.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 3725ee4..498b654 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 
 	BUG_ON(dir == DMA_NONE);
 
-	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
+	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr)) {
@@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
 	BUG_ON(dir == DMA_NONE);
 
 	if (target == SYNC_FOR_CPU)
-		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
+		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr))
 		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
 
 	if (target == SYNC_FOR_DEVICE)
-		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
+		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
 
 	if (dir != DMA_FROM_DEVICE)
 		return;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:52:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:52:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWTC-0000MW-VX; Wed, 12 Nov 2014 11:52:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoWTB-0000M8-PQ
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:52:17 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C9/61-22737-1F943645; Wed, 12 Nov 2014 11:52:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415793131!7512216!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2366 invoked from network); 12 Nov 2014 11:52:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:52:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191923118"
Message-ID: <1415793127.29592.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Steve Freitas <sflist@ihonk.com>
Date: Wed, 12 Nov 2014 11:52:07 +0000
In-Reply-To: <5461CF21.7050206@ihonk.com>
References: <5461CF21.7050206@ihonk.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] configure: error: Unable to find Python development
 headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 00:56 -0800, Steve Freitas wrote:

> configure: error: Unable to find Python development headers
> configure: error: ./configure failed for tools

config.log/status (perhaps the ones under tools/) might give a clue as
to why it thinks it can't find them.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 11:52:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 11:52:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWTC-0000MW-VX; Wed, 12 Nov 2014 11:52:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoWTB-0000M8-PQ
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 11:52:17 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C9/61-22737-1F943645; Wed, 12 Nov 2014 11:52:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415793131!7512216!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2366 invoked from network); 12 Nov 2014 11:52:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 11:52:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="191923118"
Message-ID: <1415793127.29592.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Steve Freitas <sflist@ihonk.com>
Date: Wed, 12 Nov 2014 11:52:07 +0000
In-Reply-To: <5461CF21.7050206@ihonk.com>
References: <5461CF21.7050206@ihonk.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] configure: error: Unable to find Python development
 headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 00:56 -0800, Steve Freitas wrote:

> configure: error: Unable to find Python development headers
> configure: error: ./configure failed for tools

config.log/status (perhaps the ones under tools/) might give a clue as
to why it thinks it can't find them.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 12:03:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 12:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWdz-0000mj-6v; Wed, 12 Nov 2014 12:03:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoWdx-0000mX-5S
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 12:03:25 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	ED/D2-26858-98C43645; Wed, 12 Nov 2014 12:03:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415793799!6411102!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16329 invoked from network); 12 Nov 2014 12:03:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 12:03:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190479513"
Message-ID: <1415793797.29592.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 12 Nov 2014 12:03:17 +0000
In-Reply-To: <5460DBEF.5000504@oracle.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com> <5460D9C5.4020905@oracle.com>
	<1415633435.25176.27.camel@citrix.com> <5460DBEF.5000504@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 10:38 -0500, Zhigang Wang wrote:
> OK. Let me try my best:
> 
> >>> I'm confused by the description of what's going on, in particular the
> >>> mixing of mem-max commands and target xenstore nodes (since the former
> >>> doesn't really affect the latter).
> >>>
> >>> How was the domain started (memory= and maxmem=).
> 
> xl create with 'memory = 700', no maxmem been set. I think it means maxmem = memory for this case.
> 
> >>> What were static-max and target at the point?
> 
>      /local/domain/3/memory/static-max = "716800"
>      /local/domain/3/memory/target = "716801"
> 
> >>> What did they change to when xl mem-max was issued? 
> 
> When I issue 'xl mem-max <domid> 700', static-max and target in xenstore will not change, but it will cause the command to fail.
> 
> Because: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"
> 
> >>> What did you expect them to change to instead?
> 
> I expect I can set the maxmem to the same value I initially set (700).

OK, thanks, got it. I think the use of xl mem-max is a bit of a
red-herring, the issue here is that static-max < target at start of day.

I suspect there is either a rounding error somewhere or because of
LIBXL_MAXMEM_CONSTANT being inconsistently applied to the two values
somewhere along the line.

We had been planning[0] to remove this early in the 4.5 cycle, but as
ever it never floated to the top of anyone's list. For 4.5 we should
probably look at applying this fudge more consistently.

Ian.

[0] http://bugs.xenproject.org/xen/bug/23



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 12:03:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 12:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWdz-0000mj-6v; Wed, 12 Nov 2014 12:03:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoWdx-0000mX-5S
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 12:03:25 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	ED/D2-26858-98C43645; Wed, 12 Nov 2014 12:03:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415793799!6411102!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16329 invoked from network); 12 Nov 2014 12:03:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 12:03:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190479513"
Message-ID: <1415793797.29592.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 12 Nov 2014 12:03:17 +0000
In-Reply-To: <5460DBEF.5000504@oracle.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com> <5460D9C5.4020905@oracle.com>
	<1415633435.25176.27.camel@citrix.com> <5460DBEF.5000504@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 10:38 -0500, Zhigang Wang wrote:
> OK. Let me try my best:
> 
> >>> I'm confused by the description of what's going on, in particular the
> >>> mixing of mem-max commands and target xenstore nodes (since the former
> >>> doesn't really affect the latter).
> >>>
> >>> How was the domain started (memory= and maxmem=).
> 
> xl create with 'memory = 700', no maxmem been set. I think it means maxmem = memory for this case.
> 
> >>> What were static-max and target at the point?
> 
>      /local/domain/3/memory/static-max = "716800"
>      /local/domain/3/memory/target = "716801"
> 
> >>> What did they change to when xl mem-max was issued? 
> 
> When I issue 'xl mem-max <domid> 700', static-max and target in xenstore will not change, but it will cause the command to fail.
> 
> Because: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"
> 
> >>> What did you expect them to change to instead?
> 
> I expect I can set the maxmem to the same value I initially set (700).

OK, thanks, got it. I think the use of xl mem-max is a bit of a
red-herring, the issue here is that static-max < target at start of day.

I suspect there is either a rounding error somewhere or because of
LIBXL_MAXMEM_CONSTANT being inconsistently applied to the two values
somewhere along the line.

We had been planning[0] to remove this early in the 4.5 cycle, but as
ever it never floated to the top of anyone's list. For 4.5 we should
probably look at applying this fudge more consistently.

Ian.

[0] http://bugs.xenproject.org/xen/bug/23



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 12:15:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 12:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWp3-0001Ek-Hu; Wed, 12 Nov 2014 12:14:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoWp1-0001Ef-Sr
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 12:14:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C0/45-09936-B3F43645; Wed, 12 Nov 2014 12:14:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415794489!11830436!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12394 invoked from network); 12 Nov 2014 12:14:50 -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;
	12 Nov 2014 12:14:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190482822"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 07:14:48 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoWoy-0004BO-Ce;
	Wed, 12 Nov 2014 12:14:48 +0000
Date: Wed, 12 Nov 2014 12:14:48 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141112121448.GB28075@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54624F6A.40002@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:03:22PM +0000, David Vrabel wrote:
> On 11/11/14 17:36, Wei Liu wrote:
> > # What's already implemented?
> > 
> > PV vNUMA support in libxl/xl and Linux kernel.
> 
> Linux doesn't have vnuma yet, although the last set of patches I saw
> looked fine and were waiting for acks from x86 maintainers I think.
> 

What I meant was I have those implemented but not yet posted. ;-)

> > # NUMA-aware ballooning
> > 
> > It's agreed that NUMA-aware ballooning should be achieved solely in
> > hypervisor. Everything should happen under the hood without guest
> > knowing vnode to pnode mapping.
> > 
> > As far as I can tell, existing guests (Linux and FreeBSD) use
> > XENMEM_populate_physmap to balloon up. There's a hypercall
> > called XENMEM_increase_reservation but it's not used
> > by Linux and FreeBSD.
> > 
> > I can think of two options to implement NUMA-aware ballooning:
> > 
> > 1. Modify XENMEM_populate_physmap to take into account vNUMA hint
> >    when it tries to allocate a page for guest.
> [...]
> > Option #1 requires less modification to guest, because guest won't
> > need to switch to new hypercall. It's unclear at this point if a guest
> > asks to populate a gpfn that doesn't belong to any vnode, what Xen
> > should do about it. Should it be permissive or strict? 
> 
> There are XENMEMF flags to request exact node or not  -- leave it up to
> the balloon driver.  The Linux balloon driver could try exact on all
> nodes before falling back to permissive or just always try inexact.
> 
> Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
> 

Good idea. It should be easy to make it work.

> > 
> > # HVM vNUMA
> > 
> > HVM vNUMA is implemented as followed:
> > 
> > 1. Libxl generates vNUMA information and passes it to hvmloader.
> > 2. Hvmloader build SRAT table.
> > 
> > Note that hvmloader is capable of relocating memory. This means
> > toolstack and guest can have different ideas of the memory layout.
> 
> Why can't hvmloader update the vnuma tables after it has relocated memory?
> 

Because setvnuma is a domctl which cannot be issued by hvmloader.

Wei.

> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 12:15:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 12:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoWp3-0001Ek-Hu; Wed, 12 Nov 2014 12:14:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoWp1-0001Ef-Sr
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 12:14:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C0/45-09936-B3F43645; Wed, 12 Nov 2014 12:14:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415794489!11830436!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12394 invoked from network); 12 Nov 2014 12:14:50 -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;
	12 Nov 2014 12:14:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,368,1413244800"; d="scan'208";a="190482822"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 07:14:48 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoWoy-0004BO-Ce;
	Wed, 12 Nov 2014 12:14:48 +0000
Date: Wed, 12 Nov 2014 12:14:48 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141112121448.GB28075@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54624F6A.40002@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:03:22PM +0000, David Vrabel wrote:
> On 11/11/14 17:36, Wei Liu wrote:
> > # What's already implemented?
> > 
> > PV vNUMA support in libxl/xl and Linux kernel.
> 
> Linux doesn't have vnuma yet, although the last set of patches I saw
> looked fine and were waiting for acks from x86 maintainers I think.
> 

What I meant was I have those implemented but not yet posted. ;-)

> > # NUMA-aware ballooning
> > 
> > It's agreed that NUMA-aware ballooning should be achieved solely in
> > hypervisor. Everything should happen under the hood without guest
> > knowing vnode to pnode mapping.
> > 
> > As far as I can tell, existing guests (Linux and FreeBSD) use
> > XENMEM_populate_physmap to balloon up. There's a hypercall
> > called XENMEM_increase_reservation but it's not used
> > by Linux and FreeBSD.
> > 
> > I can think of two options to implement NUMA-aware ballooning:
> > 
> > 1. Modify XENMEM_populate_physmap to take into account vNUMA hint
> >    when it tries to allocate a page for guest.
> [...]
> > Option #1 requires less modification to guest, because guest won't
> > need to switch to new hypercall. It's unclear at this point if a guest
> > asks to populate a gpfn that doesn't belong to any vnode, what Xen
> > should do about it. Should it be permissive or strict? 
> 
> There are XENMEMF flags to request exact node or not  -- leave it up to
> the balloon driver.  The Linux balloon driver could try exact on all
> nodes before falling back to permissive or just always try inexact.
> 
> Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
> 

Good idea. It should be easy to make it work.

> > 
> > # HVM vNUMA
> > 
> > HVM vNUMA is implemented as followed:
> > 
> > 1. Libxl generates vNUMA information and passes it to hvmloader.
> > 2. Hvmloader build SRAT table.
> > 
> > Note that hvmloader is capable of relocating memory. This means
> > toolstack and guest can have different ideas of the memory layout.
> 
> Why can't hvmloader update the vnuma tables after it has relocated memory?
> 

Because setvnuma is a domctl which cannot be issued by hvmloader.

Wei.

> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 12:39:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 12:39:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoXC4-0001ve-Bq; Wed, 12 Nov 2014 12:38:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XoXC3-0001vZ-3B
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 12:38:39 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	27/C0-02559-EC453645; Wed, 12 Nov 2014 12:38:38 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415795917!12038586!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17324 invoked from network); 12 Nov 2014 12:38:38 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 12:38:38 -0000
Received: by mail-wi0-f174.google.com with SMTP id d1so4754728wiv.1
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 04:38:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=eSrTHotEHZfdTIU6DcxEHbLOb8Exb+8IzEBXc3CiCCk=;
	b=D33GJGInnrNw1UgVCgTQekX5mvzAvpBJ4FborEEgdVhhISM7eLwk8HR92jT5j5sGKl
	uKfwbvdLhgp84MBMtBwgpjydpv9+aYPxALvq4BdFVQaSGy5aBeBOKFWXMtN0PdH6YbAr
	kQI7rUH2auTWH05qrVgSzcSBnedQxjAgqJiHDhE9z6Uds74YAD9m/W1JbJRDs2XK/lMA
	laChStKa0Ukvt/z72xe96zz1wyitowPecQavA7/KdkdwH4sJDI7W31WqA7gT7d0fjueD
	L+4pAmbkTpXMe2TiSLObkkvU5Rhw30NE1bRjY2Dqk+ZZvI96YYHNjPtm5JKkk4zUZY9Y
	LV7w==
X-Gm-Message-State: ALoCoQnGvyBaSwnc71cg9QZRb2CAok8f5+VLS7QbG8MhQT6ZwoMYjLIcrbCkSK87ahNmpZhrdVld
X-Received: by 10.180.102.135 with SMTP id fo7mr50517884wib.79.1415795917704; 
	Wed, 12 Nov 2014 04:38:37 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	wa10sm26636466wjc.8.2014.11.12.04.38.34 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 12 Nov 2014 04:38:36 -0800 (PST)
Message-ID: <546354C4.3010907@linaro.org>
Date: Wed, 12 Nov 2014 12:38:28 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>, xen-devel@lists.xen.org
References: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
Cc: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH] fix commit xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/2014 08:28 PM, M A Young wrote:
> The build of xen-4.5.0-rc2 fails if XSM_ENABLE=y due to an inconsistency
> in commit fda1614 "xen/arm: Add support for GICv3 for domU" which uses
> XEN_DOMCTL_configure_domain in xen/xsm/flask/hooks.c and
> xen/xsm/flask/policy/access_vectors but XEN_DOMCTL_arm_configure_domain
> elsewhere.

Sorry, I renamed the hypercall on the later version and didn't check the
XSM build.

Regards,



-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 12:39:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 12:39:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoXC4-0001ve-Bq; Wed, 12 Nov 2014 12:38:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XoXC3-0001vZ-3B
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 12:38:39 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	27/C0-02559-EC453645; Wed, 12 Nov 2014 12:38:38 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415795917!12038586!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17324 invoked from network); 12 Nov 2014 12:38:38 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 12:38:38 -0000
Received: by mail-wi0-f174.google.com with SMTP id d1so4754728wiv.1
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 04:38:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=eSrTHotEHZfdTIU6DcxEHbLOb8Exb+8IzEBXc3CiCCk=;
	b=D33GJGInnrNw1UgVCgTQekX5mvzAvpBJ4FborEEgdVhhISM7eLwk8HR92jT5j5sGKl
	uKfwbvdLhgp84MBMtBwgpjydpv9+aYPxALvq4BdFVQaSGy5aBeBOKFWXMtN0PdH6YbAr
	kQI7rUH2auTWH05qrVgSzcSBnedQxjAgqJiHDhE9z6Uds74YAD9m/W1JbJRDs2XK/lMA
	laChStKa0Ukvt/z72xe96zz1wyitowPecQavA7/KdkdwH4sJDI7W31WqA7gT7d0fjueD
	L+4pAmbkTpXMe2TiSLObkkvU5Rhw30NE1bRjY2Dqk+ZZvI96YYHNjPtm5JKkk4zUZY9Y
	LV7w==
X-Gm-Message-State: ALoCoQnGvyBaSwnc71cg9QZRb2CAok8f5+VLS7QbG8MhQT6ZwoMYjLIcrbCkSK87ahNmpZhrdVld
X-Received: by 10.180.102.135 with SMTP id fo7mr50517884wib.79.1415795917704; 
	Wed, 12 Nov 2014 04:38:37 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	wa10sm26636466wjc.8.2014.11.12.04.38.34 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 12 Nov 2014 04:38:36 -0800 (PST)
Message-ID: <546354C4.3010907@linaro.org>
Date: Wed, 12 Nov 2014 12:38:28 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>, xen-devel@lists.xen.org
References: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1411111905050.25402@procyon.dur.ac.uk>
Cc: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH] fix commit xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/11/2014 08:28 PM, M A Young wrote:
> The build of xen-4.5.0-rc2 fails if XSM_ENABLE=y due to an inconsistency
> in commit fda1614 "xen/arm: Add support for GICv3 for domU" which uses
> XEN_DOMCTL_configure_domain in xen/xsm/flask/hooks.c and
> xen/xsm/flask/policy/access_vectors but XEN_DOMCTL_arm_configure_domain
> elsewhere.

Sorry, I renamed the hypercall on the later version and didn't check the
XSM build.

Regards,



-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 12:39:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 12:39:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoXCb-0001xy-Ov; Wed, 12 Nov 2014 12:39:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XoXCa-0001xn-I7
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 12:39:12 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	DC/0A-25714-FE453645; Wed, 12 Nov 2014 12:39:11 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415795949!10900000!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10995 invoked from network); 12 Nov 2014 12:39:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 12:39:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACCd594031919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 12:39:06 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACCd47V005696
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 12:39:05 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACCd4Ch003881; Wed, 12 Nov 2014 12:39:04 GMT
Received: from [10.154.147.254] (/10.154.147.254)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 04:39:04 -0800
Message-ID: <546354D7.2040703@oracle.com>
Date: Wed, 12 Nov 2014 07:38:47 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Hu, Robert" <robert.hu@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/12/2014 01:58 AM, Hu, Robert wrote:
> 2. Failed to hotplug a VT-d device with XEN4.5-RC1
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894


This should be addressed by these two:
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00875.html
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00874.html

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 12:39:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 12:39:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoXCb-0001xy-Ov; Wed, 12 Nov 2014 12:39:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XoXCa-0001xn-I7
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 12:39:12 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	DC/0A-25714-FE453645; Wed, 12 Nov 2014 12:39:11 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415795949!10900000!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10995 invoked from network); 12 Nov 2014 12:39:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 12:39:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACCd594031919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 12:39:06 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACCd47V005696
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 12:39:05 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACCd4Ch003881; Wed, 12 Nov 2014 12:39:04 GMT
Received: from [10.154.147.254] (/10.154.147.254)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 04:39:04 -0800
Message-ID: <546354D7.2040703@oracle.com>
Date: Wed, 12 Nov 2014 07:38:47 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Hu, Robert" <robert.hu@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/12/2014 01:58 AM, Hu, Robert wrote:
> 2. Failed to hotplug a VT-d device with XEN4.5-RC1
>    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894


This should be addressed by these two:
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00875.html
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00874.html

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 13:23:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 13:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoXtF-00039G-1Q; Wed, 12 Nov 2014 13:23:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoXtE-00039B-3t
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 13:23:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6D/DC-09842-34F53645; Wed, 12 Nov 2014 13:23:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415798593!12204123!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15074 invoked from network); 12 Nov 2014 13:23:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 13:23:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190501401"
Message-ID: <1415798591.1155.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Date: Wed, 12 Nov 2014 13:23:11 +0000
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4CD95@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54633B260200007800046B39@mail.emea.novell.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A4CD95@SHSMSX103.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 10:53 +0000, Hu, Robert wrote:
> I think it shall be stored somewhere and be tracked, rather than one
> by one mail thread. To follow your suggestion, I would next time in
> addition send each bug per mail, with descriptions contained.

If you send each bug as a separate email to xen-devel then if necessary
they can be tracked via http://bugs.xenproject.org/xen/

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 13:23:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 13:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoXtF-00039G-1Q; Wed, 12 Nov 2014 13:23:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoXtE-00039B-3t
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 13:23:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6D/DC-09842-34F53645; Wed, 12 Nov 2014 13:23:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415798593!12204123!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15074 invoked from network); 12 Nov 2014 13:23:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 13:23:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190501401"
Message-ID: <1415798591.1155.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Date: Wed, 12 Nov 2014 13:23:11 +0000
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4CD95@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54633B260200007800046B39@mail.emea.novell.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A4CD95@SHSMSX103.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 10:53 +0000, Hu, Robert wrote:
> I think it shall be stored somewhere and be tracked, rather than one
> by one mail thread. To follow your suggestion, I would next time in
> addition send each bug per mail, with descriptions contained.

If you send each bug as a separate email to xen-devel then if necessary
they can be tracked via http://bugs.xenproject.org/xen/

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 13:45:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 13:45:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYEr-0003fW-En; Wed, 12 Nov 2014 13:45:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoYEq-0003fN-3i
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 13:45:36 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	C0/05-02696-F7463645; Wed, 12 Nov 2014 13:45:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415799931!11969129!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2464 invoked from network); 12 Nov 2014 13:45:34 -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;
	12 Nov 2014 13:45:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="191956816"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 08:45:30 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoYEk-0005cN-Hm;
	Wed, 12 Nov 2014 13:45:30 +0000
Date: Wed, 12 Nov 2014 13:45:30 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141112134530.GA31665@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546337D50200007800046B2F@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
> >>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
> > On 11/11/14 17:36, Wei Liu wrote:
> >> Option #1 requires less modification to guest, because guest won't
> >> need to switch to new hypercall. It's unclear at this point if a guest
> >> asks to populate a gpfn that doesn't belong to any vnode, what Xen
> >> should do about it. Should it be permissive or strict? 
> > 
> > There are XENMEMF flags to request exact node or not  -- leave it up to
> > the balloon driver.  The Linux balloon driver could try exact on all
> > nodes before falling back to permissive or just always try inexact.
> > 
> > Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
> 
> Yes. The only bad thing here is that we don't currently check in the
> hypervisor that unknown bits are zero, i.e. code using the new flag
> will need to have a separate means to find out whether the bit is
> supported. Not a big deal of course.
> 

If this new bit is set and domain has vnuma, then it's valid
(supported); otherwise it's not.

To not break existing guests, we can fall back to non-vnuma hinted
allocation when the new bit is set and vnuma is not available.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 13:45:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 13:45:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYEr-0003fW-En; Wed, 12 Nov 2014 13:45:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoYEq-0003fN-3i
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 13:45:36 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	C0/05-02696-F7463645; Wed, 12 Nov 2014 13:45:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415799931!11969129!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2464 invoked from network); 12 Nov 2014 13:45:34 -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;
	12 Nov 2014 13:45:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="191956816"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 08:45:30 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoYEk-0005cN-Hm;
	Wed, 12 Nov 2014 13:45:30 +0000
Date: Wed, 12 Nov 2014 13:45:30 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141112134530.GA31665@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546337D50200007800046B2F@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
> >>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
> > On 11/11/14 17:36, Wei Liu wrote:
> >> Option #1 requires less modification to guest, because guest won't
> >> need to switch to new hypercall. It's unclear at this point if a guest
> >> asks to populate a gpfn that doesn't belong to any vnode, what Xen
> >> should do about it. Should it be permissive or strict? 
> > 
> > There are XENMEMF flags to request exact node or not  -- leave it up to
> > the balloon driver.  The Linux balloon driver could try exact on all
> > nodes before falling back to permissive or just always try inexact.
> > 
> > Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
> 
> Yes. The only bad thing here is that we don't currently check in the
> hypervisor that unknown bits are zero, i.e. code using the new flag
> will need to have a separate means to find out whether the bit is
> supported. Not a big deal of course.
> 

If this new bit is set and domain has vnuma, then it's valid
(supported); otherwise it's not.

To not break existing guests, we can fall back to non-vnuma hinted
allocation when the new bit is set and vnuma is not available.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:05:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:05:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYXS-000473-88; Wed, 12 Nov 2014 14:04:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoYXQ-00046y-DW
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 14:04:48 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	FC/AA-24859-FF863645; Wed, 12 Nov 2014 14:04:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415801085!10876816!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32356 invoked from network); 12 Nov 2014 14:04:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:04:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190514051"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 09:03:53 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoYWX-0003So-II;
	Wed, 12 Nov 2014 14:03:53 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoYWX-0000mi-8S;
	Wed, 12 Nov 2014 14:03:53 +0000
Date: Wed, 12 Nov 2014 14:03:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31497-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11218
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31497: 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: multipart/mixed; boundary="===============1904251113972026186=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1904251113972026186==
Content-Type: text/plain
Content-Length: 10975
Content-Transfer-Encoding: quoted-printable

flight 31497 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31497/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                844741451001cf1aadecde7e5c7b556b8fc4b70b
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary

broken-step test-amd64-i386-freebsd10-i386 host-install(3)

Not pushing.

(No revision log; it would be 11519 lines long.)


--===============1904251113972026186==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1904251113972026186==--

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:05:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:05:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYXS-000473-88; Wed, 12 Nov 2014 14:04:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XoYXQ-00046y-DW
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 14:04:48 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	FC/AA-24859-FF863645; Wed, 12 Nov 2014 14:04:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415801085!10876816!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32356 invoked from network); 12 Nov 2014 14:04:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:04:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190514051"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 09:03:53 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XoYWX-0003So-II;
	Wed, 12 Nov 2014 14:03:53 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XoYWX-0000mi-8S;
	Wed, 12 Nov 2014 14:03:53 +0000
Date: Wed, 12 Nov 2014 14:03:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31497-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11218
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31497: 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: multipart/mixed; boundary="===============1904251113972026186=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1904251113972026186==
Content-Type: text/plain
Content-Length: 10975
Content-Transfer-Encoding: quoted-printable

flight 31497 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31497/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                844741451001cf1aadecde7e5c7b556b8fc4b70b
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Petr Matousek <pmatouse@redhat.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary

broken-step test-amd64-i386-freebsd10-i386 host-install(3)

Not pushing.

(No revision log; it would be 11519 lines long.)


--===============1904251113972026186==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1904251113972026186==--

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:13:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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 1XoYfc-0004L8-Dg; Wed, 12 Nov 2014 14:13:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoYfa-0004Kb-8c
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:13:14 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	EF/02-02953-9FA63645; Wed, 12 Nov 2014 14:13:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415801592!12060266!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26416 invoked from network); 12 Nov 2014 14:13:13 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 14:13:13 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 14:13:12 +0000
Message-Id: <546379050200007800046D6A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 14:13:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
	<20141112134530.GA31665@zion.uk.xensource.com>
In-Reply-To: <20141112134530.GA31665@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 14:45, <wei.liu2@citrix.com> wrote:
> On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
>> >>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
>> > On 11/11/14 17:36, Wei Liu wrote:
>> >> Option #1 requires less modification to guest, because guest won't
>> >> need to switch to new hypercall. It's unclear at this point if a guest
>> >> asks to populate a gpfn that doesn't belong to any vnode, what Xen
>> >> should do about it. Should it be permissive or strict? 
>> > 
>> > There are XENMEMF flags to request exact node or not  -- leave it up to
>> > the balloon driver.  The Linux balloon driver could try exact on all
>> > nodes before falling back to permissive or just always try inexact.
>> > 
>> > Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
>> 
>> Yes. The only bad thing here is that we don't currently check in the
>> hypervisor that unknown bits are zero, i.e. code using the new flag
>> will need to have a separate means to find out whether the bit is
>> supported. Not a big deal of course.
>> 
> 
> If this new bit is set and domain has vnuma, then it's valid
> (supported); otherwise it's not.
> 
> To not break existing guests, we can fall back to non-vnuma hinted
> allocation when the new bit is set and vnuma is not available.

While this is valid, none of this was my point - I was talking about a
new guest running on an older 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 Nov 12 14:13:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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 1XoYfc-0004L8-Dg; Wed, 12 Nov 2014 14:13:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoYfa-0004Kb-8c
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:13:14 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	EF/02-02953-9FA63645; Wed, 12 Nov 2014 14:13:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415801592!12060266!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26416 invoked from network); 12 Nov 2014 14:13:13 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 14:13:13 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 14:13:12 +0000
Message-Id: <546379050200007800046D6A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 14:13:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
	<20141112134530.GA31665@zion.uk.xensource.com>
In-Reply-To: <20141112134530.GA31665@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 14:45, <wei.liu2@citrix.com> wrote:
> On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
>> >>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
>> > On 11/11/14 17:36, Wei Liu wrote:
>> >> Option #1 requires less modification to guest, because guest won't
>> >> need to switch to new hypercall. It's unclear at this point if a guest
>> >> asks to populate a gpfn that doesn't belong to any vnode, what Xen
>> >> should do about it. Should it be permissive or strict? 
>> > 
>> > There are XENMEMF flags to request exact node or not  -- leave it up to
>> > the balloon driver.  The Linux balloon driver could try exact on all
>> > nodes before falling back to permissive or just always try inexact.
>> > 
>> > Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
>> 
>> Yes. The only bad thing here is that we don't currently check in the
>> hypervisor that unknown bits are zero, i.e. code using the new flag
>> will need to have a separate means to find out whether the bit is
>> supported. Not a big deal of course.
>> 
> 
> If this new bit is set and domain has vnuma, then it's valid
> (supported); otherwise it's not.
> 
> To not break existing guests, we can fall back to non-vnuma hinted
> allocation when the new bit is set and vnuma is not available.

While this is valid, none of this was my point - I was talking about a
new guest running on an older 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 Nov 12 14:22:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYoU-0004eP-EM; Wed, 12 Nov 2014 14:22:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XoYoT-0004eK-4O
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 14:22:25 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3B/49-09842-02D63645; Wed, 12 Nov 2014 14:22:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415802143!12219239!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20737 invoked from network); 12 Nov 2014 14:22:23 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:22:23 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so14444589wgg.16
	for <xen-devel@lists.xensource.com>;
	Wed, 12 Nov 2014 06:22:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=miILzvxwyi8A28TZh+4OK0pmLUrGeIn2VZZv5KLSnMo=;
	b=IwuIFA3AjST1bCWfjdINZ8ygZGefzytzcjEfUiRZ7y7CmbE7MBdJ8SUOyj5eT+LCaw
	OuPVXI002wIv8U5IfKSAbEA0gOSqzUs2V6pH0I31N69oOfI1Aelx6M47d2ZdTqvOS15N
	08yuhgmewvni+0kfBTC8UECFz4uhE0WoLqng7LwpyhT45KvoQvuiGVzNDSM8Gz67cjOq
	OA1KLEz6hgi5g7THZaroKRcUlejTELtCmSbLFyQtGdGPsVSAadlEiBqSHUhSfqsO8RRx
	CBR/GLAwFMG+jKXATns+/Hf6OGbO576uq45FP5z5OhU+LBk79RUQYdwui1+t1FTOtIyR
	QFhA==
X-Gm-Message-State: ALoCoQnz2TrNmM1TNFBuGW0NdaLXUvLK9K8QjeGg/ou3jtNv5I+mQgva4PwxPdR6d3gNiKqUCaXq
X-Received: by 10.194.2.244 with SMTP id 20mr64980654wjx.4.1415802143567;
	Wed, 12 Nov 2014 06:22:23 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id mu4sm21844437wib.2.2014.11.12.06.22.21
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 12 Nov 2014 06:22:22 -0800 (PST)
Message-ID: <54636D17.9080008@linaro.org>
Date: Wed, 12 Nov 2014 14:22:15 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	xen-devel@lists.xensource.com
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
Cc: catalin.marinas@arm.com, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v9 0/13] introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On 11/12/2014 11:39 AM, Stefano Stabellini wrote:
> Hi all,
> this patch series introduces support for GNTTABOP_cache_flush to perform
> cache maintenance operation on foreign pages and reverts the current
> code based on XENFEAT_grant_map_identity.
> 
> It also provides a very slow fallback by bouncing on the swiotlb buffer,
> in case the hypercall is not available.
> 
> v7 introduces a flag named dma_coherent in dev_archdata and an accessor
> function named is_device_dma_coherent in asm/dma-mapping.h under arm and
> arm64.

I've been tested this series on non-LPAE kernel and don't see crash anymore:

Tested-by: Julien Grall <julien.grall@linaro.org>

Regards,

> Changes in v9:
> - remove BUG_ON from the loop in dma_cache_maint;
> - add static inline for xen_dma_unmap_page, xen_dma_sync_single_for_cpu,
>   xen_dma_sync_single_for_device;
> - map_page is always present, don't check whether it's implemented;
> - use bool local for clarity;
> - add an in-code comment.
> 
> Changes in v8:
> - remove code duplication in mm32.c by moving the pfn_valid check in
> page-coherent.h;
> - add a dma_addr_t dev_addr argument to xen_dma_map_page;
> - use hypercall to flush caches in map_page;
> - pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu;
> - remove BUG_ON in xen_bus_to_phys.
> 
> Changes in v7:
> - rebased on 3.18-rc1;
> - rename is_dma_coherent to is_device_dma_coherent and move it to
> asm/dma-mapping.h on arm and arm64;
> - introduce a dma_coherent flag on arm and arm64;
> - set the flags from set_arch_dma_coherent_ops.
> 
> Changes in v6:
> - rename xen_is_dma_coherent to is_dma_coherent;
> - use of_dma_is_coherent to detect the dma coherency of a device;
> - remove arch/arm64/include/asm/xen/page-coherent.h, include
> ../../arm/include/asm/xen/page-coherent.h instead;
> - fix indentation.
> 
> Changes in v5:
> - introduce xen_is_dma_coherent as a xen specific function;
> - call xen_is_dma_coherent instead of is_dma_coherent;
> - introduce xen_is_dma_coherent to
> arch/arm64/include/asm/xen/page-coherent.h;
> - do not remove arch/arm64/include/asm/xen/page-coherent.h, add
> the missing dma_ops calls from it;
> - fix indentation;
> - rename hypercall_flush to hypercall_cflush;
> - remove spurious change.
> 
> Changes in v4:
> - remove outer_*_range call;
> - introduce is_dma_coherent;
> - use is_dma_coherent in arch/arm/xen/mm32.c;
> - merge xen/mm32.c into xen/mm.c;
> - xen/arm/arm64: introduce xen_arch_need_swiotlb;
> - avoid bouncing dma map operations that involve foreign grants and
> non-coherent devices if GNTTABOP_cache_flush is provided by Xen.
> 
> Changes in v3:
> - fix the cache maintenance op call to match what Linux does natively;
> - update the hypercall interface to match Xen.
> 
> Changes in v2:
> - remove the definition of XENFEAT_grant_map_identity;
> - update the hypercall interface to match Xen;
> - call the interface on a single page at a time.
> 
> 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git cache_flush_v9
> 
> Stefano Stabellini (13):
>       xen/arm: remove handling of XENFEAT_grant_map_identity
>       xen/arm: remove outer_*_range call
>       xen/arm: if(pfn_valid(pfn)) call native dma_ops
>       arm64: introduce is_device_dma_coherent
>       arm: introduce is_device_dma_coherent
>       xen/arm: use is_device_dma_coherent
>       xen: add a dma_addr_t dev_addr argument to xen_dma_map_page
>       xen/arm: use hypercall to flush caches in map_page
>       xen/arm/arm64: merge xen/mm32.c into xen/mm.c
>       xen/arm/arm64: introduce xen_arch_need_swiotlb
>       xen/arm: introduce GNTTABOP_cache_flush
>       swiotlb-xen: pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu
>       swiotlb-xen: remove BUG_ON in xen_bus_to_phys
> 
>  arch/arm/include/asm/device.h              |    1 +
>  arch/arm/include/asm/dma-mapping.h         |    6 +
>  arch/arm/include/asm/xen/page-coherent.h   |   66 +++++++--
>  arch/arm/include/asm/xen/page.h            |    4 +
>  arch/arm/xen/Makefile                      |    2 +-
>  arch/arm/xen/enlighten.c                   |    5 -
>  arch/arm/xen/mm.c                          |  121 +++++++++++++++++
>  arch/arm/xen/mm32.c                        |  202 ----------------------------
>  arch/arm64/include/asm/device.h            |    1 +
>  arch/arm64/include/asm/dma-mapping.h       |    6 +
>  arch/arm64/include/asm/xen/page-coherent.h |   44 +-----
>  arch/x86/include/asm/xen/page-coherent.h   |    4 +-
>  arch/x86/include/asm/xen/page.h            |    7 +
>  drivers/xen/swiotlb-xen.c                  |   19 +--
>  include/xen/interface/features.h           |    3 -
>  include/xen/interface/grant_table.h        |   19 +++
>  16 files changed, 237 insertions(+), 273 deletions(-)
>  delete mode 100644 arch/arm/xen/mm32.c
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:22:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYoU-0004eP-EM; Wed, 12 Nov 2014 14:22:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XoYoT-0004eK-4O
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 14:22:25 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3B/49-09842-02D63645; Wed, 12 Nov 2014 14:22:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415802143!12219239!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20737 invoked from network); 12 Nov 2014 14:22:23 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:22:23 -0000
Received: by mail-wg0-f43.google.com with SMTP id y10so14444589wgg.16
	for <xen-devel@lists.xensource.com>;
	Wed, 12 Nov 2014 06:22:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=miILzvxwyi8A28TZh+4OK0pmLUrGeIn2VZZv5KLSnMo=;
	b=IwuIFA3AjST1bCWfjdINZ8ygZGefzytzcjEfUiRZ7y7CmbE7MBdJ8SUOyj5eT+LCaw
	OuPVXI002wIv8U5IfKSAbEA0gOSqzUs2V6pH0I31N69oOfI1Aelx6M47d2ZdTqvOS15N
	08yuhgmewvni+0kfBTC8UECFz4uhE0WoLqng7LwpyhT45KvoQvuiGVzNDSM8Gz67cjOq
	OA1KLEz6hgi5g7THZaroKRcUlejTELtCmSbLFyQtGdGPsVSAadlEiBqSHUhSfqsO8RRx
	CBR/GLAwFMG+jKXATns+/Hf6OGbO576uq45FP5z5OhU+LBk79RUQYdwui1+t1FTOtIyR
	QFhA==
X-Gm-Message-State: ALoCoQnz2TrNmM1TNFBuGW0NdaLXUvLK9K8QjeGg/ou3jtNv5I+mQgva4PwxPdR6d3gNiKqUCaXq
X-Received: by 10.194.2.244 with SMTP id 20mr64980654wjx.4.1415802143567;
	Wed, 12 Nov 2014 06:22:23 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id mu4sm21844437wib.2.2014.11.12.06.22.21
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 12 Nov 2014 06:22:22 -0800 (PST)
Message-ID: <54636D17.9080008@linaro.org>
Date: Wed, 12 Nov 2014 14:22:15 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	xen-devel@lists.xensource.com
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
Cc: catalin.marinas@arm.com, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v9 0/13] introduce GNTTABOP_cache_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On 11/12/2014 11:39 AM, Stefano Stabellini wrote:
> Hi all,
> this patch series introduces support for GNTTABOP_cache_flush to perform
> cache maintenance operation on foreign pages and reverts the current
> code based on XENFEAT_grant_map_identity.
> 
> It also provides a very slow fallback by bouncing on the swiotlb buffer,
> in case the hypercall is not available.
> 
> v7 introduces a flag named dma_coherent in dev_archdata and an accessor
> function named is_device_dma_coherent in asm/dma-mapping.h under arm and
> arm64.

I've been tested this series on non-LPAE kernel and don't see crash anymore:

Tested-by: Julien Grall <julien.grall@linaro.org>

Regards,

> Changes in v9:
> - remove BUG_ON from the loop in dma_cache_maint;
> - add static inline for xen_dma_unmap_page, xen_dma_sync_single_for_cpu,
>   xen_dma_sync_single_for_device;
> - map_page is always present, don't check whether it's implemented;
> - use bool local for clarity;
> - add an in-code comment.
> 
> Changes in v8:
> - remove code duplication in mm32.c by moving the pfn_valid check in
> page-coherent.h;
> - add a dma_addr_t dev_addr argument to xen_dma_map_page;
> - use hypercall to flush caches in map_page;
> - pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu;
> - remove BUG_ON in xen_bus_to_phys.
> 
> Changes in v7:
> - rebased on 3.18-rc1;
> - rename is_dma_coherent to is_device_dma_coherent and move it to
> asm/dma-mapping.h on arm and arm64;
> - introduce a dma_coherent flag on arm and arm64;
> - set the flags from set_arch_dma_coherent_ops.
> 
> Changes in v6:
> - rename xen_is_dma_coherent to is_dma_coherent;
> - use of_dma_is_coherent to detect the dma coherency of a device;
> - remove arch/arm64/include/asm/xen/page-coherent.h, include
> ../../arm/include/asm/xen/page-coherent.h instead;
> - fix indentation.
> 
> Changes in v5:
> - introduce xen_is_dma_coherent as a xen specific function;
> - call xen_is_dma_coherent instead of is_dma_coherent;
> - introduce xen_is_dma_coherent to
> arch/arm64/include/asm/xen/page-coherent.h;
> - do not remove arch/arm64/include/asm/xen/page-coherent.h, add
> the missing dma_ops calls from it;
> - fix indentation;
> - rename hypercall_flush to hypercall_cflush;
> - remove spurious change.
> 
> Changes in v4:
> - remove outer_*_range call;
> - introduce is_dma_coherent;
> - use is_dma_coherent in arch/arm/xen/mm32.c;
> - merge xen/mm32.c into xen/mm.c;
> - xen/arm/arm64: introduce xen_arch_need_swiotlb;
> - avoid bouncing dma map operations that involve foreign grants and
> non-coherent devices if GNTTABOP_cache_flush is provided by Xen.
> 
> Changes in v3:
> - fix the cache maintenance op call to match what Linux does natively;
> - update the hypercall interface to match Xen.
> 
> Changes in v2:
> - remove the definition of XENFEAT_grant_map_identity;
> - update the hypercall interface to match Xen;
> - call the interface on a single page at a time.
> 
> 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git cache_flush_v9
> 
> Stefano Stabellini (13):
>       xen/arm: remove handling of XENFEAT_grant_map_identity
>       xen/arm: remove outer_*_range call
>       xen/arm: if(pfn_valid(pfn)) call native dma_ops
>       arm64: introduce is_device_dma_coherent
>       arm: introduce is_device_dma_coherent
>       xen/arm: use is_device_dma_coherent
>       xen: add a dma_addr_t dev_addr argument to xen_dma_map_page
>       xen/arm: use hypercall to flush caches in map_page
>       xen/arm/arm64: merge xen/mm32.c into xen/mm.c
>       xen/arm/arm64: introduce xen_arch_need_swiotlb
>       xen/arm: introduce GNTTABOP_cache_flush
>       swiotlb-xen: pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu
>       swiotlb-xen: remove BUG_ON in xen_bus_to_phys
> 
>  arch/arm/include/asm/device.h              |    1 +
>  arch/arm/include/asm/dma-mapping.h         |    6 +
>  arch/arm/include/asm/xen/page-coherent.h   |   66 +++++++--
>  arch/arm/include/asm/xen/page.h            |    4 +
>  arch/arm/xen/Makefile                      |    2 +-
>  arch/arm/xen/enlighten.c                   |    5 -
>  arch/arm/xen/mm.c                          |  121 +++++++++++++++++
>  arch/arm/xen/mm32.c                        |  202 ----------------------------
>  arch/arm64/include/asm/device.h            |    1 +
>  arch/arm64/include/asm/dma-mapping.h       |    6 +
>  arch/arm64/include/asm/xen/page-coherent.h |   44 +-----
>  arch/x86/include/asm/xen/page-coherent.h   |    4 +-
>  arch/x86/include/asm/xen/page.h            |    7 +
>  drivers/xen/swiotlb-xen.c                  |   19 +--
>  include/xen/interface/features.h           |    3 -
>  include/xen/interface/grant_table.h        |   19 +++
>  16 files changed, 237 insertions(+), 273 deletions(-)
>  delete mode 100644 arch/arm/xen/mm32.c
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:26:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYsg-0004mS-3c; Wed, 12 Nov 2014 14:26:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XoYse-0004mL-IT
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:26:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	48/B3-09842-32E63645; Wed, 12 Nov 2014 14:26:43 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415802402!11872057!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20569 invoked from network); 12 Nov 2014 14:26:43 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:26:42 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so1143195wiw.10
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 06:26:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=jkj4GO5zCAoEu8Qisewzv8UamF1H6RAGQTqcOHsoYT8=;
	b=PUkPfU6UnAeZC3suZRSy3SpjBehJzcpsPB9u/GTAuuJUq7d5b6k/ov40dnLKpyA1tK
	dZqAOk1l1TyrpPyn9LfLHTJrbxGDMdCUusu2MIMM7cSfEWWwWUK5A1IrEeFJA/PY1ODc
	jZf0HKUJJ6Gk8OCvz84QRBBER02qFuwG75bdTleV86WpofAlmKtmNftN9o0dj/TvqVb3
	nwKM8xjDY/ncLF48ZwF/jZzBYvI2kmdZNW5aPoG+SE6GNtN3tJYVHCPfcyER0b2bFfQX
	ByFif2jmWPPz6OdxmAA+vKqm03RQBeBEIjG6EoPuZXC8wduw9DL6GOGdMwIrZ5hBvXb0
	v21Q==
X-Gm-Message-State: ALoCoQmLXUTqfi83jVtG+ZxdQbNwnNmVbM0G4SMLWD8pTFPT6DFCsrn2LfL6YYXOkBSRNqaYgnzv
X-Received: by 10.194.184.199 with SMTP id ew7mr44027741wjc.85.1415802402722; 
	Wed, 12 Nov 2014 06:26:42 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	lp14sm19903375wic.20.2014.11.12.06.26.41 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 12 Nov 2014 06:26:41 -0800 (PST)
Message-ID: <54636E1A.50504@linaro.org>
Date: Wed, 12 Nov 2014 14:26:34 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1414579268.29975.13.camel@citrix.com>		<1414579302-6692-18-git-send-email-ian.campbell@citrix.com>		<21585.6188.366311.80971@mariner.uk.xensource.com>	
	<1414672390.2064.31.camel@citrix.com> <54623E3D.4060803@linaro.org>
	<1415786876.25176.49.camel@citrix.com>
In-Reply-To: <1415786876.25176.49.camel@citrix.com>
Cc: xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH OSSTEST v2 18/20] Osstest/Debian: Add
 "clk_ignore_unused" to default command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 10:07 AM, Ian Campbell wrote:
> On Tue, 2014-11-11 at 17:50 +0100, Julien Grall wrote:
>> Hi,
>>
>> Somehow I missed this email.
>>
>> On 30/10/2014 13:33, Ian Campbell wrote:
>>> create !
>>> title it arm: domain 0 disables clocks which are in fact being used
>>> thanks
>>>
>>> On Wed, 2014-10-29 at 16:39 +0000, Ian Jackson wrote:
>>>> Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
>>>>> This stops dom0 from messing with clocks which it should and is required on
>>>>> some platforms. It's harmless even when not needed.
>>>>
>>>> This is pretty odd.  Doesn't this correspond to some kind of bug, in
>>>> the dom0 kernel perhaps ?
>>>
>>> dom0 is not aware that some clocks are actually in use (e.g. by the
>>> hypervisor), so the bug is probably in the lack of some interface to
>>> communicate this from Xen to dom0, or some other mechanism to gate this.
>>
>> In reality, Xen is only using the clock of the UART. Even though, I 
>> think this would also happen with platform device passthrough.
>>
>> For the latter, it would be fairly easy via a PV drivers. But for 
>> UART... gating the clock could be a nightmare because every platform 
>> have their own way to enable/disable the clock. Futhermore, the clock 
>> could be shared with multiple device...
>>
>> I'm wondering if we could expose the UART to DOM0 without marking as 
>> disabled. It would avoid DOM0 to mess up the clock while everything 
>> would be catch via the vuart implementation in Xen.
> 
> Perhaps we could propagate any clock related properties from the UART
> node into the Xen hypervisor node (or a subnode)? The Xen Linux code
> would then consume those and mark the relevant clocks as in use. I've
> not looked into the clock bindings to know how plausible this might be.

It looks like the bindings for clock is well defined and fairly common
(Documentation/devicetree/bindins/clock/clock-bindings.txt). So your
solution sounds plausible.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:26:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYsg-0004mS-3c; Wed, 12 Nov 2014 14:26:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XoYse-0004mL-IT
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:26:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	48/B3-09842-32E63645; Wed, 12 Nov 2014 14:26:43 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415802402!11872057!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20569 invoked from network); 12 Nov 2014 14:26:43 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:26:42 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so1143195wiw.10
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 06:26:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=jkj4GO5zCAoEu8Qisewzv8UamF1H6RAGQTqcOHsoYT8=;
	b=PUkPfU6UnAeZC3suZRSy3SpjBehJzcpsPB9u/GTAuuJUq7d5b6k/ov40dnLKpyA1tK
	dZqAOk1l1TyrpPyn9LfLHTJrbxGDMdCUusu2MIMM7cSfEWWwWUK5A1IrEeFJA/PY1ODc
	jZf0HKUJJ6Gk8OCvz84QRBBER02qFuwG75bdTleV86WpofAlmKtmNftN9o0dj/TvqVb3
	nwKM8xjDY/ncLF48ZwF/jZzBYvI2kmdZNW5aPoG+SE6GNtN3tJYVHCPfcyER0b2bFfQX
	ByFif2jmWPPz6OdxmAA+vKqm03RQBeBEIjG6EoPuZXC8wduw9DL6GOGdMwIrZ5hBvXb0
	v21Q==
X-Gm-Message-State: ALoCoQmLXUTqfi83jVtG+ZxdQbNwnNmVbM0G4SMLWD8pTFPT6DFCsrn2LfL6YYXOkBSRNqaYgnzv
X-Received: by 10.194.184.199 with SMTP id ew7mr44027741wjc.85.1415802402722; 
	Wed, 12 Nov 2014 06:26:42 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	lp14sm19903375wic.20.2014.11.12.06.26.41 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 12 Nov 2014 06:26:41 -0800 (PST)
Message-ID: <54636E1A.50504@linaro.org>
Date: Wed, 12 Nov 2014 14:26:34 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1414579268.29975.13.camel@citrix.com>		<1414579302-6692-18-git-send-email-ian.campbell@citrix.com>		<21585.6188.366311.80971@mariner.uk.xensource.com>	
	<1414672390.2064.31.camel@citrix.com> <54623E3D.4060803@linaro.org>
	<1415786876.25176.49.camel@citrix.com>
In-Reply-To: <1415786876.25176.49.camel@citrix.com>
Cc: xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH OSSTEST v2 18/20] Osstest/Debian: Add
 "clk_ignore_unused" to default command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 10:07 AM, Ian Campbell wrote:
> On Tue, 2014-11-11 at 17:50 +0100, Julien Grall wrote:
>> Hi,
>>
>> Somehow I missed this email.
>>
>> On 30/10/2014 13:33, Ian Campbell wrote:
>>> create !
>>> title it arm: domain 0 disables clocks which are in fact being used
>>> thanks
>>>
>>> On Wed, 2014-10-29 at 16:39 +0000, Ian Jackson wrote:
>>>> Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
>>>>> This stops dom0 from messing with clocks which it should and is required on
>>>>> some platforms. It's harmless even when not needed.
>>>>
>>>> This is pretty odd.  Doesn't this correspond to some kind of bug, in
>>>> the dom0 kernel perhaps ?
>>>
>>> dom0 is not aware that some clocks are actually in use (e.g. by the
>>> hypervisor), so the bug is probably in the lack of some interface to
>>> communicate this from Xen to dom0, or some other mechanism to gate this.
>>
>> In reality, Xen is only using the clock of the UART. Even though, I 
>> think this would also happen with platform device passthrough.
>>
>> For the latter, it would be fairly easy via a PV drivers. But for 
>> UART... gating the clock could be a nightmare because every platform 
>> have their own way to enable/disable the clock. Futhermore, the clock 
>> could be shared with multiple device...
>>
>> I'm wondering if we could expose the UART to DOM0 without marking as 
>> disabled. It would avoid DOM0 to mess up the clock while everything 
>> would be catch via the vuart implementation in Xen.
> 
> Perhaps we could propagate any clock related properties from the UART
> node into the Xen hypervisor node (or a subnode)? The Xen Linux code
> would then consume those and mark the relevant clocks as in use. I've
> not looked into the clock bindings to know how plausible this might be.

It looks like the bindings for clock is well defined and fairly common
(Documentation/devicetree/bindins/clock/clock-bindings.txt). So your
solution sounds plausible.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:27:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:27:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYtQ-0004qN-HV; Wed, 12 Nov 2014 14:27: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 1XoYtP-0004qB-EJ
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:27:31 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	0C/3A-17958-25E63645; Wed, 12 Nov 2014 14:27:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415802447!10930927!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10265 invoked from network); 12 Nov 2014 14:27:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:27:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190522662"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 09:27:05 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoYsz-0006Jo-HH;
	Wed, 12 Nov 2014 14:27:05 +0000
Date: Wed, 12 Nov 2014 14:27:05 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141112142705.GB31665@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
	<20141112134530.GA31665@zion.uk.xensource.com>
	<546379050200007800046D6A@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546379050200007800046D6A@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 02:13:09PM +0000, Jan Beulich wrote:
> >>> On 12.11.14 at 14:45, <wei.liu2@citrix.com> wrote:
> > On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
> >> >>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
> >> > On 11/11/14 17:36, Wei Liu wrote:
> >> >> Option #1 requires less modification to guest, because guest won't
> >> >> need to switch to new hypercall. It's unclear at this point if a guest
> >> >> asks to populate a gpfn that doesn't belong to any vnode, what Xen
> >> >> should do about it. Should it be permissive or strict? 
> >> > 
> >> > There are XENMEMF flags to request exact node or not  -- leave it up to
> >> > the balloon driver.  The Linux balloon driver could try exact on all
> >> > nodes before falling back to permissive or just always try inexact.
> >> > 
> >> > Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
> >> 
> >> Yes. The only bad thing here is that we don't currently check in the
> >> hypervisor that unknown bits are zero, i.e. code using the new flag
> >> will need to have a separate means to find out whether the bit is
> >> supported. Not a big deal of course.
> >> 
> > 
> > If this new bit is set and domain has vnuma, then it's valid
> > (supported); otherwise it's not.
> > 
> > To not break existing guests, we can fall back to non-vnuma hinted
> > allocation when the new bit is set and vnuma is not available.
> 
> While this is valid, none of this was my point - I was talking about a
> new guest running on an older hypervisor.
> 

That would not cause breakage. Even if the guest sets this new bit it's
ignored by Xen. Guest can still balloon up, though the end result is
sub-optimal.

Question is, do we want to avoid such sub-optimal result?

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:27:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:27:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYtQ-0004qN-HV; Wed, 12 Nov 2014 14:27: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 1XoYtP-0004qB-EJ
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:27:31 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	0C/3A-17958-25E63645; Wed, 12 Nov 2014 14:27:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415802447!10930927!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10265 invoked from network); 12 Nov 2014 14:27:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:27:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190522662"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 09:27:05 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoYsz-0006Jo-HH;
	Wed, 12 Nov 2014 14:27:05 +0000
Date: Wed, 12 Nov 2014 14:27:05 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141112142705.GB31665@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
	<20141112134530.GA31665@zion.uk.xensource.com>
	<546379050200007800046D6A@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546379050200007800046D6A@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 02:13:09PM +0000, Jan Beulich wrote:
> >>> On 12.11.14 at 14:45, <wei.liu2@citrix.com> wrote:
> > On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
> >> >>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
> >> > On 11/11/14 17:36, Wei Liu wrote:
> >> >> Option #1 requires less modification to guest, because guest won't
> >> >> need to switch to new hypercall. It's unclear at this point if a guest
> >> >> asks to populate a gpfn that doesn't belong to any vnode, what Xen
> >> >> should do about it. Should it be permissive or strict? 
> >> > 
> >> > There are XENMEMF flags to request exact node or not  -- leave it up to
> >> > the balloon driver.  The Linux balloon driver could try exact on all
> >> > nodes before falling back to permissive or just always try inexact.
> >> > 
> >> > Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
> >> 
> >> Yes. The only bad thing here is that we don't currently check in the
> >> hypervisor that unknown bits are zero, i.e. code using the new flag
> >> will need to have a separate means to find out whether the bit is
> >> supported. Not a big deal of course.
> >> 
> > 
> > If this new bit is set and domain has vnuma, then it's valid
> > (supported); otherwise it's not.
> > 
> > To not break existing guests, we can fall back to non-vnuma hinted
> > allocation when the new bit is set and vnuma is not available.
> 
> While this is valid, none of this was my point - I was talking about a
> new guest running on an older hypervisor.
> 

That would not cause breakage. Even if the guest sets this new bit it's
ignored by Xen. Guest can still balloon up, though the end result is
sub-optimal.

Question is, do we want to avoid such sub-optimal result?

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:30:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:30:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYw0-00050q-3W; Wed, 12 Nov 2014 14:30:12 +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 1XoYvr-00050V-4T
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:30:10 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	F6/64-14727-AEE63645; Wed, 12 Nov 2014 14:30:02 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415802599!10950673!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16213 invoked from network); 12 Nov 2014 14:30:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:30:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190523684"
Message-ID: <54636EE4.7030001@citrix.com>
Date: Wed, 12 Nov 2014 14:29:56 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
	<20141112134530.GA31665@zion.uk.xensource.com>
	<546379050200007800046D6A@mail.emea.novell.com>
	<20141112142705.GB31665@zion.uk.xensource.com>
In-Reply-To: <20141112142705.GB31665@zion.uk.xensource.com>
X-DLP: MIA2
Cc: Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 14:27, Wei Liu wrote:
> On Wed, Nov 12, 2014 at 02:13:09PM +0000, Jan Beulich wrote:
>>>>> On 12.11.14 at 14:45, <wei.liu2@citrix.com> wrote:
>>> On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
>>>>>>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
>>>>> On 11/11/14 17:36, Wei Liu wrote:
>>>>>> Option #1 requires less modification to guest, because guest won't
>>>>>> need to switch to new hypercall. It's unclear at this point if a guest
>>>>>> asks to populate a gpfn that doesn't belong to any vnode, what Xen
>>>>>> should do about it. Should it be permissive or strict? 
>>>>>
>>>>> There are XENMEMF flags to request exact node or not  -- leave it up to
>>>>> the balloon driver.  The Linux balloon driver could try exact on all
>>>>> nodes before falling back to permissive or just always try inexact.
>>>>>
>>>>> Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
>>>>
>>>> Yes. The only bad thing here is that we don't currently check in the
>>>> hypervisor that unknown bits are zero, i.e. code using the new flag
>>>> will need to have a separate means to find out whether the bit is
>>>> supported. Not a big deal of course.
>>>>
>>>
>>> If this new bit is set and domain has vnuma, then it's valid
>>> (supported); otherwise it's not.
>>>
>>> To not break existing guests, we can fall back to non-vnuma hinted
>>> allocation when the new bit is set and vnuma is not available.
>>
>> While this is valid, none of this was my point - I was talking about a
>> new guest running on an older hypervisor.
>>
> 
> That would not cause breakage. Even if the guest sets this new bit it's
> ignored by Xen. Guest can still balloon up, though the end result is
> sub-optimal.

No. Because it will get memory allocated from the specified /physical/
node which would be quite wrong.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:30:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:30:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoYw0-00050q-3W; Wed, 12 Nov 2014 14:30:12 +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 1XoYvr-00050V-4T
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:30:10 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	F6/64-14727-AEE63645; Wed, 12 Nov 2014 14:30:02 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415802599!10950673!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16213 invoked from network); 12 Nov 2014 14:30:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:30:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190523684"
Message-ID: <54636EE4.7030001@citrix.com>
Date: Wed, 12 Nov 2014 14:29:56 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
	<20141112134530.GA31665@zion.uk.xensource.com>
	<546379050200007800046D6A@mail.emea.novell.com>
	<20141112142705.GB31665@zion.uk.xensource.com>
In-Reply-To: <20141112142705.GB31665@zion.uk.xensource.com>
X-DLP: MIA2
Cc: Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 14:27, Wei Liu wrote:
> On Wed, Nov 12, 2014 at 02:13:09PM +0000, Jan Beulich wrote:
>>>>> On 12.11.14 at 14:45, <wei.liu2@citrix.com> wrote:
>>> On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
>>>>>>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
>>>>> On 11/11/14 17:36, Wei Liu wrote:
>>>>>> Option #1 requires less modification to guest, because guest won't
>>>>>> need to switch to new hypercall. It's unclear at this point if a guest
>>>>>> asks to populate a gpfn that doesn't belong to any vnode, what Xen
>>>>>> should do about it. Should it be permissive or strict? 
>>>>>
>>>>> There are XENMEMF flags to request exact node or not  -- leave it up to
>>>>> the balloon driver.  The Linux balloon driver could try exact on all
>>>>> nodes before falling back to permissive or just always try inexact.
>>>>>
>>>>> Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
>>>>
>>>> Yes. The only bad thing here is that we don't currently check in the
>>>> hypervisor that unknown bits are zero, i.e. code using the new flag
>>>> will need to have a separate means to find out whether the bit is
>>>> supported. Not a big deal of course.
>>>>
>>>
>>> If this new bit is set and domain has vnuma, then it's valid
>>> (supported); otherwise it's not.
>>>
>>> To not break existing guests, we can fall back to non-vnuma hinted
>>> allocation when the new bit is set and vnuma is not available.
>>
>> While this is valid, none of this was my point - I was talking about a
>> new guest running on an older hypervisor.
>>
> 
> That would not cause breakage. Even if the guest sets this new bit it's
> ignored by Xen. Guest can still balloon up, though the end result is
> sub-optimal.

No. Because it will get memory allocated from the specified /physical/
node which would be quite wrong.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:36:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:36:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZ2O-0005J4-Vi; Wed, 12 Nov 2014 14:36:48 +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 1XoZ2N-0005Iz-QW
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 14:36:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/31-09936-F7073645; Wed, 12 Nov 2014 14:36:47 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415803005!11875066!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7578 invoked from network); 12 Nov 2014 14:36:46 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 14:36:46 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACEaf0H023996
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 14:36:41 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACEaeRR011997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 14:36:40 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACEadgl011980; Wed, 12 Nov 2014 14:36:40 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 06:36:39 -0800
Message-ID: <54637076.7060708@oracle.com>
Date: Wed, 12 Nov 2014 09:36:38 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
In-Reply-To: <20141112113156.GA28075@zion.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/12/2014 06:31 AM, Wei Liu wrote:
> On Tue, Nov 11, 2014 at 11:42:04AM -0500, Zhigang Wang wrote:
>> On 11/11/2014 10:20 AM, Wei Liu wrote:
>>> On Tue, Nov 11, 2014 at 09:41:32AM -0500, Zhigang Wang wrote:
>>>> On 11/11/2014 06:01 AM, Wei Liu wrote:
>>>>> On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
>>>>> [...]
>>>>>> Could you please explain what does "no configuration" means?
>>>>>>
>>>>>> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
>>>>>>
>>>>>
>>>>> That means no configuration at all. I think a skeleton can be provided
>>>>> at best (in xl level) to be consistent with "xl list", which should
>>>>> include domid and domain name etc. Since nothing else exists in
>>>>> xenstore yet, there's no point poking there.
>>>>
>>>> This approach should works for me.
>>>>
>>>>> [...]
>>>>>> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
>>>>>>
>>>>>
>>>>> Hmm... I don't think poking around in different places is a good idea.
>>>>> This is prone to breakage in the future.
>>>>
>>>> I agree.
>>>>  
>>>>> Since xenstore is not filled in when your tool looks at it, what makes
>>>>> it different to wait a bit until migration finishes?
>>>>
>>>> The logic is: when migration started, high level management console will check
>>>> destination side to make sure the VM is running there 
>>>> (currently call xl list -l <domain>).
>>>>
>>>> If I can get enough runtime info (even some are missing), I think it should be OK.
>>>>
>>>
>>> What runtime info do you need?
>>
>> Currently we need:
>>
>>   info['domid']
>>   info['config']['b_info']['avail_vcpus']
>>   info['config']['c_info']['uuid']
>>   info['config']['b_info']['target_memkb']
>>
>> Also read vnc port from xenstore.  
>>
> 
> Unfortunately this won't work, as not everything you need is in xenstore
> at that point (see the xenstore entries you posted). It's not something
> that can be easily worked around in xl by creating a stub -- even the
> stub needs to get its information from somewhere.
...
>> We may add more.
>>
> 
> This also means even if we create a stub now, it's still prone to
> breakage in the future.
> 
> I think the root cause of your problem is xend and libxl fires
> @introduceDomain at different point (correct me if I'm wrong, because I
> haven't looked at xend code, only inferred from your reply). It should
> be fixed there, not patching xl.

For above I just want to give you an idea what we currently using for normal VM.

For VM under migration, please see below:

>> But during migration, I believe it's OK if some info is missing. Our high level
>> management stack will handle it.

Also I want clarify one thing: the @introduceDomain watch is triggered at the same
time for xm/xend and xl: when VM fully migrated.

The different between xm/xend and xl is: xend will populate destination side VM 
xenstore entries at the beginning of migration. So xm list -l will show almost
the same result as normal VM.

I think right now we can just add little wrapper in xl cli to let xl list -l show
some info we can get.

Then we have 3 cases in xl list -l:

1. Normal VM.
2. Dom0.
3. VM under migration in the destination side.

They all valid json and 2), 3) are subset of 1). I can accept this design for now.

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:36:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:36:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZ2O-0005J4-Vi; Wed, 12 Nov 2014 14:36:48 +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 1XoZ2N-0005Iz-QW
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 14:36:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/31-09936-F7073645; Wed, 12 Nov 2014 14:36:47 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415803005!11875066!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7578 invoked from network); 12 Nov 2014 14:36:46 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 14:36:46 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACEaf0H023996
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 14:36:41 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACEaeRR011997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 14:36:40 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACEadgl011980; Wed, 12 Nov 2014 14:36:40 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 06:36:39 -0800
Message-ID: <54637076.7060708@oracle.com>
Date: Wed, 12 Nov 2014 09:36:38 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
In-Reply-To: <20141112113156.GA28075@zion.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/12/2014 06:31 AM, Wei Liu wrote:
> On Tue, Nov 11, 2014 at 11:42:04AM -0500, Zhigang Wang wrote:
>> On 11/11/2014 10:20 AM, Wei Liu wrote:
>>> On Tue, Nov 11, 2014 at 09:41:32AM -0500, Zhigang Wang wrote:
>>>> On 11/11/2014 06:01 AM, Wei Liu wrote:
>>>>> On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote:
>>>>> [...]
>>>>>> Could you please explain what does "no configuration" means?
>>>>>>
>>>>>> Do you mean no info for the domain at all? If this is the case, it seems not consistent with xl list without -l.
>>>>>>
>>>>>
>>>>> That means no configuration at all. I think a skeleton can be provided
>>>>> at best (in xl level) to be consistent with "xl list", which should
>>>>> include domid and domain name etc. Since nothing else exists in
>>>>> xenstore yet, there's no point poking there.
>>>>
>>>> This approach should works for me.
>>>>
>>>>> [...]
>>>>>> Currently we want our APIs to get domain info by invoking xl list -l, but we can change them to get necessary info from other places.
>>>>>>
>>>>>
>>>>> Hmm... I don't think poking around in different places is a good idea.
>>>>> This is prone to breakage in the future.
>>>>
>>>> I agree.
>>>>  
>>>>> Since xenstore is not filled in when your tool looks at it, what makes
>>>>> it different to wait a bit until migration finishes?
>>>>
>>>> The logic is: when migration started, high level management console will check
>>>> destination side to make sure the VM is running there 
>>>> (currently call xl list -l <domain>).
>>>>
>>>> If I can get enough runtime info (even some are missing), I think it should be OK.
>>>>
>>>
>>> What runtime info do you need?
>>
>> Currently we need:
>>
>>   info['domid']
>>   info['config']['b_info']['avail_vcpus']
>>   info['config']['c_info']['uuid']
>>   info['config']['b_info']['target_memkb']
>>
>> Also read vnc port from xenstore.  
>>
> 
> Unfortunately this won't work, as not everything you need is in xenstore
> at that point (see the xenstore entries you posted). It's not something
> that can be easily worked around in xl by creating a stub -- even the
> stub needs to get its information from somewhere.
...
>> We may add more.
>>
> 
> This also means even if we create a stub now, it's still prone to
> breakage in the future.
> 
> I think the root cause of your problem is xend and libxl fires
> @introduceDomain at different point (correct me if I'm wrong, because I
> haven't looked at xend code, only inferred from your reply). It should
> be fixed there, not patching xl.

For above I just want to give you an idea what we currently using for normal VM.

For VM under migration, please see below:

>> But during migration, I believe it's OK if some info is missing. Our high level
>> management stack will handle it.

Also I want clarify one thing: the @introduceDomain watch is triggered at the same
time for xm/xend and xl: when VM fully migrated.

The different between xm/xend and xl is: xend will populate destination side VM 
xenstore entries at the beginning of migration. So xm list -l will show almost
the same result as normal VM.

I think right now we can just add little wrapper in xl cli to let xl list -l show
some info we can get.

Then we have 3 cases in xl list -l:

1. Normal VM.
2. Dom0.
3. VM under migration in the destination side.

They all valid json and 2), 3) are subset of 1). I can accept this design for now.

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:40:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14: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 1XoZ60-0005SJ-Os; Wed, 12 Nov 2014 14:40:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoZ5z-0005SD-7w
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 14:40:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	67/79-09936-E5173645; Wed, 12 Nov 2014 14:40:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415803227!4187787!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9705 invoked from network); 12 Nov 2014 14:40:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:40:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="191977135"
Message-ID: <1415803209.1155.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 12 Nov 2014 14:40:09 +0000
In-Reply-To: <54637076.7060708@oracle.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
> time for xm/xend and xl: when VM fully migrated.
> 
> The different between xm/xend and xl is: xend will populate destination side VM 
> xenstore entries at the beginning of migration.

Do you mean *before* @introduceDomain has triggered?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:40:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14: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 1XoZ60-0005SJ-Os; Wed, 12 Nov 2014 14:40:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoZ5z-0005SD-7w
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 14:40:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	67/79-09936-E5173645; Wed, 12 Nov 2014 14:40:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415803227!4187787!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9705 invoked from network); 12 Nov 2014 14:40:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:40:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="191977135"
Message-ID: <1415803209.1155.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 12 Nov 2014 14:40:09 +0000
In-Reply-To: <54637076.7060708@oracle.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
> time for xm/xend and xl: when VM fully migrated.
> 
> The different between xm/xend and xl is: xend will populate destination side VM 
> xenstore entries at the beginning of migration.

Do you mean *before* @introduceDomain has triggered?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:41:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:41:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZ6X-0005VT-5Q; Wed, 12 Nov 2014 14:41:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoZ6V-0005VD-Ox
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:41:03 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	69/17-02699-F7173645; Wed, 12 Nov 2014 14:41:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415803258!8737339!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20510 invoked from network); 12 Nov 2014 14:41:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:41:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="191977467"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 09:40:58 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoZ6P-0006ar-QT;
	Wed, 12 Nov 2014 14:40:57 +0000
Date: Wed, 12 Nov 2014 14:40:57 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141112144057.GC31665@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
	<20141112134530.GA31665@zion.uk.xensource.com>
	<546379050200007800046D6A@mail.emea.novell.com>
	<20141112142705.GB31665@zion.uk.xensource.com>
	<54636EE4.7030001@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54636EE4.7030001@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 02:29:56PM +0000, David Vrabel wrote:
> On 12/11/14 14:27, Wei Liu wrote:
> > On Wed, Nov 12, 2014 at 02:13:09PM +0000, Jan Beulich wrote:
> >>>>> On 12.11.14 at 14:45, <wei.liu2@citrix.com> wrote:
> >>> On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
> >>>>>>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
> >>>>> On 11/11/14 17:36, Wei Liu wrote:
> >>>>>> Option #1 requires less modification to guest, because guest won't
> >>>>>> need to switch to new hypercall. It's unclear at this point if a guest
> >>>>>> asks to populate a gpfn that doesn't belong to any vnode, what Xen
> >>>>>> should do about it. Should it be permissive or strict? 
> >>>>>
> >>>>> There are XENMEMF flags to request exact node or not  -- leave it up to
> >>>>> the balloon driver.  The Linux balloon driver could try exact on all
> >>>>> nodes before falling back to permissive or just always try inexact.
> >>>>>
> >>>>> Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
> >>>>
> >>>> Yes. The only bad thing here is that we don't currently check in the
> >>>> hypervisor that unknown bits are zero, i.e. code using the new flag
> >>>> will need to have a separate means to find out whether the bit is
> >>>> supported. Not a big deal of course.
> >>>>
> >>>
> >>> If this new bit is set and domain has vnuma, then it's valid
> >>> (supported); otherwise it's not.
> >>>
> >>> To not break existing guests, we can fall back to non-vnuma hinted
> >>> allocation when the new bit is set and vnuma is not available.
> >>
> >> While this is valid, none of this was my point - I was talking about a
> >> new guest running on an older hypervisor.
> >>
> > 
> > That would not cause breakage. Even if the guest sets this new bit it's
> > ignored by Xen. Guest can still balloon up, though the end result is
> > sub-optimal.
> 
> No. Because it will get memory allocated from the specified /physical/
> node which would be quite wrong.
> 

Fair enough.

So what's the "usual technique" in Linux to make sure if a specific
Xen feature is present?

Jan, is it suitable to use a XENFEAT_* bit for this?

Wei.

> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:41:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:41:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZ6X-0005VT-5Q; Wed, 12 Nov 2014 14:41:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XoZ6V-0005VD-Ox
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:41:03 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	69/17-02699-F7173645; Wed, 12 Nov 2014 14:41:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415803258!8737339!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20510 invoked from network); 12 Nov 2014 14:41:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:41:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="191977467"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 09:40:58 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoZ6P-0006ar-QT;
	Wed, 12 Nov 2014 14:40:57 +0000
Date: Wed, 12 Nov 2014 14:40:57 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141112144057.GC31665@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
	<20141112134530.GA31665@zion.uk.xensource.com>
	<546379050200007800046D6A@mail.emea.novell.com>
	<20141112142705.GB31665@zion.uk.xensource.com>
	<54636EE4.7030001@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54636EE4.7030001@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 02:29:56PM +0000, David Vrabel wrote:
> On 12/11/14 14:27, Wei Liu wrote:
> > On Wed, Nov 12, 2014 at 02:13:09PM +0000, Jan Beulich wrote:
> >>>>> On 12.11.14 at 14:45, <wei.liu2@citrix.com> wrote:
> >>> On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
> >>>>>>> On 11.11.14 at 19:03, <david.vrabel@citrix.com> wrote:
> >>>>> On 11/11/14 17:36, Wei Liu wrote:
> >>>>>> Option #1 requires less modification to guest, because guest won't
> >>>>>> need to switch to new hypercall. It's unclear at this point if a guest
> >>>>>> asks to populate a gpfn that doesn't belong to any vnode, what Xen
> >>>>>> should do about it. Should it be permissive or strict? 
> >>>>>
> >>>>> There are XENMEMF flags to request exact node or not  -- leave it up to
> >>>>> the balloon driver.  The Linux balloon driver could try exact on all
> >>>>> nodes before falling back to permissive or just always try inexact.
> >>>>>
> >>>>> Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
> >>>>
> >>>> Yes. The only bad thing here is that we don't currently check in the
> >>>> hypervisor that unknown bits are zero, i.e. code using the new flag
> >>>> will need to have a separate means to find out whether the bit is
> >>>> supported. Not a big deal of course.
> >>>>
> >>>
> >>> If this new bit is set and domain has vnuma, then it's valid
> >>> (supported); otherwise it's not.
> >>>
> >>> To not break existing guests, we can fall back to non-vnuma hinted
> >>> allocation when the new bit is set and vnuma is not available.
> >>
> >> While this is valid, none of this was my point - I was talking about a
> >> new guest running on an older hypervisor.
> >>
> > 
> > That would not cause breakage. Even if the guest sets this new bit it's
> > ignored by Xen. Guest can still balloon up, though the end result is
> > sub-optimal.
> 
> No. Because it will get memory allocated from the specified /physical/
> node which would be quite wrong.
> 

Fair enough.

So what's the "usual technique" in Linux to make sure if a specific
Xen feature is present?

Jan, is it suitable to use a XENFEAT_* bit for this?

Wei.

> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:48:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:48:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZDY-0005r9-2X; Wed, 12 Nov 2014 14:48:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XoZDX-0005r4-Bj
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 14:48:19 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	C9/20-14214-23373645; Wed, 12 Nov 2014 14:48:18 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415803696!10907185!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30391 invoked from network); 12 Nov 2014 14:48:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 14:48:18 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACEm9bI007849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 14:48:10 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACEm8n6022083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 14:48:09 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACEm7HA016285; Wed, 12 Nov 2014 14:48:08 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 06:48:07 -0800
Message-ID: <54637326.6090908@oracle.com>
Date: Wed, 12 Nov 2014 09:48:06 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com> <1415803209.1155.10.camel@citrix.com>
In-Reply-To: <1415803209.1155.10.camel@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/12/2014 09:40 AM, Ian Campbell wrote:
> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
>> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
>> time for xm/xend and xl: when VM fully migrated.
>>
>> The different between xm/xend and xl is: xend will populate destination side VM 
>> xenstore entries at the beginning of migration.
> 
> Do you mean *before* @introduceDomain has triggered?

Yes, from my test. I didn't check the code logic yet.

I designed a test: set eth0 to low speed:

    $ ethtool -s eth0 speed 10 duplex half

and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).

Thanks,

Zhigang




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:48:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14:48:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZDY-0005r9-2X; Wed, 12 Nov 2014 14:48:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XoZDX-0005r4-Bj
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 14:48:19 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	C9/20-14214-23373645; Wed, 12 Nov 2014 14:48:18 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415803696!10907185!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30391 invoked from network); 12 Nov 2014 14:48:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 14:48:18 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACEm9bI007849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 14:48:10 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACEm8n6022083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 14:48:09 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACEm7HA016285; Wed, 12 Nov 2014 14:48:08 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 06:48:07 -0800
Message-ID: <54637326.6090908@oracle.com>
Date: Wed, 12 Nov 2014 09:48:06 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com> <1415803209.1155.10.camel@citrix.com>
In-Reply-To: <1415803209.1155.10.camel@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/12/2014 09:40 AM, Ian Campbell wrote:
> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
>> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
>> time for xm/xend and xl: when VM fully migrated.
>>
>> The different between xm/xend and xl is: xend will populate destination side VM 
>> xenstore entries at the beginning of migration.
> 
> Do you mean *before* @introduceDomain has triggered?

Yes, from my test. I didn't check the code logic yet.

I designed a test: set eth0 to low speed:

    $ ethtool -s eth0 speed 10 duplex half

and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).

Thanks,

Zhigang




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:53:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14: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 1XoZIA-00066U-Pb; Wed, 12 Nov 2014 14:53:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoZI9-00066P-4F
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 14:53:05 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	2C/FD-22819-05473645; Wed, 12 Nov 2014 14:53:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415803980!8032249!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4900 invoked from network); 12 Nov 2014 14:53:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:53:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="191981856"
Message-ID: <1415803976.1155.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 12 Nov 2014 14:52:56 +0000
In-Reply-To: <54637326.6090908@oracle.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com> <1415803209.1155.10.camel@citrix.com>
	<54637326.6090908@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> >> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
> >> time for xm/xend and xl: when VM fully migrated.
> >>
> >> The different between xm/xend and xl is: xend will populate destination side VM 
> >> xenstore entries at the beginning of migration.
> > 
> > Do you mean *before* @introduceDomain has triggered?
> 
> Yes, from my test. I didn't check the code logic yet.

I think anything which is trying to inspect the state of a domain before
the corresponding @introduceDomain and expecting anything more complex
than the fact of that domain's existence is broken.

IOW the json associated with such a domain should be:
    {
        "domid": 123,
        "config": {}
    }
Or even
    {
        "domid": 123,
    }

No more or less.

> I designed a test: set eth0 to low speed:
> 
>     $ ethtool -s eth0 speed 10 duplex half
> 
> and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).

A couple of minutes after *starting* the migration (i.e. the couple of
minutes is just the time taken to migrate) or a couple of minutes after
*finishing* the migration (which would be unfortunate and should be
investigated).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:53:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 14: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 1XoZIA-00066U-Pb; Wed, 12 Nov 2014 14:53:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoZI9-00066P-4F
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 14:53:05 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	2C/FD-22819-05473645; Wed, 12 Nov 2014 14:53:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415803980!8032249!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4900 invoked from network); 12 Nov 2014 14:53:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 14:53:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="191981856"
Message-ID: <1415803976.1155.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 12 Nov 2014 14:52:56 +0000
In-Reply-To: <54637326.6090908@oracle.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com> <1415803209.1155.10.camel@citrix.com>
	<54637326.6090908@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> >> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
> >> time for xm/xend and xl: when VM fully migrated.
> >>
> >> The different between xm/xend and xl is: xend will populate destination side VM 
> >> xenstore entries at the beginning of migration.
> > 
> > Do you mean *before* @introduceDomain has triggered?
> 
> Yes, from my test. I didn't check the code logic yet.

I think anything which is trying to inspect the state of a domain before
the corresponding @introduceDomain and expecting anything more complex
than the fact of that domain's existence is broken.

IOW the json associated with such a domain should be:
    {
        "domid": 123,
        "config": {}
    }
Or even
    {
        "domid": 123,
    }

No more or less.

> I designed a test: set eth0 to low speed:
> 
>     $ ethtool -s eth0 speed 10 duplex half
> 
> and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).

A couple of minutes after *starting* the migration (i.e. the couple of
minutes is just the time taken to migrate) or a couple of minutes after
*finishing* the migration (which would be unfortunate and should be
investigated).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:54:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1XoZJH-0006Ay-7L; Wed, 12 Nov 2014 14:54:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoZJF-0006Aq-VI
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:54:14 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5F/91-02702-59473645; Wed, 12 Nov 2014 14:54:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415804051!12075189!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14778 invoked from network); 12 Nov 2014 14:54:11 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 14:54:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 14:54:11 +0000
Message-Id: <546382A20200007800046DB0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 14:54:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
	<20141112134530.GA31665@zion.uk.xensource.com>
	<546379050200007800046D6A@mail.emea.novell.com>
	<20141112142705.GB31665@zion.uk.xensource.com>
	<54636EE4.7030001@citrix.com>
	<20141112144057.GC31665@zion.uk.xensource.com>
In-Reply-To: <20141112144057.GC31665@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: DarioFaggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 15:40, <wei.liu2@citrix.com> wrote:
> So what's the "usual technique" in Linux to make sure if a specific
> Xen feature is present?
> 
> Jan, is it suitable to use a XENFEAT_* bit for this?

Yes, that would be the canonical way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 14:54:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1XoZJH-0006Ay-7L; Wed, 12 Nov 2014 14:54:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoZJF-0006Aq-VI
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 14:54:14 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5F/91-02702-59473645; Wed, 12 Nov 2014 14:54:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415804051!12075189!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14778 invoked from network); 12 Nov 2014 14:54:11 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 14:54:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 14:54:11 +0000
Message-Id: <546382A20200007800046DB0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 14:54:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<546337D50200007800046B2F@mail.emea.novell.com>
	<20141112134530.GA31665@zion.uk.xensource.com>
	<546379050200007800046D6A@mail.emea.novell.com>
	<20141112142705.GB31665@zion.uk.xensource.com>
	<54636EE4.7030001@citrix.com>
	<20141112144057.GC31665@zion.uk.xensource.com>
In-Reply-To: <20141112144057.GC31665@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: DarioFaggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 15:40, <wei.liu2@citrix.com> wrote:
> So what's the "usual technique" in Linux to make sure if a specific
> Xen feature is present?
> 
> Jan, is it suitable to use a XENFEAT_* bit for this?

Yes, that would be the canonical way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:05:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:05:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZTR-0006XR-EJ; Wed, 12 Nov 2014 15:04:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XoZTQ-0006XM-OD
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:04:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	07/69-09842-C0773645; Wed, 12 Nov 2014 15:04:44 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415804682!8782795!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6971 invoked from network); 12 Nov 2014 15:04:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 15:04:43 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACF4cCn004379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 15:04:39 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACF4aOM029512
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 15:04:38 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACF4Zcn000880; Wed, 12 Nov 2014 15:04:36 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 07:04:35 -0800
Message-ID: <54637703.80906@oracle.com>
Date: Wed, 12 Nov 2014 10:04:35 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com> <1415803209.1155.10.camel@citrix.com>
	<54637326.6090908@oracle.com> <1415803976.1155.14.camel@citrix.com>
In-Reply-To: <1415803976.1155.14.camel@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/12/2014 09:52 AM, Ian Campbell wrote:
> On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
>> On 11/12/2014 09:40 AM, Ian Campbell wrote:
>>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
>>>> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
>>>> time for xm/xend and xl: when VM fully migrated.
>>>>
>>>> The different between xm/xend and xl is: xend will populate destination side VM 
>>>> xenstore entries at the beginning of migration.
>>>
>>> Do you mean *before* @introduceDomain has triggered?
>>
>> Yes, from my test. I didn't check the code logic yet.
> 
> I think anything which is trying to inspect the state of a domain before
> the corresponding @introduceDomain and expecting anything more complex
> than the fact of that domain's existence is broken.
...
> IOW the json associated with such a domain should be:
>     {
>         "domid": 123,
>         "config": {}
>     }
> Or even
>     {
>         "domid": 123,
>     }
> 
> No more or less.

Here is the xl list output:

    # xl list
    Name                                          ID   Mem VCPUs      State   Time(s)
    Domain-0                                       0   856     4     r-----    2758.9
    0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0

So we don't even want to match the two results?
 
>> I designed a test: set eth0 to low speed:
>>
>>     $ ethtool -s eth0 speed 10 duplex half
>>
>> and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).
> 
> A couple of minutes after *starting* the migration (i.e. the couple of
> minutes is just the time taken to migrate) or a couple of minutes after
> *finishing* the migration (which would be unfortunate and should be
> investigated).

Sorry I didn't say it clearly. I mean couple minutes after the migration started, but before the migration finish.

>From xend code xend/XendDomainInfo.py:


    def completeRestore(self, store_mfn, console_mfn):

        log.debug("XendDomainInfo.completeRestore")

        self.store_mfn = store_mfn
        self.console_mfn = console_mfn

        self._introduceDomain()
        self.image = image.create(self, self.info)
        if self.image:
            self.image.createDeviceModel(True)
        self._storeDomDetails()
        self._registerWatches()
        self.refreshShutdown()

        log.debug("XendDomainInfo.completeRestore done")

It seems the self._introduceDomain() does called at the end of migration after memory transfer.

Thanks,

Zhigang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:05:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:05:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZTR-0006XR-EJ; Wed, 12 Nov 2014 15:04:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XoZTQ-0006XM-OD
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:04:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	07/69-09842-C0773645; Wed, 12 Nov 2014 15:04:44 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415804682!8782795!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6971 invoked from network); 12 Nov 2014 15:04:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 15:04:43 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACF4cCn004379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 15:04:39 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACF4aOM029512
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 15:04:38 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACF4Zcn000880; Wed, 12 Nov 2014 15:04:36 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 07:04:35 -0800
Message-ID: <54637703.80906@oracle.com>
Date: Wed, 12 Nov 2014 10:04:35 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com> <1415803209.1155.10.camel@citrix.com>
	<54637326.6090908@oracle.com> <1415803976.1155.14.camel@citrix.com>
In-Reply-To: <1415803976.1155.14.camel@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 11/12/2014 09:52 AM, Ian Campbell wrote:
> On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
>> On 11/12/2014 09:40 AM, Ian Campbell wrote:
>>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
>>>> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
>>>> time for xm/xend and xl: when VM fully migrated.
>>>>
>>>> The different between xm/xend and xl is: xend will populate destination side VM 
>>>> xenstore entries at the beginning of migration.
>>>
>>> Do you mean *before* @introduceDomain has triggered?
>>
>> Yes, from my test. I didn't check the code logic yet.
> 
> I think anything which is trying to inspect the state of a domain before
> the corresponding @introduceDomain and expecting anything more complex
> than the fact of that domain's existence is broken.
...
> IOW the json associated with such a domain should be:
>     {
>         "domid": 123,
>         "config": {}
>     }
> Or even
>     {
>         "domid": 123,
>     }
> 
> No more or less.

Here is the xl list output:

    # xl list
    Name                                          ID   Mem VCPUs      State   Time(s)
    Domain-0                                       0   856     4     r-----    2758.9
    0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0

So we don't even want to match the two results?
 
>> I designed a test: set eth0 to low speed:
>>
>>     $ ethtool -s eth0 speed 10 duplex half
>>
>> and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).
> 
> A couple of minutes after *starting* the migration (i.e. the couple of
> minutes is just the time taken to migrate) or a couple of minutes after
> *finishing* the migration (which would be unfortunate and should be
> investigated).

Sorry I didn't say it clearly. I mean couple minutes after the migration started, but before the migration finish.

>From xend code xend/XendDomainInfo.py:


    def completeRestore(self, store_mfn, console_mfn):

        log.debug("XendDomainInfo.completeRestore")

        self.store_mfn = store_mfn
        self.console_mfn = console_mfn

        self._introduceDomain()
        self.image = image.create(self, self.info)
        if self.image:
            self.image.createDeviceModel(True)
        self._storeDomDetails()
        self._registerWatches()
        self.refreshShutdown()

        log.debug("XendDomainInfo.completeRestore done")

It seems the self._introduceDomain() does called at the end of migration after memory transfer.

Thanks,

Zhigang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZnk-000723-KL; Wed, 12 Nov 2014 15:25:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoZnj-00071h-4w
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:25:43 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	A7/9A-17694-6FB73645; Wed, 12 Nov 2014 15:25:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415805939!10782016!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21715 invoked from network); 12 Nov 2014 15:25:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:25:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190548030"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:25:28 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XoZnU-0007Pj-DG;
	Wed, 12 Nov 2014 15:25:28 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 12 Nov 2014 15:25:05 +0000
Message-ID: <1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to be
	overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 dma_ops->get_required_mask() if provided, defaulting to
dma_get_requried_mask_from_max_pfn().

This is needed on systems (such as Xen PV guests) where the DMA
address and the physical address are not equal.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/device.h |    2 ++
 arch/x86/kernel/pci-dma.c     |    8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
index 03dd729..10bc628 100644
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
 struct pdev_archdata {
 };
 
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
+
 #endif /* _ASM_X86_DEVICE_H */
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index a25e202..5154400 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -140,6 +140,14 @@ void dma_generic_free_coherent(struct device *dev, size_t size, void *vaddr,
 		free_pages((unsigned long)vaddr, get_order(size));
 }
 
+u64 dma_get_required_mask(struct device *dev)
+{
+	if (dma_ops->get_required_mask)
+		return dma_ops->get_required_mask(dev);
+	return dma_get_required_mask_from_max_pfn(dev);
+}
+EXPORT_SYMBOL_GPL(dma_get_required_mask);
+
 /*
  * See <Documentation/x86/x86_64/boot-options.txt> for the iommu kernel
  * parameter documentation.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZnl-00072O-Lx; Wed, 12 Nov 2014 15:25:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoZnj-00071o-W8
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:25:44 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	9D/9A-17694-7FB73645; Wed, 12 Nov 2014 15:25:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415805939!10782016!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21838 invoked from network); 12 Nov 2014 15:25:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:25:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190548031"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:25:28 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XoZnU-0007Pj-Dp;
	Wed, 12 Nov 2014 15:25:28 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 12 Nov 2014 15:25:06 +0000
Message-ID: <1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to calculate
	the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to
use only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

Provide a get_required_mask op that uses the maximum MFN to calculate
the DMA mask.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    1 +
 drivers/xen/swiotlb-xen.c      |   13 +++++++++++++
 include/xen/swiotlb-xen.h      |    4 ++++
 3 files changed, 18 insertions(+)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 0e98e5d..a5d180a 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -31,6 +31,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.map_page = xen_swiotlb_map_page,
 	.unmap_page = xen_swiotlb_unmap_page,
 	.dma_supported = xen_swiotlb_dma_supported,
+	.get_required_mask = xen_swiotlb_get_required_mask,
 };
 
 /*
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..472fd52 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -42,9 +42,11 @@
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 #include <xen/hvc-console.h>
+#include <xen/interface/memory.h>
 
 #include <asm/dma-mapping.h>
 #include <asm/xen/page-coherent.h>
+#include <asm/xen/hypercall.h>
 
 #include <trace/events/swiotlb.h>
 /*
@@ -683,3 +685,14 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
+
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+	u64 max_mfn;
+
+	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
+
+	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 8b2eb93..6408888 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -58,4 +58,8 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
 
 extern int
 xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
+
+extern u64
+xen_swiotlb_get_required_mask(struct device *dev);
+
 #endif /* __LINUX_SWIOTLB_XEN_H */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZnk-00072A-VC; Wed, 12 Nov 2014 15:25:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <clark.laughlin@linaro.org>) id 1XoZnj-00071m-OZ
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:25:43 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	67/2C-02712-7FB73645; Wed, 12 Nov 2014 15:25:43 +0000
X-Env-Sender: clark.laughlin@linaro.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415805941!12088339!1
X-Originating-IP: [209.85.218.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22031 invoked from network); 12 Nov 2014 15:25:42 -0000
Received: from mail-oi0-f45.google.com (HELO mail-oi0-f45.google.com)
	(209.85.218.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:25:42 -0000
Received: by mail-oi0-f45.google.com with SMTP id a141so565317oig.18
	for <xen-devel@lists.xenproject.org>;
	Wed, 12 Nov 2014 07:25:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=ELPVBsYDLih1PzOQs/gqlQPthkZEbTS+K8weaN88XdA=;
	b=RrGp+XHvKma+2UtzGXtr/O0HuVBP0Txb76Y4XnGG9F+w4uVb8DXeYg4iEx/rsvPbxe
	hFtT9oe5A0Nv6hAAf2hw1D0Hx78vOr30riNNeIi70mmAH5NT/24f1SdK3I4Q4B1i9zXx
	y2Kku6tWwM2kqzSwm6woPfkCCbxUzXRD9/8Rvj3UcbkVc3drwuqUEcDDTG6bk3xO/56V
	J+hZRvO7mbl0yH7tM0Y1ZHCSh1tJiJ2ysBZm1o7s9RVb2BF74uqbwpzt2hO+59VXFSoC
	PK2zvSaM3XUGGkN9oO50Hc0YUQi8Mc3WOSuagjLpulEJhgIkq8V2ISJIQT18K2TT8Hww
	Krfw==
X-Gm-Message-State: ALoCoQmF4y4QVrXvMEEZM5gMBysnAe7YsuXoJnYMzolM/6eyDSbR71vTu/YL2nVf1jqRmmco7pVI
X-Received: by 10.182.68.106 with SMTP id v10mr39211647obt.32.1415805941066;
	Wed, 12 Nov 2014 07:25:41 -0800 (PST)
Received: from smith.hp-linaro.org
	(173-11-172-149-houston.txt.hfc.comcastbusiness.net.
	[173.11.172.149])
	by mx.google.com with ESMTPSA id no6sm9441997obb.6.2014.11.12.07.25.39
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:25:39 -0800 (PST)
From: Clark Laughlin <clark.laughlin@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Wed, 12 Nov 2014 09:27:23 -0600
Message-Id: <1415806043-28199-1-git-send-email-clark.laughlin@linaro.org>
X-Mailer: git-send-email 1.9.1
Cc: Clark Laughlin <clark.laughlin@linaro.org>
Subject: [Xen-devel] [PATCH] mkdeb previously set the package architecture
	to be 'amd64' for anything other than XEN_TARGET_ARCH=x86_32.
	This patch attempts to correctly map the architecture from
	GNU names to debian names for x86 and ARM architectures,
	or otherwise, defaults it to the value in XEN_TARGET_ARCH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
---
 tools/misc/mkdeb | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 3bbf881..4d14d9e 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -13,11 +13,16 @@ fi
 
 cd $1
 version=$2
-if test "$XEN_TARGET_ARCH" = "x86_32"; then
-  arch=i386
-else
-  arch=amd64
-fi
+
+# map the architecture, if necessary
+arch=$XEN_TARGET_ARCH
+case "$XEN_TARGET_ARCH" in
+  x86_32)  arch=i386 ;;
+  i686)    arch=i386 ;;
+  x86_64)  arch=amd64 ;;
+  arm32)   arch=armhf ;;
+  aarch64) arch=arm64 ;;
+esac
 
 # Prepare the directory to package
 cd dist
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZnk-00072A-VC; Wed, 12 Nov 2014 15:25:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <clark.laughlin@linaro.org>) id 1XoZnj-00071m-OZ
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:25:43 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	67/2C-02712-7FB73645; Wed, 12 Nov 2014 15:25:43 +0000
X-Env-Sender: clark.laughlin@linaro.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415805941!12088339!1
X-Originating-IP: [209.85.218.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22031 invoked from network); 12 Nov 2014 15:25:42 -0000
Received: from mail-oi0-f45.google.com (HELO mail-oi0-f45.google.com)
	(209.85.218.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:25:42 -0000
Received: by mail-oi0-f45.google.com with SMTP id a141so565317oig.18
	for <xen-devel@lists.xenproject.org>;
	Wed, 12 Nov 2014 07:25:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=ELPVBsYDLih1PzOQs/gqlQPthkZEbTS+K8weaN88XdA=;
	b=RrGp+XHvKma+2UtzGXtr/O0HuVBP0Txb76Y4XnGG9F+w4uVb8DXeYg4iEx/rsvPbxe
	hFtT9oe5A0Nv6hAAf2hw1D0Hx78vOr30riNNeIi70mmAH5NT/24f1SdK3I4Q4B1i9zXx
	y2Kku6tWwM2kqzSwm6woPfkCCbxUzXRD9/8Rvj3UcbkVc3drwuqUEcDDTG6bk3xO/56V
	J+hZRvO7mbl0yH7tM0Y1ZHCSh1tJiJ2ysBZm1o7s9RVb2BF74uqbwpzt2hO+59VXFSoC
	PK2zvSaM3XUGGkN9oO50Hc0YUQi8Mc3WOSuagjLpulEJhgIkq8V2ISJIQT18K2TT8Hww
	Krfw==
X-Gm-Message-State: ALoCoQmF4y4QVrXvMEEZM5gMBysnAe7YsuXoJnYMzolM/6eyDSbR71vTu/YL2nVf1jqRmmco7pVI
X-Received: by 10.182.68.106 with SMTP id v10mr39211647obt.32.1415805941066;
	Wed, 12 Nov 2014 07:25:41 -0800 (PST)
Received: from smith.hp-linaro.org
	(173-11-172-149-houston.txt.hfc.comcastbusiness.net.
	[173.11.172.149])
	by mx.google.com with ESMTPSA id no6sm9441997obb.6.2014.11.12.07.25.39
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:25:39 -0800 (PST)
From: Clark Laughlin <clark.laughlin@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Wed, 12 Nov 2014 09:27:23 -0600
Message-Id: <1415806043-28199-1-git-send-email-clark.laughlin@linaro.org>
X-Mailer: git-send-email 1.9.1
Cc: Clark Laughlin <clark.laughlin@linaro.org>
Subject: [Xen-devel] [PATCH] mkdeb previously set the package architecture
	to be 'amd64' for anything other than XEN_TARGET_ARCH=x86_32.
	This patch attempts to correctly map the architecture from
	GNU names to debian names for x86 and ARM architectures,
	or otherwise, defaults it to the value in XEN_TARGET_ARCH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
---
 tools/misc/mkdeb | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 3bbf881..4d14d9e 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -13,11 +13,16 @@ fi
 
 cd $1
 version=$2
-if test "$XEN_TARGET_ARCH" = "x86_32"; then
-  arch=i386
-else
-  arch=amd64
-fi
+
+# map the architecture, if necessary
+arch=$XEN_TARGET_ARCH
+case "$XEN_TARGET_ARCH" in
+  x86_32)  arch=i386 ;;
+  i686)    arch=i386 ;;
+  x86_64)  arch=amd64 ;;
+  arm32)   arch=armhf ;;
+  aarch64) arch=arm64 ;;
+esac
 
 # Prepare the directory to package
 cd dist
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZnk-000723-KL; Wed, 12 Nov 2014 15:25:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoZnj-00071h-4w
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:25:43 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	A7/9A-17694-6FB73645; Wed, 12 Nov 2014 15:25:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415805939!10782016!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21715 invoked from network); 12 Nov 2014 15:25:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:25:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190548030"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:25:28 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XoZnU-0007Pj-DG;
	Wed, 12 Nov 2014 15:25:28 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 12 Nov 2014 15:25:05 +0000
Message-ID: <1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to be
	overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 dma_ops->get_required_mask() if provided, defaulting to
dma_get_requried_mask_from_max_pfn().

This is needed on systems (such as Xen PV guests) where the DMA
address and the physical address are not equal.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/device.h |    2 ++
 arch/x86/kernel/pci-dma.c     |    8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
index 03dd729..10bc628 100644
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
 struct pdev_archdata {
 };
 
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
+
 #endif /* _ASM_X86_DEVICE_H */
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index a25e202..5154400 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -140,6 +140,14 @@ void dma_generic_free_coherent(struct device *dev, size_t size, void *vaddr,
 		free_pages((unsigned long)vaddr, get_order(size));
 }
 
+u64 dma_get_required_mask(struct device *dev)
+{
+	if (dma_ops->get_required_mask)
+		return dma_ops->get_required_mask(dev);
+	return dma_get_required_mask_from_max_pfn(dev);
+}
+EXPORT_SYMBOL_GPL(dma_get_required_mask);
+
 /*
  * See <Documentation/x86/x86_64/boot-options.txt> for the iommu kernel
  * parameter documentation.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZnl-00072O-Lx; Wed, 12 Nov 2014 15:25:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoZnj-00071o-W8
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:25:44 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	9D/9A-17694-7FB73645; Wed, 12 Nov 2014 15:25:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415805939!10782016!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21838 invoked from network); 12 Nov 2014 15:25:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:25:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190548031"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:25:28 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XoZnU-0007Pj-Dp;
	Wed, 12 Nov 2014 15:25:28 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 12 Nov 2014 15:25:06 +0000
Message-ID: <1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to calculate
	the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to
use only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

Provide a get_required_mask op that uses the maximum MFN to calculate
the DMA mask.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    1 +
 drivers/xen/swiotlb-xen.c      |   13 +++++++++++++
 include/xen/swiotlb-xen.h      |    4 ++++
 3 files changed, 18 insertions(+)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 0e98e5d..a5d180a 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -31,6 +31,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.map_page = xen_swiotlb_map_page,
 	.unmap_page = xen_swiotlb_unmap_page,
 	.dma_supported = xen_swiotlb_dma_supported,
+	.get_required_mask = xen_swiotlb_get_required_mask,
 };
 
 /*
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..472fd52 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -42,9 +42,11 @@
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 #include <xen/hvc-console.h>
+#include <xen/interface/memory.h>
 
 #include <asm/dma-mapping.h>
 #include <asm/xen/page-coherent.h>
+#include <asm/xen/hypercall.h>
 
 #include <trace/events/swiotlb.h>
 /*
@@ -683,3 +685,14 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
+
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+	u64 max_mfn;
+
+	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
+
+	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 8b2eb93..6408888 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -58,4 +58,8 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
 
 extern int
 xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
+
+extern u64
+xen_swiotlb_get_required_mask(struct device *dev);
+
 #endif /* __LINUX_SWIOTLB_XEN_H */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZnl-00072H-Ak; Wed, 12 Nov 2014 15:25:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoZnj-00071n-PR
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:25:43 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	13/85-02954-7FB73645; Wed, 12 Nov 2014 15:25:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415805939!8750141!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12218 invoked from network); 12 Nov 2014 15:25:42 -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;
	12 Nov 2014 15:25:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190548029"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:25:28 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XoZnU-0007Pj-Cj;
	Wed, 12 Nov 2014 15:25:28 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 12 Nov 2014 15:25:04 +0000
Message-ID: <1415805906-27316-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Fenghua Yu <fenghua.yu@intel.com>, Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 1/3] dma,
	ia64: add dma_get_required_mask_from_max_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ia64 provides a duplicate of the generic dma_get_required_mask()
because it has ARCH_HAS_GET_REQUIRED_MASK.  Provide a common
dma_get_require_mask_max_pfn() instead.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
---
 arch/ia64/include/asm/machvec.h      |    2 +-
 arch/ia64/include/asm/machvec_init.h |    1 -
 arch/ia64/pci/pci.c                  |   20 --------------------
 drivers/base/platform.c              |   10 ++++++++--
 include/linux/dma-mapping.h          |    1 +
 5 files changed, 10 insertions(+), 24 deletions(-)

diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
index 9c39bdf..beaa47d 100644
--- a/arch/ia64/include/asm/machvec.h
+++ b/arch/ia64/include/asm/machvec.h
@@ -287,7 +287,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
 # define platform_dma_get_ops		dma_get_ops
 #endif
 #ifndef platform_dma_get_required_mask
-# define  platform_dma_get_required_mask	ia64_dma_get_required_mask
+# define  platform_dma_get_required_mask	dma_get_required_mask_from_max_pfn
 #endif
 #ifndef platform_irq_to_vector
 # define platform_irq_to_vector		__ia64_irq_to_vector
diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
index 37a4698..ef964b2 100644
--- a/arch/ia64/include/asm/machvec_init.h
+++ b/arch/ia64/include/asm/machvec_init.h
@@ -3,7 +3,6 @@
 
 extern ia64_mv_send_ipi_t ia64_send_ipi;
 extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
-extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
 extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
 extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
 extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 291a582..79da21b 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -791,26 +791,6 @@ static void __init set_pci_dfl_cacheline_size(void)
 	pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
 }
 
-u64 ia64_dma_get_required_mask(struct device *dev)
-{
-	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
-	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
-	u64 mask;
-
-	if (!high_totalram) {
-		/* convert to mask just covering totalram */
-		low_totalram = (1 << (fls(low_totalram) - 1));
-		low_totalram += low_totalram - 1;
-		mask = low_totalram;
-	} else {
-		high_totalram = (1 << (fls(high_totalram) - 1));
-		high_totalram += high_totalram - 1;
-		mask = (((u64)high_totalram) << 32) + 0xffffffff;
-	}
-	return mask;
-}
-EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
-
 u64 dma_get_required_mask(struct device *dev)
 {
 	return platform_dma_get_required_mask(dev);
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b2afc29..f9f3930 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1009,8 +1009,7 @@ int __init platform_bus_init(void)
 	return error;
 }
 
-#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
-u64 dma_get_required_mask(struct device *dev)
+u64 dma_get_required_mask_from_max_pfn(struct device *dev)
 {
 	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
 	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
@@ -1028,6 +1027,13 @@ u64 dma_get_required_mask(struct device *dev)
 	}
 	return mask;
 }
+EXPORT_SYMBOL_GPL(dma_get_required_mask_from_max_pfn);
+
+#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
+u64 dma_get_required_mask(struct device *dev)
+{
+	return dma_get_required_mask_from_max_pfn(dev);
+}
 EXPORT_SYMBOL_GPL(dma_get_required_mask);
 #endif
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d3881..6e2fdfc 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -127,6 +127,7 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
 	return dma_set_mask_and_coherent(dev, mask);
 }
 
+extern u64 dma_get_required_mask_from_max_pfn(struct device *dev);
 extern u64 dma_get_required_mask(struct device *dev);
 
 #ifndef set_arch_dma_coherent_ops
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZnx-00075E-7p; Wed, 12 Nov 2014 15:25:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoZnv-00074Z-LG
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:25:55 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	C5/2A-27785-30C73645; Wed, 12 Nov 2014 15:25:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415805949!12105278!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31536 invoked from network); 12 Nov 2014 15:25:54 -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;
	12 Nov 2014 15:25:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="191999069"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:25:21 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XoZnM-0007Pj-Tq;
	Wed, 12 Nov 2014 15:25:20 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 12 Nov 2014 15:25:03 +0000
Message-ID: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCHv2 0/3]: dma, x86,
	xen: reduce SWIOTLB usage in Xen guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On systems where DMA addresses and physical addresses are not 1:1
(such as Xen PV guests), the generic dma_get_required_mask() will not
return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to use
only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

This series allows Xen PV guests to override the default
dma_get_required_mask() with one that calculated the DMA mask from the
maximum MFN (and not the PFN).

The first patch removes a duplicated function between ia64 and common
since we want a common implementation usage by ia64 and x86.

Changes in v2:
- split x86 and xen changes into separate patches

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZnl-00072H-Ak; Wed, 12 Nov 2014 15:25:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoZnj-00071n-PR
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:25:43 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	13/85-02954-7FB73645; Wed, 12 Nov 2014 15:25:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415805939!8750141!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12218 invoked from network); 12 Nov 2014 15:25:42 -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;
	12 Nov 2014 15:25:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190548029"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:25:28 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XoZnU-0007Pj-Cj;
	Wed, 12 Nov 2014 15:25:28 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 12 Nov 2014 15:25:04 +0000
Message-ID: <1415805906-27316-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Fenghua Yu <fenghua.yu@intel.com>, Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 1/3] dma,
	ia64: add dma_get_required_mask_from_max_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ia64 provides a duplicate of the generic dma_get_required_mask()
because it has ARCH_HAS_GET_REQUIRED_MASK.  Provide a common
dma_get_require_mask_max_pfn() instead.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
---
 arch/ia64/include/asm/machvec.h      |    2 +-
 arch/ia64/include/asm/machvec_init.h |    1 -
 arch/ia64/pci/pci.c                  |   20 --------------------
 drivers/base/platform.c              |   10 ++++++++--
 include/linux/dma-mapping.h          |    1 +
 5 files changed, 10 insertions(+), 24 deletions(-)

diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
index 9c39bdf..beaa47d 100644
--- a/arch/ia64/include/asm/machvec.h
+++ b/arch/ia64/include/asm/machvec.h
@@ -287,7 +287,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
 # define platform_dma_get_ops		dma_get_ops
 #endif
 #ifndef platform_dma_get_required_mask
-# define  platform_dma_get_required_mask	ia64_dma_get_required_mask
+# define  platform_dma_get_required_mask	dma_get_required_mask_from_max_pfn
 #endif
 #ifndef platform_irq_to_vector
 # define platform_irq_to_vector		__ia64_irq_to_vector
diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
index 37a4698..ef964b2 100644
--- a/arch/ia64/include/asm/machvec_init.h
+++ b/arch/ia64/include/asm/machvec_init.h
@@ -3,7 +3,6 @@
 
 extern ia64_mv_send_ipi_t ia64_send_ipi;
 extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
-extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
 extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
 extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
 extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 291a582..79da21b 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -791,26 +791,6 @@ static void __init set_pci_dfl_cacheline_size(void)
 	pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
 }
 
-u64 ia64_dma_get_required_mask(struct device *dev)
-{
-	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
-	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
-	u64 mask;
-
-	if (!high_totalram) {
-		/* convert to mask just covering totalram */
-		low_totalram = (1 << (fls(low_totalram) - 1));
-		low_totalram += low_totalram - 1;
-		mask = low_totalram;
-	} else {
-		high_totalram = (1 << (fls(high_totalram) - 1));
-		high_totalram += high_totalram - 1;
-		mask = (((u64)high_totalram) << 32) + 0xffffffff;
-	}
-	return mask;
-}
-EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
-
 u64 dma_get_required_mask(struct device *dev)
 {
 	return platform_dma_get_required_mask(dev);
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b2afc29..f9f3930 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1009,8 +1009,7 @@ int __init platform_bus_init(void)
 	return error;
 }
 
-#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
-u64 dma_get_required_mask(struct device *dev)
+u64 dma_get_required_mask_from_max_pfn(struct device *dev)
 {
 	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
 	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
@@ -1028,6 +1027,13 @@ u64 dma_get_required_mask(struct device *dev)
 	}
 	return mask;
 }
+EXPORT_SYMBOL_GPL(dma_get_required_mask_from_max_pfn);
+
+#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
+u64 dma_get_required_mask(struct device *dev)
+{
+	return dma_get_required_mask_from_max_pfn(dev);
+}
 EXPORT_SYMBOL_GPL(dma_get_required_mask);
 #endif
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d3881..6e2fdfc 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -127,6 +127,7 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
 	return dma_set_mask_and_coherent(dev, mask);
 }
 
+extern u64 dma_get_required_mask_from_max_pfn(struct device *dev);
 extern u64 dma_get_required_mask(struct device *dev);
 
 #ifndef set_arch_dma_coherent_ops
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZnx-00075E-7p; Wed, 12 Nov 2014 15:25:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XoZnv-00074Z-LG
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:25:55 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	C5/2A-27785-30C73645; Wed, 12 Nov 2014 15:25:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415805949!12105278!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31536 invoked from network); 12 Nov 2014 15:25:54 -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;
	12 Nov 2014 15:25:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="191999069"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:25:21 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XoZnM-0007Pj-Tq;
	Wed, 12 Nov 2014 15:25:20 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 12 Nov 2014 15:25:03 +0000
Message-ID: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCHv2 0/3]: dma, x86,
	xen: reduce SWIOTLB usage in Xen guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On systems where DMA addresses and physical addresses are not 1:1
(such as Xen PV guests), the generic dma_get_required_mask() will not
return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to use
only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

This series allows Xen PV guests to override the default
dma_get_required_mask() with one that calculated the DMA mask from the
maximum MFN (and not the PFN).

The first patch removes a duplicated function between ia64 and common
since we want a common implementation usage by ia64 and x86.

Changes in v2:
- split x86 and xen changes into separate patches

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:30:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:30:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZsA-0007fg-UK; Wed, 12 Nov 2014 15:30:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoZs9-0007fZ-Dn
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:30:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1B/03-24532-80D73645; Wed, 12 Nov 2014 15:30:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415806214!12168610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19035 invoked from network); 12 Nov 2014 15:30: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;
	12 Nov 2014 15:30:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190549719"
Message-ID: <1415806209.1155.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Clark Laughlin <clark.laughlin@linaro.org>
Date: Wed, 12 Nov 2014 15:30:09 +0000
In-Reply-To: <1415806043-28199-1-git-send-email-clark.laughlin@linaro.org>
References: <1415806043-28199-1-git-send-email-clark.laughlin@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] mkdeb previously set the package
 architecture to be 'amd64' for anything other than XEN_TARGET_ARCH=x86_32.
 This patch attempts to correctly map the architecture from GNU names to
 debian names for x86 and ARM architectures, or otherwise,
 defaults it to the value in XEN_TARGET_ARCH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 09:27 -0600, Clark Laughlin wrote:
> Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

The mapping is a bit more zealous that strictly needed:
> +# map the architecture, if necessary
> +arch=$XEN_TARGET_ARCH
> +case "$XEN_TARGET_ARCH" in
> +  x86_32)  arch=i386 ;;
> +  i686)    arch=i386 ;;
> +  x86_64)  arch=amd64 ;;
> +  arm32)   arch=armhf ;;
> +  aarch64) arch=arm64 ;;
> +esac

I don't think $XEN_TARGET_ARCH can ever be i686 or aarch64, that would
break all over the place I think. Not that there is any harm in handling
those cases.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:30:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:30:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZsA-0007fg-UK; Wed, 12 Nov 2014 15:30:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoZs9-0007fZ-Dn
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:30:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1B/03-24532-80D73645; Wed, 12 Nov 2014 15:30:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415806214!12168610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19035 invoked from network); 12 Nov 2014 15:30: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;
	12 Nov 2014 15:30:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190549719"
Message-ID: <1415806209.1155.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Clark Laughlin <clark.laughlin@linaro.org>
Date: Wed, 12 Nov 2014 15:30:09 +0000
In-Reply-To: <1415806043-28199-1-git-send-email-clark.laughlin@linaro.org>
References: <1415806043-28199-1-git-send-email-clark.laughlin@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] mkdeb previously set the package
 architecture to be 'amd64' for anything other than XEN_TARGET_ARCH=x86_32.
 This patch attempts to correctly map the architecture from GNU names to
 debian names for x86 and ARM architectures, or otherwise,
 defaults it to the value in XEN_TARGET_ARCH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 09:27 -0600, Clark Laughlin wrote:
> Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

The mapping is a bit more zealous that strictly needed:
> +# map the architecture, if necessary
> +arch=$XEN_TARGET_ARCH
> +case "$XEN_TARGET_ARCH" in
> +  x86_32)  arch=i386 ;;
> +  i686)    arch=i386 ;;
> +  x86_64)  arch=amd64 ;;
> +  arm32)   arch=armhf ;;
> +  aarch64) arch=arm64 ;;
> +esac

I don't think $XEN_TARGET_ARCH can ever be i686 or aarch64, that would
break all over the place I think. Not that there is any harm in handling
those cases.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZu5-0007rE-L5; Wed, 12 Nov 2014 15:32:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZu3-0007qy-CI
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3B/E3-09936-E7D73645; Wed, 12 Nov 2014 15:32:14 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415806332!12240108!1
X-Originating-IP: [209.85.216.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11822 invoked from network); 12 Nov 2014 15:32:13 -0000
Received: from mail-qc0-f178.google.com (HELO mail-qc0-f178.google.com)
	(209.85.216.178)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:13 -0000
Received: by mail-qc0-f178.google.com with SMTP id b13so10363287qcw.23
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=VCd6nqnGpU0yN0kIYPg2J4NljVTDQdHlj/2fCwQ80Cc=;
	b=LuNkntY4CBZlj8t4qMEn8B22MCV3sQQkZSlfErlkKffQfTIO0HO4cnY7wYIRVOaSh+
	WisbELNV/+E6G+ph3R310Fa8o08jGF3Xx61GKMEdRFxa7CvDsvnoUvOtbb2BCGg7ki5m
	OVXa95Hu4A2Qb0yorvBBnvWI8bD8qYJr/nkuy4YoqledeSp3hn/4AswTk1ws2ogYHmrk
	nkXdFDPuG2FUWx6dL7ZeYThumC8iA3bjL3hBDCiHbP18cFi7F9VMVWAo13Cs/jCsP2Km
	mGEN1PqrN/FNzKrpj/ecgAF1LViIHC/eXHGMUpSnMUsbQ8jdVF1Xbk1jyHGjEl0HhGKD
	5a3Q==
X-Gm-Message-State: ALoCoQmWFdFuFZPCByie/v3Elz1g9Sb2PKI20s4bbcfwfTSa46W5IOQ+X6uAdpXmJIrKJGPkL2EJ
X-Received: by 10.140.91.245 with SMTP id z108mr48580624qgd.5.1415806332353;
	Wed, 12 Nov 2014 07:32:12 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.10 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:11 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:43 +0100
Message-Id: <1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Razvan Cojocaru <rcojocaru@bitdefender.com>

The public mem_event structures used to communicate with helper applications via
shared rings have been used in different settings. However, the variable names
within this structure have not reflected this fact, resulting in the reuse of
variables to mean different things under different scenarios.

This patch remedies the issue by clearly defining the structure members based on
the actual context within which the structure is used.

Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 tools/tests/xen-access/xen-access.c |  33 +++++----
 tools/xenpaging/xenpaging.c         |  34 ++++-----
 xen/arch/x86/hvm/hvm.c              | 137 +++++++++++++++++++++---------------
 xen/arch/x86/mm/mem_sharing.c       |   7 +-
 xen/arch/x86/mm/p2m.c               |  55 ++++++++-------
 xen/include/public/mem_event.h      |  79 ++++++++++++++++-----
 6 files changed, 211 insertions(+), 134 deletions(-)

diff --git a/tools/tests/xen-access/xen-access.c b/tools/tests/xen-access/xen-access.c
index 6cb382d..9d53fb3 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -556,8 +556,8 @@ int main(int argc, char *argv[])
             rsp.flags = req.flags;
 
             switch (req.reason) {
-            case MEM_EVENT_REASON_VIOLATION:
-                rc = xc_get_mem_access(xch, domain_id, req.gfn, &access);
+            case MEM_EVENT_REASON_MEM_ACCESS_VIOLATION:
+                rc = xc_get_mem_access(xch, domain_id, req.mem_access_event.gfn, &access);
                 if (rc < 0)
                 {
                     ERROR("Error %d getting mem_access event\n", rc);
@@ -567,21 +567,21 @@ int main(int argc, char *argv[])
 
                 printf("PAGE ACCESS: %c%c%c for GFN %"PRIx64" (offset %06"
                        PRIx64") gla %016"PRIx64" (valid: %c; fault in gpt: %c; fault with gla: %c) (vcpu %u)\n",
-                       req.access_r ? 'r' : '-',
-                       req.access_w ? 'w' : '-',
-                       req.access_x ? 'x' : '-',
-                       req.gfn,
-                       req.offset,
-                       req.gla,
-                       req.gla_valid ? 'y' : 'n',
-                       req.fault_in_gpt ? 'y' : 'n',
-                       req.fault_with_gla ? 'y': 'n',
+                       req.mem_access_event.access_r ? 'r' : '-',
+                       req.mem_access_event.access_w ? 'w' : '-',
+                       req.mem_access_event.access_x ? 'x' : '-',
+                       req.mem_access_event.gfn,
+                       req.mem_access_event.offset,
+                       req.mem_access_event.gla,
+                       req.mem_access_event.gla_valid ? 'y' : 'n',
+                       req.mem_access_event.fault_in_gpt ? 'y' : 'n',
+                       req.mem_access_event.fault_with_gla ? 'y': 'n',
                        req.vcpu_id);
 
                 if ( default_access != after_first_access )
                 {
                     rc = xc_set_mem_access(xch, domain_id, after_first_access,
-                                           req.gfn, 1);
+                                           req.mem_access_event.gfn, 1);
                     if (rc < 0)
                     {
                         ERROR("Error %d setting gfn to access_type %d\n", rc,
@@ -592,13 +592,12 @@ int main(int argc, char *argv[])
                 }
 
 
-                rsp.gfn = req.gfn;
-                rsp.p2mt = req.p2mt;
+                rsp.mem_access_event.gfn = req.mem_access_event.gfn;
                 break;
             case MEM_EVENT_REASON_INT3:
-                printf("INT3: rip=%016"PRIx64", gfn=%"PRIx64" (vcpu %d)\n", 
-                       req.gla, 
-                       req.gfn,
+                printf("INT3: rip=%016"PRIx64", gfn=%"PRIx64" (vcpu %d)\n",
+                       req.int3_event.gla,
+                       req.int3_event.gfn,
                        req.vcpu_id);
 
                 /* Reinject */
diff --git a/tools/xenpaging/xenpaging.c b/tools/xenpaging/xenpaging.c
index 82c1ee4..148b3e7 100644
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -684,9 +684,9 @@ static int xenpaging_resume_page(struct xenpaging *paging, mem_event_response_t
          * This allows page-out of these gfns if the target grows again.
          */
         if (paging->num_paged_out > paging->policy_mru_size)
-            policy_notify_paged_in(rsp->gfn);
+            policy_notify_paged_in(rsp->mem_paging_event.gfn);
         else
-            policy_notify_paged_in_nomru(rsp->gfn);
+            policy_notify_paged_in_nomru(rsp->mem_paging_event.gfn);
 
        /* Record number of resumed pages */
        paging->num_paged_out--;
@@ -910,49 +910,49 @@ int main(int argc, char *argv[])
 
             get_request(&paging->mem_event, &req);
 
-            if ( req.gfn > paging->max_pages )
+            if ( req.mem_paging_event.gfn > paging->max_pages )
             {
-                ERROR("Requested gfn %"PRIx64" higher than max_pages %x\n", req.gfn, paging->max_pages);
+                ERROR("Requested gfn %"PRIx64" higher than max_pages %x\n", req.mem_paging_event.gfn, paging->max_pages);
                 goto out;
             }
 
             /* Check if the page has already been paged in */
-            if ( test_and_clear_bit(req.gfn, paging->bitmap) )
+            if ( test_and_clear_bit(req.mem_paging_event.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                slot = paging->gfn_to_slot[req.gfn];
+                slot = paging->gfn_to_slot[req.mem_paging_event.gfn];
 
                 /* Sanity check */
-                if ( paging->slot_to_gfn[slot] != req.gfn )
+                if ( paging->slot_to_gfn[slot] != req.mem_paging_event.gfn )
                 {
-                    ERROR("Expected gfn %"PRIx64" in slot %d, but found gfn %lx\n", req.gfn, slot, paging->slot_to_gfn[slot]);
+                    ERROR("Expected gfn %"PRIx64" in slot %d, but found gfn %lx\n", req.mem_paging_event.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, slot);
+                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.mem_paging_event.gfn, slot);
                     /* Notify policy of page being dropped */
-                    policy_notify_dropped(req.gfn);
+                    policy_notify_dropped(req.mem_paging_event.gfn);
                 }
                 else
                 {
                     /* Populate the page */
-                    if ( xenpaging_populate_page(paging, req.gfn, slot) < 0 )
+                    if ( xenpaging_populate_page(paging, req.mem_paging_event.gfn, slot) < 0 )
                     {
-                        ERROR("Error populating page %"PRIx64"", req.gfn);
+                        ERROR("Error populating page %"PRIx64"", req.mem_paging_event.gfn);
                         goto out;
                     }
                 }
 
                 /* Prepare the response */
-                rsp.gfn = req.gfn;
+                rsp.mem_paging_event.gfn = req.mem_paging_event.gfn;
                 rsp.vcpu_id = req.vcpu_id;
                 rsp.flags = req.flags;
 
                 if ( xenpaging_resume_page(paging, &rsp, 1) < 0 )
                 {
-                    PERROR("Error resuming page %"PRIx64"", req.gfn);
+                    PERROR("Error resuming page %"PRIx64"", req.mem_paging_event.gfn);
                     goto out;
                 }
 
@@ -967,7 +967,7 @@ int main(int argc, char *argv[])
                 DPRINTF("page %s populated (domain = %d; vcpu = %d;"
                         " gfn = %"PRIx64"; paused = %d; evict_fail = %d)\n",
                         req.flags & MEM_EVENT_FLAG_EVICT_FAIL ? "not" : "already",
-                        paging->mem_event.domain_id, req.vcpu_id, req.gfn,
+                        paging->mem_event.domain_id, req.vcpu_id, req.mem_paging_event.gfn,
                         !!(req.flags & MEM_EVENT_FLAG_VCPU_PAUSED) ,
                         !!(req.flags & MEM_EVENT_FLAG_EVICT_FAIL) );
 
@@ -975,13 +975,13 @@ int main(int argc, char *argv[])
                 if (( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) || ( req.flags & MEM_EVENT_FLAG_EVICT_FAIL ))
                 {
                     /* Prepare the response */
-                    rsp.gfn = req.gfn;
+                    rsp.mem_paging_event.gfn = req.mem_paging_event.gfn;
                     rsp.vcpu_id = req.vcpu_id;
                     rsp.flags = req.flags;
 
                     if ( xenpaging_resume_page(paging, &rsp, 0) < 0 )
                     {
-                        PERROR("Error resuming page %"PRIx64"", req.gfn);
+                        PERROR("Error resuming page %"PRIx64"", req.mem_paging_event.gfn);
                         goto out;
                     }
                 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..67782c8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -6185,21 +6185,15 @@ static void hvm_mem_event_fill_regs(mem_event_request_t *req)
     req->x86_regs.cr4 = curr->arch.hvm_vcpu.guest_cr[4];
 }
 
-static int hvm_memory_event_traps(long p, uint32_t reason,
-                                  unsigned long value, unsigned long old, 
-                                  bool_t gla_valid, unsigned long gla) 
+static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
 {
-    struct vcpu* v = current;
-    struct domain *d = v->domain;
-    mem_event_request_t req = { .reason = reason };
     int rc;
+    struct vcpu *v = current;
+    struct domain *d = v->domain;
 
-    if ( !(p & HVMPME_MODE_MASK) ) 
+    if ( !(parameters & HVMPME_MODE_MASK) )
         return 0;
 
-    if ( (p & HVMPME_onchangeonly) && (value == old) )
-        return 1;
-
     rc = mem_event_claim_slot(d, &d->mem_event->access);
     if ( rc == -ENOSYS )
     {
@@ -6210,85 +6204,114 @@ static int hvm_memory_event_traps(long p, uint32_t reason,
     else if ( rc < 0 )
         return rc;
 
-    if ( (p & HVMPME_MODE_MASK) == HVMPME_mode_sync ) 
+    if ( (parameters & HVMPME_MODE_MASK) == HVMPME_mode_sync )
     {
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+        req->flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
         mem_event_vcpu_pause(v);
     }
 
-    req.gfn = value;
-    req.vcpu_id = v->vcpu_id;
-    if ( gla_valid ) 
-    {
-        req.offset = gla & ((1 << PAGE_SHIFT) - 1);
-        req.gla = gla;
-        req.gla_valid = 1;
-    }
-    else
-    {
-        req.gla = old;
-    }
-    
-    hvm_mem_event_fill_regs(&req);
-    mem_event_put_request(d, &d->mem_event->access, &req);
-    
+    hvm_mem_event_fill_regs(req);
+    mem_event_put_request(d, &d->mem_event->access, req);
+
     return 1;
 }
 
-void hvm_memory_event_cr0(unsigned long value, unsigned long old) 
+void hvm_memory_event_cr0(unsigned long value, unsigned long old)
 {
-    hvm_memory_event_traps(current->domain->arch.hvm_domain
-                             .params[HVM_PARAM_MEMORY_EVENT_CR0],
-                           MEM_EVENT_REASON_CR0,
-                           value, old, 0, 0);
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_CR0,
+        .vcpu_id = current->vcpu_id,
+        .cr_event.new_value = value,
+        .cr_event.old_value = old
+    };
+
+    long parameters = current->domain->arch.hvm_domain
+                        .params[HVM_PARAM_MEMORY_EVENT_CR0];
+
+    if ( (parameters & HVMPME_onchangeonly) && (value == old) )
+        return;
+
+    hvm_memory_event_traps(parameters, &req);
 }
 
-void hvm_memory_event_cr3(unsigned long value, unsigned long old) 
+void hvm_memory_event_cr3(unsigned long value, unsigned long old)
 {
-    hvm_memory_event_traps(current->domain->arch.hvm_domain
-                             .params[HVM_PARAM_MEMORY_EVENT_CR3],
-                           MEM_EVENT_REASON_CR3,
-                           value, old, 0, 0);
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_CR3,
+        .vcpu_id = current->vcpu_id,
+        .cr_event.new_value = value,
+        .cr_event.old_value = old
+    };
+
+    long parameters = current->domain->arch.hvm_domain
+                        .params[HVM_PARAM_MEMORY_EVENT_CR3];
+
+    if ( (parameters & HVMPME_onchangeonly) && (value == old) )
+        return;
+
+    hvm_memory_event_traps(parameters, &req);
 }
 
-void hvm_memory_event_cr4(unsigned long value, unsigned long old) 
+void hvm_memory_event_cr4(unsigned long value, unsigned long old)
 {
-    hvm_memory_event_traps(current->domain->arch.hvm_domain
-                             .params[HVM_PARAM_MEMORY_EVENT_CR4],
-                           MEM_EVENT_REASON_CR4,
-                           value, old, 0, 0);
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_CR4,
+        .vcpu_id = current->vcpu_id,
+        .cr_event.new_value = value,
+        .cr_event.old_value = old
+    };
+
+    long parameters = current->domain->arch.hvm_domain
+                        .params[HVM_PARAM_MEMORY_EVENT_CR4];
+
+    if ( (parameters & HVMPME_onchangeonly) && (value == old) )
+        return;
+
+    hvm_memory_event_traps(parameters, &req);
 }
 
 void hvm_memory_event_msr(unsigned long msr, unsigned long value)
 {
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_MSR,
+        .vcpu_id = current->vcpu_id,
+        .msr_event.msr = msr,
+        .msr_event.new_value = value,
+    };
+
     hvm_memory_event_traps(current->domain->arch.hvm_domain
-                             .params[HVM_PARAM_MEMORY_EVENT_MSR],
-                           MEM_EVENT_REASON_MSR,
-                           value, ~value, 1, msr);
+                            .params[HVM_PARAM_MEMORY_EVENT_MSR],
+                           &req);
 }
 
-int hvm_memory_event_int3(unsigned long gla) 
+int hvm_memory_event_int3(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
-    unsigned long gfn;
-    gfn = paging_gva_to_gfn(current, gla, &pfec);
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_INT3,
+        .vcpu_id = current->vcpu_id,
+        .int3_event.gla = gla,
+        .int3_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
+    };
 
     return hvm_memory_event_traps(current->domain->arch.hvm_domain
-                                    .params[HVM_PARAM_MEMORY_EVENT_INT3],
-                                  MEM_EVENT_REASON_INT3,
-                                  gfn, 0, 1, gla);
+                                   .params[HVM_PARAM_MEMORY_EVENT_INT3],
+                                  &req);
 }
 
 int hvm_memory_event_single_step(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
-    unsigned long gfn;
-    gfn = paging_gva_to_gfn(current, gla, &pfec);
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_SINGLESTEP,
+        .vcpu_id = current->vcpu_id,
+        .singlestep_event.gla = gla,
+        .singlestep_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
+    };
 
     return hvm_memory_event_traps(current->domain->arch.hvm_domain
-            .params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP],
-            MEM_EVENT_REASON_SINGLESTEP,
-            gfn, 0, 1, gla);
+                                   .params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP],
+                                  &req);
 }
 
 int nhvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 7c0fc7d..c15edcc 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -559,7 +559,10 @@ int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
 {
     struct vcpu *v = current;
     int rc;
-    mem_event_request_t req = { .gfn = gfn };
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_MEM_SHARING,
+        .mem_sharing_event.gfn = gfn
+    };
 
     if ( (rc = __mem_event_claim_slot(d, 
                         &d->mem_event->share, allow_sleep)) < 0 )
@@ -571,7 +574,7 @@ int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
         mem_event_vcpu_pause(v);
     }
 
-    req.p2mt = p2m_ram_shared;
+    req.mem_sharing_event.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_event->share, &req);
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index efa49dd..cfd3ff5 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1077,7 +1077,10 @@ int p2m_mem_paging_evict(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 = { .gfn = gfn };
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_MEM_PAGING,
+        .mem_paging_event.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
@@ -1124,7 +1127,10 @@ void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req = { .gfn = gfn };
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_MEM_PAGING,
+        .mem_paging_event.gfn = gfn
+    };
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
@@ -1174,7 +1180,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
     }
 
     /* Send request to pager */
-    req.p2mt = p2mt;
+    req.mem_paging_event.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_event->paging, &req);
@@ -1309,15 +1315,15 @@ void p2m_mem_paging_resume(struct domain *d)
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
             gfn_lock(p2m, rsp.gfn, 0);
-            mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, 0, NULL);
+            mfn = p2m->get_entry(p2m, rsp.mem_access_event.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) )
             {
-                p2m_set_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K,
+                p2m_set_entry(p2m, rsp.mem_access_event.gfn, mfn, PAGE_ORDER_4K,
                               paging_mode_log_dirty(d) ? p2m_ram_logdirty :
                               p2m_ram_rw, a);
-                set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
+                set_gpfn_from_mfn(mfn_x(mfn), rsp.mem_access_event.gfn);
             }
             gfn_unlock(p2m, rsp.gfn, 0);
         }
@@ -1390,39 +1396,40 @@ void p2m_mem_event_emulate_check(struct vcpu *v, const mem_event_response_t *rsp
         xenmem_access_t access;
         bool_t violation = 1;
 
-        if ( p2m_get_mem_access(v->domain, rsp->gfn, &access) == 0 )
+        if ( p2m_get_mem_access(v->domain, rsp->mem_access_event.gfn, &access) == 0 )
         {
             switch ( access )
             {
             case XENMEM_access_n:
             case XENMEM_access_n2rwx:
             default:
-                violation = rsp->access_r || rsp->access_w || rsp->access_x;
+                violation = rsp->mem_access_event.access_r || rsp->mem_access_event.access_w ||
+                            rsp->mem_access_event.access_x;
                 break;
 
             case XENMEM_access_r:
-                violation = rsp->access_w || rsp->access_x;
+                violation = rsp->mem_access_event.access_w || rsp->mem_access_event.access_x;
                 break;
 
             case XENMEM_access_w:
-                violation = rsp->access_r || rsp->access_x;
+                violation = rsp->mem_access_event.access_r || rsp->mem_access_event.access_x;
                 break;
 
             case XENMEM_access_x:
-                violation = rsp->access_r || rsp->access_w;
+                violation = rsp->mem_access_event.access_r || rsp->mem_access_event.access_w;
                 break;
 
             case XENMEM_access_rx:
             case XENMEM_access_rx2rw:
-                violation = rsp->access_w;
+                violation = rsp->mem_access_event.access_w;
                 break;
 
             case XENMEM_access_wx:
-                violation = rsp->access_r;
+                violation = rsp->mem_access_event.access_r;
                 break;
 
             case XENMEM_access_rw:
-                violation = rsp->access_x;
+                violation = rsp->mem_access_event.access_x;
                 break;
 
             case XENMEM_access_rwx:
@@ -1540,24 +1547,24 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
     if ( req )
     {
         *req_ptr = req;
-        req->reason = MEM_EVENT_REASON_VIOLATION;
+        req->reason = MEM_EVENT_REASON_MEM_ACCESS_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 = npfec.gla_valid;
-        req->gla = gla;
+        req->mem_access_event.gfn = gfn;
+        req->mem_access_event.offset = gpa & ((1 << PAGE_SHIFT) - 1);
+        req->mem_access_event.gla_valid = npfec.gla_valid;
+        req->mem_access_event.gla = gla;
         if ( npfec.kind == npfec_kind_with_gla )
-            req->fault_with_gla = 1;
+            req->mem_access_event.fault_with_gla = 1;
         else if ( npfec.kind == npfec_kind_in_gpt )
-            req->fault_in_gpt = 1;
-        req->access_r = npfec.read_access;
-        req->access_w = npfec.write_access;
-        req->access_x = npfec.insn_fetch;
+            req->mem_access_event.fault_in_gpt = 1;
+        req->mem_access_event.access_r = npfec.read_access;
+        req->mem_access_event.access_w = npfec.write_access;
+        req->mem_access_event.access_x = npfec.insn_fetch;
         req->vcpu_id = v->vcpu_id;
 
         p2m_mem_event_fill_regs(req);
diff --git a/xen/include/public/mem_event.h b/xen/include/public/mem_event.h
index 599f9e8..c0e9394 100644
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -49,15 +49,19 @@
 #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 << 6)
 
 /* Reasons for the memory event request */
-#define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */
-#define MEM_EVENT_REASON_VIOLATION   1    /* access violation, GFN is address */
-#define MEM_EVENT_REASON_CR0         2    /* CR0 was hit: gfn is new CR0 value, gla is previous */
-#define MEM_EVENT_REASON_CR3         3    /* CR3 was hit: gfn is new CR3 value, gla is previous */
-#define MEM_EVENT_REASON_CR4         4    /* CR4 was hit: gfn is new CR4 value, gla is previous */
-#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 */
-#define MEM_EVENT_REASON_MSR         7    /* MSR was hit: gfn is MSR value, gla is MSR address;
-                                             does NOT honour HVMPME_onchangeonly */
+typedef enum {
+    MEM_EVENT_REASON_UNKNOWN,              /* Default case */
+    MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
+    MEM_EVENT_REASON_MEM_SHARING,          /* Memory sharing event */
+    MEM_EVENT_REASON_MEM_PAGING,           /* Memory paging event */
+    MEM_EVENT_REASON_CR0,                  /* CR0 was updated */
+    MEM_EVENT_REASON_CR3,                  /* CR3 was updated */
+    MEM_EVENT_REASON_CR4,                  /* CR4 was updated */
+    MEM_EVENT_REASON_INT3,                 /* Debug operation executed (int3) */
+    MEM_EVENT_REASON_SINGLESTEP,           /* Single-step (MTF) */
+    MEM_EVENT_REASON_MSR,                  /* An MSR was updated.
+                                            * Does NOT honour HVMPME_onchangeonly */
+} mem_event_reason_t;
 
 /* Using a custom struct (not hvm_hw_cpu) so as to not fill
  * the mem_event ring buffer too quickly. */
@@ -97,16 +101,10 @@ struct mem_event_regs_x86 {
     uint32_t _pad;
 };
 
-typedef struct mem_event_st {
-    uint32_t flags;
-    uint32_t vcpu_id;
-
+struct mem_event_mem_access_data {
     uint64_t gfn;
     uint64_t offset;
     uint64_t gla; /* if gla_valid */
-
-    uint32_t p2mt;
-
     uint16_t access_r:1;
     uint16_t access_w:1;
     uint16_t access_x:1;
@@ -114,8 +112,55 @@ typedef struct mem_event_st {
     uint16_t fault_with_gla:1;
     uint16_t fault_in_gpt:1;
     uint16_t available:10;
+};
+
+struct mem_event_cr_data {
+    uint64_t new_value;
+    uint64_t old_value;
+};
+
+struct mem_event_int3_data {
+    uint64_t gfn;
+    uint64_t gla;
+};
+
+struct mem_event_singlestep_data {
+    uint64_t gfn;
+    uint64_t gla;
+};
+
+struct mem_event_msr_data {
+    uint64_t msr;
+    uint64_t old_value;
+    uint64_t new_value;
+};
+
+struct mem_event_paging_data {
+    uint64_t gfn;
+    uint32_t p2mt;
+};
+
+struct mem_event_sharing_data {
+    uint64_t gfn;
+    uint32_t p2mt;
+};
+
+typedef struct mem_event_st {
+    uint32_t flags;
+    uint32_t vcpu_id;
+
+    mem_event_reason_t reason;
+
+    union {
+        struct mem_event_paging_data     mem_paging_event;
+        struct mem_event_sharing_data    mem_sharing_event;
+        struct mem_event_mem_access_data mem_access_event;
+        struct mem_event_cr_data         cr_event;
+        struct mem_event_int3_data       int3_event;
+        struct mem_event_singlestep_data singlestep_event;
+        struct mem_event_msr_data        msr_event;
+    };
 
-    uint16_t reason;
     struct mem_event_regs_x86 x86_regs;
 } mem_event_request_t, mem_event_response_t;
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZu7-0007s9-8e; Wed, 12 Nov 2014 15:32:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZu6-0007rP-9k
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:18 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	7B/46-02953-18D73645; Wed, 12 Nov 2014 15:32:17 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415806334!12092587!1
X-Originating-IP: [209.85.216.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8705 invoked from network); 12 Nov 2014 15:32:15 -0000
Received: from mail-qc0-f174.google.com (HELO mail-qc0-f174.google.com)
	(209.85.216.174)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:15 -0000
Received: by mail-qc0-f174.google.com with SMTP id r5so9355624qcx.5
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=87VEqdIYyRMDxCavxx5BNfUwI+1bpkZFae5gDhTkRUo=;
	b=NgxgoigEJplnr8uPGx+f4Ks8JU6taIUKDMfKg4rXJcaPGt8RA36h2BvhCXQU7DNpRV
	S475N6W+/y/QGCIMCLZlU6JGRabaWQLFfFAvPea6IJ5Uf+Xo3syMgqZs1Ff3pthWnalA
	bv/Zve050xfBQ77tPQcYNOeuK1CU1q3hTGAig81KmzAz1SPJ2uLy8Koc8YW9hZUqKigy
	V0hfa/Q4BoUAtpBOPGmUnyCnpi2X+rsBtEWjnNdj86+QcWlM1mbd6y5R5xA8lr5k3ziG
	A3h4jvydrvPpJsmXy1bo6D28uTUqtwshkf/d+gXkjwk6a6ITALXp6fiNwlR1Vs9bYHGo
	OC2g==
X-Gm-Message-State: ALoCoQkviBVHzTLClioL7HJX5zADlh6/scvJV/b5nVbHP+pmPd63oB4fhFLSwlfuMchCxi/n26q3
X-Received: by 10.140.93.163 with SMTP id d32mr5075131qge.37.1415806334529;
	Wed, 12 Nov 2014 07:32:14 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.12 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:14 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:44 +0100
Message-Id: <1415806309-5206-3-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 2/7] xen/mem_event: Rename the mem_event
	ring from 'access' to 'monitor'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 name of the ring still implies it is used only for memory accesses,
which is no longer the case. It is also used to deliver variuos HVM events,
thus the name "monitor" is more appropriate in this setting.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 tools/libxc/xc_domain_restore.c | 14 +++++++-------
 tools/libxc/xc_domain_save.c    |  4 ++--
 tools/libxc/xc_hvm_build_x86.c  |  2 +-
 tools/libxc/xc_mem_access.c     |  8 ++++----
 tools/libxc/xc_mem_event.c      |  8 ++++----
 tools/libxc/xg_save_restore.h   |  2 +-
 xen/arch/x86/hvm/hvm.c          |  4 ++--
 xen/arch/x86/hvm/vmx/vmcs.c     |  2 +-
 xen/arch/x86/mm/p2m.c           |  2 +-
 xen/common/mem_access.c         |  8 ++++----
 xen/common/mem_event.c          | 22 +++++++++++-----------
 xen/include/public/domctl.h     | 12 ++++++------
 xen/include/public/hvm/params.h |  2 +-
 xen/include/xen/sched.h         |  4 ++--
 14 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index d8bd9b3..bc6c618 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -734,7 +734,7 @@ typedef struct {
     uint64_t vcpumap[XC_SR_MAX_VCPUS/64];
     uint64_t identpt;
     uint64_t paging_ring_pfn;
-    uint64_t access_ring_pfn;
+    uint64_t monitor_ring_pfn;
     uint64_t sharing_ring_pfn;
     uint64_t vm86_tss;
     uint64_t console_pfn;
@@ -828,15 +828,15 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         // 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:
+    case XC_SAVE_ID_HVM_MONITOR_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)) )
+        if ( RDEXACT(fd, &buf->monitor_ring_pfn, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->monitor_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);
+        // DPRINTF("monitor ring pfn address: %llx\n", buf->monitor_ring_pfn);
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
     case XC_SAVE_ID_HVM_SHARING_RING_PFN:
@@ -1660,8 +1660,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                 xc_hvm_param_set(xch, dom, HVM_PARAM_IDENT_PT, pagebuf.identpt);
             if ( pagebuf.paging_ring_pfn )
                 xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN, pagebuf.paging_ring_pfn);
-            if ( pagebuf.access_ring_pfn )
-                xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN, pagebuf.access_ring_pfn);
+            if ( pagebuf.monitor_ring_pfn )
+                xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN, pagebuf.monitor_ring_pfn);
             if ( pagebuf.sharing_ring_pfn )
                 xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN, pagebuf.sharing_ring_pfn);
             if ( pagebuf.vm86_tss )
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index 254fdb3..949ef64 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1664,9 +1664,9 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
             goto out;
         }
 
-        chunk.id = XC_SAVE_ID_HVM_ACCESS_RING_PFN;
+        chunk.id = XC_SAVE_ID_HVM_MONITOR_RING_PFN;
         chunk.data = 0;
-        xc_hvm_param_get(xch, dom, HVM_PARAM_ACCESS_RING_PFN, &chunk.data);
+        xc_hvm_param_get(xch, dom, HVM_PARAM_MONITOR_RING_PFN, &chunk.data);
 
         if ( (chunk.data != 0) &&
              wrexact(io_fd, &chunk, sizeof(chunk)) )
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..30a929d 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -497,7 +497,7 @@ static int setup_guest(xc_interface *xch,
                      special_pfn(SPECIALPAGE_CONSOLE));
     xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN,
                      special_pfn(SPECIALPAGE_PAGING));
-    xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
+    xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN,
                      special_pfn(SPECIALPAGE_ACCESS));
     xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN,
                      special_pfn(SPECIALPAGE_SHARING));
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 55d0e9f..1c979ed 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -26,22 +26,22 @@
 
 void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t *port)
 {
-    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_ACCESS_RING_PFN,
+    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
                                port, 0);
 }
 
 void *xc_mem_access_enable_introspection(xc_interface *xch, domid_t domain_id,
                                          uint32_t *port)
 {
-    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_ACCESS_RING_PFN,
+    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
                                port, 1);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
 {
     return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
+                                XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE,
+                                XEN_DOMCTL_MEM_EVENT_OP_MONITOR,
                                 NULL);
 }
 
diff --git a/tools/libxc/xc_mem_event.c b/tools/libxc/xc_mem_event.c
index 8c0be4e..20db2ed 100644
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -119,12 +119,12 @@ void *xc_mem_event_enable(xc_interface *xch, domid_t domain_id, int param,
         mode = XEN_DOMCTL_MEM_EVENT_OP_PAGING;
         break;
 
-    case HVM_PARAM_ACCESS_RING_PFN:
+    case HVM_PARAM_MONITOR_RING_PFN:
         if ( enable_introspection )
-            op = XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE_INTROSPECTION;
+            op = XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION;
         else
-            op = XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE;
-        mode = XEN_DOMCTL_MEM_EVENT_OP_ACCESS;
+            op = XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE;
+        mode = XEN_DOMCTL_MEM_EVENT_OP_MONITOR;
         break;
 
     case HVM_PARAM_SHARING_RING_PFN:
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index bdd9009..10348aa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -256,7 +256,7 @@
 #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_MONITOR_RING_PFN -16
 #define XC_SAVE_ID_HVM_SHARING_RING_PFN -17
 #define XC_SAVE_ID_TOOLSTACK          -18 /* Optional toolstack specific info */
 /* These are a pair; it is an error for one to exist without the other */
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 67782c8..b34cdbd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -6194,7 +6194,7 @@ static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
     if ( !(parameters & HVMPME_MODE_MASK) )
         return 0;
 
-    rc = mem_event_claim_slot(d, &d->mem_event->access);
+    rc = mem_event_claim_slot(d, &d->mem_event->monitor);
     if ( rc == -ENOSYS )
     {
         /* If there was no ring to handle the event, then
@@ -6211,7 +6211,7 @@ static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
     }
 
     hvm_mem_event_fill_regs(req);
-    mem_event_put_request(d, &d->mem_event->access, req);
+    mem_event_put_request(d, &d->mem_event->monitor, req);
 
     return 1;
 }
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 9d8033e..e553fb0 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -715,7 +715,7 @@ void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type)
         return;
 
     if ( unlikely(d->arch.hvm_domain.introspection_enabled) &&
-         mem_event_check_ring(&d->mem_event->access) )
+         mem_event_check_ring(&d->mem_event->monitor) )
     {
         unsigned int i;
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index cfd3ff5..5c15b14 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1489,7 +1489,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
     gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    if ( !mem_event_check_ring(&d->mem_event->access) || !req_ptr ) 
+    if ( !mem_event_check_ring(&d->mem_event->monitor) || !req_ptr ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index 6c2724b..0a4fe51 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -34,7 +34,7 @@ void mem_access_resume(struct domain *d)
     mem_event_response_t rsp;
 
     /* Pull all responses off the ring. */
-    while ( mem_event_get_response(d, &d->mem_event->access, &rsp) )
+    while ( mem_event_get_response(d, &d->mem_event->monitor, &rsp) )
     {
         struct vcpu *v;
 
@@ -78,7 +78,7 @@ int mem_access_memop(unsigned long cmd,
         goto out;
 
     rc = -ENODEV;
-    if ( unlikely(!d->mem_event->access.ring_page) )
+    if ( unlikely(!d->mem_event->monitor.ring_page) )
         goto out;
 
     switch ( mao.op )
@@ -140,11 +140,11 @@ int mem_access_memop(unsigned long cmd,
 
 int mem_access_send_req(struct domain *d, mem_event_request_t *req)
 {
-    int rc = mem_event_claim_slot(d, &d->mem_event->access);
+    int rc = mem_event_claim_slot(d, &d->mem_event->monitor);
     if ( rc < 0 )
         return rc;
 
-    mem_event_put_request(d, &d->mem_event->access, req);
+    mem_event_put_request(d, &d->mem_event->monitor, req);
 
     return 0;
 }
diff --git a/xen/common/mem_event.c b/xen/common/mem_event.c
index 16ebdb5..37b5558 100644
--- a/xen/common/mem_event.c
+++ b/xen/common/mem_event.c
@@ -443,7 +443,7 @@ static void mem_paging_notification(struct vcpu *v, unsigned int port)
 /* Registered with Xen-bound event channel for incoming notifications. */
 static void mem_access_notification(struct vcpu *v, unsigned int port)
 {
-    if ( likely(v->domain->mem_event->access.ring_page != NULL) )
+    if ( likely(v->domain->mem_event->monitor.ring_page != NULL) )
         mem_access_resume(v->domain);
 }
 #endif
@@ -508,9 +508,9 @@ void mem_event_cleanup(struct domain *d)
     }
 #endif
 #ifdef HAS_MEM_ACCESS
-    if ( d->mem_event->access.ring_page ) {
-        destroy_waitqueue_head(&d->mem_event->access.wq);
-        (void)mem_event_disable(d, &d->mem_event->access);
+    if ( d->mem_event->monitor.ring_page ) {
+        destroy_waitqueue_head(&d->mem_event->monitor.wq);
+        (void)mem_event_disable(d, &d->mem_event->monitor);
     }
 #endif
 #ifdef HAS_MEM_SHARING
@@ -609,32 +609,32 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
 #endif
 
 #ifdef HAS_MEM_ACCESS
-    case XEN_DOMCTL_MEM_EVENT_OP_ACCESS:
+    case XEN_DOMCTL_MEM_EVENT_OP_MONITOR:
     {
-        struct mem_event_domain *med = &d->mem_event->access;
+        struct mem_event_domain *med = &d->mem_event->monitor;
         rc = -EINVAL;
 
         switch( mec->op )
         {
-        case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE:
-        case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE_INTROSPECTION:
+        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE:
+        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION:
         {
             rc = -ENODEV;
             if ( !p2m_mem_event_sanity_check(d) )
                 break;
 
             rc = mem_event_enable(d, mec, med, _VPF_mem_access,
-                                    HVM_PARAM_ACCESS_RING_PFN,
+                                    HVM_PARAM_MONITOR_RING_PFN,
                                     mem_access_notification);
 
-            if ( mec->op == XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE_INTROSPECTION
+            if ( mec->op == XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION
                  && !rc )
                 p2m_setup_introspection(d);
 
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
+        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE:
         {
             if ( med->ring_page )
             {
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 8da204e..9d2cc38 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -775,7 +775,7 @@ struct xen_domctl_gdbsx_domstatus {
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE    1
 
 /*
- * Access permissions.
+ * Monitor permissions.
  *
  * As with paging, use the domctl for teardown/setup of the
  * helper<->hypervisor interface.
@@ -788,16 +788,16 @@ struct xen_domctl_gdbsx_domstatus {
  * The memory event handler can then resume the VCPU and redo the access 
  * with a XENMEM_access_op_resume hypercall.
  *
- * The XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE domctl returns several
+ * The XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE domctl returns several
  * non-standard error codes to indicate why access could not be enabled:
  * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
  * EBUSY  - guest has or had access enabled, ring buffer still active
  */
-#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS                        2
+#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR                        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_ENABLE_INTROSPECTION   2
+#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE                 0
+#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE                1
+#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION   2
 
 /*
  * Sharing ENOMEM helper.
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index 3c51072..489ab09 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -177,7 +177,7 @@
 
 /* Params for the mem event rings */
 #define HVM_PARAM_PAGING_RING_PFN   27
-#define HVM_PARAM_ACCESS_RING_PFN   28
+#define HVM_PARAM_MONITOR_RING_PFN  28
 #define HVM_PARAM_SHARING_RING_PFN  29
 
 /* SHUTDOWN_* action in case of a triple fault */
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 46fc6e3..2fc36ea 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -288,8 +288,8 @@ struct mem_event_per_domain
     struct mem_event_domain share;
     /* Memory paging support */
     struct mem_event_domain paging;
-    /* Memory access support */
-    struct mem_event_domain access;
+    /* VM event monitor support */
+    struct mem_event_domain monitor;
 };
 
 struct evtchn_port_ops;
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZu2-0007qp-8x; Wed, 12 Nov 2014 15:32:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZu0-0007qi-Vo
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:13 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	A0/26-11581-C7D73645; Wed, 12 Nov 2014 15:32:12 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415806330!10900142!1
X-Originating-IP: [209.85.216.47]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13184 invoked from network); 12 Nov 2014 15:32:11 -0000
Received: from mail-qa0-f47.google.com (HELO mail-qa0-f47.google.com)
	(209.85.216.47)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:11 -0000
Received: by mail-qa0-f47.google.com with SMTP id dc16so8689789qab.34
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=oLYmC4NWKJjDh2gg0txtpkxEFXJSHYz1TXX2utLGWH4=;
	b=dmuO6XL0mBKF7t511tlaaogCplp0G5L92MgBtywtSD47+xO74nUCQfeGAcCifNOoMM
	lz+GDBzINqXTOleSnSAAPkSwfGbrGEoyZDp2YE8B0qYtiJjEBac9IOyydM8VhTVMsevp
	nFQeJDC8xpuR3lWGOn4VeER+L5PhdR+amj4JcDyEwy/HBUtcvQeVRlRra3BaZJcFCT0B
	i2on+qNyMQuDUb4FANIV9aJBOy+uBkeYrtgKhbfXPSnVOzuqCShqfubJZIwnW3OH2bB+
	u7omuuWC4iMQi31QhcwW1KV4MPkZ/UeuHTG9cxk5kd9coH5cN7V0WbzqKP1e1f0UsRr6
	Vo/A==
X-Gm-Message-State: ALoCoQlEQgafz83eGUBc396Dlrlat2KRrAIZS05SzycUY+WkbNHHnt6jV5MnqJYwidiKLSZJ/IKA
X-Received: by 10.140.102.116 with SMTP id v107mr2453539qge.68.1415806329941; 
	Wed, 12 Nov 2014 07:32:09 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.07 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:09 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:42 +0100
Message-Id: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsystem
has since been extended to also deliver non-memory related events, namely
various HVM debugging events (INT3, MTF, MOV-TO-CR). The structures and naming
of related functions however has not caught up to these new use-cases, thus
leaving many ambigouities in the code.

In this series we convert the mem_event structures to a union of sub-structures
which clearly define the scope of information that is transmitted via the event
delivery mechanism. Afterwards, we clean up the naming of the structures and
related functions to more clearly be in line with their actual operations.

This PATCH RFC series is also available at:
https://github.com/tklengyel/xen/tree/mem_event_cleanup

Razvan Cojocaru (1):
  xen/mem_event: Cleanup of mem_event structures

Tamas K Lengyel (6):
  xen/mem_event: Rename the mem_event ring from 'access' to 'monitor'
  xen/mem_paging: Convert mem_event_op to mem_paging_op
  x86/hvm: rename hvm_memory_event_* functions to hvm_event_*
  xen/mem_event: Rename mem_event to vm_event
  xen/vm_event: Decouple vm_event and mem_access.
  tools/tests: Remove superfluous and incomplete spinlock from
    xen-access

 docs/misc/pvh-readme.txt            |   2 +-
 tools/libxc/Makefile                |   2 +-
 tools/libxc/xc_domain_restore.c     |  14 +-
 tools/libxc/xc_domain_save.c        |   4 +-
 tools/libxc/xc_hvm_build_x86.c      |   2 +-
 tools/libxc/xc_mem_access.c         |  10 +-
 tools/libxc/xc_mem_event.c          | 178 ---------
 tools/libxc/xc_mem_paging.c         |  38 +-
 tools/libxc/xc_memshr.c             |  12 +-
 tools/libxc/xc_private.h            |   9 +-
 tools/libxc/xc_vm_event.c           | 162 ++++++++
 tools/libxc/xg_save_restore.h       |   2 +-
 tools/tests/xen-access/xen-access.c | 187 ++++-----
 tools/xenpaging/pagein.c            |   2 +-
 tools/xenpaging/xenpaging.c         | 150 ++++----
 tools/xenpaging/xenpaging.h         |   8 +-
 xen/arch/x86/domain.c               |   2 +-
 xen/arch/x86/domctl.c               |   4 +-
 xen/arch/x86/hvm/emulate.c          |   4 +-
 xen/arch/x86/hvm/hvm.c              | 171 +++++----
 xen/arch/x86/hvm/vmx/vmcs.c         |   4 +-
 xen/arch/x86/hvm/vmx/vmx.c          |   6 +-
 xen/arch/x86/mm/hap/nested_ept.c    |   4 +-
 xen/arch/x86/mm/hap/nested_hap.c    |   4 +-
 xen/arch/x86/mm/mem_paging.c        |  16 +-
 xen/arch/x86/mm/mem_sharing.c       |  31 +-
 xen/arch/x86/mm/p2m-pod.c           |   4 +-
 xen/arch/x86/mm/p2m-pt.c            |   4 +-
 xen/arch/x86/mm/p2m.c               | 139 +++----
 xen/arch/x86/x86_64/compat/mm.c     |  12 +-
 xen/arch/x86/x86_64/mm.c            |  12 +-
 xen/common/Makefile                 |   2 +-
 xen/common/domain.c                 |  12 +-
 xen/common/domctl.c                 |   6 +-
 xen/common/mem_access.c             |  24 +-
 xen/common/mem_event.c              | 742 ------------------------------------
 xen/common/vm_event.c               | 742 ++++++++++++++++++++++++++++++++++++
 xen/drivers/passthrough/pci.c       |   2 +-
 xen/include/asm-arm/p2m.h           |   6 +-
 xen/include/asm-x86/domain.h        |   4 +-
 xen/include/asm-x86/hvm/emulate.h   |   2 +-
 xen/include/asm-x86/hvm/hvm.h       |  12 +-
 xen/include/asm-x86/mem_paging.h    |   2 +-
 xen/include/asm-x86/p2m.h           |  16 +-
 xen/include/public/domctl.h         |  44 +--
 xen/include/public/hvm/params.h     |   2 +-
 xen/include/public/mem_event.h      | 134 -------
 xen/include/public/memory.h         |   6 +-
 xen/include/public/vm_event.h       | 179 +++++++++
 xen/include/xen/mem_access.h        |   4 +-
 xen/include/xen/mem_event.h         | 143 -------
 xen/include/xen/p2m-common.h        |   4 +-
 xen/include/xen/sched.h             |  24 +-
 xen/include/xen/vm_event.h          |  87 +++++
 xen/include/xsm/dummy.h             |   6 +-
 xen/include/xsm/xsm.h               |  14 +-
 xen/xsm/dummy.c                     |   6 +-
 xen/xsm/flask/hooks.c               |  36 +-
 xen/xsm/flask/policy/access_vectors |   2 +-
 59 files changed, 1700 insertions(+), 1762 deletions(-)
 delete mode 100644 tools/libxc/xc_mem_event.c
 create mode 100644 tools/libxc/xc_vm_event.c
 delete mode 100644 xen/common/mem_event.c
 create mode 100644 xen/common/vm_event.c
 delete mode 100644 xen/include/public/mem_event.h
 create mode 100644 xen/include/public/vm_event.h
 delete mode 100644 xen/include/xen/mem_event.h
 create mode 100644 xen/include/xen/vm_event.h

-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZu2-0007qp-8x; Wed, 12 Nov 2014 15:32:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZu0-0007qi-Vo
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:13 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	A0/26-11581-C7D73645; Wed, 12 Nov 2014 15:32:12 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415806330!10900142!1
X-Originating-IP: [209.85.216.47]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13184 invoked from network); 12 Nov 2014 15:32:11 -0000
Received: from mail-qa0-f47.google.com (HELO mail-qa0-f47.google.com)
	(209.85.216.47)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:11 -0000
Received: by mail-qa0-f47.google.com with SMTP id dc16so8689789qab.34
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=oLYmC4NWKJjDh2gg0txtpkxEFXJSHYz1TXX2utLGWH4=;
	b=dmuO6XL0mBKF7t511tlaaogCplp0G5L92MgBtywtSD47+xO74nUCQfeGAcCifNOoMM
	lz+GDBzINqXTOleSnSAAPkSwfGbrGEoyZDp2YE8B0qYtiJjEBac9IOyydM8VhTVMsevp
	nFQeJDC8xpuR3lWGOn4VeER+L5PhdR+amj4JcDyEwy/HBUtcvQeVRlRra3BaZJcFCT0B
	i2on+qNyMQuDUb4FANIV9aJBOy+uBkeYrtgKhbfXPSnVOzuqCShqfubJZIwnW3OH2bB+
	u7omuuWC4iMQi31QhcwW1KV4MPkZ/UeuHTG9cxk5kd9coH5cN7V0WbzqKP1e1f0UsRr6
	Vo/A==
X-Gm-Message-State: ALoCoQlEQgafz83eGUBc396Dlrlat2KRrAIZS05SzycUY+WkbNHHnt6jV5MnqJYwidiKLSZJ/IKA
X-Received: by 10.140.102.116 with SMTP id v107mr2453539qge.68.1415806329941; 
	Wed, 12 Nov 2014 07:32:09 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.07 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:09 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:42 +0100
Message-Id: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsystem
has since been extended to also deliver non-memory related events, namely
various HVM debugging events (INT3, MTF, MOV-TO-CR). The structures and naming
of related functions however has not caught up to these new use-cases, thus
leaving many ambigouities in the code.

In this series we convert the mem_event structures to a union of sub-structures
which clearly define the scope of information that is transmitted via the event
delivery mechanism. Afterwards, we clean up the naming of the structures and
related functions to more clearly be in line with their actual operations.

This PATCH RFC series is also available at:
https://github.com/tklengyel/xen/tree/mem_event_cleanup

Razvan Cojocaru (1):
  xen/mem_event: Cleanup of mem_event structures

Tamas K Lengyel (6):
  xen/mem_event: Rename the mem_event ring from 'access' to 'monitor'
  xen/mem_paging: Convert mem_event_op to mem_paging_op
  x86/hvm: rename hvm_memory_event_* functions to hvm_event_*
  xen/mem_event: Rename mem_event to vm_event
  xen/vm_event: Decouple vm_event and mem_access.
  tools/tests: Remove superfluous and incomplete spinlock from
    xen-access

 docs/misc/pvh-readme.txt            |   2 +-
 tools/libxc/Makefile                |   2 +-
 tools/libxc/xc_domain_restore.c     |  14 +-
 tools/libxc/xc_domain_save.c        |   4 +-
 tools/libxc/xc_hvm_build_x86.c      |   2 +-
 tools/libxc/xc_mem_access.c         |  10 +-
 tools/libxc/xc_mem_event.c          | 178 ---------
 tools/libxc/xc_mem_paging.c         |  38 +-
 tools/libxc/xc_memshr.c             |  12 +-
 tools/libxc/xc_private.h            |   9 +-
 tools/libxc/xc_vm_event.c           | 162 ++++++++
 tools/libxc/xg_save_restore.h       |   2 +-
 tools/tests/xen-access/xen-access.c | 187 ++++-----
 tools/xenpaging/pagein.c            |   2 +-
 tools/xenpaging/xenpaging.c         | 150 ++++----
 tools/xenpaging/xenpaging.h         |   8 +-
 xen/arch/x86/domain.c               |   2 +-
 xen/arch/x86/domctl.c               |   4 +-
 xen/arch/x86/hvm/emulate.c          |   4 +-
 xen/arch/x86/hvm/hvm.c              | 171 +++++----
 xen/arch/x86/hvm/vmx/vmcs.c         |   4 +-
 xen/arch/x86/hvm/vmx/vmx.c          |   6 +-
 xen/arch/x86/mm/hap/nested_ept.c    |   4 +-
 xen/arch/x86/mm/hap/nested_hap.c    |   4 +-
 xen/arch/x86/mm/mem_paging.c        |  16 +-
 xen/arch/x86/mm/mem_sharing.c       |  31 +-
 xen/arch/x86/mm/p2m-pod.c           |   4 +-
 xen/arch/x86/mm/p2m-pt.c            |   4 +-
 xen/arch/x86/mm/p2m.c               | 139 +++----
 xen/arch/x86/x86_64/compat/mm.c     |  12 +-
 xen/arch/x86/x86_64/mm.c            |  12 +-
 xen/common/Makefile                 |   2 +-
 xen/common/domain.c                 |  12 +-
 xen/common/domctl.c                 |   6 +-
 xen/common/mem_access.c             |  24 +-
 xen/common/mem_event.c              | 742 ------------------------------------
 xen/common/vm_event.c               | 742 ++++++++++++++++++++++++++++++++++++
 xen/drivers/passthrough/pci.c       |   2 +-
 xen/include/asm-arm/p2m.h           |   6 +-
 xen/include/asm-x86/domain.h        |   4 +-
 xen/include/asm-x86/hvm/emulate.h   |   2 +-
 xen/include/asm-x86/hvm/hvm.h       |  12 +-
 xen/include/asm-x86/mem_paging.h    |   2 +-
 xen/include/asm-x86/p2m.h           |  16 +-
 xen/include/public/domctl.h         |  44 +--
 xen/include/public/hvm/params.h     |   2 +-
 xen/include/public/mem_event.h      | 134 -------
 xen/include/public/memory.h         |   6 +-
 xen/include/public/vm_event.h       | 179 +++++++++
 xen/include/xen/mem_access.h        |   4 +-
 xen/include/xen/mem_event.h         | 143 -------
 xen/include/xen/p2m-common.h        |   4 +-
 xen/include/xen/sched.h             |  24 +-
 xen/include/xen/vm_event.h          |  87 +++++
 xen/include/xsm/dummy.h             |   6 +-
 xen/include/xsm/xsm.h               |  14 +-
 xen/xsm/dummy.c                     |   6 +-
 xen/xsm/flask/hooks.c               |  36 +-
 xen/xsm/flask/policy/access_vectors |   2 +-
 59 files changed, 1700 insertions(+), 1762 deletions(-)
 delete mode 100644 tools/libxc/xc_mem_event.c
 create mode 100644 tools/libxc/xc_vm_event.c
 delete mode 100644 xen/common/mem_event.c
 create mode 100644 xen/common/vm_event.c
 delete mode 100644 xen/include/public/mem_event.h
 create mode 100644 xen/include/public/vm_event.h
 delete mode 100644 xen/include/xen/mem_event.h
 create mode 100644 xen/include/xen/vm_event.h

-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZu7-0007s9-8e; Wed, 12 Nov 2014 15:32:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZu6-0007rP-9k
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:18 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	7B/46-02953-18D73645; Wed, 12 Nov 2014 15:32:17 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415806334!12092587!1
X-Originating-IP: [209.85.216.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8705 invoked from network); 12 Nov 2014 15:32:15 -0000
Received: from mail-qc0-f174.google.com (HELO mail-qc0-f174.google.com)
	(209.85.216.174)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:15 -0000
Received: by mail-qc0-f174.google.com with SMTP id r5so9355624qcx.5
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=87VEqdIYyRMDxCavxx5BNfUwI+1bpkZFae5gDhTkRUo=;
	b=NgxgoigEJplnr8uPGx+f4Ks8JU6taIUKDMfKg4rXJcaPGt8RA36h2BvhCXQU7DNpRV
	S475N6W+/y/QGCIMCLZlU6JGRabaWQLFfFAvPea6IJ5Uf+Xo3syMgqZs1Ff3pthWnalA
	bv/Zve050xfBQ77tPQcYNOeuK1CU1q3hTGAig81KmzAz1SPJ2uLy8Koc8YW9hZUqKigy
	V0hfa/Q4BoUAtpBOPGmUnyCnpi2X+rsBtEWjnNdj86+QcWlM1mbd6y5R5xA8lr5k3ziG
	A3h4jvydrvPpJsmXy1bo6D28uTUqtwshkf/d+gXkjwk6a6ITALXp6fiNwlR1Vs9bYHGo
	OC2g==
X-Gm-Message-State: ALoCoQkviBVHzTLClioL7HJX5zADlh6/scvJV/b5nVbHP+pmPd63oB4fhFLSwlfuMchCxi/n26q3
X-Received: by 10.140.93.163 with SMTP id d32mr5075131qge.37.1415806334529;
	Wed, 12 Nov 2014 07:32:14 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.12 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:14 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:44 +0100
Message-Id: <1415806309-5206-3-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 2/7] xen/mem_event: Rename the mem_event
	ring from 'access' to 'monitor'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 name of the ring still implies it is used only for memory accesses,
which is no longer the case. It is also used to deliver variuos HVM events,
thus the name "monitor" is more appropriate in this setting.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 tools/libxc/xc_domain_restore.c | 14 +++++++-------
 tools/libxc/xc_domain_save.c    |  4 ++--
 tools/libxc/xc_hvm_build_x86.c  |  2 +-
 tools/libxc/xc_mem_access.c     |  8 ++++----
 tools/libxc/xc_mem_event.c      |  8 ++++----
 tools/libxc/xg_save_restore.h   |  2 +-
 xen/arch/x86/hvm/hvm.c          |  4 ++--
 xen/arch/x86/hvm/vmx/vmcs.c     |  2 +-
 xen/arch/x86/mm/p2m.c           |  2 +-
 xen/common/mem_access.c         |  8 ++++----
 xen/common/mem_event.c          | 22 +++++++++++-----------
 xen/include/public/domctl.h     | 12 ++++++------
 xen/include/public/hvm/params.h |  2 +-
 xen/include/xen/sched.h         |  4 ++--
 14 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index d8bd9b3..bc6c618 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -734,7 +734,7 @@ typedef struct {
     uint64_t vcpumap[XC_SR_MAX_VCPUS/64];
     uint64_t identpt;
     uint64_t paging_ring_pfn;
-    uint64_t access_ring_pfn;
+    uint64_t monitor_ring_pfn;
     uint64_t sharing_ring_pfn;
     uint64_t vm86_tss;
     uint64_t console_pfn;
@@ -828,15 +828,15 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         // 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:
+    case XC_SAVE_ID_HVM_MONITOR_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)) )
+        if ( RDEXACT(fd, &buf->monitor_ring_pfn, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->monitor_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);
+        // DPRINTF("monitor ring pfn address: %llx\n", buf->monitor_ring_pfn);
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
     case XC_SAVE_ID_HVM_SHARING_RING_PFN:
@@ -1660,8 +1660,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                 xc_hvm_param_set(xch, dom, HVM_PARAM_IDENT_PT, pagebuf.identpt);
             if ( pagebuf.paging_ring_pfn )
                 xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN, pagebuf.paging_ring_pfn);
-            if ( pagebuf.access_ring_pfn )
-                xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN, pagebuf.access_ring_pfn);
+            if ( pagebuf.monitor_ring_pfn )
+                xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN, pagebuf.monitor_ring_pfn);
             if ( pagebuf.sharing_ring_pfn )
                 xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN, pagebuf.sharing_ring_pfn);
             if ( pagebuf.vm86_tss )
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index 254fdb3..949ef64 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1664,9 +1664,9 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
             goto out;
         }
 
-        chunk.id = XC_SAVE_ID_HVM_ACCESS_RING_PFN;
+        chunk.id = XC_SAVE_ID_HVM_MONITOR_RING_PFN;
         chunk.data = 0;
-        xc_hvm_param_get(xch, dom, HVM_PARAM_ACCESS_RING_PFN, &chunk.data);
+        xc_hvm_param_get(xch, dom, HVM_PARAM_MONITOR_RING_PFN, &chunk.data);
 
         if ( (chunk.data != 0) &&
              wrexact(io_fd, &chunk, sizeof(chunk)) )
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..30a929d 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -497,7 +497,7 @@ static int setup_guest(xc_interface *xch,
                      special_pfn(SPECIALPAGE_CONSOLE));
     xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN,
                      special_pfn(SPECIALPAGE_PAGING));
-    xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
+    xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN,
                      special_pfn(SPECIALPAGE_ACCESS));
     xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN,
                      special_pfn(SPECIALPAGE_SHARING));
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 55d0e9f..1c979ed 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -26,22 +26,22 @@
 
 void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t *port)
 {
-    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_ACCESS_RING_PFN,
+    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
                                port, 0);
 }
 
 void *xc_mem_access_enable_introspection(xc_interface *xch, domid_t domain_id,
                                          uint32_t *port)
 {
-    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_ACCESS_RING_PFN,
+    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
                                port, 1);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
 {
     return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
+                                XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE,
+                                XEN_DOMCTL_MEM_EVENT_OP_MONITOR,
                                 NULL);
 }
 
diff --git a/tools/libxc/xc_mem_event.c b/tools/libxc/xc_mem_event.c
index 8c0be4e..20db2ed 100644
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -119,12 +119,12 @@ void *xc_mem_event_enable(xc_interface *xch, domid_t domain_id, int param,
         mode = XEN_DOMCTL_MEM_EVENT_OP_PAGING;
         break;
 
-    case HVM_PARAM_ACCESS_RING_PFN:
+    case HVM_PARAM_MONITOR_RING_PFN:
         if ( enable_introspection )
-            op = XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE_INTROSPECTION;
+            op = XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION;
         else
-            op = XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE;
-        mode = XEN_DOMCTL_MEM_EVENT_OP_ACCESS;
+            op = XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE;
+        mode = XEN_DOMCTL_MEM_EVENT_OP_MONITOR;
         break;
 
     case HVM_PARAM_SHARING_RING_PFN:
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index bdd9009..10348aa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -256,7 +256,7 @@
 #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_MONITOR_RING_PFN -16
 #define XC_SAVE_ID_HVM_SHARING_RING_PFN -17
 #define XC_SAVE_ID_TOOLSTACK          -18 /* Optional toolstack specific info */
 /* These are a pair; it is an error for one to exist without the other */
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 67782c8..b34cdbd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -6194,7 +6194,7 @@ static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
     if ( !(parameters & HVMPME_MODE_MASK) )
         return 0;
 
-    rc = mem_event_claim_slot(d, &d->mem_event->access);
+    rc = mem_event_claim_slot(d, &d->mem_event->monitor);
     if ( rc == -ENOSYS )
     {
         /* If there was no ring to handle the event, then
@@ -6211,7 +6211,7 @@ static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
     }
 
     hvm_mem_event_fill_regs(req);
-    mem_event_put_request(d, &d->mem_event->access, req);
+    mem_event_put_request(d, &d->mem_event->monitor, req);
 
     return 1;
 }
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 9d8033e..e553fb0 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -715,7 +715,7 @@ void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type)
         return;
 
     if ( unlikely(d->arch.hvm_domain.introspection_enabled) &&
-         mem_event_check_ring(&d->mem_event->access) )
+         mem_event_check_ring(&d->mem_event->monitor) )
     {
         unsigned int i;
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index cfd3ff5..5c15b14 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1489,7 +1489,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
     gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    if ( !mem_event_check_ring(&d->mem_event->access) || !req_ptr ) 
+    if ( !mem_event_check_ring(&d->mem_event->monitor) || !req_ptr ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index 6c2724b..0a4fe51 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -34,7 +34,7 @@ void mem_access_resume(struct domain *d)
     mem_event_response_t rsp;
 
     /* Pull all responses off the ring. */
-    while ( mem_event_get_response(d, &d->mem_event->access, &rsp) )
+    while ( mem_event_get_response(d, &d->mem_event->monitor, &rsp) )
     {
         struct vcpu *v;
 
@@ -78,7 +78,7 @@ int mem_access_memop(unsigned long cmd,
         goto out;
 
     rc = -ENODEV;
-    if ( unlikely(!d->mem_event->access.ring_page) )
+    if ( unlikely(!d->mem_event->monitor.ring_page) )
         goto out;
 
     switch ( mao.op )
@@ -140,11 +140,11 @@ int mem_access_memop(unsigned long cmd,
 
 int mem_access_send_req(struct domain *d, mem_event_request_t *req)
 {
-    int rc = mem_event_claim_slot(d, &d->mem_event->access);
+    int rc = mem_event_claim_slot(d, &d->mem_event->monitor);
     if ( rc < 0 )
         return rc;
 
-    mem_event_put_request(d, &d->mem_event->access, req);
+    mem_event_put_request(d, &d->mem_event->monitor, req);
 
     return 0;
 }
diff --git a/xen/common/mem_event.c b/xen/common/mem_event.c
index 16ebdb5..37b5558 100644
--- a/xen/common/mem_event.c
+++ b/xen/common/mem_event.c
@@ -443,7 +443,7 @@ static void mem_paging_notification(struct vcpu *v, unsigned int port)
 /* Registered with Xen-bound event channel for incoming notifications. */
 static void mem_access_notification(struct vcpu *v, unsigned int port)
 {
-    if ( likely(v->domain->mem_event->access.ring_page != NULL) )
+    if ( likely(v->domain->mem_event->monitor.ring_page != NULL) )
         mem_access_resume(v->domain);
 }
 #endif
@@ -508,9 +508,9 @@ void mem_event_cleanup(struct domain *d)
     }
 #endif
 #ifdef HAS_MEM_ACCESS
-    if ( d->mem_event->access.ring_page ) {
-        destroy_waitqueue_head(&d->mem_event->access.wq);
-        (void)mem_event_disable(d, &d->mem_event->access);
+    if ( d->mem_event->monitor.ring_page ) {
+        destroy_waitqueue_head(&d->mem_event->monitor.wq);
+        (void)mem_event_disable(d, &d->mem_event->monitor);
     }
 #endif
 #ifdef HAS_MEM_SHARING
@@ -609,32 +609,32 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
 #endif
 
 #ifdef HAS_MEM_ACCESS
-    case XEN_DOMCTL_MEM_EVENT_OP_ACCESS:
+    case XEN_DOMCTL_MEM_EVENT_OP_MONITOR:
     {
-        struct mem_event_domain *med = &d->mem_event->access;
+        struct mem_event_domain *med = &d->mem_event->monitor;
         rc = -EINVAL;
 
         switch( mec->op )
         {
-        case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE:
-        case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE_INTROSPECTION:
+        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE:
+        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION:
         {
             rc = -ENODEV;
             if ( !p2m_mem_event_sanity_check(d) )
                 break;
 
             rc = mem_event_enable(d, mec, med, _VPF_mem_access,
-                                    HVM_PARAM_ACCESS_RING_PFN,
+                                    HVM_PARAM_MONITOR_RING_PFN,
                                     mem_access_notification);
 
-            if ( mec->op == XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE_INTROSPECTION
+            if ( mec->op == XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION
                  && !rc )
                 p2m_setup_introspection(d);
 
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
+        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE:
         {
             if ( med->ring_page )
             {
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 8da204e..9d2cc38 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -775,7 +775,7 @@ struct xen_domctl_gdbsx_domstatus {
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE    1
 
 /*
- * Access permissions.
+ * Monitor permissions.
  *
  * As with paging, use the domctl for teardown/setup of the
  * helper<->hypervisor interface.
@@ -788,16 +788,16 @@ struct xen_domctl_gdbsx_domstatus {
  * The memory event handler can then resume the VCPU and redo the access 
  * with a XENMEM_access_op_resume hypercall.
  *
- * The XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE domctl returns several
+ * The XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE domctl returns several
  * non-standard error codes to indicate why access could not be enabled:
  * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
  * EBUSY  - guest has or had access enabled, ring buffer still active
  */
-#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS                        2
+#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR                        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_ENABLE_INTROSPECTION   2
+#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE                 0
+#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE                1
+#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION   2
 
 /*
  * Sharing ENOMEM helper.
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index 3c51072..489ab09 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -177,7 +177,7 @@
 
 /* Params for the mem event rings */
 #define HVM_PARAM_PAGING_RING_PFN   27
-#define HVM_PARAM_ACCESS_RING_PFN   28
+#define HVM_PARAM_MONITOR_RING_PFN  28
 #define HVM_PARAM_SHARING_RING_PFN  29
 
 /* SHUTDOWN_* action in case of a triple fault */
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 46fc6e3..2fc36ea 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -288,8 +288,8 @@ struct mem_event_per_domain
     struct mem_event_domain share;
     /* Memory paging support */
     struct mem_event_domain paging;
-    /* Memory access support */
-    struct mem_event_domain access;
+    /* VM event monitor support */
+    struct mem_event_domain monitor;
 };
 
 struct evtchn_port_ops;
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZu5-0007rE-L5; Wed, 12 Nov 2014 15:32:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZu3-0007qy-CI
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3B/E3-09936-E7D73645; Wed, 12 Nov 2014 15:32:14 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415806332!12240108!1
X-Originating-IP: [209.85.216.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11822 invoked from network); 12 Nov 2014 15:32:13 -0000
Received: from mail-qc0-f178.google.com (HELO mail-qc0-f178.google.com)
	(209.85.216.178)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:13 -0000
Received: by mail-qc0-f178.google.com with SMTP id b13so10363287qcw.23
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=VCd6nqnGpU0yN0kIYPg2J4NljVTDQdHlj/2fCwQ80Cc=;
	b=LuNkntY4CBZlj8t4qMEn8B22MCV3sQQkZSlfErlkKffQfTIO0HO4cnY7wYIRVOaSh+
	WisbELNV/+E6G+ph3R310Fa8o08jGF3Xx61GKMEdRFxa7CvDsvnoUvOtbb2BCGg7ki5m
	OVXa95Hu4A2Qb0yorvBBnvWI8bD8qYJr/nkuy4YoqledeSp3hn/4AswTk1ws2ogYHmrk
	nkXdFDPuG2FUWx6dL7ZeYThumC8iA3bjL3hBDCiHbP18cFi7F9VMVWAo13Cs/jCsP2Km
	mGEN1PqrN/FNzKrpj/ecgAF1LViIHC/eXHGMUpSnMUsbQ8jdVF1Xbk1jyHGjEl0HhGKD
	5a3Q==
X-Gm-Message-State: ALoCoQmWFdFuFZPCByie/v3Elz1g9Sb2PKI20s4bbcfwfTSa46W5IOQ+X6uAdpXmJIrKJGPkL2EJ
X-Received: by 10.140.91.245 with SMTP id z108mr48580624qgd.5.1415806332353;
	Wed, 12 Nov 2014 07:32:12 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.10 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:11 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:43 +0100
Message-Id: <1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Razvan Cojocaru <rcojocaru@bitdefender.com>

The public mem_event structures used to communicate with helper applications via
shared rings have been used in different settings. However, the variable names
within this structure have not reflected this fact, resulting in the reuse of
variables to mean different things under different scenarios.

This patch remedies the issue by clearly defining the structure members based on
the actual context within which the structure is used.

Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 tools/tests/xen-access/xen-access.c |  33 +++++----
 tools/xenpaging/xenpaging.c         |  34 ++++-----
 xen/arch/x86/hvm/hvm.c              | 137 +++++++++++++++++++++---------------
 xen/arch/x86/mm/mem_sharing.c       |   7 +-
 xen/arch/x86/mm/p2m.c               |  55 ++++++++-------
 xen/include/public/mem_event.h      |  79 ++++++++++++++++-----
 6 files changed, 211 insertions(+), 134 deletions(-)

diff --git a/tools/tests/xen-access/xen-access.c b/tools/tests/xen-access/xen-access.c
index 6cb382d..9d53fb3 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -556,8 +556,8 @@ int main(int argc, char *argv[])
             rsp.flags = req.flags;
 
             switch (req.reason) {
-            case MEM_EVENT_REASON_VIOLATION:
-                rc = xc_get_mem_access(xch, domain_id, req.gfn, &access);
+            case MEM_EVENT_REASON_MEM_ACCESS_VIOLATION:
+                rc = xc_get_mem_access(xch, domain_id, req.mem_access_event.gfn, &access);
                 if (rc < 0)
                 {
                     ERROR("Error %d getting mem_access event\n", rc);
@@ -567,21 +567,21 @@ int main(int argc, char *argv[])
 
                 printf("PAGE ACCESS: %c%c%c for GFN %"PRIx64" (offset %06"
                        PRIx64") gla %016"PRIx64" (valid: %c; fault in gpt: %c; fault with gla: %c) (vcpu %u)\n",
-                       req.access_r ? 'r' : '-',
-                       req.access_w ? 'w' : '-',
-                       req.access_x ? 'x' : '-',
-                       req.gfn,
-                       req.offset,
-                       req.gla,
-                       req.gla_valid ? 'y' : 'n',
-                       req.fault_in_gpt ? 'y' : 'n',
-                       req.fault_with_gla ? 'y': 'n',
+                       req.mem_access_event.access_r ? 'r' : '-',
+                       req.mem_access_event.access_w ? 'w' : '-',
+                       req.mem_access_event.access_x ? 'x' : '-',
+                       req.mem_access_event.gfn,
+                       req.mem_access_event.offset,
+                       req.mem_access_event.gla,
+                       req.mem_access_event.gla_valid ? 'y' : 'n',
+                       req.mem_access_event.fault_in_gpt ? 'y' : 'n',
+                       req.mem_access_event.fault_with_gla ? 'y': 'n',
                        req.vcpu_id);
 
                 if ( default_access != after_first_access )
                 {
                     rc = xc_set_mem_access(xch, domain_id, after_first_access,
-                                           req.gfn, 1);
+                                           req.mem_access_event.gfn, 1);
                     if (rc < 0)
                     {
                         ERROR("Error %d setting gfn to access_type %d\n", rc,
@@ -592,13 +592,12 @@ int main(int argc, char *argv[])
                 }
 
 
-                rsp.gfn = req.gfn;
-                rsp.p2mt = req.p2mt;
+                rsp.mem_access_event.gfn = req.mem_access_event.gfn;
                 break;
             case MEM_EVENT_REASON_INT3:
-                printf("INT3: rip=%016"PRIx64", gfn=%"PRIx64" (vcpu %d)\n", 
-                       req.gla, 
-                       req.gfn,
+                printf("INT3: rip=%016"PRIx64", gfn=%"PRIx64" (vcpu %d)\n",
+                       req.int3_event.gla,
+                       req.int3_event.gfn,
                        req.vcpu_id);
 
                 /* Reinject */
diff --git a/tools/xenpaging/xenpaging.c b/tools/xenpaging/xenpaging.c
index 82c1ee4..148b3e7 100644
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -684,9 +684,9 @@ static int xenpaging_resume_page(struct xenpaging *paging, mem_event_response_t
          * This allows page-out of these gfns if the target grows again.
          */
         if (paging->num_paged_out > paging->policy_mru_size)
-            policy_notify_paged_in(rsp->gfn);
+            policy_notify_paged_in(rsp->mem_paging_event.gfn);
         else
-            policy_notify_paged_in_nomru(rsp->gfn);
+            policy_notify_paged_in_nomru(rsp->mem_paging_event.gfn);
 
        /* Record number of resumed pages */
        paging->num_paged_out--;
@@ -910,49 +910,49 @@ int main(int argc, char *argv[])
 
             get_request(&paging->mem_event, &req);
 
-            if ( req.gfn > paging->max_pages )
+            if ( req.mem_paging_event.gfn > paging->max_pages )
             {
-                ERROR("Requested gfn %"PRIx64" higher than max_pages %x\n", req.gfn, paging->max_pages);
+                ERROR("Requested gfn %"PRIx64" higher than max_pages %x\n", req.mem_paging_event.gfn, paging->max_pages);
                 goto out;
             }
 
             /* Check if the page has already been paged in */
-            if ( test_and_clear_bit(req.gfn, paging->bitmap) )
+            if ( test_and_clear_bit(req.mem_paging_event.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                slot = paging->gfn_to_slot[req.gfn];
+                slot = paging->gfn_to_slot[req.mem_paging_event.gfn];
 
                 /* Sanity check */
-                if ( paging->slot_to_gfn[slot] != req.gfn )
+                if ( paging->slot_to_gfn[slot] != req.mem_paging_event.gfn )
                 {
-                    ERROR("Expected gfn %"PRIx64" in slot %d, but found gfn %lx\n", req.gfn, slot, paging->slot_to_gfn[slot]);
+                    ERROR("Expected gfn %"PRIx64" in slot %d, but found gfn %lx\n", req.mem_paging_event.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, slot);
+                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.mem_paging_event.gfn, slot);
                     /* Notify policy of page being dropped */
-                    policy_notify_dropped(req.gfn);
+                    policy_notify_dropped(req.mem_paging_event.gfn);
                 }
                 else
                 {
                     /* Populate the page */
-                    if ( xenpaging_populate_page(paging, req.gfn, slot) < 0 )
+                    if ( xenpaging_populate_page(paging, req.mem_paging_event.gfn, slot) < 0 )
                     {
-                        ERROR("Error populating page %"PRIx64"", req.gfn);
+                        ERROR("Error populating page %"PRIx64"", req.mem_paging_event.gfn);
                         goto out;
                     }
                 }
 
                 /* Prepare the response */
-                rsp.gfn = req.gfn;
+                rsp.mem_paging_event.gfn = req.mem_paging_event.gfn;
                 rsp.vcpu_id = req.vcpu_id;
                 rsp.flags = req.flags;
 
                 if ( xenpaging_resume_page(paging, &rsp, 1) < 0 )
                 {
-                    PERROR("Error resuming page %"PRIx64"", req.gfn);
+                    PERROR("Error resuming page %"PRIx64"", req.mem_paging_event.gfn);
                     goto out;
                 }
 
@@ -967,7 +967,7 @@ int main(int argc, char *argv[])
                 DPRINTF("page %s populated (domain = %d; vcpu = %d;"
                         " gfn = %"PRIx64"; paused = %d; evict_fail = %d)\n",
                         req.flags & MEM_EVENT_FLAG_EVICT_FAIL ? "not" : "already",
-                        paging->mem_event.domain_id, req.vcpu_id, req.gfn,
+                        paging->mem_event.domain_id, req.vcpu_id, req.mem_paging_event.gfn,
                         !!(req.flags & MEM_EVENT_FLAG_VCPU_PAUSED) ,
                         !!(req.flags & MEM_EVENT_FLAG_EVICT_FAIL) );
 
@@ -975,13 +975,13 @@ int main(int argc, char *argv[])
                 if (( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) || ( req.flags & MEM_EVENT_FLAG_EVICT_FAIL ))
                 {
                     /* Prepare the response */
-                    rsp.gfn = req.gfn;
+                    rsp.mem_paging_event.gfn = req.mem_paging_event.gfn;
                     rsp.vcpu_id = req.vcpu_id;
                     rsp.flags = req.flags;
 
                     if ( xenpaging_resume_page(paging, &rsp, 0) < 0 )
                     {
-                        PERROR("Error resuming page %"PRIx64"", req.gfn);
+                        PERROR("Error resuming page %"PRIx64"", req.mem_paging_event.gfn);
                         goto out;
                     }
                 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..67782c8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -6185,21 +6185,15 @@ static void hvm_mem_event_fill_regs(mem_event_request_t *req)
     req->x86_regs.cr4 = curr->arch.hvm_vcpu.guest_cr[4];
 }
 
-static int hvm_memory_event_traps(long p, uint32_t reason,
-                                  unsigned long value, unsigned long old, 
-                                  bool_t gla_valid, unsigned long gla) 
+static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
 {
-    struct vcpu* v = current;
-    struct domain *d = v->domain;
-    mem_event_request_t req = { .reason = reason };
     int rc;
+    struct vcpu *v = current;
+    struct domain *d = v->domain;
 
-    if ( !(p & HVMPME_MODE_MASK) ) 
+    if ( !(parameters & HVMPME_MODE_MASK) )
         return 0;
 
-    if ( (p & HVMPME_onchangeonly) && (value == old) )
-        return 1;
-
     rc = mem_event_claim_slot(d, &d->mem_event->access);
     if ( rc == -ENOSYS )
     {
@@ -6210,85 +6204,114 @@ static int hvm_memory_event_traps(long p, uint32_t reason,
     else if ( rc < 0 )
         return rc;
 
-    if ( (p & HVMPME_MODE_MASK) == HVMPME_mode_sync ) 
+    if ( (parameters & HVMPME_MODE_MASK) == HVMPME_mode_sync )
     {
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+        req->flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
         mem_event_vcpu_pause(v);
     }
 
-    req.gfn = value;
-    req.vcpu_id = v->vcpu_id;
-    if ( gla_valid ) 
-    {
-        req.offset = gla & ((1 << PAGE_SHIFT) - 1);
-        req.gla = gla;
-        req.gla_valid = 1;
-    }
-    else
-    {
-        req.gla = old;
-    }
-    
-    hvm_mem_event_fill_regs(&req);
-    mem_event_put_request(d, &d->mem_event->access, &req);
-    
+    hvm_mem_event_fill_regs(req);
+    mem_event_put_request(d, &d->mem_event->access, req);
+
     return 1;
 }
 
-void hvm_memory_event_cr0(unsigned long value, unsigned long old) 
+void hvm_memory_event_cr0(unsigned long value, unsigned long old)
 {
-    hvm_memory_event_traps(current->domain->arch.hvm_domain
-                             .params[HVM_PARAM_MEMORY_EVENT_CR0],
-                           MEM_EVENT_REASON_CR0,
-                           value, old, 0, 0);
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_CR0,
+        .vcpu_id = current->vcpu_id,
+        .cr_event.new_value = value,
+        .cr_event.old_value = old
+    };
+
+    long parameters = current->domain->arch.hvm_domain
+                        .params[HVM_PARAM_MEMORY_EVENT_CR0];
+
+    if ( (parameters & HVMPME_onchangeonly) && (value == old) )
+        return;
+
+    hvm_memory_event_traps(parameters, &req);
 }
 
-void hvm_memory_event_cr3(unsigned long value, unsigned long old) 
+void hvm_memory_event_cr3(unsigned long value, unsigned long old)
 {
-    hvm_memory_event_traps(current->domain->arch.hvm_domain
-                             .params[HVM_PARAM_MEMORY_EVENT_CR3],
-                           MEM_EVENT_REASON_CR3,
-                           value, old, 0, 0);
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_CR3,
+        .vcpu_id = current->vcpu_id,
+        .cr_event.new_value = value,
+        .cr_event.old_value = old
+    };
+
+    long parameters = current->domain->arch.hvm_domain
+                        .params[HVM_PARAM_MEMORY_EVENT_CR3];
+
+    if ( (parameters & HVMPME_onchangeonly) && (value == old) )
+        return;
+
+    hvm_memory_event_traps(parameters, &req);
 }
 
-void hvm_memory_event_cr4(unsigned long value, unsigned long old) 
+void hvm_memory_event_cr4(unsigned long value, unsigned long old)
 {
-    hvm_memory_event_traps(current->domain->arch.hvm_domain
-                             .params[HVM_PARAM_MEMORY_EVENT_CR4],
-                           MEM_EVENT_REASON_CR4,
-                           value, old, 0, 0);
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_CR4,
+        .vcpu_id = current->vcpu_id,
+        .cr_event.new_value = value,
+        .cr_event.old_value = old
+    };
+
+    long parameters = current->domain->arch.hvm_domain
+                        .params[HVM_PARAM_MEMORY_EVENT_CR4];
+
+    if ( (parameters & HVMPME_onchangeonly) && (value == old) )
+        return;
+
+    hvm_memory_event_traps(parameters, &req);
 }
 
 void hvm_memory_event_msr(unsigned long msr, unsigned long value)
 {
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_MSR,
+        .vcpu_id = current->vcpu_id,
+        .msr_event.msr = msr,
+        .msr_event.new_value = value,
+    };
+
     hvm_memory_event_traps(current->domain->arch.hvm_domain
-                             .params[HVM_PARAM_MEMORY_EVENT_MSR],
-                           MEM_EVENT_REASON_MSR,
-                           value, ~value, 1, msr);
+                            .params[HVM_PARAM_MEMORY_EVENT_MSR],
+                           &req);
 }
 
-int hvm_memory_event_int3(unsigned long gla) 
+int hvm_memory_event_int3(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
-    unsigned long gfn;
-    gfn = paging_gva_to_gfn(current, gla, &pfec);
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_INT3,
+        .vcpu_id = current->vcpu_id,
+        .int3_event.gla = gla,
+        .int3_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
+    };
 
     return hvm_memory_event_traps(current->domain->arch.hvm_domain
-                                    .params[HVM_PARAM_MEMORY_EVENT_INT3],
-                                  MEM_EVENT_REASON_INT3,
-                                  gfn, 0, 1, gla);
+                                   .params[HVM_PARAM_MEMORY_EVENT_INT3],
+                                  &req);
 }
 
 int hvm_memory_event_single_step(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
-    unsigned long gfn;
-    gfn = paging_gva_to_gfn(current, gla, &pfec);
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_SINGLESTEP,
+        .vcpu_id = current->vcpu_id,
+        .singlestep_event.gla = gla,
+        .singlestep_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
+    };
 
     return hvm_memory_event_traps(current->domain->arch.hvm_domain
-            .params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP],
-            MEM_EVENT_REASON_SINGLESTEP,
-            gfn, 0, 1, gla);
+                                   .params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP],
+                                  &req);
 }
 
 int nhvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 7c0fc7d..c15edcc 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -559,7 +559,10 @@ int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
 {
     struct vcpu *v = current;
     int rc;
-    mem_event_request_t req = { .gfn = gfn };
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_MEM_SHARING,
+        .mem_sharing_event.gfn = gfn
+    };
 
     if ( (rc = __mem_event_claim_slot(d, 
                         &d->mem_event->share, allow_sleep)) < 0 )
@@ -571,7 +574,7 @@ int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
         mem_event_vcpu_pause(v);
     }
 
-    req.p2mt = p2m_ram_shared;
+    req.mem_sharing_event.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_event->share, &req);
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index efa49dd..cfd3ff5 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1077,7 +1077,10 @@ int p2m_mem_paging_evict(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 = { .gfn = gfn };
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_MEM_PAGING,
+        .mem_paging_event.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
@@ -1124,7 +1127,10 @@ void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req = { .gfn = gfn };
+    mem_event_request_t req = {
+        .reason = MEM_EVENT_REASON_MEM_PAGING,
+        .mem_paging_event.gfn = gfn
+    };
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
@@ -1174,7 +1180,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
     }
 
     /* Send request to pager */
-    req.p2mt = p2mt;
+    req.mem_paging_event.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_event->paging, &req);
@@ -1309,15 +1315,15 @@ void p2m_mem_paging_resume(struct domain *d)
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
             gfn_lock(p2m, rsp.gfn, 0);
-            mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, 0, NULL);
+            mfn = p2m->get_entry(p2m, rsp.mem_access_event.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) )
             {
-                p2m_set_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K,
+                p2m_set_entry(p2m, rsp.mem_access_event.gfn, mfn, PAGE_ORDER_4K,
                               paging_mode_log_dirty(d) ? p2m_ram_logdirty :
                               p2m_ram_rw, a);
-                set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
+                set_gpfn_from_mfn(mfn_x(mfn), rsp.mem_access_event.gfn);
             }
             gfn_unlock(p2m, rsp.gfn, 0);
         }
@@ -1390,39 +1396,40 @@ void p2m_mem_event_emulate_check(struct vcpu *v, const mem_event_response_t *rsp
         xenmem_access_t access;
         bool_t violation = 1;
 
-        if ( p2m_get_mem_access(v->domain, rsp->gfn, &access) == 0 )
+        if ( p2m_get_mem_access(v->domain, rsp->mem_access_event.gfn, &access) == 0 )
         {
             switch ( access )
             {
             case XENMEM_access_n:
             case XENMEM_access_n2rwx:
             default:
-                violation = rsp->access_r || rsp->access_w || rsp->access_x;
+                violation = rsp->mem_access_event.access_r || rsp->mem_access_event.access_w ||
+                            rsp->mem_access_event.access_x;
                 break;
 
             case XENMEM_access_r:
-                violation = rsp->access_w || rsp->access_x;
+                violation = rsp->mem_access_event.access_w || rsp->mem_access_event.access_x;
                 break;
 
             case XENMEM_access_w:
-                violation = rsp->access_r || rsp->access_x;
+                violation = rsp->mem_access_event.access_r || rsp->mem_access_event.access_x;
                 break;
 
             case XENMEM_access_x:
-                violation = rsp->access_r || rsp->access_w;
+                violation = rsp->mem_access_event.access_r || rsp->mem_access_event.access_w;
                 break;
 
             case XENMEM_access_rx:
             case XENMEM_access_rx2rw:
-                violation = rsp->access_w;
+                violation = rsp->mem_access_event.access_w;
                 break;
 
             case XENMEM_access_wx:
-                violation = rsp->access_r;
+                violation = rsp->mem_access_event.access_r;
                 break;
 
             case XENMEM_access_rw:
-                violation = rsp->access_x;
+                violation = rsp->mem_access_event.access_x;
                 break;
 
             case XENMEM_access_rwx:
@@ -1540,24 +1547,24 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
     if ( req )
     {
         *req_ptr = req;
-        req->reason = MEM_EVENT_REASON_VIOLATION;
+        req->reason = MEM_EVENT_REASON_MEM_ACCESS_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 = npfec.gla_valid;
-        req->gla = gla;
+        req->mem_access_event.gfn = gfn;
+        req->mem_access_event.offset = gpa & ((1 << PAGE_SHIFT) - 1);
+        req->mem_access_event.gla_valid = npfec.gla_valid;
+        req->mem_access_event.gla = gla;
         if ( npfec.kind == npfec_kind_with_gla )
-            req->fault_with_gla = 1;
+            req->mem_access_event.fault_with_gla = 1;
         else if ( npfec.kind == npfec_kind_in_gpt )
-            req->fault_in_gpt = 1;
-        req->access_r = npfec.read_access;
-        req->access_w = npfec.write_access;
-        req->access_x = npfec.insn_fetch;
+            req->mem_access_event.fault_in_gpt = 1;
+        req->mem_access_event.access_r = npfec.read_access;
+        req->mem_access_event.access_w = npfec.write_access;
+        req->mem_access_event.access_x = npfec.insn_fetch;
         req->vcpu_id = v->vcpu_id;
 
         p2m_mem_event_fill_regs(req);
diff --git a/xen/include/public/mem_event.h b/xen/include/public/mem_event.h
index 599f9e8..c0e9394 100644
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -49,15 +49,19 @@
 #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 << 6)
 
 /* Reasons for the memory event request */
-#define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */
-#define MEM_EVENT_REASON_VIOLATION   1    /* access violation, GFN is address */
-#define MEM_EVENT_REASON_CR0         2    /* CR0 was hit: gfn is new CR0 value, gla is previous */
-#define MEM_EVENT_REASON_CR3         3    /* CR3 was hit: gfn is new CR3 value, gla is previous */
-#define MEM_EVENT_REASON_CR4         4    /* CR4 was hit: gfn is new CR4 value, gla is previous */
-#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 */
-#define MEM_EVENT_REASON_MSR         7    /* MSR was hit: gfn is MSR value, gla is MSR address;
-                                             does NOT honour HVMPME_onchangeonly */
+typedef enum {
+    MEM_EVENT_REASON_UNKNOWN,              /* Default case */
+    MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
+    MEM_EVENT_REASON_MEM_SHARING,          /* Memory sharing event */
+    MEM_EVENT_REASON_MEM_PAGING,           /* Memory paging event */
+    MEM_EVENT_REASON_CR0,                  /* CR0 was updated */
+    MEM_EVENT_REASON_CR3,                  /* CR3 was updated */
+    MEM_EVENT_REASON_CR4,                  /* CR4 was updated */
+    MEM_EVENT_REASON_INT3,                 /* Debug operation executed (int3) */
+    MEM_EVENT_REASON_SINGLESTEP,           /* Single-step (MTF) */
+    MEM_EVENT_REASON_MSR,                  /* An MSR was updated.
+                                            * Does NOT honour HVMPME_onchangeonly */
+} mem_event_reason_t;
 
 /* Using a custom struct (not hvm_hw_cpu) so as to not fill
  * the mem_event ring buffer too quickly. */
@@ -97,16 +101,10 @@ struct mem_event_regs_x86 {
     uint32_t _pad;
 };
 
-typedef struct mem_event_st {
-    uint32_t flags;
-    uint32_t vcpu_id;
-
+struct mem_event_mem_access_data {
     uint64_t gfn;
     uint64_t offset;
     uint64_t gla; /* if gla_valid */
-
-    uint32_t p2mt;
-
     uint16_t access_r:1;
     uint16_t access_w:1;
     uint16_t access_x:1;
@@ -114,8 +112,55 @@ typedef struct mem_event_st {
     uint16_t fault_with_gla:1;
     uint16_t fault_in_gpt:1;
     uint16_t available:10;
+};
+
+struct mem_event_cr_data {
+    uint64_t new_value;
+    uint64_t old_value;
+};
+
+struct mem_event_int3_data {
+    uint64_t gfn;
+    uint64_t gla;
+};
+
+struct mem_event_singlestep_data {
+    uint64_t gfn;
+    uint64_t gla;
+};
+
+struct mem_event_msr_data {
+    uint64_t msr;
+    uint64_t old_value;
+    uint64_t new_value;
+};
+
+struct mem_event_paging_data {
+    uint64_t gfn;
+    uint32_t p2mt;
+};
+
+struct mem_event_sharing_data {
+    uint64_t gfn;
+    uint32_t p2mt;
+};
+
+typedef struct mem_event_st {
+    uint32_t flags;
+    uint32_t vcpu_id;
+
+    mem_event_reason_t reason;
+
+    union {
+        struct mem_event_paging_data     mem_paging_event;
+        struct mem_event_sharing_data    mem_sharing_event;
+        struct mem_event_mem_access_data mem_access_event;
+        struct mem_event_cr_data         cr_event;
+        struct mem_event_int3_data       int3_event;
+        struct mem_event_singlestep_data singlestep_event;
+        struct mem_event_msr_data        msr_event;
+    };
 
-    uint16_t reason;
     struct mem_event_regs_x86 x86_regs;
 } mem_event_request_t, mem_event_response_t;
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZu8-0007tW-Mq; Wed, 12 Nov 2014 15:32:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZu7-0007s6-BJ
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:19 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	95/B7-24532-28D73645; Wed, 12 Nov 2014 15:32:18 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415806337!12246037!1
X-Originating-IP: [209.85.216.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20112 invoked from network); 12 Nov 2014 15:32:17 -0000
Received: from mail-qc0-f178.google.com (HELO mail-qc0-f178.google.com)
	(209.85.216.178)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:17 -0000
Received: by mail-qc0-f178.google.com with SMTP id b13so10788562qcw.9
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=qHx/qRSsHPlg+yQhUvKcXR18XjkLROxjWnlftR+GHoE=;
	b=TsUgk1b8Fjw7QQwTarxyk+VpGACMcLFMUxcBsTySgBpt81uBZ9e43TC5XdOzOOugoK
	jBQo7ZeHO3H8ZoC5u7QGePZfNrCuHIIlagmdJut4NMOW88t6y+lbJAEUfjPNIdxW5oOM
	n9gmKtmCzXykGEL3LIv79iTIdyDv2BGqjSWVWIMwdkF/Lmvy+TNuzhre3b7G9z+iQMHD
	Wa5tXhheUE9uvAjy70CZQLHLYQVQK7mR9NMQl9VybJrFMGceSxfb5qq3eywcAKDIpaeB
	HQONonJ17kGD9g2nv/37eFX7+ntXyEJPxah7YI5c3JdegO/LJSYr+dswrmmMcAGI/E3Q
	IO5Q==
X-Gm-Message-State: ALoCoQm+zEKR0QwX4GGLYK7Zy4GGFuI5Y+PYmbSFemNHrBZaAZGpP9JUSk4qsw+LVoa2SR53m3/+
X-Received: by 10.224.40.147 with SMTP id k19mr17218499qae.59.1415806336857;
	Wed, 12 Nov 2014 07:32:16 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.14 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:16 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:45 +0100
Message-Id: <1415806309-5206-4-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 3/7] xen/mem_paging: Convert mem_event_op to
	mem_paging_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 only use-case of the mem_event_op structure had been in mem_paging,
thus renaming the structure mem_paging_op and relocating its associated
functions clarifies its actual usage.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 tools/libxc/xc_mem_event.c       | 16 ----------------
 tools/libxc/xc_mem_paging.c      | 26 ++++++++++++++++++--------
 tools/libxc/xc_private.h         |  3 ---
 xen/arch/x86/mm/mem_paging.c     | 12 ++++++------
 xen/arch/x86/x86_64/compat/mm.c  |  8 ++++----
 xen/arch/x86/x86_64/mm.c         |  8 ++++----
 xen/common/mem_event.c           |  2 +-
 xen/include/asm-x86/mem_paging.h |  2 +-
 xen/include/public/memory.h      |  6 +++---
 9 files changed, 37 insertions(+), 46 deletions(-)

diff --git a/tools/libxc/xc_mem_event.c b/tools/libxc/xc_mem_event.c
index 20db2ed..a5e0948 100644
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -40,22 +40,6 @@ int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
     return rc;
 }
 
-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));
-}
-
 void *xc_mem_event_enable(xc_interface *xch, domid_t domain_id, int param,
                           uint32_t *port, int enable_introspection)
 {
diff --git a/tools/libxc/xc_mem_paging.c b/tools/libxc/xc_mem_paging.c
index 8aa7d4d..bf3173d 100644
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -23,6 +23,20 @@
 
 #include "xc_private.h"
 
+static int xc_mem_paging_memop(xc_interface *xch, domid_t domain_id,
+                               unsigned int op, uint64_t gfn, void *buffer)
+{
+    xen_mem_paging_op_t mpo;
+
+    memset(&mpo, 0, sizeof(mpo));
+
+    mpo.op      = op;
+    mpo.domain  = domain_id;
+    mpo.gfn     = gfn;
+    mpo.buffer  = (unsigned long) buffer;
+
+    return do_memory_op(xch, XENMEM_paging_op, &mpo, sizeof(mpo));
+}
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
                          uint32_t *port)
@@ -49,25 +63,22 @@ 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)
 {
-    return xc_mem_event_memop(xch, domain_id,
+    return xc_mem_paging_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_memop(xch, domain_id,
+    return xc_mem_paging_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_memop(xch, domain_id,
+    return xc_mem_paging_memop(xch, domain_id,
                                 XENMEM_paging_op_prep,
-                                XENMEM_paging_op,
                                 gfn, NULL);
 }
 
@@ -87,9 +98,8 @@ int xc_mem_paging_load(xc_interface *xch, domid_t domain_id,
     if ( mlock(buffer, XC_PAGE_SIZE) )
         return -1;
         
-    rc = xc_mem_event_memop(xch, domain_id,
+    rc = xc_mem_paging_memop(xch, domain_id,
                                 XENMEM_paging_op_prep,
-                                XENMEM_paging_op,
                                 gfn, buffer);
 
     old_errno = errno;
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 45b8644..f1f601c 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -425,9 +425,6 @@ int xc_ffs64(uint64_t x);
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
                          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);
 /*
  * Enables mem_event and returns the mapped ring page indicated by param.
  * param can be HVM_PARAM_PAGING/ACCESS/SHARING_RING_PFN
diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index 65f6a3d..f28e65b 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,31 +25,31 @@
 #include <xen/mem_event.h>
 
 
-int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
+int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpc)
 {
     if ( unlikely(!d->mem_event->paging.ring_page) )
         return -ENODEV;
 
-    switch( mec->op )
+    switch( mpc->op )
     {
     case XENMEM_paging_op_nominate:
     {
-        unsigned long gfn = mec->gfn;
+        unsigned long gfn = mpc->gfn;
         return p2m_mem_paging_nominate(d, gfn);
     }
     break;
 
     case XENMEM_paging_op_evict:
     {
-        unsigned long gfn = mec->gfn;
+        unsigned long gfn = mpc->gfn;
         return p2m_mem_paging_evict(d, gfn);
     }
     break;
 
     case XENMEM_paging_op_prep:
     {
-        unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn, mec->buffer);
+        unsigned long gfn = mpc->gfn;
+        return p2m_mem_paging_prep(d, gfn, mpc->buffer);
     }
     break;
 
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index 54f25b7..229d1ea 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -189,11 +189,11 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
     case XENMEM_paging_op:
     {
-        xen_mem_event_op_t meo;
-        if ( copy_from_guest(&meo, arg, 1) )
+        xen_mem_paging_op_t mpo;
+        if ( copy_from_guest(&mpo, arg, 1) )
             return -EFAULT;
-        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
-        if ( !rc && __copy_to_guest(arg, &meo, 1) )
+        rc = do_mem_event_op(op, mpo.domain, (void *) &mpo);
+        if ( !rc && __copy_to_guest(arg, &mpo, 1) )
             return -EFAULT;
         break;
     }
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 8e5a1a1..33d5ec9 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -986,11 +986,11 @@ long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
     case XENMEM_paging_op:
     {
-        xen_mem_event_op_t meo;
-        if ( copy_from_guest(&meo, arg, 1) )
+        xen_mem_paging_op_t mpo;
+        if ( copy_from_guest(&mpo, arg, 1) )
             return -EFAULT;
-        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
-        if ( !rc && __copy_to_guest(arg, &meo, 1) )
+        rc = do_mem_event_op(op, mpo.domain, (void *) &mpo);
+        if ( !rc && __copy_to_guest(arg, &mpo, 1) )
             return -EFAULT;
         break;
     }
diff --git a/xen/common/mem_event.c b/xen/common/mem_event.c
index 37b5558..b99e7d5 100644
--- a/xen/common/mem_event.c
+++ b/xen/common/mem_event.c
@@ -474,7 +474,7 @@ int do_mem_event_op(int op, uint32_t domain, void *arg)
     {
 #ifdef HAS_MEM_PAGING
         case XENMEM_paging_op:
-            ret = mem_paging_memop(d, (xen_mem_event_op_t *) arg);
+            ret = mem_paging_memop(d, (xen_mem_paging_op_t *) arg);
             break;
 #endif
 #ifdef HAS_MEM_SHARING
diff --git a/xen/include/asm-x86/mem_paging.h b/xen/include/asm-x86/mem_paging.h
index 6b7a1fe..92ed2fa 100644
--- a/xen/include/asm-x86/mem_paging.h
+++ b/xen/include/asm-x86/mem_paging.h
@@ -21,7 +21,7 @@
  */
 
 
-int mem_paging_memop(struct domain *d, xen_mem_event_op_t *meo);
+int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *meo);
 
 
 /*
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index f021958..c59c1a8 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -372,7 +372,7 @@ typedef struct xen_pod_target xen_pod_target_t;
 #define XENMEM_paging_op_evict              1
 #define XENMEM_paging_op_prep               2
 
-struct xen_mem_event_op {
+struct xen_mem_paging_op {
     uint8_t     op;         /* XENMEM_*_op_* */
     domid_t     domain;
     
@@ -382,8 +382,8 @@ struct xen_mem_event_op {
     /* 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);
+typedef struct xen_mem_paging_op xen_mem_paging_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_paging_op_t);
 
 #define XENMEM_access_op                    21
 #define XENMEM_access_op_resume             0
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZu8-0007tW-Mq; Wed, 12 Nov 2014 15:32:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZu7-0007s6-BJ
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:19 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	95/B7-24532-28D73645; Wed, 12 Nov 2014 15:32:18 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415806337!12246037!1
X-Originating-IP: [209.85.216.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20112 invoked from network); 12 Nov 2014 15:32:17 -0000
Received: from mail-qc0-f178.google.com (HELO mail-qc0-f178.google.com)
	(209.85.216.178)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:17 -0000
Received: by mail-qc0-f178.google.com with SMTP id b13so10788562qcw.9
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=qHx/qRSsHPlg+yQhUvKcXR18XjkLROxjWnlftR+GHoE=;
	b=TsUgk1b8Fjw7QQwTarxyk+VpGACMcLFMUxcBsTySgBpt81uBZ9e43TC5XdOzOOugoK
	jBQo7ZeHO3H8ZoC5u7QGePZfNrCuHIIlagmdJut4NMOW88t6y+lbJAEUfjPNIdxW5oOM
	n9gmKtmCzXykGEL3LIv79iTIdyDv2BGqjSWVWIMwdkF/Lmvy+TNuzhre3b7G9z+iQMHD
	Wa5tXhheUE9uvAjy70CZQLHLYQVQK7mR9NMQl9VybJrFMGceSxfb5qq3eywcAKDIpaeB
	HQONonJ17kGD9g2nv/37eFX7+ntXyEJPxah7YI5c3JdegO/LJSYr+dswrmmMcAGI/E3Q
	IO5Q==
X-Gm-Message-State: ALoCoQm+zEKR0QwX4GGLYK7Zy4GGFuI5Y+PYmbSFemNHrBZaAZGpP9JUSk4qsw+LVoa2SR53m3/+
X-Received: by 10.224.40.147 with SMTP id k19mr17218499qae.59.1415806336857;
	Wed, 12 Nov 2014 07:32:16 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.14 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:16 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:45 +0100
Message-Id: <1415806309-5206-4-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 3/7] xen/mem_paging: Convert mem_event_op to
	mem_paging_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 only use-case of the mem_event_op structure had been in mem_paging,
thus renaming the structure mem_paging_op and relocating its associated
functions clarifies its actual usage.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 tools/libxc/xc_mem_event.c       | 16 ----------------
 tools/libxc/xc_mem_paging.c      | 26 ++++++++++++++++++--------
 tools/libxc/xc_private.h         |  3 ---
 xen/arch/x86/mm/mem_paging.c     | 12 ++++++------
 xen/arch/x86/x86_64/compat/mm.c  |  8 ++++----
 xen/arch/x86/x86_64/mm.c         |  8 ++++----
 xen/common/mem_event.c           |  2 +-
 xen/include/asm-x86/mem_paging.h |  2 +-
 xen/include/public/memory.h      |  6 +++---
 9 files changed, 37 insertions(+), 46 deletions(-)

diff --git a/tools/libxc/xc_mem_event.c b/tools/libxc/xc_mem_event.c
index 20db2ed..a5e0948 100644
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -40,22 +40,6 @@ int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
     return rc;
 }
 
-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));
-}
-
 void *xc_mem_event_enable(xc_interface *xch, domid_t domain_id, int param,
                           uint32_t *port, int enable_introspection)
 {
diff --git a/tools/libxc/xc_mem_paging.c b/tools/libxc/xc_mem_paging.c
index 8aa7d4d..bf3173d 100644
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -23,6 +23,20 @@
 
 #include "xc_private.h"
 
+static int xc_mem_paging_memop(xc_interface *xch, domid_t domain_id,
+                               unsigned int op, uint64_t gfn, void *buffer)
+{
+    xen_mem_paging_op_t mpo;
+
+    memset(&mpo, 0, sizeof(mpo));
+
+    mpo.op      = op;
+    mpo.domain  = domain_id;
+    mpo.gfn     = gfn;
+    mpo.buffer  = (unsigned long) buffer;
+
+    return do_memory_op(xch, XENMEM_paging_op, &mpo, sizeof(mpo));
+}
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
                          uint32_t *port)
@@ -49,25 +63,22 @@ 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)
 {
-    return xc_mem_event_memop(xch, domain_id,
+    return xc_mem_paging_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_memop(xch, domain_id,
+    return xc_mem_paging_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_memop(xch, domain_id,
+    return xc_mem_paging_memop(xch, domain_id,
                                 XENMEM_paging_op_prep,
-                                XENMEM_paging_op,
                                 gfn, NULL);
 }
 
@@ -87,9 +98,8 @@ int xc_mem_paging_load(xc_interface *xch, domid_t domain_id,
     if ( mlock(buffer, XC_PAGE_SIZE) )
         return -1;
         
-    rc = xc_mem_event_memop(xch, domain_id,
+    rc = xc_mem_paging_memop(xch, domain_id,
                                 XENMEM_paging_op_prep,
-                                XENMEM_paging_op,
                                 gfn, buffer);
 
     old_errno = errno;
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 45b8644..f1f601c 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -425,9 +425,6 @@ int xc_ffs64(uint64_t x);
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
                          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);
 /*
  * Enables mem_event and returns the mapped ring page indicated by param.
  * param can be HVM_PARAM_PAGING/ACCESS/SHARING_RING_PFN
diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index 65f6a3d..f28e65b 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,31 +25,31 @@
 #include <xen/mem_event.h>
 
 
-int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
+int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpc)
 {
     if ( unlikely(!d->mem_event->paging.ring_page) )
         return -ENODEV;
 
-    switch( mec->op )
+    switch( mpc->op )
     {
     case XENMEM_paging_op_nominate:
     {
-        unsigned long gfn = mec->gfn;
+        unsigned long gfn = mpc->gfn;
         return p2m_mem_paging_nominate(d, gfn);
     }
     break;
 
     case XENMEM_paging_op_evict:
     {
-        unsigned long gfn = mec->gfn;
+        unsigned long gfn = mpc->gfn;
         return p2m_mem_paging_evict(d, gfn);
     }
     break;
 
     case XENMEM_paging_op_prep:
     {
-        unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn, mec->buffer);
+        unsigned long gfn = mpc->gfn;
+        return p2m_mem_paging_prep(d, gfn, mpc->buffer);
     }
     break;
 
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index 54f25b7..229d1ea 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -189,11 +189,11 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
     case XENMEM_paging_op:
     {
-        xen_mem_event_op_t meo;
-        if ( copy_from_guest(&meo, arg, 1) )
+        xen_mem_paging_op_t mpo;
+        if ( copy_from_guest(&mpo, arg, 1) )
             return -EFAULT;
-        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
-        if ( !rc && __copy_to_guest(arg, &meo, 1) )
+        rc = do_mem_event_op(op, mpo.domain, (void *) &mpo);
+        if ( !rc && __copy_to_guest(arg, &mpo, 1) )
             return -EFAULT;
         break;
     }
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 8e5a1a1..33d5ec9 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -986,11 +986,11 @@ long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
     case XENMEM_paging_op:
     {
-        xen_mem_event_op_t meo;
-        if ( copy_from_guest(&meo, arg, 1) )
+        xen_mem_paging_op_t mpo;
+        if ( copy_from_guest(&mpo, arg, 1) )
             return -EFAULT;
-        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
-        if ( !rc && __copy_to_guest(arg, &meo, 1) )
+        rc = do_mem_event_op(op, mpo.domain, (void *) &mpo);
+        if ( !rc && __copy_to_guest(arg, &mpo, 1) )
             return -EFAULT;
         break;
     }
diff --git a/xen/common/mem_event.c b/xen/common/mem_event.c
index 37b5558..b99e7d5 100644
--- a/xen/common/mem_event.c
+++ b/xen/common/mem_event.c
@@ -474,7 +474,7 @@ int do_mem_event_op(int op, uint32_t domain, void *arg)
     {
 #ifdef HAS_MEM_PAGING
         case XENMEM_paging_op:
-            ret = mem_paging_memop(d, (xen_mem_event_op_t *) arg);
+            ret = mem_paging_memop(d, (xen_mem_paging_op_t *) arg);
             break;
 #endif
 #ifdef HAS_MEM_SHARING
diff --git a/xen/include/asm-x86/mem_paging.h b/xen/include/asm-x86/mem_paging.h
index 6b7a1fe..92ed2fa 100644
--- a/xen/include/asm-x86/mem_paging.h
+++ b/xen/include/asm-x86/mem_paging.h
@@ -21,7 +21,7 @@
  */
 
 
-int mem_paging_memop(struct domain *d, xen_mem_event_op_t *meo);
+int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *meo);
 
 
 /*
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index f021958..c59c1a8 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -372,7 +372,7 @@ typedef struct xen_pod_target xen_pod_target_t;
 #define XENMEM_paging_op_evict              1
 #define XENMEM_paging_op_prep               2
 
-struct xen_mem_event_op {
+struct xen_mem_paging_op {
     uint8_t     op;         /* XENMEM_*_op_* */
     domid_t     domain;
     
@@ -382,8 +382,8 @@ struct xen_mem_event_op {
     /* 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);
+typedef struct xen_mem_paging_op xen_mem_paging_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_paging_op_t);
 
 #define XENMEM_access_op                    21
 #define XENMEM_access_op_resume             0
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZuB-0007vb-Ca; Wed, 12 Nov 2014 15:32:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZuA-0007ub-3v
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:22 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	8E/69-09284-58D73645; Wed, 12 Nov 2014 15:32:21 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415806339!10916791!1
X-Originating-IP: [209.85.216.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3771 invoked from network); 12 Nov 2014 15:32:20 -0000
Received: from mail-qa0-f54.google.com (HELO mail-qa0-f54.google.com)
	(209.85.216.54)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:20 -0000
Received: by mail-qa0-f54.google.com with SMTP id u7so8822328qaz.27
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=GCO2MRl7zkCnKwW3uXlFa0C4tful0DaoSPM2z9xVdTc=;
	b=g/D6gKQrCp+goBmPH9UJsAiv6fTVlYeEh2h5XSQwKzol0b8dJmb6wHT9Bi/GK4ayJ0
	e1yhpz4uBAKHLGFmrNbih9AErlj2FMZZzNYZmptVwdlFYEh71b/8+BQuCGcmZJOWFHzp
	wWDlDVFQ00ZunzCmcoMgNaz5lqS4nUUoFOYFhqaMTYq17d4R7VDs6EST6uuI3hWhrHrJ
	eFFNqItHd2jOIieBd+rO+6S4USF0c1tWxnkBEkRMyp6YrJX8tp3uHigLij3pfVgwhIP0
	HgaC/AUOU8f6cAMhdjSAV6h/5Hwfu83K4fLVTqPQ1Lo+oO/OPnjuEJRQlQlVPAAOTylu
	6I0A==
X-Gm-Message-State: ALoCoQl0ZEVIxxgIPyZCz4TrkfFEIEUyEU+m4YPuveT5r/nQZ1Q/w2Y7W72NR8Cc84cvuyGiu2u2
X-Received: by 10.140.92.148 with SMTP id b20mr59721710qge.35.1415806339087;
	Wed, 12 Nov 2014 07:32:19 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.16 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:18 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:46 +0100
Message-Id: <1415806309-5206-5-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 4/7] x86/hvm: rename hvm_memory_event_*
	functions to hvm_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>
MIME-Version: 1.0
Content-Type: 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 function names currently imply that these events are to be delivered via
the memory_event subsystem. However, the naming is confusing as these events
have nothing to do with actual memory events. Simply naming these functions
hvm_event_* more accurately describe their usage.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 docs/misc/pvh-readme.txt      |  2 +-
 xen/arch/x86/hvm/hvm.c        | 50 +++++++++++++++++++++----------------------
 xen/arch/x86/hvm/vmx/vmx.c    |  6 +++---
 xen/include/asm-x86/hvm/hvm.h | 12 +++++------
 4 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/docs/misc/pvh-readme.txt b/docs/misc/pvh-readme.txt
index c5b3de4..bbd9dbe 100644
--- a/docs/misc/pvh-readme.txt
+++ b/docs/misc/pvh-readme.txt
@@ -49,7 +49,7 @@ Following remain to be done for PVH:
    - AMD port.
    - 32bit PVH guest support in both linux and xen. Xen changes are tagged
      "32bitfixme".
-   - Add support for monitoring guest behavior. See hvm_memory_event* functions
+   - Add support for monitoring guest behavior. See hvm_event* functions
      in hvm.c
    - vcpu hotplug support
    - Live migration of PVH guests.
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b34cdbd..9140a2a 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3230,7 +3230,7 @@ int hvm_set_cr0(unsigned long value)
         hvm_funcs.handle_cd(v, value);
 
     hvm_update_cr(v, 0, value);
-    hvm_memory_event_cr0(value, old_value);
+    hvm_event_cr0(value, old_value);
 
     if ( (value ^ old_value) & X86_CR0_PG ) {
         if ( !nestedhvm_vmswitch_in_progress(v) && nestedhvm_vcpu_in_guestmode(v) )
@@ -3271,7 +3271,7 @@ int hvm_set_cr3(unsigned long value)
     old=v->arch.hvm_vcpu.guest_cr[3];
     v->arch.hvm_vcpu.guest_cr[3] = value;
     paging_update_cr3(v);
-    hvm_memory_event_cr3(value, old);
+    hvm_event_cr3(value, old);
     return X86EMUL_OKAY;
 
  bad_cr3:
@@ -3312,7 +3312,7 @@ int hvm_set_cr4(unsigned long value)
     }
 
     hvm_update_cr(v, 4, value);
-    hvm_memory_event_cr4(value, old_cr);
+    hvm_event_cr4(value, old_cr);
 
     /*
      * Modifying CR4.{PSE,PAE,PGE,SMEP}, or clearing CR4.PCIDE
@@ -4458,7 +4458,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content)
     hvm_cpuid(1, NULL, NULL, NULL, &edx);
     mtrr = !!(edx & cpufeat_mask(X86_FEATURE_MTRR));
 
-    hvm_memory_event_msr(msr, msr_content);
+    hvm_event_msr(msr, msr_content);
 
     switch ( msr )
     {
@@ -6153,7 +6153,7 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
     return rc;
 }
 
-static void hvm_mem_event_fill_regs(mem_event_request_t *req)
+static void hvm_event_fill_regs(mem_event_request_t *req)
 {
     const struct cpu_user_regs *regs = guest_cpu_user_regs();
     const struct vcpu *curr = current;
@@ -6185,7 +6185,7 @@ static void hvm_mem_event_fill_regs(mem_event_request_t *req)
     req->x86_regs.cr4 = curr->arch.hvm_vcpu.guest_cr[4];
 }
 
-static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
+static int hvm_event_traps(long parameters, mem_event_request_t *req)
 {
     int rc;
     struct vcpu *v = current;
@@ -6210,13 +6210,13 @@ static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
         mem_event_vcpu_pause(v);
     }
 
-    hvm_mem_event_fill_regs(req);
+    hvm_event_fill_regs(req);
     mem_event_put_request(d, &d->mem_event->monitor, req);
 
     return 1;
 }
 
-void hvm_memory_event_cr0(unsigned long value, unsigned long old)
+void hvm_event_cr0(unsigned long value, unsigned long old)
 {
     mem_event_request_t req = {
         .reason = MEM_EVENT_REASON_CR0,
@@ -6231,10 +6231,10 @@ void hvm_memory_event_cr0(unsigned long value, unsigned long old)
     if ( (parameters & HVMPME_onchangeonly) && (value == old) )
         return;
 
-    hvm_memory_event_traps(parameters, &req);
+    hvm_event_traps(parameters, &req);
 }
 
-void hvm_memory_event_cr3(unsigned long value, unsigned long old)
+void hvm_event_cr3(unsigned long value, unsigned long old)
 {
     mem_event_request_t req = {
         .reason = MEM_EVENT_REASON_CR3,
@@ -6249,10 +6249,10 @@ void hvm_memory_event_cr3(unsigned long value, unsigned long old)
     if ( (parameters & HVMPME_onchangeonly) && (value == old) )
         return;
 
-    hvm_memory_event_traps(parameters, &req);
+    hvm_event_traps(parameters, &req);
 }
 
-void hvm_memory_event_cr4(unsigned long value, unsigned long old)
+void hvm_event_cr4(unsigned long value, unsigned long old)
 {
     mem_event_request_t req = {
         .reason = MEM_EVENT_REASON_CR4,
@@ -6267,10 +6267,10 @@ void hvm_memory_event_cr4(unsigned long value, unsigned long old)
     if ( (parameters & HVMPME_onchangeonly) && (value == old) )
         return;
 
-    hvm_memory_event_traps(parameters, &req);
+    hvm_event_traps(parameters, &req);
 }
 
-void hvm_memory_event_msr(unsigned long msr, unsigned long value)
+void hvm_event_msr(unsigned long msr, unsigned long value)
 {
     mem_event_request_t req = {
         .reason = MEM_EVENT_REASON_MSR,
@@ -6279,12 +6279,12 @@ void hvm_memory_event_msr(unsigned long msr, unsigned long value)
         .msr_event.new_value = value,
     };
 
-    hvm_memory_event_traps(current->domain->arch.hvm_domain
-                            .params[HVM_PARAM_MEMORY_EVENT_MSR],
-                           &req);
+    hvm_event_traps(current->domain->arch.hvm_domain
+                        .params[HVM_PARAM_MEMORY_EVENT_MSR],
+                    &req);
 }
 
-int hvm_memory_event_int3(unsigned long gla)
+int hvm_event_int3(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
     mem_event_request_t req = {
@@ -6294,12 +6294,12 @@ int hvm_memory_event_int3(unsigned long gla)
         .int3_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
     };
 
-    return hvm_memory_event_traps(current->domain->arch.hvm_domain
-                                   .params[HVM_PARAM_MEMORY_EVENT_INT3],
-                                  &req);
+    return hvm_event_traps(current->domain->arch.hvm_domain
+                            .params[HVM_PARAM_MEMORY_EVENT_INT3],
+                           &req);
 }
 
-int hvm_memory_event_single_step(unsigned long gla)
+int hvm_event_single_step(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
     mem_event_request_t req = {
@@ -6309,9 +6309,9 @@ int hvm_memory_event_single_step(unsigned long gla)
         .singlestep_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
     };
 
-    return hvm_memory_event_traps(current->domain->arch.hvm_domain
-                                   .params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP],
-                                  &req);
+    return hvm_event_traps(current->domain->arch.hvm_domain
+                            .params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP],
+                           &req);
 }
 
 int nhvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 0bf92b2..0bb8b38 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1967,7 +1967,7 @@ static int vmx_cr_access(unsigned long exit_qualification)
         unsigned long old = curr->arch.hvm_vcpu.guest_cr[0];
         curr->arch.hvm_vcpu.guest_cr[0] &= ~X86_CR0_TS;
         vmx_update_guest_cr(curr, 0);
-        hvm_memory_event_cr0(curr->arch.hvm_vcpu.guest_cr[0], old);
+        hvm_event_cr0(curr->arch.hvm_vcpu.guest_cr[0], old);
         HVMTRACE_0D(CLTS);
         break;
     }
@@ -2816,7 +2816,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
                 break;
             }
             else {
-                int handled = hvm_memory_event_int3(regs->eip);
+                int handled = hvm_event_int3(regs->eip);
                 
                 if ( handled < 0 ) 
                 {
@@ -3132,7 +3132,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
         v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
         vmx_update_cpu_exec_control(v);
         if ( v->arch.hvm_vcpu.single_step ) {
-          hvm_memory_event_single_step(regs->eip);
+          hvm_event_single_step(regs->eip);
           if ( v->domain->debugger_attached )
               domain_pause_for_debugger();
         }
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index e3d2d9a..5ac390b 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -474,15 +474,15 @@ int hvm_x2apic_msr_read(struct vcpu *v, unsigned int msr, uint64_t *msr_content)
 int hvm_x2apic_msr_write(struct vcpu *v, unsigned int msr, uint64_t msr_content);
 
 /* Called for current VCPU on crX changes by guest */
-void hvm_memory_event_cr0(unsigned long value, unsigned long old);
-void hvm_memory_event_cr3(unsigned long value, unsigned long old);
-void hvm_memory_event_cr4(unsigned long value, unsigned long old);
-void hvm_memory_event_msr(unsigned long msr, unsigned long value);
+void hvm_event_cr0(unsigned long value, unsigned long old);
+void hvm_event_cr3(unsigned long value, unsigned long old);
+void hvm_event_cr4(unsigned long value, unsigned long old);
+void hvm_event_msr(unsigned long msr, unsigned long value);
 /* Called for current VCPU on int3: returns -1 if no listener */
-int hvm_memory_event_int3(unsigned long gla);
+int hvm_event_int3(unsigned long gla);
 
 /* Called for current VCPU on single step: returns -1 if no listener */
-int hvm_memory_event_single_step(unsigned long gla);
+int hvm_event_single_step(unsigned long gla);
 
 /*
  * Nested HVM
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1XoZuB-0007vb-Ca; Wed, 12 Nov 2014 15:32:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZuA-0007ub-3v
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:22 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	8E/69-09284-58D73645; Wed, 12 Nov 2014 15:32:21 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415806339!10916791!1
X-Originating-IP: [209.85.216.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3771 invoked from network); 12 Nov 2014 15:32:20 -0000
Received: from mail-qa0-f54.google.com (HELO mail-qa0-f54.google.com)
	(209.85.216.54)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:20 -0000
Received: by mail-qa0-f54.google.com with SMTP id u7so8822328qaz.27
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=GCO2MRl7zkCnKwW3uXlFa0C4tful0DaoSPM2z9xVdTc=;
	b=g/D6gKQrCp+goBmPH9UJsAiv6fTVlYeEh2h5XSQwKzol0b8dJmb6wHT9Bi/GK4ayJ0
	e1yhpz4uBAKHLGFmrNbih9AErlj2FMZZzNYZmptVwdlFYEh71b/8+BQuCGcmZJOWFHzp
	wWDlDVFQ00ZunzCmcoMgNaz5lqS4nUUoFOYFhqaMTYq17d4R7VDs6EST6uuI3hWhrHrJ
	eFFNqItHd2jOIieBd+rO+6S4USF0c1tWxnkBEkRMyp6YrJX8tp3uHigLij3pfVgwhIP0
	HgaC/AUOU8f6cAMhdjSAV6h/5Hwfu83K4fLVTqPQ1Lo+oO/OPnjuEJRQlQlVPAAOTylu
	6I0A==
X-Gm-Message-State: ALoCoQl0ZEVIxxgIPyZCz4TrkfFEIEUyEU+m4YPuveT5r/nQZ1Q/w2Y7W72NR8Cc84cvuyGiu2u2
X-Received: by 10.140.92.148 with SMTP id b20mr59721710qge.35.1415806339087;
	Wed, 12 Nov 2014 07:32:19 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.16 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:18 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:46 +0100
Message-Id: <1415806309-5206-5-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 4/7] x86/hvm: rename hvm_memory_event_*
	functions to hvm_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>
MIME-Version: 1.0
Content-Type: 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 function names currently imply that these events are to be delivered via
the memory_event subsystem. However, the naming is confusing as these events
have nothing to do with actual memory events. Simply naming these functions
hvm_event_* more accurately describe their usage.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 docs/misc/pvh-readme.txt      |  2 +-
 xen/arch/x86/hvm/hvm.c        | 50 +++++++++++++++++++++----------------------
 xen/arch/x86/hvm/vmx/vmx.c    |  6 +++---
 xen/include/asm-x86/hvm/hvm.h | 12 +++++------
 4 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/docs/misc/pvh-readme.txt b/docs/misc/pvh-readme.txt
index c5b3de4..bbd9dbe 100644
--- a/docs/misc/pvh-readme.txt
+++ b/docs/misc/pvh-readme.txt
@@ -49,7 +49,7 @@ Following remain to be done for PVH:
    - AMD port.
    - 32bit PVH guest support in both linux and xen. Xen changes are tagged
      "32bitfixme".
-   - Add support for monitoring guest behavior. See hvm_memory_event* functions
+   - Add support for monitoring guest behavior. See hvm_event* functions
      in hvm.c
    - vcpu hotplug support
    - Live migration of PVH guests.
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b34cdbd..9140a2a 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3230,7 +3230,7 @@ int hvm_set_cr0(unsigned long value)
         hvm_funcs.handle_cd(v, value);
 
     hvm_update_cr(v, 0, value);
-    hvm_memory_event_cr0(value, old_value);
+    hvm_event_cr0(value, old_value);
 
     if ( (value ^ old_value) & X86_CR0_PG ) {
         if ( !nestedhvm_vmswitch_in_progress(v) && nestedhvm_vcpu_in_guestmode(v) )
@@ -3271,7 +3271,7 @@ int hvm_set_cr3(unsigned long value)
     old=v->arch.hvm_vcpu.guest_cr[3];
     v->arch.hvm_vcpu.guest_cr[3] = value;
     paging_update_cr3(v);
-    hvm_memory_event_cr3(value, old);
+    hvm_event_cr3(value, old);
     return X86EMUL_OKAY;
 
  bad_cr3:
@@ -3312,7 +3312,7 @@ int hvm_set_cr4(unsigned long value)
     }
 
     hvm_update_cr(v, 4, value);
-    hvm_memory_event_cr4(value, old_cr);
+    hvm_event_cr4(value, old_cr);
 
     /*
      * Modifying CR4.{PSE,PAE,PGE,SMEP}, or clearing CR4.PCIDE
@@ -4458,7 +4458,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content)
     hvm_cpuid(1, NULL, NULL, NULL, &edx);
     mtrr = !!(edx & cpufeat_mask(X86_FEATURE_MTRR));
 
-    hvm_memory_event_msr(msr, msr_content);
+    hvm_event_msr(msr, msr_content);
 
     switch ( msr )
     {
@@ -6153,7 +6153,7 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
     return rc;
 }
 
-static void hvm_mem_event_fill_regs(mem_event_request_t *req)
+static void hvm_event_fill_regs(mem_event_request_t *req)
 {
     const struct cpu_user_regs *regs = guest_cpu_user_regs();
     const struct vcpu *curr = current;
@@ -6185,7 +6185,7 @@ static void hvm_mem_event_fill_regs(mem_event_request_t *req)
     req->x86_regs.cr4 = curr->arch.hvm_vcpu.guest_cr[4];
 }
 
-static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
+static int hvm_event_traps(long parameters, mem_event_request_t *req)
 {
     int rc;
     struct vcpu *v = current;
@@ -6210,13 +6210,13 @@ static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
         mem_event_vcpu_pause(v);
     }
 
-    hvm_mem_event_fill_regs(req);
+    hvm_event_fill_regs(req);
     mem_event_put_request(d, &d->mem_event->monitor, req);
 
     return 1;
 }
 
-void hvm_memory_event_cr0(unsigned long value, unsigned long old)
+void hvm_event_cr0(unsigned long value, unsigned long old)
 {
     mem_event_request_t req = {
         .reason = MEM_EVENT_REASON_CR0,
@@ -6231,10 +6231,10 @@ void hvm_memory_event_cr0(unsigned long value, unsigned long old)
     if ( (parameters & HVMPME_onchangeonly) && (value == old) )
         return;
 
-    hvm_memory_event_traps(parameters, &req);
+    hvm_event_traps(parameters, &req);
 }
 
-void hvm_memory_event_cr3(unsigned long value, unsigned long old)
+void hvm_event_cr3(unsigned long value, unsigned long old)
 {
     mem_event_request_t req = {
         .reason = MEM_EVENT_REASON_CR3,
@@ -6249,10 +6249,10 @@ void hvm_memory_event_cr3(unsigned long value, unsigned long old)
     if ( (parameters & HVMPME_onchangeonly) && (value == old) )
         return;
 
-    hvm_memory_event_traps(parameters, &req);
+    hvm_event_traps(parameters, &req);
 }
 
-void hvm_memory_event_cr4(unsigned long value, unsigned long old)
+void hvm_event_cr4(unsigned long value, unsigned long old)
 {
     mem_event_request_t req = {
         .reason = MEM_EVENT_REASON_CR4,
@@ -6267,10 +6267,10 @@ void hvm_memory_event_cr4(unsigned long value, unsigned long old)
     if ( (parameters & HVMPME_onchangeonly) && (value == old) )
         return;
 
-    hvm_memory_event_traps(parameters, &req);
+    hvm_event_traps(parameters, &req);
 }
 
-void hvm_memory_event_msr(unsigned long msr, unsigned long value)
+void hvm_event_msr(unsigned long msr, unsigned long value)
 {
     mem_event_request_t req = {
         .reason = MEM_EVENT_REASON_MSR,
@@ -6279,12 +6279,12 @@ void hvm_memory_event_msr(unsigned long msr, unsigned long value)
         .msr_event.new_value = value,
     };
 
-    hvm_memory_event_traps(current->domain->arch.hvm_domain
-                            .params[HVM_PARAM_MEMORY_EVENT_MSR],
-                           &req);
+    hvm_event_traps(current->domain->arch.hvm_domain
+                        .params[HVM_PARAM_MEMORY_EVENT_MSR],
+                    &req);
 }
 
-int hvm_memory_event_int3(unsigned long gla)
+int hvm_event_int3(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
     mem_event_request_t req = {
@@ -6294,12 +6294,12 @@ int hvm_memory_event_int3(unsigned long gla)
         .int3_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
     };
 
-    return hvm_memory_event_traps(current->domain->arch.hvm_domain
-                                   .params[HVM_PARAM_MEMORY_EVENT_INT3],
-                                  &req);
+    return hvm_event_traps(current->domain->arch.hvm_domain
+                            .params[HVM_PARAM_MEMORY_EVENT_INT3],
+                           &req);
 }
 
-int hvm_memory_event_single_step(unsigned long gla)
+int hvm_event_single_step(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
     mem_event_request_t req = {
@@ -6309,9 +6309,9 @@ int hvm_memory_event_single_step(unsigned long gla)
         .singlestep_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
     };
 
-    return hvm_memory_event_traps(current->domain->arch.hvm_domain
-                                   .params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP],
-                                  &req);
+    return hvm_event_traps(current->domain->arch.hvm_domain
+                            .params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP],
+                           &req);
 }
 
 int nhvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 0bf92b2..0bb8b38 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1967,7 +1967,7 @@ static int vmx_cr_access(unsigned long exit_qualification)
         unsigned long old = curr->arch.hvm_vcpu.guest_cr[0];
         curr->arch.hvm_vcpu.guest_cr[0] &= ~X86_CR0_TS;
         vmx_update_guest_cr(curr, 0);
-        hvm_memory_event_cr0(curr->arch.hvm_vcpu.guest_cr[0], old);
+        hvm_event_cr0(curr->arch.hvm_vcpu.guest_cr[0], old);
         HVMTRACE_0D(CLTS);
         break;
     }
@@ -2816,7 +2816,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
                 break;
             }
             else {
-                int handled = hvm_memory_event_int3(regs->eip);
+                int handled = hvm_event_int3(regs->eip);
                 
                 if ( handled < 0 ) 
                 {
@@ -3132,7 +3132,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
         v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
         vmx_update_cpu_exec_control(v);
         if ( v->arch.hvm_vcpu.single_step ) {
-          hvm_memory_event_single_step(regs->eip);
+          hvm_event_single_step(regs->eip);
           if ( v->domain->debugger_attached )
               domain_pause_for_debugger();
         }
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index e3d2d9a..5ac390b 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -474,15 +474,15 @@ int hvm_x2apic_msr_read(struct vcpu *v, unsigned int msr, uint64_t *msr_content)
 int hvm_x2apic_msr_write(struct vcpu *v, unsigned int msr, uint64_t msr_content);
 
 /* Called for current VCPU on crX changes by guest */
-void hvm_memory_event_cr0(unsigned long value, unsigned long old);
-void hvm_memory_event_cr3(unsigned long value, unsigned long old);
-void hvm_memory_event_cr4(unsigned long value, unsigned long old);
-void hvm_memory_event_msr(unsigned long msr, unsigned long value);
+void hvm_event_cr0(unsigned long value, unsigned long old);
+void hvm_event_cr3(unsigned long value, unsigned long old);
+void hvm_event_cr4(unsigned long value, unsigned long old);
+void hvm_event_msr(unsigned long msr, unsigned long value);
 /* Called for current VCPU on int3: returns -1 if no listener */
-int hvm_memory_event_int3(unsigned long gla);
+int hvm_event_int3(unsigned long gla);
 
 /* Called for current VCPU on single step: returns -1 if no listener */
-int hvm_memory_event_single_step(unsigned long gla);
+int hvm_event_single_step(unsigned long gla);
 
 /*
  * Nested HVM
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZuG-0007zE-Q7; Wed, 12 Nov 2014 15:32:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZuF-0007xd-0k
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:27 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	FB/F6-22737-A8D73645; Wed, 12 Nov 2014 15:32:26 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415806344!5516326!1
X-Originating-IP: [209.85.216.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21772 invoked from network); 12 Nov 2014 15:32:25 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:25 -0000
Received: by mail-qc0-f169.google.com with SMTP id i17so9567750qcy.0
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=XzFpeOOcOKliD6mCl/47WmC5yOOeYT7XgJ+jzLWiZFw=;
	b=gb5GQqUhdr0XAAuEOxvGMnRDnO7z3d6wsJv9UTa77b7n7qmc5hFdIB8plADBmWkz5M
	DdZrFZlU4XJfVvGWZTdgZXhn8Dg5mH7xaEfdVSb32ahO87xaQHLOjOTtxXMmUX7flJn3
	BqFMCwCr6HREzcoRlC86VC2gAIUqP3vHe4E2t/mETAp2ay3M8hAnqRUqNtGT/laiYjPo
	2Tu/ekD8eLeye20EnfoqGVDkJLp23fYOVMUZODswgLhQZzev4Q5c+6KoOsTseAGqb884
	dqEbVqf9x+Dh2BpH96OwFVdqOVOeGOjga7qWJ8CHzC+nmbbeV899+niCn8x4H2IbZsDC
	gr8g==
X-Gm-Message-State: ALoCoQlECFsgdcWC/7lVBBWQDF7rk3fmTFl+NG1bmT9raIGthOKH1Sx9BnfxO6pt2kBgTZeliyRE
X-Received: by 10.224.3.196 with SMTP id 4mr22727342qao.79.1415806343922;
	Wed, 12 Nov 2014 07:32:23 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.21 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:23 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:48 +0100
Message-Id: <1415806309-5206-7-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 6/7] xen/vm_event: Decouple vm_event and
	mem_access.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access needs to be supported
in order to enable vm_event.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 xen/common/Makefile        |  2 +-
 xen/include/xen/vm_event.h | 58 +---------------------------------------------
 xen/include/xsm/dummy.h    |  2 --
 xen/include/xsm/xsm.h      |  2 --
 xen/xsm/dummy.c            |  2 --
 xen/xsm/flask/hooks.c      | 32 +++++++++++--------------
 6 files changed, 15 insertions(+), 83 deletions(-)

diff --git a/xen/common/Makefile b/xen/common/Makefile
index f1b73a3..2ccf0bb 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -52,9 +52,9 @@ obj-y += tmem_xen.o
 obj-y += radix-tree.o
 obj-y += rbtree.o
 obj-y += lzo.o
+obj-y += vm_event.o
 obj-$(HAS_PDX) += pdx.o
 obj-$(HAS_MEM_ACCESS) += mem_access.o
-obj-$(HAS_MEM_ACCESS) += vm_event.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo unlz4 earlycpio,$(n).init.o)
 
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index e6e31cd..477ef7e 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -26,8 +26,6 @@
 
 #include <xen/sched.h>
 
-#ifdef HAS_MEM_ACCESS
-
 /* Clean up on domain destruction */
 void vm_event_cleanup(struct domain *d);
 
@@ -76,61 +74,7 @@ int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *mec,
 void vm_event_vcpu_pause(struct vcpu *v);
 void vm_event_vcpu_unpause(struct vcpu *v);
 
-#else
-
-static inline void vm_event_cleanup(struct domain *d) {}
-
-static inline bool_t vm_event_check_ring(struct vm_event_domain *med)
-{
-    return 0;
-}
-
-static inline int vm_event_claim_slot(struct domain *d,
-                                        struct vm_event_domain *med)
-{
-    return -ENOSYS;
-}
-
-static inline int vm_event_claim_slot_nosleep(struct domain *d,
-                                        struct vm_event_domain *med)
-{
-    return -ENOSYS;
-}
-
-static inline
-void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *med)
-{}
-
-static inline
-void vm_event_put_request(struct domain *d, struct vm_event_domain *med,
-                            vm_event_request_t *req)
-{}
-
-static inline
-int vm_event_get_response(struct domain *d, struct vm_event_domain *med,
-                           vm_event_response_t *rsp)
-{
-    return -ENOSYS;
-}
-
-static inline int do_vm_event_op(int op, uint32_t domain, void *arg)
-{
-    return -ENOSYS;
-}
-
-static inline
-int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *mec,
-                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
-{
-    return -ENOSYS;
-}
-
-static inline void vm_event_vcpu_pause(struct vcpu *v) {}
-static inline void vm_event_vcpu_unpause(struct vcpu *v) {}
-
-#endif /* HAS_MEM_ACCESS */
-
-#endif /* __MEM_EVENT_H__ */
+#endif /* __VM_EVENT_H__ */
 
 
 /*
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 4227093..50ee929 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -513,7 +513,6 @@ static XSM_INLINE int xsm_hvm_param_nested(XSM_DEFAULT_ARG struct domain *d)
     return xsm_default_action(action, current->domain, d);
 }
 
-#ifdef HAS_MEM_ACCESS
 static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, int mode, int op)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
@@ -525,7 +524,6 @@ static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
     XSM_ASSERT_ACTION(XSM_DM_PRIV);
     return xsm_default_action(action, current->domain, d);
 }
-#endif
 
 #ifdef CONFIG_X86
 static XSM_INLINE int xsm_do_mca(XSM_DEFAULT_VOID)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cff9d35..61c5acc 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -141,10 +141,8 @@ struct xsm_operations {
     int (*hvm_param_nested) (struct domain *d);
     int (*get_vnumainfo) (struct domain *d);
 
-#ifdef HAS_MEM_ACCESS
     int (*vm_event_control) (struct domain *d, int mode, int op);
     int (*vm_event_op) (struct domain *d, int op);
-#endif
 
 #ifdef CONFIG_X86
     int (*do_mca) (void);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 25fca68..6d12d32 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -118,10 +118,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, map_gmfn_foreign);
 
-#ifdef HAS_MEM_ACCESS
     set_to_dummy_if_null(ops, vm_event_control);
     set_to_dummy_if_null(ops, vm_event_op);
-#endif
 
 #ifdef CONFIG_X86
     set_to_dummy_if_null(ops, do_mca);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d706b1f..1f1b010 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -577,9 +577,7 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_iomem_permission:
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_set_target:
-#ifdef HAS_MEM_ACCESS
     case XEN_DOMCTL_vm_event_op:
-#endif
 #ifdef CONFIG_X86
     /* These have individual XSM hooks (arch/x86/domctl.c) */
     case XEN_DOMCTL_shadow_op:
@@ -1134,6 +1132,16 @@ static int flask_hvm_param_nested(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__NESTED);
 }
 
+static int flask_vm_event_control(struct domain *d, int mode, int op)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
+}
+
+static int flask_vm_event_op(struct domain *d, int op)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
+}
+
 #if defined(HAS_PASSTHROUGH) && defined(HAS_PCI)
 static int flask_get_device_group(uint32_t machine_bdf)
 {
@@ -1200,18 +1208,6 @@ static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
 }
 #endif /* HAS_PASSTHROUGH && HAS_PCI */
 
-#ifdef HAS_MEM_ACCESS
-static int flask_vm_event_control(struct domain *d, int mode, int op)
-{
-    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
-}
-
-static int flask_vm_event_op(struct domain *d, int op)
-{
-    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
-}
-#endif /* HAS_MEM_ACCESS */
-
 #ifdef CONFIG_X86
 static int flask_do_mca(void)
 {
@@ -1579,6 +1575,9 @@ static struct xsm_operations flask_ops = {
     .do_xsm_op = do_flask_op,
     .get_vnumainfo = flask_get_vnumainfo,
 
+    .vm_event_control = flask_vm_event_control,
+    .vm_event_op = flask_vm_event_op,
+
 #ifdef CONFIG_COMPAT
     .do_compat_op = compat_flask_op,
 #endif
@@ -1594,11 +1593,6 @@ static struct xsm_operations flask_ops = {
     .deassign_device = flask_deassign_device,
 #endif
 
-#ifdef HAS_MEM_ACCESS
-    .vm_event_control = flask_vm_event_control,
-    .vm_event_op = flask_vm_event_op,
-#endif
-
 #ifdef CONFIG_X86
     .do_mca = flask_do_mca,
     .shadow_control = flask_shadow_control,
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZuG-0007zE-Q7; Wed, 12 Nov 2014 15:32:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZuF-0007xd-0k
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:27 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	FB/F6-22737-A8D73645; Wed, 12 Nov 2014 15:32:26 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415806344!5516326!1
X-Originating-IP: [209.85.216.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21772 invoked from network); 12 Nov 2014 15:32:25 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:25 -0000
Received: by mail-qc0-f169.google.com with SMTP id i17so9567750qcy.0
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=XzFpeOOcOKliD6mCl/47WmC5yOOeYT7XgJ+jzLWiZFw=;
	b=gb5GQqUhdr0XAAuEOxvGMnRDnO7z3d6wsJv9UTa77b7n7qmc5hFdIB8plADBmWkz5M
	DdZrFZlU4XJfVvGWZTdgZXhn8Dg5mH7xaEfdVSb32ahO87xaQHLOjOTtxXMmUX7flJn3
	BqFMCwCr6HREzcoRlC86VC2gAIUqP3vHe4E2t/mETAp2ay3M8hAnqRUqNtGT/laiYjPo
	2Tu/ekD8eLeye20EnfoqGVDkJLp23fYOVMUZODswgLhQZzev4Q5c+6KoOsTseAGqb884
	dqEbVqf9x+Dh2BpH96OwFVdqOVOeGOjga7qWJ8CHzC+nmbbeV899+niCn8x4H2IbZsDC
	gr8g==
X-Gm-Message-State: ALoCoQlECFsgdcWC/7lVBBWQDF7rk3fmTFl+NG1bmT9raIGthOKH1Sx9BnfxO6pt2kBgTZeliyRE
X-Received: by 10.224.3.196 with SMTP id 4mr22727342qao.79.1415806343922;
	Wed, 12 Nov 2014 07:32:23 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.21 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:23 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:48 +0100
Message-Id: <1415806309-5206-7-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 6/7] xen/vm_event: Decouple vm_event and
	mem_access.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access needs to be supported
in order to enable vm_event.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 xen/common/Makefile        |  2 +-
 xen/include/xen/vm_event.h | 58 +---------------------------------------------
 xen/include/xsm/dummy.h    |  2 --
 xen/include/xsm/xsm.h      |  2 --
 xen/xsm/dummy.c            |  2 --
 xen/xsm/flask/hooks.c      | 32 +++++++++++--------------
 6 files changed, 15 insertions(+), 83 deletions(-)

diff --git a/xen/common/Makefile b/xen/common/Makefile
index f1b73a3..2ccf0bb 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -52,9 +52,9 @@ obj-y += tmem_xen.o
 obj-y += radix-tree.o
 obj-y += rbtree.o
 obj-y += lzo.o
+obj-y += vm_event.o
 obj-$(HAS_PDX) += pdx.o
 obj-$(HAS_MEM_ACCESS) += mem_access.o
-obj-$(HAS_MEM_ACCESS) += vm_event.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo unlz4 earlycpio,$(n).init.o)
 
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index e6e31cd..477ef7e 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -26,8 +26,6 @@
 
 #include <xen/sched.h>
 
-#ifdef HAS_MEM_ACCESS
-
 /* Clean up on domain destruction */
 void vm_event_cleanup(struct domain *d);
 
@@ -76,61 +74,7 @@ int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *mec,
 void vm_event_vcpu_pause(struct vcpu *v);
 void vm_event_vcpu_unpause(struct vcpu *v);
 
-#else
-
-static inline void vm_event_cleanup(struct domain *d) {}
-
-static inline bool_t vm_event_check_ring(struct vm_event_domain *med)
-{
-    return 0;
-}
-
-static inline int vm_event_claim_slot(struct domain *d,
-                                        struct vm_event_domain *med)
-{
-    return -ENOSYS;
-}
-
-static inline int vm_event_claim_slot_nosleep(struct domain *d,
-                                        struct vm_event_domain *med)
-{
-    return -ENOSYS;
-}
-
-static inline
-void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *med)
-{}
-
-static inline
-void vm_event_put_request(struct domain *d, struct vm_event_domain *med,
-                            vm_event_request_t *req)
-{}
-
-static inline
-int vm_event_get_response(struct domain *d, struct vm_event_domain *med,
-                           vm_event_response_t *rsp)
-{
-    return -ENOSYS;
-}
-
-static inline int do_vm_event_op(int op, uint32_t domain, void *arg)
-{
-    return -ENOSYS;
-}
-
-static inline
-int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *mec,
-                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
-{
-    return -ENOSYS;
-}
-
-static inline void vm_event_vcpu_pause(struct vcpu *v) {}
-static inline void vm_event_vcpu_unpause(struct vcpu *v) {}
-
-#endif /* HAS_MEM_ACCESS */
-
-#endif /* __MEM_EVENT_H__ */
+#endif /* __VM_EVENT_H__ */
 
 
 /*
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 4227093..50ee929 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -513,7 +513,6 @@ static XSM_INLINE int xsm_hvm_param_nested(XSM_DEFAULT_ARG struct domain *d)
     return xsm_default_action(action, current->domain, d);
 }
 
-#ifdef HAS_MEM_ACCESS
 static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, int mode, int op)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
@@ -525,7 +524,6 @@ static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
     XSM_ASSERT_ACTION(XSM_DM_PRIV);
     return xsm_default_action(action, current->domain, d);
 }
-#endif
 
 #ifdef CONFIG_X86
 static XSM_INLINE int xsm_do_mca(XSM_DEFAULT_VOID)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cff9d35..61c5acc 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -141,10 +141,8 @@ struct xsm_operations {
     int (*hvm_param_nested) (struct domain *d);
     int (*get_vnumainfo) (struct domain *d);
 
-#ifdef HAS_MEM_ACCESS
     int (*vm_event_control) (struct domain *d, int mode, int op);
     int (*vm_event_op) (struct domain *d, int op);
-#endif
 
 #ifdef CONFIG_X86
     int (*do_mca) (void);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 25fca68..6d12d32 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -118,10 +118,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, map_gmfn_foreign);
 
-#ifdef HAS_MEM_ACCESS
     set_to_dummy_if_null(ops, vm_event_control);
     set_to_dummy_if_null(ops, vm_event_op);
-#endif
 
 #ifdef CONFIG_X86
     set_to_dummy_if_null(ops, do_mca);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d706b1f..1f1b010 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -577,9 +577,7 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_iomem_permission:
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_set_target:
-#ifdef HAS_MEM_ACCESS
     case XEN_DOMCTL_vm_event_op:
-#endif
 #ifdef CONFIG_X86
     /* These have individual XSM hooks (arch/x86/domctl.c) */
     case XEN_DOMCTL_shadow_op:
@@ -1134,6 +1132,16 @@ static int flask_hvm_param_nested(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__NESTED);
 }
 
+static int flask_vm_event_control(struct domain *d, int mode, int op)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
+}
+
+static int flask_vm_event_op(struct domain *d, int op)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
+}
+
 #if defined(HAS_PASSTHROUGH) && defined(HAS_PCI)
 static int flask_get_device_group(uint32_t machine_bdf)
 {
@@ -1200,18 +1208,6 @@ static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
 }
 #endif /* HAS_PASSTHROUGH && HAS_PCI */
 
-#ifdef HAS_MEM_ACCESS
-static int flask_vm_event_control(struct domain *d, int mode, int op)
-{
-    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
-}
-
-static int flask_vm_event_op(struct domain *d, int op)
-{
-    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
-}
-#endif /* HAS_MEM_ACCESS */
-
 #ifdef CONFIG_X86
 static int flask_do_mca(void)
 {
@@ -1579,6 +1575,9 @@ static struct xsm_operations flask_ops = {
     .do_xsm_op = do_flask_op,
     .get_vnumainfo = flask_get_vnumainfo,
 
+    .vm_event_control = flask_vm_event_control,
+    .vm_event_op = flask_vm_event_op,
+
 #ifdef CONFIG_COMPAT
     .do_compat_op = compat_flask_op,
 #endif
@@ -1594,11 +1593,6 @@ static struct xsm_operations flask_ops = {
     .deassign_device = flask_deassign_device,
 #endif
 
-#ifdef HAS_MEM_ACCESS
-    .vm_event_control = flask_vm_event_control,
-    .vm_event_op = flask_vm_event_op,
-#endif
-
 #ifdef CONFIG_X86
     .do_mca = flask_do_mca,
     .shadow_control = flask_shadow_control,
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZuI-000815-6p; Wed, 12 Nov 2014 15:32:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZuG-0007yy-Qx
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:29 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	7E/86-03145-C8D73645; Wed, 12 Nov 2014 15:32:28 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415806346!12082392!1
X-Originating-IP: [209.85.192.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21987 invoked from network); 12 Nov 2014 15:32:27 -0000
Received: from mail-qg0-f50.google.com (HELO mail-qg0-f50.google.com)
	(209.85.192.50)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:27 -0000
Received: by mail-qg0-f50.google.com with SMTP id a108so8819867qge.23
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=7iCeC0uH3Z7oEetXBuyEMJOCDohlPrhHNlUYqw+Ma9U=;
	b=WOTgYD/+wc0BNJ3d4I5pIJal5e7DyNnDV7FC6T/22WXozJR9ZIsHGWu0f6Q4xal3DW
	iJyBMGVuB4s56jN2B9m+fg26tU5SCYzjZKcsZahRiG/UXg4gCISMJ/PHTxx6dVlarTug
	fS86J3QsIggIvHPZI6SiCxhzh31EtDJh4V0dTygUlBew8K5KO+KFJkaRr5iU0fgK4qem
	FcfIpIK3XIrCqGOGjXcMVuhRElDJt26mdZdM/yQ+wMkWHXYIKk3nl38PILgBCxoKaqW8
	s0SgL9Nukj5UAAQsLyw5MHfCEACHys8XmXPiUqXGHKVrtPoTDF1m45z2dDYHyjT/NW7Y
	DBdg==
X-Gm-Message-State: ALoCoQnuGInN83VDLLs8vzbBNaXTdXQ4JoSTRnNACUOlgTrcfvLaHRAJCv6xKLMbISc9Cb/rWN7x
X-Received: by 10.140.93.163 with SMTP id d32mr5076381qge.37.1415806346001;
	Wed, 12 Nov 2014 07:32:26 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.24 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:25 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:49 +0100
Message-Id: <1415806309-5206-8-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 7/7] tools/tests: Remove superfluous and
	incomplete spinlock from xen-access
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The spin-lock implementation in the xen-access test program is implemented
in a fashion that is actually incomplete. The x86 assembly that guarantees that
the lock is held by only one thread lacks the "lock;" instruction.

However, the spin-lock is not actually necessary in xen-access as it is not
multithreaded. The presence of the faulty implementation of the lock in a non-
mulithreaded environment is unnecessarily complicated for developers who are
trying to follow this code as a guide in implementing their own applications.
Thus, removing it from the code improves the clarity on the behavior of the
system.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 tools/tests/xen-access/xen-access.c | 68 ++++---------------------------------
 1 file changed, 6 insertions(+), 62 deletions(-)

diff --git a/tools/tests/xen-access/xen-access.c b/tools/tests/xen-access/xen-access.c
index 3538323..428c459 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -45,56 +45,6 @@
 #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
 #define PERROR(a, b...) fprintf(stderr, a ": %s\n", ## b, strerror(errno))
 
-/* Spinlock and mem event definitions */
-
-#define SPIN_LOCK_UNLOCKED 0
-
-#define ADDR (*(volatile long *) addr)
-/**
- * test_and_set_bit - Set a bit and return its old value
- * @nr: Bit to set
- * @addr: Address to count from
- *
- * This operation is atomic and cannot be reordered.
- * It also implies a memory barrier.
- */
-static inline int test_and_set_bit(int nr, volatile void *addr)
-{
-    int oldbit;
-
-    asm volatile (
-        "btsl %2,%1\n\tsbbl %0,%0"
-        : "=r" (oldbit), "=m" (ADDR)
-        : "Ir" (nr), "m" (ADDR) : "memory");
-    return oldbit;
-}
-
-typedef int spinlock_t;
-
-static inline void spin_lock(spinlock_t *lock)
-{
-    while ( test_and_set_bit(1, lock) );
-}
-
-static inline void spin_lock_init(spinlock_t *lock)
-{
-    *lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline void spin_unlock(spinlock_t *lock)
-{
-    *lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline int spin_trylock(spinlock_t *lock)
-{
-    return !test_and_set_bit(1, lock);
-}
-
-#define vm_event_ring_lock_init(_m)  spin_lock_init(&(_m)->ring_lock)
-#define vm_event_ring_lock(_m)       spin_lock(&(_m)->ring_lock)
-#define vm_event_ring_unlock(_m)     spin_unlock(&(_m)->ring_lock)
-
 typedef struct vm_event {
     domid_t domain_id;
     xc_evtchn *xce_handle;
@@ -102,7 +52,6 @@ typedef struct vm_event {
     vm_event_back_ring_t back_ring;
     uint32_t evtchn_port;
     void *ring_page;
-    spinlock_t ring_lock;
 } vm_event_t;
 
 typedef struct xenaccess {
@@ -241,9 +190,6 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     /* Set domain id */
     xenaccess->vm_event.domain_id = domain_id;
 
-    /* Initialise lock */
-    vm_event_ring_lock_init(&xenaccess->vm_event);
-
     /* Enable mem_access */
     xenaccess->vm_event.ring_page =
             xc_mem_access_enable(xenaccess->xc_handle,
@@ -320,13 +266,14 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     return NULL;
 }
 
+/*
+ * Note that this function is not thread safe.
+ */
 int get_request(vm_event_t *vm_event, vm_event_request_t *req)
 {
     vm_event_back_ring_t *back_ring;
     RING_IDX req_cons;
 
-    vm_event_ring_lock(vm_event);
-
     back_ring = &vm_event->back_ring;
     req_cons = back_ring->req_cons;
 
@@ -338,18 +285,17 @@ int get_request(vm_event_t *vm_event, vm_event_request_t *req)
     back_ring->req_cons = req_cons;
     back_ring->sring->req_event = req_cons + 1;
 
-    vm_event_ring_unlock(vm_event);
-
     return 0;
 }
 
+/*
+ * Note that this function is not thread safe.
+ */
 static int put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
 {
     vm_event_back_ring_t *back_ring;
     RING_IDX rsp_prod;
 
-    vm_event_ring_lock(vm_event);
-
     back_ring = &vm_event->back_ring;
     rsp_prod = back_ring->rsp_prod_pvt;
 
@@ -361,8 +307,6 @@ static int put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
     back_ring->rsp_prod_pvt = rsp_prod;
     RING_PUSH_RESPONSES(back_ring);
 
-    vm_event_ring_unlock(vm_event);
-
     return 0;
 }
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZuI-000815-6p; Wed, 12 Nov 2014 15:32:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZuG-0007yy-Qx
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:29 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	7E/86-03145-C8D73645; Wed, 12 Nov 2014 15:32:28 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415806346!12082392!1
X-Originating-IP: [209.85.192.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21987 invoked from network); 12 Nov 2014 15:32:27 -0000
Received: from mail-qg0-f50.google.com (HELO mail-qg0-f50.google.com)
	(209.85.192.50)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:27 -0000
Received: by mail-qg0-f50.google.com with SMTP id a108so8819867qge.23
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=7iCeC0uH3Z7oEetXBuyEMJOCDohlPrhHNlUYqw+Ma9U=;
	b=WOTgYD/+wc0BNJ3d4I5pIJal5e7DyNnDV7FC6T/22WXozJR9ZIsHGWu0f6Q4xal3DW
	iJyBMGVuB4s56jN2B9m+fg26tU5SCYzjZKcsZahRiG/UXg4gCISMJ/PHTxx6dVlarTug
	fS86J3QsIggIvHPZI6SiCxhzh31EtDJh4V0dTygUlBew8K5KO+KFJkaRr5iU0fgK4qem
	FcfIpIK3XIrCqGOGjXcMVuhRElDJt26mdZdM/yQ+wMkWHXYIKk3nl38PILgBCxoKaqW8
	s0SgL9Nukj5UAAQsLyw5MHfCEACHys8XmXPiUqXGHKVrtPoTDF1m45z2dDYHyjT/NW7Y
	DBdg==
X-Gm-Message-State: ALoCoQnuGInN83VDLLs8vzbBNaXTdXQ4JoSTRnNACUOlgTrcfvLaHRAJCv6xKLMbISc9Cb/rWN7x
X-Received: by 10.140.93.163 with SMTP id d32mr5076381qge.37.1415806346001;
	Wed, 12 Nov 2014 07:32:26 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.24 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:25 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:49 +0100
Message-Id: <1415806309-5206-8-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 7/7] tools/tests: Remove superfluous and
	incomplete spinlock from xen-access
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The spin-lock implementation in the xen-access test program is implemented
in a fashion that is actually incomplete. The x86 assembly that guarantees that
the lock is held by only one thread lacks the "lock;" instruction.

However, the spin-lock is not actually necessary in xen-access as it is not
multithreaded. The presence of the faulty implementation of the lock in a non-
mulithreaded environment is unnecessarily complicated for developers who are
trying to follow this code as a guide in implementing their own applications.
Thus, removing it from the code improves the clarity on the behavior of the
system.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 tools/tests/xen-access/xen-access.c | 68 ++++---------------------------------
 1 file changed, 6 insertions(+), 62 deletions(-)

diff --git a/tools/tests/xen-access/xen-access.c b/tools/tests/xen-access/xen-access.c
index 3538323..428c459 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -45,56 +45,6 @@
 #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
 #define PERROR(a, b...) fprintf(stderr, a ": %s\n", ## b, strerror(errno))
 
-/* Spinlock and mem event definitions */
-
-#define SPIN_LOCK_UNLOCKED 0
-
-#define ADDR (*(volatile long *) addr)
-/**
- * test_and_set_bit - Set a bit and return its old value
- * @nr: Bit to set
- * @addr: Address to count from
- *
- * This operation is atomic and cannot be reordered.
- * It also implies a memory barrier.
- */
-static inline int test_and_set_bit(int nr, volatile void *addr)
-{
-    int oldbit;
-
-    asm volatile (
-        "btsl %2,%1\n\tsbbl %0,%0"
-        : "=r" (oldbit), "=m" (ADDR)
-        : "Ir" (nr), "m" (ADDR) : "memory");
-    return oldbit;
-}
-
-typedef int spinlock_t;
-
-static inline void spin_lock(spinlock_t *lock)
-{
-    while ( test_and_set_bit(1, lock) );
-}
-
-static inline void spin_lock_init(spinlock_t *lock)
-{
-    *lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline void spin_unlock(spinlock_t *lock)
-{
-    *lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline int spin_trylock(spinlock_t *lock)
-{
-    return !test_and_set_bit(1, lock);
-}
-
-#define vm_event_ring_lock_init(_m)  spin_lock_init(&(_m)->ring_lock)
-#define vm_event_ring_lock(_m)       spin_lock(&(_m)->ring_lock)
-#define vm_event_ring_unlock(_m)     spin_unlock(&(_m)->ring_lock)
-
 typedef struct vm_event {
     domid_t domain_id;
     xc_evtchn *xce_handle;
@@ -102,7 +52,6 @@ typedef struct vm_event {
     vm_event_back_ring_t back_ring;
     uint32_t evtchn_port;
     void *ring_page;
-    spinlock_t ring_lock;
 } vm_event_t;
 
 typedef struct xenaccess {
@@ -241,9 +190,6 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     /* Set domain id */
     xenaccess->vm_event.domain_id = domain_id;
 
-    /* Initialise lock */
-    vm_event_ring_lock_init(&xenaccess->vm_event);
-
     /* Enable mem_access */
     xenaccess->vm_event.ring_page =
             xc_mem_access_enable(xenaccess->xc_handle,
@@ -320,13 +266,14 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     return NULL;
 }
 
+/*
+ * Note that this function is not thread safe.
+ */
 int get_request(vm_event_t *vm_event, vm_event_request_t *req)
 {
     vm_event_back_ring_t *back_ring;
     RING_IDX req_cons;
 
-    vm_event_ring_lock(vm_event);
-
     back_ring = &vm_event->back_ring;
     req_cons = back_ring->req_cons;
 
@@ -338,18 +285,17 @@ int get_request(vm_event_t *vm_event, vm_event_request_t *req)
     back_ring->req_cons = req_cons;
     back_ring->sring->req_event = req_cons + 1;
 
-    vm_event_ring_unlock(vm_event);
-
     return 0;
 }
 
+/*
+ * Note that this function is not thread safe.
+ */
 static int put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
 {
     vm_event_back_ring_t *back_ring;
     RING_IDX rsp_prod;
 
-    vm_event_ring_lock(vm_event);
-
     back_ring = &vm_event->back_ring;
     rsp_prod = back_ring->rsp_prod_pvt;
 
@@ -361,8 +307,6 @@ static int put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
     back_ring->rsp_prod_pvt = rsp_prod;
     RING_PUSH_RESPONSES(back_ring);
 
-    vm_event_ring_unlock(vm_event);
-
     return 0;
 }
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZuI-00081w-O2; Wed, 12 Nov 2014 15:32:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZuG-0007yv-P8
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/E7-24532-C8D73645; Wed, 12 Nov 2014 15:32:28 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415806342!12260474!1
X-Originating-IP: [209.85.216.182]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22797 invoked from network); 12 Nov 2014 15:32:22 -0000
Received: from mail-qc0-f182.google.com (HELO mail-qc0-f182.google.com)
	(209.85.216.182)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:22 -0000
Received: by mail-qc0-f182.google.com with SMTP id m20so9655656qcx.27
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=7fen1pMWxJntn5ybJKQwF2PmfG+2GwaM7rtmrUa/Ifs=;
	b=amKEhrvU/7pPY3zO6MHc0/PK7I1pIUqDe+gg8XfHarHdy18e9Mz+61C10Nbe0sa/3C
	1MQAd2CANfb6Ix0NfXDnzBQJt9NQdXrUaNnWUp0HRtXn2i2yPC4/zn2FOz3l3yEkj0SI
	V8iH0EugfAla/T+cJK8AVqzX1A8yQ40SN1nEqpboJmSnS5Nc8aqi2mEDtR36+QPVArGc
	qduR+ti1gkk28We9jKyAx2B4CF8nQbeaNDWscFY8THI99RjoBXZlNANAycBQg9Z5+vkL
	Cj44fDuQ9VWWDoSb57f/zGM11M4iXK04+VEhk8FveTGX86q9NxfKxjayNkynDOFJ7EOv
	Tjkw==
X-Gm-Message-State: ALoCoQk6ZZ0u10/psqE1VVczNrlsN7QU7aQHm0m2Cz1JhP+eDx6C1qYeEwwDxsa2SdLEaRAq2cwZ
X-Received: by 10.224.29.1 with SMTP id o1mr63293587qac.23.1415806341733;
	Wed, 12 Nov 2014 07:32:21 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.19 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:21 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:47 +0100
Message-Id: <1415806309-5206-6-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 5/7] xen/mem_event: Rename mem_event to
	vm_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>
MIME-Version: 1.0
Content-Type: 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 mem_event system has originally been used to deliver memory event
related information to helper programs located in a domain. However,
the usage of this sub-system have since been expanded to include non-memory
related events as well, such as register changes, debugging and singlestepping.
Therefore, renaming the system "vm_event" more accurately describes the actual
usage of the subsystem.

In this patch I also clear up the ambiguities that resulted from the interchanged
mem_event and mem_access terminology.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 tools/libxc/Makefile                |   2 +-
 tools/libxc/xc_mem_access.c         |  10 +-
 tools/libxc/xc_mem_event.c          | 162 --------
 tools/libxc/xc_mem_paging.c         |  12 +-
 tools/libxc/xc_memshr.c             |  12 +-
 tools/libxc/xc_private.h            |   6 +-
 tools/libxc/xc_vm_event.c           | 162 ++++++++
 tools/tests/xen-access/xen-access.c | 104 ++---
 tools/xenpaging/pagein.c            |   2 +-
 tools/xenpaging/xenpaging.c         | 118 +++---
 tools/xenpaging/xenpaging.h         |   8 +-
 xen/arch/x86/domain.c               |   2 +-
 xen/arch/x86/domctl.c               |   4 +-
 xen/arch/x86/hvm/emulate.c          |   4 +-
 xen/arch/x86/hvm/hvm.c              |  44 +--
 xen/arch/x86/hvm/vmx/vmcs.c         |   4 +-
 xen/arch/x86/mm/hap/nested_ept.c    |   4 +-
 xen/arch/x86/mm/hap/nested_hap.c    |   4 +-
 xen/arch/x86/mm/mem_paging.c        |   4 +-
 xen/arch/x86/mm/mem_sharing.c       |  28 +-
 xen/arch/x86/mm/p2m-pod.c           |   4 +-
 xen/arch/x86/mm/p2m-pt.c            |   4 +-
 xen/arch/x86/mm/p2m.c               |  94 ++---
 xen/arch/x86/x86_64/compat/mm.c     |   6 +-
 xen/arch/x86/x86_64/mm.c            |   6 +-
 xen/common/Makefile                 |   2 +-
 xen/common/domain.c                 |  12 +-
 xen/common/domctl.c                 |   6 +-
 xen/common/mem_access.c             |  24 +-
 xen/common/mem_event.c              | 742 ------------------------------------
 xen/common/vm_event.c               | 742 ++++++++++++++++++++++++++++++++++++
 xen/drivers/passthrough/pci.c       |   2 +-
 xen/include/asm-arm/p2m.h           |   6 +-
 xen/include/asm-x86/domain.h        |   4 +-
 xen/include/asm-x86/hvm/emulate.h   |   2 +-
 xen/include/asm-x86/p2m.h           |  16 +-
 xen/include/public/domctl.h         |  42 +-
 xen/include/public/mem_event.h      | 179 ---------
 xen/include/public/vm_event.h       | 179 +++++++++
 xen/include/xen/mem_access.h        |   4 +-
 xen/include/xen/mem_event.h         | 143 -------
 xen/include/xen/p2m-common.h        |   4 +-
 xen/include/xen/sched.h             |  26 +-
 xen/include/xen/vm_event.h          | 143 +++++++
 xen/include/xsm/dummy.h             |   4 +-
 xen/include/xsm/xsm.h               |  12 +-
 xen/xsm/dummy.c                     |   4 +-
 xen/xsm/flask/hooks.c               |  16 +-
 xen/xsm/flask/policy/access_vectors |   2 +-
 49 files changed, 1560 insertions(+), 1566 deletions(-)
 delete mode 100644 tools/libxc/xc_mem_event.c
 create mode 100644 tools/libxc/xc_vm_event.c
 delete mode 100644 xen/common/mem_event.c
 create mode 100644 xen/common/vm_event.c
 delete mode 100644 xen/include/public/mem_event.h
 create mode 100644 xen/include/public/vm_event.h
 delete mode 100644 xen/include/xen/mem_event.h
 create mode 100644 xen/include/xen/vm_event.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index bd2ca6c..6ef17ec 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -26,7 +26,7 @@ CTRL_SRCS-y       += xc_pm.c
 CTRL_SRCS-y       += xc_cpu_hotplug.c
 CTRL_SRCS-y       += xc_resume.c
 CTRL_SRCS-y       += xc_tmem.c
-CTRL_SRCS-y       += xc_mem_event.c
+CTRL_SRCS-y       += xc_vm_event.c
 CTRL_SRCS-y       += xc_mem_paging.c
 CTRL_SRCS-y       += xc_mem_access.c
 CTRL_SRCS-y       += xc_memshr.c
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 1c979ed..80f4e2d 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -26,22 +26,22 @@
 
 void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t *port)
 {
-    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
+    return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
                                port, 0);
 }
 
 void *xc_mem_access_enable_introspection(xc_interface *xch, domid_t domain_id,
                                          uint32_t *port)
 {
-    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
+    return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
                                port, 1);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE,
-                                XEN_DOMCTL_MEM_EVENT_OP_MONITOR,
+    return xc_vm_event_control(xch, domain_id,
+                                XEN_DOMCTL_VM_EVENT_OP_MONITOR_DISABLE,
+                                XEN_DOMCTL_VM_EVENT_OP_MONITOR,
                                 NULL);
 }
 
diff --git a/tools/libxc/xc_mem_event.c b/tools/libxc/xc_mem_event.c
deleted file mode 100644
index a5e0948..0000000
--- a/tools/libxc/xc_mem_event.c
+++ /dev/null
@@ -1,162 +0,0 @@
-/******************************************************************************
- *
- * xc_mem_event.c
- *
- * Interface to low-level memory event functionality.
- *
- * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
- *
- * 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
- */
-
-#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)
-{
-    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;
-    
-    rc = do_domctl(xch, &domctl);
-    if ( !rc && port )
-        *port = domctl.u.mem_event_op.port;
-    return rc;
-}
-
-void *xc_mem_event_enable(xc_interface *xch, domid_t domain_id, int param,
-                          uint32_t *port, int enable_introspection)
-{
-    void *ring_page = NULL;
-    uint64_t pfn;
-    xen_pfn_t ring_pfn, mmap_pfn;
-    unsigned int op, mode;
-    int rc1, rc2, saved_errno;
-
-    if ( !port )
-    {
-        errno = EINVAL;
-        return NULL;
-    }
-
-    /* Pause the domain for ring page setup */
-    rc1 = xc_domain_pause(xch, domain_id);
-    if ( rc1 != 0 )
-    {
-        PERROR("Unable to pause domain\n");
-        return NULL;
-    }
-
-    /* Get the pfn of the ring page */
-    rc1 = xc_hvm_param_get(xch, domain_id, param, &pfn);
-    if ( rc1 != 0 )
-    {
-        PERROR("Failed to get pfn of ring page\n");
-        goto out;
-    }
-
-    ring_pfn = pfn;
-    mmap_pfn = pfn;
-    ring_page = xc_map_foreign_batch(xch, domain_id, PROT_READ | PROT_WRITE,
-                                     &mmap_pfn, 1);
-    if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
-    {
-        /* Map failed, populate ring page */
-        rc1 = xc_domain_populate_physmap_exact(xch, domain_id, 1, 0, 0,
-                                              &ring_pfn);
-        if ( rc1 != 0 )
-        {
-            PERROR("Failed to populate ring pfn\n");
-            goto out;
-        }
-
-        mmap_pfn = ring_pfn;
-        ring_page = xc_map_foreign_batch(xch, 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 out;
-        }
-    }
-
-    switch ( param )
-    {
-    case HVM_PARAM_PAGING_RING_PFN:
-        op = XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE;
-        mode = XEN_DOMCTL_MEM_EVENT_OP_PAGING;
-        break;
-
-    case HVM_PARAM_MONITOR_RING_PFN:
-        if ( enable_introspection )
-            op = XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION;
-        else
-            op = XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE;
-        mode = XEN_DOMCTL_MEM_EVENT_OP_MONITOR;
-        break;
-
-    case HVM_PARAM_SHARING_RING_PFN:
-        op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE;
-        mode = XEN_DOMCTL_MEM_EVENT_OP_SHARING;
-        break;
-
-    /*
-     * This is for the outside chance that the HVM_PARAM is valid but is invalid
-     * as far as mem_event goes.
-     */
-    default:
-        errno = EINVAL;
-        rc1 = -1;
-        goto out;
-    }
-
-    rc1 = xc_mem_event_control(xch, domain_id, op, mode, port);
-    if ( rc1 != 0 )
-    {
-        PERROR("Failed to enable mem_event\n");
-        goto out;
-    }
-
-    /* Remove the ring_pfn from the guest's physmap */
-    rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0, &ring_pfn);
-    if ( rc1 != 0 )
-        PERROR("Failed to remove ring page from guest physmap");
-
- out:
-    saved_errno = errno;
-
-    rc2 = xc_domain_unpause(xch, domain_id);
-    if ( rc1 != 0 || rc2 != 0 )
-    {
-        if ( rc2 != 0 )
-        {
-            if ( rc1 == 0 )
-                saved_errno = errno;
-            PERROR("Unable to unpause domain");
-        }
-
-        if ( ring_page )
-            munmap(ring_page, XC_PAGE_SIZE);
-        ring_page = NULL;
-
-        errno = saved_errno;
-    }
-
-    return ring_page;
-}
diff --git a/tools/libxc/xc_mem_paging.c b/tools/libxc/xc_mem_paging.c
index bf3173d..8408b07 100644
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -47,17 +47,17 @@ int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
         return -1;
     }
         
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
+    return xc_vm_event_control(xch, domain_id,
+                                XEN_DOMCTL_VM_EVENT_OP_PAGING_ENABLE,
+                                XEN_DOMCTL_VM_EVENT_OP_PAGING,
                                 port);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
+    return xc_vm_event_control(xch, domain_id,
+                                XEN_DOMCTL_VM_EVENT_OP_PAGING_DISABLE,
+                                XEN_DOMCTL_VM_EVENT_OP_PAGING,
                                 NULL);
 }
 
diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
index d6a9539..fafa073 100644
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -52,18 +52,18 @@ int xc_memshr_ring_enable(xc_interface *xch,
         return -1;
     }
         
-    return xc_mem_event_control(xch, domid,
-                                XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE,
-                                XEN_DOMCTL_MEM_EVENT_OP_SHARING,
+    return xc_vm_event_control(xch, domid,
+                                XEN_DOMCTL_VM_EVENT_OP_SHARING_ENABLE,
+                                XEN_DOMCTL_VM_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,
+    return xc_vm_event_control(xch, domid,
+                                XEN_DOMCTL_VM_EVENT_OP_SHARING_DISABLE,
+                                XEN_DOMCTL_VM_EVENT_OP_SHARING,
                                 NULL);
 }
 
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index f1f601c..a539300 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -421,15 +421,15 @@ int xc_ffs64(uint64_t x);
 #define DOMPRINTF_CALLED(xch) xc_dom_printf((xch), "%s: called", __FUNCTION__)
 
 /**
- * mem_event operations. Internal use only.
+ * vm_event operations. Internal use only.
  */
-int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
+int xc_vm_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
                          unsigned int mode, uint32_t *port);
 /*
  * Enables mem_event and returns the mapped ring page indicated by param.
  * param can be HVM_PARAM_PAGING/ACCESS/SHARING_RING_PFN
  */
-void *xc_mem_event_enable(xc_interface *xch, domid_t domain_id, int param,
+void *xc_vm_event_enable(xc_interface *xch, domid_t domain_id, int param,
                           uint32_t *port, int enable_introspection);
 
 #endif /* __XC_PRIVATE_H__ */
diff --git a/tools/libxc/xc_vm_event.c b/tools/libxc/xc_vm_event.c
new file mode 100644
index 0000000..39d794d
--- /dev/null
+++ b/tools/libxc/xc_vm_event.c
@@ -0,0 +1,162 @@
+/******************************************************************************
+ *
+ * xc_vm_event.c
+ *
+ * Interface to low-level VM event functionality.
+ *
+ * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
+ *
+ * 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
+ */
+
+#include "xc_private.h"
+
+int xc_vm_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
+                         unsigned int mode, uint32_t *port)
+{
+    DECLARE_DOMCTL;
+    int rc;
+
+    domctl.cmd = XEN_DOMCTL_vm_event_op;
+    domctl.domain = domain_id;
+    domctl.u.vm_event_op.op = op;
+    domctl.u.vm_event_op.mode = mode;
+    
+    rc = do_domctl(xch, &domctl);
+    if ( !rc && port )
+        *port = domctl.u.vm_event_op.port;
+    return rc;
+}
+
+void *xc_vm_event_enable(xc_interface *xch, domid_t domain_id, int param,
+                          uint32_t *port, int enable_introspection)
+{
+    void *ring_page = NULL;
+    uint64_t pfn;
+    xen_pfn_t ring_pfn, mmap_pfn;
+    unsigned int op, mode;
+    int rc1, rc2, saved_errno;
+
+    if ( !port )
+    {
+        errno = EINVAL;
+        return NULL;
+    }
+
+    /* Pause the domain for ring page setup */
+    rc1 = xc_domain_pause(xch, domain_id);
+    if ( rc1 != 0 )
+    {
+        PERROR("Unable to pause domain\n");
+        return NULL;
+    }
+
+    /* Get the pfn of the ring page */
+    rc1 = xc_hvm_param_get(xch, domain_id, param, &pfn);
+    if ( rc1 != 0 )
+    {
+        PERROR("Failed to get pfn of ring page\n");
+        goto out;
+    }
+
+    ring_pfn = pfn;
+    mmap_pfn = pfn;
+    ring_page = xc_map_foreign_batch(xch, domain_id, PROT_READ | PROT_WRITE,
+                                     &mmap_pfn, 1);
+    if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
+    {
+        /* Map failed, populate ring page */
+        rc1 = xc_domain_populate_physmap_exact(xch, domain_id, 1, 0, 0,
+                                              &ring_pfn);
+        if ( rc1 != 0 )
+        {
+            PERROR("Failed to populate ring pfn\n");
+            goto out;
+        }
+
+        mmap_pfn = ring_pfn;
+        ring_page = xc_map_foreign_batch(xch, 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 out;
+        }
+    }
+
+    switch ( param )
+    {
+    case HVM_PARAM_PAGING_RING_PFN:
+        op = XEN_DOMCTL_VM_EVENT_OP_PAGING_ENABLE;
+        mode = XEN_DOMCTL_VM_EVENT_OP_PAGING;
+        break;
+
+    case HVM_PARAM_MONITOR_RING_PFN:
+        if ( enable_introspection )
+            op = XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION;
+        else
+            op = XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE;
+        mode = XEN_DOMCTL_VM_EVENT_OP_MONITOR;
+        break;
+
+    case HVM_PARAM_SHARING_RING_PFN:
+        op = XEN_DOMCTL_VM_EVENT_OP_SHARING_ENABLE;
+        mode = XEN_DOMCTL_VM_EVENT_OP_SHARING;
+        break;
+
+    /*
+     * This is for the outside chance that the HVM_PARAM is valid but is invalid
+     * as far as vm_event goes.
+     */
+    default:
+        errno = EINVAL;
+        rc1 = -1;
+        goto out;
+    }
+
+    rc1 = xc_vm_event_control(xch, domain_id, op, mode, port);
+    if ( rc1 != 0 )
+    {
+        PERROR("Failed to enable vm_event\n");
+        goto out;
+    }
+
+    /* Remove the ring_pfn from the guest's physmap */
+    rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0, &ring_pfn);
+    if ( rc1 != 0 )
+        PERROR("Failed to remove ring page from guest physmap");
+
+ out:
+    saved_errno = errno;
+
+    rc2 = xc_domain_unpause(xch, domain_id);
+    if ( rc1 != 0 || rc2 != 0 )
+    {
+        if ( rc2 != 0 )
+        {
+            if ( rc1 == 0 )
+                saved_errno = errno;
+            PERROR("Unable to unpause domain");
+        }
+
+        if ( ring_page )
+            munmap(ring_page, XC_PAGE_SIZE);
+        ring_page = NULL;
+
+        errno = saved_errno;
+    }
+
+    return ring_page;
+}
diff --git a/tools/tests/xen-access/xen-access.c b/tools/tests/xen-access/xen-access.c
index 9d53fb3..3538323 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -39,7 +39,7 @@
 #include <sys/poll.h>
 
 #include <xenctrl.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 
 #define DPRINTF(a, b...) fprintf(stderr, a, ## b)
 #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
@@ -91,26 +91,26 @@ static inline int spin_trylock(spinlock_t *lock)
     return !test_and_set_bit(1, lock);
 }
 
-#define mem_event_ring_lock_init(_m)  spin_lock_init(&(_m)->ring_lock)
-#define mem_event_ring_lock(_m)       spin_lock(&(_m)->ring_lock)
-#define mem_event_ring_unlock(_m)     spin_unlock(&(_m)->ring_lock)
+#define vm_event_ring_lock_init(_m)  spin_lock_init(&(_m)->ring_lock)
+#define vm_event_ring_lock(_m)       spin_lock(&(_m)->ring_lock)
+#define vm_event_ring_unlock(_m)     spin_unlock(&(_m)->ring_lock)
 
-typedef struct mem_event {
+typedef struct vm_event {
     domid_t domain_id;
     xc_evtchn *xce_handle;
     int port;
-    mem_event_back_ring_t back_ring;
+    vm_event_back_ring_t back_ring;
     uint32_t evtchn_port;
     void *ring_page;
     spinlock_t ring_lock;
-} mem_event_t;
+} vm_event_t;
 
 typedef struct xenaccess {
     xc_interface *xc_handle;
 
     xc_domaininfo_t    *domain_info;
 
-    mem_event_t mem_event;
+    vm_event_t vm_event;
 } xenaccess_t;
 
 static int interrupted;
@@ -170,13 +170,13 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
         return 0;
 
     /* Tear down domain xenaccess in Xen */
-    if ( xenaccess->mem_event.ring_page )
-        munmap(xenaccess->mem_event.ring_page, XC_PAGE_SIZE);
+    if ( xenaccess->vm_event.ring_page )
+        munmap(xenaccess->vm_event.ring_page, XC_PAGE_SIZE);
 
     if ( mem_access_enable )
     {
         rc = xc_mem_access_disable(xenaccess->xc_handle,
-                                   xenaccess->mem_event.domain_id);
+                                   xenaccess->vm_event.domain_id);
         if ( rc != 0 )
         {
             ERROR("Error tearing down domain xenaccess in xen");
@@ -186,8 +186,8 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
     /* Unbind VIRQ */
     if ( evtchn_bind )
     {
-        rc = xc_evtchn_unbind(xenaccess->mem_event.xce_handle,
-                              xenaccess->mem_event.port);
+        rc = xc_evtchn_unbind(xenaccess->vm_event.xce_handle,
+                              xenaccess->vm_event.port);
         if ( rc != 0 )
         {
             ERROR("Error unbinding event port");
@@ -197,7 +197,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
     /* Close event channel */
     if ( evtchn_open )
     {
-        rc = xc_evtchn_close(xenaccess->mem_event.xce_handle);
+        rc = xc_evtchn_close(xenaccess->vm_event.xce_handle);
         if ( rc != 0 )
         {
             ERROR("Error closing event channel");
@@ -239,17 +239,17 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     xenaccess->xc_handle = xch;
 
     /* Set domain id */
-    xenaccess->mem_event.domain_id = domain_id;
+    xenaccess->vm_event.domain_id = domain_id;
 
     /* Initialise lock */
-    mem_event_ring_lock_init(&xenaccess->mem_event);
+    vm_event_ring_lock_init(&xenaccess->vm_event);
 
     /* Enable mem_access */
-    xenaccess->mem_event.ring_page =
+    xenaccess->vm_event.ring_page =
             xc_mem_access_enable(xenaccess->xc_handle,
-                                 xenaccess->mem_event.domain_id,
-                                 &xenaccess->mem_event.evtchn_port);
-    if ( xenaccess->mem_event.ring_page == NULL )
+                                 xenaccess->vm_event.domain_id,
+                                 &xenaccess->vm_event.evtchn_port);
+    if ( xenaccess->vm_event.ring_page == NULL )
     {
         switch ( errno ) {
             case EBUSY:
@@ -267,8 +267,8 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     mem_access_enable = 1;
 
     /* Open event channel */
-    xenaccess->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
-    if ( xenaccess->mem_event.xce_handle == NULL )
+    xenaccess->vm_event.xce_handle = xc_evtchn_open(NULL, 0);
+    if ( xenaccess->vm_event.xce_handle == NULL )
     {
         ERROR("Failed to open event channel");
         goto err;
@@ -276,21 +276,21 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     evtchn_open = 1;
 
     /* Bind event notification */
-    rc = xc_evtchn_bind_interdomain(xenaccess->mem_event.xce_handle,
-                                    xenaccess->mem_event.domain_id,
-                                    xenaccess->mem_event.evtchn_port);
+    rc = xc_evtchn_bind_interdomain(xenaccess->vm_event.xce_handle,
+                                    xenaccess->vm_event.domain_id,
+                                    xenaccess->vm_event.evtchn_port);
     if ( rc < 0 )
     {
         ERROR("Failed to bind event channel");
         goto err;
     }
     evtchn_bind = 1;
-    xenaccess->mem_event.port = rc;
+    xenaccess->vm_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,
+    SHARED_RING_INIT((vm_event_sring_t *)xenaccess->vm_event.ring_page);
+    BACK_RING_INIT(&xenaccess->vm_event.back_ring,
+                   (vm_event_sring_t *)xenaccess->vm_event.ring_page,
                    XC_PAGE_SIZE);
 
     /* Get domaininfo */
@@ -320,14 +320,14 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     return NULL;
 }
 
-int get_request(mem_event_t *mem_event, mem_event_request_t *req)
+int get_request(vm_event_t *vm_event, vm_event_request_t *req)
 {
-    mem_event_back_ring_t *back_ring;
+    vm_event_back_ring_t *back_ring;
     RING_IDX req_cons;
 
-    mem_event_ring_lock(mem_event);
+    vm_event_ring_lock(vm_event);
 
-    back_ring = &mem_event->back_ring;
+    back_ring = &vm_event->back_ring;
     req_cons = back_ring->req_cons;
 
     /* Copy request */
@@ -338,19 +338,19 @@ int get_request(mem_event_t *mem_event, mem_event_request_t *req)
     back_ring->req_cons = req_cons;
     back_ring->sring->req_event = req_cons + 1;
 
-    mem_event_ring_unlock(mem_event);
+    vm_event_ring_unlock(vm_event);
 
     return 0;
 }
 
-static int put_response(mem_event_t *mem_event, mem_event_response_t *rsp)
+static int put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
 {
-    mem_event_back_ring_t *back_ring;
+    vm_event_back_ring_t *back_ring;
     RING_IDX rsp_prod;
 
-    mem_event_ring_lock(mem_event);
+    vm_event_ring_lock(vm_event);
 
-    back_ring = &mem_event->back_ring;
+    back_ring = &vm_event->back_ring;
     rsp_prod = back_ring->rsp_prod_pvt;
 
     /* Copy response */
@@ -361,24 +361,24 @@ static int put_response(mem_event_t *mem_event, mem_event_response_t *rsp)
     back_ring->rsp_prod_pvt = rsp_prod;
     RING_PUSH_RESPONSES(back_ring);
 
-    mem_event_ring_unlock(mem_event);
+    vm_event_ring_unlock(vm_event);
 
     return 0;
 }
 
-static int xenaccess_resume_page(xenaccess_t *paging, mem_event_response_t *rsp)
+static int xenaccess_resume_page(xenaccess_t *paging, vm_event_response_t *rsp)
 {
     int ret;
 
     /* Put the page info on the ring */
-    ret = put_response(&paging->mem_event, rsp);
+    ret = put_response(&paging->vm_event, rsp);
     if ( ret != 0 )
         goto out;
 
     /* Tell Xen page is ready */
-    ret = xc_mem_access_resume(paging->xc_handle, paging->mem_event.domain_id);
-    ret = xc_evtchn_notify(paging->mem_event.xce_handle,
-                           paging->mem_event.port);
+    ret = xc_mem_access_resume(paging->xc_handle, paging->vm_event.domain_id);
+    ret = xc_evtchn_notify(paging->vm_event.xce_handle,
+                           paging->vm_event.port);
 
  out:
     return ret;
@@ -400,8 +400,8 @@ int main(int argc, char *argv[])
     struct sigaction act;
     domid_t domain_id;
     xenaccess_t *xenaccess;
-    mem_event_request_t req;
-    mem_event_response_t rsp;
+    vm_event_request_t req;
+    vm_event_response_t rsp;
     int rc = -1;
     int rc1;
     xc_interface *xch;
@@ -507,7 +507,7 @@ int main(int argc, char *argv[])
         rc = xc_hvm_param_set(xch, domain_id, HVM_PARAM_MEMORY_EVENT_INT3, HVMPME_mode_disabled);
     if ( rc < 0 )
     {
-        ERROR("Error %d setting int3 mem_event\n", rc);
+        ERROR("Error %d setting int3 vm_event\n", rc);
         goto exit;
     }
 
@@ -527,7 +527,7 @@ int main(int argc, char *argv[])
             shutting_down = 1;
         }
 
-        rc = xc_wait_for_event_or_timeout(xch, xenaccess->mem_event.xce_handle, 100);
+        rc = xc_wait_for_event_or_timeout(xch, xenaccess->vm_event.xce_handle, 100);
         if ( rc < -1 )
         {
             ERROR("Error getting event");
@@ -539,11 +539,11 @@ int main(int argc, char *argv[])
             DPRINTF("Got event from Xen\n");
         }
 
-        while ( RING_HAS_UNCONSUMED_REQUESTS(&xenaccess->mem_event.back_ring) )
+        while ( RING_HAS_UNCONSUMED_REQUESTS(&xenaccess->vm_event.back_ring) )
         {
             xenmem_access_t access;
 
-            rc = get_request(&xenaccess->mem_event, &req);
+            rc = get_request(&xenaccess->vm_event, &req);
             if ( rc != 0 )
             {
                 ERROR("Error getting request");
@@ -556,7 +556,7 @@ int main(int argc, char *argv[])
             rsp.flags = req.flags;
 
             switch (req.reason) {
-            case MEM_EVENT_REASON_MEM_ACCESS_VIOLATION:
+            case VM_EVENT_REASON_MEM_ACCESS_VIOLATION:
                 rc = xc_get_mem_access(xch, domain_id, req.mem_access_event.gfn, &access);
                 if (rc < 0)
                 {
@@ -594,7 +594,7 @@ int main(int argc, char *argv[])
 
                 rsp.mem_access_event.gfn = req.mem_access_event.gfn;
                 break;
-            case MEM_EVENT_REASON_INT3:
+            case VM_EVENT_REASON_INT3:
                 printf("INT3: rip=%016"PRIx64", gfn=%"PRIx64" (vcpu %d)\n",
                        req.int3_event.gla,
                        req.int3_event.gfn,
diff --git a/tools/xenpaging/pagein.c b/tools/xenpaging/pagein.c
index b3bcef7..7cb0f33 100644
--- a/tools/xenpaging/pagein.c
+++ b/tools/xenpaging/pagein.c
@@ -63,7 +63,7 @@ void page_in_trigger(void)
 
 void create_page_in_thread(struct xenpaging *paging)
 {
-    page_in_args.dom = paging->mem_event.domain_id;
+    page_in_args.dom = paging->vm_event.domain_id;
     page_in_args.pagein_queue = paging->pagein_queue;
     page_in_args.xch = paging->xc_handle;
     if (pthread_create(&page_in_thread, NULL, page_in, &page_in_args) == 0)
diff --git a/tools/xenpaging/xenpaging.c b/tools/xenpaging/xenpaging.c
index 148b3e7..3031d1e 100644
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -63,7 +63,7 @@ static void close_handler(int sig)
 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;
+    domid_t domain_id = paging->vm_event.domain_id;
     char path[80];
 
     sprintf(path, "/local/domain/0/device-model/%u/command", domain_id);
@@ -74,7 +74,7 @@ static void xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
 static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
-    xc_evtchn *xce = paging->mem_event.xce_handle;
+    xc_evtchn *xce = paging->vm_event.xce_handle;
     char **vec, *val;
     unsigned int num;
     struct pollfd fd[2];
@@ -111,7 +111,7 @@ static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
             if ( strcmp(vec[XS_WATCH_TOKEN], watch_token) == 0 )
             {
                 /* If our guest disappeared, set interrupt flag and fall through */
-                if ( xs_is_domain_introduced(paging->xs_handle, paging->mem_event.domain_id) == false )
+                if ( xs_is_domain_introduced(paging->xs_handle, paging->vm_event.domain_id) == false )
                 {
                     xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
                     interrupted = SIGQUIT;
@@ -171,7 +171,7 @@ static int xenpaging_get_tot_pages(struct xenpaging *paging)
     xc_domaininfo_t domain_info;
     int rc;
 
-    rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1, &domain_info);
+    rc = xc_domain_getinfolist(xch, paging->vm_event.domain_id, 1, &domain_info);
     if ( rc != 1 )
     {
         PERROR("Error getting domain info");
@@ -231,7 +231,7 @@ static int xenpaging_getopts(struct xenpaging *paging, int argc, char *argv[])
     {
         switch(ch) {
         case 'd':
-            paging->mem_event.domain_id = atoi(optarg);
+            paging->vm_event.domain_id = atoi(optarg);
             break;
         case 'f':
             filename = strdup(optarg);
@@ -264,7 +264,7 @@ static int xenpaging_getopts(struct xenpaging *paging, int argc, char *argv[])
     }
 
     /* Set domain id */
-    if ( !paging->mem_event.domain_id )
+    if ( !paging->vm_event.domain_id )
     {
         printf("Numerical <domain_id> missing!\n");
         return 1;
@@ -312,7 +312,7 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
     }
 
     /* write domain ID to watch so we can ignore other domain shutdowns */
-    snprintf(watch_token, sizeof(watch_token), "%u", paging->mem_event.domain_id);
+    snprintf(watch_token, sizeof(watch_token), "%u", paging->vm_event.domain_id);
     if ( xs_watch(paging->xs_handle, "@releaseDomain", watch_token) == false )
     {
         PERROR("Could not bind to shutdown watch\n");
@@ -320,7 +320,7 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
     }
 
     /* Watch xenpagings working target */
-    dom_path = xs_get_domain_path(paging->xs_handle, paging->mem_event.domain_id);
+    dom_path = xs_get_domain_path(paging->xs_handle, paging->vm_event.domain_id);
     if ( !dom_path )
     {
         PERROR("Could not find domain path\n");
@@ -339,17 +339,17 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
     }
 
     /* Map the ring page */
-    xc_get_hvm_param(xch, paging->mem_event.domain_id, 
+    xc_get_hvm_param(xch, paging->vm_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, 
+    paging->vm_event.ring_page = 
+        xc_map_foreign_batch(xch, paging->vm_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(paging->xc_handle, 
-                                              paging->mem_event.domain_id,
+                                              paging->vm_event.domain_id,
                                               1, 0, 0, &ring_pfn);
         if ( rc != 0 )
         {
@@ -358,8 +358,8 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
         }
 
         mmap_pfn = ring_pfn;
-        paging->mem_event.ring_page = 
-            xc_map_foreign_batch(xch, paging->mem_event.domain_id, 
+        paging->vm_event.ring_page = 
+            xc_map_foreign_batch(xch, paging->vm_event.domain_id, 
                                     PROT_READ | PROT_WRITE, &mmap_pfn, 1);
         if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
         {
@@ -369,8 +369,8 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
     }
     
     /* Initialise Xen */
-    rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id,
-                             &paging->mem_event.evtchn_port);
+    rc = xc_mem_paging_enable(xch, paging->vm_event.domain_id,
+                             &paging->vm_event.evtchn_port);
     if ( rc != 0 )
     {
         switch ( errno ) {
@@ -394,40 +394,40 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
     }
 
     /* Open event channel */
-    paging->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
-    if ( paging->mem_event.xce_handle == NULL )
+    paging->vm_event.xce_handle = xc_evtchn_open(NULL, 0);
+    if ( paging->vm_event.xce_handle == NULL )
     {
         PERROR("Failed to open event channel");
         goto err;
     }
 
     /* Bind event notification */
-    rc = xc_evtchn_bind_interdomain(paging->mem_event.xce_handle,
-                                    paging->mem_event.domain_id,
-                                    paging->mem_event.evtchn_port);
+    rc = xc_evtchn_bind_interdomain(paging->vm_event.xce_handle,
+                                    paging->vm_event.domain_id,
+                                    paging->vm_event.evtchn_port);
     if ( rc < 0 )
     {
         PERROR("Failed to bind event channel");
         goto err;
     }
 
-    paging->mem_event.port = rc;
+    paging->vm_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,
+    SHARED_RING_INIT((vm_event_sring_t *)paging->vm_event.ring_page);
+    BACK_RING_INIT(&paging->vm_event.back_ring,
+                   (vm_event_sring_t *)paging->vm_event.ring_page,
                    PAGE_SIZE);
 
     /* Now that the ring is set, remove it from the guest's physmap */
     if ( xc_domain_decrease_reservation_exact(xch, 
-                    paging->mem_event.domain_id, 1, 0, &ring_pfn) )
+                    paging->vm_event.domain_id, 1, 0, &ring_pfn) )
         PERROR("Failed to remove ring from guest physmap");
 
     /* Get max_pages from guest if not provided via cmdline */
     if ( !paging->max_pages )
     {
-        rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1,
+        rc = xc_domain_getinfolist(xch, paging->vm_event.domain_id, 1,
                                    &domain_info);
         if ( rc != 1 )
         {
@@ -497,9 +497,9 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
             free(paging->paging_buffer);
         }
 
-        if ( paging->mem_event.ring_page )
+        if ( paging->vm_event.ring_page )
         {
-            munmap(paging->mem_event.ring_page, PAGE_SIZE);
+            munmap(paging->vm_event.ring_page, PAGE_SIZE);
         }
 
         free(dom_path);
@@ -524,28 +524,28 @@ static void xenpaging_teardown(struct xenpaging *paging)
 
     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);
+    munmap(paging->vm_event.ring_page, PAGE_SIZE);
+    rc = xc_mem_paging_disable(xch, paging->vm_event.domain_id);
     if ( rc != 0 )
     {
         PERROR("Error tearing down domain paging in xen");
     }
 
     /* Unbind VIRQ */
-    rc = xc_evtchn_unbind(paging->mem_event.xce_handle, paging->mem_event.port);
+    rc = xc_evtchn_unbind(paging->vm_event.xce_handle, paging->vm_event.port);
     if ( rc != 0 )
     {
         PERROR("Error unbinding event port");
     }
-    paging->mem_event.port = -1;
+    paging->vm_event.port = -1;
 
     /* Close event channel */
-    rc = xc_evtchn_close(paging->mem_event.xce_handle);
+    rc = xc_evtchn_close(paging->vm_event.xce_handle);
     if ( rc != 0 )
     {
         PERROR("Error closing event channel");
     }
-    paging->mem_event.xce_handle = NULL;
+    paging->vm_event.xce_handle = NULL;
     
     /* Close connection to xenstore */
     xs_close(paging->xs_handle);
@@ -558,12 +558,12 @@ static void xenpaging_teardown(struct xenpaging *paging)
     }
 }
 
-static void get_request(struct mem_event *mem_event, mem_event_request_t *req)
+static void get_request(struct vm_event *vm_event, vm_event_request_t *req)
 {
-    mem_event_back_ring_t *back_ring;
+    vm_event_back_ring_t *back_ring;
     RING_IDX req_cons;
 
-    back_ring = &mem_event->back_ring;
+    back_ring = &vm_event->back_ring;
     req_cons = back_ring->req_cons;
 
     /* Copy request */
@@ -575,12 +575,12 @@ static void get_request(struct mem_event *mem_event, mem_event_request_t *req)
     back_ring->sring->req_event = req_cons + 1;
 }
 
-static void put_response(struct mem_event *mem_event, mem_event_response_t *rsp)
+static void put_response(struct vm_event *vm_event, vm_event_response_t *rsp)
 {
-    mem_event_back_ring_t *back_ring;
+    vm_event_back_ring_t *back_ring;
     RING_IDX rsp_prod;
 
-    back_ring = &mem_event->back_ring;
+    back_ring = &vm_event->back_ring;
     rsp_prod = back_ring->rsp_prod_pvt;
 
     /* Copy response */
@@ -607,7 +607,7 @@ static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int
     DECLARE_DOMCTL;
 
     /* Nominate page */
-    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
+    ret = xc_mem_paging_nominate(xch, paging->vm_event.domain_id, gfn);
     if ( ret < 0 )
     {
         /* unpageable gfn is indicated by EBUSY */
@@ -619,7 +619,7 @@ static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int
     }
 
     /* Map page */
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
+    page = xc_map_foreign_pages(xch, paging->vm_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
         PERROR("Error mapping page %lx", gfn);
@@ -641,7 +641,7 @@ static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
-    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
+    ret = xc_mem_paging_evict(xch, paging->vm_event.domain_id, gfn);
     if ( ret < 0 )
     {
         /* A gfn in use is indicated by EBUSY */
@@ -671,10 +671,10 @@ static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int
     return ret;
 }
 
-static int xenpaging_resume_page(struct xenpaging *paging, mem_event_response_t *rsp, int notify_policy)
+static int xenpaging_resume_page(struct xenpaging *paging, vm_event_response_t *rsp, int notify_policy)
 {
     /* Put the page info on the ring */
-    put_response(&paging->mem_event, rsp);
+    put_response(&paging->vm_event, rsp);
 
     /* Notify policy of page being paged in */
     if ( notify_policy )
@@ -693,7 +693,7 @@ static int xenpaging_resume_page(struct xenpaging *paging, mem_event_response_t
     }
 
     /* Tell Xen page is ready */
-    return xc_evtchn_notify(paging->mem_event.xce_handle, paging->mem_event.port);
+    return xc_evtchn_notify(paging->vm_event.xce_handle, paging->vm_event.port);
 }
 
 static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int i)
@@ -715,7 +715,7 @@ static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn,
     do
     {
         /* Tell Xen to allocate a page for the domain */
-        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn, paging->paging_buffer);
+        ret = xc_mem_paging_load(xch, paging->vm_event.domain_id, gfn, paging->paging_buffer);
         if ( ret < 0 )
         {
             if ( errno == ENOMEM )
@@ -857,8 +857,8 @@ int main(int argc, char *argv[])
 {
     struct sigaction act;
     struct xenpaging *paging;
-    mem_event_request_t req;
-    mem_event_response_t rsp;
+    vm_event_request_t req;
+    vm_event_response_t rsp;
     int num, prev_num = 0;
     int slot;
     int tot_pages;
@@ -874,7 +874,7 @@ int main(int argc, char *argv[])
     }
     xch = paging->xc_handle;
 
-    DPRINTF("starting %s for domain_id %u with pagefile %s\n", argv[0], paging->mem_event.domain_id, filename);
+    DPRINTF("starting %s for domain_id %u with pagefile %s\n", argv[0], paging->vm_event.domain_id, filename);
 
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
@@ -903,12 +903,12 @@ int main(int argc, char *argv[])
             DPRINTF("Got event from Xen\n");
         }
 
-        while ( RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
+        while ( RING_HAS_UNCONSUMED_REQUESTS(&paging->vm_event.back_ring) )
         {
             /* Indicate possible error */
             rc = 1;
 
-            get_request(&paging->mem_event, &req);
+            get_request(&paging->vm_event, &req);
 
             if ( req.mem_paging_event.gfn > paging->max_pages )
             {
@@ -929,7 +929,7 @@ int main(int argc, char *argv[])
                     goto out;
                 }
 
-                if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
+                if ( req.flags & VM_EVENT_FLAG_DROP_PAGE )
                 {
                     DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.mem_paging_event.gfn, slot);
                     /* Notify policy of page being dropped */
@@ -966,13 +966,13 @@ int main(int argc, char *argv[])
             {
                 DPRINTF("page %s populated (domain = %d; vcpu = %d;"
                         " gfn = %"PRIx64"; paused = %d; evict_fail = %d)\n",
-                        req.flags & MEM_EVENT_FLAG_EVICT_FAIL ? "not" : "already",
-                        paging->mem_event.domain_id, req.vcpu_id, req.mem_paging_event.gfn,
-                        !!(req.flags & MEM_EVENT_FLAG_VCPU_PAUSED) ,
-                        !!(req.flags & MEM_EVENT_FLAG_EVICT_FAIL) );
+                        req.flags & VM_EVENT_FLAG_EVICT_FAIL ? "not" : "already",
+                        paging->vm_event.domain_id, req.vcpu_id, req.mem_paging_event.gfn,
+                        !!(req.flags & VM_EVENT_FLAG_VCPU_PAUSED) ,
+                        !!(req.flags & VM_EVENT_FLAG_EVICT_FAIL) );
 
                 /* Tell Xen to resume the vcpu */
-                if (( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) || ( req.flags & MEM_EVENT_FLAG_EVICT_FAIL ))
+                if (( req.flags & VM_EVENT_FLAG_VCPU_PAUSED ) || ( req.flags & VM_EVENT_FLAG_EVICT_FAIL ))
                 {
                     /* Prepare the response */
                     rsp.mem_paging_event.gfn = req.mem_paging_event.gfn;
diff --git a/tools/xenpaging/xenpaging.h b/tools/xenpaging/xenpaging.h
index 877db2f..25d511d 100644
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -27,15 +27,15 @@
 
 #include <xc_private.h>
 #include <xen/event_channel.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 
 #define XENPAGING_PAGEIN_QUEUE_SIZE 64
 
-struct mem_event {
+struct vm_event {
     domid_t domain_id;
     xc_evtchn *xce_handle;
     int port;
-    mem_event_back_ring_t back_ring;
+    vm_event_back_ring_t back_ring;
     uint32_t evtchn_port;
     void *ring_page;
 };
@@ -51,7 +51,7 @@ struct xenpaging {
 
     void *paging_buffer;
 
-    struct mem_event mem_event;
+    struct vm_event vm_event;
     int fd;
     /* number of pages for which data structures were allocated */
     int max_pages;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 73d01bb..7f30032 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -432,7 +432,7 @@ int vcpu_initialise(struct vcpu *v)
     v->arch.flags = TF_kernel_mode;
 
     /* By default, do not emulate */
-    v->arch.mem_event.emulate_flags = 0;
+    v->arch.vm_event.emulate_flags = 0;
 
     rc = mapcache_vcpu_init(v);
     if ( rc )
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 82365a4..3951ed3 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -30,8 +30,8 @@
 #include <xen/hypercall.h> /* for arch_do_domctl */
 #include <xsm/xsm.h>
 #include <xen/iommu.h>
-#include <xen/mem_event.h>
-#include <public/mem_event.h>
+#include <xen/vm_event.h>
+#include <public/vm_event.h>
 #include <asm/mem_sharing.h>
 #include <asm/xstate.h>
 #include <asm/debugger.h>
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 14c1847..218f6aa 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1401,7 +1401,7 @@ int hvm_emulate_one_no_write(
     return _hvm_emulate_one(hvmemul_ctxt, &hvm_emulate_ops_no_write);
 }
 
-void hvm_mem_event_emulate_one(bool_t nowrite, unsigned int trapnr,
+void hvm_mem_access_emulate_one(bool_t nowrite, unsigned int trapnr,
     unsigned int errcode)
 {
     struct hvm_emulate_ctxt ctx = {{ 0 }};
@@ -1418,7 +1418,7 @@ void hvm_mem_event_emulate_one(bool_t nowrite, unsigned int trapnr,
     {
     case X86EMUL_RETRY:
         /*
-         * This function is called when handling an EPT-related mem_event
+         * This function is called when handling an EPT-related vm_event
          * reply. As such, nothing else needs to be done here, since simply
          * returning makes the current instruction cause a page fault again,
          * consistent with X86EMUL_RETRY.
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 9140a2a..5d636e9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -35,7 +35,7 @@
 #include <xen/paging.h>
 #include <xen/cpu.h>
 #include <xen/wait.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/mem_access.h>
 #include <xen/rangeset.h>
 #include <asm/shadow.h>
@@ -66,7 +66,7 @@
 #include <public/hvm/ioreq.h>
 #include <public/version.h>
 #include <public/memory.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <public/arch-x86/cpuid.h>
 
 bool_t __read_mostly hvm_enabled;
@@ -2718,7 +2718,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
     struct p2m_domain *p2m;
     int rc, fall_through = 0, paged = 0;
     int sharing_enomem = 0;
-    mem_event_request_t *req_ptr = NULL;
+    vm_event_request_t *req_ptr = NULL;
 
     /* On Nested Virtualization, walk the guest page table.
      * If this succeeds, all is fine.
@@ -2788,7 +2788,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
     {
         bool_t violation;
 
-        /* If the access is against the permissions, then send to mem_event */
+        /* If the access is against the permissions, then send to vm_event */
         switch (p2ma)
         {
         case p2m_access_n:
@@ -6153,7 +6153,7 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
     return rc;
 }
 
-static void hvm_event_fill_regs(mem_event_request_t *req)
+static void hvm_event_fill_regs(vm_event_request_t *req)
 {
     const struct cpu_user_regs *regs = guest_cpu_user_regs();
     const struct vcpu *curr = current;
@@ -6185,7 +6185,7 @@ static void hvm_event_fill_regs(mem_event_request_t *req)
     req->x86_regs.cr4 = curr->arch.hvm_vcpu.guest_cr[4];
 }
 
-static int hvm_event_traps(long parameters, mem_event_request_t *req)
+static int hvm_event_traps(long parameters, vm_event_request_t *req)
 {
     int rc;
     struct vcpu *v = current;
@@ -6194,7 +6194,7 @@ static int hvm_event_traps(long parameters, mem_event_request_t *req)
     if ( !(parameters & HVMPME_MODE_MASK) )
         return 0;
 
-    rc = mem_event_claim_slot(d, &d->mem_event->monitor);
+    rc = vm_event_claim_slot(d, &d->vm_event->monitor);
     if ( rc == -ENOSYS )
     {
         /* If there was no ring to handle the event, then
@@ -6206,20 +6206,20 @@ static int hvm_event_traps(long parameters, mem_event_request_t *req)
 
     if ( (parameters & HVMPME_MODE_MASK) == HVMPME_mode_sync )
     {
-        req->flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-        mem_event_vcpu_pause(v);
+        req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
+        vm_event_vcpu_pause(v);
     }
 
     hvm_event_fill_regs(req);
-    mem_event_put_request(d, &d->mem_event->monitor, req);
+    vm_event_put_request(d, &d->vm_event->monitor, req);
 
     return 1;
 }
 
 void hvm_event_cr0(unsigned long value, unsigned long old)
 {
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_CR0,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_CR0,
         .vcpu_id = current->vcpu_id,
         .cr_event.new_value = value,
         .cr_event.old_value = old
@@ -6236,8 +6236,8 @@ void hvm_event_cr0(unsigned long value, unsigned long old)
 
 void hvm_event_cr3(unsigned long value, unsigned long old)
 {
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_CR3,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_CR3,
         .vcpu_id = current->vcpu_id,
         .cr_event.new_value = value,
         .cr_event.old_value = old
@@ -6254,8 +6254,8 @@ void hvm_event_cr3(unsigned long value, unsigned long old)
 
 void hvm_event_cr4(unsigned long value, unsigned long old)
 {
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_CR4,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_CR4,
         .vcpu_id = current->vcpu_id,
         .cr_event.new_value = value,
         .cr_event.old_value = old
@@ -6272,8 +6272,8 @@ void hvm_event_cr4(unsigned long value, unsigned long old)
 
 void hvm_event_msr(unsigned long msr, unsigned long value)
 {
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_MSR,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MSR,
         .vcpu_id = current->vcpu_id,
         .msr_event.msr = msr,
         .msr_event.new_value = value,
@@ -6287,8 +6287,8 @@ void hvm_event_msr(unsigned long msr, unsigned long value)
 int hvm_event_int3(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_INT3,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_INT3,
         .vcpu_id = current->vcpu_id,
         .int3_event.gla = gla,
         .int3_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
@@ -6302,8 +6302,8 @@ int hvm_event_int3(unsigned long gla)
 int hvm_event_single_step(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_SINGLESTEP,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_SINGLESTEP,
         .vcpu_id = current->vcpu_id,
         .singlestep_event.gla = gla,
         .singlestep_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index e553fb0..0f2b2e6 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -25,7 +25,7 @@
 #include <xen/event.h>
 #include <xen/kernel.h>
 #include <xen/keyhandler.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <asm/current.h>
 #include <asm/cpufeature.h>
 #include <asm/processor.h>
@@ -715,7 +715,7 @@ void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type)
         return;
 
     if ( unlikely(d->arch.hvm_domain.introspection_enabled) &&
-         mem_event_check_ring(&d->mem_event->monitor) )
+         vm_event_check_ring(&d->vm_event->monitor) )
     {
         unsigned int i;
 
diff --git a/xen/arch/x86/mm/hap/nested_ept.c b/xen/arch/x86/mm/hap/nested_ept.c
index cbbc4e9..40adac3 100644
--- a/xen/arch/x86/mm/hap/nested_ept.c
+++ b/xen/arch/x86/mm/hap/nested_ept.c
@@ -17,9 +17,9 @@
  * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
  * Place - Suite 330, Boston, MA 02111-1307 USA.
  */
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/event.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <asm/domain.h>
 #include <asm/page.h>
 #include <asm/paging.h>
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index 9c1ec11..cb28943 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -19,9 +19,9 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/event.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <asm/domain.h>
 #include <asm/page.h>
 #include <asm/paging.h>
diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index f28e65b..aaa72a9 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -22,12 +22,12 @@
 
 
 #include <asm/p2m.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 
 
 int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpc)
 {
-    if ( unlikely(!d->mem_event->paging.ring_page) )
+    if ( unlikely(!d->vm_event->paging.ring_page) )
         return -ENODEV;
 
     switch( mpc->op )
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index c15edcc..b17a0a9 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -28,7 +28,7 @@
 #include <xen/grant_table.h>
 #include <xen/sched.h>
 #include <xen/rcupdate.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <asm/page.h>
 #include <asm/string.h>
 #include <asm/p2m.h>
@@ -559,25 +559,25 @@ int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
 {
     struct vcpu *v = current;
     int rc;
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_MEM_SHARING,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MEM_SHARING,
         .mem_sharing_event.gfn = gfn
     };
 
-    if ( (rc = __mem_event_claim_slot(d, 
-                        &d->mem_event->share, allow_sleep)) < 0 )
+    if ( (rc = __vm_event_claim_slot(d, 
+                        &d->vm_event->share, allow_sleep)) < 0 )
         return rc;
 
     if ( v->domain == d )
     {
-        req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
-        mem_event_vcpu_pause(v);
+        req.flags = VM_EVENT_FLAG_VCPU_PAUSED;
+        vm_event_vcpu_pause(v);
     }
 
     req.mem_sharing_event.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_event->share, &req);
+    vm_event_put_request(d, &d->vm_event->share, &req);
 
     return 0;
 }
@@ -594,14 +594,14 @@ unsigned int mem_sharing_get_nr_shared_mfns(void)
 
 int mem_sharing_sharing_resume(struct domain *d)
 {
-    mem_event_response_t rsp;
+    vm_event_response_t rsp;
 
     /* Get all requests off the ring */
-    while ( mem_event_get_response(d, &d->mem_event->share, &rsp) )
+    while ( vm_event_get_response(d, &d->vm_event->share, &rsp) )
     {
         struct vcpu *v;
 
-        if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
+        if ( rsp.flags & VM_EVENT_FLAG_DUMMY )
             continue;
 
         /* Validate the vcpu_id in the response. */
@@ -611,8 +611,8 @@ int mem_sharing_sharing_resume(struct domain *d)
         v = d->vcpu[rsp.vcpu_id];
 
         /* Unpause domain/vcpu */
-        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-            mem_event_vcpu_unpause(v);
+        if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
+            vm_event_vcpu_unpause(v);
     }
 
     return 0;
@@ -1139,7 +1139,7 @@ err_out:
 
 /* 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
+ *  2. We notify a potential dom0 helper through a vm_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
diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 43f507c..0679f00 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -21,9 +21,9 @@
  */
 
 #include <xen/iommu.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/event.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <asm/domain.h>
 #include <asm/page.h>
 #include <asm/paging.h>
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index e48b63a..654384a 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -26,10 +26,10 @@
  */
 
 #include <xen/iommu.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/event.h>
 #include <xen/trace.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <asm/domain.h>
 #include <asm/page.h>
 #include <asm/paging.h>
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 5c15b14..c69bc36 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -25,9 +25,9 @@
  */
 
 #include <xen/iommu.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/event.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <asm/domain.h>
 #include <asm/page.h>
 #include <asm/paging.h>
@@ -1077,8 +1077,8 @@ int p2m_mem_paging_evict(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 = {
-        .reason = MEM_EVENT_REASON_MEM_PAGING,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MEM_PAGING,
         .mem_paging_event.gfn = gfn
     };
 
@@ -1086,21 +1086,21 @@ void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
      * correctness of the guest execution at this point.  If this is the only
      * page that happens to be paged-out, we'll be okay..  but it's likely the
      * guest will crash shortly anyways. */
-    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    int rc = vm_event_claim_slot(d, &d->vm_event->paging);
     if ( rc < 0 )
         return;
 
     /* Send release notification to pager */
-    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
+    req.flags = VM_EVENT_FLAG_DROP_PAGE;
 
     /* 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;
+        req.flags |= VM_EVENT_FLAG_EVICT_FAIL;
 
-    mem_event_put_request(d, &d->mem_event->paging, &req);
+    vm_event_put_request(d, &d->vm_event->paging, &req);
 }
 
 /**
@@ -1127,8 +1127,8 @@ void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_MEM_PAGING,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MEM_PAGING,
         .mem_paging_event.gfn = gfn
     };
     p2m_type_t p2mt;
@@ -1137,7 +1137,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* We're paging. There should be a ring */
-    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    int rc = vm_event_claim_slot(d, &d->vm_event->paging);
     if ( rc == -ENOSYS )
     {
         gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
@@ -1159,7 +1159,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
     {
         /* Evict will fail now, tag this request for pager */
         if ( p2mt == p2m_ram_paging_out )
-            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
+            req.flags |= VM_EVENT_FLAG_EVICT_FAIL;
 
         p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
     }
@@ -1168,14 +1168,14 @@ void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
     /* Pause domain if request came from guest and gfn has paging type */
     if ( p2m_is_paging(p2mt) && v->domain == d )
     {
-        mem_event_vcpu_pause(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+        vm_event_vcpu_pause(v);
+        req.flags |= VM_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);
+        vm_event_cancel_slot(d, &d->vm_event->paging);
         return;
     }
 
@@ -1183,7 +1183,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
     req.mem_paging_event.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_event->paging, &req);
+    vm_event_put_request(d, &d->vm_event->paging, &req);
 }
 
 /**
@@ -1292,17 +1292,17 @@ int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
 void p2m_mem_paging_resume(struct domain *d)
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    mem_event_response_t rsp;
+    vm_event_response_t rsp;
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
 
     /* Pull all responses off the ring */
-    while( mem_event_get_response(d, &d->mem_event->paging, &rsp) )
+    while( vm_event_get_response(d, &d->vm_event->paging, &rsp) )
     {
         struct vcpu *v;
 
-        if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
+        if ( rsp.flags & VM_EVENT_FLAG_DUMMY )
             continue;
 
         /* Validate the vcpu_id in the response. */
@@ -1312,7 +1312,7 @@ void p2m_mem_paging_resume(struct domain *d)
         v = d->vcpu[rsp.vcpu_id];
 
         /* Fix p2m entry if the page was not dropped */
-        if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
+        if ( !(rsp.flags & VM_EVENT_FLAG_DROP_PAGE) )
         {
             gfn_lock(p2m, rsp.gfn, 0);
             mfn = p2m->get_entry(p2m, rsp.mem_access_event.gfn, &p2mt, &a, 0, NULL);
@@ -1328,12 +1328,12 @@ void p2m_mem_paging_resume(struct domain *d)
             gfn_unlock(p2m, rsp.gfn, 0);
         }
         /* Unpause domain */
-        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-            mem_event_vcpu_unpause(v);
+        if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
+            vm_event_vcpu_unpause(v);
     }
 }
 
-static void p2m_mem_event_fill_regs(mem_event_request_t *req)
+static void p2m_vm_event_fill_regs(vm_event_request_t *req)
 {
     const struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct segment_register seg;
@@ -1388,10 +1388,10 @@ static void p2m_mem_event_fill_regs(mem_event_request_t *req)
     req->x86_regs.cs_arbytes = seg.attr.bytes;
 }
 
-void p2m_mem_event_emulate_check(struct vcpu *v, const mem_event_response_t *rsp)
+void p2m_mem_access_emulate_check(struct vcpu *v, const vm_event_response_t *rsp)
 {
     /* Mark vcpu for skipping one instruction upon rescheduling. */
-    if ( rsp->flags & MEM_EVENT_FLAG_EMULATE )
+    if ( rsp->flags & VM_EVENT_FLAG_EMULATE )
     {
         xenmem_access_t access;
         bool_t violation = 1;
@@ -1438,7 +1438,7 @@ void p2m_mem_event_emulate_check(struct vcpu *v, const mem_event_response_t *rsp
             }
         }
 
-        v->arch.mem_event.emulate_flags = violation ? rsp->flags : 0;
+        v->arch.vm_event.emulate_flags = violation ? rsp->flags : 0;
     }
 }
 
@@ -1453,7 +1453,7 @@ void p2m_setup_introspection(struct domain *d)
 
 bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
                             struct npfec npfec,
-                            mem_event_request_t **req_ptr)
+                            vm_event_request_t **req_ptr)
 {
     struct vcpu *v = current;
     unsigned long gfn = gpa >> PAGE_SHIFT;
@@ -1462,7 +1462,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
-    mem_event_request_t *req;
+    vm_event_request_t *req;
     int rc;
     unsigned long eip = guest_cpu_user_regs()->eip;
 
@@ -1489,13 +1489,13 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
     gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    if ( !mem_event_check_ring(&d->mem_event->monitor) || !req_ptr ) 
+    if ( !vm_event_check_ring(&d->vm_event->monitor) || !req_ptr ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
         {
             gdprintk(XENLOG_INFO, "Memory access permissions failure, "
-                                  "no mem_event listener VCPU %d, dom %d\n",
+                                  "no vm_event listener VCPU %d, dom %d\n",
                                   v->vcpu_id, d->domain_id);
             domain_crash(v->domain);
             return 0;
@@ -1518,40 +1518,40 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
         }
     }
 
-    /* The previous mem_event reply does not match the current state. */
-    if ( v->arch.mem_event.gpa != gpa || v->arch.mem_event.eip != eip )
+    /* The previous vm_event reply does not match the current state. */
+    if ( v->arch.vm_event.gpa != gpa || v->arch.vm_event.eip != eip )
     {
-        /* Don't emulate the current instruction, send a new mem_event. */
-        v->arch.mem_event.emulate_flags = 0;
+        /* Don't emulate the current instruction, send a new vm_event. */
+        v->arch.vm_event.emulate_flags = 0;
 
         /*
          * Make sure to mark the current state to match it again against
-         * the new mem_event about to be sent.
+         * the new vm_event about to be sent.
          */
-        v->arch.mem_event.gpa = gpa;
-        v->arch.mem_event.eip = eip;
+        v->arch.vm_event.gpa = gpa;
+        v->arch.vm_event.eip = eip;
     }
 
-    if ( v->arch.mem_event.emulate_flags )
+    if ( v->arch.vm_event.emulate_flags )
     {
-        hvm_mem_event_emulate_one((v->arch.mem_event.emulate_flags &
-                                   MEM_EVENT_FLAG_EMULATE_NOWRITE) != 0,
-                                  TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+        hvm_mem_access_emulate_one((v->arch.vm_event.emulate_flags &
+                                    VM_EVENT_FLAG_EMULATE_NOWRITE) != 0,
+                                   TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
 
-        v->arch.mem_event.emulate_flags = 0;
+        v->arch.vm_event.emulate_flags = 0;
         return 1;
     }
 
     *req_ptr = NULL;
-    req = xzalloc(mem_event_request_t);
+    req = xzalloc(vm_event_request_t);
     if ( req )
     {
         *req_ptr = req;
-        req->reason = MEM_EVENT_REASON_MEM_ACCESS_VIOLATION;
+        req->reason = VM_EVENT_REASON_MEM_ACCESS_VIOLATION;
 
         /* Pause the current VCPU */
         if ( p2ma != p2m_access_n2rwx )
-            req->flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+            req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
 
         /* Send request to mem event */
         req->mem_access_event.gfn = gfn;
@@ -1567,12 +1567,12 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
         req->mem_access_event.access_x = npfec.insn_fetch;
         req->vcpu_id = v->vcpu_id;
 
-        p2m_mem_event_fill_regs(req);
+        p2m_vm_event_fill_regs(req);
     }
 
     /* Pause the current VCPU */
     if ( p2ma != p2m_access_n2rwx )
-        mem_event_vcpu_pause(v);
+        vm_event_vcpu_pause(v);
 
     /* VCPU may be paused, return whether we promoted automatically */
     return (p2ma == p2m_access_n2rwx);
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index 229d1ea..62eaaf7 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -1,5 +1,5 @@
 #include <xen/event.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/mem_access.h>
 #include <xen/multicall.h>
 #include <compat/memory.h>
@@ -192,7 +192,7 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         xen_mem_paging_op_t mpo;
         if ( copy_from_guest(&mpo, arg, 1) )
             return -EFAULT;
-        rc = do_mem_event_op(op, mpo.domain, (void *) &mpo);
+        rc = do_vm_event_op(op, mpo.domain, (void *) &mpo);
         if ( !rc && __copy_to_guest(arg, &mpo, 1) )
             return -EFAULT;
         break;
@@ -205,7 +205,7 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             return -EFAULT;
         if ( mso.op == XENMEM_sharing_op_audit )
             return mem_sharing_audit(); 
-        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        rc = do_vm_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && __copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
         break;
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 33d5ec9..fcdfc05 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -26,7 +26,7 @@
 #include <xen/nodemask.h>
 #include <xen/guest_access.h>
 #include <xen/hypercall.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/mem_access.h>
 #include <asm/current.h>
 #include <asm/asm_defns.h>
@@ -989,7 +989,7 @@ long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         xen_mem_paging_op_t mpo;
         if ( copy_from_guest(&mpo, arg, 1) )
             return -EFAULT;
-        rc = do_mem_event_op(op, mpo.domain, (void *) &mpo);
+        rc = do_vm_event_op(op, mpo.domain, (void *) &mpo);
         if ( !rc && __copy_to_guest(arg, &mpo, 1) )
             return -EFAULT;
         break;
@@ -1002,7 +1002,7 @@ long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             return -EFAULT;
         if ( mso.op == XENMEM_sharing_op_audit )
             return mem_sharing_audit(); 
-        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        rc = do_vm_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && __copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
         break;
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 8391246..f1b73a3 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -54,7 +54,7 @@ obj-y += rbtree.o
 obj-y += lzo.o
 obj-$(HAS_PDX) += pdx.o
 obj-$(HAS_MEM_ACCESS) += mem_access.o
-obj-$(HAS_MEM_ACCESS) += mem_event.o
+obj-$(HAS_MEM_ACCESS) += vm_event.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo unlz4 earlycpio,$(n).init.o)
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 4a62c1d..ec896946 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -15,7 +15,7 @@
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/time.h>
 #include <xen/console.h>
 #include <xen/softirq.h>
@@ -343,8 +343,8 @@ struct domain *domain_create(
         poolid = 0;
 
         err = -ENOMEM;
-        d->mem_event = xzalloc(struct mem_event_per_domain);
-        if ( !d->mem_event )
+        d->vm_event = xzalloc(struct vm_event_per_domain);
+        if ( !d->vm_event )
             goto fail;
 
         d->pbuf = xzalloc_array(char, DOMAIN_PBUF_SIZE);
@@ -386,7 +386,7 @@ struct domain *domain_create(
     if ( hardware_domain == d )
         hardware_domain = old_hwdom;
     atomic_set(&d->refcnt, DOMAIN_DESTROYED);
-    xfree(d->mem_event);
+    xfree(d->vm_event);
     xfree(d->pbuf);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
@@ -628,7 +628,7 @@ int domain_kill(struct domain *d)
         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);
+        vm_event_cleanup(d);
         put_domain(d);
         send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
@@ -807,7 +807,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_xenoprof_pages(d);
 #endif
 
-    xfree(d->mem_event);
+    xfree(d->vm_event);
     xfree(d->pbuf);
 
     for ( i = d->max_vcpus - 1; i >= 0; i-- )
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d9c2635..2beb03c 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -24,7 +24,7 @@
 #include <xen/bitmap.h>
 #include <xen/paging.h>
 #include <xen/hypercall.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <asm/current.h>
 #include <asm/irq.h>
 #include <asm/page.h>
@@ -1113,8 +1113,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     }
     break;
 
-    case XEN_DOMCTL_mem_event_op:
-        ret = mem_event_domctl(d, &op->u.mem_event_op,
+    case XEN_DOMCTL_vm_event_op:
+        ret = vm_event_domctl(d, &op->u.vm_event_op,
                                guest_handle_cast(u_domctl, void));
         copyback = 1;
         break;
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index 0a4fe51..01e353d 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -24,21 +24,21 @@
 #include <xen/sched.h>
 #include <xen/guest_access.h>
 #include <xen/hypercall.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <public/memory.h>
 #include <asm/p2m.h>
 #include <xsm/xsm.h>
 
 void mem_access_resume(struct domain *d)
 {
-    mem_event_response_t rsp;
+    vm_event_response_t rsp;
 
     /* Pull all responses off the ring. */
-    while ( mem_event_get_response(d, &d->mem_event->monitor, &rsp) )
+    while ( vm_event_get_response(d, &d->vm_event->monitor, &rsp) )
     {
         struct vcpu *v;
 
-        if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
+        if ( rsp.flags & VM_EVENT_FLAG_DUMMY )
             continue;
 
         /* Validate the vcpu_id in the response. */
@@ -47,11 +47,11 @@ void mem_access_resume(struct domain *d)
 
         v = d->vcpu[rsp.vcpu_id];
 
-        p2m_mem_event_emulate_check(v, &rsp);
+        p2m_mem_access_emulate_check(v, &rsp);
 
         /* Unpause domain. */
-        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-            mem_event_vcpu_unpause(v);
+        if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
+            vm_event_vcpu_unpause(v);
     }
 }
 
@@ -73,12 +73,12 @@ int mem_access_memop(unsigned long cmd,
     if ( !p2m_mem_access_sanity_check(d) )
         goto out;
 
-    rc = xsm_mem_event_op(XSM_DM_PRIV, d, XENMEM_access_op);
+    rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_access_op);
     if ( rc )
         goto out;
 
     rc = -ENODEV;
-    if ( unlikely(!d->mem_event->monitor.ring_page) )
+    if ( unlikely(!d->vm_event->monitor.ring_page) )
         goto out;
 
     switch ( mao.op )
@@ -138,13 +138,13 @@ int mem_access_memop(unsigned long cmd,
     return rc;
 }
 
-int mem_access_send_req(struct domain *d, mem_event_request_t *req)
+int mem_access_send_req(struct domain *d, vm_event_request_t *req)
 {
-    int rc = mem_event_claim_slot(d, &d->mem_event->monitor);
+    int rc = vm_event_claim_slot(d, &d->vm_event->monitor);
     if ( rc < 0 )
         return rc;
 
-    mem_event_put_request(d, &d->mem_event->monitor, req);
+    vm_event_put_request(d, &d->vm_event->monitor, req);
 
     return 0;
 }
diff --git a/xen/common/mem_event.c b/xen/common/mem_event.c
deleted file mode 100644
index b99e7d5..0000000
--- a/xen/common/mem_event.c
+++ /dev/null
@@ -1,742 +0,0 @@
-/******************************************************************************
- * mem_event.c
- *
- * Memory event support.
- *
- * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-
-
-#include <xen/sched.h>
-#include <xen/event.h>
-#include <xen/wait.h>
-#include <xen/mem_event.h>
-#include <xen/mem_access.h>
-#include <asm/p2m.h>
-
-#ifdef HAS_MEM_PAGING
-#include <asm/mem_paging.h>
-#endif
-
-#ifdef HAS_MEM_SHARING
-#include <asm/mem_sharing.h>
-#endif
-
-#include <xsm/xsm.h>
-
-/* for public/io/ring.h macros */
-#define xen_mb()   mb()
-#define xen_rmb()  rmb()
-#define xen_wmb()  wmb()
-
-#define mem_event_ring_lock_init(_med)  spin_lock_init(&(_med)->ring_lock)
-#define mem_event_ring_lock(_med)       spin_lock(&(_med)->ring_lock)
-#define mem_event_ring_unlock(_med)     spin_unlock(&(_med)->ring_lock)
-
-static int mem_event_enable(
-    struct domain *d,
-    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;
-    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.
-     */
-    if ( med->ring_page )
-        return -EBUSY;
-
-    /* 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);
-
-    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;
-
-    /* Allocate event channel */
-    rc = alloc_unbound_xen_event_channel(d->vcpu[0],
-                                         current->domain->domain_id,
-                                         notification_fn);
-    if ( rc < 0 )
-        goto err;
-
-    med->xen_port = mec->port = rc;
-
-    /* Prepare ring buffer */
-    FRONT_RING_INIT(&med->front_ring,
-                    (mem_event_sring_t *)med->ring_page,
-                    PAGE_SIZE);
-
-    /* Save the pause flag for this particular ring. */
-    med->pause_flag = pause_flag;
-
-    /* Initialize the last-chance wait queue. */
-    init_waitqueue_head(&med->wq);
-
-    mem_event_ring_unlock(med);
-    return 0;
-
- err:
-    destroy_ring_for_helper(&med->ring_page,
-                            med->ring_pg_struct);
-    mem_event_ring_unlock(med);
-
-    return rc;
-}
-
-static unsigned int mem_event_ring_available(struct mem_event_domain *med)
-{
-    int avail_req = RING_FREE_REQUESTS(&med->front_ring);
-    avail_req -= med->target_producers;
-    avail_req -= med->foreign_producers;
-
-    BUG_ON(avail_req < 0);
-
-    return avail_req;
-}
-
-/*
- * mem_event_wake_blocked() will wakeup vcpus waiting for room in the
- * ring. These vCPUs were paused on their way out after placing an event,
- * but need to be resumed where the ring is capable of processing at least
- * one event from them.
- */
-static void mem_event_wake_blocked(struct domain *d, struct mem_event_domain *med)
-{
-    struct vcpu *v;
-    int online = d->max_vcpus;
-    unsigned int avail_req = mem_event_ring_available(med);
-
-    if ( avail_req == 0 || med->blocked == 0 )
-        return;
-
-    /*
-     * We ensure that we only have vCPUs online if there are enough free slots
-     * for their memory events to be processed.  This will ensure that no
-     * memory events are lost (due to the fact that certain types of events
-     * cannot be replayed, we need to ensure that there is space in the ring
-     * for when they are hit).
-     * See comment below in mem_event_put_request().
-     */
-    for_each_vcpu ( d, v )
-        if ( test_bit(med->pause_flag, &v->pause_flags) )
-            online--;
-
-    ASSERT(online == (d->max_vcpus - med->blocked));
-
-    /* We remember which vcpu last woke up to avoid scanning always linearly
-     * from zero and starving higher-numbered vcpus under high load */
-    if ( d->vcpu )
-    {
-        int i, j, k;
-
-        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
-        {
-            k = i % d->max_vcpus;
-            v = d->vcpu[k];
-            if ( !v )
-                continue;
-
-            if ( !(med->blocked) || online >= avail_req )
-               break;
-
-            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
-            {
-                vcpu_unpause(v);
-                online++;
-                med->blocked--;
-                med->last_vcpu_wake_up = k;
-            }
-        }
-    }
-}
-
-/*
- * In the event that a vCPU attempted to place an event in the ring and
- * was unable to do so, it is queued on a wait queue.  These are woken as
- * needed, and take precedence over the blocked vCPUs.
- */
-static void mem_event_wake_queued(struct domain *d, struct mem_event_domain *med)
-{
-    unsigned int avail_req = mem_event_ring_available(med);
-
-    if ( avail_req > 0 )
-        wake_up_nr(&med->wq, avail_req);
-}
-
-/*
- * mem_event_wake() will wakeup all vcpus waiting for the ring to
- * become available.  If we have queued vCPUs, they get top priority. We
- * are guaranteed that they will go through code paths that will eventually
- * call mem_event_wake() again, ensuring that any blocked vCPUs will get
- * unpaused once all the queued vCPUs have made it through.
- */
-void mem_event_wake(struct domain *d, struct mem_event_domain *med)
-{
-    if (!list_empty(&med->wq.list))
-        mem_event_wake_queued(d, med);
-    else
-        mem_event_wake_blocked(d, med);
-}
-
-static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
-{
-    if ( med->ring_page )
-    {
-        struct vcpu *v;
-
-        mem_event_ring_lock(med);
-
-        if ( !list_empty(&med->wq.list) )
-        {
-            mem_event_ring_unlock(med);
-            return -EBUSY;
-        }
-
-        /* Free domU's event channel and leave the other one unbound */
-        free_xen_event_channel(d->vcpu[0], med->xen_port);
-
-        /* Unblock all vCPUs */
-        for_each_vcpu ( d, v )
-        {
-            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
-            {
-                vcpu_unpause(v);
-                med->blocked--;
-            }
-        }
-
-        destroy_ring_for_helper(&med->ring_page,
-                                med->ring_pg_struct);
-        mem_event_ring_unlock(med);
-    }
-
-    return 0;
-}
-
-static inline void mem_event_release_slot(struct domain *d,
-                                          struct mem_event_domain *med)
-{
-    /* Update the accounting */
-    if ( current->domain == d )
-        med->target_producers--;
-    else
-        med->foreign_producers--;
-
-    /* Kick any waiters */
-    mem_event_wake(d, med);
-}
-
-/*
- * mem_event_mark_and_pause() tags vcpu and put it to sleep.
- * The vcpu will resume execution in mem_event_wake_waiters().
- */
-void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
-{
-    if ( !test_and_set_bit(med->pause_flag, &v->pause_flags) )
-    {
-        vcpu_pause_nosync(v);
-        med->blocked++;
-    }
-}
-
-/*
- * This must be preceded by a call to claim_slot(), and is guaranteed to
- * succeed.  As a side-effect however, the vCPU may be paused if the ring is
- * overly full and its continued execution would cause stalling and excessive
- * waiting.  The vCPU will be automatically unpaused when the ring clears.
- */
-void mem_event_put_request(struct domain *d,
-                           struct mem_event_domain *med,
-                           mem_event_request_t *req)
-{
-    mem_event_front_ring_t *front_ring;
-    int free_req;
-    unsigned int avail_req;
-    RING_IDX req_prod;
-
-    if ( current->domain != d )
-    {
-        req->flags |= MEM_EVENT_FLAG_FOREIGN;
-#ifndef NDEBUG
-        if ( !(req->flags & MEM_EVENT_FLAG_VCPU_PAUSED) )
-            gdprintk(XENLOG_G_WARNING, "d%dv%d was not paused.\n",
-                     d->domain_id, req->vcpu_id);
-#endif
-    }
-
-    mem_event_ring_lock(med);
-
-    /* Due to the reservations, this step must succeed. */
-    front_ring = &med->front_ring;
-    free_req = RING_FREE_REQUESTS(front_ring);
-    ASSERT(free_req > 0);
-
-    /* Copy request */
-    req_prod = front_ring->req_prod_pvt;
-    memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
-    req_prod++;
-
-    /* Update ring */
-    front_ring->req_prod_pvt = req_prod;
-    RING_PUSH_REQUESTS(front_ring);
-
-    /* We've actually *used* our reservation, so release the slot. */
-    mem_event_release_slot(d, med);
-
-    /* Give this vCPU a black eye if necessary, on the way out.
-     * See the comments above wake_blocked() for more information
-     * on how this mechanism works to avoid waiting. */
-    avail_req = mem_event_ring_available(med);
-    if( current->domain == d && avail_req < d->max_vcpus )
-        mem_event_mark_and_pause(current, med);
-
-    mem_event_ring_unlock(med);
-
-    notify_via_xen_event_channel(d, med->xen_port);
-}
-
-int mem_event_get_response(struct domain *d, struct mem_event_domain *med, mem_event_response_t *rsp)
-{
-    mem_event_front_ring_t *front_ring;
-    RING_IDX rsp_cons;
-
-    mem_event_ring_lock(med);
-
-    front_ring = &med->front_ring;
-    rsp_cons = front_ring->rsp_cons;
-
-    if ( !RING_HAS_UNCONSUMED_RESPONSES(front_ring) )
-    {
-        mem_event_ring_unlock(med);
-        return 0;
-    }
-
-    /* Copy response */
-    memcpy(rsp, RING_GET_RESPONSE(front_ring, rsp_cons), sizeof(*rsp));
-    rsp_cons++;
-
-    /* Update ring */
-    front_ring->rsp_cons = rsp_cons;
-    front_ring->sring->rsp_event = rsp_cons + 1;
-
-    /* Kick any waiters -- since we've just consumed an event,
-     * there may be additional space available in the ring. */
-    mem_event_wake(d, med);
-
-    mem_event_ring_unlock(med);
-
-    return 1;
-}
-
-void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med)
-{
-    mem_event_ring_lock(med);
-    mem_event_release_slot(d, med);
-    mem_event_ring_unlock(med);
-}
-
-static int mem_event_grab_slot(struct mem_event_domain *med, int foreign)
-{
-    unsigned int avail_req;
-
-    if ( !med->ring_page )
-        return -ENOSYS;
-
-    mem_event_ring_lock(med);
-
-    avail_req = mem_event_ring_available(med);
-    if ( avail_req == 0 )
-    {
-        mem_event_ring_unlock(med);
-        return -EBUSY;
-    }
-
-    if ( !foreign )
-        med->target_producers++;
-    else
-        med->foreign_producers++;
-
-    mem_event_ring_unlock(med);
-
-    return 0;
-}
-
-/* Simple try_grab wrapper for use in the wait_event() macro. */
-static int mem_event_wait_try_grab(struct mem_event_domain *med, int *rc)
-{
-    *rc = mem_event_grab_slot(med, 0);
-    return *rc;
-}
-
-/* Call mem_event_grab_slot() until the ring doesn't exist, or is available. */
-static int mem_event_wait_slot(struct mem_event_domain *med)
-{
-    int rc = -EBUSY;
-    wait_event(med->wq, mem_event_wait_try_grab(med, &rc) != -EBUSY);
-    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
- * use mem_event_wait_slot() to reserve a slot.  As long as there is a ring,
- * this function will always return 0 for a guest.  For a non-guest, we check
- * for space and return -EBUSY if the ring is not available.
- *
- * Return codes: -ENOSYS: the ring is not yet configured
- *               -EBUSY: the ring is busy
- *               0: a spot has been reserved
- *
- */
-int __mem_event_claim_slot(struct domain *d, struct mem_event_domain *med,
-                            bool_t allow_sleep)
-{
-    if ( (current->domain == d) && allow_sleep )
-        return mem_event_wait_slot(med);
-    else
-        return mem_event_grab_slot(med, (current->domain != d));
-}
-
-#ifdef HAS_MEM_PAGING
-/* Registered with Xen-bound event channel for incoming notifications. */
-static void mem_paging_notification(struct vcpu *v, unsigned int port)
-{
-    if ( likely(v->domain->mem_event->paging.ring_page != NULL) )
-        p2m_mem_paging_resume(v->domain);
-}
-#endif
-
-#ifdef HAS_MEM_ACCESS
-/* Registered with Xen-bound event channel for incoming notifications. */
-static void mem_access_notification(struct vcpu *v, unsigned int port)
-{
-    if ( likely(v->domain->mem_event->monitor.ring_page != NULL) )
-        mem_access_resume(v->domain);
-}
-#endif
-
-#ifdef HAS_MEM_SHARING
-/* 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);
-}
-#endif
-
-int do_mem_event_op(int op, uint32_t domain, void *arg)
-{
-    int ret;
-    struct domain *d;
-
-    ret = rcu_lock_live_remote_domain_by_id(domain, &d);
-    if ( ret )
-        return ret;
-
-    ret = xsm_mem_event_op(XSM_DM_PRIV, d, op);
-    if ( ret )
-        goto out;
-
-    switch (op)
-    {
-#ifdef HAS_MEM_PAGING
-        case XENMEM_paging_op:
-            ret = mem_paging_memop(d, (xen_mem_paging_op_t *) arg);
-            break;
-#endif
-#ifdef HAS_MEM_SHARING
-        case XENMEM_sharing_op:
-            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
-            break;
-#endif
-        default:
-            ret = -ENOSYS;
-    }
-
- out:
-    rcu_unlock_domain(d);
-    return ret;
-}
-
-/* Clean up on domain destruction */
-void mem_event_cleanup(struct domain *d)
-{
-#ifdef HAS_MEM_PAGING
-    if ( d->mem_event->paging.ring_page ) {
-        /* Destroying the wait queue head means waking up all
-         * queued vcpus. This will drain the list, allowing
-         * the disable routine to complete. It will also drop
-         * all domain refs the wait-queued vcpus are holding.
-         * Finally, because this code path involves previously
-         * pausing the domain (domain_kill), unpausing the
-         * vcpus causes no harm. */
-        destroy_waitqueue_head(&d->mem_event->paging.wq);
-        (void)mem_event_disable(d, &d->mem_event->paging);
-    }
-#endif
-#ifdef HAS_MEM_ACCESS
-    if ( d->mem_event->monitor.ring_page ) {
-        destroy_waitqueue_head(&d->mem_event->monitor.wq);
-        (void)mem_event_disable(d, &d->mem_event->monitor);
-    }
-#endif
-#ifdef HAS_MEM_SHARING
-    if ( d->mem_event->share.ring_page ) {
-        destroy_waitqueue_head(&d->mem_event->share.wq);
-        (void)mem_event_disable(d, &d->mem_event->share);
-    }
-#endif
-}
-
-int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
-{
-    int rc;
-
-    rc = xsm_mem_event_control(XSM_PRIV, d, mec->mode, mec->op);
-    if ( rc )
-        return rc;
-
-    if ( unlikely(d == current->domain) )
-    {
-        gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
-        return -EINVAL;
-    }
-
-    if ( unlikely(d->is_dying) )
-    {
-        gdprintk(XENLOG_INFO, "Ignoring memory event op on dying domain %u\n",
-                 d->domain_id);
-        return 0;
-    }
-
-    if ( unlikely(d->vcpu == NULL) || unlikely(d->vcpu[0] == NULL) )
-    {
-        gdprintk(XENLOG_INFO,
-                 "Memory event op on a domain (%u) with no vcpus\n",
-                 d->domain_id);
-        return -EINVAL;
-    }
-
-    rc = -ENOSYS;
-
-    switch ( mec->mode )
-    {
-#ifdef HAS_MEM_PAGING
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING:
-    {
-        struct mem_event_domain *med = &d->mem_event->paging;
-        rc = -EINVAL;
-
-        switch( mec->op )
-        {
-        case XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE:
-        {
-            struct p2m_domain *p2m = p2m_get_hostp2m(d);
-
-            rc = -EOPNOTSUPP;
-            /* pvh fixme: p2m_is_foreign types need addressing */
-            if ( is_pvh_vcpu(current) || is_pvh_domain(hardware_domain) )
-                break;
-
-            rc = -ENODEV;
-            /* Only HAP is supported */
-            if ( !hap_enabled(d) )
-                break;
-
-            /* No paging if iommu is used */
-            rc = -EMLINK;
-            if ( unlikely(need_iommu(d)) )
-                break;
-
-            rc = -EXDEV;
-            /* Disallow paging in a PoD guest */
-            if ( p2m->pod.entry_count )
-                break;
-
-            rc = mem_event_enable(d, mec, med, _VPF_mem_paging,
-                                    HVM_PARAM_PAGING_RING_PFN,
-                                    mem_paging_notification);
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE:
-        {
-            if ( med->ring_page )
-                rc = mem_event_disable(d, med);
-        }
-        break;
-
-        default:
-            rc = -ENOSYS;
-            break;
-        }
-    }
-    break;
-#endif
-
-#ifdef HAS_MEM_ACCESS
-    case XEN_DOMCTL_MEM_EVENT_OP_MONITOR:
-    {
-        struct mem_event_domain *med = &d->mem_event->monitor;
-        rc = -EINVAL;
-
-        switch( mec->op )
-        {
-        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE:
-        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION:
-        {
-            rc = -ENODEV;
-            if ( !p2m_mem_event_sanity_check(d) )
-                break;
-
-            rc = mem_event_enable(d, mec, med, _VPF_mem_access,
-                                    HVM_PARAM_MONITOR_RING_PFN,
-                                    mem_access_notification);
-
-            if ( mec->op == XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION
-                 && !rc )
-                p2m_setup_introspection(d);
-
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE:
-        {
-            if ( med->ring_page )
-            {
-                rc = mem_event_disable(d, med);
-                d->arch.hvm_domain.introspection_enabled = 0;
-            }
-        }
-        break;
-
-        default:
-            rc = -ENOSYS;
-            break;
-        }
-    }
-    break;
-#endif
-
-#ifdef HAS_MEM_SHARING
-    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 = -EOPNOTSUPP;
-            /* pvh fixme: p2m_is_foreign types need addressing */
-            if ( is_pvh_vcpu(current) || is_pvh_domain(hardware_domain) )
-                break;
-
-            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;
-#endif
-
-    default:
-        rc = -ENOSYS;
-    }
-
-    return rc;
-}
-
-void mem_event_vcpu_pause(struct vcpu *v)
-{
-    ASSERT(v == current);
-
-    atomic_inc(&v->mem_event_pause_count);
-    vcpu_pause_nosync(v);
-}
-
-void mem_event_vcpu_unpause(struct vcpu *v)
-{
-    int old, new, prev = v->mem_event_pause_count.counter;
-
-    /* All unpause requests as a result of toolstack responses.  Prevent
-     * underflow of the vcpu pause count. */
-    do
-    {
-        old = prev;
-        new = old - 1;
-
-        if ( new < 0 )
-        {
-            printk(XENLOG_G_WARNING
-                   "%pv mem_event: Too many unpause attempts\n", v);
-            return;
-        }
-
-        prev = cmpxchg(&v->mem_event_pause_count.counter, old, new);
-    } while ( prev != old );
-
-    vcpu_unpause(v);
-}
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
new file mode 100644
index 0000000..f81eae4
--- /dev/null
+++ b/xen/common/vm_event.c
@@ -0,0 +1,742 @@
+/******************************************************************************
+ * vm_event.c
+ *
+ * VM event support.
+ *
+ * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+
+#include <xen/sched.h>
+#include <xen/event.h>
+#include <xen/wait.h>
+#include <xen/vm_event.h>
+#include <xen/mem_access.h>
+#include <asm/p2m.h>
+
+#ifdef HAS_MEM_PAGING
+#include <asm/mem_paging.h>
+#endif
+
+#ifdef HAS_MEM_SHARING
+#include <asm/mem_sharing.h>
+#endif
+
+#include <xsm/xsm.h>
+
+/* for public/io/ring.h macros */
+#define xen_mb()   mb()
+#define xen_rmb()  rmb()
+#define xen_wmb()  wmb()
+
+#define vm_event_ring_lock_init(_ved)  spin_lock_init(&(_ved)->ring_lock)
+#define vm_event_ring_lock(_ved)       spin_lock(&(_ved)->ring_lock)
+#define vm_event_ring_unlock(_ved)     spin_unlock(&(_ved)->ring_lock)
+
+static int vm_event_enable(
+    struct domain *d,
+    xen_domctl_vm_event_op_t *vec,
+    struct vm_event_domain *ved,
+    int pause_flag,
+    int param,
+    xen_event_channel_notification_t notification_fn)
+{
+    int rc;
+    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.
+     */
+    if ( ved->ring_page )
+        return -EBUSY;
+
+    /* The parameter defaults to zero, and it should be
+     * set to something */
+    if ( ring_gfn == 0 )
+        return -ENOSYS;
+
+    vm_event_ring_lock_init(ved);
+    vm_event_ring_lock(ved);
+
+    rc = prepare_ring_for_helper(d, ring_gfn, &ved->ring_pg_struct,
+                                    &ved->ring_page);
+    if ( rc < 0 )
+        goto err;
+
+    /* Set the number of currently blocked vCPUs to 0. */
+    ved->blocked = 0;
+
+    /* Allocate event channel */
+    rc = alloc_unbound_xen_event_channel(d->vcpu[0],
+                                         current->domain->domain_id,
+                                         notification_fn);
+    if ( rc < 0 )
+        goto err;
+
+    ved->xen_port = vec->port = rc;
+
+    /* Prepare ring buffer */
+    FRONT_RING_INIT(&ved->front_ring,
+                    (vm_event_sring_t *)ved->ring_page,
+                    PAGE_SIZE);
+
+    /* Save the pause flag for this particular ring. */
+    ved->pause_flag = pause_flag;
+
+    /* Initialize the last-chance wait queue. */
+    init_waitqueue_head(&ved->wq);
+
+    vm_event_ring_unlock(ved);
+    return 0;
+
+ err:
+    destroy_ring_for_helper(&ved->ring_page,
+                            ved->ring_pg_struct);
+    vm_event_ring_unlock(ved);
+
+    return rc;
+}
+
+static unsigned int vm_event_ring_available(struct vm_event_domain *ved)
+{
+    int avail_req = RING_FREE_REQUESTS(&ved->front_ring);
+    avail_req -= ved->target_producers;
+    avail_req -= ved->foreign_producers;
+
+    BUG_ON(avail_req < 0);
+
+    return avail_req;
+}
+
+/*
+ * vm_event_wake_blocked() will wakeup vcpus waiting for room in the
+ * ring. These vCPUs were paused on their way out after placing an event,
+ * but need to be resumed where the ring is capable of processing at least
+ * one event from them.
+ */
+static void vm_event_wake_blocked(struct domain *d, struct vm_event_domain *ved)
+{
+    struct vcpu *v;
+    int online = d->max_vcpus;
+    unsigned int avail_req = vm_event_ring_available(ved);
+
+    if ( avail_req == 0 || ved->blocked == 0 )
+        return;
+
+    /*
+     * We ensure that we only have vCPUs online if there are enough free slots
+     * for their memory events to be processed.  This will ensure that no
+     * memory events are lost (due to the fact that certain types of events
+     * cannot be replayed, we need to ensure that there is space in the ring
+     * for when they are hit).
+     * See comment below in vm_event_put_request().
+     */
+    for_each_vcpu ( d, v )
+        if ( test_bit(ved->pause_flag, &v->pause_flags) )
+            online--;
+
+    ASSERT(online == (d->max_vcpus - ved->blocked));
+
+    /* We remember which vcpu last woke up to avoid scanning always linearly
+     * from zero and starving higher-numbered vcpus under high load */
+    if ( d->vcpu )
+    {
+        int i, j, k;
+
+        for (i = ved->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
+        {
+            k = i % d->max_vcpus;
+            v = d->vcpu[k];
+            if ( !v )
+                continue;
+
+            if ( !(ved->blocked) || online >= avail_req )
+               break;
+
+            if ( test_and_clear_bit(ved->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                online++;
+                ved->blocked--;
+                ved->last_vcpu_wake_up = k;
+            }
+        }
+    }
+}
+
+/*
+ * In the event that a vCPU attempted to place an event in the ring and
+ * was unable to do so, it is queued on a wait queue.  These are woken as
+ * needed, and take precedence over the blocked vCPUs.
+ */
+static void vm_event_wake_queued(struct domain *d, struct vm_event_domain *ved)
+{
+    unsigned int avail_req = vm_event_ring_available(ved);
+
+    if ( avail_req > 0 )
+        wake_up_nr(&ved->wq, avail_req);
+}
+
+/*
+ * vm_event_wake() will wakeup all vcpus waiting for the ring to
+ * become available.  If we have queued vCPUs, they get top priority. We
+ * are guaranteed that they will go through code paths that will eventually
+ * call vm_event_wake() again, ensuring that any blocked vCPUs will get
+ * unpaused once all the queued vCPUs have made it through.
+ */
+void vm_event_wake(struct domain *d, struct vm_event_domain *ved)
+{
+    if (!list_empty(&ved->wq.list))
+        vm_event_wake_queued(d, ved);
+    else
+        vm_event_wake_blocked(d, ved);
+}
+
+static int vm_event_disable(struct domain *d, struct vm_event_domain *ved)
+{
+    if ( ved->ring_page )
+    {
+        struct vcpu *v;
+
+        vm_event_ring_lock(ved);
+
+        if ( !list_empty(&ved->wq.list) )
+        {
+            vm_event_ring_unlock(ved);
+            return -EBUSY;
+        }
+
+        /* Free domU's event channel and leave the other one unbound */
+        free_xen_event_channel(d->vcpu[0], ved->xen_port);
+
+        /* Unblock all vCPUs */
+        for_each_vcpu ( d, v )
+        {
+            if ( test_and_clear_bit(ved->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                ved->blocked--;
+            }
+        }
+
+        destroy_ring_for_helper(&ved->ring_page,
+                                ved->ring_pg_struct);
+        vm_event_ring_unlock(ved);
+    }
+
+    return 0;
+}
+
+static inline void vm_event_release_slot(struct domain *d,
+                                          struct vm_event_domain *ved)
+{
+    /* Update the accounting */
+    if ( current->domain == d )
+        ved->target_producers--;
+    else
+        ved->foreign_producers--;
+
+    /* Kick any waiters */
+    vm_event_wake(d, ved);
+}
+
+/*
+ * vm_event_mark_and_pause() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in vm_event_wake_waiters().
+ */
+void vm_event_mark_and_pause(struct vcpu *v, struct vm_event_domain *ved)
+{
+    if ( !test_and_set_bit(ved->pause_flag, &v->pause_flags) )
+    {
+        vcpu_pause_nosync(v);
+        ved->blocked++;
+    }
+}
+
+/*
+ * This must be preceded by a call to claim_slot(), and is guaranteed to
+ * succeed.  As a side-effect however, the vCPU may be paused if the ring is
+ * overly full and its continued execution would cause stalling and excessive
+ * waiting.  The vCPU will be automatically unpaused when the ring clears.
+ */
+void vm_event_put_request(struct domain *d,
+                           struct vm_event_domain *ved,
+                           vm_event_request_t *req)
+{
+    vm_event_front_ring_t *front_ring;
+    int free_req;
+    unsigned int avail_req;
+    RING_IDX req_prod;
+
+    if ( current->domain != d )
+    {
+        req->flags |= VM_EVENT_FLAG_FOREIGN;
+#ifndef NDEBUG
+        if ( !(req->flags & VM_EVENT_FLAG_VCPU_PAUSED) )
+            gdprintk(XENLOG_G_WARNING, "d%dv%d was not paused.\n",
+                     d->domain_id, req->vcpu_id);
+#endif
+    }
+
+    vm_event_ring_lock(ved);
+
+    /* Due to the reservations, this step must succeed. */
+    front_ring = &ved->front_ring;
+    free_req = RING_FREE_REQUESTS(front_ring);
+    ASSERT(free_req > 0);
+
+    /* Copy request */
+    req_prod = front_ring->req_prod_pvt;
+    memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
+    req_prod++;
+
+    /* Update ring */
+    front_ring->req_prod_pvt = req_prod;
+    RING_PUSH_REQUESTS(front_ring);
+
+    /* We've actually *used* our reservation, so release the slot. */
+    vm_event_release_slot(d, ved);
+
+    /* Give this vCPU a black eye if necessary, on the way out.
+     * See the comments above wake_blocked() for more information
+     * on how this vechanism works to avoid waiting. */
+    avail_req = vm_event_ring_available(ved);
+    if( current->domain == d && avail_req < d->max_vcpus )
+        vm_event_mark_and_pause(current, ved);
+
+    vm_event_ring_unlock(ved);
+
+    notify_via_xen_event_channel(d, ved->xen_port);
+}
+
+int vm_event_get_response(struct domain *d, struct vm_event_domain *ved, vm_event_response_t *rsp)
+{
+    vm_event_front_ring_t *front_ring;
+    RING_IDX rsp_cons;
+
+    vm_event_ring_lock(ved);
+
+    front_ring = &ved->front_ring;
+    rsp_cons = front_ring->rsp_cons;
+
+    if ( !RING_HAS_UNCONSUMED_RESPONSES(front_ring) )
+    {
+        vm_event_ring_unlock(ved);
+        return 0;
+    }
+
+    /* Copy response */
+    memcpy(rsp, RING_GET_RESPONSE(front_ring, rsp_cons), sizeof(*rsp));
+    rsp_cons++;
+
+    /* Update ring */
+    front_ring->rsp_cons = rsp_cons;
+    front_ring->sring->rsp_event = rsp_cons + 1;
+
+    /* Kick any waiters -- since we've just consumed an event,
+     * there may be additional space available in the ring. */
+    vm_event_wake(d, ved);
+
+    vm_event_ring_unlock(ved);
+
+    return 1;
+}
+
+void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved)
+{
+    vm_event_ring_lock(ved);
+    vm_event_release_slot(d, ved);
+    vm_event_ring_unlock(ved);
+}
+
+static int vm_event_grab_slot(struct vm_event_domain *ved, int foreign)
+{
+    unsigned int avail_req;
+
+    if ( !ved->ring_page )
+        return -ENOSYS;
+
+    vm_event_ring_lock(ved);
+
+    avail_req = vm_event_ring_available(ved);
+    if ( avail_req == 0 )
+    {
+        vm_event_ring_unlock(ved);
+        return -EBUSY;
+    }
+
+    if ( !foreign )
+        ved->target_producers++;
+    else
+        ved->foreign_producers++;
+
+    vm_event_ring_unlock(ved);
+
+    return 0;
+}
+
+/* Simple try_grab wrapper for use in the wait_event() macro. */
+static int vm_event_wait_try_grab(struct vm_event_domain *ved, int *rc)
+{
+    *rc = vm_event_grab_slot(ved, 0);
+    return *rc;
+}
+
+/* Call vm_event_grab_slot() until the ring doesn't exist, or is available. */
+static int vm_event_wait_slot(struct vm_event_domain *ved)
+{
+    int rc = -EBUSY;
+    wait_event(ved->wq, vm_event_wait_try_grab(ved, &rc) != -EBUSY);
+    return rc;
+}
+
+bool_t vm_event_check_ring(struct vm_event_domain *ved)
+{
+    return (ved->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
+ * use vm_event_wait_slot() to reserve a slot.  As long as there is a ring,
+ * this function will always return 0 for a guest.  For a non-guest, we check
+ * for space and return -EBUSY if the ring is not available.
+ *
+ * Return codes: -ENOSYS: the ring is not yet configured
+ *               -EBUSY: the ring is busy
+ *               0: a spot has been reserved
+ *
+ */
+int __vm_event_claim_slot(struct domain *d, struct vm_event_domain *ved,
+                            bool_t allow_sleep)
+{
+    if ( (current->domain == d) && allow_sleep )
+        return vm_event_wait_slot(ved);
+    else
+        return vm_event_grab_slot(ved, (current->domain != d));
+}
+
+#ifdef HAS_MEM_PAGING
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_paging_notification(struct vcpu *v, unsigned int port)
+{
+    if ( likely(v->domain->vm_event->paging.ring_page != NULL) )
+        p2m_mem_paging_resume(v->domain);
+}
+#endif
+
+#ifdef HAS_MEM_ACCESS
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_access_notification(struct vcpu *v, unsigned int port)
+{
+    if ( likely(v->domain->vm_event->monitor.ring_page != NULL) )
+        mem_access_resume(v->domain);
+}
+#endif
+
+#ifdef HAS_MEM_SHARING
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_sharing_notification(struct vcpu *v, unsigned int port)
+{
+    if ( likely(v->domain->vm_event->share.ring_page != NULL) )
+        mem_sharing_sharing_resume(v->domain);
+}
+#endif
+
+int do_vm_event_op(int op, uint32_t domain, void *arg)
+{
+    int ret;
+    struct domain *d;
+
+    ret = rcu_lock_live_remote_domain_by_id(domain, &d);
+    if ( ret )
+        return ret;
+
+    ret = xsm_vm_event_op(XSM_DM_PRIV, d, op);
+    if ( ret )
+        goto out;
+
+    switch (op)
+    {
+#ifdef HAS_MEM_PAGING
+        case XENMEM_paging_op:
+            ret = mem_paging_memop(d, (xen_mem_paging_op_t *) arg);
+            break;
+#endif
+#ifdef HAS_MEM_SHARING
+        case XENMEM_sharing_op:
+            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
+            break;
+#endif
+        default:
+            ret = -ENOSYS;
+    }
+
+ out:
+    rcu_unlock_domain(d);
+    return ret;
+}
+
+/* Clean up on domain destruction */
+void vm_event_cleanup(struct domain *d)
+{
+#ifdef HAS_MEM_PAGING
+    if ( d->vm_event->paging.ring_page ) {
+        /* Destroying the wait queue head means waking up all
+         * queued vcpus. This will drain the list, allowing
+         * the disable routine to complete. It will also drop
+         * all domain refs the wait-queued vcpus are holding.
+         * Finally, because this code path involves previously
+         * pausing the domain (domain_kill), unpausing the
+         * vcpus causes no harm. */
+        destroy_waitqueue_head(&d->vm_event->paging.wq);
+        (void)vm_event_disable(d, &d->vm_event->paging);
+    }
+#endif
+#ifdef HAS_MEM_ACCESS
+    if ( d->vm_event->monitor.ring_page ) {
+        destroy_waitqueue_head(&d->vm_event->monitor.wq);
+        (void)vm_event_disable(d, &d->vm_event->monitor);
+    }
+#endif
+#ifdef HAS_MEM_SHARING
+    if ( d->vm_event->share.ring_page ) {
+        destroy_waitqueue_head(&d->vm_event->share.wq);
+        (void)vm_event_disable(d, &d->vm_event->share);
+    }
+#endif
+}
+
+int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *vec,
+                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
+{
+    int rc;
+
+    rc = xsm_vm_event_control(XSM_PRIV, d, vec->mode, vec->op);
+    if ( rc )
+        return rc;
+
+    if ( unlikely(d == current->domain) )
+    {
+        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 event op on dying domain %u\n",
+                 d->domain_id);
+        return 0;
+    }
+
+    if ( unlikely(d->vcpu == NULL) || unlikely(d->vcpu[0] == NULL) )
+    {
+        gdprintk(XENLOG_INFO,
+                 "Memory event op on a domain (%u) with no vcpus\n",
+                 d->domain_id);
+        return -EINVAL;
+    }
+
+    rc = -ENOSYS;
+
+    switch ( vec->mode )
+    {
+#ifdef HAS_MEM_PAGING
+    case XEN_DOMCTL_VM_EVENT_OP_PAGING:
+    {
+        struct vm_event_domain *ved = &d->vm_event->paging;
+        rc = -EINVAL;
+
+        switch( vec->op )
+        {
+        case XEN_DOMCTL_VM_EVENT_OP_PAGING_ENABLE:
+        {
+            struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+            rc = -EOPNOTSUPP;
+            /* pvh fixme: p2m_is_foreign types need addressing */
+            if ( is_pvh_vcpu(current) || is_pvh_domain(hardware_domain) )
+                break;
+
+            rc = -ENODEV;
+            /* Only HAP is supported */
+            if ( !hap_enabled(d) )
+                break;
+
+            /* No paging if iommu is used */
+            rc = -EMLINK;
+            if ( unlikely(need_iommu(d)) )
+                break;
+
+            rc = -EXDEV;
+            /* Disallow paging in a PoD guest */
+            if ( p2m->pod.entry_count )
+                break;
+
+            rc = vm_event_enable(d, vec, ved, _VPF_mem_paging,
+                                    HVM_PARAM_PAGING_RING_PFN,
+                                    mem_paging_notification);
+        }
+        break;
+
+        case XEN_DOMCTL_VM_EVENT_OP_PAGING_DISABLE:
+        {
+            if ( ved->ring_page )
+                rc = vm_event_disable(d, ved);
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+            break;
+        }
+    }
+    break;
+#endif
+
+#ifdef HAS_MEM_ACCESS
+    case XEN_DOMCTL_VM_EVENT_OP_MONITOR:
+    {
+        struct vm_event_domain *ved = &d->vm_event->monitor;
+        rc = -EINVAL;
+
+        switch( vec->op )
+        {
+        case XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE:
+        case XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION:
+        {
+            rc = -ENODEV;
+            if ( !p2m_mem_access_sanity_check(d) )
+                break;
+
+            rc = vm_event_enable(d, vec, ved, _VPF_mem_access,
+                                    HVM_PARAM_MONITOR_RING_PFN,
+                                    mem_access_notification);
+
+            if ( vec->op == XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION
+                 && !rc )
+                p2m_setup_introspection(d);
+
+        }
+        break;
+
+        case XEN_DOMCTL_VM_EVENT_OP_MONITOR_DISABLE:
+        {
+            if ( ved->ring_page )
+            {
+                rc = vm_event_disable(d, ved);
+                d->arch.hvm_domain.introspection_enabled = 0;
+            }
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+            break;
+        }
+    }
+    break;
+#endif
+
+#ifdef HAS_MEM_SHARING
+    case XEN_DOMCTL_VM_EVENT_OP_SHARING:
+    {
+        struct vm_event_domain *ved = &d->vm_event->share;
+        rc = -EINVAL;
+
+        switch( vec->op )
+        {
+        case XEN_DOMCTL_VM_EVENT_OP_SHARING_ENABLE:
+        {
+            rc = -EOPNOTSUPP;
+            /* pvh fixme: p2m_is_foreign types need addressing */
+            if ( is_pvh_vcpu(current) || is_pvh_domain(hardware_domain) )
+                break;
+
+            rc = -ENODEV;
+            /* Only HAP is supported */
+            if ( !hap_enabled(d) )
+                break;
+
+            rc = vm_event_enable(d, vec, ved, _VPF_mem_sharing,
+                                    HVM_PARAM_SHARING_RING_PFN,
+                                    mem_sharing_notification);
+        }
+        break;
+
+        case XEN_DOMCTL_VM_EVENT_OP_SHARING_DISABLE:
+        {
+            if ( ved->ring_page )
+                rc = vm_event_disable(d, ved);
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+            break;
+        }
+    }
+    break;
+#endif
+
+    default:
+        rc = -ENOSYS;
+    }
+
+    return rc;
+}
+
+void vm_event_vcpu_pause(struct vcpu *v)
+{
+    ASSERT(v == current);
+
+    atomic_inc(&v->vm_event_pause_count);
+    vcpu_pause_nosync(v);
+}
+
+void vm_event_vcpu_unpause(struct vcpu *v)
+{
+    int old, new, prev = v->vm_event_pause_count.counter;
+
+    /* All unpause requests as a result of toolstack responses.  Prevent
+     * underflow of the vcpu pause count. */
+    do
+    {
+        old = prev;
+        new = old - 1;
+
+        if ( new < 0 )
+        {
+            printk(XENLOG_G_WARNING
+                   "%pv vm_event: Too many unpause attempts\n", v);
+            return;
+        }
+
+        prev = cmpxchg(&v->vm_event_pause_count.counter, old, new);
+    } while ( prev != old );
+
+    vcpu_unpause(v);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..964384b 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1346,7 +1346,7 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
      * enabled for this domain */
     if ( unlikely(!need_iommu(d) &&
             (d->arch.hvm_domain.mem_sharing_enabled ||
-             d->mem_event->paging.ring_page ||
+             d->vm_event->paging.ring_page ||
              p2m_get_hostp2m(d)->global_logdirty)) )
         return -EXDEV;
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index da36504..e1a72d5 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -45,7 +45,7 @@ struct p2m_domain {
         unsigned long shattered[4];
     } stats;
 
-    /* If true, and an access fault comes in and there is no mem_event listener,
+    /* If true, and an access fault comes in and there is no vm_event listener,
      * pause domain. Otherwise, remove access restrictions. */
     bool_t access_required;
 };
@@ -71,8 +71,8 @@ typedef enum {
 } p2m_type_t;
 
 static inline
-void p2m_mem_event_emulate_check(struct vcpu *v,
-                                 const mem_event_response_t *rsp)
+void p2m_mem_access_emulate_check(struct vcpu *v,
+                                  const vm_event_response_t *rsp)
 {
     /* Not supported on ARM. */
 };
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 6a77a93..20ede1e 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -478,13 +478,13 @@ struct arch_vcpu
 
     /*
      * Should we emulate the next matching instruction on VCPU resume
-     * after a mem_event?
+     * after a vm_event?
      */
     struct {
         uint32_t emulate_flags;
         unsigned long gpa;
         unsigned long eip;
-    } mem_event;
+    } vm_event;
 
 } __cacheline_aligned;
 
diff --git a/xen/include/asm-x86/hvm/emulate.h b/xen/include/asm-x86/hvm/emulate.h
index 5411302..b3971c8 100644
--- a/xen/include/asm-x86/hvm/emulate.h
+++ b/xen/include/asm-x86/hvm/emulate.h
@@ -38,7 +38,7 @@ int hvm_emulate_one(
     struct hvm_emulate_ctxt *hvmemul_ctxt);
 int hvm_emulate_one_no_write(
     struct hvm_emulate_ctxt *hvmemul_ctxt);
-void hvm_mem_event_emulate_one(bool_t nowrite,
+void hvm_mem_access_emulate_one(bool_t nowrite,
     unsigned int trapnr,
     unsigned int errcode);
 void hvm_emulate_prepare(
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..2ee863b 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -238,7 +238,7 @@ struct p2m_domain {
      * retyped get this access type.  See definition of p2m_access_t. */
     p2m_access_t default_access;
 
-    /* If true, and an access fault comes in and there is no mem_event listener, 
+    /* If true, and an access fault comes in and there is no vm_event listener, 
      * pause domain.  Otherwise, remove access restrictions. */
     bool_t       access_required;
 
@@ -572,7 +572,7 @@ void p2m_mem_paging_resume(struct domain *d);
  * locks -- caller must also xfree the request. */
 bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
                             struct npfec npfec,
-                            mem_event_request_t **req_ptr);
+                            vm_event_request_t **req_ptr);
 
 /* Set access type for a region of pfns.
  * If start_pfn == -1ul, sets the default access type */
@@ -586,22 +586,16 @@ int p2m_get_mem_access(struct domain *d, unsigned long pfn,
 
 /* Check for emulation and mark vcpu for skipping one instruction
  * upon rescheduling if required. */
-void p2m_mem_event_emulate_check(struct vcpu *v,
-                                 const mem_event_response_t *rsp);
+void p2m_mem_access_emulate_check(struct vcpu *v,
+                                 const vm_event_response_t *rsp);
 
 /* Enable arch specific introspection options (such as MSR interception). */
 void p2m_setup_introspection(struct domain *d);
 
-/* Sanity check for mem_event hardware support */
-static inline bool_t p2m_mem_event_sanity_check(struct domain *d)
-{
-    return hap_enabled(d) && cpu_has_vmx;
-}
-
 /* Sanity check for mem_access hardware support */
 static inline bool_t p2m_mem_access_sanity_check(struct domain *d)
 {
-    return is_hvm_domain(d);
+    return hap_enabled(d) && cpu_has_vmx && is_hvm_domain(d);
 }
 
 /* 
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 9d2cc38..1d8bbf0 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -753,7 +753,7 @@ struct xen_domctl_gdbsx_domstatus {
  * Memory event operations
  */
 
-/* XEN_DOMCTL_mem_event_op */
+/* XEN_DOMCTL_vm_event_op */
 
 /*
  * Domain memory paging
@@ -762,17 +762,17 @@ struct xen_domctl_gdbsx_domstatus {
  * pager<->hypervisor interface. Use XENMEM_paging_op*
  * to perform per-page operations.
  *
- * The XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE domctl returns several
+ * The XEN_DOMCTL_VM_EVENT_OP_PAGING_ENABLE domctl returns several
  * non-standard error codes to indicate why paging could not be enabled:
  * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
  * EMLINK - guest has iommu passthrough enabled
  * EXDEV  - guest has PoD enabled
  * EBUSY  - guest has or had paging enabled, ring buffer still active
  */
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
+#define XEN_DOMCTL_VM_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_VM_EVENT_OP_PAGING_ENABLE     0
+#define XEN_DOMCTL_VM_EVENT_OP_PAGING_DISABLE    1
 
 /*
  * Monitor permissions.
@@ -783,21 +783,21 @@ struct xen_domctl_gdbsx_domstatus {
  * 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) .
+ * is sent with what happened.  (See public/vm_event.h) .
  *
  * The memory event handler can then resume the VCPU and redo the access 
  * with a XENMEM_access_op_resume hypercall.
  *
- * The XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE domctl returns several
+ * The XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE domctl returns several
  * non-standard error codes to indicate why access could not be enabled:
  * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
  * EBUSY  - guest has or had access enabled, ring buffer still active
  */
-#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR                        2
+#define XEN_DOMCTL_VM_EVENT_OP_MONITOR                        2
 
-#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE                 0
-#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE                1
-#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION   2
+#define XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE                 0
+#define XEN_DOMCTL_VM_EVENT_OP_MONITOR_DISABLE                1
+#define XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION   2
 
 /*
  * Sharing ENOMEM helper.
@@ -812,21 +812,21 @@ struct xen_domctl_gdbsx_domstatus {
  * 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_VM_EVENT_OP_SHARING           3
 
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE    0
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DISABLE   1
+#define XEN_DOMCTL_VM_EVENT_OP_SHARING_ENABLE    0
+#define XEN_DOMCTL_VM_EVENT_OP_SHARING_DISABLE   1
 
 /* 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_* */
+struct xen_domctl_vm_event_op {
+    uint32_t       op;           /* XEN_DOMCTL_VM_EVENT_OP_*_* */
+    uint32_t       mode;         /* XEN_DOMCTL_VM_EVENT_OP_* */
 
     uint32_t port;              /* OUT: event channel for ring */
 };
-typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
-DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
+typedef struct xen_domctl_vm_event_op xen_domctl_vm_event_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_vm_event_op_t);
 
 /*
  * Memory sharing operations
@@ -1049,7 +1049,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_suppress_spurious_page_faults 53
 #define XEN_DOMCTL_debug_op                      54
 #define XEN_DOMCTL_gethvmcontext_partial         55
-#define XEN_DOMCTL_mem_event_op                  56
+#define XEN_DOMCTL_vm_event_op                   56
 #define XEN_DOMCTL_mem_sharing_op                57
 #define XEN_DOMCTL_disable_migrate               58
 #define XEN_DOMCTL_gettscinfo                    59
@@ -1117,7 +1117,7 @@ struct xen_domctl {
         struct xen_domctl_set_target        set_target;
         struct xen_domctl_subscribe         subscribe;
         struct xen_domctl_debug_op          debug_op;
-        struct xen_domctl_mem_event_op      mem_event_op;
+        struct xen_domctl_vm_event_op       vm_event_op;
         struct xen_domctl_mem_sharing_op    mem_sharing_op;
 #if defined(__i386__) || defined(__x86_64__)
         struct xen_domctl_cpuid             cpuid;
diff --git a/xen/include/public/mem_event.h b/xen/include/public/mem_event.h
deleted file mode 100644
index c0e9394..0000000
--- a/xen/include/public/mem_event.h
+++ /dev/null
@@ -1,179 +0,0 @@
-/******************************************************************************
- * mem_event.h
- *
- * Memory event common structures.
- *
- * Copyright (c) 2009 by Citrix Systems, Inc. (Patrick Colp)
- *
- * 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_MEM_EVENT_H
-#define _XEN_PUBLIC_MEM_EVENT_H
-
-#include "xen.h"
-#include "io/ring.h"
-
-/* Memory event flags */
-#define MEM_EVENT_FLAG_VCPU_PAUSED     (1 << 0)
-#define MEM_EVENT_FLAG_DROP_PAGE       (1 << 1)
-#define MEM_EVENT_FLAG_EVICT_FAIL      (1 << 2)
-#define MEM_EVENT_FLAG_FOREIGN         (1 << 3)
-#define MEM_EVENT_FLAG_DUMMY           (1 << 4)
-/*
- * Emulate the fault-causing instruction (if set in the event response flags).
- * This will allow the guest to continue execution without lifting the page
- * access restrictions.
- */
-#define MEM_EVENT_FLAG_EMULATE         (1 << 5)
-/*
- * Same as MEM_EVENT_FLAG_EMULATE, but with write operations or operations
- * potentially having side effects (like memory mapped or port I/O) disabled.
- */
-#define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 << 6)
-
-/* Reasons for the memory event request */
-typedef enum {
-    MEM_EVENT_REASON_UNKNOWN,              /* Default case */
-    MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
-    MEM_EVENT_REASON_MEM_SHARING,          /* Memory sharing event */
-    MEM_EVENT_REASON_MEM_PAGING,           /* Memory paging event */
-    MEM_EVENT_REASON_CR0,                  /* CR0 was updated */
-    MEM_EVENT_REASON_CR3,                  /* CR3 was updated */
-    MEM_EVENT_REASON_CR4,                  /* CR4 was updated */
-    MEM_EVENT_REASON_INT3,                 /* Debug operation executed (int3) */
-    MEM_EVENT_REASON_SINGLESTEP,           /* Single-step (MTF) */
-    MEM_EVENT_REASON_MSR,                  /* An MSR was updated.
-                                            * Does NOT honour HVMPME_onchangeonly */
-} mem_event_reason_t;
-
-/* Using a custom struct (not hvm_hw_cpu) so as to not fill
- * the mem_event ring buffer too quickly. */
-struct mem_event_regs_x86 {
-    uint64_t rax;
-    uint64_t rcx;
-    uint64_t rdx;
-    uint64_t rbx;
-    uint64_t rsp;
-    uint64_t rbp;
-    uint64_t rsi;
-    uint64_t rdi;
-    uint64_t r8;
-    uint64_t r9;
-    uint64_t r10;
-    uint64_t r11;
-    uint64_t r12;
-    uint64_t r13;
-    uint64_t r14;
-    uint64_t r15;
-    uint64_t rflags;
-    uint64_t dr7;
-    uint64_t rip;
-    uint64_t cr0;
-    uint64_t cr2;
-    uint64_t cr3;
-    uint64_t cr4;
-    uint64_t sysenter_cs;
-    uint64_t sysenter_esp;
-    uint64_t sysenter_eip;
-    uint64_t msr_efer;
-    uint64_t msr_star;
-    uint64_t msr_lstar;
-    uint64_t fs_base;
-    uint64_t gs_base;
-    uint32_t cs_arbytes;
-    uint32_t _pad;
-};
-
-struct mem_event_mem_access_data {
-    uint64_t gfn;
-    uint64_t offset;
-    uint64_t gla; /* if gla_valid */
-    uint16_t access_r:1;
-    uint16_t access_w:1;
-    uint16_t access_x:1;
-    uint16_t gla_valid:1;
-    uint16_t fault_with_gla:1;
-    uint16_t fault_in_gpt:1;
-    uint16_t available:10;
-};
-
-struct mem_event_cr_data {
-    uint64_t new_value;
-    uint64_t old_value;
-};
-
-struct mem_event_int3_data {
-    uint64_t gfn;
-    uint64_t gla;
-};
-
-struct mem_event_singlestep_data {
-    uint64_t gfn;
-    uint64_t gla;
-};
-
-struct mem_event_msr_data {
-    uint64_t msr;
-    uint64_t old_value;
-    uint64_t new_value;
-};
-
-struct mem_event_paging_data {
-    uint64_t gfn;
-    uint32_t p2mt;
-};
-
-struct mem_event_sharing_data {
-    uint64_t gfn;
-    uint32_t p2mt;
-};
-
-typedef struct mem_event_st {
-    uint32_t flags;
-    uint32_t vcpu_id;
-
-    mem_event_reason_t reason;
-
-    union {
-        struct mem_event_paging_data     mem_paging_event;
-        struct mem_event_sharing_data    mem_sharing_event;
-        struct mem_event_mem_access_data mem_access_event;
-        struct mem_event_cr_data         cr_event;
-        struct mem_event_int3_data       int3_event;
-        struct mem_event_singlestep_data singlestep_event;
-        struct mem_event_msr_data        msr_event;
-    };
-
-    struct mem_event_regs_x86 x86_regs;
-} mem_event_request_t, mem_event_response_t;
-
-DEFINE_RING_TYPES(mem_event, mem_event_request_t, mem_event_response_t);
-
-#endif
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
new file mode 100644
index 0000000..ca31a39
--- /dev/null
+++ b/xen/include/public/vm_event.h
@@ -0,0 +1,179 @@
+/******************************************************************************
+ * vm_event.h
+ *
+ * VM event common structures.
+ *
+ * Copyright (c) 2009 by Citrix Systems, Inc. (Patrick Colp)
+ *
+ * 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_VM_EVENT_H
+#define _XEN_PUBLIC_VM_EVENT_H
+
+#include "xen.h"
+#include "io/ring.h"
+
+/* Memory event flags */
+#define VM_EVENT_FLAG_VCPU_PAUSED     (1 << 0)
+#define VM_EVENT_FLAG_DROP_PAGE       (1 << 1)
+#define VM_EVENT_FLAG_EVICT_FAIL      (1 << 2)
+#define VM_EVENT_FLAG_FOREIGN         (1 << 3)
+#define VM_EVENT_FLAG_DUMMY           (1 << 4)
+/*
+ * Emulate the fault-causing instruction (if set in the event response flags).
+ * This will allow the guest to continue execution without lifting the page
+ * access restrictions.
+ */
+#define VM_EVENT_FLAG_EMULATE         (1 << 5)
+/*
+ * Same as VM_EVENT_FLAG_EMULATE, but with write operations or operations
+ * potentially having side effects (like memory mapped or port I/O) disabled.
+ */
+#define VM_EVENT_FLAG_EMULATE_NOWRITE (1 << 6)
+
+/* Reasons for the memory event request */
+typedef enum {
+    VM_EVENT_REASON_UNKNOWN,              /* Default case */
+    VM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
+    VM_EVENT_REASON_MEM_SHARING,          /* Memory sharing event */
+    VM_EVENT_REASON_MEM_PAGING,           /* Memory paging event */
+    VM_EVENT_REASON_CR0,                  /* CR0 was updated */
+    VM_EVENT_REASON_CR3,                  /* CR3 was updated */
+    VM_EVENT_REASON_CR4,                  /* CR4 was updated */
+    VM_EVENT_REASON_INT3,                 /* Debug operation executed (int3) */
+    VM_EVENT_REASON_SINGLESTEP,           /* Single-step (MTF) */
+    VM_EVENT_REASON_MSR,                  /* An MSR was updated.
+                                            * Does NOT honour HVMPME_onchangeonly */
+} vm_event_reason_t;
+
+/* Using a custom struct (not hvm_hw_cpu) so as to not fill
+ * the vm_event ring buffer too quickly. */
+struct vm_event_regs_x86 {
+    uint64_t rax;
+    uint64_t rcx;
+    uint64_t rdx;
+    uint64_t rbx;
+    uint64_t rsp;
+    uint64_t rbp;
+    uint64_t rsi;
+    uint64_t rdi;
+    uint64_t r8;
+    uint64_t r9;
+    uint64_t r10;
+    uint64_t r11;
+    uint64_t r12;
+    uint64_t r13;
+    uint64_t r14;
+    uint64_t r15;
+    uint64_t rflags;
+    uint64_t dr7;
+    uint64_t rip;
+    uint64_t cr0;
+    uint64_t cr2;
+    uint64_t cr3;
+    uint64_t cr4;
+    uint64_t sysenter_cs;
+    uint64_t sysenter_esp;
+    uint64_t sysenter_eip;
+    uint64_t msr_efer;
+    uint64_t msr_star;
+    uint64_t msr_lstar;
+    uint64_t fs_base;
+    uint64_t gs_base;
+    uint32_t cs_arbytes;
+    uint32_t _pad;
+};
+
+struct vm_event_mem_access_data {
+    uint64_t gfn;
+    uint64_t offset;
+    uint64_t gla; /* if gla_valid */
+    uint16_t access_r:1;
+    uint16_t access_w:1;
+    uint16_t access_x:1;
+    uint16_t gla_valid:1;
+    uint16_t fault_with_gla:1;
+    uint16_t fault_in_gpt:1;
+    uint16_t available:10;
+};
+
+struct vm_event_cr_data {
+    uint64_t new_value;
+    uint64_t old_value;
+};
+
+struct vm_event_int3_data {
+    uint64_t gfn;
+    uint64_t gla;
+};
+
+struct vm_event_singlestep_data {
+    uint64_t gfn;
+    uint64_t gla;
+};
+
+struct vm_event_msr_data {
+    uint64_t msr;
+    uint64_t old_value;
+    uint64_t new_value;
+};
+
+struct vm_event_paging_data {
+    uint64_t gfn;
+    uint32_t p2mt;
+};
+
+struct vm_event_sharing_data {
+    uint64_t gfn;
+    uint32_t p2mt;
+};
+
+typedef struct vm_event_st {
+    uint32_t flags;
+    uint32_t vcpu_id;
+
+    vm_event_reason_t reason;
+
+    union {
+        struct vm_event_paging_data     mem_paging_event;
+        struct vm_event_sharing_data    mem_sharing_event;
+        struct vm_event_mem_access_data mem_access_event;
+        struct vm_event_cr_data         cr_event;
+        struct vm_event_int3_data       int3_event;
+        struct vm_event_singlestep_data singlestep_event;
+        struct vm_event_msr_data        msr_event;
+    };
+
+    struct vm_event_regs_x86 x86_regs;
+} vm_event_request_t, vm_event_response_t;
+
+DEFINE_RING_TYPES(vm_event, vm_event_request_t, vm_event_response_t);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
index 6ceb2a4..1d01221 100644
--- a/xen/include/xen/mem_access.h
+++ b/xen/include/xen/mem_access.h
@@ -29,7 +29,7 @@
 
 int mem_access_memop(unsigned long cmd,
                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
-int mem_access_send_req(struct domain *d, mem_event_request_t *req);
+int mem_access_send_req(struct domain *d, vm_event_request_t *req);
 
 /* Resumes the running of the VCPU, restarting the last instruction */
 void mem_access_resume(struct domain *d);
@@ -44,7 +44,7 @@ int mem_access_memop(unsigned long cmd,
 }
 
 static inline
-int mem_access_send_req(struct domain *d, mem_event_request_t *req)
+int mem_access_send_req(struct domain *d, vm_event_request_t *req)
 {
     return -ENOSYS;
 }
diff --git a/xen/include/xen/mem_event.h b/xen/include/xen/mem_event.h
deleted file mode 100644
index 4f3ad8e..0000000
--- a/xen/include/xen/mem_event.h
+++ /dev/null
@@ -1,143 +0,0 @@
-/******************************************************************************
- * mem_event.h
- *
- * Common interface for memory event support.
- *
- * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-
-
-#ifndef __MEM_EVENT_H__
-#define __MEM_EVENT_H__
-
-#include <xen/sched.h>
-
-#ifdef HAS_MEM_ACCESS
-
-/* Clean up on domain destruction */
-void mem_event_cleanup(struct domain *d);
-
-/* 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 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);
-
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
-                            mem_event_request_t *req);
-
-int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
-                           mem_event_response_t *rsp);
-
-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_PARAM(void) u_domctl);
-
-void mem_event_vcpu_pause(struct vcpu *v);
-void mem_event_vcpu_unpause(struct vcpu *v);
-
-#else
-
-static inline void mem_event_cleanup(struct domain *d) {}
-
-static inline bool_t mem_event_check_ring(struct mem_event_domain *med)
-{
-    return 0;
-}
-
-static inline int mem_event_claim_slot(struct domain *d,
-                                        struct mem_event_domain *med)
-{
-    return -ENOSYS;
-}
-
-static inline int mem_event_claim_slot_nosleep(struct domain *d,
-                                        struct mem_event_domain *med)
-{
-    return -ENOSYS;
-}
-
-static inline
-void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med)
-{}
-
-static inline
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
-                            mem_event_request_t *req)
-{}
-
-static inline
-int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
-                           mem_event_response_t *rsp)
-{
-    return -ENOSYS;
-}
-
-static inline int do_mem_event_op(int op, uint32_t domain, void *arg)
-{
-    return -ENOSYS;
-}
-
-static inline
-int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
-{
-    return -ENOSYS;
-}
-
-static inline void mem_event_vcpu_pause(struct vcpu *v) {}
-static inline void mem_event_vcpu_unpause(struct vcpu *v) {}
-
-#endif /* HAS_MEM_ACCESS */
-
-#endif /* __MEM_EVENT_H__ */
-
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/xen/p2m-common.h b/xen/include/xen/p2m-common.h
index 29f3628..5da8a2d 100644
--- a/xen/include/xen/p2m-common.h
+++ b/xen/include/xen/p2m-common.h
@@ -1,12 +1,12 @@
 #ifndef _XEN_P2M_COMMON_H
 #define _XEN_P2M_COMMON_H
 
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 
 /*
  * Additional access types, which are used to further restrict
  * the permissions given my the p2m_type_t memory type.  Violations
- * caused by p2m_access_t restrictions are sent to the mem_event
+ * caused by p2m_access_t restrictions are sent to the vm_event
  * interface.
  *
  * The access permissions are soft state: when any ambiguous change of page
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 2fc36ea..14fae4a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -23,7 +23,7 @@
 #include <public/domctl.h>
 #include <public/sysctl.h>
 #include <public/vcpu.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <public/event_channel.h>
 
 #ifdef CONFIG_COMPAT
@@ -214,8 +214,8 @@ struct vcpu
     unsigned long    pause_flags;
     atomic_t         pause_count;
 
-    /* VCPU paused for mem_event replies. */
-    atomic_t         mem_event_pause_count;
+    /* VCPU paused for vm_event replies. */
+    atomic_t         vm_event_pause_count;
     /* VCPU paused by system controller. */
     int              controller_pause_count;
 
@@ -258,7 +258,7 @@ struct vcpu
 #define domain_is_locked(d) spin_is_locked(&(d)->domain_lock)
 
 /* Memory event */
-struct mem_event_domain
+struct vm_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
@@ -269,10 +269,10 @@ struct mem_event_domain
     void *ring_page;
     struct page_info *ring_pg_struct;
     /* front-end ring */
-    mem_event_front_ring_t front_ring;
+    vm_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
-    /* mem_event bit for vcpu->pause_flags */
+    /* vm_event bit for vcpu->pause_flags */
     int pause_flag;
     /* list of vcpus waiting for room in the ring */
     struct waitqueue_head wq;
@@ -282,14 +282,14 @@ struct mem_event_domain
     unsigned int last_vcpu_wake_up;
 };
 
-struct mem_event_per_domain
+struct vm_event_per_domain
 {
     /* Memory sharing support */
-    struct mem_event_domain share;
+    struct vm_event_domain share;
     /* Memory paging support */
-    struct mem_event_domain paging;
-    /* VM event monitor support */
-    struct mem_event_domain monitor;
+    struct vm_event_domain paging;
+    /* Memory access support */
+    struct vm_event_domain monitor;
 };
 
 struct evtchn_port_ops;
@@ -442,8 +442,8 @@ struct domain
     /* Non-migratable and non-restoreable? */
     bool_t disable_migrate;
 
-    /* Various mem_events */
-    struct mem_event_per_domain *mem_event;
+    /* Various vm_events */
+    struct vm_event_per_domain *vm_event;
 
     /*
      * Can be specified by the user. If that is not the case, it is
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
new file mode 100644
index 0000000..e6e31cd
--- /dev/null
+++ b/xen/include/xen/vm_event.h
@@ -0,0 +1,143 @@
+/******************************************************************************
+ * vm_event.h
+ *
+ * Common interface for memory event support.
+ *
+ * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+
+#ifndef __VM_EVENT_H__
+#define __VM_EVENT_H__
+
+#include <xen/sched.h>
+
+#ifdef HAS_MEM_ACCESS
+
+/* Clean up on domain destruction */
+void vm_event_cleanup(struct domain *d);
+
+/* Returns whether a ring has been set up */
+bool_t vm_event_check_ring(struct vm_event_domain *med);
+
+/* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
+ * 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 __vm_event_claim_slot(struct domain *d, struct vm_event_domain *med,
+                            bool_t allow_sleep);
+static inline int vm_event_claim_slot(struct domain *d,
+                                        struct vm_event_domain *med)
+{
+    return __vm_event_claim_slot(d, med, 1);
+}
+
+static inline int vm_event_claim_slot_nosleep(struct domain *d,
+                                        struct vm_event_domain *med)
+{
+    return __vm_event_claim_slot(d, med, 0);
+}
+
+void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *med);
+
+void vm_event_put_request(struct domain *d, struct vm_event_domain *med,
+                            vm_event_request_t *req);
+
+int vm_event_get_response(struct domain *d, struct vm_event_domain *med,
+                           vm_event_response_t *rsp);
+
+int do_vm_event_op(int op, uint32_t domain, void *arg);
+int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *mec,
+                     XEN_GUEST_HANDLE_PARAM(void) u_domctl);
+
+void vm_event_vcpu_pause(struct vcpu *v);
+void vm_event_vcpu_unpause(struct vcpu *v);
+
+#else
+
+static inline void vm_event_cleanup(struct domain *d) {}
+
+static inline bool_t vm_event_check_ring(struct vm_event_domain *med)
+{
+    return 0;
+}
+
+static inline int vm_event_claim_slot(struct domain *d,
+                                        struct vm_event_domain *med)
+{
+    return -ENOSYS;
+}
+
+static inline int vm_event_claim_slot_nosleep(struct domain *d,
+                                        struct vm_event_domain *med)
+{
+    return -ENOSYS;
+}
+
+static inline
+void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *med)
+{}
+
+static inline
+void vm_event_put_request(struct domain *d, struct vm_event_domain *med,
+                            vm_event_request_t *req)
+{}
+
+static inline
+int vm_event_get_response(struct domain *d, struct vm_event_domain *med,
+                           vm_event_response_t *rsp)
+{
+    return -ENOSYS;
+}
+
+static inline int do_vm_event_op(int op, uint32_t domain, void *arg)
+{
+    return -ENOSYS;
+}
+
+static inline
+int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *mec,
+                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
+{
+    return -ENOSYS;
+}
+
+static inline void vm_event_vcpu_pause(struct vcpu *v) {}
+static inline void vm_event_vcpu_unpause(struct vcpu *v) {}
+
+#endif /* HAS_MEM_ACCESS */
+
+#endif /* __MEM_EVENT_H__ */
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f20e89c..4227093 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -514,13 +514,13 @@ static XSM_INLINE int xsm_hvm_param_nested(XSM_DEFAULT_ARG struct domain *d)
 }
 
 #ifdef HAS_MEM_ACCESS
-static XSM_INLINE int xsm_mem_event_control(XSM_DEFAULT_ARG struct domain *d, int mode, int op)
+static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, int mode, int op)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
     return xsm_default_action(action, current->domain, d);
 }
 
-static XSM_INLINE int xsm_mem_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
+static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
 {
     XSM_ASSERT_ACTION(XSM_DM_PRIV);
     return xsm_default_action(action, current->domain, d);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4ce089f..cff9d35 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -142,8 +142,8 @@ struct xsm_operations {
     int (*get_vnumainfo) (struct domain *d);
 
 #ifdef HAS_MEM_ACCESS
-    int (*mem_event_control) (struct domain *d, int mode, int op);
-    int (*mem_event_op) (struct domain *d, int op);
+    int (*vm_event_control) (struct domain *d, int mode, int op);
+    int (*vm_event_op) (struct domain *d, int op);
 #endif
 
 #ifdef CONFIG_X86
@@ -544,14 +544,14 @@ static inline int xsm_get_vnumainfo (xsm_default_t def, struct domain *d)
 }
 
 #ifdef HAS_MEM_ACCESS
-static inline int xsm_mem_event_control (xsm_default_t def, struct domain *d, int mode, int op)
+static inline int xsm_vm_event_control (xsm_default_t def, struct domain *d, int mode, int op)
 {
-    return xsm_ops->mem_event_control(d, mode, op);
+    return xsm_ops->vm_event_control(d, mode, op);
 }
 
-static inline int xsm_mem_event_op (xsm_default_t def, struct domain *d, int op)
+static inline int xsm_vm_event_op (xsm_default_t def, struct domain *d, int op)
 {
-    return xsm_ops->mem_event_op(d, op);
+    return xsm_ops->vm_event_op(d, op);
 }
 #endif
 
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 8eb3050..25fca68 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -119,8 +119,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, map_gmfn_foreign);
 
 #ifdef HAS_MEM_ACCESS
-    set_to_dummy_if_null(ops, mem_event_control);
-    set_to_dummy_if_null(ops, mem_event_op);
+    set_to_dummy_if_null(ops, vm_event_control);
+    set_to_dummy_if_null(ops, vm_event_op);
 #endif
 
 #ifdef CONFIG_X86
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0ba2ce9..d706b1f 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -578,7 +578,7 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_set_target:
 #ifdef HAS_MEM_ACCESS
-    case XEN_DOMCTL_mem_event_op:
+    case XEN_DOMCTL_vm_event_op:
 #endif
 #ifdef CONFIG_X86
     /* These have individual XSM hooks (arch/x86/domctl.c) */
@@ -687,7 +687,7 @@ static int flask_domctl(struct domain *d, int cmd)
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
 
     case XEN_DOMCTL_set_access_required:
-        return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+        return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
 
     case XEN_DOMCTL_debug_op:
     case XEN_DOMCTL_gdbsx_guestmemio:
@@ -1201,14 +1201,14 @@ static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
 #endif /* HAS_PASSTHROUGH && HAS_PCI */
 
 #ifdef HAS_MEM_ACCESS
-static int flask_mem_event_control(struct domain *d, int mode, int op)
+static int flask_vm_event_control(struct domain *d, int mode, int op)
 {
-    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
 }
 
-static int flask_mem_event_op(struct domain *d, int op)
+static int flask_vm_event_op(struct domain *d, int op)
 {
-    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
 }
 #endif /* HAS_MEM_ACCESS */
 
@@ -1595,8 +1595,8 @@ static struct xsm_operations flask_ops = {
 #endif
 
 #ifdef HAS_MEM_ACCESS
-    .mem_event_control = flask_mem_event_control,
-    .mem_event_op = flask_mem_event_op,
+    .vm_event_control = flask_vm_event_control,
+    .vm_event_op = flask_vm_event_op,
 #endif
 
 #ifdef CONFIG_X86
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1cd451e..452dd02 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -247,7 +247,7 @@ class hvm
 # HVMOP_inject_trap
     hvmctl
 # XEN_DOMCTL_set_access_required
-    mem_event
+    vm_event
 # XEN_DOMCTL_mem_sharing_op and XENMEM_sharing_op_{share,add_physmap} with:
 #  source = the domain making the hypercall
 #  target = domain whose memory is being shared
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:32:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZuI-00081w-O2; Wed, 12 Nov 2014 15:32:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoZuG-0007yv-P8
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:32:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/E7-24532-C8D73645; Wed, 12 Nov 2014 15:32:28 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415806342!12260474!1
X-Originating-IP: [209.85.216.182]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22797 invoked from network); 12 Nov 2014 15:32:22 -0000
Received: from mail-qc0-f182.google.com (HELO mail-qc0-f182.google.com)
	(209.85.216.182)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:32:22 -0000
Received: by mail-qc0-f182.google.com with SMTP id m20so9655656qcx.27
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:32:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=7fen1pMWxJntn5ybJKQwF2PmfG+2GwaM7rtmrUa/Ifs=;
	b=amKEhrvU/7pPY3zO6MHc0/PK7I1pIUqDe+gg8XfHarHdy18e9Mz+61C10Nbe0sa/3C
	1MQAd2CANfb6Ix0NfXDnzBQJt9NQdXrUaNnWUp0HRtXn2i2yPC4/zn2FOz3l3yEkj0SI
	V8iH0EugfAla/T+cJK8AVqzX1A8yQ40SN1nEqpboJmSnS5Nc8aqi2mEDtR36+QPVArGc
	qduR+ti1gkk28We9jKyAx2B4CF8nQbeaNDWscFY8THI99RjoBXZlNANAycBQg9Z5+vkL
	Cj44fDuQ9VWWDoSb57f/zGM11M4iXK04+VEhk8FveTGX86q9NxfKxjayNkynDOFJ7EOv
	Tjkw==
X-Gm-Message-State: ALoCoQk6ZZ0u10/psqE1VVczNrlsN7QU7aQHm0m2Cz1JhP+eDx6C1qYeEwwDxsa2SdLEaRAq2cwZ
X-Received: by 10.224.29.1 with SMTP id o1mr63293587qac.23.1415806341733;
	Wed, 12 Nov 2014 07:32:21 -0800 (PST)
Received: from ourea.sec.in.tum.de (ourea.sec.in.tum.de. [131.159.50.52])
	by mx.google.com with ESMTPSA id
	o40sm21228898qga.23.2014.11.12.07.32.19 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:32:21 -0800 (PST)
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: xen-devel@lists.xen.org
Date: Wed, 12 Nov 2014 16:31:47 +0100
Message-Id: <1415806309-5206-6-git-send-email-tamas.lengyel@zentific.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [PATCH RFC 5/7] xen/mem_event: Rename mem_event to
	vm_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>
MIME-Version: 1.0
Content-Type: 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 mem_event system has originally been used to deliver memory event
related information to helper programs located in a domain. However,
the usage of this sub-system have since been expanded to include non-memory
related events as well, such as register changes, debugging and singlestepping.
Therefore, renaming the system "vm_event" more accurately describes the actual
usage of the subsystem.

In this patch I also clear up the ambiguities that resulted from the interchanged
mem_event and mem_access terminology.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 tools/libxc/Makefile                |   2 +-
 tools/libxc/xc_mem_access.c         |  10 +-
 tools/libxc/xc_mem_event.c          | 162 --------
 tools/libxc/xc_mem_paging.c         |  12 +-
 tools/libxc/xc_memshr.c             |  12 +-
 tools/libxc/xc_private.h            |   6 +-
 tools/libxc/xc_vm_event.c           | 162 ++++++++
 tools/tests/xen-access/xen-access.c | 104 ++---
 tools/xenpaging/pagein.c            |   2 +-
 tools/xenpaging/xenpaging.c         | 118 +++---
 tools/xenpaging/xenpaging.h         |   8 +-
 xen/arch/x86/domain.c               |   2 +-
 xen/arch/x86/domctl.c               |   4 +-
 xen/arch/x86/hvm/emulate.c          |   4 +-
 xen/arch/x86/hvm/hvm.c              |  44 +--
 xen/arch/x86/hvm/vmx/vmcs.c         |   4 +-
 xen/arch/x86/mm/hap/nested_ept.c    |   4 +-
 xen/arch/x86/mm/hap/nested_hap.c    |   4 +-
 xen/arch/x86/mm/mem_paging.c        |   4 +-
 xen/arch/x86/mm/mem_sharing.c       |  28 +-
 xen/arch/x86/mm/p2m-pod.c           |   4 +-
 xen/arch/x86/mm/p2m-pt.c            |   4 +-
 xen/arch/x86/mm/p2m.c               |  94 ++---
 xen/arch/x86/x86_64/compat/mm.c     |   6 +-
 xen/arch/x86/x86_64/mm.c            |   6 +-
 xen/common/Makefile                 |   2 +-
 xen/common/domain.c                 |  12 +-
 xen/common/domctl.c                 |   6 +-
 xen/common/mem_access.c             |  24 +-
 xen/common/mem_event.c              | 742 ------------------------------------
 xen/common/vm_event.c               | 742 ++++++++++++++++++++++++++++++++++++
 xen/drivers/passthrough/pci.c       |   2 +-
 xen/include/asm-arm/p2m.h           |   6 +-
 xen/include/asm-x86/domain.h        |   4 +-
 xen/include/asm-x86/hvm/emulate.h   |   2 +-
 xen/include/asm-x86/p2m.h           |  16 +-
 xen/include/public/domctl.h         |  42 +-
 xen/include/public/mem_event.h      | 179 ---------
 xen/include/public/vm_event.h       | 179 +++++++++
 xen/include/xen/mem_access.h        |   4 +-
 xen/include/xen/mem_event.h         | 143 -------
 xen/include/xen/p2m-common.h        |   4 +-
 xen/include/xen/sched.h             |  26 +-
 xen/include/xen/vm_event.h          | 143 +++++++
 xen/include/xsm/dummy.h             |   4 +-
 xen/include/xsm/xsm.h               |  12 +-
 xen/xsm/dummy.c                     |   4 +-
 xen/xsm/flask/hooks.c               |  16 +-
 xen/xsm/flask/policy/access_vectors |   2 +-
 49 files changed, 1560 insertions(+), 1566 deletions(-)
 delete mode 100644 tools/libxc/xc_mem_event.c
 create mode 100644 tools/libxc/xc_vm_event.c
 delete mode 100644 xen/common/mem_event.c
 create mode 100644 xen/common/vm_event.c
 delete mode 100644 xen/include/public/mem_event.h
 create mode 100644 xen/include/public/vm_event.h
 delete mode 100644 xen/include/xen/mem_event.h
 create mode 100644 xen/include/xen/vm_event.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index bd2ca6c..6ef17ec 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -26,7 +26,7 @@ CTRL_SRCS-y       += xc_pm.c
 CTRL_SRCS-y       += xc_cpu_hotplug.c
 CTRL_SRCS-y       += xc_resume.c
 CTRL_SRCS-y       += xc_tmem.c
-CTRL_SRCS-y       += xc_mem_event.c
+CTRL_SRCS-y       += xc_vm_event.c
 CTRL_SRCS-y       += xc_mem_paging.c
 CTRL_SRCS-y       += xc_mem_access.c
 CTRL_SRCS-y       += xc_memshr.c
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 1c979ed..80f4e2d 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -26,22 +26,22 @@
 
 void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t *port)
 {
-    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
+    return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
                                port, 0);
 }
 
 void *xc_mem_access_enable_introspection(xc_interface *xch, domid_t domain_id,
                                          uint32_t *port)
 {
-    return xc_mem_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
+    return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
                                port, 1);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE,
-                                XEN_DOMCTL_MEM_EVENT_OP_MONITOR,
+    return xc_vm_event_control(xch, domain_id,
+                                XEN_DOMCTL_VM_EVENT_OP_MONITOR_DISABLE,
+                                XEN_DOMCTL_VM_EVENT_OP_MONITOR,
                                 NULL);
 }
 
diff --git a/tools/libxc/xc_mem_event.c b/tools/libxc/xc_mem_event.c
deleted file mode 100644
index a5e0948..0000000
--- a/tools/libxc/xc_mem_event.c
+++ /dev/null
@@ -1,162 +0,0 @@
-/******************************************************************************
- *
- * xc_mem_event.c
- *
- * Interface to low-level memory event functionality.
- *
- * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
- *
- * 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
- */
-
-#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)
-{
-    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;
-    
-    rc = do_domctl(xch, &domctl);
-    if ( !rc && port )
-        *port = domctl.u.mem_event_op.port;
-    return rc;
-}
-
-void *xc_mem_event_enable(xc_interface *xch, domid_t domain_id, int param,
-                          uint32_t *port, int enable_introspection)
-{
-    void *ring_page = NULL;
-    uint64_t pfn;
-    xen_pfn_t ring_pfn, mmap_pfn;
-    unsigned int op, mode;
-    int rc1, rc2, saved_errno;
-
-    if ( !port )
-    {
-        errno = EINVAL;
-        return NULL;
-    }
-
-    /* Pause the domain for ring page setup */
-    rc1 = xc_domain_pause(xch, domain_id);
-    if ( rc1 != 0 )
-    {
-        PERROR("Unable to pause domain\n");
-        return NULL;
-    }
-
-    /* Get the pfn of the ring page */
-    rc1 = xc_hvm_param_get(xch, domain_id, param, &pfn);
-    if ( rc1 != 0 )
-    {
-        PERROR("Failed to get pfn of ring page\n");
-        goto out;
-    }
-
-    ring_pfn = pfn;
-    mmap_pfn = pfn;
-    ring_page = xc_map_foreign_batch(xch, domain_id, PROT_READ | PROT_WRITE,
-                                     &mmap_pfn, 1);
-    if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
-    {
-        /* Map failed, populate ring page */
-        rc1 = xc_domain_populate_physmap_exact(xch, domain_id, 1, 0, 0,
-                                              &ring_pfn);
-        if ( rc1 != 0 )
-        {
-            PERROR("Failed to populate ring pfn\n");
-            goto out;
-        }
-
-        mmap_pfn = ring_pfn;
-        ring_page = xc_map_foreign_batch(xch, 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 out;
-        }
-    }
-
-    switch ( param )
-    {
-    case HVM_PARAM_PAGING_RING_PFN:
-        op = XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE;
-        mode = XEN_DOMCTL_MEM_EVENT_OP_PAGING;
-        break;
-
-    case HVM_PARAM_MONITOR_RING_PFN:
-        if ( enable_introspection )
-            op = XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION;
-        else
-            op = XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE;
-        mode = XEN_DOMCTL_MEM_EVENT_OP_MONITOR;
-        break;
-
-    case HVM_PARAM_SHARING_RING_PFN:
-        op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE;
-        mode = XEN_DOMCTL_MEM_EVENT_OP_SHARING;
-        break;
-
-    /*
-     * This is for the outside chance that the HVM_PARAM is valid but is invalid
-     * as far as mem_event goes.
-     */
-    default:
-        errno = EINVAL;
-        rc1 = -1;
-        goto out;
-    }
-
-    rc1 = xc_mem_event_control(xch, domain_id, op, mode, port);
-    if ( rc1 != 0 )
-    {
-        PERROR("Failed to enable mem_event\n");
-        goto out;
-    }
-
-    /* Remove the ring_pfn from the guest's physmap */
-    rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0, &ring_pfn);
-    if ( rc1 != 0 )
-        PERROR("Failed to remove ring page from guest physmap");
-
- out:
-    saved_errno = errno;
-
-    rc2 = xc_domain_unpause(xch, domain_id);
-    if ( rc1 != 0 || rc2 != 0 )
-    {
-        if ( rc2 != 0 )
-        {
-            if ( rc1 == 0 )
-                saved_errno = errno;
-            PERROR("Unable to unpause domain");
-        }
-
-        if ( ring_page )
-            munmap(ring_page, XC_PAGE_SIZE);
-        ring_page = NULL;
-
-        errno = saved_errno;
-    }
-
-    return ring_page;
-}
diff --git a/tools/libxc/xc_mem_paging.c b/tools/libxc/xc_mem_paging.c
index bf3173d..8408b07 100644
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -47,17 +47,17 @@ int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
         return -1;
     }
         
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
+    return xc_vm_event_control(xch, domain_id,
+                                XEN_DOMCTL_VM_EVENT_OP_PAGING_ENABLE,
+                                XEN_DOMCTL_VM_EVENT_OP_PAGING,
                                 port);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
+    return xc_vm_event_control(xch, domain_id,
+                                XEN_DOMCTL_VM_EVENT_OP_PAGING_DISABLE,
+                                XEN_DOMCTL_VM_EVENT_OP_PAGING,
                                 NULL);
 }
 
diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
index d6a9539..fafa073 100644
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -52,18 +52,18 @@ int xc_memshr_ring_enable(xc_interface *xch,
         return -1;
     }
         
-    return xc_mem_event_control(xch, domid,
-                                XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE,
-                                XEN_DOMCTL_MEM_EVENT_OP_SHARING,
+    return xc_vm_event_control(xch, domid,
+                                XEN_DOMCTL_VM_EVENT_OP_SHARING_ENABLE,
+                                XEN_DOMCTL_VM_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,
+    return xc_vm_event_control(xch, domid,
+                                XEN_DOMCTL_VM_EVENT_OP_SHARING_DISABLE,
+                                XEN_DOMCTL_VM_EVENT_OP_SHARING,
                                 NULL);
 }
 
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index f1f601c..a539300 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -421,15 +421,15 @@ int xc_ffs64(uint64_t x);
 #define DOMPRINTF_CALLED(xch) xc_dom_printf((xch), "%s: called", __FUNCTION__)
 
 /**
- * mem_event operations. Internal use only.
+ * vm_event operations. Internal use only.
  */
-int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
+int xc_vm_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
                          unsigned int mode, uint32_t *port);
 /*
  * Enables mem_event and returns the mapped ring page indicated by param.
  * param can be HVM_PARAM_PAGING/ACCESS/SHARING_RING_PFN
  */
-void *xc_mem_event_enable(xc_interface *xch, domid_t domain_id, int param,
+void *xc_vm_event_enable(xc_interface *xch, domid_t domain_id, int param,
                           uint32_t *port, int enable_introspection);
 
 #endif /* __XC_PRIVATE_H__ */
diff --git a/tools/libxc/xc_vm_event.c b/tools/libxc/xc_vm_event.c
new file mode 100644
index 0000000..39d794d
--- /dev/null
+++ b/tools/libxc/xc_vm_event.c
@@ -0,0 +1,162 @@
+/******************************************************************************
+ *
+ * xc_vm_event.c
+ *
+ * Interface to low-level VM event functionality.
+ *
+ * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
+ *
+ * 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
+ */
+
+#include "xc_private.h"
+
+int xc_vm_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
+                         unsigned int mode, uint32_t *port)
+{
+    DECLARE_DOMCTL;
+    int rc;
+
+    domctl.cmd = XEN_DOMCTL_vm_event_op;
+    domctl.domain = domain_id;
+    domctl.u.vm_event_op.op = op;
+    domctl.u.vm_event_op.mode = mode;
+    
+    rc = do_domctl(xch, &domctl);
+    if ( !rc && port )
+        *port = domctl.u.vm_event_op.port;
+    return rc;
+}
+
+void *xc_vm_event_enable(xc_interface *xch, domid_t domain_id, int param,
+                          uint32_t *port, int enable_introspection)
+{
+    void *ring_page = NULL;
+    uint64_t pfn;
+    xen_pfn_t ring_pfn, mmap_pfn;
+    unsigned int op, mode;
+    int rc1, rc2, saved_errno;
+
+    if ( !port )
+    {
+        errno = EINVAL;
+        return NULL;
+    }
+
+    /* Pause the domain for ring page setup */
+    rc1 = xc_domain_pause(xch, domain_id);
+    if ( rc1 != 0 )
+    {
+        PERROR("Unable to pause domain\n");
+        return NULL;
+    }
+
+    /* Get the pfn of the ring page */
+    rc1 = xc_hvm_param_get(xch, domain_id, param, &pfn);
+    if ( rc1 != 0 )
+    {
+        PERROR("Failed to get pfn of ring page\n");
+        goto out;
+    }
+
+    ring_pfn = pfn;
+    mmap_pfn = pfn;
+    ring_page = xc_map_foreign_batch(xch, domain_id, PROT_READ | PROT_WRITE,
+                                     &mmap_pfn, 1);
+    if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
+    {
+        /* Map failed, populate ring page */
+        rc1 = xc_domain_populate_physmap_exact(xch, domain_id, 1, 0, 0,
+                                              &ring_pfn);
+        if ( rc1 != 0 )
+        {
+            PERROR("Failed to populate ring pfn\n");
+            goto out;
+        }
+
+        mmap_pfn = ring_pfn;
+        ring_page = xc_map_foreign_batch(xch, 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 out;
+        }
+    }
+
+    switch ( param )
+    {
+    case HVM_PARAM_PAGING_RING_PFN:
+        op = XEN_DOMCTL_VM_EVENT_OP_PAGING_ENABLE;
+        mode = XEN_DOMCTL_VM_EVENT_OP_PAGING;
+        break;
+
+    case HVM_PARAM_MONITOR_RING_PFN:
+        if ( enable_introspection )
+            op = XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION;
+        else
+            op = XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE;
+        mode = XEN_DOMCTL_VM_EVENT_OP_MONITOR;
+        break;
+
+    case HVM_PARAM_SHARING_RING_PFN:
+        op = XEN_DOMCTL_VM_EVENT_OP_SHARING_ENABLE;
+        mode = XEN_DOMCTL_VM_EVENT_OP_SHARING;
+        break;
+
+    /*
+     * This is for the outside chance that the HVM_PARAM is valid but is invalid
+     * as far as vm_event goes.
+     */
+    default:
+        errno = EINVAL;
+        rc1 = -1;
+        goto out;
+    }
+
+    rc1 = xc_vm_event_control(xch, domain_id, op, mode, port);
+    if ( rc1 != 0 )
+    {
+        PERROR("Failed to enable vm_event\n");
+        goto out;
+    }
+
+    /* Remove the ring_pfn from the guest's physmap */
+    rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0, &ring_pfn);
+    if ( rc1 != 0 )
+        PERROR("Failed to remove ring page from guest physmap");
+
+ out:
+    saved_errno = errno;
+
+    rc2 = xc_domain_unpause(xch, domain_id);
+    if ( rc1 != 0 || rc2 != 0 )
+    {
+        if ( rc2 != 0 )
+        {
+            if ( rc1 == 0 )
+                saved_errno = errno;
+            PERROR("Unable to unpause domain");
+        }
+
+        if ( ring_page )
+            munmap(ring_page, XC_PAGE_SIZE);
+        ring_page = NULL;
+
+        errno = saved_errno;
+    }
+
+    return ring_page;
+}
diff --git a/tools/tests/xen-access/xen-access.c b/tools/tests/xen-access/xen-access.c
index 9d53fb3..3538323 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -39,7 +39,7 @@
 #include <sys/poll.h>
 
 #include <xenctrl.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 
 #define DPRINTF(a, b...) fprintf(stderr, a, ## b)
 #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
@@ -91,26 +91,26 @@ static inline int spin_trylock(spinlock_t *lock)
     return !test_and_set_bit(1, lock);
 }
 
-#define mem_event_ring_lock_init(_m)  spin_lock_init(&(_m)->ring_lock)
-#define mem_event_ring_lock(_m)       spin_lock(&(_m)->ring_lock)
-#define mem_event_ring_unlock(_m)     spin_unlock(&(_m)->ring_lock)
+#define vm_event_ring_lock_init(_m)  spin_lock_init(&(_m)->ring_lock)
+#define vm_event_ring_lock(_m)       spin_lock(&(_m)->ring_lock)
+#define vm_event_ring_unlock(_m)     spin_unlock(&(_m)->ring_lock)
 
-typedef struct mem_event {
+typedef struct vm_event {
     domid_t domain_id;
     xc_evtchn *xce_handle;
     int port;
-    mem_event_back_ring_t back_ring;
+    vm_event_back_ring_t back_ring;
     uint32_t evtchn_port;
     void *ring_page;
     spinlock_t ring_lock;
-} mem_event_t;
+} vm_event_t;
 
 typedef struct xenaccess {
     xc_interface *xc_handle;
 
     xc_domaininfo_t    *domain_info;
 
-    mem_event_t mem_event;
+    vm_event_t vm_event;
 } xenaccess_t;
 
 static int interrupted;
@@ -170,13 +170,13 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
         return 0;
 
     /* Tear down domain xenaccess in Xen */
-    if ( xenaccess->mem_event.ring_page )
-        munmap(xenaccess->mem_event.ring_page, XC_PAGE_SIZE);
+    if ( xenaccess->vm_event.ring_page )
+        munmap(xenaccess->vm_event.ring_page, XC_PAGE_SIZE);
 
     if ( mem_access_enable )
     {
         rc = xc_mem_access_disable(xenaccess->xc_handle,
-                                   xenaccess->mem_event.domain_id);
+                                   xenaccess->vm_event.domain_id);
         if ( rc != 0 )
         {
             ERROR("Error tearing down domain xenaccess in xen");
@@ -186,8 +186,8 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
     /* Unbind VIRQ */
     if ( evtchn_bind )
     {
-        rc = xc_evtchn_unbind(xenaccess->mem_event.xce_handle,
-                              xenaccess->mem_event.port);
+        rc = xc_evtchn_unbind(xenaccess->vm_event.xce_handle,
+                              xenaccess->vm_event.port);
         if ( rc != 0 )
         {
             ERROR("Error unbinding event port");
@@ -197,7 +197,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
     /* Close event channel */
     if ( evtchn_open )
     {
-        rc = xc_evtchn_close(xenaccess->mem_event.xce_handle);
+        rc = xc_evtchn_close(xenaccess->vm_event.xce_handle);
         if ( rc != 0 )
         {
             ERROR("Error closing event channel");
@@ -239,17 +239,17 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     xenaccess->xc_handle = xch;
 
     /* Set domain id */
-    xenaccess->mem_event.domain_id = domain_id;
+    xenaccess->vm_event.domain_id = domain_id;
 
     /* Initialise lock */
-    mem_event_ring_lock_init(&xenaccess->mem_event);
+    vm_event_ring_lock_init(&xenaccess->vm_event);
 
     /* Enable mem_access */
-    xenaccess->mem_event.ring_page =
+    xenaccess->vm_event.ring_page =
             xc_mem_access_enable(xenaccess->xc_handle,
-                                 xenaccess->mem_event.domain_id,
-                                 &xenaccess->mem_event.evtchn_port);
-    if ( xenaccess->mem_event.ring_page == NULL )
+                                 xenaccess->vm_event.domain_id,
+                                 &xenaccess->vm_event.evtchn_port);
+    if ( xenaccess->vm_event.ring_page == NULL )
     {
         switch ( errno ) {
             case EBUSY:
@@ -267,8 +267,8 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     mem_access_enable = 1;
 
     /* Open event channel */
-    xenaccess->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
-    if ( xenaccess->mem_event.xce_handle == NULL )
+    xenaccess->vm_event.xce_handle = xc_evtchn_open(NULL, 0);
+    if ( xenaccess->vm_event.xce_handle == NULL )
     {
         ERROR("Failed to open event channel");
         goto err;
@@ -276,21 +276,21 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     evtchn_open = 1;
 
     /* Bind event notification */
-    rc = xc_evtchn_bind_interdomain(xenaccess->mem_event.xce_handle,
-                                    xenaccess->mem_event.domain_id,
-                                    xenaccess->mem_event.evtchn_port);
+    rc = xc_evtchn_bind_interdomain(xenaccess->vm_event.xce_handle,
+                                    xenaccess->vm_event.domain_id,
+                                    xenaccess->vm_event.evtchn_port);
     if ( rc < 0 )
     {
         ERROR("Failed to bind event channel");
         goto err;
     }
     evtchn_bind = 1;
-    xenaccess->mem_event.port = rc;
+    xenaccess->vm_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,
+    SHARED_RING_INIT((vm_event_sring_t *)xenaccess->vm_event.ring_page);
+    BACK_RING_INIT(&xenaccess->vm_event.back_ring,
+                   (vm_event_sring_t *)xenaccess->vm_event.ring_page,
                    XC_PAGE_SIZE);
 
     /* Get domaininfo */
@@ -320,14 +320,14 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
     return NULL;
 }
 
-int get_request(mem_event_t *mem_event, mem_event_request_t *req)
+int get_request(vm_event_t *vm_event, vm_event_request_t *req)
 {
-    mem_event_back_ring_t *back_ring;
+    vm_event_back_ring_t *back_ring;
     RING_IDX req_cons;
 
-    mem_event_ring_lock(mem_event);
+    vm_event_ring_lock(vm_event);
 
-    back_ring = &mem_event->back_ring;
+    back_ring = &vm_event->back_ring;
     req_cons = back_ring->req_cons;
 
     /* Copy request */
@@ -338,19 +338,19 @@ int get_request(mem_event_t *mem_event, mem_event_request_t *req)
     back_ring->req_cons = req_cons;
     back_ring->sring->req_event = req_cons + 1;
 
-    mem_event_ring_unlock(mem_event);
+    vm_event_ring_unlock(vm_event);
 
     return 0;
 }
 
-static int put_response(mem_event_t *mem_event, mem_event_response_t *rsp)
+static int put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
 {
-    mem_event_back_ring_t *back_ring;
+    vm_event_back_ring_t *back_ring;
     RING_IDX rsp_prod;
 
-    mem_event_ring_lock(mem_event);
+    vm_event_ring_lock(vm_event);
 
-    back_ring = &mem_event->back_ring;
+    back_ring = &vm_event->back_ring;
     rsp_prod = back_ring->rsp_prod_pvt;
 
     /* Copy response */
@@ -361,24 +361,24 @@ static int put_response(mem_event_t *mem_event, mem_event_response_t *rsp)
     back_ring->rsp_prod_pvt = rsp_prod;
     RING_PUSH_RESPONSES(back_ring);
 
-    mem_event_ring_unlock(mem_event);
+    vm_event_ring_unlock(vm_event);
 
     return 0;
 }
 
-static int xenaccess_resume_page(xenaccess_t *paging, mem_event_response_t *rsp)
+static int xenaccess_resume_page(xenaccess_t *paging, vm_event_response_t *rsp)
 {
     int ret;
 
     /* Put the page info on the ring */
-    ret = put_response(&paging->mem_event, rsp);
+    ret = put_response(&paging->vm_event, rsp);
     if ( ret != 0 )
         goto out;
 
     /* Tell Xen page is ready */
-    ret = xc_mem_access_resume(paging->xc_handle, paging->mem_event.domain_id);
-    ret = xc_evtchn_notify(paging->mem_event.xce_handle,
-                           paging->mem_event.port);
+    ret = xc_mem_access_resume(paging->xc_handle, paging->vm_event.domain_id);
+    ret = xc_evtchn_notify(paging->vm_event.xce_handle,
+                           paging->vm_event.port);
 
  out:
     return ret;
@@ -400,8 +400,8 @@ int main(int argc, char *argv[])
     struct sigaction act;
     domid_t domain_id;
     xenaccess_t *xenaccess;
-    mem_event_request_t req;
-    mem_event_response_t rsp;
+    vm_event_request_t req;
+    vm_event_response_t rsp;
     int rc = -1;
     int rc1;
     xc_interface *xch;
@@ -507,7 +507,7 @@ int main(int argc, char *argv[])
         rc = xc_hvm_param_set(xch, domain_id, HVM_PARAM_MEMORY_EVENT_INT3, HVMPME_mode_disabled);
     if ( rc < 0 )
     {
-        ERROR("Error %d setting int3 mem_event\n", rc);
+        ERROR("Error %d setting int3 vm_event\n", rc);
         goto exit;
     }
 
@@ -527,7 +527,7 @@ int main(int argc, char *argv[])
             shutting_down = 1;
         }
 
-        rc = xc_wait_for_event_or_timeout(xch, xenaccess->mem_event.xce_handle, 100);
+        rc = xc_wait_for_event_or_timeout(xch, xenaccess->vm_event.xce_handle, 100);
         if ( rc < -1 )
         {
             ERROR("Error getting event");
@@ -539,11 +539,11 @@ int main(int argc, char *argv[])
             DPRINTF("Got event from Xen\n");
         }
 
-        while ( RING_HAS_UNCONSUMED_REQUESTS(&xenaccess->mem_event.back_ring) )
+        while ( RING_HAS_UNCONSUMED_REQUESTS(&xenaccess->vm_event.back_ring) )
         {
             xenmem_access_t access;
 
-            rc = get_request(&xenaccess->mem_event, &req);
+            rc = get_request(&xenaccess->vm_event, &req);
             if ( rc != 0 )
             {
                 ERROR("Error getting request");
@@ -556,7 +556,7 @@ int main(int argc, char *argv[])
             rsp.flags = req.flags;
 
             switch (req.reason) {
-            case MEM_EVENT_REASON_MEM_ACCESS_VIOLATION:
+            case VM_EVENT_REASON_MEM_ACCESS_VIOLATION:
                 rc = xc_get_mem_access(xch, domain_id, req.mem_access_event.gfn, &access);
                 if (rc < 0)
                 {
@@ -594,7 +594,7 @@ int main(int argc, char *argv[])
 
                 rsp.mem_access_event.gfn = req.mem_access_event.gfn;
                 break;
-            case MEM_EVENT_REASON_INT3:
+            case VM_EVENT_REASON_INT3:
                 printf("INT3: rip=%016"PRIx64", gfn=%"PRIx64" (vcpu %d)\n",
                        req.int3_event.gla,
                        req.int3_event.gfn,
diff --git a/tools/xenpaging/pagein.c b/tools/xenpaging/pagein.c
index b3bcef7..7cb0f33 100644
--- a/tools/xenpaging/pagein.c
+++ b/tools/xenpaging/pagein.c
@@ -63,7 +63,7 @@ void page_in_trigger(void)
 
 void create_page_in_thread(struct xenpaging *paging)
 {
-    page_in_args.dom = paging->mem_event.domain_id;
+    page_in_args.dom = paging->vm_event.domain_id;
     page_in_args.pagein_queue = paging->pagein_queue;
     page_in_args.xch = paging->xc_handle;
     if (pthread_create(&page_in_thread, NULL, page_in, &page_in_args) == 0)
diff --git a/tools/xenpaging/xenpaging.c b/tools/xenpaging/xenpaging.c
index 148b3e7..3031d1e 100644
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -63,7 +63,7 @@ static void close_handler(int sig)
 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;
+    domid_t domain_id = paging->vm_event.domain_id;
     char path[80];
 
     sprintf(path, "/local/domain/0/device-model/%u/command", domain_id);
@@ -74,7 +74,7 @@ static void xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
 static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
-    xc_evtchn *xce = paging->mem_event.xce_handle;
+    xc_evtchn *xce = paging->vm_event.xce_handle;
     char **vec, *val;
     unsigned int num;
     struct pollfd fd[2];
@@ -111,7 +111,7 @@ static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
             if ( strcmp(vec[XS_WATCH_TOKEN], watch_token) == 0 )
             {
                 /* If our guest disappeared, set interrupt flag and fall through */
-                if ( xs_is_domain_introduced(paging->xs_handle, paging->mem_event.domain_id) == false )
+                if ( xs_is_domain_introduced(paging->xs_handle, paging->vm_event.domain_id) == false )
                 {
                     xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
                     interrupted = SIGQUIT;
@@ -171,7 +171,7 @@ static int xenpaging_get_tot_pages(struct xenpaging *paging)
     xc_domaininfo_t domain_info;
     int rc;
 
-    rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1, &domain_info);
+    rc = xc_domain_getinfolist(xch, paging->vm_event.domain_id, 1, &domain_info);
     if ( rc != 1 )
     {
         PERROR("Error getting domain info");
@@ -231,7 +231,7 @@ static int xenpaging_getopts(struct xenpaging *paging, int argc, char *argv[])
     {
         switch(ch) {
         case 'd':
-            paging->mem_event.domain_id = atoi(optarg);
+            paging->vm_event.domain_id = atoi(optarg);
             break;
         case 'f':
             filename = strdup(optarg);
@@ -264,7 +264,7 @@ static int xenpaging_getopts(struct xenpaging *paging, int argc, char *argv[])
     }
 
     /* Set domain id */
-    if ( !paging->mem_event.domain_id )
+    if ( !paging->vm_event.domain_id )
     {
         printf("Numerical <domain_id> missing!\n");
         return 1;
@@ -312,7 +312,7 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
     }
 
     /* write domain ID to watch so we can ignore other domain shutdowns */
-    snprintf(watch_token, sizeof(watch_token), "%u", paging->mem_event.domain_id);
+    snprintf(watch_token, sizeof(watch_token), "%u", paging->vm_event.domain_id);
     if ( xs_watch(paging->xs_handle, "@releaseDomain", watch_token) == false )
     {
         PERROR("Could not bind to shutdown watch\n");
@@ -320,7 +320,7 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
     }
 
     /* Watch xenpagings working target */
-    dom_path = xs_get_domain_path(paging->xs_handle, paging->mem_event.domain_id);
+    dom_path = xs_get_domain_path(paging->xs_handle, paging->vm_event.domain_id);
     if ( !dom_path )
     {
         PERROR("Could not find domain path\n");
@@ -339,17 +339,17 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
     }
 
     /* Map the ring page */
-    xc_get_hvm_param(xch, paging->mem_event.domain_id, 
+    xc_get_hvm_param(xch, paging->vm_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, 
+    paging->vm_event.ring_page = 
+        xc_map_foreign_batch(xch, paging->vm_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(paging->xc_handle, 
-                                              paging->mem_event.domain_id,
+                                              paging->vm_event.domain_id,
                                               1, 0, 0, &ring_pfn);
         if ( rc != 0 )
         {
@@ -358,8 +358,8 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
         }
 
         mmap_pfn = ring_pfn;
-        paging->mem_event.ring_page = 
-            xc_map_foreign_batch(xch, paging->mem_event.domain_id, 
+        paging->vm_event.ring_page = 
+            xc_map_foreign_batch(xch, paging->vm_event.domain_id, 
                                     PROT_READ | PROT_WRITE, &mmap_pfn, 1);
         if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
         {
@@ -369,8 +369,8 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
     }
     
     /* Initialise Xen */
-    rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id,
-                             &paging->mem_event.evtchn_port);
+    rc = xc_mem_paging_enable(xch, paging->vm_event.domain_id,
+                             &paging->vm_event.evtchn_port);
     if ( rc != 0 )
     {
         switch ( errno ) {
@@ -394,40 +394,40 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
     }
 
     /* Open event channel */
-    paging->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
-    if ( paging->mem_event.xce_handle == NULL )
+    paging->vm_event.xce_handle = xc_evtchn_open(NULL, 0);
+    if ( paging->vm_event.xce_handle == NULL )
     {
         PERROR("Failed to open event channel");
         goto err;
     }
 
     /* Bind event notification */
-    rc = xc_evtchn_bind_interdomain(paging->mem_event.xce_handle,
-                                    paging->mem_event.domain_id,
-                                    paging->mem_event.evtchn_port);
+    rc = xc_evtchn_bind_interdomain(paging->vm_event.xce_handle,
+                                    paging->vm_event.domain_id,
+                                    paging->vm_event.evtchn_port);
     if ( rc < 0 )
     {
         PERROR("Failed to bind event channel");
         goto err;
     }
 
-    paging->mem_event.port = rc;
+    paging->vm_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,
+    SHARED_RING_INIT((vm_event_sring_t *)paging->vm_event.ring_page);
+    BACK_RING_INIT(&paging->vm_event.back_ring,
+                   (vm_event_sring_t *)paging->vm_event.ring_page,
                    PAGE_SIZE);
 
     /* Now that the ring is set, remove it from the guest's physmap */
     if ( xc_domain_decrease_reservation_exact(xch, 
-                    paging->mem_event.domain_id, 1, 0, &ring_pfn) )
+                    paging->vm_event.domain_id, 1, 0, &ring_pfn) )
         PERROR("Failed to remove ring from guest physmap");
 
     /* Get max_pages from guest if not provided via cmdline */
     if ( !paging->max_pages )
     {
-        rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1,
+        rc = xc_domain_getinfolist(xch, paging->vm_event.domain_id, 1,
                                    &domain_info);
         if ( rc != 1 )
         {
@@ -497,9 +497,9 @@ static struct xenpaging *xenpaging_init(int argc, char *argv[])
             free(paging->paging_buffer);
         }
 
-        if ( paging->mem_event.ring_page )
+        if ( paging->vm_event.ring_page )
         {
-            munmap(paging->mem_event.ring_page, PAGE_SIZE);
+            munmap(paging->vm_event.ring_page, PAGE_SIZE);
         }
 
         free(dom_path);
@@ -524,28 +524,28 @@ static void xenpaging_teardown(struct xenpaging *paging)
 
     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);
+    munmap(paging->vm_event.ring_page, PAGE_SIZE);
+    rc = xc_mem_paging_disable(xch, paging->vm_event.domain_id);
     if ( rc != 0 )
     {
         PERROR("Error tearing down domain paging in xen");
     }
 
     /* Unbind VIRQ */
-    rc = xc_evtchn_unbind(paging->mem_event.xce_handle, paging->mem_event.port);
+    rc = xc_evtchn_unbind(paging->vm_event.xce_handle, paging->vm_event.port);
     if ( rc != 0 )
     {
         PERROR("Error unbinding event port");
     }
-    paging->mem_event.port = -1;
+    paging->vm_event.port = -1;
 
     /* Close event channel */
-    rc = xc_evtchn_close(paging->mem_event.xce_handle);
+    rc = xc_evtchn_close(paging->vm_event.xce_handle);
     if ( rc != 0 )
     {
         PERROR("Error closing event channel");
     }
-    paging->mem_event.xce_handle = NULL;
+    paging->vm_event.xce_handle = NULL;
     
     /* Close connection to xenstore */
     xs_close(paging->xs_handle);
@@ -558,12 +558,12 @@ static void xenpaging_teardown(struct xenpaging *paging)
     }
 }
 
-static void get_request(struct mem_event *mem_event, mem_event_request_t *req)
+static void get_request(struct vm_event *vm_event, vm_event_request_t *req)
 {
-    mem_event_back_ring_t *back_ring;
+    vm_event_back_ring_t *back_ring;
     RING_IDX req_cons;
 
-    back_ring = &mem_event->back_ring;
+    back_ring = &vm_event->back_ring;
     req_cons = back_ring->req_cons;
 
     /* Copy request */
@@ -575,12 +575,12 @@ static void get_request(struct mem_event *mem_event, mem_event_request_t *req)
     back_ring->sring->req_event = req_cons + 1;
 }
 
-static void put_response(struct mem_event *mem_event, mem_event_response_t *rsp)
+static void put_response(struct vm_event *vm_event, vm_event_response_t *rsp)
 {
-    mem_event_back_ring_t *back_ring;
+    vm_event_back_ring_t *back_ring;
     RING_IDX rsp_prod;
 
-    back_ring = &mem_event->back_ring;
+    back_ring = &vm_event->back_ring;
     rsp_prod = back_ring->rsp_prod_pvt;
 
     /* Copy response */
@@ -607,7 +607,7 @@ static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int
     DECLARE_DOMCTL;
 
     /* Nominate page */
-    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
+    ret = xc_mem_paging_nominate(xch, paging->vm_event.domain_id, gfn);
     if ( ret < 0 )
     {
         /* unpageable gfn is indicated by EBUSY */
@@ -619,7 +619,7 @@ static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int
     }
 
     /* Map page */
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
+    page = xc_map_foreign_pages(xch, paging->vm_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
         PERROR("Error mapping page %lx", gfn);
@@ -641,7 +641,7 @@ static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
-    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
+    ret = xc_mem_paging_evict(xch, paging->vm_event.domain_id, gfn);
     if ( ret < 0 )
     {
         /* A gfn in use is indicated by EBUSY */
@@ -671,10 +671,10 @@ static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int
     return ret;
 }
 
-static int xenpaging_resume_page(struct xenpaging *paging, mem_event_response_t *rsp, int notify_policy)
+static int xenpaging_resume_page(struct xenpaging *paging, vm_event_response_t *rsp, int notify_policy)
 {
     /* Put the page info on the ring */
-    put_response(&paging->mem_event, rsp);
+    put_response(&paging->vm_event, rsp);
 
     /* Notify policy of page being paged in */
     if ( notify_policy )
@@ -693,7 +693,7 @@ static int xenpaging_resume_page(struct xenpaging *paging, mem_event_response_t
     }
 
     /* Tell Xen page is ready */
-    return xc_evtchn_notify(paging->mem_event.xce_handle, paging->mem_event.port);
+    return xc_evtchn_notify(paging->vm_event.xce_handle, paging->vm_event.port);
 }
 
 static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int i)
@@ -715,7 +715,7 @@ static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn,
     do
     {
         /* Tell Xen to allocate a page for the domain */
-        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn, paging->paging_buffer);
+        ret = xc_mem_paging_load(xch, paging->vm_event.domain_id, gfn, paging->paging_buffer);
         if ( ret < 0 )
         {
             if ( errno == ENOMEM )
@@ -857,8 +857,8 @@ int main(int argc, char *argv[])
 {
     struct sigaction act;
     struct xenpaging *paging;
-    mem_event_request_t req;
-    mem_event_response_t rsp;
+    vm_event_request_t req;
+    vm_event_response_t rsp;
     int num, prev_num = 0;
     int slot;
     int tot_pages;
@@ -874,7 +874,7 @@ int main(int argc, char *argv[])
     }
     xch = paging->xc_handle;
 
-    DPRINTF("starting %s for domain_id %u with pagefile %s\n", argv[0], paging->mem_event.domain_id, filename);
+    DPRINTF("starting %s for domain_id %u with pagefile %s\n", argv[0], paging->vm_event.domain_id, filename);
 
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
@@ -903,12 +903,12 @@ int main(int argc, char *argv[])
             DPRINTF("Got event from Xen\n");
         }
 
-        while ( RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
+        while ( RING_HAS_UNCONSUMED_REQUESTS(&paging->vm_event.back_ring) )
         {
             /* Indicate possible error */
             rc = 1;
 
-            get_request(&paging->mem_event, &req);
+            get_request(&paging->vm_event, &req);
 
             if ( req.mem_paging_event.gfn > paging->max_pages )
             {
@@ -929,7 +929,7 @@ int main(int argc, char *argv[])
                     goto out;
                 }
 
-                if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
+                if ( req.flags & VM_EVENT_FLAG_DROP_PAGE )
                 {
                     DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.mem_paging_event.gfn, slot);
                     /* Notify policy of page being dropped */
@@ -966,13 +966,13 @@ int main(int argc, char *argv[])
             {
                 DPRINTF("page %s populated (domain = %d; vcpu = %d;"
                         " gfn = %"PRIx64"; paused = %d; evict_fail = %d)\n",
-                        req.flags & MEM_EVENT_FLAG_EVICT_FAIL ? "not" : "already",
-                        paging->mem_event.domain_id, req.vcpu_id, req.mem_paging_event.gfn,
-                        !!(req.flags & MEM_EVENT_FLAG_VCPU_PAUSED) ,
-                        !!(req.flags & MEM_EVENT_FLAG_EVICT_FAIL) );
+                        req.flags & VM_EVENT_FLAG_EVICT_FAIL ? "not" : "already",
+                        paging->vm_event.domain_id, req.vcpu_id, req.mem_paging_event.gfn,
+                        !!(req.flags & VM_EVENT_FLAG_VCPU_PAUSED) ,
+                        !!(req.flags & VM_EVENT_FLAG_EVICT_FAIL) );
 
                 /* Tell Xen to resume the vcpu */
-                if (( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) || ( req.flags & MEM_EVENT_FLAG_EVICT_FAIL ))
+                if (( req.flags & VM_EVENT_FLAG_VCPU_PAUSED ) || ( req.flags & VM_EVENT_FLAG_EVICT_FAIL ))
                 {
                     /* Prepare the response */
                     rsp.mem_paging_event.gfn = req.mem_paging_event.gfn;
diff --git a/tools/xenpaging/xenpaging.h b/tools/xenpaging/xenpaging.h
index 877db2f..25d511d 100644
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -27,15 +27,15 @@
 
 #include <xc_private.h>
 #include <xen/event_channel.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 
 #define XENPAGING_PAGEIN_QUEUE_SIZE 64
 
-struct mem_event {
+struct vm_event {
     domid_t domain_id;
     xc_evtchn *xce_handle;
     int port;
-    mem_event_back_ring_t back_ring;
+    vm_event_back_ring_t back_ring;
     uint32_t evtchn_port;
     void *ring_page;
 };
@@ -51,7 +51,7 @@ struct xenpaging {
 
     void *paging_buffer;
 
-    struct mem_event mem_event;
+    struct vm_event vm_event;
     int fd;
     /* number of pages for which data structures were allocated */
     int max_pages;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 73d01bb..7f30032 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -432,7 +432,7 @@ int vcpu_initialise(struct vcpu *v)
     v->arch.flags = TF_kernel_mode;
 
     /* By default, do not emulate */
-    v->arch.mem_event.emulate_flags = 0;
+    v->arch.vm_event.emulate_flags = 0;
 
     rc = mapcache_vcpu_init(v);
     if ( rc )
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 82365a4..3951ed3 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -30,8 +30,8 @@
 #include <xen/hypercall.h> /* for arch_do_domctl */
 #include <xsm/xsm.h>
 #include <xen/iommu.h>
-#include <xen/mem_event.h>
-#include <public/mem_event.h>
+#include <xen/vm_event.h>
+#include <public/vm_event.h>
 #include <asm/mem_sharing.h>
 #include <asm/xstate.h>
 #include <asm/debugger.h>
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 14c1847..218f6aa 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1401,7 +1401,7 @@ int hvm_emulate_one_no_write(
     return _hvm_emulate_one(hvmemul_ctxt, &hvm_emulate_ops_no_write);
 }
 
-void hvm_mem_event_emulate_one(bool_t nowrite, unsigned int trapnr,
+void hvm_mem_access_emulate_one(bool_t nowrite, unsigned int trapnr,
     unsigned int errcode)
 {
     struct hvm_emulate_ctxt ctx = {{ 0 }};
@@ -1418,7 +1418,7 @@ void hvm_mem_event_emulate_one(bool_t nowrite, unsigned int trapnr,
     {
     case X86EMUL_RETRY:
         /*
-         * This function is called when handling an EPT-related mem_event
+         * This function is called when handling an EPT-related vm_event
          * reply. As such, nothing else needs to be done here, since simply
          * returning makes the current instruction cause a page fault again,
          * consistent with X86EMUL_RETRY.
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 9140a2a..5d636e9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -35,7 +35,7 @@
 #include <xen/paging.h>
 #include <xen/cpu.h>
 #include <xen/wait.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/mem_access.h>
 #include <xen/rangeset.h>
 #include <asm/shadow.h>
@@ -66,7 +66,7 @@
 #include <public/hvm/ioreq.h>
 #include <public/version.h>
 #include <public/memory.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <public/arch-x86/cpuid.h>
 
 bool_t __read_mostly hvm_enabled;
@@ -2718,7 +2718,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
     struct p2m_domain *p2m;
     int rc, fall_through = 0, paged = 0;
     int sharing_enomem = 0;
-    mem_event_request_t *req_ptr = NULL;
+    vm_event_request_t *req_ptr = NULL;
 
     /* On Nested Virtualization, walk the guest page table.
      * If this succeeds, all is fine.
@@ -2788,7 +2788,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
     {
         bool_t violation;
 
-        /* If the access is against the permissions, then send to mem_event */
+        /* If the access is against the permissions, then send to vm_event */
         switch (p2ma)
         {
         case p2m_access_n:
@@ -6153,7 +6153,7 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
     return rc;
 }
 
-static void hvm_event_fill_regs(mem_event_request_t *req)
+static void hvm_event_fill_regs(vm_event_request_t *req)
 {
     const struct cpu_user_regs *regs = guest_cpu_user_regs();
     const struct vcpu *curr = current;
@@ -6185,7 +6185,7 @@ static void hvm_event_fill_regs(mem_event_request_t *req)
     req->x86_regs.cr4 = curr->arch.hvm_vcpu.guest_cr[4];
 }
 
-static int hvm_event_traps(long parameters, mem_event_request_t *req)
+static int hvm_event_traps(long parameters, vm_event_request_t *req)
 {
     int rc;
     struct vcpu *v = current;
@@ -6194,7 +6194,7 @@ static int hvm_event_traps(long parameters, mem_event_request_t *req)
     if ( !(parameters & HVMPME_MODE_MASK) )
         return 0;
 
-    rc = mem_event_claim_slot(d, &d->mem_event->monitor);
+    rc = vm_event_claim_slot(d, &d->vm_event->monitor);
     if ( rc == -ENOSYS )
     {
         /* If there was no ring to handle the event, then
@@ -6206,20 +6206,20 @@ static int hvm_event_traps(long parameters, mem_event_request_t *req)
 
     if ( (parameters & HVMPME_MODE_MASK) == HVMPME_mode_sync )
     {
-        req->flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-        mem_event_vcpu_pause(v);
+        req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
+        vm_event_vcpu_pause(v);
     }
 
     hvm_event_fill_regs(req);
-    mem_event_put_request(d, &d->mem_event->monitor, req);
+    vm_event_put_request(d, &d->vm_event->monitor, req);
 
     return 1;
 }
 
 void hvm_event_cr0(unsigned long value, unsigned long old)
 {
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_CR0,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_CR0,
         .vcpu_id = current->vcpu_id,
         .cr_event.new_value = value,
         .cr_event.old_value = old
@@ -6236,8 +6236,8 @@ void hvm_event_cr0(unsigned long value, unsigned long old)
 
 void hvm_event_cr3(unsigned long value, unsigned long old)
 {
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_CR3,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_CR3,
         .vcpu_id = current->vcpu_id,
         .cr_event.new_value = value,
         .cr_event.old_value = old
@@ -6254,8 +6254,8 @@ void hvm_event_cr3(unsigned long value, unsigned long old)
 
 void hvm_event_cr4(unsigned long value, unsigned long old)
 {
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_CR4,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_CR4,
         .vcpu_id = current->vcpu_id,
         .cr_event.new_value = value,
         .cr_event.old_value = old
@@ -6272,8 +6272,8 @@ void hvm_event_cr4(unsigned long value, unsigned long old)
 
 void hvm_event_msr(unsigned long msr, unsigned long value)
 {
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_MSR,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MSR,
         .vcpu_id = current->vcpu_id,
         .msr_event.msr = msr,
         .msr_event.new_value = value,
@@ -6287,8 +6287,8 @@ void hvm_event_msr(unsigned long msr, unsigned long value)
 int hvm_event_int3(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_INT3,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_INT3,
         .vcpu_id = current->vcpu_id,
         .int3_event.gla = gla,
         .int3_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
@@ -6302,8 +6302,8 @@ int hvm_event_int3(unsigned long gla)
 int hvm_event_single_step(unsigned long gla)
 {
     uint32_t pfec = PFEC_page_present;
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_SINGLESTEP,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_SINGLESTEP,
         .vcpu_id = current->vcpu_id,
         .singlestep_event.gla = gla,
         .singlestep_event.gfn = paging_gva_to_gfn(current, gla, &pfec)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index e553fb0..0f2b2e6 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -25,7 +25,7 @@
 #include <xen/event.h>
 #include <xen/kernel.h>
 #include <xen/keyhandler.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <asm/current.h>
 #include <asm/cpufeature.h>
 #include <asm/processor.h>
@@ -715,7 +715,7 @@ void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type)
         return;
 
     if ( unlikely(d->arch.hvm_domain.introspection_enabled) &&
-         mem_event_check_ring(&d->mem_event->monitor) )
+         vm_event_check_ring(&d->vm_event->monitor) )
     {
         unsigned int i;
 
diff --git a/xen/arch/x86/mm/hap/nested_ept.c b/xen/arch/x86/mm/hap/nested_ept.c
index cbbc4e9..40adac3 100644
--- a/xen/arch/x86/mm/hap/nested_ept.c
+++ b/xen/arch/x86/mm/hap/nested_ept.c
@@ -17,9 +17,9 @@
  * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
  * Place - Suite 330, Boston, MA 02111-1307 USA.
  */
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/event.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <asm/domain.h>
 #include <asm/page.h>
 #include <asm/paging.h>
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index 9c1ec11..cb28943 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -19,9 +19,9 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/event.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <asm/domain.h>
 #include <asm/page.h>
 #include <asm/paging.h>
diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index f28e65b..aaa72a9 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -22,12 +22,12 @@
 
 
 #include <asm/p2m.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 
 
 int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpc)
 {
-    if ( unlikely(!d->mem_event->paging.ring_page) )
+    if ( unlikely(!d->vm_event->paging.ring_page) )
         return -ENODEV;
 
     switch( mpc->op )
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index c15edcc..b17a0a9 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -28,7 +28,7 @@
 #include <xen/grant_table.h>
 #include <xen/sched.h>
 #include <xen/rcupdate.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <asm/page.h>
 #include <asm/string.h>
 #include <asm/p2m.h>
@@ -559,25 +559,25 @@ int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
 {
     struct vcpu *v = current;
     int rc;
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_MEM_SHARING,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MEM_SHARING,
         .mem_sharing_event.gfn = gfn
     };
 
-    if ( (rc = __mem_event_claim_slot(d, 
-                        &d->mem_event->share, allow_sleep)) < 0 )
+    if ( (rc = __vm_event_claim_slot(d, 
+                        &d->vm_event->share, allow_sleep)) < 0 )
         return rc;
 
     if ( v->domain == d )
     {
-        req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
-        mem_event_vcpu_pause(v);
+        req.flags = VM_EVENT_FLAG_VCPU_PAUSED;
+        vm_event_vcpu_pause(v);
     }
 
     req.mem_sharing_event.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_event->share, &req);
+    vm_event_put_request(d, &d->vm_event->share, &req);
 
     return 0;
 }
@@ -594,14 +594,14 @@ unsigned int mem_sharing_get_nr_shared_mfns(void)
 
 int mem_sharing_sharing_resume(struct domain *d)
 {
-    mem_event_response_t rsp;
+    vm_event_response_t rsp;
 
     /* Get all requests off the ring */
-    while ( mem_event_get_response(d, &d->mem_event->share, &rsp) )
+    while ( vm_event_get_response(d, &d->vm_event->share, &rsp) )
     {
         struct vcpu *v;
 
-        if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
+        if ( rsp.flags & VM_EVENT_FLAG_DUMMY )
             continue;
 
         /* Validate the vcpu_id in the response. */
@@ -611,8 +611,8 @@ int mem_sharing_sharing_resume(struct domain *d)
         v = d->vcpu[rsp.vcpu_id];
 
         /* Unpause domain/vcpu */
-        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-            mem_event_vcpu_unpause(v);
+        if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
+            vm_event_vcpu_unpause(v);
     }
 
     return 0;
@@ -1139,7 +1139,7 @@ err_out:
 
 /* 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
+ *  2. We notify a potential dom0 helper through a vm_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
diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 43f507c..0679f00 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -21,9 +21,9 @@
  */
 
 #include <xen/iommu.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/event.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <asm/domain.h>
 #include <asm/page.h>
 #include <asm/paging.h>
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index e48b63a..654384a 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -26,10 +26,10 @@
  */
 
 #include <xen/iommu.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/event.h>
 #include <xen/trace.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <asm/domain.h>
 #include <asm/page.h>
 #include <asm/paging.h>
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 5c15b14..c69bc36 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -25,9 +25,9 @@
  */
 
 #include <xen/iommu.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/event.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <asm/domain.h>
 #include <asm/page.h>
 #include <asm/paging.h>
@@ -1077,8 +1077,8 @@ int p2m_mem_paging_evict(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 = {
-        .reason = MEM_EVENT_REASON_MEM_PAGING,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MEM_PAGING,
         .mem_paging_event.gfn = gfn
     };
 
@@ -1086,21 +1086,21 @@ void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
      * correctness of the guest execution at this point.  If this is the only
      * page that happens to be paged-out, we'll be okay..  but it's likely the
      * guest will crash shortly anyways. */
-    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    int rc = vm_event_claim_slot(d, &d->vm_event->paging);
     if ( rc < 0 )
         return;
 
     /* Send release notification to pager */
-    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
+    req.flags = VM_EVENT_FLAG_DROP_PAGE;
 
     /* 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;
+        req.flags |= VM_EVENT_FLAG_EVICT_FAIL;
 
-    mem_event_put_request(d, &d->mem_event->paging, &req);
+    vm_event_put_request(d, &d->vm_event->paging, &req);
 }
 
 /**
@@ -1127,8 +1127,8 @@ void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req = {
-        .reason = MEM_EVENT_REASON_MEM_PAGING,
+    vm_event_request_t req = {
+        .reason = VM_EVENT_REASON_MEM_PAGING,
         .mem_paging_event.gfn = gfn
     };
     p2m_type_t p2mt;
@@ -1137,7 +1137,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* We're paging. There should be a ring */
-    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    int rc = vm_event_claim_slot(d, &d->vm_event->paging);
     if ( rc == -ENOSYS )
     {
         gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
@@ -1159,7 +1159,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
     {
         /* Evict will fail now, tag this request for pager */
         if ( p2mt == p2m_ram_paging_out )
-            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
+            req.flags |= VM_EVENT_FLAG_EVICT_FAIL;
 
         p2m_set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
     }
@@ -1168,14 +1168,14 @@ void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
     /* Pause domain if request came from guest and gfn has paging type */
     if ( p2m_is_paging(p2mt) && v->domain == d )
     {
-        mem_event_vcpu_pause(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+        vm_event_vcpu_pause(v);
+        req.flags |= VM_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);
+        vm_event_cancel_slot(d, &d->vm_event->paging);
         return;
     }
 
@@ -1183,7 +1183,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
     req.mem_paging_event.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_event->paging, &req);
+    vm_event_put_request(d, &d->vm_event->paging, &req);
 }
 
 /**
@@ -1292,17 +1292,17 @@ int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
 void p2m_mem_paging_resume(struct domain *d)
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    mem_event_response_t rsp;
+    vm_event_response_t rsp;
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
 
     /* Pull all responses off the ring */
-    while( mem_event_get_response(d, &d->mem_event->paging, &rsp) )
+    while( vm_event_get_response(d, &d->vm_event->paging, &rsp) )
     {
         struct vcpu *v;
 
-        if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
+        if ( rsp.flags & VM_EVENT_FLAG_DUMMY )
             continue;
 
         /* Validate the vcpu_id in the response. */
@@ -1312,7 +1312,7 @@ void p2m_mem_paging_resume(struct domain *d)
         v = d->vcpu[rsp.vcpu_id];
 
         /* Fix p2m entry if the page was not dropped */
-        if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
+        if ( !(rsp.flags & VM_EVENT_FLAG_DROP_PAGE) )
         {
             gfn_lock(p2m, rsp.gfn, 0);
             mfn = p2m->get_entry(p2m, rsp.mem_access_event.gfn, &p2mt, &a, 0, NULL);
@@ -1328,12 +1328,12 @@ void p2m_mem_paging_resume(struct domain *d)
             gfn_unlock(p2m, rsp.gfn, 0);
         }
         /* Unpause domain */
-        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-            mem_event_vcpu_unpause(v);
+        if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
+            vm_event_vcpu_unpause(v);
     }
 }
 
-static void p2m_mem_event_fill_regs(mem_event_request_t *req)
+static void p2m_vm_event_fill_regs(vm_event_request_t *req)
 {
     const struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct segment_register seg;
@@ -1388,10 +1388,10 @@ static void p2m_mem_event_fill_regs(mem_event_request_t *req)
     req->x86_regs.cs_arbytes = seg.attr.bytes;
 }
 
-void p2m_mem_event_emulate_check(struct vcpu *v, const mem_event_response_t *rsp)
+void p2m_mem_access_emulate_check(struct vcpu *v, const vm_event_response_t *rsp)
 {
     /* Mark vcpu for skipping one instruction upon rescheduling. */
-    if ( rsp->flags & MEM_EVENT_FLAG_EMULATE )
+    if ( rsp->flags & VM_EVENT_FLAG_EMULATE )
     {
         xenmem_access_t access;
         bool_t violation = 1;
@@ -1438,7 +1438,7 @@ void p2m_mem_event_emulate_check(struct vcpu *v, const mem_event_response_t *rsp
             }
         }
 
-        v->arch.mem_event.emulate_flags = violation ? rsp->flags : 0;
+        v->arch.vm_event.emulate_flags = violation ? rsp->flags : 0;
     }
 }
 
@@ -1453,7 +1453,7 @@ void p2m_setup_introspection(struct domain *d)
 
 bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
                             struct npfec npfec,
-                            mem_event_request_t **req_ptr)
+                            vm_event_request_t **req_ptr)
 {
     struct vcpu *v = current;
     unsigned long gfn = gpa >> PAGE_SHIFT;
@@ -1462,7 +1462,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
-    mem_event_request_t *req;
+    vm_event_request_t *req;
     int rc;
     unsigned long eip = guest_cpu_user_regs()->eip;
 
@@ -1489,13 +1489,13 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
     gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    if ( !mem_event_check_ring(&d->mem_event->monitor) || !req_ptr ) 
+    if ( !vm_event_check_ring(&d->vm_event->monitor) || !req_ptr ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
         {
             gdprintk(XENLOG_INFO, "Memory access permissions failure, "
-                                  "no mem_event listener VCPU %d, dom %d\n",
+                                  "no vm_event listener VCPU %d, dom %d\n",
                                   v->vcpu_id, d->domain_id);
             domain_crash(v->domain);
             return 0;
@@ -1518,40 +1518,40 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
         }
     }
 
-    /* The previous mem_event reply does not match the current state. */
-    if ( v->arch.mem_event.gpa != gpa || v->arch.mem_event.eip != eip )
+    /* The previous vm_event reply does not match the current state. */
+    if ( v->arch.vm_event.gpa != gpa || v->arch.vm_event.eip != eip )
     {
-        /* Don't emulate the current instruction, send a new mem_event. */
-        v->arch.mem_event.emulate_flags = 0;
+        /* Don't emulate the current instruction, send a new vm_event. */
+        v->arch.vm_event.emulate_flags = 0;
 
         /*
          * Make sure to mark the current state to match it again against
-         * the new mem_event about to be sent.
+         * the new vm_event about to be sent.
          */
-        v->arch.mem_event.gpa = gpa;
-        v->arch.mem_event.eip = eip;
+        v->arch.vm_event.gpa = gpa;
+        v->arch.vm_event.eip = eip;
     }
 
-    if ( v->arch.mem_event.emulate_flags )
+    if ( v->arch.vm_event.emulate_flags )
     {
-        hvm_mem_event_emulate_one((v->arch.mem_event.emulate_flags &
-                                   MEM_EVENT_FLAG_EMULATE_NOWRITE) != 0,
-                                  TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+        hvm_mem_access_emulate_one((v->arch.vm_event.emulate_flags &
+                                    VM_EVENT_FLAG_EMULATE_NOWRITE) != 0,
+                                   TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
 
-        v->arch.mem_event.emulate_flags = 0;
+        v->arch.vm_event.emulate_flags = 0;
         return 1;
     }
 
     *req_ptr = NULL;
-    req = xzalloc(mem_event_request_t);
+    req = xzalloc(vm_event_request_t);
     if ( req )
     {
         *req_ptr = req;
-        req->reason = MEM_EVENT_REASON_MEM_ACCESS_VIOLATION;
+        req->reason = VM_EVENT_REASON_MEM_ACCESS_VIOLATION;
 
         /* Pause the current VCPU */
         if ( p2ma != p2m_access_n2rwx )
-            req->flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+            req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
 
         /* Send request to mem event */
         req->mem_access_event.gfn = gfn;
@@ -1567,12 +1567,12 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
         req->mem_access_event.access_x = npfec.insn_fetch;
         req->vcpu_id = v->vcpu_id;
 
-        p2m_mem_event_fill_regs(req);
+        p2m_vm_event_fill_regs(req);
     }
 
     /* Pause the current VCPU */
     if ( p2ma != p2m_access_n2rwx )
-        mem_event_vcpu_pause(v);
+        vm_event_vcpu_pause(v);
 
     /* VCPU may be paused, return whether we promoted automatically */
     return (p2ma == p2m_access_n2rwx);
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index 229d1ea..62eaaf7 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -1,5 +1,5 @@
 #include <xen/event.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/mem_access.h>
 #include <xen/multicall.h>
 #include <compat/memory.h>
@@ -192,7 +192,7 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         xen_mem_paging_op_t mpo;
         if ( copy_from_guest(&mpo, arg, 1) )
             return -EFAULT;
-        rc = do_mem_event_op(op, mpo.domain, (void *) &mpo);
+        rc = do_vm_event_op(op, mpo.domain, (void *) &mpo);
         if ( !rc && __copy_to_guest(arg, &mpo, 1) )
             return -EFAULT;
         break;
@@ -205,7 +205,7 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             return -EFAULT;
         if ( mso.op == XENMEM_sharing_op_audit )
             return mem_sharing_audit(); 
-        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        rc = do_vm_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && __copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
         break;
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 33d5ec9..fcdfc05 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -26,7 +26,7 @@
 #include <xen/nodemask.h>
 #include <xen/guest_access.h>
 #include <xen/hypercall.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/mem_access.h>
 #include <asm/current.h>
 #include <asm/asm_defns.h>
@@ -989,7 +989,7 @@ long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         xen_mem_paging_op_t mpo;
         if ( copy_from_guest(&mpo, arg, 1) )
             return -EFAULT;
-        rc = do_mem_event_op(op, mpo.domain, (void *) &mpo);
+        rc = do_vm_event_op(op, mpo.domain, (void *) &mpo);
         if ( !rc && __copy_to_guest(arg, &mpo, 1) )
             return -EFAULT;
         break;
@@ -1002,7 +1002,7 @@ long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             return -EFAULT;
         if ( mso.op == XENMEM_sharing_op_audit )
             return mem_sharing_audit(); 
-        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        rc = do_vm_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && __copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
         break;
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 8391246..f1b73a3 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -54,7 +54,7 @@ obj-y += rbtree.o
 obj-y += lzo.o
 obj-$(HAS_PDX) += pdx.o
 obj-$(HAS_MEM_ACCESS) += mem_access.o
-obj-$(HAS_MEM_ACCESS) += mem_event.o
+obj-$(HAS_MEM_ACCESS) += vm_event.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo unlz4 earlycpio,$(n).init.o)
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 4a62c1d..ec896946 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -15,7 +15,7 @@
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <xen/time.h>
 #include <xen/console.h>
 #include <xen/softirq.h>
@@ -343,8 +343,8 @@ struct domain *domain_create(
         poolid = 0;
 
         err = -ENOMEM;
-        d->mem_event = xzalloc(struct mem_event_per_domain);
-        if ( !d->mem_event )
+        d->vm_event = xzalloc(struct vm_event_per_domain);
+        if ( !d->vm_event )
             goto fail;
 
         d->pbuf = xzalloc_array(char, DOMAIN_PBUF_SIZE);
@@ -386,7 +386,7 @@ struct domain *domain_create(
     if ( hardware_domain == d )
         hardware_domain = old_hwdom;
     atomic_set(&d->refcnt, DOMAIN_DESTROYED);
-    xfree(d->mem_event);
+    xfree(d->vm_event);
     xfree(d->pbuf);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
@@ -628,7 +628,7 @@ int domain_kill(struct domain *d)
         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);
+        vm_event_cleanup(d);
         put_domain(d);
         send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
@@ -807,7 +807,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_xenoprof_pages(d);
 #endif
 
-    xfree(d->mem_event);
+    xfree(d->vm_event);
     xfree(d->pbuf);
 
     for ( i = d->max_vcpus - 1; i >= 0; i-- )
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d9c2635..2beb03c 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -24,7 +24,7 @@
 #include <xen/bitmap.h>
 #include <xen/paging.h>
 #include <xen/hypercall.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <asm/current.h>
 #include <asm/irq.h>
 #include <asm/page.h>
@@ -1113,8 +1113,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     }
     break;
 
-    case XEN_DOMCTL_mem_event_op:
-        ret = mem_event_domctl(d, &op->u.mem_event_op,
+    case XEN_DOMCTL_vm_event_op:
+        ret = vm_event_domctl(d, &op->u.vm_event_op,
                                guest_handle_cast(u_domctl, void));
         copyback = 1;
         break;
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index 0a4fe51..01e353d 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -24,21 +24,21 @@
 #include <xen/sched.h>
 #include <xen/guest_access.h>
 #include <xen/hypercall.h>
-#include <xen/mem_event.h>
+#include <xen/vm_event.h>
 #include <public/memory.h>
 #include <asm/p2m.h>
 #include <xsm/xsm.h>
 
 void mem_access_resume(struct domain *d)
 {
-    mem_event_response_t rsp;
+    vm_event_response_t rsp;
 
     /* Pull all responses off the ring. */
-    while ( mem_event_get_response(d, &d->mem_event->monitor, &rsp) )
+    while ( vm_event_get_response(d, &d->vm_event->monitor, &rsp) )
     {
         struct vcpu *v;
 
-        if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
+        if ( rsp.flags & VM_EVENT_FLAG_DUMMY )
             continue;
 
         /* Validate the vcpu_id in the response. */
@@ -47,11 +47,11 @@ void mem_access_resume(struct domain *d)
 
         v = d->vcpu[rsp.vcpu_id];
 
-        p2m_mem_event_emulate_check(v, &rsp);
+        p2m_mem_access_emulate_check(v, &rsp);
 
         /* Unpause domain. */
-        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-            mem_event_vcpu_unpause(v);
+        if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
+            vm_event_vcpu_unpause(v);
     }
 }
 
@@ -73,12 +73,12 @@ int mem_access_memop(unsigned long cmd,
     if ( !p2m_mem_access_sanity_check(d) )
         goto out;
 
-    rc = xsm_mem_event_op(XSM_DM_PRIV, d, XENMEM_access_op);
+    rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_access_op);
     if ( rc )
         goto out;
 
     rc = -ENODEV;
-    if ( unlikely(!d->mem_event->monitor.ring_page) )
+    if ( unlikely(!d->vm_event->monitor.ring_page) )
         goto out;
 
     switch ( mao.op )
@@ -138,13 +138,13 @@ int mem_access_memop(unsigned long cmd,
     return rc;
 }
 
-int mem_access_send_req(struct domain *d, mem_event_request_t *req)
+int mem_access_send_req(struct domain *d, vm_event_request_t *req)
 {
-    int rc = mem_event_claim_slot(d, &d->mem_event->monitor);
+    int rc = vm_event_claim_slot(d, &d->vm_event->monitor);
     if ( rc < 0 )
         return rc;
 
-    mem_event_put_request(d, &d->mem_event->monitor, req);
+    vm_event_put_request(d, &d->vm_event->monitor, req);
 
     return 0;
 }
diff --git a/xen/common/mem_event.c b/xen/common/mem_event.c
deleted file mode 100644
index b99e7d5..0000000
--- a/xen/common/mem_event.c
+++ /dev/null
@@ -1,742 +0,0 @@
-/******************************************************************************
- * mem_event.c
- *
- * Memory event support.
- *
- * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-
-
-#include <xen/sched.h>
-#include <xen/event.h>
-#include <xen/wait.h>
-#include <xen/mem_event.h>
-#include <xen/mem_access.h>
-#include <asm/p2m.h>
-
-#ifdef HAS_MEM_PAGING
-#include <asm/mem_paging.h>
-#endif
-
-#ifdef HAS_MEM_SHARING
-#include <asm/mem_sharing.h>
-#endif
-
-#include <xsm/xsm.h>
-
-/* for public/io/ring.h macros */
-#define xen_mb()   mb()
-#define xen_rmb()  rmb()
-#define xen_wmb()  wmb()
-
-#define mem_event_ring_lock_init(_med)  spin_lock_init(&(_med)->ring_lock)
-#define mem_event_ring_lock(_med)       spin_lock(&(_med)->ring_lock)
-#define mem_event_ring_unlock(_med)     spin_unlock(&(_med)->ring_lock)
-
-static int mem_event_enable(
-    struct domain *d,
-    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;
-    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.
-     */
-    if ( med->ring_page )
-        return -EBUSY;
-
-    /* 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);
-
-    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;
-
-    /* Allocate event channel */
-    rc = alloc_unbound_xen_event_channel(d->vcpu[0],
-                                         current->domain->domain_id,
-                                         notification_fn);
-    if ( rc < 0 )
-        goto err;
-
-    med->xen_port = mec->port = rc;
-
-    /* Prepare ring buffer */
-    FRONT_RING_INIT(&med->front_ring,
-                    (mem_event_sring_t *)med->ring_page,
-                    PAGE_SIZE);
-
-    /* Save the pause flag for this particular ring. */
-    med->pause_flag = pause_flag;
-
-    /* Initialize the last-chance wait queue. */
-    init_waitqueue_head(&med->wq);
-
-    mem_event_ring_unlock(med);
-    return 0;
-
- err:
-    destroy_ring_for_helper(&med->ring_page,
-                            med->ring_pg_struct);
-    mem_event_ring_unlock(med);
-
-    return rc;
-}
-
-static unsigned int mem_event_ring_available(struct mem_event_domain *med)
-{
-    int avail_req = RING_FREE_REQUESTS(&med->front_ring);
-    avail_req -= med->target_producers;
-    avail_req -= med->foreign_producers;
-
-    BUG_ON(avail_req < 0);
-
-    return avail_req;
-}
-
-/*
- * mem_event_wake_blocked() will wakeup vcpus waiting for room in the
- * ring. These vCPUs were paused on their way out after placing an event,
- * but need to be resumed where the ring is capable of processing at least
- * one event from them.
- */
-static void mem_event_wake_blocked(struct domain *d, struct mem_event_domain *med)
-{
-    struct vcpu *v;
-    int online = d->max_vcpus;
-    unsigned int avail_req = mem_event_ring_available(med);
-
-    if ( avail_req == 0 || med->blocked == 0 )
-        return;
-
-    /*
-     * We ensure that we only have vCPUs online if there are enough free slots
-     * for their memory events to be processed.  This will ensure that no
-     * memory events are lost (due to the fact that certain types of events
-     * cannot be replayed, we need to ensure that there is space in the ring
-     * for when they are hit).
-     * See comment below in mem_event_put_request().
-     */
-    for_each_vcpu ( d, v )
-        if ( test_bit(med->pause_flag, &v->pause_flags) )
-            online--;
-
-    ASSERT(online == (d->max_vcpus - med->blocked));
-
-    /* We remember which vcpu last woke up to avoid scanning always linearly
-     * from zero and starving higher-numbered vcpus under high load */
-    if ( d->vcpu )
-    {
-        int i, j, k;
-
-        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
-        {
-            k = i % d->max_vcpus;
-            v = d->vcpu[k];
-            if ( !v )
-                continue;
-
-            if ( !(med->blocked) || online >= avail_req )
-               break;
-
-            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
-            {
-                vcpu_unpause(v);
-                online++;
-                med->blocked--;
-                med->last_vcpu_wake_up = k;
-            }
-        }
-    }
-}
-
-/*
- * In the event that a vCPU attempted to place an event in the ring and
- * was unable to do so, it is queued on a wait queue.  These are woken as
- * needed, and take precedence over the blocked vCPUs.
- */
-static void mem_event_wake_queued(struct domain *d, struct mem_event_domain *med)
-{
-    unsigned int avail_req = mem_event_ring_available(med);
-
-    if ( avail_req > 0 )
-        wake_up_nr(&med->wq, avail_req);
-}
-
-/*
- * mem_event_wake() will wakeup all vcpus waiting for the ring to
- * become available.  If we have queued vCPUs, they get top priority. We
- * are guaranteed that they will go through code paths that will eventually
- * call mem_event_wake() again, ensuring that any blocked vCPUs will get
- * unpaused once all the queued vCPUs have made it through.
- */
-void mem_event_wake(struct domain *d, struct mem_event_domain *med)
-{
-    if (!list_empty(&med->wq.list))
-        mem_event_wake_queued(d, med);
-    else
-        mem_event_wake_blocked(d, med);
-}
-
-static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
-{
-    if ( med->ring_page )
-    {
-        struct vcpu *v;
-
-        mem_event_ring_lock(med);
-
-        if ( !list_empty(&med->wq.list) )
-        {
-            mem_event_ring_unlock(med);
-            return -EBUSY;
-        }
-
-        /* Free domU's event channel and leave the other one unbound */
-        free_xen_event_channel(d->vcpu[0], med->xen_port);
-
-        /* Unblock all vCPUs */
-        for_each_vcpu ( d, v )
-        {
-            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
-            {
-                vcpu_unpause(v);
-                med->blocked--;
-            }
-        }
-
-        destroy_ring_for_helper(&med->ring_page,
-                                med->ring_pg_struct);
-        mem_event_ring_unlock(med);
-    }
-
-    return 0;
-}
-
-static inline void mem_event_release_slot(struct domain *d,
-                                          struct mem_event_domain *med)
-{
-    /* Update the accounting */
-    if ( current->domain == d )
-        med->target_producers--;
-    else
-        med->foreign_producers--;
-
-    /* Kick any waiters */
-    mem_event_wake(d, med);
-}
-
-/*
- * mem_event_mark_and_pause() tags vcpu and put it to sleep.
- * The vcpu will resume execution in mem_event_wake_waiters().
- */
-void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
-{
-    if ( !test_and_set_bit(med->pause_flag, &v->pause_flags) )
-    {
-        vcpu_pause_nosync(v);
-        med->blocked++;
-    }
-}
-
-/*
- * This must be preceded by a call to claim_slot(), and is guaranteed to
- * succeed.  As a side-effect however, the vCPU may be paused if the ring is
- * overly full and its continued execution would cause stalling and excessive
- * waiting.  The vCPU will be automatically unpaused when the ring clears.
- */
-void mem_event_put_request(struct domain *d,
-                           struct mem_event_domain *med,
-                           mem_event_request_t *req)
-{
-    mem_event_front_ring_t *front_ring;
-    int free_req;
-    unsigned int avail_req;
-    RING_IDX req_prod;
-
-    if ( current->domain != d )
-    {
-        req->flags |= MEM_EVENT_FLAG_FOREIGN;
-#ifndef NDEBUG
-        if ( !(req->flags & MEM_EVENT_FLAG_VCPU_PAUSED) )
-            gdprintk(XENLOG_G_WARNING, "d%dv%d was not paused.\n",
-                     d->domain_id, req->vcpu_id);
-#endif
-    }
-
-    mem_event_ring_lock(med);
-
-    /* Due to the reservations, this step must succeed. */
-    front_ring = &med->front_ring;
-    free_req = RING_FREE_REQUESTS(front_ring);
-    ASSERT(free_req > 0);
-
-    /* Copy request */
-    req_prod = front_ring->req_prod_pvt;
-    memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
-    req_prod++;
-
-    /* Update ring */
-    front_ring->req_prod_pvt = req_prod;
-    RING_PUSH_REQUESTS(front_ring);
-
-    /* We've actually *used* our reservation, so release the slot. */
-    mem_event_release_slot(d, med);
-
-    /* Give this vCPU a black eye if necessary, on the way out.
-     * See the comments above wake_blocked() for more information
-     * on how this mechanism works to avoid waiting. */
-    avail_req = mem_event_ring_available(med);
-    if( current->domain == d && avail_req < d->max_vcpus )
-        mem_event_mark_and_pause(current, med);
-
-    mem_event_ring_unlock(med);
-
-    notify_via_xen_event_channel(d, med->xen_port);
-}
-
-int mem_event_get_response(struct domain *d, struct mem_event_domain *med, mem_event_response_t *rsp)
-{
-    mem_event_front_ring_t *front_ring;
-    RING_IDX rsp_cons;
-
-    mem_event_ring_lock(med);
-
-    front_ring = &med->front_ring;
-    rsp_cons = front_ring->rsp_cons;
-
-    if ( !RING_HAS_UNCONSUMED_RESPONSES(front_ring) )
-    {
-        mem_event_ring_unlock(med);
-        return 0;
-    }
-
-    /* Copy response */
-    memcpy(rsp, RING_GET_RESPONSE(front_ring, rsp_cons), sizeof(*rsp));
-    rsp_cons++;
-
-    /* Update ring */
-    front_ring->rsp_cons = rsp_cons;
-    front_ring->sring->rsp_event = rsp_cons + 1;
-
-    /* Kick any waiters -- since we've just consumed an event,
-     * there may be additional space available in the ring. */
-    mem_event_wake(d, med);
-
-    mem_event_ring_unlock(med);
-
-    return 1;
-}
-
-void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med)
-{
-    mem_event_ring_lock(med);
-    mem_event_release_slot(d, med);
-    mem_event_ring_unlock(med);
-}
-
-static int mem_event_grab_slot(struct mem_event_domain *med, int foreign)
-{
-    unsigned int avail_req;
-
-    if ( !med->ring_page )
-        return -ENOSYS;
-
-    mem_event_ring_lock(med);
-
-    avail_req = mem_event_ring_available(med);
-    if ( avail_req == 0 )
-    {
-        mem_event_ring_unlock(med);
-        return -EBUSY;
-    }
-
-    if ( !foreign )
-        med->target_producers++;
-    else
-        med->foreign_producers++;
-
-    mem_event_ring_unlock(med);
-
-    return 0;
-}
-
-/* Simple try_grab wrapper for use in the wait_event() macro. */
-static int mem_event_wait_try_grab(struct mem_event_domain *med, int *rc)
-{
-    *rc = mem_event_grab_slot(med, 0);
-    return *rc;
-}
-
-/* Call mem_event_grab_slot() until the ring doesn't exist, or is available. */
-static int mem_event_wait_slot(struct mem_event_domain *med)
-{
-    int rc = -EBUSY;
-    wait_event(med->wq, mem_event_wait_try_grab(med, &rc) != -EBUSY);
-    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
- * use mem_event_wait_slot() to reserve a slot.  As long as there is a ring,
- * this function will always return 0 for a guest.  For a non-guest, we check
- * for space and return -EBUSY if the ring is not available.
- *
- * Return codes: -ENOSYS: the ring is not yet configured
- *               -EBUSY: the ring is busy
- *               0: a spot has been reserved
- *
- */
-int __mem_event_claim_slot(struct domain *d, struct mem_event_domain *med,
-                            bool_t allow_sleep)
-{
-    if ( (current->domain == d) && allow_sleep )
-        return mem_event_wait_slot(med);
-    else
-        return mem_event_grab_slot(med, (current->domain != d));
-}
-
-#ifdef HAS_MEM_PAGING
-/* Registered with Xen-bound event channel for incoming notifications. */
-static void mem_paging_notification(struct vcpu *v, unsigned int port)
-{
-    if ( likely(v->domain->mem_event->paging.ring_page != NULL) )
-        p2m_mem_paging_resume(v->domain);
-}
-#endif
-
-#ifdef HAS_MEM_ACCESS
-/* Registered with Xen-bound event channel for incoming notifications. */
-static void mem_access_notification(struct vcpu *v, unsigned int port)
-{
-    if ( likely(v->domain->mem_event->monitor.ring_page != NULL) )
-        mem_access_resume(v->domain);
-}
-#endif
-
-#ifdef HAS_MEM_SHARING
-/* 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);
-}
-#endif
-
-int do_mem_event_op(int op, uint32_t domain, void *arg)
-{
-    int ret;
-    struct domain *d;
-
-    ret = rcu_lock_live_remote_domain_by_id(domain, &d);
-    if ( ret )
-        return ret;
-
-    ret = xsm_mem_event_op(XSM_DM_PRIV, d, op);
-    if ( ret )
-        goto out;
-
-    switch (op)
-    {
-#ifdef HAS_MEM_PAGING
-        case XENMEM_paging_op:
-            ret = mem_paging_memop(d, (xen_mem_paging_op_t *) arg);
-            break;
-#endif
-#ifdef HAS_MEM_SHARING
-        case XENMEM_sharing_op:
-            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
-            break;
-#endif
-        default:
-            ret = -ENOSYS;
-    }
-
- out:
-    rcu_unlock_domain(d);
-    return ret;
-}
-
-/* Clean up on domain destruction */
-void mem_event_cleanup(struct domain *d)
-{
-#ifdef HAS_MEM_PAGING
-    if ( d->mem_event->paging.ring_page ) {
-        /* Destroying the wait queue head means waking up all
-         * queued vcpus. This will drain the list, allowing
-         * the disable routine to complete. It will also drop
-         * all domain refs the wait-queued vcpus are holding.
-         * Finally, because this code path involves previously
-         * pausing the domain (domain_kill), unpausing the
-         * vcpus causes no harm. */
-        destroy_waitqueue_head(&d->mem_event->paging.wq);
-        (void)mem_event_disable(d, &d->mem_event->paging);
-    }
-#endif
-#ifdef HAS_MEM_ACCESS
-    if ( d->mem_event->monitor.ring_page ) {
-        destroy_waitqueue_head(&d->mem_event->monitor.wq);
-        (void)mem_event_disable(d, &d->mem_event->monitor);
-    }
-#endif
-#ifdef HAS_MEM_SHARING
-    if ( d->mem_event->share.ring_page ) {
-        destroy_waitqueue_head(&d->mem_event->share.wq);
-        (void)mem_event_disable(d, &d->mem_event->share);
-    }
-#endif
-}
-
-int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
-{
-    int rc;
-
-    rc = xsm_mem_event_control(XSM_PRIV, d, mec->mode, mec->op);
-    if ( rc )
-        return rc;
-
-    if ( unlikely(d == current->domain) )
-    {
-        gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
-        return -EINVAL;
-    }
-
-    if ( unlikely(d->is_dying) )
-    {
-        gdprintk(XENLOG_INFO, "Ignoring memory event op on dying domain %u\n",
-                 d->domain_id);
-        return 0;
-    }
-
-    if ( unlikely(d->vcpu == NULL) || unlikely(d->vcpu[0] == NULL) )
-    {
-        gdprintk(XENLOG_INFO,
-                 "Memory event op on a domain (%u) with no vcpus\n",
-                 d->domain_id);
-        return -EINVAL;
-    }
-
-    rc = -ENOSYS;
-
-    switch ( mec->mode )
-    {
-#ifdef HAS_MEM_PAGING
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING:
-    {
-        struct mem_event_domain *med = &d->mem_event->paging;
-        rc = -EINVAL;
-
-        switch( mec->op )
-        {
-        case XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE:
-        {
-            struct p2m_domain *p2m = p2m_get_hostp2m(d);
-
-            rc = -EOPNOTSUPP;
-            /* pvh fixme: p2m_is_foreign types need addressing */
-            if ( is_pvh_vcpu(current) || is_pvh_domain(hardware_domain) )
-                break;
-
-            rc = -ENODEV;
-            /* Only HAP is supported */
-            if ( !hap_enabled(d) )
-                break;
-
-            /* No paging if iommu is used */
-            rc = -EMLINK;
-            if ( unlikely(need_iommu(d)) )
-                break;
-
-            rc = -EXDEV;
-            /* Disallow paging in a PoD guest */
-            if ( p2m->pod.entry_count )
-                break;
-
-            rc = mem_event_enable(d, mec, med, _VPF_mem_paging,
-                                    HVM_PARAM_PAGING_RING_PFN,
-                                    mem_paging_notification);
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE:
-        {
-            if ( med->ring_page )
-                rc = mem_event_disable(d, med);
-        }
-        break;
-
-        default:
-            rc = -ENOSYS;
-            break;
-        }
-    }
-    break;
-#endif
-
-#ifdef HAS_MEM_ACCESS
-    case XEN_DOMCTL_MEM_EVENT_OP_MONITOR:
-    {
-        struct mem_event_domain *med = &d->mem_event->monitor;
-        rc = -EINVAL;
-
-        switch( mec->op )
-        {
-        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE:
-        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION:
-        {
-            rc = -ENODEV;
-            if ( !p2m_mem_event_sanity_check(d) )
-                break;
-
-            rc = mem_event_enable(d, mec, med, _VPF_mem_access,
-                                    HVM_PARAM_MONITOR_RING_PFN,
-                                    mem_access_notification);
-
-            if ( mec->op == XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION
-                 && !rc )
-                p2m_setup_introspection(d);
-
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE:
-        {
-            if ( med->ring_page )
-            {
-                rc = mem_event_disable(d, med);
-                d->arch.hvm_domain.introspection_enabled = 0;
-            }
-        }
-        break;
-
-        default:
-            rc = -ENOSYS;
-            break;
-        }
-    }
-    break;
-#endif
-
-#ifdef HAS_MEM_SHARING
-    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 = -EOPNOTSUPP;
-            /* pvh fixme: p2m_is_foreign types need addressing */
-            if ( is_pvh_vcpu(current) || is_pvh_domain(hardware_domain) )
-                break;
-
-            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;
-#endif
-
-    default:
-        rc = -ENOSYS;
-    }
-
-    return rc;
-}
-
-void mem_event_vcpu_pause(struct vcpu *v)
-{
-    ASSERT(v == current);
-
-    atomic_inc(&v->mem_event_pause_count);
-    vcpu_pause_nosync(v);
-}
-
-void mem_event_vcpu_unpause(struct vcpu *v)
-{
-    int old, new, prev = v->mem_event_pause_count.counter;
-
-    /* All unpause requests as a result of toolstack responses.  Prevent
-     * underflow of the vcpu pause count. */
-    do
-    {
-        old = prev;
-        new = old - 1;
-
-        if ( new < 0 )
-        {
-            printk(XENLOG_G_WARNING
-                   "%pv mem_event: Too many unpause attempts\n", v);
-            return;
-        }
-
-        prev = cmpxchg(&v->mem_event_pause_count.counter, old, new);
-    } while ( prev != old );
-
-    vcpu_unpause(v);
-}
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
new file mode 100644
index 0000000..f81eae4
--- /dev/null
+++ b/xen/common/vm_event.c
@@ -0,0 +1,742 @@
+/******************************************************************************
+ * vm_event.c
+ *
+ * VM event support.
+ *
+ * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+
+#include <xen/sched.h>
+#include <xen/event.h>
+#include <xen/wait.h>
+#include <xen/vm_event.h>
+#include <xen/mem_access.h>
+#include <asm/p2m.h>
+
+#ifdef HAS_MEM_PAGING
+#include <asm/mem_paging.h>
+#endif
+
+#ifdef HAS_MEM_SHARING
+#include <asm/mem_sharing.h>
+#endif
+
+#include <xsm/xsm.h>
+
+/* for public/io/ring.h macros */
+#define xen_mb()   mb()
+#define xen_rmb()  rmb()
+#define xen_wmb()  wmb()
+
+#define vm_event_ring_lock_init(_ved)  spin_lock_init(&(_ved)->ring_lock)
+#define vm_event_ring_lock(_ved)       spin_lock(&(_ved)->ring_lock)
+#define vm_event_ring_unlock(_ved)     spin_unlock(&(_ved)->ring_lock)
+
+static int vm_event_enable(
+    struct domain *d,
+    xen_domctl_vm_event_op_t *vec,
+    struct vm_event_domain *ved,
+    int pause_flag,
+    int param,
+    xen_event_channel_notification_t notification_fn)
+{
+    int rc;
+    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.
+     */
+    if ( ved->ring_page )
+        return -EBUSY;
+
+    /* The parameter defaults to zero, and it should be
+     * set to something */
+    if ( ring_gfn == 0 )
+        return -ENOSYS;
+
+    vm_event_ring_lock_init(ved);
+    vm_event_ring_lock(ved);
+
+    rc = prepare_ring_for_helper(d, ring_gfn, &ved->ring_pg_struct,
+                                    &ved->ring_page);
+    if ( rc < 0 )
+        goto err;
+
+    /* Set the number of currently blocked vCPUs to 0. */
+    ved->blocked = 0;
+
+    /* Allocate event channel */
+    rc = alloc_unbound_xen_event_channel(d->vcpu[0],
+                                         current->domain->domain_id,
+                                         notification_fn);
+    if ( rc < 0 )
+        goto err;
+
+    ved->xen_port = vec->port = rc;
+
+    /* Prepare ring buffer */
+    FRONT_RING_INIT(&ved->front_ring,
+                    (vm_event_sring_t *)ved->ring_page,
+                    PAGE_SIZE);
+
+    /* Save the pause flag for this particular ring. */
+    ved->pause_flag = pause_flag;
+
+    /* Initialize the last-chance wait queue. */
+    init_waitqueue_head(&ved->wq);
+
+    vm_event_ring_unlock(ved);
+    return 0;
+
+ err:
+    destroy_ring_for_helper(&ved->ring_page,
+                            ved->ring_pg_struct);
+    vm_event_ring_unlock(ved);
+
+    return rc;
+}
+
+static unsigned int vm_event_ring_available(struct vm_event_domain *ved)
+{
+    int avail_req = RING_FREE_REQUESTS(&ved->front_ring);
+    avail_req -= ved->target_producers;
+    avail_req -= ved->foreign_producers;
+
+    BUG_ON(avail_req < 0);
+
+    return avail_req;
+}
+
+/*
+ * vm_event_wake_blocked() will wakeup vcpus waiting for room in the
+ * ring. These vCPUs were paused on their way out after placing an event,
+ * but need to be resumed where the ring is capable of processing at least
+ * one event from them.
+ */
+static void vm_event_wake_blocked(struct domain *d, struct vm_event_domain *ved)
+{
+    struct vcpu *v;
+    int online = d->max_vcpus;
+    unsigned int avail_req = vm_event_ring_available(ved);
+
+    if ( avail_req == 0 || ved->blocked == 0 )
+        return;
+
+    /*
+     * We ensure that we only have vCPUs online if there are enough free slots
+     * for their memory events to be processed.  This will ensure that no
+     * memory events are lost (due to the fact that certain types of events
+     * cannot be replayed, we need to ensure that there is space in the ring
+     * for when they are hit).
+     * See comment below in vm_event_put_request().
+     */
+    for_each_vcpu ( d, v )
+        if ( test_bit(ved->pause_flag, &v->pause_flags) )
+            online--;
+
+    ASSERT(online == (d->max_vcpus - ved->blocked));
+
+    /* We remember which vcpu last woke up to avoid scanning always linearly
+     * from zero and starving higher-numbered vcpus under high load */
+    if ( d->vcpu )
+    {
+        int i, j, k;
+
+        for (i = ved->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
+        {
+            k = i % d->max_vcpus;
+            v = d->vcpu[k];
+            if ( !v )
+                continue;
+
+            if ( !(ved->blocked) || online >= avail_req )
+               break;
+
+            if ( test_and_clear_bit(ved->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                online++;
+                ved->blocked--;
+                ved->last_vcpu_wake_up = k;
+            }
+        }
+    }
+}
+
+/*
+ * In the event that a vCPU attempted to place an event in the ring and
+ * was unable to do so, it is queued on a wait queue.  These are woken as
+ * needed, and take precedence over the blocked vCPUs.
+ */
+static void vm_event_wake_queued(struct domain *d, struct vm_event_domain *ved)
+{
+    unsigned int avail_req = vm_event_ring_available(ved);
+
+    if ( avail_req > 0 )
+        wake_up_nr(&ved->wq, avail_req);
+}
+
+/*
+ * vm_event_wake() will wakeup all vcpus waiting for the ring to
+ * become available.  If we have queued vCPUs, they get top priority. We
+ * are guaranteed that they will go through code paths that will eventually
+ * call vm_event_wake() again, ensuring that any blocked vCPUs will get
+ * unpaused once all the queued vCPUs have made it through.
+ */
+void vm_event_wake(struct domain *d, struct vm_event_domain *ved)
+{
+    if (!list_empty(&ved->wq.list))
+        vm_event_wake_queued(d, ved);
+    else
+        vm_event_wake_blocked(d, ved);
+}
+
+static int vm_event_disable(struct domain *d, struct vm_event_domain *ved)
+{
+    if ( ved->ring_page )
+    {
+        struct vcpu *v;
+
+        vm_event_ring_lock(ved);
+
+        if ( !list_empty(&ved->wq.list) )
+        {
+            vm_event_ring_unlock(ved);
+            return -EBUSY;
+        }
+
+        /* Free domU's event channel and leave the other one unbound */
+        free_xen_event_channel(d->vcpu[0], ved->xen_port);
+
+        /* Unblock all vCPUs */
+        for_each_vcpu ( d, v )
+        {
+            if ( test_and_clear_bit(ved->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                ved->blocked--;
+            }
+        }
+
+        destroy_ring_for_helper(&ved->ring_page,
+                                ved->ring_pg_struct);
+        vm_event_ring_unlock(ved);
+    }
+
+    return 0;
+}
+
+static inline void vm_event_release_slot(struct domain *d,
+                                          struct vm_event_domain *ved)
+{
+    /* Update the accounting */
+    if ( current->domain == d )
+        ved->target_producers--;
+    else
+        ved->foreign_producers--;
+
+    /* Kick any waiters */
+    vm_event_wake(d, ved);
+}
+
+/*
+ * vm_event_mark_and_pause() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in vm_event_wake_waiters().
+ */
+void vm_event_mark_and_pause(struct vcpu *v, struct vm_event_domain *ved)
+{
+    if ( !test_and_set_bit(ved->pause_flag, &v->pause_flags) )
+    {
+        vcpu_pause_nosync(v);
+        ved->blocked++;
+    }
+}
+
+/*
+ * This must be preceded by a call to claim_slot(), and is guaranteed to
+ * succeed.  As a side-effect however, the vCPU may be paused if the ring is
+ * overly full and its continued execution would cause stalling and excessive
+ * waiting.  The vCPU will be automatically unpaused when the ring clears.
+ */
+void vm_event_put_request(struct domain *d,
+                           struct vm_event_domain *ved,
+                           vm_event_request_t *req)
+{
+    vm_event_front_ring_t *front_ring;
+    int free_req;
+    unsigned int avail_req;
+    RING_IDX req_prod;
+
+    if ( current->domain != d )
+    {
+        req->flags |= VM_EVENT_FLAG_FOREIGN;
+#ifndef NDEBUG
+        if ( !(req->flags & VM_EVENT_FLAG_VCPU_PAUSED) )
+            gdprintk(XENLOG_G_WARNING, "d%dv%d was not paused.\n",
+                     d->domain_id, req->vcpu_id);
+#endif
+    }
+
+    vm_event_ring_lock(ved);
+
+    /* Due to the reservations, this step must succeed. */
+    front_ring = &ved->front_ring;
+    free_req = RING_FREE_REQUESTS(front_ring);
+    ASSERT(free_req > 0);
+
+    /* Copy request */
+    req_prod = front_ring->req_prod_pvt;
+    memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
+    req_prod++;
+
+    /* Update ring */
+    front_ring->req_prod_pvt = req_prod;
+    RING_PUSH_REQUESTS(front_ring);
+
+    /* We've actually *used* our reservation, so release the slot. */
+    vm_event_release_slot(d, ved);
+
+    /* Give this vCPU a black eye if necessary, on the way out.
+     * See the comments above wake_blocked() for more information
+     * on how this vechanism works to avoid waiting. */
+    avail_req = vm_event_ring_available(ved);
+    if( current->domain == d && avail_req < d->max_vcpus )
+        vm_event_mark_and_pause(current, ved);
+
+    vm_event_ring_unlock(ved);
+
+    notify_via_xen_event_channel(d, ved->xen_port);
+}
+
+int vm_event_get_response(struct domain *d, struct vm_event_domain *ved, vm_event_response_t *rsp)
+{
+    vm_event_front_ring_t *front_ring;
+    RING_IDX rsp_cons;
+
+    vm_event_ring_lock(ved);
+
+    front_ring = &ved->front_ring;
+    rsp_cons = front_ring->rsp_cons;
+
+    if ( !RING_HAS_UNCONSUMED_RESPONSES(front_ring) )
+    {
+        vm_event_ring_unlock(ved);
+        return 0;
+    }
+
+    /* Copy response */
+    memcpy(rsp, RING_GET_RESPONSE(front_ring, rsp_cons), sizeof(*rsp));
+    rsp_cons++;
+
+    /* Update ring */
+    front_ring->rsp_cons = rsp_cons;
+    front_ring->sring->rsp_event = rsp_cons + 1;
+
+    /* Kick any waiters -- since we've just consumed an event,
+     * there may be additional space available in the ring. */
+    vm_event_wake(d, ved);
+
+    vm_event_ring_unlock(ved);
+
+    return 1;
+}
+
+void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved)
+{
+    vm_event_ring_lock(ved);
+    vm_event_release_slot(d, ved);
+    vm_event_ring_unlock(ved);
+}
+
+static int vm_event_grab_slot(struct vm_event_domain *ved, int foreign)
+{
+    unsigned int avail_req;
+
+    if ( !ved->ring_page )
+        return -ENOSYS;
+
+    vm_event_ring_lock(ved);
+
+    avail_req = vm_event_ring_available(ved);
+    if ( avail_req == 0 )
+    {
+        vm_event_ring_unlock(ved);
+        return -EBUSY;
+    }
+
+    if ( !foreign )
+        ved->target_producers++;
+    else
+        ved->foreign_producers++;
+
+    vm_event_ring_unlock(ved);
+
+    return 0;
+}
+
+/* Simple try_grab wrapper for use in the wait_event() macro. */
+static int vm_event_wait_try_grab(struct vm_event_domain *ved, int *rc)
+{
+    *rc = vm_event_grab_slot(ved, 0);
+    return *rc;
+}
+
+/* Call vm_event_grab_slot() until the ring doesn't exist, or is available. */
+static int vm_event_wait_slot(struct vm_event_domain *ved)
+{
+    int rc = -EBUSY;
+    wait_event(ved->wq, vm_event_wait_try_grab(ved, &rc) != -EBUSY);
+    return rc;
+}
+
+bool_t vm_event_check_ring(struct vm_event_domain *ved)
+{
+    return (ved->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
+ * use vm_event_wait_slot() to reserve a slot.  As long as there is a ring,
+ * this function will always return 0 for a guest.  For a non-guest, we check
+ * for space and return -EBUSY if the ring is not available.
+ *
+ * Return codes: -ENOSYS: the ring is not yet configured
+ *               -EBUSY: the ring is busy
+ *               0: a spot has been reserved
+ *
+ */
+int __vm_event_claim_slot(struct domain *d, struct vm_event_domain *ved,
+                            bool_t allow_sleep)
+{
+    if ( (current->domain == d) && allow_sleep )
+        return vm_event_wait_slot(ved);
+    else
+        return vm_event_grab_slot(ved, (current->domain != d));
+}
+
+#ifdef HAS_MEM_PAGING
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_paging_notification(struct vcpu *v, unsigned int port)
+{
+    if ( likely(v->domain->vm_event->paging.ring_page != NULL) )
+        p2m_mem_paging_resume(v->domain);
+}
+#endif
+
+#ifdef HAS_MEM_ACCESS
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_access_notification(struct vcpu *v, unsigned int port)
+{
+    if ( likely(v->domain->vm_event->monitor.ring_page != NULL) )
+        mem_access_resume(v->domain);
+}
+#endif
+
+#ifdef HAS_MEM_SHARING
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_sharing_notification(struct vcpu *v, unsigned int port)
+{
+    if ( likely(v->domain->vm_event->share.ring_page != NULL) )
+        mem_sharing_sharing_resume(v->domain);
+}
+#endif
+
+int do_vm_event_op(int op, uint32_t domain, void *arg)
+{
+    int ret;
+    struct domain *d;
+
+    ret = rcu_lock_live_remote_domain_by_id(domain, &d);
+    if ( ret )
+        return ret;
+
+    ret = xsm_vm_event_op(XSM_DM_PRIV, d, op);
+    if ( ret )
+        goto out;
+
+    switch (op)
+    {
+#ifdef HAS_MEM_PAGING
+        case XENMEM_paging_op:
+            ret = mem_paging_memop(d, (xen_mem_paging_op_t *) arg);
+            break;
+#endif
+#ifdef HAS_MEM_SHARING
+        case XENMEM_sharing_op:
+            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
+            break;
+#endif
+        default:
+            ret = -ENOSYS;
+    }
+
+ out:
+    rcu_unlock_domain(d);
+    return ret;
+}
+
+/* Clean up on domain destruction */
+void vm_event_cleanup(struct domain *d)
+{
+#ifdef HAS_MEM_PAGING
+    if ( d->vm_event->paging.ring_page ) {
+        /* Destroying the wait queue head means waking up all
+         * queued vcpus. This will drain the list, allowing
+         * the disable routine to complete. It will also drop
+         * all domain refs the wait-queued vcpus are holding.
+         * Finally, because this code path involves previously
+         * pausing the domain (domain_kill), unpausing the
+         * vcpus causes no harm. */
+        destroy_waitqueue_head(&d->vm_event->paging.wq);
+        (void)vm_event_disable(d, &d->vm_event->paging);
+    }
+#endif
+#ifdef HAS_MEM_ACCESS
+    if ( d->vm_event->monitor.ring_page ) {
+        destroy_waitqueue_head(&d->vm_event->monitor.wq);
+        (void)vm_event_disable(d, &d->vm_event->monitor);
+    }
+#endif
+#ifdef HAS_MEM_SHARING
+    if ( d->vm_event->share.ring_page ) {
+        destroy_waitqueue_head(&d->vm_event->share.wq);
+        (void)vm_event_disable(d, &d->vm_event->share);
+    }
+#endif
+}
+
+int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *vec,
+                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
+{
+    int rc;
+
+    rc = xsm_vm_event_control(XSM_PRIV, d, vec->mode, vec->op);
+    if ( rc )
+        return rc;
+
+    if ( unlikely(d == current->domain) )
+    {
+        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 event op on dying domain %u\n",
+                 d->domain_id);
+        return 0;
+    }
+
+    if ( unlikely(d->vcpu == NULL) || unlikely(d->vcpu[0] == NULL) )
+    {
+        gdprintk(XENLOG_INFO,
+                 "Memory event op on a domain (%u) with no vcpus\n",
+                 d->domain_id);
+        return -EINVAL;
+    }
+
+    rc = -ENOSYS;
+
+    switch ( vec->mode )
+    {
+#ifdef HAS_MEM_PAGING
+    case XEN_DOMCTL_VM_EVENT_OP_PAGING:
+    {
+        struct vm_event_domain *ved = &d->vm_event->paging;
+        rc = -EINVAL;
+
+        switch( vec->op )
+        {
+        case XEN_DOMCTL_VM_EVENT_OP_PAGING_ENABLE:
+        {
+            struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+            rc = -EOPNOTSUPP;
+            /* pvh fixme: p2m_is_foreign types need addressing */
+            if ( is_pvh_vcpu(current) || is_pvh_domain(hardware_domain) )
+                break;
+
+            rc = -ENODEV;
+            /* Only HAP is supported */
+            if ( !hap_enabled(d) )
+                break;
+
+            /* No paging if iommu is used */
+            rc = -EMLINK;
+            if ( unlikely(need_iommu(d)) )
+                break;
+
+            rc = -EXDEV;
+            /* Disallow paging in a PoD guest */
+            if ( p2m->pod.entry_count )
+                break;
+
+            rc = vm_event_enable(d, vec, ved, _VPF_mem_paging,
+                                    HVM_PARAM_PAGING_RING_PFN,
+                                    mem_paging_notification);
+        }
+        break;
+
+        case XEN_DOMCTL_VM_EVENT_OP_PAGING_DISABLE:
+        {
+            if ( ved->ring_page )
+                rc = vm_event_disable(d, ved);
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+            break;
+        }
+    }
+    break;
+#endif
+
+#ifdef HAS_MEM_ACCESS
+    case XEN_DOMCTL_VM_EVENT_OP_MONITOR:
+    {
+        struct vm_event_domain *ved = &d->vm_event->monitor;
+        rc = -EINVAL;
+
+        switch( vec->op )
+        {
+        case XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE:
+        case XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION:
+        {
+            rc = -ENODEV;
+            if ( !p2m_mem_access_sanity_check(d) )
+                break;
+
+            rc = vm_event_enable(d, vec, ved, _VPF_mem_access,
+                                    HVM_PARAM_MONITOR_RING_PFN,
+                                    mem_access_notification);
+
+            if ( vec->op == XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION
+                 && !rc )
+                p2m_setup_introspection(d);
+
+        }
+        break;
+
+        case XEN_DOMCTL_VM_EVENT_OP_MONITOR_DISABLE:
+        {
+            if ( ved->ring_page )
+            {
+                rc = vm_event_disable(d, ved);
+                d->arch.hvm_domain.introspection_enabled = 0;
+            }
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+            break;
+        }
+    }
+    break;
+#endif
+
+#ifdef HAS_MEM_SHARING
+    case XEN_DOMCTL_VM_EVENT_OP_SHARING:
+    {
+        struct vm_event_domain *ved = &d->vm_event->share;
+        rc = -EINVAL;
+
+        switch( vec->op )
+        {
+        case XEN_DOMCTL_VM_EVENT_OP_SHARING_ENABLE:
+        {
+            rc = -EOPNOTSUPP;
+            /* pvh fixme: p2m_is_foreign types need addressing */
+            if ( is_pvh_vcpu(current) || is_pvh_domain(hardware_domain) )
+                break;
+
+            rc = -ENODEV;
+            /* Only HAP is supported */
+            if ( !hap_enabled(d) )
+                break;
+
+            rc = vm_event_enable(d, vec, ved, _VPF_mem_sharing,
+                                    HVM_PARAM_SHARING_RING_PFN,
+                                    mem_sharing_notification);
+        }
+        break;
+
+        case XEN_DOMCTL_VM_EVENT_OP_SHARING_DISABLE:
+        {
+            if ( ved->ring_page )
+                rc = vm_event_disable(d, ved);
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+            break;
+        }
+    }
+    break;
+#endif
+
+    default:
+        rc = -ENOSYS;
+    }
+
+    return rc;
+}
+
+void vm_event_vcpu_pause(struct vcpu *v)
+{
+    ASSERT(v == current);
+
+    atomic_inc(&v->vm_event_pause_count);
+    vcpu_pause_nosync(v);
+}
+
+void vm_event_vcpu_unpause(struct vcpu *v)
+{
+    int old, new, prev = v->vm_event_pause_count.counter;
+
+    /* All unpause requests as a result of toolstack responses.  Prevent
+     * underflow of the vcpu pause count. */
+    do
+    {
+        old = prev;
+        new = old - 1;
+
+        if ( new < 0 )
+        {
+            printk(XENLOG_G_WARNING
+                   "%pv vm_event: Too many unpause attempts\n", v);
+            return;
+        }
+
+        prev = cmpxchg(&v->vm_event_pause_count.counter, old, new);
+    } while ( prev != old );
+
+    vcpu_unpause(v);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..964384b 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1346,7 +1346,7 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
      * enabled for this domain */
     if ( unlikely(!need_iommu(d) &&
             (d->arch.hvm_domain.mem_sharing_enabled ||
-             d->mem_event->paging.ring_page ||
+             d->vm_event->paging.ring_page ||
              p2m_get_hostp2m(d)->global_logdirty)) )
         return -EXDEV;
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index da36504..e1a72d5 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -45,7 +45,7 @@ struct p2m_domain {
         unsigned long shattered[4];
     } stats;
 
-    /* If true, and an access fault comes in and there is no mem_event listener,
+    /* If true, and an access fault comes in and there is no vm_event listener,
      * pause domain. Otherwise, remove access restrictions. */
     bool_t access_required;
 };
@@ -71,8 +71,8 @@ typedef enum {
 } p2m_type_t;
 
 static inline
-void p2m_mem_event_emulate_check(struct vcpu *v,
-                                 const mem_event_response_t *rsp)
+void p2m_mem_access_emulate_check(struct vcpu *v,
+                                  const vm_event_response_t *rsp)
 {
     /* Not supported on ARM. */
 };
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 6a77a93..20ede1e 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -478,13 +478,13 @@ struct arch_vcpu
 
     /*
      * Should we emulate the next matching instruction on VCPU resume
-     * after a mem_event?
+     * after a vm_event?
      */
     struct {
         uint32_t emulate_flags;
         unsigned long gpa;
         unsigned long eip;
-    } mem_event;
+    } vm_event;
 
 } __cacheline_aligned;
 
diff --git a/xen/include/asm-x86/hvm/emulate.h b/xen/include/asm-x86/hvm/emulate.h
index 5411302..b3971c8 100644
--- a/xen/include/asm-x86/hvm/emulate.h
+++ b/xen/include/asm-x86/hvm/emulate.h
@@ -38,7 +38,7 @@ int hvm_emulate_one(
     struct hvm_emulate_ctxt *hvmemul_ctxt);
 int hvm_emulate_one_no_write(
     struct hvm_emulate_ctxt *hvmemul_ctxt);
-void hvm_mem_event_emulate_one(bool_t nowrite,
+void hvm_mem_access_emulate_one(bool_t nowrite,
     unsigned int trapnr,
     unsigned int errcode);
 void hvm_emulate_prepare(
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..2ee863b 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -238,7 +238,7 @@ struct p2m_domain {
      * retyped get this access type.  See definition of p2m_access_t. */
     p2m_access_t default_access;
 
-    /* If true, and an access fault comes in and there is no mem_event listener, 
+    /* If true, and an access fault comes in and there is no vm_event listener, 
      * pause domain.  Otherwise, remove access restrictions. */
     bool_t       access_required;
 
@@ -572,7 +572,7 @@ void p2m_mem_paging_resume(struct domain *d);
  * locks -- caller must also xfree the request. */
 bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
                             struct npfec npfec,
-                            mem_event_request_t **req_ptr);
+                            vm_event_request_t **req_ptr);
 
 /* Set access type for a region of pfns.
  * If start_pfn == -1ul, sets the default access type */
@@ -586,22 +586,16 @@ int p2m_get_mem_access(struct domain *d, unsigned long pfn,
 
 /* Check for emulation and mark vcpu for skipping one instruction
  * upon rescheduling if required. */
-void p2m_mem_event_emulate_check(struct vcpu *v,
-                                 const mem_event_response_t *rsp);
+void p2m_mem_access_emulate_check(struct vcpu *v,
+                                 const vm_event_response_t *rsp);
 
 /* Enable arch specific introspection options (such as MSR interception). */
 void p2m_setup_introspection(struct domain *d);
 
-/* Sanity check for mem_event hardware support */
-static inline bool_t p2m_mem_event_sanity_check(struct domain *d)
-{
-    return hap_enabled(d) && cpu_has_vmx;
-}
-
 /* Sanity check for mem_access hardware support */
 static inline bool_t p2m_mem_access_sanity_check(struct domain *d)
 {
-    return is_hvm_domain(d);
+    return hap_enabled(d) && cpu_has_vmx && is_hvm_domain(d);
 }
 
 /* 
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 9d2cc38..1d8bbf0 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -753,7 +753,7 @@ struct xen_domctl_gdbsx_domstatus {
  * Memory event operations
  */
 
-/* XEN_DOMCTL_mem_event_op */
+/* XEN_DOMCTL_vm_event_op */
 
 /*
  * Domain memory paging
@@ -762,17 +762,17 @@ struct xen_domctl_gdbsx_domstatus {
  * pager<->hypervisor interface. Use XENMEM_paging_op*
  * to perform per-page operations.
  *
- * The XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE domctl returns several
+ * The XEN_DOMCTL_VM_EVENT_OP_PAGING_ENABLE domctl returns several
  * non-standard error codes to indicate why paging could not be enabled:
  * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
  * EMLINK - guest has iommu passthrough enabled
  * EXDEV  - guest has PoD enabled
  * EBUSY  - guest has or had paging enabled, ring buffer still active
  */
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
+#define XEN_DOMCTL_VM_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_VM_EVENT_OP_PAGING_ENABLE     0
+#define XEN_DOMCTL_VM_EVENT_OP_PAGING_DISABLE    1
 
 /*
  * Monitor permissions.
@@ -783,21 +783,21 @@ struct xen_domctl_gdbsx_domstatus {
  * 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) .
+ * is sent with what happened.  (See public/vm_event.h) .
  *
  * The memory event handler can then resume the VCPU and redo the access 
  * with a XENMEM_access_op_resume hypercall.
  *
- * The XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE domctl returns several
+ * The XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE domctl returns several
  * non-standard error codes to indicate why access could not be enabled:
  * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
  * EBUSY  - guest has or had access enabled, ring buffer still active
  */
-#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR                        2
+#define XEN_DOMCTL_VM_EVENT_OP_MONITOR                        2
 
-#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE                 0
-#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE                1
-#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION   2
+#define XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE                 0
+#define XEN_DOMCTL_VM_EVENT_OP_MONITOR_DISABLE                1
+#define XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION   2
 
 /*
  * Sharing ENOMEM helper.
@@ -812,21 +812,21 @@ struct xen_domctl_gdbsx_domstatus {
  * 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_VM_EVENT_OP_SHARING           3
 
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE    0
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DISABLE   1
+#define XEN_DOMCTL_VM_EVENT_OP_SHARING_ENABLE    0
+#define XEN_DOMCTL_VM_EVENT_OP_SHARING_DISABLE   1
 
 /* 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_* */
+struct xen_domctl_vm_event_op {
+    uint32_t       op;           /* XEN_DOMCTL_VM_EVENT_OP_*_* */
+    uint32_t       mode;         /* XEN_DOMCTL_VM_EVENT_OP_* */
 
     uint32_t port;              /* OUT: event channel for ring */
 };
-typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
-DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
+typedef struct xen_domctl_vm_event_op xen_domctl_vm_event_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_vm_event_op_t);
 
 /*
  * Memory sharing operations
@@ -1049,7 +1049,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_suppress_spurious_page_faults 53
 #define XEN_DOMCTL_debug_op                      54
 #define XEN_DOMCTL_gethvmcontext_partial         55
-#define XEN_DOMCTL_mem_event_op                  56
+#define XEN_DOMCTL_vm_event_op                   56
 #define XEN_DOMCTL_mem_sharing_op                57
 #define XEN_DOMCTL_disable_migrate               58
 #define XEN_DOMCTL_gettscinfo                    59
@@ -1117,7 +1117,7 @@ struct xen_domctl {
         struct xen_domctl_set_target        set_target;
         struct xen_domctl_subscribe         subscribe;
         struct xen_domctl_debug_op          debug_op;
-        struct xen_domctl_mem_event_op      mem_event_op;
+        struct xen_domctl_vm_event_op       vm_event_op;
         struct xen_domctl_mem_sharing_op    mem_sharing_op;
 #if defined(__i386__) || defined(__x86_64__)
         struct xen_domctl_cpuid             cpuid;
diff --git a/xen/include/public/mem_event.h b/xen/include/public/mem_event.h
deleted file mode 100644
index c0e9394..0000000
--- a/xen/include/public/mem_event.h
+++ /dev/null
@@ -1,179 +0,0 @@
-/******************************************************************************
- * mem_event.h
- *
- * Memory event common structures.
- *
- * Copyright (c) 2009 by Citrix Systems, Inc. (Patrick Colp)
- *
- * 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_MEM_EVENT_H
-#define _XEN_PUBLIC_MEM_EVENT_H
-
-#include "xen.h"
-#include "io/ring.h"
-
-/* Memory event flags */
-#define MEM_EVENT_FLAG_VCPU_PAUSED     (1 << 0)
-#define MEM_EVENT_FLAG_DROP_PAGE       (1 << 1)
-#define MEM_EVENT_FLAG_EVICT_FAIL      (1 << 2)
-#define MEM_EVENT_FLAG_FOREIGN         (1 << 3)
-#define MEM_EVENT_FLAG_DUMMY           (1 << 4)
-/*
- * Emulate the fault-causing instruction (if set in the event response flags).
- * This will allow the guest to continue execution without lifting the page
- * access restrictions.
- */
-#define MEM_EVENT_FLAG_EMULATE         (1 << 5)
-/*
- * Same as MEM_EVENT_FLAG_EMULATE, but with write operations or operations
- * potentially having side effects (like memory mapped or port I/O) disabled.
- */
-#define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 << 6)
-
-/* Reasons for the memory event request */
-typedef enum {
-    MEM_EVENT_REASON_UNKNOWN,              /* Default case */
-    MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
-    MEM_EVENT_REASON_MEM_SHARING,          /* Memory sharing event */
-    MEM_EVENT_REASON_MEM_PAGING,           /* Memory paging event */
-    MEM_EVENT_REASON_CR0,                  /* CR0 was updated */
-    MEM_EVENT_REASON_CR3,                  /* CR3 was updated */
-    MEM_EVENT_REASON_CR4,                  /* CR4 was updated */
-    MEM_EVENT_REASON_INT3,                 /* Debug operation executed (int3) */
-    MEM_EVENT_REASON_SINGLESTEP,           /* Single-step (MTF) */
-    MEM_EVENT_REASON_MSR,                  /* An MSR was updated.
-                                            * Does NOT honour HVMPME_onchangeonly */
-} mem_event_reason_t;
-
-/* Using a custom struct (not hvm_hw_cpu) so as to not fill
- * the mem_event ring buffer too quickly. */
-struct mem_event_regs_x86 {
-    uint64_t rax;
-    uint64_t rcx;
-    uint64_t rdx;
-    uint64_t rbx;
-    uint64_t rsp;
-    uint64_t rbp;
-    uint64_t rsi;
-    uint64_t rdi;
-    uint64_t r8;
-    uint64_t r9;
-    uint64_t r10;
-    uint64_t r11;
-    uint64_t r12;
-    uint64_t r13;
-    uint64_t r14;
-    uint64_t r15;
-    uint64_t rflags;
-    uint64_t dr7;
-    uint64_t rip;
-    uint64_t cr0;
-    uint64_t cr2;
-    uint64_t cr3;
-    uint64_t cr4;
-    uint64_t sysenter_cs;
-    uint64_t sysenter_esp;
-    uint64_t sysenter_eip;
-    uint64_t msr_efer;
-    uint64_t msr_star;
-    uint64_t msr_lstar;
-    uint64_t fs_base;
-    uint64_t gs_base;
-    uint32_t cs_arbytes;
-    uint32_t _pad;
-};
-
-struct mem_event_mem_access_data {
-    uint64_t gfn;
-    uint64_t offset;
-    uint64_t gla; /* if gla_valid */
-    uint16_t access_r:1;
-    uint16_t access_w:1;
-    uint16_t access_x:1;
-    uint16_t gla_valid:1;
-    uint16_t fault_with_gla:1;
-    uint16_t fault_in_gpt:1;
-    uint16_t available:10;
-};
-
-struct mem_event_cr_data {
-    uint64_t new_value;
-    uint64_t old_value;
-};
-
-struct mem_event_int3_data {
-    uint64_t gfn;
-    uint64_t gla;
-};
-
-struct mem_event_singlestep_data {
-    uint64_t gfn;
-    uint64_t gla;
-};
-
-struct mem_event_msr_data {
-    uint64_t msr;
-    uint64_t old_value;
-    uint64_t new_value;
-};
-
-struct mem_event_paging_data {
-    uint64_t gfn;
-    uint32_t p2mt;
-};
-
-struct mem_event_sharing_data {
-    uint64_t gfn;
-    uint32_t p2mt;
-};
-
-typedef struct mem_event_st {
-    uint32_t flags;
-    uint32_t vcpu_id;
-
-    mem_event_reason_t reason;
-
-    union {
-        struct mem_event_paging_data     mem_paging_event;
-        struct mem_event_sharing_data    mem_sharing_event;
-        struct mem_event_mem_access_data mem_access_event;
-        struct mem_event_cr_data         cr_event;
-        struct mem_event_int3_data       int3_event;
-        struct mem_event_singlestep_data singlestep_event;
-        struct mem_event_msr_data        msr_event;
-    };
-
-    struct mem_event_regs_x86 x86_regs;
-} mem_event_request_t, mem_event_response_t;
-
-DEFINE_RING_TYPES(mem_event, mem_event_request_t, mem_event_response_t);
-
-#endif
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
new file mode 100644
index 0000000..ca31a39
--- /dev/null
+++ b/xen/include/public/vm_event.h
@@ -0,0 +1,179 @@
+/******************************************************************************
+ * vm_event.h
+ *
+ * VM event common structures.
+ *
+ * Copyright (c) 2009 by Citrix Systems, Inc. (Patrick Colp)
+ *
+ * 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_VM_EVENT_H
+#define _XEN_PUBLIC_VM_EVENT_H
+
+#include "xen.h"
+#include "io/ring.h"
+
+/* Memory event flags */
+#define VM_EVENT_FLAG_VCPU_PAUSED     (1 << 0)
+#define VM_EVENT_FLAG_DROP_PAGE       (1 << 1)
+#define VM_EVENT_FLAG_EVICT_FAIL      (1 << 2)
+#define VM_EVENT_FLAG_FOREIGN         (1 << 3)
+#define VM_EVENT_FLAG_DUMMY           (1 << 4)
+/*
+ * Emulate the fault-causing instruction (if set in the event response flags).
+ * This will allow the guest to continue execution without lifting the page
+ * access restrictions.
+ */
+#define VM_EVENT_FLAG_EMULATE         (1 << 5)
+/*
+ * Same as VM_EVENT_FLAG_EMULATE, but with write operations or operations
+ * potentially having side effects (like memory mapped or port I/O) disabled.
+ */
+#define VM_EVENT_FLAG_EMULATE_NOWRITE (1 << 6)
+
+/* Reasons for the memory event request */
+typedef enum {
+    VM_EVENT_REASON_UNKNOWN,              /* Default case */
+    VM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
+    VM_EVENT_REASON_MEM_SHARING,          /* Memory sharing event */
+    VM_EVENT_REASON_MEM_PAGING,           /* Memory paging event */
+    VM_EVENT_REASON_CR0,                  /* CR0 was updated */
+    VM_EVENT_REASON_CR3,                  /* CR3 was updated */
+    VM_EVENT_REASON_CR4,                  /* CR4 was updated */
+    VM_EVENT_REASON_INT3,                 /* Debug operation executed (int3) */
+    VM_EVENT_REASON_SINGLESTEP,           /* Single-step (MTF) */
+    VM_EVENT_REASON_MSR,                  /* An MSR was updated.
+                                            * Does NOT honour HVMPME_onchangeonly */
+} vm_event_reason_t;
+
+/* Using a custom struct (not hvm_hw_cpu) so as to not fill
+ * the vm_event ring buffer too quickly. */
+struct vm_event_regs_x86 {
+    uint64_t rax;
+    uint64_t rcx;
+    uint64_t rdx;
+    uint64_t rbx;
+    uint64_t rsp;
+    uint64_t rbp;
+    uint64_t rsi;
+    uint64_t rdi;
+    uint64_t r8;
+    uint64_t r9;
+    uint64_t r10;
+    uint64_t r11;
+    uint64_t r12;
+    uint64_t r13;
+    uint64_t r14;
+    uint64_t r15;
+    uint64_t rflags;
+    uint64_t dr7;
+    uint64_t rip;
+    uint64_t cr0;
+    uint64_t cr2;
+    uint64_t cr3;
+    uint64_t cr4;
+    uint64_t sysenter_cs;
+    uint64_t sysenter_esp;
+    uint64_t sysenter_eip;
+    uint64_t msr_efer;
+    uint64_t msr_star;
+    uint64_t msr_lstar;
+    uint64_t fs_base;
+    uint64_t gs_base;
+    uint32_t cs_arbytes;
+    uint32_t _pad;
+};
+
+struct vm_event_mem_access_data {
+    uint64_t gfn;
+    uint64_t offset;
+    uint64_t gla; /* if gla_valid */
+    uint16_t access_r:1;
+    uint16_t access_w:1;
+    uint16_t access_x:1;
+    uint16_t gla_valid:1;
+    uint16_t fault_with_gla:1;
+    uint16_t fault_in_gpt:1;
+    uint16_t available:10;
+};
+
+struct vm_event_cr_data {
+    uint64_t new_value;
+    uint64_t old_value;
+};
+
+struct vm_event_int3_data {
+    uint64_t gfn;
+    uint64_t gla;
+};
+
+struct vm_event_singlestep_data {
+    uint64_t gfn;
+    uint64_t gla;
+};
+
+struct vm_event_msr_data {
+    uint64_t msr;
+    uint64_t old_value;
+    uint64_t new_value;
+};
+
+struct vm_event_paging_data {
+    uint64_t gfn;
+    uint32_t p2mt;
+};
+
+struct vm_event_sharing_data {
+    uint64_t gfn;
+    uint32_t p2mt;
+};
+
+typedef struct vm_event_st {
+    uint32_t flags;
+    uint32_t vcpu_id;
+
+    vm_event_reason_t reason;
+
+    union {
+        struct vm_event_paging_data     mem_paging_event;
+        struct vm_event_sharing_data    mem_sharing_event;
+        struct vm_event_mem_access_data mem_access_event;
+        struct vm_event_cr_data         cr_event;
+        struct vm_event_int3_data       int3_event;
+        struct vm_event_singlestep_data singlestep_event;
+        struct vm_event_msr_data        msr_event;
+    };
+
+    struct vm_event_regs_x86 x86_regs;
+} vm_event_request_t, vm_event_response_t;
+
+DEFINE_RING_TYPES(vm_event, vm_event_request_t, vm_event_response_t);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
index 6ceb2a4..1d01221 100644
--- a/xen/include/xen/mem_access.h
+++ b/xen/include/xen/mem_access.h
@@ -29,7 +29,7 @@
 
 int mem_access_memop(unsigned long cmd,
                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
-int mem_access_send_req(struct domain *d, mem_event_request_t *req);
+int mem_access_send_req(struct domain *d, vm_event_request_t *req);
 
 /* Resumes the running of the VCPU, restarting the last instruction */
 void mem_access_resume(struct domain *d);
@@ -44,7 +44,7 @@ int mem_access_memop(unsigned long cmd,
 }
 
 static inline
-int mem_access_send_req(struct domain *d, mem_event_request_t *req)
+int mem_access_send_req(struct domain *d, vm_event_request_t *req)
 {
     return -ENOSYS;
 }
diff --git a/xen/include/xen/mem_event.h b/xen/include/xen/mem_event.h
deleted file mode 100644
index 4f3ad8e..0000000
--- a/xen/include/xen/mem_event.h
+++ /dev/null
@@ -1,143 +0,0 @@
-/******************************************************************************
- * mem_event.h
- *
- * Common interface for memory event support.
- *
- * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-
-
-#ifndef __MEM_EVENT_H__
-#define __MEM_EVENT_H__
-
-#include <xen/sched.h>
-
-#ifdef HAS_MEM_ACCESS
-
-/* Clean up on domain destruction */
-void mem_event_cleanup(struct domain *d);
-
-/* 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 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);
-
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
-                            mem_event_request_t *req);
-
-int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
-                           mem_event_response_t *rsp);
-
-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_PARAM(void) u_domctl);
-
-void mem_event_vcpu_pause(struct vcpu *v);
-void mem_event_vcpu_unpause(struct vcpu *v);
-
-#else
-
-static inline void mem_event_cleanup(struct domain *d) {}
-
-static inline bool_t mem_event_check_ring(struct mem_event_domain *med)
-{
-    return 0;
-}
-
-static inline int mem_event_claim_slot(struct domain *d,
-                                        struct mem_event_domain *med)
-{
-    return -ENOSYS;
-}
-
-static inline int mem_event_claim_slot_nosleep(struct domain *d,
-                                        struct mem_event_domain *med)
-{
-    return -ENOSYS;
-}
-
-static inline
-void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med)
-{}
-
-static inline
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
-                            mem_event_request_t *req)
-{}
-
-static inline
-int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
-                           mem_event_response_t *rsp)
-{
-    return -ENOSYS;
-}
-
-static inline int do_mem_event_op(int op, uint32_t domain, void *arg)
-{
-    return -ENOSYS;
-}
-
-static inline
-int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
-{
-    return -ENOSYS;
-}
-
-static inline void mem_event_vcpu_pause(struct vcpu *v) {}
-static inline void mem_event_vcpu_unpause(struct vcpu *v) {}
-
-#endif /* HAS_MEM_ACCESS */
-
-#endif /* __MEM_EVENT_H__ */
-
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/xen/p2m-common.h b/xen/include/xen/p2m-common.h
index 29f3628..5da8a2d 100644
--- a/xen/include/xen/p2m-common.h
+++ b/xen/include/xen/p2m-common.h
@@ -1,12 +1,12 @@
 #ifndef _XEN_P2M_COMMON_H
 #define _XEN_P2M_COMMON_H
 
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 
 /*
  * Additional access types, which are used to further restrict
  * the permissions given my the p2m_type_t memory type.  Violations
- * caused by p2m_access_t restrictions are sent to the mem_event
+ * caused by p2m_access_t restrictions are sent to the vm_event
  * interface.
  *
  * The access permissions are soft state: when any ambiguous change of page
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 2fc36ea..14fae4a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -23,7 +23,7 @@
 #include <public/domctl.h>
 #include <public/sysctl.h>
 #include <public/vcpu.h>
-#include <public/mem_event.h>
+#include <public/vm_event.h>
 #include <public/event_channel.h>
 
 #ifdef CONFIG_COMPAT
@@ -214,8 +214,8 @@ struct vcpu
     unsigned long    pause_flags;
     atomic_t         pause_count;
 
-    /* VCPU paused for mem_event replies. */
-    atomic_t         mem_event_pause_count;
+    /* VCPU paused for vm_event replies. */
+    atomic_t         vm_event_pause_count;
     /* VCPU paused by system controller. */
     int              controller_pause_count;
 
@@ -258,7 +258,7 @@ struct vcpu
 #define domain_is_locked(d) spin_is_locked(&(d)->domain_lock)
 
 /* Memory event */
-struct mem_event_domain
+struct vm_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
@@ -269,10 +269,10 @@ struct mem_event_domain
     void *ring_page;
     struct page_info *ring_pg_struct;
     /* front-end ring */
-    mem_event_front_ring_t front_ring;
+    vm_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
-    /* mem_event bit for vcpu->pause_flags */
+    /* vm_event bit for vcpu->pause_flags */
     int pause_flag;
     /* list of vcpus waiting for room in the ring */
     struct waitqueue_head wq;
@@ -282,14 +282,14 @@ struct mem_event_domain
     unsigned int last_vcpu_wake_up;
 };
 
-struct mem_event_per_domain
+struct vm_event_per_domain
 {
     /* Memory sharing support */
-    struct mem_event_domain share;
+    struct vm_event_domain share;
     /* Memory paging support */
-    struct mem_event_domain paging;
-    /* VM event monitor support */
-    struct mem_event_domain monitor;
+    struct vm_event_domain paging;
+    /* Memory access support */
+    struct vm_event_domain monitor;
 };
 
 struct evtchn_port_ops;
@@ -442,8 +442,8 @@ struct domain
     /* Non-migratable and non-restoreable? */
     bool_t disable_migrate;
 
-    /* Various mem_events */
-    struct mem_event_per_domain *mem_event;
+    /* Various vm_events */
+    struct vm_event_per_domain *vm_event;
 
     /*
      * Can be specified by the user. If that is not the case, it is
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
new file mode 100644
index 0000000..e6e31cd
--- /dev/null
+++ b/xen/include/xen/vm_event.h
@@ -0,0 +1,143 @@
+/******************************************************************************
+ * vm_event.h
+ *
+ * Common interface for memory event support.
+ *
+ * Copyright (c) 2009 Citrix Systems, Inc. (Patrick Colp)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+
+#ifndef __VM_EVENT_H__
+#define __VM_EVENT_H__
+
+#include <xen/sched.h>
+
+#ifdef HAS_MEM_ACCESS
+
+/* Clean up on domain destruction */
+void vm_event_cleanup(struct domain *d);
+
+/* Returns whether a ring has been set up */
+bool_t vm_event_check_ring(struct vm_event_domain *med);
+
+/* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
+ * 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 __vm_event_claim_slot(struct domain *d, struct vm_event_domain *med,
+                            bool_t allow_sleep);
+static inline int vm_event_claim_slot(struct domain *d,
+                                        struct vm_event_domain *med)
+{
+    return __vm_event_claim_slot(d, med, 1);
+}
+
+static inline int vm_event_claim_slot_nosleep(struct domain *d,
+                                        struct vm_event_domain *med)
+{
+    return __vm_event_claim_slot(d, med, 0);
+}
+
+void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *med);
+
+void vm_event_put_request(struct domain *d, struct vm_event_domain *med,
+                            vm_event_request_t *req);
+
+int vm_event_get_response(struct domain *d, struct vm_event_domain *med,
+                           vm_event_response_t *rsp);
+
+int do_vm_event_op(int op, uint32_t domain, void *arg);
+int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *mec,
+                     XEN_GUEST_HANDLE_PARAM(void) u_domctl);
+
+void vm_event_vcpu_pause(struct vcpu *v);
+void vm_event_vcpu_unpause(struct vcpu *v);
+
+#else
+
+static inline void vm_event_cleanup(struct domain *d) {}
+
+static inline bool_t vm_event_check_ring(struct vm_event_domain *med)
+{
+    return 0;
+}
+
+static inline int vm_event_claim_slot(struct domain *d,
+                                        struct vm_event_domain *med)
+{
+    return -ENOSYS;
+}
+
+static inline int vm_event_claim_slot_nosleep(struct domain *d,
+                                        struct vm_event_domain *med)
+{
+    return -ENOSYS;
+}
+
+static inline
+void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *med)
+{}
+
+static inline
+void vm_event_put_request(struct domain *d, struct vm_event_domain *med,
+                            vm_event_request_t *req)
+{}
+
+static inline
+int vm_event_get_response(struct domain *d, struct vm_event_domain *med,
+                           vm_event_response_t *rsp)
+{
+    return -ENOSYS;
+}
+
+static inline int do_vm_event_op(int op, uint32_t domain, void *arg)
+{
+    return -ENOSYS;
+}
+
+static inline
+int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *mec,
+                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
+{
+    return -ENOSYS;
+}
+
+static inline void vm_event_vcpu_pause(struct vcpu *v) {}
+static inline void vm_event_vcpu_unpause(struct vcpu *v) {}
+
+#endif /* HAS_MEM_ACCESS */
+
+#endif /* __MEM_EVENT_H__ */
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f20e89c..4227093 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -514,13 +514,13 @@ static XSM_INLINE int xsm_hvm_param_nested(XSM_DEFAULT_ARG struct domain *d)
 }
 
 #ifdef HAS_MEM_ACCESS
-static XSM_INLINE int xsm_mem_event_control(XSM_DEFAULT_ARG struct domain *d, int mode, int op)
+static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, int mode, int op)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
     return xsm_default_action(action, current->domain, d);
 }
 
-static XSM_INLINE int xsm_mem_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
+static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
 {
     XSM_ASSERT_ACTION(XSM_DM_PRIV);
     return xsm_default_action(action, current->domain, d);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4ce089f..cff9d35 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -142,8 +142,8 @@ struct xsm_operations {
     int (*get_vnumainfo) (struct domain *d);
 
 #ifdef HAS_MEM_ACCESS
-    int (*mem_event_control) (struct domain *d, int mode, int op);
-    int (*mem_event_op) (struct domain *d, int op);
+    int (*vm_event_control) (struct domain *d, int mode, int op);
+    int (*vm_event_op) (struct domain *d, int op);
 #endif
 
 #ifdef CONFIG_X86
@@ -544,14 +544,14 @@ static inline int xsm_get_vnumainfo (xsm_default_t def, struct domain *d)
 }
 
 #ifdef HAS_MEM_ACCESS
-static inline int xsm_mem_event_control (xsm_default_t def, struct domain *d, int mode, int op)
+static inline int xsm_vm_event_control (xsm_default_t def, struct domain *d, int mode, int op)
 {
-    return xsm_ops->mem_event_control(d, mode, op);
+    return xsm_ops->vm_event_control(d, mode, op);
 }
 
-static inline int xsm_mem_event_op (xsm_default_t def, struct domain *d, int op)
+static inline int xsm_vm_event_op (xsm_default_t def, struct domain *d, int op)
 {
-    return xsm_ops->mem_event_op(d, op);
+    return xsm_ops->vm_event_op(d, op);
 }
 #endif
 
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 8eb3050..25fca68 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -119,8 +119,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, map_gmfn_foreign);
 
 #ifdef HAS_MEM_ACCESS
-    set_to_dummy_if_null(ops, mem_event_control);
-    set_to_dummy_if_null(ops, mem_event_op);
+    set_to_dummy_if_null(ops, vm_event_control);
+    set_to_dummy_if_null(ops, vm_event_op);
 #endif
 
 #ifdef CONFIG_X86
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0ba2ce9..d706b1f 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -578,7 +578,7 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_set_target:
 #ifdef HAS_MEM_ACCESS
-    case XEN_DOMCTL_mem_event_op:
+    case XEN_DOMCTL_vm_event_op:
 #endif
 #ifdef CONFIG_X86
     /* These have individual XSM hooks (arch/x86/domctl.c) */
@@ -687,7 +687,7 @@ static int flask_domctl(struct domain *d, int cmd)
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
 
     case XEN_DOMCTL_set_access_required:
-        return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+        return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
 
     case XEN_DOMCTL_debug_op:
     case XEN_DOMCTL_gdbsx_guestmemio:
@@ -1201,14 +1201,14 @@ static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
 #endif /* HAS_PASSTHROUGH && HAS_PCI */
 
 #ifdef HAS_MEM_ACCESS
-static int flask_mem_event_control(struct domain *d, int mode, int op)
+static int flask_vm_event_control(struct domain *d, int mode, int op)
 {
-    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
 }
 
-static int flask_mem_event_op(struct domain *d, int op)
+static int flask_vm_event_op(struct domain *d, int op)
 {
-    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__VM_EVENT);
 }
 #endif /* HAS_MEM_ACCESS */
 
@@ -1595,8 +1595,8 @@ static struct xsm_operations flask_ops = {
 #endif
 
 #ifdef HAS_MEM_ACCESS
-    .mem_event_control = flask_mem_event_control,
-    .mem_event_op = flask_mem_event_op,
+    .vm_event_control = flask_vm_event_control,
+    .vm_event_op = flask_vm_event_op,
 #endif
 
 #ifdef CONFIG_X86
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1cd451e..452dd02 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -247,7 +247,7 @@ class hvm
 # HVMOP_inject_trap
     hvmctl
 # XEN_DOMCTL_set_access_required
-    mem_event
+    vm_event
 # XEN_DOMCTL_mem_sharing_op and XENMEM_sharing_op_{share,add_physmap} with:
 #  source = the domain making the hypercall
 #  target = domain whose memory is being shared
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:37:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZyd-0000fN-Bq; Wed, 12 Nov 2014 15:36:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <clark.laughlin@linaro.org>) id 1XoZyc-0000f1-77
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:36:58 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	FF/68-08051-89E73645; Wed, 12 Nov 2014 15:36:56 +0000
X-Env-Sender: clark.laughlin@linaro.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415806615!12001463!1
X-Originating-IP: [209.85.218.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19407 invoked from network); 12 Nov 2014 15:36:56 -0000
Received: from mail-oi0-f46.google.com (HELO mail-oi0-f46.google.com)
	(209.85.218.46)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:36:56 -0000
Received: by mail-oi0-f46.google.com with SMTP id g201so8730816oib.19
	for <xen-devel@lists.xenproject.org>;
	Wed, 12 Nov 2014 07:36:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=vI3JTNdTazqRkpJF7xnouQ6aQzuw+MFawzXafAhycLw=;
	b=WJW4Pp26YsLBV7a/oOczoDS78l4wswJXhFGPQIQ0bEVEjGn83+VBFcx2AM+NM9T+8d
	leE5MONabv9kmV3sIYzZZ4cJ0mIqht5IIw9iL8Gp34nnMNJ7v1Qclj90QYdqHcOlHauX
	PEdb1I5Aj/5z0qlFbXTok6tZjjMXouG4d9XeAi9ul9MOybsDnKxJMG2+RLqDPvj8uqKA
	Lm9dCBPHuzR7UU1Lv+cGmxzbRZtkH9eu1dhyuFO1vY5KHTf+3i2eQ0lOdzi79DTOD4Qd
	kTykljRF0IE76XWlJPeTm0FQ0TgSAfve6BIL9vYrEPCeYWWggGuFKVCjqHoggdKbQdlI
	t0Sg==
X-Gm-Message-State: ALoCoQkes8e9a7Y7unJGjQFUQ2QZmsp2IPCnPRgExs9Gd9bzTLBsqYc8iDVxra25JcPyn5FYIGAh
X-Received: by 10.202.71.66 with SMTP id u63mr36703104oia.54.1415806614894;
	Wed, 12 Nov 2014 07:36:54 -0800 (PST)
Received: from smith.hp-linaro.org
	(173-11-172-149-houston.txt.hfc.comcastbusiness.net.
	[173.11.172.149])
	by mx.google.com with ESMTPSA id ps7sm4539598obb.5.2014.11.12.07.36.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:36:53 -0800 (PST)
From: Clark Laughlin <clark.laughlin@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Wed, 12 Nov 2014 09:38:48 -0600
Message-Id: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
X-Mailer: git-send-email 1.9.1
Cc: Clark Laughlin <clark.laughlin@linaro.org>
Subject: [Xen-devel] [PATCH v2] mkdeb: correctly map package architectures
	for x86 and 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

mkdeb previously set the package architecture to be 'amd64' for anything other than
XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture from
GNU names to debian names for x86 and ARM architectures, or otherwise, defaults it
to the value in XEN_TARGET_ARCH.

Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>

---
Changed since v1: corrected commit message / subject
---
 tools/misc/mkdeb | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 3bbf881..4d14d9e 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -13,11 +13,16 @@ fi
 
 cd $1
 version=$2
-if test "$XEN_TARGET_ARCH" = "x86_32"; then
-  arch=i386
-else
-  arch=amd64
-fi
+
+# map the architecture, if necessary
+arch=$XEN_TARGET_ARCH
+case "$XEN_TARGET_ARCH" in
+  x86_32)  arch=i386 ;;
+  i686)    arch=i386 ;;
+  x86_64)  arch=amd64 ;;
+  arm32)   arch=armhf ;;
+  aarch64) arch=arm64 ;;
+esac
 
 # Prepare the directory to package
 cd dist
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:37:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoZyd-0000fN-Bq; Wed, 12 Nov 2014 15:36:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <clark.laughlin@linaro.org>) id 1XoZyc-0000f1-77
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:36:58 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	FF/68-08051-89E73645; Wed, 12 Nov 2014 15:36:56 +0000
X-Env-Sender: clark.laughlin@linaro.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415806615!12001463!1
X-Originating-IP: [209.85.218.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19407 invoked from network); 12 Nov 2014 15:36:56 -0000
Received: from mail-oi0-f46.google.com (HELO mail-oi0-f46.google.com)
	(209.85.218.46)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:36:56 -0000
Received: by mail-oi0-f46.google.com with SMTP id g201so8730816oib.19
	for <xen-devel@lists.xenproject.org>;
	Wed, 12 Nov 2014 07:36:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=vI3JTNdTazqRkpJF7xnouQ6aQzuw+MFawzXafAhycLw=;
	b=WJW4Pp26YsLBV7a/oOczoDS78l4wswJXhFGPQIQ0bEVEjGn83+VBFcx2AM+NM9T+8d
	leE5MONabv9kmV3sIYzZZ4cJ0mIqht5IIw9iL8Gp34nnMNJ7v1Qclj90QYdqHcOlHauX
	PEdb1I5Aj/5z0qlFbXTok6tZjjMXouG4d9XeAi9ul9MOybsDnKxJMG2+RLqDPvj8uqKA
	Lm9dCBPHuzR7UU1Lv+cGmxzbRZtkH9eu1dhyuFO1vY5KHTf+3i2eQ0lOdzi79DTOD4Qd
	kTykljRF0IE76XWlJPeTm0FQ0TgSAfve6BIL9vYrEPCeYWWggGuFKVCjqHoggdKbQdlI
	t0Sg==
X-Gm-Message-State: ALoCoQkes8e9a7Y7unJGjQFUQ2QZmsp2IPCnPRgExs9Gd9bzTLBsqYc8iDVxra25JcPyn5FYIGAh
X-Received: by 10.202.71.66 with SMTP id u63mr36703104oia.54.1415806614894;
	Wed, 12 Nov 2014 07:36:54 -0800 (PST)
Received: from smith.hp-linaro.org
	(173-11-172-149-houston.txt.hfc.comcastbusiness.net.
	[173.11.172.149])
	by mx.google.com with ESMTPSA id ps7sm4539598obb.5.2014.11.12.07.36.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 12 Nov 2014 07:36:53 -0800 (PST)
From: Clark Laughlin <clark.laughlin@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Wed, 12 Nov 2014 09:38:48 -0600
Message-Id: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
X-Mailer: git-send-email 1.9.1
Cc: Clark Laughlin <clark.laughlin@linaro.org>
Subject: [Xen-devel] [PATCH v2] mkdeb: correctly map package architectures
	for x86 and 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

mkdeb previously set the package architecture to be 'amd64' for anything other than
XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture from
GNU names to debian names for x86 and ARM architectures, or otherwise, defaults it
to the value in XEN_TARGET_ARCH.

Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>

---
Changed since v1: corrected commit message / subject
---
 tools/misc/mkdeb | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 3bbf881..4d14d9e 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -13,11 +13,16 @@ fi
 
 cd $1
 version=$2
-if test "$XEN_TARGET_ARCH" = "x86_32"; then
-  arch=i386
-else
-  arch=amd64
-fi
+
+# map the architecture, if necessary
+arch=$XEN_TARGET_ARCH
+case "$XEN_TARGET_ARCH" in
+  x86_32)  arch=i386 ;;
+  i686)    arch=i386 ;;
+  x86_64)  arch=amd64 ;;
+  arm32)   arch=armhf ;;
+  aarch64) arch=arm64 ;;
+esac
 
 # Prepare the directory to package
 cd dist
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:40:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1Xoa1u-0000pJ-W5; Wed, 12 Nov 2014 15:40:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xoa1t-0000pC-O2
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:40:21 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	1F/AC-23865-56F73645; Wed, 12 Nov 2014 15:40:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415806817!10924338!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30690 invoked from network); 12 Nov 2014 15:40:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:40:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190554208"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:40:12 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xoa1i-0007lk-2R;
	Wed, 12 Nov 2014 15:40:10 +0000
Date: Wed, 12 Nov 2014 15:40:10 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141112154003.GA1125@zion.uk.xensource.com>
References: <20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com> <1415803209.1155.10.camel@citrix.com>
	<54637326.6090908@oracle.com> <1415803976.1155.14.camel@citrix.com>
	<54637703.80906@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54637703.80906@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Wed, Nov 12, 2014 at 10:04:35AM -0500, Zhigang Wang wrote:
> On 11/12/2014 09:52 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> >> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> >>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> >>>> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
> >>>> time for xm/xend and xl: when VM fully migrated.
> >>>>
> >>>> The different between xm/xend and xl is: xend will populate destination side VM 
> >>>> xenstore entries at the beginning of migration.
> >>>
> >>> Do you mean *before* @introduceDomain has triggered?
> >>
> >> Yes, from my test. I didn't check the code logic yet.
> > 
> > I think anything which is trying to inspect the state of a domain before
> > the corresponding @introduceDomain and expecting anything more complex
> > than the fact of that domain's existence is broken.
> ...
> > IOW the json associated with such a domain should be:
> >     {
> >         "domid": 123,
> >         "config": {}
> >     }
> > Or even
> >     {
> >         "domid": 123,
> >     }
> > 
> > No more or less.
> 
> Here is the xl list output:
> 
>     # xl list
>     Name                                          ID   Mem VCPUs      State   Time(s)
>     Domain-0                                       0   856     4     r-----    2758.9
>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> 
> So we don't even want to match the two results?
>  

I can make some change in *xl*, when it knows a guest is actually there
but doesn't have a valid result returned from the new API, it generates
a stub by transforming the short result to json output.

This may solve your problem short term. It matches my intention of
"caller knows best about what to do when that API call fails", and
make short and long output consistent to a degree. However, your
toolstack is still prone to breakage in the long run.

I would like to suggest you modify your toolstack so that it
properly uses the interface provided by *libxl*.  If the interface /
machinery you need doesn't exist we can talk about it on xen-devel.

It just occurs to me that the use of @introduceDomain is very hard to
justify (not blaming you, just I'm not sure whether it should be used
like that). In any case, the thread should not develop into a long
discussion on what means what and what happens before / after what.

Wei.

> >> I designed a test: set eth0 to low speed:
> >>
> >>     $ ethtool -s eth0 speed 10 duplex half
> >>
> >> and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).
> > 
> > A couple of minutes after *starting* the migration (i.e. the couple of
> > minutes is just the time taken to migrate) or a couple of minutes after
> > *finishing* the migration (which would be unfortunate and should be
> > investigated).
> 
> Sorry I didn't say it clearly. I mean couple minutes after the migration started, but before the migration finish.
> 
> >From xend code xend/XendDomainInfo.py:
> 
> 
>     def completeRestore(self, store_mfn, console_mfn):
> 
>         log.debug("XendDomainInfo.completeRestore")
> 
>         self.store_mfn = store_mfn
>         self.console_mfn = console_mfn
> 
>         self._introduceDomain()
>         self.image = image.create(self, self.info)
>         if self.image:
>             self.image.createDeviceModel(True)
>         self._storeDomDetails()
>         self._registerWatches()
>         self.refreshShutdown()
> 
>         log.debug("XendDomainInfo.completeRestore done")
> 
> It seems the self._introduceDomain() does called at the end of migration after memory transfer.
> 
> Thanks,
> 
> Zhigang
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:40:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1Xoa1u-0000pJ-W5; Wed, 12 Nov 2014 15:40:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xoa1t-0000pC-O2
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:40:21 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	1F/AC-23865-56F73645; Wed, 12 Nov 2014 15:40:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415806817!10924338!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30690 invoked from network); 12 Nov 2014 15:40:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:40:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190554208"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:40:12 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xoa1i-0007lk-2R;
	Wed, 12 Nov 2014 15:40:10 +0000
Date: Wed, 12 Nov 2014 15:40:10 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141112154003.GA1125@zion.uk.xensource.com>
References: <20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com> <1415803209.1155.10.camel@citrix.com>
	<54637326.6090908@oracle.com> <1415803976.1155.14.camel@citrix.com>
	<54637703.80906@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54637703.80906@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Wed, Nov 12, 2014 at 10:04:35AM -0500, Zhigang Wang wrote:
> On 11/12/2014 09:52 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> >> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> >>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> >>>> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
> >>>> time for xm/xend and xl: when VM fully migrated.
> >>>>
> >>>> The different between xm/xend and xl is: xend will populate destination side VM 
> >>>> xenstore entries at the beginning of migration.
> >>>
> >>> Do you mean *before* @introduceDomain has triggered?
> >>
> >> Yes, from my test. I didn't check the code logic yet.
> > 
> > I think anything which is trying to inspect the state of a domain before
> > the corresponding @introduceDomain and expecting anything more complex
> > than the fact of that domain's existence is broken.
> ...
> > IOW the json associated with such a domain should be:
> >     {
> >         "domid": 123,
> >         "config": {}
> >     }
> > Or even
> >     {
> >         "domid": 123,
> >     }
> > 
> > No more or less.
> 
> Here is the xl list output:
> 
>     # xl list
>     Name                                          ID   Mem VCPUs      State   Time(s)
>     Domain-0                                       0   856     4     r-----    2758.9
>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> 
> So we don't even want to match the two results?
>  

I can make some change in *xl*, when it knows a guest is actually there
but doesn't have a valid result returned from the new API, it generates
a stub by transforming the short result to json output.

This may solve your problem short term. It matches my intention of
"caller knows best about what to do when that API call fails", and
make short and long output consistent to a degree. However, your
toolstack is still prone to breakage in the long run.

I would like to suggest you modify your toolstack so that it
properly uses the interface provided by *libxl*.  If the interface /
machinery you need doesn't exist we can talk about it on xen-devel.

It just occurs to me that the use of @introduceDomain is very hard to
justify (not blaming you, just I'm not sure whether it should be used
like that). In any case, the thread should not develop into a long
discussion on what means what and what happens before / after what.

Wei.

> >> I designed a test: set eth0 to low speed:
> >>
> >>     $ ethtool -s eth0 speed 10 duplex half
> >>
> >> and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).
> > 
> > A couple of minutes after *starting* the migration (i.e. the couple of
> > minutes is just the time taken to migrate) or a couple of minutes after
> > *finishing* the migration (which would be unfortunate and should be
> > investigated).
> 
> Sorry I didn't say it clearly. I mean couple minutes after the migration started, but before the migration finish.
> 
> >From xend code xend/XendDomainInfo.py:
> 
> 
>     def completeRestore(self, store_mfn, console_mfn):
> 
>         log.debug("XendDomainInfo.completeRestore")
> 
>         self.store_mfn = store_mfn
>         self.console_mfn = console_mfn
> 
>         self._introduceDomain()
>         self.image = image.create(self, self.info)
>         if self.image:
>             self.image.createDeviceModel(True)
>         self._storeDomDetails()
>         self._registerWatches()
>         self.refreshShutdown()
> 
>         log.debug("XendDomainInfo.completeRestore done")
> 
> It seems the self._introduceDomain() does called at the end of migration after memory transfer.
> 
> Thanks,
> 
> Zhigang
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:43:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:43:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoa5K-00016l-Q9; Wed, 12 Nov 2014 15:43: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 1Xoa5J-00016e-Go
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:43:53 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	88/75-02699-83083645; Wed, 12 Nov 2014 15:43:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415807028!12069522!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21903 invoked from network); 12 Nov 2014 15:43:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:43:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="192007005"
Message-ID: <1415807026.1155.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Clark Laughlin <clark.laughlin@linaro.org>
Date: Wed, 12 Nov 2014 15:43:46 +0000
In-Reply-To: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
References: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] mkdeb: correctly map package
 architectures for x86 and ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 09:38 -0600, Clark Laughlin wrote:
> mkdeb previously set the package architecture to be 'amd64' for anything other than
> XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture from
> GNU names to debian names for x86 and ARM architectures, or otherwise, defaults it
> to the value in XEN_TARGET_ARCH.
> 
> Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
> Changed since v1: corrected commit message / subject
> ---
>  tools/misc/mkdeb | 15 ++++++++++-----
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
> index 3bbf881..4d14d9e 100644
> --- a/tools/misc/mkdeb
> +++ b/tools/misc/mkdeb
> @@ -13,11 +13,16 @@ fi
>  
>  cd $1
>  version=$2
> -if test "$XEN_TARGET_ARCH" = "x86_32"; then
> -  arch=i386
> -else
> -  arch=amd64
> -fi
> +
> +# map the architecture, if necessary
> +arch=$XEN_TARGET_ARCH
> +case "$XEN_TARGET_ARCH" in
> +  x86_32)  arch=i386 ;;
> +  i686)    arch=i386 ;;
> +  x86_64)  arch=amd64 ;;
> +  arm32)   arch=armhf ;;
> +  aarch64) arch=arm64 ;;
> +esac
>  
>  # Prepare the directory to package
>  cd dist



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:43:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:43:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoa5K-00016l-Q9; Wed, 12 Nov 2014 15:43: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 1Xoa5J-00016e-Go
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:43:53 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	88/75-02699-83083645; Wed, 12 Nov 2014 15:43:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415807028!12069522!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21903 invoked from network); 12 Nov 2014 15:43:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:43:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="192007005"
Message-ID: <1415807026.1155.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Clark Laughlin <clark.laughlin@linaro.org>
Date: Wed, 12 Nov 2014 15:43:46 +0000
In-Reply-To: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
References: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] mkdeb: correctly map package
 architectures for x86 and ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 09:38 -0600, Clark Laughlin wrote:
> mkdeb previously set the package architecture to be 'amd64' for anything other than
> XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture from
> GNU names to debian names for x86 and ARM architectures, or otherwise, defaults it
> to the value in XEN_TARGET_ARCH.
> 
> Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
> Changed since v1: corrected commit message / subject
> ---
>  tools/misc/mkdeb | 15 ++++++++++-----
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
> index 3bbf881..4d14d9e 100644
> --- a/tools/misc/mkdeb
> +++ b/tools/misc/mkdeb
> @@ -13,11 +13,16 @@ fi
>  
>  cd $1
>  version=$2
> -if test "$XEN_TARGET_ARCH" = "x86_32"; then
> -  arch=i386
> -else
> -  arch=amd64
> -fi
> +
> +# map the architecture, if necessary
> +arch=$XEN_TARGET_ARCH
> +case "$XEN_TARGET_ARCH" in
> +  x86_32)  arch=i386 ;;
> +  i686)    arch=i386 ;;
> +  x86_64)  arch=amd64 ;;
> +  arm32)   arch=armhf ;;
> +  aarch64) arch=arm64 ;;
> +esac
>  
>  # Prepare the directory to package
>  cd dist



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:46:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1Xoa84-0001Eu-Bw; Wed, 12 Nov 2014 15:46:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xoa82-0001Ek-MP
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:46:42 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	35/D3-17694-1E083645; Wed, 12 Nov 2014 15:46:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415807199!10905049!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9539 invoked from network); 12 Nov 2014 15:46:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:46:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190556581"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <qemu-devel@nongnu.org>, <xen-devel@lists.xenproject.org>
Date: Wed, 12 Nov 2014 16:45:16 +0100
Message-ID: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
MIME-Version: 1.0
Content-Length: 5771
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, George Dunlap <george.dunlap@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyBwYXRjaCBmaXhlcyB0d28gaXNzdWVzIHdpdGggcGVyc2lzdGVudCBncmFudHMgYW5kIHRo
ZSBkaXNrIFBWIGJhY2tlbmQKKFFkaXNrKToKCiAtIERvbid0IHVzZSBiYXRjaCBtYXBwaW5ncyB3
aGVuIHVzaW5nIHBlcnNpc3RlbnQgZ3JhbnRzLCBkb2luZyBzbyBwcmV2ZW50cwogICB1bm1hcHBp
bmcgc2luZ2xlIGdyYW50cyAodGhlIHdob2xlIGFyZWEgaGFzIHRvIGJlIHVubWFwcGVkIGF0IG9u
Y2UpLgogLSBVbm1hcCBwZXJzaXN0ZW50IGdyYW50cyBiZWZvcmUgc3dpdGNoaW5nIHRvIHRoZSBj
bG9zZWQgc3RhdGUsIHNvIHRoZQogICBmcm9udGVuZCBjYW4gYWxzbyBmcmVlIHRoZW0uCgpTaWdu
ZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KUmVwb3J0
ZWQtYW5kLVRlc3RlZC1ieTogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXgu
Y29tPgpDYzogU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4
LmNvbT4KQ2M6IEtldmluIFdvbGYgPGt3b2xmQHJlZGhhdC5jb20+CkNjOiBTdGVmYW4gSGFqbm9j
emkgPHN0ZWZhbmhhQHJlZGhhdC5jb20+CkNjOiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFw
QGV1LmNpdHJpeC5jb20+Ci0tLQogaHcvYmxvY2sveGVuX2Rpc2suYyB8IDM1ICsrKysrKysrKysr
KysrKysrKysrKysrKy0tLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMjQgaW5zZXJ0aW9ucygr
KSwgMTEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvaHcvYmxvY2sveGVuX2Rpc2suYyBiL2h3
L2Jsb2NrL3hlbl9kaXNrLmMKaW5kZXggMjMxZTlhNy4uMTMwMGMwYSAxMDA2NDQKLS0tIGEvaHcv
YmxvY2sveGVuX2Rpc2suYworKysgYi9ody9ibG9jay94ZW5fZGlzay5jCkBAIC00Myw4ICs0Myw2
IEBACiAKIC8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0gKi8KIAotc3RhdGljIGludCBiYXRjaF9tYXBzICAgPSAwOwotCiBzdGF0
aWMgaW50IG1heF9yZXF1ZXN0cyA9IDMyOwogCiAvKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICovCkBAIC0xMDUsNiArMTAzLDcg
QEAgc3RydWN0IFhlbkJsa0RldiB7CiAgICAgYmxraWZfYmFja19yaW5nc190ICByaW5nczsKICAg
ICBpbnQgICAgICAgICAgICAgICAgIG1vcmVfd29yazsKICAgICBpbnQgICAgICAgICAgICAgICAg
IGNudF9tYXA7CisgICAgYm9vbCAgICAgICAgICAgICAgICBiYXRjaF9tYXBzOwogCiAgICAgLyog
cmVxdWVzdCBsaXN0cyAqLwogICAgIFFMSVNUX0hFQUQoaW5mbGlnaHRfaGVhZCwgaW9yZXEpIGlu
ZmxpZ2h0OwpAQCAtMzA5LDcgKzMwOCw3IEBAIHN0YXRpYyB2b2lkIGlvcmVxX3VubWFwKHN0cnVj
dCBpb3JlcSAqaW9yZXEpCiAgICAgaWYgKGlvcmVxLT5udW1fdW5tYXAgPT0gMCB8fCBpb3JlcS0+
bWFwcGVkID09IDApIHsKICAgICAgICAgcmV0dXJuOwogICAgIH0KLSAgICBpZiAoYmF0Y2hfbWFw
cykgeworICAgIGlmIChpb3JlcS0+YmxrZGV2LT5iYXRjaF9tYXBzKSB7CiAgICAgICAgIGlmICgh
aW9yZXEtPnBhZ2VzKSB7CiAgICAgICAgICAgICByZXR1cm47CiAgICAgICAgIH0KQEAgLTM4Niw3
ICszODUsNyBAQCBzdGF0aWMgaW50IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEgKmlvcmVxKQogICAg
ICAgICBuZXdfbWFwcyA9IGlvcmVxLT52Lm5pb3Y7CiAgICAgfQogCi0gICAgaWYgKGJhdGNoX21h
cHMgJiYgbmV3X21hcHMpIHsKKyAgICBpZiAoaW9yZXEtPmJsa2Rldi0+YmF0Y2hfbWFwcyAmJiBu
ZXdfbWFwcykgewogICAgICAgICBpb3JlcS0+cGFnZXMgPSB4Y19nbnR0YWJfbWFwX2dyYW50X3Jl
ZnMKICAgICAgICAgICAgIChnbnQsIG5ld19tYXBzLCBkb21pZHMsIHJlZnMsIGlvcmVxLT5wcm90
KTsKICAgICAgICAgaWYgKGlvcmVxLT5wYWdlcyA9PSBOVUxMKSB7CkBAIC00MzMsNyArNDMyLDcg
QEAgc3RhdGljIGludCBpb3JlcV9tYXAoc3RydWN0IGlvcmVxICppb3JlcSkKICAgICAgICAgICAg
ICAqLwogICAgICAgICAgICAgZ3JhbnQgPSBnX21hbGxvYzAoc2l6ZW9mKCpncmFudCkpOwogICAg
ICAgICAgICAgbmV3X21hcHMtLTsKLSAgICAgICAgICAgIGlmIChiYXRjaF9tYXBzKSB7CisgICAg
ICAgICAgICBpZiAoaW9yZXEtPmJsa2Rldi0+YmF0Y2hfbWFwcykgewogICAgICAgICAgICAgICAg
IGdyYW50LT5wYWdlID0gaW9yZXEtPnBhZ2VzICsgKG5ld19tYXBzKSAqIFhDX1BBR0VfU0laRTsK
ICAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAgICAgZ3JhbnQtPnBhZ2UgPSBpb3Jl
cS0+cGFnZVtuZXdfbWFwc107CkBAIC03MTgsNyArNzE3LDkgQEAgc3RhdGljIHZvaWQgYmxrX2Fs
bG9jKHN0cnVjdCBYZW5EZXZpY2UgKnhlbmRldikKICAgICBRTElTVF9JTklUKCZibGtkZXYtPmZy
ZWVsaXN0KTsKICAgICBibGtkZXYtPmJoID0gcWVtdV9iaF9uZXcoYmxrX2JoLCBibGtkZXYpOwog
ICAgIGlmICh4ZW5fbW9kZSAhPSBYRU5fRU1VTEFURSkgewotICAgICAgICBiYXRjaF9tYXBzID0g
MTsKKyAgICAgICAgYmxrZGV2LT5iYXRjaF9tYXBzID0gVFJVRTsKKyAgICB9IGVsc2UgeworICAg
ICAgICBibGtkZXYtPmJhdGNoX21hcHMgPSBGQUxTRTsKICAgICB9CiAgICAgaWYgKHhjX2dudHRh
Yl9zZXRfbWF4X2dyYW50cyh4ZW5kZXYtPmdudHRhYmRldiwKICAgICAgICAgICAgIE1BWF9HUkFO
VFMobWF4X3JlcXVlc3RzLCBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1QpKSA8IDApIHsK
QEAgLTkyMyw2ICs5MjQsMTMgQEAgc3RhdGljIGludCBibGtfY29ubmVjdChzdHJ1Y3QgWGVuRGV2
aWNlICp4ZW5kZXYpCiAgICAgfSBlbHNlIHsKICAgICAgICAgYmxrZGV2LT5mZWF0dXJlX3BlcnNp
c3RlbnQgPSAhIXBlcnM7CiAgICAgfQorICAgIGlmIChibGtkZXYtPmZlYXR1cmVfcGVyc2lzdGVu
dCkgeworICAgICAgICAvKgorICAgICAgICAgKiBEaXNhYmxlIGJhdGNoIG1hcHMsIHNpbmNlIHRo
YXQgd291bGQgcHJldmVudCB1bm1hcHBpbmcKKyAgICAgICAgICogc2luZ2xlIHBlcnNpc3RlbnQg
Z3JhbnRzLgorICAgICAgICAgKi8KKyAgICAgICAgYmxrZGV2LT5iYXRjaF9tYXBzID0gRkFMU0U7
CisgICAgfQogCiAgICAgYmxrZGV2LT5wcm90b2NvbCA9IEJMS0lGX1BST1RPQ09MX05BVElWRTsK
ICAgICBpZiAoYmxrZGV2LT54ZW5kZXYucHJvdG9jb2wpIHsKQEAgLTEwMDAsNiArMTAwOCwxNiBA
QCBzdGF0aWMgdm9pZCBibGtfZGlzY29ubmVjdChzdHJ1Y3QgWGVuRGV2aWNlICp4ZW5kZXYpCiAg
ICAgICAgIGJsa2Rldi0+Y250X21hcC0tOwogICAgICAgICBibGtkZXYtPnNyaW5nID0gTlVMTDsK
ICAgICB9CisKKyAgICAvKgorICAgICAqIFVubWFwIHBlcnNpc3RlbnQgZ3JhbnRzIGJlZm9yZSBz
d2l0Y2hpbmcgdG8gdGhlIGNsb3NlZCBzdGF0ZQorICAgICAqIHNvIHRoZSBmcm9udGVuZCBjYW4g
ZnJlZSB0aGVtLgorICAgICAqLworICAgIGlmIChibGtkZXYtPmZlYXR1cmVfcGVyc2lzdGVudCkg
eworICAgICAgICBnX3RyZWVfZGVzdHJveShibGtkZXYtPnBlcnNpc3RlbnRfZ250cyk7CisgICAg
ICAgIGFzc2VydChibGtkZXYtPnBlcnNpc3RlbnRfZ250X2NvdW50ID09IDApOworICAgICAgICBi
bGtkZXYtPmZlYXR1cmVfcGVyc2lzdGVudCA9IEZBTFNFOworICAgIH0KIH0KIAogc3RhdGljIGlu
dCBibGtfZnJlZShzdHJ1Y3QgWGVuRGV2aWNlICp4ZW5kZXYpCkBAIC0xMDExLDExICsxMDI5LDYg
QEAgc3RhdGljIGludCBibGtfZnJlZShzdHJ1Y3QgWGVuRGV2aWNlICp4ZW5kZXYpCiAgICAgICAg
IGJsa19kaXNjb25uZWN0KHhlbmRldik7CiAgICAgfQogCi0gICAgLyogRnJlZSBwZXJzaXN0ZW50
IGdyYW50cyAqLwotICAgIGlmIChibGtkZXYtPmZlYXR1cmVfcGVyc2lzdGVudCkgewotICAgICAg
ICBnX3RyZWVfZGVzdHJveShibGtkZXYtPnBlcnNpc3RlbnRfZ250cyk7Ci0gICAgfQotCiAgICAg
d2hpbGUgKCFRTElTVF9FTVBUWSgmYmxrZGV2LT5mcmVlbGlzdCkpIHsKICAgICAgICAgaW9yZXEg
PSBRTElTVF9GSVJTVCgmYmxrZGV2LT5mcmVlbGlzdCk7CiAgICAgICAgIFFMSVNUX1JFTU9WRShp
b3JlcSwgbGlzdCk7Ci0tIAoxLjkuMyAoQXBwbGUgR2l0LTUwKQoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:46:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15: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 1Xoa84-0001Eu-Bw; Wed, 12 Nov 2014 15:46:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xoa82-0001Ek-MP
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:46:42 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	35/D3-17694-1E083645; Wed, 12 Nov 2014 15:46:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415807199!10905049!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9539 invoked from network); 12 Nov 2014 15:46:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:46:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190556581"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <qemu-devel@nongnu.org>, <xen-devel@lists.xenproject.org>
Date: Wed, 12 Nov 2014 16:45:16 +0100
Message-ID: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
MIME-Version: 1.0
Content-Length: 5771
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, George Dunlap <george.dunlap@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyBwYXRjaCBmaXhlcyB0d28gaXNzdWVzIHdpdGggcGVyc2lzdGVudCBncmFudHMgYW5kIHRo
ZSBkaXNrIFBWIGJhY2tlbmQKKFFkaXNrKToKCiAtIERvbid0IHVzZSBiYXRjaCBtYXBwaW5ncyB3
aGVuIHVzaW5nIHBlcnNpc3RlbnQgZ3JhbnRzLCBkb2luZyBzbyBwcmV2ZW50cwogICB1bm1hcHBp
bmcgc2luZ2xlIGdyYW50cyAodGhlIHdob2xlIGFyZWEgaGFzIHRvIGJlIHVubWFwcGVkIGF0IG9u
Y2UpLgogLSBVbm1hcCBwZXJzaXN0ZW50IGdyYW50cyBiZWZvcmUgc3dpdGNoaW5nIHRvIHRoZSBj
bG9zZWQgc3RhdGUsIHNvIHRoZQogICBmcm9udGVuZCBjYW4gYWxzbyBmcmVlIHRoZW0uCgpTaWdu
ZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KUmVwb3J0
ZWQtYW5kLVRlc3RlZC1ieTogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXgu
Y29tPgpDYzogU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4
LmNvbT4KQ2M6IEtldmluIFdvbGYgPGt3b2xmQHJlZGhhdC5jb20+CkNjOiBTdGVmYW4gSGFqbm9j
emkgPHN0ZWZhbmhhQHJlZGhhdC5jb20+CkNjOiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFw
QGV1LmNpdHJpeC5jb20+Ci0tLQogaHcvYmxvY2sveGVuX2Rpc2suYyB8IDM1ICsrKysrKysrKysr
KysrKysrKysrKysrKy0tLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMjQgaW5zZXJ0aW9ucygr
KSwgMTEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvaHcvYmxvY2sveGVuX2Rpc2suYyBiL2h3
L2Jsb2NrL3hlbl9kaXNrLmMKaW5kZXggMjMxZTlhNy4uMTMwMGMwYSAxMDA2NDQKLS0tIGEvaHcv
YmxvY2sveGVuX2Rpc2suYworKysgYi9ody9ibG9jay94ZW5fZGlzay5jCkBAIC00Myw4ICs0Myw2
IEBACiAKIC8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0gKi8KIAotc3RhdGljIGludCBiYXRjaF9tYXBzICAgPSAwOwotCiBzdGF0
aWMgaW50IG1heF9yZXF1ZXN0cyA9IDMyOwogCiAvKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICovCkBAIC0xMDUsNiArMTAzLDcg
QEAgc3RydWN0IFhlbkJsa0RldiB7CiAgICAgYmxraWZfYmFja19yaW5nc190ICByaW5nczsKICAg
ICBpbnQgICAgICAgICAgICAgICAgIG1vcmVfd29yazsKICAgICBpbnQgICAgICAgICAgICAgICAg
IGNudF9tYXA7CisgICAgYm9vbCAgICAgICAgICAgICAgICBiYXRjaF9tYXBzOwogCiAgICAgLyog
cmVxdWVzdCBsaXN0cyAqLwogICAgIFFMSVNUX0hFQUQoaW5mbGlnaHRfaGVhZCwgaW9yZXEpIGlu
ZmxpZ2h0OwpAQCAtMzA5LDcgKzMwOCw3IEBAIHN0YXRpYyB2b2lkIGlvcmVxX3VubWFwKHN0cnVj
dCBpb3JlcSAqaW9yZXEpCiAgICAgaWYgKGlvcmVxLT5udW1fdW5tYXAgPT0gMCB8fCBpb3JlcS0+
bWFwcGVkID09IDApIHsKICAgICAgICAgcmV0dXJuOwogICAgIH0KLSAgICBpZiAoYmF0Y2hfbWFw
cykgeworICAgIGlmIChpb3JlcS0+YmxrZGV2LT5iYXRjaF9tYXBzKSB7CiAgICAgICAgIGlmICgh
aW9yZXEtPnBhZ2VzKSB7CiAgICAgICAgICAgICByZXR1cm47CiAgICAgICAgIH0KQEAgLTM4Niw3
ICszODUsNyBAQCBzdGF0aWMgaW50IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEgKmlvcmVxKQogICAg
ICAgICBuZXdfbWFwcyA9IGlvcmVxLT52Lm5pb3Y7CiAgICAgfQogCi0gICAgaWYgKGJhdGNoX21h
cHMgJiYgbmV3X21hcHMpIHsKKyAgICBpZiAoaW9yZXEtPmJsa2Rldi0+YmF0Y2hfbWFwcyAmJiBu
ZXdfbWFwcykgewogICAgICAgICBpb3JlcS0+cGFnZXMgPSB4Y19nbnR0YWJfbWFwX2dyYW50X3Jl
ZnMKICAgICAgICAgICAgIChnbnQsIG5ld19tYXBzLCBkb21pZHMsIHJlZnMsIGlvcmVxLT5wcm90
KTsKICAgICAgICAgaWYgKGlvcmVxLT5wYWdlcyA9PSBOVUxMKSB7CkBAIC00MzMsNyArNDMyLDcg
QEAgc3RhdGljIGludCBpb3JlcV9tYXAoc3RydWN0IGlvcmVxICppb3JlcSkKICAgICAgICAgICAg
ICAqLwogICAgICAgICAgICAgZ3JhbnQgPSBnX21hbGxvYzAoc2l6ZW9mKCpncmFudCkpOwogICAg
ICAgICAgICAgbmV3X21hcHMtLTsKLSAgICAgICAgICAgIGlmIChiYXRjaF9tYXBzKSB7CisgICAg
ICAgICAgICBpZiAoaW9yZXEtPmJsa2Rldi0+YmF0Y2hfbWFwcykgewogICAgICAgICAgICAgICAg
IGdyYW50LT5wYWdlID0gaW9yZXEtPnBhZ2VzICsgKG5ld19tYXBzKSAqIFhDX1BBR0VfU0laRTsK
ICAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAgICAgZ3JhbnQtPnBhZ2UgPSBpb3Jl
cS0+cGFnZVtuZXdfbWFwc107CkBAIC03MTgsNyArNzE3LDkgQEAgc3RhdGljIHZvaWQgYmxrX2Fs
bG9jKHN0cnVjdCBYZW5EZXZpY2UgKnhlbmRldikKICAgICBRTElTVF9JTklUKCZibGtkZXYtPmZy
ZWVsaXN0KTsKICAgICBibGtkZXYtPmJoID0gcWVtdV9iaF9uZXcoYmxrX2JoLCBibGtkZXYpOwog
ICAgIGlmICh4ZW5fbW9kZSAhPSBYRU5fRU1VTEFURSkgewotICAgICAgICBiYXRjaF9tYXBzID0g
MTsKKyAgICAgICAgYmxrZGV2LT5iYXRjaF9tYXBzID0gVFJVRTsKKyAgICB9IGVsc2UgeworICAg
ICAgICBibGtkZXYtPmJhdGNoX21hcHMgPSBGQUxTRTsKICAgICB9CiAgICAgaWYgKHhjX2dudHRh
Yl9zZXRfbWF4X2dyYW50cyh4ZW5kZXYtPmdudHRhYmRldiwKICAgICAgICAgICAgIE1BWF9HUkFO
VFMobWF4X3JlcXVlc3RzLCBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1QpKSA8IDApIHsK
QEAgLTkyMyw2ICs5MjQsMTMgQEAgc3RhdGljIGludCBibGtfY29ubmVjdChzdHJ1Y3QgWGVuRGV2
aWNlICp4ZW5kZXYpCiAgICAgfSBlbHNlIHsKICAgICAgICAgYmxrZGV2LT5mZWF0dXJlX3BlcnNp
c3RlbnQgPSAhIXBlcnM7CiAgICAgfQorICAgIGlmIChibGtkZXYtPmZlYXR1cmVfcGVyc2lzdGVu
dCkgeworICAgICAgICAvKgorICAgICAgICAgKiBEaXNhYmxlIGJhdGNoIG1hcHMsIHNpbmNlIHRo
YXQgd291bGQgcHJldmVudCB1bm1hcHBpbmcKKyAgICAgICAgICogc2luZ2xlIHBlcnNpc3RlbnQg
Z3JhbnRzLgorICAgICAgICAgKi8KKyAgICAgICAgYmxrZGV2LT5iYXRjaF9tYXBzID0gRkFMU0U7
CisgICAgfQogCiAgICAgYmxrZGV2LT5wcm90b2NvbCA9IEJMS0lGX1BST1RPQ09MX05BVElWRTsK
ICAgICBpZiAoYmxrZGV2LT54ZW5kZXYucHJvdG9jb2wpIHsKQEAgLTEwMDAsNiArMTAwOCwxNiBA
QCBzdGF0aWMgdm9pZCBibGtfZGlzY29ubmVjdChzdHJ1Y3QgWGVuRGV2aWNlICp4ZW5kZXYpCiAg
ICAgICAgIGJsa2Rldi0+Y250X21hcC0tOwogICAgICAgICBibGtkZXYtPnNyaW5nID0gTlVMTDsK
ICAgICB9CisKKyAgICAvKgorICAgICAqIFVubWFwIHBlcnNpc3RlbnQgZ3JhbnRzIGJlZm9yZSBz
d2l0Y2hpbmcgdG8gdGhlIGNsb3NlZCBzdGF0ZQorICAgICAqIHNvIHRoZSBmcm9udGVuZCBjYW4g
ZnJlZSB0aGVtLgorICAgICAqLworICAgIGlmIChibGtkZXYtPmZlYXR1cmVfcGVyc2lzdGVudCkg
eworICAgICAgICBnX3RyZWVfZGVzdHJveShibGtkZXYtPnBlcnNpc3RlbnRfZ250cyk7CisgICAg
ICAgIGFzc2VydChibGtkZXYtPnBlcnNpc3RlbnRfZ250X2NvdW50ID09IDApOworICAgICAgICBi
bGtkZXYtPmZlYXR1cmVfcGVyc2lzdGVudCA9IEZBTFNFOworICAgIH0KIH0KIAogc3RhdGljIGlu
dCBibGtfZnJlZShzdHJ1Y3QgWGVuRGV2aWNlICp4ZW5kZXYpCkBAIC0xMDExLDExICsxMDI5LDYg
QEAgc3RhdGljIGludCBibGtfZnJlZShzdHJ1Y3QgWGVuRGV2aWNlICp4ZW5kZXYpCiAgICAgICAg
IGJsa19kaXNjb25uZWN0KHhlbmRldik7CiAgICAgfQogCi0gICAgLyogRnJlZSBwZXJzaXN0ZW50
IGdyYW50cyAqLwotICAgIGlmIChibGtkZXYtPmZlYXR1cmVfcGVyc2lzdGVudCkgewotICAgICAg
ICBnX3RyZWVfZGVzdHJveShibGtkZXYtPnBlcnNpc3RlbnRfZ250cyk7Ci0gICAgfQotCiAgICAg
d2hpbGUgKCFRTElTVF9FTVBUWSgmYmxrZGV2LT5mcmVlbGlzdCkpIHsKICAgICAgICAgaW9yZXEg
PSBRTElTVF9GSVJTVCgmYmxrZGV2LT5mcmVlbGlzdCk7CiAgICAgICAgIFFMSVNUX1JFTU9WRShp
b3JlcSwgbGlzdCk7Ci0tIAoxLjkuMyAoQXBwbGUgR2l0LTUwKQoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:48:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:48:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoa9h-0001LH-Rd; Wed, 12 Nov 2014 15:48:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1Xoa9g-0001LB-Ri
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:48:25 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	B8/FF-02954-84183645; Wed, 12 Nov 2014 15:48:24 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415807301!12101203!1
X-Originating-IP: [209.85.223.169]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17840 invoked from network); 12 Nov 2014 15:48:22 -0000
Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com)
	(209.85.223.169)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:48:22 -0000
Received: by mail-ie0-f169.google.com with SMTP id tr6so13977716ieb.28
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:48:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=jFtJsHXC9xaGjQ3ciGHfGgYBCCdyZQ0yoSJ+0r1qxnk=;
	b=KwKEtQOfqiFUM+evD8iv5KGlUgGYmxx7oTPryvFkx1uHT81pCM8EHwVlL079XrSbvR
	d2LqkIh49CxXu1D8lCjRPVE+GWTGodNItLZlkVJHH8IxZ8TPtoylNFEayVcItQriNO0w
	d/FlkFqbfOWeoDxXARPeowqqWerZo85mcGpbXbiYAQF01l4UiTkkhI8EQd77O79HdwO3
	dEd3htbp4rbPFajMW2n1jbDzLqwW6V8wWMZBRQ9tWQMDD6Bnys1BBaYkpRCZz/arI5wT
	RwlEtWKePSmmngllA+vdv0VtmbNSWYI63eoakZkhSR1i2YtHe/7arHiT0eVRnj0Ld2CH
	Nxjw==
X-Received: by 10.107.15.213 with SMTP id 82mr3243253iop.63.1415807301575;
	Wed, 12 Nov 2014 07:48:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.239.77 with HTTP; Wed, 12 Nov 2014 07:47:41 -0800 (PST)
In-Reply-To: <54591EB8.4070007@citrix.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
	<54591EB8.4070007@citrix.com>
From: Shriram Rajagopalan <rshriram@gmail.com>
Date: Wed, 12 Nov 2014 10:47:41 -0500
Message-ID: <CAP8mzPPbkWWWPvuBkiLxREh-o-n5wQQ7Q2fxinHdv5M0+3rneg@mail.gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: wei.liu2@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	guijianfeng@cn.fujitsu.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	FNST-Yang Hongyang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1165001160582286698=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1165001160582286698==
Content-Type: multipart/alternative; boundary=001a113fdb344826de0507ab53c7

--001a113fdb344826de0507ab53c7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 4, 2014 at 1:45 PM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 04/11/14 18:42, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 04, 2014 at 06:07:19PM +0000, Andrew Cooper wrote:
> >> On 04/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> >>> On Tue, Nov 04, 2014 at 11:52:47AM +0000, Ian Campbell wrote:
> >>>> This was disabled by default in Xen 4.4. Since xend has now been
> removed from
> >>>> the tree I don't believe anything is using it.
> >>> What about XenServer?
> >> We are most definitely not using it, and haven=E2=80=99t used it in a =
very long
> >> time. We explicitly nuke BLKTAP1 and BLKTAP2 from the Xen build.
> >>
> >>> And isn't there some blktap3 ?
> >> https://github.com/xapi-project/blktap
> >>
> >>>> We need to pass an explicit CONFIG_BLKTAP1=3Dn to qemu-xen-tradition=
al
> otherwise
> >>>> it defaults to y and doesn't build.
> >>>>
> >>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>> ---
> >>>> I think this has probably missed the boat for 4.5 and there isn't
> much harm in
> >>>> waiting for 4.6. I'm open to being told otherwise though ;-)
> >>> You really want to be at the top of the commit list with the most
> deleted
> >>> code, eh?
> >> /me suspects that he is already, but I for one am a fan of pruning dea=
d
> >> code.
> > True, but we did talk about xend removal for quite a while before doing
> it.
> >
> > However, I believe that the folks that did Remus look to be using it
> > (And they have tons of patches against it).
> >
> >
> >    It is unclear to me whether they:
> >       - want to be the maintainers of it?
> >       - want to use blktap3 but haven't yet backported their patches.
>
> The remus patches are against blktap2, not blktap1.  We currently have
> both in-tree.
>
>
More like prep patches for COLO stuff. No one that I am aware of is using
blktap2 with Remus.
So if blktap2 is being kept around just for Remus' sake, please feel free
to axe it.


> ~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--001a113fdb344826de0507ab53c7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Nov 4, 2014 at 1:45 PM, 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:1px #ccc solid;padding-left:1ex"><div cla=
ss=3D"HOEnZb"><div class=3D"h5">On 04/11/14 18:42, Konrad Rzeszutek Wilk wr=
ote:<br>
&gt; On Tue, Nov 04, 2014 at 06:07:19PM +0000, Andrew Cooper wrote:<br>
&gt;&gt; On 04/11/14 17:32, Konrad Rzeszutek Wilk wrote:<br>
&gt;&gt;&gt; On Tue, Nov 04, 2014 at 11:52:47AM +0000, Ian Campbell wrote:<=
br>
&gt;&gt;&gt;&gt; This was disabled by default in Xen 4.4. Since xend has no=
w been removed from<br>
&gt;&gt;&gt;&gt; the tree I don&#39;t believe anything is using it.<br>
&gt;&gt;&gt; What about XenServer?<br>
&gt;&gt; We are most definitely not using it, and haven=E2=80=99t used it i=
n a very long<br>
&gt;&gt; time. We explicitly nuke BLKTAP1 and BLKTAP2 from the Xen build.<b=
r>
&gt;&gt;<br>
&gt;&gt;&gt; And isn&#39;t there some blktap3 ?<br>
&gt;&gt; <a href=3D"https://github.com/xapi-project/blktap" target=3D"_blan=
k">https://github.com/xapi-project/blktap</a><br>
&gt;&gt;<br>
&gt;&gt;&gt;&gt; We need to pass an explicit CONFIG_BLKTAP1=3Dn to qemu-xen=
-traditional otherwise<br>
&gt;&gt;&gt;&gt; it defaults to y and doesn&#39;t build.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Signed-off-by: Ian Campbell &lt;<a href=3D"mailto:ian.camp=
bell@citrix.com">ian.campbell@citrix.com</a>&gt;<br>
&gt;&gt;&gt;&gt; Cc: Konrad Rzeszutek Wilk &lt;<a href=3D"mailto:konrad.wil=
k@oracle.com">konrad.wilk@oracle.com</a>&gt;<br>
&gt;&gt;&gt;&gt; ---<br>
&gt;&gt;&gt;&gt; I think this has probably missed the boat for 4.5 and ther=
e isn&#39;t much harm in<br>
&gt;&gt;&gt;&gt; waiting for 4.6. I&#39;m open to being told otherwise thou=
gh ;-)<br>
&gt;&gt;&gt; You really want to be at the top of the commit list with the m=
ost deleted<br>
&gt;&gt;&gt; code, eh?<br>
&gt;&gt; /me suspects that he is already, but I for one am a fan of pruning=
 dead<br>
&gt;&gt; code.<br>
&gt; True, but we did talk about xend removal for quite a while before doin=
g it.<br>
&gt;<br>
&gt; However, I believe that the folks that did Remus look to be using it<b=
r>
&gt; (And they have tons of patches against it).<br>
&gt;<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 It is unclear to me whether they:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0- want to be the maintainers of it?<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0- want to use blktap3 but haven&#39;t yet ba=
ckported their patches.<br>
<br>
</div></div>The remus patches are against blktap2, not blktap1.=C2=A0 We cu=
rrently have<br>
both in-tree.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>More like prep patches for COLO stuff. No one that I am aware=
 of is using blktap2 with Remus.</div><div>So if blktap2 is being kept arou=
nd just for Remus&#39; sake, please feel free to axe it.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">
~Andrew<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div><br></div></div>

--001a113fdb344826de0507ab53c7--


--===============1165001160582286698==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1165001160582286698==--


From xen-devel-bounces@lists.xen.org Wed Nov 12 15:48:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:48:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoa9h-0001LH-Rd; Wed, 12 Nov 2014 15:48:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1Xoa9g-0001LB-Ri
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:48:25 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	B8/FF-02954-84183645; Wed, 12 Nov 2014 15:48:24 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415807301!12101203!1
X-Originating-IP: [209.85.223.169]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17840 invoked from network); 12 Nov 2014 15:48:22 -0000
Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com)
	(209.85.223.169)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:48:22 -0000
Received: by mail-ie0-f169.google.com with SMTP id tr6so13977716ieb.28
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 07:48:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=jFtJsHXC9xaGjQ3ciGHfGgYBCCdyZQ0yoSJ+0r1qxnk=;
	b=KwKEtQOfqiFUM+evD8iv5KGlUgGYmxx7oTPryvFkx1uHT81pCM8EHwVlL079XrSbvR
	d2LqkIh49CxXu1D8lCjRPVE+GWTGodNItLZlkVJHH8IxZ8TPtoylNFEayVcItQriNO0w
	d/FlkFqbfOWeoDxXARPeowqqWerZo85mcGpbXbiYAQF01l4UiTkkhI8EQd77O79HdwO3
	dEd3htbp4rbPFajMW2n1jbDzLqwW6V8wWMZBRQ9tWQMDD6Bnys1BBaYkpRCZz/arI5wT
	RwlEtWKePSmmngllA+vdv0VtmbNSWYI63eoakZkhSR1i2YtHe/7arHiT0eVRnj0Ld2CH
	Nxjw==
X-Received: by 10.107.15.213 with SMTP id 82mr3243253iop.63.1415807301575;
	Wed, 12 Nov 2014 07:48:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.239.77 with HTTP; Wed, 12 Nov 2014 07:47:41 -0800 (PST)
In-Reply-To: <54591EB8.4070007@citrix.com>
References: <1415101967-9844-1-git-send-email-ian.campbell@citrix.com>
	<20141104173228.GM4510@laptop.dumpdata.com>
	<545915D7.2070804@citrix.com>
	<20141104184209.GT4510@laptop.dumpdata.com>
	<54591EB8.4070007@citrix.com>
From: Shriram Rajagopalan <rshriram@gmail.com>
Date: Wed, 12 Nov 2014 10:47:41 -0500
Message-ID: <CAP8mzPPbkWWWPvuBkiLxREh-o-n5wQQ7Q2fxinHdv5M0+3rneg@mail.gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: wei.liu2@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	guijianfeng@cn.fujitsu.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	FNST-Yang Hongyang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Is: Discussion about doing it in Xen 4.5 or Xen 4.6
 Was:Re: [PATCH] tools: remove blktap1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1165001160582286698=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1165001160582286698==
Content-Type: multipart/alternative; boundary=001a113fdb344826de0507ab53c7

--001a113fdb344826de0507ab53c7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 4, 2014 at 1:45 PM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 04/11/14 18:42, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 04, 2014 at 06:07:19PM +0000, Andrew Cooper wrote:
> >> On 04/11/14 17:32, Konrad Rzeszutek Wilk wrote:
> >>> On Tue, Nov 04, 2014 at 11:52:47AM +0000, Ian Campbell wrote:
> >>>> This was disabled by default in Xen 4.4. Since xend has now been
> removed from
> >>>> the tree I don't believe anything is using it.
> >>> What about XenServer?
> >> We are most definitely not using it, and haven=E2=80=99t used it in a =
very long
> >> time. We explicitly nuke BLKTAP1 and BLKTAP2 from the Xen build.
> >>
> >>> And isn't there some blktap3 ?
> >> https://github.com/xapi-project/blktap
> >>
> >>>> We need to pass an explicit CONFIG_BLKTAP1=3Dn to qemu-xen-tradition=
al
> otherwise
> >>>> it defaults to y and doesn't build.
> >>>>
> >>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>> ---
> >>>> I think this has probably missed the boat for 4.5 and there isn't
> much harm in
> >>>> waiting for 4.6. I'm open to being told otherwise though ;-)
> >>> You really want to be at the top of the commit list with the most
> deleted
> >>> code, eh?
> >> /me suspects that he is already, but I for one am a fan of pruning dea=
d
> >> code.
> > True, but we did talk about xend removal for quite a while before doing
> it.
> >
> > However, I believe that the folks that did Remus look to be using it
> > (And they have tons of patches against it).
> >
> >
> >    It is unclear to me whether they:
> >       - want to be the maintainers of it?
> >       - want to use blktap3 but haven't yet backported their patches.
>
> The remus patches are against blktap2, not blktap1.  We currently have
> both in-tree.
>
>
More like prep patches for COLO stuff. No one that I am aware of is using
blktap2 with Remus.
So if blktap2 is being kept around just for Remus' sake, please feel free
to axe it.


> ~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--001a113fdb344826de0507ab53c7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Nov 4, 2014 at 1:45 PM, 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:1px #ccc solid;padding-left:1ex"><div cla=
ss=3D"HOEnZb"><div class=3D"h5">On 04/11/14 18:42, Konrad Rzeszutek Wilk wr=
ote:<br>
&gt; On Tue, Nov 04, 2014 at 06:07:19PM +0000, Andrew Cooper wrote:<br>
&gt;&gt; On 04/11/14 17:32, Konrad Rzeszutek Wilk wrote:<br>
&gt;&gt;&gt; On Tue, Nov 04, 2014 at 11:52:47AM +0000, Ian Campbell wrote:<=
br>
&gt;&gt;&gt;&gt; This was disabled by default in Xen 4.4. Since xend has no=
w been removed from<br>
&gt;&gt;&gt;&gt; the tree I don&#39;t believe anything is using it.<br>
&gt;&gt;&gt; What about XenServer?<br>
&gt;&gt; We are most definitely not using it, and haven=E2=80=99t used it i=
n a very long<br>
&gt;&gt; time. We explicitly nuke BLKTAP1 and BLKTAP2 from the Xen build.<b=
r>
&gt;&gt;<br>
&gt;&gt;&gt; And isn&#39;t there some blktap3 ?<br>
&gt;&gt; <a href=3D"https://github.com/xapi-project/blktap" target=3D"_blan=
k">https://github.com/xapi-project/blktap</a><br>
&gt;&gt;<br>
&gt;&gt;&gt;&gt; We need to pass an explicit CONFIG_BLKTAP1=3Dn to qemu-xen=
-traditional otherwise<br>
&gt;&gt;&gt;&gt; it defaults to y and doesn&#39;t build.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Signed-off-by: Ian Campbell &lt;<a href=3D"mailto:ian.camp=
bell@citrix.com">ian.campbell@citrix.com</a>&gt;<br>
&gt;&gt;&gt;&gt; Cc: Konrad Rzeszutek Wilk &lt;<a href=3D"mailto:konrad.wil=
k@oracle.com">konrad.wilk@oracle.com</a>&gt;<br>
&gt;&gt;&gt;&gt; ---<br>
&gt;&gt;&gt;&gt; I think this has probably missed the boat for 4.5 and ther=
e isn&#39;t much harm in<br>
&gt;&gt;&gt;&gt; waiting for 4.6. I&#39;m open to being told otherwise thou=
gh ;-)<br>
&gt;&gt;&gt; You really want to be at the top of the commit list with the m=
ost deleted<br>
&gt;&gt;&gt; code, eh?<br>
&gt;&gt; /me suspects that he is already, but I for one am a fan of pruning=
 dead<br>
&gt;&gt; code.<br>
&gt; True, but we did talk about xend removal for quite a while before doin=
g it.<br>
&gt;<br>
&gt; However, I believe that the folks that did Remus look to be using it<b=
r>
&gt; (And they have tons of patches against it).<br>
&gt;<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 It is unclear to me whether they:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0- want to be the maintainers of it?<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0- want to use blktap3 but haven&#39;t yet ba=
ckported their patches.<br>
<br>
</div></div>The remus patches are against blktap2, not blktap1.=C2=A0 We cu=
rrently have<br>
both in-tree.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>More like prep patches for COLO stuff. No one that I am aware=
 of is using blktap2 with Remus.</div><div>So if blktap2 is being kept arou=
nd just for Remus&#39; sake, please feel free to axe it.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">
~Andrew<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div><br></div></div>

--001a113fdb344826de0507ab53c7--


--===============1165001160582286698==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1165001160582286698==--


From xen-devel-bounces@lists.xen.org Wed Nov 12 15:49:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoaAF-0001OV-8d; Wed, 12 Nov 2014 15:48:59 +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 1XoaAD-0001OK-SH
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:48:57 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	4A/94-25714-96183645; Wed, 12 Nov 2014 15:48:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415807334!10918693!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16182 invoked from network); 12 Nov 2014 15:48:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:48:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="192009010"
Message-ID: <54638141.3010500@citrix.com>
Date: Wed, 12 Nov 2014 15:48:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Tamas K Lengyel <tamas.lengyel@zentific.com>, <xen-devel@lists.xen.org>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
X-DLP: MIA1
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org,
	jun.nakajima@intel.com, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 15:31, Tamas K Lengyel wrote:
> This patch series aims to clean up the mem_event subsystem within Xen. The
> original use-case for this system was to allow external helper applications
> running in privileged domains to control various memory operations performed
> by Xen. Amongs these were paging, sharing and access control. The subsystem
> has since been extended to also deliver non-memory related events, namely
> various HVM debugging events (INT3, MTF, MOV-TO-CR). The structures and naming
> of related functions however has not caught up to these new use-cases, thus
> leaving many ambigouities in the code.
>
> In this series we convert the mem_event structures to a union of sub-structures
> which clearly define the scope of information that is transmitted via the event
> delivery mechanism. Afterwards, we clean up the naming of the structures and
> related functions to more clearly be in line with their actual operations.
>
> This PATCH RFC series is also available at:
> https://github.com/tklengyel/xen/tree/mem_event_cleanup
>

<snip>

>  xen/include/public/domctl.h         |  44 +--
>  xen/include/public/hvm/params.h     |   2 +-
>  xen/include/public/mem_event.h      | 134 -------
>  xen/include/public/memory.h         |   6 +-
>  xen/include/public/vm_event.h       | 179 +++++++++

While in principle I think this series is a very good thing, there is a
problem with editing the pubic header files.

The contents of mem_event.h is not currently hidden behind #ifdef
__XEN_TOOLS__

As a result, it is strictly speaking part of the VM-visible public
API/ABI and not permitted to change in a backwards incompatible manor.

Having said that, it is currently only usable by privileged domains, so
there is an argument to be made for declaring that it should have been
hidden behind __XEN_TOOLS__ in the first place, making it permittable to
change.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:49:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoaAF-0001OV-8d; Wed, 12 Nov 2014 15:48:59 +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 1XoaAD-0001OK-SH
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:48:57 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	4A/94-25714-96183645; Wed, 12 Nov 2014 15:48:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415807334!10918693!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16182 invoked from network); 12 Nov 2014 15:48:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:48:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="192009010"
Message-ID: <54638141.3010500@citrix.com>
Date: Wed, 12 Nov 2014 15:48:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Tamas K Lengyel <tamas.lengyel@zentific.com>, <xen-devel@lists.xen.org>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
In-Reply-To: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
X-DLP: MIA1
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org,
	jun.nakajima@intel.com, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 15:31, Tamas K Lengyel wrote:
> This patch series aims to clean up the mem_event subsystem within Xen. The
> original use-case for this system was to allow external helper applications
> running in privileged domains to control various memory operations performed
> by Xen. Amongs these were paging, sharing and access control. The subsystem
> has since been extended to also deliver non-memory related events, namely
> various HVM debugging events (INT3, MTF, MOV-TO-CR). The structures and naming
> of related functions however has not caught up to these new use-cases, thus
> leaving many ambigouities in the code.
>
> In this series we convert the mem_event structures to a union of sub-structures
> which clearly define the scope of information that is transmitted via the event
> delivery mechanism. Afterwards, we clean up the naming of the structures and
> related functions to more clearly be in line with their actual operations.
>
> This PATCH RFC series is also available at:
> https://github.com/tklengyel/xen/tree/mem_event_cleanup
>

<snip>

>  xen/include/public/domctl.h         |  44 +--
>  xen/include/public/hvm/params.h     |   2 +-
>  xen/include/public/mem_event.h      | 134 -------
>  xen/include/public/memory.h         |   6 +-
>  xen/include/public/vm_event.h       | 179 +++++++++

While in principle I think this series is a very good thing, there is a
problem with editing the pubic header files.

The contents of mem_event.h is not currently hidden behind #ifdef
__XEN_TOOLS__

As a result, it is strictly speaking part of the VM-visible public
API/ABI and not permitted to change in a backwards incompatible manor.

Having said that, it is currently only usable by privileged domains, so
there is an argument to be made for declaring that it should have been
hidden behind __XEN_TOOLS__ in the first place, making it permittable to
change.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:55:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:55:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoaGX-0001jM-8s; Wed, 12 Nov 2014 15:55:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoaGV-0001jG-Tf
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:55:28 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	87/EF-19763-FE283645; Wed, 12 Nov 2014 15:55:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415807726!3343246!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19933 invoked from network); 12 Nov 2014 15:55:26 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 15:55:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 15:55:25 +0000
Message-Id: <546390FC0200007800046E50@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 15:55:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
> +u64
> +xen_swiotlb_get_required_mask(struct device *dev)
> +{
> +	u64 max_mfn;
> +
> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
> +
> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
> +}

The value the hypercall returns is exclusive and an unsigned long.
Hence I'd suggest

u64
xen_swiotlb_get_required_mask(struct device *dev)
{
	unsigned long max_mfn;

	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);

	return DMA_BIT_MASK(__fls(max_mfn - 1) + 1 + PAGE_SHIFT);
}

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:55:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:55:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoaGX-0001jM-8s; Wed, 12 Nov 2014 15:55:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoaGV-0001jG-Tf
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:55:28 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	87/EF-19763-FE283645; Wed, 12 Nov 2014 15:55:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415807726!3343246!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19933 invoked from network); 12 Nov 2014 15:55:26 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 15:55:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 15:55:25 +0000
Message-Id: <546390FC0200007800046E50@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 15:55:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
> +u64
> +xen_swiotlb_get_required_mask(struct device *dev)
> +{
> +	u64 max_mfn;
> +
> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
> +
> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
> +}

The value the hypercall returns is exclusive and an unsigned long.
Hence I'd suggest

u64
xen_swiotlb_get_required_mask(struct device *dev)
{
	unsigned long max_mfn;

	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);

	return DMA_BIT_MASK(__fls(max_mfn - 1) + 1 + PAGE_SHIFT);
}

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:56:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:56:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoaHA-0001m8-MH; Wed, 12 Nov 2014 15:56:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XoaH9-0001lw-Ud
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:56:08 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	9F/C5-22819-71383645; Wed, 12 Nov 2014 15:56:07 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415807763!5638123!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28524 invoked from network); 12 Nov 2014 15:56:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:56:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190560654"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:55:55 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XoaGx-0008Nx-4U;
	Wed, 12 Nov 2014 15:55:55 +0000
Message-ID: <54638307.1080500@eu.citrix.com>
Date: Wed, 12 Nov 2014 15:55:51 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>, <qemu-devel@nongnu.org>,
	<xen-devel@lists.xenproject.org>
References: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
Content-Length: 6509
X-DLP: MIA1
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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

T24gMTEvMTIvMjAxNCAwMzo0NSBQTSwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+IFRoaXMgcGF0
Y2ggZml4ZXMgdHdvIGlzc3VlcyB3aXRoIHBlcnNpc3RlbnQgZ3JhbnRzIGFuZCB0aGUgZGlzayBQ
ViBiYWNrZW5kCj4gKFFkaXNrKToKPgo+ICAgLSBEb24ndCB1c2UgYmF0Y2ggbWFwcGluZ3Mgd2hl
biB1c2luZyBwZXJzaXN0ZW50IGdyYW50cywgZG9pbmcgc28gcHJldmVudHMKPiAgICAgdW5tYXBw
aW5nIHNpbmdsZSBncmFudHMgKHRoZSB3aG9sZSBhcmVhIGhhcyB0byBiZSB1bm1hcHBlZCBhdCBv
bmNlKS4KPiAgIC0gVW5tYXAgcGVyc2lzdGVudCBncmFudHMgYmVmb3JlIHN3aXRjaGluZyB0byB0
aGUgY2xvc2VkIHN0YXRlLCBzbyB0aGUKPiAgICAgZnJvbnRlbmQgY2FuIGFsc28gZnJlZSB0aGVt
Lgo+Cj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j
b20+Cj4gUmVwb3J0ZWQtYW5kLVRlc3RlZC1ieTogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxh
cEBldS5jaXRyaXguY29tPgo+IENjOiBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVs
bGluaUBldS5jaXRyaXguY29tPgo+IENjOiBLZXZpbiBXb2xmIDxrd29sZkByZWRoYXQuY29tPgo+
IENjOiBTdGVmYW4gSGFqbm9jemkgPHN0ZWZhbmhhQHJlZGhhdC5jb20+Cj4gQ2M6IEdlb3JnZSBE
dW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KCkNDJ2luZyBLb25yYWQgYW5kIFN0
ZWZhbm86IFRoaXMgZml4ZXMgYSBjcml0aWNhbCBidWcgdGhhdCBzaG91bGQgYmUgYSAKYmxvY2tl
ciBmb3IgdGhlIFhlbiA0LjUgcmVsZWFzZS4gIFdpdGhvdXQgdGhpcywgYW55IGJhY2tlbmQgdXNp
bmcgcWRpc2sgCmZvciBhIFBWIGd1ZXN0IHdpdGggcHlncnViIChpbmNsdWRpbmcgcWNvdzIgYW5k
IHZoZCkgd2lsbCBjcmFzaCBkb20wLgoKICAtR2VvcmdlCgo+IC0tLQo+ICAgaHcvYmxvY2sveGVu
X2Rpc2suYyB8IDM1ICsrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tCj4gICAxIGZp
bGUgY2hhbmdlZCwgMjQgaW5zZXJ0aW9ucygrKSwgMTEgZGVsZXRpb25zKC0pCj4KPiBkaWZmIC0t
Z2l0IGEvaHcvYmxvY2sveGVuX2Rpc2suYyBiL2h3L2Jsb2NrL3hlbl9kaXNrLmMKPiBpbmRleCAy
MzFlOWE3Li4xMzAwYzBhIDEwMDY0NAo+IC0tLSBhL2h3L2Jsb2NrL3hlbl9kaXNrLmMKPiArKysg
Yi9ody9ibG9jay94ZW5fZGlzay5jCj4gQEAgLTQzLDggKzQzLDYgQEAKPiAgIAo+ICAgLyogLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSAqLwo+ICAgCj4gLXN0YXRpYyBpbnQgYmF0Y2hfbWFwcyAgID0gMDsKPiAtCj4gICBzdGF0aWMg
aW50IG1heF9yZXF1ZXN0cyA9IDMyOwo+ICAgCj4gICAvKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICovCj4gQEAgLTEwNSw2ICsx
MDMsNyBAQCBzdHJ1Y3QgWGVuQmxrRGV2IHsKPiAgICAgICBibGtpZl9iYWNrX3JpbmdzX3QgIHJp
bmdzOwo+ICAgICAgIGludCAgICAgICAgICAgICAgICAgbW9yZV93b3JrOwo+ICAgICAgIGludCAg
ICAgICAgICAgICAgICAgY250X21hcDsKPiArICAgIGJvb2wgICAgICAgICAgICAgICAgYmF0Y2hf
bWFwczsKPiAgIAo+ICAgICAgIC8qIHJlcXVlc3QgbGlzdHMgKi8KPiAgICAgICBRTElTVF9IRUFE
KGluZmxpZ2h0X2hlYWQsIGlvcmVxKSBpbmZsaWdodDsKPiBAQCAtMzA5LDcgKzMwOCw3IEBAIHN0
YXRpYyB2b2lkIGlvcmVxX3VubWFwKHN0cnVjdCBpb3JlcSAqaW9yZXEpCj4gICAgICAgaWYgKGlv
cmVxLT5udW1fdW5tYXAgPT0gMCB8fCBpb3JlcS0+bWFwcGVkID09IDApIHsKPiAgICAgICAgICAg
cmV0dXJuOwo+ICAgICAgIH0KPiAtICAgIGlmIChiYXRjaF9tYXBzKSB7Cj4gKyAgICBpZiAoaW9y
ZXEtPmJsa2Rldi0+YmF0Y2hfbWFwcykgewo+ICAgICAgICAgICBpZiAoIWlvcmVxLT5wYWdlcykg
ewo+ICAgICAgICAgICAgICAgcmV0dXJuOwo+ICAgICAgICAgICB9Cj4gQEAgLTM4Niw3ICszODUs
NyBAQCBzdGF0aWMgaW50IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEgKmlvcmVxKQo+ICAgICAgICAg
ICBuZXdfbWFwcyA9IGlvcmVxLT52Lm5pb3Y7Cj4gICAgICAgfQo+ICAgCj4gLSAgICBpZiAoYmF0
Y2hfbWFwcyAmJiBuZXdfbWFwcykgewo+ICsgICAgaWYgKGlvcmVxLT5ibGtkZXYtPmJhdGNoX21h
cHMgJiYgbmV3X21hcHMpIHsKPiAgICAgICAgICAgaW9yZXEtPnBhZ2VzID0geGNfZ250dGFiX21h
cF9ncmFudF9yZWZzCj4gICAgICAgICAgICAgICAoZ250LCBuZXdfbWFwcywgZG9taWRzLCByZWZz
LCBpb3JlcS0+cHJvdCk7Cj4gICAgICAgICAgIGlmIChpb3JlcS0+cGFnZXMgPT0gTlVMTCkgewo+
IEBAIC00MzMsNyArNDMyLDcgQEAgc3RhdGljIGludCBpb3JlcV9tYXAoc3RydWN0IGlvcmVxICpp
b3JlcSkKPiAgICAgICAgICAgICAgICAqLwo+ICAgICAgICAgICAgICAgZ3JhbnQgPSBnX21hbGxv
YzAoc2l6ZW9mKCpncmFudCkpOwo+ICAgICAgICAgICAgICAgbmV3X21hcHMtLTsKPiAtICAgICAg
ICAgICAgaWYgKGJhdGNoX21hcHMpIHsKPiArICAgICAgICAgICAgaWYgKGlvcmVxLT5ibGtkZXYt
PmJhdGNoX21hcHMpIHsKPiAgICAgICAgICAgICAgICAgICBncmFudC0+cGFnZSA9IGlvcmVxLT5w
YWdlcyArIChuZXdfbWFwcykgKiBYQ19QQUdFX1NJWkU7Cj4gICAgICAgICAgICAgICB9IGVsc2Ug
ewo+ICAgICAgICAgICAgICAgICAgIGdyYW50LT5wYWdlID0gaW9yZXEtPnBhZ2VbbmV3X21hcHNd
Owo+IEBAIC03MTgsNyArNzE3LDkgQEAgc3RhdGljIHZvaWQgYmxrX2FsbG9jKHN0cnVjdCBYZW5E
ZXZpY2UgKnhlbmRldikKPiAgICAgICBRTElTVF9JTklUKCZibGtkZXYtPmZyZWVsaXN0KTsKPiAg
ICAgICBibGtkZXYtPmJoID0gcWVtdV9iaF9uZXcoYmxrX2JoLCBibGtkZXYpOwo+ICAgICAgIGlm
ICh4ZW5fbW9kZSAhPSBYRU5fRU1VTEFURSkgewo+IC0gICAgICAgIGJhdGNoX21hcHMgPSAxOwo+
ICsgICAgICAgIGJsa2Rldi0+YmF0Y2hfbWFwcyA9IFRSVUU7Cj4gKyAgICB9IGVsc2Ugewo+ICsg
ICAgICAgIGJsa2Rldi0+YmF0Y2hfbWFwcyA9IEZBTFNFOwo+ICAgICAgIH0KPiAgICAgICBpZiAo
eGNfZ250dGFiX3NldF9tYXhfZ3JhbnRzKHhlbmRldi0+Z250dGFiZGV2LAo+ICAgICAgICAgICAg
ICAgTUFYX0dSQU5UUyhtYXhfcmVxdWVzdHMsIEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVT
VCkpIDwgMCkgewo+IEBAIC05MjMsNiArOTI0LDEzIEBAIHN0YXRpYyBpbnQgYmxrX2Nvbm5lY3Qo
c3RydWN0IFhlbkRldmljZSAqeGVuZGV2KQo+ICAgICAgIH0gZWxzZSB7Cj4gICAgICAgICAgIGJs
a2Rldi0+ZmVhdHVyZV9wZXJzaXN0ZW50ID0gISFwZXJzOwo+ICAgICAgIH0KPiArICAgIGlmIChi
bGtkZXYtPmZlYXR1cmVfcGVyc2lzdGVudCkgewo+ICsgICAgICAgIC8qCj4gKyAgICAgICAgICog
RGlzYWJsZSBiYXRjaCBtYXBzLCBzaW5jZSB0aGF0IHdvdWxkIHByZXZlbnQgdW5tYXBwaW5nCj4g
KyAgICAgICAgICogc2luZ2xlIHBlcnNpc3RlbnQgZ3JhbnRzLgo+ICsgICAgICAgICAqLwo+ICsg
ICAgICAgIGJsa2Rldi0+YmF0Y2hfbWFwcyA9IEZBTFNFOwo+ICsgICAgfQo+ICAgCj4gICAgICAg
YmxrZGV2LT5wcm90b2NvbCA9IEJMS0lGX1BST1RPQ09MX05BVElWRTsKPiAgICAgICBpZiAoYmxr
ZGV2LT54ZW5kZXYucHJvdG9jb2wpIHsKPiBAQCAtMTAwMCw2ICsxMDA4LDE2IEBAIHN0YXRpYyB2
b2lkIGJsa19kaXNjb25uZWN0KHN0cnVjdCBYZW5EZXZpY2UgKnhlbmRldikKPiAgICAgICAgICAg
YmxrZGV2LT5jbnRfbWFwLS07Cj4gICAgICAgICAgIGJsa2Rldi0+c3JpbmcgPSBOVUxMOwo+ICAg
ICAgIH0KPiArCj4gKyAgICAvKgo+ICsgICAgICogVW5tYXAgcGVyc2lzdGVudCBncmFudHMgYmVm
b3JlIHN3aXRjaGluZyB0byB0aGUgY2xvc2VkIHN0YXRlCj4gKyAgICAgKiBzbyB0aGUgZnJvbnRl
bmQgY2FuIGZyZWUgdGhlbS4KPiArICAgICAqLwo+ICsgICAgaWYgKGJsa2Rldi0+ZmVhdHVyZV9w
ZXJzaXN0ZW50KSB7Cj4gKyAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxrZGV2LT5wZXJzaXN0ZW50
X2dudHMpOwo+ICsgICAgICAgIGFzc2VydChibGtkZXYtPnBlcnNpc3RlbnRfZ250X2NvdW50ID09
IDApOwo+ICsgICAgICAgIGJsa2Rldi0+ZmVhdHVyZV9wZXJzaXN0ZW50ID0gRkFMU0U7Cj4gKyAg
ICB9Cj4gICB9Cj4gICAKPiAgIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhlbkRldmljZSAq
eGVuZGV2KQo+IEBAIC0xMDExLDExICsxMDI5LDYgQEAgc3RhdGljIGludCBibGtfZnJlZShzdHJ1
Y3QgWGVuRGV2aWNlICp4ZW5kZXYpCj4gICAgICAgICAgIGJsa19kaXNjb25uZWN0KHhlbmRldik7
Cj4gICAgICAgfQo+ICAgCj4gLSAgICAvKiBGcmVlIHBlcnNpc3RlbnQgZ3JhbnRzICovCj4gLSAg
ICBpZiAoYmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKPiAtICAgICAgICBnX3RyZWVfZGVz
dHJveShibGtkZXYtPnBlcnNpc3RlbnRfZ250cyk7Cj4gLSAgICB9Cj4gLQo+ICAgICAgIHdoaWxl
ICghUUxJU1RfRU1QVFkoJmJsa2Rldi0+ZnJlZWxpc3QpKSB7Cj4gICAgICAgICAgIGlvcmVxID0g
UUxJU1RfRklSU1QoJmJsa2Rldi0+ZnJlZWxpc3QpOwo+ICAgICAgICAgICBRTElTVF9SRU1PVkUo
aW9yZXEsIGxpc3QpOwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:56:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:56:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoaHA-0001m8-MH; Wed, 12 Nov 2014 15:56:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XoaH9-0001lw-Ud
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:56:08 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	9F/C5-22819-71383645; Wed, 12 Nov 2014 15:56:07 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415807763!5638123!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28524 invoked from network); 12 Nov 2014 15:56:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:56:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190560654"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 10:55:55 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XoaGx-0008Nx-4U;
	Wed, 12 Nov 2014 15:55:55 +0000
Message-ID: <54638307.1080500@eu.citrix.com>
Date: Wed, 12 Nov 2014 15:55:51 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>, <qemu-devel@nongnu.org>,
	<xen-devel@lists.xenproject.org>
References: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
Content-Length: 6509
X-DLP: MIA1
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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

T24gMTEvMTIvMjAxNCAwMzo0NSBQTSwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+IFRoaXMgcGF0
Y2ggZml4ZXMgdHdvIGlzc3VlcyB3aXRoIHBlcnNpc3RlbnQgZ3JhbnRzIGFuZCB0aGUgZGlzayBQ
ViBiYWNrZW5kCj4gKFFkaXNrKToKPgo+ICAgLSBEb24ndCB1c2UgYmF0Y2ggbWFwcGluZ3Mgd2hl
biB1c2luZyBwZXJzaXN0ZW50IGdyYW50cywgZG9pbmcgc28gcHJldmVudHMKPiAgICAgdW5tYXBw
aW5nIHNpbmdsZSBncmFudHMgKHRoZSB3aG9sZSBhcmVhIGhhcyB0byBiZSB1bm1hcHBlZCBhdCBv
bmNlKS4KPiAgIC0gVW5tYXAgcGVyc2lzdGVudCBncmFudHMgYmVmb3JlIHN3aXRjaGluZyB0byB0
aGUgY2xvc2VkIHN0YXRlLCBzbyB0aGUKPiAgICAgZnJvbnRlbmQgY2FuIGFsc28gZnJlZSB0aGVt
Lgo+Cj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j
b20+Cj4gUmVwb3J0ZWQtYW5kLVRlc3RlZC1ieTogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxh
cEBldS5jaXRyaXguY29tPgo+IENjOiBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVs
bGluaUBldS5jaXRyaXguY29tPgo+IENjOiBLZXZpbiBXb2xmIDxrd29sZkByZWRoYXQuY29tPgo+
IENjOiBTdGVmYW4gSGFqbm9jemkgPHN0ZWZhbmhhQHJlZGhhdC5jb20+Cj4gQ2M6IEdlb3JnZSBE
dW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KCkNDJ2luZyBLb25yYWQgYW5kIFN0
ZWZhbm86IFRoaXMgZml4ZXMgYSBjcml0aWNhbCBidWcgdGhhdCBzaG91bGQgYmUgYSAKYmxvY2tl
ciBmb3IgdGhlIFhlbiA0LjUgcmVsZWFzZS4gIFdpdGhvdXQgdGhpcywgYW55IGJhY2tlbmQgdXNp
bmcgcWRpc2sgCmZvciBhIFBWIGd1ZXN0IHdpdGggcHlncnViIChpbmNsdWRpbmcgcWNvdzIgYW5k
IHZoZCkgd2lsbCBjcmFzaCBkb20wLgoKICAtR2VvcmdlCgo+IC0tLQo+ICAgaHcvYmxvY2sveGVu
X2Rpc2suYyB8IDM1ICsrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tCj4gICAxIGZp
bGUgY2hhbmdlZCwgMjQgaW5zZXJ0aW9ucygrKSwgMTEgZGVsZXRpb25zKC0pCj4KPiBkaWZmIC0t
Z2l0IGEvaHcvYmxvY2sveGVuX2Rpc2suYyBiL2h3L2Jsb2NrL3hlbl9kaXNrLmMKPiBpbmRleCAy
MzFlOWE3Li4xMzAwYzBhIDEwMDY0NAo+IC0tLSBhL2h3L2Jsb2NrL3hlbl9kaXNrLmMKPiArKysg
Yi9ody9ibG9jay94ZW5fZGlzay5jCj4gQEAgLTQzLDggKzQzLDYgQEAKPiAgIAo+ICAgLyogLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSAqLwo+ICAgCj4gLXN0YXRpYyBpbnQgYmF0Y2hfbWFwcyAgID0gMDsKPiAtCj4gICBzdGF0aWMg
aW50IG1heF9yZXF1ZXN0cyA9IDMyOwo+ICAgCj4gICAvKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICovCj4gQEAgLTEwNSw2ICsx
MDMsNyBAQCBzdHJ1Y3QgWGVuQmxrRGV2IHsKPiAgICAgICBibGtpZl9iYWNrX3JpbmdzX3QgIHJp
bmdzOwo+ICAgICAgIGludCAgICAgICAgICAgICAgICAgbW9yZV93b3JrOwo+ICAgICAgIGludCAg
ICAgICAgICAgICAgICAgY250X21hcDsKPiArICAgIGJvb2wgICAgICAgICAgICAgICAgYmF0Y2hf
bWFwczsKPiAgIAo+ICAgICAgIC8qIHJlcXVlc3QgbGlzdHMgKi8KPiAgICAgICBRTElTVF9IRUFE
KGluZmxpZ2h0X2hlYWQsIGlvcmVxKSBpbmZsaWdodDsKPiBAQCAtMzA5LDcgKzMwOCw3IEBAIHN0
YXRpYyB2b2lkIGlvcmVxX3VubWFwKHN0cnVjdCBpb3JlcSAqaW9yZXEpCj4gICAgICAgaWYgKGlv
cmVxLT5udW1fdW5tYXAgPT0gMCB8fCBpb3JlcS0+bWFwcGVkID09IDApIHsKPiAgICAgICAgICAg
cmV0dXJuOwo+ICAgICAgIH0KPiAtICAgIGlmIChiYXRjaF9tYXBzKSB7Cj4gKyAgICBpZiAoaW9y
ZXEtPmJsa2Rldi0+YmF0Y2hfbWFwcykgewo+ICAgICAgICAgICBpZiAoIWlvcmVxLT5wYWdlcykg
ewo+ICAgICAgICAgICAgICAgcmV0dXJuOwo+ICAgICAgICAgICB9Cj4gQEAgLTM4Niw3ICszODUs
NyBAQCBzdGF0aWMgaW50IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEgKmlvcmVxKQo+ICAgICAgICAg
ICBuZXdfbWFwcyA9IGlvcmVxLT52Lm5pb3Y7Cj4gICAgICAgfQo+ICAgCj4gLSAgICBpZiAoYmF0
Y2hfbWFwcyAmJiBuZXdfbWFwcykgewo+ICsgICAgaWYgKGlvcmVxLT5ibGtkZXYtPmJhdGNoX21h
cHMgJiYgbmV3X21hcHMpIHsKPiAgICAgICAgICAgaW9yZXEtPnBhZ2VzID0geGNfZ250dGFiX21h
cF9ncmFudF9yZWZzCj4gICAgICAgICAgICAgICAoZ250LCBuZXdfbWFwcywgZG9taWRzLCByZWZz
LCBpb3JlcS0+cHJvdCk7Cj4gICAgICAgICAgIGlmIChpb3JlcS0+cGFnZXMgPT0gTlVMTCkgewo+
IEBAIC00MzMsNyArNDMyLDcgQEAgc3RhdGljIGludCBpb3JlcV9tYXAoc3RydWN0IGlvcmVxICpp
b3JlcSkKPiAgICAgICAgICAgICAgICAqLwo+ICAgICAgICAgICAgICAgZ3JhbnQgPSBnX21hbGxv
YzAoc2l6ZW9mKCpncmFudCkpOwo+ICAgICAgICAgICAgICAgbmV3X21hcHMtLTsKPiAtICAgICAg
ICAgICAgaWYgKGJhdGNoX21hcHMpIHsKPiArICAgICAgICAgICAgaWYgKGlvcmVxLT5ibGtkZXYt
PmJhdGNoX21hcHMpIHsKPiAgICAgICAgICAgICAgICAgICBncmFudC0+cGFnZSA9IGlvcmVxLT5w
YWdlcyArIChuZXdfbWFwcykgKiBYQ19QQUdFX1NJWkU7Cj4gICAgICAgICAgICAgICB9IGVsc2Ug
ewo+ICAgICAgICAgICAgICAgICAgIGdyYW50LT5wYWdlID0gaW9yZXEtPnBhZ2VbbmV3X21hcHNd
Owo+IEBAIC03MTgsNyArNzE3LDkgQEAgc3RhdGljIHZvaWQgYmxrX2FsbG9jKHN0cnVjdCBYZW5E
ZXZpY2UgKnhlbmRldikKPiAgICAgICBRTElTVF9JTklUKCZibGtkZXYtPmZyZWVsaXN0KTsKPiAg
ICAgICBibGtkZXYtPmJoID0gcWVtdV9iaF9uZXcoYmxrX2JoLCBibGtkZXYpOwo+ICAgICAgIGlm
ICh4ZW5fbW9kZSAhPSBYRU5fRU1VTEFURSkgewo+IC0gICAgICAgIGJhdGNoX21hcHMgPSAxOwo+
ICsgICAgICAgIGJsa2Rldi0+YmF0Y2hfbWFwcyA9IFRSVUU7Cj4gKyAgICB9IGVsc2Ugewo+ICsg
ICAgICAgIGJsa2Rldi0+YmF0Y2hfbWFwcyA9IEZBTFNFOwo+ICAgICAgIH0KPiAgICAgICBpZiAo
eGNfZ250dGFiX3NldF9tYXhfZ3JhbnRzKHhlbmRldi0+Z250dGFiZGV2LAo+ICAgICAgICAgICAg
ICAgTUFYX0dSQU5UUyhtYXhfcmVxdWVzdHMsIEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVT
VCkpIDwgMCkgewo+IEBAIC05MjMsNiArOTI0LDEzIEBAIHN0YXRpYyBpbnQgYmxrX2Nvbm5lY3Qo
c3RydWN0IFhlbkRldmljZSAqeGVuZGV2KQo+ICAgICAgIH0gZWxzZSB7Cj4gICAgICAgICAgIGJs
a2Rldi0+ZmVhdHVyZV9wZXJzaXN0ZW50ID0gISFwZXJzOwo+ICAgICAgIH0KPiArICAgIGlmIChi
bGtkZXYtPmZlYXR1cmVfcGVyc2lzdGVudCkgewo+ICsgICAgICAgIC8qCj4gKyAgICAgICAgICog
RGlzYWJsZSBiYXRjaCBtYXBzLCBzaW5jZSB0aGF0IHdvdWxkIHByZXZlbnQgdW5tYXBwaW5nCj4g
KyAgICAgICAgICogc2luZ2xlIHBlcnNpc3RlbnQgZ3JhbnRzLgo+ICsgICAgICAgICAqLwo+ICsg
ICAgICAgIGJsa2Rldi0+YmF0Y2hfbWFwcyA9IEZBTFNFOwo+ICsgICAgfQo+ICAgCj4gICAgICAg
YmxrZGV2LT5wcm90b2NvbCA9IEJMS0lGX1BST1RPQ09MX05BVElWRTsKPiAgICAgICBpZiAoYmxr
ZGV2LT54ZW5kZXYucHJvdG9jb2wpIHsKPiBAQCAtMTAwMCw2ICsxMDA4LDE2IEBAIHN0YXRpYyB2
b2lkIGJsa19kaXNjb25uZWN0KHN0cnVjdCBYZW5EZXZpY2UgKnhlbmRldikKPiAgICAgICAgICAg
YmxrZGV2LT5jbnRfbWFwLS07Cj4gICAgICAgICAgIGJsa2Rldi0+c3JpbmcgPSBOVUxMOwo+ICAg
ICAgIH0KPiArCj4gKyAgICAvKgo+ICsgICAgICogVW5tYXAgcGVyc2lzdGVudCBncmFudHMgYmVm
b3JlIHN3aXRjaGluZyB0byB0aGUgY2xvc2VkIHN0YXRlCj4gKyAgICAgKiBzbyB0aGUgZnJvbnRl
bmQgY2FuIGZyZWUgdGhlbS4KPiArICAgICAqLwo+ICsgICAgaWYgKGJsa2Rldi0+ZmVhdHVyZV9w
ZXJzaXN0ZW50KSB7Cj4gKyAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxrZGV2LT5wZXJzaXN0ZW50
X2dudHMpOwo+ICsgICAgICAgIGFzc2VydChibGtkZXYtPnBlcnNpc3RlbnRfZ250X2NvdW50ID09
IDApOwo+ICsgICAgICAgIGJsa2Rldi0+ZmVhdHVyZV9wZXJzaXN0ZW50ID0gRkFMU0U7Cj4gKyAg
ICB9Cj4gICB9Cj4gICAKPiAgIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhlbkRldmljZSAq
eGVuZGV2KQo+IEBAIC0xMDExLDExICsxMDI5LDYgQEAgc3RhdGljIGludCBibGtfZnJlZShzdHJ1
Y3QgWGVuRGV2aWNlICp4ZW5kZXYpCj4gICAgICAgICAgIGJsa19kaXNjb25uZWN0KHhlbmRldik7
Cj4gICAgICAgfQo+ICAgCj4gLSAgICAvKiBGcmVlIHBlcnNpc3RlbnQgZ3JhbnRzICovCj4gLSAg
ICBpZiAoYmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKPiAtICAgICAgICBnX3RyZWVfZGVz
dHJveShibGtkZXYtPnBlcnNpc3RlbnRfZ250cyk7Cj4gLSAgICB9Cj4gLQo+ICAgICAgIHdoaWxl
ICghUUxJU1RfRU1QVFkoJmJsa2Rldi0+ZnJlZWxpc3QpKSB7Cj4gICAgICAgICAgIGlvcmVxID0g
UUxJU1RfRklSU1QoJmJsa2Rldi0+ZnJlZWxpc3QpOwo+ICAgICAgICAgICBRTElTVF9SRU1PVkUo
aW9yZXEsIGxpc3QpOwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:58:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoaJn-0001yN-9R; Wed, 12 Nov 2014 15:58:51 +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 1XoaJm-0001yI-5G
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:58:50 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	8B/8B-22819-9B383645; Wed, 12 Nov 2014 15:58:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415807926!10921178!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21802 invoked from network); 12 Nov 2014 15:58:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:58:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190561698"
Message-ID: <546383A1.8030604@citrix.com>
Date: Wed, 12 Nov 2014 15:58:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Tamas K Lengyel <tamas.lengyel@zentific.com>, <xen-devel@lists.xen.org>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
In-Reply-To: <1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
X-DLP: MIA2
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	eddie.dong@intel.com, andres@lagarcavilla.org,
	jun.nakajima@intel.com, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event
 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

On 12/11/14 15:31, Tamas K Lengyel wrote:
> diff --git a/xen/include/public/mem_event.h b/xen/include/public/mem_event.h
> index 599f9e8..c0e9394 100644
> --- a/xen/include/public/mem_event.h
> +++ b/xen/include/public/mem_event.h
> @@ -49,15 +49,19 @@
>  #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 << 6)
>  
>  /* Reasons for the memory event request */
> -#define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */
> -#define MEM_EVENT_REASON_VIOLATION   1    /* access violation, GFN is address */
> -#define MEM_EVENT_REASON_CR0         2    /* CR0 was hit: gfn is new CR0 value, gla is previous */
> -#define MEM_EVENT_REASON_CR3         3    /* CR3 was hit: gfn is new CR3 value, gla is previous */
> -#define MEM_EVENT_REASON_CR4         4    /* CR4 was hit: gfn is new CR4 value, gla is previous */
> -#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 */
> -#define MEM_EVENT_REASON_MSR         7    /* MSR was hit: gfn is MSR value, gla is MSR address;
> -                                             does NOT honour HVMPME_onchangeonly */
> +typedef enum {
> +    MEM_EVENT_REASON_UNKNOWN,              /* Default case */
> +    MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
> +    MEM_EVENT_REASON_MEM_SHARING,          /* Memory sharing event */
> +    MEM_EVENT_REASON_MEM_PAGING,           /* Memory paging event */
> +    MEM_EVENT_REASON_CR0,                  /* CR0 was updated */
> +    MEM_EVENT_REASON_CR3,                  /* CR3 was updated */
> +    MEM_EVENT_REASON_CR4,                  /* CR4 was updated */
> +    MEM_EVENT_REASON_INT3,                 /* Debug operation executed (int3) */
> +    MEM_EVENT_REASON_SINGLESTEP,           /* Single-step (MTF) */
> +    MEM_EVENT_REASON_MSR,                  /* An MSR was updated.
> +                                            * Does NOT honour HVMPME_onchangeonly */
> +} mem_event_reason_t;

Please keep these as defines.  The width of an enum is implementation
defined, meaning that different compilers are free to interpret the
width of the above definition differently, which affects the size and
alignment of mem_event_st below.

(It is completely wrong that Xen's ABI/API was ever specified using C,
rather than a document stating actual data structure widths, but that
horse has long-since bolted)

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 15:58:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 15:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoaJn-0001yN-9R; Wed, 12 Nov 2014 15:58:51 +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 1XoaJm-0001yI-5G
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 15:58:50 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	8B/8B-22819-9B383645; Wed, 12 Nov 2014 15:58:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415807926!10921178!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21802 invoked from network); 12 Nov 2014 15:58:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 15:58:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="190561698"
Message-ID: <546383A1.8030604@citrix.com>
Date: Wed, 12 Nov 2014 15:58:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Tamas K Lengyel <tamas.lengyel@zentific.com>, <xen-devel@lists.xen.org>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
In-Reply-To: <1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
X-DLP: MIA2
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	eddie.dong@intel.com, andres@lagarcavilla.org,
	jun.nakajima@intel.com, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event
 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

On 12/11/14 15:31, Tamas K Lengyel wrote:
> diff --git a/xen/include/public/mem_event.h b/xen/include/public/mem_event.h
> index 599f9e8..c0e9394 100644
> --- a/xen/include/public/mem_event.h
> +++ b/xen/include/public/mem_event.h
> @@ -49,15 +49,19 @@
>  #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 << 6)
>  
>  /* Reasons for the memory event request */
> -#define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */
> -#define MEM_EVENT_REASON_VIOLATION   1    /* access violation, GFN is address */
> -#define MEM_EVENT_REASON_CR0         2    /* CR0 was hit: gfn is new CR0 value, gla is previous */
> -#define MEM_EVENT_REASON_CR3         3    /* CR3 was hit: gfn is new CR3 value, gla is previous */
> -#define MEM_EVENT_REASON_CR4         4    /* CR4 was hit: gfn is new CR4 value, gla is previous */
> -#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 */
> -#define MEM_EVENT_REASON_MSR         7    /* MSR was hit: gfn is MSR value, gla is MSR address;
> -                                             does NOT honour HVMPME_onchangeonly */
> +typedef enum {
> +    MEM_EVENT_REASON_UNKNOWN,              /* Default case */
> +    MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
> +    MEM_EVENT_REASON_MEM_SHARING,          /* Memory sharing event */
> +    MEM_EVENT_REASON_MEM_PAGING,           /* Memory paging event */
> +    MEM_EVENT_REASON_CR0,                  /* CR0 was updated */
> +    MEM_EVENT_REASON_CR3,                  /* CR3 was updated */
> +    MEM_EVENT_REASON_CR4,                  /* CR4 was updated */
> +    MEM_EVENT_REASON_INT3,                 /* Debug operation executed (int3) */
> +    MEM_EVENT_REASON_SINGLESTEP,           /* Single-step (MTF) */
> +    MEM_EVENT_REASON_MSR,                  /* An MSR was updated.
> +                                            * Does NOT honour HVMPME_onchangeonly */
> +} mem_event_reason_t;

Please keep these as defines.  The width of an enum is implementation
defined, meaning that different compilers are free to interpret the
width of the above definition differently, which affects the size and
alignment of mem_event_st below.

(It is completely wrong that Xen's ABI/API was ever specified using C,
rather than a document stating actual data structure widths, but that
horse has long-since bolted)

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:06:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16:06:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoaRH-0002cH-EP; Wed, 12 Nov 2014 16:06:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1XoaRF-0002c9-Qa
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:06:33 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	83/3F-08051-98583645; Wed, 12 Nov 2014 16:06:33 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415808391!6685149!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13689 invoked from network); 12 Nov 2014 16:06:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 16:06:32 -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
	sACG6L1Z014012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 12 Nov 2014 11:06:21 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sACG6K4L014010;
	Wed, 12 Nov 2014 11:06:20 -0500
Date: Wed, 12 Nov 2014 12:06:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141112160620.GA12856@andromeda.dapyr.net>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> Hi All,
> 
> This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.

Yeey! Thank you for doing those tests.
> 
> Test environment:
> Xen: Xen 4.5-rc1 
> Dom0: Linux kernel 3.17.0
> Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP
> 
> New bugs(9):

> 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896

Please post the bug as an email on xen-devel so we can start the
discussion here.


> 5. Dom0 failed to resume from S3 power state

Interstingly enough it works for me on my AMD box. I will shortly try
it out with the Intel laptop (X230) (been using Xen 4.4 + 3.17.0).

Please post the bug as an email on xen-devel so we can start the
discussion here.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:06:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16:06:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoaRH-0002cH-EP; Wed, 12 Nov 2014 16:06:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1XoaRF-0002c9-Qa
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:06:33 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	83/3F-08051-98583645; Wed, 12 Nov 2014 16:06:33 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415808391!6685149!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13689 invoked from network); 12 Nov 2014 16:06:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 16:06:32 -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
	sACG6L1Z014012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 12 Nov 2014 11:06:21 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sACG6K4L014010;
	Wed, 12 Nov 2014 11:06:20 -0500
Date: Wed, 12 Nov 2014 12:06:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141112160620.GA12856@andromeda.dapyr.net>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> Hi All,
> 
> This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.

Yeey! Thank you for doing those tests.
> 
> Test environment:
> Xen: Xen 4.5-rc1 
> Dom0: Linux kernel 3.17.0
> Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP
> 
> New bugs(9):

> 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
>   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896

Please post the bug as an email on xen-devel so we can start the
discussion here.


> 5. Dom0 failed to resume from S3 power state

Interstingly enough it works for me on my AMD box. I will shortly try
it out with the Intel laptop (X230) (been using Xen 4.4 + 3.17.0).

Please post the bug as an email on xen-devel so we can start the
discussion here.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF8-0003un-CF; Wed, 12 Nov 2014 16:58:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobF6-0003uI-Km
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:04 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	6D/D7-02712-B9193645; Wed, 12 Nov 2014 16:58:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415811482!8774118!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27154 invoked from network); 12 Nov 2014 16:58:03 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvsoP018620
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:54 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvrY6011415
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:53 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvqG2029198; Wed, 12 Nov 2014 16:57:52 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:52 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 990B7114BA8; Wed, 12 Nov 2014 10:18:41 -0500 (EST)
Date: Wed, 12 Nov 2014 10:18:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141112151841.GD6017@laptop.dumpdata.com>
References: <1415790602-25779-1-git-send-email-jgross@suse.com>
	<CAFLBxZbtXBEdG5gWYgGOeAB1zJr=E7hLVd4f4=bXFQ7juLWvPg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZbtXBEdG5gWYgGOeAB1zJr=E7hLVd4f4=bXFQ7juLWvPg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Juergen Gross <jgross@suse.com>, Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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 Wed, Nov 12, 2014 at 11:11:15AM +0000, George Dunlap wrote:
> On Wed, Nov 12, 2014 at 11:10 AM, Juergen Gross <jgross@suse.com> wrote:
> > Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> > cpupool0 before destroying it) introduced an error in the accounting
> > of cpupools regarding the number of domains. The number of domains
> > is nor adjusted when a domain is moved to cpupool0 in kill_domain().
> >
> > Correct this by introducing a cpupool function doing the move
> > instead of open coding it by calling sched_move_domain().
> >
> > Signed-off-by: Juergen Gross <jgross@suse.com>
> > Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> > Reviewed-by: Andrew Cooper <Andrew.Cooper3@citrix.com>
> 
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Excellent!

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF8-0003uu-NJ; Wed, 12 Nov 2014 16:58:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobF6-0003uN-V2
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:05 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	71/1D-09936-C9193645; Wed, 12 Nov 2014 16:58:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415811482!8814739!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21809 invoked from network); 12 Nov 2014 16:58:03 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvtvp018680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:56 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvsn3011512
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:55 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvsfO029288; Wed, 12 Nov 2014 16:57:54 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3D223114B9A; Wed, 12 Nov 2014 10:14:28 -0500 (EST)
Date: Wed, 12 Nov 2014 10:14:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Malcolm Crossley <malcolm.crossley@citrix.com>
Message-ID: <20141112151428.GA6017@laptop.dumpdata.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
	<20141112013757.GC2593@laptop.dumpdata.com>
	<5463355B0200007800046B17@mail.emea.novell.com>
	<54632FF8.7020508@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54632FF8.7020508@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 10:01:28AM +0000, Malcolm Crossley wrote:
> On 12/11/14 09:24, Jan Beulich wrote:
> >>>> On 12.11.14 at 02:37, <konrad.wilk@oracle.com> wrote:
> >> When we PCI insert an device, the BARs are not set at all - and hence
> >> the Linux kernel is the one that tries to set the BARs in. The
> >> reason it cannot fit the device in the MMIO region is due to the
> >> _CRS only having certain ranges (even thought the MMIO region can
> >> cover 2GB). See:
> >>
> >> Without any devices (and me doing PCI insertion after that):
> >> # dmesg | grep "bus resource"
> >> [    0.366000] pci_bus 0000:00: root bus resource [bus 00-ff]
> >> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> >> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> >> [    0.366000] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> >> [    0.366000] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
> >>
> >> With the device (my GPU card) inserted so that hvmloader can enumerate it:
> >>  dmesg | grep 'resource'     
> >> [    0.455006] pci_bus 0000:00: root bus resource [bus 00-ff]
> >> [    0.459006] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> >> [    0.462006] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> >> [    0.466006] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> >> [    0.469006] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbffffff]
> >>
> >> I chatted with Bjorn and Rafeal on IRC about how PCI insertion works
> >> on baremetal and it sounds like Thunderbolt device insertion is an
> >> interesting case. The SMM sets the BAR regions to fit within the MMIO
> >> (which is advertised by the _CRS) and it then pokes the OS to enumerate
> >> the BARs. The OS is free to use what the firmware has set or renumber
> >> it. The end result is that since the SMM 'fits' the BAR inside the
> >> pre-set _CRS window it all works. We do not do that.
> > 
> > Who does the BAR assignment is pretty much orthogonal to the
> > problem at hand: If the region reserved for MMIO is too small,
> > no-one will be able to fit a device in there. Plus, what is being
> > reported as root bus resource doesn't have to have a
> > connection to the ranges usable for MMIO at all, at least if I
> > assume that the (Dell) system I'm right now looking at isn't
> > completely screwed:
> > 
> > pci_bus 0000:00: root bus resource [bus 00-ff]
> > pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > pci_bus 0000:00: root bus resource [mem 0x00000000-0x3fffffffff]
> > 
> > (i.e. it simply reports the full usable 38 bits wide address space)
> > 
> > Looking at another (Intel) one, there is no mention of regions
> > above the 4G boundary at all:
> > 
> > pci_bus 0000:00: root bus resource [bus 00-3d]
> > pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> > pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> > pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> > pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000cbfff]
> > pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfedfffff]
> > pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff]
> > 
> > Not sure how the OS would know it is safe to assign BARs above
> > 4Gb here.
> > 
> > In any event, what you need is an equivalent of the frequently
> > seen BIOS option controlling the size of the space to be reserved
> > for MMIO (often allowing it to be 1, 2, or 3 Gb). I.e. an alternative
> > (or extension) to the dynamic lowering of pci_mem_start in
> > hvmloader.
> > 
> 
> I agree with Jan. By using xl pci-attach you are effectively hotplugging
> a PCI device (in the bare metal case). The only way this will work
> reliably is if you reserve some MMIO space for the device you are about
> to attach. You cannot just use space above the 4G boundary because the
> PCI device may have 32 bit only BAR's and thus it's MMIO cannot be
> placed at addresses above 4G.

Is it safe to split the BARs to be in different locations? Say stash
all 64-bit BARs above 4GB and put all 32-bit under 4GB?

Looking at the hvmloader it looks to be doing that if it has exhausted
the mmio_total.

> 
> The problem you have is that you cannot predict how much MMIO space to
> reserve because you don't know in advance how many PCI device's you are
> going to hotplug and how much MMIO space is required per device.

Perhaps following Jan's advice allow "bigger" MMIO ranges to be
predefined: 4GB, 8Gb, 16GB, etc. And the larger ranges would cover
space under 4GB (so say max 3GB) while the rest is spilled past the 4GB
past the 'maxmem' range?

> 
> As for the CRS regions: These typically describe the BIOS set limits in
> hardware configuration for the MMIO hole itself. On single socket
> systems anything which isn't RAM or another predefined region decodes to
> MMIO. This is probably why Jan's Dell system has a CRS region which
> covers the entire address space.
> 
> On multi socket systems the CRS is very important because the chipset is
> configured to only decode certain regions to the PCI express ports, if
> you use an address out side of those regions then accessing that address
> will go "nowhere" and the machine will crash.
> 
> Typically you will see a separate high MMIO CRS region if 64bit BAR
> support is enabled in BIOS.
> 
> 
> To do HVM pci hotplug properly we need to reserve MMIO space below 4G
> and emulate a PCI hotplug capable PCI-PCI bridge device. The bridge
> device will know the maximum size of the MMIO behind it (as allocated at
> boot time) and so we can calculate if the device we are hotplugging can
> fit. If it doesn't fit then we fail the hotplug otherwise we allow it
> and the OS will correct allocate the BAR behind the bridge.

I think that can be done right now for the MMIO and _CRS in hvmloader
and libxc/libxl. I wonder if that can all be done without having an
PCI-PCI bridge device introduced?

> 
> BTW, calculating the required MMIO for multi BAR PCI device's is not
> easy because all the BAR's need to be aligned to their size (naturally
> aligned).

Ouch. So two 512MB and an 1GB can't be next to each but would need:
512GB BAR<-- 512GB space--->| 1GB BAR.

Or just put the 1GB first:

1GB BAR | 512GB 

?

> 
> Malcolm
> 
> 
> > Jan
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> > 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF8-0003ug-0W; Wed, 12 Nov 2014 16:58:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobF6-0003uA-Bg
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	44/6B-24532-B9193645; Wed, 12 Nov 2014 16:58:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415811480!12269891!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20626 invoked from network); 12 Nov 2014 16:58:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:01 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvupr018726
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:57 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvtxe011599
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:56 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvt2f011579; Wed, 12 Nov 2014 16:57:55 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1B077114AFF; Wed, 12 Nov 2014 09:23:59 -0500 (EST)
Date: Wed, 12 Nov 2014 09:23:58 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141112142358.GC3084@laptop.dumpdata.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<20141112121448.GB28075@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112121448.GB28075@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 12:14:48PM +0000, Wei Liu wrote:
> On Tue, Nov 11, 2014 at 06:03:22PM +0000, David Vrabel wrote:
> > On 11/11/14 17:36, Wei Liu wrote:
> > > # What's already implemented?
> > > 
> > > PV vNUMA support in libxl/xl and Linux kernel.
> > 
> > Linux doesn't have vnuma yet, although the last set of patches I saw
> > looked fine and were waiting for acks from x86 maintainers I think.
> > 
> 
> What I meant was I have those implemented but not yet posted. ;-)

Are you refering to the patches that Elena posted and that
were Acked? Or is this another set that does things differently?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF5-0003uB-LA; Wed, 12 Nov 2014 16:58:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobF4-0003u5-9F
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:02 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	FE/98-02698-99193645; Wed, 12 Nov 2014 16:58:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415811479!12117837!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29820 invoked from network); 12 Nov 2014 16:58:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:01 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvuwW018723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:57 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvteA003308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 16:57:56 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACGvsal023088; Wed, 12 Nov 2014 16:57:55 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 61690114CB7; Wed, 12 Nov 2014 11:23:06 -0500 (EST)
Date: Wed, 12 Nov 2014 11:23:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141112162306.GA24513@laptop.dumpdata.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C76C@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C76C@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] Xen-4.5.0 RC1 bug: with
 "xen_platform_pci=0" option,
 the guest with VT-d device fails to boot up and qemu-xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Basic root-causing log:
> ----------------------
> [root@vt-hsw1 carl]# xl cr xlexample.hvm 
> Parsing config from xlexample.hvm
> libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error
> message from QMP server: Unsupported bus. Bus doesn't have property
> 'acpi-pcihp-bsel' set
> libxl: error: libxl_create.c:1385:domcreate_attach_pci: libxl_device_pci_add
> failed: -3

I can reproduce this.

If you use "device_model_version = 'qemu-xen-traditional'" the problem
go aways and you can boot the guest without Xen PCI platform driver.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobFB-0003vu-VD; Wed, 12 Nov 2014 16:58:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobFA-0003vR-Et
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:08 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	CD/94-02576-F9193645; Wed, 12 Nov 2014 16:58:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415811485!12022956!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25629 invoked from network); 12 Nov 2014 16:58:07 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:07 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvu02010364
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:57 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvthj003288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:55 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvtIs003282; Wed, 12 Nov 2014 16:57:55 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 852E6114BB6; Wed, 12 Nov 2014 10:21:11 -0500 (EST)
Date: Wed, 12 Nov 2014 10:21:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141112152111.GE6017@laptop.dumpdata.com>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415790726.29592.4.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 11:12:06AM +0000, Ian Campbell wrote:
> You forgot to add the release manager... I've done that for you.
> 
> In <1413279117.1497.25.camel@citrix.com> I said:
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Is this a bug fix or a feature? What are the risks? IsLKonrad OK with
> > it?

Back again to that question.

What happens if we do not take that in now but delay to Xen 4.6?

Will systemd still correctly work? It looks like it will and 
this is just an improvement that makes the code be more streamlined.

It does not fix a bug (at least that is what I see from
reading), I believe this should be deferred to Xen 4.6.


> 
> On Wed, 2014-11-12 at 12:06 +0100, Olaf Hering wrote:
> > Ping?
> > 
> > 
> > > ... instead of hardcoding values and guess where they config files may
> > > be. Also use the result of --with-sysconfig-leaf-dir.
> > > 
> > > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Cc: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > >  tools/hotplug/Linux/init.d/xencommons.in                          | 6 +-----
> > >  tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 3 +--
> > >  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 3 +--
> > >  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 3 +--
> > >  tools/hotplug/Linux/systemd/xenstored.service.in                  | 3 +--
> > >  tools/hotplug/Linux/xendomains.in                                 | 6 +-----
> > >  6 files changed, 6 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
> > > index d53a1f3..a1095c2 100644
> > > --- a/tools/hotplug/Linux/init.d/xencommons.in
> > > +++ b/tools/hotplug/Linux/init.d/xencommons.in
> > > @@ -23,11 +23,7 @@ BACKEND_MODULES="@LINUX_BACKEND_MODULES@"
> > >  
> > >  . @XEN_SCRIPT_DIR@/hotplugpath.sh
> > >  
> > > -if [ -d /etc/sysconfig ]; then
> > > -	xencommons_config=/etc/sysconfig
> > > -else
> > > -	xencommons_config=/etc/default
> > > -fi
> > > +xencommons_config=@CONFIG_DIR@/@CONFIG_LEAF_DIR@
> > >  
> > >  test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
> > >  
> > > diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > > index 44dfce8..1e930ed 100644
> > > --- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > > +++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > > @@ -5,8 +5,7 @@ RefuseManualStop=true
> > >  
> > >  [Mount]
> > >  Environment=XENSTORED_MOUNT_CTX=none
> > > -EnvironmentFile=-/etc/sysconfig/xenstored
> > > -EnvironmentFile=-/etc/default/xenstored
> > > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> > >  What=xenstore
> > >  Where=@XEN_LIB_STORED@
> > >  Type=tmpfs
> > > diff --git a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > > index d3470fc..2282923 100644
> > > --- a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > > +++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > > @@ -8,8 +8,7 @@ ConditionVirtualization=xen
> > >  
> > >  [Service]
> > >  Type=simple
> > > -EnvironmentFile=-/etc/default/xenstored
> > > -EnvironmentFile=-/etc/sysconfig/xenstored
> > > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> > >  PIDFile=@XEN_RUN_DIR@/qemu-dom0.pid
> > >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> > >  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> > > diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > > index 7ca0264..377f131 100644
> > > --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > > +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > > @@ -9,8 +9,7 @@ Type=simple
> > >  Environment=XENCONSOLED_ARGS=
> > >  Environment=XENCONSOLED_LOG=none
> > >  Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
> > > -EnvironmentFile=-/etc/default/xenconsoled
> > > -EnvironmentFile=-/etc/sysconfig/xenconsoled
> > > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
> > >  PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
> > >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> > >  ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
> > > diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
> > > index 013e69e..f85b37d 100644
> > > --- a/tools/hotplug/Linux/systemd/xenstored.service.in
> > > +++ b/tools/hotplug/Linux/systemd/xenstored.service.in
> > > @@ -11,8 +11,7 @@ Type=notify
> > >  Environment=XENSTORED_ARGS=
> > >  Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
> > >  Environment=XENSTORED=@XENSTORED@
> > > -EnvironmentFile=-/etc/default/xencommons
> > > -EnvironmentFile=-/etc/sysconfig/xencommons
> > > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
> > >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> > >  ExecStartPre=-/bin/rm -f @XEN_LIB_STORED@/tdb*
> > >  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> > > diff --git a/tools/hotplug/Linux/xendomains.in b/tools/hotplug/Linux/xendomains.in
> > > index de711b7..2e65ac6 100644
> > > --- a/tools/hotplug/Linux/xendomains.in
> > > +++ b/tools/hotplug/Linux/xendomains.in
> > > @@ -51,11 +51,7 @@ fi
> > >  
> > >  LOCKFILE=${XEN_LOCK_DIR}/xendomains
> > >  
> > > -if [ -d /etc/sysconfig ]; then
> > > -	XENDOM_CONFIG=/etc/sysconfig/xendomains
> > > -else
> > > -	XENDOM_CONFIG=/etc/default/xendomains
> > > -fi
> > > +XENDOM_CONFIG=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xendomains
> > >  
> > >  test -r $XENDOM_CONFIG || { echo "$XENDOM_CONFIG not existing";
> > >  	if [ "$1" = "stop" ]; then exit 0;
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF9-0003vC-7J; Wed, 12 Nov 2014 16:58:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobF7-0003uS-Hv
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:05 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	FB/D5-05632-C9193645; Wed, 12 Nov 2014 16:58:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415811482!10882117!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29693 invoked from network); 12 Nov 2014 16:58:04 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:04 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvrtO018592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:54 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvqqL029200
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:53 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvqF1002971; Wed, 12 Nov 2014 16:57:52 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:52 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E7465114BA0; Wed, 12 Nov 2014 10:16:24 -0500 (EST)
Date: Wed, 12 Nov 2014 10:16:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141112151624.GB6017@laptop.dumpdata.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
	<1415789784.25176.67.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415789784.25176.67.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
 DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 10:56:24AM +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 10:39 +0000, Wei Liu wrote:
> > ... otherwise when device add operation fails, the error message looks
> > like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
> > device", which is not very helpful.
> 
> Thanks.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  tools/libxl/libxl.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..de23fec 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
> >                                                                          \
> >          GCNEW(aodev);                                                   \
> >          libxl__prepare_ao_device(ao, aodev);                            \
> > +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
> >          aodev->callback = device_addrm_aocomplete;                      \
> >          aodev->update_json = true;                                      \
> >          libxl__device_##type##_add(egc, domid, type, aodev);            \
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF8-0003un-CF; Wed, 12 Nov 2014 16:58:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobF6-0003uI-Km
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:04 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	6D/D7-02712-B9193645; Wed, 12 Nov 2014 16:58:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415811482!8774118!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27154 invoked from network); 12 Nov 2014 16:58:03 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvsoP018620
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:54 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvrY6011415
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:53 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvqG2029198; Wed, 12 Nov 2014 16:57:52 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:52 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 990B7114BA8; Wed, 12 Nov 2014 10:18:41 -0500 (EST)
Date: Wed, 12 Nov 2014 10:18:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141112151841.GD6017@laptop.dumpdata.com>
References: <1415790602-25779-1-git-send-email-jgross@suse.com>
	<CAFLBxZbtXBEdG5gWYgGOeAB1zJr=E7hLVd4f4=bXFQ7juLWvPg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZbtXBEdG5gWYgGOeAB1zJr=E7hLVd4f4=bXFQ7juLWvPg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Juergen Gross <jgross@suse.com>, Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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 Wed, Nov 12, 2014 at 11:11:15AM +0000, George Dunlap wrote:
> On Wed, Nov 12, 2014 at 11:10 AM, Juergen Gross <jgross@suse.com> wrote:
> > Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> > cpupool0 before destroying it) introduced an error in the accounting
> > of cpupools regarding the number of domains. The number of domains
> > is nor adjusted when a domain is moved to cpupool0 in kill_domain().
> >
> > Correct this by introducing a cpupool function doing the move
> > instead of open coding it by calling sched_move_domain().
> >
> > Signed-off-by: Juergen Gross <jgross@suse.com>
> > Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> > Reviewed-by: Andrew Cooper <Andrew.Cooper3@citrix.com>
> 
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Excellent!

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF8-0003uu-NJ; Wed, 12 Nov 2014 16:58:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobF6-0003uN-V2
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:05 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	71/1D-09936-C9193645; Wed, 12 Nov 2014 16:58:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415811482!8814739!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21809 invoked from network); 12 Nov 2014 16:58:03 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvtvp018680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:56 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvsn3011512
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:55 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvsfO029288; Wed, 12 Nov 2014 16:57:54 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3D223114B9A; Wed, 12 Nov 2014 10:14:28 -0500 (EST)
Date: Wed, 12 Nov 2014 10:14:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Malcolm Crossley <malcolm.crossley@citrix.com>
Message-ID: <20141112151428.GA6017@laptop.dumpdata.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
	<20141112013757.GC2593@laptop.dumpdata.com>
	<5463355B0200007800046B17@mail.emea.novell.com>
	<54632FF8.7020508@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54632FF8.7020508@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 10:01:28AM +0000, Malcolm Crossley wrote:
> On 12/11/14 09:24, Jan Beulich wrote:
> >>>> On 12.11.14 at 02:37, <konrad.wilk@oracle.com> wrote:
> >> When we PCI insert an device, the BARs are not set at all - and hence
> >> the Linux kernel is the one that tries to set the BARs in. The
> >> reason it cannot fit the device in the MMIO region is due to the
> >> _CRS only having certain ranges (even thought the MMIO region can
> >> cover 2GB). See:
> >>
> >> Without any devices (and me doing PCI insertion after that):
> >> # dmesg | grep "bus resource"
> >> [    0.366000] pci_bus 0000:00: root bus resource [bus 00-ff]
> >> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> >> [    0.366000] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> >> [    0.366000] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> >> [    0.366000] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
> >>
> >> With the device (my GPU card) inserted so that hvmloader can enumerate it:
> >>  dmesg | grep 'resource'     
> >> [    0.455006] pci_bus 0000:00: root bus resource [bus 00-ff]
> >> [    0.459006] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> >> [    0.462006] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> >> [    0.466006] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> >> [    0.469006] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbffffff]
> >>
> >> I chatted with Bjorn and Rafeal on IRC about how PCI insertion works
> >> on baremetal and it sounds like Thunderbolt device insertion is an
> >> interesting case. The SMM sets the BAR regions to fit within the MMIO
> >> (which is advertised by the _CRS) and it then pokes the OS to enumerate
> >> the BARs. The OS is free to use what the firmware has set or renumber
> >> it. The end result is that since the SMM 'fits' the BAR inside the
> >> pre-set _CRS window it all works. We do not do that.
> > 
> > Who does the BAR assignment is pretty much orthogonal to the
> > problem at hand: If the region reserved for MMIO is too small,
> > no-one will be able to fit a device in there. Plus, what is being
> > reported as root bus resource doesn't have to have a
> > connection to the ranges usable for MMIO at all, at least if I
> > assume that the (Dell) system I'm right now looking at isn't
> > completely screwed:
> > 
> > pci_bus 0000:00: root bus resource [bus 00-ff]
> > pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > pci_bus 0000:00: root bus resource [mem 0x00000000-0x3fffffffff]
> > 
> > (i.e. it simply reports the full usable 38 bits wide address space)
> > 
> > Looking at another (Intel) one, there is no mention of regions
> > above the 4G boundary at all:
> > 
> > pci_bus 0000:00: root bus resource [bus 00-3d]
> > pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> > pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> > pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> > pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000cbfff]
> > pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfedfffff]
> > pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff]
> > 
> > Not sure how the OS would know it is safe to assign BARs above
> > 4Gb here.
> > 
> > In any event, what you need is an equivalent of the frequently
> > seen BIOS option controlling the size of the space to be reserved
> > for MMIO (often allowing it to be 1, 2, or 3 Gb). I.e. an alternative
> > (or extension) to the dynamic lowering of pci_mem_start in
> > hvmloader.
> > 
> 
> I agree with Jan. By using xl pci-attach you are effectively hotplugging
> a PCI device (in the bare metal case). The only way this will work
> reliably is if you reserve some MMIO space for the device you are about
> to attach. You cannot just use space above the 4G boundary because the
> PCI device may have 32 bit only BAR's and thus it's MMIO cannot be
> placed at addresses above 4G.

Is it safe to split the BARs to be in different locations? Say stash
all 64-bit BARs above 4GB and put all 32-bit under 4GB?

Looking at the hvmloader it looks to be doing that if it has exhausted
the mmio_total.

> 
> The problem you have is that you cannot predict how much MMIO space to
> reserve because you don't know in advance how many PCI device's you are
> going to hotplug and how much MMIO space is required per device.

Perhaps following Jan's advice allow "bigger" MMIO ranges to be
predefined: 4GB, 8Gb, 16GB, etc. And the larger ranges would cover
space under 4GB (so say max 3GB) while the rest is spilled past the 4GB
past the 'maxmem' range?

> 
> As for the CRS regions: These typically describe the BIOS set limits in
> hardware configuration for the MMIO hole itself. On single socket
> systems anything which isn't RAM or another predefined region decodes to
> MMIO. This is probably why Jan's Dell system has a CRS region which
> covers the entire address space.
> 
> On multi socket systems the CRS is very important because the chipset is
> configured to only decode certain regions to the PCI express ports, if
> you use an address out side of those regions then accessing that address
> will go "nowhere" and the machine will crash.
> 
> Typically you will see a separate high MMIO CRS region if 64bit BAR
> support is enabled in BIOS.
> 
> 
> To do HVM pci hotplug properly we need to reserve MMIO space below 4G
> and emulate a PCI hotplug capable PCI-PCI bridge device. The bridge
> device will know the maximum size of the MMIO behind it (as allocated at
> boot time) and so we can calculate if the device we are hotplugging can
> fit. If it doesn't fit then we fail the hotplug otherwise we allow it
> and the OS will correct allocate the BAR behind the bridge.

I think that can be done right now for the MMIO and _CRS in hvmloader
and libxc/libxl. I wonder if that can all be done without having an
PCI-PCI bridge device introduced?

> 
> BTW, calculating the required MMIO for multi BAR PCI device's is not
> easy because all the BAR's need to be aligned to their size (naturally
> aligned).

Ouch. So two 512MB and an 1GB can't be next to each but would need:
512GB BAR<-- 512GB space--->| 1GB BAR.

Or just put the 1GB first:

1GB BAR | 512GB 

?

> 
> Malcolm
> 
> 
> > Jan
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> > 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF9-0003vK-Ij; Wed, 12 Nov 2014 16:58:07 +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 1XobF7-0003uT-Gq
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:05 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	B5/D9-02702-C9193645; Wed, 12 Nov 2014 16:58:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415811482!12118987!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29752 invoked from network); 12 Nov 2014 16:58:04 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:04 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvwAx010432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:59 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvvYQ003391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 16:57:57 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACGvuIR023146; Wed, 12 Nov 2014 16:57:56 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B047D114BA4; Wed, 12 Nov 2014 10:18:13 -0500 (EST)
Date: Wed, 12 Nov 2014 10:18:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141112151813.GC6017@laptop.dumpdata.com>
References: <1415790602-25779-1-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415790602-25779-1-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew.Cooper3@citrix.com, dietmar.hahn@ts.fujitsu.com, jbeulich@suse.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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 Wed, Nov 12, 2014 at 12:10:02PM +0100, Juergen Gross wrote:
> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> cpupool0 before destroying it) introduced an error in the accounting
> of cpupools regarding the number of domains. The number of domains
> is nor adjusted when a domain is moved to cpupool0 in kill_domain().

s/nor/not/
> 
> Correct this by introducing a cpupool function doing the move
> instead of open coding it by calling sched_move_domain().
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> Reviewed-by: Andrew Cooper <Andrew.Cooper3@citrix.com>
> ---
>  xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
>  xen/common/domain.c     |  2 +-
>  xen/include/xen/sched.h |  1 +
>  3 files changed, 35 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
> index 73249d3..a758a8b 100644
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
>  }
>  
>  /*
> + * Move domain to another cpupool
> + */
> +static int cpupool_move_domain_locked(struct domain *d, struct cpupool *c)
> +{
> +    int ret;
> +
> +    d->cpupool->n_dom--;
> +    ret = sched_move_domain(d, c);
> +    if ( ret )
> +        d->cpupool->n_dom++;
> +    else
> +        c->n_dom++;
> +
> +    return ret;
> +}

\n ?

> +int cpupool_move_domain(struct domain *d, struct cpupool *c)
> +{
> +    int ret;
> +
> +    spin_lock(&cpupool_lock);
> +
> +    ret = cpupool_move_domain_locked(d, c);
> +
> +    spin_unlock(&cpupool_lock);
> +
> +    return ret;
> +}
> +
> +/*
>   * assign a specific cpu to a cpupool
>   * cpupool_lock must be held
>   */
> @@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
>                  ret = -EBUSY;
>                  break;
>              }
> -            c->n_dom--;
> -            ret = sched_move_domain(d, cpupool0);
> +            ret = cpupool_move_domain_locked(d, cpupool0);
>              if ( ret )
> -            {
> -                c->n_dom++;
>                  break;
> -            }
> -            cpupool0->n_dom++;
>          }
>          rcu_read_unlock(&domlist_read_lock);
>          if ( ret )
> @@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
>                          d->domain_id, op->cpupool_id);
>          ret = -ENOENT;
>          spin_lock(&cpupool_lock);
> +
>          c = cpupool_find_by_id(op->cpupool_id);
>          if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
> -        {
> -            d->cpupool->n_dom--;
> -            ret = sched_move_domain(d, c);
> -            if ( ret )
> -                d->cpupool->n_dom++;
> -            else
> -                c->n_dom++;
> -        }
> +            ret = cpupool_move_domain_locked(d, c);
> +
>          spin_unlock(&cpupool_lock);
>          cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
>                          d->domain_id, op->cpupool_id, ret);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index a3f51ec..4a62c1d 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
>                  rc = -EAGAIN;
>              break;
>          }
> -        if ( sched_move_domain(d, cpupool0) )
> +        if ( cpupool_move_domain(d, cpupool0) )
>              return -EAGAIN;
>          for_each_vcpu ( d, v )
>              unmap_vcpu_info(v);
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index c5157e6..46fc6e3 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
>  void cpupool_put(struct cpupool *pool);
>  int cpupool_add_domain(struct domain *d, int poolid);
>  void cpupool_rm_domain(struct domain *d);
> +int cpupool_move_domain(struct domain *d, struct cpupool *c);
>  int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
>  void schedule_dump(struct cpupool *c);
>  extern void dump_runq(unsigned char key);
> -- 
> 2.1.2
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF8-0003ug-0W; Wed, 12 Nov 2014 16:58:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobF6-0003uA-Bg
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	44/6B-24532-B9193645; Wed, 12 Nov 2014 16:58:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415811480!12269891!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20626 invoked from network); 12 Nov 2014 16:58:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:01 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvupr018726
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:57 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvtxe011599
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:56 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvt2f011579; Wed, 12 Nov 2014 16:57:55 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1B077114AFF; Wed, 12 Nov 2014 09:23:59 -0500 (EST)
Date: Wed, 12 Nov 2014 09:23:58 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141112142358.GC3084@laptop.dumpdata.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<20141112121448.GB28075@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112121448.GB28075@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 12:14:48PM +0000, Wei Liu wrote:
> On Tue, Nov 11, 2014 at 06:03:22PM +0000, David Vrabel wrote:
> > On 11/11/14 17:36, Wei Liu wrote:
> > > # What's already implemented?
> > > 
> > > PV vNUMA support in libxl/xl and Linux kernel.
> > 
> > Linux doesn't have vnuma yet, although the last set of patches I saw
> > looked fine and were waiting for acks from x86 maintainers I think.
> > 
> 
> What I meant was I have those implemented but not yet posted. ;-)

Are you refering to the patches that Elena posted and that
were Acked? Or is this another set that does things differently?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobFB-0003vu-VD; Wed, 12 Nov 2014 16:58:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobFA-0003vR-Et
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:08 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	CD/94-02576-F9193645; Wed, 12 Nov 2014 16:58:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415811485!12022956!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25629 invoked from network); 12 Nov 2014 16:58:07 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:07 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvu02010364
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:57 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvthj003288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:55 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvtIs003282; Wed, 12 Nov 2014 16:57:55 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 852E6114BB6; Wed, 12 Nov 2014 10:21:11 -0500 (EST)
Date: Wed, 12 Nov 2014 10:21:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141112152111.GE6017@laptop.dumpdata.com>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415790726.29592.4.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 11:12:06AM +0000, Ian Campbell wrote:
> You forgot to add the release manager... I've done that for you.
> 
> In <1413279117.1497.25.camel@citrix.com> I said:
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Is this a bug fix or a feature? What are the risks? IsLKonrad OK with
> > it?

Back again to that question.

What happens if we do not take that in now but delay to Xen 4.6?

Will systemd still correctly work? It looks like it will and 
this is just an improvement that makes the code be more streamlined.

It does not fix a bug (at least that is what I see from
reading), I believe this should be deferred to Xen 4.6.


> 
> On Wed, 2014-11-12 at 12:06 +0100, Olaf Hering wrote:
> > Ping?
> > 
> > 
> > > ... instead of hardcoding values and guess where they config files may
> > > be. Also use the result of --with-sysconfig-leaf-dir.
> > > 
> > > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Cc: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > >  tools/hotplug/Linux/init.d/xencommons.in                          | 6 +-----
> > >  tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 3 +--
> > >  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 3 +--
> > >  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 3 +--
> > >  tools/hotplug/Linux/systemd/xenstored.service.in                  | 3 +--
> > >  tools/hotplug/Linux/xendomains.in                                 | 6 +-----
> > >  6 files changed, 6 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
> > > index d53a1f3..a1095c2 100644
> > > --- a/tools/hotplug/Linux/init.d/xencommons.in
> > > +++ b/tools/hotplug/Linux/init.d/xencommons.in
> > > @@ -23,11 +23,7 @@ BACKEND_MODULES="@LINUX_BACKEND_MODULES@"
> > >  
> > >  . @XEN_SCRIPT_DIR@/hotplugpath.sh
> > >  
> > > -if [ -d /etc/sysconfig ]; then
> > > -	xencommons_config=/etc/sysconfig
> > > -else
> > > -	xencommons_config=/etc/default
> > > -fi
> > > +xencommons_config=@CONFIG_DIR@/@CONFIG_LEAF_DIR@
> > >  
> > >  test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
> > >  
> > > diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > > index 44dfce8..1e930ed 100644
> > > --- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > > +++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > > @@ -5,8 +5,7 @@ RefuseManualStop=true
> > >  
> > >  [Mount]
> > >  Environment=XENSTORED_MOUNT_CTX=none
> > > -EnvironmentFile=-/etc/sysconfig/xenstored
> > > -EnvironmentFile=-/etc/default/xenstored
> > > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> > >  What=xenstore
> > >  Where=@XEN_LIB_STORED@
> > >  Type=tmpfs
> > > diff --git a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > > index d3470fc..2282923 100644
> > > --- a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > > +++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> > > @@ -8,8 +8,7 @@ ConditionVirtualization=xen
> > >  
> > >  [Service]
> > >  Type=simple
> > > -EnvironmentFile=-/etc/default/xenstored
> > > -EnvironmentFile=-/etc/sysconfig/xenstored
> > > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> > >  PIDFile=@XEN_RUN_DIR@/qemu-dom0.pid
> > >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> > >  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> > > diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > > index 7ca0264..377f131 100644
> > > --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > > +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > > @@ -9,8 +9,7 @@ Type=simple
> > >  Environment=XENCONSOLED_ARGS=
> > >  Environment=XENCONSOLED_LOG=none
> > >  Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
> > > -EnvironmentFile=-/etc/default/xenconsoled
> > > -EnvironmentFile=-/etc/sysconfig/xenconsoled
> > > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
> > >  PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
> > >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> > >  ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
> > > diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
> > > index 013e69e..f85b37d 100644
> > > --- a/tools/hotplug/Linux/systemd/xenstored.service.in
> > > +++ b/tools/hotplug/Linux/systemd/xenstored.service.in
> > > @@ -11,8 +11,7 @@ Type=notify
> > >  Environment=XENSTORED_ARGS=
> > >  Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
> > >  Environment=XENSTORED=@XENSTORED@
> > > -EnvironmentFile=-/etc/default/xencommons
> > > -EnvironmentFile=-/etc/sysconfig/xencommons
> > > +EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
> > >  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> > >  ExecStartPre=-/bin/rm -f @XEN_LIB_STORED@/tdb*
> > >  ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
> > > diff --git a/tools/hotplug/Linux/xendomains.in b/tools/hotplug/Linux/xendomains.in
> > > index de711b7..2e65ac6 100644
> > > --- a/tools/hotplug/Linux/xendomains.in
> > > +++ b/tools/hotplug/Linux/xendomains.in
> > > @@ -51,11 +51,7 @@ fi
> > >  
> > >  LOCKFILE=${XEN_LOCK_DIR}/xendomains
> > >  
> > > -if [ -d /etc/sysconfig ]; then
> > > -	XENDOM_CONFIG=/etc/sysconfig/xendomains
> > > -else
> > > -	XENDOM_CONFIG=/etc/default/xendomains
> > > -fi
> > > +XENDOM_CONFIG=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xendomains
> > >  
> > >  test -r $XENDOM_CONFIG || { echo "$XENDOM_CONFIG not existing";
> > >  	if [ "$1" = "stop" ]; then exit 0;
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF9-0003vK-Ij; Wed, 12 Nov 2014 16:58:07 +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 1XobF7-0003uT-Gq
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:05 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	B5/D9-02702-C9193645; Wed, 12 Nov 2014 16:58:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415811482!12118987!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29752 invoked from network); 12 Nov 2014 16:58:04 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:04 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvwAx010432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:59 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvvYQ003391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 16:57:57 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACGvuIR023146; Wed, 12 Nov 2014 16:57:56 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B047D114BA4; Wed, 12 Nov 2014 10:18:13 -0500 (EST)
Date: Wed, 12 Nov 2014 10:18:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141112151813.GC6017@laptop.dumpdata.com>
References: <1415790602-25779-1-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415790602-25779-1-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew.Cooper3@citrix.com, dietmar.hahn@ts.fujitsu.com, jbeulich@suse.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Adjust number of domains in cpupools when
 destroying 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 Wed, Nov 12, 2014 at 12:10:02PM +0100, Juergen Gross wrote:
> Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a (move domain to
> cpupool0 before destroying it) introduced an error in the accounting
> of cpupools regarding the number of domains. The number of domains
> is nor adjusted when a domain is moved to cpupool0 in kill_domain().

s/nor/not/
> 
> Correct this by introducing a cpupool function doing the move
> instead of open coding it by calling sched_move_domain().
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> Reviewed-by: Andrew Cooper <Andrew.Cooper3@citrix.com>
> ---
>  xen/common/cpupool.c    | 47 +++++++++++++++++++++++++++++++++--------------
>  xen/common/domain.c     |  2 +-
>  xen/include/xen/sched.h |  1 +
>  3 files changed, 35 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
> index 73249d3..a758a8b 100644
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
>  }
>  
>  /*
> + * Move domain to another cpupool
> + */
> +static int cpupool_move_domain_locked(struct domain *d, struct cpupool *c)
> +{
> +    int ret;
> +
> +    d->cpupool->n_dom--;
> +    ret = sched_move_domain(d, c);
> +    if ( ret )
> +        d->cpupool->n_dom++;
> +    else
> +        c->n_dom++;
> +
> +    return ret;
> +}

\n ?

> +int cpupool_move_domain(struct domain *d, struct cpupool *c)
> +{
> +    int ret;
> +
> +    spin_lock(&cpupool_lock);
> +
> +    ret = cpupool_move_domain_locked(d, c);
> +
> +    spin_unlock(&cpupool_lock);
> +
> +    return ret;
> +}
> +
> +/*
>   * assign a specific cpu to a cpupool
>   * cpupool_lock must be held
>   */
> @@ -338,14 +367,9 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
>                  ret = -EBUSY;
>                  break;
>              }
> -            c->n_dom--;
> -            ret = sched_move_domain(d, cpupool0);
> +            ret = cpupool_move_domain_locked(d, cpupool0);
>              if ( ret )
> -            {
> -                c->n_dom++;
>                  break;
> -            }
> -            cpupool0->n_dom++;
>          }
>          rcu_read_unlock(&domlist_read_lock);
>          if ( ret )
> @@ -613,16 +637,11 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
>                          d->domain_id, op->cpupool_id);
>          ret = -ENOENT;
>          spin_lock(&cpupool_lock);
> +
>          c = cpupool_find_by_id(op->cpupool_id);
>          if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
> -        {
> -            d->cpupool->n_dom--;
> -            ret = sched_move_domain(d, c);
> -            if ( ret )
> -                d->cpupool->n_dom++;
> -            else
> -                c->n_dom++;
> -        }
> +            ret = cpupool_move_domain_locked(d, c);
> +
>          spin_unlock(&cpupool_lock);
>          cpupool_dprintk("cpupool move_domain(dom=%d)->pool=%d ret %d\n",
>                          d->domain_id, op->cpupool_id, ret);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index a3f51ec..4a62c1d 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -621,7 +621,7 @@ int domain_kill(struct domain *d)
>                  rc = -EAGAIN;
>              break;
>          }
> -        if ( sched_move_domain(d, cpupool0) )
> +        if ( cpupool_move_domain(d, cpupool0) )
>              return -EAGAIN;
>          for_each_vcpu ( d, v )
>              unmap_vcpu_info(v);
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index c5157e6..46fc6e3 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -871,6 +871,7 @@ struct cpupool *cpupool_get_by_id(int poolid);
>  void cpupool_put(struct cpupool *pool);
>  int cpupool_add_domain(struct domain *d, int poolid);
>  void cpupool_rm_domain(struct domain *d);
> +int cpupool_move_domain(struct domain *d, struct cpupool *c);
>  int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
>  void schedule_dump(struct cpupool *c);
>  extern void dump_runq(unsigned char key);
> -- 
> 2.1.2
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF5-0003uB-LA; Wed, 12 Nov 2014 16:58:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobF4-0003u5-9F
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:02 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	FE/98-02698-99193645; Wed, 12 Nov 2014 16:58:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415811479!12117837!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29820 invoked from network); 12 Nov 2014 16:58:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:01 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvuwW018723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:57 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvteA003308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 16:57:56 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACGvsal023088; Wed, 12 Nov 2014 16:57:55 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 61690114CB7; Wed, 12 Nov 2014 11:23:06 -0500 (EST)
Date: Wed, 12 Nov 2014 11:23:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141112162306.GA24513@laptop.dumpdata.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C76C@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A4C76C@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] Xen-4.5.0 RC1 bug: with
 "xen_platform_pci=0" option,
 the guest with VT-d device fails to boot up and qemu-xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Basic root-causing log:
> ----------------------
> [root@vt-hsw1 carl]# xl cr xlexample.hvm 
> Parsing config from xlexample.hvm
> libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error
> message from QMP server: Unsupported bus. Bus doesn't have property
> 'acpi-pcihp-bsel' set
> libxl: error: libxl_create.c:1385:domcreate_attach_pci: libxl_device_pci_add
> failed: -3

I can reproduce this.

If you use "device_model_version = 'qemu-xen-traditional'" the problem
go aways and you can boot the guest without Xen PCI platform driver.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16: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 1XobF9-0003vC-7J; Wed, 12 Nov 2014 16:58:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobF7-0003uS-Hv
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:58:05 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	FB/D5-05632-C9193645; Wed, 12 Nov 2014 16:58:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415811482!10882117!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29693 invoked from network); 12 Nov 2014 16:58:04 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:58:04 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvrtO018592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:54 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvqqL029200
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:53 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvqF1002971; Wed, 12 Nov 2014 16:57:52 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:52 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E7465114BA0; Wed, 12 Nov 2014 10:16:24 -0500 (EST)
Date: Wed, 12 Nov 2014 10:16:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141112151624.GB6017@laptop.dumpdata.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
	<1415789784.25176.67.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415789784.25176.67.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
 DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 10:56:24AM +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 10:39 +0000, Wei Liu wrote:
> > ... otherwise when device add operation fails, the error message looks
> > like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
> > device", which is not very helpful.
> 
> Thanks.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  tools/libxl/libxl.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..de23fec 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
> >                                                                          \
> >          GCNEW(aodev);                                                   \
> >          libxl__prepare_ao_device(ao, aodev);                            \
> > +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
> >          aodev->callback = device_addrm_aocomplete;                      \
> >          aodev->update_json = true;                                      \
> >          libxl__device_##type##_add(egc, domid, type, aodev);            \
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 12 16:59:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16:59:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobGH-0004OI-Jo; Wed, 12 Nov 2014 16:59:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobGG-0004Nn-9n
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:59:16 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	B9/CA-02559-3E193645; Wed, 12 Nov 2014 16:59:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415811553!7469077!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10028 invoked from network); 12 Nov 2014 16:59:14 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:59:14 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvuBT010363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:56 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvsgR029327
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:55 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvseK003243; Wed, 12 Nov 2014 16:57:54 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 58D48114BB9; Wed, 12 Nov 2014 10:22:07 -0500 (EST)
Date: Wed, 12 Nov 2014 10:22:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141112152207.GF6017@laptop.dumpdata.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
	<1415790652.29592.3.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415790652.29592.3.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Chao Peng <chao.p.peng@linux.intel.com>,
	Dongxiao Xu <dongxiao.xu@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
 libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 11:10:52AM +0000, Ian Campbell wrote:
> CCing the folks who signed-of-by is on the original patch
> 
> On Wed, 2014-11-12 at 11:05 +0000, Wei Liu wrote:
> > The `if' statement considered return value 0 from libxl_domain_info an
> > error, while 0 actually means success.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> > This is a bug fix for PSR feature. This feature was added recently and it's
> > not an regression. However, it would be good to have it working correctly
> > since the beginning, and the fix is straightforward, which should be of
> > very low risk.
> 
> Ack.

I concur and I think it should go in Xen 4.5, but I would like their
input first.

> 
> > ---
> >  tools/libxl/xl_cmdimpl.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 3c9f146..9afef3f 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -7908,7 +7908,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
> >      /* Each domain */
> >      if (domid != INVALID_DOMID) {
> >          libxl_dominfo dominfo;
> > -        if (!libxl_domain_info(ctx, &dominfo, domid)) {
> > +        if (libxl_domain_info(ctx, &dominfo, domid)) {
> >              fprintf(stderr, "Failed to get domain info for %d\n", domid);
> >              return -1;
> >          }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:59:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16:59:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobGH-0004OI-Jo; Wed, 12 Nov 2014 16:59:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobGG-0004Nn-9n
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 16:59:16 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	B9/CA-02559-3E193645; Wed, 12 Nov 2014 16:59:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415811553!7469077!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10028 invoked from network); 12 Nov 2014 16:59:14 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 16:59:14 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACGvuBT010363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 16:57:56 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvsgR029327
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 16:57:55 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACGvseK003243; Wed, 12 Nov 2014 16:57:54 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 08:57:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 58D48114BB9; Wed, 12 Nov 2014 10:22:07 -0500 (EST)
Date: Wed, 12 Nov 2014 10:22:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141112152207.GF6017@laptop.dumpdata.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
	<1415790652.29592.3.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415790652.29592.3.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Chao Peng <chao.p.peng@linux.intel.com>,
	Dongxiao Xu <dongxiao.xu@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
 libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 11:10:52AM +0000, Ian Campbell wrote:
> CCing the folks who signed-of-by is on the original patch
> 
> On Wed, 2014-11-12 at 11:05 +0000, Wei Liu wrote:
> > The `if' statement considered return value 0 from libxl_domain_info an
> > error, while 0 actually means success.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> > This is a bug fix for PSR feature. This feature was added recently and it's
> > not an regression. However, it would be good to have it working correctly
> > since the beginning, and the fix is straightforward, which should be of
> > very low risk.
> 
> Ack.

I concur and I think it should go in Xen 4.5, but I would like their
input first.

> 
> > ---
> >  tools/libxl/xl_cmdimpl.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 3c9f146..9afef3f 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -7908,7 +7908,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
> >      /* Each domain */
> >      if (domid != INVALID_DOMID) {
> >          libxl_dominfo dominfo;
> > -        if (!libxl_domain_info(ctx, &dominfo, domid)) {
> > +        if (libxl_domain_info(ctx, &dominfo, domid)) {
> >              fprintf(stderr, "Failed to get domain info for %d\n", domid);
> >              return -1;
> >          }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:59:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16:59:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobGJ-0004PL-0s; Wed, 12 Nov 2014 16:59:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XobGH-0004OC-NU
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 16:59:17 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	37/D4-22737-5E193645; Wed, 12 Nov 2014 16:59:17 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415811553!8062648!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14838 invoked from network); 12 Nov 2014 16:59:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 16:59:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192042410"
Message-ID: <546391DE.7040508@citrix.com>
Date: Wed, 12 Nov 2014 16:59:10 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
	<546390FC0200007800046E50@mail.emea.novell.com>
In-Reply-To: <546390FC0200007800046E50@mail.emea.novell.com>
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 15:55, Jan Beulich wrote:
>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +	u64 max_mfn;
>> +
>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
>> +}
> 
> The value the hypercall returns is exclusive and an unsigned long.

The docs in include/public/memory.h say:

"Returns the maximum machine frame number of mapped RAM in this system."

Which sounds inclusive to me...  Do we need a doc update here?

> Hence I'd suggest
> 
> u64
> xen_swiotlb_get_required_mask(struct device *dev)
> {
> 	unsigned long max_mfn;
> 
> 	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
> 
> 	return DMA_BIT_MASK(__fls(max_mfn - 1) + 1 + PAGE_SHIFT);
> }
> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 16:59:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 16:59:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobGJ-0004PL-0s; Wed, 12 Nov 2014 16:59:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XobGH-0004OC-NU
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 16:59:17 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	37/D4-22737-5E193645; Wed, 12 Nov 2014 16:59:17 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415811553!8062648!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14838 invoked from network); 12 Nov 2014 16:59:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 16:59:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192042410"
Message-ID: <546391DE.7040508@citrix.com>
Date: Wed, 12 Nov 2014 16:59:10 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
	<546390FC0200007800046E50@mail.emea.novell.com>
In-Reply-To: <546390FC0200007800046E50@mail.emea.novell.com>
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 15:55, Jan Beulich wrote:
>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +	u64 max_mfn;
>> +
>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
>> +}
> 
> The value the hypercall returns is exclusive and an unsigned long.

The docs in include/public/memory.h say:

"Returns the maximum machine frame number of mapped RAM in this system."

Which sounds inclusive to me...  Do we need a doc update here?

> Hence I'd suggest
> 
> u64
> xen_swiotlb_get_required_mask(struct device *dev)
> {
> 	unsigned long max_mfn;
> 
> 	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
> 
> 	return DMA_BIT_MASK(__fls(max_mfn - 1) + 1 + PAGE_SHIFT);
> }
> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobNo-0005KI-41; Wed, 12 Nov 2014 17:07:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XobNm-0005KD-B9
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:07:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EC/DB-24532-5B393645; Wed, 12 Nov 2014 17:07:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415812020!12270412!1
X-Originating-IP: [81.169.146.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26019 invoked from network); 12 Nov 2014 17:07:01 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:07:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415812020; l=662;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=9s0VQhUpKDg6oov1NEnB5s53utQ=;
	b=cjJxTPHGo1qWm/Zlu0VlDjn/I9IrXtQqfsBLtEDEI8SiVpP0GCEulO95P6ZLiHqz1IL
	P8xH9hgYymmLxxIYaOQ37/oryDuXlBb8PICI6+dG5BI46I23AykiiNToSA2jOl1rdPtby
	6OBKioe7fFJVAhxvR7tAE48+HMb4zeK9eeo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.11 AUTH) with ESMTPSA id k04502qACH6wYPF
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 12 Nov 2014 18:06:58 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A11F050172; Wed, 12 Nov 2014 18:06:57 +0100 (CET)
Date: Wed, 12 Nov 2014 18:06:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141112170657.GA15386@aepfle.de>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
	<20141112152111.GE6017@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112152111.GE6017@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, 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 for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:

 
> What happens if we do not take that in now but delay to Xen 4.6?

I will be very unhappy...
I mean, what exactly is the concern here?!

> Will systemd still correctly work? It looks like it will and 
> this is just an improvement that makes the code be more streamlined.
> 
> It does not fix a bug (at least that is what I see from
> reading), I believe this should be deferred to Xen 4.6.

It does fix a bug. If the whole thing was configured with --prefix=X
--sysconfdir=Y parts of it will still refer to hardcoded paths entirely
unrelated to what was just installed with 'make install'.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobNo-0005KI-41; Wed, 12 Nov 2014 17:07:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XobNm-0005KD-B9
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:07:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EC/DB-24532-5B393645; Wed, 12 Nov 2014 17:07:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415812020!12270412!1
X-Originating-IP: [81.169.146.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26019 invoked from network); 12 Nov 2014 17:07:01 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:07:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415812020; l=662;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=9s0VQhUpKDg6oov1NEnB5s53utQ=;
	b=cjJxTPHGo1qWm/Zlu0VlDjn/I9IrXtQqfsBLtEDEI8SiVpP0GCEulO95P6ZLiHqz1IL
	P8xH9hgYymmLxxIYaOQ37/oryDuXlBb8PICI6+dG5BI46I23AykiiNToSA2jOl1rdPtby
	6OBKioe7fFJVAhxvR7tAE48+HMb4zeK9eeo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.11 AUTH) with ESMTPSA id k04502qACH6wYPF
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 12 Nov 2014 18:06:58 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A11F050172; Wed, 12 Nov 2014 18:06:57 +0100 (CET)
Date: Wed, 12 Nov 2014 18:06:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141112170657.GA15386@aepfle.de>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
	<20141112152111.GE6017@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112152111.GE6017@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, 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 for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:

 
> What happens if we do not take that in now but delay to Xen 4.6?

I will be very unhappy...
I mean, what exactly is the concern here?!

> Will systemd still correctly work? It looks like it will and 
> this is just an improvement that makes the code be more streamlined.
> 
> It does not fix a bug (at least that is what I see from
> reading), I believe this should be deferred to Xen 4.6.

It does fix a bug. If the whole thing was configured with --prefix=X
--sysconfdir=Y parts of it will still refer to hardcoded paths entirely
unrelated to what was just installed with 'make install'.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:12:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:12:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobSh-0005X4-Ra; Wed, 12 Nov 2014 17:12:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XobSe-0005Vd-27
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:12:06 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	FF/A2-17694-3E493645; Wed, 12 Nov 2014 17:12:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415812321!10957604!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22738 invoked from network); 12 Nov 2014 17:12:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:12:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192048626"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:11:42 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XobRJ-00026t-HS;
	Wed, 12 Nov 2014 17:10:41 +0000
Date: Wed, 12 Nov 2014 17:10:41 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141112171041.GA2884@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<20141112121448.GB28075@zion.uk.xensource.com>
	<20141112142358.GC3084@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112142358.GC3084@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 09:23:58AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 12:14:48PM +0000, Wei Liu wrote:
> > On Tue, Nov 11, 2014 at 06:03:22PM +0000, David Vrabel wrote:
> > > On 11/11/14 17:36, Wei Liu wrote:
> > > > # What's already implemented?
> > > > 
> > > > PV vNUMA support in libxl/xl and Linux kernel.
> > > 
> > > Linux doesn't have vnuma yet, although the last set of patches I saw
> > > looked fine and were waiting for acks from x86 maintainers I think.
> > > 
> > 
> > What I meant was I have those implemented but not yet posted. ;-)
> 
> Are you refering to the patches that Elena posted and that
> were Acked? Or is this another set that does things differently?

The interface changed last minute before applying to Xen so I rewrote
both the toolstack and kernel patches. They are still patches for PV
vNUMA but do things differently. Most changes are in toolstack part,
kernel patch mainly adapts to the new assumptions I make.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:12:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:12:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobSh-0005X4-Ra; Wed, 12 Nov 2014 17:12:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XobSe-0005Vd-27
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:12:06 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	FF/A2-17694-3E493645; Wed, 12 Nov 2014 17:12:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415812321!10957604!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22738 invoked from network); 12 Nov 2014 17:12:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:12:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192048626"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:11:42 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XobRJ-00026t-HS;
	Wed, 12 Nov 2014 17:10:41 +0000
Date: Wed, 12 Nov 2014 17:10:41 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141112171041.GA2884@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
	<54624F6A.40002@citrix.com>
	<20141112121448.GB28075@zion.uk.xensource.com>
	<20141112142358.GC3084@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112142358.GC3084@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 09:23:58AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 12:14:48PM +0000, Wei Liu wrote:
> > On Tue, Nov 11, 2014 at 06:03:22PM +0000, David Vrabel wrote:
> > > On 11/11/14 17:36, Wei Liu wrote:
> > > > # What's already implemented?
> > > > 
> > > > PV vNUMA support in libxl/xl and Linux kernel.
> > > 
> > > Linux doesn't have vnuma yet, although the last set of patches I saw
> > > looked fine and were waiting for acks from x86 maintainers I think.
> > > 
> > 
> > What I meant was I have those implemented but not yet posted. ;-)
> 
> Are you refering to the patches that Elena posted and that
> were Acked? Or is this another set that does things differently?

The interface changed last minute before applying to Xen so I rewrote
both the toolstack and kernel patches. They are still patches for PV
vNUMA but do things differently. Most changes are in toolstack part,
kernel patch mainly adapts to the new assumptions I make.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:13:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1XobTt-0005fm-A3; Wed, 12 Nov 2014 17:13:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XobTr-0005fe-Ql
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:13:19 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	1D/A4-17694-F2593645; Wed, 12 Nov 2014 17:13:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415812382!8494273!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7645 invoked from network); 12 Nov 2014 17:13:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:13:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192049268"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:13:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XobLF-0001wk-ME;
	Wed, 12 Nov 2014 17:04:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 17:04:23 +0000
Message-ID: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, zhigang.x.wang@oracle.com,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print partial
	config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This small series change the behavior of libxl_retrieve_domain_configuration,
to make it continue to retrieve information from xenstore even if JSON template
is not available.

This change of API behaviour is only internal. Conceptually speaking, any
non-zero return value means d_config is partially filled. The chanage just
makes it fill in more information (xenstore entries) than before (empty).
Caller can still expect zero on success and non-zero on error and act
accordingly.

"xl list -l" is now changed to print out the partial configuration, since it
needs to be consistent with the short output.

Wei.

Wei Liu (2):
  libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
  xl: print out partial configuration in long mode of list command

 tools/libxl/libxl.c      |    6 +++++-
 tools/libxl/xl_cmdimpl.c |    6 ++----
 2 files changed, 7 insertions(+), 5 deletions(-)

-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:13:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 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.xen.org>)
	id 1XobTt-0005fm-A3; Wed, 12 Nov 2014 17:13:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XobTr-0005fe-Ql
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:13:19 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	1D/A4-17694-F2593645; Wed, 12 Nov 2014 17:13:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415812382!8494273!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7645 invoked from network); 12 Nov 2014 17:13:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:13:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192049268"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:13:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XobLF-0001wk-ME;
	Wed, 12 Nov 2014 17:04:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 17:04:23 +0000
Message-ID: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, zhigang.x.wang@oracle.com,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print partial
	config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This small series change the behavior of libxl_retrieve_domain_configuration,
to make it continue to retrieve information from xenstore even if JSON template
is not available.

This change of API behaviour is only internal. Conceptually speaking, any
non-zero return value means d_config is partially filled. The chanage just
makes it fill in more information (xenstore entries) than before (empty).
Caller can still expect zero on success and non-zero on error and act
accordingly.

"xl list -l" is now changed to print out the partial configuration, since it
needs to be consistent with the short output.

Wei.

Wei Liu (2):
  libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
  xl: print out partial configuration in long mode of list command

 tools/libxl/libxl.c      |    6 +++++-
 tools/libxl/xl_cmdimpl.c |    6 ++----
 2 files changed, 7 insertions(+), 5 deletions(-)

-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:17:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17: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 1XobXj-0005rm-Ux; Wed, 12 Nov 2014 17:17:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobXj-0005rh-Er
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:17:19 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	F3/75-02696-E1693645; Wed, 12 Nov 2014 17:17:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415812636!12111632!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15011 invoked from network); 12 Nov 2014 17:17:18 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:17:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACHH5EV015890
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 17:17:06 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACHH3hB012850
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 17:17:03 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACHH2cK022218; Wed, 12 Nov 2014 17:17:02 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 09:17:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4DD8E114D3E; Wed, 12 Nov 2014 12:16:59 -0500 (EST)
Date: Wed, 12 Nov 2014 12:16:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141112171659.GA32634@laptop.dumpdata.com>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
	<20141112152111.GE6017@laptop.dumpdata.com>
	<20141112170657.GA15386@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112170657.GA15386@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Wei Liu <wei.liu2@citrix.com>, 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 for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 06:06:57PM +0100, Olaf Hering wrote:
> On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> 
>  
> > What happens if we do not take that in now but delay to Xen 4.6?
> 
> I will be very unhappy...
> I mean, what exactly is the concern here?!

I need to know what the risk is if this does not go in. We
are at RC2 and I really want to make the amount of patches
that go in be a trickle.
> 
> > Will systemd still correctly work? It looks like it will and 
> > this is just an improvement that makes the code be more streamlined.
> > 
> > It does not fix a bug (at least that is what I see from
> > reading), I believe this should be deferred to Xen 4.6.
> 
> It does fix a bug. If the whole thing was configured with --prefix=X
> --sysconfdir=Y parts of it will still refer to hardcoded paths entirely
> unrelated to what was just installed with 'make install'.

How often does that happen? Do the two paths that are specified
in the code cover 99% of the use-cases?

> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:17:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17: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 1XobXj-0005rm-Ux; Wed, 12 Nov 2014 17:17:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobXj-0005rh-Er
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:17:19 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	F3/75-02696-E1693645; Wed, 12 Nov 2014 17:17:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415812636!12111632!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15011 invoked from network); 12 Nov 2014 17:17:18 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:17:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACHH5EV015890
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 17:17:06 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACHH3hB012850
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 17:17:03 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACHH2cK022218; Wed, 12 Nov 2014 17:17:02 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 09:17:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4DD8E114D3E; Wed, 12 Nov 2014 12:16:59 -0500 (EST)
Date: Wed, 12 Nov 2014 12:16:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141112171659.GA32634@laptop.dumpdata.com>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
	<20141112152111.GE6017@laptop.dumpdata.com>
	<20141112170657.GA15386@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112170657.GA15386@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Wei Liu <wei.liu2@citrix.com>, 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 for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 06:06:57PM +0100, Olaf Hering wrote:
> On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> 
>  
> > What happens if we do not take that in now but delay to Xen 4.6?
> 
> I will be very unhappy...
> I mean, what exactly is the concern here?!

I need to know what the risk is if this does not go in. We
are at RC2 and I really want to make the amount of patches
that go in be a trickle.
> 
> > Will systemd still correctly work? It looks like it will and 
> > this is just an improvement that makes the code be more streamlined.
> > 
> > It does not fix a bug (at least that is what I see from
> > reading), I believe this should be deferred to Xen 4.6.
> 
> It does fix a bug. If the whole thing was configured with --prefix=X
> --sysconfdir=Y parts of it will still refer to hardcoded paths entirely
> unrelated to what was just installed with 'make install'.

How often does that happen? Do the two paths that are specified
in the code cover 99% of the use-cases?

> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:18:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobZ3-0005yr-GA; Wed, 12 Nov 2014 17:18: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 1XobZ1-0005yh-UJ
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 17:18:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	48/71-09936-F6693645; Wed, 12 Nov 2014 17:18:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415812718!12273898!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21214 invoked from network); 12 Nov 2014 17:18:38 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:18:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 17:18:36 +0000
Message-Id: <5463A47A0200007800046F19@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 17:18:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
	<546390FC0200007800046E50@mail.emea.novell.com>
	<546391DE.7040508@citrix.com>
In-Reply-To: <546391DE.7040508@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	BorisOstrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 17:59, <david.vrabel@citrix.com> wrote:
> On 12/11/14 15:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>>> +u64
>>> +xen_swiotlb_get_required_mask(struct device *dev)
>>> +{
>>> +	u64 max_mfn;
>>> +
>>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>>> +
>>> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
>>> +}
>> 
>> The value the hypercall returns is exclusive and an unsigned long.
> 
> The docs in include/public/memory.h say:
> 
> "Returns the maximum machine frame number of mapped RAM in this system."
> 
> Which sounds inclusive to me...  Do we need a doc update here?

Possibly - the origin of this is Linux'es mis-named "max_page" I believe.
And in any event I'd expect you to base your code changes on reality,
not just on documentation...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:18:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobZ3-0005yr-GA; Wed, 12 Nov 2014 17:18: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 1XobZ1-0005yh-UJ
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 17:18:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	48/71-09936-F6693645; Wed, 12 Nov 2014 17:18:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415812718!12273898!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21214 invoked from network); 12 Nov 2014 17:18:38 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:18:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 17:18:36 +0000
Message-Id: <5463A47A0200007800046F19@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 17:18:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
	<546390FC0200007800046E50@mail.emea.novell.com>
	<546391DE.7040508@citrix.com>
In-Reply-To: <546391DE.7040508@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	BorisOstrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 17:59, <david.vrabel@citrix.com> wrote:
> On 12/11/14 15:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>>> +u64
>>> +xen_swiotlb_get_required_mask(struct device *dev)
>>> +{
>>> +	u64 max_mfn;
>>> +
>>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>>> +
>>> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
>>> +}
>> 
>> The value the hypercall returns is exclusive and an unsigned long.
> 
> The docs in include/public/memory.h say:
> 
> "Returns the maximum machine frame number of mapped RAM in this system."
> 
> Which sounds inclusive to me...  Do we need a doc update here?

Possibly - the origin of this is Linux'es mis-named "max_page" I believe.
And in any event I'd expect you to base your code changes on reality,
not just on documentation...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:18:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobZB-00060Y-ST; Wed, 12 Nov 2014 17:18:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobZA-000605-25
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:18:48 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	72/8D-17694-77693645; Wed, 12 Nov 2014 17:18:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415812724!10811506!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20711 invoked from network); 12 Nov 2014 17:18:46 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:18:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACHIcjc009224
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 17:18:39 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACHIbEY011009
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 17:18:38 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACHIa2G029223; Wed, 12 Nov 2014 17:18:36 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 09:18:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B19C1114D40; Wed, 12 Nov 2014 12:18:32 -0500 (EST)
Date: Wed, 12 Nov 2014 12:18:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141112171832.GB32634@laptop.dumpdata.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print
	partial config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 05:04:23PM +0000, Wei Liu wrote:
> This small series change the behavior of libxl_retrieve_domain_configuration,
> to make it continue to retrieve information from xenstore even if JSON template
> is not available.
> 
> This change of API behaviour is only internal. Conceptually speaking, any
> non-zero return value means d_config is partially filled. The chanage just
> makes it fill in more information (xenstore entries) than before (empty).
> Caller can still expect zero on success and non-zero on error and act
> accordingly.

What are the work-arounds (if any) if this does not go in Xen 4.5?

> 
> "xl list -l" is now changed to print out the partial configuration, since it
> needs to be consistent with the short output.
> 
> Wei.
> 
> Wei Liu (2):
>   libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
>   xl: print out partial configuration in long mode of list command
> 
>  tools/libxl/libxl.c      |    6 +++++-
>  tools/libxl/xl_cmdimpl.c |    6 ++----
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:18:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobZB-00060Y-ST; Wed, 12 Nov 2014 17:18:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XobZA-000605-25
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:18:48 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	72/8D-17694-77693645; Wed, 12 Nov 2014 17:18:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415812724!10811506!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20711 invoked from network); 12 Nov 2014 17:18:46 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:18:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACHIcjc009224
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 17:18:39 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACHIbEY011009
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 17:18:38 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACHIa2G029223; Wed, 12 Nov 2014 17:18:36 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 09:18:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B19C1114D40; Wed, 12 Nov 2014 12:18:32 -0500 (EST)
Date: Wed, 12 Nov 2014 12:18:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141112171832.GB32634@laptop.dumpdata.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print
	partial config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 05:04:23PM +0000, Wei Liu wrote:
> This small series change the behavior of libxl_retrieve_domain_configuration,
> to make it continue to retrieve information from xenstore even if JSON template
> is not available.
> 
> This change of API behaviour is only internal. Conceptually speaking, any
> non-zero return value means d_config is partially filled. The chanage just
> makes it fill in more information (xenstore entries) than before (empty).
> Caller can still expect zero on success and non-zero on error and act
> accordingly.

What are the work-arounds (if any) if this does not go in Xen 4.5?

> 
> "xl list -l" is now changed to print out the partial configuration, since it
> needs to be consistent with the short output.
> 
> Wei.
> 
> Wei Liu (2):
>   libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
>   xl: print out partial configuration in long mode of list command
> 
>  tools/libxl/libxl.c      |    6 +++++-
>  tools/libxl/xl_cmdimpl.c |    6 ++----
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:20:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xobar-0006Eh-IU; Wed, 12 Nov 2014 17:20:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xobaq-0006ES-7f
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 17:20:32 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	3E/30-28296-FD693645; Wed, 12 Nov 2014 17:20:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415812829!10979684!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13201 invoked from network); 12 Nov 2014 17:20:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:20:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACHKO32020573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 17:20:24 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACHKNRw018004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 17:20:23 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACHKNMf027453; Wed, 12 Nov 2014 17:20:23 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 09:20:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 91587114D48; Wed, 12 Nov 2014 12:20:20 -0500 (EST)
Date: Wed, 12 Nov 2014 12:20:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141112172020.GC32634@laptop.dumpdata.com>
References: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
	<54638307.1080500@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54638307.1080500@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] xen_disk: fix unmapping of
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 03:55:51PM +0000, George Dunlap wrote:
> On 11/12/2014 03:45 PM, Roger Pau Monne wrote:
> >This patch fixes two issues with persistent grants and the disk PV backe=
nd
> >(Qdisk):
> >
> >  - Don't use batch mappings when using persistent grants, doing so prev=
ents
> >    unmapping single grants (the whole area has to be unmapped at once).
> >  - Unmap persistent grants before switching to the closed state, so the
> >    frontend can also free them.
> >
> >Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
> >Reported-and-Tested-by: George Dunlap <george.dunlap@eu.citrix.com>
> >Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >Cc: Kevin Wolf <kwolf@redhat.com>
> >Cc: Stefan Hajnoczi <stefanha@redhat.com>
> >Cc: George Dunlap <george.dunlap@eu.citrix.com>
> =

> CC'ing Konrad and Stefano: This fixes a critical bug that should be a
> blocker for the Xen 4.5 release.  Without this, any backend using qdisk f=
or
> a PV guest with pygrub (including qcow2 and vhd) will crash dom0.

Changing the title to reflect that.

Stefano?
> =

>  -George
> =

> >---
> >  hw/block/xen_disk.c | 35 ++++++++++++++++++++++++-----------
> >  1 file changed, 24 insertions(+), 11 deletions(-)
> >
> >diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> >index 231e9a7..1300c0a 100644
> >--- a/hw/block/xen_disk.c
> >+++ b/hw/block/xen_disk.c
> >@@ -43,8 +43,6 @@
> >  /* ------------------------------------------------------------- */
> >-static int batch_maps   =3D 0;
> >-
> >  static int max_requests =3D 32;
> >  /* ------------------------------------------------------------- */
> >@@ -105,6 +103,7 @@ struct XenBlkDev {
> >      blkif_back_rings_t  rings;
> >      int                 more_work;
> >      int                 cnt_map;
> >+    bool                batch_maps;
> >      /* request lists */
> >      QLIST_HEAD(inflight_head, ioreq) inflight;
> >@@ -309,7 +308,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
> >      if (ioreq->num_unmap =3D=3D 0 || ioreq->mapped =3D=3D 0) {
> >          return;
> >      }
> >-    if (batch_maps) {
> >+    if (ioreq->blkdev->batch_maps) {
> >          if (!ioreq->pages) {
> >              return;
> >          }
> >@@ -386,7 +385,7 @@ static int ioreq_map(struct ioreq *ioreq)
> >          new_maps =3D ioreq->v.niov;
> >      }
> >-    if (batch_maps && new_maps) {
> >+    if (ioreq->blkdev->batch_maps && new_maps) {
> >          ioreq->pages =3D xc_gnttab_map_grant_refs
> >              (gnt, new_maps, domids, refs, ioreq->prot);
> >          if (ioreq->pages =3D=3D NULL) {
> >@@ -433,7 +432,7 @@ static int ioreq_map(struct ioreq *ioreq)
> >               */
> >              grant =3D g_malloc0(sizeof(*grant));
> >              new_maps--;
> >-            if (batch_maps) {
> >+            if (ioreq->blkdev->batch_maps) {
> >                  grant->page =3D ioreq->pages + (new_maps) * XC_PAGE_SI=
ZE;
> >              } else {
> >                  grant->page =3D ioreq->page[new_maps];
> >@@ -718,7 +717,9 @@ static void blk_alloc(struct XenDevice *xendev)
> >      QLIST_INIT(&blkdev->freelist);
> >      blkdev->bh =3D qemu_bh_new(blk_bh, blkdev);
> >      if (xen_mode !=3D XEN_EMULATE) {
> >-        batch_maps =3D 1;
> >+        blkdev->batch_maps =3D TRUE;
> >+    } else {
> >+        blkdev->batch_maps =3D FALSE;
> >      }
> >      if (xc_gnttab_set_max_grants(xendev->gnttabdev,
> >              MAX_GRANTS(max_requests, BLKIF_MAX_SEGMENTS_PER_REQUEST)) =
< 0) {
> >@@ -923,6 +924,13 @@ static int blk_connect(struct XenDevice *xendev)
> >      } else {
> >          blkdev->feature_persistent =3D !!pers;
> >      }
> >+    if (blkdev->feature_persistent) {
> >+        /*
> >+         * Disable batch maps, since that would prevent unmapping
> >+         * single persistent grants.
> >+         */
> >+        blkdev->batch_maps =3D FALSE;
> >+    }
> >      blkdev->protocol =3D BLKIF_PROTOCOL_NATIVE;
> >      if (blkdev->xendev.protocol) {
> >@@ -1000,6 +1008,16 @@ static void blk_disconnect(struct XenDevice *xend=
ev)
> >          blkdev->cnt_map--;
> >          blkdev->sring =3D NULL;
> >      }
> >+
> >+    /*
> >+     * Unmap persistent grants before switching to the closed state
> >+     * so the frontend can free them.
> >+     */
> >+    if (blkdev->feature_persistent) {
> >+        g_tree_destroy(blkdev->persistent_gnts);
> >+        assert(blkdev->persistent_gnt_count =3D=3D 0);
> >+        blkdev->feature_persistent =3D FALSE;
> >+    }
> >  }
> >  static int blk_free(struct XenDevice *xendev)
> >@@ -1011,11 +1029,6 @@ static int blk_free(struct XenDevice *xendev)
> >          blk_disconnect(xendev);
> >      }
> >-    /* Free persistent grants */
> >-    if (blkdev->feature_persistent) {
> >-        g_tree_destroy(blkdev->persistent_gnts);
> >-    }
> >-
> >      while (!QLIST_EMPTY(&blkdev->freelist)) {
> >          ioreq =3D QLIST_FIRST(&blkdev->freelist);
> >          QLIST_REMOVE(ioreq, list);
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:20:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xobar-0006Eh-IU; Wed, 12 Nov 2014 17:20:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xobaq-0006ES-7f
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 17:20:32 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	3E/30-28296-FD693645; Wed, 12 Nov 2014 17:20:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415812829!10979684!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13201 invoked from network); 12 Nov 2014 17:20:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:20:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACHKO32020573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 17:20:24 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACHKNRw018004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 17:20:23 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACHKNMf027453; Wed, 12 Nov 2014 17:20:23 GMT
Received: from laptop.dumpdata.com (/172.56.22.255)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 09:20:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 91587114D48; Wed, 12 Nov 2014 12:20:20 -0500 (EST)
Date: Wed, 12 Nov 2014 12:20:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141112172020.GC32634@laptop.dumpdata.com>
References: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
	<54638307.1080500@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54638307.1080500@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] xen_disk: fix unmapping of
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 03:55:51PM +0000, George Dunlap wrote:
> On 11/12/2014 03:45 PM, Roger Pau Monne wrote:
> >This patch fixes two issues with persistent grants and the disk PV backe=
nd
> >(Qdisk):
> >
> >  - Don't use batch mappings when using persistent grants, doing so prev=
ents
> >    unmapping single grants (the whole area has to be unmapped at once).
> >  - Unmap persistent grants before switching to the closed state, so the
> >    frontend can also free them.
> >
> >Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
> >Reported-and-Tested-by: George Dunlap <george.dunlap@eu.citrix.com>
> >Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >Cc: Kevin Wolf <kwolf@redhat.com>
> >Cc: Stefan Hajnoczi <stefanha@redhat.com>
> >Cc: George Dunlap <george.dunlap@eu.citrix.com>
> =

> CC'ing Konrad and Stefano: This fixes a critical bug that should be a
> blocker for the Xen 4.5 release.  Without this, any backend using qdisk f=
or
> a PV guest with pygrub (including qcow2 and vhd) will crash dom0.

Changing the title to reflect that.

Stefano?
> =

>  -George
> =

> >---
> >  hw/block/xen_disk.c | 35 ++++++++++++++++++++++++-----------
> >  1 file changed, 24 insertions(+), 11 deletions(-)
> >
> >diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> >index 231e9a7..1300c0a 100644
> >--- a/hw/block/xen_disk.c
> >+++ b/hw/block/xen_disk.c
> >@@ -43,8 +43,6 @@
> >  /* ------------------------------------------------------------- */
> >-static int batch_maps   =3D 0;
> >-
> >  static int max_requests =3D 32;
> >  /* ------------------------------------------------------------- */
> >@@ -105,6 +103,7 @@ struct XenBlkDev {
> >      blkif_back_rings_t  rings;
> >      int                 more_work;
> >      int                 cnt_map;
> >+    bool                batch_maps;
> >      /* request lists */
> >      QLIST_HEAD(inflight_head, ioreq) inflight;
> >@@ -309,7 +308,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
> >      if (ioreq->num_unmap =3D=3D 0 || ioreq->mapped =3D=3D 0) {
> >          return;
> >      }
> >-    if (batch_maps) {
> >+    if (ioreq->blkdev->batch_maps) {
> >          if (!ioreq->pages) {
> >              return;
> >          }
> >@@ -386,7 +385,7 @@ static int ioreq_map(struct ioreq *ioreq)
> >          new_maps =3D ioreq->v.niov;
> >      }
> >-    if (batch_maps && new_maps) {
> >+    if (ioreq->blkdev->batch_maps && new_maps) {
> >          ioreq->pages =3D xc_gnttab_map_grant_refs
> >              (gnt, new_maps, domids, refs, ioreq->prot);
> >          if (ioreq->pages =3D=3D NULL) {
> >@@ -433,7 +432,7 @@ static int ioreq_map(struct ioreq *ioreq)
> >               */
> >              grant =3D g_malloc0(sizeof(*grant));
> >              new_maps--;
> >-            if (batch_maps) {
> >+            if (ioreq->blkdev->batch_maps) {
> >                  grant->page =3D ioreq->pages + (new_maps) * XC_PAGE_SI=
ZE;
> >              } else {
> >                  grant->page =3D ioreq->page[new_maps];
> >@@ -718,7 +717,9 @@ static void blk_alloc(struct XenDevice *xendev)
> >      QLIST_INIT(&blkdev->freelist);
> >      blkdev->bh =3D qemu_bh_new(blk_bh, blkdev);
> >      if (xen_mode !=3D XEN_EMULATE) {
> >-        batch_maps =3D 1;
> >+        blkdev->batch_maps =3D TRUE;
> >+    } else {
> >+        blkdev->batch_maps =3D FALSE;
> >      }
> >      if (xc_gnttab_set_max_grants(xendev->gnttabdev,
> >              MAX_GRANTS(max_requests, BLKIF_MAX_SEGMENTS_PER_REQUEST)) =
< 0) {
> >@@ -923,6 +924,13 @@ static int blk_connect(struct XenDevice *xendev)
> >      } else {
> >          blkdev->feature_persistent =3D !!pers;
> >      }
> >+    if (blkdev->feature_persistent) {
> >+        /*
> >+         * Disable batch maps, since that would prevent unmapping
> >+         * single persistent grants.
> >+         */
> >+        blkdev->batch_maps =3D FALSE;
> >+    }
> >      blkdev->protocol =3D BLKIF_PROTOCOL_NATIVE;
> >      if (blkdev->xendev.protocol) {
> >@@ -1000,6 +1008,16 @@ static void blk_disconnect(struct XenDevice *xend=
ev)
> >          blkdev->cnt_map--;
> >          blkdev->sring =3D NULL;
> >      }
> >+
> >+    /*
> >+     * Unmap persistent grants before switching to the closed state
> >+     * so the frontend can free them.
> >+     */
> >+    if (blkdev->feature_persistent) {
> >+        g_tree_destroy(blkdev->persistent_gnts);
> >+        assert(blkdev->persistent_gnt_count =3D=3D 0);
> >+        blkdev->feature_persistent =3D FALSE;
> >+    }
> >  }
> >  static int blk_free(struct XenDevice *xendev)
> >@@ -1011,11 +1029,6 @@ static int blk_free(struct XenDevice *xendev)
> >          blk_disconnect(xendev);
> >      }
> >-    /* Free persistent grants */
> >-    if (blkdev->feature_persistent) {
> >-        g_tree_destroy(blkdev->persistent_gnts);
> >-    }
> >-
> >      while (!QLIST_EMPTY(&blkdev->freelist)) {
> >          ioreq =3D QLIST_FIRST(&blkdev->freelist);
> >          QLIST_REMOVE(ioreq, list);
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:24:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:24:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xobe5-0006ae-5h; Wed, 12 Nov 2014 17:23:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xobe3-0006aX-Cr
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:23:51 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	59/69-25727-6A793645; Wed, 12 Nov 2014 17:23:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415813030!10889628!1
X-Originating-IP: [81.169.146.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13024 invoked from network); 12 Nov 2014 17:23:50 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:23:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415813030; l=1353;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=p+juNf4SI/RwQGw1HMvrlUTYfGI=;
	b=w27x9WonTb2HSOPO75LMyExJfzxecg5Hso0BCv6NaKwYvUviUKT+9X0fc3i/NkDrGzd
	K4A+vtM66vbjdou0ldVwEDJlFKPwmOwSRC4YzsyrCa3YKvZAeMQsms1/srI/Eu0D66EfN
	RUkjGqnyNsXyJn9H2VRRgfJmpbiHAx+u08s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.11 AUTH) with ESMTPSA id x03838qACHNkavB
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 12 Nov 2014 18:23:46 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 72A6250172; Wed, 12 Nov 2014 18:23:46 +0100 (CET)
Date: Wed, 12 Nov 2014 18:23:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141112172346.GC17230@aepfle.de>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
	<20141112152111.GE6017@laptop.dumpdata.com>
	<20141112170657.GA15386@aepfle.de>
	<20141112171659.GA32634@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112171659.GA32634@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, 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 for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:

> On Wed, Nov 12, 2014 at 06:06:57PM +0100, Olaf Hering wrote:
> > On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> > 
> >  
> > > What happens if we do not take that in now but delay to Xen 4.6?
> > 
> > I will be very unhappy...
> > I mean, what exactly is the concern here?!
> 
> I need to know what the risk is if this does not go in. We
> are at RC2 and I really want to make the amount of patches
> that go in be a trickle.

Its risk free.

> > > Will systemd still correctly work? It looks like it will and 
> > > this is just an improvement that makes the code be more streamlined.
> > > 
> > > It does not fix a bug (at least that is what I see from
> > > reading), I believe this should be deferred to Xen 4.6.
> > 
> > It does fix a bug. If the whole thing was configured with --prefix=X
> > --sysconfdir=Y parts of it will still refer to hardcoded paths entirely
> > unrelated to what was just installed with 'make install'.
> 
> How often does that happen? Do the two paths that are specified
> in the code cover 99% of the use-cases?

It covers 100% of the use cases. Just today someone complained on
xen-users that stuff isnt appearing below /usr/local (not sure why, not
our fault), but even if it was there it wouldnt be used because the code
hardcodes /etc.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:24:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:24:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xobe5-0006ae-5h; Wed, 12 Nov 2014 17:23:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xobe3-0006aX-Cr
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:23:51 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	59/69-25727-6A793645; Wed, 12 Nov 2014 17:23:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415813030!10889628!1
X-Originating-IP: [81.169.146.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13024 invoked from network); 12 Nov 2014 17:23:50 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:23:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415813030; l=1353;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=p+juNf4SI/RwQGw1HMvrlUTYfGI=;
	b=w27x9WonTb2HSOPO75LMyExJfzxecg5Hso0BCv6NaKwYvUviUKT+9X0fc3i/NkDrGzd
	K4A+vtM66vbjdou0ldVwEDJlFKPwmOwSRC4YzsyrCa3YKvZAeMQsms1/srI/Eu0D66EfN
	RUkjGqnyNsXyJn9H2VRRgfJmpbiHAx+u08s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.11 AUTH) with ESMTPSA id x03838qACHNkavB
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 12 Nov 2014 18:23:46 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 72A6250172; Wed, 12 Nov 2014 18:23:46 +0100 (CET)
Date: Wed, 12 Nov 2014 18:23:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141112172346.GC17230@aepfle.de>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
	<20141112152111.GE6017@laptop.dumpdata.com>
	<20141112170657.GA15386@aepfle.de>
	<20141112171659.GA32634@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112171659.GA32634@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, 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 for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:

> On Wed, Nov 12, 2014 at 06:06:57PM +0100, Olaf Hering wrote:
> > On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> > 
> >  
> > > What happens if we do not take that in now but delay to Xen 4.6?
> > 
> > I will be very unhappy...
> > I mean, what exactly is the concern here?!
> 
> I need to know what the risk is if this does not go in. We
> are at RC2 and I really want to make the amount of patches
> that go in be a trickle.

Its risk free.

> > > Will systemd still correctly work? It looks like it will and 
> > > this is just an improvement that makes the code be more streamlined.
> > > 
> > > It does not fix a bug (at least that is what I see from
> > > reading), I believe this should be deferred to Xen 4.6.
> > 
> > It does fix a bug. If the whole thing was configured with --prefix=X
> > --sysconfdir=Y parts of it will still refer to hardcoded paths entirely
> > unrelated to what was just installed with 'make install'.
> 
> How often does that happen? Do the two paths that are specified
> in the code cover 99% of the use-cases?

It covers 100% of the use cases. Just today someone complained on
xen-users that stuff isnt appearing below /usr/local (not sure why, not
our fault), but even if it was there it wouldnt be used because the code
hardcodes /etc.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:24:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:24:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobeK-0006cR-It; Wed, 12 Nov 2014 17:24:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XobeI-0006by-Mw
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:24:06 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	18/A2-27623-5B793645; Wed, 12 Nov 2014 17:24:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415813045!10874023!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13240 invoked from network); 12 Nov 2014 17:24:05 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:24:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 17:24:05 +0000
Message-Id: <5463A5C30200007800046F3E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 17:24:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
	<20141112013757.GC2593@laptop.dumpdata.com>
	<5463355B0200007800046B17@mail.emea.novell.com>
	<54632FF8.7020508@citrix.com>
	<20141112151428.GA6017@laptop.dumpdata.com>
In-Reply-To: <20141112151428.GA6017@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 16:14, <konrad.wilk@oracle.com> wrote:
> On Wed, Nov 12, 2014 at 10:01:28AM +0000, Malcolm Crossley wrote:
>> I agree with Jan. By using xl pci-attach you are effectively hotplugging
>> a PCI device (in the bare metal case). The only way this will work
>> reliably is if you reserve some MMIO space for the device you are about
>> to attach. You cannot just use space above the 4G boundary because the
>> PCI device may have 32 bit only BAR's and thus it's MMIO cannot be
>> placed at addresses above 4G.
> 
> Is it safe to split the BARs to be in different locations? Say stash
> all 64-bit BARs above 4GB and put all 32-bit under 4GB?

Sure.

>> The problem you have is that you cannot predict how much MMIO space to
>> reserve because you don't know in advance how many PCI device's you are
>> going to hotplug and how much MMIO space is required per device.
> 
> Perhaps following Jan's advice allow "bigger" MMIO ranges to be
> predefined: 4GB, 8Gb, 16GB, etc. And the larger ranges would cover
> space under 4GB (so say max 3GB) while the rest is spilled past the 4GB
> past the 'maxmem' range?

Not sure how you'd put a 4G or even 8G hole below the 4G
boundary... These BIOS settings only ever relate to space up to
4G (at least as far as I had seen them).

>> To do HVM pci hotplug properly we need to reserve MMIO space below 4G
>> and emulate a PCI hotplug capable PCI-PCI bridge device. The bridge
>> device will know the maximum size of the MMIO behind it (as allocated at
>> boot time) and so we can calculate if the device we are hotplugging can
>> fit. If it doesn't fit then we fail the hotplug otherwise we allow it
>> and the OS will correct allocate the BAR behind the bridge.
> 
> I think that can be done right now for the MMIO and _CRS in hvmloader
> and libxc/libxl. I wonder if that can all be done without having an
> PCI-PCI bridge device introduced?

I think it could, even if that possibly wouldn't be 100% spec conforming.

>> BTW, calculating the required MMIO for multi BAR PCI device's is not
>> easy because all the BAR's need to be aligned to their size (naturally
>> aligned).
> 
> Ouch. So two 512MB and an 1GB can't be next to each but would need:
> 512GB BAR<-- 512GB space--->| 1GB BAR.
> 
> Or just put the 1GB first:
> 
> 1GB BAR | 512GB 
> 
> ?

The latter is what one should prefer.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:24:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:24:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobeK-0006cR-It; Wed, 12 Nov 2014 17:24:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XobeI-0006by-Mw
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:24:06 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	18/A2-27623-5B793645; Wed, 12 Nov 2014 17:24:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415813045!10874023!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13240 invoked from network); 12 Nov 2014 17:24:05 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 17:24:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 17:24:05 +0000
Message-Id: <5463A5C30200007800046F3E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 17:24:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20141110173248.GA13778@laptop.dumpdata.com>
	<5460F908.4040208@citrix.com>
	<20141110180720.GA15286@laptop.dumpdata.com>
	<20141110213248.GA23182@laptop.dumpdata.com>
	<20141112013757.GC2593@laptop.dumpdata.com>
	<5463355B0200007800046B17@mail.emea.novell.com>
	<54632FF8.7020508@citrix.com>
	<20141112151428.GA6017@laptop.dumpdata.com>
In-Reply-To: <20141112151428.GA6017@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug
 (BAR64 addresses are bogus)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 16:14, <konrad.wilk@oracle.com> wrote:
> On Wed, Nov 12, 2014 at 10:01:28AM +0000, Malcolm Crossley wrote:
>> I agree with Jan. By using xl pci-attach you are effectively hotplugging
>> a PCI device (in the bare metal case). The only way this will work
>> reliably is if you reserve some MMIO space for the device you are about
>> to attach. You cannot just use space above the 4G boundary because the
>> PCI device may have 32 bit only BAR's and thus it's MMIO cannot be
>> placed at addresses above 4G.
> 
> Is it safe to split the BARs to be in different locations? Say stash
> all 64-bit BARs above 4GB and put all 32-bit under 4GB?

Sure.

>> The problem you have is that you cannot predict how much MMIO space to
>> reserve because you don't know in advance how many PCI device's you are
>> going to hotplug and how much MMIO space is required per device.
> 
> Perhaps following Jan's advice allow "bigger" MMIO ranges to be
> predefined: 4GB, 8Gb, 16GB, etc. And the larger ranges would cover
> space under 4GB (so say max 3GB) while the rest is spilled past the 4GB
> past the 'maxmem' range?

Not sure how you'd put a 4G or even 8G hole below the 4G
boundary... These BIOS settings only ever relate to space up to
4G (at least as far as I had seen them).

>> To do HVM pci hotplug properly we need to reserve MMIO space below 4G
>> and emulate a PCI hotplug capable PCI-PCI bridge device. The bridge
>> device will know the maximum size of the MMIO behind it (as allocated at
>> boot time) and so we can calculate if the device we are hotplugging can
>> fit. If it doesn't fit then we fail the hotplug otherwise we allow it
>> and the OS will correct allocate the BAR behind the bridge.
> 
> I think that can be done right now for the MMIO and _CRS in hvmloader
> and libxc/libxl. I wonder if that can all be done without having an
> PCI-PCI bridge device introduced?

I think it could, even if that possibly wouldn't be 100% spec conforming.

>> BTW, calculating the required MMIO for multi BAR PCI device's is not
>> easy because all the BAR's need to be aligned to their size (naturally
>> aligned).
> 
> Ouch. So two 512MB and an 1GB can't be next to each but would need:
> 512GB BAR<-- 512GB space--->| 1GB BAR.
> 
> Or just put the 1GB first:
> 
> 1GB BAR | 512GB 
> 
> ?

The latter is what one should prefer.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:28:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:28:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xobiq-0006sT-9l; Wed, 12 Nov 2014 17:28:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xobio-0006sO-8P
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:28:46 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	DD/20-02699-DC893645; Wed, 12 Nov 2014 17:28:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415813320!12119755!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23212 invoked from network); 12 Nov 2014 17:28:44 -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;
	12 Nov 2014 17:28:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192055774"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:28:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xobih-0002zW-Qc;
	Wed, 12 Nov 2014 17:28:39 +0000
Date: Wed, 12 Nov 2014 17:28:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141112172839.GA4309@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<20141112171832.GB32634@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112171832.GB32634@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, zhigang.x.wang@oracle.com,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print
 partial config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 12:18:32PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 05:04:23PM +0000, Wei Liu wrote:
> > This small series change the behavior of libxl_retrieve_domain_configuration,
> > to make it continue to retrieve information from xenstore even if JSON template
> > is not available.
> > 
> > This change of API behaviour is only internal. Conceptually speaking, any
> > non-zero return value means d_config is partially filled. The chanage just
> > makes it fill in more information (xenstore entries) than before (empty).
> > Caller can still expect zero on success and non-zero on error and act
> > accordingly.
> 
> What are the work-arounds (if any) if this does not go in Xen 4.5?
> 

The first patch to libxl doesn't change external visible behaviour, that
is, 0 on success, non-zero on error. So whether it goes in or not I
don't have very strong opinion. Keep in mind that this API is new so
this first patch wouldn't cause regression in any way.

For the inconsistency between short and long output, no workaround, but
it wouldn't be disastrous.

Wei.

> > 
> > "xl list -l" is now changed to print out the partial configuration, since it
> > needs to be consistent with the short output.
> > 
> > Wei.
> > 
> > Wei Liu (2):
> >   libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
> >   xl: print out partial configuration in long mode of list command
> > 
> >  tools/libxl/libxl.c      |    6 +++++-
> >  tools/libxl/xl_cmdimpl.c |    6 ++----
> >  2 files changed, 7 insertions(+), 5 deletions(-)
> > 
> > -- 
> > 1.7.10.4
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:28:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:28:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xobiq-0006sT-9l; Wed, 12 Nov 2014 17:28:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xobio-0006sO-8P
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:28:46 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	DD/20-02699-DC893645; Wed, 12 Nov 2014 17:28:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415813320!12119755!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23212 invoked from network); 12 Nov 2014 17:28:44 -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;
	12 Nov 2014 17:28:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192055774"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:28:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xobih-0002zW-Qc;
	Wed, 12 Nov 2014 17:28:39 +0000
Date: Wed, 12 Nov 2014 17:28:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141112172839.GA4309@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<20141112171832.GB32634@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112171832.GB32634@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, zhigang.x.wang@oracle.com,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print
 partial config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 12:18:32PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 05:04:23PM +0000, Wei Liu wrote:
> > This small series change the behavior of libxl_retrieve_domain_configuration,
> > to make it continue to retrieve information from xenstore even if JSON template
> > is not available.
> > 
> > This change of API behaviour is only internal. Conceptually speaking, any
> > non-zero return value means d_config is partially filled. The chanage just
> > makes it fill in more information (xenstore entries) than before (empty).
> > Caller can still expect zero on success and non-zero on error and act
> > accordingly.
> 
> What are the work-arounds (if any) if this does not go in Xen 4.5?
> 

The first patch to libxl doesn't change external visible behaviour, that
is, 0 on success, non-zero on error. So whether it goes in or not I
don't have very strong opinion. Keep in mind that this API is new so
this first patch wouldn't cause regression in any way.

For the inconsistency between short and long output, no workaround, but
it wouldn't be disastrous.

Wei.

> > 
> > "xl list -l" is now changed to print out the partial configuration, since it
> > needs to be consistent with the short output.
> > 
> > Wei.
> > 
> > Wei Liu (2):
> >   libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
> >   xl: print out partial configuration in long mode of list command
> > 
> >  tools/libxl/libxl.c      |    6 +++++-
> >  tools/libxl/xl_cmdimpl.c |    6 ++----
> >  2 files changed, 7 insertions(+), 5 deletions(-)
> > 
> > -- 
> > 1.7.10.4
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:31:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17: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.xen.org>)
	id 1Xoblf-0006zN-Vc; Wed, 12 Nov 2014 17:31:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xoble-0006zD-MP
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:31:42 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	EF/A6-02699-E7993645; Wed, 12 Nov 2014 17:31:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415813499!12097825!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21829 invoked from network); 12 Nov 2014 17:31:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:31:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192056755"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:31:04 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xobl2-000323-Es;
	Wed, 12 Nov 2014 17:31:04 +0000
Date: Wed, 12 Nov 2014 17:31:04 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141112173104.GB4309@zion.uk.xensource.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
	<1415790652.29592.3.camel@citrix.com>
	<20141112152207.GF6017@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112152207.GF6017@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Dongxiao Xu <dongxiao.xu@intel.com>,
	Chao Peng <chao.p.peng@linux.intel.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
 libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 10:22:07AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 11:10:52AM +0000, Ian Campbell wrote:
> > CCing the folks who signed-of-by is on the original patch
> > 
> > On Wed, 2014-11-12 at 11:05 +0000, Wei Liu wrote:
> > > The `if' statement considered return value 0 from libxl_domain_info an
> > > error, while 0 actually means success.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > ---
> > > This is a bug fix for PSR feature. This feature was added recently and it's
> > > not an regression. However, it would be good to have it working correctly
> > > since the beginning, and the fix is straightforward, which should be of
> > > very low risk.
> > 
> > Ack.
> 
> I concur and I think it should go in Xen 4.5, but I would like their
> input first.
> 

Dude, you're so cautious! ;-)

> > 
> > > ---
> > >  tools/libxl/xl_cmdimpl.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > > index 3c9f146..9afef3f 100644
> > > --- a/tools/libxl/xl_cmdimpl.c
> > > +++ b/tools/libxl/xl_cmdimpl.c
> > > @@ -7908,7 +7908,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
> > >      /* Each domain */
> > >      if (domid != INVALID_DOMID) {
> > >          libxl_dominfo dominfo;
> > > -        if (!libxl_domain_info(ctx, &dominfo, domid)) {
> > > +        if (libxl_domain_info(ctx, &dominfo, domid)) {
> > >              fprintf(stderr, "Failed to get domain info for %d\n", domid);
> > >              return -1;
> > >          }
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:31:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17: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.xen.org>)
	id 1Xoblf-0006zN-Vc; Wed, 12 Nov 2014 17:31:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xoble-0006zD-MP
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:31:42 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	EF/A6-02699-E7993645; Wed, 12 Nov 2014 17:31:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415813499!12097825!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21829 invoked from network); 12 Nov 2014 17:31:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:31:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192056755"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:31:04 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xobl2-000323-Es;
	Wed, 12 Nov 2014 17:31:04 +0000
Date: Wed, 12 Nov 2014 17:31:04 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141112173104.GB4309@zion.uk.xensource.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
	<1415790652.29592.3.camel@citrix.com>
	<20141112152207.GF6017@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112152207.GF6017@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Dongxiao Xu <dongxiao.xu@intel.com>,
	Chao Peng <chao.p.peng@linux.intel.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
 libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 10:22:07AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 11:10:52AM +0000, Ian Campbell wrote:
> > CCing the folks who signed-of-by is on the original patch
> > 
> > On Wed, 2014-11-12 at 11:05 +0000, Wei Liu wrote:
> > > The `if' statement considered return value 0 from libxl_domain_info an
> > > error, while 0 actually means success.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > ---
> > > This is a bug fix for PSR feature. This feature was added recently and it's
> > > not an regression. However, it would be good to have it working correctly
> > > since the beginning, and the fix is straightforward, which should be of
> > > very low risk.
> > 
> > Ack.
> 
> I concur and I think it should go in Xen 4.5, but I would like their
> input first.
> 

Dude, you're so cautious! ;-)

> > 
> > > ---
> > >  tools/libxl/xl_cmdimpl.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > > index 3c9f146..9afef3f 100644
> > > --- a/tools/libxl/xl_cmdimpl.c
> > > +++ b/tools/libxl/xl_cmdimpl.c
> > > @@ -7908,7 +7908,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
> > >      /* Each domain */
> > >      if (domid != INVALID_DOMID) {
> > >          libxl_dominfo dominfo;
> > > -        if (!libxl_domain_info(ctx, &dominfo, domid)) {
> > > +        if (libxl_domain_info(ctx, &dominfo, domid)) {
> > >              fprintf(stderr, "Failed to get domain info for %d\n", domid);
> > >              return -1;
> > >          }
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:40:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobuG-0007J8-0L; Wed, 12 Nov 2014 17:40:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XobuE-0007Iy-D3
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:40:34 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3D/F3-09936-19B93645; Wed, 12 Nov 2014 17:40:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415814030!12281818!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18756 invoked from network); 12 Nov 2014 17:40:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:40:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="190598516"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:13:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XobLF-0001wk-PE;
	Wed, 12 Nov 2014 17:04:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 17:04:25 +0000
Message-ID: <1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, zhigang.x.wang@oracle.com,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial configuration
	in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Unconditionally print out the partial configuration.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..396e06c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3388,7 +3388,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
 {
     libxl_domain_config d_config;
 
-    int i, rc;
+    int i;
 
     yajl_gen hand = NULL;
     yajl_gen_status s;
@@ -3410,9 +3410,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
 
     for (i = 0; i < nb_domain; i++) {
         libxl_domain_config_init(&d_config);
-        rc = libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
-        if (rc)
-            continue;
+        libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
         if (default_output_format == OUTPUT_FORMAT_JSON)
             s = printf_info_one_json(hand, info[i].domid, &d_config);
         else
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:40:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobuG-0007JF-MF; Wed, 12 Nov 2014 17:40:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XobuF-0007J3-4k
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:40:35 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	23/04-09936-29B93645; Wed, 12 Nov 2014 17:40:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415814030!12281818!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18800 invoked from network); 12 Nov 2014 17:40:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:40:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="190598517"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:13:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XobLF-0001wk-OV;
	Wed, 12 Nov 2014 17:04:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 17:04:24 +0000
Message-ID: <1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, zhigang.x.wang@oracle.com,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
	ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Continue when libxl_retrieve_domain_configuration encounters
ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
configuration pulled from xenstore.  In this case
ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
error happens along the way.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..f54e0ea 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -6521,6 +6521,7 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
     GC_INIT(ctx);
     int rc;
     libxl__domain_userdata_lock *lock = NULL;
+    bool json_empty = false;
 
     CTX_LOCK;
 
@@ -6531,11 +6532,12 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
     }
 
     rc = libxl__get_domain_configuration(gc, domid, d_config);
-    if (rc) {
+    if (rc && rc != ERROR_JSON_CONFIG_EMPTY) {
         LOG(ERROR, "fail to get domain configuration for domain %d", domid);
         rc = ERROR_FAIL;
         goto out;
     }
+    if (rc == ERROR_JSON_CONFIG_EMPTY) json_empty = true;
 
     /* Domain name */
     {
@@ -6692,6 +6694,8 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
 
 #undef MERGE
 
+    rc = json_empty ? ERROR_JSON_CONFIG_EMPTY : 0;
+
 out:
     if (lock) libxl__unlock_domain_userdata(lock);
     CTX_UNLOCK;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:40:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobuG-0007J8-0L; Wed, 12 Nov 2014 17:40:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XobuE-0007Iy-D3
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:40:34 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3D/F3-09936-19B93645; Wed, 12 Nov 2014 17:40:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415814030!12281818!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18756 invoked from network); 12 Nov 2014 17:40:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:40:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="190598516"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:13:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XobLF-0001wk-PE;
	Wed, 12 Nov 2014 17:04:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 17:04:25 +0000
Message-ID: <1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, zhigang.x.wang@oracle.com,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial configuration
	in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Unconditionally print out the partial configuration.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..396e06c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3388,7 +3388,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
 {
     libxl_domain_config d_config;
 
-    int i, rc;
+    int i;
 
     yajl_gen hand = NULL;
     yajl_gen_status s;
@@ -3410,9 +3410,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
 
     for (i = 0; i < nb_domain; i++) {
         libxl_domain_config_init(&d_config);
-        rc = libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
-        if (rc)
-            continue;
+        libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
         if (default_output_format == OUTPUT_FORMAT_JSON)
             s = printf_info_one_json(hand, info[i].domid, &d_config);
         else
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:40:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XobuG-0007JF-MF; Wed, 12 Nov 2014 17:40:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XobuF-0007J3-4k
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:40:35 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	23/04-09936-29B93645; Wed, 12 Nov 2014 17:40:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415814030!12281818!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18800 invoked from network); 12 Nov 2014 17:40:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:40:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="190598517"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:13:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XobLF-0001wk-OV;
	Wed, 12 Nov 2014 17:04:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 17:04:24 +0000
Message-ID: <1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, zhigang.x.wang@oracle.com,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
	ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Continue when libxl_retrieve_domain_configuration encounters
ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
configuration pulled from xenstore.  In this case
ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
error happens along the way.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..f54e0ea 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -6521,6 +6521,7 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
     GC_INIT(ctx);
     int rc;
     libxl__domain_userdata_lock *lock = NULL;
+    bool json_empty = false;
 
     CTX_LOCK;
 
@@ -6531,11 +6532,12 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
     }
 
     rc = libxl__get_domain_configuration(gc, domid, d_config);
-    if (rc) {
+    if (rc && rc != ERROR_JSON_CONFIG_EMPTY) {
         LOG(ERROR, "fail to get domain configuration for domain %d", domid);
         rc = ERROR_FAIL;
         goto out;
     }
+    if (rc == ERROR_JSON_CONFIG_EMPTY) json_empty = true;
 
     /* Domain name */
     {
@@ -6692,6 +6694,8 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
 
 #undef MERGE
 
+    rc = json_empty ? ERROR_JSON_CONFIG_EMPTY : 0;
+
 out:
     if (lock) libxl__unlock_domain_userdata(lock);
     CTX_UNLOCK;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:55:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17: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.xen.org>)
	id 1Xoc8M-0007vU-CS; Wed, 12 Nov 2014 17:55:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xoc8K-0007vP-RY
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:55:09 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	2A/96-26858-CFE93645; Wed, 12 Nov 2014 17:55:08 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415814904!10953414!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21902 invoked from network); 12 Nov 2014 17:55:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:55:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="190604622"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:31:39 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xoblb-000326-44;
	Wed, 12 Nov 2014 17:31:39 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 17:31:33 +0000
Message-ID: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for 4.5] xl: Return proper error codes for
	block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Return proper error codes on failure so that scripts can tell whether
the command completed properly or not.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Konrad Wilk <konrad.wilk@oracle.com>

Release justification: This is a bug fix.  It's a fairly minor one,
but it's also a very simple one.
---
 tools/libxl/xl_cmdimpl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..b2abe4f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -6383,6 +6383,7 @@ int main_blockattach(int argc, char **argv)
 
     if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
+        return 1;
     }
     return 0;
 }
@@ -6444,6 +6445,7 @@ int main_blockdetach(int argc, char **argv)
     rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
     if (rc) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
+        return 1;
     }
     libxl_device_disk_dispose(&disk);
     return rc;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:55:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17: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.xen.org>)
	id 1Xoc8M-0007vU-CS; Wed, 12 Nov 2014 17:55:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xoc8K-0007vP-RY
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:55:09 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	2A/96-26858-CFE93645; Wed, 12 Nov 2014 17:55:08 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415814904!10953414!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21902 invoked from network); 12 Nov 2014 17:55:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:55:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="190604622"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:31:39 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xoblb-000326-44;
	Wed, 12 Nov 2014 17:31:39 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 12 Nov 2014 17:31:33 +0000
Message-ID: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for 4.5] xl: Return proper error codes for
	block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Return proper error codes on failure so that scripts can tell whether
the command completed properly or not.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Konrad Wilk <konrad.wilk@oracle.com>

Release justification: This is a bug fix.  It's a fairly minor one,
but it's also a very simple one.
---
 tools/libxl/xl_cmdimpl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..b2abe4f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -6383,6 +6383,7 @@ int main_blockattach(int argc, char **argv)
 
     if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
+        return 1;
     }
     return 0;
 }
@@ -6444,6 +6445,7 @@ int main_blockdetach(int argc, char **argv)
     rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
     if (rc) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
+        return 1;
     }
     libxl_device_disk_dispose(&disk);
     return rc;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:57:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XocAX-00080w-Ty; Wed, 12 Nov 2014 17:57:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XocAW-00080n-AV
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:57:24 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	26/73-29352-38F93645; Wed, 12 Nov 2014 17:57:23 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415815039!10928892!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15201 invoked from network); 12 Nov 2014 17:57:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:57:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="190605838"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:35:39 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XobpT-00035l-Hx;
	Wed, 12 Nov 2014 17:35:39 +0000
Date: Wed, 12 Nov 2014 17:35:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141112173539.GC4309@zion.uk.xensource.com>
References: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] xl: Return proper error codes for
 block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 05:31:33PM +0000, George Dunlap wrote:
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
> CC: Ian Campbell <ian.campbell@citrix.com>
> CC: Ian Jackson <ian.jackson@citrix.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>

> CC: Konrad Wilk <konrad.wilk@oracle.com>
> 
> Release justification: This is a bug fix.  It's a fairly minor one,
> but it's also a very simple one.
> ---
>  tools/libxl/xl_cmdimpl.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3c9f146..b2abe4f 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -6383,6 +6383,7 @@ int main_blockattach(int argc, char **argv)
>  
>      if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
>          fprintf(stderr, "libxl_device_disk_add failed.\n");
> +        return 1;
>      }
>      return 0;
>  }
> @@ -6444,6 +6445,7 @@ int main_blockdetach(int argc, char **argv)
>      rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
>      if (rc) {
>          fprintf(stderr, "libxl_device_disk_remove failed.\n");
> +        return 1;
>      }
>      libxl_device_disk_dispose(&disk);
>      return rc;
> -- 
> 1.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 17:57:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 17:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XocAX-00080w-Ty; Wed, 12 Nov 2014 17:57:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XocAW-00080n-AV
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 17:57:24 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	26/73-29352-38F93645; Wed, 12 Nov 2014 17:57:23 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415815039!10928892!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15201 invoked from network); 12 Nov 2014 17:57:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 17:57:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="190605838"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:35:39 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XobpT-00035l-Hx;
	Wed, 12 Nov 2014 17:35:39 +0000
Date: Wed, 12 Nov 2014 17:35:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141112173539.GC4309@zion.uk.xensource.com>
References: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] xl: Return proper error codes for
 block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 05:31:33PM +0000, George Dunlap wrote:
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
> CC: Ian Campbell <ian.campbell@citrix.com>
> CC: Ian Jackson <ian.jackson@citrix.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>

> CC: Konrad Wilk <konrad.wilk@oracle.com>
> 
> Release justification: This is a bug fix.  It's a fairly minor one,
> but it's also a very simple one.
> ---
>  tools/libxl/xl_cmdimpl.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3c9f146..b2abe4f 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -6383,6 +6383,7 @@ int main_blockattach(int argc, char **argv)
>  
>      if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
>          fprintf(stderr, "libxl_device_disk_add failed.\n");
> +        return 1;
>      }
>      return 0;
>  }
> @@ -6444,6 +6445,7 @@ int main_blockdetach(int argc, char **argv)
>      rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
>      if (rc) {
>          fprintf(stderr, "libxl_device_disk_remove failed.\n");
> +        return 1;
>      }
>      libxl_device_disk_dispose(&disk);
>      return rc;
> -- 
> 1.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 18:01:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 18:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XocET-0008G4-K3; Wed, 12 Nov 2014 18:01: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@citrix.com>) id 1XocES-0008Fz-AU
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 18:01:28 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	32/6A-26652-770A3645; Wed, 12 Nov 2014 18:01:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415815283!10940843!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10426 invoked from network); 12 Nov 2014 18:01:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 18:01:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="190608459"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:41:55 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XobvX-0003LG-EZ;
	Wed, 12 Nov 2014 17:41:55 +0000
Date: Wed, 12 Nov 2014 17:41:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
Message-ID: <alpine.DEB.2.02.1411121629320.26318@kaball.uk.xensource.com>
References: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1411450632-1415812179=:26318"
Content-ID: <alpine.DEB.2.02.1411121714590.26318@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1411450632-1415812179=:26318
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1411121714591.26318@kaball.uk.xensource.com>

On Wed, 12 Nov 2014, Roger Pau Monne wrote:
> This patch fixes two issues with persistent grants and the disk PV backen=
d
> (Qdisk):
>=20
>  - Don't use batch mappings when using persistent grants, doing so preven=
ts
>    unmapping single grants (the whole area has to be unmapped at once).

The real issue is that destroy_grant cannot work with batch_maps.
One could reimplement destroy_grant to build a single array with all the
grants to unmap and make a single xc_gnttab_munmap call.

Do you think that would be feasible?

Performance wise, it would certainly be better.


>  - Unmap persistent grants before switching to the closed state, so the
>    frontend can also free them.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> Reported-and-Tested-by: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Kevin Wolf <kwolf@redhat.com>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  hw/block/xen_disk.c | 35 ++++++++++++++++++++++++-----------
>  1 file changed, 24 insertions(+), 11 deletions(-)
>=20
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 231e9a7..1300c0a 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -43,8 +43,6 @@
> =20
>  /* ------------------------------------------------------------- */
> =20
> -static int batch_maps   =3D 0;
> -
>  static int max_requests =3D 32;
> =20
>  /* ------------------------------------------------------------- */
> @@ -105,6 +103,7 @@ struct XenBlkDev {
>      blkif_back_rings_t  rings;
>      int                 more_work;
>      int                 cnt_map;
> +    bool                batch_maps;
> =20
>      /* request lists */
>      QLIST_HEAD(inflight_head, ioreq) inflight;
> @@ -309,7 +308,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
>      if (ioreq->num_unmap =3D=3D 0 || ioreq->mapped =3D=3D 0) {
>          return;
>      }
> -    if (batch_maps) {
> +    if (ioreq->blkdev->batch_maps) {
>          if (!ioreq->pages) {
>              return;
>          }
> @@ -386,7 +385,7 @@ static int ioreq_map(struct ioreq *ioreq)
>          new_maps =3D ioreq->v.niov;
>      }
> =20
> -    if (batch_maps && new_maps) {
> +    if (ioreq->blkdev->batch_maps && new_maps) {
>          ioreq->pages =3D xc_gnttab_map_grant_refs
>              (gnt, new_maps, domids, refs, ioreq->prot);
>          if (ioreq->pages =3D=3D NULL) {
> @@ -433,7 +432,7 @@ static int ioreq_map(struct ioreq *ioreq)
>               */
>              grant =3D g_malloc0(sizeof(*grant));
>              new_maps--;
> -            if (batch_maps) {
> +            if (ioreq->blkdev->batch_maps) {
>                  grant->page =3D ioreq->pages + (new_maps) * XC_PAGE_SIZE=
;
>              } else {
>                  grant->page =3D ioreq->page[new_maps];
> @@ -718,7 +717,9 @@ static void blk_alloc(struct XenDevice *xendev)
>      QLIST_INIT(&blkdev->freelist);
>      blkdev->bh =3D qemu_bh_new(blk_bh, blkdev);
>      if (xen_mode !=3D XEN_EMULATE) {
> -        batch_maps =3D 1;
> +        blkdev->batch_maps =3D TRUE;
> +    } else {
> +        blkdev->batch_maps =3D FALSE;
>      }

true and false, lower capitals


>      if (xc_gnttab_set_max_grants(xendev->gnttabdev,
>              MAX_GRANTS(max_requests, BLKIF_MAX_SEGMENTS_PER_REQUEST)) < =
0) {
> @@ -923,6 +924,13 @@ static int blk_connect(struct XenDevice *xendev)
>      } else {
>          blkdev->feature_persistent =3D !!pers;
>      }
> +    if (blkdev->feature_persistent) {
> +        /*
> +         * Disable batch maps, since that would prevent unmapping
> +         * single persistent grants.
> +         */
> +        blkdev->batch_maps =3D FALSE;

false


> +    }
>
>      blkdev->protocol =3D BLKIF_PROTOCOL_NATIVE;
>      if (blkdev->xendev.protocol) {
> @@ -1000,6 +1008,16 @@ static void blk_disconnect(struct XenDevice *xende=
v)
>          blkdev->cnt_map--;
>          blkdev->sring =3D NULL;
>      }
> +
> +    /*
> +     * Unmap persistent grants before switching to the closed state
> +     * so the frontend can free them.
> +     */
> +    if (blkdev->feature_persistent) {
> +        g_tree_destroy(blkdev->persistent_gnts);
> +        assert(blkdev->persistent_gnt_count =3D=3D 0);
> +        blkdev->feature_persistent =3D FALSE;
> +    }
>  }
> =20
>  static int blk_free(struct XenDevice *xendev)
> @@ -1011,11 +1029,6 @@ static int blk_free(struct XenDevice *xendev)
>          blk_disconnect(xendev);
>      }
> =20
> -    /* Free persistent grants */
> -    if (blkdev->feature_persistent) {
> -        g_tree_destroy(blkdev->persistent_gnts);
> -    }
> -
>      while (!QLIST_EMPTY(&blkdev->freelist)) {
>          ioreq =3D QLIST_FIRST(&blkdev->freelist);
>          QLIST_REMOVE(ioreq, list);
--1342847746-1411450632-1415812179=:26318
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1411450632-1415812179=:26318--


From xen-devel-bounces@lists.xen.org Wed Nov 12 18:01:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 18:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XocET-0008G4-K3; Wed, 12 Nov 2014 18:01: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@citrix.com>) id 1XocES-0008Fz-AU
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 18:01:28 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	32/6A-26652-770A3645; Wed, 12 Nov 2014 18:01:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415815283!10940843!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10426 invoked from network); 12 Nov 2014 18:01:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 18:01:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="190608459"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 12:41:55 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XobvX-0003LG-EZ;
	Wed, 12 Nov 2014 17:41:55 +0000
Date: Wed, 12 Nov 2014 17:41:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
Message-ID: <alpine.DEB.2.02.1411121629320.26318@kaball.uk.xensource.com>
References: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1411450632-1415812179=:26318"
Content-ID: <alpine.DEB.2.02.1411121714590.26318@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1411450632-1415812179=:26318
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1411121714591.26318@kaball.uk.xensource.com>

On Wed, 12 Nov 2014, Roger Pau Monne wrote:
> This patch fixes two issues with persistent grants and the disk PV backen=
d
> (Qdisk):
>=20
>  - Don't use batch mappings when using persistent grants, doing so preven=
ts
>    unmapping single grants (the whole area has to be unmapped at once).

The real issue is that destroy_grant cannot work with batch_maps.
One could reimplement destroy_grant to build a single array with all the
grants to unmap and make a single xc_gnttab_munmap call.

Do you think that would be feasible?

Performance wise, it would certainly be better.


>  - Unmap persistent grants before switching to the closed state, so the
>    frontend can also free them.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> Reported-and-Tested-by: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Kevin Wolf <kwolf@redhat.com>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  hw/block/xen_disk.c | 35 ++++++++++++++++++++++++-----------
>  1 file changed, 24 insertions(+), 11 deletions(-)
>=20
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 231e9a7..1300c0a 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -43,8 +43,6 @@
> =20
>  /* ------------------------------------------------------------- */
> =20
> -static int batch_maps   =3D 0;
> -
>  static int max_requests =3D 32;
> =20
>  /* ------------------------------------------------------------- */
> @@ -105,6 +103,7 @@ struct XenBlkDev {
>      blkif_back_rings_t  rings;
>      int                 more_work;
>      int                 cnt_map;
> +    bool                batch_maps;
> =20
>      /* request lists */
>      QLIST_HEAD(inflight_head, ioreq) inflight;
> @@ -309,7 +308,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
>      if (ioreq->num_unmap =3D=3D 0 || ioreq->mapped =3D=3D 0) {
>          return;
>      }
> -    if (batch_maps) {
> +    if (ioreq->blkdev->batch_maps) {
>          if (!ioreq->pages) {
>              return;
>          }
> @@ -386,7 +385,7 @@ static int ioreq_map(struct ioreq *ioreq)
>          new_maps =3D ioreq->v.niov;
>      }
> =20
> -    if (batch_maps && new_maps) {
> +    if (ioreq->blkdev->batch_maps && new_maps) {
>          ioreq->pages =3D xc_gnttab_map_grant_refs
>              (gnt, new_maps, domids, refs, ioreq->prot);
>          if (ioreq->pages =3D=3D NULL) {
> @@ -433,7 +432,7 @@ static int ioreq_map(struct ioreq *ioreq)
>               */
>              grant =3D g_malloc0(sizeof(*grant));
>              new_maps--;
> -            if (batch_maps) {
> +            if (ioreq->blkdev->batch_maps) {
>                  grant->page =3D ioreq->pages + (new_maps) * XC_PAGE_SIZE=
;
>              } else {
>                  grant->page =3D ioreq->page[new_maps];
> @@ -718,7 +717,9 @@ static void blk_alloc(struct XenDevice *xendev)
>      QLIST_INIT(&blkdev->freelist);
>      blkdev->bh =3D qemu_bh_new(blk_bh, blkdev);
>      if (xen_mode !=3D XEN_EMULATE) {
> -        batch_maps =3D 1;
> +        blkdev->batch_maps =3D TRUE;
> +    } else {
> +        blkdev->batch_maps =3D FALSE;
>      }

true and false, lower capitals


>      if (xc_gnttab_set_max_grants(xendev->gnttabdev,
>              MAX_GRANTS(max_requests, BLKIF_MAX_SEGMENTS_PER_REQUEST)) < =
0) {
> @@ -923,6 +924,13 @@ static int blk_connect(struct XenDevice *xendev)
>      } else {
>          blkdev->feature_persistent =3D !!pers;
>      }
> +    if (blkdev->feature_persistent) {
> +        /*
> +         * Disable batch maps, since that would prevent unmapping
> +         * single persistent grants.
> +         */
> +        blkdev->batch_maps =3D FALSE;

false


> +    }
>
>      blkdev->protocol =3D BLKIF_PROTOCOL_NATIVE;
>      if (blkdev->xendev.protocol) {
> @@ -1000,6 +1008,16 @@ static void blk_disconnect(struct XenDevice *xende=
v)
>          blkdev->cnt_map--;
>          blkdev->sring =3D NULL;
>      }
> +
> +    /*
> +     * Unmap persistent grants before switching to the closed state
> +     * so the frontend can free them.
> +     */
> +    if (blkdev->feature_persistent) {
> +        g_tree_destroy(blkdev->persistent_gnts);
> +        assert(blkdev->persistent_gnt_count =3D=3D 0);
> +        blkdev->feature_persistent =3D FALSE;
> +    }
>  }
> =20
>  static int blk_free(struct XenDevice *xendev)
> @@ -1011,11 +1029,6 @@ static int blk_free(struct XenDevice *xendev)
>          blk_disconnect(xendev);
>      }
> =20
> -    /* Free persistent grants */
> -    if (blkdev->feature_persistent) {
> -        g_tree_destroy(blkdev->persistent_gnts);
> -    }
> -
>      while (!QLIST_EMPTY(&blkdev->freelist)) {
>          ioreq =3D QLIST_FIRST(&blkdev->freelist);
>          QLIST_REMOVE(ioreq, list);
--1342847746-1411450632-1415812179=:26318
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1411450632-1415812179=:26318--


From xen-devel-bounces@lists.xen.org Wed Nov 12 18:09:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 18:09:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XocLr-00006m-Hl; Wed, 12 Nov 2014 18:09:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XocLq-00006h-0A
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 18:09:06 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	69/BE-05632-142A3645; Wed, 12 Nov 2014 18:09:05 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415815744!10821173!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1847 invoked from network); 12 Nov 2014 18:09:04 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 18:09:04 -0000
Received: by mail-wg0-f47.google.com with SMTP id a1so14918334wgh.34
	for <xen-devel@lists.xenproject.org>;
	Wed, 12 Nov 2014 10:09:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=zc/Cj6xTDtxs4CJqE5m5ojQl15wxnX+K4zAv81a6+k8=;
	b=lnSKbE0aGPw7bPHWM6SQNX6ZruYYqr2ZncEvF+6VvsJIv4ejigzUnLivcqDL9Yju8q
	D1cxMVuOJAT20bQ/MUR6BwnIbb6nIj+E3bwBto5vF/UGk6PpVEd8LZBkxVrD+A1Xx6fu
	ZKshTptwdEY8wNTXVZFLkstsVZe2IRIgueBuAfFWSAycYThliwRZAD4kzi7K4LtqVl7S
	R4wgQtPR4EPL5cEOU182gCLAAdpGBGsRm2oW3ISXJHvJrO+bJjX2eDPQFqj2CEx3s7b/
	msSs3zxLYBBckf1OFSN8Xy3BdJdMT9ggRSBrJm+7rK4jAriAt43jhnmghw1TeFzloGFZ
	zqog==
MIME-Version: 1.0
X-Received: by 10.194.248.162 with SMTP id yn2mr66158435wjc.16.1415815743966; 
	Wed, 12 Nov 2014 10:09:03 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Wed, 12 Nov 2014 10:09:03 -0800 (PST)
In-Reply-To: <21600.64887.416522.656249@chiark.greenend.org.uk>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
Date: Wed, 12 Nov 2014 18:09:03 +0000
X-Google-Sender-Auth: ZDPvgez7RJb-ALWAnHvnT8i6eFU
Message-ID: <CAFLBxZZnhUVqunXKxDP_oP53+hc0bXUEUS+kD=RRjFzYOXXk4A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Lars Kurth <lars.kurth.xen@gmail.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Having gone through the thread, I've prepared a three-part new
> proposal email.
>
> I. Deployment with Security Team Permission
> II. Predisclosure list memembership
> III. Information sharing
> IV. Fixes which seem to have rough consensus as they were
>
> Perhaps I should be checking the current web page out as a git tree
> and preparing a patch series ?
>
> Thanks,
> Ian.
>
>
> I. Deployment with Security Team Permission
> ===========================================
>
> Permitting deployment during embargo seemed to have rough consensus on
> the principle.  We seemed to be converging on the idea that the
> Security Team should explicitly set deployment restrictions for each
> set of patches.  So I suggest something like this:
>
>   List members may deploy fixed versions during the embargo, only with
>   permission from the Security Team.  The Security Team will normally
>   permit such deployment, even for systems where VMs are managed or
>   used by non-members of the predisclosure risk.  Permission for
>   deployment, and any restrictions, will be stated in the embargoed
>   advisory text.
>
>   The Security Team will impose deployment restrictions only insofar
>   as it is necessary to prevent the exposure of technicalities (for
>   example, differences in behaviour) which present a significant risk
>   of rediscovery of the vulnerability.  Such situations are expected
>   to be rare.

+1

> II. Predisclosure list memembership
> ===================================
>
> The idea of objective criteria seemed to find favour, and the general
> scheme I proposed.
>
> Lars suggested we should "test" this.  I think therefore that we
> should invite a participants in this thread to write up and post
> applications which we can then test against the proposed policy.  But
> we should probably wait until we have rough consensus on the new
> policy shape.
>
> I have dropped the section about bad websites.  I don't think its lack
> will make much difference to the way applications are processed in
> practice, and I still think documenting the issue would be useful, but
> it's clear that I'm not going to get consensus for it.
>
> Changes that I have made are:
>  - Applications to be made, and decisions sent, to a public mailing list
>  - Explicitly say that the Security Team decide and that they have no
>    discretion
>  - Explicitly say that there is appeal to the project governance process
>    (Lars: perhaps this should say something different or more specific?)
>
>
> So as I said before, applicants should be required to:
>
>   - Provide information on their public web pages which makes
>     it clear that and why they are eligible;
>
>   - Specifically, publicly state that and how they are using Xen
>     (so that the Security Team can verify eligibility);
>
>   - Provide a way for members of the public to responsibly report
>     security problems to the applicant, just as the Xen Project does.
>
> The Security Team should be forbidden from trying to hunt down
> eligibility information etc. and should instead be mandated to reject
> incomplete requests.
>
> Specifically, I propose that the section on list membership
> applications be entirely replaced with this:
>
>   Organisations who meet the criteria should contact
>   predisclosure-applications@xenproject if they wish to receive
>   pre-disclosure of advisories.  That is a public mailing list.
>
>   You must include in the e-mail:
>
>     * The name of your organization.
>
>     * Domain name(s) which you use to provide Xen software/services.
>
>     * A brief description of why you fit the criteria.
>
>     * If not all of your products/services use Xen, a list of (some
>       of) your products/services (or categories thereof) which do.
>
>     * Link(s) to current public web pages, belonging to your
>       organisation, for each of following pieces of information:
>
>       o Evidence of your status as a service/software provider:
>         + If you are a public hosting provider, your public rates
>           or how to get a quote
>         + If you are a software provider, how your
>           software can be downloaded or purchased
>         + If you are an open-source project, a mailing list
>           archive and/or version control repository, with
>           active development
>
>       o Evidence of your status as a user of Xen:
>         + Statements about, or descriptions of, your eligible
>           production services or released software, from which it is
>           immediately evident that they use Xen.
>
>       o Information about your handling of security problems:
>         + Your invitation to members of the public, who discover
>           security problems with your products/services, to report
>           them in confidence to you;
>         + Specifically, the contact information (email addresses or
>           other contact instructions) which such a member of the
>           public should use.
>
>       Blog postings, conference presentations, social media pages,
>       Flash presentations, videos, sites which require registration,
>       anything password-protected, etc., are not acceptable.  PDFs of
>       reasonable size are acceptable so long as the URL you provide is
>       of a ordinary HTML page providing a link to the PDF.
>
>       If the pages are long and/or PDFs are involved, your email
>       should say which part of the pages and documents are relevant.
>
>     * A statement to the effect that you have read this policy and
>       agree to abide by the terms for inclusion in the list,
>       specifically the requirements regarding confidentiality during
>       an embargo period.
>
>     * The single (non-personal) email alias you wish added to the
>       predisclosure list.
>
>   Your application will be determined by the Xen Project Security
>   Team, and their decision posted to the list.  The Security Team has
>   no discretion to accept applications which do not provide all of the
>   information required above.
>
>   If you are dissatisfied with the Security Team's decision you may
>   appeal it via the Xen Project's governance processes.

+1

> III. Information-sharing
> ========================
>
> Permitting sharing of embargoed fixes amongst predisclosure list
> seemed to have rough consensus in principle.  There was some
> discussion about the details.  I remain convinced that my previous
> proposal is correct and I think we should be able to get consensus for
> it.
>
> So I reproduce it (unchanged from my previous proposed wording):
>
>   List members are allowed to share fixes to embargoed issues,
>   analysis, etc., with the security teams of other list members.
>   Technical measures must be taken to prevents non-list-member

"to prevents" => either "which prevents" or "to prevent"

I take it in general the technical measures you envision is pgp / gpg?

>   organisations, or unauthorised staff in list-member organisations,
>   from obtaining the embargoed materials.
>
>   The Xen Project provides the mailing list
>      xen-security-issues-discuss@lists.xenproject.org
>   for this purpose.  List members are encouraged to use it but
>   may share with other list members' security teams via other
>   channels.
>
>   The -discuss list's distribution is identical to that of the primary
>   predisclosure list xen-security-issues.  Recipient organisations who
>   do not wish to receive all of the traffic on -discuss should use
>   recipient-side email filtering based on the provided `List-Id'.
>
>   The -discuss list is moderated by the Xen Project Security Team.
>   Announcements of private availability of fixed versions, and
>   technical messages about embargoed advisories, will be approved.
>   Messages dealing with policy matters will be rejected with a
>   reference to the Security Team contact address and/or public Xen
>   mailing lists.
>
>
> IV. Fixes which seem to have rough consensus as they were
> =========================================================
>
> (Reproduced unchanged from my previous proposed wording:)
>
> The Security Team should not be invited to give permission
> specifically for the release of patched software.  I think the rider
> was mistakenly merged into the final the bullet point in the list.  It
> should be separated out.  Also, the predisclosure list members should
> not be invited to consult the discoverer.
>
> The note about CVE numbers should be moved into the list of
> forbidden-disclosures, as a new bullet point.  So overall I would
> delete that whole paragraph about CVEs (we don't need the historical
> information) and adjust the end of the forbidden disclosures to read:
>
>     ...
>     * patched software (even in binary form)
>     * CVE number(s)
>
>   without prior consultation with security@xenproject.

+1

>
>
>> Service announcements to non-list-member users during embargo
>
> We should add just below the list of bullet points of things which may
> be disclosed:
>
>   Where the list member is a service provider who intends to take
>   disruptive action such as rebooting as part of deploying a fix (see
>   above): the list member's communications to its users about the
>   service disruption may mention that the disruption is to correct a
>   security issue, and relate it to the public information about the
>   issue (as listed above).

+1

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 18:09:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 18:09:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XocLr-00006m-Hl; Wed, 12 Nov 2014 18:09:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XocLq-00006h-0A
	for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 18:09:06 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	69/BE-05632-142A3645; Wed, 12 Nov 2014 18:09:05 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415815744!10821173!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1847 invoked from network); 12 Nov 2014 18:09:04 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 18:09:04 -0000
Received: by mail-wg0-f47.google.com with SMTP id a1so14918334wgh.34
	for <xen-devel@lists.xenproject.org>;
	Wed, 12 Nov 2014 10:09:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=zc/Cj6xTDtxs4CJqE5m5ojQl15wxnX+K4zAv81a6+k8=;
	b=lnSKbE0aGPw7bPHWM6SQNX6ZruYYqr2ZncEvF+6VvsJIv4ejigzUnLivcqDL9Yju8q
	D1cxMVuOJAT20bQ/MUR6BwnIbb6nIj+E3bwBto5vF/UGk6PpVEd8LZBkxVrD+A1Xx6fu
	ZKshTptwdEY8wNTXVZFLkstsVZe2IRIgueBuAfFWSAycYThliwRZAD4kzi7K4LtqVl7S
	R4wgQtPR4EPL5cEOU182gCLAAdpGBGsRm2oW3ISXJHvJrO+bJjX2eDPQFqj2CEx3s7b/
	msSs3zxLYBBckf1OFSN8Xy3BdJdMT9ggRSBrJm+7rK4jAriAt43jhnmghw1TeFzloGFZ
	zqog==
MIME-Version: 1.0
X-Received: by 10.194.248.162 with SMTP id yn2mr66158435wjc.16.1415815743966; 
	Wed, 12 Nov 2014 10:09:03 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Wed, 12 Nov 2014 10:09:03 -0800 (PST)
In-Reply-To: <21600.64887.416522.656249@chiark.greenend.org.uk>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
Date: Wed, 12 Nov 2014 18:09:03 +0000
X-Google-Sender-Auth: ZDPvgez7RJb-ALWAnHvnT8i6eFU
Message-ID: <CAFLBxZZnhUVqunXKxDP_oP53+hc0bXUEUS+kD=RRjFzYOXXk4A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Lars Kurth <lars.kurth.xen@gmail.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Having gone through the thread, I've prepared a three-part new
> proposal email.
>
> I. Deployment with Security Team Permission
> II. Predisclosure list memembership
> III. Information sharing
> IV. Fixes which seem to have rough consensus as they were
>
> Perhaps I should be checking the current web page out as a git tree
> and preparing a patch series ?
>
> Thanks,
> Ian.
>
>
> I. Deployment with Security Team Permission
> ===========================================
>
> Permitting deployment during embargo seemed to have rough consensus on
> the principle.  We seemed to be converging on the idea that the
> Security Team should explicitly set deployment restrictions for each
> set of patches.  So I suggest something like this:
>
>   List members may deploy fixed versions during the embargo, only with
>   permission from the Security Team.  The Security Team will normally
>   permit such deployment, even for systems where VMs are managed or
>   used by non-members of the predisclosure risk.  Permission for
>   deployment, and any restrictions, will be stated in the embargoed
>   advisory text.
>
>   The Security Team will impose deployment restrictions only insofar
>   as it is necessary to prevent the exposure of technicalities (for
>   example, differences in behaviour) which present a significant risk
>   of rediscovery of the vulnerability.  Such situations are expected
>   to be rare.

+1

> II. Predisclosure list memembership
> ===================================
>
> The idea of objective criteria seemed to find favour, and the general
> scheme I proposed.
>
> Lars suggested we should "test" this.  I think therefore that we
> should invite a participants in this thread to write up and post
> applications which we can then test against the proposed policy.  But
> we should probably wait until we have rough consensus on the new
> policy shape.
>
> I have dropped the section about bad websites.  I don't think its lack
> will make much difference to the way applications are processed in
> practice, and I still think documenting the issue would be useful, but
> it's clear that I'm not going to get consensus for it.
>
> Changes that I have made are:
>  - Applications to be made, and decisions sent, to a public mailing list
>  - Explicitly say that the Security Team decide and that they have no
>    discretion
>  - Explicitly say that there is appeal to the project governance process
>    (Lars: perhaps this should say something different or more specific?)
>
>
> So as I said before, applicants should be required to:
>
>   - Provide information on their public web pages which makes
>     it clear that and why they are eligible;
>
>   - Specifically, publicly state that and how they are using Xen
>     (so that the Security Team can verify eligibility);
>
>   - Provide a way for members of the public to responsibly report
>     security problems to the applicant, just as the Xen Project does.
>
> The Security Team should be forbidden from trying to hunt down
> eligibility information etc. and should instead be mandated to reject
> incomplete requests.
>
> Specifically, I propose that the section on list membership
> applications be entirely replaced with this:
>
>   Organisations who meet the criteria should contact
>   predisclosure-applications@xenproject if they wish to receive
>   pre-disclosure of advisories.  That is a public mailing list.
>
>   You must include in the e-mail:
>
>     * The name of your organization.
>
>     * Domain name(s) which you use to provide Xen software/services.
>
>     * A brief description of why you fit the criteria.
>
>     * If not all of your products/services use Xen, a list of (some
>       of) your products/services (or categories thereof) which do.
>
>     * Link(s) to current public web pages, belonging to your
>       organisation, for each of following pieces of information:
>
>       o Evidence of your status as a service/software provider:
>         + If you are a public hosting provider, your public rates
>           or how to get a quote
>         + If you are a software provider, how your
>           software can be downloaded or purchased
>         + If you are an open-source project, a mailing list
>           archive and/or version control repository, with
>           active development
>
>       o Evidence of your status as a user of Xen:
>         + Statements about, or descriptions of, your eligible
>           production services or released software, from which it is
>           immediately evident that they use Xen.
>
>       o Information about your handling of security problems:
>         + Your invitation to members of the public, who discover
>           security problems with your products/services, to report
>           them in confidence to you;
>         + Specifically, the contact information (email addresses or
>           other contact instructions) which such a member of the
>           public should use.
>
>       Blog postings, conference presentations, social media pages,
>       Flash presentations, videos, sites which require registration,
>       anything password-protected, etc., are not acceptable.  PDFs of
>       reasonable size are acceptable so long as the URL you provide is
>       of a ordinary HTML page providing a link to the PDF.
>
>       If the pages are long and/or PDFs are involved, your email
>       should say which part of the pages and documents are relevant.
>
>     * A statement to the effect that you have read this policy and
>       agree to abide by the terms for inclusion in the list,
>       specifically the requirements regarding confidentiality during
>       an embargo period.
>
>     * The single (non-personal) email alias you wish added to the
>       predisclosure list.
>
>   Your application will be determined by the Xen Project Security
>   Team, and their decision posted to the list.  The Security Team has
>   no discretion to accept applications which do not provide all of the
>   information required above.
>
>   If you are dissatisfied with the Security Team's decision you may
>   appeal it via the Xen Project's governance processes.

+1

> III. Information-sharing
> ========================
>
> Permitting sharing of embargoed fixes amongst predisclosure list
> seemed to have rough consensus in principle.  There was some
> discussion about the details.  I remain convinced that my previous
> proposal is correct and I think we should be able to get consensus for
> it.
>
> So I reproduce it (unchanged from my previous proposed wording):
>
>   List members are allowed to share fixes to embargoed issues,
>   analysis, etc., with the security teams of other list members.
>   Technical measures must be taken to prevents non-list-member

"to prevents" => either "which prevents" or "to prevent"

I take it in general the technical measures you envision is pgp / gpg?

>   organisations, or unauthorised staff in list-member organisations,
>   from obtaining the embargoed materials.
>
>   The Xen Project provides the mailing list
>      xen-security-issues-discuss@lists.xenproject.org
>   for this purpose.  List members are encouraged to use it but
>   may share with other list members' security teams via other
>   channels.
>
>   The -discuss list's distribution is identical to that of the primary
>   predisclosure list xen-security-issues.  Recipient organisations who
>   do not wish to receive all of the traffic on -discuss should use
>   recipient-side email filtering based on the provided `List-Id'.
>
>   The -discuss list is moderated by the Xen Project Security Team.
>   Announcements of private availability of fixed versions, and
>   technical messages about embargoed advisories, will be approved.
>   Messages dealing with policy matters will be rejected with a
>   reference to the Security Team contact address and/or public Xen
>   mailing lists.
>
>
> IV. Fixes which seem to have rough consensus as they were
> =========================================================
>
> (Reproduced unchanged from my previous proposed wording:)
>
> The Security Team should not be invited to give permission
> specifically for the release of patched software.  I think the rider
> was mistakenly merged into the final the bullet point in the list.  It
> should be separated out.  Also, the predisclosure list members should
> not be invited to consult the discoverer.
>
> The note about CVE numbers should be moved into the list of
> forbidden-disclosures, as a new bullet point.  So overall I would
> delete that whole paragraph about CVEs (we don't need the historical
> information) and adjust the end of the forbidden disclosures to read:
>
>     ...
>     * patched software (even in binary form)
>     * CVE number(s)
>
>   without prior consultation with security@xenproject.

+1

>
>
>> Service announcements to non-list-member users during embargo
>
> We should add just below the list of bullet points of things which may
> be disclosed:
>
>   Where the list member is a service provider who intends to take
>   disruptive action such as rebooting as part of deploying a fix (see
>   above): the list member's communications to its users about the
>   service disruption may mention that the disruption is to correct a
>   security issue, and relate it to the public information about the
>   issue (as listed above).

+1

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 18:47:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 18: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 1Xocwg-0001Dq-Kr; Wed, 12 Nov 2014 18:47:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xocwf-0001Dl-7C
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 18:47:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	80/BD-09842-C2BA3645; Wed, 12 Nov 2014 18:47:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415818026!4979703!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19091 invoked from network); 12 Nov 2014 18:47:07 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 18:47:07 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACIkooX028641
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 18:46:51 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACIkmlU020942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 18:46:49 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACIkmTB004514; Wed, 12 Nov 2014 18:46:48 GMT
Received: from laptop.dumpdata.com (/172.56.22.139)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 10:46:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BA494115B1D; Wed, 12 Nov 2014 13:35:22 -0500 (EST)
Date: Wed, 12 Nov 2014 13:35:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141112183522.GA2709@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-4-git-send-email-jgross@suse.com>
	<5461E50C.4040309@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5461E50C.4040309@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Juergen Gross <jgross@suse.com>, xen-devel@lists.xensource.com,
	x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com,
	hpa@zytor.com, boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 3/8] xen: Delay m2p_override
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 10:29:32AM +0000, David Vrabel wrote:
> On 11/11/14 05:43, Juergen Gross wrote:
> > The m2p overrides are used to be able to find the local pfn for a
> > foreign mfn mapped into the domain. They are used by driver backends
> > having to access frontend data.
> > 
> > As this functionality isn't used in early boot it makes no sense to
> > initialize the m2p override functions very early. It can be done
> > later without doing any harm, removing the need for allocating memory
> > via extend_brk().
> > 
> > While at it make some m2p override functions static as they are only
> > used internally.
> 
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> 
> But...
> 
> >  static struct page *m2p_find_override(unsigned long mfn)
> >  {
> >  	unsigned long flags;
> > -	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
> > +	struct list_head *bucket;
> >  	struct page *p, *ret;
> 
> 
>     if (unlikely(!m2p_overrides))
>         return NULL;
> 
> Would be preferred,

Aye,

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 18:47:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 18: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 1Xocwg-0001Dq-Kr; Wed, 12 Nov 2014 18:47:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xocwf-0001Dl-7C
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 18:47:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	80/BD-09842-C2BA3645; Wed, 12 Nov 2014 18:47:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415818026!4979703!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19091 invoked from network); 12 Nov 2014 18:47:07 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 18:47:07 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACIkooX028641
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 18:46:51 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACIkmlU020942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 18:46:49 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACIkmTB004514; Wed, 12 Nov 2014 18:46:48 GMT
Received: from laptop.dumpdata.com (/172.56.22.139)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 10:46:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BA494115B1D; Wed, 12 Nov 2014 13:35:22 -0500 (EST)
Date: Wed, 12 Nov 2014 13:35:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141112183522.GA2709@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-4-git-send-email-jgross@suse.com>
	<5461E50C.4040309@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5461E50C.4040309@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Juergen Gross <jgross@suse.com>, xen-devel@lists.xensource.com,
	x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com,
	hpa@zytor.com, boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 3/8] xen: Delay m2p_override
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 10:29:32AM +0000, David Vrabel wrote:
> On 11/11/14 05:43, Juergen Gross wrote:
> > The m2p overrides are used to be able to find the local pfn for a
> > foreign mfn mapped into the domain. They are used by driver backends
> > having to access frontend data.
> > 
> > As this functionality isn't used in early boot it makes no sense to
> > initialize the m2p override functions very early. It can be done
> > later without doing any harm, removing the need for allocating memory
> > via extend_brk().
> > 
> > While at it make some m2p override functions static as they are only
> > used internally.
> 
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> 
> But...
> 
> >  static struct page *m2p_find_override(unsigned long mfn)
> >  {
> >  	unsigned long flags;
> > -	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
> > +	struct list_head *bucket;
> >  	struct page *p, *ret;
> 
> 
>     if (unlikely(!m2p_overrides))
>         return NULL;
> 
> Would be preferred,

Aye,

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 18:48:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 18:48:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xocxx-0001Ho-3V; Wed, 12 Nov 2014 18:48:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xocxv-0001He-Ry
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 18:48:28 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	7B/CD-02699-B7BA3645; Wed, 12 Nov 2014 18:48:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415818104!12132444!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15107 invoked from network); 12 Nov 2014 18:48:26 -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;
	12 Nov 2014 18:48:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192084191"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 13:44:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xoctx-0004oL-Fi;
	Wed, 12 Nov 2014 18:44:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xoctx-0007l4-5O;
	Wed, 12 Nov 2014 18:44:21 +0000
Date: Wed, 12 Nov 2014 18:44:21 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31505-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31505: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31505 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31505/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 12 18:48:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 18:48:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xocxx-0001Ho-3V; Wed, 12 Nov 2014 18:48:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xocxv-0001He-Ry
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 18:48:28 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	7B/CD-02699-B7BA3645; Wed, 12 Nov 2014 18:48:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415818104!12132444!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15107 invoked from network); 12 Nov 2014 18:48:26 -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;
	12 Nov 2014 18:48:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192084191"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 13:44:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xoctx-0004oL-Fi;
	Wed, 12 Nov 2014 18:44:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xoctx-0007l4-5O;
	Wed, 12 Nov 2014 18:44:21 +0000
Date: Wed, 12 Nov 2014 18:44:21 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31505-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31505: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31505 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31505/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 12 18:56:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 18: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 1Xod5g-0001eF-2F; Wed, 12 Nov 2014 18:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xod5e-0001eA-0O
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 18:56:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	75/54-09842-95DA3645; Wed, 12 Nov 2014 18:56:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415818583!11939777!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9301 invoked from network); 12 Nov 2014 18:56:24 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 18:56:24 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACIu9aC019699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 18:56:09 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACIu3jJ008502
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 18:56:05 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACIu35N008466; Wed, 12 Nov 2014 18:56:03 GMT
Received: from laptop.dumpdata.com (/172.56.22.139)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 10:56:03 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 94681115BEA; Wed, 12 Nov 2014 13:56:00 -0500 (EST)
Date: Wed, 12 Nov 2014 13:56:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141112185600.GB4898@laptop.dumpdata.com>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
	<20141112152111.GE6017@laptop.dumpdata.com>
	<20141112170657.GA15386@aepfle.de>
	<20141112171659.GA32634@laptop.dumpdata.com>
	<20141112172346.GC17230@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112172346.GC17230@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, 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 for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 06:23:46PM +0100, Olaf Hering wrote:
> On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> 
> > On Wed, Nov 12, 2014 at 06:06:57PM +0100, Olaf Hering wrote:
> > > On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> > > 
> > >  
> > > > What happens if we do not take that in now but delay to Xen 4.6?
> > > 
> > > I will be very unhappy...
> > > I mean, what exactly is the concern here?!
> > 
> > I need to know what the risk is if this does not go in. We
> > are at RC2 and I really want to make the amount of patches
> > that go in be a trickle.
> 
> Its risk free.
> 
> > > > Will systemd still correctly work? It looks like it will and 
> > > > this is just an improvement that makes the code be more streamlined.
> > > > 
> > > > It does not fix a bug (at least that is what I see from
> > > > reading), I believe this should be deferred to Xen 4.6.
> > > 
> > > It does fix a bug. If the whole thing was configured with --prefix=X
> > > --sysconfdir=Y parts of it will still refer to hardcoded paths entirely
> > > unrelated to what was just installed with 'make install'.
> > 
> > How often does that happen? Do the two paths that are specified
> > in the code cover 99% of the use-cases?
> 
> It covers 100% of the use cases. Just today someone complained on
> xen-users that stuff isnt appearing below /usr/local (not sure why, not
> our fault), but even if it was there it wouldnt be used because the code
> hardcodes /etc.

Excellent.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 18:56:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 18: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 1Xod5g-0001eF-2F; Wed, 12 Nov 2014 18:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xod5e-0001eA-0O
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 18:56:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	75/54-09842-95DA3645; Wed, 12 Nov 2014 18:56:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415818583!11939777!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9301 invoked from network); 12 Nov 2014 18:56:24 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 18:56:24 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACIu9aC019699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 18:56:09 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACIu3jJ008502
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 18:56:05 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACIu35N008466; Wed, 12 Nov 2014 18:56:03 GMT
Received: from laptop.dumpdata.com (/172.56.22.139)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 10:56:03 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 94681115BEA; Wed, 12 Nov 2014 13:56:00 -0500 (EST)
Date: Wed, 12 Nov 2014 13:56:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141112185600.GB4898@laptop.dumpdata.com>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
	<20141112152111.GE6017@laptop.dumpdata.com>
	<20141112170657.GA15386@aepfle.de>
	<20141112171659.GA32634@laptop.dumpdata.com>
	<20141112172346.GC17230@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112172346.GC17230@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, 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 for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 06:23:46PM +0100, Olaf Hering wrote:
> On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> 
> > On Wed, Nov 12, 2014 at 06:06:57PM +0100, Olaf Hering wrote:
> > > On Wed, Nov 12, Konrad Rzeszutek Wilk wrote:
> > > 
> > >  
> > > > What happens if we do not take that in now but delay to Xen 4.6?
> > > 
> > > I will be very unhappy...
> > > I mean, what exactly is the concern here?!
> > 
> > I need to know what the risk is if this does not go in. We
> > are at RC2 and I really want to make the amount of patches
> > that go in be a trickle.
> 
> Its risk free.
> 
> > > > Will systemd still correctly work? It looks like it will and 
> > > > this is just an improvement that makes the code be more streamlined.
> > > > 
> > > > It does not fix a bug (at least that is what I see from
> > > > reading), I believe this should be deferred to Xen 4.6.
> > > 
> > > It does fix a bug. If the whole thing was configured with --prefix=X
> > > --sysconfdir=Y parts of it will still refer to hardcoded paths entirely
> > > unrelated to what was just installed with 'make install'.
> > 
> > How often does that happen? Do the two paths that are specified
> > in the code cover 99% of the use-cases?
> 
> It covers 100% of the use cases. Just today someone complained on
> xen-users that stuff isnt appearing below /usr/local (not sure why, not
> our fault), but even if it was there it wouldnt be used because the code
> hardcodes /etc.

Excellent.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 19:54:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 19:54:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xodzb-0002i7-V8; Wed, 12 Nov 2014 19:54:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1Xodzb-0002i1-7I
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 19:54:15 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	1C/91-11608-6EAB3645; Wed, 12 Nov 2014 19:54:14 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415822052!10969995!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22917 invoked from network); 12 Nov 2014 19:54:13 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 19:54:13 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACJs3eT017774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 19:54:04 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACJs1b2009314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 19:54:02 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACJs1gZ009284; Wed, 12 Nov 2014 19:54:01 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 11:54:01 -0800
Message-ID: <5463BAD8.9090407@oracle.com>
Date: Wed, 12 Nov 2014 14:54:00 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: ian.jackson@eu.citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print
 partial config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 12:04 PM, Wei Liu wrote:
> This small series change the behavior of libxl_retrieve_domain_configuration,
> to make it continue to retrieve information from xenstore even if JSON template
> is not available.
> 
> This change of API behaviour is only internal. Conceptually speaking, any
> non-zero return value means d_config is partially filled. The chanage just
> makes it fill in more information (xenstore entries) than before (empty).
> Caller can still expect zero on success and non-zero on error and act
> accordingly.
> 
> "xl list -l" is now changed to print out the partial configuration, since it
> needs to be consistent with the short output.
> 
> Wei.
> 
> Wei Liu (2):
>   libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
>   xl: print out partial configuration in long mode of list command
> 
>  tools/libxl/libxl.c      |    6 +++++-
>  tools/libxl/xl_cmdimpl.c |    6 ++----
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 

It seem some other places may need fix too. Here is the test result:

# xl list -l
libxl: error: libxl.c:4844:libxl__get_memory_target: cannot get target memory info from /local/domain/1/memory/target
: No such file or directory
libxl: error: libxl.c:6582:libxl_retrieve_domain_configuration: fail to get memory target for domain 1
[
    {
        "domid": 0,
        "config": {
            "c_info": {
                "type": "pv",
                "name": "Domain-0"
            },
            "b_info": {
                "max_memkb": 876544,
                "target_memkb": 876543,
                "sched_params": {

                },
                "type.pv": {

                }
            }
        }
    },
    {
        "domid": 1,
        "config": {
            "c_info": {
                "name": "0004fb00000600008b1d33e2704548b7--incoming",
                "uuid": "0004fb00-0006-0000-8b1d-33e2704548b7"
            },
            "b_info": {
                "sched_params": {

                },
                "type.invalid": {

                }
            }
        }
    }
]

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 19:54:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 19:54:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xodzb-0002i7-V8; Wed, 12 Nov 2014 19:54:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1Xodzb-0002i1-7I
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 19:54:15 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	1C/91-11608-6EAB3645; Wed, 12 Nov 2014 19:54:14 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415822052!10969995!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22917 invoked from network); 12 Nov 2014 19:54:13 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 19:54:13 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACJs3eT017774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 19:54:04 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACJs1b2009314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 19:54:02 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACJs1gZ009284; Wed, 12 Nov 2014 19:54:01 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 11:54:01 -0800
Message-ID: <5463BAD8.9090407@oracle.com>
Date: Wed, 12 Nov 2014 14:54:00 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: ian.jackson@eu.citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print
 partial config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 12:04 PM, Wei Liu wrote:
> This small series change the behavior of libxl_retrieve_domain_configuration,
> to make it continue to retrieve information from xenstore even if JSON template
> is not available.
> 
> This change of API behaviour is only internal. Conceptually speaking, any
> non-zero return value means d_config is partially filled. The chanage just
> makes it fill in more information (xenstore entries) than before (empty).
> Caller can still expect zero on success and non-zero on error and act
> accordingly.
> 
> "xl list -l" is now changed to print out the partial configuration, since it
> needs to be consistent with the short output.
> 
> Wei.
> 
> Wei Liu (2):
>   libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
>   xl: print out partial configuration in long mode of list command
> 
>  tools/libxl/libxl.c      |    6 +++++-
>  tools/libxl/xl_cmdimpl.c |    6 ++----
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 

It seem some other places may need fix too. Here is the test result:

# xl list -l
libxl: error: libxl.c:4844:libxl__get_memory_target: cannot get target memory info from /local/domain/1/memory/target
: No such file or directory
libxl: error: libxl.c:6582:libxl_retrieve_domain_configuration: fail to get memory target for domain 1
[
    {
        "domid": 0,
        "config": {
            "c_info": {
                "type": "pv",
                "name": "Domain-0"
            },
            "b_info": {
                "max_memkb": 876544,
                "target_memkb": 876543,
                "sched_params": {

                },
                "type.pv": {

                }
            }
        }
    },
    {
        "domid": 1,
        "config": {
            "c_info": {
                "name": "0004fb00000600008b1d33e2704548b7--incoming",
                "uuid": "0004fb00-0006-0000-8b1d-33e2704548b7"
            },
            "b_info": {
                "sched_params": {

                },
                "type.invalid": {

                }
            }
        }
    }
]

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 20:45:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 20: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 1Xoemh-0003zz-3H; Wed, 12 Nov 2014 20:44:59 +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 1Xoemf-0003zu-I6
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 20:44:57 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	DB/42-19763-8C6C3645; Wed, 12 Nov 2014 20:44:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415825093!10961764!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18980 invoked from network); 12 Nov 2014 20:44:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 20:44:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192131075"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 15:44:50 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoemY-00078P-E3;
	Wed, 12 Nov 2014 20:44:50 +0000
Date: Wed, 12 Nov 2014 20:44:50 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141112204450.GA6716@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<5463BAD8.9090407@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5463BAD8.9090407@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print
 partial config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 02:54:00PM -0500, Zhigang Wang wrote:
> On 11/12/2014 12:04 PM, Wei Liu wrote:
> > This small series change the behavior of libxl_retrieve_domain_configuration,
> > to make it continue to retrieve information from xenstore even if JSON template
> > is not available.
> > 
> > This change of API behaviour is only internal. Conceptually speaking, any
> > non-zero return value means d_config is partially filled. The chanage just
> > makes it fill in more information (xenstore entries) than before (empty).
> > Caller can still expect zero on success and non-zero on error and act
> > accordingly.
> > 
> > "xl list -l" is now changed to print out the partial configuration, since it
> > needs to be consistent with the short output.
> > 
> > Wei.
> > 
> > Wei Liu (2):
> >   libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
> >   xl: print out partial configuration in long mode of list command
> > 
> >  tools/libxl/libxl.c      |    6 +++++-
> >  tools/libxl/xl_cmdimpl.c |    6 ++----
> >  2 files changed, 7 insertions(+), 5 deletions(-)
> > 
> 
> It seem some other places may need fix too. Here is the test result:
> 
> # xl list -l
> libxl: error: libxl.c:4844:libxl__get_memory_target: cannot get target memory info from /local/domain/1/memory/target
> : No such file or directory
> libxl: error: libxl.c:6582:libxl_retrieve_domain_configuration: fail to get memory target for domain 1

Well, there's no such node in xenstore. There's nothing I can do about
it.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 20:45:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 20: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 1Xoemh-0003zz-3H; Wed, 12 Nov 2014 20:44:59 +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 1Xoemf-0003zu-I6
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 20:44:57 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	DB/42-19763-8C6C3645; Wed, 12 Nov 2014 20:44:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415825093!10961764!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18980 invoked from network); 12 Nov 2014 20:44:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 20:44:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="192131075"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 12 Nov 2014 15:44:50 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XoemY-00078P-E3;
	Wed, 12 Nov 2014 20:44:50 +0000
Date: Wed, 12 Nov 2014 20:44:50 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141112204450.GA6716@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<5463BAD8.9090407@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5463BAD8.9090407@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print
 partial config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 02:54:00PM -0500, Zhigang Wang wrote:
> On 11/12/2014 12:04 PM, Wei Liu wrote:
> > This small series change the behavior of libxl_retrieve_domain_configuration,
> > to make it continue to retrieve information from xenstore even if JSON template
> > is not available.
> > 
> > This change of API behaviour is only internal. Conceptually speaking, any
> > non-zero return value means d_config is partially filled. The chanage just
> > makes it fill in more information (xenstore entries) than before (empty).
> > Caller can still expect zero on success and non-zero on error and act
> > accordingly.
> > 
> > "xl list -l" is now changed to print out the partial configuration, since it
> > needs to be consistent with the short output.
> > 
> > Wei.
> > 
> > Wei Liu (2):
> >   libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
> >   xl: print out partial configuration in long mode of list command
> > 
> >  tools/libxl/libxl.c      |    6 +++++-
> >  tools/libxl/xl_cmdimpl.c |    6 ++----
> >  2 files changed, 7 insertions(+), 5 deletions(-)
> > 
> 
> It seem some other places may need fix too. Here is the test result:
> 
> # xl list -l
> libxl: error: libxl.c:4844:libxl__get_memory_target: cannot get target memory info from /local/domain/1/memory/target
> : No such file or directory
> libxl: error: libxl.c:6582:libxl_retrieve_domain_configuration: fail to get memory target for domain 1

Well, there's no such node in xenstore. There's nothing I can do about
it.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 21:45:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 21: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 1XofjJ-0005GC-5L; Wed, 12 Nov 2014 21:45:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XofjH-0005G7-1t
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 21:45:31 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	CA/76-16982-AF4D3645; Wed, 12 Nov 2014 21:45:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415828727!10848351!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29118 invoked from network); 12 Nov 2014 21:45:29 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 21:45:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACLjA8r025197
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 21:45:11 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACLj8T2011491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 21:45:10 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACLj8Cx028987; Wed, 12 Nov 2014 21:45:08 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 13:45:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id F4019115CE6; Wed, 12 Nov 2014 16:45:06 -0500 (EST)
Date: Wed, 12 Nov 2014 16:45:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141112214506.GA5922@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-3-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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, Nov 11, 2014 at 06:43:40AM +0100, Juergen Gross wrote:
> Early in the boot process the memory layout of a pv-domain is changed
> to match the E820 map (either the host one for Dom0 or the Xen one)
> regarding placement of RAM and PCI holes. This requires removing memory
> pages initially located at positions not suitable for RAM and adding
> them later at higher addresses where no restrictions apply.
> 
> To be able to operate on the hypervisor supported p2m list until a
> virtual mapped linear p2m list can be constructed, remapping must
> be delayed until virtual memory management is initialized, as the
> initial p2m list can't be extended unlimited at physical memory
> initialization time due to it's fixed structure.
> 
> A further advantage is the reduction in complexity and code volume as
> we don't have to be careful regarding memory restrictions during p2m
> updates.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/include/asm/xen/page.h |   1 -
>  arch/x86/xen/mmu.c              |   4 +
>  arch/x86/xen/p2m.c              | 149 ++++------------
>  arch/x86/xen/setup.c            | 385 +++++++++++++++++++---------------------
>  arch/x86/xen/xen-ops.h          |   1 +
>  5 files changed, 223 insertions(+), 317 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 6c16451..b475297 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -44,7 +44,6 @@ extern unsigned long  machine_to_phys_nr;
>  
>  extern unsigned long get_phys_to_machine(unsigned long pfn);
>  extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
> -extern bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn);
>  extern bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
>  extern unsigned long set_phys_range_identity(unsigned long pfn_s,
>  					     unsigned long pfn_e);
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index a8a1a3d..d3e492b 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1223,6 +1223,10 @@ static void __init xen_pagetable_init(void)
>  	/* Allocate and initialize top and mid mfn levels for p2m structure */
>  	xen_build_mfn_list_list();
>  
> +	/* Remap memory freed because of conflicts with E820 map */

s/becasue of/due to
> +	if (!xen_feature(XENFEAT_auto_translated_physmap))
> +		xen_remap_memory();
> +
>  	xen_setup_shared_info();
>  	xen_post_allocator_init();
>  }
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index fa75842..f67f8cf 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -164,6 +164,7 @@
>  #include <linux/sched.h>
>  #include <linux/seq_file.h>
>  #include <linux/bootmem.h>
> +#include <linux/slab.h>
>  
>  #include <asm/cache.h>
>  #include <asm/setup.h>
> @@ -204,6 +205,8 @@ RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER
>   */
>  RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
>  
> +static int use_brk = 1;
> +
>  static inline unsigned p2m_top_index(unsigned long pfn)
>  {
>  	BUG_ON(pfn >= MAX_P2M_PFN);
> @@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
>  		p2m[i] = INVALID_P2M_ENTRY;
>  }
>  
> +static void * __ref alloc_p2m_page(void)
> +{
> +	if (unlikely(use_brk))
> +		return extend_brk(PAGE_SIZE, PAGE_SIZE);
> +
> +	if (unlikely(!slab_is_available()))
> +		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +
> +	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
> +}
> +
> +static void free_p2m_page(void *p)
> +{
> +	free_page((unsigned long)p);
> +}
> +
>  /*
>   * Build the parallel p2m_top_mfn and p2m_mid_mfn structures
>   *
> @@ -287,13 +306,13 @@ void __ref xen_build_mfn_list_list(void)
>  
>  	/* Pre-initialize p2m_top_mfn to be completely missing */
>  	if (p2m_top_mfn == NULL) {
> -		p2m_mid_missing_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +		p2m_mid_missing_mfn = alloc_p2m_page();
>  		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
>  
> -		p2m_top_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +		p2m_top_mfn_p = alloc_p2m_page();
>  		p2m_top_mfn_p_init(p2m_top_mfn_p);
>  
> -		p2m_top_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +		p2m_top_mfn = alloc_p2m_page();
>  		p2m_top_mfn_init(p2m_top_mfn);
>  	} else {
>  		/* Reinitialise, mfn's all change after migration */
> @@ -327,7 +346,7 @@ void __ref xen_build_mfn_list_list(void)
>  			 * missing parts of the mfn tree after
>  			 * runtime.
>  			 */
> -			mid_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +			mid_mfn_p = alloc_p2m_page();
>  			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
>  
>  			p2m_top_mfn_p[topidx] = mid_mfn_p;
> @@ -364,17 +383,17 @@ void __init xen_build_dynamic_phys_to_machine(void)
>  	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
>  	xen_max_p2m_pfn = max_pfn;
>  
> -	p2m_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m_missing = alloc_p2m_page();
>  	p2m_init(p2m_missing);
> -	p2m_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m_identity = alloc_p2m_page();
>  	p2m_init(p2m_identity);
>  
> -	p2m_mid_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m_mid_missing = alloc_p2m_page();
>  	p2m_mid_init(p2m_mid_missing, p2m_missing);
> -	p2m_mid_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m_mid_identity = alloc_p2m_page();
>  	p2m_mid_init(p2m_mid_identity, p2m_identity);
>  
> -	p2m_top = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m_top = alloc_p2m_page();
>  	p2m_top_init(p2m_top);
>  
>  	/*
> @@ -387,7 +406,7 @@ void __init xen_build_dynamic_phys_to_machine(void)
>  		unsigned mididx = p2m_mid_index(pfn);
>  
>  		if (p2m_top[topidx] == p2m_mid_missing) {
> -			unsigned long **mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +			unsigned long **mid = alloc_p2m_page();
>  			p2m_mid_init(mid, p2m_missing);
>  
>  			p2m_top[topidx] = mid;
> @@ -420,6 +439,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>  	unsigned long *mfn_list = NULL;
>  	unsigned long size;
>  
> +	use_brk = 0;
>  	va_start = xen_start_info->mfn_list;
>  	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
>  	 * so make sure it is rounded up to that */
> @@ -484,6 +504,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>  #else
>  unsigned long __init xen_revector_p2m_tree(void)
>  {
> +	use_brk = 0;
>  	return 0;
>  }
>  #endif
> @@ -510,16 +531,6 @@ unsigned long get_phys_to_machine(unsigned long pfn)
>  }
>  EXPORT_SYMBOL_GPL(get_phys_to_machine);
>  
> -static void *alloc_p2m_page(void)
> -{
> -	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
> -}
> -
> -static void free_p2m_page(void *p)
> -{
> -	free_page((unsigned long)p);
> -}
> -
>  /*
>   * Fully allocate the p2m structure for a given pfn.  We need to check
>   * that both the top and mid levels are allocated, and make sure the
> @@ -624,7 +635,7 @@ static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
>  		return false;
>  
>  	/* Boundary cross-over for the edges: */
> -	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m = alloc_p2m_page();
>  
>  	p2m_init(p2m);
>  
> @@ -640,7 +651,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
>  
>  	mid = p2m_top[topidx];
>  	if (mid == p2m_mid_missing) {
> -		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +		mid = alloc_p2m_page();
>  
>  		p2m_mid_init(mid, p2m_missing);
>  
> @@ -649,100 +660,6 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
>  	return true;
>  }
>  

I would split this patch in two - one for the extend_brk/alloc_page conversation
to alloc_p2m_page and free_page to free_p2m_page.

> -/*
> - * Skim over the P2M tree looking at pages that are either filled with
> - * INVALID_P2M_ENTRY or with 1:1 PFNs. If found, re-use that page and
> - * replace the P2M leaf with a p2m_missing or p2m_identity.
> - * Stick the old page in the new P2M tree location.
> - */
> -static bool __init early_can_reuse_p2m_middle(unsigned long set_pfn)
> -{
> -	unsigned topidx;
> -	unsigned mididx;
> -	unsigned ident_pfns;
> -	unsigned inv_pfns;
> -	unsigned long *p2m;
> -	unsigned idx;
> -	unsigned long pfn;
> -
> -	/* We only look when this entails a P2M middle layer */
> -	if (p2m_index(set_pfn))
> -		return false;
> -
> -	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
> -		topidx = p2m_top_index(pfn);
> -
> -		if (!p2m_top[topidx])
> -			continue;
> -
> -		if (p2m_top[topidx] == p2m_mid_missing)
> -			continue;
> -
> -		mididx = p2m_mid_index(pfn);
> -		p2m = p2m_top[topidx][mididx];
> -		if (!p2m)
> -			continue;
> -
> -		if ((p2m == p2m_missing) || (p2m == p2m_identity))
> -			continue;
> -
> -		if ((unsigned long)p2m == INVALID_P2M_ENTRY)
> -			continue;
> -
> -		ident_pfns = 0;
> -		inv_pfns = 0;
> -		for (idx = 0; idx < P2M_PER_PAGE; idx++) {
> -			/* IDENTITY_PFNs are 1:1 */
> -			if (p2m[idx] == IDENTITY_FRAME(pfn + idx))
> -				ident_pfns++;
> -			else if (p2m[idx] == INVALID_P2M_ENTRY)
> -				inv_pfns++;
> -			else
> -				break;
> -		}
> -		if ((ident_pfns == P2M_PER_PAGE) || (inv_pfns == P2M_PER_PAGE))
> -			goto found;
> -	}
> -	return false;
> -found:
> -	/* Found one, replace old with p2m_identity or p2m_missing */
> -	p2m_top[topidx][mididx] = (ident_pfns ? p2m_identity : p2m_missing);
> -
> -	/* Reset where we want to stick the old page in. */
> -	topidx = p2m_top_index(set_pfn);
> -	mididx = p2m_mid_index(set_pfn);
> -
> -	/* This shouldn't happen */
> -	if (WARN_ON(p2m_top[topidx] == p2m_mid_missing))
> -		early_alloc_p2m_middle(set_pfn);
> -
> -	if (WARN_ON(p2m_top[topidx][mididx] != p2m_missing))
> -		return false;
> -
> -	p2m_init(p2m);
> -	p2m_top[topidx][mididx] = p2m;
> -
> -	return true;
> -}
> -bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> -{
> -	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
> -		if (!early_alloc_p2m_middle(pfn))
> -			return false;
> -
> -		if (early_can_reuse_p2m_middle(pfn))
> -			return __set_phys_to_machine(pfn, mfn);
> -
> -		if (!early_alloc_p2m(pfn, false /* boundary crossover OK!*/))
> -			return false;
> -
> -		if (!__set_phys_to_machine(pfn, mfn))
> -			return false;
> -	}
> -
> -	return true;
> -}
> -
>  static void __init early_split_p2m(unsigned long pfn)
>  {
>  	unsigned long mididx, idx;
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 29834b3..0e5f9b6 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -30,6 +30,7 @@
>  #include "xen-ops.h"
>  #include "vdso.h"
>  #include "p2m.h"
> +#include "mmu.h"
>  
>  /* These are code, but not functions.  Defined in entry.S */
>  extern const char xen_hypervisor_callback[];
> @@ -47,8 +48,18 @@ struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
>  /* Number of pages released from the initial allocation. */
>  unsigned long xen_released_pages;
>  
> -/* Buffer used to remap identity mapped pages */
> -unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
> +/*
> + * Buffer used to remap identity mapped pages. We only need the virtual space.

Could you expand on the 'need the virtual space'?


.. snip..
>  /*
>   * This function updates the p2m and m2p tables with an identity map from
> - * start_pfn to start_pfn+size and remaps the underlying RAM of the original
> - * allocation at remap_pfn. It must do so carefully in P2M_PER_PAGE sized blocks
> - * to not exhaust the reserved brk space. Doing it in properly aligned blocks
> - * ensures we only allocate the minimum required leaf pages in the p2m table. It
> - * copies the existing mfns from the p2m table under the 1:1 map, overwrites
> - * them with the identity map and then updates the p2m and m2p tables with the
> - * remapped memory.
> + * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the
> + * original allocation at remap_pfn. The information needed for remapping is
> + * saved in the memory itself to avoid the need for allocating buffers. The
> + * complete remap information is contained in a list of MFNs each containing
> + * up to REMAP_SIZE MFNs and the start target PFN for doing the remap.
> + * This enables to preserve the original mfn sequence while doing the remapping

us to
> + * at a time when the memory management is capable of allocating virtual and
> + * physical memory in arbitrary amounts.

You might want to add, see 'xen_remap_memory' and its callers.

>   */
> -static unsigned long __init xen_do_set_identity_and_remap_chunk(
> +static void __init xen_do_set_identity_and_remap_chunk(
>          unsigned long start_pfn, unsigned long size, unsigned long remap_pfn)
>  {
> +	unsigned long buf = (unsigned long)&xen_remap_buf;
> +	unsigned long mfn_save, mfn;
>  	unsigned long ident_pfn_iter, remap_pfn_iter;
> -	unsigned long ident_start_pfn_align, remap_start_pfn_align;
> -	unsigned long ident_end_pfn_align, remap_end_pfn_align;
> -	unsigned long ident_boundary_pfn, remap_boundary_pfn;
> -	unsigned long ident_cnt = 0;
> -	unsigned long remap_cnt = 0;
> +	unsigned long ident_end_pfn = start_pfn + size;
>  	unsigned long left = size;
> -	unsigned long mod;
> -	int i;
> +	unsigned long ident_cnt = 0;
> +	unsigned int i, chunk;
>  
>  	WARN_ON(size == 0);
>  
>  	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
>  
> -	/*
> -	 * Determine the proper alignment to remap memory in P2M_PER_PAGE sized
> -	 * blocks. We need to keep track of both the existing pfn mapping and
> -	 * the new pfn remapping.
> -	 */
> -	mod = start_pfn % P2M_PER_PAGE;
> -	ident_start_pfn_align =
> -		mod ? (start_pfn - mod + P2M_PER_PAGE) : start_pfn;
> -	mod = remap_pfn % P2M_PER_PAGE;
> -	remap_start_pfn_align =
> -		mod ? (remap_pfn - mod + P2M_PER_PAGE) : remap_pfn;
> -	mod = (start_pfn + size) % P2M_PER_PAGE;
> -	ident_end_pfn_align = start_pfn + size - mod;
> -	mod = (remap_pfn + size) % P2M_PER_PAGE;
> -	remap_end_pfn_align = remap_pfn + size - mod;
> -
> -	/* Iterate over each p2m leaf node in each range */
> -	for (ident_pfn_iter = ident_start_pfn_align, remap_pfn_iter = remap_start_pfn_align;
> -	     ident_pfn_iter < ident_end_pfn_align && remap_pfn_iter < remap_end_pfn_align;
> -	     ident_pfn_iter += P2M_PER_PAGE, remap_pfn_iter += P2M_PER_PAGE) {
> -		/* Check we aren't past the end */
> -		BUG_ON(ident_pfn_iter + P2M_PER_PAGE > start_pfn + size);
> -		BUG_ON(remap_pfn_iter + P2M_PER_PAGE > remap_pfn + size);
> -
> -		/* Save p2m mappings */
> -		for (i = 0; i < P2M_PER_PAGE; i++)
> -			xen_remap_buf[i] = pfn_to_mfn(ident_pfn_iter + i);
> -
> -		/* Set identity map which will free a p2m leaf */
> -		ident_cnt += set_phys_range_identity(ident_pfn_iter,
> -			ident_pfn_iter + P2M_PER_PAGE);
> -
> -#ifdef DEBUG
> -		/* Helps verify a p2m leaf has been freed */
> -		for (i = 0; i < P2M_PER_PAGE; i++) {
> -			unsigned int pfn = ident_pfn_iter + i;
> -			BUG_ON(pfn_to_mfn(pfn) != pfn);
> -		}
> -#endif
> -		/* Now remap memory */
> -		for (i = 0; i < P2M_PER_PAGE; i++) {
> -			unsigned long mfn = xen_remap_buf[i];
> -
> -			/* This will use the p2m leaf freed above */
> -			if (!xen_update_mem_tables(remap_pfn_iter + i, mfn)) {
> -				WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
> -					remap_pfn_iter + i, mfn);
> -				return 0;
> -			}
> -
> -			remap_cnt++;
> -		}
> -
> -		left -= P2M_PER_PAGE;
> -	}
> +	/* Don't use memory until remapped */
> +	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
>  
> -	/* Max boundary space possible */
> -	BUG_ON(left > (P2M_PER_PAGE - 1) * 2);
> +	mfn_save = virt_to_mfn(buf);
>  
> -	/* Now handle the boundary conditions */
> -	ident_boundary_pfn = start_pfn;
> -	remap_boundary_pfn = remap_pfn;
> -	for (i = 0; i < left; i++) {
> -		unsigned long mfn;
> +	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
> +	     ident_pfn_iter < ident_end_pfn;
> +	     ident_pfn_iter += REMAP_SIZE, remap_pfn_iter += REMAP_SIZE) {
> +		chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE;
>  
> -		/* These two checks move from the start to end boundaries */
> -		if (ident_boundary_pfn == ident_start_pfn_align)
> -			ident_boundary_pfn = ident_pfn_iter;
> -		if (remap_boundary_pfn == remap_start_pfn_align)
> -			remap_boundary_pfn = remap_pfn_iter;
> +		/* Map first pfn to xen_remap_buf */
> +		mfn = pfn_to_mfn(ident_pfn_iter);
> +		set_pte_mfn(buf, mfn, PAGE_KERNEL);

So you set the buf to be point to 'mfn'.
>  
> -		/* Check we aren't past the end */
> -		BUG_ON(ident_boundary_pfn >= start_pfn + size);
> -		BUG_ON(remap_boundary_pfn >= remap_pfn + size);
> +		/* Save mapping information in page */
> +		xen_remap_buf.next_area_mfn = xen_remap_mfn;
> +		xen_remap_buf.target_pfn = remap_pfn_iter;
> +		xen_remap_buf.size = chunk;
> +		for (i = 0; i < chunk; i++)
> +			xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i);
>  
> -		mfn = pfn_to_mfn(ident_boundary_pfn);
> +		/* New element first in list */

I don't get that comment. Don't you mean the MFN of the last chunk you
had stashed the 'xen_remap_buf' structure in?

The 'xen_remap_mfn' ends up being the the tail value of this
"list".
> +		xen_remap_mfn = mfn;
>  
> -		if (!xen_update_mem_tables(remap_boundary_pfn, mfn)) {
> -			WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
> -				remap_pfn_iter + i, mfn);
> -			return 0;
> -		}
> -		remap_cnt++;
> -
> -		ident_boundary_pfn++;
> -		remap_boundary_pfn++;
> -	}
> +		/* Set identity map */
> +		ident_cnt += set_phys_range_identity(ident_pfn_iter,
> +			ident_pfn_iter + chunk);
>  
> -	/* Finish up the identity map */
> -	if (ident_start_pfn_align >= ident_end_pfn_align) {
> -		/*
> -                 * In this case we have an identity range which does not span an
> -                 * aligned block so everything needs to be identity mapped here.
> -                 * If we didn't check this we might remap too many pages since
> -                 * the align boundaries are not meaningful in this case.
> -	         */
> -		ident_cnt += set_phys_range_identity(start_pfn,
> -			start_pfn + size);
> -	} else {
> -		/* Remapped above so check each end of the chunk */
> -		if (start_pfn < ident_start_pfn_align)
> -			ident_cnt += set_phys_range_identity(start_pfn,
> -				ident_start_pfn_align);
> -		if (start_pfn + size > ident_pfn_iter)
> -			ident_cnt += set_phys_range_identity(ident_pfn_iter,
> -				start_pfn + size);
> +		left -= chunk;
>  	}
>  
> -	BUG_ON(ident_cnt != size);
> -	BUG_ON(remap_cnt != size);
> -
> -	return size;
> +	/* Restore old xen_remap_buf mapping */
> +	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
>  }
>  
>  /*
> @@ -396,8 +318,7 @@ static unsigned long __init xen_do_set_identity_and_remap_chunk(
>  static unsigned long __init xen_set_identity_and_remap_chunk(
>          const struct e820entry *list, size_t map_size, unsigned long start_pfn,
>  	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
> -	unsigned long *identity, unsigned long *remapped,
> -	unsigned long *released)
> +	unsigned long *identity, unsigned long *released)
>  {
>  	unsigned long pfn;
>  	unsigned long i = 0;
> @@ -431,19 +352,12 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
>  		if (size > remap_range_size)
>  			size = remap_range_size;
>  
> -		if (!xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn)) {
> -			WARN(1, "Failed to remap 1:1 memory cur_pfn=%ld size=%ld remap_pfn=%ld\n",
> -				cur_pfn, size, remap_pfn);
> -			xen_set_identity_and_release_chunk(cur_pfn,
> -				cur_pfn + left, nr_pages, identity, released);
> -			break;
> -		}
> +		xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn);
>  
>  		/* Update variables to reflect new mappings. */
>  		i += size;
>  		remap_pfn += size;
>  		*identity += size;
> -		*remapped += size;
>  	}
>  
>  	/*
> @@ -464,7 +378,6 @@ static unsigned long __init xen_set_identity_and_remap(
>  {
>  	phys_addr_t start = 0;
>  	unsigned long identity = 0;
> -	unsigned long remapped = 0;
>  	unsigned long last_pfn = nr_pages;
>  	const struct e820entry *entry;
>  	unsigned long num_released = 0;
> @@ -494,8 +407,7 @@ static unsigned long __init xen_set_identity_and_remap(
>  				last_pfn = xen_set_identity_and_remap_chunk(
>  						list, map_size, start_pfn,
>  						end_pfn, nr_pages, last_pfn,
> -						&identity, &remapped,
> -						&num_released);
> +						&identity, &num_released);
>  			start = end;
>  		}
>  	}
> @@ -503,12 +415,84 @@ static unsigned long __init xen_set_identity_and_remap(
>  	*released = num_released;
>  
>  	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
> -	pr_info("Remapped %ld page(s), last_pfn=%ld\n", remapped,
> -		last_pfn);
>  	pr_info("Released %ld page(s)\n", num_released);
>  
>  	return last_pfn;
>  }
> +
> +/*
> + * Remap the memory prepared in xen_do_set_identity_and_remap_chunk().
> + */
> +void __init xen_remap_memory(void)
> +{
> +	unsigned long buf = (unsigned long)&xen_remap_buf;
> +	unsigned long mfn_save, mfn, pfn;
> +	unsigned long remapped = 0, released = 0;
> +	unsigned int i, free;
> +	unsigned long pfn_s = ~0UL;
> +	unsigned long len = 0;
> +
> +	mfn_save = virt_to_mfn(buf);
> +
> +	while (xen_remap_mfn != INVALID_P2M_ENTRY) {

So the 'list' is constructed by going forward - that is from low-numbered
PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
other way - from the highest PFN to the lowest PFN.

Won't that mean we will restore the chunks of memory in the wrong
order? That is we will still restore them in chunks size, but the
chunks will be in descending order instead of ascending?

> +		/* Map the remap information */
> +		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
> +
> +		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
> +
> +		free = 0;
> +		pfn = xen_remap_buf.target_pfn;
> +		for (i = 0; i < xen_remap_buf.size; i++) {
> +			mfn = xen_remap_buf.mfns[i];
> +			if (!released && xen_update_mem_tables(pfn, mfn)) {
> +				remapped++;

If we fail 'xen_update_mem_tables' we will on the next chunk (so i+1) keep on
freeing pages instead of trying to remap. Is that intentional? Could we
try to remap?
> +			} else {
> +				if (!released) {
> +					if (pfn_s != ~0UL && len)
> +						memblock_free(PFN_PHYS(pfn_s),
> +							      PFN_PHYS(len));
> +					pfn_s = xen_remap_buf.target_pfn;
> +					len = i;
> +				}
> +				/* Don't free the page with our mfn list! */
> +				if (i)
> +					xen_free_mfn(mfn);
> +				else
> +					free = 1;
> +				released++;
> +			}
> +			pfn++;
> +		}
> +		if (!released) {
> +			if (pfn_s == ~0UL || pfn == pfn_s) {
> +				pfn_s = xen_remap_buf.target_pfn;
> +				len += xen_remap_buf.size;
> +			} else if (pfn_s + len == xen_remap_buf.target_pfn) {
> +				len += xen_remap_buf.size;
> +			} else {
> +				memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
> +				pfn_s = xen_remap_buf.target_pfn;
> +				len = xen_remap_buf.size;
> +			}
> +		}
> +
> +		mfn = xen_remap_mfn;
> +		xen_remap_mfn = xen_remap_buf.next_area_mfn;
> +		/* Now it's save to free the page holding our data. */
> +		if (free)
> +			xen_free_mfn(mfn);
> +	}
> +
> +	if (pfn_s != ~0UL && len)
> +		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
> +
> +	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
> +
> +	pr_info("Remapped %ld page(s)\n", remapped);
> +	if (released)
> +		pr_info("Released %ld page(s)\n", released);
> +}
> +
>  static unsigned long __init xen_get_max_pages(void)
>  {
>  	unsigned long max_pages = MAX_DOMAIN_PAGES;
> @@ -616,7 +600,8 @@ char * __init xen_memory_setup(void)
>  		extra_pages += max_pages - max_pfn;
>  
>  	/*
> -	 * Set identity map on non-RAM pages and remap the underlying RAM.
> +	 * Set identity map on non-RAM pages and prepare remapping the
> +	 * underlying RAM.
>  	 */
>  	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
>  					      &xen_released_pages);
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index 28c7e0b..5b72a06 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -35,6 +35,7 @@ void xen_mm_pin_all(void);
>  void xen_mm_unpin_all(void);
>  void xen_set_pat(u64);
>  
> +void __init xen_remap_memory(void);
>  char * __init xen_memory_setup(void);
>  char * xen_auto_xlated_memory_setup(void);
>  void __init xen_arch_setup(void);
> -- 
> 2.1.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 21:45:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 21: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 1XofjJ-0005GC-5L; Wed, 12 Nov 2014 21:45:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XofjH-0005G7-1t
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 21:45:31 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	CA/76-16982-AF4D3645; Wed, 12 Nov 2014 21:45:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415828727!10848351!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29118 invoked from network); 12 Nov 2014 21:45:29 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 21:45:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACLjA8r025197
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 21:45:11 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACLj8T2011491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 21:45:10 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACLj8Cx028987; Wed, 12 Nov 2014 21:45:08 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 13:45:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id F4019115CE6; Wed, 12 Nov 2014 16:45:06 -0500 (EST)
Date: Wed, 12 Nov 2014 16:45:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141112214506.GA5922@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-3-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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, Nov 11, 2014 at 06:43:40AM +0100, Juergen Gross wrote:
> Early in the boot process the memory layout of a pv-domain is changed
> to match the E820 map (either the host one for Dom0 or the Xen one)
> regarding placement of RAM and PCI holes. This requires removing memory
> pages initially located at positions not suitable for RAM and adding
> them later at higher addresses where no restrictions apply.
> 
> To be able to operate on the hypervisor supported p2m list until a
> virtual mapped linear p2m list can be constructed, remapping must
> be delayed until virtual memory management is initialized, as the
> initial p2m list can't be extended unlimited at physical memory
> initialization time due to it's fixed structure.
> 
> A further advantage is the reduction in complexity and code volume as
> we don't have to be careful regarding memory restrictions during p2m
> updates.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/include/asm/xen/page.h |   1 -
>  arch/x86/xen/mmu.c              |   4 +
>  arch/x86/xen/p2m.c              | 149 ++++------------
>  arch/x86/xen/setup.c            | 385 +++++++++++++++++++---------------------
>  arch/x86/xen/xen-ops.h          |   1 +
>  5 files changed, 223 insertions(+), 317 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 6c16451..b475297 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -44,7 +44,6 @@ extern unsigned long  machine_to_phys_nr;
>  
>  extern unsigned long get_phys_to_machine(unsigned long pfn);
>  extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
> -extern bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn);
>  extern bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
>  extern unsigned long set_phys_range_identity(unsigned long pfn_s,
>  					     unsigned long pfn_e);
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index a8a1a3d..d3e492b 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1223,6 +1223,10 @@ static void __init xen_pagetable_init(void)
>  	/* Allocate and initialize top and mid mfn levels for p2m structure */
>  	xen_build_mfn_list_list();
>  
> +	/* Remap memory freed because of conflicts with E820 map */

s/becasue of/due to
> +	if (!xen_feature(XENFEAT_auto_translated_physmap))
> +		xen_remap_memory();
> +
>  	xen_setup_shared_info();
>  	xen_post_allocator_init();
>  }
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index fa75842..f67f8cf 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -164,6 +164,7 @@
>  #include <linux/sched.h>
>  #include <linux/seq_file.h>
>  #include <linux/bootmem.h>
> +#include <linux/slab.h>
>  
>  #include <asm/cache.h>
>  #include <asm/setup.h>
> @@ -204,6 +205,8 @@ RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER
>   */
>  RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
>  
> +static int use_brk = 1;
> +
>  static inline unsigned p2m_top_index(unsigned long pfn)
>  {
>  	BUG_ON(pfn >= MAX_P2M_PFN);
> @@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
>  		p2m[i] = INVALID_P2M_ENTRY;
>  }
>  
> +static void * __ref alloc_p2m_page(void)
> +{
> +	if (unlikely(use_brk))
> +		return extend_brk(PAGE_SIZE, PAGE_SIZE);
> +
> +	if (unlikely(!slab_is_available()))
> +		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +
> +	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
> +}
> +
> +static void free_p2m_page(void *p)
> +{
> +	free_page((unsigned long)p);
> +}
> +
>  /*
>   * Build the parallel p2m_top_mfn and p2m_mid_mfn structures
>   *
> @@ -287,13 +306,13 @@ void __ref xen_build_mfn_list_list(void)
>  
>  	/* Pre-initialize p2m_top_mfn to be completely missing */
>  	if (p2m_top_mfn == NULL) {
> -		p2m_mid_missing_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +		p2m_mid_missing_mfn = alloc_p2m_page();
>  		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
>  
> -		p2m_top_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +		p2m_top_mfn_p = alloc_p2m_page();
>  		p2m_top_mfn_p_init(p2m_top_mfn_p);
>  
> -		p2m_top_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +		p2m_top_mfn = alloc_p2m_page();
>  		p2m_top_mfn_init(p2m_top_mfn);
>  	} else {
>  		/* Reinitialise, mfn's all change after migration */
> @@ -327,7 +346,7 @@ void __ref xen_build_mfn_list_list(void)
>  			 * missing parts of the mfn tree after
>  			 * runtime.
>  			 */
> -			mid_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
> +			mid_mfn_p = alloc_p2m_page();
>  			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
>  
>  			p2m_top_mfn_p[topidx] = mid_mfn_p;
> @@ -364,17 +383,17 @@ void __init xen_build_dynamic_phys_to_machine(void)
>  	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
>  	xen_max_p2m_pfn = max_pfn;
>  
> -	p2m_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m_missing = alloc_p2m_page();
>  	p2m_init(p2m_missing);
> -	p2m_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m_identity = alloc_p2m_page();
>  	p2m_init(p2m_identity);
>  
> -	p2m_mid_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m_mid_missing = alloc_p2m_page();
>  	p2m_mid_init(p2m_mid_missing, p2m_missing);
> -	p2m_mid_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m_mid_identity = alloc_p2m_page();
>  	p2m_mid_init(p2m_mid_identity, p2m_identity);
>  
> -	p2m_top = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m_top = alloc_p2m_page();
>  	p2m_top_init(p2m_top);
>  
>  	/*
> @@ -387,7 +406,7 @@ void __init xen_build_dynamic_phys_to_machine(void)
>  		unsigned mididx = p2m_mid_index(pfn);
>  
>  		if (p2m_top[topidx] == p2m_mid_missing) {
> -			unsigned long **mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +			unsigned long **mid = alloc_p2m_page();
>  			p2m_mid_init(mid, p2m_missing);
>  
>  			p2m_top[topidx] = mid;
> @@ -420,6 +439,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>  	unsigned long *mfn_list = NULL;
>  	unsigned long size;
>  
> +	use_brk = 0;
>  	va_start = xen_start_info->mfn_list;
>  	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
>  	 * so make sure it is rounded up to that */
> @@ -484,6 +504,7 @@ unsigned long __init xen_revector_p2m_tree(void)
>  #else
>  unsigned long __init xen_revector_p2m_tree(void)
>  {
> +	use_brk = 0;
>  	return 0;
>  }
>  #endif
> @@ -510,16 +531,6 @@ unsigned long get_phys_to_machine(unsigned long pfn)
>  }
>  EXPORT_SYMBOL_GPL(get_phys_to_machine);
>  
> -static void *alloc_p2m_page(void)
> -{
> -	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
> -}
> -
> -static void free_p2m_page(void *p)
> -{
> -	free_page((unsigned long)p);
> -}
> -
>  /*
>   * Fully allocate the p2m structure for a given pfn.  We need to check
>   * that both the top and mid levels are allocated, and make sure the
> @@ -624,7 +635,7 @@ static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
>  		return false;
>  
>  	/* Boundary cross-over for the edges: */
> -	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +	p2m = alloc_p2m_page();
>  
>  	p2m_init(p2m);
>  
> @@ -640,7 +651,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
>  
>  	mid = p2m_top[topidx];
>  	if (mid == p2m_mid_missing) {
> -		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
> +		mid = alloc_p2m_page();
>  
>  		p2m_mid_init(mid, p2m_missing);
>  
> @@ -649,100 +660,6 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
>  	return true;
>  }
>  

I would split this patch in two - one for the extend_brk/alloc_page conversation
to alloc_p2m_page and free_page to free_p2m_page.

> -/*
> - * Skim over the P2M tree looking at pages that are either filled with
> - * INVALID_P2M_ENTRY or with 1:1 PFNs. If found, re-use that page and
> - * replace the P2M leaf with a p2m_missing or p2m_identity.
> - * Stick the old page in the new P2M tree location.
> - */
> -static bool __init early_can_reuse_p2m_middle(unsigned long set_pfn)
> -{
> -	unsigned topidx;
> -	unsigned mididx;
> -	unsigned ident_pfns;
> -	unsigned inv_pfns;
> -	unsigned long *p2m;
> -	unsigned idx;
> -	unsigned long pfn;
> -
> -	/* We only look when this entails a P2M middle layer */
> -	if (p2m_index(set_pfn))
> -		return false;
> -
> -	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
> -		topidx = p2m_top_index(pfn);
> -
> -		if (!p2m_top[topidx])
> -			continue;
> -
> -		if (p2m_top[topidx] == p2m_mid_missing)
> -			continue;
> -
> -		mididx = p2m_mid_index(pfn);
> -		p2m = p2m_top[topidx][mididx];
> -		if (!p2m)
> -			continue;
> -
> -		if ((p2m == p2m_missing) || (p2m == p2m_identity))
> -			continue;
> -
> -		if ((unsigned long)p2m == INVALID_P2M_ENTRY)
> -			continue;
> -
> -		ident_pfns = 0;
> -		inv_pfns = 0;
> -		for (idx = 0; idx < P2M_PER_PAGE; idx++) {
> -			/* IDENTITY_PFNs are 1:1 */
> -			if (p2m[idx] == IDENTITY_FRAME(pfn + idx))
> -				ident_pfns++;
> -			else if (p2m[idx] == INVALID_P2M_ENTRY)
> -				inv_pfns++;
> -			else
> -				break;
> -		}
> -		if ((ident_pfns == P2M_PER_PAGE) || (inv_pfns == P2M_PER_PAGE))
> -			goto found;
> -	}
> -	return false;
> -found:
> -	/* Found one, replace old with p2m_identity or p2m_missing */
> -	p2m_top[topidx][mididx] = (ident_pfns ? p2m_identity : p2m_missing);
> -
> -	/* Reset where we want to stick the old page in. */
> -	topidx = p2m_top_index(set_pfn);
> -	mididx = p2m_mid_index(set_pfn);
> -
> -	/* This shouldn't happen */
> -	if (WARN_ON(p2m_top[topidx] == p2m_mid_missing))
> -		early_alloc_p2m_middle(set_pfn);
> -
> -	if (WARN_ON(p2m_top[topidx][mididx] != p2m_missing))
> -		return false;
> -
> -	p2m_init(p2m);
> -	p2m_top[topidx][mididx] = p2m;
> -
> -	return true;
> -}
> -bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> -{
> -	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
> -		if (!early_alloc_p2m_middle(pfn))
> -			return false;
> -
> -		if (early_can_reuse_p2m_middle(pfn))
> -			return __set_phys_to_machine(pfn, mfn);
> -
> -		if (!early_alloc_p2m(pfn, false /* boundary crossover OK!*/))
> -			return false;
> -
> -		if (!__set_phys_to_machine(pfn, mfn))
> -			return false;
> -	}
> -
> -	return true;
> -}
> -
>  static void __init early_split_p2m(unsigned long pfn)
>  {
>  	unsigned long mididx, idx;
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 29834b3..0e5f9b6 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -30,6 +30,7 @@
>  #include "xen-ops.h"
>  #include "vdso.h"
>  #include "p2m.h"
> +#include "mmu.h"
>  
>  /* These are code, but not functions.  Defined in entry.S */
>  extern const char xen_hypervisor_callback[];
> @@ -47,8 +48,18 @@ struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
>  /* Number of pages released from the initial allocation. */
>  unsigned long xen_released_pages;
>  
> -/* Buffer used to remap identity mapped pages */
> -unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
> +/*
> + * Buffer used to remap identity mapped pages. We only need the virtual space.

Could you expand on the 'need the virtual space'?


.. snip..
>  /*
>   * This function updates the p2m and m2p tables with an identity map from
> - * start_pfn to start_pfn+size and remaps the underlying RAM of the original
> - * allocation at remap_pfn. It must do so carefully in P2M_PER_PAGE sized blocks
> - * to not exhaust the reserved brk space. Doing it in properly aligned blocks
> - * ensures we only allocate the minimum required leaf pages in the p2m table. It
> - * copies the existing mfns from the p2m table under the 1:1 map, overwrites
> - * them with the identity map and then updates the p2m and m2p tables with the
> - * remapped memory.
> + * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the
> + * original allocation at remap_pfn. The information needed for remapping is
> + * saved in the memory itself to avoid the need for allocating buffers. The
> + * complete remap information is contained in a list of MFNs each containing
> + * up to REMAP_SIZE MFNs and the start target PFN for doing the remap.
> + * This enables to preserve the original mfn sequence while doing the remapping

us to
> + * at a time when the memory management is capable of allocating virtual and
> + * physical memory in arbitrary amounts.

You might want to add, see 'xen_remap_memory' and its callers.

>   */
> -static unsigned long __init xen_do_set_identity_and_remap_chunk(
> +static void __init xen_do_set_identity_and_remap_chunk(
>          unsigned long start_pfn, unsigned long size, unsigned long remap_pfn)
>  {
> +	unsigned long buf = (unsigned long)&xen_remap_buf;
> +	unsigned long mfn_save, mfn;
>  	unsigned long ident_pfn_iter, remap_pfn_iter;
> -	unsigned long ident_start_pfn_align, remap_start_pfn_align;
> -	unsigned long ident_end_pfn_align, remap_end_pfn_align;
> -	unsigned long ident_boundary_pfn, remap_boundary_pfn;
> -	unsigned long ident_cnt = 0;
> -	unsigned long remap_cnt = 0;
> +	unsigned long ident_end_pfn = start_pfn + size;
>  	unsigned long left = size;
> -	unsigned long mod;
> -	int i;
> +	unsigned long ident_cnt = 0;
> +	unsigned int i, chunk;
>  
>  	WARN_ON(size == 0);
>  
>  	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
>  
> -	/*
> -	 * Determine the proper alignment to remap memory in P2M_PER_PAGE sized
> -	 * blocks. We need to keep track of both the existing pfn mapping and
> -	 * the new pfn remapping.
> -	 */
> -	mod = start_pfn % P2M_PER_PAGE;
> -	ident_start_pfn_align =
> -		mod ? (start_pfn - mod + P2M_PER_PAGE) : start_pfn;
> -	mod = remap_pfn % P2M_PER_PAGE;
> -	remap_start_pfn_align =
> -		mod ? (remap_pfn - mod + P2M_PER_PAGE) : remap_pfn;
> -	mod = (start_pfn + size) % P2M_PER_PAGE;
> -	ident_end_pfn_align = start_pfn + size - mod;
> -	mod = (remap_pfn + size) % P2M_PER_PAGE;
> -	remap_end_pfn_align = remap_pfn + size - mod;
> -
> -	/* Iterate over each p2m leaf node in each range */
> -	for (ident_pfn_iter = ident_start_pfn_align, remap_pfn_iter = remap_start_pfn_align;
> -	     ident_pfn_iter < ident_end_pfn_align && remap_pfn_iter < remap_end_pfn_align;
> -	     ident_pfn_iter += P2M_PER_PAGE, remap_pfn_iter += P2M_PER_PAGE) {
> -		/* Check we aren't past the end */
> -		BUG_ON(ident_pfn_iter + P2M_PER_PAGE > start_pfn + size);
> -		BUG_ON(remap_pfn_iter + P2M_PER_PAGE > remap_pfn + size);
> -
> -		/* Save p2m mappings */
> -		for (i = 0; i < P2M_PER_PAGE; i++)
> -			xen_remap_buf[i] = pfn_to_mfn(ident_pfn_iter + i);
> -
> -		/* Set identity map which will free a p2m leaf */
> -		ident_cnt += set_phys_range_identity(ident_pfn_iter,
> -			ident_pfn_iter + P2M_PER_PAGE);
> -
> -#ifdef DEBUG
> -		/* Helps verify a p2m leaf has been freed */
> -		for (i = 0; i < P2M_PER_PAGE; i++) {
> -			unsigned int pfn = ident_pfn_iter + i;
> -			BUG_ON(pfn_to_mfn(pfn) != pfn);
> -		}
> -#endif
> -		/* Now remap memory */
> -		for (i = 0; i < P2M_PER_PAGE; i++) {
> -			unsigned long mfn = xen_remap_buf[i];
> -
> -			/* This will use the p2m leaf freed above */
> -			if (!xen_update_mem_tables(remap_pfn_iter + i, mfn)) {
> -				WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
> -					remap_pfn_iter + i, mfn);
> -				return 0;
> -			}
> -
> -			remap_cnt++;
> -		}
> -
> -		left -= P2M_PER_PAGE;
> -	}
> +	/* Don't use memory until remapped */
> +	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
>  
> -	/* Max boundary space possible */
> -	BUG_ON(left > (P2M_PER_PAGE - 1) * 2);
> +	mfn_save = virt_to_mfn(buf);
>  
> -	/* Now handle the boundary conditions */
> -	ident_boundary_pfn = start_pfn;
> -	remap_boundary_pfn = remap_pfn;
> -	for (i = 0; i < left; i++) {
> -		unsigned long mfn;
> +	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
> +	     ident_pfn_iter < ident_end_pfn;
> +	     ident_pfn_iter += REMAP_SIZE, remap_pfn_iter += REMAP_SIZE) {
> +		chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE;
>  
> -		/* These two checks move from the start to end boundaries */
> -		if (ident_boundary_pfn == ident_start_pfn_align)
> -			ident_boundary_pfn = ident_pfn_iter;
> -		if (remap_boundary_pfn == remap_start_pfn_align)
> -			remap_boundary_pfn = remap_pfn_iter;
> +		/* Map first pfn to xen_remap_buf */
> +		mfn = pfn_to_mfn(ident_pfn_iter);
> +		set_pte_mfn(buf, mfn, PAGE_KERNEL);

So you set the buf to be point to 'mfn'.
>  
> -		/* Check we aren't past the end */
> -		BUG_ON(ident_boundary_pfn >= start_pfn + size);
> -		BUG_ON(remap_boundary_pfn >= remap_pfn + size);
> +		/* Save mapping information in page */
> +		xen_remap_buf.next_area_mfn = xen_remap_mfn;
> +		xen_remap_buf.target_pfn = remap_pfn_iter;
> +		xen_remap_buf.size = chunk;
> +		for (i = 0; i < chunk; i++)
> +			xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i);
>  
> -		mfn = pfn_to_mfn(ident_boundary_pfn);
> +		/* New element first in list */

I don't get that comment. Don't you mean the MFN of the last chunk you
had stashed the 'xen_remap_buf' structure in?

The 'xen_remap_mfn' ends up being the the tail value of this
"list".
> +		xen_remap_mfn = mfn;
>  
> -		if (!xen_update_mem_tables(remap_boundary_pfn, mfn)) {
> -			WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
> -				remap_pfn_iter + i, mfn);
> -			return 0;
> -		}
> -		remap_cnt++;
> -
> -		ident_boundary_pfn++;
> -		remap_boundary_pfn++;
> -	}
> +		/* Set identity map */
> +		ident_cnt += set_phys_range_identity(ident_pfn_iter,
> +			ident_pfn_iter + chunk);
>  
> -	/* Finish up the identity map */
> -	if (ident_start_pfn_align >= ident_end_pfn_align) {
> -		/*
> -                 * In this case we have an identity range which does not span an
> -                 * aligned block so everything needs to be identity mapped here.
> -                 * If we didn't check this we might remap too many pages since
> -                 * the align boundaries are not meaningful in this case.
> -	         */
> -		ident_cnt += set_phys_range_identity(start_pfn,
> -			start_pfn + size);
> -	} else {
> -		/* Remapped above so check each end of the chunk */
> -		if (start_pfn < ident_start_pfn_align)
> -			ident_cnt += set_phys_range_identity(start_pfn,
> -				ident_start_pfn_align);
> -		if (start_pfn + size > ident_pfn_iter)
> -			ident_cnt += set_phys_range_identity(ident_pfn_iter,
> -				start_pfn + size);
> +		left -= chunk;
>  	}
>  
> -	BUG_ON(ident_cnt != size);
> -	BUG_ON(remap_cnt != size);
> -
> -	return size;
> +	/* Restore old xen_remap_buf mapping */
> +	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
>  }
>  
>  /*
> @@ -396,8 +318,7 @@ static unsigned long __init xen_do_set_identity_and_remap_chunk(
>  static unsigned long __init xen_set_identity_and_remap_chunk(
>          const struct e820entry *list, size_t map_size, unsigned long start_pfn,
>  	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
> -	unsigned long *identity, unsigned long *remapped,
> -	unsigned long *released)
> +	unsigned long *identity, unsigned long *released)
>  {
>  	unsigned long pfn;
>  	unsigned long i = 0;
> @@ -431,19 +352,12 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
>  		if (size > remap_range_size)
>  			size = remap_range_size;
>  
> -		if (!xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn)) {
> -			WARN(1, "Failed to remap 1:1 memory cur_pfn=%ld size=%ld remap_pfn=%ld\n",
> -				cur_pfn, size, remap_pfn);
> -			xen_set_identity_and_release_chunk(cur_pfn,
> -				cur_pfn + left, nr_pages, identity, released);
> -			break;
> -		}
> +		xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn);
>  
>  		/* Update variables to reflect new mappings. */
>  		i += size;
>  		remap_pfn += size;
>  		*identity += size;
> -		*remapped += size;
>  	}
>  
>  	/*
> @@ -464,7 +378,6 @@ static unsigned long __init xen_set_identity_and_remap(
>  {
>  	phys_addr_t start = 0;
>  	unsigned long identity = 0;
> -	unsigned long remapped = 0;
>  	unsigned long last_pfn = nr_pages;
>  	const struct e820entry *entry;
>  	unsigned long num_released = 0;
> @@ -494,8 +407,7 @@ static unsigned long __init xen_set_identity_and_remap(
>  				last_pfn = xen_set_identity_and_remap_chunk(
>  						list, map_size, start_pfn,
>  						end_pfn, nr_pages, last_pfn,
> -						&identity, &remapped,
> -						&num_released);
> +						&identity, &num_released);
>  			start = end;
>  		}
>  	}
> @@ -503,12 +415,84 @@ static unsigned long __init xen_set_identity_and_remap(
>  	*released = num_released;
>  
>  	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
> -	pr_info("Remapped %ld page(s), last_pfn=%ld\n", remapped,
> -		last_pfn);
>  	pr_info("Released %ld page(s)\n", num_released);
>  
>  	return last_pfn;
>  }
> +
> +/*
> + * Remap the memory prepared in xen_do_set_identity_and_remap_chunk().
> + */
> +void __init xen_remap_memory(void)
> +{
> +	unsigned long buf = (unsigned long)&xen_remap_buf;
> +	unsigned long mfn_save, mfn, pfn;
> +	unsigned long remapped = 0, released = 0;
> +	unsigned int i, free;
> +	unsigned long pfn_s = ~0UL;
> +	unsigned long len = 0;
> +
> +	mfn_save = virt_to_mfn(buf);
> +
> +	while (xen_remap_mfn != INVALID_P2M_ENTRY) {

So the 'list' is constructed by going forward - that is from low-numbered
PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
other way - from the highest PFN to the lowest PFN.

Won't that mean we will restore the chunks of memory in the wrong
order? That is we will still restore them in chunks size, but the
chunks will be in descending order instead of ascending?

> +		/* Map the remap information */
> +		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
> +
> +		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
> +
> +		free = 0;
> +		pfn = xen_remap_buf.target_pfn;
> +		for (i = 0; i < xen_remap_buf.size; i++) {
> +			mfn = xen_remap_buf.mfns[i];
> +			if (!released && xen_update_mem_tables(pfn, mfn)) {
> +				remapped++;

If we fail 'xen_update_mem_tables' we will on the next chunk (so i+1) keep on
freeing pages instead of trying to remap. Is that intentional? Could we
try to remap?
> +			} else {
> +				if (!released) {
> +					if (pfn_s != ~0UL && len)
> +						memblock_free(PFN_PHYS(pfn_s),
> +							      PFN_PHYS(len));
> +					pfn_s = xen_remap_buf.target_pfn;
> +					len = i;
> +				}
> +				/* Don't free the page with our mfn list! */
> +				if (i)
> +					xen_free_mfn(mfn);
> +				else
> +					free = 1;
> +				released++;
> +			}
> +			pfn++;
> +		}
> +		if (!released) {
> +			if (pfn_s == ~0UL || pfn == pfn_s) {
> +				pfn_s = xen_remap_buf.target_pfn;
> +				len += xen_remap_buf.size;
> +			} else if (pfn_s + len == xen_remap_buf.target_pfn) {
> +				len += xen_remap_buf.size;
> +			} else {
> +				memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
> +				pfn_s = xen_remap_buf.target_pfn;
> +				len = xen_remap_buf.size;
> +			}
> +		}
> +
> +		mfn = xen_remap_mfn;
> +		xen_remap_mfn = xen_remap_buf.next_area_mfn;
> +		/* Now it's save to free the page holding our data. */
> +		if (free)
> +			xen_free_mfn(mfn);
> +	}
> +
> +	if (pfn_s != ~0UL && len)
> +		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
> +
> +	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
> +
> +	pr_info("Remapped %ld page(s)\n", remapped);
> +	if (released)
> +		pr_info("Released %ld page(s)\n", released);
> +}
> +
>  static unsigned long __init xen_get_max_pages(void)
>  {
>  	unsigned long max_pages = MAX_DOMAIN_PAGES;
> @@ -616,7 +600,8 @@ char * __init xen_memory_setup(void)
>  		extra_pages += max_pages - max_pfn;
>  
>  	/*
> -	 * Set identity map on non-RAM pages and remap the underlying RAM.
> +	 * Set identity map on non-RAM pages and prepare remapping the
> +	 * underlying RAM.
>  	 */
>  	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
>  					      &xen_released_pages);
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index 28c7e0b..5b72a06 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -35,6 +35,7 @@ void xen_mm_pin_all(void);
>  void xen_mm_unpin_all(void);
>  void xen_set_pat(u64);
>  
> +void __init xen_remap_memory(void);
>  char * __init xen_memory_setup(void);
>  char * xen_auto_xlated_memory_setup(void);
>  void __init xen_arch_setup(void);
> -- 
> 2.1.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 21:57:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 21:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XofuL-0005bu-FT; Wed, 12 Nov 2014 21:56:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XofuK-0005bp-FM
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 21:56:56 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	0E/0B-17958-7A7D3645; Wed, 12 Nov 2014 21:56:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415829412!10966686!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16134 invoked from network); 12 Nov 2014 21:56:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 21:56:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,371,1413244800"; d="scan'208";a="190710196"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 16:56:47 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XofuA-0005kO-Ko;
	Wed, 12 Nov 2014 21:56:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XofuA-0005Dz-1o;
	Wed, 12 Nov 2014 21:56:46 +0000
Date: Wed, 12 Nov 2014 21:56:46 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31509-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31509: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31509 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31509/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 21:57:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 21:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XofuL-0005bu-FT; Wed, 12 Nov 2014 21:56:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XofuK-0005bp-FM
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 21:56:56 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	0E/0B-17958-7A7D3645; Wed, 12 Nov 2014 21:56:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415829412!10966686!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16134 invoked from network); 12 Nov 2014 21:56:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 21:56:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,371,1413244800"; d="scan'208";a="190710196"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 16:56:47 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XofuA-0005kO-Ko;
	Wed, 12 Nov 2014 21:56:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XofuA-0005Dz-1o;
	Wed, 12 Nov 2014 21:56:46 +0000
Date: Wed, 12 Nov 2014 21:56:46 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31509-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31509: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31509 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31509/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 22:10:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 22:10:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xog7e-0005vy-Rn; Wed, 12 Nov 2014 22:10:42 +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 1Xog7c-0005vt-V0
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 22:10:41 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	AB/E4-11581-0EAD3645; Wed, 12 Nov 2014 22:10:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415830238!10956861!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8080 invoked from network); 12 Nov 2014 22:10:39 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 22:10:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACMAOaT005489
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 22:10:25 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACMAN8D008858
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 22:10:24 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACMAMZ6008834; Wed, 12 Nov 2014 22:10:22 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 14:10:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4CD83115D02; Wed, 12 Nov 2014 17:10:21 -0500 (EST)
Date: Wed, 12 Nov 2014 17:10:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141112221021.GC7549@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-5-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-5-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 4/8] xen: Delay invalidating extra 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

> @@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
>  	unsigned long max_pfn;
>  	unsigned long pfn;
>  
> -	 if (xen_feature(XENFEAT_auto_translated_physmap))
> +	if (xen_feature(XENFEAT_auto_translated_physmap))

Spurious change.

.. snip..
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 0e5f9b6..8d5985b 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -75,7 +75,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
>  
>  static void __init xen_add_extra_mem(u64 start, u64 size)
>  {
> -	unsigned long pfn;
>  	int i;
>  
>  	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
> @@ -95,17 +94,74 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
>  		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
>  
>  	memblock_reserve(start, size);
> +}
>  
> -	xen_max_p2m_pfn = PFN_DOWN(start + size);
> -	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
> -		unsigned long mfn = pfn_to_mfn(pfn);
> +static void __init xen_del_extra_mem(u64 start, u64 size)
> +{
> +	int i;
> +	u64 start_r, size_r;
>  
> -		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
> -			continue;
> -		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
> -			  pfn, mfn);
> +	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
> +		start_r = xen_extra_mem[i].start;
> +		size_r = xen_extra_mem[i].size;
> +
> +		/* Start of region. */
> +		if (start_r == start) {
> +			BUG_ON(size > size_r);
> +			xen_extra_mem[i].start += size;
> +			xen_extra_mem[i].size -= size;
> +			break;
> +		}
> +		/* End of region. */
> +		if (start_r + size_r == start + size) {
> +			BUG_ON(size > size_r);
> +			xen_extra_mem[i].size -= size;
> +			break;
> +		}
> +		/* Mid of region. */
> +		if (start > start_r && start < start_r + size_r) {
> +			BUG_ON(start + size > start_r + size_r);
> +			xen_extra_mem[i].size = start - start_r;
> +			xen_add_extra_mem(start + size, start_r + size_r -
> +					  (start + size));

Which ends up calling 'memblock_reserve' for an region it already has
reserved. Should we call memblock_free(start_r, size_r - size) before calling this?

Or is that not neccessary as memblock_* is pretty smart about this sort of thing?

> +			break;
> +		}
> +	}
> +	memblock_free(start, size);
> +}
> +

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 22:10:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 22:10:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xog7e-0005vy-Rn; Wed, 12 Nov 2014 22:10:42 +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 1Xog7c-0005vt-V0
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 22:10:41 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	AB/E4-11581-0EAD3645; Wed, 12 Nov 2014 22:10:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415830238!10956861!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8080 invoked from network); 12 Nov 2014 22:10:39 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 22:10:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACMAOaT005489
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 22:10:25 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACMAN8D008858
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 22:10:24 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACMAMZ6008834; Wed, 12 Nov 2014 22:10:22 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 14:10:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4CD83115D02; Wed, 12 Nov 2014 17:10:21 -0500 (EST)
Date: Wed, 12 Nov 2014 17:10:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141112221021.GC7549@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-5-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-5-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 4/8] xen: Delay invalidating extra 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

> @@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
>  	unsigned long max_pfn;
>  	unsigned long pfn;
>  
> -	 if (xen_feature(XENFEAT_auto_translated_physmap))
> +	if (xen_feature(XENFEAT_auto_translated_physmap))

Spurious change.

.. snip..
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 0e5f9b6..8d5985b 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -75,7 +75,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
>  
>  static void __init xen_add_extra_mem(u64 start, u64 size)
>  {
> -	unsigned long pfn;
>  	int i;
>  
>  	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
> @@ -95,17 +94,74 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
>  		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
>  
>  	memblock_reserve(start, size);
> +}
>  
> -	xen_max_p2m_pfn = PFN_DOWN(start + size);
> -	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
> -		unsigned long mfn = pfn_to_mfn(pfn);
> +static void __init xen_del_extra_mem(u64 start, u64 size)
> +{
> +	int i;
> +	u64 start_r, size_r;
>  
> -		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
> -			continue;
> -		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
> -			  pfn, mfn);
> +	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
> +		start_r = xen_extra_mem[i].start;
> +		size_r = xen_extra_mem[i].size;
> +
> +		/* Start of region. */
> +		if (start_r == start) {
> +			BUG_ON(size > size_r);
> +			xen_extra_mem[i].start += size;
> +			xen_extra_mem[i].size -= size;
> +			break;
> +		}
> +		/* End of region. */
> +		if (start_r + size_r == start + size) {
> +			BUG_ON(size > size_r);
> +			xen_extra_mem[i].size -= size;
> +			break;
> +		}
> +		/* Mid of region. */
> +		if (start > start_r && start < start_r + size_r) {
> +			BUG_ON(start + size > start_r + size_r);
> +			xen_extra_mem[i].size = start - start_r;
> +			xen_add_extra_mem(start + size, start_r + size_r -
> +					  (start + size));

Which ends up calling 'memblock_reserve' for an region it already has
reserved. Should we call memblock_free(start_r, size_r - size) before calling this?

Or is that not neccessary as memblock_* is pretty smart about this sort of thing?

> +			break;
> +		}
> +	}
> +	memblock_free(start, size);
> +}
> +

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 22:12:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 22:12:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xog9G-0006Bt-Df; Wed, 12 Nov 2014 22:12:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xog9E-0006Bm-K7
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 22:12:20 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	A0/2F-27623-34BD3645; Wed, 12 Nov 2014 22:12:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415830337!10989138!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18462 invoked from network); 12 Nov 2014 22:12:19 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 22:12:19 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACMC6Ld007400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 22:12:07 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACMC59c016369
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 22:12:06 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACMC5uI016351; Wed, 12 Nov 2014 22:12:05 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 14:12:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 49E6A115D05; Wed, 12 Nov 2014 17:12:04 -0500 (EST)
Date: Wed, 12 Nov 2014 17:12:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141112221204.GD7549@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-6-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-6-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 5/8] x86: Introduce function to get pmd
	entry pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:43:43AM +0100, Juergen Gross wrote:
> Introduces lookup_pmd_address() to get the address of the pmd entry
> related to a virtual address in the current address space. This
> function is needed for support of a virtual mapped sparse p2m list
> in xen pv domains.
>
What is wrong with using 'lookup_address' ?
 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/include/asm/pgtable_types.h |  1 +
>  arch/x86/mm/pageattr.c               | 20 ++++++++++++++++++++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
> index 0778964..d83f5e7 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -396,6 +396,7 @@ static inline void update_page_count(int level, unsigned long pages) { }
>  extern pte_t *lookup_address(unsigned long address, unsigned int *level);
>  extern pte_t *lookup_address_in_pgd(pgd_t *pgd, unsigned long address,
>  				    unsigned int *level);
> +extern pmd_t *lookup_pmd_address(unsigned long address);
>  extern phys_addr_t slow_virt_to_phys(void *__address);
>  extern int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
>  				   unsigned numpages, unsigned long page_flags);
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index 36de293..1298108 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -384,6 +384,26 @@ static pte_t *_lookup_address_cpa(struct cpa_data *cpa, unsigned long address,
>  }
>  
>  /*
> + * Lookup the PMD entry for a virtual address. Return a pointer to the entry
> + * or NULL if not present.
> + */
> +pmd_t *lookup_pmd_address(unsigned long address)
> +{
> +	pgd_t *pgd;
> +	pud_t *pud;
> +
> +	pgd = pgd_offset_k(address);
> +	if (pgd_none(*pgd))
> +		return NULL;
> +
> +	pud = pud_offset(pgd, address);
> +	if (pud_none(*pud) || pud_large(*pud) || !pud_present(*pud))
> +		return NULL;
> +
> +	return pmd_offset(pud, address);
> +}
> +
> +/*
>   * This is necessary because __pa() does not work on some
>   * kinds of memory, like vmalloc() or the alloc_remap()
>   * areas on 32-bit NUMA systems.  The percpu areas can
> -- 
> 2.1.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 22:12:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 22:12:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xog9G-0006Bt-Df; Wed, 12 Nov 2014 22:12:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xog9E-0006Bm-K7
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 22:12:20 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	A0/2F-27623-34BD3645; Wed, 12 Nov 2014 22:12:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415830337!10989138!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18462 invoked from network); 12 Nov 2014 22:12:19 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 22:12:19 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACMC6Ld007400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 22:12:07 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACMC59c016369
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 12 Nov 2014 22:12:06 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACMC5uI016351; Wed, 12 Nov 2014 22:12:05 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 14:12:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 49E6A115D05; Wed, 12 Nov 2014 17:12:04 -0500 (EST)
Date: Wed, 12 Nov 2014 17:12:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141112221204.GD7549@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-6-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-6-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 5/8] x86: Introduce function to get pmd
	entry pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:43:43AM +0100, Juergen Gross wrote:
> Introduces lookup_pmd_address() to get the address of the pmd entry
> related to a virtual address in the current address space. This
> function is needed for support of a virtual mapped sparse p2m list
> in xen pv domains.
>
What is wrong with using 'lookup_address' ?
 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/include/asm/pgtable_types.h |  1 +
>  arch/x86/mm/pageattr.c               | 20 ++++++++++++++++++++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
> index 0778964..d83f5e7 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -396,6 +396,7 @@ static inline void update_page_count(int level, unsigned long pages) { }
>  extern pte_t *lookup_address(unsigned long address, unsigned int *level);
>  extern pte_t *lookup_address_in_pgd(pgd_t *pgd, unsigned long address,
>  				    unsigned int *level);
> +extern pmd_t *lookup_pmd_address(unsigned long address);
>  extern phys_addr_t slow_virt_to_phys(void *__address);
>  extern int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
>  				   unsigned numpages, unsigned long page_flags);
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index 36de293..1298108 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -384,6 +384,26 @@ static pte_t *_lookup_address_cpa(struct cpa_data *cpa, unsigned long address,
>  }
>  
>  /*
> + * Lookup the PMD entry for a virtual address. Return a pointer to the entry
> + * or NULL if not present.
> + */
> +pmd_t *lookup_pmd_address(unsigned long address)
> +{
> +	pgd_t *pgd;
> +	pud_t *pud;
> +
> +	pgd = pgd_offset_k(address);
> +	if (pgd_none(*pgd))
> +		return NULL;
> +
> +	pud = pud_offset(pgd, address);
> +	if (pud_none(*pud) || pud_large(*pud) || !pud_present(*pud))
> +		return NULL;
> +
> +	return pmd_offset(pud, address);
> +}
> +
> +/*
>   * This is necessary because __pa() does not work on some
>   * kinds of memory, like vmalloc() or the alloc_remap()
>   * areas on 32-bit NUMA systems.  The percpu areas can
> -- 
> 2.1.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 22:18:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 22:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XogFF-0006NU-9H; Wed, 12 Nov 2014 22:18:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XogFE-0006NP-3U
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 22:18:32 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	E8/97-07724-7BCD3645; Wed, 12 Nov 2014 22:18:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415830709!11019972!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31688 invoked from network); 12 Nov 2014 22:18:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 22:18:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACMIIqD015794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 22:18:19 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACMIGRj012718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 22:18:18 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACMIFge029733; Wed, 12 Nov 2014 22:18:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 14:18:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A5C4B115D11; Wed, 12 Nov 2014 17:18:13 -0500 (EST)
Date: Wed, 12 Nov 2014 17:18:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141112221813.GE7549@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-7-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-7-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 6/8] xen: Hide get_phys_to_machine() to
 be able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:43:44AM +0100, Juergen Gross wrote:
> Today get_phys_to_machine() is always called when the mfn for a pfn
> is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
> to be able to avoid calling get_phys_to_machine() when possible as

s/when/where/
> soon as the switch to a linear mapped p2m list has been done.

But your inline function still calls get_phys_to_machine?


> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/include/asm/xen/page.h | 27 +++++++++++++++++++++------
>  arch/x86/xen/mmu.c              |  2 +-
>  arch/x86/xen/p2m.c              |  6 +++---
>  3 files changed, 25 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 28fa795..07d8a7b 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -59,6 +59,22 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
>  				     struct page **pages, unsigned int count);
>  extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
>  
> +/*
> + * When to use pfn_to_mfn(), __pfn_to_mfn() or get_phys_to_machine():
> + * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. In case of an
> + *   identity entry the identity indicator will be cleared.

Why don't you say : In case of identity PFN the same PFN is returned.

But you did miss that also the FOREIGN_FRAME_BIT is cleared.

> + * - __pfn_to_mfn() returns the found entry of the p2m table. A possibly set

s/of the/in the/
> + *   identity indicator will be still set. __pfn_to_mfn() is encapsulating
.. be still set if the PFN is an identity one.
> + *   get_phys_to_machine() and might skip that function if possible to speed
> + *   up the common path.

How is is skipping that function? The patch below does no such thing?

> + * - get_phys_to_machine() is basically the same as __pfn_to_mfn(), but
> + *   without any short cuts for the common fast path.

Right. Perhpas we should call it 'slow_p2m' instead of the 'get_phys_to_machine'.

> + */
> +static inline unsigned long __pfn_to_mfn(unsigned long pfn)
> +{
> +	return get_phys_to_machine(pfn);
> +}
> +

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 22:18:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 22:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XogFF-0006NU-9H; Wed, 12 Nov 2014 22:18:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XogFE-0006NP-3U
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 22:18:32 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	E8/97-07724-7BCD3645; Wed, 12 Nov 2014 22:18:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415830709!11019972!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31688 invoked from network); 12 Nov 2014 22:18:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Nov 2014 22:18:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sACMIIqD015794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 12 Nov 2014 22:18:19 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sACMIGRj012718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Nov 2014 22:18:18 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sACMIFge029733; Wed, 12 Nov 2014 22:18:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 14:18:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A5C4B115D11; Wed, 12 Nov 2014 17:18:13 -0500 (EST)
Date: Wed, 12 Nov 2014 17:18:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141112221813.GE7549@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-7-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-7-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 6/8] xen: Hide get_phys_to_machine() to
 be able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:43:44AM +0100, Juergen Gross wrote:
> Today get_phys_to_machine() is always called when the mfn for a pfn
> is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
> to be able to avoid calling get_phys_to_machine() when possible as

s/when/where/
> soon as the switch to a linear mapped p2m list has been done.

But your inline function still calls get_phys_to_machine?


> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/include/asm/xen/page.h | 27 +++++++++++++++++++++------
>  arch/x86/xen/mmu.c              |  2 +-
>  arch/x86/xen/p2m.c              |  6 +++---
>  3 files changed, 25 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 28fa795..07d8a7b 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -59,6 +59,22 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
>  				     struct page **pages, unsigned int count);
>  extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
>  
> +/*
> + * When to use pfn_to_mfn(), __pfn_to_mfn() or get_phys_to_machine():
> + * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. In case of an
> + *   identity entry the identity indicator will be cleared.

Why don't you say : In case of identity PFN the same PFN is returned.

But you did miss that also the FOREIGN_FRAME_BIT is cleared.

> + * - __pfn_to_mfn() returns the found entry of the p2m table. A possibly set

s/of the/in the/
> + *   identity indicator will be still set. __pfn_to_mfn() is encapsulating
.. be still set if the PFN is an identity one.
> + *   get_phys_to_machine() and might skip that function if possible to speed
> + *   up the common path.

How is is skipping that function? The patch below does no such thing?

> + * - get_phys_to_machine() is basically the same as __pfn_to_mfn(), but
> + *   without any short cuts for the common fast path.

Right. Perhpas we should call it 'slow_p2m' instead of the 'get_phys_to_machine'.

> + */
> +static inline unsigned long __pfn_to_mfn(unsigned long pfn)
> +{
> +	return get_phys_to_machine(pfn);
> +}
> +

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 22:30:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 22:30:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XogQR-0006hq-Hq; Wed, 12 Nov 2014 22:30:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1XogQP-0006hk-OP
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 22:30:05 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	CC/85-23865-C6FD3645; Wed, 12 Nov 2014 22:30:04 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415831402!10987038!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26314 invoked from network); 12 Nov 2014 22:30:03 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 22:30:03 -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
	sACMTfh0003596
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 12 Nov 2014 17:29:41 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sACMTfQx003594;
	Wed, 12 Nov 2014 17:29:41 -0500
Date: Wed, 12 Nov 2014 18:29:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141112222940.GA3566@andromeda.dapyr.net>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<20141112160620.GA12856@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112160620.GA12856@andromeda.dapyr.net>
User-Agent: Mutt/1.5.9i
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 12:06:20PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> > Hi All,
> > 
> > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> 
> Yeey! Thank you for doing those tests.
> > 
> > Test environment:
> > Xen: Xen 4.5-rc1 
> > Dom0: Linux kernel 3.17.0
> > Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP
> > 
> > New bugs(9):
> 
> > 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
> 
> Please post the bug as an email on xen-devel so we can start the
> discussion here.
> 
> 
> > 5. Dom0 failed to resume from S3 power state
> 
> Interstingly enough it works for me on my AMD box. I will shortly try
> it out with the Intel laptop (X230) (been using Xen 4.4 + 3.17.0).

I put it on laptop (Lenovo X230) and used 'pm-suspend' and as well just
closing the lid. In both cases it worked.

Does that work for you as well?

Thanks.
> 
> Please post the bug as an email on xen-devel so we can start the
> discussion here.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 22:30:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 22:30:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XogQR-0006hq-Hq; Wed, 12 Nov 2014 22:30:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1XogQP-0006hk-OP
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 22:30:05 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	CC/85-23865-C6FD3645; Wed, 12 Nov 2014 22:30:04 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415831402!10987038!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26314 invoked from network); 12 Nov 2014 22:30:03 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Nov 2014 22:30:03 -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
	sACMTfh0003596
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 12 Nov 2014 17:29:41 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sACMTfQx003594;
	Wed, 12 Nov 2014 17:29:41 -0500
Date: Wed, 12 Nov 2014 18:29:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141112222940.GA3566@andromeda.dapyr.net>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<20141112160620.GA12856@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112160620.GA12856@andromeda.dapyr.net>
User-Agent: Mutt/1.5.9i
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 12:06:20PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> > Hi All,
> > 
> > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> 
> Yeey! Thank you for doing those tests.
> > 
> > Test environment:
> > Xen: Xen 4.5-rc1 
> > Dom0: Linux kernel 3.17.0
> > Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP
> > 
> > New bugs(9):
> 
> > 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
> 
> Please post the bug as an email on xen-devel so we can start the
> discussion here.
> 
> 
> > 5. Dom0 failed to resume from S3 power state
> 
> Interstingly enough it works for me on my AMD box. I will shortly try
> it out with the Intel laptop (X230) (been using Xen 4.4 + 3.17.0).

I put it on laptop (Lenovo X230) and used 'pm-suspend' and as well just
closing the lid. In both cases it worked.

Does that work for you as well?

Thanks.
> 
> Please post the bug as an email on xen-devel so we can start the
> discussion here.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 23:14:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 23:14:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoh7G-0007k5-DL; Wed, 12 Nov 2014 23:14:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xoh7E-0007k0-8n
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 23:14:20 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	9A/C7-02699-BC9E3645; Wed, 12 Nov 2014 23:14:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415834057!7519650!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26905 invoked from network); 12 Nov 2014 23:14:18 -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;
	12 Nov 2014 23:14:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,371,1413244800"; d="scan'208";a="192186231"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 18:14:15 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xoh79-00067V-Fi;
	Wed, 12 Nov 2014 23:14:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xoh78-0003at-P7;
	Wed, 12 Nov 2014 23:14:14 +0000
Date: Wed, 12 Nov 2014 23:14:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31500-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31500: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31500 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31500/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 31476
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 31461
 test-i386-i386-pair           7 xen-boot/src_host           fail pass in 31476
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-amd64-i386-xl-multivcpu  5 xen-boot           fail in 31476 pass in 31500
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot     fail in 31476 pass in 31500
 test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail in 31476 pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31500
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31500
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31500

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31461 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-sedf host-install(3)

Not pushing.

------------------------------------------------------------
commit c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 23:14:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 23:14:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoh7G-0007k5-DL; Wed, 12 Nov 2014 23:14:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xoh7E-0007k0-8n
	for xen-devel@lists.xensource.com; Wed, 12 Nov 2014 23:14:20 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	9A/C7-02699-BC9E3645; Wed, 12 Nov 2014 23:14:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415834057!7519650!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26905 invoked from network); 12 Nov 2014 23:14:18 -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;
	12 Nov 2014 23:14:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,371,1413244800"; d="scan'208";a="192186231"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 18:14:15 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xoh79-00067V-Fi;
	Wed, 12 Nov 2014 23:14:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xoh78-0003at-P7;
	Wed, 12 Nov 2014 23:14:14 +0000
Date: Wed, 12 Nov 2014 23:14:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31500-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31500: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31500 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31500/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 31476
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 31461
 test-i386-i386-pair           7 xen-boot/src_host           fail pass in 31476
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-amd64-i386-xl-multivcpu  5 xen-boot           fail in 31476 pass in 31500
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot     fail in 31476 pass in 31500
 test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail in 31476 pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31500
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31500
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31500

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31461 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-sedf host-install(3)

Not pushing.

------------------------------------------------------------
commit c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 12 23:52:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 23: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 1Xohhm-0008SN-DF; Wed, 12 Nov 2014 23:52:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amaro@gatech.edu>) id 1Xohhl-0008SI-IS
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 23:52:05 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	3C/1D-02697-4A2F3645; Wed, 12 Nov 2014 23:52:04 +0000
X-Env-Sender: amaro@gatech.edu
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415836322!11011514!1
X-Originating-IP: [207.46.100.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19542 invoked from network); 12 Nov 2014 23:52:04 -0000
Received: from mail-by2on0134.outbound.protection.outlook.com (HELO
	na01-by2-obe.outbound.protection.outlook.com) (207.46.100.134)
	by server-4.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Nov 2014 23:52:04 -0000
Received: from BY1PR0701MB1096.namprd07.prod.outlook.com (25.160.104.18) by
	BY1PR0701MB1094.namprd07.prod.outlook.com (25.160.104.16) with
	Microsoft SMTP
	Server (TLS) id 15.1.16.15; Wed, 12 Nov 2014 23:52:01 +0000
Received: from BY1PR0701MB1096.namprd07.prod.outlook.com ([25.160.104.18]) by
	BY1PR0701MB1096.namprd07.prod.outlook.com ([25.160.104.18]) with
	mapi id 15.01.0016.006; Wed, 12 Nov 2014 23:52:01 +0000
From: "Amaro, Emmanuel" <amaro@gatech.edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: About sharing pages between Xen and guest kernel
Thread-Index: AQHP/tOmjBjc4qz+eE2pZyw+Z209KQ==
Date: Wed, 12 Nov 2014 23:52:00 +0000
Message-ID: <625C2CDC-8017-43A4-A363-661697394945@gatech.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.61.63.34]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0701MB1094;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:;
	SRVR:BY1PR0701MB1094; 
x-forefront-prvs: 03932714EB
x-forefront-antispam-report: SFV:NSPM;
	SFS:(10019020)(6009001)(189002)(199003)(40764003)(50986999)(86362001)(92566001)(92726001)(89122001)(99396003)(54356999)(46102003)(120916001)(101416001)(82746002)(75432002)(36756003)(110136001)(229853001)(107046002)(2351001)(107886001)(62966003)(4396001)(77156002)(77096003)(90282001)(21056001)(450100001)(88552001)(40100003)(122556002)(31966008)(87936001)(99286002)(97736003)(83716003)(95666004)(2656002)(33656002)(20776003)(106356001)(106116001)(64706001)(66066001)(105586002)(104396001);
	DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0701MB1094;
	H:BY1PR0701MB1096.namprd07.prod.outlook.com; FPR:; MLV:sfv;
	PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-ID: <BEA3AE4D6384274CA58B7E1887E40BDC@namprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: gatech.edu
Subject: [Xen-devel] About sharing pages between Xen and guest kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8sDQoNCkkgYW0gdHJ5aW5nIHRvIHNldCB1cCBhIHNoYXJlZCBwYWdlIGJldHdlZW4gdGhl
IGh5cGVydmlzb3IgYW5kIGEgTGludXggZ3Vlc3Qga2VybmVsLiBJbiBYZW4gSSBhbSBkb2luZzoN
Cg0Kdm9pZCAqcHRyID0gYWxsb2NfeGVuaGVhcF9wYWdlKCk7DQpzaGFyZV94ZW5fcGFnZV93aXRo
X2d1ZXN0KHZpcnRfdG9fcGFnZShwdHIpLCBjdXJyZW50LT5kb21haW4sIFhFTlNIQVJFX3dyaXRh
YmxlKTsNCnVuc2lnbmVkIGludCBtZm4gPSB2aXJ0X3RvX21mbihwdHIpOw0KDQpBbmQgbXkgcGxh
biB3YXMgdG8gcGFzcyB0aGUgbWZuIHRvIHRoZSBndWVzdCBrZXJuZWwgYW5kIHJldHJpZXZlIHRo
ZSBwZm4gd2l0aCBtZm5fdG9fcGZuKCkuIEhvd2V2ZXIsIHRoaXMgcmV0dXJuZWQgfjAuIA0KDQpT
byBJIHRvb2sgYSBsb29rIGF0IHNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3QoKSBhbmQgSSBub3Rp
Y2VkIGl0IGNhbGxzIHNldF9ncGZuX2Zyb21fbWZuKG1mbiwgSU5WQUxJRF9NMlBfRU5UUlkpLCAN
CndoZXJlIElOVkFMSURfTTJQX0VOVFJZID0gfjAuDQoNCk15IHF1ZXN0aW9ucyBhcmU6DQoJMS4g
RG8gSSBoYXZlIHRvIGNhbGwgc2V0X2dwZm5fZnJvbV9tZm4oKSBhZnRlciBjYWxsaW5nIHNoYXJl
X3hlbl9wYWdlX3dpdGhfZ3Vlc3QoKSBpbiB0aGUgaHlwZXJ2aXNvcj8NCgkyLiBJZiB5ZXMsIHdo
YXQgZ3BmbiBzaG91bGQgSSB1c2U/IEkgYW0gdGhpbmtpbmcgSSBjb3VsZCBhbGxvY2F0ZSBhIHBh
Z2UgaW4gdGhlIGd1ZXN0LCBhbmQgcmV0cmlldmUgdGhlIHBmbiB3aXRoIHBhZ2VfdG9fcGZuKCks
IA0KCWFuZCB0aGVuIHBhc3MgdGhhdCB0byB0aGUgaHlwZXJ2aXNvci4gQnV0IEkgZG9u4oCZdCBr
bm93IGlmIEkgYW0gb3ZlcmNvbXBsaWNhdGluZyB0aGluZ3MuDQoNClRoYW5rIHlvdSBmb3IgeW91
ciBoZWxwLA0KRW1tYW51ZWwKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Nov 12 23:52:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Nov 2014 23: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 1Xohhm-0008SN-DF; Wed, 12 Nov 2014 23:52:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amaro@gatech.edu>) id 1Xohhl-0008SI-IS
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 23:52:05 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	3C/1D-02697-4A2F3645; Wed, 12 Nov 2014 23:52:04 +0000
X-Env-Sender: amaro@gatech.edu
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415836322!11011514!1
X-Originating-IP: [207.46.100.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19542 invoked from network); 12 Nov 2014 23:52:04 -0000
Received: from mail-by2on0134.outbound.protection.outlook.com (HELO
	na01-by2-obe.outbound.protection.outlook.com) (207.46.100.134)
	by server-4.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Nov 2014 23:52:04 -0000
Received: from BY1PR0701MB1096.namprd07.prod.outlook.com (25.160.104.18) by
	BY1PR0701MB1094.namprd07.prod.outlook.com (25.160.104.16) with
	Microsoft SMTP
	Server (TLS) id 15.1.16.15; Wed, 12 Nov 2014 23:52:01 +0000
Received: from BY1PR0701MB1096.namprd07.prod.outlook.com ([25.160.104.18]) by
	BY1PR0701MB1096.namprd07.prod.outlook.com ([25.160.104.18]) with
	mapi id 15.01.0016.006; Wed, 12 Nov 2014 23:52:01 +0000
From: "Amaro, Emmanuel" <amaro@gatech.edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: About sharing pages between Xen and guest kernel
Thread-Index: AQHP/tOmjBjc4qz+eE2pZyw+Z209KQ==
Date: Wed, 12 Nov 2014 23:52:00 +0000
Message-ID: <625C2CDC-8017-43A4-A363-661697394945@gatech.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.61.63.34]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0701MB1094;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:;
	SRVR:BY1PR0701MB1094; 
x-forefront-prvs: 03932714EB
x-forefront-antispam-report: SFV:NSPM;
	SFS:(10019020)(6009001)(189002)(199003)(40764003)(50986999)(86362001)(92566001)(92726001)(89122001)(99396003)(54356999)(46102003)(120916001)(101416001)(82746002)(75432002)(36756003)(110136001)(229853001)(107046002)(2351001)(107886001)(62966003)(4396001)(77156002)(77096003)(90282001)(21056001)(450100001)(88552001)(40100003)(122556002)(31966008)(87936001)(99286002)(97736003)(83716003)(95666004)(2656002)(33656002)(20776003)(106356001)(106116001)(64706001)(66066001)(105586002)(104396001);
	DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0701MB1094;
	H:BY1PR0701MB1096.namprd07.prod.outlook.com; FPR:; MLV:sfv;
	PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-ID: <BEA3AE4D6384274CA58B7E1887E40BDC@namprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: gatech.edu
Subject: [Xen-devel] About sharing pages between Xen and guest kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8sDQoNCkkgYW0gdHJ5aW5nIHRvIHNldCB1cCBhIHNoYXJlZCBwYWdlIGJldHdlZW4gdGhl
IGh5cGVydmlzb3IgYW5kIGEgTGludXggZ3Vlc3Qga2VybmVsLiBJbiBYZW4gSSBhbSBkb2luZzoN
Cg0Kdm9pZCAqcHRyID0gYWxsb2NfeGVuaGVhcF9wYWdlKCk7DQpzaGFyZV94ZW5fcGFnZV93aXRo
X2d1ZXN0KHZpcnRfdG9fcGFnZShwdHIpLCBjdXJyZW50LT5kb21haW4sIFhFTlNIQVJFX3dyaXRh
YmxlKTsNCnVuc2lnbmVkIGludCBtZm4gPSB2aXJ0X3RvX21mbihwdHIpOw0KDQpBbmQgbXkgcGxh
biB3YXMgdG8gcGFzcyB0aGUgbWZuIHRvIHRoZSBndWVzdCBrZXJuZWwgYW5kIHJldHJpZXZlIHRo
ZSBwZm4gd2l0aCBtZm5fdG9fcGZuKCkuIEhvd2V2ZXIsIHRoaXMgcmV0dXJuZWQgfjAuIA0KDQpT
byBJIHRvb2sgYSBsb29rIGF0IHNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3QoKSBhbmQgSSBub3Rp
Y2VkIGl0IGNhbGxzIHNldF9ncGZuX2Zyb21fbWZuKG1mbiwgSU5WQUxJRF9NMlBfRU5UUlkpLCAN
CndoZXJlIElOVkFMSURfTTJQX0VOVFJZID0gfjAuDQoNCk15IHF1ZXN0aW9ucyBhcmU6DQoJMS4g
RG8gSSBoYXZlIHRvIGNhbGwgc2V0X2dwZm5fZnJvbV9tZm4oKSBhZnRlciBjYWxsaW5nIHNoYXJl
X3hlbl9wYWdlX3dpdGhfZ3Vlc3QoKSBpbiB0aGUgaHlwZXJ2aXNvcj8NCgkyLiBJZiB5ZXMsIHdo
YXQgZ3BmbiBzaG91bGQgSSB1c2U/IEkgYW0gdGhpbmtpbmcgSSBjb3VsZCBhbGxvY2F0ZSBhIHBh
Z2UgaW4gdGhlIGd1ZXN0LCBhbmQgcmV0cmlldmUgdGhlIHBmbiB3aXRoIHBhZ2VfdG9fcGZuKCks
IA0KCWFuZCB0aGVuIHBhc3MgdGhhdCB0byB0aGUgaHlwZXJ2aXNvci4gQnV0IEkgZG9u4oCZdCBr
bm93IGlmIEkgYW0gb3ZlcmNvbXBsaWNhdGluZyB0aGluZ3MuDQoNClRoYW5rIHlvdSBmb3IgeW91
ciBoZWxwLA0KRW1tYW51ZWwKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Nov 13 01:03:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 01:03:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoion-0005eY-8i; Thu, 13 Nov 2014 01:03:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1Xoiol-0005eT-Hg
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 01:03:23 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	13/85-28865-A5304645; Thu, 13 Nov 2014 01:03:22 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415840600!7645183!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8498 invoked from network); 13 Nov 2014 01:03:21 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-15.tower-206.messagelabs.com with SMTP;
	13 Nov 2014 01:03:21 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 12 Nov 2014 16:56:44 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,372,1413270000"; d="scan'208";a="621535180"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 12 Nov 2014 17:01:22 -0800
Date: Thu, 13 Nov 2014 09:01:21 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141113010121.GA3106@pengc-linux.bj.intel.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
	<1415790652.29592.3.camel@citrix.com>
	<20141112152207.GF6017@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112152207.GF6017@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dongxiao Xu <dongxiao.xu@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
 libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Chao Peng <chao.p.peng@linux.intel.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 10:22:07AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 11:10:52AM +0000, Ian Campbell wrote:
> > CCing the folks who signed-of-by is on the original patch
> > 
> > On Wed, 2014-11-12 at 11:05 +0000, Wei Liu wrote:
> > > The `if' statement considered return value 0 from libxl_domain_info an
> > > error, while 0 actually means success.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > ---
> > > This is a bug fix for PSR feature. This feature was added recently and it's
> > > not an regression. However, it would be good to have it working correctly
> > > since the beginning, and the fix is straightforward, which should be of
> > > very low risk.
> > 
> > Ack.
> 
> I concur and I think it should go in Xen 4.5, but I would like their
> input first.

Yeah, I'd like it to go in.
Thanks Wei for your quick fix.

Chao
> 
> > 
> > > ---
> > >  tools/libxl/xl_cmdimpl.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > > index 3c9f146..9afef3f 100644
> > > --- a/tools/libxl/xl_cmdimpl.c
> > > +++ b/tools/libxl/xl_cmdimpl.c
> > > @@ -7908,7 +7908,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
> > >      /* Each domain */
> > >      if (domid != INVALID_DOMID) {
> > >          libxl_dominfo dominfo;
> > > -        if (!libxl_domain_info(ctx, &dominfo, domid)) {
> > > +        if (libxl_domain_info(ctx, &dominfo, domid)) {
> > >              fprintf(stderr, "Failed to get domain info for %d\n", domid);
> > >              return -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 Nov 13 01:03:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 01:03:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoion-0005eY-8i; Thu, 13 Nov 2014 01:03:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1Xoiol-0005eT-Hg
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 01:03:23 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	13/85-28865-A5304645; Thu, 13 Nov 2014 01:03:22 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415840600!7645183!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8498 invoked from network); 13 Nov 2014 01:03:21 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-15.tower-206.messagelabs.com with SMTP;
	13 Nov 2014 01:03:21 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 12 Nov 2014 16:56:44 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,372,1413270000"; d="scan'208";a="621535180"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 12 Nov 2014 17:01:22 -0800
Date: Thu, 13 Nov 2014 09:01:21 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141113010121.GA3106@pengc-linux.bj.intel.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
	<1415790652.29592.3.camel@citrix.com>
	<20141112152207.GF6017@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112152207.GF6017@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dongxiao Xu <dongxiao.xu@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
 libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Chao Peng <chao.p.peng@linux.intel.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 10:22:07AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 11:10:52AM +0000, Ian Campbell wrote:
> > CCing the folks who signed-of-by is on the original patch
> > 
> > On Wed, 2014-11-12 at 11:05 +0000, Wei Liu wrote:
> > > The `if' statement considered return value 0 from libxl_domain_info an
> > > error, while 0 actually means success.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > ---
> > > This is a bug fix for PSR feature. This feature was added recently and it's
> > > not an regression. However, it would be good to have it working correctly
> > > since the beginning, and the fix is straightforward, which should be of
> > > very low risk.
> > 
> > Ack.
> 
> I concur and I think it should go in Xen 4.5, but I would like their
> input first.

Yeah, I'd like it to go in.
Thanks Wei for your quick fix.

Chao
> 
> > 
> > > ---
> > >  tools/libxl/xl_cmdimpl.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > > index 3c9f146..9afef3f 100644
> > > --- a/tools/libxl/xl_cmdimpl.c
> > > +++ b/tools/libxl/xl_cmdimpl.c
> > > @@ -7908,7 +7908,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
> > >      /* Each domain */
> > >      if (domid != INVALID_DOMID) {
> > >          libxl_dominfo dominfo;
> > > -        if (!libxl_domain_info(ctx, &dominfo, domid)) {
> > > +        if (libxl_domain_info(ctx, &dominfo, domid)) {
> > >              fprintf(stderr, "Failed to get domain info for %d\n", domid);
> > >              return -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 Nov 13 01:08:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 01: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 1Xoiu0-0005my-3j; Thu, 13 Nov 2014 01:08:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xoity-0005mt-T8
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 01:08:47 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	39/B4-17958-E9404645; Thu, 13 Nov 2014 01:08:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415840924!11036062!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5448 invoked from network); 13 Nov 2014 01:08:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 01:08:45 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAD18QSI010281
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 01:08:27 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAD18Pdv025127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 01:08:26 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAD18Puv025123; Thu, 13 Nov 2014 01:08:25 GMT
Received: from [IPv6:2607:fb90:e19:ec57:2be0:9f26:3b5c:68f4] (/172.56.23.242)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 17:08:25 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <20141113010121.GA3106@pengc-linux.bj.intel.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
	<1415790652.29592.3.camel@citrix.com>
	<20141112152207.GF6017@laptop.dumpdata.com>
	<20141113010121.GA3106@pengc-linux.bj.intel.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 12 Nov 2014 20:08:01 -0500
To: Chao Peng <chao.p.peng@linux.intel.com>
Message-ID: <4B8ABDC6-FF30-43B7-897B-7435D7433324@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dongxiao Xu <dongxiao.xu@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
	libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 12, 2014 8:01:21 PM EST, Chao Peng <chao.p.peng@linux.intel.com> wrote:
>On Wed, Nov 12, 2014 at 10:22:07AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Wed, Nov 12, 2014 at 11:10:52AM +0000, Ian Campbell wrote:
>> > CCing the folks who signed-of-by is on the original patch
>> > 
>> > On Wed, 2014-11-12 at 11:05 +0000, Wei Liu wrote:
>> > > The `if' statement considered return value 0 from
>libxl_domain_info an
>> > > error, while 0 actually means success.
>> > > 
>> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> > 
>> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
>> > 
>> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> > > ---
>> > > This is a bug fix for PSR feature. This feature was added
>recently and it's
>> > > not an regression. However, it would be good to have it working
>correctly
>> > > since the beginning, and the fix is straightforward, which should
>be of
>> > > very low risk.
>> > 
>> > Ack.
>> 
>> I concur and I think it should go in Xen 4.5, but I would like their
>> input first.
>
>Yeah, I'd like it to go in.
>Thanks Wei for your quick fix.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
>Chao
>> 
>> > 
>> > > ---
>> > >  tools/libxl/xl_cmdimpl.c |    2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > > 
>> > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> > > index 3c9f146..9afef3f 100644
>> > > --- a/tools/libxl/xl_cmdimpl.c
>> > > +++ b/tools/libxl/xl_cmdimpl.c
>> > > @@ -7908,7 +7908,7 @@ static int
>psr_cmt_show_cache_occupancy(uint32_t domid)
>> > >      /* Each domain */
>> > >      if (domid != INVALID_DOMID) {
>> > >          libxl_dominfo dominfo;
>> > > -        if (!libxl_domain_info(ctx, &dominfo, domid)) {
>> > > +        if (libxl_domain_info(ctx, &dominfo, domid)) {
>> > >              fprintf(stderr, "Failed to get domain info for
>%d\n", domid);
>> > >              return -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 Nov 13 01:08:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 01: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 1Xoiu0-0005my-3j; Thu, 13 Nov 2014 01:08:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xoity-0005mt-T8
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 01:08:47 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	39/B4-17958-E9404645; Thu, 13 Nov 2014 01:08:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415840924!11036062!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5448 invoked from network); 13 Nov 2014 01:08:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 01:08:45 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAD18QSI010281
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 01:08:27 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAD18Pdv025127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 01:08:26 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAD18Puv025123; Thu, 13 Nov 2014 01:08:25 GMT
Received: from [IPv6:2607:fb90:e19:ec57:2be0:9f26:3b5c:68f4] (/172.56.23.242)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Nov 2014 17:08:25 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <20141113010121.GA3106@pengc-linux.bj.intel.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
	<1415790652.29592.3.camel@citrix.com>
	<20141112152207.GF6017@laptop.dumpdata.com>
	<20141113010121.GA3106@pengc-linux.bj.intel.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 12 Nov 2014 20:08:01 -0500
To: Chao Peng <chao.p.peng@linux.intel.com>
Message-ID: <4B8ABDC6-FF30-43B7-897B-7435D7433324@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dongxiao Xu <dongxiao.xu@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
	libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 12, 2014 8:01:21 PM EST, Chao Peng <chao.p.peng@linux.intel.com> wrote:
>On Wed, Nov 12, 2014 at 10:22:07AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Wed, Nov 12, 2014 at 11:10:52AM +0000, Ian Campbell wrote:
>> > CCing the folks who signed-of-by is on the original patch
>> > 
>> > On Wed, 2014-11-12 at 11:05 +0000, Wei Liu wrote:
>> > > The `if' statement considered return value 0 from
>libxl_domain_info an
>> > > error, while 0 actually means success.
>> > > 
>> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> > 
>> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
>> > 
>> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> > > ---
>> > > This is a bug fix for PSR feature. This feature was added
>recently and it's
>> > > not an regression. However, it would be good to have it working
>correctly
>> > > since the beginning, and the fix is straightforward, which should
>be of
>> > > very low risk.
>> > 
>> > Ack.
>> 
>> I concur and I think it should go in Xen 4.5, but I would like their
>> input first.
>
>Yeah, I'd like it to go in.
>Thanks Wei for your quick fix.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
>Chao
>> 
>> > 
>> > > ---
>> > >  tools/libxl/xl_cmdimpl.c |    2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > > 
>> > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> > > index 3c9f146..9afef3f 100644
>> > > --- a/tools/libxl/xl_cmdimpl.c
>> > > +++ b/tools/libxl/xl_cmdimpl.c
>> > > @@ -7908,7 +7908,7 @@ static int
>psr_cmt_show_cache_occupancy(uint32_t domid)
>> > >      /* Each domain */
>> > >      if (domid != INVALID_DOMID) {
>> > >          libxl_dominfo dominfo;
>> > > -        if (!libxl_domain_info(ctx, &dominfo, domid)) {
>> > > +        if (libxl_domain_info(ctx, &dominfo, domid)) {
>> > >              fprintf(stderr, "Failed to get domain info for
>%d\n", domid);
>> > >              return -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 Nov 13 01:26:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 01:26:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XojAw-0006DQ-OW; Thu, 13 Nov 2014 01:26:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XojAv-0006DL-BA
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 01:26:17 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	34/D1-18267-8B804645; Thu, 13 Nov 2014 01:26:16 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415841974!10995731!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24729 invoked from network); 13 Nov 2014 01:26:15 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-31.messagelabs.com with SMTP;
	13 Nov 2014 01:26:15 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 12 Nov 2014 17:25:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,372,1413270000"; d="scan'208";a="621543067"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by fmsmga001.fm.intel.com with ESMTP; 12 Nov 2014 17:25:14 -0800
Received: from pgsmsx107.gar.corp.intel.com (10.221.44.105) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 09:22:55 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 09:22:51 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id
	14.03.0195.001; Thu, 13 Nov 2014 09:22:50 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Wei Liu <wei.liu2@citrix.com>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/mjefTK2tVGKjEKQqz2i/Cq1Ppxdwy3Q
Date: Thu, 13 Nov 2014 01:22:49 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A5BF5D@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<20141112110722.GC25821@zion.uk.xensource.com>
In-Reply-To: <20141112110722.GC25821@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Wednesday, November 12, 2014 7:07 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; JBeulich@suse.com; wei.liu2@citrix.com
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> > Hi All,
> >
> > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> >
> 
> > 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
> 
> See <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
Thanks for this info. However, what does this link refers to? It is read as 'mailto' link by my mail client. anything missing?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 01:26:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 01:26:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XojAw-0006DQ-OW; Thu, 13 Nov 2014 01:26:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XojAv-0006DL-BA
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 01:26:17 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	34/D1-18267-8B804645; Thu, 13 Nov 2014 01:26:16 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415841974!10995731!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24729 invoked from network); 13 Nov 2014 01:26:15 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-31.messagelabs.com with SMTP;
	13 Nov 2014 01:26:15 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 12 Nov 2014 17:25:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,372,1413270000"; d="scan'208";a="621543067"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by fmsmga001.fm.intel.com with ESMTP; 12 Nov 2014 17:25:14 -0800
Received: from pgsmsx107.gar.corp.intel.com (10.221.44.105) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 09:22:55 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 09:22:51 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id
	14.03.0195.001; Thu, 13 Nov 2014 09:22:50 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Wei Liu <wei.liu2@citrix.com>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/mjefTK2tVGKjEKQqz2i/Cq1Ppxdwy3Q
Date: Thu, 13 Nov 2014 01:22:49 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A5BF5D@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<20141112110722.GC25821@zion.uk.xensource.com>
In-Reply-To: <20141112110722.GC25821@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Wednesday, November 12, 2014 7:07 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; JBeulich@suse.com; wei.liu2@citrix.com
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> > Hi All,
> >
> > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> >
> 
> > 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
> >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
> 
> See <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
Thanks for this info. However, what does this link refers to? It is read as 'mailto' link by my mail client. anything missing?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 01:56:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 01:56:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XojeJ-0006sk-KZ; Thu, 13 Nov 2014 01:56:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XojeH-0006sf-Lp
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 01:56:37 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	DD/EC-02702-4DF04645; Thu, 13 Nov 2014 01:56:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415843794!6763820!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25222 invoked from network); 13 Nov 2014 01:56:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 01:56:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,372,1413244800"; d="scan'208";a="192225921"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 20:56:33 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XojeD-0006v4-2e;
	Thu, 13 Nov 2014 01:56:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XojeC-0001fw-O6;
	Thu, 13 Nov 2014 01:56:32 +0000
Date: Thu, 13 Nov 2014 01:56:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31504-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31504: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31504 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31504/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755
 build-i386                    5 xen-build                 fail REGR. vs. 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 build-i386-rumpuserxen        1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       blocked 
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 01:56:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 01:56:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XojeJ-0006sk-KZ; Thu, 13 Nov 2014 01:56:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XojeH-0006sf-Lp
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 01:56:37 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	DD/EC-02702-4DF04645; Thu, 13 Nov 2014 01:56:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415843794!6763820!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25222 invoked from network); 13 Nov 2014 01:56:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 01:56:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,372,1413244800"; d="scan'208";a="192225921"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 20:56:33 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XojeD-0006v4-2e;
	Thu, 13 Nov 2014 01:56:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XojeC-0001fw-O6;
	Thu, 13 Nov 2014 01:56:32 +0000
Date: Thu, 13 Nov 2014 01:56:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31504-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31504: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31504 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31504/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755
 build-i386                    5 xen-build                 fail REGR. vs. 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 build-i386-rumpuserxen        1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       blocked 
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 2795 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 01:59:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 01: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 1Xojgs-0006z5-7V; Thu, 13 Nov 2014 01:59:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xojgr-0006yz-2p
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 01:59:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	24/8A-24532-47014645; Thu, 13 Nov 2014 01:59:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415843954!12304043!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16237 invoked from network); 13 Nov 2014 01:59:15 -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 Nov 2014 01:59:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,372,1413244800"; d="scan'208";a="190776217"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 20:59:12 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xojgm-0006vu-Jb;
	Thu, 13 Nov 2014 01:59:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xojgm-00029j-Eg;
	Thu, 13 Nov 2014 01:59:12 +0000
Date: Thu, 13 Nov 2014 01:59:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31508-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8218
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31508: 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: multipart/mixed; boundary="===============2171245856753590971=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2171245856753590971==
Content-Type: text/plain
Content-Length: 7944
Content-Transfer-Encoding: quoted-printable

flight 31508 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31508/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              cce8e5f7395fef5fa782910bc4a6fc8a786f8bc2
baseline version:
 libvirt              72f808c41fcc01f1eb01bde25538638ab7b115a3

------------------------------------------------------------
People who touched revisions under test:
  Hao Liu <hliu@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Wang Rui <moon.wangrui@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3Dcce8e5f7395fef5fa782910bc4a6fc8a786f8bc2
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt cce8e5f7395fef5fa782910bc4a6fc8a786f8bc2
+ branch=3Dlibvirt
+ revision=3Dcce8e5f7395fef5fa782910bc4a6fc8a786f8bc2
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git cce8e5f7395fef5fa782910bc4a6fc8a786f8bc2:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   72f808c..cce8e5f  cce8e5f7395fef5fa782910bc4a6fc8a786f8bc2 -> xen-tested-master


--===============2171245856753590971==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2171245856753590971==--

From xen-devel-bounces@lists.xen.org Thu Nov 13 01:59:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 01: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 1Xojgs-0006z5-7V; Thu, 13 Nov 2014 01:59:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xojgr-0006yz-2p
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 01:59:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	24/8A-24532-47014645; Thu, 13 Nov 2014 01:59:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415843954!12304043!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16237 invoked from network); 13 Nov 2014 01:59:15 -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 Nov 2014 01:59:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,372,1413244800"; d="scan'208";a="190776217"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 20:59:12 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xojgm-0006vu-Jb;
	Thu, 13 Nov 2014 01:59:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xojgm-00029j-Eg;
	Thu, 13 Nov 2014 01:59:12 +0000
Date: Thu, 13 Nov 2014 01:59:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31508-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8218
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31508: 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: multipart/mixed; boundary="===============2171245856753590971=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2171245856753590971==
Content-Type: text/plain
Content-Length: 7944
Content-Transfer-Encoding: quoted-printable

flight 31508 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31508/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              cce8e5f7395fef5fa782910bc4a6fc8a786f8bc2
baseline version:
 libvirt              72f808c41fcc01f1eb01bde25538638ab7b115a3

------------------------------------------------------------
People who touched revisions under test:
  Hao Liu <hliu@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Wang Rui <moon.wangrui@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3Dcce8e5f7395fef5fa782910bc4a6fc8a786f8bc2
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt cce8e5f7395fef5fa782910bc4a6fc8a786f8bc2
+ branch=3Dlibvirt
+ revision=3Dcce8e5f7395fef5fa782910bc4a6fc8a786f8bc2
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git cce8e5f7395fef5fa782910bc4a6fc8a786f8bc2:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   72f808c..cce8e5f  cce8e5f7395fef5fa782910bc4a6fc8a786f8bc2 -> xen-tested-master


--===============2171245856753590971==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2171245856753590971==--

From xen-devel-bounces@lists.xen.org Thu Nov 13 02:24:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 02:24:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xok58-00081p-DX; Thu, 13 Nov 2014 02:24:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1Xok56-00081k-Rh
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 02:24:20 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	83/A0-02707-35614645; Thu, 13 Nov 2014 02:24:19 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415845458!10997011!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5359 invoked from network); 13 Nov 2014 02:24:18 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-6.tower-206.messagelabs.com with SMTP;
	13 Nov 2014 02:24:18 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 12 Nov 2014 18:17:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,372,1413270000"; d="scan'208";a="621562485"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by fmsmga001.fm.intel.com with ESMTP; 12 Nov 2014 18:24:04 -0800
Received: from pgsmsx105.gar.corp.intel.com (10.221.44.96) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 10:23:27 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 10:23:26 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id
	14.03.0195.001; Thu, 13 Nov 2014 10:23:25 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [TestDay]Xen-4.5.0-RC1: Not all PFs are available if assign
	multi VT-d devices to Wndows guest VM
Thread-Index: Ac/+5h3idvKwTj22RNyafH8/l/k/wQ==
Date: Thu, 13 Nov 2014 02:23:25 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A5C024@SHSMSX103.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
Subject: [Xen-devel] [TestDay]Xen-4.5.0-RC1: Not all PFs are available if
 assign multi VT-d devices to Wndows guest VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This is a separated bug report for  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896.

Environment:
------------
Service Arch (ia32/ia32e/IA64): ia32e
Guest Arch (ia32/ia32e/IA64): ia32e
Guest OS Type (Linux/Windows): Windows8.1, Windows2012
Change Set: Xen4.5-RC1 (git:1b068a5b485062c862c20d8ba7674faa97ee3714)
Hardware: Ivybridge-EP, Grantley-EP
Other:PF device: I350, 82576, 82599


Bug detailed description:
--------------------------
Assign multi PF devices(I350, 82576, 82599) to installing Windows8.1 guest VM
with xl tool. After guest boot up, one PF could not get IP address and shows as
"Network cable unplugged", while other two PF devices could get IP address and
available.
If only assign this unavailable PF to Windows guest VM, it worked normally.
The issue could not be duplicated with multi VF devices assigned to Windows
guest VM. 

Reproduce steps:
----------------
1. Create a HVM guest config file with multi PF devices(I350, 82576, 82599)
assigned to installing Windows8.1 guest VM
2. Using xl tool to start guest with command "xl create hvm_config_file"
3. After guest boot up, check the network device, issue occurred.

Current result:
----------------
Assign muti PF devices to windows guest, at least one PF device is not
availabel.

Expected result:
----------------
All assigned PF devices should work normally under windows guest.

Best Regards,
Robert Ho


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 02:24:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 02:24:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xok58-00081p-DX; Thu, 13 Nov 2014 02:24:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1Xok56-00081k-Rh
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 02:24:20 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	83/A0-02707-35614645; Thu, 13 Nov 2014 02:24:19 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415845458!10997011!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5359 invoked from network); 13 Nov 2014 02:24:18 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-6.tower-206.messagelabs.com with SMTP;
	13 Nov 2014 02:24:18 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 12 Nov 2014 18:17:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,372,1413270000"; d="scan'208";a="621562485"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by fmsmga001.fm.intel.com with ESMTP; 12 Nov 2014 18:24:04 -0800
Received: from pgsmsx105.gar.corp.intel.com (10.221.44.96) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 10:23:27 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 10:23:26 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id
	14.03.0195.001; Thu, 13 Nov 2014 10:23:25 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [TestDay]Xen-4.5.0-RC1: Not all PFs are available if assign
	multi VT-d devices to Wndows guest VM
Thread-Index: Ac/+5h3idvKwTj22RNyafH8/l/k/wQ==
Date: Thu, 13 Nov 2014 02:23:25 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A5C024@SHSMSX103.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
Subject: [Xen-devel] [TestDay]Xen-4.5.0-RC1: Not all PFs are available if
 assign multi VT-d devices to Wndows guest VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This is a separated bug report for  http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896.

Environment:
------------
Service Arch (ia32/ia32e/IA64): ia32e
Guest Arch (ia32/ia32e/IA64): ia32e
Guest OS Type (Linux/Windows): Windows8.1, Windows2012
Change Set: Xen4.5-RC1 (git:1b068a5b485062c862c20d8ba7674faa97ee3714)
Hardware: Ivybridge-EP, Grantley-EP
Other:PF device: I350, 82576, 82599


Bug detailed description:
--------------------------
Assign multi PF devices(I350, 82576, 82599) to installing Windows8.1 guest VM
with xl tool. After guest boot up, one PF could not get IP address and shows as
"Network cable unplugged", while other two PF devices could get IP address and
available.
If only assign this unavailable PF to Windows guest VM, it worked normally.
The issue could not be duplicated with multi VF devices assigned to Windows
guest VM. 

Reproduce steps:
----------------
1. Create a HVM guest config file with multi PF devices(I350, 82576, 82599)
assigned to installing Windows8.1 guest VM
2. Using xl tool to start guest with command "xl create hvm_config_file"
3. After guest boot up, check the network device, issue occurred.

Current result:
----------------
Assign muti PF devices to windows guest, at least one PF device is not
availabel.

Expected result:
----------------
All assigned PF devices should work normally under windows guest.

Best Regards,
Robert Ho


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 02:34:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 02:34:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XokER-0008JR-Lr; Thu, 13 Nov 2014 02:33:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XokEP-0008JM-Qf
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 02:33:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	75/F7-24532-59814645; Thu, 13 Nov 2014 02:33:57 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415846035!12295948!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2622 invoked from network); 13 Nov 2014 02:33:56 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-4.tower-21.messagelabs.com with SMTP;
	13 Nov 2014 02:33:56 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 12 Nov 2014 18:31:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,373,1413270000"; d="scan'208";a="606998156"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 12 Nov 2014 18:33:37 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 10:32:12 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id
	14.03.0195.001; Thu, 13 Nov 2014 10:32:11 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [TestDay]Xen-4.5-RC1: Dom0 failed to resume from S3 power
	state with operations on '/sys/power/state'
Thread-Index: Ac/+6f8avc00iSTOQ3KKTWTVPPql0w==
Date: Thu, 13 Nov 2014 02:32:10 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A5E04A@SHSMSX103.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
Subject: [Xen-devel] [TestDay]Xen-4.5-RC1: Dom0 failed to resume from S3
 power state with operations on '/sys/power/state'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This is a separated report for bug http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897

Environment:
------------
Service Arch (ia32/ia32e/IA64): ia32e
Guest Arch (ia32/ia32e/IA64): 
Guest OS Type (Linux/Windows):
Change Set: Xen4.5-RC1 (git:1b068a5b485062c862c20d8ba7674faa97ee3714)
Hardware: Ivybridge-EP, Grantley-EP
Other:


Bug detailed description:
--------------------------
Boot into Dom0 (kernel 3.17.0), execute the command "echo mem > /sys/power/state", to make Dom0
system get into S3 sleep state, then press any key or power button to resume 
from S3
state, but failed and system hangs up with black screen.


Reproduce steps:
----------------
1. Boot into Dom0, execute the command "echo mem > /sys/power/state" to make
Dom0 get into S3 state.
2. Press any key  or press power button to resume from S3,no resume to dom0

Current result:
----------------
Dom0 system cannot resume from S3 power state.

Expected result:
----------------
Dom0 system should resume from S3 power state successfully.

Best Regards,
Robert Ho


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 02:34:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 02:34:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XokER-0008JR-Lr; Thu, 13 Nov 2014 02:33:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XokEP-0008JM-Qf
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 02:33:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	75/F7-24532-59814645; Thu, 13 Nov 2014 02:33:57 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415846035!12295948!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2622 invoked from network); 13 Nov 2014 02:33:56 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-4.tower-21.messagelabs.com with SMTP;
	13 Nov 2014 02:33:56 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 12 Nov 2014 18:31:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,373,1413270000"; d="scan'208";a="606998156"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 12 Nov 2014 18:33:37 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 10:32:12 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id
	14.03.0195.001; Thu, 13 Nov 2014 10:32:11 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [TestDay]Xen-4.5-RC1: Dom0 failed to resume from S3 power
	state with operations on '/sys/power/state'
Thread-Index: Ac/+6f8avc00iSTOQ3KKTWTVPPql0w==
Date: Thu, 13 Nov 2014 02:32:10 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A5E04A@SHSMSX103.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
Subject: [Xen-devel] [TestDay]Xen-4.5-RC1: Dom0 failed to resume from S3
 power state with operations on '/sys/power/state'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This is a separated report for bug http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897

Environment:
------------
Service Arch (ia32/ia32e/IA64): ia32e
Guest Arch (ia32/ia32e/IA64): 
Guest OS Type (Linux/Windows):
Change Set: Xen4.5-RC1 (git:1b068a5b485062c862c20d8ba7674faa97ee3714)
Hardware: Ivybridge-EP, Grantley-EP
Other:


Bug detailed description:
--------------------------
Boot into Dom0 (kernel 3.17.0), execute the command "echo mem > /sys/power/state", to make Dom0
system get into S3 sleep state, then press any key or power button to resume 
from S3
state, but failed and system hangs up with black screen.


Reproduce steps:
----------------
1. Boot into Dom0, execute the command "echo mem > /sys/power/state" to make
Dom0 get into S3 state.
2. Press any key  or press power button to resume from S3,no resume to dom0

Current result:
----------------
Dom0 system cannot resume from S3 power state.

Expected result:
----------------
Dom0 system should resume from S3 power state successfully.

Best Regards,
Robert Ho


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 02:42:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 02:42:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XokLz-0008W2-P8; Thu, 13 Nov 2014 02:41:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XokLz-0008VI-1P
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 02:41:47 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	A6/DB-02696-A6A14645; Thu, 13 Nov 2014 02:41:46 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415846504!12184066!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27070 invoked from network); 13 Nov 2014 02:41:44 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-27.messagelabs.com with SMTP;
	13 Nov 2014 02:41:44 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 12 Nov 2014 18:41:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,373,1413270000"; d="scan'208";a="631144917"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga002.fm.intel.com with ESMTP; 12 Nov 2014 18:41:41 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 10:40:32 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Thu, 13 Nov 2014 10:40:32 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/l9ZNIwAqiexHE6x0A+uPl9BJ5xd18qA
Date: Thu, 13 Nov 2014 02:40:31 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A5E067@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz>
In-Reply-To: <54632F72.7020509@m2r.biz>
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: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
> Sent: Wednesday, November 12, 2014 5:59 PM
> To: Hu, Robert; xen-devel@lists.xen.org
> Cc: JBeulich@suse.com
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> Il 12/11/2014 07:58, Hu, Robert ha scritto:
> > Hi All,
> >
> > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> >
> > Test environment:
> > Xen: Xen 4.5-rc1
> > Dom0: Linux kernel 3.17.0
> > Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP
> >
> > New bugs(9):
> > 1. with "xen_platform_pci=0" option, the guest with VT-d device fails to boot
> up
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1893
> 
> Have you tried with recent domU's kernel that contain this commit?
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a
> 3bbaca868043cc45b3ad3786dd48a90235
No, we test guest OS with their native kernels.
> If I remember good there is a critical boot problem with
> "xen_platform_pci=0" and without it.
In this test case scenario, guest boots up fine.
> 
> > 2. Failed to hotplug a VT-d device with XEN4.5-RC1
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> > 3. Fail to hot add multi devices to guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895
> > 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
> > 5. Dom0 failed to resume from S3 power state
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897
> > 6. Networking is unavailable after save&restore Windows guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> 
> Should be the same problem I reported 1 year ago or more and still
> present, the workaround is use fixed mac address in domUs xl cfg :(
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
> 
Thanks a lot for this info!
> > 7. Error msg occurred after attaching multi SR-IOV VF device to running guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899
> > 8. "xl vcpu-set " will report error when adding vcpus number
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1900
> > 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
> >
> > 1 old legacy bug(1):
> > 1. Guest hang after resume from S3
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1828
> >
> >
> > Best Regards,
> > Robert
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Nov 13 02:42:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 02:42:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XokLz-0008W2-P8; Thu, 13 Nov 2014 02:41:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XokLz-0008VI-1P
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 02:41:47 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	A6/DB-02696-A6A14645; Thu, 13 Nov 2014 02:41:46 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415846504!12184066!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27070 invoked from network); 13 Nov 2014 02:41:44 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-27.messagelabs.com with SMTP;
	13 Nov 2014 02:41:44 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 12 Nov 2014 18:41:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,373,1413270000"; d="scan'208";a="631144917"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga002.fm.intel.com with ESMTP; 12 Nov 2014 18:41:41 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 13 Nov 2014 10:40:32 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Thu, 13 Nov 2014 10:40:32 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/l9ZNIwAqiexHE6x0A+uPl9BJ5xd18qA
Date: Thu, 13 Nov 2014 02:40:31 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A5E067@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz>
In-Reply-To: <54632F72.7020509@m2r.biz>
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: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
> Sent: Wednesday, November 12, 2014 5:59 PM
> To: Hu, Robert; xen-devel@lists.xen.org
> Cc: JBeulich@suse.com
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> Il 12/11/2014 07:58, Hu, Robert ha scritto:
> > Hi All,
> >
> > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> >
> > Test environment:
> > Xen: Xen 4.5-rc1
> > Dom0: Linux kernel 3.17.0
> > Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP
> >
> > New bugs(9):
> > 1. with "xen_platform_pci=0" option, the guest with VT-d device fails to boot
> up
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1893
> 
> Have you tried with recent domU's kernel that contain this commit?
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a
> 3bbaca868043cc45b3ad3786dd48a90235
No, we test guest OS with their native kernels.
> If I remember good there is a critical boot problem with
> "xen_platform_pci=0" and without it.
In this test case scenario, guest boots up fine.
> 
> > 2. Failed to hotplug a VT-d device with XEN4.5-RC1
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> > 3. Fail to hot add multi devices to guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895
> > 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
> > 5. Dom0 failed to resume from S3 power state
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897
> > 6. Networking is unavailable after save&restore Windows guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> 
> Should be the same problem I reported 1 year ago or more and still
> present, the workaround is use fixed mac address in domUs xl cfg :(
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
> 
Thanks a lot for this info!
> > 7. Error msg occurred after attaching multi SR-IOV VF device to running guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899
> > 8. "xl vcpu-set " will report error when adding vcpus number
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1900
> > 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
> >
> > 1 old legacy bug(1):
> > 1. Guest hang after resume from S3
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1828
> >
> >
> > Best Regards,
> > Robert
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Nov 13 03:06:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 03:06:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xokje-0000fE-08; Thu, 13 Nov 2014 03:06:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xokjc-0000f9-Ju
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 03:06:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AC/80-09842-32024645; Thu, 13 Nov 2014 03:06:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415847970!4305458!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15546 invoked from network); 13 Nov 2014 03:06:11 -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 Nov 2014 03:06:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,373,1413244800"; d="scan'208";a="190790872"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 22:06:00 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XokjQ-0007G0-Ia;
	Thu, 13 Nov 2014 03:06:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XokjQ-0004NS-Ar;
	Thu, 13 Nov 2014 03:06:00 +0000
Date: Thu, 13 Nov 2014 03:06:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31507-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31507: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31507 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31507/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt       5 xen-boot                    fail pass in 31484
 test-armhf-armhf-libvirt      4 xen-install        fail in 31484 pass in 31507
 test-amd64-i386-xl         14 guest-localmigrate.2 fail in 31484 pass in 31507
 test-amd64-amd64-xl-winxpsp3 13 guest-localmigrate/x10 fail in 31484 pass in 31507

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-libvirt       9 guest-start           fail in 31484 never pass

version targeted for testing:
 linux                206c5f60a3d902bc4b56dab2de3e88de5eb06108
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
430 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 14843 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 03:06:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 03:06:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xokje-0000fE-08; Thu, 13 Nov 2014 03:06:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xokjc-0000f9-Ju
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 03:06:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AC/80-09842-32024645; Thu, 13 Nov 2014 03:06:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415847970!4305458!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15546 invoked from network); 13 Nov 2014 03:06:11 -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 Nov 2014 03:06:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,373,1413244800"; d="scan'208";a="190790872"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 12 Nov 2014 22:06:00 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XokjQ-0007G0-Ia;
	Thu, 13 Nov 2014 03:06:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XokjQ-0004NS-Ar;
	Thu, 13 Nov 2014 03:06:00 +0000
Date: Thu, 13 Nov 2014 03:06:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31507-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31507: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31507 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31507/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt       5 xen-boot                    fail pass in 31484
 test-armhf-armhf-libvirt      4 xen-install        fail in 31484 pass in 31507
 test-amd64-i386-xl         14 guest-localmigrate.2 fail in 31484 pass in 31507
 test-amd64-amd64-xl-winxpsp3 13 guest-localmigrate/x10 fail in 31484 pass in 31507

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-libvirt       9 guest-start           fail in 31484 never pass

version targeted for testing:
 linux                206c5f60a3d902bc4b56dab2de3e88de5eb06108
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
430 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 14843 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 03:07:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 03:07:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xokkb-0000ip-E0; Thu, 13 Nov 2014 03:07:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xokka-0000ih-6V
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 03:07:12 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	1A/5E-05632-F5024645; Thu, 13 Nov 2014 03:07:11 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415848028!11003565!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3168 invoked from network); 13 Nov 2014 03:07:09 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 03:07:09 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 20:07:07 -0700
Message-Id: <546490D40200006600079701@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 20:07:00 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Chun Yan Liu" <CYLiu@suse.com>,
 "George Dunlap" <dunlapg@umich.edu>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
	<5462343C020000660007880A@soto.provo.novell.com>
In-Reply-To: <5462343C020000660007880A@soto.provo.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 11/11/2014 at 04:07 PM, in message
<5462343C020000660007880A@soto.provo.novell.com>, "Chun Yan Liu"
<cyliu@suse.com> wrote: 

>  
>>>> On 11/11/2014 at 01:04 AM, in message 
> <CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>, George 
> Dunlap <dunlapg@umich.edu> wrote:  
> > On Mon, Nov 10, 2014 at 8:17 AM, Chunyan Liu <cyliu@suse.com> wrote:  
> >   
> > >  
> > > 3. Function Implementation  
> > >  
> > >    libxl_domain_snapshot_create:  
> > >        1). check args validation  
> > >        2). save domain memory through save-domain  
> > >        3). take disk snapshot by qmp command (if domian is active) or 
> > qemu-img  
> > >            command (if domain is inactive).  
> >   
> > By "active" here, do you you mean "live" (vs paused)? 
> Means the domain is started (no matter is running or paused). 
> vs (libvirt defines a domain but not started). 
> Here,  I should update this to: 
> 3). take disk snapshot by qmp command 
> libxl only handles active domain. 
>  
> >   
> > >    libxl_domain_snapshot_delete:  
> > >        1). check args validation  
> > >        2). remove memory state file.  
> > >        3). delete disk snapshot. (for internal disk snapshot, through qmp  
> > >            command or qemu-img command)  
> >   
> > Out of curiosity, why is this necessary?  Is libxl keeping track of  
> > the snapshots somewhere?  Or qemu?  
> >   
> > Or to put it a different way, since the caller knows the filenames,  
> > why can't the caller just erase the files themselves? 
>  
> Ian asks the same question. The only reason I propose an API is: 
> xl and libvirt can share the code. And in future, when support many other  
> disk 
> backend types, there is much repeated code. But as Ian mentioned in 
> last version, for handling many disk backend types, maybe better placed in 
> libxlu. Well, if both of you object, I'll remove this API. 

Similar to snapshot delete, for libxl_domain_snapshot_create, the work is
in fact: save memory by domain_save, and do disk snaphsot (by qmp, or
qemu-img can also do that). Considering xl only, not very necessary to have
a new libxl API? But xl and libvirt can share the code if wrapped in API.
So, which is preferred? Any opinion?

- Chunyan

>  
> >   
> >  -George  
> >   
> > _______________________________________________  
> > Xen-devel mailing list  
> > Xen-devel@lists.xen.org  
> > http://lists.xen.org/xen-devel  
> >   
> >   
>  
>  
>  
> _______________________________________________ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 03:07:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 03:07:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xokkb-0000ip-E0; Thu, 13 Nov 2014 03:07:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xokka-0000ih-6V
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 03:07:12 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	1A/5E-05632-F5024645; Thu, 13 Nov 2014 03:07:11 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415848028!11003565!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3168 invoked from network); 13 Nov 2014 03:07:09 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 03:07:09 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Wed, 12 Nov 2014 20:07:07 -0700
Message-Id: <546490D40200006600079701@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 12 Nov 2014 20:07:00 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Chun Yan Liu" <CYLiu@suse.com>,
 "George Dunlap" <dunlapg@umich.edu>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
	<5462343C020000660007880A@soto.provo.novell.com>
In-Reply-To: <5462343C020000660007880A@soto.provo.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 11/11/2014 at 04:07 PM, in message
<5462343C020000660007880A@soto.provo.novell.com>, "Chun Yan Liu"
<cyliu@suse.com> wrote: 

>  
>>>> On 11/11/2014 at 01:04 AM, in message 
> <CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>, George 
> Dunlap <dunlapg@umich.edu> wrote:  
> > On Mon, Nov 10, 2014 at 8:17 AM, Chunyan Liu <cyliu@suse.com> wrote:  
> >   
> > >  
> > > 3. Function Implementation  
> > >  
> > >    libxl_domain_snapshot_create:  
> > >        1). check args validation  
> > >        2). save domain memory through save-domain  
> > >        3). take disk snapshot by qmp command (if domian is active) or 
> > qemu-img  
> > >            command (if domain is inactive).  
> >   
> > By "active" here, do you you mean "live" (vs paused)? 
> Means the domain is started (no matter is running or paused). 
> vs (libvirt defines a domain but not started). 
> Here,  I should update this to: 
> 3). take disk snapshot by qmp command 
> libxl only handles active domain. 
>  
> >   
> > >    libxl_domain_snapshot_delete:  
> > >        1). check args validation  
> > >        2). remove memory state file.  
> > >        3). delete disk snapshot. (for internal disk snapshot, through qmp  
> > >            command or qemu-img command)  
> >   
> > Out of curiosity, why is this necessary?  Is libxl keeping track of  
> > the snapshots somewhere?  Or qemu?  
> >   
> > Or to put it a different way, since the caller knows the filenames,  
> > why can't the caller just erase the files themselves? 
>  
> Ian asks the same question. The only reason I propose an API is: 
> xl and libvirt can share the code. And in future, when support many other  
> disk 
> backend types, there is much repeated code. But as Ian mentioned in 
> last version, for handling many disk backend types, maybe better placed in 
> libxlu. Well, if both of you object, I'll remove this API. 

Similar to snapshot delete, for libxl_domain_snapshot_create, the work is
in fact: save memory by domain_save, and do disk snaphsot (by qmp, or
qemu-img can also do that). Considering xl only, not very necessary to have
a new libxl API? But xl and libvirt can share the code if wrapped in API.
So, which is preferred? Any opinion?

- Chunyan

>  
> >   
> >  -George  
> >   
> > _______________________________________________  
> > Xen-devel mailing list  
> > Xen-devel@lists.xen.org  
> > http://lists.xen.org/xen-devel  
> >   
> >   
>  
>  
>  
> _______________________________________________ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 03:09:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 03:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XokmT-0000rg-UL; Thu, 13 Nov 2014 03:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XokmS-0000rZ-LE
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 03:09:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	14/D1-09936-4D024645; Thu, 13 Nov 2014 03:09:08 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415848146!12299115!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11776 invoked from network); 13 Nov 2014 03:09:07 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-4.tower-21.messagelabs.com with SMTP;
	13 Nov 2014 03:09:07 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 12 Nov 2014 19:02:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="415783974"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.74])
	([10.238.130.74])
	by FMSMGA003.fm.intel.com with ESMTP; 12 Nov 2014 19:00:04 -0800
Message-ID: <546420CE.1080908@intel.com>
Date: Thu, 13 Nov 2014 11:09:02 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
In-Reply-To: <54632EA80200007800046AE5@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/12 16:55, Jan Beulich wrote:
>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>> I don't see any feedback to this point, so I think you still prefer we
>> should do all check in the callback function.
>
> As a draft this looks reasonable, but there are various bugs to be
> dealt with along with cosmetic issues (I'll point out the former, but
> I'm tired of pointing out the latter once again - please go back to
> earlier reviews of patches to refresh e.g. what types to use for
> loop variables).
>
>> I tried to address this but obviously we have to pass each 'pdf' to
>> callback functions,
>
> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
> but something more neutral (maybe "id"). And you again lost the
> segment there.
>
>> @@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
>>            if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>>                return -ERANGE;
>>
>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> -                                     &rdm, 1) )
>> -            return -EFAULT;
>> +        if ( d->arch.hvm_domain.pci_force )
>> +        {
>> +            if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                         &rdm, 1) )
>> +                return -EFAULT;
>> +        }
>> +        else
>> +        {
>> +            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
>> +            {
>> +                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
>> +                                  d->arch.hvm_domain.pcidevs[i].devfn);
>> +                if ( pt_bdf == bdf )
>> +                    if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                                 &rdm, 1) )
>> +                        return -EFAULT;
>
> I think d->arch.hvm_domain.pcidevs[] shouldn't contain duplicates,
> and hence there's no point continuing the loop if you found a match.
>

I take a look at this again. Seems we shouldn't just check bdf since as 
you know its possible to occupy one entry by multiple different BDFs, so 
we have to filter-to-keep one entry. Instead, I really hope we'd check 
to expose before we do the hypercall.

BTW, I already ping Yang in local to look that possibility to reorder 
the sequence of the device assignment and the memory population in iommu 
side.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 03:09:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 03:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XokmT-0000rg-UL; Thu, 13 Nov 2014 03:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XokmS-0000rZ-LE
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 03:09:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	14/D1-09936-4D024645; Thu, 13 Nov 2014 03:09:08 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415848146!12299115!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11776 invoked from network); 13 Nov 2014 03:09:07 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-4.tower-21.messagelabs.com with SMTP;
	13 Nov 2014 03:09:07 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 12 Nov 2014 19:02:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="415783974"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.74])
	([10.238.130.74])
	by FMSMGA003.fm.intel.com with ESMTP; 12 Nov 2014 19:00:04 -0800
Message-ID: <546420CE.1080908@intel.com>
Date: Thu, 13 Nov 2014 11:09:02 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
In-Reply-To: <54632EA80200007800046AE5@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/12 16:55, Jan Beulich wrote:
>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>> I don't see any feedback to this point, so I think you still prefer we
>> should do all check in the callback function.
>
> As a draft this looks reasonable, but there are various bugs to be
> dealt with along with cosmetic issues (I'll point out the former, but
> I'm tired of pointing out the latter once again - please go back to
> earlier reviews of patches to refresh e.g. what types to use for
> loop variables).
>
>> I tried to address this but obviously we have to pass each 'pdf' to
>> callback functions,
>
> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
> but something more neutral (maybe "id"). And you again lost the
> segment there.
>
>> @@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
>>            if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>>                return -ERANGE;
>>
>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> -                                     &rdm, 1) )
>> -            return -EFAULT;
>> +        if ( d->arch.hvm_domain.pci_force )
>> +        {
>> +            if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                         &rdm, 1) )
>> +                return -EFAULT;
>> +        }
>> +        else
>> +        {
>> +            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
>> +            {
>> +                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
>> +                                  d->arch.hvm_domain.pcidevs[i].devfn);
>> +                if ( pt_bdf == bdf )
>> +                    if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                                 &rdm, 1) )
>> +                        return -EFAULT;
>
> I think d->arch.hvm_domain.pcidevs[] shouldn't contain duplicates,
> and hence there's no point continuing the loop if you found a match.
>

I take a look at this again. Seems we shouldn't just check bdf since as 
you know its possible to occupy one entry by multiple different BDFs, so 
we have to filter-to-keep one entry. Instead, I really hope we'd check 
to expose before we do the hypercall.

BTW, I already ping Yang in local to look that possibility to reorder 
the sequence of the device assignment and the memory population in iommu 
side.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 05:39:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 05: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 1Xon7P-0004zu-3U; Thu, 13 Nov 2014 05:38:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liangx.z.li@intel.com>) id 1Xon7M-0004zp-Bu
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 05:38:52 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	40/01-16982-BE344645; Thu, 13 Nov 2014 05:38:51 +0000
X-Env-Sender: liangx.z.li@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415857130!11016028!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 320 invoked from network); 13 Nov 2014 05:38:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-31.messagelabs.com with SMTP;
	13 Nov 2014 05:38:50 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 12 Nov 2014 21:38:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,374,1413270000"; d="scan'208";a="636183234"
Received: from lil.sh.intel.com (HELO localhost) ([10.239.36.68])
	by orsmga002.jf.intel.com with ESMTP; 12 Nov 2014 21:38:17 -0800
From: Li Liang <liang.z.li@intel.com>
To: xen-devel@lists.xen.org
Date: Thu, 13 Nov 2014 13:31:17 +0800
Message-Id: <1415856677-25814-1-git-send-email-liang.z.li@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com,
	Li Liang <liang.z.li@intel.com>, ian.jackson@eu.citrix.com,
	yang.z.zhang@intel.com
Subject: [Xen-devel] [PATCH] libxc: Turn on the pdpe1gb cpuid flag by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 it's no need to set the "cpuid= " option in the config file
to expose the 1GB hugepage feature to guest.

Signed-off-by: Li Liang <liang.z.li@intel.com>
---
 tools/libxc/xc_cpuid_x86.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index a18b1ff..561c5b5 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -192,6 +192,7 @@ static void intel_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_ABM));
         regs[3] &= (bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_RDTSCP));
         break;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 05:39:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 05: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 1Xon7P-0004zu-3U; Thu, 13 Nov 2014 05:38:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liangx.z.li@intel.com>) id 1Xon7M-0004zp-Bu
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 05:38:52 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	40/01-16982-BE344645; Thu, 13 Nov 2014 05:38:51 +0000
X-Env-Sender: liangx.z.li@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415857130!11016028!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 320 invoked from network); 13 Nov 2014 05:38:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-31.messagelabs.com with SMTP;
	13 Nov 2014 05:38:50 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 12 Nov 2014 21:38:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,374,1413270000"; d="scan'208";a="636183234"
Received: from lil.sh.intel.com (HELO localhost) ([10.239.36.68])
	by orsmga002.jf.intel.com with ESMTP; 12 Nov 2014 21:38:17 -0800
From: Li Liang <liang.z.li@intel.com>
To: xen-devel@lists.xen.org
Date: Thu, 13 Nov 2014 13:31:17 +0800
Message-Id: <1415856677-25814-1-git-send-email-liang.z.li@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com,
	Li Liang <liang.z.li@intel.com>, ian.jackson@eu.citrix.com,
	yang.z.zhang@intel.com
Subject: [Xen-devel] [PATCH] libxc: Turn on the pdpe1gb cpuid flag by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 it's no need to set the "cpuid= " option in the config file
to expose the 1GB hugepage feature to guest.

Signed-off-by: Li Liang <liang.z.li@intel.com>
---
 tools/libxc/xc_cpuid_x86.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index a18b1ff..561c5b5 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -192,6 +192,7 @@ static void intel_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_ABM));
         regs[3] &= (bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_RDTSCP));
         break;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 06:23:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 06:23:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XonoG-0005yx-Tj; Thu, 13 Nov 2014 06:23:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XonoE-0005ys-RO
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 06:23:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D7/D6-09842-E4E44645; Thu, 13 Nov 2014 06:23:10 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415859788!12013858!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28669 invoked from network); 13 Nov 2014 06:23:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 06:23:08 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 71662AAF1;
	Thu, 13 Nov 2014 06:23:06 +0000 (UTC)
Message-ID: <54644E48.3040506@suse.com>
Date: Thu, 13 Nov 2014 07:23:04 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
In-Reply-To: <20141112214506.GA5922@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

On 11/12/2014 10:45 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 06:43:40AM +0100, Juergen Gross wrote:
>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>> index a8a1a3d..d3e492b 100644
>> --- a/arch/x86/xen/mmu.c
>> +++ b/arch/x86/xen/mmu.c
>> @@ -1223,6 +1223,10 @@ static void __init xen_pagetable_init(void)
>>   	/* Allocate and initialize top and mid mfn levels for p2m structure */
>>   	xen_build_mfn_list_list();
>>
>> +	/* Remap memory freed because of conflicts with E820 map */
>
> s/becasue of/due to

Okay.

>>   	/* Boundary cross-over for the edges: */
>> -	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
>> +	p2m = alloc_p2m_page();
>>
>>   	p2m_init(p2m);
>>
>> @@ -640,7 +651,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
>>
>>   	mid = p2m_top[topidx];
>>   	if (mid == p2m_mid_missing) {
>> -		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
>> +		mid = alloc_p2m_page();
>>
>>   		p2m_mid_init(mid, p2m_missing);
>>
>> @@ -649,100 +660,6 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
>>   	return true;
>>   }
>>
>
> I would split this patch in two - one for the extend_brk/alloc_page conversation
> to alloc_p2m_page and free_page to free_p2m_page.

Okay.

>> -/* Buffer used to remap identity mapped pages */
>> -unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
>> +/*
>> + * Buffer used to remap identity mapped pages. We only need the virtual space.
>
> Could you expand on the 'need the virtual space'?

I'll update the comment to:

/*
  * Buffer used to remap identity mapped pages. We only need the virtual
  * space. The physical page behind this address is remapped as needed to
  * different buffer pages.
  */

>
>
> .. snip..
>>   /*
>>    * This function updates the p2m and m2p tables with an identity map from
>> - * start_pfn to start_pfn+size and remaps the underlying RAM of the original
>> - * allocation at remap_pfn. It must do so carefully in P2M_PER_PAGE sized blocks
>> - * to not exhaust the reserved brk space. Doing it in properly aligned blocks
>> - * ensures we only allocate the minimum required leaf pages in the p2m table. It
>> - * copies the existing mfns from the p2m table under the 1:1 map, overwrites
>> - * them with the identity map and then updates the p2m and m2p tables with the
>> - * remapped memory.
>> + * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the
>> + * original allocation at remap_pfn. The information needed for remapping is
>> + * saved in the memory itself to avoid the need for allocating buffers. The
>> + * complete remap information is contained in a list of MFNs each containing
>> + * up to REMAP_SIZE MFNs and the start target PFN for doing the remap.
>> + * This enables to preserve the original mfn sequence while doing the remapping
>
> us to

Yep.

>> + * at a time when the memory management is capable of allocating virtual and
>> + * physical memory in arbitrary amounts.
>
> You might want to add, see 'xen_remap_memory' and its callers.

Okay.

>> -		/* These two checks move from the start to end boundaries */
>> -		if (ident_boundary_pfn == ident_start_pfn_align)
>> -			ident_boundary_pfn = ident_pfn_iter;
>> -		if (remap_boundary_pfn == remap_start_pfn_align)
>> -			remap_boundary_pfn = remap_pfn_iter;
>> +		/* Map first pfn to xen_remap_buf */
>> +		mfn = pfn_to_mfn(ident_pfn_iter);
>> +		set_pte_mfn(buf, mfn, PAGE_KERNEL);
>
> So you set the buf to be point to 'mfn'.

Correct.

>>
>> -		/* Check we aren't past the end */
>> -		BUG_ON(ident_boundary_pfn >= start_pfn + size);
>> -		BUG_ON(remap_boundary_pfn >= remap_pfn + size);
>> +		/* Save mapping information in page */
>> +		xen_remap_buf.next_area_mfn = xen_remap_mfn;
>> +		xen_remap_buf.target_pfn = remap_pfn_iter;
>> +		xen_remap_buf.size = chunk;
>> +		for (i = 0; i < chunk; i++)
>> +			xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i);
>>
>> -		mfn = pfn_to_mfn(ident_boundary_pfn);
>> +		/* New element first in list */
>
> I don't get that comment. Don't you mean the MFN of the last chunk you
> had stashed the 'xen_remap_buf' structure in?
>
> The 'xen_remap_mfn' ends up being the the tail value of this
> "list".

I'll redo the comment:

/* Put remap buf into list. */

>> +/*
>> + * Remap the memory prepared in xen_do_set_identity_and_remap_chunk().
>> + */
>> +void __init xen_remap_memory(void)
>> +{
>> +	unsigned long buf = (unsigned long)&xen_remap_buf;
>> +	unsigned long mfn_save, mfn, pfn;
>> +	unsigned long remapped = 0, released = 0;
>> +	unsigned int i, free;
>> +	unsigned long pfn_s = ~0UL;
>> +	unsigned long len = 0;
>> +
>> +	mfn_save = virt_to_mfn(buf);
>> +
>> +	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
>
> So the 'list' is constructed by going forward - that is from low-numbered
> PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
> other way - from the highest PFN to the lowest PFN.
>
> Won't that mean we will restore the chunks of memory in the wrong
> order? That is we will still restore them in chunks size, but the
> chunks will be in descending order instead of ascending?

No, the information where to put each chunk is contained in the chunk
data. I can add a comment explaining this.

>
>> +		/* Map the remap information */
>> +		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
>> +
>> +		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
>> +
>> +		free = 0;
>> +		pfn = xen_remap_buf.target_pfn;
>> +		for (i = 0; i < xen_remap_buf.size; i++) {
>> +			mfn = xen_remap_buf.mfns[i];
>> +			if (!released && xen_update_mem_tables(pfn, mfn)) {
>> +				remapped++;
>
> If we fail 'xen_update_mem_tables' we will on the next chunk (so i+1) keep on
> freeing pages instead of trying to remap. Is that intentional? Could we
> try to remap?

Hmm, I'm not sure this is worth the effort. What could lead to failure
here? I suspect we could even just BUG() on failure. What do you think?


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 06:23:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 06:23:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XonoG-0005yx-Tj; Thu, 13 Nov 2014 06:23:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XonoE-0005ys-RO
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 06:23:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D7/D6-09842-E4E44645; Thu, 13 Nov 2014 06:23:10 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415859788!12013858!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28669 invoked from network); 13 Nov 2014 06:23:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 06:23:08 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 71662AAF1;
	Thu, 13 Nov 2014 06:23:06 +0000 (UTC)
Message-ID: <54644E48.3040506@suse.com>
Date: Thu, 13 Nov 2014 07:23:04 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
In-Reply-To: <20141112214506.GA5922@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

On 11/12/2014 10:45 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 06:43:40AM +0100, Juergen Gross wrote:
>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>> index a8a1a3d..d3e492b 100644
>> --- a/arch/x86/xen/mmu.c
>> +++ b/arch/x86/xen/mmu.c
>> @@ -1223,6 +1223,10 @@ static void __init xen_pagetable_init(void)
>>   	/* Allocate and initialize top and mid mfn levels for p2m structure */
>>   	xen_build_mfn_list_list();
>>
>> +	/* Remap memory freed because of conflicts with E820 map */
>
> s/becasue of/due to

Okay.

>>   	/* Boundary cross-over for the edges: */
>> -	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
>> +	p2m = alloc_p2m_page();
>>
>>   	p2m_init(p2m);
>>
>> @@ -640,7 +651,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
>>
>>   	mid = p2m_top[topidx];
>>   	if (mid == p2m_mid_missing) {
>> -		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
>> +		mid = alloc_p2m_page();
>>
>>   		p2m_mid_init(mid, p2m_missing);
>>
>> @@ -649,100 +660,6 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
>>   	return true;
>>   }
>>
>
> I would split this patch in two - one for the extend_brk/alloc_page conversation
> to alloc_p2m_page and free_page to free_p2m_page.

Okay.

>> -/* Buffer used to remap identity mapped pages */
>> -unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
>> +/*
>> + * Buffer used to remap identity mapped pages. We only need the virtual space.
>
> Could you expand on the 'need the virtual space'?

I'll update the comment to:

/*
  * Buffer used to remap identity mapped pages. We only need the virtual
  * space. The physical page behind this address is remapped as needed to
  * different buffer pages.
  */

>
>
> .. snip..
>>   /*
>>    * This function updates the p2m and m2p tables with an identity map from
>> - * start_pfn to start_pfn+size and remaps the underlying RAM of the original
>> - * allocation at remap_pfn. It must do so carefully in P2M_PER_PAGE sized blocks
>> - * to not exhaust the reserved brk space. Doing it in properly aligned blocks
>> - * ensures we only allocate the minimum required leaf pages in the p2m table. It
>> - * copies the existing mfns from the p2m table under the 1:1 map, overwrites
>> - * them with the identity map and then updates the p2m and m2p tables with the
>> - * remapped memory.
>> + * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the
>> + * original allocation at remap_pfn. The information needed for remapping is
>> + * saved in the memory itself to avoid the need for allocating buffers. The
>> + * complete remap information is contained in a list of MFNs each containing
>> + * up to REMAP_SIZE MFNs and the start target PFN for doing the remap.
>> + * This enables to preserve the original mfn sequence while doing the remapping
>
> us to

Yep.

>> + * at a time when the memory management is capable of allocating virtual and
>> + * physical memory in arbitrary amounts.
>
> You might want to add, see 'xen_remap_memory' and its callers.

Okay.

>> -		/* These two checks move from the start to end boundaries */
>> -		if (ident_boundary_pfn == ident_start_pfn_align)
>> -			ident_boundary_pfn = ident_pfn_iter;
>> -		if (remap_boundary_pfn == remap_start_pfn_align)
>> -			remap_boundary_pfn = remap_pfn_iter;
>> +		/* Map first pfn to xen_remap_buf */
>> +		mfn = pfn_to_mfn(ident_pfn_iter);
>> +		set_pte_mfn(buf, mfn, PAGE_KERNEL);
>
> So you set the buf to be point to 'mfn'.

Correct.

>>
>> -		/* Check we aren't past the end */
>> -		BUG_ON(ident_boundary_pfn >= start_pfn + size);
>> -		BUG_ON(remap_boundary_pfn >= remap_pfn + size);
>> +		/* Save mapping information in page */
>> +		xen_remap_buf.next_area_mfn = xen_remap_mfn;
>> +		xen_remap_buf.target_pfn = remap_pfn_iter;
>> +		xen_remap_buf.size = chunk;
>> +		for (i = 0; i < chunk; i++)
>> +			xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i);
>>
>> -		mfn = pfn_to_mfn(ident_boundary_pfn);
>> +		/* New element first in list */
>
> I don't get that comment. Don't you mean the MFN of the last chunk you
> had stashed the 'xen_remap_buf' structure in?
>
> The 'xen_remap_mfn' ends up being the the tail value of this
> "list".

I'll redo the comment:

/* Put remap buf into list. */

>> +/*
>> + * Remap the memory prepared in xen_do_set_identity_and_remap_chunk().
>> + */
>> +void __init xen_remap_memory(void)
>> +{
>> +	unsigned long buf = (unsigned long)&xen_remap_buf;
>> +	unsigned long mfn_save, mfn, pfn;
>> +	unsigned long remapped = 0, released = 0;
>> +	unsigned int i, free;
>> +	unsigned long pfn_s = ~0UL;
>> +	unsigned long len = 0;
>> +
>> +	mfn_save = virt_to_mfn(buf);
>> +
>> +	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
>
> So the 'list' is constructed by going forward - that is from low-numbered
> PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
> other way - from the highest PFN to the lowest PFN.
>
> Won't that mean we will restore the chunks of memory in the wrong
> order? That is we will still restore them in chunks size, but the
> chunks will be in descending order instead of ascending?

No, the information where to put each chunk is contained in the chunk
data. I can add a comment explaining this.

>
>> +		/* Map the remap information */
>> +		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
>> +
>> +		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
>> +
>> +		free = 0;
>> +		pfn = xen_remap_buf.target_pfn;
>> +		for (i = 0; i < xen_remap_buf.size; i++) {
>> +			mfn = xen_remap_buf.mfns[i];
>> +			if (!released && xen_update_mem_tables(pfn, mfn)) {
>> +				remapped++;
>
> If we fail 'xen_update_mem_tables' we will on the next chunk (so i+1) keep on
> freeing pages instead of trying to remap. Is that intentional? Could we
> try to remap?

Hmm, I'm not sure this is worth the effort. What could lead to failure
here? I suspect we could even just BUG() on failure. What do you think?


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 06:49:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 06:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XooDh-0006QG-5T; Thu, 13 Nov 2014 06:49:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XooDg-0006QB-6L
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 06:49:28 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	D2/8F-29352-77454645; Thu, 13 Nov 2014 06:49:27 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415861366!5620094!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32641 invoked from network); 13 Nov 2014 06:49:26 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Nov 2014 06:49:26 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A4209AAF1;
	Thu, 13 Nov 2014 06:49:25 +0000 (UTC)
Message-ID: <54645474.4040605@suse.com>
Date: Thu, 13 Nov 2014 07:49:24 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-5-git-send-email-jgross@suse.com>
	<20141112221021.GC7549@laptop.dumpdata.com>
In-Reply-To: <20141112221021.GC7549@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 4/8] xen: Delay invalidating extra 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 11:10 PM, Konrad Rzeszutek Wilk wrote:
>> @@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
>>   	unsigned long max_pfn;
>>   	unsigned long pfn;
>>
>> -	 if (xen_feature(XENFEAT_auto_translated_physmap))
>> +	if (xen_feature(XENFEAT_auto_translated_physmap))
>
> Spurious change.

I'll remove it.

>
> .. snip..
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 0e5f9b6..8d5985b 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -75,7 +75,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
>>
>>   static void __init xen_add_extra_mem(u64 start, u64 size)
>>   {
>> -	unsigned long pfn;
>>   	int i;
>>
>>   	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>> @@ -95,17 +94,74 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
>>   		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
>>
>>   	memblock_reserve(start, size);
>> +}
>>
>> -	xen_max_p2m_pfn = PFN_DOWN(start + size);
>> -	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
>> -		unsigned long mfn = pfn_to_mfn(pfn);
>> +static void __init xen_del_extra_mem(u64 start, u64 size)
>> +{
>> +	int i;
>> +	u64 start_r, size_r;
>>
>> -		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
>> -			continue;
>> -		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
>> -			  pfn, mfn);
>> +	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>> +		start_r = xen_extra_mem[i].start;
>> +		size_r = xen_extra_mem[i].size;
>> +
>> +		/* Start of region. */
>> +		if (start_r == start) {
>> +			BUG_ON(size > size_r);
>> +			xen_extra_mem[i].start += size;
>> +			xen_extra_mem[i].size -= size;
>> +			break;
>> +		}
>> +		/* End of region. */
>> +		if (start_r + size_r == start + size) {
>> +			BUG_ON(size > size_r);
>> +			xen_extra_mem[i].size -= size;
>> +			break;
>> +		}
>> +		/* Mid of region. */
>> +		if (start > start_r && start < start_r + size_r) {
>> +			BUG_ON(start + size > start_r + size_r);
>> +			xen_extra_mem[i].size = start - start_r;
>> +			xen_add_extra_mem(start + size, start_r + size_r -
>> +					  (start + size));
>
> Which ends up calling 'memblock_reserve' for an region it already has
> reserved. Should we call memblock_free(start_r, size_r - size) before calling this?
>
> Or is that not neccessary as memblock_* is pretty smart about this sort of thing?

Regions marked via memblock_reserve() are allowed to overlap. I can add
a comment.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 06:49:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 06:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XooDh-0006QG-5T; Thu, 13 Nov 2014 06:49:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XooDg-0006QB-6L
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 06:49:28 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	D2/8F-29352-77454645; Thu, 13 Nov 2014 06:49:27 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415861366!5620094!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32641 invoked from network); 13 Nov 2014 06:49:26 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Nov 2014 06:49:26 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A4209AAF1;
	Thu, 13 Nov 2014 06:49:25 +0000 (UTC)
Message-ID: <54645474.4040605@suse.com>
Date: Thu, 13 Nov 2014 07:49:24 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-5-git-send-email-jgross@suse.com>
	<20141112221021.GC7549@laptop.dumpdata.com>
In-Reply-To: <20141112221021.GC7549@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 4/8] xen: Delay invalidating extra 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 11:10 PM, Konrad Rzeszutek Wilk wrote:
>> @@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
>>   	unsigned long max_pfn;
>>   	unsigned long pfn;
>>
>> -	 if (xen_feature(XENFEAT_auto_translated_physmap))
>> +	if (xen_feature(XENFEAT_auto_translated_physmap))
>
> Spurious change.

I'll remove it.

>
> .. snip..
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 0e5f9b6..8d5985b 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -75,7 +75,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
>>
>>   static void __init xen_add_extra_mem(u64 start, u64 size)
>>   {
>> -	unsigned long pfn;
>>   	int i;
>>
>>   	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>> @@ -95,17 +94,74 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
>>   		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
>>
>>   	memblock_reserve(start, size);
>> +}
>>
>> -	xen_max_p2m_pfn = PFN_DOWN(start + size);
>> -	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
>> -		unsigned long mfn = pfn_to_mfn(pfn);
>> +static void __init xen_del_extra_mem(u64 start, u64 size)
>> +{
>> +	int i;
>> +	u64 start_r, size_r;
>>
>> -		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
>> -			continue;
>> -		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
>> -			  pfn, mfn);
>> +	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>> +		start_r = xen_extra_mem[i].start;
>> +		size_r = xen_extra_mem[i].size;
>> +
>> +		/* Start of region. */
>> +		if (start_r == start) {
>> +			BUG_ON(size > size_r);
>> +			xen_extra_mem[i].start += size;
>> +			xen_extra_mem[i].size -= size;
>> +			break;
>> +		}
>> +		/* End of region. */
>> +		if (start_r + size_r == start + size) {
>> +			BUG_ON(size > size_r);
>> +			xen_extra_mem[i].size -= size;
>> +			break;
>> +		}
>> +		/* Mid of region. */
>> +		if (start > start_r && start < start_r + size_r) {
>> +			BUG_ON(start + size > start_r + size_r);
>> +			xen_extra_mem[i].size = start - start_r;
>> +			xen_add_extra_mem(start + size, start_r + size_r -
>> +					  (start + size));
>
> Which ends up calling 'memblock_reserve' for an region it already has
> reserved. Should we call memblock_free(start_r, size_r - size) before calling this?
>
> Or is that not neccessary as memblock_* is pretty smart about this sort of thing?

Regions marked via memblock_reserve() are allowed to overlap. I can add
a comment.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 06:55:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 06:55:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XooJ6-0006hJ-LX; Thu, 13 Nov 2014 06:55:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XooJ2-0006hE-CB
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 06:55:00 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	F5/6D-02576-3C554645; Thu, 13 Nov 2014 06:54:59 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415861698!12222004!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4079 invoked from network); 13 Nov 2014 06:54:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 06:54:59 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 740E7AAF1;
	Thu, 13 Nov 2014 06:54:58 +0000 (UTC)
Message-ID: <546455C1.6000405@suse.com>
Date: Thu, 13 Nov 2014 07:54:57 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-6-git-send-email-jgross@suse.com>
	<20141112221204.GD7549@laptop.dumpdata.com>
In-Reply-To: <20141112221204.GD7549@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 5/8] x86: Introduce function to get pmd
	entry pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 11:12 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 06:43:43AM +0100, Juergen Gross wrote:
>> Introduces lookup_pmd_address() to get the address of the pmd entry
>> related to a virtual address in the current address space. This
>> function is needed for support of a virtual mapped sparse p2m list
>> in xen pv domains.
>>
> What is wrong with using 'lookup_address' ?

It doesn't return the needed information. I need a pmd entry here, not
a pte entry.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 06:55:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 06:55:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XooJ6-0006hJ-LX; Thu, 13 Nov 2014 06:55:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XooJ2-0006hE-CB
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 06:55:00 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	F5/6D-02576-3C554645; Thu, 13 Nov 2014 06:54:59 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415861698!12222004!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4079 invoked from network); 13 Nov 2014 06:54:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 06:54:59 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 740E7AAF1;
	Thu, 13 Nov 2014 06:54:58 +0000 (UTC)
Message-ID: <546455C1.6000405@suse.com>
Date: Thu, 13 Nov 2014 07:54:57 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-6-git-send-email-jgross@suse.com>
	<20141112221204.GD7549@laptop.dumpdata.com>
In-Reply-To: <20141112221204.GD7549@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 5/8] x86: Introduce function to get pmd
	entry pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 11:12 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 06:43:43AM +0100, Juergen Gross wrote:
>> Introduces lookup_pmd_address() to get the address of the pmd entry
>> related to a virtual address in the current address space. This
>> function is needed for support of a virtual mapped sparse p2m list
>> in xen pv domains.
>>
> What is wrong with using 'lookup_address' ?

It doesn't return the needed information. I need a pmd entry here, not
a pte entry.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 07:45:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 07: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 1Xop66-0007mh-HV; Thu, 13 Nov 2014 07:45:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1Xop65-0007mc-KL
	for Xen-devel@lists.xen.org; Thu, 13 Nov 2014 07:45:41 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	09/A1-24532-4A164645; Thu, 13 Nov 2014 07:45:40 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415864740!12342703!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3080 invoked from network); 13 Nov 2014 07:45:40 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 07:45:40 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id A13ED106EC4F
	for <Xen-devel@lists.xen.org>; Thu, 13 Nov 2014 08:45:39 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (solig.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP id b7lREVSKlA-C for <Xen-devel@lists.xen.org>;
	Thu, 13 Nov 2014 08:45:39 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id 2F1CE106EC15
	for <Xen-devel@lists.xen.org>; Thu, 13 Nov 2014 08:45:39 +0100 (CET)
Message-ID: <546461A2.2070908@univention.de>
Date: Thu, 13 Nov 2014 08:45:38 +0100
From: Philipp Hahn <hahn@univention.de>
Organization: Univention GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel@lists.xen.org
Content-Length: 5176
Subject: [Xen-devel] xenstored crashes with SIGSEGV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8sCgpmb3Igc29tZSB0aW1lIHdlIG9ic2VydmVkIHNldmVyYWwgaG9zdCB3aGVyZSB4ZW5z
dG9yZWQgY3Jhc2hlcy4gV2UKb2JzZXJ2ZWQgdGhlIGZvbGxvd2luZyBjcmFzaCB0d28gdGltZXMg
Ynkgbm93OgoKPiAjMCAgdGFsbG9jX2NodW5rX2Zyb21fcHRyIChwdHI9MHhmZjAwMDAwMDAwMDAp
IGF0IHRhbGxvYy5jOjExNgo+IDExNiAgICAgICAgICAgICBpZiAoKHRjLT5mbGFncyAmIH4weEYp
ICE9IFRBTExPQ19NQUdJQykgeyAKPiB3YXJuaW5nOiBub3QgdXNpbmcgdW50cnVzdGVkIGZpbGUK
PiAiL3Jvb3QveGVuLTQuMS00LjEuMy94ZW4tNC4xLjMvdG9vbHMveGVuc3RvcmUvLmdkYmluaXQi
Cj4gKGdkYikgYnQKPiAjMCAgdGFsbG9jX2NodW5rX2Zyb21fcHRyIChwdHI9MHhmZjAwMDAwMDAw
MDApIGF0IHRhbGxvYy5jOjExNgo+ICMxICAweDAwMDAwMDAwMDA0MDdlZGYgaW4gdGFsbG9jX2Zy
ZWUgKHB0cj0weGZmMDAwMDAwMDAwMCkgYXQgdGFsbG9jLmM6NTUxCj4gIzIgIDB4MDAwMDAwMDAw
MDQwYTM0OCBpbiB0ZGJfb3Blbl9leCAobmFtZT0weDE2N2Q2MjAKPiAiL3Zhci9saWIveGVuc3Rv
cmVkL3RkYi4weDE2YTQ4YjAiLCAKPiAgICAgaGFzaF9zaXplPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0
PiwgdGRiX2ZsYWdzPTAsIG9wZW5fZmxhZ3M9PHZhbHVlIG9wdGltaXplZAo+IG91dD4sIG1vZGU9
PHZhbHVlIG9wdGltaXplZCBvdXQ+LCAKPiAgICAgbG9nX2ZuPTB4NDA5M2IwIDxudWxsX2xvZ19m
bj4sIGhhc2hfZm49PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBhdCB0ZGIuYzoxOTU4Cj4gIzMgIDB4
MDAwMDAwMDAwMDQwYTY4NCBpbiB0ZGJfb3BlbiAobmFtZT0weGZmMDAwMDAwMDAwMCA8QWRkcmVz
cyAweGZmMDAwMDAwMDAwMAo+IG91dCBvZiBib3VuZHM+LCBoYXNoX3NpemU9MCwgCj4gICAgIHRk
Yl9mbGFncz00MjU0OTI4LCBvcGVuX2ZsYWdzPS0xLCBtb2RlPTM5NzQ0NTAxODQpIGF0IHRkYi5j
OjE3NzMKPiAjNCAgMHgwMDAwMDAwMDAwNDBhNzBiIGluIHRkYl9jb3B5ICh0ZGI9MHgxNmM5MDQw
LCBvdXRmaWxlPTB4MTY3ZDYyMAo+ICIvdmFyL2xpYi94ZW5zdG9yZWQvdGRiLjB4MTZhNDhiMCIp
Cj4gICAgIGF0IHRkYi5jOjIxMjQKPiAjNSAgMHgwMDAwMDAwMDAwNDA2YzJkIGluIGRvX3RyYW5z
YWN0aW9uX3N0YXJ0IChjb25uPTB4MTY3ZTMxMCwgaW49PHZhbHVlCj4gb3B0aW1pemVkIG91dD4p
Cj4gICAgIGF0IHhlbnN0b3JlZF90cmFuc2FjdGlvbi5jOjE2NAo+ICM2ICAweDAwMDAwMDAwMDA0
MDQ1Y2EgaW4gcHJvY2Vzc19tZXNzYWdlIChjb25uPTB4MTY3ZTMxMCkgYXQKPiB4ZW5zdG9yZWRf
Y29yZS5jOjEyMTQKPiAjNyAgY29uc2lkZXJfbWVzc2FnZSAoY29ubj0weDE2N2UzMTApIGF0IHhl
bnN0b3JlZF9jb3JlLmM6MTI2MQo+ICM4ICBoYW5kbGVfaW5wdXQgKGNvbm49MHgxNjdlMzEwKSBh
dCB4ZW5zdG9yZWRfY29yZS5jOjEzMDgKPiAjOSAgMHgwMDAwMDAwMDAwNDA1MTcwIGluIG1haW4g
KGFyZ2M9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCBhcmd2PTx2YWx1ZQo+IG9wdGltaXplZCBvdXQ+
KSBhdCB4ZW5zdG9yZWRfY29yZS5jOjE5NjQKCj4gKGdkYikgZnJhbWUgMgo+ICMyICAweDAwMDAw
MDAwMDA0MGEzNDggaW4gdGRiX29wZW5fZXggKG5hbWU9MHgxNjdkNjIwICIvdmFyL2xpYi94ZW5z
dG9yZWQvdGRiLjB4MTZhNDhiMCIsIAo+ICAgICBoYXNoX3NpemU9PHZhbHVlIG9wdGltaXplZCBv
dXQ+LCB0ZGJfZmxhZ3M9MCwgb3Blbl9mbGFncz08dmFsdWUgb3B0aW1pemVkIG91dD4sIG1vZGU9
PHZhbHVlIG9wdGltaXplZCBvdXQ+LCAKPiAgICAgbG9nX2ZuPTB4NDA5M2IwIDxudWxsX2xvZ19m
bj4sIGhhc2hfZm49PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBhdCB0ZGIuYzoxOTU4Cj4gMTk1OCAg
ICAgICAgICAgIFNBRkVfRlJFRSh0ZGItPmxvY2tlZCk7Cj4gKGdkYikgcHJpbnQgdGRiLT5sb2Nr
ZWQKPiAkMyA9IChzdHJ1Y3QgdGRiX2xvY2tfdHlwZSAqKSAweGZmMDAwMDAwMDAwMAoKQW5vdGhl
ciBvbmUgd2FzIGluIHZzcHJpbnRmKCkgLSBzZWUKPGh0dHBzOi8vZm9yZ2UudW5pdmVudGlvbi5v
cmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTM1MTA0I2MzPiBmb3IgdGhlCmZ1bGwgYmFjayB0
cmFjZXMuCgpUbyBtZSB0aGlzIGxvb2tzIGxpa2Ugc29tZSBtZW1vcnkgY29ycnVwdGlvbiBieSBz
b21lIHVua25vd24gY29kZQp3cml0aW5nIGludG8gc29tZSByYW5kb20gbWVtb3J5IHNwYWNlLCB3
aGljaCBoYXBwZW5zIHRvIGJlIHRoZSB0ZGIgaGVyZS4KCkFzIGZhciBhcyBJIGtub3cgeGVuc3Rv
cmVkIGNhbid0IGJlIHJlc3RhcnRlZCBhcyAtIGZvciBleGFtcGxlIC0gcWVtdS1kbQphbmQgYmxr
dGFwMiBwcm9jZXNzZXMgaGF2ZSBvcGVuIGZpbGUgaGFuZGxlcyB0byB0aGUgeGVuc3RvcmVkIHVu
aXgKc29ja2V0IGZvciBJUEMsIHdoaWNoIHdvdWxkIG5lZWQgcmUtb3BlbmluZy4gQXMgc3VjaCB0
aGUgaG9zdCBtdXN0IGJlCnJlYm9vdGVkIHRvIGZpeCB0aGlzIHNpdHVhdGlvbiwgYXMgdGhlIFZN
cyBjYW4gbm8gbG9uZ2VyIGJlIG1hbmFnZWQgYW5kCnRodXMgbm90IG1pZ3JhdGVkLgoKVGhlIGhv
c3QgaXMgc3RpbGwgcnVubmluZyB4ZW4tNC4xLjMgKEkga25vdyB0aGF0IHRoaXMgaXMgcXVpZXQg
b2xkKSwgYnV0CkkgaGFkIGEgbG9vayBhdCB0aGUgY2hhbmdlcyBiZXR3ZWVuIHRoYXQgdmVyc2lv
biBhbmQgbWFzdGVyIGZvcgp0b29scy94ZW5zdG9yZS8gbXlzZWxmIGFuZCBkaWRuJ3Qgc2VlIGFu
eSBvYnZpb3VzIGNoYW5nZSB3aGljaCBjb3VsZCBmaXgKdGhhdC4KCjEuIEhhcyBzb21lb25lIG9i
c2VydmVkIGEgc2ltaWxhciBjcmFzaD8KCjIuIFdlJ3ZlIG5vdyBhbHNvIGVuYWJsZWQgInhlbnN0
b3JlZCAtVCAvbG9nIC0tdmVyYm9zZSIgdG8gbG9nIHRoZQptZXNzYWdlcyBpbiB0aGUgaG9wZSB0
byBmaW5kIHRoZSB0cmlnZ2VyaW5nIHRyYW5zYWN0aW9uLCBidXQgdW50aWwgdGhlbgppcyB0aGVy
ZSBzb21ldGhpbmcgbW9yZSB3ZSBjYW4gZG8gdG8gdHJhY2sgZG93biB0aGUgcHJvYmxlbT8KCjMu
IHRoZSBjcmFzaCBoYXBwZW5zIHJhcmVseSBhbmQgdGhlIGhvc3QgcnVuIGZpbmUgbW9zdCBvZiB0
aGUgdGltZS4gVGhlCmNyYXNoIG1vc3RseSBoYXBwZW5zIGFyb3VuZCBtaWRuaWdodCBhbmQgc2Vl
bSB0byBiZSBndWVzdC10cmlnZ2VyZWQsIGFzCnRoZSBsb2dzIG9uIHRoZSBob3N0IGRvbid0IHNo
b3cgYW55IGFjdGl2aXR5IGxpa2Ugc3RhcnRpbmcgbmV3IG9yCmRlc3Ryb3lpbmcgcnVubmluZyBW
TXMuIFNvIGZhciB0aGUgcHJvYmxlbSBvbmx5IHNob3dlZCBvbiBob3N0IHJ1bm5pbmcKTGludXgg
Vk1zLiBPdGhlciBob3N0IHJ1bm5pbmcgV2luZG93cyBWTXMgc28gZmFyIG5ldmVyIHNob3dlZCB0
aGF0IGNyYXNoLgoKVGhhbmsgeW91IGZvciB5b3VyIHN1cHBvcnQuCgpQaGlsaXBwCi0tIApQaGls
aXBwIEhhaG4KT3BlbiBTb3VyY2UgU29mdHdhcmUgRW5naW5lZXIKClVuaXZlbnRpb24gR21iSApi
ZSBvcGVuLgpNYXJ5LVNvbWVydmlsbGUtU3RyLiAxCkQtMjgzNTkgQnJlbWVuClRlbC46ICs0OSA0
MjEgMjIyMzItMApGYXggOiArNDkgNDIxIDIyMjMyLTk5CmhhaG5AdW5pdmVudGlvbi5kZQoKaHR0
cDovL3d3dy51bml2ZW50aW9uLmRlLwpHZXNjaMOkZnRzZsO8aHJlcjogUGV0ZXIgSC4gR2FudGVu
CkhSQiAyMDc1NSBBbXRzZ2VyaWNodCBCcmVtZW4KU3RldWVyLU5yLjogNzEtNTk3LTAyODc2Cgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 13 07:45:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 07: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 1Xop66-0007mh-HV; Thu, 13 Nov 2014 07:45:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1Xop65-0007mc-KL
	for Xen-devel@lists.xen.org; Thu, 13 Nov 2014 07:45:41 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	09/A1-24532-4A164645; Thu, 13 Nov 2014 07:45:40 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415864740!12342703!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3080 invoked from network); 13 Nov 2014 07:45:40 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 07:45:40 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id A13ED106EC4F
	for <Xen-devel@lists.xen.org>; Thu, 13 Nov 2014 08:45:39 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (solig.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP id b7lREVSKlA-C for <Xen-devel@lists.xen.org>;
	Thu, 13 Nov 2014 08:45:39 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id 2F1CE106EC15
	for <Xen-devel@lists.xen.org>; Thu, 13 Nov 2014 08:45:39 +0100 (CET)
Message-ID: <546461A2.2070908@univention.de>
Date: Thu, 13 Nov 2014 08:45:38 +0100
From: Philipp Hahn <hahn@univention.de>
Organization: Univention GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel@lists.xen.org
Content-Length: 5176
Subject: [Xen-devel] xenstored crashes with SIGSEGV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8sCgpmb3Igc29tZSB0aW1lIHdlIG9ic2VydmVkIHNldmVyYWwgaG9zdCB3aGVyZSB4ZW5z
dG9yZWQgY3Jhc2hlcy4gV2UKb2JzZXJ2ZWQgdGhlIGZvbGxvd2luZyBjcmFzaCB0d28gdGltZXMg
Ynkgbm93OgoKPiAjMCAgdGFsbG9jX2NodW5rX2Zyb21fcHRyIChwdHI9MHhmZjAwMDAwMDAwMDAp
IGF0IHRhbGxvYy5jOjExNgo+IDExNiAgICAgICAgICAgICBpZiAoKHRjLT5mbGFncyAmIH4weEYp
ICE9IFRBTExPQ19NQUdJQykgeyAKPiB3YXJuaW5nOiBub3QgdXNpbmcgdW50cnVzdGVkIGZpbGUK
PiAiL3Jvb3QveGVuLTQuMS00LjEuMy94ZW4tNC4xLjMvdG9vbHMveGVuc3RvcmUvLmdkYmluaXQi
Cj4gKGdkYikgYnQKPiAjMCAgdGFsbG9jX2NodW5rX2Zyb21fcHRyIChwdHI9MHhmZjAwMDAwMDAw
MDApIGF0IHRhbGxvYy5jOjExNgo+ICMxICAweDAwMDAwMDAwMDA0MDdlZGYgaW4gdGFsbG9jX2Zy
ZWUgKHB0cj0weGZmMDAwMDAwMDAwMCkgYXQgdGFsbG9jLmM6NTUxCj4gIzIgIDB4MDAwMDAwMDAw
MDQwYTM0OCBpbiB0ZGJfb3Blbl9leCAobmFtZT0weDE2N2Q2MjAKPiAiL3Zhci9saWIveGVuc3Rv
cmVkL3RkYi4weDE2YTQ4YjAiLCAKPiAgICAgaGFzaF9zaXplPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0
PiwgdGRiX2ZsYWdzPTAsIG9wZW5fZmxhZ3M9PHZhbHVlIG9wdGltaXplZAo+IG91dD4sIG1vZGU9
PHZhbHVlIG9wdGltaXplZCBvdXQ+LCAKPiAgICAgbG9nX2ZuPTB4NDA5M2IwIDxudWxsX2xvZ19m
bj4sIGhhc2hfZm49PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBhdCB0ZGIuYzoxOTU4Cj4gIzMgIDB4
MDAwMDAwMDAwMDQwYTY4NCBpbiB0ZGJfb3BlbiAobmFtZT0weGZmMDAwMDAwMDAwMCA8QWRkcmVz
cyAweGZmMDAwMDAwMDAwMAo+IG91dCBvZiBib3VuZHM+LCBoYXNoX3NpemU9MCwgCj4gICAgIHRk
Yl9mbGFncz00MjU0OTI4LCBvcGVuX2ZsYWdzPS0xLCBtb2RlPTM5NzQ0NTAxODQpIGF0IHRkYi5j
OjE3NzMKPiAjNCAgMHgwMDAwMDAwMDAwNDBhNzBiIGluIHRkYl9jb3B5ICh0ZGI9MHgxNmM5MDQw
LCBvdXRmaWxlPTB4MTY3ZDYyMAo+ICIvdmFyL2xpYi94ZW5zdG9yZWQvdGRiLjB4MTZhNDhiMCIp
Cj4gICAgIGF0IHRkYi5jOjIxMjQKPiAjNSAgMHgwMDAwMDAwMDAwNDA2YzJkIGluIGRvX3RyYW5z
YWN0aW9uX3N0YXJ0IChjb25uPTB4MTY3ZTMxMCwgaW49PHZhbHVlCj4gb3B0aW1pemVkIG91dD4p
Cj4gICAgIGF0IHhlbnN0b3JlZF90cmFuc2FjdGlvbi5jOjE2NAo+ICM2ICAweDAwMDAwMDAwMDA0
MDQ1Y2EgaW4gcHJvY2Vzc19tZXNzYWdlIChjb25uPTB4MTY3ZTMxMCkgYXQKPiB4ZW5zdG9yZWRf
Y29yZS5jOjEyMTQKPiAjNyAgY29uc2lkZXJfbWVzc2FnZSAoY29ubj0weDE2N2UzMTApIGF0IHhl
bnN0b3JlZF9jb3JlLmM6MTI2MQo+ICM4ICBoYW5kbGVfaW5wdXQgKGNvbm49MHgxNjdlMzEwKSBh
dCB4ZW5zdG9yZWRfY29yZS5jOjEzMDgKPiAjOSAgMHgwMDAwMDAwMDAwNDA1MTcwIGluIG1haW4g
KGFyZ2M9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCBhcmd2PTx2YWx1ZQo+IG9wdGltaXplZCBvdXQ+
KSBhdCB4ZW5zdG9yZWRfY29yZS5jOjE5NjQKCj4gKGdkYikgZnJhbWUgMgo+ICMyICAweDAwMDAw
MDAwMDA0MGEzNDggaW4gdGRiX29wZW5fZXggKG5hbWU9MHgxNjdkNjIwICIvdmFyL2xpYi94ZW5z
dG9yZWQvdGRiLjB4MTZhNDhiMCIsIAo+ICAgICBoYXNoX3NpemU9PHZhbHVlIG9wdGltaXplZCBv
dXQ+LCB0ZGJfZmxhZ3M9MCwgb3Blbl9mbGFncz08dmFsdWUgb3B0aW1pemVkIG91dD4sIG1vZGU9
PHZhbHVlIG9wdGltaXplZCBvdXQ+LCAKPiAgICAgbG9nX2ZuPTB4NDA5M2IwIDxudWxsX2xvZ19m
bj4sIGhhc2hfZm49PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBhdCB0ZGIuYzoxOTU4Cj4gMTk1OCAg
ICAgICAgICAgIFNBRkVfRlJFRSh0ZGItPmxvY2tlZCk7Cj4gKGdkYikgcHJpbnQgdGRiLT5sb2Nr
ZWQKPiAkMyA9IChzdHJ1Y3QgdGRiX2xvY2tfdHlwZSAqKSAweGZmMDAwMDAwMDAwMAoKQW5vdGhl
ciBvbmUgd2FzIGluIHZzcHJpbnRmKCkgLSBzZWUKPGh0dHBzOi8vZm9yZ2UudW5pdmVudGlvbi5v
cmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTM1MTA0I2MzPiBmb3IgdGhlCmZ1bGwgYmFjayB0
cmFjZXMuCgpUbyBtZSB0aGlzIGxvb2tzIGxpa2Ugc29tZSBtZW1vcnkgY29ycnVwdGlvbiBieSBz
b21lIHVua25vd24gY29kZQp3cml0aW5nIGludG8gc29tZSByYW5kb20gbWVtb3J5IHNwYWNlLCB3
aGljaCBoYXBwZW5zIHRvIGJlIHRoZSB0ZGIgaGVyZS4KCkFzIGZhciBhcyBJIGtub3cgeGVuc3Rv
cmVkIGNhbid0IGJlIHJlc3RhcnRlZCBhcyAtIGZvciBleGFtcGxlIC0gcWVtdS1kbQphbmQgYmxr
dGFwMiBwcm9jZXNzZXMgaGF2ZSBvcGVuIGZpbGUgaGFuZGxlcyB0byB0aGUgeGVuc3RvcmVkIHVu
aXgKc29ja2V0IGZvciBJUEMsIHdoaWNoIHdvdWxkIG5lZWQgcmUtb3BlbmluZy4gQXMgc3VjaCB0
aGUgaG9zdCBtdXN0IGJlCnJlYm9vdGVkIHRvIGZpeCB0aGlzIHNpdHVhdGlvbiwgYXMgdGhlIFZN
cyBjYW4gbm8gbG9uZ2VyIGJlIG1hbmFnZWQgYW5kCnRodXMgbm90IG1pZ3JhdGVkLgoKVGhlIGhv
c3QgaXMgc3RpbGwgcnVubmluZyB4ZW4tNC4xLjMgKEkga25vdyB0aGF0IHRoaXMgaXMgcXVpZXQg
b2xkKSwgYnV0CkkgaGFkIGEgbG9vayBhdCB0aGUgY2hhbmdlcyBiZXR3ZWVuIHRoYXQgdmVyc2lv
biBhbmQgbWFzdGVyIGZvcgp0b29scy94ZW5zdG9yZS8gbXlzZWxmIGFuZCBkaWRuJ3Qgc2VlIGFu
eSBvYnZpb3VzIGNoYW5nZSB3aGljaCBjb3VsZCBmaXgKdGhhdC4KCjEuIEhhcyBzb21lb25lIG9i
c2VydmVkIGEgc2ltaWxhciBjcmFzaD8KCjIuIFdlJ3ZlIG5vdyBhbHNvIGVuYWJsZWQgInhlbnN0
b3JlZCAtVCAvbG9nIC0tdmVyYm9zZSIgdG8gbG9nIHRoZQptZXNzYWdlcyBpbiB0aGUgaG9wZSB0
byBmaW5kIHRoZSB0cmlnZ2VyaW5nIHRyYW5zYWN0aW9uLCBidXQgdW50aWwgdGhlbgppcyB0aGVy
ZSBzb21ldGhpbmcgbW9yZSB3ZSBjYW4gZG8gdG8gdHJhY2sgZG93biB0aGUgcHJvYmxlbT8KCjMu
IHRoZSBjcmFzaCBoYXBwZW5zIHJhcmVseSBhbmQgdGhlIGhvc3QgcnVuIGZpbmUgbW9zdCBvZiB0
aGUgdGltZS4gVGhlCmNyYXNoIG1vc3RseSBoYXBwZW5zIGFyb3VuZCBtaWRuaWdodCBhbmQgc2Vl
bSB0byBiZSBndWVzdC10cmlnZ2VyZWQsIGFzCnRoZSBsb2dzIG9uIHRoZSBob3N0IGRvbid0IHNo
b3cgYW55IGFjdGl2aXR5IGxpa2Ugc3RhcnRpbmcgbmV3IG9yCmRlc3Ryb3lpbmcgcnVubmluZyBW
TXMuIFNvIGZhciB0aGUgcHJvYmxlbSBvbmx5IHNob3dlZCBvbiBob3N0IHJ1bm5pbmcKTGludXgg
Vk1zLiBPdGhlciBob3N0IHJ1bm5pbmcgV2luZG93cyBWTXMgc28gZmFyIG5ldmVyIHNob3dlZCB0
aGF0IGNyYXNoLgoKVGhhbmsgeW91IGZvciB5b3VyIHN1cHBvcnQuCgpQaGlsaXBwCi0tIApQaGls
aXBwIEhhaG4KT3BlbiBTb3VyY2UgU29mdHdhcmUgRW5naW5lZXIKClVuaXZlbnRpb24gR21iSApi
ZSBvcGVuLgpNYXJ5LVNvbWVydmlsbGUtU3RyLiAxCkQtMjgzNTkgQnJlbWVuClRlbC46ICs0OSA0
MjEgMjIyMzItMApGYXggOiArNDkgNDIxIDIyMjMyLTk5CmhhaG5AdW5pdmVudGlvbi5kZQoKaHR0
cDovL3d3dy51bml2ZW50aW9uLmRlLwpHZXNjaMOkZnRzZsO8aHJlcjogUGV0ZXIgSC4gR2FudGVu
CkhSQiAyMDc1NSBBbXRzZ2VyaWNodCBCcmVtZW4KU3RldWVyLU5yLjogNzEtNTk3LTAyODc2Cgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 13 07:53:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 07:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XopDC-00083w-EP; Thu, 13 Nov 2014 07:53:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linxingnku@gmail.com>) id 1XocrL-00012B-K6
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 18:41:39 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	F7/EB-02702-2E9A3645; Wed, 12 Nov 2014 18:41:38 +0000
X-Env-Sender: linxingnku@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415817697!12131479!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18534 invoked from network); 12 Nov 2014 18:41:37 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 18:41:37 -0000
Received: by mail-wi0-f178.google.com with SMTP id bs8so5837168wib.11
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 10:41:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=z009jxF79/OX07f1WFqw6K17IH4DygCfFuKKdIz/3fY=;
	b=az48S3o3pLAmeB1AQWkhZjAHrGpRHFBa7/cM9Q8a5Ew8ltfRXwtbIg5f/b3b9n729e
	49VDV2TmN8/c5Tu+zUpTDHYBj0uiLgHCmRuq8a3pf+7w8WpBa5Pw/kxefzVsI/1OjhCQ
	J/UGd/qh7r4WbQREcTWUrUr1rcXlsbufsrg5Gx8b5w3wJ5rUUQhcR+LJofSAfPcNceYO
	QVwt8ZWPDN8EJOSH6irVckVp+Gw5IsDMeE1Fns0OV75Sfzoome8OPg/IwK1f3glzcYIZ
	6keyOYDk0Ah6CsNPX2kcxjwgRfrcqrG6QiHuj68k7el/bzOr+gewCTmiucZI48A2AFxl
	pIIQ==
MIME-Version: 1.0
X-Received: by 10.194.249.136 with SMTP id yu8mr45719570wjc.30.1415817697196; 
	Wed, 12 Nov 2014 10:41:37 -0800 (PST)
Received: by 10.27.132.215 with HTTP; Wed, 12 Nov 2014 10:41:37 -0800 (PST)
Date: Wed, 12 Nov 2014 11:41:37 -0700
Message-ID: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
From: Xing Lin <linxingnku@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 13 Nov 2014 07:53:01 +0000
Subject: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2184966563714336243=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2184966563714336243==
Content-Type: multipart/alternative; boundary=001a11c1b2f6e8818f0507adbe40

--001a11c1b2f6e8818f0507adbe40
Content-Type: text/plain; charset=UTF-8

Hi,

I am aware that Xen via libvirt is in the group C support for openstack but
since I am not able to install xenserver iso at compute machines I have, I
have to consider to use xen with libvirt (xcp-xapi is not available for
ubuntu14.04). I have three nodes, each one running ubuntu 14.04. I follow
the instruction to install juno in ubuntu 14.04 and it works (I can create
instances from openstack GUI - horizon) when I use kvm as the hypervisor at
the compute node . However, if I switch to use xen as the hypervisor by
installing xen-hypervisor-amd64 or nova-compute-xen, it will fail to create
instances. It complained "backend for qemu disk is not ready". I checked
and did not find qemu process running in dom0. I could not find
/etc/init.d/xencommons either. Then, I compiled and installed xen-4.4 from
source code and I got xencommons in /etc/init.d. qemu process is running in
dom0. However, the dom0 kernel crashes this time when I try to launch an
instance from openstack GUI. I am able to create a xen guest with
virt-install from command line, with the following command.

"$ virt-install --connect=xen:/// --name u14.04.3 --ram 1024 --disk
u14.04.3.img,size=4,driver_name=qemu --location
http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/ --network
bridge=virbr0"


dmesg:

[ 9443.130600] blkfront: xvda: flush diskcache: enabled; persistent grants:
enabled; indirect descriptors: disabled;
[ 9443.132818]  xvda: xvda1
[ 9444.604489] xen:grant_table: WARNING: g.e. 0x30 still in use!
[ 9444.604496] deferring g.e. 0x30 (pfn 0xffffffffffffffff)
[ 9444.604499] xen:grant_table: WARNING: g.e. 0x31 still in use!
[ 9444.604502] deferring g.e. 0x31 (pfn 0xffffffffffffffff)
[ 9444.604505] xen:grant_table: WARNING: g.e. 0x32 still in use!
[ 9444.604508] deferring g.e. 0x32 (pfn 0xffffffffffffffff)
  ==== lots of them====
[ 9444.604719] xen:grant_table: WARNING: g.e. 0xe still in use!
[ 9444.604721] deferring g.e. 0xe (pfn 0xffffffffffffffff)
[ 9444.604723] xen:grant_table: WARNING: g.e. 0xd still in use!
[ 9444.604725] deferring g.e. 0xd (pfn 0xffffffffffffffff)
[ 9448.325408] ------------[ cut here ]------------
[ 9448.325421] WARNING: CPU: 5 PID: 19902 at
/build/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+0x
1a9/0x1b0()
[ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF          O
3.13.0-33-generic #58-Ubuntu
[ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS 2.1.15
09/02/2010
[ 9448.325497]  0000000000000009 ffff8802d13d9aa8 ffffffff8171bd04
0000000000000000
[ 9448.325501]  ffff8802d13d9ae0 ffffffff810676cd 0000000000000000
0000000000000001
[ 9448.325505]  ffff88030418ffe0 ffff88031d6ab180 0000000000000010
ffff8802d13d9af0
[ 9448.325509] Call Trace:
[ 9448.325518]  [<ffffffff8171bd04>] dump_stack+0x45/0x56
[ 9448.325523]  [<ffffffff810676cd>] warn_slowpath_common+0x7d/0xa0
[ 9448.325526]  [<ffffffff810677aa>] warn_slowpath_null+0x1a/0x20
[ 9448.325530]  [<ffffffff81004e99>] xen_mc_flush+0x1a9/0x1b0
[ 9448.325534]  [<ffffffff81006b99>] xen_set_pud_hyper+0x109/0x110
[ 9448.325538]  [<ffffffff81006c3b>] xen_set_pud+0x9b/0xb0
[ 9448.325543]  [<ffffffff81177f06>] __pmd_alloc+0xd6/0x110
[ 9448.325548]  [<ffffffff81182218>] move_page_tables+0x678/0x720
[ 9448.325552]  [<ffffffff8117ddb7>] ? vma_adjust+0x337/0x7d0
[ 9448.325557]  [<ffffffff811c23fd>] shift_arg_pages+0xbd/0x1b0
[ 9448.325560]  [<ffffffff81181671>] ? mprotect_fixup+0x151/0x290
[ 9448.325564]  [<ffffffff811c26cb>] setup_arg_pages+0x1db/0x200
[ 9448.325570]  [<ffffffff81213edc>] load_elf_binary+0x41c/0xd80
[ 9448.325576]  [<ffffffff8131d503>] ? ima_get_action+0x23/0x30
[ 9448.325579]  [<ffffffff8131c7e2>] ? process_measurement+0x82/0x2c0
[ 9448.325584]  [<ffffffff811c2f7f>] search_binary_handler+0x8f/0x1b0
[ 9448.325587]  [<ffffffff811c44f7>] do_execve_common.isra.22+0x5a7/0x7e0
[ 9448.325591]  [<ffffffff811c49c6>] SyS_execve+0x36/0x50
[ 9448.325596]  [<ffffffff8172cc99>] stub_execve+0x69/0xa0
[ 9448.325599] ---[ end trace 53ac16782e751c0a ]---
[ 9448.347994] ------------[ cut here ]------------
[ 9448.348004] WARNING: CPU: 1 PID: 19902 at
/build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
==== more message ignored ====


I sent emails to the openstack mailing list and they gave me a few
suggestions. At last, Bob Ball suggested I should probably ask this
question on xen-devel mailing list. Any help will be highly appreciated!
Thanks,

Original discussion on openstack mailing list:
http://www.gossamer-threads.com/lists/openstack/dev/42337


-Xing

--001a11c1b2f6e8818f0507adbe40
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,=C2=A0<div><br></div><div><span style=3D"font-family:ar=
ial,sans-serif;font-size:13px">I am aware that Xen via libvirt is in the gr=
oup C support for openstack but since I am not able to install xenserver is=
o at compute machines I have, I have to consider to use xen with libvirt (x=
cp-xapi is not available for ubuntu14.04). I have three nodes, each one run=
ning ubuntu 14.04. I follow the instruction to install juno in ubuntu 14.04=
 and it works (I can create instances from openstack GUI - horizon) when I =
use kvm as the hypervisor at the compute node . However, if I switch to use=
 xen as the hypervisor by installing xen-hypervisor-amd64 or nova-compute-x=
en, it will fail to create instances. It complained &quot;backend for qemu =
disk is not ready&quot;. I checked and did not find qemu process running in=
 dom0.=C2=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13=
px">I could not find /etc/init.d/xencommons either.=C2=A0</span><span style=
=3D"font-family:arial,sans-serif;font-size:13px">Then, I compiled and insta=
lled xen-4.4 from source code and I got xencommons in /etc/init.d. qemu pro=
cess is running in dom0. However, the dom0 kernel crashes this time when I =
try to launch an instance from openstack GUI. I am able to create a xen gue=
st with virt-install from command line, with the following command.=C2=A0</=
span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"=
><br></span></div><div><span style=3D"font-family:arial,sans-serif;font-siz=
e:13px">&quot;$ virt-install --connect=3Dxen:/// --name u14.04.3 --ram 1024=
 --disk u14.04.3.img,size=3D4,driver_name=3Dqemu --location=C2=A0</span><a =
href=3D"http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/" ta=
rget=3D"_blank" style=3D"font-family:arial,sans-serif;font-size:13px">http:=
//ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/</a><span style=
=3D"font-family:arial,sans-serif;font-size:13px">=C2=A0--network bridge=3Dv=
irbr0&quot;</span><span style=3D"font-family:arial,sans-serif;font-size:13p=
x"><br></span></div><div><span style=3D"font-family:arial,sans-serif;font-s=
ize:13px"><br></span></div><div><span style=3D"font-family:arial,sans-serif=
;font-size:13px"><br></span></div><div><div style=3D"font-family:arial,sans=
-serif;font-size:13px">dmesg:=C2=A0</div><div style=3D"font-family:arial,sa=
ns-serif;font-size:13px"><br></div><div style=3D"font-family:arial,sans-ser=
if;font-size:13px"><div>[ 9443.130600] blkfront: xvda: flush diskcache: ena=
bled; persistent grants: enabled; indirect descriptors: disabled;</div><div=
>[ 9443.132818] =C2=A0xvda: xvda1</div><div>[ 9444.604489] xen:grant_table:=
 WARNING: g.e. 0x30 still in use!</div><div>[ 9444.604496] deferring g.e. 0=
x30 (pfn 0xffffffffffffffff)</div><div>[ 9444.604499] xen:grant_table: WARN=
ING: g.e. 0x31 still in use!</div><div>[ 9444.604502] deferring g.e. 0x31 (=
pfn 0xffffffffffffffff)</div><div>[ 9444.604505] xen:grant_table: WARNING: =
g.e. 0x32 still in use!</div><div>[ 9444.604508] deferring g.e. 0x32 (pfn 0=
xffffffffffffffff)</div></div><div style=3D"font-family:arial,sans-serif;fo=
nt-size:13px">=C2=A0 =3D=3D=3D=3D lots of them=3D=3D=3D=3D</div><div style=
=3D"font-family:arial,sans-serif;font-size:13px"><div>[ 9444.604719] xen:gr=
ant_table: WARNING: g.e. 0xe still in use!</div><div>[ 9444.604721] deferri=
ng g.e. 0xe (pfn 0xffffffffffffffff)</div><div>[ 9444.604723] xen:grant_tab=
le: WARNING: g.e. 0xd still in use!</div><div>[ 9444.604725] deferring g.e.=
 0xd (pfn 0xffffffffffffffff)</div><div>[ 9448.325408] ------------[ cut he=
re ]------------</div><div>[ 9448.325421] WARNING: CPU: 5 PID: 19902 at /bu=
ild/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+0x</div>=
<div>1a9/0x1b0()</div></div><div style=3D"font-family:arial,sans-serif;font=
-size:13px"><div>[ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0O 3.13.0-33-generic #58-Ubuntu</div><div>=
[ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS 2.1.15 =
09/02/2010</div><div>[ 9448.325497] =C2=A00000000000000009 ffff8802d13d9aa8=
 ffffffff8171bd04 0000000000000000</div><div>[ 9448.325501] =C2=A0ffff8802d=
13d9ae0 ffffffff810676cd 0000000000000000 0000000000000001</div><div>[ 9448=
.325505] =C2=A0ffff88030418ffe0 ffff88031d6ab180 0000000000000010 ffff8802d=
13d9af0</div><div>[ 9448.325509] Call Trace:</div><div>[ 9448.325518] =C2=
=A0[&lt;ffffffff8171bd04&gt;] dump_stack+0x45/0x56</div><div>[ 9448.325523]=
 =C2=A0[&lt;ffffffff810676cd&gt;] warn_slowpath_common+0x7d/0xa0</div><div>=
[ 9448.325526] =C2=A0[&lt;ffffffff810677aa&gt;] warn_slowpath_null+0x1a/0x2=
0</div><div>[ 9448.325530] =C2=A0[&lt;ffffffff81004e99&gt;] xen_mc_flush+0x=
1a9/0x1b0</div><div>[ 9448.325534] =C2=A0[&lt;ffffffff81006b99&gt;] xen_set=
_pud_hyper+0x109/0x110</div><div>[ 9448.325538] =C2=A0[&lt;ffffffff81006c3b=
&gt;] xen_set_pud+0x9b/0xb0</div><div>[ 9448.325543] =C2=A0[&lt;ffffffff811=
77f06&gt;] __pmd_alloc+0xd6/0x110</div><div>[ 9448.325548] =C2=A0[&lt;fffff=
fff81182218&gt;] move_page_tables+0x678/0x720</div><div>[ 9448.325552] =C2=
=A0[&lt;ffffffff8117ddb7&gt;] ? vma_adjust+0x337/0x7d0</div><div>[ 9448.325=
557] =C2=A0[&lt;ffffffff811c23fd&gt;] shift_arg_pages+0xbd/0x1b0</div><div>=
[ 9448.325560] =C2=A0[&lt;ffffffff81181671&gt;] ? mprotect_fixup+0x151/0x29=
0</div><div>[ 9448.325564] =C2=A0[&lt;ffffffff811c26cb&gt;] setup_arg_pages=
+0x1db/0x200</div><div>[ 9448.325570] =C2=A0[&lt;ffffffff81213edc&gt;] load=
_elf_binary+0x41c/0xd80</div><div>[ 9448.325576] =C2=A0[&lt;ffffffff8131d50=
3&gt;] ? ima_get_action+0x23/0x30</div><div>[ 9448.325579] =C2=A0[&lt;fffff=
fff8131c7e2&gt;] ? process_measurement+0x82/0x2c0</div><div>[ 9448.325584] =
=C2=A0[&lt;ffffffff811c2f7f&gt;] search_binary_handler+0x8f/0x1b0</div><div=
>[ 9448.325587] =C2=A0[&lt;ffffffff811c44f7&gt;] do_execve_common.isra.22+0=
x5a7/0x7e0</div><div>[ 9448.325591] =C2=A0[&lt;ffffffff811c49c6&gt;] SyS_ex=
ecve+0x36/0x50</div><div>[ 9448.325596] =C2=A0[&lt;ffffffff8172cc99&gt;] st=
ub_execve+0x69/0xa0</div><div>[ 9448.325599] ---[ end trace 53ac16782e751c0=
a ]---</div><div>[ 9448.347994] ------------[ cut here ]------------</div><=
div>[ 9448.348004] WARNING: CPU: 1 PID: 19902 at /build/buildd/linux-3.13.0=
/mm/mmap.c:2736 exit_mmap+0x16b/0x170()</div></div><div style=3D"font-famil=
y:arial,sans-serif;font-size:13px">=3D=3D=3D=3D more message ignored =3D=3D=
=3D=3D</div><div class=3D"" style=3D"font-family:arial,sans-serif;font-size=
:13px"><br></div></div><div class=3D"" style=3D"font-family:arial,sans-seri=
f;font-size:13px"><br></div><div><font face=3D"arial, sans-serif">I sent em=
ails to the openstack mailing list and they gave me a few suggestions. At l=
ast, Bob Ball suggested I should probably ask this question on xen-devel ma=
iling list.=C2=A0</font><span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">Any help will be highly appreciated! Thanks,</span></div><div><spa=
n style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></div><d=
iv><span style=3D"font-family:arial,sans-serif;font-size:13px">Original dis=
cussion on openstack mailing list:=C2=A0</span></div><div><font face=3D"ari=
al, sans-serif"><a href=3D"http://www.gossamer-threads.com/lists/openstack/=
dev/42337">http://www.gossamer-threads.com/lists/openstack/dev/42337</a></f=
ont></div><div><br></div><div><br></div><div><font face=3D"arial, sans-seri=
f">-Xing=C2=A0</font></div><div><font face=3D"arial, sans-serif"><br></font=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br=
></span></div></div>

--001a11c1b2f6e8818f0507adbe40--


--===============2184966563714336243==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2184966563714336243==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 07:53:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 07:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XopDC-00083w-EP; Thu, 13 Nov 2014 07:53:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linxingnku@gmail.com>) id 1XocrL-00012B-K6
	for xen-devel@lists.xen.org; Wed, 12 Nov 2014 18:41:39 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	F7/EB-02702-2E9A3645; Wed, 12 Nov 2014 18:41:38 +0000
X-Env-Sender: linxingnku@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415817697!12131479!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18534 invoked from network); 12 Nov 2014 18:41:37 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Nov 2014 18:41:37 -0000
Received: by mail-wi0-f178.google.com with SMTP id bs8so5837168wib.11
	for <xen-devel@lists.xen.org>; Wed, 12 Nov 2014 10:41:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=z009jxF79/OX07f1WFqw6K17IH4DygCfFuKKdIz/3fY=;
	b=az48S3o3pLAmeB1AQWkhZjAHrGpRHFBa7/cM9Q8a5Ew8ltfRXwtbIg5f/b3b9n729e
	49VDV2TmN8/c5Tu+zUpTDHYBj0uiLgHCmRuq8a3pf+7w8WpBa5Pw/kxefzVsI/1OjhCQ
	J/UGd/qh7r4WbQREcTWUrUr1rcXlsbufsrg5Gx8b5w3wJ5rUUQhcR+LJofSAfPcNceYO
	QVwt8ZWPDN8EJOSH6irVckVp+Gw5IsDMeE1Fns0OV75Sfzoome8OPg/IwK1f3glzcYIZ
	6keyOYDk0Ah6CsNPX2kcxjwgRfrcqrG6QiHuj68k7el/bzOr+gewCTmiucZI48A2AFxl
	pIIQ==
MIME-Version: 1.0
X-Received: by 10.194.249.136 with SMTP id yu8mr45719570wjc.30.1415817697196; 
	Wed, 12 Nov 2014 10:41:37 -0800 (PST)
Received: by 10.27.132.215 with HTTP; Wed, 12 Nov 2014 10:41:37 -0800 (PST)
Date: Wed, 12 Nov 2014 11:41:37 -0700
Message-ID: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
From: Xing Lin <linxingnku@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 13 Nov 2014 07:53:01 +0000
Subject: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2184966563714336243=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2184966563714336243==
Content-Type: multipart/alternative; boundary=001a11c1b2f6e8818f0507adbe40

--001a11c1b2f6e8818f0507adbe40
Content-Type: text/plain; charset=UTF-8

Hi,

I am aware that Xen via libvirt is in the group C support for openstack but
since I am not able to install xenserver iso at compute machines I have, I
have to consider to use xen with libvirt (xcp-xapi is not available for
ubuntu14.04). I have three nodes, each one running ubuntu 14.04. I follow
the instruction to install juno in ubuntu 14.04 and it works (I can create
instances from openstack GUI - horizon) when I use kvm as the hypervisor at
the compute node . However, if I switch to use xen as the hypervisor by
installing xen-hypervisor-amd64 or nova-compute-xen, it will fail to create
instances. It complained "backend for qemu disk is not ready". I checked
and did not find qemu process running in dom0. I could not find
/etc/init.d/xencommons either. Then, I compiled and installed xen-4.4 from
source code and I got xencommons in /etc/init.d. qemu process is running in
dom0. However, the dom0 kernel crashes this time when I try to launch an
instance from openstack GUI. I am able to create a xen guest with
virt-install from command line, with the following command.

"$ virt-install --connect=xen:/// --name u14.04.3 --ram 1024 --disk
u14.04.3.img,size=4,driver_name=qemu --location
http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/ --network
bridge=virbr0"


dmesg:

[ 9443.130600] blkfront: xvda: flush diskcache: enabled; persistent grants:
enabled; indirect descriptors: disabled;
[ 9443.132818]  xvda: xvda1
[ 9444.604489] xen:grant_table: WARNING: g.e. 0x30 still in use!
[ 9444.604496] deferring g.e. 0x30 (pfn 0xffffffffffffffff)
[ 9444.604499] xen:grant_table: WARNING: g.e. 0x31 still in use!
[ 9444.604502] deferring g.e. 0x31 (pfn 0xffffffffffffffff)
[ 9444.604505] xen:grant_table: WARNING: g.e. 0x32 still in use!
[ 9444.604508] deferring g.e. 0x32 (pfn 0xffffffffffffffff)
  ==== lots of them====
[ 9444.604719] xen:grant_table: WARNING: g.e. 0xe still in use!
[ 9444.604721] deferring g.e. 0xe (pfn 0xffffffffffffffff)
[ 9444.604723] xen:grant_table: WARNING: g.e. 0xd still in use!
[ 9444.604725] deferring g.e. 0xd (pfn 0xffffffffffffffff)
[ 9448.325408] ------------[ cut here ]------------
[ 9448.325421] WARNING: CPU: 5 PID: 19902 at
/build/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+0x
1a9/0x1b0()
[ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF          O
3.13.0-33-generic #58-Ubuntu
[ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS 2.1.15
09/02/2010
[ 9448.325497]  0000000000000009 ffff8802d13d9aa8 ffffffff8171bd04
0000000000000000
[ 9448.325501]  ffff8802d13d9ae0 ffffffff810676cd 0000000000000000
0000000000000001
[ 9448.325505]  ffff88030418ffe0 ffff88031d6ab180 0000000000000010
ffff8802d13d9af0
[ 9448.325509] Call Trace:
[ 9448.325518]  [<ffffffff8171bd04>] dump_stack+0x45/0x56
[ 9448.325523]  [<ffffffff810676cd>] warn_slowpath_common+0x7d/0xa0
[ 9448.325526]  [<ffffffff810677aa>] warn_slowpath_null+0x1a/0x20
[ 9448.325530]  [<ffffffff81004e99>] xen_mc_flush+0x1a9/0x1b0
[ 9448.325534]  [<ffffffff81006b99>] xen_set_pud_hyper+0x109/0x110
[ 9448.325538]  [<ffffffff81006c3b>] xen_set_pud+0x9b/0xb0
[ 9448.325543]  [<ffffffff81177f06>] __pmd_alloc+0xd6/0x110
[ 9448.325548]  [<ffffffff81182218>] move_page_tables+0x678/0x720
[ 9448.325552]  [<ffffffff8117ddb7>] ? vma_adjust+0x337/0x7d0
[ 9448.325557]  [<ffffffff811c23fd>] shift_arg_pages+0xbd/0x1b0
[ 9448.325560]  [<ffffffff81181671>] ? mprotect_fixup+0x151/0x290
[ 9448.325564]  [<ffffffff811c26cb>] setup_arg_pages+0x1db/0x200
[ 9448.325570]  [<ffffffff81213edc>] load_elf_binary+0x41c/0xd80
[ 9448.325576]  [<ffffffff8131d503>] ? ima_get_action+0x23/0x30
[ 9448.325579]  [<ffffffff8131c7e2>] ? process_measurement+0x82/0x2c0
[ 9448.325584]  [<ffffffff811c2f7f>] search_binary_handler+0x8f/0x1b0
[ 9448.325587]  [<ffffffff811c44f7>] do_execve_common.isra.22+0x5a7/0x7e0
[ 9448.325591]  [<ffffffff811c49c6>] SyS_execve+0x36/0x50
[ 9448.325596]  [<ffffffff8172cc99>] stub_execve+0x69/0xa0
[ 9448.325599] ---[ end trace 53ac16782e751c0a ]---
[ 9448.347994] ------------[ cut here ]------------
[ 9448.348004] WARNING: CPU: 1 PID: 19902 at
/build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
==== more message ignored ====


I sent emails to the openstack mailing list and they gave me a few
suggestions. At last, Bob Ball suggested I should probably ask this
question on xen-devel mailing list. Any help will be highly appreciated!
Thanks,

Original discussion on openstack mailing list:
http://www.gossamer-threads.com/lists/openstack/dev/42337


-Xing

--001a11c1b2f6e8818f0507adbe40
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,=C2=A0<div><br></div><div><span style=3D"font-family:ar=
ial,sans-serif;font-size:13px">I am aware that Xen via libvirt is in the gr=
oup C support for openstack but since I am not able to install xenserver is=
o at compute machines I have, I have to consider to use xen with libvirt (x=
cp-xapi is not available for ubuntu14.04). I have three nodes, each one run=
ning ubuntu 14.04. I follow the instruction to install juno in ubuntu 14.04=
 and it works (I can create instances from openstack GUI - horizon) when I =
use kvm as the hypervisor at the compute node . However, if I switch to use=
 xen as the hypervisor by installing xen-hypervisor-amd64 or nova-compute-x=
en, it will fail to create instances. It complained &quot;backend for qemu =
disk is not ready&quot;. I checked and did not find qemu process running in=
 dom0.=C2=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13=
px">I could not find /etc/init.d/xencommons either.=C2=A0</span><span style=
=3D"font-family:arial,sans-serif;font-size:13px">Then, I compiled and insta=
lled xen-4.4 from source code and I got xencommons in /etc/init.d. qemu pro=
cess is running in dom0. However, the dom0 kernel crashes this time when I =
try to launch an instance from openstack GUI. I am able to create a xen gue=
st with virt-install from command line, with the following command.=C2=A0</=
span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"=
><br></span></div><div><span style=3D"font-family:arial,sans-serif;font-siz=
e:13px">&quot;$ virt-install --connect=3Dxen:/// --name u14.04.3 --ram 1024=
 --disk u14.04.3.img,size=3D4,driver_name=3Dqemu --location=C2=A0</span><a =
href=3D"http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/" ta=
rget=3D"_blank" style=3D"font-family:arial,sans-serif;font-size:13px">http:=
//ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/</a><span style=
=3D"font-family:arial,sans-serif;font-size:13px">=C2=A0--network bridge=3Dv=
irbr0&quot;</span><span style=3D"font-family:arial,sans-serif;font-size:13p=
x"><br></span></div><div><span style=3D"font-family:arial,sans-serif;font-s=
ize:13px"><br></span></div><div><span style=3D"font-family:arial,sans-serif=
;font-size:13px"><br></span></div><div><div style=3D"font-family:arial,sans=
-serif;font-size:13px">dmesg:=C2=A0</div><div style=3D"font-family:arial,sa=
ns-serif;font-size:13px"><br></div><div style=3D"font-family:arial,sans-ser=
if;font-size:13px"><div>[ 9443.130600] blkfront: xvda: flush diskcache: ena=
bled; persistent grants: enabled; indirect descriptors: disabled;</div><div=
>[ 9443.132818] =C2=A0xvda: xvda1</div><div>[ 9444.604489] xen:grant_table:=
 WARNING: g.e. 0x30 still in use!</div><div>[ 9444.604496] deferring g.e. 0=
x30 (pfn 0xffffffffffffffff)</div><div>[ 9444.604499] xen:grant_table: WARN=
ING: g.e. 0x31 still in use!</div><div>[ 9444.604502] deferring g.e. 0x31 (=
pfn 0xffffffffffffffff)</div><div>[ 9444.604505] xen:grant_table: WARNING: =
g.e. 0x32 still in use!</div><div>[ 9444.604508] deferring g.e. 0x32 (pfn 0=
xffffffffffffffff)</div></div><div style=3D"font-family:arial,sans-serif;fo=
nt-size:13px">=C2=A0 =3D=3D=3D=3D lots of them=3D=3D=3D=3D</div><div style=
=3D"font-family:arial,sans-serif;font-size:13px"><div>[ 9444.604719] xen:gr=
ant_table: WARNING: g.e. 0xe still in use!</div><div>[ 9444.604721] deferri=
ng g.e. 0xe (pfn 0xffffffffffffffff)</div><div>[ 9444.604723] xen:grant_tab=
le: WARNING: g.e. 0xd still in use!</div><div>[ 9444.604725] deferring g.e.=
 0xd (pfn 0xffffffffffffffff)</div><div>[ 9448.325408] ------------[ cut he=
re ]------------</div><div>[ 9448.325421] WARNING: CPU: 5 PID: 19902 at /bu=
ild/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+0x</div>=
<div>1a9/0x1b0()</div></div><div style=3D"font-family:arial,sans-serif;font=
-size:13px"><div>[ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0O 3.13.0-33-generic #58-Ubuntu</div><div>=
[ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS 2.1.15 =
09/02/2010</div><div>[ 9448.325497] =C2=A00000000000000009 ffff8802d13d9aa8=
 ffffffff8171bd04 0000000000000000</div><div>[ 9448.325501] =C2=A0ffff8802d=
13d9ae0 ffffffff810676cd 0000000000000000 0000000000000001</div><div>[ 9448=
.325505] =C2=A0ffff88030418ffe0 ffff88031d6ab180 0000000000000010 ffff8802d=
13d9af0</div><div>[ 9448.325509] Call Trace:</div><div>[ 9448.325518] =C2=
=A0[&lt;ffffffff8171bd04&gt;] dump_stack+0x45/0x56</div><div>[ 9448.325523]=
 =C2=A0[&lt;ffffffff810676cd&gt;] warn_slowpath_common+0x7d/0xa0</div><div>=
[ 9448.325526] =C2=A0[&lt;ffffffff810677aa&gt;] warn_slowpath_null+0x1a/0x2=
0</div><div>[ 9448.325530] =C2=A0[&lt;ffffffff81004e99&gt;] xen_mc_flush+0x=
1a9/0x1b0</div><div>[ 9448.325534] =C2=A0[&lt;ffffffff81006b99&gt;] xen_set=
_pud_hyper+0x109/0x110</div><div>[ 9448.325538] =C2=A0[&lt;ffffffff81006c3b=
&gt;] xen_set_pud+0x9b/0xb0</div><div>[ 9448.325543] =C2=A0[&lt;ffffffff811=
77f06&gt;] __pmd_alloc+0xd6/0x110</div><div>[ 9448.325548] =C2=A0[&lt;fffff=
fff81182218&gt;] move_page_tables+0x678/0x720</div><div>[ 9448.325552] =C2=
=A0[&lt;ffffffff8117ddb7&gt;] ? vma_adjust+0x337/0x7d0</div><div>[ 9448.325=
557] =C2=A0[&lt;ffffffff811c23fd&gt;] shift_arg_pages+0xbd/0x1b0</div><div>=
[ 9448.325560] =C2=A0[&lt;ffffffff81181671&gt;] ? mprotect_fixup+0x151/0x29=
0</div><div>[ 9448.325564] =C2=A0[&lt;ffffffff811c26cb&gt;] setup_arg_pages=
+0x1db/0x200</div><div>[ 9448.325570] =C2=A0[&lt;ffffffff81213edc&gt;] load=
_elf_binary+0x41c/0xd80</div><div>[ 9448.325576] =C2=A0[&lt;ffffffff8131d50=
3&gt;] ? ima_get_action+0x23/0x30</div><div>[ 9448.325579] =C2=A0[&lt;fffff=
fff8131c7e2&gt;] ? process_measurement+0x82/0x2c0</div><div>[ 9448.325584] =
=C2=A0[&lt;ffffffff811c2f7f&gt;] search_binary_handler+0x8f/0x1b0</div><div=
>[ 9448.325587] =C2=A0[&lt;ffffffff811c44f7&gt;] do_execve_common.isra.22+0=
x5a7/0x7e0</div><div>[ 9448.325591] =C2=A0[&lt;ffffffff811c49c6&gt;] SyS_ex=
ecve+0x36/0x50</div><div>[ 9448.325596] =C2=A0[&lt;ffffffff8172cc99&gt;] st=
ub_execve+0x69/0xa0</div><div>[ 9448.325599] ---[ end trace 53ac16782e751c0=
a ]---</div><div>[ 9448.347994] ------------[ cut here ]------------</div><=
div>[ 9448.348004] WARNING: CPU: 1 PID: 19902 at /build/buildd/linux-3.13.0=
/mm/mmap.c:2736 exit_mmap+0x16b/0x170()</div></div><div style=3D"font-famil=
y:arial,sans-serif;font-size:13px">=3D=3D=3D=3D more message ignored =3D=3D=
=3D=3D</div><div class=3D"" style=3D"font-family:arial,sans-serif;font-size=
:13px"><br></div></div><div class=3D"" style=3D"font-family:arial,sans-seri=
f;font-size:13px"><br></div><div><font face=3D"arial, sans-serif">I sent em=
ails to the openstack mailing list and they gave me a few suggestions. At l=
ast, Bob Ball suggested I should probably ask this question on xen-devel ma=
iling list.=C2=A0</font><span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">Any help will be highly appreciated! Thanks,</span></div><div><spa=
n style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></div><d=
iv><span style=3D"font-family:arial,sans-serif;font-size:13px">Original dis=
cussion on openstack mailing list:=C2=A0</span></div><div><font face=3D"ari=
al, sans-serif"><a href=3D"http://www.gossamer-threads.com/lists/openstack/=
dev/42337">http://www.gossamer-threads.com/lists/openstack/dev/42337</a></f=
ont></div><div><br></div><div><br></div><div><font face=3D"arial, sans-seri=
f">-Xing=C2=A0</font></div><div><font face=3D"arial, sans-serif"><br></font=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br=
></span></div></div>

--001a11c1b2f6e8818f0507adbe40--


--===============2184966563714336243==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2184966563714336243==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 08:12:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08:12:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XopW2-0000YP-Ng; Thu, 13 Nov 2014 08:12:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XopW2-0000YK-1A
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:12:30 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	C0/EA-07724-DE764645; Thu, 13 Nov 2014 08:12:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415866347!7317052!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15324 invoked from network); 13 Nov 2014 08:12:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 08:12:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,375,1413244800"; d="scan'208";a="192300670"
Message-ID: <1415866345.31613.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Thu, 13 Nov 2014 08:12:25 +0000
In-Reply-To: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 11:41 -0700, Xing Lin wrote:

> 
> [ 9448.347994] ------------[ cut here ]------------
> [ 9448.348004] WARNING: CPU: 1 PID: 19902 at /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
> ==== more message ignored ====

The most interesting bits of the message are likely to be the lines
which follow here, i.e. the kernel stack trace and associated info.
Please can you paste the complete log from "cut here" until the end.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:12:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08:12:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XopW2-0000YP-Ng; Thu, 13 Nov 2014 08:12:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XopW2-0000YK-1A
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:12:30 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	C0/EA-07724-DE764645; Thu, 13 Nov 2014 08:12:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415866347!7317052!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15324 invoked from network); 13 Nov 2014 08:12:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 08:12:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,375,1413244800"; d="scan'208";a="192300670"
Message-ID: <1415866345.31613.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Thu, 13 Nov 2014 08:12:25 +0000
In-Reply-To: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 11:41 -0700, Xing Lin wrote:

> 
> [ 9448.347994] ------------[ cut here ]------------
> [ 9448.348004] WARNING: CPU: 1 PID: 19902 at /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
> ==== more message ignored ====

The most interesting bits of the message are likely to be the lines
which follow here, i.e. the kernel stack trace and associated info.
Please can you paste the complete log from "cut here" until the end.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:14:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XopXn-0000dp-7A; Thu, 13 Nov 2014 08:14:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XopXl-0000dg-Jz
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:14:17 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	77/91-17735-85864645; Thu, 13 Nov 2014 08:14:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415866456!7317406!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23433 invoked from network); 13 Nov 2014 08:14:16 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 08:14:16 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 08:14:14 +0000
Message-Id: <54647666020000780004713A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 08:14:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Li Liang" <liang.z.li@intel.com>
References: <1415856677-25814-1-git-send-email-liang.z.li@intel.com>
In-Reply-To: <1415856677-25814-1-git-send-email-liang.z.li@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Turn on the pdpe1gb cpuid flag by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 06:31, <liang.z.li@intel.com> wrote:

Apart from the subject being kind of wrong (you're not turning it on
by default, but only expose it if the hardware supports it), ...

> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -192,6 +192,7 @@ static void intel_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_ABM));
>          regs[3] &= (bitmaskof(X86_FEATURE_NX) |
>                      bitmaskof(X86_FEATURE_LM) |
> +                    bitmaskof(X86_FEATURE_PAGE1GB) |
>                      bitmaskof(X86_FEATURE_SYSCALL) |
>                      bitmaskof(X86_FEATURE_RDTSCP));
>          break;

... this is incomplete: The AMD function would seem to need the
same change, and the !PAE special casing in xc_cpuid_hvm_policy()
should imo disable the flag.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:14:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XopXn-0000dp-7A; Thu, 13 Nov 2014 08:14:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XopXl-0000dg-Jz
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:14:17 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	77/91-17735-85864645; Thu, 13 Nov 2014 08:14:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415866456!7317406!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23433 invoked from network); 13 Nov 2014 08:14:16 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 08:14:16 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 08:14:14 +0000
Message-Id: <54647666020000780004713A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 08:14:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Li Liang" <liang.z.li@intel.com>
References: <1415856677-25814-1-git-send-email-liang.z.li@intel.com>
In-Reply-To: <1415856677-25814-1-git-send-email-liang.z.li@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Turn on the pdpe1gb cpuid flag by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 06:31, <liang.z.li@intel.com> wrote:

Apart from the subject being kind of wrong (you're not turning it on
by default, but only expose it if the hardware supports it), ...

> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -192,6 +192,7 @@ static void intel_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_ABM));
>          regs[3] &= (bitmaskof(X86_FEATURE_NX) |
>                      bitmaskof(X86_FEATURE_LM) |
> +                    bitmaskof(X86_FEATURE_PAGE1GB) |
>                      bitmaskof(X86_FEATURE_SYSCALL) |
>                      bitmaskof(X86_FEATURE_RDTSCP));
>          break;

... this is incomplete: The AMD function would seem to need the
same change, and the !PAE special casing in xc_cpuid_hvm_policy()
should imo disable the flag.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:17:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08:17:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XopaN-0000nN-PG; Thu, 13 Nov 2014 08:16:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XopaM-0000nE-7h
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:16:58 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	91/A7-09842-9F864645; Thu, 13 Nov 2014 08:16:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415866615!8935469!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8876 invoked from network); 13 Nov 2014 08:16:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 08:16:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,375,1413244800"; d="scan'208";a="192301751"
Message-ID: <1415866614.31613.24.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 13 Nov 2014 08:16:54 +0000
In-Reply-To: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] xl: Return proper error codes for
 block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 17:31 +0000, George Dunlap wrote:
> @@ -6444,6 +6445,7 @@ int main_blockdetach(int argc, char **argv)
>      rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
>      if (rc) {
>          fprintf(stderr, "libxl_device_disk_remove failed.\n");
> +        return 1;
>      }
>      libxl_device_disk_dispose(&disk);
>      return rc;

This one seems odd to me, you have inadvertently arranged to skip the
disk dispose and the old code returned non-zero in the failure case
already, since it returns rc.

If it is important to return 0 or 1 then perhaps the last line should
just be:
        return rc ? 1 : 0;
        
Or maybe the ultimate caller (i.e. the xl command dispatcher) ought to
be translating libxl ERROR_FOO into suitable process exit codes (perhaps
as simplistically as suggested above).

Skipping the dispose is a memory leak, albeit in a process which is just
about to die, but we like to try and keep xl "valgrind clean" so far as
possible such that leaks in the underlying libxl stand out.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:17:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08:17:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XopaN-0000nN-PG; Thu, 13 Nov 2014 08:16:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XopaM-0000nE-7h
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:16:58 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	91/A7-09842-9F864645; Thu, 13 Nov 2014 08:16:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415866615!8935469!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8876 invoked from network); 13 Nov 2014 08:16:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 08:16:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,375,1413244800"; d="scan'208";a="192301751"
Message-ID: <1415866614.31613.24.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 13 Nov 2014 08:16:54 +0000
In-Reply-To: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] xl: Return proper error codes for
 block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 17:31 +0000, George Dunlap wrote:
> @@ -6444,6 +6445,7 @@ int main_blockdetach(int argc, char **argv)
>      rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
>      if (rc) {
>          fprintf(stderr, "libxl_device_disk_remove failed.\n");
> +        return 1;
>      }
>      libxl_device_disk_dispose(&disk);
>      return rc;

This one seems odd to me, you have inadvertently arranged to skip the
disk dispose and the old code returned non-zero in the failure case
already, since it returns rc.

If it is important to return 0 or 1 then perhaps the last line should
just be:
        return rc ? 1 : 0;
        
Or maybe the ultimate caller (i.e. the xl command dispatcher) ought to
be translating libxl ERROR_FOO into suitable process exit codes (perhaps
as simplistically as suggested above).

Skipping the dispose is a memory leak, albeit in a process which is just
about to die, but we like to try and keep xl "valgrind clean" so far as
possible such that leaks in the underlying libxl stand out.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:17:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08: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 1XopaS-0000oH-6x; Thu, 13 Nov 2014 08:17:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XopaR-0000no-Cj
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:17:03 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	4A/77-22819-EF864645; Thu, 13 Nov 2014 08:17:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415866622!5754660!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9779 invoked from network); 13 Nov 2014 08:17:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Nov 2014 08:17:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 08:17:02 +0000
Message-Id: <5464770E0200007800047145@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 08:17:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Robert Hu" <robert.hu@intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A5C024@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A5C024@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay]Xen-4.5.0-RC1: Not all PFs are available
 if assign multi VT-d devices to Wndows guest VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 03:23, <robert.hu@intel.com> wrote:
> Bug detailed description:
> --------------------------
> Assign multi PF devices(I350, 82576, 82599) to installing Windows8.1 guest 
> VM
> with xl tool. After guest boot up, one PF could not get IP address and shows 
> as
> "Network cable unplugged", while other two PF devices could get IP address 
> and
> available.
> If only assign this unavailable PF to Windows guest VM, it worked normally.
> The issue could not be duplicated with multi VF devices assigned to Windows
> guest VM. 
> 
> Reproduce steps:
> ----------------
> 1. Create a HVM guest config file with multi PF devices(I350, 82576, 82599)
> assigned to installing Windows8.1 guest VM
> 2. Using xl tool to start guest with command "xl create hvm_config_file"
> 3. After guest boot up, check the network device, issue occurred.
> 
> Current result:
> ----------------
> Assign muti PF devices to windows guest, at least one PF device is not
> availabel.

And the same question again - without this being an Intel supported
scenario, and without it being excluded that this simply is a driver
issue, why do you report it in the first place. Plus I very much think
it ought to be your engineers to look into this (at least initially), and
in such a case posting with (at least) initial investigation results would
be more useful.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:17:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08: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 1XopaS-0000oH-6x; Thu, 13 Nov 2014 08:17:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XopaR-0000no-Cj
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:17:03 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	4A/77-22819-EF864645; Thu, 13 Nov 2014 08:17:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1415866622!5754660!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9779 invoked from network); 13 Nov 2014 08:17:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Nov 2014 08:17:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 08:17:02 +0000
Message-Id: <5464770E0200007800047145@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 08:17:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Robert Hu" <robert.hu@intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A5C024@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A5C024@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay]Xen-4.5.0-RC1: Not all PFs are available
 if assign multi VT-d devices to Wndows guest VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 03:23, <robert.hu@intel.com> wrote:
> Bug detailed description:
> --------------------------
> Assign multi PF devices(I350, 82576, 82599) to installing Windows8.1 guest 
> VM
> with xl tool. After guest boot up, one PF could not get IP address and shows 
> as
> "Network cable unplugged", while other two PF devices could get IP address 
> and
> available.
> If only assign this unavailable PF to Windows guest VM, it worked normally.
> The issue could not be duplicated with multi VF devices assigned to Windows
> guest VM. 
> 
> Reproduce steps:
> ----------------
> 1. Create a HVM guest config file with multi PF devices(I350, 82576, 82599)
> assigned to installing Windows8.1 guest VM
> 2. Using xl tool to start guest with command "xl create hvm_config_file"
> 3. After guest boot up, check the network device, issue occurred.
> 
> Current result:
> ----------------
> Assign muti PF devices to windows guest, at least one PF device is not
> availabel.

And the same question again - without this being an Intel supported
scenario, and without it being excluded that this simply is a driver
issue, why do you report it in the first place. Plus I very much think
it ought to be your engineers to look into this (at least initially), and
in such a case posting with (at least) initial investigation results would
be more useful.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:19:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xopcl-00011n-PQ; Thu, 13 Nov 2014 08:19:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xopck-00011g-Gu
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:19:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	96/D5-09936-D8964645; Thu, 13 Nov 2014 08:19:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415866765!12406436!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14395 invoked from network); 13 Nov 2014 08:19:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 08:19:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 08:19:25 +0000
Message-Id: <5464779D0200007800047148@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 08:19:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Robert Hu" <robert.hu@intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A5E04A@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A5E04A@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay]Xen-4.5-RC1: Dom0 failed to resume from S3
 power state with operations on '/sys/power/state'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 03:32, <robert.hu@intel.com> wrote:
> Hi,
> 
> This is a separated report for bug 
> http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897 
> 
> Environment:
> ------------
> Service Arch (ia32/ia32e/IA64): ia32e
> Guest Arch (ia32/ia32e/IA64): 
> Guest OS Type (Linux/Windows):
> Change Set: Xen4.5-RC1 (git:1b068a5b485062c862c20d8ba7674faa97ee3714)
> Hardware: Ivybridge-EP, Grantley-EP
> Other:
> 
> 
> Bug detailed description:
> --------------------------
> Boot into Dom0 (kernel 3.17.0), execute the command "echo mem > 
> /sys/power/state", to make Dom0
> system get into S3 sleep state, then press any key or power button to resume 
> 
> from S3
> state, but failed and system hangs up with black screen.
> 
> 
> Reproduce steps:
> ----------------
> 1. Boot into Dom0, execute the command "echo mem > /sys/power/state" to make
> Dom0 get into S3 state.
> 2. Press any key  or press power button to resume from S3,no resume to dom0
> 
> Current result:
> ----------------
> Dom0 system cannot resume from S3 power state.

Considering the Konrad confirmed this to work on other hardware
it's likely going to be difficult to analyze this for anyone not in
possession of a machine where things don't work as expected. I.e.
again presumably a case where at least initial investigation would
ideally be done by your engineers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:19:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xopcl-00011n-PQ; Thu, 13 Nov 2014 08:19:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xopck-00011g-Gu
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:19:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	96/D5-09936-D8964645; Thu, 13 Nov 2014 08:19:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415866765!12406436!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14395 invoked from network); 13 Nov 2014 08:19:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 08:19:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 08:19:25 +0000
Message-Id: <5464779D0200007800047148@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 08:19:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Robert Hu" <robert.hu@intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A5E04A@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A5E04A@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay]Xen-4.5-RC1: Dom0 failed to resume from S3
 power state with operations on '/sys/power/state'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 03:32, <robert.hu@intel.com> wrote:
> Hi,
> 
> This is a separated report for bug 
> http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897 
> 
> Environment:
> ------------
> Service Arch (ia32/ia32e/IA64): ia32e
> Guest Arch (ia32/ia32e/IA64): 
> Guest OS Type (Linux/Windows):
> Change Set: Xen4.5-RC1 (git:1b068a5b485062c862c20d8ba7674faa97ee3714)
> Hardware: Ivybridge-EP, Grantley-EP
> Other:
> 
> 
> Bug detailed description:
> --------------------------
> Boot into Dom0 (kernel 3.17.0), execute the command "echo mem > 
> /sys/power/state", to make Dom0
> system get into S3 sleep state, then press any key or power button to resume 
> 
> from S3
> state, but failed and system hangs up with black screen.
> 
> 
> Reproduce steps:
> ----------------
> 1. Boot into Dom0, execute the command "echo mem > /sys/power/state" to make
> Dom0 get into S3 state.
> 2. Press any key  or press power button to resume from S3,no resume to dom0
> 
> Current result:
> ----------------
> Dom0 system cannot resume from S3 power state.

Considering the Konrad confirmed this to work on other hardware
it's likely going to be difficult to analyze this for anyone not in
possession of a machine where things don't work as expected. I.e.
again presumably a case where at least initial investigation would
ideally be done by your engineers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:31:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xopoa-0001Mz-2h; Thu, 13 Nov 2014 08:31:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XopoY-0001Mu-Vt
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:31:39 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	F2/18-26652-A6C64645; Thu, 13 Nov 2014 08:31:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415867497!11029615!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25848 invoked from network); 13 Nov 2014 08:31:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 08:31:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 08:31:37 +0000
Message-Id: <54647A78020000780004716A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 08:31:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Emmanuel Amaro" <amaro@gatech.edu>
References: <625C2CDC-8017-43A4-A363-661697394945@gatech.edu>
In-Reply-To: <625C2CDC-8017-43A4-A363-661697394945@gatech.edu>
Mime-Version: 1.0
Content-Length: 2039
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] About sharing pages between Xen and guest kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDEzLjExLjE0IGF0IDAwOjUyLCA8YW1hcm9AZ2F0ZWNoLmVkdT4gd3JvdGU6Cj4gSGVs
bG8sCj4gCj4gSSBhbSB0cnlpbmcgdG8gc2V0IHVwIGEgc2hhcmVkIHBhZ2UgYmV0d2VlbiB0aGUg
aHlwZXJ2aXNvciBhbmQgYSBMaW51eCBndWVzdCAKPiBrZXJuZWwuIEluIFhlbiBJIGFtIGRvaW5n
Ogo+IAo+IHZvaWQgKnB0ciA9IGFsbG9jX3hlbmhlYXBfcGFnZSgpOwo+IHNoYXJlX3hlbl9wYWdl
X3dpdGhfZ3Vlc3QodmlydF90b19wYWdlKHB0ciksIGN1cnJlbnQtPmRvbWFpbiwgCj4gWEVOU0hB
UkVfd3JpdGFibGUpOwo+IHVuc2lnbmVkIGludCBtZm4gPSB2aXJ0X3RvX21mbihwdHIpOwo+IAo+
IEFuZCBteSBwbGFuIHdhcyB0byBwYXNzIHRoZSBtZm4gdG8gdGhlIGd1ZXN0IGtlcm5lbCBhbmQg
cmV0cmlldmUgdGhlIHBmbiAKPiB3aXRoIG1mbl90b19wZm4oKS4gSG93ZXZlciwgdGhpcyByZXR1
cm5lZCB+MC4gCj4gCj4gU28gSSB0b29rIGEgbG9vayBhdCBzaGFyZV94ZW5fcGFnZV93aXRoX2d1
ZXN0KCkgYW5kIEkgbm90aWNlZCBpdCBjYWxscyAKPiBzZXRfZ3Bmbl9mcm9tX21mbihtZm4sIElO
VkFMSURfTTJQX0VOVFJZKSwgCj4gd2hlcmUgSU5WQUxJRF9NMlBfRU5UUlkgPSB+MC4KPiAKPiBN
eSBxdWVzdGlvbnMgYXJlOgo+IAkxLiBEbyBJIGhhdmUgdG8gY2FsbCBzZXRfZ3Bmbl9mcm9tX21m
bigpIGFmdGVyIGNhbGxpbmcgCj4gc2hhcmVfeGVuX3BhZ2Vfd2l0aF9ndWVzdCgpIGluIHRoZSBo
eXBlcnZpc29yPwo+IAkyLiBJZiB5ZXMsIHdoYXQgZ3BmbiBzaG91bGQgSSB1c2U/IEkgYW0gdGhp
bmtpbmcgSSBjb3VsZCBhbGxvY2F0ZSBhIHBhZ2UgaW4gCj4gdGhlIGd1ZXN0LCBhbmQgcmV0cmll
dmUgdGhlIHBmbiB3aXRoIHBhZ2VfdG9fcGZuKCksIAo+IAlhbmQgdGhlbiBwYXNzIHRoYXQgdG8g
dGhlIGh5cGVydmlzb3IuIEJ1dCBJIGRvbuKAmXQga25vdyBpZiBJIGFtIAo+IG92ZXJjb21wbGlj
YXRpbmcgdGhpbmdzLgoKTm8sIHRoYXQgd291bGRuJ3QgYmUgY29ycmVjdCAoYXMgaXMgaW1wbGll
ZCBieSAyKS4gSW5zdGVhZCB5b3Ugd2FudAp0byBtYXAgdGhlIHBhZ2UgYmFzZWQgb24gaXRzIE1G
TiAoaS5lLiBwb3RlbnRpYWxseSB3aXRob3V0IGV2ZW4KZXN0YWJsaXNoaW5nIGEgUEZOIGZvciBp
dCkuIEJ1dCBJIHN1cHBvc2UgeW91IGxvb2tlZCBhdCBvdGhlcgpleGFtcGxlcyBpbiB0aGUgc291
cmNlIGNvZGUsIGFuZCB5b3Ugc2hvdWxkIGhhdmUgcmVhbGl6ZWQgdGhhdAp0aGlzIGlzbid0IHJl
YWxseSBtZWFudCB0byBiZSB1c2VkIGZvciBhcmJpdHJhcnkgbWVtb3J5IHNoYXJpbmcuClBlcmhh
cHMgeGVudHJhY2UncyBtYXBfdGJ1ZnMoKSB3b3VsZCBiZSB0aGUgY2xvc2VzdCByZWZlcmVuY2Ug
dG8KdXNlLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:31:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xopoa-0001Mz-2h; Thu, 13 Nov 2014 08:31:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XopoY-0001Mu-Vt
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 08:31:39 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	F2/18-26652-A6C64645; Thu, 13 Nov 2014 08:31:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1415867497!11029615!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25848 invoked from network); 13 Nov 2014 08:31:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 08:31:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 08:31:37 +0000
Message-Id: <54647A78020000780004716A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 08:31:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Emmanuel Amaro" <amaro@gatech.edu>
References: <625C2CDC-8017-43A4-A363-661697394945@gatech.edu>
In-Reply-To: <625C2CDC-8017-43A4-A363-661697394945@gatech.edu>
Mime-Version: 1.0
Content-Length: 2039
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] About sharing pages between Xen and guest kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDEzLjExLjE0IGF0IDAwOjUyLCA8YW1hcm9AZ2F0ZWNoLmVkdT4gd3JvdGU6Cj4gSGVs
bG8sCj4gCj4gSSBhbSB0cnlpbmcgdG8gc2V0IHVwIGEgc2hhcmVkIHBhZ2UgYmV0d2VlbiB0aGUg
aHlwZXJ2aXNvciBhbmQgYSBMaW51eCBndWVzdCAKPiBrZXJuZWwuIEluIFhlbiBJIGFtIGRvaW5n
Ogo+IAo+IHZvaWQgKnB0ciA9IGFsbG9jX3hlbmhlYXBfcGFnZSgpOwo+IHNoYXJlX3hlbl9wYWdl
X3dpdGhfZ3Vlc3QodmlydF90b19wYWdlKHB0ciksIGN1cnJlbnQtPmRvbWFpbiwgCj4gWEVOU0hB
UkVfd3JpdGFibGUpOwo+IHVuc2lnbmVkIGludCBtZm4gPSB2aXJ0X3RvX21mbihwdHIpOwo+IAo+
IEFuZCBteSBwbGFuIHdhcyB0byBwYXNzIHRoZSBtZm4gdG8gdGhlIGd1ZXN0IGtlcm5lbCBhbmQg
cmV0cmlldmUgdGhlIHBmbiAKPiB3aXRoIG1mbl90b19wZm4oKS4gSG93ZXZlciwgdGhpcyByZXR1
cm5lZCB+MC4gCj4gCj4gU28gSSB0b29rIGEgbG9vayBhdCBzaGFyZV94ZW5fcGFnZV93aXRoX2d1
ZXN0KCkgYW5kIEkgbm90aWNlZCBpdCBjYWxscyAKPiBzZXRfZ3Bmbl9mcm9tX21mbihtZm4sIElO
VkFMSURfTTJQX0VOVFJZKSwgCj4gd2hlcmUgSU5WQUxJRF9NMlBfRU5UUlkgPSB+MC4KPiAKPiBN
eSBxdWVzdGlvbnMgYXJlOgo+IAkxLiBEbyBJIGhhdmUgdG8gY2FsbCBzZXRfZ3Bmbl9mcm9tX21m
bigpIGFmdGVyIGNhbGxpbmcgCj4gc2hhcmVfeGVuX3BhZ2Vfd2l0aF9ndWVzdCgpIGluIHRoZSBo
eXBlcnZpc29yPwo+IAkyLiBJZiB5ZXMsIHdoYXQgZ3BmbiBzaG91bGQgSSB1c2U/IEkgYW0gdGhp
bmtpbmcgSSBjb3VsZCBhbGxvY2F0ZSBhIHBhZ2UgaW4gCj4gdGhlIGd1ZXN0LCBhbmQgcmV0cmll
dmUgdGhlIHBmbiB3aXRoIHBhZ2VfdG9fcGZuKCksIAo+IAlhbmQgdGhlbiBwYXNzIHRoYXQgdG8g
dGhlIGh5cGVydmlzb3IuIEJ1dCBJIGRvbuKAmXQga25vdyBpZiBJIGFtIAo+IG92ZXJjb21wbGlj
YXRpbmcgdGhpbmdzLgoKTm8sIHRoYXQgd291bGRuJ3QgYmUgY29ycmVjdCAoYXMgaXMgaW1wbGll
ZCBieSAyKS4gSW5zdGVhZCB5b3Ugd2FudAp0byBtYXAgdGhlIHBhZ2UgYmFzZWQgb24gaXRzIE1G
TiAoaS5lLiBwb3RlbnRpYWxseSB3aXRob3V0IGV2ZW4KZXN0YWJsaXNoaW5nIGEgUEZOIGZvciBp
dCkuIEJ1dCBJIHN1cHBvc2UgeW91IGxvb2tlZCBhdCBvdGhlcgpleGFtcGxlcyBpbiB0aGUgc291
cmNlIGNvZGUsIGFuZCB5b3Ugc2hvdWxkIGhhdmUgcmVhbGl6ZWQgdGhhdAp0aGlzIGlzbid0IHJl
YWxseSBtZWFudCB0byBiZSB1c2VkIGZvciBhcmJpdHJhcnkgbWVtb3J5IHNoYXJpbmcuClBlcmhh
cHMgeGVudHJhY2UncyBtYXBfdGJ1ZnMoKSB3b3VsZCBiZSB0aGUgY2xvc2VzdCByZWZlcmVuY2Ug
dG8KdXNlLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:34:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08: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 1Xopqv-0001cJ-JV; Thu, 13 Nov 2014 08:34:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xopqt-0001cE-RD
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 08:34:03 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	7F/56-17958-BFC64645; Thu, 13 Nov 2014 08:34:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415867641!8604980!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12182 invoked from network); 13 Nov 2014 08:34:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 08:34:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,375,1413244800"; d="scan'208";a="192304892"
Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.78)
	with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 03:34:00 -0500
Message-ID: <54646CF6.7090302@citrix.com>
Date: Thu, 13 Nov 2014 09:33:58 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
	<alpine.DEB.2.02.1411121629320.26318@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411121629320.26318@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: Kevin Wolf <kwolf@redhat.com>, xen-devel@lists.xenproject.org,
	George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 12/11/14 a les 18.41, Stefano Stabellini ha escrit:
> On Wed, 12 Nov 2014, Roger Pau Monne wrote:
>> This patch fixes two issues with persistent grants and the disk PV backend
>> (Qdisk):
>>
>>  - Don't use batch mappings when using persistent grants, doing so prevents
>>    unmapping single grants (the whole area has to be unmapped at once).
> 
> The real issue is that destroy_grant cannot work with batch_maps.
> One could reimplement destroy_grant to build a single array with all the
> grants to unmap and make a single xc_gnttab_munmap call.
> 
> Do you think that would be feasible?

Making destroy_grant work with batch maps using the current tree
structure is going to be quite complicated, because destroy_grant
iterates on every entry on the tree, and doesn't know which grants
belong to which regions.

IMHO a simpler solution would be to introduce another tree (or list)
that keeps track of grant-mapped regions, and on tear down use the data
in that list to unmap the regions. This way the current tree will still
be used to perform the grant_ref->vaddr translation, but on teardown the
newly introduced list would be used instead.

In general I was reluctant to do this because not using batch maps with
persistent grants should not introduce a noticeable performance
regression due to the fact that grants are only mapped once for the
whole life-cycle of the virtual disk. Also, if we plan to implement
indirect descriptors for Qdisk we really need to be able to unmap single
grants in order to purge the list, since in that case it's not possible
to keep all possible grants persistently mapped.

Since this alternate solution is easy to implement I will send a new
patch using this approach, then we can decide what to do.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 08:34:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 08: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 1Xopqv-0001cJ-JV; Thu, 13 Nov 2014 08:34:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xopqt-0001cE-RD
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 08:34:03 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	7F/56-17958-BFC64645; Thu, 13 Nov 2014 08:34:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415867641!8604980!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12182 invoked from network); 13 Nov 2014 08:34:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 08:34:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,375,1413244800"; d="scan'208";a="192304892"
Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.78)
	with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 03:34:00 -0500
Message-ID: <54646CF6.7090302@citrix.com>
Date: Thu, 13 Nov 2014 09:33:58 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
	<alpine.DEB.2.02.1411121629320.26318@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411121629320.26318@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: Kevin Wolf <kwolf@redhat.com>, xen-devel@lists.xenproject.org,
	George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 12/11/14 a les 18.41, Stefano Stabellini ha escrit:
> On Wed, 12 Nov 2014, Roger Pau Monne wrote:
>> This patch fixes two issues with persistent grants and the disk PV backend
>> (Qdisk):
>>
>>  - Don't use batch mappings when using persistent grants, doing so prevents
>>    unmapping single grants (the whole area has to be unmapped at once).
> 
> The real issue is that destroy_grant cannot work with batch_maps.
> One could reimplement destroy_grant to build a single array with all the
> grants to unmap and make a single xc_gnttab_munmap call.
> 
> Do you think that would be feasible?

Making destroy_grant work with batch maps using the current tree
structure is going to be quite complicated, because destroy_grant
iterates on every entry on the tree, and doesn't know which grants
belong to which regions.

IMHO a simpler solution would be to introduce another tree (or list)
that keeps track of grant-mapped regions, and on tear down use the data
in that list to unmap the regions. This way the current tree will still
be used to perform the grant_ref->vaddr translation, but on teardown the
newly introduced list would be used instead.

In general I was reluctant to do this because not using batch maps with
persistent grants should not introduce a noticeable performance
regression due to the fact that grants are only mapped once for the
whole life-cycle of the virtual disk. Also, if we plan to implement
indirect descriptors for Qdisk we really need to be able to unmap single
grants in order to purge the list, since in that case it's not possible
to keep all possible grants persistently mapped.

Since this alternate solution is easy to implement I will send a new
patch using this approach, then we can decide what to do.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:06:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoqLe-0002dt-LD; Thu, 13 Nov 2014 09:05:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoqLe-0002do-1V
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 09:05:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BF/BF-09842-D6474645; Thu, 13 Nov 2014 09:05:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415869549!12422054!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7846 invoked from network); 13 Nov 2014 09:05:49 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 09:05:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 09:05:48 +0000
Message-Id: <5464827B0200007800047188@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 09:05:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] delaying 4.4.2 and 4.3.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

All,

while the 3 month period since the previous stable releases would
expire at the beginning of December, looking at the number of
changes in the stable trees I don't think starting preparations right
now would make much sense. Unless I hear severe objections to
this plan, and unless 4.5 gets significantly delayed, I think we
should look at RC1s for them once 4.5 is (almost) out the door.
That'll also minimize collisions between testing needs 4.5 and the
stable releases have.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:06:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoqLe-0002dt-LD; Thu, 13 Nov 2014 09:05:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XoqLe-0002do-1V
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 09:05:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BF/BF-09842-D6474645; Thu, 13 Nov 2014 09:05:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415869549!12422054!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7846 invoked from network); 13 Nov 2014 09:05:49 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 09:05:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 09:05:48 +0000
Message-Id: <5464827B0200007800047188@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 09:05:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] delaying 4.4.2 and 4.3.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

All,

while the 3 month period since the previous stable releases would
expire at the beginning of December, looking at the number of
changes in the stable trees I don't think starting preparations right
now would make much sense. Unless I hear severe objections to
this plan, and unless 4.5 gets significantly delayed, I think we
should look at RC1s for them once 4.5 is (almost) out the door.
That'll also minimize collisions between testing needs 4.5 and the
stable releases have.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:12:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:12:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoqSD-0002vT-GA; Thu, 13 Nov 2014 09:12:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoqSC-0002vO-Ku
	for Xen-devel@lists.xen.org; Thu, 13 Nov 2014 09:12:36 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	C9/33-25714-30674645; Thu, 13 Nov 2014 09:12:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415869953!11082723!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1639 invoked from network); 13 Nov 2014 09:12:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 09:12:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,375,1413244800"; d="scan'208";a="190862343"
Message-ID: <1415869951.31613.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Thu, 13 Nov 2014 09:12:31 +0000
In-Reply-To: <546461A2.2070908@univention.de>
References: <546461A2.2070908@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xenstored crashes with SIGSEGV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 08:45 +0100, Philipp Hahn wrote:
> To me this looks like some memory corruption by some unknown code
> writing into some random memory space, which happens to be the tdb here.

I wonder if running xenstored under valgrind would be useful. I think
you'd want to stop xenstored from starting during normal boot and then
launch it with:
        valgrind /usr/local/sbin/xenstored -N
-N is to stay in the foreground, you might want to do this in a screen
session or something, alternatively you could investigate the --log-*
options in the valgrind manpage, together with the various
--trace-children* in order to follow the processes over its
daemonization.

I'm not sure what the impact on the system would be with this, but I
think it is probably ok unless you have massive xs load.

You'll need a version of valgrind with xen support in it, anything from
the last year or so should do I think.

Other than that we don't really have anyone who is an expert in that
aspect of the C xenstore/tdb who we can lean on for pointers (no pun
intended) etc, so in the absence of some sort of ability to trigger on
demand I'm not sure what else to suggest.

> 1. Has someone observed a similar crash?

I think you are the only one I've seen reporting this.

> 2. We've now also enabled "xenstored -T /log --verbose" to log the
> messages in the hope to find the triggering transaction, but until then
> is there something more we can do to track down the problem?
> 
> 3. the crash happens rarely and the host run fine most of the time. The
> crash mostly happens around midnight and seem to be guest-triggered, as
> the logs on the host don't show any activity like starting new or
> destroying running VMs. So far the problem only showed on host running
> Linux VMs. Other host running Windows VMs so far never showed that crash.

If it is really mostly happening around midnight then it might be worth
digging into the host and guest configs for cronjobs and the like, e.g.
log rotation stuff like that which might be tweaking things somehow.

Does this happen on multiple hosts, or just the one?

Do you rm the xenstore db on boot? It might have a persistent
corruption, aiui most folks using C xenstored are doing so or even
placing it on a tmpfs for performance reasons.

If you are running 4.1.x then I think oxenstored isn't an option, but it
might be something to consider when you upgrade.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:12:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:12:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoqSD-0002vT-GA; Thu, 13 Nov 2014 09:12:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoqSC-0002vO-Ku
	for Xen-devel@lists.xen.org; Thu, 13 Nov 2014 09:12:36 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	C9/33-25714-30674645; Thu, 13 Nov 2014 09:12:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415869953!11082723!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1639 invoked from network); 13 Nov 2014 09:12:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 09:12:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,375,1413244800"; d="scan'208";a="190862343"
Message-ID: <1415869951.31613.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Thu, 13 Nov 2014 09:12:31 +0000
In-Reply-To: <546461A2.2070908@univention.de>
References: <546461A2.2070908@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xenstored crashes with SIGSEGV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 08:45 +0100, Philipp Hahn wrote:
> To me this looks like some memory corruption by some unknown code
> writing into some random memory space, which happens to be the tdb here.

I wonder if running xenstored under valgrind would be useful. I think
you'd want to stop xenstored from starting during normal boot and then
launch it with:
        valgrind /usr/local/sbin/xenstored -N
-N is to stay in the foreground, you might want to do this in a screen
session or something, alternatively you could investigate the --log-*
options in the valgrind manpage, together with the various
--trace-children* in order to follow the processes over its
daemonization.

I'm not sure what the impact on the system would be with this, but I
think it is probably ok unless you have massive xs load.

You'll need a version of valgrind with xen support in it, anything from
the last year or so should do I think.

Other than that we don't really have anyone who is an expert in that
aspect of the C xenstore/tdb who we can lean on for pointers (no pun
intended) etc, so in the absence of some sort of ability to trigger on
demand I'm not sure what else to suggest.

> 1. Has someone observed a similar crash?

I think you are the only one I've seen reporting this.

> 2. We've now also enabled "xenstored -T /log --verbose" to log the
> messages in the hope to find the triggering transaction, but until then
> is there something more we can do to track down the problem?
> 
> 3. the crash happens rarely and the host run fine most of the time. The
> crash mostly happens around midnight and seem to be guest-triggered, as
> the logs on the host don't show any activity like starting new or
> destroying running VMs. So far the problem only showed on host running
> Linux VMs. Other host running Windows VMs so far never showed that crash.

If it is really mostly happening around midnight then it might be worth
digging into the host and guest configs for cronjobs and the like, e.g.
log rotation stuff like that which might be tweaking things somehow.

Does this happen on multiple hosts, or just the one?

Do you rm the xenstore db on boot? It might have a persistent
corruption, aiui most folks using C xenstored are doing so or even
placing it on a tmpfs for performance reasons.

If you are running 4.1.x then I think oxenstored isn't an option, but it
might be something to consider when you upgrade.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:15:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoqV1-00033u-6x; Thu, 13 Nov 2014 09:15:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoqUz-00033n-Bs
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 09:15:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	19/50-24532-0B674645; Thu, 13 Nov 2014 09:15:28 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415870127!12052955!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24353 invoked from network); 13 Nov 2014 09:15:28 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 09:15:28 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 301DAAC01;
	Thu, 13 Nov 2014 09:15:27 +0000 (UTC)
Message-ID: <546476AE.9080207@suse.com>
Date: Thu, 13 Nov 2014 10:15:26 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-7-git-send-email-jgross@suse.com>
	<20141112221813.GE7549@laptop.dumpdata.com>
In-Reply-To: <20141112221813.GE7549@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 6/8] xen: Hide get_phys_to_machine() to
 be able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 11:18 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 06:43:44AM +0100, Juergen Gross wrote:
>> Today get_phys_to_machine() is always called when the mfn for a pfn
>> is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
>> to be able to avoid calling get_phys_to_machine() when possible as
>
> s/when/where/

No. It's not a matter of the caller, but of the p2m list entry.

>> soon as the switch to a linear mapped p2m list has been done.
>
> But your inline function still calls get_phys_to_machine?

Sure. The switch is done in the next patch. David asked me to split
the patch doing the preparation by adding __pfn_tom_mfn() in an own
patch.

>
>
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   arch/x86/include/asm/xen/page.h | 27 +++++++++++++++++++++------
>>   arch/x86/xen/mmu.c              |  2 +-
>>   arch/x86/xen/p2m.c              |  6 +++---
>>   3 files changed, 25 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
>> index 28fa795..07d8a7b 100644
>> --- a/arch/x86/include/asm/xen/page.h
>> +++ b/arch/x86/include/asm/xen/page.h
>> @@ -59,6 +59,22 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
>>   				     struct page **pages, unsigned int count);
>>   extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
>>
>> +/*
>> + * When to use pfn_to_mfn(), __pfn_to_mfn() or get_phys_to_machine():
>> + * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. In case of an
>> + *   identity entry the identity indicator will be cleared.
>
> Why don't you say : In case of identity PFN the same PFN is returned.
>
> But you did miss that also the FOREIGN_FRAME_BIT is cleared.

I'll reword the comment.

>
>> + * - __pfn_to_mfn() returns the found entry of the p2m table. A possibly set
>
> s/of the/in the/
>> + *   identity indicator will be still set. __pfn_to_mfn() is encapsulating
> .. be still set if the PFN is an identity one.
>> + *   get_phys_to_machine() and might skip that function if possible to speed
>> + *   up the common path.
>
> How is is skipping that function? The patch below does no such thing?

The next patch in this series does.

>
>> + * - get_phys_to_machine() is basically the same as __pfn_to_mfn(), but
>> + *   without any short cuts for the common fast path.
>
> Right. Perhpas we should call it 'slow_p2m' instead of the 'get_phys_to_machine'.

That's a matter of taste, I think. I can change it if nobody else
objects.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:15:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoqV1-00033u-6x; Thu, 13 Nov 2014 09:15:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoqUz-00033n-Bs
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 09:15:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	19/50-24532-0B674645; Thu, 13 Nov 2014 09:15:28 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415870127!12052955!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24353 invoked from network); 13 Nov 2014 09:15:28 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 09:15:28 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 301DAAC01;
	Thu, 13 Nov 2014 09:15:27 +0000 (UTC)
Message-ID: <546476AE.9080207@suse.com>
Date: Thu, 13 Nov 2014 10:15:26 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-7-git-send-email-jgross@suse.com>
	<20141112221813.GE7549@laptop.dumpdata.com>
In-Reply-To: <20141112221813.GE7549@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 6/8] xen: Hide get_phys_to_machine() to
 be able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 11:18 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 06:43:44AM +0100, Juergen Gross wrote:
>> Today get_phys_to_machine() is always called when the mfn for a pfn
>> is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
>> to be able to avoid calling get_phys_to_machine() when possible as
>
> s/when/where/

No. It's not a matter of the caller, but of the p2m list entry.

>> soon as the switch to a linear mapped p2m list has been done.
>
> But your inline function still calls get_phys_to_machine?

Sure. The switch is done in the next patch. David asked me to split
the patch doing the preparation by adding __pfn_tom_mfn() in an own
patch.

>
>
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   arch/x86/include/asm/xen/page.h | 27 +++++++++++++++++++++------
>>   arch/x86/xen/mmu.c              |  2 +-
>>   arch/x86/xen/p2m.c              |  6 +++---
>>   3 files changed, 25 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
>> index 28fa795..07d8a7b 100644
>> --- a/arch/x86/include/asm/xen/page.h
>> +++ b/arch/x86/include/asm/xen/page.h
>> @@ -59,6 +59,22 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
>>   				     struct page **pages, unsigned int count);
>>   extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
>>
>> +/*
>> + * When to use pfn_to_mfn(), __pfn_to_mfn() or get_phys_to_machine():
>> + * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. In case of an
>> + *   identity entry the identity indicator will be cleared.
>
> Why don't you say : In case of identity PFN the same PFN is returned.
>
> But you did miss that also the FOREIGN_FRAME_BIT is cleared.

I'll reword the comment.

>
>> + * - __pfn_to_mfn() returns the found entry of the p2m table. A possibly set
>
> s/of the/in the/
>> + *   identity indicator will be still set. __pfn_to_mfn() is encapsulating
> .. be still set if the PFN is an identity one.
>> + *   get_phys_to_machine() and might skip that function if possible to speed
>> + *   up the common path.
>
> How is is skipping that function? The patch below does no such thing?

The next patch in this series does.

>
>> + * - get_phys_to_machine() is basically the same as __pfn_to_mfn(), but
>> + *   without any short cuts for the common fast path.
>
> Right. Perhpas we should call it 'slow_p2m' instead of the 'get_phys_to_machine'.

That's a matter of taste, I think. I can change it if nobody else
objects.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:21:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoqaP-0003Dn-Ua; Thu, 13 Nov 2014 09:21:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoqaO-0003Di-NG
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 09:21:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9D/F2-09936-FF774645; Thu, 13 Nov 2014 09:21:03 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415870462!12054650!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11723 invoked from network); 13 Nov 2014 09:21:02 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 09:21:02 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 6B990AC24;
	Thu, 13 Nov 2014 09:21:02 +0000 (UTC)
Message-ID: <546477FD.9050800@suse.com>
Date: Thu, 13 Nov 2014 10:21:01 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-8-git-send-email-jgross@suse.com>
	<54624BCB.9040300@citrix.com>
In-Reply-To: <54624BCB.9040300@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m 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

On 11/11/2014 06:47 PM, David Vrabel wrote:
> On 11/11/14 05:43, Juergen Gross wrote:
>> At start of the day the Xen hypervisor presents a contiguous mfn list
>> to a pv-domain. In order to support sparse memory this mfn list is
>> accessed via a three level p2m tree built early in the boot process.
>> Whenever the system needs the mfn associated with a pfn this tree is
>> used to find the mfn.
>>
>> Instead of using a software walked tree for accessing a specific mfn
>> list entry this patch is creating a virtual address area for the
>> entire possible mfn list including memory holes. The holes are
>> covered by mapping a pre-defined  page consisting only of "invalid
>> mfn" entries. Access to a mfn entry is possible by just using the
>> virtual base address of the mfn list and the pfn as index into that
>> list. This speeds up the (hot) path of determining the mfn of a
>> pfn.
>>
>> Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
>> showed following improvements:
>>
>> Elapsed time: 32:50 ->  32:35
>> System:       18:07 ->  17:47
>> User:        104:00 -> 103:30
>>
>> Tested on 64 bit dom0 and 32 bit domU.
>
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
>
> Can you please test this with the following guests/scenarios.
>
> * 64 bit dom0 with PCI devices with high MMIO BARs.

I'm not sure I have a machine available with this configuration.

> * 32 bit domU with PCI devices assigned.
> * 32 bit domU with 64 GiB of memory.
> * domU that starts pre-ballooned and is subsequently ballooned up.
> * 64 bit domU that is saved and restored (or local host migration)
> * 32 bit domU that is saved and restored (or local host migration)

I'll try.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:21:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoqaP-0003Dn-Ua; Thu, 13 Nov 2014 09:21:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XoqaO-0003Di-NG
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 09:21:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9D/F2-09936-FF774645; Thu, 13 Nov 2014 09:21:03 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1415870462!12054650!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11723 invoked from network); 13 Nov 2014 09:21:02 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 09:21:02 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 6B990AC24;
	Thu, 13 Nov 2014 09:21:02 +0000 (UTC)
Message-ID: <546477FD.9050800@suse.com>
Date: Thu, 13 Nov 2014 10:21:01 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-8-git-send-email-jgross@suse.com>
	<54624BCB.9040300@citrix.com>
In-Reply-To: <54624BCB.9040300@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m 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

On 11/11/2014 06:47 PM, David Vrabel wrote:
> On 11/11/14 05:43, Juergen Gross wrote:
>> At start of the day the Xen hypervisor presents a contiguous mfn list
>> to a pv-domain. In order to support sparse memory this mfn list is
>> accessed via a three level p2m tree built early in the boot process.
>> Whenever the system needs the mfn associated with a pfn this tree is
>> used to find the mfn.
>>
>> Instead of using a software walked tree for accessing a specific mfn
>> list entry this patch is creating a virtual address area for the
>> entire possible mfn list including memory holes. The holes are
>> covered by mapping a pre-defined  page consisting only of "invalid
>> mfn" entries. Access to a mfn entry is possible by just using the
>> virtual base address of the mfn list and the pfn as index into that
>> list. This speeds up the (hot) path of determining the mfn of a
>> pfn.
>>
>> Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
>> showed following improvements:
>>
>> Elapsed time: 32:50 ->  32:35
>> System:       18:07 ->  17:47
>> User:        104:00 -> 103:30
>>
>> Tested on 64 bit dom0 and 32 bit domU.
>
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
>
> Can you please test this with the following guests/scenarios.
>
> * 64 bit dom0 with PCI devices with high MMIO BARs.

I'm not sure I have a machine available with this configuration.

> * 32 bit domU with PCI devices assigned.
> * 32 bit domU with 64 GiB of memory.
> * domU that starts pre-ballooned and is subsequently ballooned up.
> * 64 bit domU that is saved and restored (or local host migration)
> * 32 bit domU that is saved and restored (or local host migration)

I'll try.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:39:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:39:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoqsB-0003g4-KH; Thu, 13 Nov 2014 09:39:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoqsA-0003fz-Eh
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 09:39:26 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	73/6D-17694-D4C74645; Thu, 13 Nov 2014 09:39:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415871563!7341645!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20902 invoked from network); 13 Nov 2014 09:39:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 09:39:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,375,1413244800"; d="scan'208";a="190868964"
Message-ID: <1415871560.21321.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Date: Thu, 13 Nov 2014 09:39:20 +0000
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A5BF5D@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<20141112110722.GC25821@zion.uk.xensource.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A5BF5D@SHSMSX103.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 01:22 +0000, Hu, Robert wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: Wednesday, November 12, 2014 7:07 PM
> > To: Hu, Robert
> > Cc: xen-devel@lists.xen.org; JBeulich@suse.com; wei.liu2@citrix.com
> > Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> > 
> > On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> > > Hi All,
> > >
> > > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> > >
> > 
> > > 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
> > >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
> > 
> > See <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
> Thanks for this info. However, what does this link refers to? It is
> read as 'mailto' link by my mail client. anything missing?

It is a message-id (a header from every email which somewhat uniquely
identifies it). Many mailing list archives will let you lookup a message
by this identifier. e.g.

http://mid.gmane.org/<1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
http://marc.info/?i=<1415790358-16787-1-git-send-email-wei.liu2@citrix.com>

Note that the <>'s are part of the message-id itself.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:39:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:39:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoqsB-0003g4-KH; Thu, 13 Nov 2014 09:39:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XoqsA-0003fz-Eh
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 09:39:26 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	73/6D-17694-D4C74645; Thu, 13 Nov 2014 09:39:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415871563!7341645!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20902 invoked from network); 13 Nov 2014 09:39:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 09:39:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,375,1413244800"; d="scan'208";a="190868964"
Message-ID: <1415871560.21321.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Date: Thu, 13 Nov 2014 09:39:20 +0000
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A5BF5D@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<20141112110722.GC25821@zion.uk.xensource.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A5BF5D@SHSMSX103.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 01:22 +0000, Hu, Robert wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: Wednesday, November 12, 2014 7:07 PM
> > To: Hu, Robert
> > Cc: xen-devel@lists.xen.org; JBeulich@suse.com; wei.liu2@citrix.com
> > Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> > 
> > On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> > > Hi All,
> > >
> > > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> > >
> > 
> > > 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
> > >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
> > 
> > See <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
> Thanks for this info. However, what does this link refers to? It is
> read as 'mailto' link by my mail client. anything missing?

It is a message-id (a header from every email which somewhat uniquely
identifies it). Many mailing list archives will let you lookup a message
by this identifier. e.g.

http://mid.gmane.org/<1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
http://marc.info/?i=<1415790358-16787-1-git-send-email-wei.liu2@citrix.com>

Note that the <>'s are part of the message-id itself.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:55:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:55:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xor74-00047x-51; Thu, 13 Nov 2014 09:54:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xor72-00047s-IF
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 09:54:48 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	07/5B-02702-7EF74645; Thu, 13 Nov 2014 09:54:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415872485!12245288!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18103 invoked from network); 13 Nov 2014 09:54:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 09:54:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190873241"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 04:54:45 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xor6y-0004Pr-FL;
	Thu, 13 Nov 2014 09:54:44 +0000
Date: Thu, 13 Nov 2014 09:54:44 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141113095444.GA9739@zion.uk.xensource.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<20141112110722.GC25821@zion.uk.xensource.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A5BF5D@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A5BF5D@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 01:22:49AM +0000, Hu, Robert wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: Wednesday, November 12, 2014 7:07 PM
> > To: Hu, Robert
> > Cc: xen-devel@lists.xen.org; JBeulich@suse.com; wei.liu2@citrix.com
> > Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> > 
> > On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> > > Hi All,
> > >
> > > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> > >
> > 
> > > 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
> > >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
> > 
> > See <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
> Thanks for this info. However, what does this link refers to? It is read as 'mailto' link by my mail client. anything missing?

This is email message id.

https://en.wikipedia.org/wiki/Message-ID

You can use it to locate a particular email.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:55:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09:55:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xor74-00047x-51; Thu, 13 Nov 2014 09:54:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xor72-00047s-IF
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 09:54:48 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	07/5B-02702-7EF74645; Thu, 13 Nov 2014 09:54:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415872485!12245288!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18103 invoked from network); 13 Nov 2014 09:54:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 09:54:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190873241"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 04:54:45 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xor6y-0004Pr-FL;
	Thu, 13 Nov 2014 09:54:44 +0000
Date: Thu, 13 Nov 2014 09:54:44 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141113095444.GA9739@zion.uk.xensource.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<20141112110722.GC25821@zion.uk.xensource.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A5BF5D@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A5BF5D@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 01:22:49AM +0000, Hu, Robert wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: Wednesday, November 12, 2014 7:07 PM
> > To: Hu, Robert
> > Cc: xen-devel@lists.xen.org; JBeulich@suse.com; wei.liu2@citrix.com
> > Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> > 
> > On Wed, Nov 12, 2014 at 06:58:49AM +0000, Hu, Robert wrote:
> > > Hi All,
> > >
> > > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> > >
> > 
> > > 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
> > >   http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
> > 
> > See <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
> Thanks for this info. However, what does this link refers to? It is read as 'mailto' link by my mail client. anything missing?

This is email message id.

https://en.wikipedia.org/wiki/Message-ID

You can use it to locate a particular email.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:57:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09: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 1Xor9q-0004Ev-N4; Thu, 13 Nov 2014 09:57:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xor9o-0004Em-Jv
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 09:57:40 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	82/E1-24859-39084645; Thu, 13 Nov 2014 09:57:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415872659!11073185!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11310 invoked from network); 13 Nov 2014 09:57:39 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 09:57:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 09:57:38 +0000
Message-Id: <54648EA202000078000471CF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 09:57:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
	<546390FC0200007800046E50@mail.emea.novell.com>
In-Reply-To: <546390FC0200007800046E50@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 16:55, <JBeulich@suse.com> wrote:
>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +	u64 max_mfn;
>> +
>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
>> +}
> 
> The value the hypercall returns is exclusive and an unsigned long.

The latter has further relevance: For one, HYPERVISOR_memory_op()
returns "int" currently - this needs to become "long" for the purpose
here (also for eventual future uses of XENMEM_maximum_gpfn and
XENMEM_{current,maximum}_reservation).

And then, using u64 rather than unsigned long for max_mfn would
still cause problems for 32-bit kernels on systems with memory
extending beyond the 8Tb boundary (since the long -> u64
conversion really goes long -> s64 -> u64).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 09:57:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 09: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 1Xor9q-0004Ev-N4; Thu, 13 Nov 2014 09:57:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xor9o-0004Em-Jv
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 09:57:40 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	82/E1-24859-39084645; Thu, 13 Nov 2014 09:57:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415872659!11073185!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11310 invoked from network); 13 Nov 2014 09:57:39 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 09:57:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 09:57:38 +0000
Message-Id: <54648EA202000078000471CF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 09:57:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
	<546390FC0200007800046E50@mail.emea.novell.com>
In-Reply-To: <546390FC0200007800046E50@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 16:55, <JBeulich@suse.com> wrote:
>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +	u64 max_mfn;
>> +
>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
>> +}
> 
> The value the hypercall returns is exclusive and an unsigned long.

The latter has further relevance: For one, HYPERVISOR_memory_op()
returns "int" currently - this needs to become "long" for the purpose
here (also for eventual future uses of XENMEM_maximum_gpfn and
XENMEM_{current,maximum}_reservation).

And then, using u64 rather than unsigned long for max_mfn would
still cause problems for 32-bit kernels on systems with memory
extending beyond the 8Tb boundary (since the long -> u64
conversion really goes long -> s64 -> u64).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:14:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:14:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XorPt-0004ma-95; Thu, 13 Nov 2014 10:14:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XorPq-0004mV-QF
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 10:14:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3B/F4-24532-67484645; Thu, 13 Nov 2014 10:14:14 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415873651!12444133!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32494 invoked from network); 13 Nov 2014 10:14:11 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 10:14:11 -0000
Received: by mail-wi0-f171.google.com with SMTP id r20so7720594wiv.16
	for <xen-devel@lists.xensource.com>;
	Thu, 13 Nov 2014 02:14:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=6BGVkmzzyTh/S4bS+82ikzATkZnS9s3Y56i2SwDAXw8=;
	b=lwC5vRilM7cKWNggXornmxY8x1Vb/MXrRN8WL7fyg4Ichz/lOalXyA8eVzvkvmjGuW
	7MAlvVVDaMPgyV5hwpW3sMPO76lKpb7+uGHw6OckeuKk/ATI58C7jpGsfJsYMS6QpDfR
	64KBrcnUszN7T38xQ1rOaa/vC8GHQ5bC+gKEsXXPMqdHQlmPkUtHEWI6kQEmJdv6XFy1
	hbqINaqA5Mf/zpOc4YVMP6BaGWZM5WnsjSQxGgFcMkmTr5bD06xvi0GihpCRfGGWoiOf
	64IfGaVZZ24pkB6U+MqMldAODMG69tkePxodQFPooY3sInAxevdB4+H1EMpF8A900Urb
	rnIA==
X-Gm-Message-State: ALoCoQlNzUVUp8gw23GjLuJV25VpLKQ0gcJsz/dKmG5oZNIdSfEy4iDh7UeSQYPY5r8pQrqOOFpW
X-Received: by 10.194.52.68 with SMTP id r4mr2475521wjo.82.1415873650757;
	Thu, 13 Nov 2014 02:14:10 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	dm10sm17393645wib.18.2014.11.13.02.14.07 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 13 Nov 2014 02:14:10 -0800 (PST)
Message-ID: <54648477.5040505@m2r.biz>
Date: Thu, 13 Nov 2014 11:14:15 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <53BBA83C.3010307@m2r.biz>
	<1404809604.30343.5.camel@cihla.spice.brq.redhat.com>
	<53BBC2AA.4030503@m2r.biz> <53BBC952.1040902@m2r.biz>
	<54130761.6080501@m2r.biz> <541C2D39.1060607@m2r.biz>
In-Reply-To: <541C2D39.1060607@m2r.biz>
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [Spice-devel] screen freezed for 2-3 minutes on
 spice connect on xen windows 7 domU's with qxl after save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7257911430843709156=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============7257911430843709156==
Content-Type: multipart/alternative;
 boundary="------------040907080300070404050807"

This is a multi-part message in MIME format.
--------------040907080300070404050807
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Length: 14601
Content-Transfer-Encoding: quoted-printable

Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
> Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
>> Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
>>> Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
>>>> Il 08/07/2014 10:53, David Ja=9Aa ha scritto:
>>>>> Hi,
>>>>>
>>>>> On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
>>>>>> On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
>>>>>> client with
>>>>>> spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as kvm
>>>>>> except for one problem after xl save/restore, when after restore on
>>>>>> spice client connect  the domU's screen freezed for 2-3 minutes (and
>>>>>> seems also windows), after this time seems that all return to works
>>>>>> correctly.
>>>>>> This problem happen also if spice client connect long time after 
>>>>>> restore.
>>>>>> With stdvga not have this problem but stdvga has many missed 
>>>>>> resolutions
>>>>>> and bad refresh performance.
>>>>>>
>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>> Client and server logs would certainly help. Please run:
>>>>>    * virt-viewer with --spice-debug option
>>>>>    * spice-server with SPICE_DEBUG_LEVEL environment variable set
>>>>>      to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
>>>>>      http://libvirt.org/drvqemu.html#qemucommand )
>>>>> and note the location in the logs where the freeze takes place.
>>>>>
>>>>> Regards,
>>>>>
>>>>> David
>>>>
>>>> Thanks for your reply, in attachments:
>>>> - domU's xl cfg: W7.cfg
>>>> - xl -vvv create/save/restore: xen logs.txt
>>>> - remote-viewer with --spice-debug after domU's start until xl 
>>>> save: spicelog-1.txt (zipped)
>>>> - remote-viewer with --spice-debug after domU's xl restore: 
>>>> spicelog-2.txt
>>>
>>> Sorry for my forgetfulness, here also qemu's log:
>>> - after domU's start until xl save: qemu-dm-W7.log.1
>>> - after domU's xl restore: qemu-dm-W7.log
>>>
>>>>
>>>> If you need more tests/informations tell me and I'll post them.
>>>>
>>>>
>>>>> Thanks for any reply and sorry for my bad english.
>>>>>
>>>>> _______________________________________________
>>>>> Spice-devel mailing list
>>>>> Spice-devel@lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>
>>
>> The problem persist, this time I saw these in xl dmesg after restore:
>>
>> (XEN) HVM2 restore: CPU 0
>> (XEN) HVM2 restore: CPU 1
>> (XEN) HVM2 restore: PIC 0
>> (XEN) HVM2 restore: PIC 1
>> (XEN) HVM2 restore: IOAPIC 0
>> (XEN) HVM2 restore: LAPIC 0
>> (XEN) HVM2 restore: LAPIC 1
>> (XEN) HVM2 restore: LAPIC_REGS 0
>> (XEN) HVM2 restore: LAPIC_REGS 1
>> (XEN) HVM2 restore: PCI_IRQ 0
>> (XEN) HVM2 restore: ISA_IRQ 0
>> (XEN) HVM2 restore: PCI_LINK 0
>> (XEN) HVM2 restore: PIT 0
>> (XEN) HVM2 restore: RTC 0
>> (XEN) HVM2 restore: HPET 0
>> (XEN) HVM2 restore: PMTIMER 0
>> (XEN) HVM2 restore: MTRR 0
>> (XEN) HVM2 restore: MTRR 1
>> (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
>> (XEN) HVM2 restore: VIRIDIAN_VCPU 0
>> (XEN) HVM2 restore: VIRIDIAN_VCPU 1
>> (XEN) HVM2 restore: VMCE_VCPU 0
>> (XEN) HVM2 restore: VMCE_VCPU 1
>> (XEN) HVM2 restore: TSC_ADJUST 0
>> (XEN) HVM2 restore: TSC_ADJUST 1
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
>> (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from (4) 
>> to (32) frames.
>> (XEN) irq.c:380: Dom2 callback via changed to GSI 24
>>
>> Tested on latest staging (commit 
>> 7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:
>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>
>> If you need more informations or tests tell me and I'll post them.
>> Thanks for any reply and sorry for my bad english.
>
> I did another tests updating to latest git staging (commit 
> 3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of 
> "only" 2-3 minutes but now when it appears to restart (after 2-3 
> minutes) windows domUs undefinitely hangs instead.
> No further details in xen and domU's logs.
>
> If you need more tests/details tell me and I'll do them.
>
> Thanks for any reply.

I did a new test with xen build based on tag 4.5.0-rc2 and on xl dmesg 
show these errors:
> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
Before and after save/restore, with stdvga instead not show them.

Below I posted full xl dmesg of domU, if you need more 
informations/tests tell me and I'll post them.


> (d4) HVM Loader
> (d4) Detected Xen v4.5.0-rc
> (d4) Xenbus rings @0xfeffc000, event channel 1
> (d4) System requested SeaBIOS
> (d4) CPU speed is 2660 MHz
> (d4) Relocating guest memory for lowmem MMIO space disabled
> (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -> 5
> (d4) PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -> 10
> (d4) PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -> 11
> (d4) PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -> 5
> (d4) PCI-ISA link 3 routed to IRQ5
> (d4) pci dev 01:3 INTA->IRQ10
> (d4) pci dev 02:0 INTA->IRQ11
> (d4) pci dev 03:0 INTA->IRQ5
> (d4) pci dev 04:0 INTA->IRQ5
> (d4) pci dev 05:0 INTA->IRQ10
> (d4) pci dev 06:0 INTA->IRQ11
> (d4) pci dev 1d:0 INTA->IRQ10
> (d4) pci dev 1d:1 INTB->IRQ11
> (d4) pci dev 1d:2 INTC->IRQ5
> (d4) pci dev 1d:7 INTD->IRQ5
> (d4) No RAM in high memory; setting high_mem resource base to 100000000
> (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000
> (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000
> (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008
> (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000
> (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000
> (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000
> (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000
> (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000
> (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000
> (d4) pci dev 02:0 bar 10 size 000000100: 00000c001
> (d4) pci dev 06:0 bar 10 size 000000100: 00000c101
> (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000
> (d4) pci dev 04:0 bar 10 size 000000020: 00000c201
> (d4) pci dev 05:0 bar 1c size 000000020: 00000c221
> (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241
> (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261
> (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281
> (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1
> (d4) Multiprocessor initialisation:
> (d4)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
> (d4)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
> (d4) Testing HVM environment:
> (d4)  - REP INSB across page boundaries ... passed
> (d4)  - GS base MSRs and SWAPGS ... passed
> (d4) Passed 2 of 2 tests
> (d4) Writing SMBIOS tables ...
> (d4) Loading SeaBIOS ...
> (d4) Creating MP tables ...
> (d4) Loading ACPI ...
> (d4) S3 disabled
> (d4) S4 disabled
> (d4) vm86 TSS at fc00a100
> (d4) BIOS map:
> (d4)  10000-100d3: Scratch space
> (d4)  c0000-fffff: Main BIOS
> (d4) E820 table:
> (d4)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> (d4)  HOLE: 00000000:000a0000 - 00000000:000c0000
> (d4)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
> (d4)  [02]: 00000000:00100000 - 00000000:78000000: RAM
> (d4)  HOLE: 00000000:78000000 - 00000000:fc000000
> (d4)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> (d4) Invoking SeaBIOS ...
> (d4) SeaBIOS (version 
> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> (d4)
> (d4) Found Xen hypervisor signature at 40000100
> (d4) Running on QEMU (i440fx)
> (d4) xen: copy e820...
> (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
> (d4) CPU Mhz=3D2661
> (d4) Found 13 PCI devices (max PCI bus is 00)
> (d4) Allocated Xen hypercall page at 77fff000
> (d4) Detected Xen v4.5.0-rc
> (d4) xen: copy BIOS tables...
> (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
> (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
> (d4) Copying PIR from 0x00010030 to 0x000f0dc0
> (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
> (d4) Using pmtimer, ioport 0xb008
> (d4) Scan for VGA option rom
> (d4) Running option rom at c000:0003
> (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes
> (d4) pmm call arg1=3D0
> (d4) Turning on vga text mode console
> (d4) SeaBIOS (version 
> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838
> (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)
> (d4) Found 0 lpt ports
> (d4) Found 0 serial ports
> (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)
> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
> (d4) UHCI init on dev 00:1d.0 (io=3Dc240)
> (d4) UHCI init on dev 00:1d.1 (io=3Dc260)
> (d4) UHCI init on dev 00:1d.2 (io=3Dc280)
> (d4) PS2 keyboard initialized
> (d4) All threads complete.
> (d4) Scan for option roms
> (d4) Running option rom at c980:0003
> (d4) pmm call arg1=3D1
> (d4) pmm call arg1=3D0
> (d4) pmm call arg1=3D1
> (d4) pmm call arg1=3D0
> (d4) Searching bootorder for: /pci@i0cf8/*@6
> (d4)
> (d4) Press F12 for boot menu.
> (d4)
> (d4) Searching bootorder for: HALT
> (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba 
> LCHS=3D1024/255/63 s=3D102400000
> (d4)
> (d4) Space available for UMB: ca800-ee800, f0000-f0ce0
> (d4) Returned 258048 bytes of ZoneHigh
> (d4) e820 map has 6 items:
> (d4)   0: 0000000000000000 - 000000000009fc00 =3D 1 RAM
> (d4)   1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED
> (d4)   2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED
> (d4)   3: 0000000000100000 - 0000000077fff000 =3D 1 RAM
> (d4)   4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED
> (d4)   5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED
> (d4) enter handle_19:
> (d4)   NULL
> (d4) Booting from DVD/CD...
> (d4) Device reports MEDIUM NOT PRESENT
> (d4) scsi_is_ready returned -1
> (d4) Boot failed: Could not read from CDROM (code 0003)
> (d4) enter handle_18:
> (d4)   NULL
> (d4) Booting from Hard Disk...
> (d4) Booting from 0000:7c00
> (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 
> 1 build: 1db1
> (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
> (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
> (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
> (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -> 0
> (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -> 0
> (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -> 0
> (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -> 0
> *(XEN) hvm.c:6119:d4v1 Bad HVM op 23.**
> **(XEN) hvm.c:6119:d4v1 Bad HVM op 23.*
> (XEN) irq.c:380: Dom4 callback via changed to GSI 24
> (XEN) HVM4 save: CPU
> (XEN) HVM4 save: PIC
> (XEN) HVM4 save: IOAPIC
> (XEN) HVM4 save: LAPIC
> (XEN) HVM4 save: LAPIC_REGS
> (XEN) HVM4 save: PCI_IRQ
> (XEN) HVM4 save: ISA_IRQ
> (XEN) HVM4 save: PCI_LINK
> (XEN) HVM4 save: PIT
> (XEN) HVM4 save: RTC
> (XEN) HVM4 save: HPET
> (XEN) HVM4 save: PMTIMER
> (XEN) HVM4 save: MTRR
> (XEN) HVM4 save: VIRIDIAN_DOMAIN
> (XEN) HVM4 save: CPU_XSAVE
> (XEN) HVM4 save: VIRIDIAN_VCPU
> (XEN) HVM4 save: VMCE_VCPU
> (XEN) HVM4 save: TSC_ADJUST
> (XEN) HVM5 restore: CPU 0
> (XEN) HVM5 restore: CPU 1
> (XEN) HVM5 restore: PIC 0
> (XEN) HVM5 restore: PIC 1
> (XEN) HVM5 restore: IOAPIC 0
> (XEN) HVM5 restore: LAPIC 0
> (XEN) HVM5 restore: LAPIC 1
> (XEN) HVM5 restore: LAPIC_REGS 0
> (XEN) HVM5 restore: LAPIC_REGS 1
> (XEN) HVM5 restore: PCI_IRQ 0
> (XEN) HVM5 restore: ISA_IRQ 0
> (XEN) HVM5 restore: PCI_LINK 0
> (XEN) HVM5 restore: PIT 0
> (XEN) HVM5 restore: RTC 0
> (XEN) HVM5 restore: HPET 0
> (XEN) HVM5 restore: PMTIMER 0
> (XEN) HVM5 restore: MTRR 0
> (XEN) HVM5 restore: MTRR 1
> (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0
> (XEN) HVM5 restore: VIRIDIAN_VCPU 0
> (XEN) HVM5 restore: VIRIDIAN_VCPU 1
> (XEN) HVM5 restore: VMCE_VCPU 0
> (XEN) HVM5 restore: VMCE_VCPU 1
> (XEN) HVM5 restore: TSC_ADJUST 0
> (XEN) HVM5 restore: TSC_ADJUST 1
> (XEN) irq.c:380: Dom5 callback via changed to None
> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
> (XEN) irq.c:380: Dom5 callback via changed to GSI 24



--------------040907080300070404050807
Content-Type: text/html; charset=windows-1252
Content-Length: 20438
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Il 19/09/2014 15:18, Fabio Fantoni ha
      scritto:<br>
    </div>
    <blockquote cite=3D"mid:541C2D39.1060607@m2r.biz" type=3D"cite">Il
      12/09/2014 16:46, Fabio Fantoni ha scritto:
      <br>
      <blockquote type=3D"cite">Il 08/07/2014 12:34, Fabio Fantoni ha
        scritto:
        <br>
        <blockquote type=3D"cite">Il 08/07/2014 12:06, Fabio Fantoni ha
          scritto:
          <br>
          <blockquote type=3D"cite">Il 08/07/2014 10:53, David Ja=9Aa ha
            scritto:
            <br>
            <blockquote type=3D"cite">Hi,
              <br>
              <br>
              On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
              <br>
              <blockquote type=3D"cite">On xen 4.5 (tried with qemu
                2.0.0/2.1-rc0, spice 0.12.5 and client with
                <br>
                spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works
                good as kvm
                <br>
                except for one problem after xl save/restore, when after
                restore on
                <br>
                spice client connect=A0 the domU's screen freezed for 2-3
                minutes (and
                <br>
                seems also windows), after this time seems that all
                return to works
                <br>
                correctly.
                <br>
                This problem happen also if spice client connect long
                time after restore.
                <br>
                With stdvga not have this problem but stdvga has many
                missed resolutions
                <br>
                and bad refresh performance.
                <br>
                <br>
                If you need more tests/informations tell me and I'll
                post them.
                <br>
              </blockquote>
              Client and server logs would certainly help. Please run:
              <br>
              =A0=A0 * virt-viewer with --spice-debug option
              <br>
              =A0=A0 * spice-server with SPICE_DEBUG_LEVEL environment
              variable set
              <br>
              =A0=A0=A0=A0 to 4 or 5 (if you use qemu+libvirt, use qemu:env
              element:
              <br>
              =A0=A0=A0=A0 <a class=3D"moz-txt-link-freetext" href=3D"http://libvirt.org/drvqemu.html#qemucommand">http://libvirt.org/drvqemu.html#qemucommand</a> )
              <br>
              and note the location in the logs where the freeze takes
              place.
              <br>
              <br>
              Regards,
              <br>
              <br>
              David
              <br>
            </blockquote>
            <br>
            Thanks for your reply, in attachments:
            <br>
            - domU's xl cfg: W7.cfg
            <br>
            - xl -vvv create/save/restore: xen logs.txt
            <br>
            - remote-viewer with --spice-debug after domU's start until
            xl save: spicelog-1.txt (zipped)
            <br>
            - remote-viewer with --spice-debug after domU's xl restore:
            spicelog-2.txt
            <br>
          </blockquote>
          <br>
          Sorry for my forgetfulness, here also qemu's log:
          <br>
          - after domU's start until xl save: qemu-dm-W7.log.1
          <br>
          - after domU's xl restore: qemu-dm-W7.log
          <br>
          <br>
          <blockquote type=3D"cite">
            <br>
            If you need more tests/informations tell me and I'll post
            them.
            <br>
            <br>
            <br>
            <blockquote type=3D"cite">Thanks for any reply and sorry for
              my bad english.
              <br>
              <br>
              _______________________________________________
              <br>
              Spice-devel mailing list
              <br>
              <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a>
              <br>
              <a class=3D"moz-txt-link-freetext" href=3D"http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a>
              <br>
            </blockquote>
          </blockquote>
          <br>
        </blockquote>
        <br>
        The problem persist, this time I saw these in xl dmesg after
        restore:
        <br>
        <br>
        (XEN) HVM2 restore: CPU 0
        <br>
        (XEN) HVM2 restore: CPU 1
        <br>
        (XEN) HVM2 restore: PIC 0
        <br>
        (XEN) HVM2 restore: PIC 1
        <br>
        (XEN) HVM2 restore: IOAPIC 0
        <br>
        (XEN) HVM2 restore: LAPIC 0
        <br>
        (XEN) HVM2 restore: LAPIC 1
        <br>
        (XEN) HVM2 restore: LAPIC_REGS 0
        <br>
        (XEN) HVM2 restore: LAPIC_REGS 1
        <br>
        (XEN) HVM2 restore: PCI_IRQ 0
        <br>
        (XEN) HVM2 restore: ISA_IRQ 0
        <br>
        (XEN) HVM2 restore: PCI_LINK 0
        <br>
        (XEN) HVM2 restore: PIT 0
        <br>
        (XEN) HVM2 restore: RTC 0
        <br>
        (XEN) HVM2 restore: HPET 0
        <br>
        (XEN) HVM2 restore: PMTIMER 0
        <br>
        (XEN) HVM2 restore: MTRR 0
        <br>
        (XEN) HVM2 restore: MTRR 1
        <br>
        (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
        <br>
        (XEN) HVM2 restore: VIRIDIAN_VCPU 0
        <br>
        (XEN) HVM2 restore: VIRIDIAN_VCPU 1
        <br>
        (XEN) HVM2 restore: VMCE_VCPU 0
        <br>
        (XEN) HVM2 restore: VMCE_VCPU 1
        <br>
        (XEN) HVM2 restore: TSC_ADJUST 0
        <br>
        (XEN) HVM2 restore: TSC_ADJUST 1
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
        <br>
        (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from
        (4) to (32) frames.
        <br>
        (XEN) irq.c:380: Dom2 callback via changed to GSI 24
        <br>
        <br>
        Tested on latest staging (commit
        7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice
        patches:
        <br>
        <a class=3D"moz-txt-link-freetext" href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a>
        <br>
        <br>
        If you need more informations or tests tell me and I'll post
        them.
        <br>
        Thanks for any reply and sorry for my bad english.
        <br>
      </blockquote>
      <br>
      I did another tests updating to latest git staging (commit
      3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of
      "only" 2-3 minutes but now when it appears to restart (after 2-3
      minutes) windows domUs undefinitely hangs instead.
      <br>
      No further details in xen and domU's logs.
      <br>
      <br>
      If you need more tests/details tell me and I'll do them.
      <br>
      <br>
      Thanks for any reply.
      <br>
    </blockquote>
    <br>
    I did a new test with xen build based on tag 4.5.0-rc2 and on xl
    dmesg show these errors:<br>
    <blockquote type=3D"cite"><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b></blockquote>
    Before and after save/restore, with stdvga instead not show them.<br>
    <br>
    Below I posted full xl dmesg of domU, if you need more
    informations/tests tell me and I'll post them.<br>
    <br>
    <br>
    <blockquote type=3D"cite">(d4) HVM Loader<br>
      (d4) Detected Xen v4.5.0-rc<br>
      (d4) Xenbus rings @0xfeffc000, event channel 1<br>
      (d4) System requested SeaBIOS<br>
      (d4) CPU speed is 2660 MHz<br>
      (d4) Relocating guest memory for lowmem MMIO space disabled<br>
      (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -&gt; 5<br>
      (d4) PCI-ISA link 0 routed to IRQ5<br>
      (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -&gt; 10<br>
      (d4) PCI-ISA link 1 routed to IRQ10<br>
      (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -&gt; 11<br>
      (d4) PCI-ISA link 2 routed to IRQ11<br>
      (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -&gt; 5<br>
      (d4) PCI-ISA link 3 routed to IRQ5<br>
      (d4) pci dev 01:3 INTA-&gt;IRQ10<br>
      (d4) pci dev 02:0 INTA-&gt;IRQ11<br>
      (d4) pci dev 03:0 INTA-&gt;IRQ5<br>
      (d4) pci dev 04:0 INTA-&gt;IRQ5<br>
      (d4) pci dev 05:0 INTA-&gt;IRQ10<br>
      (d4) pci dev 06:0 INTA-&gt;IRQ11<br>
      (d4) pci dev 1d:0 INTA-&gt;IRQ10<br>
      (d4) pci dev 1d:1 INTB-&gt;IRQ11<br>
      (d4) pci dev 1d:2 INTC-&gt;IRQ5<br>
      (d4) pci dev 1d:7 INTD-&gt;IRQ5<br>
      (d4) No RAM in high memory; setting high_mem resource base to
      100000000<br>
      (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000<br>
      (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000<br>
      (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008<br>
      (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000<br>
      (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000<br>
      (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000<br>
      (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000<br>
      (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000<br>
      (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000<br>
      (d4) pci dev 02:0 bar 10 size 000000100: 00000c001<br>
      (d4) pci dev 06:0 bar 10 size 000000100: 00000c101<br>
      (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000<br>
      (d4) pci dev 04:0 bar 10 size 000000020: 00000c201<br>
      (d4) pci dev 05:0 bar 1c size 000000020: 00000c221<br>
      (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241<br>
      (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261<br>
      (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281<br>
      (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1<br>
      (d4) Multiprocessor initialisation:<br>
      (d4)=A0 - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
      ... done.<br>
      (d4)=A0 - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
      ... done.<br>
      (d4) Testing HVM environment:<br>
      (d4)=A0 - REP INSB across page boundaries ... passed<br>
      (d4)=A0 - GS base MSRs and SWAPGS ... passed<br>
      (d4) Passed 2 of 2 tests<br>
      (d4) Writing SMBIOS tables ...<br>
      (d4) Loading SeaBIOS ...<br>
      (d4) Creating MP tables ...<br>
      (d4) Loading ACPI ...<br>
      (d4) S3 disabled<br>
      (d4) S4 disabled<br>
      (d4) vm86 TSS at fc00a100<br>
      (d4) BIOS map:<br>
      (d4)=A0 10000-100d3: Scratch space<br>
      (d4)=A0 c0000-fffff: Main BIOS<br>
      (d4) E820 table:<br>
      (d4)=A0 [00]: 00000000:00000000 - 00000000:000a0000: RAM<br>
      (d4)=A0 HOLE: 00000000:000a0000 - 00000000:000c0000<br>
      (d4)=A0 [01]: 00000000:000c0000 - 00000000:00100000: RESERVED<br>
      (d4)=A0 [02]: 00000000:00100000 - 00000000:78000000: RAM<br>
      (d4)=A0 HOLE: 00000000:78000000 - 00000000:fc000000<br>
      (d4)=A0 [03]: 00000000:fc000000 - 00000001:00000000: RESERVED<br>
      (d4) Invoking SeaBIOS ...<br>
      (d4) SeaBIOS (version
      debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
      (d4) <br>
      (d4) Found Xen hypervisor signature at 40000100<br>
      (d4) Running on QEMU (i440fx)<br>
      (d4) xen: copy e820...<br>
      (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)<br>
      (d4) CPU Mhz=3D2661<br>
      (d4) Found 13 PCI devices (max PCI bus is 00)<br>
      (d4) Allocated Xen hypercall page at 77fff000<br>
      (d4) Detected Xen v4.5.0-rc<br>
      (d4) xen: copy BIOS tables...<br>
      (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40<br>
      (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40<br>
      (d4) Copying PIR from 0x00010030 to 0x000f0dc0<br>
      (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90<br>
      (d4) Using pmtimer, ioport 0xb008<br>
      (d4) Scan for VGA option rom<br>
      (d4) Running option rom at c000:0003<br>
      (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes<br>
      (d4) pmm call arg1=3D0<br>
      (d4) Turning on vga text mode console<br>
      (d4) SeaBIOS (version
      debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
      (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838<br>
      (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)<br>
      (d4) Found 0 lpt ports<br>
      (d4) Found 0 serial ports<br>
      (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)<br>
      (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)<br>
      (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)<br>
      (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0<br>
      (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]<br>
      (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1<br>
      (d4) UHCI init on dev 00:1d.0 (io=3Dc240)<br>
      (d4) UHCI init on dev 00:1d.1 (io=3Dc260)<br>
      (d4) UHCI init on dev 00:1d.2 (io=3Dc280)<br>
      (d4) PS2 keyboard initialized<br>
      (d4) All threads complete.<br>
      (d4) Scan for option roms<br>
      (d4) Running option rom at c980:0003<br>
      (d4) pmm call arg1=3D1<br>
      (d4) pmm call arg1=3D0<br>
      (d4) pmm call arg1=3D1<br>
      (d4) pmm call arg1=3D0<br>
      (d4) Searching bootorder for: /pci@i0cf8/*@6<br>
      (d4) <br>
      (d4) Press F12 for boot menu.<br>
      (d4) <br>
      (d4) Searching bootorder for: HALT<br>
      (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba
      LCHS=3D1024/255/63 s=3D102400000<br>
      (d4) <br>
      (d4) Space available for UMB: ca800-ee800, f0000-f0ce0<br>
      (d4) Returned 258048 bytes of ZoneHigh<br>
      (d4) e820 map has 6 items:<br>
      (d4)=A0=A0 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM<br>
      (d4)=A0=A0 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED<br>
      (d4)=A0=A0 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED<br>
      (d4)=A0=A0 3: 0000000000100000 - 0000000077fff000 =3D 1 RAM<br>
      (d4)=A0=A0 4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED<br>
      (d4)=A0=A0 5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED<br>
      (d4) enter handle_19:<br>
      (d4)=A0=A0 NULL<br>
      (d4) Booting from DVD/CD...<br>
      (d4) Device reports MEDIUM NOT PRESENT<br>
      (d4) scsi_is_ready returned -1<br>
      (d4) Boot failed: Could not read from CDROM (code 0003)<br>
      (d4) enter handle_18:<br>
      (d4)=A0=A0 NULL<br>
      (d4) Booting from Hard Disk...<br>
      (d4) Booting from 0000:7c00<br>
      (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1
      sp: 1 build: 1db1<br>
      (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff<br>
      (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe<br>
      (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd<br>
      (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -&gt; 0<br>
      (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -&gt; 0<br>
      (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -&gt; 0<br>
      (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -&gt; 0<br>
      <b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><b><br>
      </b><b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><br>
      (XEN) irq.c:380: Dom4 callback via changed to GSI 24<br>
      (XEN) HVM4 save: CPU<br>
      (XEN) HVM4 save: PIC<br>
      (XEN) HVM4 save: IOAPIC<br>
      (XEN) HVM4 save: LAPIC<br>
      (XEN) HVM4 save: LAPIC_REGS<br>
      (XEN) HVM4 save: PCI_IRQ<br>
      (XEN) HVM4 save: ISA_IRQ<br>
      (XEN) HVM4 save: PCI_LINK<br>
      (XEN) HVM4 save: PIT<br>
      (XEN) HVM4 save: RTC<br>
      (XEN) HVM4 save: HPET<br>
      (XEN) HVM4 save: PMTIMER<br>
      (XEN) HVM4 save: MTRR<br>
      (XEN) HVM4 save: VIRIDIAN_DOMAIN<br>
      (XEN) HVM4 save: CPU_XSAVE<br>
      (XEN) HVM4 save: VIRIDIAN_VCPU<br>
      (XEN) HVM4 save: VMCE_VCPU<br>
      (XEN) HVM4 save: TSC_ADJUST<br>
      (XEN) HVM5 restore: CPU 0<br>
      (XEN) HVM5 restore: CPU 1<br>
      (XEN) HVM5 restore: PIC 0<br>
      (XEN) HVM5 restore: PIC 1<br>
      (XEN) HVM5 restore: IOAPIC 0<br>
      (XEN) HVM5 restore: LAPIC 0<br>
      (XEN) HVM5 restore: LAPIC 1<br>
      (XEN) HVM5 restore: LAPIC_REGS 0<br>
      (XEN) HVM5 restore: LAPIC_REGS 1<br>
      (XEN) HVM5 restore: PCI_IRQ 0<br>
      (XEN) HVM5 restore: ISA_IRQ 0<br>
      (XEN) HVM5 restore: PCI_LINK 0<br>
      (XEN) HVM5 restore: PIT 0<br>
      (XEN) HVM5 restore: RTC 0<br>
      (XEN) HVM5 restore: HPET 0<br>
      (XEN) HVM5 restore: PMTIMER 0<br>
      (XEN) HVM5 restore: MTRR 0<br>
      (XEN) HVM5 restore: MTRR 1<br>
      (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0<br>
      (XEN) HVM5 restore: VIRIDIAN_VCPU 0<br>
      (XEN) HVM5 restore: VIRIDIAN_VCPU 1<br>
      (XEN) HVM5 restore: VMCE_VCPU 0<br>
      (XEN) HVM5 restore: VMCE_VCPU 1<br>
      (XEN) HVM5 restore: TSC_ADJUST 0<br>
      (XEN) HVM5 restore: TSC_ADJUST 1<br>
      (XEN) irq.c:380: Dom5 callback via changed to None<br>
      <b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
      </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
      </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
      </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><br>
      (XEN) irq.c:380: Dom5 callback via changed to GSI 24</blockquote>
    <br>
    <br>
  </body>
</html>

--------------040907080300070404050807--


--===============7257911430843709156==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7257911430843709156==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 10:14:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:14:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XorPt-0004ma-95; Thu, 13 Nov 2014 10:14:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XorPq-0004mV-QF
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 10:14:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3B/F4-24532-67484645; Thu, 13 Nov 2014 10:14:14 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415873651!12444133!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32494 invoked from network); 13 Nov 2014 10:14:11 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 10:14:11 -0000
Received: by mail-wi0-f171.google.com with SMTP id r20so7720594wiv.16
	for <xen-devel@lists.xensource.com>;
	Thu, 13 Nov 2014 02:14:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=6BGVkmzzyTh/S4bS+82ikzATkZnS9s3Y56i2SwDAXw8=;
	b=lwC5vRilM7cKWNggXornmxY8x1Vb/MXrRN8WL7fyg4Ichz/lOalXyA8eVzvkvmjGuW
	7MAlvVVDaMPgyV5hwpW3sMPO76lKpb7+uGHw6OckeuKk/ATI58C7jpGsfJsYMS6QpDfR
	64KBrcnUszN7T38xQ1rOaa/vC8GHQ5bC+gKEsXXPMqdHQlmPkUtHEWI6kQEmJdv6XFy1
	hbqINaqA5Mf/zpOc4YVMP6BaGWZM5WnsjSQxGgFcMkmTr5bD06xvi0GihpCRfGGWoiOf
	64IfGaVZZ24pkB6U+MqMldAODMG69tkePxodQFPooY3sInAxevdB4+H1EMpF8A900Urb
	rnIA==
X-Gm-Message-State: ALoCoQlNzUVUp8gw23GjLuJV25VpLKQ0gcJsz/dKmG5oZNIdSfEy4iDh7UeSQYPY5r8pQrqOOFpW
X-Received: by 10.194.52.68 with SMTP id r4mr2475521wjo.82.1415873650757;
	Thu, 13 Nov 2014 02:14:10 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	dm10sm17393645wib.18.2014.11.13.02.14.07 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 13 Nov 2014 02:14:10 -0800 (PST)
Message-ID: <54648477.5040505@m2r.biz>
Date: Thu, 13 Nov 2014 11:14:15 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <53BBA83C.3010307@m2r.biz>
	<1404809604.30343.5.camel@cihla.spice.brq.redhat.com>
	<53BBC2AA.4030503@m2r.biz> <53BBC952.1040902@m2r.biz>
	<54130761.6080501@m2r.biz> <541C2D39.1060607@m2r.biz>
In-Reply-To: <541C2D39.1060607@m2r.biz>
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [Spice-devel] screen freezed for 2-3 minutes on
 spice connect on xen windows 7 domU's with qxl after save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7257911430843709156=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============7257911430843709156==
Content-Type: multipart/alternative;
 boundary="------------040907080300070404050807"

This is a multi-part message in MIME format.
--------------040907080300070404050807
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Length: 14601
Content-Transfer-Encoding: quoted-printable

Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
> Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
>> Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
>>> Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
>>>> Il 08/07/2014 10:53, David Ja=9Aa ha scritto:
>>>>> Hi,
>>>>>
>>>>> On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
>>>>>> On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
>>>>>> client with
>>>>>> spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as kvm
>>>>>> except for one problem after xl save/restore, when after restore on
>>>>>> spice client connect  the domU's screen freezed for 2-3 minutes (and
>>>>>> seems also windows), after this time seems that all return to works
>>>>>> correctly.
>>>>>> This problem happen also if spice client connect long time after 
>>>>>> restore.
>>>>>> With stdvga not have this problem but stdvga has many missed 
>>>>>> resolutions
>>>>>> and bad refresh performance.
>>>>>>
>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>> Client and server logs would certainly help. Please run:
>>>>>    * virt-viewer with --spice-debug option
>>>>>    * spice-server with SPICE_DEBUG_LEVEL environment variable set
>>>>>      to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
>>>>>      http://libvirt.org/drvqemu.html#qemucommand )
>>>>> and note the location in the logs where the freeze takes place.
>>>>>
>>>>> Regards,
>>>>>
>>>>> David
>>>>
>>>> Thanks for your reply, in attachments:
>>>> - domU's xl cfg: W7.cfg
>>>> - xl -vvv create/save/restore: xen logs.txt
>>>> - remote-viewer with --spice-debug after domU's start until xl 
>>>> save: spicelog-1.txt (zipped)
>>>> - remote-viewer with --spice-debug after domU's xl restore: 
>>>> spicelog-2.txt
>>>
>>> Sorry for my forgetfulness, here also qemu's log:
>>> - after domU's start until xl save: qemu-dm-W7.log.1
>>> - after domU's xl restore: qemu-dm-W7.log
>>>
>>>>
>>>> If you need more tests/informations tell me and I'll post them.
>>>>
>>>>
>>>>> Thanks for any reply and sorry for my bad english.
>>>>>
>>>>> _______________________________________________
>>>>> Spice-devel mailing list
>>>>> Spice-devel@lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>
>>
>> The problem persist, this time I saw these in xl dmesg after restore:
>>
>> (XEN) HVM2 restore: CPU 0
>> (XEN) HVM2 restore: CPU 1
>> (XEN) HVM2 restore: PIC 0
>> (XEN) HVM2 restore: PIC 1
>> (XEN) HVM2 restore: IOAPIC 0
>> (XEN) HVM2 restore: LAPIC 0
>> (XEN) HVM2 restore: LAPIC 1
>> (XEN) HVM2 restore: LAPIC_REGS 0
>> (XEN) HVM2 restore: LAPIC_REGS 1
>> (XEN) HVM2 restore: PCI_IRQ 0
>> (XEN) HVM2 restore: ISA_IRQ 0
>> (XEN) HVM2 restore: PCI_LINK 0
>> (XEN) HVM2 restore: PIT 0
>> (XEN) HVM2 restore: RTC 0
>> (XEN) HVM2 restore: HPET 0
>> (XEN) HVM2 restore: PMTIMER 0
>> (XEN) HVM2 restore: MTRR 0
>> (XEN) HVM2 restore: MTRR 1
>> (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
>> (XEN) HVM2 restore: VIRIDIAN_VCPU 0
>> (XEN) HVM2 restore: VIRIDIAN_VCPU 1
>> (XEN) HVM2 restore: VMCE_VCPU 0
>> (XEN) HVM2 restore: VMCE_VCPU 1
>> (XEN) HVM2 restore: TSC_ADJUST 0
>> (XEN) HVM2 restore: TSC_ADJUST 1
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
>> (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
>> (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from (4) 
>> to (32) frames.
>> (XEN) irq.c:380: Dom2 callback via changed to GSI 24
>>
>> Tested on latest staging (commit 
>> 7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:
>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>
>> If you need more informations or tests tell me and I'll post them.
>> Thanks for any reply and sorry for my bad english.
>
> I did another tests updating to latest git staging (commit 
> 3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of 
> "only" 2-3 minutes but now when it appears to restart (after 2-3 
> minutes) windows domUs undefinitely hangs instead.
> No further details in xen and domU's logs.
>
> If you need more tests/details tell me and I'll do them.
>
> Thanks for any reply.

I did a new test with xen build based on tag 4.5.0-rc2 and on xl dmesg 
show these errors:
> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
Before and after save/restore, with stdvga instead not show them.

Below I posted full xl dmesg of domU, if you need more 
informations/tests tell me and I'll post them.


> (d4) HVM Loader
> (d4) Detected Xen v4.5.0-rc
> (d4) Xenbus rings @0xfeffc000, event channel 1
> (d4) System requested SeaBIOS
> (d4) CPU speed is 2660 MHz
> (d4) Relocating guest memory for lowmem MMIO space disabled
> (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -> 5
> (d4) PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -> 10
> (d4) PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -> 11
> (d4) PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -> 5
> (d4) PCI-ISA link 3 routed to IRQ5
> (d4) pci dev 01:3 INTA->IRQ10
> (d4) pci dev 02:0 INTA->IRQ11
> (d4) pci dev 03:0 INTA->IRQ5
> (d4) pci dev 04:0 INTA->IRQ5
> (d4) pci dev 05:0 INTA->IRQ10
> (d4) pci dev 06:0 INTA->IRQ11
> (d4) pci dev 1d:0 INTA->IRQ10
> (d4) pci dev 1d:1 INTB->IRQ11
> (d4) pci dev 1d:2 INTC->IRQ5
> (d4) pci dev 1d:7 INTD->IRQ5
> (d4) No RAM in high memory; setting high_mem resource base to 100000000
> (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000
> (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000
> (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008
> (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000
> (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000
> (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000
> (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000
> (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000
> (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000
> (d4) pci dev 02:0 bar 10 size 000000100: 00000c001
> (d4) pci dev 06:0 bar 10 size 000000100: 00000c101
> (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000
> (d4) pci dev 04:0 bar 10 size 000000020: 00000c201
> (d4) pci dev 05:0 bar 1c size 000000020: 00000c221
> (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241
> (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261
> (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281
> (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1
> (d4) Multiprocessor initialisation:
> (d4)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
> (d4)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
> (d4) Testing HVM environment:
> (d4)  - REP INSB across page boundaries ... passed
> (d4)  - GS base MSRs and SWAPGS ... passed
> (d4) Passed 2 of 2 tests
> (d4) Writing SMBIOS tables ...
> (d4) Loading SeaBIOS ...
> (d4) Creating MP tables ...
> (d4) Loading ACPI ...
> (d4) S3 disabled
> (d4) S4 disabled
> (d4) vm86 TSS at fc00a100
> (d4) BIOS map:
> (d4)  10000-100d3: Scratch space
> (d4)  c0000-fffff: Main BIOS
> (d4) E820 table:
> (d4)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> (d4)  HOLE: 00000000:000a0000 - 00000000:000c0000
> (d4)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
> (d4)  [02]: 00000000:00100000 - 00000000:78000000: RAM
> (d4)  HOLE: 00000000:78000000 - 00000000:fc000000
> (d4)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> (d4) Invoking SeaBIOS ...
> (d4) SeaBIOS (version 
> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> (d4)
> (d4) Found Xen hypervisor signature at 40000100
> (d4) Running on QEMU (i440fx)
> (d4) xen: copy e820...
> (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
> (d4) CPU Mhz=3D2661
> (d4) Found 13 PCI devices (max PCI bus is 00)
> (d4) Allocated Xen hypercall page at 77fff000
> (d4) Detected Xen v4.5.0-rc
> (d4) xen: copy BIOS tables...
> (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
> (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
> (d4) Copying PIR from 0x00010030 to 0x000f0dc0
> (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
> (d4) Using pmtimer, ioport 0xb008
> (d4) Scan for VGA option rom
> (d4) Running option rom at c000:0003
> (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes
> (d4) pmm call arg1=3D0
> (d4) Turning on vga text mode console
> (d4) SeaBIOS (version 
> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838
> (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)
> (d4) Found 0 lpt ports
> (d4) Found 0 serial ports
> (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)
> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
> (d4) UHCI init on dev 00:1d.0 (io=3Dc240)
> (d4) UHCI init on dev 00:1d.1 (io=3Dc260)
> (d4) UHCI init on dev 00:1d.2 (io=3Dc280)
> (d4) PS2 keyboard initialized
> (d4) All threads complete.
> (d4) Scan for option roms
> (d4) Running option rom at c980:0003
> (d4) pmm call arg1=3D1
> (d4) pmm call arg1=3D0
> (d4) pmm call arg1=3D1
> (d4) pmm call arg1=3D0
> (d4) Searching bootorder for: /pci@i0cf8/*@6
> (d4)
> (d4) Press F12 for boot menu.
> (d4)
> (d4) Searching bootorder for: HALT
> (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba 
> LCHS=3D1024/255/63 s=3D102400000
> (d4)
> (d4) Space available for UMB: ca800-ee800, f0000-f0ce0
> (d4) Returned 258048 bytes of ZoneHigh
> (d4) e820 map has 6 items:
> (d4)   0: 0000000000000000 - 000000000009fc00 =3D 1 RAM
> (d4)   1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED
> (d4)   2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED
> (d4)   3: 0000000000100000 - 0000000077fff000 =3D 1 RAM
> (d4)   4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED
> (d4)   5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED
> (d4) enter handle_19:
> (d4)   NULL
> (d4) Booting from DVD/CD...
> (d4) Device reports MEDIUM NOT PRESENT
> (d4) scsi_is_ready returned -1
> (d4) Boot failed: Could not read from CDROM (code 0003)
> (d4) enter handle_18:
> (d4)   NULL
> (d4) Booting from Hard Disk...
> (d4) Booting from 0000:7c00
> (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 
> 1 build: 1db1
> (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
> (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
> (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
> (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -> 0
> (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -> 0
> (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -> 0
> (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -> 0
> *(XEN) hvm.c:6119:d4v1 Bad HVM op 23.**
> **(XEN) hvm.c:6119:d4v1 Bad HVM op 23.*
> (XEN) irq.c:380: Dom4 callback via changed to GSI 24
> (XEN) HVM4 save: CPU
> (XEN) HVM4 save: PIC
> (XEN) HVM4 save: IOAPIC
> (XEN) HVM4 save: LAPIC
> (XEN) HVM4 save: LAPIC_REGS
> (XEN) HVM4 save: PCI_IRQ
> (XEN) HVM4 save: ISA_IRQ
> (XEN) HVM4 save: PCI_LINK
> (XEN) HVM4 save: PIT
> (XEN) HVM4 save: RTC
> (XEN) HVM4 save: HPET
> (XEN) HVM4 save: PMTIMER
> (XEN) HVM4 save: MTRR
> (XEN) HVM4 save: VIRIDIAN_DOMAIN
> (XEN) HVM4 save: CPU_XSAVE
> (XEN) HVM4 save: VIRIDIAN_VCPU
> (XEN) HVM4 save: VMCE_VCPU
> (XEN) HVM4 save: TSC_ADJUST
> (XEN) HVM5 restore: CPU 0
> (XEN) HVM5 restore: CPU 1
> (XEN) HVM5 restore: PIC 0
> (XEN) HVM5 restore: PIC 1
> (XEN) HVM5 restore: IOAPIC 0
> (XEN) HVM5 restore: LAPIC 0
> (XEN) HVM5 restore: LAPIC 1
> (XEN) HVM5 restore: LAPIC_REGS 0
> (XEN) HVM5 restore: LAPIC_REGS 1
> (XEN) HVM5 restore: PCI_IRQ 0
> (XEN) HVM5 restore: ISA_IRQ 0
> (XEN) HVM5 restore: PCI_LINK 0
> (XEN) HVM5 restore: PIT 0
> (XEN) HVM5 restore: RTC 0
> (XEN) HVM5 restore: HPET 0
> (XEN) HVM5 restore: PMTIMER 0
> (XEN) HVM5 restore: MTRR 0
> (XEN) HVM5 restore: MTRR 1
> (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0
> (XEN) HVM5 restore: VIRIDIAN_VCPU 0
> (XEN) HVM5 restore: VIRIDIAN_VCPU 1
> (XEN) HVM5 restore: VMCE_VCPU 0
> (XEN) HVM5 restore: VMCE_VCPU 1
> (XEN) HVM5 restore: TSC_ADJUST 0
> (XEN) HVM5 restore: TSC_ADJUST 1
> (XEN) irq.c:380: Dom5 callback via changed to None
> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
> (XEN) irq.c:380: Dom5 callback via changed to GSI 24



--------------040907080300070404050807
Content-Type: text/html; charset=windows-1252
Content-Length: 20438
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Il 19/09/2014 15:18, Fabio Fantoni ha
      scritto:<br>
    </div>
    <blockquote cite=3D"mid:541C2D39.1060607@m2r.biz" type=3D"cite">Il
      12/09/2014 16:46, Fabio Fantoni ha scritto:
      <br>
      <blockquote type=3D"cite">Il 08/07/2014 12:34, Fabio Fantoni ha
        scritto:
        <br>
        <blockquote type=3D"cite">Il 08/07/2014 12:06, Fabio Fantoni ha
          scritto:
          <br>
          <blockquote type=3D"cite">Il 08/07/2014 10:53, David Ja=9Aa ha
            scritto:
            <br>
            <blockquote type=3D"cite">Hi,
              <br>
              <br>
              On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
              <br>
              <blockquote type=3D"cite">On xen 4.5 (tried with qemu
                2.0.0/2.1-rc0, spice 0.12.5 and client with
                <br>
                spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works
                good as kvm
                <br>
                except for one problem after xl save/restore, when after
                restore on
                <br>
                spice client connect=A0 the domU's screen freezed for 2-3
                minutes (and
                <br>
                seems also windows), after this time seems that all
                return to works
                <br>
                correctly.
                <br>
                This problem happen also if spice client connect long
                time after restore.
                <br>
                With stdvga not have this problem but stdvga has many
                missed resolutions
                <br>
                and bad refresh performance.
                <br>
                <br>
                If you need more tests/informations tell me and I'll
                post them.
                <br>
              </blockquote>
              Client and server logs would certainly help. Please run:
              <br>
              =A0=A0 * virt-viewer with --spice-debug option
              <br>
              =A0=A0 * spice-server with SPICE_DEBUG_LEVEL environment
              variable set
              <br>
              =A0=A0=A0=A0 to 4 or 5 (if you use qemu+libvirt, use qemu:env
              element:
              <br>
              =A0=A0=A0=A0 <a class=3D"moz-txt-link-freetext" href=3D"http://libvirt.org/drvqemu.html#qemucommand">http://libvirt.org/drvqemu.html#qemucommand</a> )
              <br>
              and note the location in the logs where the freeze takes
              place.
              <br>
              <br>
              Regards,
              <br>
              <br>
              David
              <br>
            </blockquote>
            <br>
            Thanks for your reply, in attachments:
            <br>
            - domU's xl cfg: W7.cfg
            <br>
            - xl -vvv create/save/restore: xen logs.txt
            <br>
            - remote-viewer with --spice-debug after domU's start until
            xl save: spicelog-1.txt (zipped)
            <br>
            - remote-viewer with --spice-debug after domU's xl restore:
            spicelog-2.txt
            <br>
          </blockquote>
          <br>
          Sorry for my forgetfulness, here also qemu's log:
          <br>
          - after domU's start until xl save: qemu-dm-W7.log.1
          <br>
          - after domU's xl restore: qemu-dm-W7.log
          <br>
          <br>
          <blockquote type=3D"cite">
            <br>
            If you need more tests/informations tell me and I'll post
            them.
            <br>
            <br>
            <br>
            <blockquote type=3D"cite">Thanks for any reply and sorry for
              my bad english.
              <br>
              <br>
              _______________________________________________
              <br>
              Spice-devel mailing list
              <br>
              <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a>
              <br>
              <a class=3D"moz-txt-link-freetext" href=3D"http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a>
              <br>
            </blockquote>
          </blockquote>
          <br>
        </blockquote>
        <br>
        The problem persist, this time I saw these in xl dmesg after
        restore:
        <br>
        <br>
        (XEN) HVM2 restore: CPU 0
        <br>
        (XEN) HVM2 restore: CPU 1
        <br>
        (XEN) HVM2 restore: PIC 0
        <br>
        (XEN) HVM2 restore: PIC 1
        <br>
        (XEN) HVM2 restore: IOAPIC 0
        <br>
        (XEN) HVM2 restore: LAPIC 0
        <br>
        (XEN) HVM2 restore: LAPIC 1
        <br>
        (XEN) HVM2 restore: LAPIC_REGS 0
        <br>
        (XEN) HVM2 restore: LAPIC_REGS 1
        <br>
        (XEN) HVM2 restore: PCI_IRQ 0
        <br>
        (XEN) HVM2 restore: ISA_IRQ 0
        <br>
        (XEN) HVM2 restore: PCI_LINK 0
        <br>
        (XEN) HVM2 restore: PIT 0
        <br>
        (XEN) HVM2 restore: RTC 0
        <br>
        (XEN) HVM2 restore: HPET 0
        <br>
        (XEN) HVM2 restore: PMTIMER 0
        <br>
        (XEN) HVM2 restore: MTRR 0
        <br>
        (XEN) HVM2 restore: MTRR 1
        <br>
        (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
        <br>
        (XEN) HVM2 restore: VIRIDIAN_VCPU 0
        <br>
        (XEN) HVM2 restore: VIRIDIAN_VCPU 1
        <br>
        (XEN) HVM2 restore: VMCE_VCPU 0
        <br>
        (XEN) HVM2 restore: VMCE_VCPU 1
        <br>
        (XEN) HVM2 restore: TSC_ADJUST 0
        <br>
        (XEN) HVM2 restore: TSC_ADJUST 1
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
        <br>
        (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
        <br>
        (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from
        (4) to (32) frames.
        <br>
        (XEN) irq.c:380: Dom2 callback via changed to GSI 24
        <br>
        <br>
        Tested on latest staging (commit
        7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice
        patches:
        <br>
        <a class=3D"moz-txt-link-freetext" href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a>
        <br>
        <br>
        If you need more informations or tests tell me and I'll post
        them.
        <br>
        Thanks for any reply and sorry for my bad english.
        <br>
      </blockquote>
      <br>
      I did another tests updating to latest git staging (commit
      3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of
      "only" 2-3 minutes but now when it appears to restart (after 2-3
      minutes) windows domUs undefinitely hangs instead.
      <br>
      No further details in xen and domU's logs.
      <br>
      <br>
      If you need more tests/details tell me and I'll do them.
      <br>
      <br>
      Thanks for any reply.
      <br>
    </blockquote>
    <br>
    I did a new test with xen build based on tag 4.5.0-rc2 and on xl
    dmesg show these errors:<br>
    <blockquote type=3D"cite"><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b></blockquote>
    Before and after save/restore, with stdvga instead not show them.<br>
    <br>
    Below I posted full xl dmesg of domU, if you need more
    informations/tests tell me and I'll post them.<br>
    <br>
    <br>
    <blockquote type=3D"cite">(d4) HVM Loader<br>
      (d4) Detected Xen v4.5.0-rc<br>
      (d4) Xenbus rings @0xfeffc000, event channel 1<br>
      (d4) System requested SeaBIOS<br>
      (d4) CPU speed is 2660 MHz<br>
      (d4) Relocating guest memory for lowmem MMIO space disabled<br>
      (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -&gt; 5<br>
      (d4) PCI-ISA link 0 routed to IRQ5<br>
      (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -&gt; 10<br>
      (d4) PCI-ISA link 1 routed to IRQ10<br>
      (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -&gt; 11<br>
      (d4) PCI-ISA link 2 routed to IRQ11<br>
      (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -&gt; 5<br>
      (d4) PCI-ISA link 3 routed to IRQ5<br>
      (d4) pci dev 01:3 INTA-&gt;IRQ10<br>
      (d4) pci dev 02:0 INTA-&gt;IRQ11<br>
      (d4) pci dev 03:0 INTA-&gt;IRQ5<br>
      (d4) pci dev 04:0 INTA-&gt;IRQ5<br>
      (d4) pci dev 05:0 INTA-&gt;IRQ10<br>
      (d4) pci dev 06:0 INTA-&gt;IRQ11<br>
      (d4) pci dev 1d:0 INTA-&gt;IRQ10<br>
      (d4) pci dev 1d:1 INTB-&gt;IRQ11<br>
      (d4) pci dev 1d:2 INTC-&gt;IRQ5<br>
      (d4) pci dev 1d:7 INTD-&gt;IRQ5<br>
      (d4) No RAM in high memory; setting high_mem resource base to
      100000000<br>
      (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000<br>
      (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000<br>
      (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008<br>
      (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000<br>
      (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000<br>
      (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000<br>
      (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000<br>
      (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000<br>
      (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000<br>
      (d4) pci dev 02:0 bar 10 size 000000100: 00000c001<br>
      (d4) pci dev 06:0 bar 10 size 000000100: 00000c101<br>
      (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000<br>
      (d4) pci dev 04:0 bar 10 size 000000020: 00000c201<br>
      (d4) pci dev 05:0 bar 1c size 000000020: 00000c221<br>
      (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241<br>
      (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261<br>
      (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281<br>
      (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1<br>
      (d4) Multiprocessor initialisation:<br>
      (d4)=A0 - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
      ... done.<br>
      (d4)=A0 - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
      ... done.<br>
      (d4) Testing HVM environment:<br>
      (d4)=A0 - REP INSB across page boundaries ... passed<br>
      (d4)=A0 - GS base MSRs and SWAPGS ... passed<br>
      (d4) Passed 2 of 2 tests<br>
      (d4) Writing SMBIOS tables ...<br>
      (d4) Loading SeaBIOS ...<br>
      (d4) Creating MP tables ...<br>
      (d4) Loading ACPI ...<br>
      (d4) S3 disabled<br>
      (d4) S4 disabled<br>
      (d4) vm86 TSS at fc00a100<br>
      (d4) BIOS map:<br>
      (d4)=A0 10000-100d3: Scratch space<br>
      (d4)=A0 c0000-fffff: Main BIOS<br>
      (d4) E820 table:<br>
      (d4)=A0 [00]: 00000000:00000000 - 00000000:000a0000: RAM<br>
      (d4)=A0 HOLE: 00000000:000a0000 - 00000000:000c0000<br>
      (d4)=A0 [01]: 00000000:000c0000 - 00000000:00100000: RESERVED<br>
      (d4)=A0 [02]: 00000000:00100000 - 00000000:78000000: RAM<br>
      (d4)=A0 HOLE: 00000000:78000000 - 00000000:fc000000<br>
      (d4)=A0 [03]: 00000000:fc000000 - 00000001:00000000: RESERVED<br>
      (d4) Invoking SeaBIOS ...<br>
      (d4) SeaBIOS (version
      debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
      (d4) <br>
      (d4) Found Xen hypervisor signature at 40000100<br>
      (d4) Running on QEMU (i440fx)<br>
      (d4) xen: copy e820...<br>
      (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)<br>
      (d4) CPU Mhz=3D2661<br>
      (d4) Found 13 PCI devices (max PCI bus is 00)<br>
      (d4) Allocated Xen hypercall page at 77fff000<br>
      (d4) Detected Xen v4.5.0-rc<br>
      (d4) xen: copy BIOS tables...<br>
      (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40<br>
      (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40<br>
      (d4) Copying PIR from 0x00010030 to 0x000f0dc0<br>
      (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90<br>
      (d4) Using pmtimer, ioport 0xb008<br>
      (d4) Scan for VGA option rom<br>
      (d4) Running option rom at c000:0003<br>
      (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes<br>
      (d4) pmm call arg1=3D0<br>
      (d4) Turning on vga text mode console<br>
      (d4) SeaBIOS (version
      debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
      (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838<br>
      (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)<br>
      (d4) Found 0 lpt ports<br>
      (d4) Found 0 serial ports<br>
      (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)<br>
      (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)<br>
      (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)<br>
      (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0<br>
      (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]<br>
      (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1<br>
      (d4) UHCI init on dev 00:1d.0 (io=3Dc240)<br>
      (d4) UHCI init on dev 00:1d.1 (io=3Dc260)<br>
      (d4) UHCI init on dev 00:1d.2 (io=3Dc280)<br>
      (d4) PS2 keyboard initialized<br>
      (d4) All threads complete.<br>
      (d4) Scan for option roms<br>
      (d4) Running option rom at c980:0003<br>
      (d4) pmm call arg1=3D1<br>
      (d4) pmm call arg1=3D0<br>
      (d4) pmm call arg1=3D1<br>
      (d4) pmm call arg1=3D0<br>
      (d4) Searching bootorder for: /pci@i0cf8/*@6<br>
      (d4) <br>
      (d4) Press F12 for boot menu.<br>
      (d4) <br>
      (d4) Searching bootorder for: HALT<br>
      (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba
      LCHS=3D1024/255/63 s=3D102400000<br>
      (d4) <br>
      (d4) Space available for UMB: ca800-ee800, f0000-f0ce0<br>
      (d4) Returned 258048 bytes of ZoneHigh<br>
      (d4) e820 map has 6 items:<br>
      (d4)=A0=A0 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM<br>
      (d4)=A0=A0 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED<br>
      (d4)=A0=A0 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED<br>
      (d4)=A0=A0 3: 0000000000100000 - 0000000077fff000 =3D 1 RAM<br>
      (d4)=A0=A0 4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED<br>
      (d4)=A0=A0 5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED<br>
      (d4) enter handle_19:<br>
      (d4)=A0=A0 NULL<br>
      (d4) Booting from DVD/CD...<br>
      (d4) Device reports MEDIUM NOT PRESENT<br>
      (d4) scsi_is_ready returned -1<br>
      (d4) Boot failed: Could not read from CDROM (code 0003)<br>
      (d4) enter handle_18:<br>
      (d4)=A0=A0 NULL<br>
      (d4) Booting from Hard Disk...<br>
      (d4) Booting from 0000:7c00<br>
      (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1
      sp: 1 build: 1db1<br>
      (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff<br>
      (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe<br>
      (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd<br>
      (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -&gt; 0<br>
      (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -&gt; 0<br>
      (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -&gt; 0<br>
      (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -&gt; 0<br>
      <b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><b><br>
      </b><b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><br>
      (XEN) irq.c:380: Dom4 callback via changed to GSI 24<br>
      (XEN) HVM4 save: CPU<br>
      (XEN) HVM4 save: PIC<br>
      (XEN) HVM4 save: IOAPIC<br>
      (XEN) HVM4 save: LAPIC<br>
      (XEN) HVM4 save: LAPIC_REGS<br>
      (XEN) HVM4 save: PCI_IRQ<br>
      (XEN) HVM4 save: ISA_IRQ<br>
      (XEN) HVM4 save: PCI_LINK<br>
      (XEN) HVM4 save: PIT<br>
      (XEN) HVM4 save: RTC<br>
      (XEN) HVM4 save: HPET<br>
      (XEN) HVM4 save: PMTIMER<br>
      (XEN) HVM4 save: MTRR<br>
      (XEN) HVM4 save: VIRIDIAN_DOMAIN<br>
      (XEN) HVM4 save: CPU_XSAVE<br>
      (XEN) HVM4 save: VIRIDIAN_VCPU<br>
      (XEN) HVM4 save: VMCE_VCPU<br>
      (XEN) HVM4 save: TSC_ADJUST<br>
      (XEN) HVM5 restore: CPU 0<br>
      (XEN) HVM5 restore: CPU 1<br>
      (XEN) HVM5 restore: PIC 0<br>
      (XEN) HVM5 restore: PIC 1<br>
      (XEN) HVM5 restore: IOAPIC 0<br>
      (XEN) HVM5 restore: LAPIC 0<br>
      (XEN) HVM5 restore: LAPIC 1<br>
      (XEN) HVM5 restore: LAPIC_REGS 0<br>
      (XEN) HVM5 restore: LAPIC_REGS 1<br>
      (XEN) HVM5 restore: PCI_IRQ 0<br>
      (XEN) HVM5 restore: ISA_IRQ 0<br>
      (XEN) HVM5 restore: PCI_LINK 0<br>
      (XEN) HVM5 restore: PIT 0<br>
      (XEN) HVM5 restore: RTC 0<br>
      (XEN) HVM5 restore: HPET 0<br>
      (XEN) HVM5 restore: PMTIMER 0<br>
      (XEN) HVM5 restore: MTRR 0<br>
      (XEN) HVM5 restore: MTRR 1<br>
      (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0<br>
      (XEN) HVM5 restore: VIRIDIAN_VCPU 0<br>
      (XEN) HVM5 restore: VIRIDIAN_VCPU 1<br>
      (XEN) HVM5 restore: VMCE_VCPU 0<br>
      (XEN) HVM5 restore: VMCE_VCPU 1<br>
      (XEN) HVM5 restore: TSC_ADJUST 0<br>
      (XEN) HVM5 restore: TSC_ADJUST 1<br>
      (XEN) irq.c:380: Dom5 callback via changed to None<br>
      <b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
      </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
      </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
      </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><br>
      (XEN) irq.c:380: Dom5 callback via changed to GSI 24</blockquote>
    <br>
    <br>
  </body>
</html>

--------------040907080300070404050807--


--===============7257911430843709156==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7257911430843709156==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 10:25:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10: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 1Xorao-00056m-25; Thu, 13 Nov 2014 10:25:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xoram-00056h-5t
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 10:25:32 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	27/C8-28296-B1784645; Thu, 13 Nov 2014 10:25:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415874330!11051080!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7434 invoked from network); 13 Nov 2014 10:25:30 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 10:25:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 10:25:30 +0000
Message-Id: <546495280200007800047203@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 10:25:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to
 be overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
> --- a/arch/x86/include/asm/device.h
> +++ b/arch/x86/include/asm/device.h
> @@ -13,4 +13,6 @@ struct dev_archdata {
>  struct pdev_archdata {
>  };
>  
> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK

Is there a particular reason you put this here rather than in
dma-mapping.h?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:25:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10: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 1Xorao-00056m-25; Thu, 13 Nov 2014 10:25:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xoram-00056h-5t
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 10:25:32 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	27/C8-28296-B1784645; Thu, 13 Nov 2014 10:25:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415874330!11051080!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7434 invoked from network); 13 Nov 2014 10:25:30 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 10:25:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 10:25:30 +0000
Message-Id: <546495280200007800047203@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 10:25:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to
 be overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
> --- a/arch/x86/include/asm/device.h
> +++ b/arch/x86/include/asm/device.h
> @@ -13,4 +13,6 @@ struct dev_archdata {
>  struct pdev_archdata {
>  };
>  
> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK

Is there a particular reason you put this here rather than in
dma-mapping.h?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:30:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:30:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XorfQ-0005FB-Ov; Thu, 13 Nov 2014 10:30:20 +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 1XorfP-0005F6-Ae
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 10:30:19 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	7B/28-22819-A3884645; Thu, 13 Nov 2014 10:30:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415874614!6964698!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8263 invoked from network); 13 Nov 2014 10:30:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 10:30:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190882623"
Message-ID: <54648833.6020407@citrix.com>
Date: Thu, 13 Nov 2014 10:30:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
	<546495280200007800047203@mail.emea.novell.com>
In-Reply-To: <546495280200007800047203@mail.emea.novell.com>
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to
 be overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 10:25, Jan Beulich wrote:
>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>> --- a/arch/x86/include/asm/device.h
>> +++ b/arch/x86/include/asm/device.h
>> @@ -13,4 +13,6 @@ struct dev_archdata {
>>  struct pdev_archdata {
>>  };
>>  
>> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
> 
> Is there a particular reason you put this here rather than in
> dma-mapping.h?

I was because asm/dma-mapping is included too late for it to work, but
looking at the current code it looks like it ought to work.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:30:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:30:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XorfQ-0005FB-Ov; Thu, 13 Nov 2014 10:30:20 +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 1XorfP-0005F6-Ae
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 10:30:19 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	7B/28-22819-A3884645; Thu, 13 Nov 2014 10:30:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415874614!6964698!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8263 invoked from network); 13 Nov 2014 10:30:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 10:30:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190882623"
Message-ID: <54648833.6020407@citrix.com>
Date: Thu, 13 Nov 2014 10:30:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
	<546495280200007800047203@mail.emea.novell.com>
In-Reply-To: <546495280200007800047203@mail.emea.novell.com>
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to
 be overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 10:25, Jan Beulich wrote:
>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>> --- a/arch/x86/include/asm/device.h
>> +++ b/arch/x86/include/asm/device.h
>> @@ -13,4 +13,6 @@ struct dev_archdata {
>>  struct pdev_archdata {
>>  };
>>  
>> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
> 
> Is there a particular reason you put this here rather than in
> dma-mapping.h?

I was because asm/dma-mapping is included too late for it to work, but
looking at the current code it looks like it ought to work.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:32:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:32:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XorhK-0005Ug-OT; Thu, 13 Nov 2014 10:32:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XorhI-0005UZ-P1
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 10:32:16 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	61/75-27785-0B884645; Thu, 13 Nov 2014 10:32:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415874734!11690200!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23647 invoked from network); 13 Nov 2014 10:32:14 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 10:32:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 10:32:14 +0000
Message-Id: <546496BD020000780004721D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 10:32:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
	<546495280200007800047203@mail.emea.novell.com>
In-Reply-To: <546495280200007800047203@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to
 be overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 11:25, <JBeulich@suse.com> wrote:
>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>> --- a/arch/x86/include/asm/device.h
>> +++ b/arch/x86/include/asm/device.h
>> @@ -13,4 +13,6 @@ struct dev_archdata {
>>  struct pdev_archdata {
>>  };
>>  
>> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
> 
> Is there a particular reason you put this here rather than in
> dma-mapping.h?

Never mind - I see you need it that way so that struct dma_map_ops
gets the get_required_mask field defined, other than e.g. ia64 which
handles through another abstraction layer.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:32:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:32:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XorhK-0005Ug-OT; Thu, 13 Nov 2014 10:32:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XorhI-0005UZ-P1
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 10:32:16 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	61/75-27785-0B884645; Thu, 13 Nov 2014 10:32:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415874734!11690200!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23647 invoked from network); 13 Nov 2014 10:32:14 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 10:32:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 10:32:14 +0000
Message-Id: <546496BD020000780004721D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 10:32:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
	<546495280200007800047203@mail.emea.novell.com>
In-Reply-To: <546495280200007800047203@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to
 be overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 11:25, <JBeulich@suse.com> wrote:
>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>> --- a/arch/x86/include/asm/device.h
>> +++ b/arch/x86/include/asm/device.h
>> @@ -13,4 +13,6 @@ struct dev_archdata {
>>  struct pdev_archdata {
>>  };
>>  
>> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
> 
> Is there a particular reason you put this here rather than in
> dma-mapping.h?

Never mind - I see you need it that way so that struct dma_map_ops
gets the get_required_mask field defined, other than e.g. ia64 which
handles through another abstraction layer.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:38:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:38:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XornU-0005f9-I2; Thu, 13 Nov 2014 10:38:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XornT-0005f4-3H
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 10:38:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	90/98-09936-E2A84645; Thu, 13 Nov 2014 10:38:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415875116!5121372!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21921 invoked from network); 13 Nov 2014 10:38:37 -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;
	13 Nov 2014 10:38:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="192336482"
Message-ID: <54648A27.1060907@citrix.com>
Date: Thu, 13 Nov 2014 10:38:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
	<546390FC0200007800046E50@mail.emea.novell.com>
In-Reply-To: <546390FC0200007800046E50@mail.emea.novell.com>
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>, "H. Peter
	Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 15:55, Jan Beulich wrote:
>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +	u64 max_mfn;
>> +
>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
>> +}
> The value the hypercall returns is exclusive and an unsigned long.

All hypercalls return long, despite lack of clarity, or in some cases,
documentation to the contrary.

Almost all hypercalls need the ability to return errors in the form of
negative numbers, and those which don't should not be treated any
differently.  Furthermore, the overflow conditions for the compat
version of XENMEM_maximum_ram_page specifically truncate to INT_MAX and
INT_MIN as boundaries, making the return value signed.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:38:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:38:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XornU-0005f9-I2; Thu, 13 Nov 2014 10:38:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XornT-0005f4-3H
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 10:38:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	90/98-09936-E2A84645; Thu, 13 Nov 2014 10:38:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415875116!5121372!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21921 invoked from network); 13 Nov 2014 10:38:37 -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;
	13 Nov 2014 10:38:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="192336482"
Message-ID: <54648A27.1060907@citrix.com>
Date: Thu, 13 Nov 2014 10:38:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
	<546390FC0200007800046E50@mail.emea.novell.com>
In-Reply-To: <546390FC0200007800046E50@mail.emea.novell.com>
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>, "H. Peter
	Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 15:55, Jan Beulich wrote:
>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +	u64 max_mfn;
>> +
>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
>> +}
> The value the hypercall returns is exclusive and an unsigned long.

All hypercalls return long, despite lack of clarity, or in some cases,
documentation to the contrary.

Almost all hypercalls need the ability to return errors in the form of
negative numbers, and those which don't should not be treated any
differently.  Furthermore, the overflow conditions for the compat
version of XENMEM_maximum_ram_page specifically truncate to INT_MAX and
INT_MIN as boundaries, making the return value signed.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:40:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:40:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XorpI-0005ks-1t; Thu, 13 Nov 2014 10:40:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XorpG-0005kl-Va
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 10:40:31 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	5A/54-02696-D9A84645; Thu, 13 Nov 2014 10:40:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415875227!12265382!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20851 invoked from network); 13 Nov 2014 10:40:28 -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 Nov 2014 10:40:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="192336956"
Message-ID: <54648A90.5060307@citrix.com>
Date: Thu, 13 Nov 2014 10:40:16 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Xing Lin <linxingnku@gmail.com>, <xen-devel@lists.xen.org>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
In-Reply-To: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 18:41, Xing Lin wrote:
> Hi, 
> 
> I am aware that Xen via libvirt is in the group C support for openstack
> but since I am not able to install xenserver iso at compute machines I
> have, I have to consider to use xen with libvirt (xcp-xapi is not
> available for ubuntu14.04). I have three nodes, each one running ubuntu
> 14.04. I follow the instruction to install juno in ubuntu 14.04 and it
> works (I can create instances from openstack GUI - horizon) when I use
> kvm as the hypervisor at the compute node . However, if I switch to use
> xen as the hypervisor by installing xen-hypervisor-amd64 or
> nova-compute-xen, it will fail to create instances. It complained
> "backend for qemu disk is not ready". I checked and did not find qemu
> process running in dom0. I could not find /etc/init.d/xencommons
> either. Then, I compiled and installed xen-4.4 from source code and I
> got xencommons in /etc/init.d. qemu process is running in dom0. However,
> the dom0 kernel crashes this time when I try to launch an instance from
> openstack GUI. I am able to create a xen guest with virt-install from
> command line, with the following command. 
> 
> "$ virt-install --connect=xen:/// --name u14.04.3 --ram 1024 --disk
> u14.04.3.img,size=4,driver_name=qemu
> --location http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/ --network
> bridge=virbr0"

Does this ubuntu bug look relevant?

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1350373

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:40:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:40:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XorpI-0005ks-1t; Thu, 13 Nov 2014 10:40:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XorpG-0005kl-Va
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 10:40:31 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	5A/54-02696-D9A84645; Thu, 13 Nov 2014 10:40:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415875227!12265382!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20851 invoked from network); 13 Nov 2014 10:40:28 -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 Nov 2014 10:40:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="192336956"
Message-ID: <54648A90.5060307@citrix.com>
Date: Thu, 13 Nov 2014 10:40:16 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Xing Lin <linxingnku@gmail.com>, <xen-devel@lists.xen.org>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
In-Reply-To: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 18:41, Xing Lin wrote:
> Hi, 
> 
> I am aware that Xen via libvirt is in the group C support for openstack
> but since I am not able to install xenserver iso at compute machines I
> have, I have to consider to use xen with libvirt (xcp-xapi is not
> available for ubuntu14.04). I have three nodes, each one running ubuntu
> 14.04. I follow the instruction to install juno in ubuntu 14.04 and it
> works (I can create instances from openstack GUI - horizon) when I use
> kvm as the hypervisor at the compute node . However, if I switch to use
> xen as the hypervisor by installing xen-hypervisor-amd64 or
> nova-compute-xen, it will fail to create instances. It complained
> "backend for qemu disk is not ready". I checked and did not find qemu
> process running in dom0. I could not find /etc/init.d/xencommons
> either. Then, I compiled and installed xen-4.4 from source code and I
> got xencommons in /etc/init.d. qemu process is running in dom0. However,
> the dom0 kernel crashes this time when I try to launch an instance from
> openstack GUI. I am able to create a xen guest with virt-install from
> command line, with the following command. 
> 
> "$ virt-install --connect=xen:/// --name u14.04.3 --ram 1024 --disk
> u14.04.3.img,size=4,driver_name=qemu
> --location http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/ --network
> bridge=virbr0"

Does this ubuntu bug look relevant?

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1350373

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:53:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:53:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xos1m-0006GA-EE; Thu, 13 Nov 2014 10:53:26 +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 1Xos1k-0006G5-Qb
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 10:53:24 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	DA/71-02696-4AD84645; Thu, 13 Nov 2014 10:53:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415876003!8926979!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16991 invoked from network); 13 Nov 2014 10:53:23 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 10:53:23 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 10:53:22 +0000
Message-Id: <54649BB2020000780004725A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 10:53:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
	<546390FC0200007800046E50@mail.emea.novell.com>
	<54648A27.1060907@citrix.com>
In-Reply-To: <54648A27.1060907@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"H. PeterAnvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 11:38, <andrew.cooper3@citrix.com> wrote:
> On 12/11/14 15:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>>> +u64
>>> +xen_swiotlb_get_required_mask(struct device *dev)
>>> +{
>>> +	u64 max_mfn;
>>> +
>>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>>> +
>>> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
>>> +}
>> The value the hypercall returns is exclusive and an unsigned long.
> 
> All hypercalls return long, despite lack of clarity, or in some cases,
> documentation to the contrary.

The emphasis wasn't on "unsigned" but on "long". But see also my
later reply to that same mail.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:53:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:53:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xos1m-0006GA-EE; Thu, 13 Nov 2014 10:53:26 +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 1Xos1k-0006G5-Qb
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 10:53:24 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	DA/71-02696-4AD84645; Thu, 13 Nov 2014 10:53:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415876003!8926979!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16991 invoked from network); 13 Nov 2014 10:53:23 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 10:53:23 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 10:53:22 +0000
Message-Id: <54649BB2020000780004725A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 10:53:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-4-git-send-email-david.vrabel@citrix.com>
	<546390FC0200007800046E50@mail.emea.novell.com>
	<54648A27.1060907@citrix.com>
In-Reply-To: <54648A27.1060907@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"H. PeterAnvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 11:38, <andrew.cooper3@citrix.com> wrote:
> On 12/11/14 15:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 16:25, <david.vrabel@citrix.com> wrote:
>>> +u64
>>> +xen_swiotlb_get_required_mask(struct device *dev)
>>> +{
>>> +	u64 max_mfn;
>>> +
>>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>>> +
>>> +	return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
>>> +}
>> The value the hypercall returns is exclusive and an unsigned long.
> 
> All hypercalls return long, despite lack of clarity, or in some cases,
> documentation to the contrary.

The emphasis wasn't on "unsigned" but on "long". But see also my
later reply to that same mail.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:58:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:58:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xos6F-0006O8-4Z; Thu, 13 Nov 2014 10:58:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xos6C-0006O3-MK
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 10:58:00 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	A6/55-27584-8BE84645; Thu, 13 Nov 2014 10:58:00 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415876277!11080217!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25942 invoked from network); 13 Nov 2014 10:57:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 10:57:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190889162"
Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.80)
	with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 05:57:55 -0500
Message-ID: <54648EB3.8040703@citrix.com>
Date: Thu, 13 Nov 2014 11:57:55 +0100
From: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Xing Lin <linxingnku@gmail.com>, <xen-devel@lists.xen.org>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
In-Reply-To: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + 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

El 12/11/14 a les 19.41, Xing Lin ha escrit:
> Hi,
> 
> I am aware that Xen via libvirt is in the group C support for openstack but
> since I am not able to install xenserver iso at compute machines I have, I
> have to consider to use xen with libvirt (xcp-xapi is not available for
> ubuntu14.04). I have three nodes, each one running ubuntu 14.04. I follow
> the instruction to install juno in ubuntu 14.04 and it works (I can create
> instances from openstack GUI - horizon) when I use kvm as the hypervisor at
> the compute node . However, if I switch to use xen as the hypervisor by
> installing xen-hypervisor-amd64 or nova-compute-xen, it will fail to create
> instances. It complained "backend for qemu disk is not ready". I checked
> and did not find qemu process running in dom0. I could not find
> /etc/init.d/xencommons either. Then, I compiled and installed xen-4.4 from
> source code and I got xencommons in /etc/init.d. qemu process is running in
> dom0. However, the dom0 kernel crashes this time when I try to launch an
> instance from openstack GUI. I am able to create a xen guest with
> virt-install from command line, with the following command.
> 
> "$ virt-install --connect=xen:/// --name u14.04.3 --ram 1024 --disk
> u14.04.3.img,size=4,driver_name=qemu --location
> http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/ --network
> bridge=virbr0"
> 
> 
> dmesg:
> 
> [ 9443.130600] blkfront: xvda: flush diskcache: enabled; persistent grants:
> enabled; indirect descriptors: disabled;
> [ 9443.132818]  xvda: xvda1
> [ 9444.604489] xen:grant_table: WARNING: g.e. 0x30 still in use!
> [ 9444.604496] deferring g.e. 0x30 (pfn 0xffffffffffffffff)
> [ 9444.604499] xen:grant_table: WARNING: g.e. 0x31 still in use!
> [ 9444.604502] deferring g.e. 0x31 (pfn 0xffffffffffffffff)
> [ 9444.604505] xen:grant_table: WARNING: g.e. 0x32 still in use!
> [ 9444.604508] deferring g.e. 0x32 (pfn 0xffffffffffffffff)
>   ==== lots of them====
> [ 9444.604719] xen:grant_table: WARNING: g.e. 0xe still in use!
> [ 9444.604721] deferring g.e. 0xe (pfn 0xffffffffffffffff)
> [ 9444.604723] xen:grant_table: WARNING: g.e. 0xd still in use!
> [ 9444.604725] deferring g.e. 0xd (pfn 0xffffffffffffffff)
> [ 9448.325408] ------------[ cut here ]------------
> [ 9448.325421] WARNING: CPU: 5 PID: 19902 at
> /build/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+0x
> 1a9/0x1b0()
> [ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF          O
> 3.13.0-33-generic #58-Ubuntu
> [ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS 2.1.15
> 09/02/2010
> [ 9448.325497]  0000000000000009 ffff8802d13d9aa8 ffffffff8171bd04
> 0000000000000000
> [ 9448.325501]  ffff8802d13d9ae0 ffffffff810676cd 0000000000000000
> 0000000000000001
> [ 9448.325505]  ffff88030418ffe0 ffff88031d6ab180 0000000000000010
> ffff8802d13d9af0
> [ 9448.325509] Call Trace:
> [ 9448.325518]  [<ffffffff8171bd04>] dump_stack+0x45/0x56
> [ 9448.325523]  [<ffffffff810676cd>] warn_slowpath_common+0x7d/0xa0
> [ 9448.325526]  [<ffffffff810677aa>] warn_slowpath_null+0x1a/0x20
> [ 9448.325530]  [<ffffffff81004e99>] xen_mc_flush+0x1a9/0x1b0
> [ 9448.325534]  [<ffffffff81006b99>] xen_set_pud_hyper+0x109/0x110
> [ 9448.325538]  [<ffffffff81006c3b>] xen_set_pud+0x9b/0xb0
> [ 9448.325543]  [<ffffffff81177f06>] __pmd_alloc+0xd6/0x110
> [ 9448.325548]  [<ffffffff81182218>] move_page_tables+0x678/0x720
> [ 9448.325552]  [<ffffffff8117ddb7>] ? vma_adjust+0x337/0x7d0
> [ 9448.325557]  [<ffffffff811c23fd>] shift_arg_pages+0xbd/0x1b0
> [ 9448.325560]  [<ffffffff81181671>] ? mprotect_fixup+0x151/0x290
> [ 9448.325564]  [<ffffffff811c26cb>] setup_arg_pages+0x1db/0x200
> [ 9448.325570]  [<ffffffff81213edc>] load_elf_binary+0x41c/0xd80
> [ 9448.325576]  [<ffffffff8131d503>] ? ima_get_action+0x23/0x30
> [ 9448.325579]  [<ffffffff8131c7e2>] ? process_measurement+0x82/0x2c0
> [ 9448.325584]  [<ffffffff811c2f7f>] search_binary_handler+0x8f/0x1b0
> [ 9448.325587]  [<ffffffff811c44f7>] do_execve_common.isra.22+0x5a7/0x7e0
> [ 9448.325591]  [<ffffffff811c49c6>] SyS_execve+0x36/0x50
> [ 9448.325596]  [<ffffffff8172cc99>] stub_execve+0x69/0xa0
> [ 9448.325599] ---[ end trace 53ac16782e751c0a ]---
> [ 9448.347994] ------------[ cut here ]------------
> [ 9448.348004] WARNING: CPU: 1 PID: 19902 at
> /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
> ==== more message ignored ====
> 
> 
> I sent emails to the openstack mailing list and they gave me a few
> suggestions. At last, Bob Ball suggested I should probably ask this
> question on xen-devel mailing list. Any help will be highly appreciated!

This looks like the bug already reported by George Dunlap, could you try
to apply the following patch to qemu-xen and recompile?

http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg01112.html

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 10:58:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 10:58:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xos6F-0006O8-4Z; Thu, 13 Nov 2014 10:58:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xos6C-0006O3-MK
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 10:58:00 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	A6/55-27584-8BE84645; Thu, 13 Nov 2014 10:58:00 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415876277!11080217!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25942 invoked from network); 13 Nov 2014 10:57:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 10:57:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190889162"
Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.80)
	with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 05:57:55 -0500
Message-ID: <54648EB3.8040703@citrix.com>
Date: Thu, 13 Nov 2014 11:57:55 +0100
From: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Xing Lin <linxingnku@gmail.com>, <xen-devel@lists.xen.org>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
In-Reply-To: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + 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

El 12/11/14 a les 19.41, Xing Lin ha escrit:
> Hi,
> 
> I am aware that Xen via libvirt is in the group C support for openstack but
> since I am not able to install xenserver iso at compute machines I have, I
> have to consider to use xen with libvirt (xcp-xapi is not available for
> ubuntu14.04). I have three nodes, each one running ubuntu 14.04. I follow
> the instruction to install juno in ubuntu 14.04 and it works (I can create
> instances from openstack GUI - horizon) when I use kvm as the hypervisor at
> the compute node . However, if I switch to use xen as the hypervisor by
> installing xen-hypervisor-amd64 or nova-compute-xen, it will fail to create
> instances. It complained "backend for qemu disk is not ready". I checked
> and did not find qemu process running in dom0. I could not find
> /etc/init.d/xencommons either. Then, I compiled and installed xen-4.4 from
> source code and I got xencommons in /etc/init.d. qemu process is running in
> dom0. However, the dom0 kernel crashes this time when I try to launch an
> instance from openstack GUI. I am able to create a xen guest with
> virt-install from command line, with the following command.
> 
> "$ virt-install --connect=xen:/// --name u14.04.3 --ram 1024 --disk
> u14.04.3.img,size=4,driver_name=qemu --location
> http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/ --network
> bridge=virbr0"
> 
> 
> dmesg:
> 
> [ 9443.130600] blkfront: xvda: flush diskcache: enabled; persistent grants:
> enabled; indirect descriptors: disabled;
> [ 9443.132818]  xvda: xvda1
> [ 9444.604489] xen:grant_table: WARNING: g.e. 0x30 still in use!
> [ 9444.604496] deferring g.e. 0x30 (pfn 0xffffffffffffffff)
> [ 9444.604499] xen:grant_table: WARNING: g.e. 0x31 still in use!
> [ 9444.604502] deferring g.e. 0x31 (pfn 0xffffffffffffffff)
> [ 9444.604505] xen:grant_table: WARNING: g.e. 0x32 still in use!
> [ 9444.604508] deferring g.e. 0x32 (pfn 0xffffffffffffffff)
>   ==== lots of them====
> [ 9444.604719] xen:grant_table: WARNING: g.e. 0xe still in use!
> [ 9444.604721] deferring g.e. 0xe (pfn 0xffffffffffffffff)
> [ 9444.604723] xen:grant_table: WARNING: g.e. 0xd still in use!
> [ 9444.604725] deferring g.e. 0xd (pfn 0xffffffffffffffff)
> [ 9448.325408] ------------[ cut here ]------------
> [ 9448.325421] WARNING: CPU: 5 PID: 19902 at
> /build/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+0x
> 1a9/0x1b0()
> [ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF          O
> 3.13.0-33-generic #58-Ubuntu
> [ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS 2.1.15
> 09/02/2010
> [ 9448.325497]  0000000000000009 ffff8802d13d9aa8 ffffffff8171bd04
> 0000000000000000
> [ 9448.325501]  ffff8802d13d9ae0 ffffffff810676cd 0000000000000000
> 0000000000000001
> [ 9448.325505]  ffff88030418ffe0 ffff88031d6ab180 0000000000000010
> ffff8802d13d9af0
> [ 9448.325509] Call Trace:
> [ 9448.325518]  [<ffffffff8171bd04>] dump_stack+0x45/0x56
> [ 9448.325523]  [<ffffffff810676cd>] warn_slowpath_common+0x7d/0xa0
> [ 9448.325526]  [<ffffffff810677aa>] warn_slowpath_null+0x1a/0x20
> [ 9448.325530]  [<ffffffff81004e99>] xen_mc_flush+0x1a9/0x1b0
> [ 9448.325534]  [<ffffffff81006b99>] xen_set_pud_hyper+0x109/0x110
> [ 9448.325538]  [<ffffffff81006c3b>] xen_set_pud+0x9b/0xb0
> [ 9448.325543]  [<ffffffff81177f06>] __pmd_alloc+0xd6/0x110
> [ 9448.325548]  [<ffffffff81182218>] move_page_tables+0x678/0x720
> [ 9448.325552]  [<ffffffff8117ddb7>] ? vma_adjust+0x337/0x7d0
> [ 9448.325557]  [<ffffffff811c23fd>] shift_arg_pages+0xbd/0x1b0
> [ 9448.325560]  [<ffffffff81181671>] ? mprotect_fixup+0x151/0x290
> [ 9448.325564]  [<ffffffff811c26cb>] setup_arg_pages+0x1db/0x200
> [ 9448.325570]  [<ffffffff81213edc>] load_elf_binary+0x41c/0xd80
> [ 9448.325576]  [<ffffffff8131d503>] ? ima_get_action+0x23/0x30
> [ 9448.325579]  [<ffffffff8131c7e2>] ? process_measurement+0x82/0x2c0
> [ 9448.325584]  [<ffffffff811c2f7f>] search_binary_handler+0x8f/0x1b0
> [ 9448.325587]  [<ffffffff811c44f7>] do_execve_common.isra.22+0x5a7/0x7e0
> [ 9448.325591]  [<ffffffff811c49c6>] SyS_execve+0x36/0x50
> [ 9448.325596]  [<ffffffff8172cc99>] stub_execve+0x69/0xa0
> [ 9448.325599] ---[ end trace 53ac16782e751c0a ]---
> [ 9448.347994] ------------[ cut here ]------------
> [ 9448.348004] WARNING: CPU: 1 PID: 19902 at
> /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
> ==== more message ignored ====
> 
> 
> I sent emails to the openstack mailing list and they gave me a few
> suggestions. At last, Bob Ball suggested I should probably ask this
> question on xen-devel mailing list. Any help will be highly appreciated!

This looks like the bug already reported by George Dunlap, could you try
to apply the following patch to qemu-xen and recompile?

http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg01112.html

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:16:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XosNU-0006tJ-PX; Thu, 13 Nov 2014 11:15:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XosNT-0006tE-Mh
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 11:15:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	07/A2-09842-6E294645; Thu, 13 Nov 2014 11:15:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415877348!12413606!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21031 invoked from network); 13 Nov 2014 11:15:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 11:15:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190894203"
Message-ID: <1415877346.21321.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Thu, 13 Nov 2014 11:15:46 +0000
In-Reply-To: <1415866345.31613.22.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<1415866345.31613.22.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 08:12 +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 11:41 -0700, Xing Lin wrote:
> 
> > 
> > [ 9448.347994] ------------[ cut here ]------------
> > [ 9448.348004] WARNING: CPU: 1 PID: 19902 at /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
> > ==== more message ignored ====
> 
> The most interesting bits of the message are likely to be the lines
> which follow here, i.e. the kernel stack trace and associated info.
> Please can you paste the complete log from "cut here" until the end.

Sorry, it seems my eye somehow jumped from the "g.e. 0x30 still in use!"
bits to the end, missing the stack trace right there in front of me.
Looks like others on the thread are more on the ball and pointing in the
right directions.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:16:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XosNU-0006tJ-PX; Thu, 13 Nov 2014 11:15:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XosNT-0006tE-Mh
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 11:15:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	07/A2-09842-6E294645; Thu, 13 Nov 2014 11:15:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415877348!12413606!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21031 invoked from network); 13 Nov 2014 11:15:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 11:15:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190894203"
Message-ID: <1415877346.21321.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Thu, 13 Nov 2014 11:15:46 +0000
In-Reply-To: <1415866345.31613.22.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<1415866345.31613.22.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 08:12 +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 11:41 -0700, Xing Lin wrote:
> 
> > 
> > [ 9448.347994] ------------[ cut here ]------------
> > [ 9448.348004] WARNING: CPU: 1 PID: 19902 at /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
> > ==== more message ignored ====
> 
> The most interesting bits of the message are likely to be the lines
> which follow here, i.e. the kernel stack trace and associated info.
> Please can you paste the complete log from "cut here" until the end.

Sorry, it seems my eye somehow jumped from the "g.e. 0x30 still in use!"
bits to the end, missing the stack trace right there in front of me.
Looks like others on the thread are more on the ball and pointing in the
right directions.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:22:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XosU1-0007Bt-1M; Thu, 13 Nov 2014 11:22:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XosTy-0007Bo-SI
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 11:22:35 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	9E/29-25714-A7494645; Thu, 13 Nov 2014 11:22:34 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415877752!11118744!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30569 invoked from network); 13 Nov 2014 11:22:33 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-13.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Nov 2014 11:22:33 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XosTv-0008TE-4m; Thu, 13 Nov 2014 11:22:31 +0000
Message-ID: <54649465.1000602@canonical.com>
Date: Thu, 13 Nov 2014 12:22:13 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>, 
	Xing Lin <linxingnku@gmail.com>, xen-devel@lists.xen.org
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
In-Reply-To: <54648EB3.8040703@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8836762691069815141=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============8836762691069815141==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="2dDtdwXFtV8wnLWqnQJ9XHjTJHbbWxA2A"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2dDtdwXFtV8wnLWqnQJ9XHjTJHbbWxA2A
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 13.11.2014 11:57, Roger Pau Monn=E9 wrote:
> El 12/11/14 a les 19.41, Xing Lin ha escrit:
>> Hi,
>>
>> I am aware that Xen via libvirt is in the group C support for openstac=
k but
>> since I am not able to install xenserver iso at compute machines I hav=
e, I
>> have to consider to use xen with libvirt (xcp-xapi is not available fo=
r
>> ubuntu14.04). I have three nodes, each one running ubuntu 14.04. I fol=
low
>> the instruction to install juno in ubuntu 14.04 and it works (I can cr=
eate
>> instances from openstack GUI - horizon) when I use kvm as the hypervis=
or at
>> the compute node . However, if I switch to use xen as the hypervisor b=
y
>> installing xen-hypervisor-amd64 or nova-compute-xen, it will fail to c=
reate
>> instances. It complained "backend for qemu disk is not ready". I check=
ed
>> and did not find qemu process running in dom0. I could not find
>> /etc/init.d/xencommons either. Then, I compiled and installed xen-4.4 =
from
>> source code and I got xencommons in /etc/init.d. qemu process is runni=
ng in
>> dom0. However, the dom0 kernel crashes this time when I try to launch =
an
>> instance from openstack GUI. I am able to create a xen guest with
>> virt-install from command line, with the following command.
>>
>> "$ virt-install --connect=3Dxen:/// --name u14.04.3 --ram 1024 --disk
>> u14.04.3.img,size=3D4,driver_name=3Dqemu --location
>> http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/ --netw=
ork
>> bridge=3Dvirbr0"
>>
>>
>> dmesg:
>>
>> [ 9443.130600] blkfront: xvda: flush diskcache: enabled; persistent gr=
ants:
>> enabled; indirect descriptors: disabled;
>> [ 9443.132818]  xvda: xvda1
>> [ 9444.604489] xen:grant_table: WARNING: g.e. 0x30 still in use!
>> [ 9444.604496] deferring g.e. 0x30 (pfn 0xffffffffffffffff)
>> [ 9444.604499] xen:grant_table: WARNING: g.e. 0x31 still in use!
>> [ 9444.604502] deferring g.e. 0x31 (pfn 0xffffffffffffffff)
>> [ 9444.604505] xen:grant_table: WARNING: g.e. 0x32 still in use!
>> [ 9444.604508] deferring g.e. 0x32 (pfn 0xffffffffffffffff)
>>   =3D=3D=3D=3D lots of them=3D=3D=3D=3D
>> [ 9444.604719] xen:grant_table: WARNING: g.e. 0xe still in use!
>> [ 9444.604721] deferring g.e. 0xe (pfn 0xffffffffffffffff)
>> [ 9444.604723] xen:grant_table: WARNING: g.e. 0xd still in use!
>> [ 9444.604725] deferring g.e. 0xd (pfn 0xffffffffffffffff)
>> [ 9448.325408] ------------[ cut here ]------------
>> [ 9448.325421] WARNING: CPU: 5 PID: 19902 at
>> /build/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+=
0x
>> 1a9/0x1b0()
>> [ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF          O
>> 3.13.0-33-generic #58-Ubuntu
>> [ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS 2.=
1.15
>> 09/02/2010
>> [ 9448.325497]  0000000000000009 ffff8802d13d9aa8 ffffffff8171bd04
>> 0000000000000000
>> [ 9448.325501]  ffff8802d13d9ae0 ffffffff810676cd 0000000000000000
>> 0000000000000001
>> [ 9448.325505]  ffff88030418ffe0 ffff88031d6ab180 0000000000000010
>> ffff8802d13d9af0
>> [ 9448.325509] Call Trace:
>> [ 9448.325518]  [<ffffffff8171bd04>] dump_stack+0x45/0x56
>> [ 9448.325523]  [<ffffffff810676cd>] warn_slowpath_common+0x7d/0xa0
>> [ 9448.325526]  [<ffffffff810677aa>] warn_slowpath_null+0x1a/0x20
>> [ 9448.325530]  [<ffffffff81004e99>] xen_mc_flush+0x1a9/0x1b0
>> [ 9448.325534]  [<ffffffff81006b99>] xen_set_pud_hyper+0x109/0x110
>> [ 9448.325538]  [<ffffffff81006c3b>] xen_set_pud+0x9b/0xb0
>> [ 9448.325543]  [<ffffffff81177f06>] __pmd_alloc+0xd6/0x110
>> [ 9448.325548]  [<ffffffff81182218>] move_page_tables+0x678/0x720
>> [ 9448.325552]  [<ffffffff8117ddb7>] ? vma_adjust+0x337/0x7d0
>> [ 9448.325557]  [<ffffffff811c23fd>] shift_arg_pages+0xbd/0x1b0
>> [ 9448.325560]  [<ffffffff81181671>] ? mprotect_fixup+0x151/0x290
>> [ 9448.325564]  [<ffffffff811c26cb>] setup_arg_pages+0x1db/0x200
>> [ 9448.325570]  [<ffffffff81213edc>] load_elf_binary+0x41c/0xd80
>> [ 9448.325576]  [<ffffffff8131d503>] ? ima_get_action+0x23/0x30
>> [ 9448.325579]  [<ffffffff8131c7e2>] ? process_measurement+0x82/0x2c0
>> [ 9448.325584]  [<ffffffff811c2f7f>] search_binary_handler+0x8f/0x1b0
>> [ 9448.325587]  [<ffffffff811c44f7>] do_execve_common.isra.22+0x5a7/0x=
7e0
>> [ 9448.325591]  [<ffffffff811c49c6>] SyS_execve+0x36/0x50
>> [ 9448.325596]  [<ffffffff8172cc99>] stub_execve+0x69/0xa0
>> [ 9448.325599] ---[ end trace 53ac16782e751c0a ]---
>> [ 9448.347994] ------------[ cut here ]------------
>> [ 9448.348004] WARNING: CPU: 1 PID: 19902 at
>> /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
>> =3D=3D=3D=3D more message ignored =3D=3D=3D=3D
>>
>>
>> I sent emails to the openstack mailing list and they gave me a few
>> suggestions. At last, Bob Ball suggested I should probably ask this
>> question on xen-devel mailing list. Any help will be highly appreciate=
d!
>=20
> This looks like the bug already reported by George Dunlap, could you tr=
y
> to apply the following patch to qemu-xen and recompile?
>=20
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg01112.ht=
ml

If that turns out to be the problem we need to get a bug reported against=
 the
qemu package as the distro packaged Xen uses stock qemu with xl.

-Stefan

>=20
> Roger.
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--2dDtdwXFtV8wnLWqnQJ9XHjTJHbbWxA2A
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

iQIcBAEBCgAGBQJUZJR2AAoJEOhnXe7L7s6jv5AQANtXtcEBcVbol/9PMupYI17v
VmkF3iLCQIoiinozd9MUiukZ6/Iu+AJ5z92AAMHYz88XwprmqQr0Vpqj8q7byALV
NGaReEj8YEoIqs78O0Amc4nRxdHfD7FcJTkV9NqmchknTk1mj/UrznoMF1sd4Fi2
S9P/66HlPDREJavVbcfYG2LzGFOrmpkNIPVeANymZZo/T7iOIiWseZ78IE82cubW
QN0K25ZhrHCM9DzSg8NMKDl19WSZ6Hd+UnsdD7HYytv/XKrRTQwOlkfX17NMyi4/
Y5fPDfDHQh64/1opIN2kfD/eJ81VxgwQZFW5Vu6Fm9vsMMltbImjHkSobSfvUCQ/
X/ps/wVbwg9S3O0qhupFvU/qL2YSqTi/y6meDTp8yAUJeDySJm4ailsyKLRp7Jm6
RDGUYNEusKCze7db+cdNDshhEE6kcRoKm8M2zSKgD22sb2ClA5KcQPqqAjFQlcSl
yIKQgPrFt4lEb49nYHW0HbsXpOUrEVzzWds/oNHK5sa8baJOSPt+Bk6jKSdxT6sK
yqrqZ6Kd2AEt7BgcxPFDactevlTjt2wXT4OZupg4FABaHNK9G6t5pIj/6rJ3PCjf
y+Vr63eYxSxalubp/0UBdJ/MBYbPWxFamjgJGCSQK7dhus71dg6LVTTvWt890jzI
m7P6N1wa1LHtb6cBb1Xi
=UGmw
-----END PGP SIGNATURE-----

--2dDtdwXFtV8wnLWqnQJ9XHjTJHbbWxA2A--


--===============8836762691069815141==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8836762691069815141==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 11:22:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XosU1-0007Bt-1M; Thu, 13 Nov 2014 11:22:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XosTy-0007Bo-SI
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 11:22:35 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	9E/29-25714-A7494645; Thu, 13 Nov 2014 11:22:34 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415877752!11118744!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30569 invoked from network); 13 Nov 2014 11:22:33 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-13.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Nov 2014 11:22:33 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XosTv-0008TE-4m; Thu, 13 Nov 2014 11:22:31 +0000
Message-ID: <54649465.1000602@canonical.com>
Date: Thu, 13 Nov 2014 12:22:13 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>, 
	Xing Lin <linxingnku@gmail.com>, xen-devel@lists.xen.org
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
In-Reply-To: <54648EB3.8040703@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8836762691069815141=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============8836762691069815141==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="2dDtdwXFtV8wnLWqnQJ9XHjTJHbbWxA2A"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2dDtdwXFtV8wnLWqnQJ9XHjTJHbbWxA2A
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 13.11.2014 11:57, Roger Pau Monn=E9 wrote:
> El 12/11/14 a les 19.41, Xing Lin ha escrit:
>> Hi,
>>
>> I am aware that Xen via libvirt is in the group C support for openstac=
k but
>> since I am not able to install xenserver iso at compute machines I hav=
e, I
>> have to consider to use xen with libvirt (xcp-xapi is not available fo=
r
>> ubuntu14.04). I have three nodes, each one running ubuntu 14.04. I fol=
low
>> the instruction to install juno in ubuntu 14.04 and it works (I can cr=
eate
>> instances from openstack GUI - horizon) when I use kvm as the hypervis=
or at
>> the compute node . However, if I switch to use xen as the hypervisor b=
y
>> installing xen-hypervisor-amd64 or nova-compute-xen, it will fail to c=
reate
>> instances. It complained "backend for qemu disk is not ready". I check=
ed
>> and did not find qemu process running in dom0. I could not find
>> /etc/init.d/xencommons either. Then, I compiled and installed xen-4.4 =
from
>> source code and I got xencommons in /etc/init.d. qemu process is runni=
ng in
>> dom0. However, the dom0 kernel crashes this time when I try to launch =
an
>> instance from openstack GUI. I am able to create a xen guest with
>> virt-install from command line, with the following command.
>>
>> "$ virt-install --connect=3Dxen:/// --name u14.04.3 --ram 1024 --disk
>> u14.04.3.img,size=3D4,driver_name=3Dqemu --location
>> http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/ --netw=
ork
>> bridge=3Dvirbr0"
>>
>>
>> dmesg:
>>
>> [ 9443.130600] blkfront: xvda: flush diskcache: enabled; persistent gr=
ants:
>> enabled; indirect descriptors: disabled;
>> [ 9443.132818]  xvda: xvda1
>> [ 9444.604489] xen:grant_table: WARNING: g.e. 0x30 still in use!
>> [ 9444.604496] deferring g.e. 0x30 (pfn 0xffffffffffffffff)
>> [ 9444.604499] xen:grant_table: WARNING: g.e. 0x31 still in use!
>> [ 9444.604502] deferring g.e. 0x31 (pfn 0xffffffffffffffff)
>> [ 9444.604505] xen:grant_table: WARNING: g.e. 0x32 still in use!
>> [ 9444.604508] deferring g.e. 0x32 (pfn 0xffffffffffffffff)
>>   =3D=3D=3D=3D lots of them=3D=3D=3D=3D
>> [ 9444.604719] xen:grant_table: WARNING: g.e. 0xe still in use!
>> [ 9444.604721] deferring g.e. 0xe (pfn 0xffffffffffffffff)
>> [ 9444.604723] xen:grant_table: WARNING: g.e. 0xd still in use!
>> [ 9444.604725] deferring g.e. 0xd (pfn 0xffffffffffffffff)
>> [ 9448.325408] ------------[ cut here ]------------
>> [ 9448.325421] WARNING: CPU: 5 PID: 19902 at
>> /build/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+=
0x
>> 1a9/0x1b0()
>> [ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF          O
>> 3.13.0-33-generic #58-Ubuntu
>> [ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS 2.=
1.15
>> 09/02/2010
>> [ 9448.325497]  0000000000000009 ffff8802d13d9aa8 ffffffff8171bd04
>> 0000000000000000
>> [ 9448.325501]  ffff8802d13d9ae0 ffffffff810676cd 0000000000000000
>> 0000000000000001
>> [ 9448.325505]  ffff88030418ffe0 ffff88031d6ab180 0000000000000010
>> ffff8802d13d9af0
>> [ 9448.325509] Call Trace:
>> [ 9448.325518]  [<ffffffff8171bd04>] dump_stack+0x45/0x56
>> [ 9448.325523]  [<ffffffff810676cd>] warn_slowpath_common+0x7d/0xa0
>> [ 9448.325526]  [<ffffffff810677aa>] warn_slowpath_null+0x1a/0x20
>> [ 9448.325530]  [<ffffffff81004e99>] xen_mc_flush+0x1a9/0x1b0
>> [ 9448.325534]  [<ffffffff81006b99>] xen_set_pud_hyper+0x109/0x110
>> [ 9448.325538]  [<ffffffff81006c3b>] xen_set_pud+0x9b/0xb0
>> [ 9448.325543]  [<ffffffff81177f06>] __pmd_alloc+0xd6/0x110
>> [ 9448.325548]  [<ffffffff81182218>] move_page_tables+0x678/0x720
>> [ 9448.325552]  [<ffffffff8117ddb7>] ? vma_adjust+0x337/0x7d0
>> [ 9448.325557]  [<ffffffff811c23fd>] shift_arg_pages+0xbd/0x1b0
>> [ 9448.325560]  [<ffffffff81181671>] ? mprotect_fixup+0x151/0x290
>> [ 9448.325564]  [<ffffffff811c26cb>] setup_arg_pages+0x1db/0x200
>> [ 9448.325570]  [<ffffffff81213edc>] load_elf_binary+0x41c/0xd80
>> [ 9448.325576]  [<ffffffff8131d503>] ? ima_get_action+0x23/0x30
>> [ 9448.325579]  [<ffffffff8131c7e2>] ? process_measurement+0x82/0x2c0
>> [ 9448.325584]  [<ffffffff811c2f7f>] search_binary_handler+0x8f/0x1b0
>> [ 9448.325587]  [<ffffffff811c44f7>] do_execve_common.isra.22+0x5a7/0x=
7e0
>> [ 9448.325591]  [<ffffffff811c49c6>] SyS_execve+0x36/0x50
>> [ 9448.325596]  [<ffffffff8172cc99>] stub_execve+0x69/0xa0
>> [ 9448.325599] ---[ end trace 53ac16782e751c0a ]---
>> [ 9448.347994] ------------[ cut here ]------------
>> [ 9448.348004] WARNING: CPU: 1 PID: 19902 at
>> /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
>> =3D=3D=3D=3D more message ignored =3D=3D=3D=3D
>>
>>
>> I sent emails to the openstack mailing list and they gave me a few
>> suggestions. At last, Bob Ball suggested I should probably ask this
>> question on xen-devel mailing list. Any help will be highly appreciate=
d!
>=20
> This looks like the bug already reported by George Dunlap, could you tr=
y
> to apply the following patch to qemu-xen and recompile?
>=20
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg01112.ht=
ml

If that turns out to be the problem we need to get a bug reported against=
 the
qemu package as the distro packaged Xen uses stock qemu with xl.

-Stefan

>=20
> Roger.
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--2dDtdwXFtV8wnLWqnQJ9XHjTJHbbWxA2A
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

iQIcBAEBCgAGBQJUZJR2AAoJEOhnXe7L7s6jv5AQANtXtcEBcVbol/9PMupYI17v
VmkF3iLCQIoiinozd9MUiukZ6/Iu+AJ5z92AAMHYz88XwprmqQr0Vpqj8q7byALV
NGaReEj8YEoIqs78O0Amc4nRxdHfD7FcJTkV9NqmchknTk1mj/UrznoMF1sd4Fi2
S9P/66HlPDREJavVbcfYG2LzGFOrmpkNIPVeANymZZo/T7iOIiWseZ78IE82cubW
QN0K25ZhrHCM9DzSg8NMKDl19WSZ6Hd+UnsdD7HYytv/XKrRTQwOlkfX17NMyi4/
Y5fPDfDHQh64/1opIN2kfD/eJ81VxgwQZFW5Vu6Fm9vsMMltbImjHkSobSfvUCQ/
X/ps/wVbwg9S3O0qhupFvU/qL2YSqTi/y6meDTp8yAUJeDySJm4ailsyKLRp7Jm6
RDGUYNEusKCze7db+cdNDshhEE6kcRoKm8M2zSKgD22sb2ClA5KcQPqqAjFQlcSl
yIKQgPrFt4lEb49nYHW0HbsXpOUrEVzzWds/oNHK5sa8baJOSPt+Bk6jKSdxT6sK
yqrqZ6Kd2AEt7BgcxPFDactevlTjt2wXT4OZupg4FABaHNK9G6t5pIj/6rJ3PCjf
y+Vr63eYxSxalubp/0UBdJ/MBYbPWxFamjgJGCSQK7dhus71dg6LVTTvWt890jzI
m7P6N1wa1LHtb6cBb1Xi
=UGmw
-----END PGP SIGNATURE-----

--2dDtdwXFtV8wnLWqnQJ9XHjTJHbbWxA2A--


--===============8836762691069815141==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8836762691069815141==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 11:22:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XosUD-0007E1-J7; Thu, 13 Nov 2014 11:22:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XosUC-0007Dn-FZ
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 11:22:48 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	2E/A3-26740-78494645; Thu, 13 Nov 2014 11:22:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415877765!11051057!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29983 invoked from network); 13 Nov 2014 11:22:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 11:22:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="192347729"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 06:22:44 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XosU8-0006Kb-GF;
	Thu, 13 Nov 2014 11:22:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XosU7-0005zn-Ep;
	Thu, 13 Nov 2014 11:22:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21604.38018.698955.355136@mariner.uk.xensource.com>
Date: Thu, 13 Nov 2014 11:22:42 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
In-Reply-To: <osstest-31509-mainreport@xen.org>
References: <osstest-31509-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Subject: Re: [Xen-devel] [rumpuserxen test] 31509: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("[rumpuserxen test] 31509: regressions - FAIL"):
> flight 31509 rumpuserxen real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31509/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

This is weird.

--- /home/xc_osstest/logs/31509/test-amd64-amd64-rumpuserxen-amd64/xenstore-ls-device--xenstorels--ours-massaged        2014-11-12 21:52:04.000000000 +0000
+++ /home/xc_osstest/logs/31509/test-amd64-amd64-rumpuserxen-amd64/xenstore-ls-device--xenstorels--theirs-massaged      2014-11-12 21:52:04.000000000 +0000
@@ -15,3 +15,10 @@
 device/vbd/832/protocol = "x86_64-abi"   (n2,r0)
 device/vbd/832/state = "1"   (n2,r0)
 device/vbd/832/virtual-device = "832"   (n2,r0)
+device/vif = ""   (n0,r2)
+device/vif/0 = ""   (n2,r0)
+device/vif/0/backend = "/local/domain/0/backend/vif/2/0"   (n2,r0)
+device/vif/0/backend-id = "0"   (n2,r0)
+device/vif/0/handle = "0"   (n2,r0)
+device/vif/0/mac = "5a:36:0e:15:00:04"   (n2,r0)
+device/vif/0/state = "1"   (n2,r0)
256 COMPARISON FAILED at ./ts-rumpuserxen-demo-xenstorels line 104.

I think this may be a change in xen.git rather than rumpuser-xen, or a
problem with the tests.  I'm going to wait for the osstest bisector to
report.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:22:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XosUD-0007E1-J7; Thu, 13 Nov 2014 11:22:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XosUC-0007Dn-FZ
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 11:22:48 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	2E/A3-26740-78494645; Thu, 13 Nov 2014 11:22:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415877765!11051057!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29983 invoked from network); 13 Nov 2014 11:22:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 11:22:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="192347729"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 06:22:44 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XosU8-0006Kb-GF;
	Thu, 13 Nov 2014 11:22:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XosU7-0005zn-Ep;
	Thu, 13 Nov 2014 11:22:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21604.38018.698955.355136@mariner.uk.xensource.com>
Date: Thu, 13 Nov 2014 11:22:42 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
In-Reply-To: <osstest-31509-mainreport@xen.org>
References: <osstest-31509-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Subject: Re: [Xen-devel] [rumpuserxen test] 31509: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("[rumpuserxen test] 31509: regressions - FAIL"):
> flight 31509 rumpuserxen real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31509/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

This is weird.

--- /home/xc_osstest/logs/31509/test-amd64-amd64-rumpuserxen-amd64/xenstore-ls-device--xenstorels--ours-massaged        2014-11-12 21:52:04.000000000 +0000
+++ /home/xc_osstest/logs/31509/test-amd64-amd64-rumpuserxen-amd64/xenstore-ls-device--xenstorels--theirs-massaged      2014-11-12 21:52:04.000000000 +0000
@@ -15,3 +15,10 @@
 device/vbd/832/protocol = "x86_64-abi"   (n2,r0)
 device/vbd/832/state = "1"   (n2,r0)
 device/vbd/832/virtual-device = "832"   (n2,r0)
+device/vif = ""   (n0,r2)
+device/vif/0 = ""   (n2,r0)
+device/vif/0/backend = "/local/domain/0/backend/vif/2/0"   (n2,r0)
+device/vif/0/backend-id = "0"   (n2,r0)
+device/vif/0/handle = "0"   (n2,r0)
+device/vif/0/mac = "5a:36:0e:15:00:04"   (n2,r0)
+device/vif/0/state = "1"   (n2,r0)
256 COMPARISON FAILED at ./ts-rumpuserxen-demo-xenstorels line 104.

I think this may be a change in xen.git rather than rumpuser-xen, or a
problem with the tests.  I'm going to wait for the osstest bisector to
report.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:37:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoshm-0007eh-Jy; Thu, 13 Nov 2014 11:36:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <martin@lucina.net>) id 1XosTG-000744-TR
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 11:21:51 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	29/ED-26858-D4494645; Thu, 13 Nov 2014 11:21:49 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415877708!11050696!1
X-Originating-IP: [62.176.169.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21466 invoked from network); 13 Nov 2014 11:21:48 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 11:21:48 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id ECCBE18057BA;
	Thu, 13 Nov 2014 12:21:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1415877708;
	bh=rhiMG4romDcah9FOmbWPJlF3NFN6zkzGG9TcJoC84Vg=;
	h=Date:From:To:Cc:Subject:From;
	b=DX6esFiAl8efDAAsMfXk6QvtJX5GtNbPoLWRoPGyC+KTJJ3T9f3O+frus2GEAJEpn
	r3gc+JCG3mdAtFnVSkfDefHi8SxrcpSxFAkN797Iyo0H4xi9iXZegVGrxppR9pfF9v
	yvZKWf4TuIUACWEH5oxkGk91gPFSQPmzV1w/bUiW/n6Pj8XiPDbpTsMe68YuAHySaq
	zPjmCkZuF/oE4cfsx6v9miSbGPx8O3s1Bp0dHKw024vGzjPY0+1IkYNQrS0H4XUfXt
	czaZEXVYREKkni3/B+TOSVW7pWSJpoY7oAcIu+xsSeKPF5u6Rp3nucPUBBInIXK2Rb
	WJIXJNEf0vQgQ==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id 1C2884C0E2D; Thu, 13 Nov 2014 12:22:03 +0100 (CET)
Date: Thu, 13 Nov 2014 12:22:03 +0100
From: Martin Lucina <martin@lucina.net>
To: rumpkernel-users@lists.sourceforge.net
Message-ID: <20141113112202.GB7853@nodbug.moloch.sk>
Mail-Followup-To: rumpkernel-users@lists.sourceforge.net,
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 13 Nov 2014 11:36:49 +0000
Cc: xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] RFC: Configuring rumprun-xen application stacks from
	Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(Cc-ing xen-devel as this is relevant to general use of
"application-specific" domains, MirageOS, etc.)

Hi,

back in July there was some discussion on configuring rump kernel
application stacks:
http://thread.gmane.org/gmane.comp.rumpkernel.user/321

Some proposals were made, but no actual implementation work was done. In
the mean time, I have implemented the simplest possible mechanism I could
think of for rumprun-xen, using Xenstore.

The patches are available for review as PR #12:
https://github.com/rumpkernel/rumprun-xen/pull/12

Following is the high-level description from the Git commit:

In order to run rumprun-xen applications that are actually useful, we
need to be able to configure block devices and network interfaces.
These changes implement a basic mechanism to do this using Xenstore.

Conceptually the changes consist of the following parts which work
together:

  - The rumpconfig module provides _rumprun_config() and
    _rumprun_deconfig() functions. These are called before and after the
    application main() function, and also in the case of deconfig when
    _exit() is called.

  - These functions rely on keys like the following being present in
    Xenstore at the time the domain is started:

    /local/domain/<domid>/rumprun/net/0/... (first network interface)
    /local/domain/<domid>/rumprun/net/1/... (second network interface)
    /local/domain/<domid>/rumprun/blk/0/... (first block device)
    /local/domain/<domid>/rumprun/blk/1/... (second block device)

  - The "xr" driver script, currently located in app-tools/. The
    motivation for this script is twofold:

    Firstly, in order to write the configuration to Xenstore the domain
    must be created in a paused state so that we can retrieve its unique
    . Only then do we know where in Xenstore to write the
    configuration data.

    Secondly, it is my intention with this work to provide a
    "docker-alike" interface for running rumprun applications. The "xr"
    script is therefore the CLI for running such applications.

Note that in this initial version, only configuring IPv4 network
interfaces with DHCP is supported, and only using image files with ffs
or cd9660 filesystems for block devices is supported.

Xen people: I'm especially interested in whether or not this is a valid use
of Xenstore.

Further: I originally wanted to just add the rumprun/* keys to the
(generated) domain configuration file, but it turns out that xl does not
allow adding arbitrary keys or at least they don't show up in Xenstore for
the domain.  Hence the "two-step" approach with first creating the paused
domain, then writing the keys to Xenstore and starting the domain.

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:37:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoshm-0007eh-Jy; Thu, 13 Nov 2014 11:36:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <martin@lucina.net>) id 1XosTG-000744-TR
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 11:21:51 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	29/ED-26858-D4494645; Thu, 13 Nov 2014 11:21:49 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415877708!11050696!1
X-Originating-IP: [62.176.169.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21466 invoked from network); 13 Nov 2014 11:21:48 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 11:21:48 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id ECCBE18057BA;
	Thu, 13 Nov 2014 12:21:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1415877708;
	bh=rhiMG4romDcah9FOmbWPJlF3NFN6zkzGG9TcJoC84Vg=;
	h=Date:From:To:Cc:Subject:From;
	b=DX6esFiAl8efDAAsMfXk6QvtJX5GtNbPoLWRoPGyC+KTJJ3T9f3O+frus2GEAJEpn
	r3gc+JCG3mdAtFnVSkfDefHi8SxrcpSxFAkN797Iyo0H4xi9iXZegVGrxppR9pfF9v
	yvZKWf4TuIUACWEH5oxkGk91gPFSQPmzV1w/bUiW/n6Pj8XiPDbpTsMe68YuAHySaq
	zPjmCkZuF/oE4cfsx6v9miSbGPx8O3s1Bp0dHKw024vGzjPY0+1IkYNQrS0H4XUfXt
	czaZEXVYREKkni3/B+TOSVW7pWSJpoY7oAcIu+xsSeKPF5u6Rp3nucPUBBInIXK2Rb
	WJIXJNEf0vQgQ==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id 1C2884C0E2D; Thu, 13 Nov 2014 12:22:03 +0100 (CET)
Date: Thu, 13 Nov 2014 12:22:03 +0100
From: Martin Lucina <martin@lucina.net>
To: rumpkernel-users@lists.sourceforge.net
Message-ID: <20141113112202.GB7853@nodbug.moloch.sk>
Mail-Followup-To: rumpkernel-users@lists.sourceforge.net,
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 13 Nov 2014 11:36:49 +0000
Cc: xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] RFC: Configuring rumprun-xen application stacks from
	Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(Cc-ing xen-devel as this is relevant to general use of
"application-specific" domains, MirageOS, etc.)

Hi,

back in July there was some discussion on configuring rump kernel
application stacks:
http://thread.gmane.org/gmane.comp.rumpkernel.user/321

Some proposals were made, but no actual implementation work was done. In
the mean time, I have implemented the simplest possible mechanism I could
think of for rumprun-xen, using Xenstore.

The patches are available for review as PR #12:
https://github.com/rumpkernel/rumprun-xen/pull/12

Following is the high-level description from the Git commit:

In order to run rumprun-xen applications that are actually useful, we
need to be able to configure block devices and network interfaces.
These changes implement a basic mechanism to do this using Xenstore.

Conceptually the changes consist of the following parts which work
together:

  - The rumpconfig module provides _rumprun_config() and
    _rumprun_deconfig() functions. These are called before and after the
    application main() function, and also in the case of deconfig when
    _exit() is called.

  - These functions rely on keys like the following being present in
    Xenstore at the time the domain is started:

    /local/domain/<domid>/rumprun/net/0/... (first network interface)
    /local/domain/<domid>/rumprun/net/1/... (second network interface)
    /local/domain/<domid>/rumprun/blk/0/... (first block device)
    /local/domain/<domid>/rumprun/blk/1/... (second block device)

  - The "xr" driver script, currently located in app-tools/. The
    motivation for this script is twofold:

    Firstly, in order to write the configuration to Xenstore the domain
    must be created in a paused state so that we can retrieve its unique
    . Only then do we know where in Xenstore to write the
    configuration data.

    Secondly, it is my intention with this work to provide a
    "docker-alike" interface for running rumprun applications. The "xr"
    script is therefore the CLI for running such applications.

Note that in this initial version, only configuring IPv4 network
interfaces with DHCP is supported, and only using image files with ffs
or cd9660 filesystems for block devices is supported.

Xen people: I'm especially interested in whether or not this is a valid use
of Xenstore.

Further: I originally wanted to just add the rumprun/* keys to the
(generated) domain configuration file, but it turns out that xl does not
allow adding arbitrary keys or at least they don't show up in Xenstore for
the domain.  Hence the "two-step" approach with first creating the paused
domain, then writing the keys to Xenstore and starting the domain.

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoslw-0007n3-Lq; Thu, 13 Nov 2014 11:41:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xoslv-0007ms-J1
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 11:41:07 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	CA/33-02698-2D894645; Thu, 13 Nov 2014 11:41:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415878865!12287951!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19271 invoked from network); 13 Nov 2014 11:41:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 11:41:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="192351934"
Message-ID: <1415878862.21321.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Thu, 13 Nov 2014 11:41:02 +0000
In-Reply-To: <546490D40200006600079701@soto.provo.novell.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
	<5462343C020000660007880A@soto.provo.novell.com>
	<546490D40200006600079701@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@citrix.com>, George Dunlap <dunlapg@umich.edu>,
	Wei Liu <wei.liu2@citrix.com>, Jim Fehlig <JFEHLIG@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 20:07 -0700, Chun Yan Liu wrote:
> > > By "active" here, do you you mean "live" (vs paused)? 
> > Means the domain is started (no matter is running or paused). 
> > vs (libvirt defines a domain but not started). 
> > Here,  I should update this to: 
> > 3). take disk snapshot by qmp command 
> > libxl only handles active domain. 

I think the problem here is that different components in the system use
different terminology for things or even different concepts (e.g. libxl
has no inherent concept of inactive vs active domains, because it only
concerns itself with active domains).

Perhaps a glossary defining these things would help (also see below).

> > > >    libxl_domain_snapshot_delete:  
> > > >        1). check args validation  
> > > >        2). remove memory state file.  
> > > >        3). delete disk snapshot. (for internal disk snapshot, through qmp  
> > > >            command or qemu-img command)  
> > >   
> > > Out of curiosity, why is this necessary?  Is libxl keeping track of  
> > > the snapshots somewhere?  Or qemu?  
> > >   
> > > Or to put it a different way, since the caller knows the filenames,  
> > > why can't the caller just erase the files themselves? 
> >  
> > Ian asks the same question. The only reason I propose an API is: 
> > xl and libvirt can share the code. And in future, when support many other  
> > disk 
> > backend types, there is much repeated code. But as Ian mentioned in 
> > last version, for handling many disk backend types, maybe better placed in 
> > libxlu. Well, if both of you object, I'll remove this API. 

I think the reason we are having these same discussions over again is
that this proposal is focusing on the libxl API (e.g. the details of
what functions exist and what parameters they take) without an
introductory section which provides a broad overview of the
architecture, containing e.g. things like:

      * What the general requirements for domain snapshotting are;
      * What are the constraints which we are operating under; e.g.
        libvirt or xl design requirements
      * What the various components are (and which, possibly multiple,
        entities provide them) and where the various responsibilities
        lie.

I think we've teased a lot of this sort of thing out in past iterations
but without having it written down here I think we are all having
trouble agreeing (or remembering that we've agreed) that the API makes
sense because we all have different ideas about what the higher level
architecture/abstraction should look like.

See for example
http://xenbits.xen.org/people/dvrabel/event-channels-H.pdf or
http://lists.xen.org/archives/html/xen-devel/2014-10/msg03235.html (you
don't necessarily need to go all out on that level of formality, but
they provide some examples of the sorts of higher level design I'm
talking about)

I think it would also help with the glossary question above since it
would help define the terms.

I'm sorry for not observing this sooner.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoslw-0007n3-Lq; Thu, 13 Nov 2014 11:41:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xoslv-0007ms-J1
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 11:41:07 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	CA/33-02698-2D894645; Thu, 13 Nov 2014 11:41:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415878865!12287951!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19271 invoked from network); 13 Nov 2014 11:41:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 11:41:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="192351934"
Message-ID: <1415878862.21321.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Thu, 13 Nov 2014 11:41:02 +0000
In-Reply-To: <546490D40200006600079701@soto.provo.novell.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
	<5462343C020000660007880A@soto.provo.novell.com>
	<546490D40200006600079701@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@citrix.com>, George Dunlap <dunlapg@umich.edu>,
	Wei Liu <wei.liu2@citrix.com>, Jim Fehlig <JFEHLIG@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 20:07 -0700, Chun Yan Liu wrote:
> > > By "active" here, do you you mean "live" (vs paused)? 
> > Means the domain is started (no matter is running or paused). 
> > vs (libvirt defines a domain but not started). 
> > Here,  I should update this to: 
> > 3). take disk snapshot by qmp command 
> > libxl only handles active domain. 

I think the problem here is that different components in the system use
different terminology for things or even different concepts (e.g. libxl
has no inherent concept of inactive vs active domains, because it only
concerns itself with active domains).

Perhaps a glossary defining these things would help (also see below).

> > > >    libxl_domain_snapshot_delete:  
> > > >        1). check args validation  
> > > >        2). remove memory state file.  
> > > >        3). delete disk snapshot. (for internal disk snapshot, through qmp  
> > > >            command or qemu-img command)  
> > >   
> > > Out of curiosity, why is this necessary?  Is libxl keeping track of  
> > > the snapshots somewhere?  Or qemu?  
> > >   
> > > Or to put it a different way, since the caller knows the filenames,  
> > > why can't the caller just erase the files themselves? 
> >  
> > Ian asks the same question. The only reason I propose an API is: 
> > xl and libvirt can share the code. And in future, when support many other  
> > disk 
> > backend types, there is much repeated code. But as Ian mentioned in 
> > last version, for handling many disk backend types, maybe better placed in 
> > libxlu. Well, if both of you object, I'll remove this API. 

I think the reason we are having these same discussions over again is
that this proposal is focusing on the libxl API (e.g. the details of
what functions exist and what parameters they take) without an
introductory section which provides a broad overview of the
architecture, containing e.g. things like:

      * What the general requirements for domain snapshotting are;
      * What are the constraints which we are operating under; e.g.
        libvirt or xl design requirements
      * What the various components are (and which, possibly multiple,
        entities provide them) and where the various responsibilities
        lie.

I think we've teased a lot of this sort of thing out in past iterations
but without having it written down here I think we are all having
trouble agreeing (or remembering that we've agreed) that the API makes
sense because we all have different ideas about what the higher level
architecture/abstraction should look like.

See for example
http://xenbits.xen.org/people/dvrabel/event-channels-H.pdf or
http://lists.xen.org/archives/html/xen-devel/2014-10/msg03235.html (you
don't necessarily need to go all out on that level of formality, but
they provide some examples of the sorts of higher level design I'm
talking about)

I think it would also help with the glossary question above since it
would help define the terms.

I'm sorry for not observing this sooner.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:43:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11: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 1Xosnz-00083b-66; Thu, 13 Nov 2014 11:43:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kwolf@redhat.com>) id 1Xosny-00083U-4y
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 11:43:14 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	FF/FF-02699-15994645; Thu, 13 Nov 2014 11:43:13 +0000
X-Env-Sender: kwolf@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415878989!12261911!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5250 invoked from network); 13 Nov 2014 11:43:11 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 11:43:11 -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 sADBh1Fa008178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 13 Nov 2014 06:43:01 -0500
Received: from noname.redhat.com (ovpn-116-84.ams2.redhat.com [10.36.116.84])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with
	ESMTP id sADBgwdx003581; Thu, 13 Nov 2014 06:42:59 -0500
Date: Thu, 13 Nov 2014 12:42:57 +0100
From: Kevin Wolf <kwolf@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141113114257.GB3933@noname.redhat.com>
References: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
	<alpine.DEB.2.02.1411121629320.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Length: 3672
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411121629320.26318@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xenproject.org,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 12.11.2014 um 18:41 hat Stefano Stabellini geschrieben:
> On Wed, 12 Nov 2014, Roger Pau Monne wrote:
> > This patch fixes two issues with persistent grants and the disk PV back=
end
> > (Qdisk):
> > =

> >  - Don't use batch mappings when using persistent grants, doing so prev=
ents
> >    unmapping single grants (the whole area has to be unmapped at once).
> =

> The real issue is that destroy_grant cannot work with batch_maps.
> One could reimplement destroy_grant to build a single array with all the
> grants to unmap and make a single xc_gnttab_munmap call.
> =

> Do you think that would be feasible?
> =

> Performance wise, it would certainly be better.
> =

> =

> >  - Unmap persistent grants before switching to the closed state, so the
> >    frontend can also free them.
> >
> > Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
> > Reported-and-Tested-by: George Dunlap <george.dunlap@eu.citrix.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: Kevin Wolf <kwolf@redhat.com>
> > Cc: Stefan Hajnoczi <stefanha@redhat.com>
> > Cc: George Dunlap <george.dunlap@eu.citrix.com>
> > ---
> >  hw/block/xen_disk.c | 35 ++++++++++++++++++++++++-----------
> >  1 file changed, 24 insertions(+), 11 deletions(-)
> > =

> > diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> > index 231e9a7..1300c0a 100644
> > --- a/hw/block/xen_disk.c
> > +++ b/hw/block/xen_disk.c
> > @@ -43,8 +43,6 @@
> >  =

> >  /* ------------------------------------------------------------- */
> >  =

> > -static int batch_maps   =3D 0;
> > -
> >  static int max_requests =3D 32;
> >  =

> >  /* ------------------------------------------------------------- */
> > @@ -105,6 +103,7 @@ struct XenBlkDev {
> >      blkif_back_rings_t  rings;
> >      int                 more_work;
> >      int                 cnt_map;
> > +    bool                batch_maps;
> >  =

> >      /* request lists */
> >      QLIST_HEAD(inflight_head, ioreq) inflight;
> > @@ -309,7 +308,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
> >      if (ioreq->num_unmap =3D=3D 0 || ioreq->mapped =3D=3D 0) {
> >          return;
> >      }
> > -    if (batch_maps) {
> > +    if (ioreq->blkdev->batch_maps) {
> >          if (!ioreq->pages) {
> >              return;
> >          }
> > @@ -386,7 +385,7 @@ static int ioreq_map(struct ioreq *ioreq)
> >          new_maps =3D ioreq->v.niov;
> >      }
> >  =

> > -    if (batch_maps && new_maps) {
> > +    if (ioreq->blkdev->batch_maps && new_maps) {
> >          ioreq->pages =3D xc_gnttab_map_grant_refs
> >              (gnt, new_maps, domids, refs, ioreq->prot);
> >          if (ioreq->pages =3D=3D NULL) {
> > @@ -433,7 +432,7 @@ static int ioreq_map(struct ioreq *ioreq)
> >               */
> >              grant =3D g_malloc0(sizeof(*grant));
> >              new_maps--;
> > -            if (batch_maps) {
> > +            if (ioreq->blkdev->batch_maps) {
> >                  grant->page =3D ioreq->pages + (new_maps) * XC_PAGE_SI=
ZE;
> >              } else {
> >                  grant->page =3D ioreq->page[new_maps];
> > @@ -718,7 +717,9 @@ static void blk_alloc(struct XenDevice *xendev)
> >      QLIST_INIT(&blkdev->freelist);
> >      blkdev->bh =3D qemu_bh_new(blk_bh, blkdev);
> >      if (xen_mode !=3D XEN_EMULATE) {
> > -        batch_maps =3D 1;
> > +        blkdev->batch_maps =3D TRUE;
> > +    } else {
> > +        blkdev->batch_maps =3D FALSE;
> >      }
> =

> true and false, lower capitals

Or just blkdev->batch_maps =3D (xen_mode !=3D XEN_EMULATE);

Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:43:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11: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 1Xosnz-00083b-66; Thu, 13 Nov 2014 11:43:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kwolf@redhat.com>) id 1Xosny-00083U-4y
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 11:43:14 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	FF/FF-02699-15994645; Thu, 13 Nov 2014 11:43:13 +0000
X-Env-Sender: kwolf@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415878989!12261911!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5250 invoked from network); 13 Nov 2014 11:43:11 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 11:43:11 -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 sADBh1Fa008178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 13 Nov 2014 06:43:01 -0500
Received: from noname.redhat.com (ovpn-116-84.ams2.redhat.com [10.36.116.84])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with
	ESMTP id sADBgwdx003581; Thu, 13 Nov 2014 06:42:59 -0500
Date: Thu, 13 Nov 2014 12:42:57 +0100
From: Kevin Wolf <kwolf@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141113114257.GB3933@noname.redhat.com>
References: <1415807116-8375-1-git-send-email-roger.pau@citrix.com>
	<alpine.DEB.2.02.1411121629320.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Length: 3672
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411121629320.26318@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xenproject.org,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 12.11.2014 um 18:41 hat Stefano Stabellini geschrieben:
> On Wed, 12 Nov 2014, Roger Pau Monne wrote:
> > This patch fixes two issues with persistent grants and the disk PV back=
end
> > (Qdisk):
> > =

> >  - Don't use batch mappings when using persistent grants, doing so prev=
ents
> >    unmapping single grants (the whole area has to be unmapped at once).
> =

> The real issue is that destroy_grant cannot work with batch_maps.
> One could reimplement destroy_grant to build a single array with all the
> grants to unmap and make a single xc_gnttab_munmap call.
> =

> Do you think that would be feasible?
> =

> Performance wise, it would certainly be better.
> =

> =

> >  - Unmap persistent grants before switching to the closed state, so the
> >    frontend can also free them.
> >
> > Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
> > Reported-and-Tested-by: George Dunlap <george.dunlap@eu.citrix.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: Kevin Wolf <kwolf@redhat.com>
> > Cc: Stefan Hajnoczi <stefanha@redhat.com>
> > Cc: George Dunlap <george.dunlap@eu.citrix.com>
> > ---
> >  hw/block/xen_disk.c | 35 ++++++++++++++++++++++++-----------
> >  1 file changed, 24 insertions(+), 11 deletions(-)
> > =

> > diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> > index 231e9a7..1300c0a 100644
> > --- a/hw/block/xen_disk.c
> > +++ b/hw/block/xen_disk.c
> > @@ -43,8 +43,6 @@
> >  =

> >  /* ------------------------------------------------------------- */
> >  =

> > -static int batch_maps   =3D 0;
> > -
> >  static int max_requests =3D 32;
> >  =

> >  /* ------------------------------------------------------------- */
> > @@ -105,6 +103,7 @@ struct XenBlkDev {
> >      blkif_back_rings_t  rings;
> >      int                 more_work;
> >      int                 cnt_map;
> > +    bool                batch_maps;
> >  =

> >      /* request lists */
> >      QLIST_HEAD(inflight_head, ioreq) inflight;
> > @@ -309,7 +308,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
> >      if (ioreq->num_unmap =3D=3D 0 || ioreq->mapped =3D=3D 0) {
> >          return;
> >      }
> > -    if (batch_maps) {
> > +    if (ioreq->blkdev->batch_maps) {
> >          if (!ioreq->pages) {
> >              return;
> >          }
> > @@ -386,7 +385,7 @@ static int ioreq_map(struct ioreq *ioreq)
> >          new_maps =3D ioreq->v.niov;
> >      }
> >  =

> > -    if (batch_maps && new_maps) {
> > +    if (ioreq->blkdev->batch_maps && new_maps) {
> >          ioreq->pages =3D xc_gnttab_map_grant_refs
> >              (gnt, new_maps, domids, refs, ioreq->prot);
> >          if (ioreq->pages =3D=3D NULL) {
> > @@ -433,7 +432,7 @@ static int ioreq_map(struct ioreq *ioreq)
> >               */
> >              grant =3D g_malloc0(sizeof(*grant));
> >              new_maps--;
> > -            if (batch_maps) {
> > +            if (ioreq->blkdev->batch_maps) {
> >                  grant->page =3D ioreq->pages + (new_maps) * XC_PAGE_SI=
ZE;
> >              } else {
> >                  grant->page =3D ioreq->page[new_maps];
> > @@ -718,7 +717,9 @@ static void blk_alloc(struct XenDevice *xendev)
> >      QLIST_INIT(&blkdev->freelist);
> >      blkdev->bh =3D qemu_bh_new(blk_bh, blkdev);
> >      if (xen_mode !=3D XEN_EMULATE) {
> > -        batch_maps =3D 1;
> > +        blkdev->batch_maps =3D TRUE;
> > +    } else {
> > +        blkdev->batch_maps =3D FALSE;
> >      }
> =

> true and false, lower capitals

Or just blkdev->batch_maps =3D (xen_mode !=3D XEN_EMULATE);

Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:45:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 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 1Xospn-0008BY-M7; Thu, 13 Nov 2014 11:45: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 1Xospl-0008BO-TA
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 11:45:06 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	20/F9-26652-1C994645; Thu, 13 Nov 2014 11:45:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415879103!11101960!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4386 invoked from network); 13 Nov 2014 11:45:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 11:45:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190900863"
Message-ID: <1415879099.21321.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Thu, 13 Nov 2014 11:44:59 +0000
In-Reply-To: <54637703.80906@oracle.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com> <1415803209.1155.10.camel@citrix.com>
	<54637326.6090908@oracle.com> <1415803976.1155.14.camel@citrix.com>
	<54637703.80906@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Wed, 2014-11-12 at 10:04 -0500, Zhigang Wang wrote:
> On 11/12/2014 09:52 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> >> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> >>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> >>>> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
> >>>> time for xm/xend and xl: when VM fully migrated.
> >>>>
> >>>> The different between xm/xend and xl is: xend will populate destination side VM 
> >>>> xenstore entries at the beginning of migration.
> >>>
> >>> Do you mean *before* @introduceDomain has triggered?
> >>
> >> Yes, from my test. I didn't check the code logic yet.
> > 
> > I think anything which is trying to inspect the state of a domain before
> > the corresponding @introduceDomain and expecting anything more complex
> > than the fact of that domain's existence is broken.

I think I may have asked the wrong question there and then read the
answer in the context of the question I thought I'd asked. IOW most of
the rest of my mail was predicated on xend behaving differently to how
you've just explained via showing completeRestore().

It seems Wei is on the case so I'm just going to butt out...

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:45:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 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 1Xospn-0008BY-M7; Thu, 13 Nov 2014 11:45: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 1Xospl-0008BO-TA
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 11:45:06 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	20/F9-26652-1C994645; Thu, 13 Nov 2014 11:45:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415879103!11101960!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4386 invoked from network); 13 Nov 2014 11:45:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 11:45:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190900863"
Message-ID: <1415879099.21321.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Thu, 13 Nov 2014 11:44:59 +0000
In-Reply-To: <54637703.80906@oracle.com>
References: <20141110123525.GD28360@zion.uk.xensource.com>
	<5460D342.9090308@oracle.com>
	<20141110152535.GA6110@zion.uk.xensource.com>
	<5460F102.9000100@oracle.com>
	<20141110172408.GA6588@zion.uk.xensource.com>
	<5460FBCA.5060302@oracle.com>
	<20141111110156.GA12465@zion.uk.xensource.com>
	<5462201C.302@oracle.com>
	<20141111152011.GA21312@zion.uk.xensource.com>
	<54623C5C.6010504@oracle.com>
	<20141112113156.GA28075@zion.uk.xensource.com>
	<54637076.7060708@oracle.com> <1415803209.1155.10.camel@citrix.com>
	<54637326.6090908@oracle.com> <1415803976.1155.14.camel@citrix.com>
	<54637703.80906@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] xl list -l doesn't work for incoming 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 Wed, 2014-11-12 at 10:04 -0500, Zhigang Wang wrote:
> On 11/12/2014 09:52 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> >> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> >>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> >>>> Also I want clarify one thing: the @introduceDomain watch is triggered at the same
> >>>> time for xm/xend and xl: when VM fully migrated.
> >>>>
> >>>> The different between xm/xend and xl is: xend will populate destination side VM 
> >>>> xenstore entries at the beginning of migration.
> >>>
> >>> Do you mean *before* @introduceDomain has triggered?
> >>
> >> Yes, from my test. I didn't check the code logic yet.
> > 
> > I think anything which is trying to inspect the state of a domain before
> > the corresponding @introduceDomain and expecting anything more complex
> > than the fact of that domain's existence is broken.

I think I may have asked the wrong question there and then read the
answer in the context of the question I thought I'd asked. IOW most of
the rest of my mail was predicated on xend behaving differently to how
you've just explained via showing completeRestore().

It seems Wei is on the case so I'm just going to butt out...

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:50:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XosuN-0008Lw-DL; Thu, 13 Nov 2014 11:49:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XosuM-0008Lr-Lh
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 11:49:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3A/A8-09936-EDA94645; Thu, 13 Nov 2014 11:49:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415879388!12480951!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31540 invoked from network); 13 Nov 2014 11:49:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 11:49:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190902181"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 06:49:47 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XosuJ-0006xW-2I;
	Thu, 13 Nov 2014 11:49:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XosuI-00063W-BI;
	Thu, 13 Nov 2014 11:49:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21604.39641.398785.791489@mariner.uk.xensource.com>
Date: Thu, 13 Nov 2014 11:49:45 +0000
To: <xen-devel@lists.xensource.com>,
	<rumpkernel-builds@lists.sourceforge.net>, Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <21604.38018.698955.355136@mariner.uk.xensource.com>
References: <osstest-31509-mainreport@xen.org>
	<21604.38018.698955.355136@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Subject: Re: [Xen-devel] [rumpuserxen test] 31509: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: [rumpuserxen test] 31509: regressions - FAIL"):
...
> This is weird.

Actually, I think, the problem is that the rumpkernel now exits
successfully rather than crashing, and my domain config file says only
`on_crash="preserve"' and not `on_shutdown="preserve"'.

So this is a bug in the tests, exposed by a correct change to the
rumpkernel software.  I will fix the test and hopefully this will get
a test pass in another day or two.

Thanks to Wei for listening to me explain :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 11:50:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 11:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XosuN-0008Lw-DL; Thu, 13 Nov 2014 11:49:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XosuM-0008Lr-Lh
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 11:49:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3A/A8-09936-EDA94645; Thu, 13 Nov 2014 11:49:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415879388!12480951!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31540 invoked from network); 13 Nov 2014 11:49:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 11:49:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190902181"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 06:49:47 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XosuJ-0006xW-2I;
	Thu, 13 Nov 2014 11:49:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XosuI-00063W-BI;
	Thu, 13 Nov 2014 11:49:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21604.39641.398785.791489@mariner.uk.xensource.com>
Date: Thu, 13 Nov 2014 11:49:45 +0000
To: <xen-devel@lists.xensource.com>,
	<rumpkernel-builds@lists.sourceforge.net>, Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <21604.38018.698955.355136@mariner.uk.xensource.com>
References: <osstest-31509-mainreport@xen.org>
	<21604.38018.698955.355136@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Subject: Re: [Xen-devel] [rumpuserxen test] 31509: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: [rumpuserxen test] 31509: regressions - FAIL"):
...
> This is weird.

Actually, I think, the problem is that the rumpkernel now exits
successfully rather than crashing, and my domain config file says only
`on_crash="preserve"' and not `on_shutdown="preserve"'.

So this is a bug in the tests, exposed by a correct change to the
rumpkernel software.  I will fix the test and hopefully this will get
a test pass in another day or two.

Thanks to Wei for listening to me explain :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 12:02:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 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.xen.org>)
	id 1Xot6j-0000Wd-R4; Thu, 13 Nov 2014 12: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@citrix.com>) id 1Xot6i-0000WX-7A
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 12:02:36 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	16/D4-28865-BDD94645; Thu, 13 Nov 2014 12:02:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415880152!11104832!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15986 invoked from network); 13 Nov 2014 12:02:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 12:02:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190904933"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 07:02:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xot6G-0001SO-OZ;
	Thu, 13 Nov 2014 12:02:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xot6G-0006YT-FV;
	Thu, 13 Nov 2014 12:02:08 +0000
Date: Thu, 13 Nov 2014 12:02:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31517-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11330
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31517: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3476792518127761905=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3476792518127761905==
Content-Type: text/plain
Content-Length: 11091
Content-Transfer-Encoding: quoted-printable

flight 31517 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31517/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                e0d0041ec6dce1b8bfb3f66e9e4b8b9cd7e34806
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 11825 lines long.)


--===============3476792518127761905==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3476792518127761905==--

From xen-devel-bounces@lists.xen.org Thu Nov 13 12:02:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 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.xen.org>)
	id 1Xot6j-0000Wd-R4; Thu, 13 Nov 2014 12: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@citrix.com>) id 1Xot6i-0000WX-7A
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 12:02:36 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	16/D4-28865-BDD94645; Thu, 13 Nov 2014 12:02:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415880152!11104832!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15986 invoked from network); 13 Nov 2014 12:02:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 12:02:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,376,1413244800"; d="scan'208";a="190904933"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 07:02:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xot6G-0001SO-OZ;
	Thu, 13 Nov 2014 12:02:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xot6G-0006YT-FV;
	Thu, 13 Nov 2014 12:02:08 +0000
Date: Thu, 13 Nov 2014 12:02:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31517-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11330
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31517: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3476792518127761905=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3476792518127761905==
Content-Type: text/plain
Content-Length: 11091
Content-Transfer-Encoding: quoted-printable

flight 31517 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31517/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                e0d0041ec6dce1b8bfb3f66e9e4b8b9cd7e34806
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 11825 lines long.)


--===============3476792518127761905==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3476792518127761905==--

From xen-devel-bounces@lists.xen.org Thu Nov 13 12:22:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 12:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XotPq-0000sH-L7; Thu, 13 Nov 2014 12:22:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XotPo-0000sC-LE
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 12:22:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	38/C7-24532-C72A4645; Thu, 13 Nov 2014 12:22:20 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415881337!12444672!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8361 invoked from network); 13 Nov 2014 12:22:17 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 12:22:17 -0000
Received: by mail-wg0-f54.google.com with SMTP id n12so16683380wgh.13
	for <xen-devel@lists.xensource.com>;
	Thu, 13 Nov 2014 04:22:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=LlXSvlvuneFyiebBo7gGR7pe2SM/bvnZDPBGxIyaWeQ=;
	b=WSiXFJFHJjjBJaazJlzRkxKPcn4WSEQgYbPLmHrbAHWndtHoeaBDVTrrXjEvnhgIKA
	H0WzRffzjpKjDWTEmIBAfDSVl9bZb9Ay2f2Lk4Gh0jn8u5Qqgtn2c6M0pcvgRNXXNHie
	q2h7j+AfcrUrN+sXeIu8aV2Y81zRoWSLYVqsZNW5wfm92sXDVSWvU5fAo68mb062cO/X
	1z3S0lTfXEmNTEXx0kL/f5GWD/TuRozhLONQ8ggFA9W7gsPuiKlRW9sXvlo/EYMaJXGS
	QfLlZPtXgHJdQ32FE7iblbMdst6/OEFa6r694ZIvoaJiSVUaEZi3YmFxFcLvwClOlgNS
	Yweg==
X-Gm-Message-State: ALoCoQlIEGoelOUv4sh9kjGbIpxedXeNEVH6Ox1piuvhjfTRRLclmJRKdzfuZD2VdFCYMJmn/7mv
X-Received: by 10.180.90.112 with SMTP id bv16mr3327698wib.53.1415881336709;
	Thu, 13 Nov 2014 04:22:16 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id cv7sm35351067wjc.3.2014.11.13.04.22.13
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 13 Nov 2014 04:22:15 -0800 (PST)
Message-ID: <5464A27D.4020107@m2r.biz>
Date: Thu, 13 Nov 2014 13:22:21 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <53BBA83C.3010307@m2r.biz>
	<1404809604.30343.5.camel@cihla.spice.brq.redhat.com>
	<53BBC2AA.4030503@m2r.biz> <53BBC952.1040902@m2r.biz>
	<54130761.6080501@m2r.biz> <541C2D39.1060607@m2r.biz>
	<54648477.5040505@m2r.biz>
In-Reply-To: <54648477.5040505@m2r.biz>
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [Spice-devel] screen freezed for 2-3 minutes on
 spice connect on xen windows 7 domU's with qxl after save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1311755257024061390=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============1311755257024061390==
Content-Type: multipart/alternative;
 boundary="------------040209010902020805050608"

This is a multi-part message in MIME format.
--------------040209010902020805050608
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Length: 15342
Content-Transfer-Encoding: quoted-printable

Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
> Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
>> Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
>>> Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
>>>> Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
>>>>> Il 08/07/2014 10:53, David Ja=9Aa ha scritto:
>>>>>> Hi,
>>>>>>
>>>>>> On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
>>>>>>> On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
>>>>>>> client with
>>>>>>> spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as kvm
>>>>>>> except for one problem after xl save/restore, when after restore on
>>>>>>> spice client connect  the domU's screen freezed for 2-3 minutes 
>>>>>>> (and
>>>>>>> seems also windows), after this time seems that all return to works
>>>>>>> correctly.
>>>>>>> This problem happen also if spice client connect long time after 
>>>>>>> restore.
>>>>>>> With stdvga not have this problem but stdvga has many missed 
>>>>>>> resolutions
>>>>>>> and bad refresh performance.
>>>>>>>
>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>> Client and server logs would certainly help. Please run:
>>>>>>    * virt-viewer with --spice-debug option
>>>>>>    * spice-server with SPICE_DEBUG_LEVEL environment variable set
>>>>>>      to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
>>>>>> http://libvirt.org/drvqemu.html#qemucommand )
>>>>>> and note the location in the logs where the freeze takes place.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> David
>>>>>
>>>>> Thanks for your reply, in attachments:
>>>>> - domU's xl cfg: W7.cfg
>>>>> - xl -vvv create/save/restore: xen logs.txt
>>>>> - remote-viewer with --spice-debug after domU's start until xl 
>>>>> save: spicelog-1.txt (zipped)
>>>>> - remote-viewer with --spice-debug after domU's xl restore: 
>>>>> spicelog-2.txt
>>>>
>>>> Sorry for my forgetfulness, here also qemu's log:
>>>> - after domU's start until xl save: qemu-dm-W7.log.1
>>>> - after domU's xl restore: qemu-dm-W7.log
>>>>
>>>>>
>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>
>>>>>
>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Spice-devel mailing list
>>>>>> Spice-devel@lists.freedesktop.org
>>>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>
>>>
>>> The problem persist, this time I saw these in xl dmesg after restore:
>>>
>>> (XEN) HVM2 restore: CPU 0
>>> (XEN) HVM2 restore: CPU 1
>>> (XEN) HVM2 restore: PIC 0
>>> (XEN) HVM2 restore: PIC 1
>>> (XEN) HVM2 restore: IOAPIC 0
>>> (XEN) HVM2 restore: LAPIC 0
>>> (XEN) HVM2 restore: LAPIC 1
>>> (XEN) HVM2 restore: LAPIC_REGS 0
>>> (XEN) HVM2 restore: LAPIC_REGS 1
>>> (XEN) HVM2 restore: PCI_IRQ 0
>>> (XEN) HVM2 restore: ISA_IRQ 0
>>> (XEN) HVM2 restore: PCI_LINK 0
>>> (XEN) HVM2 restore: PIT 0
>>> (XEN) HVM2 restore: RTC 0
>>> (XEN) HVM2 restore: HPET 0
>>> (XEN) HVM2 restore: PMTIMER 0
>>> (XEN) HVM2 restore: MTRR 0
>>> (XEN) HVM2 restore: MTRR 1
>>> (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 0
>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 1
>>> (XEN) HVM2 restore: VMCE_VCPU 0
>>> (XEN) HVM2 restore: VMCE_VCPU 1
>>> (XEN) HVM2 restore: TSC_ADJUST 0
>>> (XEN) HVM2 restore: TSC_ADJUST 1
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
>>> (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from (4) 
>>> to (32) frames.
>>> (XEN) irq.c:380: Dom2 callback via changed to GSI 24
>>>
>>> Tested on latest staging (commit 
>>> 7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:
>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>
>>> If you need more informations or tests tell me and I'll post them.
>>> Thanks for any reply and sorry for my bad english.
>>
>> I did another tests updating to latest git staging (commit 
>> 3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of 
>> "only" 2-3 minutes but now when it appears to restart (after 2-3 
>> minutes) windows domUs undefinitely hangs instead.
>> No further details in xen and domU's logs.
>>
>> If you need more tests/details tell me and I'll do them.
>>
>> Thanks for any reply.
>
> I did a new test with xen build based on tag 4.5.0-rc2 and on xl dmesg 
> show these errors:
>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
> Before and after save/restore, with stdvga instead not show them.

Sorry, I found that was introduced by new winpv drivers update instead 
and I solved applying this patch:
x86/hvm: Add per-vcpu evtchn upcalls v3 
http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html
About save/restore problem with qxl I still not found a solution or at 
least the exact cause :(

>
> Below I posted full xl dmesg of domU, if you need more 
> informations/tests tell me and I'll post them.
>
>
>> (d4) HVM Loader
>> (d4) Detected Xen v4.5.0-rc
>> (d4) Xenbus rings @0xfeffc000, event channel 1
>> (d4) System requested SeaBIOS
>> (d4) CPU speed is 2660 MHz
>> (d4) Relocating guest memory for lowmem MMIO space disabled
>> (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -> 5
>> (d4) PCI-ISA link 0 routed to IRQ5
>> (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -> 10
>> (d4) PCI-ISA link 1 routed to IRQ10
>> (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -> 11
>> (d4) PCI-ISA link 2 routed to IRQ11
>> (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -> 5
>> (d4) PCI-ISA link 3 routed to IRQ5
>> (d4) pci dev 01:3 INTA->IRQ10
>> (d4) pci dev 02:0 INTA->IRQ11
>> (d4) pci dev 03:0 INTA->IRQ5
>> (d4) pci dev 04:0 INTA->IRQ5
>> (d4) pci dev 05:0 INTA->IRQ10
>> (d4) pci dev 06:0 INTA->IRQ11
>> (d4) pci dev 1d:0 INTA->IRQ10
>> (d4) pci dev 1d:1 INTB->IRQ11
>> (d4) pci dev 1d:2 INTC->IRQ5
>> (d4) pci dev 1d:7 INTD->IRQ5
>> (d4) No RAM in high memory; setting high_mem resource base to 100000000
>> (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000
>> (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000
>> (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008
>> (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000
>> (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000
>> (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000
>> (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000
>> (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000
>> (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>> (d4) pci dev 02:0 bar 10 size 000000100: 00000c001
>> (d4) pci dev 06:0 bar 10 size 000000100: 00000c101
>> (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000
>> (d4) pci dev 04:0 bar 10 size 000000020: 00000c201
>> (d4) pci dev 05:0 bar 1c size 000000020: 00000c221
>> (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241
>> (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261
>> (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281
>> (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>> (d4) Multiprocessor initialisation:
>> (d4)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>> done.
>> (d4)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>> done.
>> (d4) Testing HVM environment:
>> (d4)  - REP INSB across page boundaries ... passed
>> (d4)  - GS base MSRs and SWAPGS ... passed
>> (d4) Passed 2 of 2 tests
>> (d4) Writing SMBIOS tables ...
>> (d4) Loading SeaBIOS ...
>> (d4) Creating MP tables ...
>> (d4) Loading ACPI ...
>> (d4) S3 disabled
>> (d4) S4 disabled
>> (d4) vm86 TSS at fc00a100
>> (d4) BIOS map:
>> (d4)  10000-100d3: Scratch space
>> (d4)  c0000-fffff: Main BIOS
>> (d4) E820 table:
>> (d4)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>> (d4)  HOLE: 00000000:000a0000 - 00000000:000c0000
>> (d4)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>> (d4)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>> (d4)  HOLE: 00000000:78000000 - 00000000:fc000000
>> (d4)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>> (d4) Invoking SeaBIOS ...
>> (d4) SeaBIOS (version 
>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>> (d4)
>> (d4) Found Xen hypervisor signature at 40000100
>> (d4) Running on QEMU (i440fx)
>> (d4) xen: copy e820...
>> (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>> (d4) CPU Mhz=3D2661
>> (d4) Found 13 PCI devices (max PCI bus is 00)
>> (d4) Allocated Xen hypercall page at 77fff000
>> (d4) Detected Xen v4.5.0-rc
>> (d4) xen: copy BIOS tables...
>> (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>> (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>> (d4) Copying PIR from 0x00010030 to 0x000f0dc0
>> (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>> (d4) Using pmtimer, ioport 0xb008
>> (d4) Scan for VGA option rom
>> (d4) Running option rom at c000:0003
>> (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes
>> (d4) pmm call arg1=3D0
>> (d4) Turning on vga text mode console
>> (d4) SeaBIOS (version 
>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>> (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838
>> (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)
>> (d4) Found 0 lpt ports
>> (d4) Found 0 serial ports
>> (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>> (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>> (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)
>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>> (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
>> (d4) UHCI init on dev 00:1d.0 (io=3Dc240)
>> (d4) UHCI init on dev 00:1d.1 (io=3Dc260)
>> (d4) UHCI init on dev 00:1d.2 (io=3Dc280)
>> (d4) PS2 keyboard initialized
>> (d4) All threads complete.
>> (d4) Scan for option roms
>> (d4) Running option rom at c980:0003
>> (d4) pmm call arg1=3D1
>> (d4) pmm call arg1=3D0
>> (d4) pmm call arg1=3D1
>> (d4) pmm call arg1=3D0
>> (d4) Searching bootorder for: /pci@i0cf8/*@6
>> (d4)
>> (d4) Press F12 for boot menu.
>> (d4)
>> (d4) Searching bootorder for: HALT
>> (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba 
>> LCHS=3D1024/255/63 s=3D102400000
>> (d4)
>> (d4) Space available for UMB: ca800-ee800, f0000-f0ce0
>> (d4) Returned 258048 bytes of ZoneHigh
>> (d4) e820 map has 6 items:
>> (d4)   0: 0000000000000000 - 000000000009fc00 =3D 1 RAM
>> (d4)   1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED
>> (d4)   2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED
>> (d4)   3: 0000000000100000 - 0000000077fff000 =3D 1 RAM
>> (d4)   4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED
>> (d4)   5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED
>> (d4) enter handle_19:
>> (d4)   NULL
>> (d4) Booting from DVD/CD...
>> (d4) Device reports MEDIUM NOT PRESENT
>> (d4) scsi_is_ready returned -1
>> (d4) Boot failed: Could not read from CDROM (code 0003)
>> (d4) enter handle_18:
>> (d4)   NULL
>> (d4) Booting from Hard Disk...
>> (d4) Booting from 0000:7c00
>> (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 
>> 1 build: 1db1
>> (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
>> (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
>> (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
>> (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -> 0
>> (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -> 0
>> (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -> 0
>> (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -> 0
>> *(XEN) hvm.c:6119:d4v1 Bad HVM op 23.**
>> **(XEN) hvm.c:6119:d4v1 Bad HVM op 23.*
>> (XEN) irq.c:380: Dom4 callback via changed to GSI 24
>> (XEN) HVM4 save: CPU
>> (XEN) HVM4 save: PIC
>> (XEN) HVM4 save: IOAPIC
>> (XEN) HVM4 save: LAPIC
>> (XEN) HVM4 save: LAPIC_REGS
>> (XEN) HVM4 save: PCI_IRQ
>> (XEN) HVM4 save: ISA_IRQ
>> (XEN) HVM4 save: PCI_LINK
>> (XEN) HVM4 save: PIT
>> (XEN) HVM4 save: RTC
>> (XEN) HVM4 save: HPET
>> (XEN) HVM4 save: PMTIMER
>> (XEN) HVM4 save: MTRR
>> (XEN) HVM4 save: VIRIDIAN_DOMAIN
>> (XEN) HVM4 save: CPU_XSAVE
>> (XEN) HVM4 save: VIRIDIAN_VCPU
>> (XEN) HVM4 save: VMCE_VCPU
>> (XEN) HVM4 save: TSC_ADJUST
>> (XEN) HVM5 restore: CPU 0
>> (XEN) HVM5 restore: CPU 1
>> (XEN) HVM5 restore: PIC 0
>> (XEN) HVM5 restore: PIC 1
>> (XEN) HVM5 restore: IOAPIC 0
>> (XEN) HVM5 restore: LAPIC 0
>> (XEN) HVM5 restore: LAPIC 1
>> (XEN) HVM5 restore: LAPIC_REGS 0
>> (XEN) HVM5 restore: LAPIC_REGS 1
>> (XEN) HVM5 restore: PCI_IRQ 0
>> (XEN) HVM5 restore: ISA_IRQ 0
>> (XEN) HVM5 restore: PCI_LINK 0
>> (XEN) HVM5 restore: PIT 0
>> (XEN) HVM5 restore: RTC 0
>> (XEN) HVM5 restore: HPET 0
>> (XEN) HVM5 restore: PMTIMER 0
>> (XEN) HVM5 restore: MTRR 0
>> (XEN) HVM5 restore: MTRR 1
>> (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0
>> (XEN) HVM5 restore: VIRIDIAN_VCPU 0
>> (XEN) HVM5 restore: VIRIDIAN_VCPU 1
>> (XEN) HVM5 restore: VMCE_VCPU 0
>> (XEN) HVM5 restore: VMCE_VCPU 1
>> (XEN) HVM5 restore: TSC_ADJUST 0
>> (XEN) HVM5 restore: TSC_ADJUST 1
>> (XEN) irq.c:380: Dom5 callback via changed to None
>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>> (XEN) irq.c:380: Dom5 callback via changed to GSI 24
>
>


--------------040209010902020805050608
Content-Type: text/html; charset=windows-1252
Content-Length: 21171
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Il 13/11/2014 11:14, Fabio Fantoni ha
      scritto:<br>
    </div>
    <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite">
      <meta content=3D"text/html; charset=3Dwindows-1252"
        http-equiv=3D"Content-Type">
      <div class=3D"moz-cite-prefix">Il 19/09/2014 15:18, Fabio Fantoni ha
        scritto:<br>
      </div>
      <blockquote cite=3D"mid:541C2D39.1060607@m2r.biz" type=3D"cite">Il
        12/09/2014 16:46, Fabio Fantoni ha scritto: <br>
        <blockquote type=3D"cite">Il 08/07/2014 12:34, Fabio Fantoni ha
          scritto: <br>
          <blockquote type=3D"cite">Il 08/07/2014 12:06, Fabio Fantoni ha
            scritto: <br>
            <blockquote type=3D"cite">Il 08/07/2014 10:53, David Ja=9Aa ha
              scritto: <br>
              <blockquote type=3D"cite">Hi, <br>
                <br>
                On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote: <br>
                <blockquote type=3D"cite">On xen 4.5 (tried with qemu
                  2.0.0/2.1-rc0, spice 0.12.5 and client with <br>
                  spice-gtk 0.23/0.25) windows 7 domUs with qxl vga
                  works good as kvm <br>
                  except for one problem after xl save/restore, when
                  after restore on <br>
                  spice client connect=A0 the domU's screen freezed for
                  2-3 minutes (and <br>
                  seems also windows), after this time seems that all
                  return to works <br>
                  correctly. <br>
                  This problem happen also if spice client connect long
                  time after restore. <br>
                  With stdvga not have this problem but stdvga has many
                  missed resolutions <br>
                  and bad refresh performance. <br>
                  <br>
                  If you need more tests/informations tell me and I'll
                  post them. <br>
                </blockquote>
                Client and server logs would certainly help. Please run:
                <br>
                =A0=A0 * virt-viewer with --spice-debug option <br>
                =A0=A0 * spice-server with SPICE_DEBUG_LEVEL environment
                variable set <br>
                =A0=A0=A0=A0 to 4 or 5 (if you use qemu+libvirt, use qemu:env
                element: <br>
                =A0=A0=A0=A0 <a moz-do-not-send=3D"true"
                  class=3D"moz-txt-link-freetext"
                  href=3D"http://libvirt.org/drvqemu.html#qemucommand">http://libvirt.org/drvqemu.html#qemucommand</a>
                ) <br>
                and note the location in the logs where the freeze takes
                place. <br>
                <br>
                Regards, <br>
                <br>
                David <br>
              </blockquote>
              <br>
              Thanks for your reply, in attachments: <br>
              - domU's xl cfg: W7.cfg <br>
              - xl -vvv create/save/restore: xen logs.txt <br>
              - remote-viewer with --spice-debug after domU's start
              until xl save: spicelog-1.txt (zipped) <br>
              - remote-viewer with --spice-debug after domU's xl
              restore: spicelog-2.txt <br>
            </blockquote>
            <br>
            Sorry for my forgetfulness, here also qemu's log: <br>
            - after domU's start until xl save: qemu-dm-W7.log.1 <br>
            - after domU's xl restore: qemu-dm-W7.log <br>
            <br>
            <blockquote type=3D"cite"> <br>
              If you need more tests/informations tell me and I'll post
              them. <br>
              <br>
              <br>
              <blockquote type=3D"cite">Thanks for any reply and sorry for
                my bad english. <br>
                <br>
                _______________________________________________ <br>
                Spice-devel mailing list <br>
                <a moz-do-not-send=3D"true"
                  class=3D"moz-txt-link-abbreviated"
                  href=3D"mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a>
                <br>
                <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
href=3D"http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a>
                <br>
              </blockquote>
            </blockquote>
            <br>
          </blockquote>
          <br>
          The problem persist, this time I saw these in xl dmesg after
          restore: <br>
          <br>
          (XEN) HVM2 restore: CPU 0 <br>
          (XEN) HVM2 restore: CPU 1 <br>
          (XEN) HVM2 restore: PIC 0 <br>
          (XEN) HVM2 restore: PIC 1 <br>
          (XEN) HVM2 restore: IOAPIC 0 <br>
          (XEN) HVM2 restore: LAPIC 0 <br>
          (XEN) HVM2 restore: LAPIC 1 <br>
          (XEN) HVM2 restore: LAPIC_REGS 0 <br>
          (XEN) HVM2 restore: LAPIC_REGS 1 <br>
          (XEN) HVM2 restore: PCI_IRQ 0 <br>
          (XEN) HVM2 restore: ISA_IRQ 0 <br>
          (XEN) HVM2 restore: PCI_LINK 0 <br>
          (XEN) HVM2 restore: PIT 0 <br>
          (XEN) HVM2 restore: RTC 0 <br>
          (XEN) HVM2 restore: HPET 0 <br>
          (XEN) HVM2 restore: PMTIMER 0 <br>
          (XEN) HVM2 restore: MTRR 0 <br>
          (XEN) HVM2 restore: MTRR 1 <br>
          (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0 <br>
          (XEN) HVM2 restore: VIRIDIAN_VCPU 0 <br>
          (XEN) HVM2 restore: VIRIDIAN_VCPU 1 <br>
          (XEN) HVM2 restore: VMCE_VCPU 0 <br>
          (XEN) HVM2 restore: VMCE_VCPU 1 <br>
          (XEN) HVM2 restore: TSC_ADJUST 0 <br>
          (XEN) HVM2 restore: TSC_ADJUST 1 <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid <br>
          (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table
          from (4) to (32) frames. <br>
          (XEN) irq.c:380: Dom2 callback via changed to GSI 24 <br>
          <br>
          Tested on latest staging (commit
          7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice
          patches: <br>
          <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
            href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a>
          <br>
          <br>
          If you need more informations or tests tell me and I'll post
          them. <br>
          Thanks for any reply and sorry for my bad english. <br>
        </blockquote>
        <br>
        I did another tests updating to latest git staging (commit
        3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem
        of "only" 2-3 minutes but now when it appears to restart (after
        2-3 minutes) windows domUs undefinitely hangs instead. <br>
        No further details in xen and domU's logs. <br>
        <br>
        If you need more tests/details tell me and I'll do them. <br>
        <br>
        Thanks for any reply. <br>
      </blockquote>
      <br>
      I did a new test with xen build based on tag 4.5.0-rc2 and on xl
      dmesg show these errors:<br>
      <blockquote type=3D"cite"><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b></blockquote>
      Before and after save/restore, with stdvga instead not show them.<br>
    </blockquote>
    <br>
    Sorry, I found that was introduced by new winpv drivers update
    instead and I solved applying this patch:<br>
    x86/hvm: Add per-vcpu evtchn upcalls v3
    <a class=3D"moz-txt-link-freetext" href=3D"http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html">http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html</a><br>
    About save/restore problem with qxl I still not found a solution or
    at least the exact cause :(<br>
    <br>
    <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite"> <br>
      Below I posted full xl dmesg of domU, if you need more
      informations/tests tell me and I'll post them.<br>
      <br>
      <br>
      <blockquote type=3D"cite">(d4) HVM Loader<br>
        (d4) Detected Xen v4.5.0-rc<br>
        (d4) Xenbus rings @0xfeffc000, event channel 1<br>
        (d4) System requested SeaBIOS<br>
        (d4) CPU speed is 2660 MHz<br>
        (d4) Relocating guest memory for lowmem MMIO space disabled<br>
        (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -&gt; 5<br>
        (d4) PCI-ISA link 0 routed to IRQ5<br>
        (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -&gt; 10<br>
        (d4) PCI-ISA link 1 routed to IRQ10<br>
        (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -&gt; 11<br>
        (d4) PCI-ISA link 2 routed to IRQ11<br>
        (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -&gt; 5<br>
        (d4) PCI-ISA link 3 routed to IRQ5<br>
        (d4) pci dev 01:3 INTA-&gt;IRQ10<br>
        (d4) pci dev 02:0 INTA-&gt;IRQ11<br>
        (d4) pci dev 03:0 INTA-&gt;IRQ5<br>
        (d4) pci dev 04:0 INTA-&gt;IRQ5<br>
        (d4) pci dev 05:0 INTA-&gt;IRQ10<br>
        (d4) pci dev 06:0 INTA-&gt;IRQ11<br>
        (d4) pci dev 1d:0 INTA-&gt;IRQ10<br>
        (d4) pci dev 1d:1 INTB-&gt;IRQ11<br>
        (d4) pci dev 1d:2 INTC-&gt;IRQ5<br>
        (d4) pci dev 1d:7 INTD-&gt;IRQ5<br>
        (d4) No RAM in high memory; setting high_mem resource base to
        100000000<br>
        (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000<br>
        (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000<br>
        (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008<br>
        (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000<br>
        (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000<br>
        (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000<br>
        (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000<br>
        (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000<br>
        (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000<br>
        (d4) pci dev 02:0 bar 10 size 000000100: 00000c001<br>
        (d4) pci dev 06:0 bar 10 size 000000100: 00000c101<br>
        (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000<br>
        (d4) pci dev 04:0 bar 10 size 000000020: 00000c201<br>
        (d4) pci dev 05:0 bar 1c size 000000020: 00000c221<br>
        (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241<br>
        (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261<br>
        (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281<br>
        (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1<br>
        (d4) Multiprocessor initialisation:<br>
        (d4)=A0 - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
        ... done.<br>
        (d4)=A0 - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
        ... done.<br>
        (d4) Testing HVM environment:<br>
        (d4)=A0 - REP INSB across page boundaries ... passed<br>
        (d4)=A0 - GS base MSRs and SWAPGS ... passed<br>
        (d4) Passed 2 of 2 tests<br>
        (d4) Writing SMBIOS tables ...<br>
        (d4) Loading SeaBIOS ...<br>
        (d4) Creating MP tables ...<br>
        (d4) Loading ACPI ...<br>
        (d4) S3 disabled<br>
        (d4) S4 disabled<br>
        (d4) vm86 TSS at fc00a100<br>
        (d4) BIOS map:<br>
        (d4)=A0 10000-100d3: Scratch space<br>
        (d4)=A0 c0000-fffff: Main BIOS<br>
        (d4) E820 table:<br>
        (d4)=A0 [00]: 00000000:00000000 - 00000000:000a0000: RAM<br>
        (d4)=A0 HOLE: 00000000:000a0000 - 00000000:000c0000<br>
        (d4)=A0 [01]: 00000000:000c0000 - 00000000:00100000: RESERVED<br>
        (d4)=A0 [02]: 00000000:00100000 - 00000000:78000000: RAM<br>
        (d4)=A0 HOLE: 00000000:78000000 - 00000000:fc000000<br>
        (d4)=A0 [03]: 00000000:fc000000 - 00000001:00000000: RESERVED<br>
        (d4) Invoking SeaBIOS ...<br>
        (d4) SeaBIOS (version
        debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
        (d4) <br>
        (d4) Found Xen hypervisor signature at 40000100<br>
        (d4) Running on QEMU (i440fx)<br>
        (d4) xen: copy e820...<br>
        (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)<br>
        (d4) CPU Mhz=3D2661<br>
        (d4) Found 13 PCI devices (max PCI bus is 00)<br>
        (d4) Allocated Xen hypercall page at 77fff000<br>
        (d4) Detected Xen v4.5.0-rc<br>
        (d4) xen: copy BIOS tables...<br>
        (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40<br>
        (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40<br>
        (d4) Copying PIR from 0x00010030 to 0x000f0dc0<br>
        (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90<br>
        (d4) Using pmtimer, ioport 0xb008<br>
        (d4) Scan for VGA option rom<br>
        (d4) Running option rom at c000:0003<br>
        (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes<br>
        (d4) pmm call arg1=3D0<br>
        (d4) Turning on vga text mode console<br>
        (d4) SeaBIOS (version
        debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
        (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838<br>
        (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)<br>
        (d4) Found 0 lpt ports<br>
        (d4) Found 0 serial ports<br>
        (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)<br>
        (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)<br>
        (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)<br>
        (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0<br>
        (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]<br>
        (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1<br>
        (d4) UHCI init on dev 00:1d.0 (io=3Dc240)<br>
        (d4) UHCI init on dev 00:1d.1 (io=3Dc260)<br>
        (d4) UHCI init on dev 00:1d.2 (io=3Dc280)<br>
        (d4) PS2 keyboard initialized<br>
        (d4) All threads complete.<br>
        (d4) Scan for option roms<br>
        (d4) Running option rom at c980:0003<br>
        (d4) pmm call arg1=3D1<br>
        (d4) pmm call arg1=3D0<br>
        (d4) pmm call arg1=3D1<br>
        (d4) pmm call arg1=3D0<br>
        (d4) Searching bootorder for: /pci@i0cf8/*@6<br>
        (d4) <br>
        (d4) Press F12 for boot menu.<br>
        (d4) <br>
        (d4) Searching bootorder for: HALT<br>
        (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba
        LCHS=3D1024/255/63 s=3D102400000<br>
        (d4) <br>
        (d4) Space available for UMB: ca800-ee800, f0000-f0ce0<br>
        (d4) Returned 258048 bytes of ZoneHigh<br>
        (d4) e820 map has 6 items:<br>
        (d4)=A0=A0 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM<br>
        (d4)=A0=A0 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED<br>
        (d4)=A0=A0 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED<br>
        (d4)=A0=A0 3: 0000000000100000 - 0000000077fff000 =3D 1 RAM<br>
        (d4)=A0=A0 4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED<br>
        (d4)=A0=A0 5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED<br>
        (d4) enter handle_19:<br>
        (d4)=A0=A0 NULL<br>
        (d4) Booting from DVD/CD...<br>
        (d4) Device reports MEDIUM NOT PRESENT<br>
        (d4) scsi_is_ready returned -1<br>
        (d4) Boot failed: Could not read from CDROM (code 0003)<br>
        (d4) enter handle_18:<br>
        (d4)=A0=A0 NULL<br>
        (d4) Booting from Hard Disk...<br>
        (d4) Booting from 0000:7c00<br>
        (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor:
        1 sp: 1 build: 1db1<br>
        (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff<br>
        (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe<br>
        (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd<br>
        (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -&gt; 0<br>
        (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -&gt; 0<br>
        (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -&gt; 0<br>
        (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -&gt; 0<br>
        <b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><b><br>
        </b><b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><br>
        (XEN) irq.c:380: Dom4 callback via changed to GSI 24<br>
        (XEN) HVM4 save: CPU<br>
        (XEN) HVM4 save: PIC<br>
        (XEN) HVM4 save: IOAPIC<br>
        (XEN) HVM4 save: LAPIC<br>
        (XEN) HVM4 save: LAPIC_REGS<br>
        (XEN) HVM4 save: PCI_IRQ<br>
        (XEN) HVM4 save: ISA_IRQ<br>
        (XEN) HVM4 save: PCI_LINK<br>
        (XEN) HVM4 save: PIT<br>
        (XEN) HVM4 save: RTC<br>
        (XEN) HVM4 save: HPET<br>
        (XEN) HVM4 save: PMTIMER<br>
        (XEN) HVM4 save: MTRR<br>
        (XEN) HVM4 save: VIRIDIAN_DOMAIN<br>
        (XEN) HVM4 save: CPU_XSAVE<br>
        (XEN) HVM4 save: VIRIDIAN_VCPU<br>
        (XEN) HVM4 save: VMCE_VCPU<br>
        (XEN) HVM4 save: TSC_ADJUST<br>
        (XEN) HVM5 restore: CPU 0<br>
        (XEN) HVM5 restore: CPU 1<br>
        (XEN) HVM5 restore: PIC 0<br>
        (XEN) HVM5 restore: PIC 1<br>
        (XEN) HVM5 restore: IOAPIC 0<br>
        (XEN) HVM5 restore: LAPIC 0<br>
        (XEN) HVM5 restore: LAPIC 1<br>
        (XEN) HVM5 restore: LAPIC_REGS 0<br>
        (XEN) HVM5 restore: LAPIC_REGS 1<br>
        (XEN) HVM5 restore: PCI_IRQ 0<br>
        (XEN) HVM5 restore: ISA_IRQ 0<br>
        (XEN) HVM5 restore: PCI_LINK 0<br>
        (XEN) HVM5 restore: PIT 0<br>
        (XEN) HVM5 restore: RTC 0<br>
        (XEN) HVM5 restore: HPET 0<br>
        (XEN) HVM5 restore: PMTIMER 0<br>
        (XEN) HVM5 restore: MTRR 0<br>
        (XEN) HVM5 restore: MTRR 1<br>
        (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0<br>
        (XEN) HVM5 restore: VIRIDIAN_VCPU 0<br>
        (XEN) HVM5 restore: VIRIDIAN_VCPU 1<br>
        (XEN) HVM5 restore: VMCE_VCPU 0<br>
        (XEN) HVM5 restore: VMCE_VCPU 1<br>
        (XEN) HVM5 restore: TSC_ADJUST 0<br>
        (XEN) HVM5 restore: TSC_ADJUST 1<br>
        (XEN) irq.c:380: Dom5 callback via changed to None<br>
        <b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
        </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
        </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
        </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><br>
        (XEN) irq.c:380: Dom5 callback via changed to GSI 24</blockquote>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------040209010902020805050608--


--===============1311755257024061390==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1311755257024061390==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 12:22:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 12:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XotPq-0000sH-L7; Thu, 13 Nov 2014 12:22:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XotPo-0000sC-LE
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 12:22:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	38/C7-24532-C72A4645; Thu, 13 Nov 2014 12:22:20 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415881337!12444672!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8361 invoked from network); 13 Nov 2014 12:22:17 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 12:22:17 -0000
Received: by mail-wg0-f54.google.com with SMTP id n12so16683380wgh.13
	for <xen-devel@lists.xensource.com>;
	Thu, 13 Nov 2014 04:22:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=LlXSvlvuneFyiebBo7gGR7pe2SM/bvnZDPBGxIyaWeQ=;
	b=WSiXFJFHJjjBJaazJlzRkxKPcn4WSEQgYbPLmHrbAHWndtHoeaBDVTrrXjEvnhgIKA
	H0WzRffzjpKjDWTEmIBAfDSVl9bZb9Ay2f2Lk4Gh0jn8u5Qqgtn2c6M0pcvgRNXXNHie
	q2h7j+AfcrUrN+sXeIu8aV2Y81zRoWSLYVqsZNW5wfm92sXDVSWvU5fAo68mb062cO/X
	1z3S0lTfXEmNTEXx0kL/f5GWD/TuRozhLONQ8ggFA9W7gsPuiKlRW9sXvlo/EYMaJXGS
	QfLlZPtXgHJdQ32FE7iblbMdst6/OEFa6r694ZIvoaJiSVUaEZi3YmFxFcLvwClOlgNS
	Yweg==
X-Gm-Message-State: ALoCoQlIEGoelOUv4sh9kjGbIpxedXeNEVH6Ox1piuvhjfTRRLclmJRKdzfuZD2VdFCYMJmn/7mv
X-Received: by 10.180.90.112 with SMTP id bv16mr3327698wib.53.1415881336709;
	Thu, 13 Nov 2014 04:22:16 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id cv7sm35351067wjc.3.2014.11.13.04.22.13
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 13 Nov 2014 04:22:15 -0800 (PST)
Message-ID: <5464A27D.4020107@m2r.biz>
Date: Thu, 13 Nov 2014 13:22:21 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <53BBA83C.3010307@m2r.biz>
	<1404809604.30343.5.camel@cihla.spice.brq.redhat.com>
	<53BBC2AA.4030503@m2r.biz> <53BBC952.1040902@m2r.biz>
	<54130761.6080501@m2r.biz> <541C2D39.1060607@m2r.biz>
	<54648477.5040505@m2r.biz>
In-Reply-To: <54648477.5040505@m2r.biz>
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [Spice-devel] screen freezed for 2-3 minutes on
 spice connect on xen windows 7 domU's with qxl after save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1311755257024061390=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============1311755257024061390==
Content-Type: multipart/alternative;
 boundary="------------040209010902020805050608"

This is a multi-part message in MIME format.
--------------040209010902020805050608
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Length: 15342
Content-Transfer-Encoding: quoted-printable

Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
> Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
>> Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
>>> Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
>>>> Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
>>>>> Il 08/07/2014 10:53, David Ja=9Aa ha scritto:
>>>>>> Hi,
>>>>>>
>>>>>> On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
>>>>>>> On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
>>>>>>> client with
>>>>>>> spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as kvm
>>>>>>> except for one problem after xl save/restore, when after restore on
>>>>>>> spice client connect  the domU's screen freezed for 2-3 minutes 
>>>>>>> (and
>>>>>>> seems also windows), after this time seems that all return to works
>>>>>>> correctly.
>>>>>>> This problem happen also if spice client connect long time after 
>>>>>>> restore.
>>>>>>> With stdvga not have this problem but stdvga has many missed 
>>>>>>> resolutions
>>>>>>> and bad refresh performance.
>>>>>>>
>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>> Client and server logs would certainly help. Please run:
>>>>>>    * virt-viewer with --spice-debug option
>>>>>>    * spice-server with SPICE_DEBUG_LEVEL environment variable set
>>>>>>      to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
>>>>>> http://libvirt.org/drvqemu.html#qemucommand )
>>>>>> and note the location in the logs where the freeze takes place.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> David
>>>>>
>>>>> Thanks for your reply, in attachments:
>>>>> - domU's xl cfg: W7.cfg
>>>>> - xl -vvv create/save/restore: xen logs.txt
>>>>> - remote-viewer with --spice-debug after domU's start until xl 
>>>>> save: spicelog-1.txt (zipped)
>>>>> - remote-viewer with --spice-debug after domU's xl restore: 
>>>>> spicelog-2.txt
>>>>
>>>> Sorry for my forgetfulness, here also qemu's log:
>>>> - after domU's start until xl save: qemu-dm-W7.log.1
>>>> - after domU's xl restore: qemu-dm-W7.log
>>>>
>>>>>
>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>
>>>>>
>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Spice-devel mailing list
>>>>>> Spice-devel@lists.freedesktop.org
>>>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>
>>>
>>> The problem persist, this time I saw these in xl dmesg after restore:
>>>
>>> (XEN) HVM2 restore: CPU 0
>>> (XEN) HVM2 restore: CPU 1
>>> (XEN) HVM2 restore: PIC 0
>>> (XEN) HVM2 restore: PIC 1
>>> (XEN) HVM2 restore: IOAPIC 0
>>> (XEN) HVM2 restore: LAPIC 0
>>> (XEN) HVM2 restore: LAPIC 1
>>> (XEN) HVM2 restore: LAPIC_REGS 0
>>> (XEN) HVM2 restore: LAPIC_REGS 1
>>> (XEN) HVM2 restore: PCI_IRQ 0
>>> (XEN) HVM2 restore: ISA_IRQ 0
>>> (XEN) HVM2 restore: PCI_LINK 0
>>> (XEN) HVM2 restore: PIT 0
>>> (XEN) HVM2 restore: RTC 0
>>> (XEN) HVM2 restore: HPET 0
>>> (XEN) HVM2 restore: PMTIMER 0
>>> (XEN) HVM2 restore: MTRR 0
>>> (XEN) HVM2 restore: MTRR 1
>>> (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 0
>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 1
>>> (XEN) HVM2 restore: VMCE_VCPU 0
>>> (XEN) HVM2 restore: VMCE_VCPU 1
>>> (XEN) HVM2 restore: TSC_ADJUST 0
>>> (XEN) HVM2 restore: TSC_ADJUST 1
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
>>> (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from (4) 
>>> to (32) frames.
>>> (XEN) irq.c:380: Dom2 callback via changed to GSI 24
>>>
>>> Tested on latest staging (commit 
>>> 7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:
>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>
>>> If you need more informations or tests tell me and I'll post them.
>>> Thanks for any reply and sorry for my bad english.
>>
>> I did another tests updating to latest git staging (commit 
>> 3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of 
>> "only" 2-3 minutes but now when it appears to restart (after 2-3 
>> minutes) windows domUs undefinitely hangs instead.
>> No further details in xen and domU's logs.
>>
>> If you need more tests/details tell me and I'll do them.
>>
>> Thanks for any reply.
>
> I did a new test with xen build based on tag 4.5.0-rc2 and on xl dmesg 
> show these errors:
>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
> Before and after save/restore, with stdvga instead not show them.

Sorry, I found that was introduced by new winpv drivers update instead 
and I solved applying this patch:
x86/hvm: Add per-vcpu evtchn upcalls v3 
http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html
About save/restore problem with qxl I still not found a solution or at 
least the exact cause :(

>
> Below I posted full xl dmesg of domU, if you need more 
> informations/tests tell me and I'll post them.
>
>
>> (d4) HVM Loader
>> (d4) Detected Xen v4.5.0-rc
>> (d4) Xenbus rings @0xfeffc000, event channel 1
>> (d4) System requested SeaBIOS
>> (d4) CPU speed is 2660 MHz
>> (d4) Relocating guest memory for lowmem MMIO space disabled
>> (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -> 5
>> (d4) PCI-ISA link 0 routed to IRQ5
>> (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -> 10
>> (d4) PCI-ISA link 1 routed to IRQ10
>> (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -> 11
>> (d4) PCI-ISA link 2 routed to IRQ11
>> (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -> 5
>> (d4) PCI-ISA link 3 routed to IRQ5
>> (d4) pci dev 01:3 INTA->IRQ10
>> (d4) pci dev 02:0 INTA->IRQ11
>> (d4) pci dev 03:0 INTA->IRQ5
>> (d4) pci dev 04:0 INTA->IRQ5
>> (d4) pci dev 05:0 INTA->IRQ10
>> (d4) pci dev 06:0 INTA->IRQ11
>> (d4) pci dev 1d:0 INTA->IRQ10
>> (d4) pci dev 1d:1 INTB->IRQ11
>> (d4) pci dev 1d:2 INTC->IRQ5
>> (d4) pci dev 1d:7 INTD->IRQ5
>> (d4) No RAM in high memory; setting high_mem resource base to 100000000
>> (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000
>> (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000
>> (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008
>> (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000
>> (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000
>> (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000
>> (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000
>> (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000
>> (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>> (d4) pci dev 02:0 bar 10 size 000000100: 00000c001
>> (d4) pci dev 06:0 bar 10 size 000000100: 00000c101
>> (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000
>> (d4) pci dev 04:0 bar 10 size 000000020: 00000c201
>> (d4) pci dev 05:0 bar 1c size 000000020: 00000c221
>> (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241
>> (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261
>> (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281
>> (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>> (d4) Multiprocessor initialisation:
>> (d4)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>> done.
>> (d4)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>> done.
>> (d4) Testing HVM environment:
>> (d4)  - REP INSB across page boundaries ... passed
>> (d4)  - GS base MSRs and SWAPGS ... passed
>> (d4) Passed 2 of 2 tests
>> (d4) Writing SMBIOS tables ...
>> (d4) Loading SeaBIOS ...
>> (d4) Creating MP tables ...
>> (d4) Loading ACPI ...
>> (d4) S3 disabled
>> (d4) S4 disabled
>> (d4) vm86 TSS at fc00a100
>> (d4) BIOS map:
>> (d4)  10000-100d3: Scratch space
>> (d4)  c0000-fffff: Main BIOS
>> (d4) E820 table:
>> (d4)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>> (d4)  HOLE: 00000000:000a0000 - 00000000:000c0000
>> (d4)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>> (d4)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>> (d4)  HOLE: 00000000:78000000 - 00000000:fc000000
>> (d4)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>> (d4) Invoking SeaBIOS ...
>> (d4) SeaBIOS (version 
>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>> (d4)
>> (d4) Found Xen hypervisor signature at 40000100
>> (d4) Running on QEMU (i440fx)
>> (d4) xen: copy e820...
>> (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>> (d4) CPU Mhz=3D2661
>> (d4) Found 13 PCI devices (max PCI bus is 00)
>> (d4) Allocated Xen hypercall page at 77fff000
>> (d4) Detected Xen v4.5.0-rc
>> (d4) xen: copy BIOS tables...
>> (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>> (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>> (d4) Copying PIR from 0x00010030 to 0x000f0dc0
>> (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>> (d4) Using pmtimer, ioport 0xb008
>> (d4) Scan for VGA option rom
>> (d4) Running option rom at c000:0003
>> (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes
>> (d4) pmm call arg1=3D0
>> (d4) Turning on vga text mode console
>> (d4) SeaBIOS (version 
>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>> (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838
>> (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)
>> (d4) Found 0 lpt ports
>> (d4) Found 0 serial ports
>> (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>> (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>> (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)
>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>> (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
>> (d4) UHCI init on dev 00:1d.0 (io=3Dc240)
>> (d4) UHCI init on dev 00:1d.1 (io=3Dc260)
>> (d4) UHCI init on dev 00:1d.2 (io=3Dc280)
>> (d4) PS2 keyboard initialized
>> (d4) All threads complete.
>> (d4) Scan for option roms
>> (d4) Running option rom at c980:0003
>> (d4) pmm call arg1=3D1
>> (d4) pmm call arg1=3D0
>> (d4) pmm call arg1=3D1
>> (d4) pmm call arg1=3D0
>> (d4) Searching bootorder for: /pci@i0cf8/*@6
>> (d4)
>> (d4) Press F12 for boot menu.
>> (d4)
>> (d4) Searching bootorder for: HALT
>> (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba 
>> LCHS=3D1024/255/63 s=3D102400000
>> (d4)
>> (d4) Space available for UMB: ca800-ee800, f0000-f0ce0
>> (d4) Returned 258048 bytes of ZoneHigh
>> (d4) e820 map has 6 items:
>> (d4)   0: 0000000000000000 - 000000000009fc00 =3D 1 RAM
>> (d4)   1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED
>> (d4)   2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED
>> (d4)   3: 0000000000100000 - 0000000077fff000 =3D 1 RAM
>> (d4)   4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED
>> (d4)   5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED
>> (d4) enter handle_19:
>> (d4)   NULL
>> (d4) Booting from DVD/CD...
>> (d4) Device reports MEDIUM NOT PRESENT
>> (d4) scsi_is_ready returned -1
>> (d4) Boot failed: Could not read from CDROM (code 0003)
>> (d4) enter handle_18:
>> (d4)   NULL
>> (d4) Booting from Hard Disk...
>> (d4) Booting from 0000:7c00
>> (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 
>> 1 build: 1db1
>> (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
>> (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
>> (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
>> (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -> 0
>> (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -> 0
>> (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -> 0
>> (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -> 0
>> *(XEN) hvm.c:6119:d4v1 Bad HVM op 23.**
>> **(XEN) hvm.c:6119:d4v1 Bad HVM op 23.*
>> (XEN) irq.c:380: Dom4 callback via changed to GSI 24
>> (XEN) HVM4 save: CPU
>> (XEN) HVM4 save: PIC
>> (XEN) HVM4 save: IOAPIC
>> (XEN) HVM4 save: LAPIC
>> (XEN) HVM4 save: LAPIC_REGS
>> (XEN) HVM4 save: PCI_IRQ
>> (XEN) HVM4 save: ISA_IRQ
>> (XEN) HVM4 save: PCI_LINK
>> (XEN) HVM4 save: PIT
>> (XEN) HVM4 save: RTC
>> (XEN) HVM4 save: HPET
>> (XEN) HVM4 save: PMTIMER
>> (XEN) HVM4 save: MTRR
>> (XEN) HVM4 save: VIRIDIAN_DOMAIN
>> (XEN) HVM4 save: CPU_XSAVE
>> (XEN) HVM4 save: VIRIDIAN_VCPU
>> (XEN) HVM4 save: VMCE_VCPU
>> (XEN) HVM4 save: TSC_ADJUST
>> (XEN) HVM5 restore: CPU 0
>> (XEN) HVM5 restore: CPU 1
>> (XEN) HVM5 restore: PIC 0
>> (XEN) HVM5 restore: PIC 1
>> (XEN) HVM5 restore: IOAPIC 0
>> (XEN) HVM5 restore: LAPIC 0
>> (XEN) HVM5 restore: LAPIC 1
>> (XEN) HVM5 restore: LAPIC_REGS 0
>> (XEN) HVM5 restore: LAPIC_REGS 1
>> (XEN) HVM5 restore: PCI_IRQ 0
>> (XEN) HVM5 restore: ISA_IRQ 0
>> (XEN) HVM5 restore: PCI_LINK 0
>> (XEN) HVM5 restore: PIT 0
>> (XEN) HVM5 restore: RTC 0
>> (XEN) HVM5 restore: HPET 0
>> (XEN) HVM5 restore: PMTIMER 0
>> (XEN) HVM5 restore: MTRR 0
>> (XEN) HVM5 restore: MTRR 1
>> (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0
>> (XEN) HVM5 restore: VIRIDIAN_VCPU 0
>> (XEN) HVM5 restore: VIRIDIAN_VCPU 1
>> (XEN) HVM5 restore: VMCE_VCPU 0
>> (XEN) HVM5 restore: VMCE_VCPU 1
>> (XEN) HVM5 restore: TSC_ADJUST 0
>> (XEN) HVM5 restore: TSC_ADJUST 1
>> (XEN) irq.c:380: Dom5 callback via changed to None
>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>> (XEN) irq.c:380: Dom5 callback via changed to GSI 24
>
>


--------------040209010902020805050608
Content-Type: text/html; charset=windows-1252
Content-Length: 21171
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Il 13/11/2014 11:14, Fabio Fantoni ha
      scritto:<br>
    </div>
    <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite">
      <meta content=3D"text/html; charset=3Dwindows-1252"
        http-equiv=3D"Content-Type">
      <div class=3D"moz-cite-prefix">Il 19/09/2014 15:18, Fabio Fantoni ha
        scritto:<br>
      </div>
      <blockquote cite=3D"mid:541C2D39.1060607@m2r.biz" type=3D"cite">Il
        12/09/2014 16:46, Fabio Fantoni ha scritto: <br>
        <blockquote type=3D"cite">Il 08/07/2014 12:34, Fabio Fantoni ha
          scritto: <br>
          <blockquote type=3D"cite">Il 08/07/2014 12:06, Fabio Fantoni ha
            scritto: <br>
            <blockquote type=3D"cite">Il 08/07/2014 10:53, David Ja=9Aa ha
              scritto: <br>
              <blockquote type=3D"cite">Hi, <br>
                <br>
                On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote: <br>
                <blockquote type=3D"cite">On xen 4.5 (tried with qemu
                  2.0.0/2.1-rc0, spice 0.12.5 and client with <br>
                  spice-gtk 0.23/0.25) windows 7 domUs with qxl vga
                  works good as kvm <br>
                  except for one problem after xl save/restore, when
                  after restore on <br>
                  spice client connect=A0 the domU's screen freezed for
                  2-3 minutes (and <br>
                  seems also windows), after this time seems that all
                  return to works <br>
                  correctly. <br>
                  This problem happen also if spice client connect long
                  time after restore. <br>
                  With stdvga not have this problem but stdvga has many
                  missed resolutions <br>
                  and bad refresh performance. <br>
                  <br>
                  If you need more tests/informations tell me and I'll
                  post them. <br>
                </blockquote>
                Client and server logs would certainly help. Please run:
                <br>
                =A0=A0 * virt-viewer with --spice-debug option <br>
                =A0=A0 * spice-server with SPICE_DEBUG_LEVEL environment
                variable set <br>
                =A0=A0=A0=A0 to 4 or 5 (if you use qemu+libvirt, use qemu:env
                element: <br>
                =A0=A0=A0=A0 <a moz-do-not-send=3D"true"
                  class=3D"moz-txt-link-freetext"
                  href=3D"http://libvirt.org/drvqemu.html#qemucommand">http://libvirt.org/drvqemu.html#qemucommand</a>
                ) <br>
                and note the location in the logs where the freeze takes
                place. <br>
                <br>
                Regards, <br>
                <br>
                David <br>
              </blockquote>
              <br>
              Thanks for your reply, in attachments: <br>
              - domU's xl cfg: W7.cfg <br>
              - xl -vvv create/save/restore: xen logs.txt <br>
              - remote-viewer with --spice-debug after domU's start
              until xl save: spicelog-1.txt (zipped) <br>
              - remote-viewer with --spice-debug after domU's xl
              restore: spicelog-2.txt <br>
            </blockquote>
            <br>
            Sorry for my forgetfulness, here also qemu's log: <br>
            - after domU's start until xl save: qemu-dm-W7.log.1 <br>
            - after domU's xl restore: qemu-dm-W7.log <br>
            <br>
            <blockquote type=3D"cite"> <br>
              If you need more tests/informations tell me and I'll post
              them. <br>
              <br>
              <br>
              <blockquote type=3D"cite">Thanks for any reply and sorry for
                my bad english. <br>
                <br>
                _______________________________________________ <br>
                Spice-devel mailing list <br>
                <a moz-do-not-send=3D"true"
                  class=3D"moz-txt-link-abbreviated"
                  href=3D"mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a>
                <br>
                <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
href=3D"http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a>
                <br>
              </blockquote>
            </blockquote>
            <br>
          </blockquote>
          <br>
          The problem persist, this time I saw these in xl dmesg after
          restore: <br>
          <br>
          (XEN) HVM2 restore: CPU 0 <br>
          (XEN) HVM2 restore: CPU 1 <br>
          (XEN) HVM2 restore: PIC 0 <br>
          (XEN) HVM2 restore: PIC 1 <br>
          (XEN) HVM2 restore: IOAPIC 0 <br>
          (XEN) HVM2 restore: LAPIC 0 <br>
          (XEN) HVM2 restore: LAPIC 1 <br>
          (XEN) HVM2 restore: LAPIC_REGS 0 <br>
          (XEN) HVM2 restore: LAPIC_REGS 1 <br>
          (XEN) HVM2 restore: PCI_IRQ 0 <br>
          (XEN) HVM2 restore: ISA_IRQ 0 <br>
          (XEN) HVM2 restore: PCI_LINK 0 <br>
          (XEN) HVM2 restore: PIT 0 <br>
          (XEN) HVM2 restore: RTC 0 <br>
          (XEN) HVM2 restore: HPET 0 <br>
          (XEN) HVM2 restore: PMTIMER 0 <br>
          (XEN) HVM2 restore: MTRR 0 <br>
          (XEN) HVM2 restore: MTRR 1 <br>
          (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0 <br>
          (XEN) HVM2 restore: VIRIDIAN_VCPU 0 <br>
          (XEN) HVM2 restore: VIRIDIAN_VCPU 1 <br>
          (XEN) HVM2 restore: VMCE_VCPU 0 <br>
          (XEN) HVM2 restore: VMCE_VCPU 1 <br>
          (XEN) HVM2 restore: TSC_ADJUST 0 <br>
          (XEN) HVM2 restore: TSC_ADJUST 1 <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid <br>
          (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid <br>
          (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table
          from (4) to (32) frames. <br>
          (XEN) irq.c:380: Dom2 callback via changed to GSI 24 <br>
          <br>
          Tested on latest staging (commit
          7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice
          patches: <br>
          <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
            href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a>
          <br>
          <br>
          If you need more informations or tests tell me and I'll post
          them. <br>
          Thanks for any reply and sorry for my bad english. <br>
        </blockquote>
        <br>
        I did another tests updating to latest git staging (commit
        3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem
        of "only" 2-3 minutes but now when it appears to restart (after
        2-3 minutes) windows domUs undefinitely hangs instead. <br>
        No further details in xen and domU's logs. <br>
        <br>
        If you need more tests/details tell me and I'll do them. <br>
        <br>
        Thanks for any reply. <br>
      </blockquote>
      <br>
      I did a new test with xen build based on tag 4.5.0-rc2 and on xl
      dmesg show these errors:<br>
      <blockquote type=3D"cite"><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b></blockquote>
      Before and after save/restore, with stdvga instead not show them.<br>
    </blockquote>
    <br>
    Sorry, I found that was introduced by new winpv drivers update
    instead and I solved applying this patch:<br>
    x86/hvm: Add per-vcpu evtchn upcalls v3
    <a class=3D"moz-txt-link-freetext" href=3D"http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html">http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html</a><br>
    About save/restore problem with qxl I still not found a solution or
    at least the exact cause :(<br>
    <br>
    <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite"> <br>
      Below I posted full xl dmesg of domU, if you need more
      informations/tests tell me and I'll post them.<br>
      <br>
      <br>
      <blockquote type=3D"cite">(d4) HVM Loader<br>
        (d4) Detected Xen v4.5.0-rc<br>
        (d4) Xenbus rings @0xfeffc000, event channel 1<br>
        (d4) System requested SeaBIOS<br>
        (d4) CPU speed is 2660 MHz<br>
        (d4) Relocating guest memory for lowmem MMIO space disabled<br>
        (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -&gt; 5<br>
        (d4) PCI-ISA link 0 routed to IRQ5<br>
        (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -&gt; 10<br>
        (d4) PCI-ISA link 1 routed to IRQ10<br>
        (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -&gt; 11<br>
        (d4) PCI-ISA link 2 routed to IRQ11<br>
        (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -&gt; 5<br>
        (d4) PCI-ISA link 3 routed to IRQ5<br>
        (d4) pci dev 01:3 INTA-&gt;IRQ10<br>
        (d4) pci dev 02:0 INTA-&gt;IRQ11<br>
        (d4) pci dev 03:0 INTA-&gt;IRQ5<br>
        (d4) pci dev 04:0 INTA-&gt;IRQ5<br>
        (d4) pci dev 05:0 INTA-&gt;IRQ10<br>
        (d4) pci dev 06:0 INTA-&gt;IRQ11<br>
        (d4) pci dev 1d:0 INTA-&gt;IRQ10<br>
        (d4) pci dev 1d:1 INTB-&gt;IRQ11<br>
        (d4) pci dev 1d:2 INTC-&gt;IRQ5<br>
        (d4) pci dev 1d:7 INTD-&gt;IRQ5<br>
        (d4) No RAM in high memory; setting high_mem resource base to
        100000000<br>
        (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000<br>
        (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000<br>
        (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008<br>
        (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000<br>
        (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000<br>
        (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000<br>
        (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000<br>
        (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000<br>
        (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000<br>
        (d4) pci dev 02:0 bar 10 size 000000100: 00000c001<br>
        (d4) pci dev 06:0 bar 10 size 000000100: 00000c101<br>
        (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000<br>
        (d4) pci dev 04:0 bar 10 size 000000020: 00000c201<br>
        (d4) pci dev 05:0 bar 1c size 000000020: 00000c221<br>
        (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241<br>
        (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261<br>
        (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281<br>
        (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1<br>
        (d4) Multiprocessor initialisation:<br>
        (d4)=A0 - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
        ... done.<br>
        (d4)=A0 - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
        ... done.<br>
        (d4) Testing HVM environment:<br>
        (d4)=A0 - REP INSB across page boundaries ... passed<br>
        (d4)=A0 - GS base MSRs and SWAPGS ... passed<br>
        (d4) Passed 2 of 2 tests<br>
        (d4) Writing SMBIOS tables ...<br>
        (d4) Loading SeaBIOS ...<br>
        (d4) Creating MP tables ...<br>
        (d4) Loading ACPI ...<br>
        (d4) S3 disabled<br>
        (d4) S4 disabled<br>
        (d4) vm86 TSS at fc00a100<br>
        (d4) BIOS map:<br>
        (d4)=A0 10000-100d3: Scratch space<br>
        (d4)=A0 c0000-fffff: Main BIOS<br>
        (d4) E820 table:<br>
        (d4)=A0 [00]: 00000000:00000000 - 00000000:000a0000: RAM<br>
        (d4)=A0 HOLE: 00000000:000a0000 - 00000000:000c0000<br>
        (d4)=A0 [01]: 00000000:000c0000 - 00000000:00100000: RESERVED<br>
        (d4)=A0 [02]: 00000000:00100000 - 00000000:78000000: RAM<br>
        (d4)=A0 HOLE: 00000000:78000000 - 00000000:fc000000<br>
        (d4)=A0 [03]: 00000000:fc000000 - 00000001:00000000: RESERVED<br>
        (d4) Invoking SeaBIOS ...<br>
        (d4) SeaBIOS (version
        debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
        (d4) <br>
        (d4) Found Xen hypervisor signature at 40000100<br>
        (d4) Running on QEMU (i440fx)<br>
        (d4) xen: copy e820...<br>
        (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)<br>
        (d4) CPU Mhz=3D2661<br>
        (d4) Found 13 PCI devices (max PCI bus is 00)<br>
        (d4) Allocated Xen hypercall page at 77fff000<br>
        (d4) Detected Xen v4.5.0-rc<br>
        (d4) xen: copy BIOS tables...<br>
        (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40<br>
        (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40<br>
        (d4) Copying PIR from 0x00010030 to 0x000f0dc0<br>
        (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90<br>
        (d4) Using pmtimer, ioport 0xb008<br>
        (d4) Scan for VGA option rom<br>
        (d4) Running option rom at c000:0003<br>
        (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes<br>
        (d4) pmm call arg1=3D0<br>
        (d4) Turning on vga text mode console<br>
        (d4) SeaBIOS (version
        debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
        (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838<br>
        (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)<br>
        (d4) Found 0 lpt ports<br>
        (d4) Found 0 serial ports<br>
        (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)<br>
        (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)<br>
        (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)<br>
        (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0<br>
        (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]<br>
        (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1<br>
        (d4) UHCI init on dev 00:1d.0 (io=3Dc240)<br>
        (d4) UHCI init on dev 00:1d.1 (io=3Dc260)<br>
        (d4) UHCI init on dev 00:1d.2 (io=3Dc280)<br>
        (d4) PS2 keyboard initialized<br>
        (d4) All threads complete.<br>
        (d4) Scan for option roms<br>
        (d4) Running option rom at c980:0003<br>
        (d4) pmm call arg1=3D1<br>
        (d4) pmm call arg1=3D0<br>
        (d4) pmm call arg1=3D1<br>
        (d4) pmm call arg1=3D0<br>
        (d4) Searching bootorder for: /pci@i0cf8/*@6<br>
        (d4) <br>
        (d4) Press F12 for boot menu.<br>
        (d4) <br>
        (d4) Searching bootorder for: HALT<br>
        (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba
        LCHS=3D1024/255/63 s=3D102400000<br>
        (d4) <br>
        (d4) Space available for UMB: ca800-ee800, f0000-f0ce0<br>
        (d4) Returned 258048 bytes of ZoneHigh<br>
        (d4) e820 map has 6 items:<br>
        (d4)=A0=A0 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM<br>
        (d4)=A0=A0 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED<br>
        (d4)=A0=A0 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED<br>
        (d4)=A0=A0 3: 0000000000100000 - 0000000077fff000 =3D 1 RAM<br>
        (d4)=A0=A0 4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED<br>
        (d4)=A0=A0 5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED<br>
        (d4) enter handle_19:<br>
        (d4)=A0=A0 NULL<br>
        (d4) Booting from DVD/CD...<br>
        (d4) Device reports MEDIUM NOT PRESENT<br>
        (d4) scsi_is_ready returned -1<br>
        (d4) Boot failed: Could not read from CDROM (code 0003)<br>
        (d4) enter handle_18:<br>
        (d4)=A0=A0 NULL<br>
        (d4) Booting from Hard Disk...<br>
        (d4) Booting from 0000:7c00<br>
        (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor:
        1 sp: 1 build: 1db1<br>
        (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff<br>
        (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe<br>
        (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd<br>
        (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -&gt; 0<br>
        (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -&gt; 0<br>
        (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -&gt; 0<br>
        (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -&gt; 0<br>
        <b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><b><br>
        </b><b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><br>
        (XEN) irq.c:380: Dom4 callback via changed to GSI 24<br>
        (XEN) HVM4 save: CPU<br>
        (XEN) HVM4 save: PIC<br>
        (XEN) HVM4 save: IOAPIC<br>
        (XEN) HVM4 save: LAPIC<br>
        (XEN) HVM4 save: LAPIC_REGS<br>
        (XEN) HVM4 save: PCI_IRQ<br>
        (XEN) HVM4 save: ISA_IRQ<br>
        (XEN) HVM4 save: PCI_LINK<br>
        (XEN) HVM4 save: PIT<br>
        (XEN) HVM4 save: RTC<br>
        (XEN) HVM4 save: HPET<br>
        (XEN) HVM4 save: PMTIMER<br>
        (XEN) HVM4 save: MTRR<br>
        (XEN) HVM4 save: VIRIDIAN_DOMAIN<br>
        (XEN) HVM4 save: CPU_XSAVE<br>
        (XEN) HVM4 save: VIRIDIAN_VCPU<br>
        (XEN) HVM4 save: VMCE_VCPU<br>
        (XEN) HVM4 save: TSC_ADJUST<br>
        (XEN) HVM5 restore: CPU 0<br>
        (XEN) HVM5 restore: CPU 1<br>
        (XEN) HVM5 restore: PIC 0<br>
        (XEN) HVM5 restore: PIC 1<br>
        (XEN) HVM5 restore: IOAPIC 0<br>
        (XEN) HVM5 restore: LAPIC 0<br>
        (XEN) HVM5 restore: LAPIC 1<br>
        (XEN) HVM5 restore: LAPIC_REGS 0<br>
        (XEN) HVM5 restore: LAPIC_REGS 1<br>
        (XEN) HVM5 restore: PCI_IRQ 0<br>
        (XEN) HVM5 restore: ISA_IRQ 0<br>
        (XEN) HVM5 restore: PCI_LINK 0<br>
        (XEN) HVM5 restore: PIT 0<br>
        (XEN) HVM5 restore: RTC 0<br>
        (XEN) HVM5 restore: HPET 0<br>
        (XEN) HVM5 restore: PMTIMER 0<br>
        (XEN) HVM5 restore: MTRR 0<br>
        (XEN) HVM5 restore: MTRR 1<br>
        (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0<br>
        (XEN) HVM5 restore: VIRIDIAN_VCPU 0<br>
        (XEN) HVM5 restore: VIRIDIAN_VCPU 1<br>
        (XEN) HVM5 restore: VMCE_VCPU 0<br>
        (XEN) HVM5 restore: VMCE_VCPU 1<br>
        (XEN) HVM5 restore: TSC_ADJUST 0<br>
        (XEN) HVM5 restore: TSC_ADJUST 1<br>
        (XEN) irq.c:380: Dom5 callback via changed to None<br>
        <b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
        </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
        </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
        </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><br>
        (XEN) irq.c:380: Dom5 callback via changed to GSI 24</blockquote>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------040209010902020805050608--


--===============1311755257024061390==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1311755257024061390==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 13:07:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 13: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 1Xou7d-0001yb-Qv; Thu, 13 Nov 2014 13:07:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xou7d-0001yW-0a
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 13:07:37 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	E3/71-02953-81DA4645; Thu, 13 Nov 2014 13:07:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415884054!12308145!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10428 invoked from network); 13 Nov 2014 13:07:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 13:07:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,377,1413244800"; d="scan'208";a="190925418"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 08:06:26 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xou6U-0001m5-7b;
	Thu, 13 Nov 2014 13:06:26 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xou6R-0000W3-Hi;
	Thu, 13 Nov 2014 13:06:25 +0000
Date: Thu, 13 Nov 2014 13:06:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31520-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31520: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31520 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31520/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 26261
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 13:07:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 13: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 1Xou7d-0001yb-Qv; Thu, 13 Nov 2014 13:07:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xou7d-0001yW-0a
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 13:07:37 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	E3/71-02953-81DA4645; Thu, 13 Nov 2014 13:07:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415884054!12308145!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10428 invoked from network); 13 Nov 2014 13:07:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 13:07:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,377,1413244800"; d="scan'208";a="190925418"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 08:06:26 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xou6U-0001m5-7b;
	Thu, 13 Nov 2014 13:06:26 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xou6R-0000W3-Hi;
	Thu, 13 Nov 2014 13:06:25 +0000
Date: Thu, 13 Nov 2014 13:06:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31520-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31520: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31520 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31520/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 26261
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 13:29:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 13:29:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XouSj-0002St-Pf; Thu, 13 Nov 2014 13:29:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1XouSi-0002So-9b
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 13:29:24 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	AF/CA-05632-332B4645; Thu, 13 Nov 2014 13:29:23 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415885362!11135052!1
X-Originating-IP: [209.85.216.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3118 invoked from network); 13 Nov 2014 13:29:22 -0000
Received: from mail-qc0-f179.google.com (HELO mail-qc0-f179.google.com)
	(209.85.216.179)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 13:29:22 -0000
Received: by mail-qc0-f179.google.com with SMTP id c9so479858qcz.24
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 05:29:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:subject:mime-version:content-type
	:content-transfer-encoding;
	bh=paURJYx63se1O2c5CJnu1YXoQ/F/xylyHVEBGLapLcM=;
	b=cm90OGn6xtgjOz3H1nbXbgvA60X7AFsjjVrQt3LEyqwiQlRMLBUDbsMxrjyBNGrVE3
	SCW+fOJCRe1p7FI2xxZF21XdMqEnjjNb1FRs6zk57DYnQmvDxQsLuDl8mbAL1784H44v
	0BWgbY6n39uInOcV/nlvmgQANmcoOqecJVdf6Suw5f6SVq9229IRmlC/2xKBR7AOSR1U
	kp+wynmFmI4pKaGZVyQrhj6yprvVu44mG/+dXLn4AkLloRvBqFrf7BDfqE5J01lG5qlP
	UXHAWoMoMDMUfTaHQSl+Q50HIqftDZFv/b1IalZeturD0v+VGNvyfgfr5TDo4L/1/HAp
	0yhg==
X-Received: by 10.140.19.9 with SMTP id 9mr3124105qgg.98.1415885359807;
	Thu, 13 Nov 2014 05:29:19 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.139.66])
	by mx.google.com with ESMTPSA id
	g93sm23918156qgg.48.2014.11.13.05.29.18 for <xen-devel@lists.xen.org>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Thu, 13 Nov 2014 05:29:19 -0800 (PST)
Date: Thu, 13 Nov 2014 10:29:21 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <198478230.20141113102921@gmail.com>
To: xen-devel@lists.xen.org
MIME-Version: 1.0
Subject: [Xen-devel] Problems accessing passthrough PCI 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

Hi all,

I am back on my virtual machine once again and have run into a bit of
a problem (once again). So I am coming to you cap in hand...

I am having 2 major problems at the moment.

1.- Access to the PCI device from the PV will fail the second time I
create it UNLESS I call xl pci-assignable-remove/pci-assignable-add
between each creation. If I don't do this then all PCI accesses return
-1. I get the same if I disable memory access in the PCI configuration
register.

1.1.- Is this expected behaviour?

1.2.-   If   not,   how  do  I  work  around  it?  I  have  looked  at
HYPERVISOR_physdev_op but I'm not sure how/whether to use it.

1.3.-  xl  dmesg  and  dmesg  in Dom0 do not show anything. I have set
loglvl=all in the Xen command line.

2.-  Whenever  I  perform a software reset on the PCI device (it is an
Intel  82546  Ethernet  NIC) the hypervisor crashes. There is no oops,
kernel  panic  or the like, just a crash. My development device has no
serial port so I can't do much debugging.

Any suggestions.


-- 
Best regards,
 Simon                          mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 13:29:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 13:29:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XouSj-0002St-Pf; Thu, 13 Nov 2014 13:29:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1XouSi-0002So-9b
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 13:29:24 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	AF/CA-05632-332B4645; Thu, 13 Nov 2014 13:29:23 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415885362!11135052!1
X-Originating-IP: [209.85.216.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3118 invoked from network); 13 Nov 2014 13:29:22 -0000
Received: from mail-qc0-f179.google.com (HELO mail-qc0-f179.google.com)
	(209.85.216.179)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 13:29:22 -0000
Received: by mail-qc0-f179.google.com with SMTP id c9so479858qcz.24
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 05:29:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:subject:mime-version:content-type
	:content-transfer-encoding;
	bh=paURJYx63se1O2c5CJnu1YXoQ/F/xylyHVEBGLapLcM=;
	b=cm90OGn6xtgjOz3H1nbXbgvA60X7AFsjjVrQt3LEyqwiQlRMLBUDbsMxrjyBNGrVE3
	SCW+fOJCRe1p7FI2xxZF21XdMqEnjjNb1FRs6zk57DYnQmvDxQsLuDl8mbAL1784H44v
	0BWgbY6n39uInOcV/nlvmgQANmcoOqecJVdf6Suw5f6SVq9229IRmlC/2xKBR7AOSR1U
	kp+wynmFmI4pKaGZVyQrhj6yprvVu44mG/+dXLn4AkLloRvBqFrf7BDfqE5J01lG5qlP
	UXHAWoMoMDMUfTaHQSl+Q50HIqftDZFv/b1IalZeturD0v+VGNvyfgfr5TDo4L/1/HAp
	0yhg==
X-Received: by 10.140.19.9 with SMTP id 9mr3124105qgg.98.1415885359807;
	Thu, 13 Nov 2014 05:29:19 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.139.66])
	by mx.google.com with ESMTPSA id
	g93sm23918156qgg.48.2014.11.13.05.29.18 for <xen-devel@lists.xen.org>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Thu, 13 Nov 2014 05:29:19 -0800 (PST)
Date: Thu, 13 Nov 2014 10:29:21 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <198478230.20141113102921@gmail.com>
To: xen-devel@lists.xen.org
MIME-Version: 1.0
Subject: [Xen-devel] Problems accessing passthrough PCI 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

Hi all,

I am back on my virtual machine once again and have run into a bit of
a problem (once again). So I am coming to you cap in hand...

I am having 2 major problems at the moment.

1.- Access to the PCI device from the PV will fail the second time I
create it UNLESS I call xl pci-assignable-remove/pci-assignable-add
between each creation. If I don't do this then all PCI accesses return
-1. I get the same if I disable memory access in the PCI configuration
register.

1.1.- Is this expected behaviour?

1.2.-   If   not,   how  do  I  work  around  it?  I  have  looked  at
HYPERVISOR_physdev_op but I'm not sure how/whether to use it.

1.3.-  xl  dmesg  and  dmesg  in Dom0 do not show anything. I have set
loglvl=all in the Xen command line.

2.-  Whenever  I  perform a software reset on the PCI device (it is an
Intel  82546  Ethernet  NIC) the hypervisor crashes. There is no oops,
kernel  panic  or the like, just a crash. My development device has no
serial port so I can't do much debugging.

Any suggestions.


-- 
Best regards,
 Simon                          mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 13:53:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 13: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 1XoupL-000382-Jv; Thu, 13 Nov 2014 13:52:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoupK-00037x-9S
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 13:52:46 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	3F/4B-05632-DA7B4645; Thu, 13 Nov 2014 13:52:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415886763!11141914!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11145 invoked from network); 13 Nov 2014 13:52:44 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 13:52:44 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADDqSxI001973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 13:52:29 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADDqQF7009166
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Nov 2014 13:52:27 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sADDqPY3011894; Thu, 13 Nov 2014 13:52:25 GMT
Received: from [IPv6:2607:fb90:e19:ec57:2be0:9f26:3b5c:68f4] (/172.56.23.242)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 05:52:24 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <546476AE.9080207@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-7-git-send-email-jgross@suse.com>
	<20141112221813.GE7549@laptop.dumpdata.com>
	<546476AE.9080207@suse.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 13 Nov 2014 08:51:59 -0500
To: Juergen Gross <jgross@suse.com>
Message-ID: <F820B37E-953B-4904-9E9B-6D32BA989F29@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 6/8] xen: Hide get_phys_to_machine() to
	be able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 13, 2014 4:15:26 AM EST, Juergen Gross <jgross@suse.com> wrote:
>On 11/12/2014 11:18 PM, Konrad Rzeszutek Wilk wrote:
>> On Tue, Nov 11, 2014 at 06:43:44AM +0100, Juergen Gross wrote:
>>> Today get_phys_to_machine() is always called when the mfn for a pfn
>>> is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
>>> to be able to avoid calling get_phys_to_machine() when possible as
>>
>> s/when/where/
>
>No. It's not a matter of the caller, but of the p2m list entry.
>
>>> soon as the switch to a linear mapped p2m list has been done.
>>
>> But your inline function still calls get_phys_to_machine?
>
>Sure. The switch is done in the next patch. David asked me to split
>the patch doing the preparation by adding __pfn_tom_mfn() in an own
>patch.
>
>>
>>
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>>   arch/x86/include/asm/xen/page.h | 27 +++++++++++++++++++++------
>>>   arch/x86/xen/mmu.c              |  2 +-
>>>   arch/x86/xen/p2m.c              |  6 +++---
>>>   3 files changed, 25 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/x86/include/asm/xen/page.h
>b/arch/x86/include/asm/xen/page.h
>>> index 28fa795..07d8a7b 100644
>>> --- a/arch/x86/include/asm/xen/page.h
>>> +++ b/arch/x86/include/asm/xen/page.h
>>> @@ -59,6 +59,22 @@ extern int clear_foreign_p2m_mapping(struct
>gnttab_unmap_grant_ref *unmap_ops,
>>>   				     struct page **pages, unsigned int count);
>>>   extern unsigned long m2p_find_override_pfn(unsigned long mfn,
>unsigned long pfn);
>>>
>>> +/*
>>> + * When to use pfn_to_mfn(), __pfn_to_mfn() or
>get_phys_to_machine():
>>> + * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. In
>case of an
>>> + *   identity entry the identity indicator will be cleared.
>>
>> Why don't you say : In case of identity PFN the same PFN is returned.
>>
>> But you did miss that also the FOREIGN_FRAME_BIT is cleared.
>
>I'll reword the comment.
>
>>
>>> + * - __pfn_to_mfn() returns the found entry of the p2m table. A
>possibly set
>>
>> s/of the/in the/
>>> + *   identity indicator will be still set. __pfn_to_mfn() is
>encapsulating
>> .. be still set if the PFN is an identity one.
>>> + *   get_phys_to_machine() and might skip that function if possible
>to speed
>>> + *   up the common path.
>>
>> How is is skipping that function? The patch below does no such thing?
>
>The next patch in this series does.

Then this should be part of the next patch
>
>>
>>> + * - get_phys_to_machine() is basically the same as __pfn_to_mfn(),
>but
>>> + *   without any short cuts for the common fast path.
>>
>> Right. Perhpas we should call it 'slow_p2m' instead of the
>'get_phys_to_machine'.
>
>That's a matter of taste, I think. I can change it if nobody else
>objects.
>

That would need to be a separate patch if we wanted to go that route.

>
>Juergen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 13:53:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 13: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 1XoupL-000382-Jv; Thu, 13 Nov 2014 13:52:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XoupK-00037x-9S
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 13:52:46 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	3F/4B-05632-DA7B4645; Thu, 13 Nov 2014 13:52:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415886763!11141914!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11145 invoked from network); 13 Nov 2014 13:52:44 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 13:52:44 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADDqSxI001973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 13:52:29 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADDqQF7009166
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Nov 2014 13:52:27 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sADDqPY3011894; Thu, 13 Nov 2014 13:52:25 GMT
Received: from [IPv6:2607:fb90:e19:ec57:2be0:9f26:3b5c:68f4] (/172.56.23.242)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 05:52:24 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <546476AE.9080207@suse.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-7-git-send-email-jgross@suse.com>
	<20141112221813.GE7549@laptop.dumpdata.com>
	<546476AE.9080207@suse.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 13 Nov 2014 08:51:59 -0500
To: Juergen Gross <jgross@suse.com>
Message-ID: <F820B37E-953B-4904-9E9B-6D32BA989F29@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 6/8] xen: Hide get_phys_to_machine() to
	be able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 13, 2014 4:15:26 AM EST, Juergen Gross <jgross@suse.com> wrote:
>On 11/12/2014 11:18 PM, Konrad Rzeszutek Wilk wrote:
>> On Tue, Nov 11, 2014 at 06:43:44AM +0100, Juergen Gross wrote:
>>> Today get_phys_to_machine() is always called when the mfn for a pfn
>>> is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
>>> to be able to avoid calling get_phys_to_machine() when possible as
>>
>> s/when/where/
>
>No. It's not a matter of the caller, but of the p2m list entry.
>
>>> soon as the switch to a linear mapped p2m list has been done.
>>
>> But your inline function still calls get_phys_to_machine?
>
>Sure. The switch is done in the next patch. David asked me to split
>the patch doing the preparation by adding __pfn_tom_mfn() in an own
>patch.
>
>>
>>
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>>   arch/x86/include/asm/xen/page.h | 27 +++++++++++++++++++++------
>>>   arch/x86/xen/mmu.c              |  2 +-
>>>   arch/x86/xen/p2m.c              |  6 +++---
>>>   3 files changed, 25 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/x86/include/asm/xen/page.h
>b/arch/x86/include/asm/xen/page.h
>>> index 28fa795..07d8a7b 100644
>>> --- a/arch/x86/include/asm/xen/page.h
>>> +++ b/arch/x86/include/asm/xen/page.h
>>> @@ -59,6 +59,22 @@ extern int clear_foreign_p2m_mapping(struct
>gnttab_unmap_grant_ref *unmap_ops,
>>>   				     struct page **pages, unsigned int count);
>>>   extern unsigned long m2p_find_override_pfn(unsigned long mfn,
>unsigned long pfn);
>>>
>>> +/*
>>> + * When to use pfn_to_mfn(), __pfn_to_mfn() or
>get_phys_to_machine():
>>> + * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. In
>case of an
>>> + *   identity entry the identity indicator will be cleared.
>>
>> Why don't you say : In case of identity PFN the same PFN is returned.
>>
>> But you did miss that also the FOREIGN_FRAME_BIT is cleared.
>
>I'll reword the comment.
>
>>
>>> + * - __pfn_to_mfn() returns the found entry of the p2m table. A
>possibly set
>>
>> s/of the/in the/
>>> + *   identity indicator will be still set. __pfn_to_mfn() is
>encapsulating
>> .. be still set if the PFN is an identity one.
>>> + *   get_phys_to_machine() and might skip that function if possible
>to speed
>>> + *   up the common path.
>>
>> How is is skipping that function? The patch below does no such thing?
>
>The next patch in this series does.

Then this should be part of the next patch
>
>>
>>> + * - get_phys_to_machine() is basically the same as __pfn_to_mfn(),
>but
>>> + *   without any short cuts for the common fast path.
>>
>> Right. Perhpas we should call it 'slow_p2m' instead of the
>'get_phys_to_machine'.
>
>That's a matter of taste, I think. I can change it if nobody else
>objects.
>

That would need to be a separate patch if we wanted to go that route.

>
>Juergen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 14:07:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 14: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 1Xov3F-0003Wd-3r; Thu, 13 Nov 2014 14:07:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1Xov39-0003WV-GG
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 14:07:07 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	82/E4-27785-60BB4645; Thu, 13 Nov 2014 14:07:02 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415887621!12306910!1
X-Originating-IP: [130.233.192.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19380 invoked from network); 13 Nov 2014 14:07:02 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-6.tower-27.messagelabs.com with SMTP;
	13 Nov 2014 14:07:02 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id 82402308960;
	Thu, 13 Nov 2014 16:07:00 +0200 (EET)
Message-ID: <5464BB03.7090801@iki.fi>
Date: Thu, 13 Nov 2014 14:06:59 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: rumpkernel-users@lists.sourceforge.net, 
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk>
In-Reply-To: <20141113112202.GB7853@nodbug.moloch.sk>
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 11:22, Martin Lucina wrote:
> back in July there was some discussion on configuring rump kernel
> application stacks:
> http://thread.gmane.org/gmane.comp.rumpkernel.user/321
>
> Some proposals were made, but no actual implementation work was done. In
> the mean time, I have implemented the simplest possible mechanism I could
> think of for rumprun-xen, using Xenstore.
>
> The patches are available for review as PR #12:
> https://github.com/rumpkernel/rumprun-xen/pull/12

Thanks Martin, great work!

> Following is the high-level description from the Git commit:

Can you also post an example of the usage of your CLI tool?  Actually, 
can you post a rough description of the entire process that a user would 
have to follow, i.e. compile, configure, run.

>   - The rumpconfig module provides _rumprun_config() and
>     _rumprun_deconfig() functions. These are called before and after the
>     application main() function, and also in the case of deconfig when
>     _exit() is called.

Is deconfig necessary?  The rump kernel already automatically e.g. 
unmounts file systems and releases the dhcp lease when it's halted.

>    - The "xr" driver script, currently located in app-tools/. The
>      motivation for this script is twofold:
>
>      Firstly, in order to write the configuration to Xenstore the domain
>      must be created in a paused state so that we can retrieve its unique
>      . Only then do we know where in Xenstore to write the
>      configuration data.
>
>      Secondly, it is my intention with this work to provide a
>      "docker-alike" interface for running rumprun applications. The "xr"
>      script is therefore the CLI for running such applications.

The user-facing configuration tool was sorely needed.  I hate to go into 
naming, but ... can we call the tool "rumprun"?  I think your tool will 
be the basis for running rumprun stacks beyond Xen, and we should try to 
avoid the user-visible syntax having any obvious shortcomings.

> Note that in this initial version, only configuring IPv4 network
> interfaces with DHCP is supported, and only using image files with ffs
> or cd9660 filesystems for block devices is supported.

Would e.g. IPv6 support take longer than it took to write that paragraph ?-)

   - antti

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 14:07:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 14: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 1Xov3F-0003Wd-3r; Thu, 13 Nov 2014 14:07:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1Xov39-0003WV-GG
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 14:07:07 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	82/E4-27785-60BB4645; Thu, 13 Nov 2014 14:07:02 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415887621!12306910!1
X-Originating-IP: [130.233.192.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19380 invoked from network); 13 Nov 2014 14:07:02 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-6.tower-27.messagelabs.com with SMTP;
	13 Nov 2014 14:07:02 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id 82402308960;
	Thu, 13 Nov 2014 16:07:00 +0200 (EET)
Message-ID: <5464BB03.7090801@iki.fi>
Date: Thu, 13 Nov 2014 14:06:59 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: rumpkernel-users@lists.sourceforge.net, 
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk>
In-Reply-To: <20141113112202.GB7853@nodbug.moloch.sk>
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 11:22, Martin Lucina wrote:
> back in July there was some discussion on configuring rump kernel
> application stacks:
> http://thread.gmane.org/gmane.comp.rumpkernel.user/321
>
> Some proposals were made, but no actual implementation work was done. In
> the mean time, I have implemented the simplest possible mechanism I could
> think of for rumprun-xen, using Xenstore.
>
> The patches are available for review as PR #12:
> https://github.com/rumpkernel/rumprun-xen/pull/12

Thanks Martin, great work!

> Following is the high-level description from the Git commit:

Can you also post an example of the usage of your CLI tool?  Actually, 
can you post a rough description of the entire process that a user would 
have to follow, i.e. compile, configure, run.

>   - The rumpconfig module provides _rumprun_config() and
>     _rumprun_deconfig() functions. These are called before and after the
>     application main() function, and also in the case of deconfig when
>     _exit() is called.

Is deconfig necessary?  The rump kernel already automatically e.g. 
unmounts file systems and releases the dhcp lease when it's halted.

>    - The "xr" driver script, currently located in app-tools/. The
>      motivation for this script is twofold:
>
>      Firstly, in order to write the configuration to Xenstore the domain
>      must be created in a paused state so that we can retrieve its unique
>      . Only then do we know where in Xenstore to write the
>      configuration data.
>
>      Secondly, it is my intention with this work to provide a
>      "docker-alike" interface for running rumprun applications. The "xr"
>      script is therefore the CLI for running such applications.

The user-facing configuration tool was sorely needed.  I hate to go into 
naming, but ... can we call the tool "rumprun"?  I think your tool will 
be the basis for running rumprun stacks beyond Xen, and we should try to 
avoid the user-visible syntax having any obvious shortcomings.

> Note that in this initial version, only configuring IPv4 network
> interfaces with DHCP is supported, and only using image files with ffs
> or cd9660 filesystems for block devices is supported.

Would e.g. IPv6 support take longer than it took to write that paragraph ?-)

   - antti

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 14:08:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 14:08:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xov4f-0003aj-If; Thu, 13 Nov 2014 14:08:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xov4e-0003aa-6t
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 14:08:36 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	87/2C-22819-36BB4645; Thu, 13 Nov 2014 14:08:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415887714!7800457!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13629 invoked from network); 13 Nov 2014 14:08:34 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Nov 2014 14:08:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 14:08:34 +0000
Message-Id: <5464C971020000780004739B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 14:08:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Simon Martin" <furryfuttock@gmail.com>
References: <198478230.20141113102921@gmail.com>
In-Reply-To: <198478230.20141113102921@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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 13.11.14 at 14:29, <furryfuttock@gmail.com> wrote:
> I am having 2 major problems at the moment.
> 
> 1.- Access to the PCI device from the PV will fail the second time I
> create it UNLESS I call xl pci-assignable-remove/pci-assignable-add
> between each creation. If I don't do this then all PCI accesses return
> -1. I get the same if I disable memory access in the PCI configuration
> register.
> 
> 1.1.- Is this expected behaviour?

No. But did you verify the driver properly enables the device (i.e.
doesn't make assumptions on its state)? Also iirc some kernel
versions weren't properly resetting the device when coming back
from guest use, but without you stating the software versions
you're using that's just a remote possibility.

> 1.3.-  xl  dmesg  and  dmesg  in Dom0 do not show anything. I have set
> loglvl=all in the Xen command line.

"iommu=debug"? But given the symptoms above I don't really think
this is a problem with the IOMMU.

> 2.-  Whenever  I  perform a software reset on the PCI device (it is an
> Intel  82546  Ethernet  NIC) the hypervisor crashes. There is no oops,
> kernel  panic  or the like, just a crash. My development device has no
> serial port so I can't do much debugging.

A crash would imply you see something telling you it's a crash. If
you see nothing, I'd rather call it a hang or spontaneous reboot.
But even without serial port (assuming you can't even plug in a
serial port PCI card) there are ways to get at eventual crash output
(register+stack dump): For one, we've got USB debug port support.
This requires a special cable and there not being an (internal) hub in
between, but it's worth a consideration. And in the worst case,
"vga=keep" allows the hypervisor to continue printing to the screen
even post-boot. But that requires the video mode to not be changed
from the one Xen uses at boot (i.e. you should not use DRM's KMS,
and if you need to use X it would need to be configured to use the
frame buffer driver rather than any accelerating one).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 14:08:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 14:08:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xov4f-0003aj-If; Thu, 13 Nov 2014 14:08:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xov4e-0003aa-6t
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 14:08:36 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	87/2C-22819-36BB4645; Thu, 13 Nov 2014 14:08:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415887714!7800457!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13629 invoked from network); 13 Nov 2014 14:08:34 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Nov 2014 14:08:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 14:08:34 +0000
Message-Id: <5464C971020000780004739B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 14:08:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Simon Martin" <furryfuttock@gmail.com>
References: <198478230.20141113102921@gmail.com>
In-Reply-To: <198478230.20141113102921@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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 13.11.14 at 14:29, <furryfuttock@gmail.com> wrote:
> I am having 2 major problems at the moment.
> 
> 1.- Access to the PCI device from the PV will fail the second time I
> create it UNLESS I call xl pci-assignable-remove/pci-assignable-add
> between each creation. If I don't do this then all PCI accesses return
> -1. I get the same if I disable memory access in the PCI configuration
> register.
> 
> 1.1.- Is this expected behaviour?

No. But did you verify the driver properly enables the device (i.e.
doesn't make assumptions on its state)? Also iirc some kernel
versions weren't properly resetting the device when coming back
from guest use, but without you stating the software versions
you're using that's just a remote possibility.

> 1.3.-  xl  dmesg  and  dmesg  in Dom0 do not show anything. I have set
> loglvl=all in the Xen command line.

"iommu=debug"? But given the symptoms above I don't really think
this is a problem with the IOMMU.

> 2.-  Whenever  I  perform a software reset on the PCI device (it is an
> Intel  82546  Ethernet  NIC) the hypervisor crashes. There is no oops,
> kernel  panic  or the like, just a crash. My development device has no
> serial port so I can't do much debugging.

A crash would imply you see something telling you it's a crash. If
you see nothing, I'd rather call it a hang or spontaneous reboot.
But even without serial port (assuming you can't even plug in a
serial port PCI card) there are ways to get at eventual crash output
(register+stack dump): For one, we've got USB debug port support.
This requires a special cable and there not being an (internal) hub in
between, but it's worth a consideration. And in the worst case,
"vga=keep" allows the hypervisor to continue printing to the screen
even post-boot. But that requires the video mode to not be changed
from the one Xen uses at boot (i.e. you should not use DRM's KMS,
and if you need to use X it would need to be configured to use the
frame buffer driver rather than any accelerating one).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 14:59:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 14:59:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XovrJ-0004nt-HD; Thu, 13 Nov 2014 14:58:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1XovrH-0004no-Ir
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 14:58:51 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	D5/59-27623-A27C4645; Thu, 13 Nov 2014 14:58:50 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415890726!7448381!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11770 invoked from network); 13 Nov 2014 14:58:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 14:58:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,377,1413244800"; d="scan'208";a="190969095"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>, <qemu-devel@nongnu.org>
Date: Thu, 13 Nov 2014 15:58:23 +0100
Message-ID: <1415890703-10147-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
MIME-Version: 1.0
Content-Length:10744
X-DLP: MIA1
Cc: Kevin Wolf <kwolf@redhat.com>, George Dunlap <george.dunlap@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 for-xen-4.5] xen_disk: fix unmapping of
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyBwYXRjaCBmaXhlcyB0d28gaXNzdWVzIHdpdGggcGVyc2lzdGVudCBncmFudHMgYW5kIHRo
ZSBkaXNrIFBWIGJhY2tlbmQKKFFkaXNrKToKCiAtIEtlZXAgdHJhY2sgb2YgbWVtb3J5IHJlZ2lv
bnMgd2hlcmUgcGVyc2lzdGVudCBncmFudHMgaGF2ZSBiZWVuIG1hcHBlZAogICBzaW5jZSB3ZSBu
ZWVkIHRvIHVubWFwIHRoZW0gYXMgYSB3aG9sZS4gSXQgaXMgbm90IHBvc3NpYmxlIHRvIHVubWFw
IGEKICAgc2luZ2xlIGdyYW50IGlmIGl0IGhhcyBiZWVuIGJhdGNoLW1hcHBlZC4KIC0gVW5tYXAg
cGVyc2lzdGVudCBncmFudHMgYmVmb3JlIHN3aXRjaGluZyB0byB0aGUgY2xvc2VkIHN0YXRlLCBz
byB0aGUKICAgZnJvbnRlbmQgY2FuIGFsc28gZnJlZSB0aGVtLgoKU2lnbmVkLW9mZi1ieTogUm9n
ZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJlcG9ydGVkLWJ5OiBHZW9yZ2Ug
RHVubGFwIDxnZW9yZ2UuZHVubGFwQGV1LmNpdHJpeC5jb20+CkNjOiBTdGVmYW5vIFN0YWJlbGxp
bmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgpDYzogS2V2aW4gV29sZiA8a3dv
bGZAcmVkaGF0LmNvbT4KQ2M6IFN0ZWZhbiBIYWpub2N6aSA8c3RlZmFuaGFAcmVkaGF0LmNvbT4K
Q2M6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KQ2M6IEtvbnJh
ZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KLS0tClhlbiByZWxlYXNl
IGV4Y2VwdGlvbjogdGhpcyBpcyBvYnZpb3VzbHkgYW4gaW1wb3J0YW50IGJ1Zy1maXggdGhhdCBz
aG91bGQgYmUKaW5jbHVkZWQgaW4gNC41LiBXaXRob3V0IHRoaXMgZml4LCB0cnlpbmcgdG8gZG8g
YSBibG9jay1kZXRhY2ggb2YgYSBRZGlzawpmcm9tIGEgcnVubmluZyBndWVzdCBjYW4gbGVhZCB0
byBndWVzdCBjcmFzaCBkZXBlbmRpbmcgb24gdGhlIGJsa2Zyb250CmltcGxlbWVudGF0aW9uLgot
LS0KQ2hhbmdlcyBzaW5jZSB2MToKIC0gSW5zdGVhZCBvZiBkaXNhYmxpbmcgYmF0Y2ggbWFwcGlu
Z3Mgd2hlbiB1c2luZyBwZXJzaXN0ZW50IGdyYW50cywga2VlcAogICB0cmFjayBvZiB0aGUgcGVy
c2lzdGVudGx5IG1hcHBlZCByZWdpb25zIGFuZCB1bm1hcCB0aGVtIG9uIGRpc2Nvbm5lY3Rpb24u
CiAgIFRoaXMgcHJldmVudHMgdW5tYXBwaW5nIHNpbmdsZSBwZXJzaXN0ZW50IGdyYW50cywgYnV0
IHRoZSBjdXJyZW50CiAgIGltcGxlbWVudGF0aW9uIGRvZXNuJ3QgcmVxdWlyZSBpdC4KClRoaXMg
bmV3IHZlcnNpb24gaXMgc2xpZ2h0bHkgZmFzdGVyIHRoYW4gdGhlIHByZXZpb3VzIG9uZSwgdGhl
IGZvbGxvd2luZwp0ZXN0IHJlc3VsdHMgYXJlIGluIElPUFMgZnJvbSAyMCBydW5zIG9mIGEgYmxv
Y2stYXR0YWNoLCBmaW8gcnVuLApibG9jay1kZXRhY2ggdGVzdCBsb29wOgoKeCBiYXRjaAorIG5v
X2JhdGNoCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tKwp8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICArICAgKyAgICAgeCAgICB4ICsgKyArICB4IHh4IHggIHwKfCsgICsgICAgICAgICAgIHgg
ICAgICAgICAgICAgICAgICAgICB4KyAgKisrKyAgICogICt4KiArKyt4KiAgeCB4eCB4ICp8Cnwg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8X19fX19fX19fX19fX0Ff
X19fX01fX19fX198fAp8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxfX19fX19fX19fX19f
X19fQV9fX19fTV9fX19fX19fX19ffCAgICAgIHwKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICBOICAgICAg
ICAgICBNaW4gICAgICAgICAgIE1heCAgICAgICAgTWVkaWFuICAgICAgICAgICBBdmcgICAgICAg
IFN0ZGRldgp4ICAyMCAgICAgICAgIDUyOTQxICAgICAgICAgNjM4MjIgICAgICAgICA2MjM5NiAg
ICAgIDYxMTgwLjE1ICAgICAyNjczLjY0OTcKKyAgMjAgICAgICAgICA0OTk2NyAgICAgICAgIDYz
ODQ5ICAgICAgICAgNjAzMjIgICAgICAgNTkxMTYuOSAgICAgMzQ1Ni4zNDU1CkRpZmZlcmVuY2Ug
YXQgOTUuMCUgY29uZmlkZW5jZQoJLTIwNjMuMjUgKy8tIDE5NzcuNjYKCS0zLjM3MjQyJSArLy0g
My4yMzI1MiUKCShTdHVkZW50J3MgdCwgcG9vbGVkIHMgPSAzMDg5Ljg4KQotLS0KIGh3L2Jsb2Nr
L3hlbl9kaXNrLmMgfCA3NyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKy0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDY0IGluc2VydGlvbnMoKyksIDEzIGRlbGV0
aW9ucygtKQoKZGlmZiAtLWdpdCBhL2h3L2Jsb2NrL3hlbl9kaXNrLmMgYi9ody9ibG9jay94ZW5f
ZGlzay5jCmluZGV4IDIzMWU5YTcuLjc1YmRjMTYgMTAwNjQ0Ci0tLSBhL2h3L2Jsb2NrL3hlbl9k
aXNrLmMKKysrIGIvaHcvYmxvY2sveGVuX2Rpc2suYwpAQCAtNTksNiArNTksMTMgQEAgc3RydWN0
IFBlcnNpc3RlbnRHcmFudCB7CiAKIHR5cGVkZWYgc3RydWN0IFBlcnNpc3RlbnRHcmFudCBQZXJz
aXN0ZW50R3JhbnQ7CiAKK3N0cnVjdCBQZXJzaXN0ZW50UmVnaW9uIHsKKyAgICB2b2lkICphZGRy
OworICAgIGludCBudW07Cit9OworCit0eXBlZGVmIHN0cnVjdCBQZXJzaXN0ZW50UmVnaW9uIFBl
cnNpc3RlbnRSZWdpb247CisKIHN0cnVjdCBpb3JlcSB7CiAgICAgYmxraWZfcmVxdWVzdF90ICAg
ICByZXE7CiAgICAgaW50MTZfdCAgICAgICAgICAgICBzdGF0dXM7CkBAIC0xMTgsNiArMTI1LDcg
QEAgc3RydWN0IFhlbkJsa0RldiB7CiAgICAgZ2Jvb2xlYW4gICAgICAgICAgICBmZWF0dXJlX2Rp
c2NhcmQ7CiAgICAgZ2Jvb2xlYW4gICAgICAgICAgICBmZWF0dXJlX3BlcnNpc3RlbnQ7CiAgICAg
R1RyZWUgICAgICAgICAgICAgICAqcGVyc2lzdGVudF9nbnRzOworICAgIEdTTGlzdCAgICAgICAg
ICAgICAgKnBlcnNpc3RlbnRfcmVnaW9uczsKICAgICB1bnNpZ25lZCBpbnQgICAgICAgIHBlcnNp
c3RlbnRfZ250X2NvdW50OwogICAgIHVuc2lnbmVkIGludCAgICAgICAgbWF4X2dyYW50czsKIApA
QCAtMTY0LDE5ICsxNzIsNDEgQEAgc3RhdGljIGdpbnQgaW50X2NtcChnY29uc3Rwb2ludGVyIGEs
IGdjb25zdHBvaW50ZXIgYiwgZ3BvaW50ZXIgdXNlcl9kYXRhKQogc3RhdGljIHZvaWQgZGVzdHJv
eV9ncmFudChncG9pbnRlciBwZ250KQogewogICAgIFBlcnNpc3RlbnRHcmFudCAqZ3JhbnQgPSBw
Z250OwotICAgIFhlbkdudHRhYiBnbnQgPSBncmFudC0+YmxrZGV2LT54ZW5kZXYuZ250dGFiZGV2
OwogCi0gICAgaWYgKHhjX2dudHRhYl9tdW5tYXAoZ250LCBncmFudC0+cGFnZSwgMSkgIT0gMCkg
ewotICAgICAgICB4ZW5fYmVfcHJpbnRmKCZncmFudC0+YmxrZGV2LT54ZW5kZXYsIDAsCi0gICAg
ICAgICAgICAgICAgICAgICAgInhjX2dudHRhYl9tdW5tYXAgZmFpbGVkOiAlc1xuIiwKLSAgICAg
ICAgICAgICAgICAgICAgICBzdHJlcnJvcihlcnJubykpOwotICAgIH0KICAgICBncmFudC0+Ymxr
ZGV2LT5wZXJzaXN0ZW50X2dudF9jb3VudC0tOwogICAgIHhlbl9iZV9wcmludGYoJmdyYW50LT5i
bGtkZXYtPnhlbmRldiwgMywKLSAgICAgICAgICAgICAgICAgICJ1bm1hcHBlZCBncmFudCAlcFxu
IiwgZ3JhbnQtPnBhZ2UpOworICAgICAgICAgICAgICAgICAgInJlbW92ZWQgZ3JhbnQgJXBcbiIs
IGdyYW50LT5wYWdlKTsKICAgICBnX2ZyZWUoZ3JhbnQpOwogfQogCitzdGF0aWMgdm9pZCBhZGRf
cGVyc2lzdGVudF9yZWdpb24oc3RydWN0IFhlbkJsa0RldiAqYmxrZGV2LCB2b2lkICphZGRyLCBp
bnQgbnVtKQoreworICAgIFBlcnNpc3RlbnRSZWdpb24gKnJlZ2lvbjsKKworICAgIHJlZ2lvbiA9
IGdfbWFsbG9jMChzaXplb2YoKnJlZ2lvbikpOworICAgIHJlZ2lvbi0+YWRkciA9IGFkZHI7Cisg
ICAgcmVnaW9uLT5udW0gPSBudW07CisgICAgYmxrZGV2LT5wZXJzaXN0ZW50X3JlZ2lvbnMgPSBn
X3NsaXN0X2FwcGVuZChibGtkZXYtPnBlcnNpc3RlbnRfcmVnaW9ucywKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZ2lvbik7Cit9CisKK3N0YXRpYyB2
b2lkIHJlbW92ZV9wZXJzaXN0ZW50X3JlZ2lvbihncG9pbnRlciBkYXRhLCBncG9pbnRlciBkZXYp
Cit7CisgICAgUGVyc2lzdGVudFJlZ2lvbiAqcmVnaW9uID0gZGF0YTsKKyAgICBzdHJ1Y3QgWGVu
QmxrRGV2ICpibGtkZXYgPSBkZXY7CisgICAgWGVuR250dGFiIGdudCA9IGJsa2Rldi0+eGVuZGV2
LmdudHRhYmRldjsKKworICAgIGlmICh4Y19nbnR0YWJfbXVubWFwKGdudCwgcmVnaW9uLT5hZGRy
LCByZWdpb24tPm51bSkgIT0gMCkgeworICAgICAgICB4ZW5fYmVfcHJpbnRmKCZibGtkZXYtPnhl
bmRldiwgMCwKKyAgICAgICAgICAgICAgICAgICAgICAieGNfZ250dGFiX211bm1hcCByZWdpb24g
JXAgZmFpbGVkOiAlc1xuIiwKKyAgICAgICAgICAgICAgICAgICAgICByZWdpb24tPmFkZHIsIHN0
cmVycm9yKGVycm5vKSk7CisgICAgfQorICAgIHhlbl9iZV9wcmludGYoJmJsa2Rldi0+eGVuZGV2
LCAzLAorICAgICAgICAgICAgICAgICAgInVubWFwcGVkIGdyYW50IHJlZ2lvbiAlcCB3aXRoICVk
IHBhZ2VzXG4iLAorICAgICAgICAgICAgICAgICAgcmVnaW9uLT5hZGRyLCByZWdpb24tPm51bSk7
CisgICAgZ19mcmVlKHJlZ2lvbik7Cit9CisKIHN0YXRpYyBzdHJ1Y3QgaW9yZXEgKmlvcmVxX3N0
YXJ0KHN0cnVjdCBYZW5CbGtEZXYgKmJsa2RldikKIHsKICAgICBzdHJ1Y3QgaW9yZXEgKmlvcmVx
ID0gTlVMTDsKQEAgLTQyMSw3ICs0NTEsMTcgQEAgc3RhdGljIGludCBpb3JlcV9tYXAoc3RydWN0
IGlvcmVxICppb3JlcSkKICAgICAgICAgICAgIH0KICAgICAgICAgfQogICAgIH0KLSAgICBpZiAo
aW9yZXEtPmJsa2Rldi0+ZmVhdHVyZV9wZXJzaXN0ZW50KSB7CisgICAgaWYgKGlvcmVxLT5ibGtk
ZXYtPmZlYXR1cmVfcGVyc2lzdGVudCAmJiBuZXdfbWFwcyAmJgorICAgICAgICAoIWJhdGNoX21h
cHMgfHwgKGlvcmVxLT5ibGtkZXYtPnBlcnNpc3RlbnRfZ250X2NvdW50ICsgbmV3X21hcHMgPD0K
KyAgICAgICAgaW9yZXEtPmJsa2Rldi0+bWF4X2dyYW50cykpKSB7CisgICAgICAgIC8qCisgICAg
ICAgICAqIElmIHdlIGFyZSB1c2luZyBwZXJzaXN0ZW50IGdyYW50cyBhbmQgYmF0Y2ggbWFwcGlu
Z3Mgb25seQorICAgICAgICAgKiBhZGQgdGhlIG5ldyBtYXBzIHRvIHRoZSBsaXN0IG9mIHBlcnNp
c3RlbnQgZ3JhbnRzIGlmIHRoZSB3aG9sZQorICAgICAgICAgKiBhcmVhIGNhbiBiZSBwZXJzaXN0
ZW50bHkgbWFwcGVkLgorICAgICAgICAgKi8KKyAgICAgICAgaWYgKGJhdGNoX21hcHMgJiYgbmV3
X21hcHMpIHsKKyAgICAgICAgICAgIGFkZF9wZXJzaXN0ZW50X3JlZ2lvbihpb3JlcS0+YmxrZGV2
LCBpb3JlcS0+cGFnZXMsIG5ld19tYXBzKTsKKyAgICAgICAgfQogICAgICAgICB3aGlsZSAoKGlv
cmVxLT5ibGtkZXYtPnBlcnNpc3RlbnRfZ250X2NvdW50IDwgaW9yZXEtPmJsa2Rldi0+bWF4X2dy
YW50cykKICAgICAgICAgICAgICAgJiYgbmV3X21hcHMpIHsKICAgICAgICAgICAgIC8qIEdvIHRo
cm91Z2ggdGhlIGxpc3Qgb2YgbmV3bHkgbWFwcGVkIGdyYW50cyBhbmQgYWRkIGFzIG1hbnkKQEAg
LTQzNyw2ICs0NzcsNyBAQCBzdGF0aWMgaW50IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEgKmlvcmVx
KQogICAgICAgICAgICAgICAgIGdyYW50LT5wYWdlID0gaW9yZXEtPnBhZ2VzICsgKG5ld19tYXBz
KSAqIFhDX1BBR0VfU0laRTsKICAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAgICAg
Z3JhbnQtPnBhZ2UgPSBpb3JlcS0+cGFnZVtuZXdfbWFwc107CisgICAgICAgICAgICAgICAgYWRk
X3BlcnNpc3RlbnRfcmVnaW9uKGlvcmVxLT5ibGtkZXYsIGlvcmVxLT5wYWdlW25ld19tYXBzXSwg
MSk7CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBncmFudC0+YmxrZGV2ID0gaW9yZXEtPmJs
a2RldjsKICAgICAgICAgICAgIHhlbl9iZV9wcmludGYoJmlvcmVxLT5ibGtkZXYtPnhlbmRldiwg
MywKQEAgLTQ0Nyw2ICs0ODgsNyBAQCBzdGF0aWMgaW50IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEg
KmlvcmVxKQogICAgICAgICAgICAgICAgICAgICAgICAgICBncmFudCk7CiAgICAgICAgICAgICBp
b3JlcS0+YmxrZGV2LT5wZXJzaXN0ZW50X2dudF9jb3VudCsrOwogICAgICAgICB9CisgICAgICAg
IGFzc2VydCghYmF0Y2hfbWFwcyB8fCBuZXdfbWFwcyA9PSAwKTsKICAgICB9CiAgICAgZm9yIChp
ID0gMDsgaSA8IGlvcmVxLT52Lm5pb3Y7IGkrKykgewogICAgICAgICBpb3JlcS0+di5pb3ZbaV0u
aW92X2Jhc2UgKz0gKHVpbnRwdHJfdClwYWdlW2ldOwpAQCAtOTcyLDYgKzEwMTQsNyBAQCBzdGF0
aWMgaW50IGJsa19jb25uZWN0KHN0cnVjdCBYZW5EZXZpY2UgKnhlbmRldikKICAgICAgICAgYmxr
ZGV2LT5wZXJzaXN0ZW50X2dudHMgPSBnX3RyZWVfbmV3X2Z1bGwoKEdDb21wYXJlRGF0YUZ1bmMp
aW50X2NtcCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5V
TEwsIE5VTEwsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAo
R0Rlc3Ryb3lOb3RpZnkpZGVzdHJveV9ncmFudCk7CisgICAgICAgIGJsa2Rldi0+cGVyc2lzdGVu
dF9yZWdpb25zID0gTlVMTDsKICAgICAgICAgYmxrZGV2LT5wZXJzaXN0ZW50X2dudF9jb3VudCA9
IDA7CiAgICAgfQogCkBAIC0xMDAwLDYgKzEwNDMsMTkgQEAgc3RhdGljIHZvaWQgYmxrX2Rpc2Nv
bm5lY3Qoc3RydWN0IFhlbkRldmljZSAqeGVuZGV2KQogICAgICAgICBibGtkZXYtPmNudF9tYXAt
LTsKICAgICAgICAgYmxrZGV2LT5zcmluZyA9IE5VTEw7CiAgICAgfQorCisgICAgLyoKKyAgICAg
KiBVbm1hcCBwZXJzaXN0ZW50IGdyYW50cyBiZWZvcmUgc3dpdGNoaW5nIHRvIHRoZSBjbG9zZWQg
c3RhdGUKKyAgICAgKiBzbyB0aGUgZnJvbnRlbmQgY2FuIGZyZWUgdGhlbS4KKyAgICAgKi8KKyAg
ICBpZiAoYmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKKyAgICAgICAgZ190cmVlX2Rlc3Ry
b3koYmxrZGV2LT5wZXJzaXN0ZW50X2dudHMpOworICAgICAgICBhc3NlcnQoYmxrZGV2LT5wZXJz
aXN0ZW50X2dudF9jb3VudCA9PSAwKTsKKyAgICAgICAgZ19zbGlzdF9mb3JlYWNoKGJsa2Rldi0+
cGVyc2lzdGVudF9yZWdpb25zLAorICAgICAgICAgICAgICAgICAgICAgICAgKEdGdW5jKXJlbW92
ZV9wZXJzaXN0ZW50X3JlZ2lvbiwgYmxrZGV2KTsKKyAgICAgICAgZ19zbGlzdF9mcmVlKGJsa2Rl
di0+cGVyc2lzdGVudF9yZWdpb25zKTsKKyAgICAgICAgYmxrZGV2LT5mZWF0dXJlX3BlcnNpc3Rl
bnQgPSBmYWxzZTsKKyAgICB9CiB9CiAKIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhlbkRl
dmljZSAqeGVuZGV2KQpAQCAtMTAxMSwxMSArMTA2Nyw2IEBAIHN0YXRpYyBpbnQgYmxrX2ZyZWUo
c3RydWN0IFhlbkRldmljZSAqeGVuZGV2KQogICAgICAgICBibGtfZGlzY29ubmVjdCh4ZW5kZXYp
OwogICAgIH0KIAotICAgIC8qIEZyZWUgcGVyc2lzdGVudCBncmFudHMgKi8KLSAgICBpZiAoYmxr
ZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKLSAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxrZGV2
LT5wZXJzaXN0ZW50X2dudHMpOwotICAgIH0KLQogICAgIHdoaWxlICghUUxJU1RfRU1QVFkoJmJs
a2Rldi0+ZnJlZWxpc3QpKSB7CiAgICAgICAgIGlvcmVxID0gUUxJU1RfRklSU1QoJmJsa2Rldi0+
ZnJlZWxpc3QpOwogICAgICAgICBRTElTVF9SRU1PVkUoaW9yZXEsIGxpc3QpOwotLSAKMS45LjMg
KEFwcGxlIEdpdC01MCkKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 13 14:59:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 14:59:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XovrJ-0004nt-HD; Thu, 13 Nov 2014 14:58:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1XovrH-0004no-Ir
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 14:58:51 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	D5/59-27623-A27C4645; Thu, 13 Nov 2014 14:58:50 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415890726!7448381!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11770 invoked from network); 13 Nov 2014 14:58:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 14:58:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,377,1413244800"; d="scan'208";a="190969095"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>, <qemu-devel@nongnu.org>
Date: Thu, 13 Nov 2014 15:58:23 +0100
Message-ID: <1415890703-10147-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
MIME-Version: 1.0
Content-Length:10744
X-DLP: MIA1
Cc: Kevin Wolf <kwolf@redhat.com>, George Dunlap <george.dunlap@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 for-xen-4.5] xen_disk: fix unmapping of
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyBwYXRjaCBmaXhlcyB0d28gaXNzdWVzIHdpdGggcGVyc2lzdGVudCBncmFudHMgYW5kIHRo
ZSBkaXNrIFBWIGJhY2tlbmQKKFFkaXNrKToKCiAtIEtlZXAgdHJhY2sgb2YgbWVtb3J5IHJlZ2lv
bnMgd2hlcmUgcGVyc2lzdGVudCBncmFudHMgaGF2ZSBiZWVuIG1hcHBlZAogICBzaW5jZSB3ZSBu
ZWVkIHRvIHVubWFwIHRoZW0gYXMgYSB3aG9sZS4gSXQgaXMgbm90IHBvc3NpYmxlIHRvIHVubWFw
IGEKICAgc2luZ2xlIGdyYW50IGlmIGl0IGhhcyBiZWVuIGJhdGNoLW1hcHBlZC4KIC0gVW5tYXAg
cGVyc2lzdGVudCBncmFudHMgYmVmb3JlIHN3aXRjaGluZyB0byB0aGUgY2xvc2VkIHN0YXRlLCBz
byB0aGUKICAgZnJvbnRlbmQgY2FuIGFsc28gZnJlZSB0aGVtLgoKU2lnbmVkLW9mZi1ieTogUm9n
ZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJlcG9ydGVkLWJ5OiBHZW9yZ2Ug
RHVubGFwIDxnZW9yZ2UuZHVubGFwQGV1LmNpdHJpeC5jb20+CkNjOiBTdGVmYW5vIFN0YWJlbGxp
bmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgpDYzogS2V2aW4gV29sZiA8a3dv
bGZAcmVkaGF0LmNvbT4KQ2M6IFN0ZWZhbiBIYWpub2N6aSA8c3RlZmFuaGFAcmVkaGF0LmNvbT4K
Q2M6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KQ2M6IEtvbnJh
ZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KLS0tClhlbiByZWxlYXNl
IGV4Y2VwdGlvbjogdGhpcyBpcyBvYnZpb3VzbHkgYW4gaW1wb3J0YW50IGJ1Zy1maXggdGhhdCBz
aG91bGQgYmUKaW5jbHVkZWQgaW4gNC41LiBXaXRob3V0IHRoaXMgZml4LCB0cnlpbmcgdG8gZG8g
YSBibG9jay1kZXRhY2ggb2YgYSBRZGlzawpmcm9tIGEgcnVubmluZyBndWVzdCBjYW4gbGVhZCB0
byBndWVzdCBjcmFzaCBkZXBlbmRpbmcgb24gdGhlIGJsa2Zyb250CmltcGxlbWVudGF0aW9uLgot
LS0KQ2hhbmdlcyBzaW5jZSB2MToKIC0gSW5zdGVhZCBvZiBkaXNhYmxpbmcgYmF0Y2ggbWFwcGlu
Z3Mgd2hlbiB1c2luZyBwZXJzaXN0ZW50IGdyYW50cywga2VlcAogICB0cmFjayBvZiB0aGUgcGVy
c2lzdGVudGx5IG1hcHBlZCByZWdpb25zIGFuZCB1bm1hcCB0aGVtIG9uIGRpc2Nvbm5lY3Rpb24u
CiAgIFRoaXMgcHJldmVudHMgdW5tYXBwaW5nIHNpbmdsZSBwZXJzaXN0ZW50IGdyYW50cywgYnV0
IHRoZSBjdXJyZW50CiAgIGltcGxlbWVudGF0aW9uIGRvZXNuJ3QgcmVxdWlyZSBpdC4KClRoaXMg
bmV3IHZlcnNpb24gaXMgc2xpZ2h0bHkgZmFzdGVyIHRoYW4gdGhlIHByZXZpb3VzIG9uZSwgdGhl
IGZvbGxvd2luZwp0ZXN0IHJlc3VsdHMgYXJlIGluIElPUFMgZnJvbSAyMCBydW5zIG9mIGEgYmxv
Y2stYXR0YWNoLCBmaW8gcnVuLApibG9jay1kZXRhY2ggdGVzdCBsb29wOgoKeCBiYXRjaAorIG5v
X2JhdGNoCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tKwp8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICArICAgKyAgICAgeCAgICB4ICsgKyArICB4IHh4IHggIHwKfCsgICsgICAgICAgICAgIHgg
ICAgICAgICAgICAgICAgICAgICB4KyAgKisrKyAgICogICt4KiArKyt4KiAgeCB4eCB4ICp8Cnwg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8X19fX19fX19fX19fX0Ff
X19fX01fX19fX198fAp8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxfX19fX19fX19fX19f
X19fQV9fX19fTV9fX19fX19fX19ffCAgICAgIHwKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICBOICAgICAg
ICAgICBNaW4gICAgICAgICAgIE1heCAgICAgICAgTWVkaWFuICAgICAgICAgICBBdmcgICAgICAg
IFN0ZGRldgp4ICAyMCAgICAgICAgIDUyOTQxICAgICAgICAgNjM4MjIgICAgICAgICA2MjM5NiAg
ICAgIDYxMTgwLjE1ICAgICAyNjczLjY0OTcKKyAgMjAgICAgICAgICA0OTk2NyAgICAgICAgIDYz
ODQ5ICAgICAgICAgNjAzMjIgICAgICAgNTkxMTYuOSAgICAgMzQ1Ni4zNDU1CkRpZmZlcmVuY2Ug
YXQgOTUuMCUgY29uZmlkZW5jZQoJLTIwNjMuMjUgKy8tIDE5NzcuNjYKCS0zLjM3MjQyJSArLy0g
My4yMzI1MiUKCShTdHVkZW50J3MgdCwgcG9vbGVkIHMgPSAzMDg5Ljg4KQotLS0KIGh3L2Jsb2Nr
L3hlbl9kaXNrLmMgfCA3NyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKy0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDY0IGluc2VydGlvbnMoKyksIDEzIGRlbGV0
aW9ucygtKQoKZGlmZiAtLWdpdCBhL2h3L2Jsb2NrL3hlbl9kaXNrLmMgYi9ody9ibG9jay94ZW5f
ZGlzay5jCmluZGV4IDIzMWU5YTcuLjc1YmRjMTYgMTAwNjQ0Ci0tLSBhL2h3L2Jsb2NrL3hlbl9k
aXNrLmMKKysrIGIvaHcvYmxvY2sveGVuX2Rpc2suYwpAQCAtNTksNiArNTksMTMgQEAgc3RydWN0
IFBlcnNpc3RlbnRHcmFudCB7CiAKIHR5cGVkZWYgc3RydWN0IFBlcnNpc3RlbnRHcmFudCBQZXJz
aXN0ZW50R3JhbnQ7CiAKK3N0cnVjdCBQZXJzaXN0ZW50UmVnaW9uIHsKKyAgICB2b2lkICphZGRy
OworICAgIGludCBudW07Cit9OworCit0eXBlZGVmIHN0cnVjdCBQZXJzaXN0ZW50UmVnaW9uIFBl
cnNpc3RlbnRSZWdpb247CisKIHN0cnVjdCBpb3JlcSB7CiAgICAgYmxraWZfcmVxdWVzdF90ICAg
ICByZXE7CiAgICAgaW50MTZfdCAgICAgICAgICAgICBzdGF0dXM7CkBAIC0xMTgsNiArMTI1LDcg
QEAgc3RydWN0IFhlbkJsa0RldiB7CiAgICAgZ2Jvb2xlYW4gICAgICAgICAgICBmZWF0dXJlX2Rp
c2NhcmQ7CiAgICAgZ2Jvb2xlYW4gICAgICAgICAgICBmZWF0dXJlX3BlcnNpc3RlbnQ7CiAgICAg
R1RyZWUgICAgICAgICAgICAgICAqcGVyc2lzdGVudF9nbnRzOworICAgIEdTTGlzdCAgICAgICAg
ICAgICAgKnBlcnNpc3RlbnRfcmVnaW9uczsKICAgICB1bnNpZ25lZCBpbnQgICAgICAgIHBlcnNp
c3RlbnRfZ250X2NvdW50OwogICAgIHVuc2lnbmVkIGludCAgICAgICAgbWF4X2dyYW50czsKIApA
QCAtMTY0LDE5ICsxNzIsNDEgQEAgc3RhdGljIGdpbnQgaW50X2NtcChnY29uc3Rwb2ludGVyIGEs
IGdjb25zdHBvaW50ZXIgYiwgZ3BvaW50ZXIgdXNlcl9kYXRhKQogc3RhdGljIHZvaWQgZGVzdHJv
eV9ncmFudChncG9pbnRlciBwZ250KQogewogICAgIFBlcnNpc3RlbnRHcmFudCAqZ3JhbnQgPSBw
Z250OwotICAgIFhlbkdudHRhYiBnbnQgPSBncmFudC0+YmxrZGV2LT54ZW5kZXYuZ250dGFiZGV2
OwogCi0gICAgaWYgKHhjX2dudHRhYl9tdW5tYXAoZ250LCBncmFudC0+cGFnZSwgMSkgIT0gMCkg
ewotICAgICAgICB4ZW5fYmVfcHJpbnRmKCZncmFudC0+YmxrZGV2LT54ZW5kZXYsIDAsCi0gICAg
ICAgICAgICAgICAgICAgICAgInhjX2dudHRhYl9tdW5tYXAgZmFpbGVkOiAlc1xuIiwKLSAgICAg
ICAgICAgICAgICAgICAgICBzdHJlcnJvcihlcnJubykpOwotICAgIH0KICAgICBncmFudC0+Ymxr
ZGV2LT5wZXJzaXN0ZW50X2dudF9jb3VudC0tOwogICAgIHhlbl9iZV9wcmludGYoJmdyYW50LT5i
bGtkZXYtPnhlbmRldiwgMywKLSAgICAgICAgICAgICAgICAgICJ1bm1hcHBlZCBncmFudCAlcFxu
IiwgZ3JhbnQtPnBhZ2UpOworICAgICAgICAgICAgICAgICAgInJlbW92ZWQgZ3JhbnQgJXBcbiIs
IGdyYW50LT5wYWdlKTsKICAgICBnX2ZyZWUoZ3JhbnQpOwogfQogCitzdGF0aWMgdm9pZCBhZGRf
cGVyc2lzdGVudF9yZWdpb24oc3RydWN0IFhlbkJsa0RldiAqYmxrZGV2LCB2b2lkICphZGRyLCBp
bnQgbnVtKQoreworICAgIFBlcnNpc3RlbnRSZWdpb24gKnJlZ2lvbjsKKworICAgIHJlZ2lvbiA9
IGdfbWFsbG9jMChzaXplb2YoKnJlZ2lvbikpOworICAgIHJlZ2lvbi0+YWRkciA9IGFkZHI7Cisg
ICAgcmVnaW9uLT5udW0gPSBudW07CisgICAgYmxrZGV2LT5wZXJzaXN0ZW50X3JlZ2lvbnMgPSBn
X3NsaXN0X2FwcGVuZChibGtkZXYtPnBlcnNpc3RlbnRfcmVnaW9ucywKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZ2lvbik7Cit9CisKK3N0YXRpYyB2
b2lkIHJlbW92ZV9wZXJzaXN0ZW50X3JlZ2lvbihncG9pbnRlciBkYXRhLCBncG9pbnRlciBkZXYp
Cit7CisgICAgUGVyc2lzdGVudFJlZ2lvbiAqcmVnaW9uID0gZGF0YTsKKyAgICBzdHJ1Y3QgWGVu
QmxrRGV2ICpibGtkZXYgPSBkZXY7CisgICAgWGVuR250dGFiIGdudCA9IGJsa2Rldi0+eGVuZGV2
LmdudHRhYmRldjsKKworICAgIGlmICh4Y19nbnR0YWJfbXVubWFwKGdudCwgcmVnaW9uLT5hZGRy
LCByZWdpb24tPm51bSkgIT0gMCkgeworICAgICAgICB4ZW5fYmVfcHJpbnRmKCZibGtkZXYtPnhl
bmRldiwgMCwKKyAgICAgICAgICAgICAgICAgICAgICAieGNfZ250dGFiX211bm1hcCByZWdpb24g
JXAgZmFpbGVkOiAlc1xuIiwKKyAgICAgICAgICAgICAgICAgICAgICByZWdpb24tPmFkZHIsIHN0
cmVycm9yKGVycm5vKSk7CisgICAgfQorICAgIHhlbl9iZV9wcmludGYoJmJsa2Rldi0+eGVuZGV2
LCAzLAorICAgICAgICAgICAgICAgICAgInVubWFwcGVkIGdyYW50IHJlZ2lvbiAlcCB3aXRoICVk
IHBhZ2VzXG4iLAorICAgICAgICAgICAgICAgICAgcmVnaW9uLT5hZGRyLCByZWdpb24tPm51bSk7
CisgICAgZ19mcmVlKHJlZ2lvbik7Cit9CisKIHN0YXRpYyBzdHJ1Y3QgaW9yZXEgKmlvcmVxX3N0
YXJ0KHN0cnVjdCBYZW5CbGtEZXYgKmJsa2RldikKIHsKICAgICBzdHJ1Y3QgaW9yZXEgKmlvcmVx
ID0gTlVMTDsKQEAgLTQyMSw3ICs0NTEsMTcgQEAgc3RhdGljIGludCBpb3JlcV9tYXAoc3RydWN0
IGlvcmVxICppb3JlcSkKICAgICAgICAgICAgIH0KICAgICAgICAgfQogICAgIH0KLSAgICBpZiAo
aW9yZXEtPmJsa2Rldi0+ZmVhdHVyZV9wZXJzaXN0ZW50KSB7CisgICAgaWYgKGlvcmVxLT5ibGtk
ZXYtPmZlYXR1cmVfcGVyc2lzdGVudCAmJiBuZXdfbWFwcyAmJgorICAgICAgICAoIWJhdGNoX21h
cHMgfHwgKGlvcmVxLT5ibGtkZXYtPnBlcnNpc3RlbnRfZ250X2NvdW50ICsgbmV3X21hcHMgPD0K
KyAgICAgICAgaW9yZXEtPmJsa2Rldi0+bWF4X2dyYW50cykpKSB7CisgICAgICAgIC8qCisgICAg
ICAgICAqIElmIHdlIGFyZSB1c2luZyBwZXJzaXN0ZW50IGdyYW50cyBhbmQgYmF0Y2ggbWFwcGlu
Z3Mgb25seQorICAgICAgICAgKiBhZGQgdGhlIG5ldyBtYXBzIHRvIHRoZSBsaXN0IG9mIHBlcnNp
c3RlbnQgZ3JhbnRzIGlmIHRoZSB3aG9sZQorICAgICAgICAgKiBhcmVhIGNhbiBiZSBwZXJzaXN0
ZW50bHkgbWFwcGVkLgorICAgICAgICAgKi8KKyAgICAgICAgaWYgKGJhdGNoX21hcHMgJiYgbmV3
X21hcHMpIHsKKyAgICAgICAgICAgIGFkZF9wZXJzaXN0ZW50X3JlZ2lvbihpb3JlcS0+YmxrZGV2
LCBpb3JlcS0+cGFnZXMsIG5ld19tYXBzKTsKKyAgICAgICAgfQogICAgICAgICB3aGlsZSAoKGlv
cmVxLT5ibGtkZXYtPnBlcnNpc3RlbnRfZ250X2NvdW50IDwgaW9yZXEtPmJsa2Rldi0+bWF4X2dy
YW50cykKICAgICAgICAgICAgICAgJiYgbmV3X21hcHMpIHsKICAgICAgICAgICAgIC8qIEdvIHRo
cm91Z2ggdGhlIGxpc3Qgb2YgbmV3bHkgbWFwcGVkIGdyYW50cyBhbmQgYWRkIGFzIG1hbnkKQEAg
LTQzNyw2ICs0NzcsNyBAQCBzdGF0aWMgaW50IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEgKmlvcmVx
KQogICAgICAgICAgICAgICAgIGdyYW50LT5wYWdlID0gaW9yZXEtPnBhZ2VzICsgKG5ld19tYXBz
KSAqIFhDX1BBR0VfU0laRTsKICAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAgICAg
Z3JhbnQtPnBhZ2UgPSBpb3JlcS0+cGFnZVtuZXdfbWFwc107CisgICAgICAgICAgICAgICAgYWRk
X3BlcnNpc3RlbnRfcmVnaW9uKGlvcmVxLT5ibGtkZXYsIGlvcmVxLT5wYWdlW25ld19tYXBzXSwg
MSk7CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBncmFudC0+YmxrZGV2ID0gaW9yZXEtPmJs
a2RldjsKICAgICAgICAgICAgIHhlbl9iZV9wcmludGYoJmlvcmVxLT5ibGtkZXYtPnhlbmRldiwg
MywKQEAgLTQ0Nyw2ICs0ODgsNyBAQCBzdGF0aWMgaW50IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEg
KmlvcmVxKQogICAgICAgICAgICAgICAgICAgICAgICAgICBncmFudCk7CiAgICAgICAgICAgICBp
b3JlcS0+YmxrZGV2LT5wZXJzaXN0ZW50X2dudF9jb3VudCsrOwogICAgICAgICB9CisgICAgICAg
IGFzc2VydCghYmF0Y2hfbWFwcyB8fCBuZXdfbWFwcyA9PSAwKTsKICAgICB9CiAgICAgZm9yIChp
ID0gMDsgaSA8IGlvcmVxLT52Lm5pb3Y7IGkrKykgewogICAgICAgICBpb3JlcS0+di5pb3ZbaV0u
aW92X2Jhc2UgKz0gKHVpbnRwdHJfdClwYWdlW2ldOwpAQCAtOTcyLDYgKzEwMTQsNyBAQCBzdGF0
aWMgaW50IGJsa19jb25uZWN0KHN0cnVjdCBYZW5EZXZpY2UgKnhlbmRldikKICAgICAgICAgYmxr
ZGV2LT5wZXJzaXN0ZW50X2dudHMgPSBnX3RyZWVfbmV3X2Z1bGwoKEdDb21wYXJlRGF0YUZ1bmMp
aW50X2NtcCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5V
TEwsIE5VTEwsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAo
R0Rlc3Ryb3lOb3RpZnkpZGVzdHJveV9ncmFudCk7CisgICAgICAgIGJsa2Rldi0+cGVyc2lzdGVu
dF9yZWdpb25zID0gTlVMTDsKICAgICAgICAgYmxrZGV2LT5wZXJzaXN0ZW50X2dudF9jb3VudCA9
IDA7CiAgICAgfQogCkBAIC0xMDAwLDYgKzEwNDMsMTkgQEAgc3RhdGljIHZvaWQgYmxrX2Rpc2Nv
bm5lY3Qoc3RydWN0IFhlbkRldmljZSAqeGVuZGV2KQogICAgICAgICBibGtkZXYtPmNudF9tYXAt
LTsKICAgICAgICAgYmxrZGV2LT5zcmluZyA9IE5VTEw7CiAgICAgfQorCisgICAgLyoKKyAgICAg
KiBVbm1hcCBwZXJzaXN0ZW50IGdyYW50cyBiZWZvcmUgc3dpdGNoaW5nIHRvIHRoZSBjbG9zZWQg
c3RhdGUKKyAgICAgKiBzbyB0aGUgZnJvbnRlbmQgY2FuIGZyZWUgdGhlbS4KKyAgICAgKi8KKyAg
ICBpZiAoYmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKKyAgICAgICAgZ190cmVlX2Rlc3Ry
b3koYmxrZGV2LT5wZXJzaXN0ZW50X2dudHMpOworICAgICAgICBhc3NlcnQoYmxrZGV2LT5wZXJz
aXN0ZW50X2dudF9jb3VudCA9PSAwKTsKKyAgICAgICAgZ19zbGlzdF9mb3JlYWNoKGJsa2Rldi0+
cGVyc2lzdGVudF9yZWdpb25zLAorICAgICAgICAgICAgICAgICAgICAgICAgKEdGdW5jKXJlbW92
ZV9wZXJzaXN0ZW50X3JlZ2lvbiwgYmxrZGV2KTsKKyAgICAgICAgZ19zbGlzdF9mcmVlKGJsa2Rl
di0+cGVyc2lzdGVudF9yZWdpb25zKTsKKyAgICAgICAgYmxrZGV2LT5mZWF0dXJlX3BlcnNpc3Rl
bnQgPSBmYWxzZTsKKyAgICB9CiB9CiAKIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhlbkRl
dmljZSAqeGVuZGV2KQpAQCAtMTAxMSwxMSArMTA2Nyw2IEBAIHN0YXRpYyBpbnQgYmxrX2ZyZWUo
c3RydWN0IFhlbkRldmljZSAqeGVuZGV2KQogICAgICAgICBibGtfZGlzY29ubmVjdCh4ZW5kZXYp
OwogICAgIH0KIAotICAgIC8qIEZyZWUgcGVyc2lzdGVudCBncmFudHMgKi8KLSAgICBpZiAoYmxr
ZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKLSAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxrZGV2
LT5wZXJzaXN0ZW50X2dudHMpOwotICAgIH0KLQogICAgIHdoaWxlICghUUxJU1RfRU1QVFkoJmJs
a2Rldi0+ZnJlZWxpc3QpKSB7CiAgICAgICAgIGlvcmVxID0gUUxJU1RfRklSU1QoJmJsa2Rldi0+
ZnJlZWxpc3QpOwogICAgICAgICBRTElTVF9SRU1PVkUoaW9yZXEsIGxpc3QpOwotLSAKMS45LjMg
KEFwcGxlIEdpdC01MCkKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 13 15:07:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:07:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xovzk-0005Am-UV; Thu, 13 Nov 2014 15:07:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1Xovzj-0005Ah-TY
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 15:07:36 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E0/44-09284-739C4645; Thu, 13 Nov 2014 15:07:35 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415891253!11180318!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5271 invoked from network); 13 Nov 2014 15:07:34 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 15:07:34 -0000
Received: by mail-qa0-f45.google.com with SMTP id dc16so10190886qab.32
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 07:07:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=zxRsKlM2bXCfh6ygkIkhFOE3+fMiYFoRT7RsuRYHkW8=;
	b=OrDSprpjXVOj0LeUghldBN4r0rudB4rgE13UiHVF+obk6oEHrRq7+I7sHKJ5tRNKME
	vD5XD6DtIp+G8lsTJcBMA86SFDjtERxe0KRiT321jcWoXStdZpZymzkgN3DVKN6FQ23M
	sKvFujTc4ZWmE0wP2Auue2FJSm2a67KcWwfx82DC0nRGqBtBvyT/2Lop326j86AiVbgY
	qb9JNX/iiosbJGSa/RCqPkklKRfnUmrKIHcXJ5aSb8PA0iGs2GeEO3QtFIBfAFWEWkUW
	SNJNcGGa2NPwdXXFP1ZHsYuVs+SpG2xKj4KteEoPLFUjsEXr3P+tp18NY6SvR97FwSGe
	z1mg==
X-Received: by 10.140.23.198 with SMTP id 64mr3778944qgp.62.1415891252812;
	Thu, 13 Nov 2014 07:07:32 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.161])
	by mx.google.com with ESMTPSA id r20sm10422960qad.5.2014.11.13.07.07.31
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Thu, 13 Nov 2014 07:07:32 -0800 (PST)
Date: Thu, 13 Nov 2014 12:07:32 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <196307380.20141113120732@gmail.com>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5464C971020000780004739B@mail.emea.novell.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Thanks Jan,

Thursday, November 13, 2014, 11:08:33 AM, you wrote:

>>>> On 13.11.14 at 14:29, <furryfuttock@gmail.com> wrote:
>> I am having 2 major problems at the moment.
>> 
>> 1.- Access to the PCI device from the PV will fail the second time I
>> create it UNLESS I call xl pci-assignable-remove/pci-assignable-add
>> between each creation. If I don't do this then all PCI accesses return
>> -1. I get the same if I disable memory access in the PCI configuration
>> register.
>> 
>> 1.1.- Is this expected behaviour?

> No. But did you verify the driver properly enables the device (i.e.
> doesn't make assumptions on its state)? Also iirc some kernel
> versions weren't properly resetting the device when coming back
> from guest use, but without you stating the software versions
> you're using that's just a remote possibility.

Yes,  the  first thing I do in the driver is set the PCI configuration
access  bits to 7 that should enable IO space, Memory Space and Master
BUS access.

As  a  test I disabled this and all reads to the PCI device return -1,
even the first one.

>> 1.3.-  xl  dmesg  and  dmesg  in Dom0 do not show anything. I have set
>> loglvl=all in the Xen command line.

> "iommu=debug"? But given the symptoms above I don't really think
> this is a problem with the IOMMU.

Added this to the command line and when the PV starts I now see:

(XEN) [VT-D]iommu.c:1593: d0:PCI: unmap 0000:00:19.0
(XEN) [VT-D]iommu.c:1456: d4:PCI: map 0000:00:19.0

And when the PV stops I see

(XEN) [VT-D]iommu.c:1593: d4:PCI: unmap 0000:00:19.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:19.0

No more that this.

>> 2.-  Whenever  I  perform a software reset on the PCI device (it is an
>> Intel  82546  Ethernet  NIC) the hypervisor crashes. There is no oops,
>> kernel  panic  or the like, just a crash. My development device has no
>> serial port so I can't do much debugging.

> A crash would imply you see something telling you it's a crash. If
> you see nothing, I'd rather call it a hang or spontaneous reboot.
> But even without serial port (assuming you can't even plug in a
> serial port PCI card) there are ways to get at eventual crash output
> (register+stack dump): For one, we've got USB debug port support.
> This requires a special cable and there not being an (internal) hub in
> between, but it's worth a consideration. And in the worst case,
> "vga=keep" allows the hypervisor to continue printing to the screen
> even post-boot. But that requires the video mode to not be changed
> from the one Xen uses at boot (i.e. you should not use DRM's KMS,
> and if you need to use X it would need to be configured to use the
> frame buffer driver rather than any accelerating one).

I  agree,  this looks more than a hang than a crash. I've just found a
link to the USB debug cable. I've ordered one but it will take a while
to  get  here  (I  live in Chile). I'll try to enable the vga keep, at
least to see if I can debug this.


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 15:07:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:07:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xovzk-0005Am-UV; Thu, 13 Nov 2014 15:07:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1Xovzj-0005Ah-TY
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 15:07:36 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E0/44-09284-739C4645; Thu, 13 Nov 2014 15:07:35 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415891253!11180318!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5271 invoked from network); 13 Nov 2014 15:07:34 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 15:07:34 -0000
Received: by mail-qa0-f45.google.com with SMTP id dc16so10190886qab.32
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 07:07:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=zxRsKlM2bXCfh6ygkIkhFOE3+fMiYFoRT7RsuRYHkW8=;
	b=OrDSprpjXVOj0LeUghldBN4r0rudB4rgE13UiHVF+obk6oEHrRq7+I7sHKJ5tRNKME
	vD5XD6DtIp+G8lsTJcBMA86SFDjtERxe0KRiT321jcWoXStdZpZymzkgN3DVKN6FQ23M
	sKvFujTc4ZWmE0wP2Auue2FJSm2a67KcWwfx82DC0nRGqBtBvyT/2Lop326j86AiVbgY
	qb9JNX/iiosbJGSa/RCqPkklKRfnUmrKIHcXJ5aSb8PA0iGs2GeEO3QtFIBfAFWEWkUW
	SNJNcGGa2NPwdXXFP1ZHsYuVs+SpG2xKj4KteEoPLFUjsEXr3P+tp18NY6SvR97FwSGe
	z1mg==
X-Received: by 10.140.23.198 with SMTP id 64mr3778944qgp.62.1415891252812;
	Thu, 13 Nov 2014 07:07:32 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.161])
	by mx.google.com with ESMTPSA id r20sm10422960qad.5.2014.11.13.07.07.31
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Thu, 13 Nov 2014 07:07:32 -0800 (PST)
Date: Thu, 13 Nov 2014 12:07:32 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <196307380.20141113120732@gmail.com>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5464C971020000780004739B@mail.emea.novell.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Thanks Jan,

Thursday, November 13, 2014, 11:08:33 AM, you wrote:

>>>> On 13.11.14 at 14:29, <furryfuttock@gmail.com> wrote:
>> I am having 2 major problems at the moment.
>> 
>> 1.- Access to the PCI device from the PV will fail the second time I
>> create it UNLESS I call xl pci-assignable-remove/pci-assignable-add
>> between each creation. If I don't do this then all PCI accesses return
>> -1. I get the same if I disable memory access in the PCI configuration
>> register.
>> 
>> 1.1.- Is this expected behaviour?

> No. But did you verify the driver properly enables the device (i.e.
> doesn't make assumptions on its state)? Also iirc some kernel
> versions weren't properly resetting the device when coming back
> from guest use, but without you stating the software versions
> you're using that's just a remote possibility.

Yes,  the  first thing I do in the driver is set the PCI configuration
access  bits to 7 that should enable IO space, Memory Space and Master
BUS access.

As  a  test I disabled this and all reads to the PCI device return -1,
even the first one.

>> 1.3.-  xl  dmesg  and  dmesg  in Dom0 do not show anything. I have set
>> loglvl=all in the Xen command line.

> "iommu=debug"? But given the symptoms above I don't really think
> this is a problem with the IOMMU.

Added this to the command line and when the PV starts I now see:

(XEN) [VT-D]iommu.c:1593: d0:PCI: unmap 0000:00:19.0
(XEN) [VT-D]iommu.c:1456: d4:PCI: map 0000:00:19.0

And when the PV stops I see

(XEN) [VT-D]iommu.c:1593: d4:PCI: unmap 0000:00:19.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:19.0

No more that this.

>> 2.-  Whenever  I  perform a software reset on the PCI device (it is an
>> Intel  82546  Ethernet  NIC) the hypervisor crashes. There is no oops,
>> kernel  panic  or the like, just a crash. My development device has no
>> serial port so I can't do much debugging.

> A crash would imply you see something telling you it's a crash. If
> you see nothing, I'd rather call it a hang or spontaneous reboot.
> But even without serial port (assuming you can't even plug in a
> serial port PCI card) there are ways to get at eventual crash output
> (register+stack dump): For one, we've got USB debug port support.
> This requires a special cable and there not being an (internal) hub in
> between, but it's worth a consideration. And in the worst case,
> "vga=keep" allows the hypervisor to continue printing to the screen
> even post-boot. But that requires the video mode to not be changed
> from the one Xen uses at boot (i.e. you should not use DRM's KMS,
> and if you need to use X it would need to be configured to use the
> frame buffer driver rather than any accelerating one).

I  agree,  this looks more than a hang than a crash. I've just found a
link to the USB debug cable. I've ordered one but it will take a while
to  get  here  (I  live in Chile). I'll try to enable the vga keep, at
least to see if I can debug this.


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 15:37:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 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.xen.org>)
	id 1XowSO-0005qi-H8; Thu, 13 Nov 2014 15:37:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XowSM-0005qd-QC
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 15:37:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	53/6B-09842-620D4645; Thu, 13 Nov 2014 15:37:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415893027!12506415!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24682 invoked from network); 13 Nov 2014 15:37:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 15:37:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="192450463"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 10:36:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XowRb-000345-AQ;
	Thu, 13 Nov 2014 15:36:23 +0000
Date: Thu, 13 Nov 2014 15:36:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1415890703-10147-1-git-send-email-roger.pau@citrix.com>
Message-ID: <alpine.DEB.2.02.1411131513470.26318@kaball.uk.xensource.com>
References: <1415890703-10147-1-git-send-email-roger.pau@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1213237974-1415891636=:26318"
Content-ID: <alpine.DEB.2.02.1411131518220.26318@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2 for-xen-4.5] xen_disk: fix unmapping of
 persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1213237974-1415891636=:26318
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1411131518221.26318@kaball.uk.xensource.com>

On Thu, 13 Nov 2014, Roger Pau Monne wrote:
> This patch fixes two issues with persistent grants and the disk PV backen=
d
> (Qdisk):
>=20
>  - Keep track of memory regions where persistent grants have been mapped
>    since we need to unmap them as a whole. It is not possible to unmap a
>    single grant if it has been batch-mapped.
>  - Unmap persistent grants before switching to the closed state, so the
>    frontend can also free them.
>=20
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> Reported-by: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Kevin Wolf <kwolf@redhat.com>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Xen release exception: this is obviously an important bug-fix that should=
 be
> included in 4.5. Without this fix, trying to do a block-detach of a Qdisk
> from a running guest can lead to guest crash depending on the blkfront
> implementation.
> ---
> Changes since v1:
>  - Instead of disabling batch mappings when using persistent grants, keep
>    track of the persistently mapped regions and unmap them on disconnecti=
on.
>    This prevents unmapping single persistent grants, but the current
>    implementation doesn't require it.
>=20
> This new version is slightly faster than the previous one, the following
> test results are in IOPS from 20 runs of a block-attach, fio run,
> block-detach test loop:
>=20
> x batch
> + no_batch
> +----------------------------------------------------------------------+
> |                                      +   +     x    x + + +  x xx x  |
> |+  +           x                     x+  *+++   *  +x* +++x*  x xx x *|
> |                                          |_____________A_____M______||
> |                            |________________A_____M___________|      |
> +----------------------------------------------------------------------+
>     N           Min           Max        Median           Avg        Stdd=
ev
> x  20         52941         63822         62396      61180.15     2673.64=
97
> +  20         49967         63849         60322       59116.9     3456.34=
55
> Difference at 95.0% confidence
> =09-2063.25 +/- 1977.66
> =09-3.37242% +/- 3.23252%
> =09(Student's t, pooled s =3D 3089.88)

Not too bad! Thanks!


>  hw/block/xen_disk.c | 77 ++++++++++++++++++++++++++++++++++++++++++++---=
------
>  1 file changed, 64 insertions(+), 13 deletions(-)
>=20
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 231e9a7..75bdc16 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -59,6 +59,13 @@ struct PersistentGrant {
> =20
>  typedef struct PersistentGrant PersistentGrant;
> =20
> +struct PersistentRegion {
> +    void *addr;
> +    int num;
> +};
> +
> +typedef struct PersistentRegion PersistentRegion;
> +
>  struct ioreq {
>      blkif_request_t     req;
>      int16_t             status;
> @@ -118,6 +125,7 @@ struct XenBlkDev {
>      gboolean            feature_discard;
>      gboolean            feature_persistent;
>      GTree               *persistent_gnts;
> +    GSList              *persistent_regions;
>      unsigned int        persistent_gnt_count;
>      unsigned int        max_grants;
> =20
> @@ -164,19 +172,41 @@ static gint int_cmp(gconstpointer a, gconstpointer =
b, gpointer user_data)
>  static void destroy_grant(gpointer pgnt)
>  {
>      PersistentGrant *grant =3D pgnt;
> -    XenGnttab gnt =3D grant->blkdev->xendev.gnttabdev;
> =20
> -    if (xc_gnttab_munmap(gnt, grant->page, 1) !=3D 0) {
> -        xen_be_printf(&grant->blkdev->xendev, 0,
> -                      "xc_gnttab_munmap failed: %s\n",
> -                      strerror(errno));
> -    }
>      grant->blkdev->persistent_gnt_count--;
>      xen_be_printf(&grant->blkdev->xendev, 3,
> -                  "unmapped grant %p\n", grant->page);
> +                  "removed grant %p\n", grant->page);
>      g_free(grant);
>  }
> =20
> +static void add_persistent_region(struct XenBlkDev *blkdev, void *addr, =
int num)
> +{
> +    PersistentRegion *region;
> +
> +    region =3D g_malloc0(sizeof(*region));
> +    region->addr =3D addr;
> +    region->num =3D num;
> +    blkdev->persistent_regions =3D g_slist_append(blkdev->persistent_reg=
ions,
> +                                                region);
> +}
> +
> +static void remove_persistent_region(gpointer data, gpointer dev)
> +{
> +    PersistentRegion *region =3D data;
> +    struct XenBlkDev *blkdev =3D dev;
> +    XenGnttab gnt =3D blkdev->xendev.gnttabdev;
> +
> +    if (xc_gnttab_munmap(gnt, region->addr, region->num) !=3D 0) {
> +        xen_be_printf(&blkdev->xendev, 0,
> +                      "xc_gnttab_munmap region %p failed: %s\n",
> +                      region->addr, strerror(errno));
> +    }
> +    xen_be_printf(&blkdev->xendev, 3,
> +                  "unmapped grant region %p with %d pages\n",
> +                  region->addr, region->num);
> +    g_free(region);
> +}
> +
>  static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
>  {
>      struct ioreq *ioreq =3D NULL;
> @@ -421,7 +451,17 @@ static int ioreq_map(struct ioreq *ioreq)
>              }
>          }
>      }
> -    if (ioreq->blkdev->feature_persistent) {
> +    if (ioreq->blkdev->feature_persistent && new_maps &&
> +        (!batch_maps || (ioreq->blkdev->persistent_gnt_count + new_maps =
<=3D
> +        ioreq->blkdev->max_grants))) {

Do we really need this change? If so, could you please write something
about it in the commit message?


> +        /*
> +         * If we are using persistent grants and batch mappings only
> +         * add the new maps to the list of persistent grants if the whol=
e
> +         * area can be persistently mapped.
> +         */

Is this the reason for the change above?


> +        if (batch_maps && new_maps) {
> +            add_persistent_region(ioreq->blkdev, ioreq->pages, new_maps)=
;
> +        }
>
>          while ((ioreq->blkdev->persistent_gnt_count < ioreq->blkdev->max=
_grants)
>                && new_maps) {
>              /* Go through the list of newly mapped grants and add as man=
y
> @@ -437,6 +477,7 @@ static int ioreq_map(struct ioreq *ioreq)
>                  grant->page =3D ioreq->pages + (new_maps) * XC_PAGE_SIZE=
;
>              } else {
>                  grant->page =3D ioreq->page[new_maps];
> +                add_persistent_region(ioreq->blkdev, ioreq->page[new_map=
s], 1);

Basically in the !batch_maps case we are duplicating persistent_gnts
into persistent_regions. Couldn't we just avoid calling
add_persistent_region at all in that case and rely on the old
destroy_grant function? In fact I think we could just pass NULL as
GDestroyNotify function when creating persistent_gnts if batch_maps and
the old unmodified destroy_grant if !batch_maps.

>              }
>              grant->blkdev =3D ioreq->blkdev;
>              xen_be_printf(&ioreq->blkdev->xendev, 3,
> @@ -447,6 +488,7 @@ static int ioreq_map(struct ioreq *ioreq)
>                            grant);
>              ioreq->blkdev->persistent_gnt_count++;
>          }
> +        assert(!batch_maps || new_maps =3D=3D 0);

Shouldn't new_maps be =3D=3D 0 even in the !batch_maps case?


>      }
>      for (i =3D 0; i < ioreq->v.niov; i++) {
>          ioreq->v.iov[i].iov_base +=3D (uintptr_t)page[i];
> @@ -972,6 +1014,7 @@ static int blk_connect(struct XenDevice *xendev)
>          blkdev->persistent_gnts =3D g_tree_new_full((GCompareDataFunc)in=
t_cmp,
>                                               NULL, NULL,
>                                               (GDestroyNotify)destroy_gra=
nt);
> +        blkdev->persistent_regions =3D NULL;
>          blkdev->persistent_gnt_count =3D 0;
>      }
> =20
> @@ -1000,6 +1043,19 @@ static void blk_disconnect(struct XenDevice *xende=
v)
>          blkdev->cnt_map--;
>          blkdev->sring =3D NULL;
>      }
> +
> +    /*
> +     * Unmap persistent grants before switching to the closed state
> +     * so the frontend can free them.
> +     */
> +    if (blkdev->feature_persistent) {
> +        g_tree_destroy(blkdev->persistent_gnts);
> +        assert(blkdev->persistent_gnt_count =3D=3D 0);
> +        g_slist_foreach(blkdev->persistent_regions,
> +                        (GFunc)remove_persistent_region, blkdev);
> +        g_slist_free(blkdev->persistent_regions);
> +        blkdev->feature_persistent =3D false;
> +    }
>  }
> =20
>  static int blk_free(struct XenDevice *xendev)
> @@ -1011,11 +1067,6 @@ static int blk_free(struct XenDevice *xendev)
>          blk_disconnect(xendev);
>      }
> =20
> -    /* Free persistent grants */
> -    if (blkdev->feature_persistent) {
> -        g_tree_destroy(blkdev->persistent_gnts);
> -    }
> -
>      while (!QLIST_EMPTY(&blkdev->freelist)) {
>          ioreq =3D QLIST_FIRST(&blkdev->freelist);
>          QLIST_REMOVE(ioreq, list);
> --=20
> 1.9.3 (Apple Git-50)
>=20
--1342847746-1213237974-1415891636=:26318
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1213237974-1415891636=:26318--


From xen-devel-bounces@lists.xen.org Thu Nov 13 15:37:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 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.xen.org>)
	id 1XowSO-0005qi-H8; Thu, 13 Nov 2014 15:37:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XowSM-0005qd-QC
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 15:37:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	53/6B-09842-620D4645; Thu, 13 Nov 2014 15:37:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415893027!12506415!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24682 invoked from network); 13 Nov 2014 15:37:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 15:37:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="192450463"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 10:36:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XowRb-000345-AQ;
	Thu, 13 Nov 2014 15:36:23 +0000
Date: Thu, 13 Nov 2014 15:36:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1415890703-10147-1-git-send-email-roger.pau@citrix.com>
Message-ID: <alpine.DEB.2.02.1411131513470.26318@kaball.uk.xensource.com>
References: <1415890703-10147-1-git-send-email-roger.pau@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1213237974-1415891636=:26318"
Content-ID: <alpine.DEB.2.02.1411131518220.26318@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2 for-xen-4.5] xen_disk: fix unmapping of
 persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1213237974-1415891636=:26318
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1411131518221.26318@kaball.uk.xensource.com>

On Thu, 13 Nov 2014, Roger Pau Monne wrote:
> This patch fixes two issues with persistent grants and the disk PV backen=
d
> (Qdisk):
>=20
>  - Keep track of memory regions where persistent grants have been mapped
>    since we need to unmap them as a whole. It is not possible to unmap a
>    single grant if it has been batch-mapped.
>  - Unmap persistent grants before switching to the closed state, so the
>    frontend can also free them.
>=20
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> Reported-by: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Kevin Wolf <kwolf@redhat.com>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Xen release exception: this is obviously an important bug-fix that should=
 be
> included in 4.5. Without this fix, trying to do a block-detach of a Qdisk
> from a running guest can lead to guest crash depending on the blkfront
> implementation.
> ---
> Changes since v1:
>  - Instead of disabling batch mappings when using persistent grants, keep
>    track of the persistently mapped regions and unmap them on disconnecti=
on.
>    This prevents unmapping single persistent grants, but the current
>    implementation doesn't require it.
>=20
> This new version is slightly faster than the previous one, the following
> test results are in IOPS from 20 runs of a block-attach, fio run,
> block-detach test loop:
>=20
> x batch
> + no_batch
> +----------------------------------------------------------------------+
> |                                      +   +     x    x + + +  x xx x  |
> |+  +           x                     x+  *+++   *  +x* +++x*  x xx x *|
> |                                          |_____________A_____M______||
> |                            |________________A_____M___________|      |
> +----------------------------------------------------------------------+
>     N           Min           Max        Median           Avg        Stdd=
ev
> x  20         52941         63822         62396      61180.15     2673.64=
97
> +  20         49967         63849         60322       59116.9     3456.34=
55
> Difference at 95.0% confidence
> =09-2063.25 +/- 1977.66
> =09-3.37242% +/- 3.23252%
> =09(Student's t, pooled s =3D 3089.88)

Not too bad! Thanks!


>  hw/block/xen_disk.c | 77 ++++++++++++++++++++++++++++++++++++++++++++---=
------
>  1 file changed, 64 insertions(+), 13 deletions(-)
>=20
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 231e9a7..75bdc16 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -59,6 +59,13 @@ struct PersistentGrant {
> =20
>  typedef struct PersistentGrant PersistentGrant;
> =20
> +struct PersistentRegion {
> +    void *addr;
> +    int num;
> +};
> +
> +typedef struct PersistentRegion PersistentRegion;
> +
>  struct ioreq {
>      blkif_request_t     req;
>      int16_t             status;
> @@ -118,6 +125,7 @@ struct XenBlkDev {
>      gboolean            feature_discard;
>      gboolean            feature_persistent;
>      GTree               *persistent_gnts;
> +    GSList              *persistent_regions;
>      unsigned int        persistent_gnt_count;
>      unsigned int        max_grants;
> =20
> @@ -164,19 +172,41 @@ static gint int_cmp(gconstpointer a, gconstpointer =
b, gpointer user_data)
>  static void destroy_grant(gpointer pgnt)
>  {
>      PersistentGrant *grant =3D pgnt;
> -    XenGnttab gnt =3D grant->blkdev->xendev.gnttabdev;
> =20
> -    if (xc_gnttab_munmap(gnt, grant->page, 1) !=3D 0) {
> -        xen_be_printf(&grant->blkdev->xendev, 0,
> -                      "xc_gnttab_munmap failed: %s\n",
> -                      strerror(errno));
> -    }
>      grant->blkdev->persistent_gnt_count--;
>      xen_be_printf(&grant->blkdev->xendev, 3,
> -                  "unmapped grant %p\n", grant->page);
> +                  "removed grant %p\n", grant->page);
>      g_free(grant);
>  }
> =20
> +static void add_persistent_region(struct XenBlkDev *blkdev, void *addr, =
int num)
> +{
> +    PersistentRegion *region;
> +
> +    region =3D g_malloc0(sizeof(*region));
> +    region->addr =3D addr;
> +    region->num =3D num;
> +    blkdev->persistent_regions =3D g_slist_append(blkdev->persistent_reg=
ions,
> +                                                region);
> +}
> +
> +static void remove_persistent_region(gpointer data, gpointer dev)
> +{
> +    PersistentRegion *region =3D data;
> +    struct XenBlkDev *blkdev =3D dev;
> +    XenGnttab gnt =3D blkdev->xendev.gnttabdev;
> +
> +    if (xc_gnttab_munmap(gnt, region->addr, region->num) !=3D 0) {
> +        xen_be_printf(&blkdev->xendev, 0,
> +                      "xc_gnttab_munmap region %p failed: %s\n",
> +                      region->addr, strerror(errno));
> +    }
> +    xen_be_printf(&blkdev->xendev, 3,
> +                  "unmapped grant region %p with %d pages\n",
> +                  region->addr, region->num);
> +    g_free(region);
> +}
> +
>  static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
>  {
>      struct ioreq *ioreq =3D NULL;
> @@ -421,7 +451,17 @@ static int ioreq_map(struct ioreq *ioreq)
>              }
>          }
>      }
> -    if (ioreq->blkdev->feature_persistent) {
> +    if (ioreq->blkdev->feature_persistent && new_maps &&
> +        (!batch_maps || (ioreq->blkdev->persistent_gnt_count + new_maps =
<=3D
> +        ioreq->blkdev->max_grants))) {

Do we really need this change? If so, could you please write something
about it in the commit message?


> +        /*
> +         * If we are using persistent grants and batch mappings only
> +         * add the new maps to the list of persistent grants if the whol=
e
> +         * area can be persistently mapped.
> +         */

Is this the reason for the change above?


> +        if (batch_maps && new_maps) {
> +            add_persistent_region(ioreq->blkdev, ioreq->pages, new_maps)=
;
> +        }
>
>          while ((ioreq->blkdev->persistent_gnt_count < ioreq->blkdev->max=
_grants)
>                && new_maps) {
>              /* Go through the list of newly mapped grants and add as man=
y
> @@ -437,6 +477,7 @@ static int ioreq_map(struct ioreq *ioreq)
>                  grant->page =3D ioreq->pages + (new_maps) * XC_PAGE_SIZE=
;
>              } else {
>                  grant->page =3D ioreq->page[new_maps];
> +                add_persistent_region(ioreq->blkdev, ioreq->page[new_map=
s], 1);

Basically in the !batch_maps case we are duplicating persistent_gnts
into persistent_regions. Couldn't we just avoid calling
add_persistent_region at all in that case and rely on the old
destroy_grant function? In fact I think we could just pass NULL as
GDestroyNotify function when creating persistent_gnts if batch_maps and
the old unmodified destroy_grant if !batch_maps.

>              }
>              grant->blkdev =3D ioreq->blkdev;
>              xen_be_printf(&ioreq->blkdev->xendev, 3,
> @@ -447,6 +488,7 @@ static int ioreq_map(struct ioreq *ioreq)
>                            grant);
>              ioreq->blkdev->persistent_gnt_count++;
>          }
> +        assert(!batch_maps || new_maps =3D=3D 0);

Shouldn't new_maps be =3D=3D 0 even in the !batch_maps case?


>      }
>      for (i =3D 0; i < ioreq->v.niov; i++) {
>          ioreq->v.iov[i].iov_base +=3D (uintptr_t)page[i];
> @@ -972,6 +1014,7 @@ static int blk_connect(struct XenDevice *xendev)
>          blkdev->persistent_gnts =3D g_tree_new_full((GCompareDataFunc)in=
t_cmp,
>                                               NULL, NULL,
>                                               (GDestroyNotify)destroy_gra=
nt);
> +        blkdev->persistent_regions =3D NULL;
>          blkdev->persistent_gnt_count =3D 0;
>      }
> =20
> @@ -1000,6 +1043,19 @@ static void blk_disconnect(struct XenDevice *xende=
v)
>          blkdev->cnt_map--;
>          blkdev->sring =3D NULL;
>      }
> +
> +    /*
> +     * Unmap persistent grants before switching to the closed state
> +     * so the frontend can free them.
> +     */
> +    if (blkdev->feature_persistent) {
> +        g_tree_destroy(blkdev->persistent_gnts);
> +        assert(blkdev->persistent_gnt_count =3D=3D 0);
> +        g_slist_foreach(blkdev->persistent_regions,
> +                        (GFunc)remove_persistent_region, blkdev);
> +        g_slist_free(blkdev->persistent_regions);
> +        blkdev->feature_persistent =3D false;
> +    }
>  }
> =20
>  static int blk_free(struct XenDevice *xendev)
> @@ -1011,11 +1067,6 @@ static int blk_free(struct XenDevice *xendev)
>          blk_disconnect(xendev);
>      }
> =20
> -    /* Free persistent grants */
> -    if (blkdev->feature_persistent) {
> -        g_tree_destroy(blkdev->persistent_gnts);
> -    }
> -
>      while (!QLIST_EMPTY(&blkdev->freelist)) {
>          ioreq =3D QLIST_FIRST(&blkdev->freelist);
>          QLIST_REMOVE(ioreq, list);
> --=20
> 1.9.3 (Apple Git-50)
>=20
--1342847746-1213237974-1415891636=:26318
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1213237974-1415891636=:26318--


From xen-devel-bounces@lists.xen.org Thu Nov 13 15:47:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xowbx-0006AQ-LI; Thu, 13 Nov 2014 15:47:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xowbv-0006AL-3B
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 15:47:03 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	23/E1-11608-672D4645; Thu, 13 Nov 2014 15:47:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415893621!7464894!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6303 invoked from network); 13 Nov 2014 15:47:01 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 15:47:01 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xowbd-000PIK-EG; Thu, 13 Nov 2014 15:46:45 +0000
Date: Thu, 13 Nov 2014 16:46:45 +0100
From: Tim Deegan <tim@xen.org>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20141113154645.GB74761@deinos.phlegethon.org>
References: <1413370425-15015-1-git-send-email-roger.pau@citrix.com>
	<1413370425-15015-2-git-send-email-roger.pau@citrix.com>
	<20141016092005.GB71219@deinos.phlegethon.org>
	<543F97D6.7080702@citrix.com>
MIME-Version: 1.0
Content-Length: 3192
Content-Disposition: inline
In-Reply-To: <543F97D6.7080702@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH RFC 1/2] xen/pvh: take the p2m lock when
 doing logdirty ops from HVM domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:03 +0200 on 16 Oct (1413457382), Roger Pau Monn=E9 wrote:
> El 16/10/14 a les 11.20, Tim Deegan ha escrit:
> > Ah, I see.  This is the _caller_'s p2m lock but the _target_'s paging
> > lock.  Holding the caller's p2m lock to unstick this seems a bit of a
> > strange answer -- the paging op might be quite a long one.  And having
> > all vcpus take their own p2m locks before remote paging locks (and
> > probably other MM locks too operations) is going to be quite messy.
> >
> > I guess the tricky path is clear_user_hvm, writing the bitmap back to
> > the caller's memory.  I wonder whether we could use unlocked p2m
> > lookups for that.  Probably not, because what if the caller's memory is
> > PoD, etc?
> =

> Yes, the functions that need the caller p2m lock is
> clear_user_hvm/copy_to_user_hvm. If I'm not mistaken we explicitly
> stated that PVH is not going to use PoD, but since we are there we can
> try to fix this function so it can work with pure HVM domains that can
> indeed use PoD.
> =

> > Getting hold of all the bitmap pages before taking the lock would be
> > messy too.
> >
> > So this may end up being the least bad answer but I'd like to see if
> > we can think of something better first.
> =

> I'm certainly open to ideas, this was the naive way I've found to fixing =
it.

Sorry for the delay getting back to this -- I'm aware that I
discouraged this patch without suggesting an alternative!

I've looked through the hypervisor for callers of copy_to_guest() and
similar functions and they're almost all either:
 - at the head or tail of a hypercall; or
 - in code which doesn't touch any other domain (e.g. ctxt switch).

The only interesting cases are:
 - paging_log_dirty_op(), which as you pointed out writes the bitmap
   back to the caller while still holding the target's paging lock.
 - shadow_track_dirty_vram(), likewise.
 - hap_track_dirty_vram(), which allocates a local buffer to build
   the bitmap in and then writes it back after dropping the lock
   (and so should be OK).
 - XEN_DOMCTL_getmemlist, which has a similar issue with
   d->page_alloc_lock, for which reason it's already restricted to
   non-paging-mode-external guests (and so also OK).

shadow_track_dirty_vram() can probably be made to behave like
hap_track_dirty_vram() -- at the moment it needs the lock because it's
copying from a shared master bitmap, but it could either copy it twice
(ugh) or do some RCU-like thing to allow the copies to happen outside
the paging lock.

That leaves paging_log_dirty_op().  The inner loops of that function
are already set up to be preempted for softirqs, &c.  I wonder could
we arrange for it to map the first N pages of bitmap before taking any
locks, and then drop the locks after that many pages, and unmap them
again.

It wouldn't even need to actually set up a hypercall continuation if =

!hypercall_preempt_check(); it can simply map a new batch and carry
on.

Does that sounds plausible?  If so, then we can leave the lock
constraints as they are, which would make me very happy. :)

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 Nov 13 15:47:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xowbx-0006AQ-LI; Thu, 13 Nov 2014 15:47:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xowbv-0006AL-3B
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 15:47:03 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	23/E1-11608-672D4645; Thu, 13 Nov 2014 15:47:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415893621!7464894!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6303 invoked from network); 13 Nov 2014 15:47:01 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 15:47:01 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xowbd-000PIK-EG; Thu, 13 Nov 2014 15:46:45 +0000
Date: Thu, 13 Nov 2014 16:46:45 +0100
From: Tim Deegan <tim@xen.org>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20141113154645.GB74761@deinos.phlegethon.org>
References: <1413370425-15015-1-git-send-email-roger.pau@citrix.com>
	<1413370425-15015-2-git-send-email-roger.pau@citrix.com>
	<20141016092005.GB71219@deinos.phlegethon.org>
	<543F97D6.7080702@citrix.com>
MIME-Version: 1.0
Content-Length: 3192
Content-Disposition: inline
In-Reply-To: <543F97D6.7080702@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH RFC 1/2] xen/pvh: take the p2m lock when
 doing logdirty ops from HVM domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:03 +0200 on 16 Oct (1413457382), Roger Pau Monn=E9 wrote:
> El 16/10/14 a les 11.20, Tim Deegan ha escrit:
> > Ah, I see.  This is the _caller_'s p2m lock but the _target_'s paging
> > lock.  Holding the caller's p2m lock to unstick this seems a bit of a
> > strange answer -- the paging op might be quite a long one.  And having
> > all vcpus take their own p2m locks before remote paging locks (and
> > probably other MM locks too operations) is going to be quite messy.
> >
> > I guess the tricky path is clear_user_hvm, writing the bitmap back to
> > the caller's memory.  I wonder whether we could use unlocked p2m
> > lookups for that.  Probably not, because what if the caller's memory is
> > PoD, etc?
> =

> Yes, the functions that need the caller p2m lock is
> clear_user_hvm/copy_to_user_hvm. If I'm not mistaken we explicitly
> stated that PVH is not going to use PoD, but since we are there we can
> try to fix this function so it can work with pure HVM domains that can
> indeed use PoD.
> =

> > Getting hold of all the bitmap pages before taking the lock would be
> > messy too.
> >
> > So this may end up being the least bad answer but I'd like to see if
> > we can think of something better first.
> =

> I'm certainly open to ideas, this was the naive way I've found to fixing =
it.

Sorry for the delay getting back to this -- I'm aware that I
discouraged this patch without suggesting an alternative!

I've looked through the hypervisor for callers of copy_to_guest() and
similar functions and they're almost all either:
 - at the head or tail of a hypercall; or
 - in code which doesn't touch any other domain (e.g. ctxt switch).

The only interesting cases are:
 - paging_log_dirty_op(), which as you pointed out writes the bitmap
   back to the caller while still holding the target's paging lock.
 - shadow_track_dirty_vram(), likewise.
 - hap_track_dirty_vram(), which allocates a local buffer to build
   the bitmap in and then writes it back after dropping the lock
   (and so should be OK).
 - XEN_DOMCTL_getmemlist, which has a similar issue with
   d->page_alloc_lock, for which reason it's already restricted to
   non-paging-mode-external guests (and so also OK).

shadow_track_dirty_vram() can probably be made to behave like
hap_track_dirty_vram() -- at the moment it needs the lock because it's
copying from a shared master bitmap, but it could either copy it twice
(ugh) or do some RCU-like thing to allow the copies to happen outside
the paging lock.

That leaves paging_log_dirty_op().  The inner loops of that function
are already set up to be preempted for softirqs, &c.  I wonder could
we arrange for it to map the first N pages of bitmap before taking any
locks, and then drop the locks after that many pages, and unmap them
again.

It wouldn't even need to actually set up a hypercall continuation if =

!hypercall_preempt_check(); it can simply map a new batch and carry
on.

Does that sounds plausible?  If so, then we can leave the lock
constraints as they are, which would make me very happy. :)

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 Nov 13 15:47:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XowcF-0006C2-1K; Thu, 13 Nov 2014 15:47:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <martin@lucina.net>) id 1XowbF-0006A1-Tf
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 15:46:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	59/3E-09936-D42D4645; Thu, 13 Nov 2014 15:46:21 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415893580!12564801!1
X-Originating-IP: [62.176.169.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14517 invoked from network); 13 Nov 2014 15:46:20 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 15:46:20 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id BF96318057BA;
	Thu, 13 Nov 2014 16:46:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1415893579;
	bh=3hcr/oP1+hFiN7D0OBhPJ+eV95Qo46ZodpgC0lSPNrw=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=ct8Cow3GV1j3yGkraiKDS8QA/NNA3rVQywH+uRZCNOb/+WnH6JSJYfSz7J4AzoUEW
	TfYIc3MM1Da6UQlGDect4dEw2WZUNsFESdycrmOmc6N0KlOfCMM11gUEbP6TuoyN/H
	EPYWlGHzKKluk9kv4kOhi3gI9wnVVAC7mskt6PWVcISL2SIrRIFu/Mg4k+w9GJP6uo
	BRghx3eS+DqhByXjANf/uVPXZ8eF4u4QB7KuIX4juMF2Xl0dGDJTjC9FNjEpr0FljI
	JGezYvrXuOZXvw9gT9z2GFnxWVNNhIOzQmUtxkJRldk8LEnG4ZEVLBAa6Fkrt7DzTq
	xWuReEBphMo5A==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id D7F594C0E2D; Thu, 13 Nov 2014 16:46:34 +0100 (CET)
Date: Thu, 13 Nov 2014 16:46:34 +0100
From: Martin Lucina <martin@lucina.net>
To: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org,
	Ian.Jackson@eu.citrix.com
Message-ID: <20141113154634.GA9560@nodbug.moloch.sk>
Mail-Followup-To: rumpkernel-users@lists.sourceforge.net,
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464BB03.7090801@iki.fi>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 13 Nov 2014 15:47:21 +0000
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Following is the high-level description from the Git commit:
> 
> Can you also post an example of the usage of your CLI tool?  Actually, 
> can you post a rough description of the entire process that a user would 
> have to follow, i.e. compile, configure, run.

Running "xr" with no parameters gives a nice command reference :-)

Anyhow:

Simple hello world using tests/hello/hello built as part of buildxen.sh:

 # xr run -i tests/hello/hello

Running a webserver:

Get mathopd source from http://mathopd.org/. I used mathopd as it's BSD
licensed, non-forking and small. To build and run it:

1. git clone, buildxen.sh

2. Put app-tools at the *END* of your $PATH. There is a bug/interaction
with the app-tools ld that breaks things if you put it before the real ld.

3. (in mathopd/src) rumpapp-xen-make

4. You need filesystem images for a stub /etc and /data. I am using cd9660
for these as you can portably generate that anywhere you have genisoimage
(ex mkisofs). (see below)

5. Assuming you have those, run the following in the mathopd src directory,
as root:

 # xr run -i -n inet:dhcp -b etc.iso:/etc -b data.iso:/data mathopd -nt -f /etc/mathopd.conf

This will configure xenif0 using dhcp/ipv4, mount /etc and /data using the
respective images and then run "mathopd -nt -f /etc/mathopd.conf". The
mathopd options tell it not to fork into the background and to write logs
to standard output.

That's all :-)

Next step for me is to add a copy of mathopd as a demo into rumprun-xen.
As part of that demo I will add scripts to rebuild the filesystem images,
but probably not do that in the default build so as not to introduce a hard
dependency on genisoimage.

I then plan to experiment getting a full LAMP stack or similar running
across multiple VMs but I need to stabilise the simple case with mathopd
serving a static website first, there are still several bugs lurking there.

> >   - The rumpconfig module provides _rumprun_config() and
> >     _rumprun_deconfig() functions. These are called before and after the
> >     application main() function, and also in the case of deconfig when
> >     _exit() is called.
> 
> Is deconfig necessary?  The rump kernel already automatically e.g. 
> unmounts file systems and releases the dhcp lease when it's halted.

It does unmount filesystems (if halted correctly) but afaict it does not do
rump_pub_etfs_remove() and the dhcp stuff does not destroy the interface.
This is nitpicking, but if you don't do that then the underlying
blkfront/netfront does not get "correctly" detached either as you can see
from "port X still bound!" messages during minios_stop_kernel().

> >      Secondly, it is my intention with this work to provide a
> >      "docker-alike" interface for running rumprun applications. The "xr"
> >      script is therefore the CLI for running such applications.
> 
> The user-facing configuration tool was sorely needed.  I hate to go into 
> naming, but ... can we call the tool "rumprun"?  I think your tool will 
> be the basis for running rumprun stacks beyond Xen, and we should try to 
> avoid the user-visible syntax having any obvious shortcomings.

Guess so. In my mind there is potentially more the tool can do than just
run rumprun stacks, for example:

 - manage interaction with the host networking, map host ports to
   domain:port
 - generate or otherwise manage filesystem images (eg we could have a
   custom DNS server)
 - manage stack naming on the host, this is a bit daft at the moment, eg.
   if you try to run two copies of mathopd it will fall over due to the Xen
   domain name not being unique

And so on. Maybe this can be layered into separate tools with the 'rumprun'
script dealing only with launching. Needs more thought.

> > Note that in this initial version, only configuring IPv4 network
> > interfaces with DHCP is supported, and only using image files with ffs
> > or cd9660 filesystems for block devices is supported.
> 
> Would e.g. IPv6 support take longer than it took to write that paragraph ?-)

<taptaptap> ;)

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 15:47:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XowcF-0006C2-1K; Thu, 13 Nov 2014 15:47:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <martin@lucina.net>) id 1XowbF-0006A1-Tf
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 15:46:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	59/3E-09936-D42D4645; Thu, 13 Nov 2014 15:46:21 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415893580!12564801!1
X-Originating-IP: [62.176.169.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14517 invoked from network); 13 Nov 2014 15:46:20 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 15:46:20 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id BF96318057BA;
	Thu, 13 Nov 2014 16:46:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1415893579;
	bh=3hcr/oP1+hFiN7D0OBhPJ+eV95Qo46ZodpgC0lSPNrw=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=ct8Cow3GV1j3yGkraiKDS8QA/NNA3rVQywH+uRZCNOb/+WnH6JSJYfSz7J4AzoUEW
	TfYIc3MM1Da6UQlGDect4dEw2WZUNsFESdycrmOmc6N0KlOfCMM11gUEbP6TuoyN/H
	EPYWlGHzKKluk9kv4kOhi3gI9wnVVAC7mskt6PWVcISL2SIrRIFu/Mg4k+w9GJP6uo
	BRghx3eS+DqhByXjANf/uVPXZ8eF4u4QB7KuIX4juMF2Xl0dGDJTjC9FNjEpr0FljI
	JGezYvrXuOZXvw9gT9z2GFnxWVNNhIOzQmUtxkJRldk8LEnG4ZEVLBAa6Fkrt7DzTq
	xWuReEBphMo5A==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id D7F594C0E2D; Thu, 13 Nov 2014 16:46:34 +0100 (CET)
Date: Thu, 13 Nov 2014 16:46:34 +0100
From: Martin Lucina <martin@lucina.net>
To: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org,
	Ian.Jackson@eu.citrix.com
Message-ID: <20141113154634.GA9560@nodbug.moloch.sk>
Mail-Followup-To: rumpkernel-users@lists.sourceforge.net,
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464BB03.7090801@iki.fi>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 13 Nov 2014 15:47:21 +0000
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Following is the high-level description from the Git commit:
> 
> Can you also post an example of the usage of your CLI tool?  Actually, 
> can you post a rough description of the entire process that a user would 
> have to follow, i.e. compile, configure, run.

Running "xr" with no parameters gives a nice command reference :-)

Anyhow:

Simple hello world using tests/hello/hello built as part of buildxen.sh:

 # xr run -i tests/hello/hello

Running a webserver:

Get mathopd source from http://mathopd.org/. I used mathopd as it's BSD
licensed, non-forking and small. To build and run it:

1. git clone, buildxen.sh

2. Put app-tools at the *END* of your $PATH. There is a bug/interaction
with the app-tools ld that breaks things if you put it before the real ld.

3. (in mathopd/src) rumpapp-xen-make

4. You need filesystem images for a stub /etc and /data. I am using cd9660
for these as you can portably generate that anywhere you have genisoimage
(ex mkisofs). (see below)

5. Assuming you have those, run the following in the mathopd src directory,
as root:

 # xr run -i -n inet:dhcp -b etc.iso:/etc -b data.iso:/data mathopd -nt -f /etc/mathopd.conf

This will configure xenif0 using dhcp/ipv4, mount /etc and /data using the
respective images and then run "mathopd -nt -f /etc/mathopd.conf". The
mathopd options tell it not to fork into the background and to write logs
to standard output.

That's all :-)

Next step for me is to add a copy of mathopd as a demo into rumprun-xen.
As part of that demo I will add scripts to rebuild the filesystem images,
but probably not do that in the default build so as not to introduce a hard
dependency on genisoimage.

I then plan to experiment getting a full LAMP stack or similar running
across multiple VMs but I need to stabilise the simple case with mathopd
serving a static website first, there are still several bugs lurking there.

> >   - The rumpconfig module provides _rumprun_config() and
> >     _rumprun_deconfig() functions. These are called before and after the
> >     application main() function, and also in the case of deconfig when
> >     _exit() is called.
> 
> Is deconfig necessary?  The rump kernel already automatically e.g. 
> unmounts file systems and releases the dhcp lease when it's halted.

It does unmount filesystems (if halted correctly) but afaict it does not do
rump_pub_etfs_remove() and the dhcp stuff does not destroy the interface.
This is nitpicking, but if you don't do that then the underlying
blkfront/netfront does not get "correctly" detached either as you can see
from "port X still bound!" messages during minios_stop_kernel().

> >      Secondly, it is my intention with this work to provide a
> >      "docker-alike" interface for running rumprun applications. The "xr"
> >      script is therefore the CLI for running such applications.
> 
> The user-facing configuration tool was sorely needed.  I hate to go into 
> naming, but ... can we call the tool "rumprun"?  I think your tool will 
> be the basis for running rumprun stacks beyond Xen, and we should try to 
> avoid the user-visible syntax having any obvious shortcomings.

Guess so. In my mind there is potentially more the tool can do than just
run rumprun stacks, for example:

 - manage interaction with the host networking, map host ports to
   domain:port
 - generate or otherwise manage filesystem images (eg we could have a
   custom DNS server)
 - manage stack naming on the host, this is a bit daft at the moment, eg.
   if you try to run two copies of mathopd it will fall over due to the Xen
   domain name not being unique

And so on. Maybe this can be layered into separate tools with the 'rumprun'
script dealing only with launching. Needs more thought.

> > Note that in this initial version, only configuring IPv4 network
> > interfaces with DHCP is supported, and only using image files with ffs
> > or cd9660 filesystems for block devices is supported.
> 
> Would e.g. IPv6 support take longer than it took to write that paragraph ?-)

<taptaptap> ;)

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 15:51:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:51:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xowgd-0006Vy-6S; Thu, 13 Nov 2014 15:51:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ptesarik@suse.cz>) id 1Xowgc-0006Vt-AJ
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 15:51:54 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6C/6D-09842-993D4645; Thu, 13 Nov 2014 15:51:53 +0000
X-Env-Sender: ptesarik@suse.cz
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415893912!12516138!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21946 invoked from network); 13 Nov 2014 15:51:52 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 15:51:52 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3CFBCADA8;
	Thu, 13 Nov 2014 15:51:51 +0000 (UTC)
Date: Thu, 13 Nov 2014 16:51:48 +0100
From: Petr Tesarik <ptesarik@suse.cz>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20141113165148.4343b45e@hananiah.suse.cz>
In-Reply-To: <20120724135410.GA2230@host-192-168-1-59.local.net-space.pl>
References: <20120705121635.GA2007@host-192-168-1-59.local.net-space.pl>
	<201207231530.55871.ptesarik@suse.cz>
	<20120723201059.GA1848@host-192-168-1-59.local.net-space.pl>
	<201207241018.35292.ptesarik@suse.cz>
	<20120724135410.GA2230@host-192-168-1-59.local.net-space.pl>
Organization: SUSE Linux, s.r.o.
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-suse-linux-gnu)
MIME-Version: 1.0
Cc: olaf@aepfle.de, horms@verge.net.au, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] kexec-tools: Read always one vmcoreinfo file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

this thread got somehow forgotten because of vacations...
Anyway, read below.

On Tue, 24 Jul 2012 15:54:10 +0200
Daniel Kiper <daniel.kiper@oracle.com> wrote:

> On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > Dne Po 23. ??ervence 2012 22:10:59 Daniel Kiper napsal(a):
> > > Hi Petr,
> > >
> > > On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote:
> > > > Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a):
> > > > > Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a):
> > > > > > vmcoreinfo file could exists under /sys/kernel (valid on baremetal
> > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > /sys/hypervisor describes the Xen hypervisor (type 'XEN_VMCOREINFO').
> > > > > If you keep only the hypervisor note, then e.g. makedumpfile won't be
> > > > > able to use dumplevel greater than 1, nor will it be able to extract
> > > > > the log buffer.
> > > >
> > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > >
> > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > >
> > > [...]
> > >
> > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > If you discovered any issues with my patch please drop me more details
> > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > command lines, config files, logs, etc.). I will be more then happy to
> > > fix/improve kexec-tools and makedumpfile.
> >
> > Hi Daniel,
> >
> > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
> 
> Yep.
> 
> > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
> 
> Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> 
> > I tested with the following combinations:
> >
> > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> >
> > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > respectively. All of them work just fine and save both ELF notes into the
> > dump.
> 
> Could you test current kexec-tools development version and
> latest makedumpfile version on latest SLES version?

And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
kexec-tools 2.0.5, makedumpfile 1.5.6).

In the secondary kernel, makedumpfile complains that VMCOREINFO is not
stored in /proc/vmcore:

bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
Switched running mode from cyclic to non-cyclic,
because the cyclic mode doesn't support Xen.
/proc/vmcore doesn't contain vmcoreinfo.
Specify '-x' option or '-i' option.
Commandline parameter is invalid.
Try `makedumpfile --help' for more information.

makedumpfile Failed.

Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
everything works just fine.

> > What do you mean by "invalid physical address"? I'm getting the correct
> > physical address under Xen. Obviously, it must be translated to machine
> > addresses if you need them from the secondary kernel.
> 
> Correct vmcoreinfo address should be established by calling
> HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).

The addresses I get from /sys/kernel/vmcoreinfo and
from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
when a non-Xen kernel is used for dumping, everything works as expected.

I am well aware that the Xen implementation in SLES differs
substantially from mainline, but it seems to me that:

  1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
     filtering, and
  2. both sysfs files should report machine addresses, because the current
     p2m mapping is lost forever when the hypervisor executes the secondary
     kernel, so physical addresses are pretty useless.

I'm reverting the patch for the SLES distro, but I'd like to reach some
kind of consensus with the community, too.

Petr T

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 15:51:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:51:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xowgd-0006Vy-6S; Thu, 13 Nov 2014 15:51:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ptesarik@suse.cz>) id 1Xowgc-0006Vt-AJ
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 15:51:54 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6C/6D-09842-993D4645; Thu, 13 Nov 2014 15:51:53 +0000
X-Env-Sender: ptesarik@suse.cz
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415893912!12516138!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21946 invoked from network); 13 Nov 2014 15:51:52 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 15:51:52 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3CFBCADA8;
	Thu, 13 Nov 2014 15:51:51 +0000 (UTC)
Date: Thu, 13 Nov 2014 16:51:48 +0100
From: Petr Tesarik <ptesarik@suse.cz>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20141113165148.4343b45e@hananiah.suse.cz>
In-Reply-To: <20120724135410.GA2230@host-192-168-1-59.local.net-space.pl>
References: <20120705121635.GA2007@host-192-168-1-59.local.net-space.pl>
	<201207231530.55871.ptesarik@suse.cz>
	<20120723201059.GA1848@host-192-168-1-59.local.net-space.pl>
	<201207241018.35292.ptesarik@suse.cz>
	<20120724135410.GA2230@host-192-168-1-59.local.net-space.pl>
Organization: SUSE Linux, s.r.o.
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-suse-linux-gnu)
MIME-Version: 1.0
Cc: olaf@aepfle.de, horms@verge.net.au, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] kexec-tools: Read always one vmcoreinfo file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

this thread got somehow forgotten because of vacations...
Anyway, read below.

On Tue, 24 Jul 2012 15:54:10 +0200
Daniel Kiper <daniel.kiper@oracle.com> wrote:

> On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > Dne Po 23. ??ervence 2012 22:10:59 Daniel Kiper napsal(a):
> > > Hi Petr,
> > >
> > > On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote:
> > > > Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a):
> > > > > Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a):
> > > > > > vmcoreinfo file could exists under /sys/kernel (valid on baremetal
> > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > /sys/hypervisor describes the Xen hypervisor (type 'XEN_VMCOREINFO').
> > > > > If you keep only the hypervisor note, then e.g. makedumpfile won't be
> > > > > able to use dumplevel greater than 1, nor will it be able to extract
> > > > > the log buffer.
> > > >
> > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > >
> > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > >
> > > [...]
> > >
> > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > If you discovered any issues with my patch please drop me more details
> > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > command lines, config files, logs, etc.). I will be more then happy to
> > > fix/improve kexec-tools and makedumpfile.
> >
> > Hi Daniel,
> >
> > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
> 
> Yep.
> 
> > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
> 
> Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> 
> > I tested with the following combinations:
> >
> > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> >
> > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > respectively. All of them work just fine and save both ELF notes into the
> > dump.
> 
> Could you test current kexec-tools development version and
> latest makedumpfile version on latest SLES version?

And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
kexec-tools 2.0.5, makedumpfile 1.5.6).

In the secondary kernel, makedumpfile complains that VMCOREINFO is not
stored in /proc/vmcore:

bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
Switched running mode from cyclic to non-cyclic,
because the cyclic mode doesn't support Xen.
/proc/vmcore doesn't contain vmcoreinfo.
Specify '-x' option or '-i' option.
Commandline parameter is invalid.
Try `makedumpfile --help' for more information.

makedumpfile Failed.

Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
everything works just fine.

> > What do you mean by "invalid physical address"? I'm getting the correct
> > physical address under Xen. Obviously, it must be translated to machine
> > addresses if you need them from the secondary kernel.
> 
> Correct vmcoreinfo address should be established by calling
> HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).

The addresses I get from /sys/kernel/vmcoreinfo and
from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
when a non-Xen kernel is used for dumping, everything works as expected.

I am well aware that the Xen implementation in SLES differs
substantially from mainline, but it seems to me that:

  1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
     filtering, and
  2. both sysfs files should report machine addresses, because the current
     p2m mapping is lost forever when the hypervisor executes the secondary
     kernel, so physical addresses are pretty useless.

I'm reverting the patch for the SLES distro, but I'd like to reach some
kind of consensus with the community, too.

Petr T

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 15:52:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XowhR-0006fR-0A; Thu, 13 Nov 2014 15:52:45 +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 1XowhP-0006dr-5t
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 15:52:43 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	8D/F9-02559-AC3D4645; Thu, 13 Nov 2014 15:52:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415893961!12326836!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5442 invoked from network); 13 Nov 2014 15:52:41 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 15:52:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 15:52:41 +0000
Message-Id: <5464E1D9020000780004746B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 15:52:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Simon Martin" <furryfuttock@gmail.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
In-Reply-To: <196307380.20141113120732@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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 13.11.14 at 16:07, <furryfuttock@gmail.com> wrote:
> Thanks Jan,
> 
> Thursday, November 13, 2014, 11:08:33 AM, you wrote:
> 
>>>>> On 13.11.14 at 14:29, <furryfuttock@gmail.com> wrote:
>>> I am having 2 major problems at the moment.
>>> 
>>> 1.- Access to the PCI device from the PV will fail the second time I
>>> create it UNLESS I call xl pci-assignable-remove/pci-assignable-add
>>> between each creation. If I don't do this then all PCI accesses return
>>> -1. I get the same if I disable memory access in the PCI configuration
>>> register.
>>> 
>>> 1.1.- Is this expected behaviour?
> 
>> No. But did you verify the driver properly enables the device (i.e.
>> doesn't make assumptions on its state)? Also iirc some kernel
>> versions weren't properly resetting the device when coming back
>> from guest use, but without you stating the software versions
>> you're using that's just a remote possibility.
> 
> Yes,  the  first thing I do in the driver is set the PCI configuration
> access  bits to 7 that should enable IO space, Memory Space and Master
> BUS access.
> 
> As  a  test I disabled this and all reads to the PCI device return -1,
> even the first one.

I implied your earlier statement to mean that. But - did you also
verify that the three flags actually end up set (ideally from both
DomU and Dom0 perspective)? The PCI backend may be screwing
up things...

> I  agree,  this looks more than a hang than a crash. I've just found a
> link to the USB debug cable. I've ordered one but it will take a while

And I hope you first verified that your system meets the criteria
for this to work in the first place?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 15:52:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XowhR-0006fR-0A; Thu, 13 Nov 2014 15:52:45 +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 1XowhP-0006dr-5t
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 15:52:43 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	8D/F9-02559-AC3D4645; Thu, 13 Nov 2014 15:52:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415893961!12326836!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5442 invoked from network); 13 Nov 2014 15:52:41 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 15:52:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 15:52:41 +0000
Message-Id: <5464E1D9020000780004746B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 15:52:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Simon Martin" <furryfuttock@gmail.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
In-Reply-To: <196307380.20141113120732@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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 13.11.14 at 16:07, <furryfuttock@gmail.com> wrote:
> Thanks Jan,
> 
> Thursday, November 13, 2014, 11:08:33 AM, you wrote:
> 
>>>>> On 13.11.14 at 14:29, <furryfuttock@gmail.com> wrote:
>>> I am having 2 major problems at the moment.
>>> 
>>> 1.- Access to the PCI device from the PV will fail the second time I
>>> create it UNLESS I call xl pci-assignable-remove/pci-assignable-add
>>> between each creation. If I don't do this then all PCI accesses return
>>> -1. I get the same if I disable memory access in the PCI configuration
>>> register.
>>> 
>>> 1.1.- Is this expected behaviour?
> 
>> No. But did you verify the driver properly enables the device (i.e.
>> doesn't make assumptions on its state)? Also iirc some kernel
>> versions weren't properly resetting the device when coming back
>> from guest use, but without you stating the software versions
>> you're using that's just a remote possibility.
> 
> Yes,  the  first thing I do in the driver is set the PCI configuration
> access  bits to 7 that should enable IO space, Memory Space and Master
> BUS access.
> 
> As  a  test I disabled this and all reads to the PCI device return -1,
> even the first one.

I implied your earlier statement to mean that. But - did you also
verify that the three flags actually end up set (ideally from both
DomU and Dom0 perspective)? The PCI backend may be screwing
up things...

> I  agree,  this looks more than a hang than a crash. I've just found a
> link to the USB debug cable. I've ordered one but it will take a while

And I hope you first verified that your system meets the criteria
for this to work in the first place?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 15:57:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xowlx-0006uc-O2; Thu, 13 Nov 2014 15:57:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xowlw-0006uX-Ij
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 15:57:24 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	8C/76-18267-3E4D4645; Thu, 13 Nov 2014 15:57:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415894241!8750212!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25025 invoked from network); 13 Nov 2014 15:57:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 15:57:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="192460673"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 10:56:56 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XowlO-0003b1-PT;
	Thu, 13 Nov 2014 15:56:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XowlO-0006e7-4y;
	Thu, 13 Nov 2014 15:56:50 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 13 Nov 2014 15:56:48 +0000
Message-ID: <1415894208-25516-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <21604.39641.398785.791489@mariner.uk.xensource.com>
References: <21604.39641.398785.791489@mariner.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.campbell@eu.citrix.com, rumpkernel-builds@lists.sourceforge.net,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH] ts-rumpuserxen-demo-xenstorels: set
	`on_poweroff="preserve"'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 rely on the domain existing after xenstore-ls's main has called
exit, so that we can do our own xenstore-ls in dom0 and check the
results.

Previously, this happened by accident because the rump kernel would,
after _exit, call a minios function which crashes the domain.  New
rump kernels don't do this, and instead shut down cleanly.

Setting `on_poweroff="preserve"' has the desired effect.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-rumpuserxen-demo-xenstorels |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/ts-rumpuserxen-demo-xenstorels b/ts-rumpuserxen-demo-xenstorels
index 19f3f0d..6db7024 100755
--- a/ts-rumpuserxen-demo-xenstorels
+++ b/ts-rumpuserxen-demo-xenstorels
@@ -29,6 +29,16 @@ our $domid;
 
 our $gn = $gho->{Guest};
 
+sub arrangepreserve () {
+    target_editfile_root($ho,$r{"$gho->{Guest}_cfgpath"}, sub {
+	while (<EI>) {
+	    next if m/^\s*on_poweroff\s*=/;
+	    print EO or die $!;
+	}
+	print EO "\n","on_poweroff='preserve'\n" or die $!;
+    });
+}
+
 sub start () {
     my $cmd= toolstack()->{Command}." create ".
         $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} };
@@ -105,6 +115,7 @@ sub check_output () {
     }
 }
 
+arrangepreserve();
 start();
 await_end();
 check_output();
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 15:57:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 15:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xowlx-0006uc-O2; Thu, 13 Nov 2014 15:57:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xowlw-0006uX-Ij
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 15:57:24 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	8C/76-18267-3E4D4645; Thu, 13 Nov 2014 15:57:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415894241!8750212!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25025 invoked from network); 13 Nov 2014 15:57:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 15:57:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="192460673"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 10:56:56 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XowlO-0003b1-PT;
	Thu, 13 Nov 2014 15:56:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XowlO-0006e7-4y;
	Thu, 13 Nov 2014 15:56:50 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 13 Nov 2014 15:56:48 +0000
Message-ID: <1415894208-25516-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <21604.39641.398785.791489@mariner.uk.xensource.com>
References: <21604.39641.398785.791489@mariner.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.campbell@eu.citrix.com, rumpkernel-builds@lists.sourceforge.net,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH] ts-rumpuserxen-demo-xenstorels: set
	`on_poweroff="preserve"'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 rely on the domain existing after xenstore-ls's main has called
exit, so that we can do our own xenstore-ls in dom0 and check the
results.

Previously, this happened by accident because the rump kernel would,
after _exit, call a minios function which crashes the domain.  New
rump kernels don't do this, and instead shut down cleanly.

Setting `on_poweroff="preserve"' has the desired effect.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-rumpuserxen-demo-xenstorels |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/ts-rumpuserxen-demo-xenstorels b/ts-rumpuserxen-demo-xenstorels
index 19f3f0d..6db7024 100755
--- a/ts-rumpuserxen-demo-xenstorels
+++ b/ts-rumpuserxen-demo-xenstorels
@@ -29,6 +29,16 @@ our $domid;
 
 our $gn = $gho->{Guest};
 
+sub arrangepreserve () {
+    target_editfile_root($ho,$r{"$gho->{Guest}_cfgpath"}, sub {
+	while (<EI>) {
+	    next if m/^\s*on_poweroff\s*=/;
+	    print EO or die $!;
+	}
+	print EO "\n","on_poweroff='preserve'\n" or die $!;
+    });
+}
+
 sub start () {
     my $cmd= toolstack()->{Command}." create ".
         $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} };
@@ -105,6 +115,7 @@ sub check_output () {
     }
 }
 
+arrangepreserve();
 start();
 await_end();
 check_output();
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:05:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:05:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xowt3-0007dt-N2; Thu, 13 Nov 2014 16:04:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tdeegan@xensource.com>) id 1Xowt2-0007dm-Hm
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:04:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B3/62-09936-B96D4645; Thu, 13 Nov 2014 16:04:43 +0000
X-Env-Sender: tdeegan@xensource.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415894681!4510072!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9899 invoked from network); 13 Nov 2014 16:04:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:04:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="192465000"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 11:04:16 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tdeegan@xensource.com>)	id 1XowrY-0003k1-ML;
	Thu, 13 Nov 2014 16:03:12 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim
	4.82_1-5b7a7c0-XX)	(envelope-from <tdeegan@whitby.uk.xensource.com>)	id
	1XowrX-0004l3-PY; Thu, 13 Nov 2014 16:03:11 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 13 Nov 2014 16:03:09 +0000
Message-ID: <1415894589-18256-1-git-send-email-tim@xen.org>
X-Mailer: git-send-email 2.0.1
MIME-Version: 1.0
X-DLP: MIA1
Cc: boris.ostrovsky@oracle.com, keir@xen.org, ian.campbell@citrix.com,
	JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2] xen: remove Xencomm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Being a feature that has only been used by ia64 and/or ppc it
doesn't seem like we need to keep it any longer in the tree.

So remove it.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Tim Deegan <tim@xen.org>
---
This was suggested by Boris a while ago and seems to have stalled.

v2: leave public header in place (suggested by Jan Beulich).
---
 xen/common/Makefile       |   2 -
 xen/common/xencomm.c      | 621 ----------------------------------------------
 xen/include/Makefile      |   1 -
 xen/include/xen/xencomm.h | 170 -------------
 4 files changed, 794 deletions(-)
 delete mode 100644 xen/common/xencomm.c
 delete mode 100644 xen/include/xen/xencomm.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 8391246..1956091 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -62,8 +62,6 @@ obj-$(perfc)       += perfc.o
 obj-$(crash_debug) += gdbstub.o
 obj-$(xenoprof)    += xenoprof.o
 
-obj-$(CONFIG_XENCOMM) += xencomm.o
-
 subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
diff --git a/xen/common/xencomm.c b/xen/common/xencomm.c
deleted file mode 100644
index 2604ac0..0000000
--- a/xen/common/xencomm.c
+++ /dev/null
@@ -1,621 +0,0 @@
-/******************************************************************************
- * xencomm.c
- *
- * 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, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
- *
- * Copyright (C) IBM Corp. 2006
- *
- * Authors: Hollis Blanchard <hollisb@us.ibm.com>
- *          Tristan Gingold <tristan.gingold@bull.net>
- *          Isaku Yamahata <yamahata@valinux.co.jp> multiple page support
- */
-
-#include <xen/config.h>
-#include <xen/mm.h>
-#include <xen/sched.h>
-#include <xen/xencomm.h>
-#include <public/xen.h>
-#include <public/xencomm.h>
-
-#undef DEBUG
-#ifdef DEBUG
-#define xc_dprintk(f, a...) printk("[xencomm]" f , ## a)
-#else
-#define xc_dprintk(f, a...) ((void)0)
-#endif
-
-static void *
-xencomm_vaddr(unsigned long paddr, struct page_info *page)
-{
-    return (void*)((paddr & ~PAGE_MASK) | (unsigned long)page_to_virt(page));
-}
-
-/* get_page() to prevent another vcpu freeing the page. */
-static int
-xencomm_get_page(unsigned long paddr, struct page_info **page)
-{
-    unsigned long maddr = paddr_to_maddr(paddr);
-    if ( maddr == 0 )
-        return -EFAULT;
-        
-    *page = maddr_to_page(maddr);
-    if ( !get_page(*page, current->domain) )
-    {
-        /*
-         * This page might be a page granted by another domain, or this page 
-         * is freed with decrease reservation hypercall at the same time.
-         */
-        gdprintk(XENLOG_WARNING,
-                 "bad page is passed. paddr %#lx maddr %#lx\n",
-                 paddr, maddr);
-        return -EFAULT;
-    }
-
-    return 0;
-}
-
-/* check if struct desc doesn't cross page boundry */
-static int
-xencomm_desc_cross_page_boundary(unsigned long paddr)
-{
-    unsigned long offset = paddr & ~PAGE_MASK;
-    if ( offset > PAGE_SIZE - sizeof(struct xencomm_desc) )
-        return 1;
-    return 0;
-}
-
-struct xencomm_ctxt {
-    struct xencomm_desc __user *desc_in_paddr;
-    uint32_t nr_addrs;
-
-    struct page_info *page;
-    unsigned long *address;
-};
-
-static uint32_t
-xencomm_ctxt_nr_addrs(const struct xencomm_ctxt *ctxt)
-{
-    return ctxt->nr_addrs;
-}
-
-static unsigned long*
-xencomm_ctxt_address(struct xencomm_ctxt *ctxt)
-{
-    return ctxt->address;
-}
-
-static int
-xencomm_ctxt_init(const void *handle, struct xencomm_ctxt *ctxt)
-{
-    struct page_info *page;
-    struct xencomm_desc *desc;
-    int ret;
-
-    /* Avoid unaligned access. */
-    if ( ((unsigned long)handle % __alignof__(*desc)) != 0 )
-        return -EINVAL;
-    if ( xencomm_desc_cross_page_boundary((unsigned long)handle) )
-        return -EINVAL;
-
-    /* First we need to access the descriptor. */
-    ret = xencomm_get_page((unsigned long)handle, &page);
-    if ( ret )
-        return ret;
-
-    desc = xencomm_vaddr((unsigned long)handle, page);
-    if ( desc->magic != XENCOMM_MAGIC )
-    {
-        printk("%s: error: %p magic was %#x\n", __func__, desc, desc->magic);
-        put_page(page);
-        return -EINVAL;
-    }
-
-    /* Copy before use: It is possible for a guest to modify concurrently. */
-    ctxt->nr_addrs = desc->nr_addrs;
-    ctxt->desc_in_paddr = (struct xencomm_desc*)handle;
-    ctxt->page = page;
-    ctxt->address = &desc->address[0];
-    return 0;
-}
-
-/*
- * Calculate the vaddr of &ctxt->desc_in_paddr->address[i] and get_page().
- * And put the results in ctxt->page and ctxt->address.
- * If there is the previous page, put_page().
- *
- * A guest domain passes the array, ctxt->desc_in_paddr->address[].
- * It is gpaddr-contiguous, but not maddr-contiguous so that
- * we can't obtain the vaddr by simple offsetting.
- * We need to convert gpaddr, &ctxt->desc_in_paddr->address[i],
- * into maddr and then convert it to the xen virtual address in order
- * to access there.
- * The conversion can be optimized out by using the last result of
- * ctxt->address because we access the array sequentially.
- * The conversion, gpaddr -> maddr -> vaddr, is necessary only when
- * crossing page boundary.
- */
-static int
-xencomm_ctxt_next(struct xencomm_ctxt *ctxt, int i)
-{
-    unsigned long paddr;
-    struct page_info *page;
-    int ret;
-
-    BUG_ON(i >= ctxt->nr_addrs);
-
-    /* For i == 0 case we already calculated it in xencomm_ctxt_init(). */
-    if ( i != 0 )
-        ctxt->address++;
-
-    if ( ((unsigned long)ctxt->address & ~PAGE_MASK) != 0 )
-        return 0;
-
-    /* Crossing page boundary: machine address must be calculated. */
-    paddr = (unsigned long)&ctxt->desc_in_paddr->address[i];
-    ret = xencomm_get_page(paddr, &page);
-    if ( ret )
-        return ret;
-
-    put_page(ctxt->page);
-    ctxt->page = page;
-    ctxt->address = xencomm_vaddr(paddr, page);
-
-    return 0;
-}
-
-static void
-xencomm_ctxt_done(struct xencomm_ctxt *ctxt)
-{
-    put_page(ctxt->page);
-}
-
-static int
-xencomm_copy_chunk_from(
-    unsigned long to, unsigned long paddr, unsigned int  len)
-{
-    struct page_info *page;
-    int res;
-
-    do {
-        res = xencomm_get_page(paddr, &page);
-    } while ( res == -EAGAIN );
-
-    if ( res )
-        return res;
-
-    xc_dprintk("%lx[%d] -> %lx\n",
-               (unsigned long)xencomm_vaddr(paddr, page), len, to);
-
-    memcpy((void *)to, xencomm_vaddr(paddr, page), len);
-    put_page(page);
-
-    return 0;
-}
-
-static unsigned long
-xencomm_inline_from_guest(
-    void *to, const void *from, unsigned int n, unsigned int skip)
-{
-    unsigned long src_paddr = xencomm_inline_addr(from) + skip;
-
-    while ( n > 0 )
-    {
-        unsigned int chunksz, bytes;
-
-        chunksz = PAGE_SIZE - (src_paddr % PAGE_SIZE);
-        bytes   = min(chunksz, n);
-
-        if ( xencomm_copy_chunk_from((unsigned long)to, src_paddr, bytes) )
-            return n;
-        src_paddr += bytes;
-        to += bytes;
-        n -= bytes;
-    }
-
-    /* Always successful. */
-    return 0;
-}
-
-/**
- * xencomm_copy_from_guest: Copy a block of data from domain space.
- * @to:   Machine address.
- * @from: Physical address to a xencomm buffer descriptor.
- * @n:    Number of bytes to copy.
- * @skip: Number of bytes from the start to skip.
- *
- * Copy data from domain to hypervisor.
- *
- * Returns number of bytes that could not be copied.
- * On success, this will be zero.
- */
-unsigned long
-xencomm_copy_from_guest(
-    void *to, const void *from, unsigned int n, unsigned int skip)
-{
-    struct xencomm_ctxt ctxt;
-    unsigned int from_pos = 0;
-    unsigned int to_pos = 0;
-    unsigned int i = 0;
-
-    if ( xencomm_is_inline(from) )
-        return xencomm_inline_from_guest(to, from, n, skip);
-
-    if ( xencomm_ctxt_init(from, &ctxt) )
-        return n;
-
-    /* Iterate through the descriptor, copying up to a page at a time */
-    while ( (to_pos < n) && (i < xencomm_ctxt_nr_addrs(&ctxt)) )
-    {
-        unsigned long src_paddr;
-        unsigned int pgoffset, chunksz, chunk_skip;
-
-        if ( xencomm_ctxt_next(&ctxt, i) )
-            goto out;
-        src_paddr = *xencomm_ctxt_address(&ctxt);
-        if ( src_paddr == XENCOMM_INVALID )
-        {
-            i++;
-            continue;
-        }
-
-        pgoffset = src_paddr % PAGE_SIZE;
-        chunksz = PAGE_SIZE - pgoffset;
-
-        chunk_skip = min(chunksz, skip);
-        from_pos += chunk_skip;
-        chunksz -= chunk_skip;
-        skip -= chunk_skip;
-
-        if ( skip == 0 && chunksz > 0 )
-        {
-            unsigned int bytes = min(chunksz, n - to_pos);
-
-            if ( xencomm_copy_chunk_from((unsigned long)to + to_pos,
-                                         src_paddr + chunk_skip, bytes) )
-                goto out;
-            from_pos += bytes;
-            to_pos += bytes;
-        }
-
-        i++;
-    }
-
-out:
-    xencomm_ctxt_done(&ctxt);
-    return n - to_pos;
-}
-
-static int
-xencomm_copy_chunk_to(
-    unsigned long paddr, unsigned long from, unsigned int  len)
-{
-    struct page_info *page;
-    int res;
-
-    do {
-        res = xencomm_get_page(paddr, &page);
-    } while ( res == -EAGAIN );
-
-    if ( res )
-        return res;
-
-    xc_dprintk("%lx[%d] -> %lx\n", from, len,
-               (unsigned long)xencomm_vaddr(paddr, page));
-
-    memcpy(xencomm_vaddr(paddr, page), (void *)from, len);
-    xencomm_mark_dirty((unsigned long)xencomm_vaddr(paddr, page), len);
-    put_page(page);
-
-    return 0;
-}
-
-static unsigned long
-xencomm_inline_to_guest(
-    void *to, const void *from, unsigned int n, unsigned int skip)
-{
-    unsigned long dest_paddr = xencomm_inline_addr(to) + skip;
-
-    while ( n > 0 )
-    {
-        unsigned int chunksz, bytes;
-
-        chunksz = PAGE_SIZE - (dest_paddr % PAGE_SIZE);
-        bytes   = min(chunksz, n);
-
-        if ( xencomm_copy_chunk_to(dest_paddr, (unsigned long)from, bytes) )
-            return n;
-        dest_paddr += bytes;
-        from += bytes;
-        n -= bytes;
-    }
-
-    /* Always successful. */
-    return 0;
-}
-
-/**
- * xencomm_copy_to_guest: Copy a block of data to domain space.
- * @to:     Physical address to xencomm buffer descriptor.
- * @from:   Machine address.
- * @n:      Number of bytes to copy.
- * @skip: Number of bytes from the start to skip.
- *
- * Copy data from hypervisor to domain.
- *
- * Returns number of bytes that could not be copied.
- * On success, this will be zero.
- */
-unsigned long
-xencomm_copy_to_guest(
-    void *to, const void *from, unsigned int n, unsigned int skip)
-{
-    struct xencomm_ctxt ctxt;
-    unsigned int from_pos = 0;
-    unsigned int to_pos = 0;
-    unsigned int i = 0;
-
-    if ( xencomm_is_inline(to) )
-        return xencomm_inline_to_guest(to, from, n, skip);
-
-    if ( xencomm_ctxt_init(to, &ctxt) )
-        return n;
-
-    /* Iterate through the descriptor, copying up to a page at a time */
-    while ( (from_pos < n) && (i < xencomm_ctxt_nr_addrs(&ctxt)) )
-    {
-        unsigned long dest_paddr;
-        unsigned int pgoffset, chunksz, chunk_skip;
-
-        if ( xencomm_ctxt_next(&ctxt, i) )
-            goto out;
-        dest_paddr = *xencomm_ctxt_address(&ctxt);
-        if ( dest_paddr == XENCOMM_INVALID )
-        {
-            i++;
-            continue;
-        }
-
-        pgoffset = dest_paddr % PAGE_SIZE;
-        chunksz = PAGE_SIZE - pgoffset;
-
-        chunk_skip = min(chunksz, skip);
-        to_pos += chunk_skip;
-        chunksz -= chunk_skip;
-        skip -= chunk_skip;
-
-        if ( skip == 0 && chunksz > 0 )
-        {
-            unsigned int bytes = min(chunksz, n - from_pos);
-
-            if ( xencomm_copy_chunk_to(dest_paddr + chunk_skip,
-                                      (unsigned long)from + from_pos, bytes) )
-                goto out;
-            from_pos += bytes;
-            to_pos += bytes;
-        }
-
-        i++;
-    }
-
-out:
-    xencomm_ctxt_done(&ctxt);
-    return n - from_pos;
-}
-
-static int
-xencomm_clear_chunk(
-    unsigned long paddr, unsigned int  len)
-{
-    struct page_info *page;
-    int res;
-
-    do {
-        res = xencomm_get_page(paddr, &page);
-    } while ( res == -EAGAIN );
-
-    if ( res )
-        return res;
-
-    memset(xencomm_vaddr(paddr, page), 0x00, len);
-    xencomm_mark_dirty((unsigned long)xencomm_vaddr(paddr, page), len);
-    put_page(page);
-
-    return 0;
-}
-
-static unsigned long
-xencomm_inline_clear_guest(
-    void *to, unsigned int n, unsigned int skip)
-{
-    unsigned long dest_paddr = xencomm_inline_addr(to) + skip;
-
-    while ( n > 0 )
-    {
-        unsigned int chunksz, bytes;
-
-        chunksz = PAGE_SIZE - (dest_paddr % PAGE_SIZE);
-        bytes   = min(chunksz, n);
-
-        if ( xencomm_clear_chunk(dest_paddr, bytes) )
-            return n;
-        dest_paddr += bytes;
-        n -= bytes;
-    }
-
-    /* Always successful. */
-    return 0;
-}
-
-/**
- * xencomm_clear_guest: Clear a block of data in domain space.
- * @to:     Physical address to xencomm buffer descriptor.
- * @n:      Number of bytes to copy.
- * @skip: Number of bytes from the start to skip.
- *
- * Clear domain data
- *
- * Returns number of bytes that could not be cleared
- * On success, this will be zero.
- */
-unsigned long
-xencomm_clear_guest(
-    void *to, unsigned int n, unsigned int skip)
-{
-    struct xencomm_ctxt ctxt;
-    unsigned int from_pos = 0;
-    unsigned int to_pos = 0;
-    unsigned int i = 0;
-
-    if ( xencomm_is_inline(to) )
-        return xencomm_inline_clear_guest(to, n, skip);
-
-    if ( xencomm_ctxt_init(to, &ctxt) )
-        return n;
-
-    /* Iterate through the descriptor, copying up to a page at a time */
-    while ( (from_pos < n) && (i < xencomm_ctxt_nr_addrs(&ctxt)) )
-    {
-        unsigned long dest_paddr;
-        unsigned int pgoffset, chunksz, chunk_skip;
-
-        if ( xencomm_ctxt_next(&ctxt, i) )
-            goto out;
-        dest_paddr = *xencomm_ctxt_address(&ctxt);
-        if ( dest_paddr == XENCOMM_INVALID )
-        {
-            i++;
-            continue;
-        }
-
-        pgoffset = dest_paddr % PAGE_SIZE;
-        chunksz = PAGE_SIZE - pgoffset;
-
-        chunk_skip = min(chunksz, skip);
-        to_pos += chunk_skip;
-        chunksz -= chunk_skip;
-        skip -= chunk_skip;
-
-        if ( skip == 0 && chunksz > 0 )
-        {
-            unsigned int bytes = min(chunksz, n - from_pos);
-
-            if ( xencomm_clear_chunk(dest_paddr + chunk_skip, bytes) )
-                goto out;
-            from_pos += bytes;
-            to_pos += bytes;
-        }
-
-        i++;
-    }
-
-out:
-    xencomm_ctxt_done(&ctxt);
-    return n - from_pos;
-}
-
-static int xencomm_inline_add_offset(void **handle, unsigned int bytes)
-{
-    *handle += bytes;
-    return 0;
-}
-
-/* Offset page addresses in 'handle' to skip 'bytes' bytes. Set completely
- * exhausted pages to XENCOMM_INVALID. */
-int xencomm_add_offset(void **handle, unsigned int bytes)
-{
-    struct xencomm_ctxt ctxt;
-    int i = 0;
-    int res = 0;
-
-    if ( xencomm_is_inline(*handle) )
-        return xencomm_inline_add_offset(handle, bytes);
-
-    res = xencomm_ctxt_init(handle, &ctxt);
-    if ( res != 0 )
-        return res;
-
-    /* Iterate through the descriptor incrementing addresses */
-    while ( (bytes > 0) && (i < xencomm_ctxt_nr_addrs(&ctxt)) )
-    {
-        unsigned long *address;
-        unsigned long dest_paddr;
-        unsigned int pgoffset, chunksz, chunk_skip;
-
-        res = xencomm_ctxt_next(&ctxt, i);
-        if ( res )
-            goto out;
-        address = xencomm_ctxt_address(&ctxt);
-        dest_paddr = *address;
-        if ( dest_paddr == XENCOMM_INVALID )
-        {
-            i++;
-            continue;
-        }
-
-        pgoffset = dest_paddr % PAGE_SIZE;
-        chunksz = PAGE_SIZE - pgoffset;
-
-        chunk_skip = min(chunksz, bytes);
-        if ( chunk_skip == chunksz )
-            *address = XENCOMM_INVALID; /* exhausted this page */
-        else
-            *address += chunk_skip;
-        bytes -= chunk_skip;
-
-        i++;
-    }
-
-out:
-    xencomm_ctxt_done(&ctxt);
-    return res;
-}
-
-int xencomm_handle_is_null(void *handle)
-{
-    struct xencomm_ctxt ctxt;
-    int i;
-    int res = 1;
-
-    if ( xencomm_is_inline(handle) )
-        return xencomm_inline_addr(handle) == 0;
-
-    if ( xencomm_ctxt_init(handle, &ctxt) )
-        return 1;
-
-    for ( i = 0; i < xencomm_ctxt_nr_addrs(&ctxt); i++ )
-    {
-        if ( xencomm_ctxt_next(&ctxt, i) )
-            goto out;
-        if ( *xencomm_ctxt_address(&ctxt) != XENCOMM_INVALID )
-        {
-            res = 0;
-            goto out;
-        }
-    }
-
-out:
-    xencomm_ctxt_done(&ctxt);
-    return res;
-}
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/Makefile b/xen/include/Makefile
index f7ccbc9..94112d1 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -21,7 +21,6 @@ headers-y := \
     compat/vcpu.h \
     compat/version.h \
     compat/xen.h \
-    compat/xencomm.h \
     compat/xenoprof.h
 headers-$(CONFIG_X86)     += compat/arch-x86/xen-mca.h
 headers-$(CONFIG_X86)     += compat/arch-x86/xen.h
diff --git a/xen/include/xen/xencomm.h b/xen/include/xen/xencomm.h
deleted file mode 100644
index 3426b8a..0000000
--- a/xen/include/xen/xencomm.h
+++ /dev/null
@@ -1,170 +0,0 @@
-/*
- * 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, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
- *
- * Copyright (C) IBM Corp. 2006
- *
- * Authors: Hollis Blanchard <hollisb@us.ibm.com>
- */
-
-#ifndef __XENCOMM_H__
-#define __XENCOMM_H__
-
-#include <public/xen.h>
-
-unsigned long xencomm_copy_to_guest(
-    void *to, const void *from, unsigned int len, unsigned int skip); 
-unsigned long xencomm_copy_from_guest(
-    void *to, const void *from, unsigned int len, unsigned int skip); 
-unsigned long xencomm_clear_guest(
-    void *to, unsigned int n, unsigned int skip);
-int xencomm_add_offset(void **handle, unsigned int bytes);
-int xencomm_handle_is_null(void *ptr);
-
-static inline int xencomm_is_inline(const void *handle)
-{
-    unsigned long addr = (unsigned long)handle;
-    return (addr & XENCOMM_INLINE_FLAG) == XENCOMM_INLINE_FLAG;
-}
-
-static inline unsigned long xencomm_inline_addr(const void *handle)
-{
-    return (unsigned long)handle & ~XENCOMM_INLINE_FLAG;
-}
-
-#define raw_copy_to_guest(dst, src, len)       \
-    xencomm_copy_to_guest(dst, src, len, 0)
-#define raw_copy_from_guest(dst, src, len)     \
-    xencomm_copy_from_guest(dst, src, nr, 0)
-#define raw_clear_guest(dst, len)              \
-    xencomm_clear_guest(dst, len, 0)
-#define __raw_copy_to_guest raw_copy_to_guest
-#define __raw_copy_from_guest raw_copy_from_guest
-#define __raw_clear_guest raw_clear_guest
-
-/* Is the guest handle a NULL reference? */
-#define guest_handle_is_null(hnd) \
-    ((hnd).p == NULL || xencomm_handle_is_null((hnd).p))
-
-/* Offset the given guest handle into the array it refers to. */
-#define guest_handle_add_offset(hnd, nr) ({                             \
-    const typeof((hnd).p) _ptr;                                         \
-    xencomm_add_offset((void **)&((hnd).p), nr * sizeof(*_ptr));        \
-})
-
-/* Cast a guest handle to the specified type of handle. */
-#define guest_handle_cast(hnd, type) ({         \
-    type *_x = (hnd).p;                         \
-    XEN_GUEST_HANDLE_PARAM(type) _y;            \
-    set_xen_guest_handle(_y, _x);               \
-    _y;                                         \
-})
-
-/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
-#define guest_handle_to_param(hnd, type) ({                  \
-    /* type checking: make sure that the pointers inside     \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
-     * the same type, then return hnd */                     \
-    (void)((typeof(&(hnd).p)) 0 ==                           \
-        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
-    (hnd);                                                   \
-})
-
-/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
-#define guest_handle_from_param(hnd, type) ({                \
-    /* type checking: make sure that the pointers inside     \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
-     * the same type, then return hnd */                     \
-    (void)((typeof(&(hnd).p)) 0 ==                           \
-        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
-    (hnd);                                                   \
-})
-
-/* Since we run in real mode, we can safely access all addresses. That also
- * means our __routines are identical to our "normal" routines. */
-#define guest_handle_okay(hnd, nr) 1
-#define guest_handle_subrange_okay(hnd, first, last) 1
-
-/*
- * Copy an array of objects to guest context via a guest handle.
- * Optionally specify an offset into the guest array.
- */
-#define copy_to_guest_offset(hnd, idx, ptr, nr) \
-    __copy_to_guest_offset(hnd, idx, ptr, nr)
-
-/* Copy sub-field of a structure to guest context via a guest handle. */
-#define copy_field_to_guest(hnd, ptr, field) \
-    __copy_field_to_guest(hnd, ptr, field)
-
-/*
- * Copy an array of objects from guest context via a guest handle.
- * Optionally specify an offset into the guest array.
- */
-#define copy_from_guest_offset(ptr, hnd, idx, nr) \
-    __copy_from_guest_offset(ptr, hnd, idx, nr)
-
-/*
- * Clear an array of objects in guest context via a guest handle.
- * Optionally specify an offset into the guest array.
- */
-#define clear_guest_offset(hnd, idx, nr) \
-    __clear_guest_offset(hnd, idx, nr)
-
-/* Copy sub-field of a structure from guest context via a guest handle. */
-#define copy_field_from_guest(ptr, hnd, field) \
-    __copy_field_from_guest(ptr, hnd, field)
-
-#define __copy_to_guest_offset(hnd, idx, ptr, nr) ({                \
-    const typeof(*(ptr)) *_s = (ptr);                               \
-    void *_d = (hnd).p;                                             \
-    ((void)((hnd).p == (ptr)));                                     \
-    xencomm_copy_to_guest(_d, _s, sizeof(*_s)*(nr), sizeof(*_s)*(idx)); \
-})
-
-#define __copy_field_to_guest(hnd, ptr, field) ({                   \
-    unsigned int _off = offsetof(typeof(*(hnd).p), field);          \
-    const typeof(&(ptr)->field) _s = &(ptr)->field;                 \
-    void *_d = (hnd).p;                                             \
-    ((void)(&(hnd).p->field == &(ptr)->field));                     \
-    xencomm_copy_to_guest(_d, _s, sizeof(*_s), _off);               \
-})
-
-#define __copy_from_guest_offset(ptr, hnd, idx, nr) ({              \
-    const typeof(*(ptr)) *_s = (hnd).p;                             \
-    typeof(*(ptr)) *_d = (ptr);                                     \
-    xencomm_copy_from_guest(_d, _s, sizeof(*_d)*(nr), sizeof(*_d)*(idx)); \
-})
-
-#define __copy_field_from_guest(ptr, hnd, field) ({                 \
-    unsigned int _off = offsetof(typeof(*(hnd).p), field);          \
-    const void *_s = (hnd).p;                                       \
-    typeof(&(ptr)->field) _d = &(ptr)->field;                       \
-    ((void)(&(hnd).p->field == &(ptr)->field));                     \
-    xencomm_copy_from_guest(_d, _s, sizeof(*_d), _off);             \
-})
-
-#define __clear_guest_offset(hnd, idx, nr) ({                \
-    void *_d = (hnd).p;                                             \
-    xencomm_clear_guest(_d, nr, idx); \
-})
-
-#ifdef CONFIG_XENCOMM_MARK_DIRTY
-extern void xencomm_mark_dirty(unsigned long addr, unsigned int len);
-#else
-static inline void xencomm_mark_dirty(unsigned long addr, unsigned int len)
-{
-}
-#endif
-
-#endif /* __XENCOMM_H__ */
-- 
2.0.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:05:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:05:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xowt3-0007dt-N2; Thu, 13 Nov 2014 16:04:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tdeegan@xensource.com>) id 1Xowt2-0007dm-Hm
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:04:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B3/62-09936-B96D4645; Thu, 13 Nov 2014 16:04:43 +0000
X-Env-Sender: tdeegan@xensource.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415894681!4510072!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9899 invoked from network); 13 Nov 2014 16:04:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:04:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="192465000"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 11:04:16 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tdeegan@xensource.com>)	id 1XowrY-0003k1-ML;
	Thu, 13 Nov 2014 16:03:12 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim
	4.82_1-5b7a7c0-XX)	(envelope-from <tdeegan@whitby.uk.xensource.com>)	id
	1XowrX-0004l3-PY; Thu, 13 Nov 2014 16:03:11 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 13 Nov 2014 16:03:09 +0000
Message-ID: <1415894589-18256-1-git-send-email-tim@xen.org>
X-Mailer: git-send-email 2.0.1
MIME-Version: 1.0
X-DLP: MIA1
Cc: boris.ostrovsky@oracle.com, keir@xen.org, ian.campbell@citrix.com,
	JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2] xen: remove Xencomm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Being a feature that has only been used by ia64 and/or ppc it
doesn't seem like we need to keep it any longer in the tree.

So remove it.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Tim Deegan <tim@xen.org>
---
This was suggested by Boris a while ago and seems to have stalled.

v2: leave public header in place (suggested by Jan Beulich).
---
 xen/common/Makefile       |   2 -
 xen/common/xencomm.c      | 621 ----------------------------------------------
 xen/include/Makefile      |   1 -
 xen/include/xen/xencomm.h | 170 -------------
 4 files changed, 794 deletions(-)
 delete mode 100644 xen/common/xencomm.c
 delete mode 100644 xen/include/xen/xencomm.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 8391246..1956091 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -62,8 +62,6 @@ obj-$(perfc)       += perfc.o
 obj-$(crash_debug) += gdbstub.o
 obj-$(xenoprof)    += xenoprof.o
 
-obj-$(CONFIG_XENCOMM) += xencomm.o
-
 subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
diff --git a/xen/common/xencomm.c b/xen/common/xencomm.c
deleted file mode 100644
index 2604ac0..0000000
--- a/xen/common/xencomm.c
+++ /dev/null
@@ -1,621 +0,0 @@
-/******************************************************************************
- * xencomm.c
- *
- * 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, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
- *
- * Copyright (C) IBM Corp. 2006
- *
- * Authors: Hollis Blanchard <hollisb@us.ibm.com>
- *          Tristan Gingold <tristan.gingold@bull.net>
- *          Isaku Yamahata <yamahata@valinux.co.jp> multiple page support
- */
-
-#include <xen/config.h>
-#include <xen/mm.h>
-#include <xen/sched.h>
-#include <xen/xencomm.h>
-#include <public/xen.h>
-#include <public/xencomm.h>
-
-#undef DEBUG
-#ifdef DEBUG
-#define xc_dprintk(f, a...) printk("[xencomm]" f , ## a)
-#else
-#define xc_dprintk(f, a...) ((void)0)
-#endif
-
-static void *
-xencomm_vaddr(unsigned long paddr, struct page_info *page)
-{
-    return (void*)((paddr & ~PAGE_MASK) | (unsigned long)page_to_virt(page));
-}
-
-/* get_page() to prevent another vcpu freeing the page. */
-static int
-xencomm_get_page(unsigned long paddr, struct page_info **page)
-{
-    unsigned long maddr = paddr_to_maddr(paddr);
-    if ( maddr == 0 )
-        return -EFAULT;
-        
-    *page = maddr_to_page(maddr);
-    if ( !get_page(*page, current->domain) )
-    {
-        /*
-         * This page might be a page granted by another domain, or this page 
-         * is freed with decrease reservation hypercall at the same time.
-         */
-        gdprintk(XENLOG_WARNING,
-                 "bad page is passed. paddr %#lx maddr %#lx\n",
-                 paddr, maddr);
-        return -EFAULT;
-    }
-
-    return 0;
-}
-
-/* check if struct desc doesn't cross page boundry */
-static int
-xencomm_desc_cross_page_boundary(unsigned long paddr)
-{
-    unsigned long offset = paddr & ~PAGE_MASK;
-    if ( offset > PAGE_SIZE - sizeof(struct xencomm_desc) )
-        return 1;
-    return 0;
-}
-
-struct xencomm_ctxt {
-    struct xencomm_desc __user *desc_in_paddr;
-    uint32_t nr_addrs;
-
-    struct page_info *page;
-    unsigned long *address;
-};
-
-static uint32_t
-xencomm_ctxt_nr_addrs(const struct xencomm_ctxt *ctxt)
-{
-    return ctxt->nr_addrs;
-}
-
-static unsigned long*
-xencomm_ctxt_address(struct xencomm_ctxt *ctxt)
-{
-    return ctxt->address;
-}
-
-static int
-xencomm_ctxt_init(const void *handle, struct xencomm_ctxt *ctxt)
-{
-    struct page_info *page;
-    struct xencomm_desc *desc;
-    int ret;
-
-    /* Avoid unaligned access. */
-    if ( ((unsigned long)handle % __alignof__(*desc)) != 0 )
-        return -EINVAL;
-    if ( xencomm_desc_cross_page_boundary((unsigned long)handle) )
-        return -EINVAL;
-
-    /* First we need to access the descriptor. */
-    ret = xencomm_get_page((unsigned long)handle, &page);
-    if ( ret )
-        return ret;
-
-    desc = xencomm_vaddr((unsigned long)handle, page);
-    if ( desc->magic != XENCOMM_MAGIC )
-    {
-        printk("%s: error: %p magic was %#x\n", __func__, desc, desc->magic);
-        put_page(page);
-        return -EINVAL;
-    }
-
-    /* Copy before use: It is possible for a guest to modify concurrently. */
-    ctxt->nr_addrs = desc->nr_addrs;
-    ctxt->desc_in_paddr = (struct xencomm_desc*)handle;
-    ctxt->page = page;
-    ctxt->address = &desc->address[0];
-    return 0;
-}
-
-/*
- * Calculate the vaddr of &ctxt->desc_in_paddr->address[i] and get_page().
- * And put the results in ctxt->page and ctxt->address.
- * If there is the previous page, put_page().
- *
- * A guest domain passes the array, ctxt->desc_in_paddr->address[].
- * It is gpaddr-contiguous, but not maddr-contiguous so that
- * we can't obtain the vaddr by simple offsetting.
- * We need to convert gpaddr, &ctxt->desc_in_paddr->address[i],
- * into maddr and then convert it to the xen virtual address in order
- * to access there.
- * The conversion can be optimized out by using the last result of
- * ctxt->address because we access the array sequentially.
- * The conversion, gpaddr -> maddr -> vaddr, is necessary only when
- * crossing page boundary.
- */
-static int
-xencomm_ctxt_next(struct xencomm_ctxt *ctxt, int i)
-{
-    unsigned long paddr;
-    struct page_info *page;
-    int ret;
-
-    BUG_ON(i >= ctxt->nr_addrs);
-
-    /* For i == 0 case we already calculated it in xencomm_ctxt_init(). */
-    if ( i != 0 )
-        ctxt->address++;
-
-    if ( ((unsigned long)ctxt->address & ~PAGE_MASK) != 0 )
-        return 0;
-
-    /* Crossing page boundary: machine address must be calculated. */
-    paddr = (unsigned long)&ctxt->desc_in_paddr->address[i];
-    ret = xencomm_get_page(paddr, &page);
-    if ( ret )
-        return ret;
-
-    put_page(ctxt->page);
-    ctxt->page = page;
-    ctxt->address = xencomm_vaddr(paddr, page);
-
-    return 0;
-}
-
-static void
-xencomm_ctxt_done(struct xencomm_ctxt *ctxt)
-{
-    put_page(ctxt->page);
-}
-
-static int
-xencomm_copy_chunk_from(
-    unsigned long to, unsigned long paddr, unsigned int  len)
-{
-    struct page_info *page;
-    int res;
-
-    do {
-        res = xencomm_get_page(paddr, &page);
-    } while ( res == -EAGAIN );
-
-    if ( res )
-        return res;
-
-    xc_dprintk("%lx[%d] -> %lx\n",
-               (unsigned long)xencomm_vaddr(paddr, page), len, to);
-
-    memcpy((void *)to, xencomm_vaddr(paddr, page), len);
-    put_page(page);
-
-    return 0;
-}
-
-static unsigned long
-xencomm_inline_from_guest(
-    void *to, const void *from, unsigned int n, unsigned int skip)
-{
-    unsigned long src_paddr = xencomm_inline_addr(from) + skip;
-
-    while ( n > 0 )
-    {
-        unsigned int chunksz, bytes;
-
-        chunksz = PAGE_SIZE - (src_paddr % PAGE_SIZE);
-        bytes   = min(chunksz, n);
-
-        if ( xencomm_copy_chunk_from((unsigned long)to, src_paddr, bytes) )
-            return n;
-        src_paddr += bytes;
-        to += bytes;
-        n -= bytes;
-    }
-
-    /* Always successful. */
-    return 0;
-}
-
-/**
- * xencomm_copy_from_guest: Copy a block of data from domain space.
- * @to:   Machine address.
- * @from: Physical address to a xencomm buffer descriptor.
- * @n:    Number of bytes to copy.
- * @skip: Number of bytes from the start to skip.
- *
- * Copy data from domain to hypervisor.
- *
- * Returns number of bytes that could not be copied.
- * On success, this will be zero.
- */
-unsigned long
-xencomm_copy_from_guest(
-    void *to, const void *from, unsigned int n, unsigned int skip)
-{
-    struct xencomm_ctxt ctxt;
-    unsigned int from_pos = 0;
-    unsigned int to_pos = 0;
-    unsigned int i = 0;
-
-    if ( xencomm_is_inline(from) )
-        return xencomm_inline_from_guest(to, from, n, skip);
-
-    if ( xencomm_ctxt_init(from, &ctxt) )
-        return n;
-
-    /* Iterate through the descriptor, copying up to a page at a time */
-    while ( (to_pos < n) && (i < xencomm_ctxt_nr_addrs(&ctxt)) )
-    {
-        unsigned long src_paddr;
-        unsigned int pgoffset, chunksz, chunk_skip;
-
-        if ( xencomm_ctxt_next(&ctxt, i) )
-            goto out;
-        src_paddr = *xencomm_ctxt_address(&ctxt);
-        if ( src_paddr == XENCOMM_INVALID )
-        {
-            i++;
-            continue;
-        }
-
-        pgoffset = src_paddr % PAGE_SIZE;
-        chunksz = PAGE_SIZE - pgoffset;
-
-        chunk_skip = min(chunksz, skip);
-        from_pos += chunk_skip;
-        chunksz -= chunk_skip;
-        skip -= chunk_skip;
-
-        if ( skip == 0 && chunksz > 0 )
-        {
-            unsigned int bytes = min(chunksz, n - to_pos);
-
-            if ( xencomm_copy_chunk_from((unsigned long)to + to_pos,
-                                         src_paddr + chunk_skip, bytes) )
-                goto out;
-            from_pos += bytes;
-            to_pos += bytes;
-        }
-
-        i++;
-    }
-
-out:
-    xencomm_ctxt_done(&ctxt);
-    return n - to_pos;
-}
-
-static int
-xencomm_copy_chunk_to(
-    unsigned long paddr, unsigned long from, unsigned int  len)
-{
-    struct page_info *page;
-    int res;
-
-    do {
-        res = xencomm_get_page(paddr, &page);
-    } while ( res == -EAGAIN );
-
-    if ( res )
-        return res;
-
-    xc_dprintk("%lx[%d] -> %lx\n", from, len,
-               (unsigned long)xencomm_vaddr(paddr, page));
-
-    memcpy(xencomm_vaddr(paddr, page), (void *)from, len);
-    xencomm_mark_dirty((unsigned long)xencomm_vaddr(paddr, page), len);
-    put_page(page);
-
-    return 0;
-}
-
-static unsigned long
-xencomm_inline_to_guest(
-    void *to, const void *from, unsigned int n, unsigned int skip)
-{
-    unsigned long dest_paddr = xencomm_inline_addr(to) + skip;
-
-    while ( n > 0 )
-    {
-        unsigned int chunksz, bytes;
-
-        chunksz = PAGE_SIZE - (dest_paddr % PAGE_SIZE);
-        bytes   = min(chunksz, n);
-
-        if ( xencomm_copy_chunk_to(dest_paddr, (unsigned long)from, bytes) )
-            return n;
-        dest_paddr += bytes;
-        from += bytes;
-        n -= bytes;
-    }
-
-    /* Always successful. */
-    return 0;
-}
-
-/**
- * xencomm_copy_to_guest: Copy a block of data to domain space.
- * @to:     Physical address to xencomm buffer descriptor.
- * @from:   Machine address.
- * @n:      Number of bytes to copy.
- * @skip: Number of bytes from the start to skip.
- *
- * Copy data from hypervisor to domain.
- *
- * Returns number of bytes that could not be copied.
- * On success, this will be zero.
- */
-unsigned long
-xencomm_copy_to_guest(
-    void *to, const void *from, unsigned int n, unsigned int skip)
-{
-    struct xencomm_ctxt ctxt;
-    unsigned int from_pos = 0;
-    unsigned int to_pos = 0;
-    unsigned int i = 0;
-
-    if ( xencomm_is_inline(to) )
-        return xencomm_inline_to_guest(to, from, n, skip);
-
-    if ( xencomm_ctxt_init(to, &ctxt) )
-        return n;
-
-    /* Iterate through the descriptor, copying up to a page at a time */
-    while ( (from_pos < n) && (i < xencomm_ctxt_nr_addrs(&ctxt)) )
-    {
-        unsigned long dest_paddr;
-        unsigned int pgoffset, chunksz, chunk_skip;
-
-        if ( xencomm_ctxt_next(&ctxt, i) )
-            goto out;
-        dest_paddr = *xencomm_ctxt_address(&ctxt);
-        if ( dest_paddr == XENCOMM_INVALID )
-        {
-            i++;
-            continue;
-        }
-
-        pgoffset = dest_paddr % PAGE_SIZE;
-        chunksz = PAGE_SIZE - pgoffset;
-
-        chunk_skip = min(chunksz, skip);
-        to_pos += chunk_skip;
-        chunksz -= chunk_skip;
-        skip -= chunk_skip;
-
-        if ( skip == 0 && chunksz > 0 )
-        {
-            unsigned int bytes = min(chunksz, n - from_pos);
-
-            if ( xencomm_copy_chunk_to(dest_paddr + chunk_skip,
-                                      (unsigned long)from + from_pos, bytes) )
-                goto out;
-            from_pos += bytes;
-            to_pos += bytes;
-        }
-
-        i++;
-    }
-
-out:
-    xencomm_ctxt_done(&ctxt);
-    return n - from_pos;
-}
-
-static int
-xencomm_clear_chunk(
-    unsigned long paddr, unsigned int  len)
-{
-    struct page_info *page;
-    int res;
-
-    do {
-        res = xencomm_get_page(paddr, &page);
-    } while ( res == -EAGAIN );
-
-    if ( res )
-        return res;
-
-    memset(xencomm_vaddr(paddr, page), 0x00, len);
-    xencomm_mark_dirty((unsigned long)xencomm_vaddr(paddr, page), len);
-    put_page(page);
-
-    return 0;
-}
-
-static unsigned long
-xencomm_inline_clear_guest(
-    void *to, unsigned int n, unsigned int skip)
-{
-    unsigned long dest_paddr = xencomm_inline_addr(to) + skip;
-
-    while ( n > 0 )
-    {
-        unsigned int chunksz, bytes;
-
-        chunksz = PAGE_SIZE - (dest_paddr % PAGE_SIZE);
-        bytes   = min(chunksz, n);
-
-        if ( xencomm_clear_chunk(dest_paddr, bytes) )
-            return n;
-        dest_paddr += bytes;
-        n -= bytes;
-    }
-
-    /* Always successful. */
-    return 0;
-}
-
-/**
- * xencomm_clear_guest: Clear a block of data in domain space.
- * @to:     Physical address to xencomm buffer descriptor.
- * @n:      Number of bytes to copy.
- * @skip: Number of bytes from the start to skip.
- *
- * Clear domain data
- *
- * Returns number of bytes that could not be cleared
- * On success, this will be zero.
- */
-unsigned long
-xencomm_clear_guest(
-    void *to, unsigned int n, unsigned int skip)
-{
-    struct xencomm_ctxt ctxt;
-    unsigned int from_pos = 0;
-    unsigned int to_pos = 0;
-    unsigned int i = 0;
-
-    if ( xencomm_is_inline(to) )
-        return xencomm_inline_clear_guest(to, n, skip);
-
-    if ( xencomm_ctxt_init(to, &ctxt) )
-        return n;
-
-    /* Iterate through the descriptor, copying up to a page at a time */
-    while ( (from_pos < n) && (i < xencomm_ctxt_nr_addrs(&ctxt)) )
-    {
-        unsigned long dest_paddr;
-        unsigned int pgoffset, chunksz, chunk_skip;
-
-        if ( xencomm_ctxt_next(&ctxt, i) )
-            goto out;
-        dest_paddr = *xencomm_ctxt_address(&ctxt);
-        if ( dest_paddr == XENCOMM_INVALID )
-        {
-            i++;
-            continue;
-        }
-
-        pgoffset = dest_paddr % PAGE_SIZE;
-        chunksz = PAGE_SIZE - pgoffset;
-
-        chunk_skip = min(chunksz, skip);
-        to_pos += chunk_skip;
-        chunksz -= chunk_skip;
-        skip -= chunk_skip;
-
-        if ( skip == 0 && chunksz > 0 )
-        {
-            unsigned int bytes = min(chunksz, n - from_pos);
-
-            if ( xencomm_clear_chunk(dest_paddr + chunk_skip, bytes) )
-                goto out;
-            from_pos += bytes;
-            to_pos += bytes;
-        }
-
-        i++;
-    }
-
-out:
-    xencomm_ctxt_done(&ctxt);
-    return n - from_pos;
-}
-
-static int xencomm_inline_add_offset(void **handle, unsigned int bytes)
-{
-    *handle += bytes;
-    return 0;
-}
-
-/* Offset page addresses in 'handle' to skip 'bytes' bytes. Set completely
- * exhausted pages to XENCOMM_INVALID. */
-int xencomm_add_offset(void **handle, unsigned int bytes)
-{
-    struct xencomm_ctxt ctxt;
-    int i = 0;
-    int res = 0;
-
-    if ( xencomm_is_inline(*handle) )
-        return xencomm_inline_add_offset(handle, bytes);
-
-    res = xencomm_ctxt_init(handle, &ctxt);
-    if ( res != 0 )
-        return res;
-
-    /* Iterate through the descriptor incrementing addresses */
-    while ( (bytes > 0) && (i < xencomm_ctxt_nr_addrs(&ctxt)) )
-    {
-        unsigned long *address;
-        unsigned long dest_paddr;
-        unsigned int pgoffset, chunksz, chunk_skip;
-
-        res = xencomm_ctxt_next(&ctxt, i);
-        if ( res )
-            goto out;
-        address = xencomm_ctxt_address(&ctxt);
-        dest_paddr = *address;
-        if ( dest_paddr == XENCOMM_INVALID )
-        {
-            i++;
-            continue;
-        }
-
-        pgoffset = dest_paddr % PAGE_SIZE;
-        chunksz = PAGE_SIZE - pgoffset;
-
-        chunk_skip = min(chunksz, bytes);
-        if ( chunk_skip == chunksz )
-            *address = XENCOMM_INVALID; /* exhausted this page */
-        else
-            *address += chunk_skip;
-        bytes -= chunk_skip;
-
-        i++;
-    }
-
-out:
-    xencomm_ctxt_done(&ctxt);
-    return res;
-}
-
-int xencomm_handle_is_null(void *handle)
-{
-    struct xencomm_ctxt ctxt;
-    int i;
-    int res = 1;
-
-    if ( xencomm_is_inline(handle) )
-        return xencomm_inline_addr(handle) == 0;
-
-    if ( xencomm_ctxt_init(handle, &ctxt) )
-        return 1;
-
-    for ( i = 0; i < xencomm_ctxt_nr_addrs(&ctxt); i++ )
-    {
-        if ( xencomm_ctxt_next(&ctxt, i) )
-            goto out;
-        if ( *xencomm_ctxt_address(&ctxt) != XENCOMM_INVALID )
-        {
-            res = 0;
-            goto out;
-        }
-    }
-
-out:
-    xencomm_ctxt_done(&ctxt);
-    return res;
-}
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/Makefile b/xen/include/Makefile
index f7ccbc9..94112d1 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -21,7 +21,6 @@ headers-y := \
     compat/vcpu.h \
     compat/version.h \
     compat/xen.h \
-    compat/xencomm.h \
     compat/xenoprof.h
 headers-$(CONFIG_X86)     += compat/arch-x86/xen-mca.h
 headers-$(CONFIG_X86)     += compat/arch-x86/xen.h
diff --git a/xen/include/xen/xencomm.h b/xen/include/xen/xencomm.h
deleted file mode 100644
index 3426b8a..0000000
--- a/xen/include/xen/xencomm.h
+++ /dev/null
@@ -1,170 +0,0 @@
-/*
- * 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, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
- *
- * Copyright (C) IBM Corp. 2006
- *
- * Authors: Hollis Blanchard <hollisb@us.ibm.com>
- */
-
-#ifndef __XENCOMM_H__
-#define __XENCOMM_H__
-
-#include <public/xen.h>
-
-unsigned long xencomm_copy_to_guest(
-    void *to, const void *from, unsigned int len, unsigned int skip); 
-unsigned long xencomm_copy_from_guest(
-    void *to, const void *from, unsigned int len, unsigned int skip); 
-unsigned long xencomm_clear_guest(
-    void *to, unsigned int n, unsigned int skip);
-int xencomm_add_offset(void **handle, unsigned int bytes);
-int xencomm_handle_is_null(void *ptr);
-
-static inline int xencomm_is_inline(const void *handle)
-{
-    unsigned long addr = (unsigned long)handle;
-    return (addr & XENCOMM_INLINE_FLAG) == XENCOMM_INLINE_FLAG;
-}
-
-static inline unsigned long xencomm_inline_addr(const void *handle)
-{
-    return (unsigned long)handle & ~XENCOMM_INLINE_FLAG;
-}
-
-#define raw_copy_to_guest(dst, src, len)       \
-    xencomm_copy_to_guest(dst, src, len, 0)
-#define raw_copy_from_guest(dst, src, len)     \
-    xencomm_copy_from_guest(dst, src, nr, 0)
-#define raw_clear_guest(dst, len)              \
-    xencomm_clear_guest(dst, len, 0)
-#define __raw_copy_to_guest raw_copy_to_guest
-#define __raw_copy_from_guest raw_copy_from_guest
-#define __raw_clear_guest raw_clear_guest
-
-/* Is the guest handle a NULL reference? */
-#define guest_handle_is_null(hnd) \
-    ((hnd).p == NULL || xencomm_handle_is_null((hnd).p))
-
-/* Offset the given guest handle into the array it refers to. */
-#define guest_handle_add_offset(hnd, nr) ({                             \
-    const typeof((hnd).p) _ptr;                                         \
-    xencomm_add_offset((void **)&((hnd).p), nr * sizeof(*_ptr));        \
-})
-
-/* Cast a guest handle to the specified type of handle. */
-#define guest_handle_cast(hnd, type) ({         \
-    type *_x = (hnd).p;                         \
-    XEN_GUEST_HANDLE_PARAM(type) _y;            \
-    set_xen_guest_handle(_y, _x);               \
-    _y;                                         \
-})
-
-/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
-#define guest_handle_to_param(hnd, type) ({                  \
-    /* type checking: make sure that the pointers inside     \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
-     * the same type, then return hnd */                     \
-    (void)((typeof(&(hnd).p)) 0 ==                           \
-        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
-    (hnd);                                                   \
-})
-
-/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
-#define guest_handle_from_param(hnd, type) ({                \
-    /* type checking: make sure that the pointers inside     \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
-     * the same type, then return hnd */                     \
-    (void)((typeof(&(hnd).p)) 0 ==                           \
-        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
-    (hnd);                                                   \
-})
-
-/* Since we run in real mode, we can safely access all addresses. That also
- * means our __routines are identical to our "normal" routines. */
-#define guest_handle_okay(hnd, nr) 1
-#define guest_handle_subrange_okay(hnd, first, last) 1
-
-/*
- * Copy an array of objects to guest context via a guest handle.
- * Optionally specify an offset into the guest array.
- */
-#define copy_to_guest_offset(hnd, idx, ptr, nr) \
-    __copy_to_guest_offset(hnd, idx, ptr, nr)
-
-/* Copy sub-field of a structure to guest context via a guest handle. */
-#define copy_field_to_guest(hnd, ptr, field) \
-    __copy_field_to_guest(hnd, ptr, field)
-
-/*
- * Copy an array of objects from guest context via a guest handle.
- * Optionally specify an offset into the guest array.
- */
-#define copy_from_guest_offset(ptr, hnd, idx, nr) \
-    __copy_from_guest_offset(ptr, hnd, idx, nr)
-
-/*
- * Clear an array of objects in guest context via a guest handle.
- * Optionally specify an offset into the guest array.
- */
-#define clear_guest_offset(hnd, idx, nr) \
-    __clear_guest_offset(hnd, idx, nr)
-
-/* Copy sub-field of a structure from guest context via a guest handle. */
-#define copy_field_from_guest(ptr, hnd, field) \
-    __copy_field_from_guest(ptr, hnd, field)
-
-#define __copy_to_guest_offset(hnd, idx, ptr, nr) ({                \
-    const typeof(*(ptr)) *_s = (ptr);                               \
-    void *_d = (hnd).p;                                             \
-    ((void)((hnd).p == (ptr)));                                     \
-    xencomm_copy_to_guest(_d, _s, sizeof(*_s)*(nr), sizeof(*_s)*(idx)); \
-})
-
-#define __copy_field_to_guest(hnd, ptr, field) ({                   \
-    unsigned int _off = offsetof(typeof(*(hnd).p), field);          \
-    const typeof(&(ptr)->field) _s = &(ptr)->field;                 \
-    void *_d = (hnd).p;                                             \
-    ((void)(&(hnd).p->field == &(ptr)->field));                     \
-    xencomm_copy_to_guest(_d, _s, sizeof(*_s), _off);               \
-})
-
-#define __copy_from_guest_offset(ptr, hnd, idx, nr) ({              \
-    const typeof(*(ptr)) *_s = (hnd).p;                             \
-    typeof(*(ptr)) *_d = (ptr);                                     \
-    xencomm_copy_from_guest(_d, _s, sizeof(*_d)*(nr), sizeof(*_d)*(idx)); \
-})
-
-#define __copy_field_from_guest(ptr, hnd, field) ({                 \
-    unsigned int _off = offsetof(typeof(*(hnd).p), field);          \
-    const void *_s = (hnd).p;                                       \
-    typeof(&(ptr)->field) _d = &(ptr)->field;                       \
-    ((void)(&(hnd).p->field == &(ptr)->field));                     \
-    xencomm_copy_from_guest(_d, _s, sizeof(*_d), _off);             \
-})
-
-#define __clear_guest_offset(hnd, idx, nr) ({                \
-    void *_d = (hnd).p;                                             \
-    xencomm_clear_guest(_d, nr, idx); \
-})
-
-#ifdef CONFIG_XENCOMM_MARK_DIRTY
-extern void xencomm_mark_dirty(unsigned long addr, unsigned int len);
-#else
-static inline void xencomm_mark_dirty(unsigned long addr, unsigned int len)
-{
-}
-#endif
-
-#endif /* __XENCOMM_H__ */
-- 
2.0.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:05:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:05:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XowtJ-0007fS-HD; Thu, 13 Nov 2014 16:05:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XowtI-0007f4-GE
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 16:05:00 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	56/B5-09284-BA6D4645; Thu, 13 Nov 2014 16:04:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415894697!11068277!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19636 invoked from network); 13 Nov 2014 16:04:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:04:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="191004363"
Message-ID: <5464D627.7060104@citrix.com>
Date: Thu, 13 Nov 2014 16:02:47 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Konrad Wilk <konrad.wilk@oracle.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: [Xen-devel] XenServer results from the Test Day for RC2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

While attempting to test Konrads new interrupt injection logic, I got
blocked behind yet another Pygrub bug caused by c/s d1b93ea

This is the first time I have looked into the issue, but a cursory
inspection of the first hunk shows that it cannot possibly be correct as
self._default is either an integer or string.

I have a possible workaround which I am testing, but cursory review of
the patch would have shown that it cannot work as intended.

Notice that self._default is now either a string or an integer,
defaulting to an integer, and the top level code is updated to require a
string.  As a result, any bootloader configuration which doesn't
explicitly set a default, or still drives this logic with integers
(ExtLinux or LiLO) will die with an AttributeError

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:05:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:05:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XowtJ-0007fS-HD; Thu, 13 Nov 2014 16:05:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XowtI-0007f4-GE
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 16:05:00 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	56/B5-09284-BA6D4645; Thu, 13 Nov 2014 16:04:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415894697!11068277!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19636 invoked from network); 13 Nov 2014 16:04:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:04:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="191004363"
Message-ID: <5464D627.7060104@citrix.com>
Date: Thu, 13 Nov 2014 16:02:47 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Konrad Wilk <konrad.wilk@oracle.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: [Xen-devel] XenServer results from the Test Day for RC2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

While attempting to test Konrads new interrupt injection logic, I got
blocked behind yet another Pygrub bug caused by c/s d1b93ea

This is the first time I have looked into the issue, but a cursory
inspection of the first hunk shows that it cannot possibly be correct as
self._default is either an integer or string.

I have a possible workaround which I am testing, but cursory review of
the patch would have shown that it cannot work as intended.

Notice that self._default is now either a string or an integer,
defaulting to an integer, and the top level code is updated to require a
string.  As a result, any bootloader configuration which doesn't
explicitly set a default, or still drives this logic with integers
(ExtLinux or LiLO) will die with an AttributeError

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:17:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xox5M-000881-TU; Thu, 13 Nov 2014 16:17:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xox5L-00087w-3F
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:17:27 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	99/AA-22819-699D4645; Thu, 13 Nov 2014 16:17:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415895445!7840716!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17316 invoked from network); 13 Nov 2014 16:17:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Nov 2014 16:17:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 16:17:24 +0000
Message-Id: <5464E7A502000078000474AE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 16:17:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1413370425-15015-1-git-send-email-roger.pau@citrix.com>
	<1413370425-15015-2-git-send-email-roger.pau@citrix.com>
	<20141016092005.GB71219@deinos.phlegethon.org>
	<543F97D6.7080702@citrix.com>
	<20141113154645.GB74761@deinos.phlegethon.org>
In-Reply-To: <20141113154645.GB74761@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 1/2] xen/pvh: take the p2m lock when
 doing logdirty ops from HVM domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 16:46, <tim@xen.org> wrote:
> That leaves paging_log_dirty_op().  The inner loops of that function
> are already set up to be preempted for softirqs, &c.  I wonder could
> we arrange for it to map the first N pages of bitmap before taking any
> locks, and then drop the locks after that many pages, and unmap them
> again.
> 
> It wouldn't even need to actually set up a hypercall continuation if 
> !hypercall_preempt_check(); it can simply map a new batch and carry
> on.
> 
> Does that sounds plausible?  If so, then we can leave the lock
> constraints as they are, which would make me very happy. :)

Apart from the already not too easily readable code becoming even
more convoluted, one possible extra problem I see is that
d->arch.paging.preempt modifications are currently being protected
by the paging lock. I.e. acquiring that lock later and dropping it
intermediately would further complicate the state tracking here. But
maybe this could be dealt with by setting
d->arch.paging.preempt.dom to current->domain earlier (i.e.
before even starting)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:17:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xox5M-000881-TU; Thu, 13 Nov 2014 16:17:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xox5L-00087w-3F
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:17:27 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	99/AA-22819-699D4645; Thu, 13 Nov 2014 16:17:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415895445!7840716!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17316 invoked from network); 13 Nov 2014 16:17:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Nov 2014 16:17:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 16:17:24 +0000
Message-Id: <5464E7A502000078000474AE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 16:17:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1413370425-15015-1-git-send-email-roger.pau@citrix.com>
	<1413370425-15015-2-git-send-email-roger.pau@citrix.com>
	<20141016092005.GB71219@deinos.phlegethon.org>
	<543F97D6.7080702@citrix.com>
	<20141113154645.GB74761@deinos.phlegethon.org>
In-Reply-To: <20141113154645.GB74761@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 1/2] xen/pvh: take the p2m lock when
 doing logdirty ops from HVM domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 16:46, <tim@xen.org> wrote:
> That leaves paging_log_dirty_op().  The inner loops of that function
> are already set up to be preempted for softirqs, &c.  I wonder could
> we arrange for it to map the first N pages of bitmap before taking any
> locks, and then drop the locks after that many pages, and unmap them
> again.
> 
> It wouldn't even need to actually set up a hypercall continuation if 
> !hypercall_preempt_check(); it can simply map a new batch and carry
> on.
> 
> Does that sounds plausible?  If so, then we can leave the lock
> constraints as they are, which would make me very happy. :)

Apart from the already not too easily readable code becoming even
more convoluted, one possible extra problem I see is that
d->arch.paging.preempt modifications are currently being protected
by the paging lock. I.e. acquiring that lock later and dropping it
intermediately would further complicate the state tracking here. But
maybe this could be dealt with by setting
d->arch.paging.preempt.dom to current->domain earlier (i.e.
before even starting)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:17:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xox5l-00089X-9V; Thu, 13 Nov 2014 16:17: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@citrix.com>) id 1Xox5j-00089J-UH
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:17:52 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B7/F1-31453-FA9D4645; Thu, 13 Nov 2014 16:17:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415895465!11179524!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17765 invoked from network); 13 Nov 2014 16:17:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:17:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="191012040"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 11:16:24 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xox4K-0003zK-8a;
	Thu, 13 Nov 2014 16:16:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xox4J-0006lD-EY;
	Thu, 13 Nov 2014 16:16:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21604.55638.693745.459883@mariner.uk.xensource.com>
Date: Thu, 13 Nov 2014 16:16:22 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415788588.25176.56.camel@citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415788588.25176.56.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/9] Host allocation scoring
	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

Ian Campbell writes ("Re: [OSSTEST PATCH 0/9] Host allocation scoring improvements"):
> On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> > Here, I'm trying to fix the way that osstest gets far too obsessed
> > about particular failing hosts.
> 
> All fine by me, not that I've really grokked the bits towards the end.
> (I will try to if you want)

I find this area a bit confusing, and it's a right bastard to test, so
if you have the bandwidth for a proper review that would be great.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:17:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xox5l-00089X-9V; Thu, 13 Nov 2014 16:17: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@citrix.com>) id 1Xox5j-00089J-UH
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:17:52 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B7/F1-31453-FA9D4645; Thu, 13 Nov 2014 16:17:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415895465!11179524!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17765 invoked from network); 13 Nov 2014 16:17:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:17:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="191012040"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 11:16:24 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xox4K-0003zK-8a;
	Thu, 13 Nov 2014 16:16:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xox4J-0006lD-EY;
	Thu, 13 Nov 2014 16:16:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21604.55638.693745.459883@mariner.uk.xensource.com>
Date: Thu, 13 Nov 2014 16:16:22 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415788588.25176.56.camel@citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415788588.25176.56.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/9] Host allocation scoring
	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

Ian Campbell writes ("Re: [OSSTEST PATCH 0/9] Host allocation scoring improvements"):
> On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> > Here, I'm trying to fix the way that osstest gets far too obsessed
> > about particular failing hosts.
> 
> All fine by me, not that I've really grokked the bits towards the end.
> (I will try to if you want)

I find this area a bit confusing, and it's a right bastard to test, so
if you have the bandwidth for a proper review that would be great.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:19:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16: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 1Xox6t-0008GS-K7; Thu, 13 Nov 2014 16:19:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xox6q-0008GE-Rl
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:19:00 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	88/7A-24532-4F9D4645; Thu, 13 Nov 2014 16:19:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415895539!5244704!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10048 invoked from network); 13 Nov 2014 16:18:59 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 16:18:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 16:18:59 +0000
Message-Id: <5464E80202000078000474B1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 16:18:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1415894589-18256-1-git-send-email-tim@xen.org>
In-Reply-To: <1415894589-18256-1-git-send-email-tim@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, keir@xen.org,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2] xen: remove Xencomm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 17:03, <tim@xen.org> wrote:
> Being a feature that has only been used by ia64 and/or ppc it
> doesn't seem like we need to keep it any longer in the tree.
> 
> So remove it.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:19:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16: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 1Xox6t-0008GS-K7; Thu, 13 Nov 2014 16:19:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xox6q-0008GE-Rl
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:19:00 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	88/7A-24532-4F9D4645; Thu, 13 Nov 2014 16:19:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415895539!5244704!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10048 invoked from network); 13 Nov 2014 16:18:59 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 16:18:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 13 Nov 2014 16:18:59 +0000
Message-Id: <5464E80202000078000474B1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 13 Nov 2014 16:18:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1415894589-18256-1-git-send-email-tim@xen.org>
In-Reply-To: <1415894589-18256-1-git-send-email-tim@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, keir@xen.org,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2] xen: remove Xencomm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 17:03, <tim@xen.org> wrote:
> Being a feature that has only been used by ia64 and/or ppc it
> doesn't seem like we need to keep it any longer in the tree.
> 
> So remove it.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:21:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16: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 1Xox9M-0008SF-64; Thu, 13 Nov 2014 16:21:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xox9K-0008S4-Qa
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:21:34 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	84/2C-11581-E8AD4645; Thu, 13 Nov 2014 16:21:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415895690!11172341!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20461 invoked from network); 13 Nov 2014 16:21:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:21:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="191014063"
Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.79)
	with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 11:19:50 -0500
Message-ID: <5464DA25.7050604@citrix.com>
Date: Thu, 13 Nov 2014 17:19:49 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1415890703-10147-1-git-send-email-roger.pau@citrix.com>
	<alpine.DEB.2.02.1411131513470.26318@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411131513470.26318@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2 for-xen-4.5] xen_disk: fix unmapping of
 persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 13/11/14 a les 16.36, Stefano Stabellini ha escrit:
> On Thu, 13 Nov 2014, Roger Pau Monne wrote:
>> @@ -421,7 +451,17 @@ static int ioreq_map(struct ioreq *ioreq)
>>              }
>>          }
>>      }
>> -    if (ioreq->blkdev->feature_persistent) {
>> +    if (ioreq->blkdev->feature_persistent && new_maps &&
>> +        (!batch_maps || (ioreq->blkdev->persistent_gnt_count + new_maps <=
>> +        ioreq->blkdev->max_grants))) {
> 
> Do we really need this change? If so, could you please write something
> about it in the commit message?

Ack.

> 
>> +        /*
>> +         * If we are using persistent grants and batch mappings only
>> +         * add the new maps to the list of persistent grants if the whole
>> +         * area can be persistently mapped.
>> +         */
> 
> Is this the reason for the change above?

Yes, this is the reason. Maybe it's not clear enough. If we are using
batch maps we have to map all the region persistently, we cannot cherry
pick single grants and make them persistent.

> 
>> +        if (batch_maps && new_maps) {
>> +            add_persistent_region(ioreq->blkdev, ioreq->pages, new_maps);
>> +        }
>>
>>          while ((ioreq->blkdev->persistent_gnt_count < ioreq->blkdev->max_grants)
>>                && new_maps) {
>>              /* Go through the list of newly mapped grants and add as many
>> @@ -437,6 +477,7 @@ static int ioreq_map(struct ioreq *ioreq)
>>                  grant->page = ioreq->pages + (new_maps) * XC_PAGE_SIZE;
>>              } else {
>>                  grant->page = ioreq->page[new_maps];
>> +                add_persistent_region(ioreq->blkdev, ioreq->page[new_maps], 1);
> 
> Basically in the !batch_maps case we are duplicating persistent_gnts
> into persistent_regions. Couldn't we just avoid calling
> add_persistent_region at all in that case and rely on the old
> destroy_grant function? In fact I think we could just pass NULL as
> GDestroyNotify function when creating persistent_gnts if batch_maps and
> the old unmodified destroy_grant if !batch_maps.

Not exactly, we still need the GDestroyNotify function in the batch_maps
case, but I could just pass g_free directly. Let me send v3 with this
reworked.

> 
>>              }
>>              grant->blkdev = ioreq->blkdev;
>>              xen_be_printf(&ioreq->blkdev->xendev, 3,
>> @@ -447,6 +488,7 @@ static int ioreq_map(struct ioreq *ioreq)
>>                            grant);
>>              ioreq->blkdev->persistent_gnt_count++;
>>          }
>> +        assert(!batch_maps || new_maps == 0);
> 
> Shouldn't new_maps be == 0 even in the !batch_maps case?

In theory yes, because we can persistently map all the grants that can
be on the ring. But a malicious/badly coded blkfront could try to
exploit this by always passing different grants, in which case we would
not be able to map them all persistently.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:21:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16: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 1Xox9M-0008SF-64; Thu, 13 Nov 2014 16:21:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xox9K-0008S4-Qa
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:21:34 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	84/2C-11581-E8AD4645; Thu, 13 Nov 2014 16:21:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415895690!11172341!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20461 invoked from network); 13 Nov 2014 16:21:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:21:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="191014063"
Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.79)
	with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 11:19:50 -0500
Message-ID: <5464DA25.7050604@citrix.com>
Date: Thu, 13 Nov 2014 17:19:49 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1415890703-10147-1-git-send-email-roger.pau@citrix.com>
	<alpine.DEB.2.02.1411131513470.26318@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411131513470.26318@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2 for-xen-4.5] xen_disk: fix unmapping of
 persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 13/11/14 a les 16.36, Stefano Stabellini ha escrit:
> On Thu, 13 Nov 2014, Roger Pau Monne wrote:
>> @@ -421,7 +451,17 @@ static int ioreq_map(struct ioreq *ioreq)
>>              }
>>          }
>>      }
>> -    if (ioreq->blkdev->feature_persistent) {
>> +    if (ioreq->blkdev->feature_persistent && new_maps &&
>> +        (!batch_maps || (ioreq->blkdev->persistent_gnt_count + new_maps <=
>> +        ioreq->blkdev->max_grants))) {
> 
> Do we really need this change? If so, could you please write something
> about it in the commit message?

Ack.

> 
>> +        /*
>> +         * If we are using persistent grants and batch mappings only
>> +         * add the new maps to the list of persistent grants if the whole
>> +         * area can be persistently mapped.
>> +         */
> 
> Is this the reason for the change above?

Yes, this is the reason. Maybe it's not clear enough. If we are using
batch maps we have to map all the region persistently, we cannot cherry
pick single grants and make them persistent.

> 
>> +        if (batch_maps && new_maps) {
>> +            add_persistent_region(ioreq->blkdev, ioreq->pages, new_maps);
>> +        }
>>
>>          while ((ioreq->blkdev->persistent_gnt_count < ioreq->blkdev->max_grants)
>>                && new_maps) {
>>              /* Go through the list of newly mapped grants and add as many
>> @@ -437,6 +477,7 @@ static int ioreq_map(struct ioreq *ioreq)
>>                  grant->page = ioreq->pages + (new_maps) * XC_PAGE_SIZE;
>>              } else {
>>                  grant->page = ioreq->page[new_maps];
>> +                add_persistent_region(ioreq->blkdev, ioreq->page[new_maps], 1);
> 
> Basically in the !batch_maps case we are duplicating persistent_gnts
> into persistent_regions. Couldn't we just avoid calling
> add_persistent_region at all in that case and rely on the old
> destroy_grant function? In fact I think we could just pass NULL as
> GDestroyNotify function when creating persistent_gnts if batch_maps and
> the old unmodified destroy_grant if !batch_maps.

Not exactly, we still need the GDestroyNotify function in the batch_maps
case, but I could just pass g_free directly. Let me send v3 with this
reworked.

> 
>>              }
>>              grant->blkdev = ioreq->blkdev;
>>              xen_be_printf(&ioreq->blkdev->xendev, 3,
>> @@ -447,6 +488,7 @@ static int ioreq_map(struct ioreq *ioreq)
>>                            grant);
>>              ioreq->blkdev->persistent_gnt_count++;
>>          }
>> +        assert(!batch_maps || new_maps == 0);
> 
> Shouldn't new_maps be == 0 even in the !batch_maps case?

In theory yes, because we can persistently map all the grants that can
be on the ring. But a malicious/badly coded blkfront could try to
exploit this by always passing different grants, in which case we would
not be able to map them all persistently.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:29:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16: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 1XoxHF-0000PO-8F; Thu, 13 Nov 2014 16:29:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <talex5@gmail.com>) id 1XoxHD-0000PH-JL
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:29:43 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	3D/8B-02697-67CD4645; Thu, 13 Nov 2014 16:29:42 +0000
X-Env-Sender: talex5@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415896181!11211903!1
X-Originating-IP: [209.85.220.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19043 invoked from network); 13 Nov 2014 16:29:42 -0000
Received: from mail-vc0-f179.google.com (HELO mail-vc0-f179.google.com)
	(209.85.220.179)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:29:42 -0000
Received: by mail-vc0-f179.google.com with SMTP id le20so2499781vcb.24
	for <xen-devel@lists.xenproject.org>;
	Thu, 13 Nov 2014 08:29:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ZSVkk8UyH0A9v0uXHqIYEmEjg5qlQv3HQkJvBXYGucQ=;
	b=NdFRreoThz7CGDQKRw2XmChFDxyj4V/84zVC1F2ig0OAhxKfkWXV7MhtM2mxsn2Bvt
	KdANmqCbSgPOCVCodKMrrimFcgnZLaeGS73pUcj5WwdVWAWCOGTCeJFbrpi58u6a+nKp
	t9tHrL750lPVhUfMumuq9M+KarcS+3q2q3abjng7K6hTdPl3jjdGLiVqUbbE5G6N/9Bj
	fP6A5HSWIxwIG6sCJbTTN6bhBC68XoC8lHMoL8OUdUBaAcEngcmAjsFqcQmNLpjwqU8d
	HVfhzEJeU++3+xYNPjHoq5f5BZ5yODIpNR6MoDJuBe35ZdBbvamDORaAfwPwb1dYdjn3
	66wA==
MIME-Version: 1.0
X-Received: by 10.220.158.137 with SMTP id f9mr2391374vcx.34.1415896181109;
	Thu, 13 Nov 2014 08:29:41 -0800 (PST)
Received: by 10.31.130.80 with HTTP; Thu, 13 Nov 2014 08:29:41 -0800 (PST)
In-Reply-To: <1414406079.31057.6.camel@citrix.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-2-git-send-email-talex5@gmail.com>
	<1413888616.23337.22.camel@citrix.com>
	<CAG4opy_ntDYAnN2m-YBvzfPX3CWiHFYZ-tx+u-e=vygntayy9Q@mail.gmail.com>
	<1414406079.31057.6.camel@citrix.com>
Date: Thu, 13 Nov 2014 16:29:41 +0000
Message-ID: <CAG4opy-bY4HCmGik1y2DRLamXk=Tgj2J0cfqHjFRcs9goM1wqw@mail.gmail.com>
From: Thomas Leonard <talex5@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 1/4] mini-os: arm: time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27 October 2014 10:34, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Sun, 2014-10-26 at 09:51 +0000, Thomas Leonard wrote:
>> On 21 October 2014 11:50, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2014-10-03 at 10:20 +0100, Thomas Leonard wrote:
>> >> Based on an initial patch by Karim Raslan.
>> >>
>> >> Signed-off-by: Karim Allah Ahmed <karim.allah.ahmed@gmail.com>
>> >> Signed-off-by: Thomas Leonard <talex5@gmail.com>
>> >
>> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
>> >
>> >> +/* Wall-clock time is not currently available on ARM, so this is always zero for now:
>> >> + * http://wiki.xenproject.org/wiki/Xen_ARM_TODO#Expose_Wallclock_time_to_guests
>> >
>> > I have some slightly hacky patches for this, I really should dust them
>> > off and submit them...
>> >
>> >> +void block_domain(s_time_t until)
>> >> +{
>> >> +    uint64_t until_count = ns_to_ticks(until) + cntvct_at_init;
>> >> +    ASSERT(irqs_disabled());
>> >> +    if (read_virtual_count() < until_count)
>> >> +    {
>> >> +        set_vtimer_compare(until_count);
>> >> +        __asm__ __volatile__("wfi");
>> >> +        unset_vtimer_compare();
>> >> +
>> >> +        /* Give the IRQ handler a chance to handle whatever woke us up. */
>> >> +        local_irq_enable();
>> >> +        local_irq_disable();
>> >> +    }
>> >
>> > Just wondering, is this not roughly equivalent to a wfi loop with
>> > interrupts enabled?
>>
>> I'm not quite sure what you mean.
>>
>> If we enable interrupts before the wfi then I think the following could occur:
>>
>> 1. Application checks for work, finds none and calls block_domain.
>> 2. block_domain enables interrupts.
>> 3. An interrupt occurs.
>> 4. The interrupt handler sets a flag indicating work to do.
>> 5. wfi is called, putting the domain to sleep, even though there is work to do.
>>
>> Enabling IRQs after block_domain ensures we can't sleep while we have
>> work to do.
>
> Ah, yes.

So, can this patch be applied as-is now?


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:29:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16: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 1XoxHF-0000PO-8F; Thu, 13 Nov 2014 16:29:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <talex5@gmail.com>) id 1XoxHD-0000PH-JL
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:29:43 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	3D/8B-02697-67CD4645; Thu, 13 Nov 2014 16:29:42 +0000
X-Env-Sender: talex5@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415896181!11211903!1
X-Originating-IP: [209.85.220.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19043 invoked from network); 13 Nov 2014 16:29:42 -0000
Received: from mail-vc0-f179.google.com (HELO mail-vc0-f179.google.com)
	(209.85.220.179)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:29:42 -0000
Received: by mail-vc0-f179.google.com with SMTP id le20so2499781vcb.24
	for <xen-devel@lists.xenproject.org>;
	Thu, 13 Nov 2014 08:29:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ZSVkk8UyH0A9v0uXHqIYEmEjg5qlQv3HQkJvBXYGucQ=;
	b=NdFRreoThz7CGDQKRw2XmChFDxyj4V/84zVC1F2ig0OAhxKfkWXV7MhtM2mxsn2Bvt
	KdANmqCbSgPOCVCodKMrrimFcgnZLaeGS73pUcj5WwdVWAWCOGTCeJFbrpi58u6a+nKp
	t9tHrL750lPVhUfMumuq9M+KarcS+3q2q3abjng7K6hTdPl3jjdGLiVqUbbE5G6N/9Bj
	fP6A5HSWIxwIG6sCJbTTN6bhBC68XoC8lHMoL8OUdUBaAcEngcmAjsFqcQmNLpjwqU8d
	HVfhzEJeU++3+xYNPjHoq5f5BZ5yODIpNR6MoDJuBe35ZdBbvamDORaAfwPwb1dYdjn3
	66wA==
MIME-Version: 1.0
X-Received: by 10.220.158.137 with SMTP id f9mr2391374vcx.34.1415896181109;
	Thu, 13 Nov 2014 08:29:41 -0800 (PST)
Received: by 10.31.130.80 with HTTP; Thu, 13 Nov 2014 08:29:41 -0800 (PST)
In-Reply-To: <1414406079.31057.6.camel@citrix.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-2-git-send-email-talex5@gmail.com>
	<1413888616.23337.22.camel@citrix.com>
	<CAG4opy_ntDYAnN2m-YBvzfPX3CWiHFYZ-tx+u-e=vygntayy9Q@mail.gmail.com>
	<1414406079.31057.6.camel@citrix.com>
Date: Thu, 13 Nov 2014 16:29:41 +0000
Message-ID: <CAG4opy-bY4HCmGik1y2DRLamXk=Tgj2J0cfqHjFRcs9goM1wqw@mail.gmail.com>
From: Thomas Leonard <talex5@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 1/4] mini-os: arm: time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27 October 2014 10:34, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Sun, 2014-10-26 at 09:51 +0000, Thomas Leonard wrote:
>> On 21 October 2014 11:50, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2014-10-03 at 10:20 +0100, Thomas Leonard wrote:
>> >> Based on an initial patch by Karim Raslan.
>> >>
>> >> Signed-off-by: Karim Allah Ahmed <karim.allah.ahmed@gmail.com>
>> >> Signed-off-by: Thomas Leonard <talex5@gmail.com>
>> >
>> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
>> >
>> >> +/* Wall-clock time is not currently available on ARM, so this is always zero for now:
>> >> + * http://wiki.xenproject.org/wiki/Xen_ARM_TODO#Expose_Wallclock_time_to_guests
>> >
>> > I have some slightly hacky patches for this, I really should dust them
>> > off and submit them...
>> >
>> >> +void block_domain(s_time_t until)
>> >> +{
>> >> +    uint64_t until_count = ns_to_ticks(until) + cntvct_at_init;
>> >> +    ASSERT(irqs_disabled());
>> >> +    if (read_virtual_count() < until_count)
>> >> +    {
>> >> +        set_vtimer_compare(until_count);
>> >> +        __asm__ __volatile__("wfi");
>> >> +        unset_vtimer_compare();
>> >> +
>> >> +        /* Give the IRQ handler a chance to handle whatever woke us up. */
>> >> +        local_irq_enable();
>> >> +        local_irq_disable();
>> >> +    }
>> >
>> > Just wondering, is this not roughly equivalent to a wfi loop with
>> > interrupts enabled?
>>
>> I'm not quite sure what you mean.
>>
>> If we enable interrupts before the wfi then I think the following could occur:
>>
>> 1. Application checks for work, finds none and calls block_domain.
>> 2. block_domain enables interrupts.
>> 3. An interrupt occurs.
>> 4. The interrupt handler sets a flag indicating work to do.
>> 5. wfi is called, putting the domain to sleep, even though there is work to do.
>>
>> Enabling IRQs after block_domain ensures we can't sleep while we have
>> work to do.
>
> Ah, yes.

So, can this patch be applied as-is now?


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:32:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoxJv-0000gz-RR; Thu, 13 Nov 2014 16:32:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoxJt-0000gs-L3
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 16:32:29 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	39/69-18267-C1DD4645; Thu, 13 Nov 2014 16:32:28 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415896345!11211128!1
X-Originating-IP: [209.85.192.47]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15543 invoked from network); 13 Nov 2014 16:32:26 -0000
Received: from mail-qg0-f47.google.com (HELO mail-qg0-f47.google.com)
	(209.85.192.47)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:32:26 -0000
Received: by mail-qg0-f47.google.com with SMTP id j107so10782367qga.34
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 08:32:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Qd42wOkgrjwxol8c8vQR9SQ4pAKm5QSXY9xkvWviL5E=;
	b=NF2Mf1mqJA15OqIucNQPKXNfPw8UoIF+eXyxkojyb7Q1hPRA898RvuakSZUn6Tmhnl
	a4yDtVYeORUfQmN5rjyK5L+qTuS2cjslVcEvYlA28gyCpLroKjsSsCatEUOAjKDWYJ8H
	ZWp9Th3sCXYq0hree/K8XQebu9ATR4Idbkggb/ohLSPCL1XYNp+DPx7MvjlDuzFmYK6Q
	VqbBHA1kf0a6sLAhaGcY1HTrdGxmP+gXIFFQuyN6nfEmzXeVP6nTJYISOStShc752dkk
	QZ0peNCDgUF7pbnjvwODJAC3rLUdL7mNS0VDABPUgOrx7AhPAJqFRH4WD93hR6PsV0UN
	LTyw==
X-Gm-Message-State: ALoCoQlus0h6B4H4fDgHnzLcLFV0eIylu7bS7UKVvUik6UAN1L5zUgGDRr67p1GOjUQYdox/t4WW
MIME-Version: 1.0
X-Received: by 10.140.91.245 with SMTP id z108mr4339160qgd.5.1415896344939;
	Thu, 13 Nov 2014 08:32:24 -0800 (PST)
Received: by 10.229.23.199 with HTTP; Thu, 13 Nov 2014 08:32:24 -0800 (PST)
In-Reply-To: <546383A1.8030604@citrix.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
	<546383A1.8030604@citrix.com>
Date: Thu, 13 Nov 2014 17:32:24 +0100
Message-ID: <CAErYnshgw4ViYGxDR1zFRXWZQt1Dy_2ba0g2W96jrbusojPm2A@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, "Dong,
	Eddie" <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event
	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: multipart/mixed; boundary="===============7922696176287720705=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7922696176287720705==
Content-Type: multipart/alternative; boundary=001a113a8110ae10380507c00ed5

--001a113a8110ae10380507c00ed5
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 12, 2014 at 4:58 PM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 12/11/14 15:31, Tamas K Lengyel wrote:
> > diff --git a/xen/include/public/mem_event.h
> b/xen/include/public/mem_event.h
> > index 599f9e8..c0e9394 100644
> > --- a/xen/include/public/mem_event.h
> > +++ b/xen/include/public/mem_event.h
> > @@ -49,15 +49,19 @@
> >  #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 << 6)
> >
> >  /* Reasons for the memory event request */
> > -#define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */
> > -#define MEM_EVENT_REASON_VIOLATION   1    /* access violation, GFN is
> address */
> > -#define MEM_EVENT_REASON_CR0         2    /* CR0 was hit: gfn is new
> CR0 value, gla is previous */
> > -#define MEM_EVENT_REASON_CR3         3    /* CR3 was hit: gfn is new
> CR3 value, gla is previous */
> > -#define MEM_EVENT_REASON_CR4         4    /* CR4 was hit: gfn is new
> CR4 value, gla is previous */
> > -#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 */
> > -#define MEM_EVENT_REASON_MSR         7    /* MSR was hit: gfn is MSR
> value, gla is MSR address;
> > -                                             does NOT honour
> HVMPME_onchangeonly */
> > +typedef enum {
> > +    MEM_EVENT_REASON_UNKNOWN,              /* Default case */
> > +    MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
> > +    MEM_EVENT_REASON_MEM_SHARING,          /* Memory sharing event */
> > +    MEM_EVENT_REASON_MEM_PAGING,           /* Memory paging event */
> > +    MEM_EVENT_REASON_CR0,                  /* CR0 was updated */
> > +    MEM_EVENT_REASON_CR3,                  /* CR3 was updated */
> > +    MEM_EVENT_REASON_CR4,                  /* CR4 was updated */
> > +    MEM_EVENT_REASON_INT3,                 /* Debug operation executed
> (int3) */
> > +    MEM_EVENT_REASON_SINGLESTEP,           /* Single-step (MTF) */
> > +    MEM_EVENT_REASON_MSR,                  /* An MSR was updated.
> > +                                            * Does NOT honour
> HVMPME_onchangeonly */
> > +} mem_event_reason_t;
>
> Please keep these as defines.  The width of an enum is implementation
> defined, meaning that different compilers are free to interpret the
> width of the above definition differently, which affects the size and
> alignment of mem_event_st below.
>

OK, that makes sense.

Tamas


>
> (It is completely wrong that Xen's ABI/API was ever specified using C,
> rather than a document stating actual data structure widths, but that
> horse has long-since bolted)
>
> ~Andrew
>
>

--001a113a8110ae10380507c00ed5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Nov 12, 2014 at 4:58 PM, 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" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div cl=
ass=3D"HOEnZb"><div class=3D"h5">On 12/11/14 15:31, Tamas K Lengyel wrote:<=
br>
&gt; diff --git a/xen/include/public/mem_event.h b/xen/include/public/mem_e=
vent.h<br>
&gt; index 599f9e8..c0e9394 100644<br>
&gt; --- a/xen/include/public/mem_event.h<br>
&gt; +++ b/xen/include/public/mem_event.h<br>
&gt; @@ -49,15 +49,19 @@<br>
&gt;=A0 #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 &lt;&lt; 6)<br>
&gt;<br>
&gt;=A0 /* Reasons for the memory event request */<br>
&gt; -#define MEM_EVENT_REASON_UNKNOWN=A0 =A0 =A00=A0 =A0 /* typical reason=
 */<br>
&gt; -#define MEM_EVENT_REASON_VIOLATION=A0 =A01=A0 =A0 /* access violation=
, GFN is address */<br>
&gt; -#define MEM_EVENT_REASON_CR0=A0 =A0 =A0 =A0 =A02=A0 =A0 /* CR0 was hi=
t: gfn is new CR0 value, gla is previous */<br>
&gt; -#define MEM_EVENT_REASON_CR3=A0 =A0 =A0 =A0 =A03=A0 =A0 /* CR3 was hi=
t: gfn is new CR3 value, gla is previous */<br>
&gt; -#define MEM_EVENT_REASON_CR4=A0 =A0 =A0 =A0 =A04=A0 =A0 /* CR4 was hi=
t: gfn is new CR4 value, gla is previous */<br>
&gt; -#define MEM_EVENT_REASON_INT3=A0 =A0 =A0 =A0 5=A0 =A0 /* int3 was hit=
: gla/gfn are RIP */<br>
&gt; -#define MEM_EVENT_REASON_SINGLESTEP=A0 6=A0 =A0 /* single step was in=
voked: gla/gfn are RIP */<br>
&gt; -#define MEM_EVENT_REASON_MSR=A0 =A0 =A0 =A0 =A07=A0 =A0 /* MSR was hi=
t: gfn is MSR value, gla is MSR address;<br>
&gt; -=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0does NOT honour HVMPME_onchangeonly */<br>
&gt; +typedef enum {<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_UNKNOWN,=A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Defau=
lt case */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access viola=
tion */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_MEM_SHARING,=A0 =A0 =A0 =A0 =A0 /* Memory sh=
aring event */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_MEM_PAGING,=A0 =A0 =A0 =A0 =A0 =A0/* Memory =
paging event */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_CR0,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* C=
R0 was updated */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_CR3,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* C=
R3 was updated */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_CR4,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* C=
R4 was updated */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_INT3,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* D=
ebug operation executed (int3) */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_SINGLESTEP,=A0 =A0 =A0 =A0 =A0 =A0/* Single-=
step (MTF) */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_MSR,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* A=
n MSR was updated.<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 * Does NOT honour HVMPME_onchangeonly */<br>
&gt; +} mem_event_reason_t;<br>
<br>
</div></div>Please keep these as defines.=A0 The width of an enum is implem=
entation<br>
defined, meaning that different compilers are free to interpret the<br>
width of the above definition differently, which affects the size and<br>
alignment of mem_event_st below.<br></blockquote><div><br></div><div>OK, th=
at makes sense.<br><br>Tamas<br></div><div>=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<br>
(It is completely wrong that Xen&#39;s ABI/API was ever specified using C,<=
br>
rather than a document stating actual data structure widths, but that<br>
horse has long-since bolted)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
~Andrew<br>
<br>
</font></span></blockquote></div><br></div></div>

--001a113a8110ae10380507c00ed5--


--===============7922696176287720705==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7922696176287720705==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 16:32:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoxJv-0000gz-RR; Thu, 13 Nov 2014 16:32:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoxJt-0000gs-L3
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 16:32:29 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	39/69-18267-C1DD4645; Thu, 13 Nov 2014 16:32:28 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415896345!11211128!1
X-Originating-IP: [209.85.192.47]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15543 invoked from network); 13 Nov 2014 16:32:26 -0000
Received: from mail-qg0-f47.google.com (HELO mail-qg0-f47.google.com)
	(209.85.192.47)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:32:26 -0000
Received: by mail-qg0-f47.google.com with SMTP id j107so10782367qga.34
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 08:32:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Qd42wOkgrjwxol8c8vQR9SQ4pAKm5QSXY9xkvWviL5E=;
	b=NF2Mf1mqJA15OqIucNQPKXNfPw8UoIF+eXyxkojyb7Q1hPRA898RvuakSZUn6Tmhnl
	a4yDtVYeORUfQmN5rjyK5L+qTuS2cjslVcEvYlA28gyCpLroKjsSsCatEUOAjKDWYJ8H
	ZWp9Th3sCXYq0hree/K8XQebu9ATR4Idbkggb/ohLSPCL1XYNp+DPx7MvjlDuzFmYK6Q
	VqbBHA1kf0a6sLAhaGcY1HTrdGxmP+gXIFFQuyN6nfEmzXeVP6nTJYISOStShc752dkk
	QZ0peNCDgUF7pbnjvwODJAC3rLUdL7mNS0VDABPUgOrx7AhPAJqFRH4WD93hR6PsV0UN
	LTyw==
X-Gm-Message-State: ALoCoQlus0h6B4H4fDgHnzLcLFV0eIylu7bS7UKVvUik6UAN1L5zUgGDRr67p1GOjUQYdox/t4WW
MIME-Version: 1.0
X-Received: by 10.140.91.245 with SMTP id z108mr4339160qgd.5.1415896344939;
	Thu, 13 Nov 2014 08:32:24 -0800 (PST)
Received: by 10.229.23.199 with HTTP; Thu, 13 Nov 2014 08:32:24 -0800 (PST)
In-Reply-To: <546383A1.8030604@citrix.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
	<546383A1.8030604@citrix.com>
Date: Thu, 13 Nov 2014 17:32:24 +0100
Message-ID: <CAErYnshgw4ViYGxDR1zFRXWZQt1Dy_2ba0g2W96jrbusojPm2A@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, "Dong,
	Eddie" <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event
	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: multipart/mixed; boundary="===============7922696176287720705=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7922696176287720705==
Content-Type: multipart/alternative; boundary=001a113a8110ae10380507c00ed5

--001a113a8110ae10380507c00ed5
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 12, 2014 at 4:58 PM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 12/11/14 15:31, Tamas K Lengyel wrote:
> > diff --git a/xen/include/public/mem_event.h
> b/xen/include/public/mem_event.h
> > index 599f9e8..c0e9394 100644
> > --- a/xen/include/public/mem_event.h
> > +++ b/xen/include/public/mem_event.h
> > @@ -49,15 +49,19 @@
> >  #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 << 6)
> >
> >  /* Reasons for the memory event request */
> > -#define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */
> > -#define MEM_EVENT_REASON_VIOLATION   1    /* access violation, GFN is
> address */
> > -#define MEM_EVENT_REASON_CR0         2    /* CR0 was hit: gfn is new
> CR0 value, gla is previous */
> > -#define MEM_EVENT_REASON_CR3         3    /* CR3 was hit: gfn is new
> CR3 value, gla is previous */
> > -#define MEM_EVENT_REASON_CR4         4    /* CR4 was hit: gfn is new
> CR4 value, gla is previous */
> > -#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 */
> > -#define MEM_EVENT_REASON_MSR         7    /* MSR was hit: gfn is MSR
> value, gla is MSR address;
> > -                                             does NOT honour
> HVMPME_onchangeonly */
> > +typedef enum {
> > +    MEM_EVENT_REASON_UNKNOWN,              /* Default case */
> > +    MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
> > +    MEM_EVENT_REASON_MEM_SHARING,          /* Memory sharing event */
> > +    MEM_EVENT_REASON_MEM_PAGING,           /* Memory paging event */
> > +    MEM_EVENT_REASON_CR0,                  /* CR0 was updated */
> > +    MEM_EVENT_REASON_CR3,                  /* CR3 was updated */
> > +    MEM_EVENT_REASON_CR4,                  /* CR4 was updated */
> > +    MEM_EVENT_REASON_INT3,                 /* Debug operation executed
> (int3) */
> > +    MEM_EVENT_REASON_SINGLESTEP,           /* Single-step (MTF) */
> > +    MEM_EVENT_REASON_MSR,                  /* An MSR was updated.
> > +                                            * Does NOT honour
> HVMPME_onchangeonly */
> > +} mem_event_reason_t;
>
> Please keep these as defines.  The width of an enum is implementation
> defined, meaning that different compilers are free to interpret the
> width of the above definition differently, which affects the size and
> alignment of mem_event_st below.
>

OK, that makes sense.

Tamas


>
> (It is completely wrong that Xen's ABI/API was ever specified using C,
> rather than a document stating actual data structure widths, but that
> horse has long-since bolted)
>
> ~Andrew
>
>

--001a113a8110ae10380507c00ed5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Nov 12, 2014 at 4:58 PM, 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" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div cl=
ass=3D"HOEnZb"><div class=3D"h5">On 12/11/14 15:31, Tamas K Lengyel wrote:<=
br>
&gt; diff --git a/xen/include/public/mem_event.h b/xen/include/public/mem_e=
vent.h<br>
&gt; index 599f9e8..c0e9394 100644<br>
&gt; --- a/xen/include/public/mem_event.h<br>
&gt; +++ b/xen/include/public/mem_event.h<br>
&gt; @@ -49,15 +49,19 @@<br>
&gt;=A0 #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 &lt;&lt; 6)<br>
&gt;<br>
&gt;=A0 /* Reasons for the memory event request */<br>
&gt; -#define MEM_EVENT_REASON_UNKNOWN=A0 =A0 =A00=A0 =A0 /* typical reason=
 */<br>
&gt; -#define MEM_EVENT_REASON_VIOLATION=A0 =A01=A0 =A0 /* access violation=
, GFN is address */<br>
&gt; -#define MEM_EVENT_REASON_CR0=A0 =A0 =A0 =A0 =A02=A0 =A0 /* CR0 was hi=
t: gfn is new CR0 value, gla is previous */<br>
&gt; -#define MEM_EVENT_REASON_CR3=A0 =A0 =A0 =A0 =A03=A0 =A0 /* CR3 was hi=
t: gfn is new CR3 value, gla is previous */<br>
&gt; -#define MEM_EVENT_REASON_CR4=A0 =A0 =A0 =A0 =A04=A0 =A0 /* CR4 was hi=
t: gfn is new CR4 value, gla is previous */<br>
&gt; -#define MEM_EVENT_REASON_INT3=A0 =A0 =A0 =A0 5=A0 =A0 /* int3 was hit=
: gla/gfn are RIP */<br>
&gt; -#define MEM_EVENT_REASON_SINGLESTEP=A0 6=A0 =A0 /* single step was in=
voked: gla/gfn are RIP */<br>
&gt; -#define MEM_EVENT_REASON_MSR=A0 =A0 =A0 =A0 =A07=A0 =A0 /* MSR was hi=
t: gfn is MSR value, gla is MSR address;<br>
&gt; -=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0does NOT honour HVMPME_onchangeonly */<br>
&gt; +typedef enum {<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_UNKNOWN,=A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Defau=
lt case */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access viola=
tion */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_MEM_SHARING,=A0 =A0 =A0 =A0 =A0 /* Memory sh=
aring event */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_MEM_PAGING,=A0 =A0 =A0 =A0 =A0 =A0/* Memory =
paging event */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_CR0,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* C=
R0 was updated */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_CR3,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* C=
R3 was updated */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_CR4,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* C=
R4 was updated */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_INT3,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* D=
ebug operation executed (int3) */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_SINGLESTEP,=A0 =A0 =A0 =A0 =A0 =A0/* Single-=
step (MTF) */<br>
&gt; +=A0 =A0 MEM_EVENT_REASON_MSR,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* A=
n MSR was updated.<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 * Does NOT honour HVMPME_onchangeonly */<br>
&gt; +} mem_event_reason_t;<br>
<br>
</div></div>Please keep these as defines.=A0 The width of an enum is implem=
entation<br>
defined, meaning that different compilers are free to interpret the<br>
width of the above definition differently, which affects the size and<br>
alignment of mem_event_st below.<br></blockquote><div><br></div><div>OK, th=
at makes sense.<br><br>Tamas<br></div><div>=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<br>
(It is completely wrong that Xen&#39;s ABI/API was ever specified using C,<=
br>
rather than a document stating actual data structure widths, but that<br>
horse has long-since bolted)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
~Andrew<br>
<br>
</font></span></blockquote></div><br></div></div>

--001a113a8110ae10380507c00ed5--


--===============7922696176287720705==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7922696176287720705==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 16:37:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoxOG-0000tM-PX; Thu, 13 Nov 2014 16:37:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoxOF-0000tH-II
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 16:36:59 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5D/6D-09842-A2ED4645; Thu, 13 Nov 2014 16:36:58 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415896617!12548827!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3188 invoked from network); 13 Nov 2014 16:36:58 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:36:58 -0000
Received: by mail-qa0-f45.google.com with SMTP id dc16so10365555qab.18
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 08:36:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=0nAgP2a6DarFMqN3r5ajGzdj/EhthMu9JFyyZQHnZzI=;
	b=kywepGj8b1iD0Yq5kGaDvAi35R1+NNMCgM+HGccvSC4dTyGfF7N4F8/keIeCWveWh0
	24P9CAyAhACeUeuHuSbp2Fvd2I7n54zkxdTZ0lHN4Lx50bxGM7A6DvGfDgm5A+StSgXJ
	shw2zUzfIxI/l15/xVkAT2XmW0w33Y0FKesxHxf+WwMvRvJGQMeJTf3StD/S7AAjF/HM
	69c7jGpRi7vK2iCro1jxL43bOJwshuvTyueidbJW+vUaMHeETgs0wp1CoA58cU0ACAbW
	MkoDDkuIX4vySrwO7uDtZiw+IdnnN3A95H29Otf+GU2AqgpNyQ1HqkK5RErCGguUkp96
	DH+g==
X-Gm-Message-State: ALoCoQkk6ITFbqlfA7+l5D1Ql8wd9xyY72BWfYAGsoQqFIZbcIpupjSo+Cj5RgNH7MEFyBxyhbK/
MIME-Version: 1.0
X-Received: by 10.224.80.71 with SMTP id s7mr4152267qak.35.1415896617084; Thu,
	13 Nov 2014 08:36:57 -0800 (PST)
Received: by 10.229.23.199 with HTTP; Thu, 13 Nov 2014 08:36:57 -0800 (PST)
In-Reply-To: <54638141.3010500@citrix.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
Date: Thu, 13 Nov 2014 17:36:57 +0100
Message-ID: <CAErYnsjmT69a6SXMMfTPPYtJTPOsxWpuXVgBEtO7=ig9QLMyXw@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, "Dong,
	Eddie" <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2858101968567595470=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2858101968567595470==
Content-Type: multipart/alternative; boundary=001a11c2c7ece6839b0507c01e4b

--001a11c2c7ece6839b0507c01e4b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 12, 2014 at 4:48 PM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 12/11/14 15:31, Tamas K Lengyel wrote:
> > This patch series aims to clean up the mem_event subsystem within Xen.
> The
> > original use-case for this system was to allow external helper
> applications
> > running in privileged domains to control various memory operations
> performed
> > by Xen. Amongs these were paging, sharing and access control. The
> subsystem
> > has since been extended to also deliver non-memory related events, namely
> > various HVM debugging events (INT3, MTF, MOV-TO-CR). The structures and
> naming
> > of related functions however has not caught up to these new use-cases,
> thus
> > leaving many ambigouities in the code.
> >
> > In this series we convert the mem_event structures to a union of
> sub-structures
> > which clearly define the scope of information that is transmitted via
> the event
> > delivery mechanism. Afterwards, we clean up the naming of the structures
> and
> > related functions to more clearly be in line with their actual
> operations.
> >
> > This PATCH RFC series is also available at:
> > https://github.com/tklengyel/xen/tree/mem_event_cleanup
> >
>
> <snip>
>
> >  xen/include/public/domctl.h         |  44 +--
> >  xen/include/public/hvm/params.h     |   2 +-
> >  xen/include/public/mem_event.h      | 134 -------
> >  xen/include/public/memory.h         |   6 +-
> >  xen/include/public/vm_event.h       | 179 +++++++++
>
> While in principle I think this series is a very good thing, there is a
> problem with editing the pubic header files.
>
> The contents of mem_event.h is not currently hidden behind #ifdef
> __XEN_TOOLS__
>
> As a result, it is strictly speaking part of the VM-visible public
> API/ABI and not permitted to change in a backwards incompatible manor.
>
> Having said that, it is currently only usable by privileged domains, so
> there is an argument to be made for declaring that it should have been
> hidden behind __XEN_TOOLS__ in the first place, making it permittable to
> change.
>
> ~Andrew
>


I agree, I think it's safe to say most users of mem_event.h already made
use of it in conjuction with xenctrl.h which is already behind
__XEN_TOOLS__. Going forward we should probably have this header behind
__XEN_TOOLS__ as well just to be explicit.

Tamas

--001a11c2c7ece6839b0507c01e4b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Nov 12, 2014 at 4:48 PM, 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" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><span class=3D"">On 12/11/14 15:31, Tamas K Lengyel wrote:<br>
&gt; This patch series aims to clean up the mem_event subsystem within Xen.=
 The<br>
&gt; original use-case for this system was to allow external helper applica=
tions<br>
&gt; running in privileged domains to control various memory operations per=
formed<br>
&gt; by Xen. Amongs these were paging, sharing and access control. The subs=
ystem<br>
&gt; has since been extended to also deliver non-memory related events, nam=
ely<br>
&gt; various HVM debugging events (INT3, MTF, MOV-TO-CR). The structures an=
d naming<br>
&gt; of related functions however has not caught up to these new use-cases,=
 thus<br>
&gt; leaving many ambigouities in the code.<br>
&gt;<br>
&gt; In this series we convert the mem_event structures to a union of sub-s=
tructures<br>
&gt; which clearly define the scope of information that is transmitted via =
the event<br>
&gt; delivery mechanism. Afterwards, we clean up the naming of the structur=
es and<br>
&gt; related functions to more clearly be in line with their actual operati=
ons.<br>
&gt;<br>
&gt; This PATCH RFC series is also available at:<br>
&gt; <a href=3D"https://github.com/tklengyel/xen/tree/mem_event_cleanup" ta=
rget=3D"_blank">https://github.com/tklengyel/xen/tree/mem_event_cleanup</a>=
<br>
&gt;<br>
<br>
</span>&lt;snip&gt;<br>
<span class=3D""><br>
&gt;=A0 xen/include/public/domctl.h=A0 =A0 =A0 =A0 =A0|=A0 44 +--<br>
&gt;=A0 xen/include/public/hvm/params.h=A0 =A0 =A0|=A0 =A02 +-<br>
&gt;=A0 xen/include/public/mem_event.h=A0 =A0 =A0 | 134 -------<br>
&gt;=A0 xen/include/public/memory.h=A0 =A0 =A0 =A0 =A0|=A0 =A06 +-<br>
&gt;=A0 xen/include/public/vm_event.h=A0 =A0 =A0 =A0| 179 +++++++++<br>
<br>
</span>While in principle I think this series is a very good thing, there i=
s a<br>
problem with editing the pubic header files.<br>
<br>
The contents of mem_event.h is not currently hidden behind #ifdef<br>
__XEN_TOOLS__<br>
<br>
As a result, it is strictly speaking part of the VM-visible public<br>
API/ABI and not permitted to change in a backwards incompatible manor.<br>
<br>
Having said that, it is currently only usable by privileged domains, so<br>
there is an argument to be made for declaring that it should have been<br>
hidden behind __XEN_TOOLS__ in the first place, making it permittable to<br=
>
change.<br>
<span class=3D""><font color=3D"#888888"><br>
~Andrew<br></font></span></blockquote><div><br><br><div class=3D"gmail_quot=
e">I agree, I think it&#39;s safe to say most users of mem_event.h already =
made use of it in conjuction with xenctrl.h which is already behind __XEN_T=
OOLS__. Going forward we should probably have this header behind __XEN_TOOL=
S__ as well just to be explicit.<br><br></div>Tamas <br></div></div><br></d=
iv></div>

--001a11c2c7ece6839b0507c01e4b--


--===============2858101968567595470==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2858101968567595470==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 16:37:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoxOG-0000tM-PX; Thu, 13 Nov 2014 16:37:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XoxOF-0000tH-II
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 16:36:59 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5D/6D-09842-A2ED4645; Thu, 13 Nov 2014 16:36:58 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415896617!12548827!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3188 invoked from network); 13 Nov 2014 16:36:58 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 16:36:58 -0000
Received: by mail-qa0-f45.google.com with SMTP id dc16so10365555qab.18
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 08:36:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=0nAgP2a6DarFMqN3r5ajGzdj/EhthMu9JFyyZQHnZzI=;
	b=kywepGj8b1iD0Yq5kGaDvAi35R1+NNMCgM+HGccvSC4dTyGfF7N4F8/keIeCWveWh0
	24P9CAyAhACeUeuHuSbp2Fvd2I7n54zkxdTZ0lHN4Lx50bxGM7A6DvGfDgm5A+StSgXJ
	shw2zUzfIxI/l15/xVkAT2XmW0w33Y0FKesxHxf+WwMvRvJGQMeJTf3StD/S7AAjF/HM
	69c7jGpRi7vK2iCro1jxL43bOJwshuvTyueidbJW+vUaMHeETgs0wp1CoA58cU0ACAbW
	MkoDDkuIX4vySrwO7uDtZiw+IdnnN3A95H29Otf+GU2AqgpNyQ1HqkK5RErCGguUkp96
	DH+g==
X-Gm-Message-State: ALoCoQkk6ITFbqlfA7+l5D1Ql8wd9xyY72BWfYAGsoQqFIZbcIpupjSo+Cj5RgNH7MEFyBxyhbK/
MIME-Version: 1.0
X-Received: by 10.224.80.71 with SMTP id s7mr4152267qak.35.1415896617084; Thu,
	13 Nov 2014 08:36:57 -0800 (PST)
Received: by 10.229.23.199 with HTTP; Thu, 13 Nov 2014 08:36:57 -0800 (PST)
In-Reply-To: <54638141.3010500@citrix.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
Date: Thu, 13 Nov 2014 17:36:57 +0100
Message-ID: <CAErYnsjmT69a6SXMMfTPPYtJTPOsxWpuXVgBEtO7=ig9QLMyXw@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, "Dong,
	Eddie" <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2858101968567595470=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2858101968567595470==
Content-Type: multipart/alternative; boundary=001a11c2c7ece6839b0507c01e4b

--001a11c2c7ece6839b0507c01e4b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 12, 2014 at 4:48 PM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 12/11/14 15:31, Tamas K Lengyel wrote:
> > This patch series aims to clean up the mem_event subsystem within Xen.
> The
> > original use-case for this system was to allow external helper
> applications
> > running in privileged domains to control various memory operations
> performed
> > by Xen. Amongs these were paging, sharing and access control. The
> subsystem
> > has since been extended to also deliver non-memory related events, namely
> > various HVM debugging events (INT3, MTF, MOV-TO-CR). The structures and
> naming
> > of related functions however has not caught up to these new use-cases,
> thus
> > leaving many ambigouities in the code.
> >
> > In this series we convert the mem_event structures to a union of
> sub-structures
> > which clearly define the scope of information that is transmitted via
> the event
> > delivery mechanism. Afterwards, we clean up the naming of the structures
> and
> > related functions to more clearly be in line with their actual
> operations.
> >
> > This PATCH RFC series is also available at:
> > https://github.com/tklengyel/xen/tree/mem_event_cleanup
> >
>
> <snip>
>
> >  xen/include/public/domctl.h         |  44 +--
> >  xen/include/public/hvm/params.h     |   2 +-
> >  xen/include/public/mem_event.h      | 134 -------
> >  xen/include/public/memory.h         |   6 +-
> >  xen/include/public/vm_event.h       | 179 +++++++++
>
> While in principle I think this series is a very good thing, there is a
> problem with editing the pubic header files.
>
> The contents of mem_event.h is not currently hidden behind #ifdef
> __XEN_TOOLS__
>
> As a result, it is strictly speaking part of the VM-visible public
> API/ABI and not permitted to change in a backwards incompatible manor.
>
> Having said that, it is currently only usable by privileged domains, so
> there is an argument to be made for declaring that it should have been
> hidden behind __XEN_TOOLS__ in the first place, making it permittable to
> change.
>
> ~Andrew
>


I agree, I think it's safe to say most users of mem_event.h already made
use of it in conjuction with xenctrl.h which is already behind
__XEN_TOOLS__. Going forward we should probably have this header behind
__XEN_TOOLS__ as well just to be explicit.

Tamas

--001a11c2c7ece6839b0507c01e4b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Nov 12, 2014 at 4:48 PM, 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" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><span class=3D"">On 12/11/14 15:31, Tamas K Lengyel wrote:<br>
&gt; This patch series aims to clean up the mem_event subsystem within Xen.=
 The<br>
&gt; original use-case for this system was to allow external helper applica=
tions<br>
&gt; running in privileged domains to control various memory operations per=
formed<br>
&gt; by Xen. Amongs these were paging, sharing and access control. The subs=
ystem<br>
&gt; has since been extended to also deliver non-memory related events, nam=
ely<br>
&gt; various HVM debugging events (INT3, MTF, MOV-TO-CR). The structures an=
d naming<br>
&gt; of related functions however has not caught up to these new use-cases,=
 thus<br>
&gt; leaving many ambigouities in the code.<br>
&gt;<br>
&gt; In this series we convert the mem_event structures to a union of sub-s=
tructures<br>
&gt; which clearly define the scope of information that is transmitted via =
the event<br>
&gt; delivery mechanism. Afterwards, we clean up the naming of the structur=
es and<br>
&gt; related functions to more clearly be in line with their actual operati=
ons.<br>
&gt;<br>
&gt; This PATCH RFC series is also available at:<br>
&gt; <a href=3D"https://github.com/tklengyel/xen/tree/mem_event_cleanup" ta=
rget=3D"_blank">https://github.com/tklengyel/xen/tree/mem_event_cleanup</a>=
<br>
&gt;<br>
<br>
</span>&lt;snip&gt;<br>
<span class=3D""><br>
&gt;=A0 xen/include/public/domctl.h=A0 =A0 =A0 =A0 =A0|=A0 44 +--<br>
&gt;=A0 xen/include/public/hvm/params.h=A0 =A0 =A0|=A0 =A02 +-<br>
&gt;=A0 xen/include/public/mem_event.h=A0 =A0 =A0 | 134 -------<br>
&gt;=A0 xen/include/public/memory.h=A0 =A0 =A0 =A0 =A0|=A0 =A06 +-<br>
&gt;=A0 xen/include/public/vm_event.h=A0 =A0 =A0 =A0| 179 +++++++++<br>
<br>
</span>While in principle I think this series is a very good thing, there i=
s a<br>
problem with editing the pubic header files.<br>
<br>
The contents of mem_event.h is not currently hidden behind #ifdef<br>
__XEN_TOOLS__<br>
<br>
As a result, it is strictly speaking part of the VM-visible public<br>
API/ABI and not permitted to change in a backwards incompatible manor.<br>
<br>
Having said that, it is currently only usable by privileged domains, so<br>
there is an argument to be made for declaring that it should have been<br>
hidden behind __XEN_TOOLS__ in the first place, making it permittable to<br=
>
change.<br>
<span class=3D""><font color=3D"#888888"><br>
~Andrew<br></font></span></blockquote><div><br><br><div class=3D"gmail_quot=
e">I agree, I think it&#39;s safe to say most users of mem_event.h already =
made use of it in conjuction with xenctrl.h which is already behind __XEN_T=
OOLS__. Going forward we should probably have this header behind __XEN_TOOL=
S__ as well just to be explicit.<br><br></div>Tamas <br></div></div><br></d=
iv></div>

--001a11c2c7ece6839b0507c01e4b--


--===============2858101968567595470==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2858101968567595470==--


From xen-devel-bounces@lists.xen.org Thu Nov 13 16:39:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16: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 1XoxQu-00010Y-BQ; Thu, 13 Nov 2014 16:39:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1XoxQs-00010Q-QT
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:39:42 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	2C/21-22777-ECED4645; Thu, 13 Nov 2014 16:39:42 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415896781!11185100!1
X-Originating-IP: [130.233.192.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8405 invoked from network); 13 Nov 2014 16:39:41 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-9.tower-206.messagelabs.com with SMTP;
	13 Nov 2014 16:39:41 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id 6EB54308A94;
	Thu, 13 Nov 2014 18:39:40 +0200 (EET)
Message-ID: <5464DECB.8090001@iki.fi>
Date: Thu, 13 Nov 2014 16:39:39 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: rumpkernel-users@lists.sourceforge.net, 
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk>
In-Reply-To: <20141113154634.GA9560@nodbug.moloch.sk>
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 15:46, Martin Lucina wrote:
>>> Following is the high-level description from the Git commit:
>>
>> Can you also post an example of the usage of your CLI tool?  Actually,
>> can you post a rough description of the entire process that a user would
>> have to follow, i.e. compile, configure, run.
>
> Running "xr" with no parameters gives a nice command reference :-)

Sure, but asking everyone to fetch/build/run a tool and dig into the 
sources to be able to partake in mailing list brainstorming is excessive.

> Anyhow:

Anyhow, your list of steps was helpful.  Thank you.

> Running a webserver:
>
> Get mathopd source from http://mathopd.org/. I used mathopd as it's BSD
> licensed, non-forking and small. To build and run it:

Plus I don't think anyone had tried running mathopd on top of a rump 
kernel before.  It's always good to know that more stuff just works out 
of the box.

> 4. You need filesystem images for a stub /etc and /data. I am using cd9660
> for these as you can portably generate that anywhere you have genisoimage
> (ex mkisofs). (see below)

Just to expand on the need for /etc, libc calls such as getservent() and 
getpwent() access files from /etc and get desperately confused if such 
files don't exist.  The alternative is to modify the application to not 
use such calls or to modify libc to shortcircuit them instead of trying 
to access /etc.  Not sure what is best long-term, but short-term an 
easily available or generatable /etc is probably the best way to fly.

Actually, hmm, there's already an image for /etc available.  I 
understood from irc discussion that you needed slight modifications to 
passwd for mathopd.  In case your changes don't conflict with what's 
already up there, you could just update the existing downloadable /etc 
image:
https://github.com/rumpkernel/rumprun-xen/tree/master/img

Of course we can't generate the content image for others, but 
understanding what files need to go in there is straightforward.

> 5. Assuming you have those, run the following in the mathopd src directory,
> as root:
>
>   # xr run -i -n inet:dhcp -b etc.iso:/etc -b data.iso:/data mathopd -nt -f /etc/mathopd.conf

Did you try running more than one?  You should just be able to run as 
many domU's as you want and serve different content from each by 
altering -b, correct?

>> Is deconfig necessary?  The rump kernel already automatically e.g.
>> unmounts file systems and releases the dhcp lease when it's halted.
>
> It does unmount filesystems (if halted correctly) but afaict it does not do
> rump_pub_etfs_remove() and the dhcp stuff does not destroy the interface.
> This is nitpicking, but if you don't do that then the underlying
> blkfront/netfront does not get "correctly" detached either as you can see
> from "port X still bound!" messages during minios_stop_kernel().

Ok, so it's a quick workaround.  I should fix those in the rump kernel 
now that I'm aware of them.

> Guess so. In my mind there is potentially more the tool can do than just
> run rumprun stacks, for example:
>
>   - manage interaction with the host networking, map host ports to
>     domain:port
>   - generate or otherwise manage filesystem images (eg we could have a
>     custom DNS server)
>   - manage stack naming on the host, this is a bit daft at the moment, eg.
>     if you try to run two copies of mathopd it will fall over due to the Xen
>     domain name not being unique
>
> And so on. Maybe this can be layered into separate tools with the 'rumprun'
> script dealing only with launching. Needs more thought.

Agreed.  But we should still try to get the foreseeable stuff right.

>>> Note that in this initial version, only configuring IPv4 network
>>> interfaces with DHCP is supported, and only using image files with ffs
>>> or cd9660 filesystems for block devices is supported.
>>
>> Would e.g. IPv6 support take longer than it took to write that paragraph ?-)
>
> <taptaptap> ;)

My paragraph was shorter ;)

   - antti

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 16:39:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 16: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 1XoxQu-00010Y-BQ; Thu, 13 Nov 2014 16:39:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1XoxQs-00010Q-QT
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 16:39:42 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	2C/21-22777-ECED4645; Thu, 13 Nov 2014 16:39:42 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415896781!11185100!1
X-Originating-IP: [130.233.192.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8405 invoked from network); 13 Nov 2014 16:39:41 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-9.tower-206.messagelabs.com with SMTP;
	13 Nov 2014 16:39:41 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id 6EB54308A94;
	Thu, 13 Nov 2014 18:39:40 +0200 (EET)
Message-ID: <5464DECB.8090001@iki.fi>
Date: Thu, 13 Nov 2014 16:39:39 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: rumpkernel-users@lists.sourceforge.net, 
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk>
In-Reply-To: <20141113154634.GA9560@nodbug.moloch.sk>
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 15:46, Martin Lucina wrote:
>>> Following is the high-level description from the Git commit:
>>
>> Can you also post an example of the usage of your CLI tool?  Actually,
>> can you post a rough description of the entire process that a user would
>> have to follow, i.e. compile, configure, run.
>
> Running "xr" with no parameters gives a nice command reference :-)

Sure, but asking everyone to fetch/build/run a tool and dig into the 
sources to be able to partake in mailing list brainstorming is excessive.

> Anyhow:

Anyhow, your list of steps was helpful.  Thank you.

> Running a webserver:
>
> Get mathopd source from http://mathopd.org/. I used mathopd as it's BSD
> licensed, non-forking and small. To build and run it:

Plus I don't think anyone had tried running mathopd on top of a rump 
kernel before.  It's always good to know that more stuff just works out 
of the box.

> 4. You need filesystem images for a stub /etc and /data. I am using cd9660
> for these as you can portably generate that anywhere you have genisoimage
> (ex mkisofs). (see below)

Just to expand on the need for /etc, libc calls such as getservent() and 
getpwent() access files from /etc and get desperately confused if such 
files don't exist.  The alternative is to modify the application to not 
use such calls or to modify libc to shortcircuit them instead of trying 
to access /etc.  Not sure what is best long-term, but short-term an 
easily available or generatable /etc is probably the best way to fly.

Actually, hmm, there's already an image for /etc available.  I 
understood from irc discussion that you needed slight modifications to 
passwd for mathopd.  In case your changes don't conflict with what's 
already up there, you could just update the existing downloadable /etc 
image:
https://github.com/rumpkernel/rumprun-xen/tree/master/img

Of course we can't generate the content image for others, but 
understanding what files need to go in there is straightforward.

> 5. Assuming you have those, run the following in the mathopd src directory,
> as root:
>
>   # xr run -i -n inet:dhcp -b etc.iso:/etc -b data.iso:/data mathopd -nt -f /etc/mathopd.conf

Did you try running more than one?  You should just be able to run as 
many domU's as you want and serve different content from each by 
altering -b, correct?

>> Is deconfig necessary?  The rump kernel already automatically e.g.
>> unmounts file systems and releases the dhcp lease when it's halted.
>
> It does unmount filesystems (if halted correctly) but afaict it does not do
> rump_pub_etfs_remove() and the dhcp stuff does not destroy the interface.
> This is nitpicking, but if you don't do that then the underlying
> blkfront/netfront does not get "correctly" detached either as you can see
> from "port X still bound!" messages during minios_stop_kernel().

Ok, so it's a quick workaround.  I should fix those in the rump kernel 
now that I'm aware of them.

> Guess so. In my mind there is potentially more the tool can do than just
> run rumprun stacks, for example:
>
>   - manage interaction with the host networking, map host ports to
>     domain:port
>   - generate or otherwise manage filesystem images (eg we could have a
>     custom DNS server)
>   - manage stack naming on the host, this is a bit daft at the moment, eg.
>     if you try to run two copies of mathopd it will fall over due to the Xen
>     domain name not being unique
>
> And so on. Maybe this can be layered into separate tools with the 'rumprun'
> script dealing only with launching. Needs more thought.

Agreed.  But we should still try to get the foreseeable stuff right.

>>> Note that in this initial version, only configuring IPv4 network
>>> interfaces with DHCP is supported, and only using image files with ffs
>>> or cd9660 filesystems for block devices is supported.
>>
>> Would e.g. IPv6 support take longer than it took to write that paragraph ?-)
>
> <taptaptap> ;)

My paragraph was shorter ;)

   - antti

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 17:09:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17:09:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoxtR-0001nu-15; Thu, 13 Nov 2014 17:09:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <martin@lucina.net>) id 1XoxrW-0001nQ-7W
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 17:07:14 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	49/D1-02702-145E4645; Thu, 13 Nov 2014 17:07:13 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415898432!12398307!1
X-Originating-IP: [62.176.169.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21989 invoked from network); 13 Nov 2014 17:07:12 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 17:07:12 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id D34E518057BA;
	Thu, 13 Nov 2014 18:07:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1415898431;
	bh=Ahit58XqDI6gTSFu3CRh6wgqxo2mgBtaAYvVHKHetng=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=sU2SHhy7MWJSyEflu/LKrAvMdIyxFlTBbchsl8Kbq/zUVu1yAK8kSJmXI1cycuvNj
	2YJzFuK/y6KPQGdPjlUn63WT1opsZ/hzQ23di1ojYrYgeiIRZ75JJ06N1woKbEkV6u
	ANMXI9IHp5k1s/b+axVicHWjeZyrmVRqK4YRiD47qQJ8n+0Poj+vYGTtzwryicbfP5
	PaVwspX15BEXyVwUTHTEbmTBum+8yPIfAXEs835uCS5skiq35nRBz6Yo6ZQ597eN6d
	U+q1nMFoFPJHq+3Kwq9lSnM1lNTxhIxZn+eLf0yqh0mJTxbWiyobDCKhgzUxNC58rE
	omsQBUZaFAWtQ==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id 0442D4C0E2D; Thu, 13 Nov 2014 18:07:26 +0100 (CET)
Date: Thu, 13 Nov 2014 18:07:26 +0100
From: Martin Lucina <martin@lucina.net>
To: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org,
	Ian.Jackson@eu.citrix.com
Message-ID: <20141113170726.GB9560@nodbug.moloch.sk>
Mail-Followup-To: rumpkernel-users@lists.sourceforge.net,
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk> <5464DECB.8090001@iki.fi>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464DECB.8090001@iki.fi>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 13 Nov 2014 17:09:11 +0000
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pooka@iki.fi said:
> Actually, hmm, there's already an image for /etc available.  I 
> understood from irc discussion that you needed slight modifications to 
> passwd for mathopd.  In case your changes don't conflict with what's 
> already up there, you could just update the existing downloadable /etc 
> image:
> https://github.com/rumpkernel/rumprun-xen/tree/master/img

I'll add in a new image rather than touch the current one, so that it can
be cd9660 and read-only rather than ffs. Avoids needing to keep a "clean
image" around in case of crashes while developing. The old one can stay
until we replace the old demo code.

Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer
that it's not supposed to be used as a normal /etc.

This brings up another question; what to do with resolv.conf, for example?

> Did you try running more than one?  You should just be able to run as 
> many domU's as you want and serve different content from each by 
> altering -b, correct?

Yes. In the final demo I will move the mathopd configuration file under
/data, so that would work fine.

However: Xen requires each domU to have a locally-unique name. At the
moment "xr" just uses "rumprun-$APP" which will not be unique for more than
one copy of APP. I will add an option allowing you to override that.

In the long run I'd prefer a scheme similar to what Docker does: If you
don't specify a name then a locally-unique admin-friendly one is generated
for you, eg. (from a test I just ran on my system): boring_hopper,
mad_mcclintock, ...

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 17:09:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17:09:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoxtR-0001nu-15; Thu, 13 Nov 2014 17:09:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <martin@lucina.net>) id 1XoxrW-0001nQ-7W
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 17:07:14 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	49/D1-02702-145E4645; Thu, 13 Nov 2014 17:07:13 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415898432!12398307!1
X-Originating-IP: [62.176.169.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21989 invoked from network); 13 Nov 2014 17:07:12 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 17:07:12 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id D34E518057BA;
	Thu, 13 Nov 2014 18:07:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1415898431;
	bh=Ahit58XqDI6gTSFu3CRh6wgqxo2mgBtaAYvVHKHetng=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=sU2SHhy7MWJSyEflu/LKrAvMdIyxFlTBbchsl8Kbq/zUVu1yAK8kSJmXI1cycuvNj
	2YJzFuK/y6KPQGdPjlUn63WT1opsZ/hzQ23di1ojYrYgeiIRZ75JJ06N1woKbEkV6u
	ANMXI9IHp5k1s/b+axVicHWjeZyrmVRqK4YRiD47qQJ8n+0Poj+vYGTtzwryicbfP5
	PaVwspX15BEXyVwUTHTEbmTBum+8yPIfAXEs835uCS5skiq35nRBz6Yo6ZQ597eN6d
	U+q1nMFoFPJHq+3Kwq9lSnM1lNTxhIxZn+eLf0yqh0mJTxbWiyobDCKhgzUxNC58rE
	omsQBUZaFAWtQ==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id 0442D4C0E2D; Thu, 13 Nov 2014 18:07:26 +0100 (CET)
Date: Thu, 13 Nov 2014 18:07:26 +0100
From: Martin Lucina <martin@lucina.net>
To: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org,
	Ian.Jackson@eu.citrix.com
Message-ID: <20141113170726.GB9560@nodbug.moloch.sk>
Mail-Followup-To: rumpkernel-users@lists.sourceforge.net,
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk> <5464DECB.8090001@iki.fi>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464DECB.8090001@iki.fi>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 13 Nov 2014 17:09:11 +0000
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pooka@iki.fi said:
> Actually, hmm, there's already an image for /etc available.  I 
> understood from irc discussion that you needed slight modifications to 
> passwd for mathopd.  In case your changes don't conflict with what's 
> already up there, you could just update the existing downloadable /etc 
> image:
> https://github.com/rumpkernel/rumprun-xen/tree/master/img

I'll add in a new image rather than touch the current one, so that it can
be cd9660 and read-only rather than ffs. Avoids needing to keep a "clean
image" around in case of crashes while developing. The old one can stay
until we replace the old demo code.

Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer
that it's not supposed to be used as a normal /etc.

This brings up another question; what to do with resolv.conf, for example?

> Did you try running more than one?  You should just be able to run as 
> many domU's as you want and serve different content from each by 
> altering -b, correct?

Yes. In the final demo I will move the mathopd configuration file under
/data, so that would work fine.

However: Xen requires each domU to have a locally-unique name. At the
moment "xr" just uses "rumprun-$APP" which will not be unique for more than
one copy of APP. I will add an option allowing you to override that.

In the long run I'd prefer a scheme similar to what Docker does: If you
don't specify a name then a locally-unique admin-friendly one is generated
for you, eg. (from a test I just ran on my system): boring_hopper,
mad_mcclintock, ...

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 17:21:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17:21:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoy5P-00029I-Ek; Thu, 13 Nov 2014 17:21:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1Xoy5N-000298-UF
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 17:21:34 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C3/50-22737-D98E4645; Thu, 13 Nov 2014 17:21:33 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415899292!11198504!1
X-Originating-IP: [130.233.192.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15933 invoked from network); 13 Nov 2014 17:21:32 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-2.tower-206.messagelabs.com with SMTP;
	13 Nov 2014 17:21:32 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id 88023308B76;
	Thu, 13 Nov 2014 19:21:31 +0200 (EET)
Message-ID: <5464E89A.7000908@iki.fi>
Date: Thu, 13 Nov 2014 17:21:30 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: rumpkernel-users@lists.sourceforge.net, 
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk>
	<5464BB03.7090801@iki.fi>	<20141113154634.GA9560@nodbug.moloch.sk>
	<5464DECB.8090001@iki.fi> <20141113170726.GB9560@nodbug.moloch.sk>
In-Reply-To: <20141113170726.GB9560@nodbug.moloch.sk>
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 17:07, Martin Lucina wrote:
> pooka@iki.fi said:
>> Actually, hmm, there's already an image for /etc available.  I
>> understood from irc discussion that you needed slight modifications to
>> passwd for mathopd.  In case your changes don't conflict with what's
>> already up there, you could just update the existing downloadable /etc
>> image:
>> https://github.com/rumpkernel/rumprun-xen/tree/master/img
>
> I'll add in a new image rather than touch the current one, so that it can
> be cd9660 and read-only rather than ffs. Avoids needing to keep a "clean
> image" around in case of crashes while developing. The old one can stay
> until we replace the old demo code.

Generally speaking, file systems support read-only mounts ...

> Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer
> that it's not supposed to be used as a normal /etc.

I'd prefer it to be completely hidden from the user.  But sure, call it 
stubetc for now.

> This brings up another question; what to do with resolv.conf, for example?

Is resolv.conf an example, i.e. are there other files with similar 
needs?  Or can we figure out how to handle it as a special case?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 17:21:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17:21:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoy5P-00029I-Ek; Thu, 13 Nov 2014 17:21:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1Xoy5N-000298-UF
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 17:21:34 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C3/50-22737-D98E4645; Thu, 13 Nov 2014 17:21:33 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415899292!11198504!1
X-Originating-IP: [130.233.192.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15933 invoked from network); 13 Nov 2014 17:21:32 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-2.tower-206.messagelabs.com with SMTP;
	13 Nov 2014 17:21:32 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id 88023308B76;
	Thu, 13 Nov 2014 19:21:31 +0200 (EET)
Message-ID: <5464E89A.7000908@iki.fi>
Date: Thu, 13 Nov 2014 17:21:30 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: rumpkernel-users@lists.sourceforge.net, 
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk>
	<5464BB03.7090801@iki.fi>	<20141113154634.GA9560@nodbug.moloch.sk>
	<5464DECB.8090001@iki.fi> <20141113170726.GB9560@nodbug.moloch.sk>
In-Reply-To: <20141113170726.GB9560@nodbug.moloch.sk>
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 17:07, Martin Lucina wrote:
> pooka@iki.fi said:
>> Actually, hmm, there's already an image for /etc available.  I
>> understood from irc discussion that you needed slight modifications to
>> passwd for mathopd.  In case your changes don't conflict with what's
>> already up there, you could just update the existing downloadable /etc
>> image:
>> https://github.com/rumpkernel/rumprun-xen/tree/master/img
>
> I'll add in a new image rather than touch the current one, so that it can
> be cd9660 and read-only rather than ffs. Avoids needing to keep a "clean
> image" around in case of crashes while developing. The old one can stay
> until we replace the old demo code.

Generally speaking, file systems support read-only mounts ...

> Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer
> that it's not supposed to be used as a normal /etc.

I'd prefer it to be completely hidden from the user.  But sure, call it 
stubetc for now.

> This brings up another question; what to do with resolv.conf, for example?

Is resolv.conf an example, i.e. are there other files with similar 
needs?  Or can we figure out how to handle it as a special case?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 17:23:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17: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 1Xoy6o-0002N6-Tm; Thu, 13 Nov 2014 17:23:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1Xoy6m-0002N0-QQ
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 17:23:01 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	7E/19-05632-4F8E4645; Thu, 13 Nov 2014 17:23:00 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415899378!11230590!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25944 invoked from network); 13 Nov 2014 17:22:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 17:22:59 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADHMQRE002329
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 17:22:27 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADHMN8Z024771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 17:22:24 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADHMMgX009921; Thu, 13 Nov 2014 17:22:23 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 09:22:22 -0800
Date: Thu, 13 Nov 2014 18:22:17 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Petr Tesarik <ptesarik@suse.cz>
Message-ID: <20141113172217.GD6522@olila.local.net-space.pl>
References: <20120705121635.GA2007@host-192-168-1-59.local.net-space.pl>
	<201207231530.55871.ptesarik@suse.cz>
	<20120723201059.GA1848@host-192-168-1-59.local.net-space.pl>
	<201207241018.35292.ptesarik@suse.cz>
	<20120724135410.GA2230@host-192-168-1-59.local.net-space.pl>
	<20141113165148.4343b45e@hananiah.suse.cz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141113165148.4343b45e@hananiah.suse.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: olaf@aepfle.de, horms@verge.net.au, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] kexec-tools: Read always one vmcoreinfo file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Petr,

On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> Hi all,
>
> this thread got somehow forgotten because of vacations...
> Anyway, read below.
>
> On Tue, 24 Jul 2012 15:54:10 +0200
> Daniel Kiper <daniel.kiper@oracle.com> wrote:
>
> > On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > > Dne Po 23. ??ervence 2012 22:10:59 Daniel Kiper napsal(a):
> > > > Hi Petr,
> > > >
> > > > On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote:
> > > > > Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a):
> > > > > > Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a):
> > > > > > > vmcoreinfo file could exists under /sys/kernel (valid on baremetal
> > > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > > >
> > > > > > Hi Daniel,
> > > > > >
> > > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > > /sys/hypervisor describes the Xen hypervisor (type 'XEN_VMCOREINFO').
> > > > > > If you keep only the hypervisor note, then e.g. makedumpfile won't be
> > > > > > able to use dumplevel greater than 1, nor will it be able to extract
> > > > > > the log buffer.
> > > > >
> > > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > > >
> > > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > > >
> > > > [...]
> > > >
> > > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > > If you discovered any issues with my patch please drop me more details
> > > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > > command lines, config files, logs, etc.). I will be more then happy to
> > > > fix/improve kexec-tools and makedumpfile.
> > >
> > > Hi Daniel,
> > >
> > > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
> >
> > Yep.
> >
> > > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
> >
> > Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> >
> > > I tested with the following combinations:
> > >
> > > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> > >
> > > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > > respectively. All of them work just fine and save both ELF notes into the
> > > dump.
> >
> > Could you test current kexec-tools development version and
> > latest makedumpfile version on latest SLES version?
>
> And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
> kexec-tools 2.0.5, makedumpfile 1.5.6).
>
> In the secondary kernel, makedumpfile complains that VMCOREINFO is not
> stored in /proc/vmcore:
>
> bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
> Switched running mode from cyclic to non-cyclic,
> because the cyclic mode doesn't support Xen.
> /proc/vmcore doesn't contain vmcoreinfo.
> Specify '-x' option or '-i' option.
> Commandline parameter is invalid.
> Try `makedumpfile --help' for more information.
>
> makedumpfile Failed.
>
> Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
> everything works just fine.
>
> > > What do you mean by "invalid physical address"? I'm getting the correct
> > > physical address under Xen. Obviously, it must be translated to machine
> > > addresses if you need them from the secondary kernel.
> >
> > Correct vmcoreinfo address should be established by calling
> > HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
>
> The addresses I get from /sys/kernel/vmcoreinfo and
> from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
> when a non-Xen kernel is used for dumping, everything works as expected.
>
> I am well aware that the Xen implementation in SLES differs
> substantially from mainline, but it seems to me that:
>
>   1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
>      filtering, and
>   2. both sysfs files should report machine addresses, because the current
>      p2m mapping is lost forever when the hypervisor executes the secondary
>      kernel, so physical addresses are pretty useless.
>
> I'm reverting the patch for the SLES distro, but I'd like to reach some
> kind of consensus with the community, too.

This reminds me something. I saw that kind of thing when I was working on
makedumpfile once. I have this issue on my TODO list. However, currently
I am working on EFI and multiboot2 stuff and I am not able to take a
look at it. I will do that after releasing first version of patches.
Probably in the middle of December. Is it OK for you?

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 17:23:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17: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 1Xoy6o-0002N6-Tm; Thu, 13 Nov 2014 17:23:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1Xoy6m-0002N0-QQ
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 17:23:01 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	7E/19-05632-4F8E4645; Thu, 13 Nov 2014 17:23:00 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415899378!11230590!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25944 invoked from network); 13 Nov 2014 17:22:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 17:22:59 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADHMQRE002329
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 17:22:27 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADHMN8Z024771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 17:22:24 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADHMMgX009921; Thu, 13 Nov 2014 17:22:23 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 09:22:22 -0800
Date: Thu, 13 Nov 2014 18:22:17 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Petr Tesarik <ptesarik@suse.cz>
Message-ID: <20141113172217.GD6522@olila.local.net-space.pl>
References: <20120705121635.GA2007@host-192-168-1-59.local.net-space.pl>
	<201207231530.55871.ptesarik@suse.cz>
	<20120723201059.GA1848@host-192-168-1-59.local.net-space.pl>
	<201207241018.35292.ptesarik@suse.cz>
	<20120724135410.GA2230@host-192-168-1-59.local.net-space.pl>
	<20141113165148.4343b45e@hananiah.suse.cz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141113165148.4343b45e@hananiah.suse.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: olaf@aepfle.de, horms@verge.net.au, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] kexec-tools: Read always one vmcoreinfo file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Petr,

On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> Hi all,
>
> this thread got somehow forgotten because of vacations...
> Anyway, read below.
>
> On Tue, 24 Jul 2012 15:54:10 +0200
> Daniel Kiper <daniel.kiper@oracle.com> wrote:
>
> > On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > > Dne Po 23. ??ervence 2012 22:10:59 Daniel Kiper napsal(a):
> > > > Hi Petr,
> > > >
> > > > On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote:
> > > > > Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a):
> > > > > > Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a):
> > > > > > > vmcoreinfo file could exists under /sys/kernel (valid on baremetal
> > > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > > >
> > > > > > Hi Daniel,
> > > > > >
> > > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > > /sys/hypervisor describes the Xen hypervisor (type 'XEN_VMCOREINFO').
> > > > > > If you keep only the hypervisor note, then e.g. makedumpfile won't be
> > > > > > able to use dumplevel greater than 1, nor will it be able to extract
> > > > > > the log buffer.
> > > > >
> > > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > > >
> > > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > > >
> > > > [...]
> > > >
> > > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > > If you discovered any issues with my patch please drop me more details
> > > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > > command lines, config files, logs, etc.). I will be more then happy to
> > > > fix/improve kexec-tools and makedumpfile.
> > >
> > > Hi Daniel,
> > >
> > > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
> >
> > Yep.
> >
> > > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
> >
> > Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> >
> > > I tested with the following combinations:
> > >
> > > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> > >
> > > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > > respectively. All of them work just fine and save both ELF notes into the
> > > dump.
> >
> > Could you test current kexec-tools development version and
> > latest makedumpfile version on latest SLES version?
>
> And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
> kexec-tools 2.0.5, makedumpfile 1.5.6).
>
> In the secondary kernel, makedumpfile complains that VMCOREINFO is not
> stored in /proc/vmcore:
>
> bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
> Switched running mode from cyclic to non-cyclic,
> because the cyclic mode doesn't support Xen.
> /proc/vmcore doesn't contain vmcoreinfo.
> Specify '-x' option or '-i' option.
> Commandline parameter is invalid.
> Try `makedumpfile --help' for more information.
>
> makedumpfile Failed.
>
> Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
> everything works just fine.
>
> > > What do you mean by "invalid physical address"? I'm getting the correct
> > > physical address under Xen. Obviously, it must be translated to machine
> > > addresses if you need them from the secondary kernel.
> >
> > Correct vmcoreinfo address should be established by calling
> > HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
>
> The addresses I get from /sys/kernel/vmcoreinfo and
> from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
> when a non-Xen kernel is used for dumping, everything works as expected.
>
> I am well aware that the Xen implementation in SLES differs
> substantially from mainline, but it seems to me that:
>
>   1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
>      filtering, and
>   2. both sysfs files should report machine addresses, because the current
>      p2m mapping is lost forever when the hypervisor executes the secondary
>      kernel, so physical addresses are pretty useless.
>
> I'm reverting the patch for the SLES distro, but I'd like to reach some
> kind of consensus with the community, too.

This reminds me something. I saw that kind of thing when I was working on
makedumpfile once. I have this issue on my TODO list. However, currently
I am working on EFI and multiboot2 stuff and I am not able to take a
look at it. I will do that after releasing first version of patches.
Probably in the middle of December. Is it OK for you?

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 17:27:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17:27:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoyBC-0002bp-P8; Thu, 13 Nov 2014 17:27:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XoyBC-0002bj-3D
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 17:27:34 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	98/63-28296-50AE4645; Thu, 13 Nov 2014 17:27:33 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415899651!6781306!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27412 invoked from network); 13 Nov 2014 17:27:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 17:27:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="191047836"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 12:27:27 -0500
Received: from perard.uk.xensource.com ([10.80.2.84])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1XoyB4-0005Sj-W4;
	Thu, 13 Nov 2014 17:27:27 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: EDK2 devel <edk2-devel@lists.sourceforge.net>
Date: Thu, 13 Nov 2014 17:27:09 +0000
Message-ID: <1415899632-31802-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1415899632-31802-1-git-send-email-anthony.perard@citrix.com>
References: <1415899632-31802-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Scott Duplichan <scott@notabs.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 1/4] OvmfPkg/XenBusDxe: In XenStore,
	replace type of Len from UINTN to UINT32.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a message to XenStore have a lenght of type UINT32, have
XenStore.c deal only with UINT32 instead of a mixmatch with UINTN.

This patch replaces the type of Len in WRITE_REQUEST and the type of the
argument Len of XenStoreWriteStore and XenStoreReadStore.

This patch should avoid to have type cast were it does not make sense to
have them.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
CC: Xen Devel <xen-devel@lists.xen.org>
---
 OvmfPkg/XenBusDxe/XenStore.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index f176b95..7c272b3 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -69,7 +69,7 @@
 
 typedef struct {
   CONST VOID  *Data;
-  UINTN       Len;
+  UINT32      Len;
 } WRITE_REQUEST;
 
 /* Register callback to watch subtree (node) in the XenStore. */
@@ -456,7 +456,7 @@ STATIC
 XENSTORE_STATUS
 XenStoreWriteStore (
   IN CONST VOID *DataPtr,
-  IN UINTN      Len
+  IN UINT32     Len
   )
 {
   XENSTORE_RING_IDX Cons, Prod;
@@ -535,7 +535,7 @@ STATIC
 XENSTORE_STATUS
 XenStoreReadStore (
   OUT VOID *DataPtr,
-  IN  UINTN Len
+  IN  UINT32 Len
   )
 {
   XENSTORE_RING_IDX Cons, Prod;
@@ -883,7 +883,7 @@ XenStoreSingle (
   WRITE_REQUEST WriteRequest;
 
   WriteRequest.Data = (VOID *) Body;
-  WriteRequest.Len = AsciiStrSize (Body);
+  WriteRequest.Len = (UINT32)AsciiStrSize (Body);
 
   return XenStoreTalkv (Transaction, RequestType, &WriteRequest, 1,
                         LenPtr, Result);
@@ -912,9 +912,9 @@ XenStoreWatch (
   WRITE_REQUEST WriteRequest[2];
 
   WriteRequest[0].Data = (VOID *) Path;
-  WriteRequest[0].Len = AsciiStrSize (Path);
+  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
   WriteRequest[1].Data = (VOID *) Token;
-  WriteRequest[1].Len = AsciiStrSize (Token);
+  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
 
   return XenStoreTalkv (XST_NIL, XS_WATCH, WriteRequest, 2, NULL, NULL);
 }
@@ -938,9 +938,9 @@ XenStoreUnwatch (
   WRITE_REQUEST WriteRequest[2];
 
   WriteRequest[0].Data = (VOID *) Path;
-  WriteRequest[0].Len = AsciiStrSize (Path);
+  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
   WriteRequest[1].Data = (VOID *) Token;
-  WriteRequest[1].Len = AsciiStrSize (Token);
+  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
 
   return XenStoreTalkv (XST_NIL, XS_UNWATCH, WriteRequest, 2, NULL, NULL);
 }
@@ -1245,9 +1245,9 @@ XenStoreWrite (
   Path = XenStoreJoin (DirectoryPath, Node);
 
   WriteRequest[0].Data = (VOID *) Path;
-  WriteRequest[0].Len = AsciiStrSize (Path);
+  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
   WriteRequest[1].Data = (VOID *) Str;
-  WriteRequest[1].Len = AsciiStrLen (Str);
+  WriteRequest[1].Len = (UINT32)AsciiStrLen (Str);
 
   Status = XenStoreTalkv (Transaction, XS_WRITE, WriteRequest, 2, NULL, NULL);
   FreePool (Path);
-- 
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 Nov 13 17:27:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17:27:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoyBC-0002bp-P8; Thu, 13 Nov 2014 17:27:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XoyBC-0002bj-3D
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 17:27:34 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	98/63-28296-50AE4645; Thu, 13 Nov 2014 17:27:33 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415899651!6781306!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27412 invoked from network); 13 Nov 2014 17:27:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 17:27:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,378,1413244800"; d="scan'208";a="191047836"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 12:27:27 -0500
Received: from perard.uk.xensource.com ([10.80.2.84])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1XoyB4-0005Sj-W4;
	Thu, 13 Nov 2014 17:27:27 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: EDK2 devel <edk2-devel@lists.sourceforge.net>
Date: Thu, 13 Nov 2014 17:27:09 +0000
Message-ID: <1415899632-31802-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1415899632-31802-1-git-send-email-anthony.perard@citrix.com>
References: <1415899632-31802-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Scott Duplichan <scott@notabs.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 1/4] OvmfPkg/XenBusDxe: In XenStore,
	replace type of Len from UINTN to UINT32.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a message to XenStore have a lenght of type UINT32, have
XenStore.c deal only with UINT32 instead of a mixmatch with UINTN.

This patch replaces the type of Len in WRITE_REQUEST and the type of the
argument Len of XenStoreWriteStore and XenStoreReadStore.

This patch should avoid to have type cast were it does not make sense to
have them.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
CC: Xen Devel <xen-devel@lists.xen.org>
---
 OvmfPkg/XenBusDxe/XenStore.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index f176b95..7c272b3 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -69,7 +69,7 @@
 
 typedef struct {
   CONST VOID  *Data;
-  UINTN       Len;
+  UINT32      Len;
 } WRITE_REQUEST;
 
 /* Register callback to watch subtree (node) in the XenStore. */
@@ -456,7 +456,7 @@ STATIC
 XENSTORE_STATUS
 XenStoreWriteStore (
   IN CONST VOID *DataPtr,
-  IN UINTN      Len
+  IN UINT32     Len
   )
 {
   XENSTORE_RING_IDX Cons, Prod;
@@ -535,7 +535,7 @@ STATIC
 XENSTORE_STATUS
 XenStoreReadStore (
   OUT VOID *DataPtr,
-  IN  UINTN Len
+  IN  UINT32 Len
   )
 {
   XENSTORE_RING_IDX Cons, Prod;
@@ -883,7 +883,7 @@ XenStoreSingle (
   WRITE_REQUEST WriteRequest;
 
   WriteRequest.Data = (VOID *) Body;
-  WriteRequest.Len = AsciiStrSize (Body);
+  WriteRequest.Len = (UINT32)AsciiStrSize (Body);
 
   return XenStoreTalkv (Transaction, RequestType, &WriteRequest, 1,
                         LenPtr, Result);
@@ -912,9 +912,9 @@ XenStoreWatch (
   WRITE_REQUEST WriteRequest[2];
 
   WriteRequest[0].Data = (VOID *) Path;
-  WriteRequest[0].Len = AsciiStrSize (Path);
+  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
   WriteRequest[1].Data = (VOID *) Token;
-  WriteRequest[1].Len = AsciiStrSize (Token);
+  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
 
   return XenStoreTalkv (XST_NIL, XS_WATCH, WriteRequest, 2, NULL, NULL);
 }
@@ -938,9 +938,9 @@ XenStoreUnwatch (
   WRITE_REQUEST WriteRequest[2];
 
   WriteRequest[0].Data = (VOID *) Path;
-  WriteRequest[0].Len = AsciiStrSize (Path);
+  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
   WriteRequest[1].Data = (VOID *) Token;
-  WriteRequest[1].Len = AsciiStrSize (Token);
+  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
 
   return XenStoreTalkv (XST_NIL, XS_UNWATCH, WriteRequest, 2, NULL, NULL);
 }
@@ -1245,9 +1245,9 @@ XenStoreWrite (
   Path = XenStoreJoin (DirectoryPath, Node);
 
   WriteRequest[0].Data = (VOID *) Path;
-  WriteRequest[0].Len = AsciiStrSize (Path);
+  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
   WriteRequest[1].Data = (VOID *) Str;
-  WriteRequest[1].Len = AsciiStrLen (Str);
+  WriteRequest[1].Len = (UINT32)AsciiStrLen (Str);
 
   Status = XenStoreTalkv (Transaction, XS_WRITE, WriteRequest, 2, NULL, NULL);
   FreePool (Path);
-- 
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 Nov 13 17:36:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17: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.xen.org>)
	id 1XoyK5-0002wh-UE; Thu, 13 Nov 2014 17:36:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XoyK5-0002wc-5g
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 17:36:45 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C0/91-24532-C2CE4645; Thu, 13 Nov 2014 17:36:44 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415900204!12536536!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9427 invoked from network); 13 Nov 2014 17:36:44 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Nov 2014 17:36:44 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XoyK2-0001t6-EL; Thu, 13 Nov 2014 17:36:42 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21604.60458.368633.646285@chiark.greenend.org.uk>
Date: Thu, 13 Nov 2014 17:36:42 +0000
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZZnhUVqunXKxDP_oP53+hc0bXUEUS+kD=RRjFzYOXXk4A@mail.gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
	<CAFLBxZZnhUVqunXKxDP_oP53+hc0bXUEUS+kD=RRjFzYOXXk4A@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Lars Kurth <lars.kurth.xen@gmail.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Security policy ambiguities - XSA-108 process post-mortem"):
> On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson
> <ijackson@chiark.greenend.org.uk> wrote:
> > III. Information-sharing
> > ========================
...
> >   List members are allowed to share fixes to embargoed issues,
> >   analysis, etc., with the security teams of other list members.
> >   Technical measures must be taken to prevents non-list-member
> 
> "to prevents" => either "which prevents" or "to prevent"

Thanks.

> I take it in general the technical measures you envision is pgp / gpg?

No, I don't (honestly) expect anything that sophisticated.  I meant
that eg website downloads ought to be password protected.  We should
give that as an example.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 17:36:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17: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.xen.org>)
	id 1XoyK5-0002wh-UE; Thu, 13 Nov 2014 17:36:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XoyK5-0002wc-5g
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 17:36:45 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C0/91-24532-C2CE4645; Thu, 13 Nov 2014 17:36:44 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415900204!12536536!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9427 invoked from network); 13 Nov 2014 17:36:44 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Nov 2014 17:36:44 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XoyK2-0001t6-EL; Thu, 13 Nov 2014 17:36:42 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21604.60458.368633.646285@chiark.greenend.org.uk>
Date: Thu, 13 Nov 2014 17:36:42 +0000
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZZnhUVqunXKxDP_oP53+hc0bXUEUS+kD=RRjFzYOXXk4A@mail.gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
	<CAFLBxZZnhUVqunXKxDP_oP53+hc0bXUEUS+kD=RRjFzYOXXk4A@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Lars Kurth <lars.kurth.xen@gmail.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Security policy ambiguities - XSA-108 process post-mortem"):
> On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson
> <ijackson@chiark.greenend.org.uk> wrote:
> > III. Information-sharing
> > ========================
...
> >   List members are allowed to share fixes to embargoed issues,
> >   analysis, etc., with the security teams of other list members.
> >   Technical measures must be taken to prevents non-list-member
> 
> "to prevents" => either "which prevents" or "to prevent"

Thanks.

> I take it in general the technical measures you envision is pgp / gpg?

No, I don't (honestly) expect anything that sophisticated.  I meant
that eg website downloads ought to be password protected.  We should
give that as an example.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 17:49:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoyW5-0003H7-6y; Thu, 13 Nov 2014 17:49:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1XoyW3-0003H2-Vj
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 17:49:08 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	7C/08-17735-31FE4645; Thu, 13 Nov 2014 17:49:07 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415900945!11236052!1
X-Originating-IP: [209.85.216.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13626 invoked from network); 13 Nov 2014 17:49:06 -0000
Received: from mail-qc0-f175.google.com (HELO mail-qc0-f175.google.com)
	(209.85.216.175)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 17:49:06 -0000
Received: by mail-qc0-f175.google.com with SMTP id b13so12684172qcw.20
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 09:49:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=nkDlk5cYaEpxHSDCZFqZPTSnuz+fHqlw0MgveAZw5gY=;
	b=Id1WNB6eqxz2DxZzAN8bpFEfRL50T6bRO6KZBwrM32OQZY5qvf3fuJKOTZxJQ7owxW
	xXtL5iwBSLNK+RPfakw3W4LyjmQVTAHJ/PCjO8EoHXmskZijFgDaRtORtTrSvXBhqULN
	p+uPFeF7TLgZdoRua1rJldyrltI06RJd3vf4XEbkqz/YVDKW6iRci+Idxr5CXFYAq4Kb
	sKtRS22MMoXCIHxJufr5S/Eb7dyccXsZityEp1nHhNDb3h+tUzAT9rQ3w02ghH7us7qj
	Uq3FKP9Qum2L+98ad74uUKOaNhdoJ9578VZDT9cvhCAgrRdquga80+elEjT092KFyKbC
	1BDg==
X-Received: by 10.229.181.201 with SMTP id bz9mr4774013qcb.1.1415900945558;
	Thu, 13 Nov 2014 09:49:05 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.161])
	by mx.google.com with ESMTPSA id p13sm15677733qax.8.2014.11.13.09.49.04
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Thu, 13 Nov 2014 09:49:05 -0800 (PST)
Date: Thu, 13 Nov 2014 14:49:07 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <429773295.20141113144907@gmail.com>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5464E1D9020000780004746B@mail.emea.novell.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Hello Jan,

>>
>> Yes,  the  first thing I do in the driver is set the PCI configuration
>> access  bits to 7 that should enable IO space, Memory Space and Master
>> BUS access.
>> 
>> As  a  test I disabled this and all reads to the PCI device return -1,
>> even the first one.

> I implied your earlier statement to mean that. But - did you also
> verify that the three flags actually end up set (ideally from both
> DomU and Dom0 perspective)? The PCI backend may be screwing
> up things...

Yes I do verify the write. How do I check this from Dom0?

>> I  agree,  this looks more than a hang than a crash. I've just found a
>> link to the USB debug cable. I've ordered one but it will take a while

> And I hope you first verified that your system meets the criteria
> for this to work in the first place?

I followed the checks in the Kernel earlyprintk debugging HOWTO, i.e.
lspci -vvv to check the USB debug capability, and it verified. The
device is ordered and now just to wait....


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 17:49:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 17:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoyW5-0003H7-6y; Thu, 13 Nov 2014 17:49:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1XoyW3-0003H2-Vj
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 17:49:08 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	7C/08-17735-31FE4645; Thu, 13 Nov 2014 17:49:07 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1415900945!11236052!1
X-Originating-IP: [209.85.216.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13626 invoked from network); 13 Nov 2014 17:49:06 -0000
Received: from mail-qc0-f175.google.com (HELO mail-qc0-f175.google.com)
	(209.85.216.175)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 17:49:06 -0000
Received: by mail-qc0-f175.google.com with SMTP id b13so12684172qcw.20
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 09:49:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=nkDlk5cYaEpxHSDCZFqZPTSnuz+fHqlw0MgveAZw5gY=;
	b=Id1WNB6eqxz2DxZzAN8bpFEfRL50T6bRO6KZBwrM32OQZY5qvf3fuJKOTZxJQ7owxW
	xXtL5iwBSLNK+RPfakw3W4LyjmQVTAHJ/PCjO8EoHXmskZijFgDaRtORtTrSvXBhqULN
	p+uPFeF7TLgZdoRua1rJldyrltI06RJd3vf4XEbkqz/YVDKW6iRci+Idxr5CXFYAq4Kb
	sKtRS22MMoXCIHxJufr5S/Eb7dyccXsZityEp1nHhNDb3h+tUzAT9rQ3w02ghH7us7qj
	Uq3FKP9Qum2L+98ad74uUKOaNhdoJ9578VZDT9cvhCAgrRdquga80+elEjT092KFyKbC
	1BDg==
X-Received: by 10.229.181.201 with SMTP id bz9mr4774013qcb.1.1415900945558;
	Thu, 13 Nov 2014 09:49:05 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.161])
	by mx.google.com with ESMTPSA id p13sm15677733qax.8.2014.11.13.09.49.04
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Thu, 13 Nov 2014 09:49:05 -0800 (PST)
Date: Thu, 13 Nov 2014 14:49:07 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <429773295.20141113144907@gmail.com>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5464E1D9020000780004746B@mail.emea.novell.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Hello Jan,

>>
>> Yes,  the  first thing I do in the driver is set the PCI configuration
>> access  bits to 7 that should enable IO space, Memory Space and Master
>> BUS access.
>> 
>> As  a  test I disabled this and all reads to the PCI device return -1,
>> even the first one.

> I implied your earlier statement to mean that. But - did you also
> verify that the three flags actually end up set (ideally from both
> DomU and Dom0 perspective)? The PCI backend may be screwing
> up things...

Yes I do verify the write. How do I check this from Dom0?

>> I  agree,  this looks more than a hang than a crash. I've just found a
>> link to the USB debug cable. I've ordered one but it will take a while

> And I hope you first verified that your system meets the criteria
> for this to work in the first place?

I followed the checks in the Kernel earlyprintk debugging HOWTO, i.e.
lspci -vvv to check the USB debug capability, and it verified. The
device is ordered and now just to wait....


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 18:01:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 18:01:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoyi9-0003gA-HW; Thu, 13 Nov 2014 18:01:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xoyi7-0003g5-6A
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 18:01:35 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	F0/93-11581-EF1F4645; Thu, 13 Nov 2014 18:01:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415901691!5806257!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10589 invoked from network); 13 Nov 2014 18:01:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 18:01:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="192510401"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>, <qemu-devel@nongnu.org>
Date: Thu, 13 Nov 2014 18:42:09 +0100
Message-ID: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
MIME-Version: 1.0
Content-Length:10959
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, George Dunlap <george.dunlap@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 for-xen-4.5] xen_disk: fix unmapping of
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyBwYXRjaCBmaXhlcyB0d28gaXNzdWVzIHdpdGggcGVyc2lzdGVudCBncmFudHMgYW5kIHRo
ZSBkaXNrIFBWIGJhY2tlbmQKKFFkaXNrKToKCiAtIEtlZXAgdHJhY2sgb2YgbWVtb3J5IHJlZ2lv
bnMgd2hlcmUgcGVyc2lzdGVudCBncmFudHMgaGF2ZSBiZWVuIG1hcHBlZAogICBzaW5jZSB3ZSBu
ZWVkIHRvIHVubWFwIHRoZW0gYXMgYSB3aG9sZS4gSXQgaXMgbm90IHBvc3NpYmxlIHRvIHVubWFw
IGEKICAgc2luZ2xlIGdyYW50IGlmIGl0IGhhcyBiZWVuIGJhdGNoLW1hcHBlZC4gQSBuZXcgY2hl
Y2sgaGFzIGFsc28gYmVlbiBhZGRlZAogICB0byBtYWtlIHN1cmUgcGVyc2lzdGVudCBncmFudHMg
YXJlIG9ubHkgdXNlZCBpZiB0aGUgd2hvbGUgbWFwcGVkIHJlZ2lvbgogICBjYW4gYmUgcGVyc2lz
dGVudGx5IG1hcHBlZCBpbiB0aGUgYmF0Y2hfbWFwcyBjYXNlLgogLSBVbm1hcCBwZXJzaXN0ZW50
IGdyYW50cyBiZWZvcmUgc3dpdGNoaW5nIHRvIHRoZSBjbG9zZWQgc3RhdGUsIHNvIHRoZQogICBm
cm9udGVuZCBjYW4gYWxzbyBmcmVlIHRoZW0uCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9u
bsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KUmVwb3J0ZWQtYnk6IEdlb3JnZSBEdW5sYXAgPGdl
b3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KQ2M6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFu
by5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+CkNjOiBLZXZpbiBXb2xmIDxrd29sZkByZWRoYXQu
Y29tPgpDYzogU3RlZmFuIEhham5vY3ppIDxzdGVmYW5oYUByZWRoYXQuY29tPgpDYzogR2Vvcmdl
IER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXguY29tPgpDYzogS29ucmFkIFJ6ZXN6dXRl
ayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgotLS0KWGVuIHJlbGVhc2UgZXhjZXB0aW9u
OiB0aGlzIGlzIG9idmlvdXNseSBhbiBpbXBvcnRhbnQgYnVnLWZpeCB0aGF0IHNob3VsZCBiZQpp
bmNsdWRlZCBpbiA0LjUuIFdpdGhvdXQgdGhpcyBmaXgsIHRyeWluZyB0byBkbyBhIGJsb2NrLWRl
dGFjaCBvZiBhIFFkaXNrCmZyb20gYSBydW5uaW5nIGd1ZXN0IGNhbiBsZWFkIHRvIGd1ZXN0IGNy
YXNoIGRlcGVuZGluZyBvbiB0aGUgYmxrZnJvbnQKaW1wbGVtZW50YXRpb24uCi0tLQpDaGFuZ2Vh
IHNpbmNlIHYyOgogLSBFeHBhbmQgdGhlIGNvbW1pdCBtZXNzYWdlIHRvIG1lbnRpb24gdGhlIG5l
d2x5IGFkZGVkIGNoZWNrLgogLSBEb24ndCB1c2UgcGVyc2lzdGVudF9yZWdpb25zIGluIHRoZSAh
YmF0Y2hfbWFwcyBjYXNlLCB3ZSBjYW4gdXNlIHRoZQogICBwcmV2aW91cyBpbXBsZW1lbnRhdGlv
biB3aGljaCB3b3JrcyBmaW5lIGluIHRoYXQgY2FzZS4KCkNoYW5nZXMgc2luY2UgdjE6CiAtIElu
c3RlYWQgb2YgZGlzYWJsaW5nIGJhdGNoIG1hcHBpbmdzIHdoZW4gdXNpbmcgcGVyc2lzdGVudCBn
cmFudHMsIGtlZXAKICAgdHJhY2sgb2YgdGhlIHBlcnNpc3RlbnRseSBtYXBwZWQgcmVnaW9ucyBh
bmQgdW5tYXAgdGhlbSBvbiBkaXNjb25uZWN0aW9uLgogICBUaGlzIHByZXZlbnRzIHVubWFwcGlu
ZyBzaW5nbGUgcGVyc2lzdGVudCBncmFudHMsIGJ1dCB0aGUgY3VycmVudAogICBpbXBsZW1lbnRh
dGlvbiBkb2Vzbid0IHJlcXVpcmUgaXQuCgpUaGlzIG5ldyB2ZXJzaW9uIGlzIHNsaWdodGx5IGZh
c3RlciB0aGFuIHRoZSBwcmV2aW91cyBvbmUsIHRoZSBmb2xsb3dpbmcKdGVzdCByZXN1bHRzIGFy
ZSBpbiBJT1BTIGZyb20gMjAgcnVucyBvZiBhIGJsb2NrLWF0dGFjaCwgZmlvIHJ1biwKYmxvY2st
ZGV0YWNoIHRlc3QgbG9vcDoKCnggYmF0Y2gKKyBub19iYXRjaAorLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKfCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyAgICsgICAgIHggICAgeCArICsg
KyAgeCB4eCB4ICB8CnwrICArICAgICAgICAgICB4ICAgICAgICAgICAgICAgICAgICAgeCsgICor
KysgICAqICAreCogKysreCogIHggeHggeCAqfAp8ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgfF9fX19fX19fX19fX19BX19fX19NX19fX19ffHwKfCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB8X19fX19fX19fX19fX19fX0FfX19fX01fX19fX19fX19fX3wgICAg
ICB8CistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tKwogICAgTiAgICAgICAgICAgTWluICAgICAgICAgICBNYXggICAg
ICAgIE1lZGlhbiAgICAgICAgICAgQXZnICAgICAgICBTdGRkZXYKeCAgMjAgICAgICAgICA1Mjk0
MSAgICAgICAgIDYzODIyICAgICAgICAgNjIzOTYgICAgICA2MTE4MC4xNSAgICAgMjY3My42NDk3
CisgIDIwICAgICAgICAgNDk5NjcgICAgICAgICA2Mzg0OSAgICAgICAgIDYwMzIyICAgICAgIDU5
MTE2LjkgICAgIDM0NTYuMzQ1NQpEaWZmZXJlbmNlIGF0IDk1LjAlIGNvbmZpZGVuY2UKCS0yMDYz
LjI1ICsvLSAxOTc3LjY2CgktMy4zNzI0MiUgKy8tIDMuMjMyNTIlCgkoU3R1ZGVudCdzIHQsIHBv
b2xlZCBzID0gMzA4OS44OCkKLS0tCiBody9ibG9jay94ZW5fZGlzay5jIHwgNzIgKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0KIDEgZmlsZSBjaGFu
Z2VkLCA2NiBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2h3L2Js
b2NrL3hlbl9kaXNrLmMgYi9ody9ibG9jay94ZW5fZGlzay5jCmluZGV4IDIzMWU5YTcuLjIxODQy
YTAgMTAwNjQ0Ci0tLSBhL2h3L2Jsb2NrL3hlbl9kaXNrLmMKKysrIGIvaHcvYmxvY2sveGVuX2Rp
c2suYwpAQCAtNTksNiArNTksMTMgQEAgc3RydWN0IFBlcnNpc3RlbnRHcmFudCB7CiAKIHR5cGVk
ZWYgc3RydWN0IFBlcnNpc3RlbnRHcmFudCBQZXJzaXN0ZW50R3JhbnQ7CiAKK3N0cnVjdCBQZXJz
aXN0ZW50UmVnaW9uIHsKKyAgICB2b2lkICphZGRyOworICAgIGludCBudW07Cit9OworCit0eXBl
ZGVmIHN0cnVjdCBQZXJzaXN0ZW50UmVnaW9uIFBlcnNpc3RlbnRSZWdpb247CisKIHN0cnVjdCBp
b3JlcSB7CiAgICAgYmxraWZfcmVxdWVzdF90ICAgICByZXE7CiAgICAgaW50MTZfdCAgICAgICAg
ICAgICBzdGF0dXM7CkBAIC0xMTgsNiArMTI1LDcgQEAgc3RydWN0IFhlbkJsa0RldiB7CiAgICAg
Z2Jvb2xlYW4gICAgICAgICAgICBmZWF0dXJlX2Rpc2NhcmQ7CiAgICAgZ2Jvb2xlYW4gICAgICAg
ICAgICBmZWF0dXJlX3BlcnNpc3RlbnQ7CiAgICAgR1RyZWUgICAgICAgICAgICAgICAqcGVyc2lz
dGVudF9nbnRzOworICAgIEdTTGlzdCAgICAgICAgICAgICAgKnBlcnNpc3RlbnRfcmVnaW9uczsK
ICAgICB1bnNpZ25lZCBpbnQgICAgICAgIHBlcnNpc3RlbnRfZ250X2NvdW50OwogICAgIHVuc2ln
bmVkIGludCAgICAgICAgbWF4X2dyYW50czsKIApAQCAtMTc3LDYgKzE4NSwyMyBAQCBzdGF0aWMg
dm9pZCBkZXN0cm95X2dyYW50KGdwb2ludGVyIHBnbnQpCiAgICAgZ19mcmVlKGdyYW50KTsKIH0K
IAorc3RhdGljIHZvaWQgcmVtb3ZlX3BlcnNpc3RlbnRfcmVnaW9uKGdwb2ludGVyIGRhdGEsIGdw
b2ludGVyIGRldikKK3sKKyAgICBQZXJzaXN0ZW50UmVnaW9uICpyZWdpb24gPSBkYXRhOworICAg
IHN0cnVjdCBYZW5CbGtEZXYgKmJsa2RldiA9IGRldjsKKyAgICBYZW5HbnR0YWIgZ250ID0gYmxr
ZGV2LT54ZW5kZXYuZ250dGFiZGV2OworCisgICAgaWYgKHhjX2dudHRhYl9tdW5tYXAoZ250LCBy
ZWdpb24tPmFkZHIsIHJlZ2lvbi0+bnVtKSAhPSAwKSB7CisgICAgICAgIHhlbl9iZV9wcmludGYo
JmJsa2Rldi0+eGVuZGV2LCAwLAorICAgICAgICAgICAgICAgICAgICAgICJ4Y19nbnR0YWJfbXVu
bWFwIHJlZ2lvbiAlcCBmYWlsZWQ6ICVzXG4iLAorICAgICAgICAgICAgICAgICAgICAgIHJlZ2lv
bi0+YWRkciwgc3RyZXJyb3IoZXJybm8pKTsKKyAgICB9CisgICAgeGVuX2JlX3ByaW50ZigmYmxr
ZGV2LT54ZW5kZXYsIDMsCisgICAgICAgICAgICAgICAgICAidW5tYXBwZWQgZ3JhbnQgcmVnaW9u
ICVwIHdpdGggJWQgcGFnZXNcbiIsCisgICAgICAgICAgICAgICAgICByZWdpb24tPmFkZHIsIHJl
Z2lvbi0+bnVtKTsKKyAgICBnX2ZyZWUocmVnaW9uKTsKK30KKwogc3RhdGljIHN0cnVjdCBpb3Jl
cSAqaW9yZXFfc3RhcnQoc3RydWN0IFhlbkJsa0RldiAqYmxrZGV2KQogewogICAgIHN0cnVjdCBp
b3JlcSAqaW9yZXEgPSBOVUxMOwpAQCAtMzQzLDYgKzM2OCw3IEBAIHN0YXRpYyBpbnQgaW9yZXFf
bWFwKHN0cnVjdCBpb3JlcSAqaW9yZXEpCiAgICAgdm9pZCAqcGFnZVtCTEtJRl9NQVhfU0VHTUVO
VFNfUEVSX1JFUVVFU1RdOwogICAgIGludCBpLCBqLCBuZXdfbWFwcyA9IDA7CiAgICAgUGVyc2lz
dGVudEdyYW50ICpncmFudDsKKyAgICBQZXJzaXN0ZW50UmVnaW9uICpyZWdpb247CiAgICAgLyog
ZG9taWRzIGFuZCByZWZzIHZhcmlhYmxlcyB3aWxsIGNvbnRhaW4gdGhlIGluZm9ybWF0aW9uIG5l
Y2Vzc2FyeQogICAgICAqIHRvIG1hcCB0aGUgZ3JhbnRzIHRoYXQgYXJlIG5lZWRlZCB0byBmdWxm
aWxsIHRoaXMgcmVxdWVzdC4KICAgICAgKgpAQCAtNDIxLDcgKzQ0NywyMiBAQCBzdGF0aWMgaW50
IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEgKmlvcmVxKQogICAgICAgICAgICAgfQogICAgICAgICB9
CiAgICAgfQotICAgIGlmIChpb3JlcS0+YmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKKyAg
ICBpZiAoaW9yZXEtPmJsa2Rldi0+ZmVhdHVyZV9wZXJzaXN0ZW50ICYmIG5ld19tYXBzICE9IDAg
JiYKKyAgICAgICAgKCFiYXRjaF9tYXBzIHx8IChpb3JlcS0+YmxrZGV2LT5wZXJzaXN0ZW50X2du
dF9jb3VudCArIG5ld19tYXBzIDw9CisgICAgICAgIGlvcmVxLT5ibGtkZXYtPm1heF9ncmFudHMp
KSkgeworICAgICAgICAvKgorICAgICAgICAgKiBJZiB3ZSBhcmUgdXNpbmcgcGVyc2lzdGVudCBn
cmFudHMgYW5kIGJhdGNoIG1hcHBpbmdzIG9ubHkKKyAgICAgICAgICogYWRkIHRoZSBuZXcgbWFw
cyB0byB0aGUgbGlzdCBvZiBwZXJzaXN0ZW50IGdyYW50cyBpZiB0aGUgd2hvbGUKKyAgICAgICAg
ICogYXJlYSBjYW4gYmUgcGVyc2lzdGVudGx5IG1hcHBlZC4KKyAgICAgICAgICovCisgICAgICAg
IGlmIChiYXRjaF9tYXBzKSB7CisgICAgICAgICAgICByZWdpb24gPSBnX21hbGxvYzAoc2l6ZW9m
KCpyZWdpb24pKTsKKyAgICAgICAgICAgIHJlZ2lvbi0+YWRkciA9IGlvcmVxLT5wYWdlczsKKyAg
ICAgICAgICAgIHJlZ2lvbi0+bnVtID0gbmV3X21hcHM7CisgICAgICAgICAgICBpb3JlcS0+Ymxr
ZGV2LT5wZXJzaXN0ZW50X3JlZ2lvbnMgPSBnX3NsaXN0X2FwcGVuZCgKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW9yZXEtPmJsa2Rldi0+cGVyc2lzdGVudF9y
ZWdpb25zLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWdp
b24pOworICAgICAgICB9CiAgICAgICAgIHdoaWxlICgoaW9yZXEtPmJsa2Rldi0+cGVyc2lzdGVu
dF9nbnRfY291bnQgPCBpb3JlcS0+YmxrZGV2LT5tYXhfZ3JhbnRzKQogICAgICAgICAgICAgICAm
JiBuZXdfbWFwcykgewogICAgICAgICAgICAgLyogR28gdGhyb3VnaCB0aGUgbGlzdCBvZiBuZXds
eSBtYXBwZWQgZ3JhbnRzIGFuZCBhZGQgYXMgbWFueQpAQCAtNDQ3LDYgKzQ4OCw3IEBAIHN0YXRp
YyBpbnQgaW9yZXFfbWFwKHN0cnVjdCBpb3JlcSAqaW9yZXEpCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGdyYW50KTsKICAgICAgICAgICAgIGlvcmVxLT5ibGtkZXYtPnBlcnNpc3RlbnRfZ250
X2NvdW50Kys7CiAgICAgICAgIH0KKyAgICAgICAgYXNzZXJ0KCFiYXRjaF9tYXBzIHx8IG5ld19t
YXBzID09IDApOwogICAgIH0KICAgICBmb3IgKGkgPSAwOyBpIDwgaW9yZXEtPnYubmlvdjsgaSsr
KSB7CiAgICAgICAgIGlvcmVxLT52LmlvdltpXS5pb3ZfYmFzZSArPSAodWludHB0cl90KXBhZ2Vb
aV07CkBAIC05NzEsNyArMTAxMywxMCBAQCBzdGF0aWMgaW50IGJsa19jb25uZWN0KHN0cnVjdCBY
ZW5EZXZpY2UgKnhlbmRldikKICAgICAgICAgYmxrZGV2LT5tYXhfZ3JhbnRzID0gbWF4X3JlcXVl
c3RzICogQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUOwogICAgICAgICBibGtkZXYtPnBl
cnNpc3RlbnRfZ250cyA9IGdfdHJlZV9uZXdfZnVsbCgoR0NvbXBhcmVEYXRhRnVuYylpbnRfY21w
LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCwgTlVM
TCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJhdGNoX21h
cHMgPworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKEdEZXN0
cm95Tm90aWZ5KWdfZnJlZSA6CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAoR0Rlc3Ryb3lOb3RpZnkpZGVzdHJveV9ncmFudCk7CisgICAgICAgIGJsa2Rldi0+
cGVyc2lzdGVudF9yZWdpb25zID0gTlVMTDsKICAgICAgICAgYmxrZGV2LT5wZXJzaXN0ZW50X2du
dF9jb3VudCA9IDA7CiAgICAgfQogCkBAIC0xMDAwLDYgKzEwNDUsMjYgQEAgc3RhdGljIHZvaWQg
YmxrX2Rpc2Nvbm5lY3Qoc3RydWN0IFhlbkRldmljZSAqeGVuZGV2KQogICAgICAgICBibGtkZXYt
PmNudF9tYXAtLTsKICAgICAgICAgYmxrZGV2LT5zcmluZyA9IE5VTEw7CiAgICAgfQorCisgICAg
LyoKKyAgICAgKiBVbm1hcCBwZXJzaXN0ZW50IGdyYW50cyBiZWZvcmUgc3dpdGNoaW5nIHRvIHRo
ZSBjbG9zZWQgc3RhdGUKKyAgICAgKiBzbyB0aGUgZnJvbnRlbmQgY2FuIGZyZWUgdGhlbS4KKyAg
ICAgKgorICAgICAqIEluIHRoZSAhYmF0Y2hfbWFwcyBjYXNlIGdfdHJlZV9kZXN0cm95IHdpbGwg
dGFrZSBjYXJlIG9mIHVubWFwcGluZworICAgICAqIHRoZSBncmFudCwgYnV0IGluIHRoZSBiYXRj
aF9tYXBzIGNhc2Ugd2UgbmVlZCB0byBpdGVyYXRlIG92ZXIgZXZlcnkKKyAgICAgKiByZWdpb24g
aW4gcGVyc2lzdGVudF9yZWdpb25zIGFuZCB1bm1hcCBpdC4KKyAgICAgKi8KKyAgICBpZiAoYmxr
ZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKKyAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxrZGV2
LT5wZXJzaXN0ZW50X2dudHMpOworICAgICAgICBhc3NlcnQoYmF0Y2hfbWFwcyB8fCBibGtkZXYt
PnBlcnNpc3RlbnRfZ250X2NvdW50ID09IDApOworICAgICAgICBpZiAoYmF0Y2hfbWFwcykgewor
ICAgICAgICAgICAgYmxrZGV2LT5wZXJzaXN0ZW50X2dudF9jb3VudCA9IDA7CisgICAgICAgICAg
ICBnX3NsaXN0X2ZvcmVhY2goYmxrZGV2LT5wZXJzaXN0ZW50X3JlZ2lvbnMsCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgKEdGdW5jKXJlbW92ZV9wZXJzaXN0ZW50X3JlZ2lvbiwgYmxrZGV2
KTsKKyAgICAgICAgICAgIGdfc2xpc3RfZnJlZShibGtkZXYtPnBlcnNpc3RlbnRfcmVnaW9ucyk7
CisgICAgICAgIH0KKyAgICAgICAgYmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQgPSBmYWxzZTsK
KyAgICB9CiB9CiAKIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhlbkRldmljZSAqeGVuZGV2
KQpAQCAtMTAxMSwxMSArMTA3Niw2IEBAIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhlbkRl
dmljZSAqeGVuZGV2KQogICAgICAgICBibGtfZGlzY29ubmVjdCh4ZW5kZXYpOwogICAgIH0KIAot
ICAgIC8qIEZyZWUgcGVyc2lzdGVudCBncmFudHMgKi8KLSAgICBpZiAoYmxrZGV2LT5mZWF0dXJl
X3BlcnNpc3RlbnQpIHsKLSAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxrZGV2LT5wZXJzaXN0ZW50
X2dudHMpOwotICAgIH0KLQogICAgIHdoaWxlICghUUxJU1RfRU1QVFkoJmJsa2Rldi0+ZnJlZWxp
c3QpKSB7CiAgICAgICAgIGlvcmVxID0gUUxJU1RfRklSU1QoJmJsa2Rldi0+ZnJlZWxpc3QpOwog
ICAgICAgICBRTElTVF9SRU1PVkUoaW9yZXEsIGxpc3QpOwotLSAKMS45LjMgKEFwcGxlIEdpdC01
MCkKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 13 18:01:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 18:01:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoyi9-0003gA-HW; Thu, 13 Nov 2014 18:01:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xoyi7-0003g5-6A
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 18:01:35 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	F0/93-11581-EF1F4645; Thu, 13 Nov 2014 18:01:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415901691!5806257!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10589 invoked from network); 13 Nov 2014 18:01:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 18:01:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="192510401"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>, <qemu-devel@nongnu.org>
Date: Thu, 13 Nov 2014 18:42:09 +0100
Message-ID: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
MIME-Version: 1.0
Content-Length:10959
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, George Dunlap <george.dunlap@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 for-xen-4.5] xen_disk: fix unmapping of
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyBwYXRjaCBmaXhlcyB0d28gaXNzdWVzIHdpdGggcGVyc2lzdGVudCBncmFudHMgYW5kIHRo
ZSBkaXNrIFBWIGJhY2tlbmQKKFFkaXNrKToKCiAtIEtlZXAgdHJhY2sgb2YgbWVtb3J5IHJlZ2lv
bnMgd2hlcmUgcGVyc2lzdGVudCBncmFudHMgaGF2ZSBiZWVuIG1hcHBlZAogICBzaW5jZSB3ZSBu
ZWVkIHRvIHVubWFwIHRoZW0gYXMgYSB3aG9sZS4gSXQgaXMgbm90IHBvc3NpYmxlIHRvIHVubWFw
IGEKICAgc2luZ2xlIGdyYW50IGlmIGl0IGhhcyBiZWVuIGJhdGNoLW1hcHBlZC4gQSBuZXcgY2hl
Y2sgaGFzIGFsc28gYmVlbiBhZGRlZAogICB0byBtYWtlIHN1cmUgcGVyc2lzdGVudCBncmFudHMg
YXJlIG9ubHkgdXNlZCBpZiB0aGUgd2hvbGUgbWFwcGVkIHJlZ2lvbgogICBjYW4gYmUgcGVyc2lz
dGVudGx5IG1hcHBlZCBpbiB0aGUgYmF0Y2hfbWFwcyBjYXNlLgogLSBVbm1hcCBwZXJzaXN0ZW50
IGdyYW50cyBiZWZvcmUgc3dpdGNoaW5nIHRvIHRoZSBjbG9zZWQgc3RhdGUsIHNvIHRoZQogICBm
cm9udGVuZCBjYW4gYWxzbyBmcmVlIHRoZW0uCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9u
bsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KUmVwb3J0ZWQtYnk6IEdlb3JnZSBEdW5sYXAgPGdl
b3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KQ2M6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFu
by5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+CkNjOiBLZXZpbiBXb2xmIDxrd29sZkByZWRoYXQu
Y29tPgpDYzogU3RlZmFuIEhham5vY3ppIDxzdGVmYW5oYUByZWRoYXQuY29tPgpDYzogR2Vvcmdl
IER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXguY29tPgpDYzogS29ucmFkIFJ6ZXN6dXRl
ayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgotLS0KWGVuIHJlbGVhc2UgZXhjZXB0aW9u
OiB0aGlzIGlzIG9idmlvdXNseSBhbiBpbXBvcnRhbnQgYnVnLWZpeCB0aGF0IHNob3VsZCBiZQpp
bmNsdWRlZCBpbiA0LjUuIFdpdGhvdXQgdGhpcyBmaXgsIHRyeWluZyB0byBkbyBhIGJsb2NrLWRl
dGFjaCBvZiBhIFFkaXNrCmZyb20gYSBydW5uaW5nIGd1ZXN0IGNhbiBsZWFkIHRvIGd1ZXN0IGNy
YXNoIGRlcGVuZGluZyBvbiB0aGUgYmxrZnJvbnQKaW1wbGVtZW50YXRpb24uCi0tLQpDaGFuZ2Vh
IHNpbmNlIHYyOgogLSBFeHBhbmQgdGhlIGNvbW1pdCBtZXNzYWdlIHRvIG1lbnRpb24gdGhlIG5l
d2x5IGFkZGVkIGNoZWNrLgogLSBEb24ndCB1c2UgcGVyc2lzdGVudF9yZWdpb25zIGluIHRoZSAh
YmF0Y2hfbWFwcyBjYXNlLCB3ZSBjYW4gdXNlIHRoZQogICBwcmV2aW91cyBpbXBsZW1lbnRhdGlv
biB3aGljaCB3b3JrcyBmaW5lIGluIHRoYXQgY2FzZS4KCkNoYW5nZXMgc2luY2UgdjE6CiAtIElu
c3RlYWQgb2YgZGlzYWJsaW5nIGJhdGNoIG1hcHBpbmdzIHdoZW4gdXNpbmcgcGVyc2lzdGVudCBn
cmFudHMsIGtlZXAKICAgdHJhY2sgb2YgdGhlIHBlcnNpc3RlbnRseSBtYXBwZWQgcmVnaW9ucyBh
bmQgdW5tYXAgdGhlbSBvbiBkaXNjb25uZWN0aW9uLgogICBUaGlzIHByZXZlbnRzIHVubWFwcGlu
ZyBzaW5nbGUgcGVyc2lzdGVudCBncmFudHMsIGJ1dCB0aGUgY3VycmVudAogICBpbXBsZW1lbnRh
dGlvbiBkb2Vzbid0IHJlcXVpcmUgaXQuCgpUaGlzIG5ldyB2ZXJzaW9uIGlzIHNsaWdodGx5IGZh
c3RlciB0aGFuIHRoZSBwcmV2aW91cyBvbmUsIHRoZSBmb2xsb3dpbmcKdGVzdCByZXN1bHRzIGFy
ZSBpbiBJT1BTIGZyb20gMjAgcnVucyBvZiBhIGJsb2NrLWF0dGFjaCwgZmlvIHJ1biwKYmxvY2st
ZGV0YWNoIHRlc3QgbG9vcDoKCnggYmF0Y2gKKyBub19iYXRjaAorLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKfCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyAgICsgICAgIHggICAgeCArICsg
KyAgeCB4eCB4ICB8CnwrICArICAgICAgICAgICB4ICAgICAgICAgICAgICAgICAgICAgeCsgICor
KysgICAqICAreCogKysreCogIHggeHggeCAqfAp8ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgfF9fX19fX19fX19fX19BX19fX19NX19fX19ffHwKfCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB8X19fX19fX19fX19fX19fX0FfX19fX01fX19fX19fX19fX3wgICAg
ICB8CistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tKwogICAgTiAgICAgICAgICAgTWluICAgICAgICAgICBNYXggICAg
ICAgIE1lZGlhbiAgICAgICAgICAgQXZnICAgICAgICBTdGRkZXYKeCAgMjAgICAgICAgICA1Mjk0
MSAgICAgICAgIDYzODIyICAgICAgICAgNjIzOTYgICAgICA2MTE4MC4xNSAgICAgMjY3My42NDk3
CisgIDIwICAgICAgICAgNDk5NjcgICAgICAgICA2Mzg0OSAgICAgICAgIDYwMzIyICAgICAgIDU5
MTE2LjkgICAgIDM0NTYuMzQ1NQpEaWZmZXJlbmNlIGF0IDk1LjAlIGNvbmZpZGVuY2UKCS0yMDYz
LjI1ICsvLSAxOTc3LjY2CgktMy4zNzI0MiUgKy8tIDMuMjMyNTIlCgkoU3R1ZGVudCdzIHQsIHBv
b2xlZCBzID0gMzA4OS44OCkKLS0tCiBody9ibG9jay94ZW5fZGlzay5jIHwgNzIgKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0KIDEgZmlsZSBjaGFu
Z2VkLCA2NiBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2h3L2Js
b2NrL3hlbl9kaXNrLmMgYi9ody9ibG9jay94ZW5fZGlzay5jCmluZGV4IDIzMWU5YTcuLjIxODQy
YTAgMTAwNjQ0Ci0tLSBhL2h3L2Jsb2NrL3hlbl9kaXNrLmMKKysrIGIvaHcvYmxvY2sveGVuX2Rp
c2suYwpAQCAtNTksNiArNTksMTMgQEAgc3RydWN0IFBlcnNpc3RlbnRHcmFudCB7CiAKIHR5cGVk
ZWYgc3RydWN0IFBlcnNpc3RlbnRHcmFudCBQZXJzaXN0ZW50R3JhbnQ7CiAKK3N0cnVjdCBQZXJz
aXN0ZW50UmVnaW9uIHsKKyAgICB2b2lkICphZGRyOworICAgIGludCBudW07Cit9OworCit0eXBl
ZGVmIHN0cnVjdCBQZXJzaXN0ZW50UmVnaW9uIFBlcnNpc3RlbnRSZWdpb247CisKIHN0cnVjdCBp
b3JlcSB7CiAgICAgYmxraWZfcmVxdWVzdF90ICAgICByZXE7CiAgICAgaW50MTZfdCAgICAgICAg
ICAgICBzdGF0dXM7CkBAIC0xMTgsNiArMTI1LDcgQEAgc3RydWN0IFhlbkJsa0RldiB7CiAgICAg
Z2Jvb2xlYW4gICAgICAgICAgICBmZWF0dXJlX2Rpc2NhcmQ7CiAgICAgZ2Jvb2xlYW4gICAgICAg
ICAgICBmZWF0dXJlX3BlcnNpc3RlbnQ7CiAgICAgR1RyZWUgICAgICAgICAgICAgICAqcGVyc2lz
dGVudF9nbnRzOworICAgIEdTTGlzdCAgICAgICAgICAgICAgKnBlcnNpc3RlbnRfcmVnaW9uczsK
ICAgICB1bnNpZ25lZCBpbnQgICAgICAgIHBlcnNpc3RlbnRfZ250X2NvdW50OwogICAgIHVuc2ln
bmVkIGludCAgICAgICAgbWF4X2dyYW50czsKIApAQCAtMTc3LDYgKzE4NSwyMyBAQCBzdGF0aWMg
dm9pZCBkZXN0cm95X2dyYW50KGdwb2ludGVyIHBnbnQpCiAgICAgZ19mcmVlKGdyYW50KTsKIH0K
IAorc3RhdGljIHZvaWQgcmVtb3ZlX3BlcnNpc3RlbnRfcmVnaW9uKGdwb2ludGVyIGRhdGEsIGdw
b2ludGVyIGRldikKK3sKKyAgICBQZXJzaXN0ZW50UmVnaW9uICpyZWdpb24gPSBkYXRhOworICAg
IHN0cnVjdCBYZW5CbGtEZXYgKmJsa2RldiA9IGRldjsKKyAgICBYZW5HbnR0YWIgZ250ID0gYmxr
ZGV2LT54ZW5kZXYuZ250dGFiZGV2OworCisgICAgaWYgKHhjX2dudHRhYl9tdW5tYXAoZ250LCBy
ZWdpb24tPmFkZHIsIHJlZ2lvbi0+bnVtKSAhPSAwKSB7CisgICAgICAgIHhlbl9iZV9wcmludGYo
JmJsa2Rldi0+eGVuZGV2LCAwLAorICAgICAgICAgICAgICAgICAgICAgICJ4Y19nbnR0YWJfbXVu
bWFwIHJlZ2lvbiAlcCBmYWlsZWQ6ICVzXG4iLAorICAgICAgICAgICAgICAgICAgICAgIHJlZ2lv
bi0+YWRkciwgc3RyZXJyb3IoZXJybm8pKTsKKyAgICB9CisgICAgeGVuX2JlX3ByaW50ZigmYmxr
ZGV2LT54ZW5kZXYsIDMsCisgICAgICAgICAgICAgICAgICAidW5tYXBwZWQgZ3JhbnQgcmVnaW9u
ICVwIHdpdGggJWQgcGFnZXNcbiIsCisgICAgICAgICAgICAgICAgICByZWdpb24tPmFkZHIsIHJl
Z2lvbi0+bnVtKTsKKyAgICBnX2ZyZWUocmVnaW9uKTsKK30KKwogc3RhdGljIHN0cnVjdCBpb3Jl
cSAqaW9yZXFfc3RhcnQoc3RydWN0IFhlbkJsa0RldiAqYmxrZGV2KQogewogICAgIHN0cnVjdCBp
b3JlcSAqaW9yZXEgPSBOVUxMOwpAQCAtMzQzLDYgKzM2OCw3IEBAIHN0YXRpYyBpbnQgaW9yZXFf
bWFwKHN0cnVjdCBpb3JlcSAqaW9yZXEpCiAgICAgdm9pZCAqcGFnZVtCTEtJRl9NQVhfU0VHTUVO
VFNfUEVSX1JFUVVFU1RdOwogICAgIGludCBpLCBqLCBuZXdfbWFwcyA9IDA7CiAgICAgUGVyc2lz
dGVudEdyYW50ICpncmFudDsKKyAgICBQZXJzaXN0ZW50UmVnaW9uICpyZWdpb247CiAgICAgLyog
ZG9taWRzIGFuZCByZWZzIHZhcmlhYmxlcyB3aWxsIGNvbnRhaW4gdGhlIGluZm9ybWF0aW9uIG5l
Y2Vzc2FyeQogICAgICAqIHRvIG1hcCB0aGUgZ3JhbnRzIHRoYXQgYXJlIG5lZWRlZCB0byBmdWxm
aWxsIHRoaXMgcmVxdWVzdC4KICAgICAgKgpAQCAtNDIxLDcgKzQ0NywyMiBAQCBzdGF0aWMgaW50
IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEgKmlvcmVxKQogICAgICAgICAgICAgfQogICAgICAgICB9
CiAgICAgfQotICAgIGlmIChpb3JlcS0+YmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKKyAg
ICBpZiAoaW9yZXEtPmJsa2Rldi0+ZmVhdHVyZV9wZXJzaXN0ZW50ICYmIG5ld19tYXBzICE9IDAg
JiYKKyAgICAgICAgKCFiYXRjaF9tYXBzIHx8IChpb3JlcS0+YmxrZGV2LT5wZXJzaXN0ZW50X2du
dF9jb3VudCArIG5ld19tYXBzIDw9CisgICAgICAgIGlvcmVxLT5ibGtkZXYtPm1heF9ncmFudHMp
KSkgeworICAgICAgICAvKgorICAgICAgICAgKiBJZiB3ZSBhcmUgdXNpbmcgcGVyc2lzdGVudCBn
cmFudHMgYW5kIGJhdGNoIG1hcHBpbmdzIG9ubHkKKyAgICAgICAgICogYWRkIHRoZSBuZXcgbWFw
cyB0byB0aGUgbGlzdCBvZiBwZXJzaXN0ZW50IGdyYW50cyBpZiB0aGUgd2hvbGUKKyAgICAgICAg
ICogYXJlYSBjYW4gYmUgcGVyc2lzdGVudGx5IG1hcHBlZC4KKyAgICAgICAgICovCisgICAgICAg
IGlmIChiYXRjaF9tYXBzKSB7CisgICAgICAgICAgICByZWdpb24gPSBnX21hbGxvYzAoc2l6ZW9m
KCpyZWdpb24pKTsKKyAgICAgICAgICAgIHJlZ2lvbi0+YWRkciA9IGlvcmVxLT5wYWdlczsKKyAg
ICAgICAgICAgIHJlZ2lvbi0+bnVtID0gbmV3X21hcHM7CisgICAgICAgICAgICBpb3JlcS0+Ymxr
ZGV2LT5wZXJzaXN0ZW50X3JlZ2lvbnMgPSBnX3NsaXN0X2FwcGVuZCgKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW9yZXEtPmJsa2Rldi0+cGVyc2lzdGVudF9y
ZWdpb25zLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWdp
b24pOworICAgICAgICB9CiAgICAgICAgIHdoaWxlICgoaW9yZXEtPmJsa2Rldi0+cGVyc2lzdGVu
dF9nbnRfY291bnQgPCBpb3JlcS0+YmxrZGV2LT5tYXhfZ3JhbnRzKQogICAgICAgICAgICAgICAm
JiBuZXdfbWFwcykgewogICAgICAgICAgICAgLyogR28gdGhyb3VnaCB0aGUgbGlzdCBvZiBuZXds
eSBtYXBwZWQgZ3JhbnRzIGFuZCBhZGQgYXMgbWFueQpAQCAtNDQ3LDYgKzQ4OCw3IEBAIHN0YXRp
YyBpbnQgaW9yZXFfbWFwKHN0cnVjdCBpb3JlcSAqaW9yZXEpCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGdyYW50KTsKICAgICAgICAgICAgIGlvcmVxLT5ibGtkZXYtPnBlcnNpc3RlbnRfZ250
X2NvdW50Kys7CiAgICAgICAgIH0KKyAgICAgICAgYXNzZXJ0KCFiYXRjaF9tYXBzIHx8IG5ld19t
YXBzID09IDApOwogICAgIH0KICAgICBmb3IgKGkgPSAwOyBpIDwgaW9yZXEtPnYubmlvdjsgaSsr
KSB7CiAgICAgICAgIGlvcmVxLT52LmlvdltpXS5pb3ZfYmFzZSArPSAodWludHB0cl90KXBhZ2Vb
aV07CkBAIC05NzEsNyArMTAxMywxMCBAQCBzdGF0aWMgaW50IGJsa19jb25uZWN0KHN0cnVjdCBY
ZW5EZXZpY2UgKnhlbmRldikKICAgICAgICAgYmxrZGV2LT5tYXhfZ3JhbnRzID0gbWF4X3JlcXVl
c3RzICogQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUOwogICAgICAgICBibGtkZXYtPnBl
cnNpc3RlbnRfZ250cyA9IGdfdHJlZV9uZXdfZnVsbCgoR0NvbXBhcmVEYXRhRnVuYylpbnRfY21w
LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCwgTlVM
TCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJhdGNoX21h
cHMgPworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKEdEZXN0
cm95Tm90aWZ5KWdfZnJlZSA6CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAoR0Rlc3Ryb3lOb3RpZnkpZGVzdHJveV9ncmFudCk7CisgICAgICAgIGJsa2Rldi0+
cGVyc2lzdGVudF9yZWdpb25zID0gTlVMTDsKICAgICAgICAgYmxrZGV2LT5wZXJzaXN0ZW50X2du
dF9jb3VudCA9IDA7CiAgICAgfQogCkBAIC0xMDAwLDYgKzEwNDUsMjYgQEAgc3RhdGljIHZvaWQg
YmxrX2Rpc2Nvbm5lY3Qoc3RydWN0IFhlbkRldmljZSAqeGVuZGV2KQogICAgICAgICBibGtkZXYt
PmNudF9tYXAtLTsKICAgICAgICAgYmxrZGV2LT5zcmluZyA9IE5VTEw7CiAgICAgfQorCisgICAg
LyoKKyAgICAgKiBVbm1hcCBwZXJzaXN0ZW50IGdyYW50cyBiZWZvcmUgc3dpdGNoaW5nIHRvIHRo
ZSBjbG9zZWQgc3RhdGUKKyAgICAgKiBzbyB0aGUgZnJvbnRlbmQgY2FuIGZyZWUgdGhlbS4KKyAg
ICAgKgorICAgICAqIEluIHRoZSAhYmF0Y2hfbWFwcyBjYXNlIGdfdHJlZV9kZXN0cm95IHdpbGwg
dGFrZSBjYXJlIG9mIHVubWFwcGluZworICAgICAqIHRoZSBncmFudCwgYnV0IGluIHRoZSBiYXRj
aF9tYXBzIGNhc2Ugd2UgbmVlZCB0byBpdGVyYXRlIG92ZXIgZXZlcnkKKyAgICAgKiByZWdpb24g
aW4gcGVyc2lzdGVudF9yZWdpb25zIGFuZCB1bm1hcCBpdC4KKyAgICAgKi8KKyAgICBpZiAoYmxr
ZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKKyAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxrZGV2
LT5wZXJzaXN0ZW50X2dudHMpOworICAgICAgICBhc3NlcnQoYmF0Y2hfbWFwcyB8fCBibGtkZXYt
PnBlcnNpc3RlbnRfZ250X2NvdW50ID09IDApOworICAgICAgICBpZiAoYmF0Y2hfbWFwcykgewor
ICAgICAgICAgICAgYmxrZGV2LT5wZXJzaXN0ZW50X2dudF9jb3VudCA9IDA7CisgICAgICAgICAg
ICBnX3NsaXN0X2ZvcmVhY2goYmxrZGV2LT5wZXJzaXN0ZW50X3JlZ2lvbnMsCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgKEdGdW5jKXJlbW92ZV9wZXJzaXN0ZW50X3JlZ2lvbiwgYmxrZGV2
KTsKKyAgICAgICAgICAgIGdfc2xpc3RfZnJlZShibGtkZXYtPnBlcnNpc3RlbnRfcmVnaW9ucyk7
CisgICAgICAgIH0KKyAgICAgICAgYmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQgPSBmYWxzZTsK
KyAgICB9CiB9CiAKIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhlbkRldmljZSAqeGVuZGV2
KQpAQCAtMTAxMSwxMSArMTA3Niw2IEBAIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhlbkRl
dmljZSAqeGVuZGV2KQogICAgICAgICBibGtfZGlzY29ubmVjdCh4ZW5kZXYpOwogICAgIH0KIAot
ICAgIC8qIEZyZWUgcGVyc2lzdGVudCBncmFudHMgKi8KLSAgICBpZiAoYmxrZGV2LT5mZWF0dXJl
X3BlcnNpc3RlbnQpIHsKLSAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxrZGV2LT5wZXJzaXN0ZW50
X2dudHMpOwotICAgIH0KLQogICAgIHdoaWxlICghUUxJU1RfRU1QVFkoJmJsa2Rldi0+ZnJlZWxp
c3QpKSB7CiAgICAgICAgIGlvcmVxID0gUUxJU1RfRklSU1QoJmJsa2Rldi0+ZnJlZWxpc3QpOwog
ICAgICAgICBRTElTVF9SRU1PVkUoaW9yZXEsIGxpc3QpOwotLSAKMS45LjMgKEFwcGxlIEdpdC01
MCkKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 13 18:15:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 18:15:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoyv0-0004CG-Sh; Thu, 13 Nov 2014 18:14:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ptesarik@suse.cz>) id 1Xoyuz-0004CB-Px
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 18:14:53 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	22/E1-02698-D15F4645; Thu, 13 Nov 2014 18:14:53 +0000
X-Env-Sender: ptesarik@suse.cz
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415902491!12400676!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15840 invoked from network); 13 Nov 2014 18:14:52 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 18:14:52 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 1767BAC9F;
	Thu, 13 Nov 2014 18:14:51 +0000 (UTC)
Date: Thu, 13 Nov 2014 19:14:49 +0100
From: Petr Tesarik <ptesarik@suse.cz>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20141113191449.298157d5@hananiah.suse.cz>
In-Reply-To: <20141113172217.GD6522@olila.local.net-space.pl>
References: <20120705121635.GA2007@host-192-168-1-59.local.net-space.pl>
	<201207231530.55871.ptesarik@suse.cz>
	<20120723201059.GA1848@host-192-168-1-59.local.net-space.pl>
	<201207241018.35292.ptesarik@suse.cz>
	<20120724135410.GA2230@host-192-168-1-59.local.net-space.pl>
	<20141113165148.4343b45e@hananiah.suse.cz>
	<20141113172217.GD6522@olila.local.net-space.pl>
Organization: SUSE Linux, s.r.o.
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-suse-linux-gnu)
MIME-Version: 1.0
Cc: olaf@aepfle.de, horms@verge.net.au, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] kexec-tools: Read always one vmcoreinfo file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Nov 2014 18:22:17 +0100
Daniel Kiper <daniel.kiper@oracle.com> wrote:

> Hi Petr,
> 
> On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> > Hi all,
> >
> > this thread got somehow forgotten because of vacations...
> > Anyway, read below.
> >
> > On Tue, 24 Jul 2012 15:54:10 +0200
> > Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >
> > > On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > > > Dne Po 23. ??ervence 2012 22:10:59 Daniel Kiper napsal(a):
> > > > > Hi Petr,
> > > > >
> > > > > On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote:
> > > > > > Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a):
> > > > > > > Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a):
> > > > > > > > vmcoreinfo file could exists under /sys/kernel (valid on baremetal
> > > > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > > > >
> > > > > > > Hi Daniel,
> > > > > > >
> > > > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > > > /sys/hypervisor describes the Xen hypervisor (type 'XEN_VMCOREINFO').
> > > > > > > If you keep only the hypervisor note, then e.g. makedumpfile won't be
> > > > > > > able to use dumplevel greater than 1, nor will it be able to extract
> > > > > > > the log buffer.
> > > > > >
> > > > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > > > >
> > > > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > > > >
> > > > > [...]
> > > > >
> > > > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > > > If you discovered any issues with my patch please drop me more details
> > > > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > > > command lines, config files, logs, etc.). I will be more then happy to
> > > > > fix/improve kexec-tools and makedumpfile.
> > > >
> > > > Hi Daniel,
> > > >
> > > > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > > > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
> > >
> > > Yep.
> > >
> > > > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
> > >
> > > Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> > >
> > > > I tested with the following combinations:
> > > >
> > > > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> > > >
> > > > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > > > respectively. All of them work just fine and save both ELF notes into the
> > > > dump.
> > >
> > > Could you test current kexec-tools development version and
> > > latest makedumpfile version on latest SLES version?
> >
> > And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
> > kexec-tools 2.0.5, makedumpfile 1.5.6).
> >
> > In the secondary kernel, makedumpfile complains that VMCOREINFO is not
> > stored in /proc/vmcore:
> >
> > bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
> > Switched running mode from cyclic to non-cyclic,
> > because the cyclic mode doesn't support Xen.
> > /proc/vmcore doesn't contain vmcoreinfo.
> > Specify '-x' option or '-i' option.
> > Commandline parameter is invalid.
> > Try `makedumpfile --help' for more information.
> >
> > makedumpfile Failed.
> >
> > Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
> > everything works just fine.
> >
> > > > What do you mean by "invalid physical address"? I'm getting the correct
> > > > physical address under Xen. Obviously, it must be translated to machine
> > > > addresses if you need them from the secondary kernel.
> > >
> > > Correct vmcoreinfo address should be established by calling
> > > HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
> >
> > The addresses I get from /sys/kernel/vmcoreinfo and
> > from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
> > when a non-Xen kernel is used for dumping, everything works as expected.
> >
> > I am well aware that the Xen implementation in SLES differs
> > substantially from mainline, but it seems to me that:
> >
> >   1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
> >      filtering, and
> >   2. both sysfs files should report machine addresses, because the current
> >      p2m mapping is lost forever when the hypervisor executes the secondary
> >      kernel, so physical addresses are pretty useless.
> >
> > I'm reverting the patch for the SLES distro, but I'd like to reach some
> > kind of consensus with the community, too.
> 
> This reminds me something. I saw that kind of thing when I was working on
> makedumpfile once. I have this issue on my TODO list. However, currently
> I am working on EFI and multiboot2 stuff and I am not able to take a
> look at it. I will do that after releasing first version of patches.
> Probably in the middle of December. Is it OK for you?

Since this issue has waited two years now, I think it can also wait
another month or two. ;-)

Thanks,
Petr T

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 18:15:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 18:15:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xoyv0-0004CG-Sh; Thu, 13 Nov 2014 18:14:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ptesarik@suse.cz>) id 1Xoyuz-0004CB-Px
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 18:14:53 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	22/E1-02698-D15F4645; Thu, 13 Nov 2014 18:14:53 +0000
X-Env-Sender: ptesarik@suse.cz
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415902491!12400676!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15840 invoked from network); 13 Nov 2014 18:14:52 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 18:14:52 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 1767BAC9F;
	Thu, 13 Nov 2014 18:14:51 +0000 (UTC)
Date: Thu, 13 Nov 2014 19:14:49 +0100
From: Petr Tesarik <ptesarik@suse.cz>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20141113191449.298157d5@hananiah.suse.cz>
In-Reply-To: <20141113172217.GD6522@olila.local.net-space.pl>
References: <20120705121635.GA2007@host-192-168-1-59.local.net-space.pl>
	<201207231530.55871.ptesarik@suse.cz>
	<20120723201059.GA1848@host-192-168-1-59.local.net-space.pl>
	<201207241018.35292.ptesarik@suse.cz>
	<20120724135410.GA2230@host-192-168-1-59.local.net-space.pl>
	<20141113165148.4343b45e@hananiah.suse.cz>
	<20141113172217.GD6522@olila.local.net-space.pl>
Organization: SUSE Linux, s.r.o.
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-suse-linux-gnu)
MIME-Version: 1.0
Cc: olaf@aepfle.de, horms@verge.net.au, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] kexec-tools: Read always one vmcoreinfo file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Nov 2014 18:22:17 +0100
Daniel Kiper <daniel.kiper@oracle.com> wrote:

> Hi Petr,
> 
> On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> > Hi all,
> >
> > this thread got somehow forgotten because of vacations...
> > Anyway, read below.
> >
> > On Tue, 24 Jul 2012 15:54:10 +0200
> > Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >
> > > On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > > > Dne Po 23. ??ervence 2012 22:10:59 Daniel Kiper napsal(a):
> > > > > Hi Petr,
> > > > >
> > > > > On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote:
> > > > > > Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a):
> > > > > > > Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a):
> > > > > > > > vmcoreinfo file could exists under /sys/kernel (valid on baremetal
> > > > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > > > >
> > > > > > > Hi Daniel,
> > > > > > >
> > > > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > > > /sys/hypervisor describes the Xen hypervisor (type 'XEN_VMCOREINFO').
> > > > > > > If you keep only the hypervisor note, then e.g. makedumpfile won't be
> > > > > > > able to use dumplevel greater than 1, nor will it be able to extract
> > > > > > > the log buffer.
> > > > > >
> > > > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > > > >
> > > > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > > > >
> > > > > [...]
> > > > >
> > > > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > > > If you discovered any issues with my patch please drop me more details
> > > > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > > > command lines, config files, logs, etc.). I will be more then happy to
> > > > > fix/improve kexec-tools and makedumpfile.
> > > >
> > > > Hi Daniel,
> > > >
> > > > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > > > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
> > >
> > > Yep.
> > >
> > > > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
> > >
> > > Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> > >
> > > > I tested with the following combinations:
> > > >
> > > > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> > > >
> > > > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > > > respectively. All of them work just fine and save both ELF notes into the
> > > > dump.
> > >
> > > Could you test current kexec-tools development version and
> > > latest makedumpfile version on latest SLES version?
> >
> > And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
> > kexec-tools 2.0.5, makedumpfile 1.5.6).
> >
> > In the secondary kernel, makedumpfile complains that VMCOREINFO is not
> > stored in /proc/vmcore:
> >
> > bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
> > Switched running mode from cyclic to non-cyclic,
> > because the cyclic mode doesn't support Xen.
> > /proc/vmcore doesn't contain vmcoreinfo.
> > Specify '-x' option or '-i' option.
> > Commandline parameter is invalid.
> > Try `makedumpfile --help' for more information.
> >
> > makedumpfile Failed.
> >
> > Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
> > everything works just fine.
> >
> > > > What do you mean by "invalid physical address"? I'm getting the correct
> > > > physical address under Xen. Obviously, it must be translated to machine
> > > > addresses if you need them from the secondary kernel.
> > >
> > > Correct vmcoreinfo address should be established by calling
> > > HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
> >
> > The addresses I get from /sys/kernel/vmcoreinfo and
> > from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
> > when a non-Xen kernel is used for dumping, everything works as expected.
> >
> > I am well aware that the Xen implementation in SLES differs
> > substantially from mainline, but it seems to me that:
> >
> >   1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
> >      filtering, and
> >   2. both sysfs files should report machine addresses, because the current
> >      p2m mapping is lost forever when the hypervisor executes the secondary
> >      kernel, so physical addresses are pretty useless.
> >
> > I'm reverting the patch for the SLES distro, but I'd like to reach some
> > kind of consensus with the community, too.
> 
> This reminds me something. I saw that kind of thing when I was working on
> makedumpfile once. I have this issue on my TODO list. However, currently
> I am working on EFI and multiboot2 stuff and I am not able to take a
> look at it. I will do that after releasing first version of patches.
> Probably in the middle of December. Is it OK for you?

Since this issue has waited two years now, I think it can also wait
another month or two. ;-)

Thanks,
Petr T

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 18:26:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 18: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 1Xoz5a-0004Yn-7y; Thu, 13 Nov 2014 18:25:50 +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 1Xoz5Z-0004Yi-4F
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 18:25:49 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B6/86-02696-CA7F4645; Thu, 13 Nov 2014 18:25:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415903146!12398316!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1478 invoked from network); 13 Nov 2014 18:25:47 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 18:25:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADIPZvf022634
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 18:25:36 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sADIPYgX004913
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Nov 2014 18:25:34 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sADIPXv8004834; Thu, 13 Nov 2014 18:25:33 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 10:25:32 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2BBEF115F43; Thu, 13 Nov 2014 13:25:32 -0500 (EST)
Date: Thu, 13 Nov 2014 13:25:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141113182532.GA10264@laptop.dumpdata.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<20141112171832.GB32634@laptop.dumpdata.com>
	<20141112172839.GA4309@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112172839.GA4309@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print
 partial config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 05:28:39PM +0000, Wei Liu wrote:
> On Wed, Nov 12, 2014 at 12:18:32PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 12, 2014 at 05:04:23PM +0000, Wei Liu wrote:
> > > This small series change the behavior of libxl_retrieve_domain_configuration,
> > > to make it continue to retrieve information from xenstore even if JSON template
> > > is not available.
> > > 
> > > This change of API behaviour is only internal. Conceptually speaking, any
> > > non-zero return value means d_config is partially filled. The chanage just
> > > makes it fill in more information (xenstore entries) than before (empty).
> > > Caller can still expect zero on success and non-zero on error and act
> > > accordingly.
> > 
> > What are the work-arounds (if any) if this does not go in Xen 4.5?
> > 
> 
> The first patch to libxl doesn't change external visible behaviour, that
> is, 0 on success, non-zero on error. So whether it goes in or not I
> don't have very strong opinion. Keep in mind that this API is new so
> this first patch wouldn't cause regression in any way.
> 
> For the inconsistency between short and long output, no workaround, but
> it wouldn't be disastrous.

They look both pretty innocuous so Release-Acked-by: Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>

Thank you.
> 
> Wei.
> 
> > > 
> > > "xl list -l" is now changed to print out the partial configuration, since it
> > > needs to be consistent with the short output.
> > > 
> > > Wei.
> > > 
> > > Wei Liu (2):
> > >   libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
> > >   xl: print out partial configuration in long mode of list command
> > > 
> > >  tools/libxl/libxl.c      |    6 +++++-
> > >  tools/libxl/xl_cmdimpl.c |    6 ++----
> > >  2 files changed, 7 insertions(+), 5 deletions(-)
> > > 
> > > -- 
> > > 1.7.10.4
> > > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 18:26:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 18: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 1Xoz5a-0004Yn-7y; Thu, 13 Nov 2014 18:25:50 +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 1Xoz5Z-0004Yi-4F
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 18:25:49 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B6/86-02696-CA7F4645; Thu, 13 Nov 2014 18:25:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415903146!12398316!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1478 invoked from network); 13 Nov 2014 18:25:47 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 18:25:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADIPZvf022634
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 18:25:36 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sADIPYgX004913
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Nov 2014 18:25:34 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sADIPXv8004834; Thu, 13 Nov 2014 18:25:33 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 10:25:32 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2BBEF115F43; Thu, 13 Nov 2014 13:25:32 -0500 (EST)
Date: Thu, 13 Nov 2014 13:25:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141113182532.GA10264@laptop.dumpdata.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<20141112171832.GB32634@laptop.dumpdata.com>
	<20141112172839.GA4309@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141112172839.GA4309@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 0/2] xl/libxl: return and print
 partial config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 05:28:39PM +0000, Wei Liu wrote:
> On Wed, Nov 12, 2014 at 12:18:32PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 12, 2014 at 05:04:23PM +0000, Wei Liu wrote:
> > > This small series change the behavior of libxl_retrieve_domain_configuration,
> > > to make it continue to retrieve information from xenstore even if JSON template
> > > is not available.
> > > 
> > > This change of API behaviour is only internal. Conceptually speaking, any
> > > non-zero return value means d_config is partially filled. The chanage just
> > > makes it fill in more information (xenstore entries) than before (empty).
> > > Caller can still expect zero on success and non-zero on error and act
> > > accordingly.
> > 
> > What are the work-arounds (if any) if this does not go in Xen 4.5?
> > 
> 
> The first patch to libxl doesn't change external visible behaviour, that
> is, 0 on success, non-zero on error. So whether it goes in or not I
> don't have very strong opinion. Keep in mind that this API is new so
> this first patch wouldn't cause regression in any way.
> 
> For the inconsistency between short and long output, no workaround, but
> it wouldn't be disastrous.

They look both pretty innocuous so Release-Acked-by: Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>

Thank you.
> 
> Wei.
> 
> > > 
> > > "xl list -l" is now changed to print out the partial configuration, since it
> > > needs to be consistent with the short output.
> > > 
> > > Wei.
> > > 
> > > Wei Liu (2):
> > >   libxl: continue when encounter ERROR_JSON_CONFIG_EMPTY
> > >   xl: print out partial configuration in long mode of list command
> > > 
> > >  tools/libxl/libxl.c      |    6 +++++-
> > >  tools/libxl/xl_cmdimpl.c |    6 ++----
> > >  2 files changed, 7 insertions(+), 5 deletions(-)
> > > 
> > > -- 
> > > 1.7.10.4
> > > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 18:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 18:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XozaF-0005IR-VH; Thu, 13 Nov 2014 18:57:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <martin@lucina.net>) id 1XozaE-0005IM-HN
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 18:57:30 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	80/0A-09284-91FF4645; Thu, 13 Nov 2014 18:57:29 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415905048!11199572!1
X-Originating-IP: [62.176.169.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26462 invoked from network); 13 Nov 2014 18:57:28 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 18:57:28 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id D6F3C18057BA;
	Thu, 13 Nov 2014 19:57:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1415905047;
	bh=N7MGlNrN5vx4lyMcglmyVRl185OmcOAvm9K8LiU2sPw=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=S/Xe2sGAjDJWh4rylblYa67QV9AXL3yfLy6LNxiJ0wxI9u/gjQ9AwxDQ0Nrfn/QaW
	F/DUJ/2aB6Q2E2EDSWa4u2RXN7ktBa3TBD6uDNE8g8IGFMLh8YDTa+sLB+pYhR3/Ew
	t4NVQUVOJZ5mIYrdeQp5qVqWhmrueULeGy6dapkO8aqbuF5ohjE51WhvaTARX9lCtJ
	vIeRRLoewJqqKKGqJKa69QlJoLqGUz0fAm2hXut/OgrnCKy4tthTh74rGxUUF2cfUa
	OuL3WvzW3iwUr4CR/8rFngDjhhZtD97GGDYN1eP2E40i1xt6JDtsTk4r+U4gre3GJB
	AVrfy4Od9HtFA==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id D47F94C0E2D; Thu, 13 Nov 2014 19:57:42 +0100 (CET)
Date: Thu, 13 Nov 2014 19:57:42 +0100
From: Martin Lucina <martin@lucina.net>
To: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org,
	Ian.Jackson@eu.citrix.com
Message-ID: <20141113185742.GD9560@nodbug.moloch.sk>
Mail-Followup-To: rumpkernel-users@lists.sourceforge.net,
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk> <5464DECB.8090001@iki.fi>
	<20141113170726.GB9560@nodbug.moloch.sk> <5464E89A.7000908@iki.fi>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464E89A.7000908@iki.fi>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pooka@iki.fi said:
> On 13/11/14 17:07, Martin Lucina wrote:
> > pooka@iki.fi said:
> >> Actually, hmm, there's already an image for /etc available.  I
> >> understood from irc discussion that you needed slight modifications to
> >> passwd for mathopd.  In case your changes don't conflict with what's
> >> already up there, you could just update the existing downloadable /etc
> >> image:
> >> https://github.com/rumpkernel/rumprun-xen/tree/master/img
> >
> > I'll add in a new image rather than touch the current one, so that it can
> > be cd9660 and read-only rather than ffs. Avoids needing to keep a "clean
> > image" around in case of crashes while developing. The old one can stay
> > until we replace the old demo code.
> 
> Generally speaking, file systems support read-only mounts ...

Fair enough, will add in some basic fs options to the relevant parts.
cd9660 is still easier to rebuild on non-BSD hosts, it's just "genisoimage
-l -r -o file.iso <rootdir>".

> > Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer
> > that it's not supposed to be used as a normal /etc.
> 
> I'd prefer it to be completely hidden from the user.  But sure, call it 
> stubetc for now.
> 
> > This brings up another question; what to do with resolv.conf, for example?
> 
> Is resolv.conf an example, i.e. are there other files with similar 
> needs?  Or can we figure out how to handle it as a special case?

Can't think of any. Went and looked in /etc on my laptop to see if anything
of note gets modified regularly and found nothing besides resolv.conf.

If we want to go down the route of not having a user-visible /etc at all
(which I think is a good idea) then perhaps we could modify the libc
resolver to add an API to set the DNS servers directly, which the
rumpconfig and/or dhcp stuff can call.

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 18:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 18:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XozaF-0005IR-VH; Thu, 13 Nov 2014 18:57:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <martin@lucina.net>) id 1XozaE-0005IM-HN
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 18:57:30 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	80/0A-09284-91FF4645; Thu, 13 Nov 2014 18:57:29 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415905048!11199572!1
X-Originating-IP: [62.176.169.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26462 invoked from network); 13 Nov 2014 18:57:28 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 18:57:28 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id D6F3C18057BA;
	Thu, 13 Nov 2014 19:57:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1415905047;
	bh=N7MGlNrN5vx4lyMcglmyVRl185OmcOAvm9K8LiU2sPw=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=S/Xe2sGAjDJWh4rylblYa67QV9AXL3yfLy6LNxiJ0wxI9u/gjQ9AwxDQ0Nrfn/QaW
	F/DUJ/2aB6Q2E2EDSWa4u2RXN7ktBa3TBD6uDNE8g8IGFMLh8YDTa+sLB+pYhR3/Ew
	t4NVQUVOJZ5mIYrdeQp5qVqWhmrueULeGy6dapkO8aqbuF5ohjE51WhvaTARX9lCtJ
	vIeRRLoewJqqKKGqJKa69QlJoLqGUz0fAm2hXut/OgrnCKy4tthTh74rGxUUF2cfUa
	OuL3WvzW3iwUr4CR/8rFngDjhhZtD97GGDYN1eP2E40i1xt6JDtsTk4r+U4gre3GJB
	AVrfy4Od9HtFA==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id D47F94C0E2D; Thu, 13 Nov 2014 19:57:42 +0100 (CET)
Date: Thu, 13 Nov 2014 19:57:42 +0100
From: Martin Lucina <martin@lucina.net>
To: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org,
	Ian.Jackson@eu.citrix.com
Message-ID: <20141113185742.GD9560@nodbug.moloch.sk>
Mail-Followup-To: rumpkernel-users@lists.sourceforge.net,
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk> <5464DECB.8090001@iki.fi>
	<20141113170726.GB9560@nodbug.moloch.sk> <5464E89A.7000908@iki.fi>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464E89A.7000908@iki.fi>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pooka@iki.fi said:
> On 13/11/14 17:07, Martin Lucina wrote:
> > pooka@iki.fi said:
> >> Actually, hmm, there's already an image for /etc available.  I
> >> understood from irc discussion that you needed slight modifications to
> >> passwd for mathopd.  In case your changes don't conflict with what's
> >> already up there, you could just update the existing downloadable /etc
> >> image:
> >> https://github.com/rumpkernel/rumprun-xen/tree/master/img
> >
> > I'll add in a new image rather than touch the current one, so that it can
> > be cd9660 and read-only rather than ffs. Avoids needing to keep a "clean
> > image" around in case of crashes while developing. The old one can stay
> > until we replace the old demo code.
> 
> Generally speaking, file systems support read-only mounts ...

Fair enough, will add in some basic fs options to the relevant parts.
cd9660 is still easier to rebuild on non-BSD hosts, it's just "genisoimage
-l -r -o file.iso <rootdir>".

> > Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer
> > that it's not supposed to be used as a normal /etc.
> 
> I'd prefer it to be completely hidden from the user.  But sure, call it 
> stubetc for now.
> 
> > This brings up another question; what to do with resolv.conf, for example?
> 
> Is resolv.conf an example, i.e. are there other files with similar 
> needs?  Or can we figure out how to handle it as a special case?

Can't think of any. Went and looked in /etc on my laptop to see if anything
of note gets modified regularly and found nothing besides resolv.conf.

If we want to go down the route of not having a user-visible /etc at all
(which I think is a good idea) then perhaps we could modify the libc
resolver to add an API to set the DNS servers directly, which the
rumpconfig and/or dhcp stuff can call.

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:03:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:03:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XozfV-0005dq-Nd; Thu, 13 Nov 2014 19:02:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XozfU-0005dl-H1
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:02:56 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	77/04-02696-F5005645; Thu, 13 Nov 2014 19:02:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415905373!12367616!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8089 invoked from network); 13 Nov 2014 19:02:54 -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;
	13 Nov 2014 19:02:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="192555278"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 13:56:19 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XozZ5-0006mW-0P;
	Thu, 13 Nov 2014 18:56:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XozZ4-0007Fb-6R;
	Thu, 13 Nov 2014 18:56:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21604.65233.591428.51813@mariner.uk.xensource.com>
Date: Thu, 13 Nov 2014 18:56:17 +0000
To: <xen-devel@lists.xenproject.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Lars Kurth <lars.kurth@citrix.com>
Subject: [Xen-devel] Appointing a new committer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I would like to propose that we make Konrad Wilk a Xen committer.
Konrad is of course already a committer to Linux's Xen support.  IMO
he should formally have the authority of a committer in our project,
even though his maintainership in xen.git itself is limited.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:03:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:03:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XozfV-0005dq-Nd; Thu, 13 Nov 2014 19:02:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XozfU-0005dl-H1
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:02:56 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	77/04-02696-F5005645; Thu, 13 Nov 2014 19:02:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415905373!12367616!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8089 invoked from network); 13 Nov 2014 19:02:54 -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;
	13 Nov 2014 19:02:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="192555278"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 13:56:19 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XozZ5-0006mW-0P;
	Thu, 13 Nov 2014 18:56:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XozZ4-0007Fb-6R;
	Thu, 13 Nov 2014 18:56:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21604.65233.591428.51813@mariner.uk.xensource.com>
Date: Thu, 13 Nov 2014 18:56:17 +0000
To: <xen-devel@lists.xenproject.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Lars Kurth <lars.kurth@citrix.com>
Subject: [Xen-devel] Appointing a new committer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I would like to propose that we make Konrad Wilk a Xen committer.
Konrad is of course already a committer to Linux's Xen support.  IMO
he should formally have the authority of a committer in our project,
even though his maintainership in xen.git itself is limited.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:03:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:03:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XozgK-0005hh-4b; Thu, 13 Nov 2014 19:03:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XozgJ-0005hZ-2O
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:03:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B1/7C-09842-29005645; Thu, 13 Nov 2014 19:03:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415905424!12593994!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32005 invoked from network); 13 Nov 2014 19:03:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:03:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJ3fRN025953
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:03:42 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJ3eEj009730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:03:41 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJ3dn2023707; Thu, 13 Nov 2014 19:03:40 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:03:39 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8B695115FC3; Thu, 13 Nov 2014 14:03:38 -0500 (EST)
Date: Thu, 13 Nov 2014 14:03:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Simon Martin <furryfuttock@gmail.com>
Message-ID: <20141113190338.GB11211@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <429773295.20141113144907@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 02:49:07PM -0300, Simon Martin wrote:
> Hello Jan,
> 
> >>
> >> Yes,  the  first thing I do in the driver is set the PCI configuration
> >> access  bits to 7 that should enable IO space, Memory Space and Master
> >> BUS access.
> >> 
> >> As  a  test I disabled this and all reads to the PCI device return -1,
> >> even the first one.
> 
> > I implied your earlier statement to mean that. But - did you also
> > verify that the three flags actually end up set (ideally from both
> > DomU and Dom0 perspective)? The PCI backend may be screwing
> > up things...
> 
> Yes I do verify the write. How do I check this from Dom0?

You can crank up the debug volume in xen-pciback. Recompile the kernel
and put '#define DEBUG 1' at the start of the .c files.

Interestingly enough I saw this issue as well - and it looked to me
that Xen pciback was stuck in '7' state (Reconfiguring) and never
excited it.

But I hadn't had a chance to dig in this.

> 
> >> I  agree,  this looks more than a hang than a crash. I've just found a
> >> link to the USB debug cable. I've ordered one but it will take a while
> 
> > And I hope you first verified that your system meets the criteria
> > for this to work in the first place?
> 
> I followed the checks in the Kernel earlyprintk debugging HOWTO, i.e.
> lspci -vvv to check the USB debug capability, and it verified. The
> device is ordered and now just to wait....
> 
> 
> -- 
> Best regards,
>  Simon                            mailto:furryfuttock@gmail.com
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:03:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:03:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XozgK-0005hh-4b; Thu, 13 Nov 2014 19:03:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XozgJ-0005hZ-2O
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:03:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B1/7C-09842-29005645; Thu, 13 Nov 2014 19:03:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415905424!12593994!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32005 invoked from network); 13 Nov 2014 19:03:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:03:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJ3fRN025953
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:03:42 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJ3eEj009730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:03:41 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJ3dn2023707; Thu, 13 Nov 2014 19:03:40 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:03:39 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8B695115FC3; Thu, 13 Nov 2014 14:03:38 -0500 (EST)
Date: Thu, 13 Nov 2014 14:03:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Simon Martin <furryfuttock@gmail.com>
Message-ID: <20141113190338.GB11211@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <429773295.20141113144907@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 02:49:07PM -0300, Simon Martin wrote:
> Hello Jan,
> 
> >>
> >> Yes,  the  first thing I do in the driver is set the PCI configuration
> >> access  bits to 7 that should enable IO space, Memory Space and Master
> >> BUS access.
> >> 
> >> As  a  test I disabled this and all reads to the PCI device return -1,
> >> even the first one.
> 
> > I implied your earlier statement to mean that. But - did you also
> > verify that the three flags actually end up set (ideally from both
> > DomU and Dom0 perspective)? The PCI backend may be screwing
> > up things...
> 
> Yes I do verify the write. How do I check this from Dom0?

You can crank up the debug volume in xen-pciback. Recompile the kernel
and put '#define DEBUG 1' at the start of the .c files.

Interestingly enough I saw this issue as well - and it looked to me
that Xen pciback was stuck in '7' state (Reconfiguring) and never
excited it.

But I hadn't had a chance to dig in this.

> 
> >> I  agree,  this looks more than a hang than a crash. I've just found a
> >> link to the USB debug cable. I've ordered one but it will take a while
> 
> > And I hope you first verified that your system meets the criteria
> > for this to work in the first place?
> 
> I followed the checks in the Kernel earlyprintk debugging HOWTO, i.e.
> lspci -vvv to check the USB debug capability, and it verified. The
> device is ordered and now just to wait....
> 
> 
> -- 
> Best regards,
>  Simon                            mailto:furryfuttock@gmail.com
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:05:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 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.xen.org>)
	id 1Xozhw-0005om-KC; Thu, 13 Nov 2014 19:05:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xozhu-0005oW-KQ
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:05:26 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	40/DB-11581-5F005645; Thu, 13 Nov 2014 19:05:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415905523!11219110!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7922 invoked from network); 13 Nov 2014 19:05:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:05:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJ5Crw028078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:05:12 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sADJ5BGt005240
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:05:12 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJ5Bki016703; Thu, 13 Nov 2014 19:05:11 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:05:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 00E9E115FCF; Thu, 13 Nov 2014 14:05:09 -0500 (EST)
Date: Thu, 13 Nov 2014 14:05:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20141113190509.GC11211@laptop.dumpdata.com>
References: <1415899632-31802-1-git-send-email-anthony.perard@citrix.com>
	<1415899632-31802-2-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415899632-31802-2-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: EDK2 devel <edk2-devel@lists.sourceforge.net>,
	Scott Duplichan <scott@notabs.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] OvmfPkg/XenBusDxe: In XenStore,
 replace type of Len from UINTN to UINT32.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 05:27:09PM +0000, Anthony PERARD wrote:
> Since a message to XenStore have a lenght of type UINT32, have
> XenStore.c deal only with UINT32 instead of a mixmatch with UINTN.
> 
> This patch replaces the type of Len in WRITE_REQUEST and the type of the
> argument Len of XenStoreWriteStore and XenStoreReadStore.
> 
> This patch should avoid to have type cast were it does not make sense to
> have them.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> CC: Xen Devel <xen-devel@lists.xen.org>
> ---
>  OvmfPkg/XenBusDxe/XenStore.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
> index f176b95..7c272b3 100644
> --- a/OvmfPkg/XenBusDxe/XenStore.c
> +++ b/OvmfPkg/XenBusDxe/XenStore.c
> @@ -69,7 +69,7 @@
>  
>  typedef struct {
>    CONST VOID  *Data;
> -  UINTN       Len;
> +  UINT32      Len;
>  } WRITE_REQUEST;
>  
>  /* Register callback to watch subtree (node) in the XenStore. */
> @@ -456,7 +456,7 @@ STATIC
>  XENSTORE_STATUS
>  XenStoreWriteStore (
>    IN CONST VOID *DataPtr,
> -  IN UINTN      Len
> +  IN UINT32     Len
>    )
>  {
>    XENSTORE_RING_IDX Cons, Prod;
> @@ -535,7 +535,7 @@ STATIC
>  XENSTORE_STATUS
>  XenStoreReadStore (
>    OUT VOID *DataPtr,
> -  IN  UINTN Len
> +  IN  UINT32 Len
>    )
>  {
>    XENSTORE_RING_IDX Cons, Prod;
> @@ -883,7 +883,7 @@ XenStoreSingle (
>    WRITE_REQUEST WriteRequest;
>  
>    WriteRequest.Data = (VOID *) Body;
> -  WriteRequest.Len = AsciiStrSize (Body);
> +  WriteRequest.Len = (UINT32)AsciiStrSize (Body);
>  
>    return XenStoreTalkv (Transaction, RequestType, &WriteRequest, 1,
>                          LenPtr, Result);
> @@ -912,9 +912,9 @@ XenStoreWatch (
>    WRITE_REQUEST WriteRequest[2];
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Token;
> -  WriteRequest[1].Len = AsciiStrSize (Token);
> +  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
>  
>    return XenStoreTalkv (XST_NIL, XS_WATCH, WriteRequest, 2, NULL, NULL);
>  }
> @@ -938,9 +938,9 @@ XenStoreUnwatch (
>    WRITE_REQUEST WriteRequest[2];
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Token;
> -  WriteRequest[1].Len = AsciiStrSize (Token);
> +  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
>  
>    return XenStoreTalkv (XST_NIL, XS_UNWATCH, WriteRequest, 2, NULL, NULL);
>  }
> @@ -1245,9 +1245,9 @@ XenStoreWrite (
>    Path = XenStoreJoin (DirectoryPath, Node);
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Str;
> -  WriteRequest[1].Len = AsciiStrLen (Str);
> +  WriteRequest[1].Len = (UINT32)AsciiStrLen (Str);
>  
>    Status = XenStoreTalkv (Transaction, XS_WRITE, WriteRequest, 2, NULL, NULL);
>    FreePool (Path);
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:05:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 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.xen.org>)
	id 1Xozhw-0005om-KC; Thu, 13 Nov 2014 19:05:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xozhu-0005oW-KQ
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:05:26 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	40/DB-11581-5F005645; Thu, 13 Nov 2014 19:05:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415905523!11219110!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7922 invoked from network); 13 Nov 2014 19:05:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:05:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJ5Crw028078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:05:12 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sADJ5BGt005240
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:05:12 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJ5Bki016703; Thu, 13 Nov 2014 19:05:11 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:05:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 00E9E115FCF; Thu, 13 Nov 2014 14:05:09 -0500 (EST)
Date: Thu, 13 Nov 2014 14:05:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20141113190509.GC11211@laptop.dumpdata.com>
References: <1415899632-31802-1-git-send-email-anthony.perard@citrix.com>
	<1415899632-31802-2-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415899632-31802-2-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: EDK2 devel <edk2-devel@lists.sourceforge.net>,
	Scott Duplichan <scott@notabs.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] OvmfPkg/XenBusDxe: In XenStore,
 replace type of Len from UINTN to UINT32.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 05:27:09PM +0000, Anthony PERARD wrote:
> Since a message to XenStore have a lenght of type UINT32, have
> XenStore.c deal only with UINT32 instead of a mixmatch with UINTN.
> 
> This patch replaces the type of Len in WRITE_REQUEST and the type of the
> argument Len of XenStoreWriteStore and XenStoreReadStore.
> 
> This patch should avoid to have type cast were it does not make sense to
> have them.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> CC: Xen Devel <xen-devel@lists.xen.org>
> ---
>  OvmfPkg/XenBusDxe/XenStore.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
> index f176b95..7c272b3 100644
> --- a/OvmfPkg/XenBusDxe/XenStore.c
> +++ b/OvmfPkg/XenBusDxe/XenStore.c
> @@ -69,7 +69,7 @@
>  
>  typedef struct {
>    CONST VOID  *Data;
> -  UINTN       Len;
> +  UINT32      Len;
>  } WRITE_REQUEST;
>  
>  /* Register callback to watch subtree (node) in the XenStore. */
> @@ -456,7 +456,7 @@ STATIC
>  XENSTORE_STATUS
>  XenStoreWriteStore (
>    IN CONST VOID *DataPtr,
> -  IN UINTN      Len
> +  IN UINT32     Len
>    )
>  {
>    XENSTORE_RING_IDX Cons, Prod;
> @@ -535,7 +535,7 @@ STATIC
>  XENSTORE_STATUS
>  XenStoreReadStore (
>    OUT VOID *DataPtr,
> -  IN  UINTN Len
> +  IN  UINT32 Len
>    )
>  {
>    XENSTORE_RING_IDX Cons, Prod;
> @@ -883,7 +883,7 @@ XenStoreSingle (
>    WRITE_REQUEST WriteRequest;
>  
>    WriteRequest.Data = (VOID *) Body;
> -  WriteRequest.Len = AsciiStrSize (Body);
> +  WriteRequest.Len = (UINT32)AsciiStrSize (Body);
>  
>    return XenStoreTalkv (Transaction, RequestType, &WriteRequest, 1,
>                          LenPtr, Result);
> @@ -912,9 +912,9 @@ XenStoreWatch (
>    WRITE_REQUEST WriteRequest[2];
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Token;
> -  WriteRequest[1].Len = AsciiStrSize (Token);
> +  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
>  
>    return XenStoreTalkv (XST_NIL, XS_WATCH, WriteRequest, 2, NULL, NULL);
>  }
> @@ -938,9 +938,9 @@ XenStoreUnwatch (
>    WRITE_REQUEST WriteRequest[2];
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Token;
> -  WriteRequest[1].Len = AsciiStrSize (Token);
> +  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
>  
>    return XenStoreTalkv (XST_NIL, XS_UNWATCH, WriteRequest, 2, NULL, NULL);
>  }
> @@ -1245,9 +1245,9 @@ XenStoreWrite (
>    Path = XenStoreJoin (DirectoryPath, Node);
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Str;
> -  WriteRequest[1].Len = AsciiStrLen (Str);
> +  WriteRequest[1].Len = (UINT32)AsciiStrLen (Str);
>  
>    Status = XenStoreTalkv (Transaction, XS_WRITE, WriteRequest, 2, NULL, NULL);
>    FreePool (Path);
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:05:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoziH-0005rN-Vy; Thu, 13 Nov 2014 19:05:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth@citrix.com>) id 1XoziG-0005rF-Rq
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:05:48 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	C9/CC-27623-C0105645; Thu, 13 Nov 2014 19:05:48 +0000
X-Env-Sender: lars.kurth@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415905547!11181531!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19780 invoked from network); 13 Nov 2014 19:05:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 19:05:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="26833143"
From: Lars Kurth <lars.kurth@citrix.com>
To: Ian Jackson <Ian.Jackson@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Thread-Topic: Appointing a new committer
Thread-Index: AQHP/3OHtpMYvKg8Lku6TkW45TWIr5xe2fsA
Date: Thu, 13 Nov 2014 19:05:45 +0000
Message-ID: <D08AB036.152BA%lars.kurth@citrix.com>
References: <21604.65233.591428.51813@mariner.uk.xensource.com>
In-Reply-To: <21604.65233.591428.51813@mariner.uk.xensource.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
Content-ID: <EDB4B09577C9244199908E5ED8E4F354@citrix.com>
MIME-Version: 1.0
X-DLP: AMS1
Subject: Re: [Xen-devel] Appointing a new committer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian,

I totally agree. I don't think that limited maintainership in xen.git is
an issue. 

If I look at the process, it states that
a) A committer needs to nominate the candidate - tick
b) A private election amongst committers of the project must be held using
a voting form created by me, and then there will be a formal vote.

If Konrad agrees, that he would be willing to be a committer, I will set
up a form and formal vote. I would do this tomorrow.

Regards
Lars


On 13/11/2014 18:56, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

>I would like to propose that we make Konrad Wilk a Xen committer.
>Konrad is of course already a committer to Linux's Xen support.  IMO
>he should formally have the authority of a committer in our project,
>even though his maintainership in xen.git itself is limited.
>
>Thanks,
>Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:05:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XoziH-0005rN-Vy; Thu, 13 Nov 2014 19:05:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth@citrix.com>) id 1XoziG-0005rF-Rq
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:05:48 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	C9/CC-27623-C0105645; Thu, 13 Nov 2014 19:05:48 +0000
X-Env-Sender: lars.kurth@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415905547!11181531!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19780 invoked from network); 13 Nov 2014 19:05:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 19:05:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="26833143"
From: Lars Kurth <lars.kurth@citrix.com>
To: Ian Jackson <Ian.Jackson@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Thread-Topic: Appointing a new committer
Thread-Index: AQHP/3OHtpMYvKg8Lku6TkW45TWIr5xe2fsA
Date: Thu, 13 Nov 2014 19:05:45 +0000
Message-ID: <D08AB036.152BA%lars.kurth@citrix.com>
References: <21604.65233.591428.51813@mariner.uk.xensource.com>
In-Reply-To: <21604.65233.591428.51813@mariner.uk.xensource.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
Content-ID: <EDB4B09577C9244199908E5ED8E4F354@citrix.com>
MIME-Version: 1.0
X-DLP: AMS1
Subject: Re: [Xen-devel] Appointing a new committer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian,

I totally agree. I don't think that limited maintainership in xen.git is
an issue. 

If I look at the process, it states that
a) A committer needs to nominate the candidate - tick
b) A private election amongst committers of the project must be held using
a voting form created by me, and then there will be a formal vote.

If Konrad agrees, that he would be willing to be a committer, I will set
up a form and formal vote. I would do this tomorrow.

Regards
Lars


On 13/11/2014 18:56, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

>I would like to propose that we make Konrad Wilk a Xen committer.
>Konrad is of course already a committer to Linux's Xen support.  IMO
>he should formally have the authority of a committer in our project,
>even though his maintainership in xen.git itself is limited.
>
>Thanks,
>Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:09:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xozlt-00069f-K6; Thu, 13 Nov 2014 19:09:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xozls-00069X-CS
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:09:32 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	74/D9-02712-BE105645; Thu, 13 Nov 2014 19:09:31 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415905767!12384208!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13660 invoked from network); 13 Nov 2014 19:09:30 -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 Nov 2014 19:09:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="192560016"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 14:04:14 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xozgj-0006w4-T1;
	Thu, 13 Nov 2014 19:04:13 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Nov 2014 19:04:06 +0000
Message-ID: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes for
	block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Return proper error codes on failure so that scripts can tell whether
the command completed properly or not.

Also while we're at it, normalize init and dispose of
libxl_device_disk structures.  This means calling init and dispose in
the actual functions where they are declared.

This in turn means changing parse_disk_config_multistring() to not
call libxl_device_disk_init.  And that in turn means changes to
callers of parse_disk_config().

It also means removing libxl_device_disk_init() from
libxl.c:libxl_vdev_to_device_disk().  This is only called from
xl_cmdimpl.c.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Konrad Wilk <konrad.wilk@oracle.com>

Release justification: This is a bug fix.  It's a fairly minor one,
but it's also a very simple one.

v2:
 - Restructure functions to make sure init and dispose are properly
 called.
---
 tools/libxl/libxl.c      |  2 --
 tools/libxl/xl_cmdimpl.c | 28 +++++++++++++++++++++-------
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..d9c4ce7 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2611,8 +2611,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid,
     if (devid < 0)
         return ERROR_INVAL;
 
-    libxl_device_disk_init(disk);
-
     dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath) {
         goto out;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..25af715 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -485,8 +485,6 @@ static void parse_disk_config_multistring(XLU_Config **config,
 {
     int e;
 
-    libxl_device_disk_init(disk);
-
     if (!*config) {
         *config = xlu_cfg_init(stderr, "command line");
         if (!*config) { perror("xlu_cfg_init"); exit(-1); }
@@ -1405,6 +1403,7 @@ static void parse_config_data(const char *config_source,
 
             d_config->disks = (libxl_device_disk *) realloc(d_config->disks, sizeof (libxl_device_disk) * (d_config->num_disks + 1));
             disk = d_config->disks + d_config->num_disks;
+            libxl_device_disk_init(disk);
             parse_disk_config(&config, buf2, disk);
 
             free(buf2);
@@ -2931,6 +2930,8 @@ static int cd_insert(uint32_t domid, const char *virtdev, char *phys)
         return 1;
     }
 
+    libxl_device_disk_init(&disk);
+
     parse_disk_config(&config, buf, &disk);
 
     /* ATM the existence of the backing file is not checked for qdisk
@@ -6359,6 +6360,7 @@ int main_blockattach(int argc, char **argv)
     uint32_t fe_domid;
     libxl_device_disk disk;
     XLU_Config *config = 0;
+    int rc = 0;
 
     SWITCH_FOREACH_OPT(opt, "", NULL, "block-attach", 2) {
         /* No options */
@@ -6370,6 +6372,8 @@ int main_blockattach(int argc, char **argv)
     }
     optind++;
 
+    libxl_device_disk_init(&disk);
+
     parse_disk_config_multistring
         (&config, argc-optind, (const char* const*)argv + optind, &disk);
 
@@ -6378,13 +6382,17 @@ int main_blockattach(int argc, char **argv)
         printf("disk: %s\n", json);
         free(json);
         if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
-        return 0;
+        goto out;
     }
 
     if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
+        rc = 1;
     }
-    return 0;
+out:
+    libxl_device_disk_dispose(&disk);
+
+    return rc;
 }
 
 int main_blocklist(int argc, char **argv)
@@ -6435,17 +6443,23 @@ int main_blockdetach(int argc, char **argv)
         /* No options */
     }
 
+    libxl_device_disk_init(&disk);
+
     domid = find_domain(argv[optind]);
 
     if (libxl_vdev_to_device_disk(ctx, domid, argv[optind+1], &disk)) {
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
-        return 1;
+        rc = 1;
+        goto out;
     }
-    rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
-    if (rc) {
+    if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
+        rc = 1;
     }
+
+out:
     libxl_device_disk_dispose(&disk);
+
     return rc;
 }
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:09:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xozlt-00069f-K6; Thu, 13 Nov 2014 19:09:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xozls-00069X-CS
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:09:32 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	74/D9-02712-BE105645; Thu, 13 Nov 2014 19:09:31 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415905767!12384208!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13660 invoked from network); 13 Nov 2014 19:09:30 -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 Nov 2014 19:09:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="192560016"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 14:04:14 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Xozgj-0006w4-T1;
	Thu, 13 Nov 2014 19:04:13 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Nov 2014 19:04:06 +0000
Message-ID: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes for
	block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Return proper error codes on failure so that scripts can tell whether
the command completed properly or not.

Also while we're at it, normalize init and dispose of
libxl_device_disk structures.  This means calling init and dispose in
the actual functions where they are declared.

This in turn means changing parse_disk_config_multistring() to not
call libxl_device_disk_init.  And that in turn means changes to
callers of parse_disk_config().

It also means removing libxl_device_disk_init() from
libxl.c:libxl_vdev_to_device_disk().  This is only called from
xl_cmdimpl.c.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Konrad Wilk <konrad.wilk@oracle.com>

Release justification: This is a bug fix.  It's a fairly minor one,
but it's also a very simple one.

v2:
 - Restructure functions to make sure init and dispose are properly
 called.
---
 tools/libxl/libxl.c      |  2 --
 tools/libxl/xl_cmdimpl.c | 28 +++++++++++++++++++++-------
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..d9c4ce7 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2611,8 +2611,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid,
     if (devid < 0)
         return ERROR_INVAL;
 
-    libxl_device_disk_init(disk);
-
     dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath) {
         goto out;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..25af715 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -485,8 +485,6 @@ static void parse_disk_config_multistring(XLU_Config **config,
 {
     int e;
 
-    libxl_device_disk_init(disk);
-
     if (!*config) {
         *config = xlu_cfg_init(stderr, "command line");
         if (!*config) { perror("xlu_cfg_init"); exit(-1); }
@@ -1405,6 +1403,7 @@ static void parse_config_data(const char *config_source,
 
             d_config->disks = (libxl_device_disk *) realloc(d_config->disks, sizeof (libxl_device_disk) * (d_config->num_disks + 1));
             disk = d_config->disks + d_config->num_disks;
+            libxl_device_disk_init(disk);
             parse_disk_config(&config, buf2, disk);
 
             free(buf2);
@@ -2931,6 +2930,8 @@ static int cd_insert(uint32_t domid, const char *virtdev, char *phys)
         return 1;
     }
 
+    libxl_device_disk_init(&disk);
+
     parse_disk_config(&config, buf, &disk);
 
     /* ATM the existence of the backing file is not checked for qdisk
@@ -6359,6 +6360,7 @@ int main_blockattach(int argc, char **argv)
     uint32_t fe_domid;
     libxl_device_disk disk;
     XLU_Config *config = 0;
+    int rc = 0;
 
     SWITCH_FOREACH_OPT(opt, "", NULL, "block-attach", 2) {
         /* No options */
@@ -6370,6 +6372,8 @@ int main_blockattach(int argc, char **argv)
     }
     optind++;
 
+    libxl_device_disk_init(&disk);
+
     parse_disk_config_multistring
         (&config, argc-optind, (const char* const*)argv + optind, &disk);
 
@@ -6378,13 +6382,17 @@ int main_blockattach(int argc, char **argv)
         printf("disk: %s\n", json);
         free(json);
         if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
-        return 0;
+        goto out;
     }
 
     if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
+        rc = 1;
     }
-    return 0;
+out:
+    libxl_device_disk_dispose(&disk);
+
+    return rc;
 }
 
 int main_blocklist(int argc, char **argv)
@@ -6435,17 +6443,23 @@ int main_blockdetach(int argc, char **argv)
         /* No options */
     }
 
+    libxl_device_disk_init(&disk);
+
     domid = find_domain(argv[optind]);
 
     if (libxl_vdev_to_device_disk(ctx, domid, argv[optind+1], &disk)) {
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
-        return 1;
+        rc = 1;
+        goto out;
     }
-    rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
-    if (rc) {
+    if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
+        rc = 1;
     }
+
+out:
     libxl_device_disk_dispose(&disk);
+
     return rc;
 }
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:17:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19: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 1Xozsp-0006X4-MB; Thu, 13 Nov 2014 19:16:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xozso-0006Wz-9c
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:16:42 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	F1/37-28296-99305645; Thu, 13 Nov 2014 19:16:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415906199!11257569!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17772 invoked from network); 13 Nov 2014 19:16:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:16:40 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJGW0Z029462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:16:33 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJGVM6012416
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:16:32 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJGU10014910; Thu, 13 Nov 2014 19:16:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:16:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9872E115FFC; Thu, 13 Nov 2014 14:16:29 -0500 (EST)
Date: Thu, 13 Nov 2014 14:16:29 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141113191629.GB11727@laptop.dumpdata.com>
References: <5464D627.7060104@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464D627.7060104@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer results from the Test Day for RC2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 04:02:47PM +0000, Andrew Cooper wrote:
> Hi,
> 
> While attempting to test Konrads new interrupt injection logic, I got
> blocked behind yet another Pygrub bug caused by c/s d1b93ea
> 
> This is the first time I have looked into the issue, but a cursory
> inspection of the first hunk shows that it cannot possibly be correct as
> self._default is either an integer or string.
> 
> I have a possible workaround which I am testing, but cursory review of
> the patch would have shown that it cannot work as intended.
> 
> Notice that self._default is now either a string or an integer,
> defaulting to an integer, and the top level code is updated to require a
> string.  As a result, any bootloader configuration which doesn't
> explicitly set a default, or still drives this logic with integers
> (ExtLinux or LiLO) will die with an AttributeError

Thank you for testing it. In case you don't get to it - and are 
preempted by other stuff - please do give me a braindump (and
preliminary patch if you have one) so I can dig into it.

Thank you!
> 
> ~Andrew
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:17:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19: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 1Xozsp-0006X4-MB; Thu, 13 Nov 2014 19:16:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xozso-0006Wz-9c
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:16:42 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	F1/37-28296-99305645; Thu, 13 Nov 2014 19:16:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415906199!11257569!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17772 invoked from network); 13 Nov 2014 19:16:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:16:40 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJGW0Z029462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:16:33 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJGVM6012416
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:16:32 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJGU10014910; Thu, 13 Nov 2014 19:16:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:16:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9872E115FFC; Thu, 13 Nov 2014 14:16:29 -0500 (EST)
Date: Thu, 13 Nov 2014 14:16:29 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141113191629.GB11727@laptop.dumpdata.com>
References: <5464D627.7060104@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464D627.7060104@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer results from the Test Day for RC2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 04:02:47PM +0000, Andrew Cooper wrote:
> Hi,
> 
> While attempting to test Konrads new interrupt injection logic, I got
> blocked behind yet another Pygrub bug caused by c/s d1b93ea
> 
> This is the first time I have looked into the issue, but a cursory
> inspection of the first hunk shows that it cannot possibly be correct as
> self._default is either an integer or string.
> 
> I have a possible workaround which I am testing, but cursory review of
> the patch would have shown that it cannot work as intended.
> 
> Notice that self._default is now either a string or an integer,
> defaulting to an integer, and the top level code is updated to require a
> string.  As a result, any bootloader configuration which doesn't
> explicitly set a default, or still drives this logic with integers
> (ExtLinux or LiLO) will die with an AttributeError

Thank you for testing it. In case you don't get to it - and are 
preempted by other stuff - please do give me a braindump (and
preliminary patch if you have one) so I can dig into it.

Thank you!
> 
> ~Andrew
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:18:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XozuX-0006bW-5j; Thu, 13 Nov 2014 19:18:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XozuV-0006bN-DT
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:18:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	16/DE-24532-20405645; Thu, 13 Nov 2014 19:18:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415906305!12589725!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15607 invoked from network); 13 Nov 2014 19:18:26 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:18:26 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJIJuT031491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:18:20 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sADJIHhE022623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:18:18 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJIHFu020924; Thu, 13 Nov 2014 19:18:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:18:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 572C1116000; Thu, 13 Nov 2014 14:18:16 -0500 (EST)
Date: Thu, 13 Nov 2014 14:18:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141113191816.GC11727@laptop.dumpdata.com>
References: <1415894589-18256-1-git-send-email-tim@xen.org>
	<5464E80202000078000474B1@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464E80202000078000474B1@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, keir@xen.org,
	Tim Deegan <tim@xen.org>, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2] xen: remove Xencomm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 04:18:58PM +0000, Jan Beulich wrote:
> >>> On 13.11.14 at 17:03, <tim@xen.org> wrote:
> > Being a feature that has only been used by ia64 and/or ppc it
> > doesn't seem like we need to keep it any longer in the tree.
> > 
> > So remove it.
> > 
> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

Are folks OK if this is deferred to Xen 4.6?

Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:18:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XozuX-0006bW-5j; Thu, 13 Nov 2014 19:18:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XozuV-0006bN-DT
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:18:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	16/DE-24532-20405645; Thu, 13 Nov 2014 19:18:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415906305!12589725!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15607 invoked from network); 13 Nov 2014 19:18:26 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:18:26 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJIJuT031491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:18:20 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sADJIHhE022623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:18:18 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJIHFu020924; Thu, 13 Nov 2014 19:18:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:18:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 572C1116000; Thu, 13 Nov 2014 14:18:16 -0500 (EST)
Date: Thu, 13 Nov 2014 14:18:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141113191816.GC11727@laptop.dumpdata.com>
References: <1415894589-18256-1-git-send-email-tim@xen.org>
	<5464E80202000078000474B1@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464E80202000078000474B1@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, keir@xen.org,
	Tim Deegan <tim@xen.org>, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2] xen: remove Xencomm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 04:18:58PM +0000, Jan Beulich wrote:
> >>> On 13.11.14 at 17:03, <tim@xen.org> wrote:
> > Being a feature that has only been used by ia64 and/or ppc it
> > doesn't seem like we need to keep it any longer in the tree.
> > 
> > So remove it.
> > 
> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

Are folks OK if this is deferred to Xen 4.6?

Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:20:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19: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.xen.org>)
	id 1XozwE-0006jv-Ly; Thu, 13 Nov 2014 19:20:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XozwD-0006jk-2e
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:20:13 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	B8/82-25714-C6405645; Thu, 13 Nov 2014 19:20:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415906410!11207291!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31218 invoked from network); 13 Nov 2014 19:20:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Nov 2014 19:20:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJK2qq001230
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:20:03 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJK120015107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:20:02 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJK12E026213; Thu, 13 Nov 2014 19:20:01 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:20:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 94937116009; Thu, 13 Nov 2014 14:20:00 -0500 (EST)
Date: Thu, 13 Nov 2014 14:20:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lars Kurth <lars.kurth@citrix.com>
Message-ID: <20141113192000.GD11727@laptop.dumpdata.com>
References: <21604.65233.591428.51813@mariner.uk.xensource.com>
	<D08AB036.152BA%lars.kurth@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D08AB036.152BA%lars.kurth@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <Ian.Jackson@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Appointing a new committer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 07:05:45PM +0000, Lars Kurth wrote:
> Ian,
> 
> I totally agree. I don't think that limited maintainership in xen.git is
> an issue. 
> 
> If I look at the process, it states that
> a) A committer needs to nominate the candidate - tick
> b) A private election amongst committers of the project must be held using
> a voting form created by me, and then there will be a formal vote.
> 
> If Konrad agrees, that he would be willing to be a committer, I will set
> up a form and formal vote. I would do this tomorrow.

Sure!

Muhahhhahahahah.. Ahem, ignore that please :-)

> 
> Regards
> Lars
> 
> 
> On 13/11/2014 18:56, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> 
> >I would like to propose that we make Konrad Wilk a Xen committer.
> >Konrad is of course already a committer to Linux's Xen support.  IMO
> >he should formally have the authority of a committer in our project,
> >even though his maintainership in xen.git itself is limited.
> >
> >Thanks,
> >Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:20:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19: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.xen.org>)
	id 1XozwE-0006jv-Ly; Thu, 13 Nov 2014 19:20:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XozwD-0006jk-2e
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:20:13 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	B8/82-25714-C6405645; Thu, 13 Nov 2014 19:20:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415906410!11207291!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31218 invoked from network); 13 Nov 2014 19:20:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Nov 2014 19:20:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJK2qq001230
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:20:03 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJK120015107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:20:02 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJK12E026213; Thu, 13 Nov 2014 19:20:01 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:20:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 94937116009; Thu, 13 Nov 2014 14:20:00 -0500 (EST)
Date: Thu, 13 Nov 2014 14:20:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lars Kurth <lars.kurth@citrix.com>
Message-ID: <20141113192000.GD11727@laptop.dumpdata.com>
References: <21604.65233.591428.51813@mariner.uk.xensource.com>
	<D08AB036.152BA%lars.kurth@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D08AB036.152BA%lars.kurth@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <Ian.Jackson@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Appointing a new committer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 07:05:45PM +0000, Lars Kurth wrote:
> Ian,
> 
> I totally agree. I don't think that limited maintainership in xen.git is
> an issue. 
> 
> If I look at the process, it states that
> a) A committer needs to nominate the candidate - tick
> b) A private election amongst committers of the project must be held using
> a voting form created by me, and then there will be a formal vote.
> 
> If Konrad agrees, that he would be willing to be a committer, I will set
> up a form and formal vote. I would do this tomorrow.

Sure!

Muhahhhahahahah.. Ahem, ignore that please :-)

> 
> Regards
> Lars
> 
> 
> On 13/11/2014 18:56, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> 
> >I would like to propose that we make Konrad Wilk a Xen committer.
> >Konrad is of course already a committer to Linux's Xen support.  IMO
> >he should formally have the authority of a committer in our project,
> >even though his maintainership in xen.git itself is limited.
> >
> >Thanks,
> >Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:21:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19: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 1Xozxm-0006zR-5e; Thu, 13 Nov 2014 19:21:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1Xozxl-0006vp-25
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:21:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	21/EF-02696-CC405645; Thu, 13 Nov 2014 19:21:48 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415906506!12422202!1
X-Originating-IP: [209.85.192.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 651 invoked from network); 13 Nov 2014 19:21:47 -0000
Received: from mail-qg0-f66.google.com (HELO mail-qg0-f66.google.com)
	(209.85.192.66)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 19:21:47 -0000
Received: by mail-qg0-f66.google.com with SMTP id j107so4163qga.9
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 11:21:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=PslfAP26977l79H1Q2Osv5KziMM878IKV9xbsX35wo4=;
	b=FoJmt4z+je0Sxg1K2xddxUgCOlOiGyrs0SsiYPt2ZahVWXzhx+JWcqzCoponv7KmB4
	bkl3NqrojJ6zNYWPtT0mCp2mP2oHQdjqegUCksrnGf8ibYTCC8Ckjig1UrlFVCC50Mn+
	pL86pQ3DSO+Ifvb48DBUY7K7OmktXVQz5G2y4fXufYnI3+uEBl1Hv3mYtnzv4P/qS7jw
	IMErsJ1ONxLHZTH+ilmxWto04/9dWLkKZrBgxS9fTEEbsLPNExynbK8VEOrN1xDIkroY
	EvX1RsJ/olZwYHqWDE8a1z6UDOs6ilMkOdF/VD7075wSk/8qOGbBKjgZCZISWlcGmx1M
	jXmA==
X-Received: by 10.140.106.194 with SMTP id e60mr5325720qgf.71.1415906506447;
	Thu, 13 Nov 2014 11:21:46 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.161])
	by mx.google.com with ESMTPSA id d2sm24820028qab.24.2014.11.13.11.21.44
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Thu, 13 Nov 2014 11:21:46 -0800 (PST)
Date: Thu, 13 Nov 2014 16:21:48 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <1747475571.20141113162148@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141113190338.GB11211@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<20141113190338.GB11211@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Thanks Konrad,

Thursday, November 13, 2014, 4:03:38 PM, you wrote:

>> Yes I do verify the write. How do I check this from Dom0?

> You can crank up the debug volume in xen-pciback. Recompile the kernel
> and put '#define DEBUG 1' at the start of the .c files.

> Interestingly enough I saw this issue as well - and it looked to me
> that Xen pciback was stuck in '7' state (Reconfiguring) and never
> excited it.

> But I hadn't had a chance to dig in this.

This  might  be related to something that I reported a while ago, that
when   I   shutdown  the PV it takes a long time for the corresponding
Dom0 processes to stop.

I'll set the debug level and see what's going on. That'll be on Monday
now.


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:21:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19: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 1Xozxm-0006zR-5e; Thu, 13 Nov 2014 19:21:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1Xozxl-0006vp-25
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:21:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	21/EF-02696-CC405645; Thu, 13 Nov 2014 19:21:48 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415906506!12422202!1
X-Originating-IP: [209.85.192.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 651 invoked from network); 13 Nov 2014 19:21:47 -0000
Received: from mail-qg0-f66.google.com (HELO mail-qg0-f66.google.com)
	(209.85.192.66)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 19:21:47 -0000
Received: by mail-qg0-f66.google.com with SMTP id j107so4163qga.9
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 11:21:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=PslfAP26977l79H1Q2Osv5KziMM878IKV9xbsX35wo4=;
	b=FoJmt4z+je0Sxg1K2xddxUgCOlOiGyrs0SsiYPt2ZahVWXzhx+JWcqzCoponv7KmB4
	bkl3NqrojJ6zNYWPtT0mCp2mP2oHQdjqegUCksrnGf8ibYTCC8Ckjig1UrlFVCC50Mn+
	pL86pQ3DSO+Ifvb48DBUY7K7OmktXVQz5G2y4fXufYnI3+uEBl1Hv3mYtnzv4P/qS7jw
	IMErsJ1ONxLHZTH+ilmxWto04/9dWLkKZrBgxS9fTEEbsLPNExynbK8VEOrN1xDIkroY
	EvX1RsJ/olZwYHqWDE8a1z6UDOs6ilMkOdF/VD7075wSk/8qOGbBKjgZCZISWlcGmx1M
	jXmA==
X-Received: by 10.140.106.194 with SMTP id e60mr5325720qgf.71.1415906506447;
	Thu, 13 Nov 2014 11:21:46 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.161])
	by mx.google.com with ESMTPSA id d2sm24820028qab.24.2014.11.13.11.21.44
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Thu, 13 Nov 2014 11:21:46 -0800 (PST)
Date: Thu, 13 Nov 2014 16:21:48 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <1747475571.20141113162148@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141113190338.GB11211@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<20141113190338.GB11211@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Thanks Konrad,

Thursday, November 13, 2014, 4:03:38 PM, you wrote:

>> Yes I do verify the write. How do I check this from Dom0?

> You can crank up the debug volume in xen-pciback. Recompile the kernel
> and put '#define DEBUG 1' at the start of the .c files.

> Interestingly enough I saw this issue as well - and it looked to me
> that Xen pciback was stuck in '7' state (Reconfiguring) and never
> excited it.

> But I hadn't had a chance to dig in this.

This  might  be related to something that I reported a while ago, that
when   I   shutdown  the PV it takes a long time for the corresponding
Dom0 processes to stop.

I'll set the debug level and see what's going on. That'll be on Monday
now.


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:22:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xozxv-00074x-I1; Thu, 13 Nov 2014 19:21:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xozxt-00074T-UC
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:21:58 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	32/AA-02698-5D405645; Thu, 13 Nov 2014 19:21:57 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415906514!12410834!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2403 invoked from network); 13 Nov 2014 19:21:56 -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;
	13 Nov 2014 19:21:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="191111576"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 14:21:37 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XozxY-0007AV-Db;
	Thu, 13 Nov 2014 19:21:36 +0000
Message-ID: <546504BA.10506@eu.citrix.com>
Date: Thu, 13 Nov 2014 19:21:30 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>, <xen-devel@lists.xenproject.org>, 
	<qemu-devel@nongnu.org>
References: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
Content-Length:1241
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 for-xen-4.5] xen_disk: fix unmapping of
 persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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

T24gMTEvMTMvMjAxNCAwNTo0MiBQTSwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+IFRoaXMgcGF0
Y2ggZml4ZXMgdHdvIGlzc3VlcyB3aXRoIHBlcnNpc3RlbnQgZ3JhbnRzIGFuZCB0aGUgZGlzayBQ
ViBiYWNrZW5kCj4gKFFkaXNrKToKPgo+ICAgLSBLZWVwIHRyYWNrIG9mIG1lbW9yeSByZWdpb25z
IHdoZXJlIHBlcnNpc3RlbnQgZ3JhbnRzIGhhdmUgYmVlbiBtYXBwZWQKPiAgICAgc2luY2Ugd2Ug
bmVlZCB0byB1bm1hcCB0aGVtIGFzIGEgd2hvbGUuIEl0IGlzIG5vdCBwb3NzaWJsZSB0byB1bm1h
cCBhCj4gICAgIHNpbmdsZSBncmFudCBpZiBpdCBoYXMgYmVlbiBiYXRjaC1tYXBwZWQuIEEgbmV3
IGNoZWNrIGhhcyBhbHNvIGJlZW4gYWRkZWQKPiAgICAgdG8gbWFrZSBzdXJlIHBlcnNpc3RlbnQg
Z3JhbnRzIGFyZSBvbmx5IHVzZWQgaWYgdGhlIHdob2xlIG1hcHBlZCByZWdpb24KPiAgICAgY2Fu
IGJlIHBlcnNpc3RlbnRseSBtYXBwZWQgaW4gdGhlIGJhdGNoX21hcHMgY2FzZS4KPiAgIC0gVW5t
YXAgcGVyc2lzdGVudCBncmFudHMgYmVmb3JlIHN3aXRjaGluZyB0byB0aGUgY2xvc2VkIHN0YXRl
LCBzbyB0aGUKPiAgICAgZnJvbnRlbmQgY2FuIGFsc28gZnJlZSB0aGVtLgo+Cj4gU2lnbmVkLW9m
Zi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4gUmVwb3J0ZWQt
Ynk6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KClRlc3RlZC1i
eTogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXguY29tPgoKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:22:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xozxv-00074x-I1; Thu, 13 Nov 2014 19:21:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Xozxt-00074T-UC
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:21:58 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	32/AA-02698-5D405645; Thu, 13 Nov 2014 19:21:57 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415906514!12410834!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2403 invoked from network); 13 Nov 2014 19:21:56 -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;
	13 Nov 2014 19:21:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="191111576"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 13 Nov 2014 14:21:37 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XozxY-0007AV-Db;
	Thu, 13 Nov 2014 19:21:36 +0000
Message-ID: <546504BA.10506@eu.citrix.com>
Date: Thu, 13 Nov 2014 19:21:30 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>, <xen-devel@lists.xenproject.org>, 
	<qemu-devel@nongnu.org>
References: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
Content-Length:1241
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 for-xen-4.5] xen_disk: fix unmapping of
 persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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

T24gMTEvMTMvMjAxNCAwNTo0MiBQTSwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+IFRoaXMgcGF0
Y2ggZml4ZXMgdHdvIGlzc3VlcyB3aXRoIHBlcnNpc3RlbnQgZ3JhbnRzIGFuZCB0aGUgZGlzayBQ
ViBiYWNrZW5kCj4gKFFkaXNrKToKPgo+ICAgLSBLZWVwIHRyYWNrIG9mIG1lbW9yeSByZWdpb25z
IHdoZXJlIHBlcnNpc3RlbnQgZ3JhbnRzIGhhdmUgYmVlbiBtYXBwZWQKPiAgICAgc2luY2Ugd2Ug
bmVlZCB0byB1bm1hcCB0aGVtIGFzIGEgd2hvbGUuIEl0IGlzIG5vdCBwb3NzaWJsZSB0byB1bm1h
cCBhCj4gICAgIHNpbmdsZSBncmFudCBpZiBpdCBoYXMgYmVlbiBiYXRjaC1tYXBwZWQuIEEgbmV3
IGNoZWNrIGhhcyBhbHNvIGJlZW4gYWRkZWQKPiAgICAgdG8gbWFrZSBzdXJlIHBlcnNpc3RlbnQg
Z3JhbnRzIGFyZSBvbmx5IHVzZWQgaWYgdGhlIHdob2xlIG1hcHBlZCByZWdpb24KPiAgICAgY2Fu
IGJlIHBlcnNpc3RlbnRseSBtYXBwZWQgaW4gdGhlIGJhdGNoX21hcHMgY2FzZS4KPiAgIC0gVW5t
YXAgcGVyc2lzdGVudCBncmFudHMgYmVmb3JlIHN3aXRjaGluZyB0byB0aGUgY2xvc2VkIHN0YXRl
LCBzbyB0aGUKPiAgICAgZnJvbnRlbmQgY2FuIGFsc28gZnJlZSB0aGVtLgo+Cj4gU2lnbmVkLW9m
Zi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4gUmVwb3J0ZWQt
Ynk6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KClRlc3RlZC1i
eTogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXguY29tPgoKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:29:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:29:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp056-0007QN-Kb; Thu, 13 Nov 2014 19:29:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xp055-0007QI-Tp
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:29:24 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F7/26-17958-39605645; Thu, 13 Nov 2014 19:29:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415906960!11224935!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11872 invoked from network); 13 Nov 2014 19:29:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:29:22 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJTI3M025367
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:29:18 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJTHfl004541
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:29:18 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJTHn7006315; Thu, 13 Nov 2014 19:29:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:29:16 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9A73B116027; Thu, 13 Nov 2014 14:29:15 -0500 (EST)
Date: Thu, 13 Nov 2014 14:29:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Simon Martin <furryfuttock@gmail.com>
Message-ID: <20141113192915.GA12502@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<20141113190338.GB11211@laptop.dumpdata.com>
	<1747475571.20141113162148@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1747475571.20141113162148@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 04:21:48PM -0300, Simon Martin wrote:
> Thanks Konrad,
> 
> Thursday, November 13, 2014, 4:03:38 PM, you wrote:
> 
> >> Yes I do verify the write. How do I check this from Dom0?
> 
> > You can crank up the debug volume in xen-pciback. Recompile the kernel
> > and put '#define DEBUG 1' at the start of the .c files.
> 
> > Interestingly enough I saw this issue as well - and it looked to me
> > that Xen pciback was stuck in '7' state (Reconfiguring) and never
> > excited it.
> 
> > But I hadn't had a chance to dig in this.
> 
> This  might  be related to something that I reported a while ago, that
> when   I   shutdown  the PV it takes a long time for the corresponding
> Dom0 processes to stop.
> 
> I'll set the debug level and see what's going on. That'll be on Monday
> now.

Sure thing. Thank you for reporting it!
> 
> 
> -- 
> Best regards,
>  Simon                            mailto:furryfuttock@gmail.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:29:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:29:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp056-0007QN-Kb; Thu, 13 Nov 2014 19:29:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xp055-0007QI-Tp
	for xen-devel@lists.xen.org; Thu, 13 Nov 2014 19:29:24 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F7/26-17958-39605645; Thu, 13 Nov 2014 19:29:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415906960!11224935!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11872 invoked from network); 13 Nov 2014 19:29:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:29:22 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJTI3M025367
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:29:18 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJTHfl004541
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:29:18 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJTHn7006315; Thu, 13 Nov 2014 19:29:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:29:16 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9A73B116027; Thu, 13 Nov 2014 14:29:15 -0500 (EST)
Date: Thu, 13 Nov 2014 14:29:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Simon Martin <furryfuttock@gmail.com>
Message-ID: <20141113192915.GA12502@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<20141113190338.GB11211@laptop.dumpdata.com>
	<1747475571.20141113162148@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1747475571.20141113162148@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 04:21:48PM -0300, Simon Martin wrote:
> Thanks Konrad,
> 
> Thursday, November 13, 2014, 4:03:38 PM, you wrote:
> 
> >> Yes I do verify the write. How do I check this from Dom0?
> 
> > You can crank up the debug volume in xen-pciback. Recompile the kernel
> > and put '#define DEBUG 1' at the start of the .c files.
> 
> > Interestingly enough I saw this issue as well - and it looked to me
> > that Xen pciback was stuck in '7' state (Reconfiguring) and never
> > excited it.
> 
> > But I hadn't had a chance to dig in this.
> 
> This  might  be related to something that I reported a while ago, that
> when   I   shutdown  the PV it takes a long time for the corresponding
> Dom0 processes to stop.
> 
> I'll set the debug level and see what's going on. That'll be on Monday
> now.

Sure thing. Thank you for reporting it!
> 
> 
> -- 
> Best regards,
>  Simon                            mailto:furryfuttock@gmail.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:31:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp06o-0007Vv-4L; Thu, 13 Nov 2014 19:31:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1Xp06m-0007Vn-Gg
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:31:08 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F0/9E-03145-BF605645; Thu, 13 Nov 2014 19:31:07 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415907066!12423195!1
X-Originating-IP: [130.233.192.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5623 invoked from network); 13 Nov 2014 19:31:07 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-8.tower-27.messagelabs.com with SMTP;
	13 Nov 2014 19:31:07 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id C466F308C87;
	Thu, 13 Nov 2014 21:31:05 +0200 (EET)
Message-ID: <546506F8.6080709@iki.fi>
Date: Thu, 13 Nov 2014 19:31:04 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: rumpkernel-users@lists.sourceforge.net, 
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk>
	<5464BB03.7090801@iki.fi>	<20141113154634.GA9560@nodbug.moloch.sk>
	<5464DECB.8090001@iki.fi>	<20141113170726.GB9560@nodbug.moloch.sk>
	<5464E89A.7000908@iki.fi> <20141113185742.GD9560@nodbug.moloch.sk>
In-Reply-To: <20141113185742.GD9560@nodbug.moloch.sk>
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 18:57, Martin Lucina wrote:
>>> Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer
>>> that it's not supposed to be used as a normal /etc.
>>
>> I'd prefer it to be completely hidden from the user.  But sure, call it
>> stubetc for now.
>>
>>> This brings up another question; what to do with resolv.conf, for example?
>>
>> Is resolv.conf an example, i.e. are there other files with similar
>> needs?  Or can we figure out how to handle it as a special case?
>
> Can't think of any. Went and looked in /etc on my laptop to see if anything
> of note gets modified regularly and found nothing besides resolv.conf.
>
> If we want to go down the route of not having a user-visible /etc at all
> (which I think is a good idea) then perhaps we could modify the libc
> resolver to add an API to set the DNS servers directly, which the
> rumpconfig and/or dhcp stuff can call.

user-visible != internally visible.  We can for example build /etc into 
the image as data and mount it as a memory file system at runtime or 
symlink /etc/resolv.conf to /resolv.conf.  I'd completely avoid 
modifying libc until there's a better understanding of the role of /etc 
with experience from dozens of varying applications.  Modifying over 
upstream is a balancing act, because then we stop getting the 
*pre-tested* code for free.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:31:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp06o-0007Vv-4L; Thu, 13 Nov 2014 19:31:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1Xp06m-0007Vn-Gg
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:31:08 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F0/9E-03145-BF605645; Thu, 13 Nov 2014 19:31:07 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415907066!12423195!1
X-Originating-IP: [130.233.192.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5623 invoked from network); 13 Nov 2014 19:31:07 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-8.tower-27.messagelabs.com with SMTP;
	13 Nov 2014 19:31:07 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id C466F308C87;
	Thu, 13 Nov 2014 21:31:05 +0200 (EET)
Message-ID: <546506F8.6080709@iki.fi>
Date: Thu, 13 Nov 2014 19:31:04 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: rumpkernel-users@lists.sourceforge.net, 
	xen-devel@lists.xenproject.org, Ian.Jackson@eu.citrix.com
References: <20141113112202.GB7853@nodbug.moloch.sk>
	<5464BB03.7090801@iki.fi>	<20141113154634.GA9560@nodbug.moloch.sk>
	<5464DECB.8090001@iki.fi>	<20141113170726.GB9560@nodbug.moloch.sk>
	<5464E89A.7000908@iki.fi> <20141113185742.GD9560@nodbug.moloch.sk>
In-Reply-To: <20141113185742.GD9560@nodbug.moloch.sk>
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 18:57, Martin Lucina wrote:
>>> Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer
>>> that it's not supposed to be used as a normal /etc.
>>
>> I'd prefer it to be completely hidden from the user.  But sure, call it
>> stubetc for now.
>>
>>> This brings up another question; what to do with resolv.conf, for example?
>>
>> Is resolv.conf an example, i.e. are there other files with similar
>> needs?  Or can we figure out how to handle it as a special case?
>
> Can't think of any. Went and looked in /etc on my laptop to see if anything
> of note gets modified regularly and found nothing besides resolv.conf.
>
> If we want to go down the route of not having a user-visible /etc at all
> (which I think is a good idea) then perhaps we could modify the libc
> resolver to add an API to set the DNS servers directly, which the
> rumpconfig and/or dhcp stuff can call.

user-visible != internally visible.  We can for example build /etc into 
the image as data and mount it as a memory file system at runtime or 
symlink /etc/resolv.conf to /resolv.conf.  I'd completely avoid 
modifying libc until there's a better understanding of the role of /etc 
with experience from dozens of varying applications.  Modifying over 
upstream is a balancing act, because then we stop getting the 
*pre-tested* code for free.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:32:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp08Q-0007iT-Jv; Thu, 13 Nov 2014 19:32:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xp08P-0007iK-7c
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:32:49 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A8/B1-09936-06705645; Thu, 13 Nov 2014 19:32:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415907166!12599130!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14391 invoked from network); 13 Nov 2014 19:32:47 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:32:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJWbja029097
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:32:38 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJWadO029338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:32:36 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJWa0D029322; Thu, 13 Nov 2014 19:32:36 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:32:36 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B317A116044; Thu, 13 Nov 2014 14:32:32 -0500 (EST)
Date: Thu, 13 Nov 2014 14:32:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20141113193232.GB12502@laptop.dumpdata.com>
References: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 for-xen-4.5] xen_disk: fix unmapping of
 persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 06:42:09PM +0100, Roger Pau Monne wrote:
> This patch fixes two issues with persistent grants and the disk PV backend
> (Qdisk):
> =

>  - Keep track of memory regions where persistent grants have been mapped
>    since we need to unmap them as a whole. It is not possible to unmap a
>    single grant if it has been batch-mapped. A new check has also been ad=
ded
>    to make sure persistent grants are only used if the whole mapped region
>    can be persistently mapped in the batch_maps case.
>  - Unmap persistent grants before switching to the closed state, so the
>    frontend can also free them.
> =

> Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
> Reported-by: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Kevin Wolf <kwolf@redhat.com>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Xen release exception: this is obviously an important bug-fix that should=
 be
> included in 4.5. Without this fix, trying to do a block-detach of a Qdisk
> from a running guest can lead to guest crash depending on the blkfront
> implementation.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

on the spirit of having it in Xen 4.5 - but I am going to let
Stefano decide if he would like to take this version or another one
(if he spots something else that needs fixing).

Thank you!
> ---
> Changea since v2:
>  - Expand the commit message to mention the newly added check.
>  - Don't use persistent_regions in the !batch_maps case, we can use the
>    previous implementation which works fine in that case.
> =

> Changes since v1:
>  - Instead of disabling batch mappings when using persistent grants, keep
>    track of the persistently mapped regions and unmap them on disconnecti=
on.
>    This prevents unmapping single persistent grants, but the current
>    implementation doesn't require it.
> =

> This new version is slightly faster than the previous one, the following
> test results are in IOPS from 20 runs of a block-attach, fio run,
> block-detach test loop:
> =

> x batch
> + no_batch
> +----------------------------------------------------------------------+
> |                                      +   +     x    x + + +  x xx x  |
> |+  +           x                     x+  *+++   *  +x* +++x*  x xx x *|
> |                                          |_____________A_____M______||
> |                            |________________A_____M___________|      |
> +----------------------------------------------------------------------+
>     N           Min           Max        Median           Avg        Stdd=
ev
> x  20         52941         63822         62396      61180.15     2673.64=
97
> +  20         49967         63849         60322       59116.9     3456.34=
55
> Difference at 95.0% confidence
> 	-2063.25 +/- 1977.66
> 	-3.37242% +/- 3.23252%
> 	(Student's t, pooled s =3D 3089.88)
> ---
>  hw/block/xen_disk.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++=
+-----
>  1 file changed, 66 insertions(+), 6 deletions(-)
> =

> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 231e9a7..21842a0 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -59,6 +59,13 @@ struct PersistentGrant {
>  =

>  typedef struct PersistentGrant PersistentGrant;
>  =

> +struct PersistentRegion {
> +    void *addr;
> +    int num;
> +};
> +
> +typedef struct PersistentRegion PersistentRegion;
> +
>  struct ioreq {
>      blkif_request_t     req;
>      int16_t             status;
> @@ -118,6 +125,7 @@ struct XenBlkDev {
>      gboolean            feature_discard;
>      gboolean            feature_persistent;
>      GTree               *persistent_gnts;
> +    GSList              *persistent_regions;
>      unsigned int        persistent_gnt_count;
>      unsigned int        max_grants;
>  =

> @@ -177,6 +185,23 @@ static void destroy_grant(gpointer pgnt)
>      g_free(grant);
>  }
>  =

> +static void remove_persistent_region(gpointer data, gpointer dev)
> +{
> +    PersistentRegion *region =3D data;
> +    struct XenBlkDev *blkdev =3D dev;
> +    XenGnttab gnt =3D blkdev->xendev.gnttabdev;
> +
> +    if (xc_gnttab_munmap(gnt, region->addr, region->num) !=3D 0) {
> +        xen_be_printf(&blkdev->xendev, 0,
> +                      "xc_gnttab_munmap region %p failed: %s\n",
> +                      region->addr, strerror(errno));
> +    }
> +    xen_be_printf(&blkdev->xendev, 3,
> +                  "unmapped grant region %p with %d pages\n",
> +                  region->addr, region->num);
> +    g_free(region);
> +}
> +
>  static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
>  {
>      struct ioreq *ioreq =3D NULL;
> @@ -343,6 +368,7 @@ static int ioreq_map(struct ioreq *ioreq)
>      void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>      int i, j, new_maps =3D 0;
>      PersistentGrant *grant;
> +    PersistentRegion *region;
>      /* domids and refs variables will contain the information necessary
>       * to map the grants that are needed to fulfill this request.
>       *
> @@ -421,7 +447,22 @@ static int ioreq_map(struct ioreq *ioreq)
>              }
>          }
>      }
> -    if (ioreq->blkdev->feature_persistent) {
> +    if (ioreq->blkdev->feature_persistent && new_maps !=3D 0 &&
> +        (!batch_maps || (ioreq->blkdev->persistent_gnt_count + new_maps =
<=3D
> +        ioreq->blkdev->max_grants))) {
> +        /*
> +         * If we are using persistent grants and batch mappings only
> +         * add the new maps to the list of persistent grants if the whole
> +         * area can be persistently mapped.
> +         */
> +        if (batch_maps) {
> +            region =3D g_malloc0(sizeof(*region));
> +            region->addr =3D ioreq->pages;
> +            region->num =3D new_maps;
> +            ioreq->blkdev->persistent_regions =3D g_slist_append(
> +                                            ioreq->blkdev->persistent_re=
gions,
> +                                            region);
> +        }
>          while ((ioreq->blkdev->persistent_gnt_count < ioreq->blkdev->max=
_grants)
>                && new_maps) {
>              /* Go through the list of newly mapped grants and add as many
> @@ -447,6 +488,7 @@ static int ioreq_map(struct ioreq *ioreq)
>                            grant);
>              ioreq->blkdev->persistent_gnt_count++;
>          }
> +        assert(!batch_maps || new_maps =3D=3D 0);
>      }
>      for (i =3D 0; i < ioreq->v.niov; i++) {
>          ioreq->v.iov[i].iov_base +=3D (uintptr_t)page[i];
> @@ -971,7 +1013,10 @@ static int blk_connect(struct XenDevice *xendev)
>          blkdev->max_grants =3D max_requests * BLKIF_MAX_SEGMENTS_PER_REQ=
UEST;
>          blkdev->persistent_gnts =3D g_tree_new_full((GCompareDataFunc)in=
t_cmp,
>                                               NULL, NULL,
> +                                             batch_maps ?
> +                                             (GDestroyNotify)g_free :
>                                               (GDestroyNotify)destroy_gra=
nt);
> +        blkdev->persistent_regions =3D NULL;
>          blkdev->persistent_gnt_count =3D 0;
>      }
>  =

> @@ -1000,6 +1045,26 @@ static void blk_disconnect(struct XenDevice *xende=
v)
>          blkdev->cnt_map--;
>          blkdev->sring =3D NULL;
>      }
> +
> +    /*
> +     * Unmap persistent grants before switching to the closed state
> +     * so the frontend can free them.
> +     *
> +     * In the !batch_maps case g_tree_destroy will take care of unmapping
> +     * the grant, but in the batch_maps case we need to iterate over eve=
ry
> +     * region in persistent_regions and unmap it.
> +     */
> +    if (blkdev->feature_persistent) {
> +        g_tree_destroy(blkdev->persistent_gnts);
> +        assert(batch_maps || blkdev->persistent_gnt_count =3D=3D 0);
> +        if (batch_maps) {
> +            blkdev->persistent_gnt_count =3D 0;
> +            g_slist_foreach(blkdev->persistent_regions,
> +                            (GFunc)remove_persistent_region, blkdev);
> +            g_slist_free(blkdev->persistent_regions);
> +        }
> +        blkdev->feature_persistent =3D false;
> +    }
>  }
>  =

>  static int blk_free(struct XenDevice *xendev)
> @@ -1011,11 +1076,6 @@ static int blk_free(struct XenDevice *xendev)
>          blk_disconnect(xendev);
>      }
>  =

> -    /* Free persistent grants */
> -    if (blkdev->feature_persistent) {
> -        g_tree_destroy(blkdev->persistent_gnts);
> -    }
> -
>      while (!QLIST_EMPTY(&blkdev->freelist)) {
>          ioreq =3D QLIST_FIRST(&blkdev->freelist);
>          QLIST_REMOVE(ioreq, list);
> -- =

> 1.9.3 (Apple Git-50)
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:32:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp08Q-0007iT-Jv; Thu, 13 Nov 2014 19:32:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xp08P-0007iK-7c
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 19:32:49 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A8/B1-09936-06705645; Thu, 13 Nov 2014 19:32:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415907166!12599130!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14391 invoked from network); 13 Nov 2014 19:32:47 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:32:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJWbja029097
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:32:38 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJWadO029338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:32:36 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJWa0D029322; Thu, 13 Nov 2014 19:32:36 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:32:36 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B317A116044; Thu, 13 Nov 2014 14:32:32 -0500 (EST)
Date: Thu, 13 Nov 2014 14:32:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20141113193232.GB12502@laptop.dumpdata.com>
References: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 for-xen-4.5] xen_disk: fix unmapping of
 persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 06:42:09PM +0100, Roger Pau Monne wrote:
> This patch fixes two issues with persistent grants and the disk PV backend
> (Qdisk):
> =

>  - Keep track of memory regions where persistent grants have been mapped
>    since we need to unmap them as a whole. It is not possible to unmap a
>    single grant if it has been batch-mapped. A new check has also been ad=
ded
>    to make sure persistent grants are only used if the whole mapped region
>    can be persistently mapped in the batch_maps case.
>  - Unmap persistent grants before switching to the closed state, so the
>    frontend can also free them.
> =

> Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
> Reported-by: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Kevin Wolf <kwolf@redhat.com>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Xen release exception: this is obviously an important bug-fix that should=
 be
> included in 4.5. Without this fix, trying to do a block-detach of a Qdisk
> from a running guest can lead to guest crash depending on the blkfront
> implementation.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

on the spirit of having it in Xen 4.5 - but I am going to let
Stefano decide if he would like to take this version or another one
(if he spots something else that needs fixing).

Thank you!
> ---
> Changea since v2:
>  - Expand the commit message to mention the newly added check.
>  - Don't use persistent_regions in the !batch_maps case, we can use the
>    previous implementation which works fine in that case.
> =

> Changes since v1:
>  - Instead of disabling batch mappings when using persistent grants, keep
>    track of the persistently mapped regions and unmap them on disconnecti=
on.
>    This prevents unmapping single persistent grants, but the current
>    implementation doesn't require it.
> =

> This new version is slightly faster than the previous one, the following
> test results are in IOPS from 20 runs of a block-attach, fio run,
> block-detach test loop:
> =

> x batch
> + no_batch
> +----------------------------------------------------------------------+
> |                                      +   +     x    x + + +  x xx x  |
> |+  +           x                     x+  *+++   *  +x* +++x*  x xx x *|
> |                                          |_____________A_____M______||
> |                            |________________A_____M___________|      |
> +----------------------------------------------------------------------+
>     N           Min           Max        Median           Avg        Stdd=
ev
> x  20         52941         63822         62396      61180.15     2673.64=
97
> +  20         49967         63849         60322       59116.9     3456.34=
55
> Difference at 95.0% confidence
> 	-2063.25 +/- 1977.66
> 	-3.37242% +/- 3.23252%
> 	(Student's t, pooled s =3D 3089.88)
> ---
>  hw/block/xen_disk.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++=
+-----
>  1 file changed, 66 insertions(+), 6 deletions(-)
> =

> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 231e9a7..21842a0 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -59,6 +59,13 @@ struct PersistentGrant {
>  =

>  typedef struct PersistentGrant PersistentGrant;
>  =

> +struct PersistentRegion {
> +    void *addr;
> +    int num;
> +};
> +
> +typedef struct PersistentRegion PersistentRegion;
> +
>  struct ioreq {
>      blkif_request_t     req;
>      int16_t             status;
> @@ -118,6 +125,7 @@ struct XenBlkDev {
>      gboolean            feature_discard;
>      gboolean            feature_persistent;
>      GTree               *persistent_gnts;
> +    GSList              *persistent_regions;
>      unsigned int        persistent_gnt_count;
>      unsigned int        max_grants;
>  =

> @@ -177,6 +185,23 @@ static void destroy_grant(gpointer pgnt)
>      g_free(grant);
>  }
>  =

> +static void remove_persistent_region(gpointer data, gpointer dev)
> +{
> +    PersistentRegion *region =3D data;
> +    struct XenBlkDev *blkdev =3D dev;
> +    XenGnttab gnt =3D blkdev->xendev.gnttabdev;
> +
> +    if (xc_gnttab_munmap(gnt, region->addr, region->num) !=3D 0) {
> +        xen_be_printf(&blkdev->xendev, 0,
> +                      "xc_gnttab_munmap region %p failed: %s\n",
> +                      region->addr, strerror(errno));
> +    }
> +    xen_be_printf(&blkdev->xendev, 3,
> +                  "unmapped grant region %p with %d pages\n",
> +                  region->addr, region->num);
> +    g_free(region);
> +}
> +
>  static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
>  {
>      struct ioreq *ioreq =3D NULL;
> @@ -343,6 +368,7 @@ static int ioreq_map(struct ioreq *ioreq)
>      void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>      int i, j, new_maps =3D 0;
>      PersistentGrant *grant;
> +    PersistentRegion *region;
>      /* domids and refs variables will contain the information necessary
>       * to map the grants that are needed to fulfill this request.
>       *
> @@ -421,7 +447,22 @@ static int ioreq_map(struct ioreq *ioreq)
>              }
>          }
>      }
> -    if (ioreq->blkdev->feature_persistent) {
> +    if (ioreq->blkdev->feature_persistent && new_maps !=3D 0 &&
> +        (!batch_maps || (ioreq->blkdev->persistent_gnt_count + new_maps =
<=3D
> +        ioreq->blkdev->max_grants))) {
> +        /*
> +         * If we are using persistent grants and batch mappings only
> +         * add the new maps to the list of persistent grants if the whole
> +         * area can be persistently mapped.
> +         */
> +        if (batch_maps) {
> +            region =3D g_malloc0(sizeof(*region));
> +            region->addr =3D ioreq->pages;
> +            region->num =3D new_maps;
> +            ioreq->blkdev->persistent_regions =3D g_slist_append(
> +                                            ioreq->blkdev->persistent_re=
gions,
> +                                            region);
> +        }
>          while ((ioreq->blkdev->persistent_gnt_count < ioreq->blkdev->max=
_grants)
>                && new_maps) {
>              /* Go through the list of newly mapped grants and add as many
> @@ -447,6 +488,7 @@ static int ioreq_map(struct ioreq *ioreq)
>                            grant);
>              ioreq->blkdev->persistent_gnt_count++;
>          }
> +        assert(!batch_maps || new_maps =3D=3D 0);
>      }
>      for (i =3D 0; i < ioreq->v.niov; i++) {
>          ioreq->v.iov[i].iov_base +=3D (uintptr_t)page[i];
> @@ -971,7 +1013,10 @@ static int blk_connect(struct XenDevice *xendev)
>          blkdev->max_grants =3D max_requests * BLKIF_MAX_SEGMENTS_PER_REQ=
UEST;
>          blkdev->persistent_gnts =3D g_tree_new_full((GCompareDataFunc)in=
t_cmp,
>                                               NULL, NULL,
> +                                             batch_maps ?
> +                                             (GDestroyNotify)g_free :
>                                               (GDestroyNotify)destroy_gra=
nt);
> +        blkdev->persistent_regions =3D NULL;
>          blkdev->persistent_gnt_count =3D 0;
>      }
>  =

> @@ -1000,6 +1045,26 @@ static void blk_disconnect(struct XenDevice *xende=
v)
>          blkdev->cnt_map--;
>          blkdev->sring =3D NULL;
>      }
> +
> +    /*
> +     * Unmap persistent grants before switching to the closed state
> +     * so the frontend can free them.
> +     *
> +     * In the !batch_maps case g_tree_destroy will take care of unmapping
> +     * the grant, but in the batch_maps case we need to iterate over eve=
ry
> +     * region in persistent_regions and unmap it.
> +     */
> +    if (blkdev->feature_persistent) {
> +        g_tree_destroy(blkdev->persistent_gnts);
> +        assert(batch_maps || blkdev->persistent_gnt_count =3D=3D 0);
> +        if (batch_maps) {
> +            blkdev->persistent_gnt_count =3D 0;
> +            g_slist_foreach(blkdev->persistent_regions,
> +                            (GFunc)remove_persistent_region, blkdev);
> +            g_slist_free(blkdev->persistent_regions);
> +        }
> +        blkdev->feature_persistent =3D false;
> +    }
>  }
>  =

>  static int blk_free(struct XenDevice *xendev)
> @@ -1011,11 +1076,6 @@ static int blk_free(struct XenDevice *xendev)
>          blk_disconnect(xendev);
>      }
>  =

> -    /* Free persistent grants */
> -    if (blkdev->feature_persistent) {
> -        g_tree_destroy(blkdev->persistent_gnts);
> -    }
> -
>      while (!QLIST_EMPTY(&blkdev->freelist)) {
>          ioreq =3D QLIST_FIRST(&blkdev->freelist);
>          QLIST_REMOVE(ioreq, list);
> -- =

> 1.9.3 (Apple Git-50)
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:52:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:52:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp0RN-0008J2-Rr; Thu, 13 Nov 2014 19:52:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xp0RM-0008Ix-HP
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 19:52:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	83/3F-09936-7FB05645; Thu, 13 Nov 2014 19:52:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415908340!12618815!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19795 invoked from network); 13 Nov 2014 19:52:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 19:52:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="191125230"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 14:52:15 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xp0RD-0003lz-Kp;
	Thu, 13 Nov 2014 19:52:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xp0RD-0005Iu-Bn;
	Thu, 13 Nov 2014 19:52:15 +0000
Date: Thu, 13 Nov 2014 19:52:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31506-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31506: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31506 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31506/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot            fail pass in 31481

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 31481 like 30761

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 seabios              09f876f11743c1143c73a52eb889ae9231f7a5b3
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Hannes Reinecke <hare@suse.de>
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 337 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:52:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:52:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp0RN-0008J2-Rr; Thu, 13 Nov 2014 19:52:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xp0RM-0008Ix-HP
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 19:52:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	83/3F-09936-7FB05645; Thu, 13 Nov 2014 19:52:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415908340!12618815!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19795 invoked from network); 13 Nov 2014 19:52:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 19:52:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="191125230"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 14:52:15 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xp0RD-0003lz-Kp;
	Thu, 13 Nov 2014 19:52:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xp0RD-0005Iu-Bn;
	Thu, 13 Nov 2014 19:52:15 +0000
Date: Thu, 13 Nov 2014 19:52:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31506-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31506: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31506 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31506/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30767

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot            fail pass in 31481

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 31481 like 30761

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 seabios              09f876f11743c1143c73a52eb889ae9231f7a5b3
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Hannes Reinecke <hare@suse.de>
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 337 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:54:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:54:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp0TY-00007B-CP; Thu, 13 Nov 2014 19:54:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xp0TW-000075-Kb
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 19:54:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B0/87-09842-E7C05645; Thu, 13 Nov 2014 19:54:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415908475!4558409!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14644 invoked from network); 13 Nov 2014 19:54:37 -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 Nov 2014 19:54:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="191126072"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 14:54:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xp0TP-0003mY-J1;
	Thu, 13 Nov 2014 19:54:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xp0TP-00075n-A4;
	Thu, 13 Nov 2014 19:54:31 +0000
Date: Thu, 13 Nov 2014 19:54:31 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31531-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31531: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31531 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31531/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:54:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:54:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp0TY-00007B-CP; Thu, 13 Nov 2014 19:54:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xp0TW-000075-Kb
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 19:54:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B0/87-09842-E7C05645; Thu, 13 Nov 2014 19:54:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415908475!4558409!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14644 invoked from network); 13 Nov 2014 19:54:37 -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 Nov 2014 19:54:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="scan'208";a="191126072"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 14:54:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xp0TP-0003mY-J1;
	Thu, 13 Nov 2014 19:54:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xp0TP-00075n-A4;
	Thu, 13 Nov 2014 19:54:31 +0000
Date: Thu, 13 Nov 2014 19:54:31 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31531-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31531: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31531 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31531/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:56:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp0VI-0000Er-S6; Thu, 13 Nov 2014 19:56:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xp0VH-0000Eg-3r
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 19:56:27 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	B3/C9-02953-AEC05645; Thu, 13 Nov 2014 19:56:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415908584!9070489!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31926 invoked from network); 13 Nov 2014 19:56:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:56:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJu9Up013759
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:56:10 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sADJu8Xd016951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:56:08 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJu7RF021139; Thu, 13 Nov 2014 19:56:07 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:56:07 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 79CE7116076; Thu, 13 Nov 2014 14:56:06 -0500 (EST)
Date: Thu, 13 Nov 2014 14:56:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141113195605.GA13039@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54644E48.3040506@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

> >>+	mfn_save = virt_to_mfn(buf);
> >>+
> >>+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
> >
> >So the 'list' is constructed by going forward - that is from low-numbered
> >PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
> >other way - from the highest PFN to the lowest PFN.
> >
> >Won't that mean we will restore the chunks of memory in the wrong
> >order? That is we will still restore them in chunks size, but the
> >chunks will be in descending order instead of ascending?
> 
> No, the information where to put each chunk is contained in the chunk
> data. I can add a comment explaining this.

Right, the MFNs in a "chunks" are going to be restored in the right order.

I was thinking that the "chunks" (so a set of MFNs) will be restored in
the opposite order that they are written to. 

And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?

> 
> >
> >>+		/* Map the remap information */
> >>+		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
> >>+
> >>+		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
> >>+
> >>+		free = 0;
> >>+		pfn = xen_remap_buf.target_pfn;
> >>+		for (i = 0; i < xen_remap_buf.size; i++) {
> >>+			mfn = xen_remap_buf.mfns[i];
> >>+			if (!released && xen_update_mem_tables(pfn, mfn)) {
> >>+				remapped++;
> >
> >If we fail 'xen_update_mem_tables' we will on the next chunk (so i+1) keep on
> >freeing pages instead of trying to remap. Is that intentional? Could we
> >try to remap?
> 
> Hmm, I'm not sure this is worth the effort. What could lead to failure
> here? I suspect we could even just BUG() on failure. What do you think?

I was hoping that this question would lead to making this loop a bit
simpler as you would have to spread some of the code in the loop
into functions.

And keep 'remmaped' and 'released' reset every loop.

However, if it makes the code more complex - then please
forget my question.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:56:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp0VI-0000Er-S6; Thu, 13 Nov 2014 19:56:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xp0VH-0000Eg-3r
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 19:56:27 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	B3/C9-02953-AEC05645; Thu, 13 Nov 2014 19:56:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415908584!9070489!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31926 invoked from network); 13 Nov 2014 19:56:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:56:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJu9Up013759
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:56:10 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sADJu8Xd016951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 19:56:08 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJu7RF021139; Thu, 13 Nov 2014 19:56:07 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:56:07 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 79CE7116076; Thu, 13 Nov 2014 14:56:06 -0500 (EST)
Date: Thu, 13 Nov 2014 14:56:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141113195605.GA13039@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54644E48.3040506@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

> >>+	mfn_save = virt_to_mfn(buf);
> >>+
> >>+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
> >
> >So the 'list' is constructed by going forward - that is from low-numbered
> >PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
> >other way - from the highest PFN to the lowest PFN.
> >
> >Won't that mean we will restore the chunks of memory in the wrong
> >order? That is we will still restore them in chunks size, but the
> >chunks will be in descending order instead of ascending?
> 
> No, the information where to put each chunk is contained in the chunk
> data. I can add a comment explaining this.

Right, the MFNs in a "chunks" are going to be restored in the right order.

I was thinking that the "chunks" (so a set of MFNs) will be restored in
the opposite order that they are written to. 

And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?

> 
> >
> >>+		/* Map the remap information */
> >>+		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
> >>+
> >>+		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
> >>+
> >>+		free = 0;
> >>+		pfn = xen_remap_buf.target_pfn;
> >>+		for (i = 0; i < xen_remap_buf.size; i++) {
> >>+			mfn = xen_remap_buf.mfns[i];
> >>+			if (!released && xen_update_mem_tables(pfn, mfn)) {
> >>+				remapped++;
> >
> >If we fail 'xen_update_mem_tables' we will on the next chunk (so i+1) keep on
> >freeing pages instead of trying to remap. Is that intentional? Could we
> >try to remap?
> 
> Hmm, I'm not sure this is worth the effort. What could lead to failure
> here? I suspect we could even just BUG() on failure. What do you think?

I was hoping that this question would lead to making this loop a bit
simpler as you would have to spread some of the code in the loop
into functions.

And keep 'remmaped' and 'released' reset every loop.

However, if it makes the code more complex - then please
forget my question.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:56:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19: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 1Xp0VW-0000HA-8W; Thu, 13 Nov 2014 19:56:42 +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 1Xp0VV-0000Gy-9b
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 19:56:41 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	EA/17-22737-8FC05645; Thu, 13 Nov 2014 19:56:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415908598!11226491!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3523 invoked from network); 13 Nov 2014 19:56:39 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:56:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJuPdj014085
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:56:26 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJuOV2015692
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Nov 2014 19:56:25 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sADJuNqp017874; Thu, 13 Nov 2014 19:56:24 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:56:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E7CA0116078; Thu, 13 Nov 2014 14:56:21 -0500 (EST)
Date: Thu, 13 Nov 2014 14:56:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141113195621.GB13039@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-5-git-send-email-jgross@suse.com>
	<20141112221021.GC7549@laptop.dumpdata.com>
	<54645474.4040605@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54645474.4040605@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 4/8] xen: Delay invalidating extra memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 07:49:24AM +0100, Juergen Gross wrote:
> On 11/12/2014 11:10 PM, Konrad Rzeszutek Wilk wrote:
> >>@@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
> >>  	unsigned long max_pfn;
> >>  	unsigned long pfn;
> >>
> >>-	 if (xen_feature(XENFEAT_auto_translated_physmap))
> >>+	if (xen_feature(XENFEAT_auto_translated_physmap))
> >
> >Spurious change.
> 
> I'll remove it.
> 
> >
> >.. snip..
> >>diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> >>index 0e5f9b6..8d5985b 100644
> >>--- a/arch/x86/xen/setup.c
> >>+++ b/arch/x86/xen/setup.c
> >>@@ -75,7 +75,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
> >>
> >>  static void __init xen_add_extra_mem(u64 start, u64 size)
> >>  {
> >>-	unsigned long pfn;
> >>  	int i;
> >>
> >>  	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
> >>@@ -95,17 +94,74 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
> >>  		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
> >>
> >>  	memblock_reserve(start, size);
> >>+}
> >>
> >>-	xen_max_p2m_pfn = PFN_DOWN(start + size);
> >>-	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
> >>-		unsigned long mfn = pfn_to_mfn(pfn);
> >>+static void __init xen_del_extra_mem(u64 start, u64 size)
> >>+{
> >>+	int i;
> >>+	u64 start_r, size_r;
> >>
> >>-		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
> >>-			continue;
> >>-		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
> >>-			  pfn, mfn);
> >>+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
> >>+		start_r = xen_extra_mem[i].start;
> >>+		size_r = xen_extra_mem[i].size;
> >>+
> >>+		/* Start of region. */
> >>+		if (start_r == start) {
> >>+			BUG_ON(size > size_r);
> >>+			xen_extra_mem[i].start += size;
> >>+			xen_extra_mem[i].size -= size;
> >>+			break;
> >>+		}
> >>+		/* End of region. */
> >>+		if (start_r + size_r == start + size) {
> >>+			BUG_ON(size > size_r);
> >>+			xen_extra_mem[i].size -= size;
> >>+			break;
> >>+		}
> >>+		/* Mid of region. */
> >>+		if (start > start_r && start < start_r + size_r) {
> >>+			BUG_ON(start + size > start_r + size_r);
> >>+			xen_extra_mem[i].size = start - start_r;
> >>+			xen_add_extra_mem(start + size, start_r + size_r -
> >>+					  (start + size));
> >
> >Which ends up calling 'memblock_reserve' for an region it already has
> >reserved. Should we call memblock_free(start_r, size_r - size) before calling this?
> >
> >Or is that not neccessary as memblock_* is pretty smart about this sort of thing?
> 
> Regions marked via memblock_reserve() are allowed to overlap. I can add
> a comment.

Thank you!
> 
> 
> Juergen
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 19:56:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 19: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 1Xp0VW-0000HA-8W; Thu, 13 Nov 2014 19:56:42 +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 1Xp0VV-0000Gy-9b
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 19:56:41 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	EA/17-22737-8FC05645; Thu, 13 Nov 2014 19:56:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415908598!11226491!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3523 invoked from network); 13 Nov 2014 19:56:39 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 19:56:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADJuPdj014085
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 19:56:26 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADJuOV2015692
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Nov 2014 19:56:25 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sADJuNqp017874; Thu, 13 Nov 2014 19:56:24 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 11:56:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E7CA0116078; Thu, 13 Nov 2014 14:56:21 -0500 (EST)
Date: Thu, 13 Nov 2014 14:56:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141113195621.GB13039@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-5-git-send-email-jgross@suse.com>
	<20141112221021.GC7549@laptop.dumpdata.com>
	<54645474.4040605@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54645474.4040605@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 4/8] xen: Delay invalidating extra memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 07:49:24AM +0100, Juergen Gross wrote:
> On 11/12/2014 11:10 PM, Konrad Rzeszutek Wilk wrote:
> >>@@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
> >>  	unsigned long max_pfn;
> >>  	unsigned long pfn;
> >>
> >>-	 if (xen_feature(XENFEAT_auto_translated_physmap))
> >>+	if (xen_feature(XENFEAT_auto_translated_physmap))
> >
> >Spurious change.
> 
> I'll remove it.
> 
> >
> >.. snip..
> >>diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> >>index 0e5f9b6..8d5985b 100644
> >>--- a/arch/x86/xen/setup.c
> >>+++ b/arch/x86/xen/setup.c
> >>@@ -75,7 +75,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
> >>
> >>  static void __init xen_add_extra_mem(u64 start, u64 size)
> >>  {
> >>-	unsigned long pfn;
> >>  	int i;
> >>
> >>  	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
> >>@@ -95,17 +94,74 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
> >>  		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
> >>
> >>  	memblock_reserve(start, size);
> >>+}
> >>
> >>-	xen_max_p2m_pfn = PFN_DOWN(start + size);
> >>-	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
> >>-		unsigned long mfn = pfn_to_mfn(pfn);
> >>+static void __init xen_del_extra_mem(u64 start, u64 size)
> >>+{
> >>+	int i;
> >>+	u64 start_r, size_r;
> >>
> >>-		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
> >>-			continue;
> >>-		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
> >>-			  pfn, mfn);
> >>+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
> >>+		start_r = xen_extra_mem[i].start;
> >>+		size_r = xen_extra_mem[i].size;
> >>+
> >>+		/* Start of region. */
> >>+		if (start_r == start) {
> >>+			BUG_ON(size > size_r);
> >>+			xen_extra_mem[i].start += size;
> >>+			xen_extra_mem[i].size -= size;
> >>+			break;
> >>+		}
> >>+		/* End of region. */
> >>+		if (start_r + size_r == start + size) {
> >>+			BUG_ON(size > size_r);
> >>+			xen_extra_mem[i].size -= size;
> >>+			break;
> >>+		}
> >>+		/* Mid of region. */
> >>+		if (start > start_r && start < start_r + size_r) {
> >>+			BUG_ON(start + size > start_r + size_r);
> >>+			xen_extra_mem[i].size = start - start_r;
> >>+			xen_add_extra_mem(start + size, start_r + size_r -
> >>+					  (start + size));
> >
> >Which ends up calling 'memblock_reserve' for an region it already has
> >reserved. Should we call memblock_free(start_r, size_r - size) before calling this?
> >
> >Or is that not neccessary as memblock_* is pretty smart about this sort of thing?
> 
> Regions marked via memblock_reserve() are allowed to overlap. I can add
> a comment.

Thank you!
> 
> 
> Juergen
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 20:02:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 20:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp0ae-0000o2-0h; Thu, 13 Nov 2014 20:02:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xp0ac-0000kI-Kd
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 20:01:58 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	17/D3-03145-53E05645; Thu, 13 Nov 2014 20:01:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415908915!12414187!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3912 invoked from network); 13 Nov 2014 20:01:57 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 20:01:57 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADK1g8e032645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 20:01:42 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sADK1fKu007082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 20:01:41 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADK1eMI004199; Thu, 13 Nov 2014 20:01:41 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 12:01:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 35D68116081; Thu, 13 Nov 2014 15:01:39 -0500 (EST)
Date: Thu, 13 Nov 2014 15:01:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>, mingo@redhat.com
Message-ID: <20141113200139.GC13039@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-6-git-send-email-jgross@suse.com>
	<20141112221204.GD7549@laptop.dumpdata.com>
	<546455C1.6000405@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546455C1.6000405@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 5/8] x86: Introduce function to get pmd
	entry pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 07:54:57AM +0100, Juergen Gross wrote:
> On 11/12/2014 11:12 PM, Konrad Rzeszutek Wilk wrote:
> >On Tue, Nov 11, 2014 at 06:43:43AM +0100, Juergen Gross wrote:
> >>Introduces lookup_pmd_address() to get the address of the pmd entry
> >>related to a virtual address in the current address space. This
> >>function is needed for support of a virtual mapped sparse p2m list
> >>in xen pv domains.
> >>
> >What is wrong with using 'lookup_address' ?
> 
> It doesn't return the needed information. I need a pmd entry here, not
> a pte entry.

Thank you.

I believe that explanation ought to be part of the
commit description.

Could this code be merged with lookup_address_in_pgd -
perhaps by having an extra flag that would give it an OK
to return the PMD instead of walking down the tree?

Ingo, any preference for this?

Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 20:02:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 20:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp0ae-0000o2-0h; Thu, 13 Nov 2014 20:02:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xp0ac-0000kI-Kd
	for xen-devel@lists.xensource.com; Thu, 13 Nov 2014 20:01:58 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	17/D3-03145-53E05645; Thu, 13 Nov 2014 20:01:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415908915!12414187!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3912 invoked from network); 13 Nov 2014 20:01:57 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 20:01:57 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sADK1g8e032645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Nov 2014 20:01:42 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sADK1fKu007082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 13 Nov 2014 20:01:41 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sADK1eMI004199; Thu, 13 Nov 2014 20:01:41 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Nov 2014 12:01:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 35D68116081; Thu, 13 Nov 2014 15:01:39 -0500 (EST)
Date: Thu, 13 Nov 2014 15:01:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>, mingo@redhat.com
Message-ID: <20141113200139.GC13039@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-6-git-send-email-jgross@suse.com>
	<20141112221204.GD7549@laptop.dumpdata.com>
	<546455C1.6000405@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546455C1.6000405@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 5/8] x86: Introduce function to get pmd
	entry pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 07:54:57AM +0100, Juergen Gross wrote:
> On 11/12/2014 11:12 PM, Konrad Rzeszutek Wilk wrote:
> >On Tue, Nov 11, 2014 at 06:43:43AM +0100, Juergen Gross wrote:
> >>Introduces lookup_pmd_address() to get the address of the pmd entry
> >>related to a virtual address in the current address space. This
> >>function is needed for support of a virtual mapped sparse p2m list
> >>in xen pv domains.
> >>
> >What is wrong with using 'lookup_address' ?
> 
> It doesn't return the needed information. I need a pmd entry here, not
> a pte entry.

Thank you.

I believe that explanation ought to be part of the
commit description.

Could this code be merged with lookup_address_in_pgd -
perhaps by having an extra flag that would give it an OK
to return the PMD instead of walking down the tree?

Ingo, any preference for this?

Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 20:09:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 20:09:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp0hu-0000zg-RK; Thu, 13 Nov 2014 20:09:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xp0ht-0000zb-Gm
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 20:09:29 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D6/E0-02696-8FF05645; Thu, 13 Nov 2014 20:09:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415909368!12392722!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24109 invoked from network); 13 Nov 2014 20:09:28 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 20:09:28 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xp0hX-0003cz-4Y; Thu, 13 Nov 2014 20:09:07 +0000
Date: Thu, 13 Nov 2014 21:09:07 +0100
From: Tim Deegan <tim@xen.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141113200907.GA13359@deinos.phlegethon.org>
References: <1415894589-18256-1-git-send-email-tim@xen.org>
	<5464E80202000078000474B1@mail.emea.novell.com>
	<20141113191816.GC11727@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141113191816.GC11727@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, keir@xen.org,
	ian.campbell@citrix.com, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] xen: remove Xencomm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:18 -0500 on 13 Nov (1415884696), Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 13, 2014 at 04:18:58PM +0000, Jan Beulich wrote:
> > >>> On 13.11.14 at 17:03, <tim@xen.org> wrote:
> > > Being a feature that has only been used by ia64 and/or ppc it
> > > doesn't seem like we need to keep it any longer in the tree.
> > > 
> > > So remove it.
> > > 
> > > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> Are folks OK if this is deferred to Xen 4.6?

Yes, sure.  I'll queue it up for committing after the branch.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 20:09:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 20:09:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp0hu-0000zg-RK; Thu, 13 Nov 2014 20:09:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xp0ht-0000zb-Gm
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 20:09:29 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D6/E0-02696-8FF05645; Thu, 13 Nov 2014 20:09:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415909368!12392722!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24109 invoked from network); 13 Nov 2014 20:09:28 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Nov 2014 20:09:28 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xp0hX-0003cz-4Y; Thu, 13 Nov 2014 20:09:07 +0000
Date: Thu, 13 Nov 2014 21:09:07 +0100
From: Tim Deegan <tim@xen.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141113200907.GA13359@deinos.phlegethon.org>
References: <1415894589-18256-1-git-send-email-tim@xen.org>
	<5464E80202000078000474B1@mail.emea.novell.com>
	<20141113191816.GC11727@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141113191816.GC11727@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, keir@xen.org,
	ian.campbell@citrix.com, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] xen: remove Xencomm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:18 -0500 on 13 Nov (1415884696), Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 13, 2014 at 04:18:58PM +0000, Jan Beulich wrote:
> > >>> On 13.11.14 at 17:03, <tim@xen.org> wrote:
> > > Being a feature that has only been used by ia64 and/or ppc it
> > > doesn't seem like we need to keep it any longer in the tree.
> > > 
> > > So remove it.
> > > 
> > > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> Are folks OK if this is deferred to Xen 4.6?

Yes, sure.  I'll queue it up for committing after the branch.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 21:57:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 21:57:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp2NT-0003aM-3z; Thu, 13 Nov 2014 21:56:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justin@specialbusservice.com>) id 1Xp2NR-0003aH-NM
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 21:56:29 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	3C/84-07724-C0925645; Thu, 13 Nov 2014 21:56:28 +0000
X-Env-Sender: justin@specialbusservice.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415915787!11265168!1
X-Originating-IP: [209.85.217.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29656 invoked from network); 13 Nov 2014 21:56:27 -0000
Received: from mail-lb0-f182.google.com (HELO mail-lb0-f182.google.com)
	(209.85.217.182)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 21:56:27 -0000
Received: by mail-lb0-f182.google.com with SMTP id f15so12780354lbj.41
	for <xen-devel@lists.xenproject.org>;
	Thu, 13 Nov 2014 13:56:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=specialbusservice.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=sTKURYesCANlFRYGgbhxD3Peg8kGwv0R7+lX9G+o6C0=;
	b=opb8m5ftE7urh3GU/qfr4ooXUQX/e/8uLSXm51jGLaewxyJQG5NrZv82VDFi6BPp+j
	ftCmDVUNF2lwGclEDoiuCiXmqxDLYmJfUtMWfDNmA5RsFV80ow2eKBat7RgX7C7QaqGj
	U79T8KsuzEJBgtEzDtzYdEZrZJf/wt+9iqGTA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=sTKURYesCANlFRYGgbhxD3Peg8kGwv0R7+lX9G+o6C0=;
	b=E43BZEQixt/GjZJWASIy9v9jkJwiunQmz13MO2st4M2tGrfOuxTYxU1Lj2xNk9+lFY
	Ee8utR74TeCYDuJA2H4AQCiloE5eQHvMmMrOU/DZAsh3Wl9++NBGCTgQp+KmEcuf0HYe
	LDpA+VqzYjbq4vXAv67421V8/JwjmuE9EYEpESpOkSxHgevwPM6TuP+luJRWRNZ7BJGR
	84BKZEWK+kgnTmhgz0g577CrkupYm/CQ+SQwqUl/lxnL8r8eMAB0RuKI/IJp5JduGcRw
	pSGmOXvHElyrrWPdAG5+BuSQCJL18tHA1ytkxizuHZrdtB/MUkKt+t+fQoAI0tCo5jWy
	UoWw==
X-Gm-Message-State: ALoCoQlRX+XS5EAlwJvGY/jO49atDVODpwubbOq/8Gur1hojhdNC6Qaw/7D0g0SeuYqDcIYp4jqX
MIME-Version: 1.0
X-Received: by 10.112.135.229 with SMTP id pv5mr4714216lbb.52.1415915786957;
	Thu, 13 Nov 2014 13:56:26 -0800 (PST)
Received: by 10.152.0.197 with HTTP; Thu, 13 Nov 2014 13:56:26 -0800 (PST)
In-Reply-To: <20141113154634.GA9560@nodbug.moloch.sk>
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk>
Date: Thu, 13 Nov 2014 21:56:26 +0000
Message-ID: <CAK4o1WwwYt05sGe+-9zEqwpzbz+mvG7YMYLwJcn-oDR6AZg55Q@mail.gmail.com>
From: Justin Cormack <justin@specialbusservice.com>
To: "rumpkernel-users@lists.sourceforge.net"
	<rumpkernel-users@lists.sourceforge.net>, xen-devel@lists.xenproject.org, 
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 3:46 PM, Martin Lucina <martin@lucina.net> wrote:
>> > Following is the high-level description from the Git commit:
>>
>> Can you also post an example of the usage of your CLI tool?  Actually,
>> can you post a rough description of the entire process that a user would
>> have to follow, i.e. compile, configure, run.
>
> Running "xr" with no parameters gives a nice command reference :-)
>
> Anyhow:
>
> Simple hello world using tests/hello/hello built as part of buildxen.sh:
>
>  # xr run -i tests/hello/hello
>
> Running a webserver:
>
> Get mathopd source from http://mathopd.org/. I used mathopd as it's BSD
> licensed, non-forking and small. To build and run it:
>
> 1. git clone, buildxen.sh
>
> 2. Put app-tools at the *END* of your $PATH. There is a bug/interaction
> with the app-tools ld that breaks things if you put it before the real ld.
>
> 3. (in mathopd/src) rumpapp-xen-make
>
> 4. You need filesystem images for a stub /etc and /data. I am using cd9660
> for these as you can portably generate that anywhere you have genisoimage
> (ex mkisofs). (see below)
>
> 5. Assuming you have those, run the following in the mathopd src directory,
> as root:
>
>  # xr run -i -n inet:dhcp -b etc.iso:/etc -b data.iso:/data mathopd -nt -f /etc/mathopd.conf
>
> This will configure xenif0 using dhcp/ipv4, mount /etc and /data using the
> respective images and then run "mathopd -nt -f /etc/mathopd.conf". The
> mathopd options tell it not to fork into the background and to write logs
> to standard output.

I think the network config needs more thought - like disk it needs a
host side vs rump side set of options, wg you might want to specify a
mac address and bridge to connect to on the xen side, then some
options on rump side, eg dhcp, or none (which should just being it up
which will do ipv6 anyway). An option to use a config file might be
nice too.

Justin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 13 21:57:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Nov 2014 21:57:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp2NT-0003aM-3z; Thu, 13 Nov 2014 21:56:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justin@specialbusservice.com>) id 1Xp2NR-0003aH-NM
	for xen-devel@lists.xenproject.org; Thu, 13 Nov 2014 21:56:29 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	3C/84-07724-C0925645; Thu, 13 Nov 2014 21:56:28 +0000
X-Env-Sender: justin@specialbusservice.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1415915787!11265168!1
X-Originating-IP: [209.85.217.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29656 invoked from network); 13 Nov 2014 21:56:27 -0000
Received: from mail-lb0-f182.google.com (HELO mail-lb0-f182.google.com)
	(209.85.217.182)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Nov 2014 21:56:27 -0000
Received: by mail-lb0-f182.google.com with SMTP id f15so12780354lbj.41
	for <xen-devel@lists.xenproject.org>;
	Thu, 13 Nov 2014 13:56:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=specialbusservice.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=sTKURYesCANlFRYGgbhxD3Peg8kGwv0R7+lX9G+o6C0=;
	b=opb8m5ftE7urh3GU/qfr4ooXUQX/e/8uLSXm51jGLaewxyJQG5NrZv82VDFi6BPp+j
	ftCmDVUNF2lwGclEDoiuCiXmqxDLYmJfUtMWfDNmA5RsFV80ow2eKBat7RgX7C7QaqGj
	U79T8KsuzEJBgtEzDtzYdEZrZJf/wt+9iqGTA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=sTKURYesCANlFRYGgbhxD3Peg8kGwv0R7+lX9G+o6C0=;
	b=E43BZEQixt/GjZJWASIy9v9jkJwiunQmz13MO2st4M2tGrfOuxTYxU1Lj2xNk9+lFY
	Ee8utR74TeCYDuJA2H4AQCiloE5eQHvMmMrOU/DZAsh3Wl9++NBGCTgQp+KmEcuf0HYe
	LDpA+VqzYjbq4vXAv67421V8/JwjmuE9EYEpESpOkSxHgevwPM6TuP+luJRWRNZ7BJGR
	84BKZEWK+kgnTmhgz0g577CrkupYm/CQ+SQwqUl/lxnL8r8eMAB0RuKI/IJp5JduGcRw
	pSGmOXvHElyrrWPdAG5+BuSQCJL18tHA1ytkxizuHZrdtB/MUkKt+t+fQoAI0tCo5jWy
	UoWw==
X-Gm-Message-State: ALoCoQlRX+XS5EAlwJvGY/jO49atDVODpwubbOq/8Gur1hojhdNC6Qaw/7D0g0SeuYqDcIYp4jqX
MIME-Version: 1.0
X-Received: by 10.112.135.229 with SMTP id pv5mr4714216lbb.52.1415915786957;
	Thu, 13 Nov 2014 13:56:26 -0800 (PST)
Received: by 10.152.0.197 with HTTP; Thu, 13 Nov 2014 13:56:26 -0800 (PST)
In-Reply-To: <20141113154634.GA9560@nodbug.moloch.sk>
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk>
Date: Thu, 13 Nov 2014 21:56:26 +0000
Message-ID: <CAK4o1WwwYt05sGe+-9zEqwpzbz+mvG7YMYLwJcn-oDR6AZg55Q@mail.gmail.com>
From: Justin Cormack <justin@specialbusservice.com>
To: "rumpkernel-users@lists.sourceforge.net"
	<rumpkernel-users@lists.sourceforge.net>, xen-devel@lists.xenproject.org, 
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 3:46 PM, Martin Lucina <martin@lucina.net> wrote:
>> > Following is the high-level description from the Git commit:
>>
>> Can you also post an example of the usage of your CLI tool?  Actually,
>> can you post a rough description of the entire process that a user would
>> have to follow, i.e. compile, configure, run.
>
> Running "xr" with no parameters gives a nice command reference :-)
>
> Anyhow:
>
> Simple hello world using tests/hello/hello built as part of buildxen.sh:
>
>  # xr run -i tests/hello/hello
>
> Running a webserver:
>
> Get mathopd source from http://mathopd.org/. I used mathopd as it's BSD
> licensed, non-forking and small. To build and run it:
>
> 1. git clone, buildxen.sh
>
> 2. Put app-tools at the *END* of your $PATH. There is a bug/interaction
> with the app-tools ld that breaks things if you put it before the real ld.
>
> 3. (in mathopd/src) rumpapp-xen-make
>
> 4. You need filesystem images for a stub /etc and /data. I am using cd9660
> for these as you can portably generate that anywhere you have genisoimage
> (ex mkisofs). (see below)
>
> 5. Assuming you have those, run the following in the mathopd src directory,
> as root:
>
>  # xr run -i -n inet:dhcp -b etc.iso:/etc -b data.iso:/data mathopd -nt -f /etc/mathopd.conf
>
> This will configure xenif0 using dhcp/ipv4, mount /etc and /data using the
> respective images and then run "mathopd -nt -f /etc/mathopd.conf". The
> mathopd options tell it not to fork into the background and to write logs
> to standard output.

I think the network config needs more thought - like disk it needs a
host side vs rump side set of options, wg you might want to specify a
mac address and bridge to connect to on the xen side, then some
options on rump side, eg dhcp, or none (which should just being it up
which will do ipv6 anyway). An option to use a config file might be
nice too.

Justin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 02:22:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 02:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp6Vo-0005mk-AS; Fri, 14 Nov 2014 02:21:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xp6Vm-0005mf-C7
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 02:21:22 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	45/A4-17694-12765645; Fri, 14 Nov 2014 02:21:21 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415931679!11310783!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17276 invoked from network); 14 Nov 2014 02:21:20 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-8.tower-31.messagelabs.com with SMTP;
	14 Nov 2014 02:21:20 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 13 Nov 2014 18:18:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,382,1413270000"; d="scan'208";a="607609731"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.161])
	([10.238.128.161])
	by orsmga001.jf.intel.com with ESMTP; 13 Nov 2014 18:21:16 -0800
Message-ID: <5465671C.4070007@intel.com>
Date: Fri, 14 Nov 2014 10:21:16 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com, 
	kevin.tian@intel.com
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>	<5457174C.8020400@intel.com>	<5457515102000078000443B0@mail.emea.novell.com>	<54574D8F.8060407@intel.com>	<54575E2D0200007800044443@mail.emea.novell.com>	<545767C4.7070806@intel.com>	<5457787002000078000445C7@mail.emea.novell.com>	<54576DF7.8060408@intel.com>	<545784830200007800044627@mail.emea.novell.com>	<54585EAA.20904@intel.com>	<545894610200007800044A5B@mail.emea.novell.com>	<545992A2.8070309@intel.com>	<545A57AD02000078000C1037@mail.emea.novell.com>	<545B3F4A.5070808@intel.com>	<545B562F02000078000453FB@mail.emea.novell.com>	<545C9E97.4040800@intel.com>	<545CB64E02000078000459CD@mail.emea.novell.com>	<5461AD94.2070008@intel.com>
	<5461BF97.1070709@intel.com>	<5461DED50200007800046520@mail.emea.novell.com>	<5461DFAF020000780004652B@mail.emea.novell.com>	<5461DA23.6020105@intel.com>
	<5462CE68.6010709@intel.com>	<54632EA80200007800046AE5@mail.emea.novell.com>
	<546420CE.1080908@intel.com>
In-Reply-To: <546420CE.1080908@intel.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 2014/11/13 11:09, Chen, Tiejun wrote:
> On 2014/11/12 16:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>>> I don't see any feedback to this point, so I think you still prefer we
>>> should do all check in the callback function.
>>
>> As a draft this looks reasonable, but there are various bugs to be
>> dealt with along with cosmetic issues (I'll point out the former, but
>> I'm tired of pointing out the latter once again - please go back to
>> earlier reviews of patches to refresh e.g. what types to use for
>> loop variables).
>>
>>> I tried to address this but obviously we have to pass each 'pdf' to
>>> callback functions,
>>
>> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
>> but something more neutral (maybe "id"). And you again lost the
>> segment there.
>>
>>> @@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t
>>> start,
>>>            if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>>>                return -ERANGE;
>>>
>>> -        if ( __copy_to_compat_offset(grdm->map.buffer,
>>> grdm->used_entries,
>>> -                                     &rdm, 1) )
>>> -            return -EFAULT;
>>> +        if ( d->arch.hvm_domain.pci_force )
>>> +        {
>>> +            if ( __copy_to_compat_offset(grdm->map.buffer,
>>> grdm->used_entries,
>>> +                                         &rdm, 1) )
>>> +                return -EFAULT;
>>> +        }
>>> +        else
>>> +        {
>>> +            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
>>> +            {
>>> +                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
>>> +                                  d->arch.hvm_domain.pcidevs[i].devfn);
>>> +                if ( pt_bdf == bdf )
>>> +                    if ( __copy_to_compat_offset(grdm->map.buffer,
>>> grdm->used_entries,
>>> +                                                 &rdm, 1) )
>>> +                        return -EFAULT;
>>
>> I think d->arch.hvm_domain.pcidevs[] shouldn't contain duplicates,
>> and hence there's no point continuing the loop if you found a match.
>>
>
> I take a look at this again. Seems we shouldn't just check bdf since as
> you know its possible to occupy one entry by multiple different BDFs, so
> we have to filter-to-keep one entry. Instead, I really hope we'd check
> to expose before we do the hypercall.

Even if eventually we'll reorder that sequence, this just change that 
approach to get BDF. Are you fine to this subsequent change?

@@ -894,18 +894,55 @@ int platform_supports_x2apic(void)
      return cpu_has_x2apic && ((dmar_flags & mask) == 
ACPI_DMAR_INTR_REMAP);
  }

-int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
+int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, struct 
domain *d,
+                                           void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
-    int rc = 0;
+    int rc = 0, i, j, seg_check = 1;
+    u16 id, bdf;

-    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+    if ( d->arch.hvm_domain.pci_force )
      {
-        rc = func(PFN_DOWN(rmrr->base_address),
-                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
-                  ctxt);
-        if ( rc )
-            break;
+        list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+        {
+            rc = func(PFN_DOWN(rmrr->base_address),
+                      PFN_UP(rmrr->end_address) - 
PFN_DOWN(rmrr->base_address),
+                      ctxt);
+            if ( rc )
+                break;
+        }
+    }
+    else
+    {
+        list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+        {
+            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs &&
+                            seg_check; i++ )
+            {
+                if ( rmrr->segment == d->arch.hvm_domain.pcidevs[i].seg )
+                {
+                    bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[j].bus,
+                                   d->arch.hvm_domain.pcidevs[j].devfn);
+                    for (j = 0; (id = rmrr->scope.devices[j]) &&
+                            j < rmrr->scope.devices_cnt && seg_check; j++)
+                    {
+                        if ( bdf == id )
+                        {
+                            rc = func(PFN_DOWN(rmrr->base_address),
+                                      PFN_UP(rmrr->end_address) -
+                                        PFN_DOWN(rmrr->base_address),
+                                      ctxt);
+                            if ( rc )
+                                return;
+                            /* Hit this seg entry. */
+                            seg_check = 0;
+                        }
+                    }
+                }
+            }
+            /* goto next seg entry. */
+            seg_check = 1;
+        }
      }

      return rc;

>
> BTW, I already ping Yang in local to look that possibility to reorder
> the sequence of the device assignment and the memory population in iommu
> side.

Yang and Kevin,

Any comments to this requirement?

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 02:22:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 02:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp6Vo-0005mk-AS; Fri, 14 Nov 2014 02:21:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xp6Vm-0005mf-C7
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 02:21:22 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	45/A4-17694-12765645; Fri, 14 Nov 2014 02:21:21 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415931679!11310783!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17276 invoked from network); 14 Nov 2014 02:21:20 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-8.tower-31.messagelabs.com with SMTP;
	14 Nov 2014 02:21:20 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 13 Nov 2014 18:18:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,382,1413270000"; d="scan'208";a="607609731"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.161])
	([10.238.128.161])
	by orsmga001.jf.intel.com with ESMTP; 13 Nov 2014 18:21:16 -0800
Message-ID: <5465671C.4070007@intel.com>
Date: Fri, 14 Nov 2014 10:21:16 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com, 
	kevin.tian@intel.com
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>	<5457174C.8020400@intel.com>	<5457515102000078000443B0@mail.emea.novell.com>	<54574D8F.8060407@intel.com>	<54575E2D0200007800044443@mail.emea.novell.com>	<545767C4.7070806@intel.com>	<5457787002000078000445C7@mail.emea.novell.com>	<54576DF7.8060408@intel.com>	<545784830200007800044627@mail.emea.novell.com>	<54585EAA.20904@intel.com>	<545894610200007800044A5B@mail.emea.novell.com>	<545992A2.8070309@intel.com>	<545A57AD02000078000C1037@mail.emea.novell.com>	<545B3F4A.5070808@intel.com>	<545B562F02000078000453FB@mail.emea.novell.com>	<545C9E97.4040800@intel.com>	<545CB64E02000078000459CD@mail.emea.novell.com>	<5461AD94.2070008@intel.com>
	<5461BF97.1070709@intel.com>	<5461DED50200007800046520@mail.emea.novell.com>	<5461DFAF020000780004652B@mail.emea.novell.com>	<5461DA23.6020105@intel.com>
	<5462CE68.6010709@intel.com>	<54632EA80200007800046AE5@mail.emea.novell.com>
	<546420CE.1080908@intel.com>
In-Reply-To: <546420CE.1080908@intel.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 2014/11/13 11:09, Chen, Tiejun wrote:
> On 2014/11/12 16:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>>> I don't see any feedback to this point, so I think you still prefer we
>>> should do all check in the callback function.
>>
>> As a draft this looks reasonable, but there are various bugs to be
>> dealt with along with cosmetic issues (I'll point out the former, but
>> I'm tired of pointing out the latter once again - please go back to
>> earlier reviews of patches to refresh e.g. what types to use for
>> loop variables).
>>
>>> I tried to address this but obviously we have to pass each 'pdf' to
>>> callback functions,
>>
>> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
>> but something more neutral (maybe "id"). And you again lost the
>> segment there.
>>
>>> @@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t
>>> start,
>>>            if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>>>                return -ERANGE;
>>>
>>> -        if ( __copy_to_compat_offset(grdm->map.buffer,
>>> grdm->used_entries,
>>> -                                     &rdm, 1) )
>>> -            return -EFAULT;
>>> +        if ( d->arch.hvm_domain.pci_force )
>>> +        {
>>> +            if ( __copy_to_compat_offset(grdm->map.buffer,
>>> grdm->used_entries,
>>> +                                         &rdm, 1) )
>>> +                return -EFAULT;
>>> +        }
>>> +        else
>>> +        {
>>> +            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
>>> +            {
>>> +                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
>>> +                                  d->arch.hvm_domain.pcidevs[i].devfn);
>>> +                if ( pt_bdf == bdf )
>>> +                    if ( __copy_to_compat_offset(grdm->map.buffer,
>>> grdm->used_entries,
>>> +                                                 &rdm, 1) )
>>> +                        return -EFAULT;
>>
>> I think d->arch.hvm_domain.pcidevs[] shouldn't contain duplicates,
>> and hence there's no point continuing the loop if you found a match.
>>
>
> I take a look at this again. Seems we shouldn't just check bdf since as
> you know its possible to occupy one entry by multiple different BDFs, so
> we have to filter-to-keep one entry. Instead, I really hope we'd check
> to expose before we do the hypercall.

Even if eventually we'll reorder that sequence, this just change that 
approach to get BDF. Are you fine to this subsequent change?

@@ -894,18 +894,55 @@ int platform_supports_x2apic(void)
      return cpu_has_x2apic && ((dmar_flags & mask) == 
ACPI_DMAR_INTR_REMAP);
  }

-int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
+int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, struct 
domain *d,
+                                           void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
-    int rc = 0;
+    int rc = 0, i, j, seg_check = 1;
+    u16 id, bdf;

-    list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+    if ( d->arch.hvm_domain.pci_force )
      {
-        rc = func(PFN_DOWN(rmrr->base_address),
-                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
-                  ctxt);
-        if ( rc )
-            break;
+        list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+        {
+            rc = func(PFN_DOWN(rmrr->base_address),
+                      PFN_UP(rmrr->end_address) - 
PFN_DOWN(rmrr->base_address),
+                      ctxt);
+            if ( rc )
+                break;
+        }
+    }
+    else
+    {
+        list_for_each_entry(rmrr, &acpi_rmrr_units, list)
+        {
+            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs &&
+                            seg_check; i++ )
+            {
+                if ( rmrr->segment == d->arch.hvm_domain.pcidevs[i].seg )
+                {
+                    bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[j].bus,
+                                   d->arch.hvm_domain.pcidevs[j].devfn);
+                    for (j = 0; (id = rmrr->scope.devices[j]) &&
+                            j < rmrr->scope.devices_cnt && seg_check; j++)
+                    {
+                        if ( bdf == id )
+                        {
+                            rc = func(PFN_DOWN(rmrr->base_address),
+                                      PFN_UP(rmrr->end_address) -
+                                        PFN_DOWN(rmrr->base_address),
+                                      ctxt);
+                            if ( rc )
+                                return;
+                            /* Hit this seg entry. */
+                            seg_check = 0;
+                        }
+                    }
+                }
+            }
+            /* goto next seg entry. */
+            seg_check = 1;
+        }
      }

      return rc;

>
> BTW, I already ping Yang in local to look that possibility to reorder
> the sequence of the device assignment and the memory population in iommu
> side.

Yang and Kevin,

Any comments to this requirement?

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 03:01:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 03: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 1Xp78P-00071V-7u; Fri, 14 Nov 2014 03:01:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xp78O-00071Q-Gk
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 03:01:16 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	17/6F-22819-B7075645; Fri, 14 Nov 2014 03:01:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415934073!11281408!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1888 invoked from network); 14 Nov 2014 03:01:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 03:01:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,382,1413244800"; d="scan'208";a="192718242"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 22:01:12 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xp78J-0005qu-PC;
	Fri, 14 Nov 2014 03:01:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xp78J-0000cN-In;
	Fri, 14 Nov 2014 03:01:11 +0000
Date: Fri, 14 Nov 2014 03:01:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31510-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31510: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31510 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31510/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 31489

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31489
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31489

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  cacfcc5b4bfd705e48cdf19473e6be612d3e82c5
baseline version:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

------------------------------------------------------------
People who touched revisions under test:
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 cacfcc5b4bfd705e48cdf19473e6be612d3e82c5
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Nov 11 09:40:20 2014 -0500

    Xen 4.5.0-rc2: Update tag for QEMU upstream tree....
    
    QEMU traditional can stay at rc1 since there are no changes in it.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 03:01:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 03: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 1Xp78P-00071V-7u; Fri, 14 Nov 2014 03:01:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xp78O-00071Q-Gk
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 03:01:16 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	17/6F-22819-B7075645; Fri, 14 Nov 2014 03:01:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415934073!11281408!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1888 invoked from network); 14 Nov 2014 03:01:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 03:01:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,382,1413244800"; d="scan'208";a="192718242"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 22:01:12 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xp78J-0005qu-PC;
	Fri, 14 Nov 2014 03:01:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xp78J-0000cN-In;
	Fri, 14 Nov 2014 03:01:11 +0000
Date: Fri, 14 Nov 2014 03:01:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31510-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31510: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31510 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31510/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 31489

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31489
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31489

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  cacfcc5b4bfd705e48cdf19473e6be612d3e82c5
baseline version:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

------------------------------------------------------------
People who touched revisions under test:
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 cacfcc5b4bfd705e48cdf19473e6be612d3e82c5
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Nov 11 09:40:20 2014 -0500

    Xen 4.5.0-rc2: Update tag for QEMU upstream tree....
    
    QEMU traditional can stay at rc1 since there are no changes in it.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 03:12:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 03: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 1Xp7Ii-0007Rl-EQ; Fri, 14 Nov 2014 03:11:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xp7Ig-0007PQ-M0
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 03:11:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AF/A9-09936-AF275645; Fri, 14 Nov 2014 03:11:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415934712!12653901!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12756 invoked from network); 14 Nov 2014 03:11:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 03:11:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,382,1413244800"; d="scan'208";a="191258135"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 22:11:18 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xp7I6-0005tj-R8;
	Fri, 14 Nov 2014 03:11:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xp7I6-0005S4-D6;
	Fri, 14 Nov 2014 03:11:18 +0000
Date: Fri, 14 Nov 2014 03:11:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31530-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31530: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31530 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31530/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                04689e749b7ec156291446028a0ce2e685bf3855
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
454 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 15831 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 03:12:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 03: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 1Xp7Ii-0007Rl-EQ; Fri, 14 Nov 2014 03:11:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xp7Ig-0007PQ-M0
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 03:11:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AF/A9-09936-AF275645; Fri, 14 Nov 2014 03:11:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415934712!12653901!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12756 invoked from network); 14 Nov 2014 03:11:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 03:11:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,382,1413244800"; d="scan'208";a="191258135"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 22:11:18 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xp7I6-0005tj-R8;
	Fri, 14 Nov 2014 03:11:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xp7I6-0005S4-D6;
	Fri, 14 Nov 2014 03:11:18 +0000
Date: Fri, 14 Nov 2014 03:11:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31530-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31530: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31530 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31530/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                04689e749b7ec156291446028a0ce2e685bf3855
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
454 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 15831 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 04:48:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 04:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp8nH-0001Cd-Uf; Fri, 14 Nov 2014 04:47:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xp8nG-0001CY-H5
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 04:47:34 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D0/C7-24532-56985645; Fri, 14 Nov 2014 04:47:33 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415940451!12685778!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20014 invoked from network); 14 Nov 2014 04:47:32 -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;
	14 Nov 2014 04:47:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,383,1413244800"; d="scan'208";a="192737580"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 23:47:29 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xp8nB-0006Mt-Ag;
	Fri, 14 Nov 2014 04:47:29 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xp8nB-00051p-2m;
	Fri, 14 Nov 2014 04:47:29 +0000
Date: Fri, 14 Nov 2014 04:47:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31532-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8269
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31532: 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: multipart/mixed; boundary="===============7575573564519451214=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7575573564519451214==
Content-Type: text/plain
Content-Length: 7996
Content-Transfer-Encoding: quoted-printable

flight 31532 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31532/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              8d659b177ff44be37bdb36648eaabbaec457c941
baseline version:
 libvirt              cce8e5f7395fef5fa782910bc4a6fc8a786f8bc2

------------------------------------------------------------
People who touched revisions under test:
  Conrad Meyer <cse.cem@gmail.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Matthias Gatto <matthias.gatto@outscale.com>
  Michal Privoznik <mprivozn@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3D8d659b177ff44be37bdb36648eaabbaec457c941
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 8d659b177ff44be37bdb36648eaabbaec457c941
+ branch=3Dlibvirt
+ revision=3D8d659b177ff44be37bdb36648eaabbaec457c941
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 8d659b177ff44be37bdb36648eaabbaec457c941:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   cce8e5f..8d659b1  8d659b177ff44be37bdb36648eaabbaec457c941 -> xen-tested-master


--===============7575573564519451214==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7575573564519451214==--

From xen-devel-bounces@lists.xen.org Fri Nov 14 04:48:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 04:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xp8nH-0001Cd-Uf; Fri, 14 Nov 2014 04:47:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xp8nG-0001CY-H5
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 04:47:34 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D0/C7-24532-56985645; Fri, 14 Nov 2014 04:47:33 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415940451!12685778!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20014 invoked from network); 14 Nov 2014 04:47:32 -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;
	14 Nov 2014 04:47:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,383,1413244800"; d="scan'208";a="192737580"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 13 Nov 2014 23:47:29 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xp8nB-0006Mt-Ag;
	Fri, 14 Nov 2014 04:47:29 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xp8nB-00051p-2m;
	Fri, 14 Nov 2014 04:47:29 +0000
Date: Fri, 14 Nov 2014 04:47:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31532-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8269
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31532: 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: multipart/mixed; boundary="===============7575573564519451214=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7575573564519451214==
Content-Type: text/plain
Content-Length: 7996
Content-Transfer-Encoding: quoted-printable

flight 31532 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31532/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              8d659b177ff44be37bdb36648eaabbaec457c941
baseline version:
 libvirt              cce8e5f7395fef5fa782910bc4a6fc8a786f8bc2

------------------------------------------------------------
People who touched revisions under test:
  Conrad Meyer <cse.cem@gmail.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Matthias Gatto <matthias.gatto@outscale.com>
  Michal Privoznik <mprivozn@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3D8d659b177ff44be37bdb36648eaabbaec457c941
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 8d659b177ff44be37bdb36648eaabbaec457c941
+ branch=3Dlibvirt
+ revision=3D8d659b177ff44be37bdb36648eaabbaec457c941
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 8d659b177ff44be37bdb36648eaabbaec457c941:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   cce8e5f..8d659b1  8d659b177ff44be37bdb36648eaabbaec457c941 -> xen-tested-master


--===============7575573564519451214==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7575573564519451214==--

From xen-devel-bounces@lists.xen.org Fri Nov 14 04:53:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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.xen.org>)
	id 1Xp8su-0001WY-OX; Fri, 14 Nov 2014 04:53:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xp8st-0001WT-I7
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 04:53:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	56/3B-09842-2CA85645; Fri, 14 Nov 2014 04:53:22 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415940802!12621274!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9249 invoked from network); 14 Nov 2014 04:53:22 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 04:53:22 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 39F99AC38;
	Fri, 14 Nov 2014 04:53:20 +0000 (UTC)
Message-ID: <54658ABF.5050708@suse.com>
Date: Fri, 14 Nov 2014 05:53:19 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
	<20141113195605.GA13039@laptop.dumpdata.com>
In-Reply-To: <20141113195605.GA13039@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
>>>> +	mfn_save = virt_to_mfn(buf);
>>>> +
>>>> +	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
>>>
>>> So the 'list' is constructed by going forward - that is from low-numbered
>>> PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
>>> other way - from the highest PFN to the lowest PFN.
>>>
>>> Won't that mean we will restore the chunks of memory in the wrong
>>> order? That is we will still restore them in chunks size, but the
>>> chunks will be in descending order instead of ascending?
>>
>> No, the information where to put each chunk is contained in the chunk
>> data. I can add a comment explaining this.
>
> Right, the MFNs in a "chunks" are going to be restored in the right order.
>
> I was thinking that the "chunks" (so a set of MFNs) will be restored in
> the opposite order that they are written to.
>
> And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?

More don't fit on a single page due to the other info needed. So: yes.

>
>>
>>>
>>>> +		/* Map the remap information */
>>>> +		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
>>>> +
>>>> +		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
>>>> +
>>>> +		free = 0;
>>>> +		pfn = xen_remap_buf.target_pfn;
>>>> +		for (i = 0; i < xen_remap_buf.size; i++) {
>>>> +			mfn = xen_remap_buf.mfns[i];
>>>> +			if (!released && xen_update_mem_tables(pfn, mfn)) {
>>>> +				remapped++;
>>>
>>> If we fail 'xen_update_mem_tables' we will on the next chunk (so i+1) keep on
>>> freeing pages instead of trying to remap. Is that intentional? Could we
>>> try to remap?
>>
>> Hmm, I'm not sure this is worth the effort. What could lead to failure
>> here? I suspect we could even just BUG() on failure. What do you think?
>
> I was hoping that this question would lead to making this loop a bit
> simpler as you would have to spread some of the code in the loop
> into functions.
>
> And keep 'remmaped' and 'released' reset every loop.
>
> However, if it makes the code more complex - then please
> forget my question.

Using BUG() instead would make the code less complex. Do you really
think xen_update_mem_tables() would ever fail in a sane system?

- set_phys_to_machine() would fail only on a memory shortage. Just
   going on without adding more memory wouldn't lead to a healthy system,
   I think.
- The hypervisor calls would fail only in case of parameter errors.
   This should never happen, so dying seems to be the correct reaction.

David, what do you think?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 04:53:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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.xen.org>)
	id 1Xp8su-0001WY-OX; Fri, 14 Nov 2014 04:53:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xp8st-0001WT-I7
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 04:53:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	56/3B-09842-2CA85645; Fri, 14 Nov 2014 04:53:22 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1415940802!12621274!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9249 invoked from network); 14 Nov 2014 04:53:22 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 04:53:22 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 39F99AC38;
	Fri, 14 Nov 2014 04:53:20 +0000 (UTC)
Message-ID: <54658ABF.5050708@suse.com>
Date: Fri, 14 Nov 2014 05:53:19 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
	<20141113195605.GA13039@laptop.dumpdata.com>
In-Reply-To: <20141113195605.GA13039@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
>>>> +	mfn_save = virt_to_mfn(buf);
>>>> +
>>>> +	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
>>>
>>> So the 'list' is constructed by going forward - that is from low-numbered
>>> PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
>>> other way - from the highest PFN to the lowest PFN.
>>>
>>> Won't that mean we will restore the chunks of memory in the wrong
>>> order? That is we will still restore them in chunks size, but the
>>> chunks will be in descending order instead of ascending?
>>
>> No, the information where to put each chunk is contained in the chunk
>> data. I can add a comment explaining this.
>
> Right, the MFNs in a "chunks" are going to be restored in the right order.
>
> I was thinking that the "chunks" (so a set of MFNs) will be restored in
> the opposite order that they are written to.
>
> And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?

More don't fit on a single page due to the other info needed. So: yes.

>
>>
>>>
>>>> +		/* Map the remap information */
>>>> +		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
>>>> +
>>>> +		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
>>>> +
>>>> +		free = 0;
>>>> +		pfn = xen_remap_buf.target_pfn;
>>>> +		for (i = 0; i < xen_remap_buf.size; i++) {
>>>> +			mfn = xen_remap_buf.mfns[i];
>>>> +			if (!released && xen_update_mem_tables(pfn, mfn)) {
>>>> +				remapped++;
>>>
>>> If we fail 'xen_update_mem_tables' we will on the next chunk (so i+1) keep on
>>> freeing pages instead of trying to remap. Is that intentional? Could we
>>> try to remap?
>>
>> Hmm, I'm not sure this is worth the effort. What could lead to failure
>> here? I suspect we could even just BUG() on failure. What do you think?
>
> I was hoping that this question would lead to making this loop a bit
> simpler as you would have to spread some of the code in the loop
> into functions.
>
> And keep 'remmaped' and 'released' reset every loop.
>
> However, if it makes the code more complex - then please
> forget my question.

Using BUG() instead would make the code less complex. Do you really
think xen_update_mem_tables() would ever fail in a sane system?

- set_phys_to_machine() would fail only on a memory shortage. Just
   going on without adding more memory wouldn't lead to a healthy system,
   I think.
- The hypervisor calls would fail only in case of parameter errors.
   This should never happen, so dying seems to be the correct reaction.

David, what do you think?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 06:31:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 06: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 1XpAP8-0003n7-ID; Fri, 14 Nov 2014 06:30:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpAP6-0003n0-V0
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 06:30:45 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	4B/C7-14214-391A5645; Fri, 14 Nov 2014 06:30:43 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415946642!11285496!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 310 invoked from network); 14 Nov 2014 06:30:42 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 06:30:42 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 622A2AC38;
	Fri, 14 Nov 2014 06:30:41 +0000 (UTC)
Message-ID: <5465A18F.5050007@suse.com>
Date: Fri, 14 Nov 2014 07:30:39 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com, 
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, 
	jbeulich@suse.com, toshi.kani@hp.com, plagnioj@jcrosoft.com, 
	tomi.valkeinen@ti.com, bhelgaas@google.com
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
Subject: Re: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ingo,

could you take the patches, please?


Juergen

On 11/03/2014 02:01 PM, Juergen Gross wrote:
> The x86 architecture offers via the PAT (Page Attribute Table) a way to
> specify different caching modes in page table entries. The PAT MSR contains
> 8 entries each specifying one of 6 possible cache modes. A pte references one
> of those entries via 3 bits: _PAGE_PAT, _PAGE_PWT and _PAGE_PCD.
>
> The Linux kernel currently supports only 4 different cache modes. The PAT MSR
> is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the
> top 4 entries in the PAT MSR are the same as the 4 lower entries.
>
> This results in the kernel not supporting e.g. write-through mode. Especially
> this cache mode would speed up drivers of video cards which now have to use
> uncached accesses.
>
> OTOH some old processors (Pentium) don't support PAT correctly and the Xen
> hypervisor has been using a different PAT MSR configuration for some time now
> and can't change that as this setting is part of the ABI.
>
> This patch set abstracts the cache mode from the pte and introduces tables to
> translate between cache mode and pte bits (the default cache mode "write back"
> is hard-wired to PAT entry 0). The tables are statically initialized with
> values being compatible to old processors and current usage. As soon as the
> PAT MSR is changed (or - in case of Xen - is read at boot time) the tables are
> changed accordingly. Requests of mappings with special cache modes are always
> possible now, in case they are not supported there will be a fallback to a
> compatible but slower mode.
>
> Summing it up, this patch set adds the following features:
> - capability to support WT and WP cache modes on processors with full PAT
>    support
> - processors with no or uncorrect PAT support are still working as today, even
>    if WT or WP cache mode are selected by drivers for some pages
> - reduction of Xen special handling regarding cache mode
>
> Changes in V6:
> - add new patch 10 (x86: Remove looking for setting of _PAGE_PAT_LARGE in
>    pageattr.c) as suggested by Thomas Gleixner
> - replaced SOB of Stefan Bader by "Based-on-patch-by:" as suggested by
>    Borislav Petkov
>
> Changes in V5:
> - split up first patch as requested by Ingo Molnar and Thomas Gleixner
> - add a helper function in pat_init_cache_modes() as requested by Ingo Molnar
>
> Changes in V4:
> - rebased to 3.18-rc2
>
> Changes in V3:
> - corrected two minor nits (UC_MINUS, again) detected by Toshi Kani
>
> Changes in V2:
> - simplified handling of PAT MSR write under Xen as suggested by David Vrabel
> - removed resetting of pat_enabled under Xen
> - two small corrections requested by Toshi Kani (UC_MINUS cache mode in
>    vermilion driver, fix 32 bit kernel build failure)
> - correct build error on non-x86 arch by moving definition of
>    update_cache_mode_entry() to x86 specific header
>
> Changes since RFC:
> - renamed functions and variables as suggested by Toshi Kani
> - corrected cache mode bits for WT and WP
> - modified handling of PAT MSR write under Xen as suggested by Jan Beulich
>
>
> Juergen Gross (18):
>    x86: Make page cache mode a real type
>    x86: Use new cache mode type in include/asm/fb.h
>    x86: Use new cache mode type in drivers/video/fbdev/gbefb.c
>    x86: Use new cache mode type in drivers/video/fbdev/vermilion
>    x86: Use new cache mode type in arch/x86/pci
>    x86: Use new cache mode type in arch/x86/mm/init_64.c
>    x86: Use new cache mode type in asm/pgtable.h
>    x86: Use new cache mode type in mm/iomap_32.c
>    x86: Use new cache mode type in track_pfn_remap() and
>      track_pfn_insert()
>    x86: Remove looking for setting of _PAGE_PAT_LARGE in pageattr.c
>    x86: Use new cache mode type in setting page attributes
>    x86: Use new cache mode type in mm/ioremap.c
>    x86: Use new cache mode type in memtype related functions
>    x86: Clean up pgtable_types.h
>    x86: Support PAT bit in pagetable dump for lower levels
>    x86: Respect PAT bit when copying pte values between large and normal
>      pages
>    x86: Enable PAT to use cache mode translation tables
>    xen: Support Xen pv-domains using PAT
>
>   arch/x86/include/asm/cacheflush.h         |  38 ++++---
>   arch/x86/include/asm/fb.h                 |   6 +-
>   arch/x86/include/asm/io.h                 |   2 +-
>   arch/x86/include/asm/pat.h                |   7 +-
>   arch/x86/include/asm/pgtable.h            |  19 ++--
>   arch/x86/include/asm/pgtable_types.h      |  96 ++++++++++++----
>   arch/x86/mm/dump_pagetables.c             |  24 ++--
>   arch/x86/mm/init.c                        |  37 +++++++
>   arch/x86/mm/init_64.c                     |   9 +-
>   arch/x86/mm/iomap_32.c                    |  12 +-
>   arch/x86/mm/ioremap.c                     |  63 ++++++-----
>   arch/x86/mm/mm_internal.h                 |   2 +
>   arch/x86/mm/pageattr.c                    |  84 ++++++++------
>   arch/x86/mm/pat.c                         | 176 +++++++++++++++++++-----------
>   arch/x86/mm/pat_internal.h                |  22 ++--
>   arch/x86/mm/pat_rbtree.c                  |   8 +-
>   arch/x86/pci/i386.c                       |   4 +-
>   arch/x86/xen/enlighten.c                  |  25 ++---
>   arch/x86/xen/mmu.c                        |  47 +-------
>   arch/x86/xen/xen-ops.h                    |   1 -
>   drivers/video/fbdev/gbefb.c               |   3 +-
>   drivers/video/fbdev/vermilion/vermilion.c |   6 +-
>   22 files changed, 412 insertions(+), 279 deletions(-)
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 06:31:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 06: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 1XpAP8-0003n7-ID; Fri, 14 Nov 2014 06:30:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpAP6-0003n0-V0
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 06:30:45 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	4B/C7-14214-391A5645; Fri, 14 Nov 2014 06:30:43 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415946642!11285496!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 310 invoked from network); 14 Nov 2014 06:30:42 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 06:30:42 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 622A2AC38;
	Fri, 14 Nov 2014 06:30:41 +0000 (UTC)
Message-ID: <5465A18F.5050007@suse.com>
Date: Fri, 14 Nov 2014 07:30:39 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: hpa@zytor.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com, 
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	ville.syrjala@linux.intel.com, david.vrabel@citrix.com, 
	jbeulich@suse.com, toshi.kani@hp.com, plagnioj@jcrosoft.com, 
	tomi.valkeinen@ti.com, bhelgaas@google.com
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
Subject: Re: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ingo,

could you take the patches, please?


Juergen

On 11/03/2014 02:01 PM, Juergen Gross wrote:
> The x86 architecture offers via the PAT (Page Attribute Table) a way to
> specify different caching modes in page table entries. The PAT MSR contains
> 8 entries each specifying one of 6 possible cache modes. A pte references one
> of those entries via 3 bits: _PAGE_PAT, _PAGE_PWT and _PAGE_PCD.
>
> The Linux kernel currently supports only 4 different cache modes. The PAT MSR
> is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the
> top 4 entries in the PAT MSR are the same as the 4 lower entries.
>
> This results in the kernel not supporting e.g. write-through mode. Especially
> this cache mode would speed up drivers of video cards which now have to use
> uncached accesses.
>
> OTOH some old processors (Pentium) don't support PAT correctly and the Xen
> hypervisor has been using a different PAT MSR configuration for some time now
> and can't change that as this setting is part of the ABI.
>
> This patch set abstracts the cache mode from the pte and introduces tables to
> translate between cache mode and pte bits (the default cache mode "write back"
> is hard-wired to PAT entry 0). The tables are statically initialized with
> values being compatible to old processors and current usage. As soon as the
> PAT MSR is changed (or - in case of Xen - is read at boot time) the tables are
> changed accordingly. Requests of mappings with special cache modes are always
> possible now, in case they are not supported there will be a fallback to a
> compatible but slower mode.
>
> Summing it up, this patch set adds the following features:
> - capability to support WT and WP cache modes on processors with full PAT
>    support
> - processors with no or uncorrect PAT support are still working as today, even
>    if WT or WP cache mode are selected by drivers for some pages
> - reduction of Xen special handling regarding cache mode
>
> Changes in V6:
> - add new patch 10 (x86: Remove looking for setting of _PAGE_PAT_LARGE in
>    pageattr.c) as suggested by Thomas Gleixner
> - replaced SOB of Stefan Bader by "Based-on-patch-by:" as suggested by
>    Borislav Petkov
>
> Changes in V5:
> - split up first patch as requested by Ingo Molnar and Thomas Gleixner
> - add a helper function in pat_init_cache_modes() as requested by Ingo Molnar
>
> Changes in V4:
> - rebased to 3.18-rc2
>
> Changes in V3:
> - corrected two minor nits (UC_MINUS, again) detected by Toshi Kani
>
> Changes in V2:
> - simplified handling of PAT MSR write under Xen as suggested by David Vrabel
> - removed resetting of pat_enabled under Xen
> - two small corrections requested by Toshi Kani (UC_MINUS cache mode in
>    vermilion driver, fix 32 bit kernel build failure)
> - correct build error on non-x86 arch by moving definition of
>    update_cache_mode_entry() to x86 specific header
>
> Changes since RFC:
> - renamed functions and variables as suggested by Toshi Kani
> - corrected cache mode bits for WT and WP
> - modified handling of PAT MSR write under Xen as suggested by Jan Beulich
>
>
> Juergen Gross (18):
>    x86: Make page cache mode a real type
>    x86: Use new cache mode type in include/asm/fb.h
>    x86: Use new cache mode type in drivers/video/fbdev/gbefb.c
>    x86: Use new cache mode type in drivers/video/fbdev/vermilion
>    x86: Use new cache mode type in arch/x86/pci
>    x86: Use new cache mode type in arch/x86/mm/init_64.c
>    x86: Use new cache mode type in asm/pgtable.h
>    x86: Use new cache mode type in mm/iomap_32.c
>    x86: Use new cache mode type in track_pfn_remap() and
>      track_pfn_insert()
>    x86: Remove looking for setting of _PAGE_PAT_LARGE in pageattr.c
>    x86: Use new cache mode type in setting page attributes
>    x86: Use new cache mode type in mm/ioremap.c
>    x86: Use new cache mode type in memtype related functions
>    x86: Clean up pgtable_types.h
>    x86: Support PAT bit in pagetable dump for lower levels
>    x86: Respect PAT bit when copying pte values between large and normal
>      pages
>    x86: Enable PAT to use cache mode translation tables
>    xen: Support Xen pv-domains using PAT
>
>   arch/x86/include/asm/cacheflush.h         |  38 ++++---
>   arch/x86/include/asm/fb.h                 |   6 +-
>   arch/x86/include/asm/io.h                 |   2 +-
>   arch/x86/include/asm/pat.h                |   7 +-
>   arch/x86/include/asm/pgtable.h            |  19 ++--
>   arch/x86/include/asm/pgtable_types.h      |  96 ++++++++++++----
>   arch/x86/mm/dump_pagetables.c             |  24 ++--
>   arch/x86/mm/init.c                        |  37 +++++++
>   arch/x86/mm/init_64.c                     |   9 +-
>   arch/x86/mm/iomap_32.c                    |  12 +-
>   arch/x86/mm/ioremap.c                     |  63 ++++++-----
>   arch/x86/mm/mm_internal.h                 |   2 +
>   arch/x86/mm/pageattr.c                    |  84 ++++++++------
>   arch/x86/mm/pat.c                         | 176 +++++++++++++++++++-----------
>   arch/x86/mm/pat_internal.h                |  22 ++--
>   arch/x86/mm/pat_rbtree.c                  |   8 +-
>   arch/x86/pci/i386.c                       |   4 +-
>   arch/x86/xen/enlighten.c                  |  25 ++---
>   arch/x86/xen/mmu.c                        |  47 +-------
>   arch/x86/xen/xen-ops.h                    |   1 -
>   drivers/video/fbdev/gbefb.c               |   3 +-
>   drivers/video/fbdev/vermilion/vermilion.c |   6 +-
>   22 files changed, 412 insertions(+), 279 deletions(-)
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 07:48:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 07:48:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpBbb-0005ma-BG; Fri, 14 Nov 2014 07:47:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linxingnku@gmail.com>) id 1Xp9pq-00035v-2S
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 05:54:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8B/16-24532-90995645; Fri, 14 Nov 2014 05:54:17 +0000
X-Env-Sender: linxingnku@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415944455!12601525!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9186 invoked from network); 14 Nov 2014 05:54:15 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 05:54:15 -0000
Received: by mail-wi0-f169.google.com with SMTP id n3so4094587wiv.0
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 21:54:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=b+YKDvdvcMMUvGWmNYU6M8iT+TqyoDaffaGCJqJLqDM=;
	b=IuH5PBdZdn9eYTI0JwRCkXweQ6LL3hOa1QbRRuO72B483YLr4h8IqsMBJFFW/1SuSZ
	nIXN0eSSu251qzknOwhc+r4TxgYXbEIP1XagnOKRVfqHczps+f7TvgmTzfbAED6ZKXu3
	nL2zi5dD/eUOXuckkTfu/Q38y+QsU38cxBvmjRZqlFwA9MNVFBWUldwiJLBRmFlVreDQ
	nMjbnzNlre+f10Zww942pauvPp2c60p8uJ6i3I5AxrOKtg2D5CdERR8+1LBuJc4cYKKY
	TKFS/B6D3d4gR7tYlMpnVmnJaVn65x4MN5J8r/teKSJZ7MHhCMI8pAHcYKeRUWRrgwPy
	iVJA==
MIME-Version: 1.0
X-Received: by 10.180.90.241 with SMTP id bz17mr4396325wib.41.1415944455371;
	Thu, 13 Nov 2014 21:54:15 -0800 (PST)
Received: by 10.27.132.215 with HTTP; Thu, 13 Nov 2014 21:54:15 -0800 (PST)
In-Reply-To: <54648EB3.8040703@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
Date: Thu, 13 Nov 2014 22:54:15 -0700
Message-ID: <CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
From: Xing Lin <linxingnku@gmail.com>
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
X-Mailman-Approved-At: Fri, 14 Nov 2014 07:47:42 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7999956999793404221=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7999956999793404221==
Content-Type: multipart/alternative; boundary=f46d043be02448c0250507cb42d0

--f46d043be02448c0250507cb42d0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Roger is correct: after I applied that patch and reinstalled qemu, modified
/etc/init.d/xencommons to use the modified version of qemu to provide disk
backend, I finally succeeded to create a xen guest! I noticed that this
patch was proposed yesterday: just in-time to solve my problem. :-)


root@compute1:/mnt/qemu-2.0.2# virsh --connect=3Dxen:///
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # list
 Id    Name                           State
----------------------------------------------------
 1     instance-00000028              running

virsh #

I have been blocked by this problem for almost three weeks and as far as I
know, I could not find any online tutorial on setting up xen based compute
node for openstack juno. I will document steps I take and share them with
the community.

Cheers,
-Xing

On Thu, Nov 13, 2014 at 3:57 AM, Roger Pau Monn=C3=A9 <roger.pau@citrix.com=
>
wrote:

> El 12/11/14 a les 19.41, Xing Lin ha escrit:
> > Hi,
> >
> > I am aware that Xen via libvirt is in the group C support for openstack
> but
> > since I am not able to install xenserver iso at compute machines I have=
,
> I
> > have to consider to use xen with libvirt (xcp-xapi is not available for
> > ubuntu14.04). I have three nodes, each one running ubuntu 14.04. I foll=
ow
> > the instruction to install juno in ubuntu 14.04 and it works (I can
> create
> > instances from openstack GUI - horizon) when I use kvm as the hyperviso=
r
> at
> > the compute node . However, if I switch to use xen as the hypervisor by
> > installing xen-hypervisor-amd64 or nova-compute-xen, it will fail to
> create
> > instances. It complained "backend for qemu disk is not ready". I checke=
d
> > and did not find qemu process running in dom0. I could not find
> > /etc/init.d/xencommons either. Then, I compiled and installed xen-4.4
> from
> > source code and I got xencommons in /etc/init.d. qemu process is runnin=
g
> in
> > dom0. However, the dom0 kernel crashes this time when I try to launch a=
n
> > instance from openstack GUI. I am able to create a xen guest with
> > virt-install from command line, with the following command.
> >
> > "$ virt-install --connect=3Dxen:/// --name u14.04.3 --ram 1024 --disk
> > u14.04.3.img,size=3D4,driver_name=3Dqemu --location
> > http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/
> --network
> > bridge=3Dvirbr0"
> >
> >
> > dmesg:
> >
> > [ 9443.130600] blkfront: xvda: flush diskcache: enabled; persistent
> grants:
> > enabled; indirect descriptors: disabled;
> > [ 9443.132818]  xvda: xvda1
> > [ 9444.604489] xen:grant_table: WARNING: g.e. 0x30 still in use!
> > [ 9444.604496] deferring g.e. 0x30 (pfn 0xffffffffffffffff)
> > [ 9444.604499] xen:grant_table: WARNING: g.e. 0x31 still in use!
> > [ 9444.604502] deferring g.e. 0x31 (pfn 0xffffffffffffffff)
> > [ 9444.604505] xen:grant_table: WARNING: g.e. 0x32 still in use!
> > [ 9444.604508] deferring g.e. 0x32 (pfn 0xffffffffffffffff)
> >   =3D=3D=3D=3D lots of them=3D=3D=3D=3D
> > [ 9444.604719] xen:grant_table: WARNING: g.e. 0xe still in use!
> > [ 9444.604721] deferring g.e. 0xe (pfn 0xffffffffffffffff)
> > [ 9444.604723] xen:grant_table: WARNING: g.e. 0xd still in use!
> > [ 9444.604725] deferring g.e. 0xd (pfn 0xffffffffffffffff)
> > [ 9448.325408] ------------[ cut here ]------------
> > [ 9448.325421] WARNING: CPU: 5 PID: 19902 at
> > /build/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+0=
x
> > 1a9/0x1b0()
> > [ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF          O
> > 3.13.0-33-generic #58-Ubuntu
> > [ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS
> 2.1.15
> > 09/02/2010
> > [ 9448.325497]  0000000000000009 ffff8802d13d9aa8 ffffffff8171bd04
> > 0000000000000000
> > [ 9448.325501]  ffff8802d13d9ae0 ffffffff810676cd 0000000000000000
> > 0000000000000001
> > [ 9448.325505]  ffff88030418ffe0 ffff88031d6ab180 0000000000000010
> > ffff8802d13d9af0
> > [ 9448.325509] Call Trace:
> > [ 9448.325518]  [<ffffffff8171bd04>] dump_stack+0x45/0x56
> > [ 9448.325523]  [<ffffffff810676cd>] warn_slowpath_common+0x7d/0xa0
> > [ 9448.325526]  [<ffffffff810677aa>] warn_slowpath_null+0x1a/0x20
> > [ 9448.325530]  [<ffffffff81004e99>] xen_mc_flush+0x1a9/0x1b0
> > [ 9448.325534]  [<ffffffff81006b99>] xen_set_pud_hyper+0x109/0x110
> > [ 9448.325538]  [<ffffffff81006c3b>] xen_set_pud+0x9b/0xb0
> > [ 9448.325543]  [<ffffffff81177f06>] __pmd_alloc+0xd6/0x110
> > [ 9448.325548]  [<ffffffff81182218>] move_page_tables+0x678/0x720
> > [ 9448.325552]  [<ffffffff8117ddb7>] ? vma_adjust+0x337/0x7d0
> > [ 9448.325557]  [<ffffffff811c23fd>] shift_arg_pages+0xbd/0x1b0
> > [ 9448.325560]  [<ffffffff81181671>] ? mprotect_fixup+0x151/0x290
> > [ 9448.325564]  [<ffffffff811c26cb>] setup_arg_pages+0x1db/0x200
> > [ 9448.325570]  [<ffffffff81213edc>] load_elf_binary+0x41c/0xd80
> > [ 9448.325576]  [<ffffffff8131d503>] ? ima_get_action+0x23/0x30
> > [ 9448.325579]  [<ffffffff8131c7e2>] ? process_measurement+0x82/0x2c0
> > [ 9448.325584]  [<ffffffff811c2f7f>] search_binary_handler+0x8f/0x1b0
> > [ 9448.325587]  [<ffffffff811c44f7>] do_execve_common.isra.22+0x5a7/0x7=
e0
> > [ 9448.325591]  [<ffffffff811c49c6>] SyS_execve+0x36/0x50
> > [ 9448.325596]  [<ffffffff8172cc99>] stub_execve+0x69/0xa0
> > [ 9448.325599] ---[ end trace 53ac16782e751c0a ]---
> > [ 9448.347994] ------------[ cut here ]------------
> > [ 9448.348004] WARNING: CPU: 1 PID: 19902 at
> > /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
> > =3D=3D=3D=3D more message ignored =3D=3D=3D=3D
> >
> >
> > I sent emails to the openstack mailing list and they gave me a few
> > suggestions. At last, Bob Ball suggested I should probably ask this
> > question on xen-devel mailing list. Any help will be highly appreciated=
!
>
> This looks like the bug already reported by George Dunlap, could you try
> to apply the following patch to qemu-xen and recompile?
>
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg01112.html
>
> Roger.
>
>

--f46d043be02448c0250507cb42d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>Roger is correct: after I applied t=
hat patch and reinstalled qemu, modified /etc/init.d/xencommons to use the =
modified version of qemu to provide disk backend, I finally succeeded to cr=
eate a xen guest! I noticed that this patch was proposed yesterday: just in=
-time to solve my problem. :-)</div><div><br></div><div><br></div><div><div=
>root@compute1:/mnt/qemu-2.0.2# virsh --connect=3Dxen:///</div><div>Welcome=
 to virsh, the virtualization interactive terminal.</div><div><br></div><di=
v>Type: =C2=A0&#39;help&#39; for help with commands</div><div>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0&#39;quit&#39; to quit</div><div><br></div><div>virsh # list<=
/div><div>=C2=A0Id =C2=A0 =C2=A0Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 State</div><div>------=
----------------------------------------------</div><div>=C2=A01 =C2=A0 =C2=
=A0 instance-00000028 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0runni=
ng</div><div><br></div><div>virsh #=C2=A0</div></div><div><br></div><div>I =
have been blocked by this problem for almost three weeks and as far as I kn=
ow, I could not find any online tutorial on setting up xen based compute no=
de for openstack juno. I will document steps I take and share them with the=
 community.=C2=A0</div><div><br></div><div>Cheers,</div><div>-Xing</div></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 13=
, 2014 at 3:57 AM, Roger Pau Monn=C3=A9 <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:roger.pau@citrix.com" target=3D"_blank">roger.pau@citrix.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">El 12/11/14 a les 19.41, Xin=
g Lin ha escrit:<br>
<div><div class=3D"h5">&gt; Hi,<br>
&gt;<br>
&gt; I am aware that Xen via libvirt is in the group C support for openstac=
k but<br>
&gt; since I am not able to install xenserver iso at compute machines I hav=
e, I<br>
&gt; have to consider to use xen with libvirt (xcp-xapi is not available fo=
r<br>
&gt; ubuntu14.04). I have three nodes, each one running ubuntu 14.04. I fol=
low<br>
&gt; the instruction to install juno in ubuntu 14.04 and it works (I can cr=
eate<br>
&gt; instances from openstack GUI - horizon) when I use kvm as the hypervis=
or at<br>
&gt; the compute node . However, if I switch to use xen as the hypervisor b=
y<br>
&gt; installing xen-hypervisor-amd64 or nova-compute-xen, it will fail to c=
reate<br>
&gt; instances. It complained &quot;backend for qemu disk is not ready&quot=
;. I checked<br>
&gt; and did not find qemu process running in dom0. I could not find<br>
&gt; /etc/init.d/xencommons either. Then, I compiled and installed xen-4.4 =
from<br>
&gt; source code and I got xencommons in /etc/init.d. qemu process is runni=
ng in<br>
&gt; dom0. However, the dom0 kernel crashes this time when I try to launch =
an<br>
&gt; instance from openstack GUI. I am able to create a xen guest with<br>
&gt; virt-install from command line, with the following command.<br>
&gt;<br>
&gt; &quot;$ virt-install --connect=3Dxen:/// --name u14.04.3 --ram 1024 --=
disk<br>
&gt; u14.04.3.img,size=3D4,driver_name=3Dqemu --location<br>
&gt; <a href=3D"http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-am=
d64/" target=3D"_blank">http://ftp.ubuntu.com/ubuntu/dists/trusty/main/inst=
aller-amd64/</a> --network<br>
&gt; bridge=3Dvirbr0&quot;<br>
&gt;<br>
&gt;<br>
&gt; dmesg:<br>
&gt;<br>
&gt; [ 9443.130600] blkfront: xvda: flush diskcache: enabled; persistent gr=
ants:<br>
&gt; enabled; indirect descriptors: disabled;<br>
&gt; [ 9443.132818]=C2=A0 xvda: xvda1<br>
&gt; [ 9444.604489] xen:grant_table: WARNING: g.e. 0x30 still in use!<br>
&gt; [ 9444.604496] deferring g.e. 0x30 (pfn 0xffffffffffffffff)<br>
&gt; [ 9444.604499] xen:grant_table: WARNING: g.e. 0x31 still in use!<br>
&gt; [ 9444.604502] deferring g.e. 0x31 (pfn 0xffffffffffffffff)<br>
&gt; [ 9444.604505] xen:grant_table: WARNING: g.e. 0x32 still in use!<br>
&gt; [ 9444.604508] deferring g.e. 0x32 (pfn 0xffffffffffffffff)<br>
&gt;=C2=A0 =C2=A0=3D=3D=3D=3D lots of them=3D=3D=3D=3D<br>
&gt; [ 9444.604719] xen:grant_table: WARNING: g.e. 0xe still in use!<br>
&gt; [ 9444.604721] deferring g.e. 0xe (pfn 0xffffffffffffffff)<br>
&gt; [ 9444.604723] xen:grant_table: WARNING: g.e. 0xd still in use!<br>
&gt; [ 9444.604725] deferring g.e. 0xd (pfn 0xffffffffffffffff)<br>
&gt; [ 9448.325408] ------------[ cut here ]------------<br>
&gt; [ 9448.325421] WARNING: CPU: 5 PID: 19902 at<br>
&gt; /build/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+=
0x<br>
&gt; 1a9/0x1b0()<br>
&gt; [ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 O<br>
&gt; 3.13.0-33-generic #58-Ubuntu<br>
&gt; [ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS 2.=
1.15<br>
&gt; 09/02/2010<br>
&gt; [ 9448.325497]=C2=A0 0000000000000009 ffff8802d13d9aa8 ffffffff8171bd0=
4<br>
&gt; 0000000000000000<br>
&gt; [ 9448.325501]=C2=A0 ffff8802d13d9ae0 ffffffff810676cd 000000000000000=
0<br>
&gt; 0000000000000001<br>
&gt; [ 9448.325505]=C2=A0 ffff88030418ffe0 ffff88031d6ab180 000000000000001=
0<br>
&gt; ffff8802d13d9af0<br>
&gt; [ 9448.325509] Call Trace:<br>
&gt; [ 9448.325518]=C2=A0 [&lt;ffffffff8171bd04&gt;] dump_stack+0x45/0x56<b=
r>
&gt; [ 9448.325523]=C2=A0 [&lt;ffffffff810676cd&gt;] warn_slowpath_common+0=
x7d/0xa0<br>
&gt; [ 9448.325526]=C2=A0 [&lt;ffffffff810677aa&gt;] warn_slowpath_null+0x1=
a/0x20<br>
&gt; [ 9448.325530]=C2=A0 [&lt;ffffffff81004e99&gt;] xen_mc_flush+0x1a9/0x1=
b0<br>
&gt; [ 9448.325534]=C2=A0 [&lt;ffffffff81006b99&gt;] xen_set_pud_hyper+0x10=
9/0x110<br>
&gt; [ 9448.325538]=C2=A0 [&lt;ffffffff81006c3b&gt;] xen_set_pud+0x9b/0xb0<=
br>
&gt; [ 9448.325543]=C2=A0 [&lt;ffffffff81177f06&gt;] __pmd_alloc+0xd6/0x110=
<br>
&gt; [ 9448.325548]=C2=A0 [&lt;ffffffff81182218&gt;] move_page_tables+0x678=
/0x720<br>
&gt; [ 9448.325552]=C2=A0 [&lt;ffffffff8117ddb7&gt;] ? vma_adjust+0x337/0x7=
d0<br>
&gt; [ 9448.325557]=C2=A0 [&lt;ffffffff811c23fd&gt;] shift_arg_pages+0xbd/0=
x1b0<br>
&gt; [ 9448.325560]=C2=A0 [&lt;ffffffff81181671&gt;] ? mprotect_fixup+0x151=
/0x290<br>
&gt; [ 9448.325564]=C2=A0 [&lt;ffffffff811c26cb&gt;] setup_arg_pages+0x1db/=
0x200<br>
&gt; [ 9448.325570]=C2=A0 [&lt;ffffffff81213edc&gt;] load_elf_binary+0x41c/=
0xd80<br>
&gt; [ 9448.325576]=C2=A0 [&lt;ffffffff8131d503&gt;] ? ima_get_action+0x23/=
0x30<br>
&gt; [ 9448.325579]=C2=A0 [&lt;ffffffff8131c7e2&gt;] ? process_measurement+=
0x82/0x2c0<br>
&gt; [ 9448.325584]=C2=A0 [&lt;ffffffff811c2f7f&gt;] search_binary_handler+=
0x8f/0x1b0<br>
&gt; [ 9448.325587]=C2=A0 [&lt;ffffffff811c44f7&gt;] do_execve_common.isra.=
22+0x5a7/0x7e0<br>
&gt; [ 9448.325591]=C2=A0 [&lt;ffffffff811c49c6&gt;] SyS_execve+0x36/0x50<b=
r>
&gt; [ 9448.325596]=C2=A0 [&lt;ffffffff8172cc99&gt;] stub_execve+0x69/0xa0<=
br>
&gt; [ 9448.325599] ---[ end trace 53ac16782e751c0a ]---<br>
&gt; [ 9448.347994] ------------[ cut here ]------------<br>
&gt; [ 9448.348004] WARNING: CPU: 1 PID: 19902 at<br>
&gt; /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()<br>
&gt; =3D=3D=3D=3D more message ignored =3D=3D=3D=3D<br>
&gt;<br>
&gt;<br>
&gt; I sent emails to the openstack mailing list and they gave me a few<br>
&gt; suggestions. At last, Bob Ball suggested I should probably ask this<br=
>
&gt; question on xen-devel mailing list. Any help will be highly appreciate=
d!<br>
<br>
</div></div>This looks like the bug already reported by George Dunlap, coul=
d you try<br>
to apply the following patch to qemu-xen and recompile?<br>
<br>
<a href=3D"http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg0=
1112.html" target=3D"_blank">http://lists.xenproject.org/archives/html/xen-=
devel/2014-11/msg01112.html</a><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Roger.<br>
<br>
</font></span></blockquote></div><br></div>

--f46d043be02448c0250507cb42d0--


--===============7999956999793404221==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7999956999793404221==--


From xen-devel-bounces@lists.xen.org Fri Nov 14 07:48:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 07:48:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpBbb-0005ma-BG; Fri, 14 Nov 2014 07:47:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linxingnku@gmail.com>) id 1Xp9pq-00035v-2S
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 05:54:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8B/16-24532-90995645; Fri, 14 Nov 2014 05:54:17 +0000
X-Env-Sender: linxingnku@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415944455!12601525!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9186 invoked from network); 14 Nov 2014 05:54:15 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 05:54:15 -0000
Received: by mail-wi0-f169.google.com with SMTP id n3so4094587wiv.0
	for <xen-devel@lists.xen.org>; Thu, 13 Nov 2014 21:54:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=b+YKDvdvcMMUvGWmNYU6M8iT+TqyoDaffaGCJqJLqDM=;
	b=IuH5PBdZdn9eYTI0JwRCkXweQ6LL3hOa1QbRRuO72B483YLr4h8IqsMBJFFW/1SuSZ
	nIXN0eSSu251qzknOwhc+r4TxgYXbEIP1XagnOKRVfqHczps+f7TvgmTzfbAED6ZKXu3
	nL2zi5dD/eUOXuckkTfu/Q38y+QsU38cxBvmjRZqlFwA9MNVFBWUldwiJLBRmFlVreDQ
	nMjbnzNlre+f10Zww942pauvPp2c60p8uJ6i3I5AxrOKtg2D5CdERR8+1LBuJc4cYKKY
	TKFS/B6D3d4gR7tYlMpnVmnJaVn65x4MN5J8r/teKSJZ7MHhCMI8pAHcYKeRUWRrgwPy
	iVJA==
MIME-Version: 1.0
X-Received: by 10.180.90.241 with SMTP id bz17mr4396325wib.41.1415944455371;
	Thu, 13 Nov 2014 21:54:15 -0800 (PST)
Received: by 10.27.132.215 with HTTP; Thu, 13 Nov 2014 21:54:15 -0800 (PST)
In-Reply-To: <54648EB3.8040703@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
Date: Thu, 13 Nov 2014 22:54:15 -0700
Message-ID: <CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
From: Xing Lin <linxingnku@gmail.com>
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
X-Mailman-Approved-At: Fri, 14 Nov 2014 07:47:42 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7999956999793404221=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7999956999793404221==
Content-Type: multipart/alternative; boundary=f46d043be02448c0250507cb42d0

--f46d043be02448c0250507cb42d0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Roger is correct: after I applied that patch and reinstalled qemu, modified
/etc/init.d/xencommons to use the modified version of qemu to provide disk
backend, I finally succeeded to create a xen guest! I noticed that this
patch was proposed yesterday: just in-time to solve my problem. :-)


root@compute1:/mnt/qemu-2.0.2# virsh --connect=3Dxen:///
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # list
 Id    Name                           State
----------------------------------------------------
 1     instance-00000028              running

virsh #

I have been blocked by this problem for almost three weeks and as far as I
know, I could not find any online tutorial on setting up xen based compute
node for openstack juno. I will document steps I take and share them with
the community.

Cheers,
-Xing

On Thu, Nov 13, 2014 at 3:57 AM, Roger Pau Monn=C3=A9 <roger.pau@citrix.com=
>
wrote:

> El 12/11/14 a les 19.41, Xing Lin ha escrit:
> > Hi,
> >
> > I am aware that Xen via libvirt is in the group C support for openstack
> but
> > since I am not able to install xenserver iso at compute machines I have=
,
> I
> > have to consider to use xen with libvirt (xcp-xapi is not available for
> > ubuntu14.04). I have three nodes, each one running ubuntu 14.04. I foll=
ow
> > the instruction to install juno in ubuntu 14.04 and it works (I can
> create
> > instances from openstack GUI - horizon) when I use kvm as the hyperviso=
r
> at
> > the compute node . However, if I switch to use xen as the hypervisor by
> > installing xen-hypervisor-amd64 or nova-compute-xen, it will fail to
> create
> > instances. It complained "backend for qemu disk is not ready". I checke=
d
> > and did not find qemu process running in dom0. I could not find
> > /etc/init.d/xencommons either. Then, I compiled and installed xen-4.4
> from
> > source code and I got xencommons in /etc/init.d. qemu process is runnin=
g
> in
> > dom0. However, the dom0 kernel crashes this time when I try to launch a=
n
> > instance from openstack GUI. I am able to create a xen guest with
> > virt-install from command line, with the following command.
> >
> > "$ virt-install --connect=3Dxen:/// --name u14.04.3 --ram 1024 --disk
> > u14.04.3.img,size=3D4,driver_name=3Dqemu --location
> > http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/
> --network
> > bridge=3Dvirbr0"
> >
> >
> > dmesg:
> >
> > [ 9443.130600] blkfront: xvda: flush diskcache: enabled; persistent
> grants:
> > enabled; indirect descriptors: disabled;
> > [ 9443.132818]  xvda: xvda1
> > [ 9444.604489] xen:grant_table: WARNING: g.e. 0x30 still in use!
> > [ 9444.604496] deferring g.e. 0x30 (pfn 0xffffffffffffffff)
> > [ 9444.604499] xen:grant_table: WARNING: g.e. 0x31 still in use!
> > [ 9444.604502] deferring g.e. 0x31 (pfn 0xffffffffffffffff)
> > [ 9444.604505] xen:grant_table: WARNING: g.e. 0x32 still in use!
> > [ 9444.604508] deferring g.e. 0x32 (pfn 0xffffffffffffffff)
> >   =3D=3D=3D=3D lots of them=3D=3D=3D=3D
> > [ 9444.604719] xen:grant_table: WARNING: g.e. 0xe still in use!
> > [ 9444.604721] deferring g.e. 0xe (pfn 0xffffffffffffffff)
> > [ 9444.604723] xen:grant_table: WARNING: g.e. 0xd still in use!
> > [ 9444.604725] deferring g.e. 0xd (pfn 0xffffffffffffffff)
> > [ 9448.325408] ------------[ cut here ]------------
> > [ 9448.325421] WARNING: CPU: 5 PID: 19902 at
> > /build/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+0=
x
> > 1a9/0x1b0()
> > [ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF          O
> > 3.13.0-33-generic #58-Ubuntu
> > [ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS
> 2.1.15
> > 09/02/2010
> > [ 9448.325497]  0000000000000009 ffff8802d13d9aa8 ffffffff8171bd04
> > 0000000000000000
> > [ 9448.325501]  ffff8802d13d9ae0 ffffffff810676cd 0000000000000000
> > 0000000000000001
> > [ 9448.325505]  ffff88030418ffe0 ffff88031d6ab180 0000000000000010
> > ffff8802d13d9af0
> > [ 9448.325509] Call Trace:
> > [ 9448.325518]  [<ffffffff8171bd04>] dump_stack+0x45/0x56
> > [ 9448.325523]  [<ffffffff810676cd>] warn_slowpath_common+0x7d/0xa0
> > [ 9448.325526]  [<ffffffff810677aa>] warn_slowpath_null+0x1a/0x20
> > [ 9448.325530]  [<ffffffff81004e99>] xen_mc_flush+0x1a9/0x1b0
> > [ 9448.325534]  [<ffffffff81006b99>] xen_set_pud_hyper+0x109/0x110
> > [ 9448.325538]  [<ffffffff81006c3b>] xen_set_pud+0x9b/0xb0
> > [ 9448.325543]  [<ffffffff81177f06>] __pmd_alloc+0xd6/0x110
> > [ 9448.325548]  [<ffffffff81182218>] move_page_tables+0x678/0x720
> > [ 9448.325552]  [<ffffffff8117ddb7>] ? vma_adjust+0x337/0x7d0
> > [ 9448.325557]  [<ffffffff811c23fd>] shift_arg_pages+0xbd/0x1b0
> > [ 9448.325560]  [<ffffffff81181671>] ? mprotect_fixup+0x151/0x290
> > [ 9448.325564]  [<ffffffff811c26cb>] setup_arg_pages+0x1db/0x200
> > [ 9448.325570]  [<ffffffff81213edc>] load_elf_binary+0x41c/0xd80
> > [ 9448.325576]  [<ffffffff8131d503>] ? ima_get_action+0x23/0x30
> > [ 9448.325579]  [<ffffffff8131c7e2>] ? process_measurement+0x82/0x2c0
> > [ 9448.325584]  [<ffffffff811c2f7f>] search_binary_handler+0x8f/0x1b0
> > [ 9448.325587]  [<ffffffff811c44f7>] do_execve_common.isra.22+0x5a7/0x7=
e0
> > [ 9448.325591]  [<ffffffff811c49c6>] SyS_execve+0x36/0x50
> > [ 9448.325596]  [<ffffffff8172cc99>] stub_execve+0x69/0xa0
> > [ 9448.325599] ---[ end trace 53ac16782e751c0a ]---
> > [ 9448.347994] ------------[ cut here ]------------
> > [ 9448.348004] WARNING: CPU: 1 PID: 19902 at
> > /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()
> > =3D=3D=3D=3D more message ignored =3D=3D=3D=3D
> >
> >
> > I sent emails to the openstack mailing list and they gave me a few
> > suggestions. At last, Bob Ball suggested I should probably ask this
> > question on xen-devel mailing list. Any help will be highly appreciated=
!
>
> This looks like the bug already reported by George Dunlap, could you try
> to apply the following patch to qemu-xen and recompile?
>
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg01112.html
>
> Roger.
>
>

--f46d043be02448c0250507cb42d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>Roger is correct: after I applied t=
hat patch and reinstalled qemu, modified /etc/init.d/xencommons to use the =
modified version of qemu to provide disk backend, I finally succeeded to cr=
eate a xen guest! I noticed that this patch was proposed yesterday: just in=
-time to solve my problem. :-)</div><div><br></div><div><br></div><div><div=
>root@compute1:/mnt/qemu-2.0.2# virsh --connect=3Dxen:///</div><div>Welcome=
 to virsh, the virtualization interactive terminal.</div><div><br></div><di=
v>Type: =C2=A0&#39;help&#39; for help with commands</div><div>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0&#39;quit&#39; to quit</div><div><br></div><div>virsh # list<=
/div><div>=C2=A0Id =C2=A0 =C2=A0Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 State</div><div>------=
----------------------------------------------</div><div>=C2=A01 =C2=A0 =C2=
=A0 instance-00000028 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0runni=
ng</div><div><br></div><div>virsh #=C2=A0</div></div><div><br></div><div>I =
have been blocked by this problem for almost three weeks and as far as I kn=
ow, I could not find any online tutorial on setting up xen based compute no=
de for openstack juno. I will document steps I take and share them with the=
 community.=C2=A0</div><div><br></div><div>Cheers,</div><div>-Xing</div></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 13=
, 2014 at 3:57 AM, Roger Pau Monn=C3=A9 <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:roger.pau@citrix.com" target=3D"_blank">roger.pau@citrix.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">El 12/11/14 a les 19.41, Xin=
g Lin ha escrit:<br>
<div><div class=3D"h5">&gt; Hi,<br>
&gt;<br>
&gt; I am aware that Xen via libvirt is in the group C support for openstac=
k but<br>
&gt; since I am not able to install xenserver iso at compute machines I hav=
e, I<br>
&gt; have to consider to use xen with libvirt (xcp-xapi is not available fo=
r<br>
&gt; ubuntu14.04). I have three nodes, each one running ubuntu 14.04. I fol=
low<br>
&gt; the instruction to install juno in ubuntu 14.04 and it works (I can cr=
eate<br>
&gt; instances from openstack GUI - horizon) when I use kvm as the hypervis=
or at<br>
&gt; the compute node . However, if I switch to use xen as the hypervisor b=
y<br>
&gt; installing xen-hypervisor-amd64 or nova-compute-xen, it will fail to c=
reate<br>
&gt; instances. It complained &quot;backend for qemu disk is not ready&quot=
;. I checked<br>
&gt; and did not find qemu process running in dom0. I could not find<br>
&gt; /etc/init.d/xencommons either. Then, I compiled and installed xen-4.4 =
from<br>
&gt; source code and I got xencommons in /etc/init.d. qemu process is runni=
ng in<br>
&gt; dom0. However, the dom0 kernel crashes this time when I try to launch =
an<br>
&gt; instance from openstack GUI. I am able to create a xen guest with<br>
&gt; virt-install from command line, with the following command.<br>
&gt;<br>
&gt; &quot;$ virt-install --connect=3Dxen:/// --name u14.04.3 --ram 1024 --=
disk<br>
&gt; u14.04.3.img,size=3D4,driver_name=3Dqemu --location<br>
&gt; <a href=3D"http://ftp.ubuntu.com/ubuntu/dists/trusty/main/installer-am=
d64/" target=3D"_blank">http://ftp.ubuntu.com/ubuntu/dists/trusty/main/inst=
aller-amd64/</a> --network<br>
&gt; bridge=3Dvirbr0&quot;<br>
&gt;<br>
&gt;<br>
&gt; dmesg:<br>
&gt;<br>
&gt; [ 9443.130600] blkfront: xvda: flush diskcache: enabled; persistent gr=
ants:<br>
&gt; enabled; indirect descriptors: disabled;<br>
&gt; [ 9443.132818]=C2=A0 xvda: xvda1<br>
&gt; [ 9444.604489] xen:grant_table: WARNING: g.e. 0x30 still in use!<br>
&gt; [ 9444.604496] deferring g.e. 0x30 (pfn 0xffffffffffffffff)<br>
&gt; [ 9444.604499] xen:grant_table: WARNING: g.e. 0x31 still in use!<br>
&gt; [ 9444.604502] deferring g.e. 0x31 (pfn 0xffffffffffffffff)<br>
&gt; [ 9444.604505] xen:grant_table: WARNING: g.e. 0x32 still in use!<br>
&gt; [ 9444.604508] deferring g.e. 0x32 (pfn 0xffffffffffffffff)<br>
&gt;=C2=A0 =C2=A0=3D=3D=3D=3D lots of them=3D=3D=3D=3D<br>
&gt; [ 9444.604719] xen:grant_table: WARNING: g.e. 0xe still in use!<br>
&gt; [ 9444.604721] deferring g.e. 0xe (pfn 0xffffffffffffffff)<br>
&gt; [ 9444.604723] xen:grant_table: WARNING: g.e. 0xd still in use!<br>
&gt; [ 9444.604725] deferring g.e. 0xd (pfn 0xffffffffffffffff)<br>
&gt; [ 9448.325408] ------------[ cut here ]------------<br>
&gt; [ 9448.325421] WARNING: CPU: 5 PID: 19902 at<br>
&gt; /build/buildd/linux-3.13.0/arch/x86/xen/multicalls.c:129 xen_mc_flush+=
0x<br>
&gt; 1a9/0x1b0()<br>
&gt; [ 9448.325492] CPU: 5 PID: 19902 Comm: sudo Tainted: GF=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 O<br>
&gt; 3.13.0-33-generic #58-Ubuntu<br>
&gt; [ 9448.325494] Hardware name: Dell Inc. PowerEdge R710/00W9X3, BIOS 2.=
1.15<br>
&gt; 09/02/2010<br>
&gt; [ 9448.325497]=C2=A0 0000000000000009 ffff8802d13d9aa8 ffffffff8171bd0=
4<br>
&gt; 0000000000000000<br>
&gt; [ 9448.325501]=C2=A0 ffff8802d13d9ae0 ffffffff810676cd 000000000000000=
0<br>
&gt; 0000000000000001<br>
&gt; [ 9448.325505]=C2=A0 ffff88030418ffe0 ffff88031d6ab180 000000000000001=
0<br>
&gt; ffff8802d13d9af0<br>
&gt; [ 9448.325509] Call Trace:<br>
&gt; [ 9448.325518]=C2=A0 [&lt;ffffffff8171bd04&gt;] dump_stack+0x45/0x56<b=
r>
&gt; [ 9448.325523]=C2=A0 [&lt;ffffffff810676cd&gt;] warn_slowpath_common+0=
x7d/0xa0<br>
&gt; [ 9448.325526]=C2=A0 [&lt;ffffffff810677aa&gt;] warn_slowpath_null+0x1=
a/0x20<br>
&gt; [ 9448.325530]=C2=A0 [&lt;ffffffff81004e99&gt;] xen_mc_flush+0x1a9/0x1=
b0<br>
&gt; [ 9448.325534]=C2=A0 [&lt;ffffffff81006b99&gt;] xen_set_pud_hyper+0x10=
9/0x110<br>
&gt; [ 9448.325538]=C2=A0 [&lt;ffffffff81006c3b&gt;] xen_set_pud+0x9b/0xb0<=
br>
&gt; [ 9448.325543]=C2=A0 [&lt;ffffffff81177f06&gt;] __pmd_alloc+0xd6/0x110=
<br>
&gt; [ 9448.325548]=C2=A0 [&lt;ffffffff81182218&gt;] move_page_tables+0x678=
/0x720<br>
&gt; [ 9448.325552]=C2=A0 [&lt;ffffffff8117ddb7&gt;] ? vma_adjust+0x337/0x7=
d0<br>
&gt; [ 9448.325557]=C2=A0 [&lt;ffffffff811c23fd&gt;] shift_arg_pages+0xbd/0=
x1b0<br>
&gt; [ 9448.325560]=C2=A0 [&lt;ffffffff81181671&gt;] ? mprotect_fixup+0x151=
/0x290<br>
&gt; [ 9448.325564]=C2=A0 [&lt;ffffffff811c26cb&gt;] setup_arg_pages+0x1db/=
0x200<br>
&gt; [ 9448.325570]=C2=A0 [&lt;ffffffff81213edc&gt;] load_elf_binary+0x41c/=
0xd80<br>
&gt; [ 9448.325576]=C2=A0 [&lt;ffffffff8131d503&gt;] ? ima_get_action+0x23/=
0x30<br>
&gt; [ 9448.325579]=C2=A0 [&lt;ffffffff8131c7e2&gt;] ? process_measurement+=
0x82/0x2c0<br>
&gt; [ 9448.325584]=C2=A0 [&lt;ffffffff811c2f7f&gt;] search_binary_handler+=
0x8f/0x1b0<br>
&gt; [ 9448.325587]=C2=A0 [&lt;ffffffff811c44f7&gt;] do_execve_common.isra.=
22+0x5a7/0x7e0<br>
&gt; [ 9448.325591]=C2=A0 [&lt;ffffffff811c49c6&gt;] SyS_execve+0x36/0x50<b=
r>
&gt; [ 9448.325596]=C2=A0 [&lt;ffffffff8172cc99&gt;] stub_execve+0x69/0xa0<=
br>
&gt; [ 9448.325599] ---[ end trace 53ac16782e751c0a ]---<br>
&gt; [ 9448.347994] ------------[ cut here ]------------<br>
&gt; [ 9448.348004] WARNING: CPU: 1 PID: 19902 at<br>
&gt; /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170()<br>
&gt; =3D=3D=3D=3D more message ignored =3D=3D=3D=3D<br>
&gt;<br>
&gt;<br>
&gt; I sent emails to the openstack mailing list and they gave me a few<br>
&gt; suggestions. At last, Bob Ball suggested I should probably ask this<br=
>
&gt; question on xen-devel mailing list. Any help will be highly appreciate=
d!<br>
<br>
</div></div>This looks like the bug already reported by George Dunlap, coul=
d you try<br>
to apply the following patch to qemu-xen and recompile?<br>
<br>
<a href=3D"http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg0=
1112.html" target=3D"_blank">http://lists.xenproject.org/archives/html/xen-=
devel/2014-11/msg01112.html</a><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Roger.<br>
<br>
</font></span></blockquote></div><br></div>

--f46d043be02448c0250507cb42d0--


--===============7999956999793404221==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7999956999793404221==--


From xen-devel-bounces@lists.xen.org Fri Nov 14 07:50:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 07: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.xen.org>)
	id 1XpBeQ-0005uV-47; Fri, 14 Nov 2014 07:50:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XpBeO-0005uQ-WB
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 07:50:37 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	98/7A-22777-C44B5645; Fri, 14 Nov 2014 07:50:36 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415951434!11299739!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17957 invoked from network); 14 Nov 2014 07:50:34 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-5.tower-206.messagelabs.com with SMTP;
	14 Nov 2014 07:50:34 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 13 Nov 2014 23:50:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,384,1413270000"; d="scan'208";a="622251957"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 13 Nov 2014 23:50:31 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 14 Nov 2014 15:50:29 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Fri, 14 Nov 2014 15:50:27 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/l9ZNIwAqiexHE6x0A+uPl9BJ5xfoBCA
Date: Fri, 14 Nov 2014 07:50:27 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A604A7@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz>
In-Reply-To: <54632F72.7020509@m2r.biz>
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: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
> Sent: Wednesday, November 12, 2014 5:59 PM
> To: Hu, Robert; xen-devel@lists.xen.org
> Cc: JBeulich@suse.com
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> Il 12/11/2014 07:58, Hu, Robert ha scritto:
> > Hi All,
> >
> > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> >
> > Test environment:
> > Xen: Xen 4.5-rc1
> > Dom0: Linux kernel 3.17.0
> > Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP
> >
> > New bugs(9):
> > 1. with "xen_platform_pci=0" option, the guest with VT-d device fails to boot
> up
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1893
> 
> Have you tried with recent domU's kernel that contain this commit?
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a
> 3bbaca868043cc45b3ad3786dd48a90235
> If I remember good there is a critical boot problem with
> "xen_platform_pci=0" and without it.
> 
> > 2. Failed to hotplug a VT-d device with XEN4.5-RC1
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> > 3. Fail to hot add multi devices to guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895
> > 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
> > 5. Dom0 failed to resume from S3 power state
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897
> > 6. Networking is unavailable after save&restore Windows guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> 
> Should be the same problem I reported 1 year ago or more and still
> present, the workaround is use fixed mac address in domUs xl cfg :(
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
if we assign vif as following, it works with fix-mac.
	# Network devices
	vif = [ 'type=ioemu, mac=00:15:17:19:2D:35, bridge=xenbr0' ]
if we assign VF to guest as following, it till don't have network working with fix-mac; after save&restore, the networking status shows as "Network cable unplugged", without IP address.
    #SR-IOV VF device BDF
    pci = [ '81:10.1' ]
> 
> > 7. Error msg occurred after attaching multi SR-IOV VF device to running guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899
> > 8. "xl vcpu-set " will report error when adding vcpus number
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1900
> > 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
> >
> > 1 old legacy bug(1):
> > 1. Guest hang after resume from S3
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1828
> >
> >
> > Best Regards,
> > Robert
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Nov 14 07:50:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 07: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.xen.org>)
	id 1XpBeQ-0005uV-47; Fri, 14 Nov 2014 07:50:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XpBeO-0005uQ-WB
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 07:50:37 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	98/7A-22777-C44B5645; Fri, 14 Nov 2014 07:50:36 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415951434!11299739!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17957 invoked from network); 14 Nov 2014 07:50:34 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-5.tower-206.messagelabs.com with SMTP;
	14 Nov 2014 07:50:34 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 13 Nov 2014 23:50:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,384,1413270000"; d="scan'208";a="622251957"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 13 Nov 2014 23:50:31 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 14 Nov 2014 15:50:29 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Fri, 14 Nov 2014 15:50:27 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/l9ZNIwAqiexHE6x0A+uPl9BJ5xfoBCA
Date: Fri, 14 Nov 2014 07:50:27 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A604A7@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz>
In-Reply-To: <54632F72.7020509@m2r.biz>
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: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
> Sent: Wednesday, November 12, 2014 5:59 PM
> To: Hu, Robert; xen-devel@lists.xen.org
> Cc: JBeulich@suse.com
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> Il 12/11/2014 07:58, Hu, Robert ha scritto:
> > Hi All,
> >
> > This is a bug summary for Xen 4.5-rc1 on Intel Server platforms.
> >
> > Test environment:
> > Xen: Xen 4.5-rc1
> > Dom0: Linux kernel 3.17.0
> > Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP
> >
> > New bugs(9):
> > 1. with "xen_platform_pci=0" option, the guest with VT-d device fails to boot
> up
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1893
> 
> Have you tried with recent domU's kernel that contain this commit?
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a
> 3bbaca868043cc45b3ad3786dd48a90235
> If I remember good there is a critical boot problem with
> "xen_platform_pci=0" and without it.
> 
> > 2. Failed to hotplug a VT-d device with XEN4.5-RC1
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> > 3. Fail to hot add multi devices to guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895
> > 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896
> > 5. Dom0 failed to resume from S3 power state
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897
> > 6. Networking is unavailable after save&restore Windows guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> 
> Should be the same problem I reported 1 year ago or more and still
> present, the workaround is use fixed mac address in domUs xl cfg :(
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
if we assign vif as following, it works with fix-mac.
	# Network devices
	vif = [ 'type=ioemu, mac=00:15:17:19:2D:35, bridge=xenbr0' ]
if we assign VF to guest as following, it till don't have network working with fix-mac; after save&restore, the networking status shows as "Network cable unplugged", without IP address.
    #SR-IOV VF device BDF
    pci = [ '81:10.1' ]
> 
> > 7. Error msg occurred after attaching multi SR-IOV VF device to running guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899
> > 8. "xl vcpu-set " will report error when adding vcpus number
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1900
> > 9. "xl psr-cmt-show cache_occupancy $dom_id" will report error
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901
> >
> > 1 old legacy bug(1):
> > 1. Guest hang after resume from S3
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1828
> >
> >
> > Best Regards,
> > Robert
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Nov 14 08:21:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 08:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpC8S-00079E-Mk; Fri, 14 Nov 2014 08:21:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpC8Q-000799-OR
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 08:21:38 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	34/43-08051-29BB5645; Fri, 14 Nov 2014 08:21:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415953297!7868809!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9963 invoked from network); 14 Nov 2014 08:21:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 08:21:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 08:21:36 +0000
Message-Id: <5465C99F0200007800047829@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 08:21:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<546420CE.1080908@intel.com> <5465671C.4070007@intel.com>
In-Reply-To: <5465671C.4070007@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 03:21, <tiejun.chen@intel.com> wrote:
> Even if eventually we'll reorder that sequence, this just change that 
> approach to get BDF. Are you fine to this subsequent change?

You again pass a struct domain pointer to the IOMMU-specific
function. I already told you not to do so - the domain specific
aspect should be taken care of by the callback function, i.e. you
need to make SBDF available to it (just like you already properly
did in the previous round for BDF). I suppose that'll at once make
the ugly open coding of for_each_rmrr_device() unnecessary -
you can just use that construct as replacement for what right
now is list_for_each_entry().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 08:21:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 08:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpC8S-00079E-Mk; Fri, 14 Nov 2014 08:21:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpC8Q-000799-OR
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 08:21:38 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	34/43-08051-29BB5645; Fri, 14 Nov 2014 08:21:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415953297!7868809!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9963 invoked from network); 14 Nov 2014 08:21:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 08:21:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 08:21:36 +0000
Message-Id: <5465C99F0200007800047829@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 08:21:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<546420CE.1080908@intel.com> <5465671C.4070007@intel.com>
In-Reply-To: <5465671C.4070007@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 03:21, <tiejun.chen@intel.com> wrote:
> Even if eventually we'll reorder that sequence, this just change that 
> approach to get BDF. Are you fine to this subsequent change?

You again pass a struct domain pointer to the IOMMU-specific
function. I already told you not to do so - the domain specific
aspect should be taken care of by the callback function, i.e. you
need to make SBDF available to it (just like you already properly
did in the previous round for BDF). I suppose that'll at once make
the ugly open coding of for_each_rmrr_device() unnecessary -
you can just use that construct as replacement for what right
now is list_for_each_entry().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 08:23:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 08:23:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpC9p-0007Pz-5G; Fri, 14 Nov 2014 08:23:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpC9o-0007Ps-79
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 08:23:04 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	00/EC-09842-7EBB5645; Fri, 14 Nov 2014 08:23:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415953383!12725390!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27450 invoked from network); 14 Nov 2014 08:23:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 08:23:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 08:23:02 +0000
Message-Id: <5465C9F5020000780004782F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 08:23:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415894589-18256-1-git-send-email-tim@xen.org>
	<5464E80202000078000474B1@mail.emea.novell.com>
	<20141113191816.GC11727@laptop.dumpdata.com>
In-Reply-To: <20141113191816.GC11727@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, keir@xen.org,
	ian.campbell@citrix.com, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] xen: remove Xencomm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 20:18, <konrad.wilk@oracle.com> wrote:
> On Thu, Nov 13, 2014 at 04:18:58PM +0000, Jan Beulich wrote:
>> >>> On 13.11.14 at 17:03, <tim@xen.org> wrote:
>> > Being a feature that has only been used by ia64 and/or ppc it
>> > doesn't seem like we need to keep it any longer in the tree.
>> > 
>> > So remove it.
>> > 
>> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> > Signed-off-by: Tim Deegan <tim@xen.org>
>> 
>> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> Are folks OK if this is deferred to Xen 4.6?

Sure, albeit I can't resist to say that the change is zero risk.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 08:23:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 08:23:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpC9p-0007Pz-5G; Fri, 14 Nov 2014 08:23:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpC9o-0007Ps-79
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 08:23:04 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	00/EC-09842-7EBB5645; Fri, 14 Nov 2014 08:23:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415953383!12725390!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27450 invoked from network); 14 Nov 2014 08:23:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 08:23:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 08:23:02 +0000
Message-Id: <5465C9F5020000780004782F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 08:23:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415894589-18256-1-git-send-email-tim@xen.org>
	<5464E80202000078000474B1@mail.emea.novell.com>
	<20141113191816.GC11727@laptop.dumpdata.com>
In-Reply-To: <20141113191816.GC11727@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, keir@xen.org,
	ian.campbell@citrix.com, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] xen: remove Xencomm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.11.14 at 20:18, <konrad.wilk@oracle.com> wrote:
> On Thu, Nov 13, 2014 at 04:18:58PM +0000, Jan Beulich wrote:
>> >>> On 13.11.14 at 17:03, <tim@xen.org> wrote:
>> > Being a feature that has only been used by ia64 and/or ppc it
>> > doesn't seem like we need to keep it any longer in the tree.
>> > 
>> > So remove it.
>> > 
>> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> > Signed-off-by: Tim Deegan <tim@xen.org>
>> 
>> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> Are folks OK if this is deferred to Xen 4.6?

Sure, albeit I can't resist to say that the change is zero risk.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 08:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 08:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpCEF-0007bX-RX; Fri, 14 Nov 2014 08:27:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpCEE-0007bS-TT
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 08:27:39 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A7/3F-23865-AFCB5645; Fri, 14 Nov 2014 08:27:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415953657!11289119!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9581 invoked from network); 14 Nov 2014 08:27:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 08:27:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 08:27:37 +0000
Message-Id: <5465CB080200007800047845@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 08:27:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Simon Martin" <furryfuttock@gmail.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
In-Reply-To: <429773295.20141113144907@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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 13.11.14 at 18:49, <furryfuttock@gmail.com> wrote:
>>> Yes,  the  first thing I do in the driver is set the PCI configuration
>>> access  bits to 7 that should enable IO space, Memory Space and Master
>>> BUS access.
>>> 
>>> As  a  test I disabled this and all reads to the PCI device return -1,
>>> even the first one.
> 
>> I implied your earlier statement to mean that. But - did you also
>> verify that the three flags actually end up set (ideally from both
>> DomU and Dom0 perspective)? The PCI backend may be screwing
>> up things...
> 
> Yes I do verify the write. How do I check this from Dom0?

Just use lspci.

>>> I  agree,  this looks more than a hang than a crash. I've just found a
>>> link to the USB debug cable. I've ordered one but it will take a while
> 
>> And I hope you first verified that your system meets the criteria
>> for this to work in the first place?
> 
> I followed the checks in the Kernel earlyprintk debugging HOWTO, i.e.
> lspci -vvv to check the USB debug capability, and it verified. The
> device is ordered and now just to wait....

As said before, the less obvious thing to verify is that there must not
be a (hidden) hub in between for the port that can be used as the
debug one. Some systems (I actually have at least one of that kind)
surface some or all of their USB port via some internal hub; lsusb
should be able to tell you. Anyway - you'll see whether it works when
the device arrives.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 08:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 08:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpCEF-0007bX-RX; Fri, 14 Nov 2014 08:27:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpCEE-0007bS-TT
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 08:27:39 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A7/3F-23865-AFCB5645; Fri, 14 Nov 2014 08:27:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415953657!11289119!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9581 invoked from network); 14 Nov 2014 08:27:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 08:27:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 08:27:37 +0000
Message-Id: <5465CB080200007800047845@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 08:27:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Simon Martin" <furryfuttock@gmail.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
In-Reply-To: <429773295.20141113144907@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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 13.11.14 at 18:49, <furryfuttock@gmail.com> wrote:
>>> Yes,  the  first thing I do in the driver is set the PCI configuration
>>> access  bits to 7 that should enable IO space, Memory Space and Master
>>> BUS access.
>>> 
>>> As  a  test I disabled this and all reads to the PCI device return -1,
>>> even the first one.
> 
>> I implied your earlier statement to mean that. But - did you also
>> verify that the three flags actually end up set (ideally from both
>> DomU and Dom0 perspective)? The PCI backend may be screwing
>> up things...
> 
> Yes I do verify the write. How do I check this from Dom0?

Just use lspci.

>>> I  agree,  this looks more than a hang than a crash. I've just found a
>>> link to the USB debug cable. I've ordered one but it will take a while
> 
>> And I hope you first verified that your system meets the criteria
>> for this to work in the first place?
> 
> I followed the checks in the Kernel earlyprintk debugging HOWTO, i.e.
> lspci -vvv to check the USB debug capability, and it verified. The
> device is ordered and now just to wait....

As said before, the less obvious thing to verify is that there must not
be a (hidden) hub in between for the port that can be used as the
debug one. Some systems (I actually have at least one of that kind)
surface some or all of their USB port via some internal hub; lsusb
should be able to tell you. Anyway - you'll see whether it works when
the device arrives.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 08:55:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 08:55:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpCeW-0008MJ-70; Fri, 14 Nov 2014 08:54:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpCeU-0008ME-U4
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 08:54:47 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	74/8F-26740-653C5645; Fri, 14 Nov 2014 08:54:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415955283!7623390!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30502 invoked from network); 14 Nov 2014 08:54:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 08:54:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191314226"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 03:54:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpCeP-0007bX-SA;
	Fri, 14 Nov 2014 08:54:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpCeP-0003by-MQ;
	Fri, 14 Nov 2014 08:54:41 +0000
Date: Fri, 14 Nov 2014 08:54:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31537-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31537: tolerable trouble:
	blocked/broken/fail/pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31537 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31537/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)        broken like 30834
 test-amd64-amd64-xl-qemut-debianhvm-amd64  3 host-install(3) broken like 30834
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail like 30879

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  184e82513e3a4eb16b92e891d1d0ab719320c0ea
baseline version:
 xen                  c8ed54edda001163a5ff7610424dd2ef4244e8d6

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Don Koch <dkoch@verizon.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)

Pushing revision :

+ branch=xen-4.4-testing
+ revision=184e82513e3a4eb16b92e891d1d0ab719320c0ea
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.4-testing 184e82513e3a4eb16b92e891d1d0ab719320c0ea
+ branch=xen-4.4-testing
+ revision=184e82513e3a4eb16b92e891d1d0ab719320c0ea
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.4-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.4-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.4-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.4-testing.git
++ : daily-cron.xen-4.4-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.4-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.4-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.4-testing
+ xenversion=xen-4.4
+ xenversion=4.4
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 184e82513e3a4eb16b92e891d1d0ab719320c0ea:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   c8ed54e..184e825  184e82513e3a4eb16b92e891d1d0ab719320c0ea -> stable-4.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 08:55:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 08:55:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpCeW-0008MJ-70; Fri, 14 Nov 2014 08:54:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpCeU-0008ME-U4
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 08:54:47 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	74/8F-26740-653C5645; Fri, 14 Nov 2014 08:54:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415955283!7623390!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30502 invoked from network); 14 Nov 2014 08:54:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 08:54:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191314226"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 03:54:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpCeP-0007bX-SA;
	Fri, 14 Nov 2014 08:54:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpCeP-0003by-MQ;
	Fri, 14 Nov 2014 08:54:41 +0000
Date: Fri, 14 Nov 2014 08:54:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31537-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31537: tolerable trouble:
	blocked/broken/fail/pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31537 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31537/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)        broken like 30834
 test-amd64-amd64-xl-qemut-debianhvm-amd64  3 host-install(3) broken like 30834
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail like 30879

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  184e82513e3a4eb16b92e891d1d0ab719320c0ea
baseline version:
 xen                  c8ed54edda001163a5ff7610424dd2ef4244e8d6

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Don Koch <dkoch@verizon.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)

Pushing revision :

+ branch=xen-4.4-testing
+ revision=184e82513e3a4eb16b92e891d1d0ab719320c0ea
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.4-testing 184e82513e3a4eb16b92e891d1d0ab719320c0ea
+ branch=xen-4.4-testing
+ revision=184e82513e3a4eb16b92e891d1d0ab719320c0ea
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.4-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.4-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.4-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.4-testing.git
++ : daily-cron.xen-4.4-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.4-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.4-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.4-testing
+ xenversion=xen-4.4
+ xenversion=4.4
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 184e82513e3a4eb16b92e891d1d0ab719320c0ea:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   c8ed54e..184e825  184e82513e3a4eb16b92e891d1d0ab719320c0ea -> stable-4.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:02:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:02:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpClZ-0000aE-H2; Fri, 14 Nov 2014 09:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpClX-0000a9-QL
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 09:02:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	67/3B-09936-B05C5645; Fri, 14 Nov 2014 09:02:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415955721!12684796!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5930 invoked from network); 14 Nov 2014 09:02:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 09:02:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="192780171"
Message-ID: <1415955718.31613.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Fri, 14 Nov 2014 09:01:58 +0000
In-Reply-To: <CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 22:54 -0700, Xing Lin wrote:
> I have been blocked by this problem for almost three weeks and as far
> as I know, I could not find any online tutorial on setting up xen
> based compute node for openstack juno. I will document steps I take
> and share them with the community. 

Awesome, thanks!

Having this in the Xen wiki would be awesome. If you would like write
access to our wiki (which is granted manually due to spammers spoiling
it for everyone...) then please:

      * Create an account using the "create account" link at the
        top-right hand side of http://wiki.xen.org/wiki/Main_Page
      * Fill in this form giving your chosen username:
        http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html

You could alternatively drop me a line privately with the user name for
the second step, but filling in the form might give a quicker response
time due to reaching multiple people in multiple timezones...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:02:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:02:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpClZ-0000aE-H2; Fri, 14 Nov 2014 09:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpClX-0000a9-QL
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 09:02:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	67/3B-09936-B05C5645; Fri, 14 Nov 2014 09:02:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1415955721!12684796!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5930 invoked from network); 14 Nov 2014 09:02:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 09:02:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="192780171"
Message-ID: <1415955718.31613.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Fri, 14 Nov 2014 09:01:58 +0000
In-Reply-To: <CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.6-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 22:54 -0700, Xing Lin wrote:
> I have been blocked by this problem for almost three weeks and as far
> as I know, I could not find any online tutorial on setting up xen
> based compute node for openstack juno. I will document steps I take
> and share them with the community. 

Awesome, thanks!

Having this in the Xen wiki would be awesome. If you would like write
access to our wiki (which is granted manually due to spammers spoiling
it for everyone...) then please:

      * Create an account using the "create account" link at the
        top-right hand side of http://wiki.xen.org/wiki/Main_Page
      * Fill in this form giving your chosen username:
        http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html

You could alternatively drop me a line privately with the user name for
the second step, but filling in the form might give a quicker response
time due to reaching multiple people in multiple timezones...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:12:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpCv5-0000lE-MN; Fri, 14 Nov 2014 09:11:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1XpCv3-0000l9-Dt
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:11:53 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	01/63-28296-857C5645; Fri, 14 Nov 2014 09:11:52 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415956311!11353946!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10847 invoked from network); 14 Nov 2014 09:11:51 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 09:11:51 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 546F14004BD;
	Fri, 14 Nov 2014 10:11:51 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id oLCc1QwbJRFE; Fri, 14 Nov 2014 10:11:50 +0100 (CET)
Received: from [192.168.178.50]
	(host159-81-dynamic.7-79-r.retail.telecomitalia.it [79.7.81.159])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 1E59340007A;
	Fri, 14 Nov 2014 10:11:50 +0100 (CET)
Message-ID: <5465C752.1030208@tiscali.it>
Date: Fri, 14 Nov 2014 10:11:46 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5177E6FD.7050707@tiscali.it>
	<1366817792.20256.374.camel@zakaz.uk.xensource.com>
	<517A47B3.4040600@tiscali.it>
	<1366968964.3142.52.camel@zakaz.uk.xensource.com>
	<517A5755.7080302@tiscali.it>
In-Reply-To: <517A5755.7080302@tiscali.it>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	James Harper <james.harper@bendigoit.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Network not working after restore with qemu-xen
 windows domU and gplpv
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="===============7799171913130079910=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7799171913130079910==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080203010007070607050404"

This is a cryptographically signed message in MIME format.

--------------ms080203010007070607050404
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

Il 26/04/2013 12:30, Fabio Fantoni ha scritto:
> Il 26/04/2013 11:36, Ian Campbell ha scritto:
>> On Fri, 2013-04-26 at 10:24 +0100, Fabio Fantoni wrote:
>>> Il 24/04/2013 17:36, Ian Campbell ha scritto:
>>>> On Wed, 2013-04-24 at 15:06 +0100, Fabio Fantoni wrote:
>>>>> I send new mail about this bug with details as required by George
>>>>> Dunlap.
>>>>> Dom0 is Wheezy 64 bit with kernel from package
>>>>> linux-image-3.2.0-4-amd64
>>>>> version 3.2.41-2, package blktap-dkms and all dependency packages f=
or
>>>>> xen, spice and usb redirection.
>>>>> xen.git (in this build commit is
>>>>> 96ef6e88359910738905ac2e1969dc05d7d7e7dc)
>>>>>
>>>>> Other details about dom0 installation see here:
>>>>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02290.html
>>>>>
>>>>> DomU is Windows 7 pro 64 bit with gplpv build 372 debug.
>>>>>
>>>>> After restore it sees network but is not working, nor lan neither
>>>>> wan.
>>>>> Tried with both dhcp and static ip, try also e1000 network card,
>>>>> tried
>>>>> also qemu 1.4.
>>>> Is the vif device present and on the bridge in dom0? What about the
>>>> emu
>>>> device?
>>>>
>>>> Can you post the output of "xenstore-ls -fp" please.
>>>>
>>>> I notice references to openvswitch in your logs -- which script are
>>>> you
>>>> using, the one I recently posted or something else?
>>>>
>>>> Ian.
>>>>
>>>>
>>> Thanks for reply, the vif and the vif -emu are present, bridge also a=
nd
>>> is working.
>> Are the both the vif* present on the bridge? What does "ovs-vsctl show=
"
>> report?
>>
>>> On attachment logs of save, restore, copy of vif and xenstore command=

>>> you told me, both before and after save/restore.
>> Thanks, I can see that the front and backend devices are connected ok
>> and appear to be happy and the hotplug scripts were successful.
>>
>> However I did notice that the device MAC address seems to have changed=
!
>> I can believe this could confuse things...
>>
>> Does this issue go away if you specify
>>          vif=3D['bridge=3Dxenbr0,mac=3D00:16:3e:42:ae:8f']
>> in your configuration?
>>
>> Ian.
>>
> Thanks, fixed mac solve the problem.
> Is possible solve for have network working after restore without mac
> on xl configuration file also on qemu upstream?
> The last test was without openvswitch, I must redo with it and post
> "ovs-vsctl show" result?
>

This problem is still present and reported also by other users:
http://lists.xen.org/archives/html/xen-devel/2014-11/msg01267.html


--------------ms080203010007070607050404
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMsTCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGdTCCBV2gAwIBAgICSD8wDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDAzMjgyMDMyMTBa
Fw0xNjAzMjkxMDA5NTNaMIGMMRkwFwYDVQQNExBXUnUxOWdzOFBEYmcwNTBJMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaGyFHyGrg8i9IZFHhWZHIx01/wslgoQD4
8XFmb4NafAEtUJpfdadMZXFjS9ea/k5P+Xw83mtZdEXNOnf8IXg8FmsiwAt6Ujdz+CZD1w+0
0+lVN3yt0sCbUUOXrWjSv59rOZnFA801A8epnh8tjATQugZ7r96rLE4Vk8PT+ksp8U2dIDZH
NHhfbmcvdx1Bk5Y/PB3IbPaCDGW9M0YoILOvjClmilMtigcB8YuaqWkVqULvcagfIoFWKinL
ylTzsleIcZsduvOIAp8nzVvT/b8Ogi0TYR3e67j9a9Zpt5F7oRHrCxBHlCfaTHEhh6svXawl
aYFWfxdrfuvuoJRPJtAdAgMBAAGjggLdMIIC2TAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFGfU6G9lcLCruABqxYo6
qtmlt2iPMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwEC
AzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0
dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8w
OQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVu
dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNs
YXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t
LzANBgkqhkiG9w0BAQUFAAOCAQEABT91kQvIXq/qcTjfY3Q08cQ96PYn1ucqLydhjWr/UJTS
kGubQTptxURT3Sga8SSWWxVOjdvOSyVmNG2TcYoq6oToILvto8MPJGuNa2uVltl7tG6qyfg/
1JwqNInfCt+VAbiIiA86tN/V3kuc7vYPJ1/ah6cS9oKV58zltZ6Ww0DZ567Ax0mvcExndOLa
2KHb6J6ZxaxEZDWppBe7pwZOBHZhlB/SGwEq4ktsaecm98cJ3c0IqGyxEC3zMF3qUIwfUrlW
a99IPu7fcQrhBGPmczWFvwvUkSuk0+A4ShNdK4Ss9QDDoQc07iAFkq7dz5LJ/F7hNkHsBeZX
xX6OHJOqUjGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg
Q0ECAkg/MAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTE0MTExNDA5MTE0NlowIwYJKoZIhvcNAQkEMRYEFKFjXTuSWjPYicfH/S2F
B4Ki1+nzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgJIPzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYw
FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp
Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICSD8wDQYJKoZIhvcNAQEBBQAEggEAnTQVsMlFNPS3KBsndDSP
mhYQsPVD61fB54I/aUa75riC72pEWGTlC21HFdK7H99eqWbeE44YrdAKkfX/o96Aph8ZJWkc
bL7g4/qdfegZYP1LzX7PL5IaGB5o7EQJC/w/Im5MOGlv5rkSeed0qRHhp0Sf7/Vv5NJ9vWtD
9KqD0Mvhy2ZIDVGhClKpVJoJinAGA5AVb5EvQPQbno0XTpgExIl857V+EyVrlNBEHOR+SMHM
KgORWA954ziuZWwj4oz1MfWibej1rtgL3xMABgJGZ3ZjZHDL8ncqrEfLzuHWSYerXQa6TLJo
0nXIVx8tlRnon7UjGb7wGFt7A8ywhXowlgAAAAAAAA==
--------------ms080203010007070607050404--


--===============7799171913130079910==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7799171913130079910==--


From xen-devel-bounces@lists.xen.org Fri Nov 14 09:12:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpCv5-0000lE-MN; Fri, 14 Nov 2014 09:11:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1XpCv3-0000l9-Dt
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:11:53 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	01/63-28296-857C5645; Fri, 14 Nov 2014 09:11:52 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415956311!11353946!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10847 invoked from network); 14 Nov 2014 09:11:51 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 09:11:51 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 546F14004BD;
	Fri, 14 Nov 2014 10:11:51 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id oLCc1QwbJRFE; Fri, 14 Nov 2014 10:11:50 +0100 (CET)
Received: from [192.168.178.50]
	(host159-81-dynamic.7-79-r.retail.telecomitalia.it [79.7.81.159])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 1E59340007A;
	Fri, 14 Nov 2014 10:11:50 +0100 (CET)
Message-ID: <5465C752.1030208@tiscali.it>
Date: Fri, 14 Nov 2014 10:11:46 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5177E6FD.7050707@tiscali.it>
	<1366817792.20256.374.camel@zakaz.uk.xensource.com>
	<517A47B3.4040600@tiscali.it>
	<1366968964.3142.52.camel@zakaz.uk.xensource.com>
	<517A5755.7080302@tiscali.it>
In-Reply-To: <517A5755.7080302@tiscali.it>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	James Harper <james.harper@bendigoit.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Network not working after restore with qemu-xen
 windows domU and gplpv
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="===============7799171913130079910=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7799171913130079910==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080203010007070607050404"

This is a cryptographically signed message in MIME format.

--------------ms080203010007070607050404
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

Il 26/04/2013 12:30, Fabio Fantoni ha scritto:
> Il 26/04/2013 11:36, Ian Campbell ha scritto:
>> On Fri, 2013-04-26 at 10:24 +0100, Fabio Fantoni wrote:
>>> Il 24/04/2013 17:36, Ian Campbell ha scritto:
>>>> On Wed, 2013-04-24 at 15:06 +0100, Fabio Fantoni wrote:
>>>>> I send new mail about this bug with details as required by George
>>>>> Dunlap.
>>>>> Dom0 is Wheezy 64 bit with kernel from package
>>>>> linux-image-3.2.0-4-amd64
>>>>> version 3.2.41-2, package blktap-dkms and all dependency packages f=
or
>>>>> xen, spice and usb redirection.
>>>>> xen.git (in this build commit is
>>>>> 96ef6e88359910738905ac2e1969dc05d7d7e7dc)
>>>>>
>>>>> Other details about dom0 installation see here:
>>>>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02290.html
>>>>>
>>>>> DomU is Windows 7 pro 64 bit with gplpv build 372 debug.
>>>>>
>>>>> After restore it sees network but is not working, nor lan neither
>>>>> wan.
>>>>> Tried with both dhcp and static ip, try also e1000 network card,
>>>>> tried
>>>>> also qemu 1.4.
>>>> Is the vif device present and on the bridge in dom0? What about the
>>>> emu
>>>> device?
>>>>
>>>> Can you post the output of "xenstore-ls -fp" please.
>>>>
>>>> I notice references to openvswitch in your logs -- which script are
>>>> you
>>>> using, the one I recently posted or something else?
>>>>
>>>> Ian.
>>>>
>>>>
>>> Thanks for reply, the vif and the vif -emu are present, bridge also a=
nd
>>> is working.
>> Are the both the vif* present on the bridge? What does "ovs-vsctl show=
"
>> report?
>>
>>> On attachment logs of save, restore, copy of vif and xenstore command=

>>> you told me, both before and after save/restore.
>> Thanks, I can see that the front and backend devices are connected ok
>> and appear to be happy and the hotplug scripts were successful.
>>
>> However I did notice that the device MAC address seems to have changed=
!
>> I can believe this could confuse things...
>>
>> Does this issue go away if you specify
>>          vif=3D['bridge=3Dxenbr0,mac=3D00:16:3e:42:ae:8f']
>> in your configuration?
>>
>> Ian.
>>
> Thanks, fixed mac solve the problem.
> Is possible solve for have network working after restore without mac
> on xl configuration file also on qemu upstream?
> The last test was without openvswitch, I must redo with it and post
> "ovs-vsctl show" result?
>

This problem is still present and reported also by other users:
http://lists.xen.org/archives/html/xen-devel/2014-11/msg01267.html


--------------ms080203010007070607050404
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMsTCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGdTCCBV2gAwIBAgICSD8wDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDAzMjgyMDMyMTBa
Fw0xNjAzMjkxMDA5NTNaMIGMMRkwFwYDVQQNExBXUnUxOWdzOFBEYmcwNTBJMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaGyFHyGrg8i9IZFHhWZHIx01/wslgoQD4
8XFmb4NafAEtUJpfdadMZXFjS9ea/k5P+Xw83mtZdEXNOnf8IXg8FmsiwAt6Ujdz+CZD1w+0
0+lVN3yt0sCbUUOXrWjSv59rOZnFA801A8epnh8tjATQugZ7r96rLE4Vk8PT+ksp8U2dIDZH
NHhfbmcvdx1Bk5Y/PB3IbPaCDGW9M0YoILOvjClmilMtigcB8YuaqWkVqULvcagfIoFWKinL
ylTzsleIcZsduvOIAp8nzVvT/b8Ogi0TYR3e67j9a9Zpt5F7oRHrCxBHlCfaTHEhh6svXawl
aYFWfxdrfuvuoJRPJtAdAgMBAAGjggLdMIIC2TAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFGfU6G9lcLCruABqxYo6
qtmlt2iPMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwEC
AzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0
dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8w
OQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVu
dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNs
YXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t
LzANBgkqhkiG9w0BAQUFAAOCAQEABT91kQvIXq/qcTjfY3Q08cQ96PYn1ucqLydhjWr/UJTS
kGubQTptxURT3Sga8SSWWxVOjdvOSyVmNG2TcYoq6oToILvto8MPJGuNa2uVltl7tG6qyfg/
1JwqNInfCt+VAbiIiA86tN/V3kuc7vYPJ1/ah6cS9oKV58zltZ6Ww0DZ567Ax0mvcExndOLa
2KHb6J6ZxaxEZDWppBe7pwZOBHZhlB/SGwEq4ktsaecm98cJ3c0IqGyxEC3zMF3qUIwfUrlW
a99IPu7fcQrhBGPmczWFvwvUkSuk0+A4ShNdK4Ss9QDDoQc07iAFkq7dz5LJ/F7hNkHsBeZX
xX6OHJOqUjGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg
Q0ECAkg/MAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTE0MTExNDA5MTE0NlowIwYJKoZIhvcNAQkEMRYEFKFjXTuSWjPYicfH/S2F
B4Ki1+nzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgJIPzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYw
FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp
Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICSD8wDQYJKoZIhvcNAQEBBQAEggEAnTQVsMlFNPS3KBsndDSP
mhYQsPVD61fB54I/aUa75riC72pEWGTlC21HFdK7H99eqWbeE44YrdAKkfX/o96Aph8ZJWkc
bL7g4/qdfegZYP1LzX7PL5IaGB5o7EQJC/w/Im5MOGlv5rkSeed0qRHhp0Sf7/Vv5NJ9vWtD
9KqD0Mvhy2ZIDVGhClKpVJoJinAGA5AVb5EvQPQbno0XTpgExIl857V+EyVrlNBEHOR+SMHM
KgORWA954ziuZWwj4oz1MfWibej1rtgL3xMABgJGZ3ZjZHDL8ncqrEfLzuHWSYerXQa6TLJo
0nXIVx8tlRnon7UjGb7wGFt7A8ywhXowlgAAAAAAAA==
--------------ms080203010007070607050404--


--===============7799171913130079910==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7799171913130079910==--


From xen-devel-bounces@lists.xen.org Fri Nov 14 09:17:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09: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 1XpD0D-000145-GG; Fri, 14 Nov 2014 09:17:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpD0B-00013x-Ss
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:17:12 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E8/A9-17694-798C5645; Fri, 14 Nov 2014 09:17:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415956629!11377421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29980 invoked from network); 14 Nov 2014 09:17:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 09:17:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191318677"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 04:17:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpD07-0007ic-PQ;
	Fri, 14 Nov 2014 09:17:07 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpD07-0001kL-Ja;
	Fri, 14 Nov 2014 09:17:07 +0000
Date: Fri, 14 Nov 2014 09:17:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31513-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31513: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31513 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31513/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-xl-credit2    3 host-install(3)       broken baseline untested
 test-amd64-i386-xl           12 guest-localmigrate      fail baseline untested
 test-amd64-i386-xl-multivcpu  3 host-install(3)       broken baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10  fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken baseline untested
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install  fail baseline untested
 test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
 test-amd64-i386-xl-qemut-winxpsp3  7 windows-install    fail baseline untested
 test-amd64-i386-xl-winxpsp3   7 windows-install         fail baseline untested
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail baseline untested
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)       broken baseline untested
 test-amd64-i386-xl-win7-amd64  7 windows-install        fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install    fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass

version targeted for testing:
 linux                ebc7163fafb29c390519378897c201748acc2756
baseline version:
 linux                206c5f60a3d902bc4b56dab2de3e88de5eb06108

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:17:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09: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 1XpD0D-000145-GG; Fri, 14 Nov 2014 09:17:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpD0B-00013x-Ss
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:17:12 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E8/A9-17694-798C5645; Fri, 14 Nov 2014 09:17:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415956629!11377421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29980 invoked from network); 14 Nov 2014 09:17:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 09:17:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191318677"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 04:17:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpD07-0007ic-PQ;
	Fri, 14 Nov 2014 09:17:07 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpD07-0001kL-Ja;
	Fri, 14 Nov 2014 09:17:07 +0000
Date: Fri, 14 Nov 2014 09:17:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31513-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31513: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31513 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31513/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-xl-credit2    3 host-install(3)       broken baseline untested
 test-amd64-i386-xl           12 guest-localmigrate      fail baseline untested
 test-amd64-i386-xl-multivcpu  3 host-install(3)       broken baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10  fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken baseline untested
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install  fail baseline untested
 test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
 test-amd64-i386-xl-qemut-winxpsp3  7 windows-install    fail baseline untested
 test-amd64-i386-xl-winxpsp3   7 windows-install         fail baseline untested
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail baseline untested
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install fail baseline untested
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)       broken baseline untested
 test-amd64-i386-xl-win7-amd64  7 windows-install        fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install    fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass

version targeted for testing:
 linux                ebc7163fafb29c390519378897c201748acc2756
baseline version:
 linux                206c5f60a3d902bc4b56dab2de3e88de5eb06108

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:21:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:21:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpD4J-0001CB-6n; Fri, 14 Nov 2014 09:21:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpD4H-0001C4-G7
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:21:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	48/8F-09936-499C5645; Fri, 14 Nov 2014 09:21:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415956882!12719199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7453 invoked from network); 14 Nov 2014 09:21:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 09:21:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="192783971"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 04:21:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpD4D-0007jp-D8;
	Fri, 14 Nov 2014 09:21:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpD48-0002UE-7G;
	Fri, 14 Nov 2014 09:21:16 +0000
Date: Fri, 14 Nov 2014 09:21:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31536-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31536: 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 31536 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31536/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  d6281e354393f1c8a02fac55f4f611b4d4856303
baseline version:
 xen                  425e9039b6532a8c5884e7fe4b6676f6cd493770

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Don Koch <dkoch@verizon.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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.3-testing
+ revision=d6281e354393f1c8a02fac55f4f611b4d4856303
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.3-testing d6281e354393f1c8a02fac55f4f611b4d4856303
+ branch=xen-4.3-testing
+ revision=d6281e354393f1c8a02fac55f4f611b4d4856303
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.3-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.3-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.3-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git
++ : daily-cron.xen-4.3-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.3-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.3-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.3-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.3-testing
+ xenversion=xen-4.3
+ xenversion=4.3
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git d6281e354393f1c8a02fac55f4f611b4d4856303:stable-4.3
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   425e903..d6281e3  d6281e354393f1c8a02fac55f4f611b4d4856303 -> stable-4.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:21:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:21:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpD4J-0001CB-6n; Fri, 14 Nov 2014 09:21:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpD4H-0001C4-G7
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:21:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	48/8F-09936-499C5645; Fri, 14 Nov 2014 09:21:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415956882!12719199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7453 invoked from network); 14 Nov 2014 09:21:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 09:21:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="192783971"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 04:21:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpD4D-0007jp-D8;
	Fri, 14 Nov 2014 09:21:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpD48-0002UE-7G;
	Fri, 14 Nov 2014 09:21:16 +0000
Date: Fri, 14 Nov 2014 09:21:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31536-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31536: 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 31536 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31536/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  d6281e354393f1c8a02fac55f4f611b4d4856303
baseline version:
 xen                  425e9039b6532a8c5884e7fe4b6676f6cd493770

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Don Koch <dkoch@verizon.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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.3-testing
+ revision=d6281e354393f1c8a02fac55f4f611b4d4856303
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.3-testing d6281e354393f1c8a02fac55f4f611b4d4856303
+ branch=xen-4.3-testing
+ revision=d6281e354393f1c8a02fac55f4f611b4d4856303
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.3-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.3-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.3-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git
++ : daily-cron.xen-4.3-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.3-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.3-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.3-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.3-testing
+ xenversion=xen-4.3
+ xenversion=4.3
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git d6281e354393f1c8a02fac55f4f611b4d4856303:stable-4.3
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   425e903..d6281e3  d6281e354393f1c8a02fac55f4f611b4d4856303 -> stable-4.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:37:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDJu-00023F-Hn; Fri, 14 Nov 2014 09:37:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpDJt-00022f-1D
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:37:33 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3E/8E-09936-C5DC5645; Fri, 14 Nov 2014 09:37:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415957851!12690364!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29236 invoked from network); 14 Nov 2014 09:37:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 09:37:31 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9B28FACEE;
	Fri, 14 Nov 2014 09:37:31 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xensource.com, jbeulich@suse.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com
Date: Fri, 14 Nov 2014 10:37:25 +0100
Message-Id: <1415957846-22703-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415957846-22703-1-git-send-email-jgross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 3/4] introduce boot parameter for setting
	XENFEAT_virtual_p2m
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 boot parameter "virt_p2m" to be able to set
XENFEAT_virtual_p2m for a pv domain.

As long as Xen tools and kdump don't support this new feature it is
turned off by default.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/arch/x86/domain.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d98aabd..ccb54f6 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2166,8 +2166,44 @@ static int __init init_vcpu_kick_softirq(void)
 }
 __initcall(init_vcpu_kick_softirq);
 
+#define VIRT_P2M_DOM0        0x01
+#define VIRT_P2M_DOM0_LARGE  0x02
+#define VIRT_P2M_DOMU        0x04
+#define VIRT_P2M_DOMU_LARGE  0x08
+static unsigned virt_p2m = 0;
+
+static void __init parse_virt_p2m(const char *s)
+{
+    char *ss;
+    int b;
+
+    do {
+        ss = strchr(s, ',');
+        if ( ss )
+            *ss = '\0';
+
+        b = parse_bool(s);
+        if ( b == 0 )
+            virt_p2m = 0;
+        else if ( b == 1 )
+            virt_p2m = VIRT_P2M_DOM0 | VIRT_P2M_DOMU;
+        else if ( !strcmp(s, "dom0") )
+            virt_p2m |= VIRT_P2M_DOM0;
+        else if ( !strcmp(s, "dom0_large") )
+            virt_p2m |= VIRT_P2M_DOM0_LARGE;
+        else if ( !strcmp(s, "domu") )
+            virt_p2m |= VIRT_P2M_DOMU;
+        else if ( !strcmp(s, "domu_large") )
+            virt_p2m |= VIRT_P2M_DOMU_LARGE;
+
+        s = ss + 1;
+    } while ( ss );
+}
+custom_param("virt_p2m", parse_virt_p2m);
+
 uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
 {
+#define DOM_IS_LARGE(d) ((d)->max_pages > 1U << 27)
     uint32_t submap = 0;
 
     switch ( submap_idx )
@@ -2179,6 +2215,20 @@ uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
             submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
                       (1U << XENFEAT_highmem_assist) |
                       (1U << XENFEAT_gnttab_map_avail_bits);
+            if ( is_hardware_domain(d) )
+            {
+                if ( virt_p2m & VIRT_P2M_DOM0 )
+                    submap |= 1U << XENFEAT_virtual_p2m;
+                if ( DOM_IS_LARGE(d) && virt_p2m & VIRT_P2M_DOM0_LARGE )
+                    submap |= 1U << XENFEAT_virtual_p2m;
+            }
+            else
+            {
+                if ( virt_p2m & VIRT_P2M_DOMU )
+                    submap |= 1U << XENFEAT_virtual_p2m;
+                if ( DOM_IS_LARGE(d) && virt_p2m & VIRT_P2M_DOMU_LARGE )
+                    submap |= 1U << XENFEAT_virtual_p2m;
+            }
             break;
         case guest_type_pvh:
             submap |= (1U << XENFEAT_hvm_safe_pvclock) |
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:37:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDJu-00023M-TY; Fri, 14 Nov 2014 09:37:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpDJt-00022e-0M
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:37:33 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	D0/5D-17958-C5DC5645; Fri, 14 Nov 2014 09:37:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415957851!11402555!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7759 invoked from network); 14 Nov 2014 09:37:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 09:37:31 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3F419ACA2;
	Fri, 14 Nov 2014 09:37:31 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xensource.com, jbeulich@suse.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com
Date: Fri, 14 Nov 2014 10:37:23 +0100
Message-Id: <1415957846-22703-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415957846-22703-1-git-send-email-jgross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
	linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
currently contains the mfn of the top level page frame of the 3 level
p2m tree, which is used by the Xen tools during saving and restoring
(and live migration) of pv domains and for crash dump analysis. With
three levels of the p2m tree it is possible to support up to 512 GB of
RAM for a 64 bit pv domain.

A 32 bit pv domain can support more, as each memory page can hold 1024
instead of 512 entries, leading to a limit of 4 TB.

To be able to support more RAM on x86-64 switch to a virtual mapped
p2m list.

This patch expands struct arch_shared_info with a new p2m list virtual
address and the mfn of the page table root. The new information is
indicated by the domain to be valid by storing ~0UL into
pfn_to_mfn_frame_list_list. The hypervisor indicates usability of this
feature by a new flag XENFEAT_virtual_p2m.
---
 xen/include/public/arch-x86/xen.h | 7 ++++++-
 xen/include/public/features.h     | 3 +++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index f35804b..b0f85a9 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -224,7 +224,12 @@ struct arch_shared_info {
     /* Frame containing list of mfns containing list of mfns containing p2m. */
     xen_pfn_t     pfn_to_mfn_frame_list_list;
     unsigned long nmi_reason;
-    uint64_t pad[32];
+    /*
+     * Following two fields are valid if pfn_to_mfn_frame_list_list contains
+     * ~0UL.
+     */
+    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
+    unsigned long p2m_as_root;  /* mfn of the top level page table */
 };
 typedef struct arch_shared_info arch_shared_info_t;
 
diff --git a/xen/include/public/features.h b/xen/include/public/features.h
index 16d92aa..ff0b82d 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -99,6 +99,9 @@
 #define XENFEAT_grant_map_identity        12
  */
 
+/* x86: guest may specify virtual address of p2m list */
+#define XENFEAT_virtual_p2m               13
+
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:37:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDJu-00023F-Hn; Fri, 14 Nov 2014 09:37:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpDJt-00022f-1D
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:37:33 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3E/8E-09936-C5DC5645; Fri, 14 Nov 2014 09:37:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415957851!12690364!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29236 invoked from network); 14 Nov 2014 09:37:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 09:37:31 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9B28FACEE;
	Fri, 14 Nov 2014 09:37:31 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xensource.com, jbeulich@suse.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com
Date: Fri, 14 Nov 2014 10:37:25 +0100
Message-Id: <1415957846-22703-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415957846-22703-1-git-send-email-jgross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 3/4] introduce boot parameter for setting
	XENFEAT_virtual_p2m
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 boot parameter "virt_p2m" to be able to set
XENFEAT_virtual_p2m for a pv domain.

As long as Xen tools and kdump don't support this new feature it is
turned off by default.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/arch/x86/domain.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d98aabd..ccb54f6 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2166,8 +2166,44 @@ static int __init init_vcpu_kick_softirq(void)
 }
 __initcall(init_vcpu_kick_softirq);
 
+#define VIRT_P2M_DOM0        0x01
+#define VIRT_P2M_DOM0_LARGE  0x02
+#define VIRT_P2M_DOMU        0x04
+#define VIRT_P2M_DOMU_LARGE  0x08
+static unsigned virt_p2m = 0;
+
+static void __init parse_virt_p2m(const char *s)
+{
+    char *ss;
+    int b;
+
+    do {
+        ss = strchr(s, ',');
+        if ( ss )
+            *ss = '\0';
+
+        b = parse_bool(s);
+        if ( b == 0 )
+            virt_p2m = 0;
+        else if ( b == 1 )
+            virt_p2m = VIRT_P2M_DOM0 | VIRT_P2M_DOMU;
+        else if ( !strcmp(s, "dom0") )
+            virt_p2m |= VIRT_P2M_DOM0;
+        else if ( !strcmp(s, "dom0_large") )
+            virt_p2m |= VIRT_P2M_DOM0_LARGE;
+        else if ( !strcmp(s, "domu") )
+            virt_p2m |= VIRT_P2M_DOMU;
+        else if ( !strcmp(s, "domu_large") )
+            virt_p2m |= VIRT_P2M_DOMU_LARGE;
+
+        s = ss + 1;
+    } while ( ss );
+}
+custom_param("virt_p2m", parse_virt_p2m);
+
 uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
 {
+#define DOM_IS_LARGE(d) ((d)->max_pages > 1U << 27)
     uint32_t submap = 0;
 
     switch ( submap_idx )
@@ -2179,6 +2215,20 @@ uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
             submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
                       (1U << XENFEAT_highmem_assist) |
                       (1U << XENFEAT_gnttab_map_avail_bits);
+            if ( is_hardware_domain(d) )
+            {
+                if ( virt_p2m & VIRT_P2M_DOM0 )
+                    submap |= 1U << XENFEAT_virtual_p2m;
+                if ( DOM_IS_LARGE(d) && virt_p2m & VIRT_P2M_DOM0_LARGE )
+                    submap |= 1U << XENFEAT_virtual_p2m;
+            }
+            else
+            {
+                if ( virt_p2m & VIRT_P2M_DOMU )
+                    submap |= 1U << XENFEAT_virtual_p2m;
+                if ( DOM_IS_LARGE(d) && virt_p2m & VIRT_P2M_DOMU_LARGE )
+                    submap |= 1U << XENFEAT_virtual_p2m;
+            }
             break;
         case guest_type_pvh:
             submap |= (1U << XENFEAT_hvm_safe_pvclock) |
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:37:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDJt-00022x-RD; Fri, 14 Nov 2014 09:37:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpDJs-00022c-QB
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:37:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B1/C5-09842-C5DC5645; Fri, 14 Nov 2014 09:37:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415957851!9274224!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4831 invoked from network); 14 Nov 2014 09:37:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 09:37:31 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 6C338ACD3;
	Fri, 14 Nov 2014 09:37:31 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xensource.com, jbeulich@suse.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com
Date: Fri, 14 Nov 2014 10:37:24 +0100
Message-Id: <1415957846-22703-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415957846-22703-1-git-send-email-jgross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 2/4] introduce arch_get_features()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 XENVER_get_features sub command of the xen_version hypercall is
handled completely in common/kernel.c despite of some architecture
dependant parts.

Move the architecture dependant parts in an own function in
arch/*/domain.c

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/arch/arm/domain.c    |  5 +++++
 xen/arch/x86/domain.c    | 30 ++++++++++++++++++++++++++++++
 xen/common/kernel.c      | 22 ++--------------------
 xen/include/xen/domain.h |  2 ++
 4 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7221bc8..dc5a3fb 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -823,6 +823,11 @@ void vcpu_block_unless_event_pending(struct vcpu *v)
         vcpu_unblock(current);
 }
 
+uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
+{
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..d98aabd 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2166,6 +2166,36 @@ static int __init init_vcpu_kick_softirq(void)
 }
 __initcall(init_vcpu_kick_softirq);
 
+uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
+{
+    uint32_t submap = 0;
+
+    switch ( submap_idx )
+    {
+    case 0:
+        switch ( d->guest_type )
+        {
+        case guest_type_pv:
+            submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
+                      (1U << XENFEAT_highmem_assist) |
+                      (1U << XENFEAT_gnttab_map_avail_bits);
+            break;
+        case guest_type_pvh:
+            submap |= (1U << XENFEAT_hvm_safe_pvclock) |
+                      (1U << XENFEAT_supervisor_mode_kernel) |
+                      (1U << XENFEAT_hvm_callback_vector);
+            break;
+        case guest_type_hvm:
+            submap |= (1U << XENFEAT_hvm_safe_pvclock) |
+                      (1U << XENFEAT_hvm_callback_vector) |
+                      (1U << XENFEAT_hvm_pirqs);
+            break;
+        }
+        break;
+    }
+
+    return submap;
+}
 
 /*
  * Local variables:
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index d23c422..d22a860 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -312,31 +312,13 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
                 fi.submap |= 1U << XENFEAT_supervisor_mode_kernel;
             if ( is_hardware_domain(current->domain) )
                 fi.submap |= 1U << XENFEAT_dom0;
-#ifdef CONFIG_X86
-            switch ( d->guest_type )
-            {
-            case guest_type_pv:
-                fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
-                             (1U << XENFEAT_highmem_assist) |
-                             (1U << XENFEAT_gnttab_map_avail_bits);
-                break;
-            case guest_type_pvh:
-                fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
-                             (1U << XENFEAT_supervisor_mode_kernel) |
-                             (1U << XENFEAT_hvm_callback_vector);
-                break;
-            case guest_type_hvm:
-                fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
-                             (1U << XENFEAT_hvm_callback_vector) |
-                             (1U << XENFEAT_hvm_pirqs);
-                break;
-            }
-#endif
             break;
         default:
             return -EINVAL;
         }
 
+        fi.submap |= arch_get_features(d, fi.submap_idx);
+
         if ( copy_to_guest(arg, &fi, 1) )
             return -EFAULT;
         return 0;
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 9215b0e..0d12dc0 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -80,6 +80,8 @@ extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
 
+uint32_t arch_get_features(struct domain *d, unsigned int submap_idx);
+
 /*
  * Continue the current hypercall via func(data) on specified cpu.
  * If this function returns 0 then the function is guaranteed to run at some
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:37:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDJu-000234-6G; Fri, 14 Nov 2014 09:37:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpDJs-00022d-UL
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:37:33 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	C7/77-26652-C5DC5645; Fri, 14 Nov 2014 09:37:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415957851!7233410!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28915 invoked from network); 14 Nov 2014 09:37:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 09:37:31 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0A926AC32;
	Fri, 14 Nov 2014 09:37:31 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xensource.com, jbeulich@suse.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com
Date: Fri, 14 Nov 2014 10:37:22 +0100
Message-Id: <1415957846-22703-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 0/4] support guest virtual mapped p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
currently contains the mfn of the top level page frame of the 3 level
p2m tree, which is used by the Xen tools during saving and restoring
(and live migration) of pv domains and for crash dump analysis. With
three levels of the p2m tree it is possible to support up to 512 GB of
RAM for a 64 bit pv domain.

A 32 bit pv domain can support more, as each memory page can hold 1024
instead of 512 entries, leading to a limit of 4 TB.

To be able to support more RAM on x86-64 switch to a virtual mapped
p2m list.

Juergen Gross (4):
  expand x86 arch_shared_info to support linear p2m list
  introduce arch_get_features()
  introduce boot parameter for setting XENFEAT_virtual_p2m
  document new boot parameter virt_p2m

 docs/misc/xen-command-line.markdown | 22 ++++++++++
 xen/arch/arm/domain.c               |  5 +++
 xen/arch/x86/domain.c               | 80 +++++++++++++++++++++++++++++++++++++
 xen/common/kernel.c                 | 22 +---------
 xen/include/public/arch-x86/xen.h   |  7 +++-
 xen/include/public/features.h       |  3 ++
 xen/include/xen/domain.h            |  2 +
 7 files changed, 120 insertions(+), 21 deletions(-)

-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:37:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDJu-000234-6G; Fri, 14 Nov 2014 09:37:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpDJs-00022d-UL
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:37:33 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	C7/77-26652-C5DC5645; Fri, 14 Nov 2014 09:37:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415957851!7233410!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28915 invoked from network); 14 Nov 2014 09:37:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 09:37:31 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0A926AC32;
	Fri, 14 Nov 2014 09:37:31 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xensource.com, jbeulich@suse.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com
Date: Fri, 14 Nov 2014 10:37:22 +0100
Message-Id: <1415957846-22703-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 0/4] support guest virtual mapped p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
currently contains the mfn of the top level page frame of the 3 level
p2m tree, which is used by the Xen tools during saving and restoring
(and live migration) of pv domains and for crash dump analysis. With
three levels of the p2m tree it is possible to support up to 512 GB of
RAM for a 64 bit pv domain.

A 32 bit pv domain can support more, as each memory page can hold 1024
instead of 512 entries, leading to a limit of 4 TB.

To be able to support more RAM on x86-64 switch to a virtual mapped
p2m list.

Juergen Gross (4):
  expand x86 arch_shared_info to support linear p2m list
  introduce arch_get_features()
  introduce boot parameter for setting XENFEAT_virtual_p2m
  document new boot parameter virt_p2m

 docs/misc/xen-command-line.markdown | 22 ++++++++++
 xen/arch/arm/domain.c               |  5 +++
 xen/arch/x86/domain.c               | 80 +++++++++++++++++++++++++++++++++++++
 xen/common/kernel.c                 | 22 +---------
 xen/include/public/arch-x86/xen.h   |  7 +++-
 xen/include/public/features.h       |  3 ++
 xen/include/xen/domain.h            |  2 +
 7 files changed, 120 insertions(+), 21 deletions(-)

-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:37:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDJv-00023T-8k; Fri, 14 Nov 2014 09:37:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpDJu-00022o-6c
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:37:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	25/C5-09842-C5DC5645; Fri, 14 Nov 2014 09:37:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415957851!12692389!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28714 invoked from network); 14 Nov 2014 09:37:32 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 09:37:32 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CA3F9ACF1;
	Fri, 14 Nov 2014 09:37:31 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xensource.com, jbeulich@suse.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com
Date: Fri, 14 Nov 2014 10:37:26 +0100
Message-Id: <1415957846-22703-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415957846-22703-1-git-send-email-jgross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 4/4] document new boot parameter virt_p2m
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 documentation for the new boot parameter "virt_p2m".

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 docs/misc/xen-command-line.markdown | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0830e5f..c56273d 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1272,6 +1272,28 @@ The optional `keep` parameter causes Xen to continue using the vga
 console even after dom0 has been started.  The default behaviour is to
 relinquish control to dom0.
 
+### virt\_p2m
+> `= List of [ <boolean> | dom0 | dom0\_large | domu | domu\_large ]`
+
+> Default: `false`
+
+Allow pv-domains to specify a virtual address for the domain's p2m list which
+is used by the Xen tools during domain save and restore and by kdump.
+
+`dom0` enables this feature for Dom0.
+
+`dom0\_large` enables this feature for Dom0 with more than 512 GiB of RAM
+(the traditional 3 level p2m tree can't map more than that).
+
+`domu` enables this feature for all pv domains but Dom0.
+
+`domu\_large` enables this feature for all pv domains with more than 512 GiB
+of RAM but Dom0.
+
+`true` enables this feature for all pv domains.
+
+`false` disables this feature for all domains.
+
 ### vpid (Intel)
 > `= <boolean>`
 
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:37:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDJt-00022x-RD; Fri, 14 Nov 2014 09:37:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpDJs-00022c-QB
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:37:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B1/C5-09842-C5DC5645; Fri, 14 Nov 2014 09:37:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415957851!9274224!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4831 invoked from network); 14 Nov 2014 09:37:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 09:37:31 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 6C338ACD3;
	Fri, 14 Nov 2014 09:37:31 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xensource.com, jbeulich@suse.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com
Date: Fri, 14 Nov 2014 10:37:24 +0100
Message-Id: <1415957846-22703-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415957846-22703-1-git-send-email-jgross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 2/4] introduce arch_get_features()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 XENVER_get_features sub command of the xen_version hypercall is
handled completely in common/kernel.c despite of some architecture
dependant parts.

Move the architecture dependant parts in an own function in
arch/*/domain.c

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/arch/arm/domain.c    |  5 +++++
 xen/arch/x86/domain.c    | 30 ++++++++++++++++++++++++++++++
 xen/common/kernel.c      | 22 ++--------------------
 xen/include/xen/domain.h |  2 ++
 4 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7221bc8..dc5a3fb 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -823,6 +823,11 @@ void vcpu_block_unless_event_pending(struct vcpu *v)
         vcpu_unblock(current);
 }
 
+uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
+{
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..d98aabd 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2166,6 +2166,36 @@ static int __init init_vcpu_kick_softirq(void)
 }
 __initcall(init_vcpu_kick_softirq);
 
+uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
+{
+    uint32_t submap = 0;
+
+    switch ( submap_idx )
+    {
+    case 0:
+        switch ( d->guest_type )
+        {
+        case guest_type_pv:
+            submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
+                      (1U << XENFEAT_highmem_assist) |
+                      (1U << XENFEAT_gnttab_map_avail_bits);
+            break;
+        case guest_type_pvh:
+            submap |= (1U << XENFEAT_hvm_safe_pvclock) |
+                      (1U << XENFEAT_supervisor_mode_kernel) |
+                      (1U << XENFEAT_hvm_callback_vector);
+            break;
+        case guest_type_hvm:
+            submap |= (1U << XENFEAT_hvm_safe_pvclock) |
+                      (1U << XENFEAT_hvm_callback_vector) |
+                      (1U << XENFEAT_hvm_pirqs);
+            break;
+        }
+        break;
+    }
+
+    return submap;
+}
 
 /*
  * Local variables:
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index d23c422..d22a860 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -312,31 +312,13 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
                 fi.submap |= 1U << XENFEAT_supervisor_mode_kernel;
             if ( is_hardware_domain(current->domain) )
                 fi.submap |= 1U << XENFEAT_dom0;
-#ifdef CONFIG_X86
-            switch ( d->guest_type )
-            {
-            case guest_type_pv:
-                fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
-                             (1U << XENFEAT_highmem_assist) |
-                             (1U << XENFEAT_gnttab_map_avail_bits);
-                break;
-            case guest_type_pvh:
-                fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
-                             (1U << XENFEAT_supervisor_mode_kernel) |
-                             (1U << XENFEAT_hvm_callback_vector);
-                break;
-            case guest_type_hvm:
-                fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
-                             (1U << XENFEAT_hvm_callback_vector) |
-                             (1U << XENFEAT_hvm_pirqs);
-                break;
-            }
-#endif
             break;
         default:
             return -EINVAL;
         }
 
+        fi.submap |= arch_get_features(d, fi.submap_idx);
+
         if ( copy_to_guest(arg, &fi, 1) )
             return -EFAULT;
         return 0;
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 9215b0e..0d12dc0 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -80,6 +80,8 @@ extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
 
+uint32_t arch_get_features(struct domain *d, unsigned int submap_idx);
+
 /*
  * Continue the current hypercall via func(data) on specified cpu.
  * If this function returns 0 then the function is guaranteed to run at some
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:37:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDJv-00023T-8k; Fri, 14 Nov 2014 09:37:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpDJu-00022o-6c
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:37:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	25/C5-09842-C5DC5645; Fri, 14 Nov 2014 09:37:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415957851!12692389!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28714 invoked from network); 14 Nov 2014 09:37:32 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 09:37:32 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CA3F9ACF1;
	Fri, 14 Nov 2014 09:37:31 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xensource.com, jbeulich@suse.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com
Date: Fri, 14 Nov 2014 10:37:26 +0100
Message-Id: <1415957846-22703-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415957846-22703-1-git-send-email-jgross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 4/4] document new boot parameter virt_p2m
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 documentation for the new boot parameter "virt_p2m".

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 docs/misc/xen-command-line.markdown | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0830e5f..c56273d 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1272,6 +1272,28 @@ The optional `keep` parameter causes Xen to continue using the vga
 console even after dom0 has been started.  The default behaviour is to
 relinquish control to dom0.
 
+### virt\_p2m
+> `= List of [ <boolean> | dom0 | dom0\_large | domu | domu\_large ]`
+
+> Default: `false`
+
+Allow pv-domains to specify a virtual address for the domain's p2m list which
+is used by the Xen tools during domain save and restore and by kdump.
+
+`dom0` enables this feature for Dom0.
+
+`dom0\_large` enables this feature for Dom0 with more than 512 GiB of RAM
+(the traditional 3 level p2m tree can't map more than that).
+
+`domu` enables this feature for all pv domains but Dom0.
+
+`domu\_large` enables this feature for all pv domains with more than 512 GiB
+of RAM but Dom0.
+
+`true` enables this feature for all pv domains.
+
+`false` disables this feature for all domains.
+
 ### vpid (Intel)
 > `= <boolean>`
 
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:37:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDJu-00023M-TY; Fri, 14 Nov 2014 09:37:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpDJt-00022e-0M
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 09:37:33 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	D0/5D-17958-C5DC5645; Fri, 14 Nov 2014 09:37:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415957851!11402555!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7759 invoked from network); 14 Nov 2014 09:37:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 09:37:31 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3F419ACA2;
	Fri, 14 Nov 2014 09:37:31 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xensource.com, jbeulich@suse.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com
Date: Fri, 14 Nov 2014 10:37:23 +0100
Message-Id: <1415957846-22703-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1415957846-22703-1-git-send-email-jgross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
	linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
currently contains the mfn of the top level page frame of the 3 level
p2m tree, which is used by the Xen tools during saving and restoring
(and live migration) of pv domains and for crash dump analysis. With
three levels of the p2m tree it is possible to support up to 512 GB of
RAM for a 64 bit pv domain.

A 32 bit pv domain can support more, as each memory page can hold 1024
instead of 512 entries, leading to a limit of 4 TB.

To be able to support more RAM on x86-64 switch to a virtual mapped
p2m list.

This patch expands struct arch_shared_info with a new p2m list virtual
address and the mfn of the page table root. The new information is
indicated by the domain to be valid by storing ~0UL into
pfn_to_mfn_frame_list_list. The hypervisor indicates usability of this
feature by a new flag XENFEAT_virtual_p2m.
---
 xen/include/public/arch-x86/xen.h | 7 ++++++-
 xen/include/public/features.h     | 3 +++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index f35804b..b0f85a9 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -224,7 +224,12 @@ struct arch_shared_info {
     /* Frame containing list of mfns containing list of mfns containing p2m. */
     xen_pfn_t     pfn_to_mfn_frame_list_list;
     unsigned long nmi_reason;
-    uint64_t pad[32];
+    /*
+     * Following two fields are valid if pfn_to_mfn_frame_list_list contains
+     * ~0UL.
+     */
+    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
+    unsigned long p2m_as_root;  /* mfn of the top level page table */
 };
 typedef struct arch_shared_info arch_shared_info_t;
 
diff --git a/xen/include/public/features.h b/xen/include/public/features.h
index 16d92aa..ff0b82d 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -99,6 +99,9 @@
 #define XENFEAT_grant_map_identity        12
  */
 
+/* x86: guest may specify virtual address of p2m list */
+#define XENFEAT_virtual_p2m               13
+
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:43:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:43:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDPD-0002p8-15; Fri, 14 Nov 2014 09:43:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpDPB-0002p3-HX
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 09:43:01 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	88/75-02699-4AEC5645; Fri, 14 Nov 2014 09:43:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415958178!9193312!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26840 invoked from network); 14 Nov 2014 09:42:59 -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;
	14 Nov 2014 09:42:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191322927"
Message-ID: <1415958176.21321.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>, Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 09:42:56 +0000
In-Reply-To: <54632F72.7020509@m2r.biz>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "Hu, Robert" <robert.hu@intel.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I've not seen an individual thread on this one, so replying here.

On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:

> > 6. Networking is unavailable after save&restore Windows guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> 
> Should be the same problem I reported 1 year ago or more and still 
> present, the workaround is use fixed mac address in domUs xl cfg :(
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html

Wei, shouldn't your json migration thing have solved this? (this being
the preservation of a vif's mac addr over migration?)

Robert, all reports of toolstack bugs should include a full set of logs.
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
advice on reporting bugs as well as lists of specific things which
should be included.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:43:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:43:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDPD-0002p8-15; Fri, 14 Nov 2014 09:43:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpDPB-0002p3-HX
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 09:43:01 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	88/75-02699-4AEC5645; Fri, 14 Nov 2014 09:43:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415958178!9193312!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26840 invoked from network); 14 Nov 2014 09:42:59 -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;
	14 Nov 2014 09:42:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191322927"
Message-ID: <1415958176.21321.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>, Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 09:42:56 +0000
In-Reply-To: <54632F72.7020509@m2r.biz>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "Hu, Robert" <robert.hu@intel.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I've not seen an individual thread on this one, so replying here.

On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:

> > 6. Networking is unavailable after save&restore Windows guest
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> 
> Should be the same problem I reported 1 year ago or more and still 
> present, the workaround is use fixed mac address in domUs xl cfg :(
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html

Wei, shouldn't your json migration thing have solved this? (this being
the preservation of a vif's mac addr over migration?)

Robert, all reports of toolstack bugs should include a full set of logs.
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
advice on reporting bugs as well as lists of specific things which
should be included.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:59:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:59:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDel-0003Fq-Pf; Fri, 14 Nov 2014 09:59:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpDek-0003Fl-55
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 09:59:06 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	E1/78-27623-962D5645; Fri, 14 Nov 2014 09:59:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415959143!11409288!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3856 invoked from network); 14 Nov 2014 09:59:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 09:59:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191325663"
Message-ID: <1415959140.21321.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 09:59:00 +0000
In-Reply-To: <1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> Unconditionally print out the partial configuration.

Can you provide an example of what such a configuration looks like?

> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/xl_cmdimpl.c |    6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3c9f146..396e06c 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3388,7 +3388,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
>  {
>      libxl_domain_config d_config;
>  
> -    int i, rc;
> +    int i;
>  
>      yajl_gen hand = NULL;
>      yajl_gen_status s;
> @@ -3410,9 +3410,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
>  
>      for (i = 0; i < nb_domain; i++) {
>          libxl_domain_config_init(&d_config);
> -        rc = libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> -        if (rc)
> -            continue;
> +        libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
>          if (default_output_format == OUTPUT_FORMAT_JSON)
>              s = printf_info_one_json(hand, info[i].domid, &d_config);
>          else



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:59:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:59:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDel-0003Fq-Pf; Fri, 14 Nov 2014 09:59:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpDek-0003Fl-55
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 09:59:06 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	E1/78-27623-962D5645; Fri, 14 Nov 2014 09:59:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415959143!11409288!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3856 invoked from network); 14 Nov 2014 09:59:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 09:59:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191325663"
Message-ID: <1415959140.21321.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 09:59:00 +0000
In-Reply-To: <1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> Unconditionally print out the partial configuration.

Can you provide an example of what such a configuration looks like?

> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/xl_cmdimpl.c |    6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3c9f146..396e06c 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3388,7 +3388,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
>  {
>      libxl_domain_config d_config;
>  
> -    int i, rc;
> +    int i;
>  
>      yajl_gen hand = NULL;
>      yajl_gen_status s;
> @@ -3410,9 +3410,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
>  
>      for (i = 0; i < nb_domain; i++) {
>          libxl_domain_config_init(&d_config);
> -        rc = libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> -        if (rc)
> -            continue;
> +        libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
>          if (default_output_format == OUTPUT_FORMAT_JSON)
>              s = printf_info_one_json(hand, info[i].domid, &d_config);
>          else



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:59:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDfX-0003Ir-6h; Fri, 14 Nov 2014 09:59:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XpDfW-0003If-1w
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 09:59:54 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	83/97-02698-992D5645; Fri, 14 Nov 2014 09:59:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415959191!12539200!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22762 invoked from network); 14 Nov 2014 09:59:52 -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;
	14 Nov 2014 09:59:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191325742"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 04:59:50 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpDfR-0003qa-Ex;
	Fri, 14 Nov 2014 09:59:49 +0000
Date: Fri, 14 Nov 2014 09:59:49 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141114095949.GA30599@zion.uk.xensource.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415958176.21321.18.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Hu, Robert" <robert.hu@intel.com>, Fabio Fantoni <fabio.fantoni@m2r.biz>,
	Wei Liu <wei.liu2@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 09:42:56AM +0000, Ian Campbell wrote:
> I've not seen an individual thread on this one, so replying here.
> 
> On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:
> 
> > > 6. Networking is unavailable after save&restore Windows guest
> > >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> > 
> > Should be the same problem I reported 1 year ago or more and still 
> > present, the workaround is use fixed mac address in domUs xl cfg :(
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
> 
> Wei, shouldn't your json migration thing have solved this? (this being
> the preservation of a vif's mac addr over migration?)
> 

I think so.

> Robert, all reports of toolstack bugs should include a full set of logs.
> See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
> advice on reporting bugs as well as lists of specific things which
> should be included.
> 

Right, without detailed logs it's hard to tell what's going on.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 09:59:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 09:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDfX-0003Ir-6h; Fri, 14 Nov 2014 09:59:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XpDfW-0003If-1w
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 09:59:54 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	83/97-02698-992D5645; Fri, 14 Nov 2014 09:59:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1415959191!12539200!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22762 invoked from network); 14 Nov 2014 09:59:52 -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;
	14 Nov 2014 09:59:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191325742"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 04:59:50 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpDfR-0003qa-Ex;
	Fri, 14 Nov 2014 09:59:49 +0000
Date: Fri, 14 Nov 2014 09:59:49 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141114095949.GA30599@zion.uk.xensource.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415958176.21321.18.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Hu, Robert" <robert.hu@intel.com>, Fabio Fantoni <fabio.fantoni@m2r.biz>,
	Wei Liu <wei.liu2@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 09:42:56AM +0000, Ian Campbell wrote:
> I've not seen an individual thread on this one, so replying here.
> 
> On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:
> 
> > > 6. Networking is unavailable after save&restore Windows guest
> > >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> > 
> > Should be the same problem I reported 1 year ago or more and still 
> > present, the workaround is use fixed mac address in domUs xl cfg :(
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
> 
> Wei, shouldn't your json migration thing have solved this? (this being
> the preservation of a vif's mac addr over migration?)
> 

I think so.

> Robert, all reports of toolstack bugs should include a full set of logs.
> See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
> advice on reporting bugs as well as lists of specific things which
> should be included.
> 

Right, without detailed logs it's hard to tell what's going on.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:00:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:00:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDgR-0003Vq-QP; Fri, 14 Nov 2014 10:00:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpDgR-0003Vi-2U
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 10:00:51 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	31/F2-28296-2D2D5645; Fri, 14 Nov 2014 10:00:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415959249!11391350!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25541 invoked from network); 14 Nov 2014 10:00:49 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 10:00:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 10:00:49 +0000
Message-Id: <5465E0E10200007800047902@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 10:00:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: [Xen-devel] kexec-ed kernel possibly needing low 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

David,

we're being approached with the situation where a disk driver in the
kexec-ed kernel needs memory below 4G in order to perform DMA
(e.g. for the swiotlb to be set up). Linux not so long ago invented a
two area approach, which doesn't fit with the current single
KEXEC_RANGE_MA_CRASH area obtainable via
KEXEC_CMD_kexec_get_range.

I see multiple options
- do no change at all; the user can deal with this by explicitly
  specifying an area below 4G via "crashkernel="
- add KEXEC_RANGE_MA_CRASH_LOW
- when not asked for a specific address, always allocate the (single)
  area below 4G if there is enough space
- provide a means to request allocating the (single) area below 4G
  (or perhaps more generically below a certain boundary) without
  requiring an exact address to be specified

Do you have any preference here, or do you see other viable
alternatives?

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:00:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:00:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDgR-0003Vq-QP; Fri, 14 Nov 2014 10:00:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpDgR-0003Vi-2U
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 10:00:51 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	31/F2-28296-2D2D5645; Fri, 14 Nov 2014 10:00:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415959249!11391350!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25541 invoked from network); 14 Nov 2014 10:00:49 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 10:00:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 10:00:49 +0000
Message-Id: <5465E0E10200007800047902@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 10:00:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: [Xen-devel] kexec-ed kernel possibly needing low 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

David,

we're being approached with the situation where a disk driver in the
kexec-ed kernel needs memory below 4G in order to perform DMA
(e.g. for the swiotlb to be set up). Linux not so long ago invented a
two area approach, which doesn't fit with the current single
KEXEC_RANGE_MA_CRASH area obtainable via
KEXEC_CMD_kexec_get_range.

I see multiple options
- do no change at all; the user can deal with this by explicitly
  specifying an area below 4G via "crashkernel="
- add KEXEC_RANGE_MA_CRASH_LOW
- when not asked for a specific address, always allocate the (single)
  area below 4G if there is enough space
- provide a means to request allocating the (single) area below 4G
  (or perhaps more generically below a certain boundary) without
  requiring an exact address to be specified

Do you have any preference here, or do you see other viable
alternatives?

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:09:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpDp4-0003ym-Rq; Fri, 14 Nov 2014 10:09:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XpDp3-0003yh-U6
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:09:46 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	9E/3E-02696-9E4D5645; Fri, 14 Nov 2014 10:09:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415959781!12518952!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27033 invoked from network); 14 Nov 2014 10:09:42 -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;
	14 Nov 2014 10:09:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="192792892"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 05:09:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpDoy-0005IT-2O;
	Fri, 14 Nov 2014 10:09:40 +0000
Date: Fri, 14 Nov 2014 10:09:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141114100939.GB30599@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415959140.21321.21.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, zhigang.x.wang@oracle.com,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > Unconditionally print out the partial configuration.
> 
> Can you provide an example of what such a configuration looks like?
> 

    {
        "domid": 2,
        "config": {
            "c_info": {
                "name": "s0-raw-vnuma",
                "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
            },
            "b_info": {
                "sched_params": {

                },
                "type.invalid": {

                }
            }
        }
    }

Libxl still complains because it tries to read some nodes that don't
exist, so xl will just print it out on stderr. This is the same
behaviour as before though.

Wei.

> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  tools/libxl/xl_cmdimpl.c |    6 ++----
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 3c9f146..396e06c 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -3388,7 +3388,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
> >  {
> >      libxl_domain_config d_config;
> >  
> > -    int i, rc;
> > +    int i;
> >  
> >      yajl_gen hand = NULL;
> >      yajl_gen_status s;
> > @@ -3410,9 +3410,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
> >  
> >      for (i = 0; i < nb_domain; i++) {
> >          libxl_domain_config_init(&d_config);
> > -        rc = libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> > -        if (rc)
> > -            continue;
> > +        libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> >          if (default_output_format == OUTPUT_FORMAT_JSON)
> >              s = printf_info_one_json(hand, info[i].domid, &d_config);
> >          else
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:09:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpDp4-0003ym-Rq; Fri, 14 Nov 2014 10:09:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XpDp3-0003yh-U6
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:09:46 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	9E/3E-02696-9E4D5645; Fri, 14 Nov 2014 10:09:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415959781!12518952!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27033 invoked from network); 14 Nov 2014 10:09:42 -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;
	14 Nov 2014 10:09:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="192792892"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 05:09:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpDoy-0005IT-2O;
	Fri, 14 Nov 2014 10:09:40 +0000
Date: Fri, 14 Nov 2014 10:09:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141114100939.GB30599@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415959140.21321.21.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, zhigang.x.wang@oracle.com,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > Unconditionally print out the partial configuration.
> 
> Can you provide an example of what such a configuration looks like?
> 

    {
        "domid": 2,
        "config": {
            "c_info": {
                "name": "s0-raw-vnuma",
                "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
            },
            "b_info": {
                "sched_params": {

                },
                "type.invalid": {

                }
            }
        }
    }

Libxl still complains because it tries to read some nodes that don't
exist, so xl will just print it out on stderr. This is the same
behaviour as before though.

Wei.

> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  tools/libxl/xl_cmdimpl.c |    6 ++----
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 3c9f146..396e06c 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -3388,7 +3388,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
> >  {
> >      libxl_domain_config d_config;
> >  
> > -    int i, rc;
> > +    int i;
> >  
> >      yajl_gen hand = NULL;
> >      yajl_gen_status s;
> > @@ -3410,9 +3410,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
> >  
> >      for (i = 0; i < nb_domain; i++) {
> >          libxl_domain_config_init(&d_config);
> > -        rc = libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> > -        if (rc)
> > -            continue;
> > +        libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> >          if (default_output_format == OUTPUT_FORMAT_JSON)
> >              s = printf_info_one_json(hand, info[i].domid, &d_config);
> >          else
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:11:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:11:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDqY-00043Y-C4; Fri, 14 Nov 2014 10:11:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpDqX-00043P-AA
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 10:11:17 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	3E/36-02696-445D5645; Fri, 14 Nov 2014 10:11:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415959874!12537320!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20943 invoked from network); 14 Nov 2014 10:11:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:11:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="192793205"
Message-ID: <1415959858.21321.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Clark Laughlin <clark.laughlin@linaro.org>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>, Tim Deegan
	<tim@xen.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:10:58 +0000
In-Reply-To: <1415807026.1155.21.camel@citrix.com>
References: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
	<1415807026.1155.21.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] mkdeb: correctly map package
 architectures for x86 and 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

(CCing some more maintainers and the release manager)

On Wed, 2014-11-12 at 15:43 +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 09:38 -0600, Clark Laughlin wrote:
> > mkdeb previously set the package architecture to be 'amd64' for anything other than
> > XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture from
> > GNU names to debian names for x86 and ARM architectures, or otherwise, defaults it
> > to the value in XEN_TARGET_ARCH.
> > 
> > Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Actually thinking about it some more I'd be happier arguing for a freeze
exception for something like the below which only handles the actual
valid values of XEN_TARGET_ARCH and not the GNU names (which cannot
happen) and prints an error for unknown architectures (so new ports
aren't bitten in the future, etc).

Konrad, wrt the freeze I think this is low risk for breaking x86
platforms and makes things work for arm, so is worth it.

------

>From d861e1bcf5c3530ef322515ec2c55031dd538277 Mon Sep 17 00:00:00 2001
From: Clark Laughlin <clark.laughlin@linaro.org>
Date: Wed, 12 Nov 2014 09:38:48 -0600
Subject: [PATCH] mkdeb: correctly map package architectures for x86 and ARM

mkdeb previously set the package architecture to be 'amd64' for anything other than
XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture
from XEN_TARGET_ARCH to the Debian architecture names for x86 and ARM
architectures.

Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3 (ijc): Handle only valid values for $XEN_TARGET_ARCH, print an error if the
arch is unknown.
---
 tools/misc/mkdeb |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 3bbf881..67b91cc 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -13,11 +13,17 @@ fi
 
 cd $1
 version=$2
-if test "$XEN_TARGET_ARCH" = "x86_32"; then
-  arch=i386
-else
-  arch=amd64
-fi
+
+# map the architecture, if necessary
+case "$XEN_TARGET_ARCH" in
+  x86_32|x86_32p)  arch=i386 ;;
+  x86_64)  arch=amd64 ;;
+  arm32)   arch=armhf ;;
+  arm64)   arch=$XEN_TARGET_ARCH;;
+  *) echo "Unknown XEN_TARGET_ARCH $XEN_TARGET_ARCH" >&2
+     exit 1
+     ;;
+esac
 
 # Prepare the directory to package
 cd dist
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:11:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:11:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDqY-00043Y-C4; Fri, 14 Nov 2014 10:11:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpDqX-00043P-AA
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 10:11:17 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	3E/36-02696-445D5645; Fri, 14 Nov 2014 10:11:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415959874!12537320!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20943 invoked from network); 14 Nov 2014 10:11:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:11:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="192793205"
Message-ID: <1415959858.21321.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Clark Laughlin <clark.laughlin@linaro.org>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>, Tim Deegan
	<tim@xen.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:10:58 +0000
In-Reply-To: <1415807026.1155.21.camel@citrix.com>
References: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
	<1415807026.1155.21.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] mkdeb: correctly map package
 architectures for x86 and 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

(CCing some more maintainers and the release manager)

On Wed, 2014-11-12 at 15:43 +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 09:38 -0600, Clark Laughlin wrote:
> > mkdeb previously set the package architecture to be 'amd64' for anything other than
> > XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture from
> > GNU names to debian names for x86 and ARM architectures, or otherwise, defaults it
> > to the value in XEN_TARGET_ARCH.
> > 
> > Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Actually thinking about it some more I'd be happier arguing for a freeze
exception for something like the below which only handles the actual
valid values of XEN_TARGET_ARCH and not the GNU names (which cannot
happen) and prints an error for unknown architectures (so new ports
aren't bitten in the future, etc).

Konrad, wrt the freeze I think this is low risk for breaking x86
platforms and makes things work for arm, so is worth it.

------

>From d861e1bcf5c3530ef322515ec2c55031dd538277 Mon Sep 17 00:00:00 2001
From: Clark Laughlin <clark.laughlin@linaro.org>
Date: Wed, 12 Nov 2014 09:38:48 -0600
Subject: [PATCH] mkdeb: correctly map package architectures for x86 and ARM

mkdeb previously set the package architecture to be 'amd64' for anything other than
XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture
from XEN_TARGET_ARCH to the Debian architecture names for x86 and ARM
architectures.

Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3 (ijc): Handle only valid values for $XEN_TARGET_ARCH, print an error if the
arch is unknown.
---
 tools/misc/mkdeb |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 3bbf881..67b91cc 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -13,11 +13,17 @@ fi
 
 cd $1
 version=$2
-if test "$XEN_TARGET_ARCH" = "x86_32"; then
-  arch=i386
-else
-  arch=amd64
-fi
+
+# map the architecture, if necessary
+case "$XEN_TARGET_ARCH" in
+  x86_32|x86_32p)  arch=i386 ;;
+  x86_64)  arch=amd64 ;;
+  arm32)   arch=armhf ;;
+  arm64)   arch=$XEN_TARGET_ARCH;;
+  *) echo "Unknown XEN_TARGET_ARCH $XEN_TARGET_ARCH" >&2
+     exit 1
+     ;;
+esac
 
 # Prepare the directory to package
 cd dist
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:16:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDvQ-0004Tf-Fj; Fri, 14 Nov 2014 10:16:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpDvP-0004TU-C3
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:16:19 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	F8/22-02698-276D5645; Fri, 14 Nov 2014 10:16:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415960176!7902095!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21772 invoked from network); 14 Nov 2014 10:16:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:16:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191329098"
Message-ID: <1415960174.21321.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:16:14 +0000
In-Reply-To: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
References: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxc: don't leak buffer containing
 the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Adding Konrad who I previously forgot it seems.

We really ought to get this into 4.5, but it needs some review...

On Mon, 2014-11-10 at 12:08 +0000, Ian Campbell wrote:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> up leaked.
> 
> The memory pool currently supports mmap'd buffers as well as a directly
> allocated buffers, however the try decode routines make use of realloc and do
> not fit well into this model. Introduce a concept of an external memory block
> to the memory pool and provide an interface to register such memory.
> 
> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> mmap_ prefix since they are now also used for external memory blocks.
> 
> We are only seeing this now because the gzip decoder doesn't leak and it's only
> relatively recently that kernels in the wild have switched to better
> compression.
> 
> This is https://bugs.debian.org/767295
> 
> Reported by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> This is a bug fix and should go into 4.5.
> 
> I have a sneaking suspicion this is going to need to backport a very long way...
> ---
>  tools/libxc/include/xc_dom.h        |   10 ++++--
>  tools/libxc/xc_dom_bzimageloader.c  |   18 +++++++++++
>  tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
>  tools/libxc/xc_dom_decompress_lz4.c |    5 +++
>  4 files changed, 78 insertions(+), 16 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6ae6a9f..07d7224 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -33,8 +33,13 @@ struct xc_dom_seg {
>  
>  struct xc_dom_mem {
>      struct xc_dom_mem *next;
> -    void *mmap_ptr;
> -    size_t mmap_len;
> +    void *ptr;
> +    enum {
> +        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
> +        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
> +        XC_DOM_MEM_TYPE_MMAP,
> +    } type;
> +    size_t len;
>      unsigned char memory[0];
>  };
>  
> @@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
>  /* --- simple memory pool ------------------------------------------ */
>  
>  void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
>  void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>                              const char *filename, size_t * size,
> diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
> index 2225699..991a07b 100644
> --- a/tools/libxc/xc_dom_bzimageloader.c
> +++ b/tools/libxc/xc_dom_bzimageloader.c
> @@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
>  
>      total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
>  
> +    if ( xc_dom_register_external(dom, out_buf, total) )
> +    {
> +        DOMPRINTF("BZIP2: Error registering stream output");
> +        free(out_buf);
> +        goto bzip2_cleanup;
> +    }
> +
>      DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
>                __FUNCTION__, *size, (long unsigned int) total);
>  
> @@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
>          }
>      }
>  
> +    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
> +    {
> +        DOMPRINTF("%s: Error registering stream output", what);
> +        free(out_buf);
> +        goto lzma_cleanup;
> +    }
> +
>      DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
>                __FUNCTION__, what, *size, (size_t)stream->total_out);
>  
> @@ -508,6 +522,10 @@ static int xc_try_lzo1x_decode(
>              if ( out_len != dst_len )
>                  break;
>  
> +            msg = "Error registering stream output";
> +            if ( xc_dom_register_external(dom, out_buf, out_len) )
> +                break;
> +
>              *blob = out_buf;
>              *size += out_len;
>              cur += src_len;
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index baa62a1..ecbf981 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block) + size);
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block) + size;
> @@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len,
> -                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> -                           -1, 0);
> -    if ( block->mmap_ptr == MAP_FAILED )
> +    block->len = size;
> +    block->ptr = mmap(NULL, block->len,
> +                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> +                      -1, 0);
> +    if ( block->ptr == MAP_FAILED )
>      {
>          DOMPRINTF("%s: mmap failed", __FUNCTION__);
>          free(block);
>          return NULL;
>      }
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_mem_map += block->mmap_len;
> +    dom->alloc_mem_map += block->len;
>      if ( size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, size);
> -    return block->mmap_ptr;
> +    return block->ptr;
> +}
> +
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
> +{
> +    struct xc_dom_mem *block;
> +
> +    block = malloc(sizeof(*block));
> +    if ( block == NULL )
> +    {
> +        DOMPRINTF("%s: allocation failed", __FUNCTION__);
> +        return -1;
> +    }
> +    memset(block, 0, sizeof(*block));
> +    block->ptr = ptr;
> +    block->len = size;
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
> +    block->next = dom->memblocks;
> +    dom->memblocks = block;
> +    dom->alloc_malloc += sizeof(*block);
> +    dom->alloc_mem_map += block->len;
> +    return 0;
>  }
>  
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
> @@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>      }
>  
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = *size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
> +    block->len = *size;
> +    block->ptr = mmap(NULL, block->len, PROT_READ,
>                             MAP_SHARED, fd, 0);
> -    if ( block->mmap_ptr == MAP_FAILED ) {
> +    if ( block->ptr == MAP_FAILED ) {
>          xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
>                       "failed to mmap file: %s",
>                       strerror(errno));
>          goto err;
>      }
>  
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_file_map += block->mmap_len;
> +    dom->alloc_file_map += block->len;
>      close(fd);
>      if ( *size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, *size);
> -    return block->mmap_ptr;
> +    return block->ptr;
>  
>   err:
>      if ( fd != -1 )
> @@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
>      while ( (block = dom->memblocks) != NULL )
>      {
>          dom->memblocks = block->next;
> -        if ( block->mmap_ptr )
> -            munmap(block->mmap_ptr, block->mmap_len);
> +        switch ( block->type )
> +        {
> +        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
> +            break;
> +        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
> +            free(block->ptr);
> +            break;
> +        case XC_DOM_MEM_TYPE_MMAP:
> +            munmap(block->ptr, block->len);
> +            break;
> +        }
>          free(block);
>      }
>  }
> diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
> index 490ec56..b6a33f2 100644
> --- a/tools/libxc/xc_dom_decompress_lz4.c
> +++ b/tools/libxc/xc_dom_decompress_lz4.c
> @@ -103,6 +103,11 @@ int xc_try_lz4_decode(
>  
>  		if (size == 0)
>  		{
> +			if ( xc_dom_register_external(dom, output, out_len) )
> +			{
> +				msg = "Error registering stream output";
> +				goto exit_2;
> +			}
>  			*blob = output;
>  			*psize = out_len;
>  			return 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:16:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDvH-0004St-3Y; Fri, 14 Nov 2014 10:16:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XpDvE-0004So-RW
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:16:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3F/3E-09842-866D5645; Fri, 14 Nov 2014 10:16:08 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415960166!5431788!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26903 invoked from network); 14 Nov 2014 10:16:07 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-21.messagelabs.com with SMTP;
	14 Nov 2014 10:16:07 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 14 Nov 2014 02:13:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,384,1413270000"; d="scan'208";a="636903283"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by orsmga002.jf.intel.com with ESMTP; 14 Nov 2014 02:16:03 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 14 Nov 2014 18:14:34 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Fri, 14 Nov 2014 18:14:32 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Fabio Fantoni
	<fabio.fantoni@m2r.biz>, Wei Liu <wei.liu2@citrix.com>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/l9ZNIwAqiexHE6x0A+uPl9BJ5xfW+EAgACOpLA=
Date: Fri, 14 Nov 2014 10:14:32 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
In-Reply-To: <1415958176.21321.18.camel@citrix.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: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: Friday, November 14, 2014 5:43 PM
> To: Fabio Fantoni; Wei Liu
> Cc: Hu, Robert; JBeulich@suse.com; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> I've not seen an individual thread on this one, so replying here.
> 
> On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:
> 
> > > 6. Networking is unavailable after save&restore Windows guest
> > >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> >
> > Should be the same problem I reported 1 year ago or more and still
> > present, the workaround is use fixed mac address in domUs xl cfg :(
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
> 
> Wei, shouldn't your json migration thing have solved this? (this being
> the preservation of a vif's mac addr over migration?)
> 
> Robert, all reports of toolstack bugs should include a full set of logs.
> See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
> advice on reporting bugs as well as lists of specific things which
> should be included.
Thanks Ian. Will rerun this test case in RC2 testing, and if still there, append the full logs then.
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:16:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDvQ-0004Tf-Fj; Fri, 14 Nov 2014 10:16:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpDvP-0004TU-C3
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:16:19 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	F8/22-02698-276D5645; Fri, 14 Nov 2014 10:16:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415960176!7902095!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21772 invoked from network); 14 Nov 2014 10:16:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:16:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191329098"
Message-ID: <1415960174.21321.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:16:14 +0000
In-Reply-To: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
References: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxc: don't leak buffer containing
 the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Adding Konrad who I previously forgot it seems.

We really ought to get this into 4.5, but it needs some review...

On Mon, 2014-11-10 at 12:08 +0000, Ian Campbell wrote:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> up leaked.
> 
> The memory pool currently supports mmap'd buffers as well as a directly
> allocated buffers, however the try decode routines make use of realloc and do
> not fit well into this model. Introduce a concept of an external memory block
> to the memory pool and provide an interface to register such memory.
> 
> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> mmap_ prefix since they are now also used for external memory blocks.
> 
> We are only seeing this now because the gzip decoder doesn't leak and it's only
> relatively recently that kernels in the wild have switched to better
> compression.
> 
> This is https://bugs.debian.org/767295
> 
> Reported by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> This is a bug fix and should go into 4.5.
> 
> I have a sneaking suspicion this is going to need to backport a very long way...
> ---
>  tools/libxc/include/xc_dom.h        |   10 ++++--
>  tools/libxc/xc_dom_bzimageloader.c  |   18 +++++++++++
>  tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
>  tools/libxc/xc_dom_decompress_lz4.c |    5 +++
>  4 files changed, 78 insertions(+), 16 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6ae6a9f..07d7224 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -33,8 +33,13 @@ struct xc_dom_seg {
>  
>  struct xc_dom_mem {
>      struct xc_dom_mem *next;
> -    void *mmap_ptr;
> -    size_t mmap_len;
> +    void *ptr;
> +    enum {
> +        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
> +        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
> +        XC_DOM_MEM_TYPE_MMAP,
> +    } type;
> +    size_t len;
>      unsigned char memory[0];
>  };
>  
> @@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
>  /* --- simple memory pool ------------------------------------------ */
>  
>  void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
>  void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>                              const char *filename, size_t * size,
> diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
> index 2225699..991a07b 100644
> --- a/tools/libxc/xc_dom_bzimageloader.c
> +++ b/tools/libxc/xc_dom_bzimageloader.c
> @@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
>  
>      total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
>  
> +    if ( xc_dom_register_external(dom, out_buf, total) )
> +    {
> +        DOMPRINTF("BZIP2: Error registering stream output");
> +        free(out_buf);
> +        goto bzip2_cleanup;
> +    }
> +
>      DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
>                __FUNCTION__, *size, (long unsigned int) total);
>  
> @@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
>          }
>      }
>  
> +    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
> +    {
> +        DOMPRINTF("%s: Error registering stream output", what);
> +        free(out_buf);
> +        goto lzma_cleanup;
> +    }
> +
>      DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
>                __FUNCTION__, what, *size, (size_t)stream->total_out);
>  
> @@ -508,6 +522,10 @@ static int xc_try_lzo1x_decode(
>              if ( out_len != dst_len )
>                  break;
>  
> +            msg = "Error registering stream output";
> +            if ( xc_dom_register_external(dom, out_buf, out_len) )
> +                break;
> +
>              *blob = out_buf;
>              *size += out_len;
>              cur += src_len;
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index baa62a1..ecbf981 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block) + size);
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block) + size;
> @@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len,
> -                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> -                           -1, 0);
> -    if ( block->mmap_ptr == MAP_FAILED )
> +    block->len = size;
> +    block->ptr = mmap(NULL, block->len,
> +                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> +                      -1, 0);
> +    if ( block->ptr == MAP_FAILED )
>      {
>          DOMPRINTF("%s: mmap failed", __FUNCTION__);
>          free(block);
>          return NULL;
>      }
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_mem_map += block->mmap_len;
> +    dom->alloc_mem_map += block->len;
>      if ( size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, size);
> -    return block->mmap_ptr;
> +    return block->ptr;
> +}
> +
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
> +{
> +    struct xc_dom_mem *block;
> +
> +    block = malloc(sizeof(*block));
> +    if ( block == NULL )
> +    {
> +        DOMPRINTF("%s: allocation failed", __FUNCTION__);
> +        return -1;
> +    }
> +    memset(block, 0, sizeof(*block));
> +    block->ptr = ptr;
> +    block->len = size;
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
> +    block->next = dom->memblocks;
> +    dom->memblocks = block;
> +    dom->alloc_malloc += sizeof(*block);
> +    dom->alloc_mem_map += block->len;
> +    return 0;
>  }
>  
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
> @@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>      }
>  
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = *size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
> +    block->len = *size;
> +    block->ptr = mmap(NULL, block->len, PROT_READ,
>                             MAP_SHARED, fd, 0);
> -    if ( block->mmap_ptr == MAP_FAILED ) {
> +    if ( block->ptr == MAP_FAILED ) {
>          xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
>                       "failed to mmap file: %s",
>                       strerror(errno));
>          goto err;
>      }
>  
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_file_map += block->mmap_len;
> +    dom->alloc_file_map += block->len;
>      close(fd);
>      if ( *size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, *size);
> -    return block->mmap_ptr;
> +    return block->ptr;
>  
>   err:
>      if ( fd != -1 )
> @@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
>      while ( (block = dom->memblocks) != NULL )
>      {
>          dom->memblocks = block->next;
> -        if ( block->mmap_ptr )
> -            munmap(block->mmap_ptr, block->mmap_len);
> +        switch ( block->type )
> +        {
> +        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
> +            break;
> +        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
> +            free(block->ptr);
> +            break;
> +        case XC_DOM_MEM_TYPE_MMAP:
> +            munmap(block->ptr, block->len);
> +            break;
> +        }
>          free(block);
>      }
>  }
> diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
> index 490ec56..b6a33f2 100644
> --- a/tools/libxc/xc_dom_decompress_lz4.c
> +++ b/tools/libxc/xc_dom_decompress_lz4.c
> @@ -103,6 +103,11 @@ int xc_try_lz4_decode(
>  
>  		if (size == 0)
>  		{
> +			if ( xc_dom_register_external(dom, output, out_len) )
> +			{
> +				msg = "Error registering stream output";
> +				goto exit_2;
> +			}
>  			*blob = output;
>  			*psize = out_len;
>  			return 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:16:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDvH-0004St-3Y; Fri, 14 Nov 2014 10:16:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XpDvE-0004So-RW
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:16:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3F/3E-09842-866D5645; Fri, 14 Nov 2014 10:16:08 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415960166!5431788!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26903 invoked from network); 14 Nov 2014 10:16:07 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-21.messagelabs.com with SMTP;
	14 Nov 2014 10:16:07 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 14 Nov 2014 02:13:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,384,1413270000"; d="scan'208";a="636903283"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by orsmga002.jf.intel.com with ESMTP; 14 Nov 2014 02:16:03 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 14 Nov 2014 18:14:34 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Fri, 14 Nov 2014 18:14:32 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Fabio Fantoni
	<fabio.fantoni@m2r.biz>, Wei Liu <wei.liu2@citrix.com>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/l9ZNIwAqiexHE6x0A+uPl9BJ5xfW+EAgACOpLA=
Date: Fri, 14 Nov 2014 10:14:32 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
In-Reply-To: <1415958176.21321.18.camel@citrix.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: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: Friday, November 14, 2014 5:43 PM
> To: Fabio Fantoni; Wei Liu
> Cc: Hu, Robert; JBeulich@suse.com; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> I've not seen an individual thread on this one, so replying here.
> 
> On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:
> 
> > > 6. Networking is unavailable after save&restore Windows guest
> > >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> >
> > Should be the same problem I reported 1 year ago or more and still
> > present, the workaround is use fixed mac address in domUs xl cfg :(
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
> 
> Wei, shouldn't your json migration thing have solved this? (this being
> the preservation of a vif's mac addr over migration?)
> 
> Robert, all reports of toolstack bugs should include a full set of logs.
> See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
> advice on reporting bugs as well as lists of specific things which
> should be included.
Thanks Ian. Will rerun this test case in RC2 testing, and if still there, append the full logs then.
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:19:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:19:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDyD-0004gG-1j; Fri, 14 Nov 2014 10:19:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpDyC-0004g7-1J
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 10:19:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/B1-24532-F17D5645; Fri, 14 Nov 2014 10:19:11 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415960349!4701821!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25849 invoked from network); 14 Nov 2014 10:19:10 -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;
	14 Nov 2014 10:19:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191329596"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 05:19:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpDy7-0005RM-8N;
	Fri, 14 Nov 2014 10:19:07 +0000
Date: Fri, 14 Nov 2014 10:18:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
Message-ID: <alpine.DEB.2.02.1411141018230.26318@kaball.uk.xensource.com>
References: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-118268911-1415960331=:26318"
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 for-xen-4.5] xen_disk: fix unmapping of
 persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-118268911-1415960331=:26318
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 13 Nov 2014, Roger Pau Monne wrote:
> This patch fixes two issues with persistent grants and the disk PV backen=
d
> (Qdisk):
>=20
>  - Keep track of memory regions where persistent grants have been mapped
>    since we need to unmap them as a whole. It is not possible to unmap a
>    single grant if it has been batch-mapped. A new check has also been ad=
ded
>    to make sure persistent grants are only used if the whole mapped regio=
n
>    can be persistently mapped in the batch_maps case.
>  - Unmap persistent grants before switching to the closed state, so the
>    frontend can also free them.
>=20
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> Reported-by: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Kevin Wolf <kwolf@redhat.com>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

I'll send a pull request and backport to qemu-xen.


> Xen release exception: this is obviously an important bug-fix that should=
 be
> included in 4.5. Without this fix, trying to do a block-detach of a Qdisk
> from a running guest can lead to guest crash depending on the blkfront
> implementation.
> ---
> Changea since v2:
>  - Expand the commit message to mention the newly added check.
>  - Don't use persistent_regions in the !batch_maps case, we can use the
>    previous implementation which works fine in that case.
>=20
> Changes since v1:
>  - Instead of disabling batch mappings when using persistent grants, keep
>    track of the persistently mapped regions and unmap them on disconnecti=
on.
>    This prevents unmapping single persistent grants, but the current
>    implementation doesn't require it.
>=20
> This new version is slightly faster than the previous one, the following
> test results are in IOPS from 20 runs of a block-attach, fio run,
> block-detach test loop:
>=20
> x batch
> + no_batch
> +----------------------------------------------------------------------+
> |                                      +   +     x    x + + +  x xx x  |
> |+  +           x                     x+  *+++   *  +x* +++x*  x xx x *|
> |                                          |_____________A_____M______||
> |                            |________________A_____M___________|      |
> +----------------------------------------------------------------------+
>     N           Min           Max        Median           Avg        Stdd=
ev
> x  20         52941         63822         62396      61180.15     2673.64=
97
> +  20         49967         63849         60322       59116.9     3456.34=
55
> Difference at 95.0% confidence
> =09-2063.25 +/- 1977.66
> =09-3.37242% +/- 3.23252%
> =09(Student's t, pooled s =3D 3089.88)
> ---
>  hw/block/xen_disk.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++=
+-----
>  1 file changed, 66 insertions(+), 6 deletions(-)
>=20
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 231e9a7..21842a0 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -59,6 +59,13 @@ struct PersistentGrant {
> =20
>  typedef struct PersistentGrant PersistentGrant;
> =20
> +struct PersistentRegion {
> +    void *addr;
> +    int num;
> +};
> +
> +typedef struct PersistentRegion PersistentRegion;
> +
>  struct ioreq {
>      blkif_request_t     req;
>      int16_t             status;
> @@ -118,6 +125,7 @@ struct XenBlkDev {
>      gboolean            feature_discard;
>      gboolean            feature_persistent;
>      GTree               *persistent_gnts;
> +    GSList              *persistent_regions;
>      unsigned int        persistent_gnt_count;
>      unsigned int        max_grants;
> =20
> @@ -177,6 +185,23 @@ static void destroy_grant(gpointer pgnt)
>      g_free(grant);
>  }
> =20
> +static void remove_persistent_region(gpointer data, gpointer dev)
> +{
> +    PersistentRegion *region =3D data;
> +    struct XenBlkDev *blkdev =3D dev;
> +    XenGnttab gnt =3D blkdev->xendev.gnttabdev;
> +
> +    if (xc_gnttab_munmap(gnt, region->addr, region->num) !=3D 0) {
> +        xen_be_printf(&blkdev->xendev, 0,
> +                      "xc_gnttab_munmap region %p failed: %s\n",
> +                      region->addr, strerror(errno));
> +    }
> +    xen_be_printf(&blkdev->xendev, 3,
> +                  "unmapped grant region %p with %d pages\n",
> +                  region->addr, region->num);
> +    g_free(region);
> +}
> +
>  static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
>  {
>      struct ioreq *ioreq =3D NULL;
> @@ -343,6 +368,7 @@ static int ioreq_map(struct ioreq *ioreq)
>      void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>      int i, j, new_maps =3D 0;
>      PersistentGrant *grant;
> +    PersistentRegion *region;
>      /* domids and refs variables will contain the information necessary
>       * to map the grants that are needed to fulfill this request.
>       *
> @@ -421,7 +447,22 @@ static int ioreq_map(struct ioreq *ioreq)
>              }
>          }
>      }
> -    if (ioreq->blkdev->feature_persistent) {
> +    if (ioreq->blkdev->feature_persistent && new_maps !=3D 0 &&
> +        (!batch_maps || (ioreq->blkdev->persistent_gnt_count + new_maps =
<=3D
> +        ioreq->blkdev->max_grants))) {
> +        /*
> +         * If we are using persistent grants and batch mappings only
> +         * add the new maps to the list of persistent grants if the whol=
e
> +         * area can be persistently mapped.
> +         */
> +        if (batch_maps) {
> +            region =3D g_malloc0(sizeof(*region));
> +            region->addr =3D ioreq->pages;
> +            region->num =3D new_maps;
> +            ioreq->blkdev->persistent_regions =3D g_slist_append(
> +                                            ioreq->blkdev->persistent_re=
gions,
> +                                            region);
> +        }
>          while ((ioreq->blkdev->persistent_gnt_count < ioreq->blkdev->max=
_grants)
>                && new_maps) {
>              /* Go through the list of newly mapped grants and add as man=
y
> @@ -447,6 +488,7 @@ static int ioreq_map(struct ioreq *ioreq)
>                            grant);
>              ioreq->blkdev->persistent_gnt_count++;
>          }
> +        assert(!batch_maps || new_maps =3D=3D 0);
>      }
>      for (i =3D 0; i < ioreq->v.niov; i++) {
>          ioreq->v.iov[i].iov_base +=3D (uintptr_t)page[i];
> @@ -971,7 +1013,10 @@ static int blk_connect(struct XenDevice *xendev)
>          blkdev->max_grants =3D max_requests * BLKIF_MAX_SEGMENTS_PER_REQ=
UEST;
>          blkdev->persistent_gnts =3D g_tree_new_full((GCompareDataFunc)in=
t_cmp,
>                                               NULL, NULL,
> +                                             batch_maps ?
> +                                             (GDestroyNotify)g_free :
>                                               (GDestroyNotify)destroy_gra=
nt);
> +        blkdev->persistent_regions =3D NULL;
>          blkdev->persistent_gnt_count =3D 0;
>      }
> =20
> @@ -1000,6 +1045,26 @@ static void blk_disconnect(struct XenDevice *xende=
v)
>          blkdev->cnt_map--;
>          blkdev->sring =3D NULL;
>      }
> +
> +    /*
> +     * Unmap persistent grants before switching to the closed state
> +     * so the frontend can free them.
> +     *
> +     * In the !batch_maps case g_tree_destroy will take care of unmappin=
g
> +     * the grant, but in the batch_maps case we need to iterate over eve=
ry
> +     * region in persistent_regions and unmap it.
> +     */
> +    if (blkdev->feature_persistent) {
> +        g_tree_destroy(blkdev->persistent_gnts);
> +        assert(batch_maps || blkdev->persistent_gnt_count =3D=3D 0);
> +        if (batch_maps) {
> +            blkdev->persistent_gnt_count =3D 0;
> +            g_slist_foreach(blkdev->persistent_regions,
> +                            (GFunc)remove_persistent_region, blkdev);
> +            g_slist_free(blkdev->persistent_regions);
> +        }
> +        blkdev->feature_persistent =3D false;
> +    }
>  }
> =20
>  static int blk_free(struct XenDevice *xendev)
> @@ -1011,11 +1076,6 @@ static int blk_free(struct XenDevice *xendev)
>          blk_disconnect(xendev);
>      }
> =20
> -    /* Free persistent grants */
> -    if (blkdev->feature_persistent) {
> -        g_tree_destroy(blkdev->persistent_gnts);
> -    }
> -
>      while (!QLIST_EMPTY(&blkdev->freelist)) {
>          ioreq =3D QLIST_FIRST(&blkdev->freelist);
>          QLIST_REMOVE(ioreq, list);
> --=20
> 1.9.3 (Apple Git-50)
>=20
--1342847746-118268911-1415960331=:26318
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-118268911-1415960331=:26318--


From xen-devel-bounces@lists.xen.org Fri Nov 14 10:19:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:19:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpDyD-0004gG-1j; Fri, 14 Nov 2014 10:19:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpDyC-0004g7-1J
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 10:19:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/B1-24532-F17D5645; Fri, 14 Nov 2014 10:19:11 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415960349!4701821!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25849 invoked from network); 14 Nov 2014 10:19:10 -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;
	14 Nov 2014 10:19:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191329596"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 05:19:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpDy7-0005RM-8N;
	Fri, 14 Nov 2014 10:19:07 +0000
Date: Fri, 14 Nov 2014 10:18:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
Message-ID: <alpine.DEB.2.02.1411141018230.26318@kaball.uk.xensource.com>
References: <1415900529-10629-1-git-send-email-roger.pau@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-118268911-1415960331=:26318"
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 for-xen-4.5] xen_disk: fix unmapping of
 persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-118268911-1415960331=:26318
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 13 Nov 2014, Roger Pau Monne wrote:
> This patch fixes two issues with persistent grants and the disk PV backen=
d
> (Qdisk):
>=20
>  - Keep track of memory regions where persistent grants have been mapped
>    since we need to unmap them as a whole. It is not possible to unmap a
>    single grant if it has been batch-mapped. A new check has also been ad=
ded
>    to make sure persistent grants are only used if the whole mapped regio=
n
>    can be persistently mapped in the batch_maps case.
>  - Unmap persistent grants before switching to the closed state, so the
>    frontend can also free them.
>=20
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> Reported-by: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Kevin Wolf <kwolf@redhat.com>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

I'll send a pull request and backport to qemu-xen.


> Xen release exception: this is obviously an important bug-fix that should=
 be
> included in 4.5. Without this fix, trying to do a block-detach of a Qdisk
> from a running guest can lead to guest crash depending on the blkfront
> implementation.
> ---
> Changea since v2:
>  - Expand the commit message to mention the newly added check.
>  - Don't use persistent_regions in the !batch_maps case, we can use the
>    previous implementation which works fine in that case.
>=20
> Changes since v1:
>  - Instead of disabling batch mappings when using persistent grants, keep
>    track of the persistently mapped regions and unmap them on disconnecti=
on.
>    This prevents unmapping single persistent grants, but the current
>    implementation doesn't require it.
>=20
> This new version is slightly faster than the previous one, the following
> test results are in IOPS from 20 runs of a block-attach, fio run,
> block-detach test loop:
>=20
> x batch
> + no_batch
> +----------------------------------------------------------------------+
> |                                      +   +     x    x + + +  x xx x  |
> |+  +           x                     x+  *+++   *  +x* +++x*  x xx x *|
> |                                          |_____________A_____M______||
> |                            |________________A_____M___________|      |
> +----------------------------------------------------------------------+
>     N           Min           Max        Median           Avg        Stdd=
ev
> x  20         52941         63822         62396      61180.15     2673.64=
97
> +  20         49967         63849         60322       59116.9     3456.34=
55
> Difference at 95.0% confidence
> =09-2063.25 +/- 1977.66
> =09-3.37242% +/- 3.23252%
> =09(Student's t, pooled s =3D 3089.88)
> ---
>  hw/block/xen_disk.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++=
+-----
>  1 file changed, 66 insertions(+), 6 deletions(-)
>=20
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 231e9a7..21842a0 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -59,6 +59,13 @@ struct PersistentGrant {
> =20
>  typedef struct PersistentGrant PersistentGrant;
> =20
> +struct PersistentRegion {
> +    void *addr;
> +    int num;
> +};
> +
> +typedef struct PersistentRegion PersistentRegion;
> +
>  struct ioreq {
>      blkif_request_t     req;
>      int16_t             status;
> @@ -118,6 +125,7 @@ struct XenBlkDev {
>      gboolean            feature_discard;
>      gboolean            feature_persistent;
>      GTree               *persistent_gnts;
> +    GSList              *persistent_regions;
>      unsigned int        persistent_gnt_count;
>      unsigned int        max_grants;
> =20
> @@ -177,6 +185,23 @@ static void destroy_grant(gpointer pgnt)
>      g_free(grant);
>  }
> =20
> +static void remove_persistent_region(gpointer data, gpointer dev)
> +{
> +    PersistentRegion *region =3D data;
> +    struct XenBlkDev *blkdev =3D dev;
> +    XenGnttab gnt =3D blkdev->xendev.gnttabdev;
> +
> +    if (xc_gnttab_munmap(gnt, region->addr, region->num) !=3D 0) {
> +        xen_be_printf(&blkdev->xendev, 0,
> +                      "xc_gnttab_munmap region %p failed: %s\n",
> +                      region->addr, strerror(errno));
> +    }
> +    xen_be_printf(&blkdev->xendev, 3,
> +                  "unmapped grant region %p with %d pages\n",
> +                  region->addr, region->num);
> +    g_free(region);
> +}
> +
>  static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
>  {
>      struct ioreq *ioreq =3D NULL;
> @@ -343,6 +368,7 @@ static int ioreq_map(struct ioreq *ioreq)
>      void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>      int i, j, new_maps =3D 0;
>      PersistentGrant *grant;
> +    PersistentRegion *region;
>      /* domids and refs variables will contain the information necessary
>       * to map the grants that are needed to fulfill this request.
>       *
> @@ -421,7 +447,22 @@ static int ioreq_map(struct ioreq *ioreq)
>              }
>          }
>      }
> -    if (ioreq->blkdev->feature_persistent) {
> +    if (ioreq->blkdev->feature_persistent && new_maps !=3D 0 &&
> +        (!batch_maps || (ioreq->blkdev->persistent_gnt_count + new_maps =
<=3D
> +        ioreq->blkdev->max_grants))) {
> +        /*
> +         * If we are using persistent grants and batch mappings only
> +         * add the new maps to the list of persistent grants if the whol=
e
> +         * area can be persistently mapped.
> +         */
> +        if (batch_maps) {
> +            region =3D g_malloc0(sizeof(*region));
> +            region->addr =3D ioreq->pages;
> +            region->num =3D new_maps;
> +            ioreq->blkdev->persistent_regions =3D g_slist_append(
> +                                            ioreq->blkdev->persistent_re=
gions,
> +                                            region);
> +        }
>          while ((ioreq->blkdev->persistent_gnt_count < ioreq->blkdev->max=
_grants)
>                && new_maps) {
>              /* Go through the list of newly mapped grants and add as man=
y
> @@ -447,6 +488,7 @@ static int ioreq_map(struct ioreq *ioreq)
>                            grant);
>              ioreq->blkdev->persistent_gnt_count++;
>          }
> +        assert(!batch_maps || new_maps =3D=3D 0);
>      }
>      for (i =3D 0; i < ioreq->v.niov; i++) {
>          ioreq->v.iov[i].iov_base +=3D (uintptr_t)page[i];
> @@ -971,7 +1013,10 @@ static int blk_connect(struct XenDevice *xendev)
>          blkdev->max_grants =3D max_requests * BLKIF_MAX_SEGMENTS_PER_REQ=
UEST;
>          blkdev->persistent_gnts =3D g_tree_new_full((GCompareDataFunc)in=
t_cmp,
>                                               NULL, NULL,
> +                                             batch_maps ?
> +                                             (GDestroyNotify)g_free :
>                                               (GDestroyNotify)destroy_gra=
nt);
> +        blkdev->persistent_regions =3D NULL;
>          blkdev->persistent_gnt_count =3D 0;
>      }
> =20
> @@ -1000,6 +1045,26 @@ static void blk_disconnect(struct XenDevice *xende=
v)
>          blkdev->cnt_map--;
>          blkdev->sring =3D NULL;
>      }
> +
> +    /*
> +     * Unmap persistent grants before switching to the closed state
> +     * so the frontend can free them.
> +     *
> +     * In the !batch_maps case g_tree_destroy will take care of unmappin=
g
> +     * the grant, but in the batch_maps case we need to iterate over eve=
ry
> +     * region in persistent_regions and unmap it.
> +     */
> +    if (blkdev->feature_persistent) {
> +        g_tree_destroy(blkdev->persistent_gnts);
> +        assert(batch_maps || blkdev->persistent_gnt_count =3D=3D 0);
> +        if (batch_maps) {
> +            blkdev->persistent_gnt_count =3D 0;
> +            g_slist_foreach(blkdev->persistent_regions,
> +                            (GFunc)remove_persistent_region, blkdev);
> +            g_slist_free(blkdev->persistent_regions);
> +        }
> +        blkdev->feature_persistent =3D false;
> +    }
>  }
> =20
>  static int blk_free(struct XenDevice *xendev)
> @@ -1011,11 +1076,6 @@ static int blk_free(struct XenDevice *xendev)
>          blk_disconnect(xendev);
>      }
> =20
> -    /* Free persistent grants */
> -    if (blkdev->feature_persistent) {
> -        g_tree_destroy(blkdev->persistent_gnts);
> -    }
> -
>      while (!QLIST_EMPTY(&blkdev->freelist)) {
>          ioreq =3D QLIST_FIRST(&blkdev->freelist);
>          QLIST_REMOVE(ioreq, list);
> --=20
> 1.9.3 (Apple Git-50)
>=20
--1342847746-118268911-1415960331=:26318
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-118268911-1415960331=:26318--


From xen-devel-bounces@lists.xen.org Fri Nov 14 10:22:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpE1N-00050v-QN; Fri, 14 Nov 2014 10:22:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <talex5@gmail.com>) id 1XpE1M-00050q-5k
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 10:22:28 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	E9/8F-18267-3E7D5645; Fri, 14 Nov 2014 10:22:27 +0000
X-Env-Sender: talex5@gmail.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415960545!11306477!1
X-Originating-IP: [209.85.220.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18261 invoked from network); 14 Nov 2014 10:22:26 -0000
Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com)
	(209.85.220.169)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:22:26 -0000
Received: by mail-vc0-f169.google.com with SMTP id hy10so696605vcb.0
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 02:22:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=XoxqOfFovRsoCQ0ekNStvUfGdcFBsnVlhh+pxBCUiuQ=;
	b=BC3XEYnjUwAuR0B4/VrCRp4K4QHiWRP+4A3MuTU1ofjtulXY5seoIoHI1oTaln0Qgc
	pi9qfM5Cc5ERjqAVQVZqmqGXc4KBO69DqlqrMt7B0DZ1DbxXvvcHhJEa6ONE6TIXn4B7
	2cA5cbXS7lo6qdETjWPkVqShfYTS+rC7LM906rgS+oo402y+1CRfbFvNFwOqaBg6U/Zu
	4vWsOjQE5J3Axd/9VGYYwOHPPsybiLipCVAmXu7M12oy1TCQkcV3wkyBWdNh6CO5Hhe3
	OZ0Riw6AM90V0FWwCehntYpqooHlItLAtxbuLI/BjRK7nk1tHJMeHc6/pU8RDo8ud9CE
	2CAw==
MIME-Version: 1.0
X-Received: by 10.220.195.132 with SMTP id ec4mr6396772vcb.16.1415960545160;
	Fri, 14 Nov 2014 02:22:25 -0800 (PST)
Received: by 10.31.130.80 with HTTP; Fri, 14 Nov 2014 02:22:25 -0800 (PST)
In-Reply-To: <544FBB76.7050102@linaro.org>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-3-git-send-email-talex5@gmail.com>
	<1413889218.23337.24.camel@citrix.com>
	<20141021215406.GJ3481@type.youpi.perso.aquilenet.fr>
	<1413968619.20604.56.camel@citrix.com>
	<5447ABE4.1030703@linaro.org>
	<CAG4opy9QCRaMY41=M0HfK4vajvcE=nS+5P-L91itgOMDOBGS4w@mail.gmail.com>
	<544FB580.7080809@linaro.org>
	<CAG4opy-th0P+BBaRJOHeSP0jo=2hS1MqqVM2793q6NdB8jvEKA@mail.gmail.com>
	<544FBB76.7050102@linaro.org>
Date: Fri, 14 Nov 2014 10:22:25 +0000
Message-ID: <CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>
From: Thomas Leonard <talex5@gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH ARM v8 2/4] mini-os: arm: interrupt
	controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjggT2N0b2JlciAyMDE0IDE1OjUxLCBKdWxpZW4gR3JhbGwgPGp1bGllbi5ncmFsbEBsaW5h
cm8ub3JnPiB3cm90ZToKPiBPbiAxMC8yOC8yMDE0IDAzOjQzIFBNLCBUaG9tYXMgTGVvbmFyZCB3
cm90ZToKPj4gT24gMjggT2N0b2JlciAyMDE0IDE1OjI1LCBKdWxpZW4gR3JhbGwgPGp1bGllbi5n
cmFsbEBsaW5hcm8ub3JnPiB3cm90ZToKPj4+IE9uIDEwLzI4LzIwMTQgMDM6MTUgUE0sIFRob21h
cyBMZW9uYXJkIHdyb3RlOgo+Pj4+IE9uIDIyIE9jdG9iZXIgMjAxNCAxNDowNiwgSnVsaWVuIEdy
YWxsIDxqdWxpZW4uZ3JhbGxAbGluYXJvLm9yZz4gd3JvdGU6Cj4+Pj4+IE9uIDEwLzIyLzIwMTQg
MTA6MDMgQU0sIElhbiBDYW1wYmVsbCB3cm90ZToKPj4+Pj4+IE9uIFR1ZSwgMjAxNC0xMC0yMSBh
dCAyMzo1NCArMDIwMCwgU2FtdWVsIFRoaWJhdWx0IHdyb3RlOgo+Pj4+Pj4+IElhbiBDYW1wYmVs
bCwgbGUgVHVlIDIxIE9jdCAyMDE0IDEyOjAwOjE4ICswMTAwLCBhIMOpY3JpdCA6Cj4+Pj4+Pj4+
IE9uIEZyaSwgMjAxNC0xMC0wMyBhdCAxMDoyMCArMDEwMCwgVGhvbWFzIExlb25hcmQgd3JvdGU6
Cj4+Pj4+Pj4+PiArc3RhdGljIGlubGluZSB1aW50MzJfdCBSRUdfUkVBRDMyKHZvbGF0aWxlIHVp
bnQzMl90ICphZGRyKQo+Pj4+Pj4+Pj4gK3sKPj4+Pj4+Pj4+ICsgICAgdWludDMyX3QgdmFsdWU7
Cj4+Pj4+Pj4+PiArICAgIF9fYXNtX18gX192b2xhdGlsZV9fKCJsZHIgJTAsIFslMV0iOiI9JnIi
KHZhbHVlKToiciIoYWRkcikpOwo+Pj4+Pj4+Pj4gKyAgICBybWIoKTsKPj4+Pj4+Pj4KPj4+Pj4+
Pj4gSSdtIG5vdCAxMDAlIGNvbnZpbmNlZCB0aGF0IHlvdSBuZWVkIHRoaXMgcm1iKCkuCj4+Pj4+
Cj4+Pj4+IE1vc3QgdGhlIEdJQyBjb2RlIGRvZXNuJ3QgcmVxdWlyZSByZWFkIGJhcnJpZXIgYnV0
Li4uCj4+Pj4+Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+PiArICAgIHJldHVybiB2YWx1ZTsKPj4+Pj4+Pj4+
ICt9Cj4+Pj4+Pj4+PiArCj4+Pj4+Pj4+PiArc3RhdGljIGlubGluZSB2b2lkIFJFR19XUklURTMy
KHZvbGF0aWxlIHVpbnQzMl90ICphZGRyLCB1bnNpZ25lZCBpbnQgdmFsdWUpCj4+Pj4+Pj4+PiAr
ewo+Pj4+Pj4+Pj4gKyAgICBfX2FzbV9fIF9fdm9sYXRpbGVfXygic3RyICUwLCBbJTFdIjo6InIi
KHZhbHVlKSwgInIiKGFkZHIpKTsKPj4+Pj4+Pj4+ICsgICAgd21iKCk7Cj4+Pj4+Pj4+PiArfQo+
Pj4+Pgo+Pj4+PiB3cml0ZSBiYXJyaWVyIG1heSBiZSBuZWNlc3Nhcnkgb24gc29tZSwgd2hlcmUg
d2UgbmVlZCB0byB3YWl0IHRoYXQgYWxsCj4+Pj4+IHdyaXRlIGhhcyBiZWVuIGRvbmUgYmVmb3Jl
IGRvaW5nIHRoaXMgb25lIChzdWNoIGFzIGVuYWJsZSB0aGUgR0lDIC4uLikuCj4+Pj4+Cj4+Pj4+
IFNvIHRoaXMgZnVuY3Rpb24gaXMgYnVnZ3kuIEl0IHNob3VsZCBiZToKPj4+Pj4KPj4+Pj4gd21i
KCk7Cj4+Pj4+IF9fYXNtX18gX192b2xhdGlsZV9fKC4uLi4pLgo+Pj4+Cj4+Pj4gZ2ljX2luaXQg
ZG9lcyBhbiBleHBsaWNpdCB3bWIoKSBiZWZvcmUgZW5hYmxpbmcgdGhlIEdJQyBhbnl3YXksCj4+
Pj4gYWx0aG91Z2ggSSdtIG5vdCByZWFsbHkgc3VyZSB3aHkgaXQncyBuZWVkZWQgKHRoZXNlIGJh
cnJpZXJzIGFyZSBmcm9tCj4+Pj4gS2FyaW0ncyBvcmlnaW5hbCBjb2RlLCBzbyBJIGRvbid0IGtu
b3cgdGhlIG9yaWdpbmFsIHJlYXNvbiBmb3IgdGhlbSkuCj4+Pj4gWGVuIHdpbGwgaGF2ZSBtYXJr
ZWQgdGhlIEdJQyBtZW1vcnkgYXMgZGV2aWNlIG1lbW9yeSwgc28gSSBndWVzcyB3ZSdyZQo+Pj4+
IHByb3RlY3RlZCBmcm9tIG1hbnkgZWZmZWN0cyAoIlRoZSBudW1iZXIsIG9yZGVyIGFuZCBzaXpl
cyBvZiB0aGUKPj4+PiBhY2Nlc3NlcyBhcmUgbWFpbnRhaW5lZC4iKS4KPj4+Cj4+PiBEZXZpY2Ug
bWVtb3J5IGRvZXNuJ3QgbWVhbiB0aGUgYmFycmllciBhcmUgbm90IG5lY2Vzc2FyeS4uLiBUaGUg
YmFycmllcnMKPj4+IGFyZSB0aGVyZSBmb3IgdGhlIHdob2xlIG1lbW9yeSwgbm90IG9ubHkgdGhl
IEdJQyBtZW1vcnkuCj4+Pgo+Pj4gQSBjb21tb24gdXNlIGNhc2UgaXMgc2VuZGluZyBhbiBTR0ku
IFlvdSBuZWVkIHRvIGVuc3VyZSB0aGF0IGV2ZXJ5Cj4+PiByZWFkL3dyaXRlIGJlZm9yZSB0aGUg
U0dJIHdpbGwgYmUgc2VlbiBieSB0aGUgb3RoZXIgcHJvY2Vzc29ycy4KPj4+IE90aGVyd2lzZSB0
aGV5IG1heSBub3Qgc2VlIGNvcnJlY3RseSB0aGUgZGF0YS4KPj4KPj4gUmlnaHQsIGJ1dCBJIG1l
YW4gaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBjb2RlLiBUaGUgb25seSB0aGluZ3Mgd2UncmUgZG9p
bmcgYXJlOgo+Pgo+PiAtIGVuYWJsaW5nIGludGVycnVwdHMgKGluIGdpY19pbml0KQo+Cj4gWW91
IG5lZWQgdG8gdGFrZSBjYXJlIG9mIHRoZSBiYXJyaWVyL2xvY2sgZm9yIGVuYWJsaW5nIGludGVy
cnVwdHMuIE90aGVyCj4gcHJvY2Vzc29yIG1heSBiZSBwcmVzZW50IGF0IHRoYXQgdGltZS4KPgo+
IFRob3VnaCBJSVJDLCBtaW5pLW9zIGZvciBBUk0gaXMgbm90IHlldCBTTVAuCgpJdCdzIGRpZmZp
Y3VsdCB0byBzZWUgd2hhdCBuZWVkcyB0byBiZSBkb25lIHRvIHN1cHBvcnQgY29kZSB0aGF0CmRv
ZXNuJ3QgZXhpc3QgeWV0LiBGb3IgZXhhbXBsZSwgd291bGQgZ2ljX2luaXQgYmUgY2FsbGVkIG9u
Y2UsIG9yIG9uY2UKcGVyIHByb2Nlc3Nvcj8gQmVmb3JlIG9yIGFmdGVyIHRoZSBvdGhlciBwcm9j
ZXNzb3JzIGFyZSBzdGFydGVkPwoKPj4gLSByZWFkaW5nIGFuZCBhY2tpbmcgYW4gaW50ZXJydXB0
IChpbiBnaWNfaGFuZGxlcikKPgo+IFlvdSBkb24ndCBjYXJlIGZvciB0aGlzIHBhcnQgYXMgaXQn
cyBwZXIgQ1BVLgoKSnVzdCB0byBjb25maXJtOiB5b3UgbWVhbiB0aGF0IHdyaXRpbmcgdG8gdGhl
IEdJQyByZWdpc3RlcnMgaGFwcGVucwppbW1lZGlhdGVseSwgd2l0aG91dCBidWZmZXJpbmc/IGku
ZS4gY2FsbGluZyBnaWNfZW9pcigpIGFuZCB0aGVuCnJlZW5hYmxpbmcgaW50ZXJydXB0cyB3b24n
dCB0cmlnZ2VyIGFnYWluIGJlY2F1c2UgdGhlIGFjayBoYXNuJ3QKcmVhY2hlZCB0aGUgR0lDIHll
dD8KCj4gWy4uXQo+Cj4+IElmIGVuYWJsaW5nIGludGVycnVwdHMgaXMgZGVsYXllZCBzbGlnaHRs
eSwgaXQgc2hvdWxkbid0IGhhdmUgYW55Cj4+IGVmZmVjdCAoZXZlbiBpZiB3ZSBnZXQgdG8gYmxv
Y2tfZG9tYWluLCB3Zmkgd2lsbCBmbHVzaCB0aGUgd3JpdGVzKS4KPgo+IFJlbHlpbmcgb24gYSBs
YXRlciBmbHVzaCB0aGF0IGlzIGN1cnJlbnRseSBleGlzdGluZyBpcyBub3QgdGhlIHJpZ2h0Cj4g
dGhpbmcgdG8gZG8uIFlvdSBkb24ndCBrbm93IGhvdyBtaW5pLW9zIHdpbGwgZXZvbHZlLgo+Cj4g
WW91IGhhdmUgdG8gY2hlY2sgaWYgYmFycmllcnMgYXJlIG5lZWRlZCBldmVyeXdoZXJlLgoKQ291
bGQgeW91IGdpdmUgYSBjb25jcmV0ZSBleGFtcGxlIG9mIHdoZXJlIG5vdCBoYXZpbmcgYSBiYXJy
aWVyIHdvdWxkCmNhdXNlIGEgcHJvYmxlbT8gQXMgZmFyIGFzIEkgY2FuIHNlZToKCi0gSWYgdGhl
IGNhbGxlciBvZiBnaWNfaW5pdCByZXF1aXJlcyBzb21ldGhpbmcgdG8gcmVhY2ggUkFNLCBkaXNr
IG9yCndoYXRldmVyIGJlZm9yZSBpbnRlcnJ1cHRzIGFyZSBlbmFibGVkLCB0aGVuIHRoYXQgY2Fs
bGVyIHNob3VsZCBhZGQKdGhlIGJhcnJpZXIuIGdpYy5jIGNhbid0IGtub3cgd2hhdCBuZWVkcyBm
bHVzaGluZyBmaXJzdC4KCi0gT3BlcmF0aW9ucyBwZXJmb3JtZWQgYnkgZ2ljLmMgYXJlIHN5bmNo
cm9ub3VzLCBiZWNhdXNlIHRoZXkgd3JpdGUgdG8KZGV2aWNlIG1lbW9yeSAoc28gdGhlIHByb2Nl
c3NvciBjYW4ndCByZW9yZGVyIHRoZW0pIGFuZCB1c2UgX19hc21fXwpfX3ZvbGF0aWxlX18gKHBy
ZXZlbnRpbmcgdGhlIGNvbXBpbGVyIGZyb20gcmVvcmRlcmluZyB0aGVtKS4gU28gdGhlcmUKc2hv
dWxkIGJlIG5vIG5lZWQgZm9yIGEgYmFycmllciBhZnRlcndhcmRzLCBvciBpbiBiZXR3ZWVuIG9w
ZXJhdGlvbnMKZWl0aGVyLgoKCi0tIApEciBUaG9tYXMgTGVvbmFyZCAgICAgICAgaHR0cDovLzBp
bnN0YWxsLm5ldC8KR1BHOiA5MjQyIDk4MDcgQzk4NSAzQzA3IDQ0QTYgIDhCOUEgQUUwNyA4Mjgw
IDU5QTUgM0NDMQpHUEc6IERBOTggMjVBRSBDQUQwIDg5NzUgN0NEQSAgQkQ4RSAwNzEzIDNGOTYg
Q0E3NCBEOEJBCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:22:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpE1N-00050v-QN; Fri, 14 Nov 2014 10:22:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <talex5@gmail.com>) id 1XpE1M-00050q-5k
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 10:22:28 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	E9/8F-18267-3E7D5645; Fri, 14 Nov 2014 10:22:27 +0000
X-Env-Sender: talex5@gmail.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415960545!11306477!1
X-Originating-IP: [209.85.220.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18261 invoked from network); 14 Nov 2014 10:22:26 -0000
Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com)
	(209.85.220.169)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:22:26 -0000
Received: by mail-vc0-f169.google.com with SMTP id hy10so696605vcb.0
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 02:22:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=XoxqOfFovRsoCQ0ekNStvUfGdcFBsnVlhh+pxBCUiuQ=;
	b=BC3XEYnjUwAuR0B4/VrCRp4K4QHiWRP+4A3MuTU1ofjtulXY5seoIoHI1oTaln0Qgc
	pi9qfM5Cc5ERjqAVQVZqmqGXc4KBO69DqlqrMt7B0DZ1DbxXvvcHhJEa6ONE6TIXn4B7
	2cA5cbXS7lo6qdETjWPkVqShfYTS+rC7LM906rgS+oo402y+1CRfbFvNFwOqaBg6U/Zu
	4vWsOjQE5J3Axd/9VGYYwOHPPsybiLipCVAmXu7M12oy1TCQkcV3wkyBWdNh6CO5Hhe3
	OZ0Riw6AM90V0FWwCehntYpqooHlItLAtxbuLI/BjRK7nk1tHJMeHc6/pU8RDo8ud9CE
	2CAw==
MIME-Version: 1.0
X-Received: by 10.220.195.132 with SMTP id ec4mr6396772vcb.16.1415960545160;
	Fri, 14 Nov 2014 02:22:25 -0800 (PST)
Received: by 10.31.130.80 with HTTP; Fri, 14 Nov 2014 02:22:25 -0800 (PST)
In-Reply-To: <544FBB76.7050102@linaro.org>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-3-git-send-email-talex5@gmail.com>
	<1413889218.23337.24.camel@citrix.com>
	<20141021215406.GJ3481@type.youpi.perso.aquilenet.fr>
	<1413968619.20604.56.camel@citrix.com>
	<5447ABE4.1030703@linaro.org>
	<CAG4opy9QCRaMY41=M0HfK4vajvcE=nS+5P-L91itgOMDOBGS4w@mail.gmail.com>
	<544FB580.7080809@linaro.org>
	<CAG4opy-th0P+BBaRJOHeSP0jo=2hS1MqqVM2793q6NdB8jvEKA@mail.gmail.com>
	<544FBB76.7050102@linaro.org>
Date: Fri, 14 Nov 2014 10:22:25 +0000
Message-ID: <CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>
From: Thomas Leonard <talex5@gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH ARM v8 2/4] mini-os: arm: interrupt
	controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjggT2N0b2JlciAyMDE0IDE1OjUxLCBKdWxpZW4gR3JhbGwgPGp1bGllbi5ncmFsbEBsaW5h
cm8ub3JnPiB3cm90ZToKPiBPbiAxMC8yOC8yMDE0IDAzOjQzIFBNLCBUaG9tYXMgTGVvbmFyZCB3
cm90ZToKPj4gT24gMjggT2N0b2JlciAyMDE0IDE1OjI1LCBKdWxpZW4gR3JhbGwgPGp1bGllbi5n
cmFsbEBsaW5hcm8ub3JnPiB3cm90ZToKPj4+IE9uIDEwLzI4LzIwMTQgMDM6MTUgUE0sIFRob21h
cyBMZW9uYXJkIHdyb3RlOgo+Pj4+IE9uIDIyIE9jdG9iZXIgMjAxNCAxNDowNiwgSnVsaWVuIEdy
YWxsIDxqdWxpZW4uZ3JhbGxAbGluYXJvLm9yZz4gd3JvdGU6Cj4+Pj4+IE9uIDEwLzIyLzIwMTQg
MTA6MDMgQU0sIElhbiBDYW1wYmVsbCB3cm90ZToKPj4+Pj4+IE9uIFR1ZSwgMjAxNC0xMC0yMSBh
dCAyMzo1NCArMDIwMCwgU2FtdWVsIFRoaWJhdWx0IHdyb3RlOgo+Pj4+Pj4+IElhbiBDYW1wYmVs
bCwgbGUgVHVlIDIxIE9jdCAyMDE0IDEyOjAwOjE4ICswMTAwLCBhIMOpY3JpdCA6Cj4+Pj4+Pj4+
IE9uIEZyaSwgMjAxNC0xMC0wMyBhdCAxMDoyMCArMDEwMCwgVGhvbWFzIExlb25hcmQgd3JvdGU6
Cj4+Pj4+Pj4+PiArc3RhdGljIGlubGluZSB1aW50MzJfdCBSRUdfUkVBRDMyKHZvbGF0aWxlIHVp
bnQzMl90ICphZGRyKQo+Pj4+Pj4+Pj4gK3sKPj4+Pj4+Pj4+ICsgICAgdWludDMyX3QgdmFsdWU7
Cj4+Pj4+Pj4+PiArICAgIF9fYXNtX18gX192b2xhdGlsZV9fKCJsZHIgJTAsIFslMV0iOiI9JnIi
KHZhbHVlKToiciIoYWRkcikpOwo+Pj4+Pj4+Pj4gKyAgICBybWIoKTsKPj4+Pj4+Pj4KPj4+Pj4+
Pj4gSSdtIG5vdCAxMDAlIGNvbnZpbmNlZCB0aGF0IHlvdSBuZWVkIHRoaXMgcm1iKCkuCj4+Pj4+
Cj4+Pj4+IE1vc3QgdGhlIEdJQyBjb2RlIGRvZXNuJ3QgcmVxdWlyZSByZWFkIGJhcnJpZXIgYnV0
Li4uCj4+Pj4+Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+PiArICAgIHJldHVybiB2YWx1ZTsKPj4+Pj4+Pj4+
ICt9Cj4+Pj4+Pj4+PiArCj4+Pj4+Pj4+PiArc3RhdGljIGlubGluZSB2b2lkIFJFR19XUklURTMy
KHZvbGF0aWxlIHVpbnQzMl90ICphZGRyLCB1bnNpZ25lZCBpbnQgdmFsdWUpCj4+Pj4+Pj4+PiAr
ewo+Pj4+Pj4+Pj4gKyAgICBfX2FzbV9fIF9fdm9sYXRpbGVfXygic3RyICUwLCBbJTFdIjo6InIi
KHZhbHVlKSwgInIiKGFkZHIpKTsKPj4+Pj4+Pj4+ICsgICAgd21iKCk7Cj4+Pj4+Pj4+PiArfQo+
Pj4+Pgo+Pj4+PiB3cml0ZSBiYXJyaWVyIG1heSBiZSBuZWNlc3Nhcnkgb24gc29tZSwgd2hlcmUg
d2UgbmVlZCB0byB3YWl0IHRoYXQgYWxsCj4+Pj4+IHdyaXRlIGhhcyBiZWVuIGRvbmUgYmVmb3Jl
IGRvaW5nIHRoaXMgb25lIChzdWNoIGFzIGVuYWJsZSB0aGUgR0lDIC4uLikuCj4+Pj4+Cj4+Pj4+
IFNvIHRoaXMgZnVuY3Rpb24gaXMgYnVnZ3kuIEl0IHNob3VsZCBiZToKPj4+Pj4KPj4+Pj4gd21i
KCk7Cj4+Pj4+IF9fYXNtX18gX192b2xhdGlsZV9fKC4uLi4pLgo+Pj4+Cj4+Pj4gZ2ljX2luaXQg
ZG9lcyBhbiBleHBsaWNpdCB3bWIoKSBiZWZvcmUgZW5hYmxpbmcgdGhlIEdJQyBhbnl3YXksCj4+
Pj4gYWx0aG91Z2ggSSdtIG5vdCByZWFsbHkgc3VyZSB3aHkgaXQncyBuZWVkZWQgKHRoZXNlIGJh
cnJpZXJzIGFyZSBmcm9tCj4+Pj4gS2FyaW0ncyBvcmlnaW5hbCBjb2RlLCBzbyBJIGRvbid0IGtu
b3cgdGhlIG9yaWdpbmFsIHJlYXNvbiBmb3IgdGhlbSkuCj4+Pj4gWGVuIHdpbGwgaGF2ZSBtYXJr
ZWQgdGhlIEdJQyBtZW1vcnkgYXMgZGV2aWNlIG1lbW9yeSwgc28gSSBndWVzcyB3ZSdyZQo+Pj4+
IHByb3RlY3RlZCBmcm9tIG1hbnkgZWZmZWN0cyAoIlRoZSBudW1iZXIsIG9yZGVyIGFuZCBzaXpl
cyBvZiB0aGUKPj4+PiBhY2Nlc3NlcyBhcmUgbWFpbnRhaW5lZC4iKS4KPj4+Cj4+PiBEZXZpY2Ug
bWVtb3J5IGRvZXNuJ3QgbWVhbiB0aGUgYmFycmllciBhcmUgbm90IG5lY2Vzc2FyeS4uLiBUaGUg
YmFycmllcnMKPj4+IGFyZSB0aGVyZSBmb3IgdGhlIHdob2xlIG1lbW9yeSwgbm90IG9ubHkgdGhl
IEdJQyBtZW1vcnkuCj4+Pgo+Pj4gQSBjb21tb24gdXNlIGNhc2UgaXMgc2VuZGluZyBhbiBTR0ku
IFlvdSBuZWVkIHRvIGVuc3VyZSB0aGF0IGV2ZXJ5Cj4+PiByZWFkL3dyaXRlIGJlZm9yZSB0aGUg
U0dJIHdpbGwgYmUgc2VlbiBieSB0aGUgb3RoZXIgcHJvY2Vzc29ycy4KPj4+IE90aGVyd2lzZSB0
aGV5IG1heSBub3Qgc2VlIGNvcnJlY3RseSB0aGUgZGF0YS4KPj4KPj4gUmlnaHQsIGJ1dCBJIG1l
YW4gaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBjb2RlLiBUaGUgb25seSB0aGluZ3Mgd2UncmUgZG9p
bmcgYXJlOgo+Pgo+PiAtIGVuYWJsaW5nIGludGVycnVwdHMgKGluIGdpY19pbml0KQo+Cj4gWW91
IG5lZWQgdG8gdGFrZSBjYXJlIG9mIHRoZSBiYXJyaWVyL2xvY2sgZm9yIGVuYWJsaW5nIGludGVy
cnVwdHMuIE90aGVyCj4gcHJvY2Vzc29yIG1heSBiZSBwcmVzZW50IGF0IHRoYXQgdGltZS4KPgo+
IFRob3VnaCBJSVJDLCBtaW5pLW9zIGZvciBBUk0gaXMgbm90IHlldCBTTVAuCgpJdCdzIGRpZmZp
Y3VsdCB0byBzZWUgd2hhdCBuZWVkcyB0byBiZSBkb25lIHRvIHN1cHBvcnQgY29kZSB0aGF0CmRv
ZXNuJ3QgZXhpc3QgeWV0LiBGb3IgZXhhbXBsZSwgd291bGQgZ2ljX2luaXQgYmUgY2FsbGVkIG9u
Y2UsIG9yIG9uY2UKcGVyIHByb2Nlc3Nvcj8gQmVmb3JlIG9yIGFmdGVyIHRoZSBvdGhlciBwcm9j
ZXNzb3JzIGFyZSBzdGFydGVkPwoKPj4gLSByZWFkaW5nIGFuZCBhY2tpbmcgYW4gaW50ZXJydXB0
IChpbiBnaWNfaGFuZGxlcikKPgo+IFlvdSBkb24ndCBjYXJlIGZvciB0aGlzIHBhcnQgYXMgaXQn
cyBwZXIgQ1BVLgoKSnVzdCB0byBjb25maXJtOiB5b3UgbWVhbiB0aGF0IHdyaXRpbmcgdG8gdGhl
IEdJQyByZWdpc3RlcnMgaGFwcGVucwppbW1lZGlhdGVseSwgd2l0aG91dCBidWZmZXJpbmc/IGku
ZS4gY2FsbGluZyBnaWNfZW9pcigpIGFuZCB0aGVuCnJlZW5hYmxpbmcgaW50ZXJydXB0cyB3b24n
dCB0cmlnZ2VyIGFnYWluIGJlY2F1c2UgdGhlIGFjayBoYXNuJ3QKcmVhY2hlZCB0aGUgR0lDIHll
dD8KCj4gWy4uXQo+Cj4+IElmIGVuYWJsaW5nIGludGVycnVwdHMgaXMgZGVsYXllZCBzbGlnaHRs
eSwgaXQgc2hvdWxkbid0IGhhdmUgYW55Cj4+IGVmZmVjdCAoZXZlbiBpZiB3ZSBnZXQgdG8gYmxv
Y2tfZG9tYWluLCB3Zmkgd2lsbCBmbHVzaCB0aGUgd3JpdGVzKS4KPgo+IFJlbHlpbmcgb24gYSBs
YXRlciBmbHVzaCB0aGF0IGlzIGN1cnJlbnRseSBleGlzdGluZyBpcyBub3QgdGhlIHJpZ2h0Cj4g
dGhpbmcgdG8gZG8uIFlvdSBkb24ndCBrbm93IGhvdyBtaW5pLW9zIHdpbGwgZXZvbHZlLgo+Cj4g
WW91IGhhdmUgdG8gY2hlY2sgaWYgYmFycmllcnMgYXJlIG5lZWRlZCBldmVyeXdoZXJlLgoKQ291
bGQgeW91IGdpdmUgYSBjb25jcmV0ZSBleGFtcGxlIG9mIHdoZXJlIG5vdCBoYXZpbmcgYSBiYXJy
aWVyIHdvdWxkCmNhdXNlIGEgcHJvYmxlbT8gQXMgZmFyIGFzIEkgY2FuIHNlZToKCi0gSWYgdGhl
IGNhbGxlciBvZiBnaWNfaW5pdCByZXF1aXJlcyBzb21ldGhpbmcgdG8gcmVhY2ggUkFNLCBkaXNr
IG9yCndoYXRldmVyIGJlZm9yZSBpbnRlcnJ1cHRzIGFyZSBlbmFibGVkLCB0aGVuIHRoYXQgY2Fs
bGVyIHNob3VsZCBhZGQKdGhlIGJhcnJpZXIuIGdpYy5jIGNhbid0IGtub3cgd2hhdCBuZWVkcyBm
bHVzaGluZyBmaXJzdC4KCi0gT3BlcmF0aW9ucyBwZXJmb3JtZWQgYnkgZ2ljLmMgYXJlIHN5bmNo
cm9ub3VzLCBiZWNhdXNlIHRoZXkgd3JpdGUgdG8KZGV2aWNlIG1lbW9yeSAoc28gdGhlIHByb2Nl
c3NvciBjYW4ndCByZW9yZGVyIHRoZW0pIGFuZCB1c2UgX19hc21fXwpfX3ZvbGF0aWxlX18gKHBy
ZXZlbnRpbmcgdGhlIGNvbXBpbGVyIGZyb20gcmVvcmRlcmluZyB0aGVtKS4gU28gdGhlcmUKc2hv
dWxkIGJlIG5vIG5lZWQgZm9yIGEgYmFycmllciBhZnRlcndhcmRzLCBvciBpbiBiZXR3ZWVuIG9w
ZXJhdGlvbnMKZWl0aGVyLgoKCi0tIApEciBUaG9tYXMgTGVvbmFyZCAgICAgICAgaHR0cDovLzBp
bnN0YWxsLm5ldC8KR1BHOiA5MjQyIDk4MDcgQzk4NSAzQzA3IDQ0QTYgIDhCOUEgQUUwNyA4Mjgw
IDU5QTUgM0NDMQpHUEc6IERBOTggMjVBRSBDQUQwIDg5NzUgN0NEQSAgQkQ4RSAwNzEzIDNGOTYg
Q0E3NCBEOEJBCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:23:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:23:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpE1s-00057m-6p; Fri, 14 Nov 2014 10:23:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpE1r-00057b-FS
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:22:59 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	07/EB-27623-208D5645; Fri, 14 Nov 2014 10:22:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415960575!11362015!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29627 invoked from network); 14 Nov 2014 10:22:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:22:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191330394"
Message-ID: <1415960555.21321.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 10:22:35 +0000
In-Reply-To: <20141114100939.GB30599@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
	<20141114100939.GB30599@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 10:09 +0000, Wei Liu wrote:
> On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > > Unconditionally print out the partial configuration.
> > 
> > Can you provide an example of what such a configuration looks like?
> > 
> 
>     {
>         "domid": 2,
>         "config": {
>             "c_info": {
>                 "name": "s0-raw-vnuma",
>                 "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
>             },
>             "b_info": {
>                 "sched_params": {
> 
>                 },
>                 "type.invalid": {
> 
>                 }
>             }
>         }
>     }

Great, thanks. I propose to insert this into the commit message as I
check it in (once I check who's acked it etc)

> Libxl still complains because it tries to read some nodes that don't
> exist, so xl will just print it out on stderr. This is the same
> behaviour as before though.

I think that's tolerable for 4.5 at least.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:23:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:23:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpE1s-00057m-6p; Fri, 14 Nov 2014 10:23:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpE1r-00057b-FS
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:22:59 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	07/EB-27623-208D5645; Fri, 14 Nov 2014 10:22:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415960575!11362015!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29627 invoked from network); 14 Nov 2014 10:22:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:22:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="191330394"
Message-ID: <1415960555.21321.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 10:22:35 +0000
In-Reply-To: <20141114100939.GB30599@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
	<20141114100939.GB30599@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 10:09 +0000, Wei Liu wrote:
> On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > > Unconditionally print out the partial configuration.
> > 
> > Can you provide an example of what such a configuration looks like?
> > 
> 
>     {
>         "domid": 2,
>         "config": {
>             "c_info": {
>                 "name": "s0-raw-vnuma",
>                 "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
>             },
>             "b_info": {
>                 "sched_params": {
> 
>                 },
>                 "type.invalid": {
> 
>                 }
>             }
>         }
>     }

Great, thanks. I propose to insert this into the commit message as I
check it in (once I check who's acked it etc)

> Libxl still complains because it tries to read some nodes that don't
> exist, so xl will just print it out on stderr. This is the same
> behaviour as before though.

I think that's tolerable for 4.5 at least.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:29:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:29:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpE8F-0005Mz-3X; Fri, 14 Nov 2014 10:29:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpE8D-0005Mu-Es
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 10:29:33 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	B1/05-02712-C89D5645; Fri, 14 Nov 2014 10:29:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415960970!12528668!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29591 invoked from network); 14 Nov 2014 10:29:32 -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;
	14 Nov 2014 10:29:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="192797296"
Message-ID: <1415960966.21321.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Thomas Leonard <talex5@gmail.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:29:26 +0000
In-Reply-To: <CAG4opy-bY4HCmGik1y2DRLamXk=Tgj2J0cfqHjFRcs9goM1wqw@mail.gmail.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-2-git-send-email-talex5@gmail.com>
	<1413888616.23337.22.camel@citrix.com>
	<CAG4opy_ntDYAnN2m-YBvzfPX3CWiHFYZ-tx+u-e=vygntayy9Q@mail.gmail.com>
	<1414406079.31057.6.camel@citrix.com>
	<CAG4opy-bY4HCmGik1y2DRLamXk=Tgj2J0cfqHjFRcs9goM1wqw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 1/4] mini-os: arm: time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 16:29 +0000, Thomas Leonard wrote:
> On 27 October 2014 10:34, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Sun, 2014-10-26 at 09:51 +0000, Thomas Leonard wrote:
> >> On 21 October 2014 11:50, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Fri, 2014-10-03 at 10:20 +0100, Thomas Leonard wrote:
> >> >> Based on an initial patch by Karim Raslan.
> >> >>
> >> >> Signed-off-by: Karim Allah Ahmed <karim.allah.ahmed@gmail.com>
> >> >> Signed-off-by: Thomas Leonard <talex5@gmail.com>
> >> >
> >> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >> >
> >> >> +/* Wall-clock time is not currently available on ARM, so this is always zero for now:
> >> >> + * http://wiki.xenproject.org/wiki/Xen_ARM_TODO#Expose_Wallclock_time_to_guests
> >> >
> >> > I have some slightly hacky patches for this, I really should dust them
> >> > off and submit them...
> >> >
> >> >> +void block_domain(s_time_t until)
> >> >> +{
> >> >> +    uint64_t until_count = ns_to_ticks(until) + cntvct_at_init;
> >> >> +    ASSERT(irqs_disabled());
> >> >> +    if (read_virtual_count() < until_count)
> >> >> +    {
> >> >> +        set_vtimer_compare(until_count);
> >> >> +        __asm__ __volatile__("wfi");
> >> >> +        unset_vtimer_compare();
> >> >> +
> >> >> +        /* Give the IRQ handler a chance to handle whatever woke us up. */
> >> >> +        local_irq_enable();
> >> >> +        local_irq_disable();
> >> >> +    }
> >> >
> >> > Just wondering, is this not roughly equivalent to a wfi loop with
> >> > interrupts enabled?
> >>
> >> I'm not quite sure what you mean.
> >>
> >> If we enable interrupts before the wfi then I think the following could occur:
> >>
> >> 1. Application checks for work, finds none and calls block_domain.
> >> 2. block_domain enables interrupts.
> >> 3. An interrupt occurs.
> >> 4. The interrupt handler sets a flag indicating work to do.
> >> 5. wfi is called, putting the domain to sleep, even though there is work to do.
> >>
> >> Enabling IRQs after block_domain ensures we can't sleep while we have
> >> work to do.
> >
> > Ah, yes.
> 
> So, can this patch be applied as-is now?

We are now post-rc2 in the 4.5.0 release process, so the answer would be
"needs a release exception, but it's a feature so probably not" (and it
would have been a bit dubious towards the end of October too, which was
post rc1, and feature freeze was the end of September in any case).

However this is part of a new mini-os port which isn't even hooked into
the main build system yet (AFAICT), so in that sense it is utterly
harmless to apply. On the other hand there is a bunch more patches to
come which are needed to make the mini-os port actually useful, and I'm
not sure those are all utterly harmless e.g. to common or x86 code (as
in I've not gone looked at the diffstat for the remaining patches), so
in that sense there's no harm waiting for 4.6 development to open.

I defer to the release manager (Konrad, CCd) on this...



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:29:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:29:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpE8F-0005Mz-3X; Fri, 14 Nov 2014 10:29:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpE8D-0005Mu-Es
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 10:29:33 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	B1/05-02712-C89D5645; Fri, 14 Nov 2014 10:29:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415960970!12528668!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29591 invoked from network); 14 Nov 2014 10:29:32 -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;
	14 Nov 2014 10:29:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,384,1413244800"; d="scan'208";a="192797296"
Message-ID: <1415960966.21321.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Thomas Leonard <talex5@gmail.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:29:26 +0000
In-Reply-To: <CAG4opy-bY4HCmGik1y2DRLamXk=Tgj2J0cfqHjFRcs9goM1wqw@mail.gmail.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-2-git-send-email-talex5@gmail.com>
	<1413888616.23337.22.camel@citrix.com>
	<CAG4opy_ntDYAnN2m-YBvzfPX3CWiHFYZ-tx+u-e=vygntayy9Q@mail.gmail.com>
	<1414406079.31057.6.camel@citrix.com>
	<CAG4opy-bY4HCmGik1y2DRLamXk=Tgj2J0cfqHjFRcs9goM1wqw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 1/4] mini-os: arm: time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 16:29 +0000, Thomas Leonard wrote:
> On 27 October 2014 10:34, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Sun, 2014-10-26 at 09:51 +0000, Thomas Leonard wrote:
> >> On 21 October 2014 11:50, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Fri, 2014-10-03 at 10:20 +0100, Thomas Leonard wrote:
> >> >> Based on an initial patch by Karim Raslan.
> >> >>
> >> >> Signed-off-by: Karim Allah Ahmed <karim.allah.ahmed@gmail.com>
> >> >> Signed-off-by: Thomas Leonard <talex5@gmail.com>
> >> >
> >> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >> >
> >> >> +/* Wall-clock time is not currently available on ARM, so this is always zero for now:
> >> >> + * http://wiki.xenproject.org/wiki/Xen_ARM_TODO#Expose_Wallclock_time_to_guests
> >> >
> >> > I have some slightly hacky patches for this, I really should dust them
> >> > off and submit them...
> >> >
> >> >> +void block_domain(s_time_t until)
> >> >> +{
> >> >> +    uint64_t until_count = ns_to_ticks(until) + cntvct_at_init;
> >> >> +    ASSERT(irqs_disabled());
> >> >> +    if (read_virtual_count() < until_count)
> >> >> +    {
> >> >> +        set_vtimer_compare(until_count);
> >> >> +        __asm__ __volatile__("wfi");
> >> >> +        unset_vtimer_compare();
> >> >> +
> >> >> +        /* Give the IRQ handler a chance to handle whatever woke us up. */
> >> >> +        local_irq_enable();
> >> >> +        local_irq_disable();
> >> >> +    }
> >> >
> >> > Just wondering, is this not roughly equivalent to a wfi loop with
> >> > interrupts enabled?
> >>
> >> I'm not quite sure what you mean.
> >>
> >> If we enable interrupts before the wfi then I think the following could occur:
> >>
> >> 1. Application checks for work, finds none and calls block_domain.
> >> 2. block_domain enables interrupts.
> >> 3. An interrupt occurs.
> >> 4. The interrupt handler sets a flag indicating work to do.
> >> 5. wfi is called, putting the domain to sleep, even though there is work to do.
> >>
> >> Enabling IRQs after block_domain ensures we can't sleep while we have
> >> work to do.
> >
> > Ah, yes.
> 
> So, can this patch be applied as-is now?

We are now post-rc2 in the 4.5.0 release process, so the answer would be
"needs a release exception, but it's a feature so probably not" (and it
would have been a bit dubious towards the end of October too, which was
post rc1, and feature freeze was the end of September in any case).

However this is part of a new mini-os port which isn't even hooked into
the main build system yet (AFAICT), so in that sense it is utterly
harmless to apply. On the other hand there is a bunch more patches to
come which are needed to make the mini-os port actually useful, and I'm
not sure those are all utterly harmless e.g. to common or x86 code (as
in I've not gone looked at the diffstat for the remaining patches), so
in that sense there's no harm waiting for 4.6 development to open.

I defer to the release manager (Konrad, CCd) on this...



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:35:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEE2-0005jF-AT; Fri, 14 Nov 2014 10:35:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEE1-0005j7-ID
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:35:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C8/27-09842-4FAD5645; Fri, 14 Nov 2014 10:35:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415961294!12710197!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14062 invoked from network); 14 Nov 2014 10:34:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:34:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191333377"
Message-ID: <1415961291.21321.33.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:34:51 +0000
In-Reply-To: <20141110143530.GD3783@laptop.dumpdata.com>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>
	<545235EE.4040000@citrix.com>
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
	<1415096148.11486.11.camel@citrix.com> <545BEFC5.3010803@tycho.nsa.gov>
	<1415620919.28370.14.camel@citrix.com>
	<20141110143530.GD3783@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Emil Condrea <emilcondrea@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 09:35 -0500, Konrad Rzeszutek Wilk wrote:
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied with Daniel's ack.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:35:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEE6-0005ji-MF; Fri, 14 Nov 2014 10:35:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEE5-0005jY-RA
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:35:37 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	A0/26-02699-9FAD5645; Fri, 14 Nov 2014 10:35:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415961335!12567431!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1393 invoked from network); 14 Nov 2014 10:35:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:35:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191333618"
Message-ID: <1415961333.21321.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:35:33 +0000
In-Reply-To: <1415789784.25176.67.camel@citrix.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
	<1415789784.25176.67.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
 DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 10:56 +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 10:39 +0000, Wei Liu wrote:
> > ... otherwise when device add operation fails, the error message looks
> > like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
> > device", which is not very helpful.
> 
> Thanks.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Konrad, in v1 Wei said "This is a simple enough bug fix I think it
should just go in." and I agree.

> 
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  tools/libxl/libxl.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..de23fec 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
> >                                                                          \
> >          GCNEW(aodev);                                                   \
> >          libxl__prepare_ao_device(ao, aodev);                            \
> > +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
> >          aodev->callback = device_addrm_aocomplete;                      \
> >          aodev->update_json = true;                                      \
> >          libxl__device_##type##_add(egc, domid, type, aodev);            \
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 14 10:35:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEE2-0005jF-AT; Fri, 14 Nov 2014 10:35:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEE1-0005j7-ID
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:35:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C8/27-09842-4FAD5645; Fri, 14 Nov 2014 10:35:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415961294!12710197!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14062 invoked from network); 14 Nov 2014 10:34:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:34:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191333377"
Message-ID: <1415961291.21321.33.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:34:51 +0000
In-Reply-To: <20141110143530.GD3783@laptop.dumpdata.com>
References: <1414674330-2779-1-git-send-email-emilcondrea@gmail.com>
	<545235EE.4040000@citrix.com>
	<CAAULxKKYu3_z4E7q30Zx91jS2QeHfi2okGDrgj4j5s+p+Re77w@mail.gmail.com>
	<1415096148.11486.11.camel@citrix.com> <545BEFC5.3010803@tycho.nsa.gov>
	<1415620919.28370.14.camel@citrix.com>
	<20141110143530.GD3783@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Emil Condrea <emilcondrea@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] vTPM: Fix Atmel timeout bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-10 at 09:35 -0500, Konrad Rzeszutek Wilk wrote:
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied with Daniel's ack.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:35:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEE0-0005j3-Ul; Fri, 14 Nov 2014 10:35:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEDy-0005iy-PN
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:35:30 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F0/8C-02957-2FAD5645; Fri, 14 Nov 2014 10:35:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415961328!12516782!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9182 invoked from network); 14 Nov 2014 10:35:29 -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;
	14 Nov 2014 10:35:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191333595"
Message-ID: <1415961325.21321.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:35:25 +0000
In-Reply-To: <4B8ABDC6-FF30-43B7-897B-7435D7433324@oracle.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
	<1415790652.29592.3.camel@citrix.com>
	<20141112152207.GF6017@laptop.dumpdata.com>
	<20141113010121.GA3106@pengc-linux.bj.intel.com>
	<4B8ABDC6-FF30-43B7-897B-7435D7433324@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Chao Peng <chao.p.peng@linux.intel.com>,
	Dongxiao Xu <dongxiao.xu@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
 libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 20:08 -0500, Konrad Rzeszutek Wilk wrote:
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:35:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEE6-0005ji-MF; Fri, 14 Nov 2014 10:35:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEE5-0005jY-RA
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:35:37 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	A0/26-02699-9FAD5645; Fri, 14 Nov 2014 10:35:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415961335!12567431!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1393 invoked from network); 14 Nov 2014 10:35:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:35:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191333618"
Message-ID: <1415961333.21321.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:35:33 +0000
In-Reply-To: <1415789784.25176.67.camel@citrix.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
	<1415789784.25176.67.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
 DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 10:56 +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 10:39 +0000, Wei Liu wrote:
> > ... otherwise when device add operation fails, the error message looks
> > like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
> > device", which is not very helpful.
> 
> Thanks.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Konrad, in v1 Wei said "This is a simple enough bug fix I think it
should just go in." and I agree.

> 
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  tools/libxl/libxl.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..de23fec 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
> >                                                                          \
> >          GCNEW(aodev);                                                   \
> >          libxl__prepare_ao_device(ao, aodev);                            \
> > +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
> >          aodev->callback = device_addrm_aocomplete;                      \
> >          aodev->update_json = true;                                      \
> >          libxl__device_##type##_add(egc, domid, type, aodev);            \
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 14 10:35:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEE0-0005j3-Ul; Fri, 14 Nov 2014 10:35:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEDy-0005iy-PN
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:35:30 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F0/8C-02957-2FAD5645; Fri, 14 Nov 2014 10:35:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415961328!12516782!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9182 invoked from network); 14 Nov 2014 10:35:29 -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;
	14 Nov 2014 10:35:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191333595"
Message-ID: <1415961325.21321.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:35:25 +0000
In-Reply-To: <4B8ABDC6-FF30-43B7-897B-7435D7433324@oracle.com>
References: <1415790358-16787-1-git-send-email-wei.liu2@citrix.com>
	<1415790652.29592.3.camel@citrix.com>
	<20141112152207.GF6017@laptop.dumpdata.com>
	<20141113010121.GA3106@pengc-linux.bj.intel.com>
	<4B8ABDC6-FF30-43B7-897B-7435D7433324@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Chao Peng <chao.p.peng@linux.intel.com>,
	Dongxiao Xu <dongxiao.xu@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: correct test condition on
 libxl_domain_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 20:08 -0500, Konrad Rzeszutek Wilk wrote:
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:36:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEEg-0005s2-4Z; Fri, 14 Nov 2014 10:36:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEEe-0005rX-T4
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:36:13 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	9C/34-25727-C1BD5645; Fri, 14 Nov 2014 10:36:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415961370!11421389!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25799 invoked from network); 14 Nov 2014 10:36:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:36:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192799090"
Message-ID: <1415961345.21321.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:35:45 +0000
In-Reply-To: <20141112185600.GB4898@laptop.dumpdata.com>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
	<20141112152111.GE6017@laptop.dumpdata.com>
	<20141112170657.GA15386@aepfle.de>
	<20141112171659.GA32634@laptop.dumpdata.com>
	<20141112172346.GC17230@aepfle.de>
	<20141112185600.GB4898@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 13:56 -0500, Konrad Rzeszutek Wilk wrote:

> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:36:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEEg-0005s2-4Z; Fri, 14 Nov 2014 10:36:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEEe-0005rX-T4
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:36:13 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	9C/34-25727-C1BD5645; Fri, 14 Nov 2014 10:36:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415961370!11421389!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25799 invoked from network); 14 Nov 2014 10:36:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:36:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192799090"
Message-ID: <1415961345.21321.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:35:45 +0000
In-Reply-To: <20141112185600.GB4898@laptop.dumpdata.com>
References: <1413269723-28599-1-git-send-email-olaf@aepfle.de>
	<20141112110640.GA26748@aepfle.de>
	<1415790726.29592.4.camel@citrix.com>
	<20141112152111.GE6017@laptop.dumpdata.com>
	<20141112170657.GA15386@aepfle.de>
	<20141112171659.GA32634@laptop.dumpdata.com>
	<20141112172346.GC17230@aepfle.de>
	<20141112185600.GB4898@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] tools/hotplug: use configure
 --sysconfdir result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 13:56 -0500, Konrad Rzeszutek Wilk wrote:

> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:38:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEGU-00067R-7k; Fri, 14 Nov 2014 10:38:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XpEGS-00067I-RH
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:38:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8D/B5-24532-C8BD5645; Fri, 14 Nov 2014 10:38:04 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415961483!12752292!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25531 invoked from network); 14 Nov 2014 10:38:03 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:38:03 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so2200055wib.13
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 02:38:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=B1dPZVhGmIYldRX4qxeEB2ci0VYC4HtIxxyeozwW9os=;
	b=mJZ7i8oL/OjEp/2+cbWseHNrmxTBubFQ8kX4JjtrpDOp93gQTYhTzNnLQDIAJHO/lX
	4ge1cneL/rXuE/G6/KLAcGZB+rtlEQpgjvoUyoKfc48PhHxZrngBE5bA8Lcr2MSK02Ut
	t+V8Z0dAw1F1gasCwS8kCyPDV2vbvmXd5oPvjropdFqeHyB3t/m2hx5ApYV5+eeiphFe
	6d/jR3Mhuv+jk1Bz1fVqFWXkEXX/rcZOBHodEtb2/TViq4kAndNsBHslNS8kIMGDjmuk
	geR9RQjyrPWN0k473X1OmeZPnvlpgD6GVBruF2Ko/gkNgL7GqOaJkqm6DHQv0ykeVln6
	iDyA==
X-Gm-Message-State: ALoCoQnm59Sp2kCCVGwZtbmo5hBpMytdfi/SVW8feWNNWytvQlt1a/sgZj5O5aR9iDsfr8+mrwj+
X-Received: by 10.194.92.116 with SMTP id cl20mr12695104wjb.71.1415961483260; 
	Fri, 14 Nov 2014 02:38:03 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	w10sm39108502wje.10.2014.11.14.02.38.01 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 14 Nov 2014 02:38:02 -0800 (PST)
Message-ID: <5465DB93.6090506@m2r.biz>
Date: Fri, 14 Nov 2014 11:38:11 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Hu, Robert" <robert.hu@intel.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>, Wei Liu <wei.liu2@citrix.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>	<54632F72.7020509@m2r.biz>
	<1415958176.21321.18.camel@citrix.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 14/11/2014 11:14, Hu, Robert ha scritto:
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org
>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
>> Sent: Friday, November 14, 2014 5:43 PM
>> To: Fabio Fantoni; Wei Liu
>> Cc: Hu, Robert; JBeulich@suse.com; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
>>
>> I've not seen an individual thread on this one, so replying here.
>>
>> On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:
>>
>>>> 6. Networking is unavailable after save&restore Windows guest
>>>>     http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
>>> Should be the same problem I reported 1 year ago or more and still
>>> present, the workaround is use fixed mac address in domUs xl cfg :(
>>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
>>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
>> Wei, shouldn't your json migration thing have solved this? (this being
>> the preservation of a vif's mac addr over migration?)
>>
>> Robert, all reports of toolstack bugs should include a full set of logs.
>> See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
>> advice on reporting bugs as well as lists of specific things which
>> should be included.
> Thanks Ian. Will rerun this test case in RC2 testing, and if still there, append the full logs then.

I not tried without fixed mac in latest weeks until now, and the problem 
seems solved.
dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid leaf 
with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, and 
qemu 2.2 from spice git:
https://github.com/Fantu/Xen/commits/rebase/m2r-staging
I tried windows 7 domU with latest winpv drivers from git.
Sorry if I not tried before in recently builds.

>> Ian.
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:38:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEGU-00067R-7k; Fri, 14 Nov 2014 10:38:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XpEGS-00067I-RH
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:38:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8D/B5-24532-C8BD5645; Fri, 14 Nov 2014 10:38:04 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415961483!12752292!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25531 invoked from network); 14 Nov 2014 10:38:03 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:38:03 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so2200055wib.13
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 02:38:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=B1dPZVhGmIYldRX4qxeEB2ci0VYC4HtIxxyeozwW9os=;
	b=mJZ7i8oL/OjEp/2+cbWseHNrmxTBubFQ8kX4JjtrpDOp93gQTYhTzNnLQDIAJHO/lX
	4ge1cneL/rXuE/G6/KLAcGZB+rtlEQpgjvoUyoKfc48PhHxZrngBE5bA8Lcr2MSK02Ut
	t+V8Z0dAw1F1gasCwS8kCyPDV2vbvmXd5oPvjropdFqeHyB3t/m2hx5ApYV5+eeiphFe
	6d/jR3Mhuv+jk1Bz1fVqFWXkEXX/rcZOBHodEtb2/TViq4kAndNsBHslNS8kIMGDjmuk
	geR9RQjyrPWN0k473X1OmeZPnvlpgD6GVBruF2Ko/gkNgL7GqOaJkqm6DHQv0ykeVln6
	iDyA==
X-Gm-Message-State: ALoCoQnm59Sp2kCCVGwZtbmo5hBpMytdfi/SVW8feWNNWytvQlt1a/sgZj5O5aR9iDsfr8+mrwj+
X-Received: by 10.194.92.116 with SMTP id cl20mr12695104wjb.71.1415961483260; 
	Fri, 14 Nov 2014 02:38:03 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	w10sm39108502wje.10.2014.11.14.02.38.01 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 14 Nov 2014 02:38:02 -0800 (PST)
Message-ID: <5465DB93.6090506@m2r.biz>
Date: Fri, 14 Nov 2014 11:38:11 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Hu, Robert" <robert.hu@intel.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>, Wei Liu <wei.liu2@citrix.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>	<54632F72.7020509@m2r.biz>
	<1415958176.21321.18.camel@citrix.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 14/11/2014 11:14, Hu, Robert ha scritto:
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org
>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
>> Sent: Friday, November 14, 2014 5:43 PM
>> To: Fabio Fantoni; Wei Liu
>> Cc: Hu, Robert; JBeulich@suse.com; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
>>
>> I've not seen an individual thread on this one, so replying here.
>>
>> On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:
>>
>>>> 6. Networking is unavailable after save&restore Windows guest
>>>>     http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
>>> Should be the same problem I reported 1 year ago or more and still
>>> present, the workaround is use fixed mac address in domUs xl cfg :(
>>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
>>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
>> Wei, shouldn't your json migration thing have solved this? (this being
>> the preservation of a vif's mac addr over migration?)
>>
>> Robert, all reports of toolstack bugs should include a full set of logs.
>> See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
>> advice on reporting bugs as well as lists of specific things which
>> should be included.
> Thanks Ian. Will rerun this test case in RC2 testing, and if still there, append the full logs then.

I not tried without fixed mac in latest weeks until now, and the problem 
seems solved.
dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid leaf 
with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, and 
qemu 2.2 from spice git:
https://github.com/Fantu/Xen/commits/rebase/m2r-staging
I tried windows 7 domU with latest winpv drivers from git.
Sorry if I not tried before in recently builds.

>> Ian.
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:40:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEIW-0006R0-Ug; Fri, 14 Nov 2014 10:40: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 1XpEIV-0006Qo-0l
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:40:11 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	05/DA-14727-A0CD5645; Fri, 14 Nov 2014 10:40:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415961607!11416040!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 313 invoked from network); 14 Nov 2014 10:40:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:40:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192799775"
Message-ID: <1415961604.21321.40.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 10:40:04 +0000
In-Reply-To: <1415961333.21321.35.camel@citrix.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
	<1415789784.25176.67.camel@citrix.com>
	<1415961333.21321.35.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
 DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 10:35 +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 10:56 +0000, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 10:39 +0000, Wei Liu wrote:
> > > ... otherwise when device add operation fails, the error message looks
> > > like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
> > > device", which is not very helpful.
> > 
> > Thanks.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Konrad, in v1 Wei said "This is a simple enough bug fix I think it
> should just go in." and I agree.

Nevermind I've just seen the ack which was in the wrong folder here. 

> 
> > 
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > ---
> > >  tools/libxl/libxl.c |    1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > index f7961f6..de23fec 100644
> > > --- a/tools/libxl/libxl.c
> > > +++ b/tools/libxl/libxl.c
> > > @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
> > >                                                                          \
> > >          GCNEW(aodev);                                                   \
> > >          libxl__prepare_ao_device(ao, aodev);                            \
> > > +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
> > >          aodev->callback = device_addrm_aocomplete;                      \
> > >          aodev->update_json = true;                                      \
> > >          libxl__device_##type##_add(egc, domid, type, aodev);            \
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:40:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEIW-0006R0-Ug; Fri, 14 Nov 2014 10:40: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 1XpEIV-0006Qo-0l
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:40:11 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	05/DA-14727-A0CD5645; Fri, 14 Nov 2014 10:40:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1415961607!11416040!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 313 invoked from network); 14 Nov 2014 10:40:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:40:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192799775"
Message-ID: <1415961604.21321.40.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 10:40:04 +0000
In-Reply-To: <1415961333.21321.35.camel@citrix.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
	<1415789784.25176.67.camel@citrix.com>
	<1415961333.21321.35.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
 DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 10:35 +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 10:56 +0000, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 10:39 +0000, Wei Liu wrote:
> > > ... otherwise when device add operation fails, the error message looks
> > > like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
> > > device", which is not very helpful.
> > 
> > Thanks.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Konrad, in v1 Wei said "This is a simple enough bug fix I think it
> should just go in." and I agree.

Nevermind I've just seen the ack which was in the wrong folder here. 

> 
> > 
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > ---
> > >  tools/libxl/libxl.c |    1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > index f7961f6..de23fec 100644
> > > --- a/tools/libxl/libxl.c
> > > +++ b/tools/libxl/libxl.c
> > > @@ -4164,6 +4164,7 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
> > >                                                                          \
> > >          GCNEW(aodev);                                                   \
> > >          libxl__prepare_ao_device(ao, aodev);                            \
> > > +        aodev->action = LIBXL__DEVICE_ACTION_ADD;                       \
> > >          aodev->callback = device_addrm_aocomplete;                      \
> > >          aodev->update_json = true;                                      \
> > >          libxl__device_##type##_add(egc, domid, type, aodev);            \
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:53:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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 1XpEV5-0007F1-Ho; Fri, 14 Nov 2014 10:53:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEV4-0007Eu-3s
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:53:10 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	07/63-23865-51FD5645; Fri, 14 Nov 2014 10:53:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415962385!11408922!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29269 invoked from network); 14 Nov 2014 10:53:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:53:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191336324"
Message-ID: <1415962372.7113.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 10:52:52 +0000
In-Reply-To: <1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
 ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> Continue when libxl_retrieve_domain_configuration encounters
> ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
> configuration pulled from xenstore.  In this case
> ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
> error happens along the way.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Zhigang Wang <zhigang.x.wang@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..f54e0ea 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -6521,6 +6521,7 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
>      GC_INIT(ctx);
>      int rc;
>      libxl__domain_userdata_lock *lock = NULL;
> +    bool json_empty = false;
>  
>      CTX_LOCK;
>  
> @@ -6531,11 +6532,12 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
>      }
>  
>      rc = libxl__get_domain_configuration(gc, domid, d_config);
> -    if (rc) {
> +    if (rc && rc != ERROR_JSON_CONFIG_EMPTY) {
>          LOG(ERROR, "fail to get domain configuration for domain %d", domid);
>          rc = ERROR_FAIL;
>          goto out;
>      }
> +    if (rc == ERROR_JSON_CONFIG_EMPTY) json_empty = true;
>  
>      /* Domain name */
>      {
> @@ -6692,6 +6694,8 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
>  
>  #undef MERGE
>  
> +    rc = json_empty ? ERROR_JSON_CONFIG_EMPTY : 0;
> +
>  out:
>      if (lock) libxl__unlock_domain_userdata(lock);
>      CTX_UNLOCK;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:53:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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 1XpEV5-0007F1-Ho; Fri, 14 Nov 2014 10:53:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEV4-0007Eu-3s
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:53:10 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	07/63-23865-51FD5645; Fri, 14 Nov 2014 10:53:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415962385!11408922!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29269 invoked from network); 14 Nov 2014 10:53:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:53:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191336324"
Message-ID: <1415962372.7113.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 10:52:52 +0000
In-Reply-To: <1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
 ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> Continue when libxl_retrieve_domain_configuration encounters
> ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
> configuration pulled from xenstore.  In this case
> ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
> error happens along the way.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Zhigang Wang <zhigang.x.wang@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..f54e0ea 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -6521,6 +6521,7 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
>      GC_INIT(ctx);
>      int rc;
>      libxl__domain_userdata_lock *lock = NULL;
> +    bool json_empty = false;
>  
>      CTX_LOCK;
>  
> @@ -6531,11 +6532,12 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
>      }
>  
>      rc = libxl__get_domain_configuration(gc, domid, d_config);
> -    if (rc) {
> +    if (rc && rc != ERROR_JSON_CONFIG_EMPTY) {
>          LOG(ERROR, "fail to get domain configuration for domain %d", domid);
>          rc = ERROR_FAIL;
>          goto out;
>      }
> +    if (rc == ERROR_JSON_CONFIG_EMPTY) json_empty = true;
>  
>      /* Domain name */
>      {
> @@ -6692,6 +6694,8 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
>  
>  #undef MERGE
>  
> +    rc = json_empty ? ERROR_JSON_CONFIG_EMPTY : 0;
> +
>  out:
>      if (lock) libxl__unlock_domain_userdata(lock);
>      CTX_UNLOCK;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:53:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:53:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEVi-0007Hz-V0; Fri, 14 Nov 2014 10:53:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEVh-0007Hj-RS
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:53:49 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	FD/8A-02698-D3FD5645; Fri, 14 Nov 2014 10:53:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415962427!12549446!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31715 invoked from network); 14 Nov 2014 10:53:48 -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;
	14 Nov 2014 10:53:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192802192"
Message-ID: <1415962425.7113.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 10:53:45 +0000
In-Reply-To: <1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> Unconditionally print out the partial configuration.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/xl_cmdimpl.c |    6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3c9f146..396e06c 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3388,7 +3388,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
>  {
>      libxl_domain_config d_config;
>  
> -    int i, rc;
> +    int i;
>  
>      yajl_gen hand = NULL;
>      yajl_gen_status s;
> @@ -3410,9 +3410,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
>  
>      for (i = 0; i < nb_domain; i++) {
>          libxl_domain_config_init(&d_config);
> -        rc = libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> -        if (rc)
> -            continue;
> +        libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);

Should't this continue to skip cases where rc is not in {0,
ERROR_EMPTY_JSON}?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:53:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10:53:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEVi-0007Hz-V0; Fri, 14 Nov 2014 10:53:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEVh-0007Hj-RS
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:53:49 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	FD/8A-02698-D3FD5645; Fri, 14 Nov 2014 10:53:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415962427!12549446!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31715 invoked from network); 14 Nov 2014 10:53:48 -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;
	14 Nov 2014 10:53:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192802192"
Message-ID: <1415962425.7113.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 10:53:45 +0000
In-Reply-To: <1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> Unconditionally print out the partial configuration.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/xl_cmdimpl.c |    6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3c9f146..396e06c 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3388,7 +3388,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
>  {
>      libxl_domain_config d_config;
>  
> -    int i, rc;
> +    int i;
>  
>      yajl_gen hand = NULL;
>      yajl_gen_status s;
> @@ -3410,9 +3410,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
>  
>      for (i = 0; i < nb_domain; i++) {
>          libxl_domain_config_init(&d_config);
> -        rc = libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> -        if (rc)
> -            continue;
> +        libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);

Should't this continue to skip cases where rc is not in {0,
ERROR_EMPTY_JSON}?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:55:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEXX-0007Ru-MR; Fri, 14 Nov 2014 10:55: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 1XpEXV-0007Rl-Ld
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:55:41 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	5E/3E-14727-CAFD5645; Fri, 14 Nov 2014 10:55:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415962538!5968463!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9668 invoked from network); 14 Nov 2014 10:55:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:55:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192802597"
Message-ID: <1415962535.7113.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 10:55:35 +0000
In-Reply-To: <1415962372.7113.2.camel@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
	<1415962372.7113.2.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
 ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 10:52 +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > Continue when libxl_retrieve_domain_configuration encounters
> > ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
> > configuration pulled from xenstore.  In this case
> > ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
> > error happens along the way.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

On second thoughts, I think this really needs an update to libxl.h to
describe the semantics of this function, i.e. to what extent the output
is valid for various error codes, especially ERROR_JSON_CONFIG_EMPTY.

> 
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  tools/libxl/libxl.c |    6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..f54e0ea 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -6521,6 +6521,7 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
> >      GC_INIT(ctx);
> >      int rc;
> >      libxl__domain_userdata_lock *lock = NULL;
> > +    bool json_empty = false;
> >  
> >      CTX_LOCK;
> >  
> > @@ -6531,11 +6532,12 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
> >      }
> >  
> >      rc = libxl__get_domain_configuration(gc, domid, d_config);
> > -    if (rc) {
> > +    if (rc && rc != ERROR_JSON_CONFIG_EMPTY) {
> >          LOG(ERROR, "fail to get domain configuration for domain %d", domid);
> >          rc = ERROR_FAIL;
> >          goto out;
> >      }
> > +    if (rc == ERROR_JSON_CONFIG_EMPTY) json_empty = true;
> >  
> >      /* Domain name */
> >      {
> > @@ -6692,6 +6694,8 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
> >  
> >  #undef MERGE
> >  
> > +    rc = json_empty ? ERROR_JSON_CONFIG_EMPTY : 0;
> > +
> >  out:
> >      if (lock) libxl__unlock_domain_userdata(lock);
> >      CTX_UNLOCK;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 14 10:55:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEXX-0007Ru-MR; Fri, 14 Nov 2014 10:55: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 1XpEXV-0007Rl-Ld
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:55:41 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	5E/3E-14727-CAFD5645; Fri, 14 Nov 2014 10:55:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415962538!5968463!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9668 invoked from network); 14 Nov 2014 10:55:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:55:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192802597"
Message-ID: <1415962535.7113.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 10:55:35 +0000
In-Reply-To: <1415962372.7113.2.camel@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
	<1415962372.7113.2.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
 ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 10:52 +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > Continue when libxl_retrieve_domain_configuration encounters
> > ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
> > configuration pulled from xenstore.  In this case
> > ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
> > error happens along the way.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

On second thoughts, I think this really needs an update to libxl.h to
describe the semantics of this function, i.e. to what extent the output
is valid for various error codes, especially ERROR_JSON_CONFIG_EMPTY.

> 
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  tools/libxl/libxl.c |    6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..f54e0ea 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -6521,6 +6521,7 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
> >      GC_INIT(ctx);
> >      int rc;
> >      libxl__domain_userdata_lock *lock = NULL;
> > +    bool json_empty = false;
> >  
> >      CTX_LOCK;
> >  
> > @@ -6531,11 +6532,12 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
> >      }
> >  
> >      rc = libxl__get_domain_configuration(gc, domid, d_config);
> > -    if (rc) {
> > +    if (rc && rc != ERROR_JSON_CONFIG_EMPTY) {
> >          LOG(ERROR, "fail to get domain configuration for domain %d", domid);
> >          rc = ERROR_FAIL;
> >          goto out;
> >      }
> > +    if (rc == ERROR_JSON_CONFIG_EMPTY) json_empty = true;
> >  
> >      /* Domain name */
> >      {
> > @@ -6692,6 +6694,8 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
> >  
> >  #undef MERGE
> >  
> > +    rc = json_empty ? ERROR_JSON_CONFIG_EMPTY : 0;
> > +
> >  out:
> >      if (lock) libxl__unlock_domain_userdata(lock);
> >      CTX_UNLOCK;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 14 10:57:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEYu-0007aX-6B; Fri, 14 Nov 2014 10:57:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEYt-0007aL-34
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:57:07 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	88/3C-02712-200E5645; Fri, 14 Nov 2014 10:57:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415962624!12559437!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8456 invoked from network); 14 Nov 2014 10:57:05 -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;
	14 Nov 2014 10:57:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191337227"
Message-ID: <1415962621.7113.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:57:01 +0000
In-Reply-To: <20141112151624.GB6017@laptop.dumpdata.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
	<1415789784.25176.67.camel@citrix.com>
	<20141112151624.GB6017@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
 DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 10:16 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 10:56:24AM +0000, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 10:39 +0000, Wei Liu wrote:
> > > ... otherwise when device add operation fails, the error message looks
> > > like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
> > > device", which is not very helpful.
> > 
> > Thanks.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, thanks.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:57:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEYu-0007aX-6B; Fri, 14 Nov 2014 10:57:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEYt-0007aL-34
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:57:07 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	88/3C-02712-200E5645; Fri, 14 Nov 2014 10:57:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415962624!12559437!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8456 invoked from network); 14 Nov 2014 10:57:05 -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;
	14 Nov 2014 10:57:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191337227"
Message-ID: <1415962621.7113.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 10:57:01 +0000
In-Reply-To: <20141112151624.GB6017@laptop.dumpdata.com>
References: <1415788771-16563-1-git-send-email-wei.liu2@citrix.com>
	<1415789784.25176.67.camel@citrix.com>
	<20141112151624.GB6017@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: add missing action in
 DEFINE_DEVICE_ADD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-12 at 10:16 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 10:56:24AM +0000, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 10:39 +0000, Wei Liu wrote:
> > > ... otherwise when device add operation fails, the error message looks
> > > like "libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to (null)
> > > device", which is not very helpful.
> > 
> > Thanks.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, thanks.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:57:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEZT-0007es-JM; Fri, 14 Nov 2014 10:57:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1XpEZS-0007ee-HX
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:57:42 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	F0/6B-29352-520E5645; Fri, 14 Nov 2014 10:57:41 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415962657!8026434!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18384 invoked from network); 14 Nov 2014 10:57:40 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:57:40 -0000
Received: from 172.24.2.119 (EHLO SZXEMA403-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AXC60881; Fri, 14 Nov 2014 18:57:35 +0800 (CST)
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.174]) by
	SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id
	14.03.0158.001; Fri, 14 Nov 2014 18:57:24 +0800
From: Liuyongan <liuyongan@huawei.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: ioreq process conflict when  EVTCHNOP_bind_interdomain
	hypercall and vcpu pio occur concurrently
Thread-Index: Ac/9rVq1IRZuUMpZQbCRp6vd6elF1ACSf8Rg
Date: Fri, 14 Nov 2014 10:57:23 +0000
Message-ID: <E4ABEE53CC34664FA3F0BD8AEAF50A1958CCA617@SZXEMA512-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.177.20.146]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020206.5465E020.0057, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.174,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: b1e334c70884c4b8543c0dcb13a637e3
Cc: Qianhuibin <qianhuibin@huawei.com>, zhangyuexi <zhangyuexi@huawei.com>,
	"Shanhaitao \(Tony\)" <shanhaitao1@huawei.com>,
	Fanhenglong <fanhenglong@huawei.com>,
	Huangzhichao <huangzhichao@huawei.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] ioreq process conflict when
 EVTCHNOP_bind_interdomain hypercall and vcpu pio occur concurrently
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Qemu calls xc_evtchn_bind_interdomain to allocate an free port for each vcpu, 
it will receive empty io-request triggered by xen. I say it empty as the ioreq in
shared page is not filled. So qemu can simply skip the first ioreq of each vcpu by
a pervcpu flag.

You should not skip the first one by check ioreq->state , as the shared page may
be modified by real vm trigged io req, so ioreq->state becomes REQUEST READY.

Any bugs here?

Liuyongan
2014-11-14


> -----Original Message-----
> From: Liuyongan
> Sent: Tuesday, November 11, 2014 8:45 PM
> To: 'xen-devel@lists.xen.org'
> Cc: 'JBeulich@suse.com'; Shanhaitao (Tony); Huangzhichao; zhangyuexi;
> Fanhenglong; Qianhuibin
> Subject: ioreq process conflict when EVTCHNOP_bind_interdomain hypercall
> and vcpu pio occur concurrently
> 
> I wonder if it is necessary for xen to trigger the event channel pending when
> the port related a vcpu port io.
> 
> Suppose a scenario as follows:
> 
> 1)  Qemu make a hypercall using codes:
>      for (i = 0; i < smp_cpus; i++) {
>         rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
> 
> xen_vcpu_eport(state->shared_page, i));
>         if (rc == -1) {
>             fprintf(stderr, "bind interdomain ioctl(shared_page) error %d\n",
> errno);
>             return -1;
>         }
>         state->ioreq_local_port[i] = rc;
>         ...
>      }
> 
> 2)  Xen do_event_channel_op allocate a free port and call evtchn_set_pending
> to trigger a evtchn event.
> 
> 3)  Qemu enters main_loop and begin the evtchn event (pio event).
> 
> 4)  The vcpus of a vm begin to trigger real pio exit,  and this ioreq_t will
> conflict with the one triggered in step 2.
> 
> This will certainly cause failures of real port io.
> 
> Does anyone here have any suggestions?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 10:57:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 10: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 1XpEZT-0007es-JM; Fri, 14 Nov 2014 10:57:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1XpEZS-0007ee-HX
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 10:57:42 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	F0/6B-29352-520E5645; Fri, 14 Nov 2014 10:57:41 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415962657!8026434!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiA4NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18384 invoked from network); 14 Nov 2014 10:57:40 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 10:57:40 -0000
Received: from 172.24.2.119 (EHLO SZXEMA403-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AXC60881; Fri, 14 Nov 2014 18:57:35 +0800 (CST)
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.174]) by
	SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id
	14.03.0158.001; Fri, 14 Nov 2014 18:57:24 +0800
From: Liuyongan <liuyongan@huawei.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: ioreq process conflict when  EVTCHNOP_bind_interdomain
	hypercall and vcpu pio occur concurrently
Thread-Index: Ac/9rVq1IRZuUMpZQbCRp6vd6elF1ACSf8Rg
Date: Fri, 14 Nov 2014 10:57:23 +0000
Message-ID: <E4ABEE53CC34664FA3F0BD8AEAF50A1958CCA617@SZXEMA512-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.177.20.146]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020206.5465E020.0057, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.174,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: b1e334c70884c4b8543c0dcb13a637e3
Cc: Qianhuibin <qianhuibin@huawei.com>, zhangyuexi <zhangyuexi@huawei.com>,
	"Shanhaitao \(Tony\)" <shanhaitao1@huawei.com>,
	Fanhenglong <fanhenglong@huawei.com>,
	Huangzhichao <huangzhichao@huawei.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] ioreq process conflict when
 EVTCHNOP_bind_interdomain hypercall and vcpu pio occur concurrently
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Qemu calls xc_evtchn_bind_interdomain to allocate an free port for each vcpu, 
it will receive empty io-request triggered by xen. I say it empty as the ioreq in
shared page is not filled. So qemu can simply skip the first ioreq of each vcpu by
a pervcpu flag.

You should not skip the first one by check ioreq->state , as the shared page may
be modified by real vm trigged io req, so ioreq->state becomes REQUEST READY.

Any bugs here?

Liuyongan
2014-11-14


> -----Original Message-----
> From: Liuyongan
> Sent: Tuesday, November 11, 2014 8:45 PM
> To: 'xen-devel@lists.xen.org'
> Cc: 'JBeulich@suse.com'; Shanhaitao (Tony); Huangzhichao; zhangyuexi;
> Fanhenglong; Qianhuibin
> Subject: ioreq process conflict when EVTCHNOP_bind_interdomain hypercall
> and vcpu pio occur concurrently
> 
> I wonder if it is necessary for xen to trigger the event channel pending when
> the port related a vcpu port io.
> 
> Suppose a scenario as follows:
> 
> 1)  Qemu make a hypercall using codes:
>      for (i = 0; i < smp_cpus; i++) {
>         rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
> 
> xen_vcpu_eport(state->shared_page, i));
>         if (rc == -1) {
>             fprintf(stderr, "bind interdomain ioctl(shared_page) error %d\n",
> errno);
>             return -1;
>         }
>         state->ioreq_local_port[i] = rc;
>         ...
>      }
> 
> 2)  Xen do_event_channel_op allocate a free port and call evtchn_set_pending
> to trigger a evtchn event.
> 
> 3)  Qemu enters main_loop and begin the evtchn event (pio event).
> 
> 4)  The vcpus of a vm begin to trigger real pio exit,  and this ioreq_t will
> conflict with the one triggered in step 2.
> 
> This will certainly cause failures of real port io.
> 
> Does anyone here have any suggestions?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:04:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:04:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEfV-00089l-F1; Fri, 14 Nov 2014 11:03:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XpEfT-00089g-QY
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:03:55 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	B6/BB-25727-A91E5645; Fri, 14 Nov 2014 11:03:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415963029!11375334!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2738 invoked from network); 14 Nov 2014 11:03:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:03:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192804688"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:03:31 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpEf4-0006HA-Iw;
	Fri, 14 Nov 2014 11:03:30 +0000
Date: Fri, 14 Nov 2014 11:03:30 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141114110330.GA31422@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415962425.7113.3.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415962425.7113.3.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, zhigang.x.wang@oracle.com,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 10:53:45AM +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > Unconditionally print out the partial configuration.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  tools/libxl/xl_cmdimpl.c |    6 ++----
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 3c9f146..396e06c 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -3388,7 +3388,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
> >  {
> >      libxl_domain_config d_config;
> >  
> > -    int i, rc;
> > +    int i;
> >  
> >      yajl_gen hand = NULL;
> >      yajl_gen_status s;
> > @@ -3410,9 +3410,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
> >  
> >      for (i = 0; i < nb_domain; i++) {
> >          libxl_domain_config_init(&d_config);
> > -        rc = libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> > -        if (rc)
> > -            continue;
> > +        libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> 
> Should't this continue to skip cases where rc is not in {0,
> ERROR_EMPTY_JSON}?
> 

Conceptually speaking, non-zero return value means this d_config is
partially filled. ERROR_JSON_CONFIG_EMPTY is as good / bad as any other
return values.

In this "xl list -l" case, We're interested in two things: to state the
fact that this domain exists and to print out the config.

Domain's existence is confirmed at this point, and we should print out
that partially filled d_config. How much information is filled in is
another question though.  Only printing out d_config when {0,
ERROR_JSON_CONFIG_EMPTY} makes "xl list -l" inconsistent with "xl list".

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:04:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:04:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEfV-00089l-F1; Fri, 14 Nov 2014 11:03:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XpEfT-00089g-QY
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:03:55 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	B6/BB-25727-A91E5645; Fri, 14 Nov 2014 11:03:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415963029!11375334!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2738 invoked from network); 14 Nov 2014 11:03:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:03:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192804688"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:03:31 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpEf4-0006HA-Iw;
	Fri, 14 Nov 2014 11:03:30 +0000
Date: Fri, 14 Nov 2014 11:03:30 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141114110330.GA31422@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415962425.7113.3.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415962425.7113.3.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, zhigang.x.wang@oracle.com,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 10:53:45AM +0000, Ian Campbell wrote:
> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > Unconditionally print out the partial configuration.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  tools/libxl/xl_cmdimpl.c |    6 ++----
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 3c9f146..396e06c 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -3388,7 +3388,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
> >  {
> >      libxl_domain_config d_config;
> >  
> > -    int i, rc;
> > +    int i;
> >  
> >      yajl_gen hand = NULL;
> >      yajl_gen_status s;
> > @@ -3410,9 +3410,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
> >  
> >      for (i = 0; i < nb_domain; i++) {
> >          libxl_domain_config_init(&d_config);
> > -        rc = libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> > -        if (rc)
> > -            continue;
> > +        libxl_retrieve_domain_configuration(ctx, info[i].domid, &d_config);
> 
> Should't this continue to skip cases where rc is not in {0,
> ERROR_EMPTY_JSON}?
> 

Conceptually speaking, non-zero return value means this d_config is
partially filled. ERROR_JSON_CONFIG_EMPTY is as good / bad as any other
return values.

In this "xl list -l" case, We're interested in two things: to state the
fact that this domain exists and to print out the config.

Domain's existence is confirmed at this point, and we should print out
that partially filled d_config. How much information is filled in is
another question though.  Only printing out d_config when {0,
ERROR_JSON_CONFIG_EMPTY} makes "xl list -l" inconsistent with "xl list".

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:04:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:04:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEfw-0008Ba-Rh; Fri, 14 Nov 2014 11:04:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XpEfv-0008BP-L5
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 11:04:23 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	9B/AB-19763-5B1E5645; Fri, 14 Nov 2014 11:04:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415963055!8028651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17498 invoked from network); 14 Nov 2014 11:04:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:04:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191339052"
Message-ID: <5465E15E.4010109@citrix.com>
Date: Fri, 14 Nov 2014 11:02:54 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
References: <5465E0E10200007800047902@mail.emea.novell.com>
In-Reply-To: <5465E0E10200007800047902@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] kexec-ed kernel possibly needing low 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 14/11/14 10:00, Jan Beulich wrote:
> David,
> 
> we're being approached with the situation where a disk driver in the
> kexec-ed kernel needs memory below 4G in order to perform DMA
> (e.g. for the swiotlb to be set up). Linux not so long ago invented a
> two area approach, which doesn't fit with the current single
> KEXEC_RANGE_MA_CRASH area obtainable via
> KEXEC_CMD_kexec_get_range.
> 
> I see multiple options
> - do no change at all; the user can deal with this by explicitly
>   specifying an area below 4G via "crashkernel="

This is what we do.

> - add KEXEC_RANGE_MA_CRASH_LOW

If you choose this option, it would be preferable to support N (which
might be 2) arbitrary crash regions rather than specifying that one
region is always low memory.  I would suggest combining this with a way
to specify the bounds of each region.

e.g., crashkernel=32M@<4G,128M

I wouldn't go this route unless you actually need a large crash region
that would use up too much low memory otherwise.

> - when not asked for a specific address, always allocate the (single)
>   area below 4G if there is enough space

I don't think the default location should change.  A user might have
specified  a large crash region that might use up most of low memory.

> - provide a means to request allocating the (single) area below 4G
>   (or perhaps more generically below a certain boundary) without
>   requiring an exact address to be specified

This sounds ok.

> Do you have any preference here, or do you see other viable
> alternatives?

My preference would be option 1 since it already works, then option 4.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:04:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:04:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEfw-0008Ba-Rh; Fri, 14 Nov 2014 11:04:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XpEfv-0008BP-L5
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 11:04:23 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	9B/AB-19763-5B1E5645; Fri, 14 Nov 2014 11:04:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1415963055!8028651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17498 invoked from network); 14 Nov 2014 11:04:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:04:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191339052"
Message-ID: <5465E15E.4010109@citrix.com>
Date: Fri, 14 Nov 2014 11:02:54 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
References: <5465E0E10200007800047902@mail.emea.novell.com>
In-Reply-To: <5465E0E10200007800047902@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] kexec-ed kernel possibly needing low 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 14/11/14 10:00, Jan Beulich wrote:
> David,
> 
> we're being approached with the situation where a disk driver in the
> kexec-ed kernel needs memory below 4G in order to perform DMA
> (e.g. for the swiotlb to be set up). Linux not so long ago invented a
> two area approach, which doesn't fit with the current single
> KEXEC_RANGE_MA_CRASH area obtainable via
> KEXEC_CMD_kexec_get_range.
> 
> I see multiple options
> - do no change at all; the user can deal with this by explicitly
>   specifying an area below 4G via "crashkernel="

This is what we do.

> - add KEXEC_RANGE_MA_CRASH_LOW

If you choose this option, it would be preferable to support N (which
might be 2) arbitrary crash regions rather than specifying that one
region is always low memory.  I would suggest combining this with a way
to specify the bounds of each region.

e.g., crashkernel=32M@<4G,128M

I wouldn't go this route unless you actually need a large crash region
that would use up too much low memory otherwise.

> - when not asked for a specific address, always allocate the (single)
>   area below 4G if there is enough space

I don't think the default location should change.  A user might have
specified  a large crash region that might use up most of low memory.

> - provide a means to request allocating the (single) area below 4G
>   (or perhaps more generically below a certain boundary) without
>   requiring an exact address to be specified

This sounds ok.

> Do you have any preference here, or do you see other viable
> alternatives?

My preference would be option 1 since it already works, then option 4.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:06:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11: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 1XpEhd-0008N6-Ge; Fri, 14 Nov 2014 11:06:09 +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 1XpEhc-0008N1-Jm
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:06:08 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	87/15-09284-F12E5645; Fri, 14 Nov 2014 11:06:07 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415963165!11356305!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30324 invoked from network); 14 Nov 2014 11:06:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:06:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191339471"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:05:00 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpEgV-0006Il-SD;
	Fri, 14 Nov 2014 11:04:59 +0000
Date: Fri, 14 Nov 2014 11:04:59 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141114110459.GB31422@zion.uk.xensource.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Fabio Fantoni <fabio.fantoni@m2r.biz>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 10:14:32AM +0000, Hu, Robert wrote:
> 
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> > Sent: Friday, November 14, 2014 5:43 PM
> > To: Fabio Fantoni; Wei Liu
> > Cc: Hu, Robert; JBeulich@suse.com; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> > 
> > I've not seen an individual thread on this one, so replying here.
> > 
> > On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:
> > 
> > > > 6. Networking is unavailable after save&restore Windows guest
> > > >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> > >
> > > Should be the same problem I reported 1 year ago or more and still
> > > present, the workaround is use fixed mac address in domUs xl cfg :(
> > > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> > > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
> > 
> > Wei, shouldn't your json migration thing have solved this? (this being
> > the preservation of a vif's mac addr over migration?)
> > 
> > Robert, all reports of toolstack bugs should include a full set of logs.
> > See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
> > advice on reporting bugs as well as lists of specific things which
> > should be included.
> Thanks Ian. Will rerun this test case in RC2 testing, and if still there, append the full logs then.

Those patches were applied before RC1, so you can paste those logs now.
;-)

> > 
> > Ian.
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:06:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11: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 1XpEhd-0008N6-Ge; Fri, 14 Nov 2014 11:06:09 +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 1XpEhc-0008N1-Jm
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:06:08 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	87/15-09284-F12E5645; Fri, 14 Nov 2014 11:06:07 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1415963165!11356305!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30324 invoked from network); 14 Nov 2014 11:06:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:06:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191339471"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:05:00 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpEgV-0006Il-SD;
	Fri, 14 Nov 2014 11:04:59 +0000
Date: Fri, 14 Nov 2014 11:04:59 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141114110459.GB31422@zion.uk.xensource.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Fabio Fantoni <fabio.fantoni@m2r.biz>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 10:14:32AM +0000, Hu, Robert wrote:
> 
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> > Sent: Friday, November 14, 2014 5:43 PM
> > To: Fabio Fantoni; Wei Liu
> > Cc: Hu, Robert; JBeulich@suse.com; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> > 
> > I've not seen an individual thread on this one, so replying here.
> > 
> > On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:
> > 
> > > > 6. Networking is unavailable after save&restore Windows guest
> > > >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> > >
> > > Should be the same problem I reported 1 year ago or more and still
> > > present, the workaround is use fixed mac address in domUs xl cfg :(
> > > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> > > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
> > 
> > Wei, shouldn't your json migration thing have solved this? (this being
> > the preservation of a vif's mac addr over migration?)
> > 
> > Robert, all reports of toolstack bugs should include a full set of logs.
> > See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
> > advice on reporting bugs as well as lists of specific things which
> > should be included.
> Thanks Ian. Will rerun this test case in RC2 testing, and if still there, append the full logs then.

Those patches were applied before RC1, so you can paste those logs now.
;-)

> > 
> > Ian.
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:11:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11: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 1XpEme-0000A2-E3; Fri, 14 Nov 2014 11:11:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XpEmd-00009x-47
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:11:19 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	98/8A-29352-653E5645; Fri, 14 Nov 2014 11:11:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415963476!11358059!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31902 invoked from network); 14 Nov 2014 11:11:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:11:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192806779"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:10:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpEmB-0006Ps-Bh;
	Fri, 14 Nov 2014 11:10:51 +0000
Date: Fri, 14 Nov 2014 11:10:51 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141114111051.GC31422@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
	<1415962372.7113.2.camel@citrix.com>
	<1415962535.7113.4.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415962535.7113.4.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, zhigang.x.wang@oracle.com,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
 ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 10:55:35AM +0000, Ian Campbell wrote:
> On Fri, 2014-11-14 at 10:52 +0000, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > > Continue when libxl_retrieve_domain_configuration encounters
> > > ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
> > > configuration pulled from xenstore.  In this case
> > > ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
> > > error happens along the way.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> On second thoughts, I think this really needs an update to libxl.h to
> describe the semantics of this function, i.e. to what extent the output
> is valid for various error codes, especially ERROR_JSON_CONFIG_EMPTY.
> 

Any non-zero return code means the output is invalid (as in "Is this
output valid to rebuild a domain?").

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:11:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11: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 1XpEme-0000A2-E3; Fri, 14 Nov 2014 11:11:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XpEmd-00009x-47
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:11:19 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	98/8A-29352-653E5645; Fri, 14 Nov 2014 11:11:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415963476!11358059!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31902 invoked from network); 14 Nov 2014 11:11:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:11:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192806779"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:10:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpEmB-0006Ps-Bh;
	Fri, 14 Nov 2014 11:10:51 +0000
Date: Fri, 14 Nov 2014 11:10:51 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141114111051.GC31422@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
	<1415962372.7113.2.camel@citrix.com>
	<1415962535.7113.4.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415962535.7113.4.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, zhigang.x.wang@oracle.com,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
 ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 10:55:35AM +0000, Ian Campbell wrote:
> On Fri, 2014-11-14 at 10:52 +0000, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > > Continue when libxl_retrieve_domain_configuration encounters
> > > ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
> > > configuration pulled from xenstore.  In this case
> > > ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
> > > error happens along the way.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> On second thoughts, I think this really needs an update to libxl.h to
> describe the semantics of this function, i.e. to what extent the output
> is valid for various error codes, especially ERROR_JSON_CONFIG_EMPTY.
> 

Any non-zero return code means the output is invalid (as in "Is this
output valid to rebuild a domain?").

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:13:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEoF-0000Ud-TT; Fri, 14 Nov 2014 11:12:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEoF-0000UW-76
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:12:59 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	FF/37-02697-AB3E5645; Fri, 14 Nov 2014 11:12:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415963576!11405545!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18058 invoked from network); 14 Nov 2014 11:12:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:12:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192807145"
Message-ID: <1415963574.7113.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>, Ian Jackson
	<ian.jackson@citrix.com>
Date: Fri, 14 Nov 2014 11:12:54 +0000
In-Reply-To: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.
> 
> Also while we're at it, normalize init and dispose of
> libxl_device_disk structures.  This means calling init and dispose in
> the actual functions where they are declared.
> 
> This in turn means changing parse_disk_config_multistring() to not
> call libxl_device_disk_init.  And that in turn means changes to
> callers of parse_disk_config().
> 
> It also means removing libxl_device_disk_init() from
> libxl.c:libxl_vdev_to_device_disk().  This is only called from
> xl_cmdimpl.c.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
> CC: Ian Campbell <ian.campbell@citrix.com>
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Konrad Wilk <konrad.wilk@oracle.com>
> 
> Release justification: This is a bug fix.  It's a fairly minor one,
> but it's also a very simple one.
> 
> v2:
>  - Restructure functions to make sure init and dispose are properly
>  called.

Sadly this bit has somewhat reduced the truth of the second half of your
release justification, since the patch is a fair bit more subtle though.
Although IMHO it hasn't invalidated the case for taking the patch for
4.5 (modulo comments below).

> ---
>  tools/libxl/libxl.c      |  2 --
>  tools/libxl/xl_cmdimpl.c | 28 +++++++++++++++++++++-------
>  2 files changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..d9c4ce7 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2611,8 +2611,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid,
>      if (devid < 0)
>          return ERROR_INVAL;
>  
> -    libxl_device_disk_init(disk);

_init functions are idempotent, so this is harmless, I think. Existing
callers (including things which aren't xl) might be relying on it.
Outside of a freeze period that might be acceptable (those callers are
buggy) but since you are asking for a freeze exception I think this may
be going a step too far in cleaning things up.

In terms of other callers you've missed
tools/ocaml/libs/xl/xenlight_stubs.c (which appears buggy to me) in
tree, plus whatever use e.g. libvirt makes of it.

> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3c9f146..25af715 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -485,8 +485,6 @@ static void parse_disk_config_multistring(XLU_Config **config,
>  {
>      int e;
>  
> -    libxl_device_disk_init(disk);

Likewise here, although to a lesser extent since this is xl not libxl.
>  
> @@ -6378,13 +6382,17 @@ int main_blockattach(int argc, char **argv)
>          printf("disk: %s\n", json);
>          free(json);
>          if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
> -        return 0;

You should set rc = 0 here rather than initing it at declaration to
catch error paths which don't set the result. (we aren't very consistent
about this in the code today so I'm only mentioning it because other
changes seem to be needed, if that turns out not to be the case and
there's no need for v3 then this shouldn't block acceptance)

> +        goto out;

I'm not 100% convinced by the use of the goto out error handling style
for a success path, but it's probably better than duplicating the exit
path or adding !dryrun checks to all the following operations. Ian,
since you recently posted updated coding style for things around this,
what do you think?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:13:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEoF-0000Ud-TT; Fri, 14 Nov 2014 11:12:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEoF-0000UW-76
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:12:59 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	FF/37-02697-AB3E5645; Fri, 14 Nov 2014 11:12:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415963576!11405545!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18058 invoked from network); 14 Nov 2014 11:12:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:12:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192807145"
Message-ID: <1415963574.7113.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>, Ian Jackson
	<ian.jackson@citrix.com>
Date: Fri, 14 Nov 2014 11:12:54 +0000
In-Reply-To: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.
> 
> Also while we're at it, normalize init and dispose of
> libxl_device_disk structures.  This means calling init and dispose in
> the actual functions where they are declared.
> 
> This in turn means changing parse_disk_config_multistring() to not
> call libxl_device_disk_init.  And that in turn means changes to
> callers of parse_disk_config().
> 
> It also means removing libxl_device_disk_init() from
> libxl.c:libxl_vdev_to_device_disk().  This is only called from
> xl_cmdimpl.c.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
> CC: Ian Campbell <ian.campbell@citrix.com>
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Konrad Wilk <konrad.wilk@oracle.com>
> 
> Release justification: This is a bug fix.  It's a fairly minor one,
> but it's also a very simple one.
> 
> v2:
>  - Restructure functions to make sure init and dispose are properly
>  called.

Sadly this bit has somewhat reduced the truth of the second half of your
release justification, since the patch is a fair bit more subtle though.
Although IMHO it hasn't invalidated the case for taking the patch for
4.5 (modulo comments below).

> ---
>  tools/libxl/libxl.c      |  2 --
>  tools/libxl/xl_cmdimpl.c | 28 +++++++++++++++++++++-------
>  2 files changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..d9c4ce7 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2611,8 +2611,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid,
>      if (devid < 0)
>          return ERROR_INVAL;
>  
> -    libxl_device_disk_init(disk);

_init functions are idempotent, so this is harmless, I think. Existing
callers (including things which aren't xl) might be relying on it.
Outside of a freeze period that might be acceptable (those callers are
buggy) but since you are asking for a freeze exception I think this may
be going a step too far in cleaning things up.

In terms of other callers you've missed
tools/ocaml/libs/xl/xenlight_stubs.c (which appears buggy to me) in
tree, plus whatever use e.g. libvirt makes of it.

> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3c9f146..25af715 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -485,8 +485,6 @@ static void parse_disk_config_multistring(XLU_Config **config,
>  {
>      int e;
>  
> -    libxl_device_disk_init(disk);

Likewise here, although to a lesser extent since this is xl not libxl.
>  
> @@ -6378,13 +6382,17 @@ int main_blockattach(int argc, char **argv)
>          printf("disk: %s\n", json);
>          free(json);
>          if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
> -        return 0;

You should set rc = 0 here rather than initing it at declaration to
catch error paths which don't set the result. (we aren't very consistent
about this in the code today so I'm only mentioning it because other
changes seem to be needed, if that turns out not to be the case and
there's no need for v3 then this shouldn't block acceptance)

> +        goto out;

I'm not 100% convinced by the use of the goto out error handling style
for a success path, but it's probably better than duplicating the exit
path or adding !dryrun checks to all the following operations. Ian,
since you recently posted updated coding style for things around this,
what do you think?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:16:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEri-0000fN-Hg; Fri, 14 Nov 2014 11:16:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XpErg-0000fI-OV
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:16:32 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E4/4A-09284-094E5645; Fri, 14 Nov 2014 11:16:32 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415963790!11416686!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6771 invoked from network); 14 Nov 2014 11:16:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:16:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192807758"
Message-ID: <5465E483.7080802@citrix.com>
Date: Fri, 14 Nov 2014 11:16:19 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>	<1415684626-18590-3-git-send-email-jgross@suse.com>	<20141112214506.GA5922@laptop.dumpdata.com>	<54644E48.3040506@suse.com>	<20141113195605.GA13039@laptop.dumpdata.com>
	<54658ABF.5050708@suse.com>
In-Reply-To: <54658ABF.5050708@suse.com>
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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 14/11/14 04:53, Juergen Gross wrote:
> 
> Using BUG() instead would make the code less complex. Do you really
> think xen_update_mem_tables() would ever fail in a sane system?
> 
> - set_phys_to_machine() would fail only on a memory shortage. Just
>   going on without adding more memory wouldn't lead to a healthy system,
>   I think.
> - The hypervisor calls would fail only in case of parameter errors.
>   This should never happen, so dying seems to be the correct reaction.
> 
> David, what do you think?

BUG() sounds fine.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:16:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEri-0000fN-Hg; Fri, 14 Nov 2014 11:16:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XpErg-0000fI-OV
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:16:32 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E4/4A-09284-094E5645; Fri, 14 Nov 2014 11:16:32 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415963790!11416686!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6771 invoked from network); 14 Nov 2014 11:16:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:16:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192807758"
Message-ID: <5465E483.7080802@citrix.com>
Date: Fri, 14 Nov 2014 11:16:19 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>	<1415684626-18590-3-git-send-email-jgross@suse.com>	<20141112214506.GA5922@laptop.dumpdata.com>	<54644E48.3040506@suse.com>	<20141113195605.GA13039@laptop.dumpdata.com>
	<54658ABF.5050708@suse.com>
In-Reply-To: <54658ABF.5050708@suse.com>
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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 14/11/14 04:53, Juergen Gross wrote:
> 
> Using BUG() instead would make the code less complex. Do you really
> think xen_update_mem_tables() would ever fail in a sane system?
> 
> - set_phys_to_machine() would fail only on a memory shortage. Just
>   going on without adding more memory wouldn't lead to a healthy system,
>   I think.
> - The hypervisor calls would fail only in case of parameter errors.
>   This should never happen, so dying seems to be the correct reaction.
> 
> David, what do you think?

BUG() sounds fine.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:20:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11: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 1XpEv4-0000mF-4w; Fri, 14 Nov 2014 11:20:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEv2-0000m8-CK
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:20:00 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	51/98-02696-F55E5645; Fri, 14 Nov 2014 11:19:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415963997!12566278!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24794 invoked from network); 14 Nov 2014 11:19:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:19:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192808381"
Message-ID: <1415963996.7113.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 11:19:56 +0000
In-Reply-To: <20141114111051.GC31422@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
	<1415962372.7113.2.camel@citrix.com>
	<1415962535.7113.4.camel@citrix.com>
	<20141114111051.GC31422@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
 ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 11:10 +0000, Wei Liu wrote:
> On Fri, Nov 14, 2014 at 10:55:35AM +0000, Ian Campbell wrote:
> > On Fri, 2014-11-14 at 10:52 +0000, Ian Campbell wrote:
> > > On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > > > Continue when libxl_retrieve_domain_configuration encounters
> > > > ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
> > > > configuration pulled from xenstore.  In this case
> > > > ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
> > > > error happens along the way.
> > > > 
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> > > 
> > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > On second thoughts, I think this really needs an update to libxl.h to
> > describe the semantics of this function, i.e. to what extent the output
> > is valid for various error codes, especially ERROR_JSON_CONFIG_EMPTY.
> > 
> 
> Any non-zero return code means the output is invalid (as in "Is this
> output valid to rebuild a domain?").

But your second patch prints it as if it is at least somewhat
meaningful, if not entirely valid. According to what you just said it
shouldn't do so.

You effectively have three return states now: Fully valid, domain exists
but it's configuration is unsure or somehow incomplete (~= JSON EMPTY),
some sort of error occurred.

It might even be a good idea to have some new externally visible error
code for the middle state, since JSON_EMPTY may not be the only reason
for being in that state (at least in theory).

Anyway, since this is all more subtle than the existing 0 is good,
non-zero is completely bad it should be written down.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:20:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11: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 1XpEv4-0000mF-4w; Fri, 14 Nov 2014 11:20:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpEv2-0000m8-CK
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:20:00 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	51/98-02696-F55E5645; Fri, 14 Nov 2014 11:19:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415963997!12566278!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24794 invoked from network); 14 Nov 2014 11:19:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:19:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192808381"
Message-ID: <1415963996.7113.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 14 Nov 2014 11:19:56 +0000
In-Reply-To: <20141114111051.GC31422@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
	<1415962372.7113.2.camel@citrix.com>
	<1415962535.7113.4.camel@citrix.com>
	<20141114111051.GC31422@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: zhigang.x.wang@oracle.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
 ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 11:10 +0000, Wei Liu wrote:
> On Fri, Nov 14, 2014 at 10:55:35AM +0000, Ian Campbell wrote:
> > On Fri, 2014-11-14 at 10:52 +0000, Ian Campbell wrote:
> > > On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > > > Continue when libxl_retrieve_domain_configuration encounters
> > > > ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
> > > > configuration pulled from xenstore.  In this case
> > > > ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
> > > > error happens along the way.
> > > > 
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> > > 
> > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > On second thoughts, I think this really needs an update to libxl.h to
> > describe the semantics of this function, i.e. to what extent the output
> > is valid for various error codes, especially ERROR_JSON_CONFIG_EMPTY.
> > 
> 
> Any non-zero return code means the output is invalid (as in "Is this
> output valid to rebuild a domain?").

But your second patch prints it as if it is at least somewhat
meaningful, if not entirely valid. According to what you just said it
shouldn't do so.

You effectively have three return states now: Fully valid, domain exists
but it's configuration is unsure or somehow incomplete (~= JSON EMPTY),
some sort of error occurred.

It might even be a good idea to have some new externally visible error
code for the middle state, since JSON_EMPTY may not be the only reason
for being in that state (at least in theory).

Anyway, since this is all more subtle than the existing 0 is good,
non-zero is completely bad it should be written down.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:25:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:25:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEzp-0001Ae-UY; Fri, 14 Nov 2014 11:24:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XpEzo-0001AZ-L0
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:24:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5A/0C-09842-886E5645; Fri, 14 Nov 2014 11:24:56 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415964294!5454497!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32713 invoked from network); 14 Nov 2014 11:24:54 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:24:54 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so2342750wiw.10
	for <xen-devel@lists.xensource.com>;
	Fri, 14 Nov 2014 03:24:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=Hf9Uxkooiz7/r5wXdge4uWd+qhhoDbhyO/QOVB8aaSo=;
	b=QLh/OZDcnADg2IBFeb7C3t5oymMypsEgtCdN+Zz05LcKvPRSL9394v4Zm8goXj1oqU
	8K2BkTIMHvs+2Fi1cb+1c0GuftK8cSj4XyK1YKEUE/VpESWf9rB8c2ZrWUsqgRsjRRVm
	tBiUKDy+6aJ1Znz2VqfpuNNjH3YPcarwIDxV6UjwfDCgd8YeTH2wLGYHZQEDBiPH0eh0
	EVMujKsKFp58EpzVP/PZ4hpqdemaTOmcZGe4XzVW+sceuZqqP+FYytZ73HcsOwYrqLHw
	xHYaen4OkfMtdnjAFAWW5LvMg1OerXfc04mvYbob0QKVBfgKDYESHlD0xMiCy91iCY3X
	hWRQ==
X-Gm-Message-State: ALoCoQkAmk1ZTL2wALUUrFfUbk8VK8AIyVsurUOHAn3I7bVIybMBoZAFtsA7n9KsoNOcDg8dkfZa
X-Received: by 10.180.11.194 with SMTP id s2mr6670328wib.45.1415964294155;
	Fri, 14 Nov 2014 03:24:54 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	dm10sm3029182wib.18.2014.11.14.03.24.52 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 14 Nov 2014 03:24:53 -0800 (PST)
Message-ID: <5465E68E.1000304@m2r.biz>
Date: Fri, 14 Nov 2014 12:25:02 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
Subject: [Xen-devel] qemu 2.2 crash on linux hvm domU (full backtrace
	included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid leaf 
with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, and 
qemu 2.2 from spice git (spice/next commit 
e779fa0a715530311e6f59fc8adb0f6eca914a89):
https://github.com/Fantu/Xen/commits/rebase/m2r-staging

Qemu crash on fedora 20 lxde (with software updates of some days ago) 
boot with this backtrace:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
> addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> 73          eax = env->regs[R_EAX];
> (gdb) bt full
> #0  0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
> addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>         s = 0x555556440a20
>         cs = 0x0
>         cpu = 0x0
>         __func__ = "vmport_ioport_read"
>         env = 0x8250
>         command = 0 '\000'
>         eax = 0
> #1  0x0000555555655b9c in memory_region_read_accessor 
> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0, 
> mask=4294967295)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>         tmp = 0
> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0, 
> value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
>     access=0x555555655b3a <memory_region_read_accessor>, 
> mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>         access_mask = 4294967295
>         access_size = 4
>         i = 0
> #3  0x0000555555658cc1 in memory_region_dispatch_read1 
> (mr=0x555556440aa8, addr=0, size=4) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>         data = 0
> #4  0x0000555555658d89 in memory_region_dispatch_read 
> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> No locals.
> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0, 
> pval=0x7fffffffd998, size=4) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> No locals.
> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840, 
> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4, is_write=false)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>         l = 4
>         ptr = 0x0
>         val = 7964229952888770560
>         addr1 = 0
>         mr = 0x555556440aa8
>         error = false
> #7  0x000055555560a173 in address_space_read (as=0x555555eae840, 
> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
> No locals.
> #8  0x000055555564fac7 in cpu_inl (addr=22104) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>         buf = "\377\377\377\377"
>         val = 21845
> #9  0x000055555567084b in do_inp (addr=22104, size=4) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> No locals.
> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>         i = 0
> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590, 
> req=0x7ffff7ff3000) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> ---Type <return> to continue, or q <return> to quit---
> No locals.
> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>         state = 0x5555563c1590
>         req = 0x7ffff7ff3000
> #13 0x000055555596d874 in qemu_iohandler_poll (pollfds=0x555556388a30, 
> ret=1) at iohandler.c:143
>         revents = 1
>         pioh = 0x5555563f3c90
>         ioh = 0x555556515f80
> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at 
> main-loop.c:495
>         ret = 1
>         timeout = 4294967295
>         timeout_ns = 3418165
> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>         nonblocking = false
>         last_io = 1
> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038, 
> envp=0x7fffffffe230) at vl.c:4400
>         i = 128
>         snapshot = 0
>         linux_boot = 0
>         initrd_filename = 0x0
>         kernel_filename = 0x0
>         kernel_cmdline = 0x555555a485c6 ""
>         boot_order = 0x5555563864e0 "dc"
>         ds = 0x5555564c71b0
>         cyls = 0
>         heads = 0
>         secs = 0
>         translation = 0
>         hda_opts = 0x0
>         opts = 0x555556386430
>         machine_opts = 0x555556388090
>         icount_opts = 0x0
>         olist = 0x555555e56da0
>         optind = 62
>         optarg = 0x7fffffffe914 
> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>         loadvm = 0x0
>         machine_class = 0x55555637c5c0
>         cpu_model = 0x0
>         vga_model = 0x0
>         qtest_chrdev = 0x0
> ---Type <return> to continue, or q <return> to quit---
>         qtest_log = 0x0
>         pid_file = 0x0
>         incoming = 0x0
>         show_vnc_port = 0
>         defconfig = true
>         userconfig = true
>         log_mask = 0x0
>         log_file = 0x0
>         mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>, 
> realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39 
> <free_and_trace>, calloc = 0,
>           try_malloc = 0, try_realloc = 0}
>         trace_events = 0x0
>         trace_file = 0x0
>         default_ram_size = 134217728
>         maxram_size = 2013265920
>         ram_slots = 0
>         vmstate_dump_file = 0x0
>         main_loop_err = 0x0
>         __func__ = "main"


> xl -vvv create /etc/xen/FEDORA19.cfg
> Parsing config from /etc/xen/FEDORA19.cfg
> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660: 
> create: how=(nil) callback=(nil) poller=0xac2af0
> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk 
> vdev=hda spec.backend=unknown
> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda, 
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk 
> vdev=hda, using backend qdisk
> libxl: debug: libxl_create.c:935:initiate_domain_create: running 
> bootloader
> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV 
> domain, skipping bootloader
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac32f8: deregister unregistered
> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
> xc: detail:   Loader:   0000000000100000->000000000036b324
> xc: detail:   Modules:  0000000000000000->0000000000000000
> xc: detail:   TOTAL:    0000000000000000->0000000078000000
> xc: detail:   ENTRY:    0000000000100000
> xc: detail: PHYSICAL MEMORY ALLOCATION:
> xc: detail:   4KB PAGES: 0x0000000000000200
> xc: detail:   2MB PAGES: 0x00000000000003bf
> xc: detail:   1GB PAGES: 0x0000000000000000
> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 -> 0x7f1f975012b0
> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk 
> vdev=hda spec.backend=qdisk
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac4ad0: deregister unregistered
> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning 
> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> /usr/lib/xen/bin/qemu-gdb
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -xen-domid
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> chardev=libxl-cmd,mode=control
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -nodefaults
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   FEDORA
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -spice
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> spicevmc,id=vdagent,name=vdagent
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> virtserialport,chardev=vdagent,name=com.redhat.spice.0
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> qxl-vga,vram_size_mb=64,ram_size_mb=64
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   order=dc
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> spicevmc,name=usbredir,id=usbrc1
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> usb-redir,chardev=usbrc1,id=usbrc1
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> spicevmc,name=usbredir,id=usbrc2
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> usb-redir,chardev=usbrc2,id=usbrc2
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> spicevmc,name=usbredir,id=usbrc3
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> usb-redir,chardev=usbrc3,id=usbrc3
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> spicevmc,name=usbredir,id=usbrc4
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> usb-redir,chardev=usbrc4,id=usbrc4
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -soundhw
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   2,maxcpus=2
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -netdev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -machine
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -drive
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
> register slotnum=3
> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660: 
> inprogress: poller=0xac2af0, flags=i
> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
> wpath=/local/domain/0/device-model/9/state token=3/0: event 
> epath=/local/domain/0/device-model/9/state
> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
> wpath=/local/domain/0/device-model/9/state token=3/0: event 
> epath=/local/domain/0/device-model/9/state
> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
> deregister slotnum=3
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac3558: deregister unregistered
> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to 
> /var/run/xen/qmp-libxl-9
> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>     "execute": "qmp_capabilities",
>     "id": 1
> }
> '
> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>     "execute": "query-chardev",
>     "id": 2
> }
> '
> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>     "execute": "query-vnc",
>     "id": 3
> }
> '
> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
> register slotnum=3
> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
> epath=/local/domain/0/backend/vif/9/0/state
> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend 
> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting state 1
> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
> epath=/local/domain/0/backend/vif/9/0/state
> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend 
> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
> deregister slotnum=3
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac8368: deregister unregistered
> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
> script: /etc/xen/scripts/vif-bridge online
> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to 
> execute: /etc/xen/scripts/vif-bridge online
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac83f0: deregister unregistered
> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
> script: /etc/xen/scripts/vif-bridge add
> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to 
> execute: /etc/xen/scripts/vif-bridge add
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac83f0: deregister unregistered
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac83f0: deregister unregistered
> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao 
> 0xac2660: progress report: ignored
> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660: 
> complete, rc=0
> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660: destroy
> xc: debug: hypercall buffer: total allocations:704 total releases:704
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
> xc: debug: hypercall buffer: cache current size:4
> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
> xc: debug: hypercall buffer: total allocations:0 total releases:0
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:0
> xc: debug: hypercall buffer: cache current size:0
> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0

xl dmesg
> (d9) HVM Loader
> (d9) Detected Xen v4.5.0-rc
> (d9) Xenbus rings @0xfeffc000, event channel 1
> (d9) System requested SeaBIOS
> (d9) CPU speed is 2660 MHz
> (d9) Relocating guest memory for lowmem MMIO space disabled
> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
> (d9) PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
> (d9) PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
> (d9) PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
> (d9) PCI-ISA link 3 routed to IRQ5
> (d9) pci dev 01:3 INTA->IRQ10
> (d9) pci dev 02:0 INTA->IRQ11
> (d9) pci dev 03:0 INTA->IRQ5
> (d9) pci dev 04:0 INTA->IRQ5
> (d9) pci dev 05:0 INTA->IRQ10
> (d9) pci dev 06:0 INTA->IRQ11
> (d9) pci dev 1d:0 INTA->IRQ10
> (d9) pci dev 1d:1 INTB->IRQ11
> (d9) pci dev 1d:2 INTC->IRQ5
> (d9) pci dev 1d:7 INTD->IRQ5
> (d9) No RAM in high memory; setting high_mem resource base to 100000000
> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
> (d9) Multiprocessor initialisation:
> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
> (d9) Testing HVM environment:
> (d9)  - REP INSB across page boundaries ... passed
> (d9)  - GS base MSRs and SWAPGS ... passed
> (d9) Passed 2 of 2 tests
> (d9) Writing SMBIOS tables ...
> (d9) Loading SeaBIOS ...
> (d9) Creating MP tables ...
> (d9) Loading ACPI ...
> (d9) S3 disabled
> (d9) S4 disabled
> (d9) vm86 TSS at fc00a100
> (d9) BIOS map:
> (d9)  10000-100d3: Scratch space
> (d9)  c0000-fffff: Main BIOS
> (d9) E820 table:
> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> (d9) Invoking SeaBIOS ...
> (d9) SeaBIOS (version 
> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> (d9)
> (d9) Found Xen hypervisor signature at 40000000
> (d9) Running on QEMU (i440fx)
> (d9) xen: copy e820...
> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
> (d9) CPU Mhz=2660
> (d9) Found 13 PCI devices (max PCI bus is 00)
> (d9) Allocated Xen hypercall page at 77fff000
> (d9) Detected Xen v4.5.0-rc
> (d9) xen: copy BIOS tables...
> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
> (d9) Using pmtimer, ioport 0xb008
> (d9) Scan for VGA option rom
> (d9) Running option rom at c000:0003
> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
> (d9) pmm call arg1=0
> (d9) Turning on vga text mode console
> (d9) SeaBIOS (version 
> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
> (d9) Found 0 lpt ports
> (d9) Found 0 serial ports
> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> (d9) UHCI init on dev 00:1d.0 (io=c240)
> (d9) UHCI init on dev 00:1d.1 (io=c260)
> (d9) UHCI init on dev 00:1d.2 (io=c280)
> (d9) PS2 keyboard initialized
> (d9) All threads complete.
> (d9) Scan for option roms
> (d9) Running option rom at c980:0003
> (d9) pmm call arg1=1
> (d9) pmm call arg1=0
> (d9) pmm call arg1=1
> (d9) pmm call arg1=0
> (d9) Searching bootorder for: /pci@i0cf8/*@6
> (d9)
> (d9) Press F12 for boot menu.
> (d9)
> (d9) Searching bootorder for: HALT
> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba 
> LCHS=1024/255/63 s=20480000
> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
> (d9) Returned 258048 bytes of ZoneHigh
> (d9) e820 map has 6 items:
> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
> (d9) enter handle_19:
> (d9)   NULL
> (d9) Booting from Hard Disk...
> (d9) Booting from 0000:7c00
> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0

domU's xl cfg:
> name='FEDORA'
> builder="hvm"
> device_model_override="/usr/lib/xen/bin/qemu-gdb"
> memory=2048
> vcpus=2
> acpi_s3=0
> acpi_s4=0
> vif=['bridge=xenbr0']
> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
> boot='dc'
> device_model_version='qemu-xen'
> vnc=0
> keymap="it"
> vga="qxl"
> spice=1
> spicehost='0.0.0.0'
> spiceport=6005
> spicedisable_ticketing=1
> spicevdagent=1
> spice_clipboard_sharing=0
> spiceusbredirection=4
> soundhw="hda"

I tested also with stdvga instead of qxl vga but qemu crash always on 
fedora boot with same error.

If you need more informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:25:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:25:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpEzp-0001Ae-UY; Fri, 14 Nov 2014 11:24:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XpEzo-0001AZ-L0
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:24:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5A/0C-09842-886E5645; Fri, 14 Nov 2014 11:24:56 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415964294!5454497!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32713 invoked from network); 14 Nov 2014 11:24:54 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:24:54 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so2342750wiw.10
	for <xen-devel@lists.xensource.com>;
	Fri, 14 Nov 2014 03:24:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=Hf9Uxkooiz7/r5wXdge4uWd+qhhoDbhyO/QOVB8aaSo=;
	b=QLh/OZDcnADg2IBFeb7C3t5oymMypsEgtCdN+Zz05LcKvPRSL9394v4Zm8goXj1oqU
	8K2BkTIMHvs+2Fi1cb+1c0GuftK8cSj4XyK1YKEUE/VpESWf9rB8c2ZrWUsqgRsjRRVm
	tBiUKDy+6aJ1Znz2VqfpuNNjH3YPcarwIDxV6UjwfDCgd8YeTH2wLGYHZQEDBiPH0eh0
	EVMujKsKFp58EpzVP/PZ4hpqdemaTOmcZGe4XzVW+sceuZqqP+FYytZ73HcsOwYrqLHw
	xHYaen4OkfMtdnjAFAWW5LvMg1OerXfc04mvYbob0QKVBfgKDYESHlD0xMiCy91iCY3X
	hWRQ==
X-Gm-Message-State: ALoCoQkAmk1ZTL2wALUUrFfUbk8VK8AIyVsurUOHAn3I7bVIybMBoZAFtsA7n9KsoNOcDg8dkfZa
X-Received: by 10.180.11.194 with SMTP id s2mr6670328wib.45.1415964294155;
	Fri, 14 Nov 2014 03:24:54 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	dm10sm3029182wib.18.2014.11.14.03.24.52 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 14 Nov 2014 03:24:53 -0800 (PST)
Message-ID: <5465E68E.1000304@m2r.biz>
Date: Fri, 14 Nov 2014 12:25:02 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
Subject: [Xen-devel] qemu 2.2 crash on linux hvm domU (full backtrace
	included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid leaf 
with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, and 
qemu 2.2 from spice git (spice/next commit 
e779fa0a715530311e6f59fc8adb0f6eca914a89):
https://github.com/Fantu/Xen/commits/rebase/m2r-staging

Qemu crash on fedora 20 lxde (with software updates of some days ago) 
boot with this backtrace:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
> addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> 73          eax = env->regs[R_EAX];
> (gdb) bt full
> #0  0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
> addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>         s = 0x555556440a20
>         cs = 0x0
>         cpu = 0x0
>         __func__ = "vmport_ioport_read"
>         env = 0x8250
>         command = 0 '\000'
>         eax = 0
> #1  0x0000555555655b9c in memory_region_read_accessor 
> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0, 
> mask=4294967295)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>         tmp = 0
> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0, 
> value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
>     access=0x555555655b3a <memory_region_read_accessor>, 
> mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>         access_mask = 4294967295
>         access_size = 4
>         i = 0
> #3  0x0000555555658cc1 in memory_region_dispatch_read1 
> (mr=0x555556440aa8, addr=0, size=4) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>         data = 0
> #4  0x0000555555658d89 in memory_region_dispatch_read 
> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> No locals.
> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0, 
> pval=0x7fffffffd998, size=4) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> No locals.
> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840, 
> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4, is_write=false)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>         l = 4
>         ptr = 0x0
>         val = 7964229952888770560
>         addr1 = 0
>         mr = 0x555556440aa8
>         error = false
> #7  0x000055555560a173 in address_space_read (as=0x555555eae840, 
> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
> No locals.
> #8  0x000055555564fac7 in cpu_inl (addr=22104) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>         buf = "\377\377\377\377"
>         val = 21845
> #9  0x000055555567084b in do_inp (addr=22104, size=4) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> No locals.
> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>         i = 0
> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590, 
> req=0x7ffff7ff3000) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> ---Type <return> to continue, or q <return> to quit---
> No locals.
> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>         state = 0x5555563c1590
>         req = 0x7ffff7ff3000
> #13 0x000055555596d874 in qemu_iohandler_poll (pollfds=0x555556388a30, 
> ret=1) at iohandler.c:143
>         revents = 1
>         pioh = 0x5555563f3c90
>         ioh = 0x555556515f80
> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at 
> main-loop.c:495
>         ret = 1
>         timeout = 4294967295
>         timeout_ns = 3418165
> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>         nonblocking = false
>         last_io = 1
> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038, 
> envp=0x7fffffffe230) at vl.c:4400
>         i = 128
>         snapshot = 0
>         linux_boot = 0
>         initrd_filename = 0x0
>         kernel_filename = 0x0
>         kernel_cmdline = 0x555555a485c6 ""
>         boot_order = 0x5555563864e0 "dc"
>         ds = 0x5555564c71b0
>         cyls = 0
>         heads = 0
>         secs = 0
>         translation = 0
>         hda_opts = 0x0
>         opts = 0x555556386430
>         machine_opts = 0x555556388090
>         icount_opts = 0x0
>         olist = 0x555555e56da0
>         optind = 62
>         optarg = 0x7fffffffe914 
> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>         loadvm = 0x0
>         machine_class = 0x55555637c5c0
>         cpu_model = 0x0
>         vga_model = 0x0
>         qtest_chrdev = 0x0
> ---Type <return> to continue, or q <return> to quit---
>         qtest_log = 0x0
>         pid_file = 0x0
>         incoming = 0x0
>         show_vnc_port = 0
>         defconfig = true
>         userconfig = true
>         log_mask = 0x0
>         log_file = 0x0
>         mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>, 
> realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39 
> <free_and_trace>, calloc = 0,
>           try_malloc = 0, try_realloc = 0}
>         trace_events = 0x0
>         trace_file = 0x0
>         default_ram_size = 134217728
>         maxram_size = 2013265920
>         ram_slots = 0
>         vmstate_dump_file = 0x0
>         main_loop_err = 0x0
>         __func__ = "main"


> xl -vvv create /etc/xen/FEDORA19.cfg
> Parsing config from /etc/xen/FEDORA19.cfg
> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660: 
> create: how=(nil) callback=(nil) poller=0xac2af0
> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk 
> vdev=hda spec.backend=unknown
> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda, 
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk 
> vdev=hda, using backend qdisk
> libxl: debug: libxl_create.c:935:initiate_domain_create: running 
> bootloader
> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV 
> domain, skipping bootloader
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac32f8: deregister unregistered
> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
> xc: detail:   Loader:   0000000000100000->000000000036b324
> xc: detail:   Modules:  0000000000000000->0000000000000000
> xc: detail:   TOTAL:    0000000000000000->0000000078000000
> xc: detail:   ENTRY:    0000000000100000
> xc: detail: PHYSICAL MEMORY ALLOCATION:
> xc: detail:   4KB PAGES: 0x0000000000000200
> xc: detail:   2MB PAGES: 0x00000000000003bf
> xc: detail:   1GB PAGES: 0x0000000000000000
> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 -> 0x7f1f975012b0
> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk 
> vdev=hda spec.backend=qdisk
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac4ad0: deregister unregistered
> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning 
> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> /usr/lib/xen/bin/qemu-gdb
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -xen-domid
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> chardev=libxl-cmd,mode=control
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -nodefaults
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   FEDORA
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -spice
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> spicevmc,id=vdagent,name=vdagent
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> virtserialport,chardev=vdagent,name=com.redhat.spice.0
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> qxl-vga,vram_size_mb=64,ram_size_mb=64
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   order=dc
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> spicevmc,name=usbredir,id=usbrc1
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> usb-redir,chardev=usbrc1,id=usbrc1
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> spicevmc,name=usbredir,id=usbrc2
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> usb-redir,chardev=usbrc2,id=usbrc2
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> spicevmc,name=usbredir,id=usbrc3
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> usb-redir,chardev=usbrc3,id=usbrc3
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> spicevmc,name=usbredir,id=usbrc4
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> usb-redir,chardev=usbrc4,id=usbrc4
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -soundhw
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   2,maxcpus=2
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -netdev
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -machine
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -drive
> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
> register slotnum=3
> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660: 
> inprogress: poller=0xac2af0, flags=i
> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
> wpath=/local/domain/0/device-model/9/state token=3/0: event 
> epath=/local/domain/0/device-model/9/state
> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
> wpath=/local/domain/0/device-model/9/state token=3/0: event 
> epath=/local/domain/0/device-model/9/state
> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
> deregister slotnum=3
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac3558: deregister unregistered
> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to 
> /var/run/xen/qmp-libxl-9
> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>     "execute": "qmp_capabilities",
>     "id": 1
> }
> '
> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>     "execute": "query-chardev",
>     "id": 2
> }
> '
> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>     "execute": "query-vnc",
>     "id": 3
> }
> '
> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
> register slotnum=3
> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
> epath=/local/domain/0/backend/vif/9/0/state
> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend 
> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting state 1
> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
> epath=/local/domain/0/backend/vif/9/0/state
> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend 
> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
> deregister slotnum=3
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac8368: deregister unregistered
> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
> script: /etc/xen/scripts/vif-bridge online
> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to 
> execute: /etc/xen/scripts/vif-bridge online
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac83f0: deregister unregistered
> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
> script: /etc/xen/scripts/vif-bridge add
> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to 
> execute: /etc/xen/scripts/vif-bridge add
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac83f0: deregister unregistered
> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
> w=0xac83f0: deregister unregistered
> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao 
> 0xac2660: progress report: ignored
> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660: 
> complete, rc=0
> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660: destroy
> xc: debug: hypercall buffer: total allocations:704 total releases:704
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
> xc: debug: hypercall buffer: cache current size:4
> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
> xc: debug: hypercall buffer: total allocations:0 total releases:0
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:0
> xc: debug: hypercall buffer: cache current size:0
> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0

xl dmesg
> (d9) HVM Loader
> (d9) Detected Xen v4.5.0-rc
> (d9) Xenbus rings @0xfeffc000, event channel 1
> (d9) System requested SeaBIOS
> (d9) CPU speed is 2660 MHz
> (d9) Relocating guest memory for lowmem MMIO space disabled
> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
> (d9) PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
> (d9) PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
> (d9) PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
> (d9) PCI-ISA link 3 routed to IRQ5
> (d9) pci dev 01:3 INTA->IRQ10
> (d9) pci dev 02:0 INTA->IRQ11
> (d9) pci dev 03:0 INTA->IRQ5
> (d9) pci dev 04:0 INTA->IRQ5
> (d9) pci dev 05:0 INTA->IRQ10
> (d9) pci dev 06:0 INTA->IRQ11
> (d9) pci dev 1d:0 INTA->IRQ10
> (d9) pci dev 1d:1 INTB->IRQ11
> (d9) pci dev 1d:2 INTC->IRQ5
> (d9) pci dev 1d:7 INTD->IRQ5
> (d9) No RAM in high memory; setting high_mem resource base to 100000000
> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
> (d9) Multiprocessor initialisation:
> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
> (d9) Testing HVM environment:
> (d9)  - REP INSB across page boundaries ... passed
> (d9)  - GS base MSRs and SWAPGS ... passed
> (d9) Passed 2 of 2 tests
> (d9) Writing SMBIOS tables ...
> (d9) Loading SeaBIOS ...
> (d9) Creating MP tables ...
> (d9) Loading ACPI ...
> (d9) S3 disabled
> (d9) S4 disabled
> (d9) vm86 TSS at fc00a100
> (d9) BIOS map:
> (d9)  10000-100d3: Scratch space
> (d9)  c0000-fffff: Main BIOS
> (d9) E820 table:
> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> (d9) Invoking SeaBIOS ...
> (d9) SeaBIOS (version 
> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> (d9)
> (d9) Found Xen hypervisor signature at 40000000
> (d9) Running on QEMU (i440fx)
> (d9) xen: copy e820...
> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
> (d9) CPU Mhz=2660
> (d9) Found 13 PCI devices (max PCI bus is 00)
> (d9) Allocated Xen hypercall page at 77fff000
> (d9) Detected Xen v4.5.0-rc
> (d9) xen: copy BIOS tables...
> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
> (d9) Using pmtimer, ioport 0xb008
> (d9) Scan for VGA option rom
> (d9) Running option rom at c000:0003
> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
> (d9) pmm call arg1=0
> (d9) Turning on vga text mode console
> (d9) SeaBIOS (version 
> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
> (d9) Found 0 lpt ports
> (d9) Found 0 serial ports
> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> (d9) UHCI init on dev 00:1d.0 (io=c240)
> (d9) UHCI init on dev 00:1d.1 (io=c260)
> (d9) UHCI init on dev 00:1d.2 (io=c280)
> (d9) PS2 keyboard initialized
> (d9) All threads complete.
> (d9) Scan for option roms
> (d9) Running option rom at c980:0003
> (d9) pmm call arg1=1
> (d9) pmm call arg1=0
> (d9) pmm call arg1=1
> (d9) pmm call arg1=0
> (d9) Searching bootorder for: /pci@i0cf8/*@6
> (d9)
> (d9) Press F12 for boot menu.
> (d9)
> (d9) Searching bootorder for: HALT
> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba 
> LCHS=1024/255/63 s=20480000
> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
> (d9) Returned 258048 bytes of ZoneHigh
> (d9) e820 map has 6 items:
> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
> (d9) enter handle_19:
> (d9)   NULL
> (d9) Booting from Hard Disk...
> (d9) Booting from 0000:7c00
> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0

domU's xl cfg:
> name='FEDORA'
> builder="hvm"
> device_model_override="/usr/lib/xen/bin/qemu-gdb"
> memory=2048
> vcpus=2
> acpi_s3=0
> acpi_s4=0
> vif=['bridge=xenbr0']
> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
> boot='dc'
> device_model_version='qemu-xen'
> vnc=0
> keymap="it"
> vga="qxl"
> spice=1
> spicehost='0.0.0.0'
> spiceport=6005
> spicedisable_ticketing=1
> spicevdagent=1
> spice_clipboard_sharing=0
> spiceusbredirection=4
> soundhw="hda"

I tested also with stdvga instead of qxl vga but qemu crash always on 
fedora boot with same error.

If you need more informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:28:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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.xen.org>)
	id 1XpF3G-0001KV-3l; Fri, 14 Nov 2014 11:28:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpF3E-0001KJ-4p
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:28:28 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	1E/E2-02953-B57E5645; Fri, 14 Nov 2014 11:28:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415964505!7146384!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12897 invoked from network); 14 Nov 2014 11:28:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:28:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192810618"
Message-ID: <1415964503.7113.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Date: Fri, 14 Nov 2014 11:28:23 +0000
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Fabio Fantoni <fabio.fantoni@m2r.biz>, Wei Liu <wei.liu2@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 10:14 +0000, Hu, Robert wrote:
> Will rerun this test case in RC2 testing, and if still there, append
> the full logs then.

Thank you.

BTW, I've pointed this need for logs out to multiple of your
predecessors over the years. If you could try and get this information
(e.g. the link to the wiki, the need for logs in the general case) added
to your internal documentation (test plan, onboard docs for new
engineers, etc) that would be awesome.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:28:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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.xen.org>)
	id 1XpF38-0001Js-Nw; Fri, 14 Nov 2014 11:28:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XpF37-0001Jj-7y
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:28:21 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	52/A1-02957-457E5645; Fri, 14 Nov 2014 11:28:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415964499!12544475!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4746 invoked from network); 14 Nov 2014 11:28:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:28:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="26848166"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Liuyongan <liuyongan@huawei.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] ioreq process conflict when
	EVTCHNOP_bind_interdomain hypercall and vcpu pio occur concurrently
Thread-Index: Ac/9rVq1IRZuUMpZQbCRp6vd6elF1ACSf8RgAAGWZKA=
Date: Fri, 14 Nov 2014 11:28:17 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD011151867@AMSPEX01CL01.citrite.net>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A1958CCA617@SZXEMA512-MBS.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A1958CCA617@SZXEMA512-MBS.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: Qianhuibin <qianhuibin@huawei.com>, zhangyuexi <zhangyuexi@huawei.com>,
	"Shanhaitao \(Tony\)" <shanhaitao1@huawei.com>,
	Fanhenglong <fanhenglong@huawei.com>,
	Huangzhichao <huangzhichao@huawei.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] ioreq process conflict when
 EVTCHNOP_bind_interdomain hypercall and vcpu pio occur concurrently
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Liuyongan
> Sent: 14 November 2014 10:57
> To: xen-devel@lists.xen.org
> Cc: Qianhuibin; zhangyuexi; Shanhaitao (Tony); Fanhenglong; Huangzhichao;
> JBeulich@suse.com
> Subject: Re: [Xen-devel] ioreq process conflict when
> EVTCHNOP_bind_interdomain hypercall and vcpu pio occur concurrently
> 
> If Qemu calls xc_evtchn_bind_interdomain to allocate an free port for each
> vcpu,
> it will receive empty io-request triggered by xen. I say it empty as the ioreq in
> shared page is not filled. So qemu can simply skip the first ioreq of each vcpu
> by
> a pervcpu flag.
> 
> You should not skip the first one by check ioreq->state , as the shared page
> may
> be modified by real vm trigged io req, so ioreq->state becomes REQUEST
> READY.
> 
> Any bugs here?
> 

Not as far as  I know. The emulator should ignore the ioreq is the state is not 'request ready' and that's fine because Xen will always raise the event after setting the state and will only set the state to ready after setting up the rest of the structure.

  Paul

> Liuyongan
> 2014-11-14
> 
> 
> > -----Original Message-----
> > From: Liuyongan
> > Sent: Tuesday, November 11, 2014 8:45 PM
> > To: 'xen-devel@lists.xen.org'
> > Cc: 'JBeulich@suse.com'; Shanhaitao (Tony); Huangzhichao; zhangyuexi;
> > Fanhenglong; Qianhuibin
> > Subject: ioreq process conflict when EVTCHNOP_bind_interdomain
> hypercall
> > and vcpu pio occur concurrently
> >
> > I wonder if it is necessary for xen to trigger the event channel pending
> when
> > the port related a vcpu port io.
> >
> > Suppose a scenario as follows:
> >
> > 1)  Qemu make a hypercall using codes:
> >      for (i = 0; i < smp_cpus; i++) {
> >         rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
> >
> > xen_vcpu_eport(state->shared_page, i));
> >         if (rc == -1) {
> >             fprintf(stderr, "bind interdomain ioctl(shared_page) error %d\n",
> > errno);
> >             return -1;
> >         }
> >         state->ioreq_local_port[i] = rc;
> >         ...
> >      }
> >
> > 2)  Xen do_event_channel_op allocate a free port and call
> evtchn_set_pending
> > to trigger a evtchn event.
> >
> > 3)  Qemu enters main_loop and begin the evtchn event (pio event).
> >
> > 4)  The vcpus of a vm begin to trigger real pio exit,  and this ioreq_t will
> > conflict with the one triggered in step 2.
> >
> > This will certainly cause failures of real port io.
> >
> > Does anyone here have any suggestions?
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 14 11:28:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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.xen.org>)
	id 1XpF3G-0001KV-3l; Fri, 14 Nov 2014 11:28:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpF3E-0001KJ-4p
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:28:28 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	1E/E2-02953-B57E5645; Fri, 14 Nov 2014 11:28:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415964505!7146384!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12897 invoked from network); 14 Nov 2014 11:28:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:28:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192810618"
Message-ID: <1415964503.7113.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Date: Fri, 14 Nov 2014 11:28:23 +0000
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Fabio Fantoni <fabio.fantoni@m2r.biz>, Wei Liu <wei.liu2@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 10:14 +0000, Hu, Robert wrote:
> Will rerun this test case in RC2 testing, and if still there, append
> the full logs then.

Thank you.

BTW, I've pointed this need for logs out to multiple of your
predecessors over the years. If you could try and get this information
(e.g. the link to the wiki, the need for logs in the general case) added
to your internal documentation (test plan, onboard docs for new
engineers, etc) that would be awesome.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:28:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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.xen.org>)
	id 1XpF38-0001Js-Nw; Fri, 14 Nov 2014 11:28:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1XpF37-0001Jj-7y
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 11:28:21 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	52/A1-02957-457E5645; Fri, 14 Nov 2014 11:28:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415964499!12544475!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4746 invoked from network); 14 Nov 2014 11:28:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:28:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="26848166"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Liuyongan <liuyongan@huawei.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] ioreq process conflict when
	EVTCHNOP_bind_interdomain hypercall and vcpu pio occur concurrently
Thread-Index: Ac/9rVq1IRZuUMpZQbCRp6vd6elF1ACSf8RgAAGWZKA=
Date: Fri, 14 Nov 2014 11:28:17 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD011151867@AMSPEX01CL01.citrite.net>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A1958CCA617@SZXEMA512-MBS.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A1958CCA617@SZXEMA512-MBS.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-DLP: AMS1
Cc: Qianhuibin <qianhuibin@huawei.com>, zhangyuexi <zhangyuexi@huawei.com>,
	"Shanhaitao \(Tony\)" <shanhaitao1@huawei.com>,
	Fanhenglong <fanhenglong@huawei.com>,
	Huangzhichao <huangzhichao@huawei.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] ioreq process conflict when
 EVTCHNOP_bind_interdomain hypercall and vcpu pio occur concurrently
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Liuyongan
> Sent: 14 November 2014 10:57
> To: xen-devel@lists.xen.org
> Cc: Qianhuibin; zhangyuexi; Shanhaitao (Tony); Fanhenglong; Huangzhichao;
> JBeulich@suse.com
> Subject: Re: [Xen-devel] ioreq process conflict when
> EVTCHNOP_bind_interdomain hypercall and vcpu pio occur concurrently
> 
> If Qemu calls xc_evtchn_bind_interdomain to allocate an free port for each
> vcpu,
> it will receive empty io-request triggered by xen. I say it empty as the ioreq in
> shared page is not filled. So qemu can simply skip the first ioreq of each vcpu
> by
> a pervcpu flag.
> 
> You should not skip the first one by check ioreq->state , as the shared page
> may
> be modified by real vm trigged io req, so ioreq->state becomes REQUEST
> READY.
> 
> Any bugs here?
> 

Not as far as  I know. The emulator should ignore the ioreq is the state is not 'request ready' and that's fine because Xen will always raise the event after setting the state and will only set the state to ready after setting up the rest of the structure.

  Paul

> Liuyongan
> 2014-11-14
> 
> 
> > -----Original Message-----
> > From: Liuyongan
> > Sent: Tuesday, November 11, 2014 8:45 PM
> > To: 'xen-devel@lists.xen.org'
> > Cc: 'JBeulich@suse.com'; Shanhaitao (Tony); Huangzhichao; zhangyuexi;
> > Fanhenglong; Qianhuibin
> > Subject: ioreq process conflict when EVTCHNOP_bind_interdomain
> hypercall
> > and vcpu pio occur concurrently
> >
> > I wonder if it is necessary for xen to trigger the event channel pending
> when
> > the port related a vcpu port io.
> >
> > Suppose a scenario as follows:
> >
> > 1)  Qemu make a hypercall using codes:
> >      for (i = 0; i < smp_cpus; i++) {
> >         rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
> >
> > xen_vcpu_eport(state->shared_page, i));
> >         if (rc == -1) {
> >             fprintf(stderr, "bind interdomain ioctl(shared_page) error %d\n",
> > errno);
> >             return -1;
> >         }
> >         state->ioreq_local_port[i] = rc;
> >         ...
> >      }
> >
> > 2)  Xen do_event_channel_op allocate a free port and call
> evtchn_set_pending
> > to trigger a evtchn event.
> >
> > 3)  Qemu enters main_loop and begin the evtchn event (pio event).
> >
> > 4)  The vcpus of a vm begin to trigger real pio exit,  and this ioreq_t will
> > conflict with the one triggered in step 2.
> >
> > This will certainly cause failures of real port io.
> >
> > Does anyone here have any suggestions?
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 14 11:30:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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 1XpF4j-0001VI-J2; Fri, 14 Nov 2014 11:30:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpF4i-0001V2-Ac
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:30:00 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	65/50-02698-6B7E5645; Fri, 14 Nov 2014 11:29:58 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415964597!9226991!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11514 invoked from network); 14 Nov 2014 11:29:58 -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;
	14 Nov 2014 11:29:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191345556"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:29:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpF4d-0006jl-KV;
	Fri, 14 Nov 2014 11:29:55 +0000
Date: Fri, 14 Nov 2014 11:29:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PULL for-2.2 0/2] Xen tree 2014-11-14
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following changes since commit c52e67924fbdadfa00668248f5c075542943c54c:

  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2014-11-13 15:44:16 +0000)

are available in the git repository at:


  git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2014-11-14

for you to fetch changes up to 2f01dfacb56bc7a0d4639adc9dff9aae131e6216:

  xen_disk: fix unmapping of persistent grants (2014-11-14 11:12:38 +0000)

----------------------------------------------------------------
Igor Mammedov (1):
      pc: piix4_pm: init legacy PCI hotplug when running on Xen

Roger Pau Monne (1):
      xen_disk: fix unmapping of persistent grants

 hw/acpi/piix4.c     |    4 +++
 hw/block/xen_disk.c |   72 ++++++++++++++++++++++++++++++++++++++++++++++-----
 hw/i386/pc_piix.c   |   11 --------
 3 files changed, 70 insertions(+), 17 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:30:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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 1XpF4j-0001VI-J2; Fri, 14 Nov 2014 11:30:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpF4i-0001V2-Ac
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:30:00 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	65/50-02698-6B7E5645; Fri, 14 Nov 2014 11:29:58 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415964597!9226991!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11514 invoked from network); 14 Nov 2014 11:29:58 -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;
	14 Nov 2014 11:29:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191345556"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:29:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpF4d-0006jl-KV;
	Fri, 14 Nov 2014 11:29:55 +0000
Date: Fri, 14 Nov 2014 11:29:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PULL for-2.2 0/2] Xen tree 2014-11-14
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following changes since commit c52e67924fbdadfa00668248f5c075542943c54c:

  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2014-11-13 15:44:16 +0000)

are available in the git repository at:


  git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2014-11-14

for you to fetch changes up to 2f01dfacb56bc7a0d4639adc9dff9aae131e6216:

  xen_disk: fix unmapping of persistent grants (2014-11-14 11:12:38 +0000)

----------------------------------------------------------------
Igor Mammedov (1):
      pc: piix4_pm: init legacy PCI hotplug when running on Xen

Roger Pau Monne (1):
      xen_disk: fix unmapping of persistent grants

 hw/acpi/piix4.c     |    4 +++
 hw/block/xen_disk.c |   72 ++++++++++++++++++++++++++++++++++++++++++++++-----
 hw/i386/pc_piix.c   |   11 --------
 3 files changed, 70 insertions(+), 17 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:30:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpF5L-0001a5-Bt; Fri, 14 Nov 2014 11:30:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpF5K-0001Zh-6g
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:30:38 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	D1/06-02957-DD7E5645; Fri, 14 Nov 2014 11:30:37 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415964635!7925209!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17118 invoked from network); 14 Nov 2014 11:30:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:30:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191345667"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:30:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpF59-0006kB-LY;
	Fri, 14 Nov 2014 11:30:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Fri, 14 Nov 2014 11:30:10 +0000
Message-ID: <1415964611-20838-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Length: 8714
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, peter.maydell@linaro.org,
	xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PULL for-2.2 2/2] xen_disk: fix unmapping of
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RnJvbTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KClRoaXMgcGF0Y2gg
Zml4ZXMgdHdvIGlzc3VlcyB3aXRoIHBlcnNpc3RlbnQgZ3JhbnRzIGFuZCB0aGUgZGlzayBQViBi
YWNrZW5kCihRZGlzayk6CgogLSBLZWVwIHRyYWNrIG9mIG1lbW9yeSByZWdpb25zIHdoZXJlIHBl
cnNpc3RlbnQgZ3JhbnRzIGhhdmUgYmVlbiBtYXBwZWQKICAgc2luY2Ugd2UgbmVlZCB0byB1bm1h
cCB0aGVtIGFzIGEgd2hvbGUuIEl0IGlzIG5vdCBwb3NzaWJsZSB0byB1bm1hcCBhCiAgIHNpbmds
ZSBncmFudCBpZiBpdCBoYXMgYmVlbiBiYXRjaC1tYXBwZWQuIEEgbmV3IGNoZWNrIGhhcyBhbHNv
IGJlZW4gYWRkZWQKICAgdG8gbWFrZSBzdXJlIHBlcnNpc3RlbnQgZ3JhbnRzIGFyZSBvbmx5IHVz
ZWQgaWYgdGhlIHdob2xlIG1hcHBlZCByZWdpb24KICAgY2FuIGJlIHBlcnNpc3RlbnRseSBtYXBw
ZWQgaW4gdGhlIGJhdGNoX21hcHMgY2FzZS4KIC0gVW5tYXAgcGVyc2lzdGVudCBncmFudHMgYmVm
b3JlIHN3aXRjaGluZyB0byB0aGUgY2xvc2VkIHN0YXRlLCBzbyB0aGUKICAgZnJvbnRlbmQgY2Fu
IGFsc28gZnJlZSB0aGVtLgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIu
cGF1QGNpdHJpeC5jb20+ClJlcG9ydGVkLWJ5OiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFw
QGV1LmNpdHJpeC5jb20+CkNjOiBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGlu
aUBldS5jaXRyaXguY29tPgpDYzogS2V2aW4gV29sZiA8a3dvbGZAcmVkaGF0LmNvbT4KQ2M6IFN0
ZWZhbiBIYWpub2N6aSA8c3RlZmFuaGFAcmVkaGF0LmNvbT4KQ2M6IEdlb3JnZSBEdW5sYXAgPGdl
b3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29u
cmFkLndpbGtAb3JhY2xlLmNvbT4KLS0tCiBody9ibG9jay94ZW5fZGlzay5jIHwgICA3MiArKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0KIDEgZmlsZSBj
aGFuZ2VkLCA2NiBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2h3
L2Jsb2NrL3hlbl9kaXNrLmMgYi9ody9ibG9jay94ZW5fZGlzay5jCmluZGV4IDIzMWU5YTcuLjIx
ODQyYTAgMTAwNjQ0Ci0tLSBhL2h3L2Jsb2NrL3hlbl9kaXNrLmMKKysrIGIvaHcvYmxvY2sveGVu
X2Rpc2suYwpAQCAtNTksNiArNTksMTMgQEAgc3RydWN0IFBlcnNpc3RlbnRHcmFudCB7CiAKIHR5
cGVkZWYgc3RydWN0IFBlcnNpc3RlbnRHcmFudCBQZXJzaXN0ZW50R3JhbnQ7CiAKK3N0cnVjdCBQ
ZXJzaXN0ZW50UmVnaW9uIHsKKyAgICB2b2lkICphZGRyOworICAgIGludCBudW07Cit9OworCit0
eXBlZGVmIHN0cnVjdCBQZXJzaXN0ZW50UmVnaW9uIFBlcnNpc3RlbnRSZWdpb247CisKIHN0cnVj
dCBpb3JlcSB7CiAgICAgYmxraWZfcmVxdWVzdF90ICAgICByZXE7CiAgICAgaW50MTZfdCAgICAg
ICAgICAgICBzdGF0dXM7CkBAIC0xMTgsNiArMTI1LDcgQEAgc3RydWN0IFhlbkJsa0RldiB7CiAg
ICAgZ2Jvb2xlYW4gICAgICAgICAgICBmZWF0dXJlX2Rpc2NhcmQ7CiAgICAgZ2Jvb2xlYW4gICAg
ICAgICAgICBmZWF0dXJlX3BlcnNpc3RlbnQ7CiAgICAgR1RyZWUgICAgICAgICAgICAgICAqcGVy
c2lzdGVudF9nbnRzOworICAgIEdTTGlzdCAgICAgICAgICAgICAgKnBlcnNpc3RlbnRfcmVnaW9u
czsKICAgICB1bnNpZ25lZCBpbnQgICAgICAgIHBlcnNpc3RlbnRfZ250X2NvdW50OwogICAgIHVu
c2lnbmVkIGludCAgICAgICAgbWF4X2dyYW50czsKIApAQCAtMTc3LDYgKzE4NSwyMyBAQCBzdGF0
aWMgdm9pZCBkZXN0cm95X2dyYW50KGdwb2ludGVyIHBnbnQpCiAgICAgZ19mcmVlKGdyYW50KTsK
IH0KIAorc3RhdGljIHZvaWQgcmVtb3ZlX3BlcnNpc3RlbnRfcmVnaW9uKGdwb2ludGVyIGRhdGEs
IGdwb2ludGVyIGRldikKK3sKKyAgICBQZXJzaXN0ZW50UmVnaW9uICpyZWdpb24gPSBkYXRhOwor
ICAgIHN0cnVjdCBYZW5CbGtEZXYgKmJsa2RldiA9IGRldjsKKyAgICBYZW5HbnR0YWIgZ250ID0g
YmxrZGV2LT54ZW5kZXYuZ250dGFiZGV2OworCisgICAgaWYgKHhjX2dudHRhYl9tdW5tYXAoZ250
LCByZWdpb24tPmFkZHIsIHJlZ2lvbi0+bnVtKSAhPSAwKSB7CisgICAgICAgIHhlbl9iZV9wcmlu
dGYoJmJsa2Rldi0+eGVuZGV2LCAwLAorICAgICAgICAgICAgICAgICAgICAgICJ4Y19nbnR0YWJf
bXVubWFwIHJlZ2lvbiAlcCBmYWlsZWQ6ICVzXG4iLAorICAgICAgICAgICAgICAgICAgICAgIHJl
Z2lvbi0+YWRkciwgc3RyZXJyb3IoZXJybm8pKTsKKyAgICB9CisgICAgeGVuX2JlX3ByaW50Zigm
YmxrZGV2LT54ZW5kZXYsIDMsCisgICAgICAgICAgICAgICAgICAidW5tYXBwZWQgZ3JhbnQgcmVn
aW9uICVwIHdpdGggJWQgcGFnZXNcbiIsCisgICAgICAgICAgICAgICAgICByZWdpb24tPmFkZHIs
IHJlZ2lvbi0+bnVtKTsKKyAgICBnX2ZyZWUocmVnaW9uKTsKK30KKwogc3RhdGljIHN0cnVjdCBp
b3JlcSAqaW9yZXFfc3RhcnQoc3RydWN0IFhlbkJsa0RldiAqYmxrZGV2KQogewogICAgIHN0cnVj
dCBpb3JlcSAqaW9yZXEgPSBOVUxMOwpAQCAtMzQzLDYgKzM2OCw3IEBAIHN0YXRpYyBpbnQgaW9y
ZXFfbWFwKHN0cnVjdCBpb3JlcSAqaW9yZXEpCiAgICAgdm9pZCAqcGFnZVtCTEtJRl9NQVhfU0VH
TUVOVFNfUEVSX1JFUVVFU1RdOwogICAgIGludCBpLCBqLCBuZXdfbWFwcyA9IDA7CiAgICAgUGVy
c2lzdGVudEdyYW50ICpncmFudDsKKyAgICBQZXJzaXN0ZW50UmVnaW9uICpyZWdpb247CiAgICAg
LyogZG9taWRzIGFuZCByZWZzIHZhcmlhYmxlcyB3aWxsIGNvbnRhaW4gdGhlIGluZm9ybWF0aW9u
IG5lY2Vzc2FyeQogICAgICAqIHRvIG1hcCB0aGUgZ3JhbnRzIHRoYXQgYXJlIG5lZWRlZCB0byBm
dWxmaWxsIHRoaXMgcmVxdWVzdC4KICAgICAgKgpAQCAtNDIxLDcgKzQ0NywyMiBAQCBzdGF0aWMg
aW50IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEgKmlvcmVxKQogICAgICAgICAgICAgfQogICAgICAg
ICB9CiAgICAgfQotICAgIGlmIChpb3JlcS0+YmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsK
KyAgICBpZiAoaW9yZXEtPmJsa2Rldi0+ZmVhdHVyZV9wZXJzaXN0ZW50ICYmIG5ld19tYXBzICE9
IDAgJiYKKyAgICAgICAgKCFiYXRjaF9tYXBzIHx8IChpb3JlcS0+YmxrZGV2LT5wZXJzaXN0ZW50
X2dudF9jb3VudCArIG5ld19tYXBzIDw9CisgICAgICAgIGlvcmVxLT5ibGtkZXYtPm1heF9ncmFu
dHMpKSkgeworICAgICAgICAvKgorICAgICAgICAgKiBJZiB3ZSBhcmUgdXNpbmcgcGVyc2lzdGVu
dCBncmFudHMgYW5kIGJhdGNoIG1hcHBpbmdzIG9ubHkKKyAgICAgICAgICogYWRkIHRoZSBuZXcg
bWFwcyB0byB0aGUgbGlzdCBvZiBwZXJzaXN0ZW50IGdyYW50cyBpZiB0aGUgd2hvbGUKKyAgICAg
ICAgICogYXJlYSBjYW4gYmUgcGVyc2lzdGVudGx5IG1hcHBlZC4KKyAgICAgICAgICovCisgICAg
ICAgIGlmIChiYXRjaF9tYXBzKSB7CisgICAgICAgICAgICByZWdpb24gPSBnX21hbGxvYzAoc2l6
ZW9mKCpyZWdpb24pKTsKKyAgICAgICAgICAgIHJlZ2lvbi0+YWRkciA9IGlvcmVxLT5wYWdlczsK
KyAgICAgICAgICAgIHJlZ2lvbi0+bnVtID0gbmV3X21hcHM7CisgICAgICAgICAgICBpb3JlcS0+
YmxrZGV2LT5wZXJzaXN0ZW50X3JlZ2lvbnMgPSBnX3NsaXN0X2FwcGVuZCgKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW9yZXEtPmJsa2Rldi0+cGVyc2lzdGVu
dF9yZWdpb25zLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy
ZWdpb24pOworICAgICAgICB9CiAgICAgICAgIHdoaWxlICgoaW9yZXEtPmJsa2Rldi0+cGVyc2lz
dGVudF9nbnRfY291bnQgPCBpb3JlcS0+YmxrZGV2LT5tYXhfZ3JhbnRzKQogICAgICAgICAgICAg
ICAmJiBuZXdfbWFwcykgewogICAgICAgICAgICAgLyogR28gdGhyb3VnaCB0aGUgbGlzdCBvZiBu
ZXdseSBtYXBwZWQgZ3JhbnRzIGFuZCBhZGQgYXMgbWFueQpAQCAtNDQ3LDYgKzQ4OCw3IEBAIHN0
YXRpYyBpbnQgaW9yZXFfbWFwKHN0cnVjdCBpb3JlcSAqaW9yZXEpCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGdyYW50KTsKICAgICAgICAgICAgIGlvcmVxLT5ibGtkZXYtPnBlcnNpc3RlbnRf
Z250X2NvdW50Kys7CiAgICAgICAgIH0KKyAgICAgICAgYXNzZXJ0KCFiYXRjaF9tYXBzIHx8IG5l
d19tYXBzID09IDApOwogICAgIH0KICAgICBmb3IgKGkgPSAwOyBpIDwgaW9yZXEtPnYubmlvdjsg
aSsrKSB7CiAgICAgICAgIGlvcmVxLT52LmlvdltpXS5pb3ZfYmFzZSArPSAodWludHB0cl90KXBh
Z2VbaV07CkBAIC05NzEsNyArMTAxMywxMCBAQCBzdGF0aWMgaW50IGJsa19jb25uZWN0KHN0cnVj
dCBYZW5EZXZpY2UgKnhlbmRldikKICAgICAgICAgYmxrZGV2LT5tYXhfZ3JhbnRzID0gbWF4X3Jl
cXVlc3RzICogQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUOwogICAgICAgICBibGtkZXYt
PnBlcnNpc3RlbnRfZ250cyA9IGdfdHJlZV9uZXdfZnVsbCgoR0NvbXBhcmVEYXRhRnVuYylpbnRf
Y21wLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCwg
TlVMTCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJhdGNo
X21hcHMgPworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKEdE
ZXN0cm95Tm90aWZ5KWdfZnJlZSA6CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAoR0Rlc3Ryb3lOb3RpZnkpZGVzdHJveV9ncmFudCk7CisgICAgICAgIGJsa2Rl
di0+cGVyc2lzdGVudF9yZWdpb25zID0gTlVMTDsKICAgICAgICAgYmxrZGV2LT5wZXJzaXN0ZW50
X2dudF9jb3VudCA9IDA7CiAgICAgfQogCkBAIC0xMDAwLDYgKzEwNDUsMjYgQEAgc3RhdGljIHZv
aWQgYmxrX2Rpc2Nvbm5lY3Qoc3RydWN0IFhlbkRldmljZSAqeGVuZGV2KQogICAgICAgICBibGtk
ZXYtPmNudF9tYXAtLTsKICAgICAgICAgYmxrZGV2LT5zcmluZyA9IE5VTEw7CiAgICAgfQorCisg
ICAgLyoKKyAgICAgKiBVbm1hcCBwZXJzaXN0ZW50IGdyYW50cyBiZWZvcmUgc3dpdGNoaW5nIHRv
IHRoZSBjbG9zZWQgc3RhdGUKKyAgICAgKiBzbyB0aGUgZnJvbnRlbmQgY2FuIGZyZWUgdGhlbS4K
KyAgICAgKgorICAgICAqIEluIHRoZSAhYmF0Y2hfbWFwcyBjYXNlIGdfdHJlZV9kZXN0cm95IHdp
bGwgdGFrZSBjYXJlIG9mIHVubWFwcGluZworICAgICAqIHRoZSBncmFudCwgYnV0IGluIHRoZSBi
YXRjaF9tYXBzIGNhc2Ugd2UgbmVlZCB0byBpdGVyYXRlIG92ZXIgZXZlcnkKKyAgICAgKiByZWdp
b24gaW4gcGVyc2lzdGVudF9yZWdpb25zIGFuZCB1bm1hcCBpdC4KKyAgICAgKi8KKyAgICBpZiAo
YmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKKyAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxr
ZGV2LT5wZXJzaXN0ZW50X2dudHMpOworICAgICAgICBhc3NlcnQoYmF0Y2hfbWFwcyB8fCBibGtk
ZXYtPnBlcnNpc3RlbnRfZ250X2NvdW50ID09IDApOworICAgICAgICBpZiAoYmF0Y2hfbWFwcykg
eworICAgICAgICAgICAgYmxrZGV2LT5wZXJzaXN0ZW50X2dudF9jb3VudCA9IDA7CisgICAgICAg
ICAgICBnX3NsaXN0X2ZvcmVhY2goYmxrZGV2LT5wZXJzaXN0ZW50X3JlZ2lvbnMsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgKEdGdW5jKXJlbW92ZV9wZXJzaXN0ZW50X3JlZ2lvbiwgYmxr
ZGV2KTsKKyAgICAgICAgICAgIGdfc2xpc3RfZnJlZShibGtkZXYtPnBlcnNpc3RlbnRfcmVnaW9u
cyk7CisgICAgICAgIH0KKyAgICAgICAgYmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQgPSBmYWxz
ZTsKKyAgICB9CiB9CiAKIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhlbkRldmljZSAqeGVu
ZGV2KQpAQCAtMTAxMSwxMSArMTA3Niw2IEBAIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhl
bkRldmljZSAqeGVuZGV2KQogICAgICAgICBibGtfZGlzY29ubmVjdCh4ZW5kZXYpOwogICAgIH0K
IAotICAgIC8qIEZyZWUgcGVyc2lzdGVudCBncmFudHMgKi8KLSAgICBpZiAoYmxrZGV2LT5mZWF0
dXJlX3BlcnNpc3RlbnQpIHsKLSAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxrZGV2LT5wZXJzaXN0
ZW50X2dudHMpOwotICAgIH0KLQogICAgIHdoaWxlICghUUxJU1RfRU1QVFkoJmJsa2Rldi0+ZnJl
ZWxpc3QpKSB7CiAgICAgICAgIGlvcmVxID0gUUxJU1RfRklSU1QoJmJsa2Rldi0+ZnJlZWxpc3Qp
OwogICAgICAgICBRTElTVF9SRU1PVkUoaW9yZXEsIGxpc3QpOwotLSAKMS43LjEwLjQKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:30:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpF5K-0001Zs-RL; Fri, 14 Nov 2014 11:30:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpF5J-0001ZY-HS
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:30:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CB/77-09842-CD7E5645; Fri, 14 Nov 2014 11:30:36 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415964635!12728352!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19927 invoked from network); 14 Nov 2014 11:30:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:30:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192811192"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:30:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpF59-0006kB-Kr;
	Fri, 14 Nov 2014 11:30:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Fri, 14 Nov 2014 11:30:09 +0000
Message-ID: <1415964611-20838-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: peter.maydell@linaro.org, Igor Mammedov <imammedo@redhat.com>,
	xen-devel@lists.xensource.com, Li Liang <liang.z.li@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PULL for-2.2 1/2] pc: piix4_pm: init legacy PCI
	hotplug when running 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

From: Igor Mammedov <imammedo@redhat.com>

If user starts QEMU with "-machine pc,accel=xen", then
compat property in xenfv won't work and it would cause error:
"Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set"
when PCI device is added with -device on QEMU CLI.

From: Igor Mammedov <imammedo@redhat.com>

In case of Xen instead of using compat property, just use the fact
that xen doesn't use QEMU's fw_cfg/acpi tables to switch piix4_pm
into legacy PCI hotplug mode when Xen is enabled.

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Li Liang <liang.z.li@intel.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
---
 hw/acpi/piix4.c   |    4 ++++
 hw/i386/pc_piix.c |   11 -----------
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 78c0a6d..481a16c 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -36,6 +36,7 @@
 #include "hw/mem/pc-dimm.h"
 #include "hw/acpi/memory_hotplug.h"
 #include "hw/acpi/acpi_dev_interface.h"
+#include "hw/xen/xen.h"
 
 //#define DEBUG
 
@@ -501,6 +502,9 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
     s->irq = sci_irq;
     s->smi_irq = smi_irq;
     s->kvm_enabled = kvm_enabled;
+    if (xen_enabled()) {
+        s->use_acpi_pci_hotplug = false;
+    }
 
     qdev_init_nofail(dev);
 
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index b559181..7bb97a4 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -916,17 +916,6 @@ static QEMUMachine xenfv_machine = {
     .max_cpus = HVM_MAX_VCPUS,
     .default_machine_opts = "accel=xen",
     .hot_add_cpu = pc_hot_add_cpu,
-    .compat_props = (GlobalProperty[]) {
-        /* xenfv has no fwcfg and so does not load acpi from QEMU.
-         * as such new acpi features don't work.
-         */
-        {
-            .driver   = "PIIX4_PM",
-            .property = "acpi-pci-hotplug-with-bridge-support",
-            .value    = "off",
-        },
-        { /* end of list */ }
-    },
 };
 #endif
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:30:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpF5L-0001a5-Bt; Fri, 14 Nov 2014 11:30:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpF5K-0001Zh-6g
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:30:38 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	D1/06-02957-DD7E5645; Fri, 14 Nov 2014 11:30:37 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415964635!7925209!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17118 invoked from network); 14 Nov 2014 11:30:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:30:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191345667"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:30:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpF59-0006kB-LY;
	Fri, 14 Nov 2014 11:30:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Fri, 14 Nov 2014 11:30:10 +0000
Message-ID: <1415964611-20838-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Length: 8714
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, peter.maydell@linaro.org,
	xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PULL for-2.2 2/2] xen_disk: fix unmapping of
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RnJvbTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KClRoaXMgcGF0Y2gg
Zml4ZXMgdHdvIGlzc3VlcyB3aXRoIHBlcnNpc3RlbnQgZ3JhbnRzIGFuZCB0aGUgZGlzayBQViBi
YWNrZW5kCihRZGlzayk6CgogLSBLZWVwIHRyYWNrIG9mIG1lbW9yeSByZWdpb25zIHdoZXJlIHBl
cnNpc3RlbnQgZ3JhbnRzIGhhdmUgYmVlbiBtYXBwZWQKICAgc2luY2Ugd2UgbmVlZCB0byB1bm1h
cCB0aGVtIGFzIGEgd2hvbGUuIEl0IGlzIG5vdCBwb3NzaWJsZSB0byB1bm1hcCBhCiAgIHNpbmds
ZSBncmFudCBpZiBpdCBoYXMgYmVlbiBiYXRjaC1tYXBwZWQuIEEgbmV3IGNoZWNrIGhhcyBhbHNv
IGJlZW4gYWRkZWQKICAgdG8gbWFrZSBzdXJlIHBlcnNpc3RlbnQgZ3JhbnRzIGFyZSBvbmx5IHVz
ZWQgaWYgdGhlIHdob2xlIG1hcHBlZCByZWdpb24KICAgY2FuIGJlIHBlcnNpc3RlbnRseSBtYXBw
ZWQgaW4gdGhlIGJhdGNoX21hcHMgY2FzZS4KIC0gVW5tYXAgcGVyc2lzdGVudCBncmFudHMgYmVm
b3JlIHN3aXRjaGluZyB0byB0aGUgY2xvc2VkIHN0YXRlLCBzbyB0aGUKICAgZnJvbnRlbmQgY2Fu
IGFsc28gZnJlZSB0aGVtLgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIu
cGF1QGNpdHJpeC5jb20+ClJlcG9ydGVkLWJ5OiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFw
QGV1LmNpdHJpeC5jb20+CkNjOiBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGlu
aUBldS5jaXRyaXguY29tPgpDYzogS2V2aW4gV29sZiA8a3dvbGZAcmVkaGF0LmNvbT4KQ2M6IFN0
ZWZhbiBIYWpub2N6aSA8c3RlZmFuaGFAcmVkaGF0LmNvbT4KQ2M6IEdlb3JnZSBEdW5sYXAgPGdl
b3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29u
cmFkLndpbGtAb3JhY2xlLmNvbT4KLS0tCiBody9ibG9jay94ZW5fZGlzay5jIHwgICA3MiArKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0KIDEgZmlsZSBj
aGFuZ2VkLCA2NiBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2h3
L2Jsb2NrL3hlbl9kaXNrLmMgYi9ody9ibG9jay94ZW5fZGlzay5jCmluZGV4IDIzMWU5YTcuLjIx
ODQyYTAgMTAwNjQ0Ci0tLSBhL2h3L2Jsb2NrL3hlbl9kaXNrLmMKKysrIGIvaHcvYmxvY2sveGVu
X2Rpc2suYwpAQCAtNTksNiArNTksMTMgQEAgc3RydWN0IFBlcnNpc3RlbnRHcmFudCB7CiAKIHR5
cGVkZWYgc3RydWN0IFBlcnNpc3RlbnRHcmFudCBQZXJzaXN0ZW50R3JhbnQ7CiAKK3N0cnVjdCBQ
ZXJzaXN0ZW50UmVnaW9uIHsKKyAgICB2b2lkICphZGRyOworICAgIGludCBudW07Cit9OworCit0
eXBlZGVmIHN0cnVjdCBQZXJzaXN0ZW50UmVnaW9uIFBlcnNpc3RlbnRSZWdpb247CisKIHN0cnVj
dCBpb3JlcSB7CiAgICAgYmxraWZfcmVxdWVzdF90ICAgICByZXE7CiAgICAgaW50MTZfdCAgICAg
ICAgICAgICBzdGF0dXM7CkBAIC0xMTgsNiArMTI1LDcgQEAgc3RydWN0IFhlbkJsa0RldiB7CiAg
ICAgZ2Jvb2xlYW4gICAgICAgICAgICBmZWF0dXJlX2Rpc2NhcmQ7CiAgICAgZ2Jvb2xlYW4gICAg
ICAgICAgICBmZWF0dXJlX3BlcnNpc3RlbnQ7CiAgICAgR1RyZWUgICAgICAgICAgICAgICAqcGVy
c2lzdGVudF9nbnRzOworICAgIEdTTGlzdCAgICAgICAgICAgICAgKnBlcnNpc3RlbnRfcmVnaW9u
czsKICAgICB1bnNpZ25lZCBpbnQgICAgICAgIHBlcnNpc3RlbnRfZ250X2NvdW50OwogICAgIHVu
c2lnbmVkIGludCAgICAgICAgbWF4X2dyYW50czsKIApAQCAtMTc3LDYgKzE4NSwyMyBAQCBzdGF0
aWMgdm9pZCBkZXN0cm95X2dyYW50KGdwb2ludGVyIHBnbnQpCiAgICAgZ19mcmVlKGdyYW50KTsK
IH0KIAorc3RhdGljIHZvaWQgcmVtb3ZlX3BlcnNpc3RlbnRfcmVnaW9uKGdwb2ludGVyIGRhdGEs
IGdwb2ludGVyIGRldikKK3sKKyAgICBQZXJzaXN0ZW50UmVnaW9uICpyZWdpb24gPSBkYXRhOwor
ICAgIHN0cnVjdCBYZW5CbGtEZXYgKmJsa2RldiA9IGRldjsKKyAgICBYZW5HbnR0YWIgZ250ID0g
YmxrZGV2LT54ZW5kZXYuZ250dGFiZGV2OworCisgICAgaWYgKHhjX2dudHRhYl9tdW5tYXAoZ250
LCByZWdpb24tPmFkZHIsIHJlZ2lvbi0+bnVtKSAhPSAwKSB7CisgICAgICAgIHhlbl9iZV9wcmlu
dGYoJmJsa2Rldi0+eGVuZGV2LCAwLAorICAgICAgICAgICAgICAgICAgICAgICJ4Y19nbnR0YWJf
bXVubWFwIHJlZ2lvbiAlcCBmYWlsZWQ6ICVzXG4iLAorICAgICAgICAgICAgICAgICAgICAgIHJl
Z2lvbi0+YWRkciwgc3RyZXJyb3IoZXJybm8pKTsKKyAgICB9CisgICAgeGVuX2JlX3ByaW50Zigm
YmxrZGV2LT54ZW5kZXYsIDMsCisgICAgICAgICAgICAgICAgICAidW5tYXBwZWQgZ3JhbnQgcmVn
aW9uICVwIHdpdGggJWQgcGFnZXNcbiIsCisgICAgICAgICAgICAgICAgICByZWdpb24tPmFkZHIs
IHJlZ2lvbi0+bnVtKTsKKyAgICBnX2ZyZWUocmVnaW9uKTsKK30KKwogc3RhdGljIHN0cnVjdCBp
b3JlcSAqaW9yZXFfc3RhcnQoc3RydWN0IFhlbkJsa0RldiAqYmxrZGV2KQogewogICAgIHN0cnVj
dCBpb3JlcSAqaW9yZXEgPSBOVUxMOwpAQCAtMzQzLDYgKzM2OCw3IEBAIHN0YXRpYyBpbnQgaW9y
ZXFfbWFwKHN0cnVjdCBpb3JlcSAqaW9yZXEpCiAgICAgdm9pZCAqcGFnZVtCTEtJRl9NQVhfU0VH
TUVOVFNfUEVSX1JFUVVFU1RdOwogICAgIGludCBpLCBqLCBuZXdfbWFwcyA9IDA7CiAgICAgUGVy
c2lzdGVudEdyYW50ICpncmFudDsKKyAgICBQZXJzaXN0ZW50UmVnaW9uICpyZWdpb247CiAgICAg
LyogZG9taWRzIGFuZCByZWZzIHZhcmlhYmxlcyB3aWxsIGNvbnRhaW4gdGhlIGluZm9ybWF0aW9u
IG5lY2Vzc2FyeQogICAgICAqIHRvIG1hcCB0aGUgZ3JhbnRzIHRoYXQgYXJlIG5lZWRlZCB0byBm
dWxmaWxsIHRoaXMgcmVxdWVzdC4KICAgICAgKgpAQCAtNDIxLDcgKzQ0NywyMiBAQCBzdGF0aWMg
aW50IGlvcmVxX21hcChzdHJ1Y3QgaW9yZXEgKmlvcmVxKQogICAgICAgICAgICAgfQogICAgICAg
ICB9CiAgICAgfQotICAgIGlmIChpb3JlcS0+YmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsK
KyAgICBpZiAoaW9yZXEtPmJsa2Rldi0+ZmVhdHVyZV9wZXJzaXN0ZW50ICYmIG5ld19tYXBzICE9
IDAgJiYKKyAgICAgICAgKCFiYXRjaF9tYXBzIHx8IChpb3JlcS0+YmxrZGV2LT5wZXJzaXN0ZW50
X2dudF9jb3VudCArIG5ld19tYXBzIDw9CisgICAgICAgIGlvcmVxLT5ibGtkZXYtPm1heF9ncmFu
dHMpKSkgeworICAgICAgICAvKgorICAgICAgICAgKiBJZiB3ZSBhcmUgdXNpbmcgcGVyc2lzdGVu
dCBncmFudHMgYW5kIGJhdGNoIG1hcHBpbmdzIG9ubHkKKyAgICAgICAgICogYWRkIHRoZSBuZXcg
bWFwcyB0byB0aGUgbGlzdCBvZiBwZXJzaXN0ZW50IGdyYW50cyBpZiB0aGUgd2hvbGUKKyAgICAg
ICAgICogYXJlYSBjYW4gYmUgcGVyc2lzdGVudGx5IG1hcHBlZC4KKyAgICAgICAgICovCisgICAg
ICAgIGlmIChiYXRjaF9tYXBzKSB7CisgICAgICAgICAgICByZWdpb24gPSBnX21hbGxvYzAoc2l6
ZW9mKCpyZWdpb24pKTsKKyAgICAgICAgICAgIHJlZ2lvbi0+YWRkciA9IGlvcmVxLT5wYWdlczsK
KyAgICAgICAgICAgIHJlZ2lvbi0+bnVtID0gbmV3X21hcHM7CisgICAgICAgICAgICBpb3JlcS0+
YmxrZGV2LT5wZXJzaXN0ZW50X3JlZ2lvbnMgPSBnX3NsaXN0X2FwcGVuZCgKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW9yZXEtPmJsa2Rldi0+cGVyc2lzdGVu
dF9yZWdpb25zLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy
ZWdpb24pOworICAgICAgICB9CiAgICAgICAgIHdoaWxlICgoaW9yZXEtPmJsa2Rldi0+cGVyc2lz
dGVudF9nbnRfY291bnQgPCBpb3JlcS0+YmxrZGV2LT5tYXhfZ3JhbnRzKQogICAgICAgICAgICAg
ICAmJiBuZXdfbWFwcykgewogICAgICAgICAgICAgLyogR28gdGhyb3VnaCB0aGUgbGlzdCBvZiBu
ZXdseSBtYXBwZWQgZ3JhbnRzIGFuZCBhZGQgYXMgbWFueQpAQCAtNDQ3LDYgKzQ4OCw3IEBAIHN0
YXRpYyBpbnQgaW9yZXFfbWFwKHN0cnVjdCBpb3JlcSAqaW9yZXEpCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGdyYW50KTsKICAgICAgICAgICAgIGlvcmVxLT5ibGtkZXYtPnBlcnNpc3RlbnRf
Z250X2NvdW50Kys7CiAgICAgICAgIH0KKyAgICAgICAgYXNzZXJ0KCFiYXRjaF9tYXBzIHx8IG5l
d19tYXBzID09IDApOwogICAgIH0KICAgICBmb3IgKGkgPSAwOyBpIDwgaW9yZXEtPnYubmlvdjsg
aSsrKSB7CiAgICAgICAgIGlvcmVxLT52LmlvdltpXS5pb3ZfYmFzZSArPSAodWludHB0cl90KXBh
Z2VbaV07CkBAIC05NzEsNyArMTAxMywxMCBAQCBzdGF0aWMgaW50IGJsa19jb25uZWN0KHN0cnVj
dCBYZW5EZXZpY2UgKnhlbmRldikKICAgICAgICAgYmxrZGV2LT5tYXhfZ3JhbnRzID0gbWF4X3Jl
cXVlc3RzICogQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUOwogICAgICAgICBibGtkZXYt
PnBlcnNpc3RlbnRfZ250cyA9IGdfdHJlZV9uZXdfZnVsbCgoR0NvbXBhcmVEYXRhRnVuYylpbnRf
Y21wLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCwg
TlVMTCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJhdGNo
X21hcHMgPworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKEdE
ZXN0cm95Tm90aWZ5KWdfZnJlZSA6CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAoR0Rlc3Ryb3lOb3RpZnkpZGVzdHJveV9ncmFudCk7CisgICAgICAgIGJsa2Rl
di0+cGVyc2lzdGVudF9yZWdpb25zID0gTlVMTDsKICAgICAgICAgYmxrZGV2LT5wZXJzaXN0ZW50
X2dudF9jb3VudCA9IDA7CiAgICAgfQogCkBAIC0xMDAwLDYgKzEwNDUsMjYgQEAgc3RhdGljIHZv
aWQgYmxrX2Rpc2Nvbm5lY3Qoc3RydWN0IFhlbkRldmljZSAqeGVuZGV2KQogICAgICAgICBibGtk
ZXYtPmNudF9tYXAtLTsKICAgICAgICAgYmxrZGV2LT5zcmluZyA9IE5VTEw7CiAgICAgfQorCisg
ICAgLyoKKyAgICAgKiBVbm1hcCBwZXJzaXN0ZW50IGdyYW50cyBiZWZvcmUgc3dpdGNoaW5nIHRv
IHRoZSBjbG9zZWQgc3RhdGUKKyAgICAgKiBzbyB0aGUgZnJvbnRlbmQgY2FuIGZyZWUgdGhlbS4K
KyAgICAgKgorICAgICAqIEluIHRoZSAhYmF0Y2hfbWFwcyBjYXNlIGdfdHJlZV9kZXN0cm95IHdp
bGwgdGFrZSBjYXJlIG9mIHVubWFwcGluZworICAgICAqIHRoZSBncmFudCwgYnV0IGluIHRoZSBi
YXRjaF9tYXBzIGNhc2Ugd2UgbmVlZCB0byBpdGVyYXRlIG92ZXIgZXZlcnkKKyAgICAgKiByZWdp
b24gaW4gcGVyc2lzdGVudF9yZWdpb25zIGFuZCB1bm1hcCBpdC4KKyAgICAgKi8KKyAgICBpZiAo
YmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQpIHsKKyAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxr
ZGV2LT5wZXJzaXN0ZW50X2dudHMpOworICAgICAgICBhc3NlcnQoYmF0Y2hfbWFwcyB8fCBibGtk
ZXYtPnBlcnNpc3RlbnRfZ250X2NvdW50ID09IDApOworICAgICAgICBpZiAoYmF0Y2hfbWFwcykg
eworICAgICAgICAgICAgYmxrZGV2LT5wZXJzaXN0ZW50X2dudF9jb3VudCA9IDA7CisgICAgICAg
ICAgICBnX3NsaXN0X2ZvcmVhY2goYmxrZGV2LT5wZXJzaXN0ZW50X3JlZ2lvbnMsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgKEdGdW5jKXJlbW92ZV9wZXJzaXN0ZW50X3JlZ2lvbiwgYmxr
ZGV2KTsKKyAgICAgICAgICAgIGdfc2xpc3RfZnJlZShibGtkZXYtPnBlcnNpc3RlbnRfcmVnaW9u
cyk7CisgICAgICAgIH0KKyAgICAgICAgYmxrZGV2LT5mZWF0dXJlX3BlcnNpc3RlbnQgPSBmYWxz
ZTsKKyAgICB9CiB9CiAKIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhlbkRldmljZSAqeGVu
ZGV2KQpAQCAtMTAxMSwxMSArMTA3Niw2IEBAIHN0YXRpYyBpbnQgYmxrX2ZyZWUoc3RydWN0IFhl
bkRldmljZSAqeGVuZGV2KQogICAgICAgICBibGtfZGlzY29ubmVjdCh4ZW5kZXYpOwogICAgIH0K
IAotICAgIC8qIEZyZWUgcGVyc2lzdGVudCBncmFudHMgKi8KLSAgICBpZiAoYmxrZGV2LT5mZWF0
dXJlX3BlcnNpc3RlbnQpIHsKLSAgICAgICAgZ190cmVlX2Rlc3Ryb3koYmxrZGV2LT5wZXJzaXN0
ZW50X2dudHMpOwotICAgIH0KLQogICAgIHdoaWxlICghUUxJU1RfRU1QVFkoJmJsa2Rldi0+ZnJl
ZWxpc3QpKSB7CiAgICAgICAgIGlvcmVxID0gUUxJU1RfRklSU1QoJmJsa2Rldi0+ZnJlZWxpc3Qp
OwogICAgICAgICBRTElTVF9SRU1PVkUoaW9yZXEsIGxpc3QpOwotLSAKMS43LjEwLjQKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:30:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpF5K-0001Zs-RL; Fri, 14 Nov 2014 11:30:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpF5J-0001ZY-HS
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:30:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CB/77-09842-CD7E5645; Fri, 14 Nov 2014 11:30:36 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1415964635!12728352!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19927 invoked from network); 14 Nov 2014 11:30:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:30:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192811192"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 06:30:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpF59-0006kB-Kr;
	Fri, 14 Nov 2014 11:30:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Fri, 14 Nov 2014 11:30:09 +0000
Message-ID: <1415964611-20838-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: peter.maydell@linaro.org, Igor Mammedov <imammedo@redhat.com>,
	xen-devel@lists.xensource.com, Li Liang <liang.z.li@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PULL for-2.2 1/2] pc: piix4_pm: init legacy PCI
	hotplug when running 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

From: Igor Mammedov <imammedo@redhat.com>

If user starts QEMU with "-machine pc,accel=xen", then
compat property in xenfv won't work and it would cause error:
"Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set"
when PCI device is added with -device on QEMU CLI.

From: Igor Mammedov <imammedo@redhat.com>

In case of Xen instead of using compat property, just use the fact
that xen doesn't use QEMU's fw_cfg/acpi tables to switch piix4_pm
into legacy PCI hotplug mode when Xen is enabled.

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Li Liang <liang.z.li@intel.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
---
 hw/acpi/piix4.c   |    4 ++++
 hw/i386/pc_piix.c |   11 -----------
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 78c0a6d..481a16c 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -36,6 +36,7 @@
 #include "hw/mem/pc-dimm.h"
 #include "hw/acpi/memory_hotplug.h"
 #include "hw/acpi/acpi_dev_interface.h"
+#include "hw/xen/xen.h"
 
 //#define DEBUG
 
@@ -501,6 +502,9 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
     s->irq = sci_irq;
     s->smi_irq = smi_irq;
     s->kvm_enabled = kvm_enabled;
+    if (xen_enabled()) {
+        s->use_acpi_pci_hotplug = false;
+    }
 
     qdev_init_nofail(dev);
 
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index b559181..7bb97a4 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -916,17 +916,6 @@ static QEMUMachine xenfv_machine = {
     .max_cpus = HVM_MAX_VCPUS,
     .default_machine_opts = "accel=xen",
     .hot_add_cpu = pc_hot_add_cpu,
-    .compat_props = (GlobalProperty[]) {
-        /* xenfv has no fwcfg and so does not load acpi from QEMU.
-         * as such new acpi features don't work.
-         */
-        {
-            .driver   = "PIIX4_PM",
-            .property = "acpi-pci-hotplug-with-bridge-support",
-            .value    = "off",
-        },
-        { /* end of list */ }
-    },
 };
 #endif
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:33:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:33:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpF8T-000247-W4; Fri, 14 Nov 2014 11:33:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XpF8S-00023z-4m
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 11:33:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B6/A9-09936-F98E5645; Fri, 14 Nov 2014 11:33:51 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415964830!12754941!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32023 invoked from network); 14 Nov 2014 11:33:51 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:33:51 -0000
Received: by mail-wg0-f53.google.com with SMTP id b13so19145545wgh.40
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 03:33:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=9aoTp2cn4LgiYDY8s0tKv2Bek1LaKXI2YmyS1yVbsWw=;
	b=mIL1VqjV6jKmayQBV6p3B2vmwgb7mBvwBNzKavi3MT+Q77/R2stLZYCUhB52zbr/Pw
	/u7li2KbSrBAjUjflJ1ficWlzjFKkvgvwwD3yl1kjBQhmHV7Vbb0kfFJGhLr2xv8VOKE
	MnHOENIYuUgCKouuTXSwqEYRejbcxd1ozzPU/VOPEn/09J18IflOcKaSiROG50HtqFXX
	oc2qcuvUQUYUDDuSMGcOWuTVzkWo+N6v+2pvcwq2Qyo/ASDupUoC1lhEpukzQISeSNjV
	UoKL2FtGU578BDYmsYTkw4HzziFPWL+Bp0lJcvOEdNRVte3jc9Q7NYHkxITZ0VShtc8f
	Y4bA==
X-Gm-Message-State: ALoCoQmJIixMPP2JbKixGIkP6S4cpp5tMLdvtwhO5rZUgysGyyjYzRBRUFByvQNh1Zl42TGpBLXm
X-Received: by 10.180.212.110 with SMTP id nj14mr6702506wic.45.1415964830572; 
	Fri, 14 Nov 2014 03:33:50 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id bo1sm6551341wjc.18.2014.11.14.03.33.48
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 14 Nov 2014 03:33:49 -0800 (PST)
Message-ID: <5465E89C.1030701@linaro.org>
Date: Fri, 14 Nov 2014 11:33:48 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Thomas Leonard <talex5@gmail.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>	<1412328051-20015-3-git-send-email-talex5@gmail.com>	<1413889218.23337.24.camel@citrix.com>	<20141021215406.GJ3481@type.youpi.perso.aquilenet.fr>	<1413968619.20604.56.camel@citrix.com>	<5447ABE4.1030703@linaro.org>	<CAG4opy9QCRaMY41=M0HfK4vajvcE=nS+5P-L91itgOMDOBGS4w@mail.gmail.com>	<544FB580.7080809@linaro.org>	<CAG4opy-th0P+BBaRJOHeSP0jo=2hS1MqqVM2793q6NdB8jvEKA@mail.gmail.com>	<544FBB76.7050102@linaro.org>
	<CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>
In-Reply-To: <CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>
Content-Length: 6772
Cc: David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH ARM v8 2/4] mini-os: arm: interrupt
	controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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

SGkgVGhvbWFzLAoKT24gMTQvMTEvMjAxNCAxMDoyMiwgVGhvbWFzIExlb25hcmQgd3JvdGU6Cj4g
T24gMjggT2N0b2JlciAyMDE0IDE1OjUxLCBKdWxpZW4gR3JhbGwgPGp1bGllbi5ncmFsbEBsaW5h
cm8ub3JnPiB3cm90ZToKPj4gT24gMTAvMjgvMjAxNCAwMzo0MyBQTSwgVGhvbWFzIExlb25hcmQg
d3JvdGU6Cj4+PiBPbiAyOCBPY3RvYmVyIDIwMTQgMTU6MjUsIEp1bGllbiBHcmFsbCA8anVsaWVu
LmdyYWxsQGxpbmFyby5vcmc+IHdyb3RlOgo+Pj4+IE9uIDEwLzI4LzIwMTQgMDM6MTUgUE0sIFRo
b21hcyBMZW9uYXJkIHdyb3RlOgo+Pj4+PiBPbiAyMiBPY3RvYmVyIDIwMTQgMTQ6MDYsIEp1bGll
biBHcmFsbCA8anVsaWVuLmdyYWxsQGxpbmFyby5vcmc+IHdyb3RlOgo+Pj4+Pj4gT24gMTAvMjIv
MjAxNCAxMDowMyBBTSwgSWFuIENhbXBiZWxsIHdyb3RlOgo+Pj4+Pj4+IE9uIFR1ZSwgMjAxNC0x
MC0yMSBhdCAyMzo1NCArMDIwMCwgU2FtdWVsIFRoaWJhdWx0IHdyb3RlOgo+Pj4+Pj4+PiBJYW4g
Q2FtcGJlbGwsIGxlIFR1ZSAyMSBPY3QgMjAxNCAxMjowMDoxOCArMDEwMCwgYSDDqWNyaXQgOgo+
Pj4+Pj4+Pj4gT24gRnJpLCAyMDE0LTEwLTAzIGF0IDEwOjIwICswMTAwLCBUaG9tYXMgTGVvbmFy
ZCB3cm90ZToKPj4+Pj4+Pj4+PiArc3RhdGljIGlubGluZSB1aW50MzJfdCBSRUdfUkVBRDMyKHZv
bGF0aWxlIHVpbnQzMl90ICphZGRyKQo+Pj4+Pj4+Pj4+ICt7Cj4+Pj4+Pj4+Pj4gKyAgICB1aW50
MzJfdCB2YWx1ZTsKPj4+Pj4+Pj4+PiArICAgIF9fYXNtX18gX192b2xhdGlsZV9fKCJsZHIgJTAs
IFslMV0iOiI9JnIiKHZhbHVlKToiciIoYWRkcikpOwo+Pj4+Pj4+Pj4+ICsgICAgcm1iKCk7Cj4+
Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gSSdtIG5vdCAxMDAlIGNvbnZpbmNlZCB0aGF0IHlvdSBuZWVkIHRo
aXMgcm1iKCkuCj4+Pj4+Pgo+Pj4+Pj4gTW9zdCB0aGUgR0lDIGNvZGUgZG9lc24ndCByZXF1aXJl
IHJlYWQgYmFycmllciBidXQuLi4KPj4+Pj4+Cj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+ICsgICAgcmV0
dXJuIHZhbHVlOwo+Pj4+Pj4+Pj4+ICt9Cj4+Pj4+Pj4+Pj4gKwo+Pj4+Pj4+Pj4+ICtzdGF0aWMg
aW5saW5lIHZvaWQgUkVHX1dSSVRFMzIodm9sYXRpbGUgdWludDMyX3QgKmFkZHIsIHVuc2lnbmVk
IGludCB2YWx1ZSkKPj4+Pj4+Pj4+PiArewo+Pj4+Pj4+Pj4+ICsgICAgX19hc21fXyBfX3ZvbGF0
aWxlX18oInN0ciAlMCwgWyUxXSI6OiJyIih2YWx1ZSksICJyIihhZGRyKSk7Cj4+Pj4+Pj4+Pj4g
KyAgICB3bWIoKTsKPj4+Pj4+Pj4+PiArfQo+Pj4+Pj4KPj4+Pj4+IHdyaXRlIGJhcnJpZXIgbWF5
IGJlIG5lY2Vzc2FyeSBvbiBzb21lLCB3aGVyZSB3ZSBuZWVkIHRvIHdhaXQgdGhhdCBhbGwKPj4+
Pj4+IHdyaXRlIGhhcyBiZWVuIGRvbmUgYmVmb3JlIGRvaW5nIHRoaXMgb25lIChzdWNoIGFzIGVu
YWJsZSB0aGUgR0lDIC4uLikuCj4+Pj4+Pgo+Pj4+Pj4gU28gdGhpcyBmdW5jdGlvbiBpcyBidWdn
eS4gSXQgc2hvdWxkIGJlOgo+Pj4+Pj4KPj4+Pj4+IHdtYigpOwo+Pj4+Pj4gX19hc21fXyBfX3Zv
bGF0aWxlX18oLi4uLikuCj4+Pj4+Cj4+Pj4+IGdpY19pbml0IGRvZXMgYW4gZXhwbGljaXQgd21i
KCkgYmVmb3JlIGVuYWJsaW5nIHRoZSBHSUMgYW55d2F5LAo+Pj4+PiBhbHRob3VnaCBJJ20gbm90
IHJlYWxseSBzdXJlIHdoeSBpdCdzIG5lZWRlZCAodGhlc2UgYmFycmllcnMgYXJlIGZyb20KPj4+
Pj4gS2FyaW0ncyBvcmlnaW5hbCBjb2RlLCBzbyBJIGRvbid0IGtub3cgdGhlIG9yaWdpbmFsIHJl
YXNvbiBmb3IgdGhlbSkuCj4+Pj4+IFhlbiB3aWxsIGhhdmUgbWFya2VkIHRoZSBHSUMgbWVtb3J5
IGFzIGRldmljZSBtZW1vcnksIHNvIEkgZ3Vlc3Mgd2UncmUKPj4+Pj4gcHJvdGVjdGVkIGZyb20g
bWFueSBlZmZlY3RzICgiVGhlIG51bWJlciwgb3JkZXIgYW5kIHNpemVzIG9mIHRoZQo+Pj4+PiBh
Y2Nlc3NlcyBhcmUgbWFpbnRhaW5lZC4iKS4KPj4+Pgo+Pj4+IERldmljZSBtZW1vcnkgZG9lc24n
dCBtZWFuIHRoZSBiYXJyaWVyIGFyZSBub3QgbmVjZXNzYXJ5Li4uIFRoZSBiYXJyaWVycwo+Pj4+
IGFyZSB0aGVyZSBmb3IgdGhlIHdob2xlIG1lbW9yeSwgbm90IG9ubHkgdGhlIEdJQyBtZW1vcnku
Cj4+Pj4KPj4+PiBBIGNvbW1vbiB1c2UgY2FzZSBpcyBzZW5kaW5nIGFuIFNHSS4gWW91IG5lZWQg
dG8gZW5zdXJlIHRoYXQgZXZlcnkKPj4+PiByZWFkL3dyaXRlIGJlZm9yZSB0aGUgU0dJIHdpbGwg
YmUgc2VlbiBieSB0aGUgb3RoZXIgcHJvY2Vzc29ycy4KPj4+PiBPdGhlcndpc2UgdGhleSBtYXkg
bm90IHNlZSBjb3JyZWN0bHkgdGhlIGRhdGEuCj4+Pgo+Pj4gUmlnaHQsIGJ1dCBJIG1lYW4gaW4g
dGhlIGNvbnRleHQgb2YgdGhpcyBjb2RlLiBUaGUgb25seSB0aGluZ3Mgd2UncmUgZG9pbmcgYXJl
Ogo+Pj4KPj4+IC0gZW5hYmxpbmcgaW50ZXJydXB0cyAoaW4gZ2ljX2luaXQpCj4+Cj4+IFlvdSBu
ZWVkIHRvIHRha2UgY2FyZSBvZiB0aGUgYmFycmllci9sb2NrIGZvciBlbmFibGluZyBpbnRlcnJ1
cHRzLiBPdGhlcgo+PiBwcm9jZXNzb3IgbWF5IGJlIHByZXNlbnQgYXQgdGhhdCB0aW1lLgo+Pgo+
PiBUaG91Z2ggSUlSQywgbWluaS1vcyBmb3IgQVJNIGlzIG5vdCB5ZXQgU01QLgo+Cj4gSXQncyBk
aWZmaWN1bHQgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUgZG9uZSB0byBzdXBwb3J0IGNvZGUgdGhh
dAo+IGRvZXNuJ3QgZXhpc3QgeWV0LiBGb3IgZXhhbXBsZSwgd291bGQgZ2ljX2luaXQgYmUgY2Fs
bGVkIG9uY2UsIG9yIG9uY2UKPiBwZXIgcHJvY2Vzc29yPyBCZWZvcmUgb3IgYWZ0ZXIgdGhlIG90
aGVyIHByb2Nlc3NvcnMgYXJlIHN0YXJ0ZWQ/CgpTb21lIHBhcnQgb2YgdGhlIGNvZGUgbWF5YmUg
bmVjZXNzYXJ5OiBzZXR0aW5nIFBQSXMvU0dJcy4uLiBZb3UgY2FuIGdpdmUgCmEgbG9vayB0byBM
aW51eC9YZW4gR0lDIGRyaXZlcnMgdG8gaGF2ZSBhbiBpZGVhIG9uIHdoYXQgaXMgbmVjZXNzYXJ5
LgoKPj4+IC0gcmVhZGluZyBhbmQgYWNraW5nIGFuIGludGVycnVwdCAoaW4gZ2ljX2hhbmRsZXIp
Cj4+Cj4+IFlvdSBkb24ndCBjYXJlIGZvciB0aGlzIHBhcnQgYXMgaXQncyBwZXIgQ1BVLgo+Cj4g
SnVzdCB0byBjb25maXJtOiB5b3UgbWVhbiB0aGF0IHdyaXRpbmcgdG8gdGhlIEdJQyByZWdpc3Rl
cnMgaGFwcGVucwo+IGltbWVkaWF0ZWx5LCB3aXRob3V0IGJ1ZmZlcmluZz8gaS5lLiBjYWxsaW5n
IGdpY19lb2lyKCkgYW5kIHRoZW4KPiByZWVuYWJsaW5nIGludGVycnVwdHMgd29uJ3QgdHJpZ2dl
ciBhZ2FpbiBiZWNhdXNlIHRoZSBhY2sgaGFzbid0Cj4gcmVhY2hlZCB0aGUgR0lDIHlldD8KCllv
dSBkb24ndCBjYXJlIGlmIHRoZSBFT0kgdGFrZXMgZmV3IG1pbGlzZWNvbmRzIG1vcmUgdG8gcmVh
Y2ggdGhlIEdJQ0MgCmludGVyZmFjZS4gVGhlIHNhbWUgaW50ZXJydXB0IHdvbid0IHRyaWdnZXIg
dW50aWwgdGhlIEVPSSBoYXMgYmVlbiBoYW5kbGluZy4KCj4+IFsuLl0KPj4KPj4+IElmIGVuYWJs
aW5nIGludGVycnVwdHMgaXMgZGVsYXllZCBzbGlnaHRseSwgaXQgc2hvdWxkbid0IGhhdmUgYW55
Cj4+PiBlZmZlY3QgKGV2ZW4gaWYgd2UgZ2V0IHRvIGJsb2NrX2RvbWFpbiwgd2ZpIHdpbGwgZmx1
c2ggdGhlIHdyaXRlcykuCj4+Cj4+IFJlbHlpbmcgb24gYSBsYXRlciBmbHVzaCB0aGF0IGlzIGN1
cnJlbnRseSBleGlzdGluZyBpcyBub3QgdGhlIHJpZ2h0Cj4+IHRoaW5nIHRvIGRvLiBZb3UgZG9u
J3Qga25vdyBob3cgbWluaS1vcyB3aWxsIGV2b2x2ZS4KPj4KPj4gWW91IGhhdmUgdG8gY2hlY2sg
aWYgYmFycmllcnMgYXJlIG5lZWRlZCBldmVyeXdoZXJlLgo+Cj4gQ291bGQgeW91IGdpdmUgYSBj
b25jcmV0ZSBleGFtcGxlIG9mIHdoZXJlIG5vdCBoYXZpbmcgYSBiYXJyaWVyIHdvdWxkCj4gY2F1
c2UgYSBwcm9ibGVtPyBBcyBmYXIgYXMgSSBjYW4gc2VlOgo+Cj4gLSBJZiB0aGUgY2FsbGVyIG9m
IGdpY19pbml0IHJlcXVpcmVzIHNvbWV0aGluZyB0byByZWFjaCBSQU0sIGRpc2sgb3IKPiB3aGF0
ZXZlciBiZWZvcmUgaW50ZXJydXB0cyBhcmUgZW5hYmxlZCwgdGhlbiB0aGF0IGNhbGxlciBzaG91
bGQgYWRkCj4gdGhlIGJhcnJpZXIuIGdpYy5jIGNhbid0IGtub3cgd2hhdCBuZWVkcyBmbHVzaGlu
ZyBmaXJzdC4KCldoYXQgZG8geW91IG1lYW4gYnkgZmx1c2hpbmc/IENhY2hlPwoKZ2ljLmMgbWF5
IHJlcXVpcmUgdG8gcHV0IGRhdGEgaW4gUkFNIHRvby4uLiBhIGJhcnJpZXIgaW4gdGhlIElSUSAK
ZW5hYmxpbmcgY29kZSB3aWxsIG1ha2Ugc3VyZSB0aGF0IHRoZSBkYXRhIGlzIHNlZW4gYnkgdGhl
IG90aGVyIHByb2Nlc3Nvci4KCj4gLSBPcGVyYXRpb25zIHBlcmZvcm1lZCBieSBnaWMuYyBhcmUg
c3luY2hyb25vdXMsIGJlY2F1c2UgdGhleSB3cml0ZSB0bwo+IGRldmljZSBtZW1vcnkgKHNvIHRo
ZSBwcm9jZXNzb3IgY2FuJ3QgcmVvcmRlciB0aGVtKSBhbmQgdXNlIF9fYXNtX18KPiBfX3ZvbGF0
aWxlX18gKHByZXZlbnRpbmcgdGhlIGNvbXBpbGVyIGZyb20gcmVvcmRlcmluZyB0aGVtKS4gU28g
dGhlcmUKPiBzaG91bGQgYmUgbm8gbmVlZCBmb3IgYSBiYXJyaWVyIGFmdGVyd2FyZHMsIG9yIGlu
IGJldHdlZW4gb3BlcmF0aW9ucwo+IGVpdGhlci4KClRoZSBHSUN2MiBpcyBkaXZpZGVkIGluIDIg
cGFydHM6IEdJQ0MgYW5kIEdJQ0QuIFRoZSBmb3JtZXIgaXMgcGVyLWNwdSAKd2hpbGUgdGhlIGxh
dHRlciBpcyBzaGFyZWQuCgpJIGFncmVlIHRoYXQgRGV2aWNlIG1lbW9yeSBpcyBzeW5jaHJvbm91
cy4gQnV0IHdpdGggU01QIHlvdSBuZXZlciBrbm93IAp3aGljaCBwcm9jZXNzb3Igd2lsbCB3cml0
ZS9yZWFkIGZpcnN0IG9uIHRoaXMgcmVnaW9uLiBTbyB5b3UgaGF2ZSB0byAKdGFrZSBsb2NrIHRv
IG9yZGVyIHRoZW0uCgpSZWdhcmRzLAoKLS0gCkp1bGllbiBHcmFsbAoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:33:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:33:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpF8T-000247-W4; Fri, 14 Nov 2014 11:33:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XpF8S-00023z-4m
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 11:33:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B6/A9-09936-F98E5645; Fri, 14 Nov 2014 11:33:51 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415964830!12754941!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32023 invoked from network); 14 Nov 2014 11:33:51 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:33:51 -0000
Received: by mail-wg0-f53.google.com with SMTP id b13so19145545wgh.40
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 03:33:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=9aoTp2cn4LgiYDY8s0tKv2Bek1LaKXI2YmyS1yVbsWw=;
	b=mIL1VqjV6jKmayQBV6p3B2vmwgb7mBvwBNzKavi3MT+Q77/R2stLZYCUhB52zbr/Pw
	/u7li2KbSrBAjUjflJ1ficWlzjFKkvgvwwD3yl1kjBQhmHV7Vbb0kfFJGhLr2xv8VOKE
	MnHOENIYuUgCKouuTXSwqEYRejbcxd1ozzPU/VOPEn/09J18IflOcKaSiROG50HtqFXX
	oc2qcuvUQUYUDDuSMGcOWuTVzkWo+N6v+2pvcwq2Qyo/ASDupUoC1lhEpukzQISeSNjV
	UoKL2FtGU578BDYmsYTkw4HzziFPWL+Bp0lJcvOEdNRVte3jc9Q7NYHkxITZ0VShtc8f
	Y4bA==
X-Gm-Message-State: ALoCoQmJIixMPP2JbKixGIkP6S4cpp5tMLdvtwhO5rZUgysGyyjYzRBRUFByvQNh1Zl42TGpBLXm
X-Received: by 10.180.212.110 with SMTP id nj14mr6702506wic.45.1415964830572; 
	Fri, 14 Nov 2014 03:33:50 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id bo1sm6551341wjc.18.2014.11.14.03.33.48
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 14 Nov 2014 03:33:49 -0800 (PST)
Message-ID: <5465E89C.1030701@linaro.org>
Date: Fri, 14 Nov 2014 11:33:48 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Thomas Leonard <talex5@gmail.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>	<1412328051-20015-3-git-send-email-talex5@gmail.com>	<1413889218.23337.24.camel@citrix.com>	<20141021215406.GJ3481@type.youpi.perso.aquilenet.fr>	<1413968619.20604.56.camel@citrix.com>	<5447ABE4.1030703@linaro.org>	<CAG4opy9QCRaMY41=M0HfK4vajvcE=nS+5P-L91itgOMDOBGS4w@mail.gmail.com>	<544FB580.7080809@linaro.org>	<CAG4opy-th0P+BBaRJOHeSP0jo=2hS1MqqVM2793q6NdB8jvEKA@mail.gmail.com>	<544FBB76.7050102@linaro.org>
	<CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>
In-Reply-To: <CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>
Content-Length: 6772
Cc: David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH ARM v8 2/4] mini-os: arm: interrupt
	controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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

SGkgVGhvbWFzLAoKT24gMTQvMTEvMjAxNCAxMDoyMiwgVGhvbWFzIExlb25hcmQgd3JvdGU6Cj4g
T24gMjggT2N0b2JlciAyMDE0IDE1OjUxLCBKdWxpZW4gR3JhbGwgPGp1bGllbi5ncmFsbEBsaW5h
cm8ub3JnPiB3cm90ZToKPj4gT24gMTAvMjgvMjAxNCAwMzo0MyBQTSwgVGhvbWFzIExlb25hcmQg
d3JvdGU6Cj4+PiBPbiAyOCBPY3RvYmVyIDIwMTQgMTU6MjUsIEp1bGllbiBHcmFsbCA8anVsaWVu
LmdyYWxsQGxpbmFyby5vcmc+IHdyb3RlOgo+Pj4+IE9uIDEwLzI4LzIwMTQgMDM6MTUgUE0sIFRo
b21hcyBMZW9uYXJkIHdyb3RlOgo+Pj4+PiBPbiAyMiBPY3RvYmVyIDIwMTQgMTQ6MDYsIEp1bGll
biBHcmFsbCA8anVsaWVuLmdyYWxsQGxpbmFyby5vcmc+IHdyb3RlOgo+Pj4+Pj4gT24gMTAvMjIv
MjAxNCAxMDowMyBBTSwgSWFuIENhbXBiZWxsIHdyb3RlOgo+Pj4+Pj4+IE9uIFR1ZSwgMjAxNC0x
MC0yMSBhdCAyMzo1NCArMDIwMCwgU2FtdWVsIFRoaWJhdWx0IHdyb3RlOgo+Pj4+Pj4+PiBJYW4g
Q2FtcGJlbGwsIGxlIFR1ZSAyMSBPY3QgMjAxNCAxMjowMDoxOCArMDEwMCwgYSDDqWNyaXQgOgo+
Pj4+Pj4+Pj4gT24gRnJpLCAyMDE0LTEwLTAzIGF0IDEwOjIwICswMTAwLCBUaG9tYXMgTGVvbmFy
ZCB3cm90ZToKPj4+Pj4+Pj4+PiArc3RhdGljIGlubGluZSB1aW50MzJfdCBSRUdfUkVBRDMyKHZv
bGF0aWxlIHVpbnQzMl90ICphZGRyKQo+Pj4+Pj4+Pj4+ICt7Cj4+Pj4+Pj4+Pj4gKyAgICB1aW50
MzJfdCB2YWx1ZTsKPj4+Pj4+Pj4+PiArICAgIF9fYXNtX18gX192b2xhdGlsZV9fKCJsZHIgJTAs
IFslMV0iOiI9JnIiKHZhbHVlKToiciIoYWRkcikpOwo+Pj4+Pj4+Pj4+ICsgICAgcm1iKCk7Cj4+
Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gSSdtIG5vdCAxMDAlIGNvbnZpbmNlZCB0aGF0IHlvdSBuZWVkIHRo
aXMgcm1iKCkuCj4+Pj4+Pgo+Pj4+Pj4gTW9zdCB0aGUgR0lDIGNvZGUgZG9lc24ndCByZXF1aXJl
IHJlYWQgYmFycmllciBidXQuLi4KPj4+Pj4+Cj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+ICsgICAgcmV0
dXJuIHZhbHVlOwo+Pj4+Pj4+Pj4+ICt9Cj4+Pj4+Pj4+Pj4gKwo+Pj4+Pj4+Pj4+ICtzdGF0aWMg
aW5saW5lIHZvaWQgUkVHX1dSSVRFMzIodm9sYXRpbGUgdWludDMyX3QgKmFkZHIsIHVuc2lnbmVk
IGludCB2YWx1ZSkKPj4+Pj4+Pj4+PiArewo+Pj4+Pj4+Pj4+ICsgICAgX19hc21fXyBfX3ZvbGF0
aWxlX18oInN0ciAlMCwgWyUxXSI6OiJyIih2YWx1ZSksICJyIihhZGRyKSk7Cj4+Pj4+Pj4+Pj4g
KyAgICB3bWIoKTsKPj4+Pj4+Pj4+PiArfQo+Pj4+Pj4KPj4+Pj4+IHdyaXRlIGJhcnJpZXIgbWF5
IGJlIG5lY2Vzc2FyeSBvbiBzb21lLCB3aGVyZSB3ZSBuZWVkIHRvIHdhaXQgdGhhdCBhbGwKPj4+
Pj4+IHdyaXRlIGhhcyBiZWVuIGRvbmUgYmVmb3JlIGRvaW5nIHRoaXMgb25lIChzdWNoIGFzIGVu
YWJsZSB0aGUgR0lDIC4uLikuCj4+Pj4+Pgo+Pj4+Pj4gU28gdGhpcyBmdW5jdGlvbiBpcyBidWdn
eS4gSXQgc2hvdWxkIGJlOgo+Pj4+Pj4KPj4+Pj4+IHdtYigpOwo+Pj4+Pj4gX19hc21fXyBfX3Zv
bGF0aWxlX18oLi4uLikuCj4+Pj4+Cj4+Pj4+IGdpY19pbml0IGRvZXMgYW4gZXhwbGljaXQgd21i
KCkgYmVmb3JlIGVuYWJsaW5nIHRoZSBHSUMgYW55d2F5LAo+Pj4+PiBhbHRob3VnaCBJJ20gbm90
IHJlYWxseSBzdXJlIHdoeSBpdCdzIG5lZWRlZCAodGhlc2UgYmFycmllcnMgYXJlIGZyb20KPj4+
Pj4gS2FyaW0ncyBvcmlnaW5hbCBjb2RlLCBzbyBJIGRvbid0IGtub3cgdGhlIG9yaWdpbmFsIHJl
YXNvbiBmb3IgdGhlbSkuCj4+Pj4+IFhlbiB3aWxsIGhhdmUgbWFya2VkIHRoZSBHSUMgbWVtb3J5
IGFzIGRldmljZSBtZW1vcnksIHNvIEkgZ3Vlc3Mgd2UncmUKPj4+Pj4gcHJvdGVjdGVkIGZyb20g
bWFueSBlZmZlY3RzICgiVGhlIG51bWJlciwgb3JkZXIgYW5kIHNpemVzIG9mIHRoZQo+Pj4+PiBh
Y2Nlc3NlcyBhcmUgbWFpbnRhaW5lZC4iKS4KPj4+Pgo+Pj4+IERldmljZSBtZW1vcnkgZG9lc24n
dCBtZWFuIHRoZSBiYXJyaWVyIGFyZSBub3QgbmVjZXNzYXJ5Li4uIFRoZSBiYXJyaWVycwo+Pj4+
IGFyZSB0aGVyZSBmb3IgdGhlIHdob2xlIG1lbW9yeSwgbm90IG9ubHkgdGhlIEdJQyBtZW1vcnku
Cj4+Pj4KPj4+PiBBIGNvbW1vbiB1c2UgY2FzZSBpcyBzZW5kaW5nIGFuIFNHSS4gWW91IG5lZWQg
dG8gZW5zdXJlIHRoYXQgZXZlcnkKPj4+PiByZWFkL3dyaXRlIGJlZm9yZSB0aGUgU0dJIHdpbGwg
YmUgc2VlbiBieSB0aGUgb3RoZXIgcHJvY2Vzc29ycy4KPj4+PiBPdGhlcndpc2UgdGhleSBtYXkg
bm90IHNlZSBjb3JyZWN0bHkgdGhlIGRhdGEuCj4+Pgo+Pj4gUmlnaHQsIGJ1dCBJIG1lYW4gaW4g
dGhlIGNvbnRleHQgb2YgdGhpcyBjb2RlLiBUaGUgb25seSB0aGluZ3Mgd2UncmUgZG9pbmcgYXJl
Ogo+Pj4KPj4+IC0gZW5hYmxpbmcgaW50ZXJydXB0cyAoaW4gZ2ljX2luaXQpCj4+Cj4+IFlvdSBu
ZWVkIHRvIHRha2UgY2FyZSBvZiB0aGUgYmFycmllci9sb2NrIGZvciBlbmFibGluZyBpbnRlcnJ1
cHRzLiBPdGhlcgo+PiBwcm9jZXNzb3IgbWF5IGJlIHByZXNlbnQgYXQgdGhhdCB0aW1lLgo+Pgo+
PiBUaG91Z2ggSUlSQywgbWluaS1vcyBmb3IgQVJNIGlzIG5vdCB5ZXQgU01QLgo+Cj4gSXQncyBk
aWZmaWN1bHQgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUgZG9uZSB0byBzdXBwb3J0IGNvZGUgdGhh
dAo+IGRvZXNuJ3QgZXhpc3QgeWV0LiBGb3IgZXhhbXBsZSwgd291bGQgZ2ljX2luaXQgYmUgY2Fs
bGVkIG9uY2UsIG9yIG9uY2UKPiBwZXIgcHJvY2Vzc29yPyBCZWZvcmUgb3IgYWZ0ZXIgdGhlIG90
aGVyIHByb2Nlc3NvcnMgYXJlIHN0YXJ0ZWQ/CgpTb21lIHBhcnQgb2YgdGhlIGNvZGUgbWF5YmUg
bmVjZXNzYXJ5OiBzZXR0aW5nIFBQSXMvU0dJcy4uLiBZb3UgY2FuIGdpdmUgCmEgbG9vayB0byBM
aW51eC9YZW4gR0lDIGRyaXZlcnMgdG8gaGF2ZSBhbiBpZGVhIG9uIHdoYXQgaXMgbmVjZXNzYXJ5
LgoKPj4+IC0gcmVhZGluZyBhbmQgYWNraW5nIGFuIGludGVycnVwdCAoaW4gZ2ljX2hhbmRsZXIp
Cj4+Cj4+IFlvdSBkb24ndCBjYXJlIGZvciB0aGlzIHBhcnQgYXMgaXQncyBwZXIgQ1BVLgo+Cj4g
SnVzdCB0byBjb25maXJtOiB5b3UgbWVhbiB0aGF0IHdyaXRpbmcgdG8gdGhlIEdJQyByZWdpc3Rl
cnMgaGFwcGVucwo+IGltbWVkaWF0ZWx5LCB3aXRob3V0IGJ1ZmZlcmluZz8gaS5lLiBjYWxsaW5n
IGdpY19lb2lyKCkgYW5kIHRoZW4KPiByZWVuYWJsaW5nIGludGVycnVwdHMgd29uJ3QgdHJpZ2dl
ciBhZ2FpbiBiZWNhdXNlIHRoZSBhY2sgaGFzbid0Cj4gcmVhY2hlZCB0aGUgR0lDIHlldD8KCllv
dSBkb24ndCBjYXJlIGlmIHRoZSBFT0kgdGFrZXMgZmV3IG1pbGlzZWNvbmRzIG1vcmUgdG8gcmVh
Y2ggdGhlIEdJQ0MgCmludGVyZmFjZS4gVGhlIHNhbWUgaW50ZXJydXB0IHdvbid0IHRyaWdnZXIg
dW50aWwgdGhlIEVPSSBoYXMgYmVlbiBoYW5kbGluZy4KCj4+IFsuLl0KPj4KPj4+IElmIGVuYWJs
aW5nIGludGVycnVwdHMgaXMgZGVsYXllZCBzbGlnaHRseSwgaXQgc2hvdWxkbid0IGhhdmUgYW55
Cj4+PiBlZmZlY3QgKGV2ZW4gaWYgd2UgZ2V0IHRvIGJsb2NrX2RvbWFpbiwgd2ZpIHdpbGwgZmx1
c2ggdGhlIHdyaXRlcykuCj4+Cj4+IFJlbHlpbmcgb24gYSBsYXRlciBmbHVzaCB0aGF0IGlzIGN1
cnJlbnRseSBleGlzdGluZyBpcyBub3QgdGhlIHJpZ2h0Cj4+IHRoaW5nIHRvIGRvLiBZb3UgZG9u
J3Qga25vdyBob3cgbWluaS1vcyB3aWxsIGV2b2x2ZS4KPj4KPj4gWW91IGhhdmUgdG8gY2hlY2sg
aWYgYmFycmllcnMgYXJlIG5lZWRlZCBldmVyeXdoZXJlLgo+Cj4gQ291bGQgeW91IGdpdmUgYSBj
b25jcmV0ZSBleGFtcGxlIG9mIHdoZXJlIG5vdCBoYXZpbmcgYSBiYXJyaWVyIHdvdWxkCj4gY2F1
c2UgYSBwcm9ibGVtPyBBcyBmYXIgYXMgSSBjYW4gc2VlOgo+Cj4gLSBJZiB0aGUgY2FsbGVyIG9m
IGdpY19pbml0IHJlcXVpcmVzIHNvbWV0aGluZyB0byByZWFjaCBSQU0sIGRpc2sgb3IKPiB3aGF0
ZXZlciBiZWZvcmUgaW50ZXJydXB0cyBhcmUgZW5hYmxlZCwgdGhlbiB0aGF0IGNhbGxlciBzaG91
bGQgYWRkCj4gdGhlIGJhcnJpZXIuIGdpYy5jIGNhbid0IGtub3cgd2hhdCBuZWVkcyBmbHVzaGlu
ZyBmaXJzdC4KCldoYXQgZG8geW91IG1lYW4gYnkgZmx1c2hpbmc/IENhY2hlPwoKZ2ljLmMgbWF5
IHJlcXVpcmUgdG8gcHV0IGRhdGEgaW4gUkFNIHRvby4uLiBhIGJhcnJpZXIgaW4gdGhlIElSUSAK
ZW5hYmxpbmcgY29kZSB3aWxsIG1ha2Ugc3VyZSB0aGF0IHRoZSBkYXRhIGlzIHNlZW4gYnkgdGhl
IG90aGVyIHByb2Nlc3Nvci4KCj4gLSBPcGVyYXRpb25zIHBlcmZvcm1lZCBieSBnaWMuYyBhcmUg
c3luY2hyb25vdXMsIGJlY2F1c2UgdGhleSB3cml0ZSB0bwo+IGRldmljZSBtZW1vcnkgKHNvIHRo
ZSBwcm9jZXNzb3IgY2FuJ3QgcmVvcmRlciB0aGVtKSBhbmQgdXNlIF9fYXNtX18KPiBfX3ZvbGF0
aWxlX18gKHByZXZlbnRpbmcgdGhlIGNvbXBpbGVyIGZyb20gcmVvcmRlcmluZyB0aGVtKS4gU28g
dGhlcmUKPiBzaG91bGQgYmUgbm8gbmVlZCBmb3IgYSBiYXJyaWVyIGFmdGVyd2FyZHMsIG9yIGlu
IGJldHdlZW4gb3BlcmF0aW9ucwo+IGVpdGhlci4KClRoZSBHSUN2MiBpcyBkaXZpZGVkIGluIDIg
cGFydHM6IEdJQ0MgYW5kIEdJQ0QuIFRoZSBmb3JtZXIgaXMgcGVyLWNwdSAKd2hpbGUgdGhlIGxh
dHRlciBpcyBzaGFyZWQuCgpJIGFncmVlIHRoYXQgRGV2aWNlIG1lbW9yeSBpcyBzeW5jaHJvbm91
cy4gQnV0IHdpdGggU01QIHlvdSBuZXZlciBrbm93IAp3aGljaCBwcm9jZXNzb3Igd2lsbCB3cml0
ZS9yZWFkIGZpcnN0IG9uIHRoaXMgcmVnaW9uLiBTbyB5b3UgaGF2ZSB0byAKdGFrZSBsb2NrIHRv
IG9yZGVyIHRoZW0uCgpSZWdhcmRzLAoKLS0gCkp1bGllbiBHcmFsbAoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:41:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:41:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpFFp-0002Uq-La; Fri, 14 Nov 2014 11:41:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpFFn-0002Uk-Le
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:41:27 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	53/37-09936-76AE5645; Fri, 14 Nov 2014 11:41:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415965285!12757448!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25225 invoked from network); 14 Nov 2014 11:41:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:41:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191347919"
Message-ID: <5465EA63.3010007@citrix.com>
Date: Fri, 14 Nov 2014 11:41:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xensource.com>,
	<jbeulich@suse.com>, <konrad.wilk@oracle.com>, <david.vrabel@citrix.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-2-git-send-email-jgross@suse.com>
In-Reply-To: <1415957846-22703-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 09:37, Juergen Gross wrote:
> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
> currently contains the mfn of the top level page frame of the 3 level
> p2m tree, which is used by the Xen tools during saving and restoring
> (and live migration) of pv domains and for crash dump analysis. With
> three levels of the p2m tree it is possible to support up to 512 GB of
> RAM for a 64 bit pv domain.
>
> A 32 bit pv domain can support more, as each memory page can hold 1024
> instead of 512 entries, leading to a limit of 4 TB.
>
> To be able to support more RAM on x86-64 switch to a virtual mapped
> p2m list.
>
> This patch expands struct arch_shared_info with a new p2m list virtual
> address and the mfn of the page table root. The new information is
> indicated by the domain to be valid by storing ~0UL into
> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of this
> feature by a new flag XENFEAT_virtual_p2m.

How do you envisage this being used?  Are you expecting the tools to do
manual pagetable walks using xc_map_foreign_xxx() ?

~Andrew

> ---
>  xen/include/public/arch-x86/xen.h | 7 ++++++-
>  xen/include/public/features.h     | 3 +++
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
> index f35804b..b0f85a9 100644
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -224,7 +224,12 @@ struct arch_shared_info {
>      /* Frame containing list of mfns containing list of mfns containing p2m. */
>      xen_pfn_t     pfn_to_mfn_frame_list_list;
>      unsigned long nmi_reason;
> -    uint64_t pad[32];
> +    /*
> +     * Following two fields are valid if pfn_to_mfn_frame_list_list contains
> +     * ~0UL.
> +     */
> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
> +    unsigned long p2m_as_root;  /* mfn of the top level page table */
>  };
>  typedef struct arch_shared_info arch_shared_info_t;
>  
> diff --git a/xen/include/public/features.h b/xen/include/public/features.h
> index 16d92aa..ff0b82d 100644
> --- a/xen/include/public/features.h
> +++ b/xen/include/public/features.h
> @@ -99,6 +99,9 @@
>  #define XENFEAT_grant_map_identity        12
>   */
>  
> +/* x86: guest may specify virtual address of p2m list */
> +#define XENFEAT_virtual_p2m               13
> +
>  #define XENFEAT_NR_SUBMAPS 1
>  
>  #endif /* __XEN_PUBLIC_FEATURES_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:41:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:41:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpFFp-0002Uq-La; Fri, 14 Nov 2014 11:41:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpFFn-0002Uk-Le
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:41:27 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	53/37-09936-76AE5645; Fri, 14 Nov 2014 11:41:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415965285!12757448!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25225 invoked from network); 14 Nov 2014 11:41:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:41:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191347919"
Message-ID: <5465EA63.3010007@citrix.com>
Date: Fri, 14 Nov 2014 11:41:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xensource.com>,
	<jbeulich@suse.com>, <konrad.wilk@oracle.com>, <david.vrabel@citrix.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-2-git-send-email-jgross@suse.com>
In-Reply-To: <1415957846-22703-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 09:37, Juergen Gross wrote:
> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
> currently contains the mfn of the top level page frame of the 3 level
> p2m tree, which is used by the Xen tools during saving and restoring
> (and live migration) of pv domains and for crash dump analysis. With
> three levels of the p2m tree it is possible to support up to 512 GB of
> RAM for a 64 bit pv domain.
>
> A 32 bit pv domain can support more, as each memory page can hold 1024
> instead of 512 entries, leading to a limit of 4 TB.
>
> To be able to support more RAM on x86-64 switch to a virtual mapped
> p2m list.
>
> This patch expands struct arch_shared_info with a new p2m list virtual
> address and the mfn of the page table root. The new information is
> indicated by the domain to be valid by storing ~0UL into
> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of this
> feature by a new flag XENFEAT_virtual_p2m.

How do you envisage this being used?  Are you expecting the tools to do
manual pagetable walks using xc_map_foreign_xxx() ?

~Andrew

> ---
>  xen/include/public/arch-x86/xen.h | 7 ++++++-
>  xen/include/public/features.h     | 3 +++
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
> index f35804b..b0f85a9 100644
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -224,7 +224,12 @@ struct arch_shared_info {
>      /* Frame containing list of mfns containing list of mfns containing p2m. */
>      xen_pfn_t     pfn_to_mfn_frame_list_list;
>      unsigned long nmi_reason;
> -    uint64_t pad[32];
> +    /*
> +     * Following two fields are valid if pfn_to_mfn_frame_list_list contains
> +     * ~0UL.
> +     */
> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
> +    unsigned long p2m_as_root;  /* mfn of the top level page table */
>  };
>  typedef struct arch_shared_info arch_shared_info_t;
>  
> diff --git a/xen/include/public/features.h b/xen/include/public/features.h
> index 16d92aa..ff0b82d 100644
> --- a/xen/include/public/features.h
> +++ b/xen/include/public/features.h
> @@ -99,6 +99,9 @@
>  #define XENFEAT_grant_map_identity        12
>   */
>  
> +/* x86: guest may specify virtual address of p2m list */
> +#define XENFEAT_virtual_p2m               13
> +
>  #define XENFEAT_NR_SUBMAPS 1
>  
>  #endif /* __XEN_PUBLIC_FEATURES_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:43:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11: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 1XpFHR-0002rc-4H; Fri, 14 Nov 2014 11:43: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 1XpFHQ-0002rP-3l
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 11:43:08 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	AD/56-14214-BCAE5645; Fri, 14 Nov 2014 11:43:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415965385!11379052!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25787 invoked from network); 14 Nov 2014 11:43:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:43:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191348151"
Message-ID: <1415965353.7113.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 14 Nov 2014 11:42:33 +0000
In-Reply-To: <5465E89C.1030701@linaro.org>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-3-git-send-email-talex5@gmail.com>
	<1413889218.23337.24.camel@citrix.com>
	<20141021215406.GJ3481@type.youpi.perso.aquilenet.fr>
	<1413968619.20604.56.camel@citrix.com>	<5447ABE4.1030703@linaro.org>
	<CAG4opy9QCRaMY41=M0HfK4vajvcE=nS+5P-L91itgOMDOBGS4w@mail.gmail.com>
	<544FB580.7080809@linaro.org>
	<CAG4opy-th0P+BBaRJOHeSP0jo=2hS1MqqVM2793q6NdB8jvEKA@mail.gmail.com>
	<544FBB76.7050102@linaro.org>
	<CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>
	<5465E89C.1030701@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Thomas Leonard <talex5@gmail.com>, David Scott <Dave.Scott@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 2/4] mini-os: arm: interrupt
 controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 11:33 +0000, Julien Grall wrote:
> >> Though IIRC, mini-os for ARM is not yet SMP.
> >
> > It's difficult to see what needs to be done to support code that
> > doesn't exist yet. For example, would gic_init be called once, or once
> > per processor? Before or after the other processors are started?
> 
> Some part of the code maybe necessary: setting PPIs/SGIs... You can give 
> a look to Linux/Xen GIC drivers to have an idea on what is necessary.

This would be necessary as part of the port of mini-os to support SMP. I
don't see why it should be necessary now, going to SMP is surely going
to require a bunch of refactoring in other places too (Xen itself
certainly did).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:43:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11: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 1XpFHR-0002rc-4H; Fri, 14 Nov 2014 11:43: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 1XpFHQ-0002rP-3l
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 11:43:08 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	AD/56-14214-BCAE5645; Fri, 14 Nov 2014 11:43:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415965385!11379052!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25787 invoked from network); 14 Nov 2014 11:43:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:43:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191348151"
Message-ID: <1415965353.7113.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 14 Nov 2014 11:42:33 +0000
In-Reply-To: <5465E89C.1030701@linaro.org>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-3-git-send-email-talex5@gmail.com>
	<1413889218.23337.24.camel@citrix.com>
	<20141021215406.GJ3481@type.youpi.perso.aquilenet.fr>
	<1413968619.20604.56.camel@citrix.com>	<5447ABE4.1030703@linaro.org>
	<CAG4opy9QCRaMY41=M0HfK4vajvcE=nS+5P-L91itgOMDOBGS4w@mail.gmail.com>
	<544FB580.7080809@linaro.org>
	<CAG4opy-th0P+BBaRJOHeSP0jo=2hS1MqqVM2793q6NdB8jvEKA@mail.gmail.com>
	<544FBB76.7050102@linaro.org>
	<CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>
	<5465E89C.1030701@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Thomas Leonard <talex5@gmail.com>, David Scott <Dave.Scott@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 2/4] mini-os: arm: interrupt
 controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 11:33 +0000, Julien Grall wrote:
> >> Though IIRC, mini-os for ARM is not yet SMP.
> >
> > It's difficult to see what needs to be done to support code that
> > doesn't exist yet. For example, would gic_init be called once, or once
> > per processor? Before or after the other processors are started?
> 
> Some part of the code maybe necessary: setting PPIs/SGIs... You can give 
> a look to Linux/Xen GIC drivers to have an idea on what is necessary.

This would be necessary as part of the port of mini-os to support SMP. I
don't see why it should be necessary now, going to SMP is surely going
to require a bunch of refactoring in other places too (Xen itself
certainly did).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:48:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:48:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpFMY-00036h-T4; Fri, 14 Nov 2014 11:48:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XpFMX-00036b-DO
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 11:48:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E6/D3-09936-80CE5645; Fri, 14 Nov 2014 11:48:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415965704!12697498!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25205 invoked from network); 14 Nov 2014 11:48:24 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:48:24 -0000
Received: by mail-wi0-f170.google.com with SMTP id r20so4844942wiv.5
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 03:48:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=9gsAXi2kqUxazkRbxmwPeX+I3AEkRzKk9Ae6jvOseBk=;
	b=mAdNfC02w3WtGBPxBu0lIax8sm7hbXVi4iE6EAPE/2GvHhvn5RZdh481B8GOX2APDv
	UPNUdUKu/SCpGzWExhjdzTvJlZEN3XbttSwZiRE2In4yRvnep+fnRXg7BQgY6iFG6J+S
	Fcs5h3fAdHBubjB6eoOEAosTFJlL3govxD25QNdLR1gQW3HsC6LMrM4aTuhivnrad7U9
	JwrX7FIC6mdIRGlR3RWGu52IZR3VNmamHwAaTf20BnIEIorRqkWXjBz3piijErNgAyNw
	hbr7Bn7oGv2K3MqCtUjc2HiVXJTkBUy0CtpxlL4psUB2tsJ9bW8p1pD7BSdKrYZkoqlI
	yswQ==
X-Gm-Message-State: ALoCoQnFS815pgNe9tMfnuFu/ujAatTUyJzuvJBffpmLWj7R+/KtSsotSFtcu4V7whWPQxxy5Y6p
X-Received: by 10.194.47.226 with SMTP id g2mr12966950wjn.68.1415965703960;
	Fri, 14 Nov 2014 03:48:23 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id w5sm3117689wif.18.2014.11.14.03.48.22
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 14 Nov 2014 03:48:22 -0800 (PST)
Message-ID: <5465EC05.8060801@linaro.org>
Date: Fri, 14 Nov 2014 11:48:21 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>		<1412328051-20015-3-git-send-email-talex5@gmail.com>		<1413889218.23337.24.camel@citrix.com>		<20141021215406.GJ3481@type.youpi.perso.aquilenet.fr>		<1413968619.20604.56.camel@citrix.com>	<5447ABE4.1030703@linaro.org>		<CAG4opy9QCRaMY41=M0HfK4vajvcE=nS+5P-L91itgOMDOBGS4w@mail.gmail.com>		<544FB580.7080809@linaro.org>		<CAG4opy-th0P+BBaRJOHeSP0jo=2hS1MqqVM2793q6NdB8jvEKA@mail.gmail.com>		<544FBB76.7050102@linaro.org>	
	<CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>	
	<5465E89C.1030701@linaro.org> <1415965353.7113.16.camel@citrix.com>
In-Reply-To: <1415965353.7113.16.camel@citrix.com>
Cc: Thomas Leonard <talex5@gmail.com>, David Scott <Dave.Scott@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 2/4] mini-os: arm: interrupt
	controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 14/11/2014 11:42, Ian Campbell wrote:
> On Fri, 2014-11-14 at 11:33 +0000, Julien Grall wrote:
>>>> Though IIRC, mini-os for ARM is not yet SMP.
>>>
>>> It's difficult to see what needs to be done to support code that
>>> doesn't exist yet. For example, would gic_init be called once, or once
>>> per processor? Before or after the other processors are started?
>>
>> Some part of the code maybe necessary: setting PPIs/SGIs... You can give
>> a look to Linux/Xen GIC drivers to have an idea on what is necessary.
>
> This would be necessary as part of the port of mini-os to support SMP. I
> don't see why it should be necessary now, going to SMP is surely going
> to require a bunch of refactoring in other places too (Xen itself
> certainly did).

I just answered to his question. I didn't asked for changing this code 
right now.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:48:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11:48:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpFMY-00036h-T4; Fri, 14 Nov 2014 11:48:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XpFMX-00036b-DO
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 11:48:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E6/D3-09936-80CE5645; Fri, 14 Nov 2014 11:48:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415965704!12697498!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25205 invoked from network); 14 Nov 2014 11:48:24 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:48:24 -0000
Received: by mail-wi0-f170.google.com with SMTP id r20so4844942wiv.5
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 03:48:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=9gsAXi2kqUxazkRbxmwPeX+I3AEkRzKk9Ae6jvOseBk=;
	b=mAdNfC02w3WtGBPxBu0lIax8sm7hbXVi4iE6EAPE/2GvHhvn5RZdh481B8GOX2APDv
	UPNUdUKu/SCpGzWExhjdzTvJlZEN3XbttSwZiRE2In4yRvnep+fnRXg7BQgY6iFG6J+S
	Fcs5h3fAdHBubjB6eoOEAosTFJlL3govxD25QNdLR1gQW3HsC6LMrM4aTuhivnrad7U9
	JwrX7FIC6mdIRGlR3RWGu52IZR3VNmamHwAaTf20BnIEIorRqkWXjBz3piijErNgAyNw
	hbr7Bn7oGv2K3MqCtUjc2HiVXJTkBUy0CtpxlL4psUB2tsJ9bW8p1pD7BSdKrYZkoqlI
	yswQ==
X-Gm-Message-State: ALoCoQnFS815pgNe9tMfnuFu/ujAatTUyJzuvJBffpmLWj7R+/KtSsotSFtcu4V7whWPQxxy5Y6p
X-Received: by 10.194.47.226 with SMTP id g2mr12966950wjn.68.1415965703960;
	Fri, 14 Nov 2014 03:48:23 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id w5sm3117689wif.18.2014.11.14.03.48.22
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 14 Nov 2014 03:48:22 -0800 (PST)
Message-ID: <5465EC05.8060801@linaro.org>
Date: Fri, 14 Nov 2014 11:48:21 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>		<1412328051-20015-3-git-send-email-talex5@gmail.com>		<1413889218.23337.24.camel@citrix.com>		<20141021215406.GJ3481@type.youpi.perso.aquilenet.fr>		<1413968619.20604.56.camel@citrix.com>	<5447ABE4.1030703@linaro.org>		<CAG4opy9QCRaMY41=M0HfK4vajvcE=nS+5P-L91itgOMDOBGS4w@mail.gmail.com>		<544FB580.7080809@linaro.org>		<CAG4opy-th0P+BBaRJOHeSP0jo=2hS1MqqVM2793q6NdB8jvEKA@mail.gmail.com>		<544FBB76.7050102@linaro.org>	
	<CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>	
	<5465E89C.1030701@linaro.org> <1415965353.7113.16.camel@citrix.com>
In-Reply-To: <1415965353.7113.16.camel@citrix.com>
Cc: Thomas Leonard <talex5@gmail.com>, David Scott <Dave.Scott@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 2/4] mini-os: arm: interrupt
	controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 14/11/2014 11:42, Ian Campbell wrote:
> On Fri, 2014-11-14 at 11:33 +0000, Julien Grall wrote:
>>>> Though IIRC, mini-os for ARM is not yet SMP.
>>>
>>> It's difficult to see what needs to be done to support code that
>>> doesn't exist yet. For example, would gic_init be called once, or once
>>> per processor? Before or after the other processors are started?
>>
>> Some part of the code maybe necessary: setting PPIs/SGIs... You can give
>> a look to Linux/Xen GIC drivers to have an idea on what is necessary.
>
> This would be necessary as part of the port of mini-os to support SMP. I
> don't see why it should be necessary now, going to SMP is surely going
> to require a bunch of refactoring in other places too (Xen itself
> certainly did).

I just answered to his question. I didn't asked for changing this code 
right now.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:58:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11: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 1XpFW1-0003Xy-0V; Fri, 14 Nov 2014 11:58:13 +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 1XpFVz-0003Xt-M3
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:58:11 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	60/EF-26652-25EE5645; Fri, 14 Nov 2014 11:58:10 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415966289!11418976!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18649 invoked from network); 14 Nov 2014 11:58:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:58:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192816416"
Message-ID: <5465EE4E.2010206@citrix.com>
Date: Fri, 14 Nov 2014 11:58:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, David Vrabel <david.vrabel@citrix.com>,
	<linux-kernel@vger.kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>	<1415684626-18590-8-git-send-email-jgross@suse.com>	<54624BCB.9040300@citrix.com>
	<546477FD.9050800@suse.com>
In-Reply-To: <546477FD.9050800@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 09:21, Juergen Gross wrote:
> On 11/11/2014 06:47 PM, David Vrabel wrote:
>>
>> Can you please test this with the following guests/scenarios.
>>
>> * 64 bit dom0 with PCI devices with high MMIO BARs.
> 
> I'm not sure I have a machine available with this configuration.

We have a bunch of them in our test lab. Unfortunately, xapi doesn't
work on Linux 3.12 or later so I won't be able to test this series in
the short term.

David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 11:58:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 11: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 1XpFW1-0003Xy-0V; Fri, 14 Nov 2014 11:58:13 +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 1XpFVz-0003Xt-M3
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 11:58:11 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	60/EF-26652-25EE5645; Fri, 14 Nov 2014 11:58:10 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415966289!11418976!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18649 invoked from network); 14 Nov 2014 11:58:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 11:58:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192816416"
Message-ID: <5465EE4E.2010206@citrix.com>
Date: Fri, 14 Nov 2014 11:58:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, David Vrabel <david.vrabel@citrix.com>,
	<linux-kernel@vger.kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, <boris.ostrovsky@oracle.com>, <x86@kernel.org>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>	<1415684626-18590-8-git-send-email-jgross@suse.com>	<54624BCB.9040300@citrix.com>
	<546477FD.9050800@suse.com>
In-Reply-To: <546477FD.9050800@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/11/14 09:21, Juergen Gross wrote:
> On 11/11/2014 06:47 PM, David Vrabel wrote:
>>
>> Can you please test this with the following guests/scenarios.
>>
>> * 64 bit dom0 with PCI devices with high MMIO BARs.
> 
> I'm not sure I have a machine available with this configuration.

We have a bunch of them in our test lab. Unfortunately, xapi doesn't
work on Linux 3.12 or later so I won't be able to test this series in
the short term.

David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:00:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpFXz-0003gj-6L; Fri, 14 Nov 2014 12:00:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpFXy-0003gO-3H
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 12:00:14 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	05/9B-02953-DCEE5645; Fri, 14 Nov 2014 12:00:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415966411!12568970!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11710 invoked from network); 14 Nov 2014 12:00:12 -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;
	14 Nov 2014 12:00:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191351169"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 07:00:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpFXt-0007Hh-4A;
	Fri, 14 Nov 2014 12:00:09 +0000
Date: Fri, 14 Nov 2014 11:59:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, linux@arm.linux.org.uk,
	Ian.Campbell@citrix.com, catalin.marinas@arm.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 05/13] arm: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Russell,
this patch needs your feedback.

- Stefano

On Wed, 12 Nov 2014, Stefano Stabellini wrote:
> Introduce a boolean flag and an accessor function to check whether a
> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> CC: linux@arm.linux.org.uk
> ---
>  arch/arm/include/asm/device.h      |    1 +
>  arch/arm/include/asm/dma-mapping.h |    6 ++++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index dc662fc..4111592 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -17,6 +17,7 @@ struct dev_archdata {
>  #ifdef CONFIG_ARM_DMA_USE_IOMMU
>  	struct dma_iommu_mapping	*mapping;
>  #endif
> +	bool dma_coherent;
>  };
>  
>  struct omap_device;
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index 85738b2..8c3b616 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -123,11 +123,17 @@ static inline unsigned long dma_max_pfn(struct device *dev)
>  
>  static inline int set_arch_dma_coherent_ops(struct device *dev)
>  {
> +	dev->archdata.dma_coherent = true;
>  	set_dma_ops(dev, &arm_coherent_dma_ops);
>  	return 0;
>  }
>  #define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
>  
> +static inline bool is_device_dma_coherent(struct device *dev)
> +{
> +	return dev->archdata.dma_coherent;
> +}
> +
>  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
>  {
>  	unsigned int offset = paddr & ~PAGE_MASK;
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:00:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpFXz-0003gj-6L; Fri, 14 Nov 2014 12:00:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpFXy-0003gO-3H
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 12:00:14 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	05/9B-02953-DCEE5645; Fri, 14 Nov 2014 12:00:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1415966411!12568970!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11710 invoked from network); 14 Nov 2014 12:00:12 -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;
	14 Nov 2014 12:00:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191351169"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 07:00:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpFXt-0007Hh-4A;
	Fri, 14 Nov 2014 12:00:09 +0000
Date: Fri, 14 Nov 2014 11:59:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, linux@arm.linux.org.uk,
	Ian.Campbell@citrix.com, catalin.marinas@arm.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 05/13] arm: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Russell,
this patch needs your feedback.

- Stefano

On Wed, 12 Nov 2014, Stefano Stabellini wrote:
> Introduce a boolean flag and an accessor function to check whether a
> device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> CC: linux@arm.linux.org.uk
> ---
>  arch/arm/include/asm/device.h      |    1 +
>  arch/arm/include/asm/dma-mapping.h |    6 ++++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index dc662fc..4111592 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -17,6 +17,7 @@ struct dev_archdata {
>  #ifdef CONFIG_ARM_DMA_USE_IOMMU
>  	struct dma_iommu_mapping	*mapping;
>  #endif
> +	bool dma_coherent;
>  };
>  
>  struct omap_device;
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index 85738b2..8c3b616 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -123,11 +123,17 @@ static inline unsigned long dma_max_pfn(struct device *dev)
>  
>  static inline int set_arch_dma_coherent_ops(struct device *dev)
>  {
> +	dev->archdata.dma_coherent = true;
>  	set_dma_ops(dev, &arm_coherent_dma_ops);
>  	return 0;
>  }
>  #define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
>  
> +static inline bool is_device_dma_coherent(struct device *dev)
> +{
> +	return dev->archdata.dma_coherent;
> +}
> +
>  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
>  {
>  	unsigned int offset = paddr & ~PAGE_MASK;
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:01:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:01:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpFZG-0003q8-MV; Fri, 14 Nov 2014 12:01:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpFZE-0003pn-LR
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 12:01:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	54/C3-24532-C1FE5645; Fri, 14 Nov 2014 12:01:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415966489!5466405!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15948 invoked from network); 14 Nov 2014 12:01:31 -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;
	14 Nov 2014 12:01:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192816973"
Message-ID: <1415966461.7113.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 14 Nov 2014 12:01:01 +0000
In-Reply-To: <5465EC05.8060801@linaro.org>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-3-git-send-email-talex5@gmail.com>
	<1413889218.23337.24.camel@citrix.com>
	<20141021215406.GJ3481@type.youpi.perso.aquilenet.fr>
	<1413968619.20604.56.camel@citrix.com>	<5447ABE4.1030703@linaro.org>
	<CAG4opy9QCRaMY41=M0HfK4vajvcE=nS+5P-L91itgOMDOBGS4w@mail.gmail.com>
	<544FB580.7080809@linaro.org>
	<CAG4opy-th0P+BBaRJOHeSP0jo=2hS1MqqVM2793q6NdB8jvEKA@mail.gmail.com>
	<544FBB76.7050102@linaro.org>
	<CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>
	<5465E89C.1030701@linaro.org> <1415965353.7113.16.camel@citrix.com>
	<5465EC05.8060801@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Thomas Leonard <talex5@gmail.com>, David Scott <Dave.Scott@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 2/4] mini-os: arm: interrupt
 controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 11:48 +0000, Julien Grall wrote:
> 
> On 14/11/2014 11:42, Ian Campbell wrote:
> > On Fri, 2014-11-14 at 11:33 +0000, Julien Grall wrote:
> >>>> Though IIRC, mini-os for ARM is not yet SMP.
> >>>
> >>> It's difficult to see what needs to be done to support code that
> >>> doesn't exist yet. For example, would gic_init be called once, or once
> >>> per processor? Before or after the other processors are started?
> >>
> >> Some part of the code maybe necessary: setting PPIs/SGIs... You can give
> >> a look to Linux/Xen GIC drivers to have an idea on what is necessary.
> >
> > This would be necessary as part of the port of mini-os to support SMP. I
> > don't see why it should be necessary now, going to SMP is surely going
> > to require a bunch of refactoring in other places too (Xen itself
> > certainly did).
> 
> I just answered to his question. I didn't asked for changing this code 
> right now.

I'm afraid you haven't made that at all clear until now.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:01:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:01:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpFZG-0003q8-MV; Fri, 14 Nov 2014 12:01:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpFZE-0003pn-LR
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 12:01:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	54/C3-24532-C1FE5645; Fri, 14 Nov 2014 12:01:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415966489!5466405!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15948 invoked from network); 14 Nov 2014 12:01:31 -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;
	14 Nov 2014 12:01:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="192816973"
Message-ID: <1415966461.7113.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 14 Nov 2014 12:01:01 +0000
In-Reply-To: <5465EC05.8060801@linaro.org>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-3-git-send-email-talex5@gmail.com>
	<1413889218.23337.24.camel@citrix.com>
	<20141021215406.GJ3481@type.youpi.perso.aquilenet.fr>
	<1413968619.20604.56.camel@citrix.com>	<5447ABE4.1030703@linaro.org>
	<CAG4opy9QCRaMY41=M0HfK4vajvcE=nS+5P-L91itgOMDOBGS4w@mail.gmail.com>
	<544FB580.7080809@linaro.org>
	<CAG4opy-th0P+BBaRJOHeSP0jo=2hS1MqqVM2793q6NdB8jvEKA@mail.gmail.com>
	<544FBB76.7050102@linaro.org>
	<CAG4opy8=HySzsg+HLCJm1PHHe8hUL60x_=GquhUR1AGjKVYNEw@mail.gmail.com>
	<5465E89C.1030701@linaro.org> <1415965353.7113.16.camel@citrix.com>
	<5465EC05.8060801@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Thomas Leonard <talex5@gmail.com>, David Scott <Dave.Scott@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 2/4] mini-os: arm: interrupt
 controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 11:48 +0000, Julien Grall wrote:
> 
> On 14/11/2014 11:42, Ian Campbell wrote:
> > On Fri, 2014-11-14 at 11:33 +0000, Julien Grall wrote:
> >>>> Though IIRC, mini-os for ARM is not yet SMP.
> >>>
> >>> It's difficult to see what needs to be done to support code that
> >>> doesn't exist yet. For example, would gic_init be called once, or once
> >>> per processor? Before or after the other processors are started?
> >>
> >> Some part of the code maybe necessary: setting PPIs/SGIs... You can give
> >> a look to Linux/Xen GIC drivers to have an idea on what is necessary.
> >
> > This would be necessary as part of the port of mini-os to support SMP. I
> > don't see why it should be necessary now, going to SMP is surely going
> > to require a bunch of refactoring in other places too (Xen itself
> > certainly did).
> 
> I just answered to his question. I didn't asked for changing this code 
> right now.

I'm afraid you haven't made that at all clear until now.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:11:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:11:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpFiN-0004M7-Ul; Fri, 14 Nov 2014 12:10:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1XpFiM-0004M2-CP
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 12:10:58 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F0/81-17958-151F5645; Fri, 14 Nov 2014 12:10:57 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415967056!11359214!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20388 invoked from network); 14 Nov 2014 12:10:56 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 12:10:56 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so2501357wiw.2
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 04:10:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=BTBTLbXvTogiHXjCIFyEnTEqU2IrFv7w4YJ13EBkvi8=;
	b=DqlclrBRi9I7v0YblMoyP6VYLRYz2YrYL6Q/L+6xAMJ0QczZYZerTwNRTFQod+ifEM
	SL5pcQalEjao6rK6D0kwVb/YZbi0aFX5jtbFFI3Ume5EKQOCajJhjFQLfxiD5XPGLqpj
	SNqv2iBFa4bKhAole5g2FAJxtqBeKRWodLP0aKa+Rf/YmH88ww+3tj1py2F+AMo/jQSm
	uA95Q6nNWnJ+A6hDMbglm1caQdCi4uWNBy9P5YZNv47bkwdJOFk4CLlVxtjCezN0YyRe
	LSjr8gfmSCol9A7RKg6WSm08pkjVw1ikz+bFjXO/84pKhnjPJ58Gubq/ZsPzOT23jh+D
	1Fsw==
X-Received: by 10.181.5.6 with SMTP id ci6mr7084481wid.35.1415967056164;
	Fri, 14 Nov 2014 04:10:56 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id
	kn5sm31883220wjb.48.2014.11.14.04.10.53 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 14 Nov 2014 04:10:54 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Lars Kurth <lars.kurth.xen@gmail.com>
In-Reply-To: <21600.64887.416522.656249@chiark.greenend.org.uk>
Date: Fri, 14 Nov 2014 12:10:52 +0000
Message-Id: <CE6BE269-4910-411C-B695-F3DB476F8229@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
X-Mailer: Apple Mail (2.1878.6)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 10 Nov 2014, at 18:01, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

> Having gone through the thread, I've prepared a three-part new
> proposal email.
> 
> I. Deployment with Security Team Permission
> II. Predisclosure list memembership
> III. Information sharing
> IV. Fixes which seem to have rough consensus as they were
> 
> Perhaps I should be checking the current web page out as a git tree
> and preparing a patch series ?

I would say, give it a week for further feedback and then prepare a patch.

I do have one question. What led us to publish an XSA number on 
http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell, 
CVE numbers are not published normally and we don't publish them 
until after the embargo due to CVE rules. The reason why I am asking 
is that one of the main reasons for the heightened media attention we 
got during XSA 108, is because the media were able to correlate 
statements related to an undisclosed security fix being responsible 
for the AWS reboot, with the information on http://xenbits.xen.org/xsa/ 

If this kind of correlation was not possible, this might remove media
speculation in future and reduce pressure on Xen users.

I am wondering what community members view on publish XSA 
numbers post embargo only? Of course this would impact what
can be disclosed pre-embargo.

> 
> Thanks,
> Ian.
> 
> 
> I. Deployment with Security Team Permission
> ===========================================
> 
> Permitting deployment during embargo seemed to have rough consensus on
> the principle.  We seemed to be converging on the idea that the
> Security Team should explicitly set deployment restrictions for each
> set of patches.  So I suggest something like this:
> 
>  List members may deploy fixed versions during the embargo, only with
>  permission from the Security Team.  The Security Team will normally
>  permit such deployment, even for systems where VMs are managed or
>  used by non-members of the predisclosure risk.  Permission for
>  deployment, and any restrictions, will be stated in the embargoed
>  advisory text.
> 
>  The Security Team will impose deployment restrictions only insofar
>  as it is necessary to prevent the exposure of technicalities (for
>  example, differences in behaviour) which present a significant risk
>  of rediscovery of the vulnerability.  Such situations are expected
>  to be rare.

+1

However, I find the text somewhat confusing. "may deploy fixed 
versions during  the embargo, only with permission from the 
Security Team" contradicts the other statements, that deploying 
fixes is OK, unless stated in the  advisory text. 

Or did I misinterpret? 

In any case, it is not quite clear what the protocol to get permission 
is. Or whether, the protocol is "deployment is OK" unless stated 
otherwise.

So I think, in the final policy text this should be written from the 
viewpoint of a pre-disclosure member, not the viewpoint of the 
Security Team.

Or is the intention that permission is sought via
xen-security-issues-discuss@lists.xenproject.org? 

> 
> 
> 
> II. Predisclosure list memembership
> ===================================
> 
> The idea of objective criteria seemed to find favour, and the general
> scheme I proposed.
> 
> Lars suggested we should "test" this.  I think therefore that we
> should invite a participants in this thread to write up and post
> applications which we can then test against the proposed policy.  But
> we should probably wait until we have rough consensus on the new
> policy shape.

It's either that, or we periodically review applications and see whether
they need to be improved. Given that the list is public, over time
there will be a list of templates that have been accepted which can
serve as examples.

> I have dropped the section about bad websites.  I don't think its lack
> will make much difference to the way applications are processed in
> practice, and I still think documenting the issue would be useful, but
> it's clear that I'm not going to get consensus for it.
> 
> Changes that I have made are:
> - Applications to be made, and decisions sent, to a public mailing list
> - Explicitly say that the Security Team decide and that they have no
>   discretion
> - Explicitly say that there is appeal to the project governance process
>   (Lars: perhaps this should say something different or more specific?)
> 
> 
> So as I said before, applicants should be required to:
> 
>  - Provide information on their public web pages which makes
>    it clear that and why they are eligible;
> 
>  - Specifically, publicly state that and how they are using Xen
>    (so that the Security Team can verify eligibility);
> 
>  - Provide a way for members of the public to responsibly report
>    security problems to the applicant, just as the Xen Project does.
> 
> The Security Team should be forbidden from trying to hunt down
> eligibility information etc. and should instead be mandated to reject
> incomplete requests.
> 
> Specifically, I propose that the section on list membership
> applications be entirely replaced with this:
> 
>  Organisations who meet the criteria should contact
>  predisclosure-applications@xenproject if they wish to receive
>  pre-disclosure of advisories.  That is a public mailing list.

Do you anticipate that the list be moderated?

> 
>  You must include in the e-mail:
> 
>    * The name of your organization.
> 
>    * Domain name(s) which you use to provide Xen software/services.
> 
>    * A brief description of why you fit the criteria.
> 
>    * If not all of your products/services use Xen, a list of (some
>      of) your products/services (or categories thereof) which do.
> 
>    * Link(s) to current public web pages, belonging to your
>      organisation, for each of following pieces of information:
> 
>      o Evidence of your status as a service/software provider:
>        + If you are a public hosting provider, your public rates
>          or how to get a quote
>        + If you are a software provider, how your
>          software can be downloaded or purchased
>        + If you are an open-source project, a mailing list
>          archive and/or version control repository, with
>          active development
> 
>      o Evidence of your status as a user of Xen:
>        + Statements about, or descriptions of, your eligible
>          production services or released software, from which it is
>          immediately evident that they use Xen.
> 
>      o Information about your handling of security problems:
>        + Your invitation to members of the public, who discover
>          security problems with your products/services, to report
>          them in confidence to you;
>        + Specifically, the contact information (email addresses or
>          other contact instructions) which such a member of the
>          public should use.
> 
>      Blog postings, conference presentations, social media pages,
>      Flash presentations, videos, sites which require registration,
>      anything password-protected, etc., are not acceptable.  PDFs of
>      reasonable size are acceptable so long as the URL you provide is
>      of a ordinary HTML page providing a link to the PDF.
> 
>      If the pages are long and/or PDFs are involved, your email
>      should say which part of the pages and documents are relevant.
> 
>    * A statement to the effect that you have read this policy and
>      agree to abide by the terms for inclusion in the list,
>      specifically the requirements regarding confidentiality during
>      an embargo period.
> 
>    * The single (non-personal) email alias you wish added to the
>      predisclosure list.
> 
>  Your application will be determined by the Xen Project Security
>  Team, and their decision posted to the list.  The Security Team has
>  no discretion to accept applications which do not provide all of the
>  information required above.

As it is a public list, I am assuming that others on the list may be
allowed to post concerns on the list. 

>  If you are dissatisfied with the Security Team's decision you may
>  appeal it via the Xen Project's governance processes.

It is not quite clear how this would work in practice. Are you 
suggesting that the referee process would be used in this case?
That would be that fundamentally, maintainers, project leads, ...
would need to look at appeals.

I suppose that would be OK and in reality, we will hardly ever
get appeals.


> III. Information-sharing
> ========================
> 
> Permitting sharing of embargoed fixes amongst predisclosure list
> seemed to have rough consensus in principle.  There was some
> discussion about the details.  I remain convinced that my previous
> proposal is correct and I think we should be able to get consensus for
> it.

+1


> IV. Fixes which seem to have rough consensus as they were
> =========================================================
> 
> (Reproduced unchanged from my previous proposed wording:)
+1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:11:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:11:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpFiN-0004M7-Ul; Fri, 14 Nov 2014 12:10:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1XpFiM-0004M2-CP
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 12:10:58 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F0/81-17958-151F5645; Fri, 14 Nov 2014 12:10:57 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415967056!11359214!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20388 invoked from network); 14 Nov 2014 12:10:56 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 12:10:56 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so2501357wiw.2
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 04:10:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=BTBTLbXvTogiHXjCIFyEnTEqU2IrFv7w4YJ13EBkvi8=;
	b=DqlclrBRi9I7v0YblMoyP6VYLRYz2YrYL6Q/L+6xAMJ0QczZYZerTwNRTFQod+ifEM
	SL5pcQalEjao6rK6D0kwVb/YZbi0aFX5jtbFFI3Ume5EKQOCajJhjFQLfxiD5XPGLqpj
	SNqv2iBFa4bKhAole5g2FAJxtqBeKRWodLP0aKa+Rf/YmH88ww+3tj1py2F+AMo/jQSm
	uA95Q6nNWnJ+A6hDMbglm1caQdCi4uWNBy9P5YZNv47bkwdJOFk4CLlVxtjCezN0YyRe
	LSjr8gfmSCol9A7RKg6WSm08pkjVw1ikz+bFjXO/84pKhnjPJ58Gubq/ZsPzOT23jh+D
	1Fsw==
X-Received: by 10.181.5.6 with SMTP id ci6mr7084481wid.35.1415967056164;
	Fri, 14 Nov 2014 04:10:56 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id
	kn5sm31883220wjb.48.2014.11.14.04.10.53 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 14 Nov 2014 04:10:54 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Lars Kurth <lars.kurth.xen@gmail.com>
In-Reply-To: <21600.64887.416522.656249@chiark.greenend.org.uk>
Date: Fri, 14 Nov 2014 12:10:52 +0000
Message-Id: <CE6BE269-4910-411C-B695-F3DB476F8229@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
X-Mailer: Apple Mail (2.1878.6)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 10 Nov 2014, at 18:01, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

> Having gone through the thread, I've prepared a three-part new
> proposal email.
> 
> I. Deployment with Security Team Permission
> II. Predisclosure list memembership
> III. Information sharing
> IV. Fixes which seem to have rough consensus as they were
> 
> Perhaps I should be checking the current web page out as a git tree
> and preparing a patch series ?

I would say, give it a week for further feedback and then prepare a patch.

I do have one question. What led us to publish an XSA number on 
http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell, 
CVE numbers are not published normally and we don't publish them 
until after the embargo due to CVE rules. The reason why I am asking 
is that one of the main reasons for the heightened media attention we 
got during XSA 108, is because the media were able to correlate 
statements related to an undisclosed security fix being responsible 
for the AWS reboot, with the information on http://xenbits.xen.org/xsa/ 

If this kind of correlation was not possible, this might remove media
speculation in future and reduce pressure on Xen users.

I am wondering what community members view on publish XSA 
numbers post embargo only? Of course this would impact what
can be disclosed pre-embargo.

> 
> Thanks,
> Ian.
> 
> 
> I. Deployment with Security Team Permission
> ===========================================
> 
> Permitting deployment during embargo seemed to have rough consensus on
> the principle.  We seemed to be converging on the idea that the
> Security Team should explicitly set deployment restrictions for each
> set of patches.  So I suggest something like this:
> 
>  List members may deploy fixed versions during the embargo, only with
>  permission from the Security Team.  The Security Team will normally
>  permit such deployment, even for systems where VMs are managed or
>  used by non-members of the predisclosure risk.  Permission for
>  deployment, and any restrictions, will be stated in the embargoed
>  advisory text.
> 
>  The Security Team will impose deployment restrictions only insofar
>  as it is necessary to prevent the exposure of technicalities (for
>  example, differences in behaviour) which present a significant risk
>  of rediscovery of the vulnerability.  Such situations are expected
>  to be rare.

+1

However, I find the text somewhat confusing. "may deploy fixed 
versions during  the embargo, only with permission from the 
Security Team" contradicts the other statements, that deploying 
fixes is OK, unless stated in the  advisory text. 

Or did I misinterpret? 

In any case, it is not quite clear what the protocol to get permission 
is. Or whether, the protocol is "deployment is OK" unless stated 
otherwise.

So I think, in the final policy text this should be written from the 
viewpoint of a pre-disclosure member, not the viewpoint of the 
Security Team.

Or is the intention that permission is sought via
xen-security-issues-discuss@lists.xenproject.org? 

> 
> 
> 
> II. Predisclosure list memembership
> ===================================
> 
> The idea of objective criteria seemed to find favour, and the general
> scheme I proposed.
> 
> Lars suggested we should "test" this.  I think therefore that we
> should invite a participants in this thread to write up and post
> applications which we can then test against the proposed policy.  But
> we should probably wait until we have rough consensus on the new
> policy shape.

It's either that, or we periodically review applications and see whether
they need to be improved. Given that the list is public, over time
there will be a list of templates that have been accepted which can
serve as examples.

> I have dropped the section about bad websites.  I don't think its lack
> will make much difference to the way applications are processed in
> practice, and I still think documenting the issue would be useful, but
> it's clear that I'm not going to get consensus for it.
> 
> Changes that I have made are:
> - Applications to be made, and decisions sent, to a public mailing list
> - Explicitly say that the Security Team decide and that they have no
>   discretion
> - Explicitly say that there is appeal to the project governance process
>   (Lars: perhaps this should say something different or more specific?)
> 
> 
> So as I said before, applicants should be required to:
> 
>  - Provide information on their public web pages which makes
>    it clear that and why they are eligible;
> 
>  - Specifically, publicly state that and how they are using Xen
>    (so that the Security Team can verify eligibility);
> 
>  - Provide a way for members of the public to responsibly report
>    security problems to the applicant, just as the Xen Project does.
> 
> The Security Team should be forbidden from trying to hunt down
> eligibility information etc. and should instead be mandated to reject
> incomplete requests.
> 
> Specifically, I propose that the section on list membership
> applications be entirely replaced with this:
> 
>  Organisations who meet the criteria should contact
>  predisclosure-applications@xenproject if they wish to receive
>  pre-disclosure of advisories.  That is a public mailing list.

Do you anticipate that the list be moderated?

> 
>  You must include in the e-mail:
> 
>    * The name of your organization.
> 
>    * Domain name(s) which you use to provide Xen software/services.
> 
>    * A brief description of why you fit the criteria.
> 
>    * If not all of your products/services use Xen, a list of (some
>      of) your products/services (or categories thereof) which do.
> 
>    * Link(s) to current public web pages, belonging to your
>      organisation, for each of following pieces of information:
> 
>      o Evidence of your status as a service/software provider:
>        + If you are a public hosting provider, your public rates
>          or how to get a quote
>        + If you are a software provider, how your
>          software can be downloaded or purchased
>        + If you are an open-source project, a mailing list
>          archive and/or version control repository, with
>          active development
> 
>      o Evidence of your status as a user of Xen:
>        + Statements about, or descriptions of, your eligible
>          production services or released software, from which it is
>          immediately evident that they use Xen.
> 
>      o Information about your handling of security problems:
>        + Your invitation to members of the public, who discover
>          security problems with your products/services, to report
>          them in confidence to you;
>        + Specifically, the contact information (email addresses or
>          other contact instructions) which such a member of the
>          public should use.
> 
>      Blog postings, conference presentations, social media pages,
>      Flash presentations, videos, sites which require registration,
>      anything password-protected, etc., are not acceptable.  PDFs of
>      reasonable size are acceptable so long as the URL you provide is
>      of a ordinary HTML page providing a link to the PDF.
> 
>      If the pages are long and/or PDFs are involved, your email
>      should say which part of the pages and documents are relevant.
> 
>    * A statement to the effect that you have read this policy and
>      agree to abide by the terms for inclusion in the list,
>      specifically the requirements regarding confidentiality during
>      an embargo period.
> 
>    * The single (non-personal) email alias you wish added to the
>      predisclosure list.
> 
>  Your application will be determined by the Xen Project Security
>  Team, and their decision posted to the list.  The Security Team has
>  no discretion to accept applications which do not provide all of the
>  information required above.

As it is a public list, I am assuming that others on the list may be
allowed to post concerns on the list. 

>  If you are dissatisfied with the Security Team's decision you may
>  appeal it via the Xen Project's governance processes.

It is not quite clear how this would work in practice. Are you 
suggesting that the referee process would be used in this case?
That would be that fundamentally, maintainers, project leads, ...
would need to look at appeals.

I suppose that would be OK and in reality, we will hardly ever
get appeals.


> III. Information-sharing
> ========================
> 
> Permitting sharing of embargoed fixes amongst predisclosure list
> seemed to have rough consensus in principle.  There was some
> discussion about the details.  I remain convinced that my previous
> proposal is correct and I think we should be able to get consensus for
> it.

+1


> IV. Fixes which seem to have rough consensus as they were
> =========================================================
> 
> (Reproduced unchanged from my previous proposed wording:)
+1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:38:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:38:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpG86-0005W4-6U; Fri, 14 Nov 2014 12:37:34 +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 1XpG84-0005Vy-Bb
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 12:37:32 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	23/D2-02712-B87F5645; Fri, 14 Nov 2014 12:37:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415968650!12016168!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6917 invoked from network); 14 Nov 2014 12:37:30 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 12:37:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 12:37:30 +0000
Message-Id: <5466059A0200007800047A4B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 12:37:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3401089A.1__="
Cc: roy.franz@linaro.org
Subject: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices() call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part3401089A.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The specification is kind of vague under what conditions
ExitBootServices() may legitimately fail, requiring the OS loader to
retry:

"If MapKey value is incorrect, ExitBootServices() returns
 EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
 be called again. Firmware implementation may choose to do a partial
 shutdown of the boot services during the first call to
 ExitBootServices(). EFI OS loader should not make calls to any boot
 service function other then GetMemoryMap() after the first call to
 ExitBootServices()."

While our code guarantees the map key to be valid, there are systems
where a firmware internal notification sent while processing
ExitBootServices() reportedly results in changes to the memory map.
In that case, make a best effort second try: Avoid any boot service
calls other than the two named above, with the possible exception of
error paths. Those aren't a problem, since if we end up needing to
retry, we're hosed when something goes wrong as much as if we didn't
make the retry attempt.

For x86, a minimal adjustment to efi_arch_process_memory_map() is
needed for it to cope with potentially being called a second time.

For arm64, while efi_process_memory_map_bootinfo() is easy to verify
that it can safely be called more than once without violating spec
constraints, it's not so obvious for fdt_add_uefi_nodes(), hence a
step by step approach:
- deletion of memory nodes and memory reserve map entries: the 2nd pass
  shouldn't find any as the 1st one deleted them all,
- a "chosen" node should be found as it got added in the 1st pass,
- the various "linux,uefi-*" nodes all got added during the 1st pass
  and hence only their contents may get updated.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -140,7 +140,7 @@ static void __init efi_arch_process_memo
=20
     /* Populate E820 table and check trampoline area availability. */
     e =3D e820map - 1;
-    for ( i =3D 0; i < map_size; i +=3D desc_size )
+    for ( e820nr =3D i =3D 0; i < map_size; i +=3D desc_size )
     {
         EFI_MEMORY_DESCRIPTOR *desc =3D map + i;
         u64 len =3D desc->NumberOfPages << EFI_PAGE_SHIFT;
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -703,7 +703,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop =3D NULL;
     EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
     union string section =3D { NULL }, name;
-    bool_t base_video =3D 0;
+    bool_t base_video =3D 0, retry;
     char *option_str;
     bool_t use_cfg_file;
=20
@@ -1051,17 +1051,23 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
     if ( !efi_memmap )
         blexit(L"Unable to allocate memory for EFI memory map");
=20
-    status =3D efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, =
&map_key,
-                                  &efi_mdesc_size, &mdesc_ver);
-    if ( EFI_ERROR(status) )
-        PrintErrMesg(L"Cannot obtain memory map", status);
+    for ( retry =3D 0; ; retry =3D 1 )
+    {
+        status =3D efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, =
&map_key,
+                                      &efi_mdesc_size, &mdesc_ver);
+        if ( EFI_ERROR(status) )
+            PrintErrMesg(L"Cannot obtain memory map", status);
=20
-    efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
-                                efi_mdesc_size, mdesc_ver);
+        efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_si=
ze,
+                                    efi_mdesc_size, mdesc_ver);
=20
-    efi_arch_pre_exit_boot();
+        efi_arch_pre_exit_boot();
+
+        status =3D efi_bs->ExitBootServices(ImageHandle, map_key);
+        if ( status !=3D EFI_INVALID_PARAMETER || retry )
+            break;
+    }
=20
-    status =3D efi_bs->ExitBootServices(ImageHandle, map_key);
     if ( EFI_ERROR(status) )
         PrintErrMesg(L"Cannot exit boot services", status);
=20




--=__Part3401089A.1__=
Content-Type: text/plain; name="EFI-exit-boot-services-retry.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="EFI-exit-boot-services-retry.patch"

EFI: allow retry of ExitBootServices() call=0A=0AThe specification is kind =
of vague under what conditions=0AExitBootServices() may legitimately fail, =
requiring the OS loader to=0Aretry:=0A=0A"If MapKey value is incorrect, =
ExitBootServices() returns=0A EFI_INVALID_PARAMETER and GetMemoryMap() =
with ExitBootServices() must=0A be called again. Firmware implementation =
may choose to do a partial=0A shutdown of the boot services during the =
first call to=0A ExitBootServices(). EFI OS loader should not make calls =
to any boot=0A service function other then GetMemoryMap() after the first =
call to=0A ExitBootServices()."=0A=0AWhile our code guarantees the map key =
to be valid, there are systems=0Awhere a firmware internal notification =
sent while processing=0AExitBootServices() reportedly results in changes =
to the memory map.=0AIn that case, make a best effort second try: Avoid =
any boot service=0Acalls other than the two named above, with the possible =
exception of=0Aerror paths. Those aren't a problem, since if we end up =
needing to=0Aretry, we're hosed when something goes wrong as much as if we =
didn't=0Amake the retry attempt.=0A=0AFor x86, a minimal adjustment to =
efi_arch_process_memory_map() is=0Aneeded for it to cope with potentially =
being called a second time.=0A=0AFor arm64, while efi_process_memory_map_bo=
otinfo() is easy to verify=0Athat it can safely be called more than once =
without violating spec=0Aconstraints, it's not so obvious for fdt_add_uefi_=
nodes(), hence a=0Astep by step approach:=0A- deletion of memory nodes and =
memory reserve map entries: the 2nd pass=0A  shouldn't find any as the 1st =
one deleted them all,=0A- a "chosen" node should be found as it got added =
in the 1st pass,=0A- the various "linux,uefi-*" nodes all got added during =
the 1st pass=0A  and hence only their contents may get updated.=0A=0ASigned=
-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/efi/efi-bo=
ot.h=0A+++ b/xen/arch/x86/efi/efi-boot.h=0A@@ -140,7 +140,7 @@ static void =
__init efi_arch_process_memo=0A =0A     /* Populate E820 table and check =
trampoline area availability. */=0A     e =3D e820map - 1;=0A-    for ( i =
=3D 0; i < map_size; i +=3D desc_size )=0A+    for ( e820nr =3D i =3D 0; i =
< map_size; i +=3D desc_size )=0A     {=0A         EFI_MEMORY_DESCRIPTOR =
*desc =3D map + i;=0A         u64 len =3D desc->NumberOfPages << EFI_PAGE_S=
HIFT;=0A--- a/xen/common/efi/boot.c=0A+++ b/xen/common/efi/boot.c=0A@@ =
-703,7 +703,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A     EFI_GRAPHI=
CS_OUTPUT_PROTOCOL *gop =3D NULL;=0A     EFI_GRAPHICS_OUTPUT_MODE_INFORMATI=
ON *mode_info;=0A     union string section =3D { NULL }, name;=0A-    =
bool_t base_video =3D 0;=0A+    bool_t base_video =3D 0, retry;=0A     =
char *option_str;=0A     bool_t use_cfg_file;=0A =0A@@ -1051,17 +1051,23 =
@@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A     if ( !efi_memmap )=0A   =
      blexit(L"Unable to allocate memory for EFI memory map");=0A =0A-    =
status =3D efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,=0A-=
                                  &efi_mdesc_size, &mdesc_ver);=0A-    if =
( EFI_ERROR(status) )=0A-        PrintErrMesg(L"Cannot obtain memory map", =
status);=0A+    for ( retry =3D 0; ; retry =3D 1 )=0A+    {=0A+        =
status =3D efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,=0A+=
                                      &efi_mdesc_size, &mdesc_ver);=0A+    =
    if ( EFI_ERROR(status) )=0A+            PrintErrMesg(L"Cannot obtain =
memory map", status);=0A =0A-    efi_arch_process_memory_map(SystemTable, =
efi_memmap, efi_memmap_size,=0A-                                efi_mdesc_s=
ize, mdesc_ver);=0A+        efi_arch_process_memory_map(SystemTable, =
efi_memmap, efi_memmap_size,=0A+                                    =
efi_mdesc_size, mdesc_ver);=0A =0A-    efi_arch_pre_exit_boot();=0A+       =
 efi_arch_pre_exit_boot();=0A+=0A+        status =3D efi_bs->ExitBootServic=
es(ImageHandle, map_key);=0A+        if ( status !=3D EFI_INVALID_PARAMETER=
 || retry )=0A+            break;=0A+    }=0A =0A-    status =3D efi_bs->Ex=
itBootServices(ImageHandle, map_key);=0A     if ( EFI_ERROR(status) )=0A   =
      PrintErrMesg(L"Cannot exit boot services", status);=0A =0A
--=__Part3401089A.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

--=__Part3401089A.1__=--


From xen-devel-bounces@lists.xen.org Fri Nov 14 12:38:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:38:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpG86-0005W4-6U; Fri, 14 Nov 2014 12:37:34 +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 1XpG84-0005Vy-Bb
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 12:37:32 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	23/D2-02712-B87F5645; Fri, 14 Nov 2014 12:37:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415968650!12016168!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6917 invoked from network); 14 Nov 2014 12:37:30 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 12:37:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 12:37:30 +0000
Message-Id: <5466059A0200007800047A4B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 12:37:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3401089A.1__="
Cc: roy.franz@linaro.org
Subject: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices() call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part3401089A.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The specification is kind of vague under what conditions
ExitBootServices() may legitimately fail, requiring the OS loader to
retry:

"If MapKey value is incorrect, ExitBootServices() returns
 EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
 be called again. Firmware implementation may choose to do a partial
 shutdown of the boot services during the first call to
 ExitBootServices(). EFI OS loader should not make calls to any boot
 service function other then GetMemoryMap() after the first call to
 ExitBootServices()."

While our code guarantees the map key to be valid, there are systems
where a firmware internal notification sent while processing
ExitBootServices() reportedly results in changes to the memory map.
In that case, make a best effort second try: Avoid any boot service
calls other than the two named above, with the possible exception of
error paths. Those aren't a problem, since if we end up needing to
retry, we're hosed when something goes wrong as much as if we didn't
make the retry attempt.

For x86, a minimal adjustment to efi_arch_process_memory_map() is
needed for it to cope with potentially being called a second time.

For arm64, while efi_process_memory_map_bootinfo() is easy to verify
that it can safely be called more than once without violating spec
constraints, it's not so obvious for fdt_add_uefi_nodes(), hence a
step by step approach:
- deletion of memory nodes and memory reserve map entries: the 2nd pass
  shouldn't find any as the 1st one deleted them all,
- a "chosen" node should be found as it got added in the 1st pass,
- the various "linux,uefi-*" nodes all got added during the 1st pass
  and hence only their contents may get updated.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -140,7 +140,7 @@ static void __init efi_arch_process_memo
=20
     /* Populate E820 table and check trampoline area availability. */
     e =3D e820map - 1;
-    for ( i =3D 0; i < map_size; i +=3D desc_size )
+    for ( e820nr =3D i =3D 0; i < map_size; i +=3D desc_size )
     {
         EFI_MEMORY_DESCRIPTOR *desc =3D map + i;
         u64 len =3D desc->NumberOfPages << EFI_PAGE_SHIFT;
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -703,7 +703,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop =3D NULL;
     EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
     union string section =3D { NULL }, name;
-    bool_t base_video =3D 0;
+    bool_t base_video =3D 0, retry;
     char *option_str;
     bool_t use_cfg_file;
=20
@@ -1051,17 +1051,23 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
     if ( !efi_memmap )
         blexit(L"Unable to allocate memory for EFI memory map");
=20
-    status =3D efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, =
&map_key,
-                                  &efi_mdesc_size, &mdesc_ver);
-    if ( EFI_ERROR(status) )
-        PrintErrMesg(L"Cannot obtain memory map", status);
+    for ( retry =3D 0; ; retry =3D 1 )
+    {
+        status =3D efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, =
&map_key,
+                                      &efi_mdesc_size, &mdesc_ver);
+        if ( EFI_ERROR(status) )
+            PrintErrMesg(L"Cannot obtain memory map", status);
=20
-    efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
-                                efi_mdesc_size, mdesc_ver);
+        efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_si=
ze,
+                                    efi_mdesc_size, mdesc_ver);
=20
-    efi_arch_pre_exit_boot();
+        efi_arch_pre_exit_boot();
+
+        status =3D efi_bs->ExitBootServices(ImageHandle, map_key);
+        if ( status !=3D EFI_INVALID_PARAMETER || retry )
+            break;
+    }
=20
-    status =3D efi_bs->ExitBootServices(ImageHandle, map_key);
     if ( EFI_ERROR(status) )
         PrintErrMesg(L"Cannot exit boot services", status);
=20




--=__Part3401089A.1__=
Content-Type: text/plain; name="EFI-exit-boot-services-retry.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="EFI-exit-boot-services-retry.patch"

EFI: allow retry of ExitBootServices() call=0A=0AThe specification is kind =
of vague under what conditions=0AExitBootServices() may legitimately fail, =
requiring the OS loader to=0Aretry:=0A=0A"If MapKey value is incorrect, =
ExitBootServices() returns=0A EFI_INVALID_PARAMETER and GetMemoryMap() =
with ExitBootServices() must=0A be called again. Firmware implementation =
may choose to do a partial=0A shutdown of the boot services during the =
first call to=0A ExitBootServices(). EFI OS loader should not make calls =
to any boot=0A service function other then GetMemoryMap() after the first =
call to=0A ExitBootServices()."=0A=0AWhile our code guarantees the map key =
to be valid, there are systems=0Awhere a firmware internal notification =
sent while processing=0AExitBootServices() reportedly results in changes =
to the memory map.=0AIn that case, make a best effort second try: Avoid =
any boot service=0Acalls other than the two named above, with the possible =
exception of=0Aerror paths. Those aren't a problem, since if we end up =
needing to=0Aretry, we're hosed when something goes wrong as much as if we =
didn't=0Amake the retry attempt.=0A=0AFor x86, a minimal adjustment to =
efi_arch_process_memory_map() is=0Aneeded for it to cope with potentially =
being called a second time.=0A=0AFor arm64, while efi_process_memory_map_bo=
otinfo() is easy to verify=0Athat it can safely be called more than once =
without violating spec=0Aconstraints, it's not so obvious for fdt_add_uefi_=
nodes(), hence a=0Astep by step approach:=0A- deletion of memory nodes and =
memory reserve map entries: the 2nd pass=0A  shouldn't find any as the 1st =
one deleted them all,=0A- a "chosen" node should be found as it got added =
in the 1st pass,=0A- the various "linux,uefi-*" nodes all got added during =
the 1st pass=0A  and hence only their contents may get updated.=0A=0ASigned=
-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/efi/efi-bo=
ot.h=0A+++ b/xen/arch/x86/efi/efi-boot.h=0A@@ -140,7 +140,7 @@ static void =
__init efi_arch_process_memo=0A =0A     /* Populate E820 table and check =
trampoline area availability. */=0A     e =3D e820map - 1;=0A-    for ( i =
=3D 0; i < map_size; i +=3D desc_size )=0A+    for ( e820nr =3D i =3D 0; i =
< map_size; i +=3D desc_size )=0A     {=0A         EFI_MEMORY_DESCRIPTOR =
*desc =3D map + i;=0A         u64 len =3D desc->NumberOfPages << EFI_PAGE_S=
HIFT;=0A--- a/xen/common/efi/boot.c=0A+++ b/xen/common/efi/boot.c=0A@@ =
-703,7 +703,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A     EFI_GRAPHI=
CS_OUTPUT_PROTOCOL *gop =3D NULL;=0A     EFI_GRAPHICS_OUTPUT_MODE_INFORMATI=
ON *mode_info;=0A     union string section =3D { NULL }, name;=0A-    =
bool_t base_video =3D 0;=0A+    bool_t base_video =3D 0, retry;=0A     =
char *option_str;=0A     bool_t use_cfg_file;=0A =0A@@ -1051,17 +1051,23 =
@@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A     if ( !efi_memmap )=0A   =
      blexit(L"Unable to allocate memory for EFI memory map");=0A =0A-    =
status =3D efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,=0A-=
                                  &efi_mdesc_size, &mdesc_ver);=0A-    if =
( EFI_ERROR(status) )=0A-        PrintErrMesg(L"Cannot obtain memory map", =
status);=0A+    for ( retry =3D 0; ; retry =3D 1 )=0A+    {=0A+        =
status =3D efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,=0A+=
                                      &efi_mdesc_size, &mdesc_ver);=0A+    =
    if ( EFI_ERROR(status) )=0A+            PrintErrMesg(L"Cannot obtain =
memory map", status);=0A =0A-    efi_arch_process_memory_map(SystemTable, =
efi_memmap, efi_memmap_size,=0A-                                efi_mdesc_s=
ize, mdesc_ver);=0A+        efi_arch_process_memory_map(SystemTable, =
efi_memmap, efi_memmap_size,=0A+                                    =
efi_mdesc_size, mdesc_ver);=0A =0A-    efi_arch_pre_exit_boot();=0A+       =
 efi_arch_pre_exit_boot();=0A+=0A+        status =3D efi_bs->ExitBootServic=
es(ImageHandle, map_key);=0A+        if ( status !=3D EFI_INVALID_PARAMETER=
 || retry )=0A+            break;=0A+    }=0A =0A-    status =3D efi_bs->Ex=
itBootServices(ImageHandle, map_key);=0A     if ( EFI_ERROR(status) )=0A   =
      PrintErrMesg(L"Cannot exit boot services", status);=0A =0A
--=__Part3401089A.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

--=__Part3401089A.1__=--


From xen-devel-bounces@lists.xen.org Fri Nov 14 12:42:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12: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 1XpGCo-0005jn-2M; Fri, 14 Nov 2014 12:42:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpGCn-0005ji-30
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 12:42:25 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	79/0C-28865-0B8F5645; Fri, 14 Nov 2014 12:42:24 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415968942!7289514!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15521 invoked from network); 14 Nov 2014 12:42:23 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 12:42:23 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 2914EAD06;
	Fri, 14 Nov 2014 12:42:21 +0000 (UTC)
Message-ID: <5465F8AC.1050905@suse.com>
Date: Fri, 14 Nov 2014 13:42:20 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415684626-18590-1-git-send-email-jgross@suse.com>	<1415684626-18590-8-git-send-email-jgross@suse.com>	<54624BCB.9040300@citrix.com>
	<546477FD.9050800@suse.com> <5465EE4E.2010206@citrix.com>
In-Reply-To: <5465EE4E.2010206@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m 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

On 11/14/2014 12:58 PM, David Vrabel wrote:
> On 13/11/14 09:21, Juergen Gross wrote:
>> On 11/11/2014 06:47 PM, David Vrabel wrote:
>>>
>>> Can you please test this with the following guests/scenarios.
>>>
>>> * 64 bit dom0 with PCI devices with high MMIO BARs.
>>
>> I'm not sure I have a machine available with this configuration.
>
> We have a bunch of them in our test lab. Unfortunately, xapi doesn't
> work on Linux 3.12 or later so I won't be able to test this series in
> the short term.

I've found one. Stay tuned. :-)


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:42:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12: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 1XpGCo-0005jn-2M; Fri, 14 Nov 2014 12:42:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpGCn-0005ji-30
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 12:42:25 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	79/0C-28865-0B8F5645; Fri, 14 Nov 2014 12:42:24 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1415968942!7289514!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15521 invoked from network); 14 Nov 2014 12:42:23 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 12:42:23 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 2914EAD06;
	Fri, 14 Nov 2014 12:42:21 +0000 (UTC)
Message-ID: <5465F8AC.1050905@suse.com>
Date: Fri, 14 Nov 2014 13:42:20 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
References: <1415684626-18590-1-git-send-email-jgross@suse.com>	<1415684626-18590-8-git-send-email-jgross@suse.com>	<54624BCB.9040300@citrix.com>
	<546477FD.9050800@suse.com> <5465EE4E.2010206@citrix.com>
In-Reply-To: <5465EE4E.2010206@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m 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

On 11/14/2014 12:58 PM, David Vrabel wrote:
> On 13/11/14 09:21, Juergen Gross wrote:
>> On 11/11/2014 06:47 PM, David Vrabel wrote:
>>>
>>> Can you please test this with the following guests/scenarios.
>>>
>>> * 64 bit dom0 with PCI devices with high MMIO BARs.
>>
>> I'm not sure I have a machine available with this configuration.
>
> We have a bunch of them in our test lab. Unfortunately, xapi doesn't
> work on Linux 3.12 or later so I won't be able to test this series in
> the short term.

I've found one. Stay tuned. :-)


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:50:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12: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 1XpGKJ-00061U-0n; Fri, 14 Nov 2014 12:50:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XpGKH-00061P-Pz
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 12:50:09 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	30/44-31453-18AF5645; Fri, 14 Nov 2014 12:50:09 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415969408!3825249!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25166 invoked from network); 14 Nov 2014 12:50:08 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-3.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Nov 2014 12:50:08 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XpGKG-0005yZ-14; Fri, 14 Nov 2014 12:50:08 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21605.64128.1227.643880@chiark.greenend.org.uk>
Date: Fri, 14 Nov 2014 12:50:08 +0000
To: Lars Kurth <lars.kurth.xen@gmail.com>
In-Reply-To: <CE6BE269-4910-411C-B695-F3DB476F8229@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
	<CE6BE269-4910-411C-B695-F3DB476F8229@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> I do have one question. What led us to publish an XSA number on 
> http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell, 
> CVE numbers are not published normally and we don't publish them 
> until after the embargo due to CVE rules.

We used to publish CVEs in advance but MITRE asked us to stop doing
so.

We publish the XSA numbers because the purpose of the secrecy is to
prevent vulnerabilities being exploited.  The purpose of the secrecy
is not the convenience of the Security Team.  Everything that does not
need to be secret for that real purpose should be public.

Keeping secret the existence of an XSA number, and its embargo date,
would not improve the security of systems running Xen.  So we should
not do that.

Making the embargo end date public is very useful for people who are
_not_ on the predisclosure list, because it means that they can plan
their response.  (And it wouldn't make much sense to publish embargo
end date(s) without XSA numbers.)

> I am wondering what community members view on publish XSA 
> numbers post embargo only? Of course this would impact what
> can be disclosed pre-embargo.

Another impact of keeping things totally secret in the way you suggest
is that service providers would no longer be able to give honest
reasons for maintenance activity.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:50:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12: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 1XpGKJ-00061U-0n; Fri, 14 Nov 2014 12:50:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijackson@chiark.greenend.org.uk>) id 1XpGKH-00061P-Pz
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 12:50:09 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	30/44-31453-18AF5645; Fri, 14 Nov 2014 12:50:09 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415969408!3825249!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25166 invoked from network); 14 Nov 2014 12:50:08 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
	(212.13.197.229)
	by server-3.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Nov 2014 12:50:08 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
	(return-path ijackson@chiark.greenend.org.uk)
	id 1XpGKG-0005yZ-14; Fri, 14 Nov 2014 12:50:08 +0000
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
MIME-Version: 1.0
Message-ID: <21605.64128.1227.643880@chiark.greenend.org.uk>
Date: Fri, 14 Nov 2014 12:50:08 +0000
To: Lars Kurth <lars.kurth.xen@gmail.com>
In-Reply-To: <CE6BE269-4910-411C-B695-F3DB476F8229@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
	<CE6BE269-4910-411C-B695-F3DB476F8229@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> I do have one question. What led us to publish an XSA number on 
> http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell, 
> CVE numbers are not published normally and we don't publish them 
> until after the embargo due to CVE rules.

We used to publish CVEs in advance but MITRE asked us to stop doing
so.

We publish the XSA numbers because the purpose of the secrecy is to
prevent vulnerabilities being exploited.  The purpose of the secrecy
is not the convenience of the Security Team.  Everything that does not
need to be secret for that real purpose should be public.

Keeping secret the existence of an XSA number, and its embargo date,
would not improve the security of systems running Xen.  So we should
not do that.

Making the embargo end date public is very useful for people who are
_not_ on the predisclosure list, because it means that they can plan
their response.  (And it wouldn't make much sense to publish embargo
end date(s) without XSA numbers.)

> I am wondering what community members view on publish XSA 
> numbers post embargo only? Of course this would impact what
> can be disclosed pre-embargo.

Another impact of keeping things totally secret in the way you suggest
is that service providers would no longer be able to give honest
reasons for maintenance activity.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:53:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:53:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpGND-0006C9-JM; Fri, 14 Nov 2014 12:53:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpGNC-0006C4-2x
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 12:53:10 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	3E/3A-31453-53BF5645; Fri, 14 Nov 2014 12:53:09 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415969588!6003041!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7125 invoked from network); 14 Nov 2014 12:53:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 12:53:08 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id AECC9AD06;
	Fri, 14 Nov 2014 12:53:08 +0000 (UTC)
Message-ID: <5465FB34.9010606@suse.com>
Date: Fri, 14 Nov 2014 13:53:08 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	xen-devel@lists.xensource.com, jbeulich@suse.com, 
	konrad.wilk@oracle.com, david.vrabel@citrix.com
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>
	<5465EA63.3010007@citrix.com>
In-Reply-To: <5465EA63.3010007@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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

On 11/14/2014 12:41 PM, Andrew Cooper wrote:
> On 14/11/14 09:37, Juergen Gross wrote:
>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>> currently contains the mfn of the top level page frame of the 3 level
>> p2m tree, which is used by the Xen tools during saving and restoring
>> (and live migration) of pv domains and for crash dump analysis. With
>> three levels of the p2m tree it is possible to support up to 512 GB of
>> RAM for a 64 bit pv domain.
>>
>> A 32 bit pv domain can support more, as each memory page can hold 1024
>> instead of 512 entries, leading to a limit of 4 TB.
>>
>> To be able to support more RAM on x86-64 switch to a virtual mapped
>> p2m list.
>>
>> This patch expands struct arch_shared_info with a new p2m list virtual
>> address and the mfn of the page table root. The new information is
>> indicated by the domain to be valid by storing ~0UL into
>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of this
>> feature by a new flag XENFEAT_virtual_p2m.
>
> How do you envisage this being used?  Are you expecting the tools to do
> manual pagetable walks using xc_map_foreign_xxx() ?

Yes. Not very different compared to today's mapping via the 3 level
p2m tree. Just another entry format, 4 instead of 3 levels and starting
at an offset.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:53:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:53:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpGND-0006C9-JM; Fri, 14 Nov 2014 12:53:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpGNC-0006C4-2x
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 12:53:10 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	3E/3A-31453-53BF5645; Fri, 14 Nov 2014 12:53:09 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415969588!6003041!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7125 invoked from network); 14 Nov 2014 12:53:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 12:53:08 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id AECC9AD06;
	Fri, 14 Nov 2014 12:53:08 +0000 (UTC)
Message-ID: <5465FB34.9010606@suse.com>
Date: Fri, 14 Nov 2014 13:53:08 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	xen-devel@lists.xensource.com, jbeulich@suse.com, 
	konrad.wilk@oracle.com, david.vrabel@citrix.com
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>
	<5465EA63.3010007@citrix.com>
In-Reply-To: <5465EA63.3010007@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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

On 11/14/2014 12:41 PM, Andrew Cooper wrote:
> On 14/11/14 09:37, Juergen Gross wrote:
>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>> currently contains the mfn of the top level page frame of the 3 level
>> p2m tree, which is used by the Xen tools during saving and restoring
>> (and live migration) of pv domains and for crash dump analysis. With
>> three levels of the p2m tree it is possible to support up to 512 GB of
>> RAM for a 64 bit pv domain.
>>
>> A 32 bit pv domain can support more, as each memory page can hold 1024
>> instead of 512 entries, leading to a limit of 4 TB.
>>
>> To be able to support more RAM on x86-64 switch to a virtual mapped
>> p2m list.
>>
>> This patch expands struct arch_shared_info with a new p2m list virtual
>> address and the mfn of the page table root. The new information is
>> indicated by the domain to be valid by storing ~0UL into
>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of this
>> feature by a new flag XENFEAT_virtual_p2m.
>
> How do you envisage this being used?  Are you expecting the tools to do
> manual pagetable walks using xc_map_foreign_xxx() ?

Yes. Not very different compared to today's mapping via the 3 level
p2m tree. Just another entry format, 4 instead of 3 levels and starting
at an offset.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:58:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpGSG-0006bq-Aw; Fri, 14 Nov 2014 12:58:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpGSF-0006bk-FF
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 12:58:23 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	F7/A6-02696-E6CF5645; Fri, 14 Nov 2014 12:58:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415969900!12594922!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1945 invoked from network); 14 Nov 2014 12:58:21 -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;
	14 Nov 2014 12:58:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191364407"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 07:57:45 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpGRd-0000uC-3V;
	Fri, 14 Nov 2014 12:57:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpGRc-0000fe-Tr;
	Fri, 14 Nov 2014 12:57:44 +0000
Date: Fri, 14 Nov 2014 12:57:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31542-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11504
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31542: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6849528492063253047=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6849528492063253047==
Content-Type: text/plain
Content-Length: 11269
Content-Transfer-Encoding: quoted-printable

flight 31542 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31542/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10    fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                410bd787bf44ef95192507802967a0edce19955f
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 11876 lines long.)


--===============6849528492063253047==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6849528492063253047==--

From xen-devel-bounces@lists.xen.org Fri Nov 14 12:58:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 12:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpGSG-0006bq-Aw; Fri, 14 Nov 2014 12:58:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpGSF-0006bk-FF
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 12:58:23 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	F7/A6-02696-E6CF5645; Fri, 14 Nov 2014 12:58:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1415969900!12594922!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1945 invoked from network); 14 Nov 2014 12:58:21 -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;
	14 Nov 2014 12:58:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191364407"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 07:57:45 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpGRd-0000uC-3V;
	Fri, 14 Nov 2014 12:57:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpGRc-0000fe-Tr;
	Fri, 14 Nov 2014 12:57:44 +0000
Date: Fri, 14 Nov 2014 12:57:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31542-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11504
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31542: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6849528492063253047=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6849528492063253047==
Content-Type: text/plain
Content-Length: 11269
Content-Transfer-Encoding: quoted-printable

flight 31542 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31542/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10    fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                410bd787bf44ef95192507802967a0edce19955f
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 11876 lines long.)


--===============6849528492063253047==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6849528492063253047==--

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:15:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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.xen.org>)
	id 1XpGii-00073x-6G; Fri, 14 Nov 2014 13:15:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpGek-00073A-Hh
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 13:11:18 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	87/AD-01660-57FF5645; Fri, 14 Nov 2014 13:11:17 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415970676!8535677!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15513 invoked from network); 14 Nov 2014 13:11:17 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 14 Nov 2014 13:11:17 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:51948 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpGdc-0006iP-IC; Fri, 14 Nov 2014 14:10:08 +0100
Date: Fri, 14 Nov 2014 14:11:12 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <193010671.20141114141112@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	"Jan Beulich" <JBeulich@suse.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 14 Nov 2014 13:15:23 +0000
Subject: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad / Jan,

One of these commits:
- aeeea485bcfe2a517ed9bcb3ba1c3be0f6824e07 dpci: move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model
- f6dd295381f4b6a66acddacf46bca8940586c8d8 pci: replace tasklet with softirq

gives (running under 5 minutes of host boot, on AMD hardware and with guest with 
pci passthrough) the splat below.

--
Sander

(XEN) [2014-11-14 13:00:06.810] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) [2014-11-14 13:00:06.810] CPU:    3
(XEN) [2014-11-14 13:00:06.810] RIP:    e008:[<ffff82d080148f14>] dpci_softirq+0x9c/0x231
(XEN) [2014-11-14 13:00:06.810] RFLAGS: 0000000000010283   CONTEXT: hypervisor
(XEN) [2014-11-14 13:00:06.811] rax: 0000000000100100   rbx: ffff830515c86d90   rcx: 0000000000000001
(XEN) [2014-11-14 13:00:06.811] rdx: ffff83054ef30000   rsi: 0000000000000002   rdi: ffff830518b3b0b8
(XEN) [2014-11-14 13:00:06.811] rbp: ffff83054ef37eb0   rsp: ffff83054ef37e50   r8:  ffff830515c86d60
(XEN) [2014-11-14 13:00:06.811] r9:  0000016b62294400   r10: 0000016b63143e58   r11: 0000000000000246
(XEN) [2014-11-14 13:00:06.811] r12: ffff830515c86d38   r13: ffff830518b3b000   r14: ffff830515c86d28
(XEN) [2014-11-14 13:00:06.811] r15: ffff830515c86d28   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2014-11-14 13:00:06.811] cr3: 000000009fc92000   cr2: 0000000000100108
(XEN) [2014-11-14 13:00:06.811] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) [2014-11-14 13:00:06.811] Xen stack trace from rsp=ffff83054ef37e50:
(XEN) [2014-11-14 13:00:06.811]    ffff83054ef37e60 ffff830518b3b0b8 ffff830515c86d38 ffff83054ef37e70
(XEN) [2014-11-14 13:00:06.811]    ffff830515c86d90 ffff830515c86d90 ffff83054ef37ef0 ffff82d080300100
(XEN) [2014-11-14 13:00:06.811]    ffff82d0802fff80 ffffffffffffffff ffff83054ef30000 0000000000000002
(XEN) [2014-11-14 13:00:06.811]    ffff83054ef37ee0 ffff82d08012bd91 ffff83054ef30000 ffff83009faea000
(XEN) [2014-11-14 13:00:06.811]    00000000ffffffff ffff83054ef3e068 ffff83054ef37ef0 ffff82d08012bde9
(XEN) [2014-11-14 13:00:06.811]    ffff83054ef37f10 ffff82d0801623d5 ffff82d08012bde9 ffff83009fafd000
(XEN) [2014-11-14 13:00:06.811]    ffff83054ef37de8 ffffffff82200000 ffffffff82200000 0000000000000000
(XEN) [2014-11-14 13:00:06.811]    0000000000000000 ffffffff82203e28 ffffffff822f3ec0 0000000000000246
(XEN) [2014-11-14 13:00:06.811]    0000000000000001 0000000000000000 0000000000000000 0000000000000000
(XEN) [2014-11-14 13:00:06.811]    ffffffff810013aa ffffffff8221c520 00000000deadbeef 00000000deadbeef
(XEN) [2014-11-14 13:00:06.811]    0000010000000000 ffffffff810013aa 000000000000e033 0000000000000246
(XEN) [2014-11-14 13:00:06.811]    ffffffff82203e10 000000000000e02b 008000000000beef 000000000000beef
(XEN) [2014-11-14 13:00:06.811]    000000000000beef 00000000ffffbeef ffffea0000000003 ffff83009fafd000
(XEN) [2014-11-14 13:00:06.811]    00000034cec15280 0000000000000000
(XEN) [2014-11-14 13:00:06.811] Xen call trace:
(XEN) [2014-11-14 13:00:06.811]    [<ffff82d080148f14>] dpci_softirq+0x9c/0x231
(XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bd91>] __do_softirq+0x81/0x8c
(XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bde9>] do_softirq+0x13/0x15
(XEN) [2014-11-14 13:00:06.811]    [<ffff82d0801623d5>] idle_loop+0x5e/0x6e
(XEN) [2014-11-14 13:00:06.811] 
(XEN) [2014-11-14 13:00:06.811] Pagetable walk from 0000000000100108:
(XEN) [2014-11-14 13:00:06.811]  L4[0x000] = 000000055d09a063 ffffffffffffffff
(XEN) [2014-11-14 13:00:06.811]  L3[0x000] = 000000055d099063 ffffffffffffffff
(XEN) [2014-11-14 13:00:06.811]  L2[0x000] = 000000055d098063 ffffffffffffffff 
(XEN) [2014-11-14 13:00:06.811]  L1[0x100] = 0000000000000000 ffffffffffffffff
(XEN) [2014-11-14 13:00:07.692] 
(XEN) [2014-11-14 13:00:07.700] ****************************************
(XEN) [2014-11-14 13:00:07.720] Panic on CPU 3:
(XEN) [2014-11-14 13:00:07.732] FATAL PAGE FAULT
(XEN) [2014-11-14 13:00:07.745] [error_code=0000]
(XEN) [2014-11-14 13:00:07.759] Faulting linear address: 0000000000100108
(XEN) [2014-11-14 13:00:07.778] ****************************************
(XEN) [2014-11-14 13:00:07.797] 
(XEN) [2014-11-14 13:00:07.806] Reboot in five seconds...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:15:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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.xen.org>)
	id 1XpGii-00073x-6G; Fri, 14 Nov 2014 13:15:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpGek-00073A-Hh
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 13:11:18 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	87/AD-01660-57FF5645; Fri, 14 Nov 2014 13:11:17 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415970676!8535677!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15513 invoked from network); 14 Nov 2014 13:11:17 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 14 Nov 2014 13:11:17 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:51948 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpGdc-0006iP-IC; Fri, 14 Nov 2014 14:10:08 +0100
Date: Fri, 14 Nov 2014 14:11:12 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <193010671.20141114141112@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	"Jan Beulich" <JBeulich@suse.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 14 Nov 2014 13:15:23 +0000
Subject: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad / Jan,

One of these commits:
- aeeea485bcfe2a517ed9bcb3ba1c3be0f6824e07 dpci: move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model
- f6dd295381f4b6a66acddacf46bca8940586c8d8 pci: replace tasklet with softirq

gives (running under 5 minutes of host boot, on AMD hardware and with guest with 
pci passthrough) the splat below.

--
Sander

(XEN) [2014-11-14 13:00:06.810] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) [2014-11-14 13:00:06.810] CPU:    3
(XEN) [2014-11-14 13:00:06.810] RIP:    e008:[<ffff82d080148f14>] dpci_softirq+0x9c/0x231
(XEN) [2014-11-14 13:00:06.810] RFLAGS: 0000000000010283   CONTEXT: hypervisor
(XEN) [2014-11-14 13:00:06.811] rax: 0000000000100100   rbx: ffff830515c86d90   rcx: 0000000000000001
(XEN) [2014-11-14 13:00:06.811] rdx: ffff83054ef30000   rsi: 0000000000000002   rdi: ffff830518b3b0b8
(XEN) [2014-11-14 13:00:06.811] rbp: ffff83054ef37eb0   rsp: ffff83054ef37e50   r8:  ffff830515c86d60
(XEN) [2014-11-14 13:00:06.811] r9:  0000016b62294400   r10: 0000016b63143e58   r11: 0000000000000246
(XEN) [2014-11-14 13:00:06.811] r12: ffff830515c86d38   r13: ffff830518b3b000   r14: ffff830515c86d28
(XEN) [2014-11-14 13:00:06.811] r15: ffff830515c86d28   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2014-11-14 13:00:06.811] cr3: 000000009fc92000   cr2: 0000000000100108
(XEN) [2014-11-14 13:00:06.811] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) [2014-11-14 13:00:06.811] Xen stack trace from rsp=ffff83054ef37e50:
(XEN) [2014-11-14 13:00:06.811]    ffff83054ef37e60 ffff830518b3b0b8 ffff830515c86d38 ffff83054ef37e70
(XEN) [2014-11-14 13:00:06.811]    ffff830515c86d90 ffff830515c86d90 ffff83054ef37ef0 ffff82d080300100
(XEN) [2014-11-14 13:00:06.811]    ffff82d0802fff80 ffffffffffffffff ffff83054ef30000 0000000000000002
(XEN) [2014-11-14 13:00:06.811]    ffff83054ef37ee0 ffff82d08012bd91 ffff83054ef30000 ffff83009faea000
(XEN) [2014-11-14 13:00:06.811]    00000000ffffffff ffff83054ef3e068 ffff83054ef37ef0 ffff82d08012bde9
(XEN) [2014-11-14 13:00:06.811]    ffff83054ef37f10 ffff82d0801623d5 ffff82d08012bde9 ffff83009fafd000
(XEN) [2014-11-14 13:00:06.811]    ffff83054ef37de8 ffffffff82200000 ffffffff82200000 0000000000000000
(XEN) [2014-11-14 13:00:06.811]    0000000000000000 ffffffff82203e28 ffffffff822f3ec0 0000000000000246
(XEN) [2014-11-14 13:00:06.811]    0000000000000001 0000000000000000 0000000000000000 0000000000000000
(XEN) [2014-11-14 13:00:06.811]    ffffffff810013aa ffffffff8221c520 00000000deadbeef 00000000deadbeef
(XEN) [2014-11-14 13:00:06.811]    0000010000000000 ffffffff810013aa 000000000000e033 0000000000000246
(XEN) [2014-11-14 13:00:06.811]    ffffffff82203e10 000000000000e02b 008000000000beef 000000000000beef
(XEN) [2014-11-14 13:00:06.811]    000000000000beef 00000000ffffbeef ffffea0000000003 ffff83009fafd000
(XEN) [2014-11-14 13:00:06.811]    00000034cec15280 0000000000000000
(XEN) [2014-11-14 13:00:06.811] Xen call trace:
(XEN) [2014-11-14 13:00:06.811]    [<ffff82d080148f14>] dpci_softirq+0x9c/0x231
(XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bd91>] __do_softirq+0x81/0x8c
(XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bde9>] do_softirq+0x13/0x15
(XEN) [2014-11-14 13:00:06.811]    [<ffff82d0801623d5>] idle_loop+0x5e/0x6e
(XEN) [2014-11-14 13:00:06.811] 
(XEN) [2014-11-14 13:00:06.811] Pagetable walk from 0000000000100108:
(XEN) [2014-11-14 13:00:06.811]  L4[0x000] = 000000055d09a063 ffffffffffffffff
(XEN) [2014-11-14 13:00:06.811]  L3[0x000] = 000000055d099063 ffffffffffffffff
(XEN) [2014-11-14 13:00:06.811]  L2[0x000] = 000000055d098063 ffffffffffffffff 
(XEN) [2014-11-14 13:00:06.811]  L1[0x100] = 0000000000000000 ffffffffffffffff
(XEN) [2014-11-14 13:00:07.692] 
(XEN) [2014-11-14 13:00:07.700] ****************************************
(XEN) [2014-11-14 13:00:07.720] Panic on CPU 3:
(XEN) [2014-11-14 13:00:07.732] FATAL PAGE FAULT
(XEN) [2014-11-14 13:00:07.745] [error_code=0000]
(XEN) [2014-11-14 13:00:07.759] Faulting linear address: 0000000000100108
(XEN) [2014-11-14 13:00:07.778] ****************************************
(XEN) [2014-11-14 13:00:07.797] 
(XEN) [2014-11-14 13:00:07.806] Reboot in five seconds...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:29:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13: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.xen.org>)
	id 1XpGvk-0007iw-Mg; Fri, 14 Nov 2014 13:28:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1XpGvj-0007ir-0M
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 13:28:51 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	44/51-05632-29306645; Fri, 14 Nov 2014 13:28:50 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415971729!11473613!1
X-Originating-IP: [209.85.217.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19653 invoked from network); 14 Nov 2014 13:28:49 -0000
Received: from mail-lb0-f169.google.com (HELO mail-lb0-f169.google.com)
	(209.85.217.169)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 13:28:49 -0000
Received: by mail-lb0-f169.google.com with SMTP id 10so12989841lbg.28
	for <xen-devel@lists.xensource.com>;
	Fri, 14 Nov 2014 05:28:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=bPZAsIS5drKn7pzX1yfIKYloi1lwIdqMK8BORxv2+/E=;
	b=MysY88mCalzdQu5IrupHC0EIIb818SxuPI/9ic1/4UZECyjIccCJpkBbi/Q/+2duNO
	d8fj+oMr1Vlkyw1lDkm7Ya1xKGaePHcpxXmOSPY4WJPm1OAsy8CY9W/hyJLN52rIVW+i
	VhlXCynymxhUyevv+lByI5z7ZRPHwZFgtxGdb0v+hU58qg/Tj3idz9wY8yU8X2WaN8Vf
	scz+Cq2VOBto7TXZVTk8K3IjHzTp92Jxf70C6qZRRNOyy4aRW0kwtCfje/TLN77OH8hs
	/n5/VWedbPc5AhWFj1P6t2syuaxinDvHQaTuU8M2BSG6n/GCcCC24dRap0QXDyIl8wTF
	c8Lw==
X-Gm-Message-State: ALoCoQlFjBODu1msYbw7hV22YgaIGDhSsIjlr79JELgi2N3yC/q9eetgp8/sY6w2XnyAxrXvWHLp
X-Received: by 10.112.189.10 with SMTP id ge10mr8179424lbc.23.1415971729005;
	Fri, 14 Nov 2014 05:28:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.150.135 with HTTP; Fri, 14 Nov 2014 05:28:28 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Fri, 14 Nov 2014 13:28:28 +0000
Message-ID: <CAFEAcA9dxVOoGEet3Cuxeu6848udog342UJ66OzTPC1ns4H95A@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PULL for-2.2 0/2] Xen tree 2014-11-14
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14 November 2014 11:29, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> The following changes since commit c52e67924fbdadfa00668248f5c075542943c54c:
>
>   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2014-11-13 15:44:16 +0000)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2014-11-14
>
> for you to fetch changes up to 2f01dfacb56bc7a0d4639adc9dff9aae131e6216:
>
>   xen_disk: fix unmapping of persistent grants (2014-11-14 11:12:38 +0000)
>
> ----------------------------------------------------------------
> Igor Mammedov (1):
>       pc: piix4_pm: init legacy PCI hotplug when running on Xen
>
> Roger Pau Monne (1):
>       xen_disk: fix unmapping of persistent grants
>
>  hw/acpi/piix4.c     |    4 +++
>  hw/block/xen_disk.c |   72 ++++++++++++++++++++++++++++++++++++++++++++++-----
>  hw/i386/pc_piix.c   |   11 --------
>  3 files changed, 70 insertions(+), 17 deletions(-)

Applied, thanks.

-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:29:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13: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.xen.org>)
	id 1XpGvk-0007iw-Mg; Fri, 14 Nov 2014 13:28:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1XpGvj-0007ir-0M
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 13:28:51 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	44/51-05632-29306645; Fri, 14 Nov 2014 13:28:50 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415971729!11473613!1
X-Originating-IP: [209.85.217.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19653 invoked from network); 14 Nov 2014 13:28:49 -0000
Received: from mail-lb0-f169.google.com (HELO mail-lb0-f169.google.com)
	(209.85.217.169)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 13:28:49 -0000
Received: by mail-lb0-f169.google.com with SMTP id 10so12989841lbg.28
	for <xen-devel@lists.xensource.com>;
	Fri, 14 Nov 2014 05:28:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=bPZAsIS5drKn7pzX1yfIKYloi1lwIdqMK8BORxv2+/E=;
	b=MysY88mCalzdQu5IrupHC0EIIb818SxuPI/9ic1/4UZECyjIccCJpkBbi/Q/+2duNO
	d8fj+oMr1Vlkyw1lDkm7Ya1xKGaePHcpxXmOSPY4WJPm1OAsy8CY9W/hyJLN52rIVW+i
	VhlXCynymxhUyevv+lByI5z7ZRPHwZFgtxGdb0v+hU58qg/Tj3idz9wY8yU8X2WaN8Vf
	scz+Cq2VOBto7TXZVTk8K3IjHzTp92Jxf70C6qZRRNOyy4aRW0kwtCfje/TLN77OH8hs
	/n5/VWedbPc5AhWFj1P6t2syuaxinDvHQaTuU8M2BSG6n/GCcCC24dRap0QXDyIl8wTF
	c8Lw==
X-Gm-Message-State: ALoCoQlFjBODu1msYbw7hV22YgaIGDhSsIjlr79JELgi2N3yC/q9eetgp8/sY6w2XnyAxrXvWHLp
X-Received: by 10.112.189.10 with SMTP id ge10mr8179424lbc.23.1415971729005;
	Fri, 14 Nov 2014 05:28:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.150.135 with HTTP; Fri, 14 Nov 2014 05:28:28 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411141112540.26318@kaball.uk.xensource.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Fri, 14 Nov 2014 13:28:28 +0000
Message-ID: <CAFEAcA9dxVOoGEet3Cuxeu6848udog342UJ66OzTPC1ns4H95A@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PULL for-2.2 0/2] Xen tree 2014-11-14
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14 November 2014 11:29, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> The following changes since commit c52e67924fbdadfa00668248f5c075542943c54c:
>
>   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2014-11-13 15:44:16 +0000)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2014-11-14
>
> for you to fetch changes up to 2f01dfacb56bc7a0d4639adc9dff9aae131e6216:
>
>   xen_disk: fix unmapping of persistent grants (2014-11-14 11:12:38 +0000)
>
> ----------------------------------------------------------------
> Igor Mammedov (1):
>       pc: piix4_pm: init legacy PCI hotplug when running on Xen
>
> Roger Pau Monne (1):
>       xen_disk: fix unmapping of persistent grants
>
>  hw/acpi/piix4.c     |    4 +++
>  hw/block/xen_disk.c |   72 ++++++++++++++++++++++++++++++++++++++++++++++-----
>  hw/i386/pc_piix.c   |   11 --------
>  3 files changed, 70 insertions(+), 17 deletions(-)

Applied, thanks.

-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:32:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpGzF-0007uD-FX; Fri, 14 Nov 2014 13:32:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpGzE-0007u6-7p
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 13:32:28 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	5F/39-26858-B6406645; Fri, 14 Nov 2014 13:32:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415971945!11435082!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32186 invoked from network); 14 Nov 2014 13:32:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 13:32:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191374450"
Message-ID: <54660467.5060707@citrix.com>
Date: Fri, 14 Nov 2014 13:32:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Jan Beulich <JBeulich@suse.com>
References: <193010671.20141114141112@eikelenboom.it>
In-Reply-To: <193010671.20141114141112@eikelenboom.it>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 13:11, Sander Eikelenboom wrote:
> Hi Konrad / Jan,
>
> One of these commits:
> - aeeea485bcfe2a517ed9bcb3ba1c3be0f6824e07 dpci: move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model
> - f6dd295381f4b6a66acddacf46bca8940586c8d8 pci: replace tasklet with softirq
>
> gives (running under 5 minutes of host boot, on AMD hardware and with guest with 
> pci passthrough) the splat below.
>
> --
> Sander

I was hoping to get a chance to test this as well, but am currently
blocked on other issues.

Would you mind giving it a go at c/s aeeea485?  It is highly likely that
the bug is in f6dd295, but it would be nice to confirm that it want a
bug in the (hopefully noop) shuffling of the position of the tasklet.

~Andrew

>
> (XEN) [2014-11-14 13:00:06.810] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> (XEN) [2014-11-14 13:00:06.810] CPU:    3
> (XEN) [2014-11-14 13:00:06.810] RIP:    e008:[<ffff82d080148f14>] dpci_softirq+0x9c/0x231
> (XEN) [2014-11-14 13:00:06.810] RFLAGS: 0000000000010283   CONTEXT: hypervisor
> (XEN) [2014-11-14 13:00:06.811] rax: 0000000000100100   rbx: ffff830515c86d90   rcx: 0000000000000001
> (XEN) [2014-11-14 13:00:06.811] rdx: ffff83054ef30000   rsi: 0000000000000002   rdi: ffff830518b3b0b8
> (XEN) [2014-11-14 13:00:06.811] rbp: ffff83054ef37eb0   rsp: ffff83054ef37e50   r8:  ffff830515c86d60
> (XEN) [2014-11-14 13:00:06.811] r9:  0000016b62294400   r10: 0000016b63143e58   r11: 0000000000000246
> (XEN) [2014-11-14 13:00:06.811] r12: ffff830515c86d38   r13: ffff830518b3b000   r14: ffff830515c86d28
> (XEN) [2014-11-14 13:00:06.811] r15: ffff830515c86d28   cr0: 000000008005003b   cr4: 00000000000006f0
> (XEN) [2014-11-14 13:00:06.811] cr3: 000000009fc92000   cr2: 0000000000100108
> (XEN) [2014-11-14 13:00:06.811] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) [2014-11-14 13:00:06.811] Xen stack trace from rsp=ffff83054ef37e50:
> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37e60 ffff830518b3b0b8 ffff830515c86d38 ffff83054ef37e70
> (XEN) [2014-11-14 13:00:06.811]    ffff830515c86d90 ffff830515c86d90 ffff83054ef37ef0 ffff82d080300100
> (XEN) [2014-11-14 13:00:06.811]    ffff82d0802fff80 ffffffffffffffff ffff83054ef30000 0000000000000002
> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37ee0 ffff82d08012bd91 ffff83054ef30000 ffff83009faea000
> (XEN) [2014-11-14 13:00:06.811]    00000000ffffffff ffff83054ef3e068 ffff83054ef37ef0 ffff82d08012bde9
> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37f10 ffff82d0801623d5 ffff82d08012bde9 ffff83009fafd000
> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37de8 ffffffff82200000 ffffffff82200000 0000000000000000
> (XEN) [2014-11-14 13:00:06.811]    0000000000000000 ffffffff82203e28 ffffffff822f3ec0 0000000000000246
> (XEN) [2014-11-14 13:00:06.811]    0000000000000001 0000000000000000 0000000000000000 0000000000000000
> (XEN) [2014-11-14 13:00:06.811]    ffffffff810013aa ffffffff8221c520 00000000deadbeef 00000000deadbeef
> (XEN) [2014-11-14 13:00:06.811]    0000010000000000 ffffffff810013aa 000000000000e033 0000000000000246
> (XEN) [2014-11-14 13:00:06.811]    ffffffff82203e10 000000000000e02b 008000000000beef 000000000000beef
> (XEN) [2014-11-14 13:00:06.811]    000000000000beef 00000000ffffbeef ffffea0000000003 ffff83009fafd000
> (XEN) [2014-11-14 13:00:06.811]    00000034cec15280 0000000000000000
> (XEN) [2014-11-14 13:00:06.811] Xen call trace:
> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d080148f14>] dpci_softirq+0x9c/0x231
> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bd91>] __do_softirq+0x81/0x8c
> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bde9>] do_softirq+0x13/0x15
> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d0801623d5>] idle_loop+0x5e/0x6e
> (XEN) [2014-11-14 13:00:06.811] 
> (XEN) [2014-11-14 13:00:06.811] Pagetable walk from 0000000000100108:
> (XEN) [2014-11-14 13:00:06.811]  L4[0x000] = 000000055d09a063 ffffffffffffffff
> (XEN) [2014-11-14 13:00:06.811]  L3[0x000] = 000000055d099063 ffffffffffffffff
> (XEN) [2014-11-14 13:00:06.811]  L2[0x000] = 000000055d098063 ffffffffffffffff 
> (XEN) [2014-11-14 13:00:06.811]  L1[0x100] = 0000000000000000 ffffffffffffffff
> (XEN) [2014-11-14 13:00:07.692] 
> (XEN) [2014-11-14 13:00:07.700] ****************************************
> (XEN) [2014-11-14 13:00:07.720] Panic on CPU 3:
> (XEN) [2014-11-14 13:00:07.732] FATAL PAGE FAULT
> (XEN) [2014-11-14 13:00:07.745] [error_code=0000]
> (XEN) [2014-11-14 13:00:07.759] Faulting linear address: 0000000000100108
> (XEN) [2014-11-14 13:00:07.778] ****************************************
> (XEN) [2014-11-14 13:00:07.797] 
> (XEN) [2014-11-14 13:00:07.806] Reboot in five seconds...
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:32:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpGzF-0007uD-FX; Fri, 14 Nov 2014 13:32:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpGzE-0007u6-7p
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 13:32:28 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	5F/39-26858-B6406645; Fri, 14 Nov 2014 13:32:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1415971945!11435082!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32186 invoked from network); 14 Nov 2014 13:32:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 13:32:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,385,1413244800"; d="scan'208";a="191374450"
Message-ID: <54660467.5060707@citrix.com>
Date: Fri, 14 Nov 2014 13:32:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Jan Beulich <JBeulich@suse.com>
References: <193010671.20141114141112@eikelenboom.it>
In-Reply-To: <193010671.20141114141112@eikelenboom.it>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 13:11, Sander Eikelenboom wrote:
> Hi Konrad / Jan,
>
> One of these commits:
> - aeeea485bcfe2a517ed9bcb3ba1c3be0f6824e07 dpci: move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model
> - f6dd295381f4b6a66acddacf46bca8940586c8d8 pci: replace tasklet with softirq
>
> gives (running under 5 minutes of host boot, on AMD hardware and with guest with 
> pci passthrough) the splat below.
>
> --
> Sander

I was hoping to get a chance to test this as well, but am currently
blocked on other issues.

Would you mind giving it a go at c/s aeeea485?  It is highly likely that
the bug is in f6dd295, but it would be nice to confirm that it want a
bug in the (hopefully noop) shuffling of the position of the tasklet.

~Andrew

>
> (XEN) [2014-11-14 13:00:06.810] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> (XEN) [2014-11-14 13:00:06.810] CPU:    3
> (XEN) [2014-11-14 13:00:06.810] RIP:    e008:[<ffff82d080148f14>] dpci_softirq+0x9c/0x231
> (XEN) [2014-11-14 13:00:06.810] RFLAGS: 0000000000010283   CONTEXT: hypervisor
> (XEN) [2014-11-14 13:00:06.811] rax: 0000000000100100   rbx: ffff830515c86d90   rcx: 0000000000000001
> (XEN) [2014-11-14 13:00:06.811] rdx: ffff83054ef30000   rsi: 0000000000000002   rdi: ffff830518b3b0b8
> (XEN) [2014-11-14 13:00:06.811] rbp: ffff83054ef37eb0   rsp: ffff83054ef37e50   r8:  ffff830515c86d60
> (XEN) [2014-11-14 13:00:06.811] r9:  0000016b62294400   r10: 0000016b63143e58   r11: 0000000000000246
> (XEN) [2014-11-14 13:00:06.811] r12: ffff830515c86d38   r13: ffff830518b3b000   r14: ffff830515c86d28
> (XEN) [2014-11-14 13:00:06.811] r15: ffff830515c86d28   cr0: 000000008005003b   cr4: 00000000000006f0
> (XEN) [2014-11-14 13:00:06.811] cr3: 000000009fc92000   cr2: 0000000000100108
> (XEN) [2014-11-14 13:00:06.811] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) [2014-11-14 13:00:06.811] Xen stack trace from rsp=ffff83054ef37e50:
> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37e60 ffff830518b3b0b8 ffff830515c86d38 ffff83054ef37e70
> (XEN) [2014-11-14 13:00:06.811]    ffff830515c86d90 ffff830515c86d90 ffff83054ef37ef0 ffff82d080300100
> (XEN) [2014-11-14 13:00:06.811]    ffff82d0802fff80 ffffffffffffffff ffff83054ef30000 0000000000000002
> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37ee0 ffff82d08012bd91 ffff83054ef30000 ffff83009faea000
> (XEN) [2014-11-14 13:00:06.811]    00000000ffffffff ffff83054ef3e068 ffff83054ef37ef0 ffff82d08012bde9
> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37f10 ffff82d0801623d5 ffff82d08012bde9 ffff83009fafd000
> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37de8 ffffffff82200000 ffffffff82200000 0000000000000000
> (XEN) [2014-11-14 13:00:06.811]    0000000000000000 ffffffff82203e28 ffffffff822f3ec0 0000000000000246
> (XEN) [2014-11-14 13:00:06.811]    0000000000000001 0000000000000000 0000000000000000 0000000000000000
> (XEN) [2014-11-14 13:00:06.811]    ffffffff810013aa ffffffff8221c520 00000000deadbeef 00000000deadbeef
> (XEN) [2014-11-14 13:00:06.811]    0000010000000000 ffffffff810013aa 000000000000e033 0000000000000246
> (XEN) [2014-11-14 13:00:06.811]    ffffffff82203e10 000000000000e02b 008000000000beef 000000000000beef
> (XEN) [2014-11-14 13:00:06.811]    000000000000beef 00000000ffffbeef ffffea0000000003 ffff83009fafd000
> (XEN) [2014-11-14 13:00:06.811]    00000034cec15280 0000000000000000
> (XEN) [2014-11-14 13:00:06.811] Xen call trace:
> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d080148f14>] dpci_softirq+0x9c/0x231
> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bd91>] __do_softirq+0x81/0x8c
> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bde9>] do_softirq+0x13/0x15
> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d0801623d5>] idle_loop+0x5e/0x6e
> (XEN) [2014-11-14 13:00:06.811] 
> (XEN) [2014-11-14 13:00:06.811] Pagetable walk from 0000000000100108:
> (XEN) [2014-11-14 13:00:06.811]  L4[0x000] = 000000055d09a063 ffffffffffffffff
> (XEN) [2014-11-14 13:00:06.811]  L3[0x000] = 000000055d099063 ffffffffffffffff
> (XEN) [2014-11-14 13:00:06.811]  L2[0x000] = 000000055d098063 ffffffffffffffff 
> (XEN) [2014-11-14 13:00:06.811]  L1[0x100] = 0000000000000000 ffffffffffffffff
> (XEN) [2014-11-14 13:00:07.692] 
> (XEN) [2014-11-14 13:00:07.700] ****************************************
> (XEN) [2014-11-14 13:00:07.720] Panic on CPU 3:
> (XEN) [2014-11-14 13:00:07.732] FATAL PAGE FAULT
> (XEN) [2014-11-14 13:00:07.745] [error_code=0000]
> (XEN) [2014-11-14 13:00:07.759] Faulting linear address: 0000000000100108
> (XEN) [2014-11-14 13:00:07.778] ****************************************
> (XEN) [2014-11-14 13:00:07.797] 
> (XEN) [2014-11-14 13:00:07.806] Reboot in five seconds...
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:37:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpH4A-0008FA-6t; Fri, 14 Nov 2014 13:37:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpH49-0008F5-8j
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 13:37:33 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C7/B8-02957-C9506645; Fri, 14 Nov 2014 13:37:32 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415972250!12607136!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7507 invoked from network); 14 Nov 2014 13:37:31 -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;
	14 Nov 2014 13:37:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191376044"
Message-ID: <54660598.3060504@citrix.com>
Date: Fri, 14 Nov 2014 13:37:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Jan Beulich <JBeulich@suse.com>
References: <193010671.20141114141112@eikelenboom.it>
	<54660467.5060707@citrix.com>
In-Reply-To: <54660467.5060707@citrix.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 13:32, Andrew Cooper wrote:
> On 14/11/14 13:11, Sander Eikelenboom wrote:
>> Hi Konrad / Jan,
>>
>> One of these commits:
>> - aeeea485bcfe2a517ed9bcb3ba1c3be0f6824e07 dpci: move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model
>> - f6dd295381f4b6a66acddacf46bca8940586c8d8 pci: replace tasklet with softirq
>>
>> gives (running under 5 minutes of host boot, on AMD hardware and with guest with 
>> pci passthrough) the splat below.
>>
>> --
>> Sander
> I was hoping to get a chance to test this as well, but am currently
> blocked on other issues.
>
> Would you mind giving it a go at c/s aeeea485?  It is highly likely that
> the bug is in f6dd295, but it would be nice to confirm that it want a
> bug in the (hopefully noop) shuffling of the position of the tasklet.

Sorry - sent too soon.  I meant "..that it wasn't a bug in the.."

~Andrew

>> (XEN) [2014-11-14 13:00:06.810] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> (XEN) [2014-11-14 13:00:06.810] CPU:    3
>> (XEN) [2014-11-14 13:00:06.810] RIP:    e008:[<ffff82d080148f14>] dpci_softirq+0x9c/0x231
>> (XEN) [2014-11-14 13:00:06.810] RFLAGS: 0000000000010283   CONTEXT: hypervisor
>> (XEN) [2014-11-14 13:00:06.811] rax: 0000000000100100   rbx: ffff830515c86d90   rcx: 0000000000000001
>> (XEN) [2014-11-14 13:00:06.811] rdx: ffff83054ef30000   rsi: 0000000000000002   rdi: ffff830518b3b0b8
>> (XEN) [2014-11-14 13:00:06.811] rbp: ffff83054ef37eb0   rsp: ffff83054ef37e50   r8:  ffff830515c86d60
>> (XEN) [2014-11-14 13:00:06.811] r9:  0000016b62294400   r10: 0000016b63143e58   r11: 0000000000000246
>> (XEN) [2014-11-14 13:00:06.811] r12: ffff830515c86d38   r13: ffff830518b3b000   r14: ffff830515c86d28
>> (XEN) [2014-11-14 13:00:06.811] r15: ffff830515c86d28   cr0: 000000008005003b   cr4: 00000000000006f0
>> (XEN) [2014-11-14 13:00:06.811] cr3: 000000009fc92000   cr2: 0000000000100108
>> (XEN) [2014-11-14 13:00:06.811] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
>> (XEN) [2014-11-14 13:00:06.811] Xen stack trace from rsp=ffff83054ef37e50:
>> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37e60 ffff830518b3b0b8 ffff830515c86d38 ffff83054ef37e70
>> (XEN) [2014-11-14 13:00:06.811]    ffff830515c86d90 ffff830515c86d90 ffff83054ef37ef0 ffff82d080300100
>> (XEN) [2014-11-14 13:00:06.811]    ffff82d0802fff80 ffffffffffffffff ffff83054ef30000 0000000000000002
>> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37ee0 ffff82d08012bd91 ffff83054ef30000 ffff83009faea000
>> (XEN) [2014-11-14 13:00:06.811]    00000000ffffffff ffff83054ef3e068 ffff83054ef37ef0 ffff82d08012bde9
>> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37f10 ffff82d0801623d5 ffff82d08012bde9 ffff83009fafd000
>> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37de8 ffffffff82200000 ffffffff82200000 0000000000000000
>> (XEN) [2014-11-14 13:00:06.811]    0000000000000000 ffffffff82203e28 ffffffff822f3ec0 0000000000000246
>> (XEN) [2014-11-14 13:00:06.811]    0000000000000001 0000000000000000 0000000000000000 0000000000000000
>> (XEN) [2014-11-14 13:00:06.811]    ffffffff810013aa ffffffff8221c520 00000000deadbeef 00000000deadbeef
>> (XEN) [2014-11-14 13:00:06.811]    0000010000000000 ffffffff810013aa 000000000000e033 0000000000000246
>> (XEN) [2014-11-14 13:00:06.811]    ffffffff82203e10 000000000000e02b 008000000000beef 000000000000beef
>> (XEN) [2014-11-14 13:00:06.811]    000000000000beef 00000000ffffbeef ffffea0000000003 ffff83009fafd000
>> (XEN) [2014-11-14 13:00:06.811]    00000034cec15280 0000000000000000
>> (XEN) [2014-11-14 13:00:06.811] Xen call trace:
>> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d080148f14>] dpci_softirq+0x9c/0x231
>> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bd91>] __do_softirq+0x81/0x8c
>> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bde9>] do_softirq+0x13/0x15
>> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d0801623d5>] idle_loop+0x5e/0x6e
>> (XEN) [2014-11-14 13:00:06.811] 
>> (XEN) [2014-11-14 13:00:06.811] Pagetable walk from 0000000000100108:
>> (XEN) [2014-11-14 13:00:06.811]  L4[0x000] = 000000055d09a063 ffffffffffffffff
>> (XEN) [2014-11-14 13:00:06.811]  L3[0x000] = 000000055d099063 ffffffffffffffff
>> (XEN) [2014-11-14 13:00:06.811]  L2[0x000] = 000000055d098063 ffffffffffffffff 
>> (XEN) [2014-11-14 13:00:06.811]  L1[0x100] = 0000000000000000 ffffffffffffffff
>> (XEN) [2014-11-14 13:00:07.692] 
>> (XEN) [2014-11-14 13:00:07.700] ****************************************
>> (XEN) [2014-11-14 13:00:07.720] Panic on CPU 3:
>> (XEN) [2014-11-14 13:00:07.732] FATAL PAGE FAULT
>> (XEN) [2014-11-14 13:00:07.745] [error_code=0000]
>> (XEN) [2014-11-14 13:00:07.759] Faulting linear address: 0000000000100108
>> (XEN) [2014-11-14 13:00:07.778] ****************************************
>> (XEN) [2014-11-14 13:00:07.797] 
>> (XEN) [2014-11-14 13:00:07.806] Reboot in five seconds...
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:37:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpH4A-0008FA-6t; Fri, 14 Nov 2014 13:37:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpH49-0008F5-8j
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 13:37:33 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C7/B8-02957-C9506645; Fri, 14 Nov 2014 13:37:32 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415972250!12607136!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7507 invoked from network); 14 Nov 2014 13:37:31 -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;
	14 Nov 2014 13:37:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191376044"
Message-ID: <54660598.3060504@citrix.com>
Date: Fri, 14 Nov 2014 13:37:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Jan Beulich <JBeulich@suse.com>
References: <193010671.20141114141112@eikelenboom.it>
	<54660467.5060707@citrix.com>
In-Reply-To: <54660467.5060707@citrix.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 13:32, Andrew Cooper wrote:
> On 14/11/14 13:11, Sander Eikelenboom wrote:
>> Hi Konrad / Jan,
>>
>> One of these commits:
>> - aeeea485bcfe2a517ed9bcb3ba1c3be0f6824e07 dpci: move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model
>> - f6dd295381f4b6a66acddacf46bca8940586c8d8 pci: replace tasklet with softirq
>>
>> gives (running under 5 minutes of host boot, on AMD hardware and with guest with 
>> pci passthrough) the splat below.
>>
>> --
>> Sander
> I was hoping to get a chance to test this as well, but am currently
> blocked on other issues.
>
> Would you mind giving it a go at c/s aeeea485?  It is highly likely that
> the bug is in f6dd295, but it would be nice to confirm that it want a
> bug in the (hopefully noop) shuffling of the position of the tasklet.

Sorry - sent too soon.  I meant "..that it wasn't a bug in the.."

~Andrew

>> (XEN) [2014-11-14 13:00:06.810] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> (XEN) [2014-11-14 13:00:06.810] CPU:    3
>> (XEN) [2014-11-14 13:00:06.810] RIP:    e008:[<ffff82d080148f14>] dpci_softirq+0x9c/0x231
>> (XEN) [2014-11-14 13:00:06.810] RFLAGS: 0000000000010283   CONTEXT: hypervisor
>> (XEN) [2014-11-14 13:00:06.811] rax: 0000000000100100   rbx: ffff830515c86d90   rcx: 0000000000000001
>> (XEN) [2014-11-14 13:00:06.811] rdx: ffff83054ef30000   rsi: 0000000000000002   rdi: ffff830518b3b0b8
>> (XEN) [2014-11-14 13:00:06.811] rbp: ffff83054ef37eb0   rsp: ffff83054ef37e50   r8:  ffff830515c86d60
>> (XEN) [2014-11-14 13:00:06.811] r9:  0000016b62294400   r10: 0000016b63143e58   r11: 0000000000000246
>> (XEN) [2014-11-14 13:00:06.811] r12: ffff830515c86d38   r13: ffff830518b3b000   r14: ffff830515c86d28
>> (XEN) [2014-11-14 13:00:06.811] r15: ffff830515c86d28   cr0: 000000008005003b   cr4: 00000000000006f0
>> (XEN) [2014-11-14 13:00:06.811] cr3: 000000009fc92000   cr2: 0000000000100108
>> (XEN) [2014-11-14 13:00:06.811] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
>> (XEN) [2014-11-14 13:00:06.811] Xen stack trace from rsp=ffff83054ef37e50:
>> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37e60 ffff830518b3b0b8 ffff830515c86d38 ffff83054ef37e70
>> (XEN) [2014-11-14 13:00:06.811]    ffff830515c86d90 ffff830515c86d90 ffff83054ef37ef0 ffff82d080300100
>> (XEN) [2014-11-14 13:00:06.811]    ffff82d0802fff80 ffffffffffffffff ffff83054ef30000 0000000000000002
>> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37ee0 ffff82d08012bd91 ffff83054ef30000 ffff83009faea000
>> (XEN) [2014-11-14 13:00:06.811]    00000000ffffffff ffff83054ef3e068 ffff83054ef37ef0 ffff82d08012bde9
>> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37f10 ffff82d0801623d5 ffff82d08012bde9 ffff83009fafd000
>> (XEN) [2014-11-14 13:00:06.811]    ffff83054ef37de8 ffffffff82200000 ffffffff82200000 0000000000000000
>> (XEN) [2014-11-14 13:00:06.811]    0000000000000000 ffffffff82203e28 ffffffff822f3ec0 0000000000000246
>> (XEN) [2014-11-14 13:00:06.811]    0000000000000001 0000000000000000 0000000000000000 0000000000000000
>> (XEN) [2014-11-14 13:00:06.811]    ffffffff810013aa ffffffff8221c520 00000000deadbeef 00000000deadbeef
>> (XEN) [2014-11-14 13:00:06.811]    0000010000000000 ffffffff810013aa 000000000000e033 0000000000000246
>> (XEN) [2014-11-14 13:00:06.811]    ffffffff82203e10 000000000000e02b 008000000000beef 000000000000beef
>> (XEN) [2014-11-14 13:00:06.811]    000000000000beef 00000000ffffbeef ffffea0000000003 ffff83009fafd000
>> (XEN) [2014-11-14 13:00:06.811]    00000034cec15280 0000000000000000
>> (XEN) [2014-11-14 13:00:06.811] Xen call trace:
>> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d080148f14>] dpci_softirq+0x9c/0x231
>> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bd91>] __do_softirq+0x81/0x8c
>> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d08012bde9>] do_softirq+0x13/0x15
>> (XEN) [2014-11-14 13:00:06.811]    [<ffff82d0801623d5>] idle_loop+0x5e/0x6e
>> (XEN) [2014-11-14 13:00:06.811] 
>> (XEN) [2014-11-14 13:00:06.811] Pagetable walk from 0000000000100108:
>> (XEN) [2014-11-14 13:00:06.811]  L4[0x000] = 000000055d09a063 ffffffffffffffff
>> (XEN) [2014-11-14 13:00:06.811]  L3[0x000] = 000000055d099063 ffffffffffffffff
>> (XEN) [2014-11-14 13:00:06.811]  L2[0x000] = 000000055d098063 ffffffffffffffff 
>> (XEN) [2014-11-14 13:00:06.811]  L1[0x100] = 0000000000000000 ffffffffffffffff
>> (XEN) [2014-11-14 13:00:07.692] 
>> (XEN) [2014-11-14 13:00:07.700] ****************************************
>> (XEN) [2014-11-14 13:00:07.720] Panic on CPU 3:
>> (XEN) [2014-11-14 13:00:07.732] FATAL PAGE FAULT
>> (XEN) [2014-11-14 13:00:07.745] [error_code=0000]
>> (XEN) [2014-11-14 13:00:07.759] Faulting linear address: 0000000000100108
>> (XEN) [2014-11-14 13:00:07.778] ****************************************
>> (XEN) [2014-11-14 13:00:07.797] 
>> (XEN) [2014-11-14 13:00:07.806] Reboot in five seconds...
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:57:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHMk-0000Xb-6h; Fri, 14 Nov 2014 13:56:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpHMi-0000XT-6x
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 13:56:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EF/27-09842-B1A06645; Fri, 14 Nov 2014 13:56:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415973401!12737174!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12142 invoked from network); 14 Nov 2014 13:56:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 13:56:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191381384"
Message-ID: <54660A16.2090006@citrix.com>
Date: Fri, 14 Nov 2014 13:56:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xensource.com>,
	<jbeulich@suse.com>, <konrad.wilk@oracle.com>, <david.vrabel@citrix.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>
	<5465EA63.3010007@citrix.com> <5465FB34.9010606@suse.com>
In-Reply-To: <5465FB34.9010606@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 12:53, Juergen Gross wrote:
> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>> On 14/11/14 09:37, Juergen Gross wrote:
>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>> currently contains the mfn of the top level page frame of the 3 level
>>> p2m tree, which is used by the Xen tools during saving and restoring
>>> (and live migration) of pv domains and for crash dump analysis. With
>>> three levels of the p2m tree it is possible to support up to 512 GB of
>>> RAM for a 64 bit pv domain.
>>>
>>> A 32 bit pv domain can support more, as each memory page can hold 1024
>>> instead of 512 entries, leading to a limit of 4 TB.
>>>
>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>> p2m list.
>>>
>>> This patch expands struct arch_shared_info with a new p2m list virtual
>>> address and the mfn of the page table root. The new information is
>>> indicated by the domain to be valid by storing ~0UL into
>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of this
>>> feature by a new flag XENFEAT_virtual_p2m.
>>
>> How do you envisage this being used?  Are you expecting the tools to do
>> manual pagetable walks using xc_map_foreign_xxx() ?
>
> Yes. Not very different compared to today's mapping via the 3 level
> p2m tree. Just another entry format, 4 instead of 3 levels and starting
> at an offset.

Yes - David and I were discussing this over lunch, and it is not
actually very different.

In reality, how likely is it that the pages backing this virtual linear
array change?

One issue currently is that, during the live part of migration, the
toolstack has no way of working out whether the structure of the p2m has
changed (intermediate leaves rearranged, or the length increasing).

In the case that the VM does change the structure of the p2m under the
feet of the toolstack, migration will either blow up in a non-subtle way
with a p2m/m2p mismatch, or in a subtle way with the receiving side
copying the new p2m over the wrong part of the new domain.

I am wondering whether, with this new p2m method, we can take sufficient
steps to be able to guarantee mishaps like this can't occur.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:57:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHMk-0000Xb-6h; Fri, 14 Nov 2014 13:56:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpHMi-0000XT-6x
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 13:56:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EF/27-09842-B1A06645; Fri, 14 Nov 2014 13:56:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1415973401!12737174!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12142 invoked from network); 14 Nov 2014 13:56:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 13:56:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191381384"
Message-ID: <54660A16.2090006@citrix.com>
Date: Fri, 14 Nov 2014 13:56:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xensource.com>,
	<jbeulich@suse.com>, <konrad.wilk@oracle.com>, <david.vrabel@citrix.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>
	<5465EA63.3010007@citrix.com> <5465FB34.9010606@suse.com>
In-Reply-To: <5465FB34.9010606@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 12:53, Juergen Gross wrote:
> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>> On 14/11/14 09:37, Juergen Gross wrote:
>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>> currently contains the mfn of the top level page frame of the 3 level
>>> p2m tree, which is used by the Xen tools during saving and restoring
>>> (and live migration) of pv domains and for crash dump analysis. With
>>> three levels of the p2m tree it is possible to support up to 512 GB of
>>> RAM for a 64 bit pv domain.
>>>
>>> A 32 bit pv domain can support more, as each memory page can hold 1024
>>> instead of 512 entries, leading to a limit of 4 TB.
>>>
>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>> p2m list.
>>>
>>> This patch expands struct arch_shared_info with a new p2m list virtual
>>> address and the mfn of the page table root. The new information is
>>> indicated by the domain to be valid by storing ~0UL into
>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of this
>>> feature by a new flag XENFEAT_virtual_p2m.
>>
>> How do you envisage this being used?  Are you expecting the tools to do
>> manual pagetable walks using xc_map_foreign_xxx() ?
>
> Yes. Not very different compared to today's mapping via the 3 level
> p2m tree. Just another entry format, 4 instead of 3 levels and starting
> at an offset.

Yes - David and I were discussing this over lunch, and it is not
actually very different.

In reality, how likely is it that the pages backing this virtual linear
array change?

One issue currently is that, during the live part of migration, the
toolstack has no way of working out whether the structure of the p2m has
changed (intermediate leaves rearranged, or the length increasing).

In the case that the VM does change the structure of the p2m under the
feet of the toolstack, migration will either blow up in a non-subtle way
with a p2m/m2p mismatch, or in a subtle way with the receiving side
copying the new p2m over the wrong part of the new domain.

I am wondering whether, with this new p2m method, we can take sufficient
steps to be able to guarantee mishaps like this can't occur.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:57:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHNd-0000b5-QO; Fri, 14 Nov 2014 13:57:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpHNc-0000ar-Ky
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 13:57:40 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B4/4C-17958-35A06645; Fri, 14 Nov 2014 13:57:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415973459!11372834!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3590 invoked from network); 14 Nov 2014 13:57:39 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 13:57:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 13:57:38 +0000
Message-Id: <546618620200007800047AD1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 13:57:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <193010671.20141114141112@eikelenboom.it>
In-Reply-To: <193010671.20141114141112@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 14:11, <linux@eikelenboom.it> wrote:
> (XEN) [2014-11-14 13:00:06.810] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> (XEN) [2014-11-14 13:00:06.810] CPU:    3
> (XEN) [2014-11-14 13:00:06.810] RIP:    e008:[<ffff82d080148f14>] dpci_softirq+0x9c/0x231
> (XEN) [2014-11-14 13:00:06.810] RFLAGS: 0000000000010283   CONTEXT: hypervisor
> (XEN) [2014-11-14 13:00:06.811] rax: 0000000000100100   rbx: ffff830515c86d90  rcx: 0000000000000001

This and ...

> (XEN) [2014-11-14 13:00:06.811] Pagetable walk from 0000000000100108:
> (XEN) [2014-11-14 13:00:06.811]  L4[0x000] = 000000055d09a063 ffffffffffffffff
> (XEN) [2014-11-14 13:00:06.811]  L3[0x000] = 000000055d099063 ffffffffffffffff
> (XEN) [2014-11-14 13:00:06.811]  L2[0x000] = 000000055d098063 ffffffffffffffff 

... this suggest it hit a poisoned list entry, due to

#define LIST_POISON1  ((void *) 0x00100100)

But without you helping out with associating the crash location with
a source line (or allowing us to do so by making xen-syms available
somewhere) this is going to remain guesswork.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:57:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHNd-0000b5-QO; Fri, 14 Nov 2014 13:57:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpHNc-0000ar-Ky
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 13:57:40 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B4/4C-17958-35A06645; Fri, 14 Nov 2014 13:57:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415973459!11372834!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3590 invoked from network); 14 Nov 2014 13:57:39 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 13:57:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 13:57:38 +0000
Message-Id: <546618620200007800047AD1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 13:57:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <193010671.20141114141112@eikelenboom.it>
In-Reply-To: <193010671.20141114141112@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 14:11, <linux@eikelenboom.it> wrote:
> (XEN) [2014-11-14 13:00:06.810] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> (XEN) [2014-11-14 13:00:06.810] CPU:    3
> (XEN) [2014-11-14 13:00:06.810] RIP:    e008:[<ffff82d080148f14>] dpci_softirq+0x9c/0x231
> (XEN) [2014-11-14 13:00:06.810] RFLAGS: 0000000000010283   CONTEXT: hypervisor
> (XEN) [2014-11-14 13:00:06.811] rax: 0000000000100100   rbx: ffff830515c86d90  rcx: 0000000000000001

This and ...

> (XEN) [2014-11-14 13:00:06.811] Pagetable walk from 0000000000100108:
> (XEN) [2014-11-14 13:00:06.811]  L4[0x000] = 000000055d09a063 ffffffffffffffff
> (XEN) [2014-11-14 13:00:06.811]  L3[0x000] = 000000055d099063 ffffffffffffffff
> (XEN) [2014-11-14 13:00:06.811]  L2[0x000] = 000000055d098063 ffffffffffffffff 

... this suggest it hit a poisoned list entry, due to

#define LIST_POISON1  ((void *) 0x00100100)

But without you helping out with associating the crash location with
a source line (or allowing us to do so by making xen-syms available
somewhere) this is going to remain guesswork.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:57:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13:57:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHNg-0000br-79; Fri, 14 Nov 2014 13:57:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpHNe-0000bH-Th
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 13:57:43 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	07/C6-02953-65A06645; Fri, 14 Nov 2014 13:57:42 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415973458!12576677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16497 invoked from network); 14 Nov 2014 13:57:39 -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;
	14 Nov 2014 13:57:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192847404"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 08:57:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpHNZ-0000rj-6z;
	Fri, 14 Nov 2014 13:57:37 +0000
Date: Fri, 14 Nov 2014 13:57:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
In-Reply-To: <54648AB7.5010706@redhat.com>
Message-ID: <alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: mst@redhat.com, liang.z.li@intel.com,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	aliguori@amazon.com, qemu-devel@nongun.org,
	Igor Mammedov <imammedo@redhat.com>, rth@twiddle.net
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
 running 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

Konrad,
this is another bug fix for QEMU: pci hotplug doesn't work when
xen_platform_pci=0 without this.

I think we should have it in 4.5. What do you think?

- Stefano

On Thu, 13 Nov 2014, Paolo Bonzini wrote:
> On 13/11/2014 03:30, Li Liang wrote:
> > If user starts QEMU with "-machine pc,accel=xen", then
> > compat property in xenfv won't work and it would cause error:
> > "Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set"
> > when PCI device is added with -device on QEMU CLI.
> > 
> > In case of Xen instead of using compat property, just use the fact
> > that xen doesn't use QEMU's fw_cfg/acpi tables to switch piix4_pm
> > into legacy PCI hotplug mode when Xen is enabled.
> > 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > [liang.z.li@intel.com: use "xen_enabled()" instead of "!fw_cfg"]
> > Signed-off-by: Li Liang <liang.z.li@intel.com>
> > ---
> >  hw/acpi/piix4.c   |  4 ++++
> >  hw/i386/pc_piix.c | 11 -----------
> >  2 files changed, 4 insertions(+), 11 deletions(-)
> > 
> > diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> > index 78c0a6d..481a16c 100644
> > --- a/hw/acpi/piix4.c
> > +++ b/hw/acpi/piix4.c
> > @@ -36,6 +36,7 @@
> >  #include "hw/mem/pc-dimm.h"
> >  #include "hw/acpi/memory_hotplug.h"
> >  #include "hw/acpi/acpi_dev_interface.h"
> > +#include "hw/xen/xen.h"
> >  
> >  //#define DEBUG
> >  
> > @@ -501,6 +502,9 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
> >      s->irq = sci_irq;
> >      s->smi_irq = smi_irq;
> >      s->kvm_enabled = kvm_enabled;
> > +    if (xen_enabled()) {
> > +        s->use_acpi_pci_hotplug = false;
> > +    }
> >  
> >      qdev_init_nofail(dev);
> >  
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > index b559181..7bb97a4 100644
> > --- a/hw/i386/pc_piix.c
> > +++ b/hw/i386/pc_piix.c
> > @@ -916,17 +916,6 @@ static QEMUMachine xenfv_machine = {
> >      .max_cpus = HVM_MAX_VCPUS,
> >      .default_machine_opts = "accel=xen",
> >      .hot_add_cpu = pc_hot_add_cpu,
> > -    .compat_props = (GlobalProperty[]) {
> > -        /* xenfv has no fwcfg and so does not load acpi from QEMU.
> > -         * as such new acpi features don't work.
> > -         */
> > -        {
> > -            .driver   = "PIIX4_PM",
> > -            .property = "acpi-pci-hotplug-with-bridge-support",
> > -            .value    = "off",
> > -        },
> > -        { /* end of list */ }
> > -    },
> >  };
> >  #endif
> >  
> > 
> 
> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> Stefano, are you going to send the pull request yourself?
> 
> Paolo
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 13:57:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 13:57:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHNg-0000br-79; Fri, 14 Nov 2014 13:57:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpHNe-0000bH-Th
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 13:57:43 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	07/C6-02953-65A06645; Fri, 14 Nov 2014 13:57:42 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415973458!12576677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16497 invoked from network); 14 Nov 2014 13:57:39 -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;
	14 Nov 2014 13:57:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192847404"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 08:57:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpHNZ-0000rj-6z;
	Fri, 14 Nov 2014 13:57:37 +0000
Date: Fri, 14 Nov 2014 13:57:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
In-Reply-To: <54648AB7.5010706@redhat.com>
Message-ID: <alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: mst@redhat.com, liang.z.li@intel.com,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	aliguori@amazon.com, qemu-devel@nongun.org,
	Igor Mammedov <imammedo@redhat.com>, rth@twiddle.net
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
 running 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

Konrad,
this is another bug fix for QEMU: pci hotplug doesn't work when
xen_platform_pci=0 without this.

I think we should have it in 4.5. What do you think?

- Stefano

On Thu, 13 Nov 2014, Paolo Bonzini wrote:
> On 13/11/2014 03:30, Li Liang wrote:
> > If user starts QEMU with "-machine pc,accel=xen", then
> > compat property in xenfv won't work and it would cause error:
> > "Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set"
> > when PCI device is added with -device on QEMU CLI.
> > 
> > In case of Xen instead of using compat property, just use the fact
> > that xen doesn't use QEMU's fw_cfg/acpi tables to switch piix4_pm
> > into legacy PCI hotplug mode when Xen is enabled.
> > 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > [liang.z.li@intel.com: use "xen_enabled()" instead of "!fw_cfg"]
> > Signed-off-by: Li Liang <liang.z.li@intel.com>
> > ---
> >  hw/acpi/piix4.c   |  4 ++++
> >  hw/i386/pc_piix.c | 11 -----------
> >  2 files changed, 4 insertions(+), 11 deletions(-)
> > 
> > diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> > index 78c0a6d..481a16c 100644
> > --- a/hw/acpi/piix4.c
> > +++ b/hw/acpi/piix4.c
> > @@ -36,6 +36,7 @@
> >  #include "hw/mem/pc-dimm.h"
> >  #include "hw/acpi/memory_hotplug.h"
> >  #include "hw/acpi/acpi_dev_interface.h"
> > +#include "hw/xen/xen.h"
> >  
> >  //#define DEBUG
> >  
> > @@ -501,6 +502,9 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
> >      s->irq = sci_irq;
> >      s->smi_irq = smi_irq;
> >      s->kvm_enabled = kvm_enabled;
> > +    if (xen_enabled()) {
> > +        s->use_acpi_pci_hotplug = false;
> > +    }
> >  
> >      qdev_init_nofail(dev);
> >  
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > index b559181..7bb97a4 100644
> > --- a/hw/i386/pc_piix.c
> > +++ b/hw/i386/pc_piix.c
> > @@ -916,17 +916,6 @@ static QEMUMachine xenfv_machine = {
> >      .max_cpus = HVM_MAX_VCPUS,
> >      .default_machine_opts = "accel=xen",
> >      .hot_add_cpu = pc_hot_add_cpu,
> > -    .compat_props = (GlobalProperty[]) {
> > -        /* xenfv has no fwcfg and so does not load acpi from QEMU.
> > -         * as such new acpi features don't work.
> > -         */
> > -        {
> > -            .driver   = "PIIX4_PM",
> > -            .property = "acpi-pci-hotplug-with-bridge-support",
> > -            .value    = "off",
> > -        },
> > -        { /* end of list */ }
> > -    },
> >  };
> >  #endif
> >  
> > 
> 
> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> Stefano, are you going to send the pull request yourself?
> 
> Paolo
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:15:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14: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 1XpHeK-0001Wr-7D; Fri, 14 Nov 2014 14:14:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpHeJ-0001Wm-4w
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 14:14:55 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	A0/EB-27785-E5E06645; Fri, 14 Nov 2014 14:14:54 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415974493!12610506!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32193 invoked from network); 14 Nov 2014 14:14:53 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 14:14:53 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CBA5AADA4;
	Fri, 14 Nov 2014 14:14:52 +0000 (UTC)
Message-ID: <54660E5C.8030107@suse.com>
Date: Fri, 14 Nov 2014 15:14:52 +0100
From: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	xen-devel@lists.xensource.com, jbeulich@suse.com, 
	konrad.wilk@oracle.com, david.vrabel@citrix.com
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>
	<5465FB34.9010606@suse.com> <54660A16.2090006@citrix.com>
In-Reply-To: <54660A16.2090006@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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

On 11/14/2014 02:56 PM, Andrew Cooper wrote:
> On 14/11/14 12:53, Juergen Gross wrote:
>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>> currently contains the mfn of the top level page frame of the 3 level
>>>> p2m tree, which is used by the Xen tools during saving and restoring
>>>> (and live migration) of pv domains and for crash dump analysis. With
>>>> three levels of the p2m tree it is possible to support up to 512 GB of
>>>> RAM for a 64 bit pv domain.
>>>>
>>>> A 32 bit pv domain can support more, as each memory page can hold 1024
>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>
>>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>>> p2m list.
>>>>
>>>> This patch expands struct arch_shared_info with a new p2m list virtual
>>>> address and the mfn of the page table root. The new information is
>>>> indicated by the domain to be valid by storing ~0UL into
>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of this
>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>
>>> How do you envisage this being used?  Are you expecting the tools to do
>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>
>> Yes. Not very different compared to today's mapping via the 3 level
>> p2m tree. Just another entry format, 4 instead of 3 levels and starting
>> at an offset.
>
> Yes - David and I were discussing this over lunch, and it is not
> actually very different.
>
> In reality, how likely is it that the pages backing this virtual linear
> array change?

Very unlikely, I think. But not impossible.

> One issue currently is that, during the live part of migration, the
> toolstack has no way of working out whether the structure of the p2m has
> changed (intermediate leaves rearranged, or the length increasing).
>
> In the case that the VM does change the structure of the p2m under the
> feet of the toolstack, migration will either blow up in a non-subtle way
> with a p2m/m2p mismatch, or in a subtle way with the receiving side
> copying the new p2m over the wrong part of the new domain.
>
> I am wondering whether, with this new p2m method, we can take sufficient
> steps to be able to guarantee mishaps like this can't occur.

This should be easy: I could add a counter in arch_shared_info which is
incremented whenever a p2m mapping is being changed. The toolstack could
compare the counter values before start and at end of migration and redo
the migration (or fail) if they are different. In order to avoid races
I would have to increment the counter before and after changing the
mapping.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:15:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14: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 1XpHeK-0001Wr-7D; Fri, 14 Nov 2014 14:14:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpHeJ-0001Wm-4w
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 14:14:55 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	A0/EB-27785-E5E06645; Fri, 14 Nov 2014 14:14:54 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415974493!12610506!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32193 invoked from network); 14 Nov 2014 14:14:53 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 14:14:53 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CBA5AADA4;
	Fri, 14 Nov 2014 14:14:52 +0000 (UTC)
Message-ID: <54660E5C.8030107@suse.com>
Date: Fri, 14 Nov 2014 15:14:52 +0100
From: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	xen-devel@lists.xensource.com, jbeulich@suse.com, 
	konrad.wilk@oracle.com, david.vrabel@citrix.com
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>
	<5465FB34.9010606@suse.com> <54660A16.2090006@citrix.com>
In-Reply-To: <54660A16.2090006@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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

On 11/14/2014 02:56 PM, Andrew Cooper wrote:
> On 14/11/14 12:53, Juergen Gross wrote:
>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>> currently contains the mfn of the top level page frame of the 3 level
>>>> p2m tree, which is used by the Xen tools during saving and restoring
>>>> (and live migration) of pv domains and for crash dump analysis. With
>>>> three levels of the p2m tree it is possible to support up to 512 GB of
>>>> RAM for a 64 bit pv domain.
>>>>
>>>> A 32 bit pv domain can support more, as each memory page can hold 1024
>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>
>>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>>> p2m list.
>>>>
>>>> This patch expands struct arch_shared_info with a new p2m list virtual
>>>> address and the mfn of the page table root. The new information is
>>>> indicated by the domain to be valid by storing ~0UL into
>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of this
>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>
>>> How do you envisage this being used?  Are you expecting the tools to do
>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>
>> Yes. Not very different compared to today's mapping via the 3 level
>> p2m tree. Just another entry format, 4 instead of 3 levels and starting
>> at an offset.
>
> Yes - David and I were discussing this over lunch, and it is not
> actually very different.
>
> In reality, how likely is it that the pages backing this virtual linear
> array change?

Very unlikely, I think. But not impossible.

> One issue currently is that, during the live part of migration, the
> toolstack has no way of working out whether the structure of the p2m has
> changed (intermediate leaves rearranged, or the length increasing).
>
> In the case that the VM does change the structure of the p2m under the
> feet of the toolstack, migration will either blow up in a non-subtle way
> with a p2m/m2p mismatch, or in a subtle way with the receiving side
> copying the new p2m over the wrong part of the new domain.
>
> I am wondering whether, with this new p2m method, we can take sufficient
> steps to be able to guarantee mishaps like this can't occur.

This should be easy: I could add a counter in arch_shared_info which is
incremented whenever a p2m mapping is being changed. The toolstack could
compare the counter values before start and at end of migration and redo
the migration (or fail) if they are different. In order to avoid races
I would have to increment the counter before and after changing the
mapping.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:23:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHm5-0001xW-AV; Fri, 14 Nov 2014 14:22:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1XpHm4-0001xR-5i
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:22:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	83/B8-09936-F3016645; Fri, 14 Nov 2014 14:22:55 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415974973!12784432!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21770 invoked from network); 14 Nov 2014 14:22:53 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:22:53 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so2863689wib.1
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 06:22:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=zTKmkUWDaQfnwpCLIonkAxOtW4o29+LIl0EH18Y6iJ4=;
	b=QCRluuozTYA3YwiZaaq6sdQojkKMdwVDJJ8vKTOncSLQZBGyYnq3MUIRk9lre488X7
	87rrYWfsF/im86k0+rFKpdqU31PTWrg4qmlsu2VU0bMb/M9MMa04z2+TU4Pp0MNazLys
	pVRShULYwYDLQ42j+K1k5YfHWqUa3HL5BRCQOxC0KkkqikcK8i56mgBsAphXHzy/U9G8
	kkLpIaPBIVRPw7oIDtdhnLEXcX73eiPGdKX7HigiwAgEsHE6l1M42uIUcTmYHTogQXqm
	aQh2KDPEJTE0GT4OSWJAo/LPmRlDeci33qTYz7jvEbQVCwGmlt31jh9R1UAvRN9cYA68
	4QqA==
MIME-Version: 1.0
X-Received: by 10.180.126.37 with SMTP id mv5mr8065023wib.2.1415974973604;
	Fri, 14 Nov 2014 06:22:53 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Fri, 14 Nov 2014 06:22:53 -0800 (PST)
In-Reply-To: <545D564E.4000106@tycho.nsa.gov>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>
	<545BEE4F.3080305@tycho.nsa.gov>
	<CAAULxKJwTAdVKGrb5p=j701dAO=PWLYsdX6LpYRbmrAUuAM86A@mail.gmail.com>
	<545D564E.4000106@tycho.nsa.gov>
Date: Fri, 14 Nov 2014 16:22:53 +0200
Message-ID: <CAAULxKLkbau3WsLAiAYXee+mtJN6RTtkBHP=W7bOQTa_pE-nEQ@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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: multipart/mixed; boundary="===============7179403939769863870=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7179403939769863870==
Content-Type: multipart/alternative; boundary=e89a8f839d7d50094a0507d25deb

--e89a8f839d7d50094a0507d25deb
Content-Type: text/plain; charset=UTF-8

I modified linux kernel tpm_tis driver to try to start with locality 2. I
did some logging and after taking a look with dmesg it seems that the IO
pages for other localities are full with 1.
in tpm_tis_init:
for(i=0;i<5;i++){
    release_locality(chip,i,1);
}
...
wait_startup(chip,2);
request_locality(chip,2)
...
TPM_RID(2);//FF
TPM_RID(0);//64
Would this mean that Atmel disabled other localities after manufacturing? I
tried to define a NVRAM index at F200 but I have the same results.

I see what you mean about changing the DeepQuote behaviour in order to
provide evidence of the VM launch but I am not sure that I understand what
is the type of extraInfoFlags and what should it contain. Will the UUIDs
and vTPM measurements be stored in extraInfoFlags?
If we take this as a solution for systems that do not support DRTM lanch,
they will still be forced to use locality 0 if any other is disabled and
the TPM might return busy if other commands are currently running.

Thanks.
Emil Condrea

On Sat, Nov 8, 2014 at 1:31 AM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
wrote:

> On 11/07/2014 05:40 AM, Emil Condrea wrote:
>
>> My system does not support DRTM so I can not test this. I am interested in
>> contributing to vtpm and making this to work without DRTM, can you give me
>> more details about PCRs that need to be implemented using an alternate
>> manner? When someone wants to use other locality than 0 it will run all
>> commands with PCRs disabled? Since the vtpmmgr is tying domU to hardware
>> TPM, deactivating PCRs will result that all commands issued by domU will
>> not use PCRs anymore, right?
>>
>
> The PCRs seen by the domU are emulated by the vTPM, and the vTPM Manager
> has no information on any of their values or updates.  Deep quotes may
> include a hash of the vTPM's PCR values, but the vTPM Manager is only
> asserting that the hash was given by the vTPM.
>
>  Where should the new layer of PCR values stored? NVRAM ?
>>
>
> They will be stored in the vtpmmgr domain's RAM; in fact, they are already
> stored there (they just need to be used more directly).
>
> The PCRs in question are PCR 20-23, used by the vTPM Manager to store
> information about the vTPM making a deep quote request.  In order to
> support more than one vTPM, the values of these PCRs need to be reset when
> a different client connects.  However, the reset operation for PCR 20-22 is
> limited to locality 2.
>
> An alternative to this is to embed this information in the externData
> field that is signed by the quote operation.  This requires a bit more work
> to provide the same flexibility that the PCRs provided, but it can be made
> equivalently secure.
>
> A deep quote request currently contains a PCR mask and a requestData value
> (20 bytes) from the vTPM.  On a deep quote request, the vTPM Manager:
>  1. Reset PCR 20-23
>  2. Extend information about the requesting vTPM to PCR 20-23
>    - Different information is extended into each PCR
>    - Some clients want all information, some only want selected PCRs
>  3. Perform a Quote with externData=requestData on the requested PCRs
>  4. Return the result to the requesting vTPM
>
> The change I am suggesting requires:
>  - Add a field to the request - extraInfoFlags
>  - Compute externData = SHA1 (
>         requestData
>         extraInfoFlags
>         [UUIDs if requested]
>         [vTPM measurements if requested]
>         [vTPM group update policy if requested]
>   )
>  - Perform deep quotes using the above externData value instead of the
> value provided by the vTPM.
>
> This change also has the benefit of increasing the flexibility of the
> request - it is simple to define additional flags and add data to the hash
> if needed.
>
>
>  On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> wrote:
>>
>>  On 11/05/2014 05:00 AM, Ian Campbell wrote:
>>>
>>>  CCing Daniel.
>>>>
>>>> On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
>>>>
>>>>
>>>>> I am wondering if this is known issue that when I set locality!=0 to
>>>>> vtpmmgr it does not start. It is a bit strange that every call to
>>>>> tpm_tis_status returns 255 and device-id is also FFFF:
>>>>> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
>>>>> TPM interface capabilities (0xffffffff):
>>>>>
>>>>> I am configuring vtpmmgr using:
>>>>>
>>>>> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
>>>>> memory=8
>>>>> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
>>>>> name="vtpmmgr"
>>>>> iomem=["fed40,5"]
>>>>> extra="tpmlocality=2"
>>>>>
>>>>>
>>>>> I also tried using :
>>>>> iomem=["fed40,1"]
>>>>> extra="tpmlocality=0"//works well
>>>>>
>>>>> or
>>>>> iomem=["fed42,1"]
>>>>> extra="tpmlocality=2"
>>>>> It seems that everything that is not mapped at fed40-fed41 is
>>>>> FFFFFFFF.
>>>>>
>>>>> I have an Atmel TPM chipset.
>>>>>
>>>>> Could it be a chipset problem to not handle well different localities?
>>>>>
>>>>> When I use locality=0, the device driver info is correct and
>>>>> everything works fine:
>>>>> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
>>>>> TPM interface capabilities (0xfd)
>>>>>
>>>>>
>>>>  This may be an issue with locality 2 being unavailable unless a DRTM
>>> launch (tboot) is performed.  Returning all-ones is the normal response
>>> of the x86 chipset when unmapped MMIO regions are accessed; disabled
>>> localities of the TPM may act like this.
>>>
>>> Does your system support the DRTM launch?  If so, can you test it to see
>>> if this is the issue?
>>>
>>> In this case, to better support people who want to use the vTPM Manager
>>> without a DRTM launch, the features of the vTPM Manager that use the TPM
>>> 1.2 PCRs may need to be disabled or implemented in an alternate manner
>>> such as embedding the data in the quote instead of in PCRs.  The current
>>> design was created with the assumption that systems using it would be
>>> performing a DRTM launch in order to fully secure the boot process.
>>>
>>>   In linux kernel this information is obtained using locality 0 and
>>>
>>>> after that other commands execute using specified locality.
>>>>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-
>>>>> stable.git/tree/drivers/char/tpm/tpm_tis.c#n558
>>>>>
>>>>>
>>>>  Have you tested that other localities work for your TPM under Linux?
>>>
>>
>>
>>
>>
>>
>>>  Thanks,
>>>>>
>>>>> Emil
>>>>>
>>>>>
>>>>>  --
>>> Daniel De Graaf
>>> National Security Agency
>>>
>>>
>>
>
> --
> Daniel De Graaf
> National Security Agency
>

--e89a8f839d7d50094a0507d25deb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I modified linux kernel tpm_tis driver to try to start wit=
h locality 2. I did some logging and after taking a look with dmesg it seem=
s that the IO pages for other localities are full with 1.<div>in tpm_tis_in=
it:</div><div>for(i=3D0;i&lt;5;i++){</div><div>=C2=A0 =C2=A0 release_locali=
ty(chip,i,1);</div><div>}</div><div>...</div><div>wait_startup(chip,2);</di=
v><div>request_locality(chip,2)</div><div>...</div><div>TPM_RID(2);//FF</di=
v><div>TPM_RID(0);//64</div><div>Would this mean that Atmel disabled other =
localities after manufacturing? I tried to define a NVRAM index at F200 but=
 I have the same results.</div><div><br></div><div>I see what you mean abou=
t changing the DeepQuote behaviour in order to provide evidence of the VM l=
aunch but I am not sure that I understand what is the type of extraInfoFlag=
s and what should it contain. Will the UUIDs and vTPM measurements be store=
d in extraInfoFlags?</div><div><span style=3D"font-family:arial,sans-serif;=
font-size:13px">If we take this as a solution for systems that do not suppo=
rt DRTM lanch, they will still be forced to use locality 0 if any other is =
disabled and the TPM might return busy if other commands are currently runn=
ing.</span></div><div><br></div><div>Thanks.</div><div>Emil Condrea</div></=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Nov 8=
, 2014 at 1:31 AM, Daniel De Graaf <span dir=3D"ltr">&lt;<a href=3D"mailto:=
dgdegra@tycho.nsa.gov" target=3D"_blank">dgdegra@tycho.nsa.gov</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 11/07/2014 =
05:40 AM, Emil Condrea wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
My system does not support DRTM so I can not test this. I am interested in<=
br>
contributing to vtpm and making this to work without DRTM, can you give me<=
br>
more details about PCRs that need to be implemented using an alternate<br>
manner? When someone wants to use other locality than 0 it will run all<br>
commands with PCRs disabled? Since the vtpmmgr is tying domU to hardware<br=
>
TPM, deactivating PCRs will result that all commands issued by domU will<br=
>
not use PCRs anymore, right?<br>
</blockquote>
<br></span>
The PCRs seen by the domU are emulated by the vTPM, and the vTPM Manager ha=
s no information on any of their values or updates.=C2=A0 Deep quotes may i=
nclude a hash of the vTPM&#39;s PCR values, but the vTPM Manager is only as=
serting that the hash was given by the vTPM.<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Where should the new layer of PCR values stored? NVRAM ?<br>
</blockquote>
<br></span>
They will be stored in the vtpmmgr domain&#39;s RAM; in fact, they are alre=
ady stored there (they just need to be used more directly).<br>
<br>
The PCRs in question are PCR 20-23, used by the vTPM Manager to store infor=
mation about the vTPM making a deep quote request.=C2=A0 In order to suppor=
t more than one vTPM, the values of these PCRs need to be reset when a diff=
erent client connects.=C2=A0 However, the reset operation for PCR 20-22 is =
limited to locality 2.<br>
<br>
An alternative to this is to embed this information in the externData field=
 that is signed by the quote operation.=C2=A0 This requires a bit more work=
 to provide the same flexibility that the PCRs provided, but it can be made=
 equivalently secure.<br>
<br>
A deep quote request currently contains a PCR mask and a requestData value =
(20 bytes) from the vTPM.=C2=A0 On a deep quote request, the vTPM Manager:<=
br>
=C2=A01. Reset PCR 20-23<br>
=C2=A02. Extend information about the requesting vTPM to PCR 20-23<br>
=C2=A0 =C2=A0- Different information is extended into each PCR<br>
=C2=A0 =C2=A0- Some clients want all information, some only want selected P=
CRs<br>
=C2=A03. Perform a Quote with externData=3DrequestData on the requested PCR=
s<br>
=C2=A04. Return the result to the requesting vTPM<br>
<br>
The change I am suggesting requires:<br>
=C2=A0- Add a field to the request - extraInfoFlags<br>
=C2=A0- Compute externData =3D SHA1 (<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 requestData<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 extraInfoFlags<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [UUIDs if requested]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [vTPM measurements if requested]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [vTPM group update policy if requested]<br>
=C2=A0 )<br>
=C2=A0- Perform deep quotes using the above externData value instead of the=
 value provided by the vTPM.<br>
<br>
This change also has the benefit of increasing the flexibility of the reque=
st - it is simple to define additional flags and add data to the hash if ne=
eded.<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf &lt;<a href=3D"mailto:dgde=
gra@tycho.nsa.gov" target=3D"_blank">dgdegra@tycho.nsa.gov</a>&gt;<br>
wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 11/05/2014 05:00 AM, Ian Campbell wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
CCing Daniel.<br>
<br>
On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
I am wondering if this is known issue that when I set locality!=3D0 to<br>
vtpmmgr it does not start. It is a bit strange that every call to<br>
tpm_tis_status returns 255 and device-id is also FFFF:<br>
1.2 TPM (device-id=3D0xFFFF vendor-id =3D FFFF rev-id =3D FF).<br>
TPM interface capabilities (0xffffffff):<br>
<br>
I am configuring vtpmmgr using:<br>
<br>
kernel=3D&quot;/usr/local/lib/xen/<u></u>boot/vtpmmgr-stubdom.gz&quot;<br>
memory=3D8<br>
disk=3D[&quot;file:/var/vtpmmgr-<u></u>stubdom.img,hda,w&quot;]<br>
name=3D&quot;vtpmmgr&quot;<br>
iomem=3D[&quot;fed40,5&quot;]<br>
extra=3D&quot;tpmlocality=3D2&quot;<br>
<br>
<br>
I also tried using :<br>
iomem=3D[&quot;fed40,1&quot;]<br>
extra=3D&quot;tpmlocality=3D0&quot;//works well<br>
<br>
or<br>
iomem=3D[&quot;fed42,1&quot;]<br>
extra=3D&quot;tpmlocality=3D2&quot;<br>
It seems that everything that is not mapped at fed40-fed41 is<br>
FFFFFFFF.<br>
<br>
I have an Atmel TPM chipset.<br>
<br>
Could it be a chipset problem to not handle well different localities?<br>
<br>
When I use locality=3D0, the device driver info is correct and<br>
everything works fine:<br>
1.2 TPM (device-id=3D0x3204 vendor-id =3D 1114 rev-id =3D 40)<br>
TPM interface capabilities (0xfd)<br>
<br>
</blockquote>
<br>
</blockquote>
This may be an issue with locality 2 being unavailable unless a DRTM<br>
launch (tboot) is performed.=C2=A0 Returning all-ones is the normal respons=
e<br>
of the x86 chipset when unmapped MMIO regions are accessed; disabled<br>
localities of the TPM may act like this.<br>
<br>
Does your system support the DRTM launch?=C2=A0 If so, can you test it to s=
ee<br>
if this is the issue?<br>
<br>
In this case, to better support people who want to use the vTPM Manager<br>
without a DRTM launch, the features of the vTPM Manager that use the TPM<br=
>
1.2 PCRs may need to be disabled or implemented in an alternate manner<br>
such as embedding the data in the quote instead of in PCRs.=C2=A0 The curre=
nt<br>
design was created with the assumption that systems using it would be<br>
performing a DRTM launch in order to fully secure the boot process.<br>
<br>
=C2=A0 In linux kernel this information is obtained using locality 0 and<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
after that other commands execute using specified locality.<br>
<a href=3D"https://git.kernel.org/cgit/linux/kernel/git/stable/linux-" targ=
et=3D"_blank">https://git.kernel.org/cgit/<u></u>linux/kernel/git/stable/li=
nux-</a><br>
stable.git/tree/drivers/char/<u></u>tpm/tpm_tis.c#n558<br>
<br>
</blockquote>
<br>
</blockquote>
Have you tested that other localities work for your TPM under Linux?<br>
</blockquote>
<br>
<br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
<br>
Emil<br>
<br>
<br>
</blockquote></blockquote>
--<br>
Daniel De Graaf<br>
National Security Agency<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
-- <br>
Daniel De Graaf<br>
National Security Agency<br>
</div></div></blockquote></div><br></div>

--e89a8f839d7d50094a0507d25deb--


--===============7179403939769863870==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7179403939769863870==--


From xen-devel-bounces@lists.xen.org Fri Nov 14 14:23:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHm5-0001xW-AV; Fri, 14 Nov 2014 14:22:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1XpHm4-0001xR-5i
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:22:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	83/B8-09936-F3016645; Fri, 14 Nov 2014 14:22:55 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1415974973!12784432!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21770 invoked from network); 14 Nov 2014 14:22:53 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:22:53 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so2863689wib.1
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 06:22:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=zTKmkUWDaQfnwpCLIonkAxOtW4o29+LIl0EH18Y6iJ4=;
	b=QCRluuozTYA3YwiZaaq6sdQojkKMdwVDJJ8vKTOncSLQZBGyYnq3MUIRk9lre488X7
	87rrYWfsF/im86k0+rFKpdqU31PTWrg4qmlsu2VU0bMb/M9MMa04z2+TU4Pp0MNazLys
	pVRShULYwYDLQ42j+K1k5YfHWqUa3HL5BRCQOxC0KkkqikcK8i56mgBsAphXHzy/U9G8
	kkLpIaPBIVRPw7oIDtdhnLEXcX73eiPGdKX7HigiwAgEsHE6l1M42uIUcTmYHTogQXqm
	aQh2KDPEJTE0GT4OSWJAo/LPmRlDeci33qTYz7jvEbQVCwGmlt31jh9R1UAvRN9cYA68
	4QqA==
MIME-Version: 1.0
X-Received: by 10.180.126.37 with SMTP id mv5mr8065023wib.2.1415974973604;
	Fri, 14 Nov 2014 06:22:53 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Fri, 14 Nov 2014 06:22:53 -0800 (PST)
In-Reply-To: <545D564E.4000106@tycho.nsa.gov>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>
	<545BEE4F.3080305@tycho.nsa.gov>
	<CAAULxKJwTAdVKGrb5p=j701dAO=PWLYsdX6LpYRbmrAUuAM86A@mail.gmail.com>
	<545D564E.4000106@tycho.nsa.gov>
Date: Fri, 14 Nov 2014 16:22:53 +0200
Message-ID: <CAAULxKLkbau3WsLAiAYXee+mtJN6RTtkBHP=W7bOQTa_pE-nEQ@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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: multipart/mixed; boundary="===============7179403939769863870=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7179403939769863870==
Content-Type: multipart/alternative; boundary=e89a8f839d7d50094a0507d25deb

--e89a8f839d7d50094a0507d25deb
Content-Type: text/plain; charset=UTF-8

I modified linux kernel tpm_tis driver to try to start with locality 2. I
did some logging and after taking a look with dmesg it seems that the IO
pages for other localities are full with 1.
in tpm_tis_init:
for(i=0;i<5;i++){
    release_locality(chip,i,1);
}
...
wait_startup(chip,2);
request_locality(chip,2)
...
TPM_RID(2);//FF
TPM_RID(0);//64
Would this mean that Atmel disabled other localities after manufacturing? I
tried to define a NVRAM index at F200 but I have the same results.

I see what you mean about changing the DeepQuote behaviour in order to
provide evidence of the VM launch but I am not sure that I understand what
is the type of extraInfoFlags and what should it contain. Will the UUIDs
and vTPM measurements be stored in extraInfoFlags?
If we take this as a solution for systems that do not support DRTM lanch,
they will still be forced to use locality 0 if any other is disabled and
the TPM might return busy if other commands are currently running.

Thanks.
Emil Condrea

On Sat, Nov 8, 2014 at 1:31 AM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
wrote:

> On 11/07/2014 05:40 AM, Emil Condrea wrote:
>
>> My system does not support DRTM so I can not test this. I am interested in
>> contributing to vtpm and making this to work without DRTM, can you give me
>> more details about PCRs that need to be implemented using an alternate
>> manner? When someone wants to use other locality than 0 it will run all
>> commands with PCRs disabled? Since the vtpmmgr is tying domU to hardware
>> TPM, deactivating PCRs will result that all commands issued by domU will
>> not use PCRs anymore, right?
>>
>
> The PCRs seen by the domU are emulated by the vTPM, and the vTPM Manager
> has no information on any of their values or updates.  Deep quotes may
> include a hash of the vTPM's PCR values, but the vTPM Manager is only
> asserting that the hash was given by the vTPM.
>
>  Where should the new layer of PCR values stored? NVRAM ?
>>
>
> They will be stored in the vtpmmgr domain's RAM; in fact, they are already
> stored there (they just need to be used more directly).
>
> The PCRs in question are PCR 20-23, used by the vTPM Manager to store
> information about the vTPM making a deep quote request.  In order to
> support more than one vTPM, the values of these PCRs need to be reset when
> a different client connects.  However, the reset operation for PCR 20-22 is
> limited to locality 2.
>
> An alternative to this is to embed this information in the externData
> field that is signed by the quote operation.  This requires a bit more work
> to provide the same flexibility that the PCRs provided, but it can be made
> equivalently secure.
>
> A deep quote request currently contains a PCR mask and a requestData value
> (20 bytes) from the vTPM.  On a deep quote request, the vTPM Manager:
>  1. Reset PCR 20-23
>  2. Extend information about the requesting vTPM to PCR 20-23
>    - Different information is extended into each PCR
>    - Some clients want all information, some only want selected PCRs
>  3. Perform a Quote with externData=requestData on the requested PCRs
>  4. Return the result to the requesting vTPM
>
> The change I am suggesting requires:
>  - Add a field to the request - extraInfoFlags
>  - Compute externData = SHA1 (
>         requestData
>         extraInfoFlags
>         [UUIDs if requested]
>         [vTPM measurements if requested]
>         [vTPM group update policy if requested]
>   )
>  - Perform deep quotes using the above externData value instead of the
> value provided by the vTPM.
>
> This change also has the benefit of increasing the flexibility of the
> request - it is simple to define additional flags and add data to the hash
> if needed.
>
>
>  On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> wrote:
>>
>>  On 11/05/2014 05:00 AM, Ian Campbell wrote:
>>>
>>>  CCing Daniel.
>>>>
>>>> On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
>>>>
>>>>
>>>>> I am wondering if this is known issue that when I set locality!=0 to
>>>>> vtpmmgr it does not start. It is a bit strange that every call to
>>>>> tpm_tis_status returns 255 and device-id is also FFFF:
>>>>> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
>>>>> TPM interface capabilities (0xffffffff):
>>>>>
>>>>> I am configuring vtpmmgr using:
>>>>>
>>>>> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
>>>>> memory=8
>>>>> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
>>>>> name="vtpmmgr"
>>>>> iomem=["fed40,5"]
>>>>> extra="tpmlocality=2"
>>>>>
>>>>>
>>>>> I also tried using :
>>>>> iomem=["fed40,1"]
>>>>> extra="tpmlocality=0"//works well
>>>>>
>>>>> or
>>>>> iomem=["fed42,1"]
>>>>> extra="tpmlocality=2"
>>>>> It seems that everything that is not mapped at fed40-fed41 is
>>>>> FFFFFFFF.
>>>>>
>>>>> I have an Atmel TPM chipset.
>>>>>
>>>>> Could it be a chipset problem to not handle well different localities?
>>>>>
>>>>> When I use locality=0, the device driver info is correct and
>>>>> everything works fine:
>>>>> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
>>>>> TPM interface capabilities (0xfd)
>>>>>
>>>>>
>>>>  This may be an issue with locality 2 being unavailable unless a DRTM
>>> launch (tboot) is performed.  Returning all-ones is the normal response
>>> of the x86 chipset when unmapped MMIO regions are accessed; disabled
>>> localities of the TPM may act like this.
>>>
>>> Does your system support the DRTM launch?  If so, can you test it to see
>>> if this is the issue?
>>>
>>> In this case, to better support people who want to use the vTPM Manager
>>> without a DRTM launch, the features of the vTPM Manager that use the TPM
>>> 1.2 PCRs may need to be disabled or implemented in an alternate manner
>>> such as embedding the data in the quote instead of in PCRs.  The current
>>> design was created with the assumption that systems using it would be
>>> performing a DRTM launch in order to fully secure the boot process.
>>>
>>>   In linux kernel this information is obtained using locality 0 and
>>>
>>>> after that other commands execute using specified locality.
>>>>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-
>>>>> stable.git/tree/drivers/char/tpm/tpm_tis.c#n558
>>>>>
>>>>>
>>>>  Have you tested that other localities work for your TPM under Linux?
>>>
>>
>>
>>
>>
>>
>>>  Thanks,
>>>>>
>>>>> Emil
>>>>>
>>>>>
>>>>>  --
>>> Daniel De Graaf
>>> National Security Agency
>>>
>>>
>>
>
> --
> Daniel De Graaf
> National Security Agency
>

--e89a8f839d7d50094a0507d25deb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I modified linux kernel tpm_tis driver to try to start wit=
h locality 2. I did some logging and after taking a look with dmesg it seem=
s that the IO pages for other localities are full with 1.<div>in tpm_tis_in=
it:</div><div>for(i=3D0;i&lt;5;i++){</div><div>=C2=A0 =C2=A0 release_locali=
ty(chip,i,1);</div><div>}</div><div>...</div><div>wait_startup(chip,2);</di=
v><div>request_locality(chip,2)</div><div>...</div><div>TPM_RID(2);//FF</di=
v><div>TPM_RID(0);//64</div><div>Would this mean that Atmel disabled other =
localities after manufacturing? I tried to define a NVRAM index at F200 but=
 I have the same results.</div><div><br></div><div>I see what you mean abou=
t changing the DeepQuote behaviour in order to provide evidence of the VM l=
aunch but I am not sure that I understand what is the type of extraInfoFlag=
s and what should it contain. Will the UUIDs and vTPM measurements be store=
d in extraInfoFlags?</div><div><span style=3D"font-family:arial,sans-serif;=
font-size:13px">If we take this as a solution for systems that do not suppo=
rt DRTM lanch, they will still be forced to use locality 0 if any other is =
disabled and the TPM might return busy if other commands are currently runn=
ing.</span></div><div><br></div><div>Thanks.</div><div>Emil Condrea</div></=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Nov 8=
, 2014 at 1:31 AM, Daniel De Graaf <span dir=3D"ltr">&lt;<a href=3D"mailto:=
dgdegra@tycho.nsa.gov" target=3D"_blank">dgdegra@tycho.nsa.gov</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 11/07/2014 =
05:40 AM, Emil Condrea wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
My system does not support DRTM so I can not test this. I am interested in<=
br>
contributing to vtpm and making this to work without DRTM, can you give me<=
br>
more details about PCRs that need to be implemented using an alternate<br>
manner? When someone wants to use other locality than 0 it will run all<br>
commands with PCRs disabled? Since the vtpmmgr is tying domU to hardware<br=
>
TPM, deactivating PCRs will result that all commands issued by domU will<br=
>
not use PCRs anymore, right?<br>
</blockquote>
<br></span>
The PCRs seen by the domU are emulated by the vTPM, and the vTPM Manager ha=
s no information on any of their values or updates.=C2=A0 Deep quotes may i=
nclude a hash of the vTPM&#39;s PCR values, but the vTPM Manager is only as=
serting that the hash was given by the vTPM.<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Where should the new layer of PCR values stored? NVRAM ?<br>
</blockquote>
<br></span>
They will be stored in the vtpmmgr domain&#39;s RAM; in fact, they are alre=
ady stored there (they just need to be used more directly).<br>
<br>
The PCRs in question are PCR 20-23, used by the vTPM Manager to store infor=
mation about the vTPM making a deep quote request.=C2=A0 In order to suppor=
t more than one vTPM, the values of these PCRs need to be reset when a diff=
erent client connects.=C2=A0 However, the reset operation for PCR 20-22 is =
limited to locality 2.<br>
<br>
An alternative to this is to embed this information in the externData field=
 that is signed by the quote operation.=C2=A0 This requires a bit more work=
 to provide the same flexibility that the PCRs provided, but it can be made=
 equivalently secure.<br>
<br>
A deep quote request currently contains a PCR mask and a requestData value =
(20 bytes) from the vTPM.=C2=A0 On a deep quote request, the vTPM Manager:<=
br>
=C2=A01. Reset PCR 20-23<br>
=C2=A02. Extend information about the requesting vTPM to PCR 20-23<br>
=C2=A0 =C2=A0- Different information is extended into each PCR<br>
=C2=A0 =C2=A0- Some clients want all information, some only want selected P=
CRs<br>
=C2=A03. Perform a Quote with externData=3DrequestData on the requested PCR=
s<br>
=C2=A04. Return the result to the requesting vTPM<br>
<br>
The change I am suggesting requires:<br>
=C2=A0- Add a field to the request - extraInfoFlags<br>
=C2=A0- Compute externData =3D SHA1 (<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 requestData<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 extraInfoFlags<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [UUIDs if requested]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [vTPM measurements if requested]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [vTPM group update policy if requested]<br>
=C2=A0 )<br>
=C2=A0- Perform deep quotes using the above externData value instead of the=
 value provided by the vTPM.<br>
<br>
This change also has the benefit of increasing the flexibility of the reque=
st - it is simple to define additional flags and add data to the hash if ne=
eded.<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf &lt;<a href=3D"mailto:dgde=
gra@tycho.nsa.gov" target=3D"_blank">dgdegra@tycho.nsa.gov</a>&gt;<br>
wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 11/05/2014 05:00 AM, Ian Campbell wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
CCing Daniel.<br>
<br>
On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
I am wondering if this is known issue that when I set locality!=3D0 to<br>
vtpmmgr it does not start. It is a bit strange that every call to<br>
tpm_tis_status returns 255 and device-id is also FFFF:<br>
1.2 TPM (device-id=3D0xFFFF vendor-id =3D FFFF rev-id =3D FF).<br>
TPM interface capabilities (0xffffffff):<br>
<br>
I am configuring vtpmmgr using:<br>
<br>
kernel=3D&quot;/usr/local/lib/xen/<u></u>boot/vtpmmgr-stubdom.gz&quot;<br>
memory=3D8<br>
disk=3D[&quot;file:/var/vtpmmgr-<u></u>stubdom.img,hda,w&quot;]<br>
name=3D&quot;vtpmmgr&quot;<br>
iomem=3D[&quot;fed40,5&quot;]<br>
extra=3D&quot;tpmlocality=3D2&quot;<br>
<br>
<br>
I also tried using :<br>
iomem=3D[&quot;fed40,1&quot;]<br>
extra=3D&quot;tpmlocality=3D0&quot;//works well<br>
<br>
or<br>
iomem=3D[&quot;fed42,1&quot;]<br>
extra=3D&quot;tpmlocality=3D2&quot;<br>
It seems that everything that is not mapped at fed40-fed41 is<br>
FFFFFFFF.<br>
<br>
I have an Atmel TPM chipset.<br>
<br>
Could it be a chipset problem to not handle well different localities?<br>
<br>
When I use locality=3D0, the device driver info is correct and<br>
everything works fine:<br>
1.2 TPM (device-id=3D0x3204 vendor-id =3D 1114 rev-id =3D 40)<br>
TPM interface capabilities (0xfd)<br>
<br>
</blockquote>
<br>
</blockquote>
This may be an issue with locality 2 being unavailable unless a DRTM<br>
launch (tboot) is performed.=C2=A0 Returning all-ones is the normal respons=
e<br>
of the x86 chipset when unmapped MMIO regions are accessed; disabled<br>
localities of the TPM may act like this.<br>
<br>
Does your system support the DRTM launch?=C2=A0 If so, can you test it to s=
ee<br>
if this is the issue?<br>
<br>
In this case, to better support people who want to use the vTPM Manager<br>
without a DRTM launch, the features of the vTPM Manager that use the TPM<br=
>
1.2 PCRs may need to be disabled or implemented in an alternate manner<br>
such as embedding the data in the quote instead of in PCRs.=C2=A0 The curre=
nt<br>
design was created with the assumption that systems using it would be<br>
performing a DRTM launch in order to fully secure the boot process.<br>
<br>
=C2=A0 In linux kernel this information is obtained using locality 0 and<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
after that other commands execute using specified locality.<br>
<a href=3D"https://git.kernel.org/cgit/linux/kernel/git/stable/linux-" targ=
et=3D"_blank">https://git.kernel.org/cgit/<u></u>linux/kernel/git/stable/li=
nux-</a><br>
stable.git/tree/drivers/char/<u></u>tpm/tpm_tis.c#n558<br>
<br>
</blockquote>
<br>
</blockquote>
Have you tested that other localities work for your TPM under Linux?<br>
</blockquote>
<br>
<br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
<br>
Emil<br>
<br>
<br>
</blockquote></blockquote>
--<br>
Daniel De Graaf<br>
National Security Agency<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
-- <br>
Daniel De Graaf<br>
National Security Agency<br>
</div></div></blockquote></div><br></div>

--e89a8f839d7d50094a0507d25deb--


--===============7179403939769863870==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7179403939769863870==--


From xen-devel-bounces@lists.xen.org Fri Nov 14 14:25:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHoG-00023Q-Rl; Fri, 14 Nov 2014 14:25:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpHoF-00023L-C2
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:25:11 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	56/D5-02696-6C016645; Fri, 14 Nov 2014 14:25:10 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415975107!12613401!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13781 invoked from network); 14 Nov 2014 14:25:09 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 14:25:09 -0000
Received: from mail-qg0-f45.google.com ([209.85.192.45]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYQw1cv37Siy6KKg0io8kBeDZPdkn4R@postini.com;
	Fri, 14 Nov 2014 06:25:09 PST
Received: by mail-qg0-f45.google.com with SMTP id z107so12102019qgd.18
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 06:25:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=9OUj3QUo/no/WAJgmcCjtlaAGbVKcCHPwT30350pSO0=;
	b=a77acVAApx14Fi8V8aKfAgA3GN2jABz5Vgv1KuVpdhuCqHG39R0P7LZzilEM2Ovg1B
	mDm+As5IDtDg5Nm+Tt9ec7xvOZykycPMkI+KSgroIne45IcsHDeU44QCUUf1PbUgW6wM
	8bPzY+dXPPII8dumdgNRKOufjMW0OVKBdTgro=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=9OUj3QUo/no/WAJgmcCjtlaAGbVKcCHPwT30350pSO0=;
	b=FSm0vuPEcgNwt03dUYOLRLeE1udiw20gesgRwLjRvJ/AQ+rS3P93BWrFflkn4vDs87
	OKE9JgH/ck6WbMxMAw8OEIeijuEAOmTSuBUnEsVj4AJQEUoC1ClxJ5sW4vz1gtT8pIwG
	lelXIBKi/di7WifcTGhRqRgEaC/fHOEe5mZE3oOSAJ8ryhVjn0JU+xC7vAcdvK2Td2u6
	Za7yxNmFAGQ4tUtTbu6w7vZMvUMdwH8axyQDO3DsmdoMJyPTjD4/2Qwun4sx3ImM/bH4
	OU3gJvXQd2xmrhSW6fkMF4DuraalZdr+RjqPEtD68nwgJVLH3gXfDH6BxgrpeUHIAEXv
	HEhg==
X-Gm-Message-State: ALoCoQk9dCcP9VVY+gMjDH4v9zvxIz/zEWnbX5YNzGt75IgKpo3wtaFNgsH8Jc5/Ah1tqpEfSKZRKNmx6jWusAzk+4c12hXWL9QZQ+bx8+yZiytSmRMUqlbI1XsadY/Tg/KuZAqKr9xGyNqpGroQiezlInnBk814qA==
X-Received: by 10.229.236.197 with SMTP id kl5mr11676498qcb.31.1415975107135; 
	Fri, 14 Nov 2014 06:25:07 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.229.236.197 with SMTP id kl5mr11676485qcb.31.1415975107035; 
	Fri, 14 Nov 2014 06:25:07 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 06:25:06 -0800 (PST)
Date: Fri, 14 Nov 2014 16:25:06 +0200
Message-ID: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Julien Grall <julien.grall@linaro.org>
Subject: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I observe system freeze on latest xen/master branch.

My setup is:

- Jacinto 6 evm board (OMAP5)
- Latest Xen 4.5.0-rc2 as hypervisor
- Linux 3.8 as dom0, running on 2 vcpus
- Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
- XSM feature is disabled
- gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
compiler

Freeze occurs in random moment of time during creation of domU domain.
Even Xen console may be not available after freeze.
Can someone suggest - what it can be? Maybe some weak places in new
code? Maybe new gic, which was reworked a lot or something else?

Thank you in advance for any suggestions.

Regards

-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:25:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHoG-00023Q-Rl; Fri, 14 Nov 2014 14:25:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpHoF-00023L-C2
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:25:11 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	56/D5-02696-6C016645; Fri, 14 Nov 2014 14:25:10 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415975107!12613401!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13781 invoked from network); 14 Nov 2014 14:25:09 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 14:25:09 -0000
Received: from mail-qg0-f45.google.com ([209.85.192.45]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYQw1cv37Siy6KKg0io8kBeDZPdkn4R@postini.com;
	Fri, 14 Nov 2014 06:25:09 PST
Received: by mail-qg0-f45.google.com with SMTP id z107so12102019qgd.18
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 06:25:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=9OUj3QUo/no/WAJgmcCjtlaAGbVKcCHPwT30350pSO0=;
	b=a77acVAApx14Fi8V8aKfAgA3GN2jABz5Vgv1KuVpdhuCqHG39R0P7LZzilEM2Ovg1B
	mDm+As5IDtDg5Nm+Tt9ec7xvOZykycPMkI+KSgroIne45IcsHDeU44QCUUf1PbUgW6wM
	8bPzY+dXPPII8dumdgNRKOufjMW0OVKBdTgro=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=9OUj3QUo/no/WAJgmcCjtlaAGbVKcCHPwT30350pSO0=;
	b=FSm0vuPEcgNwt03dUYOLRLeE1udiw20gesgRwLjRvJ/AQ+rS3P93BWrFflkn4vDs87
	OKE9JgH/ck6WbMxMAw8OEIeijuEAOmTSuBUnEsVj4AJQEUoC1ClxJ5sW4vz1gtT8pIwG
	lelXIBKi/di7WifcTGhRqRgEaC/fHOEe5mZE3oOSAJ8ryhVjn0JU+xC7vAcdvK2Td2u6
	Za7yxNmFAGQ4tUtTbu6w7vZMvUMdwH8axyQDO3DsmdoMJyPTjD4/2Qwun4sx3ImM/bH4
	OU3gJvXQd2xmrhSW6fkMF4DuraalZdr+RjqPEtD68nwgJVLH3gXfDH6BxgrpeUHIAEXv
	HEhg==
X-Gm-Message-State: ALoCoQk9dCcP9VVY+gMjDH4v9zvxIz/zEWnbX5YNzGt75IgKpo3wtaFNgsH8Jc5/Ah1tqpEfSKZRKNmx6jWusAzk+4c12hXWL9QZQ+bx8+yZiytSmRMUqlbI1XsadY/Tg/KuZAqKr9xGyNqpGroQiezlInnBk814qA==
X-Received: by 10.229.236.197 with SMTP id kl5mr11676498qcb.31.1415975107135; 
	Fri, 14 Nov 2014 06:25:07 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.229.236.197 with SMTP id kl5mr11676485qcb.31.1415975107035; 
	Fri, 14 Nov 2014 06:25:07 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 06:25:06 -0800 (PST)
Date: Fri, 14 Nov 2014 16:25:06 +0200
Message-ID: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Julien Grall <julien.grall@linaro.org>
Subject: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I observe system freeze on latest xen/master branch.

My setup is:

- Jacinto 6 evm board (OMAP5)
- Latest Xen 4.5.0-rc2 as hypervisor
- Linux 3.8 as dom0, running on 2 vcpus
- Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
- XSM feature is disabled
- gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
compiler

Freeze occurs in random moment of time during creation of domU domain.
Even Xen console may be not available after freeze.
Can someone suggest - what it can be? Maybe some weak places in new
code? Maybe new gic, which was reworked a lot or something else?

Thank you in advance for any suggestions.

Regards

-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:34:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:34:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHwv-0002U0-Tp; Fri, 14 Nov 2014 14:34:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpHwv-0002Tv-1u
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 14:34:09 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	86/03-22819-0E216645; Fri, 14 Nov 2014 14:34:08 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415975647!3854778!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22612 invoked from network); 14 Nov 2014 14:34:08 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 14:34:08 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52713 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpHvn-0004mx-UK; Fri, 14 Nov 2014 15:32:59 +0100
Date: Fri, 14 Nov 2014 15:34:04 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <688701120.20141114153404@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <546618620200007800047AD1@mail.emea.novell.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 2:57:38 PM, you wrote:

>>>> On 14.11.14 at 14:11, <linux@eikelenboom.it> wrote:
>> (XEN) [2014-11-14 13:00:06.810] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> (XEN) [2014-11-14 13:00:06.810] CPU:    3
>> (XEN) [2014-11-14 13:00:06.810] RIP:    e008:[<ffff82d080148f14>] dpci_softirq+0x9c/0x231
>> (XEN) [2014-11-14 13:00:06.810] RFLAGS: 0000000000010283   CONTEXT: hypervisor
>> (XEN) [2014-11-14 13:00:06.811] rax: 0000000000100100   rbx: ffff830515c86d90  rcx: 0000000000000001

> This and ...

>> (XEN) [2014-11-14 13:00:06.811] Pagetable walk from 0000000000100108:
>> (XEN) [2014-11-14 13:00:06.811]  L4[0x000] = 000000055d09a063 ffffffffffffffff
>> (XEN) [2014-11-14 13:00:06.811]  L3[0x000] = 000000055d099063 ffffffffffffffff
>> (XEN) [2014-11-14 13:00:06.811]  L2[0x000] = 000000055d098063 ffffffffffffffff 

> ... this suggest it hit a poisoned list entry, due to

> #define LIST_POISON1  ((void *) 0x00100100)

> But without you helping out with associating the crash location with
> a source line (or allowing us to do so by making xen-syms available
> somewhere) this is going to remain guesswork.

> Jan

Hi Jan,

# addr2line -e ./xen-syms ffff82d080148f14
/usr/src/new/xen-unstable/xen/include/xen/list.h:175

Which turns out to be this assert:
/**
 * list_del - deletes entry from list.
 * @entry: the element to delete from the list.
 * Note: list_empty on entry does not return true after this, the entry is
 * in an undefined state.
 */
static inline void list_del(struct list_head *entry)
{
    ASSERT(entry->next->prev == entry);



The other lines from the stacktrace point to:
# addr2line -e ./xen-syms ffff82d08012bd91
/usr/src/new/xen-unstable/xen/common/softirq.c:52

# addr2line -e ./xen-syms ffff82d08012bde9
/usr/src/new/xen-unstable/xen/common/softirq.c:66

# addr2line -e ./xen-syms ffff82d0801623d5
/usr/src/new/xen-unstable/xen/arch/x86/domain.c:119

# addr2line -e ./xen-syms ffff82d08012bd91
/usr/src/new/xen-unstable/xen/common/softirq.c:52


--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:34:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:34:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHwv-0002U0-Tp; Fri, 14 Nov 2014 14:34:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpHwv-0002Tv-1u
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 14:34:09 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	86/03-22819-0E216645; Fri, 14 Nov 2014 14:34:08 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-206.messagelabs.com!1415975647!3854778!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22612 invoked from network); 14 Nov 2014 14:34:08 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 14:34:08 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52713 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpHvn-0004mx-UK; Fri, 14 Nov 2014 15:32:59 +0100
Date: Fri, 14 Nov 2014 15:34:04 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <688701120.20141114153404@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <546618620200007800047AD1@mail.emea.novell.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 2:57:38 PM, you wrote:

>>>> On 14.11.14 at 14:11, <linux@eikelenboom.it> wrote:
>> (XEN) [2014-11-14 13:00:06.810] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> (XEN) [2014-11-14 13:00:06.810] CPU:    3
>> (XEN) [2014-11-14 13:00:06.810] RIP:    e008:[<ffff82d080148f14>] dpci_softirq+0x9c/0x231
>> (XEN) [2014-11-14 13:00:06.810] RFLAGS: 0000000000010283   CONTEXT: hypervisor
>> (XEN) [2014-11-14 13:00:06.811] rax: 0000000000100100   rbx: ffff830515c86d90  rcx: 0000000000000001

> This and ...

>> (XEN) [2014-11-14 13:00:06.811] Pagetable walk from 0000000000100108:
>> (XEN) [2014-11-14 13:00:06.811]  L4[0x000] = 000000055d09a063 ffffffffffffffff
>> (XEN) [2014-11-14 13:00:06.811]  L3[0x000] = 000000055d099063 ffffffffffffffff
>> (XEN) [2014-11-14 13:00:06.811]  L2[0x000] = 000000055d098063 ffffffffffffffff 

> ... this suggest it hit a poisoned list entry, due to

> #define LIST_POISON1  ((void *) 0x00100100)

> But without you helping out with associating the crash location with
> a source line (or allowing us to do so by making xen-syms available
> somewhere) this is going to remain guesswork.

> Jan

Hi Jan,

# addr2line -e ./xen-syms ffff82d080148f14
/usr/src/new/xen-unstable/xen/include/xen/list.h:175

Which turns out to be this assert:
/**
 * list_del - deletes entry from list.
 * @entry: the element to delete from the list.
 * Note: list_empty on entry does not return true after this, the entry is
 * in an undefined state.
 */
static inline void list_del(struct list_head *entry)
{
    ASSERT(entry->next->prev == entry);



The other lines from the stacktrace point to:
# addr2line -e ./xen-syms ffff82d08012bd91
/usr/src/new/xen-unstable/xen/common/softirq.c:52

# addr2line -e ./xen-syms ffff82d08012bde9
/usr/src/new/xen-unstable/xen/common/softirq.c:66

# addr2line -e ./xen-syms ffff82d0801623d5
/usr/src/new/xen-unstable/xen/arch/x86/domain.c:119

# addr2line -e ./xen-syms ffff82d08012bd91
/usr/src/new/xen-unstable/xen/common/softirq.c:52


--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:36:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:36:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHz2-0002ao-Gk; Fri, 14 Nov 2014 14:36:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpHz0-0002aj-SC
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:36:18 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	EA/B1-02957-26316645; Fri, 14 Nov 2014 14:36:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415975775!12617011!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17439 invoked from network); 14 Nov 2014 14:36:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:36:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191396885"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 09:36:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpHyt-0001Op-CC;
	Fri, 14 Nov 2014 14:36:11 +0000
Date: Fri, 14 Nov 2014 14:35:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> Hi,
> 
> I observe system freeze on latest xen/master branch.
> 
> My setup is:
> 
> - Jacinto 6 evm board (OMAP5)
> - Latest Xen 4.5.0-rc2 as hypervisor
> - Linux 3.8 as dom0, running on 2 vcpus
> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
> - XSM feature is disabled
> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
> compiler
> 
> Freeze occurs in random moment of time during creation of domU domain.
> Even Xen console may be not available after freeze.
> Can someone suggest - what it can be? Maybe some weak places in new
> code? Maybe new gic, which was reworked a lot or something else?
> 
> Thank you in advance for any suggestions.

Is this really 3.8 or 3.18? 3.8 is pretty old and doesn't have any of
the fixes to be able to safely do dma involving guest pages to
non-coherent devices. Where are you storing the guest disk images?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:36:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:36:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpHz2-0002ao-Gk; Fri, 14 Nov 2014 14:36:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpHz0-0002aj-SC
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:36:18 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	EA/B1-02957-26316645; Fri, 14 Nov 2014 14:36:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415975775!12617011!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17439 invoked from network); 14 Nov 2014 14:36:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:36:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191396885"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 09:36:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpHyt-0001Op-CC;
	Fri, 14 Nov 2014 14:36:11 +0000
Date: Fri, 14 Nov 2014 14:35:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> Hi,
> 
> I observe system freeze on latest xen/master branch.
> 
> My setup is:
> 
> - Jacinto 6 evm board (OMAP5)
> - Latest Xen 4.5.0-rc2 as hypervisor
> - Linux 3.8 as dom0, running on 2 vcpus
> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
> - XSM feature is disabled
> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
> compiler
> 
> Freeze occurs in random moment of time during creation of domU domain.
> Even Xen console may be not available after freeze.
> Can someone suggest - what it can be? Maybe some weak places in new
> code? Maybe new gic, which was reworked a lot or something else?
> 
> Thank you in advance for any suggestions.

Is this really 3.8 or 3.18? 3.8 is pretty old and doesn't have any of
the fixes to be able to safely do dma involving guest pages to
non-coherent devices. Where are you storing the guest disk images?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:42:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:42:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpI4j-0002nN-Ea; Fri, 14 Nov 2014 14:42:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpI4h-0002nI-Jk
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:42:11 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	9C/E5-26858-2C416645; Fri, 14 Nov 2014 14:42:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415976125!9013628!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10541 invoked from network); 14 Nov 2014 14:42:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:42:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192864816"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 09:41:40 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpI4C-0001V2-68;
	Fri, 14 Nov 2014 14:41:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpI4B-0001YF-Eo;
	Fri, 14 Nov 2014 14:41:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.5282.659930.728522@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 14:41:38 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("[PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> When a device is hot-unplugged libxl sends QEMU a "device-del" message
> (via QMP). This call returns after QEMU has initiated device removal by
> sending an interrupt to the guest. At some point later QEMU is expected
> to clean up after the device (such as unbind/unmap MSIs), which will
> occur when the guest signals that the device has been ejected.

I haven't repro'd this bug, but after looking at your patch, and
staring at the code, I think you may have misdiagnosed the problem.

I found this:

    if (type == LIBXL_DOMAIN_TYPE_HVM) {
       [stuff]
    } else if (type != LIBXL_DOMAIN_TYPE_PV)
        abort();
    {

This is, of course, very bizarre.  For a moment I put it down to
coding style, but the subsequent block is the PV pci unplug path.  It
would appear therefore that HVM PCI unplug executes first the HVM
code, and then immediately afterwards the PV code.

This strangeness was introduced in abfb006f
 "tools/libxl: explicitly grant access to needed I/O-memory ranges"
which seems to contain an entirely wrong hunk.

Can you try the patch below and see if it helps your problem ?

AFAICT your other patch probably isn't needed in the light of all
this.  If it is, then I have misunderstood (and perhaps the commit
message could be more explicit about the bug that this is allegedly
fixing - calling a patch `Simplify ....' makes it sound like the kind
of cleanup we don't want to take during the freeze).

Thanks
Ian.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 9f40100..bec25a9 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1255,9 +1255,9 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
             rc = ERROR_FAIL;
             goto out_fail;
         }
-    } else if (type != LIBXL_DOMAIN_TYPE_PV)
-        abort();
-    {
+    } else {
+        assert(type == LIBXL_DOMAIN_TYPE_PV);
+
         char *sysfs_path = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/resource", pcidev->domain,
                                          pcidev->bus, pcidev->dev, pcidev->func);
         FILE *f = fopen(sysfs_path, "r");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:42:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:42:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpI4j-0002nN-Ea; Fri, 14 Nov 2014 14:42:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpI4h-0002nI-Jk
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:42:11 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	9C/E5-26858-2C416645; Fri, 14 Nov 2014 14:42:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415976125!9013628!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10541 invoked from network); 14 Nov 2014 14:42:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:42:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192864816"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 09:41:40 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpI4C-0001V2-68;
	Fri, 14 Nov 2014 14:41:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpI4B-0001YF-Eo;
	Fri, 14 Nov 2014 14:41:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.5282.659930.728522@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 14:41:38 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("[PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> When a device is hot-unplugged libxl sends QEMU a "device-del" message
> (via QMP). This call returns after QEMU has initiated device removal by
> sending an interrupt to the guest. At some point later QEMU is expected
> to clean up after the device (such as unbind/unmap MSIs), which will
> occur when the guest signals that the device has been ejected.

I haven't repro'd this bug, but after looking at your patch, and
staring at the code, I think you may have misdiagnosed the problem.

I found this:

    if (type == LIBXL_DOMAIN_TYPE_HVM) {
       [stuff]
    } else if (type != LIBXL_DOMAIN_TYPE_PV)
        abort();
    {

This is, of course, very bizarre.  For a moment I put it down to
coding style, but the subsequent block is the PV pci unplug path.  It
would appear therefore that HVM PCI unplug executes first the HVM
code, and then immediately afterwards the PV code.

This strangeness was introduced in abfb006f
 "tools/libxl: explicitly grant access to needed I/O-memory ranges"
which seems to contain an entirely wrong hunk.

Can you try the patch below and see if it helps your problem ?

AFAICT your other patch probably isn't needed in the light of all
this.  If it is, then I have misunderstood (and perhaps the commit
message could be more explicit about the bug that this is allegedly
fixing - calling a patch `Simplify ....' makes it sound like the kind
of cleanup we don't want to take during the freeze).

Thanks
Ian.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 9f40100..bec25a9 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1255,9 +1255,9 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
             rc = ERROR_FAIL;
             goto out_fail;
         }
-    } else if (type != LIBXL_DOMAIN_TYPE_PV)
-        abort();
-    {
+    } else {
+        assert(type == LIBXL_DOMAIN_TYPE_PV);
+
         char *sysfs_path = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/resource", pcidev->domain,
                                          pcidev->bus, pcidev->dev, pcidev->func);
         FILE *f = fopen(sysfs_path, "r");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:43:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14: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.xen.org>)
	id 1XpI6F-0002sE-Te; Fri, 14 Nov 2014 14:43:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpI6E-0002s6-Q3
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:43:46 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	15/8C-02559-12516645; Fri, 14 Nov 2014 14:43:45 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415976223!12640727!1
X-Originating-IP: [64.18.0.251]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28410 invoked from network); 14 Nov 2014 14:43:45 -0000
Received: from exprod5og126.obsmtp.com (HELO exprod5og126.obsmtp.com)
	(64.18.0.251)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 14:43:45 -0000
Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by
	exprod5ob126.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYVH/RUbtc37o5mvCPXd0h2xscXptgs@postini.com;
	Fri, 14 Nov 2014 06:43:44 PST
Received: by mail-qa0-f45.google.com with SMTP id dc16so11715937qab.18
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 06:43:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Esbrpm5q1y/AVuepPkWb7t7XVW0iUj5vwAzTijlxHjU=;
	b=PIkMruQJ3PCZgU/+kW30KdSmxzy9VKMdzMMFyBCNemlrnhUDiBmBrVThLhHiMhRhG8
	AmFQ3EdnO96nhcw53lLv9OCCR8HTpY0Wn2cEGSz9zKwgCcZsj6FdHOAf7wLQPFTwVeDz
	Yq6GKDaKMuFsP4JXksk7Q08D8jY+pszgJoeNM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Esbrpm5q1y/AVuepPkWb7t7XVW0iUj5vwAzTijlxHjU=;
	b=dNvtsjFHhzx08sFQWyr2y+Aotd4b3VpkT/rgmt165jClaROmJhQ9M/wW8vIS+Ynzma
	h1j8nUWJJS9IHCvRFU0Ypz72n4LbJq5d2zojH/ccN2u5T+xFe/hZwxbprB9FXholXEjS
	mdniYHCA5W4pDbt1/KVD3E93vo7RYrERvX24Af+g7uosc3ga4oAKOWnOazX7uv4uuuP4
	bve4qFAgY7afMHGHaSPuOdyuBe7PNaRSgna91Z03eFUuRm0cablTWNxVgXN+x1bjxqaO
	kWFXLvmHOZSII7BANO39sOCjrPb7IURVYTon1OWZUQ7SDvvRZWU/jBesmRkXgWweiYmP
	u2rQ==
X-Gm-Message-State: ALoCoQltsc3M5xgQiBUeTw7SITs+DjVfa3cIGq9ZFS1harOLb23Pk98XSxmCKRL/6YQRiv1Q07bpN11dVs1/IvLnqi3Rj06sXx8KR1opeRlPu0NyEI74Fsf6xqFq1ylQVxlobn9DZ9bessEEgcPiBwqsXAtO072vkw==
X-Received: by 10.140.85.83 with SMTP id m77mr11502686qgd.93.1415976222545;
	Fri, 14 Nov 2014 06:43:42 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.85.83 with SMTP id m77mr11502673qgd.93.1415976222445;
	Fri, 14 Nov 2014 06:43:42 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 06:43:42 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
Date: Fri, 14 Nov 2014 16:43:42 +0200
Message-ID: <CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi,
>>
>> I observe system freeze on latest xen/master branch.
>>
>> My setup is:
>>
>> - Jacinto 6 evm board (OMAP5)
>> - Latest Xen 4.5.0-rc2 as hypervisor
>> - Linux 3.8 as dom0, running on 2 vcpus
>> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
>> - XSM feature is disabled
>> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
>> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
>> compiler
>>
>> Freeze occurs in random moment of time during creation of domU domain.
>> Even Xen console may be not available after freeze.
>> Can someone suggest - what it can be? Maybe some weak places in new
>> code? Maybe new gic, which was reworked a lot or something else?
>>
>> Thank you in advance for any suggestions.
>
> Is this really 3.8 or 3.18?

We have 3.8 in both dom0 and domU

> 3.8 is pretty old and doesn't have any of
> the fixes to be able to safely do dma involving guest pages to
> non-coherent devices.

This is a good point. Now we are migrating to 3.12 kernel in dom0. But
Android will remain on 3.8. Will it help ?
Maybe you can point me to any tree with proper DMA fixes? Note: if you
are talking about SWIOTLB - we have your latest one, retrieved from
git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
branch:swiotlb-xen-9.1

> Where are you storing the guest disk images?

SATA drive, dedicated to dom0, its controller has its own DMA

Regards,
Andri



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:43:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14: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.xen.org>)
	id 1XpI6F-0002sE-Te; Fri, 14 Nov 2014 14:43:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpI6E-0002s6-Q3
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:43:46 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	15/8C-02559-12516645; Fri, 14 Nov 2014 14:43:45 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1415976223!12640727!1
X-Originating-IP: [64.18.0.251]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28410 invoked from network); 14 Nov 2014 14:43:45 -0000
Received: from exprod5og126.obsmtp.com (HELO exprod5og126.obsmtp.com)
	(64.18.0.251)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 14:43:45 -0000
Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by
	exprod5ob126.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYVH/RUbtc37o5mvCPXd0h2xscXptgs@postini.com;
	Fri, 14 Nov 2014 06:43:44 PST
Received: by mail-qa0-f45.google.com with SMTP id dc16so11715937qab.18
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 06:43:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Esbrpm5q1y/AVuepPkWb7t7XVW0iUj5vwAzTijlxHjU=;
	b=PIkMruQJ3PCZgU/+kW30KdSmxzy9VKMdzMMFyBCNemlrnhUDiBmBrVThLhHiMhRhG8
	AmFQ3EdnO96nhcw53lLv9OCCR8HTpY0Wn2cEGSz9zKwgCcZsj6FdHOAf7wLQPFTwVeDz
	Yq6GKDaKMuFsP4JXksk7Q08D8jY+pszgJoeNM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Esbrpm5q1y/AVuepPkWb7t7XVW0iUj5vwAzTijlxHjU=;
	b=dNvtsjFHhzx08sFQWyr2y+Aotd4b3VpkT/rgmt165jClaROmJhQ9M/wW8vIS+Ynzma
	h1j8nUWJJS9IHCvRFU0Ypz72n4LbJq5d2zojH/ccN2u5T+xFe/hZwxbprB9FXholXEjS
	mdniYHCA5W4pDbt1/KVD3E93vo7RYrERvX24Af+g7uosc3ga4oAKOWnOazX7uv4uuuP4
	bve4qFAgY7afMHGHaSPuOdyuBe7PNaRSgna91Z03eFUuRm0cablTWNxVgXN+x1bjxqaO
	kWFXLvmHOZSII7BANO39sOCjrPb7IURVYTon1OWZUQ7SDvvRZWU/jBesmRkXgWweiYmP
	u2rQ==
X-Gm-Message-State: ALoCoQltsc3M5xgQiBUeTw7SITs+DjVfa3cIGq9ZFS1harOLb23Pk98XSxmCKRL/6YQRiv1Q07bpN11dVs1/IvLnqi3Rj06sXx8KR1opeRlPu0NyEI74Fsf6xqFq1ylQVxlobn9DZ9bessEEgcPiBwqsXAtO072vkw==
X-Received: by 10.140.85.83 with SMTP id m77mr11502686qgd.93.1415976222545;
	Fri, 14 Nov 2014 06:43:42 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.85.83 with SMTP id m77mr11502673qgd.93.1415976222445;
	Fri, 14 Nov 2014 06:43:42 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 06:43:42 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
Date: Fri, 14 Nov 2014 16:43:42 +0200
Message-ID: <CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi,
>>
>> I observe system freeze on latest xen/master branch.
>>
>> My setup is:
>>
>> - Jacinto 6 evm board (OMAP5)
>> - Latest Xen 4.5.0-rc2 as hypervisor
>> - Linux 3.8 as dom0, running on 2 vcpus
>> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
>> - XSM feature is disabled
>> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
>> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
>> compiler
>>
>> Freeze occurs in random moment of time during creation of domU domain.
>> Even Xen console may be not available after freeze.
>> Can someone suggest - what it can be? Maybe some weak places in new
>> code? Maybe new gic, which was reworked a lot or something else?
>>
>> Thank you in advance for any suggestions.
>
> Is this really 3.8 or 3.18?

We have 3.8 in both dom0 and domU

> 3.8 is pretty old and doesn't have any of
> the fixes to be able to safely do dma involving guest pages to
> non-coherent devices.

This is a good point. Now we are migrating to 3.12 kernel in dom0. But
Android will remain on 3.8. Will it help ?
Maybe you can point me to any tree with proper DMA fixes? Note: if you
are talking about SWIOTLB - we have your latest one, retrieved from
git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
branch:swiotlb-xen-9.1

> Where are you storing the guest disk images?

SATA drive, dedicated to dom0, its controller has its own DMA

Regards,
Andri



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:53:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:53:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIFA-0003WN-9E; Fri, 14 Nov 2014 14:53: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 1XpIF8-0003Vi-Au
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 14:52:58 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	B7/4E-02712-94716645; Fri, 14 Nov 2014 14:52:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415976777!12593022!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14971 invoked from network); 14 Nov 2014 14:52:57 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 14:52:57 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 14:52:56 +0000
Message-Id: <546625590200007800047B7E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 14:52:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] x86: (allow to) override LIST_POISON*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Having these point into space not controlled by the hypervisor provides
an unnecessary attack surface. Allow architectures to override them and
utilize that override to make them non-canonical addresses (thus
causing #GP rather than #PF when dereferenced).

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
The security aspect of this makes Andrew and me think this should be
considered for 4.5 despite it not fixing an actual bug.

--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -106,6 +106,10 @@
 /* Return value for zero-size _xmalloc(), distinguished from NULL. */
 #define ZERO_BLOCK_PTR ((void *)0xBAD0BAD0BAD0BAD0UL)
 
+/* Override include/xen/list.h to make these non-canonical addresses. */
+#define LIST_POISON1  ((void *)0x0100100100100100UL)
+#define LIST_POISON2  ((void *)0x0200200200200200UL)
+
 #ifndef __ASSEMBLY__
 extern unsigned long trampoline_phys;
 #define bootsym_phys(sym)                                 \
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -10,12 +10,15 @@
 #include <xen/lib.h>
 #include <asm/system.h>
 
-/* These are non-NULL pointers that will result in page faults
- * under normal circumstances, used to verify that nobody uses
- * non-initialized list entries.
+/*
+ * These are non-NULL pointers that will result in faults under normal
+ * circumstances, used to verify that nobody uses non-initialized list
+ * entries. Architectures can override these.
  */
+#ifndef LIST_POISON1
 #define LIST_POISON1  ((void *) 0x00100100)
 #define LIST_POISON2  ((void *) 0x00200200)
+#endif
 
 /*
  * Simple doubly linked list implementation.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:53:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:53:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIFA-0003WN-9E; Fri, 14 Nov 2014 14:53: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 1XpIF8-0003Vi-Au
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 14:52:58 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	B7/4E-02712-94716645; Fri, 14 Nov 2014 14:52:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415976777!12593022!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14971 invoked from network); 14 Nov 2014 14:52:57 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 14:52:57 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 14:52:56 +0000
Message-Id: <546625590200007800047B7E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 14:52:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] x86: (allow to) override LIST_POISON*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Having these point into space not controlled by the hypervisor provides
an unnecessary attack surface. Allow architectures to override them and
utilize that override to make them non-canonical addresses (thus
causing #GP rather than #PF when dereferenced).

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
The security aspect of this makes Andrew and me think this should be
considered for 4.5 despite it not fixing an actual bug.

--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -106,6 +106,10 @@
 /* Return value for zero-size _xmalloc(), distinguished from NULL. */
 #define ZERO_BLOCK_PTR ((void *)0xBAD0BAD0BAD0BAD0UL)
 
+/* Override include/xen/list.h to make these non-canonical addresses. */
+#define LIST_POISON1  ((void *)0x0100100100100100UL)
+#define LIST_POISON2  ((void *)0x0200200200200200UL)
+
 #ifndef __ASSEMBLY__
 extern unsigned long trampoline_phys;
 #define bootsym_phys(sym)                                 \
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -10,12 +10,15 @@
 #include <xen/lib.h>
 #include <asm/system.h>
 
-/* These are non-NULL pointers that will result in page faults
- * under normal circumstances, used to verify that nobody uses
- * non-initialized list entries.
+/*
+ * These are non-NULL pointers that will result in faults under normal
+ * circumstances, used to verify that nobody uses non-initialized list
+ * entries. Architectures can override these.
  */
+#ifndef LIST_POISON1
 #define LIST_POISON1  ((void *) 0x00100100)
 #define LIST_POISON2  ((void *) 0x00200200)
+#endif
 
 /*
  * Simple doubly linked list implementation.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:56:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIID-0003ga-Sd; Fri, 14 Nov 2014 14:56:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpIIC-0003gN-4h
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 14:56:08 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	BF/7F-14727-70816645; Fri, 14 Nov 2014 14:56:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415976963!8564970!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8151 invoked from network); 14 Nov 2014 14:56:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:56:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192869454"
Message-ID: <546617FF.40206@citrix.com>
Date: Fri, 14 Nov 2014 14:55:59 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <546625590200007800047B7E@mail.emea.novell.com>
In-Reply-To: <546625590200007800047B7E@mail.emea.novell.com>
X-DLP: MIA2
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86: (allow to) override LIST_POISON*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 14:52, Jan Beulich wrote:
> Having these point into space not controlled by the hypervisor provides
> an unnecessary attack surface. Allow architectures to override them and
> utilize that override to make them non-canonical addresses (thus
> causing #GP rather than #PF when dereferenced).
>
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
> The security aspect of this makes Andrew and me think this should be
> considered for 4.5 despite it not fixing an actual bug.
>
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -106,6 +106,10 @@
>  /* Return value for zero-size _xmalloc(), distinguished from NULL. */
>  #define ZERO_BLOCK_PTR ((void *)0xBAD0BAD0BAD0BAD0UL)
>  
> +/* Override include/xen/list.h to make these non-canonical addresses. */
> +#define LIST_POISON1  ((void *)0x0100100100100100UL)
> +#define LIST_POISON2  ((void *)0x0200200200200200UL)
> +
>  #ifndef __ASSEMBLY__
>  extern unsigned long trampoline_phys;
>  #define bootsym_phys(sym)                                 \
> --- a/xen/include/xen/list.h
> +++ b/xen/include/xen/list.h
> @@ -10,12 +10,15 @@
>  #include <xen/lib.h>
>  #include <asm/system.h>
>  
> -/* These are non-NULL pointers that will result in page faults
> - * under normal circumstances, used to verify that nobody uses
> - * non-initialized list entries.
> +/*
> + * These are non-NULL pointers that will result in faults under normal
> + * circumstances, used to verify that nobody uses non-initialized list
> + * entries. Architectures can override these.
>   */
> +#ifndef LIST_POISON1
>  #define LIST_POISON1  ((void *) 0x00100100)
>  #define LIST_POISON2  ((void *) 0x00200200)
> +#endif
>  
>  /*
>   * Simple doubly linked list implementation.
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:56:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIID-0003ga-Sd; Fri, 14 Nov 2014 14:56:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpIIC-0003gN-4h
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 14:56:08 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	BF/7F-14727-70816645; Fri, 14 Nov 2014 14:56:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415976963!8564970!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8151 invoked from network); 14 Nov 2014 14:56:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:56:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192869454"
Message-ID: <546617FF.40206@citrix.com>
Date: Fri, 14 Nov 2014 14:55:59 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <546625590200007800047B7E@mail.emea.novell.com>
In-Reply-To: <546625590200007800047B7E@mail.emea.novell.com>
X-DLP: MIA2
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86: (allow to) override LIST_POISON*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 14:52, Jan Beulich wrote:
> Having these point into space not controlled by the hypervisor provides
> an unnecessary attack surface. Allow architectures to override them and
> utilize that override to make them non-canonical addresses (thus
> causing #GP rather than #PF when dereferenced).
>
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
> The security aspect of this makes Andrew and me think this should be
> considered for 4.5 despite it not fixing an actual bug.
>
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -106,6 +106,10 @@
>  /* Return value for zero-size _xmalloc(), distinguished from NULL. */
>  #define ZERO_BLOCK_PTR ((void *)0xBAD0BAD0BAD0BAD0UL)
>  
> +/* Override include/xen/list.h to make these non-canonical addresses. */
> +#define LIST_POISON1  ((void *)0x0100100100100100UL)
> +#define LIST_POISON2  ((void *)0x0200200200200200UL)
> +
>  #ifndef __ASSEMBLY__
>  extern unsigned long trampoline_phys;
>  #define bootsym_phys(sym)                                 \
> --- a/xen/include/xen/list.h
> +++ b/xen/include/xen/list.h
> @@ -10,12 +10,15 @@
>  #include <xen/lib.h>
>  #include <asm/system.h>
>  
> -/* These are non-NULL pointers that will result in page faults
> - * under normal circumstances, used to verify that nobody uses
> - * non-initialized list entries.
> +/*
> + * These are non-NULL pointers that will result in faults under normal
> + * circumstances, used to verify that nobody uses non-initialized list
> + * entries. Architectures can override these.
>   */
> +#ifndef LIST_POISON1
>  #define LIST_POISON1  ((void *) 0x00100100)
>  #define LIST_POISON2  ((void *) 0x00200200)
> +#endif
>  
>  /*
>   * Simple doubly linked list implementation.
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:57:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14: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 1XpIJI-0003le-At; Fri, 14 Nov 2014 14:57:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpIJH-0003lX-F9
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:57:15 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	6F/B5-14214-A4816645; Fri, 14 Nov 2014 14:57:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415977032!8565231!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20298 invoked from network); 14 Nov 2014 14:57:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:57:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191404028"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 09:57:10 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpIJC-0001kn-3r;
	Fri, 14 Nov 2014 14:57:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpIJB-0001bd-13;
	Fri, 14 Nov 2014 14:57:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.6212.353346.560825@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 14:57:08 +0000
To: Wen Congyang <wency@cn.fujitsu.com>
In-Reply-To: <1412820314-323-3-git-send-email-wency@cn.fujitsu.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
	<1412820314-323-3-git-send-email-wency@cn.fujitsu.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch v2 2/3] correct xc_domain_save()'s 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

Wen Congyang writes ("[Patch v2 2/3] correct xc_domain_save()'s return value"):
> If suspend_and_state() fails, the errno may be 0. But we assume
> that the errno is not 0. So remove assert().

Thanks for spotting this.

I think this is going in the wrong direction.  Perhaps we could
instead do something like the patch below ?  Please let me know what
you think.

If you think this is a better idea, please submit it as a proper patch
with a proper commit message.

(Ideally we would fix the actual suspend hook in libxl, to always set
errno, but that's too invasive a set of changes to do now, I think.)

Thanks,
Ian.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 40bbac8..3ab9dd8 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -35,7 +35,9 @@
 /* callbacks provided by xc_domain_save */
 struct save_callbacks {
     /* Called after expiration of checkpoint interval,
-     * to suspend the guest.
+     * to suspend the guest.  Returns 1 for success, or 0 for failure.
+     * On failure it should ideally set errno.  (If it leaves errno
+     * as 0, EIO will be used instead.)
      */
     int (*suspend)(void* data);
 
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index 254fdb3..444aac6 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -361,9 +361,15 @@ static int suspend_and_state(int (*suspend)(void*), void* data,
                              xc_interface *xch, int io_fd, int dom,
                              xc_dominfo_t *info)
 {
+    errno = 0;
     if ( !(*suspend)(data) )
     {
-        ERROR("Suspend request failed");
+        if (!errno) {
+            errno = EIO;
+            ERROR("Suspend request failed (without errno, using EINVAL)");
+        } else {
+            ERROR("Suspend request failed");
+        }
         return -1;
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:57:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14: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 1XpIJI-0003le-At; Fri, 14 Nov 2014 14:57:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpIJH-0003lX-F9
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:57:15 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	6F/B5-14214-A4816645; Fri, 14 Nov 2014 14:57:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415977032!8565231!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20298 invoked from network); 14 Nov 2014 14:57:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:57:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191404028"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 09:57:10 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpIJC-0001kn-3r;
	Fri, 14 Nov 2014 14:57:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpIJB-0001bd-13;
	Fri, 14 Nov 2014 14:57:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.6212.353346.560825@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 14:57:08 +0000
To: Wen Congyang <wency@cn.fujitsu.com>
In-Reply-To: <1412820314-323-3-git-send-email-wency@cn.fujitsu.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
	<1412820314-323-3-git-send-email-wency@cn.fujitsu.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch v2 2/3] correct xc_domain_save()'s 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

Wen Congyang writes ("[Patch v2 2/3] correct xc_domain_save()'s return value"):
> If suspend_and_state() fails, the errno may be 0. But we assume
> that the errno is not 0. So remove assert().

Thanks for spotting this.

I think this is going in the wrong direction.  Perhaps we could
instead do something like the patch below ?  Please let me know what
you think.

If you think this is a better idea, please submit it as a proper patch
with a proper commit message.

(Ideally we would fix the actual suspend hook in libxl, to always set
errno, but that's too invasive a set of changes to do now, I think.)

Thanks,
Ian.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 40bbac8..3ab9dd8 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -35,7 +35,9 @@
 /* callbacks provided by xc_domain_save */
 struct save_callbacks {
     /* Called after expiration of checkpoint interval,
-     * to suspend the guest.
+     * to suspend the guest.  Returns 1 for success, or 0 for failure.
+     * On failure it should ideally set errno.  (If it leaves errno
+     * as 0, EIO will be used instead.)
      */
     int (*suspend)(void* data);
 
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index 254fdb3..444aac6 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -361,9 +361,15 @@ static int suspend_and_state(int (*suspend)(void*), void* data,
                              xc_interface *xch, int io_fd, int dom,
                              xc_dominfo_t *info)
 {
+    errno = 0;
     if ( !(*suspend)(data) )
     {
-        ERROR("Suspend request failed");
+        if (!errno) {
+            errno = EIO;
+            ERROR("Suspend request failed (without errno, using EINVAL)");
+        } else {
+            ERROR("Suspend request failed");
+        }
         return -1;
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:59:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14: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 1XpIL1-0003uU-RA; Fri, 14 Nov 2014 14:59:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpIL0-0003uI-Dl
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:59:02 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	A6/4D-28296-5B816645; Fri, 14 Nov 2014 14:59:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415977139!11331803!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31672 invoked from network); 14 Nov 2014 14:59:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:59:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191404458"
Message-ID: <1415977117.7113.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 14:58:37 +0000
In-Reply-To: <21606.6212.353346.560825@mariner.uk.xensource.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
	<1412820314-323-3-git-send-email-wency@cn.fujitsu.com>
	<21606.6212.353346.560825@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>, Wen Congyang <wency@cn.fujitsu.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Patch v2 2/3] correct xc_domain_save()'s return
	value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 14:57 +0000, Ian Jackson wrote:
> +            errno = EIO;
> +            ERROR("Suspend request failed (without errno, using EINVAL)");

You mean EIO in the error message, I think.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:59:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14: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 1XpIL1-0003uU-RA; Fri, 14 Nov 2014 14:59:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpIL0-0003uI-Dl
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 14:59:02 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	A6/4D-28296-5B816645; Fri, 14 Nov 2014 14:59:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1415977139!11331803!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31672 invoked from network); 14 Nov 2014 14:59:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:59:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191404458"
Message-ID: <1415977117.7113.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 14:58:37 +0000
In-Reply-To: <21606.6212.353346.560825@mariner.uk.xensource.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
	<1412820314-323-3-git-send-email-wency@cn.fujitsu.com>
	<21606.6212.353346.560825@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>, Wen Congyang <wency@cn.fujitsu.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Patch v2 2/3] correct xc_domain_save()'s return
	value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 14:57 +0000, Ian Jackson wrote:
> +            errno = EIO;
> +            ERROR("Suspend request failed (without errno, using EINVAL)");

You mean EIO in the error message, I think.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:59:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpILh-0003ys-8k; Fri, 14 Nov 2014 14:59:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpILf-0003ye-9R
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 14:59:43 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	92/B0-02576-ED816645; Fri, 14 Nov 2014 14:59:42 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415977180!7985650!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21690 invoked from network); 14 Nov 2014 14:59:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:59:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192870597"
Message-ID: <546618D9.5070200@citrix.com>
Date: Fri, 14 Nov 2014 14:59:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>,
	<xen-devel@lists.xensource.com>, <jbeulich@suse.com>,
	<konrad.wilk@oracle.com>, <david.vrabel@citrix.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>
	<5465FB34.9010606@suse.com> <54660A16.2090006@citrix.com>
	<54660E5C.8030107@suse.com>
In-Reply-To: <54660E5C.8030107@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 14:14, J=FCrgen Gro=DF wrote:
> On 11/14/2014 02:56 PM, Andrew Cooper wrote:
>> On 14/11/14 12:53, Juergen Gross wrote:
>>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>>> currently contains the mfn of the top level page frame of the 3 level
>>>>> p2m tree, which is used by the Xen tools during saving and restoring
>>>>> (and live migration) of pv domains and for crash dump analysis. With
>>>>> three levels of the p2m tree it is possible to support up to 512
>>>>> GB of
>>>>> RAM for a 64 bit pv domain.
>>>>>
>>>>> A 32 bit pv domain can support more, as each memory page can hold
>>>>> 1024
>>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>>
>>>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>>>> p2m list.
>>>>>
>>>>> This patch expands struct arch_shared_info with a new p2m list
>>>>> virtual
>>>>> address and the mfn of the page table root. The new information is
>>>>> indicated by the domain to be valid by storing ~0UL into
>>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of
>>>>> this
>>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>>
>>>> How do you envisage this being used?  Are you expecting the tools
>>>> to do
>>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>>
>>> Yes. Not very different compared to today's mapping via the 3 level
>>> p2m tree. Just another entry format, 4 instead of 3 levels and starting
>>> at an offset.
>>
>> Yes - David and I were discussing this over lunch, and it is not
>> actually very different.
>>
>> In reality, how likely is it that the pages backing this virtual linear
>> array change?
>
> Very unlikely, I think. But not impossible.
>
>> One issue currently is that, during the live part of migration, the
>> toolstack has no way of working out whether the structure of the p2m has
>> changed (intermediate leaves rearranged, or the length increasing).
>>
>> In the case that the VM does change the structure of the p2m under the
>> feet of the toolstack, migration will either blow up in a non-subtle way
>> with a p2m/m2p mismatch, or in a subtle way with the receiving side
>> copying the new p2m over the wrong part of the new domain.
>>
>> I am wondering whether, with this new p2m method, we can take sufficient
>> steps to be able to guarantee mishaps like this can't occur.
>
> This should be easy: I could add a counter in arch_shared_info which is
> incremented whenever a p2m mapping is being changed. The toolstack could
> compare the counter values before start and at end of migration and redo
> the migration (or fail) if they are different. In order to avoid races
> I would have to increment the counter before and after changing the
> mapping.
>

That is insufficient I believe.

Consider:

* Toolstack walks pagetables and maps the frames containing the linear p2m
* Live migration starts
* VM remaps a frame in the middle of the linear p2m
* Live migration continues, but the toolstack has a stale frame in the
middle of its view of the p2m.

As the p2m is almost never expected to change, I think it might be
better to have a flag the toolstack can set to say "The toolstack is
peeking at your p2m behind your back - you must not change its structure."

Having just thought this through, I think there is also a race condition
between a VM changing an entry in the p2m, and the toolstack doing
verifications of frames being sent.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 14:59:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 14:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpILh-0003ys-8k; Fri, 14 Nov 2014 14:59:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpILf-0003ye-9R
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 14:59:43 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	92/B0-02576-ED816645; Fri, 14 Nov 2014 14:59:42 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415977180!7985650!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21690 invoked from network); 14 Nov 2014 14:59:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 14:59:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192870597"
Message-ID: <546618D9.5070200@citrix.com>
Date: Fri, 14 Nov 2014 14:59:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>,
	<xen-devel@lists.xensource.com>, <jbeulich@suse.com>,
	<konrad.wilk@oracle.com>, <david.vrabel@citrix.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>
	<5465FB34.9010606@suse.com> <54660A16.2090006@citrix.com>
	<54660E5C.8030107@suse.com>
In-Reply-To: <54660E5C.8030107@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 14:14, J=FCrgen Gro=DF wrote:
> On 11/14/2014 02:56 PM, Andrew Cooper wrote:
>> On 14/11/14 12:53, Juergen Gross wrote:
>>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>>> currently contains the mfn of the top level page frame of the 3 level
>>>>> p2m tree, which is used by the Xen tools during saving and restoring
>>>>> (and live migration) of pv domains and for crash dump analysis. With
>>>>> three levels of the p2m tree it is possible to support up to 512
>>>>> GB of
>>>>> RAM for a 64 bit pv domain.
>>>>>
>>>>> A 32 bit pv domain can support more, as each memory page can hold
>>>>> 1024
>>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>>
>>>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>>>> p2m list.
>>>>>
>>>>> This patch expands struct arch_shared_info with a new p2m list
>>>>> virtual
>>>>> address and the mfn of the page table root. The new information is
>>>>> indicated by the domain to be valid by storing ~0UL into
>>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of
>>>>> this
>>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>>
>>>> How do you envisage this being used?  Are you expecting the tools
>>>> to do
>>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>>
>>> Yes. Not very different compared to today's mapping via the 3 level
>>> p2m tree. Just another entry format, 4 instead of 3 levels and starting
>>> at an offset.
>>
>> Yes - David and I were discussing this over lunch, and it is not
>> actually very different.
>>
>> In reality, how likely is it that the pages backing this virtual linear
>> array change?
>
> Very unlikely, I think. But not impossible.
>
>> One issue currently is that, during the live part of migration, the
>> toolstack has no way of working out whether the structure of the p2m has
>> changed (intermediate leaves rearranged, or the length increasing).
>>
>> In the case that the VM does change the structure of the p2m under the
>> feet of the toolstack, migration will either blow up in a non-subtle way
>> with a p2m/m2p mismatch, or in a subtle way with the receiving side
>> copying the new p2m over the wrong part of the new domain.
>>
>> I am wondering whether, with this new p2m method, we can take sufficient
>> steps to be able to guarantee mishaps like this can't occur.
>
> This should be easy: I could add a counter in arch_shared_info which is
> incremented whenever a p2m mapping is being changed. The toolstack could
> compare the counter values before start and at end of migration and redo
> the migration (or fail) if they are different. In order to avoid races
> I would have to increment the counter before and after changing the
> mapping.
>

That is insufficient I believe.

Consider:

* Toolstack walks pagetables and maps the frames containing the linear p2m
* Live migration starts
* VM remaps a frame in the middle of the linear p2m
* Live migration continues, but the toolstack has a stale frame in the
middle of its view of the p2m.

As the p2m is almost never expected to change, I think it might be
better to have a flag the toolstack can set to say "The toolstack is
peeking at your p2m behind your back - you must not change its structure."

Having just thought this through, I think there is also a race condition
between a VM changing an entry in the p2m, and the toolstack doing
verifications of frames being sent.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:09:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIUz-0004Ya-Ii; Fri, 14 Nov 2014 15:09:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpIUy-0004YV-8U
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:09:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	14/D9-09936-F1B16645; Fri, 14 Nov 2014 15:09:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415977756!5525651!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29111 invoked from network); 14 Nov 2014 15:09:19 -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;
	14 Nov 2014 15:09:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192874588"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:07:25 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpIT7-0001xW-9g;
	Fri, 14 Nov 2014 15:07:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpIT6-0001d3-Bz;
	Fri, 14 Nov 2014 15:07:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.6827.719509.752666@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 15:07:23 +0000
To: Wen Congyang <wency@cn.fujitsu.com>
In-Reply-To: <1412820314-323-4-git-send-email-wency@cn.fujitsu.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
	<1412820314-323-4-git-send-email-wency@cn.fujitsu.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch v2 3/3] update
	libxl__device_disk_from_xs_be() to support blktap 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

Wen Congyang writes ("[Patch v2 3/3] update libxl__device_disk_from_xs_be() to support blktap device"):
> [stuff]

Thanks for your attention to the details of this rather neglected
area.

This patch seems related to 
  [RFC Patch v4 8/9] store correct format into tapdisk-params/params
from Mon, 22 Sep 2014 13:59:20 +0800.

Is that right ?  I confess I don't know exactly how all of the tapdisk
plumbing works, but I do expect it to be rather ... idiosyncratic.  Is
this patch (and the other one) for blktap1 or blktap2 ?

Is there is some kind of document I should be looking at explaining
how the relevant blktap's xenstore protocol works ?  I found
tools/blktap/README and tools/blktap2/README but they don't seem to
answer the question.

I think it will be difficult to review this patch without a clear
description of the intended design.  You seem to have done much of the
reverse-engineering necessary, so perhaps you could provide a sketch
of the relevant information with your patch - perhaps as a doc comment
somewhere in the code, provided in a pre-patch ?  Also, I would like
to understand more clearly how this functionality interacts with Wei
Liu's new approach to libxl domain configuration management.

I think I should avoid reviewing the concrete implementation until I
feel I understand what the patch ought to do.  Otherwise we risk
iterating to improve details when the overall approach isn't
necessarily right.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:09:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIUz-0004Ya-Ii; Fri, 14 Nov 2014 15:09:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpIUy-0004YV-8U
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:09:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	14/D9-09936-F1B16645; Fri, 14 Nov 2014 15:09:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415977756!5525651!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29111 invoked from network); 14 Nov 2014 15:09:19 -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;
	14 Nov 2014 15:09:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192874588"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:07:25 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpIT7-0001xW-9g;
	Fri, 14 Nov 2014 15:07:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpIT6-0001d3-Bz;
	Fri, 14 Nov 2014 15:07:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.6827.719509.752666@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 15:07:23 +0000
To: Wen Congyang <wency@cn.fujitsu.com>
In-Reply-To: <1412820314-323-4-git-send-email-wency@cn.fujitsu.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
	<1412820314-323-4-git-send-email-wency@cn.fujitsu.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch v2 3/3] update
	libxl__device_disk_from_xs_be() to support blktap 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

Wen Congyang writes ("[Patch v2 3/3] update libxl__device_disk_from_xs_be() to support blktap device"):
> [stuff]

Thanks for your attention to the details of this rather neglected
area.

This patch seems related to 
  [RFC Patch v4 8/9] store correct format into tapdisk-params/params
from Mon, 22 Sep 2014 13:59:20 +0800.

Is that right ?  I confess I don't know exactly how all of the tapdisk
plumbing works, but I do expect it to be rather ... idiosyncratic.  Is
this patch (and the other one) for blktap1 or blktap2 ?

Is there is some kind of document I should be looking at explaining
how the relevant blktap's xenstore protocol works ?  I found
tools/blktap/README and tools/blktap2/README but they don't seem to
answer the question.

I think it will be difficult to review this patch without a clear
description of the intended design.  You seem to have done much of the
reverse-engineering necessary, so perhaps you could provide a sketch
of the relevant information with your patch - perhaps as a doc comment
somewhere in the code, provided in a pre-patch ?  Also, I would like
to understand more clearly how this functionality interacts with Wei
Liu's new approach to libxl domain configuration management.

I think I should avoid reviewing the concrete implementation until I
feel I understand what the patch ought to do.  Otherwise we risk
iterating to improve details when the overall approach isn't
necessarily right.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:09:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15: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 1XpIVX-0004au-WA; Fri, 14 Nov 2014 15:09: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 1XpIVW-0004ag-Ma
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:09:54 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F7/88-09842-24B16645; Fri, 14 Nov 2014 15:09:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415977793!9381182!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21140 invoked from network); 14 Nov 2014 15:09:53 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 15:09:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 15:09:52 +0000
Message-Id: <546629510200007800047BC3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 15:09:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
In-Reply-To: <688701120.20141114153404@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 15:34, <linux@eikelenboom.it> wrote:
> # addr2line -e ./xen-syms ffff82d080148f14
> /usr/src/new/xen-unstable/xen/include/xen/list.h:175
> 
> Which turns out to be this assert:
> /**
>  * list_del - deletes entry from list.
>  * @entry: the element to delete from the list.
>  * Note: list_empty on entry does not return true after this, the entry is
>  * in an undefined state.
>  */
> static inline void list_del(struct list_head *entry)
> {
>     ASSERT(entry->next->prev == entry);

Okay, and there's only one caller in dpci_softirq().

Now, was the guest triggering this already fully up and running at
the time of the crash, or still booting, already shutting down, or
doing yet something else it wouldn't do all the time?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:09:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15: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 1XpIVX-0004au-WA; Fri, 14 Nov 2014 15:09: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 1XpIVW-0004ag-Ma
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:09:54 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F7/88-09842-24B16645; Fri, 14 Nov 2014 15:09:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1415977793!9381182!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21140 invoked from network); 14 Nov 2014 15:09:53 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 15:09:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 15:09:52 +0000
Message-Id: <546629510200007800047BC3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 15:09:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
In-Reply-To: <688701120.20141114153404@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 15:34, <linux@eikelenboom.it> wrote:
> # addr2line -e ./xen-syms ffff82d080148f14
> /usr/src/new/xen-unstable/xen/include/xen/list.h:175
> 
> Which turns out to be this assert:
> /**
>  * list_del - deletes entry from list.
>  * @entry: the element to delete from the list.
>  * Note: list_empty on entry does not return true after this, the entry is
>  * in an undefined state.
>  */
> static inline void list_del(struct list_head *entry)
> {
>     ASSERT(entry->next->prev == entry);

Okay, and there's only one caller in dpci_softirq().

Now, was the guest triggering this already fully up and running at
the time of the crash, or still booting, already shutting down, or
doing yet something else it wouldn't do all the time?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:10:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIVp-0004e4-CK; Fri, 14 Nov 2014 15:10:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpIVo-0004dn-0d
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:10:12 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	28/5F-02954-35B16645; Fri, 14 Nov 2014 15:10:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415977809!9289861!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7395 invoked from network); 14 Nov 2014 15:10:10 -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;
	14 Nov 2014 15:10:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191409700"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:08:29 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpIU9-0001yJ-Gi;
	Fri, 14 Nov 2014 15:08:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpIU8-0001dG-Jc;
	Fri, 14 Nov 2014 15:08:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.6892.128938.521146@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 15:08:28 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415977117.7113.21.camel@citrix.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
	<1412820314-323-3-git-send-email-wency@cn.fujitsu.com>
	<21606.6212.353346.560825@mariner.uk.xensource.com>
	<1415977117.7113.21.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>, Wen Congyang <wency@cn.fujitsu.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Patch v2 2/3] correct xc_domain_save()'s 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

Ian Campbell writes ("Re: [Patch v2 2/3] correct xc_domain_save()'s return value"):
> On Fri, 2014-11-14 at 14:57 +0000, Ian Jackson wrote:
> > +            errno = EIO;
> > +            ERROR("Suspend request failed (without errno, using EINVAL)");
> 
> You mean EIO in the error message, I think.

Oops, yes.

Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:10:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIVp-0004e4-CK; Fri, 14 Nov 2014 15:10:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpIVo-0004dn-0d
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:10:12 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	28/5F-02954-35B16645; Fri, 14 Nov 2014 15:10:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415977809!9289861!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7395 invoked from network); 14 Nov 2014 15:10:10 -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;
	14 Nov 2014 15:10:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191409700"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:08:29 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpIU9-0001yJ-Gi;
	Fri, 14 Nov 2014 15:08:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpIU8-0001dG-Jc;
	Fri, 14 Nov 2014 15:08:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.6892.128938.521146@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 15:08:28 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415977117.7113.21.camel@citrix.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>
	<1412820314-323-3-git-send-email-wency@cn.fujitsu.com>
	<21606.6212.353346.560825@mariner.uk.xensource.com>
	<1415977117.7113.21.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>, Wen Congyang <wency@cn.fujitsu.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Patch v2 2/3] correct xc_domain_save()'s 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

Ian Campbell writes ("Re: [Patch v2 2/3] correct xc_domain_save()'s return value"):
> On Fri, 2014-11-14 at 14:57 +0000, Ian Jackson wrote:
> > +            errno = EIO;
> > +            ERROR("Suspend request failed (without errno, using EINVAL)");
> 
> You mean EIO in the error message, I think.

Oops, yes.

Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:12:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:12:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIYO-00055t-UK; Fri, 14 Nov 2014 15:12: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@citrix.com>) id 1XpIYO-00054t-4M
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:12:52 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	98/E1-24859-3FB16645; Fri, 14 Nov 2014 15:12:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415977968!11505050!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1899 invoked from network); 14 Nov 2014 15:12:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 15:12:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191411308"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:11:51 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpIXO-00021K-AQ;
	Fri, 14 Nov 2014 15:11:50 +0000
Date: Fri, 14 Nov 2014 15:11:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <1415805906-27316-2-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411141507550.26318@kaball.uk.xensource.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-2-git-send-email-david.vrabel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Fenghua Yu <fenghua.yu@intel.com>, Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/3] dma,
 ia64: add dma_get_required_mask_from_max_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Nov 2014, David Vrabel wrote:
> ia64 provides a duplicate of the generic dma_get_required_mask()
> because it has ARCH_HAS_GET_REQUIRED_MASK.  Provide a common
> dma_get_require_mask_max_pfn() instead.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: linux-ia64@vger.kernel.org

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/ia64/include/asm/machvec.h      |    2 +-
>  arch/ia64/include/asm/machvec_init.h |    1 -
>  arch/ia64/pci/pci.c                  |   20 --------------------
>  drivers/base/platform.c              |   10 ++++++++--
>  include/linux/dma-mapping.h          |    1 +
>  5 files changed, 10 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
> index 9c39bdf..beaa47d 100644
> --- a/arch/ia64/include/asm/machvec.h
> +++ b/arch/ia64/include/asm/machvec.h
> @@ -287,7 +287,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
>  # define platform_dma_get_ops		dma_get_ops
>  #endif
>  #ifndef platform_dma_get_required_mask
> -# define  platform_dma_get_required_mask	ia64_dma_get_required_mask
> +# define  platform_dma_get_required_mask	dma_get_required_mask_from_max_pfn
>  #endif
>  #ifndef platform_irq_to_vector
>  # define platform_irq_to_vector		__ia64_irq_to_vector
> diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
> index 37a4698..ef964b2 100644
> --- a/arch/ia64/include/asm/machvec_init.h
> +++ b/arch/ia64/include/asm/machvec_init.h
> @@ -3,7 +3,6 @@
>  
>  extern ia64_mv_send_ipi_t ia64_send_ipi;
>  extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
> -extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
>  extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
>  extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
>  extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index 291a582..79da21b 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -791,26 +791,6 @@ static void __init set_pci_dfl_cacheline_size(void)
>  	pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
>  }
>  
> -u64 ia64_dma_get_required_mask(struct device *dev)
> -{
> -	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
> -	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
> -	u64 mask;
> -
> -	if (!high_totalram) {
> -		/* convert to mask just covering totalram */
> -		low_totalram = (1 << (fls(low_totalram) - 1));
> -		low_totalram += low_totalram - 1;
> -		mask = low_totalram;
> -	} else {
> -		high_totalram = (1 << (fls(high_totalram) - 1));
> -		high_totalram += high_totalram - 1;
> -		mask = (((u64)high_totalram) << 32) + 0xffffffff;
> -	}
> -	return mask;
> -}
> -EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
> -
>  u64 dma_get_required_mask(struct device *dev)
>  {
>  	return platform_dma_get_required_mask(dev);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index b2afc29..f9f3930 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1009,8 +1009,7 @@ int __init platform_bus_init(void)
>  	return error;
>  }
>  
> -#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
> -u64 dma_get_required_mask(struct device *dev)
> +u64 dma_get_required_mask_from_max_pfn(struct device *dev)
>  {
>  	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
>  	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
> @@ -1028,6 +1027,13 @@ u64 dma_get_required_mask(struct device *dev)
>  	}
>  	return mask;
>  }
> +EXPORT_SYMBOL_GPL(dma_get_required_mask_from_max_pfn);
> +
> +#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
> +u64 dma_get_required_mask(struct device *dev)
> +{
> +	return dma_get_required_mask_from_max_pfn(dev);
> +}
>  EXPORT_SYMBOL_GPL(dma_get_required_mask);
>  #endif
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index d5d3881..6e2fdfc 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -127,6 +127,7 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
>  	return dma_set_mask_and_coherent(dev, mask);
>  }
>  
> +extern u64 dma_get_required_mask_from_max_pfn(struct device *dev);
>  extern u64 dma_get_required_mask(struct device *dev);
>  
>  #ifndef set_arch_dma_coherent_ops
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:12:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:12:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIYO-00055t-UK; Fri, 14 Nov 2014 15:12: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@citrix.com>) id 1XpIYO-00054t-4M
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:12:52 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	98/E1-24859-3FB16645; Fri, 14 Nov 2014 15:12:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415977968!11505050!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1899 invoked from network); 14 Nov 2014 15:12:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 15:12:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191411308"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:11:51 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpIXO-00021K-AQ;
	Fri, 14 Nov 2014 15:11:50 +0000
Date: Fri, 14 Nov 2014 15:11:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <1415805906-27316-2-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411141507550.26318@kaball.uk.xensource.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-2-git-send-email-david.vrabel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Fenghua Yu <fenghua.yu@intel.com>, Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/3] dma,
 ia64: add dma_get_required_mask_from_max_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Nov 2014, David Vrabel wrote:
> ia64 provides a duplicate of the generic dma_get_required_mask()
> because it has ARCH_HAS_GET_REQUIRED_MASK.  Provide a common
> dma_get_require_mask_max_pfn() instead.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: linux-ia64@vger.kernel.org

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/ia64/include/asm/machvec.h      |    2 +-
>  arch/ia64/include/asm/machvec_init.h |    1 -
>  arch/ia64/pci/pci.c                  |   20 --------------------
>  drivers/base/platform.c              |   10 ++++++++--
>  include/linux/dma-mapping.h          |    1 +
>  5 files changed, 10 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
> index 9c39bdf..beaa47d 100644
> --- a/arch/ia64/include/asm/machvec.h
> +++ b/arch/ia64/include/asm/machvec.h
> @@ -287,7 +287,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
>  # define platform_dma_get_ops		dma_get_ops
>  #endif
>  #ifndef platform_dma_get_required_mask
> -# define  platform_dma_get_required_mask	ia64_dma_get_required_mask
> +# define  platform_dma_get_required_mask	dma_get_required_mask_from_max_pfn
>  #endif
>  #ifndef platform_irq_to_vector
>  # define platform_irq_to_vector		__ia64_irq_to_vector
> diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
> index 37a4698..ef964b2 100644
> --- a/arch/ia64/include/asm/machvec_init.h
> +++ b/arch/ia64/include/asm/machvec_init.h
> @@ -3,7 +3,6 @@
>  
>  extern ia64_mv_send_ipi_t ia64_send_ipi;
>  extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
> -extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
>  extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
>  extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
>  extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index 291a582..79da21b 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -791,26 +791,6 @@ static void __init set_pci_dfl_cacheline_size(void)
>  	pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
>  }
>  
> -u64 ia64_dma_get_required_mask(struct device *dev)
> -{
> -	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
> -	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
> -	u64 mask;
> -
> -	if (!high_totalram) {
> -		/* convert to mask just covering totalram */
> -		low_totalram = (1 << (fls(low_totalram) - 1));
> -		low_totalram += low_totalram - 1;
> -		mask = low_totalram;
> -	} else {
> -		high_totalram = (1 << (fls(high_totalram) - 1));
> -		high_totalram += high_totalram - 1;
> -		mask = (((u64)high_totalram) << 32) + 0xffffffff;
> -	}
> -	return mask;
> -}
> -EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
> -
>  u64 dma_get_required_mask(struct device *dev)
>  {
>  	return platform_dma_get_required_mask(dev);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index b2afc29..f9f3930 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1009,8 +1009,7 @@ int __init platform_bus_init(void)
>  	return error;
>  }
>  
> -#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
> -u64 dma_get_required_mask(struct device *dev)
> +u64 dma_get_required_mask_from_max_pfn(struct device *dev)
>  {
>  	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
>  	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
> @@ -1028,6 +1027,13 @@ u64 dma_get_required_mask(struct device *dev)
>  	}
>  	return mask;
>  }
> +EXPORT_SYMBOL_GPL(dma_get_required_mask_from_max_pfn);
> +
> +#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
> +u64 dma_get_required_mask(struct device *dev)
> +{
> +	return dma_get_required_mask_from_max_pfn(dev);
> +}
>  EXPORT_SYMBOL_GPL(dma_get_required_mask);
>  #endif
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index d5d3881..6e2fdfc 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -127,6 +127,7 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
>  	return dma_set_mask_and_coherent(dev, mask);
>  }
>  
> +extern u64 dma_get_required_mask_from_max_pfn(struct device *dev);
>  extern u64 dma_get_required_mask(struct device *dev);
>  
>  #ifndef set_arch_dma_coherent_ops
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:13:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIZG-0005G9-Cc; Fri, 14 Nov 2014 15:13:46 +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 1XpIZE-0005Fs-RA
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:13:44 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	F8/85-02954-82C16645; Fri, 14 Nov 2014 15:13:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415978023!12060383!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27934 invoked from network); 14 Nov 2014 15:13:43 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 15:13:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 15:13:43 +0000
Message-Id: <54662A360200007800047BDB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 15:13:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
	<1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet
 with an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 03:23, <konrad.wilk@oracle.com> wrote:
> +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> +{
> +    struct domain *d = pirq_dpci->dom;
> +
> +    ASSERT(spin_is_locked(&d->event_lock));
> +
> +    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
> +    {
> +    case (1 << STATE_SCHED):
> +        /*
> +         * We are going to try to de-schedule the softirq before it goes in
> +         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
> +         */
> +        put_domain(d);
> +        /* fallthrough. */

Considering Sander's report, the only suspicious place I find is this
one: When the STATE_SCHED flag is set, pirq_dpci is on some
CPU's list. What guarantees it to get removed from that list before
getting inserted on another one?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:13:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIZG-0005G9-Cc; Fri, 14 Nov 2014 15:13:46 +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 1XpIZE-0005Fs-RA
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:13:44 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	F8/85-02954-82C16645; Fri, 14 Nov 2014 15:13:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415978023!12060383!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27934 invoked from network); 14 Nov 2014 15:13:43 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 15:13:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 15:13:43 +0000
Message-Id: <54662A360200007800047BDB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 15:13:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
	<1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet
 with an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 03:23, <konrad.wilk@oracle.com> wrote:
> +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> +{
> +    struct domain *d = pirq_dpci->dom;
> +
> +    ASSERT(spin_is_locked(&d->event_lock));
> +
> +    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
> +    {
> +    case (1 << STATE_SCHED):
> +        /*
> +         * We are going to try to de-schedule the softirq before it goes in
> +         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
> +         */
> +        put_domain(d);
> +        /* fallthrough. */

Considering Sander's report, the only suspicious place I find is this
one: When the STATE_SCHED flag is set, pirq_dpci is on some
CPU's list. What guarantees it to get removed from that list before
getting inserted on another one?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:20:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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.xen.org>)
	id 1XpIfQ-0005Ss-RQ; Fri, 14 Nov 2014 15:20:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpIfM-0005Sn-4t
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:20:04 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	3A/43-02699-3AD16645; Fri, 14 Nov 2014 15:20:03 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415978399!12635792!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17216 invoked from network); 14 Nov 2014 15:20:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 15:20:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192880196"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:19:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpIfD-0002Cr-LU;
	Fri, 14 Nov 2014 15:19:55 +0000
Date: Fri, 14 Nov 2014 15:19:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411141519100.26318@kaball.uk.xensource.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to
 be overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Nov 2014, David Vrabel wrote:
> Use dma_ops->get_required_mask() if provided, defaulting to
> dma_get_requried_mask_from_max_pfn().
> 
> This is needed on systems (such as Xen PV guests) where the DMA
> address and the physical address are not equal.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/x86/include/asm/device.h |    2 ++
>  arch/x86/kernel/pci-dma.c     |    8 ++++++++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
> index 03dd729..10bc628 100644
> --- a/arch/x86/include/asm/device.h
> +++ b/arch/x86/include/asm/device.h
> @@ -13,4 +13,6 @@ struct dev_archdata {
>  struct pdev_archdata {
>  };
>  
> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
> +
>  #endif /* _ASM_X86_DEVICE_H */
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index a25e202..5154400 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -140,6 +140,14 @@ void dma_generic_free_coherent(struct device *dev, size_t size, void *vaddr,
>  		free_pages((unsigned long)vaddr, get_order(size));
>  }
>  
> +u64 dma_get_required_mask(struct device *dev)
> +{
> +	if (dma_ops->get_required_mask)
> +		return dma_ops->get_required_mask(dev);
> +	return dma_get_required_mask_from_max_pfn(dev);
> +}
> +EXPORT_SYMBOL_GPL(dma_get_required_mask);
> +
>  /*
>   * See <Documentation/x86/x86_64/boot-options.txt> for the iommu kernel
>   * parameter documentation.
> -- 
> 1.7.10.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  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://secure-web.cisco.com/1ixXdBDpz1KdvMlO1aynlM5N1jrQ7I1zdB_g1CPo0rimcVM76xTOPAvm484tRhqPosYwwpXnvHtyzSn_CZ4-EcYzELZhn5abgWc7e5fB0Ki0nE024_U4cvFTVoR2qflul0tkkVvivUWBl8v3vMWMTT6wuEYW3UcP3Bt3ttSORXPc/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:20:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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.xen.org>)
	id 1XpIfQ-0005Ss-RQ; Fri, 14 Nov 2014 15:20:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpIfM-0005Sn-4t
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:20:04 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	3A/43-02699-3AD16645; Fri, 14 Nov 2014 15:20:03 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1415978399!12635792!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17216 invoked from network); 14 Nov 2014 15:20:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 15:20:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192880196"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:19:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpIfD-0002Cr-LU;
	Fri, 14 Nov 2014 15:19:55 +0000
Date: Fri, 14 Nov 2014 15:19:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411141519100.26318@kaball.uk.xensource.com>
References: <1415805906-27316-1-git-send-email-david.vrabel@citrix.com>
	<1415805906-27316-3-git-send-email-david.vrabel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to
 be overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Nov 2014, David Vrabel wrote:
> Use dma_ops->get_required_mask() if provided, defaulting to
> dma_get_requried_mask_from_max_pfn().
> 
> This is needed on systems (such as Xen PV guests) where the DMA
> address and the physical address are not equal.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/x86/include/asm/device.h |    2 ++
>  arch/x86/kernel/pci-dma.c     |    8 ++++++++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
> index 03dd729..10bc628 100644
> --- a/arch/x86/include/asm/device.h
> +++ b/arch/x86/include/asm/device.h
> @@ -13,4 +13,6 @@ struct dev_archdata {
>  struct pdev_archdata {
>  };
>  
> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
> +
>  #endif /* _ASM_X86_DEVICE_H */
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index a25e202..5154400 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -140,6 +140,14 @@ void dma_generic_free_coherent(struct device *dev, size_t size, void *vaddr,
>  		free_pages((unsigned long)vaddr, get_order(size));
>  }
>  
> +u64 dma_get_required_mask(struct device *dev)
> +{
> +	if (dma_ops->get_required_mask)
> +		return dma_ops->get_required_mask(dev);
> +	return dma_get_required_mask_from_max_pfn(dev);
> +}
> +EXPORT_SYMBOL_GPL(dma_get_required_mask);
> +
>  /*
>   * See <Documentation/x86/x86_64/boot-options.txt> for the iommu kernel
>   * parameter documentation.
> -- 
> 1.7.10.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  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://secure-web.cisco.com/1ixXdBDpz1KdvMlO1aynlM5N1jrQ7I1zdB_g1CPo0rimcVM76xTOPAvm484tRhqPosYwwpXnvHtyzSn_CZ4-EcYzELZhn5abgWc7e5fB0Ki0nE024_U4cvFTVoR2qflul0tkkVvivUWBl8v3vMWMTT6wuEYW3UcP3Bt3ttSORXPc/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:20:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIgD-0005WD-9M; Fri, 14 Nov 2014 15:20:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpIgC-0005W3-Es
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:20:56 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	AB/4C-29352-7DD16645; Fri, 14 Nov 2014 15:20:55 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415978455!11432505!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14411 invoked from network); 14 Nov 2014 15:20:55 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 14 Nov 2014 15:20:55 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52955 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpIf5-0008T1-8z; Fri, 14 Nov 2014 16:19:47 +0100
Date: Fri, 14 Nov 2014 16:20:52 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1224708950.20141114162052@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <546629510200007800047BC3@mail.emea.novell.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 4:09:53 PM, you wrote:

>>>> On 14.11.14 at 15:34, <linux@eikelenboom.it> wrote:
>> # addr2line -e ./xen-syms ffff82d080148f14
>> /usr/src/new/xen-unstable/xen/include/xen/list.h:175
>> 
>> Which turns out to be this assert:
>> /**
>>  * list_del - deletes entry from list.
>>  * @entry: the element to delete from the list.
>>  * Note: list_empty on entry does not return true after this, the entry is
>>  * in an undefined state.
>>  */
>> static inline void list_del(struct list_head *entry)
>> {
>>     ASSERT(entry->next->prev == entry);

> Okay, and there's only one caller in dpci_softirq().

> Now, was the guest triggering this already fully up and running at
> the time of the crash, or still booting, already shutting down, or
> doing yet something else it wouldn't do all the time?

> Jan



I had multiple guests  (from which also multiple (1 PV, 2 HVM) use pci 
passthrough (with one or multiple devices each)), running at the same time.

This occurred with all my guests up and running for a short while after host 
boot .. and pci passthough working (verified that). 

Wasn't doing anything special i can point out .. 

If it still helps i could try Andrews suggestion and try out with only commit 
aeeea485 ..

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:20:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIgD-0005WD-9M; Fri, 14 Nov 2014 15:20:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpIgC-0005W3-Es
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:20:56 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	AB/4C-29352-7DD16645; Fri, 14 Nov 2014 15:20:55 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415978455!11432505!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14411 invoked from network); 14 Nov 2014 15:20:55 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 14 Nov 2014 15:20:55 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52955 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpIf5-0008T1-8z; Fri, 14 Nov 2014 16:19:47 +0100
Date: Fri, 14 Nov 2014 16:20:52 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1224708950.20141114162052@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <546629510200007800047BC3@mail.emea.novell.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 4:09:53 PM, you wrote:

>>>> On 14.11.14 at 15:34, <linux@eikelenboom.it> wrote:
>> # addr2line -e ./xen-syms ffff82d080148f14
>> /usr/src/new/xen-unstable/xen/include/xen/list.h:175
>> 
>> Which turns out to be this assert:
>> /**
>>  * list_del - deletes entry from list.
>>  * @entry: the element to delete from the list.
>>  * Note: list_empty on entry does not return true after this, the entry is
>>  * in an undefined state.
>>  */
>> static inline void list_del(struct list_head *entry)
>> {
>>     ASSERT(entry->next->prev == entry);

> Okay, and there's only one caller in dpci_softirq().

> Now, was the guest triggering this already fully up and running at
> the time of the crash, or still booting, already shutting down, or
> doing yet something else it wouldn't do all the time?

> Jan



I had multiple guests  (from which also multiple (1 PV, 2 HVM) use pci 
passthrough (with one or multiple devices each)), running at the same time.

This occurred with all my guests up and running for a short while after host 
boot .. and pci passthough working (verified that). 

Wasn't doing anything special i can point out .. 

If it still helps i could try Andrews suggestion and try out with only commit 
aeeea485 ..

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:23:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:23:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIir-0005l5-Rf; Fri, 14 Nov 2014 15:23:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpIiq-0005kw-Cb
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:23:40 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	8B/33-25727-B7E16645; Fri, 14 Nov 2014 15:23:39 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415978616!11508244!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20783 invoked from network); 14 Nov 2014 15:23:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 15:23:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192882026"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:23:02 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpIiD-0002Gs-U6;
	Fri, 14 Nov 2014 15:23:01 +0000
Date: Fri, 14 Nov 2014 15:22:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi,
> >>
> >> I observe system freeze on latest xen/master branch.
> >>
> >> My setup is:
> >>
> >> - Jacinto 6 evm board (OMAP5)
> >> - Latest Xen 4.5.0-rc2 as hypervisor
> >> - Linux 3.8 as dom0, running on 2 vcpus
> >> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
> >> - XSM feature is disabled
> >> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
> >> compiler
> >>
> >> Freeze occurs in random moment of time during creation of domU domain.
> >> Even Xen console may be not available after freeze.
> >> Can someone suggest - what it can be? Maybe some weak places in new
> >> code? Maybe new gic, which was reworked a lot or something else?
> >>
> >> Thank you in advance for any suggestions.
> >
> > Is this really 3.8 or 3.18?
> 
> We have 3.8 in both dom0 and domU
> 
> > 3.8 is pretty old and doesn't have any of
> > the fixes to be able to safely do dma involving guest pages to
> > non-coherent devices.
> 
> This is a good point. Now we are migrating to 3.12 kernel in dom0. But
> Android will remain on 3.8. Will it help ?
> Maybe you can point me to any tree with proper DMA fixes? Note: if you
> are talking about SWIOTLB - we have your latest one, retrieved from
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
> branch:swiotlb-xen-9.1

The last and most stable series is:

http://marc.info/?l=linux-kernel&m=141579241729749&w=2

But thinking more about this, I doubt that it is a dma problem, because
you would most probably see various kind of error messages, not a
freeze.


> > Where are you storing the guest disk images?
> 
> SATA drive, dedicated to dom0, its controller has its own DMA

Are they on file or on lvm volumes?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:23:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:23:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIir-0005l5-Rf; Fri, 14 Nov 2014 15:23:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpIiq-0005kw-Cb
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:23:40 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	8B/33-25727-B7E16645; Fri, 14 Nov 2014 15:23:39 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415978616!11508244!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20783 invoked from network); 14 Nov 2014 15:23:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 15:23:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192882026"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:23:02 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpIiD-0002Gs-U6;
	Fri, 14 Nov 2014 15:23:01 +0000
Date: Fri, 14 Nov 2014 15:22:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi,
> >>
> >> I observe system freeze on latest xen/master branch.
> >>
> >> My setup is:
> >>
> >> - Jacinto 6 evm board (OMAP5)
> >> - Latest Xen 4.5.0-rc2 as hypervisor
> >> - Linux 3.8 as dom0, running on 2 vcpus
> >> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
> >> - XSM feature is disabled
> >> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
> >> compiler
> >>
> >> Freeze occurs in random moment of time during creation of domU domain.
> >> Even Xen console may be not available after freeze.
> >> Can someone suggest - what it can be? Maybe some weak places in new
> >> code? Maybe new gic, which was reworked a lot or something else?
> >>
> >> Thank you in advance for any suggestions.
> >
> > Is this really 3.8 or 3.18?
> 
> We have 3.8 in both dom0 and domU
> 
> > 3.8 is pretty old and doesn't have any of
> > the fixes to be able to safely do dma involving guest pages to
> > non-coherent devices.
> 
> This is a good point. Now we are migrating to 3.12 kernel in dom0. But
> Android will remain on 3.8. Will it help ?
> Maybe you can point me to any tree with proper DMA fixes? Note: if you
> are talking about SWIOTLB - we have your latest one, retrieved from
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
> branch:swiotlb-xen-9.1

The last and most stable series is:

http://marc.info/?l=linux-kernel&m=141579241729749&w=2

But thinking more about this, I doubt that it is a dma problem, because
you would most probably see various kind of error messages, not a
freeze.


> > Where are you storing the guest disk images?
> 
> SATA drive, dedicated to dom0, its controller has its own DMA

Are they on file or on lvm volumes?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:28:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpImq-00068x-Ll; Fri, 14 Nov 2014 15:27:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpImp-00068s-Cm
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:27:47 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	ED/5A-17735-27F16645; Fri, 14 Nov 2014 15:27:46 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415978864!11451359!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28185 invoked from network); 14 Nov 2014 15:27:46 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 15:27:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEFRcJT024338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 15:27:38 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEFRbnw017778
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 15:27:38 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEFRbll017769; Fri, 14 Nov 2014 15:27:37 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 07:27:37 -0800
Message-ID: <54662004.6050702@oracle.com>
Date: Fri, 14 Nov 2014 10:30:12 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
In-Reply-To: <21606.5282.659930.728522@mariner.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 09:41 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("[PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>> When a device is hot-unplugged libxl sends QEMU a "device-del" message
>> (via QMP). This call returns after QEMU has initiated device removal by
>> sending an interrupt to the guest. At some point later QEMU is expected
>> to clean up after the device (such as unbind/unmap MSIs), which will
>> occur when the guest signals that the device has been ejected.
> I haven't repro'd this bug, but after looking at your patch, and
> staring at the code, I think you may have misdiagnosed the problem.
>
> I found this:
>
>      if (type == LIBXL_DOMAIN_TYPE_HVM) {
>         [stuff]
>      } else if (type != LIBXL_DOMAIN_TYPE_PV)
>          abort();
>      {
>
> This is, of course, very bizarre.  For a moment I put it down to
> coding style, but the subsequent block is the PV pci unplug path.  It
> would appear therefore that HVM PCI unplug executes first the HVM
> code, and then immediately afterwards the PV code.
>
> This strangeness was introduced in abfb006f
>   "tools/libxl: explicitly grant access to needed I/O-memory ranges"
> which seems to contain an entirely wrong hunk.
>
> Can you try the patch below and see if it helps your problem ?

It does help with the first half of the problem --- we don't do the 
unnecessary unmap anymore in what now becomes PV-only 'else if (type != 
LIBXL_DOMAIN_TYPE_PV)' clause.

But it doesn't help with the second part (the one that shows Linux 
WARNING), because we still may try to reset the device before guest 
kernel is done unloading the driver. Reproducing that problem is 
probably dependent on the guest/driver: in this particular case the igb 
driver does an IN instruction while unloading the driver and if that 
instruction fails (which may happen if the device is gone from the POV 
of toolstack) then it triggers the warning.

>
> AFAICT your other patch probably isn't needed in the light of all
> this.  If it is, then I have misunderstood (and perhaps the commit
> message could be more explicit about the bug that this is allegedly
> fixing - calling a patch `Simplify ....' makes it sound like the kind
> of cleanup we don't want to take during the freeze).

And I believe we still need part of the second patch --- the one that 
removes call to xc_domain_irq_permission() for PV guests (after your 
patch is applied): this call will fail because xc_physdev_unmap_pirq() 
above it will cause hypervisor to do unmap_domain_pirq()->irq_deny_access()

So I think we need:
1. Your patch
2. My first patch
3. Part of my second patch as described above. (and make commit 
message/subject more understandable)


Thanks.
-boris

>
> Thanks
> Ian.
>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 9f40100..bec25a9 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -1255,9 +1255,9 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
>               rc = ERROR_FAIL;
>               goto out_fail;
>           }
> -    } else if (type != LIBXL_DOMAIN_TYPE_PV)
> -        abort();
> -    {
> +    } else {
> +        assert(type == LIBXL_DOMAIN_TYPE_PV);
> +
>           char *sysfs_path = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/resource", pcidev->domain,
>                                            pcidev->bus, pcidev->dev, pcidev->func);
>           FILE *f = fopen(sysfs_path, "r");


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:28:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpImq-00068x-Ll; Fri, 14 Nov 2014 15:27:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpImp-00068s-Cm
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:27:47 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	ED/5A-17735-27F16645; Fri, 14 Nov 2014 15:27:46 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1415978864!11451359!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28185 invoked from network); 14 Nov 2014 15:27:46 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 15:27:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEFRcJT024338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 15:27:38 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEFRbnw017778
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 15:27:38 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEFRbll017769; Fri, 14 Nov 2014 15:27:37 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 07:27:37 -0800
Message-ID: <54662004.6050702@oracle.com>
Date: Fri, 14 Nov 2014 10:30:12 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
In-Reply-To: <21606.5282.659930.728522@mariner.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 09:41 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("[PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>> When a device is hot-unplugged libxl sends QEMU a "device-del" message
>> (via QMP). This call returns after QEMU has initiated device removal by
>> sending an interrupt to the guest. At some point later QEMU is expected
>> to clean up after the device (such as unbind/unmap MSIs), which will
>> occur when the guest signals that the device has been ejected.
> I haven't repro'd this bug, but after looking at your patch, and
> staring at the code, I think you may have misdiagnosed the problem.
>
> I found this:
>
>      if (type == LIBXL_DOMAIN_TYPE_HVM) {
>         [stuff]
>      } else if (type != LIBXL_DOMAIN_TYPE_PV)
>          abort();
>      {
>
> This is, of course, very bizarre.  For a moment I put it down to
> coding style, but the subsequent block is the PV pci unplug path.  It
> would appear therefore that HVM PCI unplug executes first the HVM
> code, and then immediately afterwards the PV code.
>
> This strangeness was introduced in abfb006f
>   "tools/libxl: explicitly grant access to needed I/O-memory ranges"
> which seems to contain an entirely wrong hunk.
>
> Can you try the patch below and see if it helps your problem ?

It does help with the first half of the problem --- we don't do the 
unnecessary unmap anymore in what now becomes PV-only 'else if (type != 
LIBXL_DOMAIN_TYPE_PV)' clause.

But it doesn't help with the second part (the one that shows Linux 
WARNING), because we still may try to reset the device before guest 
kernel is done unloading the driver. Reproducing that problem is 
probably dependent on the guest/driver: in this particular case the igb 
driver does an IN instruction while unloading the driver and if that 
instruction fails (which may happen if the device is gone from the POV 
of toolstack) then it triggers the warning.

>
> AFAICT your other patch probably isn't needed in the light of all
> this.  If it is, then I have misunderstood (and perhaps the commit
> message could be more explicit about the bug that this is allegedly
> fixing - calling a patch `Simplify ....' makes it sound like the kind
> of cleanup we don't want to take during the freeze).

And I believe we still need part of the second patch --- the one that 
removes call to xc_domain_irq_permission() for PV guests (after your 
patch is applied): this call will fail because xc_physdev_unmap_pirq() 
above it will cause hypervisor to do unmap_domain_pirq()->irq_deny_access()

So I think we need:
1. Your patch
2. My first patch
3. Part of my second patch as described above. (and make commit 
message/subject more understandable)


Thanks.
-boris

>
> Thanks
> Ian.
>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 9f40100..bec25a9 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -1255,9 +1255,9 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
>               rc = ERROR_FAIL;
>               goto out_fail;
>           }
> -    } else if (type != LIBXL_DOMAIN_TYPE_PV)
> -        abort();
> -    {
> +    } else {
> +        assert(type == LIBXL_DOMAIN_TYPE_PV);
> +
>           char *sysfs_path = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/resource", pcidev->domain,
>                                            pcidev->bus, pcidev->dev, pcidev->func);
>           FILE *f = fopen(sysfs_path, "r");


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:32:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIra-0006Vn-IK; Fri, 14 Nov 2014 15:32:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpIrZ-0006Vi-9t
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 15:32:41 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	47/3D-22737-89026645; Fri, 14 Nov 2014 15:32:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415979159!11435239!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22501 invoked from network); 14 Nov 2014 15:32:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 15:32:40 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 7B083ADB0;
	Fri, 14 Nov 2014 15:32:39 +0000 (UTC)
Message-ID: <54662096.6060603@suse.com>
Date: Fri, 14 Nov 2014 16:32:38 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	xen-devel@lists.xensource.com, jbeulich@suse.com, 
	konrad.wilk@oracle.com, david.vrabel@citrix.com
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>	<5465FB34.9010606@suse.com>
	<54660A16.2090006@citrix.com>	<54660E5C.8030107@suse.com>
	<546618D9.5070200@citrix.com>
In-Reply-To: <546618D9.5070200@citrix.com>
Content-Length: 4811
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 03:59 PM, Andrew Cooper wrote:
> On 14/11/14 14:14, J=FCrgen Gro=DF wrote:
>> On 11/14/2014 02:56 PM, Andrew Cooper wrote:
>>> On 14/11/14 12:53, Juergen Gross wrote:
>>>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>>>> currently contains the mfn of the top level page frame of the 3 level
>>>>>> p2m tree, which is used by the Xen tools during saving and restoring
>>>>>> (and live migration) of pv domains and for crash dump analysis. With
>>>>>> three levels of the p2m tree it is possible to support up to 512
>>>>>> GB of
>>>>>> RAM for a 64 bit pv domain.
>>>>>>
>>>>>> A 32 bit pv domain can support more, as each memory page can hold
>>>>>> 1024
>>>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>>>
>>>>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>>>>> p2m list.
>>>>>>
>>>>>> This patch expands struct arch_shared_info with a new p2m list
>>>>>> virtual
>>>>>> address and the mfn of the page table root. The new information is
>>>>>> indicated by the domain to be valid by storing ~0UL into
>>>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of
>>>>>> this
>>>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>>>
>>>>> How do you envisage this being used?  Are you expecting the tools
>>>>> to do
>>>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>>>
>>>> Yes. Not very different compared to today's mapping via the 3 level
>>>> p2m tree. Just another entry format, 4 instead of 3 levels and starting
>>>> at an offset.
>>>
>>> Yes - David and I were discussing this over lunch, and it is not
>>> actually very different.
>>>
>>> In reality, how likely is it that the pages backing this virtual linear
>>> array change?
>>
>> Very unlikely, I think. But not impossible.
>>
>>> One issue currently is that, during the live part of migration, the
>>> toolstack has no way of working out whether the structure of the p2m has
>>> changed (intermediate leaves rearranged, or the length increasing).
>>>
>>> In the case that the VM does change the structure of the p2m under the
>>> feet of the toolstack, migration will either blow up in a non-subtle way
>>> with a p2m/m2p mismatch, or in a subtle way with the receiving side
>>> copying the new p2m over the wrong part of the new domain.
>>>
>>> I am wondering whether, with this new p2m method, we can take sufficient
>>> steps to be able to guarantee mishaps like this can't occur.
>>
>> This should be easy: I could add a counter in arch_shared_info which is
>> incremented whenever a p2m mapping is being changed. The toolstack could
>> compare the counter values before start and at end of migration and redo
>> the migration (or fail) if they are different. In order to avoid races
>> I would have to increment the counter before and after changing the
>> mapping.
>>
>
> That is insufficient I believe.
>
> Consider:
>
> * Toolstack walks pagetables and maps the frames containing the linear p2m
> * Live migration starts
> * VM remaps a frame in the middle of the linear p2m
> * Live migration continues, but the toolstack has a stale frame in the
> middle of its view of the p2m.

This would be covered by my suggestion. At the end of the memory
transfer (with some bogus contents) the toolstack would discover the
change of the p2m structure and either fail the migration or start it
from the beginning and thus overwriting the bogus frames.

> As the p2m is almost never expected to change, I think it might be
> better to have a flag the toolstack can set to say "The toolstack is
> peeking at your p2m behind your back - you must not change its structure."

Be careful here: changes of the structure can be due to two scenarios:
- ballooning (invalid entries being populated): this is no problem, as
   we can stop the ballooning during live migration.
- mapping of grant pages e.g. in a stub domain (first map in an area
   former marked as invalid): you can't stop this, as the stub domain
   has to do some work. Here a restart of the migration should work, as
   the p2m structure change can only happen once for each affected p2m
   page.

> Having just thought this through, I think there is also a race condition
> between a VM changing an entry in the p2m, and the toolstack doing
> verifications of frames being sent.

Okay, so the flag you mentioned should just prohibit changes in the
p2m list related to memory frames of the affected domain: ballooning
up or down, or rearranging the memory layout (does this happen today?).
Mapping and unmapping of grant pages should be still allowed.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:32:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIra-0006Vn-IK; Fri, 14 Nov 2014 15:32:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpIrZ-0006Vi-9t
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 15:32:41 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	47/3D-22737-89026645; Fri, 14 Nov 2014 15:32:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1415979159!11435239!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22501 invoked from network); 14 Nov 2014 15:32:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 15:32:40 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 7B083ADB0;
	Fri, 14 Nov 2014 15:32:39 +0000 (UTC)
Message-ID: <54662096.6060603@suse.com>
Date: Fri, 14 Nov 2014 16:32:38 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	xen-devel@lists.xensource.com, jbeulich@suse.com, 
	konrad.wilk@oracle.com, david.vrabel@citrix.com
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>	<5465FB34.9010606@suse.com>
	<54660A16.2090006@citrix.com>	<54660E5C.8030107@suse.com>
	<546618D9.5070200@citrix.com>
In-Reply-To: <546618D9.5070200@citrix.com>
Content-Length: 4811
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 03:59 PM, Andrew Cooper wrote:
> On 14/11/14 14:14, J=FCrgen Gro=DF wrote:
>> On 11/14/2014 02:56 PM, Andrew Cooper wrote:
>>> On 14/11/14 12:53, Juergen Gross wrote:
>>>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>>>> currently contains the mfn of the top level page frame of the 3 level
>>>>>> p2m tree, which is used by the Xen tools during saving and restoring
>>>>>> (and live migration) of pv domains and for crash dump analysis. With
>>>>>> three levels of the p2m tree it is possible to support up to 512
>>>>>> GB of
>>>>>> RAM for a 64 bit pv domain.
>>>>>>
>>>>>> A 32 bit pv domain can support more, as each memory page can hold
>>>>>> 1024
>>>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>>>
>>>>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>>>>> p2m list.
>>>>>>
>>>>>> This patch expands struct arch_shared_info with a new p2m list
>>>>>> virtual
>>>>>> address and the mfn of the page table root. The new information is
>>>>>> indicated by the domain to be valid by storing ~0UL into
>>>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of
>>>>>> this
>>>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>>>
>>>>> How do you envisage this being used?  Are you expecting the tools
>>>>> to do
>>>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>>>
>>>> Yes. Not very different compared to today's mapping via the 3 level
>>>> p2m tree. Just another entry format, 4 instead of 3 levels and starting
>>>> at an offset.
>>>
>>> Yes - David and I were discussing this over lunch, and it is not
>>> actually very different.
>>>
>>> In reality, how likely is it that the pages backing this virtual linear
>>> array change?
>>
>> Very unlikely, I think. But not impossible.
>>
>>> One issue currently is that, during the live part of migration, the
>>> toolstack has no way of working out whether the structure of the p2m has
>>> changed (intermediate leaves rearranged, or the length increasing).
>>>
>>> In the case that the VM does change the structure of the p2m under the
>>> feet of the toolstack, migration will either blow up in a non-subtle way
>>> with a p2m/m2p mismatch, or in a subtle way with the receiving side
>>> copying the new p2m over the wrong part of the new domain.
>>>
>>> I am wondering whether, with this new p2m method, we can take sufficient
>>> steps to be able to guarantee mishaps like this can't occur.
>>
>> This should be easy: I could add a counter in arch_shared_info which is
>> incremented whenever a p2m mapping is being changed. The toolstack could
>> compare the counter values before start and at end of migration and redo
>> the migration (or fail) if they are different. In order to avoid races
>> I would have to increment the counter before and after changing the
>> mapping.
>>
>
> That is insufficient I believe.
>
> Consider:
>
> * Toolstack walks pagetables and maps the frames containing the linear p2m
> * Live migration starts
> * VM remaps a frame in the middle of the linear p2m
> * Live migration continues, but the toolstack has a stale frame in the
> middle of its view of the p2m.

This would be covered by my suggestion. At the end of the memory
transfer (with some bogus contents) the toolstack would discover the
change of the p2m structure and either fail the migration or start it
from the beginning and thus overwriting the bogus frames.

> As the p2m is almost never expected to change, I think it might be
> better to have a flag the toolstack can set to say "The toolstack is
> peeking at your p2m behind your back - you must not change its structure."

Be careful here: changes of the structure can be due to two scenarios:
- ballooning (invalid entries being populated): this is no problem, as
   we can stop the ballooning during live migration.
- mapping of grant pages e.g. in a stub domain (first map in an area
   former marked as invalid): you can't stop this, as the stub domain
   has to do some work. Here a restart of the migration should work, as
   the p2m structure change can only happen once for each affected p2m
   page.

> Having just thought this through, I think there is also a race condition
> between a VM changing an entry in the p2m, and the toolstack doing
> verifications of frames being sent.

Okay, so the flag you mentioned should just prohibit changes in the
p2m list related to memory frames of the affected domain: ballooning
up or down, or rearranging the memory layout (does this happen today?).
Mapping and unmapping of grant pages should be still allowed.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:39:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:39:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIyC-0006h7-DW; Fri, 14 Nov 2014 15:39:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpIyA-0006h2-Iv
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:39:30 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	98/8C-25714-13226645; Fri, 14 Nov 2014 15:39:29 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415979567!8575530!1
X-Originating-IP: [64.18.0.26]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2879 invoked from network); 14 Nov 2014 15:39:28 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 15:39:28 -0000
Received: from mail-qa0-f46.google.com ([209.85.216.46]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYiLtqxtNKlpPsrs8P7eV3ZyrS8CUNL@postini.com;
	Fri, 14 Nov 2014 07:39:28 PST
Received: by mail-qa0-f46.google.com with SMTP id n8so11495353qaq.19
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 07:39:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=uG0I51wh4kP/fJF4xjFybz+jtHCPpopAR5IcwFy9mPY=;
	b=YY0yvft5mNF5TXNYeJ9Z8LvEeAnkjSXdwL8ebU45OuqNKVakgPGDm0Yh8JmW3K5eGq
	O95eQgNMCK+P0OiamDFpnrKkjS5vhZF3x8BNOYT7znvR1FuZgVsAyXMXmYR4YetmZmEy
	47F8nmlsdlJK+rfwa0can7Q2K5A+goQQZvRRE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=uG0I51wh4kP/fJF4xjFybz+jtHCPpopAR5IcwFy9mPY=;
	b=Ctz+SZwKQA+2wZzmUv+4tUpw/VXJ1lGvjD7Vl3qlTAJ8ilVICgfIUQgEZ8fRJDfI7z
	lCaJkVBj/uarSnzor7O3QBUl+8TXhFdAn9JjaA2PhHaJynOq8TiK8uWWzVweVQXtJ2wh
	gd6wPNagiCJxWO9NQgn1kOmPzHLzGwBw8cyfr5L46krP9jXg4ZWJBzNfSRu9WYpbkseb
	vAGAKxvBELweQ3xgjK6oEMj+8B6cc6lVWV9VJqA7muS24NPvYM32KI3Se8ohQMWX+AJc
	2JjWVQEDSGytOkWQK72lk9e0TKJ/MzfVaY3AXMNYes+ZcGnQpUYFZvwWluoQgH1TQpsJ
	phrQ==
X-Gm-Message-State: ALoCoQn8EO+xUGUbsfZcTEYApGtLP+vX4rzfeILCfIFZTO8w4RgBl70AVb8lg6c7Ny3LY3WXroZgUgnYs6sD0v1+2AfW+mqX/FoRNOpmI0h8sjRosknF1EnrRNpyRRh1HEdsp9AItu7S3WZBidZhVtbDMzyA8QZE0A==
X-Received: by 10.140.109.102 with SMTP id k93mr12041227qgf.83.1415979566170; 
	Fri, 14 Nov 2014 07:39:26 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.109.102 with SMTP id k93mr12041195qgf.83.1415979565890; 
	Fri, 14 Nov 2014 07:39:25 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 07:39:25 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
Date: Fri, 14 Nov 2014 17:39:25 +0200
Message-ID: <CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi,
>> >>
>> >> I observe system freeze on latest xen/master branch.
>> >>
>> >> My setup is:
>> >>
>> >> - Jacinto 6 evm board (OMAP5)
>> >> - Latest Xen 4.5.0-rc2 as hypervisor
>> >> - Linux 3.8 as dom0, running on 2 vcpus
>> >> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
>> >> - XSM feature is disabled
>> >> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
>> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
>> >> compiler
>> >>
>> >> Freeze occurs in random moment of time during creation of domU domain.
>> >> Even Xen console may be not available after freeze.
>> >> Can someone suggest - what it can be? Maybe some weak places in new
>> >> code? Maybe new gic, which was reworked a lot or something else?
>> >>
>> >> Thank you in advance for any suggestions.
>> >
>> > Is this really 3.8 or 3.18?
>>
>> We have 3.8 in both dom0 and domU
>>
>> > 3.8 is pretty old and doesn't have any of
>> > the fixes to be able to safely do dma involving guest pages to
>> > non-coherent devices.
>>
>> This is a good point. Now we are migrating to 3.12 kernel in dom0. But
>> Android will remain on 3.8. Will it help ?
>> Maybe you can point me to any tree with proper DMA fixes? Note: if you
>> are talking about SWIOTLB - we have your latest one, retrieved from
>> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
>> branch:swiotlb-xen-9.1
>
> The last and most stable series is:
>
> http://marc.info/?l=linux-kernel&m=141579241729749&w=2
>

Thanks  - I'll try this series anyway.

> But thinking more about this, I doubt that it is a dma problem, because
> you would most probably see various kind of error messages, not a
> freeze.
>

Agree.

>
>> > Where are you storing the guest disk images?
>>
>> SATA drive, dedicated to dom0, its controller has its own DMA
>
> Are they on file or on lvm volumes?

Images are on file.

Also note - freeze depends on system load. It reproduces more
frequently if I start Android + QNX + all frontends/backends drivers.
Starting Android only without any addition drivers works more less
stable. It looks like issue is reproduced when domU starts in parallel
with backends drivers in dom0.
But the same works fine with old Xen 4.4.

Regards,
Andrii


-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:39:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:39:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpIyC-0006h7-DW; Fri, 14 Nov 2014 15:39:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpIyA-0006h2-Iv
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:39:30 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	98/8C-25714-13226645; Fri, 14 Nov 2014 15:39:29 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415979567!8575530!1
X-Originating-IP: [64.18.0.26]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2879 invoked from network); 14 Nov 2014 15:39:28 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 15:39:28 -0000
Received: from mail-qa0-f46.google.com ([209.85.216.46]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYiLtqxtNKlpPsrs8P7eV3ZyrS8CUNL@postini.com;
	Fri, 14 Nov 2014 07:39:28 PST
Received: by mail-qa0-f46.google.com with SMTP id n8so11495353qaq.19
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 07:39:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=uG0I51wh4kP/fJF4xjFybz+jtHCPpopAR5IcwFy9mPY=;
	b=YY0yvft5mNF5TXNYeJ9Z8LvEeAnkjSXdwL8ebU45OuqNKVakgPGDm0Yh8JmW3K5eGq
	O95eQgNMCK+P0OiamDFpnrKkjS5vhZF3x8BNOYT7znvR1FuZgVsAyXMXmYR4YetmZmEy
	47F8nmlsdlJK+rfwa0can7Q2K5A+goQQZvRRE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=uG0I51wh4kP/fJF4xjFybz+jtHCPpopAR5IcwFy9mPY=;
	b=Ctz+SZwKQA+2wZzmUv+4tUpw/VXJ1lGvjD7Vl3qlTAJ8ilVICgfIUQgEZ8fRJDfI7z
	lCaJkVBj/uarSnzor7O3QBUl+8TXhFdAn9JjaA2PhHaJynOq8TiK8uWWzVweVQXtJ2wh
	gd6wPNagiCJxWO9NQgn1kOmPzHLzGwBw8cyfr5L46krP9jXg4ZWJBzNfSRu9WYpbkseb
	vAGAKxvBELweQ3xgjK6oEMj+8B6cc6lVWV9VJqA7muS24NPvYM32KI3Se8ohQMWX+AJc
	2JjWVQEDSGytOkWQK72lk9e0TKJ/MzfVaY3AXMNYes+ZcGnQpUYFZvwWluoQgH1TQpsJ
	phrQ==
X-Gm-Message-State: ALoCoQn8EO+xUGUbsfZcTEYApGtLP+vX4rzfeILCfIFZTO8w4RgBl70AVb8lg6c7Ny3LY3WXroZgUgnYs6sD0v1+2AfW+mqX/FoRNOpmI0h8sjRosknF1EnrRNpyRRh1HEdsp9AItu7S3WZBidZhVtbDMzyA8QZE0A==
X-Received: by 10.140.109.102 with SMTP id k93mr12041227qgf.83.1415979566170; 
	Fri, 14 Nov 2014 07:39:26 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.109.102 with SMTP id k93mr12041195qgf.83.1415979565890; 
	Fri, 14 Nov 2014 07:39:25 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 07:39:25 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
Date: Fri, 14 Nov 2014 17:39:25 +0200
Message-ID: <CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi,
>> >>
>> >> I observe system freeze on latest xen/master branch.
>> >>
>> >> My setup is:
>> >>
>> >> - Jacinto 6 evm board (OMAP5)
>> >> - Latest Xen 4.5.0-rc2 as hypervisor
>> >> - Linux 3.8 as dom0, running on 2 vcpus
>> >> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
>> >> - XSM feature is disabled
>> >> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
>> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
>> >> compiler
>> >>
>> >> Freeze occurs in random moment of time during creation of domU domain.
>> >> Even Xen console may be not available after freeze.
>> >> Can someone suggest - what it can be? Maybe some weak places in new
>> >> code? Maybe new gic, which was reworked a lot or something else?
>> >>
>> >> Thank you in advance for any suggestions.
>> >
>> > Is this really 3.8 or 3.18?
>>
>> We have 3.8 in both dom0 and domU
>>
>> > 3.8 is pretty old and doesn't have any of
>> > the fixes to be able to safely do dma involving guest pages to
>> > non-coherent devices.
>>
>> This is a good point. Now we are migrating to 3.12 kernel in dom0. But
>> Android will remain on 3.8. Will it help ?
>> Maybe you can point me to any tree with proper DMA fixes? Note: if you
>> are talking about SWIOTLB - we have your latest one, retrieved from
>> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
>> branch:swiotlb-xen-9.1
>
> The last and most stable series is:
>
> http://marc.info/?l=linux-kernel&m=141579241729749&w=2
>

Thanks  - I'll try this series anyway.

> But thinking more about this, I doubt that it is a dma problem, because
> you would most probably see various kind of error messages, not a
> freeze.
>

Agree.

>
>> > Where are you storing the guest disk images?
>>
>> SATA drive, dedicated to dom0, its controller has its own DMA
>
> Are they on file or on lvm volumes?

Images are on file.

Also note - freeze depends on system load. It reproduces more
frequently if I start Android + QNX + all frontends/backends drivers.
Starting Android only without any addition drivers works more less
stable. It looks like issue is reproduced when domU starts in parallel
with backends drivers in dom0.
But the same works fine with old Xen 4.4.

Regards,
Andrii


-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:44:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15: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 1XpJ2X-0006xc-2z; Fri, 14 Nov 2014 15:44:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpJ2V-0006xW-5i
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:43:59 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	69/33-24532-E3326645; Fri, 14 Nov 2014 15:43:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415979838!12864716!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24958 invoked from network); 14 Nov 2014 15:43:58 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 15:43:58 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 15:43:57 +0000
Message-Id: <5466314E0200007800047C90@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 15:43:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
In-Reply-To: <1224708950.20141114162052@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
> If it still helps i could try Andrews suggestion and try out with only 
> commit aeeea485 ..

Yes, even if it's pretty certain it's the second of the commits, verifying
this would be helpful (or if the assumption is wrong, the pattern it's
dying with would change and hence perhaps provide further clues).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:44:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15: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 1XpJ2X-0006xc-2z; Fri, 14 Nov 2014 15:44:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpJ2V-0006xW-5i
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:43:59 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	69/33-24532-E3326645; Fri, 14 Nov 2014 15:43:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415979838!12864716!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24958 invoked from network); 14 Nov 2014 15:43:58 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 15:43:58 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 15:43:57 +0000
Message-Id: <5466314E0200007800047C90@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 15:43:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
In-Reply-To: <1224708950.20141114162052@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
> If it still helps i could try Andrews suggestion and try out with only 
> commit aeeea485 ..

Yes, even if it's pretty certain it's the second of the commits, verifying
this would be helpful (or if the assumption is wrong, the pattern it's
dying with would change and hence perhaps provide further clues).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:49:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:49:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJ7v-0007EO-Rv; Fri, 14 Nov 2014 15:49:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XpJ7u-0007EJ-IQ
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:49:34 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BA/DA-09936-D8426645; Fri, 14 Nov 2014 15:49:33 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415980173!12863998!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13819 invoked from network); 14 Nov 2014 15:49:33 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 15:49:33 -0000
Received: by mail-wi0-f169.google.com with SMTP id n3so5523141wiv.2
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 07:49:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=3POf451k/BKBGBuzTwaNYWLLJDb3a2L2kiQiE7Cvklg=;
	b=Js3jjWIX4XMR8KwJ8QR7augtbQ8c3r1K15l4JQjaMrmZLGzYiSAGKnxsSzCaLyhhJ1
	vdAcy+N2GwEberMo2NzCDsZrh54+/di9dkj3qrdViKDT1SulxT9+1RNEf9Z8svueS40H
	wW/i2diXriwAL0rz4TqPhxDM/CsPw950t4Ql1PUvu+08YD9CY9/7y07uQ8PYjiKFIsN3
	NyaP+duTvSWrK+6sxudoHoxCwMQtKriAslEztfweRIswDp6qPfglEVxWaCw7jonWCEwZ
	Em/wZYYkbuSXkhBoqtfCs0ckC32t38hV3tPOdgFT9yB2/MfkBknPVP7oiPY+EkvSOiBJ
	INqQ==
X-Gm-Message-State: ALoCoQmbNiVAF5cYYn8tPTK45MzTnbeq+EnC7Vap4M/B7QNXGJ0FMYVrbcCobj/tJrytLyiH1IAU
X-Received: by 10.194.236.200 with SMTP id uw8mr15444755wjc.50.1415980173277; 
	Fri, 14 Nov 2014 07:49:33 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id p8sm7125512wia.1.2014.11.14.07.49.31
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 14 Nov 2014 07:49:32 -0800 (PST)
Message-ID: <54662484.9060708@linaro.org>
Date: Fri, 14 Nov 2014 15:49:24 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
In-Reply-To: <CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Andrii,

On 11/14/2014 03:39 PM, Andrii Tseglytskyi wrote:
> Also note - freeze depends on system load. It reproduces more
> frequently if I start Android + QNX + all frontends/backends drivers.
> Starting Android only without any addition drivers works more less
> stable. It looks like issue is reproduced when domU starts in parallel
> with backends drivers in dom0.
> But the same works fine with old Xen 4.4.

To be sure, when you say "xen/master" is it a vanilla Xen? Or do you
have patches on top of it?

Also, what are the frontends/backends?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:49:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:49:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJ7v-0007EO-Rv; Fri, 14 Nov 2014 15:49:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XpJ7u-0007EJ-IQ
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:49:34 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BA/DA-09936-D8426645; Fri, 14 Nov 2014 15:49:33 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1415980173!12863998!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13819 invoked from network); 14 Nov 2014 15:49:33 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 15:49:33 -0000
Received: by mail-wi0-f169.google.com with SMTP id n3so5523141wiv.2
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 07:49:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=3POf451k/BKBGBuzTwaNYWLLJDb3a2L2kiQiE7Cvklg=;
	b=Js3jjWIX4XMR8KwJ8QR7augtbQ8c3r1K15l4JQjaMrmZLGzYiSAGKnxsSzCaLyhhJ1
	vdAcy+N2GwEberMo2NzCDsZrh54+/di9dkj3qrdViKDT1SulxT9+1RNEf9Z8svueS40H
	wW/i2diXriwAL0rz4TqPhxDM/CsPw950t4Ql1PUvu+08YD9CY9/7y07uQ8PYjiKFIsN3
	NyaP+duTvSWrK+6sxudoHoxCwMQtKriAslEztfweRIswDp6qPfglEVxWaCw7jonWCEwZ
	Em/wZYYkbuSXkhBoqtfCs0ckC32t38hV3tPOdgFT9yB2/MfkBknPVP7oiPY+EkvSOiBJ
	INqQ==
X-Gm-Message-State: ALoCoQmbNiVAF5cYYn8tPTK45MzTnbeq+EnC7Vap4M/B7QNXGJ0FMYVrbcCobj/tJrytLyiH1IAU
X-Received: by 10.194.236.200 with SMTP id uw8mr15444755wjc.50.1415980173277; 
	Fri, 14 Nov 2014 07:49:33 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id p8sm7125512wia.1.2014.11.14.07.49.31
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 14 Nov 2014 07:49:32 -0800 (PST)
Message-ID: <54662484.9060708@linaro.org>
Date: Fri, 14 Nov 2014 15:49:24 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
In-Reply-To: <CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Andrii,

On 11/14/2014 03:39 PM, Andrii Tseglytskyi wrote:
> Also note - freeze depends on system load. It reproduces more
> frequently if I start Android + QNX + all frontends/backends drivers.
> Starting Android only without any addition drivers works more less
> stable. It looks like issue is reproduced when domU starts in parallel
> with backends drivers in dom0.
> But the same works fine with old Xen 4.4.

To be sure, when you say "xen/master" is it a vanilla Xen? Or do you
have patches on top of it?

Also, what are the frontends/backends?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:51:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:51:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJ9c-0007K5-Bn; Fri, 14 Nov 2014 15:51:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJ9b-0007Jw-30
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:51:19 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	77/3B-26652-6F426645; Fri, 14 Nov 2014 15:51:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415980273!11481946!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2240 invoked from network); 14 Nov 2014 15:51:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 15:51:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191430299"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:51:09 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJ9R-0002tA-3e;
	Fri, 14 Nov 2014 15:51:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJ9Q-0001jY-AN;
	Fri, 14 Nov 2014 15:51:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.9451.524882.759471@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 15:51:07 +0000
To: Antti Kantee <pooka@iki.fi>
Newsgroups: chiark.mail.sourceforge.rumpkernel.users
In-Reply-To: <546506F8.6080709@iki.fi>
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk> <5464DECB.8090001@iki.fi>
	<20141113170726.GB9560@nodbug.moloch.sk> <5464E89A.7000908@iki.fi>
	<20141113185742.GD9560@nodbug.moloch.sk> <546506F8.6080709@iki.fi>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Antti Kantee writes ("Re: RFC: Configuring rumprun-xen application stacks from Xenstore"):
> user-visible != internally visible.  We can for example build /etc into 
> the image as data and mount it as a memory file system at runtime or 
> symlink /etc/resolv.conf to /resolv.conf.  I'd completely avoid 
> modifying libc until there's a better understanding of the role of /etc 
> with experience from dozens of varying applications.  Modifying over 
> upstream is a balancing act, because then we stop getting the 
> *pre-tested* code for free.

I agree that having rumprun-xen create a suitable /etc image and feed
it to the guest is a very good idea.

I wonder if this mechanism could be used for some or all of the things
that you're currently using xenstore for.  Specifying which virtual
block devices to mount where, or what network configuration to use,
are things that other rump kernel runners would want to do.  Putting
that information in a stunt /etc seems like it might make more
commonality.

Another observation I had was: perhaps we can make some of this
configuration unnecessary, or at least we could provide sensible
defaults.  If the guest has been given a single network interface it
probably ought to do DHCPv4 and IPv6 autoconf on it, unless it has
been told otherwise.

Feel free to tell me I'm wrong about both of the above.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:51:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:51:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJ9c-0007K5-Bn; Fri, 14 Nov 2014 15:51:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJ9b-0007Jw-30
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 15:51:19 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	77/3B-26652-6F426645; Fri, 14 Nov 2014 15:51:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415980273!11481946!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2240 invoked from network); 14 Nov 2014 15:51:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 15:51:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191430299"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 10:51:09 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJ9R-0002tA-3e;
	Fri, 14 Nov 2014 15:51:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJ9Q-0001jY-AN;
	Fri, 14 Nov 2014 15:51:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.9451.524882.759471@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 15:51:07 +0000
To: Antti Kantee <pooka@iki.fi>
Newsgroups: chiark.mail.sourceforge.rumpkernel.users
In-Reply-To: <546506F8.6080709@iki.fi>
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk> <5464DECB.8090001@iki.fi>
	<20141113170726.GB9560@nodbug.moloch.sk> <5464E89A.7000908@iki.fi>
	<20141113185742.GD9560@nodbug.moloch.sk> <546506F8.6080709@iki.fi>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Antti Kantee writes ("Re: RFC: Configuring rumprun-xen application stacks from Xenstore"):
> user-visible != internally visible.  We can for example build /etc into 
> the image as data and mount it as a memory file system at runtime or 
> symlink /etc/resolv.conf to /resolv.conf.  I'd completely avoid 
> modifying libc until there's a better understanding of the role of /etc 
> with experience from dozens of varying applications.  Modifying over 
> upstream is a balancing act, because then we stop getting the 
> *pre-tested* code for free.

I agree that having rumprun-xen create a suitable /etc image and feed
it to the guest is a very good idea.

I wonder if this mechanism could be used for some or all of the things
that you're currently using xenstore for.  Specifying which virtual
block devices to mount where, or what network configuration to use,
are things that other rump kernel runners would want to do.  Putting
that information in a stunt /etc seems like it might make more
commonality.

Another observation I had was: perhaps we can make some of this
configuration unnecessary, or at least we could provide sensible
defaults.  If the guest has been given a single network interface it
probably ought to do DHCPv4 and IPv6 autoconf on it, unless it has
been told otherwise.

Feel free to tell me I'm wrong about both of the above.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:59:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:59:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJH0-0007nV-HE; Fri, 14 Nov 2014 15:58:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpJGy-0007nQ-Pc
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:58:56 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C0/2B-02957-0C626645; Fri, 14 Nov 2014 15:58:56 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415980733!12646771!1
X-Originating-IP: [64.18.0.24]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 14 Nov 2014 15:58:55 -0000
Received: from exprod5og112.obsmtp.com (HELO exprod5og112.obsmtp.com)
	(64.18.0.24)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 15:58:55 -0000
Received: from mail-qg0-f44.google.com ([209.85.192.44]) (using TLSv1) by
	exprod5ob112.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYmvTyqOzrfCgmDFgCj+v6xVXgzHZ+v@postini.com;
	Fri, 14 Nov 2014 07:58:54 PST
Received: by mail-qg0-f44.google.com with SMTP id q107so12114828qgd.17
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 07:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=mmllDRYTR/LUrZxB8pViZ4Ww5BFMCysmLdHifXt9avE=;
	b=BA88CTdTj1theQ6vhMv2AfNqKWw4OEnn72pKuHp6wND9yOMGwZ7d4Ld0uF8ttMN8CO
	eD51r35kEBKfbZ7PN44dx1He1dOGfTtw+K0v/nmOzt58fKATARFqXxAkPUhgynzS87zp
	wZGG2u7bL1NEG2RNtpiNdA1Y1Vz2D7dPEJ+0A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=mmllDRYTR/LUrZxB8pViZ4Ww5BFMCysmLdHifXt9avE=;
	b=IoittzNbpS9uSHS+TuXTF8TED0OzLqfr/z4ik0+vMCNx6pUqZk7HAf+2nE82JZ1LGE
	P2pAE7UFDqpR58y27xuffdsLI+Bm2XQbDou1//DXBnQNSqxidSB3L1e/mefvop9isDDk
	Aulpxrl1hs+z4Kur6pGNHDfI1QMxTQan1WDmKrnidFetosozDWFqC60OYzDabmmCgZUd
	S+KNUSubkn/V9ZdFtNMuA582CsXJ+mOdeZAZThVyxn0u1iuT4UBYmoXoX8gzsn9z9+Xw
	KeqgW/t1rLS/9g6n2eN4yyhjd9lsKrUrdfECDJiKdimmT04dRJp6Pe7a232d58r9qZwL
	bleQ==
X-Gm-Message-State: ALoCoQmRj00sknluSheyZ0kBeG37aYEGhiCDNL46A7UAhU47qvOBIZt7VdKj6AHZxzk6GdKIgd+s7HDYAag3FfECv99fFMBq52XYllv7PG+g6kcsxB5zjueyxsWT6YAjv7j5T2f6v8KaY3iajGKVPaIIoYvGp/z7GA==
X-Received: by 10.140.107.163 with SMTP id h32mr7009161qgf.34.1415980732520;
	Fri, 14 Nov 2014 07:58:52 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.107.163 with SMTP id h32mr7009146qgf.34.1415980732314;
	Fri, 14 Nov 2014 07:58:52 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 07:58:52 -0800 (PST)
In-Reply-To: <54662484.9060708@linaro.org>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<54662484.9060708@linaro.org>
Date: Fri, 14 Nov 2014 17:58:52 +0200
Message-ID: <CAH_mUMPnK6XvhGu9+7sEk80udx3bG7Wf2tVxYu1djLWC=AgoHg@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Julien,

On Fri, Nov 14, 2014 at 5:49 PM, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Andrii,
>
> On 11/14/2014 03:39 PM, Andrii Tseglytskyi wrote:
>> Also note - freeze depends on system load. It reproduces more
>> frequently if I start Android + QNX + all frontends/backends drivers.
>> Starting Android only without any addition drivers works more less
>> stable. It looks like issue is reproduced when domU starts in parallel
>> with backends drivers in dom0.
>> But the same works fine with old Xen 4.4.
>
> To be sure, when you say "xen/master" is it a vanilla Xen? Or do you
> have patches on top of it?
>

This is my work tree, I have some local patches, specific to our system:

579f19c (HEAD, dev_xen_4.5_rc2_04) xsm: arm: allow dom0 to use send
call on during event_channel creation <-- XSM is currently disabled,
this one has no effect
0f1bd43 kbdif: add raw events passing
b7289a0 pvfb: add release event
bd979de xen/tools: Fix virtual disks helper scripts.
81d2f11 libxl: skip memory finalize if appended DTB found <-- we have
device tree attached to domU zImage, we skip initializetion of domU
DTB
6c7f2ae libxc: skip constructing DTB during zImage loading <-- we have
device tree attached to domU zImage, we skip initializetion of domU
DTB
2b4ba6c libxl: add ability to skip constructing DTB <-- we have device
tree attached to domU zImage, we skip initializetion of domU DTB
bd226aa Revert "tools: arm: remove code to check for a DTB appended to
the kernel" <-- we have device tree attached to domU zImage, we skip
initializetion of domU DTB
e445c33 arm: decrease size of RAM memory for arm guest  <-- We have
memory mapped registers starting from 0x40000000, so I moved rambase
to 0x80000000
3a00dd2 flask/policy: allow domU to use previously-mapped I/O-memory
<-- XSM is currently disabled, this one has no effect
0fd131ac2 fix commit xen/arm: Add support for GICv3 for domU
cacfcc5 (tag: 4.5.0-rc2) Xen 4.5.0-rc2: Update tag for QEMU upstream tree....
e6fa63d (xen_baseline/master) pvgrub: ignore NUL
fda1614 xen/arm: Add support for GICv3 for domU


> Also, what are the frontends/backends?

We have some userspace backend drivers - audio, framebuffer, event device, etc

I may send a tarball with all my local patches if needed.

Regards,
Andrii

>
> Regards,
>
> --
> Julien Grall



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 15:59:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 15:59:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJH0-0007nV-HE; Fri, 14 Nov 2014 15:58:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpJGy-0007nQ-Pc
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 15:58:56 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C0/2B-02957-0C626645; Fri, 14 Nov 2014 15:58:56 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415980733!12646771!1
X-Originating-IP: [64.18.0.24]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 14 Nov 2014 15:58:55 -0000
Received: from exprod5og112.obsmtp.com (HELO exprod5og112.obsmtp.com)
	(64.18.0.24)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 15:58:55 -0000
Received: from mail-qg0-f44.google.com ([209.85.192.44]) (using TLSv1) by
	exprod5ob112.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYmvTyqOzrfCgmDFgCj+v6xVXgzHZ+v@postini.com;
	Fri, 14 Nov 2014 07:58:54 PST
Received: by mail-qg0-f44.google.com with SMTP id q107so12114828qgd.17
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 07:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=mmllDRYTR/LUrZxB8pViZ4Ww5BFMCysmLdHifXt9avE=;
	b=BA88CTdTj1theQ6vhMv2AfNqKWw4OEnn72pKuHp6wND9yOMGwZ7d4Ld0uF8ttMN8CO
	eD51r35kEBKfbZ7PN44dx1He1dOGfTtw+K0v/nmOzt58fKATARFqXxAkPUhgynzS87zp
	wZGG2u7bL1NEG2RNtpiNdA1Y1Vz2D7dPEJ+0A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=mmllDRYTR/LUrZxB8pViZ4Ww5BFMCysmLdHifXt9avE=;
	b=IoittzNbpS9uSHS+TuXTF8TED0OzLqfr/z4ik0+vMCNx6pUqZk7HAf+2nE82JZ1LGE
	P2pAE7UFDqpR58y27xuffdsLI+Bm2XQbDou1//DXBnQNSqxidSB3L1e/mefvop9isDDk
	Aulpxrl1hs+z4Kur6pGNHDfI1QMxTQan1WDmKrnidFetosozDWFqC60OYzDabmmCgZUd
	S+KNUSubkn/V9ZdFtNMuA582CsXJ+mOdeZAZThVyxn0u1iuT4UBYmoXoX8gzsn9z9+Xw
	KeqgW/t1rLS/9g6n2eN4yyhjd9lsKrUrdfECDJiKdimmT04dRJp6Pe7a232d58r9qZwL
	bleQ==
X-Gm-Message-State: ALoCoQmRj00sknluSheyZ0kBeG37aYEGhiCDNL46A7UAhU47qvOBIZt7VdKj6AHZxzk6GdKIgd+s7HDYAag3FfECv99fFMBq52XYllv7PG+g6kcsxB5zjueyxsWT6YAjv7j5T2f6v8KaY3iajGKVPaIIoYvGp/z7GA==
X-Received: by 10.140.107.163 with SMTP id h32mr7009161qgf.34.1415980732520;
	Fri, 14 Nov 2014 07:58:52 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.107.163 with SMTP id h32mr7009146qgf.34.1415980732314;
	Fri, 14 Nov 2014 07:58:52 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 07:58:52 -0800 (PST)
In-Reply-To: <54662484.9060708@linaro.org>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<54662484.9060708@linaro.org>
Date: Fri, 14 Nov 2014 17:58:52 +0200
Message-ID: <CAH_mUMPnK6XvhGu9+7sEk80udx3bG7Wf2tVxYu1djLWC=AgoHg@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Julien,

On Fri, Nov 14, 2014 at 5:49 PM, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Andrii,
>
> On 11/14/2014 03:39 PM, Andrii Tseglytskyi wrote:
>> Also note - freeze depends on system load. It reproduces more
>> frequently if I start Android + QNX + all frontends/backends drivers.
>> Starting Android only without any addition drivers works more less
>> stable. It looks like issue is reproduced when domU starts in parallel
>> with backends drivers in dom0.
>> But the same works fine with old Xen 4.4.
>
> To be sure, when you say "xen/master" is it a vanilla Xen? Or do you
> have patches on top of it?
>

This is my work tree, I have some local patches, specific to our system:

579f19c (HEAD, dev_xen_4.5_rc2_04) xsm: arm: allow dom0 to use send
call on during event_channel creation <-- XSM is currently disabled,
this one has no effect
0f1bd43 kbdif: add raw events passing
b7289a0 pvfb: add release event
bd979de xen/tools: Fix virtual disks helper scripts.
81d2f11 libxl: skip memory finalize if appended DTB found <-- we have
device tree attached to domU zImage, we skip initializetion of domU
DTB
6c7f2ae libxc: skip constructing DTB during zImage loading <-- we have
device tree attached to domU zImage, we skip initializetion of domU
DTB
2b4ba6c libxl: add ability to skip constructing DTB <-- we have device
tree attached to domU zImage, we skip initializetion of domU DTB
bd226aa Revert "tools: arm: remove code to check for a DTB appended to
the kernel" <-- we have device tree attached to domU zImage, we skip
initializetion of domU DTB
e445c33 arm: decrease size of RAM memory for arm guest  <-- We have
memory mapped registers starting from 0x40000000, so I moved rambase
to 0x80000000
3a00dd2 flask/policy: allow domU to use previously-mapped I/O-memory
<-- XSM is currently disabled, this one has no effect
0fd131ac2 fix commit xen/arm: Add support for GICv3 for domU
cacfcc5 (tag: 4.5.0-rc2) Xen 4.5.0-rc2: Update tag for QEMU upstream tree....
e6fa63d (xen_baseline/master) pvgrub: ignore NUL
fda1614 xen/arm: Add support for GICv3 for domU


> Also, what are the frontends/backends?

We have some userspace backend drivers - audio, framebuffer, event device, etc

I may send a tarball with all my local patches if needed.

Regards,
Andrii

>
> Regards,
>
> --
> Julien Grall



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:03:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJLW-0000AS-Bw; Fri, 14 Nov 2014 16:03:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJLU-0000AN-R1
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:03:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0D/76-09842-8D726645; Fri, 14 Nov 2014 16:03:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415981014!12846669!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22863 invoked from network); 14 Nov 2014 16:03:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:03:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192900872"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:02:02 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJJx-00039W-4o;
	Fri, 14 Nov 2014 16:02:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJJw-0001lG-EM;
	Fri, 14 Nov 2014 16:02:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.10103.850619.644934@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 16:01:59 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54662004.6050702@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> But it doesn't help with the second part (the one that shows Linux 
> WARNING), because we still may try to reset the device before guest 
> kernel is done unloading the driver. Reproducing that problem is 
> probably dependent on the guest/driver: in this particular case the igb 
> driver does an IN instruction while unloading the driver and if that 
> instruction fails (which may happen if the device is gone from the POV 
> of toolstack) then it triggers the warning.

Right.  OK.  Looking at the code, I think you have convinced about
that.    I will review the implementation in your patch now.

> And I believe we still need part of the second patch --- the one that 
> removes call to xc_domain_irq_permission() for PV guests (after your 
> patch is applied): this call will fail because xc_physdev_unmap_pirq() 
> above it will cause hypervisor to do unmap_domain_pirq()->irq_deny_access()

What call to xc_physdev_unmap_pirq ?  I see one in the PV path.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:03:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJLW-0000AS-Bw; Fri, 14 Nov 2014 16:03:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJLU-0000AN-R1
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:03:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0D/76-09842-8D726645; Fri, 14 Nov 2014 16:03:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1415981014!12846669!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22863 invoked from network); 14 Nov 2014 16:03:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:03:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192900872"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:02:02 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJJx-00039W-4o;
	Fri, 14 Nov 2014 16:02:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJJw-0001lG-EM;
	Fri, 14 Nov 2014 16:02:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.10103.850619.644934@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 16:01:59 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54662004.6050702@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> But it doesn't help with the second part (the one that shows Linux 
> WARNING), because we still may try to reset the device before guest 
> kernel is done unloading the driver. Reproducing that problem is 
> probably dependent on the guest/driver: in this particular case the igb 
> driver does an IN instruction while unloading the driver and if that 
> instruction fails (which may happen if the device is gone from the POV 
> of toolstack) then it triggers the warning.

Right.  OK.  Looking at the code, I think you have convinced about
that.    I will review the implementation in your patch now.

> And I believe we still need part of the second patch --- the one that 
> removes call to xc_domain_irq_permission() for PV guests (after your 
> patch is applied): this call will fail because xc_physdev_unmap_pirq() 
> above it will cause hypervisor to do unmap_domain_pirq()->irq_deny_access()

What call to xc_physdev_unmap_pirq ?  I see one in the PV path.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:10:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJRd-0000JU-7t; Fri, 14 Nov 2014 16:09:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpJRc-0000JP-9s
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 16:09:56 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	25/F0-03145-35926645; Fri, 14 Nov 2014 16:09:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415981393!12649767!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16545 invoked from network); 14 Nov 2014 16:09:54 -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;
	14 Nov 2014 16:09:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191438986"
Message-ID: <546628F7.4000008@citrix.com>
Date: Fri, 14 Nov 2014 16:08:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xensource.com>,
	<jbeulich@suse.com>, <konrad.wilk@oracle.com>, <david.vrabel@citrix.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>	<5465FB34.9010606@suse.com>	<54660A16.2090006@citrix.com>	<54660E5C.8030107@suse.com>	<546618D9.5070200@citrix.com>
	<54662096.6060603@suse.com>
In-Reply-To: <54662096.6060603@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 15:32, Juergen Gross wrote:
> On 11/14/2014 03:59 PM, Andrew Cooper wrote:
>> On 14/11/14 14:14, J=FCrgen Gro=DF wrote:
>>> On 11/14/2014 02:56 PM, Andrew Cooper wrote:
>>>> On 14/11/14 12:53, Juergen Gross wrote:
>>>>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>>>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>>>>> currently contains the mfn of the top level page frame of the 3
>>>>>>> level
>>>>>>> p2m tree, which is used by the Xen tools during saving and
>>>>>>> restoring
>>>>>>> (and live migration) of pv domains and for crash dump analysis.
>>>>>>> With
>>>>>>> three levels of the p2m tree it is possible to support up to 512
>>>>>>> GB of
>>>>>>> RAM for a 64 bit pv domain.
>>>>>>>
>>>>>>> A 32 bit pv domain can support more, as each memory page can hold
>>>>>>> 1024
>>>>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>>>>
>>>>>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>>>>>> p2m list.
>>>>>>>
>>>>>>> This patch expands struct arch_shared_info with a new p2m list
>>>>>>> virtual
>>>>>>> address and the mfn of the page table root. The new information is
>>>>>>> indicated by the domain to be valid by storing ~0UL into
>>>>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of
>>>>>>> this
>>>>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>>>>
>>>>>> How do you envisage this being used?  Are you expecting the tools
>>>>>> to do
>>>>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>>>>
>>>>> Yes. Not very different compared to today's mapping via the 3 level
>>>>> p2m tree. Just another entry format, 4 instead of 3 levels and
>>>>> starting
>>>>> at an offset.
>>>>
>>>> Yes - David and I were discussing this over lunch, and it is not
>>>> actually very different.
>>>>
>>>> In reality, how likely is it that the pages backing this virtual
>>>> linear
>>>> array change?
>>>
>>> Very unlikely, I think. But not impossible.
>>>
>>>> One issue currently is that, during the live part of migration, the
>>>> toolstack has no way of working out whether the structure of the
>>>> p2m has
>>>> changed (intermediate leaves rearranged, or the length increasing).
>>>>
>>>> In the case that the VM does change the structure of the p2m under the
>>>> feet of the toolstack, migration will either blow up in a
>>>> non-subtle way
>>>> with a p2m/m2p mismatch, or in a subtle way with the receiving side
>>>> copying the new p2m over the wrong part of the new domain.
>>>>
>>>> I am wondering whether, with this new p2m method, we can take
>>>> sufficient
>>>> steps to be able to guarantee mishaps like this can't occur.
>>>
>>> This should be easy: I could add a counter in arch_shared_info which is
>>> incremented whenever a p2m mapping is being changed. The toolstack
>>> could
>>> compare the counter values before start and at end of migration and
>>> redo
>>> the migration (or fail) if they are different. In order to avoid races
>>> I would have to increment the counter before and after changing the
>>> mapping.
>>>
>>
>> That is insufficient I believe.
>>
>> Consider:
>>
>> * Toolstack walks pagetables and maps the frames containing the
>> linear p2m
>> * Live migration starts
>> * VM remaps a frame in the middle of the linear p2m
>> * Live migration continues, but the toolstack has a stale frame in the
>> middle of its view of the p2m.
>
> This would be covered by my suggestion. At the end of the memory
> transfer (with some bogus contents) the toolstack would discover the
> change of the p2m structure and either fail the migration or start it
> from the beginning and thus overwriting the bogus frames.

Checking after pause is too late.  The content of the p2m is used verify
each frame being sent on the wire, so is in active use for the entire
duration of live migration.

If the toolstack starts verifying frames being sent using information
from a stale p2m, the best that can be hoped for is that the toolstack
declares that the p2m and m2p are inconsistent and abort the migrate.

>
>> As the p2m is almost never expected to change, I think it might be
>> better to have a flag the toolstack can set to say "The toolstack is
>> peeking at your p2m behind your back - you must not change its
>> structure."
>
> Be careful here: changes of the structure can be due to two scenarios:
> - ballooning (invalid entries being populated): this is no problem, as
>   we can stop the ballooning during live migration.
> - mapping of grant pages e.g. in a stub domain (first map in an area
>   former marked as invalid): you can't stop this, as the stub domain
>   has to do some work. Here a restart of the migration should work, as
>   the p2m structure change can only happen once for each affected p2m
>   page.

Migration is not at all possible with a domain referencing foreign frames.

The live part can cope with foreign frames referenced in the ptes.  As
part of the pause handling in the VM, the frontends must unmap any
grants they have.  After pause, any remaining foreign frames cause a
migration failure.

>
>> Having just thought this through, I think there is also a race condition
>> between a VM changing an entry in the p2m, and the toolstack doing
>> verifications of frames being sent.
>
> Okay, so the flag you mentioned should just prohibit changes in the
> p2m list related to memory frames of the affected domain: ballooning
> up or down, or rearranging the memory layout (does this happen today?).
> Mapping and unmapping of grant pages should be still allowed.

HVM guests doesn't have any of their p2m updates represented in the
logdirty bitmap, so ballooning an HVM guest during migrate leads to
unexpected holes or lack of holes on the resuming side, leading to a
very confused balloon driver.

At the time I had not found a problem with PV guests, but it is now
clear that there is a period of time when a guest is altering its p2m
where the p2m and m2p are out of sync, which will cause a migration
failure if the toolstack observes this artefact.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:10:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJRd-0000JU-7t; Fri, 14 Nov 2014 16:09:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XpJRc-0000JP-9s
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 16:09:56 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	25/F0-03145-35926645; Fri, 14 Nov 2014 16:09:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1415981393!12649767!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16545 invoked from network); 14 Nov 2014 16:09:54 -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;
	14 Nov 2014 16:09:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191438986"
Message-ID: <546628F7.4000008@citrix.com>
Date: Fri, 14 Nov 2014 16:08:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xensource.com>,
	<jbeulich@suse.com>, <konrad.wilk@oracle.com>, <david.vrabel@citrix.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>	<5465FB34.9010606@suse.com>	<54660A16.2090006@citrix.com>	<54660E5C.8030107@suse.com>	<546618D9.5070200@citrix.com>
	<54662096.6060603@suse.com>
In-Reply-To: <54662096.6060603@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/11/14 15:32, Juergen Gross wrote:
> On 11/14/2014 03:59 PM, Andrew Cooper wrote:
>> On 14/11/14 14:14, J=FCrgen Gro=DF wrote:
>>> On 11/14/2014 02:56 PM, Andrew Cooper wrote:
>>>> On 14/11/14 12:53, Juergen Gross wrote:
>>>>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>>>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>>>>> currently contains the mfn of the top level page frame of the 3
>>>>>>> level
>>>>>>> p2m tree, which is used by the Xen tools during saving and
>>>>>>> restoring
>>>>>>> (and live migration) of pv domains and for crash dump analysis.
>>>>>>> With
>>>>>>> three levels of the p2m tree it is possible to support up to 512
>>>>>>> GB of
>>>>>>> RAM for a 64 bit pv domain.
>>>>>>>
>>>>>>> A 32 bit pv domain can support more, as each memory page can hold
>>>>>>> 1024
>>>>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>>>>
>>>>>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>>>>>> p2m list.
>>>>>>>
>>>>>>> This patch expands struct arch_shared_info with a new p2m list
>>>>>>> virtual
>>>>>>> address and the mfn of the page table root. The new information is
>>>>>>> indicated by the domain to be valid by storing ~0UL into
>>>>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of
>>>>>>> this
>>>>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>>>>
>>>>>> How do you envisage this being used?  Are you expecting the tools
>>>>>> to do
>>>>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>>>>
>>>>> Yes. Not very different compared to today's mapping via the 3 level
>>>>> p2m tree. Just another entry format, 4 instead of 3 levels and
>>>>> starting
>>>>> at an offset.
>>>>
>>>> Yes - David and I were discussing this over lunch, and it is not
>>>> actually very different.
>>>>
>>>> In reality, how likely is it that the pages backing this virtual
>>>> linear
>>>> array change?
>>>
>>> Very unlikely, I think. But not impossible.
>>>
>>>> One issue currently is that, during the live part of migration, the
>>>> toolstack has no way of working out whether the structure of the
>>>> p2m has
>>>> changed (intermediate leaves rearranged, or the length increasing).
>>>>
>>>> In the case that the VM does change the structure of the p2m under the
>>>> feet of the toolstack, migration will either blow up in a
>>>> non-subtle way
>>>> with a p2m/m2p mismatch, or in a subtle way with the receiving side
>>>> copying the new p2m over the wrong part of the new domain.
>>>>
>>>> I am wondering whether, with this new p2m method, we can take
>>>> sufficient
>>>> steps to be able to guarantee mishaps like this can't occur.
>>>
>>> This should be easy: I could add a counter in arch_shared_info which is
>>> incremented whenever a p2m mapping is being changed. The toolstack
>>> could
>>> compare the counter values before start and at end of migration and
>>> redo
>>> the migration (or fail) if they are different. In order to avoid races
>>> I would have to increment the counter before and after changing the
>>> mapping.
>>>
>>
>> That is insufficient I believe.
>>
>> Consider:
>>
>> * Toolstack walks pagetables and maps the frames containing the
>> linear p2m
>> * Live migration starts
>> * VM remaps a frame in the middle of the linear p2m
>> * Live migration continues, but the toolstack has a stale frame in the
>> middle of its view of the p2m.
>
> This would be covered by my suggestion. At the end of the memory
> transfer (with some bogus contents) the toolstack would discover the
> change of the p2m structure and either fail the migration or start it
> from the beginning and thus overwriting the bogus frames.

Checking after pause is too late.  The content of the p2m is used verify
each frame being sent on the wire, so is in active use for the entire
duration of live migration.

If the toolstack starts verifying frames being sent using information
from a stale p2m, the best that can be hoped for is that the toolstack
declares that the p2m and m2p are inconsistent and abort the migrate.

>
>> As the p2m is almost never expected to change, I think it might be
>> better to have a flag the toolstack can set to say "The toolstack is
>> peeking at your p2m behind your back - you must not change its
>> structure."
>
> Be careful here: changes of the structure can be due to two scenarios:
> - ballooning (invalid entries being populated): this is no problem, as
>   we can stop the ballooning during live migration.
> - mapping of grant pages e.g. in a stub domain (first map in an area
>   former marked as invalid): you can't stop this, as the stub domain
>   has to do some work. Here a restart of the migration should work, as
>   the p2m structure change can only happen once for each affected p2m
>   page.

Migration is not at all possible with a domain referencing foreign frames.

The live part can cope with foreign frames referenced in the ptes.  As
part of the pause handling in the VM, the frontends must unmap any
grants they have.  After pause, any remaining foreign frames cause a
migration failure.

>
>> Having just thought this through, I think there is also a race condition
>> between a VM changing an entry in the p2m, and the toolstack doing
>> verifications of frames being sent.
>
> Okay, so the flag you mentioned should just prohibit changes in the
> p2m list related to memory frames of the affected domain: ballooning
> up or down, or rearranging the memory layout (does this happen today?).
> Mapping and unmapping of grant pages should be still allowed.

HVM guests doesn't have any of their p2m updates represented in the
logdirty bitmap, so ballooning an HVM guest during migrate leads to
unexpected holes or lack of holes on the resuming side, leading to a
very confused balloon driver.

At the time I had not found a problem with PV guests, but it is now
clear that there is a period of time when a guest is altering its p2m
where the p2m and m2p are out of sync, which will cause a migration
failure if the toolstack observes this artefact.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:15:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:15:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJXB-0000ja-20; Fri, 14 Nov 2014 16:15:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpJX9-0000jV-7w
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:15:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/C5-24532-AAA26645; Fri, 14 Nov 2014 16:15:38 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415981734!12853787!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20309 invoked from network); 14 Nov 2014 16:15:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:15:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192907178"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:15:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpJX0-0003VY-At;
	Fri, 14 Nov 2014 16:15:30 +0000
Date: Fri, 14 Nov 2014 16:15:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> Hi,
> >> >>
> >> >> I observe system freeze on latest xen/master branch.
> >> >>
> >> >> My setup is:
> >> >>
> >> >> - Jacinto 6 evm board (OMAP5)
> >> >> - Latest Xen 4.5.0-rc2 as hypervisor
> >> >> - Linux 3.8 as dom0, running on 2 vcpus
> >> >> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
> >> >> - XSM feature is disabled
> >> >> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
> >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
> >> >> compiler
> >> >>
> >> >> Freeze occurs in random moment of time during creation of domU domain.
> >> >> Even Xen console may be not available after freeze.
> >> >> Can someone suggest - what it can be? Maybe some weak places in new
> >> >> code? Maybe new gic, which was reworked a lot or something else?
> >> >>
> >> >> Thank you in advance for any suggestions.
> >> >
> >> > Is this really 3.8 or 3.18?
> >>
> >> We have 3.8 in both dom0 and domU
> >>
> >> > 3.8 is pretty old and doesn't have any of
> >> > the fixes to be able to safely do dma involving guest pages to
> >> > non-coherent devices.
> >>
> >> This is a good point. Now we are migrating to 3.12 kernel in dom0. But
> >> Android will remain on 3.8. Will it help ?
> >> Maybe you can point me to any tree with proper DMA fixes? Note: if you
> >> are talking about SWIOTLB - we have your latest one, retrieved from
> >> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
> >> branch:swiotlb-xen-9.1
> >
> > The last and most stable series is:
> >
> > http://marc.info/?l=linux-kernel&m=141579241729749&w=2
> >
> 
> Thanks  - I'll try this series anyway.
> 
> > But thinking more about this, I doubt that it is a dma problem, because
> > you would most probably see various kind of error messages, not a
> > freeze.
> >
> 
> Agree.
> 
> >
> >> > Where are you storing the guest disk images?
> >>
> >> SATA drive, dedicated to dom0, its controller has its own DMA
> >
> > Are they on file or on lvm volumes?
> 
> Images are on file.
> 
> Also note - freeze depends on system load. It reproduces more
> frequently if I start Android + QNX + all frontends/backends drivers.
> Starting Android only without any addition drivers works more less
> stable. It looks like issue is reproduced when domU starts in parallel
> with backends drivers in dom0.
> But the same works fine with old Xen 4.4.

In my experience freezes like the one you are describing are due to
interrupt related bugs or deadlocks. Both of them are hard to track
down. If you can reproduce it reliably maybe you could bisect it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:15:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:15:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJXB-0000ja-20; Fri, 14 Nov 2014 16:15:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpJX9-0000jV-7w
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:15:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/C5-24532-AAA26645; Fri, 14 Nov 2014 16:15:38 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415981734!12853787!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20309 invoked from network); 14 Nov 2014 16:15:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:15:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192907178"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:15:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpJX0-0003VY-At;
	Fri, 14 Nov 2014 16:15:30 +0000
Date: Fri, 14 Nov 2014 16:15:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> Hi,
> >> >>
> >> >> I observe system freeze on latest xen/master branch.
> >> >>
> >> >> My setup is:
> >> >>
> >> >> - Jacinto 6 evm board (OMAP5)
> >> >> - Latest Xen 4.5.0-rc2 as hypervisor
> >> >> - Linux 3.8 as dom0, running on 2 vcpus
> >> >> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
> >> >> - XSM feature is disabled
> >> >> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
> >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
> >> >> compiler
> >> >>
> >> >> Freeze occurs in random moment of time during creation of domU domain.
> >> >> Even Xen console may be not available after freeze.
> >> >> Can someone suggest - what it can be? Maybe some weak places in new
> >> >> code? Maybe new gic, which was reworked a lot or something else?
> >> >>
> >> >> Thank you in advance for any suggestions.
> >> >
> >> > Is this really 3.8 or 3.18?
> >>
> >> We have 3.8 in both dom0 and domU
> >>
> >> > 3.8 is pretty old and doesn't have any of
> >> > the fixes to be able to safely do dma involving guest pages to
> >> > non-coherent devices.
> >>
> >> This is a good point. Now we are migrating to 3.12 kernel in dom0. But
> >> Android will remain on 3.8. Will it help ?
> >> Maybe you can point me to any tree with proper DMA fixes? Note: if you
> >> are talking about SWIOTLB - we have your latest one, retrieved from
> >> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
> >> branch:swiotlb-xen-9.1
> >
> > The last and most stable series is:
> >
> > http://marc.info/?l=linux-kernel&m=141579241729749&w=2
> >
> 
> Thanks  - I'll try this series anyway.
> 
> > But thinking more about this, I doubt that it is a dma problem, because
> > you would most probably see various kind of error messages, not a
> > freeze.
> >
> 
> Agree.
> 
> >
> >> > Where are you storing the guest disk images?
> >>
> >> SATA drive, dedicated to dom0, its controller has its own DMA
> >
> > Are they on file or on lvm volumes?
> 
> Images are on file.
> 
> Also note - freeze depends on system load. It reproduces more
> frequently if I start Android + QNX + all frontends/backends drivers.
> Starting Android only without any addition drivers works more less
> stable. It looks like issue is reproduced when domU starts in parallel
> with backends drivers in dom0.
> But the same works fine with old Xen 4.4.

In my experience freezes like the one you are describing are due to
interrupt related bugs or deadlocks. Both of them are hard to track
down. If you can reproduce it reliably maybe you could bisect it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:16:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJXi-0000mG-Gg; Fri, 14 Nov 2014 16:16:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpJXg-0000m5-In
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:16:12 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	15/B0-01660-BCA26645; Fri, 14 Nov 2014 16:16:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415981769!11455847!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23211 invoked from network); 14 Nov 2014 16:16:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:16:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGG7R0029062
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:16:08 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEGG6Rc025603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:16:07 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG6qs010126; Fri, 14 Nov 2014 16:16:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:16:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5C9F3116568; Fri, 14 Nov 2014 10:32:08 -0500 (EST)
Date: Fri, 14 Nov 2014 10:32:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141114153208.GD5364@laptop.dumpdata.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5466059A0200007800047A4B@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: roy.franz@linaro.org, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 12:37:30PM +0000, Jan Beulich wrote:
> The specification is kind of vague under what conditions
> ExitBootServices() may legitimately fail, requiring the OS loader to
> retry:
> 
> "If MapKey value is incorrect, ExitBootServices() returns
>  EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
>  be called again. Firmware implementation may choose to do a partial
>  shutdown of the boot services during the first call to
>  ExitBootServices(). EFI OS loader should not make calls to any boot
>  service function other then GetMemoryMap() after the first call to
>  ExitBootServices()."
> 
> While our code guarantees the map key to be valid, there are systems
> where a firmware internal notification sent while processing
> ExitBootServices() reportedly results in changes to the memory map.

s/reportedly/in fact/
> In that case, make a best effort second try: Avoid any boot service
> calls other than the two named above, with the possible exception of
> error paths. Those aren't a problem, since if we end up needing to
> retry, we're hosed when something goes wrong as much as if we didn't
> make the retry attempt.
> 
> For x86, a minimal adjustment to efi_arch_process_memory_map() is
> needed for it to cope with potentially being called a second time.

Wow. Talk about timing. We saw this and were going to see
doing something similar.


> 
> For arm64, while efi_process_memory_map_bootinfo() is easy to verify
> that it can safely be called more than once without violating spec
> constraints, it's not so obvious for fdt_add_uefi_nodes(), hence a
> step by step approach:
> - deletion of memory nodes and memory reserve map entries: the 2nd pass
>   shouldn't find any as the 1st one deleted them all,
> - a "chosen" node should be found as it got added in the 1st pass,
> - the various "linux,uefi-*" nodes all got added during the 1st pass
>   and hence only their contents may get updated.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -140,7 +140,7 @@ static void __init efi_arch_process_memo
>  
>      /* Populate E820 table and check trampoline area availability. */
>      e = e820map - 1;
> -    for ( i = 0; i < map_size; i += desc_size )
> +    for ( e820nr = i = 0; i < map_size; i += desc_size )
>      {
>          EFI_MEMORY_DESCRIPTOR *desc = map + i;
>          u64 len = desc->NumberOfPages << EFI_PAGE_SHIFT;
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -703,7 +703,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>      EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
>      EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
>      union string section = { NULL }, name;
> -    bool_t base_video = 0;
> +    bool_t base_video = 0, retry;
>      char *option_str;
>      bool_t use_cfg_file;
>  
> @@ -1051,17 +1051,23 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>      if ( !efi_memmap )
>          blexit(L"Unable to allocate memory for EFI memory map");
>  
> -    status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
> -                                  &efi_mdesc_size, &mdesc_ver);
> -    if ( EFI_ERROR(status) )
> -        PrintErrMesg(L"Cannot obtain memory map", status);
> +    for ( retry = 0; ; retry = 1 )
> +    {
> +        status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
> +                                      &efi_mdesc_size, &mdesc_ver);
> +        if ( EFI_ERROR(status) )
> +            PrintErrMesg(L"Cannot obtain memory map", status);
>  
> -    efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
> -                                efi_mdesc_size, mdesc_ver);
> +        efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
> +                                    efi_mdesc_size, mdesc_ver);
>  
> -    efi_arch_pre_exit_boot();
> +        efi_arch_pre_exit_boot();
> +
> +        status = efi_bs->ExitBootServices(ImageHandle, map_key);
> +        if ( status != EFI_INVALID_PARAMETER || retry )
> +            break;
> +    }

Any reason for just doing the loop at max twice? Could we iterate
more than those (say forever?) with an printk at suitable intervals
to notify the user?

>  
> -    status = efi_bs->ExitBootServices(ImageHandle, map_key);
>      if ( EFI_ERROR(status) )
>          PrintErrMesg(L"Cannot exit boot services", status);
>  
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:16:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJXi-0000mG-Gg; Fri, 14 Nov 2014 16:16:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpJXg-0000m5-In
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:16:12 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	15/B0-01660-BCA26645; Fri, 14 Nov 2014 16:16:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1415981769!11455847!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23211 invoked from network); 14 Nov 2014 16:16:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:16:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGG7R0029062
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:16:08 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEGG6Rc025603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:16:07 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG6qs010126; Fri, 14 Nov 2014 16:16:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:16:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5C9F3116568; Fri, 14 Nov 2014 10:32:08 -0500 (EST)
Date: Fri, 14 Nov 2014 10:32:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141114153208.GD5364@laptop.dumpdata.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5466059A0200007800047A4B@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: roy.franz@linaro.org, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 12:37:30PM +0000, Jan Beulich wrote:
> The specification is kind of vague under what conditions
> ExitBootServices() may legitimately fail, requiring the OS loader to
> retry:
> 
> "If MapKey value is incorrect, ExitBootServices() returns
>  EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
>  be called again. Firmware implementation may choose to do a partial
>  shutdown of the boot services during the first call to
>  ExitBootServices(). EFI OS loader should not make calls to any boot
>  service function other then GetMemoryMap() after the first call to
>  ExitBootServices()."
> 
> While our code guarantees the map key to be valid, there are systems
> where a firmware internal notification sent while processing
> ExitBootServices() reportedly results in changes to the memory map.

s/reportedly/in fact/
> In that case, make a best effort second try: Avoid any boot service
> calls other than the two named above, with the possible exception of
> error paths. Those aren't a problem, since if we end up needing to
> retry, we're hosed when something goes wrong as much as if we didn't
> make the retry attempt.
> 
> For x86, a minimal adjustment to efi_arch_process_memory_map() is
> needed for it to cope with potentially being called a second time.

Wow. Talk about timing. We saw this and were going to see
doing something similar.


> 
> For arm64, while efi_process_memory_map_bootinfo() is easy to verify
> that it can safely be called more than once without violating spec
> constraints, it's not so obvious for fdt_add_uefi_nodes(), hence a
> step by step approach:
> - deletion of memory nodes and memory reserve map entries: the 2nd pass
>   shouldn't find any as the 1st one deleted them all,
> - a "chosen" node should be found as it got added in the 1st pass,
> - the various "linux,uefi-*" nodes all got added during the 1st pass
>   and hence only their contents may get updated.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -140,7 +140,7 @@ static void __init efi_arch_process_memo
>  
>      /* Populate E820 table and check trampoline area availability. */
>      e = e820map - 1;
> -    for ( i = 0; i < map_size; i += desc_size )
> +    for ( e820nr = i = 0; i < map_size; i += desc_size )
>      {
>          EFI_MEMORY_DESCRIPTOR *desc = map + i;
>          u64 len = desc->NumberOfPages << EFI_PAGE_SHIFT;
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -703,7 +703,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>      EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
>      EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
>      union string section = { NULL }, name;
> -    bool_t base_video = 0;
> +    bool_t base_video = 0, retry;
>      char *option_str;
>      bool_t use_cfg_file;
>  
> @@ -1051,17 +1051,23 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>      if ( !efi_memmap )
>          blexit(L"Unable to allocate memory for EFI memory map");
>  
> -    status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
> -                                  &efi_mdesc_size, &mdesc_ver);
> -    if ( EFI_ERROR(status) )
> -        PrintErrMesg(L"Cannot obtain memory map", status);
> +    for ( retry = 0; ; retry = 1 )
> +    {
> +        status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
> +                                      &efi_mdesc_size, &mdesc_ver);
> +        if ( EFI_ERROR(status) )
> +            PrintErrMesg(L"Cannot obtain memory map", status);
>  
> -    efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
> -                                efi_mdesc_size, mdesc_ver);
> +        efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
> +                                    efi_mdesc_size, mdesc_ver);
>  
> -    efi_arch_pre_exit_boot();
> +        efi_arch_pre_exit_boot();
> +
> +        status = efi_bs->ExitBootServices(ImageHandle, map_key);
> +        if ( status != EFI_INVALID_PARAMETER || retry )
> +            break;
> +    }

Any reason for just doing the loop at max twice? Could we iterate
more than those (say forever?) with an printk at suitable intervals
to notify the user?

>  
> -    status = efi_bs->ExitBootServices(ImageHandle, map_key);
>      if ( EFI_ERROR(status) )
>          PrintErrMesg(L"Cannot exit boot services", status);
>  
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:16:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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 1XpJXk-0000nK-5M; Fri, 14 Nov 2014 16:16:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpJXi-0000mE-LL
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:16:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E5/A6-24532-ECA26645; Fri, 14 Nov 2014 16:16:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415981772!4812542!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15612 invoked from network); 14 Nov 2014 16:16:13 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:16:13 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGG7di010892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:16:08 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG6BM028892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:16:07 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG6QT010115; Fri, 14 Nov 2014 16:16:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:16:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 582FA116535; Fri, 14 Nov 2014 10:18:33 -0500 (EST)
Date: Fri, 14 Nov 2014 10:18:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141114151833.GB5364@laptop.dumpdata.com>
References: <5465E0E10200007800047902@mail.emea.novell.com>
	<5465E15E.4010109@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5465E15E.4010109@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] kexec-ed kernel possibly needing low 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 Fri, Nov 14, 2014 at 11:02:54AM +0000, David Vrabel wrote:
> On 14/11/14 10:00, Jan Beulich wrote:
> > David,
> > 
> > we're being approached with the situation where a disk driver in the
> > kexec-ed kernel needs memory below 4G in order to perform DMA
> > (e.g. for the swiotlb to be set up). Linux not so long ago invented a
> > two area approach, which doesn't fit with the current single
> > KEXEC_RANGE_MA_CRASH area obtainable via
> > KEXEC_CMD_kexec_get_range.
> > 
> > I see multiple options
> > - do no change at all; the user can deal with this by explicitly
> >   specifying an area below 4G via "crashkernel="
> 
> This is what we do.
> 
> > - add KEXEC_RANGE_MA_CRASH_LOW
> 
> If you choose this option, it would be preferable to support N (which
> might be 2) arbitrary crash regions rather than specifying that one
> region is always low memory.  I would suggest combining this with a way
> to specify the bounds of each region.
> 
> e.g., crashkernel=32M@<4G,128M

We could also implement the 'autoplacement' feature that Red Hat has put
in their kexec implementation (not sure if it was upstreamed).

That would nicely deal with this by always putting it under 4GB.
> 
> I wouldn't go this route unless you actually need a large crash region
> that would use up too much low memory otherwise.
> 
> > - when not asked for a specific address, always allocate the (single)
> >   area below 4G if there is enough space
> 
> I don't think the default location should change.  A user might have
> specified  a large crash region that might use up most of low memory.
> 
> > - provide a means to request allocating the (single) area below 4G
> >   (or perhaps more generically below a certain boundary) without
> >   requiring an exact address to be specified
> 
> This sounds ok.
> 
> > Do you have any preference here, or do you see other viable
> > alternatives?
> 
> My preference would be option 1 since it already works, then option 4.
> 
> David
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:16:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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 1XpJXk-0000nK-5M; Fri, 14 Nov 2014 16:16:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpJXi-0000mE-LL
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:16:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E5/A6-24532-ECA26645; Fri, 14 Nov 2014 16:16:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1415981772!4812542!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15612 invoked from network); 14 Nov 2014 16:16:13 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:16:13 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGG7di010892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:16:08 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG6BM028892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:16:07 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG6QT010115; Fri, 14 Nov 2014 16:16:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:16:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 582FA116535; Fri, 14 Nov 2014 10:18:33 -0500 (EST)
Date: Fri, 14 Nov 2014 10:18:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141114151833.GB5364@laptop.dumpdata.com>
References: <5465E0E10200007800047902@mail.emea.novell.com>
	<5465E15E.4010109@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5465E15E.4010109@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] kexec-ed kernel possibly needing low 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 Fri, Nov 14, 2014 at 11:02:54AM +0000, David Vrabel wrote:
> On 14/11/14 10:00, Jan Beulich wrote:
> > David,
> > 
> > we're being approached with the situation where a disk driver in the
> > kexec-ed kernel needs memory below 4G in order to perform DMA
> > (e.g. for the swiotlb to be set up). Linux not so long ago invented a
> > two area approach, which doesn't fit with the current single
> > KEXEC_RANGE_MA_CRASH area obtainable via
> > KEXEC_CMD_kexec_get_range.
> > 
> > I see multiple options
> > - do no change at all; the user can deal with this by explicitly
> >   specifying an area below 4G via "crashkernel="
> 
> This is what we do.
> 
> > - add KEXEC_RANGE_MA_CRASH_LOW
> 
> If you choose this option, it would be preferable to support N (which
> might be 2) arbitrary crash regions rather than specifying that one
> region is always low memory.  I would suggest combining this with a way
> to specify the bounds of each region.
> 
> e.g., crashkernel=32M@<4G,128M

We could also implement the 'autoplacement' feature that Red Hat has put
in their kexec implementation (not sure if it was upstreamed).

That would nicely deal with this by always putting it under 4GB.
> 
> I wouldn't go this route unless you actually need a large crash region
> that would use up too much low memory otherwise.
> 
> > - when not asked for a specific address, always allocate the (single)
> >   area below 4G if there is enough space
> 
> I don't think the default location should change.  A user might have
> specified  a large crash region that might use up most of low memory.
> 
> > - provide a means to request allocating the (single) area below 4G
> >   (or perhaps more generically below a certain boundary) without
> >   requiring an exact address to be specified
> 
> This sounds ok.
> 
> > Do you have any preference here, or do you see other viable
> > alternatives?
> 
> My preference would be option 1 since it already works, then option 4.
> 
> David
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:16:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:16:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJXs-0000qL-KQ; Fri, 14 Nov 2014 16:16:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpJXr-0000pk-Bj
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:16:23 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	D7/2A-28296-6DA26645; Fri, 14 Nov 2014 16:16:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415981780!11428516!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20004 invoked from network); 14 Nov 2014 16:16:21 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:16:21 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGG85Z010897
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:16:08 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG7uu029034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:16:07 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG6KH028875; Fri, 14 Nov 2014 16:16:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:16:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BCC8911660B; Fri, 14 Nov 2014 11:11:46 -0500 (EST)
Date: Fri, 14 Nov 2014 11:11:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, linux@eikelenboom.it
Message-ID: <20141114161146.GG5364@laptop.dumpdata.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
	<1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
	<54662A360200007800047BDB@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54662A360200007800047BDB@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet
	with an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 03:13:42PM +0000, Jan Beulich wrote:
> >>> On 12.11.14 at 03:23, <konrad.wilk@oracle.com> wrote:
> > +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> > +{
> > +    struct domain *d = pirq_dpci->dom;
> > +
> > +    ASSERT(spin_is_locked(&d->event_lock));
> > +
> > +    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
> > +    {
> > +    case (1 << STATE_SCHED):
> > +        /*
> > +         * We are going to try to de-schedule the softirq before it goes in
> > +         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
> > +         */
> > +        put_domain(d);
> > +        /* fallthrough. */
> 
> Considering Sander's report, the only suspicious place I find is this
> one: When the STATE_SCHED flag is set, pirq_dpci is on some
> CPU's list. What guarantees it to get removed from that list before
> getting inserted on another one?

None. The moment that STATE_SCHED is cleared, 'raise_softirq_for'
is free to manipulate the list.

We could:
 - Add another bit, say STATE_ZOMBIE - which pt_pirq_softirq_reset could
   set, and dpci_softirq - if it sees it - would clear. Said bit
   would stop 'raise_softirq_for' from trying to do anything.

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..8e9141e 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -50,20 +50,25 @@ static DEFINE_PER_CPU(struct list_head, dpci_list);
 
 enum {
     STATE_SCHED,
-    STATE_RUN
+    STATE_RUN,
+    STATE_ZOMBIE
 };
 
 /*
  * This can be called multiple times, but the softirq is only raised once.
- * That is until the STATE_SCHED state has been cleared. The state can be
- * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
- * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
- * the softirq had a chance to run).
+ * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
+ * STATE_SCHED and STATE_ZOMBIE state can be cleared by the 'dpci_softirq'
+ * (when it has executed 'hvm_dirq_assist'). The STATE_SCHED can be cleared
+ * by 'pt_pirq_softirq_reset' (which will try to clear the state before the
+ * softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
 
+    if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+        return;
+
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
@@ -85,7 +90,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
  */
 bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 {
-    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
         return 1;
 
     /*
@@ -109,7 +114,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
 
     ASSERT(spin_is_locked(&d->event_lock));
 
-    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
         /*
@@ -120,6 +125,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
         /* fallthrough. */
     case (1 << STATE_RUN):
     case (1 << STATE_RUN) | (1 << STATE_SCHED):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
         /*
          * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
@@ -779,6 +785,7 @@ unlock:
 static void dpci_softirq(void)
 {
     unsigned int cpu = smp_processor_id();
+    unsigned int reset = 0;
     LIST_HEAD(our_list);
 
     local_irq_disable();
@@ -805,7 +812,15 @@ static void dpci_softirq(void)
             hvm_dirq_assist(d, pirq_dpci);
             put_domain(d);
         }
+        else
+            reset = 1;
+
         clear_bit(STATE_RUN, &pirq_dpci->state);
+        if ( reset )
+        {
+            clear_bit(STATE_ZOMBIE, &pirq_dpci->state);
+            reset = 0;
+        }
     }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:16:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:16:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJXs-0000qL-KQ; Fri, 14 Nov 2014 16:16:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpJXr-0000pk-Bj
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:16:23 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	D7/2A-28296-6DA26645; Fri, 14 Nov 2014 16:16:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1415981780!11428516!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20004 invoked from network); 14 Nov 2014 16:16:21 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:16:21 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGG85Z010897
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:16:08 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG7uu029034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:16:07 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG6KH028875; Fri, 14 Nov 2014 16:16:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:16:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BCC8911660B; Fri, 14 Nov 2014 11:11:46 -0500 (EST)
Date: Fri, 14 Nov 2014 11:11:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, linux@eikelenboom.it
Message-ID: <20141114161146.GG5364@laptop.dumpdata.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
	<1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
	<54662A360200007800047BDB@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54662A360200007800047BDB@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet
	with an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 03:13:42PM +0000, Jan Beulich wrote:
> >>> On 12.11.14 at 03:23, <konrad.wilk@oracle.com> wrote:
> > +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> > +{
> > +    struct domain *d = pirq_dpci->dom;
> > +
> > +    ASSERT(spin_is_locked(&d->event_lock));
> > +
> > +    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
> > +    {
> > +    case (1 << STATE_SCHED):
> > +        /*
> > +         * We are going to try to de-schedule the softirq before it goes in
> > +         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
> > +         */
> > +        put_domain(d);
> > +        /* fallthrough. */
> 
> Considering Sander's report, the only suspicious place I find is this
> one: When the STATE_SCHED flag is set, pirq_dpci is on some
> CPU's list. What guarantees it to get removed from that list before
> getting inserted on another one?

None. The moment that STATE_SCHED is cleared, 'raise_softirq_for'
is free to manipulate the list.

We could:
 - Add another bit, say STATE_ZOMBIE - which pt_pirq_softirq_reset could
   set, and dpci_softirq - if it sees it - would clear. Said bit
   would stop 'raise_softirq_for' from trying to do anything.

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..8e9141e 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -50,20 +50,25 @@ static DEFINE_PER_CPU(struct list_head, dpci_list);
 
 enum {
     STATE_SCHED,
-    STATE_RUN
+    STATE_RUN,
+    STATE_ZOMBIE
 };
 
 /*
  * This can be called multiple times, but the softirq is only raised once.
- * That is until the STATE_SCHED state has been cleared. The state can be
- * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
- * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
- * the softirq had a chance to run).
+ * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
+ * STATE_SCHED and STATE_ZOMBIE state can be cleared by the 'dpci_softirq'
+ * (when it has executed 'hvm_dirq_assist'). The STATE_SCHED can be cleared
+ * by 'pt_pirq_softirq_reset' (which will try to clear the state before the
+ * softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
 
+    if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+        return;
+
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
@@ -85,7 +90,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
  */
 bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 {
-    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
         return 1;
 
     /*
@@ -109,7 +114,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
 
     ASSERT(spin_is_locked(&d->event_lock));
 
-    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
         /*
@@ -120,6 +125,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
         /* fallthrough. */
     case (1 << STATE_RUN):
     case (1 << STATE_RUN) | (1 << STATE_SCHED):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
         /*
          * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
@@ -779,6 +785,7 @@ unlock:
 static void dpci_softirq(void)
 {
     unsigned int cpu = smp_processor_id();
+    unsigned int reset = 0;
     LIST_HEAD(our_list);
 
     local_irq_disable();
@@ -805,7 +812,15 @@ static void dpci_softirq(void)
             hvm_dirq_assist(d, pirq_dpci);
             put_domain(d);
         }
+        else
+            reset = 1;
+
         clear_bit(STATE_RUN, &pirq_dpci->state);
+        if ( reset )
+        {
+            clear_bit(STATE_ZOMBIE, &pirq_dpci->state);
+            reset = 0;
+        }
     }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:16:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:16:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJXt-0000qn-4V; Fri, 14 Nov 2014 16:16:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpJXr-0000pt-NA
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 16:16:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BA/EB-09842-7DA26645; Fri, 14 Nov 2014 16:16:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415981781!5544376!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32193 invoked from network); 14 Nov 2014 16:16:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:16:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGG9J0010943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:16:10 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG7Ga015017
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:16:08 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG6M1028881; Fri, 14 Nov 2014 16:16:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:16:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 355A71165D0; Fri, 14 Nov 2014 10:50:39 -0500 (EST)
Date: Fri, 14 Nov 2014 10:50:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141114155039.GF5364@laptop.dumpdata.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
	<alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, mst@redhat.com, liang.z.li@intel.com,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	aliguori@amazon.com, qemu-devel@nongun.org,
	Igor Mammedov <imammedo@redhat.com>, rth@twiddle.net
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
	running 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 Fri, Nov 14, 2014 at 01:57:21PM +0000, Stefano Stabellini wrote:
> Konrad,
> this is another bug fix for QEMU: pci hotplug doesn't work when
> xen_platform_pci=0 without this.

Yes.
> 
> I think we should have it in 4.5. What do you think?

Do you believe we should first get an Tested-by from the Intel QA folks?

Thanks.
> 
> - Stefano
> 
> On Thu, 13 Nov 2014, Paolo Bonzini wrote:
> > On 13/11/2014 03:30, Li Liang wrote:
> > > If user starts QEMU with "-machine pc,accel=xen", then
> > > compat property in xenfv won't work and it would cause error:
> > > "Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set"
> > > when PCI device is added with -device on QEMU CLI.
> > > 
> > > In case of Xen instead of using compat property, just use the fact
> > > that xen doesn't use QEMU's fw_cfg/acpi tables to switch piix4_pm
> > > into legacy PCI hotplug mode when Xen is enabled.
> > > 
> > > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > > [liang.z.li@intel.com: use "xen_enabled()" instead of "!fw_cfg"]
> > > Signed-off-by: Li Liang <liang.z.li@intel.com>
> > > ---
> > >  hw/acpi/piix4.c   |  4 ++++
> > >  hw/i386/pc_piix.c | 11 -----------
> > >  2 files changed, 4 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> > > index 78c0a6d..481a16c 100644
> > > --- a/hw/acpi/piix4.c
> > > +++ b/hw/acpi/piix4.c
> > > @@ -36,6 +36,7 @@
> > >  #include "hw/mem/pc-dimm.h"
> > >  #include "hw/acpi/memory_hotplug.h"
> > >  #include "hw/acpi/acpi_dev_interface.h"
> > > +#include "hw/xen/xen.h"
> > >  
> > >  //#define DEBUG
> > >  
> > > @@ -501,6 +502,9 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
> > >      s->irq = sci_irq;
> > >      s->smi_irq = smi_irq;
> > >      s->kvm_enabled = kvm_enabled;
> > > +    if (xen_enabled()) {
> > > +        s->use_acpi_pci_hotplug = false;
> > > +    }
> > >  
> > >      qdev_init_nofail(dev);
> > >  
> > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > > index b559181..7bb97a4 100644
> > > --- a/hw/i386/pc_piix.c
> > > +++ b/hw/i386/pc_piix.c
> > > @@ -916,17 +916,6 @@ static QEMUMachine xenfv_machine = {
> > >      .max_cpus = HVM_MAX_VCPUS,
> > >      .default_machine_opts = "accel=xen",
> > >      .hot_add_cpu = pc_hot_add_cpu,
> > > -    .compat_props = (GlobalProperty[]) {
> > > -        /* xenfv has no fwcfg and so does not load acpi from QEMU.
> > > -         * as such new acpi features don't work.
> > > -         */
> > > -        {
> > > -            .driver   = "PIIX4_PM",
> > > -            .property = "acpi-pci-hotplug-with-bridge-support",
> > > -            .value    = "off",
> > > -        },
> > > -        { /* end of list */ }
> > > -    },
> > >  };
> > >  #endif
> > >  
> > > 
> > 
> > Acked-by: Paolo Bonzini <pbonzini@redhat.com>
> > 
> > Stefano, are you going to send the pull request yourself?
> > 
> > Paolo
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:16:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:16:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJXt-0000qn-4V; Fri, 14 Nov 2014 16:16:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpJXr-0000pt-NA
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 16:16:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BA/EB-09842-7DA26645; Fri, 14 Nov 2014 16:16:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415981781!5544376!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32193 invoked from network); 14 Nov 2014 16:16:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:16:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGG9J0010943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:16:10 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG7Ga015017
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:16:08 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGG6M1028881; Fri, 14 Nov 2014 16:16:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:16:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 355A71165D0; Fri, 14 Nov 2014 10:50:39 -0500 (EST)
Date: Fri, 14 Nov 2014 10:50:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141114155039.GF5364@laptop.dumpdata.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
	<alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, mst@redhat.com, liang.z.li@intel.com,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	aliguori@amazon.com, qemu-devel@nongun.org,
	Igor Mammedov <imammedo@redhat.com>, rth@twiddle.net
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
	running 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 Fri, Nov 14, 2014 at 01:57:21PM +0000, Stefano Stabellini wrote:
> Konrad,
> this is another bug fix for QEMU: pci hotplug doesn't work when
> xen_platform_pci=0 without this.

Yes.
> 
> I think we should have it in 4.5. What do you think?

Do you believe we should first get an Tested-by from the Intel QA folks?

Thanks.
> 
> - Stefano
> 
> On Thu, 13 Nov 2014, Paolo Bonzini wrote:
> > On 13/11/2014 03:30, Li Liang wrote:
> > > If user starts QEMU with "-machine pc,accel=xen", then
> > > compat property in xenfv won't work and it would cause error:
> > > "Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set"
> > > when PCI device is added with -device on QEMU CLI.
> > > 
> > > In case of Xen instead of using compat property, just use the fact
> > > that xen doesn't use QEMU's fw_cfg/acpi tables to switch piix4_pm
> > > into legacy PCI hotplug mode when Xen is enabled.
> > > 
> > > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > > [liang.z.li@intel.com: use "xen_enabled()" instead of "!fw_cfg"]
> > > Signed-off-by: Li Liang <liang.z.li@intel.com>
> > > ---
> > >  hw/acpi/piix4.c   |  4 ++++
> > >  hw/i386/pc_piix.c | 11 -----------
> > >  2 files changed, 4 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> > > index 78c0a6d..481a16c 100644
> > > --- a/hw/acpi/piix4.c
> > > +++ b/hw/acpi/piix4.c
> > > @@ -36,6 +36,7 @@
> > >  #include "hw/mem/pc-dimm.h"
> > >  #include "hw/acpi/memory_hotplug.h"
> > >  #include "hw/acpi/acpi_dev_interface.h"
> > > +#include "hw/xen/xen.h"
> > >  
> > >  //#define DEBUG
> > >  
> > > @@ -501,6 +502,9 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
> > >      s->irq = sci_irq;
> > >      s->smi_irq = smi_irq;
> > >      s->kvm_enabled = kvm_enabled;
> > > +    if (xen_enabled()) {
> > > +        s->use_acpi_pci_hotplug = false;
> > > +    }
> > >  
> > >      qdev_init_nofail(dev);
> > >  
> > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > > index b559181..7bb97a4 100644
> > > --- a/hw/i386/pc_piix.c
> > > +++ b/hw/i386/pc_piix.c
> > > @@ -916,17 +916,6 @@ static QEMUMachine xenfv_machine = {
> > >      .max_cpus = HVM_MAX_VCPUS,
> > >      .default_machine_opts = "accel=xen",
> > >      .hot_add_cpu = pc_hot_add_cpu,
> > > -    .compat_props = (GlobalProperty[]) {
> > > -        /* xenfv has no fwcfg and so does not load acpi from QEMU.
> > > -         * as such new acpi features don't work.
> > > -         */
> > > -        {
> > > -            .driver   = "PIIX4_PM",
> > > -            .property = "acpi-pci-hotplug-with-bridge-support",
> > > -            .value    = "off",
> > > -        },
> > > -        { /* end of list */ }
> > > -    },
> > >  };
> > >  #endif
> > >  
> > > 
> > 
> > Acked-by: Paolo Bonzini <pbonzini@redhat.com>
> > 
> > Stefano, are you going to send the pull request yourself?
> > 
> > Paolo
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:19:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:19:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJam-0001Lb-VH; Fri, 14 Nov 2014 16:19:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJal-0001LF-94
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:19:23 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	BA/13-16982-A8B26645; Fri, 14 Nov 2014 16:19:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415981958!11523628!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30302 invoked from network); 14 Nov 2014 16:19:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:19:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192908642"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:19:16 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJad-0003eS-Dz;
	Fri, 14 Nov 2014 16:19:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJac-0001nE-T0;
	Fri, 14 Nov 2014 16:19:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.11138.483109.931473@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 16:19:14 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("[PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> When a device is hot-unplugged libxl sends QEMU a "device-del" message
> (via QMP). This call returns after QEMU has initiated device removal by
> sending an interrupt to the guest. At some point later QEMU is expected
> to clean up after the device (such as unbind/unmap MSIs), which will
> occur when the guest signals that the device has been ejected.

As discussed, I agree that this is a problem.  There is a race between
qemu/libxl and the guest.  If libxl gets there first, you see the
symptoms you report.  Having libxl not progress with the rest of the
removal is the right approach to fixing it.

However, unfortunately, the approach you have taken has some problems.

The most seriouis is this: you may not call usleep() anywhere inside
libxl.  If you want to wait, you must use the callback mechanisms.
This is because the process running libxl may be a daemon handling
many domains, and we must not hang waiting for any particular domain.

I think that this means:
  * Making libxl__device_pci_remove_common asynchronous (ie, so
    that it makes a callback when done, rather than simply returning;
  * Then, making do_pci_remove asynchronous, too.  This will involve
    unfolding the loop in libxl__device_pci_remove_common into a
    callback chain.
  * Then, adjusting the new asynchronous do_pci_remove so that it
    becomes two (or perhaps more) chained callback functions which
    use a libxl__ev_time to manage the polling loop

Secondly, I'm not particularly keen on polling.  Is there not a QMP
function that can be used to get notified when the device is really
removed ?  Sadly I guess that if there is, restructuring the qmp
handling in libxl_qmp.c (qmp_next et al) to be able to use it would be
way out of scope for a bugfix during the freeze.


Finally, some notes about error handling:

> +            else {
> +                unsigned total_us = 0, wait_us = 100000;
> +
> +                rc = -ETIMEDOUT;

rc must contain only libxl error values.  Most libxl functions return
libxl error values, not errno values.

I'm sorry that the rest of this file is so confused about this.  I
think you should use `ret' to contain responses which are `0 (for
success) or -1 (setting errno)', and probably something like
`errnoval' if you need actual errno values.

You should definitely never write  -EFOOBAR  in userland code.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:19:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:19:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJam-0001Lb-VH; Fri, 14 Nov 2014 16:19:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJal-0001LF-94
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:19:23 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	BA/13-16982-A8B26645; Fri, 14 Nov 2014 16:19:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415981958!11523628!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30302 invoked from network); 14 Nov 2014 16:19:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:19:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192908642"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:19:16 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJad-0003eS-Dz;
	Fri, 14 Nov 2014 16:19:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJac-0001nE-T0;
	Fri, 14 Nov 2014 16:19:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.11138.483109.931473@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 16:19:14 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("[PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> When a device is hot-unplugged libxl sends QEMU a "device-del" message
> (via QMP). This call returns after QEMU has initiated device removal by
> sending an interrupt to the guest. At some point later QEMU is expected
> to clean up after the device (such as unbind/unmap MSIs), which will
> occur when the guest signals that the device has been ejected.

As discussed, I agree that this is a problem.  There is a race between
qemu/libxl and the guest.  If libxl gets there first, you see the
symptoms you report.  Having libxl not progress with the rest of the
removal is the right approach to fixing it.

However, unfortunately, the approach you have taken has some problems.

The most seriouis is this: you may not call usleep() anywhere inside
libxl.  If you want to wait, you must use the callback mechanisms.
This is because the process running libxl may be a daemon handling
many domains, and we must not hang waiting for any particular domain.

I think that this means:
  * Making libxl__device_pci_remove_common asynchronous (ie, so
    that it makes a callback when done, rather than simply returning;
  * Then, making do_pci_remove asynchronous, too.  This will involve
    unfolding the loop in libxl__device_pci_remove_common into a
    callback chain.
  * Then, adjusting the new asynchronous do_pci_remove so that it
    becomes two (or perhaps more) chained callback functions which
    use a libxl__ev_time to manage the polling loop

Secondly, I'm not particularly keen on polling.  Is there not a QMP
function that can be used to get notified when the device is really
removed ?  Sadly I guess that if there is, restructuring the qmp
handling in libxl_qmp.c (qmp_next et al) to be able to use it would be
way out of scope for a bugfix during the freeze.


Finally, some notes about error handling:

> +            else {
> +                unsigned total_us = 0, wait_us = 100000;
> +
> +                rc = -ETIMEDOUT;

rc must contain only libxl error values.  Most libxl functions return
libxl error values, not errno values.

I'm sorry that the rest of this file is so confused about this.  I
think you should use `ret' to contain responses which are `0 (for
success) or -1 (setting errno)', and probably something like
`errnoval' if you need actual errno values.

You should definitely never write  -EFOOBAR  in userland code.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:22:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJdE-0001XN-HA; Fri, 14 Nov 2014 16:21:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpJdE-0001XH-2e
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:21:56 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	FA/0A-09284-32C26645; Fri, 14 Nov 2014 16:21:55 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415982113!11414272!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25133 invoked from network); 14 Nov 2014 16:21:54 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:21:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGLie0018462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:21:44 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGLhEG022965
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:21:44 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGLgpb022924; Fri, 14 Nov 2014 16:21:43 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:21:42 -0800
Message-ID: <54662CB1.2050505@oracle.com>
Date: Fri, 14 Nov 2014 11:24:17 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>	<21606.5282.659930.728522@mariner.uk.xensource.com>	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
In-Reply-To: <21606.10103.850619.644934@mariner.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 11:01 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>
>
>> And I believe we still need part of the second patch --- the one that
>> removes call to xc_domain_irq_permission() for PV guests (after your
>> patch is applied): this call will fail because xc_physdev_unmap_pirq()
>> above it will cause hypervisor to do unmap_domain_pirq()->irq_deny_access()
> What call to xc_physdev_unmap_pirq ?  I see one in the PV path.

(Now with Reply-all, sorry)

At the skip1 label.

The error is:
   [root@ovs105 libxl]# ./xl  pci-detach pvlinux 0000:09:00.1
   libxl: error: libxl_pci.c:1305:do_pci_remove: 
xc_domain_irq_permission irq=17: Invalid argument
   [root@ovs105 libxl]#


Thanks.
-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:22:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJdE-0001XN-HA; Fri, 14 Nov 2014 16:21:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpJdE-0001XH-2e
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:21:56 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	FA/0A-09284-32C26645; Fri, 14 Nov 2014 16:21:55 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1415982113!11414272!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25133 invoked from network); 14 Nov 2014 16:21:54 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:21:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGLie0018462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:21:44 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGLhEG022965
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:21:44 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGLgpb022924; Fri, 14 Nov 2014 16:21:43 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:21:42 -0800
Message-ID: <54662CB1.2050505@oracle.com>
Date: Fri, 14 Nov 2014 11:24:17 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>	<21606.5282.659930.728522@mariner.uk.xensource.com>	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
In-Reply-To: <21606.10103.850619.644934@mariner.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 11:01 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>
>
>> And I believe we still need part of the second patch --- the one that
>> removes call to xc_domain_irq_permission() for PV guests (after your
>> patch is applied): this call will fail because xc_physdev_unmap_pirq()
>> above it will cause hypervisor to do unmap_domain_pirq()->irq_deny_access()
> What call to xc_physdev_unmap_pirq ?  I see one in the PV path.

(Now with Reply-all, sorry)

At the skip1 label.

The error is:
   [root@ovs105 libxl]# ./xl  pci-detach pvlinux 0000:09:00.1
   libxl: error: libxl_pci.c:1305:do_pci_remove: 
xc_domain_irq_permission irq=17: Invalid argument
   [root@ovs105 libxl]#


Thanks.
-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:22:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJdz-0001sP-Us; Fri, 14 Nov 2014 16:22:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpJdy-0001sE-Ug
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:22:43 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	6A/D3-03145-25C26645; Fri, 14 Nov 2014 16:22:42 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415982159!12078144!1
X-Originating-IP: [64.18.0.145]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14041 invoked from network); 14 Nov 2014 16:22:41 -0000
Received: from exprod5og103.obsmtp.com (HELO exprod5og103.obsmtp.com)
	(64.18.0.145)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:22:41 -0000
Received: from mail-qc0-f171.google.com ([209.85.216.171]) (using TLSv1) by
	exprod5ob103.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYsTxcSHdMU/Ac96yy0Jtjj5nkSjNEl@postini.com;
	Fri, 14 Nov 2014 08:22:41 PST
Received: by mail-qc0-f171.google.com with SMTP id r5so1546543qcx.30
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 08:22:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=SFIUjhVlzWM8FNrolroOjrnVBxypis6j+PpqkHN6Z0U=;
	b=ZPMOWFNPnf1YWboEhbD0BbIcCptkS5t1hvTLFG3ZcbcpLl1UscCFM/qBVt8e8smAik
	grx2H+Z9txgNaLC4+xKRhKAV9pMsIzVW5jQZZ92QsGtGEsOefNPCXwUWv4HBRBHgbbad
	ZeMXo2g6p928n7L2X08jdJmfeOveFLv3wML9A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=SFIUjhVlzWM8FNrolroOjrnVBxypis6j+PpqkHN6Z0U=;
	b=WmLsLWV9tp4DmgHLTGGwuXUi/9U+rTF7acIPi7qPiCXBj6SbWhKvEnDwE/UEFbMnlj
	VnMzsiAsYyKf8cDvCtbUHtqsz7zj50Y/THje9QXtWZIAXEpFsIU5kPU4lUARAO2Cb6Zt
	gZSvLrqTK1kfTqaVnizOIN+SFylMN/Pijsv29CoVjibzC+jYmHyQwwdRQcGiowsgRTi6
	dUOdh2D9IYUx0RCIFYrv49CIZObB7K/s1+rojqTuXdrUthtpgMcL6laZrygkcj0HY/mh
	GuMXtKBdlnvTwukckP3d8Ujyo8OcyKDY8TUMG7uU99n+c3fEQS8JXojuMGh4+aSYlbsY
	lQPA==
X-Received: by 10.224.23.71 with SMTP id q7mr11303122qab.22.1415982158759;
	Fri, 14 Nov 2014 08:22:38 -0800 (PST)
X-Gm-Message-State: ALoCoQmRMaadvFwsBEJU/mVNwZ62NRFVbD9JAhVPgiRS5e3HuMxmaAuOVHAj76zNp4pHT2L6CT0zmjs7ptmpQ0l5cHVv66UnQ7oIa1PpOXhl58kcv7vEd4rLIlv0G0+rSl5+lf1NE42zWHfEvVCpnGDWiyDdOstm0A==
MIME-Version: 1.0
X-Received: by 10.224.23.71 with SMTP id q7mr11303111qab.22.1415982158653;
	Fri, 14 Nov 2014 08:22:38 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 08:22:38 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
Date: Fri, 14 Nov 2014 18:22:38 +0200
Message-ID: <CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 6:15 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> >> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I observe system freeze on latest xen/master branch.
>> >> >>
>> >> >> My setup is:
>> >> >>
>> >> >> - Jacinto 6 evm board (OMAP5)
>> >> >> - Latest Xen 4.5.0-rc2 as hypervisor
>> >> >> - Linux 3.8 as dom0, running on 2 vcpus
>> >> >> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
>> >> >> - XSM feature is disabled
>> >> >> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
>> >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
>> >> >> compiler
>> >> >>
>> >> >> Freeze occurs in random moment of time during creation of domU domain.
>> >> >> Even Xen console may be not available after freeze.
>> >> >> Can someone suggest - what it can be? Maybe some weak places in new
>> >> >> code? Maybe new gic, which was reworked a lot or something else?
>> >> >>
>> >> >> Thank you in advance for any suggestions.
>> >> >
>> >> > Is this really 3.8 or 3.18?
>> >>
>> >> We have 3.8 in both dom0 and domU
>> >>
>> >> > 3.8 is pretty old and doesn't have any of
>> >> > the fixes to be able to safely do dma involving guest pages to
>> >> > non-coherent devices.
>> >>
>> >> This is a good point. Now we are migrating to 3.12 kernel in dom0. But
>> >> Android will remain on 3.8. Will it help ?
>> >> Maybe you can point me to any tree with proper DMA fixes? Note: if you
>> >> are talking about SWIOTLB - we have your latest one, retrieved from
>> >> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
>> >> branch:swiotlb-xen-9.1
>> >
>> > The last and most stable series is:
>> >
>> > http://marc.info/?l=linux-kernel&m=141579241729749&w=2
>> >
>>
>> Thanks  - I'll try this series anyway.
>>
>> > But thinking more about this, I doubt that it is a dma problem, because
>> > you would most probably see various kind of error messages, not a
>> > freeze.
>> >
>>
>> Agree.
>>
>> >
>> >> > Where are you storing the guest disk images?
>> >>
>> >> SATA drive, dedicated to dom0, its controller has its own DMA
>> >
>> > Are they on file or on lvm volumes?
>>
>> Images are on file.
>>
>> Also note - freeze depends on system load. It reproduces more
>> frequently if I start Android + QNX + all frontends/backends drivers.
>> Starting Android only without any addition drivers works more less
>> stable. It looks like issue is reproduced when domU starts in parallel
>> with backends drivers in dom0.
>> But the same works fine with old Xen 4.4.
>
> In my experience freezes like the one you are describing are due to
> interrupt related bugs or deadlocks. Both of them are hard to track
> down. If you can reproduce it reliably maybe you could bisect it.

Agree. I suspect that new gic series impacts on this. In very few
moments when xen console is available after freeze I see that dom0
code stacks around kernel lock_release() or  handle_IPI() functions


-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:22:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJdz-0001sP-Us; Fri, 14 Nov 2014 16:22:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpJdy-0001sE-Ug
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:22:43 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	6A/D3-03145-25C26645; Fri, 14 Nov 2014 16:22:42 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1415982159!12078144!1
X-Originating-IP: [64.18.0.145]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14041 invoked from network); 14 Nov 2014 16:22:41 -0000
Received: from exprod5og103.obsmtp.com (HELO exprod5og103.obsmtp.com)
	(64.18.0.145)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:22:41 -0000
Received: from mail-qc0-f171.google.com ([209.85.216.171]) (using TLSv1) by
	exprod5ob103.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYsTxcSHdMU/Ac96yy0Jtjj5nkSjNEl@postini.com;
	Fri, 14 Nov 2014 08:22:41 PST
Received: by mail-qc0-f171.google.com with SMTP id r5so1546543qcx.30
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 08:22:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=SFIUjhVlzWM8FNrolroOjrnVBxypis6j+PpqkHN6Z0U=;
	b=ZPMOWFNPnf1YWboEhbD0BbIcCptkS5t1hvTLFG3ZcbcpLl1UscCFM/qBVt8e8smAik
	grx2H+Z9txgNaLC4+xKRhKAV9pMsIzVW5jQZZ92QsGtGEsOefNPCXwUWv4HBRBHgbbad
	ZeMXo2g6p928n7L2X08jdJmfeOveFLv3wML9A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=SFIUjhVlzWM8FNrolroOjrnVBxypis6j+PpqkHN6Z0U=;
	b=WmLsLWV9tp4DmgHLTGGwuXUi/9U+rTF7acIPi7qPiCXBj6SbWhKvEnDwE/UEFbMnlj
	VnMzsiAsYyKf8cDvCtbUHtqsz7zj50Y/THje9QXtWZIAXEpFsIU5kPU4lUARAO2Cb6Zt
	gZSvLrqTK1kfTqaVnizOIN+SFylMN/Pijsv29CoVjibzC+jYmHyQwwdRQcGiowsgRTi6
	dUOdh2D9IYUx0RCIFYrv49CIZObB7K/s1+rojqTuXdrUthtpgMcL6laZrygkcj0HY/mh
	GuMXtKBdlnvTwukckP3d8Ujyo8OcyKDY8TUMG7uU99n+c3fEQS8JXojuMGh4+aSYlbsY
	lQPA==
X-Received: by 10.224.23.71 with SMTP id q7mr11303122qab.22.1415982158759;
	Fri, 14 Nov 2014 08:22:38 -0800 (PST)
X-Gm-Message-State: ALoCoQmRMaadvFwsBEJU/mVNwZ62NRFVbD9JAhVPgiRS5e3HuMxmaAuOVHAj76zNp4pHT2L6CT0zmjs7ptmpQ0l5cHVv66UnQ7oIa1PpOXhl58kcv7vEd4rLIlv0G0+rSl5+lf1NE42zWHfEvVCpnGDWiyDdOstm0A==
MIME-Version: 1.0
X-Received: by 10.224.23.71 with SMTP id q7mr11303111qab.22.1415982158653;
	Fri, 14 Nov 2014 08:22:38 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 08:22:38 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
Date: Fri, 14 Nov 2014 18:22:38 +0200
Message-ID: <CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 6:15 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> >> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I observe system freeze on latest xen/master branch.
>> >> >>
>> >> >> My setup is:
>> >> >>
>> >> >> - Jacinto 6 evm board (OMAP5)
>> >> >> - Latest Xen 4.5.0-rc2 as hypervisor
>> >> >> - Linux 3.8 as dom0, running on 2 vcpus
>> >> >> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
>> >> >> - XSM feature is disabled
>> >> >> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
>> >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
>> >> >> compiler
>> >> >>
>> >> >> Freeze occurs in random moment of time during creation of domU domain.
>> >> >> Even Xen console may be not available after freeze.
>> >> >> Can someone suggest - what it can be? Maybe some weak places in new
>> >> >> code? Maybe new gic, which was reworked a lot or something else?
>> >> >>
>> >> >> Thank you in advance for any suggestions.
>> >> >
>> >> > Is this really 3.8 or 3.18?
>> >>
>> >> We have 3.8 in both dom0 and domU
>> >>
>> >> > 3.8 is pretty old and doesn't have any of
>> >> > the fixes to be able to safely do dma involving guest pages to
>> >> > non-coherent devices.
>> >>
>> >> This is a good point. Now we are migrating to 3.12 kernel in dom0. But
>> >> Android will remain on 3.8. Will it help ?
>> >> Maybe you can point me to any tree with proper DMA fixes? Note: if you
>> >> are talking about SWIOTLB - we have your latest one, retrieved from
>> >> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
>> >> branch:swiotlb-xen-9.1
>> >
>> > The last and most stable series is:
>> >
>> > http://marc.info/?l=linux-kernel&m=141579241729749&w=2
>> >
>>
>> Thanks  - I'll try this series anyway.
>>
>> > But thinking more about this, I doubt that it is a dma problem, because
>> > you would most probably see various kind of error messages, not a
>> > freeze.
>> >
>>
>> Agree.
>>
>> >
>> >> > Where are you storing the guest disk images?
>> >>
>> >> SATA drive, dedicated to dom0, its controller has its own DMA
>> >
>> > Are they on file or on lvm volumes?
>>
>> Images are on file.
>>
>> Also note - freeze depends on system load. It reproduces more
>> frequently if I start Android + QNX + all frontends/backends drivers.
>> Starting Android only without any addition drivers works more less
>> stable. It looks like issue is reproduced when domU starts in parallel
>> with backends drivers in dom0.
>> But the same works fine with old Xen 4.4.
>
> In my experience freezes like the one you are describing are due to
> interrupt related bugs or deadlocks. Both of them are hard to track
> down. If you can reproduce it reliably maybe you could bisect it.

Agree. I suspect that new gic series impacts on this. In very few
moments when xen console is available after freeze I see that dom0
code stacks around kernel lock_release() or  handle_IPI() functions


-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:28:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJj4-00027l-Bv; Fri, 14 Nov 2014 16:27: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@citrix.com>) id 1XpJj2-00027Z-Kt
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:27:56 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	96/07-25714-B8D26645; Fri, 14 Nov 2014 16:27:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415982471!11490065!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2876 invoked from network); 14 Nov 2014 16:27:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:27:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191447843"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:27:13 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJiF-0003r2-Ux;
	Fri, 14 Nov 2014 16:27:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJiF-0001pf-8Y;
	Fri, 14 Nov 2014 16:27:07 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Fri, 14 Nov 2014 16:27:04 +0000
Message-ID: <1415982424-7007-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 2/2] cs-adjust-flight: runvar-perlop: Do
	not report non-changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With -v, runvar-perlop would unconditionally print a message about the
changed variable.  Instead, only call runvar_set if the value is to
change.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 cs-adjust-flight |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cs-adjust-flight b/cs-adjust-flight
index 7ec17e3..d6cab1a 100755
--- a/cs-adjust-flight
+++ b/cs-adjust-flight
@@ -268,7 +268,8 @@ sub change__runvar_perlop {
         my ($job, $name, $varrow) = @_;
 	my $oldval = $varrow->{val};
 	my $newval = perlop_value($job, $name, $op, $oldval);
-        runvar_set($job, $name, $newval, " (modified from \`$oldval')");
+        runvar_set($job, $name, $newval, " (modified from \`$oldval')")
+	    if $newval ne $oldval;
     }, 'IGNORE');
 }
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:28:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJj3-00027e-0N; Fri, 14 Nov 2014 16:27:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJj1-00027U-Gy
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:27:55 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	16/34-11581-A8D26645; Fri, 14 Nov 2014 16:27:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415982471!11490065!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2789 invoked from network); 14 Nov 2014 16:27:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:27:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191447841"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:27:13 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJiF-0003r0-GV;
	Fri, 14 Nov 2014 16:27:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJiE-0001pc-QI;
	Fri, 14 Nov 2014 16:27:06 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Fri, 14 Nov 2014 16:27:03 +0000
Message-ID: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 1/2] target_editfile: Improve doc 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

More clearly state which arguments are optional.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 45ceee9..46b6720 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -521,7 +521,8 @@ sub teditfileex {
 sub target_editfile_root ($$$;$$) { teditfileex('root',@_); }
 sub target_editfile      ($$$;$$) { teditfileex('osstest',@_); }
     # my $code= pop @_;
-    # my ($ho,$rfile,$lleaf,$rdest) = @_;
+    # my ($ho,$rfile, $lleaf,$rdest) = @_;
+    #                 ^^^^^^^^^^^^^ optional
 
 sub target_cmd_build ($$$$) {
     my ($ho,$timeout,$builddir,$script) = @_;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:28:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJj4-00027l-Bv; Fri, 14 Nov 2014 16:27: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@citrix.com>) id 1XpJj2-00027Z-Kt
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:27:56 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	96/07-25714-B8D26645; Fri, 14 Nov 2014 16:27:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415982471!11490065!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2876 invoked from network); 14 Nov 2014 16:27:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:27:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191447843"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:27:13 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJiF-0003r2-Ux;
	Fri, 14 Nov 2014 16:27:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJiF-0001pf-8Y;
	Fri, 14 Nov 2014 16:27:07 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Fri, 14 Nov 2014 16:27:04 +0000
Message-ID: <1415982424-7007-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 2/2] cs-adjust-flight: runvar-perlop: Do
	not report non-changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With -v, runvar-perlop would unconditionally print a message about the
changed variable.  Instead, only call runvar_set if the value is to
change.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 cs-adjust-flight |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cs-adjust-flight b/cs-adjust-flight
index 7ec17e3..d6cab1a 100755
--- a/cs-adjust-flight
+++ b/cs-adjust-flight
@@ -268,7 +268,8 @@ sub change__runvar_perlop {
         my ($job, $name, $varrow) = @_;
 	my $oldval = $varrow->{val};
 	my $newval = perlop_value($job, $name, $op, $oldval);
-        runvar_set($job, $name, $newval, " (modified from \`$oldval')");
+        runvar_set($job, $name, $newval, " (modified from \`$oldval')")
+	    if $newval ne $oldval;
     }, 'IGNORE');
 }
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:28:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJj3-00027e-0N; Fri, 14 Nov 2014 16:27:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJj1-00027U-Gy
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:27:55 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	16/34-11581-A8D26645; Fri, 14 Nov 2014 16:27:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415982471!11490065!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2789 invoked from network); 14 Nov 2014 16:27:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:27:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191447841"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:27:13 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJiF-0003r0-GV;
	Fri, 14 Nov 2014 16:27:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJiE-0001pc-QI;
	Fri, 14 Nov 2014 16:27:06 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Fri, 14 Nov 2014 16:27:03 +0000
Message-ID: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 1/2] target_editfile: Improve doc 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

More clearly state which arguments are optional.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 45ceee9..46b6720 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -521,7 +521,8 @@ sub teditfileex {
 sub target_editfile_root ($$$;$$) { teditfileex('root',@_); }
 sub target_editfile      ($$$;$$) { teditfileex('osstest',@_); }
     # my $code= pop @_;
-    # my ($ho,$rfile,$lleaf,$rdest) = @_;
+    # my ($ho,$rfile, $lleaf,$rdest) = @_;
+    #                 ^^^^^^^^^^^^^ optional
 
 sub target_cmd_build ($$$$) {
     my ($ho,$timeout,$builddir,$script) = @_;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:28:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJjp-0002Db-1e; Fri, 14 Nov 2014 16:28:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpJjn-0002DM-Hc
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:28:43 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	D1/45-07724-ABD26645; Fri, 14 Nov 2014 16:28:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415982522!11520683!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19835 invoked from network); 14 Nov 2014 16:28:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:28:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 16:28:41 +0000
Message-Id: <54663BC90200007800047D3F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 16:28:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
	<20141114153208.GD5364@laptop.dumpdata.com>
In-Reply-To: <20141114153208.GD5364@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: roy.franz@linaro.org, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 16:32, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 14, 2014 at 12:37:30PM +0000, Jan Beulich wrote:
>> @@ -1051,17 +1051,23 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>>      if ( !efi_memmap )
>>          blexit(L"Unable to allocate memory for EFI memory map");
>>  
>> -    status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
>> -                                  &efi_mdesc_size, &mdesc_ver);
>> -    if ( EFI_ERROR(status) )
>> -        PrintErrMesg(L"Cannot obtain memory map", status);
>> +    for ( retry = 0; ; retry = 1 )
>> +    {
>> +        status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
>> +                                      &efi_mdesc_size, &mdesc_ver);
>> +        if ( EFI_ERROR(status) )
>> +            PrintErrMesg(L"Cannot obtain memory map", status);
>>  
>> -    efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
>> -                                efi_mdesc_size, mdesc_ver);
>> +        efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
>> +                                    efi_mdesc_size, mdesc_ver);
>>  
>> -    efi_arch_pre_exit_boot();
>> +        efi_arch_pre_exit_boot();
>> +
>> +        status = efi_bs->ExitBootServices(ImageHandle, map_key);
>> +        if ( status != EFI_INVALID_PARAMETER || retry )
>> +            break;
>> +    }
> 
> Any reason for just doing the loop at max twice? Could we iterate
> more than those (say forever?) with an printk at suitable intervals
> to notify the user?

For one, there's no reason to do it more than twice. As said in the
patch description, even doing the first retry is already going beyond
what the current specification requires us to do. And just to make
this clear here too - when I first wrote this EFI boot code, I was
aware of the retry being done elsewhere, and I intentionally
decided against doing so as not being mandated by the spec. I'm
continuing to take the position that we shouldn't give firmware
writers more leeway than we absolutely have to, otherwise they
will never get their stuff conform to the spec.

And then, there's no printk() available at this point. And we mustn't
call boot services anymore either. So there's no way to get anything
out to the user.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:28:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJjp-0002Db-1e; Fri, 14 Nov 2014 16:28:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpJjn-0002DM-Hc
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:28:43 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	D1/45-07724-ABD26645; Fri, 14 Nov 2014 16:28:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1415982522!11520683!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19835 invoked from network); 14 Nov 2014 16:28:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:28:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 16:28:41 +0000
Message-Id: <54663BC90200007800047D3F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 16:28:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
	<20141114153208.GD5364@laptop.dumpdata.com>
In-Reply-To: <20141114153208.GD5364@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: roy.franz@linaro.org, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 16:32, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 14, 2014 at 12:37:30PM +0000, Jan Beulich wrote:
>> @@ -1051,17 +1051,23 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>>      if ( !efi_memmap )
>>          blexit(L"Unable to allocate memory for EFI memory map");
>>  
>> -    status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
>> -                                  &efi_mdesc_size, &mdesc_ver);
>> -    if ( EFI_ERROR(status) )
>> -        PrintErrMesg(L"Cannot obtain memory map", status);
>> +    for ( retry = 0; ; retry = 1 )
>> +    {
>> +        status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
>> +                                      &efi_mdesc_size, &mdesc_ver);
>> +        if ( EFI_ERROR(status) )
>> +            PrintErrMesg(L"Cannot obtain memory map", status);
>>  
>> -    efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
>> -                                efi_mdesc_size, mdesc_ver);
>> +        efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
>> +                                    efi_mdesc_size, mdesc_ver);
>>  
>> -    efi_arch_pre_exit_boot();
>> +        efi_arch_pre_exit_boot();
>> +
>> +        status = efi_bs->ExitBootServices(ImageHandle, map_key);
>> +        if ( status != EFI_INVALID_PARAMETER || retry )
>> +            break;
>> +    }
> 
> Any reason for just doing the loop at max twice? Could we iterate
> more than those (say forever?) with an printk at suitable intervals
> to notify the user?

For one, there's no reason to do it more than twice. As said in the
patch description, even doing the first retry is already going beyond
what the current specification requires us to do. And just to make
this clear here too - when I first wrote this EFI boot code, I was
aware of the retry being done elsewhere, and I intentionally
decided against doing so as not being mandated by the spec. I'm
continuing to take the position that we shouldn't give firmware
writers more leeway than we absolutely have to, otherwise they
will never get their stuff conform to the spec.

And then, there's no printk() available at this point. And we mustn't
call boot services anymore either. So there's no way to get anything
out to the user.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:28:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:28:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJk3-0002Gt-J7; Fri, 14 Nov 2014 16:28:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpJk1-0002GP-Di
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:28:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	81/68-09936-8CD26645; Fri, 14 Nov 2014 16:28:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415982533!12844612!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7149 invoked from network); 14 Nov 2014 16:28:56 -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;
	14 Nov 2014 16:28:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192913459"
Message-ID: <1415982529.7113.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 16:28:49 +0000
In-Reply-To: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 1/2] target_editfile: Improve doc
	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

On Fri, 2014-11-14 at 16:27 +0000, Ian Jackson wrote:
> More clearly state which arguments are optional.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  Osstest/TestSupport.pm |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index 45ceee9..46b6720 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -521,7 +521,8 @@ sub teditfileex {
>  sub target_editfile_root ($$$;$$) { teditfileex('root',@_); }
>  sub target_editfile      ($$$;$$) { teditfileex('osstest',@_); }
>      # my $code= pop @_;
> -    # my ($ho,$rfile,$lleaf,$rdest) = @_;
> +    # my ($ho,$rfile, $lleaf,$rdest) = @_;
> +    #                 ^^^^^^^^^^^^^ optional
>  
>  sub target_cmd_build ($$$$) {
>      my ($ho,$timeout,$builddir,$script) = @_;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:28:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:28:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJk3-0002Gt-J7; Fri, 14 Nov 2014 16:28:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpJk1-0002GP-Di
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:28:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	81/68-09936-8CD26645; Fri, 14 Nov 2014 16:28:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415982533!12844612!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7149 invoked from network); 14 Nov 2014 16:28:56 -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;
	14 Nov 2014 16:28:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192913459"
Message-ID: <1415982529.7113.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 16:28:49 +0000
In-Reply-To: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 1/2] target_editfile: Improve doc
	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

On Fri, 2014-11-14 at 16:27 +0000, Ian Jackson wrote:
> More clearly state which arguments are optional.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  Osstest/TestSupport.pm |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index 45ceee9..46b6720 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -521,7 +521,8 @@ sub teditfileex {
>  sub target_editfile_root ($$$;$$) { teditfileex('root',@_); }
>  sub target_editfile      ($$$;$$) { teditfileex('osstest',@_); }
>      # my $code= pop @_;
> -    # my ($ho,$rfile,$lleaf,$rdest) = @_;
> +    # my ($ho,$rfile, $lleaf,$rdest) = @_;
> +    #                 ^^^^^^^^^^^^^ optional
>  
>  sub target_cmd_build ($$$$) {
>      my ($ho,$timeout,$builddir,$script) = @_;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:29:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:29:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJkZ-0002NJ-1S; Fri, 14 Nov 2014 16:29:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpJkY-0002N5-0o
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:29:30 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	71/71-02699-9ED26645; Fri, 14 Nov 2014 16:29:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415982565!12645670!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11858 invoked from network); 14 Nov 2014 16:29:28 -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;
	14 Nov 2014 16:29:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191448799"
Message-ID: <1415982562.7113.24.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 16:29:22 +0000
In-Reply-To: <1415982424-7007-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415982424-7007-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/2] cs-adjust-flight:
 runvar-perlop: Do not report non-changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 16:27 +0000, Ian Jackson wrote:
> With -v, runvar-perlop would unconditionally print a message about the
> changed variable.  Instead, only call runvar_set if the value is to
> change.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  cs-adjust-flight |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/cs-adjust-flight b/cs-adjust-flight
> index 7ec17e3..d6cab1a 100755
> --- a/cs-adjust-flight
> +++ b/cs-adjust-flight
> @@ -268,7 +268,8 @@ sub change__runvar_perlop {
>          my ($job, $name, $varrow) = @_;
>  	my $oldval = $varrow->{val};
>  	my $newval = perlop_value($job, $name, $op, $oldval);
> -        runvar_set($job, $name, $newval, " (modified from \`$oldval')");
> +        runvar_set($job, $name, $newval, " (modified from \`$oldval')")
> +	    if $newval ne $oldval;
>      }, 'IGNORE');
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:29:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:29:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJkZ-0002NJ-1S; Fri, 14 Nov 2014 16:29:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpJkY-0002N5-0o
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:29:30 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	71/71-02699-9ED26645; Fri, 14 Nov 2014 16:29:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1415982565!12645670!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11858 invoked from network); 14 Nov 2014 16:29:28 -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;
	14 Nov 2014 16:29:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191448799"
Message-ID: <1415982562.7113.24.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 16:29:22 +0000
In-Reply-To: <1415982424-7007-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1415982424-7007-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415982424-7007-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/2] cs-adjust-flight:
 runvar-perlop: Do not report non-changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 16:27 +0000, Ian Jackson wrote:
> With -v, runvar-perlop would unconditionally print a message about the
> changed variable.  Instead, only call runvar_set if the value is to
> change.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  cs-adjust-flight |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/cs-adjust-flight b/cs-adjust-flight
> index 7ec17e3..d6cab1a 100755
> --- a/cs-adjust-flight
> +++ b/cs-adjust-flight
> @@ -268,7 +268,8 @@ sub change__runvar_perlop {
>          my ($job, $name, $varrow) = @_;
>  	my $oldval = $varrow->{val};
>  	my $newval = perlop_value($job, $name, $op, $oldval);
> -        runvar_set($job, $name, $newval, " (modified from \`$oldval')");
> +        runvar_set($job, $name, $newval, " (modified from \`$oldval')")
> +	    if $newval ne $oldval;
>      }, 'IGNORE');
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:30:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJlv-0002b8-H5; Fri, 14 Nov 2014 16:30:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJlt-0002as-T1
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 16:30:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3C/3B-09936-D3E26645; Fri, 14 Nov 2014 16:30:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415982649!12845095!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19538 invoked from network); 14 Nov 2014 16:30:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:30:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192914333"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 11:30:45 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJlk-00027K-P0;
	Fri, 14 Nov 2014 16:30:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJlk-0004lI-Jj;
	Fri, 14 Nov 2014 16:30:44 +0000
Date: Fri, 14 Nov 2014 16:30:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31544-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31544: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31544 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31544/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 31520
 test-amd64-i386-pair          8 xen-boot/dst_host           fail pass in 31520

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  like 26261
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 31520 like 26261
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail in 31520 blocked in 26303
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 31520 like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31520 never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:30:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJlv-0002b8-H5; Fri, 14 Nov 2014 16:30:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJlt-0002as-T1
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 16:30:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3C/3B-09936-D3E26645; Fri, 14 Nov 2014 16:30:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415982649!12845095!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19538 invoked from network); 14 Nov 2014 16:30:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:30:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192914333"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 11:30:45 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJlk-00027K-P0;
	Fri, 14 Nov 2014 16:30:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJlk-0004lI-Jj;
	Fri, 14 Nov 2014 16:30:44 +0000
Date: Fri, 14 Nov 2014 16:30:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31544-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31544: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31544 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31544/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 31520
 test-amd64-i386-pair          8 xen-boot/dst_host           fail pass in 31520

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  like 26261
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 31520 like 26261
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail in 31520 blocked in 26303
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 31520 like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31520 never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:31:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJmF-0002fg-Us; Fri, 14 Nov 2014 16:31:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJmE-0002fH-3n
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:31:14 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	A1/90-05632-15E26645; Fri, 14 Nov 2014 16:31:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415982669!7754750!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30276 invoked from network); 14 Nov 2014 16:31:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:31:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192914535"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:31:05 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJm4-0003uA-Cs;
	Fri, 14 Nov 2014 16:31:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJm3-0001xQ-Ld;
	Fri, 14 Nov 2014 16:31:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.11847.373254.124439@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 16:31:03 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54662CB1.2050505@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> (Now with Reply-all, sorry)

Likewise.

> On 11/14/2014 11:01 AM, Ian Jackson wrote:
> > What call to xc_physdev_unmap_pirq ?  I see one in the PV path.
> 
> At the skip1 label.

`goto skip1' only appears in the PV path AFAICT.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:31:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJmF-0002fg-Us; Fri, 14 Nov 2014 16:31:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpJmE-0002fH-3n
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:31:14 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	A1/90-05632-15E26645; Fri, 14 Nov 2014 16:31:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415982669!7754750!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30276 invoked from network); 14 Nov 2014 16:31:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:31:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192914535"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:31:05 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpJm4-0003uA-Cs;
	Fri, 14 Nov 2014 16:31:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJm3-0001xQ-Ld;
	Fri, 14 Nov 2014 16:31:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.11847.373254.124439@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 16:31:03 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54662CB1.2050505@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> (Now with Reply-all, sorry)

Likewise.

> On 11/14/2014 11:01 AM, Ian Jackson wrote:
> > What call to xc_physdev_unmap_pirq ?  I see one in the PV path.
> 
> At the skip1 label.

`goto skip1' only appears in the PV path AFAICT.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:33:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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 1XpJo8-0003DV-LF; Fri, 14 Nov 2014 16:33:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1XpJo7-0003DM-V2
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:33:12 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	E2/5C-07724-7CE26645; Fri, 14 Nov 2014 16:33:11 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415982788!7755321!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9156 invoked from network); 14 Nov 2014 16:33:10 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:33:10 -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 sAEGWwmk013626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Fri, 14 Nov 2014 11:32:59 -0500
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-125.ams2.redhat.com
	[10.36.116.125])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAEGWtuf022142; Fri, 14 Nov 2014 11:32:57 -0500
Message-ID: <54662EB7.8080501@redhat.com>
Date: Fri, 14 Nov 2014 17:32:55 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: edk2-devel@lists.sourceforge.net
References: <1415899632-31802-1-git-send-email-anthony.perard@citrix.com>
	<1415899632-31802-2-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1415899632-31802-2-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [edk2] [PATCH 1/4] OvmfPkg/XenBusDxe: In XenStore,
 replace type of Len from UINTN to UINT32.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/13/14 18:27, Anthony PERARD wrote:
> Since a message to XenStore have a lenght of type UINT32, have
> XenStore.c deal only with UINT32 instead of a mixmatch with UINTN.
> 
> This patch replaces the type of Len in WRITE_REQUEST and the type of the
> argument Len of XenStoreWriteStore and XenStoreReadStore.
> 
> This patch should avoid to have type cast were it does not make sense to
> have them.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> CC: Xen Devel <xen-devel@lists.xen.org>
> ---
>  OvmfPkg/XenBusDxe/XenStore.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
> index f176b95..7c272b3 100644
> --- a/OvmfPkg/XenBusDxe/XenStore.c
> +++ b/OvmfPkg/XenBusDxe/XenStore.c
> @@ -69,7 +69,7 @@
>  
>  typedef struct {
>    CONST VOID  *Data;
> -  UINTN       Len;
> +  UINT32      Len;
>  } WRITE_REQUEST;
>  
>  /* Register callback to watch subtree (node) in the XenStore. */
> @@ -456,7 +456,7 @@ STATIC
>  XENSTORE_STATUS
>  XenStoreWriteStore (
>    IN CONST VOID *DataPtr,
> -  IN UINTN      Len
> +  IN UINT32     Len
>    )
>  {
>    XENSTORE_RING_IDX Cons, Prod;
> @@ -535,7 +535,7 @@ STATIC
>  XENSTORE_STATUS
>  XenStoreReadStore (
>    OUT VOID *DataPtr,
> -  IN  UINTN Len
> +  IN  UINT32 Len
>    )
>  {
>    XENSTORE_RING_IDX Cons, Prod;
> @@ -883,7 +883,7 @@ XenStoreSingle (
>    WRITE_REQUEST WriteRequest;
>  
>    WriteRequest.Data = (VOID *) Body;
> -  WriteRequest.Len = AsciiStrSize (Body);
> +  WriteRequest.Len = (UINT32)AsciiStrSize (Body);
>  
>    return XenStoreTalkv (Transaction, RequestType, &WriteRequest, 1,
>                          LenPtr, Result);
> @@ -912,9 +912,9 @@ XenStoreWatch (
>    WRITE_REQUEST WriteRequest[2];
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Token;
> -  WriteRequest[1].Len = AsciiStrSize (Token);
> +  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
>  
>    return XenStoreTalkv (XST_NIL, XS_WATCH, WriteRequest, 2, NULL, NULL);
>  }
> @@ -938,9 +938,9 @@ XenStoreUnwatch (
>    WRITE_REQUEST WriteRequest[2];
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Token;
> -  WriteRequest[1].Len = AsciiStrSize (Token);
> +  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
>  
>    return XenStoreTalkv (XST_NIL, XS_UNWATCH, WriteRequest, 2, NULL, NULL);
>  }
> @@ -1245,9 +1245,9 @@ XenStoreWrite (
>    Path = XenStoreJoin (DirectoryPath, Node);
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Str;
> -  WriteRequest[1].Len = AsciiStrLen (Str);
> +  WriteRequest[1].Len = (UINT32)AsciiStrLen (Str);
>  
>    Status = XenStoreTalkv (Transaction, XS_WRITE, WriteRequest, 2, NULL, NULL);
>    FreePool (Path);
> 

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:33:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 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 1XpJo8-0003DV-LF; Fri, 14 Nov 2014 16:33:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1XpJo7-0003DM-V2
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:33:12 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	E2/5C-07724-7CE26645; Fri, 14 Nov 2014 16:33:11 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415982788!7755321!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9156 invoked from network); 14 Nov 2014 16:33:10 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:33:10 -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 sAEGWwmk013626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Fri, 14 Nov 2014 11:32:59 -0500
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-125.ams2.redhat.com
	[10.36.116.125])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAEGWtuf022142; Fri, 14 Nov 2014 11:32:57 -0500
Message-ID: <54662EB7.8080501@redhat.com>
Date: Fri, 14 Nov 2014 17:32:55 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: edk2-devel@lists.sourceforge.net
References: <1415899632-31802-1-git-send-email-anthony.perard@citrix.com>
	<1415899632-31802-2-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1415899632-31802-2-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [edk2] [PATCH 1/4] OvmfPkg/XenBusDxe: In XenStore,
 replace type of Len from UINTN to UINT32.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/13/14 18:27, Anthony PERARD wrote:
> Since a message to XenStore have a lenght of type UINT32, have
> XenStore.c deal only with UINT32 instead of a mixmatch with UINTN.
> 
> This patch replaces the type of Len in WRITE_REQUEST and the type of the
> argument Len of XenStoreWriteStore and XenStoreReadStore.
> 
> This patch should avoid to have type cast were it does not make sense to
> have them.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> CC: Xen Devel <xen-devel@lists.xen.org>
> ---
>  OvmfPkg/XenBusDxe/XenStore.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
> index f176b95..7c272b3 100644
> --- a/OvmfPkg/XenBusDxe/XenStore.c
> +++ b/OvmfPkg/XenBusDxe/XenStore.c
> @@ -69,7 +69,7 @@
>  
>  typedef struct {
>    CONST VOID  *Data;
> -  UINTN       Len;
> +  UINT32      Len;
>  } WRITE_REQUEST;
>  
>  /* Register callback to watch subtree (node) in the XenStore. */
> @@ -456,7 +456,7 @@ STATIC
>  XENSTORE_STATUS
>  XenStoreWriteStore (
>    IN CONST VOID *DataPtr,
> -  IN UINTN      Len
> +  IN UINT32     Len
>    )
>  {
>    XENSTORE_RING_IDX Cons, Prod;
> @@ -535,7 +535,7 @@ STATIC
>  XENSTORE_STATUS
>  XenStoreReadStore (
>    OUT VOID *DataPtr,
> -  IN  UINTN Len
> +  IN  UINT32 Len
>    )
>  {
>    XENSTORE_RING_IDX Cons, Prod;
> @@ -883,7 +883,7 @@ XenStoreSingle (
>    WRITE_REQUEST WriteRequest;
>  
>    WriteRequest.Data = (VOID *) Body;
> -  WriteRequest.Len = AsciiStrSize (Body);
> +  WriteRequest.Len = (UINT32)AsciiStrSize (Body);
>  
>    return XenStoreTalkv (Transaction, RequestType, &WriteRequest, 1,
>                          LenPtr, Result);
> @@ -912,9 +912,9 @@ XenStoreWatch (
>    WRITE_REQUEST WriteRequest[2];
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Token;
> -  WriteRequest[1].Len = AsciiStrSize (Token);
> +  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
>  
>    return XenStoreTalkv (XST_NIL, XS_WATCH, WriteRequest, 2, NULL, NULL);
>  }
> @@ -938,9 +938,9 @@ XenStoreUnwatch (
>    WRITE_REQUEST WriteRequest[2];
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Token;
> -  WriteRequest[1].Len = AsciiStrSize (Token);
> +  WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
>  
>    return XenStoreTalkv (XST_NIL, XS_UNWATCH, WriteRequest, 2, NULL, NULL);
>  }
> @@ -1245,9 +1245,9 @@ XenStoreWrite (
>    Path = XenStoreJoin (DirectoryPath, Node);
>  
>    WriteRequest[0].Data = (VOID *) Path;
> -  WriteRequest[0].Len = AsciiStrSize (Path);
> +  WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
>    WriteRequest[1].Data = (VOID *) Str;
> -  WriteRequest[1].Len = AsciiStrLen (Str);
> +  WriteRequest[1].Len = (UINT32)AsciiStrLen (Str);
>  
>    Status = XenStoreTalkv (Transaction, XS_WRITE, WriteRequest, 2, NULL, NULL);
>    FreePool (Path);
> 

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:34:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJpn-0003Po-4Y; Fri, 14 Nov 2014 16:34:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpJpl-0003PU-AA
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:34:53 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	73/D8-17958-C2F26645; Fri, 14 Nov 2014 16:34:52 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415982889!9044364!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25934 invoked from network); 14 Nov 2014 16:34:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:34:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGYhc1003656
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:34:44 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEGYgiu007388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:34:43 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGYgCH025408; Fri, 14 Nov 2014 16:34:42 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:34:42 -0800
Message-ID: <54662FBD.1010605@oracle.com>
Date: Fri, 14 Nov 2014 11:37:17 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>	<21606.5282.659930.728522@mariner.uk.xensource.com>	<54662004.6050702@oracle.com>	<21606.10103.850619.644934@mariner.uk.xensource.com>	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
In-Reply-To: <21606.11847.373254.124439@mariner.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 11:31 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>
>> On 11/14/2014 11:01 AM, Ian Jackson wrote:
>>> What call to xc_physdev_unmap_pirq ?  I see one in the PV path.
>> At the skip1 label.
> `goto skip1' only appears in the PV path AFAICT.
>

Right, this is all about PV code path.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:34:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJpn-0003Po-4Y; Fri, 14 Nov 2014 16:34:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpJpl-0003PU-AA
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:34:53 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	73/D8-17958-C2F26645; Fri, 14 Nov 2014 16:34:52 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415982889!9044364!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25934 invoked from network); 14 Nov 2014 16:34:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:34:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGYhc1003656
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:34:44 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEGYgiu007388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:34:43 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGYgCH025408; Fri, 14 Nov 2014 16:34:42 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:34:42 -0800
Message-ID: <54662FBD.1010605@oracle.com>
Date: Fri, 14 Nov 2014 11:37:17 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>	<21606.5282.659930.728522@mariner.uk.xensource.com>	<54662004.6050702@oracle.com>	<21606.10103.850619.644934@mariner.uk.xensource.com>	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
In-Reply-To: <21606.11847.373254.124439@mariner.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 11:31 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>
>> On 11/14/2014 11:01 AM, Ian Jackson wrote:
>>> What call to xc_physdev_unmap_pirq ?  I see one in the PV path.
>> At the skip1 label.
> `goto skip1' only appears in the PV path AFAICT.
>

Right, this is all about PV code path.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:36:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJqu-0003Vw-JQ; Fri, 14 Nov 2014 16:36:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XpJqt-0003Vk-5U
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:36:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7F/23-24532-27F26645; Fri, 14 Nov 2014 16:36:02 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415982961!12878715!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22522 invoked from network); 14 Nov 2014 16:36:01 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:36:01 -0000
Received: by mail-wg0-f50.google.com with SMTP id k14so1800832wgh.9
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 08:36:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=bzTCXWsPs5F0v0/eZvaJWHpJsKn6tbEeTQEMbdTFG5w=;
	b=H/2JlilxaSVf9gVHkXezVN2/Ffb+aovtHe5ps2E/j91fBIErbPOnra4VJAQGgFaLbl
	M/eaVstEcZ6vMAm0ypiEcjB7V+RR2Cd6NlOg2e8FlPd4WCiietsATJb4MEOYB7VgNLKi
	AqxaksdlNx7OiPaKUwPlnDTSzb5VfLMZRusnLnnrvMcp8BOXzep92Vi+BrxGw+Ysq1Ta
	HaLiHIvb/1Mb0zlXPKFvDG6X6Up6LcDZxGwfzXaiek9RgavuDb6rRsEKXgMoTyKP+d2p
	/jGk/5asVi13WN6FH22Zc6rlbijWR+NLUYcTGnYId1aCHmwVE2agH1F0Q++gdpdFCxPN
	BYtQ==
X-Gm-Message-State: ALoCoQnk/j4AsWlFg+s5IqyK5ixCG/Tz2lRYdS+z0r41YiAhCgj6ta2KWSmMRaiB+Huv5yoHzF5l
X-Received: by 10.180.8.193 with SMTP id t1mr9239297wia.15.1415982961479;
	Fri, 14 Nov 2014 08:36:01 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fl1sm4020547wib.15.2014.11.14.08.36.00
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 14 Nov 2014 08:36:00 -0800 (PST)
Message-ID: <54662F69.8060700@linaro.org>
Date: Fri, 14 Nov 2014 16:35:53 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
In-Reply-To: <CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 04:22 PM, Andrii Tseglytskyi wrote:
> On Fri, Nov 14, 2014 at 6:15 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>>> On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>>>>> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
>>>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>>>> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I observe system freeze on latest xen/master branch.
>>>>>>>
>>>>>>> My setup is:
>>>>>>>
>>>>>>> - Jacinto 6 evm board (OMAP5)
>>>>>>> - Latest Xen 4.5.0-rc2 as hypervisor
>>>>>>> - Linux 3.8 as dom0, running on 2 vcpus
>>>>>>> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
>>>>>>> - XSM feature is disabled
>>>>>>> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
>>>>>>> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
>>>>>>> compiler
>>>>>>>
>>>>>>> Freeze occurs in random moment of time during creation of domU domain.
>>>>>>> Even Xen console may be not available after freeze.
>>>>>>> Can someone suggest - what it can be? Maybe some weak places in new
>>>>>>> code? Maybe new gic, which was reworked a lot or something else?
>>>>>>>
>>>>>>> Thank you in advance for any suggestions.
>>>>>>
>>>>>> Is this really 3.8 or 3.18?
>>>>>
>>>>> We have 3.8 in both dom0 and domU
>>>>>
>>>>>> 3.8 is pretty old and doesn't have any of
>>>>>> the fixes to be able to safely do dma involving guest pages to
>>>>>> non-coherent devices.
>>>>>
>>>>> This is a good point. Now we are migrating to 3.12 kernel in dom0. But
>>>>> Android will remain on 3.8. Will it help ?
>>>>> Maybe you can point me to any tree with proper DMA fixes? Note: if you
>>>>> are talking about SWIOTLB - we have your latest one, retrieved from
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
>>>>> branch:swiotlb-xen-9.1
>>>>
>>>> The last and most stable series is:
>>>>
>>>> http://marc.info/?l=linux-kernel&m=141579241729749&w=2
>>>>
>>>
>>> Thanks  - I'll try this series anyway.
>>>
>>>> But thinking more about this, I doubt that it is a dma problem, because
>>>> you would most probably see various kind of error messages, not a
>>>> freeze.
>>>>
>>>
>>> Agree.
>>>
>>>>
>>>>>> Where are you storing the guest disk images?
>>>>>
>>>>> SATA drive, dedicated to dom0, its controller has its own DMA
>>>>
>>>> Are they on file or on lvm volumes?
>>>
>>> Images are on file.
>>>
>>> Also note - freeze depends on system load. It reproduces more
>>> frequently if I start Android + QNX + all frontends/backends drivers.
>>> Starting Android only without any addition drivers works more less
>>> stable. It looks like issue is reproduced when domU starts in parallel
>>> with backends drivers in dom0.
>>> But the same works fine with old Xen 4.4.
>>
>> In my experience freezes like the one you are describing are due to
>> interrupt related bugs or deadlocks. Both of them are hard to track
>> down. If you can reproduce it reliably maybe you could bisect it.
> 
> Agree. I suspect that new gic series impacts on this. In very few
> moments when xen console is available after freeze I see that dom0
> code stacks around kernel lock_release() or  handle_IPI() functions

I would be surprised that the next GIC series impact this code as the
next driver is only compiled for arm64 (GICv3 doesn't exist on arm32).
Though, there was some refactoring.

The interrupt management has also been reworked for Xen 4.5 to avoid
maintenance interrupt. I would give a look on this part.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:36:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJqu-0003Vw-JQ; Fri, 14 Nov 2014 16:36:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XpJqt-0003Vk-5U
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:36:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7F/23-24532-27F26645; Fri, 14 Nov 2014 16:36:02 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1415982961!12878715!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22522 invoked from network); 14 Nov 2014 16:36:01 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:36:01 -0000
Received: by mail-wg0-f50.google.com with SMTP id k14so1800832wgh.9
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 08:36:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=bzTCXWsPs5F0v0/eZvaJWHpJsKn6tbEeTQEMbdTFG5w=;
	b=H/2JlilxaSVf9gVHkXezVN2/Ffb+aovtHe5ps2E/j91fBIErbPOnra4VJAQGgFaLbl
	M/eaVstEcZ6vMAm0ypiEcjB7V+RR2Cd6NlOg2e8FlPd4WCiietsATJb4MEOYB7VgNLKi
	AqxaksdlNx7OiPaKUwPlnDTSzb5VfLMZRusnLnnrvMcp8BOXzep92Vi+BrxGw+Ysq1Ta
	HaLiHIvb/1Mb0zlXPKFvDG6X6Up6LcDZxGwfzXaiek9RgavuDb6rRsEKXgMoTyKP+d2p
	/jGk/5asVi13WN6FH22Zc6rlbijWR+NLUYcTGnYId1aCHmwVE2agH1F0Q++gdpdFCxPN
	BYtQ==
X-Gm-Message-State: ALoCoQnk/j4AsWlFg+s5IqyK5ixCG/Tz2lRYdS+z0r41YiAhCgj6ta2KWSmMRaiB+Huv5yoHzF5l
X-Received: by 10.180.8.193 with SMTP id t1mr9239297wia.15.1415982961479;
	Fri, 14 Nov 2014 08:36:01 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fl1sm4020547wib.15.2014.11.14.08.36.00
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 14 Nov 2014 08:36:00 -0800 (PST)
Message-ID: <54662F69.8060700@linaro.org>
Date: Fri, 14 Nov 2014 16:35:53 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
In-Reply-To: <CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 04:22 PM, Andrii Tseglytskyi wrote:
> On Fri, Nov 14, 2014 at 6:15 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>>> On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>>>>> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
>>>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>>>> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I observe system freeze on latest xen/master branch.
>>>>>>>
>>>>>>> My setup is:
>>>>>>>
>>>>>>> - Jacinto 6 evm board (OMAP5)
>>>>>>> - Latest Xen 4.5.0-rc2 as hypervisor
>>>>>>> - Linux 3.8 as dom0, running on 2 vcpus
>>>>>>> - Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
>>>>>>> - XSM feature is disabled
>>>>>>> - gcc version 4.7.3 20130328 (prerelease) (crosstool-NG
>>>>>>> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) as cross
>>>>>>> compiler
>>>>>>>
>>>>>>> Freeze occurs in random moment of time during creation of domU domain.
>>>>>>> Even Xen console may be not available after freeze.
>>>>>>> Can someone suggest - what it can be? Maybe some weak places in new
>>>>>>> code? Maybe new gic, which was reworked a lot or something else?
>>>>>>>
>>>>>>> Thank you in advance for any suggestions.
>>>>>>
>>>>>> Is this really 3.8 or 3.18?
>>>>>
>>>>> We have 3.8 in both dom0 and domU
>>>>>
>>>>>> 3.8 is pretty old and doesn't have any of
>>>>>> the fixes to be able to safely do dma involving guest pages to
>>>>>> non-coherent devices.
>>>>>
>>>>> This is a good point. Now we are migrating to 3.12 kernel in dom0. But
>>>>> Android will remain on 3.8. Will it help ?
>>>>> Maybe you can point me to any tree with proper DMA fixes? Note: if you
>>>>> are talking about SWIOTLB - we have your latest one, retrieved from
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
>>>>> branch:swiotlb-xen-9.1
>>>>
>>>> The last and most stable series is:
>>>>
>>>> http://marc.info/?l=linux-kernel&m=141579241729749&w=2
>>>>
>>>
>>> Thanks  - I'll try this series anyway.
>>>
>>>> But thinking more about this, I doubt that it is a dma problem, because
>>>> you would most probably see various kind of error messages, not a
>>>> freeze.
>>>>
>>>
>>> Agree.
>>>
>>>>
>>>>>> Where are you storing the guest disk images?
>>>>>
>>>>> SATA drive, dedicated to dom0, its controller has its own DMA
>>>>
>>>> Are they on file or on lvm volumes?
>>>
>>> Images are on file.
>>>
>>> Also note - freeze depends on system load. It reproduces more
>>> frequently if I start Android + QNX + all frontends/backends drivers.
>>> Starting Android only without any addition drivers works more less
>>> stable. It looks like issue is reproduced when domU starts in parallel
>>> with backends drivers in dom0.
>>> But the same works fine with old Xen 4.4.
>>
>> In my experience freezes like the one you are describing are due to
>> interrupt related bugs or deadlocks. Both of them are hard to track
>> down. If you can reproduce it reliably maybe you could bisect it.
> 
> Agree. I suspect that new gic series impacts on this. In very few
> moments when xen console is available after freeze I see that dom0
> code stacks around kernel lock_release() or  handle_IPI() functions

I would be surprised that the next GIC series impact this code as the
next driver is only compiled for arm64 (GICv3 doesn't exist on arm32).
Though, there was some refactoring.

The interrupt management has also been reworked for Xen 4.5 to avoid
maintenance interrupt. I would give a look on this part.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:36:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:36:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJrU-0003av-0o; Fri, 14 Nov 2014 16:36:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpJrT-0003ai-9j
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 16:36:39 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	C2/FA-08051-69F26645; Fri, 14 Nov 2014 16:36:38 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415982995!9311940!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4641 invoked from network); 14 Nov 2014 16:36:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:36:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192917201"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:36:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpJrK-00044B-1W;
	Fri, 14 Nov 2014 16:36:30 +0000
Date: Fri, 14 Nov 2014 16:36:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141114155039.GF5364@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411141634480.26318@kaball.uk.xensource.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
	<alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
	<20141114155039.GF5364@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, mst@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	aliguori@amazon.com, qemu-devel@nongun.org,
	Igor Mammedov <imammedo@redhat.com>, liang.z.li@intel.com, rth@twiddle.net
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
 running 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 Fri, 14 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 01:57:21PM +0000, Stefano Stabellini wrote:
> > Konrad,
> > this is another bug fix for QEMU: pci hotplug doesn't work when
> > xen_platform_pci=0 without this.
> 
> Yes.
> > 
> > I think we should have it in 4.5. What do you think?
> 
> Do you believe we should first get an Tested-by from the Intel QA folks?
 
Liang at Intel was the one to fix and resend. Liang, could you please
test this patch on qemu-xen on xen-unstable? Thanks!


> Thanks.
> > 
> > - Stefano
> > 
> > On Thu, 13 Nov 2014, Paolo Bonzini wrote:
> > > On 13/11/2014 03:30, Li Liang wrote:
> > > > If user starts QEMU with "-machine pc,accel=xen", then
> > > > compat property in xenfv won't work and it would cause error:
> > > > "Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set"
> > > > when PCI device is added with -device on QEMU CLI.
> > > > 
> > > > In case of Xen instead of using compat property, just use the fact
> > > > that xen doesn't use QEMU's fw_cfg/acpi tables to switch piix4_pm
> > > > into legacy PCI hotplug mode when Xen is enabled.
> > > > 
> > > > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > > > [liang.z.li@intel.com: use "xen_enabled()" instead of "!fw_cfg"]
> > > > Signed-off-by: Li Liang <liang.z.li@intel.com>
> > > > ---
> > > >  hw/acpi/piix4.c   |  4 ++++
> > > >  hw/i386/pc_piix.c | 11 -----------
> > > >  2 files changed, 4 insertions(+), 11 deletions(-)
> > > > 
> > > > diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> > > > index 78c0a6d..481a16c 100644
> > > > --- a/hw/acpi/piix4.c
> > > > +++ b/hw/acpi/piix4.c
> > > > @@ -36,6 +36,7 @@
> > > >  #include "hw/mem/pc-dimm.h"
> > > >  #include "hw/acpi/memory_hotplug.h"
> > > >  #include "hw/acpi/acpi_dev_interface.h"
> > > > +#include "hw/xen/xen.h"
> > > >  
> > > >  //#define DEBUG
> > > >  
> > > > @@ -501,6 +502,9 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
> > > >      s->irq = sci_irq;
> > > >      s->smi_irq = smi_irq;
> > > >      s->kvm_enabled = kvm_enabled;
> > > > +    if (xen_enabled()) {
> > > > +        s->use_acpi_pci_hotplug = false;
> > > > +    }
> > > >  
> > > >      qdev_init_nofail(dev);
> > > >  
> > > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > > > index b559181..7bb97a4 100644
> > > > --- a/hw/i386/pc_piix.c
> > > > +++ b/hw/i386/pc_piix.c
> > > > @@ -916,17 +916,6 @@ static QEMUMachine xenfv_machine = {
> > > >      .max_cpus = HVM_MAX_VCPUS,
> > > >      .default_machine_opts = "accel=xen",
> > > >      .hot_add_cpu = pc_hot_add_cpu,
> > > > -    .compat_props = (GlobalProperty[]) {
> > > > -        /* xenfv has no fwcfg and so does not load acpi from QEMU.
> > > > -         * as such new acpi features don't work.
> > > > -         */
> > > > -        {
> > > > -            .driver   = "PIIX4_PM",
> > > > -            .property = "acpi-pci-hotplug-with-bridge-support",
> > > > -            .value    = "off",
> > > > -        },
> > > > -        { /* end of list */ }
> > > > -    },
> > > >  };
> > > >  #endif
> > > >  
> > > > 
> > > 
> > > Acked-by: Paolo Bonzini <pbonzini@redhat.com>
> > > 
> > > Stefano, are you going to send the pull request yourself?
> > > 
> > > Paolo
> > > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:36:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:36:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJrU-0003av-0o; Fri, 14 Nov 2014 16:36:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XpJrT-0003ai-9j
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 16:36:39 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	C2/FA-08051-69F26645; Fri, 14 Nov 2014 16:36:38 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415982995!9311940!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4641 invoked from network); 14 Nov 2014 16:36:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:36:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192917201"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:36:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XpJrK-00044B-1W;
	Fri, 14 Nov 2014 16:36:30 +0000
Date: Fri, 14 Nov 2014 16:36:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141114155039.GF5364@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411141634480.26318@kaball.uk.xensource.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
	<alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
	<20141114155039.GF5364@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, mst@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	aliguori@amazon.com, qemu-devel@nongun.org,
	Igor Mammedov <imammedo@redhat.com>, liang.z.li@intel.com, rth@twiddle.net
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
 running 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 Fri, 14 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 01:57:21PM +0000, Stefano Stabellini wrote:
> > Konrad,
> > this is another bug fix for QEMU: pci hotplug doesn't work when
> > xen_platform_pci=0 without this.
> 
> Yes.
> > 
> > I think we should have it in 4.5. What do you think?
> 
> Do you believe we should first get an Tested-by from the Intel QA folks?
 
Liang at Intel was the one to fix and resend. Liang, could you please
test this patch on qemu-xen on xen-unstable? Thanks!


> Thanks.
> > 
> > - Stefano
> > 
> > On Thu, 13 Nov 2014, Paolo Bonzini wrote:
> > > On 13/11/2014 03:30, Li Liang wrote:
> > > > If user starts QEMU with "-machine pc,accel=xen", then
> > > > compat property in xenfv won't work and it would cause error:
> > > > "Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set"
> > > > when PCI device is added with -device on QEMU CLI.
> > > > 
> > > > In case of Xen instead of using compat property, just use the fact
> > > > that xen doesn't use QEMU's fw_cfg/acpi tables to switch piix4_pm
> > > > into legacy PCI hotplug mode when Xen is enabled.
> > > > 
> > > > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > > > [liang.z.li@intel.com: use "xen_enabled()" instead of "!fw_cfg"]
> > > > Signed-off-by: Li Liang <liang.z.li@intel.com>
> > > > ---
> > > >  hw/acpi/piix4.c   |  4 ++++
> > > >  hw/i386/pc_piix.c | 11 -----------
> > > >  2 files changed, 4 insertions(+), 11 deletions(-)
> > > > 
> > > > diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> > > > index 78c0a6d..481a16c 100644
> > > > --- a/hw/acpi/piix4.c
> > > > +++ b/hw/acpi/piix4.c
> > > > @@ -36,6 +36,7 @@
> > > >  #include "hw/mem/pc-dimm.h"
> > > >  #include "hw/acpi/memory_hotplug.h"
> > > >  #include "hw/acpi/acpi_dev_interface.h"
> > > > +#include "hw/xen/xen.h"
> > > >  
> > > >  //#define DEBUG
> > > >  
> > > > @@ -501,6 +502,9 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
> > > >      s->irq = sci_irq;
> > > >      s->smi_irq = smi_irq;
> > > >      s->kvm_enabled = kvm_enabled;
> > > > +    if (xen_enabled()) {
> > > > +        s->use_acpi_pci_hotplug = false;
> > > > +    }
> > > >  
> > > >      qdev_init_nofail(dev);
> > > >  
> > > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > > > index b559181..7bb97a4 100644
> > > > --- a/hw/i386/pc_piix.c
> > > > +++ b/hw/i386/pc_piix.c
> > > > @@ -916,17 +916,6 @@ static QEMUMachine xenfv_machine = {
> > > >      .max_cpus = HVM_MAX_VCPUS,
> > > >      .default_machine_opts = "accel=xen",
> > > >      .hot_add_cpu = pc_hot_add_cpu,
> > > > -    .compat_props = (GlobalProperty[]) {
> > > > -        /* xenfv has no fwcfg and so does not load acpi from QEMU.
> > > > -         * as such new acpi features don't work.
> > > > -         */
> > > > -        {
> > > > -            .driver   = "PIIX4_PM",
> > > > -            .property = "acpi-pci-hotplug-with-bridge-support",
> > > > -            .value    = "off",
> > > > -        },
> > > > -        { /* end of list */ }
> > > > -    },
> > > >  };
> > > >  #endif
> > > >  
> > > > 
> > > 
> > > Acked-by: Paolo Bonzini <pbonzini@redhat.com>
> > > 
> > > Stefano, are you going to send the pull request yourself?
> > > 
> > > Paolo
> > > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:37:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:37:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJsP-0003jX-F8; Fri, 14 Nov 2014 16:37:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpJsO-0003jJ-Ep
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:37:36 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	3E/40-22819-FCF26645; Fri, 14 Nov 2014 16:37:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415983055!11463382!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16266 invoked from network); 14 Nov 2014 16:37:35 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:37:35 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 16:37:34 +0000
Message-Id: <54663DDE0200007800047D7E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 16:37:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
	<1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
	<54662A360200007800047BDB@mail.emea.novell.com>
	<20141114161146.GG5364@laptop.dumpdata.com>
In-Reply-To: <20141114161146.GG5364@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, linux@eikelenboom.it,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet
 with an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 17:11, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 14, 2014 at 03:13:42PM +0000, Jan Beulich wrote:
>> >>> On 12.11.14 at 03:23, <konrad.wilk@oracle.com> wrote:
>> > +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
>> > +{
>> > +    struct domain *d = pirq_dpci->dom;
>> > +
>> > +    ASSERT(spin_is_locked(&d->event_lock));
>> > +
>> > +    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
>> > +    {
>> > +    case (1 << STATE_SCHED):
>> > +        /*
>> > +         * We are going to try to de-schedule the softirq before it goes in
>> > +         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
>> > +         */
>> > +        put_domain(d);
>> > +        /* fallthrough. */
>> 
>> Considering Sander's report, the only suspicious place I find is this
>> one: When the STATE_SCHED flag is set, pirq_dpci is on some
>> CPU's list. What guarantees it to get removed from that list before
>> getting inserted on another one?
> 
> None. The moment that STATE_SCHED is cleared, 'raise_softirq_for'
> is free to manipulate the list.
> 
> We could:
>  - Add another bit, say STATE_ZOMBIE - which pt_pirq_softirq_reset could
>    set, and dpci_softirq - if it sees it - would clear. Said bit
>    would stop 'raise_softirq_for' from trying to do anything.

Pretty ugly. I guess I'll have to think about this some more early
next week, unless you or someone else has an idea for a less
convoluted solution. And I'm not at all certain this is what is
causing Sander's issue (that's why I asked whether the guests
were booting or shutting down, which he said they weren't), as
it was my understanding so far that this reset mechanism would
come into play only when tearing down guest IRQs. I.e. handing
him a debugging patch to understand what's going on might be
the better first step 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 Nov 14 16:37:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:37:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJsP-0003jX-F8; Fri, 14 Nov 2014 16:37:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XpJsO-0003jJ-Ep
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:37:36 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	3E/40-22819-FCF26645; Fri, 14 Nov 2014 16:37:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1415983055!11463382!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16266 invoked from network); 14 Nov 2014 16:37:35 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:37:35 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 14 Nov 2014 16:37:34 +0000
Message-Id: <54663DDE0200007800047D7E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 14 Nov 2014 16:37:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
	<1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
	<54662A360200007800047BDB@mail.emea.novell.com>
	<20141114161146.GG5364@laptop.dumpdata.com>
In-Reply-To: <20141114161146.GG5364@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, linux@eikelenboom.it,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet
 with an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 17:11, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 14, 2014 at 03:13:42PM +0000, Jan Beulich wrote:
>> >>> On 12.11.14 at 03:23, <konrad.wilk@oracle.com> wrote:
>> > +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
>> > +{
>> > +    struct domain *d = pirq_dpci->dom;
>> > +
>> > +    ASSERT(spin_is_locked(&d->event_lock));
>> > +
>> > +    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
>> > +    {
>> > +    case (1 << STATE_SCHED):
>> > +        /*
>> > +         * We are going to try to de-schedule the softirq before it goes in
>> > +         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
>> > +         */
>> > +        put_domain(d);
>> > +        /* fallthrough. */
>> 
>> Considering Sander's report, the only suspicious place I find is this
>> one: When the STATE_SCHED flag is set, pirq_dpci is on some
>> CPU's list. What guarantees it to get removed from that list before
>> getting inserted on another one?
> 
> None. The moment that STATE_SCHED is cleared, 'raise_softirq_for'
> is free to manipulate the list.
> 
> We could:
>  - Add another bit, say STATE_ZOMBIE - which pt_pirq_softirq_reset could
>    set, and dpci_softirq - if it sees it - would clear. Said bit
>    would stop 'raise_softirq_for' from trying to do anything.

Pretty ugly. I guess I'll have to think about this some more early
next week, unless you or someone else has an idea for a less
convoluted solution. And I'm not at all certain this is what is
causing Sander's issue (that's why I asked whether the guests
were booting or shutting down, which he said they weren't), as
it was my understanding so far that this reset mechanism would
come into play only when tearing down guest IRQs. I.e. handing
him a debugging patch to understand what's going on might be
the better first step 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 Nov 14 16:38:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:38:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJss-0003oy-Sg; Fri, 14 Nov 2014 16:38:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpJsr-0003oc-AV
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:38:05 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	87/9C-02699-CEF26645; Fri, 14 Nov 2014 16:38:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415983080!12632715!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4376 invoked from network); 14 Nov 2014 16:38:03 -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;
	14 Nov 2014 16:38:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192917617"
Message-ID: <1415983042.7113.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 16:37:22 +0000
In-Reply-To: <21604.55638.693745.459883@mariner.uk.xensource.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415788588.25176.56.camel@citrix.com>
	<21604.55638.693745.459883@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/9] Host allocation scoring
	improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 16:16 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [OSSTEST PATCH 0/9] Host allocation scoring improvements"):
> > On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> > > Here, I'm trying to fix the way that osstest gets far too obsessed
> > > about particular failing hosts.
> > 
> > All fine by me, not that I've really grokked the bits towards the end.
> > (I will try to if you want)
> 
> I find this area a bit confusing, and it's a right bastard to test, so
> if you have the bandwidth for a proper review that would be great.

These:
[OSSTEST PATCH 1/9] cs-adjust-flight: Fix doc about /<pcre> to match implementation
[OSSTEST PATCH 2/9] ts-hosts-allocate-Executive: allow uncompressed log
[OSSTEST PATCH 3/9] Osstest/Executive.pm: Debug log same-host status (in duration estimator)
[OSSTEST PATCH 4/9] ts-hosts-allocate-Executive: Move $variation_age setting
[OSSTEST PATCH 5/9] ts-hosts-allocate-Executive: Do not prefer fast hosts for tests
[OSSTEST PATCH 6/9] ts-hosts-allocate-Executive: Clarify an expression with //

Are:
        Acked-by: Ian Campbell <ian.campbell@citrix.com>
        
I'll try and grok the rest now and reply to them individually.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:38:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:38:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpJss-0003oy-Sg; Fri, 14 Nov 2014 16:38:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpJsr-0003oc-AV
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:38:05 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	87/9C-02699-CEF26645; Fri, 14 Nov 2014 16:38:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415983080!12632715!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4376 invoked from network); 14 Nov 2014 16:38:03 -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;
	14 Nov 2014 16:38:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192917617"
Message-ID: <1415983042.7113.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 16:37:22 +0000
In-Reply-To: <21604.55638.693745.459883@mariner.uk.xensource.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415788588.25176.56.camel@citrix.com>
	<21604.55638.693745.459883@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/9] Host allocation scoring
	improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-13 at 16:16 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [OSSTEST PATCH 0/9] Host allocation scoring improvements"):
> > On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> > > Here, I'm trying to fix the way that osstest gets far too obsessed
> > > about particular failing hosts.
> > 
> > All fine by me, not that I've really grokked the bits towards the end.
> > (I will try to if you want)
> 
> I find this area a bit confusing, and it's a right bastard to test, so
> if you have the bandwidth for a proper review that would be great.

These:
[OSSTEST PATCH 1/9] cs-adjust-flight: Fix doc about /<pcre> to match implementation
[OSSTEST PATCH 2/9] ts-hosts-allocate-Executive: allow uncompressed log
[OSSTEST PATCH 3/9] Osstest/Executive.pm: Debug log same-host status (in duration estimator)
[OSSTEST PATCH 4/9] ts-hosts-allocate-Executive: Move $variation_age setting
[OSSTEST PATCH 5/9] ts-hosts-allocate-Executive: Do not prefer fast hosts for tests
[OSSTEST PATCH 6/9] ts-hosts-allocate-Executive: Clarify an expression with //

Are:
        Acked-by: Ian Campbell <ian.campbell@citrix.com>
        
I'll try and grok the rest now and reply to them individually.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:40:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJv2-000460-Ki; Fri, 14 Nov 2014 16:40:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpJv1-00045q-8Q
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:40:19 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	9A/D8-11608-27036645; Fri, 14 Nov 2014 16:40:18 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415983215!9045622!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24528 invoked from network); 14 Nov 2014 16:40:17 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:40:17 -0000
Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYwb6paCadvR/8/MVZvrFgeTj+gjSwo@postini.com;
	Fri, 14 Nov 2014 08:40:17 PST
Received: by mail-qa0-f45.google.com with SMTP id dc16so11888542qab.18
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 08:40:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=colTccUYmPg+a7B+IQDnTVw04E93q+CDE/dBUSi8Y0Q=;
	b=DOn6YHLOssziRuG4wNFY0nbLQKLA72lfrYYm/9l2HPre2u327cxbrXfWGmhm0OljJc
	W6WPIiCyxJ75yJaQt7vi6XKs9586RWIzbZnl4eFTYlJk8ak2kdSLxRDMCGAhSsgorebw
	rt2r6asN6KYJC67hOaTnx6YPRjKaYuZYgM7xA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=colTccUYmPg+a7B+IQDnTVw04E93q+CDE/dBUSi8Y0Q=;
	b=JjMFKBwflegtw7K917kaby37gVF9i1PM3cCYnHvz9D4kBiQzrw2u/QX+CqpNmK526i
	stA/0taaCpuiZOoqoXcwDX1L/vRmCMpxzON5cw8MsFgEUNPvoPZvIBqItz64zcgWQDVE
	tiztuRgXYf+Vdv4XV0Hb7aEZ7/yF+vIBg0+w1PBXGXsLJlf07y8Q2Wyt/uUaONQS5gI1
	4S7kW2C+uf0mVF6LONaS36z12y0XM+C92cYcIbBsOi8F0Q6X88FMJAbR1pJU/tvhr9vS
	6sD1XDNZ9NznM9kPnivrvr+GtZYPLzA8/OGIntVMknWtm434nBqSkCF3NHek/ids5K6G
	a3nQ==
X-Gm-Message-State: ALoCoQkOl7E8FGdkpqDsyaRrZPFWiljEzfVGiH5VM1dCOALEQ75AeLf+lZ/2CGmlfP5Km18QkdBGvSSOffReWDKhjhafie7R+RsLH5AdHgC81MRLCXlbeT7Hx7/GQOrvBU9A1j//jy1orXpzzs//mO69zdC3+GtIHw==
X-Received: by 10.224.92.81 with SMTP id q17mr12500894qam.66.1415983214928;
	Fri, 14 Nov 2014 08:40:14 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.92.81 with SMTP id q17mr12500881qam.66.1415983214795;
	Fri, 14 Nov 2014 08:40:14 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 08:40:14 -0800 (PST)
In-Reply-To: <54662F69.8060700@linaro.org>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
Date: Fri, 14 Nov 2014 18:40:14 +0200
Message-ID: <CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Julien,

> I would be surprised that the next GIC series impact this code as the
> next driver is only compiled for arm64 (GICv3 doesn't exist on arm32).
> Though, there was some refactoring.

I meant that code was divided for generic GIC and GICv2 together with
refactoring. Also in mails I saw that it was initially tested without
SMP.
GICv3 has no impacts for sure.

>
> The interrupt management has also been reworked for Xen 4.5 to avoid
> maintenance interrupt. I would give a look on this part.

Thanks, this may help.

Regards,
Andrii


>
> Regards,
>
> --
> Julien Grall



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:40:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpJv2-000460-Ki; Fri, 14 Nov 2014 16:40:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XpJv1-00045q-8Q
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:40:19 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	9A/D8-11608-27036645; Fri, 14 Nov 2014 16:40:18 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415983215!9045622!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24528 invoked from network); 14 Nov 2014 16:40:17 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:40:17 -0000
Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGYwb6paCadvR/8/MVZvrFgeTj+gjSwo@postini.com;
	Fri, 14 Nov 2014 08:40:17 PST
Received: by mail-qa0-f45.google.com with SMTP id dc16so11888542qab.18
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 08:40:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=colTccUYmPg+a7B+IQDnTVw04E93q+CDE/dBUSi8Y0Q=;
	b=DOn6YHLOssziRuG4wNFY0nbLQKLA72lfrYYm/9l2HPre2u327cxbrXfWGmhm0OljJc
	W6WPIiCyxJ75yJaQt7vi6XKs9586RWIzbZnl4eFTYlJk8ak2kdSLxRDMCGAhSsgorebw
	rt2r6asN6KYJC67hOaTnx6YPRjKaYuZYgM7xA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=colTccUYmPg+a7B+IQDnTVw04E93q+CDE/dBUSi8Y0Q=;
	b=JjMFKBwflegtw7K917kaby37gVF9i1PM3cCYnHvz9D4kBiQzrw2u/QX+CqpNmK526i
	stA/0taaCpuiZOoqoXcwDX1L/vRmCMpxzON5cw8MsFgEUNPvoPZvIBqItz64zcgWQDVE
	tiztuRgXYf+Vdv4XV0Hb7aEZ7/yF+vIBg0+w1PBXGXsLJlf07y8Q2Wyt/uUaONQS5gI1
	4S7kW2C+uf0mVF6LONaS36z12y0XM+C92cYcIbBsOi8F0Q6X88FMJAbR1pJU/tvhr9vS
	6sD1XDNZ9NznM9kPnivrvr+GtZYPLzA8/OGIntVMknWtm434nBqSkCF3NHek/ids5K6G
	a3nQ==
X-Gm-Message-State: ALoCoQkOl7E8FGdkpqDsyaRrZPFWiljEzfVGiH5VM1dCOALEQ75AeLf+lZ/2CGmlfP5Km18QkdBGvSSOffReWDKhjhafie7R+RsLH5AdHgC81MRLCXlbeT7Hx7/GQOrvBU9A1j//jy1orXpzzs//mO69zdC3+GtIHw==
X-Received: by 10.224.92.81 with SMTP id q17mr12500894qam.66.1415983214928;
	Fri, 14 Nov 2014 08:40:14 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.92.81 with SMTP id q17mr12500881qam.66.1415983214795;
	Fri, 14 Nov 2014 08:40:14 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Fri, 14 Nov 2014 08:40:14 -0800 (PST)
In-Reply-To: <54662F69.8060700@linaro.org>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
Date: Fri, 14 Nov 2014 18:40:14 +0200
Message-ID: <CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Julien,

> I would be surprised that the next GIC series impact this code as the
> next driver is only compiled for arm64 (GICv3 doesn't exist on arm32).
> Though, there was some refactoring.

I meant that code was divided for generic GIC and GICv2 together with
refactoring. Also in mails I saw that it was initially tested without
SMP.
GICv3 has no impacts for sure.

>
> The interrupt management has also been reworked for Xen 4.5 to avoid
> maintenance interrupt. I would give a look on this part.

Thanks, this may help.

Regards,
Andrii


>
> Regards,
>
> --
> Julien Grall



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:48:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpK2V-0004aT-KD; Fri, 14 Nov 2014 16:48:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpK2U-0004aO-3J
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 16:48:02 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	16/23-02696-14236645; Fri, 14 Nov 2014 16:48:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415983679!12650957!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6329 invoked from network); 14 Nov 2014 16:48:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:48:00 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGlkv3008927
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:47:47 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEGljRv023812
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Nov 2014 16:47:46 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAEGlhQO023753; Fri, 14 Nov 2014 16:47:44 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:47:43 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 07F53116685; Fri, 14 Nov 2014 11:47:41 -0500 (EST)
Date: Fri, 14 Nov 2014 11:47:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141114164741.GA8198@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
	<20141113195605.GA13039@laptop.dumpdata.com>
	<54658ABF.5050708@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54658ABF.5050708@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 05:53:19AM +0100, Juergen Gross wrote:
> On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
> >>>>+	mfn_save = virt_to_mfn(buf);
> >>>>+
> >>>>+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
> >>>
> >>>So the 'list' is constructed by going forward - that is from low-numbered
> >>>PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
> >>>other way - from the highest PFN to the lowest PFN.
> >>>
> >>>Won't that mean we will restore the chunks of memory in the wrong
> >>>order? That is we will still restore them in chunks size, but the
> >>>chunks will be in descending order instead of ascending?
> >>
> >>No, the information where to put each chunk is contained in the chunk
> >>data. I can add a comment explaining this.
> >
> >Right, the MFNs in a "chunks" are going to be restored in the right order.
> >
> >I was thinking that the "chunks" (so a set of MFNs) will be restored in
> >the opposite order that they are written to.
> >
> >And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?
> 
> More don't fit on a single page due to the other info needed. So: yes.

But you could use two pages - one for the structure and the other
for the list of MFNs. That would fix the problem of having only
509 MFNs being contingous per chunk when restoring.

Anyhow the point I had that I am worried is that we do not restore the
MFNs in the same order. We do it in "chunk" size which is OK (so the 509 MFNs
at once)- but the order we traverse the restoration process is the opposite of
the save process. Say we have 4MB of contingous MFNs, so two (err, three)
chunks. The first one we iterate is from 0->509, the second is 510->1018, the
last is 1019->1023. When we restore (remap) we start with the last 'chunk'
so we end up restoring them: 1019->1023, 510->1018, 0->509 order.

If we go with using two pages - one for the structure and one for the
list of PFNs, we could expand the structure to have an 'next' and 'prev'
MFN. When you then traverse in 'xen_remap_memory' you could do:

mfn = xen_remap_mfn;
while (mfn != INVALID_P2M_ENTRY) {
	xen_remap_mfn = mfn;
	set_pte_mfn(buf, mfn, PAGE_KERNEL);
	mfn = xen_remap_buf.next_area_mfn;
}

And then you can start from this updated xen_remap_mfn which will
start with the first chunk that has been set. Thought at this point
it does not matter whether we have a seperate page for the MFNs as
the restoration/remap process will put them in the save order
that they were saved.

> 
> >
> >>
> >>>
> >>>>+		/* Map the remap information */
> >>>>+		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
> >>>>+
> >>>>+		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
> >>>>+
> >>>>+		free = 0;
> >>>>+		pfn = xen_remap_buf.target_pfn;
> >>>>+		for (i = 0; i < xen_remap_buf.size; i++) {
> >>>>+			mfn = xen_remap_buf.mfns[i];
> >>>>+			if (!released && xen_update_mem_tables(pfn, mfn)) {
> >>>>+				remapped++;
> >>>
> >>>If we fail 'xen_update_mem_tables' we will on the next chunk (so i+1) keep on
> >>>freeing pages instead of trying to remap. Is that intentional? Could we
> >>>try to remap?
> >>
> >>Hmm, I'm not sure this is worth the effort. What could lead to failure
> >>here? I suspect we could even just BUG() on failure. What do you think?
> >
> >I was hoping that this question would lead to making this loop a bit
> >simpler as you would have to spread some of the code in the loop
> >into functions.
> >
> >And keep 'remmaped' and 'released' reset every loop.
> >
> >However, if it makes the code more complex - then please
> >forget my question.
> 
> Using BUG() instead would make the code less complex. Do you really
> think xen_update_mem_tables() would ever fail in a sane system?
> 
> - set_phys_to_machine() would fail only on a memory shortage. Just
>   going on without adding more memory wouldn't lead to a healthy system,
>   I think.
> - The hypervisor calls would fail only in case of parameter errors.
>   This should never happen, so dying seems to be the correct reaction.
> 
> David, what do you think?
> 
> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:48:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpK2V-0004aT-KD; Fri, 14 Nov 2014 16:48:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpK2U-0004aO-3J
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 16:48:02 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	16/23-02696-14236645; Fri, 14 Nov 2014 16:48:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1415983679!12650957!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6329 invoked from network); 14 Nov 2014 16:48:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 16:48:00 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGlkv3008927
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:47:47 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEGljRv023812
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Nov 2014 16:47:46 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAEGlhQO023753; Fri, 14 Nov 2014 16:47:44 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:47:43 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 07F53116685; Fri, 14 Nov 2014 11:47:41 -0500 (EST)
Date: Fri, 14 Nov 2014 11:47:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141114164741.GA8198@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
	<20141113195605.GA13039@laptop.dumpdata.com>
	<54658ABF.5050708@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54658ABF.5050708@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 05:53:19AM +0100, Juergen Gross wrote:
> On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
> >>>>+	mfn_save = virt_to_mfn(buf);
> >>>>+
> >>>>+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
> >>>
> >>>So the 'list' is constructed by going forward - that is from low-numbered
> >>>PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
> >>>other way - from the highest PFN to the lowest PFN.
> >>>
> >>>Won't that mean we will restore the chunks of memory in the wrong
> >>>order? That is we will still restore them in chunks size, but the
> >>>chunks will be in descending order instead of ascending?
> >>
> >>No, the information where to put each chunk is contained in the chunk
> >>data. I can add a comment explaining this.
> >
> >Right, the MFNs in a "chunks" are going to be restored in the right order.
> >
> >I was thinking that the "chunks" (so a set of MFNs) will be restored in
> >the opposite order that they are written to.
> >
> >And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?
> 
> More don't fit on a single page due to the other info needed. So: yes.

But you could use two pages - one for the structure and the other
for the list of MFNs. That would fix the problem of having only
509 MFNs being contingous per chunk when restoring.

Anyhow the point I had that I am worried is that we do not restore the
MFNs in the same order. We do it in "chunk" size which is OK (so the 509 MFNs
at once)- but the order we traverse the restoration process is the opposite of
the save process. Say we have 4MB of contingous MFNs, so two (err, three)
chunks. The first one we iterate is from 0->509, the second is 510->1018, the
last is 1019->1023. When we restore (remap) we start with the last 'chunk'
so we end up restoring them: 1019->1023, 510->1018, 0->509 order.

If we go with using two pages - one for the structure and one for the
list of PFNs, we could expand the structure to have an 'next' and 'prev'
MFN. When you then traverse in 'xen_remap_memory' you could do:

mfn = xen_remap_mfn;
while (mfn != INVALID_P2M_ENTRY) {
	xen_remap_mfn = mfn;
	set_pte_mfn(buf, mfn, PAGE_KERNEL);
	mfn = xen_remap_buf.next_area_mfn;
}

And then you can start from this updated xen_remap_mfn which will
start with the first chunk that has been set. Thought at this point
it does not matter whether we have a seperate page for the MFNs as
the restoration/remap process will put them in the save order
that they were saved.

> 
> >
> >>
> >>>
> >>>>+		/* Map the remap information */
> >>>>+		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
> >>>>+
> >>>>+		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
> >>>>+
> >>>>+		free = 0;
> >>>>+		pfn = xen_remap_buf.target_pfn;
> >>>>+		for (i = 0; i < xen_remap_buf.size; i++) {
> >>>>+			mfn = xen_remap_buf.mfns[i];
> >>>>+			if (!released && xen_update_mem_tables(pfn, mfn)) {
> >>>>+				remapped++;
> >>>
> >>>If we fail 'xen_update_mem_tables' we will on the next chunk (so i+1) keep on
> >>>freeing pages instead of trying to remap. Is that intentional? Could we
> >>>try to remap?
> >>
> >>Hmm, I'm not sure this is worth the effort. What could lead to failure
> >>here? I suspect we could even just BUG() on failure. What do you think?
> >
> >I was hoping that this question would lead to making this loop a bit
> >simpler as you would have to spread some of the code in the loop
> >into functions.
> >
> >And keep 'remmaped' and 'released' reset every loop.
> >
> >However, if it makes the code more complex - then please
> >forget my question.
> 
> Using BUG() instead would make the code less complex. Do you really
> think xen_update_mem_tables() would ever fail in a sane system?
> 
> - set_phys_to_machine() would fail only on a memory shortage. Just
>   going on without adding more memory wouldn't lead to a healthy system,
>   I think.
> - The hypervisor calls would fail only in case of parameter errors.
>   This should never happen, so dying seems to be the correct reaction.
> 
> David, what do you think?
> 
> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:50:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpK54-0004gg-6E; Fri, 14 Nov 2014 16:50:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpK52-0004ga-TX
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:50:41 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	08/AB-02699-0E236645; Fri, 14 Nov 2014 16:50:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415983838!12633516!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22413 invoked from network); 14 Nov 2014 16:50:39 -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;
	14 Nov 2014 16:50:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192923143"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:50:37 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpK4z-0004NR-8m;
	Fri, 14 Nov 2014 16:50:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJra-00022q-Sg;
	Fri, 14 Nov 2014 16:36:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.12190.531985.105109@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 16:36:46 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54662FBD.1010605@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<54662FBD.1010605@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> On 11/14/2014 11:31 AM, Ian Jackson wrote:
> > `goto skip1' only appears in the PV path AFAICT.
> 
> Right, this is all about PV code path.

So now I am confused.  Why is qemu involved ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:50:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpK54-0004gg-6E; Fri, 14 Nov 2014 16:50:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpK52-0004ga-TX
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:50:41 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	08/AB-02699-0E236645; Fri, 14 Nov 2014 16:50:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1415983838!12633516!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22413 invoked from network); 14 Nov 2014 16:50:39 -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;
	14 Nov 2014 16:50:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192923143"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 11:50:37 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpK4z-0004NR-8m;
	Fri, 14 Nov 2014 16:50:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpJra-00022q-Sg;
	Fri, 14 Nov 2014 16:36:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.12190.531985.105109@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 16:36:46 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54662FBD.1010605@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<54662FBD.1010605@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> On 11/14/2014 11:31 AM, Ian Jackson wrote:
> > `goto skip1' only appears in the PV path AFAICT.
> 
> Right, this is all about PV code path.

So now I am confused.  Why is qemu involved ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:55:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:55:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpK9z-0005A1-Uy; Fri, 14 Nov 2014 16:55:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpK9y-00059w-7M
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:55:46 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	C7/72-01660-11436645; Fri, 14 Nov 2014 16:55:45 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415984143!6064327!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26532 invoked from network); 14 Nov 2014 16:55:44 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 16:55:44 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGtbtZ019533
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:55:38 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGtbLu019018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:55:37 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGtaw3020517; Fri, 14 Nov 2014 16:55:36 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:55:36 -0800
Message-ID: <546634A3.6060005@oracle.com>
Date: Fri, 14 Nov 2014 11:58:11 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>	<21606.5282.659930.728522@mariner.uk.xensource.com>	<54662004.6050702@oracle.com>	<21606.10103.850619.644934@mariner.uk.xensource.com>	<54662CB1.2050505@oracle.com>	<21606.11847.373254.124439@mariner.uk.xensource.com>	<54662FBD.1010605@oracle.com>
	<21606.12190.531985.105109@mariner.uk.xensource.com>
In-Reply-To: <21606.12190.531985.105109@mariner.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 11:36 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>> On 11/14/2014 11:31 AM, Ian Jackson wrote:
>>> `goto skip1' only appears in the PV path AFAICT.
>> Right, this is all about PV code path.
> So now I am confused.  Why is qemu involved ?

This has nothing to do with QEMU. It's just that we are having this 
conversation in the thread with wrong subject ;-)

We should be talking about it in "[PATCH 2/2] libxl: Simplify cleanup in 
do_pci_remove()"

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:55:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:55:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpK9z-0005A1-Uy; Fri, 14 Nov 2014 16:55:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpK9y-00059w-7M
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 16:55:46 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	C7/72-01660-11436645; Fri, 14 Nov 2014 16:55:45 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415984143!6064327!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26532 invoked from network); 14 Nov 2014 16:55:44 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 16:55:44 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEGtbtZ019533
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 16:55:38 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGtbLu019018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 16:55:37 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEGtaw3020517; Fri, 14 Nov 2014 16:55:36 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 08:55:36 -0800
Message-ID: <546634A3.6060005@oracle.com>
Date: Fri, 14 Nov 2014 11:58:11 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>	<21606.5282.659930.728522@mariner.uk.xensource.com>	<54662004.6050702@oracle.com>	<21606.10103.850619.644934@mariner.uk.xensource.com>	<54662CB1.2050505@oracle.com>	<21606.11847.373254.124439@mariner.uk.xensource.com>	<54662FBD.1010605@oracle.com>
	<21606.12190.531985.105109@mariner.uk.xensource.com>
In-Reply-To: <21606.12190.531985.105109@mariner.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 11:36 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>> On 11/14/2014 11:31 AM, Ian Jackson wrote:
>>> `goto skip1' only appears in the PV path AFAICT.
>> Right, this is all about PV code path.
> So now I am confused.  Why is qemu involved ?

This has nothing to do with QEMU. It's just that we are having this 
conversation in the thread with wrong subject ;-)

We should be talking about it in "[PATCH 2/2] libxl: Simplify cleanup in 
do_pci_remove()"

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:59:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:59:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKDZ-0005Hy-J2; Fri, 14 Nov 2014 16:59:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpKDY-0005Ht-So
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:59:28 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4C/B3-09936-0F436645; Fri, 14 Nov 2014 16:59:28 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415984367!12851993!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10754 invoked from network); 14 Nov 2014 16:59:27 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 16:59:27 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:53849 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpKCQ-0007iP-KM; Fri, 14 Nov 2014 17:58:18 +0100
Date: Fri, 14 Nov 2014 17:59:23 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1393541150.20141114175923@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5466314E0200007800047C90@mail.emea.novell.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 4:43:58 PM, you wrote:

>>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
>> If it still helps i could try Andrews suggestion and try out with only 
>> commit aeeea485 ..

> Yes, even if it's pretty certain it's the second of the commits, verifying
> this would be helpful (or if the assumption is wrong, the pattern it's
> dying with would change and hence perhaps provide further clues).

> Jan


Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
pasta without a panic. So it would probably be indeed that specific commit.

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:59:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16:59:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKDZ-0005Hy-J2; Fri, 14 Nov 2014 16:59:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpKDY-0005Ht-So
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:59:28 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4C/B3-09936-0F436645; Fri, 14 Nov 2014 16:59:28 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-21.messagelabs.com!1415984367!12851993!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10754 invoked from network); 14 Nov 2014 16:59:27 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 16:59:27 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:53849 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpKCQ-0007iP-KM; Fri, 14 Nov 2014 17:58:18 +0100
Date: Fri, 14 Nov 2014 17:59:23 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1393541150.20141114175923@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5466314E0200007800047C90@mail.emea.novell.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 4:43:58 PM, you wrote:

>>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
>> If it still helps i could try Andrews suggestion and try out with only 
>> commit aeeea485 ..

> Yes, even if it's pretty certain it's the second of the commits, verifying
> this would be helpful (or if the assumption is wrong, the pattern it's
> dying with would change and hence perhaps provide further clues).

> Jan


Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
pasta without a panic. So it would probably be indeed that specific commit.

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:59:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpKE0-0005KV-Vw; Fri, 14 Nov 2014 16:59:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpKDz-0005KI-Mi
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:59:55 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	EE/19-27584-A0536645; Fri, 14 Nov 2014 16:59:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415984391!8592273!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8205 invoked from network); 14 Nov 2014 16:59:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:59:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191462118"
Message-ID: <1415984388.7113.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 16:59:48 +0000
In-Reply-To: <1415734910-4647-8-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415734910-4647-8-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 7/9] ts-hosts-allocate-Executive:
 Score for equivalent previous failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> Look to see whether the last run on any hosts which are equivalent to
> the ones we're looking at, failed.  This means that when host X is
> failing and we are considering host Y which is equivalent to X, we
> give Y a selection bonus.
> 
> This means that osstest will be less obsessive about sticking to the
> very same failing host.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  ts-hosts-allocate-Executive |   45 +++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
> index 9562a0a..24f78d3 100755
> --- a/ts-hosts-allocate-Executive
> +++ b/ts-hosts-allocate-Executive
> @@ -284,6 +284,29 @@ END
>          $findhostsq->execute("blessed-$fi->{intended}");
>      }
>  
> +    my $equivstatusq= $dbh_tests->prepare(<<END);
> +            SELECT flight, job, val, status
> +	      FROM flights f
> +	      JOIN jobs j USING (flight)
> +	      JOIN runvars r USING (flight,job)
> +             WHERE j.job=?
> +               AND f.blessing=?
> +	       AND f.branch=?
> +               AND r.name=?
> +	       AND r.val IN (
> +		   SELECT hostname
> +		     FROM hostflags
> +		    WHERE hostflag IN (
> +			  SELECT hostflag
> +			    FROM hostflags
> +			   WHERE hostname=?
> +			     AND hostflag LIKE 'equiv-%'
> +		       )
> +		   )
> +	  ORDER BY f.started DESC
> +	     LIMIT 1;
> +END
> +
>      my @candidates;
>      my $any=0;
>  
> @@ -342,6 +365,17 @@ END
>  
>          find_recent_duration($dbg,$hid,$candrow);
>  
> +	if ($candrow->{restype} eq 'host') {
> +	    $equivstatusq->execute($job,$fi->{intended},$fi->{branch},
> +				   $hid->{Ident},$candrow->{resname});
> +	    my $esrow = $equivstatusq->fetchrow_hashref();

For the first flight on a new branch (or perhaps a new blessing), this
will return an undef, because there is no previous flight to match,
won't it?

http://search.cpan.org/~timb/DBI-1.632/DBI.pm#fetchrow_hashref says if
you get an undef you should check $equivstatusq->err to see if that was
due to an error vs. empty result set. Not sure if you'll care given this
is all heuristics though.

> +	    $candrow->{EquivMostRecentStatus} = $esrow->{status};

Meaning this will fail, or perhaps just produce a warning.

> +	    print DEBUG "$dbg EQUIV-MOST-RECENT ";
> +	    print DEBUG ("$esrow->{flight}.$esrow->{job}".
> +			 " $esrow->{val} $esrow->{status}") if $esrow;
> +	    print DEBUG ".\n";

And so will these?

> +	}
> +
>          foreach my $kcomb (qw(Shared-Max-Wear Shared-Max-Tasks)) {
>              my $kdb= $kcomb;  $kdb =~ y/-A-Z/ a-z/;
>              my $khash= $kcomb;  $khash =~ y/-//d;
> @@ -362,6 +396,7 @@ END
>  	print DEBUG "$dbg CANDIDATE.\n";
>      }
>      $findhostsq->finish();
> +    $equivstatusq->finish();
>  
>      if (!@candidates) {
>          if (defined $use) {
> @@ -455,6 +490,7 @@ sub hid_recurse ($$) {
>      my $variation_age= 0;
>      my $duration= undef;
>      my $previously_failed = 0;
> +    my $previously_failed_equiv = 0;
>      foreach my $hid (@hids) {
>  	my $cand= $hid->{Selected};
>  	my $recentstarted= $cand->{MostRecentStarted};
> @@ -465,6 +501,8 @@ sub hid_recurse ($$) {
>  	    defined($cand->{Duration}) && $cand->{Duration} >= $duration;
>          $previously_failed++ if
>  	    ($cand->{MostRecentStatus} // '') eq 'fail';
> +	$previously_failed_equiv++ if
> +	    ($cand->{EquivMostRecentStatus} // '') eq 'fail';
>      }
>      my $duration_rightaway_adjust= 0;
>      
> @@ -505,12 +543,15 @@ sub hid_recurse ($$) {
>  
>      my $cost= $start_time
>  	+ $duration_for_cost
> -        - $previously_failed * 366*86400
> +        - ($previously_failed      ==@hids ? 366*86400 :
> +	   $previously_failed_equiv==@hids ? 365*86400 :
> +	   0)

You've dropped the behaviour of multiplying 366*86400 by
$previously_failed, was that intentional?

I think you've also gone to giving a bonus at all only if all @hids
previously failed, instead of just at least one of them.

>          + ($previously_failed ? + $variation_age * 10 : - $variation_age / 30)
>  	- $share_reuse * 10000;
>      
>      print DEBUG "$dbg FINAL start=$start_time va=$variation_age".
> -        " previously_failed=$previously_failed cost=$cost\n";
> +        " previously_failed=$previously_failed".
> +	" previously_failed_equiv=$previously_failed_equiv cost=$cost\n";
>  
>      if (!defined $best || $cost < $best->{Cost}) {
>          print DEBUG "$dbg FINAL BEST: ".



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 16:59:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 16: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 1XpKE0-0005KV-Vw; Fri, 14 Nov 2014 16:59:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpKDz-0005KI-Mi
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 16:59:55 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	EE/19-27584-A0536645; Fri, 14 Nov 2014 16:59:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1415984391!8592273!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8205 invoked from network); 14 Nov 2014 16:59:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 16:59:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191462118"
Message-ID: <1415984388.7113.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 16:59:48 +0000
In-Reply-To: <1415734910-4647-8-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415734910-4647-8-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 7/9] ts-hosts-allocate-Executive:
 Score for equivalent previous failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> Look to see whether the last run on any hosts which are equivalent to
> the ones we're looking at, failed.  This means that when host X is
> failing and we are considering host Y which is equivalent to X, we
> give Y a selection bonus.
> 
> This means that osstest will be less obsessive about sticking to the
> very same failing host.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  ts-hosts-allocate-Executive |   45 +++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
> index 9562a0a..24f78d3 100755
> --- a/ts-hosts-allocate-Executive
> +++ b/ts-hosts-allocate-Executive
> @@ -284,6 +284,29 @@ END
>          $findhostsq->execute("blessed-$fi->{intended}");
>      }
>  
> +    my $equivstatusq= $dbh_tests->prepare(<<END);
> +            SELECT flight, job, val, status
> +	      FROM flights f
> +	      JOIN jobs j USING (flight)
> +	      JOIN runvars r USING (flight,job)
> +             WHERE j.job=?
> +               AND f.blessing=?
> +	       AND f.branch=?
> +               AND r.name=?
> +	       AND r.val IN (
> +		   SELECT hostname
> +		     FROM hostflags
> +		    WHERE hostflag IN (
> +			  SELECT hostflag
> +			    FROM hostflags
> +			   WHERE hostname=?
> +			     AND hostflag LIKE 'equiv-%'
> +		       )
> +		   )
> +	  ORDER BY f.started DESC
> +	     LIMIT 1;
> +END
> +
>      my @candidates;
>      my $any=0;
>  
> @@ -342,6 +365,17 @@ END
>  
>          find_recent_duration($dbg,$hid,$candrow);
>  
> +	if ($candrow->{restype} eq 'host') {
> +	    $equivstatusq->execute($job,$fi->{intended},$fi->{branch},
> +				   $hid->{Ident},$candrow->{resname});
> +	    my $esrow = $equivstatusq->fetchrow_hashref();

For the first flight on a new branch (or perhaps a new blessing), this
will return an undef, because there is no previous flight to match,
won't it?

http://search.cpan.org/~timb/DBI-1.632/DBI.pm#fetchrow_hashref says if
you get an undef you should check $equivstatusq->err to see if that was
due to an error vs. empty result set. Not sure if you'll care given this
is all heuristics though.

> +	    $candrow->{EquivMostRecentStatus} = $esrow->{status};

Meaning this will fail, or perhaps just produce a warning.

> +	    print DEBUG "$dbg EQUIV-MOST-RECENT ";
> +	    print DEBUG ("$esrow->{flight}.$esrow->{job}".
> +			 " $esrow->{val} $esrow->{status}") if $esrow;
> +	    print DEBUG ".\n";

And so will these?

> +	}
> +
>          foreach my $kcomb (qw(Shared-Max-Wear Shared-Max-Tasks)) {
>              my $kdb= $kcomb;  $kdb =~ y/-A-Z/ a-z/;
>              my $khash= $kcomb;  $khash =~ y/-//d;
> @@ -362,6 +396,7 @@ END
>  	print DEBUG "$dbg CANDIDATE.\n";
>      }
>      $findhostsq->finish();
> +    $equivstatusq->finish();
>  
>      if (!@candidates) {
>          if (defined $use) {
> @@ -455,6 +490,7 @@ sub hid_recurse ($$) {
>      my $variation_age= 0;
>      my $duration= undef;
>      my $previously_failed = 0;
> +    my $previously_failed_equiv = 0;
>      foreach my $hid (@hids) {
>  	my $cand= $hid->{Selected};
>  	my $recentstarted= $cand->{MostRecentStarted};
> @@ -465,6 +501,8 @@ sub hid_recurse ($$) {
>  	    defined($cand->{Duration}) && $cand->{Duration} >= $duration;
>          $previously_failed++ if
>  	    ($cand->{MostRecentStatus} // '') eq 'fail';
> +	$previously_failed_equiv++ if
> +	    ($cand->{EquivMostRecentStatus} // '') eq 'fail';
>      }
>      my $duration_rightaway_adjust= 0;
>      
> @@ -505,12 +543,15 @@ sub hid_recurse ($$) {
>  
>      my $cost= $start_time
>  	+ $duration_for_cost
> -        - $previously_failed * 366*86400
> +        - ($previously_failed      ==@hids ? 366*86400 :
> +	   $previously_failed_equiv==@hids ? 365*86400 :
> +	   0)

You've dropped the behaviour of multiplying 366*86400 by
$previously_failed, was that intentional?

I think you've also gone to giving a bonus at all only if all @hids
previously failed, instead of just at least one of them.

>          + ($previously_failed ? + $variation_age * 10 : - $variation_age / 30)
>  	- $share_reuse * 10000;
>      
>      print DEBUG "$dbg FINAL start=$start_time va=$variation_age".
> -        " previously_failed=$previously_failed cost=$cost\n";
> +        " previously_failed=$previously_failed".
> +	" previously_failed_equiv=$previously_failed_equiv cost=$cost\n";
>  
>      if (!defined $best || $cost < $best->{Cost}) {
>          print DEBUG "$dbg FINAL BEST: ".



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:05:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17:05:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKJX-0005uP-QN; Fri, 14 Nov 2014 17:05:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpKJW-0005uK-7F
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:05:38 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	E7/94-26652-16636645; Fri, 14 Nov 2014 17:05:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415984735!11492064!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29243 invoked from network); 14 Nov 2014 17:05:36 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 17:05:36 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEH5WFn013625
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 17:05:33 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEH5VRD012076
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Nov 2014 17:05:32 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAEH5Tah011966; Fri, 14 Nov 2014 17:05:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 09:05:29 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7FCFB1166B7; Fri, 14 Nov 2014 12:05:28 -0500 (EST)
Date: Fri, 14 Nov 2014 12:05:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141114170528.GC8198@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1393541150.20141114175923@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
> 
> Friday, November 14, 2014, 4:43:58 PM, you wrote:
> 
> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
> >> If it still helps i could try Andrews suggestion and try out with only 
> >> commit aeeea485 ..
> 
> > Yes, even if it's pretty certain it's the second of the commits, verifying
> > this would be helpful (or if the assumption is wrong, the pattern it's
> > dying with would change and hence perhaps provide further clues).
> 
> > Jan
> 
> 
> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
> pasta without a panic. So it would probably be indeed that specific commit.

Thank you for confirmation.

Could you give some specifics on the guests? As in what kind of devices you
are giving it - and more interestingly - what type of interrupt mechanism
do they use (/proc/interrupts along with 'dmesg' | grep <name of driver> should
give some ideas).

I wouldn't worry about the PV case as that bypasses the dpci codebase - just
on the HVM side.

Thanks again!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:05:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17:05:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKJX-0005uP-QN; Fri, 14 Nov 2014 17:05:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpKJW-0005uK-7F
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:05:38 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	E7/94-26652-16636645; Fri, 14 Nov 2014 17:05:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415984735!11492064!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29243 invoked from network); 14 Nov 2014 17:05:36 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 17:05:36 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEH5WFn013625
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 17:05:33 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEH5VRD012076
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Nov 2014 17:05:32 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAEH5Tah011966; Fri, 14 Nov 2014 17:05:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 09:05:29 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7FCFB1166B7; Fri, 14 Nov 2014 12:05:28 -0500 (EST)
Date: Fri, 14 Nov 2014 12:05:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141114170528.GC8198@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1393541150.20141114175923@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
> 
> Friday, November 14, 2014, 4:43:58 PM, you wrote:
> 
> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
> >> If it still helps i could try Andrews suggestion and try out with only 
> >> commit aeeea485 ..
> 
> > Yes, even if it's pretty certain it's the second of the commits, verifying
> > this would be helpful (or if the assumption is wrong, the pattern it's
> > dying with would change and hence perhaps provide further clues).
> 
> > Jan
> 
> 
> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
> pasta without a panic. So it would probably be indeed that specific commit.

Thank you for confirmation.

Could you give some specifics on the guests? As in what kind of devices you
are giving it - and more interestingly - what type of interrupt mechanism
do they use (/proc/interrupts along with 'dmesg' | grep <name of driver> should
give some ideas).

I wouldn't worry about the PV case as that bypasses the dpci codebase - just
on the HVM side.

Thanks again!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:07:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17:07:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKLP-00061i-HL; Fri, 14 Nov 2014 17:07:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpKLO-00061c-GX
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 17:07:34 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	D4/94-02712-5D636645; Fri, 14 Nov 2014 17:07:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415984851!7238558!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11864 invoked from network); 14 Nov 2014 17:07:33 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 17:07:33 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEH75JF003461
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 17:07:06 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEH74rH012914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 17:07:05 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEH73Lv028453; Fri, 14 Nov 2014 17:07:04 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 09:07:03 -0800
Message-ID: <54663752.5080200@oracle.com>
Date: Fri, 14 Nov 2014 12:09:38 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.11138.483109.931473@mariner.uk.xensource.com>
In-Reply-To: <21606.11138.483109.931473@mariner.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 11:19 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("[PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>> When a device is hot-unplugged libxl sends QEMU a "device-del" message
>> (via QMP). This call returns after QEMU has initiated device removal by
>> sending an interrupt to the guest. At some point later QEMU is expected
>> to clean up after the device (such as unbind/unmap MSIs), which will
>> occur when the guest signals that the device has been ejected.
> As discussed, I agree that this is a problem.  There is a race between
> qemu/libxl and the guest.  If libxl gets there first, you see the
> symptoms you report.  Having libxl not progress with the rest of the
> removal is the right approach to fixing it.
>
> However, unfortunately, the approach you have taken has some problems.
>
> The most seriouis is this: you may not call usleep() anywhere inside
> libxl.  If you want to wait, you must use the callback mechanisms.

There are already instances of usleep in libxl (e.g. qmp_open(), which 
is where I got the ~5 seconds number, btw). But I agree that callbacks 
are better here, I didn't think of non-xl users.

> This is because the process running libxl may be a daemon handling
> many domains, and we must not hang waiting for any particular domain.
>
> I think that this means:
>    * Making libxl__device_pci_remove_common asynchronous (ie, so
>      that it makes a callback when done, rather than simply returning;
>    * Then, making do_pci_remove asynchronous, too.  This will involve
>      unfolding the loop in libxl__device_pci_remove_common into a
>      callback chain.
>    * Then, adjusting the new asynchronous do_pci_remove so that it
>      becomes two (or perhaps more) chained callback functions which
>      use a libxl__ev_time to manage the polling loop

OK, I'll try to see what needs to be done (I am not familiar with how 
libxl does asynchronous calls)

>
> Secondly, I'm not particularly keen on polling. Is there not a QMP
> function that can be used to get notified when the device is really
> removed ?

I didn't see any.

> Sadly I guess that if there is, restructuring the qmp
> handling in libxl_qmp.c (qmp_next et al) to be able to use it would be
> way out of scope for a bugfix during the freeze.

This would probably require changes in QEMU as well since I don't 
believe it notifies anyone on the other end of QMP connection that it is 
done cleaning up.

>
>
> Finally, some notes about error handling:
>
>> +            else {
>> +                unsigned total_us = 0, wait_us = 100000;
>> +
>> +                rc = -ETIMEDOUT;
> rc must contain only libxl error values.  Most libxl functions return
> libxl error values, not errno values.

rc is overwritten later:
         if (rc) {
             rc = ERROR_FAIL;
             goto out_fail;
         }


So this whole rc assignment business in the patch was somewhat pointless 
anyway.

One question though: should we fail on the timeout and not clean up 
xenstore and reset the device (which is what this version of the patch 
does)? Because we may end up with device finally removed and cleanup up 
by QEMU/guest but not reset and removed from xenstore.

Thanks.
-boris

>
> I'm sorry that the rest of this file is so confused about this.  I
> think you should use `ret' to contain responses which are `0 (for
> success) or -1 (setting errno)', and probably something like
> `errnoval' if you need actual errno values.
>
> You should definitely never write  -EFOOBAR  in userland code.
>
> Thanks,
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:07:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17:07:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKLP-00061i-HL; Fri, 14 Nov 2014 17:07:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpKLO-00061c-GX
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 17:07:34 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	D4/94-02712-5D636645; Fri, 14 Nov 2014 17:07:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415984851!7238558!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11864 invoked from network); 14 Nov 2014 17:07:33 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 17:07:33 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEH75JF003461
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 17:07:06 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEH74rH012914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 17:07:05 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEH73Lv028453; Fri, 14 Nov 2014 17:07:04 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 09:07:03 -0800
Message-ID: <54663752.5080200@oracle.com>
Date: Fri, 14 Nov 2014 12:09:38 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.11138.483109.931473@mariner.uk.xensource.com>
In-Reply-To: <21606.11138.483109.931473@mariner.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 11:19 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("[PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>> When a device is hot-unplugged libxl sends QEMU a "device-del" message
>> (via QMP). This call returns after QEMU has initiated device removal by
>> sending an interrupt to the guest. At some point later QEMU is expected
>> to clean up after the device (such as unbind/unmap MSIs), which will
>> occur when the guest signals that the device has been ejected.
> As discussed, I agree that this is a problem.  There is a race between
> qemu/libxl and the guest.  If libxl gets there first, you see the
> symptoms you report.  Having libxl not progress with the rest of the
> removal is the right approach to fixing it.
>
> However, unfortunately, the approach you have taken has some problems.
>
> The most seriouis is this: you may not call usleep() anywhere inside
> libxl.  If you want to wait, you must use the callback mechanisms.

There are already instances of usleep in libxl (e.g. qmp_open(), which 
is where I got the ~5 seconds number, btw). But I agree that callbacks 
are better here, I didn't think of non-xl users.

> This is because the process running libxl may be a daemon handling
> many domains, and we must not hang waiting for any particular domain.
>
> I think that this means:
>    * Making libxl__device_pci_remove_common asynchronous (ie, so
>      that it makes a callback when done, rather than simply returning;
>    * Then, making do_pci_remove asynchronous, too.  This will involve
>      unfolding the loop in libxl__device_pci_remove_common into a
>      callback chain.
>    * Then, adjusting the new asynchronous do_pci_remove so that it
>      becomes two (or perhaps more) chained callback functions which
>      use a libxl__ev_time to manage the polling loop

OK, I'll try to see what needs to be done (I am not familiar with how 
libxl does asynchronous calls)

>
> Secondly, I'm not particularly keen on polling. Is there not a QMP
> function that can be used to get notified when the device is really
> removed ?

I didn't see any.

> Sadly I guess that if there is, restructuring the qmp
> handling in libxl_qmp.c (qmp_next et al) to be able to use it would be
> way out of scope for a bugfix during the freeze.

This would probably require changes in QEMU as well since I don't 
believe it notifies anyone on the other end of QMP connection that it is 
done cleaning up.

>
>
> Finally, some notes about error handling:
>
>> +            else {
>> +                unsigned total_us = 0, wait_us = 100000;
>> +
>> +                rc = -ETIMEDOUT;
> rc must contain only libxl error values.  Most libxl functions return
> libxl error values, not errno values.

rc is overwritten later:
         if (rc) {
             rc = ERROR_FAIL;
             goto out_fail;
         }


So this whole rc assignment business in the patch was somewhat pointless 
anyway.

One question though: should we fail on the timeout and not clean up 
xenstore and reset the device (which is what this version of the patch 
does)? Because we may end up with device finally removed and cleanup up 
by QEMU/guest but not reset and removed from xenstore.

Thanks.
-boris

>
> I'm sorry that the rest of this file is so confused about this.  I
> think you should use `ret' to contain responses which are `0 (for
> success) or -1 (setting errno)', and probably something like
> `errnoval' if you need actual errno values.
>
> You should definitely never write  -EFOOBAR  in userland code.
>
> Thanks,
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:14:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKRn-0006Y6-Ch; Fri, 14 Nov 2014 17:14:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpKRm-0006Xq-Ai
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 17:14:10 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	6E/EC-08051-16836645; Fri, 14 Nov 2014 17:14:09 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415985248!12640503!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30345 invoked from network); 14 Nov 2014 17:14:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 17:14:08 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 1FCBDAABF;
	Fri, 14 Nov 2014 17:14:07 +0000 (UTC)
Message-ID: <5466385E.6040009@suse.com>
Date: Fri, 14 Nov 2014 18:14:06 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
	<20141113195605.GA13039@laptop.dumpdata.com>
	<54658ABF.5050708@suse.com>
	<20141114164741.GA8198@laptop.dumpdata.com>
In-Reply-To: <20141114164741.GA8198@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

On 11/14/2014 05:47 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 05:53:19AM +0100, Juergen Gross wrote:
>> On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
>>>>>> +	mfn_save = virt_to_mfn(buf);
>>>>>> +
>>>>>> +	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
>>>>>
>>>>> So the 'list' is constructed by going forward - that is from low-numbered
>>>>> PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
>>>>> other way - from the highest PFN to the lowest PFN.
>>>>>
>>>>> Won't that mean we will restore the chunks of memory in the wrong
>>>>> order? That is we will still restore them in chunks size, but the
>>>>> chunks will be in descending order instead of ascending?
>>>>
>>>> No, the information where to put each chunk is contained in the chunk
>>>> data. I can add a comment explaining this.
>>>
>>> Right, the MFNs in a "chunks" are going to be restored in the right order.
>>>
>>> I was thinking that the "chunks" (so a set of MFNs) will be restored in
>>> the opposite order that they are written to.
>>>
>>> And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?
>>
>> More don't fit on a single page due to the other info needed. So: yes.
>
> But you could use two pages - one for the structure and the other
> for the list of MFNs. That would fix the problem of having only
> 509 MFNs being contingous per chunk when restoring.

That's no problem (see below).

> Anyhow the point I had that I am worried is that we do not restore the
> MFNs in the same order. We do it in "chunk" size which is OK (so the 509 MFNs
> at once)- but the order we traverse the restoration process is the opposite of
> the save process. Say we have 4MB of contingous MFNs, so two (err, three)
> chunks. The first one we iterate is from 0->509, the second is 510->1018, the
> last is 1019->1023. When we restore (remap) we start with the last 'chunk'
> so we end up restoring them: 1019->1023, 510->1018, 0->509 order.

No. When building up the chunks we save in each chunk where to put it
on remap. So in your example 0-509 should be mapped at <dest>+0,
510-1018 at <dest>+510, and 1019-1023 at <dest>+1019.

When remapping we map 1019-1023 to <dest>+1019, 510-1018 at <dest>+510
and last 0-509 at <dest>+0. So we do the mapping in reverse order, but
to the correct pfns.

Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:14:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKRZ-0006WM-JE; Fri, 14 Nov 2014 17:13:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpKRX-0006WH-Sj
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:13:56 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	05/68-27623-35836645; Fri, 14 Nov 2014 17:13:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415985233!7764677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20852 invoked from network); 14 Nov 2014 17:13:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 17:13:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192932276"
Message-ID: <1415984820.7113.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 17:07:00 +0000
In-Reply-To: <1415734910-4647-9-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415734910-4647-9-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 8/9] ts-hosts-allocate-Executive:
 Redo variation_bonus scoring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> Use a logarithmic scale.  Cap the bonus at 12h rather than 5d/30 = 4h.
> When we have previously failed, make sure we apply a reverse bonus,
> rather than a penalty.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  ts-hosts-allocate-Executive |   12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
> index 24f78d3..590fe98 100755
> --- a/ts-hosts-allocate-Executive
> +++ b/ts-hosts-allocate-Executive
> @@ -537,19 +537,25 @@ sub hid_recurse ($$) {
>      if ($jobinfo->{recipe} =~ m/build/) {
>          $variation_age= 0;
>  	$duration_for_cost= $duration + $duration_rightaway_adjust;
> -    } elsif ($variation_age > 5*86400) {
> -	$variation_age= 5*86400;
>      }
>  
> +    my $log_variation_age = log(1+$variation_age/86400);
> +    my $variation_bonus = $log_variation_age * 3600*2;
> +    my $max_variation_bonus = 12*86400;

Isn't that 12 days, rather than the 12 hours in the commit log?

Or are the units here something other than seconds? (in which case I'm
v. confused by what time() returns...)

> +    $variation_bonus=$max_variation_bonus
> +	if $variation_bonus>$max_variation_bonus;
> +
>      my $cost= $start_time
>  	+ $duration_for_cost
>          - ($previously_failed      ==@hids ? 366*86400 :
>  	   $previously_failed_equiv==@hids ? 365*86400 :
>  	   0)
> -        + ($previously_failed ? + $variation_age * 10 : - $variation_age / 30)
> +        + ($previously_failed || $previously_failed_equiv
> +	   ? (-$max_variation_bonus+$variation_bonus) : -$variation_bonus)
>  	- $share_reuse * 10000;
>      
>      print DEBUG "$dbg FINAL start=$start_time va=$variation_age".
> +	" variation_bonus=$variation_bonus".
>          " previously_failed=$previously_failed".
>  	" previously_failed_equiv=$previously_failed_equiv cost=$cost\n";
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:14:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKRf-0006Wh-0S; Fri, 14 Nov 2014 17:14:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <martin@lucina.net>) id 1XpKRd-0006WZ-Tu
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:14:02 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	DB/49-09284-95836645; Fri, 14 Nov 2014 17:14:01 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415985240!7764713!1
X-Originating-IP: [62.176.169.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21311 invoked from network); 14 Nov 2014 17:14:00 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 17:14:00 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id 21412180201D;
	Fri, 14 Nov 2014 18:14:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1415985240;
	bh=Z/X99FuRV+rWDYPEyreo/txzTjfUJ2/ROdvoy7vtOZw=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=d47LoUqlfklzXr499VcGW+YT/fjEO14tEtBkQcn4NFUPp5W+Bcssz0Bz7ROolSX0X
	X1055u9sGWS4LYgGxXDkeQMwLxNzGJeZfGOPrj66a04FJYOCKQpDnvF9Bc2YlxEMKW
	9vhJE4/Xrq5JLM7177vWFjAzSDE1helbg10QObwS0BBV8BTLQCg5j7AjRjAcjaSS4y
	QUUcnhxxwYe2atRnWnXLi+tlSiuhHCF9x4CWV5fuwa+PwwVj+GPgp+C6ETUTfDsXc2
	nkplIfCBTQ4G/IDk1LlGqPDxW1zoladwF11H+v8SGBQjqzETitCmAJf4osEiiZjTxl
	sd72VpbfptsuQ==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id 5C70C4C0E2D; Fri, 14 Nov 2014 18:14:15 +0100 (CET)
Date: Fri, 14 Nov 2014 18:14:15 +0100
From: Martin Lucina <martin@lucina.net>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141114171415.GB12962@nodbug.moloch.sk>
Mail-Followup-To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net,
	xen-devel@lists.xenproject.org
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk> <5464DECB.8090001@iki.fi>
	<20141113170726.GB9560@nodbug.moloch.sk> <5464E89A.7000908@iki.fi>
	<20141113185742.GD9560@nodbug.moloch.sk> <546506F8.6080709@iki.fi>
	<21606.9451.524882.759471@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21606.9451.524882.759471@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian.Jackson@eu.citrix.com said:
> I wonder if this mechanism could be used for some or all of the things
> that you're currently using xenstore for.  Specifying which virtual
> block devices to mount where, or what network configuration to use,
> are things that other rump kernel runners would want to do.  Putting
> that information in a stunt /etc seems like it might make more
> commonality.

<brainstorm>
What about embedded platforms with no notion of block devices?

I think that a "key/value store" is a more general abstraction to use.
It works equally well for eg. U-Boot environment variables instead of
xenstore.
</brainstorm>

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:14:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKRn-0006Y6-Ch; Fri, 14 Nov 2014 17:14:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XpKRm-0006Xq-Ai
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 17:14:10 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	6E/EC-08051-16836645; Fri, 14 Nov 2014 17:14:09 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1415985248!12640503!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30345 invoked from network); 14 Nov 2014 17:14:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 17:14:08 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 1FCBDAABF;
	Fri, 14 Nov 2014 17:14:07 +0000 (UTC)
Message-ID: <5466385E.6040009@suse.com>
Date: Fri, 14 Nov 2014 18:14:06 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
	<20141113195605.GA13039@laptop.dumpdata.com>
	<54658ABF.5050708@suse.com>
	<20141114164741.GA8198@laptop.dumpdata.com>
In-Reply-To: <20141114164741.GA8198@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

On 11/14/2014 05:47 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 05:53:19AM +0100, Juergen Gross wrote:
>> On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
>>>>>> +	mfn_save = virt_to_mfn(buf);
>>>>>> +
>>>>>> +	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
>>>>>
>>>>> So the 'list' is constructed by going forward - that is from low-numbered
>>>>> PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
>>>>> other way - from the highest PFN to the lowest PFN.
>>>>>
>>>>> Won't that mean we will restore the chunks of memory in the wrong
>>>>> order? That is we will still restore them in chunks size, but the
>>>>> chunks will be in descending order instead of ascending?
>>>>
>>>> No, the information where to put each chunk is contained in the chunk
>>>> data. I can add a comment explaining this.
>>>
>>> Right, the MFNs in a "chunks" are going to be restored in the right order.
>>>
>>> I was thinking that the "chunks" (so a set of MFNs) will be restored in
>>> the opposite order that they are written to.
>>>
>>> And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?
>>
>> More don't fit on a single page due to the other info needed. So: yes.
>
> But you could use two pages - one for the structure and the other
> for the list of MFNs. That would fix the problem of having only
> 509 MFNs being contingous per chunk when restoring.

That's no problem (see below).

> Anyhow the point I had that I am worried is that we do not restore the
> MFNs in the same order. We do it in "chunk" size which is OK (so the 509 MFNs
> at once)- but the order we traverse the restoration process is the opposite of
> the save process. Say we have 4MB of contingous MFNs, so two (err, three)
> chunks. The first one we iterate is from 0->509, the second is 510->1018, the
> last is 1019->1023. When we restore (remap) we start with the last 'chunk'
> so we end up restoring them: 1019->1023, 510->1018, 0->509 order.

No. When building up the chunks we save in each chunk where to put it
on remap. So in your example 0-509 should be mapped at <dest>+0,
510-1018 at <dest>+510, and 1019-1023 at <dest>+1019.

When remapping we map 1019-1023 to <dest>+1019, 510-1018 at <dest>+510
and last 0-509 at <dest>+0. So we do the mapping in reverse order, but
to the correct pfns.

Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:14:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKRZ-0006WM-JE; Fri, 14 Nov 2014 17:13:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XpKRX-0006WH-Sj
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:13:56 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	05/68-27623-35836645; Fri, 14 Nov 2014 17:13:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415985233!7764677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20852 invoked from network); 14 Nov 2014 17:13:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 17:13:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192932276"
Message-ID: <1415984820.7113.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 14 Nov 2014 17:07:00 +0000
In-Reply-To: <1415734910-4647-9-git-send-email-ian.jackson@eu.citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415734910-4647-9-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 8/9] ts-hosts-allocate-Executive:
 Redo variation_bonus scoring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> Use a logarithmic scale.  Cap the bonus at 12h rather than 5d/30 = 4h.
> When we have previously failed, make sure we apply a reverse bonus,
> rather than a penalty.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  ts-hosts-allocate-Executive |   12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
> index 24f78d3..590fe98 100755
> --- a/ts-hosts-allocate-Executive
> +++ b/ts-hosts-allocate-Executive
> @@ -537,19 +537,25 @@ sub hid_recurse ($$) {
>      if ($jobinfo->{recipe} =~ m/build/) {
>          $variation_age= 0;
>  	$duration_for_cost= $duration + $duration_rightaway_adjust;
> -    } elsif ($variation_age > 5*86400) {
> -	$variation_age= 5*86400;
>      }
>  
> +    my $log_variation_age = log(1+$variation_age/86400);
> +    my $variation_bonus = $log_variation_age * 3600*2;
> +    my $max_variation_bonus = 12*86400;

Isn't that 12 days, rather than the 12 hours in the commit log?

Or are the units here something other than seconds? (in which case I'm
v. confused by what time() returns...)

> +    $variation_bonus=$max_variation_bonus
> +	if $variation_bonus>$max_variation_bonus;
> +
>      my $cost= $start_time
>  	+ $duration_for_cost
>          - ($previously_failed      ==@hids ? 366*86400 :
>  	   $previously_failed_equiv==@hids ? 365*86400 :
>  	   0)
> -        + ($previously_failed ? + $variation_age * 10 : - $variation_age / 30)
> +        + ($previously_failed || $previously_failed_equiv
> +	   ? (-$max_variation_bonus+$variation_bonus) : -$variation_bonus)
>  	- $share_reuse * 10000;
>      
>      print DEBUG "$dbg FINAL start=$start_time va=$variation_age".
> +	" variation_bonus=$variation_bonus".
>          " previously_failed=$previously_failed".
>  	" previously_failed_equiv=$previously_failed_equiv cost=$cost\n";
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:14:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKRf-0006Wh-0S; Fri, 14 Nov 2014 17:14:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <martin@lucina.net>) id 1XpKRd-0006WZ-Tu
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:14:02 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	DB/49-09284-95836645; Fri, 14 Nov 2014 17:14:01 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415985240!7764713!1
X-Originating-IP: [62.176.169.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21311 invoked from network); 14 Nov 2014 17:14:00 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 17:14:00 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id 21412180201D;
	Fri, 14 Nov 2014 18:14:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1415985240;
	bh=Z/X99FuRV+rWDYPEyreo/txzTjfUJ2/ROdvoy7vtOZw=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=d47LoUqlfklzXr499VcGW+YT/fjEO14tEtBkQcn4NFUPp5W+Bcssz0Bz7ROolSX0X
	X1055u9sGWS4LYgGxXDkeQMwLxNzGJeZfGOPrj66a04FJYOCKQpDnvF9Bc2YlxEMKW
	9vhJE4/Xrq5JLM7177vWFjAzSDE1helbg10QObwS0BBV8BTLQCg5j7AjRjAcjaSS4y
	QUUcnhxxwYe2atRnWnXLi+tlSiuhHCF9x4CWV5fuwa+PwwVj+GPgp+C6ETUTfDsXc2
	nkplIfCBTQ4G/IDk1LlGqPDxW1zoladwF11H+v8SGBQjqzETitCmAJf4osEiiZjTxl
	sd72VpbfptsuQ==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id 5C70C4C0E2D; Fri, 14 Nov 2014 18:14:15 +0100 (CET)
Date: Fri, 14 Nov 2014 18:14:15 +0100
From: Martin Lucina <martin@lucina.net>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141114171415.GB12962@nodbug.moloch.sk>
Mail-Followup-To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net,
	xen-devel@lists.xenproject.org
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk> <5464DECB.8090001@iki.fi>
	<20141113170726.GB9560@nodbug.moloch.sk> <5464E89A.7000908@iki.fi>
	<20141113185742.GD9560@nodbug.moloch.sk> <546506F8.6080709@iki.fi>
	<21606.9451.524882.759471@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21606.9451.524882.759471@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian.Jackson@eu.citrix.com said:
> I wonder if this mechanism could be used for some or all of the things
> that you're currently using xenstore for.  Specifying which virtual
> block devices to mount where, or what network configuration to use,
> are things that other rump kernel runners would want to do.  Putting
> that information in a stunt /etc seems like it might make more
> commonality.

<brainstorm>
What about embedded platforms with no notion of block devices?

I think that a "key/value store" is a more general abstraction to use.
It works equally well for eg. U-Boot environment variables instead of
xenstore.
</brainstorm>

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:16:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKTa-0006la-TA; Fri, 14 Nov 2014 17:16:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpKTY-0006lJ-GX
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:16:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F8/F4-09842-FC836645; Fri, 14 Nov 2014 17:15:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415985357!12871780!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11255 invoked from network); 14 Nov 2014 17:15:59 -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 Nov 2014 17:15:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192934232"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 12:10:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpKOg-0004gB-FZ;
	Fri, 14 Nov 2014 17:10:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpKOf-0002Fn-Op;
	Fri, 14 Nov 2014 17:10:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.14241.299779.475425@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 17:10:57 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415984388.7113.28.camel@citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415734910-4647-8-git-send-email-ian.jackson@eu.citrix.com>
	<1415984388.7113.28.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 7/9] ts-hosts-allocate-Executive:
 Score for equivalent previous failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [OSSTEST PATCH 7/9] ts-hosts-allocate-Executive: Score for equivalent previous failures"):
> On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> > +	if ($candrow->{restype} eq 'host') {
> > +	    $equivstatusq->execute($job,$fi->{intended},$fi->{branch},
> > +				   $hid->{Ident},$candrow->{resname});
> > +	    my $esrow = $equivstatusq->fetchrow_hashref();
> 
> For the first flight on a new branch (or perhaps a new blessing), this
> will return an undef, because there is no previous flight to match,
> won't it?

Yes.

> http://search.cpan.org/~timb/DBI-1.632/DBI.pm#fetchrow_hashref says if
> you get an undef you should check $equivstatusq->err to see if that was
> due to an error vs. empty result set. Not sure if you'll care given this
> is all heuristics though.

We turn on the automatic error trapping during db setup, so errors
helpfully turn into die.

> > +	    $candrow->{EquivMostRecentStatus} = $esrow->{status};
> 
> Meaning this will fail, or perhaps just produce a warning.

$ perl -MData::Dumper -we 'use strict; my $y; print Dumper($y->{foo});'
$VAR1 = undef;
$

> > +	    print DEBUG "$dbg EQUIV-MOST-RECENT ";
> > +	    print DEBUG ("$esrow->{flight}.$esrow->{job}".
> > +			 " $esrow->{val} $esrow->{status}") if $esrow;
> > +	    print DEBUG ".\n";
> 
> And so will these?

  if $esrow;

> > @@ -505,12 +543,15 @@ sub hid_recurse ($$) {
> >  
> >      my $cost= $start_time
> >  	+ $duration_for_cost
> > -        - $previously_failed * 366*86400
> > +        - ($previously_failed      ==@hids ? 366*86400 :
> > +	   $previously_failed_equiv==@hids ? 365*86400 :
> > +	   0)
> 
> You've dropped the behaviour of multiplying 366*86400 by
> $previously_failed, was that intentional?

Yes.  $previously_failed was the number of candidate hosts which had
previous failures.  Making the offset proportional to the number of
hosts in the test is daft.

> I think you've also gone to giving a bonus at all only if all @hids
> previously failed, instead of just at least one of them.

Yes.

Should I write this better in the commit message ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:16:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKTa-0006la-TA; Fri, 14 Nov 2014 17:16:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpKTY-0006lJ-GX
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:16:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F8/F4-09842-FC836645; Fri, 14 Nov 2014 17:15:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1415985357!12871780!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11255 invoked from network); 14 Nov 2014 17:15:59 -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 Nov 2014 17:15:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192934232"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 12:10:59 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpKOg-0004gB-FZ;
	Fri, 14 Nov 2014 17:10:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpKOf-0002Fn-Op;
	Fri, 14 Nov 2014 17:10:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.14241.299779.475425@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 17:10:57 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415984388.7113.28.camel@citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415734910-4647-8-git-send-email-ian.jackson@eu.citrix.com>
	<1415984388.7113.28.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 7/9] ts-hosts-allocate-Executive:
 Score for equivalent previous failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [OSSTEST PATCH 7/9] ts-hosts-allocate-Executive: Score for equivalent previous failures"):
> On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> > +	if ($candrow->{restype} eq 'host') {
> > +	    $equivstatusq->execute($job,$fi->{intended},$fi->{branch},
> > +				   $hid->{Ident},$candrow->{resname});
> > +	    my $esrow = $equivstatusq->fetchrow_hashref();
> 
> For the first flight on a new branch (or perhaps a new blessing), this
> will return an undef, because there is no previous flight to match,
> won't it?

Yes.

> http://search.cpan.org/~timb/DBI-1.632/DBI.pm#fetchrow_hashref says if
> you get an undef you should check $equivstatusq->err to see if that was
> due to an error vs. empty result set. Not sure if you'll care given this
> is all heuristics though.

We turn on the automatic error trapping during db setup, so errors
helpfully turn into die.

> > +	    $candrow->{EquivMostRecentStatus} = $esrow->{status};
> 
> Meaning this will fail, or perhaps just produce a warning.

$ perl -MData::Dumper -we 'use strict; my $y; print Dumper($y->{foo});'
$VAR1 = undef;
$

> > +	    print DEBUG "$dbg EQUIV-MOST-RECENT ";
> > +	    print DEBUG ("$esrow->{flight}.$esrow->{job}".
> > +			 " $esrow->{val} $esrow->{status}") if $esrow;
> > +	    print DEBUG ".\n";
> 
> And so will these?

  if $esrow;

> > @@ -505,12 +543,15 @@ sub hid_recurse ($$) {
> >  
> >      my $cost= $start_time
> >  	+ $duration_for_cost
> > -        - $previously_failed * 366*86400
> > +        - ($previously_failed      ==@hids ? 366*86400 :
> > +	   $previously_failed_equiv==@hids ? 365*86400 :
> > +	   0)
> 
> You've dropped the behaviour of multiplying 366*86400 by
> $previously_failed, was that intentional?

Yes.  $previously_failed was the number of candidate hosts which had
previous failures.  Making the offset proportional to the number of
hosts in the test is daft.

> I think you've also gone to giving a bonus at all only if all @hids
> previously failed, instead of just at least one of them.

Yes.

Should I write this better in the commit message ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:25:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKcB-00076K-TU; Fri, 14 Nov 2014 17:24: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@citrix.com>) id 1XpKcB-00076F-Ea
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:24:55 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	6B/41-11581-6EA36645; Fri, 14 Nov 2014 17:24:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415985892!11465925!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1912 invoked from network); 14 Nov 2014 17:24:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 17:24:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192941025"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 12:24:26 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpKbh-0004s5-I0;
	Fri, 14 Nov 2014 17:24:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpKbg-0002Hf-De;
	Fri, 14 Nov 2014 17:24:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.15047.870789.338503@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 17:24:23 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415984820.7113.30.camel@citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415734910-4647-9-git-send-email-ian.jackson@eu.citrix.com>
	<1415984820.7113.30.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 8/9] ts-hosts-allocate-Executive:
 Redo variation_bonus scoring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [OSSTEST PATCH 8/9] ts-hosts-allocate-Executive: Redo variation_bonus scoring"):
> On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> > +    my $log_variation_age = log(1+$variation_age/86400);
> > +    my $variation_bonus = $log_variation_age * 3600*2;
> > +    my $max_variation_bonus = 12*86400;
> 
> Isn't that 12 days, rather than the 12 hours in the commit log?

Well spotted.  I made that mistake deliberately, honest.

Thanks for the review!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:25:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKcB-00076K-TU; Fri, 14 Nov 2014 17:24: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@citrix.com>) id 1XpKcB-00076F-Ea
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:24:55 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	6B/41-11581-6EA36645; Fri, 14 Nov 2014 17:24:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1415985892!11465925!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1912 invoked from network); 14 Nov 2014 17:24:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 17:24:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192941025"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 12:24:26 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpKbh-0004s5-I0;
	Fri, 14 Nov 2014 17:24:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpKbg-0002Hf-De;
	Fri, 14 Nov 2014 17:24:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.15047.870789.338503@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 17:24:23 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415984820.7113.30.camel@citrix.com>
References: <1415734910-4647-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415734910-4647-9-git-send-email-ian.jackson@eu.citrix.com>
	<1415984820.7113.30.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 8/9] ts-hosts-allocate-Executive:
 Redo variation_bonus scoring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [OSSTEST PATCH 8/9] ts-hosts-allocate-Executive: Redo variation_bonus scoring"):
> On Tue, 2014-11-11 at 19:41 +0000, Ian Jackson wrote:
> > +    my $log_variation_age = log(1+$variation_age/86400);
> > +    my $variation_bonus = $log_variation_age * 3600*2;
> > +    my $max_variation_bonus = 12*86400;
> 
> Isn't that 12 days, rather than the 12 hours in the commit log?

Well spotted.  I made that mistake deliberately, honest.

Thanks for the review!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:28:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17:28:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKfw-0007Gc-Hx; Fri, 14 Nov 2014 17:28:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpKfv-0007GU-BT
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:28:47 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	A9/E7-26740-ECB36645; Fri, 14 Nov 2014 17:28:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415986123!7767677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28703 invoked from network); 14 Nov 2014 17:28:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 17:28:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192942389"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 12:28:06 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpKfF-0004vt-9D;
	Fri, 14 Nov 2014 17:28:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpKfE-0002IL-G7;
	Fri, 14 Nov 2014 17:28:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.15267.876027.979239@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 17:28:03 +0000
To: Martin Lucina <martin@lucina.net>
In-Reply-To: <20141114171415.GB12962@nodbug.moloch.sk>
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk> <5464DECB.8090001@iki.fi>
	<20141113170726.GB9560@nodbug.moloch.sk> <5464E89A.7000908@iki.fi>
	<20141113185742.GD9560@nodbug.moloch.sk> <546506F8.6080709@iki.fi>
	<21606.9451.524882.759471@mariner.uk.xensource.com>
	<20141114171415.GB12962@nodbug.moloch.sk>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Martin Lucina writes ("Re: RFC: Configuring rumprun-xen application stacks from Xenstore"):
> <brainstorm>
> What about embedded platforms with no notion of block devices?

The /etc should be provided as a RAM image then.  I did this very
successfully in a previous life in a resource-constrained embedded
platform.  We provided an in-memory cpio archive for a faked-up
filesystem containing the bits of /etc (and /dev) that are needed for
proper operation of the libc.

The format isn't very important and the data involved is small.  The
point is that it's much easier to provide the libc with a cardboard
cutout /etc that cause the libc to work just like on a `real' system,
than to try to fix all the places where it expects /etc/vital.conf.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:28:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17:28:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKfw-0007Gc-Hx; Fri, 14 Nov 2014 17:28:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpKfv-0007GU-BT
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:28:47 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	A9/E7-26740-ECB36645; Fri, 14 Nov 2014 17:28:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1415986123!7767677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28703 invoked from network); 14 Nov 2014 17:28:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 17:28:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192942389"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 12:28:06 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpKfF-0004vt-9D;
	Fri, 14 Nov 2014 17:28:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpKfE-0002IL-G7;
	Fri, 14 Nov 2014 17:28:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.15267.876027.979239@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 17:28:03 +0000
To: Martin Lucina <martin@lucina.net>
In-Reply-To: <20141114171415.GB12962@nodbug.moloch.sk>
References: <20141113112202.GB7853@nodbug.moloch.sk> <5464BB03.7090801@iki.fi>
	<20141113154634.GA9560@nodbug.moloch.sk> <5464DECB.8090001@iki.fi>
	<20141113170726.GB9560@nodbug.moloch.sk> <5464E89A.7000908@iki.fi>
	<20141113185742.GD9560@nodbug.moloch.sk> <546506F8.6080709@iki.fi>
	<21606.9451.524882.759471@mariner.uk.xensource.com>
	<20141114171415.GB12962@nodbug.moloch.sk>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: rumpkernel-users@lists.sourceforge.net, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks
	from Xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Martin Lucina writes ("Re: RFC: Configuring rumprun-xen application stacks from Xenstore"):
> <brainstorm>
> What about embedded platforms with no notion of block devices?

The /etc should be provided as a RAM image then.  I did this very
successfully in a previous life in a resource-constrained embedded
platform.  We provided an in-memory cpio archive for a faked-up
filesystem containing the bits of /etc (and /dev) that are needed for
proper operation of the libc.

The format isn't very important and the data involved is small.  The
point is that it's much easier to provide the libc with a cardboard
cutout /etc that cause the libc to work just like on a `real' system,
than to try to fix all the places where it expects /etc/vital.conf.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:37:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKoE-0007X6-LI; Fri, 14 Nov 2014 17:37:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1XpKoD-0007X1-8V
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:37:21 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	46/31-27785-0DD36645; Fri, 14 Nov 2014 17:37:20 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415986639!12632196!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16506 invoked from network); 14 Nov 2014 17:37:19 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 17:37:19 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so3454058wid.0
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 09:37:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=kj7C8Vl5F/V6XMK+93dH2fvD8Jjt9LXbgnufrLBR50M=;
	b=YoRf+czOreZHGlcvV3ypRrUqEzv9SBENX+dO16d/FU08+cR2SoZENUD+BB6syCOaKm
	U/c9Pxzo6n5tSHxkKeJuVuyUVdOAjI3lYevxb47Jm7JcpFUGldmsky+rPIUm5B684NR+
	7qysrKHywVeVOKPOl2vWE0riRN8QfQz3mU8tWmp8/r+mf1iJclWhxM169Oux4oXkWHml
	V6c9DbDYlMFO1N489ca/OkoNh9R92FLAbd4hFYcegA+asRJk3gBt/gTN3z0KH2+XqKaX
	saZUp/HJUO5byI+jlybB3a/GXY342Gr2vK9i6J6caEcSlFNe6V0DNrx6rhnPxlxue+jl
	YbIw==
X-Received: by 10.194.200.129 with SMTP id js1mr16449608wjc.0.1415986639187;
	Fri, 14 Nov 2014 09:37:19 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id wm6sm40446456wjb.5.2014.11.14.09.37.17
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 14 Nov 2014 09:37:18 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Lars Kurth <lars.kurth.xen@gmail.com>
In-Reply-To: <21605.64128.1227.643880@chiark.greenend.org.uk>
Date: Fri, 14 Nov 2014 17:37:16 +0000
Message-Id: <D541AEB1-F618-4E6F-AFB7-63C5A8ECE7AB@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
	<CE6BE269-4910-411C-B695-F3DB476F8229@gmail.com>
	<21605.64128.1227.643880@chiark.greenend.org.uk>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
X-Mailer: Apple Mail (2.1878.6)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 14 Nov 2014, at 12:50, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

> Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
>> I do have one question. What led us to publish an XSA number on 
>> http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell, 
>> CVE numbers are not published normally and we don't publish them 
>> until after the embargo due to CVE rules.
> 
> We used to publish CVEs in advance but MITRE asked us to stop doing
> so.
> 
> We publish the XSA numbers because the purpose of the secrecy is to
> prevent vulnerabilities being exploited.  The purpose of the secrecy
> is not the convenience of the Security Team.  Everything that does not
> need to be secret for that real purpose should be public.
> 
> Keeping secret the existence of an XSA number, and its embargo date,
> would not improve the security of systems running Xen.  So we should
> not do that.
> 
> Making the embargo end date public is very useful for people who are
> _not_ on the predisclosure list, because it means that they can plan
> their response.  (And it wouldn't make much sense to publish embargo
> end date(s) without XSA numbers.)

That is a good explanation and I can live with it.
I was mainly asking, because MITRE asked us to remove CVE numbers and there seemed to be some inconsistency

> 
>> I am wondering what community members view on publish XSA 
>> numbers post embargo only? Of course this would impact what
>> can be disclosed pre-embargo.
> 
> Another impact of keeping things totally secret in the way you suggest
> is that service providers would no longer be able to give honest
> reasons for maintenance activity.

That is also true

Regards
Lars


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:37:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpKoE-0007X6-LI; Fri, 14 Nov 2014 17:37:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1XpKoD-0007X1-8V
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 17:37:21 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	46/31-27785-0DD36645; Fri, 14 Nov 2014 17:37:20 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415986639!12632196!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16506 invoked from network); 14 Nov 2014 17:37:19 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 17:37:19 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so3454058wid.0
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 09:37:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=kj7C8Vl5F/V6XMK+93dH2fvD8Jjt9LXbgnufrLBR50M=;
	b=YoRf+czOreZHGlcvV3ypRrUqEzv9SBENX+dO16d/FU08+cR2SoZENUD+BB6syCOaKm
	U/c9Pxzo6n5tSHxkKeJuVuyUVdOAjI3lYevxb47Jm7JcpFUGldmsky+rPIUm5B684NR+
	7qysrKHywVeVOKPOl2vWE0riRN8QfQz3mU8tWmp8/r+mf1iJclWhxM169Oux4oXkWHml
	V6c9DbDYlMFO1N489ca/OkoNh9R92FLAbd4hFYcegA+asRJk3gBt/gTN3z0KH2+XqKaX
	saZUp/HJUO5byI+jlybB3a/GXY342Gr2vK9i6J6caEcSlFNe6V0DNrx6rhnPxlxue+jl
	YbIw==
X-Received: by 10.194.200.129 with SMTP id js1mr16449608wjc.0.1415986639187;
	Fri, 14 Nov 2014 09:37:19 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id wm6sm40446456wjb.5.2014.11.14.09.37.17
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 14 Nov 2014 09:37:18 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Lars Kurth <lars.kurth.xen@gmail.com>
In-Reply-To: <21605.64128.1227.643880@chiark.greenend.org.uk>
Date: Fri, 14 Nov 2014 17:37:16 +0000
Message-Id: <D541AEB1-F618-4E6F-AFB7-63C5A8ECE7AB@gmail.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
	<21557.50031.783473.873273@chiark.greenend.org.uk>
	<A104B0B6-C528-49EA-8460-A333DD1B0587@gmail.com>
	<21600.64887.416522.656249@chiark.greenend.org.uk>
	<CE6BE269-4910-411C-B695-F3DB476F8229@gmail.com>
	<21605.64128.1227.643880@chiark.greenend.org.uk>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
X-Mailer: Apple Mail (2.1878.6)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
	post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 14 Nov 2014, at 12:50, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

> Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
>> I do have one question. What led us to publish an XSA number on 
>> http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell, 
>> CVE numbers are not published normally and we don't publish them 
>> until after the embargo due to CVE rules.
> 
> We used to publish CVEs in advance but MITRE asked us to stop doing
> so.
> 
> We publish the XSA numbers because the purpose of the secrecy is to
> prevent vulnerabilities being exploited.  The purpose of the secrecy
> is not the convenience of the Security Team.  Everything that does not
> need to be secret for that real purpose should be public.
> 
> Keeping secret the existence of an XSA number, and its embargo date,
> would not improve the security of systems running Xen.  So we should
> not do that.
> 
> Making the embargo end date public is very useful for people who are
> _not_ on the predisclosure list, because it means that they can plan
> their response.  (And it wouldn't make much sense to publish embargo
> end date(s) without XSA numbers.)

That is a good explanation and I can live with it.
I was mainly asking, because MITRE asked us to remove CVE numbers and there seemed to be some inconsistency

> 
>> I am wondering what community members view on publish XSA 
>> numbers post embargo only? Of course this would impact what
>> can be disclosed pre-embargo.
> 
> Another impact of keeping things totally secret in the way you suggest
> is that service providers would no longer be able to give honest
> reasons for maintenance activity.

That is also true

Regards
Lars


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:41:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKsW-0007g3-DB; Fri, 14 Nov 2014 17:41:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpKsU-0007fK-6o
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 17:41:46 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	4D/55-02699-8DE36645; Fri, 14 Nov 2014 17:41:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415986901!12632880!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5441 invoked from network); 14 Nov 2014 17:41:44 -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;
	14 Nov 2014 17:41:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191479316"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 12:33:51 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpKkp-00051y-49;
	Fri, 14 Nov 2014 17:33:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpKko-0002JN-AT;
	Fri, 14 Nov 2014 17:33:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.15613.548151.502715@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 17:33:49 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54663752.5080200@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.11138.483109.931473@mariner.uk.xensource.com>
	<54663752.5080200@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> On 11/14/2014 11:19 AM, Ian Jackson wrote:
> > The most seriouis is this: you may not call usleep() anywhere inside
> > libxl.  If you want to wait, you must use the callback mechanisms.
> 
> There are already instances of usleep in libxl

Yes.  :-/.

> (e.g. qmp_open(), which is where I got the ~5 seconds number,
> btw). But I agree that callbacks are better here, I didn't think of
> non-xl users.

Right.  In this case the polling loop is worse than in qmp_open,
because a guest which doesn't respond to the pci event can trivially
cause the process to lock up.  (Causing qemu to fail to respond in a
timely fashion is probably possible but harder.)

> > I think that this means:
> >    * [asyncinfying]
> 
> OK, I'll try to see what needs to be done (I am not familiar with how 
> libxl does asynchronous calls)

Thanks.  You probably want to read the CODING_STYLE patch series that
I posted recently.  There are some examples of how to do event
chaining in the domain creation, bootloader execution and disk/vif
handling.

> > Secondly, I'm not particularly keen on polling. Is there not a QMP
> > function that can be used to get notified when the device is really
> > removed ?
> 
> I didn't see any.

Oh well.

> > Finally, some notes about error handling:
...
> > rc must contain only libxl error values.  Most libxl functions return
> > libxl error values, not errno values.
> 
> rc is overwritten later:

I didn't spot that.

> So this whole rc assignment business in the patch was somewhat pointless 
> anyway.

Ah well.

> One question though: should we fail on the timeout and not clean up 
> xenstore and reset the device (which is what this version of the patch 
> does)? Because we may end up with device finally removed and cleanup up 
> by QEMU/guest but not reset and removed from xenstore.

This is a bit of a policy decision.  My initial view is that if the
guest fails to respond to the unplug request, we should just force the
unplug and the guest will have to live with the resulting damage.

At the very least, it must be possible to tear the whole thing down
properly when destroying the domain.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:41:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKsW-0007g3-DB; Fri, 14 Nov 2014 17:41:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpKsU-0007fK-6o
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 17:41:46 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	4D/55-02699-8DE36645; Fri, 14 Nov 2014 17:41:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1415986901!12632880!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5441 invoked from network); 14 Nov 2014 17:41:44 -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;
	14 Nov 2014 17:41:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="191479316"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 12:33:51 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpKkp-00051y-49;
	Fri, 14 Nov 2014 17:33:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpKko-0002JN-AT;
	Fri, 14 Nov 2014 17:33:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.15613.548151.502715@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 17:33:49 +0000
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54663752.5080200@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.11138.483109.931473@mariner.uk.xensource.com>
	<54663752.5080200@oracle.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> On 11/14/2014 11:19 AM, Ian Jackson wrote:
> > The most seriouis is this: you may not call usleep() anywhere inside
> > libxl.  If you want to wait, you must use the callback mechanisms.
> 
> There are already instances of usleep in libxl

Yes.  :-/.

> (e.g. qmp_open(), which is where I got the ~5 seconds number,
> btw). But I agree that callbacks are better here, I didn't think of
> non-xl users.

Right.  In this case the polling loop is worse than in qmp_open,
because a guest which doesn't respond to the pci event can trivially
cause the process to lock up.  (Causing qemu to fail to respond in a
timely fashion is probably possible but harder.)

> > I think that this means:
> >    * [asyncinfying]
> 
> OK, I'll try to see what needs to be done (I am not familiar with how 
> libxl does asynchronous calls)

Thanks.  You probably want to read the CODING_STYLE patch series that
I posted recently.  There are some examples of how to do event
chaining in the domain creation, bootloader execution and disk/vif
handling.

> > Secondly, I'm not particularly keen on polling. Is there not a QMP
> > function that can be used to get notified when the device is really
> > removed ?
> 
> I didn't see any.

Oh well.

> > Finally, some notes about error handling:
...
> > rc must contain only libxl error values.  Most libxl functions return
> > libxl error values, not errno values.
> 
> rc is overwritten later:

I didn't spot that.

> So this whole rc assignment business in the patch was somewhat pointless 
> anyway.

Ah well.

> One question though: should we fail on the timeout and not clean up 
> xenstore and reset the device (which is what this version of the patch 
> does)? Because we may end up with device finally removed and cleanup up 
> by QEMU/guest but not reset and removed from xenstore.

This is a bit of a policy decision.  My initial view is that if the
guest fails to respond to the unplug request, we should just force the
unplug and the guest will have to live with the resulting damage.

At the very least, it must be possible to tear the whole thing down
properly when destroying the domain.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:45:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKwF-00005K-1o; Fri, 14 Nov 2014 17:45:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpKwE-00005F-Ba
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 17:45:38 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	A0/25-31453-1CF36645; Fri, 14 Nov 2014 17:45:37 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415987137!11503975!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13176 invoked from network); 14 Nov 2014 17:45:37 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 17:45:37 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54009 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpKv6-0002x9-PE; Fri, 14 Nov 2014 18:44:28 +0100
Date: Fri, 14 Nov 2014 18:45:34 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <156073497.20141114184534@eikelenboom.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <21606.11847.373254.124439@mariner.uk.xensource.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 5:31:03 PM, you wrote:

> Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>> (Now with Reply-all, sorry)

> Likewise.

>> On 11/14/2014 11:01 AM, Ian Jackson wrote:
>> > What call to xc_physdev_unmap_pirq ?  I see one in the PV path.
>> 
>> At the skip1 label.

> `goto skip1' only appears in the PV path AFAICT.

Not wanting to hijack this thread, but since it addresses a problem i tried to 
report and partly fix earlier, just 3 notes:

1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.

   See this part of an earlier report of mine: 
    http://lists.xen.org/archives/html/xen-devel/2014-10/msg02518.html :

   - When i destroy the guest (instead of shutting it down), 
     "xen_pcibk_disable_msi()" does get called, but then i get an error
     from the toolstack, it reads the /sys/bus/pci/devices/<BDF>/irq value which 
     is still "68" and that is not
     assigned to the guest:
     libxl: error: libxl_pci.c:1319:do_pci_remove: xc_physdev_unmap_pirq irq=68: 
     Invalid argument
     libxl: error: libxl_pci.c:1323:do_pci_remove: xc_domain_irq_permission 
     irq=68: Invalid argument

     On the guest start it called xc_physdev_unmap_pirq and 
     xc_domain_irq_permission for irq=22 ..

  This particular error only occurs when the guest is has enabled MSI, this changes the 
  irq number in /sys/bus/pci/devices/<BDF>/irq to the MSI nr. So on guest 
  destroy it now tries to do things based on the MSI nr instead of the intX irq.

2) When setting and updating the device states in xenstore for a passed through 
   device, libxl doesn't mimic the states pciback and pcifront set and use, very well.
   (see f.e. http://lists.xen.org/archives/html/xen-devel/2014-08/msg00970.html)
   And when 

3) When a HVM guest has multiple pci devices passes through,  pciback doesn't currently get a signal *what* pci-device has 
   been removed from the guest on a 'xl pci-detach', since it only has a watch on the whole pci-root in xenstore, 
   since it doesn't know which device has been yanked out, it also can't clean up everything properly until *all* devices
   have been removed from the guest and the whole pci-root entry gets removed from xenstore.
   The effect is that if you remove only one device from a guest with "xl 
   pci-detach" and then do a "xl pci-assignable-remove" you will run into trouble.

Just my 3 notes and 2 cents on issues related to this code.

> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 17:45:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 17: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 1XpKwF-00005K-1o; Fri, 14 Nov 2014 17:45:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpKwE-00005F-Ba
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 17:45:38 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	A0/25-31453-1CF36645; Fri, 14 Nov 2014 17:45:37 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-206.messagelabs.com!1415987137!11503975!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13176 invoked from network); 14 Nov 2014 17:45:37 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 17:45:37 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54009 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpKv6-0002x9-PE; Fri, 14 Nov 2014 18:44:28 +0100
Date: Fri, 14 Nov 2014 18:45:34 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <156073497.20141114184534@eikelenboom.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <21606.11847.373254.124439@mariner.uk.xensource.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 5:31:03 PM, you wrote:

> Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>> (Now with Reply-all, sorry)

> Likewise.

>> On 11/14/2014 11:01 AM, Ian Jackson wrote:
>> > What call to xc_physdev_unmap_pirq ?  I see one in the PV path.
>> 
>> At the skip1 label.

> `goto skip1' only appears in the PV path AFAICT.

Not wanting to hijack this thread, but since it addresses a problem i tried to 
report and partly fix earlier, just 3 notes:

1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.

   See this part of an earlier report of mine: 
    http://lists.xen.org/archives/html/xen-devel/2014-10/msg02518.html :

   - When i destroy the guest (instead of shutting it down), 
     "xen_pcibk_disable_msi()" does get called, but then i get an error
     from the toolstack, it reads the /sys/bus/pci/devices/<BDF>/irq value which 
     is still "68" and that is not
     assigned to the guest:
     libxl: error: libxl_pci.c:1319:do_pci_remove: xc_physdev_unmap_pirq irq=68: 
     Invalid argument
     libxl: error: libxl_pci.c:1323:do_pci_remove: xc_domain_irq_permission 
     irq=68: Invalid argument

     On the guest start it called xc_physdev_unmap_pirq and 
     xc_domain_irq_permission for irq=22 ..

  This particular error only occurs when the guest is has enabled MSI, this changes the 
  irq number in /sys/bus/pci/devices/<BDF>/irq to the MSI nr. So on guest 
  destroy it now tries to do things based on the MSI nr instead of the intX irq.

2) When setting and updating the device states in xenstore for a passed through 
   device, libxl doesn't mimic the states pciback and pcifront set and use, very well.
   (see f.e. http://lists.xen.org/archives/html/xen-devel/2014-08/msg00970.html)
   And when 

3) When a HVM guest has multiple pci devices passes through,  pciback doesn't currently get a signal *what* pci-device has 
   been removed from the guest on a 'xl pci-detach', since it only has a watch on the whole pci-root in xenstore, 
   since it doesn't know which device has been yanked out, it also can't clean up everything properly until *all* devices
   have been removed from the guest and the whole pci-root entry gets removed from xenstore.
   The effect is that if you remove only one device from a guest with "xl 
   pci-detach" and then do a "xl pci-assignable-remove" you will run into trouble.

Just my 3 notes and 2 cents on issues related to this code.

> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:06:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLGM-0000qu-1l; Fri, 14 Nov 2014 18:06:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XpLGK-0000qp-F6
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 18:06:24 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	D5/A1-27623-F9446645; Fri, 14 Nov 2014 18:06:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415988382!9062675!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1305 invoked from network); 14 Nov 2014 18:06:22 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-14.tower-31.messagelabs.com with SMTP;
	14 Nov 2014 18:06:22 -0000
X-TM-IMSS-Message-ID: <1e6677bd0003a0c6@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 1e6677bd0003a0c6 ;
	Fri, 14 Nov 2014 13:06:38 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAEI5WIH015786; 
	Fri, 14 Nov 2014 13:05:52 -0500
Message-ID: <54664390.3000706@tycho.nsa.gov>
Date: Fri, 14 Nov 2014 13:01:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Emil Condrea <emilcondrea@gmail.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>	<1415181601.11486.69.camel@citrix.com>	<545BEE4F.3080305@tycho.nsa.gov>	<CAAULxKJwTAdVKGrb5p=j701dAO=PWLYsdX6LpYRbmrAUuAM86A@mail.gmail.com>	<545D564E.4000106@tycho.nsa.gov>
	<CAAULxKLkbau3WsLAiAYXee+mtJN6RTtkBHP=W7bOQTa_pE-nEQ@mail.gmail.com>
In-Reply-To: <CAAULxKLkbau3WsLAiAYXee+mtJN6RTtkBHP=W7bOQTa_pE-nEQ@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 09:22 AM, Emil Condrea wrote:
> I modified linux kernel tpm_tis driver to try to start with locality 2. I
> did some logging and after taking a look with dmesg it seems that the IO
> pages for other localities are full with 1.
> in tpm_tis_init:
> for(i=0;i<5;i++){
>      release_locality(chip,i,1);
> }
> ...
> wait_startup(chip,2);
> request_locality(chip,2)
> ...
> TPM_RID(2);//FF
> TPM_RID(0);//64
> Would this mean that Atmel disabled other localities after manufacturing? I
> tried to define a NVRAM index at F200 but I have the same results.

My best guess is that locality 2 is disabled until a DRTM launch is
done.  Since your system does not support a DRTM launch, this guess
cannot easily be tested.

> I see what you mean about changing the DeepQuote behaviour in order to
> provide evidence of the VM launch but I am not sure that I understand what
> is the type of extraInfoFlags and what should it contain. Will the UUIDs
> and vTPM measurements be stored in extraInfoFlags?

extraInfoFlags would be a bitmask defined in a specification, like:

  1 - vTPM UUID present
  2 - vTPM Group UUID present
  4 - vTPM kernel measurement present
  8 - vTPM command line argument measurement present
16 - Group configuration hash present
32 - Group master public key hash present
...

This allows the later fields to be unambiguously decoded by a verifier
without requiring the disclosure of fields that are not needed (for
example, the UUIDs could be omitted for privacy reasons).

> If we take this as a solution for systems that do not support DRTM lanch,
> they will still be forced to use locality 0 if any other is disabled and
> the TPM might return busy if other commands are currently running.
>
> Thanks.
> Emil Condrea
>
> On Sat, Nov 8, 2014 at 1:31 AM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
> wrote:
>
>> On 11/07/2014 05:40 AM, Emil Condrea wrote:
>>
>>> My system does not support DRTM so I can not test this. I am interested in
>>> contributing to vtpm and making this to work without DRTM, can you give me
>>> more details about PCRs that need to be implemented using an alternate
>>> manner? When someone wants to use other locality than 0 it will run all
>>> commands with PCRs disabled? Since the vtpmmgr is tying domU to hardware
>>> TPM, deactivating PCRs will result that all commands issued by domU will
>>> not use PCRs anymore, right?
>>>
>>
>> The PCRs seen by the domU are emulated by the vTPM, and the vTPM Manager
>> has no information on any of their values or updates.  Deep quotes may
>> include a hash of the vTPM's PCR values, but the vTPM Manager is only
>> asserting that the hash was given by the vTPM.
>>
>>   Where should the new layer of PCR values stored? NVRAM ?
>>>
>>
>> They will be stored in the vtpmmgr domain's RAM; in fact, they are already
>> stored there (they just need to be used more directly).
>>
>> The PCRs in question are PCR 20-23, used by the vTPM Manager to store
>> information about the vTPM making a deep quote request.  In order to
>> support more than one vTPM, the values of these PCRs need to be reset when
>> a different client connects.  However, the reset operation for PCR 20-22 is
>> limited to locality 2.
>>
>> An alternative to this is to embed this information in the externData
>> field that is signed by the quote operation.  This requires a bit more work
>> to provide the same flexibility that the PCRs provided, but it can be made
>> equivalently secure.
>>
>> A deep quote request currently contains a PCR mask and a requestData value
>> (20 bytes) from the vTPM.  On a deep quote request, the vTPM Manager:
>>   1. Reset PCR 20-23
>>   2. Extend information about the requesting vTPM to PCR 20-23
>>     - Different information is extended into each PCR
>>     - Some clients want all information, some only want selected PCRs
>>   3. Perform a Quote with externData=requestData on the requested PCRs
>>   4. Return the result to the requesting vTPM
>>
>> The change I am suggesting requires:
>>   - Add a field to the request - extraInfoFlags
>>   - Compute externData = SHA1 (
>>          requestData
>>          extraInfoFlags
>>          [UUIDs if requested]
>>          [vTPM measurements if requested]
>>          [vTPM group update policy if requested]
>>    )
>>   - Perform deep quotes using the above externData value instead of the
>> value provided by the vTPM.
>>
>> This change also has the benefit of increasing the flexibility of the
>> request - it is simple to define additional flags and add data to the hash
>> if needed.
>>
>>
>>   On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>> wrote:
>>>
>>>   On 11/05/2014 05:00 AM, Ian Campbell wrote:
>>>>
>>>>   CCing Daniel.
>>>>>
>>>>> On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
>>>>>
>>>>>
>>>>>> I am wondering if this is known issue that when I set locality!=0 to
>>>>>> vtpmmgr it does not start. It is a bit strange that every call to
>>>>>> tpm_tis_status returns 255 and device-id is also FFFF:
>>>>>> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
>>>>>> TPM interface capabilities (0xffffffff):
>>>>>>
>>>>>> I am configuring vtpmmgr using:
>>>>>>
>>>>>> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
>>>>>> memory=8
>>>>>> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
>>>>>> name="vtpmmgr"
>>>>>> iomem=["fed40,5"]
>>>>>> extra="tpmlocality=2"
>>>>>>
>>>>>>
>>>>>> I also tried using :
>>>>>> iomem=["fed40,1"]
>>>>>> extra="tpmlocality=0"//works well
>>>>>>
>>>>>> or
>>>>>> iomem=["fed42,1"]
>>>>>> extra="tpmlocality=2"
>>>>>> It seems that everything that is not mapped at fed40-fed41 is
>>>>>> FFFFFFFF.
>>>>>>
>>>>>> I have an Atmel TPM chipset.
>>>>>>
>>>>>> Could it be a chipset problem to not handle well different localities?
>>>>>>
>>>>>> When I use locality=0, the device driver info is correct and
>>>>>> everything works fine:
>>>>>> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
>>>>>> TPM interface capabilities (0xfd)
>>>>>>
>>>>>>
>>>>>   This may be an issue with locality 2 being unavailable unless a DRTM
>>>> launch (tboot) is performed.  Returning all-ones is the normal response
>>>> of the x86 chipset when unmapped MMIO regions are accessed; disabled
>>>> localities of the TPM may act like this.
>>>>
>>>> Does your system support the DRTM launch?  If so, can you test it to see
>>>> if this is the issue?
>>>>
>>>> In this case, to better support people who want to use the vTPM Manager
>>>> without a DRTM launch, the features of the vTPM Manager that use the TPM
>>>> 1.2 PCRs may need to be disabled or implemented in an alternate manner
>>>> such as embedding the data in the quote instead of in PCRs.  The current
>>>> design was created with the assumption that systems using it would be
>>>> performing a DRTM launch in order to fully secure the boot process.
>>>>
>>>>    In linux kernel this information is obtained using locality 0 and
>>>>
>>>>> after that other commands execute using specified locality.
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-
>>>>>> stable.git/tree/drivers/char/tpm/tpm_tis.c#n558
>>>>>>
>>>>>>
>>>>>   Have you tested that other localities work for your TPM under Linux?
>>>>
>>>
>>>
>>>
>>>
>>>
>>>>   Thanks,
>>>>>>
>>>>>> Emil
>>>>>>
>>>>>>
>>>>>>   --
>>>> Daniel De Graaf
>>>> National Security Agency
>>>>
>>>>
>>>
>>
>> --
>> Daniel De Graaf
>> National Security Agency
>>
>


-- 
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 Fri Nov 14 18:06:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLGM-0000qu-1l; Fri, 14 Nov 2014 18:06:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XpLGK-0000qp-F6
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 18:06:24 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	D5/A1-27623-F9446645; Fri, 14 Nov 2014 18:06:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415988382!9062675!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1305 invoked from network); 14 Nov 2014 18:06:22 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-14.tower-31.messagelabs.com with SMTP;
	14 Nov 2014 18:06:22 -0000
X-TM-IMSS-Message-ID: <1e6677bd0003a0c6@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 1e6677bd0003a0c6 ;
	Fri, 14 Nov 2014 13:06:38 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAEI5WIH015786; 
	Fri, 14 Nov 2014 13:05:52 -0500
Message-ID: <54664390.3000706@tycho.nsa.gov>
Date: Fri, 14 Nov 2014 13:01:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Emil Condrea <emilcondrea@gmail.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>	<1415181601.11486.69.camel@citrix.com>	<545BEE4F.3080305@tycho.nsa.gov>	<CAAULxKJwTAdVKGrb5p=j701dAO=PWLYsdX6LpYRbmrAUuAM86A@mail.gmail.com>	<545D564E.4000106@tycho.nsa.gov>
	<CAAULxKLkbau3WsLAiAYXee+mtJN6RTtkBHP=W7bOQTa_pE-nEQ@mail.gmail.com>
In-Reply-To: <CAAULxKLkbau3WsLAiAYXee+mtJN6RTtkBHP=W7bOQTa_pE-nEQ@mail.gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 09:22 AM, Emil Condrea wrote:
> I modified linux kernel tpm_tis driver to try to start with locality 2. I
> did some logging and after taking a look with dmesg it seems that the IO
> pages for other localities are full with 1.
> in tpm_tis_init:
> for(i=0;i<5;i++){
>      release_locality(chip,i,1);
> }
> ...
> wait_startup(chip,2);
> request_locality(chip,2)
> ...
> TPM_RID(2);//FF
> TPM_RID(0);//64
> Would this mean that Atmel disabled other localities after manufacturing? I
> tried to define a NVRAM index at F200 but I have the same results.

My best guess is that locality 2 is disabled until a DRTM launch is
done.  Since your system does not support a DRTM launch, this guess
cannot easily be tested.

> I see what you mean about changing the DeepQuote behaviour in order to
> provide evidence of the VM launch but I am not sure that I understand what
> is the type of extraInfoFlags and what should it contain. Will the UUIDs
> and vTPM measurements be stored in extraInfoFlags?

extraInfoFlags would be a bitmask defined in a specification, like:

  1 - vTPM UUID present
  2 - vTPM Group UUID present
  4 - vTPM kernel measurement present
  8 - vTPM command line argument measurement present
16 - Group configuration hash present
32 - Group master public key hash present
...

This allows the later fields to be unambiguously decoded by a verifier
without requiring the disclosure of fields that are not needed (for
example, the UUIDs could be omitted for privacy reasons).

> If we take this as a solution for systems that do not support DRTM lanch,
> they will still be forced to use locality 0 if any other is disabled and
> the TPM might return busy if other commands are currently running.
>
> Thanks.
> Emil Condrea
>
> On Sat, Nov 8, 2014 at 1:31 AM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
> wrote:
>
>> On 11/07/2014 05:40 AM, Emil Condrea wrote:
>>
>>> My system does not support DRTM so I can not test this. I am interested in
>>> contributing to vtpm and making this to work without DRTM, can you give me
>>> more details about PCRs that need to be implemented using an alternate
>>> manner? When someone wants to use other locality than 0 it will run all
>>> commands with PCRs disabled? Since the vtpmmgr is tying domU to hardware
>>> TPM, deactivating PCRs will result that all commands issued by domU will
>>> not use PCRs anymore, right?
>>>
>>
>> The PCRs seen by the domU are emulated by the vTPM, and the vTPM Manager
>> has no information on any of their values or updates.  Deep quotes may
>> include a hash of the vTPM's PCR values, but the vTPM Manager is only
>> asserting that the hash was given by the vTPM.
>>
>>   Where should the new layer of PCR values stored? NVRAM ?
>>>
>>
>> They will be stored in the vtpmmgr domain's RAM; in fact, they are already
>> stored there (they just need to be used more directly).
>>
>> The PCRs in question are PCR 20-23, used by the vTPM Manager to store
>> information about the vTPM making a deep quote request.  In order to
>> support more than one vTPM, the values of these PCRs need to be reset when
>> a different client connects.  However, the reset operation for PCR 20-22 is
>> limited to locality 2.
>>
>> An alternative to this is to embed this information in the externData
>> field that is signed by the quote operation.  This requires a bit more work
>> to provide the same flexibility that the PCRs provided, but it can be made
>> equivalently secure.
>>
>> A deep quote request currently contains a PCR mask and a requestData value
>> (20 bytes) from the vTPM.  On a deep quote request, the vTPM Manager:
>>   1. Reset PCR 20-23
>>   2. Extend information about the requesting vTPM to PCR 20-23
>>     - Different information is extended into each PCR
>>     - Some clients want all information, some only want selected PCRs
>>   3. Perform a Quote with externData=requestData on the requested PCRs
>>   4. Return the result to the requesting vTPM
>>
>> The change I am suggesting requires:
>>   - Add a field to the request - extraInfoFlags
>>   - Compute externData = SHA1 (
>>          requestData
>>          extraInfoFlags
>>          [UUIDs if requested]
>>          [vTPM measurements if requested]
>>          [vTPM group update policy if requested]
>>    )
>>   - Perform deep quotes using the above externData value instead of the
>> value provided by the vTPM.
>>
>> This change also has the benefit of increasing the flexibility of the
>> request - it is simple to define additional flags and add data to the hash
>> if needed.
>>
>>
>>   On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>> wrote:
>>>
>>>   On 11/05/2014 05:00 AM, Ian Campbell wrote:
>>>>
>>>>   CCing Daniel.
>>>>>
>>>>> On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
>>>>>
>>>>>
>>>>>> I am wondering if this is known issue that when I set locality!=0 to
>>>>>> vtpmmgr it does not start. It is a bit strange that every call to
>>>>>> tpm_tis_status returns 255 and device-id is also FFFF:
>>>>>> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
>>>>>> TPM interface capabilities (0xffffffff):
>>>>>>
>>>>>> I am configuring vtpmmgr using:
>>>>>>
>>>>>> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
>>>>>> memory=8
>>>>>> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
>>>>>> name="vtpmmgr"
>>>>>> iomem=["fed40,5"]
>>>>>> extra="tpmlocality=2"
>>>>>>
>>>>>>
>>>>>> I also tried using :
>>>>>> iomem=["fed40,1"]
>>>>>> extra="tpmlocality=0"//works well
>>>>>>
>>>>>> or
>>>>>> iomem=["fed42,1"]
>>>>>> extra="tpmlocality=2"
>>>>>> It seems that everything that is not mapped at fed40-fed41 is
>>>>>> FFFFFFFF.
>>>>>>
>>>>>> I have an Atmel TPM chipset.
>>>>>>
>>>>>> Could it be a chipset problem to not handle well different localities?
>>>>>>
>>>>>> When I use locality=0, the device driver info is correct and
>>>>>> everything works fine:
>>>>>> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40)
>>>>>> TPM interface capabilities (0xfd)
>>>>>>
>>>>>>
>>>>>   This may be an issue with locality 2 being unavailable unless a DRTM
>>>> launch (tboot) is performed.  Returning all-ones is the normal response
>>>> of the x86 chipset when unmapped MMIO regions are accessed; disabled
>>>> localities of the TPM may act like this.
>>>>
>>>> Does your system support the DRTM launch?  If so, can you test it to see
>>>> if this is the issue?
>>>>
>>>> In this case, to better support people who want to use the vTPM Manager
>>>> without a DRTM launch, the features of the vTPM Manager that use the TPM
>>>> 1.2 PCRs may need to be disabled or implemented in an alternate manner
>>>> such as embedding the data in the quote instead of in PCRs.  The current
>>>> design was created with the assumption that systems using it would be
>>>> performing a DRTM launch in order to fully secure the boot process.
>>>>
>>>>    In linux kernel this information is obtained using locality 0 and
>>>>
>>>>> after that other commands execute using specified locality.
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-
>>>>>> stable.git/tree/drivers/char/tpm/tpm_tis.c#n558
>>>>>>
>>>>>>
>>>>>   Have you tested that other localities work for your TPM under Linux?
>>>>
>>>
>>>
>>>
>>>
>>>
>>>>   Thanks,
>>>>>>
>>>>>> Emil
>>>>>>
>>>>>>
>>>>>>   --
>>>> Daniel De Graaf
>>>> National Security Agency
>>>>
>>>>
>>>
>>
>> --
>> Daniel De Graaf
>> National Security Agency
>>
>


-- 
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 Fri Nov 14 18:08:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:08:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLIH-0000wE-Hv; Fri, 14 Nov 2014 18:08: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@citrix.com>) id 1XpLIG-0000w7-Bz
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 18:08:24 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	AA/F7-11581-71546645; Fri, 14 Nov 2014 18:08:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415988501!11501548!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31492 invoked from network); 14 Nov 2014 18:08:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 18:08:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192955826"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:07:48 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLHf-0005ey-PF;
	Fri, 14 Nov 2014 18:07:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLHf-0002cm-7j;
	Fri, 14 Nov 2014 18:07:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.17650.686851.210458@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 18:07:46 +0000
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <156073497.20141114184534@eikelenboom.it>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> 1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.

Yes, but I think that is so only because of the block structure bug
introduced in abfb006f.

> 2) When setting and updating the device states in xenstore for
> a[...]

The rest of your message is difficult to read on my screen due to wrap
damage.  Can you wrap it to <75 characters ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:08:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:08:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLIH-0000wE-Hv; Fri, 14 Nov 2014 18:08: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@citrix.com>) id 1XpLIG-0000w7-Bz
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 18:08:24 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	AA/F7-11581-71546645; Fri, 14 Nov 2014 18:08:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1415988501!11501548!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31492 invoked from network); 14 Nov 2014 18:08:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 18:08:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,386,1413244800"; d="scan'208";a="192955826"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:07:48 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLHf-0005ey-PF;
	Fri, 14 Nov 2014 18:07:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLHf-0002cm-7j;
	Fri, 14 Nov 2014 18:07:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.17650.686851.210458@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 18:07:46 +0000
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <156073497.20141114184534@eikelenboom.it>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
> 1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.

Yes, but I think that is so only because of the block structure bug
introduced in abfb006f.

> 2) When setting and updating the device states in xenstore for
> a[...]

The rest of your message is difficult to read on my screen due to wrap
damage.  Can you wrap it to <75 characters ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:44:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:44:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLqp-0001l3-Lc; Fri, 14 Nov 2014 18:44:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLqo-0001kv-Os
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:44:06 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	C4/17-01660-67D46645; Fri, 14 Nov 2014 18:44:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415990644!11464635!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19943 invoked from network); 14 Nov 2014 18:44:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 18:44:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="192967922"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:43:55 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLqd-0006Ff-5c;
	Fri, 14 Nov 2014 18:43:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLqc-0002lx-Cl;
	Fri, 14 Nov 2014 18:43:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.19817.933930.293751@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 18:43:53 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415622453.25176.4.camel@citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
	<1415622453.25176.4.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] libxl: CODING_STYLE: Much new material
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 1/4] libxl: CODING_STYLE: Much new material"):
> On Wed, 2014-11-05 at 14:43 +0000, Ian Jackson wrote:
> > +The following local variable names should be used where applicable:
> > +
> > +  int rc;    /* a libxl error code - and not anything else */
> > +  int r;     /* the return value from a system call (or libxc call) */
> 
> Quite a bit more "ret" for this one. Probably quite a few are being
> misused as rc too, which is perhaps why you omitted it?

I have avoided specifying `ret' here because ret is used
indiscriminately for pretty much any int returned from a function.

> > +  * If the function is to return a libxl error value, `rc' is
> > +    used to contain the error codem, but it is NOT initialised:
> 
> I suspect this is a typo? (but then I never studied latin...)

Fixed.

> > +  * Function calls which might fail (ie most function calls) are
> > +    handled by putting the return/status value into a variable, and
> > +    then checking it in a separate statement:
> > +            evg->vdev = strdup(vdev);
> > +            if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
> 
> A slightly dodgy example because this should be GCSTRDUP(NOGC, vdev) and
> therefore can't fail ;-)

Example replaced with:
    char *dompath = libxl__xs_get_dompath(gc, bl->domid);
    if (!dompath) { rc = ERROR_FAIL; goto out; }

> > +Nontrivial data structures (in structs) should come with an idempotent
> > +_destroy function, which must free all resources associated with the
> 
> _dispose.

Fixed (twice).

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:44:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:44:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLqp-0001l3-Lc; Fri, 14 Nov 2014 18:44:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLqo-0001kv-Os
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:44:06 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	C4/17-01660-67D46645; Fri, 14 Nov 2014 18:44:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1415990644!11464635!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19943 invoked from network); 14 Nov 2014 18:44:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 18:44:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="192967922"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:43:55 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLqd-0006Ff-5c;
	Fri, 14 Nov 2014 18:43:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLqc-0002lx-Cl;
	Fri, 14 Nov 2014 18:43:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.19817.933930.293751@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 18:43:53 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415622453.25176.4.camel@citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415198630-29937-2-git-send-email-ian.jackson@eu.citrix.com>
	<1415622453.25176.4.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] libxl: CODING_STYLE: Much new material
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 1/4] libxl: CODING_STYLE: Much new material"):
> On Wed, 2014-11-05 at 14:43 +0000, Ian Jackson wrote:
> > +The following local variable names should be used where applicable:
> > +
> > +  int rc;    /* a libxl error code - and not anything else */
> > +  int r;     /* the return value from a system call (or libxc call) */
> 
> Quite a bit more "ret" for this one. Probably quite a few are being
> misused as rc too, which is perhaps why you omitted it?

I have avoided specifying `ret' here because ret is used
indiscriminately for pretty much any int returned from a function.

> > +  * If the function is to return a libxl error value, `rc' is
> > +    used to contain the error codem, but it is NOT initialised:
> 
> I suspect this is a typo? (but then I never studied latin...)

Fixed.

> > +  * Function calls which might fail (ie most function calls) are
> > +    handled by putting the return/status value into a variable, and
> > +    then checking it in a separate statement:
> > +            evg->vdev = strdup(vdev);
> > +            if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
> 
> A slightly dodgy example because this should be GCSTRDUP(NOGC, vdev) and
> therefore can't fail ;-)

Example replaced with:
    char *dompath = libxl__xs_get_dompath(gc, bl->domid);
    if (!dompath) { rc = ERROR_FAIL; goto out; }

> > +Nontrivial data structures (in structs) should come with an idempotent
> > +_destroy function, which must free all resources associated with the
> 
> _dispose.

Fixed (twice).

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:45:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:45:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLrr-0001pB-A0; Fri, 14 Nov 2014 18:45: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@citrix.com>) id 1XpLrq-0001ou-79
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:45:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	29/B7-24532-5BD46645; Fri, 14 Nov 2014 18:45:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415990707!5574987!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23524 invoked from network); 14 Nov 2014 18:45:08 -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;
	14 Nov 2014 18:45:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="192968287"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:45:06 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLrl-0006Gr-G6;
	Fri, 14 Nov 2014 18:45:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLrj-0002m9-Vc;
	Fri, 14 Nov 2014 18:45:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.19887.547217.22359@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 18:45:03 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415622619.25176.6.camel@citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415198630-29937-5-git-send-email-ian.jackson@eu.citrix.com>
	<1415622619.25176.6.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4/4] libxl: CODING_STYLE: Discuss existing
	style problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 4/4] libxl: CODING_STYLE: Discuss existing style problems"):
> On Wed, 2014-11-05 at 14:43 +0000, Ian Jackson wrote:
> > +If it is not feasible to conform fully to the style while patching old
> > +code, without doing substantial style reengineering first, we may
> > +accept patches which contain nonconformant elements, provided that
> > +they don't make the coding style problem worse overall.
> 
> I'd perhaps be a little more explicit and say that the exceptional code
> should conform to the (probably implicit) prevailing style in the area
> so far as that is possible.

Yes, done.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:45:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:45:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLrr-0001pB-A0; Fri, 14 Nov 2014 18:45: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@citrix.com>) id 1XpLrq-0001ou-79
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:45:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	29/B7-24532-5BD46645; Fri, 14 Nov 2014 18:45:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1415990707!5574987!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23524 invoked from network); 14 Nov 2014 18:45:08 -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;
	14 Nov 2014 18:45:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="192968287"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:45:06 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLrl-0006Gr-G6;
	Fri, 14 Nov 2014 18:45:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLrj-0002m9-Vc;
	Fri, 14 Nov 2014 18:45:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21606.19887.547217.22359@mariner.uk.xensource.com>
Date: Fri, 14 Nov 2014 18:45:03 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1415622619.25176.6.camel@citrix.com>
References: <1415198630-29937-1-git-send-email-ian.jackson@eu.citrix.com>
	<1415198630-29937-5-git-send-email-ian.jackson@eu.citrix.com>
	<1415622619.25176.6.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4/4] libxl: CODING_STYLE: Discuss existing
	style problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 4/4] libxl: CODING_STYLE: Discuss existing style problems"):
> On Wed, 2014-11-05 at 14:43 +0000, Ian Jackson wrote:
> > +If it is not feasible to conform fully to the style while patching old
> > +code, without doing substantial style reengineering first, we may
> > +accept patches which contain nonconformant elements, provided that
> > +they don't make the coding style problem worse overall.
> 
> I'd perhaps be a little more explicit and say that the exceptional code
> should conform to the (probably implicit) prevailing style in the area
> so far as that is possible.

Yes, done.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:52:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLzN-0002DX-Nf; Fri, 14 Nov 2014 18:52:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLzM-0002CZ-9z
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:52:56 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	F0/AB-09284-78F46645; Fri, 14 Nov 2014 18:52:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415991173!7077012!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32015 invoked from network); 14 Nov 2014 18:52:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 18:52:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="192971037"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:52:52 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLzD-0006Ni-1G;
	Fri, 14 Nov 2014 18:52:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLzC-0002x8-4T;
	Fri, 14 Nov 2014 18:52:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 14 Nov 2014 18:52:40 +0000
Message-ID: <1415991161-11293-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/4] libxl: CODING_STYLE: Mention function out
	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

We seem to use both `_r' and `_out'.  Document both.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 128cfea..9a1d6e0 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -241,6 +241,9 @@ Local variables used to store return values should have descriptive name
 like "rc" or "ret". Following the same reasoning the label used as exit
 path should be called "out".
 
+Function arguments which are used to return values to the caller
+should be suffixed `_r' or `_out'.
+
 Variables, type names and function names are
 lower_case_with_underscores.
 Type names and function names use the prefix libxl__ when internal to
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:52:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLzG-0002Be-7y; Fri, 14 Nov 2014 18:52:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLzE-0002BZ-Cr
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:52:48 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	83/B4-02696-F7F46645; Fri, 14 Nov 2014 18:52:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415991165!9334768!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23094 invoked from network); 14 Nov 2014 18:52:47 -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;
	14 Nov 2014 18:52:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="191508341"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:52:45 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLzA-0006NZ-8X;
	Fri, 14 Nov 2014 18:52:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLz9-0002wv-HK;
	Fri, 14 Nov 2014 18:52:43 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 14 Nov 2014 18:52:37 +0000
Message-ID: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 structural considerations, error handling patterns, and so on, in
libxl have remained undocumented.  This has been a problem during
recent code submissions and reviews.

In this series I have attempted to document current best practice.
The first patch contains much new material and the others are minor
and consequential fixes.

*1/4 libxl: CODING_STYLE: Much new material
 2/4 libxl: CODING_STYLE: Deprecate `error' for out blocks
 3/4 libxl: CODING_STYLE: Mention function out parameters
*4/4 libxl: CODING_STYLE: Discuss existing style problems

 * = Modified patches, to take into account review comments from
     Ian Campbell.

I would like to suggest that this ought to go into 4.5 because:
 - it would be useful documentation to assist with any nontrivial
   bugfixes that need to be made to libxl
 - there isn't any risk of it actually breaking anything, because
   it's just doc 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 Fri Nov 14 18:52:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLzK-0002C6-Jd; Fri, 14 Nov 2014 18:52:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLzJ-0002Bt-IK
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:52:53 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B9/17-02957-48F46645; Fri, 14 Nov 2014 18:52:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415991165!9334768!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23434 invoked from network); 14 Nov 2014 18:52:51 -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;
	14 Nov 2014 18:52:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="191508364"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:52:50 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLzA-0006Nb-SP;
	Fri, 14 Nov 2014 18:52:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLzA-0002wy-1O;
	Fri, 14 Nov 2014 18:52:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 14 Nov 2014 18:52:38 +0000
Message-ID: <1415991161-11293-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/4] libxl: CODING_STYLE: Much new material
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Discuss:

    Memory allocation
    Conventional variable names
    Convenience macros
    Error handling
    Idempotent data structure construction/destruction
    Asynchronous/long-running operations

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

---
v2: Fix typo `codem'.
    Fix example to use libxl__xs_get_dompath not something that
    ought to be GCSTRDUP.
    Talk about *_dispose not *_destroy.
---
 tools/libxl/CODING_STYLE |  169 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 168 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 110a48f..32d058f 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -1,6 +1,173 @@
-Libxenlight Coding Style
+LIBXENLIGHT CODING STYLE
 ========================
 
+
+MEMORY ALLOCATION
+-----------------
+
+Memory allocation for libxl-internal purposes should normally be done
+with the provided gc mechanisms; there is then no need to free.  See
+"libxl memory management" in libxl.h.
+
+
+CONVENTIONAL VARIABLE NAMES
+---------------------------
+
+The following local variable names should be used where applicable:
+
+  int rc;    /* a libxl error code - and not anything else */
+  int r;     /* the return value from a system call (or libxc call) */
+
+  uint32_t domid;
+  libxl__gc *gc;
+  libxl__egc *egc;
+  libxl__ao *ao;
+
+  libxl_foo_bar_state *fbs;    /* local variable */
+  libxl_foo_bar_state foo_bar; /* inside another state struct */
+
+
+CONVENIENCE MACROS
+------------------
+
+There are a number of convenience macros which shorten the program and
+avoid opportunity for mistakes.  In some cases non-use of the macros
+produces functional bugs or incorrect error handling.  Use the macros
+whenever they are applicable.  For example:
+
+ Usually, don't use:     Instead, use (see libxl_internal.h):
+  libxl__log[v]           LOG, LOGE, LOGEV
+  libxl__sprintf          GCSPRINTF
+  libxl__*alloc et al.    GCNEW, GCNEW_ARRAY, GCREALLOC_ARRAY
+  malloc et al.           GCNEW, GCNEW_ARRAY, GCREALLOC_ARRAY with NOGC
+  isalnum etc. directly   CTYPE
+  libxl__ctx_[un]lock     CTX_LOCK, CTX_UNLOCK
+  gc=...; ao=...;         EGC_GC, AO_GC, STATE_AO_GC
+  explicit gc creation    GC_INIT, GC_FREE
+
+
+ERROR HANDLING
+--------------
+
+Unless, there are good reasons to do otherwise, the following error
+handling and cleanup paradigm should be used:
+
+  * All local variables referring to resources which might need
+    cleaning up are declared at the top of the function, and
+    initialised to a sentinel value indicating "nothing allocated".
+    For example,
+            libxl_evgen_disk_eject *evg = NULL;
+            int nullfd = -1;
+
+  * If the function is to return a libxl error value, `rc' is
+    used to contain the error code, but it is NOT initialised:
+            int rc;
+
+  * There is only one error cleanup path out of the function.  It
+    starts with a label `out:'.  That error cleanup path checks for
+    each allocated resource and frees it iff necessary.  It then
+    returns rc.  For example,
+         out:
+             if (evg) libxl__evdisable_disk_eject(gc, evg);
+             if (nullfd >= 0) close(nullfd);
+             return rc;
+
+  * Function calls which might fail (ie most function calls) are
+    handled by putting the return/status value into a variable, and
+    then checking it in a separate statement:
+            char *dompath = libxl__xs_get_dompath(gc, bl->domid);
+            if (!dompath) { rc = ERROR_FAIL; goto out; }
+
+  * If a resource is freed in the main body of the function (for
+    example, in a loop), the corresponding variable has to be reset to
+    the sentinel at the point where it's freed.
+
+Whether to use the `out' path for successful returns as well as error
+returns is a matter of taste and convenience for the specific
+function.  Not reusing the out path is fine if the duplicated function
+exit code is only `CTX_UNLOCK; GC_FREE;' (or similar).
+
+If you reuse the `out' path for successful returns, there may be
+resources which are to be returned to the caller rather than freed.
+In that case you have to reset the local variable to `nothing here',
+to avoid the resource being freed on the out path.  That resetting
+should be done immediately after the resource value is stored at the
+applicable _r function parameter (or equivalent).  Do not test `rc' in
+the out section, to discover whether to free things.
+
+The uses of the single-line formatting in the examples above are
+permitted exceptions to the usual libxl code formatting rules.
+
+
+
+IDEMPOTENT DATA STRUCTURE CONSTRUCTION/DESTRUCTION
+--------------------------------------------------
+
+Nontrivial data structures (in structs) should come with an idempotent
+_dispose function, which must free all resources associated with the
+data structure (but not free the struct itself).
+
+Such a struct should also come with an _init function which
+initialises the struct so that _dispose is a no-op.
+
+
+ASYNCHRONOUS/LONG-RUNNING OPERATIONS
+------------------------------------
+
+All long-running operations in libxl need to use the asynchronous
+operation machinery.  Consult the programmer documentation in
+libxl_internal.h for details - search for "Machinery for asynchronous
+operations".
+
+The code for asynchronous operations should be laid out in
+chronological order.  That is, where there is a chain of callback
+functions, each subsequent function should be, textually, the next
+function in the file.  This will normally involve predeclaring the
+callback functions.  Synchronous helper functions should be separated
+out into a section preceding the main callback chain.
+
+Control flow arrangements in asynchronous operations should be made as
+simple as possible, because it can otherwise be very hard to see
+through the tangle.
+
+
+When inventing a new sub-operation in asynchronous code, consider
+whether to structure it formally as a sub-operation with its own state
+structure.  (See, for example, libxl__datacopier_*.)
+
+An ao-suboperation state structure should contain, in this order:
+  * fields that the caller must fill in, and which are,
+    effectively, the parameters to the operation, including:
+      - libxl__ao *ao
+      - the callback function pointer(s), which
+        should be named callback or callback_*.
+  * shared information fields or ones used for returning information
+    to the calling operation
+  * private fields
+These sections should be clearly demarcated by comments.
+
+An asynchronous operation should normally have an idempotent stop or
+cancel function.  It should normally also have an _init function for
+its state struct, which arranges that the stop is a no-op.
+
+The permitted order of calls into your ao operation's methods must be
+documented in comments, if it is nontrivial.
+
+
+When using an ao sub-operation, you should normally:
+ * Physically include the sub-operation state struct in your
+   own state struct;
+ * Use CONTAINER_OF to find your own state struct at the start of
+   your implementations of the sub-operation callback functions;
+ * Unconditionally initialise the sub-operation's struct (with its
+   _init method) in your own _init method.
+ * Unconditionally cancel or destroy the sub-operation in your own
+   cancel or destroy method.
+
+
+FORMATTING AND NAMING
+---------------------
+
 Blatantly copied from qemu and linux with few modifications.
 
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:52:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLzM-0002Cz-Vo; Fri, 14 Nov 2014 18:52:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLzL-0002CO-M8
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:52:55 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F4/BC-07724-68F46645; Fri, 14 Nov 2014 18:52:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415991173!7077012!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31994 invoked from network); 14 Nov 2014 18:52:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 18:52:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="192971033"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:52:52 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLzC-0006Nf-IR;
	Fri, 14 Nov 2014 18:52:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLzA-0002x3-LA;
	Fri, 14 Nov 2014 18:52:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 14 Nov 2014 18:52:39 +0000
Message-ID: <1415991161-11293-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/4] libxl: CODING_STYLE: Deprecate `error' for
	out blocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 should have only one name for this and `out' is more prevalent.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 32d058f..128cfea 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -239,7 +239,7 @@ variable that is used to hold a temporary value.
 
 Local variables used to store return values should have descriptive name
 like "rc" or "ret". Following the same reasoning the label used as exit
-path should be called "out" or "error".
+path should be called "out".
 
 Variables, type names and function names are
 lower_case_with_underscores.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:52:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLzN-0002DG-Ad; Fri, 14 Nov 2014 18:52:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLzL-0002CU-U6
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:52:56 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	AE/FC-02712-78F46645; Fri, 14 Nov 2014 18:52:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415991165!9334768!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23481 invoked from network); 14 Nov 2014 18:52:54 -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;
	14 Nov 2014 18:52:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="191508371"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:52:53 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLzD-0006Nl-MU;
	Fri, 14 Nov 2014 18:52:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLzC-0002xD-Rc;
	Fri, 14 Nov 2014 18:52:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 14 Nov 2014 18:52:41 +0000
Message-ID: <1415991161-11293-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/4] libxl: CODING_STYLE: Discuss existing style
	problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Document that:
 - the existing code is not all confirming yet
 - code should conform
 - we will sometimes accept patches with nonconforming elements if
   they don't make matters worse.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

---
v2: When not fixing up existing style problems, new code should
    conform to prevailing existing style nearby.
---
 tools/libxl/CODING_STYLE |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 9a1d6e0..f5b5890 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -2,6 +2,24 @@ LIBXENLIGHT CODING STYLE
 ========================
 
 
+AN APOLOGY AND WARNING
+----------------------
+
+Much of the code in libxl does not yet follow this coding style
+document in every respect.  However, new code is expected to conform.
+
+Patches to improve the style of existing code are welcome.  Please
+separate these out from functional changes.
+
+If it is not feasible to conform fully to the style while patching old
+code, without doing substantial style reengineering first, we may
+accept patches which contain nonconformant elements, provided that
+they don't make the coding style problem worse overall.
+
+In this case, the new code should conform to the prevailing style in
+the area being touched.
+
+
 MEMORY ALLOCATION
 -----------------
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:52:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLzG-0002Be-7y; Fri, 14 Nov 2014 18:52:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLzE-0002BZ-Cr
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:52:48 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	83/B4-02696-F7F46645; Fri, 14 Nov 2014 18:52:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415991165!9334768!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23094 invoked from network); 14 Nov 2014 18:52:47 -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;
	14 Nov 2014 18:52:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="191508341"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:52:45 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLzA-0006NZ-8X;
	Fri, 14 Nov 2014 18:52:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLz9-0002wv-HK;
	Fri, 14 Nov 2014 18:52:43 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 14 Nov 2014 18:52:37 +0000
Message-ID: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 structural considerations, error handling patterns, and so on, in
libxl have remained undocumented.  This has been a problem during
recent code submissions and reviews.

In this series I have attempted to document current best practice.
The first patch contains much new material and the others are minor
and consequential fixes.

*1/4 libxl: CODING_STYLE: Much new material
 2/4 libxl: CODING_STYLE: Deprecate `error' for out blocks
 3/4 libxl: CODING_STYLE: Mention function out parameters
*4/4 libxl: CODING_STYLE: Discuss existing style problems

 * = Modified patches, to take into account review comments from
     Ian Campbell.

I would like to suggest that this ought to go into 4.5 because:
 - it would be useful documentation to assist with any nontrivial
   bugfixes that need to be made to libxl
 - there isn't any risk of it actually breaking anything, because
   it's just doc 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 Fri Nov 14 18:52:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLzN-0002DX-Nf; Fri, 14 Nov 2014 18:52:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLzM-0002CZ-9z
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:52:56 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	F0/AB-09284-78F46645; Fri, 14 Nov 2014 18:52:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415991173!7077012!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32015 invoked from network); 14 Nov 2014 18:52:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 18:52:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="192971037"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:52:52 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLzD-0006Ni-1G;
	Fri, 14 Nov 2014 18:52:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLzC-0002x8-4T;
	Fri, 14 Nov 2014 18:52:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 14 Nov 2014 18:52:40 +0000
Message-ID: <1415991161-11293-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/4] libxl: CODING_STYLE: Mention function out
	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

We seem to use both `_r' and `_out'.  Document both.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 128cfea..9a1d6e0 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -241,6 +241,9 @@ Local variables used to store return values should have descriptive name
 like "rc" or "ret". Following the same reasoning the label used as exit
 path should be called "out".
 
+Function arguments which are used to return values to the caller
+should be suffixed `_r' or `_out'.
+
 Variables, type names and function names are
 lower_case_with_underscores.
 Type names and function names use the prefix libxl__ when internal to
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:52:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLzK-0002C6-Jd; Fri, 14 Nov 2014 18:52:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLzJ-0002Bt-IK
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:52:53 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B9/17-02957-48F46645; Fri, 14 Nov 2014 18:52:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415991165!9334768!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23434 invoked from network); 14 Nov 2014 18:52:51 -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;
	14 Nov 2014 18:52:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="191508364"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:52:50 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLzA-0006Nb-SP;
	Fri, 14 Nov 2014 18:52:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLzA-0002wy-1O;
	Fri, 14 Nov 2014 18:52:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 14 Nov 2014 18:52:38 +0000
Message-ID: <1415991161-11293-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/4] libxl: CODING_STYLE: Much new material
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Discuss:

    Memory allocation
    Conventional variable names
    Convenience macros
    Error handling
    Idempotent data structure construction/destruction
    Asynchronous/long-running operations

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

---
v2: Fix typo `codem'.
    Fix example to use libxl__xs_get_dompath not something that
    ought to be GCSTRDUP.
    Talk about *_dispose not *_destroy.
---
 tools/libxl/CODING_STYLE |  169 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 168 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 110a48f..32d058f 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -1,6 +1,173 @@
-Libxenlight Coding Style
+LIBXENLIGHT CODING STYLE
 ========================
 
+
+MEMORY ALLOCATION
+-----------------
+
+Memory allocation for libxl-internal purposes should normally be done
+with the provided gc mechanisms; there is then no need to free.  See
+"libxl memory management" in libxl.h.
+
+
+CONVENTIONAL VARIABLE NAMES
+---------------------------
+
+The following local variable names should be used where applicable:
+
+  int rc;    /* a libxl error code - and not anything else */
+  int r;     /* the return value from a system call (or libxc call) */
+
+  uint32_t domid;
+  libxl__gc *gc;
+  libxl__egc *egc;
+  libxl__ao *ao;
+
+  libxl_foo_bar_state *fbs;    /* local variable */
+  libxl_foo_bar_state foo_bar; /* inside another state struct */
+
+
+CONVENIENCE MACROS
+------------------
+
+There are a number of convenience macros which shorten the program and
+avoid opportunity for mistakes.  In some cases non-use of the macros
+produces functional bugs or incorrect error handling.  Use the macros
+whenever they are applicable.  For example:
+
+ Usually, don't use:     Instead, use (see libxl_internal.h):
+  libxl__log[v]           LOG, LOGE, LOGEV
+  libxl__sprintf          GCSPRINTF
+  libxl__*alloc et al.    GCNEW, GCNEW_ARRAY, GCREALLOC_ARRAY
+  malloc et al.           GCNEW, GCNEW_ARRAY, GCREALLOC_ARRAY with NOGC
+  isalnum etc. directly   CTYPE
+  libxl__ctx_[un]lock     CTX_LOCK, CTX_UNLOCK
+  gc=...; ao=...;         EGC_GC, AO_GC, STATE_AO_GC
+  explicit gc creation    GC_INIT, GC_FREE
+
+
+ERROR HANDLING
+--------------
+
+Unless, there are good reasons to do otherwise, the following error
+handling and cleanup paradigm should be used:
+
+  * All local variables referring to resources which might need
+    cleaning up are declared at the top of the function, and
+    initialised to a sentinel value indicating "nothing allocated".
+    For example,
+            libxl_evgen_disk_eject *evg = NULL;
+            int nullfd = -1;
+
+  * If the function is to return a libxl error value, `rc' is
+    used to contain the error code, but it is NOT initialised:
+            int rc;
+
+  * There is only one error cleanup path out of the function.  It
+    starts with a label `out:'.  That error cleanup path checks for
+    each allocated resource and frees it iff necessary.  It then
+    returns rc.  For example,
+         out:
+             if (evg) libxl__evdisable_disk_eject(gc, evg);
+             if (nullfd >= 0) close(nullfd);
+             return rc;
+
+  * Function calls which might fail (ie most function calls) are
+    handled by putting the return/status value into a variable, and
+    then checking it in a separate statement:
+            char *dompath = libxl__xs_get_dompath(gc, bl->domid);
+            if (!dompath) { rc = ERROR_FAIL; goto out; }
+
+  * If a resource is freed in the main body of the function (for
+    example, in a loop), the corresponding variable has to be reset to
+    the sentinel at the point where it's freed.
+
+Whether to use the `out' path for successful returns as well as error
+returns is a matter of taste and convenience for the specific
+function.  Not reusing the out path is fine if the duplicated function
+exit code is only `CTX_UNLOCK; GC_FREE;' (or similar).
+
+If you reuse the `out' path for successful returns, there may be
+resources which are to be returned to the caller rather than freed.
+In that case you have to reset the local variable to `nothing here',
+to avoid the resource being freed on the out path.  That resetting
+should be done immediately after the resource value is stored at the
+applicable _r function parameter (or equivalent).  Do not test `rc' in
+the out section, to discover whether to free things.
+
+The uses of the single-line formatting in the examples above are
+permitted exceptions to the usual libxl code formatting rules.
+
+
+
+IDEMPOTENT DATA STRUCTURE CONSTRUCTION/DESTRUCTION
+--------------------------------------------------
+
+Nontrivial data structures (in structs) should come with an idempotent
+_dispose function, which must free all resources associated with the
+data structure (but not free the struct itself).
+
+Such a struct should also come with an _init function which
+initialises the struct so that _dispose is a no-op.
+
+
+ASYNCHRONOUS/LONG-RUNNING OPERATIONS
+------------------------------------
+
+All long-running operations in libxl need to use the asynchronous
+operation machinery.  Consult the programmer documentation in
+libxl_internal.h for details - search for "Machinery for asynchronous
+operations".
+
+The code for asynchronous operations should be laid out in
+chronological order.  That is, where there is a chain of callback
+functions, each subsequent function should be, textually, the next
+function in the file.  This will normally involve predeclaring the
+callback functions.  Synchronous helper functions should be separated
+out into a section preceding the main callback chain.
+
+Control flow arrangements in asynchronous operations should be made as
+simple as possible, because it can otherwise be very hard to see
+through the tangle.
+
+
+When inventing a new sub-operation in asynchronous code, consider
+whether to structure it formally as a sub-operation with its own state
+structure.  (See, for example, libxl__datacopier_*.)
+
+An ao-suboperation state structure should contain, in this order:
+  * fields that the caller must fill in, and which are,
+    effectively, the parameters to the operation, including:
+      - libxl__ao *ao
+      - the callback function pointer(s), which
+        should be named callback or callback_*.
+  * shared information fields or ones used for returning information
+    to the calling operation
+  * private fields
+These sections should be clearly demarcated by comments.
+
+An asynchronous operation should normally have an idempotent stop or
+cancel function.  It should normally also have an _init function for
+its state struct, which arranges that the stop is a no-op.
+
+The permitted order of calls into your ao operation's methods must be
+documented in comments, if it is nontrivial.
+
+
+When using an ao sub-operation, you should normally:
+ * Physically include the sub-operation state struct in your
+   own state struct;
+ * Use CONTAINER_OF to find your own state struct at the start of
+   your implementations of the sub-operation callback functions;
+ * Unconditionally initialise the sub-operation's struct (with its
+   _init method) in your own _init method.
+ * Unconditionally cancel or destroy the sub-operation in your own
+   cancel or destroy method.
+
+
+FORMATTING AND NAMING
+---------------------
+
 Blatantly copied from qemu and linux with few modifications.
 
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:52:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLzM-0002Cz-Vo; Fri, 14 Nov 2014 18:52:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLzL-0002CO-M8
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:52:55 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F4/BC-07724-68F46645; Fri, 14 Nov 2014 18:52:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1415991173!7077012!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31994 invoked from network); 14 Nov 2014 18:52:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 18:52:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="192971033"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:52:52 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLzC-0006Nf-IR;
	Fri, 14 Nov 2014 18:52:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLzA-0002x3-LA;
	Fri, 14 Nov 2014 18:52:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 14 Nov 2014 18:52:39 +0000
Message-ID: <1415991161-11293-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/4] libxl: CODING_STYLE: Deprecate `error' for
	out blocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 should have only one name for this and `out' is more prevalent.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/CODING_STYLE |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 32d058f..128cfea 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -239,7 +239,7 @@ variable that is used to hold a temporary value.
 
 Local variables used to store return values should have descriptive name
 like "rc" or "ret". Following the same reasoning the label used as exit
-path should be called "out" or "error".
+path should be called "out".
 
 Variables, type names and function names are
 lower_case_with_underscores.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:52:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpLzN-0002DG-Ad; Fri, 14 Nov 2014 18:52:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpLzL-0002CU-U6
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:52:56 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	AE/FC-02712-78F46645; Fri, 14 Nov 2014 18:52:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1415991165!9334768!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23481 invoked from network); 14 Nov 2014 18:52:54 -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;
	14 Nov 2014 18:52:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="191508371"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 14 Nov 2014 13:52:53 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpLzD-0006Nl-MU;
	Fri, 14 Nov 2014 18:52:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpLzC-0002xD-Rc;
	Fri, 14 Nov 2014 18:52:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 14 Nov 2014 18:52:41 +0000
Message-ID: <1415991161-11293-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/4] libxl: CODING_STYLE: Discuss existing style
	problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Document that:
 - the existing code is not all confirming yet
 - code should conform
 - we will sometimes accept patches with nonconforming elements if
   they don't make matters worse.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

---
v2: When not fixing up existing style problems, new code should
    conform to prevailing existing style nearby.
---
 tools/libxl/CODING_STYLE |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 9a1d6e0..f5b5890 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -2,6 +2,24 @@ LIBXENLIGHT CODING STYLE
 ========================
 
 
+AN APOLOGY AND WARNING
+----------------------
+
+Much of the code in libxl does not yet follow this coding style
+document in every respect.  However, new code is expected to conform.
+
+Patches to improve the style of existing code are welcome.  Please
+separate these out from functional changes.
+
+If it is not feasible to conform fully to the style while patching old
+code, without doing substantial style reengineering first, we may
+accept patches which contain nonconformant elements, provided that
+they don't make the coding style problem worse overall.
+
+In this case, the new code should conform to the prevailing style in
+the area being touched.
+
+
 MEMORY ALLOCATION
 -----------------
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:57:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:57:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpM3Q-0002pA-DN; Fri, 14 Nov 2014 18:57:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpM3P-0002oz-0j
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:57:07 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	10/73-16982-28056645; Fri, 14 Nov 2014 18:57:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415991424!9069202!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21714 invoked from network); 14 Nov 2014 18:57:05 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 18:57:05 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEIuw02009499
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 18:56:59 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEIuwYn015815
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Nov 2014 18:56:58 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAEIuvAY015791; Fri, 14 Nov 2014 18:56:58 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 10:56:57 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 526C41167A3; Fri, 14 Nov 2014 13:56:56 -0500 (EST)
Date: Fri, 14 Nov 2014 13:56:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Message-ID: <20141114185656.GB20066@laptop.dumpdata.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 06:52:37PM +0000, Ian Jackson wrote:
> The structural considerations, error handling patterns, and so on, in
> libxl have remained undocumented.  This has been a problem during
> recent code submissions and reviews.
> 
> In this series I have attempted to document current best practice.
> The first patch contains much new material and the others are minor
> and consequential fixes.
> 
> *1/4 libxl: CODING_STYLE: Much new material
>  2/4 libxl: CODING_STYLE: Deprecate `error' for out blocks
>  3/4 libxl: CODING_STYLE: Mention function out parameters
> *4/4 libxl: CODING_STYLE: Discuss existing style problems
> 
>  * = Modified patches, to take into account review comments from
>      Ian Campbell.
> 
> I would like to suggest that this ought to go into 4.5 because:
>  - it would be useful documentation to assist with any nontrivial
>    bugfixes that need to be made to libxl
>  - there isn't any risk of it actually breaking anything, because
>    it's just doc changes.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Thanks,
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 18:57:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 18:57:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpM3Q-0002pA-DN; Fri, 14 Nov 2014 18:57:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpM3P-0002oz-0j
	for xen-devel@lists.xensource.com; Fri, 14 Nov 2014 18:57:07 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	10/73-16982-28056645; Fri, 14 Nov 2014 18:57:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1415991424!9069202!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21714 invoked from network); 14 Nov 2014 18:57:05 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 18:57:05 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEIuw02009499
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 18:56:59 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEIuwYn015815
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Nov 2014 18:56:58 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAEIuvAY015791; Fri, 14 Nov 2014 18:56:58 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 10:56:57 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 526C41167A3; Fri, 14 Nov 2014 13:56:56 -0500 (EST)
Date: Fri, 14 Nov 2014 13:56:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Message-ID: <20141114185656.GB20066@laptop.dumpdata.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 06:52:37PM +0000, Ian Jackson wrote:
> The structural considerations, error handling patterns, and so on, in
> libxl have remained undocumented.  This has been a problem during
> recent code submissions and reviews.
> 
> In this series I have attempted to document current best practice.
> The first patch contains much new material and the others are minor
> and consequential fixes.
> 
> *1/4 libxl: CODING_STYLE: Much new material
>  2/4 libxl: CODING_STYLE: Deprecate `error' for out blocks
>  3/4 libxl: CODING_STYLE: Mention function out parameters
> *4/4 libxl: CODING_STYLE: Discuss existing style problems
> 
>  * = Modified patches, to take into account review comments from
>      Ian Campbell.
> 
> I would like to suggest that this ought to go into 4.5 because:
>  - it would be useful documentation to assist with any nontrivial
>    bugfixes that need to be made to libxl
>  - there isn't any risk of it actually breaking anything, because
>    it's just doc changes.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Thanks,
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 19:25:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 19:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpMUO-0003Kr-4a; Fri, 14 Nov 2014 19:25:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpMUL-0003Km-OS
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 19:24:57 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	6C/F4-17958-80756645; Fri, 14 Nov 2014 19:24:56 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415993095!11537856!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27278 invoked from network); 14 Nov 2014 19:24:56 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 19:24:56 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54300 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpMTD-0002Ku-Ea; Fri, 14 Nov 2014 20:23:47 +0100
Date: Fri, 14 Nov 2014 20:24:53 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <433553573.20141114202453@eikelenboom.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <21606.17650.686851.210458@mariner.uk.xensource.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
	<21606.17650.686851.210458@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 7:07:46 PM, you wrote:

> Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>> 1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.

> Yes, but I think that is so only because of the block structure bug
> introduced in abfb006f.

OK, if this code is only for PV guests, this problem could also still be
there for PV guests then (they can also enable MSI AFAIK).

What i saw was that when a guest enables MSI for a device, the value of 
/sys/bus/pci/devices/<BDF>/irq in dom0 changes from the intx to the msi irq 
value. This occurs after libxl has read the irq and has called:

When shutting down the guest disables MSI for that device and the value of 
/sys/bus/pci/devices/<BDF>/irq in dom0 is changed back to the intx irq before
libxl reads it again and calls:

So there is no error.
However in the destroy case the guest doesn't disable MSI, so the value of
/sys/bus/pci/devices/<BDF>/irq in dom0 isn't changed, so libxl tries to operate 
on the wrong value.

I don't know if it is a kernel bug that /sys/bus/pci/devices/<BDF>/irq changes 
when MSI are enabled, or that libxl shouldn't depend on that value.

>> 2) When setting and updating the device states in xenstore for
>> a[...]

> The rest of your message is difficult to read on my screen due to wrap
> damage.  Can you wrap it to <75 characters ?

Hmm it could do with some restructuring an rephrasing as well, sorry for that,
hope it's a bit clearer now (combined note 2 and 3):

2) When setting and updating the device states in xenstore for
   a passed through device, libxl doesn't mimic the states that 
   pciback and pcifront set and use in their "dance", very well.
   (see f.e. http://lists.xen.org/archives/html/xen-devel/2014-08/msg00970.html )

   When a HVM guest has multiple pci devices passed through,
   pciback doesn't currently get a signal *what* pci-device has 
   been removed from the guest on a 'xl pci-detach'.
   
   Pciback currently only has a watch on the whole "pci-root" 
   of a guest in xenstore, so it only knows *something* has changed:
   - in or under the "pci-root" entry
   - In the PV guest case, the xenbus-state of a individual pci device
     node is set to a different state by pcifront, so pciback can take
     action on cleaning up / resetting this particular physical device.
   - In the HVM guest case however, the xenbus-states are don't mimic
     what pcifront does, so pciback doesn't do all the clean up and
     resetting on the physical device  when doing a "xl pci-detach".
     It *does* cleanup when *all* devices and there for the complete"
     "pci-root" entry for a device is yanked out of xenstore. That's why
     you don't get intro trouble when you shutdown a guest with multiple
     devices passed through. You also don't get into trouble when a 
     single device is passed through and removed (the "pci-root" entry in
     xenstore is removed when the last pci device of a guest is removed
     from the guest. 
     But you *do* get into trouble when hot-unplugging
     any but the last device from a guest which has multiple pci devices
     passed through to it. You also won't notice it while it is still
     owned by pciback. You do notice it when you try to do a 
     "xl pci-assignable-remove".

     I tried to fix this my self .. but ran into trouble because when you
     signal pciback via xenstore of the intent of removing a device from the 
     guest, you need a callback but you can also run in to "timeout" issues.
     Another issue was that on shutdown you will remove multiple devices in
     short succession and i ran into locking/race issues, so it clearly 
     became something beyond my skills at that point.

> Thanks,
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 19:25:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 19:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpMUO-0003Kr-4a; Fri, 14 Nov 2014 19:25:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpMUL-0003Km-OS
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 19:24:57 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	6C/F4-17958-80756645; Fri, 14 Nov 2014 19:24:56 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-31.messagelabs.com!1415993095!11537856!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27278 invoked from network); 14 Nov 2014 19:24:56 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 19:24:56 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54300 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpMTD-0002Ku-Ea; Fri, 14 Nov 2014 20:23:47 +0100
Date: Fri, 14 Nov 2014 20:24:53 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <433553573.20141114202453@eikelenboom.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <21606.17650.686851.210458@mariner.uk.xensource.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
	<21606.17650.686851.210458@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 7:07:46 PM, you wrote:

> Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>> 1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.

> Yes, but I think that is so only because of the block structure bug
> introduced in abfb006f.

OK, if this code is only for PV guests, this problem could also still be
there for PV guests then (they can also enable MSI AFAIK).

What i saw was that when a guest enables MSI for a device, the value of 
/sys/bus/pci/devices/<BDF>/irq in dom0 changes from the intx to the msi irq 
value. This occurs after libxl has read the irq and has called:

When shutting down the guest disables MSI for that device and the value of 
/sys/bus/pci/devices/<BDF>/irq in dom0 is changed back to the intx irq before
libxl reads it again and calls:

So there is no error.
However in the destroy case the guest doesn't disable MSI, so the value of
/sys/bus/pci/devices/<BDF>/irq in dom0 isn't changed, so libxl tries to operate 
on the wrong value.

I don't know if it is a kernel bug that /sys/bus/pci/devices/<BDF>/irq changes 
when MSI are enabled, or that libxl shouldn't depend on that value.

>> 2) When setting and updating the device states in xenstore for
>> a[...]

> The rest of your message is difficult to read on my screen due to wrap
> damage.  Can you wrap it to <75 characters ?

Hmm it could do with some restructuring an rephrasing as well, sorry for that,
hope it's a bit clearer now (combined note 2 and 3):

2) When setting and updating the device states in xenstore for
   a passed through device, libxl doesn't mimic the states that 
   pciback and pcifront set and use in their "dance", very well.
   (see f.e. http://lists.xen.org/archives/html/xen-devel/2014-08/msg00970.html )

   When a HVM guest has multiple pci devices passed through,
   pciback doesn't currently get a signal *what* pci-device has 
   been removed from the guest on a 'xl pci-detach'.
   
   Pciback currently only has a watch on the whole "pci-root" 
   of a guest in xenstore, so it only knows *something* has changed:
   - in or under the "pci-root" entry
   - In the PV guest case, the xenbus-state of a individual pci device
     node is set to a different state by pcifront, so pciback can take
     action on cleaning up / resetting this particular physical device.
   - In the HVM guest case however, the xenbus-states are don't mimic
     what pcifront does, so pciback doesn't do all the clean up and
     resetting on the physical device  when doing a "xl pci-detach".
     It *does* cleanup when *all* devices and there for the complete"
     "pci-root" entry for a device is yanked out of xenstore. That's why
     you don't get intro trouble when you shutdown a guest with multiple
     devices passed through. You also don't get into trouble when a 
     single device is passed through and removed (the "pci-root" entry in
     xenstore is removed when the last pci device of a guest is removed
     from the guest. 
     But you *do* get into trouble when hot-unplugging
     any but the last device from a guest which has multiple pci devices
     passed through to it. You also won't notice it while it is still
     owned by pciback. You do notice it when you try to do a 
     "xl pci-assignable-remove".

     I tried to fix this my self .. but ran into trouble because when you
     signal pciback via xenstore of the intent of removing a device from the 
     guest, you need a callback but you can also run in to "timeout" issues.
     Another issue was that on shutdown you will remove multiple devices in
     short succession and i ran into locking/race issues, so it clearly 
     became something beyond my skills at that point.

> Thanks,
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 19:57:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 19:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpMz7-00042E-SV; Fri, 14 Nov 2014 19:56:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpMz6-000429-Vm
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 19:56:45 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	6C/DB-11608-C7E56645; Fri, 14 Nov 2014 19:56:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415995003!11560316!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25292 invoked from network); 14 Nov 2014 19:56:43 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 19:56:43 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54494 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpMxy-0004pR-AZ; Fri, 14 Nov 2014 20:55:34 +0100
Date: Fri, 14 Nov 2014 20:56:40 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <151958463.20141114205640@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141114170528.GC8198@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114170528.GC8198@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 6:05:28 PM, you wrote:

> On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> 
>> Friday, November 14, 2014, 4:43:58 PM, you wrote:
>> 
>> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
>> >> If it still helps i could try Andrews suggestion and try out with only 
>> >> commit aeeea485 ..
>> 
>> > Yes, even if it's pretty certain it's the second of the commits, verifying
>> > this would be helpful (or if the assumption is wrong, the pattern it's
>> > dying with would change and hence perhaps provide further clues).
>> 
>> > Jan
>> 
>> 
>> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
>> pasta without a panic. So it would probably be indeed that specific commit.

> Thank you for confirmation.

> Could you give some specifics on the guests? As in what kind of devices you
> are giving it - and more interestingly - what type of interrupt mechanism
> do they use (/proc/interrupts along with 'dmesg' | grep <name of driver> should
> give some ideas).

> I wouldn't worry about the PV case as that bypasses the dpci codebase - just
> on the HVM side.

> Thanks again!

xen-pciback owns some more devices but these are assigned to started guests:

PV:
03:06.0 Multimedia audio controller: C-Media Electronics Inc CMI8738/CMI8768 PCI Audio (rev 10)
        Subsystem: C-Media Electronics Inc CMI8738/C3DX PCI Audio Device
        Flags: bus master, medium devsel, latency 64, IRQ 22
        I/O ports at 7800 [size=256]
        Capabilities: [c0] Power Management version 2
        Kernel driver in use: pciback

HVM:
04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI])
        Subsystem: Micro-Star International Co., Ltd. Device 4257
        Flags: bus master, fast devsel, latency 0, IRQ 40
        Memory at fddfe000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [50] Power Management version 3
        Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
        Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
        Capabilities: [a0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
        Capabilities: [150] Latency Tolerance Reporting
        Kernel driver in use: pciback

08:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI])
        Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
        Flags: bus master, fast devsel, latency 0, IRQ 37
        Memory at fe0fe000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [50] Power Management version 3
        Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
        Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
        Capabilities: [a0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
        Capabilities: [150] Latency Tolerance Reporting
        Kernel driver in use: pciback

0a:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
        Flags: bus master, fast devsel, latency 0, IRQ 47
        Memory at fe200000 (64-bit, non-prefetchable) [size=2M]
        Capabilities: [40] Express Endpoint, MSI 00
        Capabilities: [80] Power Management version 3
        Capabilities: [90] Vital Product Data
        Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [200] Virtual Channel
        Kernel driver in use: pciback


So for HVM it's two times MSI-X and one time intX (although it should be MSI capable so it seems)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 19:57:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 19:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpMz7-00042E-SV; Fri, 14 Nov 2014 19:56:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpMz6-000429-Vm
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 19:56:45 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	6C/DB-11608-C7E56645; Fri, 14 Nov 2014 19:56:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-31.messagelabs.com!1415995003!11560316!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25292 invoked from network); 14 Nov 2014 19:56:43 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 19:56:43 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54494 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpMxy-0004pR-AZ; Fri, 14 Nov 2014 20:55:34 +0100
Date: Fri, 14 Nov 2014 20:56:40 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <151958463.20141114205640@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141114170528.GC8198@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114170528.GC8198@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 6:05:28 PM, you wrote:

> On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> 
>> Friday, November 14, 2014, 4:43:58 PM, you wrote:
>> 
>> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
>> >> If it still helps i could try Andrews suggestion and try out with only 
>> >> commit aeeea485 ..
>> 
>> > Yes, even if it's pretty certain it's the second of the commits, verifying
>> > this would be helpful (or if the assumption is wrong, the pattern it's
>> > dying with would change and hence perhaps provide further clues).
>> 
>> > Jan
>> 
>> 
>> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
>> pasta without a panic. So it would probably be indeed that specific commit.

> Thank you for confirmation.

> Could you give some specifics on the guests? As in what kind of devices you
> are giving it - and more interestingly - what type of interrupt mechanism
> do they use (/proc/interrupts along with 'dmesg' | grep <name of driver> should
> give some ideas).

> I wouldn't worry about the PV case as that bypasses the dpci codebase - just
> on the HVM side.

> Thanks again!

xen-pciback owns some more devices but these are assigned to started guests:

PV:
03:06.0 Multimedia audio controller: C-Media Electronics Inc CMI8738/CMI8768 PCI Audio (rev 10)
        Subsystem: C-Media Electronics Inc CMI8738/C3DX PCI Audio Device
        Flags: bus master, medium devsel, latency 64, IRQ 22
        I/O ports at 7800 [size=256]
        Capabilities: [c0] Power Management version 2
        Kernel driver in use: pciback

HVM:
04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI])
        Subsystem: Micro-Star International Co., Ltd. Device 4257
        Flags: bus master, fast devsel, latency 0, IRQ 40
        Memory at fddfe000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [50] Power Management version 3
        Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
        Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
        Capabilities: [a0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
        Capabilities: [150] Latency Tolerance Reporting
        Kernel driver in use: pciback

08:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI])
        Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
        Flags: bus master, fast devsel, latency 0, IRQ 37
        Memory at fe0fe000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [50] Power Management version 3
        Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
        Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
        Capabilities: [a0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
        Capabilities: [150] Latency Tolerance Reporting
        Kernel driver in use: pciback

0a:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
        Flags: bus master, fast devsel, latency 0, IRQ 47
        Memory at fe200000 (64-bit, non-prefetchable) [size=2M]
        Capabilities: [40] Express Endpoint, MSI 00
        Capabilities: [80] Power Management version 3
        Capabilities: [90] Vital Product Data
        Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [200] Virtual Channel
        Kernel driver in use: pciback


So for HVM it's two times MSI-X and one time intX (although it should be MSI capable so it seems)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 20:25:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 20: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 1XpNQr-0004fn-A8; Fri, 14 Nov 2014 20:25:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpNQp-0004fi-MQ
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 20:25:23 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	86/11-02559-23566645; Fri, 14 Nov 2014 20:25:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415996720!7266363!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12591 invoked from network); 14 Nov 2014 20:25:21 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 20:25:21 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEKPG6m017980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 20:25:17 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEKPFGD000388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 20:25:16 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEKPEiV000382; Fri, 14 Nov 2014 20:25:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 12:25:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A0BD1116899; Fri, 14 Nov 2014 15:25:13 -0500 (EST)
Date: Fri, 14 Nov 2014 15:25:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141114202513.GA3281@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj"
Content-Disposition: inline
In-Reply-To: <1393541150.20141114175923@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
> 
> Friday, November 14, 2014, 4:43:58 PM, you wrote:
> 
> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
> >> If it still helps i could try Andrews suggestion and try out with only 
> >> commit aeeea485 ..
> 
> > Yes, even if it's pretty certain it's the second of the commits, verifying
> > this would be helpful (or if the assumption is wrong, the pattern it's
> > dying with would change and hence perhaps provide further clues).
> 
> > Jan
> 
> 
> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
> pasta without a panic. So it would probably be indeed that specific commit.

Could you try running with these two patches while you enjoy an beer in the evening?

> 
> --
> Sander
> 

--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-dpci-Add-ZOMBIE-state.patch"

>From b8c267ea34663a9585e1aee9c09dede240b546f9 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 12:15:26 -0500
Subject: [PATCH 1/2] dpci: Add ZOMBIE state.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..8e9141e 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -50,20 +50,25 @@ static DEFINE_PER_CPU(struct list_head, dpci_list);
 
 enum {
     STATE_SCHED,
-    STATE_RUN
+    STATE_RUN,
+    STATE_ZOMBIE
 };
 
 /*
  * This can be called multiple times, but the softirq is only raised once.
- * That is until the STATE_SCHED state has been cleared. The state can be
- * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
- * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
- * the softirq had a chance to run).
+ * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
+ * STATE_SCHED and STATE_ZOMBIE state can be cleared by the 'dpci_softirq'
+ * (when it has executed 'hvm_dirq_assist'). The STATE_SCHED can be cleared
+ * by 'pt_pirq_softirq_reset' (which will try to clear the state before the
+ * softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
 
+    if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+        return;
+
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
@@ -85,7 +90,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
  */
 bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 {
-    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
         return 1;
 
     /*
@@ -109,7 +114,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
 
     ASSERT(spin_is_locked(&d->event_lock));
 
-    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
         /*
@@ -120,6 +125,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
         /* fallthrough. */
     case (1 << STATE_RUN):
     case (1 << STATE_RUN) | (1 << STATE_SCHED):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
         /*
          * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
@@ -779,6 +785,7 @@ unlock:
 static void dpci_softirq(void)
 {
     unsigned int cpu = smp_processor_id();
+    unsigned int reset = 0;
     LIST_HEAD(our_list);
 
     local_irq_disable();
@@ -805,7 +812,15 @@ static void dpci_softirq(void)
             hvm_dirq_assist(d, pirq_dpci);
             put_domain(d);
         }
+        else
+            reset = 1;
+
         clear_bit(STATE_RUN, &pirq_dpci->state);
+        if ( reset )
+        {
+            clear_bit(STATE_ZOMBIE, &pirq_dpci->state);
+            reset = 0;
+        }
     }
 }
 
-- 
1.9.3


--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0002-debug.patch"

>From a4171fa12583eabd126bc5b4c305f49b2fb2b515 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 15:00:39 -0500
Subject: [PATCH 2/2] debug:

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 180 ++++++++++++++++++++++++++++++++++++++++++-
 xen/include/xen/hvm/irq.h    |   2 +
 2 files changed, 178 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 8e9141e..23e5ed1 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -54,6 +54,117 @@ enum {
     STATE_ZOMBIE
 };
 
+struct _debug_f {
+    unsigned int domid;
+    unsigned long count;
+    s_time_t last;
+    struct list_head list;
+    unsigned int state;
+    struct hvm_pirq_dpci *dpci;
+};
+
+struct __debug {
+    struct _debug_f ok;
+    struct _debug_f poison;
+    struct _debug_f raise;
+    struct _debug_f reset;
+    struct _debug_f zombie_softirq;
+    struct _debug_f zombie_raise;
+};
+
+static DEFINE_PER_CPU(struct __debug, _d);
+
+void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
+{
+    if (pirq_dpci->dom)
+        d->domid = pirq_dpci->dom->domain_id;
+    else
+        d->domid = 0xdead;
+    d->count ++;
+    d->last = NOW();
+    d->list.next = pirq_dpci->softirq_list.next;
+    d->list.prev = pirq_dpci->softirq_list.prev;
+    d->state = pirq_dpci->state;
+    d->dpci = pirq_dpci;
+}
+
+enum {
+    Z_SOFTIRQ,
+    Z_RAISE,
+    ERR_POISON,
+    OK_SOFTIRQ,
+    OK_RAISE,
+    OK_RESET,
+};
+
+static void dump_record(struct _debug_f *d, unsigned int type)
+{
+    static const char *const names[] = {
+        [Z_SOFTIRQ]  = "Z-softirq ",
+        [Z_RAISE]    = "Z-raise   ",
+        [ERR_POISON] = "ERR-poison",
+        [OK_SOFTIRQ] = "OK-softirq",
+        [OK_RAISE]   = "OK-raise  ",
+        [OK_RESET]   = "OK-reset  ",
+    };
+#define LONG(x) [_HVM_IRQ_DPCI_##x] = #x
+    static const char *const names_flag[] = {
+        LONG(MACH_PCI_SHIFT),
+        LONG(MAPPED_SHIFT),
+        LONG(EOI_LATCH_SHIFT),
+        LONG(GUEST_PCI_SHIFT),
+        LONG(GUEST_MSI_SHIFT),
+    };
+#undef LONG
+    unsigned int i;
+    s_time_t now;
+
+    if ( d->domid == 0 )
+        return;
+
+    if ( type >= ARRAY_SIZE(names) )
+        BUG();
+
+    now = NOW();
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
+           d->domid, names[type],
+           (unsigned long)((now - d->last) / MILLISECS(1)),
+            d->state, d->count, d->list.prev, d->list.next);
+
+    if ( d->dpci )
+    {
+        struct hvm_pirq_dpci *pirq_dpci = d->dpci;
+
+        for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
+            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
+                printk("%s ", names_flag[i]);
+
+        printk(" PIRQ:%d", pirq_dpci->pirq);
+        if (pirq_dpci->line)
+            printk(" LINE: %d", pirq_dpci->line);
+    }
+    printk("\n");
+    memset(d, 0, sizeof(struct _debug_f));
+}
+
+static void dump_debug(unsigned char key)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu ( cpu )
+    {
+        struct __debug *d;
+        d = &per_cpu(_d, cpu);
+
+        printk("CPU%02d: \n" ,cpu);
+        dump_record(&d->ok, OK_SOFTIRQ);
+        dump_record(&d->raise, OK_RAISE);
+        dump_record(&d->reset, OK_RESET);
+        dump_record(&d->poison, ERR_POISON);
+        dump_record(&d->zombie_softirq, Z_SOFTIRQ);
+        dump_record(&d->zombie_raise, Z_RAISE);
+    }
+}
 /*
  * This can be called multiple times, but the softirq is only raised once.
  * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
@@ -65,13 +176,18 @@ enum {
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
+    struct __debug *d = &__get_cpu_var(_d);
 
     if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+    {
+        _record(&d->zombie_raise, pirq_dpci);
         return;
-
+    }
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
+    _record(&d->raise, pirq_dpci);
+
     get_knownalive_domain(pirq_dpci->dom);
 
     local_irq_save(flags);
@@ -111,9 +227,12 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
 {
     struct domain *d = pirq_dpci->dom;
+    struct __debug *debug = &__get_cpu_var(_d);
 
     ASSERT(spin_is_locked(&d->event_lock));
 
+    _record(&debug->reset, pirq_dpci);
+
     switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
@@ -277,6 +396,7 @@ int pt_irq_create_bind(
              * As such on every 'pt_irq_create_bind' call we MUST set it.
              */
             pirq_dpci->dom = d;
+            pirq_dpci->pirq = pirq;
             /* bind after hvm_irq_dpci is setup to avoid race with irq handler*/
             rc = pirq_guest_bind(d->vcpu[0], info, 0);
             if ( rc == 0 && pt_irq_bind->u.msi.gtable )
@@ -291,6 +411,7 @@ int pt_irq_create_bind(
                      * to be scheduled but we must deal with the one that may be
                      * in the queue.
                      */
+                    pirq_dpci->line = __LINE__;
                     pt_pirq_softirq_reset(pirq_dpci);
                 }
             }
@@ -300,6 +421,7 @@ int pt_irq_create_bind(
                 pirq_dpci->gmsi.gvec = 0;
                 pirq_dpci->dom = NULL;
                 pirq_dpci->flags = 0;
+                pirq_dpci->pirq = -pirq;
                 pirq_cleanup_check(info, d);
                 spin_unlock(&d->event_lock);
                 return rc;
@@ -544,6 +666,7 @@ int pt_irq_destroy_bind(
          * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
          * call to pt_pirq_softirq_reset.
          */
+        pirq_dpci->line = __LINE__;
         pt_pirq_softirq_reset(pirq_dpci);
 
         pirq_cleanup_check(pirq, d);
@@ -778,6 +901,8 @@ unlock:
     spin_unlock(&d->event_lock);
 }
 
+#include <xen/console.h>
+
 /*
  * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
  * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
@@ -787,6 +912,9 @@ static void dpci_softirq(void)
     unsigned int cpu = smp_processor_id();
     unsigned int reset = 0;
     LIST_HEAD(our_list);
+    struct __debug *debug;
+
+    debug = &per_cpu(_d, cpu);
 
     local_irq_disable();
     list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
@@ -796,9 +924,22 @@ static void dpci_softirq(void)
     {
         struct hvm_pirq_dpci *pirq_dpci;
         struct domain *d;
+        struct list_head *entry;
 
         pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
-        list_del(&pirq_dpci->softirq_list);
+        entry = &pirq_dpci->softirq_list;
+        if ( entry->next == LIST_POISON1 || entry->next == LIST_POISON2 ||
+             entry->prev == LIST_POISON2 || entry->prev == LIST_POISON2 )
+        {
+            _record(&debug->poison, pirq_dpci);
+            console_start_sync();
+            dump_debug((char)0);
+            console_end_sync();
+            domain_crash(pirq_dpci->dom);
+            break;
+        }
+        _record(&debug->ok, pirq_dpci);
+        list_del(entry);
 
         d = pirq_dpci->dom;
         smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
@@ -813,8 +954,10 @@ static void dpci_softirq(void)
             put_domain(d);
         }
         else
+        {
+            _record(&debug->zombie_softirq, pirq_dpci);
             reset = 1;
-
+        }
         clear_bit(STATE_RUN, &pirq_dpci->state);
         if ( reset )
         {
@@ -833,6 +976,7 @@ static int cpu_callback(
     {
     case CPU_UP_PREPARE:
         INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        memset(&per_cpu(_d, cpu), 0, sizeof(struct __debug));
         break;
     case CPU_UP_CANCELED:
     case CPU_DEAD:
@@ -854,15 +998,43 @@ static struct notifier_block cpu_nfb = {
     .notifier_call = cpu_callback,
 };
 
+#include <xen/keyhandler.h>
+
+static struct keyhandler dump_debug_keyhandler = {
+    .diagnostic = 1,
+    .u.fn = dump_debug,
+    .desc = "dpci debug stats"
+};
+static struct timer debug_timer;
+static s_time_t last_time = 0;
+static unsigned int debug_cnt = 0;
+
+static void debug_timer_fn(void *d)
+{
+    if ( ( debug_cnt ++ % 10 ) == 0 )
+        printk("--MARK--\n");
+
+    last_time = NOW();
+    set_timer(&debug_timer, last_time + SECONDS(1));
+}
+
 static int __init setup_dpci_softirq(void)
 {
     unsigned int cpu;
 
     for_each_online_cpu(cpu)
+    {
         INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
-
+        memset(&per_cpu(_d, cpu), 0, sizeof(struct __debug));
+    }
     open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
     register_cpu_notifier(&cpu_nfb);
+
+    init_timer(&debug_timer, debug_timer_fn, NULL, smp_processor_id());
+    last_time = NOW();
+    set_timer(&debug_timer, NOW() + SECONDS(1));
+    register_keyhandler('k', &dump_debug_keyhandler);
+
     return 0;
 }
 __initcall(setup_dpci_softirq);
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..1fb1292 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -100,6 +100,8 @@ struct hvm_pirq_dpci {
     struct hvm_gmsi_info gmsi;
     struct timer timer;
     struct list_head softirq_list;
+    unsigned int pirq;
+    unsigned int line;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


--9amGYk9869ThD9tj
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--9amGYk9869ThD9tj--


From xen-devel-bounces@lists.xen.org Fri Nov 14 20:25:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 20: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 1XpNQr-0004fn-A8; Fri, 14 Nov 2014 20:25:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpNQp-0004fi-MQ
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 20:25:23 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	86/11-02559-23566645; Fri, 14 Nov 2014 20:25:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1415996720!7266363!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12591 invoked from network); 14 Nov 2014 20:25:21 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 20:25:21 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEKPG6m017980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 20:25:17 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEKPFGD000388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 20:25:16 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEKPEiV000382; Fri, 14 Nov 2014 20:25:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 12:25:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A0BD1116899; Fri, 14 Nov 2014 15:25:13 -0500 (EST)
Date: Fri, 14 Nov 2014 15:25:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141114202513.GA3281@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj"
Content-Disposition: inline
In-Reply-To: <1393541150.20141114175923@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
> 
> Friday, November 14, 2014, 4:43:58 PM, you wrote:
> 
> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
> >> If it still helps i could try Andrews suggestion and try out with only 
> >> commit aeeea485 ..
> 
> > Yes, even if it's pretty certain it's the second of the commits, verifying
> > this would be helpful (or if the assumption is wrong, the pattern it's
> > dying with would change and hence perhaps provide further clues).
> 
> > Jan
> 
> 
> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
> pasta without a panic. So it would probably be indeed that specific commit.

Could you try running with these two patches while you enjoy an beer in the evening?

> 
> --
> Sander
> 

--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-dpci-Add-ZOMBIE-state.patch"

>From b8c267ea34663a9585e1aee9c09dede240b546f9 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 12:15:26 -0500
Subject: [PATCH 1/2] dpci: Add ZOMBIE state.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..8e9141e 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -50,20 +50,25 @@ static DEFINE_PER_CPU(struct list_head, dpci_list);
 
 enum {
     STATE_SCHED,
-    STATE_RUN
+    STATE_RUN,
+    STATE_ZOMBIE
 };
 
 /*
  * This can be called multiple times, but the softirq is only raised once.
- * That is until the STATE_SCHED state has been cleared. The state can be
- * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
- * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
- * the softirq had a chance to run).
+ * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
+ * STATE_SCHED and STATE_ZOMBIE state can be cleared by the 'dpci_softirq'
+ * (when it has executed 'hvm_dirq_assist'). The STATE_SCHED can be cleared
+ * by 'pt_pirq_softirq_reset' (which will try to clear the state before the
+ * softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
 
+    if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+        return;
+
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
@@ -85,7 +90,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
  */
 bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 {
-    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
         return 1;
 
     /*
@@ -109,7 +114,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
 
     ASSERT(spin_is_locked(&d->event_lock));
 
-    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
         /*
@@ -120,6 +125,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
         /* fallthrough. */
     case (1 << STATE_RUN):
     case (1 << STATE_RUN) | (1 << STATE_SCHED):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
         /*
          * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
@@ -779,6 +785,7 @@ unlock:
 static void dpci_softirq(void)
 {
     unsigned int cpu = smp_processor_id();
+    unsigned int reset = 0;
     LIST_HEAD(our_list);
 
     local_irq_disable();
@@ -805,7 +812,15 @@ static void dpci_softirq(void)
             hvm_dirq_assist(d, pirq_dpci);
             put_domain(d);
         }
+        else
+            reset = 1;
+
         clear_bit(STATE_RUN, &pirq_dpci->state);
+        if ( reset )
+        {
+            clear_bit(STATE_ZOMBIE, &pirq_dpci->state);
+            reset = 0;
+        }
     }
 }
 
-- 
1.9.3


--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0002-debug.patch"

>From a4171fa12583eabd126bc5b4c305f49b2fb2b515 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 15:00:39 -0500
Subject: [PATCH 2/2] debug:

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 180 ++++++++++++++++++++++++++++++++++++++++++-
 xen/include/xen/hvm/irq.h    |   2 +
 2 files changed, 178 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 8e9141e..23e5ed1 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -54,6 +54,117 @@ enum {
     STATE_ZOMBIE
 };
 
+struct _debug_f {
+    unsigned int domid;
+    unsigned long count;
+    s_time_t last;
+    struct list_head list;
+    unsigned int state;
+    struct hvm_pirq_dpci *dpci;
+};
+
+struct __debug {
+    struct _debug_f ok;
+    struct _debug_f poison;
+    struct _debug_f raise;
+    struct _debug_f reset;
+    struct _debug_f zombie_softirq;
+    struct _debug_f zombie_raise;
+};
+
+static DEFINE_PER_CPU(struct __debug, _d);
+
+void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
+{
+    if (pirq_dpci->dom)
+        d->domid = pirq_dpci->dom->domain_id;
+    else
+        d->domid = 0xdead;
+    d->count ++;
+    d->last = NOW();
+    d->list.next = pirq_dpci->softirq_list.next;
+    d->list.prev = pirq_dpci->softirq_list.prev;
+    d->state = pirq_dpci->state;
+    d->dpci = pirq_dpci;
+}
+
+enum {
+    Z_SOFTIRQ,
+    Z_RAISE,
+    ERR_POISON,
+    OK_SOFTIRQ,
+    OK_RAISE,
+    OK_RESET,
+};
+
+static void dump_record(struct _debug_f *d, unsigned int type)
+{
+    static const char *const names[] = {
+        [Z_SOFTIRQ]  = "Z-softirq ",
+        [Z_RAISE]    = "Z-raise   ",
+        [ERR_POISON] = "ERR-poison",
+        [OK_SOFTIRQ] = "OK-softirq",
+        [OK_RAISE]   = "OK-raise  ",
+        [OK_RESET]   = "OK-reset  ",
+    };
+#define LONG(x) [_HVM_IRQ_DPCI_##x] = #x
+    static const char *const names_flag[] = {
+        LONG(MACH_PCI_SHIFT),
+        LONG(MAPPED_SHIFT),
+        LONG(EOI_LATCH_SHIFT),
+        LONG(GUEST_PCI_SHIFT),
+        LONG(GUEST_MSI_SHIFT),
+    };
+#undef LONG
+    unsigned int i;
+    s_time_t now;
+
+    if ( d->domid == 0 )
+        return;
+
+    if ( type >= ARRAY_SIZE(names) )
+        BUG();
+
+    now = NOW();
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
+           d->domid, names[type],
+           (unsigned long)((now - d->last) / MILLISECS(1)),
+            d->state, d->count, d->list.prev, d->list.next);
+
+    if ( d->dpci )
+    {
+        struct hvm_pirq_dpci *pirq_dpci = d->dpci;
+
+        for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
+            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
+                printk("%s ", names_flag[i]);
+
+        printk(" PIRQ:%d", pirq_dpci->pirq);
+        if (pirq_dpci->line)
+            printk(" LINE: %d", pirq_dpci->line);
+    }
+    printk("\n");
+    memset(d, 0, sizeof(struct _debug_f));
+}
+
+static void dump_debug(unsigned char key)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu ( cpu )
+    {
+        struct __debug *d;
+        d = &per_cpu(_d, cpu);
+
+        printk("CPU%02d: \n" ,cpu);
+        dump_record(&d->ok, OK_SOFTIRQ);
+        dump_record(&d->raise, OK_RAISE);
+        dump_record(&d->reset, OK_RESET);
+        dump_record(&d->poison, ERR_POISON);
+        dump_record(&d->zombie_softirq, Z_SOFTIRQ);
+        dump_record(&d->zombie_raise, Z_RAISE);
+    }
+}
 /*
  * This can be called multiple times, but the softirq is only raised once.
  * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
@@ -65,13 +176,18 @@ enum {
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
+    struct __debug *d = &__get_cpu_var(_d);
 
     if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+    {
+        _record(&d->zombie_raise, pirq_dpci);
         return;
-
+    }
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
+    _record(&d->raise, pirq_dpci);
+
     get_knownalive_domain(pirq_dpci->dom);
 
     local_irq_save(flags);
@@ -111,9 +227,12 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
 {
     struct domain *d = pirq_dpci->dom;
+    struct __debug *debug = &__get_cpu_var(_d);
 
     ASSERT(spin_is_locked(&d->event_lock));
 
+    _record(&debug->reset, pirq_dpci);
+
     switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
@@ -277,6 +396,7 @@ int pt_irq_create_bind(
              * As such on every 'pt_irq_create_bind' call we MUST set it.
              */
             pirq_dpci->dom = d;
+            pirq_dpci->pirq = pirq;
             /* bind after hvm_irq_dpci is setup to avoid race with irq handler*/
             rc = pirq_guest_bind(d->vcpu[0], info, 0);
             if ( rc == 0 && pt_irq_bind->u.msi.gtable )
@@ -291,6 +411,7 @@ int pt_irq_create_bind(
                      * to be scheduled but we must deal with the one that may be
                      * in the queue.
                      */
+                    pirq_dpci->line = __LINE__;
                     pt_pirq_softirq_reset(pirq_dpci);
                 }
             }
@@ -300,6 +421,7 @@ int pt_irq_create_bind(
                 pirq_dpci->gmsi.gvec = 0;
                 pirq_dpci->dom = NULL;
                 pirq_dpci->flags = 0;
+                pirq_dpci->pirq = -pirq;
                 pirq_cleanup_check(info, d);
                 spin_unlock(&d->event_lock);
                 return rc;
@@ -544,6 +666,7 @@ int pt_irq_destroy_bind(
          * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
          * call to pt_pirq_softirq_reset.
          */
+        pirq_dpci->line = __LINE__;
         pt_pirq_softirq_reset(pirq_dpci);
 
         pirq_cleanup_check(pirq, d);
@@ -778,6 +901,8 @@ unlock:
     spin_unlock(&d->event_lock);
 }
 
+#include <xen/console.h>
+
 /*
  * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
  * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
@@ -787,6 +912,9 @@ static void dpci_softirq(void)
     unsigned int cpu = smp_processor_id();
     unsigned int reset = 0;
     LIST_HEAD(our_list);
+    struct __debug *debug;
+
+    debug = &per_cpu(_d, cpu);
 
     local_irq_disable();
     list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
@@ -796,9 +924,22 @@ static void dpci_softirq(void)
     {
         struct hvm_pirq_dpci *pirq_dpci;
         struct domain *d;
+        struct list_head *entry;
 
         pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
-        list_del(&pirq_dpci->softirq_list);
+        entry = &pirq_dpci->softirq_list;
+        if ( entry->next == LIST_POISON1 || entry->next == LIST_POISON2 ||
+             entry->prev == LIST_POISON2 || entry->prev == LIST_POISON2 )
+        {
+            _record(&debug->poison, pirq_dpci);
+            console_start_sync();
+            dump_debug((char)0);
+            console_end_sync();
+            domain_crash(pirq_dpci->dom);
+            break;
+        }
+        _record(&debug->ok, pirq_dpci);
+        list_del(entry);
 
         d = pirq_dpci->dom;
         smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
@@ -813,8 +954,10 @@ static void dpci_softirq(void)
             put_domain(d);
         }
         else
+        {
+            _record(&debug->zombie_softirq, pirq_dpci);
             reset = 1;
-
+        }
         clear_bit(STATE_RUN, &pirq_dpci->state);
         if ( reset )
         {
@@ -833,6 +976,7 @@ static int cpu_callback(
     {
     case CPU_UP_PREPARE:
         INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        memset(&per_cpu(_d, cpu), 0, sizeof(struct __debug));
         break;
     case CPU_UP_CANCELED:
     case CPU_DEAD:
@@ -854,15 +998,43 @@ static struct notifier_block cpu_nfb = {
     .notifier_call = cpu_callback,
 };
 
+#include <xen/keyhandler.h>
+
+static struct keyhandler dump_debug_keyhandler = {
+    .diagnostic = 1,
+    .u.fn = dump_debug,
+    .desc = "dpci debug stats"
+};
+static struct timer debug_timer;
+static s_time_t last_time = 0;
+static unsigned int debug_cnt = 0;
+
+static void debug_timer_fn(void *d)
+{
+    if ( ( debug_cnt ++ % 10 ) == 0 )
+        printk("--MARK--\n");
+
+    last_time = NOW();
+    set_timer(&debug_timer, last_time + SECONDS(1));
+}
+
 static int __init setup_dpci_softirq(void)
 {
     unsigned int cpu;
 
     for_each_online_cpu(cpu)
+    {
         INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
-
+        memset(&per_cpu(_d, cpu), 0, sizeof(struct __debug));
+    }
     open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
     register_cpu_notifier(&cpu_nfb);
+
+    init_timer(&debug_timer, debug_timer_fn, NULL, smp_processor_id());
+    last_time = NOW();
+    set_timer(&debug_timer, NOW() + SECONDS(1));
+    register_keyhandler('k', &dump_debug_keyhandler);
+
     return 0;
 }
 __initcall(setup_dpci_softirq);
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..1fb1292 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -100,6 +100,8 @@ struct hvm_pirq_dpci {
     struct hvm_gmsi_info gmsi;
     struct timer timer;
     struct list_head softirq_list;
+    unsigned int pirq;
+    unsigned int line;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


--9amGYk9869ThD9tj
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--9amGYk9869ThD9tj--


From xen-devel-bounces@lists.xen.org Fri Nov 14 21:07:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21:07:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpO4r-0005HL-Nu; Fri, 14 Nov 2014 21:06:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpO4q-0005HE-0s
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:06:44 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	90/F5-28865-3EE66645; Fri, 14 Nov 2014 21:06:43 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415999201!6094101!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25619 invoked from network); 14 Nov 2014 21:06:42 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 21:06:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEL6V0s030996
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 21:06:32 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEL6U4o011411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 21:06:30 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEL6TX0013982; Fri, 14 Nov 2014 21:06:30 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 13:06:29 -0800
Message-ID: <54666F70.7020301@oracle.com>
Date: Fri, 14 Nov 2014 16:09:04 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
	<21606.17650.686851.210458@mariner.uk.xensource.com>
	<433553573.20141114202453@eikelenboom.it>
In-Reply-To: <433553573.20141114202453@eikelenboom.it>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 02:24 PM, Sander Eikelenboom wrote:
> Friday, November 14, 2014, 7:07:46 PM, you wrote:
>
>> Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>>> 1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.
>> Yes, but I think that is so only because of the block structure bug
>> introduced in abfb006f.
> OK, if this code is only for PV guests, this problem could also still be
> there for PV guests then (they can also enable MSI AFAIK).
>
> What i saw was that when a guest enables MSI for a device, the value of
> /sys/bus/pci/devices/<BDF>/irq in dom0 changes from the intx to the msi irq
> value. This occurs after libxl has read the irq and has called:
>
> When shutting down the guest disables MSI for that device and the value of
> /sys/bus/pci/devices/<BDF>/irq in dom0 is changed back to the intx irq before
> libxl reads it again and calls:
>
> So there is no error.
> However in the destroy case the guest doesn't disable MSI, so the value of
> /sys/bus/pci/devices/<BDF>/irq in dom0 isn't changed, so libxl tries to operate
> on the wrong value.
>
> I don't know if it is a kernel bug that /sys/bus/pci/devices/<BDF>/irq changes
> when MSI are enabled, or that libxl shouldn't depend on that value.

I am unable to reproduce irq value change. But I can see that if it 
changes you will see libxl complain since we'd be trying to unmap an irq 
that has not been mapped.

What device are you passing through?


>
>>> 2) When setting and updating the device states in xenstore for
>>> a[...]
>> The rest of your message is difficult to read on my screen due to wrap
>> damage.  Can you wrap it to <75 characters ?
> Hmm it could do with some restructuring an rephrasing as well, sorry for that,
> hope it's a bit clearer now (combined note 2 and 3):
>
> 2) When setting and updating the device states in xenstore for
>     a passed through device, libxl doesn't mimic the states that
>     pciback and pcifront set and use in their "dance", very well.
>     (see f.e. http://lists.xen.org/archives/html/xen-devel/2014-08/msg00970.html )
>
>     When a HVM guest has multiple pci devices passed through,
>     pciback doesn't currently get a signal *what* pci-device has
>     been removed from the guest on a 'xl pci-detach'.
>     
>     Pciback currently only has a watch on the whole "pci-root"
>     of a guest in xenstore, so it only knows *something* has changed:
>     - in or under the "pci-root" entry
>     - In the PV guest case, the xenbus-state of a individual pci device
>       node is set to a different state by pcifront, so pciback can take
>       action on cleaning up / resetting this particular physical device.
>     - In the HVM guest case however, the xenbus-states are don't mimic
>       what pcifront does, so pciback doesn't do all the clean up and
>       resetting on the physical device  when doing a "xl pci-detach".
>       It *does* cleanup when *all* devices and there for the complete"
>       "pci-root" entry for a device is yanked out of xenstore. That's why
>       you don't get intro trouble when you shutdown a guest with multiple
>       devices passed through. You also don't get into trouble when a
>       single device is passed through and removed (the "pci-root" entry in
>       xenstore is removed when the last pci device of a guest is removed
>       from the guest.
>       But you *do* get into trouble when hot-unplugging
>       any but the last device from a guest which has multiple pci devices
>       passed through to it. You also won't notice it while it is still
>       owned by pciback. You do notice it when you try to do a
>       "xl pci-assignable-remove".

I don't know about detach but I apparently can't even properly attach a 
second device --- I get complaints about it already being in xenstore. 
But device does show up in the guest.

And then I can't remove it because, well, it's not in xenstore.

Maybe it has something to do with the fact that both devices are virtual 
functions of the same physical device. I might look at this sometime 
next week.

-boris


>
>       I tried to fix this my self .. but ran into trouble because when you
>       signal pciback via xenstore of the intent of removing a device from the
>       guest, you need a callback but you can also run in to "timeout" issues.
>       Another issue was that on shutdown you will remove multiple devices in
>       short succession and i ran into locking/race issues, so it clearly
>       became something beyond my skills at that point.
>
>> Thanks,
>> Ian.
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 21:07:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21:07:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpO4r-0005HL-Nu; Fri, 14 Nov 2014 21:06:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpO4q-0005HE-0s
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:06:44 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	90/F5-28865-3EE66645; Fri, 14 Nov 2014 21:06:43 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1415999201!6094101!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25619 invoked from network); 14 Nov 2014 21:06:42 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 21:06:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEL6V0s030996
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 21:06:32 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAEL6U4o011411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 21:06:30 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEL6TX0013982; Fri, 14 Nov 2014 21:06:30 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 13:06:29 -0800
Message-ID: <54666F70.7020301@oracle.com>
Date: Fri, 14 Nov 2014 16:09:04 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
	<21606.17650.686851.210458@mariner.uk.xensource.com>
	<433553573.20141114202453@eikelenboom.it>
In-Reply-To: <433553573.20141114202453@eikelenboom.it>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 02:24 PM, Sander Eikelenboom wrote:
> Friday, November 14, 2014, 7:07:46 PM, you wrote:
>
>> Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>>> 1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.
>> Yes, but I think that is so only because of the block structure bug
>> introduced in abfb006f.
> OK, if this code is only for PV guests, this problem could also still be
> there for PV guests then (they can also enable MSI AFAIK).
>
> What i saw was that when a guest enables MSI for a device, the value of
> /sys/bus/pci/devices/<BDF>/irq in dom0 changes from the intx to the msi irq
> value. This occurs after libxl has read the irq and has called:
>
> When shutting down the guest disables MSI for that device and the value of
> /sys/bus/pci/devices/<BDF>/irq in dom0 is changed back to the intx irq before
> libxl reads it again and calls:
>
> So there is no error.
> However in the destroy case the guest doesn't disable MSI, so the value of
> /sys/bus/pci/devices/<BDF>/irq in dom0 isn't changed, so libxl tries to operate
> on the wrong value.
>
> I don't know if it is a kernel bug that /sys/bus/pci/devices/<BDF>/irq changes
> when MSI are enabled, or that libxl shouldn't depend on that value.

I am unable to reproduce irq value change. But I can see that if it 
changes you will see libxl complain since we'd be trying to unmap an irq 
that has not been mapped.

What device are you passing through?


>
>>> 2) When setting and updating the device states in xenstore for
>>> a[...]
>> The rest of your message is difficult to read on my screen due to wrap
>> damage.  Can you wrap it to <75 characters ?
> Hmm it could do with some restructuring an rephrasing as well, sorry for that,
> hope it's a bit clearer now (combined note 2 and 3):
>
> 2) When setting and updating the device states in xenstore for
>     a passed through device, libxl doesn't mimic the states that
>     pciback and pcifront set and use in their "dance", very well.
>     (see f.e. http://lists.xen.org/archives/html/xen-devel/2014-08/msg00970.html )
>
>     When a HVM guest has multiple pci devices passed through,
>     pciback doesn't currently get a signal *what* pci-device has
>     been removed from the guest on a 'xl pci-detach'.
>     
>     Pciback currently only has a watch on the whole "pci-root"
>     of a guest in xenstore, so it only knows *something* has changed:
>     - in or under the "pci-root" entry
>     - In the PV guest case, the xenbus-state of a individual pci device
>       node is set to a different state by pcifront, so pciback can take
>       action on cleaning up / resetting this particular physical device.
>     - In the HVM guest case however, the xenbus-states are don't mimic
>       what pcifront does, so pciback doesn't do all the clean up and
>       resetting on the physical device  when doing a "xl pci-detach".
>       It *does* cleanup when *all* devices and there for the complete"
>       "pci-root" entry for a device is yanked out of xenstore. That's why
>       you don't get intro trouble when you shutdown a guest with multiple
>       devices passed through. You also don't get into trouble when a
>       single device is passed through and removed (the "pci-root" entry in
>       xenstore is removed when the last pci device of a guest is removed
>       from the guest.
>       But you *do* get into trouble when hot-unplugging
>       any but the last device from a guest which has multiple pci devices
>       passed through to it. You also won't notice it while it is still
>       owned by pciback. You do notice it when you try to do a
>       "xl pci-assignable-remove".

I don't know about detach but I apparently can't even properly attach a 
second device --- I get complaints about it already being in xenstore. 
But device does show up in the guest.

And then I can't remove it because, well, it's not in xenstore.

Maybe it has something to do with the fact that both devices are virtual 
functions of the same physical device. I might look at this sometime 
next week.

-boris


>
>       I tried to fix this my self .. but ran into trouble because when you
>       signal pciback via xenstore of the intent of removing a device from the
>       guest, you need a callback but you can also run in to "timeout" issues.
>       Another issue was that on shutdown you will remove multiple devices in
>       short succession and i ran into locking/race issues, so it clearly
>       became something beyond my skills at that point.
>
>> Thanks,
>> Ian.
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 21:08:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpO6R-0005VN-Dg; Fri, 14 Nov 2014 21:08:23 +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 1XpO6Q-0005VC-3u
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:08:22 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	82/74-02698-54F66645; Fri, 14 Nov 2014 21:08:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415999299!8049637!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3055 invoked from network); 14 Nov 2014 21:08:20 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 21:08:20 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEL8Hdv032623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 21:08:18 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEL8GmT005352
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 21:08:17 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEL8FK3020132; Fri, 14 Nov 2014 21:08:16 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 13:08:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9DCAE116902; Fri, 14 Nov 2014 16:08:14 -0500 (EST)
Date: Fri, 14 Nov 2014 16:08:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zir Blazer <zir_blazer@hotmail.com>
Message-ID: <20141114210814.GA4173@laptop.dumpdata.com>
References: <SNT151-W350FF3218816B4188CCE62F3A40@phx.gbl>
	<SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs
 4.3.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 06, 2014 at 03:55:36AM -0300, Zir Blazer wrote:
> There is a regression in both PCI and VGA Passthrough in Xen 4.4.1 when compared to 4.3.2. Due to the added complexity of VGA Passthrough, I was suggested to focus instead in my PCI Passthrough issue, which involves the integrated Sound Card of my Motherboard. While it passes to the DomU and works, it produces robotic, distorted and lagged noise everytime it reproduces sound. The Video Card is an absolute no-go. On the previous Xen version, everything else being equal, both works properly.I have been trying to gather as much information as possible of my issue according to Xen Wiki articles http://wiki.xen.org/wiki/Debugging_Xen and http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen so this E-Mail comes attached with tons of logs.
> 
> 
> HARDWARE
> Processor: Intel Xeon E3-1245V3 (Haswell) - http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
> Motherboard: Supermicro X10SAT (Chipset C226, BIOS R2.0) - http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm
> Sound Card: Integrated Realtek ALC1150

So I tried this on my box which has similar specs:

Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

[    0.000000] DMI: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014

with todays' xen-unstable and with a simple guest config:

builder='hvm'
memory = 2048
name = "WinXP"
vcpus=1
vif = [ 'type=ioemu, mac=00:0F:4B:00:00:61,bridge=switch' ]
disk=[ 'phy:/dev/G/WinXP,hda,w']
vnc=1
videoram=8
vnclisten="0.0.0.0"
vncpasswd=''
stdvga=0
usb=1
usbdevice='tablet'
qemu_model_version="traditional"
device_model_version = 'qemu-xen-traditional'
pci=["01:00.0","01:00.1","00:1b.0"]

# lspci -s 01:00.*
01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
01:00.1 Audio device: ATI Technologies Inc HD48x0 audio

# lspci -s 00:1b.0
00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 04)

This is using Windows XP 32 (don't have 64bit laying around) and when
using the Realtek HD Sound Effects and the '3D Audio Demo' it plays
nicely on my speakers.

The VGA is a different story as it seems there are no Video drivers
for XP for it available at all!

# 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 21:08:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpO6R-0005VN-Dg; Fri, 14 Nov 2014 21:08:23 +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 1XpO6Q-0005VC-3u
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:08:22 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	82/74-02698-54F66645; Fri, 14 Nov 2014 21:08:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1415999299!8049637!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3055 invoked from network); 14 Nov 2014 21:08:20 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 21:08:20 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEL8Hdv032623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 21:08:18 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEL8GmT005352
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 21:08:17 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEL8FK3020132; Fri, 14 Nov 2014 21:08:16 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 13:08:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9DCAE116902; Fri, 14 Nov 2014 16:08:14 -0500 (EST)
Date: Fri, 14 Nov 2014 16:08:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zir Blazer <zir_blazer@hotmail.com>
Message-ID: <20141114210814.GA4173@laptop.dumpdata.com>
References: <SNT151-W350FF3218816B4188CCE62F3A40@phx.gbl>
	<SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs
 4.3.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 06, 2014 at 03:55:36AM -0300, Zir Blazer wrote:
> There is a regression in both PCI and VGA Passthrough in Xen 4.4.1 when compared to 4.3.2. Due to the added complexity of VGA Passthrough, I was suggested to focus instead in my PCI Passthrough issue, which involves the integrated Sound Card of my Motherboard. While it passes to the DomU and works, it produces robotic, distorted and lagged noise everytime it reproduces sound. The Video Card is an absolute no-go. On the previous Xen version, everything else being equal, both works properly.I have been trying to gather as much information as possible of my issue according to Xen Wiki articles http://wiki.xen.org/wiki/Debugging_Xen and http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen so this E-Mail comes attached with tons of logs.
> 
> 
> HARDWARE
> Processor: Intel Xeon E3-1245V3 (Haswell) - http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
> Motherboard: Supermicro X10SAT (Chipset C226, BIOS R2.0) - http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm
> Sound Card: Integrated Realtek ALC1150

So I tried this on my box which has similar specs:

Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

[    0.000000] DMI: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014

with todays' xen-unstable and with a simple guest config:

builder='hvm'
memory = 2048
name = "WinXP"
vcpus=1
vif = [ 'type=ioemu, mac=00:0F:4B:00:00:61,bridge=switch' ]
disk=[ 'phy:/dev/G/WinXP,hda,w']
vnc=1
videoram=8
vnclisten="0.0.0.0"
vncpasswd=''
stdvga=0
usb=1
usbdevice='tablet'
qemu_model_version="traditional"
device_model_version = 'qemu-xen-traditional'
pci=["01:00.0","01:00.1","00:1b.0"]

# lspci -s 01:00.*
01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
01:00.1 Audio device: ATI Technologies Inc HD48x0 audio

# lspci -s 00:1b.0
00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 04)

This is using Windows XP 32 (don't have 64bit laying around) and when
using the Realtek HD Sound Effects and the '3D Audio Demo' it plays
nicely on my speakers.

The VGA is a different story as it seems there are no Video drivers
for XP for it available at all!

# 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 21:20:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21:20:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpOIP-0005pK-NE; Fri, 14 Nov 2014 21:20:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpOIO-0005pD-3y
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:20:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AA/D4-09936-B2276645; Fri, 14 Nov 2014 21:20:43 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416000042!12831040!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15597 invoked from network); 14 Nov 2014 21:20:42 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 21:20:42 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:55004 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpOHF-00033y-79; Fri, 14 Nov 2014 22:19:33 +0100
Date: Fri, 14 Nov 2014 22:20:39 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1106502345.20141114222039@eikelenboom.it>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54666F70.7020301@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
	<21606.17650.686851.210458@mariner.uk.xensource.com>
	<433553573.20141114202453@eikelenboom.it>
	<54666F70.7020301@oracle.com>
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 10:09:04 PM, you wrote:

> On 11/14/2014 02:24 PM, Sander Eikelenboom wrote:
>> Friday, November 14, 2014, 7:07:46 PM, you wrote:
>>
>>> Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>>>> 1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.
>>> Yes, but I think that is so only because of the block structure bug
>>> introduced in abfb006f.
>> OK, if this code is only for PV guests, this problem could also still be
>> there for PV guests then (they can also enable MSI AFAIK).
>>
>> What i saw was that when a guest enables MSI for a device, the value of
>> /sys/bus/pci/devices/<BDF>/irq in dom0 changes from the intx to the msi irq
>> value. This occurs after libxl has read the irq and has called:
>>
>> When shutting down the guest disables MSI for that device and the value of
>> /sys/bus/pci/devices/<BDF>/irq in dom0 is changed back to the intx irq before
>> libxl reads it again and calls:
>>
>> So there is no error.
>> However in the destroy case the guest doesn't disable MSI, so the value of
>> /sys/bus/pci/devices/<BDF>/irq in dom0 isn't changed, so libxl tries to operate
>> on the wrong value.
>>
>> I don't know if it is a kernel bug that /sys/bus/pci/devices/<BDF>/irq changes
>> when MSI are enabled, or that libxl shouldn't depend on that value.

> I am unable to reproduce irq value change. But I can see that if it 
> changes you will see libxl complain since we'd be trying to unmap an irq 
> that has not been mapped.

> What device are you passing through?

Will look at it again this weekend and report back the details of device,
used irq's, kernel version etc, so you can hopefully reproduce.

>>
>>>> 2) When setting and updating the device states in xenstore for
>>>> a[...]
>>> The rest of your message is difficult to read on my screen due to wrap
>>> damage.  Can you wrap it to <75 characters ?
>> Hmm it could do with some restructuring an rephrasing as well, sorry for that,
>> hope it's a bit clearer now (combined note 2 and 3):
>>
>> 2) When setting and updating the device states in xenstore for
>>     a passed through device, libxl doesn't mimic the states that
>>     pciback and pcifront set and use in their "dance", very well.
>>     (see f.e. http://lists.xen.org/archives/html/xen-devel/2014-08/msg00970.html )
>>
>>     When a HVM guest has multiple pci devices passed through,
>>     pciback doesn't currently get a signal *what* pci-device has
>>     been removed from the guest on a 'xl pci-detach'.
>>     
>>     Pciback currently only has a watch on the whole "pci-root"
>>     of a guest in xenstore, so it only knows *something* has changed:
>>     - in or under the "pci-root" entry
>>     - In the PV guest case, the xenbus-state of a individual pci device
>>       node is set to a different state by pcifront, so pciback can take
>>       action on cleaning up / resetting this particular physical device.
>>     - In the HVM guest case however, the xenbus-states are don't mimic
>>       what pcifront does, so pciback doesn't do all the clean up and
>>       resetting on the physical device  when doing a "xl pci-detach".
>>       It *does* cleanup when *all* devices and there for the complete"
>>       "pci-root" entry for a device is yanked out of xenstore. That's why
>>       you don't get intro trouble when you shutdown a guest with multiple
>>       devices passed through. You also don't get into trouble when a
>>       single device is passed through and removed (the "pci-root" entry in
>>       xenstore is removed when the last pci device of a guest is removed
>>       from the guest.
>>       But you *do* get into trouble when hot-unplugging
>>       any but the last device from a guest which has multiple pci devices
>>       passed through to it. You also won't notice it while it is still
>>       owned by pciback. You do notice it when you try to do a
>>       "xl pci-assignable-remove".

> I don't know about detach but I apparently can't even properly attach a 
> second device --- I get complaints about it already being in xenstore. 
> But device does show up in the guest.

> And then I can't remove it because, well, it's not in xenstore.

> Maybe it has something to do with the fact that both devices are virtual 
> functions of the same physical device. I might look at this sometime 
> next week.

Ah .. virtual function as in virtual functions of a SR-IOV NIC ?
or the functions of a multi-function device (the later ends up as separate devices
in a HVM guest (assuming you use qemu-xen and not qemu-traditional)).

Ok wil keep an eye on the mailing list if i can test other help in any other way 
then !

Thx !

Sander

> -boris


>>
>>       I tried to fix this my self .. but ran into trouble because when you
>>       signal pciback via xenstore of the intent of removing a device from the
>>       guest, you need a callback but you can also run in to "timeout" issues.
>>       Another issue was that on shutdown you will remove multiple devices in
>>       short succession and i ran into locking/race issues, so it clearly
>>       became something beyond my skills at that point.
>>
>>> Thanks,
>>> Ian.
>>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 21:20:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21:20:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpOIP-0005pK-NE; Fri, 14 Nov 2014 21:20:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpOIO-0005pD-3y
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:20:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AA/D4-09936-B2276645; Fri, 14 Nov 2014 21:20:43 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416000042!12831040!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15597 invoked from network); 14 Nov 2014 21:20:42 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 21:20:42 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:55004 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpOHF-00033y-79; Fri, 14 Nov 2014 22:19:33 +0100
Date: Fri, 14 Nov 2014 22:20:39 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1106502345.20141114222039@eikelenboom.it>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54666F70.7020301@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
	<21606.17650.686851.210458@mariner.uk.xensource.com>
	<433553573.20141114202453@eikelenboom.it>
	<54666F70.7020301@oracle.com>
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 10:09:04 PM, you wrote:

> On 11/14/2014 02:24 PM, Sander Eikelenboom wrote:
>> Friday, November 14, 2014, 7:07:46 PM, you wrote:
>>
>>> Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down"):
>>>> 1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.
>>> Yes, but I think that is so only because of the block structure bug
>>> introduced in abfb006f.
>> OK, if this code is only for PV guests, this problem could also still be
>> there for PV guests then (they can also enable MSI AFAIK).
>>
>> What i saw was that when a guest enables MSI for a device, the value of
>> /sys/bus/pci/devices/<BDF>/irq in dom0 changes from the intx to the msi irq
>> value. This occurs after libxl has read the irq and has called:
>>
>> When shutting down the guest disables MSI for that device and the value of
>> /sys/bus/pci/devices/<BDF>/irq in dom0 is changed back to the intx irq before
>> libxl reads it again and calls:
>>
>> So there is no error.
>> However in the destroy case the guest doesn't disable MSI, so the value of
>> /sys/bus/pci/devices/<BDF>/irq in dom0 isn't changed, so libxl tries to operate
>> on the wrong value.
>>
>> I don't know if it is a kernel bug that /sys/bus/pci/devices/<BDF>/irq changes
>> when MSI are enabled, or that libxl shouldn't depend on that value.

> I am unable to reproduce irq value change. But I can see that if it 
> changes you will see libxl complain since we'd be trying to unmap an irq 
> that has not been mapped.

> What device are you passing through?

Will look at it again this weekend and report back the details of device,
used irq's, kernel version etc, so you can hopefully reproduce.

>>
>>>> 2) When setting and updating the device states in xenstore for
>>>> a[...]
>>> The rest of your message is difficult to read on my screen due to wrap
>>> damage.  Can you wrap it to <75 characters ?
>> Hmm it could do with some restructuring an rephrasing as well, sorry for that,
>> hope it's a bit clearer now (combined note 2 and 3):
>>
>> 2) When setting and updating the device states in xenstore for
>>     a passed through device, libxl doesn't mimic the states that
>>     pciback and pcifront set and use in their "dance", very well.
>>     (see f.e. http://lists.xen.org/archives/html/xen-devel/2014-08/msg00970.html )
>>
>>     When a HVM guest has multiple pci devices passed through,
>>     pciback doesn't currently get a signal *what* pci-device has
>>     been removed from the guest on a 'xl pci-detach'.
>>     
>>     Pciback currently only has a watch on the whole "pci-root"
>>     of a guest in xenstore, so it only knows *something* has changed:
>>     - in or under the "pci-root" entry
>>     - In the PV guest case, the xenbus-state of a individual pci device
>>       node is set to a different state by pcifront, so pciback can take
>>       action on cleaning up / resetting this particular physical device.
>>     - In the HVM guest case however, the xenbus-states are don't mimic
>>       what pcifront does, so pciback doesn't do all the clean up and
>>       resetting on the physical device  when doing a "xl pci-detach".
>>       It *does* cleanup when *all* devices and there for the complete"
>>       "pci-root" entry for a device is yanked out of xenstore. That's why
>>       you don't get intro trouble when you shutdown a guest with multiple
>>       devices passed through. You also don't get into trouble when a
>>       single device is passed through and removed (the "pci-root" entry in
>>       xenstore is removed when the last pci device of a guest is removed
>>       from the guest.
>>       But you *do* get into trouble when hot-unplugging
>>       any but the last device from a guest which has multiple pci devices
>>       passed through to it. You also won't notice it while it is still
>>       owned by pciback. You do notice it when you try to do a
>>       "xl pci-assignable-remove".

> I don't know about detach but I apparently can't even properly attach a 
> second device --- I get complaints about it already being in xenstore. 
> But device does show up in the guest.

> And then I can't remove it because, well, it's not in xenstore.

> Maybe it has something to do with the fact that both devices are virtual 
> functions of the same physical device. I might look at this sometime 
> next week.

Ah .. virtual function as in virtual functions of a SR-IOV NIC ?
or the functions of a multi-function device (the later ends up as separate devices
in a HVM guest (assuming you use qemu-xen and not qemu-traditional)).

Ok wil keep an eye on the mailing list if i can test other help in any other way 
then !

Thx !

Sander

> -boris


>>
>>       I tried to fix this my self .. but ran into trouble because when you
>>       signal pciback via xenstore of the intent of removing a device from the
>>       guest, you need a callback but you can also run in to "timeout" issues.
>>       Another issue was that on shutdown you will remove multiple devices in
>>       short succession and i ran into locking/race issues, so it clearly
>>       became something beyond my skills at that point.
>>
>>> Thanks,
>>> Ian.
>>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 21:21:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21: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 1XpOIi-0005qn-3F; Fri, 14 Nov 2014 21:21:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gordan@bobich.net>) id 1XpOIg-0005qW-6A
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:21:02 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	38/F3-17694-D3276645; Fri, 14 Nov 2014 21:21:01 +0000
X-Env-Sender: gordan@bobich.net
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416000060!11543074!1
X-Originating-IP: [217.34.137.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20309 invoked from network); 14 Nov 2014 21:21:00 -0000
Received: from host217-34-137-81.in-addr.btopenworld.com (HELO
	external.sentinel2) (217.34.137.81)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 21:21:00 -0000
Received: from [10.2.3.3] (unknown [10.2.3.3])
	(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by external.sentinel2 (Postfix) with ESMTPSA id 10B54221124;
	Fri, 14 Nov 2014 21:20:58 +0000 (GMT)
Message-ID: <54667239.5090300@bobich.net>
Date: Fri, 14 Nov 2014 21:20:57 +0000
From: Gordan Bobic <gordan@bobich.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Zir Blazer <zir_blazer@hotmail.com>
References: <SNT151-W350FF3218816B4188CCE62F3A40@phx.gbl>	<SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>
	<20141114210814.GA4173@laptop.dumpdata.com>
In-Reply-To: <20141114210814.GA4173@laptop.dumpdata.com>
X-Spam-Tests: multi.surbl.org:OK,black.uribl.com:OK
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs
 4.3.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 09:08 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 06, 2014 at 03:55:36AM -0300, Zir Blazer wrote:
>> There is a regression in both PCI and VGA Passthrough in Xen 4.4.1 when compared to 4.3.2. Due to the added complexity of VGA Passthrough, I was suggested to focus instead in my PCI Passthrough issue, which involves the integrated Sound Card of my Motherboard. While it passes to the DomU and works, it produces robotic, distorted and lagged noise everytime it reproduces sound. The Video Card is an absolute no-go. On the previous Xen version, everything else being equal, both works properly.I have been trying to gather as much information as possible of my issue according to Xen Wiki articles http://wiki.xen.org/wiki/Debugging_Xen and http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen so this E-Mail comes attached with tons of logs.
>>
>>
>> HARDWARE
>> Processor: Intel Xeon E3-1245V3 (Haswell) - http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
>> Motherboard: Supermicro X10SAT (Chipset C226, BIOS R2.0) - http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm
>> Sound Card: Integrated Realtek ALC1150
>
> So I tried this on my box which has similar specs:
>
> Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
>
> [    0.000000] DMI: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014
>
> with todays' xen-unstable and with a simple guest config:
>
> builder='hvm'
> memory = 2048
> name = "WinXP"
> vcpus=1
> vif = [ 'type=ioemu, mac=00:0F:4B:00:00:61,bridge=switch' ]
> disk=[ 'phy:/dev/G/WinXP,hda,w']
> vnc=1
> videoram=8
> vnclisten="0.0.0.0"
> vncpasswd=''
> stdvga=0
> usb=1
> usbdevice='tablet'
> qemu_model_version="traditional"
> device_model_version = 'qemu-xen-traditional'
> pci=["01:00.0","01:00.1","00:1b.0"]
>
> # lspci -s 01:00.*
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
> 01:00.1 Audio device: ATI Technologies Inc HD48x0 audio
>
> # lspci -s 00:1b.0
> 00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 04)
>
> This is using Windows XP 32 (don't have 64bit laying around) and when
> using the Realtek HD Sound Effects and the '3D Audio Demo' it plays
> nicely on my speakers.
>
> The VGA is a different story as it seems there are no Video drivers
> for XP for it available at all!

There are definitely drivers for the HD48xx series cards available for 
XP. You'll have to look at legacy drivers since support for HD4xxx 
series is no longer included in the current drivers.

Gordan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 21:21:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21: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 1XpOIi-0005qn-3F; Fri, 14 Nov 2014 21:21:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gordan@bobich.net>) id 1XpOIg-0005qW-6A
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:21:02 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	38/F3-17694-D3276645; Fri, 14 Nov 2014 21:21:01 +0000
X-Env-Sender: gordan@bobich.net
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416000060!11543074!1
X-Originating-IP: [217.34.137.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20309 invoked from network); 14 Nov 2014 21:21:00 -0000
Received: from host217-34-137-81.in-addr.btopenworld.com (HELO
	external.sentinel2) (217.34.137.81)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 21:21:00 -0000
Received: from [10.2.3.3] (unknown [10.2.3.3])
	(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by external.sentinel2 (Postfix) with ESMTPSA id 10B54221124;
	Fri, 14 Nov 2014 21:20:58 +0000 (GMT)
Message-ID: <54667239.5090300@bobich.net>
Date: Fri, 14 Nov 2014 21:20:57 +0000
From: Gordan Bobic <gordan@bobich.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Zir Blazer <zir_blazer@hotmail.com>
References: <SNT151-W350FF3218816B4188CCE62F3A40@phx.gbl>	<SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>
	<20141114210814.GA4173@laptop.dumpdata.com>
In-Reply-To: <20141114210814.GA4173@laptop.dumpdata.com>
X-Spam-Tests: multi.surbl.org:OK,black.uribl.com:OK
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs
 4.3.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 09:08 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 06, 2014 at 03:55:36AM -0300, Zir Blazer wrote:
>> There is a regression in both PCI and VGA Passthrough in Xen 4.4.1 when compared to 4.3.2. Due to the added complexity of VGA Passthrough, I was suggested to focus instead in my PCI Passthrough issue, which involves the integrated Sound Card of my Motherboard. While it passes to the DomU and works, it produces robotic, distorted and lagged noise everytime it reproduces sound. The Video Card is an absolute no-go. On the previous Xen version, everything else being equal, both works properly.I have been trying to gather as much information as possible of my issue according to Xen Wiki articles http://wiki.xen.org/wiki/Debugging_Xen and http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen so this E-Mail comes attached with tons of logs.
>>
>>
>> HARDWARE
>> Processor: Intel Xeon E3-1245V3 (Haswell) - http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
>> Motherboard: Supermicro X10SAT (Chipset C226, BIOS R2.0) - http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm
>> Sound Card: Integrated Realtek ALC1150
>
> So I tried this on my box which has similar specs:
>
> Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
>
> [    0.000000] DMI: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014
>
> with todays' xen-unstable and with a simple guest config:
>
> builder='hvm'
> memory = 2048
> name = "WinXP"
> vcpus=1
> vif = [ 'type=ioemu, mac=00:0F:4B:00:00:61,bridge=switch' ]
> disk=[ 'phy:/dev/G/WinXP,hda,w']
> vnc=1
> videoram=8
> vnclisten="0.0.0.0"
> vncpasswd=''
> stdvga=0
> usb=1
> usbdevice='tablet'
> qemu_model_version="traditional"
> device_model_version = 'qemu-xen-traditional'
> pci=["01:00.0","01:00.1","00:1b.0"]
>
> # lspci -s 01:00.*
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
> 01:00.1 Audio device: ATI Technologies Inc HD48x0 audio
>
> # lspci -s 00:1b.0
> 00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 04)
>
> This is using Windows XP 32 (don't have 64bit laying around) and when
> using the Realtek HD Sound Effects and the '3D Audio Demo' it plays
> nicely on my speakers.
>
> The VGA is a different story as it seems there are no Video drivers
> for XP for it available at all!

There are definitely drivers for the HD48xx series cards available for 
XP. You'll have to look at legacy drivers since support for HD4xxx 
series is no longer included in the current drivers.

Gordan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 21:36:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpOX3-0006M8-He; Fri, 14 Nov 2014 21:35:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpOX2-0006M3-LQ
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:35:52 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	9D/F8-22819-7B576645; Fri, 14 Nov 2014 21:35:51 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416000949!8623183!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30119 invoked from network); 14 Nov 2014 21:35:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 21:35:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAELZcHW002953
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 21:35:39 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAELZaLO006027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 21:35:36 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAELZZjC016777; Fri, 14 Nov 2014 21:35:35 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 13:35:35 -0800
Message-ID: <54667643.7010008@oracle.com>
Date: Fri, 14 Nov 2014 16:38:11 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
	<21606.17650.686851.210458@mariner.uk.xensource.com>
	<433553573.20141114202453@eikelenboom.it>
	<54666F70.7020301@oracle.com>
	<1106502345.20141114222039@eikelenboom.it>
In-Reply-To: <1106502345.20141114222039@eikelenboom.it>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 04:20 PM, Sander Eikelenboom wrote:
> Friday, November 14, 2014, 10:09:04 PM, you wrote:
>
>
>> I don't know about detach but I apparently can't even properly attach a
>> second device --- I get complaints about it already being in xenstore.
>> But device does show up in the guest.
>> And then I can't remove it because, well, it's not in xenstore.
>> Maybe it has something to do with the fact that both devices are virtual
>> functions of the same physical device. I might look at this sometime
>> next week.
> Ah .. virtual function as in virtual functions of a SR-IOV NIC ?
> or the functions of a multi-function device (the later ends up as separate devices
> in a HVM guest (assuming you use qemu-xen and not qemu-traditional)).

Virtual functions of an SR-IOV NIC. I'd think they should show up as separate devices in xenstore. (And they do show up as separate devices in the guest)

And qemu-xen.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 21:36:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpOX3-0006M8-He; Fri, 14 Nov 2014 21:35:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XpOX2-0006M3-LQ
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:35:52 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	9D/F8-22819-7B576645; Fri, 14 Nov 2014 21:35:51 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416000949!8623183!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30119 invoked from network); 14 Nov 2014 21:35:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Nov 2014 21:35:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAELZcHW002953
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 21:35:39 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAELZaLO006027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 21:35:36 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAELZZjC016777; Fri, 14 Nov 2014 21:35:35 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 13:35:35 -0800
Message-ID: <54667643.7010008@oracle.com>
Date: Fri, 14 Nov 2014 16:38:11 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
	<21606.17650.686851.210458@mariner.uk.xensource.com>
	<433553573.20141114202453@eikelenboom.it>
	<54666F70.7020301@oracle.com>
	<1106502345.20141114222039@eikelenboom.it>
In-Reply-To: <1106502345.20141114222039@eikelenboom.it>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
 device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 04:20 PM, Sander Eikelenboom wrote:
> Friday, November 14, 2014, 10:09:04 PM, you wrote:
>
>
>> I don't know about detach but I apparently can't even properly attach a
>> second device --- I get complaints about it already being in xenstore.
>> But device does show up in the guest.
>> And then I can't remove it because, well, it's not in xenstore.
>> Maybe it has something to do with the fact that both devices are virtual
>> functions of the same physical device. I might look at this sometime
>> next week.
> Ah .. virtual function as in virtual functions of a SR-IOV NIC ?
> or the functions of a multi-function device (the later ends up as separate devices
> in a HVM guest (assuming you use qemu-xen and not qemu-traditional)).

Virtual functions of an SR-IOV NIC. I'd think they should show up as separate devices in xenstore. (And they do show up as separate devices in the guest)

And qemu-xen.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 21:50:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpOko-0006cr-Ua; Fri, 14 Nov 2014 21:50:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpOkm-0006cm-Ca
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:50:05 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E7/A0-09936-B0976645; Fri, 14 Nov 2014 21:50:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416001803!12895817!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19454 invoked from network); 14 Nov 2014 21:50:03 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 21:50:03 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:55182 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpOjd-0005Nm-Ro; Fri, 14 Nov 2014 22:48:53 +0100
Date: Fri, 14 Nov 2014 22:50:00 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <135104825.20141114225000@eikelenboom.it>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54667643.7010008@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
	<21606.17650.686851.210458@mariner.uk.xensource.com>
	<433553573.20141114202453@eikelenboom.it>
	<54666F70.7020301@oracle.com>
	<1106502345.20141114222039@eikelenboom.it>
	<54667643.7010008@oracle.com>
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 10:38:11 PM, you wrote:

> On 11/14/2014 04:20 PM, Sander Eikelenboom wrote:
>> Friday, November 14, 2014, 10:09:04 PM, you wrote:
>>
>>
>>> I don't know about detach but I apparently can't even properly attach a
>>> second device --- I get complaints about it already being in xenstore.
>>> But device does show up in the guest.
>>> And then I can't remove it because, well, it's not in xenstore.
>>> Maybe it has something to do with the fact that both devices are virtual
>>> functions of the same physical device. I might look at this sometime
>>> next week.
>> Ah .. virtual function as in virtual functions of a SR-IOV NIC ?
>> or the functions of a multi-function device (the later ends up as separate devices
>> in a HVM guest (assuming you use qemu-xen and not qemu-traditional)).

> Virtual functions of an SR-IOV NIC. I'd think they should show up as separate devices in xenstore. (And they do show up as separate devices in the guest)
> And qemu-xen.

Hmm i thought SR-IOV was in some aspects a special case, also thought i had 
seen some conversation between Jan and Konrad about SR-IOV and device removal
the last week(s). But i don't have a SR-IOV capable NIC, so also no experiences 
related to that.

> -boris




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 21:50:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 21:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpOko-0006cr-Ua; Fri, 14 Nov 2014 21:50:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpOkm-0006cm-Ca
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 21:50:05 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E7/A0-09936-B0976645; Fri, 14 Nov 2014 21:50:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416001803!12895817!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19454 invoked from network); 14 Nov 2014 21:50:03 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 21:50:03 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:55182 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpOjd-0005Nm-Ro; Fri, 14 Nov 2014 22:48:53 +0100
Date: Fri, 14 Nov 2014 22:50:00 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <135104825.20141114225000@eikelenboom.it>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54667643.7010008@oracle.com>
References: <1415661410-5191-1-git-send-email-boris.ostrovsky@oracle.com>
	<1415661410-5191-2-git-send-email-boris.ostrovsky@oracle.com>
	<21606.5282.659930.728522@mariner.uk.xensource.com>
	<54662004.6050702@oracle.com>
	<21606.10103.850619.644934@mariner.uk.xensource.com>
	<54662CB1.2050505@oracle.com>
	<21606.11847.373254.124439@mariner.uk.xensource.com>
	<156073497.20141114184534@eikelenboom.it>
	<21606.17650.686851.210458@mariner.uk.xensource.com>
	<433553573.20141114202453@eikelenboom.it>
	<54666F70.7020301@oracle.com>
	<1106502345.20141114222039@eikelenboom.it>
	<54667643.7010008@oracle.com>
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the
	device before tearing it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 14, 2014, 10:38:11 PM, you wrote:

> On 11/14/2014 04:20 PM, Sander Eikelenboom wrote:
>> Friday, November 14, 2014, 10:09:04 PM, you wrote:
>>
>>
>>> I don't know about detach but I apparently can't even properly attach a
>>> second device --- I get complaints about it already being in xenstore.
>>> But device does show up in the guest.
>>> And then I can't remove it because, well, it's not in xenstore.
>>> Maybe it has something to do with the fact that both devices are virtual
>>> functions of the same physical device. I might look at this sometime
>>> next week.
>> Ah .. virtual function as in virtual functions of a SR-IOV NIC ?
>> or the functions of a multi-function device (the later ends up as separate devices
>> in a HVM guest (assuming you use qemu-xen and not qemu-traditional)).

> Virtual functions of an SR-IOV NIC. I'd think they should show up as separate devices in xenstore. (And they do show up as separate devices in the guest)
> And qemu-xen.

Hmm i thought SR-IOV was in some aspects a special case, also thought i had 
seen some conversation between Jan and Konrad about SR-IOV and device removal
the last week(s). But i don't have a SR-IOV capable NIC, so also no experiences 
related to that.

> -boris




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 22:10:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 22:10:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpP4C-00073z-Q9; Fri, 14 Nov 2014 22:10:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpP4B-00073r-4d
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 22:10:07 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	2F/F1-02699-EBD76645; Fri, 14 Nov 2014 22:10:06 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416003002!12663643!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19111 invoked from network); 14 Nov 2014 22:10:02 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 22:10:02 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:55262 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpP2x-0006x3-SP; Fri, 14 Nov 2014 23:08:52 +0100
Date: Fri, 14 Nov 2014 23:09:58 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1402169526.20141114230958@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141114202513.GA3281@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0FA1682463FBE0669"
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0FA1682463FBE0669
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Friday, November 14, 2014, 9:25:13 PM, you wrote:

> On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> 
>> Friday, November 14, 2014, 4:43:58 PM, you wrote:
>> 
>> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
>> >> If it still helps i could try Andrews suggestion and try out with only 
>> >> commit aeeea485 ..
>> 
>> > Yes, even if it's pretty certain it's the second of the commits, verifying
>> > this would be helpful (or if the assumption is wrong, the pattern it's
>> > dying with would change and hence perhaps provide further clues).
>> 
>> > Jan
>> 
>> 
>> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
>> pasta without a panic. So it would probably be indeed that specific commit.

> Could you try running with these two patches while you enjoy an beer in the evening?

Hmm i didn't expect it not to panic and reboot anymore :-)

However xl dmesg (complete one attached) showed it would have:

(XEN) [2014-11-14 21:35:50.646] --MARK--
(XEN) [2014-11-14 21:35:56.861] grant_table.c:305:d0v0 Increased maptrack size to 9 frames
(XEN) [2014-11-14 21:36:00.647] --MARK--
(XEN) [2014-11-14 21:36:10.410] grant_table.c:1299:d16v1 Expanding dom (16) grant table from (5) to (6) frames.
(XEN) [2014-11-14 21:36:10.820] --MARK--
(XEN) [2014-11-14 21:36:20.820] --MARK--
(XEN) [2014-11-14 21:36:30.820] --MARK--
(XEN) [2014-11-14 21:36:40.821] --MARK--
(XEN) [2014-11-14 21:36:50.821] --MARK--
(XEN) [2014-11-14 21:37:00.388] CPU00:
(XEN) [2014-11-14 21:37:00.399] CPU01:
(XEN) [2014-11-14 21:37:00.410] d16 OK-softirq 20msec ago, state:1, 41220 count, [prev:ffff83054ef5e3e0, next:ffff83054ef5e3e0]  PIRQ:0
(XEN) [2014-11-14 21:37:00.445] d16 OK-raise   46msec ago, state:1, 41223 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
(XEN) [2014-11-14 21:37:00.481] d16 ERR-poison 92msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
(XEN) [2014-11-14 21:37:00.515] d16 Z-softirq  28853msec ago, state:2, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
(XEN) [2014-11-14 21:37:00.551] CPU02:
(XEN) [2014-11-14 21:37:00.561] d17 OK-softirq 43msec ago, state:1, 2381 count, [prev:ffff83054ef47e88, next:ffff83054ef47e88]  PIRQ:87
(XEN) [2014-11-14 21:37:00.597] d17 OK-raise   79msec ago, state:1, 2381 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:87
(XEN) [2014-11-14 21:37:00.633] CPU03:
(XEN) [2014-11-14 21:37:00.643] d16 OK-softirq 274msec ago, state:1, 3216 count, [prev:ffff83054ef37e88, next:ffff83054ef37e88]  PIRQ:87
(XEN) [2014-11-14 21:37:00.679] d16 OK-raise   310msec ago, state:1, 3216 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:87
(XEN) [2014-11-14 21:37:00.715] CPU04:
(XEN) [2014-11-14 21:37:00.726] d17 OK-softirq 108msec ago, state:1, 2872 count, [prev:ffff83054ef27e70, next:ffff83054ef27e70]  PIRQ:87
(XEN) [2014-11-14 21:37:00.762] d17 OK-raise   143msec ago, state:1, 2872 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:87
(XEN) [2014-11-14 21:37:00.798] CPU05:
(XEN) [2014-11-14 21:37:00.808] d17 OK-softirq 590msec ago, state:1, 2287 count, [prev:ffff83054ef1fe70, next:ffff83054ef1fe70]  PIRQ:87--MARK--
(XEN) [2014-11-14 21:37:00.846]
(XEN) [2014-11-14 21:37:00.855] d17 OK-raise   637msec ago, state:1, 2287 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:87
(XEN) [2014-11-14 21:37:00.889] domain_crash called from io.c:938
(XEN) [2014-11-14 21:37:00.889] Domain 16 reported crashed by domain 32767 on cpu#1:
(XEN) [2014-11-14 21:37:10.845] --MARK--
(XEN) [2014-11-14 21:37:20.845] --MARK--


>> 
>> --
>> Sander
>> 
------------0FA1682463FBE0669
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

bmcgTFZUMDogNzAwCihYRU4pIEdldHRpbmcgTFZUMTogNDAwCihYRU4pIGVuYWJsZWQgRXh0
SU5UIG9uIENQVSMwCihYRU4pIEVTUiB2YWx1ZSBiZWZvcmUgZW5hYmxpbmcgdmVjdG9yOiAw
eDQgIGFmdGVyOiAwCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcwooWEVOKSAgLT4gVXNp
bmcgbmV3IEFDSyBtZXRob2QKKFhFTikgaW5pdCBJT19BUElDIElSUXMKKFhFTikgIElPLUFQ
SUMgKGFwaWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0y
MSwgNi0yMiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcs
IDctOCwgNy05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3
LTE3LCA3LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3
LTI2LCA3LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuCihYRU4p
IC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMyPS0xIHBpbjI9LTEK
KFhFTikgbnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4KKFhFTikgbnVtYmVyIG9mIElP
LUFQSUMgIzYgcmVnaXN0ZXJzOiAyNC4KKFhFTikgbnVtYmVyIG9mIElPLUFQSUMgIzcgcmVn
aXN0ZXJzOiAzMi4KKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uCihYRU4pIElPIEFQSUMgIzYuLi4uLi4KKFhFTikgLi4uLiByZWdpc3RlciAjMDA6
IDA2MDAwMDAwCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNgooWEVO
KSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMAooWEVOKSAuLi4uLi4uICAgIDogTFRT
ICAgICAgICAgIDogMAooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzgwMjEKKFhFTikg
Li4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNwooWEVOKSAuLi4u
Li4uICAgICA6IFBSUSBpbXBsZW1lbnRlZDogMQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQ
SUMgdmVyc2lvbjogMDAyMQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYwMDAwMDAKKFhF
TikgLi4uLi4uLiAgICAgOiBhcmJpdHJhdGlvbjogMDYKKFhFTikgLi4uLiByZWdpc3RlciAj
MDM6IDA3MDAwMDAwCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAgICA6IDAKKFhFTikg
Li4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6CihYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJp
ZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgCihYRU4pICAwMCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAwMSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDMwCihYRU4pICAwMiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwCihYRU4pICAwMyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4CihYRU4pICAwNCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYxCihYRU4pICAwNSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwCihYRU4pICAwNiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4CihYRU4pICAwNyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDUwCihYRU4pICAwOCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4CihYRU4pICAwOSAwMDEgMDEgIDEg
ICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAwICAgIDAwCihYRU4pICAwYSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDY4CihYRU4pICAwYiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwCihYRU4pICAwYyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4CihYRU4pICAwZCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDg4CihYRU4pICAwZSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwCihYRU4pICAwZiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDk4CihYRU4pICAxMCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMiAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMyAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNiAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNyAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pIElPIEFQSUMgIzcuLi4u
Li4KKFhFTikgLi4uLiByZWdpc3RlciAjMDA6IDA3MDAwMDAwCihYRU4pIC4uLi4uLi4gICAg
OiBwaHlzaWNhbCBBUElDIGlkOiAwNwooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlw
ZTogMAooWEVOKSAuLi4uLi4uICAgIDogTFRTICAgICAgICAgIDogMAooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMTogMDAxRjgwMjEKKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rp
b24gZW50cmllczogMDAxRgooWEVOKSAuLi4uLi4uICAgICA6IFBSUSBpbXBsZW1lbnRlZDog
MQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMjogMDAwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAgOiBhcmJpdHJhdGlv
bjogMDAKKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6CihYRU4pICBOUiBMb2cg
UGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgCihYRU4pICAw
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
OSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
OSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pIFVz
aW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZwooWEVOKSBJUlEgdG8gcGluIG1hcHBpbmdzOgoo
WEVOKSBJUlEyNDAgLT4gMDoyCihYRU4pIElSUTQ4IC0+IDA6MQooWEVOKSBJUlE1NiAtPiAw
OjMKKFhFTikgSVJRMjQxIC0+IDA6NAooWEVOKSBJUlE2NCAtPiAwOjUKKFhFTikgSVJRNzIg
LT4gMDo2CihYRU4pIElSUTgwIC0+IDA6NwooWEVOKSBJUlE4OCAtPiAwOjgKKFhFTikgSVJR
OTYgLT4gMDo5CihYRU4pIElSUTEwNCAtPiAwOjEwCihYRU4pIElSUTExMiAtPiAwOjExCihY
RU4pIElSUTEyMCAtPiAwOjEyCihYRU4pIElSUTEzNiAtPiAwOjEzCihYRU4pIElSUTE0NCAt
PiAwOjE0CihYRU4pIElSUTE1MiAtPiAwOjE1CihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLiBkb25lLgooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGlu
dGVycnVwdHMuCihYRU4pIGNhbGlicmF0aW5nIEFQSUMgdGltZXIgLi4uCihYRU4pIC4uLi4u
IENQVSBjbG9jayBzcGVlZCBpcyAzMjAwLjE1MzEgTUh6LgooWEVOKSAuLi4uLiBob3N0IGJ1
cyBjbG9jayBzcGVlZCBpcyAyMDAuMDA5NCBNSHouCihYRU4pIC4uLi4uIGJ1c19zY2FsZSA9
IDB4Y2NkNwooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS41NjVdIFBsYXRmb3JtIHRpbWVy
IGlzIDE0LjMxOE1IeiBIUEVUCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjQ5LjU4Nl0gQWxs
b2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0
OjQ5LjU5Ml0gSFZNOiBBU0lEcyBlbmFibGVkLgooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0
OS41OThdIFNWTTogU3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOgooWEVOKSBbMjAxNC0x
MS0xNCAyMToyNDo0OS42MDRdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQooWEVOKSBb
MjAxNC0xMS0xNCAyMToyNDo0OS42MTBdICAtIExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBW
aXJ0dWFsaXNhdGlvbgooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS42MTZdICAtIE5leHQt
UklQIFNhdmVkIG9uICNWTUVYSVQKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NDkuNjIyXSAg
LSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVyCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjQ5LjYy
OV0gSFZNOiBTVk0gZW5hYmxlZAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS42MzVdIEhW
TTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVApIGRldGVjdGVkCihYRU4pIFsyMDE0
LTExLTE0IDIxOjI0OjQ5LjY0MV0gSFZNOiBIQVAgcGFnZSBzaXplczogNGtCLCAyTUIsIDFH
QgooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS42NDhdIEhWTTogUFZIIG1vZGUgbm90IHN1
cHBvcnRlZCBvbiB0aGlzIHBsYXRmb3JtCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjQ5LjY3
NF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS43
MDFdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzIKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NDku
NzI4XSBtYXNrZWQgRXh0SU5UIG9uIENQVSMzCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjQ5
Ljc1NF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0
OS43ODFdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzUKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6
NDkuNzg3XSBCcm91Z2h0IHVwIDYgQ1BVcwooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS43
OTddIEhQRVQ6IDMgdGltZXJzIHVzYWJsZSBmb3IgYnJvYWRjYXN0ICgzIHRvdGFsKQooWEVO
KSBbMjAxNC0xMS0xNCAyMToyNDo0OS44MjRdIEFDUEkgc2xlZXAgbW9kZXM6IFMzCihYRU4p
IFsyMDE0LTExLTE0IDIxOjI0OjQ5LjgzMF0gTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5nIHRv
IGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS44
MzddIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4K
KFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NDkuODQ0XSBYZW5vcHJvZmlsZTogRmFpbGVkIHRv
IHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmCihYRU4pIFsyMDE0
LTExLTE0IDIxOjI0OjQ5Ljg1MV0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjUwLjAxOV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9
MHgxMDAwMDAwIG1lbXN6PTB4MTA2NTAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4w
MjZdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MjIwMDAwMCBtZW1zej0weDEw
NjAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4wMzNdIGVsZl9wYXJzZV9iaW5hcnk6
IHBoZHI6IHBhZGRyPTB4MjMwNjAwMCBtZW1zej0weDE0MjgwCihYRU4pIFsyMDE0LTExLTE0
IDIxOjI0OjUwLjA0MF0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgyMzFiMDAw
IG1lbXN6PTB4MTE0MDAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4wNDhdIGVsZl9w
YXJzZV9iaW5hcnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MzQ1YjAwMAooWEVOKSBbMjAx
NC0xMS0xNCAyMToyNDo1MC4wNTVdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAi
bGludXgiCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjA2Ml0gZWxmX3hlbl9wYXJzZV9u
b3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiIKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAu
MDcwXSBlbGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCihYRU4p
IFsyMDE0LTExLTE0IDIxOjI0OjUwLjA3N10gZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JB
U0UgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMDg0
XSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgyMzFiMWYwCihYRU4p
IFsyMDE0LTExLTE0IDIxOjI0OjUwLjA5Ml0gZWxmX3hlbl9wYXJzZV9ub3RlOiBIWVBFUkNB
TExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1
MC4xMDBdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2Vf
dGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2J8d3JpdGFibGVfZGVzY3JpcHRvcl90YWJsZXN8
YXV0b190cmFuc2xhdGVkX3BoeXNtYXB8c3VwZXJ2aXNvcl9tb2RlX2tlcm5lbCIKKFhFTikg
WzIwMTQtMTEtMTQgMjE6MjQ6NTAuMTE1XSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVUFBPUlRF
RF9GRUFUVVJFUyA9IDB4OTBkCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjEyM10gZWxm
X3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjUwLjEzMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKKFhF
TikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMTM5XSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25v
d24geGVuIGVsZiBub3RlICgweGQpCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjE0N10g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQooWEVOKSBbMjAxNC0x
MS0xNCAyMToyNDo1MC4xNTVdIGVsZl94ZW5fcGFyc2Vfbm90ZTogTU9EX1NUQVJUX1BGTiA9
IDB4MQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4xNjNdIGVsZl94ZW5fcGFyc2Vfbm90
ZTogSFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE0
IDIxOjI0OjUwLjE3Ml0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDAK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMTgxXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVj
azogYWRkcmVzc2VzOgooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4xODldICAgICB2aXJ0
X2Jhc2UgICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjUwLjE5OF0gICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MjQ6NTAuMjA3XSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAw
MDAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4yMTZdICAgICB2aXJ0X2tzdGFydCAg
ICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjIy
NV0gICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZmZmZmODM0NWIwMDAKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MjQ6NTAuMjM1XSAgICAgdmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZm
ZmY4MjMxYjFmMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4yNDRdICAgICBwMm1fYmFz
ZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0
OjUwLjI1NF0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MjQ6NTAuMjYzXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2Is
IHBhZGRyIDB4MTAwMDAwMCAtPiAweDM0NWIwMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6
NTAuMjc0XSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6CihYRU4pIFsyMDE0LTExLTE0
IDIxOjI0OjUwLjI4M10gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDA1NDgwMDAwMDAtPjAwMDAw
MDA1NGMwMDAwMDAgKDM3MjkzOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pIFsyMDE0
LTExLTE0IDIxOjI0OjUwLjI5NF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDA1NWYwY2EwMDAt
PjAwMDAwMDA1NWZmZmZhMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMzA1XSBWSVJU
VUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMzE1
XSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MzQ1YjAwMAoo
WEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4zMjVdICBJbml0LiByYW1kaXNrOiAwMDAwMDAw
MDAwMDAwMDAwLT4wMDAwMDAwMDAwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUw
LjMzNl0gIFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODM0NWIwMDAtPmZmZmZmZmZmODM3NWIw
MDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMzQ3XSAgU3RhcnQgaW5mbzogICAgZmZm
ZmZmZmY4Mzc1YjAwMC0+ZmZmZmZmZmY4Mzc1YjRiNAooWEVOKSBbMjAxNC0xMS0xNCAyMToy
NDo1MC4zNTddICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzNzVjMDAwLT5mZmZmZmZmZjgz
NzdiMDAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjM2OF0gIEJvb3Qgc3RhY2s6ICAg
IGZmZmZmZmZmODM3N2IwMDAtPmZmZmZmZmZmODM3N2MwMDAKKFhFTikgWzIwMTQtMTEtMTQg
MjE6MjQ6NTAuMzc5XSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZm
ZmY4MzgwMDAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4zOTBdICBFTlRSWSBBRERS
RVNTOiBmZmZmZmZmZjgyMzFiMWYwCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjQwMV0g
RG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjQx
Ml0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4
ZmZmZmZmZmY4MjA2NTAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC40MzBdIGVsZl9s
b2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MjIwMDAwMCAtPiAweGZmZmZmZmZm
ODIzMDYwMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuNDQxXSBlbGZfbG9hZF9iaW5h
cnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODIzMDYwMDAgLT4gMHhmZmZmZmZmZjgyMzFhMjgw
CihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjQ1M10gZWxmX2xvYWRfYmluYXJ5OiBwaGRy
IDMgYXQgMHhmZmZmZmZmZjgyMzFiMDAwIC0+IDB4ZmZmZmZmZmY4MjQyMzAwMAooWEVOKSBb
MjAxNC0xMS0xNCAyMToyNDo1MC44NjVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjUxLjYxM10gU2NydWJiaW5nIEZyZWUgUkFNIG9uIDEgbm9kZXMgdXNpbmcgNiBDUFVz
CihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUxLjcxN10gLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi5kb25lLgooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1NC44MDRdIEluaXRpYWwg
bG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgooWEVOKSBb
MjAxNC0xMS0xNCAyMToyNDo1NC44MTZdIFN0ZC4gTG9nbGV2ZWw6IEFsbAooWEVOKSBbMjAx
NC0xMS0xNCAyMToyNDo1NC44MjddIEd1ZXN0IExvZ2xldmVsOiBBbGwKKFhFTikgWzIwMTQt
MTEtMTQgMjE6MjQ6NTQuODM4XSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4K
KFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTQuOTM0XSAqKiogU2VyaWFsIGlucHV0IC0+IERP
TTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTQuOTM0XSBGcmVlZCAyODhrQiBpbml0IG1lbW9y
eS4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTUuMDg4XSBJT0FQSUNbMF06IFNldCBQQ0kg
cm91dGluZyBlbnRyeSAoNi05IC0+IDB4NjAgLT4gSVJRIDkgTW9kZToxIEFjdGl2ZToxKQoo
WEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1NS4xMTFdIHRyYXBzLmM6MjU3OTpkMHYwIERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAw
MDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjQ0NV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjQ0NV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI0OjU1LjQ0Nl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjU1LjQ0Nl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMy4wCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0Nl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDow
NS4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0N10gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDowNi4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0N10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDowOS4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0N10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDowYS4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0OF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDowYi4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjQ0OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYy4wCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjQ0OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowZC4wCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI0OjU1LjQ0OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMS4wCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjU1LjQ0OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4wCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
Mi4yCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0OV0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxMy4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1MF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxMy4yCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1MF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxNC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1MV0g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4yCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjQ1MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4zCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjQ1MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC40CihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI0OjU1LjQ1MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41CihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjU1LjQ1Ml0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNS4wCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1Ml0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
Ni4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1Ml0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxNi4yCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1M10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxOC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1M10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxOC4xCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1M10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjQ1M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4zCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjQ1M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40CihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI0OjU1LjQ1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowZjowMC4wCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjU1LjQ1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowZjowMC4xCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ2M10gUENJIGFkZCBkZXZpY2UgMDAwMDowZTow
MC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ2M10gUENJIGFkZCBkZXZpY2UgMDAw
MDowZTowMC4xCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ3M10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowZDowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ4M10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowYzowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ5M10g
UENJIGFkZCBkZXZpY2UgMDAwMDowYjowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjUwNF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjUxNF0gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4wCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI0OjU1LjUxNF0gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4xCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjU1LjUyNF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4wCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjUzNF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNjow
MS4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjUzNF0gUENJIGFkZCBkZXZpY2UgMDAw
MDowNjowMi4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjUzNV0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowODowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjU0NF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowNzowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjU0NV0g
UENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjU1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMzowNi4wCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjU1NV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTMgLT4g
MHg4OCAtPiBJUlEgMTMgTW9kZTowIEFjdGl2ZTowKQooWEVOKSBbMjAxNC0xMS0xNCAyMToy
NDo1NS41NzBdIFBDSTogVXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAwMC1mZgoo
WEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1NS41NjRdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg2LTggLT4gMHg1OCAtPiBJUlEgOCBNb2RlOjAgQWN0aXZlOjApCihYRU4p
IFsyMDE0LTExLTE0IDIxOjI0OjU1LjU3OF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDYtMTggLT4gMHhiOCAtPiBJUlEgMTggTW9kZToxIEFjdGl2ZToxKQooWEVOKSBb
MjAxNC0xMS0xNCAyMToyNDo1NS42NTNdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg2LTE3IC0+IDB4YzAgLT4gSVJRIDE3IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MjQ6NTUuODgzXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy0yOSAtPiAweGM4IC0+IElSUSA1MyBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0
LTExLTE0IDIxOjI0OjU1Ljg4M10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctMjQgLT4gMHhkMCAtPiBJUlEgNDggTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0x
MS0xNCAyMToyNDo1NS44ODRdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTMwIC0+IDB4ZDggLT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MjQ6NTUuODg0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0x
MiAtPiAweDIxIC0+IElSUSAzNiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE0
IDIxOjI0OjU1Ljg4NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTMg
LT4gMHgyOSAtPiBJUlEgMzcgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xNCAy
MToyNDo1NS44ODRdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE2IC0+
IDB4MzEgLT4gSVJRIDQwIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTQgMjE6
MjQ6NTUuOTUxXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yOCAtPiAw
eDM5IC0+IElSUSA1MiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0
OjU1Ljk1M10gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTYgLT4gMHg4
OSAtPiBJUlEgMTYgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1
NS45NTRdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE0IC0+IDB4YTkg
LT4gSVJRIDM4IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTYu
MDAzXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0yMiAtPiAweGI5IC0+
IElSUSAyMiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU4LjM0
NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOSAtPiAweGMxIC0+IElS
USAzMyBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU4LjQ0Nl0g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOCAtPiAweGM5IC0+IElSUSAz
MiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU4LjU0MV0gSU9B
UElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjMgLT4gMHhkMSAtPiBJUlEgNDcg
TW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNTowMC43NjddIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTUgLT4gMHhkOSAtPiBJUlEgMjkgTW9k
ZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNTowMC44NjldIElPQVBJQ1sx
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTQgLT4gMHgyMiAtPiBJUlEgMjggTW9kZTox
IEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNTowMS4wMjVdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI1OjAxLjAyOF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDYtMTkgLT4gMHgyYSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQooWEVO
KSBbMjAxNC0xMS0xNCAyMToyNTowMS4xOTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5n
IGVudHJ5ICg3LTIyIC0+IDB4NzIgLT4gSVJRIDQ2IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikg
WzIwMTQtMTEtMTQgMjE6MjU6MDEuMjQyXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNy0yNyAtPiAweDhhIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI1OjAzLjQ5Nl0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDctMSAtPiAweDlhIC0+IElSUSAyNSBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0
LTExLTE0IDIxOjI1OjEwLjYzM10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MjU6
MjAuNjM0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNTozMC42MzRdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjI1OjQwLjYzNF0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTQgMjE6MjU6NTAuNjM0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToy
NjowMC42MzVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjI2OjEwLjYzNV0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MjY6MjAuNjM1XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xNCAyMToyNjozMC42MzVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI2OjQwLjYzNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MjY6NTAuNjM2XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNzowMC42MzZdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE0IDIxOjI3OjEwLjYzNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQg
MjE6Mjc6MjAuNjM2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNzozMC42Mzdd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjI3OjQwLjYzN10gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTQgMjE6Mjc6NTAuNjM3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
NCAyMToyODowMC42MzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjI4OjEwLjYz
OF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6Mjg6MjAuNjM4XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xNCAyMToyODozMC42MzhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI4OjQwLjYzOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6Mjg6NTAu
NjM4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToyOTowMC42MzhdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE0IDIxOjI5OjEwLjYzOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTQgMjE6Mjk6MjAuNjM5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToyOToz
MC42MzldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjI5OjQwLjYzOV0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6Mjk6NTAuNjQwXSAtLU1BUkstLQooZDEpIFsyMDE0
LTExLTE0IDIxOjI5OjUyLjI2Nl0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1v
cnkKKGQxKSBbMjAxNC0xMS0xNCAyMToyOTo1Mi4yNjddIGFib3V0IHRvIGdldCBzdGFydGVk
Li4uCihYRU4pIFsyMDE0LTExLTE0IDIxOjI5OjUyLjUzMV0gdHJhcHMuYzoyNTc5OmQxdjAg
RG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAw
MDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKGQyKSBbMjAxNC0xMS0xNCAyMToy
OTo1OC4xODhdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMikgWzIw
MTQtMTEtMTQgMjE6Mjk6NTguMTg4XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBb
MjAxNC0xMS0xNCAyMToyOTo1OC4yNjRdIHRyYXBzLmM6MjU3OTpkMnYwIERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0
byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE0IDIxOjMwOjAwLjY0MF0g
LS1NQVJLLS0KKGQzKSBbMjAxNC0xMS0xNCAyMTozMDowNC4yODJdIG1hcHBpbmcga2VybmVs
IGludG8gcGh5c2ljYWwgbWVtb3J5CihkMykgWzIwMTQtMTEtMTQgMjE6MzA6MDQuMjgyXSBh
Ym91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMDowNC4zNzhd
IHRyYXBzLmM6MjU3OTpkM3YwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihk
NCkgWzIwMTQtMTEtMTQgMjE6MzA6MTAuMTA4XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNp
Y2FsIG1lbW9yeQooZDQpIFsyMDE0LTExLTE0IDIxOjMwOjEwLjEwOF0gYWJvdXQgdG8gZ2V0
IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzA6MTAuMTg5XSB0cmFwcy5jOjI1
Nzk6ZDR2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAw
eDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0x
MS0xNCAyMTozMDoxMC42NDBdIC0tTUFSSy0tCihkNSkgWzIwMTQtMTEtMTQgMjE6MzA6MTUu
ODgxXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDUpIFsyMDE0LTEx
LTE0IDIxOjMwOjE1Ljg4MV0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQt
MTEtMTQgMjE6MzA6MTUuOTU4XSB0cmFwcy5jOjI1Nzk6ZDV2MCBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgw
MDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMDoxOC4yOThdIGdyYW50
X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gMiBmcmFtZXMK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MzA6MjAuNjQwXSAtLU1BUkstLQooZDYpIFsyMDE0LTEx
LTE0IDIxOjMwOjIxLjg3NF0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkK
KGQ2KSBbMjAxNC0xMS0xNCAyMTozMDoyMS44NzRdIGFib3V0IHRvIGdldCBzdGFydGVkLi4u
CihYRU4pIFsyMDE0LTExLTE0IDIxOjMwOjIxLjk4Nl0gdHJhcHMuYzoyNTc5OmQ2djAgRG9t
YWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAw
MDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKGQ3KSBbMjAxNC0xMS0xNCAyMTozMDoy
OC4wMThdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkNykgWzIwMTQt
MTEtMTQgMjE6MzA6MjguMDE5XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAx
NC0xMS0xNCAyMTozMDoyOC4wOTNdIHRyYXBzLmM6MjU3OTpkN3YwIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAw
eDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE0IDIxOjMwOjMwLjY0MV0gLS1N
QVJLLS0KKGQ4KSBbMjAxNC0xMS0xNCAyMTozMDozNC4yMDRdIG1hcHBpbmcga2VybmVsIGlu
dG8gcGh5c2ljYWwgbWVtb3J5CihkOCkgWzIwMTQtMTEtMTQgMjE6MzA6MzQuMjA0XSBhYm91
dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMDozNC4yODBdIHRy
YXBzLmM6MjU3OTpkOHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihkOSkg
WzIwMTQtMTEtMTQgMjE6MzA6NDAuNjIwXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2Fs
IG1lbW9yeQooZDkpIFsyMDE0LTExLTE0IDIxOjMwOjQwLjYyMF0gYWJvdXQgdG8gZ2V0IHN0
YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzA6NDAuNjQxXSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xNCAyMTozMDo0MC43MDddIHRyYXBzLmM6MjU3OTpkOXYwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAw
MCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihkMTApIFsyMDE0LTExLTE0IDIxOjMwOjQ2LjUy
OF0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQxMCkgWzIwMTQtMTEt
MTQgMjE6MzA6NDYuNTI4XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0x
MS0xNCAyMTozMDo0Ni42MDhdIHRyYXBzLmM6MjU3OTpkMTB2MCBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgw
MDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMDo0Ny42OTVdIGdyYW50
X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gMyBmcmFtZXMK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MzA6NTAuNjQxXSAtLU1BUkstLQooZDExKSBbMjAxNC0x
MS0xNCAyMTozMDo1Mi41OTVdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5
CihkMTEpIFsyMDE0LTExLTE0IDIxOjMwOjUyLjU5NV0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQu
Li4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzA6NTIuNjg3XSB0cmFwcy5jOjI1Nzk6ZDExdjAg
RG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAw
MDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKGQxMikgWzIwMTQtMTEtMTQgMjE6
MzA6NTguNTY2XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDEyKSBb
MjAxNC0xMS0xNCAyMTozMDo1OC41NjZdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4p
IFsyMDE0LTExLTE0IDIxOjMwOjU4LjY1N10gdHJhcHMuYzoyNTc5OmQxMnYwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAw
MCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjAwLjY0
MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MDAuNzI4XSBncmFudF90YWJs
ZS5jOjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDQgZnJhbWVzCihYRU4p
IFsyMDE0LTExLTE0IDIxOjMxOjAwLjc1MF0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNy
ZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA1IGZyYW1lcwooZDEzKSBbMjAxNC0xMS0xNCAyMToz
MTowNS44MTldIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTMpIFsy
MDE0LTExLTE0IDIxOjMxOjA1LjgxOV0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikg
WzIwMTQtMTEtMTQgMjE6MzE6MDYuMDc3XSB0cmFwcy5jOjI1Nzk6ZDEzdjAgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAw
IHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MTAuNjQx
XSAtLU1BUkstLQooZDE0KSBbMjAxNC0xMS0xNCAyMTozMToxMi4xNDNdIG1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTQpIFsyMDE0LTExLTE0IDIxOjMxOjEyLjE0
NF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MTIu
MjM0XSB0cmFwcy5jOjI1Nzk6ZDE0djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZm
Zi4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MTUuNzY2XSBncmFudF90YWJsZS5jOjMwNTpk
MHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDYgZnJhbWVzCihkMTUpIFsyMDE0LTEx
LTE0IDIxOjMxOjE4LjM5OV0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkK
KGQxNSkgWzIwMTQtMTEtMTQgMjE6MzE6MTguMzk5XSBhYm91dCB0byBnZXQgc3RhcnRlZC4u
LgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMToxOC40OTFdIHRyYXBzLmM6MjU3OTpkMTV2MCBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAw
MDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xNCAyMToz
MToyMC42NDJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjI2LjU2OV0gaW8u
Yzo1NTA6IGQxNjogYmluZDogbV9nc2k9MzcgZ19nc2k9MzYgZGV2PTAwLjAwLjUgaW50eD0w
CihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjI4LjA5NV0gaW8uYzo1NTA6IGQxNjogYmluZDog
bV9nc2k9NDcgZ19nc2k9NDAgZGV2PTAwLjAwLjYgaW50eD0wCihkMTYpIFsyMDE0LTExLTE0
IDIxOjMxOjI4LjExMF0gSFZNIExvYWRlcgooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4x
MTBdIERldGVjdGVkIFhlbiB2NC41LjAtcmMKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6Mjgu
MTEwXSBYZW5idXMgcmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgMQooZDE2KSBb
MjAxNC0xMS0xNCAyMTozMToyOC4xMTBdIFN5c3RlbSByZXF1ZXN0ZWQgU2VhQklPUwooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC4xMTBdIENQVSBzcGVlZCBpcyAzMjAwIE1IegooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC4xMTFdIFJlbG9jYXRpbmcgZ3Vlc3QgbWVtb3J5IGZv
ciBsb3dtZW0gTU1JTyBzcGFjZSBkaXNhYmxlZAooWEVOKSBbMjAxNC0xMS0xNCAyMTozMToy
OC4xMTFdIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC4xMTFdIFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJ
UlE1CihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjI4LjExMV0gaXJxLmM6MjcwOiBEb20xNiBQ
Q0kgbGluayAxIGNoYW5nZWQgMCAtPiAxMAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4x
MTFdIFBDSS1JU0EgbGluayAxIHJvdXRlZCB0byBJUlExMAooWEVOKSBbMjAxNC0xMS0xNCAy
MTozMToyOC4xMTJdIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4g
MTEKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMTEyXSBQQ0ktSVNBIGxpbmsgMiByb3V0
ZWQgdG8gSVJRMTEKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMTEyXSBpcnEuYzoyNzA6
IERvbTE2IFBDSSBsaW5rIDMgY2hhbmdlZCAwIC0+IDUKKGQxNikgWzIwMTQtMTEtMTQgMjE6
MzE6MjguMTEyXSBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQooZDE2KSBbMjAxNC0x
MS0xNCAyMTozMToyOC4xMjhdIHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1CihkMTYpIFsyMDE0
LTExLTE0IDIxOjMxOjI4LjEzNF0gcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihkMTYpIFsy
MDE0LTExLTE0IDIxOjMxOjI4LjEzOV0gcGNpIGRldiAwMjowIElOVEEtPklSUTExCihkMTYp
IFsyMDE0LTExLTE0IDIxOjMxOjI4LjE1MF0gcGNpIGRldiAwNDowIElOVEEtPklSUTUKKGQx
NikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMTU3XSBwY2kgZGV2IDA1OjAgSU5UQS0+SVJRMTAK
KGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMTYzXSBwY2kgZGV2IDA2OjAgSU5UQS0+SVJR
MTEKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMjA4XSBObyBSQU0gaW4gaGlnaCBtZW1v
cnk7IHNldHRpbmcgaGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDAKKGQxNikg
WzIwMTQtMTEtMTQgMjE6MzE6MjguMjA4XSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAy
MDAwMDAwOiAwZjAwMDAwMDgKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMjEwXSBwY2kg
ZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQxNikgWzIwMTQt
MTEtMTQgMjE6MzE6MjguMjEyXSBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMjAwMDAw
OiAwZjMwMDAwMDQKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMjEzXSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKGQxNikgWzIwMTQtMTEt
MTQgMjE6MzE6MjguMjE4XSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUgMDAwMDQwMDAwOiAw
ZjMyMDAwMDAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMjIwXSBwY2kgZGV2IDA0OjAg
YmFyIDEwIHNpemUgMDAwMDIwMDAwOiAwZjMyNDAwMDAKKGQxNikgWzIwMTQtMTEtMTQgMjE6
MzE6MjguMjIxXSBwY2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEwMDAwOiAwZjMyNjAw
MDAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMjIxXSBwY2kgZGV2IDA1OjAgYmFyIDEw
IHNpemUgMDAwMDAyMDAwOiAwZjMyNzAwMDQKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6Mjgu
MjIxXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihk
MTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjIyOF0gcGNpIGRldiAwMzowIGJhciAxNCBzaXpl
IDAwMDAwMTAwMDogMGYzMjcyMDAwCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjIyOF0g
cGNpIGRldiAwMjowIGJhciAxMCBzaXplIDAwMDAwMDEwMDogMDAwMDBjMDAxCihkMTYpIFsy
MDE0LTExLTE0IDIxOjMxOjI4LjIzMV0gcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAw
MDA0MDogMDAwMDBjMTAxCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjIzM10gcGNpIGRl
diAwMToyIGJhciAyMCBzaXplIDAwMDAwMDAyMDogMDAwMDBjMTQxCihkMTYpIFsyMDE0LTEx
LTE0IDIxOjMxOjI4LjIzNl0gcGNpIGRldiAwMToxIGJhciAyMCBzaXplIDAwMDAwMDAxMDog
MDAwMDBjMTYxCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjIzOF0gPyE/IT8hPyE/IGVu
YWJsZSBJTyBvbiBwcmltYXJ5IHZnYSBwY2kgZGV2IDAzOjAgCihkMTYpIFsyMDE0LTExLTE0
IDIxOjMxOjI4LjIzOF0gTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246CihkMTYpIFsy
MDE0LTExLTE0IDIxOjMxOjI4LjI2M10gIC0gQ1BVMCAuLi4gNDgtYml0IHBoeXMgLi4uIGZp
eGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0LTEx
LTE0IDIxOjMxOjI4LjI4Nl0gIC0gQ1BVMSAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1U
UlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0LTExLTE0IDIx
OjMxOjI4LjMxMl0gIC0gQ1BVMiAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4u
LiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4
LjMzOF0gIC0gQ1BVMyAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIg
TVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjMzOF0g
VGVzdGluZyBIVk0gZW52aXJvbm1lbnQ6CihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM0
Nl0gIC0gUkVQIElOU0IgYWNyb3NzIHBhZ2UgYm91bmRhcmllcyAuLi4gcGFzc2VkCihkMTYp
IFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1MF0gIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1Mg
Li4uIHBhc3NlZAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNTBdIFBhc3NlZCAyIG9m
IDIgdGVzdHMKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzUwXSBXcml0aW5nIFNNQklP
UyB0YWJsZXMgLi4uCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1MV0gTG9hZGluZyBT
ZWFCSU9TIC4uLgooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNTFdIENyZWF0aW5nIE1Q
IHRhYmxlcyAuLi4KKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzUyXSBMb2FkaW5nIEFD
UEkgLi4uCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1M10gdm04NiBUU1MgYXQgZmMw
MGEyMDAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzU0XSBCSU9TIG1hcDoKKGQxNikg
WzIwMTQtMTEtMTQgMjE6MzE6MjguMzU0XSAgMTAwMDAtMTAwZDM6IFNjcmF0Y2ggc3BhY2UK
KGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzU0XSAgYzAwMDAtZmZmZmY6IE1haW4gQklP
UwooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNTRdIEU4MjAgdGFibGU6CihkMTYpIFsy
MDE0LTExLTE0IDIxOjMxOjI4LjM1NF0gIFswMF06IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAw
MDAwMDA6MDAwYTAwMDA6IFJBTQooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNTRdICBI
T0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGMwMDAwCihkMTYpIFsyMDE0
LTExLTE0IDIxOjMxOjI4LjM1NF0gIFswMV06IDAwMDAwMDAwOjAwMGMwMDAwIC0gMDAwMDAw
MDA6MDAxMDAwMDA6IFJFU0VSVkVECihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1NF0g
IFswMl06IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAwMDA6M2Y4MDAwMDA6IFJBTQooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNTRdICBIT0xFOiAwMDAwMDAwMDozZjgwMDAwMCAt
IDAwMDAwMDAwOmZjMDAwMDAwCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1NF0gIFsw
M106IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAwMDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVECihk
MTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1NF0gSW52b2tpbmcgU2VhQklPUyAuLi4KKGQx
NikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzU3XSBTZWFCSU9TICh2ZXJzaW9uIHJlbC0xLjcu
NS0wLWdlNTE0ODhjLTIwMTQxMTE0XzIyMDMyMC1zZXJ2ZWVyc3RlcnRqZSkKKGQxNikgWzIw
MTQtMTEtMTQgMjE6MzE6MjguMzU3XSAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzU3
XSBGb3VuZCBYZW4gaHlwZXJ2aXNvciBzaWduYXR1cmUgYXQgNDAwMDAwMDAKKGQxNikgWzIw
MTQtMTEtMTQgMjE6MzE6MjguMzU3XSBSdW5uaW5nIG9uIFFFTVUgKGk0NDBmeCkKKGQxNikg
WzIwMTQtMTEtMTQgMjE6MzE6MjguMzU3XSB4ZW46IGNvcHkgZTgyMC4uLgooZDE2KSBbMjAx
NC0xMS0xNCAyMTozMToyOC4zNTddIFJlbG9jYXRpbmcgaW5pdCBmcm9tIDB4MDAwZGUyZTkg
dG8gMHgzZjdhZTRmMCAoc2l6ZSA3MjI2NykKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6Mjgu
MzYwXSBDUFUgTWh6PTMyMDEKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzY2XSBGb3Vu
ZCAxMCBQQ0kgZGV2aWNlcyAobWF4IFBDSSBidXMgaXMgMDApCihkMTYpIFsyMDE0LTExLTE0
IDIxOjMxOjI4LjM2Nl0gQWxsb2NhdGVkIFhlbiBoeXBlcmNhbGwgcGFnZSBhdCAzZjdmZjAw
MAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNjZdIERldGVjdGVkIFhlbiB2NC41LjAt
cmMKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzY2XSB4ZW46IGNvcHkgQklPUyB0YWJs
ZXMuLi4KKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzY2XSBDb3B5aW5nIFNNQklPUyBl
bnRyeSBwb2ludCBmcm9tIDB4MDAwMTAwMTAgdG8gMHgwMDBmNWRlMAooZDE2KSBbMjAxNC0x
MS0xNCAyMTozMToyOC4zNjZdIENvcHlpbmcgTVBUQUJMRSBmcm9tIDB4ZmMwMDExYTAvZmMw
MDExYjAgdG8gMHgwMDBmNWNjMAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNjZdIENv
cHlpbmcgUElSIGZyb20gMHgwMDAxMDAzMCB0byAweDAwMGY1YzQwCihkMTYpIFsyMDE0LTEx
LTE0IDIxOjMxOjI4LjM2Nl0gQ29weWluZyBBQ1BJIFJTRFAgZnJvbSAweDAwMDEwMGIwIHRv
IDB4MDAwZjVjMTAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzY2XSBVc2luZyBwbXRp
bWVyLCBpb3BvcnQgMHhiMDA4CihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM2Nl0gU2Nh
biBmb3IgVkdBIG9wdGlvbiByb20KKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzg0XSBS
dW5uaW5nIG9wdGlvbiByb20gYXQgYzAwMDowMDAzCihYRU4pIFsyMDE0LTExLTE0IDIxOjMx
OjI4LjM5M10gc3RkdmdhLmM6MTQ3OmQxNnYwIGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGlu
ZyBtb2RlcwooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC40MjBdIHBtbSBjYWxsIGFyZzE9
MAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC40MjFdIFR1cm5pbmcgb24gdmdhIHRleHQg
bW9kZSBjb25zb2xlCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU0Nl0gU2VhQklPUyAo
dmVyc2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTExNF8yMjAzMjAtc2VydmVlcnN0
ZXJ0amUpCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU2MF0gTWFjaGluZSBVVUlEIDcy
OGE2YTIyLTgzOGYtNDg1MC04YzIwLTgzOGQ3M2E1NDM4YwooZDE2KSBbMjAxNC0xMS0xNCAy
MTozMToyOC41NjFdIC8zZjdhZDAwMFwgU3RhcnQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0
IDIxOjMxOjI4LjU2MV0gfDNmN2FkMDAwfCBYSENJIGluaXQgb24gZGV2IDAwOjA1LjA6IHJl
Z3MgQCAweGYzMjcwMDAwLCA0IHBvcnRzLCAzMiBzbG90cywgMzIgYgooZDE2KSBbMjAxNC0x
MS0xNCAyMTozMToyOC41NjFdIHl0ZSBjb250ZXh0cwooZDE2KSBbMjAxNC0xMS0xNCAyMToz
MToyOC41NjFdIHwzZjdhZDAwMHwgWEhDSSAgICBleHRjYXAgMHgxIEAgZjMyNzA1MDAKKGQx
NikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNTYxXSB8M2Y3YWQwMDB8IFhIQ0kgICAgcHJvdG9j
b2wgVVNCICAzLjAwLCAyIHBvcnRzIChvZmZzZXQgMSksIGRlZiAwCihkMTYpIFsyMDE0LTEx
LTE0IDIxOjMxOjI4LjU2MV0gfDNmN2FkMDAwfCBYSENJICAgIHByb3RvY29sIFVTQiAgMi4w
MCwgMiBwb3J0cyAob2Zmc2V0IDMpLCBkZWYgMAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToy
OC41NjJdIC8zZjdhYjAwMFwgU3RhcnQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIxOjMx
OjI4LjU2Ml0gLzNmN2FhMDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6
MzE6MjguNTYyXSB8M2Y3YWQwMDB8IFVIQ0kgaW5pdCBvbiBkZXYgMDA6MDEuMiAoaW89YzE0
MCkKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNTYzXSAvM2Y3YTkwMDBcIFN0YXJ0IHRo
cmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC41NjNdIC8zZjdhODAwMFwgU3RhcnQg
dGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU2M10gRm91bmQgMCBscHQgcG9y
dHMKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNTY0XSBGb3VuZCAxIHNlcmlhbCBwb3J0
cwooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC41NjVdIEFUQSBjb250cm9sbGVyIDEgYXQg
MWYwLzNmNC8wIChpcnEgMTQgZGV2IDkpCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU2
NV0gLzNmN2E3MDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6Mjgu
NTY2XSBcM2Y3YWQwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6Mjgu
NTY2XSAvM2Y3YTYwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToy
OC41NjZdIFwzZjdhNjAwMC8gRW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToy
OC41NjZdIEFUQSBjb250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUgZGV2IDkpCihk
MTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU2Nl0gLzNmN2E2MDAwXCBTdGFydCB0aHJlYWQK
KGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNTY3XSBcM2Y3YTYwMDAvIEVuZCB0aHJlYWQK
KGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNTcwXSB8M2Y3YTcwMDB8IGF0YTAtMDogUUVN
VSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDEwMjQwIE1pQnl0ZXMpCihkMTYpIFsyMDE0
LTExLTE0IDIxOjMxOjI4LjU3MF0gfDNmN2E3MDAwfCBTZWFyY2hpbmcgYm9vdG9yZGVyIGZv
cjogL3BjaUBpMGNmOC8qQDEsMS9kcml2ZUAwL2Rpc2tAMAooZDE2KSBbMjAxNC0xMS0xNCAy
MTozMToyOC41NzFdIHwzZjdhNzAwMHwgYXRhMC0xOiBRRU1VIEhBUkRESVNLIEFUQS03IEhh
cmQtRGlzayAoMzAwIEdpQnl0ZXMpCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU3MV0g
fDNmN2E3MDAwfCBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDEsMS9k
cml2ZUAwL2Rpc2tAMQooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC41NzFdIFwzZjdhNzAw
MC8gRW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC42MzFdIHwzZjdhODAw
MHwgdXNiX2hpZF9zZXR1cCAweDNmN2FkZGJjCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4
LjYzMV0gXDNmN2E4MDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4
LjYzMl0gXDNmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4
LjY2M10gLzNmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6
MjguNjYzXSBcM2Y3YTkwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6
MjguNjY0XSAvM2Y3YTkwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMToz
MToyOC42NjRdIFwzZjdhOTAwMC8gRW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMToz
MToyOC42NjRdIC8zZjdhOTAwMFwgU3RhcnQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIx
OjMxOjI4LjY2NF0gXDNmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIx
OjMxOjI4LjY2NF0gLzNmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQg
MjE6MzE6MjguNjY5XSB8M2Y3YWEwMDB8IFBTMiBrZXlib2FyZCBpbml0aWFsaXplZAooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC42NjldIFwzZjdhYTAwMC8gRW5kIHRocmVhZAooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC43MTRdIHwzZjdhOTAwMHwgWEhDSSBwb3J0ICM0OiAw
eDAwMjAwYTAzLCBwb3dlcmVkLCBlbmFibGVkLCBwbHMgMCwgc3BlZWQgMiBbTG93XQooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC43NDRdIHwzZjdhOTAwMHwgdXNiX2hpZF9zZXR1cCAw
eDNmN2ZlYzIwCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4Ljc0NF0gXDNmN2E5MDAwLyBF
bmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4Ljc0NV0gfDNmN2FiMDAwfCBY
SENJIG5vIGRldmljZXMgZm91bmQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzUwXSBc
M2Y3YWIwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzUwXSBB
bGwgdGhyZWFkcyBjb21wbGV0ZS4KKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzUwXSBT
Y2FuIGZvciBvcHRpb24gcm9tcwooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC43ODRdIFJ1
bm5pbmcgb3B0aW9uIHJvbSBhdCBjOTgwOjAwMDMKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6
MjguNzkwXSBwbW0gY2FsbCBhcmcxPTEKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzkw
XSBwbW0gY2FsbCBhcmcxPTAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzkyXSBwbW0g
Y2FsbCBhcmcxPTEKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzkyXSBwbW0gY2FsbCBh
cmcxPTAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguODA5XSBTZWFyY2hpbmcgYm9vdG9y
ZGVyIGZvcjogL3BjaUBpMGNmOC8qQDQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguODA5
XSAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguODE2XSBQcmVzcyBGMTIgZm9yIGJvb3Qg
bWVudS4KKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguODE3XSAKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MzE6MzAuNjQyXSAtLU1BUkstLQooZDE2KSBbMjAxNC0xMS0xNCAyMTozMTozMS4z
NTddIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTYpIFsyMDE0LTExLTE0IDIx
OjMxOjMxLjM1OF0gZHJpdmUgMHgwMDBmNWJjMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xh
dGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwCihkMTYpIFsyMDE0LTExLTE0
IDIxOjMxOjMxLjM1OV0gZHJpdmUgMHgwMDBmNWI5MDogUENIUz0xNjM4My8xNi82MyB0cmFu
c2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTYyOTE0NTYwMAooZDE2KSBbMjAxNC0x
MS0xNCAyMTozMTozMS4zNTldIAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMTozMS4zNjBdIFNw
YWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjU2MDAtZjViOTAKKGQxNikg
WzIwMTQtMTEtMTQgMjE6MzE6MzEuMzYwXSBSZXR1cm5lZCAyNTM5NTIgYnl0ZXMgb2YgWm9u
ZUhpZ2gKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MzEuMzYwXSBlODIwIG1hcCBoYXMgNiBp
dGVtczoKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MzEuMzYwXSAgIDA6IDAwMDAwMDAwMDAw
MDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0KKGQxNikgWzIwMTQtMTEtMTQgMjE6
MzE6MzEuMzYwXSAgIDE6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEwMDAwID0g
MiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMTozMS4zNjBdICAgMjogMDAwMDAw
MDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgPSAyIFJFU0VSVkVECihkMTYpIFsyMDE0
LTExLTE0IDIxOjMxOjMxLjM2MF0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDAz
ZjdmZTAwMCA9IDEgUkFNCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjMxLjM2MV0gICA0OiAw
MDAwMDAwMDNmN2ZlMDAwIC0gMDAwMDAwMDAzZjgwMDAwMCA9IDIgUkVTRVJWRUQKKGQxNikg
WzIwMTQtMTEtMTQgMjE6MzE6MzEuMzYxXSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAgLSAwMDAw
MDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMTozMS4z
NjRdIGVudGVyIGhhbmRsZV8xOToKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MzEuMzY0XSAg
IE5VTEwKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MzEuMzkxXSBCb290aW5nIGZyb20gSGFy
ZCBEaXNrLi4uCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjMxLjM5M10gQm9vdGluZyBmcm9t
IDAwMDA6N2MwMAooWEVOKSBbMjAxNC0xMS0xNCAyMTozMTozNi43NDFdIGlvLmM6NTUwOiBk
MTc6IGJpbmQ6IG1fZ3NpPTQwIGdfZ3NpPTM2IGRldj0wMC4wMC41IGludHg9MAooZDE3KSBb
MjAxNC0xMS0xNCAyMTozMTozNi45NjBdIEhWTSBMb2FkZXIKKGQxNykgWzIwMTQtMTEtMTQg
MjE6MzE6MzYuOTYwXSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihkMTcpIFsyMDE0LTExLTE0
IDIxOjMxOjM2Ljk2MF0gWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBldmVudCBjaGFubmVs
IDEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTYwXSBTeXN0ZW0gcmVxdWVzdGVkIFNl
YUJJT1MKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTYwXSBDUFUgc3BlZWQgaXMgMzIw
MCBNSHoKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTYwXSBSZWxvY2F0aW5nIGd1ZXN0
IG1lbW9yeSBmb3IgbG93bWVtIE1NSU8gc3BhY2UgZGlzYWJsZWQKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MzE6MzYuOTYxXSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDAgY2hhbmdlZCAw
IC0+IDUKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTYxXSBQQ0ktSVNBIGxpbmsgMCBy
b3V0ZWQgdG8gSVJRNQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMTozNi45NjFdIGlycS5jOjI3
MDogRG9tMTcgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKKGQxNykgWzIwMTQtMTEtMTQg
MjE6MzE6MzYuOTYxXSBQQ0ktSVNBIGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MzE6MzYuOTYxXSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDIgY2hh
bmdlZCAwIC0+IDExCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM2Ljk2Ml0gUENJLUlTQSBs
aW5rIDIgcm91dGVkIHRvIElSUTExCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjM2Ljk2Ml0g
aXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAzIGNoYW5nZWQgMCAtPiA1CihkMTcpIFsyMDE0
LTExLTE0IDIxOjMxOjM2Ljk2Ml0gUENJLUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUKKGQx
NykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTgyXSBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTAK
KGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTg3XSBwY2kgZGV2IDAyOjAgSU5UQS0+SVJR
MTEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTk4XSBwY2kgZGV2IDA0OjAgSU5UQS0+
SVJRNQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wMDVdIHBjaSBkZXYgMDU6MCBJTlRB
LT5JUlExMAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wNTddIE5vIFJBTSBpbiBoaWdo
IG1lbW9yeTsgc2V0dGluZyBoaWdoX21lbSByZXNvdXJjZSBiYXNlIHRvIDEwMDAwMDAwMAoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wNTddIHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6
ZSAwMDIwMDAwMDA6IDBmMDAwMDAwOAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wNTld
IHBjaSBkZXYgMDI6MCBiYXIgMTQgc2l6ZSAwMDEwMDAwMDA6IDBmMjAwMDAwOAooZDE3KSBb
MjAxNC0xMS0xNCAyMTozMTozNy4wNjFdIHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAw
NDAwMDA6IDBmMzAwMDAwMAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wNjNdIHBjaSBk
ZXYgMDQ6MCBiYXIgMTAgc2l6ZSAwMDAwMjAwMDA6IDBmMzA0MDAwMAooZDE3KSBbMjAxNC0x
MS0xNCAyMTozMTozNy4wNjNdIHBjaSBkZXYgMDM6MCBiYXIgMzAgc2l6ZSAwMDAwMTAwMDA6
IDBmMzA2MDAwMAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wNjRdIHBjaSBkZXYgMDU6
MCBiYXIgMTAgc2l6ZSAwMDAwMDIwMDA6IDBmMzA3MDAwNAooWEVOKSBbMjAxNC0xMS0xNCAy
MTozMTozNy4wNjRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNyBnZm49ZjMwNzAgbWZuPWZkZGZl
IG5yPTEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMDcwXSBwY2kgZGV2IDAzOjAgYmFy
IDE0IHNpemUgMDAwMDAxMDAwOiAwZjMwNzIwMDAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuMDcwXSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDEK
KGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMDcyXSBwY2kgZGV2IDA0OjAgYmFyIDE0IHNp
emUgMDAwMDAwMDQwOiAwMDAwMGMxMDEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMDc1
XSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNDEKKGQxNykg
WzIwMTQtMTEtMTQgMjE6MzE6MzcuMDc3XSA/IT8hPyE/IT8gZW5hYmxlIElPIG9uIHByaW1h
cnkgdmdhIHBjaSBkZXYgMDM6MCAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMDc3XSBN
dWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuMTAwXSAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh
ciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTE2
XSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS
cyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTM2XSAgLSBD
UFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84
XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTM2XSBUZXN0aW5nIEhW
TSBlbnZpcm9ubWVudDoKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTQ2XSAgLSBSRVAg
SU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxNykgWzIwMTQtMTEt
MTQgMjE6MzE6MzcuMTUwXSAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2Vk
CihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjE1MF0gUGFzc2VkIDIgb2YgMiB0ZXN0cwoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNTBdIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAu
Li4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTUyXSBMb2FkaW5nIFNlYUJJT1MgLi4u
CihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjE1Ml0gQ3JlYXRpbmcgTVAgdGFibGVzIC4u
LgooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNTJdIExvYWRpbmcgQUNQSSAuLi4KKGQx
NykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTUzXSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE3
KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNTRdIEJJT1MgbWFwOgooZDE3KSBbMjAxNC0xMS0x
NCAyMTozMTozNy4xNTRdICAxMDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE3KSBbMjAx
NC0xMS0xNCAyMTozMTozNy4xNTRdICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTcpIFsy
MDE0LTExLTE0IDIxOjMxOjM3LjE1NF0gRTgyMCB0YWJsZToKKGQxNykgWzIwMTQtMTEtMTQg
MjE6MzE6MzcuMTU0XSAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBh
MDAwMDogUkFNCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjE1NF0gIEhPTEU6IDAwMDAw
MDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwYzAwMDAKKGQxNykgWzIwMTQtMTEtMTQgMjE6
MzE6MzcuMTU0XSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAw
MDogUkVTRVJWRUQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTU0XSAgWzAyXTogMDAw
MDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDoxZjgwMDAwMDogUkFNCihkMTcpIFsyMDE0LTEx
LTE0IDIxOjMxOjM3LjE1NF0gIEhPTEU6IDAwMDAwMDAwOjFmODAwMDAwIC0gMDAwMDAwMDA6
ZmMwMDAwMDAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTU0XSAgWzAzXTogMDAwMDAw
MDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxNykgWzIwMTQt
MTEtMTQgMjE6MzE6MzcuMTU0XSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE3KSBbMjAxNC0x
MS0xNCAyMTozMTozNy4xNTddIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4
OGMtMjAxNDExMTRfMjIwMzIwLXNlcnZlZXJzdGVydGplKQooZDE3KSBbMjAxNC0xMS0xNCAy
MTozMTozNy4xNTddIAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNTddIEZvdW5kIFhl
biBoeXBlcnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMAooZDE3KSBbMjAxNC0xMS0xNCAy
MTozMTozNy4xNThdIFJ1bm5pbmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE3KSBbMjAxNC0xMS0x
NCAyMTozMTozNy4xNThdIHhlbjogY29weSBlODIwLi4uCihkMTcpIFsyMDE0LTExLTE0IDIx
OjMxOjM3LjE1OF0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZTJlOSB0byAweDFmN2Fl
NGYwIChzaXplIDcyMjY3KQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNjBdIENQVSBN
aHo9MzIwMQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNjZdIEZvdW5kIDggUENJIGRl
dmljZXMgKG1heCBQQ0kgYnVzIGlzIDAwKQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4x
NjZdIEFsbG9jYXRlZCBYZW4gaHlwZXJjYWxsIHBhZ2UgYXQgMWY3ZmYwMDAKKGQxNykgWzIw
MTQtMTEtMTQgMjE6MzE6MzcuMTY2XSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihkMTcpIFsy
MDE0LTExLTE0IDIxOjMxOjM3LjE2Nl0geGVuOiBjb3B5IEJJT1MgdGFibGVzLi4uCihkMTcp
IFsyMDE0LTExLTE0IDIxOjMxOjM3LjE2Nl0gQ29weWluZyBTTUJJT1MgZW50cnkgcG9pbnQg
ZnJvbSAweDAwMDEwMDEwIHRvIDB4MDAwZjVkZTAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuMTY2XSBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMTgwL2ZjMDAxMTkwIHRvIDB4
MDAwZjVjZDAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTY2XSBDb3B5aW5nIFBJUiBm
cm9tIDB4MDAwMTAwMzAgdG8gMHgwMDBmNWM1MAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMToz
Ny4xNjZdIENvcHlpbmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAwMGY1YzIw
CihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjE2Nl0gVXNpbmcgcG10aW1lciwgaW9wb3J0
IDB4YjAwOAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNjZdIFNjYW4gZm9yIFZHQSBv
cHRpb24gcm9tCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjE4M10gUnVubmluZyBvcHRp
b24gcm9tIGF0IGMwMDA6MDAwMwooWEVOKSBbMjAxNC0xMS0xNCAyMTozMTozNy4xOTNdIHN0
ZHZnYS5jOjE0NzpkMTd2MCBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMKKGQx
NykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMjI1XSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIw
MTQtMTEtMTQgMjE6MzE6MzcuMjI2XSBUdXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUgY29uc29s
ZQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4zNTRdIFNlYUJJT1MgKHZlcnNpb24gcmVs
LTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMTRfMjIwMzIwLXNlcnZlZXJzdGVydGplKQooZDE3
KSBbMjAxNC0xMS0xNCAyMTozMTozNy4zNzBdIE1hY2hpbmUgVVVJRCAyYjBjMjU2YS1lNTZm
LTQ1ZTUtYTc3OC03ZDU4MDE1ZWUzYzUKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMzcx
XSAvMWY3YWQwMDBcIFN0YXJ0IHRocmVhZAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4z
NzFdIHwxZjdhZDAwMHwgWEhDSSBpbml0IG9uIGRldiAwMDowNS4wOiByZWdzIEAgMHhmMzA3
MDAwMCwgNCBwb3J0cywgMzIgc2xvdHMsIDMyIGIKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuMzcxXSB5dGUgY29udGV4dHMKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMzcxXSB8
MWY3YWQwMDB8IFhIQ0kgICAgZXh0Y2FwIDB4MSBAIGYzMDcwNTAwCihkMTcpIFsyMDE0LTEx
LTE0IDIxOjMxOjM3LjM3MV0gfDFmN2FkMDAwfCBYSENJICAgIHByb3RvY29sIFVTQiAgMy4w
MCwgMiBwb3J0cyAob2Zmc2V0IDEpLCBkZWYgMAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMToz
Ny4zNzFdIHwxZjdhZDAwMHwgWEhDSSAgICBwcm90b2NvbCBVU0IgIDIuMDAsIDIgcG9ydHMg
KG9mZnNldCAzKSwgZGVmIDAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMzcxXSAvMWY3
YWMwMDBcIFN0YXJ0IHRocmVhZAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4zNzFdIC8x
ZjdhYTAwMFwgU3RhcnQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjM3Ml0g
XDFmN2FkMDAwLyBFbmQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjM3Ml0g
Rm91bmQgMCBscHQgcG9ydHMKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMzczXSBGb3Vu
ZCAxIHNlcmlhbCBwb3J0cwooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4zNzNdIEFUQSBj
b250cm9sbGVyIDEgYXQgMWYwLzNmNC8wIChpcnEgMTQgZGV2IDkpCihkMTcpIFsyMDE0LTEx
LTE0IDIxOjMxOjM3LjM3M10gLzFmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNykgWzIwMTQt
MTEtMTQgMjE6MzE6MzcuMzc0XSBBVEEgY29udHJvbGxlciAyIGF0IDE3MC8zNzQvMCAoaXJx
IDE1IGRldiA5KQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4zNzRdIC8xZjdhODAwMFwg
U3RhcnQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjM3NV0gXDFmN2E4MDAw
LyBFbmQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjM3OV0gfDFmN2E5MDAw
fCBhdGEwLTA6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICg1MTIwIE1pQnl0ZXMp
CihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjM3OV0gfDFmN2E5MDAwfCBTZWFyY2hpbmcg
Ym9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDEsMS9kcml2ZUAwL2Rpc2tAMAooZDE3KSBb
MjAxNC0xMS0xNCAyMTozMTozNy4zODBdIFwxZjdhOTAwMC8gRW5kIHRocmVhZAooZDE3KSBb
MjAxNC0xMS0xNCAyMTozMTozNy40NzJdIC8xZjdhOTAwMFwgU3RhcnQgdGhyZWFkCihkMTcp
IFsyMDE0LTExLTE0IDIxOjMxOjM3LjQ3Ml0gXDFmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTcp
IFsyMDE0LTExLTE0IDIxOjMxOjM3LjQ3Ml0gLzFmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQx
NykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNDcyXSBcMWY3YTkwMDAvIEVuZCB0aHJlYWQKKGQx
NykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNDczXSAvMWY3YTkwMDBcIFN0YXJ0IHRocmVhZAoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy40NzNdIFwxZjdhOTAwMC8gRW5kIHRocmVhZAoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy40NzNdIC8xZjdhOTAwMFwgU3RhcnQgdGhyZWFk
CihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjQ3N10gfDFmN2FhMDAwfCBQUzIga2V5Ym9h
cmQgaW5pdGlhbGl6ZWQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNDc3XSBcMWY3YWEw
MDAvIEVuZCB0aHJlYWQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNTIzXSB8MWY3YTkw
MDB8IFhIQ0kgcG9ydCAjNDogMHgwMDIwMGUwMywgcG93ZXJlZCwgZW5hYmxlZCwgcGxzIDAs
IHNwZWVkIDMgW0hpZ2hdCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjUzN10gXDFmN2E5
MDAwLyBFbmQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjUzN10gfDFmN2Fj
MDAwfCBYSENJIG5vIGRldmljZXMgZm91bmQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6Mzcu
NTQ1XSBcMWY3YWMwMDAvIEVuZCB0aHJlYWQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6Mzcu
NTQ1XSBBbGwgdGhyZWFkcyBjb21wbGV0ZS4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6Mzcu
NTQ1XSBTY2FuIGZvciBvcHRpb24gcm9tcwooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy41
NjhdIFJ1bm5pbmcgb3B0aW9uIHJvbSBhdCBjOTgwOjAwMDMKKGQxNykgWzIwMTQtMTEtMTQg
MjE6MzE6MzcuNTc2XSBwbW0gY2FsbCBhcmcxPTEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuNTc2XSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNTc3
XSBwbW0gY2FsbCBhcmcxPTEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNTc4XSBwbW0g
Y2FsbCBhcmcxPTAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNTk2XSBTZWFyY2hpbmcg
Ym9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuNTk2XSAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNjA0XSBQcmVzcyBGMTIgZm9y
IGJvb3QgbWVudS4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNjA0XSAKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MzE6MzguMzE2XSBzdGR2Z2EuYzoxNTE6ZDE2djAgbGVhdmluZyBzdGR2
Z2EKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6NDAuMTQ0XSBTZWFyY2hpbmcgYm9vdG9yZGVy
IGZvcjogSEFMVAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4xNDRdIGRyaXZlIDB4MDAw
ZjViZDA6IFBDSFM9MTA0MDIvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9NjUyLzI1NS82
MyBzPTEwNDg1NzYwCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjQwLjE0NV0gU3BhY2UgYXZh
aWxhYmxlIGZvciBVTUI6IGNhODAwLWVmMDAwLCBmNTYwMC1mNWJkMAooZDE3KSBbMjAxNC0x
MS0xNCAyMTozMTo0MC4xNDVdIFJldHVybmVkIDI1Mzk1MiBieXRlcyBvZiBab25lSGlnaAoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4xNDVdIGU4MjAgbWFwIGhhcyA2IGl0ZW1zOgoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4xNDVdICAgMDogMDAwMDAwMDAwMDAwMDAwMCAt
IDAwMDAwMDAwMDAwOWZjMDAgPSAxIFJBTQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4x
NDVdICAgMTogMDAwMDAwMDAwMDA5ZmMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgPSAyIFJFU0VS
VkVECihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjQwLjE0NV0gICAyOiAwMDAwMDAwMDAwMGYw
MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCA9IDIgUkVTRVJWRUQKKGQxNykgWzIwMTQtMTEtMTQg
MjE6MzE6NDAuMTQ1XSAgIDM6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDFmN2ZlMDAw
ID0gMSBSQU0KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6NDAuMTQ1XSAgIDQ6IDAwMDAwMDAw
MWY3ZmUwMDAgLSAwMDAwMDAwMDFmODAwMDAwID0gMiBSRVNFUlZFRAooZDE3KSBbMjAxNC0x
MS0xNCAyMTozMTo0MC4xNDVdICAgNTogMDAwMDAwMDBmYzAwMDAwMCAtIDAwMDAwMDAxMDAw
MDAwMDAgPSAyIFJFU0VSVkVECihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjQwLjE0Nl0gZW50
ZXIgaGFuZGxlXzE5OgooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4xNDZdICAgTlVMTAoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4xNTJdIEJvb3RpbmcgZnJvbSBIYXJkIERpc2su
Li4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6NDAuMTU0XSBCb290aW5nIGZyb20gMDAwMDo3
YzAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjQwLjY0Ml0gLS1NQVJLLS0KKGQxOCkgWzIw
MTQtMTEtMTQgMjE6MzE6NDMuMTI5XSBIVk0gTG9hZGVyCihkMTgpIFsyMDE0LTExLTE0IDIx
OjMxOjQzLjEyOV0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE4KSBbMjAxNC0xMS0xNCAy
MTozMTo0My4xMjldIFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCAx
CihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjEzMF0gU3lzdGVtIHJlcXVlc3RlZCBTZWFC
SU9TCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjEzMF0gQ1BVIHNwZWVkIGlzIDMyMDAg
TUh6CihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjEzMF0gUmVsb2NhdGluZyBndWVzdCBt
ZW1vcnkgZm9yIGxvd21lbSBNTUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsyMDE0LTExLTE0
IDIxOjMxOjQzLjEzMF0gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAwIGNoYW5nZWQgMCAt
PiA1CihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjEzMF0gUENJLUlTQSBsaW5rIDAgcm91
dGVkIHRvIElSUTUKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMTMwXSBpcnEuYzoyNzA6
IERvbTE4IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCihkMTgpIFsyMDE0LTExLTE0IDIx
OjMxOjQzLjEzMF0gUENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihYRU4pIFsyMDE0
LTExLTE0IDIxOjMxOjQzLjEzMV0gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAyIGNoYW5n
ZWQgMCAtPiAxMQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4xMzFdIFBDSS1JU0EgbGlu
ayAyIHJvdXRlZCB0byBJUlExMQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMTo0My4xMzFdIGly
cS5jOjI3MDogRG9tMTggUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE4KSBbMjAxNC0x
MS0xNCAyMTozMTo0My4xMzFdIFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1CihkMTgp
IFsyMDE0LTExLTE0IDIxOjMxOjQzLjE1MF0gcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihk
MTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjE1NF0gcGNpIGRldiAwMjowIElOVEEtPklSUTEx
CihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjE2NV0gcGNpIGRldiAwNDowIElOVEEtPklS
UTUKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjE0XSBObyBSQU0gaW4gaGlnaCBtZW1v
cnk7IHNldHRpbmcgaGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDAKKGQxOCkg
WzIwMTQtMTEtMTQgMjE6MzE6NDMuMjE0XSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAy
MDAwMDAwOiAwZjAwMDAwMDgKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjE2XSBwY2kg
ZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQxOCkgWzIwMTQt
MTEtMTQgMjE6MzE6NDMuMjE3XSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUgMDAwMDQwMDAw
OiAwZjMwMDAwMDAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjE5XSBwY2kgZGV2IDA0
OjAgYmFyIDEwIHNpemUgMDAwMDIwMDAwOiAwZjMwNDAwMDAKKGQxOCkgWzIwMTQtMTEtMTQg
MjE6MzE6NDMuMjE5XSBwY2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEwMDAwOiAwZjMw
NjAwMDAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjIxXSBwY2kgZGV2IDAzOjAgYmFy
IDE0IHNpemUgMDAwMDAxMDAwOiAwZjMwNzAwMDAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6
NDMuMjIyXSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDEK
KGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjI0XSBwY2kgZGV2IDA0OjAgYmFyIDE0IHNp
emUgMDAwMDAwMDQwOiAwMDAwMGMxMDEKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjI2
XSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNDEKKGQxOCkg
WzIwMTQtMTEtMTQgMjE6MzE6NDMuMjI3XSA/IT8hPyE/IT8gZW5hYmxlIElPIG9uIHByaW1h
cnkgdmdhIHBjaSBkZXYgMDM6MCAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjI3XSBN
dWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6
NDMuMjQ2XSAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh
ciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjYy
XSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS
cyBbMS84XSAuLi4gZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjc5XSAgLSBD
UFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84
XSAuLi4gZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjk1XSAgLSBDUFUzIC4u
LiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4g
ZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjk1XSBUZXN0aW5nIEhWTSBlbnZp
cm9ubWVudDoKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzA1XSAgLSBSRVAgSU5TQiBh
Y3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxOCkgWzIwMTQtMTEtMTQgMjE6
MzE6NDMuMzA5XSAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCihkMTgp
IFsyMDE0LTExLTE0IDIxOjMxOjQzLjMwOV0gUGFzc2VkIDIgb2YgMiB0ZXN0cwooZDE4KSBb
MjAxNC0xMS0xNCAyMTozMTo0My4zMDldIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KKGQx
OCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzEwXSBMb2FkaW5nIFNlYUJJT1MgLi4uCihkMTgp
IFsyMDE0LTExLTE0IDIxOjMxOjQzLjMxMF0gQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgooZDE4
KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMTFdIExvYWRpbmcgQUNQSSAuLi4KKGQxOCkgWzIw
MTQtMTEtMTQgMjE6MzE6NDMuMzEyXSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE4KSBbMjAx
NC0xMS0xNCAyMTozMTo0My4zMTNdIEJJT1MgbWFwOgooZDE4KSBbMjAxNC0xMS0xNCAyMToz
MTo0My4zMTNdICAxMDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE4KSBbMjAxNC0xMS0x
NCAyMTozMTo0My4zMTNdICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTgpIFsyMDE0LTEx
LTE0IDIxOjMxOjQzLjMxM10gRTgyMCB0YWJsZToKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6
NDMuMzEzXSAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDog
UkFNCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjMxM10gIEhPTEU6IDAwMDAwMDAwOjAw
MGEwMDAwIC0gMDAwMDAwMDA6MDAwYzAwMDAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMu
MzEzXSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVT
RVJWRUQKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzEzXSAgWzAyXTogMDAwMDAwMDA6
MDAxMDAwMDAgLSAwMDAwMDAwMDozZjgwMDAwMDogUkFNCihkMTgpIFsyMDE0LTExLTE0IDIx
OjMxOjQzLjMxM10gIEhPTEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAw
MDAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzEzXSAgWzAzXTogMDAwMDAwMDA6ZmMw
MDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxOCkgWzIwMTQtMTEtMTQg
MjE6MzE6NDMuMzEzXSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE4KSBbMjAxNC0xMS0xNCAy
MTozMTo0My4zMTZdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAx
NDExMTRfMjIwMzIwLXNlcnZlZXJzdGVydGplKQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0
My4zMTZdIAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMTZdIEZvdW5kIFhlbiBoeXBl
cnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0
My4zMTZdIFJ1bm5pbmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE4KSBbMjAxNC0xMS0xNCAyMToz
MTo0My4zMTZdIHhlbjogY29weSBlODIwLi4uCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQz
LjMxNl0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZTJlOSB0byAweDNmN2FlNGYwIChz
aXplIDcyMjY3KQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMThdIENQVSBNaHo9MzIw
MQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMjNdIEZvdW5kIDcgUENJIGRldmljZXMg
KG1heCBQQ0kgYnVzIGlzIDAwKQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMjNdIEFs
bG9jYXRlZCBYZW4gaHlwZXJjYWxsIHBhZ2UgYXQgM2Y3ZmYwMDAKKGQxOCkgWzIwMTQtMTEt
MTQgMjE6MzE6NDMuMzIzXSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihkMTgpIFsyMDE0LTEx
LTE0IDIxOjMxOjQzLjMyNF0geGVuOiBjb3B5IEJJT1MgdGFibGVzLi4uCihkMTgpIFsyMDE0
LTExLTE0IDIxOjMxOjQzLjMyNF0gQ29weWluZyBTTUJJT1MgZW50cnkgcG9pbnQgZnJvbSAw
eDAwMDEwMDEwIHRvIDB4MDAwZjVkZTAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzI0
XSBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMWEwL2ZjMDAxMWIwIHRvIDB4MDAwZjVj
YzAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzI0XSBDb3B5aW5nIFBJUiBmcm9tIDB4
MDAwMTAwMzAgdG8gMHgwMDBmNWM0MAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMjRd
IENvcHlpbmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAwMGY1YzEwCihkMTgp
IFsyMDE0LTExLTE0IDIxOjMxOjQzLjMyNF0gVXNpbmcgcG10aW1lciwgaW9wb3J0IDB4YjAw
OAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMjRdIFNjYW4gZm9yIFZHQSBvcHRpb24g
cm9tCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjMzOV0gUnVubmluZyBvcHRpb24gcm9t
IGF0IGMwMDA6MDAwMwooWEVOKSBbMjAxNC0xMS0xNCAyMTozMTo0My4zNDddIHN0ZHZnYS5j
OjE0NzpkMTh2MCBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMKKGQxOCkgWzIw
MTQtMTEtMTQgMjE6MzE6NDMuMzY3XSBwbW0gY2FsbCBhcmcxPTAKKGQxOCkgWzIwMTQtMTEt
MTQgMjE6MzE6NDMuMzY4XSBUdXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUgY29uc29sZQooZDE4
KSBbMjAxNC0xMS0xNCAyMTozMTo0My40OTddIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41
LTAtZ2U1MTQ4OGMtMjAxNDExMTRfMjIwMzIwLXNlcnZlZXJzdGVydGplKQooZDE4KSBbMjAx
NC0xMS0xNCAyMTozMTo0My41MTNdIE1hY2hpbmUgVVVJRCBlNTdkNmI2NC03YzAyLTQwMmIt
OTBiOS1hM2MyMzdkYmRmYTEKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuNTE0XSAvM2Y3
YWQwMDBcIFN0YXJ0IHRocmVhZAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MTRdIFwz
ZjdhZDAwMC8gRW5kIHRocmVhZAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MTRdIEFs
bCB0aHJlYWRzIGNvbXBsZXRlLgooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MTRdIC8z
ZjdhZDAwMFwgU3RhcnQgdGhyZWFkCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjUxNV0g
Rm91bmQgMCBscHQgcG9ydHMKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuNTE1XSBGb3Vu
ZCAwIHNlcmlhbCBwb3J0cwooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MTZdIEFUQSBj
b250cm9sbGVyIDEgYXQgMWYwLzNmNC8wIChpcnEgMTQgZGV2IDkpCihkMTgpIFsyMDE0LTEx
LTE0IDIxOjMxOjQzLjUxNl0gLzNmN2FjMDAwXCBTdGFydCB0aHJlYWQKKGQxOCkgWzIwMTQt
MTEtMTQgMjE6MzE6NDMuNTE3XSBBVEEgY29udHJvbGxlciAyIGF0IDE3MC8zNzQvMCAoaXJx
IDE1IGRldiA5KQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MTddIC8zZjdhYjAwMFwg
U3RhcnQgdGhyZWFkCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjUxN10gXDNmN2FiMDAw
LyBFbmQgdGhyZWFkCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjUyMl0gfDNmN2FjMDAw
fCBhdGEwLTA6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgxMDI0MCBNaUJ5dGVz
KQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MjJdIHwzZjdhYzAwMHwgU2VhcmNoaW5n
IGJvb3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDAKKGQxOCkg
WzIwMTQtMTEtMTQgMjE6MzE6NDMuNTIzXSBcM2Y3YWMwMDAvIEVuZCB0aHJlYWQKKGQxOCkg
WzIwMTQtMTEtMTQgMjE6MzE6NDMuNjIwXSB8M2Y3YWQwMDB8IFBTMiBrZXlib2FyZCBpbml0
aWFsaXplZAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42MjBdIFwzZjdhZDAwMC8gRW5k
IHRocmVhZAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42MjBdIEFsbCB0aHJlYWRzIGNv
bXBsZXRlLgooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42MjBdIFNjYW4gZm9yIG9wdGlv
biByb21zCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjY0OF0gUnVubmluZyBvcHRpb24g
cm9tIGF0IGM5ODA6MDAwMwooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42NTZdIHBtbSBj
YWxsIGFyZzE9MQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42NTddIHBtbSBjYWxsIGFy
ZzE9MAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42NThdIHBtbSBjYWxsIGFyZzE9MQoo
ZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42NTldIHBtbSBjYWxsIGFyZzE9MAooZDE4KSBb
MjAxNC0xMS0xNCAyMTozMTo0My42ODBdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNp
QGkwY2Y4LypANAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42ODBdIAooZDE4KSBbMjAx
NC0xMS0xNCAyMTozMTo0My42ODhdIFByZXNzIEYxMiBmb3IgYm9vdCBtZW51LgooZDE4KSBb
MjAxNC0xMS0xNCAyMTozMTo0My42ODldIAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4y
NDFdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTgpIFsyMDE0LTExLTE0IDIx
OjMxOjQ2LjI0MV0gZHJpdmUgMHgwMDBmNWJjMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xh
dGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwCihkMTgpIFsyMDE0LTExLTE0
IDIxOjMxOjQ2LjI0MV0gU3BhY2UgYXZhaWxhYmxlIGZvciBVTUI6IGNhODAwLWVmMDAwLCBm
NTYwMC1mNWJjMAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDFdIFJldHVybmVkIDI1
ODA0OCBieXRlcyBvZiBab25lSGlnaAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDFd
IGU4MjAgbWFwIGhhcyA2IGl0ZW1zOgooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDFd
ICAgMDogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWZjMDAgPSAxIFJBTQooZDE4
KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDFdICAgMTogMDAwMDAwMDAwMDA5ZmMwMCAtIDAw
MDAwMDAwMDAwYTAwMDAgPSAyIFJFU0VSVkVECihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQ2
LjI0MV0gICAyOiAwMDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCA9IDIgUkVT
RVJWRUQKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDYuMjQxXSAgIDM6IDAwMDAwMDAwMDAx
MDAwMDAgLSAwMDAwMDAwMDNmN2ZmMDAwID0gMSBSQU0KKGQxOCkgWzIwMTQtMTEtMTQgMjE6
MzE6NDYuMjQxXSAgIDQ6IDAwMDAwMDAwM2Y3ZmYwMDAgLSAwMDAwMDAwMDNmODAwMDAwID0g
MiBSRVNFUlZFRAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDFdICAgNTogMDAwMDAw
MDBmYzAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJFU0VSVkVECihkMTgpIFsyMDE0
LTExLTE0IDIxOjMxOjQ2LjI0Ml0gZW50ZXIgaGFuZGxlXzE5OgooZDE4KSBbMjAxNC0xMS0x
NCAyMTozMTo0Ni4yNDJdICAgTlVMTAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDld
IEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4KKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDYu
MjUwXSBCb290aW5nIGZyb20gMDAwMDo3YzAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjQ4
LjAxOV0gc3RkdmdhLmM6MTUxOmQxN3YwIGxlYXZpbmcgc3RkdmdhCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjMxOjUwLjY0Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6NTEu
MTA5XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRv
IDcgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjUzLjMwOV0gc3RkdmdhLmM6MTUx
OmQxOHYwIGxlYXZpbmcgc3RkdmdhCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjAwLjY0Ml0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MDQuNTU2XSBzdGR2Z2EuYzoxNDc6
ZDE2djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjMyOjA2LjgxN10gaXJxLmM6MzgwOiBEb20xNiBjYWxsYmFjayB2aWEgY2hhbmdl
ZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MDkuOTEy
XSBzdGR2Z2EuYzoxNDc6ZDE3djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVz
CihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEwLjY0Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTQgMjE6MzI6MTAuNzc4XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcw
IG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEwLjc4M10gbWVtb3J5
X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0x
MS0xNCAyMTozMjoxMC43ODZdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAg
bWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuNzkwXSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjMyOjEwLjc5Nl0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBt
Zm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMC44MDFdIG1lbW9yeV9t
YXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MzI6MTAuODA1XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1m
bj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEwLjgxMF0gbWVtb3J5X21h
cDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0x
NCAyMTozMjoxMC44MTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZu
PWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuODE5XSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE0
IDIxOjMyOjEwLjgyM10gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49
ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMC44MjhdIG1lbW9yeV9tYXA6
YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTQg
MjE6MzI6MTAuODQyXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1m
ZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuODUwXSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MzI6MTAuODU2XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1m
bj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuODY0XSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQt
MTEtMTQgMjE6MzI6MTAuODcwXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAw
IG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuODc4XSBtZW1v
cnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MzI6MTAuODg1XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYz
MDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuODkyXSBt
ZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikg
WzIwMTQtMTEtMTQgMjE6MzI6MTAuODk3XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2Zu
PWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuOTA0
XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhF
TikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuOTA5XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYg
Z2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAu
OTE2XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuOTQxXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBs
aW5rIDAgY2hhbmdlZCA1IC0+IDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuOTU1XSBp
cnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwCihYRU4pIFsyMDE0
LTExLTE0IDIxOjMyOjEwLjk2OV0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAyIGNoYW5n
ZWQgMTEgLT4gMAooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMC45ODJdIGlycS5jOjI3MDog
RG9tMTYgUENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMAooWEVOKSBbMjAxNC0xMS0xNCAyMToz
MjoxMS42NTBdIGlycS5jOjM4MDogRG9tMTcgY2FsbGJhY2sgdmlhIGNoYW5nZWQgdG8gRGly
ZWN0IFZlY3RvciAweGYzCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEyLjMwOF0gZ3JhbnRf
dGFibGUuYzoxMjk5OmQxNnYyIEV4cGFuZGluZyBkb20gKDE2KSBncmFudCB0YWJsZSBmcm9t
ICg0KSB0byAoNSkgZnJhbWVzLgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMy4yMzJdIG1l
bW9yeV9tYXA6cmVtb3ZlOiBkb20xNyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5yPTEKKFhFTikg
WzIwMTQtMTEtMTQgMjE6MzI6MTMuMjM2XSBtZW1vcnlfbWFwOmFkZDogZG9tMTcgZ2ZuPWYz
MDcwIG1mbj1mZGRmZSBucj0xCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEzLjI0MF0gbWVt
b3J5X21hcDpyZW1vdmU6IGRvbTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9MQooWEVOKSBb
MjAxNC0xMS0xNCAyMTozMjoxMy4yNDNdIG1lbW9yeV9tYXA6YWRkOiBkb20xNyBnZm49ZjMw
NzAgbWZuPWZkZGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTMuMjQ4XSBtZW1v
cnlfbWFwOnJlbW92ZTogZG9tMTcgZ2ZuPWYzMDcwIG1mbj1mZGRmZSBucj0xCihYRU4pIFsy
MDE0LTExLTE0IDIxOjMyOjEzLjI1Ml0gbWVtb3J5X21hcDphZGQ6IGRvbTE3IGdmbj1mMzA3
MCBtZm49ZmRkZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMy4yNTddIG1lbW9y
eV9tYXA6cmVtb3ZlOiBkb20xNyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5yPTEKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MzI6MTMuMjYwXSBtZW1vcnlfbWFwOmFkZDogZG9tMTcgZ2ZuPWYzMDcw
IG1mbj1mZGRmZSBucj0xCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEzLjI2NV0gbWVtb3J5
X21hcDpyZW1vdmU6IGRvbTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9MQooWEVOKSBbMjAx
NC0xMS0xNCAyMTozMjoxMy4yNjldIG1lbW9yeV9tYXA6YWRkOiBkb20xNyBnZm49ZjMwNzAg
bWZuPWZkZGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTMuMjc0XSBtZW1vcnlf
bWFwOnJlbW92ZTogZG9tMTcgZ2ZuPWYzMDcwIG1mbj1mZGRmZSBucj0xCihYRU4pIFsyMDE0
LTExLTE0IDIxOjMyOjEzLjI3OV0gbWVtb3J5X21hcDphZGQ6IGRvbTE3IGdmbj1mMzA3MCBt
Zm49ZmRkZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMy4zMTBdIGlycS5jOjI3
MDogRG9tMTcgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMAooWEVOKSBbMjAxNC0xMS0xNCAy
MTozMjoxMy4zMThdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMSBjaGFuZ2VkIDEwIC0+
IDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTMuMzI0XSBpcnEuYzoyNzA6IERvbTE3IFBD
SSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEzLjMz
MV0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwCihYRU4pIFsy
MDE0LTExLTE0IDIxOjMyOjE5Ljc2Ml0gc3RkdmdhLmM6MTQ3OmQxOHYwIGVudGVyaW5nIHN0
ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoyMC42NDJd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjIxLjY1MF0gaXJxLmM6MzgwOiBE
b20xOCBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMKKFhFTikg
WzIwMTQtMTEtMTQgMjE6MzI6MjIuODU2XSBpcnEuYzoyNzA6IERvbTE4IFBDSSBsaW5rIDAg
Y2hhbmdlZCA1IC0+IDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MjIuODY3XSBpcnEuYzoy
NzA6IERvbTE4IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwCihYRU4pIFsyMDE0LTExLTE0
IDIxOjMyOjIyLjg3OF0gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAyIGNoYW5nZWQgMTEg
LT4gMAooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoyMi44OTBdIGlycS5jOjI3MDogRG9tMTgg
UENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMAooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoyMy40
MDldIGdyYW50X3RhYmxlLmM6MTI5OTpkMTh2MyBFeHBhbmRpbmcgZG9tICgxOCkgZ3JhbnQg
dGFibGUgZnJvbSAoNCkgdG8gKDUpIGZyYW1lcy4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6
MzAuNjQyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjozNC4wOTBdIGdyYW50
X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gOCBmcmFtZXMK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6NDAuNjQyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xNCAyMTozMjo1MC42NDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjMzOjAw
LjY0M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzM6MTAuNjQzXSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMzoyMC42NDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE0IDIxOjMzOjMwLjY0NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzM6
NDAuNjQ0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMzo1MC42NDRdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjM0OjAwLjY0NF0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTQgMjE6MzQ6MTAuNjQ0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToz
NDoyMC42NDRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjM0OjMwLjY0NV0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzQ6NDAuNjQ1XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xNCAyMTozNDo1MC42NDVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIx
OjM1OjAwLjY0Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzU6MTAuNjQ2XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMTozNToyMC42NDZdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE0IDIxOjM1OjMwLjY0Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQg
MjE6MzU6NDAuNjQ2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMTozNTo1MC42NDZd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjM1OjU2Ljg2MV0gZ3JhbnRfdGFibGUu
YzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA5IGZyYW1lcwooWEVOKSBb
MjAxNC0xMS0xNCAyMTozNjowMC42NDddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIx
OjM2OjEwLjQxMF0gZ3JhbnRfdGFibGUuYzoxMjk5OmQxNnYxIEV4cGFuZGluZyBkb20gKDE2
KSBncmFudCB0YWJsZSBmcm9tICg1KSB0byAoNikgZnJhbWVzLgooWEVOKSBbMjAxNC0xMS0x
NCAyMTozNjoxMC44MjBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjM2OjIwLjgy
MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzY6MzAuODIwXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xNCAyMTozNjo0MC44MjFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjM2OjUwLjgyMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAu
Mzg4XSBDUFUwMDogCihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjM5OV0gQ1BVMDE6IAoo
WEVOKSBbMjAxNC0xMS0xNCAyMTozNzowMC40MTBdIGQxNiBPSy1zb2Z0aXJxIDIwbXNlYyBh
Z28sIHN0YXRlOjEsIDQxMjIwIGNvdW50LCBbcHJldjpmZmZmODMwNTRlZjVlM2UwLCBuZXh0
OmZmZmY4MzA1NGVmNWUzZTBdICBQSVJROjAKKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAu
NDQ1XSBkMTYgT0stcmFpc2UgICA0Nm1zZWMgYWdvLCBzdGF0ZToxLCA0MTIyMyBjb3VudCwg
W3ByZXY6MDAwMDAwMDAwMDIwMDIwMCwgbmV4dDowMDAwMDAwMDAwMTAwMTAwXSAgUElSUTow
CihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjQ4MV0gZDE2IEVSUi1wb2lzb24gOTJtc2Vj
IGFnbywgc3RhdGU6MCwgMSBjb3VudCwgW3ByZXY6MDAwMDAwMDAwMDIwMDIwMCwgbmV4dDow
MDAwMDAwMDAwMTAwMTAwXSAgUElSUTowCihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjUx
NV0gZDE2IFotc29mdGlycSAgMjg4NTNtc2VjIGFnbywgc3RhdGU6MiwgMSBjb3VudCwgW3By
ZXY6MDAwMDAwMDAwMDIwMDIwMCwgbmV4dDowMDAwMDAwMDAwMTAwMTAwXSAgUElSUTowCihY
RU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjU1MV0gQ1BVMDI6IAooWEVOKSBbMjAxNC0xMS0x
NCAyMTozNzowMC41NjFdIGQxNyBPSy1zb2Z0aXJxIDQzbXNlYyBhZ28sIHN0YXRlOjEsIDIz
ODEgY291bnQsIFtwcmV2OmZmZmY4MzA1NGVmNDdlODgsIG5leHQ6ZmZmZjgzMDU0ZWY0N2U4
OF0gIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAuNTk3XSBkMTcgT0stcmFp
c2UgICA3OW1zZWMgYWdvLCBzdGF0ZToxLCAyMzgxIGNvdW50LCBbcHJldjowMDAwMDAwMDAw
MjAwMjAwLCBuZXh0OjAwMDAwMDAwMDAxMDAxMDBdICBQSVJROjg3CihYRU4pIFsyMDE0LTEx
LTE0IDIxOjM3OjAwLjYzM10gQ1BVMDM6IAooWEVOKSBbMjAxNC0xMS0xNCAyMTozNzowMC42
NDNdIGQxNiBPSy1zb2Z0aXJxIDI3NG1zZWMgYWdvLCBzdGF0ZToxLCAzMjE2IGNvdW50LCBb
cHJldjpmZmZmODMwNTRlZjM3ZTg4LCBuZXh0OmZmZmY4MzA1NGVmMzdlODhdICBQSVJROjg3
CihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjY3OV0gZDE2IE9LLXJhaXNlICAgMzEwbXNl
YyBhZ28sIHN0YXRlOjEsIDMyMTYgY291bnQsIFtwcmV2OjAwMDAwMDAwMDAyMDAyMDAsIG5l
eHQ6MDAwMDAwMDAwMDEwMDEwMF0gIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6
MDAuNzE1XSBDUFUwNDogCihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjcyNl0gZDE3IE9L
LXNvZnRpcnEgMTA4bXNlYyBhZ28sIHN0YXRlOjEsIDI4NzIgY291bnQsIFtwcmV2OmZmZmY4
MzA1NGVmMjdlNzAsIG5leHQ6ZmZmZjgzMDU0ZWYyN2U3MF0gIFBJUlE6ODcKKFhFTikgWzIw
MTQtMTEtMTQgMjE6Mzc6MDAuNzYyXSBkMTcgT0stcmFpc2UgICAxNDNtc2VjIGFnbywgc3Rh
dGU6MSwgMjg3MiBjb3VudCwgW3ByZXY6MDAwMDAwMDAwMDIwMDIwMCwgbmV4dDowMDAwMDAw
MDAwMTAwMTAwXSAgUElSUTo4NwooWEVOKSBbMjAxNC0xMS0xNCAyMTozNzowMC43OThdIENQ
VTA1OiAKKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAuODA4XSBkMTcgT0stc29mdGlycSA1
OTBtc2VjIGFnbywgc3RhdGU6MSwgMjI4NyBjb3VudCwgW3ByZXY6ZmZmZjgzMDU0ZWYxZmU3
MCwgbmV4dDpmZmZmODMwNTRlZjFmZTcwXSAgUElSUTo4Ny0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE0IDIxOjM3OjAwLjg0Nl0gCihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjg1NV0g
ZDE3IE9LLXJhaXNlICAgNjM3bXNlYyBhZ28sIHN0YXRlOjEsIDIyODcgY291bnQsIFtwcmV2
OjAwMDAwMDAwMDAyMDAyMDAsIG5leHQ6MDAwMDAwMDAwMDEwMDEwMF0gIFBJUlE6ODcKKFhF
TikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAuODg5XSBkb21haW5fY3Jhc2ggY2FsbGVkIGZyb20g
aW8uYzo5MzgKKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAuODg5XSBEb21haW4gMTYgcmVw
b3J0ZWQgY3Jhc2hlZCBieSBkb21haW4gMzI3Njcgb24gY3B1IzE6CihYRU4pIFsyMDE0LTEx
LTE0IDIxOjM3OjEwLjg0NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MjAu
ODQ1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMTozNzozMC44NDVdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjQwLjg0Nl0gLS1NQVJLLS0KCjxTTklQPgoKKFhF
TikgWzIwMTQtMTEtMTQgMjI6MDY6MzAuODc4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
NCAyMjowNjo0MC44NzhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjUwLjg3
OF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSBJUlEgaW5mb3Jt
YXRpb246CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgIDAgYWZm
aW5pdHk6MDEgdmVjOmYwIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMCB0
aW1lcl9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElS
UTogICAxIGFmZmluaXR5OjAxIHZlYzozMCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9
MDAwMDAwMzQgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogIDEoLS0tKSwKKFhFTikgWzIw
MTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICAgMyBhZmZpbml0eTowMSB2ZWM6Mzgg
dHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAoo
WEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogICA0IGFmZmluaXR5OjAx
IHZlYzpmMSB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDAgbnMxNjU1MF9p
bnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogICA1
IGFmZmluaXR5OjAxIHZlYzo0MCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAw
MDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAg
SVJROiAgIDYgYWZmaW5pdHk6MDEgdmVjOjQ4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1
cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTgu
MTU2XSAgICBJUlE6ICAgNyBhZmZpbml0eTowMSB2ZWM6NTAgdHlwZT1JTy1BUElDLWVkZ2Ug
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAy
MjowNjo1OC4xNTZdICAgIElSUTogICA4IGFmZmluaXR5OjAxIHZlYzo1OCB0eXBlPUlPLUFQ
SUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDog
IDgoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICAgOSBh
ZmZpbml0eTozZiB2ZWM6NjAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElS
UTogIDEwIGFmZmluaXR5OjAxIHZlYzo2OCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9
MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgSVJROiAgMTEgYWZmaW5pdHk6MDEgdmVjOjcwIHR5cGU9SU8tQVBJQy1lZGdlICAg
IHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICBJUlE6ICAxMiBhZmZpbml0eTowMSB2ZWM6NzggdHlwZT1JTy1BUElD
LWVkZ2UgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDEy
KC0tLSksCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgMTMgYWZm
aW5pdHk6M2YgdmVjOjg4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBt
YXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6
ICAxNCBhZmZpbml0eTowMSB2ZWM6OTAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZd
ICAgIElSUTogIDE1IGFmZmluaXR5OjAxIHZlYzo5OCB0eXBlPUlPLUFQSUMtZWRnZSAgICBz
dGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2
OjU4LjE1Nl0gICAgSVJROiAgMTYgYWZmaW5pdHk6MDEgdmVjOjg5IHR5cGU9SU8tQVBJQy1s
ZXZlbCAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOiAxNigt
LS0pLAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDE3IGFmZmlu
aXR5OjAxIHZlYzpjMCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMzAgaW4t
ZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogMTcoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICBJUlE6ICAxOCBhZmZpbml0eTowMSB2ZWM6YjggdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDE4
KC0tLSksCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgMTkgYWZm
aW5pdHk6M2YgdmVjOjJhIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBt
YXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6
ICAyMiBhZmZpbml0eTowMiB2ZWM6YjkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAw
MDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDIyKC0tLSksMTM6IDIyKC0tLSks
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgMjUgYWZmaW5pdHk6
M2YgdmVjOjlhIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQs
IHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICAyOCBh
ZmZpbml0eTozZiB2ZWM6MjIgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElS
UTogIDI5IGFmZmluaXR5OjNmIHZlYzpkOSB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9
MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgSVJROiAgMzIgYWZmaW5pdHk6M2YgdmVjOmM5IHR5cGU9SU8tQVBJQy1sZXZlbCAg
IHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICBJUlE6ICAzMyBhZmZpbml0eTozZiB2ZWM6YzEgdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0x
MS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDM2IGFmZmluaXR5OjNmIHZlYzoyMSB0eXBl
PUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4p
IFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgMzcgYWZmaW5pdHk6MDIgdmVj
OjI5IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBk
b21haW4tbGlzdD0xNjogMzcoLU0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2
XSAgICBJUlE6ICAzOCBhZmZpbml0eTozZiB2ZWM6YTkgdHlwZT1JTy1BUElDLWxldmVsICAg
c3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjow
Njo1OC4xNTZdICAgIElSUTogIDQwIGFmZmluaXR5OjA4IHZlYzozMSB0eXBlPUlPLUFQSUMt
bGV2ZWwgICBzdGF0dXM9MDAwMDAwMTAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTc6IDQw
KC1NLSksCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgNDYgYWZm
aW5pdHk6M2YgdmVjOjcyIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBt
YXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6
ICA0NyBhZmZpbml0eTowMiB2ZWM6ZDEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAw
MDAwMDMwIGluLWZsaWdodD0xIGRvbWFpbi1saXN0PTE2OiA0NyhQLU0pLAooWEVOKSBbMjAx
NC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDQ4IGFmZmluaXR5OjNmIHZlYzpkMCB0
eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihY
RU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgNTEgYWZmaW5pdHk6M2Yg
dmVjOjhhIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVu
Ym91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA1MiBhZmZp
bml0eTozZiB2ZWM6MzkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1h
cHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTog
IDUzIGFmZmluaXR5OjNmIHZlYzpjOCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAw
MDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0g
ICAgSVJROiAgNTQgYWZmaW5pdHk6M2YgdmVjOmQ4IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0
YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6
NTguMTU2XSAgICBJUlE6ICA1NiBhZmZpbml0eTowMSB2ZWM6MjggdHlwZT1BTUQtSU9NTVUt
TVNJICAgc3RhdHVzPTAwMDAwMDAwIGlvbW11X2ludGVycnVwdF9oYW5kbGVyKCkKKFhFTikg
WzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA1NyBhZmZpbml0eTowOCB2ZWM6
YTAgdHlwZT1IUEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIGhwZXRfaW50ZXJydXB0
X2hhbmRsZXIoKQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDU4
IGFmZmluaXR5OjA4IHZlYzphOCB0eXBlPUhQRVQtTVNJICAgICAgICBzdGF0dXM9MDAwMDAw
MDAgaHBldF9pbnRlcnJ1cHRfaGFuZGxlcigpCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4
LjE1Nl0gICAgSVJROiAgNTkgYWZmaW5pdHk6MDQgdmVjOmIwIHR5cGU9SFBFVC1NU0kgICAg
ICAgIHN0YXR1cz0wMDAwMDAwMCBocGV0X2ludGVycnVwdF9oYW5kbGVyKCkKKFhFTikgWzIw
MTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA2MCBhZmZpbml0eTozZiB2ZWM6NDEg
dHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAoo
WEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDYxIGFmZmluaXR5OjNm
IHZlYzo0OSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1
bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgNjIgYWZm
aW5pdHk6M2YgdmVjOjUxIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBt
YXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6
ICA2MyBhZmZpbml0eTozZiB2ZWM6NTkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZd
ICAgIElSUTogIDY0IGFmZmluaXR5OjNmIHZlYzo2MSB0eXBlPVBDSS1NU0kgICAgICAgICBz
dGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2
OjU4LjE1Nl0gICAgSVJROiAgNjUgYWZmaW5pdHk6M2YgdmVjOjY5IHR5cGU9UENJLU1TSSAg
ICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEt
MTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA2NiBhZmZpbml0eTozZiB2ZWM6NzEgdHlwZT1Q
Q0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDY3IGFmZmluaXR5OjNmIHZlYzo3
OSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5k
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgNjggYWZmaW5pdHk6
M2YgdmVjOjgxIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQs
IHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA2OSBh
ZmZpbml0eTozZiB2ZWM6OTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElS
UTogIDcwIGFmZmluaXR5OjNmIHZlYzo5OSB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9
MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgSVJROiAgNzEgYWZmaW5pdHk6M2YgdmVjOmExIHR5cGU9UENJLU1TSS8tWCAgICAg
IHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICBJUlE6ICA3MiBhZmZpbml0eTozZiB2ZWM6YjEgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0x
MS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDczIGFmZmluaXR5OjAxIHZlYzozMiB0eXBl
PVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMTAgaW4tZmxpZ2h0PTAgZG9tYWluLWxp
c3Q9MDoyOTEoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6
ICA3NCBhZmZpbml0eTowMSB2ZWM6M2EgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAw
MDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkyKC0tLSksCihYRU4pIFsyMDE0
LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgNzUgYWZmaW5pdHk6MDEgdmVjOjQyIHR5
cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4t
bGlzdD0wOjI5MygtLS0pLAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElS
UTogIDc2IGFmZmluaXR5OjAxIHZlYzo0YSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9
MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyOTQoLS0tKSwKKFhFTikgWzIw
MTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA3NyBhZmZpbml0eTowMSB2ZWM6NTIg
dHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6Mjk1KC0tLSksCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAg
SVJROiAgNzggYWZmaW5pdHk6MDEgdmVjOjVhIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1
cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI5NigtLS0pLAooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDc5IGFmZmluaXR5OjNmIHZlYzo2
MiB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5k
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgODAgYWZmaW5pdHk6
M2YgdmVjOjZhIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQs
IHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA4MSBh
ZmZpbml0eTowMSB2ZWM6N2EgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDEw
IGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkwKC0tLSksCihYRU4pIFsyMDE0LTExLTE0
IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgODIgYWZmaW5pdHk6MDEgdmVjOjkyIHR5cGU9UENJ
LU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0w
OjI4OSgtLS0pLAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDgz
IGFmZmluaXR5OjAxIHZlYzphMiB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAw
MzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyODgoLS0tKSwKKFhFTikgWzIwMTQtMTEt
MTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA4NCBhZmZpbml0eTowOCB2ZWM6YWEgdHlwZT1Q
Q0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0
PTE2OiA4NygtLS0pLAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTog
IDg1IGFmZmluaXR5OjA4IHZlYzpiMiB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAw
MDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTY6IDg2KC0tLSksCihYRU4pIFsyMDE0
LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgODYgYWZmaW5pdHk6MDggdmVjOmJhIHR5
cGU9UENJLU1TSS8tWCAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4t
bGlzdD0xNjogODUoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJ
UlE6ICA4NyBhZmZpbml0eTowOCB2ZWM6YzIgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVz
PTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiA4NCgtLS0pLAooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDg4IGFmZmluaXR5OjA4IHZlYzpj
YSB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9t
YWluLWxpc3Q9MTY6IDgzKC0tLSksCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0g
ICAgSVJROiAgODkgYWZmaW5pdHk6MDggdmVjOmQyIHR5cGU9UENJLU1TSS8tWCAgICAgIHN0
YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0xNzogODcoLS0tKSwKKFhF
TikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA5MCBhZmZpbml0eToxMCB2
ZWM6ZGEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0w
IGRvbWFpbi1saXN0PTE3OiA4NigtLS0pLAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4x
NTZdICAgIElSUTogIDkxIGFmZmluaXR5OjEwIHZlYzoyMyB0eXBlPVBDSS1NU0kvLVggICAg
ICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTc6IDg1KC0tLSks
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgOTIgYWZmaW5pdHk6
MTAgdmVjOjJiIHR5cGU9UENJLU1TSS8tWCAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGln
aHQ9MCBkb21haW4tbGlzdD0xNzogODQoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6
NTguMTU2XSBEaXJlY3QgdmVjdG9yIGluZm9ybWF0aW9uOgooWEVOKSBbMjAxNC0xMS0xNCAy
MjowNjo1OC4xNTZdICAgIDB4MjAgLT4gaXJxX21vdmVfY2xlYW51cF9pbnRlcnJ1cHQoKQoo
WEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIDB4ZjkgLT4gcG11X2FwaWNfaW50
ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAweGZhIC0+IGFw
aWNfdGltZXJfaW50ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAg
ICAweGZiIC0+IGNhbGxfZnVuY3Rpb25faW50ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTQg
MjI6MDY6NTguMTU2XSAgICAweGZjIC0+IGV2ZW50X2NoZWNrX2ludGVycnVwdCgpCihYRU4p
IFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgMHhmZCAtPiBpbnZhbGlkYXRlX2ludGVy
cnVwdCgpCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgMHhmZSAtPiBlcnJv
cl9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIDB4ZmYg
LT4gc3B1cmlvdXNfaW50ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2
XSBJTy1BUElDIGludGVycnVwdCBpbmZvcm1hdGlvbjoKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICAgSVJRICAwIFZlYzI0MDoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6
NTguMTU2XSAgICAgICBBcGljIDB4MDAsIFBpbiAgMjogdmVjPWYwIGRlbGl2ZXJ5PUxvUHJp
IGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9p
ZDoxCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAgMSBWZWMgNDg6
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAwLCBQaW4g
IDE6IHZlYz0zMCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBp
cnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1
OC4xNTZdICAgICBJUlEgIDMgVmVjIDU2OgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4x
NTZdICAgICAgIEFwaWMgMHgwMCwgUGluICAzOiB2ZWM9MzggZGVsaXZlcnk9TG9QcmkgZGVz
dD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEK
KFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgSVJRICA0IFZlYzI0MToKKFhF
TikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgICBBcGljIDB4MDAsIFBpbiAgNDog
dmVjPWYxIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0w
IHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgIElSUSAgNSBWZWMgNjQ6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0g
ICAgICAgQXBpYyAweDAwLCBQaW4gIDU6IHZlYz00MCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwg
c3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVO
KSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEgIDYgVmVjIDcyOgooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMgMHgwMCwgUGluICA2OiB2ZWM9
NDggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJp
Zz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAg
ICAgSVJRICA3IFZlYyA4MDoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAg
ICBBcGljIDB4MDAsIFBpbiAgNzogdmVjPTUwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0
dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsy
MDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAgOCBWZWMgODg6CihYRU4pIFsyMDE0
LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAwLCBQaW4gIDg6IHZlYz01OCBk
ZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUg
bWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJ
UlEgIDkgVmVjIDk2OgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFw
aWMgMHgwMCwgUGluICA5OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0
LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAxMCBWZWMxMDQ6CihYRU4pIFsyMDE0LTEx
LTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAwLCBQaW4gMTA6IHZlYz02OCBkZWxp
dmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFz
az0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEg
MTEgVmVjMTEyOgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMg
MHgwMCwgUGluIDExOiB2ZWM9NzAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBv
bGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEt
MTQgMjI6MDY6NTguMTU2XSAgICAgSVJRIDEyIFZlYzEyMDoKKFhFTikgWzIwMTQtMTEtMTQg
MjI6MDY6NTguMTU2XSAgICAgICBBcGljIDB4MDAsIFBpbiAxMjogdmVjPTc4IGRlbGl2ZXJ5
PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAg
ZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAxMyBW
ZWMxMzY6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAw
LCBQaW4gMTM6IHZlYz04OCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJp
dHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTQg
MjI6MDY6NTguMTU2XSAgICAgSVJRIDE0IFZlYzE0NDoKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICAgICBBcGljIDB4MDAsIFBpbiAxNDogdmVjPTkwIGRlbGl2ZXJ5PUxv
UHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVz
dF9pZDoxCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAxNSBWZWMx
NTI6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAwLCBQ
aW4gMTU6IHZlYz05OCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9
MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNCAyMjow
Njo1OC4xNTZdICAgICBJUlEgMTYgVmVjMTM3OgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1
OC4xNTZdICAgICAgIEFwaWMgMHgwMCwgUGluIDE2OiB2ZWM9ODkgZGVsaXZlcnk9Rml4ZWQg
ZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lk
OjEKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgSVJRIDE3IFZlYzE5MjoK
KFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgICBBcGljIDB4MDAsIFBpbiAx
NzogdmVjPWMwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGly
cj0wIHRyaWc9TCBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4
LjE1Nl0gICAgIElSUSAxOCBWZWMxODQ6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgICAgQXBpYyAweDAwLCBQaW4gMTg6IHZlYz1iOCBkZWxpdmVyeT1GaXhlZCBkZXN0
PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQoo
WEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEgMTkgVmVjIDQyOgooWEVO
KSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMgMHgwMCwgUGluIDE5OiB2
ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAg
dHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgIElSUSAyMiBWZWMxODU6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0g
ICAgICAgQXBpYyAweDAwLCBQaW4gMjI6IHZlYz1iOSBkZWxpdmVyeT1GaXhlZCBkZXN0PUwg
c3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MgooWEVO
KSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEgMjUgVmVjMTU0OgooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMgMHgwMSwgUGluICAxOiB2ZWM9
MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJp
Zz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0g
ICAgIElSUSAyOCBWZWMgMzQ6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAg
ICAgQXBpYyAweDAxLCBQaW4gIDQ6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3Rh
dHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikg
WzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgSVJRIDI5IFZlYzIxNzoKKFhFTikgWzIw
MTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgICBBcGljIDB4MDEsIFBpbiAgNTogdmVjPTAw
IGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9
TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAg
ICBJUlEgMzIgVmVjMjAxOgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAg
IEFwaWMgMHgwMSwgUGluICA4OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1
cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsy
MDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAzMyBWZWMxOTM6CihYRU4pIFsyMDE0
LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAxLCBQaW4gIDk6IHZlYz0wMCBk
ZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwg
bWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAg
SVJRIDM2IFZlYyAzMzoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgICBB
cGljIDB4MDEsIFBpbiAxMjogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9
MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAx
NC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEgMzcgVmVjIDQxOgooWEVOKSBbMjAxNC0x
MS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMgMHgwMSwgUGluIDEzOiB2ZWM9MjkgZGVs
aXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1h
c2s9MCBkZXN0X2lkOjIKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgSVJR
IDM4IFZlYzE2OToKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgICBBcGlj
IDB4MDEsIFBpbiAxNDogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBw
b2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0x
MS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEgNDAgVmVjIDQ5OgooWEVOKSBbMjAxNC0xMS0x
NCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMgMHgwMSwgUGluIDE2OiB2ZWM9MzEgZGVsaXZl
cnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9
MCBkZXN0X2lkOjgKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgSVJRIDQ2
IFZlYzExNDoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU3XSAgICAgICBBcGljIDB4
MDEsIFBpbiAyMjogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xh
cml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0x
NCAyMjowNjo1OC4xNTddICAgICBJUlEgNDcgVmVjMjA5OgooWEVOKSBbMjAxNC0xMS0xNCAy
MjowNjo1OC4xNTddICAgICAgIEFwaWMgMHgwMSwgUGluIDIzOiB2ZWM9ZDEgZGVsaXZlcnk9
Rml4ZWQgZGVzdD1MIHN0YXR1cz0xIHBvbGFyaXR5PTEgaXJyPTEgdHJpZz1MIG1hc2s9MCBk
ZXN0X2lkOjIKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU3XSAgICAgSVJRIDQ4IFZl
YzIwODoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU3XSAgICAgICBBcGljIDB4MDEs
IFBpbiAyNDogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0
eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xNCAy
MjowNjo1OC4xNTddICAgICBJUlEgNTEgVmVjMTM4OgooWEVOKSBbMjAxNC0xMS0xNCAyMjow
Njo1OC4xNTddICAgICAgIEFwaWMgMHgwMSwgUGluIDI3OiB2ZWM9MDAgZGVsaXZlcnk9Rml4
ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0
X2lkOjYzCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1N10gICAgIElSUSA1MiBWZWMg
NTc6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1N10gICAgICAgQXBpYyAweDAxLCBQ
aW4gMjg6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9
MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU3XSAgICAgSVJRIDUzIFZlYzIwMDoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6
NTguMTU3XSAgICAgICBBcGljIDB4MDEsIFBpbiAyOTogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVk
IGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9p
ZDo2MwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xODldICAgICBJUlEgNTQgVmVjMjE2
OgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4yMDJdICAgICAgIEFwaWMgMHgwMSwgUGlu
IDMwOiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEg
aXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE0IDIyOjA3
OjAwLjg3OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSBNU0kg
aW5mb3JtYXRpb246CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAg
NTYgdmVjPTI4IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAw
MDAxIG1hc2s9MC8wLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgSFBFVCAg
ICA1NyB2ZWM9YTAgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAw
MDAwMDggbWFzaz0xLzAvPwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBIUEVU
ICAgIDU4IHZlYz1hOCBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0w
MDAwMDAwOCBtYXNrPTEvMC8/CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIEhQ
RVQgICAgNTkgdmVjPWIwIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0
PTAwMDAwMDA0IG1hc2s9MS8wLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAg
TVNJICAgICA2MCB2ZWM9NDEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRl
c3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJd
ICBNU0kgICAgIDYxIHZlYz00OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3Qg
ZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcx
Ml0gIE1TSSAgICAgNjIgdmVjPTUxIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2Vz
dCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMu
NzEyXSAgTVNJICAgICA2MyB2ZWM9NTkgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93
ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzow
My43MTJdICBNU0kgICAgIDY0IHZlYz02MSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBs
b3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3
OjAzLjcxMl0gIE1TSSAgICAgNjUgdmVjPTY5IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9n
IGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDc6MDMuNzEyXSAgTVNJICAgICA2NiB2ZWM9NzEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBs
b2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNCAy
MjowNzowMy43MTJdICBNU0kgICAgIDY3IHZlYz03OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQg
IGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE0
IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAgNjggdmVjPTgxIGxvd2VzdCAgZWRnZSAgIGFzc2Vy
dCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEt
MTQgMjI6MDc6MDMuNzEyXSAgTVNJICAgICA2OSB2ZWM9OTEgbG93ZXN0ICBlZGdlICAgYXNz
ZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0x
MS0xNCAyMjowNzowMy43MTJdICBNU0kgICAgIDcwIHZlYz05OSBsb3dlc3QgIGVkZ2UgICBh
c3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTEvMS8xCihYRU4pIFsyMDE0
LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAgNzEgdmVjPWExIGxvd2VzdCAgZWRnZSAg
IGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MS8xLzEKKFhFTikgWzIw
MTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgTVNJICAgICA3MiB2ZWM9YjEgbG93ZXN0ICBlZGdl
ICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0xLzEvMQooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBNU0kgICAgIDczIHZlYz0zMiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8/CihYRU4p
IFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAgNzQgdmVjPTNhIGxvd2VzdCAg
ZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8KKFhF
TikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgTVNJICAgICA3NSB2ZWM9NDIgbG93ZXN0
ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFzaz0wLzEvPwoo
WEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBNU0kgICAgIDc2IHZlYz00YSBsb3dl
c3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8/
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAgNzcgdmVjPTUyIGxv
d2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8x
Lz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgTVNJICAgICA3OCB2ZWM9NWEg
bG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFzaz0w
LzEvPwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBNU0kgICAgIDc5IHZlYz02
MiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNr
PTAvMS8/CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAgODAgdmVj
PTZhIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1h
c2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgTVNJICAgICA4MSB2
ZWM9N2EgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEg
bWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBNU0kgICAgIDgy
IHZlYz05MiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAw
MSBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAg
ODMgdmVjPWEyIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAw
MDAxIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgTVNJLVgg
ICA4NCB2ZWM9YWEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAw
MDAwMDggbWFzaz0xLzAvMAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBNU0kt
WCAgIDg1IHZlYz1iMiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0w
MDAwMDAwOCBtYXNrPTEvMC8wCihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1T
SS1YICAgODYgdmVjPWJhIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0
PTAwMDAwMDA4IG1hc2s9MS8wLzAKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAg
TVNJLVggICA4NyB2ZWM9YzIgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRl
c3Q9MDAwMDAwMDggbWFzaz0xLzAvMAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJd
ICBNU0ktWCAgIDg4IHZlYz1jYSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3Qg
ZGVzdD0wMDAwMDAwOCBtYXNrPTEvMC8wCihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcx
Ml0gIE1TSS1YICAgODkgdmVjPWQyIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2Vz
dCBkZXN0PTAwMDAwMDIwIG1hc2s9MS8wLzAKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMu
NzEyXSAgTVNJLVggICA5MCB2ZWM9ZGEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93
ZXN0IGRlc3Q9MDAwMDAwMTAgbWFzaz0xLzAvMAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzow
My43MTJdICBNU0ktWCAgIDkxIHZlYz0yMyBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBs
b3dlc3QgZGVzdD0wMDAwMDAxMCBtYXNrPTEvMC8wCihYRU4pIFsyMDE0LTExLTE0IDIyOjA3
OjAzLjcxMl0gIE1TSS1YICAgOTIgdmVjPTJiIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9n
IGxvd2VzdCBkZXN0PTAwMDAwMDEwIG1hc2s9MS8wLzAKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDc6MTAuODc5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzoyMC44NzldIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjMwLjg3OV0gLS1NQVJLLS0K
------------0FA1682463FBE0669
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0FA1682463FBE0669--



From xen-devel-bounces@lists.xen.org Fri Nov 14 22:10:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 22:10:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpP4C-00073z-Q9; Fri, 14 Nov 2014 22:10:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XpP4B-00073r-4d
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 22:10:07 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	2F/F1-02699-EBD76645; Fri, 14 Nov 2014 22:10:06 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416003002!12663643!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19111 invoked from network); 14 Nov 2014 22:10:02 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 14 Nov 2014 22:10:02 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:55262 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XpP2x-0006x3-SP; Fri, 14 Nov 2014 23:08:52 +0100
Date: Fri, 14 Nov 2014 23:09:58 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1402169526.20141114230958@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141114202513.GA3281@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0FA1682463FBE0669"
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0FA1682463FBE0669
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Friday, November 14, 2014, 9:25:13 PM, you wrote:

> On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> 
>> Friday, November 14, 2014, 4:43:58 PM, you wrote:
>> 
>> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
>> >> If it still helps i could try Andrews suggestion and try out with only 
>> >> commit aeeea485 ..
>> 
>> > Yes, even if it's pretty certain it's the second of the commits, verifying
>> > this would be helpful (or if the assumption is wrong, the pattern it's
>> > dying with would change and hence perhaps provide further clues).
>> 
>> > Jan
>> 
>> 
>> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
>> pasta without a panic. So it would probably be indeed that specific commit.

> Could you try running with these two patches while you enjoy an beer in the evening?

Hmm i didn't expect it not to panic and reboot anymore :-)

However xl dmesg (complete one attached) showed it would have:

(XEN) [2014-11-14 21:35:50.646] --MARK--
(XEN) [2014-11-14 21:35:56.861] grant_table.c:305:d0v0 Increased maptrack size to 9 frames
(XEN) [2014-11-14 21:36:00.647] --MARK--
(XEN) [2014-11-14 21:36:10.410] grant_table.c:1299:d16v1 Expanding dom (16) grant table from (5) to (6) frames.
(XEN) [2014-11-14 21:36:10.820] --MARK--
(XEN) [2014-11-14 21:36:20.820] --MARK--
(XEN) [2014-11-14 21:36:30.820] --MARK--
(XEN) [2014-11-14 21:36:40.821] --MARK--
(XEN) [2014-11-14 21:36:50.821] --MARK--
(XEN) [2014-11-14 21:37:00.388] CPU00:
(XEN) [2014-11-14 21:37:00.399] CPU01:
(XEN) [2014-11-14 21:37:00.410] d16 OK-softirq 20msec ago, state:1, 41220 count, [prev:ffff83054ef5e3e0, next:ffff83054ef5e3e0]  PIRQ:0
(XEN) [2014-11-14 21:37:00.445] d16 OK-raise   46msec ago, state:1, 41223 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
(XEN) [2014-11-14 21:37:00.481] d16 ERR-poison 92msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
(XEN) [2014-11-14 21:37:00.515] d16 Z-softirq  28853msec ago, state:2, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
(XEN) [2014-11-14 21:37:00.551] CPU02:
(XEN) [2014-11-14 21:37:00.561] d17 OK-softirq 43msec ago, state:1, 2381 count, [prev:ffff83054ef47e88, next:ffff83054ef47e88]  PIRQ:87
(XEN) [2014-11-14 21:37:00.597] d17 OK-raise   79msec ago, state:1, 2381 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:87
(XEN) [2014-11-14 21:37:00.633] CPU03:
(XEN) [2014-11-14 21:37:00.643] d16 OK-softirq 274msec ago, state:1, 3216 count, [prev:ffff83054ef37e88, next:ffff83054ef37e88]  PIRQ:87
(XEN) [2014-11-14 21:37:00.679] d16 OK-raise   310msec ago, state:1, 3216 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:87
(XEN) [2014-11-14 21:37:00.715] CPU04:
(XEN) [2014-11-14 21:37:00.726] d17 OK-softirq 108msec ago, state:1, 2872 count, [prev:ffff83054ef27e70, next:ffff83054ef27e70]  PIRQ:87
(XEN) [2014-11-14 21:37:00.762] d17 OK-raise   143msec ago, state:1, 2872 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:87
(XEN) [2014-11-14 21:37:00.798] CPU05:
(XEN) [2014-11-14 21:37:00.808] d17 OK-softirq 590msec ago, state:1, 2287 count, [prev:ffff83054ef1fe70, next:ffff83054ef1fe70]  PIRQ:87--MARK--
(XEN) [2014-11-14 21:37:00.846]
(XEN) [2014-11-14 21:37:00.855] d17 OK-raise   637msec ago, state:1, 2287 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:87
(XEN) [2014-11-14 21:37:00.889] domain_crash called from io.c:938
(XEN) [2014-11-14 21:37:00.889] Domain 16 reported crashed by domain 32767 on cpu#1:
(XEN) [2014-11-14 21:37:10.845] --MARK--
(XEN) [2014-11-14 21:37:20.845] --MARK--


>> 
>> --
>> Sander
>> 
------------0FA1682463FBE0669
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

bmcgTFZUMDogNzAwCihYRU4pIEdldHRpbmcgTFZUMTogNDAwCihYRU4pIGVuYWJsZWQgRXh0
SU5UIG9uIENQVSMwCihYRU4pIEVTUiB2YWx1ZSBiZWZvcmUgZW5hYmxpbmcgdmVjdG9yOiAw
eDQgIGFmdGVyOiAwCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcwooWEVOKSAgLT4gVXNp
bmcgbmV3IEFDSyBtZXRob2QKKFhFTikgaW5pdCBJT19BUElDIElSUXMKKFhFTikgIElPLUFQ
SUMgKGFwaWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0y
MSwgNi0yMiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcs
IDctOCwgNy05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3
LTE3LCA3LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3
LTI2LCA3LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuCihYRU4p
IC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMyPS0xIHBpbjI9LTEK
KFhFTikgbnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4KKFhFTikgbnVtYmVyIG9mIElP
LUFQSUMgIzYgcmVnaXN0ZXJzOiAyNC4KKFhFTikgbnVtYmVyIG9mIElPLUFQSUMgIzcgcmVn
aXN0ZXJzOiAzMi4KKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uCihYRU4pIElPIEFQSUMgIzYuLi4uLi4KKFhFTikgLi4uLiByZWdpc3RlciAjMDA6
IDA2MDAwMDAwCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNgooWEVO
KSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMAooWEVOKSAuLi4uLi4uICAgIDogTFRT
ICAgICAgICAgIDogMAooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzgwMjEKKFhFTikg
Li4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNwooWEVOKSAuLi4u
Li4uICAgICA6IFBSUSBpbXBsZW1lbnRlZDogMQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQ
SUMgdmVyc2lvbjogMDAyMQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYwMDAwMDAKKFhF
TikgLi4uLi4uLiAgICAgOiBhcmJpdHJhdGlvbjogMDYKKFhFTikgLi4uLiByZWdpc3RlciAj
MDM6IDA3MDAwMDAwCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAgICA6IDAKKFhFTikg
Li4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6CihYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJp
ZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgCihYRU4pICAwMCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAwMSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDMwCihYRU4pICAwMiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwCihYRU4pICAwMyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4CihYRU4pICAwNCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYxCihYRU4pICAwNSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwCihYRU4pICAwNiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4CihYRU4pICAwNyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDUwCihYRU4pICAwOCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4CihYRU4pICAwOSAwMDEgMDEgIDEg
ICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAwICAgIDAwCihYRU4pICAwYSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDY4CihYRU4pICAwYiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwCihYRU4pICAwYyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4CihYRU4pICAwZCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDg4CihYRU4pICAwZSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwCihYRU4pICAwZiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDk4CihYRU4pICAxMCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMiAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMyAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNiAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNyAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pIElPIEFQSUMgIzcuLi4u
Li4KKFhFTikgLi4uLiByZWdpc3RlciAjMDA6IDA3MDAwMDAwCihYRU4pIC4uLi4uLi4gICAg
OiBwaHlzaWNhbCBBUElDIGlkOiAwNwooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlw
ZTogMAooWEVOKSAuLi4uLi4uICAgIDogTFRTICAgICAgICAgIDogMAooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMTogMDAxRjgwMjEKKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rp
b24gZW50cmllczogMDAxRgooWEVOKSAuLi4uLi4uICAgICA6IFBSUSBpbXBsZW1lbnRlZDog
MQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMjogMDAwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAgOiBhcmJpdHJhdGlv
bjogMDAKKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6CihYRU4pICBOUiBMb2cg
UGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgCihYRU4pICAw
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
OSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
OSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pIFVz
aW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZwooWEVOKSBJUlEgdG8gcGluIG1hcHBpbmdzOgoo
WEVOKSBJUlEyNDAgLT4gMDoyCihYRU4pIElSUTQ4IC0+IDA6MQooWEVOKSBJUlE1NiAtPiAw
OjMKKFhFTikgSVJRMjQxIC0+IDA6NAooWEVOKSBJUlE2NCAtPiAwOjUKKFhFTikgSVJRNzIg
LT4gMDo2CihYRU4pIElSUTgwIC0+IDA6NwooWEVOKSBJUlE4OCAtPiAwOjgKKFhFTikgSVJR
OTYgLT4gMDo5CihYRU4pIElSUTEwNCAtPiAwOjEwCihYRU4pIElSUTExMiAtPiAwOjExCihY
RU4pIElSUTEyMCAtPiAwOjEyCihYRU4pIElSUTEzNiAtPiAwOjEzCihYRU4pIElSUTE0NCAt
PiAwOjE0CihYRU4pIElSUTE1MiAtPiAwOjE1CihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLiBkb25lLgooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGlu
dGVycnVwdHMuCihYRU4pIGNhbGlicmF0aW5nIEFQSUMgdGltZXIgLi4uCihYRU4pIC4uLi4u
IENQVSBjbG9jayBzcGVlZCBpcyAzMjAwLjE1MzEgTUh6LgooWEVOKSAuLi4uLiBob3N0IGJ1
cyBjbG9jayBzcGVlZCBpcyAyMDAuMDA5NCBNSHouCihYRU4pIC4uLi4uIGJ1c19zY2FsZSA9
IDB4Y2NkNwooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS41NjVdIFBsYXRmb3JtIHRpbWVy
IGlzIDE0LjMxOE1IeiBIUEVUCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjQ5LjU4Nl0gQWxs
b2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0
OjQ5LjU5Ml0gSFZNOiBBU0lEcyBlbmFibGVkLgooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0
OS41OThdIFNWTTogU3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOgooWEVOKSBbMjAxNC0x
MS0xNCAyMToyNDo0OS42MDRdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQooWEVOKSBb
MjAxNC0xMS0xNCAyMToyNDo0OS42MTBdICAtIExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBW
aXJ0dWFsaXNhdGlvbgooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS42MTZdICAtIE5leHQt
UklQIFNhdmVkIG9uICNWTUVYSVQKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NDkuNjIyXSAg
LSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVyCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjQ5LjYy
OV0gSFZNOiBTVk0gZW5hYmxlZAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS42MzVdIEhW
TTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVApIGRldGVjdGVkCihYRU4pIFsyMDE0
LTExLTE0IDIxOjI0OjQ5LjY0MV0gSFZNOiBIQVAgcGFnZSBzaXplczogNGtCLCAyTUIsIDFH
QgooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS42NDhdIEhWTTogUFZIIG1vZGUgbm90IHN1
cHBvcnRlZCBvbiB0aGlzIHBsYXRmb3JtCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjQ5LjY3
NF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS43
MDFdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzIKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NDku
NzI4XSBtYXNrZWQgRXh0SU5UIG9uIENQVSMzCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjQ5
Ljc1NF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0
OS43ODFdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzUKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6
NDkuNzg3XSBCcm91Z2h0IHVwIDYgQ1BVcwooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS43
OTddIEhQRVQ6IDMgdGltZXJzIHVzYWJsZSBmb3IgYnJvYWRjYXN0ICgzIHRvdGFsKQooWEVO
KSBbMjAxNC0xMS0xNCAyMToyNDo0OS44MjRdIEFDUEkgc2xlZXAgbW9kZXM6IFMzCihYRU4p
IFsyMDE0LTExLTE0IDIxOjI0OjQ5LjgzMF0gTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5nIHRv
IGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo0OS44
MzddIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4K
KFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NDkuODQ0XSBYZW5vcHJvZmlsZTogRmFpbGVkIHRv
IHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmCihYRU4pIFsyMDE0
LTExLTE0IDIxOjI0OjQ5Ljg1MV0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjUwLjAxOV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9
MHgxMDAwMDAwIG1lbXN6PTB4MTA2NTAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4w
MjZdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MjIwMDAwMCBtZW1zej0weDEw
NjAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4wMzNdIGVsZl9wYXJzZV9iaW5hcnk6
IHBoZHI6IHBhZGRyPTB4MjMwNjAwMCBtZW1zej0weDE0MjgwCihYRU4pIFsyMDE0LTExLTE0
IDIxOjI0OjUwLjA0MF0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgyMzFiMDAw
IG1lbXN6PTB4MTE0MDAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4wNDhdIGVsZl9w
YXJzZV9iaW5hcnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MzQ1YjAwMAooWEVOKSBbMjAx
NC0xMS0xNCAyMToyNDo1MC4wNTVdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAi
bGludXgiCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjA2Ml0gZWxmX3hlbl9wYXJzZV9u
b3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiIKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAu
MDcwXSBlbGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCihYRU4p
IFsyMDE0LTExLTE0IDIxOjI0OjUwLjA3N10gZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JB
U0UgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMDg0
XSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgyMzFiMWYwCihYRU4p
IFsyMDE0LTExLTE0IDIxOjI0OjUwLjA5Ml0gZWxmX3hlbl9wYXJzZV9ub3RlOiBIWVBFUkNB
TExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1
MC4xMDBdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2Vf
dGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2J8d3JpdGFibGVfZGVzY3JpcHRvcl90YWJsZXN8
YXV0b190cmFuc2xhdGVkX3BoeXNtYXB8c3VwZXJ2aXNvcl9tb2RlX2tlcm5lbCIKKFhFTikg
WzIwMTQtMTEtMTQgMjE6MjQ6NTAuMTE1XSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVUFBPUlRF
RF9GRUFUVVJFUyA9IDB4OTBkCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjEyM10gZWxm
X3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjUwLjEzMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKKFhF
TikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMTM5XSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25v
d24geGVuIGVsZiBub3RlICgweGQpCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjE0N10g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQooWEVOKSBbMjAxNC0x
MS0xNCAyMToyNDo1MC4xNTVdIGVsZl94ZW5fcGFyc2Vfbm90ZTogTU9EX1NUQVJUX1BGTiA9
IDB4MQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4xNjNdIGVsZl94ZW5fcGFyc2Vfbm90
ZTogSFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE0
IDIxOjI0OjUwLjE3Ml0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDAK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMTgxXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVj
azogYWRkcmVzc2VzOgooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4xODldICAgICB2aXJ0
X2Jhc2UgICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjUwLjE5OF0gICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MjQ6NTAuMjA3XSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAw
MDAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4yMTZdICAgICB2aXJ0X2tzdGFydCAg
ICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjIy
NV0gICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZmZmZmODM0NWIwMDAKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MjQ6NTAuMjM1XSAgICAgdmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZm
ZmY4MjMxYjFmMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4yNDRdICAgICBwMm1fYmFz
ZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0
OjUwLjI1NF0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MjQ6NTAuMjYzXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2Is
IHBhZGRyIDB4MTAwMDAwMCAtPiAweDM0NWIwMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6
NTAuMjc0XSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6CihYRU4pIFsyMDE0LTExLTE0
IDIxOjI0OjUwLjI4M10gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDA1NDgwMDAwMDAtPjAwMDAw
MDA1NGMwMDAwMDAgKDM3MjkzOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pIFsyMDE0
LTExLTE0IDIxOjI0OjUwLjI5NF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDA1NWYwY2EwMDAt
PjAwMDAwMDA1NWZmZmZhMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMzA1XSBWSVJU
VUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMzE1
XSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MzQ1YjAwMAoo
WEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4zMjVdICBJbml0LiByYW1kaXNrOiAwMDAwMDAw
MDAwMDAwMDAwLT4wMDAwMDAwMDAwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUw
LjMzNl0gIFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODM0NWIwMDAtPmZmZmZmZmZmODM3NWIw
MDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuMzQ3XSAgU3RhcnQgaW5mbzogICAgZmZm
ZmZmZmY4Mzc1YjAwMC0+ZmZmZmZmZmY4Mzc1YjRiNAooWEVOKSBbMjAxNC0xMS0xNCAyMToy
NDo1MC4zNTddICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzNzVjMDAwLT5mZmZmZmZmZjgz
NzdiMDAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjM2OF0gIEJvb3Qgc3RhY2s6ICAg
IGZmZmZmZmZmODM3N2IwMDAtPmZmZmZmZmZmODM3N2MwMDAKKFhFTikgWzIwMTQtMTEtMTQg
MjE6MjQ6NTAuMzc5XSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZm
ZmY4MzgwMDAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC4zOTBdICBFTlRSWSBBRERS
RVNTOiBmZmZmZmZmZjgyMzFiMWYwCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjQwMV0g
RG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjQx
Ml0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4
ZmZmZmZmZmY4MjA2NTAwMAooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1MC40MzBdIGVsZl9s
b2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MjIwMDAwMCAtPiAweGZmZmZmZmZm
ODIzMDYwMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTAuNDQxXSBlbGZfbG9hZF9iaW5h
cnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODIzMDYwMDAgLT4gMHhmZmZmZmZmZjgyMzFhMjgw
CihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUwLjQ1M10gZWxmX2xvYWRfYmluYXJ5OiBwaGRy
IDMgYXQgMHhmZmZmZmZmZjgyMzFiMDAwIC0+IDB4ZmZmZmZmZmY4MjQyMzAwMAooWEVOKSBb
MjAxNC0xMS0xNCAyMToyNDo1MC44NjVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjUxLjYxM10gU2NydWJiaW5nIEZyZWUgUkFNIG9uIDEgbm9kZXMgdXNpbmcgNiBDUFVz
CihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjUxLjcxN10gLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi5kb25lLgooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1NC44MDRdIEluaXRpYWwg
bG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgooWEVOKSBb
MjAxNC0xMS0xNCAyMToyNDo1NC44MTZdIFN0ZC4gTG9nbGV2ZWw6IEFsbAooWEVOKSBbMjAx
NC0xMS0xNCAyMToyNDo1NC44MjddIEd1ZXN0IExvZ2xldmVsOiBBbGwKKFhFTikgWzIwMTQt
MTEtMTQgMjE6MjQ6NTQuODM4XSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4K
KFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTQuOTM0XSAqKiogU2VyaWFsIGlucHV0IC0+IERP
TTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTQuOTM0XSBGcmVlZCAyODhrQiBpbml0IG1lbW9y
eS4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTUuMDg4XSBJT0FQSUNbMF06IFNldCBQQ0kg
cm91dGluZyBlbnRyeSAoNi05IC0+IDB4NjAgLT4gSVJRIDkgTW9kZToxIEFjdGl2ZToxKQoo
WEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1NS4xMTFdIHRyYXBzLmM6MjU3OTpkMHYwIERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAw
MDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjQ0NV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjQ0NV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI0OjU1LjQ0Nl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjU1LjQ0Nl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMy4wCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0Nl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDow
NS4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0N10gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDowNi4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0N10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDowOS4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0N10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDowYS4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0OF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDowYi4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjQ0OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYy4wCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjQ0OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowZC4wCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI0OjU1LjQ0OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMS4wCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjU1LjQ0OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4wCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
Mi4yCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ0OV0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxMy4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1MF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxMy4yCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1MF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxNC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1MV0g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4yCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjQ1MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4zCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjQ1MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC40CihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI0OjU1LjQ1MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41CihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjU1LjQ1Ml0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNS4wCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1Ml0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
Ni4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1Ml0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxNi4yCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1M10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxOC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1M10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxOC4xCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ1M10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjQ1M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4zCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjQ1M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40CihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI0OjU1LjQ1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowZjowMC4wCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjU1LjQ1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowZjowMC4xCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ2M10gUENJIGFkZCBkZXZpY2UgMDAwMDowZTow
MC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ2M10gUENJIGFkZCBkZXZpY2UgMDAw
MDowZTowMC4xCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ3M10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowZDowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ4M10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowYzowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjQ5M10g
UENJIGFkZCBkZXZpY2UgMDAwMDowYjowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjUwNF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjUxNF0gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4wCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI0OjU1LjUxNF0gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4xCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI0OjU1LjUyNF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4wCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjUzNF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNjow
MS4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjUzNF0gUENJIGFkZCBkZXZpY2UgMDAw
MDowNjowMi4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjUzNV0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowODowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjU0NF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowNzowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1LjU0NV0g
UENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4wCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU1
LjU1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMzowNi4wCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI0OjU1LjU1NV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTMgLT4g
MHg4OCAtPiBJUlEgMTMgTW9kZTowIEFjdGl2ZTowKQooWEVOKSBbMjAxNC0xMS0xNCAyMToy
NDo1NS41NzBdIFBDSTogVXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAwMC1mZgoo
WEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1NS41NjRdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg2LTggLT4gMHg1OCAtPiBJUlEgOCBNb2RlOjAgQWN0aXZlOjApCihYRU4p
IFsyMDE0LTExLTE0IDIxOjI0OjU1LjU3OF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDYtMTggLT4gMHhiOCAtPiBJUlEgMTggTW9kZToxIEFjdGl2ZToxKQooWEVOKSBb
MjAxNC0xMS0xNCAyMToyNDo1NS42NTNdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg2LTE3IC0+IDB4YzAgLT4gSVJRIDE3IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MjQ6NTUuODgzXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy0yOSAtPiAweGM4IC0+IElSUSA1MyBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0
LTExLTE0IDIxOjI0OjU1Ljg4M10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctMjQgLT4gMHhkMCAtPiBJUlEgNDggTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0x
MS0xNCAyMToyNDo1NS44ODRdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTMwIC0+IDB4ZDggLT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MjQ6NTUuODg0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0x
MiAtPiAweDIxIC0+IElSUSAzNiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE0
IDIxOjI0OjU1Ljg4NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTMg
LT4gMHgyOSAtPiBJUlEgMzcgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xNCAy
MToyNDo1NS44ODRdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE2IC0+
IDB4MzEgLT4gSVJRIDQwIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTQgMjE6
MjQ6NTUuOTUxXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yOCAtPiAw
eDM5IC0+IElSUSA1MiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0
OjU1Ljk1M10gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTYgLT4gMHg4
OSAtPiBJUlEgMTYgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNDo1
NS45NTRdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE0IC0+IDB4YTkg
LT4gSVJRIDM4IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTQgMjE6MjQ6NTYu
MDAzXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0yMiAtPiAweGI5IC0+
IElSUSAyMiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU4LjM0
NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOSAtPiAweGMxIC0+IElS
USAzMyBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU4LjQ0Nl0g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOCAtPiAweGM5IC0+IElSUSAz
MiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE0IDIxOjI0OjU4LjU0MV0gSU9B
UElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjMgLT4gMHhkMSAtPiBJUlEgNDcg
TW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNTowMC43NjddIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTUgLT4gMHhkOSAtPiBJUlEgMjkgTW9k
ZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNTowMC44NjldIElPQVBJQ1sx
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTQgLT4gMHgyMiAtPiBJUlEgMjggTW9kZTox
IEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNTowMS4wMjVdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE0IDIxOjI1OjAxLjAyOF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDYtMTkgLT4gMHgyYSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQooWEVO
KSBbMjAxNC0xMS0xNCAyMToyNTowMS4xOTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5n
IGVudHJ5ICg3LTIyIC0+IDB4NzIgLT4gSVJRIDQ2IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikg
WzIwMTQtMTEtMTQgMjE6MjU6MDEuMjQyXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNy0yNyAtPiAweDhhIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsy
MDE0LTExLTE0IDIxOjI1OjAzLjQ5Nl0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDctMSAtPiAweDlhIC0+IElSUSAyNSBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0
LTExLTE0IDIxOjI1OjEwLjYzM10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MjU6
MjAuNjM0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNTozMC42MzRdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjI1OjQwLjYzNF0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTQgMjE6MjU6NTAuNjM0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToy
NjowMC42MzVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjI2OjEwLjYzNV0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MjY6MjAuNjM1XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xNCAyMToyNjozMC42MzVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIx
OjI2OjQwLjYzNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MjY6NTAuNjM2XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNzowMC42MzZdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE0IDIxOjI3OjEwLjYzNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQg
MjE6Mjc6MjAuNjM2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToyNzozMC42Mzdd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjI3OjQwLjYzN10gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTQgMjE6Mjc6NTAuNjM3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
NCAyMToyODowMC42MzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjI4OjEwLjYz
OF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6Mjg6MjAuNjM4XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xNCAyMToyODozMC42MzhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjI4OjQwLjYzOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6Mjg6NTAu
NjM4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToyOTowMC42MzhdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE0IDIxOjI5OjEwLjYzOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTQgMjE6Mjk6MjAuNjM5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToyOToz
MC42MzldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjI5OjQwLjYzOV0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6Mjk6NTAuNjQwXSAtLU1BUkstLQooZDEpIFsyMDE0
LTExLTE0IDIxOjI5OjUyLjI2Nl0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1v
cnkKKGQxKSBbMjAxNC0xMS0xNCAyMToyOTo1Mi4yNjddIGFib3V0IHRvIGdldCBzdGFydGVk
Li4uCihYRU4pIFsyMDE0LTExLTE0IDIxOjI5OjUyLjUzMV0gdHJhcHMuYzoyNTc5OmQxdjAg
RG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAw
MDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKGQyKSBbMjAxNC0xMS0xNCAyMToy
OTo1OC4xODhdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMikgWzIw
MTQtMTEtMTQgMjE6Mjk6NTguMTg4XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBb
MjAxNC0xMS0xNCAyMToyOTo1OC4yNjRdIHRyYXBzLmM6MjU3OTpkMnYwIERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0
byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE0IDIxOjMwOjAwLjY0MF0g
LS1NQVJLLS0KKGQzKSBbMjAxNC0xMS0xNCAyMTozMDowNC4yODJdIG1hcHBpbmcga2VybmVs
IGludG8gcGh5c2ljYWwgbWVtb3J5CihkMykgWzIwMTQtMTEtMTQgMjE6MzA6MDQuMjgyXSBh
Ym91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMDowNC4zNzhd
IHRyYXBzLmM6MjU3OTpkM3YwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihk
NCkgWzIwMTQtMTEtMTQgMjE6MzA6MTAuMTA4XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNp
Y2FsIG1lbW9yeQooZDQpIFsyMDE0LTExLTE0IDIxOjMwOjEwLjEwOF0gYWJvdXQgdG8gZ2V0
IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzA6MTAuMTg5XSB0cmFwcy5jOjI1
Nzk6ZDR2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAw
eDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0x
MS0xNCAyMTozMDoxMC42NDBdIC0tTUFSSy0tCihkNSkgWzIwMTQtMTEtMTQgMjE6MzA6MTUu
ODgxXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDUpIFsyMDE0LTEx
LTE0IDIxOjMwOjE1Ljg4MV0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQt
MTEtMTQgMjE6MzA6MTUuOTU4XSB0cmFwcy5jOjI1Nzk6ZDV2MCBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgw
MDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMDoxOC4yOThdIGdyYW50
X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gMiBmcmFtZXMK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MzA6MjAuNjQwXSAtLU1BUkstLQooZDYpIFsyMDE0LTEx
LTE0IDIxOjMwOjIxLjg3NF0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkK
KGQ2KSBbMjAxNC0xMS0xNCAyMTozMDoyMS44NzRdIGFib3V0IHRvIGdldCBzdGFydGVkLi4u
CihYRU4pIFsyMDE0LTExLTE0IDIxOjMwOjIxLjk4Nl0gdHJhcHMuYzoyNTc5OmQ2djAgRG9t
YWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAw
MDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKGQ3KSBbMjAxNC0xMS0xNCAyMTozMDoy
OC4wMThdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkNykgWzIwMTQt
MTEtMTQgMjE6MzA6MjguMDE5XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAx
NC0xMS0xNCAyMTozMDoyOC4wOTNdIHRyYXBzLmM6MjU3OTpkN3YwIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAw
eDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE0IDIxOjMwOjMwLjY0MV0gLS1N
QVJLLS0KKGQ4KSBbMjAxNC0xMS0xNCAyMTozMDozNC4yMDRdIG1hcHBpbmcga2VybmVsIGlu
dG8gcGh5c2ljYWwgbWVtb3J5CihkOCkgWzIwMTQtMTEtMTQgMjE6MzA6MzQuMjA0XSBhYm91
dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMDozNC4yODBdIHRy
YXBzLmM6MjU3OTpkOHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihkOSkg
WzIwMTQtMTEtMTQgMjE6MzA6NDAuNjIwXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2Fs
IG1lbW9yeQooZDkpIFsyMDE0LTExLTE0IDIxOjMwOjQwLjYyMF0gYWJvdXQgdG8gZ2V0IHN0
YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzA6NDAuNjQxXSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xNCAyMTozMDo0MC43MDddIHRyYXBzLmM6MjU3OTpkOXYwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAw
MCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihkMTApIFsyMDE0LTExLTE0IDIxOjMwOjQ2LjUy
OF0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQxMCkgWzIwMTQtMTEt
MTQgMjE6MzA6NDYuNTI4XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0x
MS0xNCAyMTozMDo0Ni42MDhdIHRyYXBzLmM6MjU3OTpkMTB2MCBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgw
MDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMDo0Ny42OTVdIGdyYW50
X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gMyBmcmFtZXMK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MzA6NTAuNjQxXSAtLU1BUkstLQooZDExKSBbMjAxNC0x
MS0xNCAyMTozMDo1Mi41OTVdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5
CihkMTEpIFsyMDE0LTExLTE0IDIxOjMwOjUyLjU5NV0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQu
Li4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzA6NTIuNjg3XSB0cmFwcy5jOjI1Nzk6ZDExdjAg
RG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAw
MDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKGQxMikgWzIwMTQtMTEtMTQgMjE6
MzA6NTguNTY2XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDEyKSBb
MjAxNC0xMS0xNCAyMTozMDo1OC41NjZdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4p
IFsyMDE0LTExLTE0IDIxOjMwOjU4LjY1N10gdHJhcHMuYzoyNTc5OmQxMnYwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAw
MCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjAwLjY0
MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MDAuNzI4XSBncmFudF90YWJs
ZS5jOjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDQgZnJhbWVzCihYRU4p
IFsyMDE0LTExLTE0IDIxOjMxOjAwLjc1MF0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNy
ZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA1IGZyYW1lcwooZDEzKSBbMjAxNC0xMS0xNCAyMToz
MTowNS44MTldIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTMpIFsy
MDE0LTExLTE0IDIxOjMxOjA1LjgxOV0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikg
WzIwMTQtMTEtMTQgMjE6MzE6MDYuMDc3XSB0cmFwcy5jOjI1Nzk6ZDEzdjAgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAw
IHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MTAuNjQx
XSAtLU1BUkstLQooZDE0KSBbMjAxNC0xMS0xNCAyMTozMToxMi4xNDNdIG1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTQpIFsyMDE0LTExLTE0IDIxOjMxOjEyLjE0
NF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MTIu
MjM0XSB0cmFwcy5jOjI1Nzk6ZDE0djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZm
Zi4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MTUuNzY2XSBncmFudF90YWJsZS5jOjMwNTpk
MHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDYgZnJhbWVzCihkMTUpIFsyMDE0LTEx
LTE0IDIxOjMxOjE4LjM5OV0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkK
KGQxNSkgWzIwMTQtMTEtMTQgMjE6MzE6MTguMzk5XSBhYm91dCB0byBnZXQgc3RhcnRlZC4u
LgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMToxOC40OTFdIHRyYXBzLmM6MjU3OTpkMTV2MCBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAw
MDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xNCAyMToz
MToyMC42NDJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjI2LjU2OV0gaW8u
Yzo1NTA6IGQxNjogYmluZDogbV9nc2k9MzcgZ19nc2k9MzYgZGV2PTAwLjAwLjUgaW50eD0w
CihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjI4LjA5NV0gaW8uYzo1NTA6IGQxNjogYmluZDog
bV9nc2k9NDcgZ19nc2k9NDAgZGV2PTAwLjAwLjYgaW50eD0wCihkMTYpIFsyMDE0LTExLTE0
IDIxOjMxOjI4LjExMF0gSFZNIExvYWRlcgooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4x
MTBdIERldGVjdGVkIFhlbiB2NC41LjAtcmMKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6Mjgu
MTEwXSBYZW5idXMgcmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgMQooZDE2KSBb
MjAxNC0xMS0xNCAyMTozMToyOC4xMTBdIFN5c3RlbSByZXF1ZXN0ZWQgU2VhQklPUwooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC4xMTBdIENQVSBzcGVlZCBpcyAzMjAwIE1IegooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC4xMTFdIFJlbG9jYXRpbmcgZ3Vlc3QgbWVtb3J5IGZv
ciBsb3dtZW0gTU1JTyBzcGFjZSBkaXNhYmxlZAooWEVOKSBbMjAxNC0xMS0xNCAyMTozMToy
OC4xMTFdIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC4xMTFdIFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJ
UlE1CihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjI4LjExMV0gaXJxLmM6MjcwOiBEb20xNiBQ
Q0kgbGluayAxIGNoYW5nZWQgMCAtPiAxMAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4x
MTFdIFBDSS1JU0EgbGluayAxIHJvdXRlZCB0byBJUlExMAooWEVOKSBbMjAxNC0xMS0xNCAy
MTozMToyOC4xMTJdIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4g
MTEKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMTEyXSBQQ0ktSVNBIGxpbmsgMiByb3V0
ZWQgdG8gSVJRMTEKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMTEyXSBpcnEuYzoyNzA6
IERvbTE2IFBDSSBsaW5rIDMgY2hhbmdlZCAwIC0+IDUKKGQxNikgWzIwMTQtMTEtMTQgMjE6
MzE6MjguMTEyXSBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQooZDE2KSBbMjAxNC0x
MS0xNCAyMTozMToyOC4xMjhdIHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1CihkMTYpIFsyMDE0
LTExLTE0IDIxOjMxOjI4LjEzNF0gcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihkMTYpIFsy
MDE0LTExLTE0IDIxOjMxOjI4LjEzOV0gcGNpIGRldiAwMjowIElOVEEtPklSUTExCihkMTYp
IFsyMDE0LTExLTE0IDIxOjMxOjI4LjE1MF0gcGNpIGRldiAwNDowIElOVEEtPklSUTUKKGQx
NikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMTU3XSBwY2kgZGV2IDA1OjAgSU5UQS0+SVJRMTAK
KGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMTYzXSBwY2kgZGV2IDA2OjAgSU5UQS0+SVJR
MTEKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMjA4XSBObyBSQU0gaW4gaGlnaCBtZW1v
cnk7IHNldHRpbmcgaGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDAKKGQxNikg
WzIwMTQtMTEtMTQgMjE6MzE6MjguMjA4XSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAy
MDAwMDAwOiAwZjAwMDAwMDgKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMjEwXSBwY2kg
ZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQxNikgWzIwMTQt
MTEtMTQgMjE6MzE6MjguMjEyXSBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMjAwMDAw
OiAwZjMwMDAwMDQKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMjEzXSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKGQxNikgWzIwMTQtMTEt
MTQgMjE6MzE6MjguMjE4XSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUgMDAwMDQwMDAwOiAw
ZjMyMDAwMDAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMjIwXSBwY2kgZGV2IDA0OjAg
YmFyIDEwIHNpemUgMDAwMDIwMDAwOiAwZjMyNDAwMDAKKGQxNikgWzIwMTQtMTEtMTQgMjE6
MzE6MjguMjIxXSBwY2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEwMDAwOiAwZjMyNjAw
MDAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMjIxXSBwY2kgZGV2IDA1OjAgYmFyIDEw
IHNpemUgMDAwMDAyMDAwOiAwZjMyNzAwMDQKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6Mjgu
MjIxXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihk
MTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjIyOF0gcGNpIGRldiAwMzowIGJhciAxNCBzaXpl
IDAwMDAwMTAwMDogMGYzMjcyMDAwCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjIyOF0g
cGNpIGRldiAwMjowIGJhciAxMCBzaXplIDAwMDAwMDEwMDogMDAwMDBjMDAxCihkMTYpIFsy
MDE0LTExLTE0IDIxOjMxOjI4LjIzMV0gcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAw
MDA0MDogMDAwMDBjMTAxCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjIzM10gcGNpIGRl
diAwMToyIGJhciAyMCBzaXplIDAwMDAwMDAyMDogMDAwMDBjMTQxCihkMTYpIFsyMDE0LTEx
LTE0IDIxOjMxOjI4LjIzNl0gcGNpIGRldiAwMToxIGJhciAyMCBzaXplIDAwMDAwMDAxMDog
MDAwMDBjMTYxCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjIzOF0gPyE/IT8hPyE/IGVu
YWJsZSBJTyBvbiBwcmltYXJ5IHZnYSBwY2kgZGV2IDAzOjAgCihkMTYpIFsyMDE0LTExLTE0
IDIxOjMxOjI4LjIzOF0gTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246CihkMTYpIFsy
MDE0LTExLTE0IDIxOjMxOjI4LjI2M10gIC0gQ1BVMCAuLi4gNDgtYml0IHBoeXMgLi4uIGZp
eGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0LTEx
LTE0IDIxOjMxOjI4LjI4Nl0gIC0gQ1BVMSAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1U
UlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0LTExLTE0IDIx
OjMxOjI4LjMxMl0gIC0gQ1BVMiAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4u
LiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4
LjMzOF0gIC0gQ1BVMyAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIg
TVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjMzOF0g
VGVzdGluZyBIVk0gZW52aXJvbm1lbnQ6CihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM0
Nl0gIC0gUkVQIElOU0IgYWNyb3NzIHBhZ2UgYm91bmRhcmllcyAuLi4gcGFzc2VkCihkMTYp
IFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1MF0gIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1Mg
Li4uIHBhc3NlZAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNTBdIFBhc3NlZCAyIG9m
IDIgdGVzdHMKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzUwXSBXcml0aW5nIFNNQklP
UyB0YWJsZXMgLi4uCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1MV0gTG9hZGluZyBT
ZWFCSU9TIC4uLgooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNTFdIENyZWF0aW5nIE1Q
IHRhYmxlcyAuLi4KKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzUyXSBMb2FkaW5nIEFD
UEkgLi4uCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1M10gdm04NiBUU1MgYXQgZmMw
MGEyMDAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzU0XSBCSU9TIG1hcDoKKGQxNikg
WzIwMTQtMTEtMTQgMjE6MzE6MjguMzU0XSAgMTAwMDAtMTAwZDM6IFNjcmF0Y2ggc3BhY2UK
KGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzU0XSAgYzAwMDAtZmZmZmY6IE1haW4gQklP
UwooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNTRdIEU4MjAgdGFibGU6CihkMTYpIFsy
MDE0LTExLTE0IDIxOjMxOjI4LjM1NF0gIFswMF06IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAw
MDAwMDA6MDAwYTAwMDA6IFJBTQooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNTRdICBI
T0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGMwMDAwCihkMTYpIFsyMDE0
LTExLTE0IDIxOjMxOjI4LjM1NF0gIFswMV06IDAwMDAwMDAwOjAwMGMwMDAwIC0gMDAwMDAw
MDA6MDAxMDAwMDA6IFJFU0VSVkVECihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1NF0g
IFswMl06IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAwMDA6M2Y4MDAwMDA6IFJBTQooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNTRdICBIT0xFOiAwMDAwMDAwMDozZjgwMDAwMCAt
IDAwMDAwMDAwOmZjMDAwMDAwCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1NF0gIFsw
M106IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAwMDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVECihk
MTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM1NF0gSW52b2tpbmcgU2VhQklPUyAuLi4KKGQx
NikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzU3XSBTZWFCSU9TICh2ZXJzaW9uIHJlbC0xLjcu
NS0wLWdlNTE0ODhjLTIwMTQxMTE0XzIyMDMyMC1zZXJ2ZWVyc3RlcnRqZSkKKGQxNikgWzIw
MTQtMTEtMTQgMjE6MzE6MjguMzU3XSAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzU3
XSBGb3VuZCBYZW4gaHlwZXJ2aXNvciBzaWduYXR1cmUgYXQgNDAwMDAwMDAKKGQxNikgWzIw
MTQtMTEtMTQgMjE6MzE6MjguMzU3XSBSdW5uaW5nIG9uIFFFTVUgKGk0NDBmeCkKKGQxNikg
WzIwMTQtMTEtMTQgMjE6MzE6MjguMzU3XSB4ZW46IGNvcHkgZTgyMC4uLgooZDE2KSBbMjAx
NC0xMS0xNCAyMTozMToyOC4zNTddIFJlbG9jYXRpbmcgaW5pdCBmcm9tIDB4MDAwZGUyZTkg
dG8gMHgzZjdhZTRmMCAoc2l6ZSA3MjI2NykKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6Mjgu
MzYwXSBDUFUgTWh6PTMyMDEKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzY2XSBGb3Vu
ZCAxMCBQQ0kgZGV2aWNlcyAobWF4IFBDSSBidXMgaXMgMDApCihkMTYpIFsyMDE0LTExLTE0
IDIxOjMxOjI4LjM2Nl0gQWxsb2NhdGVkIFhlbiBoeXBlcmNhbGwgcGFnZSBhdCAzZjdmZjAw
MAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNjZdIERldGVjdGVkIFhlbiB2NC41LjAt
cmMKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzY2XSB4ZW46IGNvcHkgQklPUyB0YWJs
ZXMuLi4KKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzY2XSBDb3B5aW5nIFNNQklPUyBl
bnRyeSBwb2ludCBmcm9tIDB4MDAwMTAwMTAgdG8gMHgwMDBmNWRlMAooZDE2KSBbMjAxNC0x
MS0xNCAyMTozMToyOC4zNjZdIENvcHlpbmcgTVBUQUJMRSBmcm9tIDB4ZmMwMDExYTAvZmMw
MDExYjAgdG8gMHgwMDBmNWNjMAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC4zNjZdIENv
cHlpbmcgUElSIGZyb20gMHgwMDAxMDAzMCB0byAweDAwMGY1YzQwCihkMTYpIFsyMDE0LTEx
LTE0IDIxOjMxOjI4LjM2Nl0gQ29weWluZyBBQ1BJIFJTRFAgZnJvbSAweDAwMDEwMGIwIHRv
IDB4MDAwZjVjMTAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzY2XSBVc2luZyBwbXRp
bWVyLCBpb3BvcnQgMHhiMDA4CihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjM2Nl0gU2Nh
biBmb3IgVkdBIG9wdGlvbiByb20KKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguMzg0XSBS
dW5uaW5nIG9wdGlvbiByb20gYXQgYzAwMDowMDAzCihYRU4pIFsyMDE0LTExLTE0IDIxOjMx
OjI4LjM5M10gc3RkdmdhLmM6MTQ3OmQxNnYwIGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGlu
ZyBtb2RlcwooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC40MjBdIHBtbSBjYWxsIGFyZzE9
MAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC40MjFdIFR1cm5pbmcgb24gdmdhIHRleHQg
bW9kZSBjb25zb2xlCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU0Nl0gU2VhQklPUyAo
dmVyc2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTExNF8yMjAzMjAtc2VydmVlcnN0
ZXJ0amUpCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU2MF0gTWFjaGluZSBVVUlEIDcy
OGE2YTIyLTgzOGYtNDg1MC04YzIwLTgzOGQ3M2E1NDM4YwooZDE2KSBbMjAxNC0xMS0xNCAy
MTozMToyOC41NjFdIC8zZjdhZDAwMFwgU3RhcnQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0
IDIxOjMxOjI4LjU2MV0gfDNmN2FkMDAwfCBYSENJIGluaXQgb24gZGV2IDAwOjA1LjA6IHJl
Z3MgQCAweGYzMjcwMDAwLCA0IHBvcnRzLCAzMiBzbG90cywgMzIgYgooZDE2KSBbMjAxNC0x
MS0xNCAyMTozMToyOC41NjFdIHl0ZSBjb250ZXh0cwooZDE2KSBbMjAxNC0xMS0xNCAyMToz
MToyOC41NjFdIHwzZjdhZDAwMHwgWEhDSSAgICBleHRjYXAgMHgxIEAgZjMyNzA1MDAKKGQx
NikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNTYxXSB8M2Y3YWQwMDB8IFhIQ0kgICAgcHJvdG9j
b2wgVVNCICAzLjAwLCAyIHBvcnRzIChvZmZzZXQgMSksIGRlZiAwCihkMTYpIFsyMDE0LTEx
LTE0IDIxOjMxOjI4LjU2MV0gfDNmN2FkMDAwfCBYSENJICAgIHByb3RvY29sIFVTQiAgMi4w
MCwgMiBwb3J0cyAob2Zmc2V0IDMpLCBkZWYgMAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToy
OC41NjJdIC8zZjdhYjAwMFwgU3RhcnQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIxOjMx
OjI4LjU2Ml0gLzNmN2FhMDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6
MzE6MjguNTYyXSB8M2Y3YWQwMDB8IFVIQ0kgaW5pdCBvbiBkZXYgMDA6MDEuMiAoaW89YzE0
MCkKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNTYzXSAvM2Y3YTkwMDBcIFN0YXJ0IHRo
cmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC41NjNdIC8zZjdhODAwMFwgU3RhcnQg
dGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU2M10gRm91bmQgMCBscHQgcG9y
dHMKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNTY0XSBGb3VuZCAxIHNlcmlhbCBwb3J0
cwooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC41NjVdIEFUQSBjb250cm9sbGVyIDEgYXQg
MWYwLzNmNC8wIChpcnEgMTQgZGV2IDkpCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU2
NV0gLzNmN2E3MDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6Mjgu
NTY2XSBcM2Y3YWQwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6Mjgu
NTY2XSAvM2Y3YTYwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToy
OC41NjZdIFwzZjdhNjAwMC8gRW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToy
OC41NjZdIEFUQSBjb250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUgZGV2IDkpCihk
MTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU2Nl0gLzNmN2E2MDAwXCBTdGFydCB0aHJlYWQK
KGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNTY3XSBcM2Y3YTYwMDAvIEVuZCB0aHJlYWQK
KGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNTcwXSB8M2Y3YTcwMDB8IGF0YTAtMDogUUVN
VSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDEwMjQwIE1pQnl0ZXMpCihkMTYpIFsyMDE0
LTExLTE0IDIxOjMxOjI4LjU3MF0gfDNmN2E3MDAwfCBTZWFyY2hpbmcgYm9vdG9yZGVyIGZv
cjogL3BjaUBpMGNmOC8qQDEsMS9kcml2ZUAwL2Rpc2tAMAooZDE2KSBbMjAxNC0xMS0xNCAy
MTozMToyOC41NzFdIHwzZjdhNzAwMHwgYXRhMC0xOiBRRU1VIEhBUkRESVNLIEFUQS03IEhh
cmQtRGlzayAoMzAwIEdpQnl0ZXMpCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4LjU3MV0g
fDNmN2E3MDAwfCBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDEsMS9k
cml2ZUAwL2Rpc2tAMQooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC41NzFdIFwzZjdhNzAw
MC8gRW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC42MzFdIHwzZjdhODAw
MHwgdXNiX2hpZF9zZXR1cCAweDNmN2FkZGJjCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4
LjYzMV0gXDNmN2E4MDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4
LjYzMl0gXDNmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4
LjY2M10gLzNmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6
MjguNjYzXSBcM2Y3YTkwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6
MjguNjY0XSAvM2Y3YTkwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMToz
MToyOC42NjRdIFwzZjdhOTAwMC8gRW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNCAyMToz
MToyOC42NjRdIC8zZjdhOTAwMFwgU3RhcnQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIx
OjMxOjI4LjY2NF0gXDNmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIx
OjMxOjI4LjY2NF0gLzNmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQg
MjE6MzE6MjguNjY5XSB8M2Y3YWEwMDB8IFBTMiBrZXlib2FyZCBpbml0aWFsaXplZAooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC42NjldIFwzZjdhYTAwMC8gRW5kIHRocmVhZAooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC43MTRdIHwzZjdhOTAwMHwgWEhDSSBwb3J0ICM0OiAw
eDAwMjAwYTAzLCBwb3dlcmVkLCBlbmFibGVkLCBwbHMgMCwgc3BlZWQgMiBbTG93XQooZDE2
KSBbMjAxNC0xMS0xNCAyMTozMToyOC43NDRdIHwzZjdhOTAwMHwgdXNiX2hpZF9zZXR1cCAw
eDNmN2ZlYzIwCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4Ljc0NF0gXDNmN2E5MDAwLyBF
bmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjI4Ljc0NV0gfDNmN2FiMDAwfCBY
SENJIG5vIGRldmljZXMgZm91bmQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzUwXSBc
M2Y3YWIwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzUwXSBB
bGwgdGhyZWFkcyBjb21wbGV0ZS4KKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzUwXSBT
Y2FuIGZvciBvcHRpb24gcm9tcwooZDE2KSBbMjAxNC0xMS0xNCAyMTozMToyOC43ODRdIFJ1
bm5pbmcgb3B0aW9uIHJvbSBhdCBjOTgwOjAwMDMKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6
MjguNzkwXSBwbW0gY2FsbCBhcmcxPTEKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzkw
XSBwbW0gY2FsbCBhcmcxPTAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzkyXSBwbW0g
Y2FsbCBhcmcxPTEKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguNzkyXSBwbW0gY2FsbCBh
cmcxPTAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguODA5XSBTZWFyY2hpbmcgYm9vdG9y
ZGVyIGZvcjogL3BjaUBpMGNmOC8qQDQKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguODA5
XSAKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguODE2XSBQcmVzcyBGMTIgZm9yIGJvb3Qg
bWVudS4KKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MjguODE3XSAKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MzE6MzAuNjQyXSAtLU1BUkstLQooZDE2KSBbMjAxNC0xMS0xNCAyMTozMTozMS4z
NTddIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTYpIFsyMDE0LTExLTE0IDIx
OjMxOjMxLjM1OF0gZHJpdmUgMHgwMDBmNWJjMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xh
dGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwCihkMTYpIFsyMDE0LTExLTE0
IDIxOjMxOjMxLjM1OV0gZHJpdmUgMHgwMDBmNWI5MDogUENIUz0xNjM4My8xNi82MyB0cmFu
c2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTYyOTE0NTYwMAooZDE2KSBbMjAxNC0x
MS0xNCAyMTozMTozMS4zNTldIAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMTozMS4zNjBdIFNw
YWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjU2MDAtZjViOTAKKGQxNikg
WzIwMTQtMTEtMTQgMjE6MzE6MzEuMzYwXSBSZXR1cm5lZCAyNTM5NTIgYnl0ZXMgb2YgWm9u
ZUhpZ2gKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MzEuMzYwXSBlODIwIG1hcCBoYXMgNiBp
dGVtczoKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MzEuMzYwXSAgIDA6IDAwMDAwMDAwMDAw
MDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0KKGQxNikgWzIwMTQtMTEtMTQgMjE6
MzE6MzEuMzYwXSAgIDE6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEwMDAwID0g
MiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMTozMS4zNjBdICAgMjogMDAwMDAw
MDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgPSAyIFJFU0VSVkVECihkMTYpIFsyMDE0
LTExLTE0IDIxOjMxOjMxLjM2MF0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDAz
ZjdmZTAwMCA9IDEgUkFNCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjMxLjM2MV0gICA0OiAw
MDAwMDAwMDNmN2ZlMDAwIC0gMDAwMDAwMDAzZjgwMDAwMCA9IDIgUkVTRVJWRUQKKGQxNikg
WzIwMTQtMTEtMTQgMjE6MzE6MzEuMzYxXSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAgLSAwMDAw
MDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xNCAyMTozMTozMS4z
NjRdIGVudGVyIGhhbmRsZV8xOToKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MzEuMzY0XSAg
IE5VTEwKKGQxNikgWzIwMTQtMTEtMTQgMjE6MzE6MzEuMzkxXSBCb290aW5nIGZyb20gSGFy
ZCBEaXNrLi4uCihkMTYpIFsyMDE0LTExLTE0IDIxOjMxOjMxLjM5M10gQm9vdGluZyBmcm9t
IDAwMDA6N2MwMAooWEVOKSBbMjAxNC0xMS0xNCAyMTozMTozNi43NDFdIGlvLmM6NTUwOiBk
MTc6IGJpbmQ6IG1fZ3NpPTQwIGdfZ3NpPTM2IGRldj0wMC4wMC41IGludHg9MAooZDE3KSBb
MjAxNC0xMS0xNCAyMTozMTozNi45NjBdIEhWTSBMb2FkZXIKKGQxNykgWzIwMTQtMTEtMTQg
MjE6MzE6MzYuOTYwXSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihkMTcpIFsyMDE0LTExLTE0
IDIxOjMxOjM2Ljk2MF0gWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBldmVudCBjaGFubmVs
IDEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTYwXSBTeXN0ZW0gcmVxdWVzdGVkIFNl
YUJJT1MKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTYwXSBDUFUgc3BlZWQgaXMgMzIw
MCBNSHoKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTYwXSBSZWxvY2F0aW5nIGd1ZXN0
IG1lbW9yeSBmb3IgbG93bWVtIE1NSU8gc3BhY2UgZGlzYWJsZWQKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MzE6MzYuOTYxXSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDAgY2hhbmdlZCAw
IC0+IDUKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTYxXSBQQ0ktSVNBIGxpbmsgMCBy
b3V0ZWQgdG8gSVJRNQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMTozNi45NjFdIGlycS5jOjI3
MDogRG9tMTcgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKKGQxNykgWzIwMTQtMTEtMTQg
MjE6MzE6MzYuOTYxXSBQQ0ktSVNBIGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MzE6MzYuOTYxXSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDIgY2hh
bmdlZCAwIC0+IDExCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM2Ljk2Ml0gUENJLUlTQSBs
aW5rIDIgcm91dGVkIHRvIElSUTExCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjM2Ljk2Ml0g
aXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAzIGNoYW5nZWQgMCAtPiA1CihkMTcpIFsyMDE0
LTExLTE0IDIxOjMxOjM2Ljk2Ml0gUENJLUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUKKGQx
NykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTgyXSBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTAK
KGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTg3XSBwY2kgZGV2IDAyOjAgSU5UQS0+SVJR
MTEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzYuOTk4XSBwY2kgZGV2IDA0OjAgSU5UQS0+
SVJRNQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wMDVdIHBjaSBkZXYgMDU6MCBJTlRB
LT5JUlExMAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wNTddIE5vIFJBTSBpbiBoaWdo
IG1lbW9yeTsgc2V0dGluZyBoaWdoX21lbSByZXNvdXJjZSBiYXNlIHRvIDEwMDAwMDAwMAoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wNTddIHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6
ZSAwMDIwMDAwMDA6IDBmMDAwMDAwOAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wNTld
IHBjaSBkZXYgMDI6MCBiYXIgMTQgc2l6ZSAwMDEwMDAwMDA6IDBmMjAwMDAwOAooZDE3KSBb
MjAxNC0xMS0xNCAyMTozMTozNy4wNjFdIHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAw
NDAwMDA6IDBmMzAwMDAwMAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wNjNdIHBjaSBk
ZXYgMDQ6MCBiYXIgMTAgc2l6ZSAwMDAwMjAwMDA6IDBmMzA0MDAwMAooZDE3KSBbMjAxNC0x
MS0xNCAyMTozMTozNy4wNjNdIHBjaSBkZXYgMDM6MCBiYXIgMzAgc2l6ZSAwMDAwMTAwMDA6
IDBmMzA2MDAwMAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4wNjRdIHBjaSBkZXYgMDU6
MCBiYXIgMTAgc2l6ZSAwMDAwMDIwMDA6IDBmMzA3MDAwNAooWEVOKSBbMjAxNC0xMS0xNCAy
MTozMTozNy4wNjRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNyBnZm49ZjMwNzAgbWZuPWZkZGZl
IG5yPTEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMDcwXSBwY2kgZGV2IDAzOjAgYmFy
IDE0IHNpemUgMDAwMDAxMDAwOiAwZjMwNzIwMDAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuMDcwXSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDEK
KGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMDcyXSBwY2kgZGV2IDA0OjAgYmFyIDE0IHNp
emUgMDAwMDAwMDQwOiAwMDAwMGMxMDEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMDc1
XSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNDEKKGQxNykg
WzIwMTQtMTEtMTQgMjE6MzE6MzcuMDc3XSA/IT8hPyE/IT8gZW5hYmxlIElPIG9uIHByaW1h
cnkgdmdhIHBjaSBkZXYgMDM6MCAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMDc3XSBN
dWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuMTAwXSAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh
ciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTE2
XSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS
cyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTM2XSAgLSBD
UFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84
XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTM2XSBUZXN0aW5nIEhW
TSBlbnZpcm9ubWVudDoKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTQ2XSAgLSBSRVAg
SU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxNykgWzIwMTQtMTEt
MTQgMjE6MzE6MzcuMTUwXSAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2Vk
CihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjE1MF0gUGFzc2VkIDIgb2YgMiB0ZXN0cwoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNTBdIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAu
Li4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTUyXSBMb2FkaW5nIFNlYUJJT1MgLi4u
CihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjE1Ml0gQ3JlYXRpbmcgTVAgdGFibGVzIC4u
LgooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNTJdIExvYWRpbmcgQUNQSSAuLi4KKGQx
NykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTUzXSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE3
KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNTRdIEJJT1MgbWFwOgooZDE3KSBbMjAxNC0xMS0x
NCAyMTozMTozNy4xNTRdICAxMDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE3KSBbMjAx
NC0xMS0xNCAyMTozMTozNy4xNTRdICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTcpIFsy
MDE0LTExLTE0IDIxOjMxOjM3LjE1NF0gRTgyMCB0YWJsZToKKGQxNykgWzIwMTQtMTEtMTQg
MjE6MzE6MzcuMTU0XSAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBh
MDAwMDogUkFNCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjE1NF0gIEhPTEU6IDAwMDAw
MDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwYzAwMDAKKGQxNykgWzIwMTQtMTEtMTQgMjE6
MzE6MzcuMTU0XSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAw
MDogUkVTRVJWRUQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTU0XSAgWzAyXTogMDAw
MDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDoxZjgwMDAwMDogUkFNCihkMTcpIFsyMDE0LTEx
LTE0IDIxOjMxOjM3LjE1NF0gIEhPTEU6IDAwMDAwMDAwOjFmODAwMDAwIC0gMDAwMDAwMDA6
ZmMwMDAwMDAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTU0XSAgWzAzXTogMDAwMDAw
MDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxNykgWzIwMTQt
MTEtMTQgMjE6MzE6MzcuMTU0XSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE3KSBbMjAxNC0x
MS0xNCAyMTozMTozNy4xNTddIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4
OGMtMjAxNDExMTRfMjIwMzIwLXNlcnZlZXJzdGVydGplKQooZDE3KSBbMjAxNC0xMS0xNCAy
MTozMTozNy4xNTddIAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNTddIEZvdW5kIFhl
biBoeXBlcnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMAooZDE3KSBbMjAxNC0xMS0xNCAy
MTozMTozNy4xNThdIFJ1bm5pbmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE3KSBbMjAxNC0xMS0x
NCAyMTozMTozNy4xNThdIHhlbjogY29weSBlODIwLi4uCihkMTcpIFsyMDE0LTExLTE0IDIx
OjMxOjM3LjE1OF0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZTJlOSB0byAweDFmN2Fl
NGYwIChzaXplIDcyMjY3KQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNjBdIENQVSBN
aHo9MzIwMQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNjZdIEZvdW5kIDggUENJIGRl
dmljZXMgKG1heCBQQ0kgYnVzIGlzIDAwKQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4x
NjZdIEFsbG9jYXRlZCBYZW4gaHlwZXJjYWxsIHBhZ2UgYXQgMWY3ZmYwMDAKKGQxNykgWzIw
MTQtMTEtMTQgMjE6MzE6MzcuMTY2XSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihkMTcpIFsy
MDE0LTExLTE0IDIxOjMxOjM3LjE2Nl0geGVuOiBjb3B5IEJJT1MgdGFibGVzLi4uCihkMTcp
IFsyMDE0LTExLTE0IDIxOjMxOjM3LjE2Nl0gQ29weWluZyBTTUJJT1MgZW50cnkgcG9pbnQg
ZnJvbSAweDAwMDEwMDEwIHRvIDB4MDAwZjVkZTAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuMTY2XSBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMTgwL2ZjMDAxMTkwIHRvIDB4
MDAwZjVjZDAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMTY2XSBDb3B5aW5nIFBJUiBm
cm9tIDB4MDAwMTAwMzAgdG8gMHgwMDBmNWM1MAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMToz
Ny4xNjZdIENvcHlpbmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAwMGY1YzIw
CihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjE2Nl0gVXNpbmcgcG10aW1lciwgaW9wb3J0
IDB4YjAwOAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4xNjZdIFNjYW4gZm9yIFZHQSBv
cHRpb24gcm9tCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjE4M10gUnVubmluZyBvcHRp
b24gcm9tIGF0IGMwMDA6MDAwMwooWEVOKSBbMjAxNC0xMS0xNCAyMTozMTozNy4xOTNdIHN0
ZHZnYS5jOjE0NzpkMTd2MCBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMKKGQx
NykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMjI1XSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIw
MTQtMTEtMTQgMjE6MzE6MzcuMjI2XSBUdXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUgY29uc29s
ZQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4zNTRdIFNlYUJJT1MgKHZlcnNpb24gcmVs
LTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMTRfMjIwMzIwLXNlcnZlZXJzdGVydGplKQooZDE3
KSBbMjAxNC0xMS0xNCAyMTozMTozNy4zNzBdIE1hY2hpbmUgVVVJRCAyYjBjMjU2YS1lNTZm
LTQ1ZTUtYTc3OC03ZDU4MDE1ZWUzYzUKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMzcx
XSAvMWY3YWQwMDBcIFN0YXJ0IHRocmVhZAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4z
NzFdIHwxZjdhZDAwMHwgWEhDSSBpbml0IG9uIGRldiAwMDowNS4wOiByZWdzIEAgMHhmMzA3
MDAwMCwgNCBwb3J0cywgMzIgc2xvdHMsIDMyIGIKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuMzcxXSB5dGUgY29udGV4dHMKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMzcxXSB8
MWY3YWQwMDB8IFhIQ0kgICAgZXh0Y2FwIDB4MSBAIGYzMDcwNTAwCihkMTcpIFsyMDE0LTEx
LTE0IDIxOjMxOjM3LjM3MV0gfDFmN2FkMDAwfCBYSENJICAgIHByb3RvY29sIFVTQiAgMy4w
MCwgMiBwb3J0cyAob2Zmc2V0IDEpLCBkZWYgMAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMToz
Ny4zNzFdIHwxZjdhZDAwMHwgWEhDSSAgICBwcm90b2NvbCBVU0IgIDIuMDAsIDIgcG9ydHMg
KG9mZnNldCAzKSwgZGVmIDAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMzcxXSAvMWY3
YWMwMDBcIFN0YXJ0IHRocmVhZAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4zNzFdIC8x
ZjdhYTAwMFwgU3RhcnQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjM3Ml0g
XDFmN2FkMDAwLyBFbmQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjM3Ml0g
Rm91bmQgMCBscHQgcG9ydHMKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuMzczXSBGb3Vu
ZCAxIHNlcmlhbCBwb3J0cwooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4zNzNdIEFUQSBj
b250cm9sbGVyIDEgYXQgMWYwLzNmNC8wIChpcnEgMTQgZGV2IDkpCihkMTcpIFsyMDE0LTEx
LTE0IDIxOjMxOjM3LjM3M10gLzFmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNykgWzIwMTQt
MTEtMTQgMjE6MzE6MzcuMzc0XSBBVEEgY29udHJvbGxlciAyIGF0IDE3MC8zNzQvMCAoaXJx
IDE1IGRldiA5KQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy4zNzRdIC8xZjdhODAwMFwg
U3RhcnQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjM3NV0gXDFmN2E4MDAw
LyBFbmQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjM3OV0gfDFmN2E5MDAw
fCBhdGEwLTA6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICg1MTIwIE1pQnl0ZXMp
CihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjM3OV0gfDFmN2E5MDAwfCBTZWFyY2hpbmcg
Ym9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDEsMS9kcml2ZUAwL2Rpc2tAMAooZDE3KSBb
MjAxNC0xMS0xNCAyMTozMTozNy4zODBdIFwxZjdhOTAwMC8gRW5kIHRocmVhZAooZDE3KSBb
MjAxNC0xMS0xNCAyMTozMTozNy40NzJdIC8xZjdhOTAwMFwgU3RhcnQgdGhyZWFkCihkMTcp
IFsyMDE0LTExLTE0IDIxOjMxOjM3LjQ3Ml0gXDFmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTcp
IFsyMDE0LTExLTE0IDIxOjMxOjM3LjQ3Ml0gLzFmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQx
NykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNDcyXSBcMWY3YTkwMDAvIEVuZCB0aHJlYWQKKGQx
NykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNDczXSAvMWY3YTkwMDBcIFN0YXJ0IHRocmVhZAoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy40NzNdIFwxZjdhOTAwMC8gRW5kIHRocmVhZAoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy40NzNdIC8xZjdhOTAwMFwgU3RhcnQgdGhyZWFk
CihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjQ3N10gfDFmN2FhMDAwfCBQUzIga2V5Ym9h
cmQgaW5pdGlhbGl6ZWQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNDc3XSBcMWY3YWEw
MDAvIEVuZCB0aHJlYWQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNTIzXSB8MWY3YTkw
MDB8IFhIQ0kgcG9ydCAjNDogMHgwMDIwMGUwMywgcG93ZXJlZCwgZW5hYmxlZCwgcGxzIDAs
IHNwZWVkIDMgW0hpZ2hdCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjUzN10gXDFmN2E5
MDAwLyBFbmQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjM3LjUzN10gfDFmN2Fj
MDAwfCBYSENJIG5vIGRldmljZXMgZm91bmQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6Mzcu
NTQ1XSBcMWY3YWMwMDAvIEVuZCB0aHJlYWQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6Mzcu
NTQ1XSBBbGwgdGhyZWFkcyBjb21wbGV0ZS4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6Mzcu
NTQ1XSBTY2FuIGZvciBvcHRpb24gcm9tcwooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTozNy41
NjhdIFJ1bm5pbmcgb3B0aW9uIHJvbSBhdCBjOTgwOjAwMDMKKGQxNykgWzIwMTQtMTEtMTQg
MjE6MzE6MzcuNTc2XSBwbW0gY2FsbCBhcmcxPTEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuNTc2XSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNTc3
XSBwbW0gY2FsbCBhcmcxPTEKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNTc4XSBwbW0g
Y2FsbCBhcmcxPTAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNTk2XSBTZWFyY2hpbmcg
Ym9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDQKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6
MzcuNTk2XSAKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNjA0XSBQcmVzcyBGMTIgZm9y
IGJvb3QgbWVudS4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6MzcuNjA0XSAKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MzE6MzguMzE2XSBzdGR2Z2EuYzoxNTE6ZDE2djAgbGVhdmluZyBzdGR2
Z2EKKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6NDAuMTQ0XSBTZWFyY2hpbmcgYm9vdG9yZGVy
IGZvcjogSEFMVAooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4xNDRdIGRyaXZlIDB4MDAw
ZjViZDA6IFBDSFM9MTA0MDIvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9NjUyLzI1NS82
MyBzPTEwNDg1NzYwCihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjQwLjE0NV0gU3BhY2UgYXZh
aWxhYmxlIGZvciBVTUI6IGNhODAwLWVmMDAwLCBmNTYwMC1mNWJkMAooZDE3KSBbMjAxNC0x
MS0xNCAyMTozMTo0MC4xNDVdIFJldHVybmVkIDI1Mzk1MiBieXRlcyBvZiBab25lSGlnaAoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4xNDVdIGU4MjAgbWFwIGhhcyA2IGl0ZW1zOgoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4xNDVdICAgMDogMDAwMDAwMDAwMDAwMDAwMCAt
IDAwMDAwMDAwMDAwOWZjMDAgPSAxIFJBTQooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4x
NDVdICAgMTogMDAwMDAwMDAwMDA5ZmMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgPSAyIFJFU0VS
VkVECihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjQwLjE0NV0gICAyOiAwMDAwMDAwMDAwMGYw
MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCA9IDIgUkVTRVJWRUQKKGQxNykgWzIwMTQtMTEtMTQg
MjE6MzE6NDAuMTQ1XSAgIDM6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDFmN2ZlMDAw
ID0gMSBSQU0KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6NDAuMTQ1XSAgIDQ6IDAwMDAwMDAw
MWY3ZmUwMDAgLSAwMDAwMDAwMDFmODAwMDAwID0gMiBSRVNFUlZFRAooZDE3KSBbMjAxNC0x
MS0xNCAyMTozMTo0MC4xNDVdICAgNTogMDAwMDAwMDBmYzAwMDAwMCAtIDAwMDAwMDAxMDAw
MDAwMDAgPSAyIFJFU0VSVkVECihkMTcpIFsyMDE0LTExLTE0IDIxOjMxOjQwLjE0Nl0gZW50
ZXIgaGFuZGxlXzE5OgooZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4xNDZdICAgTlVMTAoo
ZDE3KSBbMjAxNC0xMS0xNCAyMTozMTo0MC4xNTJdIEJvb3RpbmcgZnJvbSBIYXJkIERpc2su
Li4KKGQxNykgWzIwMTQtMTEtMTQgMjE6MzE6NDAuMTU0XSBCb290aW5nIGZyb20gMDAwMDo3
YzAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjQwLjY0Ml0gLS1NQVJLLS0KKGQxOCkgWzIw
MTQtMTEtMTQgMjE6MzE6NDMuMTI5XSBIVk0gTG9hZGVyCihkMTgpIFsyMDE0LTExLTE0IDIx
OjMxOjQzLjEyOV0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE4KSBbMjAxNC0xMS0xNCAy
MTozMTo0My4xMjldIFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCAx
CihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjEzMF0gU3lzdGVtIHJlcXVlc3RlZCBTZWFC
SU9TCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjEzMF0gQ1BVIHNwZWVkIGlzIDMyMDAg
TUh6CihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjEzMF0gUmVsb2NhdGluZyBndWVzdCBt
ZW1vcnkgZm9yIGxvd21lbSBNTUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsyMDE0LTExLTE0
IDIxOjMxOjQzLjEzMF0gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAwIGNoYW5nZWQgMCAt
PiA1CihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjEzMF0gUENJLUlTQSBsaW5rIDAgcm91
dGVkIHRvIElSUTUKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMTMwXSBpcnEuYzoyNzA6
IERvbTE4IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCihkMTgpIFsyMDE0LTExLTE0IDIx
OjMxOjQzLjEzMF0gUENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihYRU4pIFsyMDE0
LTExLTE0IDIxOjMxOjQzLjEzMV0gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAyIGNoYW5n
ZWQgMCAtPiAxMQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4xMzFdIFBDSS1JU0EgbGlu
ayAyIHJvdXRlZCB0byBJUlExMQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMTo0My4xMzFdIGly
cS5jOjI3MDogRG9tMTggUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE4KSBbMjAxNC0x
MS0xNCAyMTozMTo0My4xMzFdIFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1CihkMTgp
IFsyMDE0LTExLTE0IDIxOjMxOjQzLjE1MF0gcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihk
MTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjE1NF0gcGNpIGRldiAwMjowIElOVEEtPklSUTEx
CihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjE2NV0gcGNpIGRldiAwNDowIElOVEEtPklS
UTUKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjE0XSBObyBSQU0gaW4gaGlnaCBtZW1v
cnk7IHNldHRpbmcgaGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDAKKGQxOCkg
WzIwMTQtMTEtMTQgMjE6MzE6NDMuMjE0XSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAy
MDAwMDAwOiAwZjAwMDAwMDgKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjE2XSBwY2kg
ZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQxOCkgWzIwMTQt
MTEtMTQgMjE6MzE6NDMuMjE3XSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUgMDAwMDQwMDAw
OiAwZjMwMDAwMDAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjE5XSBwY2kgZGV2IDA0
OjAgYmFyIDEwIHNpemUgMDAwMDIwMDAwOiAwZjMwNDAwMDAKKGQxOCkgWzIwMTQtMTEtMTQg
MjE6MzE6NDMuMjE5XSBwY2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEwMDAwOiAwZjMw
NjAwMDAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjIxXSBwY2kgZGV2IDAzOjAgYmFy
IDE0IHNpemUgMDAwMDAxMDAwOiAwZjMwNzAwMDAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6
NDMuMjIyXSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDEK
KGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjI0XSBwY2kgZGV2IDA0OjAgYmFyIDE0IHNp
emUgMDAwMDAwMDQwOiAwMDAwMGMxMDEKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjI2
XSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNDEKKGQxOCkg
WzIwMTQtMTEtMTQgMjE6MzE6NDMuMjI3XSA/IT8hPyE/IT8gZW5hYmxlIElPIG9uIHByaW1h
cnkgdmdhIHBjaSBkZXYgMDM6MCAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjI3XSBN
dWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6
NDMuMjQ2XSAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh
ciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjYy
XSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS
cyBbMS84XSAuLi4gZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjc5XSAgLSBD
UFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84
XSAuLi4gZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjk1XSAgLSBDUFUzIC4u
LiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4g
ZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMjk1XSBUZXN0aW5nIEhWTSBlbnZp
cm9ubWVudDoKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzA1XSAgLSBSRVAgSU5TQiBh
Y3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxOCkgWzIwMTQtMTEtMTQgMjE6
MzE6NDMuMzA5XSAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCihkMTgp
IFsyMDE0LTExLTE0IDIxOjMxOjQzLjMwOV0gUGFzc2VkIDIgb2YgMiB0ZXN0cwooZDE4KSBb
MjAxNC0xMS0xNCAyMTozMTo0My4zMDldIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KKGQx
OCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzEwXSBMb2FkaW5nIFNlYUJJT1MgLi4uCihkMTgp
IFsyMDE0LTExLTE0IDIxOjMxOjQzLjMxMF0gQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgooZDE4
KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMTFdIExvYWRpbmcgQUNQSSAuLi4KKGQxOCkgWzIw
MTQtMTEtMTQgMjE6MzE6NDMuMzEyXSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE4KSBbMjAx
NC0xMS0xNCAyMTozMTo0My4zMTNdIEJJT1MgbWFwOgooZDE4KSBbMjAxNC0xMS0xNCAyMToz
MTo0My4zMTNdICAxMDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE4KSBbMjAxNC0xMS0x
NCAyMTozMTo0My4zMTNdICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTgpIFsyMDE0LTEx
LTE0IDIxOjMxOjQzLjMxM10gRTgyMCB0YWJsZToKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6
NDMuMzEzXSAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDog
UkFNCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjMxM10gIEhPTEU6IDAwMDAwMDAwOjAw
MGEwMDAwIC0gMDAwMDAwMDA6MDAwYzAwMDAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMu
MzEzXSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVT
RVJWRUQKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzEzXSAgWzAyXTogMDAwMDAwMDA6
MDAxMDAwMDAgLSAwMDAwMDAwMDozZjgwMDAwMDogUkFNCihkMTgpIFsyMDE0LTExLTE0IDIx
OjMxOjQzLjMxM10gIEhPTEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAw
MDAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzEzXSAgWzAzXTogMDAwMDAwMDA6ZmMw
MDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxOCkgWzIwMTQtMTEtMTQg
MjE6MzE6NDMuMzEzXSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE4KSBbMjAxNC0xMS0xNCAy
MTozMTo0My4zMTZdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAx
NDExMTRfMjIwMzIwLXNlcnZlZXJzdGVydGplKQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0
My4zMTZdIAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMTZdIEZvdW5kIFhlbiBoeXBl
cnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0
My4zMTZdIFJ1bm5pbmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE4KSBbMjAxNC0xMS0xNCAyMToz
MTo0My4zMTZdIHhlbjogY29weSBlODIwLi4uCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQz
LjMxNl0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZTJlOSB0byAweDNmN2FlNGYwIChz
aXplIDcyMjY3KQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMThdIENQVSBNaHo9MzIw
MQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMjNdIEZvdW5kIDcgUENJIGRldmljZXMg
KG1heCBQQ0kgYnVzIGlzIDAwKQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMjNdIEFs
bG9jYXRlZCBYZW4gaHlwZXJjYWxsIHBhZ2UgYXQgM2Y3ZmYwMDAKKGQxOCkgWzIwMTQtMTEt
MTQgMjE6MzE6NDMuMzIzXSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihkMTgpIFsyMDE0LTEx
LTE0IDIxOjMxOjQzLjMyNF0geGVuOiBjb3B5IEJJT1MgdGFibGVzLi4uCihkMTgpIFsyMDE0
LTExLTE0IDIxOjMxOjQzLjMyNF0gQ29weWluZyBTTUJJT1MgZW50cnkgcG9pbnQgZnJvbSAw
eDAwMDEwMDEwIHRvIDB4MDAwZjVkZTAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzI0
XSBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMWEwL2ZjMDAxMWIwIHRvIDB4MDAwZjVj
YzAKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuMzI0XSBDb3B5aW5nIFBJUiBmcm9tIDB4
MDAwMTAwMzAgdG8gMHgwMDBmNWM0MAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMjRd
IENvcHlpbmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAwMGY1YzEwCihkMTgp
IFsyMDE0LTExLTE0IDIxOjMxOjQzLjMyNF0gVXNpbmcgcG10aW1lciwgaW9wb3J0IDB4YjAw
OAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My4zMjRdIFNjYW4gZm9yIFZHQSBvcHRpb24g
cm9tCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjMzOV0gUnVubmluZyBvcHRpb24gcm9t
IGF0IGMwMDA6MDAwMwooWEVOKSBbMjAxNC0xMS0xNCAyMTozMTo0My4zNDddIHN0ZHZnYS5j
OjE0NzpkMTh2MCBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMKKGQxOCkgWzIw
MTQtMTEtMTQgMjE6MzE6NDMuMzY3XSBwbW0gY2FsbCBhcmcxPTAKKGQxOCkgWzIwMTQtMTEt
MTQgMjE6MzE6NDMuMzY4XSBUdXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUgY29uc29sZQooZDE4
KSBbMjAxNC0xMS0xNCAyMTozMTo0My40OTddIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41
LTAtZ2U1MTQ4OGMtMjAxNDExMTRfMjIwMzIwLXNlcnZlZXJzdGVydGplKQooZDE4KSBbMjAx
NC0xMS0xNCAyMTozMTo0My41MTNdIE1hY2hpbmUgVVVJRCBlNTdkNmI2NC03YzAyLTQwMmIt
OTBiOS1hM2MyMzdkYmRmYTEKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuNTE0XSAvM2Y3
YWQwMDBcIFN0YXJ0IHRocmVhZAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MTRdIFwz
ZjdhZDAwMC8gRW5kIHRocmVhZAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MTRdIEFs
bCB0aHJlYWRzIGNvbXBsZXRlLgooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MTRdIC8z
ZjdhZDAwMFwgU3RhcnQgdGhyZWFkCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjUxNV0g
Rm91bmQgMCBscHQgcG9ydHMKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDMuNTE1XSBGb3Vu
ZCAwIHNlcmlhbCBwb3J0cwooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MTZdIEFUQSBj
b250cm9sbGVyIDEgYXQgMWYwLzNmNC8wIChpcnEgMTQgZGV2IDkpCihkMTgpIFsyMDE0LTEx
LTE0IDIxOjMxOjQzLjUxNl0gLzNmN2FjMDAwXCBTdGFydCB0aHJlYWQKKGQxOCkgWzIwMTQt
MTEtMTQgMjE6MzE6NDMuNTE3XSBBVEEgY29udHJvbGxlciAyIGF0IDE3MC8zNzQvMCAoaXJx
IDE1IGRldiA5KQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MTddIC8zZjdhYjAwMFwg
U3RhcnQgdGhyZWFkCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjUxN10gXDNmN2FiMDAw
LyBFbmQgdGhyZWFkCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjUyMl0gfDNmN2FjMDAw
fCBhdGEwLTA6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgxMDI0MCBNaUJ5dGVz
KQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My41MjJdIHwzZjdhYzAwMHwgU2VhcmNoaW5n
IGJvb3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDAKKGQxOCkg
WzIwMTQtMTEtMTQgMjE6MzE6NDMuNTIzXSBcM2Y3YWMwMDAvIEVuZCB0aHJlYWQKKGQxOCkg
WzIwMTQtMTEtMTQgMjE6MzE6NDMuNjIwXSB8M2Y3YWQwMDB8IFBTMiBrZXlib2FyZCBpbml0
aWFsaXplZAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42MjBdIFwzZjdhZDAwMC8gRW5k
IHRocmVhZAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42MjBdIEFsbCB0aHJlYWRzIGNv
bXBsZXRlLgooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42MjBdIFNjYW4gZm9yIG9wdGlv
biByb21zCihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQzLjY0OF0gUnVubmluZyBvcHRpb24g
cm9tIGF0IGM5ODA6MDAwMwooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42NTZdIHBtbSBj
YWxsIGFyZzE9MQooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42NTddIHBtbSBjYWxsIGFy
ZzE9MAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42NThdIHBtbSBjYWxsIGFyZzE9MQoo
ZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42NTldIHBtbSBjYWxsIGFyZzE9MAooZDE4KSBb
MjAxNC0xMS0xNCAyMTozMTo0My42ODBdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNp
QGkwY2Y4LypANAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0My42ODBdIAooZDE4KSBbMjAx
NC0xMS0xNCAyMTozMTo0My42ODhdIFByZXNzIEYxMiBmb3IgYm9vdCBtZW51LgooZDE4KSBb
MjAxNC0xMS0xNCAyMTozMTo0My42ODldIAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4y
NDFdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTgpIFsyMDE0LTExLTE0IDIx
OjMxOjQ2LjI0MV0gZHJpdmUgMHgwMDBmNWJjMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xh
dGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwCihkMTgpIFsyMDE0LTExLTE0
IDIxOjMxOjQ2LjI0MV0gU3BhY2UgYXZhaWxhYmxlIGZvciBVTUI6IGNhODAwLWVmMDAwLCBm
NTYwMC1mNWJjMAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDFdIFJldHVybmVkIDI1
ODA0OCBieXRlcyBvZiBab25lSGlnaAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDFd
IGU4MjAgbWFwIGhhcyA2IGl0ZW1zOgooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDFd
ICAgMDogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWZjMDAgPSAxIFJBTQooZDE4
KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDFdICAgMTogMDAwMDAwMDAwMDA5ZmMwMCAtIDAw
MDAwMDAwMDAwYTAwMDAgPSAyIFJFU0VSVkVECihkMTgpIFsyMDE0LTExLTE0IDIxOjMxOjQ2
LjI0MV0gICAyOiAwMDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCA9IDIgUkVT
RVJWRUQKKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDYuMjQxXSAgIDM6IDAwMDAwMDAwMDAx
MDAwMDAgLSAwMDAwMDAwMDNmN2ZmMDAwID0gMSBSQU0KKGQxOCkgWzIwMTQtMTEtMTQgMjE6
MzE6NDYuMjQxXSAgIDQ6IDAwMDAwMDAwM2Y3ZmYwMDAgLSAwMDAwMDAwMDNmODAwMDAwID0g
MiBSRVNFUlZFRAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDFdICAgNTogMDAwMDAw
MDBmYzAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJFU0VSVkVECihkMTgpIFsyMDE0
LTExLTE0IDIxOjMxOjQ2LjI0Ml0gZW50ZXIgaGFuZGxlXzE5OgooZDE4KSBbMjAxNC0xMS0x
NCAyMTozMTo0Ni4yNDJdICAgTlVMTAooZDE4KSBbMjAxNC0xMS0xNCAyMTozMTo0Ni4yNDld
IEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4KKGQxOCkgWzIwMTQtMTEtMTQgMjE6MzE6NDYu
MjUwXSBCb290aW5nIGZyb20gMDAwMDo3YzAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjQ4
LjAxOV0gc3RkdmdhLmM6MTUxOmQxN3YwIGxlYXZpbmcgc3RkdmdhCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjMxOjUwLjY0Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzE6NTEu
MTA5XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRv
IDcgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE0IDIxOjMxOjUzLjMwOV0gc3RkdmdhLmM6MTUx
OmQxOHYwIGxlYXZpbmcgc3RkdmdhCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjAwLjY0Ml0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MDQuNTU2XSBzdGR2Z2EuYzoxNDc6
ZDE2djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjMyOjA2LjgxN10gaXJxLmM6MzgwOiBEb20xNiBjYWxsYmFjayB2aWEgY2hhbmdl
ZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MDkuOTEy
XSBzdGR2Z2EuYzoxNDc6ZDE3djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVz
CihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEwLjY0Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTQgMjE6MzI6MTAuNzc4XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcw
IG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEwLjc4M10gbWVtb3J5
X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0x
MS0xNCAyMTozMjoxMC43ODZdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAg
bWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuNzkwXSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjMyOjEwLjc5Nl0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBt
Zm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMC44MDFdIG1lbW9yeV9t
YXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MzI6MTAuODA1XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1m
bj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEwLjgxMF0gbWVtb3J5X21h
cDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0x
NCAyMTozMjoxMC44MTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZu
PWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuODE5XSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE0
IDIxOjMyOjEwLjgyM10gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49
ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMC44MjhdIG1lbW9yeV9tYXA6
YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTQg
MjE6MzI6MTAuODQyXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1m
ZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuODUwXSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEt
MTQgMjE6MzI6MTAuODU2XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1m
bj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuODY0XSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQt
MTEtMTQgMjE6MzI6MTAuODcwXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAw
IG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuODc4XSBtZW1v
cnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MzI6MTAuODg1XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYz
MDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuODkyXSBt
ZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikg
WzIwMTQtMTEtMTQgMjE6MzI6MTAuODk3XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2Zu
PWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuOTA0
XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhF
TikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuOTA5XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYg
Z2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAu
OTE2XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuOTQxXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBs
aW5rIDAgY2hhbmdlZCA1IC0+IDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTAuOTU1XSBp
cnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwCihYRU4pIFsyMDE0
LTExLTE0IDIxOjMyOjEwLjk2OV0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAyIGNoYW5n
ZWQgMTEgLT4gMAooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMC45ODJdIGlycS5jOjI3MDog
RG9tMTYgUENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMAooWEVOKSBbMjAxNC0xMS0xNCAyMToz
MjoxMS42NTBdIGlycS5jOjM4MDogRG9tMTcgY2FsbGJhY2sgdmlhIGNoYW5nZWQgdG8gRGly
ZWN0IFZlY3RvciAweGYzCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEyLjMwOF0gZ3JhbnRf
dGFibGUuYzoxMjk5OmQxNnYyIEV4cGFuZGluZyBkb20gKDE2KSBncmFudCB0YWJsZSBmcm9t
ICg0KSB0byAoNSkgZnJhbWVzLgooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMy4yMzJdIG1l
bW9yeV9tYXA6cmVtb3ZlOiBkb20xNyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5yPTEKKFhFTikg
WzIwMTQtMTEtMTQgMjE6MzI6MTMuMjM2XSBtZW1vcnlfbWFwOmFkZDogZG9tMTcgZ2ZuPWYz
MDcwIG1mbj1mZGRmZSBucj0xCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEzLjI0MF0gbWVt
b3J5X21hcDpyZW1vdmU6IGRvbTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9MQooWEVOKSBb
MjAxNC0xMS0xNCAyMTozMjoxMy4yNDNdIG1lbW9yeV9tYXA6YWRkOiBkb20xNyBnZm49ZjMw
NzAgbWZuPWZkZGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTMuMjQ4XSBtZW1v
cnlfbWFwOnJlbW92ZTogZG9tMTcgZ2ZuPWYzMDcwIG1mbj1mZGRmZSBucj0xCihYRU4pIFsy
MDE0LTExLTE0IDIxOjMyOjEzLjI1Ml0gbWVtb3J5X21hcDphZGQ6IGRvbTE3IGdmbj1mMzA3
MCBtZm49ZmRkZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMy4yNTddIG1lbW9y
eV9tYXA6cmVtb3ZlOiBkb20xNyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5yPTEKKFhFTikgWzIw
MTQtMTEtMTQgMjE6MzI6MTMuMjYwXSBtZW1vcnlfbWFwOmFkZDogZG9tMTcgZ2ZuPWYzMDcw
IG1mbj1mZGRmZSBucj0xCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEzLjI2NV0gbWVtb3J5
X21hcDpyZW1vdmU6IGRvbTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9MQooWEVOKSBbMjAx
NC0xMS0xNCAyMTozMjoxMy4yNjldIG1lbW9yeV9tYXA6YWRkOiBkb20xNyBnZm49ZjMwNzAg
bWZuPWZkZGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTMuMjc0XSBtZW1vcnlf
bWFwOnJlbW92ZTogZG9tMTcgZ2ZuPWYzMDcwIG1mbj1mZGRmZSBucj0xCihYRU4pIFsyMDE0
LTExLTE0IDIxOjMyOjEzLjI3OV0gbWVtb3J5X21hcDphZGQ6IGRvbTE3IGdmbj1mMzA3MCBt
Zm49ZmRkZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoxMy4zMTBdIGlycS5jOjI3
MDogRG9tMTcgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMAooWEVOKSBbMjAxNC0xMS0xNCAy
MTozMjoxMy4zMThdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMSBjaGFuZ2VkIDEwIC0+
IDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MTMuMzI0XSBpcnEuYzoyNzA6IERvbTE3IFBD
SSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjEzLjMz
MV0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwCihYRU4pIFsy
MDE0LTExLTE0IDIxOjMyOjE5Ljc2Ml0gc3RkdmdhLmM6MTQ3OmQxOHYwIGVudGVyaW5nIHN0
ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoyMC42NDJd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjMyOjIxLjY1MF0gaXJxLmM6MzgwOiBE
b20xOCBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMKKFhFTikg
WzIwMTQtMTEtMTQgMjE6MzI6MjIuODU2XSBpcnEuYzoyNzA6IERvbTE4IFBDSSBsaW5rIDAg
Y2hhbmdlZCA1IC0+IDAKKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6MjIuODY3XSBpcnEuYzoy
NzA6IERvbTE4IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwCihYRU4pIFsyMDE0LTExLTE0
IDIxOjMyOjIyLjg3OF0gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAyIGNoYW5nZWQgMTEg
LT4gMAooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoyMi44OTBdIGlycS5jOjI3MDogRG9tMTgg
UENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMAooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjoyMy40
MDldIGdyYW50X3RhYmxlLmM6MTI5OTpkMTh2MyBFeHBhbmRpbmcgZG9tICgxOCkgZ3JhbnQg
dGFibGUgZnJvbSAoNCkgdG8gKDUpIGZyYW1lcy4KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6
MzAuNjQyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMjozNC4wOTBdIGdyYW50
X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gOCBmcmFtZXMK
KFhFTikgWzIwMTQtMTEtMTQgMjE6MzI6NDAuNjQyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xNCAyMTozMjo1MC42NDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjMzOjAw
LjY0M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzM6MTAuNjQzXSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMzoyMC42NDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE0IDIxOjMzOjMwLjY0NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzM6
NDAuNjQ0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMTozMzo1MC42NDRdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjM0OjAwLjY0NF0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTQgMjE6MzQ6MTAuNjQ0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMToz
NDoyMC42NDRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjM0OjMwLjY0NV0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzQ6NDAuNjQ1XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xNCAyMTozNDo1MC42NDVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIx
OjM1OjAwLjY0Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzU6MTAuNjQ2XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMTozNToyMC42NDZdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE0IDIxOjM1OjMwLjY0Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQg
MjE6MzU6NDAuNjQ2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMTozNTo1MC42NDZd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjM1OjU2Ljg2MV0gZ3JhbnRfdGFibGUu
YzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA5IGZyYW1lcwooWEVOKSBb
MjAxNC0xMS0xNCAyMTozNjowMC42NDddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIx
OjM2OjEwLjQxMF0gZ3JhbnRfdGFibGUuYzoxMjk5OmQxNnYxIEV4cGFuZGluZyBkb20gKDE2
KSBncmFudCB0YWJsZSBmcm9tICg1KSB0byAoNikgZnJhbWVzLgooWEVOKSBbMjAxNC0xMS0x
NCAyMTozNjoxMC44MjBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIxOjM2OjIwLjgy
MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6MzY6MzAuODIwXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xNCAyMTozNjo0MC44MjFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE0IDIxOjM2OjUwLjgyMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAu
Mzg4XSBDUFUwMDogCihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjM5OV0gQ1BVMDE6IAoo
WEVOKSBbMjAxNC0xMS0xNCAyMTozNzowMC40MTBdIGQxNiBPSy1zb2Z0aXJxIDIwbXNlYyBh
Z28sIHN0YXRlOjEsIDQxMjIwIGNvdW50LCBbcHJldjpmZmZmODMwNTRlZjVlM2UwLCBuZXh0
OmZmZmY4MzA1NGVmNWUzZTBdICBQSVJROjAKKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAu
NDQ1XSBkMTYgT0stcmFpc2UgICA0Nm1zZWMgYWdvLCBzdGF0ZToxLCA0MTIyMyBjb3VudCwg
W3ByZXY6MDAwMDAwMDAwMDIwMDIwMCwgbmV4dDowMDAwMDAwMDAwMTAwMTAwXSAgUElSUTow
CihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjQ4MV0gZDE2IEVSUi1wb2lzb24gOTJtc2Vj
IGFnbywgc3RhdGU6MCwgMSBjb3VudCwgW3ByZXY6MDAwMDAwMDAwMDIwMDIwMCwgbmV4dDow
MDAwMDAwMDAwMTAwMTAwXSAgUElSUTowCihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjUx
NV0gZDE2IFotc29mdGlycSAgMjg4NTNtc2VjIGFnbywgc3RhdGU6MiwgMSBjb3VudCwgW3By
ZXY6MDAwMDAwMDAwMDIwMDIwMCwgbmV4dDowMDAwMDAwMDAwMTAwMTAwXSAgUElSUTowCihY
RU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjU1MV0gQ1BVMDI6IAooWEVOKSBbMjAxNC0xMS0x
NCAyMTozNzowMC41NjFdIGQxNyBPSy1zb2Z0aXJxIDQzbXNlYyBhZ28sIHN0YXRlOjEsIDIz
ODEgY291bnQsIFtwcmV2OmZmZmY4MzA1NGVmNDdlODgsIG5leHQ6ZmZmZjgzMDU0ZWY0N2U4
OF0gIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAuNTk3XSBkMTcgT0stcmFp
c2UgICA3OW1zZWMgYWdvLCBzdGF0ZToxLCAyMzgxIGNvdW50LCBbcHJldjowMDAwMDAwMDAw
MjAwMjAwLCBuZXh0OjAwMDAwMDAwMDAxMDAxMDBdICBQSVJROjg3CihYRU4pIFsyMDE0LTEx
LTE0IDIxOjM3OjAwLjYzM10gQ1BVMDM6IAooWEVOKSBbMjAxNC0xMS0xNCAyMTozNzowMC42
NDNdIGQxNiBPSy1zb2Z0aXJxIDI3NG1zZWMgYWdvLCBzdGF0ZToxLCAzMjE2IGNvdW50LCBb
cHJldjpmZmZmODMwNTRlZjM3ZTg4LCBuZXh0OmZmZmY4MzA1NGVmMzdlODhdICBQSVJROjg3
CihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjY3OV0gZDE2IE9LLXJhaXNlICAgMzEwbXNl
YyBhZ28sIHN0YXRlOjEsIDMyMTYgY291bnQsIFtwcmV2OjAwMDAwMDAwMDAyMDAyMDAsIG5l
eHQ6MDAwMDAwMDAwMDEwMDEwMF0gIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6
MDAuNzE1XSBDUFUwNDogCihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjcyNl0gZDE3IE9L
LXNvZnRpcnEgMTA4bXNlYyBhZ28sIHN0YXRlOjEsIDI4NzIgY291bnQsIFtwcmV2OmZmZmY4
MzA1NGVmMjdlNzAsIG5leHQ6ZmZmZjgzMDU0ZWYyN2U3MF0gIFBJUlE6ODcKKFhFTikgWzIw
MTQtMTEtMTQgMjE6Mzc6MDAuNzYyXSBkMTcgT0stcmFpc2UgICAxNDNtc2VjIGFnbywgc3Rh
dGU6MSwgMjg3MiBjb3VudCwgW3ByZXY6MDAwMDAwMDAwMDIwMDIwMCwgbmV4dDowMDAwMDAw
MDAwMTAwMTAwXSAgUElSUTo4NwooWEVOKSBbMjAxNC0xMS0xNCAyMTozNzowMC43OThdIENQ
VTA1OiAKKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAuODA4XSBkMTcgT0stc29mdGlycSA1
OTBtc2VjIGFnbywgc3RhdGU6MSwgMjI4NyBjb3VudCwgW3ByZXY6ZmZmZjgzMDU0ZWYxZmU3
MCwgbmV4dDpmZmZmODMwNTRlZjFmZTcwXSAgUElSUTo4Ny0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE0IDIxOjM3OjAwLjg0Nl0gCihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjAwLjg1NV0g
ZDE3IE9LLXJhaXNlICAgNjM3bXNlYyBhZ28sIHN0YXRlOjEsIDIyODcgY291bnQsIFtwcmV2
OjAwMDAwMDAwMDAyMDAyMDAsIG5leHQ6MDAwMDAwMDAwMDEwMDEwMF0gIFBJUlE6ODcKKFhF
TikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAuODg5XSBkb21haW5fY3Jhc2ggY2FsbGVkIGZyb20g
aW8uYzo5MzgKKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MDAuODg5XSBEb21haW4gMTYgcmVw
b3J0ZWQgY3Jhc2hlZCBieSBkb21haW4gMzI3Njcgb24gY3B1IzE6CihYRU4pIFsyMDE0LTEx
LTE0IDIxOjM3OjEwLjg0NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjE6Mzc6MjAu
ODQ1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMTozNzozMC44NDVdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE0IDIxOjM3OjQwLjg0Nl0gLS1NQVJLLS0KCjxTTklQPgoKKFhF
TikgWzIwMTQtMTEtMTQgMjI6MDY6MzAuODc4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
NCAyMjowNjo0MC44NzhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjUwLjg3
OF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSBJUlEgaW5mb3Jt
YXRpb246CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgIDAgYWZm
aW5pdHk6MDEgdmVjOmYwIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMCB0
aW1lcl9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElS
UTogICAxIGFmZmluaXR5OjAxIHZlYzozMCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9
MDAwMDAwMzQgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogIDEoLS0tKSwKKFhFTikgWzIw
MTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICAgMyBhZmZpbml0eTowMSB2ZWM6Mzgg
dHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAoo
WEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogICA0IGFmZmluaXR5OjAx
IHZlYzpmMSB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDAgbnMxNjU1MF9p
bnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogICA1
IGFmZmluaXR5OjAxIHZlYzo0MCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAw
MDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAg
SVJROiAgIDYgYWZmaW5pdHk6MDEgdmVjOjQ4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1
cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTgu
MTU2XSAgICBJUlE6ICAgNyBhZmZpbml0eTowMSB2ZWM6NTAgdHlwZT1JTy1BUElDLWVkZ2Ug
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAy
MjowNjo1OC4xNTZdICAgIElSUTogICA4IGFmZmluaXR5OjAxIHZlYzo1OCB0eXBlPUlPLUFQ
SUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDog
IDgoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICAgOSBh
ZmZpbml0eTozZiB2ZWM6NjAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElS
UTogIDEwIGFmZmluaXR5OjAxIHZlYzo2OCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9
MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgSVJROiAgMTEgYWZmaW5pdHk6MDEgdmVjOjcwIHR5cGU9SU8tQVBJQy1lZGdlICAg
IHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICBJUlE6ICAxMiBhZmZpbml0eTowMSB2ZWM6NzggdHlwZT1JTy1BUElD
LWVkZ2UgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDEy
KC0tLSksCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgMTMgYWZm
aW5pdHk6M2YgdmVjOjg4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBt
YXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6
ICAxNCBhZmZpbml0eTowMSB2ZWM6OTAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZd
ICAgIElSUTogIDE1IGFmZmluaXR5OjAxIHZlYzo5OCB0eXBlPUlPLUFQSUMtZWRnZSAgICBz
dGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2
OjU4LjE1Nl0gICAgSVJROiAgMTYgYWZmaW5pdHk6MDEgdmVjOjg5IHR5cGU9SU8tQVBJQy1s
ZXZlbCAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOiAxNigt
LS0pLAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDE3IGFmZmlu
aXR5OjAxIHZlYzpjMCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMzAgaW4t
ZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogMTcoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICBJUlE6ICAxOCBhZmZpbml0eTowMSB2ZWM6YjggdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDE4
KC0tLSksCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgMTkgYWZm
aW5pdHk6M2YgdmVjOjJhIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBt
YXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6
ICAyMiBhZmZpbml0eTowMiB2ZWM6YjkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAw
MDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDIyKC0tLSksMTM6IDIyKC0tLSks
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgMjUgYWZmaW5pdHk6
M2YgdmVjOjlhIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQs
IHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICAyOCBh
ZmZpbml0eTozZiB2ZWM6MjIgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElS
UTogIDI5IGFmZmluaXR5OjNmIHZlYzpkOSB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9
MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgSVJROiAgMzIgYWZmaW5pdHk6M2YgdmVjOmM5IHR5cGU9SU8tQVBJQy1sZXZlbCAg
IHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICBJUlE6ICAzMyBhZmZpbml0eTozZiB2ZWM6YzEgdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0x
MS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDM2IGFmZmluaXR5OjNmIHZlYzoyMSB0eXBl
PUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4p
IFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgMzcgYWZmaW5pdHk6MDIgdmVj
OjI5IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBk
b21haW4tbGlzdD0xNjogMzcoLU0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2
XSAgICBJUlE6ICAzOCBhZmZpbml0eTozZiB2ZWM6YTkgdHlwZT1JTy1BUElDLWxldmVsICAg
c3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjow
Njo1OC4xNTZdICAgIElSUTogIDQwIGFmZmluaXR5OjA4IHZlYzozMSB0eXBlPUlPLUFQSUMt
bGV2ZWwgICBzdGF0dXM9MDAwMDAwMTAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTc6IDQw
KC1NLSksCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgNDYgYWZm
aW5pdHk6M2YgdmVjOjcyIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBt
YXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6
ICA0NyBhZmZpbml0eTowMiB2ZWM6ZDEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAw
MDAwMDMwIGluLWZsaWdodD0xIGRvbWFpbi1saXN0PTE2OiA0NyhQLU0pLAooWEVOKSBbMjAx
NC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDQ4IGFmZmluaXR5OjNmIHZlYzpkMCB0
eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihY
RU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgNTEgYWZmaW5pdHk6M2Yg
dmVjOjhhIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVu
Ym91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA1MiBhZmZp
bml0eTozZiB2ZWM6MzkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1h
cHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTog
IDUzIGFmZmluaXR5OjNmIHZlYzpjOCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAw
MDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0g
ICAgSVJROiAgNTQgYWZmaW5pdHk6M2YgdmVjOmQ4IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0
YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6
NTguMTU2XSAgICBJUlE6ICA1NiBhZmZpbml0eTowMSB2ZWM6MjggdHlwZT1BTUQtSU9NTVUt
TVNJICAgc3RhdHVzPTAwMDAwMDAwIGlvbW11X2ludGVycnVwdF9oYW5kbGVyKCkKKFhFTikg
WzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA1NyBhZmZpbml0eTowOCB2ZWM6
YTAgdHlwZT1IUEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIGhwZXRfaW50ZXJydXB0
X2hhbmRsZXIoKQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDU4
IGFmZmluaXR5OjA4IHZlYzphOCB0eXBlPUhQRVQtTVNJICAgICAgICBzdGF0dXM9MDAwMDAw
MDAgaHBldF9pbnRlcnJ1cHRfaGFuZGxlcigpCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4
LjE1Nl0gICAgSVJROiAgNTkgYWZmaW5pdHk6MDQgdmVjOmIwIHR5cGU9SFBFVC1NU0kgICAg
ICAgIHN0YXR1cz0wMDAwMDAwMCBocGV0X2ludGVycnVwdF9oYW5kbGVyKCkKKFhFTikgWzIw
MTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA2MCBhZmZpbml0eTozZiB2ZWM6NDEg
dHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAoo
WEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDYxIGFmZmluaXR5OjNm
IHZlYzo0OSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1
bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgNjIgYWZm
aW5pdHk6M2YgdmVjOjUxIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBt
YXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6
ICA2MyBhZmZpbml0eTozZiB2ZWM6NTkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZd
ICAgIElSUTogIDY0IGFmZmluaXR5OjNmIHZlYzo2MSB0eXBlPVBDSS1NU0kgICAgICAgICBz
dGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2
OjU4LjE1Nl0gICAgSVJROiAgNjUgYWZmaW5pdHk6M2YgdmVjOjY5IHR5cGU9UENJLU1TSSAg
ICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEt
MTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA2NiBhZmZpbml0eTozZiB2ZWM6NzEgdHlwZT1Q
Q0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDY3IGFmZmluaXR5OjNmIHZlYzo3
OSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5k
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgNjggYWZmaW5pdHk6
M2YgdmVjOjgxIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQs
IHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA2OSBh
ZmZpbml0eTozZiB2ZWM6OTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElS
UTogIDcwIGFmZmluaXR5OjNmIHZlYzo5OSB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9
MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgSVJROiAgNzEgYWZmaW5pdHk6M2YgdmVjOmExIHR5cGU9UENJLU1TSS8tWCAgICAg
IHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICBJUlE6ICA3MiBhZmZpbml0eTozZiB2ZWM6YjEgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0x
MS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDczIGFmZmluaXR5OjAxIHZlYzozMiB0eXBl
PVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMTAgaW4tZmxpZ2h0PTAgZG9tYWluLWxp
c3Q9MDoyOTEoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6
ICA3NCBhZmZpbml0eTowMSB2ZWM6M2EgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAw
MDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkyKC0tLSksCihYRU4pIFsyMDE0
LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgNzUgYWZmaW5pdHk6MDEgdmVjOjQyIHR5
cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4t
bGlzdD0wOjI5MygtLS0pLAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElS
UTogIDc2IGFmZmluaXR5OjAxIHZlYzo0YSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9
MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyOTQoLS0tKSwKKFhFTikgWzIw
MTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA3NyBhZmZpbml0eTowMSB2ZWM6NTIg
dHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6Mjk1KC0tLSksCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAg
SVJROiAgNzggYWZmaW5pdHk6MDEgdmVjOjVhIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1
cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI5NigtLS0pLAooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDc5IGFmZmluaXR5OjNmIHZlYzo2
MiB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5k
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgODAgYWZmaW5pdHk6
M2YgdmVjOjZhIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQs
IHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA4MSBh
ZmZpbml0eTowMSB2ZWM6N2EgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDEw
IGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkwKC0tLSksCihYRU4pIFsyMDE0LTExLTE0
IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgODIgYWZmaW5pdHk6MDEgdmVjOjkyIHR5cGU9UENJ
LU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0w
OjI4OSgtLS0pLAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDgz
IGFmZmluaXR5OjAxIHZlYzphMiB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAw
MzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyODgoLS0tKSwKKFhFTikgWzIwMTQtMTEt
MTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA4NCBhZmZpbml0eTowOCB2ZWM6YWEgdHlwZT1Q
Q0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0
PTE2OiA4NygtLS0pLAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTog
IDg1IGFmZmluaXR5OjA4IHZlYzpiMiB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAw
MDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTY6IDg2KC0tLSksCihYRU4pIFsyMDE0
LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgODYgYWZmaW5pdHk6MDggdmVjOmJhIHR5
cGU9UENJLU1TSS8tWCAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4t
bGlzdD0xNjogODUoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJ
UlE6ICA4NyBhZmZpbml0eTowOCB2ZWM6YzIgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVz
PTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiA4NCgtLS0pLAooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIElSUTogIDg4IGFmZmluaXR5OjA4IHZlYzpj
YSB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9t
YWluLWxpc3Q9MTY6IDgzKC0tLSksCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0g
ICAgSVJROiAgODkgYWZmaW5pdHk6MDggdmVjOmQyIHR5cGU9UENJLU1TSS8tWCAgICAgIHN0
YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0xNzogODcoLS0tKSwKKFhF
TikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICBJUlE6ICA5MCBhZmZpbml0eToxMCB2
ZWM6ZGEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0w
IGRvbWFpbi1saXN0PTE3OiA4NigtLS0pLAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4x
NTZdICAgIElSUTogIDkxIGFmZmluaXR5OjEwIHZlYzoyMyB0eXBlPVBDSS1NU0kvLVggICAg
ICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTc6IDg1KC0tLSks
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgSVJROiAgOTIgYWZmaW5pdHk6
MTAgdmVjOjJiIHR5cGU9UENJLU1TSS8tWCAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGln
aHQ9MCBkb21haW4tbGlzdD0xNzogODQoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6
NTguMTU2XSBEaXJlY3QgdmVjdG9yIGluZm9ybWF0aW9uOgooWEVOKSBbMjAxNC0xMS0xNCAy
MjowNjo1OC4xNTZdICAgIDB4MjAgLT4gaXJxX21vdmVfY2xlYW51cF9pbnRlcnJ1cHQoKQoo
WEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIDB4ZjkgLT4gcG11X2FwaWNfaW50
ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAweGZhIC0+IGFw
aWNfdGltZXJfaW50ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAg
ICAweGZiIC0+IGNhbGxfZnVuY3Rpb25faW50ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTQg
MjI6MDY6NTguMTU2XSAgICAweGZjIC0+IGV2ZW50X2NoZWNrX2ludGVycnVwdCgpCihYRU4p
IFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgMHhmZCAtPiBpbnZhbGlkYXRlX2ludGVy
cnVwdCgpCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgMHhmZSAtPiBlcnJv
cl9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgIDB4ZmYg
LT4gc3B1cmlvdXNfaW50ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2
XSBJTy1BUElDIGludGVycnVwdCBpbmZvcm1hdGlvbjoKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICAgSVJRICAwIFZlYzI0MDoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6
NTguMTU2XSAgICAgICBBcGljIDB4MDAsIFBpbiAgMjogdmVjPWYwIGRlbGl2ZXJ5PUxvUHJp
IGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9p
ZDoxCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAgMSBWZWMgNDg6
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAwLCBQaW4g
IDE6IHZlYz0zMCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBp
cnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1
OC4xNTZdICAgICBJUlEgIDMgVmVjIDU2OgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4x
NTZdICAgICAgIEFwaWMgMHgwMCwgUGluICAzOiB2ZWM9MzggZGVsaXZlcnk9TG9QcmkgZGVz
dD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEK
KFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgSVJRICA0IFZlYzI0MToKKFhF
TikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgICBBcGljIDB4MDAsIFBpbiAgNDog
dmVjPWYxIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0w
IHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgIElSUSAgNSBWZWMgNjQ6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0g
ICAgICAgQXBpYyAweDAwLCBQaW4gIDU6IHZlYz00MCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwg
c3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVO
KSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEgIDYgVmVjIDcyOgooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMgMHgwMCwgUGluICA2OiB2ZWM9
NDggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJp
Zz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAg
ICAgSVJRICA3IFZlYyA4MDoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAg
ICBBcGljIDB4MDAsIFBpbiAgNzogdmVjPTUwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0
dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsy
MDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAgOCBWZWMgODg6CihYRU4pIFsyMDE0
LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAwLCBQaW4gIDg6IHZlYz01OCBk
ZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUg
bWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJ
UlEgIDkgVmVjIDk2OgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFw
aWMgMHgwMCwgUGluICA5OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0
LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAxMCBWZWMxMDQ6CihYRU4pIFsyMDE0LTEx
LTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAwLCBQaW4gMTA6IHZlYz02OCBkZWxp
dmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFz
az0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEg
MTEgVmVjMTEyOgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMg
MHgwMCwgUGluIDExOiB2ZWM9NzAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBv
bGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEt
MTQgMjI6MDY6NTguMTU2XSAgICAgSVJRIDEyIFZlYzEyMDoKKFhFTikgWzIwMTQtMTEtMTQg
MjI6MDY6NTguMTU2XSAgICAgICBBcGljIDB4MDAsIFBpbiAxMjogdmVjPTc4IGRlbGl2ZXJ5
PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAg
ZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAxMyBW
ZWMxMzY6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAw
LCBQaW4gMTM6IHZlYz04OCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJp
dHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTQg
MjI6MDY6NTguMTU2XSAgICAgSVJRIDE0IFZlYzE0NDoKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU2XSAgICAgICBBcGljIDB4MDAsIFBpbiAxNDogdmVjPTkwIGRlbGl2ZXJ5PUxv
UHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVz
dF9pZDoxCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAxNSBWZWMx
NTI6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAwLCBQ
aW4gMTU6IHZlYz05OCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9
MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNCAyMjow
Njo1OC4xNTZdICAgICBJUlEgMTYgVmVjMTM3OgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1
OC4xNTZdICAgICAgIEFwaWMgMHgwMCwgUGluIDE2OiB2ZWM9ODkgZGVsaXZlcnk9Rml4ZWQg
ZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lk
OjEKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgSVJRIDE3IFZlYzE5MjoK
KFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgICBBcGljIDB4MDAsIFBpbiAx
NzogdmVjPWMwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGly
cj0wIHRyaWc9TCBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4
LjE1Nl0gICAgIElSUSAxOCBWZWMxODQ6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgICAgQXBpYyAweDAwLCBQaW4gMTg6IHZlYz1iOCBkZWxpdmVyeT1GaXhlZCBkZXN0
PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQoo
WEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEgMTkgVmVjIDQyOgooWEVO
KSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMgMHgwMCwgUGluIDE5OiB2
ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAg
dHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1
Nl0gICAgIElSUSAyMiBWZWMxODU6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0g
ICAgICAgQXBpYyAweDAwLCBQaW4gMjI6IHZlYz1iOSBkZWxpdmVyeT1GaXhlZCBkZXN0PUwg
c3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MgooWEVO
KSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEgMjUgVmVjMTU0OgooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMgMHgwMSwgUGluICAxOiB2ZWM9
MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJp
Zz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0g
ICAgIElSUSAyOCBWZWMgMzQ6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAg
ICAgQXBpYyAweDAxLCBQaW4gIDQ6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3Rh
dHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikg
WzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgSVJRIDI5IFZlYzIxNzoKKFhFTikgWzIw
MTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgICBBcGljIDB4MDEsIFBpbiAgNTogdmVjPTAw
IGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9
TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAg
ICBJUlEgMzIgVmVjMjAxOgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICAg
IEFwaWMgMHgwMSwgUGluICA4OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1
cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsy
MDE0LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgIElSUSAzMyBWZWMxOTM6CihYRU4pIFsyMDE0
LTExLTE0IDIyOjA2OjU4LjE1Nl0gICAgICAgQXBpYyAweDAxLCBQaW4gIDk6IHZlYz0wMCBk
ZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwg
bWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAg
SVJRIDM2IFZlYyAzMzoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgICBB
cGljIDB4MDEsIFBpbiAxMjogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9
MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAx
NC0xMS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEgMzcgVmVjIDQxOgooWEVOKSBbMjAxNC0x
MS0xNCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMgMHgwMSwgUGluIDEzOiB2ZWM9MjkgZGVs
aXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1h
c2s9MCBkZXN0X2lkOjIKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgSVJR
IDM4IFZlYzE2OToKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgICBBcGlj
IDB4MDEsIFBpbiAxNDogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBw
b2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0x
MS0xNCAyMjowNjo1OC4xNTZdICAgICBJUlEgNDAgVmVjIDQ5OgooWEVOKSBbMjAxNC0xMS0x
NCAyMjowNjo1OC4xNTZdICAgICAgIEFwaWMgMHgwMSwgUGluIDE2OiB2ZWM9MzEgZGVsaXZl
cnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9
MCBkZXN0X2lkOjgKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU2XSAgICAgSVJRIDQ2
IFZlYzExNDoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU3XSAgICAgICBBcGljIDB4
MDEsIFBpbiAyMjogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xh
cml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0x
NCAyMjowNjo1OC4xNTddICAgICBJUlEgNDcgVmVjMjA5OgooWEVOKSBbMjAxNC0xMS0xNCAy
MjowNjo1OC4xNTddICAgICAgIEFwaWMgMHgwMSwgUGluIDIzOiB2ZWM9ZDEgZGVsaXZlcnk9
Rml4ZWQgZGVzdD1MIHN0YXR1cz0xIHBvbGFyaXR5PTEgaXJyPTEgdHJpZz1MIG1hc2s9MCBk
ZXN0X2lkOjIKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU3XSAgICAgSVJRIDQ4IFZl
YzIwODoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6NTguMTU3XSAgICAgICBBcGljIDB4MDEs
IFBpbiAyNDogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0
eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xNCAy
MjowNjo1OC4xNTddICAgICBJUlEgNTEgVmVjMTM4OgooWEVOKSBbMjAxNC0xMS0xNCAyMjow
Njo1OC4xNTddICAgICAgIEFwaWMgMHgwMSwgUGluIDI3OiB2ZWM9MDAgZGVsaXZlcnk9Rml4
ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0
X2lkOjYzCihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1N10gICAgIElSUSA1MiBWZWMg
NTc6CihYRU4pIFsyMDE0LTExLTE0IDIyOjA2OjU4LjE1N10gICAgICAgQXBpYyAweDAxLCBQ
aW4gMjg6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9
MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDY6NTguMTU3XSAgICAgSVJRIDUzIFZlYzIwMDoKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDY6
NTguMTU3XSAgICAgICBBcGljIDB4MDEsIFBpbiAyOTogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVk
IGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9p
ZDo2MwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4xODldICAgICBJUlEgNTQgVmVjMjE2
OgooWEVOKSBbMjAxNC0xMS0xNCAyMjowNjo1OC4yMDJdICAgICAgIEFwaWMgMHgwMSwgUGlu
IDMwOiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEg
aXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE0IDIyOjA3
OjAwLjg3OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSBNU0kg
aW5mb3JtYXRpb246CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAg
NTYgdmVjPTI4IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAw
MDAxIG1hc2s9MC8wLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgSFBFVCAg
ICA1NyB2ZWM9YTAgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAw
MDAwMDggbWFzaz0xLzAvPwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBIUEVU
ICAgIDU4IHZlYz1hOCBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0w
MDAwMDAwOCBtYXNrPTEvMC8/CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIEhQ
RVQgICAgNTkgdmVjPWIwIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0
PTAwMDAwMDA0IG1hc2s9MS8wLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAg
TVNJICAgICA2MCB2ZWM9NDEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRl
c3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJd
ICBNU0kgICAgIDYxIHZlYz00OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3Qg
ZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcx
Ml0gIE1TSSAgICAgNjIgdmVjPTUxIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2Vz
dCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMu
NzEyXSAgTVNJICAgICA2MyB2ZWM9NTkgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93
ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzow
My43MTJdICBNU0kgICAgIDY0IHZlYz02MSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBs
b3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3
OjAzLjcxMl0gIE1TSSAgICAgNjUgdmVjPTY5IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9n
IGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDc6MDMuNzEyXSAgTVNJICAgICA2NiB2ZWM9NzEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBs
b2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNCAy
MjowNzowMy43MTJdICBNU0kgICAgIDY3IHZlYz03OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQg
IGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE0
IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAgNjggdmVjPTgxIGxvd2VzdCAgZWRnZSAgIGFzc2Vy
dCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEt
MTQgMjI6MDc6MDMuNzEyXSAgTVNJICAgICA2OSB2ZWM9OTEgbG93ZXN0ICBlZGdlICAgYXNz
ZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0x
MS0xNCAyMjowNzowMy43MTJdICBNU0kgICAgIDcwIHZlYz05OSBsb3dlc3QgIGVkZ2UgICBh
c3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTEvMS8xCihYRU4pIFsyMDE0
LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAgNzEgdmVjPWExIGxvd2VzdCAgZWRnZSAg
IGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MS8xLzEKKFhFTikgWzIw
MTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgTVNJICAgICA3MiB2ZWM9YjEgbG93ZXN0ICBlZGdl
ICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0xLzEvMQooWEVOKSBb
MjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBNU0kgICAgIDczIHZlYz0zMiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8/CihYRU4p
IFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAgNzQgdmVjPTNhIGxvd2VzdCAg
ZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8KKFhF
TikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgTVNJICAgICA3NSB2ZWM9NDIgbG93ZXN0
ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFzaz0wLzEvPwoo
WEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBNU0kgICAgIDc2IHZlYz00YSBsb3dl
c3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8/
CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAgNzcgdmVjPTUyIGxv
d2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8x
Lz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgTVNJICAgICA3OCB2ZWM9NWEg
bG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFzaz0w
LzEvPwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBNU0kgICAgIDc5IHZlYz02
MiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNr
PTAvMS8/CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAgODAgdmVj
PTZhIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1h
c2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgTVNJICAgICA4MSB2
ZWM9N2EgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEg
bWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBNU0kgICAgIDgy
IHZlYz05MiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAw
MSBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1TSSAgICAg
ODMgdmVjPWEyIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAw
MDAxIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAgTVNJLVgg
ICA4NCB2ZWM9YWEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAw
MDAwMDggbWFzaz0xLzAvMAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJdICBNU0kt
WCAgIDg1IHZlYz1iMiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0w
MDAwMDAwOCBtYXNrPTEvMC8wCihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcxMl0gIE1T
SS1YICAgODYgdmVjPWJhIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0
PTAwMDAwMDA4IG1hc2s9MS8wLzAKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMuNzEyXSAg
TVNJLVggICA4NyB2ZWM9YzIgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRl
c3Q9MDAwMDAwMDggbWFzaz0xLzAvMAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzowMy43MTJd
ICBNU0ktWCAgIDg4IHZlYz1jYSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3Qg
ZGVzdD0wMDAwMDAwOCBtYXNrPTEvMC8wCihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjAzLjcx
Ml0gIE1TSS1YICAgODkgdmVjPWQyIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2Vz
dCBkZXN0PTAwMDAwMDIwIG1hc2s9MS8wLzAKKFhFTikgWzIwMTQtMTEtMTQgMjI6MDc6MDMu
NzEyXSAgTVNJLVggICA5MCB2ZWM9ZGEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93
ZXN0IGRlc3Q9MDAwMDAwMTAgbWFzaz0xLzAvMAooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzow
My43MTJdICBNU0ktWCAgIDkxIHZlYz0yMyBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBs
b3dlc3QgZGVzdD0wMDAwMDAxMCBtYXNrPTEvMC8wCihYRU4pIFsyMDE0LTExLTE0IDIyOjA3
OjAzLjcxMl0gIE1TSS1YICAgOTIgdmVjPTJiIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9n
IGxvd2VzdCBkZXN0PTAwMDAwMDEwIG1hc2s9MS8wLzAKKFhFTikgWzIwMTQtMTEtMTQgMjI6
MDc6MTAuODc5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNCAyMjowNzoyMC44NzldIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE0IDIyOjA3OjMwLjg3OV0gLS1NQVJLLS0K
------------0FA1682463FBE0669
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0FA1682463FBE0669--



From xen-devel-bounces@lists.xen.org Fri Nov 14 22:12:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 22:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpP6R-0007GC-JN; Fri, 14 Nov 2014 22:12:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpP6R-0007G6-3z
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 22:12:27 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	CD/76-29352-A4E76645; Fri, 14 Nov 2014 22:12:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416003143!11500806!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27423 invoked from network); 14 Nov 2014 22:12:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 22:12:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEMCMNJ010095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 22:12:22 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEMCLGq016883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 22:12:21 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEMCLAw016866; Fri, 14 Nov 2014 22:12:21 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 14:12:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CBEDA116989; Fri, 14 Nov 2014 17:12:19 -0500 (EST)
Date: Fri, 14 Nov 2014 17:12:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zir Blazer <zir_blazer@hotmail.com>
Message-ID: <20141114221219.GA7007@laptop.dumpdata.com>
References: <SNT151-W350FF3218816B4188CCE62F3A40@phx.gbl>
	<SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>
	<20141114210814.GA4173@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141114210814.GA4173@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs
 4.3.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 04:08:14PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 06, 2014 at 03:55:36AM -0300, Zir Blazer wrote:
> > There is a regression in both PCI and VGA Passthrough in Xen 4.4.1 when compared to 4.3.2. Due to the added complexity of VGA Passthrough, I was suggested to focus instead in my PCI Passthrough issue, which involves the integrated Sound Card of my Motherboard. While it passes to the DomU and works, it produces robotic, distorted and lagged noise everytime it reproduces sound. The Video Card is an absolute no-go. On the previous Xen version, everything else being equal, both works properly.I have been trying to gather as much information as possible of my issue according to Xen Wiki articles http://wiki.xen.org/wiki/Debugging_Xen and http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen so this E-Mail comes attached with tons of logs.
> > 
> > 
> > HARDWARE
> > Processor: Intel Xeon E3-1245V3 (Haswell) - http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
> > Motherboard: Supermicro X10SAT (Chipset C226, BIOS R2.0) - http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm
> > Sound Card: Integrated Realtek ALC1150
> 
> So I tried this on my box which has similar specs:
> 
> Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
> 
> [    0.000000] DMI: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014
> 
> with todays' xen-unstable and with a simple guest config:
> 
> builder='hvm'
> memory = 2048
> name = "WinXP"
> vcpus=1
> vif = [ 'type=ioemu, mac=00:0F:4B:00:00:61,bridge=switch' ]
> disk=[ 'phy:/dev/G/WinXP,hda,w']
> vnc=1
> videoram=8
> vnclisten="0.0.0.0"
> vncpasswd=''
> stdvga=0
> usb=1
> usbdevice='tablet'
> qemu_model_version="traditional"
> device_model_version = 'qemu-xen-traditional'
> pci=["01:00.0","01:00.1","00:1b.0"]
> 
> # lspci -s 01:00.*
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
> 01:00.1 Audio device: ATI Technologies Inc HD48x0 audio
> 
> # lspci -s 00:1b.0
> 00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 04)
> 
> This is using Windows XP 32 (don't have 64bit laying around) and when
> using the Realtek HD Sound Effects and the '3D Audio Demo' it plays
> nicely on my speakers.

Aha! But if I use Xen 4.4 from Fedora 20 I get an horrible sound.

The plot thickens! The other interesting thing is that my unstable build
is with 'debug=y' while the Xen 4.4 from Fedora is not.

> 
> The VGA is a different story as it seems there are no Video drivers
> for XP for it available at all!
> 
> # 
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 22:12:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 22:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpP6R-0007GC-JN; Fri, 14 Nov 2014 22:12:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpP6R-0007G6-3z
	for xen-devel@lists.xen.org; Fri, 14 Nov 2014 22:12:27 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	CD/76-29352-A4E76645; Fri, 14 Nov 2014 22:12:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416003143!11500806!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27423 invoked from network); 14 Nov 2014 22:12:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Nov 2014 22:12:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAEMCMNJ010095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Nov 2014 22:12:22 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEMCLGq016883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 14 Nov 2014 22:12:21 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAEMCLAw016866; Fri, 14 Nov 2014 22:12:21 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Nov 2014 14:12:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CBEDA116989; Fri, 14 Nov 2014 17:12:19 -0500 (EST)
Date: Fri, 14 Nov 2014 17:12:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zir Blazer <zir_blazer@hotmail.com>
Message-ID: <20141114221219.GA7007@laptop.dumpdata.com>
References: <SNT151-W350FF3218816B4188CCE62F3A40@phx.gbl>
	<SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>
	<20141114210814.GA4173@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141114210814.GA4173@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs
 4.3.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 04:08:14PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 06, 2014 at 03:55:36AM -0300, Zir Blazer wrote:
> > There is a regression in both PCI and VGA Passthrough in Xen 4.4.1 when compared to 4.3.2. Due to the added complexity of VGA Passthrough, I was suggested to focus instead in my PCI Passthrough issue, which involves the integrated Sound Card of my Motherboard. While it passes to the DomU and works, it produces robotic, distorted and lagged noise everytime it reproduces sound. The Video Card is an absolute no-go. On the previous Xen version, everything else being equal, both works properly.I have been trying to gather as much information as possible of my issue according to Xen Wiki articles http://wiki.xen.org/wiki/Debugging_Xen and http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen so this E-Mail comes attached with tons of logs.
> > 
> > 
> > HARDWARE
> > Processor: Intel Xeon E3-1245V3 (Haswell) - http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
> > Motherboard: Supermicro X10SAT (Chipset C226, BIOS R2.0) - http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm
> > Sound Card: Integrated Realtek ALC1150
> 
> So I tried this on my box which has similar specs:
> 
> Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
> 
> [    0.000000] DMI: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014
> 
> with todays' xen-unstable and with a simple guest config:
> 
> builder='hvm'
> memory = 2048
> name = "WinXP"
> vcpus=1
> vif = [ 'type=ioemu, mac=00:0F:4B:00:00:61,bridge=switch' ]
> disk=[ 'phy:/dev/G/WinXP,hda,w']
> vnc=1
> videoram=8
> vnclisten="0.0.0.0"
> vncpasswd=''
> stdvga=0
> usb=1
> usbdevice='tablet'
> qemu_model_version="traditional"
> device_model_version = 'qemu-xen-traditional'
> pci=["01:00.0","01:00.1","00:1b.0"]
> 
> # lspci -s 01:00.*
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
> 01:00.1 Audio device: ATI Technologies Inc HD48x0 audio
> 
> # lspci -s 00:1b.0
> 00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 04)
> 
> This is using Windows XP 32 (don't have 64bit laying around) and when
> using the Realtek HD Sound Effects and the '3D Audio Demo' it plays
> nicely on my speakers.

Aha! But if I use Xen 4.4 from Fedora 20 I get an horrible sound.

The plot thickens! The other interesting thing is that my unstable build
is with 'debug=y' while the Xen 4.4 from Fedora is not.

> 
> The VGA is a different story as it seems there are no Video drivers
> for XP for it available at all!
> 
> # 
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 23:18:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 23: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 1XpQ7h-0008MU-Nw; Fri, 14 Nov 2014 23:17:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XpQ7g-0008MP-Ph
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 23:17:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5E/8D-24532-B9D86645; Fri, 14 Nov 2014 23:17:47 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416007066!9461719!1
X-Originating-IP: [209.85.220.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25772 invoked from network); 14 Nov 2014 23:17:47 -0000
Received: from mail-vc0-f170.google.com (HELO mail-vc0-f170.google.com)
	(209.85.220.170)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 23:17:47 -0000
Received: by mail-vc0-f170.google.com with SMTP id hq12so6159255vcb.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 15:17:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=FDOAH6Wy9fVrFEh0GuEThCd6E+OUSnSgy90d7W91fao=;
	b=jAqhQANRPPykPrsgAKadmE58EDMwg4GoSfIhTLWfdOIGUCUkGAZpxGaYDJ4JqzQ7w9
	OKKsKj6VgWk2DQbVbATvnoDR/1LIf4cF0fyPLcUw7f9JjdFGdxGYh9Sq1VlViLKk2SHm
	jXCAsBr+KFNq2GZqSTlvYsRcARm5UFf3xD4c+RoL6klWg7MNB5hjzPjvkBoomIZrxTR2
	fakhPIvK4A8d9Kj+RmfoowQ8pPRGYscHsB52zS896RzXaRzqBOixbcZfUMaOjNIpXUf4
	5Q4tr/V7hIvxycUhJaKsgVsdiPuzi2Co8rvG8OtGR5OnW4ADeBkocLdKOZ4m4uGo4Dhc
	dowA==
X-Gm-Message-State: ALoCoQmuQFs4dxAcu7hE8W+gdPMdgLd6ZfjaRA6QST/emqJ8tW0gJaYv/s1kKQQ8h5NZ/dDCLssl
MIME-Version: 1.0
X-Received: by 10.220.111.6 with SMTP id q6mr8989331vcp.12.1416007065961; Fri,
	14 Nov 2014 15:17:45 -0800 (PST)
Received: by 10.220.68.20 with HTTP; Fri, 14 Nov 2014 15:17:45 -0800 (PST)
In-Reply-To: <5466059A0200007800047A4B@mail.emea.novell.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
Date: Fri, 14 Nov 2014 18:17:45 -0500
Message-ID: <CAFECyb_YSnzdp3kf2nHJDygQMT_0-Gk6TWDLT9910WjzRAxcLQ@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
	call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 7:37 AM, Jan Beulich <JBeulich@suse.com> wrote:
> The specification is kind of vague under what conditions
> ExitBootServices() may legitimately fail, requiring the OS loader to
> retry:
>
> "If MapKey value is incorrect, ExitBootServices() returns
>  EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
>  be called again. Firmware implementation may choose to do a partial
>  shutdown of the boot services during the first call to
>  ExitBootServices(). EFI OS loader should not make calls to any boot
>  service function other then GetMemoryMap() after the first call to
>  ExitBootServices()."
>
> While our code guarantees the map key to be valid, there are systems
> where a firmware internal notification sent while processing
> ExitBootServices() reportedly results in changes to the memory map.
> In that case, make a best effort second try: Avoid any boot service
> calls other than the two named above, with the possible exception of
> error paths. Those aren't a problem, since if we end up needing to
> retry, we're hosed when something goes wrong as much as if we didn't
> make the retry attempt.
>
> For x86, a minimal adjustment to efi_arch_process_memory_map() is
> needed for it to cope with potentially being called a second time.
>
> For arm64, while efi_process_memory_map_bootinfo() is easy to verify
> that it can safely be called more than once without violating spec
> constraints, it's not so obvious for fdt_add_uefi_nodes(), hence a
> step by step approach:
> - deletion of memory nodes and memory reserve map entries: the 2nd pass
>   shouldn't find any as the 1st one deleted them all,
> - a "chosen" node should be found as it got added in the 1st pass,
> - the various "linux,uefi-*" nodes all got added during the 1st pass
>   and hence only their contents may get updated.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Roy Franz <roy.franz@linaro.org>

I built and tested this, however since my firmware is not triggering the retry
the interesting case is not happening.  I agree with your analysis that
repeatedly calling  fdt_add_uefi_nodes() multiple times should be fine.

Roy

>
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -140,7 +140,7 @@ static void __init efi_arch_process_memo
>
>      /* Populate E820 table and check trampoline area availability. */
>      e = e820map - 1;
> -    for ( i = 0; i < map_size; i += desc_size )
> +    for ( e820nr = i = 0; i < map_size; i += desc_size )
>      {
>          EFI_MEMORY_DESCRIPTOR *desc = map + i;
>          u64 len = desc->NumberOfPages << EFI_PAGE_SHIFT;
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -703,7 +703,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>      EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
>      EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
>      union string section = { NULL }, name;
> -    bool_t base_video = 0;
> +    bool_t base_video = 0, retry;
>      char *option_str;
>      bool_t use_cfg_file;
>
> @@ -1051,17 +1051,23 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>      if ( !efi_memmap )
>          blexit(L"Unable to allocate memory for EFI memory map");
>
> -    status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
> -                                  &efi_mdesc_size, &mdesc_ver);
> -    if ( EFI_ERROR(status) )
> -        PrintErrMesg(L"Cannot obtain memory map", status);
> +    for ( retry = 0; ; retry = 1 )
> +    {
> +        status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
> +                                      &efi_mdesc_size, &mdesc_ver);
> +        if ( EFI_ERROR(status) )
> +            PrintErrMesg(L"Cannot obtain memory map", status);
>
> -    efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
> -                                efi_mdesc_size, mdesc_ver);
> +        efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
> +                                    efi_mdesc_size, mdesc_ver);
>
> -    efi_arch_pre_exit_boot();
> +        efi_arch_pre_exit_boot();
> +
> +        status = efi_bs->ExitBootServices(ImageHandle, map_key);
> +        if ( status != EFI_INVALID_PARAMETER || retry )
> +            break;
> +    }
>
> -    status = efi_bs->ExitBootServices(ImageHandle, map_key);
>      if ( EFI_ERROR(status) )
>          PrintErrMesg(L"Cannot exit boot services", status);
>
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 14 23:18:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Nov 2014 23: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 1XpQ7h-0008MU-Nw; Fri, 14 Nov 2014 23:17:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roy.franz@linaro.org>) id 1XpQ7g-0008MP-Ph
	for xen-devel@lists.xenproject.org; Fri, 14 Nov 2014 23:17:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5E/8D-24532-B9D86645; Fri, 14 Nov 2014 23:17:47 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416007066!9461719!1
X-Originating-IP: [209.85.220.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25772 invoked from network); 14 Nov 2014 23:17:47 -0000
Received: from mail-vc0-f170.google.com (HELO mail-vc0-f170.google.com)
	(209.85.220.170)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Nov 2014 23:17:47 -0000
Received: by mail-vc0-f170.google.com with SMTP id hq12so6159255vcb.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 14 Nov 2014 15:17:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=FDOAH6Wy9fVrFEh0GuEThCd6E+OUSnSgy90d7W91fao=;
	b=jAqhQANRPPykPrsgAKadmE58EDMwg4GoSfIhTLWfdOIGUCUkGAZpxGaYDJ4JqzQ7w9
	OKKsKj6VgWk2DQbVbATvnoDR/1LIf4cF0fyPLcUw7f9JjdFGdxGYh9Sq1VlViLKk2SHm
	jXCAsBr+KFNq2GZqSTlvYsRcARm5UFf3xD4c+RoL6klWg7MNB5hjzPjvkBoomIZrxTR2
	fakhPIvK4A8d9Kj+RmfoowQ8pPRGYscHsB52zS896RzXaRzqBOixbcZfUMaOjNIpXUf4
	5Q4tr/V7hIvxycUhJaKsgVsdiPuzi2Co8rvG8OtGR5OnW4ADeBkocLdKOZ4m4uGo4Dhc
	dowA==
X-Gm-Message-State: ALoCoQmuQFs4dxAcu7hE8W+gdPMdgLd6ZfjaRA6QST/emqJ8tW0gJaYv/s1kKQQ8h5NZ/dDCLssl
MIME-Version: 1.0
X-Received: by 10.220.111.6 with SMTP id q6mr8989331vcp.12.1416007065961; Fri,
	14 Nov 2014 15:17:45 -0800 (PST)
Received: by 10.220.68.20 with HTTP; Fri, 14 Nov 2014 15:17:45 -0800 (PST)
In-Reply-To: <5466059A0200007800047A4B@mail.emea.novell.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
Date: Fri, 14 Nov 2014 18:17:45 -0500
Message-ID: <CAFECyb_YSnzdp3kf2nHJDygQMT_0-Gk6TWDLT9910WjzRAxcLQ@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
	call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 7:37 AM, Jan Beulich <JBeulich@suse.com> wrote:
> The specification is kind of vague under what conditions
> ExitBootServices() may legitimately fail, requiring the OS loader to
> retry:
>
> "If MapKey value is incorrect, ExitBootServices() returns
>  EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
>  be called again. Firmware implementation may choose to do a partial
>  shutdown of the boot services during the first call to
>  ExitBootServices(). EFI OS loader should not make calls to any boot
>  service function other then GetMemoryMap() after the first call to
>  ExitBootServices()."
>
> While our code guarantees the map key to be valid, there are systems
> where a firmware internal notification sent while processing
> ExitBootServices() reportedly results in changes to the memory map.
> In that case, make a best effort second try: Avoid any boot service
> calls other than the two named above, with the possible exception of
> error paths. Those aren't a problem, since if we end up needing to
> retry, we're hosed when something goes wrong as much as if we didn't
> make the retry attempt.
>
> For x86, a minimal adjustment to efi_arch_process_memory_map() is
> needed for it to cope with potentially being called a second time.
>
> For arm64, while efi_process_memory_map_bootinfo() is easy to verify
> that it can safely be called more than once without violating spec
> constraints, it's not so obvious for fdt_add_uefi_nodes(), hence a
> step by step approach:
> - deletion of memory nodes and memory reserve map entries: the 2nd pass
>   shouldn't find any as the 1st one deleted them all,
> - a "chosen" node should be found as it got added in the 1st pass,
> - the various "linux,uefi-*" nodes all got added during the 1st pass
>   and hence only their contents may get updated.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Roy Franz <roy.franz@linaro.org>

I built and tested this, however since my firmware is not triggering the retry
the interesting case is not happening.  I agree with your analysis that
repeatedly calling  fdt_add_uefi_nodes() multiple times should be fine.

Roy

>
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -140,7 +140,7 @@ static void __init efi_arch_process_memo
>
>      /* Populate E820 table and check trampoline area availability. */
>      e = e820map - 1;
> -    for ( i = 0; i < map_size; i += desc_size )
> +    for ( e820nr = i = 0; i < map_size; i += desc_size )
>      {
>          EFI_MEMORY_DESCRIPTOR *desc = map + i;
>          u64 len = desc->NumberOfPages << EFI_PAGE_SHIFT;
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -703,7 +703,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>      EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
>      EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
>      union string section = { NULL }, name;
> -    bool_t base_video = 0;
> +    bool_t base_video = 0, retry;
>      char *option_str;
>      bool_t use_cfg_file;
>
> @@ -1051,17 +1051,23 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>      if ( !efi_memmap )
>          blexit(L"Unable to allocate memory for EFI memory map");
>
> -    status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
> -                                  &efi_mdesc_size, &mdesc_ver);
> -    if ( EFI_ERROR(status) )
> -        PrintErrMesg(L"Cannot obtain memory map", status);
> +    for ( retry = 0; ; retry = 1 )
> +    {
> +        status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
> +                                      &efi_mdesc_size, &mdesc_ver);
> +        if ( EFI_ERROR(status) )
> +            PrintErrMesg(L"Cannot obtain memory map", status);
>
> -    efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
> -                                efi_mdesc_size, mdesc_ver);
> +        efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
> +                                    efi_mdesc_size, mdesc_ver);
>
> -    efi_arch_pre_exit_boot();
> +        efi_arch_pre_exit_boot();
> +
> +        status = efi_bs->ExitBootServices(ImageHandle, map_key);
> +        if ( status != EFI_INVALID_PARAMETER || retry )
> +            break;
> +    }
>
> -    status = efi_bs->ExitBootServices(ImageHandle, map_key);
>      if ( EFI_ERROR(status) )
>          PrintErrMesg(L"Cannot exit boot services", status);
>
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 03:04:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 03:04:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpTeS-0007nZ-S7; Sat, 15 Nov 2014 03:03:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpTeQ-0007nU-IS
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 03:03:50 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	AC/A3-02576-592C6645; Sat, 15 Nov 2014 03:03:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416020627!12722341!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15343 invoked from network); 15 Nov 2014 03:03:48 -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;
	15 Nov 2014 03:03:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,389,1413244800"; d="scan'208";a="193088112"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 22:03:46 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpTeI-0005CG-OZ;
	Sat, 15 Nov 2014 03:03:42 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpTeI-0008HL-FJ;
	Sat, 15 Nov 2014 03:03:42 +0000
Date: Sat, 15 Nov 2014 03:03:42 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31565-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31565: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31565 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31565/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 03:04:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 03:04:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpTeS-0007nZ-S7; Sat, 15 Nov 2014 03:03:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpTeQ-0007nU-IS
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 03:03:50 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	AC/A3-02576-592C6645; Sat, 15 Nov 2014 03:03:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416020627!12722341!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15343 invoked from network); 15 Nov 2014 03:03:48 -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;
	15 Nov 2014 03:03:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,389,1413244800"; d="scan'208";a="193088112"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 22:03:46 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpTeI-0005CG-OZ;
	Sat, 15 Nov 2014 03:03:42 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpTeI-0008HL-FJ;
	Sat, 15 Nov 2014 03:03:42 +0000
Date: Sat, 15 Nov 2014 03:03:42 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31565-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31565: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31565 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31565/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 03:50:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 03:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpUNR-0008NT-W5; Sat, 15 Nov 2014 03:50:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpUNQ-0008NO-Gf
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 03:50:20 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	E0/A3-02702-B7DC6645; Sat, 15 Nov 2014 03:50:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416023417!12738577!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32559 invoked from network); 15 Nov 2014 03:50:18 -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;
	15 Nov 2014 03:50:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,389,1413244800"; d="scan'208";a="191626663"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 22:49:46 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpUMr-0005Pz-Np;
	Sat, 15 Nov 2014 03:49:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpUMr-0004b0-A8;
	Sat, 15 Nov 2014 03:49:45 +0000
Date: Sat, 15 Nov 2014 03:49:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31525-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31525: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31525 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31525/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2             fail pass in 31500
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 31500 pass in 31525
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31500 pass in 31525
 test-i386-i386-pair           7 xen-boot/src_host  fail in 31500 pass in 31525
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31525
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot     fail in 31451 pass in 31525
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31525
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31525

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 03:50:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 03:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpUNR-0008NT-W5; Sat, 15 Nov 2014 03:50:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpUNQ-0008NO-Gf
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 03:50:20 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	E0/A3-02702-B7DC6645; Sat, 15 Nov 2014 03:50:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416023417!12738577!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32559 invoked from network); 15 Nov 2014 03:50:18 -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;
	15 Nov 2014 03:50:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,389,1413244800"; d="scan'208";a="191626663"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 14 Nov 2014 22:49:46 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpUMr-0005Pz-Np;
	Sat, 15 Nov 2014 03:49:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpUMr-0004b0-A8;
	Sat, 15 Nov 2014 03:49:45 +0000
Date: Sat, 15 Nov 2014 03:49:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31525-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31525: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31525 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31525/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2             fail pass in 31500
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 31500 pass in 31525
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31500 pass in 31525
 test-i386-i386-pair           7 xen-boot/src_host  fail in 31500 pass in 31525
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31525
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot     fail in 31451 pass in 31525
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31525
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31525

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 07:26:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 07: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.xen.org>)
	id 1XpXk5-000344-Kl; Sat, 15 Nov 2014 07:25:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpXk4-00033z-6b
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 07:25:56 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	DA/8E-02696-20007645; Sat, 15 Nov 2014 07:25:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416036352!12738474!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15047 invoked from network); 15 Nov 2014 07:25:53 -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;
	15 Nov 2014 07:25:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,390,1413244800"; d="scan'208";a="193120058"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 02:25:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpXjx-0006V4-Pl;
	Sat, 15 Nov 2014 07:25:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpXjx-0005BM-IE;
	Sat, 15 Nov 2014 07:25:49 +0000
Date: Sat, 15 Nov 2014 07:25:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31566-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31566: 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 31566 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31566/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              ae3e29e6e7a9a208732f22721e735d238b2aa8cb
baseline version:
 libvirt              8d659b177ff44be37bdb36648eaabbaec457c941

------------------------------------------------------------
People who touched revisions under test:
  Conrad Meyer <cse.cem@gmail.com>
  Daniel P. Berrange <berrange@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Jiri Denemark <jdenemar@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Pavel Hrdina <phrdina@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=ae3e29e6e7a9a208732f22721e735d238b2aa8cb
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt ae3e29e6e7a9a208732f22721e735d238b2aa8cb
+ branch=libvirt
+ revision=ae3e29e6e7a9a208732f22721e735d238b2aa8cb
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git ae3e29e6e7a9a208732f22721e735d238b2aa8cb:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   8d659b1..ae3e29e6 ae3e29e6e7a9a208732f22721e735d238b2aa8cb -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 07:26:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 07: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.xen.org>)
	id 1XpXk5-000344-Kl; Sat, 15 Nov 2014 07:25:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpXk4-00033z-6b
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 07:25:56 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	DA/8E-02696-20007645; Sat, 15 Nov 2014 07:25:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416036352!12738474!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15047 invoked from network); 15 Nov 2014 07:25:53 -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;
	15 Nov 2014 07:25:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,390,1413244800"; d="scan'208";a="193120058"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 02:25:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpXjx-0006V4-Pl;
	Sat, 15 Nov 2014 07:25:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpXjx-0005BM-IE;
	Sat, 15 Nov 2014 07:25:49 +0000
Date: Sat, 15 Nov 2014 07:25:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31566-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31566: 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 31566 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31566/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              ae3e29e6e7a9a208732f22721e735d238b2aa8cb
baseline version:
 libvirt              8d659b177ff44be37bdb36648eaabbaec457c941

------------------------------------------------------------
People who touched revisions under test:
  Conrad Meyer <cse.cem@gmail.com>
  Daniel P. Berrange <berrange@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Jiri Denemark <jdenemar@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Pavel Hrdina <phrdina@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=ae3e29e6e7a9a208732f22721e735d238b2aa8cb
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt ae3e29e6e7a9a208732f22721e735d238b2aa8cb
+ branch=libvirt
+ revision=ae3e29e6e7a9a208732f22721e735d238b2aa8cb
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git ae3e29e6e7a9a208732f22721e735d238b2aa8cb:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   8d659b1..ae3e29e6 ae3e29e6e7a9a208732f22721e735d238b2aa8cb -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 08:24:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 08:24:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpYeW-0004JY-LU; Sat, 15 Nov 2014 08:24:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpYeU-0004JT-TE
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 08:24:15 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	94/92-02957-EAD07645; Sat, 15 Nov 2014 08:24:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416039852!12733000!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28092 invoked from network); 15 Nov 2014 08:24:13 -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 Nov 2014 08:24:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,390,1413244800"; d="scan'208";a="193126552"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 03:24:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpYeQ-0006mR-FA;
	Sat, 15 Nov 2014 08:24:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpYeP-0008Lo-Tg;
	Sat, 15 Nov 2014 08:24:09 +0000
Date: Sat, 15 Nov 2014 08:24:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31527-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31527: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31527 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31527/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755
 build-i386-rumpuserxen        3 host-install(3)         broken REGR. vs. 30755
 build-i386                    5 xen-build        fail in 31504 REGR. vs. 30755

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)     broken pass in 31479
 test-amd64-i386-xl            3 host-install(3)           broken pass in 31479
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 31479
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 31504

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31479 never pass
 test-amd64-i386-libvirt       1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)      blocked in 31504 n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)            blocked in 31504 n/a
 build-i386-libvirt            1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)      blocked in 31504 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)    blocked in 31504 n/a
 test-amd64-i386-xl            1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-xl-credit2    1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)          blocked in 31504 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)    blocked in 31504 n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)       blocked in 31504 n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)         blocked in 31504 n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)           blocked in 31504 n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)          blocked in 31504 n/a
 build-i386-rumpuserxen        1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 31504 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)     blocked in 31504 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)     blocked in 31504 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 31504 n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)      blocked in 31504 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked in 31504 n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked in 31504 n/a
 test-amd64-i386-pair          1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)       blocked in 31504 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)     blocked in 31504 n/a

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       broken  
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-qemut-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step build-i386-rumpuserxen host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)

Not pushing.

(No revision log; it would be 2795 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 Nov 15 08:24:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 08:24:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpYeW-0004JY-LU; Sat, 15 Nov 2014 08:24:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpYeU-0004JT-TE
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 08:24:15 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	94/92-02957-EAD07645; Sat, 15 Nov 2014 08:24:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416039852!12733000!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28092 invoked from network); 15 Nov 2014 08:24:13 -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 Nov 2014 08:24:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,390,1413244800"; d="scan'208";a="193126552"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 03:24:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpYeQ-0006mR-FA;
	Sat, 15 Nov 2014 08:24:10 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpYeP-0008Lo-Tg;
	Sat, 15 Nov 2014 08:24:09 +0000
Date: Sat, 15 Nov 2014 08:24:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31527-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31527: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31527 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31527/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30755
 build-i386-rumpuserxen        3 host-install(3)         broken REGR. vs. 30755
 build-i386                    5 xen-build        fail in 31504 REGR. vs. 30755

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)     broken pass in 31479
 test-amd64-i386-xl            3 host-install(3)           broken pass in 31479
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 31479
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 31504

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31479 never pass
 test-amd64-i386-libvirt       1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)      blocked in 31504 n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)            blocked in 31504 n/a
 build-i386-libvirt            1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)      blocked in 31504 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)    blocked in 31504 n/a
 test-amd64-i386-xl            1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-xl-credit2    1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)          blocked in 31504 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)    blocked in 31504 n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)       blocked in 31504 n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)         blocked in 31504 n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)           blocked in 31504 n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)          blocked in 31504 n/a
 build-i386-rumpuserxen        1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 31504 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)     blocked in 31504 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)     blocked in 31504 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 31504 n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)      blocked in 31504 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked in 31504 n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked in 31504 n/a
 test-amd64-i386-pair          1 build-check(1)            blocked in 31504 n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)       blocked in 31504 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)     blocked in 31504 n/a

version targeted for testing:
 linux                cd2c5381cba9b0c40519b25841315621738688a0
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
People who touched revisions under test:
  Alexander Usyskin <alexander.usyskin@intel.com>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Allen Pais <allen.pais@oracle.com>
  Alvin (Weike) Chen <alvin.chen@intel.com>
  Anatol Pomozov <anatol.pomozov@gmail.com>
  Andreas Henriksson <andreas.henriksson@endian.se>
  Andreas Larsson <andreas@gaisler.com>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Adamson <andros@netapp.com>
  Andy Lutomirski <luto@amacapital.net>
  Andy Shevchenko <andriy.shevchenko@linux.intel.com>
  Anssi Hannula <anssi.hannula@iki.fi>
  Anthony Harivel <anthony.harivel@emtrion.de>
  Anton Blanchard <anton@samba.org>
  Arnaud Ebalard <arno@natisbad.org>
  Arnd Bergmann <arnd@arndb.de>
  Arun Easi <arun.easi@qlogic.com>
  Ben Peddell <klightspeed@killerwolves.net>
  Bing Niu <bing.niu@intel.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bob Picco <bob.picco@oracle.com>
  bob picco <bpicco@meloft.net>
  Boris Brezillon <boris.brezillon@free-electrons.com>
  Bryan O'Donoghue <bryan.odonoghue@intel.com>
  Bryan O'Donoghue <pure.logic@nexus-software.ie>
  Catalin Marinas <catalin.marinas@arm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Champion Chen <champion_chen@realsil.com.cn>
  Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
  Chao Yu <chao2.yu@samsung.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Mason <clm@fb.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@lst.de>
  Clemens Ladisch <clemens@ladisch.de>
  Dan Williams <dan.j.williams@intel.com>
  Daniel Hellstrom <daniel@gaisler.com>
  Dave Chinner <david@fromorbit.com>
  Dave Chinner <dchinner@redhat.com>
  Dave Kleikamp <dave.kleikamp@oracle.com>
  David Dueck <davidcdueck@googlemail.com>
  David Matlack <dmatlack@google.com>
  David S. Miller <davem@davemloft.net>
  David Sterba <dsterba@suse.cz>
  Davidlohr Bueso <dave@stgolabs.net>
  Dmitry Kasatkin <d.kasatkin@samsung.com>
  Douglas Lehr <dllehr@us.ibm.com>
  Dwight Engen <dwight.engen@oracle.com>
  Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
  Felipe Balbi <balbi@ti.com>
  Filipe David Borba Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@gmail.com>
  Filipe Manana <fdmanana@suse.com>
  Frans Klaver <frans.klaver@xsens.com>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Harsha Priya <harshapriya.n@intel.com>
  Heinrich Schuchardt <xypron.glpk@gmx.de>
  Ingo Molnar <mingo@kernel.org>
  Jason Cooper <jason@lakedaemon.net>
  Joe Lawrence <joe.lawrence@stratus.com>
  Johan Hedberg <johan.hedberg@intel.com>
  John Soni Jose <sony.john-n@emulex.com>
  John W. Linville <linville@tuxdriver.com>
  Josef Ahmad <josef.ahmad@intel.com>
  Josef Bacik <jbacik@fb.com>
  Junxiao Bi <junxiao.bi@oracle.com>
  K. Y. Srinivasan <kys@microsoft.com>
  Kees Cook <keescook@chromium.org>
  klightspeed@killerwolves.net <klightspeed@killerwolves.net>
  Larry Finger <Larry.Finger@lwfinger.net>
  Lee Jones <lee.jones@linaro.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Liu Bo <bo.li.liu@oracle.com>
  Loic Poulain <loic.poulain@intel.com>
  Ludovic Desroches <ludovic.desroches@atmel.com>
  Marcel Holtmann <marcel@holtmann.org>
  Mark Brown <broonie@kernel.org>
  Meelis Roos <mroos@linux.ee>
  Michael Ellerman <mpe@ellerman.id.au>
  Mike Christie <michaelc@cs.wisc.edu>
  Mike Galbraith <umgwanakikbuti@gmail.com>
  Milton Miller <miltonm@us.ibm.com>
  Mimi Zohar <zohar@linux.vnet.ibm.com>
  Nicolas Ferre <nicolas.ferre@atmel.com>
  Olga Kornievskaia <kolga@netapp.com>
  Oren Givon <oren.givon@intel.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
  Sage Weil <sage@redhat.com>
  Sasha Levin <sasha.levin@oracle.com>
  Saurav Kashyap <saurav.kashyap@qlogic.com>
  Sitsofe Wheeler <sitsofe@yahoo.com>
  Sowmini Varadhan <sowmini.varadhan@oracle.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomas Winkler <tomas.winkler@intel.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Tyler Hicks <tyhicks@canonical.com>
  Victor Kamensky <victor.kamensky@linaro.org>
  Vlad Catoi <vladcatoi@gmail.com>
  Willy Tarreau <w@1wt.eu>
  Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
  Xiubo Li <Li.Xiubo@freescale.com>
  Xuelin Shi <xuelin.shi@freescale.com>
  Yann Droneaud <ydroneaud@opteya.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       broken  
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-qemut-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step build-i386-rumpuserxen host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)

Not pushing.

(No revision log; it would be 2795 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 Nov 15 08:59:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 08: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 1XpZCS-0004mi-LB; Sat, 15 Nov 2014 08:59:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpZCR-0004md-5q
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 08:59:19 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	69/BC-22819-6E517645; Sat, 15 Nov 2014 08:59:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416041956!8656882!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9566 invoked from network); 15 Nov 2014 08:59:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 08:59:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,390,1413244800"; d="scan'208";a="191661546"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 03:59:14 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpZCM-0006ww-KU;
	Sat, 15 Nov 2014 08:59:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpZCM-0002zH-DY;
	Sat, 15 Nov 2014 08:59:14 +0000
Date: Sat, 15 Nov 2014 08:59:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31564-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31564: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31564 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31564/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                b23dc5a7cc6ebc9a0d57351da7a0e8454c9ffea3
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
497 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 19227 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 Nov 15 08:59:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 08: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 1XpZCS-0004mi-LB; Sat, 15 Nov 2014 08:59:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpZCR-0004md-5q
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 08:59:19 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	69/BC-22819-6E517645; Sat, 15 Nov 2014 08:59:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416041956!8656882!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9566 invoked from network); 15 Nov 2014 08:59:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 08:59:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,390,1413244800"; d="scan'208";a="191661546"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 03:59:14 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpZCM-0006ww-KU;
	Sat, 15 Nov 2014 08:59:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpZCM-0002zH-DY;
	Sat, 15 Nov 2014 08:59:14 +0000
Date: Sat, 15 Nov 2014 08:59:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31564-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31564: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31564 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31564/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                b23dc5a7cc6ebc9a0d57351da7a0e8454c9ffea3
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
497 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 19227 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 Nov 15 12:00:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 12:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpc1F-0007Up-FH; Sat, 15 Nov 2014 11:59:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zir_blazer@hotmail.com>) id 1Xpc1D-0007Uf-Pf
	for xen-devel@lists.xen.org; Sat, 15 Nov 2014 11:59:56 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	A8/B7-11608-A3047645; Sat, 15 Nov 2014 11:59:54 +0000
X-Env-Sender: zir_blazer@hotmail.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416052792!9151247!1
X-Originating-IP: [65.54.61.83]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	FORGED_HOTMAIL_RCVD
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10401 invoked from network); 15 Nov 2014 11:59:53 -0000
Received: from snt004-omc1s46.hotmail.com (HELO SNT004-OMC1S46.hotmail.com)
	(65.54.61.83)
	by server-14.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Nov 2014 11:59:53 -0000
Received: from SNT151-W46 ([65.55.90.7]) by SNT004-OMC1S46.hotmail.com over
	TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); 
	Sat, 15 Nov 2014 03:59:51 -0800
X-TMN: [yjgZknA3KEgRoXSsl9Mx1qtHcMal63vl07J0CoeBs54=]
X-Originating-Email: [zir_blazer@hotmail.com]
Message-ID: <SNT151-W4621893576D241F163123FF38D0@phx.gbl>
From: Zir Blazer <zir_blazer@hotmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 15 Nov 2014 08:59:51 -0300
Importance: Normal
In-Reply-To: <20141114221219.GA7007@laptop.dumpdata.com>
References: <SNT151-W350FF3218816B4188CCE62F3A40@phx.gbl>,
	<SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>,
	<20141114210814.GA4173@laptop.dumpdata.com>,
	<20141114221219.GA7007@laptop.dumpdata.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Nov 2014 11:59:51.0773 (UTC)
	FILETIME=[A99CC8D0:01D000CB]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs
 4.3.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm happy that you managed to reproduce the sound issue. It means that it will be possible to track it down and fix it.
So, if I understanded properly: It does NOT happen on your custom Xen 4.4 build, but the one that Fedora got is affected by it. Could it be that your unstable build got any recent patch that fixes it that Fedora doesn't have should it be using the stable source? Should be the same with Arch Linux.
Have your tried with the workaround of not using xen-pciback for the Sound Card and instead using xl pci-assignable-add? It should work, too.



For my Radeon 5770, I use Catalyst 12.1 Drivers. The reason is that they're the latest which includes OpenCL support out of the box in Windows XP. It got removed from later versions, and not so much later, AMD branched out old GPU into another set of Drivers. If I recall correctly, the 12.1 are still unified, so they should work for your 4xxx.
Cause AMD website has become a pain in the ass to browse if you're looking for older Driver versions archives, you can use the TechPowerUp mirror:
www.techpowerup.com/downloads/2096/amd-catalyst-12-1-software-suite-winxp-32-bit/mirrors
Download with confidence, they're the same ones that I'm using and TechPowerUp is a reputable Hardware reviewer website. Otherwise, you can download the latest legacy 14.4 from AMD website:
support.amd.com/en-us/download/desktop/legacy?product=legacy2&os=Windows%20XP%20-%20Professional/Home&RenderOnServer=true

I will stay tuned on this.


----------------------------------------
> Date: Fri, 14 Nov 2014 17:12:19 -0500
> From: konrad.wilk@oracle.com
> To: zir_blazer@hotmail.com
> CC: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs 4.3.2
>
> On Fri, Nov 14, 2014 at 04:08:14PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Mon, Oct 06, 2014 at 03:55:36AM -0300, Zir Blazer wrote:
>>> There is a regression in both PCI and VGA Passthrough in Xen 4.4.1 when compared to 4.3.2. Due to the added complexity of VGA Passthrough, I was suggested to focus instead in my PCI Passthrough issue, which involves the integrated Sound Card of my Motherboard. While it passes to the DomU and works, it produces robotic, distorted and lagged noise everytime it reproduces sound. The Video Card is an absolute no-go. On the previous Xen version, everything else being equal, both works properly.I have been trying to gather as much information as possible of my issue according to Xen Wiki articles http://wiki.xen.org/wiki/Debugging_Xen and http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen so this E-Mail comes attached with tons of logs.
>>>
>>>
>>> HARDWARE
>>> Processor: Intel Xeon E3-1245V3 (Haswell) - http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
>>> Motherboard: Supermicro X10SAT (Chipset C226, BIOS R2.0) - http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm
>>> Sound Card: Integrated Realtek ALC1150
>>
>> So I tried this on my box which has similar specs:
>>
>> Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
>>
>> [ 0.000000] DMI: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014
>>
>> with todays' xen-unstable and with a simple guest config:
>>
>> builder='hvm'
>> memory = 2048
>> name = "WinXP"
>> vcpus=1
>> vif = [ 'type=ioemu, mac=00:0F:4B:00:00:61,bridge=switch' ]
>> disk=[ 'phy:/dev/G/WinXP,hda,w']
>> vnc=1
>> videoram=8
>> vnclisten="0.0.0.0"
>> vncpasswd=''
>> stdvga=0
>> usb=1
>> usbdevice='tablet'
>> qemu_model_version="traditional"
>> device_model_version = 'qemu-xen-traditional'
>> pci=["01:00.0","01:00.1","00:1b.0"]
>>
>> # lspci -s 01:00.*
>> 01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
>> 01:00.1 Audio device: ATI Technologies Inc HD48x0 audio
>>
>> # lspci -s 00:1b.0
>> 00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 04)
>>
>> This is using Windows XP 32 (don't have 64bit laying around) and when
>> using the Realtek HD Sound Effects and the '3D Audio Demo' it plays
>> nicely on my speakers.
>
> Aha! But if I use Xen 4.4 from Fedora 20 I get an horrible sound.
>
> The plot thickens! The other interesting thing is that my unstable build
> is with 'debug=y' while the Xen 4.4 from Fedora is not.
>
>>
>> The VGA is a different story as it seems there are no Video drivers
>> for XP for it available at all!
>>
>> #
>>
>>
>>
>>
 		 	   		  
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 12:00:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 12:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpc1F-0007Up-FH; Sat, 15 Nov 2014 11:59:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zir_blazer@hotmail.com>) id 1Xpc1D-0007Uf-Pf
	for xen-devel@lists.xen.org; Sat, 15 Nov 2014 11:59:56 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	A8/B7-11608-A3047645; Sat, 15 Nov 2014 11:59:54 +0000
X-Env-Sender: zir_blazer@hotmail.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416052792!9151247!1
X-Originating-IP: [65.54.61.83]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	FORGED_HOTMAIL_RCVD
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10401 invoked from network); 15 Nov 2014 11:59:53 -0000
Received: from snt004-omc1s46.hotmail.com (HELO SNT004-OMC1S46.hotmail.com)
	(65.54.61.83)
	by server-14.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Nov 2014 11:59:53 -0000
Received: from SNT151-W46 ([65.55.90.7]) by SNT004-OMC1S46.hotmail.com over
	TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); 
	Sat, 15 Nov 2014 03:59:51 -0800
X-TMN: [yjgZknA3KEgRoXSsl9Mx1qtHcMal63vl07J0CoeBs54=]
X-Originating-Email: [zir_blazer@hotmail.com]
Message-ID: <SNT151-W4621893576D241F163123FF38D0@phx.gbl>
From: Zir Blazer <zir_blazer@hotmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 15 Nov 2014 08:59:51 -0300
Importance: Normal
In-Reply-To: <20141114221219.GA7007@laptop.dumpdata.com>
References: <SNT151-W350FF3218816B4188CCE62F3A40@phx.gbl>,
	<SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>,
	<20141114210814.GA4173@laptop.dumpdata.com>,
	<20141114221219.GA7007@laptop.dumpdata.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Nov 2014 11:59:51.0773 (UTC)
	FILETIME=[A99CC8D0:01D000CB]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs
 4.3.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm happy that you managed to reproduce the sound issue. It means that it will be possible to track it down and fix it.
So, if I understanded properly: It does NOT happen on your custom Xen 4.4 build, but the one that Fedora got is affected by it. Could it be that your unstable build got any recent patch that fixes it that Fedora doesn't have should it be using the stable source? Should be the same with Arch Linux.
Have your tried with the workaround of not using xen-pciback for the Sound Card and instead using xl pci-assignable-add? It should work, too.



For my Radeon 5770, I use Catalyst 12.1 Drivers. The reason is that they're the latest which includes OpenCL support out of the box in Windows XP. It got removed from later versions, and not so much later, AMD branched out old GPU into another set of Drivers. If I recall correctly, the 12.1 are still unified, so they should work for your 4xxx.
Cause AMD website has become a pain in the ass to browse if you're looking for older Driver versions archives, you can use the TechPowerUp mirror:
www.techpowerup.com/downloads/2096/amd-catalyst-12-1-software-suite-winxp-32-bit/mirrors
Download with confidence, they're the same ones that I'm using and TechPowerUp is a reputable Hardware reviewer website. Otherwise, you can download the latest legacy 14.4 from AMD website:
support.amd.com/en-us/download/desktop/legacy?product=legacy2&os=Windows%20XP%20-%20Professional/Home&RenderOnServer=true

I will stay tuned on this.


----------------------------------------
> Date: Fri, 14 Nov 2014 17:12:19 -0500
> From: konrad.wilk@oracle.com
> To: zir_blazer@hotmail.com
> CC: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs 4.3.2
>
> On Fri, Nov 14, 2014 at 04:08:14PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Mon, Oct 06, 2014 at 03:55:36AM -0300, Zir Blazer wrote:
>>> There is a regression in both PCI and VGA Passthrough in Xen 4.4.1 when compared to 4.3.2. Due to the added complexity of VGA Passthrough, I was suggested to focus instead in my PCI Passthrough issue, which involves the integrated Sound Card of my Motherboard. While it passes to the DomU and works, it produces robotic, distorted and lagged noise everytime it reproduces sound. The Video Card is an absolute no-go. On the previous Xen version, everything else being equal, both works properly.I have been trying to gather as much information as possible of my issue according to Xen Wiki articles http://wiki.xen.org/wiki/Debugging_Xen and http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen so this E-Mail comes attached with tons of logs.
>>>
>>>
>>> HARDWARE
>>> Processor: Intel Xeon E3-1245V3 (Haswell) - http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
>>> Motherboard: Supermicro X10SAT (Chipset C226, BIOS R2.0) - http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm
>>> Sound Card: Integrated Realtek ALC1150
>>
>> So I tried this on my box which has similar specs:
>>
>> Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
>>
>> [ 0.000000] DMI: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014
>>
>> with todays' xen-unstable and with a simple guest config:
>>
>> builder='hvm'
>> memory = 2048
>> name = "WinXP"
>> vcpus=1
>> vif = [ 'type=ioemu, mac=00:0F:4B:00:00:61,bridge=switch' ]
>> disk=[ 'phy:/dev/G/WinXP,hda,w']
>> vnc=1
>> videoram=8
>> vnclisten="0.0.0.0"
>> vncpasswd=''
>> stdvga=0
>> usb=1
>> usbdevice='tablet'
>> qemu_model_version="traditional"
>> device_model_version = 'qemu-xen-traditional'
>> pci=["01:00.0","01:00.1","00:1b.0"]
>>
>> # lspci -s 01:00.*
>> 01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
>> 01:00.1 Audio device: ATI Technologies Inc HD48x0 audio
>>
>> # lspci -s 00:1b.0
>> 00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 04)
>>
>> This is using Windows XP 32 (don't have 64bit laying around) and when
>> using the Realtek HD Sound Effects and the '3D Audio Demo' it plays
>> nicely on my speakers.
>
> Aha! But if I use Xen 4.4 from Fedora 20 I get an horrible sound.
>
> The plot thickens! The other interesting thing is that my unstable build
> is with 'debug=y' while the Xen 4.4 from Fedora is not.
>
>>
>> The VGA is a different story as it seems there are no Video drivers
>> for XP for it available at all!
>>
>> #
>>
>>
>>
>>
 		 	   		  
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 13:56:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 13:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpdp5-0000qP-2F; Sat, 15 Nov 2014 13:55: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@citrix.com>) id 1Xpdp3-0000qK-Jb
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 13:55:29 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	AD/B9-19763-05B57645; Sat, 15 Nov 2014 13:55:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416059726!6148990!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3430 invoked from network); 15 Nov 2014 13:55:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 13:55:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="191693354"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 08:55:24 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpdoy-0008NQ-Gq;
	Sat, 15 Nov 2014 13:55:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpdoy-0007J0-6B;
	Sat, 15 Nov 2014 13:55:24 +0000
Date: Sat, 15 Nov 2014 13:55:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31573-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11430
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31573: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1507359205536571906=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1507359205536571906==
Content-Type: text/plain
Content-Length: 11194
Content-Transfer-Encoding: quoted-printable

flight 31573 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31573/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                b87dcdd0746dc110fa5a3353cbc257818e618930
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12639 lines long.)


--===============1507359205536571906==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1507359205536571906==--

From xen-devel-bounces@lists.xen.org Sat Nov 15 13:56:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 13:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpdp5-0000qP-2F; Sat, 15 Nov 2014 13:55: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@citrix.com>) id 1Xpdp3-0000qK-Jb
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 13:55:29 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	AD/B9-19763-05B57645; Sat, 15 Nov 2014 13:55:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416059726!6148990!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3430 invoked from network); 15 Nov 2014 13:55:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 13:55:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="191693354"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 08:55:24 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpdoy-0008NQ-Gq;
	Sat, 15 Nov 2014 13:55:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpdoy-0007J0-6B;
	Sat, 15 Nov 2014 13:55:24 +0000
Date: Sat, 15 Nov 2014 13:55:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31573-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11430
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31573: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1507359205536571906=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1507359205536571906==
Content-Type: text/plain
Content-Length: 11194
Content-Transfer-Encoding: quoted-printable

flight 31573 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31573/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                b87dcdd0746dc110fa5a3353cbc257818e618930
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12639 lines long.)


--===============1507359205536571906==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1507359205536571906==--

From xen-devel-bounces@lists.xen.org Sat Nov 15 14:19:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 14:19:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpeBr-0001HR-AU; Sat, 15 Nov 2014 14:19:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XpeBp-0001HM-BS
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 14:19:01 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	6B/84-02576-4D067645; Sat, 15 Nov 2014 14:19:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416061138!12734212!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27708 invoked from network); 15 Nov 2014 14:18:59 -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;
	15 Nov 2014 14:18:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="193169347"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Sat, 15 Nov 2014 09:18:57 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpeBk-0005rt-Ub;
	Sat, 15 Nov 2014 14:18:56 +0000
Date: Sat, 15 Nov 2014 14:18:56 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Message-ID: <20141115141856.GA11070@zion.uk.xensource.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Acked-by: Wei Liu <wei.liu2@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 14:19:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 14:19:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpeBr-0001HR-AU; Sat, 15 Nov 2014 14:19:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XpeBp-0001HM-BS
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 14:19:01 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	6B/84-02576-4D067645; Sat, 15 Nov 2014 14:19:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416061138!12734212!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27708 invoked from network); 15 Nov 2014 14:18:59 -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;
	15 Nov 2014 14:18:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="193169347"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Sat, 15 Nov 2014 09:18:57 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XpeBk-0005rt-Ub;
	Sat, 15 Nov 2014 14:18:56 +0000
Date: Sat, 15 Nov 2014 14:18:56 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Message-ID: <20141115141856.GA11070@zion.uk.xensource.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Acked-by: Wei Liu <wei.liu2@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 14:34:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 14:34:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpeQj-0001eB-RS; Sat, 15 Nov 2014 14:34:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpeQj-0001e6-0Q
	for xen-devel@lists.xen.org; Sat, 15 Nov 2014 14:34:25 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	8B/9A-07724-07467645; Sat, 15 Nov 2014 14:34:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416062061!7172030!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26918 invoked from network); 15 Nov 2014 14:34:23 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Nov 2014 14:34:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAFEYJSl006299
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 15 Nov 2014 14:34:20 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAFEYI3I004935
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 15 Nov 2014 14:34:18 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAFEYHTG023191; Sat, 15 Nov 2014 14:34:17 GMT
Received: from [IPv6:2607:fb90:e1c:a997:30:e2bf:3bd2:accf] (/172.56.22.128)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 15 Nov 2014 06:34:17 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <SNT151-W4621893576D241F163123FF38D0@phx.gbl>
References: <SNT151-W350FF3218816B4188CCE62F3A40@phx.gbl>,
	<SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>,
	<20141114210814.GA4173@laptop.dumpdata.com>,
	<20141114221219.GA7007@laptop.dumpdata.com>
	<SNT151-W4621893576D241F163123FF38D0@phx.gbl>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 15 Nov 2014 09:34:13 -0500
To: Zir Blazer <zir_blazer@hotmail.com>
Message-ID: <18C34262-BE6A-46D1-90B6-1A2437640ADC@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs
	4.3.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 15, 2014 6:59:51 AM EST, Zir Blazer <zir_blazer@hotmail.com> wrote:
>I'm happy that you managed to reproduce the sound issue. It means that
>it will be possible to track it down and fix it.
>So, if I understanded properly: It does NOT happen on your custom Xen
>4.4 build, but the one that Fedora got is affected by it. 


I did an 'custom' build (the only custom thing is that it is stock and has debug=y) and with Xen 4.4 from that build I can hear the sound issue.

>From my testing - Xen 4.5 - good. Xen 4.4 - not good. Hadn't yet done 4.3.

Which is excellent as it removes variables.


>Could it be
>that your unstable build got any recent patch that fixes it that Fedora
>doesn't have should it be using the stable source? Should be the same
>with Arch Linux.
>Have your tried with the workaround of not using xen-pciback for the
>Sound Card and instead using xl pci-assignable-add? It should work,
>too.

The kernel I  am using as dom0 has no sound drivers so the pre-init workaround is not in effect.

Depending on the list of patches - it might be easier to bisect based on 4.5 instead of Xen 4.3 or 4.4.

Anyhow have to figure out how to make this automated to do the week long bisection.
>
>
>
>For my Radeon 5770, I use Catalyst 12.1 Drivers. The reason is that
>they're the latest which includes OpenCL support out of the box in
>Windows XP. It got removed from later versions, and not so much later,
>AMD branched out old GPU into another set of Drivers. If I recall
>correctly, the 12.1 are still unified, so they should work for your
>4xxx.
>Cause AMD website has become a pain in the ass to browse if you're
>looking for older Driver versions archives, you can use the TechPowerUp
>mirror:
>www.techpowerup.com/downloads/2096/amd-catalyst-12-1-software-suite-winxp-32-bit/mirrors
>Download with confidence, they're the same ones that I'm using and
>TechPowerUp is a reputable Hardware reviewer website. Otherwise, you
>can download the latest legacy 14.4 from AMD website:
>support.amd.com/en-us/download/desktop/legacy?product=legacy2&os=Windows%20XP%20-%20Professional/Home&RenderOnServer=true
>

Ah! Thank you for the link!

>I will stay tuned on this.
>
>
>----------------------------------------
>> Date: Fri, 14 Nov 2014 17:12:19 -0500
>> From: konrad.wilk@oracle.com
>> To: zir_blazer@hotmail.com
>> CC: xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen
>4.4.1 vs 4.3.2
>>
>> On Fri, Nov 14, 2014 at 04:08:14PM -0500, Konrad Rzeszutek Wilk
>wrote:
>>> On Mon, Oct 06, 2014 at 03:55:36AM -0300, Zir Blazer wrote:
>>>> There is a regression in both PCI and VGA Passthrough in Xen 4.4.1
>when compared to 4.3.2. Due to the added complexity of VGA Passthrough,
>I was suggested to focus instead in my PCI Passthrough issue, which
>involves the integrated Sound Card of my Motherboard. While it passes
>to the DomU and works, it produces robotic, distorted and lagged noise
>everytime it reproduces sound. The Video Card is an absolute no-go. On
>the previous Xen version, everything else being equal, both works
>properly.I have been trying to gather as much information as possible
>of my issue according to Xen Wiki articles
>http://wiki.xen.org/wiki/Debugging_Xen and
>http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen so this E-Mail
>comes attached with tons of logs.
>>>>
>>>>
>>>> HARDWARE
>>>> Processor: Intel Xeon E3-1245V3 (Haswell) -
>http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
>>>> Motherboard: Supermicro X10SAT (Chipset C226, BIOS R2.0) -
>http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm
>>>> Sound Card: Integrated Realtek ALC1150
>>>
>>> So I tried this on my box which has similar specs:
>>>
>>> Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
>>>
>>> [ 0.000000] DMI: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014
>>>
>>> with todays' xen-unstable and with a simple guest config:
>>>
>>> builder='hvm'
>>> memory = 2048
>>> name = "WinXP"
>>> vcpus=1
>>> vif = [ 'type=ioemu, mac=00:0F:4B:00:00:61,bridge=switch' ]
>>> disk=[ 'phy:/dev/G/WinXP,hda,w']
>>> vnc=1
>>> videoram=8
>>> vnclisten="0.0.0.0"
>>> vncpasswd=''
>>> stdvga=0
>>> usb=1
>>> usbdevice='tablet'
>>> qemu_model_version="traditional"
>>> device_model_version = 'qemu-xen-traditional'
>>> pci=["01:00.0","01:00.1","00:1b.0"]
>>>
>>> # lspci -s 01:00.*
>>> 01:00.0 VGA compatible controller: ATI Technologies Inc RV770
>[Radeon HD 4870]
>>> 01:00.1 Audio device: ATI Technologies Inc HD48x0 audio
>>>
>>> # lspci -s 00:1b.0
>>> 00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 04)
>>>
>>> This is using Windows XP 32 (don't have 64bit laying around) and
>when
>>> using the Realtek HD Sound Effects and the '3D Audio Demo' it plays
>>> nicely on my speakers.
>>
>> Aha! But if I use Xen 4.4 from Fedora 20 I get an horrible sound.
>>
>> The plot thickens! The other interesting thing is that my unstable
>build
>> is with 'debug=y' while the Xen 4.4 from Fedora is not.
>>
>>>
>>> The VGA is a different story as it seems there are no Video drivers
>>> for XP for it available at all!
>>>
>>> #
>>>
>>>
>>>
>>>
> 		 	   		  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 14:34:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 14:34:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpeQj-0001eB-RS; Sat, 15 Nov 2014 14:34:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XpeQj-0001e6-0Q
	for xen-devel@lists.xen.org; Sat, 15 Nov 2014 14:34:25 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	8B/9A-07724-07467645; Sat, 15 Nov 2014 14:34:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416062061!7172030!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26918 invoked from network); 15 Nov 2014 14:34:23 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Nov 2014 14:34:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAFEYJSl006299
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 15 Nov 2014 14:34:20 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAFEYI3I004935
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 15 Nov 2014 14:34:18 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAFEYHTG023191; Sat, 15 Nov 2014 14:34:17 GMT
Received: from [IPv6:2607:fb90:e1c:a997:30:e2bf:3bd2:accf] (/172.56.22.128)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 15 Nov 2014 06:34:17 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <SNT151-W4621893576D241F163123FF38D0@phx.gbl>
References: <SNT151-W350FF3218816B4188CCE62F3A40@phx.gbl>,
	<SNT151-W12F4DACB9A800BCEC6D188F3A50@phx.gbl>,
	<20141114210814.GA4173@laptop.dumpdata.com>,
	<20141114221219.GA7007@laptop.dumpdata.com>
	<SNT151-W4621893576D241F163123FF38D0@phx.gbl>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 15 Nov 2014 09:34:13 -0500
To: Zir Blazer <zir_blazer@hotmail.com>
Message-ID: <18C34262-BE6A-46D1-90B6-1A2437640ADC@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs
	4.3.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 15, 2014 6:59:51 AM EST, Zir Blazer <zir_blazer@hotmail.com> wrote:
>I'm happy that you managed to reproduce the sound issue. It means that
>it will be possible to track it down and fix it.
>So, if I understanded properly: It does NOT happen on your custom Xen
>4.4 build, but the one that Fedora got is affected by it. 


I did an 'custom' build (the only custom thing is that it is stock and has debug=y) and with Xen 4.4 from that build I can hear the sound issue.

>From my testing - Xen 4.5 - good. Xen 4.4 - not good. Hadn't yet done 4.3.

Which is excellent as it removes variables.


>Could it be
>that your unstable build got any recent patch that fixes it that Fedora
>doesn't have should it be using the stable source? Should be the same
>with Arch Linux.
>Have your tried with the workaround of not using xen-pciback for the
>Sound Card and instead using xl pci-assignable-add? It should work,
>too.

The kernel I  am using as dom0 has no sound drivers so the pre-init workaround is not in effect.

Depending on the list of patches - it might be easier to bisect based on 4.5 instead of Xen 4.3 or 4.4.

Anyhow have to figure out how to make this automated to do the week long bisection.
>
>
>
>For my Radeon 5770, I use Catalyst 12.1 Drivers. The reason is that
>they're the latest which includes OpenCL support out of the box in
>Windows XP. It got removed from later versions, and not so much later,
>AMD branched out old GPU into another set of Drivers. If I recall
>correctly, the 12.1 are still unified, so they should work for your
>4xxx.
>Cause AMD website has become a pain in the ass to browse if you're
>looking for older Driver versions archives, you can use the TechPowerUp
>mirror:
>www.techpowerup.com/downloads/2096/amd-catalyst-12-1-software-suite-winxp-32-bit/mirrors
>Download with confidence, they're the same ones that I'm using and
>TechPowerUp is a reputable Hardware reviewer website. Otherwise, you
>can download the latest legacy 14.4 from AMD website:
>support.amd.com/en-us/download/desktop/legacy?product=legacy2&os=Windows%20XP%20-%20Professional/Home&RenderOnServer=true
>

Ah! Thank you for the link!

>I will stay tuned on this.
>
>
>----------------------------------------
>> Date: Fri, 14 Nov 2014 17:12:19 -0500
>> From: konrad.wilk@oracle.com
>> To: zir_blazer@hotmail.com
>> CC: xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen
>4.4.1 vs 4.3.2
>>
>> On Fri, Nov 14, 2014 at 04:08:14PM -0500, Konrad Rzeszutek Wilk
>wrote:
>>> On Mon, Oct 06, 2014 at 03:55:36AM -0300, Zir Blazer wrote:
>>>> There is a regression in both PCI and VGA Passthrough in Xen 4.4.1
>when compared to 4.3.2. Due to the added complexity of VGA Passthrough,
>I was suggested to focus instead in my PCI Passthrough issue, which
>involves the integrated Sound Card of my Motherboard. While it passes
>to the DomU and works, it produces robotic, distorted and lagged noise
>everytime it reproduces sound. The Video Card is an absolute no-go. On
>the previous Xen version, everything else being equal, both works
>properly.I have been trying to gather as much information as possible
>of my issue according to Xen Wiki articles
>http://wiki.xen.org/wiki/Debugging_Xen and
>http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen so this E-Mail
>comes attached with tons of logs.
>>>>
>>>>
>>>> HARDWARE
>>>> Processor: Intel Xeon E3-1245V3 (Haswell) -
>http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
>>>> Motherboard: Supermicro X10SAT (Chipset C226, BIOS R2.0) -
>http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm
>>>> Sound Card: Integrated Realtek ALC1150
>>>
>>> So I tried this on my box which has similar specs:
>>>
>>> Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
>>>
>>> [ 0.000000] DMI: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014
>>>
>>> with todays' xen-unstable and with a simple guest config:
>>>
>>> builder='hvm'
>>> memory = 2048
>>> name = "WinXP"
>>> vcpus=1
>>> vif = [ 'type=ioemu, mac=00:0F:4B:00:00:61,bridge=switch' ]
>>> disk=[ 'phy:/dev/G/WinXP,hda,w']
>>> vnc=1
>>> videoram=8
>>> vnclisten="0.0.0.0"
>>> vncpasswd=''
>>> stdvga=0
>>> usb=1
>>> usbdevice='tablet'
>>> qemu_model_version="traditional"
>>> device_model_version = 'qemu-xen-traditional'
>>> pci=["01:00.0","01:00.1","00:1b.0"]
>>>
>>> # lspci -s 01:00.*
>>> 01:00.0 VGA compatible controller: ATI Technologies Inc RV770
>[Radeon HD 4870]
>>> 01:00.1 Audio device: ATI Technologies Inc HD48x0 audio
>>>
>>> # lspci -s 00:1b.0
>>> 00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 04)
>>>
>>> This is using Windows XP 32 (don't have 64bit laying around) and
>when
>>> using the Realtek HD Sound Effects and the '3D Audio Demo' it plays
>>> nicely on my speakers.
>>
>> Aha! But if I use Xen 4.4 from Fedora 20 I get an horrible sound.
>>
>> The plot thickens! The other interesting thing is that my unstable
>build
>> is with 'debug=y' while the Xen 4.4 from Fedora is not.
>>
>>>
>>> The VGA is a different story as it seems there are no Video drivers
>>> for XP for it available at all!
>>>
>>> #
>>>
>>>
>>>
>>>
> 		 	   		  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 14:56:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 14:56:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpelO-00021b-R8; Sat, 15 Nov 2014 14:55:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpelN-00021W-WB
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 14:55:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AB/F6-09842-17967645; Sat, 15 Nov 2014 14:55:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416063343!13012439!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23264 invoked from network); 15 Nov 2014 14:55:44 -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;
	15 Nov 2014 14:55:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="193174314"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 09:55:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpelK-0000E2-5I;
	Sat, 15 Nov 2014 14:55:42 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpelK-0000tA-0F;
	Sat, 15 Nov 2014 14:55:42 +0000
Date: Sat, 15 Nov 2014 14:55:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31553-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31553: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31553 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31553/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   18 guest-migrate/dst_host/src_host fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 seabios              b0d42bd03225ad61e5421e12b57f633f84637328
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Hannes Reinecke <hare@suse.de>
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 401 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 Nov 15 14:56:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 14:56:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpelO-00021b-R8; Sat, 15 Nov 2014 14:55:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpelN-00021W-WB
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 14:55:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AB/F6-09842-17967645; Sat, 15 Nov 2014 14:55:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416063343!13012439!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23264 invoked from network); 15 Nov 2014 14:55:44 -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;
	15 Nov 2014 14:55:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="193174314"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 09:55:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpelK-0000E2-5I;
	Sat, 15 Nov 2014 14:55:42 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpelK-0000tA-0F;
	Sat, 15 Nov 2014 14:55:42 +0000
Date: Sat, 15 Nov 2014 14:55:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31553-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31553: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31553 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31553/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   18 guest-migrate/dst_host/src_host fail REGR. vs. 30767

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 seabios              b0d42bd03225ad61e5421e12b57f633f84637328
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Hannes Reinecke <hare@suse.de>
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 401 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 Nov 15 15:39:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 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 1XpfRp-0002hB-Ve; Sat, 15 Nov 2014 15:39: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@citrix.com>) id 1XpfRo-0002h6-Vf
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 15:39:37 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	47/91-17735-8B377645; Sat, 15 Nov 2014 15:39:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416065972!11648222!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13913 invoked from network); 15 Nov 2014 15:39:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 15:39:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="191708931"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 10:39:30 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpfRi-0000Rn-3B;
	Sat, 15 Nov 2014 15:39:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpfRh-0007KK-RR;
	Sat, 15 Nov 2014 15:39:29 +0000
Date: Sat, 15 Nov 2014 15:39:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31574-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8322
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31574: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8052626585741998485=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8052626585741998485==
Content-Type: text/plain
Content-Length: 8003
Content-Transfer-Encoding: quoted-printable

flight 31574 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31574/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 31237
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 31237

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 31237

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                abbbc2f09a53f8f9ee565356ab11a78af006e45e
baseline version:
 qemuu                ca78cc83650b535d7e24baeaea32947be0141534

------------------------------------------------------------
People who touched revisions under test:
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

------------------------------------------------------------
commit abbbc2f09a53f8f9ee565356ab11a78af006e45e
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Nov 13 18:42:09 2014 +0100

    xen_disk: fix unmapping of persistent grants
    
    This patch fixes two issues with persistent grants and the disk PV backend
    (Qdisk):
    
     - Keep track of memory regions where persistent grants have been mapped
       since we need to unmap them as a whole. It is not possible to unmap a
       single grant if it has been batch-mapped. A new check has also been added
       to make sure persistent grants are only used if the whole mapped region
       can be persistently mapped in the batch_maps case.
     - Unmap persistent grants before switching to the closed state, so the
       frontend can also free them.
    
    upstream-commit-id: 2f01dfacb56bc7a0d4639adc9dff9aae131e6216
    
    Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reported-by: George Dunlap <george.dunlap@eu.citrix.com>
    Cc: Kevin Wolf <kwolf@redhat.com>
    Cc: Stefan Hajnoczi <stefanha@redhat.com>
    Cc: George Dunlap <george.dunlap@eu.citrix.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


--===============8052626585741998485==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8052626585741998485==--

From xen-devel-bounces@lists.xen.org Sat Nov 15 15:39:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 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 1XpfRp-0002hB-Ve; Sat, 15 Nov 2014 15:39: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@citrix.com>) id 1XpfRo-0002h6-Vf
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 15:39:37 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	47/91-17735-8B377645; Sat, 15 Nov 2014 15:39:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416065972!11648222!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13913 invoked from network); 15 Nov 2014 15:39:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 15:39:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="191708931"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 10:39:30 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpfRi-0000Rn-3B;
	Sat, 15 Nov 2014 15:39:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpfRh-0007KK-RR;
	Sat, 15 Nov 2014 15:39:29 +0000
Date: Sat, 15 Nov 2014 15:39:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31574-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8322
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31574: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8052626585741998485=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8052626585741998485==
Content-Type: text/plain
Content-Length: 8003
Content-Transfer-Encoding: quoted-printable

flight 31574 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31574/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 31237
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 31237

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 31237

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                abbbc2f09a53f8f9ee565356ab11a78af006e45e
baseline version:
 qemuu                ca78cc83650b535d7e24baeaea32947be0141534

------------------------------------------------------------
People who touched revisions under test:
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

------------------------------------------------------------
commit abbbc2f09a53f8f9ee565356ab11a78af006e45e
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Nov 13 18:42:09 2014 +0100

    xen_disk: fix unmapping of persistent grants
    
    This patch fixes two issues with persistent grants and the disk PV backend
    (Qdisk):
    
     - Keep track of memory regions where persistent grants have been mapped
       since we need to unmap them as a whole. It is not possible to unmap a
       single grant if it has been batch-mapped. A new check has also been added
       to make sure persistent grants are only used if the whole mapped region
       can be persistently mapped in the batch_maps case.
     - Unmap persistent grants before switching to the closed state, so the
       frontend can also free them.
    
    upstream-commit-id: 2f01dfacb56bc7a0d4639adc9dff9aae131e6216
    
    Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reported-by: George Dunlap <george.dunlap@eu.citrix.com>
    Cc: Kevin Wolf <kwolf@redhat.com>
    Cc: Stefan Hajnoczi <stefanha@redhat.com>
    Cc: George Dunlap <george.dunlap@eu.citrix.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


--===============8052626585741998485==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8052626585741998485==--

From xen-devel-bounces@lists.xen.org Sat Nov 15 16:16:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 16: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 1Xpg1O-0003hb-24; Sat, 15 Nov 2014 16:16:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xpg1N-0003hW-5p
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 16:16:21 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	6A/DB-25727-45C77645; Sat, 15 Nov 2014 16:16:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416068178!11595937!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13719 invoked from network); 15 Nov 2014 16:16:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 16:16:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="191713996"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 11:16:16 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpg1H-0000d5-Ul;
	Sat, 15 Nov 2014 16:16:16 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpg1H-0008Sg-MB;
	Sat, 15 Nov 2014 16:16:15 +0000
Date: Sat, 15 Nov 2014 16:16:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31560-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31560: 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 31560 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31560/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)   broken REGR. vs. 31489

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31489
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31489

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  934e7baa6c12d19cfaf24e8f8e27d6c6a8b8c5e4
baseline version:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

------------------------------------------------------------
People who touched revisions under test:
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Juergen Gross <jgross@suse.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  M A Young <m.a.young@durham.ac.uk>
  Meng Xu <mengxu@cis.upenn.edu>
  Michael Young <m.a.young@durham.ac.uk>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           broken  
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-qemut-winxpsp3 host-install(3)

Not pushing.

(No revision log; it would be 330 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 Nov 15 16:16:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 16: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 1Xpg1O-0003hb-24; Sat, 15 Nov 2014 16:16:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xpg1N-0003hW-5p
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 16:16:21 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	6A/DB-25727-45C77645; Sat, 15 Nov 2014 16:16:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416068178!11595937!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13719 invoked from network); 15 Nov 2014 16:16:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 16:16:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="191713996"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 11:16:16 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpg1H-0000d5-Ul;
	Sat, 15 Nov 2014 16:16:16 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpg1H-0008Sg-MB;
	Sat, 15 Nov 2014 16:16:15 +0000
Date: Sat, 15 Nov 2014 16:16:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31560-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31560: 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 31560 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31560/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)   broken REGR. vs. 31489

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31489
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31489

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  934e7baa6c12d19cfaf24e8f8e27d6c6a8b8c5e4
baseline version:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

------------------------------------------------------------
People who touched revisions under test:
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Juergen Gross <jgross@suse.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  M A Young <m.a.young@durham.ac.uk>
  Meng Xu <mengxu@cis.upenn.edu>
  Michael Young <m.a.young@durham.ac.uk>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           broken  
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-qemut-winxpsp3 host-install(3)

Not pushing.

(No revision log; it would be 330 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 Nov 15 17:00:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 17:00:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpgi6-0004MD-Vj; Sat, 15 Nov 2014 17:00:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xpgi5-0004M8-HY
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 17:00:29 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	96/7E-27623-CA687645; Sat, 15 Nov 2014 17:00:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416070826!11631891!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2414 invoked from network); 15 Nov 2014 17:00:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 17:00:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="191719566"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 12:00:23 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpghz-0000q6-1l;
	Sat, 15 Nov 2014 17:00:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpghy-0002SU-Nr;
	Sat, 15 Nov 2014 17:00:22 +0000
Date: Sat, 15 Nov 2014 17:00:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31571-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31571: 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 31571 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31571/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-xl-credit2    9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf      9 guest-start             fail baseline untested
 test-amd64-i386-xl            9 guest-start             fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu 11 guest-saverestore       fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-xl-sedf-pin 12 guest-localmigrate      fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                d7e5a72b951a4ef6d97b2aa43cad37f237ba8030
baseline version:
 linux                04689e749b7ec156291446028a0ce2e685bf3855

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 17:00:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 17:00:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpgi6-0004MD-Vj; Sat, 15 Nov 2014 17:00:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xpgi5-0004M8-HY
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 17:00:29 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	96/7E-27623-CA687645; Sat, 15 Nov 2014 17:00:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416070826!11631891!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2414 invoked from network); 15 Nov 2014 17:00:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 17:00:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208";a="191719566"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 12:00:23 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpghz-0000q6-1l;
	Sat, 15 Nov 2014 17:00:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpghy-0002SU-Nr;
	Sat, 15 Nov 2014 17:00:22 +0000
Date: Sat, 15 Nov 2014 17:00:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31571-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31571: 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 31571 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31571/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-xl-credit2    9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf      9 guest-start             fail baseline untested
 test-amd64-i386-xl            9 guest-start             fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu 11 guest-saverestore       fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-xl-sedf-pin 12 guest-localmigrate      fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                d7e5a72b951a4ef6d97b2aa43cad37f237ba8030
baseline version:
 linux                04689e749b7ec156291446028a0ce2e685bf3855

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 19:42:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 19: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 1XpjE3-0006TJ-Un; Sat, 15 Nov 2014 19:41:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpjE2-0006TE-OU
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 19:41:38 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4D/A3-09936-27CA7645; Sat, 15 Nov 2014 19:41:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416080496!12984646!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22299 invoked from network); 15 Nov 2014 19:41:37 -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;
	15 Nov 2014 19:41:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,392,1413244800"; d="scan'208";a="191739036"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 14:41:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpjDx-0001c0-LA;
	Sat, 15 Nov 2014 19:41:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpjDx-0002XQ-Cf;
	Sat, 15 Nov 2014 19:41:33 +0000
Date: Sat, 15 Nov 2014 19:41:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31577-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31577: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31577 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31577/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 31544
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31544 pass in 31520
 test-amd64-i386-pair          8 xen-boot/dst_host  fail in 31544 pass in 31577

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail in 31544 blocked in 26303
 test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 31544 like 26261
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 31520 like 26261
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail in 31520 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 15 19:42:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 19: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 1XpjE3-0006TJ-Un; Sat, 15 Nov 2014 19:41:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XpjE2-0006TE-OU
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 19:41:38 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4D/A3-09936-27CA7645; Sat, 15 Nov 2014 19:41:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416080496!12984646!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22299 invoked from network); 15 Nov 2014 19:41:37 -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;
	15 Nov 2014 19:41:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,392,1413244800"; d="scan'208";a="191739036"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 14:41:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XpjDx-0001c0-LA;
	Sat, 15 Nov 2014 19:41:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XpjDx-0002XQ-Cf;
	Sat, 15 Nov 2014 19:41:33 +0000
Date: Sat, 15 Nov 2014 19:41:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31577-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31577: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31577 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31577/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 31544
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31544 pass in 31520
 test-amd64-i386-pair          8 xen-boot/dst_host  fail in 31544 pass in 31577

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail in 31544 blocked in 26303
 test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 31544 like 26261
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 31520 like 26261
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail in 31520 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                816b571ac0e9eb9700df1ebc99702f9ad04e8607
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
698 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27231 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 Nov 15 21:42:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 21:42:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpl6J-0008D5-Kp; Sat, 15 Nov 2014 21:41: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@citrix.com>) id 1Xpl6H-00089r-SZ
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 21:41:46 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	BE/F4-27623-898C7645; Sat, 15 Nov 2014 21:41:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416087702!11661143!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25956 invoked from network); 15 Nov 2014 21:41:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 21:41:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,392,1413244800"; d="scan'208";a="193228676"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 16:41:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpl6C-0002Bw-K7;
	Sat, 15 Nov 2014 21:41:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpl6C-0006Th-EA;
	Sat, 15 Nov 2014 21:41:40 +0000
Date: Sat, 15 Nov 2014 21:41:40 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31593-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31593: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31593 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31593/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 21:42:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 21:42:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpl6J-0008D5-Kp; Sat, 15 Nov 2014 21:41: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@citrix.com>) id 1Xpl6H-00089r-SZ
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 21:41:46 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	BE/F4-27623-898C7645; Sat, 15 Nov 2014 21:41:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416087702!11661143!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25956 invoked from network); 15 Nov 2014 21:41:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 21:41:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,392,1413244800"; d="scan'208";a="193228676"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 16:41:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpl6C-0002Bw-K7;
	Sat, 15 Nov 2014 21:41:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpl6C-0006Th-EA;
	Sat, 15 Nov 2014 21:41:40 +0000
Date: Sat, 15 Nov 2014 21:41:40 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31593-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31593: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31593 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31593/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 22:47:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 22: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 1Xpm7C-0000i0-OI; Sat, 15 Nov 2014 22:46:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xpm7B-0000hv-9K
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 22:46:45 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	22/A7-02957-4D7D7645; Sat, 15 Nov 2014 22:46:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416091602!12795971!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27696 invoked from network); 15 Nov 2014 22:46:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 22:46:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,393,1413244800"; d="scan'208";a="191758863"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 17:46:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpm76-0002Va-3M;
	Sat, 15 Nov 2014 22:46:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpm75-0005gw-UW;
	Sat, 15 Nov 2014 22:46:39 +0000
Date: Sat, 15 Nov 2014 22:46:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31595-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31595: 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 31595 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31595/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              72b4151f858df3564b82a8ebba60778b996b6dce
baseline version:
 libvirt              ae3e29e6e7a9a208732f22721e735d238b2aa8cb

------------------------------------------------------------
People who touched revisions under test:
  Daniel P. Berrange <berrange@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Luyao Huang <lhuang@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=72b4151f858df3564b82a8ebba60778b996b6dce
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 72b4151f858df3564b82a8ebba60778b996b6dce
+ branch=libvirt
+ revision=72b4151f858df3564b82a8ebba60778b996b6dce
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 72b4151f858df3564b82a8ebba60778b996b6dce:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   ae3e29e6..72b4151 72b4151f858df3564b82a8ebba60778b996b6dce -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 15 22:47:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Nov 2014 22: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 1Xpm7C-0000i0-OI; Sat, 15 Nov 2014 22:46:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xpm7B-0000hv-9K
	for xen-devel@lists.xensource.com; Sat, 15 Nov 2014 22:46:45 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	22/A7-02957-4D7D7645; Sat, 15 Nov 2014 22:46:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416091602!12795971!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27696 invoked from network); 15 Nov 2014 22:46:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 22:46:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,393,1413244800"; d="scan'208";a="191758863"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 17:46:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpm76-0002Va-3M;
	Sat, 15 Nov 2014 22:46:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpm75-0005gw-UW;
	Sat, 15 Nov 2014 22:46:39 +0000
Date: Sat, 15 Nov 2014 22:46:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31595-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31595: 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 31595 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31595/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              72b4151f858df3564b82a8ebba60778b996b6dce
baseline version:
 libvirt              ae3e29e6e7a9a208732f22721e735d238b2aa8cb

------------------------------------------------------------
People who touched revisions under test:
  Daniel P. Berrange <berrange@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Luyao Huang <lhuang@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=72b4151f858df3564b82a8ebba60778b996b6dce
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 72b4151f858df3564b82a8ebba60778b996b6dce
+ branch=libvirt
+ revision=72b4151f858df3564b82a8ebba60778b996b6dce
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 72b4151f858df3564b82a8ebba60778b996b6dce:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   ae3e29e6..72b4151 72b4151f858df3564b82a8ebba60778b996b6dce -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 02:37:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 02:37:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpphY-0006tu-Ao; Sun, 16 Nov 2014 02:36:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caobosimon@gmail.com>) id 1XpphX-0006to-6P
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 02:36:31 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E8/92-24532-EAD08645; Sun, 16 Nov 2014 02:36:30 +0000
X-Env-Sender: caobosimon@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416105389!13071271!1
X-Originating-IP: [209.85.215.53]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20247 invoked from network); 16 Nov 2014 02:36:29 -0000
Received: from mail-la0-f53.google.com (HELO mail-la0-f53.google.com)
	(209.85.215.53)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 02:36:29 -0000
Received: by mail-la0-f53.google.com with SMTP id mc6so16560207lab.26
	for <xen-devel@lists.xensource.com>;
	Sat, 15 Nov 2014 18:36:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=9oBPnja8+UPr/Z3hH99Y3TT205gvDMXUKs2b8ig0J/Y=;
	b=gyDzelGZd/iOJdL03gb2L5Fr3yd+KNwbyNtxXH7+wUO2uvAiE1IDXnANUDlvhMpwbT
	A1zP9Tl/A3b3bU/cZ+m08ZoZbmmeD+0kWKhI1CSaEh5peY6KpbkQgI+GLMycV1V5r2a0
	YR7YYffovirUtOrxTkynNHes5vMnGocZEr7rCy92dH0Doci/6241odyVuf5MQBiPoUrQ
	c6If+A8h/9X67EP5rXY31yUUEiAx1AGSjMPx+0wFhj32TysuKlr8Vmy68nbi5F8rKc9j
	zRkjGNOqLIrqxTWSIed6O4ix7vp84khpuQ+AtjxtPkrxR2ZleVdkI8Lp7VMeTAqEFZkb
	SFqw==
MIME-Version: 1.0
X-Received: by 10.152.88.8 with SMTP id bc8mr17227693lab.64.1416105388552;
	Sat, 15 Nov 2014 18:36:28 -0800 (PST)
Received: by 10.112.1.38 with HTTP; Sat, 15 Nov 2014 18:36:28 -0800 (PST)
In-Reply-To: <5460E9D80200006600078038@soto.provo.novell.com>
References: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
	<5460E9D80200006600078038@soto.provo.novell.com>
Date: Sun, 16 Nov 2014 10:36:28 +0800
Message-ID: <CAMJpVt8yO8SDpmgFE1XJDNCF1v87Czt+9Li117xZnhsxpCRj_Q@mail.gmail.com>
From: Simon Cao <caobosimon@gmail.com>
To: Chun Yan Liu <cyliu@suse.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>, Lars Kurth <lars.kurth@citrix.com>
Subject: Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6960418408066348711=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6960418408066348711==
Content-Type: multipart/alternative; boundary=001a11c35664a639860507f0ba96

--001a11c35664a639860507f0ba96
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I was working on the work. But I was busing preparing some job interviews
in the last three months, sorry for this long delay. I will update my
progress in a few days.

Thanks!

Bo Cao

On Mon, Nov 10, 2014 at 4:37 PM, Chun Yan Liu <cyliu@suse.com> wrote:

> Is there any progress on this work? I didn't see new version after this.
> Anyone knows the status?
>
> Thanks,
> Chunyan
>
> >>> On 8/11/2014 at 04:23 AM, in message
> <1407702234-22309-1-git-send-email-caobosimon@gmail.com>, Bo Cao
> <caobosimon@gmail.com> wrote:
> > Finally I have a workable version xl/libxl support for PVUSB. Most of
> > its commands work property now, but there are still some probelm to be
> > solved.
> > Please take a loot and give me some advices.
> >
> > =3D=3D What have been implemented ? =3D=3D
> > I have implemented libxl functions for PVUSB in libxl_usb.c. It mainly
> > consists of two part:
> > usbctrl_add/remove/list and usb_add/remove/list in which usbctrl denote
> usb
> > controller in which
> > usd device can be plugged in. I don't use "ao_dev" in
> > libxl_deivce_usbctrl_add since we don't need to
> > execute hotplug script for usbctrl and without "ao_dev", adding default
> > usbctrl for usb device
> > would be easier.
> >
> > For the cammands to manipulate usb device such as "xl usb-attach" and "=
xl
> > usb-detach", this patch now only
> > support to specify usb devices by their interface in sysfs. Using this
> > interface, we can read usb device
> > information through sysfs and bind/unbind usb device. (The support for
> > mapping the "lsusb" bus:addr to the
> > sysfs usb interface will come later).
> >
> > =3D=3D What needs to do next ? =3D=3D
> > There are two main problems to be solved.
> >
> > 1.  PVUSB Options in VM Guest's Configuration File
> >     The interface in VM Guest's configuration file to add usb device is=
:
> > "usb=3D[interface=3D"1-1"]".
> > But the problem is now is that after the default usbctrl is added, the
> state
> > of usbctrl is "2", e,g, "XenbusStateInitWait",
> > waiting for xen-usbfront to connect. The xen-usbfront in VM Guest isn't
> > loaded. Therefore, "sysfs_intf_write"
> > will report error. Does anyone have any clue how to solve this?
> >
> > 2. sysfs_intf_write
> >     In the process of "xl usb-attach domid intf=3D1-1", after writing
> "1-1" to
> > Xenstore entry, we need to
> > bind the controller of this usb device to usbback driver so that it can
> be
> > used by VM Guest. For exampele,
> > for usb device "1-1", it's controller interface maybe "1-1:1.0", and we
> > write this value to "/sys/bus/usb/driver/usbback/bind".
> > But for some devices, they have two controllers, for example "1-1:1.0"
> and
> > "1-1:1.1". I think this means it has two functions,
> > such as usbhid and usb-storage. So in this case, we bind the two
> controller
> > to usbback?
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D
> > There maybe some errors or bugs in the codes. Feel free to tell me.
> >
> > Cheers,
> >
> > - Simon
> >
> > ---
> > CC: George Dunlap <george.dunlap@eu.citrix.com>
> > CC: Ian Jackson <ian.jackson@citrix.com>
> > CC: Ian Campbell <ian.campbell@citrix.com>
> > CC: Pasi K=C3=A4rkk=C3=A4inen <pasik@iki.fi>
> > CC: Lars Kurth <lars.kurth@citrix.com>
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>
>

--001a11c35664a639860507f0ba96
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi, <br><br></div>I was working on the work. But=
 I was busing preparing some job interviews in the last three months, sorry=
 for this long delay. I will update my progress in a few days. <br><br>Than=
ks!<br><br></div>Bo Cao<br></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Mon, Nov 10, 2014 at 4:37 PM, Chun Yan Liu <span dir=3D=
"ltr">&lt;<a href=3D"mailto:cyliu@suse.com" target=3D"_blank">cyliu@suse.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there any prog=
ress on this work? I didn&#39;t see new version after this.<br>
Anyone knows the status?<br>
<br>
Thanks,<br>
Chunyan<br>
<br>
&gt;&gt;&gt; On 8/11/2014 at 04:23 AM, in message<br>
&lt;<a href=3D"mailto:1407702234-22309-1-git-send-email-caobosimon@gmail.co=
m">1407702234-22309-1-git-send-email-caobosimon@gmail.com</a>&gt;, Bo Cao<b=
r>
<div><div class=3D"h5">&lt;<a href=3D"mailto:caobosimon@gmail.com">caobosim=
on@gmail.com</a>&gt; wrote:<br>
&gt; Finally I have a workable version xl/libxl support for PVUSB. Most of<=
br>
&gt; its commands work property now, but there are still some probelm to be=
<br>
&gt; solved.<br>
&gt; Please take a loot and give me some advices.<br>
&gt;<br>
&gt; =3D=3D What have been implemented ? =3D=3D<br>
&gt; I have implemented libxl functions for PVUSB in libxl_usb.c. It mainly=
<br>
&gt; consists of two part:<br>
&gt; usbctrl_add/remove/list and usb_add/remove/list in which usbctrl denot=
e usb<br>
&gt; controller in which<br>
&gt; usd device can be plugged in. I don&#39;t use &quot;ao_dev&quot; in<br=
>
&gt; libxl_deivce_usbctrl_add since we don&#39;t need to<br>
&gt; execute hotplug script for usbctrl and without &quot;ao_dev&quot;, add=
ing default<br>
&gt; usbctrl for usb device<br>
&gt; would be easier.<br>
&gt;<br>
&gt; For the cammands to manipulate usb device such as &quot;xl usb-attach&=
quot; and &quot;xl<br>
&gt; usb-detach&quot;, this patch now only<br>
&gt; support to specify usb devices by their interface in sysfs. Using this=
<br>
&gt; interface, we can read usb device<br>
&gt; information through sysfs and bind/unbind usb device. (The support for=
<br>
&gt; mapping the &quot;lsusb&quot; bus:addr to the<br>
&gt; sysfs usb interface will come later).<br>
&gt;<br>
&gt; =3D=3D What needs to do next ? =3D=3D<br>
&gt; There are two main problems to be solved.<br>
&gt;<br>
&gt; 1.=C2=A0 PVUSB Options in VM Guest&#39;s Configuration File<br>
&gt;=C2=A0 =C2=A0 =C2=A0The interface in VM Guest&#39;s configuration file =
to add usb device is:<br>
&gt; &quot;usb=3D[interface=3D&quot;1-1&quot;]&quot;.<br>
&gt; But the problem is now is that after the default usbctrl is added, the=
 state<br>
&gt; of usbctrl is &quot;2&quot;, e,g, &quot;XenbusStateInitWait&quot;,<br>
&gt; waiting for xen-usbfront to connect. The xen-usbfront in VM Guest isn&=
#39;t<br>
&gt; loaded. Therefore, &quot;sysfs_intf_write&quot;<br>
&gt; will report error. Does anyone have any clue how to solve this?<br>
&gt;<br>
&gt; 2. sysfs_intf_write<br>
&gt;=C2=A0 =C2=A0 =C2=A0In the process of &quot;xl usb-attach domid intf=3D=
1-1&quot;, after writing &quot;1-1&quot; to<br>
&gt; Xenstore entry, we need to<br>
&gt; bind the controller of this usb device to usbback driver so that it ca=
n be<br>
&gt; used by VM Guest. For exampele,<br>
&gt; for usb device &quot;1-1&quot;, it&#39;s controller interface maybe &q=
uot;1-1:1.0&quot;, and we<br>
&gt; write this value to &quot;/sys/bus/usb/driver/usbback/bind&quot;.<br>
&gt; But for some devices, they have two controllers, for example &quot;1-1=
:1.0&quot; and<br>
&gt; &quot;1-1:1.1&quot;. I think this means it has two functions,<br>
&gt; such as usbhid and usb-storage. So in this case, we bind the two contr=
oller<br>
&gt; to usbback?<br>
&gt;<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; There maybe some errors or bugs in the codes. Feel free to tell me.<br=
>
&gt;<br>
&gt; Cheers,<br>
&gt;<br>
&gt; - Simon<br>
&gt;<br>
&gt; ---<br>
&gt; CC: George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.com">g=
eorge.dunlap@eu.citrix.com</a>&gt;<br>
&gt; CC: Ian Jackson &lt;<a href=3D"mailto:ian.jackson@citrix.com">ian.jack=
son@citrix.com</a>&gt;<br>
&gt; CC: Ian Campbell &lt;<a href=3D"mailto:ian.campbell@citrix.com">ian.ca=
mpbell@citrix.com</a>&gt;<br>
&gt; CC: Pasi K=C3=A4rkk=C3=A4inen &lt;<a href=3D"mailto:pasik@iki.fi">pasi=
k@iki.fi</a>&gt;<br>
&gt; CC: Lars Kurth &lt;<a href=3D"mailto:lars.kurth@citrix.com">lars.kurth=
@citrix.com</a>&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
&gt;<br>
<br>
</blockquote></div><br></div>

--001a11c35664a639860507f0ba96--


--===============6960418408066348711==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6960418408066348711==--


From xen-devel-bounces@lists.xen.org Sun Nov 16 02:37:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 02:37:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpphY-0006tu-Ao; Sun, 16 Nov 2014 02:36:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caobosimon@gmail.com>) id 1XpphX-0006to-6P
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 02:36:31 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E8/92-24532-EAD08645; Sun, 16 Nov 2014 02:36:30 +0000
X-Env-Sender: caobosimon@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416105389!13071271!1
X-Originating-IP: [209.85.215.53]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20247 invoked from network); 16 Nov 2014 02:36:29 -0000
Received: from mail-la0-f53.google.com (HELO mail-la0-f53.google.com)
	(209.85.215.53)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 02:36:29 -0000
Received: by mail-la0-f53.google.com with SMTP id mc6so16560207lab.26
	for <xen-devel@lists.xensource.com>;
	Sat, 15 Nov 2014 18:36:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=9oBPnja8+UPr/Z3hH99Y3TT205gvDMXUKs2b8ig0J/Y=;
	b=gyDzelGZd/iOJdL03gb2L5Fr3yd+KNwbyNtxXH7+wUO2uvAiE1IDXnANUDlvhMpwbT
	A1zP9Tl/A3b3bU/cZ+m08ZoZbmmeD+0kWKhI1CSaEh5peY6KpbkQgI+GLMycV1V5r2a0
	YR7YYffovirUtOrxTkynNHes5vMnGocZEr7rCy92dH0Doci/6241odyVuf5MQBiPoUrQ
	c6If+A8h/9X67EP5rXY31yUUEiAx1AGSjMPx+0wFhj32TysuKlr8Vmy68nbi5F8rKc9j
	zRkjGNOqLIrqxTWSIed6O4ix7vp84khpuQ+AtjxtPkrxR2ZleVdkI8Lp7VMeTAqEFZkb
	SFqw==
MIME-Version: 1.0
X-Received: by 10.152.88.8 with SMTP id bc8mr17227693lab.64.1416105388552;
	Sat, 15 Nov 2014 18:36:28 -0800 (PST)
Received: by 10.112.1.38 with HTTP; Sat, 15 Nov 2014 18:36:28 -0800 (PST)
In-Reply-To: <5460E9D80200006600078038@soto.provo.novell.com>
References: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
	<5460E9D80200006600078038@soto.provo.novell.com>
Date: Sun, 16 Nov 2014 10:36:28 +0800
Message-ID: <CAMJpVt8yO8SDpmgFE1XJDNCF1v87Czt+9Li117xZnhsxpCRj_Q@mail.gmail.com>
From: Simon Cao <caobosimon@gmail.com>
To: Chun Yan Liu <cyliu@suse.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>, Lars Kurth <lars.kurth@citrix.com>
Subject: Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6960418408066348711=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6960418408066348711==
Content-Type: multipart/alternative; boundary=001a11c35664a639860507f0ba96

--001a11c35664a639860507f0ba96
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I was working on the work. But I was busing preparing some job interviews
in the last three months, sorry for this long delay. I will update my
progress in a few days.

Thanks!

Bo Cao

On Mon, Nov 10, 2014 at 4:37 PM, Chun Yan Liu <cyliu@suse.com> wrote:

> Is there any progress on this work? I didn't see new version after this.
> Anyone knows the status?
>
> Thanks,
> Chunyan
>
> >>> On 8/11/2014 at 04:23 AM, in message
> <1407702234-22309-1-git-send-email-caobosimon@gmail.com>, Bo Cao
> <caobosimon@gmail.com> wrote:
> > Finally I have a workable version xl/libxl support for PVUSB. Most of
> > its commands work property now, but there are still some probelm to be
> > solved.
> > Please take a loot and give me some advices.
> >
> > =3D=3D What have been implemented ? =3D=3D
> > I have implemented libxl functions for PVUSB in libxl_usb.c. It mainly
> > consists of two part:
> > usbctrl_add/remove/list and usb_add/remove/list in which usbctrl denote
> usb
> > controller in which
> > usd device can be plugged in. I don't use "ao_dev" in
> > libxl_deivce_usbctrl_add since we don't need to
> > execute hotplug script for usbctrl and without "ao_dev", adding default
> > usbctrl for usb device
> > would be easier.
> >
> > For the cammands to manipulate usb device such as "xl usb-attach" and "=
xl
> > usb-detach", this patch now only
> > support to specify usb devices by their interface in sysfs. Using this
> > interface, we can read usb device
> > information through sysfs and bind/unbind usb device. (The support for
> > mapping the "lsusb" bus:addr to the
> > sysfs usb interface will come later).
> >
> > =3D=3D What needs to do next ? =3D=3D
> > There are two main problems to be solved.
> >
> > 1.  PVUSB Options in VM Guest's Configuration File
> >     The interface in VM Guest's configuration file to add usb device is=
:
> > "usb=3D[interface=3D"1-1"]".
> > But the problem is now is that after the default usbctrl is added, the
> state
> > of usbctrl is "2", e,g, "XenbusStateInitWait",
> > waiting for xen-usbfront to connect. The xen-usbfront in VM Guest isn't
> > loaded. Therefore, "sysfs_intf_write"
> > will report error. Does anyone have any clue how to solve this?
> >
> > 2. sysfs_intf_write
> >     In the process of "xl usb-attach domid intf=3D1-1", after writing
> "1-1" to
> > Xenstore entry, we need to
> > bind the controller of this usb device to usbback driver so that it can
> be
> > used by VM Guest. For exampele,
> > for usb device "1-1", it's controller interface maybe "1-1:1.0", and we
> > write this value to "/sys/bus/usb/driver/usbback/bind".
> > But for some devices, they have two controllers, for example "1-1:1.0"
> and
> > "1-1:1.1". I think this means it has two functions,
> > such as usbhid and usb-storage. So in this case, we bind the two
> controller
> > to usbback?
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D
> > There maybe some errors or bugs in the codes. Feel free to tell me.
> >
> > Cheers,
> >
> > - Simon
> >
> > ---
> > CC: George Dunlap <george.dunlap@eu.citrix.com>
> > CC: Ian Jackson <ian.jackson@citrix.com>
> > CC: Ian Campbell <ian.campbell@citrix.com>
> > CC: Pasi K=C3=A4rkk=C3=A4inen <pasik@iki.fi>
> > CC: Lars Kurth <lars.kurth@citrix.com>
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>
>

--001a11c35664a639860507f0ba96
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi, <br><br></div>I was working on the work. But=
 I was busing preparing some job interviews in the last three months, sorry=
 for this long delay. I will update my progress in a few days. <br><br>Than=
ks!<br><br></div>Bo Cao<br></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Mon, Nov 10, 2014 at 4:37 PM, Chun Yan Liu <span dir=3D=
"ltr">&lt;<a href=3D"mailto:cyliu@suse.com" target=3D"_blank">cyliu@suse.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there any prog=
ress on this work? I didn&#39;t see new version after this.<br>
Anyone knows the status?<br>
<br>
Thanks,<br>
Chunyan<br>
<br>
&gt;&gt;&gt; On 8/11/2014 at 04:23 AM, in message<br>
&lt;<a href=3D"mailto:1407702234-22309-1-git-send-email-caobosimon@gmail.co=
m">1407702234-22309-1-git-send-email-caobosimon@gmail.com</a>&gt;, Bo Cao<b=
r>
<div><div class=3D"h5">&lt;<a href=3D"mailto:caobosimon@gmail.com">caobosim=
on@gmail.com</a>&gt; wrote:<br>
&gt; Finally I have a workable version xl/libxl support for PVUSB. Most of<=
br>
&gt; its commands work property now, but there are still some probelm to be=
<br>
&gt; solved.<br>
&gt; Please take a loot and give me some advices.<br>
&gt;<br>
&gt; =3D=3D What have been implemented ? =3D=3D<br>
&gt; I have implemented libxl functions for PVUSB in libxl_usb.c. It mainly=
<br>
&gt; consists of two part:<br>
&gt; usbctrl_add/remove/list and usb_add/remove/list in which usbctrl denot=
e usb<br>
&gt; controller in which<br>
&gt; usd device can be plugged in. I don&#39;t use &quot;ao_dev&quot; in<br=
>
&gt; libxl_deivce_usbctrl_add since we don&#39;t need to<br>
&gt; execute hotplug script for usbctrl and without &quot;ao_dev&quot;, add=
ing default<br>
&gt; usbctrl for usb device<br>
&gt; would be easier.<br>
&gt;<br>
&gt; For the cammands to manipulate usb device such as &quot;xl usb-attach&=
quot; and &quot;xl<br>
&gt; usb-detach&quot;, this patch now only<br>
&gt; support to specify usb devices by their interface in sysfs. Using this=
<br>
&gt; interface, we can read usb device<br>
&gt; information through sysfs and bind/unbind usb device. (The support for=
<br>
&gt; mapping the &quot;lsusb&quot; bus:addr to the<br>
&gt; sysfs usb interface will come later).<br>
&gt;<br>
&gt; =3D=3D What needs to do next ? =3D=3D<br>
&gt; There are two main problems to be solved.<br>
&gt;<br>
&gt; 1.=C2=A0 PVUSB Options in VM Guest&#39;s Configuration File<br>
&gt;=C2=A0 =C2=A0 =C2=A0The interface in VM Guest&#39;s configuration file =
to add usb device is:<br>
&gt; &quot;usb=3D[interface=3D&quot;1-1&quot;]&quot;.<br>
&gt; But the problem is now is that after the default usbctrl is added, the=
 state<br>
&gt; of usbctrl is &quot;2&quot;, e,g, &quot;XenbusStateInitWait&quot;,<br>
&gt; waiting for xen-usbfront to connect. The xen-usbfront in VM Guest isn&=
#39;t<br>
&gt; loaded. Therefore, &quot;sysfs_intf_write&quot;<br>
&gt; will report error. Does anyone have any clue how to solve this?<br>
&gt;<br>
&gt; 2. sysfs_intf_write<br>
&gt;=C2=A0 =C2=A0 =C2=A0In the process of &quot;xl usb-attach domid intf=3D=
1-1&quot;, after writing &quot;1-1&quot; to<br>
&gt; Xenstore entry, we need to<br>
&gt; bind the controller of this usb device to usbback driver so that it ca=
n be<br>
&gt; used by VM Guest. For exampele,<br>
&gt; for usb device &quot;1-1&quot;, it&#39;s controller interface maybe &q=
uot;1-1:1.0&quot;, and we<br>
&gt; write this value to &quot;/sys/bus/usb/driver/usbback/bind&quot;.<br>
&gt; But for some devices, they have two controllers, for example &quot;1-1=
:1.0&quot; and<br>
&gt; &quot;1-1:1.1&quot;. I think this means it has two functions,<br>
&gt; such as usbhid and usb-storage. So in this case, we bind the two contr=
oller<br>
&gt; to usbback?<br>
&gt;<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; There maybe some errors or bugs in the codes. Feel free to tell me.<br=
>
&gt;<br>
&gt; Cheers,<br>
&gt;<br>
&gt; - Simon<br>
&gt;<br>
&gt; ---<br>
&gt; CC: George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.com">g=
eorge.dunlap@eu.citrix.com</a>&gt;<br>
&gt; CC: Ian Jackson &lt;<a href=3D"mailto:ian.jackson@citrix.com">ian.jack=
son@citrix.com</a>&gt;<br>
&gt; CC: Ian Campbell &lt;<a href=3D"mailto:ian.campbell@citrix.com">ian.ca=
mpbell@citrix.com</a>&gt;<br>
&gt; CC: Pasi K=C3=A4rkk=C3=A4inen &lt;<a href=3D"mailto:pasik@iki.fi">pasi=
k@iki.fi</a>&gt;<br>
&gt; CC: Lars Kurth &lt;<a href=3D"mailto:lars.kurth@citrix.com">lars.kurth=
@citrix.com</a>&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
&gt;<br>
<br>
</blockquote></div><br></div>

--001a11c35664a639860507f0ba96--


--===============6960418408066348711==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6960418408066348711==--


From xen-devel-bounces@lists.xen.org Sun Nov 16 04:55:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 04: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 1Xprrj-0007tL-Ad; Sun, 16 Nov 2014 04:55:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xprrh-0007tD-BL
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 04:55:09 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	00/6D-27584-B2E28645; Sun, 16 Nov 2014 04:55:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416113702!11575677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14150 invoked from network); 16 Nov 2014 04:55:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 04:55:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,395,1413244800"; d="scan'208";a="193273212"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 23:55:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XprrY-0004Ob-IT;
	Sun, 16 Nov 2014 04:55:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XprrY-0006OM-95;
	Sun, 16 Nov 2014 04:55:00 +0000
Date: Sun, 16 Nov 2014 04:55:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31597-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31597: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31597 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31597/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)       broken REGR. vs. 31241
 build-i386-pvops              5 kernel-build              fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a

version targeted for testing:
 linux                56c381f93d57b88a3e667a2f55137947315c17e2
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
522 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-win7-amd64 host-install(3)

Not pushing.

(No revision log; it would be 20250 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 Nov 16 04:55:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 04: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 1Xprrj-0007tL-Ad; Sun, 16 Nov 2014 04:55:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xprrh-0007tD-BL
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 04:55:09 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	00/6D-27584-B2E28645; Sun, 16 Nov 2014 04:55:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416113702!11575677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14150 invoked from network); 16 Nov 2014 04:55:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 04:55:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,395,1413244800"; d="scan'208";a="193273212"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 15 Nov 2014 23:55:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XprrY-0004Ob-IT;
	Sun, 16 Nov 2014 04:55:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XprrY-0006OM-95;
	Sun, 16 Nov 2014 04:55:00 +0000
Date: Sun, 16 Nov 2014 04:55:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31597-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31597: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31597 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31597/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)       broken REGR. vs. 31241
 build-i386-pvops              5 kernel-build              fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a

version targeted for testing:
 linux                56c381f93d57b88a3e667a2f55137947315c17e2
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
522 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-win7-amd64 host-install(3)

Not pushing.

(No revision log; it would be 20250 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 Nov 16 07:15:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 07:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpu3Q-0000lr-I9; Sun, 16 Nov 2014 07:15:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xpu3P-0000lm-0J
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 07:15:23 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	54/4F-26858-A0F48645; Sun, 16 Nov 2014 07:15:22 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416122118!11688559!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29409 invoked from network); 16 Nov 2014 07:15:19 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-31.messagelabs.com with SMTP;
	16 Nov 2014 07:15:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 15 Nov 2014 23:15:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,396,1413270000"; 
	d="log'?scan'208";a="637687361"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 15 Nov 2014 23:15:15 -0800
Received: from pgsmsx107.gar.corp.intel.com (10.221.44.105) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Sun, 16 Nov 2014 15:15:14 +0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Sun, 16 Nov 2014 15:15:14 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Sun, 16 Nov 2014 15:15:12 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Emil Condrea <emilcondrea@gmail.com>, Daniel De Graaf
	<dgdegra@tycho.nsa.gov>
Thread-Topic: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
Thread-Index: AQHP+gyQogoroHdVBUOna8rL71CGzpxUYzsQgAARkYCAA4WJQIAK6YvQ
Date: Sun, 16 Nov 2014 07:15:11 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E83A0E9@SHSMSX101.ccr.corp.intel.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>	<545BEE4F.3080305@tycho.nsa.gov>
	<945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
	<CAAULxKL+z_p_JcN5pBySiQzRBP5Jc-2w+oRcg81jgkTshAQDiw@mail.gmail.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8278EA@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E8278EA@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_945CA011AD5F084CBEA3E851C0AB28890E83A0E9SHSMSX101ccrcor_"
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, "Xu, Quan" <quan.xu@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_945CA011AD5F084CBEA3E851C0AB28890E83A0E9SHSMSX101ccrcor_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RW1pbCAvIEdyYWFmLA0KCUkgaGF2ZSB2ZXJpZmllZCBpdCwgaXQgaXMgc3RpbGwgbm90IHdvcmtp
bmcgd2hlbiB0Ym9vdCBpcyBlbmFibGVkLiANClRoZSBhdHRhY2ggZmlsZSBpcyB0eHQtc3RhdCBs
b2cuIA0KWy4uLl0NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioNCiAgICAgICAgIFRYVCBtZWFzdXJlZCBsYXVuY2g6IFRSVUUNCiAg
ICAgICAgIHNlY3JldHMgZmxhZyBzZXQ6IFRSVUUNCioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpbLi4uXQ0KDQoNCkJlbG93IGlzIGVy
cm9yIHdoZW4gSSBib290IHZ0cG1tZ3I6DQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KWy4uLl0NCklPTUVNIE1hY2hpbmUgQmFz
ZSBBZGRyZXNzOiBGRUQ0MDAwMA0KRW5hYmxlZCBMb2NhbGl0aWVzOiAyDQpSRVEgTE9DQUxJVFkg
RkFJTFVSRQ0KVW5hYmxlIHRvIHJlcXVlc3QgbG9jYWxpdHkgMj8/DQpTaHV0dGluZyBkb3duIHRw
bV90aXMgZGV2aWNlDQpQYWdlIGZhdWx0IGF0IGxpbmVhciBhZGRyZXNzIDB4ZmVkNDAwMDgsIHJp
cCAweDJmOTE4LCByZWdzIDB4MTBmYzc4LCBzcCAweDEwZmQyMCwgb3VyX3NwIDB4MTBmYzQwLCBj
b2RlIDINClRocmVhZDogbWFpbg0KUklQOiBlMDMwOls8MDAwMDAwMDAwMDAyZjkxOD5dDQpSU1A6
IGUwMmI6MDAwMDAwMDAwMDEwZmQyMCAgRUZMQUdTOiAwMDAxMDIwMg0KUkFYOiBmZmZmZmZmZmZm
ZmZmZmZmIFJCWDogMDAwMDAwMjAwMDgwNGM2MCBSQ1g6IDAwMDAwMDAwMDAwMDA3MmMNClJEWDog
MDAwMDAwMDAwMDAwMDAxZSBSU0k6IDAwMDAwMDAwN2ZmZmZmZmYgUkRJOiAwMDAwMDAwMGZlZDQw
MDA4DQpSQlA6IDAwMDAwMDAwMDAxMGZkMjAgUjA4OiAwMDAwMDAwMDAwMDAwMDBhIFIwOTogMDAw
MDAwMDAwMDBhZjAwMA0KUjEwOiAwMDAwMDAwMDAwMDAwNzBlIFIxMTogMDAwMDAwMDAwMDAwMDZk
OCBSMTI6IDAwMDAwMDIwMDA4MDRjNjANClIxMzogMDAwMDAwMDBmZWQ0MjAwMCBSMTQ6IDAwMDAw
MDAwMDAwMDAwMDAgUjE1OiAwMDAwMDAwMDAwMDAwMDAyDQpiYXNlIGlzIDB4MTBmZDIwIGNhbGxl
ciBpcyAweDI0OTc3DQpiYXNlIGlzIDB4MTBmZDQwIGNhbGxlciBpcyAweDI0ZTMyDQpiYXNlIGlz
IDB4MTBmZDgwIGNhbGxlciBpcyAweDViNGINCmJhc2UgaXMgMHgxMGZmMzAgY2FsbGVyIGlzIDB4
MzUxMA0KYmFzZSBpcyAweDEwZmY1MCBjYWxsZXIgaXMgMHgyODdhMg0KYmFzZSBpcyAweDEwZmZl
MCBjYWxsZXIgaXMgMHgzNDNiDQoNCjEwZmQxMDogMjAgZmQgMTAgMDAgMDAgMDAgMDAgMDAgMmIg
ZTAgMDAgMDAgMDAgMDAgMDAgMDANCjEwZmQyMDogNDAgZmQgMTAgMDAgMDAgMDAgMDAgMDAgNzcg
NDkgMDIgMDAgMDAgMDAgMDAgMDANCjEwZmQzMDogNjAgNGMgODAgMDAgMjAgMDAgMDAgMDAgMDIg
MDAgMDAgMDAgMDAgMDAgMDAgMDANCjEwZmQ0MDogODAgZmQgMTAgMDAgMDAgMDAgMDAgMDAgMzIg
NGUgMDIgMDAgMDAgMDAgMDAgMDANCg0KMTBmZDEwOiAyMCBmZCAxMCAwMCAwMCAwMCAwMCAwMCAy
YiBlMCAwMCAwMCAwMCAwMCAwMCAwMA0KMTBmZDIwOiA0MCBmZCAxMCAwMCAwMCAwMCAwMCAwMCA3
NyA0OSAwMiAwMCAwMCAwMCAwMCAwMA0KMTBmZDMwOiA2MCA0YyA4MCAwMCAyMCAwMCAwMCAwMCAw
MiAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KMTBmZDQwOiA4MCBmZCAxMCAwMCAwMCAwMCAwMCAwMCAz
MiA0ZSAwMiAwMCAwMCAwMCAwMCAwMA0KDQoyZjkwMDogNWQgYzMgNTUgNDggODkgZTUgNDAgODgg
MzcgNWQgYzMgNTUgNDggODkgZTUgNjYNCjJmOTEwOiA4OSAzNyA1ZCBjMyA1NSA0OCA4OSBlNSA4
OSAzNyA1ZCBjMyA1NSA0OCA4OSBlNQ0KMmY5MjA6IDQ4IDg5IDM3IDVkIGMzIDU1IDQ4IDg5IGU1
IDBmIGI2IDA3IDVkIGMzIDU1IDQ4DQoyZjkzMDogODkgZTUgMGYgYjcgMDcgNWQgYzMgNTUgNDgg
ODkgZTUgOGIgMDcgNWQgYzMgNTUNClBhZ2V0YWJsZSB3YWxrIGZyb20gdmlydCBmZWQ0MDAwOCwg
YmFzZSBiMDAwMDoNCiBMNCA9IDAwMDAwMDAxMjcwMzMwNjcgKDB4YjEwMDApICBbb2Zmc2V0ID0g
MF0NCiAgTDMgPSAwMDAwMDAwMDAwMDAwMDAwICgweGZmZmZmZmZmZmZmZmYwMDApICBbb2Zmc2V0
ID0gM10NClBhZ2UgZmF1bHQgaW4gcGFnZXRhYmxlIHdhbGsgKGFjY2VzcyB0byBpbnZhbGlkIG1l
bW9yeT8pLg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KiogDQoNClRoYW5rcyANClF1YW4gWHUNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+IEZyb206IHhlbi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbi5vcmcNCj4gW21haWx0bzp4ZW4t
ZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnXSBPbiBCZWhhbGYgT2YgWHUsIFF1YW4NCj4gU2Vu
dDogU3VuZGF5LCBOb3ZlbWJlciAwOSwgMjAxNCA0OjMwIFBNDQo+IFRvOiBFbWlsIENvbmRyZWEN
Cj4gQ2M6IERhbmllbCBEZSBHcmFhZjsgSWFuIENhbXBiZWxsOyB4ZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1hlbi1kZXZlbF0gdnRwbW1nciBidWc6IGZhaWxzIHRvIHN0
YXJ0IGlmIGxvY2FsaXR5IT0wDQo+IA0KPiBPa2F5LCBJIHdpbGwgdGVzdCBpdCBpbiBuZXh0IHdl
ZWsuDQo+IA0KPiBUaGFua3MNCj4gUXVhbiBYdQ0KPiANCj4gDQo+IEZyb206IHhlbi1kZXZlbC1i
b3VuY2VzQGxpc3RzLnhlbi5vcmcNCj4gW21haWx0bzp4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54
ZW4ub3JnXSBPbiBCZWhhbGYgT2YgRW1pbCBDb25kcmVhDQo+IFNlbnQ6IEZyaWRheSwgTm92ZW1i
ZXIgMDcsIDIwMTQgNjo0MiBQTQ0KPiBUbzogWHUsIFF1YW4NCj4gQ2M6IERhbmllbCBEZSBHcmFh
ZjsgSWFuIENhbXBiZWxsOyB4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZw0KPiBTdWJqZWN0OiBSZTog
W1hlbi1kZXZlbF0gdnRwbW1nciBidWc6IGZhaWxzIHRvIHN0YXJ0IGlmIGxvY2FsaXR5IT0wDQo+
IA0KPiBYdSwgbXkgc3lzdGVtIGRvZXMgbm90IHN1cHBvcnQgRFJUTSBsYXVuY2ggc28gaWYgeW91
IGNhbiB0ZXN0IGl0IG5leHQgd2Vlaw0KPiBpdCB3b3VsZCBiZSBncmVhdC4NCj4gVGhhbmtzDQo+
IA0KPiBPbiBGcmksIE5vdiA3LCAyMDE0IGF0IDM6NDYgQU0sIFh1LCBRdWFuIDxxdWFuLnh1QGlu
dGVsLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiA+IEZyb206IHhlbi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbi5vcmcNCj4gPiBbbWFpbHRvOnhl
bi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbi5vcmddIE9uIEJlaGFsZiBPZiBEYW5pZWwgRGUgR3Jh
YWYNCj4gPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDA3LCAyMDE0IDU6NTUgQU0NCj4gPiBUbzog
RW1pbCBDb25kcmVhDQo+ID4gQ2M6IElhbiBDYW1wYmVsbDsgeGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcNCj4gPiBTdWJqZWN0OiBSZTogW1hlbi1kZXZlbF0gdnRwbW1nciBidWc6IGZhaWxzIHRvIHN0
YXJ0IGlmIGxvY2FsaXR5IT0wDQo+ID4NCj4gPiBPbiAxMS8wNS8yMDE0IDA1OjAwIEFNLCBJYW4g
Q2FtcGJlbGwgd3JvdGU6DQo+ID4gPiBDQ2luZyBEYW5pZWwuDQo+ID4gPg0KPiA+ID4gT24gRnJp
LCAyMDE0LTEwLTMxIGF0IDE3OjM3ICswMjAwLCBFbWlsIENvbmRyZWEgd3JvdGU6DQo+ID4gPj4N
Cj4gPiA+PiBJIGFtIHdvbmRlcmluZyBpZiB0aGlzIGlzIGtub3duIGlzc3VlIHRoYXQgd2hlbiBJ
IHNldCBsb2NhbGl0eSE9MCB0bw0KPiA+ID4+IHZ0cG1tZ3IgaXQgZG9lcyBub3Qgc3RhcnQuIEl0
IGlzIGEgYml0IHN0cmFuZ2UgdGhhdCBldmVyeSBjYWxsIHRvDQo+ID4gPj4gdHBtX3Rpc19zdGF0
dXMgcmV0dXJucyAyNTUgYW5kIGRldmljZS1pZCBpcyBhbHNvIEZGRkY6DQo+ID4gPj4gMS4yIFRQ
TSAoZGV2aWNlLWlkPTB4RkZGRiB2ZW5kb3ItaWQgPSBGRkZGIHJldi1pZCA9IEZGKS4NCj4gPiA+
PiBUUE0gaW50ZXJmYWNlIGNhcGFiaWxpdGllcyAoMHhmZmZmZmZmZik6DQo+ID4gPj4NCj4gPiA+
PiBJIGFtIGNvbmZpZ3VyaW5nIHZ0cG1tZ3IgdXNpbmc6DQo+ID4gPj4NCj4gPiA+PiBrZXJuZWw9
Ii91c3IvbG9jYWwvbGliL3hlbi9ib290L3Z0cG1tZ3Itc3R1YmRvbS5neiINCj4gPiA+PiBtZW1v
cnk9OA0KPiA+ID4+IGRpc2s9WyJmaWxlOi92YXIvdnRwbW1nci1zdHViZG9tLmltZyxoZGEsdyJd
DQo+ID4gPj4gbmFtZT0idnRwbW1nciINCj4gPiA+PiBpb21lbT1bImZlZDQwLDUiXQ0KPiA+ID4+
IGV4dHJhPSJ0cG1sb2NhbGl0eT0yIg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiBJIGFsc28gdHJp
ZWQgdXNpbmcgOg0KPiA+ID4+IGlvbWVtPVsiZmVkNDAsMSJdDQo+ID4gPj4gZXh0cmE9InRwbWxv
Y2FsaXR5PTAiLy93b3JrcyB3ZWxsDQo+ID4gPj4NCj4gPiA+PiBvcg0KPiA+ID4+IGlvbWVtPVsi
ZmVkNDIsMSJdDQo+ID4gPj4gZXh0cmE9InRwbWxvY2FsaXR5PTIiDQo+ID4gPj4gSXQgc2VlbXMg
dGhhdCBldmVyeXRoaW5nIHRoYXQgaXMgbm90IG1hcHBlZCBhdCBmZWQ0MC1mZWQ0MSBpcw0KPiA+
ID4+IEZGRkZGRkZGLg0KPiA+ID4+DQo+ID4gPj4gSSBoYXZlIGFuIEF0bWVsIFRQTSBjaGlwc2V0
Lg0KPiA+ID4+DQo+ID4gPj4gQ291bGQgaXQgYmUgYSBjaGlwc2V0IHByb2JsZW0gdG8gbm90IGhh
bmRsZSB3ZWxsIGRpZmZlcmVudCBsb2NhbGl0aWVzPw0KPiA+ID4+DQo+ID4gPj4gV2hlbiBJIHVz
ZSBsb2NhbGl0eT0wLCB0aGUgZGV2aWNlIGRyaXZlciBpbmZvIGlzIGNvcnJlY3QgYW5kDQo+ID4g
Pj4gZXZlcnl0aGluZyB3b3JrcyBmaW5lOg0KPiA+ID4+IDEuMiBUUE0gKGRldmljZS1pZD0weDMy
MDQgdmVuZG9yLWlkID0gMTExNCByZXYtaWQgPSA0MCkgVFBNIGludGVyZmFjZQ0KPiA+ID4+IGNh
cGFiaWxpdGllcyAoMHhmZCkNCj4gPg0KPiA+IFRoaXMgbWF5IGJlIGFuIGlzc3VlIHdpdGggbG9j
YWxpdHkgMiBiZWluZyB1bmF2YWlsYWJsZSB1bmxlc3MgYSBEUlRNDQo+IGxhdW5jaA0KPiA+ICh0
Ym9vdCkgaXMgcGVyZm9ybWVkLsKgIFJldHVybmluZyBhbGwtb25lcyBpcyB0aGUgbm9ybWFsIHJl
c3BvbnNlIG9mIHRoZQ0KPiB4ODYNCj4gPiBjaGlwc2V0IHdoZW4gdW5tYXBwZWQgTU1JTyByZWdp
b25zIGFyZSBhY2Nlc3NlZDsgZGlzYWJsZWQgbG9jYWxpdGllcyBvZg0KPiA+IHRoZSBUUE0gbWF5
IGFjdCBsaWtlIHRoaXMuDQo+ID4NCj4gPiBEb2VzIHlvdXIgc3lzdGVtIHN1cHBvcnQgdGhlIERS
VE0gbGF1bmNoP8KgIElmIHNvLCBjYW4geW91IHRlc3QgaXQgdG8gc2VlDQo+IGlmDQo+ID4gdGhp
cyBpcyB0aGUgaXNzdWU/DQo+IA0KPiBFbWlsLA0KPiB0Ym9vdCBzdXBwb3J0cyBJbnRlbCBhbmQg
T0VNIHN5c3RlbXMgdGhhdCBhcmUgSW50ZWwgVFhULWNhcGFibGUuDQo+IElmIHlvdXIgc3lzdGVt
IGRvZXMgbm90IHN1cHBvcnQgRFJUTSBsYXVuY2gsIEkgY2FuIHRlc3QgaXQgaW4gbmV4dCB3ZWVr
Lg0KPiANCj4gDQo+ID4NCj4gPiBJbiB0aGlzIGNhc2UsIHRvIGJldHRlciBzdXBwb3J0IHBlb3Bs
ZSB3aG8gd2FudCB0byB1c2UgdGhlIHZUUE0gTWFuYWdlcg0KPiA+IHdpdGhvdXQgYSBEUlRNIGxh
dW5jaCwgdGhlIGZlYXR1cmVzIG9mIHRoZSB2VFBNIE1hbmFnZXIgdGhhdCB1c2UgdGhlDQo+IFRQ
TQ0KPiA+IDEuMiBQQ1JzIG1heSBuZWVkIHRvIGJlIGRpc2FibGVkIG9yIGltcGxlbWVudGVkIGlu
IGFuIGFsdGVybmF0ZSBtYW5uZXINCj4gPiBzdWNoIGFzIGVtYmVkZGluZyB0aGUgZGF0YSBpbiB0
aGUgcXVvdGUgaW5zdGVhZCBvZiBpbiBQQ1JzLsKgIFRoZSBjdXJyZW50DQo+ID4gZGVzaWduIHdh
cyBjcmVhdGVkIHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCBzeXN0ZW1zIHVzaW5nIGl0IHdvdWxk
IGJlDQo+ID4gcGVyZm9ybWluZyBhIERSVE0gbGF1bmNoIGluIG9yZGVyIHRvIGZ1bGx5IHNlY3Vy
ZSB0aGUgYm9vdCBwcm9jZXNzLg0KPiA+DQo+ID4gPj4gSW4gbGludXgga2VybmVsIHRoaXMgaW5m
b3JtYXRpb24gaXMgb2J0YWluZWQgdXNpbmcgbG9jYWxpdHkgMCBhbmQNCj4gPiA+PiBhZnRlciB0
aGF0IG90aGVyIGNvbW1hbmRzIGV4ZWN1dGUgdXNpbmcgc3BlY2lmaWVkIGxvY2FsaXR5Lg0KPiA+
ID4+IGh0dHBzOi8vZ2l0Lmtlcm5lbC5vcmcvY2dpdC9saW51eC9rZXJuZWwvZ2l0L3N0YWJsZS9s
aW51eC1zdGFibGUuZ2l0Lw0KPiA+ID4+IHRyZWUvZHJpdmVycy9jaGFyL3RwbS90cG1fdGlzLmMj
bjU1OA0KPiA+DQo+ID4gSGF2ZSB5b3UgdGVzdGVkIHRoYXQgb3RoZXIgbG9jYWxpdGllcyB3b3Jr
IGZvciB5b3VyIFRQTSB1bmRlciBMaW51eD8NCj4gPg0KPiA+ID4+DQo+ID4gPj4gVGhhbmtzLA0K
PiA+ID4+DQo+ID4gPj4gRW1pbA0KPiA+ID4+DQo+ID4NCj4gPiAtLQ0KPiA+IERhbmllbCBEZSBH
cmFhZg0KPiA+IE5hdGlvbmFsIFNlY3VyaXR5IEFnZW5jeQ0KPiA+DQo+ID4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0DQo+ID4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcNCj4gPiBodHRwOi8vbGlzdHMueGVu
Lm9yZy94ZW4tZGV2ZWwNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QNCj4gWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcNCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsDQo=

--_002_945CA011AD5F084CBEA3E851C0AB28890E83A0E9SHSMSX101ccrcor_
Content-Type: application/octet-stream; name="txt-stat.log"
Content-Description: txt-stat.log
Content-Disposition: attachment; filename="txt-stat.log"; size=18250;
	creation-date="Sun, 16 Nov 2014 07:11:57 GMT";
	modification-date="Tue, 19 Feb 2008 00:22:04 GMT"
Content-Transfer-Encoding: base64

SW50ZWwocikgVFhUIENvbmZpZ3VyYXRpb24gUmVnaXN0ZXJzOgoJU1RTOiAweDAwMDE4MGQxCgkg
ICAgc2VudGVyX2RvbmU6IFRSVUUKCSAgICBzZXhpdF9kb25lOiBGQUxTRQoJICAgIG1lbV9jb25m
aWdfbG9jazogVFJVRQoJICAgIHByaXZhdGVfb3BlbjogVFJVRQoJICAgIGxvY2FsaXR5XzFfb3Bl
bjogVFJVRQoJICAgIGxvY2FsaXR5XzJfb3BlbjogVFJVRQoJRVNUUzogMHgwMAoJICAgIHR4dF9y
ZXNldDogRkFMU0UKCUUyU1RTOiAweDAwMDAwMDAwMDAwMDAwMTYKCSAgICBzZWNyZXRzOiBUUlVF
CglFUlJPUkNPREU6IDB4MDAwMDAwMDAKCURJRFZJRDogMHgwMDAwMDAwNzgwMDE4MDg2CgkgICAg
dmVuZG9yX2lkOiAweDgwODYKCSAgICBkZXZpY2VfaWQ6IDB4ODAwMQoJICAgIHJldmlzaW9uX2lk
OiAweDcKCUZTQklGOiAweDAwMDAwMDAwODAwMDEwMDAKCVFQSUlGOiAweDAwMDAwMDAwMDQ0YTEw
MDAKCVNJTklULkJBU0U6IDB4Y2Y0MDAwMDAKCVNJTklULlNJWkU6IDEzMTA3MkIgKDB4MjAwMDAp
CglIRUFQLkJBU0U6IDB4Y2Y0MjAwMDAKCUhFQVAuU0laRTogOTE3NTA0QiAoMHhlMDAwMCkKCURQ
UjogMHgwMDAwMDAwMGNmNTAwMDMxCgkgICAgbG9jazogVFJVRQoJICAgIHRvcDogMHhjZjUwMDAw
MAoJICAgIHNpemU6IDNNQiAoMzE0NTcyOEIpCglQVUJMSUMuS0VZOgoJICAgIDViIDFmIDcxIGM1
IGE1IGI1IDA5IGVjIGU1IDk1IDhlIDNiIDE3IDdjIDc2IGY5IAoJICAgIGI3IDE3IGNhIGI2IDAw
IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIAoKKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKCSBUWFQgbWVhc3VyZWQgbGF1
bmNoOiBUUlVFCgkgc2VjcmV0cyBmbGFnIHNldDogVFJVRQoqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUQk9PVCBsb2c6CgkgbWF4X3Np
emU9N2ZlOAoJIGN1cnJfcG9zPTQzNjEKCSBidWY6ClRCT09UOiAqKioqKioqKioqKioqKioqKioq
IFRCT09UICoqKioqKioqKioqKioqKioqKioKVEJPT1Q6ICAgIDIwMTMtMDctMDUgMTI6MDAgKzA4
MDAgMS43LjQKVEJPT1Q6ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKgpUQk9PVDogY29tbWFuZCBsaW5lOiBsb2dnaW5nPXZnYSxtZW1vcnksc2VyaWFsClRCT09U
OiBCU1AgaXMgY3B1IDAKVEJPT1Q6IG9yaWdpbmFsIGU4MjAgbWFwOgpUQk9PVDogCTAwMDAwMDAw
MDAwMDAwMDAgLSAwMDAwMDAwMDAwMDllYzAwICAoMSkKVEJPT1Q6IAkwMDAwMDAwMDAwMGYwMDAw
IC0gMDAwMDAwMDAwMDEwMDAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAw
MDAwY2YwZmY4MDAgICgxKQpUQk9PVDogCTAwMDAwMDAwY2YwZmY4MDAgLSAwMDAwMDAwMGNmMTUz
YzAwICAoNCkKVEJPT1Q6IAkwMDAwMDAwMGNmMTUzYzAwIC0gMDAwMDAwMDBjZjE1NWMwMCAgKDMp
ClRCT09UOiAJMDAwMDAwMDBjZjE1NWMwMCAtIDAwMDAwMDAwZDAwMDAwMDAgICgyKQpUQk9PVDog
CTAwMDAwMDAwZTAwMDAwMDAgLSAwMDAwMDAwMGYwMDAwMDAwICAoMikKVEJPT1Q6IAkwMDAwMDAw
MGZlYzAwMDAwIC0gMDAwMDAwMDBmZWQwMDQwMCAgKDIpClRCT09UOiAJMDAwMDAwMDBmZWQyMDAw
MCAtIDAwMDAwMDAwZmVkYTAwMDAgICgyKQpUQk9PVDogCTAwMDAwMDAwZmVlMDAwMDAgLSAwMDAw
MDAwMGZlZjAwMDAwICAoMikKVEJPT1Q6IAkwMDAwMDAwMGZmYjAwMDAwIC0gMDAwMDAwMDEwMDAw
MDAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAxMjgwMDAwMDAgICgx
KQpUQk9PVDogVFBNIGlzIHJlYWR5ClRCT09UOiBUUE0gbnZfbG9ja2VkOiBGQUxTRQpUQk9PVDog
VFBNIHRpbWVvdXQgdmFsdWVzOiBBOiA3NTAsIEI6IDc1MCwgQzogNzUwLCBEOiA3NTAKVEJPT1Q6
IFdyb25nIHRpbWVvdXQgQiwgZmFsbGJhY2sgdG8gMjAwMApUQk9PVDogcmVhZGluZyBWZXJpZmll
ZCBMYXVuY2ggUG9saWN5IGZyb20gVFBNIE5WLi4uClRCT09UOiBUUE06IGdldCBjYXBhYmlsaXR5
LCByZXR1cm4gdmFsdWUgPSAwMDAwMDAwMgpUQk9PVDogVFBNOiBmYWlsIHRvIGdldCBwdWJsaWMg
ZGF0YSBvZiAweDIwMDAwMDAxIGluIFRQTSBOVgpUQk9PVDogCTpyZWFkaW5nIGZhaWxlZApUQk9P
VDogcmVhZGluZyBMYXVuY2ggQ29udHJvbCBQb2xpY3kgZnJvbSBUUE0gTlYuLi4KVEJPT1Q6IFRQ
TTogZ2V0IGNhcGFiaWxpdHksIHJldHVybiB2YWx1ZSA9IDAwMDAwMDAyClRCT09UOiBUUE06IGZh
aWwgdG8gZ2V0IHB1YmxpYyBkYXRhIG9mIDB4NDAwMDAwMDEgaW4gVFBNIE5WClRCT09UOiAJOnJl
YWRpbmcgZmFpbGVkClRCT09UOiBmYWlsZWQgdG8gcmVhZCBwb2xpY3kgZnJvbSBUUE0gTlYsIHVz
aW5nIGRlZmF1bHQKVEJPT1Q6IHBvbGljeToKVEJPT1Q6IAkgdmVyc2lvbjogMgpUQk9PVDogCSBw
b2xpY3lfdHlwZTogVEJfUE9MVFlQRV9DT05UX05PTl9GQVRBTApUQk9PVDogCSBoYXNoX2FsZzog
VEJfSEFMR19TSEExClRCT09UOiAJIHBvbGljeV9jb250cm9sOiAwMDAwMDAwMSAoRVhURU5EX1BD
UjE3KQpUQk9PVDogCSBudW1fZW50cmllczogMgpUQk9PVDogCSBwb2xpY3kgZW50cnlbMF06ClRC
T09UOiAJCSBtb2RfbnVtOiAwClRCT09UOiAJCSBwY3I6IG5vbmUKVEJPT1Q6IAkJIGhhc2hfdHlw
ZTogVEJfSFRZUEVfQU5ZClRCT09UOiAJCSBudW1faGFzaGVzOiAwClRCT09UOiAJIHBvbGljeSBl
bnRyeVsxXToKVEJPT1Q6IAkJIG1vZF9udW06IGFueQpUQk9PVDogCQkgcGNyOiAxOQpUQk9PVDog
CQkgaGFzaF90eXBlOiBUQl9IVFlQRV9BTlkKVEJPT1Q6IAkJIG51bV9oYXNoZXM6IDAKVEJPT1Q6
IFRQTTogd3JpdGUgbnYgMjAwMDAwMDIsIG9mZnNldCAwMDAwMDAwMCwgMDAwMDAwMDQgYnl0ZXMs
IHJldHVybiA9IDAwMDAwMDAyClRCT09UOiBFcnJvcjogd3JpdGUgVFBNIGVycm9yOiAweDIuClRC
T09UOiBubyBwb2xpY3kgaW4gVFBNIE5WLgpUQk9PVDogSUEzMl9GRUFUVVJFX0NPTlRST0xfTVNS
OiAwMDAwZmYwMwpUQk9PVDogQ1BVIGlzIFNNWC1jYXBhYmxlClRCT09UOiBDUFUgaXMgVk1YLWNh
cGFibGUKVEJPT1Q6IFNNWCBpcyBlbmFibGVkClRCT09UOiBUWFQgY2hpcHNldCBhbmQgYWxsIG5l
ZWRlZCBjYXBhYmlsaXRpZXMgcHJlc2VudApUQk9PVDogVFhULkVSUk9SQ09ERTogMHgwClRCT09U
OiBUWFQuRVNUUzogMHgwClRCT09UOiBUWFQuRTJTVFM6IDB4MTQKVEJPT1Q6IElBMzJfRkVBVFVS
RV9DT05UUk9MX01TUjogMDAwMGZmMDMKVEJPT1Q6IENQVSBpcyBTTVgtY2FwYWJsZQpUQk9PVDog
Q1BVIGlzIFZNWC1jYXBhYmxlClRCT09UOiBTTVggaXMgZW5hYmxlZApUQk9PVDogVFhUIGNoaXBz
ZXQgYW5kIGFsbCBuZWVkZWQgY2FwYWJpbGl0aWVzIHByZXNlbnQKVEJPT1Q6IFRYVC5IRUFQLkJB
U0U6IDB4Y2Y0MjAwMDAKVEJPT1Q6IFRYVC5IRUFQLlNJWkU6IDB4ZTAwMDAgKDkxNzUwNCkKVEJP
T1Q6IGJpb3NfZGF0YSAoQDB4Y2Y0MjAwMDgsIDB4MjQpOgpUQk9PVDogCSB2ZXJzaW9uOiAyClRC
T09UOiAJIGJpb3Nfc2luaXRfc2l6ZTogMHgwICgwKQpUQk9PVDogCSBsY3BfcGRfYmFzZTogMHgw
ClRCT09UOiAJIGxjcF9wZF9zaXplOiAweDAgKDApClRCT09UOiAJIG51bV9sb2dpY2FsX3Byb2Nz
OiAyClRCT09UOiBDUjAuTkUgbm90IHNldApUQk9PVDogQ1IwIGFuZCBFRkxBR1MgT0sKVEJPT1Q6
IG5vIG1hY2hpbmUgY2hlY2sgZXJyb3JzClRCT09UOiBDUFUgaXMgcmVhZHkgZm9yIFNFTlRFUgpU
Qk9PVDogY2hlY2tpbmcgcHJldmlvdXMgZXJyb3JzIG9uIHRoZSBsYXN0IGJvb3QuCglUUE06IHJl
YWQgbnYgaW5kZXggMjAwMDAwMDIgb2Zmc2V0IDAwMDAwMDAwLCByZXR1cm4gdmFsdWUgPSAwMDAw
MDAwMgpUQk9PVDogRXJyb3I6IHJlYWQgVFBNIGVycm9yOiAweDIuClRCT09UOiBsYXN0IGJvb3Qg
aGFzIG5vIGVycm9yLgpUQk9PVDogY2hlY2tpbmcgaWYgbW9kdWxlICBpcyBhbiBTSU5JVCBmb3Ig
dGhpcyBwbGF0Zm9ybS4uLgpUQk9PVDogY2hpcHNldCBwcm9kdWN0aW9uIGZ1c2VkOiAxClRCT09U
OiBjaGlwc2V0IGlkczogdmVuZG9yOiAweDgwODYsIGRldmljZTogMHg4MDAxLCByZXZpc2lvbjog
MHg3ClRCT09UOiBwcm9jZXNzb3IgZmFtaWx5L21vZGVsL3N0ZXBwaW5nOiAweDZmYgpUQk9PVDog
cGxhdGZvcm0gaWQ6IDB4ODgwMDg4MmEKVEJPT1Q6IAkgMSBBQ00gY2hpcHNldCBpZCBlbnRyaWVz
OgpUQk9PVDogCSAgICAgdmVuZG9yOiAweDgwODYsIGRldmljZTogMHg4MDAxLCBmbGFnczogMHgx
LCByZXZpc2lvbjogMHg3LCBleHRlbmRlZDogMHgwClRCT09UOiBTSU5JVCBtYXRjaGVzIHBsYXRm
b3JtClRCT09UOiBUWFQuU0lOSVQuQkFTRTogMHhjZjQwMDAwMApUQk9PVDogVFhULlNJTklULlNJ
WkU6IDB4MjAwMDAgKDEzMTA3MikKVEJPT1Q6IGNvcGllZCBTSU5JVCAoc2l6ZT03YjQwKSB0byAw
eGNmNDAwMDAwClRCT09UOiBBQyBtb2QgYmFzZSBhbGlnbm1lbnQgT0sKVEJPT1Q6IEFDIG1vZCBz
aXplIE9LClRCT09UOiBBQyBtb2R1bGUgaGVhZGVyIGR1bXAgZm9yIFNJTklUOgpUQk9PVDogCSB0
eXBlOiAweDIgKEFDTV9UWVBFX0NISVBTRVQpClRCT09UOiAJIHN1YnR5cGU6IDB4MCAKVEJPT1Q6
IAkgbGVuZ3RoOiAweGExICgxNjEpClRCT09UOiAJIHZlcnNpb246IDAKVEJPT1Q6IAkgY2hpcHNl
dF9pZDogMHgyOWMwClRCT09UOiAJIGZsYWdzOiAweDAKVEJPT1Q6IAkJIHByZV9wcm9kdWN0aW9u
OiAwClRCT09UOiAJCSBkZWJ1Z19zaWduZWQ6IDAKVEJPT1Q6IAkgdmVuZG9yOiAweDgwODYKVEJP
T1Q6IAkgZGF0ZTogMHgyMDExMTEyMgpUQk9PVDogCSBzaXplKjQ6IDB4N2I0MCAoMzE1NTIpClRC
T09UOiAJIGNvZGVfY29udHJvbDogMHgwClRCT09UOiAJIGVudHJ5IHBvaW50OiAweDAwMDAwMDA4
OjAwMDA1MWY0ClRCT09UOiAJIHNjcmF0Y2hfc2l6ZTogMHg4ZiAoMTQzKQpUQk9PVDogCSBpbmZv
X3RhYmxlOgpUQk9PVDogCQkgdXVpZDogezB4N2ZjMDNhYWEsIDB4NDZhNywgMHgxOGRiLCAweGFj
MmUsCgkJezB4NjksIDB4OGYsIDB4OGQsIDB4NDEsIDB4N2YsIDB4NWF9fQpUQk9PVDogCQkgICAg
IEFDTV9VVUlEX1YzClRCT09UOiAJCSBjaGlwc2V0X2FjbV90eXBlOiAweDEgKFNJTklUKQpUQk9P
VDogCQkgdmVyc2lvbjogMwpUQk9PVDogCQkgbGVuZ3RoOiAweDI4ICg0MCkKVEJPT1Q6IAkJIGNo
aXBzZXRfaWRfbGlzdDogMHg0ZTgKVEJPT1Q6IAkJIG9zX3Npbml0X2RhdGFfdmVyOiAweDQKVEJP
T1Q6IAkJIG1pbl9tbGVfaGRyX3ZlcjogMHgwMDAyMDAwMApUQk9PVDogCQkgY2FwYWJpbGl0aWVz
OiAweDAwMDAwMDA2ClRCT09UOiAJCSAgICAgcmxwX3dha2VfZ2V0c2VjOiAwClRCT09UOiAJCSAg
ICAgcmxwX3dha2VfbW9uaXRvcjogMQpUQk9PVDogCQkgICAgIGVjeF9wZ3RibDogMQpUQk9PVDog
CQkgICAgIHBjcl9tYXBfbm9fbGVnYWN5OiAwClRCT09UOiAJCSAgICAgcGNyX21hcF9kYTogMApU
Qk9PVDogCQkgYWNtX3ZlcjogNTEKVEJPT1Q6IAkgY2hpcHNldCBsaXN0OgpUQk9PVDogCQkgY291
bnQ6IDEKVEJPT1Q6IAkJIGVudHJ5IDA6ClRCT09UOiAJCSAgICAgZmxhZ3M6IDB4MQpUQk9PVDog
CQkgICAgIHZlbmRvcl9pZDogMHg4MDg2ClRCT09UOiAJCSAgICAgZGV2aWNlX2lkOiAweDgwMDEK
VEJPT1Q6IAkJICAgICByZXZpc2lvbl9pZDogMHg3ClRCT09UOiAJCSAgICAgZXh0ZW5kZWRfaWQ6
IDB4MApUQk9PVDogZmlsZSBhZGRyZXNzZXM6ClRCT09UOiAJICZfc3RhcnQ9MHg4MDQwMDAKVEJP
T1Q6IAkgJl9lbmQ9MHg5NzRmMDgKVEJPT1Q6IAkgJl9tbGVfc3RhcnQ9MHg4MDQwMDAKVEJPT1Q6
IAkgJl9tbGVfZW5kPTB4ODI5MDAwClRCT09UOiAJICZfcG9zdF9sYXVuY2hfZW50cnk9MHg4MDQw
MTAKVEJPT1Q6IAkgJl90eHRfd2FrZXVwPTB4ODA0MWUwClRCT09UOiAJICZnX21sZV9oZHI9MHg4
MWFkYzAKVEJPT1Q6IE1MRSBoZWFkZXI6ClRCT09UOiAJIHV1aWQ9ezB4OTA4MmFjNWEsIDB4NDc2
ZiwgMHg3NGE3LCAweDVjMGYsCgkJezB4NTUsIDB4YTIsIDB4Y2IsIDB4NTEsIDB4YjYsIDB4NDJ9
fQpUQk9PVDogCSBsZW5ndGg9MzQKVEJPT1Q6IAkgdmVyc2lvbj0wMDAyMDAwMQpUQk9PVDogCSBl
bnRyeV9wb2ludD0wMDAwMDAxMApUQk9PVDogCSBmaXJzdF92YWxpZF9wYWdlPTAwMDAwMDAwClRC
T09UOiAJIG1sZV9zdGFydF9vZmY9NDAwMApUQk9PVDogCSBtbGVfZW5kX29mZj0yOTAwMApUQk9P
VDogCSBjYXBhYmlsaXRpZXM6IDB4MDAwMDAwMjcKVEJPT1Q6IAkgICAgIHJscF93YWtlX2dldHNl
YzogMQpUQk9PVDogCSAgICAgcmxwX3dha2VfbW9uaXRvcjogMQpUQk9PVDogCSAgICAgZWN4X3Bn
dGJsOiAxClRCT09UOiAJICAgICBwY3JfbWFwX25vX2xlZ2FjeTogMApUQk9PVDogCSAgICAgcGNy
X21hcF9kYTogMQpUQk9PVDogTUxFIHN0YXJ0PTgwNDAwMCwgZW5kPTgyOTAwMCwgc2l6ZT0yNTAw
MApUQk9PVDogcHRhYl9zaXplPTMwMDAsIHB0YWJfYmFzZT0weDgwMTAwMApUQk9PVDogVFhULkhF
QVAuQkFTRTogMHhjZjQyMDAwMApUQk9PVDogVFhULkhFQVAuU0laRTogMHhlMDAwMCAoOTE3NTA0
KQpUQk9PVDogYmlvc19kYXRhIChAMHhjZjQyMDAwOCwgMHgyNCk6ClRCT09UOiAJIHZlcnNpb246
IDIKVEJPT1Q6IAkgYmlvc19zaW5pdF9zaXplOiAweDAgKDApClRCT09UOiAJIGxjcF9wZF9iYXNl
OiAweDAKVEJPT1Q6IAkgbGNwX3BkX3NpemU6IDB4MCAoMCkKVEJPT1Q6IAkgbnVtX2xvZ2ljYWxf
cHJvY3M6IDIKVEJPT1Q6IG1pbl9sb19yYW06IDB4MCwgbWF4X2xvX3JhbTogMHhjZjBmZjgwMApU
Qk9PVDogbWluX2hpX3JhbTogMHgxMDAwMDAwMDAsIG1heF9oaV9yYW06IDB4MTI4MDAwMDAwClRC
T09UOiBubyBMQ1AgbW9kdWxlIGZvdW5kClRCT09UOiBvc19zaW5pdF9kYXRhIChAMHhjZjQzMTE0
YywgMHg1Yyk6ClRCT09UOiAJIHZlcnNpb246IDQKVEJPT1Q6IAkgbWxlX3B0YWI6IDB4ODAxMDAw
ClRCT09UOiAJIG1sZV9zaXplOiAweDI1MDAwICgxNTE1NTIpClRCT09UOiAJIG1sZV9oZHJfYmFz
ZTogMHgxNmRjMApUQk9PVDogCSB2dGRfcG1yX2xvX2Jhc2U6IDB4MApUQk9PVDogCSB2dGRfcG1y
X2xvX3NpemU6IDB4Y2YwMDAwMDAKVEJPT1Q6IAkgdnRkX3Btcl9oaV9iYXNlOiAweDEwMDAwMDAw
MApUQk9PVDogCSB2dGRfcG1yX2hpX3NpemU6IDB4MjgwMDAwMDAKVEJPT1Q6IAkgbGNwX3BvX2Jh
c2U6IDB4MApUQk9PVDogCSBsY3BfcG9fc2l6ZTogMHgwICgwKQpUQk9PVDogCSBjYXBhYmlsaXRp
ZXM6IDB4MDAwMDAwMDIKVEJPT1Q6IAkgICAgIHJscF93YWtlX2dldHNlYzogMApUQk9PVDogCSAg
ICAgcmxwX3dha2VfbW9uaXRvcjogMQpUQk9PVDogCSAgICAgZWN4X3BndGJsOiAwClRCT09UOiAJ
ICAgICBwY3JfbWFwX25vX2xlZ2FjeTogMApUQk9PVDogCSAgICAgcGNyX21hcF9kYTogMApUQk9P
VDogc2V0dGluZyBNVFJScyBmb3IgYWNtb2Q6IGJhc2U9MHhjZjQwMDAwMCwgc2l6ZT0weDdiNDAs
IG51bV9wYWdlcz04ClRCT09UOiBleGVjdXRpbmcgR0VUU0VDW1NFTlRFUl0uLi4KVEJPT1Q6ICoq
KioqKioqKioqKioqKioqKiogVEJPT1QgKioqKioqKioqKioqKioqKioqKgpUQk9PVDogICAgMjAx
My0wNy0wNSAxMjowMCArMDgwMCAxLjcuNApUQk9PVDogKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqClRCT09UOiBjb21tYW5kIGxpbmU6IGxvZ2dpbmc9dmdhLG1l
bW9yeSxzZXJpYWwKVEJPT1Q6IEJTUCBpcyBjcHUgMApUQk9PVDogb3JpZ2luYWwgZTgyMCBtYXA6
ClRCT09UOiAJMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWVjMDAgICgxKQpUQk9PVDog
CTAwMDAwMDAwMDAwZjAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwICAoMikKVEJPT1Q6IAkwMDAwMDAw
MDAwMTAwMDAwIC0gMDAwMDAwMDBjZjBmZjgwMCAgKDEpClRCT09UOiAJMDAwMDAwMDBjZjBmZjgw
MCAtIDAwMDAwMDAwY2YxNTNjMDAgICg0KQpUQk9PVDogCTAwMDAwMDAwY2YxNTNjMDAgLSAwMDAw
MDAwMGNmMTU1YzAwICAoMykKVEJPT1Q6IAkwMDAwMDAwMGNmMTU1YzAwIC0gMDAwMDAwMDBkMDAw
MDAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDBlMDAwMDAwMCAtIDAwMDAwMDAwZjAwMDAwMDAgICgy
KQpUQk9PVDogCTAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlZDAwNDAwICAoMikKVEJPT1Q6
IAkwMDAwMDAwMGZlZDIwMDAwIC0gMDAwMDAwMDBmZWRhMDAwMCAgKDIpClRCT09UOiAJMDAwMDAw
MDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVmMDAwMDAgICgyKQpUQk9PVDogCTAwMDAwMDAwZmZiMDAw
MDAgLSAwMDAwMDAwMTAwMDAwMDAwICAoMikKVEJPT1Q6IAkwMDAwMDAwMTAwMDAwMDAwIC0gMDAw
MDAwMDEyODAwMDAwMCAgKDEpClRCT09UOiBUUE0gaXMgcmVhZHkKVEJPT1Q6IFRQTSBudl9sb2Nr
ZWQ6IEZBTFNFClRCT09UOiBUUE0gdGltZW91dCB2YWx1ZXM6IEE6IDc1MCwgQjogNzUwLCBDOiA3
NTAsIEQ6IDc1MApUQk9PVDogV3JvbmcgdGltZW91dCBCLCBmYWxsYmFjayB0byAyMDAwClRCT09U
OiByZWFkaW5nIFZlcmlmaWVkIExhdW5jaCBQb2xpY3kgZnJvbSBUUE0gTlYuLi4KVEJPT1Q6IFRQ
TTogZ2V0IGNhcGFiaWxpdHksIHJldHVybiB2YWx1ZSA9IDAwMDAwMDAyClRCT09UOiBUUE06IGZh
aWwgdG8gZ2V0IHB1YmxpYyBkYXRhIG9mIDB4MjAwMDAwMDEgaW4gVFBNIE5WClRCT09UOiAJOnJl
YWRpbmcgZmFpbGVkClRCT09UOiByZWFkaW5nIExhdW5jaCBDb250cm9sIFBvbGljeSBmcm9tIFRQ
TSBOVi4uLgpUQk9PVDogVFBNOiBnZXQgY2FwYWJpbGl0eSwgcmV0dXJuIHZhbHVlID0gMDAwMDAw
MDIKVEJPT1Q6IFRQTTogZmFpbCB0byBnZXQgcHVibGljIGRhdGEgb2YgMHg0MDAwMDAwMSBpbiBU
UE0gTlYKVEJPT1Q6IAk6cmVhZGluZyBmYWlsZWQKVEJPT1Q6IGZhaWxlZCB0byByZWFkIHBvbGlj
eSBmcm9tIFRQTSBOViwgdXNpbmcgZGVmYXVsdApUQk9PVDogcG9saWN5OgpUQk9PVDogCSB2ZXJz
aW9uOiAyClRCT09UOiAJIHBvbGljeV90eXBlOiBUQl9QT0xUWVBFX0NPTlRfTk9OX0ZBVEFMClRC
T09UOiAJIGhhc2hfYWxnOiBUQl9IQUxHX1NIQTEKVEJPT1Q6IAkgcG9saWN5X2NvbnRyb2w6IDAw
MDAwMDAxIChFWFRFTkRfUENSMTcpClRCT09UOiAJIG51bV9lbnRyaWVzOiAyClRCT09UOiAJIHBv
bGljeSBlbnRyeVswXToKVEJPT1Q6IAkJIG1vZF9udW06IDAKVEJPT1Q6IAkJIHBjcjogbm9uZQpU
Qk9PVDogCQkgaGFzaF90eXBlOiBUQl9IVFlQRV9BTlkKVEJPT1Q6IAkJIG51bV9oYXNoZXM6IDAK
VEJPT1Q6IAkgcG9saWN5IGVudHJ5WzFdOgpUQk9PVDogCQkgbW9kX251bTogYW55ClRCT09UOiAJ
CSBwY3I6IDE5ClRCT09UOiAJCSBoYXNoX3R5cGU6IFRCX0hUWVBFX0FOWQpUQk9PVDogCQkgbnVt
X2hhc2hlczogMApUQk9PVDogVFBNOiB3cml0ZSBudiAyMDAwMDAwMiwgb2Zmc2V0IDAwMDAwMDAw
LCAwMDAwMDAwNCBieXRlcywgcmV0dXJuID0gMDAwMDAwMDIKVEJPT1Q6IEVycm9yOiB3cml0ZSBU
UE0gZXJyb3I6IDB4Mi4KVEJPT1Q6IG5vIHBvbGljeSBpbiBUUE0gTlYuClRCT09UOiBJQTMyX0ZF
QVRVUkVfQ09OVFJPTF9NU1I6IDAwMDBmZjAzClRCT09UOiBDUFUgaXMgU01YLWNhcGFibGUKVEJP
T1Q6IENQVSBpcyBWTVgtY2FwYWJsZQpUQk9PVDogU01YIGlzIGVuYWJsZWQKVEJPT1Q6IFRYVCBj
aGlwc2V0IGFuZCBhbGwgbmVlZGVkIGNhcGFiaWxpdGllcyBwcmVzZW50ClRCT09UOiBUWFQuRVJS
T1JDT0RFOiAweGMwMDAwMDAxClRCT09UOiBBQyBtb2R1bGUgZXJyb3IgOiBhY21fdHlwZT0weDEs
IHByb2dyZXNzPTB4MDAsIGVycm9yPTB4MApUQk9PVDogVFhULkVTVFM6IDB4MApUQk9PVDogVFhU
LkUyU1RTOiAweDE0ClRCT09UOiBJQTMyX0ZFQVRVUkVfQ09OVFJPTF9NU1I6IDAwMDBmZjAzClRC
T09UOiBDUFUgaXMgU01YLWNhcGFibGUKVEJPT1Q6IENQVSBpcyBWTVgtY2FwYWJsZQpUQk9PVDog
U01YIGlzIGVuYWJsZWQKVEJPT1Q6IFRYVCBjaGlwc2V0IGFuZCBhbGwgbmVlZGVkIGNhcGFiaWxp
dGllcyBwcmVzZW50ClRCT09UOiBUWFQuSEVBUC5CQVNFOiAweGNmNDIwMDAwClRCT09UOiBUWFQu
SEVBUC5TSVpFOiAweGUwMDAwICg5MTc1MDQpClRCT09UOiBiaW9zX2RhdGEgKEAweGNmNDIwMDA4
LCAweDI0KToKVEJPT1Q6IAkgdmVyc2lvbjogMgpUQk9PVDogCSBiaW9zX3Npbml0X3NpemU6IDB4
MCAoMCkKVEJPT1Q6IAkgbGNwX3BkX2Jhc2U6IDB4MApUQk9PVDogCSBsY3BfcGRfc2l6ZTogMHgw
ICgwKQpUQk9PVDogCSBudW1fbG9naWNhbF9wcm9jczogMgpUQk9PVDogbWVhc3VyZWQgbGF1bmNo
IHN1Y2NlZWRlZApUQk9PVDogVFhULkhFQVAuQkFTRTogMHhjZjQyMDAwMApUQk9PVDogVFhULkhF
QVAuU0laRTogMHhlMDAwMCAoOTE3NTA0KQpUQk9PVDogYmlvc19kYXRhIChAMHhjZjQyMDAwOCwg
MHgyNCk6ClRCT09UOiAJIHZlcnNpb246IDIKVEJPT1Q6IAkgYmlvc19zaW5pdF9zaXplOiAweDAg
KDApClRCT09UOiAJIGxjcF9wZF9iYXNlOiAweDAKVEJPT1Q6IAkgbGNwX3BkX3NpemU6IDB4MCAo
MCkKVEJPT1Q6IAkgbnVtX2xvZ2ljYWxfcHJvY3M6IDIKVEJPT1Q6IG9zX21sZV9kYXRhIChAMHhj
ZjQyMDAyYywgMHgxMTEyMCk6ClRCT09UOiAJIHZlcnNpb246IDMKVEJPT1Q6IAkgbWJpOiAweDEw
MDAwClRCT09UOiBvc19zaW5pdF9kYXRhIChAMHhjZjQzMTE0YywgMHg1Yyk6ClRCT09UOiAJIHZl
cnNpb246IDQKVEJPT1Q6IAkgbWxlX3B0YWI6IDB4ODAxMDAwClRCT09UOiAJIG1sZV9zaXplOiAw
eDI1MDAwICgxNTE1NTIpClRCT09UOiAJIG1sZV9oZHJfYmFzZTogMHgxNmRjMApUQk9PVDogCSB2
dGRfcG1yX2xvX2Jhc2U6IDB4MApUQk9PVDogCSB2dGRfcG1yX2xvX3NpemU6IDB4Y2YwMDAwMDAK
VEJPT1Q6IAkgdnRkX3Btcl9oaV9iYXNlOiAweDEwMDAwMDAwMApUQk9PVDogCSB2dGRfcG1yX2hp
X3NpemU6IDB4MjgwMDAwMDAKVEJPT1Q6IAkgbGNwX3BvX2Jhc2U6IDB4MApUQk9PVDogCSBsY3Bf
cG9fc2l6ZTogMHgwICgwKQpUQk9PVDogCSBjYXBhYmlsaXRpZXM6IDB4MDAwMDAwMDIKVEJPT1Q6
IAkgICAgIHJscF93YWtlX2dldHNlYzogMApUQk9PVDogCSAgICAgcmxwX3dha2VfbW9uaXRvcjog
MQpUQk9PVDogCSAgICAgZWN4X3BndGJsOiAwClRCT09UOiAJICAgICBwY3JfbWFwX25vX2xlZ2Fj
eTogMApUQk9PVDogCSAgICAgcGNyX21hcF9kYTogMApUQk9PVDogc2luaXRfbWxlX2RhdGEgKEAw
eGNmNDMxMWE4LCAweDI1OCk6ClRCT09UOiAJIHZlcnNpb246IDYKVEJPT1Q6IAkgYmlvc19hY21f
aWQ6IAoJODAgMDAgMDAgMDAgMjAgMDcgMDkgMTAgZmYgZmYgZmYgZmYgZmYgZmYgZmYgZmYgZmYg
ZmYgZmYgZmYgClRCT09UOiAJIGVkeF9zZW50ZXJfZmxhZ3M6IDB4MDAwMDAwMDAKVEJPT1Q6IAkg
bXNlZ192YWxpZDogMHgwClRCT09UOiAJIHNpbml0X2hhc2g6CgllYyBmNyA5OCBmNyA1OCA0YSA4
MSA5NiAwOCBiYyA5NiAyMyAwYiAxMyBlYyBkZiA4NCA1MiA0NyA0NyAKVEJPT1Q6IAkgbWxlX2hh
c2g6CgljMSA2YiA5OCBhOSA5MSA4YSA5YyA4YSAwZiBjNSA1NyBmZiA1YSBmZiBmMyAwYyAyNCA0
OSA5NyA2NCAKVEJPT1Q6IAkgc3RtX2hhc2g6CgkwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAKVEJPT1Q6IAkgbGNwX3BvbGljeV9oYXNo
OgoJMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgMDAgClRCT09UOiAJIGxjcF9wb2xpY3lfY29udHJvbDogMHgwMDAwMDAwMApUQk9PVDogCSBy
bHBfd2FrZXVwX2FkZHI6IDB4Y2Y0MDFhODAKVEJPT1Q6IAkgbnVtX21kcnM6IDcKVEJPT1Q6IAkg
bWRyc19vZmY6IDB4OTgKVEJPT1Q6IAkgbnVtX3Z0ZF9kbWFyczogMjgwClRCT09UOiAJIHZ0ZF9k
bWFyc19vZmY6IDB4MTQwClRCT09UOiAJIHNpbml0X21kcnM6ClRCT09UOiAJCSAwMDAwMDAwMDAw
MDAwMDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAoR09PRCkKVEJPT1Q6IAkJIDAwMDAwMDAwMDAxMDAw
MDAgLSAwMDAwMDAwMDAxMDAwMDAwIChHT09EKQpUQk9PVDogCQkgMDAwMDAwMDAwMTAwMDAwMCAt
IDAwMDAwMDAwY2Y0MDAwMDAgKEdPT0QpClRCT09UOiAJCSAwMDAwMDAwMTAwMDAwMDAwIC0gMDAw
MDAwMDEyYzAwMDAwMCAoR09PRCkKVEJPT1Q6IAkJIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAw
MTJjMDAwMDAwIChHT09EKQpUQk9PVDogCQkgMDAwMDAwMDBjZjUwMDAwMCAtIDAwMDAwMDAwY2Y2
MDAwMDAgKFNNUkFNIE5PTi1PVkVSTEFZKQpUQk9PVDogCQkgMDAwMDAwMDBlMDAwMDAwMCAtIDAw
MDAwMDAwZjAwMDAwMDAgKFBDSUUgRVhURU5ERUQgQ09ORklHKQpUQk9PVDogQ1BVIHN1cHBvcnRz
IDM2IHBoeXMgYWRkcmVzcyBiaXRzClRCT09UOiBSU0RQICh2MiwgREVMTCAgAk3FDykgQCAweDBm
ZWMwMApUQk9PVDogYWNwaV90YWJsZV9pb2FwaWMgQCAweGZjODRkLCAuYWRkcmVzcyA9IDB4ZmVj
MDAwMDAKVEJPT1Q6IGFjcGlfdGFibGVfbWNmZyBAIDB4ZmM5MzEsIC5iYXNlX2FkZHJlc3MgPSAw
eGUwMDAwMDAwClRCT09UOiBtdHJyX2RlZl90eXBlOiBlID0gMSwgZmUgPSAxLCB0eXBlID0gMApU
Qk9PVDogbXRycnM6ClRCT09UOiAJCSAgICBiYXNlICAgICAgICAgIG1hc2sgICAgICB0eXBlICB2
ClRCT09UOiAJCTAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMCAgMDYgIDAxClRCT09UOiAJCTAw
MDAwMDAwY2Y2MDAgMDAwMDAwMGZmZmUwMCAgMDAgIDAxClRCT09UOiAJCTAwMDAwMDAwY2Y4MDAg
MDAwMDAwMGZmZjgwMCAgMDAgIDAxClRCT09UOiAJCTAwMDAwMDAwY2Y1MDAgMDAwMDAwMGZmZmYw
MCAgMDAgIDAxClRCT09UOiAJCTAwMDAwMDAwZDAwMDAgMDAwMDAwMGZmMDAwMCAgMDAgIDAxClRC
T09UOiAJCTAwMDAwMDAwZTAwMDAgMDAwMDAwMGZlMDAwMCAgMDAgIDAxClRCT09UOiAJCTAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMCAgMDAgIDAwClRCT09UOiAJCTAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMCAgMDAgIDAwClRCT09UOiByZXNlcnZpbmcgMHhjZjAwMDAwMCAtIDB4Y2YwZmY4
MDAsIHdoaWNoIHdhcyB0cnVuY2F0ZWQgZm9yIFZULWQKVEJPT1Q6IG1pbl9sb19yYW06IDB4MCwg
bWF4X2xvX3JhbTogMHhjZjBmZjgwMApUQk9PVDogbWluX2hpX3JhbTogMHgxMDAwMDAwMDAsIG1h
eF9oaV9yYW06IDB4MTI4MDAwMDAwClRCT09UOiBNU1IgZm9yIFNNTSBtb25pdG9yIGNvbnRyb2wg
b24gQlNQIGlzIDB4MC4KVEJPT1Q6IHZlcmlmeWluZyBJTFAgaXMgb3B0LW91dCBvciBoYXMgdGhl
IHNhbWUgTVNFRyBoZWFkZXIgd2l0aCBUWFQuTVNFRy5CQVNFCgkJb3B0LW91dApUQk9PVDogIDog
c3VjY2VlZGVkLgpUQk9PVDogZW5hYmxpbmcgU01JcyBvbiBCU1AKVEJPT1Q6IG1sZV9qb2luLmVu
dHJ5X3BvaW50ID0gODA0MWUwClRCT09UOiBtbGVfam9pbi5zZWdfc2VsID0gOApUQk9PVDogbWxl
X2pvaW4uZ2R0X2Jhc2UgPSA4MDUwMDAKVEJPT1Q6IG1sZV9qb2luLmdkdF9saW1pdCA9IDNmClRC
T09UOiBqb2luaW5nIFJMUHMgdG8gTUxFIHdpdGggTU9OSVRPUiB3YWtldXAKVEJPT1Q6IHJscF93
YWtldXBfYWRkciA9IDB4Y2Y0MDFhODAKVEJPT1Q6IGNwdSAxIHdha2luZyB1cCBmcm9tIFRYVCBz
bGVlcApUQk9PVDogd2FpdGluZyBmb3IgYWxsIEFQcyAoMSkgdG8gZW50ZXIgd2FpdC1mb3Itc2lw
aS4uLgpUQk9PVDogTVNSIGZvciBTTU0gbW9uaXRvciBjb250cm9sIG9uIGNwdSAxIGlzIDB4MApU
Qk9PVDogdmVyaWZ5aW5nIElMUCdzIE1TUl9JQTMyX1NNTV9NT05JVE9SX0NUTCB3aXRoIGNwdSAx
CgkgOiBzdWNjZWVkZWQuClRCT09UOiBlbmFibGluZyBTTUlzIG9uIGNwdSAxClRCT09UOiAuVk1Y
T04gZG9uZSBmb3IgY3B1IDEKVEJPT1Q6IApUQk9PVDogbGF1bmNoaW5nIG1pbmktZ3Vlc3QgZm9y
IGNwdSAxClRCT09UOiAKVEJPT1Q6IGFsbCBBUHMgaW4gd2FpdC1mb3Itc2lwaQpUQk9PVDogc2F2
ZWQgSUEzMl9NSVNDX0VOQUJMRSA9IDB4NjI4NjIwODkKVEJPT1Q6IHNldCBUWFQuQ01ELlNFQ1JF
VFMgZmxhZwpUQk9PVDogb3BlbmVkIFRQTSBsb2NhbGl0eSAxClRCT09UOiBETUFSIHRhYmxlIEAg
MHhmY2JmZCBzYXZlZC4KVEJPT1Q6IG5vIExDUCBtb2R1bGUgZm91bmQKVEJPT1Q6IHZlcmlmeWlu
ZyBtb2R1bGUgMCBvZiBtYmkgKDEwNDAwMCAtIDJmMjVlYikgaW4gZTgyMCB0YWJsZQoJIChyYW5n
ZSBmcm9tIDAwMDAwMDAwMDAxMDQwMDAgdG8gMDAwMDAwMDAwMDJmMjVlYyBpcyBpbiBFODIwX1JB
TSkKVEJPT1Q6IDogc3VjY2VlZGVkLgpUQk9PVDogdmVyaWZ5aW5nIG1vZHVsZSAxIG9mIG1iaSAo
OTc1MDAwIC0gZWZmMmJmKSBpbiBlODIwIHRhYmxlCgkgKHJhbmdlIGZyb20gMDAwMDAwMDAwMDk3
NTAwMCB0byAwMDAwMDAwMDAwZWZmMmMwIGlzIGluIEU4MjBfUkFNKQpUQk9PVDogOiBzdWNjZWVk
ZWQuClRCT09UOiB2ZXJpZnlpbmcgbW9kdWxlIDIgb2YgbWJpIChmMDAwMDAgLSA0MmQwOWZmKSBp
biBlODIwIHRhYmxlCgkgKHJhbmdlIGZyb20gMDAwMDAwMDAwMGYwMDAwMCB0byAwMDAwMDAwMDA0
MmQwYTAwIGlzIGluIEU4MjBfUkFNKQpUQk9PVDogOiBzdWNjZWVkZWQuClRCT09UOiBwcm90ZWN0
aW5nIFRYVCBoZWFwIChjZjQyMDAwMCAtIGNmNGZmZmZmKSBpbiBlODIwIHRhYmxlClRCT09UOiBw
cm90ZWN0aW5nIFNJTklUIChjZjQwMDAwMCAtIGNmNDFmZmZmKSBpbiBlODIwIHRhYmxlClRCT09U
OiBwcm90ZWN0aW5nIFRYVCBQcml2YXRlIFNwYWNlIChmZWQyMDAwMCAtIGZlZDJmZmZmKSBpbiBl
ODIwIHRhYmxlClRCT09UOiB2ZXJpZnlpbmcgZTgyMCB0YWJsZSBhZ2FpbnN0IFNJTklUIE1EUnM6
IHZlcmlmaWNhdGlvbiBzdWNjZWVkZWQuClRCT09UOiB2ZXJpZnlpbmcgdGJvb3QgYW5kIGl0cyBw
YWdlIHRhYmxlICg4MDAwMDAgLSA5NzRmMDcpIGluIGU4MjAgdGFibGUKCSAocmFuZ2UgZnJvbSAw
MDAwMDAwMDAwODAwMDAwIHRvIDAwMDAwMDAwMDA5NzRmMDggaXMgaW4gRTgyMF9SQU0pClRCT09U
OiA6IHN1Y2NlZWRlZC4KVEJPT1Q6IHByb3RlY3RpbmcgdGJvb3QgKDgwMDAwMCAtIDk3NGZmZikg
aW4gZTgyMCB0YWJsZQpUQk9PVDogcmVzZXJ2aW5nIHRib290IG1lbW9yeSBsb2cgKDYwMDAwIC0g
NjdmZmYpIGluIGU4MjAgdGFibGUKVEJPT1Q6IGFkanVzdGVkIGU4MjAgbWFwOgpUQk9PVDogCTAw
MDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDYwMDAwICAoMSkKVEJPT1Q6IAkwMDAwMDAwMDAw
MDYwMDAwIC0gMDAwMDAwMDAwMDA2ODAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDAwMDA2ODAwMCAt
IDAwMDAwMDAwMDAwOWVjMDAgICgxKQpUQk9PVDogCTAwMDAwMDAwMDAwZjAwMDAgLSAwMDAwMDAw
MDAwMTAwMDAwICAoMikKVEJPT1Q6IAkwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDAwMDgwMDAw
MCAgKDEpClRCT09UOiAJMDAwMDAwMDAwMDgwMDAwMCAtIDAwMDAwMDAwMDA5NzUwMDAgICg1KQpU
Qk9PVDogCTAwMDAwMDAwMDA5NzUwMDAgLSAwMDAwMDAwMGNmMDAwMDAwICAoMSkKVEJPT1Q6IAkw
MDAwMDAwMGNmMDAwMDAwIC0gMDAwMDAwMDBjZjBmZjgwMCAgKDIpClRCT09UOiAJMDAwMDAwMDBj
ZjBmZjgwMCAtIDAwMDAwMDAwY2YxNTNjMDAgICg0KQpUQk9PVDogCTAwMDAwMDAwY2YxNTNjMDAg
LSAwMDAwMDAwMGNmMTU1YzAwICAoMykKVEJPT1Q6IAkwMDAwMDAwMGNmMTU1YzAwIC0gMDAwMDAw
MDBjZjQwMDAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDBjZjQwMDAwMCAtIDAwMDAwMDAwY2Y0MjAw
MDAgICgyKQpUQk9PVDogCTAwMDAwMDAwY2Y0MjAwMDAgLSAwMDAwMDAwMGNmNTAwMDAwICAoMikK
VEJPT1Q6IAkwMDAwMDAwMGNmNTAwMDAwIC0gMDAwMDAwMDBkMDAwMDAwMCAgKDIpClRCT09UOiAJ
MDAwMDAwMDBlMDAwMDAwMCAtIDAwMDAwMDAwZjAwMDAwMDAgICgyKQpUQk9PVDogCTAwMDAwMDAw
ZmVjMDAwMDAgLSAwMDAwMDAwMGZlZDAwNDAwICAoMikKVEJPT1Q6IAkwMDAwMDAwMGZlZDIwMDAw
IC0gMDAwMDAwMDBmZWQzMDAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDBmZWQzMDAwMCAtIDAwMDAw
MDAwZmVkYTAwMDAgICgyKQpUQk9PVDogCTAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZjAw
MDAwICAoMikKVEJPT1Q6IAkwMDAwMDAwMGZmYjAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAgKDIp
ClRCT09UOiAJMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAxMjgwMDAwMDAgICgxKQpUQk9PVDog
dmVyaWZ5aW5nIG1vZHVsZSAiCi94ZW4uZ3ogcGxhY2Vob2xkZXIiLi4uClRCT09UOiAJIE9LIDog
NGUgZmYgMDQgODMgOWQgYzggNjUgNGMgNGMgYWYgZmMgY2YgZDkgMzAgYjAgZDUgMTEgNzEgMGEg
ZDYgClRCT09UOiB2ZXJpZnlpbmcgbW9kdWxlICIKL3ZtbGludXotMy4xMy4wLTM3LWdlbmVyaWMg
cm9vdD0vZGV2L21hcHBlci94ZW4yLS12Zy1yb290IHJvIHF1aWV0IHNwbGFzaCB2dC5oYW4KZG9m
Zj03Ii4uLgpUQk9PVDogCSBPSyA6IDFiIGVlIDVhIDIxIGE5IDc0IGY2IGY0IDdjIDdlIDBlIDFj
IGE5IGIxIDlhIDI2IGU3IGU0IDMyIDk5IApUQk9PVDogdmVyaWZ5aW5nIG1vZHVsZSAiCi9pbml0
cmQuaW1nLTMuMTMuMC0zNy1nZW5lcmljIi4uLgpUQk9PVDogCSBPSyA6IGUyIDE3IDZhIDliIDI2
IDk5IGFmIDFkIGI4IDMzIGVhIGM0IGRmIGJkIDYyIGVkIDZhIDQ3IDc5IDNlIApUQk9PVDogYWxs
IG1vZHVsZXMgYXJlIHZlcmlmaWVkClRCT09UOiBwcmVfa19zM19zdGF0ZToKVEJPT1Q6IAkgdnRk
X3Btcl9sb19iYXNlOiAweDAKVEJPT1Q6IAkgdnRkX3Btcl9sb19zaXplOiAweGNmMDAwMDAwClRC
T09UOiAJIHZ0ZF9wbXJfaGlfYmFzZTogMHgxMDAwMDAwMDAKVEJPT1Q6IAkgdnRkX3Btcl9oaV9z
aXplOiAweDI4MDAwMDAwClRCT09UOiAJIHBvbF9oYXNoOiBhYiA0MSA2MiA0ZSA3ZCA3MSBmMCA2
OCBkNCA4ZSAxYyAyZiA0MyBlNiAxNiBiZiA0MCA2NyAxYyAzOSAKVEJPT1Q6IAkgVkwgbWVhc3Vy
ZW1lbnRzOgpUQk9PVDogCSAgIFBDUiAxNzogOTcgMDQgMzUgMzYgMzAgNjcgNGIgZmUgMjEgYjgg
NmIgNjQgYTcgYjAgZjkgOWMgMjkgN2MgZjkgMDIgClRCT09UOiAJICAgUENSIDE4OiA0ZSBmZiAw
NCA4MyA5ZCBjOCA2NSA0YyA0YyBhZiBmYyBjZiBkOSAzMCBiMCBkNSAxMSA3MSAwYSBkNiAKVEJP
T1Q6IAkgICBQQ1IgMTk6IDFiIGVlIDVhIDIxIGE5IDc0IGY2IGY0IDdjIDdlIDBlIDFjIGE5IGIx
IDlhIDI2IGU3IGU0IDMyIDk5IApUQk9PVDogCSAgIFBDUiAxOTogZTIgMTcgNmEgOWIgMjYgOTkg
YWYgMWQgYjggMzMgZWEgYzQgZGYgYmQgNjIgZWQgNmEgNDcgNzkgM2UgClRCT09UOiBUUE06IHN0
YXJ0IE9TQVAsIHJldHVybiB2YWx1ZSA9IDAwMDAwMDAzClRCT09UOiBmYWlsZWQgdG8gc2VhbCBk
YXRhClRCT09UOiBQQ1JzIGJlZm9yZSBleHRlbmRpbmc6ClRCT09UOiAgIFBDUiAxNzogMDQgOWQg
MTIgZTMgMWIgZjQgZWMgYTAgYTQgOTIgMWYgZWEgNTUgYTQgMTMgNzggOGYgYWUgNDUgMDIgClRC
T09UOiAgIFBDUiAxODogZGQgY2YgMmYgNDQgZmUgZmIgMjIgNTAgM2YgNzkgNTkgZDYgZjAgMTAg
MzEgZDYgYzUgYzAgYTggNjcgClRCT09UOiBQQ1JzIGFmdGVyIGV4dGVuZGluZzoKVEJPT1Q6ICAg
UENSIDE3OiBhMyBkOSA2MyA1MiBkMSA2ZiBhMSA4OSAxNCBmZSBjZSBjMSA3MyA2MSA1NiBmNSA4
NiAyYSA1NCA3MyAKVEJPT1Q6ICAgUENSIDE4OiBiZCBjNiBmNCA0MiAyMiAyMSA2MSAyNiBjMiA0
NyBhYyBjNSA3ZiA4MyA3YiA3YiA1NyBkMyBhYSA2MSAKVEJPT1Q6IGNyZWF0aW9uIG9yIHZlcmlm
aWNhdGlvbiBvZiBTMyBtZWFzdXJlbWVudHMgZmFpbGVkLgpUQk9PVDogdGJvb3Rfc2hhcmVkIGRh
dGE6ClRCT09UOiAJIHZlcnNpb246IDYKVEJPT1Q6IAkgbG9nX2FkZHI6IDB4MDAwNjAwMDAKVEJP
T1Q6IAkgc2h1dGRvd25fZW50cnk6IDB4MDA4MDQxYTAKVEJPT1Q6IAkgc2h1dGRvd25fdHlwZTog
MApUQk9PVDogCSB0Ym9vdF9iYXNlOiAweDAwODA0MDAwClRCT09UOiAJIHRib290X3NpemU6IDB4
MTcwZjA4ClRCT09UOiAJIG51bV9pbl93ZnM6IDEKVEJPT1Q6IAkgZmxhZ3M6IDB4MDAwMDAwMDAK
VEJPT1Q6IAkgYXBfd2FrZV9hZGRyOiAweDAwMDAwMDAwClRCT09UOiAJIGFwX3dha2VfdHJpZ2dl
cjogMApUQk9PVDogbm8gTENQIG1vZHVsZSBmb3VuZApUQk9PVDoga2VybmVsIGlzIEVMRiBmb3Jt
YXQKVEJPT1Q6IDB4NmZjMDAwIGJ5dGVzIGNvcGllZCBmcm9tIDB4MTA0MDAwIHRvIDB4NDJkMTAw
MApUQk9PVDogdHJhbnNmZXJpbmcgY29udHJvbCB0byBrZXJuZWwgQDB4MTAwMDAwLi4uClRCT09U
OiBWTVhPRkYgZG9uZSBmb3IgY3B1IDEKVEJPT1Q6IGNwdSAxIHdha2luZyB1cCwgU0lQSSB2ZWN0
b3I9OGUwMDAKCg==

--_002_945CA011AD5F084CBEA3E851C0AB28890E83A0E9SHSMSX101ccrcor_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_945CA011AD5F084CBEA3E851C0AB28890E83A0E9SHSMSX101ccrcor_--


From xen-devel-bounces@lists.xen.org Sun Nov 16 07:15:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 07:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpu3Q-0000lr-I9; Sun, 16 Nov 2014 07:15:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xpu3P-0000lm-0J
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 07:15:23 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	54/4F-26858-A0F48645; Sun, 16 Nov 2014 07:15:22 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416122118!11688559!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29409 invoked from network); 16 Nov 2014 07:15:19 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-31.messagelabs.com with SMTP;
	16 Nov 2014 07:15:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 15 Nov 2014 23:15:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,396,1413270000"; 
	d="log'?scan'208";a="637687361"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 15 Nov 2014 23:15:15 -0800
Received: from pgsmsx107.gar.corp.intel.com (10.221.44.105) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Sun, 16 Nov 2014 15:15:14 +0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Sun, 16 Nov 2014 15:15:14 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Sun, 16 Nov 2014 15:15:12 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Emil Condrea <emilcondrea@gmail.com>, Daniel De Graaf
	<dgdegra@tycho.nsa.gov>
Thread-Topic: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
Thread-Index: AQHP+gyQogoroHdVBUOna8rL71CGzpxUYzsQgAARkYCAA4WJQIAK6YvQ
Date: Sun, 16 Nov 2014 07:15:11 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E83A0E9@SHSMSX101.ccr.corp.intel.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>	<545BEE4F.3080305@tycho.nsa.gov>
	<945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
	<CAAULxKL+z_p_JcN5pBySiQzRBP5Jc-2w+oRcg81jgkTshAQDiw@mail.gmail.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8278EA@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E8278EA@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_945CA011AD5F084CBEA3E851C0AB28890E83A0E9SHSMSX101ccrcor_"
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, "Xu, Quan" <quan.xu@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_945CA011AD5F084CBEA3E851C0AB28890E83A0E9SHSMSX101ccrcor_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RW1pbCAvIEdyYWFmLA0KCUkgaGF2ZSB2ZXJpZmllZCBpdCwgaXQgaXMgc3RpbGwgbm90IHdvcmtp
bmcgd2hlbiB0Ym9vdCBpcyBlbmFibGVkLiANClRoZSBhdHRhY2ggZmlsZSBpcyB0eHQtc3RhdCBs
b2cuIA0KWy4uLl0NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioNCiAgICAgICAgIFRYVCBtZWFzdXJlZCBsYXVuY2g6IFRSVUUNCiAg
ICAgICAgIHNlY3JldHMgZmxhZyBzZXQ6IFRSVUUNCioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpbLi4uXQ0KDQoNCkJlbG93IGlzIGVy
cm9yIHdoZW4gSSBib290IHZ0cG1tZ3I6DQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KWy4uLl0NCklPTUVNIE1hY2hpbmUgQmFz
ZSBBZGRyZXNzOiBGRUQ0MDAwMA0KRW5hYmxlZCBMb2NhbGl0aWVzOiAyDQpSRVEgTE9DQUxJVFkg
RkFJTFVSRQ0KVW5hYmxlIHRvIHJlcXVlc3QgbG9jYWxpdHkgMj8/DQpTaHV0dGluZyBkb3duIHRw
bV90aXMgZGV2aWNlDQpQYWdlIGZhdWx0IGF0IGxpbmVhciBhZGRyZXNzIDB4ZmVkNDAwMDgsIHJp
cCAweDJmOTE4LCByZWdzIDB4MTBmYzc4LCBzcCAweDEwZmQyMCwgb3VyX3NwIDB4MTBmYzQwLCBj
b2RlIDINClRocmVhZDogbWFpbg0KUklQOiBlMDMwOls8MDAwMDAwMDAwMDAyZjkxOD5dDQpSU1A6
IGUwMmI6MDAwMDAwMDAwMDEwZmQyMCAgRUZMQUdTOiAwMDAxMDIwMg0KUkFYOiBmZmZmZmZmZmZm
ZmZmZmZmIFJCWDogMDAwMDAwMjAwMDgwNGM2MCBSQ1g6IDAwMDAwMDAwMDAwMDA3MmMNClJEWDog
MDAwMDAwMDAwMDAwMDAxZSBSU0k6IDAwMDAwMDAwN2ZmZmZmZmYgUkRJOiAwMDAwMDAwMGZlZDQw
MDA4DQpSQlA6IDAwMDAwMDAwMDAxMGZkMjAgUjA4OiAwMDAwMDAwMDAwMDAwMDBhIFIwOTogMDAw
MDAwMDAwMDBhZjAwMA0KUjEwOiAwMDAwMDAwMDAwMDAwNzBlIFIxMTogMDAwMDAwMDAwMDAwMDZk
OCBSMTI6IDAwMDAwMDIwMDA4MDRjNjANClIxMzogMDAwMDAwMDBmZWQ0MjAwMCBSMTQ6IDAwMDAw
MDAwMDAwMDAwMDAgUjE1OiAwMDAwMDAwMDAwMDAwMDAyDQpiYXNlIGlzIDB4MTBmZDIwIGNhbGxl
ciBpcyAweDI0OTc3DQpiYXNlIGlzIDB4MTBmZDQwIGNhbGxlciBpcyAweDI0ZTMyDQpiYXNlIGlz
IDB4MTBmZDgwIGNhbGxlciBpcyAweDViNGINCmJhc2UgaXMgMHgxMGZmMzAgY2FsbGVyIGlzIDB4
MzUxMA0KYmFzZSBpcyAweDEwZmY1MCBjYWxsZXIgaXMgMHgyODdhMg0KYmFzZSBpcyAweDEwZmZl
MCBjYWxsZXIgaXMgMHgzNDNiDQoNCjEwZmQxMDogMjAgZmQgMTAgMDAgMDAgMDAgMDAgMDAgMmIg
ZTAgMDAgMDAgMDAgMDAgMDAgMDANCjEwZmQyMDogNDAgZmQgMTAgMDAgMDAgMDAgMDAgMDAgNzcg
NDkgMDIgMDAgMDAgMDAgMDAgMDANCjEwZmQzMDogNjAgNGMgODAgMDAgMjAgMDAgMDAgMDAgMDIg
MDAgMDAgMDAgMDAgMDAgMDAgMDANCjEwZmQ0MDogODAgZmQgMTAgMDAgMDAgMDAgMDAgMDAgMzIg
NGUgMDIgMDAgMDAgMDAgMDAgMDANCg0KMTBmZDEwOiAyMCBmZCAxMCAwMCAwMCAwMCAwMCAwMCAy
YiBlMCAwMCAwMCAwMCAwMCAwMCAwMA0KMTBmZDIwOiA0MCBmZCAxMCAwMCAwMCAwMCAwMCAwMCA3
NyA0OSAwMiAwMCAwMCAwMCAwMCAwMA0KMTBmZDMwOiA2MCA0YyA4MCAwMCAyMCAwMCAwMCAwMCAw
MiAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KMTBmZDQwOiA4MCBmZCAxMCAwMCAwMCAwMCAwMCAwMCAz
MiA0ZSAwMiAwMCAwMCAwMCAwMCAwMA0KDQoyZjkwMDogNWQgYzMgNTUgNDggODkgZTUgNDAgODgg
MzcgNWQgYzMgNTUgNDggODkgZTUgNjYNCjJmOTEwOiA4OSAzNyA1ZCBjMyA1NSA0OCA4OSBlNSA4
OSAzNyA1ZCBjMyA1NSA0OCA4OSBlNQ0KMmY5MjA6IDQ4IDg5IDM3IDVkIGMzIDU1IDQ4IDg5IGU1
IDBmIGI2IDA3IDVkIGMzIDU1IDQ4DQoyZjkzMDogODkgZTUgMGYgYjcgMDcgNWQgYzMgNTUgNDgg
ODkgZTUgOGIgMDcgNWQgYzMgNTUNClBhZ2V0YWJsZSB3YWxrIGZyb20gdmlydCBmZWQ0MDAwOCwg
YmFzZSBiMDAwMDoNCiBMNCA9IDAwMDAwMDAxMjcwMzMwNjcgKDB4YjEwMDApICBbb2Zmc2V0ID0g
MF0NCiAgTDMgPSAwMDAwMDAwMDAwMDAwMDAwICgweGZmZmZmZmZmZmZmZmYwMDApICBbb2Zmc2V0
ID0gM10NClBhZ2UgZmF1bHQgaW4gcGFnZXRhYmxlIHdhbGsgKGFjY2VzcyB0byBpbnZhbGlkIG1l
bW9yeT8pLg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KiogDQoNClRoYW5rcyANClF1YW4gWHUNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+IEZyb206IHhlbi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbi5vcmcNCj4gW21haWx0bzp4ZW4t
ZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnXSBPbiBCZWhhbGYgT2YgWHUsIFF1YW4NCj4gU2Vu
dDogU3VuZGF5LCBOb3ZlbWJlciAwOSwgMjAxNCA0OjMwIFBNDQo+IFRvOiBFbWlsIENvbmRyZWEN
Cj4gQ2M6IERhbmllbCBEZSBHcmFhZjsgSWFuIENhbXBiZWxsOyB4ZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1hlbi1kZXZlbF0gdnRwbW1nciBidWc6IGZhaWxzIHRvIHN0
YXJ0IGlmIGxvY2FsaXR5IT0wDQo+IA0KPiBPa2F5LCBJIHdpbGwgdGVzdCBpdCBpbiBuZXh0IHdl
ZWsuDQo+IA0KPiBUaGFua3MNCj4gUXVhbiBYdQ0KPiANCj4gDQo+IEZyb206IHhlbi1kZXZlbC1i
b3VuY2VzQGxpc3RzLnhlbi5vcmcNCj4gW21haWx0bzp4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54
ZW4ub3JnXSBPbiBCZWhhbGYgT2YgRW1pbCBDb25kcmVhDQo+IFNlbnQ6IEZyaWRheSwgTm92ZW1i
ZXIgMDcsIDIwMTQgNjo0MiBQTQ0KPiBUbzogWHUsIFF1YW4NCj4gQ2M6IERhbmllbCBEZSBHcmFh
ZjsgSWFuIENhbXBiZWxsOyB4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZw0KPiBTdWJqZWN0OiBSZTog
W1hlbi1kZXZlbF0gdnRwbW1nciBidWc6IGZhaWxzIHRvIHN0YXJ0IGlmIGxvY2FsaXR5IT0wDQo+
IA0KPiBYdSwgbXkgc3lzdGVtIGRvZXMgbm90IHN1cHBvcnQgRFJUTSBsYXVuY2ggc28gaWYgeW91
IGNhbiB0ZXN0IGl0IG5leHQgd2Vlaw0KPiBpdCB3b3VsZCBiZSBncmVhdC4NCj4gVGhhbmtzDQo+
IA0KPiBPbiBGcmksIE5vdiA3LCAyMDE0IGF0IDM6NDYgQU0sIFh1LCBRdWFuIDxxdWFuLnh1QGlu
dGVsLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiA+IEZyb206IHhlbi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbi5vcmcNCj4gPiBbbWFpbHRvOnhl
bi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbi5vcmddIE9uIEJlaGFsZiBPZiBEYW5pZWwgRGUgR3Jh
YWYNCj4gPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDA3LCAyMDE0IDU6NTUgQU0NCj4gPiBUbzog
RW1pbCBDb25kcmVhDQo+ID4gQ2M6IElhbiBDYW1wYmVsbDsgeGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcNCj4gPiBTdWJqZWN0OiBSZTogW1hlbi1kZXZlbF0gdnRwbW1nciBidWc6IGZhaWxzIHRvIHN0
YXJ0IGlmIGxvY2FsaXR5IT0wDQo+ID4NCj4gPiBPbiAxMS8wNS8yMDE0IDA1OjAwIEFNLCBJYW4g
Q2FtcGJlbGwgd3JvdGU6DQo+ID4gPiBDQ2luZyBEYW5pZWwuDQo+ID4gPg0KPiA+ID4gT24gRnJp
LCAyMDE0LTEwLTMxIGF0IDE3OjM3ICswMjAwLCBFbWlsIENvbmRyZWEgd3JvdGU6DQo+ID4gPj4N
Cj4gPiA+PiBJIGFtIHdvbmRlcmluZyBpZiB0aGlzIGlzIGtub3duIGlzc3VlIHRoYXQgd2hlbiBJ
IHNldCBsb2NhbGl0eSE9MCB0bw0KPiA+ID4+IHZ0cG1tZ3IgaXQgZG9lcyBub3Qgc3RhcnQuIEl0
IGlzIGEgYml0IHN0cmFuZ2UgdGhhdCBldmVyeSBjYWxsIHRvDQo+ID4gPj4gdHBtX3Rpc19zdGF0
dXMgcmV0dXJucyAyNTUgYW5kIGRldmljZS1pZCBpcyBhbHNvIEZGRkY6DQo+ID4gPj4gMS4yIFRQ
TSAoZGV2aWNlLWlkPTB4RkZGRiB2ZW5kb3ItaWQgPSBGRkZGIHJldi1pZCA9IEZGKS4NCj4gPiA+
PiBUUE0gaW50ZXJmYWNlIGNhcGFiaWxpdGllcyAoMHhmZmZmZmZmZik6DQo+ID4gPj4NCj4gPiA+
PiBJIGFtIGNvbmZpZ3VyaW5nIHZ0cG1tZ3IgdXNpbmc6DQo+ID4gPj4NCj4gPiA+PiBrZXJuZWw9
Ii91c3IvbG9jYWwvbGliL3hlbi9ib290L3Z0cG1tZ3Itc3R1YmRvbS5neiINCj4gPiA+PiBtZW1v
cnk9OA0KPiA+ID4+IGRpc2s9WyJmaWxlOi92YXIvdnRwbW1nci1zdHViZG9tLmltZyxoZGEsdyJd
DQo+ID4gPj4gbmFtZT0idnRwbW1nciINCj4gPiA+PiBpb21lbT1bImZlZDQwLDUiXQ0KPiA+ID4+
IGV4dHJhPSJ0cG1sb2NhbGl0eT0yIg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiBJIGFsc28gdHJp
ZWQgdXNpbmcgOg0KPiA+ID4+IGlvbWVtPVsiZmVkNDAsMSJdDQo+ID4gPj4gZXh0cmE9InRwbWxv
Y2FsaXR5PTAiLy93b3JrcyB3ZWxsDQo+ID4gPj4NCj4gPiA+PiBvcg0KPiA+ID4+IGlvbWVtPVsi
ZmVkNDIsMSJdDQo+ID4gPj4gZXh0cmE9InRwbWxvY2FsaXR5PTIiDQo+ID4gPj4gSXQgc2VlbXMg
dGhhdCBldmVyeXRoaW5nIHRoYXQgaXMgbm90IG1hcHBlZCBhdCBmZWQ0MC1mZWQ0MSBpcw0KPiA+
ID4+IEZGRkZGRkZGLg0KPiA+ID4+DQo+ID4gPj4gSSBoYXZlIGFuIEF0bWVsIFRQTSBjaGlwc2V0
Lg0KPiA+ID4+DQo+ID4gPj4gQ291bGQgaXQgYmUgYSBjaGlwc2V0IHByb2JsZW0gdG8gbm90IGhh
bmRsZSB3ZWxsIGRpZmZlcmVudCBsb2NhbGl0aWVzPw0KPiA+ID4+DQo+ID4gPj4gV2hlbiBJIHVz
ZSBsb2NhbGl0eT0wLCB0aGUgZGV2aWNlIGRyaXZlciBpbmZvIGlzIGNvcnJlY3QgYW5kDQo+ID4g
Pj4gZXZlcnl0aGluZyB3b3JrcyBmaW5lOg0KPiA+ID4+IDEuMiBUUE0gKGRldmljZS1pZD0weDMy
MDQgdmVuZG9yLWlkID0gMTExNCByZXYtaWQgPSA0MCkgVFBNIGludGVyZmFjZQ0KPiA+ID4+IGNh
cGFiaWxpdGllcyAoMHhmZCkNCj4gPg0KPiA+IFRoaXMgbWF5IGJlIGFuIGlzc3VlIHdpdGggbG9j
YWxpdHkgMiBiZWluZyB1bmF2YWlsYWJsZSB1bmxlc3MgYSBEUlRNDQo+IGxhdW5jaA0KPiA+ICh0
Ym9vdCkgaXMgcGVyZm9ybWVkLsKgIFJldHVybmluZyBhbGwtb25lcyBpcyB0aGUgbm9ybWFsIHJl
c3BvbnNlIG9mIHRoZQ0KPiB4ODYNCj4gPiBjaGlwc2V0IHdoZW4gdW5tYXBwZWQgTU1JTyByZWdp
b25zIGFyZSBhY2Nlc3NlZDsgZGlzYWJsZWQgbG9jYWxpdGllcyBvZg0KPiA+IHRoZSBUUE0gbWF5
IGFjdCBsaWtlIHRoaXMuDQo+ID4NCj4gPiBEb2VzIHlvdXIgc3lzdGVtIHN1cHBvcnQgdGhlIERS
VE0gbGF1bmNoP8KgIElmIHNvLCBjYW4geW91IHRlc3QgaXQgdG8gc2VlDQo+IGlmDQo+ID4gdGhp
cyBpcyB0aGUgaXNzdWU/DQo+IA0KPiBFbWlsLA0KPiB0Ym9vdCBzdXBwb3J0cyBJbnRlbCBhbmQg
T0VNIHN5c3RlbXMgdGhhdCBhcmUgSW50ZWwgVFhULWNhcGFibGUuDQo+IElmIHlvdXIgc3lzdGVt
IGRvZXMgbm90IHN1cHBvcnQgRFJUTSBsYXVuY2gsIEkgY2FuIHRlc3QgaXQgaW4gbmV4dCB3ZWVr
Lg0KPiANCj4gDQo+ID4NCj4gPiBJbiB0aGlzIGNhc2UsIHRvIGJldHRlciBzdXBwb3J0IHBlb3Bs
ZSB3aG8gd2FudCB0byB1c2UgdGhlIHZUUE0gTWFuYWdlcg0KPiA+IHdpdGhvdXQgYSBEUlRNIGxh
dW5jaCwgdGhlIGZlYXR1cmVzIG9mIHRoZSB2VFBNIE1hbmFnZXIgdGhhdCB1c2UgdGhlDQo+IFRQ
TQ0KPiA+IDEuMiBQQ1JzIG1heSBuZWVkIHRvIGJlIGRpc2FibGVkIG9yIGltcGxlbWVudGVkIGlu
IGFuIGFsdGVybmF0ZSBtYW5uZXINCj4gPiBzdWNoIGFzIGVtYmVkZGluZyB0aGUgZGF0YSBpbiB0
aGUgcXVvdGUgaW5zdGVhZCBvZiBpbiBQQ1JzLsKgIFRoZSBjdXJyZW50DQo+ID4gZGVzaWduIHdh
cyBjcmVhdGVkIHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCBzeXN0ZW1zIHVzaW5nIGl0IHdvdWxk
IGJlDQo+ID4gcGVyZm9ybWluZyBhIERSVE0gbGF1bmNoIGluIG9yZGVyIHRvIGZ1bGx5IHNlY3Vy
ZSB0aGUgYm9vdCBwcm9jZXNzLg0KPiA+DQo+ID4gPj4gSW4gbGludXgga2VybmVsIHRoaXMgaW5m
b3JtYXRpb24gaXMgb2J0YWluZWQgdXNpbmcgbG9jYWxpdHkgMCBhbmQNCj4gPiA+PiBhZnRlciB0
aGF0IG90aGVyIGNvbW1hbmRzIGV4ZWN1dGUgdXNpbmcgc3BlY2lmaWVkIGxvY2FsaXR5Lg0KPiA+
ID4+IGh0dHBzOi8vZ2l0Lmtlcm5lbC5vcmcvY2dpdC9saW51eC9rZXJuZWwvZ2l0L3N0YWJsZS9s
aW51eC1zdGFibGUuZ2l0Lw0KPiA+ID4+IHRyZWUvZHJpdmVycy9jaGFyL3RwbS90cG1fdGlzLmMj
bjU1OA0KPiA+DQo+ID4gSGF2ZSB5b3UgdGVzdGVkIHRoYXQgb3RoZXIgbG9jYWxpdGllcyB3b3Jr
IGZvciB5b3VyIFRQTSB1bmRlciBMaW51eD8NCj4gPg0KPiA+ID4+DQo+ID4gPj4gVGhhbmtzLA0K
PiA+ID4+DQo+ID4gPj4gRW1pbA0KPiA+ID4+DQo+ID4NCj4gPiAtLQ0KPiA+IERhbmllbCBEZSBH
cmFhZg0KPiA+IE5hdGlvbmFsIFNlY3VyaXR5IEFnZW5jeQ0KPiA+DQo+ID4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0DQo+ID4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcNCj4gPiBodHRwOi8vbGlzdHMueGVu
Lm9yZy94ZW4tZGV2ZWwNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QNCj4gWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcNCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsDQo=

--_002_945CA011AD5F084CBEA3E851C0AB28890E83A0E9SHSMSX101ccrcor_
Content-Type: application/octet-stream; name="txt-stat.log"
Content-Description: txt-stat.log
Content-Disposition: attachment; filename="txt-stat.log"; size=18250;
	creation-date="Sun, 16 Nov 2014 07:11:57 GMT";
	modification-date="Tue, 19 Feb 2008 00:22:04 GMT"
Content-Transfer-Encoding: base64

SW50ZWwocikgVFhUIENvbmZpZ3VyYXRpb24gUmVnaXN0ZXJzOgoJU1RTOiAweDAwMDE4MGQxCgkg
ICAgc2VudGVyX2RvbmU6IFRSVUUKCSAgICBzZXhpdF9kb25lOiBGQUxTRQoJICAgIG1lbV9jb25m
aWdfbG9jazogVFJVRQoJICAgIHByaXZhdGVfb3BlbjogVFJVRQoJICAgIGxvY2FsaXR5XzFfb3Bl
bjogVFJVRQoJICAgIGxvY2FsaXR5XzJfb3BlbjogVFJVRQoJRVNUUzogMHgwMAoJICAgIHR4dF9y
ZXNldDogRkFMU0UKCUUyU1RTOiAweDAwMDAwMDAwMDAwMDAwMTYKCSAgICBzZWNyZXRzOiBUUlVF
CglFUlJPUkNPREU6IDB4MDAwMDAwMDAKCURJRFZJRDogMHgwMDAwMDAwNzgwMDE4MDg2CgkgICAg
dmVuZG9yX2lkOiAweDgwODYKCSAgICBkZXZpY2VfaWQ6IDB4ODAwMQoJICAgIHJldmlzaW9uX2lk
OiAweDcKCUZTQklGOiAweDAwMDAwMDAwODAwMDEwMDAKCVFQSUlGOiAweDAwMDAwMDAwMDQ0YTEw
MDAKCVNJTklULkJBU0U6IDB4Y2Y0MDAwMDAKCVNJTklULlNJWkU6IDEzMTA3MkIgKDB4MjAwMDAp
CglIRUFQLkJBU0U6IDB4Y2Y0MjAwMDAKCUhFQVAuU0laRTogOTE3NTA0QiAoMHhlMDAwMCkKCURQ
UjogMHgwMDAwMDAwMGNmNTAwMDMxCgkgICAgbG9jazogVFJVRQoJICAgIHRvcDogMHhjZjUwMDAw
MAoJICAgIHNpemU6IDNNQiAoMzE0NTcyOEIpCglQVUJMSUMuS0VZOgoJICAgIDViIDFmIDcxIGM1
IGE1IGI1IDA5IGVjIGU1IDk1IDhlIDNiIDE3IDdjIDc2IGY5IAoJICAgIGI3IDE3IGNhIGI2IDAw
IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIAoKKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKCSBUWFQgbWVhc3VyZWQgbGF1
bmNoOiBUUlVFCgkgc2VjcmV0cyBmbGFnIHNldDogVFJVRQoqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUQk9PVCBsb2c6CgkgbWF4X3Np
emU9N2ZlOAoJIGN1cnJfcG9zPTQzNjEKCSBidWY6ClRCT09UOiAqKioqKioqKioqKioqKioqKioq
IFRCT09UICoqKioqKioqKioqKioqKioqKioKVEJPT1Q6ICAgIDIwMTMtMDctMDUgMTI6MDAgKzA4
MDAgMS43LjQKVEJPT1Q6ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKgpUQk9PVDogY29tbWFuZCBsaW5lOiBsb2dnaW5nPXZnYSxtZW1vcnksc2VyaWFsClRCT09U
OiBCU1AgaXMgY3B1IDAKVEJPT1Q6IG9yaWdpbmFsIGU4MjAgbWFwOgpUQk9PVDogCTAwMDAwMDAw
MDAwMDAwMDAgLSAwMDAwMDAwMDAwMDllYzAwICAoMSkKVEJPT1Q6IAkwMDAwMDAwMDAwMGYwMDAw
IC0gMDAwMDAwMDAwMDEwMDAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAw
MDAwY2YwZmY4MDAgICgxKQpUQk9PVDogCTAwMDAwMDAwY2YwZmY4MDAgLSAwMDAwMDAwMGNmMTUz
YzAwICAoNCkKVEJPT1Q6IAkwMDAwMDAwMGNmMTUzYzAwIC0gMDAwMDAwMDBjZjE1NWMwMCAgKDMp
ClRCT09UOiAJMDAwMDAwMDBjZjE1NWMwMCAtIDAwMDAwMDAwZDAwMDAwMDAgICgyKQpUQk9PVDog
CTAwMDAwMDAwZTAwMDAwMDAgLSAwMDAwMDAwMGYwMDAwMDAwICAoMikKVEJPT1Q6IAkwMDAwMDAw
MGZlYzAwMDAwIC0gMDAwMDAwMDBmZWQwMDQwMCAgKDIpClRCT09UOiAJMDAwMDAwMDBmZWQyMDAw
MCAtIDAwMDAwMDAwZmVkYTAwMDAgICgyKQpUQk9PVDogCTAwMDAwMDAwZmVlMDAwMDAgLSAwMDAw
MDAwMGZlZjAwMDAwICAoMikKVEJPT1Q6IAkwMDAwMDAwMGZmYjAwMDAwIC0gMDAwMDAwMDEwMDAw
MDAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAxMjgwMDAwMDAgICgx
KQpUQk9PVDogVFBNIGlzIHJlYWR5ClRCT09UOiBUUE0gbnZfbG9ja2VkOiBGQUxTRQpUQk9PVDog
VFBNIHRpbWVvdXQgdmFsdWVzOiBBOiA3NTAsIEI6IDc1MCwgQzogNzUwLCBEOiA3NTAKVEJPT1Q6
IFdyb25nIHRpbWVvdXQgQiwgZmFsbGJhY2sgdG8gMjAwMApUQk9PVDogcmVhZGluZyBWZXJpZmll
ZCBMYXVuY2ggUG9saWN5IGZyb20gVFBNIE5WLi4uClRCT09UOiBUUE06IGdldCBjYXBhYmlsaXR5
LCByZXR1cm4gdmFsdWUgPSAwMDAwMDAwMgpUQk9PVDogVFBNOiBmYWlsIHRvIGdldCBwdWJsaWMg
ZGF0YSBvZiAweDIwMDAwMDAxIGluIFRQTSBOVgpUQk9PVDogCTpyZWFkaW5nIGZhaWxlZApUQk9P
VDogcmVhZGluZyBMYXVuY2ggQ29udHJvbCBQb2xpY3kgZnJvbSBUUE0gTlYuLi4KVEJPT1Q6IFRQ
TTogZ2V0IGNhcGFiaWxpdHksIHJldHVybiB2YWx1ZSA9IDAwMDAwMDAyClRCT09UOiBUUE06IGZh
aWwgdG8gZ2V0IHB1YmxpYyBkYXRhIG9mIDB4NDAwMDAwMDEgaW4gVFBNIE5WClRCT09UOiAJOnJl
YWRpbmcgZmFpbGVkClRCT09UOiBmYWlsZWQgdG8gcmVhZCBwb2xpY3kgZnJvbSBUUE0gTlYsIHVz
aW5nIGRlZmF1bHQKVEJPT1Q6IHBvbGljeToKVEJPT1Q6IAkgdmVyc2lvbjogMgpUQk9PVDogCSBw
b2xpY3lfdHlwZTogVEJfUE9MVFlQRV9DT05UX05PTl9GQVRBTApUQk9PVDogCSBoYXNoX2FsZzog
VEJfSEFMR19TSEExClRCT09UOiAJIHBvbGljeV9jb250cm9sOiAwMDAwMDAwMSAoRVhURU5EX1BD
UjE3KQpUQk9PVDogCSBudW1fZW50cmllczogMgpUQk9PVDogCSBwb2xpY3kgZW50cnlbMF06ClRC
T09UOiAJCSBtb2RfbnVtOiAwClRCT09UOiAJCSBwY3I6IG5vbmUKVEJPT1Q6IAkJIGhhc2hfdHlw
ZTogVEJfSFRZUEVfQU5ZClRCT09UOiAJCSBudW1faGFzaGVzOiAwClRCT09UOiAJIHBvbGljeSBl
bnRyeVsxXToKVEJPT1Q6IAkJIG1vZF9udW06IGFueQpUQk9PVDogCQkgcGNyOiAxOQpUQk9PVDog
CQkgaGFzaF90eXBlOiBUQl9IVFlQRV9BTlkKVEJPT1Q6IAkJIG51bV9oYXNoZXM6IDAKVEJPT1Q6
IFRQTTogd3JpdGUgbnYgMjAwMDAwMDIsIG9mZnNldCAwMDAwMDAwMCwgMDAwMDAwMDQgYnl0ZXMs
IHJldHVybiA9IDAwMDAwMDAyClRCT09UOiBFcnJvcjogd3JpdGUgVFBNIGVycm9yOiAweDIuClRC
T09UOiBubyBwb2xpY3kgaW4gVFBNIE5WLgpUQk9PVDogSUEzMl9GRUFUVVJFX0NPTlRST0xfTVNS
OiAwMDAwZmYwMwpUQk9PVDogQ1BVIGlzIFNNWC1jYXBhYmxlClRCT09UOiBDUFUgaXMgVk1YLWNh
cGFibGUKVEJPT1Q6IFNNWCBpcyBlbmFibGVkClRCT09UOiBUWFQgY2hpcHNldCBhbmQgYWxsIG5l
ZWRlZCBjYXBhYmlsaXRpZXMgcHJlc2VudApUQk9PVDogVFhULkVSUk9SQ09ERTogMHgwClRCT09U
OiBUWFQuRVNUUzogMHgwClRCT09UOiBUWFQuRTJTVFM6IDB4MTQKVEJPT1Q6IElBMzJfRkVBVFVS
RV9DT05UUk9MX01TUjogMDAwMGZmMDMKVEJPT1Q6IENQVSBpcyBTTVgtY2FwYWJsZQpUQk9PVDog
Q1BVIGlzIFZNWC1jYXBhYmxlClRCT09UOiBTTVggaXMgZW5hYmxlZApUQk9PVDogVFhUIGNoaXBz
ZXQgYW5kIGFsbCBuZWVkZWQgY2FwYWJpbGl0aWVzIHByZXNlbnQKVEJPT1Q6IFRYVC5IRUFQLkJB
U0U6IDB4Y2Y0MjAwMDAKVEJPT1Q6IFRYVC5IRUFQLlNJWkU6IDB4ZTAwMDAgKDkxNzUwNCkKVEJP
T1Q6IGJpb3NfZGF0YSAoQDB4Y2Y0MjAwMDgsIDB4MjQpOgpUQk9PVDogCSB2ZXJzaW9uOiAyClRC
T09UOiAJIGJpb3Nfc2luaXRfc2l6ZTogMHgwICgwKQpUQk9PVDogCSBsY3BfcGRfYmFzZTogMHgw
ClRCT09UOiAJIGxjcF9wZF9zaXplOiAweDAgKDApClRCT09UOiAJIG51bV9sb2dpY2FsX3Byb2Nz
OiAyClRCT09UOiBDUjAuTkUgbm90IHNldApUQk9PVDogQ1IwIGFuZCBFRkxBR1MgT0sKVEJPT1Q6
IG5vIG1hY2hpbmUgY2hlY2sgZXJyb3JzClRCT09UOiBDUFUgaXMgcmVhZHkgZm9yIFNFTlRFUgpU
Qk9PVDogY2hlY2tpbmcgcHJldmlvdXMgZXJyb3JzIG9uIHRoZSBsYXN0IGJvb3QuCglUUE06IHJl
YWQgbnYgaW5kZXggMjAwMDAwMDIgb2Zmc2V0IDAwMDAwMDAwLCByZXR1cm4gdmFsdWUgPSAwMDAw
MDAwMgpUQk9PVDogRXJyb3I6IHJlYWQgVFBNIGVycm9yOiAweDIuClRCT09UOiBsYXN0IGJvb3Qg
aGFzIG5vIGVycm9yLgpUQk9PVDogY2hlY2tpbmcgaWYgbW9kdWxlICBpcyBhbiBTSU5JVCBmb3Ig
dGhpcyBwbGF0Zm9ybS4uLgpUQk9PVDogY2hpcHNldCBwcm9kdWN0aW9uIGZ1c2VkOiAxClRCT09U
OiBjaGlwc2V0IGlkczogdmVuZG9yOiAweDgwODYsIGRldmljZTogMHg4MDAxLCByZXZpc2lvbjog
MHg3ClRCT09UOiBwcm9jZXNzb3IgZmFtaWx5L21vZGVsL3N0ZXBwaW5nOiAweDZmYgpUQk9PVDog
cGxhdGZvcm0gaWQ6IDB4ODgwMDg4MmEKVEJPT1Q6IAkgMSBBQ00gY2hpcHNldCBpZCBlbnRyaWVz
OgpUQk9PVDogCSAgICAgdmVuZG9yOiAweDgwODYsIGRldmljZTogMHg4MDAxLCBmbGFnczogMHgx
LCByZXZpc2lvbjogMHg3LCBleHRlbmRlZDogMHgwClRCT09UOiBTSU5JVCBtYXRjaGVzIHBsYXRm
b3JtClRCT09UOiBUWFQuU0lOSVQuQkFTRTogMHhjZjQwMDAwMApUQk9PVDogVFhULlNJTklULlNJ
WkU6IDB4MjAwMDAgKDEzMTA3MikKVEJPT1Q6IGNvcGllZCBTSU5JVCAoc2l6ZT03YjQwKSB0byAw
eGNmNDAwMDAwClRCT09UOiBBQyBtb2QgYmFzZSBhbGlnbm1lbnQgT0sKVEJPT1Q6IEFDIG1vZCBz
aXplIE9LClRCT09UOiBBQyBtb2R1bGUgaGVhZGVyIGR1bXAgZm9yIFNJTklUOgpUQk9PVDogCSB0
eXBlOiAweDIgKEFDTV9UWVBFX0NISVBTRVQpClRCT09UOiAJIHN1YnR5cGU6IDB4MCAKVEJPT1Q6
IAkgbGVuZ3RoOiAweGExICgxNjEpClRCT09UOiAJIHZlcnNpb246IDAKVEJPT1Q6IAkgY2hpcHNl
dF9pZDogMHgyOWMwClRCT09UOiAJIGZsYWdzOiAweDAKVEJPT1Q6IAkJIHByZV9wcm9kdWN0aW9u
OiAwClRCT09UOiAJCSBkZWJ1Z19zaWduZWQ6IDAKVEJPT1Q6IAkgdmVuZG9yOiAweDgwODYKVEJP
T1Q6IAkgZGF0ZTogMHgyMDExMTEyMgpUQk9PVDogCSBzaXplKjQ6IDB4N2I0MCAoMzE1NTIpClRC
T09UOiAJIGNvZGVfY29udHJvbDogMHgwClRCT09UOiAJIGVudHJ5IHBvaW50OiAweDAwMDAwMDA4
OjAwMDA1MWY0ClRCT09UOiAJIHNjcmF0Y2hfc2l6ZTogMHg4ZiAoMTQzKQpUQk9PVDogCSBpbmZv
X3RhYmxlOgpUQk9PVDogCQkgdXVpZDogezB4N2ZjMDNhYWEsIDB4NDZhNywgMHgxOGRiLCAweGFj
MmUsCgkJezB4NjksIDB4OGYsIDB4OGQsIDB4NDEsIDB4N2YsIDB4NWF9fQpUQk9PVDogCQkgICAg
IEFDTV9VVUlEX1YzClRCT09UOiAJCSBjaGlwc2V0X2FjbV90eXBlOiAweDEgKFNJTklUKQpUQk9P
VDogCQkgdmVyc2lvbjogMwpUQk9PVDogCQkgbGVuZ3RoOiAweDI4ICg0MCkKVEJPT1Q6IAkJIGNo
aXBzZXRfaWRfbGlzdDogMHg0ZTgKVEJPT1Q6IAkJIG9zX3Npbml0X2RhdGFfdmVyOiAweDQKVEJP
T1Q6IAkJIG1pbl9tbGVfaGRyX3ZlcjogMHgwMDAyMDAwMApUQk9PVDogCQkgY2FwYWJpbGl0aWVz
OiAweDAwMDAwMDA2ClRCT09UOiAJCSAgICAgcmxwX3dha2VfZ2V0c2VjOiAwClRCT09UOiAJCSAg
ICAgcmxwX3dha2VfbW9uaXRvcjogMQpUQk9PVDogCQkgICAgIGVjeF9wZ3RibDogMQpUQk9PVDog
CQkgICAgIHBjcl9tYXBfbm9fbGVnYWN5OiAwClRCT09UOiAJCSAgICAgcGNyX21hcF9kYTogMApU
Qk9PVDogCQkgYWNtX3ZlcjogNTEKVEJPT1Q6IAkgY2hpcHNldCBsaXN0OgpUQk9PVDogCQkgY291
bnQ6IDEKVEJPT1Q6IAkJIGVudHJ5IDA6ClRCT09UOiAJCSAgICAgZmxhZ3M6IDB4MQpUQk9PVDog
CQkgICAgIHZlbmRvcl9pZDogMHg4MDg2ClRCT09UOiAJCSAgICAgZGV2aWNlX2lkOiAweDgwMDEK
VEJPT1Q6IAkJICAgICByZXZpc2lvbl9pZDogMHg3ClRCT09UOiAJCSAgICAgZXh0ZW5kZWRfaWQ6
IDB4MApUQk9PVDogZmlsZSBhZGRyZXNzZXM6ClRCT09UOiAJICZfc3RhcnQ9MHg4MDQwMDAKVEJP
T1Q6IAkgJl9lbmQ9MHg5NzRmMDgKVEJPT1Q6IAkgJl9tbGVfc3RhcnQ9MHg4MDQwMDAKVEJPT1Q6
IAkgJl9tbGVfZW5kPTB4ODI5MDAwClRCT09UOiAJICZfcG9zdF9sYXVuY2hfZW50cnk9MHg4MDQw
MTAKVEJPT1Q6IAkgJl90eHRfd2FrZXVwPTB4ODA0MWUwClRCT09UOiAJICZnX21sZV9oZHI9MHg4
MWFkYzAKVEJPT1Q6IE1MRSBoZWFkZXI6ClRCT09UOiAJIHV1aWQ9ezB4OTA4MmFjNWEsIDB4NDc2
ZiwgMHg3NGE3LCAweDVjMGYsCgkJezB4NTUsIDB4YTIsIDB4Y2IsIDB4NTEsIDB4YjYsIDB4NDJ9
fQpUQk9PVDogCSBsZW5ndGg9MzQKVEJPT1Q6IAkgdmVyc2lvbj0wMDAyMDAwMQpUQk9PVDogCSBl
bnRyeV9wb2ludD0wMDAwMDAxMApUQk9PVDogCSBmaXJzdF92YWxpZF9wYWdlPTAwMDAwMDAwClRC
T09UOiAJIG1sZV9zdGFydF9vZmY9NDAwMApUQk9PVDogCSBtbGVfZW5kX29mZj0yOTAwMApUQk9P
VDogCSBjYXBhYmlsaXRpZXM6IDB4MDAwMDAwMjcKVEJPT1Q6IAkgICAgIHJscF93YWtlX2dldHNl
YzogMQpUQk9PVDogCSAgICAgcmxwX3dha2VfbW9uaXRvcjogMQpUQk9PVDogCSAgICAgZWN4X3Bn
dGJsOiAxClRCT09UOiAJICAgICBwY3JfbWFwX25vX2xlZ2FjeTogMApUQk9PVDogCSAgICAgcGNy
X21hcF9kYTogMQpUQk9PVDogTUxFIHN0YXJ0PTgwNDAwMCwgZW5kPTgyOTAwMCwgc2l6ZT0yNTAw
MApUQk9PVDogcHRhYl9zaXplPTMwMDAsIHB0YWJfYmFzZT0weDgwMTAwMApUQk9PVDogVFhULkhF
QVAuQkFTRTogMHhjZjQyMDAwMApUQk9PVDogVFhULkhFQVAuU0laRTogMHhlMDAwMCAoOTE3NTA0
KQpUQk9PVDogYmlvc19kYXRhIChAMHhjZjQyMDAwOCwgMHgyNCk6ClRCT09UOiAJIHZlcnNpb246
IDIKVEJPT1Q6IAkgYmlvc19zaW5pdF9zaXplOiAweDAgKDApClRCT09UOiAJIGxjcF9wZF9iYXNl
OiAweDAKVEJPT1Q6IAkgbGNwX3BkX3NpemU6IDB4MCAoMCkKVEJPT1Q6IAkgbnVtX2xvZ2ljYWxf
cHJvY3M6IDIKVEJPT1Q6IG1pbl9sb19yYW06IDB4MCwgbWF4X2xvX3JhbTogMHhjZjBmZjgwMApU
Qk9PVDogbWluX2hpX3JhbTogMHgxMDAwMDAwMDAsIG1heF9oaV9yYW06IDB4MTI4MDAwMDAwClRC
T09UOiBubyBMQ1AgbW9kdWxlIGZvdW5kClRCT09UOiBvc19zaW5pdF9kYXRhIChAMHhjZjQzMTE0
YywgMHg1Yyk6ClRCT09UOiAJIHZlcnNpb246IDQKVEJPT1Q6IAkgbWxlX3B0YWI6IDB4ODAxMDAw
ClRCT09UOiAJIG1sZV9zaXplOiAweDI1MDAwICgxNTE1NTIpClRCT09UOiAJIG1sZV9oZHJfYmFz
ZTogMHgxNmRjMApUQk9PVDogCSB2dGRfcG1yX2xvX2Jhc2U6IDB4MApUQk9PVDogCSB2dGRfcG1y
X2xvX3NpemU6IDB4Y2YwMDAwMDAKVEJPT1Q6IAkgdnRkX3Btcl9oaV9iYXNlOiAweDEwMDAwMDAw
MApUQk9PVDogCSB2dGRfcG1yX2hpX3NpemU6IDB4MjgwMDAwMDAKVEJPT1Q6IAkgbGNwX3BvX2Jh
c2U6IDB4MApUQk9PVDogCSBsY3BfcG9fc2l6ZTogMHgwICgwKQpUQk9PVDogCSBjYXBhYmlsaXRp
ZXM6IDB4MDAwMDAwMDIKVEJPT1Q6IAkgICAgIHJscF93YWtlX2dldHNlYzogMApUQk9PVDogCSAg
ICAgcmxwX3dha2VfbW9uaXRvcjogMQpUQk9PVDogCSAgICAgZWN4X3BndGJsOiAwClRCT09UOiAJ
ICAgICBwY3JfbWFwX25vX2xlZ2FjeTogMApUQk9PVDogCSAgICAgcGNyX21hcF9kYTogMApUQk9P
VDogc2V0dGluZyBNVFJScyBmb3IgYWNtb2Q6IGJhc2U9MHhjZjQwMDAwMCwgc2l6ZT0weDdiNDAs
IG51bV9wYWdlcz04ClRCT09UOiBleGVjdXRpbmcgR0VUU0VDW1NFTlRFUl0uLi4KVEJPT1Q6ICoq
KioqKioqKioqKioqKioqKiogVEJPT1QgKioqKioqKioqKioqKioqKioqKgpUQk9PVDogICAgMjAx
My0wNy0wNSAxMjowMCArMDgwMCAxLjcuNApUQk9PVDogKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqClRCT09UOiBjb21tYW5kIGxpbmU6IGxvZ2dpbmc9dmdhLG1l
bW9yeSxzZXJpYWwKVEJPT1Q6IEJTUCBpcyBjcHUgMApUQk9PVDogb3JpZ2luYWwgZTgyMCBtYXA6
ClRCT09UOiAJMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWVjMDAgICgxKQpUQk9PVDog
CTAwMDAwMDAwMDAwZjAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwICAoMikKVEJPT1Q6IAkwMDAwMDAw
MDAwMTAwMDAwIC0gMDAwMDAwMDBjZjBmZjgwMCAgKDEpClRCT09UOiAJMDAwMDAwMDBjZjBmZjgw
MCAtIDAwMDAwMDAwY2YxNTNjMDAgICg0KQpUQk9PVDogCTAwMDAwMDAwY2YxNTNjMDAgLSAwMDAw
MDAwMGNmMTU1YzAwICAoMykKVEJPT1Q6IAkwMDAwMDAwMGNmMTU1YzAwIC0gMDAwMDAwMDBkMDAw
MDAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDBlMDAwMDAwMCAtIDAwMDAwMDAwZjAwMDAwMDAgICgy
KQpUQk9PVDogCTAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlZDAwNDAwICAoMikKVEJPT1Q6
IAkwMDAwMDAwMGZlZDIwMDAwIC0gMDAwMDAwMDBmZWRhMDAwMCAgKDIpClRCT09UOiAJMDAwMDAw
MDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVmMDAwMDAgICgyKQpUQk9PVDogCTAwMDAwMDAwZmZiMDAw
MDAgLSAwMDAwMDAwMTAwMDAwMDAwICAoMikKVEJPT1Q6IAkwMDAwMDAwMTAwMDAwMDAwIC0gMDAw
MDAwMDEyODAwMDAwMCAgKDEpClRCT09UOiBUUE0gaXMgcmVhZHkKVEJPT1Q6IFRQTSBudl9sb2Nr
ZWQ6IEZBTFNFClRCT09UOiBUUE0gdGltZW91dCB2YWx1ZXM6IEE6IDc1MCwgQjogNzUwLCBDOiA3
NTAsIEQ6IDc1MApUQk9PVDogV3JvbmcgdGltZW91dCBCLCBmYWxsYmFjayB0byAyMDAwClRCT09U
OiByZWFkaW5nIFZlcmlmaWVkIExhdW5jaCBQb2xpY3kgZnJvbSBUUE0gTlYuLi4KVEJPT1Q6IFRQ
TTogZ2V0IGNhcGFiaWxpdHksIHJldHVybiB2YWx1ZSA9IDAwMDAwMDAyClRCT09UOiBUUE06IGZh
aWwgdG8gZ2V0IHB1YmxpYyBkYXRhIG9mIDB4MjAwMDAwMDEgaW4gVFBNIE5WClRCT09UOiAJOnJl
YWRpbmcgZmFpbGVkClRCT09UOiByZWFkaW5nIExhdW5jaCBDb250cm9sIFBvbGljeSBmcm9tIFRQ
TSBOVi4uLgpUQk9PVDogVFBNOiBnZXQgY2FwYWJpbGl0eSwgcmV0dXJuIHZhbHVlID0gMDAwMDAw
MDIKVEJPT1Q6IFRQTTogZmFpbCB0byBnZXQgcHVibGljIGRhdGEgb2YgMHg0MDAwMDAwMSBpbiBU
UE0gTlYKVEJPT1Q6IAk6cmVhZGluZyBmYWlsZWQKVEJPT1Q6IGZhaWxlZCB0byByZWFkIHBvbGlj
eSBmcm9tIFRQTSBOViwgdXNpbmcgZGVmYXVsdApUQk9PVDogcG9saWN5OgpUQk9PVDogCSB2ZXJz
aW9uOiAyClRCT09UOiAJIHBvbGljeV90eXBlOiBUQl9QT0xUWVBFX0NPTlRfTk9OX0ZBVEFMClRC
T09UOiAJIGhhc2hfYWxnOiBUQl9IQUxHX1NIQTEKVEJPT1Q6IAkgcG9saWN5X2NvbnRyb2w6IDAw
MDAwMDAxIChFWFRFTkRfUENSMTcpClRCT09UOiAJIG51bV9lbnRyaWVzOiAyClRCT09UOiAJIHBv
bGljeSBlbnRyeVswXToKVEJPT1Q6IAkJIG1vZF9udW06IDAKVEJPT1Q6IAkJIHBjcjogbm9uZQpU
Qk9PVDogCQkgaGFzaF90eXBlOiBUQl9IVFlQRV9BTlkKVEJPT1Q6IAkJIG51bV9oYXNoZXM6IDAK
VEJPT1Q6IAkgcG9saWN5IGVudHJ5WzFdOgpUQk9PVDogCQkgbW9kX251bTogYW55ClRCT09UOiAJ
CSBwY3I6IDE5ClRCT09UOiAJCSBoYXNoX3R5cGU6IFRCX0hUWVBFX0FOWQpUQk9PVDogCQkgbnVt
X2hhc2hlczogMApUQk9PVDogVFBNOiB3cml0ZSBudiAyMDAwMDAwMiwgb2Zmc2V0IDAwMDAwMDAw
LCAwMDAwMDAwNCBieXRlcywgcmV0dXJuID0gMDAwMDAwMDIKVEJPT1Q6IEVycm9yOiB3cml0ZSBU
UE0gZXJyb3I6IDB4Mi4KVEJPT1Q6IG5vIHBvbGljeSBpbiBUUE0gTlYuClRCT09UOiBJQTMyX0ZF
QVRVUkVfQ09OVFJPTF9NU1I6IDAwMDBmZjAzClRCT09UOiBDUFUgaXMgU01YLWNhcGFibGUKVEJP
T1Q6IENQVSBpcyBWTVgtY2FwYWJsZQpUQk9PVDogU01YIGlzIGVuYWJsZWQKVEJPT1Q6IFRYVCBj
aGlwc2V0IGFuZCBhbGwgbmVlZGVkIGNhcGFiaWxpdGllcyBwcmVzZW50ClRCT09UOiBUWFQuRVJS
T1JDT0RFOiAweGMwMDAwMDAxClRCT09UOiBBQyBtb2R1bGUgZXJyb3IgOiBhY21fdHlwZT0weDEs
IHByb2dyZXNzPTB4MDAsIGVycm9yPTB4MApUQk9PVDogVFhULkVTVFM6IDB4MApUQk9PVDogVFhU
LkUyU1RTOiAweDE0ClRCT09UOiBJQTMyX0ZFQVRVUkVfQ09OVFJPTF9NU1I6IDAwMDBmZjAzClRC
T09UOiBDUFUgaXMgU01YLWNhcGFibGUKVEJPT1Q6IENQVSBpcyBWTVgtY2FwYWJsZQpUQk9PVDog
U01YIGlzIGVuYWJsZWQKVEJPT1Q6IFRYVCBjaGlwc2V0IGFuZCBhbGwgbmVlZGVkIGNhcGFiaWxp
dGllcyBwcmVzZW50ClRCT09UOiBUWFQuSEVBUC5CQVNFOiAweGNmNDIwMDAwClRCT09UOiBUWFQu
SEVBUC5TSVpFOiAweGUwMDAwICg5MTc1MDQpClRCT09UOiBiaW9zX2RhdGEgKEAweGNmNDIwMDA4
LCAweDI0KToKVEJPT1Q6IAkgdmVyc2lvbjogMgpUQk9PVDogCSBiaW9zX3Npbml0X3NpemU6IDB4
MCAoMCkKVEJPT1Q6IAkgbGNwX3BkX2Jhc2U6IDB4MApUQk9PVDogCSBsY3BfcGRfc2l6ZTogMHgw
ICgwKQpUQk9PVDogCSBudW1fbG9naWNhbF9wcm9jczogMgpUQk9PVDogbWVhc3VyZWQgbGF1bmNo
IHN1Y2NlZWRlZApUQk9PVDogVFhULkhFQVAuQkFTRTogMHhjZjQyMDAwMApUQk9PVDogVFhULkhF
QVAuU0laRTogMHhlMDAwMCAoOTE3NTA0KQpUQk9PVDogYmlvc19kYXRhIChAMHhjZjQyMDAwOCwg
MHgyNCk6ClRCT09UOiAJIHZlcnNpb246IDIKVEJPT1Q6IAkgYmlvc19zaW5pdF9zaXplOiAweDAg
KDApClRCT09UOiAJIGxjcF9wZF9iYXNlOiAweDAKVEJPT1Q6IAkgbGNwX3BkX3NpemU6IDB4MCAo
MCkKVEJPT1Q6IAkgbnVtX2xvZ2ljYWxfcHJvY3M6IDIKVEJPT1Q6IG9zX21sZV9kYXRhIChAMHhj
ZjQyMDAyYywgMHgxMTEyMCk6ClRCT09UOiAJIHZlcnNpb246IDMKVEJPT1Q6IAkgbWJpOiAweDEw
MDAwClRCT09UOiBvc19zaW5pdF9kYXRhIChAMHhjZjQzMTE0YywgMHg1Yyk6ClRCT09UOiAJIHZl
cnNpb246IDQKVEJPT1Q6IAkgbWxlX3B0YWI6IDB4ODAxMDAwClRCT09UOiAJIG1sZV9zaXplOiAw
eDI1MDAwICgxNTE1NTIpClRCT09UOiAJIG1sZV9oZHJfYmFzZTogMHgxNmRjMApUQk9PVDogCSB2
dGRfcG1yX2xvX2Jhc2U6IDB4MApUQk9PVDogCSB2dGRfcG1yX2xvX3NpemU6IDB4Y2YwMDAwMDAK
VEJPT1Q6IAkgdnRkX3Btcl9oaV9iYXNlOiAweDEwMDAwMDAwMApUQk9PVDogCSB2dGRfcG1yX2hp
X3NpemU6IDB4MjgwMDAwMDAKVEJPT1Q6IAkgbGNwX3BvX2Jhc2U6IDB4MApUQk9PVDogCSBsY3Bf
cG9fc2l6ZTogMHgwICgwKQpUQk9PVDogCSBjYXBhYmlsaXRpZXM6IDB4MDAwMDAwMDIKVEJPT1Q6
IAkgICAgIHJscF93YWtlX2dldHNlYzogMApUQk9PVDogCSAgICAgcmxwX3dha2VfbW9uaXRvcjog
MQpUQk9PVDogCSAgICAgZWN4X3BndGJsOiAwClRCT09UOiAJICAgICBwY3JfbWFwX25vX2xlZ2Fj
eTogMApUQk9PVDogCSAgICAgcGNyX21hcF9kYTogMApUQk9PVDogc2luaXRfbWxlX2RhdGEgKEAw
eGNmNDMxMWE4LCAweDI1OCk6ClRCT09UOiAJIHZlcnNpb246IDYKVEJPT1Q6IAkgYmlvc19hY21f
aWQ6IAoJODAgMDAgMDAgMDAgMjAgMDcgMDkgMTAgZmYgZmYgZmYgZmYgZmYgZmYgZmYgZmYgZmYg
ZmYgZmYgZmYgClRCT09UOiAJIGVkeF9zZW50ZXJfZmxhZ3M6IDB4MDAwMDAwMDAKVEJPT1Q6IAkg
bXNlZ192YWxpZDogMHgwClRCT09UOiAJIHNpbml0X2hhc2g6CgllYyBmNyA5OCBmNyA1OCA0YSA4
MSA5NiAwOCBiYyA5NiAyMyAwYiAxMyBlYyBkZiA4NCA1MiA0NyA0NyAKVEJPT1Q6IAkgbWxlX2hh
c2g6CgljMSA2YiA5OCBhOSA5MSA4YSA5YyA4YSAwZiBjNSA1NyBmZiA1YSBmZiBmMyAwYyAyNCA0
OSA5NyA2NCAKVEJPT1Q6IAkgc3RtX2hhc2g6CgkwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAKVEJPT1Q6IAkgbGNwX3BvbGljeV9oYXNo
OgoJMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgMDAgClRCT09UOiAJIGxjcF9wb2xpY3lfY29udHJvbDogMHgwMDAwMDAwMApUQk9PVDogCSBy
bHBfd2FrZXVwX2FkZHI6IDB4Y2Y0MDFhODAKVEJPT1Q6IAkgbnVtX21kcnM6IDcKVEJPT1Q6IAkg
bWRyc19vZmY6IDB4OTgKVEJPT1Q6IAkgbnVtX3Z0ZF9kbWFyczogMjgwClRCT09UOiAJIHZ0ZF9k
bWFyc19vZmY6IDB4MTQwClRCT09UOiAJIHNpbml0X21kcnM6ClRCT09UOiAJCSAwMDAwMDAwMDAw
MDAwMDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAoR09PRCkKVEJPT1Q6IAkJIDAwMDAwMDAwMDAxMDAw
MDAgLSAwMDAwMDAwMDAxMDAwMDAwIChHT09EKQpUQk9PVDogCQkgMDAwMDAwMDAwMTAwMDAwMCAt
IDAwMDAwMDAwY2Y0MDAwMDAgKEdPT0QpClRCT09UOiAJCSAwMDAwMDAwMTAwMDAwMDAwIC0gMDAw
MDAwMDEyYzAwMDAwMCAoR09PRCkKVEJPT1Q6IAkJIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAw
MTJjMDAwMDAwIChHT09EKQpUQk9PVDogCQkgMDAwMDAwMDBjZjUwMDAwMCAtIDAwMDAwMDAwY2Y2
MDAwMDAgKFNNUkFNIE5PTi1PVkVSTEFZKQpUQk9PVDogCQkgMDAwMDAwMDBlMDAwMDAwMCAtIDAw
MDAwMDAwZjAwMDAwMDAgKFBDSUUgRVhURU5ERUQgQ09ORklHKQpUQk9PVDogQ1BVIHN1cHBvcnRz
IDM2IHBoeXMgYWRkcmVzcyBiaXRzClRCT09UOiBSU0RQICh2MiwgREVMTCAgAk3FDykgQCAweDBm
ZWMwMApUQk9PVDogYWNwaV90YWJsZV9pb2FwaWMgQCAweGZjODRkLCAuYWRkcmVzcyA9IDB4ZmVj
MDAwMDAKVEJPT1Q6IGFjcGlfdGFibGVfbWNmZyBAIDB4ZmM5MzEsIC5iYXNlX2FkZHJlc3MgPSAw
eGUwMDAwMDAwClRCT09UOiBtdHJyX2RlZl90eXBlOiBlID0gMSwgZmUgPSAxLCB0eXBlID0gMApU
Qk9PVDogbXRycnM6ClRCT09UOiAJCSAgICBiYXNlICAgICAgICAgIG1hc2sgICAgICB0eXBlICB2
ClRCT09UOiAJCTAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMCAgMDYgIDAxClRCT09UOiAJCTAw
MDAwMDAwY2Y2MDAgMDAwMDAwMGZmZmUwMCAgMDAgIDAxClRCT09UOiAJCTAwMDAwMDAwY2Y4MDAg
MDAwMDAwMGZmZjgwMCAgMDAgIDAxClRCT09UOiAJCTAwMDAwMDAwY2Y1MDAgMDAwMDAwMGZmZmYw
MCAgMDAgIDAxClRCT09UOiAJCTAwMDAwMDAwZDAwMDAgMDAwMDAwMGZmMDAwMCAgMDAgIDAxClRC
T09UOiAJCTAwMDAwMDAwZTAwMDAgMDAwMDAwMGZlMDAwMCAgMDAgIDAxClRCT09UOiAJCTAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMCAgMDAgIDAwClRCT09UOiAJCTAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMCAgMDAgIDAwClRCT09UOiByZXNlcnZpbmcgMHhjZjAwMDAwMCAtIDB4Y2YwZmY4
MDAsIHdoaWNoIHdhcyB0cnVuY2F0ZWQgZm9yIFZULWQKVEJPT1Q6IG1pbl9sb19yYW06IDB4MCwg
bWF4X2xvX3JhbTogMHhjZjBmZjgwMApUQk9PVDogbWluX2hpX3JhbTogMHgxMDAwMDAwMDAsIG1h
eF9oaV9yYW06IDB4MTI4MDAwMDAwClRCT09UOiBNU1IgZm9yIFNNTSBtb25pdG9yIGNvbnRyb2wg
b24gQlNQIGlzIDB4MC4KVEJPT1Q6IHZlcmlmeWluZyBJTFAgaXMgb3B0LW91dCBvciBoYXMgdGhl
IHNhbWUgTVNFRyBoZWFkZXIgd2l0aCBUWFQuTVNFRy5CQVNFCgkJb3B0LW91dApUQk9PVDogIDog
c3VjY2VlZGVkLgpUQk9PVDogZW5hYmxpbmcgU01JcyBvbiBCU1AKVEJPT1Q6IG1sZV9qb2luLmVu
dHJ5X3BvaW50ID0gODA0MWUwClRCT09UOiBtbGVfam9pbi5zZWdfc2VsID0gOApUQk9PVDogbWxl
X2pvaW4uZ2R0X2Jhc2UgPSA4MDUwMDAKVEJPT1Q6IG1sZV9qb2luLmdkdF9saW1pdCA9IDNmClRC
T09UOiBqb2luaW5nIFJMUHMgdG8gTUxFIHdpdGggTU9OSVRPUiB3YWtldXAKVEJPT1Q6IHJscF93
YWtldXBfYWRkciA9IDB4Y2Y0MDFhODAKVEJPT1Q6IGNwdSAxIHdha2luZyB1cCBmcm9tIFRYVCBz
bGVlcApUQk9PVDogd2FpdGluZyBmb3IgYWxsIEFQcyAoMSkgdG8gZW50ZXIgd2FpdC1mb3Itc2lw
aS4uLgpUQk9PVDogTVNSIGZvciBTTU0gbW9uaXRvciBjb250cm9sIG9uIGNwdSAxIGlzIDB4MApU
Qk9PVDogdmVyaWZ5aW5nIElMUCdzIE1TUl9JQTMyX1NNTV9NT05JVE9SX0NUTCB3aXRoIGNwdSAx
CgkgOiBzdWNjZWVkZWQuClRCT09UOiBlbmFibGluZyBTTUlzIG9uIGNwdSAxClRCT09UOiAuVk1Y
T04gZG9uZSBmb3IgY3B1IDEKVEJPT1Q6IApUQk9PVDogbGF1bmNoaW5nIG1pbmktZ3Vlc3QgZm9y
IGNwdSAxClRCT09UOiAKVEJPT1Q6IGFsbCBBUHMgaW4gd2FpdC1mb3Itc2lwaQpUQk9PVDogc2F2
ZWQgSUEzMl9NSVNDX0VOQUJMRSA9IDB4NjI4NjIwODkKVEJPT1Q6IHNldCBUWFQuQ01ELlNFQ1JF
VFMgZmxhZwpUQk9PVDogb3BlbmVkIFRQTSBsb2NhbGl0eSAxClRCT09UOiBETUFSIHRhYmxlIEAg
MHhmY2JmZCBzYXZlZC4KVEJPT1Q6IG5vIExDUCBtb2R1bGUgZm91bmQKVEJPT1Q6IHZlcmlmeWlu
ZyBtb2R1bGUgMCBvZiBtYmkgKDEwNDAwMCAtIDJmMjVlYikgaW4gZTgyMCB0YWJsZQoJIChyYW5n
ZSBmcm9tIDAwMDAwMDAwMDAxMDQwMDAgdG8gMDAwMDAwMDAwMDJmMjVlYyBpcyBpbiBFODIwX1JB
TSkKVEJPT1Q6IDogc3VjY2VlZGVkLgpUQk9PVDogdmVyaWZ5aW5nIG1vZHVsZSAxIG9mIG1iaSAo
OTc1MDAwIC0gZWZmMmJmKSBpbiBlODIwIHRhYmxlCgkgKHJhbmdlIGZyb20gMDAwMDAwMDAwMDk3
NTAwMCB0byAwMDAwMDAwMDAwZWZmMmMwIGlzIGluIEU4MjBfUkFNKQpUQk9PVDogOiBzdWNjZWVk
ZWQuClRCT09UOiB2ZXJpZnlpbmcgbW9kdWxlIDIgb2YgbWJpIChmMDAwMDAgLSA0MmQwOWZmKSBp
biBlODIwIHRhYmxlCgkgKHJhbmdlIGZyb20gMDAwMDAwMDAwMGYwMDAwMCB0byAwMDAwMDAwMDA0
MmQwYTAwIGlzIGluIEU4MjBfUkFNKQpUQk9PVDogOiBzdWNjZWVkZWQuClRCT09UOiBwcm90ZWN0
aW5nIFRYVCBoZWFwIChjZjQyMDAwMCAtIGNmNGZmZmZmKSBpbiBlODIwIHRhYmxlClRCT09UOiBw
cm90ZWN0aW5nIFNJTklUIChjZjQwMDAwMCAtIGNmNDFmZmZmKSBpbiBlODIwIHRhYmxlClRCT09U
OiBwcm90ZWN0aW5nIFRYVCBQcml2YXRlIFNwYWNlIChmZWQyMDAwMCAtIGZlZDJmZmZmKSBpbiBl
ODIwIHRhYmxlClRCT09UOiB2ZXJpZnlpbmcgZTgyMCB0YWJsZSBhZ2FpbnN0IFNJTklUIE1EUnM6
IHZlcmlmaWNhdGlvbiBzdWNjZWVkZWQuClRCT09UOiB2ZXJpZnlpbmcgdGJvb3QgYW5kIGl0cyBw
YWdlIHRhYmxlICg4MDAwMDAgLSA5NzRmMDcpIGluIGU4MjAgdGFibGUKCSAocmFuZ2UgZnJvbSAw
MDAwMDAwMDAwODAwMDAwIHRvIDAwMDAwMDAwMDA5NzRmMDggaXMgaW4gRTgyMF9SQU0pClRCT09U
OiA6IHN1Y2NlZWRlZC4KVEJPT1Q6IHByb3RlY3RpbmcgdGJvb3QgKDgwMDAwMCAtIDk3NGZmZikg
aW4gZTgyMCB0YWJsZQpUQk9PVDogcmVzZXJ2aW5nIHRib290IG1lbW9yeSBsb2cgKDYwMDAwIC0g
NjdmZmYpIGluIGU4MjAgdGFibGUKVEJPT1Q6IGFkanVzdGVkIGU4MjAgbWFwOgpUQk9PVDogCTAw
MDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDYwMDAwICAoMSkKVEJPT1Q6IAkwMDAwMDAwMDAw
MDYwMDAwIC0gMDAwMDAwMDAwMDA2ODAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDAwMDA2ODAwMCAt
IDAwMDAwMDAwMDAwOWVjMDAgICgxKQpUQk9PVDogCTAwMDAwMDAwMDAwZjAwMDAgLSAwMDAwMDAw
MDAwMTAwMDAwICAoMikKVEJPT1Q6IAkwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDAwMDgwMDAw
MCAgKDEpClRCT09UOiAJMDAwMDAwMDAwMDgwMDAwMCAtIDAwMDAwMDAwMDA5NzUwMDAgICg1KQpU
Qk9PVDogCTAwMDAwMDAwMDA5NzUwMDAgLSAwMDAwMDAwMGNmMDAwMDAwICAoMSkKVEJPT1Q6IAkw
MDAwMDAwMGNmMDAwMDAwIC0gMDAwMDAwMDBjZjBmZjgwMCAgKDIpClRCT09UOiAJMDAwMDAwMDBj
ZjBmZjgwMCAtIDAwMDAwMDAwY2YxNTNjMDAgICg0KQpUQk9PVDogCTAwMDAwMDAwY2YxNTNjMDAg
LSAwMDAwMDAwMGNmMTU1YzAwICAoMykKVEJPT1Q6IAkwMDAwMDAwMGNmMTU1YzAwIC0gMDAwMDAw
MDBjZjQwMDAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDBjZjQwMDAwMCAtIDAwMDAwMDAwY2Y0MjAw
MDAgICgyKQpUQk9PVDogCTAwMDAwMDAwY2Y0MjAwMDAgLSAwMDAwMDAwMGNmNTAwMDAwICAoMikK
VEJPT1Q6IAkwMDAwMDAwMGNmNTAwMDAwIC0gMDAwMDAwMDBkMDAwMDAwMCAgKDIpClRCT09UOiAJ
MDAwMDAwMDBlMDAwMDAwMCAtIDAwMDAwMDAwZjAwMDAwMDAgICgyKQpUQk9PVDogCTAwMDAwMDAw
ZmVjMDAwMDAgLSAwMDAwMDAwMGZlZDAwNDAwICAoMikKVEJPT1Q6IAkwMDAwMDAwMGZlZDIwMDAw
IC0gMDAwMDAwMDBmZWQzMDAwMCAgKDIpClRCT09UOiAJMDAwMDAwMDBmZWQzMDAwMCAtIDAwMDAw
MDAwZmVkYTAwMDAgICgyKQpUQk9PVDogCTAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZjAw
MDAwICAoMikKVEJPT1Q6IAkwMDAwMDAwMGZmYjAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAgKDIp
ClRCT09UOiAJMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAxMjgwMDAwMDAgICgxKQpUQk9PVDog
dmVyaWZ5aW5nIG1vZHVsZSAiCi94ZW4uZ3ogcGxhY2Vob2xkZXIiLi4uClRCT09UOiAJIE9LIDog
NGUgZmYgMDQgODMgOWQgYzggNjUgNGMgNGMgYWYgZmMgY2YgZDkgMzAgYjAgZDUgMTEgNzEgMGEg
ZDYgClRCT09UOiB2ZXJpZnlpbmcgbW9kdWxlICIKL3ZtbGludXotMy4xMy4wLTM3LWdlbmVyaWMg
cm9vdD0vZGV2L21hcHBlci94ZW4yLS12Zy1yb290IHJvIHF1aWV0IHNwbGFzaCB2dC5oYW4KZG9m
Zj03Ii4uLgpUQk9PVDogCSBPSyA6IDFiIGVlIDVhIDIxIGE5IDc0IGY2IGY0IDdjIDdlIDBlIDFj
IGE5IGIxIDlhIDI2IGU3IGU0IDMyIDk5IApUQk9PVDogdmVyaWZ5aW5nIG1vZHVsZSAiCi9pbml0
cmQuaW1nLTMuMTMuMC0zNy1nZW5lcmljIi4uLgpUQk9PVDogCSBPSyA6IGUyIDE3IDZhIDliIDI2
IDk5IGFmIDFkIGI4IDMzIGVhIGM0IGRmIGJkIDYyIGVkIDZhIDQ3IDc5IDNlIApUQk9PVDogYWxs
IG1vZHVsZXMgYXJlIHZlcmlmaWVkClRCT09UOiBwcmVfa19zM19zdGF0ZToKVEJPT1Q6IAkgdnRk
X3Btcl9sb19iYXNlOiAweDAKVEJPT1Q6IAkgdnRkX3Btcl9sb19zaXplOiAweGNmMDAwMDAwClRC
T09UOiAJIHZ0ZF9wbXJfaGlfYmFzZTogMHgxMDAwMDAwMDAKVEJPT1Q6IAkgdnRkX3Btcl9oaV9z
aXplOiAweDI4MDAwMDAwClRCT09UOiAJIHBvbF9oYXNoOiBhYiA0MSA2MiA0ZSA3ZCA3MSBmMCA2
OCBkNCA4ZSAxYyAyZiA0MyBlNiAxNiBiZiA0MCA2NyAxYyAzOSAKVEJPT1Q6IAkgVkwgbWVhc3Vy
ZW1lbnRzOgpUQk9PVDogCSAgIFBDUiAxNzogOTcgMDQgMzUgMzYgMzAgNjcgNGIgZmUgMjEgYjgg
NmIgNjQgYTcgYjAgZjkgOWMgMjkgN2MgZjkgMDIgClRCT09UOiAJICAgUENSIDE4OiA0ZSBmZiAw
NCA4MyA5ZCBjOCA2NSA0YyA0YyBhZiBmYyBjZiBkOSAzMCBiMCBkNSAxMSA3MSAwYSBkNiAKVEJP
T1Q6IAkgICBQQ1IgMTk6IDFiIGVlIDVhIDIxIGE5IDc0IGY2IGY0IDdjIDdlIDBlIDFjIGE5IGIx
IDlhIDI2IGU3IGU0IDMyIDk5IApUQk9PVDogCSAgIFBDUiAxOTogZTIgMTcgNmEgOWIgMjYgOTkg
YWYgMWQgYjggMzMgZWEgYzQgZGYgYmQgNjIgZWQgNmEgNDcgNzkgM2UgClRCT09UOiBUUE06IHN0
YXJ0IE9TQVAsIHJldHVybiB2YWx1ZSA9IDAwMDAwMDAzClRCT09UOiBmYWlsZWQgdG8gc2VhbCBk
YXRhClRCT09UOiBQQ1JzIGJlZm9yZSBleHRlbmRpbmc6ClRCT09UOiAgIFBDUiAxNzogMDQgOWQg
MTIgZTMgMWIgZjQgZWMgYTAgYTQgOTIgMWYgZWEgNTUgYTQgMTMgNzggOGYgYWUgNDUgMDIgClRC
T09UOiAgIFBDUiAxODogZGQgY2YgMmYgNDQgZmUgZmIgMjIgNTAgM2YgNzkgNTkgZDYgZjAgMTAg
MzEgZDYgYzUgYzAgYTggNjcgClRCT09UOiBQQ1JzIGFmdGVyIGV4dGVuZGluZzoKVEJPT1Q6ICAg
UENSIDE3OiBhMyBkOSA2MyA1MiBkMSA2ZiBhMSA4OSAxNCBmZSBjZSBjMSA3MyA2MSA1NiBmNSA4
NiAyYSA1NCA3MyAKVEJPT1Q6ICAgUENSIDE4OiBiZCBjNiBmNCA0MiAyMiAyMSA2MSAyNiBjMiA0
NyBhYyBjNSA3ZiA4MyA3YiA3YiA1NyBkMyBhYSA2MSAKVEJPT1Q6IGNyZWF0aW9uIG9yIHZlcmlm
aWNhdGlvbiBvZiBTMyBtZWFzdXJlbWVudHMgZmFpbGVkLgpUQk9PVDogdGJvb3Rfc2hhcmVkIGRh
dGE6ClRCT09UOiAJIHZlcnNpb246IDYKVEJPT1Q6IAkgbG9nX2FkZHI6IDB4MDAwNjAwMDAKVEJP
T1Q6IAkgc2h1dGRvd25fZW50cnk6IDB4MDA4MDQxYTAKVEJPT1Q6IAkgc2h1dGRvd25fdHlwZTog
MApUQk9PVDogCSB0Ym9vdF9iYXNlOiAweDAwODA0MDAwClRCT09UOiAJIHRib290X3NpemU6IDB4
MTcwZjA4ClRCT09UOiAJIG51bV9pbl93ZnM6IDEKVEJPT1Q6IAkgZmxhZ3M6IDB4MDAwMDAwMDAK
VEJPT1Q6IAkgYXBfd2FrZV9hZGRyOiAweDAwMDAwMDAwClRCT09UOiAJIGFwX3dha2VfdHJpZ2dl
cjogMApUQk9PVDogbm8gTENQIG1vZHVsZSBmb3VuZApUQk9PVDoga2VybmVsIGlzIEVMRiBmb3Jt
YXQKVEJPT1Q6IDB4NmZjMDAwIGJ5dGVzIGNvcGllZCBmcm9tIDB4MTA0MDAwIHRvIDB4NDJkMTAw
MApUQk9PVDogdHJhbnNmZXJpbmcgY29udHJvbCB0byBrZXJuZWwgQDB4MTAwMDAwLi4uClRCT09U
OiBWTVhPRkYgZG9uZSBmb3IgY3B1IDEKVEJPT1Q6IGNwdSAxIHdha2luZyB1cCwgU0lQSSB2ZWN0
b3I9OGUwMDAKCg==

--_002_945CA011AD5F084CBEA3E851C0AB28890E83A0E9SHSMSX101ccrcor_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_945CA011AD5F084CBEA3E851C0AB28890E83A0E9SHSMSX101ccrcor_--


From xen-devel-bounces@lists.xen.org Sun Nov 16 10:46:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 10: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 1XpxLf-0002aA-0P; Sun, 16 Nov 2014 10:46:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1XpxLd-0002a5-NA
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 10:46:25 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	5C/5F-02707-08088645; Sun, 16 Nov 2014 10:46:24 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416134782!11601721!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1650 invoked from network); 16 Nov 2014 10:46:23 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 10:46:23 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so36543wiv.12
	for <xen-devel@lists.xen.org>; Sun, 16 Nov 2014 02:46:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=rmrdfIL3KK3y6/6yoU8RGDTphJVgVDiEKajgJRZhL2Q=;
	b=n47evbEY8DOT2k3Ig3FkNhJX10RY4cjMh7VjnML+Oi1rGSiyykxBJUXUz7JiqijvV4
	IHE7k2GYnKotnDhMpKmSSonebHWrtJh6IgPUE6Yyds7cCQWjrSsVi4H8c8wEemKtRRPa
	mF2Gxh1aMfTfQREqadaiVubfRwV4lWON+j6+4bjIgkUPDAcp6MAYYOpG8BH7qMT8S8Zn
	qnYeqWEYlzm0ObAPYD/vk55SoIGORK+2BqgfTTsc4mSWgMoGMu6PA91H3zjpCyl5GG78
	t/FhtxSDq9R1e9TqUrfE7wx2KAKMM0BNuHxDHXMm+3kxChXWd/o+KDIlYb9j1nDbtGJw
	hrhQ==
MIME-Version: 1.0
X-Received: by 10.194.184.75 with SMTP id es11mr29576315wjc.35.1416134782744; 
	Sun, 16 Nov 2014 02:46:22 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Sun, 16 Nov 2014 02:46:22 -0800 (PST)
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E83A0E9@SHSMSX101.ccr.corp.intel.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>
	<545BEE4F.3080305@tycho.nsa.gov>
	<945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
	<CAAULxKL+z_p_JcN5pBySiQzRBP5Jc-2w+oRcg81jgkTshAQDiw@mail.gmail.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8278EA@SHSMSX101.ccr.corp.intel.com>
	<945CA011AD5F084CBEA3E851C0AB28890E83A0E9@SHSMSX101.ccr.corp.intel.com>
Date: Sun, 16 Nov 2014 12:46:22 +0200
Message-ID: <CAAULxK+krQ-gs9x5xE8eWWs7tZjLSO+FcHR-XZJf1vjFSNr1jA@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: "Xu, Quan" <quan.xu@intel.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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: multipart/mixed; boundary="===============2033914112742821442=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2033914112742821442==
Content-Type: multipart/alternative; boundary=047d7b6da766ae00610507f792fa

--047d7b6da766ae00610507f792fa
Content-Type: text/plain; charset=UTF-8

It seems that tpm_tis_request_locality did not manage to wait enough for
locality change. I suspect that if timeout_a does not have correct value it
will not wait enough in that loop and it will exit too soon. Can you do
this test again replacing timeout_a value from tpm_tis_request_locality
=>(stop = NOW() + tpm->timeout_a;) with something much bigger?
I sent a patch that was committed this week, that fixes timeout problems
that could appear and resets them to the standard value if they are
incorrect.
At least it seems that the locality 2 on your chip is enabled since you got
here.

Thanks.
Emil Condrea

On Sun, Nov 16, 2014 at 9:15 AM, Xu, Quan <quan.xu@intel.com> wrote:

> Emil / Graaf,
>         I have verified it, it is still not working when tboot is enabled.
> The attach file is txt-stat log.
> [...]
>
> ***********************************************************
>          TXT measured launch: TRUE
>          secrets flag set: TRUE
> ***********************************************************
> [...]
>
>
> Below is error when I boot vtpmmgr:
>
>
> **********************************************************
> [...]
> IOMEM Machine Base Address: FED40000
> Enabled Localities: 2
> REQ LOCALITY FAILURE
> Unable to request locality 2??
> Shutting down tpm_tis device
> Page fault at linear address 0xfed40008, rip 0x2f918, regs 0x10fc78, sp
> 0x10fd20, our_sp 0x10fc40, code 2
> Thread: main
> RIP: e030:[<000000000002f918>]
> RSP: e02b:000000000010fd20  EFLAGS: 00010202
> RAX: ffffffffffffffff RBX: 0000002000804c60 RCX: 000000000000072c
> RDX: 000000000000001e RSI: 000000007fffffff RDI: 00000000fed40008
> RBP: 000000000010fd20 R08: 000000000000000a R09: 00000000000af000
> R10: 000000000000070e R11: 00000000000006d8 R12: 0000002000804c60
> R13: 00000000fed42000 R14: 0000000000000000 R15: 0000000000000002
> base is 0x10fd20 caller is 0x24977
> base is 0x10fd40 caller is 0x24e32
> base is 0x10fd80 caller is 0x5b4b
> base is 0x10ff30 caller is 0x3510
> base is 0x10ff50 caller is 0x287a2
> base is 0x10ffe0 caller is 0x343b
>
> 10fd10: 20 fd 10 00 00 00 00 00 2b e0 00 00 00 00 00 00
> 10fd20: 40 fd 10 00 00 00 00 00 77 49 02 00 00 00 00 00
> 10fd30: 60 4c 80 00 20 00 00 00 02 00 00 00 00 00 00 00
> 10fd40: 80 fd 10 00 00 00 00 00 32 4e 02 00 00 00 00 00
>
> 10fd10: 20 fd 10 00 00 00 00 00 2b e0 00 00 00 00 00 00
> 10fd20: 40 fd 10 00 00 00 00 00 77 49 02 00 00 00 00 00
> 10fd30: 60 4c 80 00 20 00 00 00 02 00 00 00 00 00 00 00
> 10fd40: 80 fd 10 00 00 00 00 00 32 4e 02 00 00 00 00 00
>
> 2f900: 5d c3 55 48 89 e5 40 88 37 5d c3 55 48 89 e5 66
> 2f910: 89 37 5d c3 55 48 89 e5 89 37 5d c3 55 48 89 e5
> 2f920: 48 89 37 5d c3 55 48 89 e5 0f b6 07 5d c3 55 48
> 2f930: 89 e5 0f b7 07 5d c3 55 48 89 e5 8b 07 5d c3 55
> Pagetable walk from virt fed40008, base b0000:
>  L4 = 0000000127033067 (0xb1000)  [offset = 0]
>   L3 = 0000000000000000 (0xfffffffffffff000)  [offset = 3]
> Page fault in pagetable walk (access to invalid memory?).
>
> ************************************************
>
> Thanks
> Quan Xu
>
>
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Xu, Quan
> > Sent: Sunday, November 09, 2014 4:30 PM
> > To: Emil Condrea
> > Cc: Daniel De Graaf; Ian Campbell; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
> >
> > Okay, I will test it in next week.
> >
> > Thanks
> > Quan Xu
> >
> >
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Emil Condrea
> > Sent: Friday, November 07, 2014 6:42 PM
> > To: Xu, Quan
> > Cc: Daniel De Graaf; Ian Campbell; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
> >
> > Xu, my system does not support DRTM launch so if you can test it next
> week
> > it would be great.
> > Thanks
> >
> > On Fri, Nov 7, 2014 at 3:46 AM, Xu, Quan <quan.xu@intel.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: xen-devel-bounces@lists.xen.org
> > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Daniel De Graaf
> > > Sent: Friday, November 07, 2014 5:55 AM
> > > To: Emil Condrea
> > > Cc: Ian Campbell; xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
> > >
> > > On 11/05/2014 05:00 AM, Ian Campbell wrote:
> > > > CCing Daniel.
> > > >
> > > > On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
> > > >>
> > > >> I am wondering if this is known issue that when I set locality!=0 to
> > > >> vtpmmgr it does not start. It is a bit strange that every call to
> > > >> tpm_tis_status returns 255 and device-id is also FFFF:
> > > >> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
> > > >> TPM interface capabilities (0xffffffff):
> > > >>
> > > >> I am configuring vtpmmgr using:
> > > >>
> > > >> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
> > > >> memory=8
> > > >> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
> > > >> name="vtpmmgr"
> > > >> iomem=["fed40,5"]
> > > >> extra="tpmlocality=2"
> > > >>
> > > >>
> > > >> I also tried using :
> > > >> iomem=["fed40,1"]
> > > >> extra="tpmlocality=0"//works well
> > > >>
> > > >> or
> > > >> iomem=["fed42,1"]
> > > >> extra="tpmlocality=2"
> > > >> It seems that everything that is not mapped at fed40-fed41 is
> > > >> FFFFFFFF.
> > > >>
> > > >> I have an Atmel TPM chipset.
> > > >>
> > > >> Could it be a chipset problem to not handle well different
> localities?
> > > >>
> > > >> When I use locality=0, the device driver info is correct and
> > > >> everything works fine:
> > > >> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40) TPM
> interface
> > > >> capabilities (0xfd)
> > >
> > > This may be an issue with locality 2 being unavailable unless a DRTM
> > launch
> > > (tboot) is performed.  Returning all-ones is the normal response of the
> > x86
> > > chipset when unmapped MMIO regions are accessed; disabled localities of
> > > the TPM may act like this.
> > >
> > > Does your system support the DRTM launch?  If so, can you test it to
> see
> > if
> > > this is the issue?
> >
> > Emil,
> > tboot supports Intel and OEM systems that are Intel TXT-capable.
> > If your system does not support DRTM launch, I can test it in next week.
> >
> >
> > >
> > > In this case, to better support people who want to use the vTPM Manager
> > > without a DRTM launch, the features of the vTPM Manager that use the
> > TPM
> > > 1.2 PCRs may need to be disabled or implemented in an alternate manner
> > > such as embedding the data in the quote instead of in PCRs.  The
> current
> > > design was created with the assumption that systems using it would be
> > > performing a DRTM launch in order to fully secure the boot process.
> > >
> > > >> In linux kernel this information is obtained using locality 0 and
> > > >> after that other commands execute using specified locality.
> > > >>
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/
> > > >> tree/drivers/char/tpm/tpm_tis.c#n558
> > >
> > > Have you tested that other localities work for your TPM under Linux?
> > >
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Emil
> > > >>
> > >
> > > --
> > > Daniel De Graaf
> > > National Security Agency
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>

--047d7b6da766ae00610507f792fa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It seems that=C2=A0tpm_tis_request_locality did not manage=
 to wait enough for locality change. I suspect that if timeout_a does not h=
ave correct value it will not wait enough in that loop and it will exit too=
 soon. Can you do this test again replacing timeout_a value from tpm_tis_re=
quest_locality =3D&gt;(stop =3D NOW() + tpm-&gt;timeout_a;) with something =
much bigger?<div>I sent a patch that was committed this week, that fixes ti=
meout problems that could appear and resets them to the standard value if t=
hey are incorrect.<br><div>At least it seems that the locality 2 on your ch=
ip is enabled since you got here.</div><div><br></div><div>Thanks.</div></d=
iv><div>Emil Condrea</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Sun, Nov 16, 2014 at 9:15 AM, Xu, Quan <span dir=3D"ltr=
">&lt;<a href=3D"mailto:quan.xu@intel.com" target=3D"_blank">quan.xu@intel.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Emil / Graaf,<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I have verified it, it is still not working whe=
n tboot is enabled.<br>
The attach file is txt-stat log.<br>
[...]<br>
<br>
***********************************************************<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TXT measured launch: TRUE<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0secrets flag set: TRUE<br>
***********************************************************<br>
[...]<br>
<br>
<br>
Below is error when I boot vtpmmgr:<br>
<br>
<br>
**********************************************************<br>
[...]<br>
IOMEM Machine Base Address: FED40000<br>
Enabled Localities: 2<br>
REQ LOCALITY FAILURE<br>
Unable to request locality 2??<br>
Shutting down tpm_tis device<br>
Page fault at linear address 0xfed40008, rip 0x2f918, regs 0x10fc78, sp 0x1=
0fd20, our_sp 0x10fc40, code 2<br>
Thread: main<br>
RIP: e030:[&lt;000000000002f918&gt;]<br>
RSP: e02b:000000000010fd20=C2=A0 EFLAGS: 00010202<br>
RAX: ffffffffffffffff RBX: 0000002000804c60 RCX: 000000000000072c<br>
RDX: 000000000000001e RSI: 000000007fffffff RDI: 00000000fed40008<br>
RBP: 000000000010fd20 R08: 000000000000000a R09: 00000000000af000<br>
R10: 000000000000070e R11: 00000000000006d8 R12: 0000002000804c60<br>
R13: 00000000fed42000 R14: 0000000000000000 R15: 0000000000000002<br>
base is 0x10fd20 caller is 0x24977<br>
base is 0x10fd40 caller is 0x24e32<br>
base is 0x10fd80 caller is 0x5b4b<br>
base is 0x10ff30 caller is 0x3510<br>
base is 0x10ff50 caller is 0x287a2<br>
base is 0x10ffe0 caller is 0x343b<br>
<br>
10fd10: 20 fd 10 00 00 00 00 00 2b e0 00 00 00 00 00 00<br>
10fd20: 40 fd 10 00 00 00 00 00 77 49 02 00 00 00 00 00<br>
10fd30: 60 4c 80 00 20 00 00 00 02 00 00 00 00 00 00 00<br>
10fd40: 80 fd 10 00 00 00 00 00 32 4e 02 00 00 00 00 00<br>
<br>
10fd10: 20 fd 10 00 00 00 00 00 2b e0 00 00 00 00 00 00<br>
10fd20: 40 fd 10 00 00 00 00 00 77 49 02 00 00 00 00 00<br>
10fd30: 60 4c 80 00 20 00 00 00 02 00 00 00 00 00 00 00<br>
10fd40: 80 fd 10 00 00 00 00 00 32 4e 02 00 00 00 00 00<br>
<br>
2f900: 5d c3 55 48 89 e5 40 88 37 5d c3 55 48 89 e5 66<br>
2f910: 89 37 5d c3 55 48 89 e5 89 37 5d c3 55 48 89 e5<br>
2f920: 48 89 37 5d c3 55 48 89 e5 0f b6 07 5d c3 55 48<br>
2f930: 89 e5 0f b7 07 5d c3 55 48 89 e5 8b 07 5d c3 55<br>
Pagetable walk from virt fed40008, base b0000:<br>
=C2=A0L4 =3D 0000000127033067 (0xb1000)=C2=A0 [offset =3D 0]<br>
=C2=A0 L3 =3D 0000000000000000 (0xfffffffffffff000)=C2=A0 [offset =3D 3]<br=
>
Page fault in pagetable walk (access to invalid memory?).<br>
<br>
************************************************<br>
<br>
Thanks<br>
<span class=3D"HOEnZb"><font color=3D"#888888">Quan Xu<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
&gt; -----Original Message-----<br>
&gt; From: <a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-bou=
nces@lists.xen.org</a><br>
&gt; [mailto:<a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-b=
ounces@lists.xen.org</a>] On Behalf Of Xu, Quan<br>
&gt; Sent: Sunday, November 09, 2014 4:30 PM<br>
&gt; To: Emil Condrea<br>
&gt; Cc: Daniel De Graaf; Ian Campbell; <a href=3D"mailto:xen-devel@lists.x=
en.org">xen-devel@lists.xen.org</a><br>
&gt; Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=3D0<=
br>
&gt;<br>
&gt; Okay, I will test it in next week.<br>
&gt;<br>
&gt; Thanks<br>
&gt; Quan Xu<br>
&gt;<br>
&gt;<br>
&gt; From: <a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-bou=
nces@lists.xen.org</a><br>
&gt; [mailto:<a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-b=
ounces@lists.xen.org</a>] On Behalf Of Emil Condrea<br>
&gt; Sent: Friday, November 07, 2014 6:42 PM<br>
&gt; To: Xu, Quan<br>
&gt; Cc: Daniel De Graaf; Ian Campbell; <a href=3D"mailto:xen-devel@lists.x=
en.org">xen-devel@lists.xen.org</a><br>
&gt; Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=3D0<=
br>
&gt;<br>
&gt; Xu, my system does not support DRTM launch so if you can test it next =
week<br>
&gt; it would be great.<br>
&gt; Thanks<br>
&gt;<br>
&gt; On Fri, Nov 7, 2014 at 3:46 AM, Xu, Quan &lt;<a href=3D"mailto:quan.xu=
@intel.com">quan.xu@intel.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: <a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-deve=
l-bounces@lists.xen.org</a><br>
&gt; &gt; [mailto:<a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-de=
vel-bounces@lists.xen.org</a>] On Behalf Of Daniel De Graaf<br>
&gt; &gt; Sent: Friday, November 07, 2014 5:55 AM<br>
&gt; &gt; To: Emil Condrea<br>
&gt; &gt; Cc: Ian Campbell; <a href=3D"mailto:xen-devel@lists.xen.org">xen-=
devel@lists.xen.org</a><br>
&gt; &gt; Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=
=3D0<br>
&gt; &gt;<br>
&gt; &gt; On 11/05/2014 05:00 AM, Ian Campbell wrote:<br>
&gt; &gt; &gt; CCing Daniel.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; I am wondering if this is known issue that when I set lo=
cality!=3D0 to<br>
&gt; &gt; &gt;&gt; vtpmmgr it does not start. It is a bit strange that ever=
y call to<br>
&gt; &gt; &gt;&gt; tpm_tis_status returns 255 and device-id is also FFFF:<b=
r>
&gt; &gt; &gt;&gt; 1.2 TPM (device-id=3D0xFFFF vendor-id =3D FFFF rev-id =
=3D FF).<br>
&gt; &gt; &gt;&gt; TPM interface capabilities (0xffffffff):<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; I am configuring vtpmmgr using:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; kernel=3D&quot;/usr/local/lib/xen/boot/vtpmmgr-stubdom.g=
z&quot;<br>
&gt; &gt; &gt;&gt; memory=3D8<br>
&gt; &gt; &gt;&gt; disk=3D[&quot;file:/var/vtpmmgr-stubdom.img,hda,w&quot;]=
<br>
&gt; &gt; &gt;&gt; name=3D&quot;vtpmmgr&quot;<br>
&gt; &gt; &gt;&gt; iomem=3D[&quot;fed40,5&quot;]<br>
&gt; &gt; &gt;&gt; extra=3D&quot;tpmlocality=3D2&quot;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; I also tried using :<br>
&gt; &gt; &gt;&gt; iomem=3D[&quot;fed40,1&quot;]<br>
&gt; &gt; &gt;&gt; extra=3D&quot;tpmlocality=3D0&quot;//works well<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; or<br>
&gt; &gt; &gt;&gt; iomem=3D[&quot;fed42,1&quot;]<br>
&gt; &gt; &gt;&gt; extra=3D&quot;tpmlocality=3D2&quot;<br>
&gt; &gt; &gt;&gt; It seems that everything that is not mapped at fed40-fed=
41 is<br>
&gt; &gt; &gt;&gt; FFFFFFFF.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; I have an Atmel TPM chipset.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Could it be a chipset problem to not handle well differe=
nt localities?<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; When I use locality=3D0, the device driver info is corre=
ct and<br>
&gt; &gt; &gt;&gt; everything works fine:<br>
&gt; &gt; &gt;&gt; 1.2 TPM (device-id=3D0x3204 vendor-id =3D 1114 rev-id =
=3D 40) TPM interface<br>
&gt; &gt; &gt;&gt; capabilities (0xfd)<br>
&gt; &gt;<br>
&gt; &gt; This may be an issue with locality 2 being unavailable unless a D=
RTM<br>
&gt; launch<br>
&gt; &gt; (tboot) is performed.=C2=A0 Returning all-ones is the normal resp=
onse of the<br>
&gt; x86<br>
&gt; &gt; chipset when unmapped MMIO regions are accessed; disabled localit=
ies of<br>
&gt; &gt; the TPM may act like this.<br>
&gt; &gt;<br>
&gt; &gt; Does your system support the DRTM launch?=C2=A0 If so, can you te=
st it to see<br>
&gt; if<br>
&gt; &gt; this is the issue?<br>
&gt;<br>
&gt; Emil,<br>
&gt; tboot supports Intel and OEM systems that are Intel TXT-capable.<br>
&gt; If your system does not support DRTM launch, I can test it in next wee=
k.<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; In this case, to better support people who want to use the vTPM M=
anager<br>
&gt; &gt; without a DRTM launch, the features of the vTPM Manager that use =
the<br>
&gt; TPM<br>
&gt; &gt; 1.2 PCRs may need to be disabled or implemented in an alternate m=
anner<br>
&gt; &gt; such as embedding the data in the quote instead of in PCRs.=C2=A0=
 The current<br>
&gt; &gt; design was created with the assumption that systems using it woul=
d be<br>
&gt; &gt; performing a DRTM launch in order to fully secure the boot proces=
s.<br>
&gt; &gt;<br>
&gt; &gt; &gt;&gt; In linux kernel this information is obtained using local=
ity 0 and<br>
&gt; &gt; &gt;&gt; after that other commands execute using specified locali=
ty.<br>
&gt; &gt; &gt;&gt; <a href=3D"https://git.kernel.org/cgit/linux/kernel/git/=
stable/linux-stable.git/" target=3D"_blank">https://git.kernel.org/cgit/lin=
ux/kernel/git/stable/linux-stable.git/</a><br>
&gt; &gt; &gt;&gt; tree/drivers/char/tpm/tpm_tis.c#n558<br>
&gt; &gt;<br>
&gt; &gt; Have you tested that other localities work for your TPM under Lin=
ux?<br>
&gt; &gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Thanks,<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Emil<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Daniel De Graaf<br>
&gt; &gt; National Security Agency<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Xen-devel mailing list<br>
&gt; &gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.or=
g</a><br>
&gt; &gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http=
://lists.xen.org/xen-devel</a><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>
</div></div></blockquote></div><br></div>

--047d7b6da766ae00610507f792fa--


--===============2033914112742821442==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2033914112742821442==--


From xen-devel-bounces@lists.xen.org Sun Nov 16 10:46:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 10: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 1XpxLf-0002aA-0P; Sun, 16 Nov 2014 10:46:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1XpxLd-0002a5-NA
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 10:46:25 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	5C/5F-02707-08088645; Sun, 16 Nov 2014 10:46:24 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416134782!11601721!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1650 invoked from network); 16 Nov 2014 10:46:23 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 10:46:23 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so36543wiv.12
	for <xen-devel@lists.xen.org>; Sun, 16 Nov 2014 02:46:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=rmrdfIL3KK3y6/6yoU8RGDTphJVgVDiEKajgJRZhL2Q=;
	b=n47evbEY8DOT2k3Ig3FkNhJX10RY4cjMh7VjnML+Oi1rGSiyykxBJUXUz7JiqijvV4
	IHE7k2GYnKotnDhMpKmSSonebHWrtJh6IgPUE6Yyds7cCQWjrSsVi4H8c8wEemKtRRPa
	mF2Gxh1aMfTfQREqadaiVubfRwV4lWON+j6+4bjIgkUPDAcp6MAYYOpG8BH7qMT8S8Zn
	qnYeqWEYlzm0ObAPYD/vk55SoIGORK+2BqgfTTsc4mSWgMoGMu6PA91H3zjpCyl5GG78
	t/FhtxSDq9R1e9TqUrfE7wx2KAKMM0BNuHxDHXMm+3kxChXWd/o+KDIlYb9j1nDbtGJw
	hrhQ==
MIME-Version: 1.0
X-Received: by 10.194.184.75 with SMTP id es11mr29576315wjc.35.1416134782744; 
	Sun, 16 Nov 2014 02:46:22 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Sun, 16 Nov 2014 02:46:22 -0800 (PST)
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E83A0E9@SHSMSX101.ccr.corp.intel.com>
References: <CAAULxKL1vcz3bjzGAW7=7yB6dz4w=96nJYXWP1r1HaV-Nupdxw@mail.gmail.com>
	<1415181601.11486.69.camel@citrix.com>
	<545BEE4F.3080305@tycho.nsa.gov>
	<945CA011AD5F084CBEA3E851C0AB28890E820EDD@SHSMSX101.ccr.corp.intel.com>
	<CAAULxKL+z_p_JcN5pBySiQzRBP5Jc-2w+oRcg81jgkTshAQDiw@mail.gmail.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8278EA@SHSMSX101.ccr.corp.intel.com>
	<945CA011AD5F084CBEA3E851C0AB28890E83A0E9@SHSMSX101.ccr.corp.intel.com>
Date: Sun, 16 Nov 2014 12:46:22 +0200
Message-ID: <CAAULxK+krQ-gs9x5xE8eWWs7tZjLSO+FcHR-XZJf1vjFSNr1jA@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: "Xu, Quan" <quan.xu@intel.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=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: multipart/mixed; boundary="===============2033914112742821442=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2033914112742821442==
Content-Type: multipart/alternative; boundary=047d7b6da766ae00610507f792fa

--047d7b6da766ae00610507f792fa
Content-Type: text/plain; charset=UTF-8

It seems that tpm_tis_request_locality did not manage to wait enough for
locality change. I suspect that if timeout_a does not have correct value it
will not wait enough in that loop and it will exit too soon. Can you do
this test again replacing timeout_a value from tpm_tis_request_locality
=>(stop = NOW() + tpm->timeout_a;) with something much bigger?
I sent a patch that was committed this week, that fixes timeout problems
that could appear and resets them to the standard value if they are
incorrect.
At least it seems that the locality 2 on your chip is enabled since you got
here.

Thanks.
Emil Condrea

On Sun, Nov 16, 2014 at 9:15 AM, Xu, Quan <quan.xu@intel.com> wrote:

> Emil / Graaf,
>         I have verified it, it is still not working when tboot is enabled.
> The attach file is txt-stat log.
> [...]
>
> ***********************************************************
>          TXT measured launch: TRUE
>          secrets flag set: TRUE
> ***********************************************************
> [...]
>
>
> Below is error when I boot vtpmmgr:
>
>
> **********************************************************
> [...]
> IOMEM Machine Base Address: FED40000
> Enabled Localities: 2
> REQ LOCALITY FAILURE
> Unable to request locality 2??
> Shutting down tpm_tis device
> Page fault at linear address 0xfed40008, rip 0x2f918, regs 0x10fc78, sp
> 0x10fd20, our_sp 0x10fc40, code 2
> Thread: main
> RIP: e030:[<000000000002f918>]
> RSP: e02b:000000000010fd20  EFLAGS: 00010202
> RAX: ffffffffffffffff RBX: 0000002000804c60 RCX: 000000000000072c
> RDX: 000000000000001e RSI: 000000007fffffff RDI: 00000000fed40008
> RBP: 000000000010fd20 R08: 000000000000000a R09: 00000000000af000
> R10: 000000000000070e R11: 00000000000006d8 R12: 0000002000804c60
> R13: 00000000fed42000 R14: 0000000000000000 R15: 0000000000000002
> base is 0x10fd20 caller is 0x24977
> base is 0x10fd40 caller is 0x24e32
> base is 0x10fd80 caller is 0x5b4b
> base is 0x10ff30 caller is 0x3510
> base is 0x10ff50 caller is 0x287a2
> base is 0x10ffe0 caller is 0x343b
>
> 10fd10: 20 fd 10 00 00 00 00 00 2b e0 00 00 00 00 00 00
> 10fd20: 40 fd 10 00 00 00 00 00 77 49 02 00 00 00 00 00
> 10fd30: 60 4c 80 00 20 00 00 00 02 00 00 00 00 00 00 00
> 10fd40: 80 fd 10 00 00 00 00 00 32 4e 02 00 00 00 00 00
>
> 10fd10: 20 fd 10 00 00 00 00 00 2b e0 00 00 00 00 00 00
> 10fd20: 40 fd 10 00 00 00 00 00 77 49 02 00 00 00 00 00
> 10fd30: 60 4c 80 00 20 00 00 00 02 00 00 00 00 00 00 00
> 10fd40: 80 fd 10 00 00 00 00 00 32 4e 02 00 00 00 00 00
>
> 2f900: 5d c3 55 48 89 e5 40 88 37 5d c3 55 48 89 e5 66
> 2f910: 89 37 5d c3 55 48 89 e5 89 37 5d c3 55 48 89 e5
> 2f920: 48 89 37 5d c3 55 48 89 e5 0f b6 07 5d c3 55 48
> 2f930: 89 e5 0f b7 07 5d c3 55 48 89 e5 8b 07 5d c3 55
> Pagetable walk from virt fed40008, base b0000:
>  L4 = 0000000127033067 (0xb1000)  [offset = 0]
>   L3 = 0000000000000000 (0xfffffffffffff000)  [offset = 3]
> Page fault in pagetable walk (access to invalid memory?).
>
> ************************************************
>
> Thanks
> Quan Xu
>
>
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Xu, Quan
> > Sent: Sunday, November 09, 2014 4:30 PM
> > To: Emil Condrea
> > Cc: Daniel De Graaf; Ian Campbell; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
> >
> > Okay, I will test it in next week.
> >
> > Thanks
> > Quan Xu
> >
> >
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Emil Condrea
> > Sent: Friday, November 07, 2014 6:42 PM
> > To: Xu, Quan
> > Cc: Daniel De Graaf; Ian Campbell; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
> >
> > Xu, my system does not support DRTM launch so if you can test it next
> week
> > it would be great.
> > Thanks
> >
> > On Fri, Nov 7, 2014 at 3:46 AM, Xu, Quan <quan.xu@intel.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: xen-devel-bounces@lists.xen.org
> > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Daniel De Graaf
> > > Sent: Friday, November 07, 2014 5:55 AM
> > > To: Emil Condrea
> > > Cc: Ian Campbell; xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
> > >
> > > On 11/05/2014 05:00 AM, Ian Campbell wrote:
> > > > CCing Daniel.
> > > >
> > > > On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
> > > >>
> > > >> I am wondering if this is known issue that when I set locality!=0 to
> > > >> vtpmmgr it does not start. It is a bit strange that every call to
> > > >> tpm_tis_status returns 255 and device-id is also FFFF:
> > > >> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
> > > >> TPM interface capabilities (0xffffffff):
> > > >>
> > > >> I am configuring vtpmmgr using:
> > > >>
> > > >> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
> > > >> memory=8
> > > >> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
> > > >> name="vtpmmgr"
> > > >> iomem=["fed40,5"]
> > > >> extra="tpmlocality=2"
> > > >>
> > > >>
> > > >> I also tried using :
> > > >> iomem=["fed40,1"]
> > > >> extra="tpmlocality=0"//works well
> > > >>
> > > >> or
> > > >> iomem=["fed42,1"]
> > > >> extra="tpmlocality=2"
> > > >> It seems that everything that is not mapped at fed40-fed41 is
> > > >> FFFFFFFF.
> > > >>
> > > >> I have an Atmel TPM chipset.
> > > >>
> > > >> Could it be a chipset problem to not handle well different
> localities?
> > > >>
> > > >> When I use locality=0, the device driver info is correct and
> > > >> everything works fine:
> > > >> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40) TPM
> interface
> > > >> capabilities (0xfd)
> > >
> > > This may be an issue with locality 2 being unavailable unless a DRTM
> > launch
> > > (tboot) is performed.  Returning all-ones is the normal response of the
> > x86
> > > chipset when unmapped MMIO regions are accessed; disabled localities of
> > > the TPM may act like this.
> > >
> > > Does your system support the DRTM launch?  If so, can you test it to
> see
> > if
> > > this is the issue?
> >
> > Emil,
> > tboot supports Intel and OEM systems that are Intel TXT-capable.
> > If your system does not support DRTM launch, I can test it in next week.
> >
> >
> > >
> > > In this case, to better support people who want to use the vTPM Manager
> > > without a DRTM launch, the features of the vTPM Manager that use the
> > TPM
> > > 1.2 PCRs may need to be disabled or implemented in an alternate manner
> > > such as embedding the data in the quote instead of in PCRs.  The
> current
> > > design was created with the assumption that systems using it would be
> > > performing a DRTM launch in order to fully secure the boot process.
> > >
> > > >> In linux kernel this information is obtained using locality 0 and
> > > >> after that other commands execute using specified locality.
> > > >>
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/
> > > >> tree/drivers/char/tpm/tpm_tis.c#n558
> > >
> > > Have you tested that other localities work for your TPM under Linux?
> > >
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Emil
> > > >>
> > >
> > > --
> > > Daniel De Graaf
> > > National Security Agency
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>

--047d7b6da766ae00610507f792fa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It seems that=C2=A0tpm_tis_request_locality did not manage=
 to wait enough for locality change. I suspect that if timeout_a does not h=
ave correct value it will not wait enough in that loop and it will exit too=
 soon. Can you do this test again replacing timeout_a value from tpm_tis_re=
quest_locality =3D&gt;(stop =3D NOW() + tpm-&gt;timeout_a;) with something =
much bigger?<div>I sent a patch that was committed this week, that fixes ti=
meout problems that could appear and resets them to the standard value if t=
hey are incorrect.<br><div>At least it seems that the locality 2 on your ch=
ip is enabled since you got here.</div><div><br></div><div>Thanks.</div></d=
iv><div>Emil Condrea</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Sun, Nov 16, 2014 at 9:15 AM, Xu, Quan <span dir=3D"ltr=
">&lt;<a href=3D"mailto:quan.xu@intel.com" target=3D"_blank">quan.xu@intel.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Emil / Graaf,<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I have verified it, it is still not working whe=
n tboot is enabled.<br>
The attach file is txt-stat log.<br>
[...]<br>
<br>
***********************************************************<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TXT measured launch: TRUE<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0secrets flag set: TRUE<br>
***********************************************************<br>
[...]<br>
<br>
<br>
Below is error when I boot vtpmmgr:<br>
<br>
<br>
**********************************************************<br>
[...]<br>
IOMEM Machine Base Address: FED40000<br>
Enabled Localities: 2<br>
REQ LOCALITY FAILURE<br>
Unable to request locality 2??<br>
Shutting down tpm_tis device<br>
Page fault at linear address 0xfed40008, rip 0x2f918, regs 0x10fc78, sp 0x1=
0fd20, our_sp 0x10fc40, code 2<br>
Thread: main<br>
RIP: e030:[&lt;000000000002f918&gt;]<br>
RSP: e02b:000000000010fd20=C2=A0 EFLAGS: 00010202<br>
RAX: ffffffffffffffff RBX: 0000002000804c60 RCX: 000000000000072c<br>
RDX: 000000000000001e RSI: 000000007fffffff RDI: 00000000fed40008<br>
RBP: 000000000010fd20 R08: 000000000000000a R09: 00000000000af000<br>
R10: 000000000000070e R11: 00000000000006d8 R12: 0000002000804c60<br>
R13: 00000000fed42000 R14: 0000000000000000 R15: 0000000000000002<br>
base is 0x10fd20 caller is 0x24977<br>
base is 0x10fd40 caller is 0x24e32<br>
base is 0x10fd80 caller is 0x5b4b<br>
base is 0x10ff30 caller is 0x3510<br>
base is 0x10ff50 caller is 0x287a2<br>
base is 0x10ffe0 caller is 0x343b<br>
<br>
10fd10: 20 fd 10 00 00 00 00 00 2b e0 00 00 00 00 00 00<br>
10fd20: 40 fd 10 00 00 00 00 00 77 49 02 00 00 00 00 00<br>
10fd30: 60 4c 80 00 20 00 00 00 02 00 00 00 00 00 00 00<br>
10fd40: 80 fd 10 00 00 00 00 00 32 4e 02 00 00 00 00 00<br>
<br>
10fd10: 20 fd 10 00 00 00 00 00 2b e0 00 00 00 00 00 00<br>
10fd20: 40 fd 10 00 00 00 00 00 77 49 02 00 00 00 00 00<br>
10fd30: 60 4c 80 00 20 00 00 00 02 00 00 00 00 00 00 00<br>
10fd40: 80 fd 10 00 00 00 00 00 32 4e 02 00 00 00 00 00<br>
<br>
2f900: 5d c3 55 48 89 e5 40 88 37 5d c3 55 48 89 e5 66<br>
2f910: 89 37 5d c3 55 48 89 e5 89 37 5d c3 55 48 89 e5<br>
2f920: 48 89 37 5d c3 55 48 89 e5 0f b6 07 5d c3 55 48<br>
2f930: 89 e5 0f b7 07 5d c3 55 48 89 e5 8b 07 5d c3 55<br>
Pagetable walk from virt fed40008, base b0000:<br>
=C2=A0L4 =3D 0000000127033067 (0xb1000)=C2=A0 [offset =3D 0]<br>
=C2=A0 L3 =3D 0000000000000000 (0xfffffffffffff000)=C2=A0 [offset =3D 3]<br=
>
Page fault in pagetable walk (access to invalid memory?).<br>
<br>
************************************************<br>
<br>
Thanks<br>
<span class=3D"HOEnZb"><font color=3D"#888888">Quan Xu<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
&gt; -----Original Message-----<br>
&gt; From: <a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-bou=
nces@lists.xen.org</a><br>
&gt; [mailto:<a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-b=
ounces@lists.xen.org</a>] On Behalf Of Xu, Quan<br>
&gt; Sent: Sunday, November 09, 2014 4:30 PM<br>
&gt; To: Emil Condrea<br>
&gt; Cc: Daniel De Graaf; Ian Campbell; <a href=3D"mailto:xen-devel@lists.x=
en.org">xen-devel@lists.xen.org</a><br>
&gt; Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=3D0<=
br>
&gt;<br>
&gt; Okay, I will test it in next week.<br>
&gt;<br>
&gt; Thanks<br>
&gt; Quan Xu<br>
&gt;<br>
&gt;<br>
&gt; From: <a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-bou=
nces@lists.xen.org</a><br>
&gt; [mailto:<a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-devel-b=
ounces@lists.xen.org</a>] On Behalf Of Emil Condrea<br>
&gt; Sent: Friday, November 07, 2014 6:42 PM<br>
&gt; To: Xu, Quan<br>
&gt; Cc: Daniel De Graaf; Ian Campbell; <a href=3D"mailto:xen-devel@lists.x=
en.org">xen-devel@lists.xen.org</a><br>
&gt; Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=3D0<=
br>
&gt;<br>
&gt; Xu, my system does not support DRTM launch so if you can test it next =
week<br>
&gt; it would be great.<br>
&gt; Thanks<br>
&gt;<br>
&gt; On Fri, Nov 7, 2014 at 3:46 AM, Xu, Quan &lt;<a href=3D"mailto:quan.xu=
@intel.com">quan.xu@intel.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: <a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-deve=
l-bounces@lists.xen.org</a><br>
&gt; &gt; [mailto:<a href=3D"mailto:xen-devel-bounces@lists.xen.org">xen-de=
vel-bounces@lists.xen.org</a>] On Behalf Of Daniel De Graaf<br>
&gt; &gt; Sent: Friday, November 07, 2014 5:55 AM<br>
&gt; &gt; To: Emil Condrea<br>
&gt; &gt; Cc: Ian Campbell; <a href=3D"mailto:xen-devel@lists.xen.org">xen-=
devel@lists.xen.org</a><br>
&gt; &gt; Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=
=3D0<br>
&gt; &gt;<br>
&gt; &gt; On 11/05/2014 05:00 AM, Ian Campbell wrote:<br>
&gt; &gt; &gt; CCing Daniel.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; I am wondering if this is known issue that when I set lo=
cality!=3D0 to<br>
&gt; &gt; &gt;&gt; vtpmmgr it does not start. It is a bit strange that ever=
y call to<br>
&gt; &gt; &gt;&gt; tpm_tis_status returns 255 and device-id is also FFFF:<b=
r>
&gt; &gt; &gt;&gt; 1.2 TPM (device-id=3D0xFFFF vendor-id =3D FFFF rev-id =
=3D FF).<br>
&gt; &gt; &gt;&gt; TPM interface capabilities (0xffffffff):<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; I am configuring vtpmmgr using:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; kernel=3D&quot;/usr/local/lib/xen/boot/vtpmmgr-stubdom.g=
z&quot;<br>
&gt; &gt; &gt;&gt; memory=3D8<br>
&gt; &gt; &gt;&gt; disk=3D[&quot;file:/var/vtpmmgr-stubdom.img,hda,w&quot;]=
<br>
&gt; &gt; &gt;&gt; name=3D&quot;vtpmmgr&quot;<br>
&gt; &gt; &gt;&gt; iomem=3D[&quot;fed40,5&quot;]<br>
&gt; &gt; &gt;&gt; extra=3D&quot;tpmlocality=3D2&quot;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; I also tried using :<br>
&gt; &gt; &gt;&gt; iomem=3D[&quot;fed40,1&quot;]<br>
&gt; &gt; &gt;&gt; extra=3D&quot;tpmlocality=3D0&quot;//works well<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; or<br>
&gt; &gt; &gt;&gt; iomem=3D[&quot;fed42,1&quot;]<br>
&gt; &gt; &gt;&gt; extra=3D&quot;tpmlocality=3D2&quot;<br>
&gt; &gt; &gt;&gt; It seems that everything that is not mapped at fed40-fed=
41 is<br>
&gt; &gt; &gt;&gt; FFFFFFFF.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; I have an Atmel TPM chipset.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Could it be a chipset problem to not handle well differe=
nt localities?<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; When I use locality=3D0, the device driver info is corre=
ct and<br>
&gt; &gt; &gt;&gt; everything works fine:<br>
&gt; &gt; &gt;&gt; 1.2 TPM (device-id=3D0x3204 vendor-id =3D 1114 rev-id =
=3D 40) TPM interface<br>
&gt; &gt; &gt;&gt; capabilities (0xfd)<br>
&gt; &gt;<br>
&gt; &gt; This may be an issue with locality 2 being unavailable unless a D=
RTM<br>
&gt; launch<br>
&gt; &gt; (tboot) is performed.=C2=A0 Returning all-ones is the normal resp=
onse of the<br>
&gt; x86<br>
&gt; &gt; chipset when unmapped MMIO regions are accessed; disabled localit=
ies of<br>
&gt; &gt; the TPM may act like this.<br>
&gt; &gt;<br>
&gt; &gt; Does your system support the DRTM launch?=C2=A0 If so, can you te=
st it to see<br>
&gt; if<br>
&gt; &gt; this is the issue?<br>
&gt;<br>
&gt; Emil,<br>
&gt; tboot supports Intel and OEM systems that are Intel TXT-capable.<br>
&gt; If your system does not support DRTM launch, I can test it in next wee=
k.<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; In this case, to better support people who want to use the vTPM M=
anager<br>
&gt; &gt; without a DRTM launch, the features of the vTPM Manager that use =
the<br>
&gt; TPM<br>
&gt; &gt; 1.2 PCRs may need to be disabled or implemented in an alternate m=
anner<br>
&gt; &gt; such as embedding the data in the quote instead of in PCRs.=C2=A0=
 The current<br>
&gt; &gt; design was created with the assumption that systems using it woul=
d be<br>
&gt; &gt; performing a DRTM launch in order to fully secure the boot proces=
s.<br>
&gt; &gt;<br>
&gt; &gt; &gt;&gt; In linux kernel this information is obtained using local=
ity 0 and<br>
&gt; &gt; &gt;&gt; after that other commands execute using specified locali=
ty.<br>
&gt; &gt; &gt;&gt; <a href=3D"https://git.kernel.org/cgit/linux/kernel/git/=
stable/linux-stable.git/" target=3D"_blank">https://git.kernel.org/cgit/lin=
ux/kernel/git/stable/linux-stable.git/</a><br>
&gt; &gt; &gt;&gt; tree/drivers/char/tpm/tpm_tis.c#n558<br>
&gt; &gt;<br>
&gt; &gt; Have you tested that other localities work for your TPM under Lin=
ux?<br>
&gt; &gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Thanks,<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Emil<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Daniel De Graaf<br>
&gt; &gt; National Security Agency<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Xen-devel mailing list<br>
&gt; &gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.or=
g</a><br>
&gt; &gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http=
://lists.xen.org/xen-devel</a><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>
</div></div></blockquote></div><br></div>

--047d7b6da766ae00610507f792fa--


--===============2033914112742821442==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2033914112742821442==--


From xen-devel-bounces@lists.xen.org Sun Nov 16 12:27:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 12:27:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpyuw-0003MB-ON; Sun, 16 Nov 2014 12:26:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xpyuu-0003M6-Va
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 12:26:57 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	41/8C-27785-01898645; Sun, 16 Nov 2014 12:26:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416140813!12859422!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22399 invoked from network); 16 Nov 2014 12:26:55 -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;
	16 Nov 2014 12:26:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,397,1413244800"; d="scan'208";a="191832065"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 07:26:51 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpyup-0006co-N2;
	Sun, 16 Nov 2014 12:26:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpyup-0001Cz-9a;
	Sun, 16 Nov 2014 12:26:51 +0000
Date: Sun, 16 Nov 2014 12:26:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31599-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11605
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31599: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6810269630997173470=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6810269630997173470==
Content-Type: text/plain
Content-Length: 11373
Content-Transfer-Encoding: quoted-printable

flight 31599 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31599/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                4e70f9271dabc58fbf14680843bfac510c193152
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liang <liang.z.li@intel.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12699 lines long.)


--===============6810269630997173470==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6810269630997173470==--

From xen-devel-bounces@lists.xen.org Sun Nov 16 12:27:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 12:27:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xpyuw-0003MB-ON; Sun, 16 Nov 2014 12:26:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xpyuu-0003M6-Va
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 12:26:57 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	41/8C-27785-01898645; Sun, 16 Nov 2014 12:26:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416140813!12859422!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22399 invoked from network); 16 Nov 2014 12:26:55 -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;
	16 Nov 2014 12:26:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,397,1413244800"; d="scan'208";a="191832065"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 07:26:51 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xpyup-0006co-N2;
	Sun, 16 Nov 2014 12:26:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xpyup-0001Cz-9a;
	Sun, 16 Nov 2014 12:26:51 +0000
Date: Sun, 16 Nov 2014 12:26:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31599-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11605
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31599: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6810269630997173470=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6810269630997173470==
Content-Type: text/plain
Content-Length: 11373
Content-Transfer-Encoding: quoted-printable

flight 31599 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31599/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                4e70f9271dabc58fbf14680843bfac510c193152
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liang <liang.z.li@intel.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12699 lines long.)


--===============6810269630997173470==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6810269630997173470==--

From xen-devel-bounces@lists.xen.org Sun Nov 16 13:09:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 13:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpzZW-0003iy-9g; Sun, 16 Nov 2014 13:08:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo.kernel.org@gmail.com>) id 1XpzZV-0003it-Bk
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 13:08:53 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	6C/F4-23865-4E1A8645; Sun, 16 Nov 2014 13:08:52 +0000
X-Env-Sender: mingo.kernel.org@gmail.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416143331!11649813!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30788 invoked from network); 16 Nov 2014 13:08:52 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 13:08:52 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so3341280wiw.2
	for <xen-devel@lists.xensource.com>;
	Sun, 16 Nov 2014 05:08:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=Y3d1az05/M0beykXUE6pqh3sibCnjnQCTjVl1qoZojY=;
	b=eLGlRvP8zPLYFrMhB/YWX0ePVC0e33X8RYmYF5e0GjmlfXUvUX5KZf7AHHpQ8cAMD7
	RNuce8EsNGoSsinFyQ1qg+FQQn8CeHblXOgR6Bhlp5muaIP3QbhbYIn8CauedEjNcR+W
	t1DiDp/r2Ec8ayCJCTAO6ZwUZTZqXSNnbG79eA87SPposcbnnZC20EcDeS4kLX52A2vw
	pfdobW1gXZeW573VDyUSItFtWpnwwlVvUKzyKecu8DeGUIMjvl0nPDlwkGA8b3tUET0z
	Sg2gB6LR3wGGw6+gnn3Y/y4Mx0PGcRbwm2RmkVGs6zqRaItGjNXYqSkDDIovlnGu8duB
	fgnA==
X-Received: by 10.194.85.83 with SMTP id f19mr31376602wjz.20.1416143331487;
	Sun, 16 Nov 2014 05:08:51 -0800 (PST)
Received: from gmail.com (54033583.catv.pool.telekom.hu. [84.3.53.131])
	by mx.google.com with ESMTPSA id cq4sm3005525wjc.35.2014.11.16.05.08.49
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 16 Nov 2014 05:08:50 -0800 (PST)
Date: Sun, 16 Nov 2014 14:08:47 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141116130847.GA4736@gmail.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Length: 1954
Content-Disposition: inline
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, tglx@linutronix.de, plagnioj@jcrosoft.com,
	ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CiogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPiB3cm90ZToKCj4gIGFyY2gveDg2L2lu
Y2x1ZGUvYXNtL2NhY2hlZmx1c2guaCAgICAgICAgIHwgIDM4ICsrKystLS0KCkZZSSwgdGhpcyBz
ZXJpZXMgYnJlYWtzIHRoZSBVTUwgYnVpbGQ6CgpJbiBmaWxlIGluY2x1ZGVkIGZyb20gL2hvbWUv
bWluZ28vdGlwL2luY2x1ZGUvbGludXgvaGlnaG1lbS5oOjExOjAsCiAgICAgICAgICAgICAgICAg
ZnJvbSAvaG9tZS9taW5nby90aXAvaW5jbHVkZS9saW51eC9wYWdlbWFwLmg6MTAsCiAgICAgICAg
ICAgICAgICAgZnJvbSAvaG9tZS9taW5nby90aXAvaW5jbHVkZS9saW51eC9tZW1wb2xpY3kuaDox
NCwKICAgICAgICAgICAgICAgICBmcm9tIC9ob21lL21pbmdvL3RpcC9pbmNsdWRlL2xpbnV4L3No
bWVtX2ZzLmg6NiwKICAgICAgICAgICAgICAgICBmcm9tIC9ob21lL21pbmdvL3RpcC9pbml0L2Rv
X21vdW50cy5jOjMwOgovaG9tZS9taW5nby90aXAvYXJjaC94ODYvaW5jbHVkZS9hc20vY2FjaGVm
bHVzaC5oOjY3OjM2OiBlcnJvcjogcmV0dXJuIHR5cGUgaXMgYW4gaW5jb21wbGV0ZSB0eXBlCiBz
dGF0aWMgaW5saW5lIGVudW0gcGFnZV9jYWNoZV9tb2RlIGdldF9wYWdlX21lbXR5cGUoc3RydWN0
IHBhZ2UgKnBnKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeCi9ob21lL21p
bmdvL3RpcC9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jYWNoZWZsdXNoLmg6IEluIGZ1bmN0aW9uIOKA
mGdldF9wYWdlX21lbXR5cGXigJk6Ci9ob21lL21pbmdvL3RpcC9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9jYWNoZWZsdXNoLmg6Njk6Mjogd2FybmluZzog4oCYcmV0dXJu4oCZIHdpdGggYSB2YWx1ZSwg
aW4gZnVuY3Rpb24gcmV0dXJuaW5nIHZvaWQgW2VuYWJsZWQgYnkgZGVmYXVsdF0KICByZXR1cm4g
LTE7CiAgXgovaG9tZS9taW5nby90aXAvYXJjaC94ODYvaW5jbHVkZS9hc20vY2FjaGVmbHVzaC5o
OiBBdCB0b3AgbGV2ZWw6Ci9ob21lL21pbmdvL3RpcC9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jYWNo
ZWZsdXNoLmg6NzI6MzA6IGVycm9yOiBwYXJhbWV0ZXIgMiAo4oCYbWVtdHlwZeKAmSkgaGFzIGlu
Y29tcGxldGUgdHlwZQogICAgICAgICBlbnVtIHBhZ2VfY2FjaGVfbW9kZSBtZW10eXBlKQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBeCi9ob21lL21pbmdvL3RpcC9hcmNoL3g4Ni9pbmNs
dWRlL2FzbS9jYWNoZWZsdXNoLmg6NzE6MjA6IGVycm9yOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBp
c27igJl0IGEgcHJvdG90eXBlIFstV2Vycm9yPXN0cmljdC1wcm90b3R5cGVzXQoKVGhhbmtzLAoK
CUluZ28KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Nov 16 13:09:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 13:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XpzZW-0003iy-9g; Sun, 16 Nov 2014 13:08:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo.kernel.org@gmail.com>) id 1XpzZV-0003it-Bk
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 13:08:53 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	6C/F4-23865-4E1A8645; Sun, 16 Nov 2014 13:08:52 +0000
X-Env-Sender: mingo.kernel.org@gmail.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416143331!11649813!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30788 invoked from network); 16 Nov 2014 13:08:52 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 13:08:52 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so3341280wiw.2
	for <xen-devel@lists.xensource.com>;
	Sun, 16 Nov 2014 05:08:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=Y3d1az05/M0beykXUE6pqh3sibCnjnQCTjVl1qoZojY=;
	b=eLGlRvP8zPLYFrMhB/YWX0ePVC0e33X8RYmYF5e0GjmlfXUvUX5KZf7AHHpQ8cAMD7
	RNuce8EsNGoSsinFyQ1qg+FQQn8CeHblXOgR6Bhlp5muaIP3QbhbYIn8CauedEjNcR+W
	t1DiDp/r2Ec8ayCJCTAO6ZwUZTZqXSNnbG79eA87SPposcbnnZC20EcDeS4kLX52A2vw
	pfdobW1gXZeW573VDyUSItFtWpnwwlVvUKzyKecu8DeGUIMjvl0nPDlwkGA8b3tUET0z
	Sg2gB6LR3wGGw6+gnn3Y/y4Mx0PGcRbwm2RmkVGs6zqRaItGjNXYqSkDDIovlnGu8duB
	fgnA==
X-Received: by 10.194.85.83 with SMTP id f19mr31376602wjz.20.1416143331487;
	Sun, 16 Nov 2014 05:08:51 -0800 (PST)
Received: from gmail.com (54033583.catv.pool.telekom.hu. [84.3.53.131])
	by mx.google.com with ESMTPSA id cq4sm3005525wjc.35.2014.11.16.05.08.49
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 16 Nov 2014 05:08:50 -0800 (PST)
Date: Sun, 16 Nov 2014 14:08:47 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141116130847.GA4736@gmail.com>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Length: 1954
Content-Disposition: inline
In-Reply-To: <1415019724-4317-1-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, tglx@linutronix.de, plagnioj@jcrosoft.com,
	ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CiogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPiB3cm90ZToKCj4gIGFyY2gveDg2L2lu
Y2x1ZGUvYXNtL2NhY2hlZmx1c2guaCAgICAgICAgIHwgIDM4ICsrKystLS0KCkZZSSwgdGhpcyBz
ZXJpZXMgYnJlYWtzIHRoZSBVTUwgYnVpbGQ6CgpJbiBmaWxlIGluY2x1ZGVkIGZyb20gL2hvbWUv
bWluZ28vdGlwL2luY2x1ZGUvbGludXgvaGlnaG1lbS5oOjExOjAsCiAgICAgICAgICAgICAgICAg
ZnJvbSAvaG9tZS9taW5nby90aXAvaW5jbHVkZS9saW51eC9wYWdlbWFwLmg6MTAsCiAgICAgICAg
ICAgICAgICAgZnJvbSAvaG9tZS9taW5nby90aXAvaW5jbHVkZS9saW51eC9tZW1wb2xpY3kuaDox
NCwKICAgICAgICAgICAgICAgICBmcm9tIC9ob21lL21pbmdvL3RpcC9pbmNsdWRlL2xpbnV4L3No
bWVtX2ZzLmg6NiwKICAgICAgICAgICAgICAgICBmcm9tIC9ob21lL21pbmdvL3RpcC9pbml0L2Rv
X21vdW50cy5jOjMwOgovaG9tZS9taW5nby90aXAvYXJjaC94ODYvaW5jbHVkZS9hc20vY2FjaGVm
bHVzaC5oOjY3OjM2OiBlcnJvcjogcmV0dXJuIHR5cGUgaXMgYW4gaW5jb21wbGV0ZSB0eXBlCiBz
dGF0aWMgaW5saW5lIGVudW0gcGFnZV9jYWNoZV9tb2RlIGdldF9wYWdlX21lbXR5cGUoc3RydWN0
IHBhZ2UgKnBnKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeCi9ob21lL21p
bmdvL3RpcC9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jYWNoZWZsdXNoLmg6IEluIGZ1bmN0aW9uIOKA
mGdldF9wYWdlX21lbXR5cGXigJk6Ci9ob21lL21pbmdvL3RpcC9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9jYWNoZWZsdXNoLmg6Njk6Mjogd2FybmluZzog4oCYcmV0dXJu4oCZIHdpdGggYSB2YWx1ZSwg
aW4gZnVuY3Rpb24gcmV0dXJuaW5nIHZvaWQgW2VuYWJsZWQgYnkgZGVmYXVsdF0KICByZXR1cm4g
LTE7CiAgXgovaG9tZS9taW5nby90aXAvYXJjaC94ODYvaW5jbHVkZS9hc20vY2FjaGVmbHVzaC5o
OiBBdCB0b3AgbGV2ZWw6Ci9ob21lL21pbmdvL3RpcC9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jYWNo
ZWZsdXNoLmg6NzI6MzA6IGVycm9yOiBwYXJhbWV0ZXIgMiAo4oCYbWVtdHlwZeKAmSkgaGFzIGlu
Y29tcGxldGUgdHlwZQogICAgICAgICBlbnVtIHBhZ2VfY2FjaGVfbW9kZSBtZW10eXBlKQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBeCi9ob21lL21pbmdvL3RpcC9hcmNoL3g4Ni9pbmNs
dWRlL2FzbS9jYWNoZWZsdXNoLmg6NzE6MjA6IGVycm9yOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBp
c27igJl0IGEgcHJvdG90eXBlIFstV2Vycm9yPXN0cmljdC1wcm90b3R5cGVzXQoKVGhhbmtzLAoK
CUluZ28KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Nov 16 15:03:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 15:03:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq1Lm-0004ZS-6I; Sun, 16 Nov 2014 15:02:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1Xq1Lk-0004ZN-CD
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 15:02:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0E/04-09842-79CB8645; Sun, 16 Nov 2014 15:02:47 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416150166!9663881!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20542 invoked from network); 16 Nov 2014 15:02:47 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-21.messagelabs.com with SMTP;
	16 Nov 2014 15:02:47 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 16 Nov 2014 07:02:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,397,1413270000"; d="scan'208";a="632774272"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by fmsmga002.fm.intel.com with ESMTP; 16 Nov 2014 07:02:42 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Sun, 16 Nov 2014 23:02:41 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.110]) with mapi id
	14.03.0195.001; Sun, 16 Nov 2014 23:02:39 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, "Konrad Rzeszutek
	Wilk" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] pc: piix4_pm: init legacy PCI hotplug when running on Xen
Thread-Index: AQHP/urpJPyXvdVjckiXgO2i6/6zL5xd2KiAgAHJN4CAAB+ogIAADLuAgAONw3A=
Date: Sun, 16 Nov 2014 15:02:38 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E448659@shsmsx102.ccr.corp.intel.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
	<alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
	<20141114155039.GF5364@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411141634480.26318@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411141634480.26318@kaball.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	"aliguori@amazon.com" <aliguori@amazon.com>,
	"qemu-devel@nongun.org" <qemu-devel@nongun.org>,
	Igor Mammedov <imammedo@redhat.com>, "rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
 running 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

> > > Konrad,
> > > this is another bug fix for QEMU: pci hotplug doesn't work when
> > > xen_platform_pci=0 without this.
> >
> > Yes.
> > >
> > >I think we should have it in 4.5. What do yo  think?
> >
> > Do you believe we should first get an Tested-by from the Intel QA folks?
 
> Liang at Intel was the one to fix and resend. Liang, could you please test this patch on qemu-xen on xen-unstable? Thanks! 

I have verified this patch can fix the bug  for QEMU: pci hotplug doesn't work when  xen_platform_pci=0,  my original intention  was to fix this bug, so I resent the patch.

Liang
  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 15:03:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 15:03:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq1Lm-0004ZS-6I; Sun, 16 Nov 2014 15:02:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1Xq1Lk-0004ZN-CD
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 15:02:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0E/04-09842-79CB8645; Sun, 16 Nov 2014 15:02:47 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416150166!9663881!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20542 invoked from network); 16 Nov 2014 15:02:47 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-21.messagelabs.com with SMTP;
	16 Nov 2014 15:02:47 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 16 Nov 2014 07:02:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,397,1413270000"; d="scan'208";a="632774272"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by fmsmga002.fm.intel.com with ESMTP; 16 Nov 2014 07:02:42 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Sun, 16 Nov 2014 23:02:41 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.110]) with mapi id
	14.03.0195.001; Sun, 16 Nov 2014 23:02:39 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, "Konrad Rzeszutek
	Wilk" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] pc: piix4_pm: init legacy PCI hotplug when running on Xen
Thread-Index: AQHP/urpJPyXvdVjckiXgO2i6/6zL5xd2KiAgAHJN4CAAB+ogIAADLuAgAONw3A=
Date: Sun, 16 Nov 2014 15:02:38 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E448659@shsmsx102.ccr.corp.intel.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
	<alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
	<20141114155039.GF5364@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411141634480.26318@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411141634480.26318@kaball.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	"aliguori@amazon.com" <aliguori@amazon.com>,
	"qemu-devel@nongun.org" <qemu-devel@nongun.org>,
	Igor Mammedov <imammedo@redhat.com>, "rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
 running 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

> > > Konrad,
> > > this is another bug fix for QEMU: pci hotplug doesn't work when
> > > xen_platform_pci=0 without this.
> >
> > Yes.
> > >
> > >I think we should have it in 4.5. What do yo  think?
> >
> > Do you believe we should first get an Tested-by from the Intel QA folks?
 
> Liang at Intel was the one to fix and resend. Liang, could you please test this patch on qemu-xen on xen-unstable? Thanks! 

I have verified this patch can fix the bug  for QEMU: pci hotplug doesn't work when  xen_platform_pci=0,  my original intention  was to fix this bug, so I resent the patch.

Liang
  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 20:26:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 20:26:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq6Oh-0007IX-U8; Sun, 16 Nov 2014 20:26:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christoffer.dall@linaro.org>) id 1Xq6Og-0007IS-Lq
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 20:26:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1E/CD-09936-26809645; Sun, 16 Nov 2014 20:26:10 +0000
X-Env-Sender: christoffer.dall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416169569!5104559!1
X-Originating-IP: [209.85.215.41]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8279 invoked from network); 16 Nov 2014 20:26:09 -0000
Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com)
	(209.85.215.41)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 20:26:09 -0000
Received: by mail-la0-f41.google.com with SMTP id gf13so5460081lab.0
	for <xen-devel@lists.xen.org>; Sun, 16 Nov 2014 12:26:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=mRPDa2cvR5bIbw6M35zno40Mf0XYBL6CGBFk5JyrNeM=;
	b=cwBrRK1WfY75Isr9J0UsPt/yyTj+TYsDrktU6uwaH0X4jd/2bQrMr/XXaPBOXnKbZx
	1moTWpw2PNvmVTOIoEBjThfSdIGBvgC1l1mGUo04A+kto3Gn1L3xRQC1xQhTq0MjTe6m
	4ZWjCYY0Bl0D11IhkQLIFWco9TukC+roix4rerf+coZ/cHhr6gUD0alfgqqyPRSqkIUH
	HINCdReoOVXe7beULHWzxNlZllPKJnUuCxaLYj1oMxkHerH9GPp+abx4Q+LCkZ9TpJ+X
	V8MVuKOmKBB/ljdEb/aFhgjtRcqAT1x4O+ic5qYCvs31GxoOicbIqdUDiuNBHZiR3R4b
	G1tg==
X-Gm-Message-State: ALoCoQlIbpZrRRpzq+7tyeWTKfdQY1J4HC2aNn1Tj/qVRJ0GzqAg4S40mTyITjigIXlyQcygWobe
X-Received: by 10.152.25.226 with SMTP id f2mr4991578lag.98.1416169568778;
	Sun, 16 Nov 2014 12:26:08 -0800 (PST)
Received: from localhost (x1-6-b8-c7-5d-cb-5a-ca.cpe.webspeed.dk.
	[2.108.248.47])
	by mx.google.com with ESMTPSA id f6sm9832478lbh.10.2014.11.16.12.26.07
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Sun, 16 Nov 2014 12:26:07 -0800 (PST)
Date: Sun, 16 Nov 2014 12:26:06 -0800
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141116202606.GD9960@lvm>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
	<1415628601-31075-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415628601-31075-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen: Correction to module@1 (dom0
	kernel) DT 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

Hi Ian,

On Mon, Nov 10, 2014 at 02:09:58PM +0000, Ian Campbell wrote:
> - Include bootargs (kernel command line) property.

Why?

The logic I was going for was to reduce duplicate code/entries in the
DT, and if I read docs/misc/arm/device-tree/booting.txt, the fact that
we have xen,xen-bootargs but no xen,dom0-bootargs then bootargs added
further down in Makefile.am will be used.

Is this not correct or not preferred for some reason?

-Christoffer

> - Update reg property to match #address-cells and #size-cells in the DTB (both
>   2).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  Makefile.am |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 9b6c7e3..ed5acbb 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -69,8 +69,9 @@ XEN_OFFSET	:= 0xA00000
>  DOM0_OFFSET	:= $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
>  XEN_BOOTARGS	:= xen,xen-bootargs = \"$(BOOTARGS)\";			\
>  		   module@1 {						\
> +			bootargs = \"$(CMDLINE)\";			\
>  			compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
> -			reg = <$(DOM0_OFFSET) 0x800000>;		\
> +			reg = <0 $(DOM0_OFFSET) 0 0x800000>;		\
>  		   };
>  endif
>  
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 20:26:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 20:26:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq6Oh-0007IX-U8; Sun, 16 Nov 2014 20:26:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christoffer.dall@linaro.org>) id 1Xq6Og-0007IS-Lq
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 20:26:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1E/CD-09936-26809645; Sun, 16 Nov 2014 20:26:10 +0000
X-Env-Sender: christoffer.dall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416169569!5104559!1
X-Originating-IP: [209.85.215.41]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8279 invoked from network); 16 Nov 2014 20:26:09 -0000
Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com)
	(209.85.215.41)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 20:26:09 -0000
Received: by mail-la0-f41.google.com with SMTP id gf13so5460081lab.0
	for <xen-devel@lists.xen.org>; Sun, 16 Nov 2014 12:26:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=mRPDa2cvR5bIbw6M35zno40Mf0XYBL6CGBFk5JyrNeM=;
	b=cwBrRK1WfY75Isr9J0UsPt/yyTj+TYsDrktU6uwaH0X4jd/2bQrMr/XXaPBOXnKbZx
	1moTWpw2PNvmVTOIoEBjThfSdIGBvgC1l1mGUo04A+kto3Gn1L3xRQC1xQhTq0MjTe6m
	4ZWjCYY0Bl0D11IhkQLIFWco9TukC+roix4rerf+coZ/cHhr6gUD0alfgqqyPRSqkIUH
	HINCdReoOVXe7beULHWzxNlZllPKJnUuCxaLYj1oMxkHerH9GPp+abx4Q+LCkZ9TpJ+X
	V8MVuKOmKBB/ljdEb/aFhgjtRcqAT1x4O+ic5qYCvs31GxoOicbIqdUDiuNBHZiR3R4b
	G1tg==
X-Gm-Message-State: ALoCoQlIbpZrRRpzq+7tyeWTKfdQY1J4HC2aNn1Tj/qVRJ0GzqAg4S40mTyITjigIXlyQcygWobe
X-Received: by 10.152.25.226 with SMTP id f2mr4991578lag.98.1416169568778;
	Sun, 16 Nov 2014 12:26:08 -0800 (PST)
Received: from localhost (x1-6-b8-c7-5d-cb-5a-ca.cpe.webspeed.dk.
	[2.108.248.47])
	by mx.google.com with ESMTPSA id f6sm9832478lbh.10.2014.11.16.12.26.07
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Sun, 16 Nov 2014 12:26:07 -0800 (PST)
Date: Sun, 16 Nov 2014 12:26:06 -0800
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141116202606.GD9960@lvm>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
	<1415628601-31075-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415628601-31075-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen: Correction to module@1 (dom0
	kernel) DT 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

Hi Ian,

On Mon, Nov 10, 2014 at 02:09:58PM +0000, Ian Campbell wrote:
> - Include bootargs (kernel command line) property.

Why?

The logic I was going for was to reduce duplicate code/entries in the
DT, and if I read docs/misc/arm/device-tree/booting.txt, the fact that
we have xen,xen-bootargs but no xen,dom0-bootargs then bootargs added
further down in Makefile.am will be used.

Is this not correct or not preferred for some reason?

-Christoffer

> - Update reg property to match #address-cells and #size-cells in the DTB (both
>   2).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  Makefile.am |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 9b6c7e3..ed5acbb 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -69,8 +69,9 @@ XEN_OFFSET	:= 0xA00000
>  DOM0_OFFSET	:= $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
>  XEN_BOOTARGS	:= xen,xen-bootargs = \"$(BOOTARGS)\";			\
>  		   module@1 {						\
> +			bootargs = \"$(CMDLINE)\";			\
>  			compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
> -			reg = <$(DOM0_OFFSET) 0x800000>;		\
> +			reg = <0 $(DOM0_OFFSET) 0 0x800000>;		\
>  		   };
>  endif
>  
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 21:04:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 21:04:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq6zK-0007iM-QP; Sun, 16 Nov 2014 21:04:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christoffer.dall@linaro.org>) id 1Xq6zI-0007iH-Vk
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 21:04:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A8/B7-09936-04119645; Sun, 16 Nov 2014 21:04:00 +0000
X-Env-Sender: christoffer.dall@linaro.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416171839!13152698!1
X-Originating-IP: [209.85.215.42]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP, UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14458 invoked from network); 16 Nov 2014 21:03:59 -0000
Received: from mail-la0-f42.google.com (HELO mail-la0-f42.google.com)
	(209.85.215.42)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 21:03:59 -0000
Received: by mail-la0-f42.google.com with SMTP id s18so3502762lam.15
	for <xen-devel@lists.xen.org>; Sun, 16 Nov 2014 13:03:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=4hdhHj4DweCN/5cC2jnB8AozFxGVapGf0VOWXK54F/g=;
	b=bP3usci5oLPRvMIGHfDferga/5A+itduIgxwZk95Iwim/TZlaErh4HAAzJIKrrS4Vl
	DWZ/oVm4jR4Tazt+UsCHTChaVgx8F3W3qqGNKl1XxuBKvVQrkr8GpETtj1RxLa4m6fTm
	jKJjAIgKYPHkDJtrj3D61kGgucUiEO6dfy9RIkN5i31kfRsJmIU38XKxOlrEzzTs6tfG
	m3voC21Ugr/P0qM1jqMsv+4lCZOktm/1z9T2mueeSUgBfC+0LEz3oq256/NiTiU1W7Eu
	SGIZohlyHzDG7oByU0Mi1KCiJRR+/H5wY/ft0dg+dtCBCl+ZIFSTFBf1Q4jZR/iaq8Gz
	ItqA==
X-Gm-Message-State: ALoCoQmq2cleRztYKqSwYhqbESc3zpzwPsLzN1fU0gQWWZmPFu9Qmr0K0WOWo6Bm/7WveSU1r08W
X-Received: by 10.112.130.65 with SMTP id oc1mr9371105lbb.7.1416171839051;
	Sun, 16 Nov 2014 13:03:59 -0800 (PST)
Received: from localhost (x1-6-b8-c7-5d-cb-5a-ca.cpe.webspeed.dk.
	[2.108.248.47])
	by mx.google.com with ESMTPSA id ar4sm9842991lbc.48.2014.11.16.13.03.57
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Sun, 16 Nov 2014 13:03:57 -0800 (PST)
Date: Sun, 16 Nov 2014 13:03:56 -0800
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141116210356.GE9960@lvm>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
	<1415628601-31075-2-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415628601-31075-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] Fix build when Xen is not enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 02:09:59PM +0000, Ian Campbell wrote:
> If Xen isn't enabled then XEN_IMAGE ends up as "no.o", which obviously doesn't
> exist. Handle the dependency explicitly.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  Makefile.am |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index ed5acbb..6c2786e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -98,7 +98,10 @@ all: $(IMAGE) $(XIMAGE)
>  
>  CLEANFILES = $(IMAGE) boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb
>  
> -$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
> +if XEN
> +XEN_IMAGE_DEP = $(XEN_IMAGE)
> +endif
> +$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE_DEP)
>  	$(LD) -o $@ --script=model.lds
>  
>  %.o: %.S Makefile
> -- 
> 1.7.10.4
> 
I fixed this differently, see the 'xen-psci-support-for-upstream' branch in:
http://git.linaro.org/people/christoffer.dall/boot-wrapper-aarch64.git

Hopefully you're ok with that change.

-Christoffer

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 21:04:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 21:04:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq6zK-0007iM-QP; Sun, 16 Nov 2014 21:04:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christoffer.dall@linaro.org>) id 1Xq6zI-0007iH-Vk
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 21:04:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A8/B7-09936-04119645; Sun, 16 Nov 2014 21:04:00 +0000
X-Env-Sender: christoffer.dall@linaro.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416171839!13152698!1
X-Originating-IP: [209.85.215.42]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP, UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14458 invoked from network); 16 Nov 2014 21:03:59 -0000
Received: from mail-la0-f42.google.com (HELO mail-la0-f42.google.com)
	(209.85.215.42)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 21:03:59 -0000
Received: by mail-la0-f42.google.com with SMTP id s18so3502762lam.15
	for <xen-devel@lists.xen.org>; Sun, 16 Nov 2014 13:03:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=4hdhHj4DweCN/5cC2jnB8AozFxGVapGf0VOWXK54F/g=;
	b=bP3usci5oLPRvMIGHfDferga/5A+itduIgxwZk95Iwim/TZlaErh4HAAzJIKrrS4Vl
	DWZ/oVm4jR4Tazt+UsCHTChaVgx8F3W3qqGNKl1XxuBKvVQrkr8GpETtj1RxLa4m6fTm
	jKJjAIgKYPHkDJtrj3D61kGgucUiEO6dfy9RIkN5i31kfRsJmIU38XKxOlrEzzTs6tfG
	m3voC21Ugr/P0qM1jqMsv+4lCZOktm/1z9T2mueeSUgBfC+0LEz3oq256/NiTiU1W7Eu
	SGIZohlyHzDG7oByU0Mi1KCiJRR+/H5wY/ft0dg+dtCBCl+ZIFSTFBf1Q4jZR/iaq8Gz
	ItqA==
X-Gm-Message-State: ALoCoQmq2cleRztYKqSwYhqbESc3zpzwPsLzN1fU0gQWWZmPFu9Qmr0K0WOWo6Bm/7WveSU1r08W
X-Received: by 10.112.130.65 with SMTP id oc1mr9371105lbb.7.1416171839051;
	Sun, 16 Nov 2014 13:03:59 -0800 (PST)
Received: from localhost (x1-6-b8-c7-5d-cb-5a-ca.cpe.webspeed.dk.
	[2.108.248.47])
	by mx.google.com with ESMTPSA id ar4sm9842991lbc.48.2014.11.16.13.03.57
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Sun, 16 Nov 2014 13:03:57 -0800 (PST)
Date: Sun, 16 Nov 2014 13:03:56 -0800
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141116210356.GE9960@lvm>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
	<1415628601-31075-2-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415628601-31075-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] Fix build when Xen is not enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 02:09:59PM +0000, Ian Campbell wrote:
> If Xen isn't enabled then XEN_IMAGE ends up as "no.o", which obviously doesn't
> exist. Handle the dependency explicitly.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  Makefile.am |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index ed5acbb..6c2786e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -98,7 +98,10 @@ all: $(IMAGE) $(XIMAGE)
>  
>  CLEANFILES = $(IMAGE) boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb
>  
> -$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
> +if XEN
> +XEN_IMAGE_DEP = $(XEN_IMAGE)
> +endif
> +$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE_DEP)
>  	$(LD) -o $@ --script=model.lds
>  
>  %.o: %.S Makefile
> -- 
> 1.7.10.4
> 
I fixed this differently, see the 'xen-psci-support-for-upstream' branch in:
http://git.linaro.org/people/christoffer.dall/boot-wrapper-aarch64.git

Hopefully you're ok with that change.

-Christoffer

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 22:34:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 22:34:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq8OZ-00004s-9K; Sun, 16 Nov 2014 22:34:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xq8OX-0008WT-T2
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 22:34:10 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	2A/FE-14214-16629645; Sun, 16 Nov 2014 22:34:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416177247!11678303!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2316 invoked from network); 16 Nov 2014 22:34:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 22:34:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,398,1413244800"; d="scan'208";a="191894294"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 17:34:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xq8OT-000185-1b;
	Sun, 16 Nov 2014 22:34:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xq8OS-00057K-PZ;
	Sun, 16 Nov 2014 22:34:04 +0000
Date: Sun, 16 Nov 2014 22:34:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31606-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31606: 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 31606 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31606/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 26303
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 26303
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 26303
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)

Not pushing.

(No revision log; it would be 30846 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 Nov 16 22:34:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 22:34:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq8OZ-00004s-9K; Sun, 16 Nov 2014 22:34:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xq8OX-0008WT-T2
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 22:34:10 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	2A/FE-14214-16629645; Sun, 16 Nov 2014 22:34:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416177247!11678303!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2316 invoked from network); 16 Nov 2014 22:34:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 22:34:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,398,1413244800"; d="scan'208";a="191894294"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 17:34:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xq8OT-000185-1b;
	Sun, 16 Nov 2014 22:34:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xq8OS-00057K-PZ;
	Sun, 16 Nov 2014 22:34:04 +0000
Date: Sun, 16 Nov 2014 22:34:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31606-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31606: 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 31606 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31606/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 26303
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 26303
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 26303
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)

Not pushing.

(No revision log; it would be 30846 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 Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94W-0000oF-U1; Sun, 16 Nov 2014 23:17:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94U-0000mc-9Y
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:30 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	6B/44-22777-98039645; Sun, 16 Nov 2014 23:17:29 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416179846!11643484!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15917 invoked from network); 16 Nov 2014 23:17:28 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Nov 2014 23:17:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHLVU003450
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:22 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHKJK007400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:21 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHKuu007381; Sun, 16 Nov 2014 23:17:20 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:19 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:37 -0500
Message-Id: <1416179271-1221-8-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 07/21] x86/VPMU: Handle APIC_LVTPC accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Don't have the hypervisor update APIC_LVTPC when _it_ thinks the vector should
be updated. Instead, handle guest's APIC_LVTPC accesses and write what the guest
explicitly wanted.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       |  4 ----
 xen/arch/x86/hvm/vlapic.c         |  3 +++
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 17 -----------------
 xen/arch/x86/hvm/vpmu.c           |  8 ++++++++
 xen/include/asm-x86/hvm/vpmu.h    |  1 +
 5 files changed, 12 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index f49af97..af3cdb2 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -302,8 +302,6 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
             return 1;
         vpmu_set(vpmu, VPMU_RUNNING);
-        apic_write(APIC_LVTPC, PMU_APIC_VECTOR);
-        vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR;
 
         if ( has_hvm_container_vcpu(v) &&
              !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
@@ -314,8 +312,6 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     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->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
         vpmu_reset(vpmu, VPMU_RUNNING);
         if ( has_hvm_container_vcpu(v) &&
              ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 0b7b607..5c3b2be 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -38,6 +38,7 @@
 #include <asm/hvm/support.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/nestedhvm.h>
+#include <asm/hvm/vpmu.h>
 #include <public/hvm/ioreq.h>
 #include <public/hvm/params.h>
 
@@ -789,6 +790,8 @@ static int vlapic_reg_write(struct vcpu *v,
         }
         if ( (offset == APIC_LVTT) && !(val & APIC_LVT_MASKED) )
             pt_may_unmask_irq(NULL, &vlapic->pt);
+        if ( offset == APIC_LVTPC )
+            vpmu_lvtpc_update(val);
         break;
 
     case APIC_TMICT:
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 09af846..f44847f 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -528,19 +528,6 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     else
         vpmu_reset(vpmu, VPMU_RUNNING);
 
-    /* Setup LVTPC in local apic */
-    if ( vpmu_is_set(vpmu, VPMU_RUNNING) &&
-         is_vlapic_lvtpc_enabled(vcpu_vlapic(v)) )
-    {
-        apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR);
-        vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR;
-    }
-    else
-    {
-        apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
-        vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
-    }
-
     if ( type != MSR_TYPE_GLOBAL )
     {
         u64 mask;
@@ -706,10 +693,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
             return 0;
     }
 
-    /* HW sets the MASK bit when performance counter interrupt occurs*/
-    vpmu->hw_lapic_lvtpc = apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED;
-    apic_write_around(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
-
     return 1;
 }
 
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index aec7b5f..29d9fde 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -64,6 +64,14 @@ static void __init parse_vpmu_param(char *s)
     }
 }
 
+void vpmu_lvtpc_update(uint32_t val)
+{
+    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+
+    vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
+    apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
+}
+
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index ddc2748..9c4e65a 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -104,6 +104,7 @@ static inline bool_t vpmu_are_all_set(const struct vpmu_struct *vpmu,
     return !!((vpmu->flags & mask) == mask);
 }
 
+void vpmu_lvtpc_update(uint32_t val);
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
 void vpmu_do_interrupt(struct cpu_user_regs *regs);
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94W-0000nV-5A; Sun, 16 Nov 2014 23:17:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94T-0000mS-Mj
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F4/92-09842-98039645; Sun, 16 Nov 2014 23:17:29 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416179846!13128348!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13249 invoked from network); 16 Nov 2014 23:17:28 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHJnL007688
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:20 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHIdt016391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:19 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHIKN012697; Sun, 16 Nov 2014 23:17:18 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:17 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:35 -0500
Message-Id: <1416179271-1221-6-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 05/21] intel/VPMU: Clean up Intel VPMU code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove struct pmumsr and core2_pmu_enable. Replace static MSR structures with
fields in core2_vpmu_context.

Call core2_get_pmc_count() once, during initialization.

Properly clean up when core2_vpmu_alloc_resource() fails.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vmx/vpmu_core2.c        | 381 ++++++++++++++-----------------
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |  19 --
 2 files changed, 172 insertions(+), 228 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index f2e9735..09af846 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -69,6 +69,27 @@
 static bool_t __read_mostly full_width_write;
 
 /*
+ * MSR_CORE_PERF_FIXED_CTR_CTRL contains the configuration of all fixed
+ * counters. 4 bits for every counter.
+ */
+#define FIXED_CTR_CTRL_BITS 4
+#define FIXED_CTR_CTRL_MASK ((1 << FIXED_CTR_CTRL_BITS) - 1)
+
+#define VPMU_CORE2_MAX_FIXED_PMCS     4
+struct core2_vpmu_context {
+    u64 fixed_ctrl;
+    u64 ds_area;
+    u64 pebs_enable;
+    u64 global_ovf_status;
+    u64 enabled_cntrs;  /* Follows PERF_GLOBAL_CTRL MSR format */
+    u64 fix_counters[VPMU_CORE2_MAX_FIXED_PMCS];
+    struct arch_msr_pair arch_msr_pair[1];
+};
+
+/* Number of general-purpose and fixed performance counters */
+static unsigned int __read_mostly arch_pmc_cnt, fixed_pmc_cnt;
+
+/*
  * QUIRK to workaround an issue on various family 6 cpus.
  * The issue leads to endless PMC interrupt loops on the processor.
  * If the interrupt handler is running and a pmc reaches the value 0, this
@@ -88,11 +109,8 @@ static void check_pmc_quirk(void)
         is_pmc_quirk = 0;    
 }
 
-static int core2_get_pmc_count(void);
 static void handle_pmc_quirk(u64 msr_content)
 {
-    int num_gen_pmc = core2_get_pmc_count();
-    int num_fix_pmc  = 3;
     int i;
     u64 val;
 
@@ -100,7 +118,7 @@ static void handle_pmc_quirk(u64 msr_content)
         return;
 
     val = msr_content;
-    for ( i = 0; i < num_gen_pmc; i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
     {
         if ( val & 0x1 )
         {
@@ -112,7 +130,7 @@ static void handle_pmc_quirk(u64 msr_content)
         val >>= 1;
     }
     val = msr_content >> 32;
-    for ( i = 0; i < num_fix_pmc; i++ )
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
     {
         if ( val & 0x1 )
         {
@@ -125,128 +143,91 @@ static void handle_pmc_quirk(u64 msr_content)
     }
 }
 
-static const u32 core2_fix_counters_msr[] = {
-    MSR_CORE_PERF_FIXED_CTR0,
-    MSR_CORE_PERF_FIXED_CTR1,
-    MSR_CORE_PERF_FIXED_CTR2
-};
-
 /*
- * MSR_CORE_PERF_FIXED_CTR_CTRL contains the configuration of all fixed
- * counters. 4 bits for every counter.
+ * Read the number of general counters via CPUID.EAX[0xa].EAX[8..15]
  */
-#define FIXED_CTR_CTRL_BITS 4
-#define FIXED_CTR_CTRL_MASK ((1 << FIXED_CTR_CTRL_BITS) - 1)
-
-/* The index into the core2_ctrls_msr[] of this MSR used in core2_vpmu_dump() */
-#define MSR_CORE_PERF_FIXED_CTR_CTRL_IDX 0
-
-/* Core 2 Non-architectual Performance Control MSRs. */
-static const u32 core2_ctrls_msr[] = {
-    MSR_CORE_PERF_FIXED_CTR_CTRL,
-    MSR_IA32_PEBS_ENABLE,
-    MSR_IA32_DS_AREA
-};
-
-struct pmumsr {
-    unsigned int num;
-    const u32 *msr;
-};
-
-static const struct pmumsr core2_fix_counters = {
-    VPMU_CORE2_NUM_FIXED,
-    core2_fix_counters_msr
-};
+static int core2_get_arch_pmc_count(void)
+{
+    u32 eax;
 
-static const struct pmumsr core2_ctrls = {
-    VPMU_CORE2_NUM_CTRLS,
-    core2_ctrls_msr
-};
-static int arch_pmc_cnt;
+    eax = cpuid_eax(0xa);
+    return MASK_EXTR(eax, PMU_GENERAL_NR_MASK);
+}
 
 /*
- * Read the number of general counters via CPUID.EAX[0xa].EAX[8..15]
+ * Read the number of fixed counters via CPUID.EDX[0xa].EDX[0..4]
  */
-static int core2_get_pmc_count(void)
+static int core2_get_fixed_pmc_count(void)
 {
-    u32 eax, ebx, ecx, edx;
+    u32 eax;
 
-    if ( arch_pmc_cnt == 0 )
-    {
-        cpuid(0xa, &eax, &ebx, &ecx, &edx);
-        arch_pmc_cnt = (eax & PMU_GENERAL_NR_MASK) >> PMU_GENERAL_NR_SHIFT;
-    }
-
-    return arch_pmc_cnt;
+    eax = cpuid_eax(0xa);
+    return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
 }
 
 static u64 core2_calc_intial_glb_ctrl_msr(void)
 {
-    int arch_pmc_bits = (1 << core2_get_pmc_count()) - 1;
-    u64 fix_pmc_bits  = (1 << 3) - 1;
-    return ((fix_pmc_bits << 32) | arch_pmc_bits);
+    int arch_pmc_bits = (1 << arch_pmc_cnt) - 1;
+    u64 fix_pmc_bits  = (1 << fixed_pmc_cnt) - 1;
+
+    return (fix_pmc_bits << 32) | arch_pmc_bits;
 }
 
 /* edx bits 5-12: Bit width of fixed-function performance counters  */
 static int core2_get_bitwidth_fix_count(void)
 {
-    u32 eax, ebx, ecx, edx;
+    u32 edx;
 
-    cpuid(0xa, &eax, &ebx, &ecx, &edx);
-    return ((edx & PMU_FIXED_WIDTH_MASK) >> PMU_FIXED_WIDTH_SHIFT);
+    edx = cpuid_edx(0xa);
+    return MASK_EXTR(edx, PMU_FIXED_WIDTH_MASK);
 }
 
 static int is_core2_vpmu_msr(u32 msr_index, int *type, int *index)
 {
-    int i;
     u32 msr_index_pmc;
 
-    for ( i = 0; i < core2_fix_counters.num; i++ )
+    switch ( msr_index )
     {
-        if ( core2_fix_counters.msr[i] == msr_index )
+    case MSR_CORE_PERF_FIXED_CTR_CTRL:
+    case MSR_IA32_DS_AREA:
+    case MSR_IA32_PEBS_ENABLE:
+        *type = MSR_TYPE_CTRL;
+        return 1;
+
+    case MSR_CORE_PERF_GLOBAL_CTRL:
+    case MSR_CORE_PERF_GLOBAL_STATUS:
+    case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+        *type = MSR_TYPE_GLOBAL;
+        return 1;
+
+    default:
+
+        if ( (msr_index >= MSR_CORE_PERF_FIXED_CTR0) &&
+             (msr_index < MSR_CORE_PERF_FIXED_CTR0 + fixed_pmc_cnt) )
         {
+            *index = msr_index - MSR_CORE_PERF_FIXED_CTR0;
             *type = MSR_TYPE_COUNTER;
-            *index = i;
             return 1;
         }
-    }
 
-    for ( i = 0; i < core2_ctrls.num; i++ )
-    {
-        if ( core2_ctrls.msr[i] == msr_index )
+        if ( (msr_index >= MSR_P6_EVNTSEL(0)) &&
+             (msr_index < MSR_P6_EVNTSEL(arch_pmc_cnt)) )
         {
-            *type = MSR_TYPE_CTRL;
-            *index = i;
+            *index = msr_index - MSR_P6_EVNTSEL(0);
+            *type = MSR_TYPE_ARCH_CTRL;
             return 1;
         }
-    }
-
-    if ( (msr_index == MSR_CORE_PERF_GLOBAL_CTRL) ||
-         (msr_index == MSR_CORE_PERF_GLOBAL_STATUS) ||
-         (msr_index == MSR_CORE_PERF_GLOBAL_OVF_CTRL) )
-    {
-        *type = MSR_TYPE_GLOBAL;
-        return 1;
-    }
-
-    msr_index_pmc = msr_index & MSR_PMC_ALIAS_MASK;
-    if ( (msr_index_pmc >= MSR_IA32_PERFCTR0) &&
-         (msr_index_pmc < (MSR_IA32_PERFCTR0 + core2_get_pmc_count())) )
-    {
-        *type = MSR_TYPE_ARCH_COUNTER;
-        *index = msr_index_pmc - MSR_IA32_PERFCTR0;
-        return 1;
-    }
 
-    if ( (msr_index >= MSR_P6_EVNTSEL(0)) &&
-         (msr_index < (MSR_P6_EVNTSEL(core2_get_pmc_count()))) )
-    {
-        *type = MSR_TYPE_ARCH_CTRL;
-        *index = msr_index - MSR_P6_EVNTSEL(0);
-        return 1;
+        msr_index_pmc = msr_index & MSR_PMC_ALIAS_MASK;
+        if ( (msr_index_pmc >= MSR_IA32_PERFCTR0) &&
+             (msr_index_pmc < (MSR_IA32_PERFCTR0 + arch_pmc_cnt)) )
+        {
+            *type = MSR_TYPE_ARCH_COUNTER;
+            *index = msr_index_pmc - MSR_IA32_PERFCTR0;
+            return 1;
+        }
+        return 0;
     }
-
-    return 0;
 }
 
 static void core2_vpmu_set_msr_bitmap(unsigned long *msr_bitmap)
@@ -254,13 +235,13 @@ static void core2_vpmu_set_msr_bitmap(unsigned long *msr_bitmap)
     int i;
 
     /* Allow Read/Write PMU Counters MSR Directly. */
-    for ( i = 0; i < core2_fix_counters.num; i++ )
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
     {
-        clear_bit(msraddr_to_bitpos(core2_fix_counters.msr[i]), msr_bitmap);
-        clear_bit(msraddr_to_bitpos(core2_fix_counters.msr[i]),
+        clear_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR0 + i), msr_bitmap);
+        clear_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR0 + i),
                   msr_bitmap + 0x800/BYTES_PER_LONG);
     }
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
     {
         clear_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0+i), msr_bitmap);
         clear_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0+i),
@@ -275,26 +256,28 @@ static void core2_vpmu_set_msr_bitmap(unsigned long *msr_bitmap)
     }
 
     /* Allow Read PMU Non-global Controls Directly. */
-    for ( i = 0; i < core2_ctrls.num; i++ )
-        clear_bit(msraddr_to_bitpos(core2_ctrls.msr[i]), msr_bitmap);
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
-        clear_bit(msraddr_to_bitpos(MSR_P6_EVNTSEL(i)), msr_bitmap);
+    for ( i = 0; i < arch_pmc_cnt; i++ )
+         clear_bit(msraddr_to_bitpos(MSR_P6_EVNTSEL(i)), msr_bitmap);
+
+    clear_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR_CTRL), msr_bitmap);
+    clear_bit(msraddr_to_bitpos(MSR_IA32_PEBS_ENABLE), msr_bitmap);
+    clear_bit(msraddr_to_bitpos(MSR_IA32_DS_AREA), msr_bitmap);
 }
 
 static void core2_vpmu_unset_msr_bitmap(unsigned long *msr_bitmap)
 {
     int i;
 
-    for ( i = 0; i < core2_fix_counters.num; i++ )
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
     {
-        set_bit(msraddr_to_bitpos(core2_fix_counters.msr[i]), msr_bitmap);
-        set_bit(msraddr_to_bitpos(core2_fix_counters.msr[i]),
+        set_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR0 + i), msr_bitmap);
+        set_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR0 + i),
                 msr_bitmap + 0x800/BYTES_PER_LONG);
     }
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
     {
-        set_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0+i), msr_bitmap);
-        set_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0+i),
+        set_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0 + i), msr_bitmap);
+        set_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0 + i),
                 msr_bitmap + 0x800/BYTES_PER_LONG);
 
         if ( full_width_write )
@@ -305,10 +288,12 @@ static void core2_vpmu_unset_msr_bitmap(unsigned long *msr_bitmap)
         }
     }
 
-    for ( i = 0; i < core2_ctrls.num; i++ )
-        set_bit(msraddr_to_bitpos(core2_ctrls.msr[i]), msr_bitmap);
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
         set_bit(msraddr_to_bitpos(MSR_P6_EVNTSEL(i)), msr_bitmap);
+
+    set_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR_CTRL), msr_bitmap);
+    set_bit(msraddr_to_bitpos(MSR_IA32_PEBS_ENABLE), msr_bitmap);
+    set_bit(msraddr_to_bitpos(MSR_IA32_DS_AREA), msr_bitmap);
 }
 
 static inline void __core2_vpmu_save(struct vcpu *v)
@@ -316,10 +301,10 @@ static inline void __core2_vpmu_save(struct vcpu *v)
     int i;
     struct core2_vpmu_context *core2_vpmu_cxt = vcpu_vpmu(v)->context;
 
-    for ( i = 0; i < core2_fix_counters.num; i++ )
-        rdmsrl(core2_fix_counters.msr[i], core2_vpmu_cxt->fix_counters[i]);
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
-        rdmsrl(MSR_IA32_PERFCTR0+i, core2_vpmu_cxt->arch_msr_pair[i].counter);
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
+        rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, core2_vpmu_cxt->fix_counters[i]);
+    for ( i = 0; i < arch_pmc_cnt; i++ )
+        rdmsrl(MSR_IA32_PERFCTR0 + i, core2_vpmu_cxt->arch_msr_pair[i].counter);
 }
 
 static int core2_vpmu_save(struct vcpu *v)
@@ -344,20 +329,22 @@ static inline void __core2_vpmu_load(struct vcpu *v)
     unsigned int i, pmc_start;
     struct core2_vpmu_context *core2_vpmu_cxt = vcpu_vpmu(v)->context;
 
-    for ( i = 0; i < core2_fix_counters.num; i++ )
-        wrmsrl(core2_fix_counters.msr[i], core2_vpmu_cxt->fix_counters[i]);
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
+        wrmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, core2_vpmu_cxt->fix_counters[i]);
 
     if ( full_width_write )
         pmc_start = MSR_IA32_A_PERFCTR0;
     else
         pmc_start = MSR_IA32_PERFCTR0;
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
+    {
         wrmsrl(pmc_start + i, core2_vpmu_cxt->arch_msr_pair[i].counter);
-
-    for ( i = 0; i < core2_ctrls.num; i++ )
-        wrmsrl(core2_ctrls.msr[i], core2_vpmu_cxt->ctrls[i]);
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
         wrmsrl(MSR_P6_EVNTSEL(i), core2_vpmu_cxt->arch_msr_pair[i].control);
+    }
+
+    wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
+    wrmsrl(MSR_IA32_DS_AREA, core2_vpmu_cxt->ds_area);
+    wrmsrl(MSR_IA32_PEBS_ENABLE, core2_vpmu_cxt->pebs_enable);
 }
 
 static void core2_vpmu_load(struct vcpu *v)
@@ -376,56 +363,37 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct core2_vpmu_context *core2_vpmu_cxt;
-    struct core2_pmu_enable *pmu_enable;
 
     if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
         return 0;
 
     wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
     if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
-        return 0;
+        goto out_err;
 
     if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
-        return 0;
+        goto out_err;
     vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
                  core2_calc_intial_glb_ctrl_msr());
 
-    pmu_enable = xzalloc_bytes(sizeof(struct core2_pmu_enable) +
-                               core2_get_pmc_count() - 1);
-    if ( !pmu_enable )
-        goto out1;
-
     core2_vpmu_cxt = xzalloc_bytes(sizeof(struct core2_vpmu_context) +
-                    (core2_get_pmc_count()-1)*sizeof(struct arch_msr_pair));
+                    (arch_pmc_cnt-1)*sizeof(struct arch_msr_pair));
     if ( !core2_vpmu_cxt )
-        goto out2;
-    core2_vpmu_cxt->pmu_enable = pmu_enable;
+        goto out_err;
+
     vpmu->context = (void *)core2_vpmu_cxt;
 
+    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
+
     return 1;
- out2:
-    xfree(pmu_enable);
- out1:
-    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 0;
-}
 
-static void core2_vpmu_save_msr_context(struct vcpu *v, int type,
-                                       int index, u64 msr_data)
-{
-    struct core2_vpmu_context *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+out_err:
+    release_pmu_ownship(PMU_OWNER_HVM);
 
-    switch ( type )
-    {
-    case MSR_TYPE_CTRL:
-        core2_vpmu_cxt->ctrls[index] = msr_data;
-        break;
-    case MSR_TYPE_ARCH_CTRL:
-        core2_vpmu_cxt->arch_msr_pair[index].control = msr_data;
-        break;
-    }
+    printk("Failed to allocate VPMU resources for domain %u vcpu %u\n",
+           v->vcpu_id, v->domain->domain_id);
+
+    return 0;
 }
 
 static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
@@ -436,10 +404,8 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
         return 0;
 
     if ( unlikely(!vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED)) &&
-	 (vpmu->context != NULL ||
-	  !core2_vpmu_alloc_resource(current)) )
+         !core2_vpmu_alloc_resource(current) )
         return 0;
-    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
 
     /* Do the lazy load staff. */
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
@@ -456,8 +422,7 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
 static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
                                uint64_t supported)
 {
-    u64 global_ctrl, non_global_ctrl;
-    char pmu_enable = 0;
+    u64 global_ctrl;
     int i, tmp;
     int type = -1, index = -1;
     struct vcpu *v = current;
@@ -504,6 +469,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         if ( msr_content & 1 )
             gdprintk(XENLOG_WARNING, "Guest is trying to enable PEBS, "
                      "which is not supported.\n");
+        core2_vpmu_cxt->pebs_enable = msr_content;
         return 1;
     case MSR_IA32_DS_AREA:
         if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
@@ -516,57 +482,48 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
                 hvm_inject_hw_exception(TRAP_gp_fault, 0);
                 return 1;
             }
-            core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 0;
+            core2_vpmu_cxt->ds_area = msr_content;
             break;
         }
         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++ )
-        {
-            rdmsrl(MSR_P6_EVNTSEL(i), non_global_ctrl);
-            core2_vpmu_cxt->pmu_enable->arch_pmc_enable[i] =
-                    global_ctrl & (non_global_ctrl >> 22) & 1;
-            global_ctrl >>= 1;
-        }
-
-        rdmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, non_global_ctrl);
-        global_ctrl = msr_content >> 32;
-        for ( i = 0; i < core2_fix_counters.num; i++ )
-        {
-            core2_vpmu_cxt->pmu_enable->fixed_ctr_enable[i] =
-                (global_ctrl & 1) & ((non_global_ctrl & 0x3)? 1: 0);
-            non_global_ctrl >>= FIXED_CTR_CTRL_BITS;
-            global_ctrl >>= 1;
-        }
         break;
     case MSR_CORE_PERF_FIXED_CTR_CTRL:
-        non_global_ctrl = msr_content;
         vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
-        global_ctrl >>= 32;
-        for ( i = 0; i < core2_fix_counters.num; i++ )
+        core2_vpmu_cxt->enabled_cntrs &=
+                ~(((1ULL << VPMU_CORE2_MAX_FIXED_PMCS) - 1) << 32);
+        if ( msr_content != 0 )
         {
-            core2_vpmu_cxt->pmu_enable->fixed_ctr_enable[i] =
-                (global_ctrl & 1) & ((non_global_ctrl & 0x3)? 1: 0);
-            non_global_ctrl >>= 4;
-            global_ctrl >>= 1;
+            u64 val = msr_content;
+            for ( i = 0; i < fixed_pmc_cnt; i++ )
+            {
+                if ( val & 3 )
+                    core2_vpmu_cxt->enabled_cntrs |= (1ULL << 32) << i;
+                val >>= FIXED_CTR_CTRL_BITS;
+            }
         }
+
+        core2_vpmu_cxt->fixed_ctrl = msr_content;
         break;
     default:
         tmp = msr - MSR_P6_EVNTSEL(0);
-        vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
-        if ( tmp >= 0 && tmp < core2_get_pmc_count() )
-            core2_vpmu_cxt->pmu_enable->arch_pmc_enable[tmp] =
-                (global_ctrl >> tmp) & (msr_content >> 22) & 1;
+        if ( tmp >= 0 && tmp < arch_pmc_cnt )
+        {
+            vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+
+            if ( msr_content & (1ULL << 22) )
+                core2_vpmu_cxt->enabled_cntrs |= 1ULL << tmp;
+            else
+                core2_vpmu_cxt->enabled_cntrs &= ~(1ULL << tmp);
+
+            core2_vpmu_cxt->arch_msr_pair[tmp].control = msr_content;
+        }
     }
 
-    for ( i = 0; i < core2_fix_counters.num; i++ )
-        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 )
+    if ( (global_ctrl & core2_vpmu_cxt->enabled_cntrs) ||
+         (core2_vpmu_cxt->ds_area != 0)  )
         vpmu_set(vpmu, VPMU_RUNNING);
     else
         vpmu_reset(vpmu, VPMU_RUNNING);
@@ -584,7 +541,6 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
     }
 
-    core2_vpmu_save_msr_context(v, type, index, msr_content);
     if ( type != MSR_TYPE_GLOBAL )
     {
         u64 mask;
@@ -600,7 +556,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
             if  ( msr == MSR_IA32_DS_AREA )
                 break;
             /* 4 bits per counter, currently 3 fixed counters implemented. */
-            mask = ~((1ull << (VPMU_CORE2_NUM_FIXED * FIXED_CTR_CTRL_BITS)) - 1);
+            mask = ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1);
             if (msr_content & mask)
                 inject_gp = 1;
             break;
@@ -685,7 +641,7 @@ static void core2_vpmu_do_cpuid(unsigned int input,
 static void core2_vpmu_dump(const struct vcpu *v)
 {
     const struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    int i, num;
+    unsigned int i;
     const struct core2_vpmu_context *core2_vpmu_cxt = NULL;
     u64 val;
 
@@ -703,27 +659,25 @@ static void core2_vpmu_dump(const struct vcpu *v)
 
     printk("    vPMU running\n");
     core2_vpmu_cxt = vpmu->context;
-    num = core2_get_pmc_count();
+
     /* Print the contents of the counter and its configuration msr. */
-    for ( i = 0; i < num; i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
     {
         const struct arch_msr_pair *msr_pair = core2_vpmu_cxt->arch_msr_pair;
 
-        if ( core2_vpmu_cxt->pmu_enable->arch_pmc_enable[i] )
-            printk("      general_%d: 0x%016lx ctrl: 0x%016lx\n",
-                   i, msr_pair[i].counter, msr_pair[i].control);
+        printk("      general_%d: 0x%016lx ctrl: 0x%016lx\n",
+               i, msr_pair[i].counter, msr_pair[i].control);
     }
     /*
      * The configuration of the fixed counter is 4 bits each in the
      * MSR_CORE_PERF_FIXED_CTR_CTRL.
      */
-    val = core2_vpmu_cxt->ctrls[MSR_CORE_PERF_FIXED_CTR_CTRL_IDX];
-    for ( i = 0; i < core2_fix_counters.num; i++ )
+    val = core2_vpmu_cxt->fixed_ctrl;
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
     {
-        if ( core2_vpmu_cxt->pmu_enable->fixed_ctr_enable[i] )
-            printk("      fixed_%d:   0x%016lx ctrl: %#lx\n",
-                   i, core2_vpmu_cxt->fix_counters[i],
-                   val & FIXED_CTR_CTRL_MASK);
+        printk("      fixed_%d:   0x%016lx ctrl: %#lx\n",
+               i, core2_vpmu_cxt->fix_counters[i],
+               val & FIXED_CTR_CTRL_MASK);
         val >>= FIXED_CTR_CTRL_BITS;
     }
 }
@@ -741,7 +695,7 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
         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);
+        msr_content = 0xC000000700000000 | ((1 << arch_pmc_cnt) - 1);
         wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
     }
     else
@@ -808,6 +762,16 @@ static int core2_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
     }
     ds_warned = 1;
  func_out:
+
+    arch_pmc_cnt = core2_get_arch_pmc_count();
+    fixed_pmc_cnt = core2_get_fixed_pmc_count();
+    if ( fixed_pmc_cnt > VPMU_CORE2_MAX_FIXED_PMCS )
+    {
+        fixed_pmc_cnt = VPMU_CORE2_MAX_FIXED_PMCS;
+        printk(XENLOG_G_WARNING "Limiting number of fixed counters to %d\n",
+               fixed_pmc_cnt);
+    }
+
     check_pmc_quirk();
     return 0;
 }
@@ -815,11 +779,10 @@ static int core2_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
 static void core2_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct core2_vpmu_context *core2_vpmu_cxt = vpmu->context;
 
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
-    xfree(core2_vpmu_cxt->pmu_enable);
+
     xfree(vpmu->context);
     if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
diff --git a/xen/include/asm-x86/hvm/vmx/vpmu_core2.h b/xen/include/asm-x86/hvm/vmx/vpmu_core2.h
index 60b05fd..410372d 100644
--- a/xen/include/asm-x86/hvm/vmx/vpmu_core2.h
+++ b/xen/include/asm-x86/hvm/vmx/vpmu_core2.h
@@ -23,29 +23,10 @@
 #ifndef __ASM_X86_HVM_VPMU_CORE_H_
 #define __ASM_X86_HVM_VPMU_CORE_H_
 
-/* Currently only 3 fixed counters are supported. */
-#define VPMU_CORE2_NUM_FIXED 3
-/* Currently only 3 Non-architectual Performance Control MSRs */
-#define VPMU_CORE2_NUM_CTRLS 3
-
 struct arch_msr_pair {
     u64 counter;
     u64 control;
 };
 
-struct core2_pmu_enable {
-    char ds_area_enable;
-    char fixed_ctr_enable[VPMU_CORE2_NUM_FIXED];
-    char arch_pmc_enable[1];
-};
-
-struct core2_vpmu_context {
-    struct core2_pmu_enable *pmu_enable;
-    u64 fix_counters[VPMU_CORE2_NUM_FIXED];
-    u64 ctrls[VPMU_CORE2_NUM_CTRLS];
-    u64 global_ovf_status;
-    struct arch_msr_pair arch_msr_pair[1];
-};
-
 #endif /* __ASM_X86_HVM_VPMU_CORE_H_ */
 
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94V-0000nH-P7; Sun, 16 Nov 2014 23:17:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94T-0000mR-Bz
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:29 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	C1/3F-27785-88039645; Sun, 16 Nov 2014 23:17:28 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416179846!9569771!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7178 invoked from network); 16 Nov 2014 23:17:27 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:27 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHKV6007689
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:20 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHG21007302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:17 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHGWR023782; Sun, 16 Nov 2014 23:17:16 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:16 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:33 -0500
Message-Id: <1416179271-1221-4-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 03/21] x86/VPMU: Set MSR bitmaps only for
	HVM/PVH guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In preparation for making VPMU code shared with PV make sure that we we update
MSR bitmaps only for HVM/PVH guests

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       | 21 +++++++++++++--------
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  8 +++++---
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 8e07a98..f49af97 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -244,7 +244,8 @@ static int amd_vpmu_save(struct vcpu *v)
 
     context_save(v);
 
-    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) && ctx->msr_bitmap_set )
+    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
+         has_hvm_container_vcpu(v) && ctx->msr_bitmap_set )
         amd_vpmu_unset_msr_bitmap(v);
 
     return 1;
@@ -287,8 +288,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     ASSERT(!supported);
 
     /* For all counters, enable guest only mode for HVM guest */
-    if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
-        !(is_guest_mode(msr_content)) )
+    if ( has_hvm_container_vcpu(v) &&
+         (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
+         !is_guest_mode(msr_content) )
     {
         set_guest_mode(msr_content);
     }
@@ -303,8 +305,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         apic_write(APIC_LVTPC, PMU_APIC_VECTOR);
         vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR;
 
-        if ( !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
-            amd_vpmu_set_msr_bitmap(v);
+        if ( has_hvm_container_vcpu(v) &&
+             !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+             amd_vpmu_set_msr_bitmap(v);
     }
 
     /* stop saving & restore if guest stops first counter */
@@ -314,8 +317,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
         vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
         vpmu_reset(vpmu, VPMU_RUNNING);
-        if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
-            amd_vpmu_unset_msr_bitmap(v);
+        if ( has_hvm_container_vcpu(v) &&
+             ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+             amd_vpmu_unset_msr_bitmap(v);
         release_pmu_ownship(PMU_OWNER_HVM);
     }
 
@@ -406,7 +410,8 @@ static void amd_vpmu_destroy(struct vcpu *v)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
-    if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+    if ( has_hvm_container_vcpu(v) &&
+         ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
         amd_vpmu_unset_msr_bitmap(v);
 
     xfree(vpmu->context);
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 68b6272..54e96b6 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -335,7 +335,8 @@ static int core2_vpmu_save(struct vcpu *v)
     __core2_vpmu_save(v);
 
     /* Unset PMU MSR bitmap to trap lazy load. */
-    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) && cpu_has_vmx_msr_bitmap )
+    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
+         has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
 
     return 1;
@@ -448,7 +449,8 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
     {
         __core2_vpmu_load(current);
         vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
-        if ( cpu_has_vmx_msr_bitmap )
+        if ( has_hvm_container_vcpu(current) &&
+             cpu_has_vmx_msr_bitmap )
             core2_vpmu_set_msr_bitmap(current->arch.hvm_vmx.msr_bitmap);
     }
     return 1;
@@ -822,7 +824,7 @@ static void core2_vpmu_destroy(struct vcpu *v)
         return;
     xfree(core2_vpmu_cxt->pmu_enable);
     xfree(vpmu->context);
-    if ( cpu_has_vmx_msr_bitmap )
+    if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
     release_pmu_ownship(PMU_OWNER_HVM);
     vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94e-0000vY-76; Sun, 16 Nov 2014 23:17:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94c-0000sh-2A
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:38 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	69/BA-17694-19039645; Sun, 16 Nov 2014 23:17:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416179853!11749510!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28600 invoked from network); 16 Nov 2014 23:17:34 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:34 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHR5M007732
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:27 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHQS9016549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:26 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHPcE012835; Sun, 16 Nov 2014 23:17:25 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:25 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:42 -0500
Message-Id: <1416179271-1221-13-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 12/21] x86/VPMU: Initialize VPMUs with
	__initcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 some VPMU initilization operations into __initcalls to avoid performing
same tests and calculations for each vcpu.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       | 115 +++++++++++++---------------
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 154 +++++++++++++++++++-------------------
 xen/arch/x86/hvm/vpmu.c           |  35 +++++++++
 xen/include/asm-x86/hvm/vpmu.h    |   2 +
 4 files changed, 166 insertions(+), 140 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 61d56d5..8460d7b 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -356,57 +356,6 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
     return 1;
 }
 
-static int amd_vpmu_initialise(struct vcpu *v)
-{
-    struct xen_pmu_amd_ctxt *ctxt;
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    uint8_t family = current_cpu_data.x86;
-
-    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
-        return 0;
-
-    if ( counters == NULL )
-    {
-         switch ( family )
-	 {
-	 case 0x15:
-	     num_counters = F15H_NUM_COUNTERS;
-	     counters = AMD_F15H_COUNTERS;
-	     ctrls = AMD_F15H_CTRLS;
-	     k7_counters_mirrored = 1;
-	     break;
-	 case 0x10:
-	 case 0x12:
-	 case 0x14:
-	 case 0x16:
-	 default:
-	     num_counters = F10H_NUM_COUNTERS;
-	     counters = AMD_F10H_COUNTERS;
-	     ctrls = AMD_F10H_CTRLS;
-	     k7_counters_mirrored = 0;
-	     break;
-	 }
-    }
-
-    ctxt = xzalloc_bytes(sizeof(*ctxt) +
-                         2 * sizeof(uint64_t) * num_counters);
-    if ( !ctxt )
-    {
-        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 -ENOMEM;
-    }
-
-    ctxt->counters = sizeof(*ctxt);
-    ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
-
-    vpmu->context = ctxt;
-    vpmu->priv_context = NULL;
-    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
-    return 0;
-}
-
 static void amd_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
@@ -480,30 +429,66 @@ struct arch_vpmu_ops amd_vpmu_ops = {
 
 int svm_vpmu_initialise(struct vcpu *v)
 {
+    struct xen_pmu_amd_ctxt *ctxt;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    uint8_t family = current_cpu_data.x86;
-    int ret = 0;
 
-    /* vpmu enabled? */
-    if ( vpmu_mode == XENPMU_MODE_OFF )
+    if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+         vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return 0;
 
-    switch ( family )
+    if ( !counters )
+        return -EINVAL;
+
+    ctxt = xzalloc_bytes(sizeof(*ctxt) +
+                         2 * sizeof(uint64_t) * num_counters);
+    if ( !ctxt )
+    {
+        printk(XENLOG_G_WARNING "Insufficient memory for PMU, "
+               " PMU feature is unavailable on domain %d vcpu %d.\n",
+               v->vcpu_id, v->domain->domain_id);
+        return -ENOMEM;
+    }
+
+    ctxt->counters = sizeof(*ctxt);
+    ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
+
+    vpmu->context = ctxt;
+    vpmu->priv_context = NULL;
+
+    vpmu->arch_vpmu_ops = &amd_vpmu_ops;
+
+    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
+    return 0;
+}
+
+int __init amd_vpmu_init(void)
+{
+    if ( current_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return -EINVAL;
+
+    switch ( current_cpu_data.x86 )
     {
+    case 0x15:
+        num_counters = F15H_NUM_COUNTERS;
+        counters = AMD_F15H_COUNTERS;
+        ctrls = AMD_F15H_CTRLS;
+        k7_counters_mirrored = 1;
+        break;
     case 0x10:
     case 0x12:
     case 0x14:
-    case 0x15:
     case 0x16:
-        ret = amd_vpmu_initialise(v);
-        if ( !ret )
-            vpmu->arch_vpmu_ops = &amd_vpmu_ops;
-        return ret;
+        num_counters = F10H_NUM_COUNTERS;
+        counters = AMD_F10H_COUNTERS;
+        ctrls = AMD_F10H_CTRLS;
+        k7_counters_mirrored = 0;
+        break;
+    default:
+        printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
+               current_cpu_data.x86);
+        return -EINVAL;
     }
 
-    printk("VPMU: Initialization failed. "
-           "AMD processor family %d has not "
-           "been supported\n", family);
-    return -EINVAL;
+    return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 23e4899..e199367 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -708,62 +708,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
     return 1;
 }
 
-static int core2_vpmu_initialise(struct vcpu *v)
-{
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    u64 msr_content;
-    static bool_t ds_warned;
-
-    if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
-        goto func_out;
-    /* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
-    while ( boot_cpu_has(X86_FEATURE_DS) )
-    {
-        if ( !boot_cpu_has(X86_FEATURE_DTES64) )
-        {
-            if ( !ds_warned )
-                printk(XENLOG_G_WARNING "CPU doesn't support 64-bit DS Area"
-                       " - Debug Store disabled for guests\n");
-            break;
-        }
-        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);
-            if ( !ds_warned )
-                printk(XENLOG_G_WARNING "CPU has set BTS_UNAVAIL"
-                       " - Debug Store disabled for guests\n");
-            break;
-        }
-
-        vpmu_set(vpmu, VPMU_CPU_HAS_BTS);
-        if ( !ds_warned )
-        {
-            if ( !boot_cpu_has(X86_FEATURE_DSCPL) )
-                printk(XENLOG_G_INFO
-                       "vpmu: CPU doesn't support CPL-Qualified BTS\n");
-            printk("******************************************************\n");
-            printk("** WARNING: Emulation of BTS Feature is switched on **\n");
-            printk("** Using this processor feature in a virtualized    **\n");
-            printk("** environment is not 100%% safe.                    **\n");
-            printk("** Setting the DS buffer address with wrong values  **\n");
-            printk("** may lead to hypervisor hangs or crashes.         **\n");
-            printk("** It is NOT recommended for production use!        **\n");
-            printk("******************************************************\n");
-        }
-        break;
-    }
-    ds_warned = 1;
- func_out:
-
-    arch_pmc_cnt = core2_get_arch_pmc_count();
-    fixed_pmc_cnt = core2_get_fixed_pmc_count();
-    check_pmc_quirk();
-    return 0;
-}
-
 static void core2_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
@@ -832,23 +776,80 @@ struct arch_vpmu_ops core2_no_vpmu_ops = {
 int vmx_vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    uint8_t family = current_cpu_data.x86;
-    uint8_t cpu_model = current_cpu_data.x86_model;
-    int ret = 0;
+    u64 msr_content;
+    static bool_t ds_warned;
 
     vpmu->arch_vpmu_ops = &core2_no_vpmu_ops;
     if ( vpmu_mode == XENPMU_MODE_OFF )
         return 0;
 
-    if ( family == 6 )
-    {
-        u64 caps;
+    if ( (arch_pmc_cnt + fixed_pmc_cnt) == 0 )
+        return -EINVAL;
 
-        rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
-        full_width_write = (caps >> 13) & 1;
+    if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
+        goto func_out;
+    /* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
+    while ( boot_cpu_has(X86_FEATURE_DS) )
+    {
+        if ( !boot_cpu_has(X86_FEATURE_DTES64) )
+        {
+            if ( !ds_warned )
+                printk(XENLOG_G_WARNING "CPU doesn't support 64-bit DS Area"
+                       " - Debug Store disabled for guests\n");
+            break;
+        }
+        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);
+            if ( !ds_warned )
+                printk(XENLOG_G_WARNING "CPU has set BTS_UNAVAIL"
+                       " - Debug Store disabled for guests\n");
+            break;
+        }
 
-        switch ( cpu_model )
+        vpmu_set(vpmu, VPMU_CPU_HAS_BTS);
+        if ( !ds_warned )
         {
+            if ( !boot_cpu_has(X86_FEATURE_DSCPL) )
+                printk(XENLOG_G_INFO
+                       "vpmu: CPU doesn't support CPL-Qualified BTS\n");
+            printk("******************************************************\n");
+            printk("** WARNING: Emulation of BTS Feature is switched on **\n");
+            printk("** Using this processor feature in a virtualized    **\n");
+            printk("** environment is not 100%% safe.                    **\n");
+            printk("** Setting the DS buffer address with wrong values  **\n");
+            printk("** may lead to hypervisor hangs or crashes.         **\n");
+            printk("** It is NOT recommended for production use!        **\n");
+            printk("******************************************************\n");
+        }
+        break;
+    }
+    ds_warned = 1;
+ func_out:
+
+    vpmu->arch_vpmu_ops = &core2_vpmu_ops;
+
+    return 0;
+}
+
+int __init core2_vpmu_init(void)
+{
+    u64 caps;
+
+    if ( current_cpu_data.x86_vendor != X86_VENDOR_INTEL )
+        return -EINVAL;
+
+    if ( current_cpu_data.x86 != 6 )
+    {
+        printk(XENLOG_WARNING "VPMU: only family 6 is supported\n");
+        return -EINVAL;
+    }
+
+    switch ( current_cpu_data.x86_model )
+    {
         /* Core2: */
         case 0x0f: /* original 65 nm celeron/pentium/core2/xeon, "Merom"/"Conroe" */
         case 0x16: /* single-core 65 nm celeron/core2solo "Merom-L"/"Conroe-L" */
@@ -880,16 +881,19 @@ int vmx_vpmu_initialise(struct vcpu *v)
         /* future: */
         case 0x3d:
         case 0x4e:
-            ret = core2_vpmu_initialise(v);
-            if ( !ret )
-                vpmu->arch_vpmu_ops = &core2_vpmu_ops;
-            return ret;
-        }
+            break;
+    default:
+        printk(XENLOG_WARNING "VPMU: Unsupported CPU model %#x\n",
+               current_cpu_data.x86_model);
+        return -EINVAL;
     }
 
-    printk("VPMU: Initialization failed. "
-           "Intel processor family %d model %d has not "
-           "been supported\n", family, cpu_model);
-    return -EINVAL;
-}
+    arch_pmc_cnt = core2_get_arch_pmc_count();
+    fixed_pmc_cnt = core2_get_fixed_pmc_count();
+    rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
+    full_width_write = (caps >> 13) & 1;
 
+    check_pmc_quirk();
+
+    return 0;
+}
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 6d9e6f9..ed3b99a 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -426,3 +426,38 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 
     return ret;
 }
+
+static int __init vpmu_init(void)
+{
+    int vendor = current_cpu_data.x86_vendor;
+
+    if ( vpmu_mode == XENPMU_MODE_OFF )
+    {
+        printk(XENLOG_INFO "VPMU: disabled\n");
+        return 0;
+    }
+
+    switch ( vendor )
+    {
+        case X86_VENDOR_AMD:
+            if ( amd_vpmu_init() )
+               vpmu_mode = XENPMU_MODE_OFF;
+            break;
+        case X86_VENDOR_INTEL:
+            if ( core2_vpmu_init() )
+               vpmu_mode = XENPMU_MODE_OFF;
+            break;
+        default:
+            printk(XENLOG_WARNING "VPMU: Unknown CPU vendor: %d\n", vendor);
+            vpmu_mode = XENPMU_MODE_OFF;
+    }
+
+    if ( vpmu_mode == XENPMU_MODE_OFF )
+        printk(XENLOG_WARNING "VPMU: Disabling due to initialization error\n");
+    else
+        printk(XENLOG_INFO "VPMU: version %d.%d\n",
+               XENPMU_VER_MAJ, XENPMU_VER_MIN);
+
+    return 0;
+}
+__initcall(vpmu_init);
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 5fc15fb..97fe17c 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -52,7 +52,9 @@ struct arch_vpmu_ops {
     void (*arch_vpmu_dump)(const struct vcpu *);
 };
 
+int core2_vpmu_init(void);
 int vmx_vpmu_initialise(struct vcpu *);
+int amd_vpmu_init(void);
 int svm_vpmu_initialise(struct vcpu *);
 
 struct vpmu_struct {
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Q-0000m1-Qe; Sun, 16 Nov 2014 23:17:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94O-0000lY-T6
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:25 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	0A/B5-17958-48039645; Sun, 16 Nov 2014 23:17:24 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416179841!9308243!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6713 invoked from network); 16 Nov 2014 23:17:23 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHFpx007641
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:15 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHDZE023701
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:13 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHDGX012564; Sun, 16 Nov 2014 23:17:13 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:13 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:30 -0500
Message-Id: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 00/21] x86/PMU: Xen PMU PV(H) support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Version 15 of PV(H) PMU patches.

Changes in v15:

* Rewrote vpmu_force_context_switch() to use continue_hypercall_on_cpu()
* Added vpmu_init initcall that will call vendor-specific init routines
* Added a lock to vpmu_struct to serialize pmu_init()/pmu_finish()
* Use SS instead of CS for DPL (instead of RPL)
* Don't take lock for XENPMU_mode_get
* Make vmpu_mode/features an unsigned int (from uint64_t)
* Adjusted pvh_hypercall64_table[] order
* Replaced address range check [XEN_VIRT_START..XEN_VIRT_END] with guest_mode()
* A few style cleanups

Changes in v14:

* Moved struct xen_pmu_regs to pmu.h
* Moved CHECK_pmu_* to an earlier patch (when structures are first introduced)
* Added PMU_SAMPLE_REAL flag to indicate whether the sample was taken in real mode
* Simplified slightly setting rules for xenpmu_data flags
* Rewrote vpmu_force_context_switch() to again use continuations. (Returning EAGAIN
  to user would mean that VPMU mode may get into inconsistent state (across processors)
  and dealing with that is more compicated than I'd like).
* Fixed msraddr_to_bitpos() and converted it into an inline
* Replaced address range check in vmpu_do_interrupt() with guest_mode()
* No error returns from __initcall
* Rebased on top of recent VPMU changes
* Various cleanups

Changes in v13:

* Rearranged data in xenpf_symdata to eliminate a hole (no change in
  structure size)
* Removed unnecessary zeroing of last character in name string during
  symbol read hypercall
* Updated comment in access_vectors for pmu_use operation
* Compute AMD MSR bank size at runtime
* Moved a couple of BUILD_BUG_ON later, to when the structures they are
  checking are first used
* Added ss and eflags to xen_pmu_registers structure
* vpmu_force_context_switch() uses per-cpu tasklet pointers.
* Moved most of arch-specific VPMU initialization code into an __initcall()
  to avoid re-calculating/re-checking things more than once (new patch, #12)
* Replaced is_*_domain() with is_*_vcpu()
* choose_hwdom_vcpu() will now assume that hardware_domain->vcpu[idx]
  is always there (callers will still verify whether or not that's true)
* Fixed a couple of sampled vs. sampling tests in vpmu_do_interrupt()
* Pass CS to the guest unchanged, add pmu_flags's flag to indicate whether the
  sample was for a user or kernel space. Move pmu_flags from xen_pmu_data into
  xen_pmu_arch
* Removed local msr_content variable from vpmu_do_wrmsr()
* Re-arranged code in parse_vpmu_param()
* Made vpmu_interrupt_type checks test for value, not individual bits
* Moved PMU_SOFTIRQ definition into arch-specific header
* Moved vpmu*.c files into xen/arch/x86/cpu/ instead of xen/arch/x86/
* For hypervisor samples, report DOMID_XEN to the guest
* Changed logic to select which registers to report to the guest (include RIP
  check to see whether we are in the hypervisor)

Changes in v12:

* Added XSM support
* Made a valifity check before writing MSR_CORE_PERF_GLOBAL_OVF_CTRL
* Updated documentation for 'vpmu=nmi' option
* Added more text to a bunch of commit messages (per Konrad's request)

Changes in v11:

* Replaced cpu_user_regs with new xen_pmu_regs (IP, SP, CS) in xen_pmu_arch.
  - as part of this re-work noticed that CS registers were set in later patch then
    needed. Moved those changes to appropriate place
* Added new VPMU mode (XENPMU_MODE_HV). Now XENPMU_MODE_SELF will only provide dom0
  with its own samples only (i.e. no hypervisor data) and XENPMU_MODE_HV will be what
  XENPMU_MODE_SELF used to be.
* Kept  vmx_add_guest_msr()/vmx_add_host_load_msr() as wrappers around vmx_add_msr()
* Cleaned up VPMU context switch macros (moved  'if(prev!=next)' back to context_switch())
* Dropped hypercall continuation from vpmu_force_context_switch() and replaced it with
  -EAGAIN error if hypercall_preempt_check() is true after 2ms.
* Kept vpmu_do_rdmsr()/vpmu_do_wrmsr as wrapperd for vpmu_do_msr()
* Move context switching patch (#13) earlier in the series (for proper bisection support)
* Various comment updates and cleanups
* Dropped a bunch of Reviewed-by and all Tested-by tags

Changes in v10:

* Swapped address and name fields of xenpf_symdata (to make it smaller on 32-bit)
* Dropped vmx_rm_guest_msr() as it requires refcountig which makes code more complicated.
* Cleaned up vlapic_reg_write()
* Call vpmu_destroy() for both HVM and PVH VCPUs
* Verify that (xen_pmu_data+PMU register bank) fit into a page
* Return error codes from arch-specific VPMU init code
* Moved VPMU-related context switch logic into inlines
* vpmu_force_context_switch() changes:
  o Avoid greater than page-sized allocations
  o Prevent another VCPU from starting VPMU sync while the first sync is in progress
* Avoid stack leak in do_xenpmu_op()
* Checked validity of Intel VPMU MSR values before they are committed
* Fixed MSR handling in traps.c (avoid potential accesses to Intel MSRs on AMD)
* Fixed VCPU selection in interrupt handler for 32-bit dom0 (sampled => sampling)
* Clarified commit messages (patches 2, 13, 18) 
* Various cleanups

Changes in v9:

* Restore VPMU context after context_saved() is called in
  context_switch(). This is needed because vpmu_load() may end up
  calling vmx_vmcs_try_enter()->vcpu_pause() and that needs is_running
  to be correctly set/cleared. (patch 18, dropped review acks)
* Added patch 2 to properly manage VPMU_CONTEXT_LOADED
* Addressed most of Jan's comments.
  o Keep track of time in vpmu_force_context_switch() to properly break
    out of a loop when using hypercall continuations
  o Fixed logic in calling vpmu_do_msr() in emulate_privileged_op()
  o Cleaned up vpmu_interrupt() wrt vcpu variable names to (hopefully)
    make it more clear which vcpu we are using
  o Cleaned up vpmu_do_wrmsr()
  o Did *not* replace sizeof(uint64_t) with sizeof(variable) in
    amd_vpmu_initialise(): throughout the code registers are declared as
    uint64_t and if we are to add a new type (e.g. reg_t) this should be
    done in a separate patch, unrelated to this series.
  o Various more minor cleanups and code style fixes
  
Changes in v8:

* Cleaned up a bit definitions of struct xenpf_symdata and xen_pmu_params
* Added compat checks for vpmu structures
* Converted vpmu flag manipulation macros to inline routines
* Reimplemented vpmu_unload_all() to avoid long loops
* Reworked PMU fault generation and handling (new patch #12)
* Added checks for domain->vcpu[] non-NULLness
* Added more comments, renamed some routines and macros, code style cleanup


Changes in v7:

* When reading hypervisor symbols make the caller pass buffer length
  (as opposed to having this length be part of the API). Make the
  hypervisor buffer static, make xensyms_read() return zero-length
  string on end-of-symbols. Make 'type' field of xenpf_symdata a char,
  drop compat_pf_symdata definition.
* Spread PVH support across patches as opposed to lumping it into a
  separate patch
* Rename vpmu_is_set_all() to vpmu_are_all_set()
* Split VPMU cleanup patch in two
* Use memmove when copying VMX guest and host MSRs
* Make padding of xen_arch_pmu's context union a constand that does not
  depend on arch context size.
* Set interface version to 0.1
* Check pointer validity in pvpmu_init/destroy()
* Fixed crash in core2_vpmu_dump()
* Fixed crash in vmx_add_msr()
* Break handling of Intel and AMD MSRs in traps.c into separate cases
* Pass full CS selector to guests
* Add lock in pvpmu init code to prevent potential race


Changes in v6:

* Two new patches:
  o Merge VMX MSR add/remove routines in vmcs.c (patch 5)
  o Merge VPMU read/write MSR routines in vpmu.c (patch 14)
* Check for pending NMI softirq after saving VPMU context to prevent a newly-scheduled
  guest from overwriting sampled_vcpu written by de-scheduled VPCU.
* Keep track of enabled counters on Intel. This was removed in earlier patches and
  was a mistake. As result of this change struct vpmu will have a pointer to private
  context data (i.e. data that is not exposed to a PV(H) guest). Use this private pointer
  on SVM as well for storing MSR bitmap status (it was unnecessarily exposed to PV guests
  earlier).
  Dropped Reviewed-by: and Tested-by: tags from patch 4 since it needs to be reviewed
  agan (core2_vpmu_do_wrmsr() routine, mostly)
* Replaced references to dom0 with hardware_domain (and is_control_domain with
  is_hardware_domain for consistency)
* Prevent non-privileged domains from reading PMU MSRs in VPMU_PRIV_MODE
* Reverted unnecessary changes in vpmu_initialise()'s switch statement
* Fixed comment in vpmu_do_interrupt


Changes in v5:

* Dropped patch number 2 ("Stop AMD counters when called from vpmu_save_force()")
  as no longer needed
* Added patch number 2 that marks context as loaded before PMU registers are
  loaded. This prevents situation where a PMU interrupt may occur while context
  is still viewed as not loaded. (This is really a bug fix for exsiting VPMU
  code)
* Renamed xenpmu.h files to pmu.h
* More careful use of is_pv_domain(), is_hvm_domain(, is_pvh_domain and
  has_hvm_container_domain(). Also explicitly disabled support for PVH until
  patch 16 to make distinction between usage of the above macros more clear.
* Added support for disabling VPMU support during runtime.
* Disable VPMUs for non-privileged domains when switching to privileged
  profiling mode
* Added ARM stub for xen_arch_pmu_t
* Separated vpmu_mode from vpmu_features
* Moved CS register query to make sure we use appropriate query mechanism for
  various guest types.
* LVTPC is now set from value in shared area, not copied from dom0
* Various code and comments cleanup as suggested by Jan.

Changes in v4:

* Added support for PVH guests:
  o changes in pvpmu_init() to accommodate both PV and PVH guests, still in patch 10
  o more careful use of is_hvm_domain
  o Additional patch (16)
* Moved HVM interrupt handling out of vpmu_do_interrupt() for NMI-safe handling
* Fixed dom0's VCPU selection in privileged mode
* Added a cast in register copy for 32-bit PV guests cpu_user_regs_t in vpmu_do_interrupt.
  (don't want to expose compat_cpu_user_regs in a public header)
* Renamed public structures by prefixing them with "xen_"
* Added an entry for xenpf_symdata in xlat.lst
* Fixed pv_cpuid check for vpmu-specific cpuid adjustments
* Varios code style fixes
* Eliminated anonymous unions
* Added more verbiage to NMI patch description


Changes in v3:

* Moved PMU MSR banks out from architectural context data structures to allow
for future expansion without protocol changes
* PMU interrupts can be either NMIs or regular vector interrupts (the latter
is the default)
* Context is now marked as PMU_CACHED by the hypervisor code to avoid certain
race conditions with the guest
* Fixed races with PV guest in MSR access handlers
* More Intel VPMU cleanup
* Moved NMI-unsafe code from NMI handler
* Dropped changes to vcpu->is_running
* Added LVTPC apic handling (cached for PV guests)
* Separated privileged profiling mode into a standalone patch
* Separated NMI handling into a standalone patch


Changes in v2:

* Xen symbols are exported as data structure (as opoosed to a set of formatted
strings in v1). Even though one symbol per hypercall is returned performance
appears to be acceptable: reading whole file from dom0 userland takes on average
about twice as long as reading /proc/kallsyms
* More cleanup of Intel VPMU code to simplify publicly exported structures
* There is an architecture-independent and x86-specific public include files (ARM
has a stub)
* General cleanup of public include files to make them more presentable (and
to make auto doc generation better)
* Setting of vcpu->is_running is now done on ARM in schedule_tail as well (making
changes to common/schedule.c architecture-independent). Note that this is not
tested since I don't have access to ARM hardware.
* PCPU ID of interrupted processor is now passed to PV guest


The following patch series adds PMU support in Xen for PV(H)
guests. There is a companion patchset for Linux kernel. In addition,
another set of changes will be provided (later) for userland perf
code.

This version has following limitations:
* For accurate profiling of dom0/Xen dom0 VCPUs should be pinned.
* Hypervisor code is only profiled on processors that have running dom0 VCPUs
on them.
* No backtrace support.

A few notes that may help reviewing:

* A shared data structure (xenpmu_data_t) between each PV VPCU and hypervisor
CPU is used for passing registers' values as well as PMU state at the time of
PMU interrupt.
* PMU interrupts are taken by hypervisor either as NMIs or regular vector
interrupts for both HVM and PV(H). The interrupts are sent as NMIs to HVM guests
and as virtual interrupts to PV(H) guests
* PV guest's interrupt handler does not read/write PMU MSRs directly. Instead, it
accesses xenpmu_data_t and flushes it to HW it before returning.
* PMU mode is controlled at runtime via /sys/hypervisor/pmu/pmu/{pmu_mode,pmu_flags}
in addition to 'vpmu' boot option (which is preserved for back compatibility).
The following modes are provided:
  * disable: VPMU is off
  * enable: VPMU is on. Guests can profile themselves, dom0 profiles itself and Xen
  * priv_enable: dom0 only profiling. dom0 collects samples for everyone. Sampling
    in guests is suspended.
* /proc/xen/xensyms file exports hypervisor's symbols to dom0 (similar to
/proc/kallsyms)
* VPMU infrastructure is now used for HVM, PV and PVH and therefore has been moved
up from hvm subtree


Boris Ostrovsky (21):
  common/symbols: Export hypervisor symbols to privileged guest
  x86/VPMU: Manage VPMU_CONTEXT_SAVE flag in vpmu_save_force()
  x86/VPMU: Set MSR bitmaps only for HVM/PVH guests
  x86/VPMU: Make vpmu macros a bit more efficient
  intel/VPMU: Clean up Intel VPMU code
  vmx: Merge MSR management routines
  x86/VPMU: Handle APIC_LVTPC accesses
  intel/VPMU: MSR_CORE_PERF_GLOBAL_CTRL should be initialized to zero
  x86/VPMU: Add public xenpmu.h
  x86/VPMU: Make vpmu not HVM-specific
  x86/VPMU: Interface for setting PMU mode and flags
  x86/VPMU: Initialize VPMUs with __initcall
  x86/VPMU: Initialize PMU for PV(H) guests
  x86/VPMU: Save VPMU state for PV guests during context switch
  x86/VPMU: When handling MSR accesses, leave fault injection to callers
  x86/VPMU: Add support for PMU register handling on PV guests
  x86/VPMU: Handle PMU interrupts for PV guests
  x86/VPMU: Merge vpmu_rdmsr and vpmu_wrmsr
  x86/VPMU: Add privileged PMU mode
  x86/VPMU: NMI-based VPMU support
  x86/VPMU: Move VPMU files up from hvm/ directory

 docs/misc/xen-command-line.markdown                |   8 +-
 tools/flask/policy/policy/modules/xen/xen.te       |   7 +
 xen/arch/x86/cpu/Makefile                          |   1 +
 xen/arch/x86/cpu/vpmu.c                            | 873 +++++++++++++++++++++
 xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c}    | 245 +++---
 .../x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 780 +++++++++---------
 xen/arch/x86/domain.c                              |  25 +-
 xen/arch/x86/hvm/Makefile                          |   1 -
 xen/arch/x86/hvm/hvm.c                             |   1 +
 xen/arch/x86/hvm/svm/Makefile                      |   1 -
 xen/arch/x86/hvm/svm/svm.c                         |  10 +-
 xen/arch/x86/hvm/vlapic.c                          |   3 +
 xen/arch/x86/hvm/vmx/Makefile                      |   1 -
 xen/arch/x86/hvm/vmx/vmcs.c                        |  84 +-
 xen/arch/x86/hvm/vmx/vmx.c                         |  28 +-
 xen/arch/x86/hvm/vpmu.c                            | 263 -------
 xen/arch/x86/oprofile/op_model_ppro.c              |   8 +-
 xen/arch/x86/platform_hypercall.c                  |  28 +
 xen/arch/x86/traps.c                               |  62 +-
 xen/arch/x86/x86_64/compat/entry.S                 |   4 +
 xen/arch/x86/x86_64/entry.S                        |   4 +
 xen/common/event_channel.c                         |   1 +
 xen/common/symbols.c                               |  54 ++
 xen/include/Makefile                               |   2 +
 xen/include/asm-x86/domain.h                       |   2 +
 xen/include/asm-x86/hvm/vcpu.h                     |   3 -
 xen/include/asm-x86/hvm/vmx/vmcs.h                 |  18 +-
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h           |  51 --
 xen/include/asm-x86/softirq.h                      |   3 +-
 xen/include/asm-x86/{hvm => }/vpmu.h               |  96 ++-
 xen/include/public/arch-arm.h                      |   3 +
 xen/include/public/arch-x86/pmu.h                  |  95 +++
 xen/include/public/platform.h                      |  19 +
 xen/include/public/pmu.h                           |  90 +++
 xen/include/public/xen.h                           |   2 +
 xen/include/xen/hypercall.h                        |   4 +
 xen/include/xen/symbols.h                          |   3 +
 xen/include/xlat.lst                               |   6 +
 xen/include/xsm/dummy.h                            |  20 +
 xen/include/xsm/xsm.h                              |   6 +
 xen/xsm/dummy.c                                    |   1 +
 xen/xsm/flask/hooks.c                              |  28 +
 xen/xsm/flask/policy/access_vectors                |   6 +
 43 files changed, 2018 insertions(+), 932 deletions(-)
 create mode 100644 xen/arch/x86/cpu/vpmu.c
 rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (68%)
 rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (58%)
 delete mode 100644 xen/arch/x86/hvm/vpmu.c
 delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
 rename xen/include/asm-x86/{hvm => }/vpmu.h (54%)
 create mode 100644 xen/include/public/arch-x86/pmu.h
 create mode 100644 xen/include/public/pmu.h

-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Z-0000pv-1D; Sun, 16 Nov 2014 23:17:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94X-0000o1-A0
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:33 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	37/8B-02576-C8039645; Sun, 16 Nov 2014 23:17:32 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416179849!12912834!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22845 invoked from network); 16 Nov 2014 23:17:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:31 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHPPT007715
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:25 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHOXS024016
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 16 Nov 2014 23:17:25 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAGNHN0V016490; Sun, 16 Nov 2014 23:17:23 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:21 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:39 -0500
Message-Id: <1416179271-1221-10-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 09/21] x86/VPMU: Add public xenpmu.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add pmu.h header files, move various macros and structures that will be
shared between hypervisor and PV guests to it.

Move MSR banks out of architectural PMU structures to allow for larger sizes
in the future. The banks are allocated immediately after the context and
PMU structures store offsets to them.

While making these updates, also:
* Remove unused vpmu_domain() macro from vpmu.h
* Convert msraddr_to_bitpos() into an inline and make it a little faster by
  realizing that all Intel's PMU-related MSRs are in the lower MSR range.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/vpmu.c              |  83 +++++++++++----------
 xen/arch/x86/hvm/vmx/vpmu_core2.c        | 123 +++++++++++++++++--------------
 xen/arch/x86/hvm/vpmu.c                  |  10 +++
 xen/arch/x86/oprofile/op_model_ppro.c    |   6 +-
 xen/include/Makefile                     |   2 +
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |  32 --------
 xen/include/asm-x86/hvm/vpmu.h           |  16 ++--
 xen/include/public/arch-arm.h            |   3 +
 xen/include/public/arch-x86/pmu.h        |  90 ++++++++++++++++++++++
 xen/include/public/pmu.h                 |  38 ++++++++++
 xen/include/xlat.lst                     |   4 +
 11 files changed, 274 insertions(+), 133 deletions(-)
 delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
 create mode 100644 xen/include/public/arch-x86/pmu.h
 create mode 100644 xen/include/public/pmu.h

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index af3cdb2..0d30b37 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -30,10 +30,7 @@
 #include <asm/apic.h>
 #include <asm/hvm/vlapic.h>
 #include <asm/hvm/vpmu.h>
-
-#define F10H_NUM_COUNTERS 4
-#define F15H_NUM_COUNTERS 6
-#define MAX_NUM_COUNTERS F15H_NUM_COUNTERS
+#include <public/pmu.h>
 
 #define MSR_F10H_EVNTSEL_GO_SHIFT   40
 #define MSR_F10H_EVNTSEL_EN_SHIFT   22
@@ -49,6 +46,9 @@ static const u32 __read_mostly *counters;
 static const u32 __read_mostly *ctrls;
 static bool_t __read_mostly k7_counters_mirrored;
 
+#define F10H_NUM_COUNTERS   4
+#define F15H_NUM_COUNTERS   6
+
 /* PMU Counter MSRs. */
 static const u32 AMD_F10H_COUNTERS[] = {
     MSR_K7_PERFCTR0,
@@ -83,12 +83,14 @@ static const u32 AMD_F15H_CTRLS[] = {
     MSR_AMD_FAM15H_EVNTSEL5
 };
 
-/* storage for context switching */
-struct amd_vpmu_context {
-    u64 counters[MAX_NUM_COUNTERS];
-    u64 ctrls[MAX_NUM_COUNTERS];
-    bool_t msr_bitmap_set;
-};
+/* Use private context as a flag for MSR bitmap */
+#define msr_bitmap_on(vpmu)    do {                                    \
+                                   (vpmu)->priv_context = (void *)-1L; \
+                               } while (0)
+#define msr_bitmap_off(vpmu)   do {                                    \
+                                   (vpmu)->priv_context = NULL;        \
+                               } while (0)
+#define is_msr_bitmap_on(vpmu) ((vpmu)->priv_context != NULL)
 
 static inline int get_pmu_reg_type(u32 addr)
 {
@@ -142,7 +144,6 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
 {
     unsigned int i;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
 
     for ( i = 0; i < num_counters; i++ )
     {
@@ -150,14 +151,13 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
         svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_WRITE);
     }
 
-    ctxt->msr_bitmap_set = 1;
+    msr_bitmap_on(vpmu);
 }
 
 static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
 {
     unsigned int i;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
 
     for ( i = 0; i < num_counters; i++ )
     {
@@ -165,7 +165,7 @@ static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
         svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_RW);
     }
 
-    ctxt->msr_bitmap_set = 0;
+    msr_bitmap_off(vpmu);
 }
 
 static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
@@ -177,19 +177,22 @@ static inline void context_load(struct vcpu *v)
 {
     unsigned int i;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
+    struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+    uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
+    uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
     for ( i = 0; i < num_counters; i++ )
     {
-        wrmsrl(counters[i], ctxt->counters[i]);
-        wrmsrl(ctrls[i], ctxt->ctrls[i]);
+        wrmsrl(counters[i], counter_regs[i]);
+        wrmsrl(ctrls[i], ctrl_regs[i]);
     }
 }
 
 static void amd_vpmu_load(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
+    struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+    uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
     vpmu_reset(vpmu, VPMU_FROZEN);
 
@@ -198,7 +201,7 @@ static void amd_vpmu_load(struct vcpu *v)
         unsigned int i;
 
         for ( i = 0; i < num_counters; i++ )
-            wrmsrl(ctrls[i], ctxt->ctrls[i]);
+            wrmsrl(ctrls[i], ctrl_regs[i]);
 
         return;
     }
@@ -212,17 +215,17 @@ static inline void context_save(struct vcpu *v)
 {
     unsigned int i;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
+    struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+    uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
 
     /* No need to save controls -- they are saved in amd_vpmu_do_wrmsr */
     for ( i = 0; i < num_counters; i++ )
-        rdmsrl(counters[i], ctxt->counters[i]);
+        rdmsrl(counters[i], counter_regs[i]);
 }
 
 static int amd_vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctx = vpmu->context;
     unsigned int i;
 
     /*
@@ -245,7 +248,7 @@ static int amd_vpmu_save(struct vcpu *v)
     context_save(v);
 
     if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
-         has_hvm_container_vcpu(v) && ctx->msr_bitmap_set )
+         has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
         amd_vpmu_unset_msr_bitmap(v);
 
     return 1;
@@ -256,7 +259,9 @@ static void context_update(unsigned int msr, u64 msr_content)
     unsigned int i;
     struct vcpu *v = current;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
+    struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+    uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
+    uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
     if ( k7_counters_mirrored &&
         ((msr >= MSR_K7_EVNTSEL0) && (msr <= MSR_K7_PERFCTR3)) )
@@ -268,12 +273,12 @@ static void context_update(unsigned int msr, u64 msr_content)
     {
        if ( msr == ctrls[i] )
        {
-           ctxt->ctrls[i] = msr_content;
+           ctrl_regs[i] = msr_content;
            return;
        }
         else if (msr == counters[i] )
         {
-            ctxt->counters[i] = msr_content;
+            counter_regs[i] = msr_content;
             return;
         }
     }
@@ -303,8 +308,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
             return 1;
         vpmu_set(vpmu, VPMU_RUNNING);
 
-        if ( has_hvm_container_vcpu(v) &&
-             !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+        if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
              amd_vpmu_set_msr_bitmap(v);
     }
 
@@ -313,8 +317,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         (is_pmu_enabled(msr_content) == 0) && vpmu_is_set(vpmu, VPMU_RUNNING) )
     {
         vpmu_reset(vpmu, VPMU_RUNNING);
-        if ( has_hvm_container_vcpu(v) &&
-             ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+        if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
              amd_vpmu_unset_msr_bitmap(v);
         release_pmu_ownship(PMU_OWNER_HVM);
     }
@@ -355,7 +358,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
 
 static int amd_vpmu_initialise(struct vcpu *v)
 {
-    struct amd_vpmu_context *ctxt;
+    struct xen_pmu_amd_ctxt *ctxt;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t family = current_cpu_data.x86;
 
@@ -385,7 +388,8 @@ static int amd_vpmu_initialise(struct vcpu *v)
 	 }
     }
 
-    ctxt = xzalloc(struct amd_vpmu_context);
+    ctxt = xzalloc_bytes(sizeof(*ctxt) +
+                         2 * sizeof(uint64_t) * num_counters);
     if ( !ctxt )
     {
         gdprintk(XENLOG_WARNING, "Insufficient memory for PMU, "
@@ -394,7 +398,11 @@ static int amd_vpmu_initialise(struct vcpu *v)
         return -ENOMEM;
     }
 
+    ctxt->counters = sizeof(*ctxt);
+    ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
+
     vpmu->context = ctxt;
+    vpmu->priv_context = NULL;
     vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
     return 0;
 }
@@ -406,8 +414,7 @@ static void amd_vpmu_destroy(struct vcpu *v)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
-    if ( has_hvm_container_vcpu(v) &&
-         ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+    if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
         amd_vpmu_unset_msr_bitmap(v);
 
     xfree(vpmu->context);
@@ -424,7 +431,9 @@ static void amd_vpmu_destroy(struct vcpu *v)
 static void amd_vpmu_dump(const struct vcpu *v)
 {
     const struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    const struct amd_vpmu_context *ctxt = vpmu->context;
+    const struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+    const uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
+    const uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
     unsigned int i;
 
     printk("    VPMU state: 0x%x ", vpmu->flags);
@@ -454,8 +463,8 @@ static void amd_vpmu_dump(const struct vcpu *v)
         rdmsrl(ctrls[i], ctrl);
         rdmsrl(counters[i], cntr);
         printk("      %#x: %#lx (%#lx in HW)    %#x: %#lx (%#lx in HW)\n",
-               ctrls[i], ctxt->ctrls[i], ctrl,
-               counters[i], ctxt->counters[i], cntr);
+               ctrls[i], ctrl_regs[i], ctrl,
+               counters[i], counter_regs[i], cntr);
     }
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index e7fffcf..a6cca38 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -35,8 +35,8 @@
 #include <asm/hvm/vmx/vmcs.h>
 #include <public/sched.h>
 #include <public/hvm/save.h>
+#include <public/pmu.h>
 #include <asm/hvm/vpmu.h>
-#include <asm/hvm/vmx/vpmu_core2.h>
 
 /*
  * See Intel SDM Vol 2a Instruction Set Reference chapter 3 for CPUID
@@ -68,6 +68,10 @@
 #define MSR_PMC_ALIAS_MASK       (~(MSR_IA32_PERFCTR0 ^ MSR_IA32_A_PERFCTR0))
 static bool_t __read_mostly full_width_write;
 
+/* Intel-specific VPMU features */
+#define VPMU_CPU_HAS_DS                     0x100 /* Has Debug Store */
+#define VPMU_CPU_HAS_BTS                    0x200 /* Has Branch Trace Store */
+
 /*
  * MSR_CORE_PERF_FIXED_CTR_CTRL contains the configuration of all fixed
  * counters. 4 bits for every counter.
@@ -75,17 +79,6 @@ static bool_t __read_mostly full_width_write;
 #define FIXED_CTR_CTRL_BITS 4
 #define FIXED_CTR_CTRL_MASK ((1 << FIXED_CTR_CTRL_BITS) - 1)
 
-#define VPMU_CORE2_MAX_FIXED_PMCS     4
-struct core2_vpmu_context {
-    u64 fixed_ctrl;
-    u64 ds_area;
-    u64 pebs_enable;
-    u64 global_ovf_status;
-    u64 enabled_cntrs;  /* Follows PERF_GLOBAL_CTRL MSR format */
-    u64 fix_counters[VPMU_CORE2_MAX_FIXED_PMCS];
-    struct arch_msr_pair arch_msr_pair[1];
-};
-
 /* Number of general-purpose and fixed performance counters */
 static unsigned int __read_mostly arch_pmc_cnt, fixed_pmc_cnt;
 
@@ -222,6 +215,12 @@ static int is_core2_vpmu_msr(u32 msr_index, int *type, int *index)
     }
 }
 
+static inline int msraddr_to_bitpos(int x)
+{
+    ASSERT(x == (x & 0x1fff));
+    return x;
+}
+
 static void core2_vpmu_set_msr_bitmap(unsigned long *msr_bitmap)
 {
     int i;
@@ -291,12 +290,15 @@ static void core2_vpmu_unset_msr_bitmap(unsigned long *msr_bitmap)
 static inline void __core2_vpmu_save(struct vcpu *v)
 {
     int i;
-    struct core2_vpmu_context *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    uint64_t *fixed_counters = vpmu_reg_pointer(core2_vpmu_cxt, fixed_counters);
+    struct xen_pmu_cntr_pair *xen_pmu_cntr_pair =
+        vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
 
     for ( i = 0; i < fixed_pmc_cnt; i++ )
-        rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, core2_vpmu_cxt->fix_counters[i]);
+        rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, fixed_counters[i]);
     for ( i = 0; i < arch_pmc_cnt; i++ )
-        rdmsrl(MSR_IA32_PERFCTR0 + i, core2_vpmu_cxt->arch_msr_pair[i].counter);
+        rdmsrl(MSR_IA32_PERFCTR0 + i, xen_pmu_cntr_pair[i].counter);
 }
 
 static int core2_vpmu_save(struct vcpu *v)
@@ -319,10 +321,13 @@ static int core2_vpmu_save(struct vcpu *v)
 static inline void __core2_vpmu_load(struct vcpu *v)
 {
     unsigned int i, pmc_start;
-    struct core2_vpmu_context *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    uint64_t *fixed_counters = vpmu_reg_pointer(core2_vpmu_cxt, fixed_counters);
+    struct xen_pmu_cntr_pair *xen_pmu_cntr_pair =
+        vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
 
     for ( i = 0; i < fixed_pmc_cnt; i++ )
-        wrmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, core2_vpmu_cxt->fix_counters[i]);
+        wrmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, fixed_counters[i]);
 
     if ( full_width_write )
         pmc_start = MSR_IA32_A_PERFCTR0;
@@ -330,8 +335,8 @@ static inline void __core2_vpmu_load(struct vcpu *v)
         pmc_start = MSR_IA32_PERFCTR0;
     for ( i = 0; i < arch_pmc_cnt; i++ )
     {
-        wrmsrl(pmc_start + i, core2_vpmu_cxt->arch_msr_pair[i].counter);
-        wrmsrl(MSR_P6_EVNTSEL(i), core2_vpmu_cxt->arch_msr_pair[i].control);
+        wrmsrl(pmc_start + i, xen_pmu_cntr_pair[i].counter);
+        wrmsrl(MSR_P6_EVNTSEL(i), xen_pmu_cntr_pair[i].control);
     }
 
     wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
@@ -354,7 +359,8 @@ static void core2_vpmu_load(struct vcpu *v)
 static int core2_vpmu_alloc_resource(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct core2_vpmu_context *core2_vpmu_cxt;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = NULL;
+    uint64_t *p = NULL;
 
     if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
         return 0;
@@ -367,12 +373,20 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
         goto out_err;
     vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
 
-    core2_vpmu_cxt = xzalloc_bytes(sizeof(struct core2_vpmu_context) +
-                    (arch_pmc_cnt-1)*sizeof(struct arch_msr_pair));
-    if ( !core2_vpmu_cxt )
+    core2_vpmu_cxt = xzalloc_bytes(sizeof(*core2_vpmu_cxt) +
+                                   sizeof(uint64_t) * fixed_pmc_cnt +
+                                   sizeof(struct xen_pmu_cntr_pair) *
+                                   arch_pmc_cnt);
+    p = xzalloc(uint64_t);
+    if ( !core2_vpmu_cxt || !p )
         goto out_err;
 
-    vpmu->context = (void *)core2_vpmu_cxt;
+    core2_vpmu_cxt->fixed_counters = sizeof(*core2_vpmu_cxt);
+    core2_vpmu_cxt->arch_counters = core2_vpmu_cxt->fixed_counters +
+                                    sizeof(uint64_t) * fixed_pmc_cnt;
+
+    vpmu->context = core2_vpmu_cxt;
+    vpmu->priv_context = p;
 
     vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
 
@@ -381,6 +395,9 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
 out_err:
     release_pmu_ownship(PMU_OWNER_HVM);
 
+    xfree(core2_vpmu_cxt);
+    xfree(p);
+
     printk("Failed to allocate VPMU resources for domain %u vcpu %u\n",
            v->vcpu_id, v->domain->domain_id);
 
@@ -418,7 +435,8 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     int type = -1, index = -1;
     struct vcpu *v = current;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct core2_vpmu_context *core2_vpmu_cxt = NULL;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt;
+    uint64_t *enabled_cntrs;
 
     if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
     {
@@ -446,10 +464,11 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     ASSERT(!supported);
 
     core2_vpmu_cxt = vpmu->context;
+    enabled_cntrs = vpmu->priv_context;
     switch ( msr )
     {
     case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
-        core2_vpmu_cxt->global_ovf_status &= ~msr_content;
+        core2_vpmu_cxt->global_status &= ~msr_content;
         return 1;
     case MSR_CORE_PERF_GLOBAL_STATUS:
         gdprintk(XENLOG_INFO, "Can not write readonly MSR: "
@@ -483,15 +502,14 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         break;
     case MSR_CORE_PERF_FIXED_CTR_CTRL:
         vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
-        core2_vpmu_cxt->enabled_cntrs &=
-                ~(((1ULL << VPMU_CORE2_MAX_FIXED_PMCS) - 1) << 32);
+        *enabled_cntrs &= ~(((1ULL << fixed_pmc_cnt) - 1) << 32);
         if ( msr_content != 0 )
         {
             u64 val = msr_content;
             for ( i = 0; i < fixed_pmc_cnt; i++ )
             {
                 if ( val & 3 )
-                    core2_vpmu_cxt->enabled_cntrs |= (1ULL << 32) << i;
+                    *enabled_cntrs |= (1ULL << 32) << i;
                 val >>= FIXED_CTR_CTRL_BITS;
             }
         }
@@ -502,19 +520,21 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         tmp = msr - MSR_P6_EVNTSEL(0);
         if ( tmp >= 0 && tmp < arch_pmc_cnt )
         {
+            struct xen_pmu_cntr_pair *xen_pmu_cntr_pair =
+                vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
+
             vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
 
             if ( msr_content & (1ULL << 22) )
-                core2_vpmu_cxt->enabled_cntrs |= 1ULL << tmp;
+                *enabled_cntrs |= 1ULL << tmp;
             else
-                core2_vpmu_cxt->enabled_cntrs &= ~(1ULL << tmp);
+                *enabled_cntrs &= ~(1ULL << tmp);
 
-            core2_vpmu_cxt->arch_msr_pair[tmp].control = msr_content;
+            xen_pmu_cntr_pair[tmp].control = msr_content;
         }
     }
 
-    if ( (global_ctrl & core2_vpmu_cxt->enabled_cntrs) ||
-         (core2_vpmu_cxt->ds_area != 0)  )
+    if ( (global_ctrl & *enabled_cntrs) || (core2_vpmu_cxt->ds_area != 0) )
         vpmu_set(vpmu, VPMU_RUNNING);
     else
         vpmu_reset(vpmu, VPMU_RUNNING);
@@ -560,7 +580,7 @@ static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
     int type = -1, index = -1;
     struct vcpu *v = current;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct core2_vpmu_context *core2_vpmu_cxt = NULL;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt;
 
     if ( core2_vpmu_msr_common_check(msr, &type, &index) )
     {
@@ -571,7 +591,7 @@ static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
             *msr_content = 0;
             break;
         case MSR_CORE_PERF_GLOBAL_STATUS:
-            *msr_content = core2_vpmu_cxt->global_ovf_status;
+            *msr_content = core2_vpmu_cxt->global_status;
             break;
         case MSR_CORE_PERF_GLOBAL_CTRL:
             vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
@@ -620,10 +640,12 @@ static void core2_vpmu_dump(const struct vcpu *v)
 {
     const struct vpmu_struct *vpmu = vcpu_vpmu(v);
     unsigned int i;
-    const struct core2_vpmu_context *core2_vpmu_cxt = NULL;
+    const struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vpmu->context;
     u64 val;
+    uint64_t *fixed_counters;
+    struct xen_pmu_cntr_pair *cntr_pair;
 
-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
+    if ( !core2_vpmu_cxt || !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
          return;
 
     if ( !vpmu_is_set(vpmu, VPMU_RUNNING) )
@@ -636,16 +658,15 @@ static void core2_vpmu_dump(const struct vcpu *v)
     }
 
     printk("    vPMU running\n");
-    core2_vpmu_cxt = vpmu->context;
+
+    cntr_pair = vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
+    fixed_counters = vpmu_reg_pointer(core2_vpmu_cxt, fixed_counters);
 
     /* Print the contents of the counter and its configuration msr. */
     for ( i = 0; i < arch_pmc_cnt; i++ )
-    {
-        const struct arch_msr_pair *msr_pair = core2_vpmu_cxt->arch_msr_pair;
-
         printk("      general_%d: 0x%016lx ctrl: 0x%016lx\n",
-               i, msr_pair[i].counter, msr_pair[i].control);
-    }
+            i, cntr_pair[i].counter, cntr_pair[i].control);
+
     /*
      * The configuration of the fixed counter is 4 bits each in the
      * MSR_CORE_PERF_FIXED_CTR_CTRL.
@@ -654,7 +675,7 @@ static void core2_vpmu_dump(const struct vcpu *v)
     for ( i = 0; i < fixed_pmc_cnt; i++ )
     {
         printk("      fixed_%d:   0x%016lx ctrl: %#lx\n",
-               i, core2_vpmu_cxt->fix_counters[i],
+               i, fixed_counters[i],
                val & FIXED_CTR_CTRL_MASK);
         val >>= FIXED_CTR_CTRL_BITS;
     }
@@ -665,14 +686,14 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
     struct vcpu *v = current;
     u64 msr_content;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct core2_vpmu_context *core2_vpmu_cxt = vpmu->context;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vpmu->context;
 
     rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content);
     if ( msr_content )
     {
         if ( is_pmc_quirk )
             handle_pmc_quirk(msr_content);
-        core2_vpmu_cxt->global_ovf_status |= msr_content;
+        core2_vpmu_cxt->global_status |= msr_content;
         msr_content = 0xC000000700000000 | ((1 << arch_pmc_cnt) - 1);
         wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
     }
@@ -739,13 +760,6 @@ static int core2_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
 
     arch_pmc_cnt = core2_get_arch_pmc_count();
     fixed_pmc_cnt = core2_get_fixed_pmc_count();
-    if ( fixed_pmc_cnt > VPMU_CORE2_MAX_FIXED_PMCS )
-    {
-        fixed_pmc_cnt = VPMU_CORE2_MAX_FIXED_PMCS;
-        printk(XENLOG_G_WARNING "Limiting number of fixed counters to %d\n",
-               fixed_pmc_cnt);
-    }
-
     check_pmc_quirk();
     return 0;
 }
@@ -758,6 +772,7 @@ static void core2_vpmu_destroy(struct vcpu *v)
         return;
 
     xfree(vpmu->context);
+    xfree(vpmu->priv_context);
     if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
     release_pmu_ownship(PMU_OWNER_HVM);
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 29d9fde..f96b530 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -31,6 +31,13 @@
 #include <asm/hvm/svm/svm.h>
 #include <asm/hvm/svm/vmcb.h>
 #include <asm/apic.h>
+#include <public/pmu.h>
+
+#include <compat/pmu.h>
+CHECK_pmu_intel_ctxt;
+CHECK_pmu_amd_ctxt;
+CHECK_pmu_cntr_pair;
+CHECK_pmu_regs;
 
 /*
  * "vpmu" :     vpmu generally enabled
@@ -226,6 +233,9 @@ void vpmu_initialise(struct vcpu *v)
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t vendor = current_cpu_data.x86_vendor;
 
+    BUILD_BUG_ON(sizeof(struct xen_pmu_intel_ctxt) > XENPMU_CTXT_PAD_SZ);
+    BUILD_BUG_ON(sizeof(struct xen_pmu_amd_ctxt) > XENPMU_CTXT_PAD_SZ);
+
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         vpmu_destroy(v);
     vpmu_clear(vpmu);
diff --git a/xen/arch/x86/oprofile/op_model_ppro.c b/xen/arch/x86/oprofile/op_model_ppro.c
index aa99e4d..ca429a1 100644
--- a/xen/arch/x86/oprofile/op_model_ppro.c
+++ b/xen/arch/x86/oprofile/op_model_ppro.c
@@ -20,11 +20,15 @@
 #include <asm/regs.h>
 #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"
 
+struct arch_msr_pair {
+    u64 counter;
+    u64 control;
+};
+
 /*
  * Intel "Architectural Performance Monitoring" CPUID
  * detection/enumeration details:
diff --git a/xen/include/Makefile b/xen/include/Makefile
index f7ccbc9..f97733a 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -26,7 +26,9 @@ headers-y := \
 headers-$(CONFIG_X86)     += compat/arch-x86/xen-mca.h
 headers-$(CONFIG_X86)     += compat/arch-x86/xen.h
 headers-$(CONFIG_X86)     += compat/arch-x86/xen-$(compat-arch-y).h
+headers-$(CONFIG_X86)     += compat/arch-x86/pmu.h
 headers-y                 += compat/arch-$(compat-arch-y).h compat/xlat.h
+headers-y                 += compat/pmu.h
 headers-$(FLASK_ENABLE)   += compat/xsm/flask_op.h
 
 cppflags-y                := -include public/xen-compat.h
diff --git a/xen/include/asm-x86/hvm/vmx/vpmu_core2.h b/xen/include/asm-x86/hvm/vmx/vpmu_core2.h
deleted file mode 100644
index 410372d..0000000
--- a/xen/include/asm-x86/hvm/vmx/vpmu_core2.h
+++ /dev/null
@@ -1,32 +0,0 @@
-
-/*
- * vpmu_core2.h: CORE 2 specific PMU virtualization for HVM domain.
- *
- * Copyright (c) 2007, Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
- * Place - Suite 330, Boston, MA 02111-1307 USA.
- *
- * Author: Haitao Shan <haitao.shan@intel.com>
- */
-
-#ifndef __ASM_X86_HVM_VPMU_CORE_H_
-#define __ASM_X86_HVM_VPMU_CORE_H_
-
-struct arch_msr_pair {
-    u64 counter;
-    u64 control;
-};
-
-#endif /* __ASM_X86_HVM_VPMU_CORE_H_ */
-
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 9c4e65a..83eea7e 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -22,6 +22,8 @@
 #ifndef __ASM_X86_HVM_VPMU_H_
 #define __ASM_X86_HVM_VPMU_H_
 
+#include <public/pmu.h>
+
 /*
  * Flag bits given as a string on the hypervisor boot parameter 'vpmu'.
  * See arch/x86/hvm/vpmu.c.
@@ -29,12 +31,9 @@
 #define VPMU_BOOT_ENABLED 0x1    /* vpmu generally enabled. */
 #define VPMU_BOOT_BTS     0x2    /* Intel BTS feature wanted. */
 
-
-#define msraddr_to_bitpos(x) (((x)&0xffff) + ((x)>>31)*0x2000)
 #define vcpu_vpmu(vcpu)   (&((vcpu)->arch.hvm_vcpu.vpmu))
 #define vpmu_vcpu(vpmu)   (container_of((vpmu), struct vcpu, \
                                           arch.hvm_vcpu.vpmu))
-#define vpmu_domain(vpmu) (vpmu_vcpu(vpmu)->domain)
 
 #define MSR_TYPE_COUNTER            0
 #define MSR_TYPE_CTRL               1
@@ -42,6 +41,9 @@
 #define MSR_TYPE_ARCH_COUNTER       3
 #define MSR_TYPE_ARCH_CTRL          4
 
+/* Start of PMU register bank */
+#define vpmu_reg_pointer(ctxt, offset) ((void *)((uintptr_t)ctxt + \
+                                                 (uintptr_t)ctxt->offset))
 
 /* Arch specific operations shared by all vpmus */
 struct arch_vpmu_ops {
@@ -65,7 +67,8 @@ struct vpmu_struct {
     u32 flags;
     u32 last_pcpu;
     u32 hw_lapic_lvtpc;
-    void *context;
+    void *context;      /* May be shared with PV guest */
+    void *priv_context; /* hypervisor-only */
     struct arch_vpmu_ops *arch_vpmu_ops;
 };
 
@@ -77,11 +80,6 @@ struct vpmu_struct {
 #define VPMU_FROZEN                         0x10  /* Stop counters while VCPU is not running */
 #define VPMU_PASSIVE_DOMAIN_ALLOCATED       0x20
 
-/* VPMU features */
-#define VPMU_CPU_HAS_DS                     0x100 /* Has Debug Store */
-#define VPMU_CPU_HAS_BTS                    0x200 /* Has Branch Trace Store */
-
-
 static inline void vpmu_set(struct vpmu_struct *vpmu, const u32 mask)
 {
     vpmu->flags |= mask;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e711606..f694369 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -423,6 +423,9 @@ typedef uint64_t xen_callback_t;
 
 #endif
 
+/* Stub definition of PMU structure */
+typedef struct xen_pmu_arch {} xen_pmu_arch_t;
+
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
 
 /*
diff --git a/xen/include/public/arch-x86/pmu.h b/xen/include/public/arch-x86/pmu.h
new file mode 100644
index 0000000..b0f9100
--- /dev/null
+++ b/xen/include/public/arch-x86/pmu.h
@@ -0,0 +1,90 @@
+#ifndef __XEN_PUBLIC_ARCH_X86_PMU_H__
+#define __XEN_PUBLIC_ARCH_X86_PMU_H__
+
+/* x86-specific PMU definitions */
+
+/* AMD PMU registers and structures */
+struct xen_pmu_amd_ctxt {
+    /* Offsets to counter and control MSRs (relative to xen_pmu_arch.c.amd) */
+    uint32_t counters;
+    uint32_t ctrls;
+};
+typedef struct xen_pmu_amd_ctxt xen_pmu_amd_ctxt_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_amd_ctxt_t);
+
+/* Intel PMU registers and structures */
+struct xen_pmu_cntr_pair {
+    uint64_t counter;
+    uint64_t control;
+};
+typedef struct xen_pmu_cntr_pair xen_pmu_cntr_pair_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_cntr_pair_t);
+
+struct xen_pmu_intel_ctxt {
+    uint64_t global_ctrl;
+    uint64_t global_ovf_ctrl;
+    uint64_t global_status;
+    uint64_t fixed_ctrl;
+    uint64_t ds_area;
+    uint64_t pebs_enable;
+    uint64_t debugctl;
+    /*
+     * Offsets to fixed and architectural counter MSRs (relative to
+     * xen_pmu_arch.c.intel)
+     */
+    uint32_t fixed_counters;
+    uint32_t arch_counters;
+};
+typedef struct xen_pmu_intel_ctxt xen_pmu_intel_ctxt_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_intel_ctxt_t);
+
+/* Sampled domain's registers */
+struct xen_pmu_regs {
+    uint64_t ip;
+    uint64_t sp;
+    uint64_t flags;
+    uint16_t cs;
+    uint16_t ss;
+    uint32_t pad;
+};
+typedef struct xen_pmu_regs xen_pmu_regs_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_regs_t);
+
+struct xen_pmu_arch {
+    union {
+        struct xen_pmu_regs regs;
+        /* Padding for adding new registers to xen_pmu_regs in the future */
+#define XENPMU_REGS_PAD_SZ  64
+        uint8_t pad[XENPMU_REGS_PAD_SZ];
+    } r;
+    uint64_t pmu_flags;
+    union {
+        uint32_t lapic_lvtpc;
+        uint64_t pad;
+    } l;
+    union {
+        struct xen_pmu_amd_ctxt amd;
+        struct xen_pmu_intel_ctxt intel;
+
+        /*
+         * Padding for contexts (fixed parts only, does not include MSR banks
+         * that are specified by offsets
+         */
+#define XENPMU_CTXT_PAD_SZ  128
+        uint8_t pad[XENPMU_CTXT_PAD_SZ];
+    } c;
+};
+typedef struct xen_pmu_arch xen_pmu_arch_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_arch_t);
+
+#endif /* __XEN_PUBLIC_ARCH_X86_PMU_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/include/public/pmu.h b/xen/include/public/pmu.h
new file mode 100644
index 0000000..f97106d
--- /dev/null
+++ b/xen/include/public/pmu.h
@@ -0,0 +1,38 @@
+#ifndef __XEN_PUBLIC_PMU_H__
+#define __XEN_PUBLIC_PMU_H__
+
+#include "xen.h"
+#if defined(__i386__) || defined(__x86_64__)
+#include "arch-x86/pmu.h"
+#elif defined (__arm__) || defined (__aarch64__)
+#include "arch-arm.h"
+#else
+#error "Unsupported architecture"
+#endif
+
+#define XENPMU_VER_MAJ    0
+#define XENPMU_VER_MIN    1
+
+
+/* Shared between hypervisor and PV domain */
+struct xen_pmu_data {
+    uint32_t domain_id;
+    uint32_t vcpu_id;
+    uint32_t pcpu_id;
+
+    uint32_t pad;
+
+    xen_pmu_arch_t pmu;
+};
+
+#endif /* __XEN_PUBLIC_PMU_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index eb40aab..8bff86d 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -103,6 +103,10 @@
 !	vcpu_set_singleshot_timer	vcpu.h
 ?	xenoprof_init			xenoprof.h
 ?	xenoprof_passive		xenoprof.h
+?	pmu_intel_ctxt			arch-x86/pmu.h
+?	pmu_amd_ctxt			arch-x86/pmu.h
+?	pmu_cntr_pair			arch-x86/pmu.h
+?	pmu_regs			arch-x86/pmu.h
 ?	flask_access			xsm/flask_op.h
 !	flask_boolean			xsm/flask_op.h
 ?	flask_cache_stats		xsm/flask_op.h
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94f-0000wW-1g; Sun, 16 Nov 2014 23:17:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94c-0000tV-Pn
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	72/A2-09842-29039645; Sun, 16 Nov 2014 23:17:38 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416179855!13161211!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13951 invoked from network); 16 Nov 2014 23:17:37 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:37 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHUok003475
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:30 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHT7j016619
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:29 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHSa2024155; Sun, 16 Nov 2014 23:17:28 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:28 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:45 -0500
Message-Id: <1416179271-1221-16-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 15/21] x86/VPMU: When handling MSR accesses,
	leave fault injection to callers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With this patch return value of 1 of vpmu_do_msr() will now indicate whether an
error was encountered during MSR processing (instead of stating that the access
was to a VPMU register).

As part of this patch we also check for validity of certain MSR accesses right
when we determine which register is being written, as opposed to postponing this
until later.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/svm.c        |  6 ++-
 xen/arch/x86/hvm/svm/vpmu.c       |  6 +--
 xen/arch/x86/hvm/vmx/vmx.c        | 24 +++++++++---
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 78 ++++++++++++++-------------------------
 4 files changed, 53 insertions(+), 61 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b1c4845..d0ba075 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1700,7 +1700,8 @@ static int svm_msr_read_intercept(unsigned int msr, uint64_t *msr_content)
     case MSR_AMD_FAM15H_EVNTSEL3:
     case MSR_AMD_FAM15H_EVNTSEL4:
     case MSR_AMD_FAM15H_EVNTSEL5:
-        vpmu_do_rdmsr(msr, msr_content);
+        if ( vpmu_do_rdmsr(msr, msr_content) )
+            goto gpf;
         break;
 
     case MSR_AMD64_DR0_ADDRESS_MASK:
@@ -1851,7 +1852,8 @@ static int svm_msr_write_intercept(unsigned int msr, uint64_t msr_content)
     case MSR_AMD_FAM15H_EVNTSEL3:
     case MSR_AMD_FAM15H_EVNTSEL4:
     case MSR_AMD_FAM15H_EVNTSEL5:
-        vpmu_do_wrmsr(msr, msr_content, 0);
+        if ( vpmu_do_wrmsr(msr, msr_content, 0) )
+            goto gpf;
         break;
 
     case MSR_IA32_MCx_MISC(4): /* Threshold register */
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index fe852ed..b54a51d 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -305,7 +305,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         is_pmu_enabled(msr_content) && !vpmu_is_set(vpmu, VPMU_RUNNING) )
     {
         if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
-            return 1;
+            return 0;
         vpmu_set(vpmu, VPMU_RUNNING);
 
         if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
@@ -335,7 +335,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
 
     /* Write to hw counters */
     wrmsrl(msr, msr_content);
-    return 1;
+    return 0;
 }
 
 static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
@@ -353,7 +353,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
 
     rdmsrl(msr, *msr_content);
 
-    return 1;
+    return 0;
 }
 
 static void amd_vpmu_destroy(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index a7c3a7a..ef7ce72 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2112,12 +2112,17 @@ static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content)
         *msr_content |= MSR_IA32_MISC_ENABLE_BTS_UNAVAIL |
                        MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL;
         /* Perhaps vpmu will change some bits. */
+        /* FALLTHROUGH */
+    case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+    case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
+    case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+    case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+    case MSR_IA32_PEBS_ENABLE:
+    case MSR_IA32_DS_AREA:
         if ( vpmu_do_rdmsr(msr, msr_content) )
-            goto done;
+            goto gp_fault;
         break;
     default:
-        if ( vpmu_do_rdmsr(msr, msr_content) )
-            break;
         if ( passive_domain_do_rdmsr(msr, msr_content) )
             goto done;
         switch ( long_mode_do_msr_read(msr, msr_content) )
@@ -2293,7 +2298,7 @@ static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content)
         if ( msr_content & ~supported )
         {
             /* Perhaps some other bits are supported in vpmu. */
-            if ( !vpmu_do_wrmsr(msr, msr_content, supported) )
+            if ( vpmu_do_wrmsr(msr, msr_content, supported) )
                 break;
         }
         if ( msr_content & IA32_DEBUGCTLMSR_LBR )
@@ -2321,9 +2326,16 @@ static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content)
         if ( !nvmx_msr_write_intercept(msr, msr_content) )
             goto gp_fault;
         break;
+    case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+    case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(7):
+    case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+    case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+    case MSR_IA32_PEBS_ENABLE:
+    case MSR_IA32_DS_AREA:
+         if ( vpmu_do_wrmsr(msr, msr_content, 0) )
+            goto gp_fault;
+        break;
     default:
-        if ( vpmu_do_wrmsr(msr, msr_content, 0) )
-            return X86EMUL_OKAY;
         if ( passive_domain_do_wrmsr(msr, msr_content) )
             return X86EMUL_OKAY;
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 03dc981..2dd8000 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -463,36 +463,41 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
                              IA32_DEBUGCTLMSR_BTS_OFF_USR;
             if ( !(msr_content & ~supported) &&
                  vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
-                return 1;
+                return 0;
             if ( (msr_content & supported) &&
                  !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
                 printk(XENLOG_G_WARNING
                        "%pv: Debug Store unsupported on this CPU\n",
                        current);
         }
-        return 0;
+        return 1;
     }
 
     ASSERT(!supported);
 
+    if ( type == MSR_TYPE_COUNTER &&
+         (msr_content &
+          ~((1ull << core2_get_bitwidth_fix_count()) - 1)) )
+        /* Writing unsupported bits to a fixed counter */
+        return 1;
+
     core2_vpmu_cxt = vpmu->context;
     enabled_cntrs = vpmu->priv_context;
     switch ( msr )
     {
     case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
         core2_vpmu_cxt->global_status &= ~msr_content;
-        return 1;
+        return 0;
     case MSR_CORE_PERF_GLOBAL_STATUS:
         gdprintk(XENLOG_INFO, "Can not write readonly MSR: "
                  "MSR_PERF_GLOBAL_STATUS(0x38E)!\n");
-        hvm_inject_hw_exception(TRAP_gp_fault, 0);
         return 1;
     case MSR_IA32_PEBS_ENABLE:
         if ( msr_content & 1 )
             gdprintk(XENLOG_WARNING, "Guest is trying to enable PEBS, "
                      "which is not supported.\n");
         core2_vpmu_cxt->pebs_enable = msr_content;
-        return 1;
+        return 0;
     case MSR_IA32_DS_AREA:
         if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
         {
@@ -501,18 +506,21 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
                 gdprintk(XENLOG_WARNING,
                          "Illegal address for IA32_DS_AREA: %#" PRIx64 "x\n",
                          msr_content);
-                hvm_inject_hw_exception(TRAP_gp_fault, 0);
                 return 1;
             }
             core2_vpmu_cxt->ds_area = msr_content;
             break;
         }
         gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
-        return 1;
+        return 0;
     case MSR_CORE_PERF_GLOBAL_CTRL:
         global_ctrl = msr_content;
         break;
     case MSR_CORE_PERF_FIXED_CTR_CTRL:
+        if ( msr_content &
+             ( ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1)) )
+            return 1;
+
         vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
         *enabled_cntrs &= ~(((1ULL << fixed_pmc_cnt) - 1) << 32);
         if ( msr_content != 0 )
@@ -535,6 +543,9 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
             struct xen_pmu_cntr_pair *xen_pmu_cntr_pair =
                 vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
 
+            if ( msr_content & (~((1ull << 32) - 1)) )
+                return 1;
+
             vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
 
             if ( msr_content & (1ULL << 22) )
@@ -546,45 +557,17 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         }
     }
 
+    if ( type != MSR_TYPE_GLOBAL )
+        wrmsrl(msr, msr_content);
+    else
+        vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+
     if ( (global_ctrl & *enabled_cntrs) || (core2_vpmu_cxt->ds_area != 0) )
         vpmu_set(vpmu, VPMU_RUNNING);
     else
         vpmu_reset(vpmu, VPMU_RUNNING);
 
-    if ( type != MSR_TYPE_GLOBAL )
-    {
-        u64 mask;
-        int inject_gp = 0;
-        switch ( type )
-        {
-        case MSR_TYPE_ARCH_CTRL:      /* MSR_P6_EVNTSEL[0,...] */
-            mask = ~((1ull << 32) - 1);
-            if (msr_content & mask)
-                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 << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1);
-            if (msr_content & mask)
-                inject_gp = 1;
-            break;
-        case MSR_TYPE_COUNTER:        /* IA32_FIXED_CTR[0-2] */
-            mask = ~((1ull << core2_get_bitwidth_fix_count()) - 1);
-            if (msr_content & mask)
-                inject_gp = 1;
-            break;
-        }
-        if (inject_gp)
-            hvm_inject_hw_exception(TRAP_gp_fault, 0);
-        else
-            wrmsrl(msr, msr_content);
-    }
-    else
-        vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
-
-    return 1;
+    return 0;
 }
 
 static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
@@ -612,19 +595,14 @@ static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
             rdmsrl(msr, *msr_content);
         }
     }
-    else
+    else if ( msr == MSR_IA32_MISC_ENABLE )
     {
         /* 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;
+        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
+            *msr_content &= ~MSR_IA32_MISC_ENABLE_BTS_UNAVAIL;
     }
 
-    return 1;
+    return 0;
 }
 
 static void core2_vpmu_do_cpuid(unsigned int input,
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94h-0000zx-NV; Sun, 16 Nov 2014 23:17:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94f-0000wh-KU
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	57/A2-09842-49039645; Sun, 16 Nov 2014 23:17:40 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416179858!13124246!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10877 invoked from network); 16 Nov 2014 23:17:39 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHWtu007755
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:33 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHWqF007664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 16 Nov 2014 23:17:32 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAGNHUZb016668; Sun, 16 Nov 2014 23:17:31 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:30 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:47 -0500
Message-Id: <1416179271-1221-18-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 17/21] x86/VPMU: Handle PMU interrupts 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>
MIME-Version: 1.0
Content-Type: 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 support for handling PMU interrupts for PV guests.

VPMU for the interrupted VCPU is unloaded until the guest issues XENPMU_flush
hypercall. This allows the guest to access PMU MSR values that are stored in
VPMU context which is shared between hypervisor and domain, thus avoiding
traps to hypervisor.

Since the interrupt handler may now force VPMU context save (i.e. set
VPMU_CONTEXT_SAVE flag) we need to make changes to amd_vpmu_save() which
until now expected this flag to be set only when the counters were stopped.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       |  11 +--
 xen/arch/x86/hvm/vpmu.c           | 203 +++++++++++++++++++++++++++++++++++---
 xen/include/public/arch-x86/pmu.h |   5 +
 xen/include/public/pmu.h          |   2 +
 xen/include/xsm/dummy.h           |   4 +-
 xen/xsm/flask/hooks.c             |   2 +
 6 files changed, 207 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index b54a51d..7d9ba8c 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -228,17 +228,12 @@ static int amd_vpmu_save(struct vcpu *v)
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     unsigned int i;
 
-    /*
-     * Stop the counters. If we came here via vpmu_save_force (i.e.
-     * when VPMU_CONTEXT_SAVE is set) counters are already stopped.
-     */
+    for ( i = 0; i < num_counters; i++ )
+        wrmsrl(ctrls[i], 0);
+
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_SAVE) )
     {
         vpmu_set(vpmu, VPMU_FROZEN);
-
-        for ( i = 0; i < num_counters; i++ )
-            wrmsrl(ctrls[i], 0);
-
         return 0;
     }
 
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 2ad9832..6a71d53 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -80,46 +80,203 @@ static void __init parse_vpmu_param(char *s)
 
 void vpmu_lvtpc_update(uint32_t val)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+    struct vcpu *curr = current;
+    struct vpmu_struct *vpmu = vcpu_vpmu(curr);
 
     vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
-    apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
+
+    /* Postpone APIC updates for PV(H) guests if PMU interrupt is pending */
+    if ( is_hvm_vcpu(curr) || !vpmu->xenpmu_data ||
+         !(vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
+        apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
 
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+    struct vcpu *curr = current;
+    struct vpmu_struct *vpmu = vcpu_vpmu(curr);
 
     if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
         return 0;
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
-        return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
+    {
+        int ret = vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
+
+        /*
+         * We may have received a PMU interrupt during WRMSR handling
+         * and since do_wrmsr may load VPMU context we should save
+         * (and unload) it again.
+         */
+        if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+             (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
+        {
+            vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+            vpmu->arch_vpmu_ops->arch_vpmu_save(curr);
+            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+        }
+        return ret;
+    }
     return 0;
 }
 
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+    struct vcpu *curr = current;
+    struct vpmu_struct *vpmu = vcpu_vpmu(curr);
 
     if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
         return 0;
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
-        return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
+    {
+        int ret = vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
+
+        if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+             (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
+        {
+            vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+            vpmu->arch_vpmu_ops->arch_vpmu_save(curr);
+            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+        }
+        return ret;
+    }
     return 0;
 }
 
+static struct vcpu *choose_hwdom_vcpu(void)
+{
+    unsigned idx = smp_processor_id() % hardware_domain->max_vcpus;
+
+    if ( hardware_domain->vcpu == NULL )
+        return NULL;
+
+    return hardware_domain->vcpu[idx];
+}
+
 void vpmu_do_interrupt(struct cpu_user_regs *regs)
 {
-    struct vcpu *v = current;
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    struct vcpu *sampled = current, *sampling;
+    struct vpmu_struct *vpmu;
+
+    /* dom0 will handle interrupt for special domains (e.g. idle domain) */
+    if ( sampled->domain->domain_id >= DOMID_FIRST_RESERVED )
+    {
+        sampling = choose_hwdom_vcpu();
+        if ( !sampling )
+            return;
+    }
+    else
+        sampling = sampled;
+
+    vpmu = vcpu_vpmu(sampling);
+    if ( !is_hvm_vcpu(sampling) )
+    {
+        /* PV(H) guest */
+        const struct cpu_user_regs *cur_regs;
+        uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
+        uint32_t domid = DOMID_SELF;
+
+        if ( !vpmu->xenpmu_data )
+            return;
+
+        if ( *flags & PMU_CACHED )
+            return;
+
+        if ( is_pvh_vcpu(sampling) &&
+             !vpmu->arch_vpmu_ops->do_interrupt(regs) )
+            return;
+
+        /* PV guest will be reading PMU MSRs from xenpmu_data */
+        vpmu_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+        vpmu->arch_vpmu_ops->arch_vpmu_save(sampling);
+        vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+
+        *flags = 0;
+
+        /* Store appropriate registers in xenpmu_data */
+        /* FIXME: 32-bit PVH should go here as well */
+        if ( is_pv_32bit_vcpu(sampling) )
+        {
+            /*
+             * 32-bit dom0 cannot process Xen's addresses (which are 64 bit)
+             * and therefore we treat it the same way as a non-privileged
+             * PV 32-bit domain.
+             */
+            struct compat_pmu_regs *cmp;
+
+            cur_regs = guest_cpu_user_regs();
+
+            cmp = (void *)&vpmu->xenpmu_data->pmu.r.regs;
+            cmp->ip = cur_regs->rip;
+            cmp->sp = cur_regs->rsp;
+            cmp->flags = cur_regs->eflags;
+            cmp->ss = cur_regs->ss;
+            cmp->cs = cur_regs->cs;
+            if ( (cmp->cs & 3) != 1 )
+                *flags |= PMU_SAMPLE_USER;
+        }
+        else
+        {
+            struct xen_pmu_regs *r = &vpmu->xenpmu_data->pmu.r.regs;
+
+            if ( (vpmu_mode & XENPMU_MODE_SELF) )
+                cur_regs = guest_cpu_user_regs();
+            else if ( !guest_mode(regs) && is_hardware_domain(sampling->domain) )
+            {
+                cur_regs = regs;
+                domid = DOMID_XEN;
+            }
+            else
+                cur_regs = guest_cpu_user_regs();
+
+            r->ip = cur_regs->rip;
+            r->sp = cur_regs->rsp;
+            r->flags = cur_regs->eflags;
+
+            if ( !has_hvm_container_vcpu(sampled) )
+            {
+                r->ss = cur_regs->ss;
+                r->cs = cur_regs->cs;
+                if ( !(sampled->arch.flags & TF_kernel_mode) )
+                    *flags |= PMU_SAMPLE_USER;
+            }
+            else
+            {
+                struct segment_register seg;
+
+                hvm_get_segment_register(sampled, x86_seg_cs, &seg);
+                r->cs = seg.sel;
+                hvm_get_segment_register(sampled, x86_seg_ss, &seg);
+                r->ss = seg.sel;
+                if ( seg.attr.fields.dpl != 0 )
+                    *flags |= PMU_SAMPLE_USER;
+                if ( !(sampled->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) )
+                    *flags |= PMU_SAMPLE_REAL;
+            }
+        }
+
+        vpmu->xenpmu_data->domain_id = domid;
+        vpmu->xenpmu_data->vcpu_id = sampled->vcpu_id;
+        vpmu->xenpmu_data->pcpu_id = smp_processor_id();
+
+        *flags |= PMU_CACHED;
+        vpmu->hw_lapic_lvtpc |= APIC_LVT_MASKED;
+        apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
+
+        send_guest_vcpu_virq(sampling, VIRQ_XENPMU);
+
+        return;
+    }
 
     if ( vpmu->arch_vpmu_ops )
     {
-        struct vlapic *vlapic = vcpu_vlapic(v);
+        struct vlapic *vlapic = vcpu_vlapic(sampling);
         u32 vlapic_lvtpc;
 
+        /* We don't support (yet) HVM dom0 */
+        ASSERT(sampling == sampled);
+
         if ( !vpmu->arch_vpmu_ops->do_interrupt(regs) ||
              !is_vlapic_lvtpc_enabled(vlapic) )
             return;
@@ -132,7 +289,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
             vlapic_set_irq(vlapic, vlapic_lvtpc & APIC_VECTOR_MASK, 0);
             break;
         case APIC_MODE_NMI:
-            v->nmi_pending = 1;
+            sampling->nmi_pending = 1;
             break;
         }
     }
@@ -230,7 +387,9 @@ void vpmu_load(struct vcpu *v)
     local_irq_enable();
 
     /* Only when PMU is counting, we load PMU context immediately. */
-    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) )
+    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) ||
+         (!is_hvm_vcpu(v) &&
+          (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED)) )
         return;
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
@@ -248,6 +407,8 @@ void vpmu_initialise(struct vcpu *v)
 
     BUILD_BUG_ON(sizeof(struct xen_pmu_intel_ctxt) > XENPMU_CTXT_PAD_SZ);
     BUILD_BUG_ON(sizeof(struct xen_pmu_amd_ctxt) > XENPMU_CTXT_PAD_SZ);
+    BUILD_BUG_ON(sizeof(struct xen_pmu_regs) > XENPMU_REGS_PAD_SZ);
+    BUILD_BUG_ON(sizeof(struct compat_pmu_regs) > XENPMU_REGS_PAD_SZ);
 
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         vpmu_destroy(v);
@@ -421,7 +582,9 @@ static int vpmu_force_context_switch(uint64_t old_mode)
 long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 {
     int ret;
+    struct vcpu *curr;
     struct xen_pmu_params pmu_params;
+    struct xen_pmu_data *xenpmu_data;
 
     ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
     if ( ret )
@@ -516,6 +679,24 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
         pvpmu_finish(current->domain, &pmu_params);
         break;
 
+    case XENPMU_lvtpc_set:
+        curr = current;
+        xenpmu_data = curr->arch.vpmu.xenpmu_data;
+        if ( xenpmu_data == NULL )
+            return -EINVAL;
+        vpmu_lvtpc_update(xenpmu_data->pmu.l.lapic_lvtpc);
+        break;
+
+    case XENPMU_flush:
+        curr = current;
+        xenpmu_data = curr->arch.vpmu.xenpmu_data;
+        if ( xenpmu_data == NULL )
+            return -EINVAL;
+        xenpmu_data->pmu.pmu_flags &= ~PMU_CACHED;
+        vpmu_lvtpc_update(xenpmu_data->pmu.l.lapic_lvtpc);
+        vpmu_load(curr);
+        break;
+
     default:
         ret = -EINVAL;
     }
diff --git a/xen/include/public/arch-x86/pmu.h b/xen/include/public/arch-x86/pmu.h
index b0f9100..d795594 100644
--- a/xen/include/public/arch-x86/pmu.h
+++ b/xen/include/public/arch-x86/pmu.h
@@ -50,6 +50,11 @@ struct xen_pmu_regs {
 typedef struct xen_pmu_regs xen_pmu_regs_t;
 DEFINE_XEN_GUEST_HANDLE(xen_pmu_regs_t);
 
+/* PMU flags */
+#define PMU_CACHED         (1<<0) /* PMU MSRs are cached in the context */
+#define PMU_SAMPLE_USER    (1<<1) /* Sample is from user or kernel mode */
+#define PMU_SAMPLE_REAL    (1<<2) /* Sample is from realmode */
+
 struct xen_pmu_arch {
     union {
         struct xen_pmu_regs regs;
diff --git a/xen/include/public/pmu.h b/xen/include/public/pmu.h
index afb4ca1..db5321a 100644
--- a/xen/include/public/pmu.h
+++ b/xen/include/public/pmu.h
@@ -27,6 +27,8 @@
 #define XENPMU_feature_set     3
 #define XENPMU_init            4
 #define XENPMU_finish          5
+#define XENPMU_lvtpc_set       6
+#define XENPMU_flush           7 /* Write cached MSR values to HW     */
 /* ` } */
 
 /* Parameters structure for HYPERVISOR_xenpmu_op call */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index ae47135..1ad4ecc 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -666,7 +666,9 @@ static XSM_INLINE int xsm_pmu_op (XSM_DEFAULT_ARG struct domain *d, int op)
     case XENPMU_feature_get:
         return xsm_default_action(XSM_PRIV, d, current->domain);
     case XENPMU_init:
-    case XENPMU_finish: 
+    case XENPMU_finish:
+    case XENPMU_lvtpc_set:
+    case XENPMU_flush:
         return xsm_default_action(XSM_HOOK, d, current->domain);
     default:
         return -EPERM;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 76f2cf1..bc71b8e 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1517,6 +1517,8 @@ static int flask_pmu_op (struct domain *d, int op)
                             XEN2__PMU_CTRL, NULL);
     case XENPMU_init:
     case XENPMU_finish:
+    case XENPMU_lvtpc_set:
+    case XENPMU_flush:
         return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN2,
                             XEN2__PMU_USE, NULL);
     default:
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94W-0000nq-HZ; Sun, 16 Nov 2014 23:17:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94U-0000mb-3s
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E1/89-24532-98039645; Sun, 16 Nov 2014 23:17:29 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416179846!12807246!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4585 invoked from network); 16 Nov 2014 23:17:28 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHKKc003445
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:21 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHJ2Y007375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:20 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHJLs007363; Sun, 16 Nov 2014 23:17:19 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:18 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:36 -0500
Message-Id: <1416179271-1221-7-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 06/21] vmx: Merge MSR management routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

vmx_add_host_load_msr() and vmx_add_guest_msr() share fair amount of code. Merge
them to simplify code maintenance.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vmx/vmcs.c        | 84 +++++++++++++++++++-------------------
 xen/include/asm-x86/hvm/vmx/vmcs.h | 16 +++++++-
 2 files changed, 55 insertions(+), 45 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 9d8033e..b9e3ef8 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1201,64 +1201,62 @@ int vmx_write_guest_msr(u32 msr, u64 val)
     return -ESRCH;
 }
 
-int vmx_add_guest_msr(u32 msr)
+int vmx_add_msr(u32 msr, int type)
 {
     struct vcpu *curr = current;
-    unsigned int i, msr_count = curr->arch.hvm_vmx.msr_count;
-    struct vmx_msr_entry *msr_area = curr->arch.hvm_vmx.msr_area;
+    unsigned int idx, *msr_count;
+    struct vmx_msr_entry **msr_area, *msr_area_elem;
+
+    if ( type == VMX_GUEST_MSR )
+    {
+        msr_count = &curr->arch.hvm_vmx.msr_count;
+        msr_area = &curr->arch.hvm_vmx.msr_area;
+    }
+    else
+    {
+        ASSERT(type == VMX_HOST_MSR);
+        msr_count = &curr->arch.hvm_vmx.host_msr_count;
+        msr_area = &curr->arch.hvm_vmx.host_msr_area;
+    }
 
-    if ( msr_area == NULL )
+    if ( *msr_area == NULL )
     {
-        if ( (msr_area = alloc_xenheap_page()) == NULL )
+        if ( (*msr_area = alloc_xenheap_page()) == NULL )
             return -ENOMEM;
-        curr->arch.hvm_vmx.msr_area = msr_area;
-        __vmwrite(VM_EXIT_MSR_STORE_ADDR, virt_to_maddr(msr_area));
-        __vmwrite(VM_ENTRY_MSR_LOAD_ADDR, virt_to_maddr(msr_area));
+
+        if ( type == VMX_GUEST_MSR )
+        {
+            __vmwrite(VM_EXIT_MSR_STORE_ADDR, virt_to_maddr(*msr_area));
+            __vmwrite(VM_ENTRY_MSR_LOAD_ADDR, virt_to_maddr(*msr_area));
+        }
+        else
+            __vmwrite(VM_EXIT_MSR_LOAD_ADDR, virt_to_maddr(*msr_area));
     }
 
-    for ( i = 0; i < msr_count; i++ )
-        if ( msr_area[i].index == msr )
+    for ( idx = 0; idx < *msr_count; idx++ )
+        if ( (*msr_area)[idx].index == msr )
             return 0;
 
-    if ( msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
+    if ( *msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
         return -ENOSPC;
 
-    msr_area[msr_count].index = msr;
-    msr_area[msr_count].mbz   = 0;
-    msr_area[msr_count].data  = 0;
-    curr->arch.hvm_vmx.msr_count = ++msr_count;
-    __vmwrite(VM_EXIT_MSR_STORE_COUNT, msr_count);
-    __vmwrite(VM_ENTRY_MSR_LOAD_COUNT, msr_count);
+    msr_area_elem = *msr_area + *msr_count;
+    msr_area_elem->index = msr;
+    msr_area_elem->mbz = 0;
 
-    return 0;
-}
+    ++*msr_count;
 
-int vmx_add_host_load_msr(u32 msr)
-{
-    struct vcpu *curr = current;
-    unsigned int i, msr_count = curr->arch.hvm_vmx.host_msr_count;
-    struct vmx_msr_entry *msr_area = curr->arch.hvm_vmx.host_msr_area;
-
-    if ( msr_area == NULL )
+    if ( type == VMX_GUEST_MSR )
     {
-        if ( (msr_area = alloc_xenheap_page()) == NULL )
-            return -ENOMEM;
-        curr->arch.hvm_vmx.host_msr_area = msr_area;
-        __vmwrite(VM_EXIT_MSR_LOAD_ADDR, virt_to_maddr(msr_area));
+        msr_area_elem->data = 0;
+        __vmwrite(VM_EXIT_MSR_STORE_COUNT, *msr_count);
+        __vmwrite(VM_ENTRY_MSR_LOAD_COUNT, *msr_count);
+    }
+    else
+    {
+        rdmsrl(msr, msr_area_elem->data);
+        __vmwrite(VM_EXIT_MSR_LOAD_COUNT, *msr_count);
     }
-
-    for ( i = 0; i < msr_count; i++ )
-        if ( msr_area[i].index == msr )
-            return 0;
-
-    if ( msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
-        return -ENOSPC;
-
-    msr_area[msr_count].index = msr;
-    msr_area[msr_count].mbz   = 0;
-    rdmsrl(msr, msr_area[msr_count].data);
-    curr->arch.hvm_vmx.host_msr_count = ++msr_count;
-    __vmwrite(VM_EXIT_MSR_LOAD_COUNT, msr_count);
 
     return 0;
 }
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 6a99dca..949884b 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -482,12 +482,15 @@ extern const unsigned int vmx_introspection_force_enabled_msrs_size;
 
 #define MSR_TYPE_R 1
 #define MSR_TYPE_W 2
+
+#define VMX_GUEST_MSR 0
+#define VMX_HOST_MSR  1
+
 void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
 void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
 int vmx_read_guest_msr(u32 msr, u64 *val);
 int vmx_write_guest_msr(u32 msr, u64 val);
-int vmx_add_guest_msr(u32 msr);
-int vmx_add_host_load_msr(u32 msr);
+int vmx_add_msr(u32 msr, int type);
 void vmx_vmcs_switch(struct vmcs_struct *from, struct vmcs_struct *to);
 void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector);
 void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector);
@@ -497,6 +500,15 @@ void virtual_vmcs_exit(void *vvmcs);
 u64 virtual_vmcs_vmread(void *vvmcs, u32 vmcs_encoding);
 void virtual_vmcs_vmwrite(void *vvmcs, u32 vmcs_encoding, u64 val);
 
+static inline int vmx_add_guest_msr(u32 msr)
+{
+    return vmx_add_msr(msr, VMX_GUEST_MSR);
+}
+static inline int vmx_add_host_load_msr(u32 msr)
+{
+    return vmx_add_msr(msr, VMX_HOST_MSR);
+}
+
 DECLARE_PER_CPU(bool_t, vmxon);
 
 #endif /* ASM_X86_HVM_VMX_VMCS_H__ */
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Z-0000qm-Lu; Sun, 16 Nov 2014 23:17:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94Y-0000pB-2d
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:34 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	94/25-19763-D8039645; Sun, 16 Nov 2014 23:17:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416179851!6372086!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26561 invoked from network); 16 Nov 2014 23:17:32 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Nov 2014 23:17:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHPDZ007716
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:26 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHO83016521
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:25 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHOkn007493; Sun, 16 Nov 2014 23:17:24 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:23 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:40 -0500
Message-Id: <1416179271-1221-11-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 10/21] x86/VPMU: Make vpmu not HVM-specific
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

vpmu structure will be used for both HVM and PV guests. Move it from
hvm_vcpu to arch_vcpu.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/include/asm-x86/domain.h   | 2 ++
 xen/include/asm-x86/hvm/vcpu.h | 3 ---
 xen/include/asm-x86/hvm/vpmu.h | 5 ++---
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 6a77a93..be4d1dc 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -426,6 +426,8 @@ struct arch_vcpu
     void (*ctxt_switch_from) (struct vcpu *);
     void (*ctxt_switch_to) (struct vcpu *);
 
+    struct vpmu_struct vpmu;
+
     /* Virtual Machine Extensions */
     union {
         struct pv_vcpu pv_vcpu;
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..71a5b15 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -151,9 +151,6 @@ struct hvm_vcpu {
     u32                 msr_tsc_aux;
     u64                 msr_tsc_adjust;
 
-    /* VPMU */
-    struct vpmu_struct  vpmu;
-
     union {
         struct arch_vmx_struct vmx;
         struct arch_svm_struct svm;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 83eea7e..82bfa0e 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -31,9 +31,8 @@
 #define VPMU_BOOT_ENABLED 0x1    /* vpmu generally enabled. */
 #define VPMU_BOOT_BTS     0x2    /* Intel BTS feature wanted. */
 
-#define vcpu_vpmu(vcpu)   (&((vcpu)->arch.hvm_vcpu.vpmu))
-#define vpmu_vcpu(vpmu)   (container_of((vpmu), struct vcpu, \
-                                          arch.hvm_vcpu.vpmu))
+#define vcpu_vpmu(vcpu)   (&(vcpu)->arch.vpmu)
+#define vpmu_vcpu(vpmu)   container_of((vpmu), struct vcpu, arch.vpmu)
 
 #define MSR_TYPE_COUNTER            0
 #define MSR_TYPE_CTRL               1
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94V-0000my-Bv; Sun, 16 Nov 2014 23:17:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94T-0000mQ-C3
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/89-24532-88039645; Sun, 16 Nov 2014 23:17:28 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416179846!12807247!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4579 invoked from network); 16 Nov 2014 23:17:28 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHJgf003443
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:20 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHHV0016373
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:18 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHHIB012663; Sun, 16 Nov 2014 23:17:17 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:17 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:34 -0500
Message-Id: <1416179271-1221-5-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 04/21] x86/VPMU: Make vpmu macros a bit more
	efficient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 vpmu_are_all_set that allows testing multiple bits at once. Convert macros
into inlines for better compiler checking.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  5 +----
 xen/arch/x86/hvm/vpmu.c           |  3 +--
 xen/include/asm-x86/hvm/vpmu.h    | 25 +++++++++++++++++++++----
 3 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 54e96b6..f2e9735 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -326,10 +326,7 @@ static int core2_vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_SAVE) )
-        return 0;
-
-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) ) 
+    if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
         return 0;
 
     __core2_vpmu_save(v);
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index e74c871..aec7b5f 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -143,8 +143,7 @@ void vpmu_save(struct vcpu *v)
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     int pcpu = smp_processor_id();
 
-    if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) &&
-           vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)) )
+    if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_ALLOCATED | VPMU_CONTEXT_LOADED) )
        return;
 
     vpmu->last_pcpu = pcpu;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 1f28bd8..ddc2748 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -82,10 +82,27 @@ struct vpmu_struct {
 #define VPMU_CPU_HAS_BTS                    0x200 /* Has Branch Trace Store */
 
 
-#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)
+static inline void vpmu_set(struct vpmu_struct *vpmu, const u32 mask)
+{
+    vpmu->flags |= mask;
+}
+static inline void vpmu_reset(struct vpmu_struct *vpmu, const u32 mask)
+{
+    vpmu->flags &= ~mask;
+}
+static inline void vpmu_clear(struct vpmu_struct *vpmu)
+{
+    vpmu->flags = 0;
+}
+static inline bool_t vpmu_is_set(const struct vpmu_struct *vpmu, const u32 mask)
+{
+    return !!(vpmu->flags & mask);
+}
+static inline bool_t vpmu_are_all_set(const struct vpmu_struct *vpmu,
+                                      const u32 mask)
+{
+    return !!((vpmu->flags & mask) == mask);
+}
 
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Q-0000lu-Fc; Sun, 16 Nov 2014 23:17:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94O-0000lb-Tg
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:25 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	4C/EB-02957-48039645; Sun, 16 Nov 2014 23:17:24 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416179842!12878148!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21687 invoked from network); 16 Nov 2014 23:17:23 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHHA0007673
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:17 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHGi2023779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:16 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHFbO007279; Sun, 16 Nov 2014 23:17:15 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:15 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:32 -0500
Message-Id: <1416179271-1221-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 02/21] x86/VPMU: Manage VPMU_CONTEXT_SAVE
	flag in vpmu_save_force()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 a possibility that we set VPMU_CONTEXT_SAVE on VPMU context in
vpmu_load() and never clear it (because vpmu_save_force() will see
VPMU_CONTEXT_LOADED bit clear, which is possible on AMD processors)

The problem is that amd_vpmu_save() assumes that if VPMU_CONTEXT_SAVE is set
then (1) we need to save counters and (2) we don't need to "stop" control
registers since they must have been stopped earlier. The latter may cause all
sorts of problem (like counters still running in a wrong guest and hypervisor
sending to that guest unexpected PMU interrupts).

Since setting this flag is currently always done prior to calling
vpmu_save_force() let's both set and clear it there.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vpmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 265fc0e..e74c871 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -128,6 +128,8 @@ static void vpmu_save_force(void *arg)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         return;
 
+    vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+
     if ( vpmu->arch_vpmu_ops )
         (void)vpmu->arch_vpmu_ops->arch_vpmu_save(v);
 
@@ -176,7 +178,6 @@ void vpmu_load(struct vcpu *v)
          */
         if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         {
-            vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
             on_selected_cpus(cpumask_of(vpmu->last_pcpu),
                              vpmu_save_force, (void *)v, 1);
             vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
@@ -193,7 +194,6 @@ void vpmu_load(struct vcpu *v)
         vpmu = vcpu_vpmu(prev);
 
         /* Someone ran here before us */
-        vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
         vpmu_save_force(prev);
         vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
 
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94j-00013Q-IS; Sun, 16 Nov 2014 23:17:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94h-0000yr-92
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C9/A2-09842-69039645; Sun, 16 Nov 2014 23:17:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416179860!13124250!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10918 invoked from network); 16 Nov 2014 23:17:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:41 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHXEn007762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:34 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHWYh007681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:33 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHW0B012976; Sun, 16 Nov 2014 23:17:32 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:32 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:49 -0500
Message-Id: <1416179271-1221-20-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 19/21] x86/VPMU: Add privileged PMU mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 support for privileged PMU mode (XENPMU_MODE_ALL) which allows privileged
domain (dom0) profile both itself (and the hypervisor) and the guests. While
this mode is on profiling in guests is disabled.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vpmu.c  | 36 ++++++++++++++++++++++++++----------
 xen/arch/x86/traps.c     | 12 ++++++++++++
 xen/include/public/pmu.h |  3 +++
 3 files changed, 41 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index aa4a5d9..5f0a871 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -99,7 +99,9 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
     struct arch_vpmu_ops *ops;
     int ret = 0;
 
-    if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+    if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+         ((vpmu_mode & XENPMU_MODE_ALL) &&
+          !is_hardware_domain(current->domain)) )
         return 0;
 
     curr = current;
@@ -144,8 +146,12 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
     struct vcpu *sampled = current, *sampling;
     struct vpmu_struct *vpmu;
 
-    /* dom0 will handle interrupt for special domains (e.g. idle domain) */
-    if ( sampled->domain->domain_id >= DOMID_FIRST_RESERVED )
+    /*
+     * dom0 will handle interrupt for special domains (e.g. idle domain) or,
+     * in XENPMU_MODE_ALL, for everyone.
+     */
+    if ( (vpmu_mode & XENPMU_MODE_ALL) ||
+         (sampled->domain->domain_id >= DOMID_FIRST_RESERVED) )
     {
         sampling = choose_hwdom_vcpu();
         if ( !sampling )
@@ -155,12 +161,12 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
         sampling = sampled;
 
     vpmu = vcpu_vpmu(sampling);
-    if ( !is_hvm_vcpu(sampling) )
+    if ( !is_hvm_vcpu(sampling) || (vpmu_mode & XENPMU_MODE_ALL) )
     {
         /* PV(H) guest */
         const struct cpu_user_regs *cur_regs;
         uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
-        uint32_t domid = DOMID_SELF;
+        uint32_t domid;
 
         if ( !vpmu->xenpmu_data )
             return;
@@ -169,6 +175,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
             return;
 
         if ( is_pvh_vcpu(sampling) &&
+             !(vpmu_mode & XENPMU_MODE_ALL) &&
              !vpmu->arch_vpmu_ops->do_interrupt(regs) )
             return;
 
@@ -179,6 +186,11 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 
         *flags = 0;
 
+        if ( sampled == sampling )
+            domid = DOMID_SELF;
+        else
+            domid = sampled->domain->domain_id;
+
         /* Store appropriate registers in xenpmu_data */
         /* FIXME: 32-bit PVH should go here as well */
         if ( is_pv_32bit_vcpu(sampling) )
@@ -207,7 +219,8 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 
             if ( (vpmu_mode & XENPMU_MODE_SELF) )
                 cur_regs = guest_cpu_user_regs();
-            else if ( !guest_mode(regs) && is_hardware_domain(sampling->domain) )
+            else if ( !guest_mode(regs) &&
+                      is_hardware_domain(sampling->domain) )
             {
                 cur_regs = regs;
                 domid = DOMID_XEN;
@@ -442,7 +455,8 @@ static int pvpmu_init(struct domain *d, xen_pmu_params_t *params)
     struct page_info *page;
     uint64_t gfn = params->val;
 
-    if ( vpmu_mode == XENPMU_MODE_OFF )
+    if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+         ((vpmu_mode & XENPMU_MODE_ALL) && !is_hardware_domain(d)) )
         return -EINVAL;
 
     if ( (params->vcpu >= d->max_vcpus) || (d->vcpu == NULL) ||
@@ -585,11 +599,13 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
         if ( copy_from_guest(&pmu_params, arg, 1) )
             return -EFAULT;
 
-        if ( pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+        if ( pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV |
+                                XENPMU_MODE_ALL) )
             return -EINVAL;
 
         /* 32-bit dom0 can only sample itself. */
-        if ( is_pv_32bit_vcpu(current) && (pmu_params.val & XENPMU_MODE_HV) )
+        if ( is_pv_32bit_vcpu(current) &&
+             (pmu_params.val & (XENPMU_MODE_HV | XENPMU_MODE_ALL)) )
             return -EINVAL;
 
         /*
@@ -608,7 +624,7 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
         old_mode = vpmu_mode;
         vpmu_mode = pmu_params.val;
 
-        if ( vpmu_mode == XENPMU_MODE_OFF )
+        if ( (vpmu_mode == XENPMU_MODE_OFF) || (vpmu_mode == XENPMU_MODE_ALL) )
         {
             /*
              * Make sure all (non-dom0) VCPUs have unloaded their VPMUs. This
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 70477b2..663b44f 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2579,6 +2579,10 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
         case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR5:
                 if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
                 {
+                    if ( (vpmu_mode & XENPMU_MODE_ALL) &&
+                         !is_hardware_domain(v->domain) )
+                        break;
+
                     if ( vpmu_do_wrmsr(regs->ecx, msr_content, 0) )
                         goto fail;
                 }
@@ -2702,6 +2706,14 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
         case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR5:
                 if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
                 {
+                    if ( (vpmu_mode & XENPMU_MODE_ALL) &&
+                         !is_hardware_domain(v->domain) )
+                    {
+                        /* Don't leak PMU MSRs to unprivileged domains */
+                        regs->eax = regs->edx = 0;
+                        break;
+                    }
+
                     if ( vpmu_do_rdmsr(regs->ecx, &msr_content) )
                         goto fail;
 
diff --git a/xen/include/public/pmu.h b/xen/include/public/pmu.h
index db5321a..a83ae71 100644
--- a/xen/include/public/pmu.h
+++ b/xen/include/public/pmu.h
@@ -52,10 +52,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_pmu_params_t);
  * - XENPMU_MODE_SELF:  Guests can profile themselves
  * - XENPMU_MODE_HV:    Guests can profile themselves, dom0 profiles
  *                      itself and Xen
+ * - XENPMU_MODE_ALL:   Only dom0 has access to VPMU and it profiles
+ *                      everyone: itself, the hypervisor and the guests.
  */
 #define XENPMU_MODE_OFF           0
 #define XENPMU_MODE_SELF          (1<<0)
 #define XENPMU_MODE_HV            (1<<1)
+#define XENPMU_MODE_ALL           (1<<2)
 
 /*
  * PMU features:
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Y-0000pa-Ka; Sun, 16 Nov 2014 23:17:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94X-0000nu-0i
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:33 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	70/F0-03145-C8039645; Sun, 16 Nov 2014 23:17:32 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416179848!12878157!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22268 invoked from network); 16 Nov 2014 23:17:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHMtQ003453
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:22 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHLf1016449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:21 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHLSY023928; Sun, 16 Nov 2014 23:17:21 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:20 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:38 -0500
Message-Id: <1416179271-1221-9-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 08/21] intel/VPMU: MSR_CORE_PERF_GLOBAL_CTRL
	should be initialized 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MSR_CORE_PERF_GLOBAL_CTRL register should be set zero initially. It is up to
the guest to set it so that counters are enabled.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index f44847f..e7fffcf 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -165,14 +165,6 @@ static int core2_get_fixed_pmc_count(void)
     return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
 }
 
-static u64 core2_calc_intial_glb_ctrl_msr(void)
-{
-    int arch_pmc_bits = (1 << arch_pmc_cnt) - 1;
-    u64 fix_pmc_bits  = (1 << fixed_pmc_cnt) - 1;
-
-    return (fix_pmc_bits << 32) | arch_pmc_bits;
-}
-
 /* edx bits 5-12: Bit width of fixed-function performance counters  */
 static int core2_get_bitwidth_fix_count(void)
 {
@@ -373,8 +365,7 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
 
     if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
         goto out_err;
-    vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
-                 core2_calc_intial_glb_ctrl_msr());
+    vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
 
     core2_vpmu_cxt = xzalloc_bytes(sizeof(struct core2_vpmu_context) +
                     (arch_pmc_cnt-1)*sizeof(struct arch_msr_pair));
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94c-0000tf-HQ; Sun, 16 Nov 2014 23:17:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94a-0000r9-Ft
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/AB-09936-F8039645; Sun, 16 Nov 2014 23:17:35 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416179852!5851236!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18622 invoked from network); 16 Nov 2014 23:17:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHPp7003464
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:26 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHPIX012814
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:25 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHOGh012810; Sun, 16 Nov 2014 23:17:24 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:24 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:41 -0500
Message-Id: <1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting PMU
	mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF:  PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
  can profile itself and the hypervisor.

Note that PMU modes are different from what can be provided at Xen's boot line
with 'vpmu' argument. An 'off' (or '0') value is equivalent to XENPMU_MODE_OFF.
Any other value, on the other hand, will cause VPMU mode to be set to
XENPMU_MODE_SELF during boot.

For feature flags only Intel's BTS is currently supported.

Mode and flags are set via HYPERVISOR_xenpmu_op hypercall.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 tools/flask/policy/policy/modules/xen/xen.te |   3 +
 xen/arch/x86/domain.c                        |   6 +-
 xen/arch/x86/hvm/svm/vpmu.c                  |   4 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c            |  10 +-
 xen/arch/x86/hvm/vpmu.c                      | 164 +++++++++++++++++++++++++--
 xen/arch/x86/x86_64/compat/entry.S           |   4 +
 xen/arch/x86/x86_64/entry.S                  |   4 +
 xen/include/asm-x86/hvm/vpmu.h               |  27 +++--
 xen/include/public/pmu.h                     |  45 ++++++++
 xen/include/public/xen.h                     |   1 +
 xen/include/xen/hypercall.h                  |   4 +
 xen/include/xlat.lst                         |   1 +
 xen/include/xsm/dummy.h                      |  15 +++
 xen/include/xsm/xsm.h                        |   6 +
 xen/xsm/dummy.c                              |   1 +
 xen/xsm/flask/hooks.c                        |  18 +++
 xen/xsm/flask/policy/access_vectors          |   2 +
 17 files changed, 288 insertions(+), 27 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index d214470..ae7bf3c 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -68,6 +68,9 @@ allow dom0_t xen_t:xen2 {
     resource_op
     psr_cmt_op
 };
+allow dom0_t xen_t:xen2 {
+    pmu_ctrl
+};
 allow dom0_t xen_t:mmu memorymap;
 
 # Allow dom0 to use these domctls on itself. For domctls acting on other
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..da5bdf4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1544,7 +1544,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
     if ( is_hvm_vcpu(prev) )
     {
         if (prev != next)
-            vpmu_save(prev);
+            vpmu_switch_from(prev, next);
 
         if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
             pt_save_timer(prev);
@@ -1587,9 +1587,9 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
                            !is_hardware_domain(next->domain));
     }
 
-    if (is_hvm_vcpu(next) && (prev != next) )
+    if ( is_hvm_vcpu(prev) && (prev != next) )
         /* Must be done with interrupts enabled */
-        vpmu_load(next);
+        vpmu_switch_to(prev, next);
 
     context_saved(prev);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 0d30b37..61d56d5 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -478,14 +478,14 @@ struct arch_vpmu_ops amd_vpmu_ops = {
     .arch_vpmu_dump = amd_vpmu_dump
 };
 
-int svm_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int svm_vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t family = current_cpu_data.x86;
     int ret = 0;
 
     /* vpmu enabled? */
-    if ( !vpmu_flags )
+    if ( vpmu_mode == XENPMU_MODE_OFF )
         return 0;
 
     switch ( family )
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index a6cca38..23e4899 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -708,13 +708,13 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
     return 1;
 }
 
-static int core2_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+static int core2_vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     u64 msr_content;
     static bool_t ds_warned;
 
-    if ( !(vpmu_flags & VPMU_BOOT_BTS) )
+    if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
         goto func_out;
     /* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
     while ( boot_cpu_has(X86_FEATURE_DS) )
@@ -829,7 +829,7 @@ struct arch_vpmu_ops core2_no_vpmu_ops = {
     .do_cpuid = core2_no_vpmu_do_cpuid,
 };
 
-int vmx_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int vmx_vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t family = current_cpu_data.x86;
@@ -837,7 +837,7 @@ int vmx_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
     int ret = 0;
 
     vpmu->arch_vpmu_ops = &core2_no_vpmu_ops;
-    if ( !vpmu_flags )
+    if ( vpmu_mode == XENPMU_MODE_OFF )
         return 0;
 
     if ( family == 6 )
@@ -880,7 +880,7 @@ int vmx_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
         /* future: */
         case 0x3d:
         case 0x4e:
-            ret = core2_vpmu_initialise(v, vpmu_flags);
+            ret = core2_vpmu_initialise(v);
             if ( !ret )
                 vpmu->arch_vpmu_ops = &core2_vpmu_ops;
             return ret;
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index f96b530..6d9e6f9 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -21,6 +21,8 @@
 #include <xen/config.h>
 #include <xen/sched.h>
 #include <xen/xenoprof.h>
+#include <xen/event.h>
+#include <xen/guest_access.h>
 #include <asm/regs.h>
 #include <asm/types.h>
 #include <asm/msr.h>
@@ -32,8 +34,10 @@
 #include <asm/hvm/svm/vmcb.h>
 #include <asm/apic.h>
 #include <public/pmu.h>
+#include <xsm/xsm.h>
 
 #include <compat/pmu.h>
+CHECK_pmu_params;
 CHECK_pmu_intel_ctxt;
 CHECK_pmu_amd_ctxt;
 CHECK_pmu_cntr_pair;
@@ -44,7 +48,8 @@ CHECK_pmu_regs;
  * "vpmu=off" : vpmu generally disabled
  * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
  */
-static unsigned int __read_mostly opt_vpmu_enabled;
+unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
+unsigned int __read_mostly vpmu_features = 0;
 static void parse_vpmu_param(char *s);
 custom_param("vpmu", parse_vpmu_param);
 
@@ -58,7 +63,7 @@ static void __init parse_vpmu_param(char *s)
         break;
     default:
         if ( !strcmp(s, "bts") )
-            opt_vpmu_enabled |= VPMU_BOOT_BTS;
+            vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
         else if ( *s )
         {
             printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
@@ -66,7 +71,8 @@ static void __init parse_vpmu_param(char *s)
         }
         /* fall through */
     case 1:
-        opt_vpmu_enabled |= VPMU_BOOT_ENABLED;
+        /* Default VPMU mode */
+        vpmu_mode = XENPMU_MODE_SELF;
         break;
     }
 }
@@ -83,6 +89,9 @@ int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
 
+    if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+        return 0;
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
         return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
     return 0;
@@ -92,6 +101,9 @@ int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
 
+    if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+        return 0;
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
         return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
     return 0;
@@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
     switch ( vendor )
     {
     case X86_VENDOR_AMD:
-        if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-            opt_vpmu_enabled = 0;
+        if ( svm_vpmu_initialise(v) != 0 )
+            vpmu_mode = XENPMU_MODE_OFF;
         break;
 
     case X86_VENDOR_INTEL:
-        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-            opt_vpmu_enabled = 0;
+        if ( vmx_vpmu_initialise(v) != 0 )
+            vpmu_mode = XENPMU_MODE_OFF;
         break;
 
     default:
         printk("VPMU: Initialization failed. "
                "Unknown CPU vendor %d\n", vendor);
-        opt_vpmu_enabled = 0;
+        vpmu_mode = XENPMU_MODE_OFF;
         break;
     }
 }
@@ -278,3 +290,139 @@ void vpmu_dump(struct vcpu *v)
         vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
 }
 
+static s_time_t vpmu_start_ctxt_switch;
+static long vpmu_sched_checkin(void *arg)
+{
+    int cpu = cpumask_next(smp_processor_id(), &cpu_online_map);
+    int ret;
+
+    /* Mode change shouldn't take more than a few (say, 5) seconds. */
+    if ( NOW() > vpmu_start_ctxt_switch + SECONDS(5) )
+    {
+        ret = -EBUSY;
+        goto fail;
+    }
+
+    if ( cpu < nr_cpu_ids )
+    {
+        ret = continue_hypercall_on_cpu(cpu, vpmu_sched_checkin, arg);
+        if ( ret )
+            goto fail;
+    }
+    else
+        vpmu_start_ctxt_switch = 0;
+
+    return 0;
+
+ fail:
+    vpmu_mode = (uint64_t)arg;
+    vpmu_start_ctxt_switch = 0;
+    return ret;
+}
+
+static int vpmu_force_context_switch(uint64_t old_mode)
+{
+    int ret;
+
+    vpmu_start_ctxt_switch = NOW();
+
+    ret = continue_hypercall_on_cpu(cpumask_first(&cpu_online_map),
+                                    vpmu_sched_checkin, (void *)old_mode);
+    if ( ret )
+        vpmu_start_ctxt_switch = 0;
+
+    return ret;
+}
+
+long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
+{
+    int ret;
+    struct xen_pmu_params pmu_params;
+
+    ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
+    if ( ret )
+        return ret;
+
+    switch ( op )
+    {
+    case XENPMU_mode_set:
+    {
+        uint64_t old_mode;
+        static DEFINE_SPINLOCK(xenpmu_mode_lock);
+
+        if ( copy_from_guest(&pmu_params, arg, 1) )
+            return -EFAULT;
+
+        if ( pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+            return -EINVAL;
+
+        /* 32-bit dom0 can only sample itself. */
+        if ( is_pv_32bit_vcpu(current) && (pmu_params.val & XENPMU_MODE_HV) )
+            return -EINVAL;
+
+        /*
+         * Return error if someone else is in the middle of changing mode ---
+         * this is most likely indication of two system administrators
+         * working against each other.
+         */
+        if ( !spin_trylock(&xenpmu_mode_lock) )
+            return -EAGAIN;
+        if ( vpmu_start_ctxt_switch != 0 )
+        {
+            spin_unlock(&xenpmu_mode_lock);
+            return -EAGAIN;
+        }
+
+        old_mode = vpmu_mode;
+        vpmu_mode = pmu_params.val;
+
+        if ( vpmu_mode == XENPMU_MODE_OFF )
+        {
+            /*
+             * Make sure all (non-dom0) VCPUs have unloaded their VPMUs. This
+             * can be achieved by having all physical processors go through
+             * context_switch().
+             */
+            ret = vpmu_force_context_switch(old_mode);
+            if ( ret )
+                vpmu_mode = old_mode;
+        }
+
+        spin_unlock(&xenpmu_mode_lock);
+
+        break;
+    }
+
+    case XENPMU_mode_get:
+        memset(&pmu_params, 0, sizeof(pmu_params));
+        pmu_params.val = vpmu_mode;
+
+        pmu_params.version.maj = XENPMU_VER_MAJ;
+        pmu_params.version.min = XENPMU_VER_MIN;
+
+        if ( copy_to_guest(arg, &pmu_params, 1) )
+            return -EFAULT;
+        break;
+
+    case XENPMU_feature_set:
+        if ( copy_from_guest(&pmu_params, arg, 1) )
+            return -EFAULT;
+
+        if ( pmu_params.val & ~XENPMU_FEATURE_INTEL_BTS )
+            return -EINVAL;
+
+        vpmu_features = pmu_params.val;
+        break;
+
+    case XENPMU_feature_get:
+        pmu_params.val = vpmu_features;
+        if ( copy_field_to_guest(arg, &pmu_params, val) )
+            return -EFAULT;
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+
+    return ret;
+}
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index 5b0af61..7691a79 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -417,6 +417,8 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad do_ni_hypercall           /* reserved for XenClient */
+        .quad do_xenpmu_op              /* 40 */
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -466,6 +468,8 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 0 /* reserved for XenClient   */
+        .byte 2 /* do_xenpmu_op             */  /* 40 */
         .rept __HYPERVISOR_arch_0-(.-compat_hypercall_args_table)
         .byte 0 /* compat_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index b3d6e32..aa842ac 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -772,6 +772,8 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_ni_hypercall       /* reserved for XenClient */
+        .quad do_xenpmu_op          /* 40 */
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -821,6 +823,8 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 0 /* reserved for XenClient */
+        .byte 2 /* do_xenpmu_op         */  /* 40 */
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 82bfa0e..5fc15fb 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -24,13 +24,6 @@
 
 #include <public/pmu.h>
 
-/*
- * Flag bits given as a string on the hypervisor boot parameter 'vpmu'.
- * See arch/x86/hvm/vpmu.c.
- */
-#define VPMU_BOOT_ENABLED 0x1    /* vpmu generally enabled. */
-#define VPMU_BOOT_BTS     0x2    /* Intel BTS feature wanted. */
-
 #define vcpu_vpmu(vcpu)   (&(vcpu)->arch.vpmu)
 #define vpmu_vcpu(vpmu)   container_of((vpmu), struct vcpu, arch.vpmu)
 
@@ -59,8 +52,8 @@ struct arch_vpmu_ops {
     void (*arch_vpmu_dump)(const struct vcpu *);
 };
 
-int vmx_vpmu_initialise(struct vcpu *, unsigned int flags);
-int svm_vpmu_initialise(struct vcpu *, unsigned int flags);
+int vmx_vpmu_initialise(struct vcpu *);
+int svm_vpmu_initialise(struct vcpu *);
 
 struct vpmu_struct {
     u32 flags;
@@ -116,5 +109,21 @@ void vpmu_dump(struct vcpu *v);
 extern int acquire_pmu_ownership(int pmu_ownership);
 extern void release_pmu_ownership(int pmu_ownership);
 
+extern unsigned int vpmu_mode;
+extern unsigned int vpmu_features;
+
+/* Context switch */
+inline void vpmu_switch_from(struct vcpu *prev, struct vcpu *next)
+{
+    if ( vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+        vpmu_save(prev);
+}
+
+inline void vpmu_switch_to(struct vcpu *prev, struct vcpu *next)
+{
+    if ( vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+        vpmu_load(next);
+}
+
 #endif /* __ASM_X86_HVM_VPMU_H_*/
 
diff --git a/xen/include/public/pmu.h b/xen/include/public/pmu.h
index f97106d..66cc494 100644
--- a/xen/include/public/pmu.h
+++ b/xen/include/public/pmu.h
@@ -13,6 +13,51 @@
 #define XENPMU_VER_MAJ    0
 #define XENPMU_VER_MIN    1
 
+/*
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_xenpmu_op(enum xenpmu_op cmd, struct xenpmu_params *args);
+ *
+ * @cmd  == XENPMU_* (PMU operation)
+ * @args == struct xenpmu_params
+ */
+/* ` enum xenpmu_op { */
+#define XENPMU_mode_get        0 /* Also used for getting PMU version */
+#define XENPMU_mode_set        1
+#define XENPMU_feature_get     2
+#define XENPMU_feature_set     3
+/* ` } */
+
+/* Parameters structure for HYPERVISOR_xenpmu_op call */
+struct xen_pmu_params {
+    /* IN/OUT parameters */
+    struct {
+        uint32_t maj;
+        uint32_t min;
+    } version;
+    uint64_t val;
+
+    /* IN parameters */
+    uint32_t vcpu;
+    uint32_t pad;
+};
+typedef struct xen_pmu_params xen_pmu_params_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_params_t);
+
+/* PMU modes:
+ * - XENPMU_MODE_OFF:   No PMU virtualization
+ * - XENPMU_MODE_SELF:  Guests can profile themselves
+ * - XENPMU_MODE_HV:    Guests can profile themselves, dom0 profiles
+ *                      itself and Xen
+ */
+#define XENPMU_MODE_OFF           0
+#define XENPMU_MODE_SELF          (1<<0)
+#define XENPMU_MODE_HV            (1<<1)
+
+/*
+ * PMU features:
+ * - XENPMU_FEATURE_INTEL_BTS: Intel BTS support (ignored on AMD)
+ */
+#define XENPMU_FEATURE_INTEL_BTS  1
 
 /* Shared between hypervisor and PV domain */
 struct xen_pmu_data {
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index a6a2092..0766790 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -101,6 +101,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
 #define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient */
+#define __HYPERVISOR_xenpmu_op            40
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index a9e5229..cf34547 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -14,6 +14,7 @@
 #include <public/event_channel.h>
 #include <public/tmem.h>
 #include <public/version.h>
+#include <public/pmu.h>
 #include <asm/hypercall.h>
 #include <xsm/xsm.h>
 
@@ -139,6 +140,9 @@ do_tmem_op(
 extern long
 do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
+extern long
+do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg);
+
 #ifdef CONFIG_COMPAT
 
 extern int
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 8bff86d..0186573 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -103,6 +103,7 @@
 !	vcpu_set_singleshot_timer	vcpu.h
 ?	xenoprof_init			xenoprof.h
 ?	xenoprof_passive		xenoprof.h
+?	pmu_params			pmu.h
 ?	pmu_intel_ctxt			arch-x86/pmu.h
 ?	pmu_amd_ctxt			arch-x86/pmu.h
 ?	pmu_cntr_pair			arch-x86/pmu.h
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f20e89c..c637454 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -655,4 +655,19 @@ static XSM_INLINE int xsm_ioport_mapping(XSM_DEFAULT_ARG struct domain *d, uint3
     return xsm_default_action(action, current->domain, d);
 }
 
+static XSM_INLINE int xsm_pmu_op (XSM_DEFAULT_ARG struct domain *d, int op)
+{
+    XSM_ASSERT_ACTION(XSM_OTHER);
+    switch ( op )
+    {
+    case XENPMU_mode_set:
+    case XENPMU_mode_get:
+    case XENPMU_feature_set:
+    case XENPMU_feature_get:
+        return xsm_default_action(XSM_PRIV, d, current->domain);
+    default:
+        return -EPERM;
+    }
+}
+
 #endif /* CONFIG_X86 */
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4ce089f..0e39dfe 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -173,6 +173,7 @@ struct xsm_operations {
     int (*unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
     int (*ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
+    int (*pmu_op) (struct domain *d, int op);
 #endif
 };
 
@@ -665,6 +666,11 @@ static inline int xsm_ioport_mapping (xsm_default_t def, struct domain *d, uint3
     return xsm_ops->ioport_mapping(d, s, e, allow);
 }
 
+static inline int xsm_pmu_op (xsm_default_t def, struct domain *d, int op)
+{
+    return xsm_ops->pmu_op(d, op);
+}
+
 #endif /* CONFIG_X86 */
 
 #endif /* XSM_NO_WRAPPERS */
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 8eb3050..94f1cf0 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -144,5 +144,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, unbind_pt_irq);
     set_to_dummy_if_null(ops, ioport_permission);
     set_to_dummy_if_null(ops, ioport_mapping);
+    set_to_dummy_if_null(ops, pmu_op);
 #endif
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index b57b9d3..8e1914e 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1502,6 +1502,23 @@ static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq
 {
     return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
+
+static int flask_pmu_op (struct domain *d, int op)
+{
+    u32 dsid = domain_sid(d);
+
+    switch ( op )
+    {
+    case XENPMU_mode_set:
+    case XENPMU_mode_get:
+    case XENPMU_feature_set:
+    case XENPMU_feature_get:
+        return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN2,
+                            XEN2__PMU_CTRL, NULL);
+    default:
+        return -EPERM;
+    }
+}
 #endif /* CONFIG_X86 */
 
 long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op);
@@ -1624,6 +1641,7 @@ static struct xsm_operations flask_ops = {
     .unbind_pt_irq = flask_unbind_pt_irq,
     .ioport_permission = flask_ioport_permission,
     .ioport_mapping = flask_ioport_mapping,
+    .pmu_op = flask_pmu_op,
 #endif
 };
 
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 69152d6..3289d98 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -85,6 +85,8 @@ class xen2
     psr_cmt_op
 # XENPF_get_symbol
     get_symbol
+# PMU control
+    pmu_ctrl
 }
 
 # Classes domain and domain2 consist of operations that a domain performs on
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94e-0000vY-76; Sun, 16 Nov 2014 23:17:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94c-0000sh-2A
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:38 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	69/BA-17694-19039645; Sun, 16 Nov 2014 23:17:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416179853!11749510!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28600 invoked from network); 16 Nov 2014 23:17:34 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:34 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHR5M007732
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:27 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHQS9016549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:26 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHPcE012835; Sun, 16 Nov 2014 23:17:25 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:25 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:42 -0500
Message-Id: <1416179271-1221-13-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 12/21] x86/VPMU: Initialize VPMUs with
	__initcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 some VPMU initilization operations into __initcalls to avoid performing
same tests and calculations for each vcpu.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       | 115 +++++++++++++---------------
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 154 +++++++++++++++++++-------------------
 xen/arch/x86/hvm/vpmu.c           |  35 +++++++++
 xen/include/asm-x86/hvm/vpmu.h    |   2 +
 4 files changed, 166 insertions(+), 140 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 61d56d5..8460d7b 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -356,57 +356,6 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
     return 1;
 }
 
-static int amd_vpmu_initialise(struct vcpu *v)
-{
-    struct xen_pmu_amd_ctxt *ctxt;
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    uint8_t family = current_cpu_data.x86;
-
-    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
-        return 0;
-
-    if ( counters == NULL )
-    {
-         switch ( family )
-	 {
-	 case 0x15:
-	     num_counters = F15H_NUM_COUNTERS;
-	     counters = AMD_F15H_COUNTERS;
-	     ctrls = AMD_F15H_CTRLS;
-	     k7_counters_mirrored = 1;
-	     break;
-	 case 0x10:
-	 case 0x12:
-	 case 0x14:
-	 case 0x16:
-	 default:
-	     num_counters = F10H_NUM_COUNTERS;
-	     counters = AMD_F10H_COUNTERS;
-	     ctrls = AMD_F10H_CTRLS;
-	     k7_counters_mirrored = 0;
-	     break;
-	 }
-    }
-
-    ctxt = xzalloc_bytes(sizeof(*ctxt) +
-                         2 * sizeof(uint64_t) * num_counters);
-    if ( !ctxt )
-    {
-        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 -ENOMEM;
-    }
-
-    ctxt->counters = sizeof(*ctxt);
-    ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
-
-    vpmu->context = ctxt;
-    vpmu->priv_context = NULL;
-    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
-    return 0;
-}
-
 static void amd_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
@@ -480,30 +429,66 @@ struct arch_vpmu_ops amd_vpmu_ops = {
 
 int svm_vpmu_initialise(struct vcpu *v)
 {
+    struct xen_pmu_amd_ctxt *ctxt;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    uint8_t family = current_cpu_data.x86;
-    int ret = 0;
 
-    /* vpmu enabled? */
-    if ( vpmu_mode == XENPMU_MODE_OFF )
+    if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+         vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return 0;
 
-    switch ( family )
+    if ( !counters )
+        return -EINVAL;
+
+    ctxt = xzalloc_bytes(sizeof(*ctxt) +
+                         2 * sizeof(uint64_t) * num_counters);
+    if ( !ctxt )
+    {
+        printk(XENLOG_G_WARNING "Insufficient memory for PMU, "
+               " PMU feature is unavailable on domain %d vcpu %d.\n",
+               v->vcpu_id, v->domain->domain_id);
+        return -ENOMEM;
+    }
+
+    ctxt->counters = sizeof(*ctxt);
+    ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
+
+    vpmu->context = ctxt;
+    vpmu->priv_context = NULL;
+
+    vpmu->arch_vpmu_ops = &amd_vpmu_ops;
+
+    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
+    return 0;
+}
+
+int __init amd_vpmu_init(void)
+{
+    if ( current_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return -EINVAL;
+
+    switch ( current_cpu_data.x86 )
     {
+    case 0x15:
+        num_counters = F15H_NUM_COUNTERS;
+        counters = AMD_F15H_COUNTERS;
+        ctrls = AMD_F15H_CTRLS;
+        k7_counters_mirrored = 1;
+        break;
     case 0x10:
     case 0x12:
     case 0x14:
-    case 0x15:
     case 0x16:
-        ret = amd_vpmu_initialise(v);
-        if ( !ret )
-            vpmu->arch_vpmu_ops = &amd_vpmu_ops;
-        return ret;
+        num_counters = F10H_NUM_COUNTERS;
+        counters = AMD_F10H_COUNTERS;
+        ctrls = AMD_F10H_CTRLS;
+        k7_counters_mirrored = 0;
+        break;
+    default:
+        printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
+               current_cpu_data.x86);
+        return -EINVAL;
     }
 
-    printk("VPMU: Initialization failed. "
-           "AMD processor family %d has not "
-           "been supported\n", family);
-    return -EINVAL;
+    return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 23e4899..e199367 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -708,62 +708,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
     return 1;
 }
 
-static int core2_vpmu_initialise(struct vcpu *v)
-{
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    u64 msr_content;
-    static bool_t ds_warned;
-
-    if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
-        goto func_out;
-    /* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
-    while ( boot_cpu_has(X86_FEATURE_DS) )
-    {
-        if ( !boot_cpu_has(X86_FEATURE_DTES64) )
-        {
-            if ( !ds_warned )
-                printk(XENLOG_G_WARNING "CPU doesn't support 64-bit DS Area"
-                       " - Debug Store disabled for guests\n");
-            break;
-        }
-        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);
-            if ( !ds_warned )
-                printk(XENLOG_G_WARNING "CPU has set BTS_UNAVAIL"
-                       " - Debug Store disabled for guests\n");
-            break;
-        }
-
-        vpmu_set(vpmu, VPMU_CPU_HAS_BTS);
-        if ( !ds_warned )
-        {
-            if ( !boot_cpu_has(X86_FEATURE_DSCPL) )
-                printk(XENLOG_G_INFO
-                       "vpmu: CPU doesn't support CPL-Qualified BTS\n");
-            printk("******************************************************\n");
-            printk("** WARNING: Emulation of BTS Feature is switched on **\n");
-            printk("** Using this processor feature in a virtualized    **\n");
-            printk("** environment is not 100%% safe.                    **\n");
-            printk("** Setting the DS buffer address with wrong values  **\n");
-            printk("** may lead to hypervisor hangs or crashes.         **\n");
-            printk("** It is NOT recommended for production use!        **\n");
-            printk("******************************************************\n");
-        }
-        break;
-    }
-    ds_warned = 1;
- func_out:
-
-    arch_pmc_cnt = core2_get_arch_pmc_count();
-    fixed_pmc_cnt = core2_get_fixed_pmc_count();
-    check_pmc_quirk();
-    return 0;
-}
-
 static void core2_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
@@ -832,23 +776,80 @@ struct arch_vpmu_ops core2_no_vpmu_ops = {
 int vmx_vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    uint8_t family = current_cpu_data.x86;
-    uint8_t cpu_model = current_cpu_data.x86_model;
-    int ret = 0;
+    u64 msr_content;
+    static bool_t ds_warned;
 
     vpmu->arch_vpmu_ops = &core2_no_vpmu_ops;
     if ( vpmu_mode == XENPMU_MODE_OFF )
         return 0;
 
-    if ( family == 6 )
-    {
-        u64 caps;
+    if ( (arch_pmc_cnt + fixed_pmc_cnt) == 0 )
+        return -EINVAL;
 
-        rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
-        full_width_write = (caps >> 13) & 1;
+    if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
+        goto func_out;
+    /* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
+    while ( boot_cpu_has(X86_FEATURE_DS) )
+    {
+        if ( !boot_cpu_has(X86_FEATURE_DTES64) )
+        {
+            if ( !ds_warned )
+                printk(XENLOG_G_WARNING "CPU doesn't support 64-bit DS Area"
+                       " - Debug Store disabled for guests\n");
+            break;
+        }
+        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);
+            if ( !ds_warned )
+                printk(XENLOG_G_WARNING "CPU has set BTS_UNAVAIL"
+                       " - Debug Store disabled for guests\n");
+            break;
+        }
 
-        switch ( cpu_model )
+        vpmu_set(vpmu, VPMU_CPU_HAS_BTS);
+        if ( !ds_warned )
         {
+            if ( !boot_cpu_has(X86_FEATURE_DSCPL) )
+                printk(XENLOG_G_INFO
+                       "vpmu: CPU doesn't support CPL-Qualified BTS\n");
+            printk("******************************************************\n");
+            printk("** WARNING: Emulation of BTS Feature is switched on **\n");
+            printk("** Using this processor feature in a virtualized    **\n");
+            printk("** environment is not 100%% safe.                    **\n");
+            printk("** Setting the DS buffer address with wrong values  **\n");
+            printk("** may lead to hypervisor hangs or crashes.         **\n");
+            printk("** It is NOT recommended for production use!        **\n");
+            printk("******************************************************\n");
+        }
+        break;
+    }
+    ds_warned = 1;
+ func_out:
+
+    vpmu->arch_vpmu_ops = &core2_vpmu_ops;
+
+    return 0;
+}
+
+int __init core2_vpmu_init(void)
+{
+    u64 caps;
+
+    if ( current_cpu_data.x86_vendor != X86_VENDOR_INTEL )
+        return -EINVAL;
+
+    if ( current_cpu_data.x86 != 6 )
+    {
+        printk(XENLOG_WARNING "VPMU: only family 6 is supported\n");
+        return -EINVAL;
+    }
+
+    switch ( current_cpu_data.x86_model )
+    {
         /* Core2: */
         case 0x0f: /* original 65 nm celeron/pentium/core2/xeon, "Merom"/"Conroe" */
         case 0x16: /* single-core 65 nm celeron/core2solo "Merom-L"/"Conroe-L" */
@@ -880,16 +881,19 @@ int vmx_vpmu_initialise(struct vcpu *v)
         /* future: */
         case 0x3d:
         case 0x4e:
-            ret = core2_vpmu_initialise(v);
-            if ( !ret )
-                vpmu->arch_vpmu_ops = &core2_vpmu_ops;
-            return ret;
-        }
+            break;
+    default:
+        printk(XENLOG_WARNING "VPMU: Unsupported CPU model %#x\n",
+               current_cpu_data.x86_model);
+        return -EINVAL;
     }
 
-    printk("VPMU: Initialization failed. "
-           "Intel processor family %d model %d has not "
-           "been supported\n", family, cpu_model);
-    return -EINVAL;
-}
+    arch_pmc_cnt = core2_get_arch_pmc_count();
+    fixed_pmc_cnt = core2_get_fixed_pmc_count();
+    rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
+    full_width_write = (caps >> 13) & 1;
 
+    check_pmc_quirk();
+
+    return 0;
+}
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 6d9e6f9..ed3b99a 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -426,3 +426,38 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 
     return ret;
 }
+
+static int __init vpmu_init(void)
+{
+    int vendor = current_cpu_data.x86_vendor;
+
+    if ( vpmu_mode == XENPMU_MODE_OFF )
+    {
+        printk(XENLOG_INFO "VPMU: disabled\n");
+        return 0;
+    }
+
+    switch ( vendor )
+    {
+        case X86_VENDOR_AMD:
+            if ( amd_vpmu_init() )
+               vpmu_mode = XENPMU_MODE_OFF;
+            break;
+        case X86_VENDOR_INTEL:
+            if ( core2_vpmu_init() )
+               vpmu_mode = XENPMU_MODE_OFF;
+            break;
+        default:
+            printk(XENLOG_WARNING "VPMU: Unknown CPU vendor: %d\n", vendor);
+            vpmu_mode = XENPMU_MODE_OFF;
+    }
+
+    if ( vpmu_mode == XENPMU_MODE_OFF )
+        printk(XENLOG_WARNING "VPMU: Disabling due to initialization error\n");
+    else
+        printk(XENLOG_INFO "VPMU: version %d.%d\n",
+               XENPMU_VER_MAJ, XENPMU_VER_MIN);
+
+    return 0;
+}
+__initcall(vpmu_init);
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 5fc15fb..97fe17c 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -52,7 +52,9 @@ struct arch_vpmu_ops {
     void (*arch_vpmu_dump)(const struct vcpu *);
 };
 
+int core2_vpmu_init(void);
 int vmx_vpmu_initialise(struct vcpu *);
+int amd_vpmu_init(void);
 int svm_vpmu_initialise(struct vcpu *);
 
 struct vpmu_struct {
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94i-00010b-7h; Sun, 16 Nov 2014 23:17:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94g-0000xo-6J
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:42 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	15/52-03148-59039645; Sun, 16 Nov 2014 23:17:41 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416179859!12903943!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21375 invoked from network); 16 Nov 2014 23:17:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:40 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHWdT007753
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:32 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHVHD024215
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 16 Nov 2014 23:17:31 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAGNHTqV016631; Sun, 16 Nov 2014 23:17:30 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:29 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:46 -0500
Message-Id: <1416179271-1221-17-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 16/21] x86/VPMU: Add support for PMU
	register handling on 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Intercept accesses to PMU MSRs and process them in VPMU module.

Dump VPMU state for all domains (HVM and PV) when requested.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/domain.c             |  3 +--
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 49 ++++++++++++++++++++++++++++++++------
 xen/arch/x86/traps.c              | 50 ++++++++++++++++++++++++++++++++++++++-
 3 files changed, 92 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0de8a20..37c6371 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2075,8 +2075,7 @@ void arch_dump_vcpu_info(struct vcpu *v)
 {
     paging_dump_vcpu_info(v);
 
-    if ( is_hvm_vcpu(v) )
-        vpmu_dump(v);
+    vpmu_dump(v);
 }
 
 void domain_cpuid(
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 2dd8000..839dce0 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -27,6 +27,7 @@
 #include <asm/regs.h>
 #include <asm/types.h>
 #include <asm/apic.h>
+#include <asm/traps.h>
 #include <asm/msr.h>
 #include <asm/msr-index.h>
 #include <asm/hvm/support.h>
@@ -299,12 +300,18 @@ static inline void __core2_vpmu_save(struct vcpu *v)
         rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, fixed_counters[i]);
     for ( i = 0; i < arch_pmc_cnt; i++ )
         rdmsrl(MSR_IA32_PERFCTR0 + i, xen_pmu_cntr_pair[i].counter);
+
+    if ( !has_hvm_container_vcpu(v) )
+        rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
 static int core2_vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
+    if ( !has_hvm_container_vcpu(v) )
+        wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+
     if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
         return 0;
 
@@ -342,6 +349,13 @@ static inline void __core2_vpmu_load(struct vcpu *v)
     wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
     wrmsrl(MSR_IA32_DS_AREA, core2_vpmu_cxt->ds_area);
     wrmsrl(MSR_IA32_PEBS_ENABLE, core2_vpmu_cxt->pebs_enable);
+
+    if ( !has_hvm_container_vcpu(v) )
+    {
+        wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, core2_vpmu_cxt->global_ovf_ctrl);
+        core2_vpmu_cxt->global_ovf_ctrl = 0;
+        wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
+    }
 }
 
 static void core2_vpmu_load(struct vcpu *v)
@@ -442,7 +456,6 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
 static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
                                uint64_t supported)
 {
-    u64 global_ctrl;
     int i, tmp;
     int type = -1, index = -1;
     struct vcpu *v = current;
@@ -486,7 +499,12 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     switch ( msr )
     {
     case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+        if ( msr_content & ~(0xC000000000000000 |
+                             (((1ULL << fixed_pmc_cnt) - 1) << 32) |
+                             ((1ULL << arch_pmc_cnt) - 1)) )
+            return 1;
         core2_vpmu_cxt->global_status &= ~msr_content;
+        wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
         return 0;
     case MSR_CORE_PERF_GLOBAL_STATUS:
         gdprintk(XENLOG_INFO, "Can not write readonly MSR: "
@@ -514,14 +532,18 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
         return 0;
     case MSR_CORE_PERF_GLOBAL_CTRL:
-        global_ctrl = msr_content;
+        core2_vpmu_cxt->global_ctrl = msr_content;
         break;
     case MSR_CORE_PERF_FIXED_CTR_CTRL:
         if ( msr_content &
              ( ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1)) )
             return 1;
 
-        vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+        if ( has_hvm_container_vcpu(v) )
+            vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
+                               &core2_vpmu_cxt->global_ctrl);
+        else
+            rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
         *enabled_cntrs &= ~(((1ULL << fixed_pmc_cnt) - 1) << 32);
         if ( msr_content != 0 )
         {
@@ -546,7 +568,11 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
             if ( msr_content & (~((1ull << 32) - 1)) )
                 return 1;
 
-            vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+            if ( has_hvm_container_vcpu(v) )
+                vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
+                                   &core2_vpmu_cxt->global_ctrl);
+            else
+                rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
 
             if ( msr_content & (1ULL << 22) )
                 *enabled_cntrs |= 1ULL << tmp;
@@ -560,9 +586,15 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     if ( type != MSR_TYPE_GLOBAL )
         wrmsrl(msr, msr_content);
     else
-        vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+    {
+        if ( has_hvm_container_vcpu(v) )
+            vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+        else
+            wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+    }
 
-    if ( (global_ctrl & *enabled_cntrs) || (core2_vpmu_cxt->ds_area != 0) )
+    if ( (core2_vpmu_cxt->global_ctrl & *enabled_cntrs) ||
+         (core2_vpmu_cxt->ds_area != 0) )
         vpmu_set(vpmu, VPMU_RUNNING);
     else
         vpmu_reset(vpmu, VPMU_RUNNING);
@@ -589,7 +621,10 @@ static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
             *msr_content = core2_vpmu_cxt->global_status;
             break;
         case MSR_CORE_PERF_GLOBAL_CTRL:
-            vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+            if ( has_hvm_container_vcpu(v) )
+                vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+            else
+                rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, *msr_content);
             break;
         default:
             rdmsrl(msr, *msr_content);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 10fc2ca..70477b2 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -72,6 +72,7 @@
 #include <asm/apic.h>
 #include <asm/mc146818rtc.h>
 #include <asm/hpet.h>
+#include <asm/hvm/vpmu.h>
 #include <public/arch-x86/cpuid.h>
 #include <xsm/xsm.h>
 
@@ -896,8 +897,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
         __clear_bit(X86_FEATURE_TOPOEXT % 32, &c);
         break;
 
+    case 0x0000000a: /* Architectural Performance Monitor Features (Intel) */
+        break;
+
     case 0x00000005: /* MONITOR/MWAIT */
-    case 0x0000000a: /* Architectural Performance Monitor Features */
     case 0x0000000b: /* Extended Topology Enumeration */
     case 0x8000000a: /* SVM revision and features */
     case 0x8000001b: /* Instruction Based Sampling */
@@ -913,6 +916,9 @@ void pv_cpuid(struct cpu_user_regs *regs)
     }
 
  out:
+    /* VPMU may decide to modify some of the leaves */
+    vpmu_do_cpuid(regs->eax, &a, &b, &c, &d);
+
     regs->eax = a;
     regs->ebx = b;
     regs->ecx = c;
@@ -1935,6 +1941,7 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
     char io_emul_stub[32];
     void (*io_emul)(struct cpu_user_regs *) __attribute__((__regparm__(1)));
     uint64_t val, msr_content;
+    bool_t vpmu_msr;
 
     if ( !read_descriptor(regs->cs, v, regs,
                           &code_base, &code_limit, &ar,
@@ -2425,6 +2432,7 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
         uint32_t eax = regs->eax;
         uint32_t edx = regs->edx;
         msr_content = ((uint64_t)edx << 32) | eax;
+        vpmu_msr = 0;
         switch ( (u32)regs->ecx )
         {
         case MSR_FS_BASE:
@@ -2561,6 +2569,22 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
             if ( v->arch.debugreg[7] & DR7_ACTIVE_MASK )
                 wrmsrl(regs->_ecx, msr_content);
             break;
+        case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+        case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
+        case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+        case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+            if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+            {
+                vpmu_msr = 1;
+        case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR5:
+                if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+                {
+                    if ( vpmu_do_wrmsr(regs->ecx, msr_content, 0) )
+                        goto fail;
+                }
+                break;
+            }
+            /*FALLTHROUGH*/
 
         default:
             if ( wrmsr_hypervisor_regs(regs->ecx, msr_content) == 1 )
@@ -2593,6 +2617,7 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
         break;
 
     case 0x32: /* RDMSR */
+        vpmu_msr = 0;
         switch ( (u32)regs->ecx )
         {
         case MSR_FS_BASE:
@@ -2663,6 +2688,29 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
                             [regs->_ecx - MSR_AMD64_DR1_ADDRESS_MASK + 1];
             regs->edx = 0;
             break;
+        case MSR_IA32_PERF_CAPABILITIES:
+            /* No extra capabilities are supported */
+            regs->eax = regs->edx = 0;
+            break;
+        case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+        case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
+        case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+        case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+            if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+            {
+                vpmu_msr = 1;
+        case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR5:
+                if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+                {
+                    if ( vpmu_do_rdmsr(regs->ecx, &msr_content) )
+                        goto fail;
+
+                    regs->eax = (uint32_t)msr_content;
+                    regs->edx = (uint32_t)(msr_content >> 32);
+                }
+                break;
+            }
+            /*FALLTHROUGH*/
 
         default:
             if ( rdmsr_hypervisor_regs(regs->ecx, &val) )
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94k-00015y-Tz; Sun, 16 Nov 2014 23:17:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94i-00010R-Hr
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:44 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	C9/AB-22819-79039645; Sun, 16 Nov 2014 23:17:43 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416179861!6372093!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26654 invoked from network); 16 Nov 2014 23:17:42 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Nov 2014 23:17:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHZlh007783
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:36 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHY4K016738
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:35 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHYbs013025; Sun, 16 Nov 2014 23:17:34 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:34 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:51 -0500
Message-Id: <1416179271-1221-22-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 21/21] x86/VPMU: Move VPMU files up from
	hvm/ directory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since PMU is now not HVM specific we can move VPMU-related files up from
arch/x86/hvm/ directory.

Specifically:
    arch/x86/hvm/vpmu.c -> arch/x86/cpu/vpmu.c
    arch/x86/hvm/svm/vpmu.c -> arch/x86/cpu/vpmu_amd.c
    arch/x86/hvm/vmx/vpmu_core2.c -> arch/x86/cpu/vpmu_intel.c
    include/asm-x86/hvm/vpmu.h -> include/asm-x86/vpmu.h

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/cpu/Makefile                               | 1 +
 xen/arch/x86/{hvm => cpu}/vpmu.c                        | 2 +-
 xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c}         | 2 +-
 xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 2 +-
 xen/arch/x86/hvm/Makefile                               | 1 -
 xen/arch/x86/hvm/svm/Makefile                           | 1 -
 xen/arch/x86/hvm/vlapic.c                               | 2 +-
 xen/arch/x86/hvm/vmx/Makefile                           | 1 -
 xen/arch/x86/oprofile/op_model_ppro.c                   | 2 +-
 xen/arch/x86/traps.c                                    | 2 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h                      | 2 +-
 xen/include/asm-x86/{hvm => }/vpmu.h                    | 0
 12 files changed, 8 insertions(+), 10 deletions(-)
 rename xen/arch/x86/{hvm => cpu}/vpmu.c (99%)
 rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (99%)
 rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (99%)
 rename xen/include/asm-x86/{hvm => }/vpmu.h (100%)

diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index d73d93a..74f23ae 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -7,3 +7,4 @@ obj-y += common.o
 obj-y += intel.o
 obj-y += intel_cacheinfo.o
 obj-y += mwait-idle.o
+obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/cpu/vpmu.c
similarity index 99%
rename from xen/arch/x86/hvm/vpmu.c
rename to xen/arch/x86/cpu/vpmu.c
index cf96da7..a52604a 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -27,10 +27,10 @@
 #include <asm/types.h>
 #include <asm/msr.h>
 #include <asm/p2m.h>
+#include <asm/vpmu.h>
 #include <asm/hvm/support.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/vmx/vmcs.h>
-#include <asm/hvm/vpmu.h>
 #include <asm/hvm/svm/svm.h>
 #include <asm/hvm/svm/vmcb.h>
 #include <asm/apic.h>
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/cpu/vpmu_amd.c
similarity index 99%
rename from xen/arch/x86/hvm/svm/vpmu.c
rename to xen/arch/x86/cpu/vpmu_amd.c
index c21bde0..bb9da12 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -28,8 +28,8 @@
 #include <xen/sched.h>
 #include <xen/irq.h>
 #include <asm/apic.h>
+#include <asm/vpmu.h>
 #include <asm/hvm/vlapic.h>
-#include <asm/hvm/vpmu.h>
 #include <public/pmu.h>
 
 #define MSR_F10H_EVNTSEL_GO_SHIFT   40
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/cpu/vpmu_intel.c
similarity index 99%
rename from xen/arch/x86/hvm/vmx/vpmu_core2.c
rename to xen/arch/x86/cpu/vpmu_intel.c
index 271fae5..e5f22a7 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -30,6 +30,7 @@
 #include <asm/traps.h>
 #include <asm/msr.h>
 #include <asm/msr-index.h>
+#include <asm/vpmu.h>
 #include <asm/hvm/support.h>
 #include <asm/hvm/vlapic.h>
 #include <asm/hvm/vmx/vmx.h>
@@ -37,7 +38,6 @@
 #include <public/sched.h>
 #include <public/hvm/save.h>
 #include <public/pmu.h>
-#include <asm/hvm/vpmu.h>
 
 /*
  * See Intel SDM Vol 2a Instruction Set Reference chapter 3 for CPUID
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index eea5555..742b83b 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -22,4 +22,3 @@ obj-y += vlapic.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
-obj-y += vpmu.o
\ No newline at end of file
diff --git a/xen/arch/x86/hvm/svm/Makefile b/xen/arch/x86/hvm/svm/Makefile
index a10a55e..760d295 100644
--- a/xen/arch/x86/hvm/svm/Makefile
+++ b/xen/arch/x86/hvm/svm/Makefile
@@ -6,4 +6,3 @@ obj-y += nestedsvm.o
 obj-y += svm.o
 obj-y += svmdebug.o
 obj-y += vmcb.o
-obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 5c3b2be..16ad0ce 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -38,7 +38,7 @@
 #include <asm/hvm/support.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/nestedhvm.h>
-#include <asm/hvm/vpmu.h>
+#include <asm/vpmu.h>
 #include <public/hvm/ioreq.h>
 #include <public/hvm/params.h>
 
diff --git a/xen/arch/x86/hvm/vmx/Makefile b/xen/arch/x86/hvm/vmx/Makefile
index 373b3d9..04a29ce 100644
--- a/xen/arch/x86/hvm/vmx/Makefile
+++ b/xen/arch/x86/hvm/vmx/Makefile
@@ -3,5 +3,4 @@ obj-y += intr.o
 obj-y += realmode.o
 obj-y += vmcs.o
 obj-y += vmx.o
-obj-y += vpmu_core2.o
 obj-y += vvmx.o
diff --git a/xen/arch/x86/oprofile/op_model_ppro.c b/xen/arch/x86/oprofile/op_model_ppro.c
index ca429a1..89649d0 100644
--- a/xen/arch/x86/oprofile/op_model_ppro.c
+++ b/xen/arch/x86/oprofile/op_model_ppro.c
@@ -19,7 +19,7 @@
 #include <asm/processor.h>
 #include <asm/regs.h>
 #include <asm/current.h>
-#include <asm/hvm/vpmu.h>
+#include <asm/vpmu.h>
 
 #include "op_x86_model.h"
 #include "op_counter.h"
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 663b44f..33f0fc5 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -72,7 +72,7 @@
 #include <asm/apic.h>
 #include <asm/mc146818rtc.h>
 #include <asm/hpet.h>
-#include <asm/hvm/vpmu.h>
+#include <asm/vpmu.h>
 #include <public/arch-x86/cpuid.h>
 #include <xsm/xsm.h>
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 949884b..dcf2d31 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -20,7 +20,7 @@
 #define __ASM_X86_HVM_VMX_VMCS_H__
 
 #include <asm/hvm/io.h>
-#include <asm/hvm/vpmu.h>
+#include <asm/vpmu.h>
 #include <irq_vectors.h>
 
 extern void vmcs_dump_vcpu(struct vcpu *v);
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/vpmu.h
similarity index 100%
rename from xen/include/asm-x86/hvm/vpmu.h
rename to xen/include/asm-x86/vpmu.h
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Q-0000ln-1z; Sun, 16 Nov 2014 23:17:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94O-0000lX-6z
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:24 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	9C/63-28865-38039645; Sun, 16 Nov 2014 23:17:23 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416179841!7543521!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28389 invoked from network); 16 Nov 2014 23:17:22 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Nov 2014 23:17:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHFLn007643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:15 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHEuo012579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:14 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHECg023727; Sun, 16 Nov 2014 23:17:14 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:13 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:31 -0500
Message-Id: <1416179271-1221-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 01/21] common/symbols: Export hypervisor
	symbols to privileged 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Export Xen's symbols as {<address><type><name>} triplet via new XENPF_get_symbol
hypercall

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/platform_hypercall.c   | 28 +++++++++++++++++++
 xen/common/symbols.c                | 54 +++++++++++++++++++++++++++++++++++++
 xen/include/public/platform.h       | 19 +++++++++++++
 xen/include/xen/symbols.h           |  3 +++
 xen/include/xlat.lst                |  1 +
 xen/xsm/flask/hooks.c               |  4 +++
 xen/xsm/flask/policy/access_vectors |  2 ++
 7 files changed, 111 insertions(+)

diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 32f39b2..7b37960 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -23,6 +23,7 @@
 #include <xen/cpu.h>
 #include <xen/pmstat.h>
 #include <xen/irq.h>
+#include <xen/symbols.h>
 #include <asm/current.h>
 #include <public/platform.h>
 #include <acpi/cpufreq/processor_perf.h>
@@ -760,6 +761,33 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
     }
     break;
 
+    case XENPF_get_symbol:
+    {
+        static char name[KSYM_NAME_LEN + 1]; /* protected by xenpf_lock */
+        XEN_GUEST_HANDLE(char) nameh;
+        uint32_t namelen, copylen;
+
+        guest_from_compat_handle(nameh, op->u.symdata.name);
+
+        ret = xensyms_read(&op->u.symdata.symnum, &op->u.symdata.type,
+                           &op->u.symdata.address, name);
+
+        namelen = strlen(name) + 1;
+
+        if ( namelen > op->u.symdata.namelen )
+            copylen = op->u.symdata.namelen;
+        else
+            copylen = namelen;
+
+        op->u.symdata.namelen = namelen;
+
+        if ( !ret && copy_to_guest(nameh, name, copylen) )
+            ret = -EFAULT;
+        if ( !ret && __copy_field_to_guest(u_xenpf_op, op, u.symdata) )
+            ret = -EFAULT;
+    }
+    break;
+
     default:
         ret = -ENOSYS;
         break;
diff --git a/xen/common/symbols.c b/xen/common/symbols.c
index bc2fde6..2c0942d 100644
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -17,6 +17,8 @@
 #include <xen/lib.h>
 #include <xen/string.h>
 #include <xen/spinlock.h>
+#include <public/platform.h>
+#include <xen/guest_access.h>
 
 #ifdef SYMBOLS_ORIGIN
 extern const unsigned int symbols_offsets[1];
@@ -148,3 +150,55 @@ const char *symbols_lookup(unsigned long addr,
     *offset = addr - symbols_address(low);
     return namebuf;
 }
+
+/*
+ * Get symbol type information. This is encoded as a single char at the
+ * beginning of the symbol name.
+ */
+static char symbols_get_symbol_type(unsigned int off)
+{
+    /*
+     * Get just the first code, look it up in the token table,
+     * and return the first char from this token.
+     */
+    return symbols_token_table[symbols_token_index[symbols_names[off + 1]]];
+}
+
+int xensyms_read(uint32_t *symnum, char *type,
+                 uint64_t *address, char *name)
+{
+    /*
+     * Symbols are most likely accessed sequentially so we remember position
+     * from previous read. This can help us avoid the extra call to
+     * get_symbol_offset().
+     */
+    static uint64_t next_symbol, next_offset;
+    static DEFINE_SPINLOCK(symbols_mutex);
+
+    if ( *symnum > symbols_num_syms )
+        return -ERANGE;
+    if ( *symnum == symbols_num_syms )
+    {
+        /* No more symbols */
+        name[0] = '\0';
+        return 0;
+    }
+
+    spin_lock(&symbols_mutex);
+
+    if ( *symnum == 0 )
+        next_offset = next_symbol = 0;
+    if ( next_symbol != *symnum )
+        /* Non-sequential access */
+        next_offset = get_symbol_offset(*symnum);
+
+    *type = symbols_get_symbol_type(next_offset);
+    next_offset = symbols_expand_symbol(next_offset, name);
+    *address = symbols_offsets[*symnum] + SYMBOLS_ORIGIN;
+
+    next_symbol = ++*symnum;
+
+    spin_unlock(&symbols_mutex);
+
+    return 0;
+}
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 5c57615..6dd7732 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -560,6 +560,24 @@ struct xenpf_resource_op {
 typedef struct xenpf_resource_op xenpf_resource_op_t;
 DEFINE_XEN_GUEST_HANDLE(xenpf_resource_op_t);
 
+#define XENPF_get_symbol   62
+struct xenpf_symdata {
+    /* IN/OUT variables */
+    uint32_t namelen; /* IN:  size of name buffer                       */
+                      /* OUT: strlen(name) of hypervisor symbol (may be */
+                      /*      larger than what's been copied to guest)  */
+    uint32_t symnum;  /* IN:  Symbol to read                            */
+                      /* OUT: Next available symbol. If same as IN then */
+                      /*      we reached the end                        */
+
+    /* OUT variables */
+    XEN_GUEST_HANDLE(char) name;
+    uint64_t address;
+    char type;
+};
+typedef struct xenpf_symdata xenpf_symdata_t;
+DEFINE_XEN_GUEST_HANDLE(xenpf_symdata_t);
+
 /*
  * ` enum neg_errnoval
  * ` HYPERVISOR_platform_op(const struct xen_platform_op*);
@@ -587,6 +605,7 @@ struct xen_platform_op {
         struct xenpf_mem_hotadd        mem_add;
         struct xenpf_core_parking      core_parking;
         struct xenpf_resource_op       resource_op;
+        struct xenpf_symdata           symdata;
         uint8_t                        pad[128];
     } u;
 };
diff --git a/xen/include/xen/symbols.h b/xen/include/xen/symbols.h
index 87cd77d..1fa0537 100644
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -11,4 +11,7 @@ const char *symbols_lookup(unsigned long addr,
                            unsigned long *offset,
                            char *namebuf);
 
+int xensyms_read(uint32_t *symnum, char *type,
+                 uint64_t *address, char *name);
+
 #endif /*_XEN_SYMBOLS_H*/
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 41b3e35..eb40aab 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -87,6 +87,7 @@
 ?	processor_px			platform.h
 !	psd_package			platform.h
 ?	xenpf_enter_acpi_sleep		platform.h
+!	xenpf_symdata			platform.h
 ?	xenpf_pcpuinfo			platform.h
 ?	xenpf_pcpu_version		platform.h
 ?	xenpf_resource_entry		platform.h
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 846cf88..b57b9d3 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1408,6 +1408,10 @@ static int flask_platform_op(uint32_t op)
         return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
                                     XEN2__RESOURCE_OP, NULL);
 
+    case XENPF_get_symbol:
+        return avc_has_perm(domain_sid(current->domain), SECINITSID_XEN,
+                            SECCLASS_XEN2, XEN2__GET_SYMBOL, NULL);
+
     default:
         printk("flask_platform_op: Unknown op %d\n", op);
         return -EPERM;
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index bfe2fa5..69152d6 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -83,6 +83,8 @@ class xen2
     resource_op
 # XEN_SYSCTL_psr_cmt_op
     psr_cmt_op
+# XENPF_get_symbol
+    get_symbol
 }
 
 # Classes domain and domain2 consist of operations that a domain performs on
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94c-0000tf-HQ; Sun, 16 Nov 2014 23:17:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94a-0000r9-Ft
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/AB-09936-F8039645; Sun, 16 Nov 2014 23:17:35 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416179852!5851236!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18622 invoked from network); 16 Nov 2014 23:17:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHPp7003464
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:26 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHPIX012814
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:25 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHOGh012810; Sun, 16 Nov 2014 23:17:24 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:24 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:41 -0500
Message-Id: <1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting PMU
	mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF:  PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
  can profile itself and the hypervisor.

Note that PMU modes are different from what can be provided at Xen's boot line
with 'vpmu' argument. An 'off' (or '0') value is equivalent to XENPMU_MODE_OFF.
Any other value, on the other hand, will cause VPMU mode to be set to
XENPMU_MODE_SELF during boot.

For feature flags only Intel's BTS is currently supported.

Mode and flags are set via HYPERVISOR_xenpmu_op hypercall.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 tools/flask/policy/policy/modules/xen/xen.te |   3 +
 xen/arch/x86/domain.c                        |   6 +-
 xen/arch/x86/hvm/svm/vpmu.c                  |   4 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c            |  10 +-
 xen/arch/x86/hvm/vpmu.c                      | 164 +++++++++++++++++++++++++--
 xen/arch/x86/x86_64/compat/entry.S           |   4 +
 xen/arch/x86/x86_64/entry.S                  |   4 +
 xen/include/asm-x86/hvm/vpmu.h               |  27 +++--
 xen/include/public/pmu.h                     |  45 ++++++++
 xen/include/public/xen.h                     |   1 +
 xen/include/xen/hypercall.h                  |   4 +
 xen/include/xlat.lst                         |   1 +
 xen/include/xsm/dummy.h                      |  15 +++
 xen/include/xsm/xsm.h                        |   6 +
 xen/xsm/dummy.c                              |   1 +
 xen/xsm/flask/hooks.c                        |  18 +++
 xen/xsm/flask/policy/access_vectors          |   2 +
 17 files changed, 288 insertions(+), 27 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index d214470..ae7bf3c 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -68,6 +68,9 @@ allow dom0_t xen_t:xen2 {
     resource_op
     psr_cmt_op
 };
+allow dom0_t xen_t:xen2 {
+    pmu_ctrl
+};
 allow dom0_t xen_t:mmu memorymap;
 
 # Allow dom0 to use these domctls on itself. For domctls acting on other
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ae0a344..da5bdf4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1544,7 +1544,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
     if ( is_hvm_vcpu(prev) )
     {
         if (prev != next)
-            vpmu_save(prev);
+            vpmu_switch_from(prev, next);
 
         if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
             pt_save_timer(prev);
@@ -1587,9 +1587,9 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
                            !is_hardware_domain(next->domain));
     }
 
-    if (is_hvm_vcpu(next) && (prev != next) )
+    if ( is_hvm_vcpu(prev) && (prev != next) )
         /* Must be done with interrupts enabled */
-        vpmu_load(next);
+        vpmu_switch_to(prev, next);
 
     context_saved(prev);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 0d30b37..61d56d5 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -478,14 +478,14 @@ struct arch_vpmu_ops amd_vpmu_ops = {
     .arch_vpmu_dump = amd_vpmu_dump
 };
 
-int svm_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int svm_vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t family = current_cpu_data.x86;
     int ret = 0;
 
     /* vpmu enabled? */
-    if ( !vpmu_flags )
+    if ( vpmu_mode == XENPMU_MODE_OFF )
         return 0;
 
     switch ( family )
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index a6cca38..23e4899 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -708,13 +708,13 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
     return 1;
 }
 
-static int core2_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+static int core2_vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     u64 msr_content;
     static bool_t ds_warned;
 
-    if ( !(vpmu_flags & VPMU_BOOT_BTS) )
+    if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
         goto func_out;
     /* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
     while ( boot_cpu_has(X86_FEATURE_DS) )
@@ -829,7 +829,7 @@ struct arch_vpmu_ops core2_no_vpmu_ops = {
     .do_cpuid = core2_no_vpmu_do_cpuid,
 };
 
-int vmx_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int vmx_vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t family = current_cpu_data.x86;
@@ -837,7 +837,7 @@ int vmx_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
     int ret = 0;
 
     vpmu->arch_vpmu_ops = &core2_no_vpmu_ops;
-    if ( !vpmu_flags )
+    if ( vpmu_mode == XENPMU_MODE_OFF )
         return 0;
 
     if ( family == 6 )
@@ -880,7 +880,7 @@ int vmx_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
         /* future: */
         case 0x3d:
         case 0x4e:
-            ret = core2_vpmu_initialise(v, vpmu_flags);
+            ret = core2_vpmu_initialise(v);
             if ( !ret )
                 vpmu->arch_vpmu_ops = &core2_vpmu_ops;
             return ret;
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index f96b530..6d9e6f9 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -21,6 +21,8 @@
 #include <xen/config.h>
 #include <xen/sched.h>
 #include <xen/xenoprof.h>
+#include <xen/event.h>
+#include <xen/guest_access.h>
 #include <asm/regs.h>
 #include <asm/types.h>
 #include <asm/msr.h>
@@ -32,8 +34,10 @@
 #include <asm/hvm/svm/vmcb.h>
 #include <asm/apic.h>
 #include <public/pmu.h>
+#include <xsm/xsm.h>
 
 #include <compat/pmu.h>
+CHECK_pmu_params;
 CHECK_pmu_intel_ctxt;
 CHECK_pmu_amd_ctxt;
 CHECK_pmu_cntr_pair;
@@ -44,7 +48,8 @@ CHECK_pmu_regs;
  * "vpmu=off" : vpmu generally disabled
  * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
  */
-static unsigned int __read_mostly opt_vpmu_enabled;
+unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
+unsigned int __read_mostly vpmu_features = 0;
 static void parse_vpmu_param(char *s);
 custom_param("vpmu", parse_vpmu_param);
 
@@ -58,7 +63,7 @@ static void __init parse_vpmu_param(char *s)
         break;
     default:
         if ( !strcmp(s, "bts") )
-            opt_vpmu_enabled |= VPMU_BOOT_BTS;
+            vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
         else if ( *s )
         {
             printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
@@ -66,7 +71,8 @@ static void __init parse_vpmu_param(char *s)
         }
         /* fall through */
     case 1:
-        opt_vpmu_enabled |= VPMU_BOOT_ENABLED;
+        /* Default VPMU mode */
+        vpmu_mode = XENPMU_MODE_SELF;
         break;
     }
 }
@@ -83,6 +89,9 @@ int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
 
+    if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+        return 0;
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
         return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
     return 0;
@@ -92,6 +101,9 @@ int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
 
+    if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+        return 0;
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
         return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
     return 0;
@@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
     switch ( vendor )
     {
     case X86_VENDOR_AMD:
-        if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-            opt_vpmu_enabled = 0;
+        if ( svm_vpmu_initialise(v) != 0 )
+            vpmu_mode = XENPMU_MODE_OFF;
         break;
 
     case X86_VENDOR_INTEL:
-        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-            opt_vpmu_enabled = 0;
+        if ( vmx_vpmu_initialise(v) != 0 )
+            vpmu_mode = XENPMU_MODE_OFF;
         break;
 
     default:
         printk("VPMU: Initialization failed. "
                "Unknown CPU vendor %d\n", vendor);
-        opt_vpmu_enabled = 0;
+        vpmu_mode = XENPMU_MODE_OFF;
         break;
     }
 }
@@ -278,3 +290,139 @@ void vpmu_dump(struct vcpu *v)
         vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
 }
 
+static s_time_t vpmu_start_ctxt_switch;
+static long vpmu_sched_checkin(void *arg)
+{
+    int cpu = cpumask_next(smp_processor_id(), &cpu_online_map);
+    int ret;
+
+    /* Mode change shouldn't take more than a few (say, 5) seconds. */
+    if ( NOW() > vpmu_start_ctxt_switch + SECONDS(5) )
+    {
+        ret = -EBUSY;
+        goto fail;
+    }
+
+    if ( cpu < nr_cpu_ids )
+    {
+        ret = continue_hypercall_on_cpu(cpu, vpmu_sched_checkin, arg);
+        if ( ret )
+            goto fail;
+    }
+    else
+        vpmu_start_ctxt_switch = 0;
+
+    return 0;
+
+ fail:
+    vpmu_mode = (uint64_t)arg;
+    vpmu_start_ctxt_switch = 0;
+    return ret;
+}
+
+static int vpmu_force_context_switch(uint64_t old_mode)
+{
+    int ret;
+
+    vpmu_start_ctxt_switch = NOW();
+
+    ret = continue_hypercall_on_cpu(cpumask_first(&cpu_online_map),
+                                    vpmu_sched_checkin, (void *)old_mode);
+    if ( ret )
+        vpmu_start_ctxt_switch = 0;
+
+    return ret;
+}
+
+long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
+{
+    int ret;
+    struct xen_pmu_params pmu_params;
+
+    ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
+    if ( ret )
+        return ret;
+
+    switch ( op )
+    {
+    case XENPMU_mode_set:
+    {
+        uint64_t old_mode;
+        static DEFINE_SPINLOCK(xenpmu_mode_lock);
+
+        if ( copy_from_guest(&pmu_params, arg, 1) )
+            return -EFAULT;
+
+        if ( pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+            return -EINVAL;
+
+        /* 32-bit dom0 can only sample itself. */
+        if ( is_pv_32bit_vcpu(current) && (pmu_params.val & XENPMU_MODE_HV) )
+            return -EINVAL;
+
+        /*
+         * Return error if someone else is in the middle of changing mode ---
+         * this is most likely indication of two system administrators
+         * working against each other.
+         */
+        if ( !spin_trylock(&xenpmu_mode_lock) )
+            return -EAGAIN;
+        if ( vpmu_start_ctxt_switch != 0 )
+        {
+            spin_unlock(&xenpmu_mode_lock);
+            return -EAGAIN;
+        }
+
+        old_mode = vpmu_mode;
+        vpmu_mode = pmu_params.val;
+
+        if ( vpmu_mode == XENPMU_MODE_OFF )
+        {
+            /*
+             * Make sure all (non-dom0) VCPUs have unloaded their VPMUs. This
+             * can be achieved by having all physical processors go through
+             * context_switch().
+             */
+            ret = vpmu_force_context_switch(old_mode);
+            if ( ret )
+                vpmu_mode = old_mode;
+        }
+
+        spin_unlock(&xenpmu_mode_lock);
+
+        break;
+    }
+
+    case XENPMU_mode_get:
+        memset(&pmu_params, 0, sizeof(pmu_params));
+        pmu_params.val = vpmu_mode;
+
+        pmu_params.version.maj = XENPMU_VER_MAJ;
+        pmu_params.version.min = XENPMU_VER_MIN;
+
+        if ( copy_to_guest(arg, &pmu_params, 1) )
+            return -EFAULT;
+        break;
+
+    case XENPMU_feature_set:
+        if ( copy_from_guest(&pmu_params, arg, 1) )
+            return -EFAULT;
+
+        if ( pmu_params.val & ~XENPMU_FEATURE_INTEL_BTS )
+            return -EINVAL;
+
+        vpmu_features = pmu_params.val;
+        break;
+
+    case XENPMU_feature_get:
+        pmu_params.val = vpmu_features;
+        if ( copy_field_to_guest(arg, &pmu_params, val) )
+            return -EFAULT;
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+
+    return ret;
+}
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index 5b0af61..7691a79 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -417,6 +417,8 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad do_ni_hypercall           /* reserved for XenClient */
+        .quad do_xenpmu_op              /* 40 */
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -466,6 +468,8 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 0 /* reserved for XenClient   */
+        .byte 2 /* do_xenpmu_op             */  /* 40 */
         .rept __HYPERVISOR_arch_0-(.-compat_hypercall_args_table)
         .byte 0 /* compat_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index b3d6e32..aa842ac 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -772,6 +772,8 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_ni_hypercall       /* reserved for XenClient */
+        .quad do_xenpmu_op          /* 40 */
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -821,6 +823,8 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 0 /* reserved for XenClient */
+        .byte 2 /* do_xenpmu_op         */  /* 40 */
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 82bfa0e..5fc15fb 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -24,13 +24,6 @@
 
 #include <public/pmu.h>
 
-/*
- * Flag bits given as a string on the hypervisor boot parameter 'vpmu'.
- * See arch/x86/hvm/vpmu.c.
- */
-#define VPMU_BOOT_ENABLED 0x1    /* vpmu generally enabled. */
-#define VPMU_BOOT_BTS     0x2    /* Intel BTS feature wanted. */
-
 #define vcpu_vpmu(vcpu)   (&(vcpu)->arch.vpmu)
 #define vpmu_vcpu(vpmu)   container_of((vpmu), struct vcpu, arch.vpmu)
 
@@ -59,8 +52,8 @@ struct arch_vpmu_ops {
     void (*arch_vpmu_dump)(const struct vcpu *);
 };
 
-int vmx_vpmu_initialise(struct vcpu *, unsigned int flags);
-int svm_vpmu_initialise(struct vcpu *, unsigned int flags);
+int vmx_vpmu_initialise(struct vcpu *);
+int svm_vpmu_initialise(struct vcpu *);
 
 struct vpmu_struct {
     u32 flags;
@@ -116,5 +109,21 @@ void vpmu_dump(struct vcpu *v);
 extern int acquire_pmu_ownership(int pmu_ownership);
 extern void release_pmu_ownership(int pmu_ownership);
 
+extern unsigned int vpmu_mode;
+extern unsigned int vpmu_features;
+
+/* Context switch */
+inline void vpmu_switch_from(struct vcpu *prev, struct vcpu *next)
+{
+    if ( vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+        vpmu_save(prev);
+}
+
+inline void vpmu_switch_to(struct vcpu *prev, struct vcpu *next)
+{
+    if ( vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+        vpmu_load(next);
+}
+
 #endif /* __ASM_X86_HVM_VPMU_H_*/
 
diff --git a/xen/include/public/pmu.h b/xen/include/public/pmu.h
index f97106d..66cc494 100644
--- a/xen/include/public/pmu.h
+++ b/xen/include/public/pmu.h
@@ -13,6 +13,51 @@
 #define XENPMU_VER_MAJ    0
 #define XENPMU_VER_MIN    1
 
+/*
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_xenpmu_op(enum xenpmu_op cmd, struct xenpmu_params *args);
+ *
+ * @cmd  == XENPMU_* (PMU operation)
+ * @args == struct xenpmu_params
+ */
+/* ` enum xenpmu_op { */
+#define XENPMU_mode_get        0 /* Also used for getting PMU version */
+#define XENPMU_mode_set        1
+#define XENPMU_feature_get     2
+#define XENPMU_feature_set     3
+/* ` } */
+
+/* Parameters structure for HYPERVISOR_xenpmu_op call */
+struct xen_pmu_params {
+    /* IN/OUT parameters */
+    struct {
+        uint32_t maj;
+        uint32_t min;
+    } version;
+    uint64_t val;
+
+    /* IN parameters */
+    uint32_t vcpu;
+    uint32_t pad;
+};
+typedef struct xen_pmu_params xen_pmu_params_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_params_t);
+
+/* PMU modes:
+ * - XENPMU_MODE_OFF:   No PMU virtualization
+ * - XENPMU_MODE_SELF:  Guests can profile themselves
+ * - XENPMU_MODE_HV:    Guests can profile themselves, dom0 profiles
+ *                      itself and Xen
+ */
+#define XENPMU_MODE_OFF           0
+#define XENPMU_MODE_SELF          (1<<0)
+#define XENPMU_MODE_HV            (1<<1)
+
+/*
+ * PMU features:
+ * - XENPMU_FEATURE_INTEL_BTS: Intel BTS support (ignored on AMD)
+ */
+#define XENPMU_FEATURE_INTEL_BTS  1
 
 /* Shared between hypervisor and PV domain */
 struct xen_pmu_data {
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index a6a2092..0766790 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -101,6 +101,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
 #define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient */
+#define __HYPERVISOR_xenpmu_op            40
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index a9e5229..cf34547 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -14,6 +14,7 @@
 #include <public/event_channel.h>
 #include <public/tmem.h>
 #include <public/version.h>
+#include <public/pmu.h>
 #include <asm/hypercall.h>
 #include <xsm/xsm.h>
 
@@ -139,6 +140,9 @@ do_tmem_op(
 extern long
 do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
+extern long
+do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg);
+
 #ifdef CONFIG_COMPAT
 
 extern int
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 8bff86d..0186573 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -103,6 +103,7 @@
 !	vcpu_set_singleshot_timer	vcpu.h
 ?	xenoprof_init			xenoprof.h
 ?	xenoprof_passive		xenoprof.h
+?	pmu_params			pmu.h
 ?	pmu_intel_ctxt			arch-x86/pmu.h
 ?	pmu_amd_ctxt			arch-x86/pmu.h
 ?	pmu_cntr_pair			arch-x86/pmu.h
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f20e89c..c637454 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -655,4 +655,19 @@ static XSM_INLINE int xsm_ioport_mapping(XSM_DEFAULT_ARG struct domain *d, uint3
     return xsm_default_action(action, current->domain, d);
 }
 
+static XSM_INLINE int xsm_pmu_op (XSM_DEFAULT_ARG struct domain *d, int op)
+{
+    XSM_ASSERT_ACTION(XSM_OTHER);
+    switch ( op )
+    {
+    case XENPMU_mode_set:
+    case XENPMU_mode_get:
+    case XENPMU_feature_set:
+    case XENPMU_feature_get:
+        return xsm_default_action(XSM_PRIV, d, current->domain);
+    default:
+        return -EPERM;
+    }
+}
+
 #endif /* CONFIG_X86 */
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4ce089f..0e39dfe 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -173,6 +173,7 @@ struct xsm_operations {
     int (*unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
     int (*ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
+    int (*pmu_op) (struct domain *d, int op);
 #endif
 };
 
@@ -665,6 +666,11 @@ static inline int xsm_ioport_mapping (xsm_default_t def, struct domain *d, uint3
     return xsm_ops->ioport_mapping(d, s, e, allow);
 }
 
+static inline int xsm_pmu_op (xsm_default_t def, struct domain *d, int op)
+{
+    return xsm_ops->pmu_op(d, op);
+}
+
 #endif /* CONFIG_X86 */
 
 #endif /* XSM_NO_WRAPPERS */
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 8eb3050..94f1cf0 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -144,5 +144,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, unbind_pt_irq);
     set_to_dummy_if_null(ops, ioport_permission);
     set_to_dummy_if_null(ops, ioport_mapping);
+    set_to_dummy_if_null(ops, pmu_op);
 #endif
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index b57b9d3..8e1914e 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1502,6 +1502,23 @@ static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq
 {
     return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
+
+static int flask_pmu_op (struct domain *d, int op)
+{
+    u32 dsid = domain_sid(d);
+
+    switch ( op )
+    {
+    case XENPMU_mode_set:
+    case XENPMU_mode_get:
+    case XENPMU_feature_set:
+    case XENPMU_feature_get:
+        return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN2,
+                            XEN2__PMU_CTRL, NULL);
+    default:
+        return -EPERM;
+    }
+}
 #endif /* CONFIG_X86 */
 
 long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op);
@@ -1624,6 +1641,7 @@ static struct xsm_operations flask_ops = {
     .unbind_pt_irq = flask_unbind_pt_irq,
     .ioport_permission = flask_ioport_permission,
     .ioport_mapping = flask_ioport_mapping,
+    .pmu_op = flask_pmu_op,
 #endif
 };
 
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 69152d6..3289d98 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -85,6 +85,8 @@ class xen2
     psr_cmt_op
 # XENPF_get_symbol
     get_symbol
+# PMU control
+    pmu_ctrl
 }
 
 # Classes domain and domain2 consist of operations that a domain performs on
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94k-00014Q-3D; Sun, 16 Nov 2014 23:17:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94h-0000z5-JX
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:43 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	88/AB-22819-69039645; Sun, 16 Nov 2014 23:17:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416179860!11643500!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16230 invoked from network); 16 Nov 2014 23:17:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Nov 2014 23:17:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHYA8003493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:35 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHXqv024301
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:34 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHXDG013001; Sun, 16 Nov 2014 23:17:33 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:33 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:50 -0500
Message-Id: <1416179271-1221-21-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 20/21] x86/VPMU: NMI-based VPMU support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 support for using NMIs as PMU interrupts to allow profiling hypervisor
when interrupts are disabled.

Most of processing is still performed by vpmu_do_interrupt(). However, since
certain operations are not NMI-safe we defer them to a softint that vpmu_do_interrupt()
will schedule:
* For PV guests that would be send_guest_vcpu_virq()
* For HVM guests it's VLAPIC accesses and hvm_get_segment_register() (the later
can be called in privileged profiling mode when the interrupted guest is an HVM one).

With send_guest_vcpu_virq() and hvm_get_segment_register() for PV(H) and vlapic
accesses for HVM moved to sofint, the only routines/macros that vpmu_do_interrupt()
calls in NMI mode are:
* memcpy()
* querying domain type (is_XX_domain())
* guest_cpu_user_regs()
* XLAT_cpu_user_regs()
* raise_softirq()
* vcpu_vpmu()
* vpmu_ops->arch_vpmu_save()
* vpmu_ops->do_interrupt()

The latter two only access PMU MSRs with {rd,wr}msrl() (not the _safe versions
which would not be NMI-safe).

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 docs/misc/xen-command-line.markdown |   8 +-
 xen/arch/x86/hvm/svm/vpmu.c         |   3 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c   |   3 +-
 xen/arch/x86/hvm/vpmu.c             | 230 ++++++++++++++++++++++++++++--------
 xen/include/asm-x86/hvm/vpmu.h      |   4 +-
 xen/include/asm-x86/softirq.h       |   3 +-
 6 files changed, 195 insertions(+), 56 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0830e5f..d7f988e 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1281,11 +1281,11 @@ Use Virtual Processor ID support if available.  This prevents the need for TLB
 flushes on VM entry and exit, increasing performance.
 
 ### vpmu
-> `= ( bts )`
+> `= ( [nmi,][bts] )`
 
 > Default: `off`
 
-Switch on the virtualized performance monitoring unit for HVM guests.
+Switch on the virtualized performance monitoring unit.
 
 If the current cpu isn't supported a message like  
 'VPMU: Initialization failed. ...'  
@@ -1297,6 +1297,10 @@ wrong behaviour (see handle\_pmc\_quirk()).
 If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
 feature is switched on on Intel processors supporting this feature.
 
+If 'vpmu=nmi' is specified the PMU interrupt will cause an NMI instead of a
+regular vector interrupt (which is the default). This can be useful for sampling
+hypervisor code that is executed with interrupts disabled.
+
 *Warning:*
 As the BTS virtualisation is not 100% safe and because of the nehalem quirk
 don't use the vpmu flag on production systems with Intel cpus!
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 7d9ba8c..c21bde0 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -168,7 +168,7 @@ static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
     msr_bitmap_off(vpmu);
 }
 
-static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
+static int amd_vpmu_do_interrupt(const struct cpu_user_regs *regs)
 {
     return 1;
 }
@@ -223,6 +223,7 @@ static inline void context_save(struct vcpu *v)
         rdmsrl(counters[i], counter_regs[i]);
 }
 
+/* Must be NMI-safe */
 static int amd_vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 839dce0..271fae5 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -305,6 +305,7 @@ static inline void __core2_vpmu_save(struct vcpu *v)
         rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
+/* Must be NMI-safe */
 static int core2_vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
@@ -706,7 +707,7 @@ static void core2_vpmu_dump(const struct vcpu *v)
     }
 }
 
-static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
+static int core2_vpmu_do_interrupt(const struct cpu_user_regs *regs)
 {
     struct vcpu *v = current;
     u64 msr_content;
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 5f0a871..cf96da7 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -34,6 +34,7 @@
 #include <asm/hvm/svm/svm.h>
 #include <asm/hvm/svm/vmcb.h>
 #include <asm/apic.h>
+#include <asm/nmi.h>
 #include <public/pmu.h>
 #include <xsm/xsm.h>
 
@@ -54,36 +55,54 @@ unsigned int __read_mostly vpmu_features = 0;
 static void parse_vpmu_param(char *s);
 custom_param("vpmu", parse_vpmu_param);
 
+static void pmu_softnmi(void);
+
 static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
+static DEFINE_PER_CPU(struct vcpu *, sampled_vcpu);
+
+static uint32_t __read_mostly vpmu_interrupt_type = PMU_APIC_VECTOR;
 
 static void __init parse_vpmu_param(char *s)
 {
-    switch ( parse_bool(s) )
-    {
-    case 0:
-        break;
-    default:
-        if ( !strcmp(s, "bts") )
-            vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
-        else if ( *s )
+    char *ss;
+
+    vpmu_mode = XENPMU_MODE_SELF;
+    if (*s == '\0')
+        return;
+
+    do {
+        ss = strchr(s, ',');
+        if ( ss )
+            *ss = '\0';
+
+        switch  ( parse_bool(s) )
         {
-            printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
-            break;
+        default:
+            if ( !strcmp(s, "nmi") )
+                vpmu_interrupt_type = APIC_DM_NMI;
+            else if ( !strcmp(s, "bts") )
+                vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
+            else
+            {
+                printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
+        case 0:
+                vpmu_mode = XENPMU_MODE_OFF;
+        case 1:
+                return;
+            }
         }
-        /* fall through */
-    case 1:
-        /* Default VPMU mode */
-        vpmu_mode = XENPMU_MODE_SELF;
-        break;
-    }
+
+        s = ss + 1;
+    } while ( ss );
 }
 
+
 void vpmu_lvtpc_update(uint32_t val)
 {
     struct vcpu *curr = current;
     struct vpmu_struct *vpmu = vcpu_vpmu(curr);
 
-    vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
+    vpmu->hw_lapic_lvtpc = vpmu_interrupt_type | (val & APIC_LVT_MASKED);
 
     /* Postpone APIC updates for PV(H) guests if PMU interrupt is pending */
     if ( is_hvm_vcpu(curr) || !vpmu->xenpmu_data ||
@@ -91,6 +110,30 @@ void vpmu_lvtpc_update(uint32_t val)
         apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
 
+static void vpmu_send_interrupt(struct vcpu *v)
+{
+    struct vlapic *vlapic;
+    u32 vlapic_lvtpc;
+
+    ASSERT(is_hvm_vcpu(v));
+
+    vlapic = vcpu_vlapic(v);
+    if ( !is_vlapic_lvtpc_enabled(vlapic) )
+        return;
+
+    vlapic_lvtpc = vlapic_get_reg(vlapic, APIC_LVTPC);
+
+    switch ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) )
+    {
+    case APIC_MODE_FIXED:
+        vlapic_set_irq(vlapic, vlapic_lvtpc & APIC_VECTOR_MASK, 0);
+        break;
+    case APIC_MODE_NMI:
+        v->nmi_pending = 1;
+        break;
+    }
+}
+
 int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
                 uint64_t supported, bool_t is_write)
 {
@@ -141,7 +184,7 @@ static struct vcpu *choose_hwdom_vcpu(void)
     return hardware_domain->vcpu[idx];
 }
 
-void vpmu_do_interrupt(struct cpu_user_regs *regs)
+int vpmu_do_interrupt(const struct cpu_user_regs *regs)
 {
     struct vcpu *sampled = current, *sampling;
     struct vpmu_struct *vpmu;
@@ -155,7 +198,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
     {
         sampling = choose_hwdom_vcpu();
         if ( !sampling )
-            return;
+            return 0;
     }
     else
         sampling = sampled;
@@ -169,15 +212,15 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
         uint32_t domid;
 
         if ( !vpmu->xenpmu_data )
-            return;
+            return 0;
 
         if ( *flags & PMU_CACHED )
-            return;
+            return 0;
 
         if ( is_pvh_vcpu(sampling) &&
              !(vpmu_mode & XENPMU_MODE_ALL) &&
              !vpmu->arch_vpmu_ops->do_interrupt(regs) )
-            return;
+            return 0;
 
         /* PV guest will be reading PMU MSRs from xenpmu_data */
         vpmu_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
@@ -241,16 +284,21 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
             }
             else
             {
-                struct segment_register seg;
-
-                hvm_get_segment_register(sampled, x86_seg_cs, &seg);
-                r->cs = seg.sel;
-                hvm_get_segment_register(sampled, x86_seg_ss, &seg);
-                r->ss = seg.sel;
-                if ( seg.attr.fields.dpl != 0 )
-                    *flags |= PMU_SAMPLE_USER;
                 if ( !(sampled->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) )
                     *flags |= PMU_SAMPLE_REAL;
+
+                /* Unsafe in NMI context, defer to softint later. */
+                if ( vpmu_interrupt_type != APIC_DM_NMI )
+                {
+                    struct segment_register seg;
+
+                    hvm_get_segment_register(sampled, x86_seg_cs, &seg);
+                    r->cs = seg.sel;
+                    hvm_get_segment_register(sampled, x86_seg_ss, &seg);
+                    r->ss = seg.sel;
+                    if ( seg.attr.fields.dpl != 0 )
+                        *flags |= PMU_SAMPLE_USER;
+                }
             }
         }
 
@@ -262,35 +310,37 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
         vpmu->hw_lapic_lvtpc |= APIC_LVT_MASKED;
         apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 
-        send_guest_vcpu_virq(sampling, VIRQ_XENPMU);
+        if ( vpmu_interrupt_type == APIC_DM_NMI )
+        {
+            this_cpu(sampled_vcpu) = sampled;
+            raise_softirq(PMU_SOFTIRQ);
+        }
+        else
+            send_guest_vcpu_virq(sampling, VIRQ_XENPMU);
 
-        return;
+        return 1;
     }
 
     if ( vpmu->arch_vpmu_ops )
     {
-        struct vlapic *vlapic = vcpu_vlapic(sampling);
-        u32 vlapic_lvtpc;
-
         /* We don't support (yet) HVM dom0 */
         ASSERT(sampling == sampled);
 
-        if ( !vpmu->arch_vpmu_ops->do_interrupt(regs) ||
-             !is_vlapic_lvtpc_enabled(vlapic) )
-            return;
+        if ( !vpmu->arch_vpmu_ops->do_interrupt(regs) )
+            return 0;
 
-        vlapic_lvtpc = vlapic_get_reg(vlapic, APIC_LVTPC);
-
-        switch ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) )
+        if ( vpmu_interrupt_type == APIC_DM_NMI )
         {
-        case APIC_MODE_FIXED:
-            vlapic_set_irq(vlapic, vlapic_lvtpc & APIC_VECTOR_MASK, 0);
-            break;
-        case APIC_MODE_NMI:
-            sampling->nmi_pending = 1;
-            break;
+            this_cpu(sampled_vcpu) = sampled;
+            raise_softirq(PMU_SOFTIRQ);
         }
+        else
+            vpmu_send_interrupt(sampling);
+
+        return 1;
     }
+
+    return 0;
 }
 
 void vpmu_do_cpuid(unsigned int input,
@@ -319,6 +369,9 @@ static void vpmu_save_force(void *arg)
     vpmu_reset(vpmu, VPMU_CONTEXT_SAVE);
 
     per_cpu(last_vcpu, smp_processor_id()) = NULL;
+
+    /* Make sure there are no outstanding PMU NMIs */
+    pmu_softnmi();
 }
 
 void vpmu_save(struct vcpu *v)
@@ -336,7 +389,10 @@ void vpmu_save(struct vcpu *v)
         if ( vpmu->arch_vpmu_ops->arch_vpmu_save(v) )
             vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
 
-    apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
+    apic_write(APIC_LVTPC, vpmu_interrupt_type | APIC_LVT_MASKED);
+
+    /* Make sure there are no outstanding PMU NMIs */
+    pmu_softnmi();
 }
 
 void vpmu_load(struct vcpu *v)
@@ -390,6 +446,9 @@ void vpmu_load(struct vcpu *v)
           (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED)) )
         return;
 
+    /* Make sure there are no outstanding PMU NMIs from previous vcpu */
+    pmu_softnmi();
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
     {
         apic_write_around(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
@@ -412,7 +471,7 @@ void vpmu_initialise(struct vcpu *v)
         vpmu_destroy(v);
     vpmu_clear(vpmu);
     vpmu->context = NULL;
-    vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
+    vpmu->hw_lapic_lvtpc = vpmu_interrupt_type | APIC_LVT_MASKED;
 
     switch ( vendor )
     {
@@ -448,6 +507,57 @@ void vpmu_destroy(struct vcpu *v)
     }
 }
 
+/* Process the softirq set by PMU NMI handler */
+static void pmu_softnmi(void)
+{
+    unsigned int cpu = smp_processor_id();
+    struct vcpu *v, *sampled = per_cpu(sampled_vcpu, cpu);
+
+    if ( sampled == NULL )
+        return;
+
+    per_cpu(sampled_vcpu, cpu) = NULL;
+
+    if ( (vpmu_mode & XENPMU_MODE_ALL) ||
+         (sampled->domain->domain_id >= DOMID_FIRST_RESERVED) )
+    {
+            v = choose_hwdom_vcpu();
+            if ( !v )
+                return;
+    }
+    else
+    {
+        if ( is_hvm_vcpu(sampled) )
+        {
+            vpmu_send_interrupt(sampled);
+            return;
+        }
+        v = sampled;
+    }
+
+    if ( has_hvm_container_vcpu(sampled) )
+    {
+        struct segment_register seg;
+        struct xen_pmu_arch *pmu = &v->arch.vpmu.xenpmu_data->pmu;
+        struct xen_pmu_regs *r = &pmu->r.regs;
+
+        hvm_get_segment_register(sampled, x86_seg_cs, &seg);
+        r->cs = seg.sel;
+        hvm_get_segment_register(sampled, x86_seg_ss, &seg);
+        r->ss = seg.sel;
+        if ( seg.attr.fields.dpl != 0 )
+            pmu->pmu_flags |= PMU_SAMPLE_USER;
+    }
+
+    send_guest_vcpu_virq(v, VIRQ_XENPMU);
+}
+
+int pmu_nmi_interrupt(const struct cpu_user_regs *regs, int cpu)
+{
+    return vpmu_do_interrupt(regs);
+}
+
+
 static int pvpmu_init(struct domain *d, xen_pmu_params_t *params)
 {
     struct vcpu *v;
@@ -715,6 +825,21 @@ static int __init vpmu_init(void)
         return 0;
     }
 
+    if ( vpmu_interrupt_type == APIC_DM_NMI )
+    {
+        if ( reserve_lapic_nmi() != 0 )
+        {
+            printk(XENLOG_WARNING "VPMU: Can't reserve NMI, will use"
+                                  " APIC vector 0x%x\n", PMU_APIC_VECTOR);
+            vpmu_interrupt_type = PMU_APIC_VECTOR;
+        }
+        else
+        {
+            set_nmi_callback(pmu_nmi_interrupt);
+            open_softirq(PMU_SOFTIRQ, pmu_softnmi);
+        }
+    }
+
     switch ( vendor )
     {
         case X86_VENDOR_AMD:
@@ -731,7 +856,14 @@ static int __init vpmu_init(void)
     }
 
     if ( vpmu_mode == XENPMU_MODE_OFF )
+    {
+        if ( vpmu_interrupt_type == APIC_DM_NMI )
+        {
+            unset_nmi_callback();
+            release_lapic_nmi();
+        }
         printk(XENLOG_WARNING "VPMU: Disabling due to initialization error\n");
+    }
     else
         printk(XENLOG_INFO "VPMU: version %d.%d\n",
                XENPMU_VER_MAJ, XENPMU_VER_MIN);
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 56cc09c..8662b51 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -42,7 +42,7 @@ struct arch_vpmu_ops {
     int (*do_wrmsr)(unsigned int msr, uint64_t msr_content,
                     uint64_t supported);
     int (*do_rdmsr)(unsigned int msr, uint64_t *msr_content);
-    int (*do_interrupt)(struct cpu_user_regs *regs);
+    int (*do_interrupt)(const struct cpu_user_regs *regs);
     void (*do_cpuid)(unsigned int input,
                      unsigned int *eax, unsigned int *ebx,
                      unsigned int *ecx, unsigned int *edx);
@@ -101,7 +101,7 @@ static inline bool_t vpmu_are_all_set(const struct vpmu_struct *vpmu,
 void vpmu_lvtpc_update(uint32_t val);
 int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
                 uint64_t supported, bool_t is_write);
-void vpmu_do_interrupt(struct cpu_user_regs *regs);
+int vpmu_do_interrupt(const 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);
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 7225dea..ef24056 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -7,7 +7,8 @@
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
-#define NR_ARCH_SOFTIRQS       5
+#define PMU_SOFTIRQ            (NR_COMMON_SOFTIRQS + 5)
+#define NR_ARCH_SOFTIRQS       6
 
 bool_t arch_skip_send_event_check(unsigned int cpu);
 
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94j-00012c-2D; Sun, 16 Nov 2014 23:17:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94h-0000yc-1M
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FC/AB-09936-69039645; Sun, 16 Nov 2014 23:17:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416179859!13180247!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10315 invoked from network); 16 Nov 2014 23:17:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:40 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHXJi007761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:34 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHXtd007687
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 16 Nov 2014 23:17:33 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAGNHVWT016684; Sun, 16 Nov 2014 23:17:32 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:31 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:48 -0500
Message-Id: <1416179271-1221-19-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 18/21] x86/VPMU: Merge vpmu_rdmsr and
	vpmu_wrmsr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 two routines share most of their logic.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vpmu.c        | 69 +++++++++++++++++-------------------------
 xen/include/asm-x86/hvm/vpmu.h | 14 +++++++--
 2 files changed, 39 insertions(+), 44 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 6a71d53..aa4a5d9 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -91,57 +91,42 @@ void vpmu_lvtpc_update(uint32_t val)
         apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
 
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+                uint64_t supported, bool_t is_write)
 {
-    struct vcpu *curr = current;
-    struct vpmu_struct *vpmu = vcpu_vpmu(curr);
+    struct vcpu *curr;
+    struct vpmu_struct *vpmu;
+    struct arch_vpmu_ops *ops;
+    int ret = 0;
 
     if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
         return 0;
 
-    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
-    {
-        int ret = vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
-
-        /*
-         * We may have received a PMU interrupt during WRMSR handling
-         * and since do_wrmsr may load VPMU context we should save
-         * (and unload) it again.
-         */
-        if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
-             (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
-        {
-            vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-            vpmu->arch_vpmu_ops->arch_vpmu_save(curr);
-            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-        }
-        return ret;
-    }
-    return 0;
-}
-
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
-{
-    struct vcpu *curr = current;
-    struct vpmu_struct *vpmu = vcpu_vpmu(curr);
-
-    if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+    curr = current;
+    vpmu = vcpu_vpmu(curr);
+    ops = vpmu->arch_vpmu_ops;
+    if ( !ops )
         return 0;
 
-    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
+    if ( is_write && ops->do_wrmsr )
+        ret = ops->do_wrmsr(msr, *msr_content, supported);
+    else if ( !is_write && ops->do_rdmsr )
+        ret = ops->do_rdmsr(msr, msr_content);
+
+    /*
+     * We may have received a PMU interrupt while handling MSR access
+     * and since do_wr/rdmsr may load VPMU context we should save
+     * (and unload) it again.
+     */
+    if ( !is_hvm_vcpu(curr) &&
+         vpmu->xenpmu_data && (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
     {
-        int ret = vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
-
-        if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
-             (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
-        {
-            vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-            vpmu->arch_vpmu_ops->arch_vpmu_save(curr);
-            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-        }
-        return ret;
+        vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+        ops->arch_vpmu_save(curr);
+        vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
     }
-    return 0;
+
+    return ret;
 }
 
 static struct vcpu *choose_hwdom_vcpu(void)
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index ada2ab7..56cc09c 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -99,8 +99,8 @@ static inline bool_t vpmu_are_all_set(const struct vpmu_struct *vpmu,
 }
 
 void vpmu_lvtpc_update(uint32_t val);
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+                uint64_t supported, bool_t is_write);
 void 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);
@@ -110,6 +110,16 @@ void vpmu_save(struct vcpu *v);
 void vpmu_load(struct vcpu *v);
 void vpmu_dump(struct vcpu *v);
 
+static inline int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
+                                uint64_t supported)
+{
+    return vpmu_do_msr(msr, &msr_content, supported, 1);
+}
+static inline int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
+{
+    return vpmu_do_msr(msr, msr_content, 0, 0);
+}
+
 extern int acquire_pmu_ownership(int pmu_ownership);
 extern void release_pmu_ownership(int pmu_ownership);
 
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94W-0000nq-HZ; Sun, 16 Nov 2014 23:17:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94U-0000mb-3s
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E1/89-24532-98039645; Sun, 16 Nov 2014 23:17:29 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416179846!12807246!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4585 invoked from network); 16 Nov 2014 23:17:28 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHKKc003445
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:21 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHJ2Y007375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:20 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHJLs007363; Sun, 16 Nov 2014 23:17:19 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:18 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:36 -0500
Message-Id: <1416179271-1221-7-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 06/21] vmx: Merge MSR management routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

vmx_add_host_load_msr() and vmx_add_guest_msr() share fair amount of code. Merge
them to simplify code maintenance.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vmx/vmcs.c        | 84 +++++++++++++++++++-------------------
 xen/include/asm-x86/hvm/vmx/vmcs.h | 16 +++++++-
 2 files changed, 55 insertions(+), 45 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 9d8033e..b9e3ef8 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1201,64 +1201,62 @@ int vmx_write_guest_msr(u32 msr, u64 val)
     return -ESRCH;
 }
 
-int vmx_add_guest_msr(u32 msr)
+int vmx_add_msr(u32 msr, int type)
 {
     struct vcpu *curr = current;
-    unsigned int i, msr_count = curr->arch.hvm_vmx.msr_count;
-    struct vmx_msr_entry *msr_area = curr->arch.hvm_vmx.msr_area;
+    unsigned int idx, *msr_count;
+    struct vmx_msr_entry **msr_area, *msr_area_elem;
+
+    if ( type == VMX_GUEST_MSR )
+    {
+        msr_count = &curr->arch.hvm_vmx.msr_count;
+        msr_area = &curr->arch.hvm_vmx.msr_area;
+    }
+    else
+    {
+        ASSERT(type == VMX_HOST_MSR);
+        msr_count = &curr->arch.hvm_vmx.host_msr_count;
+        msr_area = &curr->arch.hvm_vmx.host_msr_area;
+    }
 
-    if ( msr_area == NULL )
+    if ( *msr_area == NULL )
     {
-        if ( (msr_area = alloc_xenheap_page()) == NULL )
+        if ( (*msr_area = alloc_xenheap_page()) == NULL )
             return -ENOMEM;
-        curr->arch.hvm_vmx.msr_area = msr_area;
-        __vmwrite(VM_EXIT_MSR_STORE_ADDR, virt_to_maddr(msr_area));
-        __vmwrite(VM_ENTRY_MSR_LOAD_ADDR, virt_to_maddr(msr_area));
+
+        if ( type == VMX_GUEST_MSR )
+        {
+            __vmwrite(VM_EXIT_MSR_STORE_ADDR, virt_to_maddr(*msr_area));
+            __vmwrite(VM_ENTRY_MSR_LOAD_ADDR, virt_to_maddr(*msr_area));
+        }
+        else
+            __vmwrite(VM_EXIT_MSR_LOAD_ADDR, virt_to_maddr(*msr_area));
     }
 
-    for ( i = 0; i < msr_count; i++ )
-        if ( msr_area[i].index == msr )
+    for ( idx = 0; idx < *msr_count; idx++ )
+        if ( (*msr_area)[idx].index == msr )
             return 0;
 
-    if ( msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
+    if ( *msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
         return -ENOSPC;
 
-    msr_area[msr_count].index = msr;
-    msr_area[msr_count].mbz   = 0;
-    msr_area[msr_count].data  = 0;
-    curr->arch.hvm_vmx.msr_count = ++msr_count;
-    __vmwrite(VM_EXIT_MSR_STORE_COUNT, msr_count);
-    __vmwrite(VM_ENTRY_MSR_LOAD_COUNT, msr_count);
+    msr_area_elem = *msr_area + *msr_count;
+    msr_area_elem->index = msr;
+    msr_area_elem->mbz = 0;
 
-    return 0;
-}
+    ++*msr_count;
 
-int vmx_add_host_load_msr(u32 msr)
-{
-    struct vcpu *curr = current;
-    unsigned int i, msr_count = curr->arch.hvm_vmx.host_msr_count;
-    struct vmx_msr_entry *msr_area = curr->arch.hvm_vmx.host_msr_area;
-
-    if ( msr_area == NULL )
+    if ( type == VMX_GUEST_MSR )
     {
-        if ( (msr_area = alloc_xenheap_page()) == NULL )
-            return -ENOMEM;
-        curr->arch.hvm_vmx.host_msr_area = msr_area;
-        __vmwrite(VM_EXIT_MSR_LOAD_ADDR, virt_to_maddr(msr_area));
+        msr_area_elem->data = 0;
+        __vmwrite(VM_EXIT_MSR_STORE_COUNT, *msr_count);
+        __vmwrite(VM_ENTRY_MSR_LOAD_COUNT, *msr_count);
+    }
+    else
+    {
+        rdmsrl(msr, msr_area_elem->data);
+        __vmwrite(VM_EXIT_MSR_LOAD_COUNT, *msr_count);
     }
-
-    for ( i = 0; i < msr_count; i++ )
-        if ( msr_area[i].index == msr )
-            return 0;
-
-    if ( msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
-        return -ENOSPC;
-
-    msr_area[msr_count].index = msr;
-    msr_area[msr_count].mbz   = 0;
-    rdmsrl(msr, msr_area[msr_count].data);
-    curr->arch.hvm_vmx.host_msr_count = ++msr_count;
-    __vmwrite(VM_EXIT_MSR_LOAD_COUNT, msr_count);
 
     return 0;
 }
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 6a99dca..949884b 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -482,12 +482,15 @@ extern const unsigned int vmx_introspection_force_enabled_msrs_size;
 
 #define MSR_TYPE_R 1
 #define MSR_TYPE_W 2
+
+#define VMX_GUEST_MSR 0
+#define VMX_HOST_MSR  1
+
 void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
 void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
 int vmx_read_guest_msr(u32 msr, u64 *val);
 int vmx_write_guest_msr(u32 msr, u64 val);
-int vmx_add_guest_msr(u32 msr);
-int vmx_add_host_load_msr(u32 msr);
+int vmx_add_msr(u32 msr, int type);
 void vmx_vmcs_switch(struct vmcs_struct *from, struct vmcs_struct *to);
 void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector);
 void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector);
@@ -497,6 +500,15 @@ void virtual_vmcs_exit(void *vvmcs);
 u64 virtual_vmcs_vmread(void *vvmcs, u32 vmcs_encoding);
 void virtual_vmcs_vmwrite(void *vvmcs, u32 vmcs_encoding, u64 val);
 
+static inline int vmx_add_guest_msr(u32 msr)
+{
+    return vmx_add_msr(msr, VMX_GUEST_MSR);
+}
+static inline int vmx_add_host_load_msr(u32 msr)
+{
+    return vmx_add_msr(msr, VMX_HOST_MSR);
+}
+
 DECLARE_PER_CPU(bool_t, vmxon);
 
 #endif /* ASM_X86_HVM_VMX_VMCS_H__ */
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Z-0000pv-1D; Sun, 16 Nov 2014 23:17:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94X-0000o1-A0
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:33 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	37/8B-02576-C8039645; Sun, 16 Nov 2014 23:17:32 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416179849!12912834!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22845 invoked from network); 16 Nov 2014 23:17:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:31 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHPPT007715
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:25 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHOXS024016
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 16 Nov 2014 23:17:25 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAGNHN0V016490; Sun, 16 Nov 2014 23:17:23 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:21 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:39 -0500
Message-Id: <1416179271-1221-10-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 09/21] x86/VPMU: Add public xenpmu.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add pmu.h header files, move various macros and structures that will be
shared between hypervisor and PV guests to it.

Move MSR banks out of architectural PMU structures to allow for larger sizes
in the future. The banks are allocated immediately after the context and
PMU structures store offsets to them.

While making these updates, also:
* Remove unused vpmu_domain() macro from vpmu.h
* Convert msraddr_to_bitpos() into an inline and make it a little faster by
  realizing that all Intel's PMU-related MSRs are in the lower MSR range.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/vpmu.c              |  83 +++++++++++----------
 xen/arch/x86/hvm/vmx/vpmu_core2.c        | 123 +++++++++++++++++--------------
 xen/arch/x86/hvm/vpmu.c                  |  10 +++
 xen/arch/x86/oprofile/op_model_ppro.c    |   6 +-
 xen/include/Makefile                     |   2 +
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |  32 --------
 xen/include/asm-x86/hvm/vpmu.h           |  16 ++--
 xen/include/public/arch-arm.h            |   3 +
 xen/include/public/arch-x86/pmu.h        |  90 ++++++++++++++++++++++
 xen/include/public/pmu.h                 |  38 ++++++++++
 xen/include/xlat.lst                     |   4 +
 11 files changed, 274 insertions(+), 133 deletions(-)
 delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
 create mode 100644 xen/include/public/arch-x86/pmu.h
 create mode 100644 xen/include/public/pmu.h

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index af3cdb2..0d30b37 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -30,10 +30,7 @@
 #include <asm/apic.h>
 #include <asm/hvm/vlapic.h>
 #include <asm/hvm/vpmu.h>
-
-#define F10H_NUM_COUNTERS 4
-#define F15H_NUM_COUNTERS 6
-#define MAX_NUM_COUNTERS F15H_NUM_COUNTERS
+#include <public/pmu.h>
 
 #define MSR_F10H_EVNTSEL_GO_SHIFT   40
 #define MSR_F10H_EVNTSEL_EN_SHIFT   22
@@ -49,6 +46,9 @@ static const u32 __read_mostly *counters;
 static const u32 __read_mostly *ctrls;
 static bool_t __read_mostly k7_counters_mirrored;
 
+#define F10H_NUM_COUNTERS   4
+#define F15H_NUM_COUNTERS   6
+
 /* PMU Counter MSRs. */
 static const u32 AMD_F10H_COUNTERS[] = {
     MSR_K7_PERFCTR0,
@@ -83,12 +83,14 @@ static const u32 AMD_F15H_CTRLS[] = {
     MSR_AMD_FAM15H_EVNTSEL5
 };
 
-/* storage for context switching */
-struct amd_vpmu_context {
-    u64 counters[MAX_NUM_COUNTERS];
-    u64 ctrls[MAX_NUM_COUNTERS];
-    bool_t msr_bitmap_set;
-};
+/* Use private context as a flag for MSR bitmap */
+#define msr_bitmap_on(vpmu)    do {                                    \
+                                   (vpmu)->priv_context = (void *)-1L; \
+                               } while (0)
+#define msr_bitmap_off(vpmu)   do {                                    \
+                                   (vpmu)->priv_context = NULL;        \
+                               } while (0)
+#define is_msr_bitmap_on(vpmu) ((vpmu)->priv_context != NULL)
 
 static inline int get_pmu_reg_type(u32 addr)
 {
@@ -142,7 +144,6 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
 {
     unsigned int i;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
 
     for ( i = 0; i < num_counters; i++ )
     {
@@ -150,14 +151,13 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
         svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_WRITE);
     }
 
-    ctxt->msr_bitmap_set = 1;
+    msr_bitmap_on(vpmu);
 }
 
 static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
 {
     unsigned int i;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
 
     for ( i = 0; i < num_counters; i++ )
     {
@@ -165,7 +165,7 @@ static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
         svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_RW);
     }
 
-    ctxt->msr_bitmap_set = 0;
+    msr_bitmap_off(vpmu);
 }
 
 static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
@@ -177,19 +177,22 @@ static inline void context_load(struct vcpu *v)
 {
     unsigned int i;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
+    struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+    uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
+    uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
     for ( i = 0; i < num_counters; i++ )
     {
-        wrmsrl(counters[i], ctxt->counters[i]);
-        wrmsrl(ctrls[i], ctxt->ctrls[i]);
+        wrmsrl(counters[i], counter_regs[i]);
+        wrmsrl(ctrls[i], ctrl_regs[i]);
     }
 }
 
 static void amd_vpmu_load(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
+    struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+    uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
     vpmu_reset(vpmu, VPMU_FROZEN);
 
@@ -198,7 +201,7 @@ static void amd_vpmu_load(struct vcpu *v)
         unsigned int i;
 
         for ( i = 0; i < num_counters; i++ )
-            wrmsrl(ctrls[i], ctxt->ctrls[i]);
+            wrmsrl(ctrls[i], ctrl_regs[i]);
 
         return;
     }
@@ -212,17 +215,17 @@ static inline void context_save(struct vcpu *v)
 {
     unsigned int i;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
+    struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+    uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
 
     /* No need to save controls -- they are saved in amd_vpmu_do_wrmsr */
     for ( i = 0; i < num_counters; i++ )
-        rdmsrl(counters[i], ctxt->counters[i]);
+        rdmsrl(counters[i], counter_regs[i]);
 }
 
 static int amd_vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctx = vpmu->context;
     unsigned int i;
 
     /*
@@ -245,7 +248,7 @@ static int amd_vpmu_save(struct vcpu *v)
     context_save(v);
 
     if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
-         has_hvm_container_vcpu(v) && ctx->msr_bitmap_set )
+         has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
         amd_vpmu_unset_msr_bitmap(v);
 
     return 1;
@@ -256,7 +259,9 @@ static void context_update(unsigned int msr, u64 msr_content)
     unsigned int i;
     struct vcpu *v = current;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct amd_vpmu_context *ctxt = vpmu->context;
+    struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+    uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
+    uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
     if ( k7_counters_mirrored &&
         ((msr >= MSR_K7_EVNTSEL0) && (msr <= MSR_K7_PERFCTR3)) )
@@ -268,12 +273,12 @@ static void context_update(unsigned int msr, u64 msr_content)
     {
        if ( msr == ctrls[i] )
        {
-           ctxt->ctrls[i] = msr_content;
+           ctrl_regs[i] = msr_content;
            return;
        }
         else if (msr == counters[i] )
         {
-            ctxt->counters[i] = msr_content;
+            counter_regs[i] = msr_content;
             return;
         }
     }
@@ -303,8 +308,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
             return 1;
         vpmu_set(vpmu, VPMU_RUNNING);
 
-        if ( has_hvm_container_vcpu(v) &&
-             !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+        if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
              amd_vpmu_set_msr_bitmap(v);
     }
 
@@ -313,8 +317,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         (is_pmu_enabled(msr_content) == 0) && vpmu_is_set(vpmu, VPMU_RUNNING) )
     {
         vpmu_reset(vpmu, VPMU_RUNNING);
-        if ( has_hvm_container_vcpu(v) &&
-             ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+        if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
              amd_vpmu_unset_msr_bitmap(v);
         release_pmu_ownship(PMU_OWNER_HVM);
     }
@@ -355,7 +358,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
 
 static int amd_vpmu_initialise(struct vcpu *v)
 {
-    struct amd_vpmu_context *ctxt;
+    struct xen_pmu_amd_ctxt *ctxt;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t family = current_cpu_data.x86;
 
@@ -385,7 +388,8 @@ static int amd_vpmu_initialise(struct vcpu *v)
 	 }
     }
 
-    ctxt = xzalloc(struct amd_vpmu_context);
+    ctxt = xzalloc_bytes(sizeof(*ctxt) +
+                         2 * sizeof(uint64_t) * num_counters);
     if ( !ctxt )
     {
         gdprintk(XENLOG_WARNING, "Insufficient memory for PMU, "
@@ -394,7 +398,11 @@ static int amd_vpmu_initialise(struct vcpu *v)
         return -ENOMEM;
     }
 
+    ctxt->counters = sizeof(*ctxt);
+    ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
+
     vpmu->context = ctxt;
+    vpmu->priv_context = NULL;
     vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
     return 0;
 }
@@ -406,8 +414,7 @@ static void amd_vpmu_destroy(struct vcpu *v)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
-    if ( has_hvm_container_vcpu(v) &&
-         ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+    if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
         amd_vpmu_unset_msr_bitmap(v);
 
     xfree(vpmu->context);
@@ -424,7 +431,9 @@ static void amd_vpmu_destroy(struct vcpu *v)
 static void amd_vpmu_dump(const struct vcpu *v)
 {
     const struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    const struct amd_vpmu_context *ctxt = vpmu->context;
+    const struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+    const uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
+    const uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
     unsigned int i;
 
     printk("    VPMU state: 0x%x ", vpmu->flags);
@@ -454,8 +463,8 @@ static void amd_vpmu_dump(const struct vcpu *v)
         rdmsrl(ctrls[i], ctrl);
         rdmsrl(counters[i], cntr);
         printk("      %#x: %#lx (%#lx in HW)    %#x: %#lx (%#lx in HW)\n",
-               ctrls[i], ctxt->ctrls[i], ctrl,
-               counters[i], ctxt->counters[i], cntr);
+               ctrls[i], ctrl_regs[i], ctrl,
+               counters[i], counter_regs[i], cntr);
     }
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index e7fffcf..a6cca38 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -35,8 +35,8 @@
 #include <asm/hvm/vmx/vmcs.h>
 #include <public/sched.h>
 #include <public/hvm/save.h>
+#include <public/pmu.h>
 #include <asm/hvm/vpmu.h>
-#include <asm/hvm/vmx/vpmu_core2.h>
 
 /*
  * See Intel SDM Vol 2a Instruction Set Reference chapter 3 for CPUID
@@ -68,6 +68,10 @@
 #define MSR_PMC_ALIAS_MASK       (~(MSR_IA32_PERFCTR0 ^ MSR_IA32_A_PERFCTR0))
 static bool_t __read_mostly full_width_write;
 
+/* Intel-specific VPMU features */
+#define VPMU_CPU_HAS_DS                     0x100 /* Has Debug Store */
+#define VPMU_CPU_HAS_BTS                    0x200 /* Has Branch Trace Store */
+
 /*
  * MSR_CORE_PERF_FIXED_CTR_CTRL contains the configuration of all fixed
  * counters. 4 bits for every counter.
@@ -75,17 +79,6 @@ static bool_t __read_mostly full_width_write;
 #define FIXED_CTR_CTRL_BITS 4
 #define FIXED_CTR_CTRL_MASK ((1 << FIXED_CTR_CTRL_BITS) - 1)
 
-#define VPMU_CORE2_MAX_FIXED_PMCS     4
-struct core2_vpmu_context {
-    u64 fixed_ctrl;
-    u64 ds_area;
-    u64 pebs_enable;
-    u64 global_ovf_status;
-    u64 enabled_cntrs;  /* Follows PERF_GLOBAL_CTRL MSR format */
-    u64 fix_counters[VPMU_CORE2_MAX_FIXED_PMCS];
-    struct arch_msr_pair arch_msr_pair[1];
-};
-
 /* Number of general-purpose and fixed performance counters */
 static unsigned int __read_mostly arch_pmc_cnt, fixed_pmc_cnt;
 
@@ -222,6 +215,12 @@ static int is_core2_vpmu_msr(u32 msr_index, int *type, int *index)
     }
 }
 
+static inline int msraddr_to_bitpos(int x)
+{
+    ASSERT(x == (x & 0x1fff));
+    return x;
+}
+
 static void core2_vpmu_set_msr_bitmap(unsigned long *msr_bitmap)
 {
     int i;
@@ -291,12 +290,15 @@ static void core2_vpmu_unset_msr_bitmap(unsigned long *msr_bitmap)
 static inline void __core2_vpmu_save(struct vcpu *v)
 {
     int i;
-    struct core2_vpmu_context *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    uint64_t *fixed_counters = vpmu_reg_pointer(core2_vpmu_cxt, fixed_counters);
+    struct xen_pmu_cntr_pair *xen_pmu_cntr_pair =
+        vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
 
     for ( i = 0; i < fixed_pmc_cnt; i++ )
-        rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, core2_vpmu_cxt->fix_counters[i]);
+        rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, fixed_counters[i]);
     for ( i = 0; i < arch_pmc_cnt; i++ )
-        rdmsrl(MSR_IA32_PERFCTR0 + i, core2_vpmu_cxt->arch_msr_pair[i].counter);
+        rdmsrl(MSR_IA32_PERFCTR0 + i, xen_pmu_cntr_pair[i].counter);
 }
 
 static int core2_vpmu_save(struct vcpu *v)
@@ -319,10 +321,13 @@ static int core2_vpmu_save(struct vcpu *v)
 static inline void __core2_vpmu_load(struct vcpu *v)
 {
     unsigned int i, pmc_start;
-    struct core2_vpmu_context *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    uint64_t *fixed_counters = vpmu_reg_pointer(core2_vpmu_cxt, fixed_counters);
+    struct xen_pmu_cntr_pair *xen_pmu_cntr_pair =
+        vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
 
     for ( i = 0; i < fixed_pmc_cnt; i++ )
-        wrmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, core2_vpmu_cxt->fix_counters[i]);
+        wrmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, fixed_counters[i]);
 
     if ( full_width_write )
         pmc_start = MSR_IA32_A_PERFCTR0;
@@ -330,8 +335,8 @@ static inline void __core2_vpmu_load(struct vcpu *v)
         pmc_start = MSR_IA32_PERFCTR0;
     for ( i = 0; i < arch_pmc_cnt; i++ )
     {
-        wrmsrl(pmc_start + i, core2_vpmu_cxt->arch_msr_pair[i].counter);
-        wrmsrl(MSR_P6_EVNTSEL(i), core2_vpmu_cxt->arch_msr_pair[i].control);
+        wrmsrl(pmc_start + i, xen_pmu_cntr_pair[i].counter);
+        wrmsrl(MSR_P6_EVNTSEL(i), xen_pmu_cntr_pair[i].control);
     }
 
     wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
@@ -354,7 +359,8 @@ static void core2_vpmu_load(struct vcpu *v)
 static int core2_vpmu_alloc_resource(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct core2_vpmu_context *core2_vpmu_cxt;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = NULL;
+    uint64_t *p = NULL;
 
     if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
         return 0;
@@ -367,12 +373,20 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
         goto out_err;
     vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
 
-    core2_vpmu_cxt = xzalloc_bytes(sizeof(struct core2_vpmu_context) +
-                    (arch_pmc_cnt-1)*sizeof(struct arch_msr_pair));
-    if ( !core2_vpmu_cxt )
+    core2_vpmu_cxt = xzalloc_bytes(sizeof(*core2_vpmu_cxt) +
+                                   sizeof(uint64_t) * fixed_pmc_cnt +
+                                   sizeof(struct xen_pmu_cntr_pair) *
+                                   arch_pmc_cnt);
+    p = xzalloc(uint64_t);
+    if ( !core2_vpmu_cxt || !p )
         goto out_err;
 
-    vpmu->context = (void *)core2_vpmu_cxt;
+    core2_vpmu_cxt->fixed_counters = sizeof(*core2_vpmu_cxt);
+    core2_vpmu_cxt->arch_counters = core2_vpmu_cxt->fixed_counters +
+                                    sizeof(uint64_t) * fixed_pmc_cnt;
+
+    vpmu->context = core2_vpmu_cxt;
+    vpmu->priv_context = p;
 
     vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
 
@@ -381,6 +395,9 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
 out_err:
     release_pmu_ownship(PMU_OWNER_HVM);
 
+    xfree(core2_vpmu_cxt);
+    xfree(p);
+
     printk("Failed to allocate VPMU resources for domain %u vcpu %u\n",
            v->vcpu_id, v->domain->domain_id);
 
@@ -418,7 +435,8 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     int type = -1, index = -1;
     struct vcpu *v = current;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct core2_vpmu_context *core2_vpmu_cxt = NULL;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt;
+    uint64_t *enabled_cntrs;
 
     if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
     {
@@ -446,10 +464,11 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     ASSERT(!supported);
 
     core2_vpmu_cxt = vpmu->context;
+    enabled_cntrs = vpmu->priv_context;
     switch ( msr )
     {
     case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
-        core2_vpmu_cxt->global_ovf_status &= ~msr_content;
+        core2_vpmu_cxt->global_status &= ~msr_content;
         return 1;
     case MSR_CORE_PERF_GLOBAL_STATUS:
         gdprintk(XENLOG_INFO, "Can not write readonly MSR: "
@@ -483,15 +502,14 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         break;
     case MSR_CORE_PERF_FIXED_CTR_CTRL:
         vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
-        core2_vpmu_cxt->enabled_cntrs &=
-                ~(((1ULL << VPMU_CORE2_MAX_FIXED_PMCS) - 1) << 32);
+        *enabled_cntrs &= ~(((1ULL << fixed_pmc_cnt) - 1) << 32);
         if ( msr_content != 0 )
         {
             u64 val = msr_content;
             for ( i = 0; i < fixed_pmc_cnt; i++ )
             {
                 if ( val & 3 )
-                    core2_vpmu_cxt->enabled_cntrs |= (1ULL << 32) << i;
+                    *enabled_cntrs |= (1ULL << 32) << i;
                 val >>= FIXED_CTR_CTRL_BITS;
             }
         }
@@ -502,19 +520,21 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         tmp = msr - MSR_P6_EVNTSEL(0);
         if ( tmp >= 0 && tmp < arch_pmc_cnt )
         {
+            struct xen_pmu_cntr_pair *xen_pmu_cntr_pair =
+                vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
+
             vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
 
             if ( msr_content & (1ULL << 22) )
-                core2_vpmu_cxt->enabled_cntrs |= 1ULL << tmp;
+                *enabled_cntrs |= 1ULL << tmp;
             else
-                core2_vpmu_cxt->enabled_cntrs &= ~(1ULL << tmp);
+                *enabled_cntrs &= ~(1ULL << tmp);
 
-            core2_vpmu_cxt->arch_msr_pair[tmp].control = msr_content;
+            xen_pmu_cntr_pair[tmp].control = msr_content;
         }
     }
 
-    if ( (global_ctrl & core2_vpmu_cxt->enabled_cntrs) ||
-         (core2_vpmu_cxt->ds_area != 0)  )
+    if ( (global_ctrl & *enabled_cntrs) || (core2_vpmu_cxt->ds_area != 0) )
         vpmu_set(vpmu, VPMU_RUNNING);
     else
         vpmu_reset(vpmu, VPMU_RUNNING);
@@ -560,7 +580,7 @@ static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
     int type = -1, index = -1;
     struct vcpu *v = current;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct core2_vpmu_context *core2_vpmu_cxt = NULL;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt;
 
     if ( core2_vpmu_msr_common_check(msr, &type, &index) )
     {
@@ -571,7 +591,7 @@ static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
             *msr_content = 0;
             break;
         case MSR_CORE_PERF_GLOBAL_STATUS:
-            *msr_content = core2_vpmu_cxt->global_ovf_status;
+            *msr_content = core2_vpmu_cxt->global_status;
             break;
         case MSR_CORE_PERF_GLOBAL_CTRL:
             vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
@@ -620,10 +640,12 @@ static void core2_vpmu_dump(const struct vcpu *v)
 {
     const struct vpmu_struct *vpmu = vcpu_vpmu(v);
     unsigned int i;
-    const struct core2_vpmu_context *core2_vpmu_cxt = NULL;
+    const struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vpmu->context;
     u64 val;
+    uint64_t *fixed_counters;
+    struct xen_pmu_cntr_pair *cntr_pair;
 
-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
+    if ( !core2_vpmu_cxt || !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
          return;
 
     if ( !vpmu_is_set(vpmu, VPMU_RUNNING) )
@@ -636,16 +658,15 @@ static void core2_vpmu_dump(const struct vcpu *v)
     }
 
     printk("    vPMU running\n");
-    core2_vpmu_cxt = vpmu->context;
+
+    cntr_pair = vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
+    fixed_counters = vpmu_reg_pointer(core2_vpmu_cxt, fixed_counters);
 
     /* Print the contents of the counter and its configuration msr. */
     for ( i = 0; i < arch_pmc_cnt; i++ )
-    {
-        const struct arch_msr_pair *msr_pair = core2_vpmu_cxt->arch_msr_pair;
-
         printk("      general_%d: 0x%016lx ctrl: 0x%016lx\n",
-               i, msr_pair[i].counter, msr_pair[i].control);
-    }
+            i, cntr_pair[i].counter, cntr_pair[i].control);
+
     /*
      * The configuration of the fixed counter is 4 bits each in the
      * MSR_CORE_PERF_FIXED_CTR_CTRL.
@@ -654,7 +675,7 @@ static void core2_vpmu_dump(const struct vcpu *v)
     for ( i = 0; i < fixed_pmc_cnt; i++ )
     {
         printk("      fixed_%d:   0x%016lx ctrl: %#lx\n",
-               i, core2_vpmu_cxt->fix_counters[i],
+               i, fixed_counters[i],
                val & FIXED_CTR_CTRL_MASK);
         val >>= FIXED_CTR_CTRL_BITS;
     }
@@ -665,14 +686,14 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
     struct vcpu *v = current;
     u64 msr_content;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct core2_vpmu_context *core2_vpmu_cxt = vpmu->context;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vpmu->context;
 
     rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content);
     if ( msr_content )
     {
         if ( is_pmc_quirk )
             handle_pmc_quirk(msr_content);
-        core2_vpmu_cxt->global_ovf_status |= msr_content;
+        core2_vpmu_cxt->global_status |= msr_content;
         msr_content = 0xC000000700000000 | ((1 << arch_pmc_cnt) - 1);
         wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
     }
@@ -739,13 +760,6 @@ static int core2_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
 
     arch_pmc_cnt = core2_get_arch_pmc_count();
     fixed_pmc_cnt = core2_get_fixed_pmc_count();
-    if ( fixed_pmc_cnt > VPMU_CORE2_MAX_FIXED_PMCS )
-    {
-        fixed_pmc_cnt = VPMU_CORE2_MAX_FIXED_PMCS;
-        printk(XENLOG_G_WARNING "Limiting number of fixed counters to %d\n",
-               fixed_pmc_cnt);
-    }
-
     check_pmc_quirk();
     return 0;
 }
@@ -758,6 +772,7 @@ static void core2_vpmu_destroy(struct vcpu *v)
         return;
 
     xfree(vpmu->context);
+    xfree(vpmu->priv_context);
     if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
     release_pmu_ownship(PMU_OWNER_HVM);
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 29d9fde..f96b530 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -31,6 +31,13 @@
 #include <asm/hvm/svm/svm.h>
 #include <asm/hvm/svm/vmcb.h>
 #include <asm/apic.h>
+#include <public/pmu.h>
+
+#include <compat/pmu.h>
+CHECK_pmu_intel_ctxt;
+CHECK_pmu_amd_ctxt;
+CHECK_pmu_cntr_pair;
+CHECK_pmu_regs;
 
 /*
  * "vpmu" :     vpmu generally enabled
@@ -226,6 +233,9 @@ void vpmu_initialise(struct vcpu *v)
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t vendor = current_cpu_data.x86_vendor;
 
+    BUILD_BUG_ON(sizeof(struct xen_pmu_intel_ctxt) > XENPMU_CTXT_PAD_SZ);
+    BUILD_BUG_ON(sizeof(struct xen_pmu_amd_ctxt) > XENPMU_CTXT_PAD_SZ);
+
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         vpmu_destroy(v);
     vpmu_clear(vpmu);
diff --git a/xen/arch/x86/oprofile/op_model_ppro.c b/xen/arch/x86/oprofile/op_model_ppro.c
index aa99e4d..ca429a1 100644
--- a/xen/arch/x86/oprofile/op_model_ppro.c
+++ b/xen/arch/x86/oprofile/op_model_ppro.c
@@ -20,11 +20,15 @@
 #include <asm/regs.h>
 #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"
 
+struct arch_msr_pair {
+    u64 counter;
+    u64 control;
+};
+
 /*
  * Intel "Architectural Performance Monitoring" CPUID
  * detection/enumeration details:
diff --git a/xen/include/Makefile b/xen/include/Makefile
index f7ccbc9..f97733a 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -26,7 +26,9 @@ headers-y := \
 headers-$(CONFIG_X86)     += compat/arch-x86/xen-mca.h
 headers-$(CONFIG_X86)     += compat/arch-x86/xen.h
 headers-$(CONFIG_X86)     += compat/arch-x86/xen-$(compat-arch-y).h
+headers-$(CONFIG_X86)     += compat/arch-x86/pmu.h
 headers-y                 += compat/arch-$(compat-arch-y).h compat/xlat.h
+headers-y                 += compat/pmu.h
 headers-$(FLASK_ENABLE)   += compat/xsm/flask_op.h
 
 cppflags-y                := -include public/xen-compat.h
diff --git a/xen/include/asm-x86/hvm/vmx/vpmu_core2.h b/xen/include/asm-x86/hvm/vmx/vpmu_core2.h
deleted file mode 100644
index 410372d..0000000
--- a/xen/include/asm-x86/hvm/vmx/vpmu_core2.h
+++ /dev/null
@@ -1,32 +0,0 @@
-
-/*
- * vpmu_core2.h: CORE 2 specific PMU virtualization for HVM domain.
- *
- * Copyright (c) 2007, Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
- * Place - Suite 330, Boston, MA 02111-1307 USA.
- *
- * Author: Haitao Shan <haitao.shan@intel.com>
- */
-
-#ifndef __ASM_X86_HVM_VPMU_CORE_H_
-#define __ASM_X86_HVM_VPMU_CORE_H_
-
-struct arch_msr_pair {
-    u64 counter;
-    u64 control;
-};
-
-#endif /* __ASM_X86_HVM_VPMU_CORE_H_ */
-
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 9c4e65a..83eea7e 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -22,6 +22,8 @@
 #ifndef __ASM_X86_HVM_VPMU_H_
 #define __ASM_X86_HVM_VPMU_H_
 
+#include <public/pmu.h>
+
 /*
  * Flag bits given as a string on the hypervisor boot parameter 'vpmu'.
  * See arch/x86/hvm/vpmu.c.
@@ -29,12 +31,9 @@
 #define VPMU_BOOT_ENABLED 0x1    /* vpmu generally enabled. */
 #define VPMU_BOOT_BTS     0x2    /* Intel BTS feature wanted. */
 
-
-#define msraddr_to_bitpos(x) (((x)&0xffff) + ((x)>>31)*0x2000)
 #define vcpu_vpmu(vcpu)   (&((vcpu)->arch.hvm_vcpu.vpmu))
 #define vpmu_vcpu(vpmu)   (container_of((vpmu), struct vcpu, \
                                           arch.hvm_vcpu.vpmu))
-#define vpmu_domain(vpmu) (vpmu_vcpu(vpmu)->domain)
 
 #define MSR_TYPE_COUNTER            0
 #define MSR_TYPE_CTRL               1
@@ -42,6 +41,9 @@
 #define MSR_TYPE_ARCH_COUNTER       3
 #define MSR_TYPE_ARCH_CTRL          4
 
+/* Start of PMU register bank */
+#define vpmu_reg_pointer(ctxt, offset) ((void *)((uintptr_t)ctxt + \
+                                                 (uintptr_t)ctxt->offset))
 
 /* Arch specific operations shared by all vpmus */
 struct arch_vpmu_ops {
@@ -65,7 +67,8 @@ struct vpmu_struct {
     u32 flags;
     u32 last_pcpu;
     u32 hw_lapic_lvtpc;
-    void *context;
+    void *context;      /* May be shared with PV guest */
+    void *priv_context; /* hypervisor-only */
     struct arch_vpmu_ops *arch_vpmu_ops;
 };
 
@@ -77,11 +80,6 @@ struct vpmu_struct {
 #define VPMU_FROZEN                         0x10  /* Stop counters while VCPU is not running */
 #define VPMU_PASSIVE_DOMAIN_ALLOCATED       0x20
 
-/* VPMU features */
-#define VPMU_CPU_HAS_DS                     0x100 /* Has Debug Store */
-#define VPMU_CPU_HAS_BTS                    0x200 /* Has Branch Trace Store */
-
-
 static inline void vpmu_set(struct vpmu_struct *vpmu, const u32 mask)
 {
     vpmu->flags |= mask;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e711606..f694369 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -423,6 +423,9 @@ typedef uint64_t xen_callback_t;
 
 #endif
 
+/* Stub definition of PMU structure */
+typedef struct xen_pmu_arch {} xen_pmu_arch_t;
+
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
 
 /*
diff --git a/xen/include/public/arch-x86/pmu.h b/xen/include/public/arch-x86/pmu.h
new file mode 100644
index 0000000..b0f9100
--- /dev/null
+++ b/xen/include/public/arch-x86/pmu.h
@@ -0,0 +1,90 @@
+#ifndef __XEN_PUBLIC_ARCH_X86_PMU_H__
+#define __XEN_PUBLIC_ARCH_X86_PMU_H__
+
+/* x86-specific PMU definitions */
+
+/* AMD PMU registers and structures */
+struct xen_pmu_amd_ctxt {
+    /* Offsets to counter and control MSRs (relative to xen_pmu_arch.c.amd) */
+    uint32_t counters;
+    uint32_t ctrls;
+};
+typedef struct xen_pmu_amd_ctxt xen_pmu_amd_ctxt_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_amd_ctxt_t);
+
+/* Intel PMU registers and structures */
+struct xen_pmu_cntr_pair {
+    uint64_t counter;
+    uint64_t control;
+};
+typedef struct xen_pmu_cntr_pair xen_pmu_cntr_pair_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_cntr_pair_t);
+
+struct xen_pmu_intel_ctxt {
+    uint64_t global_ctrl;
+    uint64_t global_ovf_ctrl;
+    uint64_t global_status;
+    uint64_t fixed_ctrl;
+    uint64_t ds_area;
+    uint64_t pebs_enable;
+    uint64_t debugctl;
+    /*
+     * Offsets to fixed and architectural counter MSRs (relative to
+     * xen_pmu_arch.c.intel)
+     */
+    uint32_t fixed_counters;
+    uint32_t arch_counters;
+};
+typedef struct xen_pmu_intel_ctxt xen_pmu_intel_ctxt_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_intel_ctxt_t);
+
+/* Sampled domain's registers */
+struct xen_pmu_regs {
+    uint64_t ip;
+    uint64_t sp;
+    uint64_t flags;
+    uint16_t cs;
+    uint16_t ss;
+    uint32_t pad;
+};
+typedef struct xen_pmu_regs xen_pmu_regs_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_regs_t);
+
+struct xen_pmu_arch {
+    union {
+        struct xen_pmu_regs regs;
+        /* Padding for adding new registers to xen_pmu_regs in the future */
+#define XENPMU_REGS_PAD_SZ  64
+        uint8_t pad[XENPMU_REGS_PAD_SZ];
+    } r;
+    uint64_t pmu_flags;
+    union {
+        uint32_t lapic_lvtpc;
+        uint64_t pad;
+    } l;
+    union {
+        struct xen_pmu_amd_ctxt amd;
+        struct xen_pmu_intel_ctxt intel;
+
+        /*
+         * Padding for contexts (fixed parts only, does not include MSR banks
+         * that are specified by offsets
+         */
+#define XENPMU_CTXT_PAD_SZ  128
+        uint8_t pad[XENPMU_CTXT_PAD_SZ];
+    } c;
+};
+typedef struct xen_pmu_arch xen_pmu_arch_t;
+DEFINE_XEN_GUEST_HANDLE(xen_pmu_arch_t);
+
+#endif /* __XEN_PUBLIC_ARCH_X86_PMU_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/include/public/pmu.h b/xen/include/public/pmu.h
new file mode 100644
index 0000000..f97106d
--- /dev/null
+++ b/xen/include/public/pmu.h
@@ -0,0 +1,38 @@
+#ifndef __XEN_PUBLIC_PMU_H__
+#define __XEN_PUBLIC_PMU_H__
+
+#include "xen.h"
+#if defined(__i386__) || defined(__x86_64__)
+#include "arch-x86/pmu.h"
+#elif defined (__arm__) || defined (__aarch64__)
+#include "arch-arm.h"
+#else
+#error "Unsupported architecture"
+#endif
+
+#define XENPMU_VER_MAJ    0
+#define XENPMU_VER_MIN    1
+
+
+/* Shared between hypervisor and PV domain */
+struct xen_pmu_data {
+    uint32_t domain_id;
+    uint32_t vcpu_id;
+    uint32_t pcpu_id;
+
+    uint32_t pad;
+
+    xen_pmu_arch_t pmu;
+};
+
+#endif /* __XEN_PUBLIC_PMU_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index eb40aab..8bff86d 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -103,6 +103,10 @@
 !	vcpu_set_singleshot_timer	vcpu.h
 ?	xenoprof_init			xenoprof.h
 ?	xenoprof_passive		xenoprof.h
+?	pmu_intel_ctxt			arch-x86/pmu.h
+?	pmu_amd_ctxt			arch-x86/pmu.h
+?	pmu_cntr_pair			arch-x86/pmu.h
+?	pmu_regs			arch-x86/pmu.h
 ?	flask_access			xsm/flask_op.h
 !	flask_boolean			xsm/flask_op.h
 ?	flask_cache_stats		xsm/flask_op.h
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Z-0000qm-Lu; Sun, 16 Nov 2014 23:17:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94Y-0000pB-2d
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:34 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	94/25-19763-D8039645; Sun, 16 Nov 2014 23:17:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416179851!6372086!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26561 invoked from network); 16 Nov 2014 23:17:32 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Nov 2014 23:17:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHPDZ007716
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:26 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHO83016521
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:25 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHOkn007493; Sun, 16 Nov 2014 23:17:24 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:23 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:40 -0500
Message-Id: <1416179271-1221-11-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 10/21] x86/VPMU: Make vpmu not HVM-specific
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

vpmu structure will be used for both HVM and PV guests. Move it from
hvm_vcpu to arch_vcpu.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/include/asm-x86/domain.h   | 2 ++
 xen/include/asm-x86/hvm/vcpu.h | 3 ---
 xen/include/asm-x86/hvm/vpmu.h | 5 ++---
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 6a77a93..be4d1dc 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -426,6 +426,8 @@ struct arch_vcpu
     void (*ctxt_switch_from) (struct vcpu *);
     void (*ctxt_switch_to) (struct vcpu *);
 
+    struct vpmu_struct vpmu;
+
     /* Virtual Machine Extensions */
     union {
         struct pv_vcpu pv_vcpu;
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..71a5b15 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -151,9 +151,6 @@ struct hvm_vcpu {
     u32                 msr_tsc_aux;
     u64                 msr_tsc_adjust;
 
-    /* VPMU */
-    struct vpmu_struct  vpmu;
-
     union {
         struct arch_vmx_struct vmx;
         struct arch_svm_struct svm;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 83eea7e..82bfa0e 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -31,9 +31,8 @@
 #define VPMU_BOOT_ENABLED 0x1    /* vpmu generally enabled. */
 #define VPMU_BOOT_BTS     0x2    /* Intel BTS feature wanted. */
 
-#define vcpu_vpmu(vcpu)   (&((vcpu)->arch.hvm_vcpu.vpmu))
-#define vpmu_vcpu(vpmu)   (container_of((vpmu), struct vcpu, \
-                                          arch.hvm_vcpu.vpmu))
+#define vcpu_vpmu(vcpu)   (&(vcpu)->arch.vpmu)
+#define vpmu_vcpu(vpmu)   container_of((vpmu), struct vcpu, arch.vpmu)
 
 #define MSR_TYPE_COUNTER            0
 #define MSR_TYPE_CTRL               1
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94j-00012c-2D; Sun, 16 Nov 2014 23:17:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94h-0000yc-1M
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FC/AB-09936-69039645; Sun, 16 Nov 2014 23:17:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416179859!13180247!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10315 invoked from network); 16 Nov 2014 23:17:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:40 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHXJi007761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:34 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHXtd007687
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 16 Nov 2014 23:17:33 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAGNHVWT016684; Sun, 16 Nov 2014 23:17:32 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:31 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:48 -0500
Message-Id: <1416179271-1221-19-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 18/21] x86/VPMU: Merge vpmu_rdmsr and
	vpmu_wrmsr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 two routines share most of their logic.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vpmu.c        | 69 +++++++++++++++++-------------------------
 xen/include/asm-x86/hvm/vpmu.h | 14 +++++++--
 2 files changed, 39 insertions(+), 44 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 6a71d53..aa4a5d9 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -91,57 +91,42 @@ void vpmu_lvtpc_update(uint32_t val)
         apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
 
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+                uint64_t supported, bool_t is_write)
 {
-    struct vcpu *curr = current;
-    struct vpmu_struct *vpmu = vcpu_vpmu(curr);
+    struct vcpu *curr;
+    struct vpmu_struct *vpmu;
+    struct arch_vpmu_ops *ops;
+    int ret = 0;
 
     if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
         return 0;
 
-    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
-    {
-        int ret = vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
-
-        /*
-         * We may have received a PMU interrupt during WRMSR handling
-         * and since do_wrmsr may load VPMU context we should save
-         * (and unload) it again.
-         */
-        if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
-             (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
-        {
-            vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-            vpmu->arch_vpmu_ops->arch_vpmu_save(curr);
-            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-        }
-        return ret;
-    }
-    return 0;
-}
-
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
-{
-    struct vcpu *curr = current;
-    struct vpmu_struct *vpmu = vcpu_vpmu(curr);
-
-    if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+    curr = current;
+    vpmu = vcpu_vpmu(curr);
+    ops = vpmu->arch_vpmu_ops;
+    if ( !ops )
         return 0;
 
-    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
+    if ( is_write && ops->do_wrmsr )
+        ret = ops->do_wrmsr(msr, *msr_content, supported);
+    else if ( !is_write && ops->do_rdmsr )
+        ret = ops->do_rdmsr(msr, msr_content);
+
+    /*
+     * We may have received a PMU interrupt while handling MSR access
+     * and since do_wr/rdmsr may load VPMU context we should save
+     * (and unload) it again.
+     */
+    if ( !is_hvm_vcpu(curr) &&
+         vpmu->xenpmu_data && (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
     {
-        int ret = vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
-
-        if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
-             (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
-        {
-            vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-            vpmu->arch_vpmu_ops->arch_vpmu_save(curr);
-            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-        }
-        return ret;
+        vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+        ops->arch_vpmu_save(curr);
+        vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
     }
-    return 0;
+
+    return ret;
 }
 
 static struct vcpu *choose_hwdom_vcpu(void)
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index ada2ab7..56cc09c 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -99,8 +99,8 @@ static inline bool_t vpmu_are_all_set(const struct vpmu_struct *vpmu,
 }
 
 void vpmu_lvtpc_update(uint32_t val);
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+                uint64_t supported, bool_t is_write);
 void 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);
@@ -110,6 +110,16 @@ void vpmu_save(struct vcpu *v);
 void vpmu_load(struct vcpu *v);
 void vpmu_dump(struct vcpu *v);
 
+static inline int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
+                                uint64_t supported)
+{
+    return vpmu_do_msr(msr, &msr_content, supported, 1);
+}
+static inline int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
+{
+    return vpmu_do_msr(msr, msr_content, 0, 0);
+}
+
 extern int acquire_pmu_ownership(int pmu_ownership);
 extern void release_pmu_ownership(int pmu_ownership);
 
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94f-0000wW-1g; Sun, 16 Nov 2014 23:17:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94c-0000tV-Pn
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	72/A2-09842-29039645; Sun, 16 Nov 2014 23:17:38 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416179855!13161211!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13951 invoked from network); 16 Nov 2014 23:17:37 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:37 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHUok003475
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:30 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHT7j016619
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:29 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHSa2024155; Sun, 16 Nov 2014 23:17:28 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:28 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:45 -0500
Message-Id: <1416179271-1221-16-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 15/21] x86/VPMU: When handling MSR accesses,
	leave fault injection to callers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With this patch return value of 1 of vpmu_do_msr() will now indicate whether an
error was encountered during MSR processing (instead of stating that the access
was to a VPMU register).

As part of this patch we also check for validity of certain MSR accesses right
when we determine which register is being written, as opposed to postponing this
until later.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/svm.c        |  6 ++-
 xen/arch/x86/hvm/svm/vpmu.c       |  6 +--
 xen/arch/x86/hvm/vmx/vmx.c        | 24 +++++++++---
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 78 ++++++++++++++-------------------------
 4 files changed, 53 insertions(+), 61 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b1c4845..d0ba075 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1700,7 +1700,8 @@ static int svm_msr_read_intercept(unsigned int msr, uint64_t *msr_content)
     case MSR_AMD_FAM15H_EVNTSEL3:
     case MSR_AMD_FAM15H_EVNTSEL4:
     case MSR_AMD_FAM15H_EVNTSEL5:
-        vpmu_do_rdmsr(msr, msr_content);
+        if ( vpmu_do_rdmsr(msr, msr_content) )
+            goto gpf;
         break;
 
     case MSR_AMD64_DR0_ADDRESS_MASK:
@@ -1851,7 +1852,8 @@ static int svm_msr_write_intercept(unsigned int msr, uint64_t msr_content)
     case MSR_AMD_FAM15H_EVNTSEL3:
     case MSR_AMD_FAM15H_EVNTSEL4:
     case MSR_AMD_FAM15H_EVNTSEL5:
-        vpmu_do_wrmsr(msr, msr_content, 0);
+        if ( vpmu_do_wrmsr(msr, msr_content, 0) )
+            goto gpf;
         break;
 
     case MSR_IA32_MCx_MISC(4): /* Threshold register */
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index fe852ed..b54a51d 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -305,7 +305,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         is_pmu_enabled(msr_content) && !vpmu_is_set(vpmu, VPMU_RUNNING) )
     {
         if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
-            return 1;
+            return 0;
         vpmu_set(vpmu, VPMU_RUNNING);
 
         if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
@@ -335,7 +335,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
 
     /* Write to hw counters */
     wrmsrl(msr, msr_content);
-    return 1;
+    return 0;
 }
 
 static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
@@ -353,7 +353,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
 
     rdmsrl(msr, *msr_content);
 
-    return 1;
+    return 0;
 }
 
 static void amd_vpmu_destroy(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index a7c3a7a..ef7ce72 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2112,12 +2112,17 @@ static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content)
         *msr_content |= MSR_IA32_MISC_ENABLE_BTS_UNAVAIL |
                        MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL;
         /* Perhaps vpmu will change some bits. */
+        /* FALLTHROUGH */
+    case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+    case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
+    case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+    case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+    case MSR_IA32_PEBS_ENABLE:
+    case MSR_IA32_DS_AREA:
         if ( vpmu_do_rdmsr(msr, msr_content) )
-            goto done;
+            goto gp_fault;
         break;
     default:
-        if ( vpmu_do_rdmsr(msr, msr_content) )
-            break;
         if ( passive_domain_do_rdmsr(msr, msr_content) )
             goto done;
         switch ( long_mode_do_msr_read(msr, msr_content) )
@@ -2293,7 +2298,7 @@ static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content)
         if ( msr_content & ~supported )
         {
             /* Perhaps some other bits are supported in vpmu. */
-            if ( !vpmu_do_wrmsr(msr, msr_content, supported) )
+            if ( vpmu_do_wrmsr(msr, msr_content, supported) )
                 break;
         }
         if ( msr_content & IA32_DEBUGCTLMSR_LBR )
@@ -2321,9 +2326,16 @@ static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content)
         if ( !nvmx_msr_write_intercept(msr, msr_content) )
             goto gp_fault;
         break;
+    case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+    case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(7):
+    case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+    case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+    case MSR_IA32_PEBS_ENABLE:
+    case MSR_IA32_DS_AREA:
+         if ( vpmu_do_wrmsr(msr, msr_content, 0) )
+            goto gp_fault;
+        break;
     default:
-        if ( vpmu_do_wrmsr(msr, msr_content, 0) )
-            return X86EMUL_OKAY;
         if ( passive_domain_do_wrmsr(msr, msr_content) )
             return X86EMUL_OKAY;
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 03dc981..2dd8000 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -463,36 +463,41 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
                              IA32_DEBUGCTLMSR_BTS_OFF_USR;
             if ( !(msr_content & ~supported) &&
                  vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
-                return 1;
+                return 0;
             if ( (msr_content & supported) &&
                  !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
                 printk(XENLOG_G_WARNING
                        "%pv: Debug Store unsupported on this CPU\n",
                        current);
         }
-        return 0;
+        return 1;
     }
 
     ASSERT(!supported);
 
+    if ( type == MSR_TYPE_COUNTER &&
+         (msr_content &
+          ~((1ull << core2_get_bitwidth_fix_count()) - 1)) )
+        /* Writing unsupported bits to a fixed counter */
+        return 1;
+
     core2_vpmu_cxt = vpmu->context;
     enabled_cntrs = vpmu->priv_context;
     switch ( msr )
     {
     case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
         core2_vpmu_cxt->global_status &= ~msr_content;
-        return 1;
+        return 0;
     case MSR_CORE_PERF_GLOBAL_STATUS:
         gdprintk(XENLOG_INFO, "Can not write readonly MSR: "
                  "MSR_PERF_GLOBAL_STATUS(0x38E)!\n");
-        hvm_inject_hw_exception(TRAP_gp_fault, 0);
         return 1;
     case MSR_IA32_PEBS_ENABLE:
         if ( msr_content & 1 )
             gdprintk(XENLOG_WARNING, "Guest is trying to enable PEBS, "
                      "which is not supported.\n");
         core2_vpmu_cxt->pebs_enable = msr_content;
-        return 1;
+        return 0;
     case MSR_IA32_DS_AREA:
         if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
         {
@@ -501,18 +506,21 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
                 gdprintk(XENLOG_WARNING,
                          "Illegal address for IA32_DS_AREA: %#" PRIx64 "x\n",
                          msr_content);
-                hvm_inject_hw_exception(TRAP_gp_fault, 0);
                 return 1;
             }
             core2_vpmu_cxt->ds_area = msr_content;
             break;
         }
         gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
-        return 1;
+        return 0;
     case MSR_CORE_PERF_GLOBAL_CTRL:
         global_ctrl = msr_content;
         break;
     case MSR_CORE_PERF_FIXED_CTR_CTRL:
+        if ( msr_content &
+             ( ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1)) )
+            return 1;
+
         vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
         *enabled_cntrs &= ~(((1ULL << fixed_pmc_cnt) - 1) << 32);
         if ( msr_content != 0 )
@@ -535,6 +543,9 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
             struct xen_pmu_cntr_pair *xen_pmu_cntr_pair =
                 vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
 
+            if ( msr_content & (~((1ull << 32) - 1)) )
+                return 1;
+
             vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
 
             if ( msr_content & (1ULL << 22) )
@@ -546,45 +557,17 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         }
     }
 
+    if ( type != MSR_TYPE_GLOBAL )
+        wrmsrl(msr, msr_content);
+    else
+        vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+
     if ( (global_ctrl & *enabled_cntrs) || (core2_vpmu_cxt->ds_area != 0) )
         vpmu_set(vpmu, VPMU_RUNNING);
     else
         vpmu_reset(vpmu, VPMU_RUNNING);
 
-    if ( type != MSR_TYPE_GLOBAL )
-    {
-        u64 mask;
-        int inject_gp = 0;
-        switch ( type )
-        {
-        case MSR_TYPE_ARCH_CTRL:      /* MSR_P6_EVNTSEL[0,...] */
-            mask = ~((1ull << 32) - 1);
-            if (msr_content & mask)
-                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 << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1);
-            if (msr_content & mask)
-                inject_gp = 1;
-            break;
-        case MSR_TYPE_COUNTER:        /* IA32_FIXED_CTR[0-2] */
-            mask = ~((1ull << core2_get_bitwidth_fix_count()) - 1);
-            if (msr_content & mask)
-                inject_gp = 1;
-            break;
-        }
-        if (inject_gp)
-            hvm_inject_hw_exception(TRAP_gp_fault, 0);
-        else
-            wrmsrl(msr, msr_content);
-    }
-    else
-        vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
-
-    return 1;
+    return 0;
 }
 
 static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
@@ -612,19 +595,14 @@ static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
             rdmsrl(msr, *msr_content);
         }
     }
-    else
+    else if ( msr == MSR_IA32_MISC_ENABLE )
     {
         /* 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;
+        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
+            *msr_content &= ~MSR_IA32_MISC_ENABLE_BTS_UNAVAIL;
     }
 
-    return 1;
+    return 0;
 }
 
 static void core2_vpmu_do_cpuid(unsigned int input,
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Q-0000ln-1z; Sun, 16 Nov 2014 23:17:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94O-0000lX-6z
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:24 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	9C/63-28865-38039645; Sun, 16 Nov 2014 23:17:23 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416179841!7543521!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28389 invoked from network); 16 Nov 2014 23:17:22 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Nov 2014 23:17:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHFLn007643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:15 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHEuo012579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:14 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHECg023727; Sun, 16 Nov 2014 23:17:14 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:13 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:31 -0500
Message-Id: <1416179271-1221-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 01/21] common/symbols: Export hypervisor
	symbols to privileged 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Export Xen's symbols as {<address><type><name>} triplet via new XENPF_get_symbol
hypercall

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/platform_hypercall.c   | 28 +++++++++++++++++++
 xen/common/symbols.c                | 54 +++++++++++++++++++++++++++++++++++++
 xen/include/public/platform.h       | 19 +++++++++++++
 xen/include/xen/symbols.h           |  3 +++
 xen/include/xlat.lst                |  1 +
 xen/xsm/flask/hooks.c               |  4 +++
 xen/xsm/flask/policy/access_vectors |  2 ++
 7 files changed, 111 insertions(+)

diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 32f39b2..7b37960 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -23,6 +23,7 @@
 #include <xen/cpu.h>
 #include <xen/pmstat.h>
 #include <xen/irq.h>
+#include <xen/symbols.h>
 #include <asm/current.h>
 #include <public/platform.h>
 #include <acpi/cpufreq/processor_perf.h>
@@ -760,6 +761,33 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
     }
     break;
 
+    case XENPF_get_symbol:
+    {
+        static char name[KSYM_NAME_LEN + 1]; /* protected by xenpf_lock */
+        XEN_GUEST_HANDLE(char) nameh;
+        uint32_t namelen, copylen;
+
+        guest_from_compat_handle(nameh, op->u.symdata.name);
+
+        ret = xensyms_read(&op->u.symdata.symnum, &op->u.symdata.type,
+                           &op->u.symdata.address, name);
+
+        namelen = strlen(name) + 1;
+
+        if ( namelen > op->u.symdata.namelen )
+            copylen = op->u.symdata.namelen;
+        else
+            copylen = namelen;
+
+        op->u.symdata.namelen = namelen;
+
+        if ( !ret && copy_to_guest(nameh, name, copylen) )
+            ret = -EFAULT;
+        if ( !ret && __copy_field_to_guest(u_xenpf_op, op, u.symdata) )
+            ret = -EFAULT;
+    }
+    break;
+
     default:
         ret = -ENOSYS;
         break;
diff --git a/xen/common/symbols.c b/xen/common/symbols.c
index bc2fde6..2c0942d 100644
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -17,6 +17,8 @@
 #include <xen/lib.h>
 #include <xen/string.h>
 #include <xen/spinlock.h>
+#include <public/platform.h>
+#include <xen/guest_access.h>
 
 #ifdef SYMBOLS_ORIGIN
 extern const unsigned int symbols_offsets[1];
@@ -148,3 +150,55 @@ const char *symbols_lookup(unsigned long addr,
     *offset = addr - symbols_address(low);
     return namebuf;
 }
+
+/*
+ * Get symbol type information. This is encoded as a single char at the
+ * beginning of the symbol name.
+ */
+static char symbols_get_symbol_type(unsigned int off)
+{
+    /*
+     * Get just the first code, look it up in the token table,
+     * and return the first char from this token.
+     */
+    return symbols_token_table[symbols_token_index[symbols_names[off + 1]]];
+}
+
+int xensyms_read(uint32_t *symnum, char *type,
+                 uint64_t *address, char *name)
+{
+    /*
+     * Symbols are most likely accessed sequentially so we remember position
+     * from previous read. This can help us avoid the extra call to
+     * get_symbol_offset().
+     */
+    static uint64_t next_symbol, next_offset;
+    static DEFINE_SPINLOCK(symbols_mutex);
+
+    if ( *symnum > symbols_num_syms )
+        return -ERANGE;
+    if ( *symnum == symbols_num_syms )
+    {
+        /* No more symbols */
+        name[0] = '\0';
+        return 0;
+    }
+
+    spin_lock(&symbols_mutex);
+
+    if ( *symnum == 0 )
+        next_offset = next_symbol = 0;
+    if ( next_symbol != *symnum )
+        /* Non-sequential access */
+        next_offset = get_symbol_offset(*symnum);
+
+    *type = symbols_get_symbol_type(next_offset);
+    next_offset = symbols_expand_symbol(next_offset, name);
+    *address = symbols_offsets[*symnum] + SYMBOLS_ORIGIN;
+
+    next_symbol = ++*symnum;
+
+    spin_unlock(&symbols_mutex);
+
+    return 0;
+}
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 5c57615..6dd7732 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -560,6 +560,24 @@ struct xenpf_resource_op {
 typedef struct xenpf_resource_op xenpf_resource_op_t;
 DEFINE_XEN_GUEST_HANDLE(xenpf_resource_op_t);
 
+#define XENPF_get_symbol   62
+struct xenpf_symdata {
+    /* IN/OUT variables */
+    uint32_t namelen; /* IN:  size of name buffer                       */
+                      /* OUT: strlen(name) of hypervisor symbol (may be */
+                      /*      larger than what's been copied to guest)  */
+    uint32_t symnum;  /* IN:  Symbol to read                            */
+                      /* OUT: Next available symbol. If same as IN then */
+                      /*      we reached the end                        */
+
+    /* OUT variables */
+    XEN_GUEST_HANDLE(char) name;
+    uint64_t address;
+    char type;
+};
+typedef struct xenpf_symdata xenpf_symdata_t;
+DEFINE_XEN_GUEST_HANDLE(xenpf_symdata_t);
+
 /*
  * ` enum neg_errnoval
  * ` HYPERVISOR_platform_op(const struct xen_platform_op*);
@@ -587,6 +605,7 @@ struct xen_platform_op {
         struct xenpf_mem_hotadd        mem_add;
         struct xenpf_core_parking      core_parking;
         struct xenpf_resource_op       resource_op;
+        struct xenpf_symdata           symdata;
         uint8_t                        pad[128];
     } u;
 };
diff --git a/xen/include/xen/symbols.h b/xen/include/xen/symbols.h
index 87cd77d..1fa0537 100644
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -11,4 +11,7 @@ const char *symbols_lookup(unsigned long addr,
                            unsigned long *offset,
                            char *namebuf);
 
+int xensyms_read(uint32_t *symnum, char *type,
+                 uint64_t *address, char *name);
+
 #endif /*_XEN_SYMBOLS_H*/
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 41b3e35..eb40aab 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -87,6 +87,7 @@
 ?	processor_px			platform.h
 !	psd_package			platform.h
 ?	xenpf_enter_acpi_sleep		platform.h
+!	xenpf_symdata			platform.h
 ?	xenpf_pcpuinfo			platform.h
 ?	xenpf_pcpu_version		platform.h
 ?	xenpf_resource_entry		platform.h
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 846cf88..b57b9d3 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1408,6 +1408,10 @@ static int flask_platform_op(uint32_t op)
         return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
                                     XEN2__RESOURCE_OP, NULL);
 
+    case XENPF_get_symbol:
+        return avc_has_perm(domain_sid(current->domain), SECINITSID_XEN,
+                            SECCLASS_XEN2, XEN2__GET_SYMBOL, NULL);
+
     default:
         printk("flask_platform_op: Unknown op %d\n", op);
         return -EPERM;
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index bfe2fa5..69152d6 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -83,6 +83,8 @@ class xen2
     resource_op
 # XEN_SYSCTL_psr_cmt_op
     psr_cmt_op
+# XENPF_get_symbol
+    get_symbol
 }
 
 # Classes domain and domain2 consist of operations that a domain performs on
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94h-0000zx-NV; Sun, 16 Nov 2014 23:17:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94f-0000wh-KU
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	57/A2-09842-49039645; Sun, 16 Nov 2014 23:17:40 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416179858!13124246!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10877 invoked from network); 16 Nov 2014 23:17:39 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHWtu007755
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:33 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHWqF007664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 16 Nov 2014 23:17:32 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAGNHUZb016668; Sun, 16 Nov 2014 23:17:31 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:30 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:47 -0500
Message-Id: <1416179271-1221-18-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 17/21] x86/VPMU: Handle PMU interrupts 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>
MIME-Version: 1.0
Content-Type: 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 support for handling PMU interrupts for PV guests.

VPMU for the interrupted VCPU is unloaded until the guest issues XENPMU_flush
hypercall. This allows the guest to access PMU MSR values that are stored in
VPMU context which is shared between hypervisor and domain, thus avoiding
traps to hypervisor.

Since the interrupt handler may now force VPMU context save (i.e. set
VPMU_CONTEXT_SAVE flag) we need to make changes to amd_vpmu_save() which
until now expected this flag to be set only when the counters were stopped.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       |  11 +--
 xen/arch/x86/hvm/vpmu.c           | 203 +++++++++++++++++++++++++++++++++++---
 xen/include/public/arch-x86/pmu.h |   5 +
 xen/include/public/pmu.h          |   2 +
 xen/include/xsm/dummy.h           |   4 +-
 xen/xsm/flask/hooks.c             |   2 +
 6 files changed, 207 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index b54a51d..7d9ba8c 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -228,17 +228,12 @@ static int amd_vpmu_save(struct vcpu *v)
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     unsigned int i;
 
-    /*
-     * Stop the counters. If we came here via vpmu_save_force (i.e.
-     * when VPMU_CONTEXT_SAVE is set) counters are already stopped.
-     */
+    for ( i = 0; i < num_counters; i++ )
+        wrmsrl(ctrls[i], 0);
+
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_SAVE) )
     {
         vpmu_set(vpmu, VPMU_FROZEN);
-
-        for ( i = 0; i < num_counters; i++ )
-            wrmsrl(ctrls[i], 0);
-
         return 0;
     }
 
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 2ad9832..6a71d53 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -80,46 +80,203 @@ static void __init parse_vpmu_param(char *s)
 
 void vpmu_lvtpc_update(uint32_t val)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+    struct vcpu *curr = current;
+    struct vpmu_struct *vpmu = vcpu_vpmu(curr);
 
     vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
-    apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
+
+    /* Postpone APIC updates for PV(H) guests if PMU interrupt is pending */
+    if ( is_hvm_vcpu(curr) || !vpmu->xenpmu_data ||
+         !(vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
+        apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
 
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+    struct vcpu *curr = current;
+    struct vpmu_struct *vpmu = vcpu_vpmu(curr);
 
     if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
         return 0;
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
-        return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
+    {
+        int ret = vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
+
+        /*
+         * We may have received a PMU interrupt during WRMSR handling
+         * and since do_wrmsr may load VPMU context we should save
+         * (and unload) it again.
+         */
+        if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+             (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
+        {
+            vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+            vpmu->arch_vpmu_ops->arch_vpmu_save(curr);
+            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+        }
+        return ret;
+    }
     return 0;
 }
 
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+    struct vcpu *curr = current;
+    struct vpmu_struct *vpmu = vcpu_vpmu(curr);
 
     if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
         return 0;
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
-        return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
+    {
+        int ret = vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
+
+        if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+             (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
+        {
+            vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+            vpmu->arch_vpmu_ops->arch_vpmu_save(curr);
+            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+        }
+        return ret;
+    }
     return 0;
 }
 
+static struct vcpu *choose_hwdom_vcpu(void)
+{
+    unsigned idx = smp_processor_id() % hardware_domain->max_vcpus;
+
+    if ( hardware_domain->vcpu == NULL )
+        return NULL;
+
+    return hardware_domain->vcpu[idx];
+}
+
 void vpmu_do_interrupt(struct cpu_user_regs *regs)
 {
-    struct vcpu *v = current;
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    struct vcpu *sampled = current, *sampling;
+    struct vpmu_struct *vpmu;
+
+    /* dom0 will handle interrupt for special domains (e.g. idle domain) */
+    if ( sampled->domain->domain_id >= DOMID_FIRST_RESERVED )
+    {
+        sampling = choose_hwdom_vcpu();
+        if ( !sampling )
+            return;
+    }
+    else
+        sampling = sampled;
+
+    vpmu = vcpu_vpmu(sampling);
+    if ( !is_hvm_vcpu(sampling) )
+    {
+        /* PV(H) guest */
+        const struct cpu_user_regs *cur_regs;
+        uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
+        uint32_t domid = DOMID_SELF;
+
+        if ( !vpmu->xenpmu_data )
+            return;
+
+        if ( *flags & PMU_CACHED )
+            return;
+
+        if ( is_pvh_vcpu(sampling) &&
+             !vpmu->arch_vpmu_ops->do_interrupt(regs) )
+            return;
+
+        /* PV guest will be reading PMU MSRs from xenpmu_data */
+        vpmu_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+        vpmu->arch_vpmu_ops->arch_vpmu_save(sampling);
+        vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+
+        *flags = 0;
+
+        /* Store appropriate registers in xenpmu_data */
+        /* FIXME: 32-bit PVH should go here as well */
+        if ( is_pv_32bit_vcpu(sampling) )
+        {
+            /*
+             * 32-bit dom0 cannot process Xen's addresses (which are 64 bit)
+             * and therefore we treat it the same way as a non-privileged
+             * PV 32-bit domain.
+             */
+            struct compat_pmu_regs *cmp;
+
+            cur_regs = guest_cpu_user_regs();
+
+            cmp = (void *)&vpmu->xenpmu_data->pmu.r.regs;
+            cmp->ip = cur_regs->rip;
+            cmp->sp = cur_regs->rsp;
+            cmp->flags = cur_regs->eflags;
+            cmp->ss = cur_regs->ss;
+            cmp->cs = cur_regs->cs;
+            if ( (cmp->cs & 3) != 1 )
+                *flags |= PMU_SAMPLE_USER;
+        }
+        else
+        {
+            struct xen_pmu_regs *r = &vpmu->xenpmu_data->pmu.r.regs;
+
+            if ( (vpmu_mode & XENPMU_MODE_SELF) )
+                cur_regs = guest_cpu_user_regs();
+            else if ( !guest_mode(regs) && is_hardware_domain(sampling->domain) )
+            {
+                cur_regs = regs;
+                domid = DOMID_XEN;
+            }
+            else
+                cur_regs = guest_cpu_user_regs();
+
+            r->ip = cur_regs->rip;
+            r->sp = cur_regs->rsp;
+            r->flags = cur_regs->eflags;
+
+            if ( !has_hvm_container_vcpu(sampled) )
+            {
+                r->ss = cur_regs->ss;
+                r->cs = cur_regs->cs;
+                if ( !(sampled->arch.flags & TF_kernel_mode) )
+                    *flags |= PMU_SAMPLE_USER;
+            }
+            else
+            {
+                struct segment_register seg;
+
+                hvm_get_segment_register(sampled, x86_seg_cs, &seg);
+                r->cs = seg.sel;
+                hvm_get_segment_register(sampled, x86_seg_ss, &seg);
+                r->ss = seg.sel;
+                if ( seg.attr.fields.dpl != 0 )
+                    *flags |= PMU_SAMPLE_USER;
+                if ( !(sampled->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) )
+                    *flags |= PMU_SAMPLE_REAL;
+            }
+        }
+
+        vpmu->xenpmu_data->domain_id = domid;
+        vpmu->xenpmu_data->vcpu_id = sampled->vcpu_id;
+        vpmu->xenpmu_data->pcpu_id = smp_processor_id();
+
+        *flags |= PMU_CACHED;
+        vpmu->hw_lapic_lvtpc |= APIC_LVT_MASKED;
+        apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
+
+        send_guest_vcpu_virq(sampling, VIRQ_XENPMU);
+
+        return;
+    }
 
     if ( vpmu->arch_vpmu_ops )
     {
-        struct vlapic *vlapic = vcpu_vlapic(v);
+        struct vlapic *vlapic = vcpu_vlapic(sampling);
         u32 vlapic_lvtpc;
 
+        /* We don't support (yet) HVM dom0 */
+        ASSERT(sampling == sampled);
+
         if ( !vpmu->arch_vpmu_ops->do_interrupt(regs) ||
              !is_vlapic_lvtpc_enabled(vlapic) )
             return;
@@ -132,7 +289,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
             vlapic_set_irq(vlapic, vlapic_lvtpc & APIC_VECTOR_MASK, 0);
             break;
         case APIC_MODE_NMI:
-            v->nmi_pending = 1;
+            sampling->nmi_pending = 1;
             break;
         }
     }
@@ -230,7 +387,9 @@ void vpmu_load(struct vcpu *v)
     local_irq_enable();
 
     /* Only when PMU is counting, we load PMU context immediately. */
-    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) )
+    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) ||
+         (!is_hvm_vcpu(v) &&
+          (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED)) )
         return;
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
@@ -248,6 +407,8 @@ void vpmu_initialise(struct vcpu *v)
 
     BUILD_BUG_ON(sizeof(struct xen_pmu_intel_ctxt) > XENPMU_CTXT_PAD_SZ);
     BUILD_BUG_ON(sizeof(struct xen_pmu_amd_ctxt) > XENPMU_CTXT_PAD_SZ);
+    BUILD_BUG_ON(sizeof(struct xen_pmu_regs) > XENPMU_REGS_PAD_SZ);
+    BUILD_BUG_ON(sizeof(struct compat_pmu_regs) > XENPMU_REGS_PAD_SZ);
 
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         vpmu_destroy(v);
@@ -421,7 +582,9 @@ static int vpmu_force_context_switch(uint64_t old_mode)
 long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 {
     int ret;
+    struct vcpu *curr;
     struct xen_pmu_params pmu_params;
+    struct xen_pmu_data *xenpmu_data;
 
     ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
     if ( ret )
@@ -516,6 +679,24 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
         pvpmu_finish(current->domain, &pmu_params);
         break;
 
+    case XENPMU_lvtpc_set:
+        curr = current;
+        xenpmu_data = curr->arch.vpmu.xenpmu_data;
+        if ( xenpmu_data == NULL )
+            return -EINVAL;
+        vpmu_lvtpc_update(xenpmu_data->pmu.l.lapic_lvtpc);
+        break;
+
+    case XENPMU_flush:
+        curr = current;
+        xenpmu_data = curr->arch.vpmu.xenpmu_data;
+        if ( xenpmu_data == NULL )
+            return -EINVAL;
+        xenpmu_data->pmu.pmu_flags &= ~PMU_CACHED;
+        vpmu_lvtpc_update(xenpmu_data->pmu.l.lapic_lvtpc);
+        vpmu_load(curr);
+        break;
+
     default:
         ret = -EINVAL;
     }
diff --git a/xen/include/public/arch-x86/pmu.h b/xen/include/public/arch-x86/pmu.h
index b0f9100..d795594 100644
--- a/xen/include/public/arch-x86/pmu.h
+++ b/xen/include/public/arch-x86/pmu.h
@@ -50,6 +50,11 @@ struct xen_pmu_regs {
 typedef struct xen_pmu_regs xen_pmu_regs_t;
 DEFINE_XEN_GUEST_HANDLE(xen_pmu_regs_t);
 
+/* PMU flags */
+#define PMU_CACHED         (1<<0) /* PMU MSRs are cached in the context */
+#define PMU_SAMPLE_USER    (1<<1) /* Sample is from user or kernel mode */
+#define PMU_SAMPLE_REAL    (1<<2) /* Sample is from realmode */
+
 struct xen_pmu_arch {
     union {
         struct xen_pmu_regs regs;
diff --git a/xen/include/public/pmu.h b/xen/include/public/pmu.h
index afb4ca1..db5321a 100644
--- a/xen/include/public/pmu.h
+++ b/xen/include/public/pmu.h
@@ -27,6 +27,8 @@
 #define XENPMU_feature_set     3
 #define XENPMU_init            4
 #define XENPMU_finish          5
+#define XENPMU_lvtpc_set       6
+#define XENPMU_flush           7 /* Write cached MSR values to HW     */
 /* ` } */
 
 /* Parameters structure for HYPERVISOR_xenpmu_op call */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index ae47135..1ad4ecc 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -666,7 +666,9 @@ static XSM_INLINE int xsm_pmu_op (XSM_DEFAULT_ARG struct domain *d, int op)
     case XENPMU_feature_get:
         return xsm_default_action(XSM_PRIV, d, current->domain);
     case XENPMU_init:
-    case XENPMU_finish: 
+    case XENPMU_finish:
+    case XENPMU_lvtpc_set:
+    case XENPMU_flush:
         return xsm_default_action(XSM_HOOK, d, current->domain);
     default:
         return -EPERM;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 76f2cf1..bc71b8e 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1517,6 +1517,8 @@ static int flask_pmu_op (struct domain *d, int op)
                             XEN2__PMU_CTRL, NULL);
     case XENPMU_init:
     case XENPMU_finish:
+    case XENPMU_lvtpc_set:
+    case XENPMU_flush:
         return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN2,
                             XEN2__PMU_USE, NULL);
     default:
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Y-0000pa-Ka; Sun, 16 Nov 2014 23:17:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94X-0000nu-0i
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:33 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	70/F0-03145-C8039645; Sun, 16 Nov 2014 23:17:32 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416179848!12878157!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22268 invoked from network); 16 Nov 2014 23:17:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHMtQ003453
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:22 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHLf1016449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:21 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHLSY023928; Sun, 16 Nov 2014 23:17:21 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:20 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:38 -0500
Message-Id: <1416179271-1221-9-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 08/21] intel/VPMU: MSR_CORE_PERF_GLOBAL_CTRL
	should be initialized 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MSR_CORE_PERF_GLOBAL_CTRL register should be set zero initially. It is up to
the guest to set it so that counters are enabled.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index f44847f..e7fffcf 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -165,14 +165,6 @@ static int core2_get_fixed_pmc_count(void)
     return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
 }
 
-static u64 core2_calc_intial_glb_ctrl_msr(void)
-{
-    int arch_pmc_bits = (1 << arch_pmc_cnt) - 1;
-    u64 fix_pmc_bits  = (1 << fixed_pmc_cnt) - 1;
-
-    return (fix_pmc_bits << 32) | arch_pmc_bits;
-}
-
 /* edx bits 5-12: Bit width of fixed-function performance counters  */
 static int core2_get_bitwidth_fix_count(void)
 {
@@ -373,8 +365,7 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
 
     if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
         goto out_err;
-    vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
-                 core2_calc_intial_glb_ctrl_msr());
+    vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
 
     core2_vpmu_cxt = xzalloc_bytes(sizeof(struct core2_vpmu_context) +
                     (arch_pmc_cnt-1)*sizeof(struct arch_msr_pair));
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94V-0000my-Bv; Sun, 16 Nov 2014 23:17:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94T-0000mQ-C3
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/89-24532-88039645; Sun, 16 Nov 2014 23:17:28 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416179846!12807247!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4579 invoked from network); 16 Nov 2014 23:17:28 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHJgf003443
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:20 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHHV0016373
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:18 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHHIB012663; Sun, 16 Nov 2014 23:17:17 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:17 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:34 -0500
Message-Id: <1416179271-1221-5-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 04/21] x86/VPMU: Make vpmu macros a bit more
	efficient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 vpmu_are_all_set that allows testing multiple bits at once. Convert macros
into inlines for better compiler checking.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  5 +----
 xen/arch/x86/hvm/vpmu.c           |  3 +--
 xen/include/asm-x86/hvm/vpmu.h    | 25 +++++++++++++++++++++----
 3 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 54e96b6..f2e9735 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -326,10 +326,7 @@ static int core2_vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_SAVE) )
-        return 0;
-
-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) ) 
+    if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
         return 0;
 
     __core2_vpmu_save(v);
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index e74c871..aec7b5f 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -143,8 +143,7 @@ void vpmu_save(struct vcpu *v)
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     int pcpu = smp_processor_id();
 
-    if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) &&
-           vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)) )
+    if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_ALLOCATED | VPMU_CONTEXT_LOADED) )
        return;
 
     vpmu->last_pcpu = pcpu;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 1f28bd8..ddc2748 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -82,10 +82,27 @@ struct vpmu_struct {
 #define VPMU_CPU_HAS_BTS                    0x200 /* Has Branch Trace Store */
 
 
-#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)
+static inline void vpmu_set(struct vpmu_struct *vpmu, const u32 mask)
+{
+    vpmu->flags |= mask;
+}
+static inline void vpmu_reset(struct vpmu_struct *vpmu, const u32 mask)
+{
+    vpmu->flags &= ~mask;
+}
+static inline void vpmu_clear(struct vpmu_struct *vpmu)
+{
+    vpmu->flags = 0;
+}
+static inline bool_t vpmu_is_set(const struct vpmu_struct *vpmu, const u32 mask)
+{
+    return !!(vpmu->flags & mask);
+}
+static inline bool_t vpmu_are_all_set(const struct vpmu_struct *vpmu,
+                                      const u32 mask)
+{
+    return !!((vpmu->flags & mask) == mask);
+}
 
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94k-00015y-Tz; Sun, 16 Nov 2014 23:17:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94i-00010R-Hr
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:44 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	C9/AB-22819-79039645; Sun, 16 Nov 2014 23:17:43 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416179861!6372093!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26654 invoked from network); 16 Nov 2014 23:17:42 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Nov 2014 23:17:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHZlh007783
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:36 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHY4K016738
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:35 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHYbs013025; Sun, 16 Nov 2014 23:17:34 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:34 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:51 -0500
Message-Id: <1416179271-1221-22-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 21/21] x86/VPMU: Move VPMU files up from
	hvm/ directory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since PMU is now not HVM specific we can move VPMU-related files up from
arch/x86/hvm/ directory.

Specifically:
    arch/x86/hvm/vpmu.c -> arch/x86/cpu/vpmu.c
    arch/x86/hvm/svm/vpmu.c -> arch/x86/cpu/vpmu_amd.c
    arch/x86/hvm/vmx/vpmu_core2.c -> arch/x86/cpu/vpmu_intel.c
    include/asm-x86/hvm/vpmu.h -> include/asm-x86/vpmu.h

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/cpu/Makefile                               | 1 +
 xen/arch/x86/{hvm => cpu}/vpmu.c                        | 2 +-
 xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c}         | 2 +-
 xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 2 +-
 xen/arch/x86/hvm/Makefile                               | 1 -
 xen/arch/x86/hvm/svm/Makefile                           | 1 -
 xen/arch/x86/hvm/vlapic.c                               | 2 +-
 xen/arch/x86/hvm/vmx/Makefile                           | 1 -
 xen/arch/x86/oprofile/op_model_ppro.c                   | 2 +-
 xen/arch/x86/traps.c                                    | 2 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h                      | 2 +-
 xen/include/asm-x86/{hvm => }/vpmu.h                    | 0
 12 files changed, 8 insertions(+), 10 deletions(-)
 rename xen/arch/x86/{hvm => cpu}/vpmu.c (99%)
 rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (99%)
 rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (99%)
 rename xen/include/asm-x86/{hvm => }/vpmu.h (100%)

diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index d73d93a..74f23ae 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -7,3 +7,4 @@ obj-y += common.o
 obj-y += intel.o
 obj-y += intel_cacheinfo.o
 obj-y += mwait-idle.o
+obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/cpu/vpmu.c
similarity index 99%
rename from xen/arch/x86/hvm/vpmu.c
rename to xen/arch/x86/cpu/vpmu.c
index cf96da7..a52604a 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -27,10 +27,10 @@
 #include <asm/types.h>
 #include <asm/msr.h>
 #include <asm/p2m.h>
+#include <asm/vpmu.h>
 #include <asm/hvm/support.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/vmx/vmcs.h>
-#include <asm/hvm/vpmu.h>
 #include <asm/hvm/svm/svm.h>
 #include <asm/hvm/svm/vmcb.h>
 #include <asm/apic.h>
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/cpu/vpmu_amd.c
similarity index 99%
rename from xen/arch/x86/hvm/svm/vpmu.c
rename to xen/arch/x86/cpu/vpmu_amd.c
index c21bde0..bb9da12 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -28,8 +28,8 @@
 #include <xen/sched.h>
 #include <xen/irq.h>
 #include <asm/apic.h>
+#include <asm/vpmu.h>
 #include <asm/hvm/vlapic.h>
-#include <asm/hvm/vpmu.h>
 #include <public/pmu.h>
 
 #define MSR_F10H_EVNTSEL_GO_SHIFT   40
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/cpu/vpmu_intel.c
similarity index 99%
rename from xen/arch/x86/hvm/vmx/vpmu_core2.c
rename to xen/arch/x86/cpu/vpmu_intel.c
index 271fae5..e5f22a7 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -30,6 +30,7 @@
 #include <asm/traps.h>
 #include <asm/msr.h>
 #include <asm/msr-index.h>
+#include <asm/vpmu.h>
 #include <asm/hvm/support.h>
 #include <asm/hvm/vlapic.h>
 #include <asm/hvm/vmx/vmx.h>
@@ -37,7 +38,6 @@
 #include <public/sched.h>
 #include <public/hvm/save.h>
 #include <public/pmu.h>
-#include <asm/hvm/vpmu.h>
 
 /*
  * See Intel SDM Vol 2a Instruction Set Reference chapter 3 for CPUID
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index eea5555..742b83b 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -22,4 +22,3 @@ obj-y += vlapic.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
-obj-y += vpmu.o
\ No newline at end of file
diff --git a/xen/arch/x86/hvm/svm/Makefile b/xen/arch/x86/hvm/svm/Makefile
index a10a55e..760d295 100644
--- a/xen/arch/x86/hvm/svm/Makefile
+++ b/xen/arch/x86/hvm/svm/Makefile
@@ -6,4 +6,3 @@ obj-y += nestedsvm.o
 obj-y += svm.o
 obj-y += svmdebug.o
 obj-y += vmcb.o
-obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 5c3b2be..16ad0ce 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -38,7 +38,7 @@
 #include <asm/hvm/support.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/nestedhvm.h>
-#include <asm/hvm/vpmu.h>
+#include <asm/vpmu.h>
 #include <public/hvm/ioreq.h>
 #include <public/hvm/params.h>
 
diff --git a/xen/arch/x86/hvm/vmx/Makefile b/xen/arch/x86/hvm/vmx/Makefile
index 373b3d9..04a29ce 100644
--- a/xen/arch/x86/hvm/vmx/Makefile
+++ b/xen/arch/x86/hvm/vmx/Makefile
@@ -3,5 +3,4 @@ obj-y += intr.o
 obj-y += realmode.o
 obj-y += vmcs.o
 obj-y += vmx.o
-obj-y += vpmu_core2.o
 obj-y += vvmx.o
diff --git a/xen/arch/x86/oprofile/op_model_ppro.c b/xen/arch/x86/oprofile/op_model_ppro.c
index ca429a1..89649d0 100644
--- a/xen/arch/x86/oprofile/op_model_ppro.c
+++ b/xen/arch/x86/oprofile/op_model_ppro.c
@@ -19,7 +19,7 @@
 #include <asm/processor.h>
 #include <asm/regs.h>
 #include <asm/current.h>
-#include <asm/hvm/vpmu.h>
+#include <asm/vpmu.h>
 
 #include "op_x86_model.h"
 #include "op_counter.h"
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 663b44f..33f0fc5 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -72,7 +72,7 @@
 #include <asm/apic.h>
 #include <asm/mc146818rtc.h>
 #include <asm/hpet.h>
-#include <asm/hvm/vpmu.h>
+#include <asm/vpmu.h>
 #include <public/arch-x86/cpuid.h>
 #include <xsm/xsm.h>
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 949884b..dcf2d31 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -20,7 +20,7 @@
 #define __ASM_X86_HVM_VMX_VMCS_H__
 
 #include <asm/hvm/io.h>
-#include <asm/hvm/vpmu.h>
+#include <asm/vpmu.h>
 #include <irq_vectors.h>
 
 extern void vmcs_dump_vcpu(struct vcpu *v);
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/vpmu.h
similarity index 100%
rename from xen/include/asm-x86/hvm/vpmu.h
rename to xen/include/asm-x86/vpmu.h
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94k-00014Q-3D; Sun, 16 Nov 2014 23:17:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94h-0000z5-JX
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:43 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	88/AB-22819-69039645; Sun, 16 Nov 2014 23:17:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416179860!11643500!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16230 invoked from network); 16 Nov 2014 23:17:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Nov 2014 23:17:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHYA8003493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:35 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHXqv024301
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:34 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHXDG013001; Sun, 16 Nov 2014 23:17:33 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:33 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:50 -0500
Message-Id: <1416179271-1221-21-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 20/21] x86/VPMU: NMI-based VPMU support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 support for using NMIs as PMU interrupts to allow profiling hypervisor
when interrupts are disabled.

Most of processing is still performed by vpmu_do_interrupt(). However, since
certain operations are not NMI-safe we defer them to a softint that vpmu_do_interrupt()
will schedule:
* For PV guests that would be send_guest_vcpu_virq()
* For HVM guests it's VLAPIC accesses and hvm_get_segment_register() (the later
can be called in privileged profiling mode when the interrupted guest is an HVM one).

With send_guest_vcpu_virq() and hvm_get_segment_register() for PV(H) and vlapic
accesses for HVM moved to sofint, the only routines/macros that vpmu_do_interrupt()
calls in NMI mode are:
* memcpy()
* querying domain type (is_XX_domain())
* guest_cpu_user_regs()
* XLAT_cpu_user_regs()
* raise_softirq()
* vcpu_vpmu()
* vpmu_ops->arch_vpmu_save()
* vpmu_ops->do_interrupt()

The latter two only access PMU MSRs with {rd,wr}msrl() (not the _safe versions
which would not be NMI-safe).

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 docs/misc/xen-command-line.markdown |   8 +-
 xen/arch/x86/hvm/svm/vpmu.c         |   3 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c   |   3 +-
 xen/arch/x86/hvm/vpmu.c             | 230 ++++++++++++++++++++++++++++--------
 xen/include/asm-x86/hvm/vpmu.h      |   4 +-
 xen/include/asm-x86/softirq.h       |   3 +-
 6 files changed, 195 insertions(+), 56 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0830e5f..d7f988e 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1281,11 +1281,11 @@ Use Virtual Processor ID support if available.  This prevents the need for TLB
 flushes on VM entry and exit, increasing performance.
 
 ### vpmu
-> `= ( bts )`
+> `= ( [nmi,][bts] )`
 
 > Default: `off`
 
-Switch on the virtualized performance monitoring unit for HVM guests.
+Switch on the virtualized performance monitoring unit.
 
 If the current cpu isn't supported a message like  
 'VPMU: Initialization failed. ...'  
@@ -1297,6 +1297,10 @@ wrong behaviour (see handle\_pmc\_quirk()).
 If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
 feature is switched on on Intel processors supporting this feature.
 
+If 'vpmu=nmi' is specified the PMU interrupt will cause an NMI instead of a
+regular vector interrupt (which is the default). This can be useful for sampling
+hypervisor code that is executed with interrupts disabled.
+
 *Warning:*
 As the BTS virtualisation is not 100% safe and because of the nehalem quirk
 don't use the vpmu flag on production systems with Intel cpus!
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 7d9ba8c..c21bde0 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -168,7 +168,7 @@ static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
     msr_bitmap_off(vpmu);
 }
 
-static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
+static int amd_vpmu_do_interrupt(const struct cpu_user_regs *regs)
 {
     return 1;
 }
@@ -223,6 +223,7 @@ static inline void context_save(struct vcpu *v)
         rdmsrl(counters[i], counter_regs[i]);
 }
 
+/* Must be NMI-safe */
 static int amd_vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 839dce0..271fae5 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -305,6 +305,7 @@ static inline void __core2_vpmu_save(struct vcpu *v)
         rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
+/* Must be NMI-safe */
 static int core2_vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
@@ -706,7 +707,7 @@ static void core2_vpmu_dump(const struct vcpu *v)
     }
 }
 
-static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
+static int core2_vpmu_do_interrupt(const struct cpu_user_regs *regs)
 {
     struct vcpu *v = current;
     u64 msr_content;
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 5f0a871..cf96da7 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -34,6 +34,7 @@
 #include <asm/hvm/svm/svm.h>
 #include <asm/hvm/svm/vmcb.h>
 #include <asm/apic.h>
+#include <asm/nmi.h>
 #include <public/pmu.h>
 #include <xsm/xsm.h>
 
@@ -54,36 +55,54 @@ unsigned int __read_mostly vpmu_features = 0;
 static void parse_vpmu_param(char *s);
 custom_param("vpmu", parse_vpmu_param);
 
+static void pmu_softnmi(void);
+
 static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
+static DEFINE_PER_CPU(struct vcpu *, sampled_vcpu);
+
+static uint32_t __read_mostly vpmu_interrupt_type = PMU_APIC_VECTOR;
 
 static void __init parse_vpmu_param(char *s)
 {
-    switch ( parse_bool(s) )
-    {
-    case 0:
-        break;
-    default:
-        if ( !strcmp(s, "bts") )
-            vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
-        else if ( *s )
+    char *ss;
+
+    vpmu_mode = XENPMU_MODE_SELF;
+    if (*s == '\0')
+        return;
+
+    do {
+        ss = strchr(s, ',');
+        if ( ss )
+            *ss = '\0';
+
+        switch  ( parse_bool(s) )
         {
-            printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
-            break;
+        default:
+            if ( !strcmp(s, "nmi") )
+                vpmu_interrupt_type = APIC_DM_NMI;
+            else if ( !strcmp(s, "bts") )
+                vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
+            else
+            {
+                printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
+        case 0:
+                vpmu_mode = XENPMU_MODE_OFF;
+        case 1:
+                return;
+            }
         }
-        /* fall through */
-    case 1:
-        /* Default VPMU mode */
-        vpmu_mode = XENPMU_MODE_SELF;
-        break;
-    }
+
+        s = ss + 1;
+    } while ( ss );
 }
 
+
 void vpmu_lvtpc_update(uint32_t val)
 {
     struct vcpu *curr = current;
     struct vpmu_struct *vpmu = vcpu_vpmu(curr);
 
-    vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
+    vpmu->hw_lapic_lvtpc = vpmu_interrupt_type | (val & APIC_LVT_MASKED);
 
     /* Postpone APIC updates for PV(H) guests if PMU interrupt is pending */
     if ( is_hvm_vcpu(curr) || !vpmu->xenpmu_data ||
@@ -91,6 +110,30 @@ void vpmu_lvtpc_update(uint32_t val)
         apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
 
+static void vpmu_send_interrupt(struct vcpu *v)
+{
+    struct vlapic *vlapic;
+    u32 vlapic_lvtpc;
+
+    ASSERT(is_hvm_vcpu(v));
+
+    vlapic = vcpu_vlapic(v);
+    if ( !is_vlapic_lvtpc_enabled(vlapic) )
+        return;
+
+    vlapic_lvtpc = vlapic_get_reg(vlapic, APIC_LVTPC);
+
+    switch ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) )
+    {
+    case APIC_MODE_FIXED:
+        vlapic_set_irq(vlapic, vlapic_lvtpc & APIC_VECTOR_MASK, 0);
+        break;
+    case APIC_MODE_NMI:
+        v->nmi_pending = 1;
+        break;
+    }
+}
+
 int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
                 uint64_t supported, bool_t is_write)
 {
@@ -141,7 +184,7 @@ static struct vcpu *choose_hwdom_vcpu(void)
     return hardware_domain->vcpu[idx];
 }
 
-void vpmu_do_interrupt(struct cpu_user_regs *regs)
+int vpmu_do_interrupt(const struct cpu_user_regs *regs)
 {
     struct vcpu *sampled = current, *sampling;
     struct vpmu_struct *vpmu;
@@ -155,7 +198,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
     {
         sampling = choose_hwdom_vcpu();
         if ( !sampling )
-            return;
+            return 0;
     }
     else
         sampling = sampled;
@@ -169,15 +212,15 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
         uint32_t domid;
 
         if ( !vpmu->xenpmu_data )
-            return;
+            return 0;
 
         if ( *flags & PMU_CACHED )
-            return;
+            return 0;
 
         if ( is_pvh_vcpu(sampling) &&
              !(vpmu_mode & XENPMU_MODE_ALL) &&
              !vpmu->arch_vpmu_ops->do_interrupt(regs) )
-            return;
+            return 0;
 
         /* PV guest will be reading PMU MSRs from xenpmu_data */
         vpmu_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
@@ -241,16 +284,21 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
             }
             else
             {
-                struct segment_register seg;
-
-                hvm_get_segment_register(sampled, x86_seg_cs, &seg);
-                r->cs = seg.sel;
-                hvm_get_segment_register(sampled, x86_seg_ss, &seg);
-                r->ss = seg.sel;
-                if ( seg.attr.fields.dpl != 0 )
-                    *flags |= PMU_SAMPLE_USER;
                 if ( !(sampled->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) )
                     *flags |= PMU_SAMPLE_REAL;
+
+                /* Unsafe in NMI context, defer to softint later. */
+                if ( vpmu_interrupt_type != APIC_DM_NMI )
+                {
+                    struct segment_register seg;
+
+                    hvm_get_segment_register(sampled, x86_seg_cs, &seg);
+                    r->cs = seg.sel;
+                    hvm_get_segment_register(sampled, x86_seg_ss, &seg);
+                    r->ss = seg.sel;
+                    if ( seg.attr.fields.dpl != 0 )
+                        *flags |= PMU_SAMPLE_USER;
+                }
             }
         }
 
@@ -262,35 +310,37 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
         vpmu->hw_lapic_lvtpc |= APIC_LVT_MASKED;
         apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 
-        send_guest_vcpu_virq(sampling, VIRQ_XENPMU);
+        if ( vpmu_interrupt_type == APIC_DM_NMI )
+        {
+            this_cpu(sampled_vcpu) = sampled;
+            raise_softirq(PMU_SOFTIRQ);
+        }
+        else
+            send_guest_vcpu_virq(sampling, VIRQ_XENPMU);
 
-        return;
+        return 1;
     }
 
     if ( vpmu->arch_vpmu_ops )
     {
-        struct vlapic *vlapic = vcpu_vlapic(sampling);
-        u32 vlapic_lvtpc;
-
         /* We don't support (yet) HVM dom0 */
         ASSERT(sampling == sampled);
 
-        if ( !vpmu->arch_vpmu_ops->do_interrupt(regs) ||
-             !is_vlapic_lvtpc_enabled(vlapic) )
-            return;
+        if ( !vpmu->arch_vpmu_ops->do_interrupt(regs) )
+            return 0;
 
-        vlapic_lvtpc = vlapic_get_reg(vlapic, APIC_LVTPC);
-
-        switch ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) )
+        if ( vpmu_interrupt_type == APIC_DM_NMI )
         {
-        case APIC_MODE_FIXED:
-            vlapic_set_irq(vlapic, vlapic_lvtpc & APIC_VECTOR_MASK, 0);
-            break;
-        case APIC_MODE_NMI:
-            sampling->nmi_pending = 1;
-            break;
+            this_cpu(sampled_vcpu) = sampled;
+            raise_softirq(PMU_SOFTIRQ);
         }
+        else
+            vpmu_send_interrupt(sampling);
+
+        return 1;
     }
+
+    return 0;
 }
 
 void vpmu_do_cpuid(unsigned int input,
@@ -319,6 +369,9 @@ static void vpmu_save_force(void *arg)
     vpmu_reset(vpmu, VPMU_CONTEXT_SAVE);
 
     per_cpu(last_vcpu, smp_processor_id()) = NULL;
+
+    /* Make sure there are no outstanding PMU NMIs */
+    pmu_softnmi();
 }
 
 void vpmu_save(struct vcpu *v)
@@ -336,7 +389,10 @@ void vpmu_save(struct vcpu *v)
         if ( vpmu->arch_vpmu_ops->arch_vpmu_save(v) )
             vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
 
-    apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
+    apic_write(APIC_LVTPC, vpmu_interrupt_type | APIC_LVT_MASKED);
+
+    /* Make sure there are no outstanding PMU NMIs */
+    pmu_softnmi();
 }
 
 void vpmu_load(struct vcpu *v)
@@ -390,6 +446,9 @@ void vpmu_load(struct vcpu *v)
           (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED)) )
         return;
 
+    /* Make sure there are no outstanding PMU NMIs from previous vcpu */
+    pmu_softnmi();
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
     {
         apic_write_around(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
@@ -412,7 +471,7 @@ void vpmu_initialise(struct vcpu *v)
         vpmu_destroy(v);
     vpmu_clear(vpmu);
     vpmu->context = NULL;
-    vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
+    vpmu->hw_lapic_lvtpc = vpmu_interrupt_type | APIC_LVT_MASKED;
 
     switch ( vendor )
     {
@@ -448,6 +507,57 @@ void vpmu_destroy(struct vcpu *v)
     }
 }
 
+/* Process the softirq set by PMU NMI handler */
+static void pmu_softnmi(void)
+{
+    unsigned int cpu = smp_processor_id();
+    struct vcpu *v, *sampled = per_cpu(sampled_vcpu, cpu);
+
+    if ( sampled == NULL )
+        return;
+
+    per_cpu(sampled_vcpu, cpu) = NULL;
+
+    if ( (vpmu_mode & XENPMU_MODE_ALL) ||
+         (sampled->domain->domain_id >= DOMID_FIRST_RESERVED) )
+    {
+            v = choose_hwdom_vcpu();
+            if ( !v )
+                return;
+    }
+    else
+    {
+        if ( is_hvm_vcpu(sampled) )
+        {
+            vpmu_send_interrupt(sampled);
+            return;
+        }
+        v = sampled;
+    }
+
+    if ( has_hvm_container_vcpu(sampled) )
+    {
+        struct segment_register seg;
+        struct xen_pmu_arch *pmu = &v->arch.vpmu.xenpmu_data->pmu;
+        struct xen_pmu_regs *r = &pmu->r.regs;
+
+        hvm_get_segment_register(sampled, x86_seg_cs, &seg);
+        r->cs = seg.sel;
+        hvm_get_segment_register(sampled, x86_seg_ss, &seg);
+        r->ss = seg.sel;
+        if ( seg.attr.fields.dpl != 0 )
+            pmu->pmu_flags |= PMU_SAMPLE_USER;
+    }
+
+    send_guest_vcpu_virq(v, VIRQ_XENPMU);
+}
+
+int pmu_nmi_interrupt(const struct cpu_user_regs *regs, int cpu)
+{
+    return vpmu_do_interrupt(regs);
+}
+
+
 static int pvpmu_init(struct domain *d, xen_pmu_params_t *params)
 {
     struct vcpu *v;
@@ -715,6 +825,21 @@ static int __init vpmu_init(void)
         return 0;
     }
 
+    if ( vpmu_interrupt_type == APIC_DM_NMI )
+    {
+        if ( reserve_lapic_nmi() != 0 )
+        {
+            printk(XENLOG_WARNING "VPMU: Can't reserve NMI, will use"
+                                  " APIC vector 0x%x\n", PMU_APIC_VECTOR);
+            vpmu_interrupt_type = PMU_APIC_VECTOR;
+        }
+        else
+        {
+            set_nmi_callback(pmu_nmi_interrupt);
+            open_softirq(PMU_SOFTIRQ, pmu_softnmi);
+        }
+    }
+
     switch ( vendor )
     {
         case X86_VENDOR_AMD:
@@ -731,7 +856,14 @@ static int __init vpmu_init(void)
     }
 
     if ( vpmu_mode == XENPMU_MODE_OFF )
+    {
+        if ( vpmu_interrupt_type == APIC_DM_NMI )
+        {
+            unset_nmi_callback();
+            release_lapic_nmi();
+        }
         printk(XENLOG_WARNING "VPMU: Disabling due to initialization error\n");
+    }
     else
         printk(XENLOG_INFO "VPMU: version %d.%d\n",
                XENPMU_VER_MAJ, XENPMU_VER_MIN);
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 56cc09c..8662b51 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -42,7 +42,7 @@ struct arch_vpmu_ops {
     int (*do_wrmsr)(unsigned int msr, uint64_t msr_content,
                     uint64_t supported);
     int (*do_rdmsr)(unsigned int msr, uint64_t *msr_content);
-    int (*do_interrupt)(struct cpu_user_regs *regs);
+    int (*do_interrupt)(const struct cpu_user_regs *regs);
     void (*do_cpuid)(unsigned int input,
                      unsigned int *eax, unsigned int *ebx,
                      unsigned int *ecx, unsigned int *edx);
@@ -101,7 +101,7 @@ static inline bool_t vpmu_are_all_set(const struct vpmu_struct *vpmu,
 void vpmu_lvtpc_update(uint32_t val);
 int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
                 uint64_t supported, bool_t is_write);
-void vpmu_do_interrupt(struct cpu_user_regs *regs);
+int vpmu_do_interrupt(const 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);
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 7225dea..ef24056 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -7,7 +7,8 @@
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
-#define NR_ARCH_SOFTIRQS       5
+#define PMU_SOFTIRQ            (NR_COMMON_SOFTIRQS + 5)
+#define NR_ARCH_SOFTIRQS       6
 
 bool_t arch_skip_send_event_check(unsigned int cpu);
 
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94c-0000t5-3o; Sun, 16 Nov 2014 23:17:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94a-0000rA-F9
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:36 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	76/30-02696-F8039645; Sun, 16 Nov 2014 23:17:35 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416179853!8269001!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26898 invoked from network); 16 Nov 2014 23:17:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:35 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHTCS003472
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:29 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHSL6007593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:29 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHRYZ007579; Sun, 16 Nov 2014 23:17:28 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:27 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:44 -0500
Message-Id: <1416179271-1221-15-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 14/21] x86/VPMU: Save VPMU state for PV
	guests during context switch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Save VPMU state during context switch for both HVM and PV(H) guests.

A subsequent patch ("x86/VPMU: NMI-based VPMU support") will make it possible
for vpmu_switch_to() to call vmx_vmcs_try_enter()->vcpu_pause() which needs
is_running to be correctly set/cleared. To prepare for that, call context_saved()
before vpmu_switch_to() is executed. (Note that while this change could have
been dalayed until that later patch, the changes are harmless to existing code
and so we do it here)

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/domain.c | 20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ce1d187..0de8a20 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1541,16 +1541,13 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
     }
 
     if ( prev != next )
-        _update_runstate_area(prev);
-
-    if ( is_hvm_vcpu(prev) )
     {
-        if (prev != next)
-            vpmu_switch_from(prev, next);
+        _update_runstate_area(prev);
+        vpmu_switch_from(prev, next);
+    }
 
-        if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
+    if ( is_hvm_vcpu(prev) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
             pt_save_timer(prev);
-    }
 
     local_irq_disable();
 
@@ -1589,15 +1586,16 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
                            !is_hardware_domain(next->domain));
     }
 
-    if ( is_hvm_vcpu(prev) && (prev != next) )
-        /* Must be done with interrupts enabled */
-        vpmu_switch_to(prev, next);
-
     context_saved(prev);
 
     if ( prev != next )
+    {
         _update_runstate_area(next);
 
+        /* Must be done with interrupts enabled */
+        vpmu_switch_to(prev, next);
+    }
+
     /* Ensure that the vcpu has an up-to-date time base. */
     update_vcpu_system_time(next);
 
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94e-0000w0-KI; Sun, 16 Nov 2014 23:17:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94c-0000t9-J9
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9D/89-24532-19039645; Sun, 16 Nov 2014 23:17:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416179855!13161209!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13944 invoked from network); 16 Nov 2014 23:17:36 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:36 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHSmk007736
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:29 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHSc3016611
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 16 Nov 2014 23:17:28 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAGNHQhs016573; Sun, 16 Nov 2014 23:17:27 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:26 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:43 -0500
Message-Id: <1416179271-1221-14-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 13/21] x86/VPMU: Initialize PMU for PV(H)
	guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Code for initializing/tearing down PMU for PV guests

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 tools/flask/policy/policy/modules/xen/xen.te |  4 ++
 xen/arch/x86/domain.c                        |  2 +
 xen/arch/x86/hvm/hvm.c                       |  1 +
 xen/arch/x86/hvm/svm/svm.c                   |  4 +-
 xen/arch/x86/hvm/svm/vpmu.c                  | 44 +++++++++----
 xen/arch/x86/hvm/vmx/vmx.c                   |  4 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c            | 81 ++++++++++++++++-------
 xen/arch/x86/hvm/vpmu.c                      | 98 +++++++++++++++++++++++++++-
 xen/common/event_channel.c                   |  1 +
 xen/include/asm-x86/hvm/vpmu.h               |  2 +
 xen/include/public/pmu.h                     |  2 +
 xen/include/public/xen.h                     |  1 +
 xen/include/xsm/dummy.h                      |  3 +
 xen/xsm/flask/hooks.c                        |  4 ++
 xen/xsm/flask/policy/access_vectors          |  2 +
 15 files changed, 212 insertions(+), 41 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index ae7bf3c..9d84004 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -120,6 +120,10 @@ domain_comms(dom0_t, dom0_t)
 # Allow all domains to use (unprivileged parts of) the tmem hypercall
 allow domain_type xen_t:xen tmem_op;
 
+# Allow all domains to use PMU (but not to change its settings --- that's what
+# pmu_ctrl is for)
+allow domain_type xen_t:xen2 pmu_use;
+
 ###############################################################################
 #
 # Domain creation
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index da5bdf4..ce1d187 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -445,6 +445,8 @@ int vcpu_initialise(struct vcpu *v)
 
     vmce_init_vcpu(v);
 
+    spin_lock_init(&v->arch.vpmu.vpmu_lock);
+
     if ( has_hvm_container_domain(d) )
     {
         rc = hvm_vcpu_initialise(v);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..ec9c89a 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4820,6 +4820,7 @@ static hvm_hypercall_t *const pvh_hypercall64_table[NR_hypercalls] = {
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
     HYPERCALL(domctl),
+    HYPERCALL(xenpmu_op),
     [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
 };
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 8aca6e6..b1c4845 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1157,7 +1157,9 @@ static int svm_vcpu_initialise(struct vcpu *v)
         return rc;
     }
 
-    vpmu_initialise(v);
+    /* PVH's VPMU is initialized via hypercall */
+    if ( is_hvm_vcpu(v) )
+        vpmu_initialise(v);
 
     svm_guest_osvw_init(v);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 8460d7b..fe852ed 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -363,17 +363,19 @@ static void amd_vpmu_destroy(struct vcpu *v)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
-    if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
-        amd_vpmu_unset_msr_bitmap(v);
+    if ( has_hvm_container_vcpu(v) )
+    {
+        if ( is_msr_bitmap_on(vpmu) )
+            amd_vpmu_unset_msr_bitmap(v);
 
-    xfree(vpmu->context);
-    vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
+        if ( is_hvm_vcpu(v) )
+            xfree(vpmu->context);
 
-    if ( vpmu_is_set(vpmu, VPMU_RUNNING) )
-    {
-        vpmu_reset(vpmu, VPMU_RUNNING);
         release_pmu_ownship(PMU_OWNER_HVM);
     }
+
+    vpmu->context = NULL;
+    vpmu_clear(vpmu);
 }
 
 /* VPMU part of the 'q' keyhandler */
@@ -439,15 +441,19 @@ int svm_vpmu_initialise(struct vcpu *v)
     if ( !counters )
         return -EINVAL;
 
-    ctxt = xzalloc_bytes(sizeof(*ctxt) +
-                         2 * sizeof(uint64_t) * num_counters);
-    if ( !ctxt )
+    if ( is_hvm_vcpu(v) )
     {
-        printk(XENLOG_G_WARNING "Insufficient memory for PMU, "
-               " PMU feature is unavailable on domain %d vcpu %d.\n",
-               v->vcpu_id, v->domain->domain_id);
-        return -ENOMEM;
+        ctxt = xzalloc_bytes(sizeof(*ctxt) +
+                             2 * sizeof(uint64_t) * num_counters);
+        if ( !ctxt )
+        {
+            printk(XENLOG_G_WARNING "%pv: Insufficient memory for PMU, "
+                   " PMU feature is unavailable\n", v);
+            return -ENOMEM;
+        }
     }
+    else
+        ctxt = &v->arch.vpmu.xenpmu_data->pmu.c.amd;
 
     ctxt->counters = sizeof(*ctxt);
     ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
@@ -489,6 +495,16 @@ int __init amd_vpmu_init(void)
         return -EINVAL;
     }
 
+    if ( sizeof(struct xen_pmu_data) +
+         2 * sizeof(uint64_t) * num_counters > PAGE_SIZE )
+    {
+        printk(XENLOG_WARNING
+               "VPMU: Register bank does not fit into VPMU shared page\n");
+        counters = ctrls = NULL;
+        num_counters = 0;
+        return -ENOSPC;
+    }
+
     return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 0bf92b2..a7c3a7a 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -116,7 +116,9 @@ static int vmx_vcpu_initialise(struct vcpu *v)
         return rc;
     }
 
-    vpmu_initialise(v);
+    /* PVH's VPMU is initialized via hypercall */
+    if ( is_hvm_vcpu(v) )
+        vpmu_initialise(v);
 
     vmx_install_vlapic_mapping(v);
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index e199367..03dc981 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -362,24 +362,34 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
     struct xen_pmu_intel_ctxt *core2_vpmu_cxt = NULL;
     uint64_t *p = NULL;
 
-    if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
-        return 0;
-
-    wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
-    if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
+    p = xzalloc_bytes(sizeof(uint64_t));
+    if ( !p )
         goto out_err;
 
-    if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
-        goto out_err;
-    vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
-
-    core2_vpmu_cxt = xzalloc_bytes(sizeof(*core2_vpmu_cxt) +
-                                   sizeof(uint64_t) * fixed_pmc_cnt +
-                                   sizeof(struct xen_pmu_cntr_pair) *
-                                   arch_pmc_cnt);
-    p = xzalloc(uint64_t);
-    if ( !core2_vpmu_cxt || !p )
-        goto out_err;
+    if ( has_hvm_container_vcpu(v) )
+    {
+        if ( is_hvm_vcpu(v) && !acquire_pmu_ownership(PMU_OWNER_HVM) )
+            goto out_err;
+
+        wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+        if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
+            goto out_err_hvm;
+        if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
+            goto out_err_hvm;
+        vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+    }
+
+    if ( is_hvm_vcpu(v) )
+    {
+        core2_vpmu_cxt = xzalloc_bytes(sizeof(*core2_vpmu_cxt) +
+                                       sizeof(uint64_t) * fixed_pmc_cnt +
+                                       sizeof(struct xen_pmu_cntr_pair) *
+                                       arch_pmc_cnt);
+        if ( !core2_vpmu_cxt )
+            goto out_err_hvm;
+    }
+    else
+        core2_vpmu_cxt = &v->arch.vpmu.xenpmu_data->pmu.c.intel;
 
     core2_vpmu_cxt->fixed_counters = sizeof(*core2_vpmu_cxt);
     core2_vpmu_cxt->arch_counters = core2_vpmu_cxt->fixed_counters +
@@ -392,10 +402,12 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
 
     return 1;
 
-out_err:
-    release_pmu_ownship(PMU_OWNER_HVM);
-
+ out_err_hvm:
     xfree(core2_vpmu_cxt);
+    if ( is_hvm_vcpu(v) )
+        release_pmu_ownship(PMU_OWNER_HVM);
+
+ out_err:
     xfree(p);
 
     printk("Failed to allocate VPMU resources for domain %u vcpu %u\n",
@@ -715,12 +727,20 @@ static void core2_vpmu_destroy(struct vcpu *v)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
-    xfree(vpmu->context);
+    if ( has_hvm_container_vcpu(v) )
+    {
+        if ( cpu_has_vmx_msr_bitmap )
+            core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
+
+        if ( is_hvm_vcpu(v) )
+            xfree(vpmu->context);
+
+        release_pmu_ownship(PMU_OWNER_HVM);
+    }
+
     xfree(vpmu->priv_context);
-    if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
-        core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
-    release_pmu_ownship(PMU_OWNER_HVM);
-    vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
+    vpmu->context = NULL;
+    vpmu_clear(vpmu);
 }
 
 struct arch_vpmu_ops core2_vpmu_ops = {
@@ -830,6 +850,10 @@ int vmx_vpmu_initialise(struct vcpu *v)
     ds_warned = 1;
  func_out:
 
+    /* PV domains can allocate resources immediately */
+    if ( is_pv_vcpu(v) && !core2_vpmu_alloc_resource(v) )
+        return -EIO;
+
     vpmu->arch_vpmu_ops = &core2_vpmu_ops;
 
     return 0;
@@ -895,5 +919,14 @@ int __init core2_vpmu_init(void)
 
     check_pmc_quirk();
 
+    if ( sizeof(struct xen_pmu_data) + sizeof(uint64_t) * fixed_pmc_cnt +
+         sizeof(struct xen_pmu_cntr_pair) * arch_pmc_cnt > PAGE_SIZE )
+    {
+        printk(XENLOG_WARNING
+               "VPMU: Register bank does not fit into VPMU share page\n");
+        arch_pmc_cnt = fixed_pmc_cnt = 0;
+        return -ENOSPC;
+    }
+
     return 0;
 }
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index ed3b99a..2ad9832 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -26,6 +26,7 @@
 #include <asm/regs.h>
 #include <asm/types.h>
 #include <asm/msr.h>
+#include <asm/p2m.h>
 #include <asm/hvm/support.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/vmx/vmcs.h>
@@ -252,6 +253,7 @@ void vpmu_initialise(struct vcpu *v)
         vpmu_destroy(v);
     vpmu_clear(vpmu);
     vpmu->context = NULL;
+    vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
 
     switch ( vendor )
     {
@@ -278,7 +280,89 @@ void vpmu_destroy(struct vcpu *v)
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
+    {
+        /* Unload VPMU first. This will stop counters */
+        on_selected_cpus(cpumask_of(vcpu_vpmu(v)->last_pcpu),
+                         vpmu_save_force, v, 1);
+
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
+    }
+}
+
+static int pvpmu_init(struct domain *d, xen_pmu_params_t *params)
+{
+    struct vcpu *v;
+    struct vpmu_struct *vpmu;
+    struct page_info *page;
+    uint64_t gfn = params->val;
+
+    if ( vpmu_mode == XENPMU_MODE_OFF )
+        return -EINVAL;
+
+    if ( (params->vcpu >= d->max_vcpus) || (d->vcpu == NULL) ||
+         (d->vcpu[params->vcpu] == NULL) )
+        return -EINVAL;
+
+    page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
+    if ( !page )
+        return -EINVAL;
+
+    if ( !get_page_type(page, PGT_writable_page) )
+    {
+        put_page(page);
+        return -EINVAL;
+    }
+
+    v = d->vcpu[params->vcpu];
+    vpmu = vcpu_vpmu(v);
+    spin_lock(&vpmu->vpmu_lock);
+
+    v->arch.vpmu.xenpmu_data = __map_domain_page_global(page);
+    if ( !v->arch.vpmu.xenpmu_data )
+    {
+        put_page_and_type(page);
+        spin_unlock(&vpmu->vpmu_lock);
+        return -EINVAL;
+    }
+
+    vpmu_initialise(v);
+
+    spin_unlock(&vpmu->vpmu_lock);
+
+    return 0;
+}
+
+static void pvpmu_finish(struct domain *d, xen_pmu_params_t *params)
+{
+    struct vcpu *v;
+    struct vpmu_struct *vpmu;
+    uint64_t mfn;
+
+    if ( (params->vcpu >= d->max_vcpus) || (d->vcpu == NULL) ||
+         (d->vcpu[params->vcpu] == NULL) )
+        return;
+
+    v = d->vcpu[params->vcpu];
+    if ( v != current )
+        vcpu_pause(v);
+
+    vpmu = vcpu_vpmu(v);
+    spin_lock(&vpmu->vpmu_lock);
+
+    if ( v->arch.vpmu.xenpmu_data )
+    {
+        mfn = domain_page_map_to_mfn(v->arch.vpmu.xenpmu_data);
+        ASSERT(mfn != 0);
+        unmap_domain_page_global(v->arch.vpmu.xenpmu_data);
+        put_page_and_type(mfn_to_page(mfn));
+        v->arch.vpmu.xenpmu_data = NULL;
+    }
+    vpmu_destroy(v);
+
+    spin_unlock(&vpmu->vpmu_lock);
+
+    if ( v != current )
+        vcpu_unpause(v);
 }
 
 /* Dump some vpmu informations on console. Used in keyhandler dump_domains(). */
@@ -402,7 +486,7 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 
         if ( copy_to_guest(arg, &pmu_params, 1) )
             return -EFAULT;
-        break;
+         break;
 
     case XENPMU_feature_set:
         if ( copy_from_guest(&pmu_params, arg, 1) )
@@ -420,6 +504,18 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
             return -EFAULT;
         break;
 
+    case XENPMU_init:
+        if ( copy_from_guest(&pmu_params, arg, 1) )
+            return -EFAULT;
+        ret = pvpmu_init(current->domain, &pmu_params);
+        break;
+
+    case XENPMU_finish:
+        if ( copy_from_guest(&pmu_params, arg, 1) )
+            return -EFAULT;
+        pvpmu_finish(current->domain, &pmu_params);
+        break;
+
     default:
         ret = -EINVAL;
     }
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 7d6de54..a991b2d 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -108,6 +108,7 @@ static int virq_is_global(uint32_t virq)
     case VIRQ_TIMER:
     case VIRQ_DEBUG:
     case VIRQ_XENOPROF:
+    case VIRQ_XENPMU:
         rc = 0;
         break;
     case VIRQ_ARCH_0 ... VIRQ_ARCH_7:
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 97fe17c..ada2ab7 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -64,6 +64,8 @@ struct vpmu_struct {
     void *context;      /* May be shared with PV guest */
     void *priv_context; /* hypervisor-only */
     struct arch_vpmu_ops *arch_vpmu_ops;
+    struct xen_pmu_data *xenpmu_data;
+    spinlock_t vpmu_lock;
 };
 
 /* VPMU states */
diff --git a/xen/include/public/pmu.h b/xen/include/public/pmu.h
index 66cc494..afb4ca1 100644
--- a/xen/include/public/pmu.h
+++ b/xen/include/public/pmu.h
@@ -25,6 +25,8 @@
 #define XENPMU_mode_set        1
 #define XENPMU_feature_get     2
 #define XENPMU_feature_set     3
+#define XENPMU_init            4
+#define XENPMU_finish          5
 /* ` } */
 
 /* Parameters structure for HYPERVISOR_xenpmu_op call */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 0766790..e4d0b79 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -161,6 +161,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #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       */
+#define VIRQ_XENPMU     13 /* V.  PMC interrupt                              */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index c637454..ae47135 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -665,6 +665,9 @@ static XSM_INLINE int xsm_pmu_op (XSM_DEFAULT_ARG struct domain *d, int op)
     case XENPMU_feature_set:
     case XENPMU_feature_get:
         return xsm_default_action(XSM_PRIV, d, current->domain);
+    case XENPMU_init:
+    case XENPMU_finish: 
+        return xsm_default_action(XSM_HOOK, d, current->domain);
     default:
         return -EPERM;
     }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8e1914e..76f2cf1 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1515,6 +1515,10 @@ static int flask_pmu_op (struct domain *d, int op)
     case XENPMU_feature_get:
         return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN2,
                             XEN2__PMU_CTRL, NULL);
+    case XENPMU_init:
+    case XENPMU_finish:
+        return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN2,
+                            XEN2__PMU_USE, NULL);
     default:
         return -EPERM;
     }
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 3289d98..b84af31 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -87,6 +87,8 @@ class xen2
     get_symbol
 # PMU control
     pmu_ctrl
+# PMU use (domains, including unprivileged ones, will be using this operation)
+    pmu_use
 }
 
 # Classes domain and domain2 consist of operations that a domain performs on
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94i-00010b-7h; Sun, 16 Nov 2014 23:17:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94g-0000xo-6J
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:42 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	15/52-03148-59039645; Sun, 16 Nov 2014 23:17:41 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416179859!12903943!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21375 invoked from network); 16 Nov 2014 23:17:40 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:40 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHWdT007753
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:32 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHVHD024215
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 16 Nov 2014 23:17:31 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAGNHTqV016631; Sun, 16 Nov 2014 23:17:30 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:29 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:46 -0500
Message-Id: <1416179271-1221-17-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 16/21] x86/VPMU: Add support for PMU
	register handling on 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Intercept accesses to PMU MSRs and process them in VPMU module.

Dump VPMU state for all domains (HVM and PV) when requested.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/domain.c             |  3 +--
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 49 ++++++++++++++++++++++++++++++++------
 xen/arch/x86/traps.c              | 50 ++++++++++++++++++++++++++++++++++++++-
 3 files changed, 92 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0de8a20..37c6371 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2075,8 +2075,7 @@ void arch_dump_vcpu_info(struct vcpu *v)
 {
     paging_dump_vcpu_info(v);
 
-    if ( is_hvm_vcpu(v) )
-        vpmu_dump(v);
+    vpmu_dump(v);
 }
 
 void domain_cpuid(
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 2dd8000..839dce0 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -27,6 +27,7 @@
 #include <asm/regs.h>
 #include <asm/types.h>
 #include <asm/apic.h>
+#include <asm/traps.h>
 #include <asm/msr.h>
 #include <asm/msr-index.h>
 #include <asm/hvm/support.h>
@@ -299,12 +300,18 @@ static inline void __core2_vpmu_save(struct vcpu *v)
         rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, fixed_counters[i]);
     for ( i = 0; i < arch_pmc_cnt; i++ )
         rdmsrl(MSR_IA32_PERFCTR0 + i, xen_pmu_cntr_pair[i].counter);
+
+    if ( !has_hvm_container_vcpu(v) )
+        rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
 static int core2_vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
+    if ( !has_hvm_container_vcpu(v) )
+        wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+
     if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
         return 0;
 
@@ -342,6 +349,13 @@ static inline void __core2_vpmu_load(struct vcpu *v)
     wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
     wrmsrl(MSR_IA32_DS_AREA, core2_vpmu_cxt->ds_area);
     wrmsrl(MSR_IA32_PEBS_ENABLE, core2_vpmu_cxt->pebs_enable);
+
+    if ( !has_hvm_container_vcpu(v) )
+    {
+        wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, core2_vpmu_cxt->global_ovf_ctrl);
+        core2_vpmu_cxt->global_ovf_ctrl = 0;
+        wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
+    }
 }
 
 static void core2_vpmu_load(struct vcpu *v)
@@ -442,7 +456,6 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
 static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
                                uint64_t supported)
 {
-    u64 global_ctrl;
     int i, tmp;
     int type = -1, index = -1;
     struct vcpu *v = current;
@@ -486,7 +499,12 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     switch ( msr )
     {
     case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+        if ( msr_content & ~(0xC000000000000000 |
+                             (((1ULL << fixed_pmc_cnt) - 1) << 32) |
+                             ((1ULL << arch_pmc_cnt) - 1)) )
+            return 1;
         core2_vpmu_cxt->global_status &= ~msr_content;
+        wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
         return 0;
     case MSR_CORE_PERF_GLOBAL_STATUS:
         gdprintk(XENLOG_INFO, "Can not write readonly MSR: "
@@ -514,14 +532,18 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
         return 0;
     case MSR_CORE_PERF_GLOBAL_CTRL:
-        global_ctrl = msr_content;
+        core2_vpmu_cxt->global_ctrl = msr_content;
         break;
     case MSR_CORE_PERF_FIXED_CTR_CTRL:
         if ( msr_content &
              ( ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1)) )
             return 1;
 
-        vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+        if ( has_hvm_container_vcpu(v) )
+            vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
+                               &core2_vpmu_cxt->global_ctrl);
+        else
+            rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
         *enabled_cntrs &= ~(((1ULL << fixed_pmc_cnt) - 1) << 32);
         if ( msr_content != 0 )
         {
@@ -546,7 +568,11 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
             if ( msr_content & (~((1ull << 32) - 1)) )
                 return 1;
 
-            vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+            if ( has_hvm_container_vcpu(v) )
+                vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
+                                   &core2_vpmu_cxt->global_ctrl);
+            else
+                rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
 
             if ( msr_content & (1ULL << 22) )
                 *enabled_cntrs |= 1ULL << tmp;
@@ -560,9 +586,15 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     if ( type != MSR_TYPE_GLOBAL )
         wrmsrl(msr, msr_content);
     else
-        vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+    {
+        if ( has_hvm_container_vcpu(v) )
+            vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+        else
+            wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+    }
 
-    if ( (global_ctrl & *enabled_cntrs) || (core2_vpmu_cxt->ds_area != 0) )
+    if ( (core2_vpmu_cxt->global_ctrl & *enabled_cntrs) ||
+         (core2_vpmu_cxt->ds_area != 0) )
         vpmu_set(vpmu, VPMU_RUNNING);
     else
         vpmu_reset(vpmu, VPMU_RUNNING);
@@ -589,7 +621,10 @@ static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
             *msr_content = core2_vpmu_cxt->global_status;
             break;
         case MSR_CORE_PERF_GLOBAL_CTRL:
-            vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+            if ( has_hvm_container_vcpu(v) )
+                vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+            else
+                rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, *msr_content);
             break;
         default:
             rdmsrl(msr, *msr_content);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 10fc2ca..70477b2 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -72,6 +72,7 @@
 #include <asm/apic.h>
 #include <asm/mc146818rtc.h>
 #include <asm/hpet.h>
+#include <asm/hvm/vpmu.h>
 #include <public/arch-x86/cpuid.h>
 #include <xsm/xsm.h>
 
@@ -896,8 +897,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
         __clear_bit(X86_FEATURE_TOPOEXT % 32, &c);
         break;
 
+    case 0x0000000a: /* Architectural Performance Monitor Features (Intel) */
+        break;
+
     case 0x00000005: /* MONITOR/MWAIT */
-    case 0x0000000a: /* Architectural Performance Monitor Features */
     case 0x0000000b: /* Extended Topology Enumeration */
     case 0x8000000a: /* SVM revision and features */
     case 0x8000001b: /* Instruction Based Sampling */
@@ -913,6 +916,9 @@ void pv_cpuid(struct cpu_user_regs *regs)
     }
 
  out:
+    /* VPMU may decide to modify some of the leaves */
+    vpmu_do_cpuid(regs->eax, &a, &b, &c, &d);
+
     regs->eax = a;
     regs->ebx = b;
     regs->ecx = c;
@@ -1935,6 +1941,7 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
     char io_emul_stub[32];
     void (*io_emul)(struct cpu_user_regs *) __attribute__((__regparm__(1)));
     uint64_t val, msr_content;
+    bool_t vpmu_msr;
 
     if ( !read_descriptor(regs->cs, v, regs,
                           &code_base, &code_limit, &ar,
@@ -2425,6 +2432,7 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
         uint32_t eax = regs->eax;
         uint32_t edx = regs->edx;
         msr_content = ((uint64_t)edx << 32) | eax;
+        vpmu_msr = 0;
         switch ( (u32)regs->ecx )
         {
         case MSR_FS_BASE:
@@ -2561,6 +2569,22 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
             if ( v->arch.debugreg[7] & DR7_ACTIVE_MASK )
                 wrmsrl(regs->_ecx, msr_content);
             break;
+        case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+        case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
+        case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+        case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+            if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+            {
+                vpmu_msr = 1;
+        case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR5:
+                if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+                {
+                    if ( vpmu_do_wrmsr(regs->ecx, msr_content, 0) )
+                        goto fail;
+                }
+                break;
+            }
+            /*FALLTHROUGH*/
 
         default:
             if ( wrmsr_hypervisor_regs(regs->ecx, msr_content) == 1 )
@@ -2593,6 +2617,7 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
         break;
 
     case 0x32: /* RDMSR */
+        vpmu_msr = 0;
         switch ( (u32)regs->ecx )
         {
         case MSR_FS_BASE:
@@ -2663,6 +2688,29 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
                             [regs->_ecx - MSR_AMD64_DR1_ADDRESS_MASK + 1];
             regs->edx = 0;
             break;
+        case MSR_IA32_PERF_CAPABILITIES:
+            /* No extra capabilities are supported */
+            regs->eax = regs->edx = 0;
+            break;
+        case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+        case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
+        case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+        case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+            if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+            {
+                vpmu_msr = 1;
+        case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR5:
+                if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+                {
+                    if ( vpmu_do_rdmsr(regs->ecx, &msr_content) )
+                        goto fail;
+
+                    regs->eax = (uint32_t)msr_content;
+                    regs->edx = (uint32_t)(msr_content >> 32);
+                }
+                break;
+            }
+            /*FALLTHROUGH*/
 
         default:
             if ( rdmsr_hypervisor_regs(regs->ecx, &val) )
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Q-0000m1-Qe; Sun, 16 Nov 2014 23:17:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94O-0000lY-T6
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:25 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	0A/B5-17958-48039645; Sun, 16 Nov 2014 23:17:24 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416179841!9308243!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6713 invoked from network); 16 Nov 2014 23:17:23 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHFpx007641
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:15 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHDZE023701
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:13 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHDGX012564; Sun, 16 Nov 2014 23:17:13 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:13 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:30 -0500
Message-Id: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 00/21] x86/PMU: Xen PMU PV(H) support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Version 15 of PV(H) PMU patches.

Changes in v15:

* Rewrote vpmu_force_context_switch() to use continue_hypercall_on_cpu()
* Added vpmu_init initcall that will call vendor-specific init routines
* Added a lock to vpmu_struct to serialize pmu_init()/pmu_finish()
* Use SS instead of CS for DPL (instead of RPL)
* Don't take lock for XENPMU_mode_get
* Make vmpu_mode/features an unsigned int (from uint64_t)
* Adjusted pvh_hypercall64_table[] order
* Replaced address range check [XEN_VIRT_START..XEN_VIRT_END] with guest_mode()
* A few style cleanups

Changes in v14:

* Moved struct xen_pmu_regs to pmu.h
* Moved CHECK_pmu_* to an earlier patch (when structures are first introduced)
* Added PMU_SAMPLE_REAL flag to indicate whether the sample was taken in real mode
* Simplified slightly setting rules for xenpmu_data flags
* Rewrote vpmu_force_context_switch() to again use continuations. (Returning EAGAIN
  to user would mean that VPMU mode may get into inconsistent state (across processors)
  and dealing with that is more compicated than I'd like).
* Fixed msraddr_to_bitpos() and converted it into an inline
* Replaced address range check in vmpu_do_interrupt() with guest_mode()
* No error returns from __initcall
* Rebased on top of recent VPMU changes
* Various cleanups

Changes in v13:

* Rearranged data in xenpf_symdata to eliminate a hole (no change in
  structure size)
* Removed unnecessary zeroing of last character in name string during
  symbol read hypercall
* Updated comment in access_vectors for pmu_use operation
* Compute AMD MSR bank size at runtime
* Moved a couple of BUILD_BUG_ON later, to when the structures they are
  checking are first used
* Added ss and eflags to xen_pmu_registers structure
* vpmu_force_context_switch() uses per-cpu tasklet pointers.
* Moved most of arch-specific VPMU initialization code into an __initcall()
  to avoid re-calculating/re-checking things more than once (new patch, #12)
* Replaced is_*_domain() with is_*_vcpu()
* choose_hwdom_vcpu() will now assume that hardware_domain->vcpu[idx]
  is always there (callers will still verify whether or not that's true)
* Fixed a couple of sampled vs. sampling tests in vpmu_do_interrupt()
* Pass CS to the guest unchanged, add pmu_flags's flag to indicate whether the
  sample was for a user or kernel space. Move pmu_flags from xen_pmu_data into
  xen_pmu_arch
* Removed local msr_content variable from vpmu_do_wrmsr()
* Re-arranged code in parse_vpmu_param()
* Made vpmu_interrupt_type checks test for value, not individual bits
* Moved PMU_SOFTIRQ definition into arch-specific header
* Moved vpmu*.c files into xen/arch/x86/cpu/ instead of xen/arch/x86/
* For hypervisor samples, report DOMID_XEN to the guest
* Changed logic to select which registers to report to the guest (include RIP
  check to see whether we are in the hypervisor)

Changes in v12:

* Added XSM support
* Made a valifity check before writing MSR_CORE_PERF_GLOBAL_OVF_CTRL
* Updated documentation for 'vpmu=nmi' option
* Added more text to a bunch of commit messages (per Konrad's request)

Changes in v11:

* Replaced cpu_user_regs with new xen_pmu_regs (IP, SP, CS) in xen_pmu_arch.
  - as part of this re-work noticed that CS registers were set in later patch then
    needed. Moved those changes to appropriate place
* Added new VPMU mode (XENPMU_MODE_HV). Now XENPMU_MODE_SELF will only provide dom0
  with its own samples only (i.e. no hypervisor data) and XENPMU_MODE_HV will be what
  XENPMU_MODE_SELF used to be.
* Kept  vmx_add_guest_msr()/vmx_add_host_load_msr() as wrappers around vmx_add_msr()
* Cleaned up VPMU context switch macros (moved  'if(prev!=next)' back to context_switch())
* Dropped hypercall continuation from vpmu_force_context_switch() and replaced it with
  -EAGAIN error if hypercall_preempt_check() is true after 2ms.
* Kept vpmu_do_rdmsr()/vpmu_do_wrmsr as wrapperd for vpmu_do_msr()
* Move context switching patch (#13) earlier in the series (for proper bisection support)
* Various comment updates and cleanups
* Dropped a bunch of Reviewed-by and all Tested-by tags

Changes in v10:

* Swapped address and name fields of xenpf_symdata (to make it smaller on 32-bit)
* Dropped vmx_rm_guest_msr() as it requires refcountig which makes code more complicated.
* Cleaned up vlapic_reg_write()
* Call vpmu_destroy() for both HVM and PVH VCPUs
* Verify that (xen_pmu_data+PMU register bank) fit into a page
* Return error codes from arch-specific VPMU init code
* Moved VPMU-related context switch logic into inlines
* vpmu_force_context_switch() changes:
  o Avoid greater than page-sized allocations
  o Prevent another VCPU from starting VPMU sync while the first sync is in progress
* Avoid stack leak in do_xenpmu_op()
* Checked validity of Intel VPMU MSR values before they are committed
* Fixed MSR handling in traps.c (avoid potential accesses to Intel MSRs on AMD)
* Fixed VCPU selection in interrupt handler for 32-bit dom0 (sampled => sampling)
* Clarified commit messages (patches 2, 13, 18) 
* Various cleanups

Changes in v9:

* Restore VPMU context after context_saved() is called in
  context_switch(). This is needed because vpmu_load() may end up
  calling vmx_vmcs_try_enter()->vcpu_pause() and that needs is_running
  to be correctly set/cleared. (patch 18, dropped review acks)
* Added patch 2 to properly manage VPMU_CONTEXT_LOADED
* Addressed most of Jan's comments.
  o Keep track of time in vpmu_force_context_switch() to properly break
    out of a loop when using hypercall continuations
  o Fixed logic in calling vpmu_do_msr() in emulate_privileged_op()
  o Cleaned up vpmu_interrupt() wrt vcpu variable names to (hopefully)
    make it more clear which vcpu we are using
  o Cleaned up vpmu_do_wrmsr()
  o Did *not* replace sizeof(uint64_t) with sizeof(variable) in
    amd_vpmu_initialise(): throughout the code registers are declared as
    uint64_t and if we are to add a new type (e.g. reg_t) this should be
    done in a separate patch, unrelated to this series.
  o Various more minor cleanups and code style fixes
  
Changes in v8:

* Cleaned up a bit definitions of struct xenpf_symdata and xen_pmu_params
* Added compat checks for vpmu structures
* Converted vpmu flag manipulation macros to inline routines
* Reimplemented vpmu_unload_all() to avoid long loops
* Reworked PMU fault generation and handling (new patch #12)
* Added checks for domain->vcpu[] non-NULLness
* Added more comments, renamed some routines and macros, code style cleanup


Changes in v7:

* When reading hypervisor symbols make the caller pass buffer length
  (as opposed to having this length be part of the API). Make the
  hypervisor buffer static, make xensyms_read() return zero-length
  string on end-of-symbols. Make 'type' field of xenpf_symdata a char,
  drop compat_pf_symdata definition.
* Spread PVH support across patches as opposed to lumping it into a
  separate patch
* Rename vpmu_is_set_all() to vpmu_are_all_set()
* Split VPMU cleanup patch in two
* Use memmove when copying VMX guest and host MSRs
* Make padding of xen_arch_pmu's context union a constand that does not
  depend on arch context size.
* Set interface version to 0.1
* Check pointer validity in pvpmu_init/destroy()
* Fixed crash in core2_vpmu_dump()
* Fixed crash in vmx_add_msr()
* Break handling of Intel and AMD MSRs in traps.c into separate cases
* Pass full CS selector to guests
* Add lock in pvpmu init code to prevent potential race


Changes in v6:

* Two new patches:
  o Merge VMX MSR add/remove routines in vmcs.c (patch 5)
  o Merge VPMU read/write MSR routines in vpmu.c (patch 14)
* Check for pending NMI softirq after saving VPMU context to prevent a newly-scheduled
  guest from overwriting sampled_vcpu written by de-scheduled VPCU.
* Keep track of enabled counters on Intel. This was removed in earlier patches and
  was a mistake. As result of this change struct vpmu will have a pointer to private
  context data (i.e. data that is not exposed to a PV(H) guest). Use this private pointer
  on SVM as well for storing MSR bitmap status (it was unnecessarily exposed to PV guests
  earlier).
  Dropped Reviewed-by: and Tested-by: tags from patch 4 since it needs to be reviewed
  agan (core2_vpmu_do_wrmsr() routine, mostly)
* Replaced references to dom0 with hardware_domain (and is_control_domain with
  is_hardware_domain for consistency)
* Prevent non-privileged domains from reading PMU MSRs in VPMU_PRIV_MODE
* Reverted unnecessary changes in vpmu_initialise()'s switch statement
* Fixed comment in vpmu_do_interrupt


Changes in v5:

* Dropped patch number 2 ("Stop AMD counters when called from vpmu_save_force()")
  as no longer needed
* Added patch number 2 that marks context as loaded before PMU registers are
  loaded. This prevents situation where a PMU interrupt may occur while context
  is still viewed as not loaded. (This is really a bug fix for exsiting VPMU
  code)
* Renamed xenpmu.h files to pmu.h
* More careful use of is_pv_domain(), is_hvm_domain(, is_pvh_domain and
  has_hvm_container_domain(). Also explicitly disabled support for PVH until
  patch 16 to make distinction between usage of the above macros more clear.
* Added support for disabling VPMU support during runtime.
* Disable VPMUs for non-privileged domains when switching to privileged
  profiling mode
* Added ARM stub for xen_arch_pmu_t
* Separated vpmu_mode from vpmu_features
* Moved CS register query to make sure we use appropriate query mechanism for
  various guest types.
* LVTPC is now set from value in shared area, not copied from dom0
* Various code and comments cleanup as suggested by Jan.

Changes in v4:

* Added support for PVH guests:
  o changes in pvpmu_init() to accommodate both PV and PVH guests, still in patch 10
  o more careful use of is_hvm_domain
  o Additional patch (16)
* Moved HVM interrupt handling out of vpmu_do_interrupt() for NMI-safe handling
* Fixed dom0's VCPU selection in privileged mode
* Added a cast in register copy for 32-bit PV guests cpu_user_regs_t in vpmu_do_interrupt.
  (don't want to expose compat_cpu_user_regs in a public header)
* Renamed public structures by prefixing them with "xen_"
* Added an entry for xenpf_symdata in xlat.lst
* Fixed pv_cpuid check for vpmu-specific cpuid adjustments
* Varios code style fixes
* Eliminated anonymous unions
* Added more verbiage to NMI patch description


Changes in v3:

* Moved PMU MSR banks out from architectural context data structures to allow
for future expansion without protocol changes
* PMU interrupts can be either NMIs or regular vector interrupts (the latter
is the default)
* Context is now marked as PMU_CACHED by the hypervisor code to avoid certain
race conditions with the guest
* Fixed races with PV guest in MSR access handlers
* More Intel VPMU cleanup
* Moved NMI-unsafe code from NMI handler
* Dropped changes to vcpu->is_running
* Added LVTPC apic handling (cached for PV guests)
* Separated privileged profiling mode into a standalone patch
* Separated NMI handling into a standalone patch


Changes in v2:

* Xen symbols are exported as data structure (as opoosed to a set of formatted
strings in v1). Even though one symbol per hypercall is returned performance
appears to be acceptable: reading whole file from dom0 userland takes on average
about twice as long as reading /proc/kallsyms
* More cleanup of Intel VPMU code to simplify publicly exported structures
* There is an architecture-independent and x86-specific public include files (ARM
has a stub)
* General cleanup of public include files to make them more presentable (and
to make auto doc generation better)
* Setting of vcpu->is_running is now done on ARM in schedule_tail as well (making
changes to common/schedule.c architecture-independent). Note that this is not
tested since I don't have access to ARM hardware.
* PCPU ID of interrupted processor is now passed to PV guest


The following patch series adds PMU support in Xen for PV(H)
guests. There is a companion patchset for Linux kernel. In addition,
another set of changes will be provided (later) for userland perf
code.

This version has following limitations:
* For accurate profiling of dom0/Xen dom0 VCPUs should be pinned.
* Hypervisor code is only profiled on processors that have running dom0 VCPUs
on them.
* No backtrace support.

A few notes that may help reviewing:

* A shared data structure (xenpmu_data_t) between each PV VPCU and hypervisor
CPU is used for passing registers' values as well as PMU state at the time of
PMU interrupt.
* PMU interrupts are taken by hypervisor either as NMIs or regular vector
interrupts for both HVM and PV(H). The interrupts are sent as NMIs to HVM guests
and as virtual interrupts to PV(H) guests
* PV guest's interrupt handler does not read/write PMU MSRs directly. Instead, it
accesses xenpmu_data_t and flushes it to HW it before returning.
* PMU mode is controlled at runtime via /sys/hypervisor/pmu/pmu/{pmu_mode,pmu_flags}
in addition to 'vpmu' boot option (which is preserved for back compatibility).
The following modes are provided:
  * disable: VPMU is off
  * enable: VPMU is on. Guests can profile themselves, dom0 profiles itself and Xen
  * priv_enable: dom0 only profiling. dom0 collects samples for everyone. Sampling
    in guests is suspended.
* /proc/xen/xensyms file exports hypervisor's symbols to dom0 (similar to
/proc/kallsyms)
* VPMU infrastructure is now used for HVM, PV and PVH and therefore has been moved
up from hvm subtree


Boris Ostrovsky (21):
  common/symbols: Export hypervisor symbols to privileged guest
  x86/VPMU: Manage VPMU_CONTEXT_SAVE flag in vpmu_save_force()
  x86/VPMU: Set MSR bitmaps only for HVM/PVH guests
  x86/VPMU: Make vpmu macros a bit more efficient
  intel/VPMU: Clean up Intel VPMU code
  vmx: Merge MSR management routines
  x86/VPMU: Handle APIC_LVTPC accesses
  intel/VPMU: MSR_CORE_PERF_GLOBAL_CTRL should be initialized to zero
  x86/VPMU: Add public xenpmu.h
  x86/VPMU: Make vpmu not HVM-specific
  x86/VPMU: Interface for setting PMU mode and flags
  x86/VPMU: Initialize VPMUs with __initcall
  x86/VPMU: Initialize PMU for PV(H) guests
  x86/VPMU: Save VPMU state for PV guests during context switch
  x86/VPMU: When handling MSR accesses, leave fault injection to callers
  x86/VPMU: Add support for PMU register handling on PV guests
  x86/VPMU: Handle PMU interrupts for PV guests
  x86/VPMU: Merge vpmu_rdmsr and vpmu_wrmsr
  x86/VPMU: Add privileged PMU mode
  x86/VPMU: NMI-based VPMU support
  x86/VPMU: Move VPMU files up from hvm/ directory

 docs/misc/xen-command-line.markdown                |   8 +-
 tools/flask/policy/policy/modules/xen/xen.te       |   7 +
 xen/arch/x86/cpu/Makefile                          |   1 +
 xen/arch/x86/cpu/vpmu.c                            | 873 +++++++++++++++++++++
 xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c}    | 245 +++---
 .../x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 780 +++++++++---------
 xen/arch/x86/domain.c                              |  25 +-
 xen/arch/x86/hvm/Makefile                          |   1 -
 xen/arch/x86/hvm/hvm.c                             |   1 +
 xen/arch/x86/hvm/svm/Makefile                      |   1 -
 xen/arch/x86/hvm/svm/svm.c                         |  10 +-
 xen/arch/x86/hvm/vlapic.c                          |   3 +
 xen/arch/x86/hvm/vmx/Makefile                      |   1 -
 xen/arch/x86/hvm/vmx/vmcs.c                        |  84 +-
 xen/arch/x86/hvm/vmx/vmx.c                         |  28 +-
 xen/arch/x86/hvm/vpmu.c                            | 263 -------
 xen/arch/x86/oprofile/op_model_ppro.c              |   8 +-
 xen/arch/x86/platform_hypercall.c                  |  28 +
 xen/arch/x86/traps.c                               |  62 +-
 xen/arch/x86/x86_64/compat/entry.S                 |   4 +
 xen/arch/x86/x86_64/entry.S                        |   4 +
 xen/common/event_channel.c                         |   1 +
 xen/common/symbols.c                               |  54 ++
 xen/include/Makefile                               |   2 +
 xen/include/asm-x86/domain.h                       |   2 +
 xen/include/asm-x86/hvm/vcpu.h                     |   3 -
 xen/include/asm-x86/hvm/vmx/vmcs.h                 |  18 +-
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h           |  51 --
 xen/include/asm-x86/softirq.h                      |   3 +-
 xen/include/asm-x86/{hvm => }/vpmu.h               |  96 ++-
 xen/include/public/arch-arm.h                      |   3 +
 xen/include/public/arch-x86/pmu.h                  |  95 +++
 xen/include/public/platform.h                      |  19 +
 xen/include/public/pmu.h                           |  90 +++
 xen/include/public/xen.h                           |   2 +
 xen/include/xen/hypercall.h                        |   4 +
 xen/include/xen/symbols.h                          |   3 +
 xen/include/xlat.lst                               |   6 +
 xen/include/xsm/dummy.h                            |  20 +
 xen/include/xsm/xsm.h                              |   6 +
 xen/xsm/dummy.c                                    |   1 +
 xen/xsm/flask/hooks.c                              |  28 +
 xen/xsm/flask/policy/access_vectors                |   6 +
 43 files changed, 2018 insertions(+), 932 deletions(-)
 create mode 100644 xen/arch/x86/cpu/vpmu.c
 rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (68%)
 rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (58%)
 delete mode 100644 xen/arch/x86/hvm/vpmu.c
 delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
 rename xen/include/asm-x86/{hvm => }/vpmu.h (54%)
 create mode 100644 xen/include/public/arch-x86/pmu.h
 create mode 100644 xen/include/public/pmu.h

-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94W-0000nV-5A; Sun, 16 Nov 2014 23:17:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94T-0000mS-Mj
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F4/92-09842-98039645; Sun, 16 Nov 2014 23:17:29 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416179846!13128348!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13249 invoked from network); 16 Nov 2014 23:17:28 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHJnL007688
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:20 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHIdt016391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:19 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHIKN012697; Sun, 16 Nov 2014 23:17:18 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:17 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:35 -0500
Message-Id: <1416179271-1221-6-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 05/21] intel/VPMU: Clean up Intel VPMU code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove struct pmumsr and core2_pmu_enable. Replace static MSR structures with
fields in core2_vpmu_context.

Call core2_get_pmc_count() once, during initialization.

Properly clean up when core2_vpmu_alloc_resource() fails.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vmx/vpmu_core2.c        | 381 ++++++++++++++-----------------
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |  19 --
 2 files changed, 172 insertions(+), 228 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index f2e9735..09af846 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -69,6 +69,27 @@
 static bool_t __read_mostly full_width_write;
 
 /*
+ * MSR_CORE_PERF_FIXED_CTR_CTRL contains the configuration of all fixed
+ * counters. 4 bits for every counter.
+ */
+#define FIXED_CTR_CTRL_BITS 4
+#define FIXED_CTR_CTRL_MASK ((1 << FIXED_CTR_CTRL_BITS) - 1)
+
+#define VPMU_CORE2_MAX_FIXED_PMCS     4
+struct core2_vpmu_context {
+    u64 fixed_ctrl;
+    u64 ds_area;
+    u64 pebs_enable;
+    u64 global_ovf_status;
+    u64 enabled_cntrs;  /* Follows PERF_GLOBAL_CTRL MSR format */
+    u64 fix_counters[VPMU_CORE2_MAX_FIXED_PMCS];
+    struct arch_msr_pair arch_msr_pair[1];
+};
+
+/* Number of general-purpose and fixed performance counters */
+static unsigned int __read_mostly arch_pmc_cnt, fixed_pmc_cnt;
+
+/*
  * QUIRK to workaround an issue on various family 6 cpus.
  * The issue leads to endless PMC interrupt loops on the processor.
  * If the interrupt handler is running and a pmc reaches the value 0, this
@@ -88,11 +109,8 @@ static void check_pmc_quirk(void)
         is_pmc_quirk = 0;    
 }
 
-static int core2_get_pmc_count(void);
 static void handle_pmc_quirk(u64 msr_content)
 {
-    int num_gen_pmc = core2_get_pmc_count();
-    int num_fix_pmc  = 3;
     int i;
     u64 val;
 
@@ -100,7 +118,7 @@ static void handle_pmc_quirk(u64 msr_content)
         return;
 
     val = msr_content;
-    for ( i = 0; i < num_gen_pmc; i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
     {
         if ( val & 0x1 )
         {
@@ -112,7 +130,7 @@ static void handle_pmc_quirk(u64 msr_content)
         val >>= 1;
     }
     val = msr_content >> 32;
-    for ( i = 0; i < num_fix_pmc; i++ )
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
     {
         if ( val & 0x1 )
         {
@@ -125,128 +143,91 @@ static void handle_pmc_quirk(u64 msr_content)
     }
 }
 
-static const u32 core2_fix_counters_msr[] = {
-    MSR_CORE_PERF_FIXED_CTR0,
-    MSR_CORE_PERF_FIXED_CTR1,
-    MSR_CORE_PERF_FIXED_CTR2
-};
-
 /*
- * MSR_CORE_PERF_FIXED_CTR_CTRL contains the configuration of all fixed
- * counters. 4 bits for every counter.
+ * Read the number of general counters via CPUID.EAX[0xa].EAX[8..15]
  */
-#define FIXED_CTR_CTRL_BITS 4
-#define FIXED_CTR_CTRL_MASK ((1 << FIXED_CTR_CTRL_BITS) - 1)
-
-/* The index into the core2_ctrls_msr[] of this MSR used in core2_vpmu_dump() */
-#define MSR_CORE_PERF_FIXED_CTR_CTRL_IDX 0
-
-/* Core 2 Non-architectual Performance Control MSRs. */
-static const u32 core2_ctrls_msr[] = {
-    MSR_CORE_PERF_FIXED_CTR_CTRL,
-    MSR_IA32_PEBS_ENABLE,
-    MSR_IA32_DS_AREA
-};
-
-struct pmumsr {
-    unsigned int num;
-    const u32 *msr;
-};
-
-static const struct pmumsr core2_fix_counters = {
-    VPMU_CORE2_NUM_FIXED,
-    core2_fix_counters_msr
-};
+static int core2_get_arch_pmc_count(void)
+{
+    u32 eax;
 
-static const struct pmumsr core2_ctrls = {
-    VPMU_CORE2_NUM_CTRLS,
-    core2_ctrls_msr
-};
-static int arch_pmc_cnt;
+    eax = cpuid_eax(0xa);
+    return MASK_EXTR(eax, PMU_GENERAL_NR_MASK);
+}
 
 /*
- * Read the number of general counters via CPUID.EAX[0xa].EAX[8..15]
+ * Read the number of fixed counters via CPUID.EDX[0xa].EDX[0..4]
  */
-static int core2_get_pmc_count(void)
+static int core2_get_fixed_pmc_count(void)
 {
-    u32 eax, ebx, ecx, edx;
+    u32 eax;
 
-    if ( arch_pmc_cnt == 0 )
-    {
-        cpuid(0xa, &eax, &ebx, &ecx, &edx);
-        arch_pmc_cnt = (eax & PMU_GENERAL_NR_MASK) >> PMU_GENERAL_NR_SHIFT;
-    }
-
-    return arch_pmc_cnt;
+    eax = cpuid_eax(0xa);
+    return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
 }
 
 static u64 core2_calc_intial_glb_ctrl_msr(void)
 {
-    int arch_pmc_bits = (1 << core2_get_pmc_count()) - 1;
-    u64 fix_pmc_bits  = (1 << 3) - 1;
-    return ((fix_pmc_bits << 32) | arch_pmc_bits);
+    int arch_pmc_bits = (1 << arch_pmc_cnt) - 1;
+    u64 fix_pmc_bits  = (1 << fixed_pmc_cnt) - 1;
+
+    return (fix_pmc_bits << 32) | arch_pmc_bits;
 }
 
 /* edx bits 5-12: Bit width of fixed-function performance counters  */
 static int core2_get_bitwidth_fix_count(void)
 {
-    u32 eax, ebx, ecx, edx;
+    u32 edx;
 
-    cpuid(0xa, &eax, &ebx, &ecx, &edx);
-    return ((edx & PMU_FIXED_WIDTH_MASK) >> PMU_FIXED_WIDTH_SHIFT);
+    edx = cpuid_edx(0xa);
+    return MASK_EXTR(edx, PMU_FIXED_WIDTH_MASK);
 }
 
 static int is_core2_vpmu_msr(u32 msr_index, int *type, int *index)
 {
-    int i;
     u32 msr_index_pmc;
 
-    for ( i = 0; i < core2_fix_counters.num; i++ )
+    switch ( msr_index )
     {
-        if ( core2_fix_counters.msr[i] == msr_index )
+    case MSR_CORE_PERF_FIXED_CTR_CTRL:
+    case MSR_IA32_DS_AREA:
+    case MSR_IA32_PEBS_ENABLE:
+        *type = MSR_TYPE_CTRL;
+        return 1;
+
+    case MSR_CORE_PERF_GLOBAL_CTRL:
+    case MSR_CORE_PERF_GLOBAL_STATUS:
+    case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+        *type = MSR_TYPE_GLOBAL;
+        return 1;
+
+    default:
+
+        if ( (msr_index >= MSR_CORE_PERF_FIXED_CTR0) &&
+             (msr_index < MSR_CORE_PERF_FIXED_CTR0 + fixed_pmc_cnt) )
         {
+            *index = msr_index - MSR_CORE_PERF_FIXED_CTR0;
             *type = MSR_TYPE_COUNTER;
-            *index = i;
             return 1;
         }
-    }
 
-    for ( i = 0; i < core2_ctrls.num; i++ )
-    {
-        if ( core2_ctrls.msr[i] == msr_index )
+        if ( (msr_index >= MSR_P6_EVNTSEL(0)) &&
+             (msr_index < MSR_P6_EVNTSEL(arch_pmc_cnt)) )
         {
-            *type = MSR_TYPE_CTRL;
-            *index = i;
+            *index = msr_index - MSR_P6_EVNTSEL(0);
+            *type = MSR_TYPE_ARCH_CTRL;
             return 1;
         }
-    }
-
-    if ( (msr_index == MSR_CORE_PERF_GLOBAL_CTRL) ||
-         (msr_index == MSR_CORE_PERF_GLOBAL_STATUS) ||
-         (msr_index == MSR_CORE_PERF_GLOBAL_OVF_CTRL) )
-    {
-        *type = MSR_TYPE_GLOBAL;
-        return 1;
-    }
-
-    msr_index_pmc = msr_index & MSR_PMC_ALIAS_MASK;
-    if ( (msr_index_pmc >= MSR_IA32_PERFCTR0) &&
-         (msr_index_pmc < (MSR_IA32_PERFCTR0 + core2_get_pmc_count())) )
-    {
-        *type = MSR_TYPE_ARCH_COUNTER;
-        *index = msr_index_pmc - MSR_IA32_PERFCTR0;
-        return 1;
-    }
 
-    if ( (msr_index >= MSR_P6_EVNTSEL(0)) &&
-         (msr_index < (MSR_P6_EVNTSEL(core2_get_pmc_count()))) )
-    {
-        *type = MSR_TYPE_ARCH_CTRL;
-        *index = msr_index - MSR_P6_EVNTSEL(0);
-        return 1;
+        msr_index_pmc = msr_index & MSR_PMC_ALIAS_MASK;
+        if ( (msr_index_pmc >= MSR_IA32_PERFCTR0) &&
+             (msr_index_pmc < (MSR_IA32_PERFCTR0 + arch_pmc_cnt)) )
+        {
+            *type = MSR_TYPE_ARCH_COUNTER;
+            *index = msr_index_pmc - MSR_IA32_PERFCTR0;
+            return 1;
+        }
+        return 0;
     }
-
-    return 0;
 }
 
 static void core2_vpmu_set_msr_bitmap(unsigned long *msr_bitmap)
@@ -254,13 +235,13 @@ static void core2_vpmu_set_msr_bitmap(unsigned long *msr_bitmap)
     int i;
 
     /* Allow Read/Write PMU Counters MSR Directly. */
-    for ( i = 0; i < core2_fix_counters.num; i++ )
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
     {
-        clear_bit(msraddr_to_bitpos(core2_fix_counters.msr[i]), msr_bitmap);
-        clear_bit(msraddr_to_bitpos(core2_fix_counters.msr[i]),
+        clear_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR0 + i), msr_bitmap);
+        clear_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR0 + i),
                   msr_bitmap + 0x800/BYTES_PER_LONG);
     }
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
     {
         clear_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0+i), msr_bitmap);
         clear_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0+i),
@@ -275,26 +256,28 @@ static void core2_vpmu_set_msr_bitmap(unsigned long *msr_bitmap)
     }
 
     /* Allow Read PMU Non-global Controls Directly. */
-    for ( i = 0; i < core2_ctrls.num; i++ )
-        clear_bit(msraddr_to_bitpos(core2_ctrls.msr[i]), msr_bitmap);
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
-        clear_bit(msraddr_to_bitpos(MSR_P6_EVNTSEL(i)), msr_bitmap);
+    for ( i = 0; i < arch_pmc_cnt; i++ )
+         clear_bit(msraddr_to_bitpos(MSR_P6_EVNTSEL(i)), msr_bitmap);
+
+    clear_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR_CTRL), msr_bitmap);
+    clear_bit(msraddr_to_bitpos(MSR_IA32_PEBS_ENABLE), msr_bitmap);
+    clear_bit(msraddr_to_bitpos(MSR_IA32_DS_AREA), msr_bitmap);
 }
 
 static void core2_vpmu_unset_msr_bitmap(unsigned long *msr_bitmap)
 {
     int i;
 
-    for ( i = 0; i < core2_fix_counters.num; i++ )
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
     {
-        set_bit(msraddr_to_bitpos(core2_fix_counters.msr[i]), msr_bitmap);
-        set_bit(msraddr_to_bitpos(core2_fix_counters.msr[i]),
+        set_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR0 + i), msr_bitmap);
+        set_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR0 + i),
                 msr_bitmap + 0x800/BYTES_PER_LONG);
     }
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
     {
-        set_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0+i), msr_bitmap);
-        set_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0+i),
+        set_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0 + i), msr_bitmap);
+        set_bit(msraddr_to_bitpos(MSR_IA32_PERFCTR0 + i),
                 msr_bitmap + 0x800/BYTES_PER_LONG);
 
         if ( full_width_write )
@@ -305,10 +288,12 @@ static void core2_vpmu_unset_msr_bitmap(unsigned long *msr_bitmap)
         }
     }
 
-    for ( i = 0; i < core2_ctrls.num; i++ )
-        set_bit(msraddr_to_bitpos(core2_ctrls.msr[i]), msr_bitmap);
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
         set_bit(msraddr_to_bitpos(MSR_P6_EVNTSEL(i)), msr_bitmap);
+
+    set_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR_CTRL), msr_bitmap);
+    set_bit(msraddr_to_bitpos(MSR_IA32_PEBS_ENABLE), msr_bitmap);
+    set_bit(msraddr_to_bitpos(MSR_IA32_DS_AREA), msr_bitmap);
 }
 
 static inline void __core2_vpmu_save(struct vcpu *v)
@@ -316,10 +301,10 @@ static inline void __core2_vpmu_save(struct vcpu *v)
     int i;
     struct core2_vpmu_context *core2_vpmu_cxt = vcpu_vpmu(v)->context;
 
-    for ( i = 0; i < core2_fix_counters.num; i++ )
-        rdmsrl(core2_fix_counters.msr[i], core2_vpmu_cxt->fix_counters[i]);
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
-        rdmsrl(MSR_IA32_PERFCTR0+i, core2_vpmu_cxt->arch_msr_pair[i].counter);
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
+        rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, core2_vpmu_cxt->fix_counters[i]);
+    for ( i = 0; i < arch_pmc_cnt; i++ )
+        rdmsrl(MSR_IA32_PERFCTR0 + i, core2_vpmu_cxt->arch_msr_pair[i].counter);
 }
 
 static int core2_vpmu_save(struct vcpu *v)
@@ -344,20 +329,22 @@ static inline void __core2_vpmu_load(struct vcpu *v)
     unsigned int i, pmc_start;
     struct core2_vpmu_context *core2_vpmu_cxt = vcpu_vpmu(v)->context;
 
-    for ( i = 0; i < core2_fix_counters.num; i++ )
-        wrmsrl(core2_fix_counters.msr[i], core2_vpmu_cxt->fix_counters[i]);
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
+        wrmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, core2_vpmu_cxt->fix_counters[i]);
 
     if ( full_width_write )
         pmc_start = MSR_IA32_A_PERFCTR0;
     else
         pmc_start = MSR_IA32_PERFCTR0;
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
+    {
         wrmsrl(pmc_start + i, core2_vpmu_cxt->arch_msr_pair[i].counter);
-
-    for ( i = 0; i < core2_ctrls.num; i++ )
-        wrmsrl(core2_ctrls.msr[i], core2_vpmu_cxt->ctrls[i]);
-    for ( i = 0; i < core2_get_pmc_count(); i++ )
         wrmsrl(MSR_P6_EVNTSEL(i), core2_vpmu_cxt->arch_msr_pair[i].control);
+    }
+
+    wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
+    wrmsrl(MSR_IA32_DS_AREA, core2_vpmu_cxt->ds_area);
+    wrmsrl(MSR_IA32_PEBS_ENABLE, core2_vpmu_cxt->pebs_enable);
 }
 
 static void core2_vpmu_load(struct vcpu *v)
@@ -376,56 +363,37 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct core2_vpmu_context *core2_vpmu_cxt;
-    struct core2_pmu_enable *pmu_enable;
 
     if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
         return 0;
 
     wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
     if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
-        return 0;
+        goto out_err;
 
     if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
-        return 0;
+        goto out_err;
     vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
                  core2_calc_intial_glb_ctrl_msr());
 
-    pmu_enable = xzalloc_bytes(sizeof(struct core2_pmu_enable) +
-                               core2_get_pmc_count() - 1);
-    if ( !pmu_enable )
-        goto out1;
-
     core2_vpmu_cxt = xzalloc_bytes(sizeof(struct core2_vpmu_context) +
-                    (core2_get_pmc_count()-1)*sizeof(struct arch_msr_pair));
+                    (arch_pmc_cnt-1)*sizeof(struct arch_msr_pair));
     if ( !core2_vpmu_cxt )
-        goto out2;
-    core2_vpmu_cxt->pmu_enable = pmu_enable;
+        goto out_err;
+
     vpmu->context = (void *)core2_vpmu_cxt;
 
+    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
+
     return 1;
- out2:
-    xfree(pmu_enable);
- out1:
-    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 0;
-}
 
-static void core2_vpmu_save_msr_context(struct vcpu *v, int type,
-                                       int index, u64 msr_data)
-{
-    struct core2_vpmu_context *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+out_err:
+    release_pmu_ownship(PMU_OWNER_HVM);
 
-    switch ( type )
-    {
-    case MSR_TYPE_CTRL:
-        core2_vpmu_cxt->ctrls[index] = msr_data;
-        break;
-    case MSR_TYPE_ARCH_CTRL:
-        core2_vpmu_cxt->arch_msr_pair[index].control = msr_data;
-        break;
-    }
+    printk("Failed to allocate VPMU resources for domain %u vcpu %u\n",
+           v->vcpu_id, v->domain->domain_id);
+
+    return 0;
 }
 
 static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
@@ -436,10 +404,8 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
         return 0;
 
     if ( unlikely(!vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED)) &&
-	 (vpmu->context != NULL ||
-	  !core2_vpmu_alloc_resource(current)) )
+         !core2_vpmu_alloc_resource(current) )
         return 0;
-    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
 
     /* Do the lazy load staff. */
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
@@ -456,8 +422,7 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
 static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
                                uint64_t supported)
 {
-    u64 global_ctrl, non_global_ctrl;
-    char pmu_enable = 0;
+    u64 global_ctrl;
     int i, tmp;
     int type = -1, index = -1;
     struct vcpu *v = current;
@@ -504,6 +469,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         if ( msr_content & 1 )
             gdprintk(XENLOG_WARNING, "Guest is trying to enable PEBS, "
                      "which is not supported.\n");
+        core2_vpmu_cxt->pebs_enable = msr_content;
         return 1;
     case MSR_IA32_DS_AREA:
         if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
@@ -516,57 +482,48 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
                 hvm_inject_hw_exception(TRAP_gp_fault, 0);
                 return 1;
             }
-            core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 0;
+            core2_vpmu_cxt->ds_area = msr_content;
             break;
         }
         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++ )
-        {
-            rdmsrl(MSR_P6_EVNTSEL(i), non_global_ctrl);
-            core2_vpmu_cxt->pmu_enable->arch_pmc_enable[i] =
-                    global_ctrl & (non_global_ctrl >> 22) & 1;
-            global_ctrl >>= 1;
-        }
-
-        rdmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, non_global_ctrl);
-        global_ctrl = msr_content >> 32;
-        for ( i = 0; i < core2_fix_counters.num; i++ )
-        {
-            core2_vpmu_cxt->pmu_enable->fixed_ctr_enable[i] =
-                (global_ctrl & 1) & ((non_global_ctrl & 0x3)? 1: 0);
-            non_global_ctrl >>= FIXED_CTR_CTRL_BITS;
-            global_ctrl >>= 1;
-        }
         break;
     case MSR_CORE_PERF_FIXED_CTR_CTRL:
-        non_global_ctrl = msr_content;
         vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
-        global_ctrl >>= 32;
-        for ( i = 0; i < core2_fix_counters.num; i++ )
+        core2_vpmu_cxt->enabled_cntrs &=
+                ~(((1ULL << VPMU_CORE2_MAX_FIXED_PMCS) - 1) << 32);
+        if ( msr_content != 0 )
         {
-            core2_vpmu_cxt->pmu_enable->fixed_ctr_enable[i] =
-                (global_ctrl & 1) & ((non_global_ctrl & 0x3)? 1: 0);
-            non_global_ctrl >>= 4;
-            global_ctrl >>= 1;
+            u64 val = msr_content;
+            for ( i = 0; i < fixed_pmc_cnt; i++ )
+            {
+                if ( val & 3 )
+                    core2_vpmu_cxt->enabled_cntrs |= (1ULL << 32) << i;
+                val >>= FIXED_CTR_CTRL_BITS;
+            }
         }
+
+        core2_vpmu_cxt->fixed_ctrl = msr_content;
         break;
     default:
         tmp = msr - MSR_P6_EVNTSEL(0);
-        vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
-        if ( tmp >= 0 && tmp < core2_get_pmc_count() )
-            core2_vpmu_cxt->pmu_enable->arch_pmc_enable[tmp] =
-                (global_ctrl >> tmp) & (msr_content >> 22) & 1;
+        if ( tmp >= 0 && tmp < arch_pmc_cnt )
+        {
+            vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+
+            if ( msr_content & (1ULL << 22) )
+                core2_vpmu_cxt->enabled_cntrs |= 1ULL << tmp;
+            else
+                core2_vpmu_cxt->enabled_cntrs &= ~(1ULL << tmp);
+
+            core2_vpmu_cxt->arch_msr_pair[tmp].control = msr_content;
+        }
     }
 
-    for ( i = 0; i < core2_fix_counters.num; i++ )
-        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 )
+    if ( (global_ctrl & core2_vpmu_cxt->enabled_cntrs) ||
+         (core2_vpmu_cxt->ds_area != 0)  )
         vpmu_set(vpmu, VPMU_RUNNING);
     else
         vpmu_reset(vpmu, VPMU_RUNNING);
@@ -584,7 +541,6 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
     }
 
-    core2_vpmu_save_msr_context(v, type, index, msr_content);
     if ( type != MSR_TYPE_GLOBAL )
     {
         u64 mask;
@@ -600,7 +556,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
             if  ( msr == MSR_IA32_DS_AREA )
                 break;
             /* 4 bits per counter, currently 3 fixed counters implemented. */
-            mask = ~((1ull << (VPMU_CORE2_NUM_FIXED * FIXED_CTR_CTRL_BITS)) - 1);
+            mask = ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1);
             if (msr_content & mask)
                 inject_gp = 1;
             break;
@@ -685,7 +641,7 @@ static void core2_vpmu_do_cpuid(unsigned int input,
 static void core2_vpmu_dump(const struct vcpu *v)
 {
     const struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    int i, num;
+    unsigned int i;
     const struct core2_vpmu_context *core2_vpmu_cxt = NULL;
     u64 val;
 
@@ -703,27 +659,25 @@ static void core2_vpmu_dump(const struct vcpu *v)
 
     printk("    vPMU running\n");
     core2_vpmu_cxt = vpmu->context;
-    num = core2_get_pmc_count();
+
     /* Print the contents of the counter and its configuration msr. */
-    for ( i = 0; i < num; i++ )
+    for ( i = 0; i < arch_pmc_cnt; i++ )
     {
         const struct arch_msr_pair *msr_pair = core2_vpmu_cxt->arch_msr_pair;
 
-        if ( core2_vpmu_cxt->pmu_enable->arch_pmc_enable[i] )
-            printk("      general_%d: 0x%016lx ctrl: 0x%016lx\n",
-                   i, msr_pair[i].counter, msr_pair[i].control);
+        printk("      general_%d: 0x%016lx ctrl: 0x%016lx\n",
+               i, msr_pair[i].counter, msr_pair[i].control);
     }
     /*
      * The configuration of the fixed counter is 4 bits each in the
      * MSR_CORE_PERF_FIXED_CTR_CTRL.
      */
-    val = core2_vpmu_cxt->ctrls[MSR_CORE_PERF_FIXED_CTR_CTRL_IDX];
-    for ( i = 0; i < core2_fix_counters.num; i++ )
+    val = core2_vpmu_cxt->fixed_ctrl;
+    for ( i = 0; i < fixed_pmc_cnt; i++ )
     {
-        if ( core2_vpmu_cxt->pmu_enable->fixed_ctr_enable[i] )
-            printk("      fixed_%d:   0x%016lx ctrl: %#lx\n",
-                   i, core2_vpmu_cxt->fix_counters[i],
-                   val & FIXED_CTR_CTRL_MASK);
+        printk("      fixed_%d:   0x%016lx ctrl: %#lx\n",
+               i, core2_vpmu_cxt->fix_counters[i],
+               val & FIXED_CTR_CTRL_MASK);
         val >>= FIXED_CTR_CTRL_BITS;
     }
 }
@@ -741,7 +695,7 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
         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);
+        msr_content = 0xC000000700000000 | ((1 << arch_pmc_cnt) - 1);
         wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
     }
     else
@@ -808,6 +762,16 @@ static int core2_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
     }
     ds_warned = 1;
  func_out:
+
+    arch_pmc_cnt = core2_get_arch_pmc_count();
+    fixed_pmc_cnt = core2_get_fixed_pmc_count();
+    if ( fixed_pmc_cnt > VPMU_CORE2_MAX_FIXED_PMCS )
+    {
+        fixed_pmc_cnt = VPMU_CORE2_MAX_FIXED_PMCS;
+        printk(XENLOG_G_WARNING "Limiting number of fixed counters to %d\n",
+               fixed_pmc_cnt);
+    }
+
     check_pmc_quirk();
     return 0;
 }
@@ -815,11 +779,10 @@ static int core2_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
 static void core2_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
-    struct core2_vpmu_context *core2_vpmu_cxt = vpmu->context;
 
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
-    xfree(core2_vpmu_cxt->pmu_enable);
+
     xfree(vpmu->context);
     if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
diff --git a/xen/include/asm-x86/hvm/vmx/vpmu_core2.h b/xen/include/asm-x86/hvm/vmx/vpmu_core2.h
index 60b05fd..410372d 100644
--- a/xen/include/asm-x86/hvm/vmx/vpmu_core2.h
+++ b/xen/include/asm-x86/hvm/vmx/vpmu_core2.h
@@ -23,29 +23,10 @@
 #ifndef __ASM_X86_HVM_VPMU_CORE_H_
 #define __ASM_X86_HVM_VPMU_CORE_H_
 
-/* Currently only 3 fixed counters are supported. */
-#define VPMU_CORE2_NUM_FIXED 3
-/* Currently only 3 Non-architectual Performance Control MSRs */
-#define VPMU_CORE2_NUM_CTRLS 3
-
 struct arch_msr_pair {
     u64 counter;
     u64 control;
 };
 
-struct core2_pmu_enable {
-    char ds_area_enable;
-    char fixed_ctr_enable[VPMU_CORE2_NUM_FIXED];
-    char arch_pmc_enable[1];
-};
-
-struct core2_vpmu_context {
-    struct core2_pmu_enable *pmu_enable;
-    u64 fix_counters[VPMU_CORE2_NUM_FIXED];
-    u64 ctrls[VPMU_CORE2_NUM_CTRLS];
-    u64 global_ovf_status;
-    struct arch_msr_pair arch_msr_pair[1];
-};
-
 #endif /* __ASM_X86_HVM_VPMU_CORE_H_ */
 
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94e-0000w0-KI; Sun, 16 Nov 2014 23:17:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94c-0000t9-J9
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9D/89-24532-19039645; Sun, 16 Nov 2014 23:17:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416179855!13161209!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13944 invoked from network); 16 Nov 2014 23:17:36 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:36 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHSmk007736
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:29 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAGNHSc3016611
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 16 Nov 2014 23:17:28 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAGNHQhs016573; Sun, 16 Nov 2014 23:17:27 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:26 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:43 -0500
Message-Id: <1416179271-1221-14-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 13/21] x86/VPMU: Initialize PMU for PV(H)
	guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Code for initializing/tearing down PMU for PV guests

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 tools/flask/policy/policy/modules/xen/xen.te |  4 ++
 xen/arch/x86/domain.c                        |  2 +
 xen/arch/x86/hvm/hvm.c                       |  1 +
 xen/arch/x86/hvm/svm/svm.c                   |  4 +-
 xen/arch/x86/hvm/svm/vpmu.c                  | 44 +++++++++----
 xen/arch/x86/hvm/vmx/vmx.c                   |  4 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c            | 81 ++++++++++++++++-------
 xen/arch/x86/hvm/vpmu.c                      | 98 +++++++++++++++++++++++++++-
 xen/common/event_channel.c                   |  1 +
 xen/include/asm-x86/hvm/vpmu.h               |  2 +
 xen/include/public/pmu.h                     |  2 +
 xen/include/public/xen.h                     |  1 +
 xen/include/xsm/dummy.h                      |  3 +
 xen/xsm/flask/hooks.c                        |  4 ++
 xen/xsm/flask/policy/access_vectors          |  2 +
 15 files changed, 212 insertions(+), 41 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index ae7bf3c..9d84004 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -120,6 +120,10 @@ domain_comms(dom0_t, dom0_t)
 # Allow all domains to use (unprivileged parts of) the tmem hypercall
 allow domain_type xen_t:xen tmem_op;
 
+# Allow all domains to use PMU (but not to change its settings --- that's what
+# pmu_ctrl is for)
+allow domain_type xen_t:xen2 pmu_use;
+
 ###############################################################################
 #
 # Domain creation
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index da5bdf4..ce1d187 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -445,6 +445,8 @@ int vcpu_initialise(struct vcpu *v)
 
     vmce_init_vcpu(v);
 
+    spin_lock_init(&v->arch.vpmu.vpmu_lock);
+
     if ( has_hvm_container_domain(d) )
     {
         rc = hvm_vcpu_initialise(v);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..ec9c89a 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4820,6 +4820,7 @@ static hvm_hypercall_t *const pvh_hypercall64_table[NR_hypercalls] = {
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
     HYPERCALL(domctl),
+    HYPERCALL(xenpmu_op),
     [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
 };
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 8aca6e6..b1c4845 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1157,7 +1157,9 @@ static int svm_vcpu_initialise(struct vcpu *v)
         return rc;
     }
 
-    vpmu_initialise(v);
+    /* PVH's VPMU is initialized via hypercall */
+    if ( is_hvm_vcpu(v) )
+        vpmu_initialise(v);
 
     svm_guest_osvw_init(v);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 8460d7b..fe852ed 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -363,17 +363,19 @@ static void amd_vpmu_destroy(struct vcpu *v)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
-    if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
-        amd_vpmu_unset_msr_bitmap(v);
+    if ( has_hvm_container_vcpu(v) )
+    {
+        if ( is_msr_bitmap_on(vpmu) )
+            amd_vpmu_unset_msr_bitmap(v);
 
-    xfree(vpmu->context);
-    vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
+        if ( is_hvm_vcpu(v) )
+            xfree(vpmu->context);
 
-    if ( vpmu_is_set(vpmu, VPMU_RUNNING) )
-    {
-        vpmu_reset(vpmu, VPMU_RUNNING);
         release_pmu_ownship(PMU_OWNER_HVM);
     }
+
+    vpmu->context = NULL;
+    vpmu_clear(vpmu);
 }
 
 /* VPMU part of the 'q' keyhandler */
@@ -439,15 +441,19 @@ int svm_vpmu_initialise(struct vcpu *v)
     if ( !counters )
         return -EINVAL;
 
-    ctxt = xzalloc_bytes(sizeof(*ctxt) +
-                         2 * sizeof(uint64_t) * num_counters);
-    if ( !ctxt )
+    if ( is_hvm_vcpu(v) )
     {
-        printk(XENLOG_G_WARNING "Insufficient memory for PMU, "
-               " PMU feature is unavailable on domain %d vcpu %d.\n",
-               v->vcpu_id, v->domain->domain_id);
-        return -ENOMEM;
+        ctxt = xzalloc_bytes(sizeof(*ctxt) +
+                             2 * sizeof(uint64_t) * num_counters);
+        if ( !ctxt )
+        {
+            printk(XENLOG_G_WARNING "%pv: Insufficient memory for PMU, "
+                   " PMU feature is unavailable\n", v);
+            return -ENOMEM;
+        }
     }
+    else
+        ctxt = &v->arch.vpmu.xenpmu_data->pmu.c.amd;
 
     ctxt->counters = sizeof(*ctxt);
     ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
@@ -489,6 +495,16 @@ int __init amd_vpmu_init(void)
         return -EINVAL;
     }
 
+    if ( sizeof(struct xen_pmu_data) +
+         2 * sizeof(uint64_t) * num_counters > PAGE_SIZE )
+    {
+        printk(XENLOG_WARNING
+               "VPMU: Register bank does not fit into VPMU shared page\n");
+        counters = ctrls = NULL;
+        num_counters = 0;
+        return -ENOSPC;
+    }
+
     return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 0bf92b2..a7c3a7a 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -116,7 +116,9 @@ static int vmx_vcpu_initialise(struct vcpu *v)
         return rc;
     }
 
-    vpmu_initialise(v);
+    /* PVH's VPMU is initialized via hypercall */
+    if ( is_hvm_vcpu(v) )
+        vpmu_initialise(v);
 
     vmx_install_vlapic_mapping(v);
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index e199367..03dc981 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -362,24 +362,34 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
     struct xen_pmu_intel_ctxt *core2_vpmu_cxt = NULL;
     uint64_t *p = NULL;
 
-    if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
-        return 0;
-
-    wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
-    if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
+    p = xzalloc_bytes(sizeof(uint64_t));
+    if ( !p )
         goto out_err;
 
-    if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
-        goto out_err;
-    vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
-
-    core2_vpmu_cxt = xzalloc_bytes(sizeof(*core2_vpmu_cxt) +
-                                   sizeof(uint64_t) * fixed_pmc_cnt +
-                                   sizeof(struct xen_pmu_cntr_pair) *
-                                   arch_pmc_cnt);
-    p = xzalloc(uint64_t);
-    if ( !core2_vpmu_cxt || !p )
-        goto out_err;
+    if ( has_hvm_container_vcpu(v) )
+    {
+        if ( is_hvm_vcpu(v) && !acquire_pmu_ownership(PMU_OWNER_HVM) )
+            goto out_err;
+
+        wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+        if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
+            goto out_err_hvm;
+        if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
+            goto out_err_hvm;
+        vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+    }
+
+    if ( is_hvm_vcpu(v) )
+    {
+        core2_vpmu_cxt = xzalloc_bytes(sizeof(*core2_vpmu_cxt) +
+                                       sizeof(uint64_t) * fixed_pmc_cnt +
+                                       sizeof(struct xen_pmu_cntr_pair) *
+                                       arch_pmc_cnt);
+        if ( !core2_vpmu_cxt )
+            goto out_err_hvm;
+    }
+    else
+        core2_vpmu_cxt = &v->arch.vpmu.xenpmu_data->pmu.c.intel;
 
     core2_vpmu_cxt->fixed_counters = sizeof(*core2_vpmu_cxt);
     core2_vpmu_cxt->arch_counters = core2_vpmu_cxt->fixed_counters +
@@ -392,10 +402,12 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
 
     return 1;
 
-out_err:
-    release_pmu_ownship(PMU_OWNER_HVM);
-
+ out_err_hvm:
     xfree(core2_vpmu_cxt);
+    if ( is_hvm_vcpu(v) )
+        release_pmu_ownship(PMU_OWNER_HVM);
+
+ out_err:
     xfree(p);
 
     printk("Failed to allocate VPMU resources for domain %u vcpu %u\n",
@@ -715,12 +727,20 @@ static void core2_vpmu_destroy(struct vcpu *v)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
-    xfree(vpmu->context);
+    if ( has_hvm_container_vcpu(v) )
+    {
+        if ( cpu_has_vmx_msr_bitmap )
+            core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
+
+        if ( is_hvm_vcpu(v) )
+            xfree(vpmu->context);
+
+        release_pmu_ownship(PMU_OWNER_HVM);
+    }
+
     xfree(vpmu->priv_context);
-    if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
-        core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
-    release_pmu_ownship(PMU_OWNER_HVM);
-    vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
+    vpmu->context = NULL;
+    vpmu_clear(vpmu);
 }
 
 struct arch_vpmu_ops core2_vpmu_ops = {
@@ -830,6 +850,10 @@ int vmx_vpmu_initialise(struct vcpu *v)
     ds_warned = 1;
  func_out:
 
+    /* PV domains can allocate resources immediately */
+    if ( is_pv_vcpu(v) && !core2_vpmu_alloc_resource(v) )
+        return -EIO;
+
     vpmu->arch_vpmu_ops = &core2_vpmu_ops;
 
     return 0;
@@ -895,5 +919,14 @@ int __init core2_vpmu_init(void)
 
     check_pmc_quirk();
 
+    if ( sizeof(struct xen_pmu_data) + sizeof(uint64_t) * fixed_pmc_cnt +
+         sizeof(struct xen_pmu_cntr_pair) * arch_pmc_cnt > PAGE_SIZE )
+    {
+        printk(XENLOG_WARNING
+               "VPMU: Register bank does not fit into VPMU share page\n");
+        arch_pmc_cnt = fixed_pmc_cnt = 0;
+        return -ENOSPC;
+    }
+
     return 0;
 }
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index ed3b99a..2ad9832 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -26,6 +26,7 @@
 #include <asm/regs.h>
 #include <asm/types.h>
 #include <asm/msr.h>
+#include <asm/p2m.h>
 #include <asm/hvm/support.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/vmx/vmcs.h>
@@ -252,6 +253,7 @@ void vpmu_initialise(struct vcpu *v)
         vpmu_destroy(v);
     vpmu_clear(vpmu);
     vpmu->context = NULL;
+    vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
 
     switch ( vendor )
     {
@@ -278,7 +280,89 @@ void vpmu_destroy(struct vcpu *v)
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
+    {
+        /* Unload VPMU first. This will stop counters */
+        on_selected_cpus(cpumask_of(vcpu_vpmu(v)->last_pcpu),
+                         vpmu_save_force, v, 1);
+
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
+    }
+}
+
+static int pvpmu_init(struct domain *d, xen_pmu_params_t *params)
+{
+    struct vcpu *v;
+    struct vpmu_struct *vpmu;
+    struct page_info *page;
+    uint64_t gfn = params->val;
+
+    if ( vpmu_mode == XENPMU_MODE_OFF )
+        return -EINVAL;
+
+    if ( (params->vcpu >= d->max_vcpus) || (d->vcpu == NULL) ||
+         (d->vcpu[params->vcpu] == NULL) )
+        return -EINVAL;
+
+    page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
+    if ( !page )
+        return -EINVAL;
+
+    if ( !get_page_type(page, PGT_writable_page) )
+    {
+        put_page(page);
+        return -EINVAL;
+    }
+
+    v = d->vcpu[params->vcpu];
+    vpmu = vcpu_vpmu(v);
+    spin_lock(&vpmu->vpmu_lock);
+
+    v->arch.vpmu.xenpmu_data = __map_domain_page_global(page);
+    if ( !v->arch.vpmu.xenpmu_data )
+    {
+        put_page_and_type(page);
+        spin_unlock(&vpmu->vpmu_lock);
+        return -EINVAL;
+    }
+
+    vpmu_initialise(v);
+
+    spin_unlock(&vpmu->vpmu_lock);
+
+    return 0;
+}
+
+static void pvpmu_finish(struct domain *d, xen_pmu_params_t *params)
+{
+    struct vcpu *v;
+    struct vpmu_struct *vpmu;
+    uint64_t mfn;
+
+    if ( (params->vcpu >= d->max_vcpus) || (d->vcpu == NULL) ||
+         (d->vcpu[params->vcpu] == NULL) )
+        return;
+
+    v = d->vcpu[params->vcpu];
+    if ( v != current )
+        vcpu_pause(v);
+
+    vpmu = vcpu_vpmu(v);
+    spin_lock(&vpmu->vpmu_lock);
+
+    if ( v->arch.vpmu.xenpmu_data )
+    {
+        mfn = domain_page_map_to_mfn(v->arch.vpmu.xenpmu_data);
+        ASSERT(mfn != 0);
+        unmap_domain_page_global(v->arch.vpmu.xenpmu_data);
+        put_page_and_type(mfn_to_page(mfn));
+        v->arch.vpmu.xenpmu_data = NULL;
+    }
+    vpmu_destroy(v);
+
+    spin_unlock(&vpmu->vpmu_lock);
+
+    if ( v != current )
+        vcpu_unpause(v);
 }
 
 /* Dump some vpmu informations on console. Used in keyhandler dump_domains(). */
@@ -402,7 +486,7 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 
         if ( copy_to_guest(arg, &pmu_params, 1) )
             return -EFAULT;
-        break;
+         break;
 
     case XENPMU_feature_set:
         if ( copy_from_guest(&pmu_params, arg, 1) )
@@ -420,6 +504,18 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
             return -EFAULT;
         break;
 
+    case XENPMU_init:
+        if ( copy_from_guest(&pmu_params, arg, 1) )
+            return -EFAULT;
+        ret = pvpmu_init(current->domain, &pmu_params);
+        break;
+
+    case XENPMU_finish:
+        if ( copy_from_guest(&pmu_params, arg, 1) )
+            return -EFAULT;
+        pvpmu_finish(current->domain, &pmu_params);
+        break;
+
     default:
         ret = -EINVAL;
     }
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 7d6de54..a991b2d 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -108,6 +108,7 @@ static int virq_is_global(uint32_t virq)
     case VIRQ_TIMER:
     case VIRQ_DEBUG:
     case VIRQ_XENOPROF:
+    case VIRQ_XENPMU:
         rc = 0;
         break;
     case VIRQ_ARCH_0 ... VIRQ_ARCH_7:
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 97fe17c..ada2ab7 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -64,6 +64,8 @@ struct vpmu_struct {
     void *context;      /* May be shared with PV guest */
     void *priv_context; /* hypervisor-only */
     struct arch_vpmu_ops *arch_vpmu_ops;
+    struct xen_pmu_data *xenpmu_data;
+    spinlock_t vpmu_lock;
 };
 
 /* VPMU states */
diff --git a/xen/include/public/pmu.h b/xen/include/public/pmu.h
index 66cc494..afb4ca1 100644
--- a/xen/include/public/pmu.h
+++ b/xen/include/public/pmu.h
@@ -25,6 +25,8 @@
 #define XENPMU_mode_set        1
 #define XENPMU_feature_get     2
 #define XENPMU_feature_set     3
+#define XENPMU_init            4
+#define XENPMU_finish          5
 /* ` } */
 
 /* Parameters structure for HYPERVISOR_xenpmu_op call */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 0766790..e4d0b79 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -161,6 +161,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #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       */
+#define VIRQ_XENPMU     13 /* V.  PMC interrupt                              */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index c637454..ae47135 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -665,6 +665,9 @@ static XSM_INLINE int xsm_pmu_op (XSM_DEFAULT_ARG struct domain *d, int op)
     case XENPMU_feature_set:
     case XENPMU_feature_get:
         return xsm_default_action(XSM_PRIV, d, current->domain);
+    case XENPMU_init:
+    case XENPMU_finish: 
+        return xsm_default_action(XSM_HOOK, d, current->domain);
     default:
         return -EPERM;
     }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8e1914e..76f2cf1 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1515,6 +1515,10 @@ static int flask_pmu_op (struct domain *d, int op)
     case XENPMU_feature_get:
         return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN2,
                             XEN2__PMU_CTRL, NULL);
+    case XENPMU_init:
+    case XENPMU_finish:
+        return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN2,
+                            XEN2__PMU_USE, NULL);
     default:
         return -EPERM;
     }
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 3289d98..b84af31 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -87,6 +87,8 @@ class xen2
     get_symbol
 # PMU control
     pmu_ctrl
+# PMU use (domains, including unprivileged ones, will be using this operation)
+    pmu_use
 }
 
 # Classes domain and domain2 consist of operations that a domain performs on
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94V-0000nH-P7; Sun, 16 Nov 2014 23:17:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94T-0000mR-Bz
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:29 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	C1/3F-27785-88039645; Sun, 16 Nov 2014 23:17:28 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416179846!9569771!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7178 invoked from network); 16 Nov 2014 23:17:27 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:27 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHKV6007689
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:20 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHG21007302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:17 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHGWR023782; Sun, 16 Nov 2014 23:17:16 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:16 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:33 -0500
Message-Id: <1416179271-1221-4-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 03/21] x86/VPMU: Set MSR bitmaps only for
	HVM/PVH guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In preparation for making VPMU code shared with PV make sure that we we update
MSR bitmaps only for HVM/PVH guests

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       | 21 +++++++++++++--------
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  8 +++++---
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 8e07a98..f49af97 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -244,7 +244,8 @@ static int amd_vpmu_save(struct vcpu *v)
 
     context_save(v);
 
-    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) && ctx->msr_bitmap_set )
+    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
+         has_hvm_container_vcpu(v) && ctx->msr_bitmap_set )
         amd_vpmu_unset_msr_bitmap(v);
 
     return 1;
@@ -287,8 +288,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     ASSERT(!supported);
 
     /* For all counters, enable guest only mode for HVM guest */
-    if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
-        !(is_guest_mode(msr_content)) )
+    if ( has_hvm_container_vcpu(v) &&
+         (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
+         !is_guest_mode(msr_content) )
     {
         set_guest_mode(msr_content);
     }
@@ -303,8 +305,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         apic_write(APIC_LVTPC, PMU_APIC_VECTOR);
         vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR;
 
-        if ( !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
-            amd_vpmu_set_msr_bitmap(v);
+        if ( has_hvm_container_vcpu(v) &&
+             !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+             amd_vpmu_set_msr_bitmap(v);
     }
 
     /* stop saving & restore if guest stops first counter */
@@ -314,8 +317,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
         vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
         vpmu_reset(vpmu, VPMU_RUNNING);
-        if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
-            amd_vpmu_unset_msr_bitmap(v);
+        if ( has_hvm_container_vcpu(v) &&
+             ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+             amd_vpmu_unset_msr_bitmap(v);
         release_pmu_ownship(PMU_OWNER_HVM);
     }
 
@@ -406,7 +410,8 @@ static void amd_vpmu_destroy(struct vcpu *v)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
-    if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+    if ( has_hvm_container_vcpu(v) &&
+         ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
         amd_vpmu_unset_msr_bitmap(v);
 
     xfree(vpmu->context);
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 68b6272..54e96b6 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -335,7 +335,8 @@ static int core2_vpmu_save(struct vcpu *v)
     __core2_vpmu_save(v);
 
     /* Unset PMU MSR bitmap to trap lazy load. */
-    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) && cpu_has_vmx_msr_bitmap )
+    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
+         has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
 
     return 1;
@@ -448,7 +449,8 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
     {
         __core2_vpmu_load(current);
         vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
-        if ( cpu_has_vmx_msr_bitmap )
+        if ( has_hvm_container_vcpu(current) &&
+             cpu_has_vmx_msr_bitmap )
             core2_vpmu_set_msr_bitmap(current->arch.hvm_vmx.msr_bitmap);
     }
     return 1;
@@ -822,7 +824,7 @@ static void core2_vpmu_destroy(struct vcpu *v)
         return;
     xfree(core2_vpmu_cxt->pmu_enable);
     xfree(vpmu->context);
-    if ( cpu_has_vmx_msr_bitmap )
+    if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
     release_pmu_ownship(PMU_OWNER_HVM);
     vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94Q-0000lu-Fc; Sun, 16 Nov 2014 23:17:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94O-0000lb-Tg
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:25 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	4C/EB-02957-48039645; Sun, 16 Nov 2014 23:17:24 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416179842!12878148!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21687 invoked from network); 16 Nov 2014 23:17:23 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHHA0007673
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:17 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHGi2023779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:16 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHFbO007279; Sun, 16 Nov 2014 23:17:15 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:15 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:32 -0500
Message-Id: <1416179271-1221-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 02/21] x86/VPMU: Manage VPMU_CONTEXT_SAVE
	flag in vpmu_save_force()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 a possibility that we set VPMU_CONTEXT_SAVE on VPMU context in
vpmu_load() and never clear it (because vpmu_save_force() will see
VPMU_CONTEXT_LOADED bit clear, which is possible on AMD processors)

The problem is that amd_vpmu_save() assumes that if VPMU_CONTEXT_SAVE is set
then (1) we need to save counters and (2) we don't need to "stop" control
registers since they must have been stopped earlier. The latter may cause all
sorts of problem (like counters still running in a wrong guest and hypervisor
sending to that guest unexpected PMU interrupts).

Since setting this flag is currently always done prior to calling
vpmu_save_force() let's both set and clear it there.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vpmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 265fc0e..e74c871 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -128,6 +128,8 @@ static void vpmu_save_force(void *arg)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         return;
 
+    vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+
     if ( vpmu->arch_vpmu_ops )
         (void)vpmu->arch_vpmu_ops->arch_vpmu_save(v);
 
@@ -176,7 +178,6 @@ void vpmu_load(struct vcpu *v)
          */
         if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         {
-            vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
             on_selected_cpus(cpumask_of(vpmu->last_pcpu),
                              vpmu_save_force, (void *)v, 1);
             vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
@@ -193,7 +194,6 @@ void vpmu_load(struct vcpu *v)
         vpmu = vcpu_vpmu(prev);
 
         /* Someone ran here before us */
-        vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
         vpmu_save_force(prev);
         vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
 
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94c-0000t5-3o; Sun, 16 Nov 2014 23:17:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94a-0000rA-F9
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:36 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	76/30-02696-F8039645; Sun, 16 Nov 2014 23:17:35 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416179853!8269001!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26898 invoked from network); 16 Nov 2014 23:17:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:35 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHTCS003472
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:29 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHSL6007593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:29 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHRYZ007579; Sun, 16 Nov 2014 23:17:28 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:27 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:44 -0500
Message-Id: <1416179271-1221-15-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 14/21] x86/VPMU: Save VPMU state for PV
	guests during context switch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Save VPMU state during context switch for both HVM and PV(H) guests.

A subsequent patch ("x86/VPMU: NMI-based VPMU support") will make it possible
for vpmu_switch_to() to call vmx_vmcs_try_enter()->vcpu_pause() which needs
is_running to be correctly set/cleared. To prepare for that, call context_saved()
before vpmu_switch_to() is executed. (Note that while this change could have
been dalayed until that later patch, the changes are harmless to existing code
and so we do it here)

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/domain.c | 20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ce1d187..0de8a20 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1541,16 +1541,13 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
     }
 
     if ( prev != next )
-        _update_runstate_area(prev);
-
-    if ( is_hvm_vcpu(prev) )
     {
-        if (prev != next)
-            vpmu_switch_from(prev, next);
+        _update_runstate_area(prev);
+        vpmu_switch_from(prev, next);
+    }
 
-        if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
+    if ( is_hvm_vcpu(prev) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
             pt_save_timer(prev);
-    }
 
     local_irq_disable();
 
@@ -1589,15 +1586,16 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
                            !is_hardware_domain(next->domain));
     }
 
-    if ( is_hvm_vcpu(prev) && (prev != next) )
-        /* Must be done with interrupts enabled */
-        vpmu_switch_to(prev, next);
-
     context_saved(prev);
 
     if ( prev != next )
+    {
         _update_runstate_area(next);
 
+        /* Must be done with interrupts enabled */
+        vpmu_switch_to(prev, next);
+    }
+
     /* Ensure that the vcpu has an up-to-date time base. */
     update_vcpu_system_time(next);
 
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94W-0000oF-U1; Sun, 16 Nov 2014 23:17:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94U-0000mc-9Y
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:30 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	6B/44-22777-98039645; Sun, 16 Nov 2014 23:17:29 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416179846!11643484!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15917 invoked from network); 16 Nov 2014 23:17:28 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Nov 2014 23:17:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHLVU003450
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:22 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHKJK007400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:21 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHKuu007381; Sun, 16 Nov 2014 23:17:20 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:19 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:37 -0500
Message-Id: <1416179271-1221-8-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 07/21] x86/VPMU: Handle APIC_LVTPC accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Don't have the hypervisor update APIC_LVTPC when _it_ thinks the vector should
be updated. Instead, handle guest's APIC_LVTPC accesses and write what the guest
explicitly wanted.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       |  4 ----
 xen/arch/x86/hvm/vlapic.c         |  3 +++
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 17 -----------------
 xen/arch/x86/hvm/vpmu.c           |  8 ++++++++
 xen/include/asm-x86/hvm/vpmu.h    |  1 +
 5 files changed, 12 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index f49af97..af3cdb2 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -302,8 +302,6 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
         if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
             return 1;
         vpmu_set(vpmu, VPMU_RUNNING);
-        apic_write(APIC_LVTPC, PMU_APIC_VECTOR);
-        vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR;
 
         if ( has_hvm_container_vcpu(v) &&
              !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
@@ -314,8 +312,6 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     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->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
         vpmu_reset(vpmu, VPMU_RUNNING);
         if ( has_hvm_container_vcpu(v) &&
              ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 0b7b607..5c3b2be 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -38,6 +38,7 @@
 #include <asm/hvm/support.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/nestedhvm.h>
+#include <asm/hvm/vpmu.h>
 #include <public/hvm/ioreq.h>
 #include <public/hvm/params.h>
 
@@ -789,6 +790,8 @@ static int vlapic_reg_write(struct vcpu *v,
         }
         if ( (offset == APIC_LVTT) && !(val & APIC_LVT_MASKED) )
             pt_may_unmask_irq(NULL, &vlapic->pt);
+        if ( offset == APIC_LVTPC )
+            vpmu_lvtpc_update(val);
         break;
 
     case APIC_TMICT:
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 09af846..f44847f 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -528,19 +528,6 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     else
         vpmu_reset(vpmu, VPMU_RUNNING);
 
-    /* Setup LVTPC in local apic */
-    if ( vpmu_is_set(vpmu, VPMU_RUNNING) &&
-         is_vlapic_lvtpc_enabled(vcpu_vlapic(v)) )
-    {
-        apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR);
-        vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR;
-    }
-    else
-    {
-        apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
-        vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
-    }
-
     if ( type != MSR_TYPE_GLOBAL )
     {
         u64 mask;
@@ -706,10 +693,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
             return 0;
     }
 
-    /* HW sets the MASK bit when performance counter interrupt occurs*/
-    vpmu->hw_lapic_lvtpc = apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED;
-    apic_write_around(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
-
     return 1;
 }
 
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index aec7b5f..29d9fde 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -64,6 +64,14 @@ static void __init parse_vpmu_param(char *s)
     }
 }
 
+void vpmu_lvtpc_update(uint32_t val)
+{
+    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+
+    vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
+    apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
+}
+
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index ddc2748..9c4e65a 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -104,6 +104,7 @@ static inline bool_t vpmu_are_all_set(const struct vpmu_struct *vpmu,
     return !!((vpmu->flags & mask) == mask);
 }
 
+void vpmu_lvtpc_update(uint32_t val);
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
 void vpmu_do_interrupt(struct cpu_user_regs *regs);
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq94j-00013Q-IS; Sun, 16 Nov 2014 23:17:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xq94h-0000yr-92
	for xen-devel@lists.xen.org; Sun, 16 Nov 2014 23:17:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C9/A2-09842-69039645; Sun, 16 Nov 2014 23:17:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416179860!13124250!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10918 invoked from network); 16 Nov 2014 23:17:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Nov 2014 23:17:41 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAGNHXEn007762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 16 Nov 2014 23:17:34 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHWYh007681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 16 Nov 2014 23:17:33 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAGNHW0B012976; Sun, 16 Nov 2014 23:17:32 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 16 Nov 2014 15:17:32 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: JBeulich@suse.com, kevin.tian@intel.com, suravee.suthikulpanit@amd.com,
	Aravind.Gopalakrishnan@amd.com, dietmar.hahn@ts.fujitsu.com,
	dgdegra@tycho.nsa.gov
Date: Sun, 16 Nov 2014 18:07:49 -0500
Message-Id: <1416179271-1221-20-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, andrew.cooper3@citrix.com, tim@xen.org,
	xen-devel@lists.xen.org, jun.nakajima@intel.com, boris.ostrovsky@oracle.com
Subject: [Xen-devel] [PATCH v15 19/21] x86/VPMU: Add privileged PMU mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 support for privileged PMU mode (XENPMU_MODE_ALL) which allows privileged
domain (dom0) profile both itself (and the hypervisor) and the guests. While
this mode is on profiling in guests is disabled.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
---
 xen/arch/x86/hvm/vpmu.c  | 36 ++++++++++++++++++++++++++----------
 xen/arch/x86/traps.c     | 12 ++++++++++++
 xen/include/public/pmu.h |  3 +++
 3 files changed, 41 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index aa4a5d9..5f0a871 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -99,7 +99,9 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
     struct arch_vpmu_ops *ops;
     int ret = 0;
 
-    if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+    if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+         ((vpmu_mode & XENPMU_MODE_ALL) &&
+          !is_hardware_domain(current->domain)) )
         return 0;
 
     curr = current;
@@ -144,8 +146,12 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
     struct vcpu *sampled = current, *sampling;
     struct vpmu_struct *vpmu;
 
-    /* dom0 will handle interrupt for special domains (e.g. idle domain) */
-    if ( sampled->domain->domain_id >= DOMID_FIRST_RESERVED )
+    /*
+     * dom0 will handle interrupt for special domains (e.g. idle domain) or,
+     * in XENPMU_MODE_ALL, for everyone.
+     */
+    if ( (vpmu_mode & XENPMU_MODE_ALL) ||
+         (sampled->domain->domain_id >= DOMID_FIRST_RESERVED) )
     {
         sampling = choose_hwdom_vcpu();
         if ( !sampling )
@@ -155,12 +161,12 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
         sampling = sampled;
 
     vpmu = vcpu_vpmu(sampling);
-    if ( !is_hvm_vcpu(sampling) )
+    if ( !is_hvm_vcpu(sampling) || (vpmu_mode & XENPMU_MODE_ALL) )
     {
         /* PV(H) guest */
         const struct cpu_user_regs *cur_regs;
         uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
-        uint32_t domid = DOMID_SELF;
+        uint32_t domid;
 
         if ( !vpmu->xenpmu_data )
             return;
@@ -169,6 +175,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
             return;
 
         if ( is_pvh_vcpu(sampling) &&
+             !(vpmu_mode & XENPMU_MODE_ALL) &&
              !vpmu->arch_vpmu_ops->do_interrupt(regs) )
             return;
 
@@ -179,6 +186,11 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 
         *flags = 0;
 
+        if ( sampled == sampling )
+            domid = DOMID_SELF;
+        else
+            domid = sampled->domain->domain_id;
+
         /* Store appropriate registers in xenpmu_data */
         /* FIXME: 32-bit PVH should go here as well */
         if ( is_pv_32bit_vcpu(sampling) )
@@ -207,7 +219,8 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 
             if ( (vpmu_mode & XENPMU_MODE_SELF) )
                 cur_regs = guest_cpu_user_regs();
-            else if ( !guest_mode(regs) && is_hardware_domain(sampling->domain) )
+            else if ( !guest_mode(regs) &&
+                      is_hardware_domain(sampling->domain) )
             {
                 cur_regs = regs;
                 domid = DOMID_XEN;
@@ -442,7 +455,8 @@ static int pvpmu_init(struct domain *d, xen_pmu_params_t *params)
     struct page_info *page;
     uint64_t gfn = params->val;
 
-    if ( vpmu_mode == XENPMU_MODE_OFF )
+    if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+         ((vpmu_mode & XENPMU_MODE_ALL) && !is_hardware_domain(d)) )
         return -EINVAL;
 
     if ( (params->vcpu >= d->max_vcpus) || (d->vcpu == NULL) ||
@@ -585,11 +599,13 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
         if ( copy_from_guest(&pmu_params, arg, 1) )
             return -EFAULT;
 
-        if ( pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+        if ( pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV |
+                                XENPMU_MODE_ALL) )
             return -EINVAL;
 
         /* 32-bit dom0 can only sample itself. */
-        if ( is_pv_32bit_vcpu(current) && (pmu_params.val & XENPMU_MODE_HV) )
+        if ( is_pv_32bit_vcpu(current) &&
+             (pmu_params.val & (XENPMU_MODE_HV | XENPMU_MODE_ALL)) )
             return -EINVAL;
 
         /*
@@ -608,7 +624,7 @@ long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
         old_mode = vpmu_mode;
         vpmu_mode = pmu_params.val;
 
-        if ( vpmu_mode == XENPMU_MODE_OFF )
+        if ( (vpmu_mode == XENPMU_MODE_OFF) || (vpmu_mode == XENPMU_MODE_ALL) )
         {
             /*
              * Make sure all (non-dom0) VCPUs have unloaded their VPMUs. This
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 70477b2..663b44f 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2579,6 +2579,10 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
         case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR5:
                 if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
                 {
+                    if ( (vpmu_mode & XENPMU_MODE_ALL) &&
+                         !is_hardware_domain(v->domain) )
+                        break;
+
                     if ( vpmu_do_wrmsr(regs->ecx, msr_content, 0) )
                         goto fail;
                 }
@@ -2702,6 +2706,14 @@ static int emulate_privileged_op(struct cpu_user_regs *regs)
         case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR5:
                 if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
                 {
+                    if ( (vpmu_mode & XENPMU_MODE_ALL) &&
+                         !is_hardware_domain(v->domain) )
+                    {
+                        /* Don't leak PMU MSRs to unprivileged domains */
+                        regs->eax = regs->edx = 0;
+                        break;
+                    }
+
                     if ( vpmu_do_rdmsr(regs->ecx, &msr_content) )
                         goto fail;
 
diff --git a/xen/include/public/pmu.h b/xen/include/public/pmu.h
index db5321a..a83ae71 100644
--- a/xen/include/public/pmu.h
+++ b/xen/include/public/pmu.h
@@ -52,10 +52,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_pmu_params_t);
  * - XENPMU_MODE_SELF:  Guests can profile themselves
  * - XENPMU_MODE_HV:    Guests can profile themselves, dom0 profiles
  *                      itself and Xen
+ * - XENPMU_MODE_ALL:   Only dom0 has access to VPMU and it profiles
+ *                      everyone: itself, the hypervisor and the guests.
  */
 #define XENPMU_MODE_OFF           0
 #define XENPMU_MODE_SELF          (1<<0)
 #define XENPMU_MODE_HV            (1<<1)
+#define XENPMU_MODE_ALL           (1<<2)
 
 /*
  * PMU features:
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:26:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:26:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq9DF-0003yY-0T; Sun, 16 Nov 2014 23:26: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@citrix.com>) id 1Xq9DD-0003yT-J1
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 23:26:31 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	6A/53-27584-6A239645; Sun, 16 Nov 2014 23:26:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416180388!7544028!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21134 invoked from network); 16 Nov 2014 23:26:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 23:26:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,399,1413244800"; d="scan'208";a="191899392"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 18:26:14 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xq9Cw-0001Ni-Vk;
	Sun, 16 Nov 2014 23:26:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xq9Cw-0002nt-QE;
	Sun, 16 Nov 2014 23:26:14 +0000
Date: Sun, 16 Nov 2014 23:26:14 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31609-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31609: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31609 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31609/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 16 23:26:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Nov 2014 23:26:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xq9DF-0003yY-0T; Sun, 16 Nov 2014 23:26: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@citrix.com>) id 1Xq9DD-0003yT-J1
	for xen-devel@lists.xensource.com; Sun, 16 Nov 2014 23:26:31 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	6A/53-27584-6A239645; Sun, 16 Nov 2014 23:26:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416180388!7544028!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21134 invoked from network); 16 Nov 2014 23:26:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Nov 2014 23:26:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,399,1413244800"; d="scan'208";a="191899392"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 18:26:14 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xq9Cw-0001Ni-Vk;
	Sun, 16 Nov 2014 23:26:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xq9Cw-0002nt-QE;
	Sun, 16 Nov 2014 23:26:14 +0000
Date: Sun, 16 Nov 2014 23:26:14 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31609-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31609: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31609 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31609/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 00:28:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 00:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqAAm-0005IG-CP; Mon, 17 Nov 2014 00:28:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqAAj-0005IB-Jp
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 00:28:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7F/20-24532-01149645; Mon, 17 Nov 2014 00:28:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416184052!13134825!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31008 invoked from network); 17 Nov 2014 00:27:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 00:27:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,399,1413244800"; d="scan'208";a="193397064"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 19:27:30 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqAAE-0001fr-0s;
	Mon, 17 Nov 2014 00:27:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqAAD-0001TP-NL;
	Mon, 17 Nov 2014 00:27:29 +0000
Date: Mon, 17 Nov 2014 00:27:29 +0000
Message-ID: <E1XqAAD-0001TP-NL@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen bisection] complete
	test-amd64-i386-rumpuserxen-i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rumpuserxen-i386
test rumpuserxen-demo-xenstorels/xenstorels

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: rumpuserxen https://github.com/rumpkernel/rumprun-xen
Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.git
Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  rumpuserxen https://github.com/rumpkernel/rumprun-xen
  Bug introduced:  62d07142e5b4c77633bd1283ac06bd71f29d777a
  Bug not present: 3dec9eb4656a1af934f4c4222476a77384b2c487


  commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
  Author: Martin Lucina <martin@lucina.net>
  Date:   Tue Nov 11 16:11:46 2014 +0100
  
      rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
      
      rumpuser_exit() and _exit() were calling minios_do_exit() which is
      intended to be called from an exception context and/or other "panic"
      situation.  This was causing the stack trace code in minios_do_exit() to
      walk off into never never land when the rumprun-xen application called
      exit() or returned from main().
      
      This commit adds a new minios_do_halt(reason) function, with the reason
      code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
      only poweroff and crash are implemented.
      
      We then modify the rumpuser_exit() and _exit() functions to correctly
      shut down the domain by calling minios_stop_kernel() followed by
      minios_do_halt(MINIOS_HALT_POWEROFF).
      
      Signed-off-by: Martin Lucina <martin@lucina.net>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.rumpuserxen.test-amd64-i386-rumpuserxen-i386.rumpuserxen-demo-xenstorels--xenstorels.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31609 fail [host=gall-mite] / 31437 [host=itch-mite] 31373 ok.
Failure / basis pass flights: 31609 / 31373
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: rumpuserxen https://github.com/rumpkernel/rumprun-xen
Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.git
Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd
Tree: xen git://xenbits.xen.org/xen.git
Latest d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Basis pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3d8a59f98b15b625babcb8b19d1832d002cc98b0 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 5283b310e14884341f51be35253cdd59c4cb034c
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#d7892a4c389d54bccb9bce8e65eb053a33bbe290-d7892a4c389d54bccb9bce8e65eb053a33bbe290 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#ca78cc83650b535d7e24baeaea32947be0141534-ca78cc83650b535d7e24baeaea32947be0141534 https://github.com/rumpkernel/rumprun-xen#3d8a59f98b15b625babcb8b19d1832d002cc98b0-9716ed62cb1d73254b552e2077497d684c81639d https://github.com/rumpkernel/buildrump.sh.git#e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b-e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b https://github.com/rumpkernel/src-netbsd#f02880da13242d962fd0119d093f05d9d13a2eb4-f02880da13242d962fd0119d093f05d9d13a2eb4 git://xenbits.xen.org/xen.git#5283b310e14884341f51be35253cdd59c4cb034c-e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/rumprun-xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumprun-xen
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/rumprun-xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumprun-xen
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 461.
Loaded 400 nodes in revision graph
Searching for test results:
 31373 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3d8a59f98b15b625babcb8b19d1832d002cc98b0 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 5283b310e14884341f51be35253cdd59c4cb034c
 31437 [host=itch-mite]
 31546 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 4a8991242b6dc5881fc72a8c37a914afe54de042 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31509 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31524 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3d8a59f98b15b625babcb8b19d1832d002cc98b0 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 5283b310e14884341f51be35253cdd59c4cb034c
 31548 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3d8a59f98b15b625babcb8b19d1832d002cc98b0 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 816f5bb1f0740be8355e1be6cc24edf09547d984
 31555 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3a5227edd6ff8329e690a4b282278017188052df e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31531 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31539 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31551 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 1eb3666b469e307b20262e856229d0bd5d06a59e e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 fda1614e1e95e7ecdfa97ea0afb80597ef8dbbc7
 31545 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 62d07142e5b4c77633bd1283ac06bd71f29d777a e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31554 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 8bd474a4674110ca0fd75d557dc40532a63cc35b e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31584 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 952b8ff86bb756f52a8e194c9e6831c7e39b4d23 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31589 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 62d07142e5b4c77633bd1283ac06bd71f29d777a e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31591 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3dec9eb4656a1af934f4c4222476a77384b2c487 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31568 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 1eb3666b469e307b20262e856229d0bd5d06a59e e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31583 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31586 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 f5247f87792ab5084664be70b409964691d14f43 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31588 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3dec9eb4656a1af934f4c4222476a77384b2c487 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31565 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31593 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31607 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3dec9eb4656a1af934f4c4222476a77384b2c487 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31609 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31627 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 62d07142e5b4c77633bd1283ac06bd71f29d777a e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31605 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 62d07142e5b4c77633bd1283ac06bd71f29d777a e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Searching for interesting versions
 Result found: flight 31373 (pass), for basis pass
 Result found: flight 31509 (fail), for basis failure
 Repro found: flight 31524 (pass), for basis pass
 Repro found: flight 31531 (fail), for basis failure
 0 revisions at d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3dec9eb4656a1af934f4c4222476a77384b2c487 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
No revisions left to test, checking graph state.
 Result found: flight 31588 (pass), for last pass
 Result found: flight 31589 (fail), for first failure
 Repro found: flight 31591 (pass), for last pass
 Repro found: flight 31605 (fail), for first failure
 Repro found: flight 31607 (pass), for last pass
 Repro found: flight 31627 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  rumpuserxen https://github.com/rumpkernel/rumprun-xen
  Bug introduced:  62d07142e5b4c77633bd1283ac06bd71f29d777a
  Bug not present: 3dec9eb4656a1af934f4c4222476a77384b2c487

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/rumprun-xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumprun-xen
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
  Author: Martin Lucina <martin@lucina.net>
  Date:   Tue Nov 11 16:11:46 2014 +0100
  
      rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
      
      rumpuser_exit() and _exit() were calling minios_do_exit() which is
      intended to be called from an exception context and/or other "panic"
      situation.  This was causing the stack trace code in minios_do_exit() to
      walk off into never never land when the rumprun-xen application called
      exit() or returned from main().
      
      This commit adds a new minios_do_halt(reason) function, with the reason
      code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
      only poweroff and crash are implemented.
      
      We then modify the rumpuser_exit() and _exit() functions to correctly
      shut down the domain by calling minios_stop_kernel() followed by
      minios_do_halt(MINIOS_HALT_POWEROFF).
      
      Signed-off-by: Martin Lucina <martin@lucina.net>

Revision graph left in /home/xc_osstest/results/bisect.rumpuserxen.test-amd64-i386-rumpuserxen-i386.rumpuserxen-demo-xenstorels--xenstorels.{dot,ps,png,html}.
----------------------------------------
31627: tolerable FAIL

flight 31627 rumpuserxen real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31627/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail baseline untested


jobs:
 build-i386-rumpuserxen                                       pass    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 00:28:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 00:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqAAm-0005IG-CP; Mon, 17 Nov 2014 00:28:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqAAj-0005IB-Jp
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 00:28:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7F/20-24532-01149645; Mon, 17 Nov 2014 00:28:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416184052!13134825!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31008 invoked from network); 17 Nov 2014 00:27:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 00:27:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,399,1413244800"; d="scan'208";a="193397064"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 19:27:30 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqAAE-0001fr-0s;
	Mon, 17 Nov 2014 00:27:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqAAD-0001TP-NL;
	Mon, 17 Nov 2014 00:27:29 +0000
Date: Mon, 17 Nov 2014 00:27:29 +0000
Message-ID: <E1XqAAD-0001TP-NL@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen bisection] complete
	test-amd64-i386-rumpuserxen-i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rumpuserxen-i386
test rumpuserxen-demo-xenstorels/xenstorels

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: rumpuserxen https://github.com/rumpkernel/rumprun-xen
Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.git
Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  rumpuserxen https://github.com/rumpkernel/rumprun-xen
  Bug introduced:  62d07142e5b4c77633bd1283ac06bd71f29d777a
  Bug not present: 3dec9eb4656a1af934f4c4222476a77384b2c487


  commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
  Author: Martin Lucina <martin@lucina.net>
  Date:   Tue Nov 11 16:11:46 2014 +0100
  
      rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
      
      rumpuser_exit() and _exit() were calling minios_do_exit() which is
      intended to be called from an exception context and/or other "panic"
      situation.  This was causing the stack trace code in minios_do_exit() to
      walk off into never never land when the rumprun-xen application called
      exit() or returned from main().
      
      This commit adds a new minios_do_halt(reason) function, with the reason
      code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
      only poweroff and crash are implemented.
      
      We then modify the rumpuser_exit() and _exit() functions to correctly
      shut down the domain by calling minios_stop_kernel() followed by
      minios_do_halt(MINIOS_HALT_POWEROFF).
      
      Signed-off-by: Martin Lucina <martin@lucina.net>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.rumpuserxen.test-amd64-i386-rumpuserxen-i386.rumpuserxen-demo-xenstorels--xenstorels.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31609 fail [host=gall-mite] / 31437 [host=itch-mite] 31373 ok.
Failure / basis pass flights: 31609 / 31373
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: rumpuserxen https://github.com/rumpkernel/rumprun-xen
Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.git
Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd
Tree: xen git://xenbits.xen.org/xen.git
Latest d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Basis pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3d8a59f98b15b625babcb8b19d1832d002cc98b0 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 5283b310e14884341f51be35253cdd59c4cb034c
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#d7892a4c389d54bccb9bce8e65eb053a33bbe290-d7892a4c389d54bccb9bce8e65eb053a33bbe290 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#ca78cc83650b535d7e24baeaea32947be0141534-ca78cc83650b535d7e24baeaea32947be0141534 https://github.com/rumpkernel/rumprun-xen#3d8a59f98b15b625babcb8b19d1832d002cc98b0-9716ed62cb1d73254b552e2077497d684c81639d https://github.com/rumpkernel/buildrump.sh.git#e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b-e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b https://github.com/rumpkernel/src-netbsd#f02880da13242d962fd0119d093f05d9d13a2eb4-f02880da13242d962fd0119d093f05d9d13a2eb4 git://xenbits.xen.org/xen.git#5283b310e14884341f51be35253cdd59c4cb034c-e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/rumprun-xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumprun-xen
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/rumprun-xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumprun-xen
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 461.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 461.
Loaded 400 nodes in revision graph
Searching for test results:
 31373 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3d8a59f98b15b625babcb8b19d1832d002cc98b0 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 5283b310e14884341f51be35253cdd59c4cb034c
 31437 [host=itch-mite]
 31546 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 4a8991242b6dc5881fc72a8c37a914afe54de042 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31509 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31524 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3d8a59f98b15b625babcb8b19d1832d002cc98b0 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 5283b310e14884341f51be35253cdd59c4cb034c
 31548 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3d8a59f98b15b625babcb8b19d1832d002cc98b0 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 816f5bb1f0740be8355e1be6cc24edf09547d984
 31555 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3a5227edd6ff8329e690a4b282278017188052df e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31531 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31539 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31551 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 1eb3666b469e307b20262e856229d0bd5d06a59e e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 fda1614e1e95e7ecdfa97ea0afb80597ef8dbbc7
 31545 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 62d07142e5b4c77633bd1283ac06bd71f29d777a e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31554 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 8bd474a4674110ca0fd75d557dc40532a63cc35b e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31584 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 952b8ff86bb756f52a8e194c9e6831c7e39b4d23 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31589 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 62d07142e5b4c77633bd1283ac06bd71f29d777a e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31591 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3dec9eb4656a1af934f4c4222476a77384b2c487 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31568 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 1eb3666b469e307b20262e856229d0bd5d06a59e e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31583 blocked d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31586 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 f5247f87792ab5084664be70b409964691d14f43 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31588 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3dec9eb4656a1af934f4c4222476a77384b2c487 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31565 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31593 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31607 pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3dec9eb4656a1af934f4c4222476a77384b2c487 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31609 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31627 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 62d07142e5b4c77633bd1283ac06bd71f29d777a e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31605 fail d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 62d07142e5b4c77633bd1283ac06bd71f29d777a e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Searching for interesting versions
 Result found: flight 31373 (pass), for basis pass
 Result found: flight 31509 (fail), for basis failure
 Repro found: flight 31524 (pass), for basis pass
 Repro found: flight 31531 (fail), for basis failure
 0 revisions at d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3dec9eb4656a1af934f4c4222476a77384b2c487 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
No revisions left to test, checking graph state.
 Result found: flight 31588 (pass), for last pass
 Result found: flight 31589 (fail), for first failure
 Repro found: flight 31591 (pass), for last pass
 Repro found: flight 31605 (fail), for first failure
 Repro found: flight 31607 (pass), for last pass
 Repro found: flight 31627 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  rumpuserxen https://github.com/rumpkernel/rumprun-xen
  Bug introduced:  62d07142e5b4c77633bd1283ac06bd71f29d777a
  Bug not present: 3dec9eb4656a1af934f4c4222476a77384b2c487

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/rumprun-xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumprun-xen
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
  Author: Martin Lucina <martin@lucina.net>
  Date:   Tue Nov 11 16:11:46 2014 +0100
  
      rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
      
      rumpuser_exit() and _exit() were calling minios_do_exit() which is
      intended to be called from an exception context and/or other "panic"
      situation.  This was causing the stack trace code in minios_do_exit() to
      walk off into never never land when the rumprun-xen application called
      exit() or returned from main().
      
      This commit adds a new minios_do_halt(reason) function, with the reason
      code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
      only poweroff and crash are implemented.
      
      We then modify the rumpuser_exit() and _exit() functions to correctly
      shut down the domain by calling minios_stop_kernel() followed by
      minios_do_halt(MINIOS_HALT_POWEROFF).
      
      Signed-off-by: Martin Lucina <martin@lucina.net>

Revision graph left in /home/xc_osstest/results/bisect.rumpuserxen.test-amd64-i386-rumpuserxen-i386.rumpuserxen-demo-xenstorels--xenstorels.{dot,ps,png,html}.
----------------------------------------
31627: tolerable FAIL

flight 31627 rumpuserxen real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31627/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail baseline untested


jobs:
 build-i386-rumpuserxen                                       pass    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 00:50:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 00:50:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqAVv-0005cF-Jk; Mon, 17 Nov 2014 00:49:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqAVu-0005c7-Cl
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 00:49:54 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	2E/6E-27623-13649645; Mon, 17 Nov 2014 00:49:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416185390!9315815!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18103 invoked from network); 17 Nov 2014 00:49:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 00:49:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,399,1413244800"; d="scan'208";a="193399300"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 19:49:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqAVp-0001mc-9D;
	Mon, 17 Nov 2014 00:49:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqAVo-0006n1-Vm;
	Mon, 17 Nov 2014 00:49:48 +0000
Date: Mon, 17 Nov 2014 00:49:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31592-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31592: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31592 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31592/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot     fail in 31451 pass in 31592
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31592
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31592
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31592

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 00:50:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 00:50:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqAVv-0005cF-Jk; Mon, 17 Nov 2014 00:49:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqAVu-0005c7-Cl
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 00:49:54 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	2E/6E-27623-13649645; Mon, 17 Nov 2014 00:49:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416185390!9315815!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18103 invoked from network); 17 Nov 2014 00:49:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 00:49:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,399,1413244800"; d="scan'208";a="193399300"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 19:49:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqAVp-0001mc-9D;
	Mon, 17 Nov 2014 00:49:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqAVo-0006n1-Vm;
	Mon, 17 Nov 2014 00:49:48 +0000
Date: Mon, 17 Nov 2014 00:49:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31592-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31592: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31592 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31592/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-i386-i386-pair      17 guest-migrate/src_host/dst_host fail pass in 31288
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot     fail in 31451 pass in 31592
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31592
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31592
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31592

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 01:24:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 01:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqB31-0001h1-Vi; Mon, 17 Nov 2014 01:24:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1XqB30-0001gw-Ja
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 01:24:06 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	76/18-25714-53E49645; Mon, 17 Nov 2014 01:24:05 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416187443!11657613!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29264 invoked from network); 17 Nov 2014 01:24:04 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-9.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 01:24:04 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43470169"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 17 Nov 2014 09:20:49 +0800
Received: from G08CNEXCHPEKD03.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAH1NlG0014942;
	Mon, 17 Nov 2014 09:23:47 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 17 Nov 2014 09:24:01 +0800
Message-ID: <54694EAA.7080403@cn.fujitsu.com>
Date: Mon, 17 Nov 2014 09:26:02 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>	<1412820314-323-3-git-send-email-wency@cn.fujitsu.com>
	<21606.6212.353346.560825@mariner.uk.xensource.com>
In-Reply-To: <21606.6212.353346.560825@mariner.uk.xensource.com>
X-Originating-IP: [10.167.226.91]
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch v2 2/3] correct xc_domain_save()'s return
	value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 10:57 PM, Ian Jackson wrote:
> Wen Congyang writes ("[Patch v2 2/3] correct xc_domain_save()'s return value"):
>> If suspend_and_state() fails, the errno may be 0. But we assume
>> that the errno is not 0. So remove assert().
> 
> Thanks for spotting this.
> 
> I think this is going in the wrong direction.  Perhaps we could
> instead do something like the patch below ?  Please let me know what
> you think.
> 
> If you think this is a better idea, please submit it as a proper patch
> with a proper commit message.

OK, I will do it.

> 
> (Ideally we would fix the actual suspend hook in libxl, to always set
> errno, but that's too invasive a set of changes to do now, I think.)

libxl and helper program are two programs, and we should update the interface
between libxl and the hepler program first. We can do it later.

Thanks
Wen Congyang

> 
> Thanks,
> Ian.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
> index 40bbac8..3ab9dd8 100644
> --- a/tools/libxc/include/xenguest.h
> +++ b/tools/libxc/include/xenguest.h
> @@ -35,7 +35,9 @@
>  /* callbacks provided by xc_domain_save */
>  struct save_callbacks {
>      /* Called after expiration of checkpoint interval,
> -     * to suspend the guest.
> +     * to suspend the guest.  Returns 1 for success, or 0 for failure.
> +     * On failure it should ideally set errno.  (If it leaves errno
> +     * as 0, EIO will be used instead.)
>       */
>      int (*suspend)(void* data);
>  
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index 254fdb3..444aac6 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -361,9 +361,15 @@ static int suspend_and_state(int (*suspend)(void*), void* data,
>                               xc_interface *xch, int io_fd, int dom,
>                               xc_dominfo_t *info)
>  {
> +    errno = 0;
>      if ( !(*suspend)(data) )
>      {
> -        ERROR("Suspend request failed");
> +        if (!errno) {
> +            errno = EIO;
> +            ERROR("Suspend request failed (without errno, using EINVAL)");
> +        } else {
> +            ERROR("Suspend request failed");
> +        }
>          return -1;
>      }
>  
> .
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 01:24:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 01:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqB31-0001h1-Vi; Mon, 17 Nov 2014 01:24:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1XqB30-0001gw-Ja
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 01:24:06 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	76/18-25714-53E49645; Mon, 17 Nov 2014 01:24:05 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416187443!11657613!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29264 invoked from network); 17 Nov 2014 01:24:04 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-9.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 01:24:04 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43470169"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 17 Nov 2014 09:20:49 +0800
Received: from G08CNEXCHPEKD03.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAH1NlG0014942;
	Mon, 17 Nov 2014 09:23:47 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 17 Nov 2014 09:24:01 +0800
Message-ID: <54694EAA.7080403@cn.fujitsu.com>
Date: Mon, 17 Nov 2014 09:26:02 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1412820314-323-1-git-send-email-wency@cn.fujitsu.com>	<1412820314-323-3-git-send-email-wency@cn.fujitsu.com>
	<21606.6212.353346.560825@mariner.uk.xensource.com>
In-Reply-To: <21606.6212.353346.560825@mariner.uk.xensource.com>
X-Originating-IP: [10.167.226.91]
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch v2 2/3] correct xc_domain_save()'s return
	value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 10:57 PM, Ian Jackson wrote:
> Wen Congyang writes ("[Patch v2 2/3] correct xc_domain_save()'s return value"):
>> If suspend_and_state() fails, the errno may be 0. But we assume
>> that the errno is not 0. So remove assert().
> 
> Thanks for spotting this.
> 
> I think this is going in the wrong direction.  Perhaps we could
> instead do something like the patch below ?  Please let me know what
> you think.
> 
> If you think this is a better idea, please submit it as a proper patch
> with a proper commit message.

OK, I will do it.

> 
> (Ideally we would fix the actual suspend hook in libxl, to always set
> errno, but that's too invasive a set of changes to do now, I think.)

libxl and helper program are two programs, and we should update the interface
between libxl and the hepler program first. We can do it later.

Thanks
Wen Congyang

> 
> Thanks,
> Ian.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
> index 40bbac8..3ab9dd8 100644
> --- a/tools/libxc/include/xenguest.h
> +++ b/tools/libxc/include/xenguest.h
> @@ -35,7 +35,9 @@
>  /* callbacks provided by xc_domain_save */
>  struct save_callbacks {
>      /* Called after expiration of checkpoint interval,
> -     * to suspend the guest.
> +     * to suspend the guest.  Returns 1 for success, or 0 for failure.
> +     * On failure it should ideally set errno.  (If it leaves errno
> +     * as 0, EIO will be used instead.)
>       */
>      int (*suspend)(void* data);
>  
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index 254fdb3..444aac6 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -361,9 +361,15 @@ static int suspend_and_state(int (*suspend)(void*), void* data,
>                               xc_interface *xch, int io_fd, int dom,
>                               xc_dominfo_t *info)
>  {
> +    errno = 0;
>      if ( !(*suspend)(data) )
>      {
> -        ERROR("Suspend request failed");
> +        if (!errno) {
> +            errno = EIO;
> +            ERROR("Suspend request failed (without errno, using EINVAL)");
> +        } else {
> +            ERROR("Suspend request failed");
> +        }
>          return -1;
>      }
>  
> .
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 02:48:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 02:48:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqCMH-0002o4-11; Mon, 17 Nov 2014 02:48:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqCME-0002nz-PY
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 02:48:02 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	0B/9F-02712-1E169645; Mon, 17 Nov 2014 02:48:01 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416192480!12920708!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27013 invoked from network); 17 Nov 2014 02:48:01 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 02:48:01 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 16 Nov 2014 18:47:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="417399898"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by FMSMGA003.fm.intel.com with ESMTP; 16 Nov 2014 18:38:43 -0800
Message-ID: <546961DC.4040300@intel.com>
Date: Mon, 17 Nov 2014 10:47:56 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com>
In-Reply-To: <20141105140906.GA4912@redhat.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa
 bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/5 22:09, Michael S. Tsirkin wrote:
> On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
>> Currently IGD drivers always need to access PCH by 1f.0, and
>> PCH vendor/device id is used to identify the card.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
>>   1 file changed, 27 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>> index b559181..b19c7a9 100644
>> --- a/hw/i386/pc_piix.c
>> +++ b/hw/i386/pc_piix.c
>> @@ -50,7 +50,7 @@
>>   #include "cpu.h"
>>   #include "qemu/error-report.h"
>>   #ifdef CONFIG_XEN
>> -#  include <xen/hvm/hvm_info_table.h>
>> +#include <xen/hvm/hvm_info_table.h>
>>   #endif
>>
>>   #define MAX_IDE_BUS 2
>> @@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
>>   }
>>
>>   #ifdef CONFIG_XEN
>> +static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
>> +{
>> +    struct PCIDevice *dev;
>> +    Error *local_err = NULL;
>> +    uint16_t device_id = 0xffff;
>> +
>> +    /* Currently IGD drivers always need to access PCH by 1f.0. */
>> +    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
>> +                            "xen-igd-passthrough-isa-bridge");
>> +
>> +    /* Identify PCH card with its own real vendor/device ids.
>> +     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
>> +     */
>> +    if (dev) {
>> +        device_id = object_property_get_int(OBJECT(dev), "device-id",
>> +                                            &local_err);
>> +        if (!local_err && device_id != 0xffff) {
>> +            pci_config_set_device_id(dev->config, device_id);
>> +            return;
>> +        }
>> +    }
>> +
>> +    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
>> +}
>> +
>>   static void pc_xen_hvm_init(MachineState *machine)
>>   {
>>       PCIBus *bus;
>> @@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
>>       bus = pci_find_primary_bus();
>>       if (bus != NULL) {
>>           pci_create_simple(bus, -1, "xen-platform");
>> +        xen_igd_passthrough_isa_bridge_create(bus);
>>       }
>>   }
>>   #endif
>
> Can't we defer this step until the GPU is added?

Sounds great but I can't figure out where we can to do this exactly.

> This way there won't be need to poke at host device
> directly, you could get all info from dev->config
> of the host device.

As I understand We have two steps here:

#1 At first I have to write something to check if we're registering 
00:02.0 & IGD, right? But where? While registering each pci device?

#2 Then if that condition is matched, we register this ISA bridge on its 
associated bus.

Thanks
Tiejun

> Additionally the correct bridge would be initialized automatically.
>
>
>> --
>> 1.9.1
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 02:48:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 02:48:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqCMH-0002o4-11; Mon, 17 Nov 2014 02:48:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqCME-0002nz-PY
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 02:48:02 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	0B/9F-02712-1E169645; Mon, 17 Nov 2014 02:48:01 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416192480!12920708!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27013 invoked from network); 17 Nov 2014 02:48:01 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 02:48:01 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 16 Nov 2014 18:47:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="417399898"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by FMSMGA003.fm.intel.com with ESMTP; 16 Nov 2014 18:38:43 -0800
Message-ID: <546961DC.4040300@intel.com>
Date: Mon, 17 Nov 2014 10:47:56 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com>
In-Reply-To: <20141105140906.GA4912@redhat.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa
 bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/5 22:09, Michael S. Tsirkin wrote:
> On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
>> Currently IGD drivers always need to access PCH by 1f.0, and
>> PCH vendor/device id is used to identify the card.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
>>   1 file changed, 27 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>> index b559181..b19c7a9 100644
>> --- a/hw/i386/pc_piix.c
>> +++ b/hw/i386/pc_piix.c
>> @@ -50,7 +50,7 @@
>>   #include "cpu.h"
>>   #include "qemu/error-report.h"
>>   #ifdef CONFIG_XEN
>> -#  include <xen/hvm/hvm_info_table.h>
>> +#include <xen/hvm/hvm_info_table.h>
>>   #endif
>>
>>   #define MAX_IDE_BUS 2
>> @@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
>>   }
>>
>>   #ifdef CONFIG_XEN
>> +static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
>> +{
>> +    struct PCIDevice *dev;
>> +    Error *local_err = NULL;
>> +    uint16_t device_id = 0xffff;
>> +
>> +    /* Currently IGD drivers always need to access PCH by 1f.0. */
>> +    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
>> +                            "xen-igd-passthrough-isa-bridge");
>> +
>> +    /* Identify PCH card with its own real vendor/device ids.
>> +     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
>> +     */
>> +    if (dev) {
>> +        device_id = object_property_get_int(OBJECT(dev), "device-id",
>> +                                            &local_err);
>> +        if (!local_err && device_id != 0xffff) {
>> +            pci_config_set_device_id(dev->config, device_id);
>> +            return;
>> +        }
>> +    }
>> +
>> +    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
>> +}
>> +
>>   static void pc_xen_hvm_init(MachineState *machine)
>>   {
>>       PCIBus *bus;
>> @@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
>>       bus = pci_find_primary_bus();
>>       if (bus != NULL) {
>>           pci_create_simple(bus, -1, "xen-platform");
>> +        xen_igd_passthrough_isa_bridge_create(bus);
>>       }
>>   }
>>   #endif
>
> Can't we defer this step until the GPU is added?

Sounds great but I can't figure out where we can to do this exactly.

> This way there won't be need to poke at host device
> directly, you could get all info from dev->config
> of the host device.

As I understand We have two steps here:

#1 At first I have to write something to check if we're registering 
00:02.0 & IGD, right? But where? While registering each pci device?

#2 Then if that condition is matched, we register this ISA bridge on its 
associated bus.

Thanks
Tiejun

> Additionally the correct bridge would be initialized automatically.
>
>
>> --
>> 1.9.1
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 04:11:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 04:11:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqDf2-00043w-Fv; Mon, 17 Nov 2014 04:11:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <donald.d.dugger@intel.com>) id 1XqDf1-00043r-1B
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 04:11:31 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AF/68-09842-27579645; Mon, 17 Nov 2014 04:11:30 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416197488!13151739!1
X-Originating-IP: [67.41.209.129]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20250 invoked from network); 17 Nov 2014 04:11:29 -0000
Received: from willie.n0ano.com (HELO willie.n0ano.com) (67.41.209.129)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Nov 2014 04:11:29 -0000
Received: from maat.n0ano.com ([192.168.1.25])
	by willie.n0ano.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <donald.d.dugger@intel.com>)
	id 1XqDex-0000kT-Ms; Sun, 16 Nov 2014 21:11:27 -0700
Received: from n0ano by maat.n0ano.com with local (Exim 4.77)
	(envelope-from <donald.d.dugger@intel.com>)
	id 1XqDee-0007TD-RN; Sun, 16 Nov 2014 21:11:08 -0700
To: xen-devel@lists.xen.org
Message-Id: <E1XqDee-0007TD-RN@maat.n0ano.com>
From: Don Dugger <donald.d.dugger@intel.com>
Date: Sun, 16 Nov 2014 21:11:08 -0700
Cc: eddie.dong@intel.com, will.auld@intel.com, allen.m.kay@intel.com,
	JBeulich@suse.com
Subject: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently the quirk code for SandyBridge uses the VTd timeout value when
writing to an IGD register.  This is the wrong timeout to use and, at
1000 msec, is much too large.  Change this behavior by adding a new
boot paramter, snb_igd_timeout, that can specify the timeout to be used
when accessing the IGD registers in the quirk code.

For compatibility purposes, specifying the current boolean parameter,
snb_igd_quirk, will enable the quirk code with a timeout of 1000 msec.
Specifying the new parameter, snb_igd_timeout, with no value will
enable the quirk code with the theoretical maximum timeout of
670 msec.  Specifying a value for this parameter sets the timeout
to that number of msec.

Signed-off-by: Don Dugger <donald.d.dugger@intel.com>

diff -r 9d485e2c8339 xen/drivers/passthrough/vtd/quirks.c
--- a/xen/drivers/passthrough/vtd/quirks.c	Mon Nov 10 12:03:36 2014 +0000
+++ b/xen/drivers/passthrough/vtd/quirks.c	Sun Nov 16 17:28:17 2014 -0700
@@ -50,6 +50,9 @@
 #define IS_ILK(id)    (id == 0x00408086 || id == 0x00448086 || id== 0x00628086 || id == 0x006A8086)
 #define IS_CPT(id)    (id == 0x01008086 || id == 0x01048086)
 
+#define SNB_IGD_TIMEOUT	MILLISECS(670)
+static u32 snb_igd_timeout = MILLISECS(1000);
+
 static u32 __read_mostly ioh_id;
 static u32 __initdata igd_id;
 bool_t __read_mostly rwbf_quirk;
@@ -158,6 +161,20 @@
  * Workaround is to prevent graphics get into RC6
  * state when doing VT-d IOTLB operations, do the VT-d
  * IOTLB operation, and then re-enable RC6 state.
+ *
+ * This code, enabled by the Xen command line parameter
+ * snb_igd_quirk, due to legacy issues, uses th VTd timeout
+ * of 1000 msec.  This timeout is too large so a second
+ * integer parameter, snb_igd_timeout, can be used to fine
+ * tune the IGD register access timeout.
+ *
+ * Specifying snb_igd_timeout with no value enables this
+ * quirk and sets the timeout to the theoretical maximum
+ * of 670 msec.  Setting this parameter with a value enables
+ * this quirk and sets the timeout to that value.
+ *
+ * If neither snb_igd_quirk nor snb_igd_timeout are specified
+ * then the quirk code is not enabled.
  */
 static void snb_vtd_ops_preamble(struct iommu* iommu)
 {
@@ -177,7 +194,7 @@
     start_time = NOW();
     while ( (*(volatile u32 *)(igd_reg_va + 0x22AC) & 0xF) != 0 )
     {
-        if ( NOW() > start_time + DMAR_OPERATION_TIMEOUT )
+        if ( NOW() > start_time + snb_igd_timeout )
         {
             dprintk(XENLOG_INFO VTDPREFIX,
                     "snb_vtd_ops_preamble: failed to disable idle handshake\n");
@@ -237,6 +254,18 @@
     }
 }
 
+static void __init parse_snb_timeout(const char *s)
+{
+
+	if (*s == '\0')
+		snb_igd_timeout = SNB_IGD_TIMEOUT;
+	else
+		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
+	snb_igd_quirk = 1;
+	return;
+}
+custom_param("snb_igd_timeout", parse_snb_timeout);
+
 /* 5500/5520/X58 Chipset Interrupt remapping errata, for stepping B-3.
  * Fixed in stepping C-2. */
 static void __init tylersburg_intremap_quirk(void)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 04:11:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 04:11:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqDf2-00043w-Fv; Mon, 17 Nov 2014 04:11:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <donald.d.dugger@intel.com>) id 1XqDf1-00043r-1B
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 04:11:31 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AF/68-09842-27579645; Mon, 17 Nov 2014 04:11:30 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416197488!13151739!1
X-Originating-IP: [67.41.209.129]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20250 invoked from network); 17 Nov 2014 04:11:29 -0000
Received: from willie.n0ano.com (HELO willie.n0ano.com) (67.41.209.129)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Nov 2014 04:11:29 -0000
Received: from maat.n0ano.com ([192.168.1.25])
	by willie.n0ano.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <donald.d.dugger@intel.com>)
	id 1XqDex-0000kT-Ms; Sun, 16 Nov 2014 21:11:27 -0700
Received: from n0ano by maat.n0ano.com with local (Exim 4.77)
	(envelope-from <donald.d.dugger@intel.com>)
	id 1XqDee-0007TD-RN; Sun, 16 Nov 2014 21:11:08 -0700
To: xen-devel@lists.xen.org
Message-Id: <E1XqDee-0007TD-RN@maat.n0ano.com>
From: Don Dugger <donald.d.dugger@intel.com>
Date: Sun, 16 Nov 2014 21:11:08 -0700
Cc: eddie.dong@intel.com, will.auld@intel.com, allen.m.kay@intel.com,
	JBeulich@suse.com
Subject: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently the quirk code for SandyBridge uses the VTd timeout value when
writing to an IGD register.  This is the wrong timeout to use and, at
1000 msec, is much too large.  Change this behavior by adding a new
boot paramter, snb_igd_timeout, that can specify the timeout to be used
when accessing the IGD registers in the quirk code.

For compatibility purposes, specifying the current boolean parameter,
snb_igd_quirk, will enable the quirk code with a timeout of 1000 msec.
Specifying the new parameter, snb_igd_timeout, with no value will
enable the quirk code with the theoretical maximum timeout of
670 msec.  Specifying a value for this parameter sets the timeout
to that number of msec.

Signed-off-by: Don Dugger <donald.d.dugger@intel.com>

diff -r 9d485e2c8339 xen/drivers/passthrough/vtd/quirks.c
--- a/xen/drivers/passthrough/vtd/quirks.c	Mon Nov 10 12:03:36 2014 +0000
+++ b/xen/drivers/passthrough/vtd/quirks.c	Sun Nov 16 17:28:17 2014 -0700
@@ -50,6 +50,9 @@
 #define IS_ILK(id)    (id == 0x00408086 || id == 0x00448086 || id== 0x00628086 || id == 0x006A8086)
 #define IS_CPT(id)    (id == 0x01008086 || id == 0x01048086)
 
+#define SNB_IGD_TIMEOUT	MILLISECS(670)
+static u32 snb_igd_timeout = MILLISECS(1000);
+
 static u32 __read_mostly ioh_id;
 static u32 __initdata igd_id;
 bool_t __read_mostly rwbf_quirk;
@@ -158,6 +161,20 @@
  * Workaround is to prevent graphics get into RC6
  * state when doing VT-d IOTLB operations, do the VT-d
  * IOTLB operation, and then re-enable RC6 state.
+ *
+ * This code, enabled by the Xen command line parameter
+ * snb_igd_quirk, due to legacy issues, uses th VTd timeout
+ * of 1000 msec.  This timeout is too large so a second
+ * integer parameter, snb_igd_timeout, can be used to fine
+ * tune the IGD register access timeout.
+ *
+ * Specifying snb_igd_timeout with no value enables this
+ * quirk and sets the timeout to the theoretical maximum
+ * of 670 msec.  Setting this parameter with a value enables
+ * this quirk and sets the timeout to that value.
+ *
+ * If neither snb_igd_quirk nor snb_igd_timeout are specified
+ * then the quirk code is not enabled.
  */
 static void snb_vtd_ops_preamble(struct iommu* iommu)
 {
@@ -177,7 +194,7 @@
     start_time = NOW();
     while ( (*(volatile u32 *)(igd_reg_va + 0x22AC) & 0xF) != 0 )
     {
-        if ( NOW() > start_time + DMAR_OPERATION_TIMEOUT )
+        if ( NOW() > start_time + snb_igd_timeout )
         {
             dprintk(XENLOG_INFO VTDPREFIX,
                     "snb_vtd_ops_preamble: failed to disable idle handshake\n");
@@ -237,6 +254,18 @@
     }
 }
 
+static void __init parse_snb_timeout(const char *s)
+{
+
+	if (*s == '\0')
+		snb_igd_timeout = SNB_IGD_TIMEOUT;
+	else
+		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
+	snb_igd_quirk = 1;
+	return;
+}
+custom_param("snb_igd_timeout", parse_snb_timeout);
+
 /* 5500/5520/X58 Chipset Interrupt remapping errata, for stepping B-3.
  * Fixed in stepping C-2. */
 static void __init tylersburg_intremap_quirk(void)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 04:18:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 04: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 1XqDlw-0004GD-AP; Mon, 17 Nov 2014 04:18:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqDlu-0004G5-Vf
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 04:18:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BC/03-09936-E1779645; Mon, 17 Nov 2014 04:18:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416197916!12835478!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13554 invoked from network); 17 Nov 2014 04:18:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 04:18:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,400,1413244800"; d="scan'208";a="193424541"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 23:18:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqDlq-0002my-9r;
	Mon, 17 Nov 2014 04:18:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqDlq-0008PT-40;
	Mon, 17 Nov 2014 04:18:34 +0000
Date: Mon, 17 Nov 2014 04:18:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31618-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11741
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31618: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8261825137315131592=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8261825137315131592==
Content-Type: text/plain
Content-Length: 11512
Content-Transfer-Encoding: quoted-printable

flight 31618 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31618/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 31599

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install   fail in 31599 REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                4e70f9271dabc58fbf14680843bfac510c193152
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liang <liang.z.li@intel.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12699 lines long.)


--===============8261825137315131592==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8261825137315131592==--

From xen-devel-bounces@lists.xen.org Mon Nov 17 04:18:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 04: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 1XqDlw-0004GD-AP; Mon, 17 Nov 2014 04:18:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqDlu-0004G5-Vf
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 04:18:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BC/03-09936-E1779645; Mon, 17 Nov 2014 04:18:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416197916!12835478!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13554 invoked from network); 17 Nov 2014 04:18:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 04:18:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,400,1413244800"; d="scan'208";a="193424541"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 16 Nov 2014 23:18:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqDlq-0002my-9r;
	Mon, 17 Nov 2014 04:18:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqDlq-0008PT-40;
	Mon, 17 Nov 2014 04:18:34 +0000
Date: Mon, 17 Nov 2014 04:18:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31618-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11741
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31618: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8261825137315131592=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8261825137315131592==
Content-Type: text/plain
Content-Length: 11512
Content-Transfer-Encoding: quoted-printable

flight 31618 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31618/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 30603
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 31599

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install   fail in 31599 REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                4e70f9271dabc58fbf14680843bfac510c193152
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liang <liang.z.li@intel.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12699 lines long.)


--===============8261825137315131592==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8261825137315131592==--

From xen-devel-bounces@lists.xen.org Mon Nov 17 04:40:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 04:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqE6Z-0004Xz-3f; Mon, 17 Nov 2014 04:39:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <twwood@gmail.com>) id 1XqE6X-0004Xu-Qw
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 04:39:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	71/EF-07724-D1C79645; Mon, 17 Nov 2014 04:39:57 +0000
X-Env-Sender: twwood@gmail.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416199195!11775341!1
X-Originating-IP: [209.85.192.50]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22492 invoked from network); 17 Nov 2014 04:39:56 -0000
Received: from mail-qg0-f50.google.com (HELO mail-qg0-f50.google.com)
	(209.85.192.50)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 04:39:56 -0000
Received: by mail-qg0-f50.google.com with SMTP id e89so3699335qgf.9
	for <xen-devel@lists.xensource.com>;
	Sun, 16 Nov 2014 20:39:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:from:date:message-id:subject:to:content-type;
	bh=09aPjt3hF3y9CpK9Ga0ff/mCVF4Wn8zU/HO4NA42Tew=;
	b=J9nNIIzi8DLxJHmy3WtwWhe+ym7fcRsR0rB7UuySVjAU+j2qM2iFRD8NCFVvHlC8aV
	xOrIChN7LqVFnfqQW6fquoVc1dQTI7VX/SsW+d+ePtVXJqV833RY24nDSMy5KinpqLDc
	sZhjjZ+qaOVjXq6Regn0Yf8S2UO2AR2eEF8YXWN6V1Yat1JFhm3vc7VYENNeeWCsuELJ
	CcS7K1TjMXtSHSE9XAQfL7Jc3fMnW2VbjCm9J6FYaYMeJr6+SKbNdS21ajJSXcILZKY1
	IU9+7vcuBSDpXlGWOcCPM/QZSWQSqb8QwLiMUVnQpjJiYD15zIJ/kIbJMO5V0e8fSiCV
	qmEg==
X-Received: by 10.229.105.196 with SMTP id u4mr31346113qco.27.1416199195083;
	Sun, 16 Nov 2014 20:39:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.51.130 with HTTP; Sun, 16 Nov 2014 20:39:34 -0800 (PST)
From: Tim Wood <timwood@gwu.edu>
Date: Sun, 16 Nov 2014 23:39:34 -0500
X-Google-Sender-Auth: fCPAo1FlPs-cHvqL_axazKYL1kU
Message-ID: <CABm+uF9cqpdqrjbwj3WUaeZXPZsNkCVHdL_=m4xh9MMxKQduUg@mail.gmail.com>
To: Xen devel list <xen-devel@lists.xensource.com>
Subject: [Xen-devel] support for sharing huge pages with grant table?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6868289992065264449=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6868289992065264449==
Content-Type: multipart/alternative; boundary=001a11334604f44bbd0508069101

--001a11334604f44bbd0508069101
Content-Type: text/plain; charset=UTF-8

Hi,
I am curious if Xen currently supports sharing hugepages between domains
(specifically ones originally allocated in Dom-0 and shared with a guest
r/w).  I've seen some references to huge pages in the archives of this
list, but not in relation to the grant mechanism.

Also, can someone confirm that "superpages" are another term for "huge
pages" in Xen?

This would be helpful for some work we are doing on high speed networking
to VMs---DPDK stores packets into huge pages and we'd like to get those to
VMs as quickly as possible.

thanks!
Tim

--001a11334604f44bbd0508069101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hi,<br></div>I am curious if Xen currently =
supports sharing hugepages between domains (specifically ones originally al=
located in Dom-0 and shared with a guest r/w).=C2=A0 I&#39;ve seen some ref=
erences to huge pages in the archives of this list, but not in relation to =
the grant mechanism.<br><br></div><div>Also, can someone confirm that &quot=
;superpages&quot; are another term for &quot;huge pages&quot; in Xen?<br></=
div><div><br></div>This would be helpful for some work we are doing on high=
 speed networking to VMs---DPDK stores packets into huge pages and we&#39;d=
 like to get those to VMs as quickly as possible.<br><br></div>thanks!<br>T=
im<br></div>

--001a11334604f44bbd0508069101--


--===============6868289992065264449==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6868289992065264449==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 04:40:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 04:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqE6Z-0004Xz-3f; Mon, 17 Nov 2014 04:39:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <twwood@gmail.com>) id 1XqE6X-0004Xu-Qw
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 04:39:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	71/EF-07724-D1C79645; Mon, 17 Nov 2014 04:39:57 +0000
X-Env-Sender: twwood@gmail.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416199195!11775341!1
X-Originating-IP: [209.85.192.50]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22492 invoked from network); 17 Nov 2014 04:39:56 -0000
Received: from mail-qg0-f50.google.com (HELO mail-qg0-f50.google.com)
	(209.85.192.50)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 04:39:56 -0000
Received: by mail-qg0-f50.google.com with SMTP id e89so3699335qgf.9
	for <xen-devel@lists.xensource.com>;
	Sun, 16 Nov 2014 20:39:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:from:date:message-id:subject:to:content-type;
	bh=09aPjt3hF3y9CpK9Ga0ff/mCVF4Wn8zU/HO4NA42Tew=;
	b=J9nNIIzi8DLxJHmy3WtwWhe+ym7fcRsR0rB7UuySVjAU+j2qM2iFRD8NCFVvHlC8aV
	xOrIChN7LqVFnfqQW6fquoVc1dQTI7VX/SsW+d+ePtVXJqV833RY24nDSMy5KinpqLDc
	sZhjjZ+qaOVjXq6Regn0Yf8S2UO2AR2eEF8YXWN6V1Yat1JFhm3vc7VYENNeeWCsuELJ
	CcS7K1TjMXtSHSE9XAQfL7Jc3fMnW2VbjCm9J6FYaYMeJr6+SKbNdS21ajJSXcILZKY1
	IU9+7vcuBSDpXlGWOcCPM/QZSWQSqb8QwLiMUVnQpjJiYD15zIJ/kIbJMO5V0e8fSiCV
	qmEg==
X-Received: by 10.229.105.196 with SMTP id u4mr31346113qco.27.1416199195083;
	Sun, 16 Nov 2014 20:39:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.51.130 with HTTP; Sun, 16 Nov 2014 20:39:34 -0800 (PST)
From: Tim Wood <timwood@gwu.edu>
Date: Sun, 16 Nov 2014 23:39:34 -0500
X-Google-Sender-Auth: fCPAo1FlPs-cHvqL_axazKYL1kU
Message-ID: <CABm+uF9cqpdqrjbwj3WUaeZXPZsNkCVHdL_=m4xh9MMxKQduUg@mail.gmail.com>
To: Xen devel list <xen-devel@lists.xensource.com>
Subject: [Xen-devel] support for sharing huge pages with grant table?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6868289992065264449=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6868289992065264449==
Content-Type: multipart/alternative; boundary=001a11334604f44bbd0508069101

--001a11334604f44bbd0508069101
Content-Type: text/plain; charset=UTF-8

Hi,
I am curious if Xen currently supports sharing hugepages between domains
(specifically ones originally allocated in Dom-0 and shared with a guest
r/w).  I've seen some references to huge pages in the archives of this
list, but not in relation to the grant mechanism.

Also, can someone confirm that "superpages" are another term for "huge
pages" in Xen?

This would be helpful for some work we are doing on high speed networking
to VMs---DPDK stores packets into huge pages and we'd like to get those to
VMs as quickly as possible.

thanks!
Tim

--001a11334604f44bbd0508069101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hi,<br></div>I am curious if Xen currently =
supports sharing hugepages between domains (specifically ones originally al=
located in Dom-0 and shared with a guest r/w).=C2=A0 I&#39;ve seen some ref=
erences to huge pages in the archives of this list, but not in relation to =
the grant mechanism.<br><br></div><div>Also, can someone confirm that &quot=
;superpages&quot; are another term for &quot;huge pages&quot; in Xen?<br></=
div><div><br></div>This would be helpful for some work we are doing on high=
 speed networking to VMs---DPDK stores packets into huge pages and we&#39;d=
 like to get those to VMs as quickly as possible.<br><br></div>thanks!<br>T=
im<br></div>

--001a11334604f44bbd0508069101--


--===============6868289992065264449==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6868289992065264449==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 04:42:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 04: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 1XqE8v-0004jM-TP; Mon, 17 Nov 2014 04:42:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XqE8u-0004jH-Be
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 04:42:24 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	36/39-27785-FAC79645; Mon, 17 Nov 2014 04:42:23 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416199342!12939847!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2687 invoked from network); 17 Nov 2014 04:42:23 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 04:42:23 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 70D45ABA3;
	Mon, 17 Nov 2014 04:42:20 +0000 (UTC)
Message-ID: <54697CAA.5040601@suse.com>
Date: Mon, 17 Nov 2014 05:42:18 +0100
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ingo Molnar <mingo@kernel.org>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
	<20141116130847.GA4736@gmail.com>
In-Reply-To: <20141116130847.GA4736@gmail.com>
Content-Length: 2148
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, tglx@linutronix.de, plagnioj@jcrosoft.com,
	ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

T24gMTEvMTYvMjAxNCAwMjowOCBQTSwgSW5nbyBNb2xuYXIgd3JvdGU6Cj4KPiAqIEp1ZXJnZW4g
R3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4gd3JvdGU6Cj4KPj4gICBhcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9jYWNoZWZsdXNoLmggICAgICAgICB8ICAzOCArKysrLS0tCj4KPiBGWUksIHRoaXMgc2VyaWVz
IGJyZWFrcyB0aGUgVU1MIGJ1aWxkOgo+Cj4gSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC9ob21lL21p
bmdvL3RpcC9pbmNsdWRlL2xpbnV4L2hpZ2htZW0uaDoxMTowLAo+ICAgICAgICAgICAgICAgICAg
IGZyb20gL2hvbWUvbWluZ28vdGlwL2luY2x1ZGUvbGludXgvcGFnZW1hcC5oOjEwLAo+ICAgICAg
ICAgICAgICAgICAgIGZyb20gL2hvbWUvbWluZ28vdGlwL2luY2x1ZGUvbGludXgvbWVtcG9saWN5
Lmg6MTQsCj4gICAgICAgICAgICAgICAgICAgZnJvbSAvaG9tZS9taW5nby90aXAvaW5jbHVkZS9s
aW51eC9zaG1lbV9mcy5oOjYsCj4gICAgICAgICAgICAgICAgICAgZnJvbSAvaG9tZS9taW5nby90
aXAvaW5pdC9kb19tb3VudHMuYzozMDoKPiAvaG9tZS9taW5nby90aXAvYXJjaC94ODYvaW5jbHVk
ZS9hc20vY2FjaGVmbHVzaC5oOjY3OjM2OiBlcnJvcjogcmV0dXJuIHR5cGUgaXMgYW4gaW5jb21w
bGV0ZSB0eXBlCj4gICBzdGF0aWMgaW5saW5lIGVudW0gcGFnZV9jYWNoZV9tb2RlIGdldF9wYWdl
X21lbXR5cGUoc3RydWN0IHBhZ2UgKnBnKQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBeCj4gL2hvbWUvbWluZ28vdGlwL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NhY2hlZmx1
c2guaDogSW4gZnVuY3Rpb24g4oCYZ2V0X3BhZ2VfbWVtdHlwZeKAmToKPiAvaG9tZS9taW5nby90
aXAvYXJjaC94ODYvaW5jbHVkZS9hc20vY2FjaGVmbHVzaC5oOjY5OjI6IHdhcm5pbmc6IOKAmHJl
dHVybuKAmSB3aXRoIGEgdmFsdWUsIGluIGZ1bmN0aW9uIHJldHVybmluZyB2b2lkIFtlbmFibGVk
IGJ5IGRlZmF1bHRdCj4gICAgcmV0dXJuIC0xOwo+ICAgIF4KPiAvaG9tZS9taW5nby90aXAvYXJj
aC94ODYvaW5jbHVkZS9hc20vY2FjaGVmbHVzaC5oOiBBdCB0b3AgbGV2ZWw6Cj4gL2hvbWUvbWlu
Z28vdGlwL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NhY2hlZmx1c2guaDo3MjozMDogZXJyb3I6IHBh
cmFtZXRlciAyICjigJhtZW10eXBl4oCZKSBoYXMgaW5jb21wbGV0ZSB0eXBlCj4gICAgICAgICAg
IGVudW0gcGFnZV9jYWNoZV9tb2RlIG1lbXR5cGUpCj4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIF4KPiAvaG9tZS9taW5nby90aXAvYXJjaC94ODYvaW5jbHVkZS9hc20vY2FjaGVmbHVz
aC5oOjcxOjIwOiBlcnJvcjogZnVuY3Rpb24gZGVjbGFyYXRpb24gaXNu4oCZdCBhIHByb3RvdHlw
ZSBbLVdlcnJvcj1zdHJpY3QtcHJvdG90eXBlc10KClRob21hcyBhbHJlYWR5IGNvbW1pdHRlZCBh
IGZpeHVwLiBUaGFuayB5b3UsIFRob21hcy4KCgpKdWVyZ2VuCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Nov 17 04:42:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 04: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 1XqE8v-0004jM-TP; Mon, 17 Nov 2014 04:42:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XqE8u-0004jH-Be
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 04:42:24 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	36/39-27785-FAC79645; Mon, 17 Nov 2014 04:42:23 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416199342!12939847!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2687 invoked from network); 17 Nov 2014 04:42:23 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 04:42:23 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 70D45ABA3;
	Mon, 17 Nov 2014 04:42:20 +0000 (UTC)
Message-ID: <54697CAA.5040601@suse.com>
Date: Mon, 17 Nov 2014 05:42:18 +0100
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ingo Molnar <mingo@kernel.org>
References: <1415019724-4317-1-git-send-email-jgross@suse.com>
	<20141116130847.GA4736@gmail.com>
In-Reply-To: <20141116130847.GA4736@gmail.com>
Content-Length: 2148
Cc: xen-devel@lists.xensource.com, toshi.kani@hp.com, tomi.valkeinen@ti.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stefan.bader@canonical.com, mingo@redhat.com,
	david.vrabel@citrix.com, jbeulich@suse.com, hpa@zytor.com,
	bhelgaas@google.com, tglx@linutronix.de, plagnioj@jcrosoft.com,
	ville.syrjala@linux.intel.com
Subject: Re: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

T24gMTEvMTYvMjAxNCAwMjowOCBQTSwgSW5nbyBNb2xuYXIgd3JvdGU6Cj4KPiAqIEp1ZXJnZW4g
R3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4gd3JvdGU6Cj4KPj4gICBhcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9jYWNoZWZsdXNoLmggICAgICAgICB8ICAzOCArKysrLS0tCj4KPiBGWUksIHRoaXMgc2VyaWVz
IGJyZWFrcyB0aGUgVU1MIGJ1aWxkOgo+Cj4gSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC9ob21lL21p
bmdvL3RpcC9pbmNsdWRlL2xpbnV4L2hpZ2htZW0uaDoxMTowLAo+ICAgICAgICAgICAgICAgICAg
IGZyb20gL2hvbWUvbWluZ28vdGlwL2luY2x1ZGUvbGludXgvcGFnZW1hcC5oOjEwLAo+ICAgICAg
ICAgICAgICAgICAgIGZyb20gL2hvbWUvbWluZ28vdGlwL2luY2x1ZGUvbGludXgvbWVtcG9saWN5
Lmg6MTQsCj4gICAgICAgICAgICAgICAgICAgZnJvbSAvaG9tZS9taW5nby90aXAvaW5jbHVkZS9s
aW51eC9zaG1lbV9mcy5oOjYsCj4gICAgICAgICAgICAgICAgICAgZnJvbSAvaG9tZS9taW5nby90
aXAvaW5pdC9kb19tb3VudHMuYzozMDoKPiAvaG9tZS9taW5nby90aXAvYXJjaC94ODYvaW5jbHVk
ZS9hc20vY2FjaGVmbHVzaC5oOjY3OjM2OiBlcnJvcjogcmV0dXJuIHR5cGUgaXMgYW4gaW5jb21w
bGV0ZSB0eXBlCj4gICBzdGF0aWMgaW5saW5lIGVudW0gcGFnZV9jYWNoZV9tb2RlIGdldF9wYWdl
X21lbXR5cGUoc3RydWN0IHBhZ2UgKnBnKQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBeCj4gL2hvbWUvbWluZ28vdGlwL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NhY2hlZmx1
c2guaDogSW4gZnVuY3Rpb24g4oCYZ2V0X3BhZ2VfbWVtdHlwZeKAmToKPiAvaG9tZS9taW5nby90
aXAvYXJjaC94ODYvaW5jbHVkZS9hc20vY2FjaGVmbHVzaC5oOjY5OjI6IHdhcm5pbmc6IOKAmHJl
dHVybuKAmSB3aXRoIGEgdmFsdWUsIGluIGZ1bmN0aW9uIHJldHVybmluZyB2b2lkIFtlbmFibGVk
IGJ5IGRlZmF1bHRdCj4gICAgcmV0dXJuIC0xOwo+ICAgIF4KPiAvaG9tZS9taW5nby90aXAvYXJj
aC94ODYvaW5jbHVkZS9hc20vY2FjaGVmbHVzaC5oOiBBdCB0b3AgbGV2ZWw6Cj4gL2hvbWUvbWlu
Z28vdGlwL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NhY2hlZmx1c2guaDo3MjozMDogZXJyb3I6IHBh
cmFtZXRlciAyICjigJhtZW10eXBl4oCZKSBoYXMgaW5jb21wbGV0ZSB0eXBlCj4gICAgICAgICAg
IGVudW0gcGFnZV9jYWNoZV9tb2RlIG1lbXR5cGUpCj4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIF4KPiAvaG9tZS9taW5nby90aXAvYXJjaC94ODYvaW5jbHVkZS9hc20vY2FjaGVmbHVz
aC5oOjcxOjIwOiBlcnJvcjogZnVuY3Rpb24gZGVjbGFyYXRpb24gaXNu4oCZdCBhIHByb3RvdHlw
ZSBbLVdlcnJvcj1zdHJpY3QtcHJvdG90eXBlc10KClRob21hcyBhbHJlYWR5IGNvbW1pdHRlZCBh
IGZpeHVwLiBUaGFuayB5b3UsIFRob21hcy4KCgpKdWVyZ2VuCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Nov 17 05:21:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 05:21:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqEki-0005LY-G1; Mon, 17 Nov 2014 05:21:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqEkg-0005LT-VP
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 05:21:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	37/CF-24532-6D589645; Mon, 17 Nov 2014 05:21:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416201684!13157652!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13639 invoked from network); 17 Nov 2014 05:21:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 05:21:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,401,1413244800"; d="scan'208";a="193431624"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 00:21:22 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqEkc-00035o-9r;
	Mon, 17 Nov 2014 05:21:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqEkc-0001W8-3L;
	Mon, 17 Nov 2014 05:21:22 +0000
Date: Mon, 17 Nov 2014 05:21:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31603-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 13003
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31603: 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: multipart/mixed; boundary="===============2025240866498922971=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2025240866498922971==
Content-Type: text/plain
Content-Length: 12791
Content-Transfer-Encoding: quoted-printable

flight 31603 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31603/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl           9 guest-start                 fail pass in 31574
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 31574
 test-amd64-i386-xl            5 xen-boot           fail in 31574 pass in 31603
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 5 xen-boot fail in 31574 pass in 31603

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 31237

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-armhf-armhf-xl          10 migrate-support-check fail in 31574 never pass

version targeted for testing:
 qemuu                abbbc2f09a53f8f9ee565356ab11a78af006e45e
baseline version:
 qemuu                ca78cc83650b535d7e24baeaea32947be0141534

------------------------------------------------------------
People who touched revisions under test:
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dqemu-upstream-unstable
+ revision=3Dabbbc2f09a53f8f9ee565356ab11a78af006e45e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable abbbc2f09a53f8f9ee565356ab11a78af006e45e
+ branch=3Dqemu-upstream-unstable
+ revision=3Dabbbc2f09a53f8f9ee565356ab11a78af006e45e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dqemuu
+ xenbranch=3Dxen-unstable
+ '[' xqemuu =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : 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
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git abbbc2f09a53f8f9ee565356ab11a78af006e45e:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
   ca78cc8..abbbc2f  abbbc2f09a53f8f9ee565356ab11a78af006e45e -> master


--===============2025240866498922971==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2025240866498922971==--

From xen-devel-bounces@lists.xen.org Mon Nov 17 05:21:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 05:21:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqEki-0005LY-G1; Mon, 17 Nov 2014 05:21:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqEkg-0005LT-VP
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 05:21:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	37/CF-24532-6D589645; Mon, 17 Nov 2014 05:21:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416201684!13157652!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13639 invoked from network); 17 Nov 2014 05:21:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 05:21:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,401,1413244800"; d="scan'208";a="193431624"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 00:21:22 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqEkc-00035o-9r;
	Mon, 17 Nov 2014 05:21:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqEkc-0001W8-3L;
	Mon, 17 Nov 2014 05:21:22 +0000
Date: Mon, 17 Nov 2014 05:21:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31603-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 13003
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31603: 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: multipart/mixed; boundary="===============2025240866498922971=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2025240866498922971==
Content-Type: text/plain
Content-Length: 12791
Content-Transfer-Encoding: quoted-printable

flight 31603 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31603/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl           9 guest-start                 fail pass in 31574
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 31574
 test-amd64-i386-xl            5 xen-boot           fail in 31574 pass in 31603
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 5 xen-boot fail in 31574 pass in 31603

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 31237

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-armhf-armhf-xl          10 migrate-support-check fail in 31574 never pass

version targeted for testing:
 qemuu                abbbc2f09a53f8f9ee565356ab11a78af006e45e
baseline version:
 qemuu                ca78cc83650b535d7e24baeaea32947be0141534

------------------------------------------------------------
People who touched revisions under test:
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dqemu-upstream-unstable
+ revision=3Dabbbc2f09a53f8f9ee565356ab11a78af006e45e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable abbbc2f09a53f8f9ee565356ab11a78af006e45e
+ branch=3Dqemu-upstream-unstable
+ revision=3Dabbbc2f09a53f8f9ee565356ab11a78af006e45e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dqemuu
+ xenbranch=3Dxen-unstable
+ '[' xqemuu =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : 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
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git abbbc2f09a53f8f9ee565356ab11a78af006e45e:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
   ca78cc8..abbbc2f  abbbc2f09a53f8f9ee565356ab11a78af006e45e -> master


--===============2025240866498922971==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2025240866498922971==--

From xen-devel-bounces@lists.xen.org Mon Nov 17 05:24:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 05: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 1XqEns-0005X2-Ew; Mon, 17 Nov 2014 05:24:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liangx.z.li@intel.com>) id 1XqEnr-0005Wt-4E
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 05:24:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	6F/8A-02702-A9689645; Mon, 17 Nov 2014 05:24:42 +0000
X-Env-Sender: liangx.z.li@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416201878!12917959!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5881 invoked from network); 17 Nov 2014 05:24:41 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 05:24:41 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 16 Nov 2014 21:24:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,401,1413270000"; d="scan'208";a="623390069"
Received: from lil.sh.intel.com (HELO localhost) ([10.239.36.68])
	by fmsmga001.fm.intel.com with ESMTP; 16 Nov 2014 21:24:36 -0800
From: Liang Li <liang.z.li@intel.com>
To: xen-devel@lists.xen.org
Date: Mon, 17 Nov 2014 13:16:49 +0800
Message-Id: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com,
	Liang Li <liang.z.li@intel.com>, ian.jackson@eu.citrix.com,
	yang.z.zhang@intel.com
Subject: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to 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>
MIME-Version: 1.0
Content-Type: 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 hardware support the pdpe1gb flag, expose it to guest by default.
Users don't have to use a 'cpuid= ' option in config file to turn
it on.

Signed-off-by: Liang Li <liang.z.li@intel.com>
---
 tools/libxc/xc_cpuid_x86.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index a18b1ff..c97f91a 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -109,6 +109,7 @@ static void amd_xc_cpuid_policy(
         regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */
                     bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_MP) |
                     bitmaskof(X86_FEATURE_MMXEXT) |
@@ -192,6 +193,7 @@ static void intel_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_ABM));
         regs[3] &= (bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_RDTSCP));
         break;
@@ -386,6 +388,7 @@ static void xc_cpuid_hvm_policy(
             clear_bit(X86_FEATURE_LM, regs[3]);
             clear_bit(X86_FEATURE_NX, regs[3]);
             clear_bit(X86_FEATURE_PSE36, regs[3]);
+            clear_bit(X86_FEATURE_PAGE1GB, regs[3]);
         }
         break;
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 05:24:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 05: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 1XqEns-0005X2-Ew; Mon, 17 Nov 2014 05:24:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liangx.z.li@intel.com>) id 1XqEnr-0005Wt-4E
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 05:24:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	6F/8A-02702-A9689645; Mon, 17 Nov 2014 05:24:42 +0000
X-Env-Sender: liangx.z.li@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416201878!12917959!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5881 invoked from network); 17 Nov 2014 05:24:41 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 05:24:41 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 16 Nov 2014 21:24:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,401,1413270000"; d="scan'208";a="623390069"
Received: from lil.sh.intel.com (HELO localhost) ([10.239.36.68])
	by fmsmga001.fm.intel.com with ESMTP; 16 Nov 2014 21:24:36 -0800
From: Liang Li <liang.z.li@intel.com>
To: xen-devel@lists.xen.org
Date: Mon, 17 Nov 2014 13:16:49 +0800
Message-Id: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com,
	Liang Li <liang.z.li@intel.com>, ian.jackson@eu.citrix.com,
	yang.z.zhang@intel.com
Subject: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to 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>
MIME-Version: 1.0
Content-Type: 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 hardware support the pdpe1gb flag, expose it to guest by default.
Users don't have to use a 'cpuid= ' option in config file to turn
it on.

Signed-off-by: Liang Li <liang.z.li@intel.com>
---
 tools/libxc/xc_cpuid_x86.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index a18b1ff..c97f91a 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -109,6 +109,7 @@ static void amd_xc_cpuid_policy(
         regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */
                     bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_MP) |
                     bitmaskof(X86_FEATURE_MMXEXT) |
@@ -192,6 +193,7 @@ static void intel_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_ABM));
         regs[3] &= (bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_RDTSCP));
         break;
@@ -386,6 +388,7 @@ static void xc_cpuid_hvm_policy(
             clear_bit(X86_FEATURE_LM, regs[3]);
             clear_bit(X86_FEATURE_NX, regs[3]);
             clear_bit(X86_FEATURE_PSE36, regs[3]);
+            clear_bit(X86_FEATURE_PAGE1GB, regs[3]);
         }
         break;
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 06:10:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 06:10:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqFW2-00066Q-Kd; Mon, 17 Nov 2014 06:10:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1XqFW0-00066L-Sl
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 06:10:20 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	57/7A-02696-C4199645; Mon, 17 Nov 2014 06:10:20 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416204617!12948822!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16075 invoked from network); 17 Nov 2014 06:10:19 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 06:10:19 -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 sAH6AEQl022548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 17 Nov 2014 01:10:14 -0500
Received: from redhat.com (ovpn-116-29.ams2.redhat.com [10.36.116.29])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sAH6ABHi000641; Mon, 17 Nov 2014 01:10:12 -0500
Date: Mon, 17 Nov 2014 08:10:10 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141117061010.GB19718@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546961DC.4040300@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa
 bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
> On 2014/11/5 22:09, Michael S. Tsirkin wrote:
> >On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
> >>Currently IGD drivers always need to access PCH by 1f.0, and
> >>PCH vendor/device id is used to identify the card.
> >>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>---
> >>  hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
> >>  1 file changed, 27 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> >>index b559181..b19c7a9 100644
> >>--- a/hw/i386/pc_piix.c
> >>+++ b/hw/i386/pc_piix.c
> >>@@ -50,7 +50,7 @@
> >>  #include "cpu.h"
> >>  #include "qemu/error-report.h"
> >>  #ifdef CONFIG_XEN
> >>-#  include <xen/hvm/hvm_info_table.h>
> >>+#include <xen/hvm/hvm_info_table.h>
> >>  #endif
> >>
> >>  #define MAX_IDE_BUS 2
> >>@@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
> >>  }
> >>
> >>  #ifdef CONFIG_XEN
> >>+static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
> >>+{
> >>+    struct PCIDevice *dev;
> >>+    Error *local_err = NULL;
> >>+    uint16_t device_id = 0xffff;
> >>+
> >>+    /* Currently IGD drivers always need to access PCH by 1f.0. */
> >>+    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
> >>+                            "xen-igd-passthrough-isa-bridge");
> >>+
> >>+    /* Identify PCH card with its own real vendor/device ids.
> >>+     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
> >>+     */
> >>+    if (dev) {
> >>+        device_id = object_property_get_int(OBJECT(dev), "device-id",
> >>+                                            &local_err);
> >>+        if (!local_err && device_id != 0xffff) {
> >>+            pci_config_set_device_id(dev->config, device_id);
> >>+            return;
> >>+        }
> >>+    }
> >>+
> >>+    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
> >>+}
> >>+
> >>  static void pc_xen_hvm_init(MachineState *machine)
> >>  {
> >>      PCIBus *bus;
> >>@@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
> >>      bus = pci_find_primary_bus();
> >>      if (bus != NULL) {
> >>          pci_create_simple(bus, -1, "xen-platform");
> >>+        xen_igd_passthrough_isa_bridge_create(bus);
> >>      }
> >>  }
> >>  #endif
> >
> >Can't we defer this step until the GPU is added?
> 
> Sounds great but I can't figure out where we can to do this exactly.
> 
> >This way there won't be need to poke at host device
> >directly, you could get all info from dev->config
> >of the host device.
> 
> As I understand We have two steps here:
> 
> #1 At first I have to write something to check if we're registering 00:02.0
> & IGD, right? But where? While registering each pci device?

In xen_pt_initfn.
Just check the device and vendor ID against the table you have.


> #2 Then if that condition is matched, we register this ISA bridge on its
> associated bus.
> 
> Thanks
> Tiejun

Yep.

> >Additionally the correct bridge would be initialized automatically.
> >
> >
> >>--
> >>1.9.1
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 06:10:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 06:10:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqFW2-00066Q-Kd; Mon, 17 Nov 2014 06:10:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1XqFW0-00066L-Sl
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 06:10:20 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	57/7A-02696-C4199645; Mon, 17 Nov 2014 06:10:20 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416204617!12948822!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16075 invoked from network); 17 Nov 2014 06:10:19 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 06:10:19 -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 sAH6AEQl022548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 17 Nov 2014 01:10:14 -0500
Received: from redhat.com (ovpn-116-29.ams2.redhat.com [10.36.116.29])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sAH6ABHi000641; Mon, 17 Nov 2014 01:10:12 -0500
Date: Mon, 17 Nov 2014 08:10:10 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141117061010.GB19718@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546961DC.4040300@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa
 bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
> On 2014/11/5 22:09, Michael S. Tsirkin wrote:
> >On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
> >>Currently IGD drivers always need to access PCH by 1f.0, and
> >>PCH vendor/device id is used to identify the card.
> >>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>---
> >>  hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
> >>  1 file changed, 27 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> >>index b559181..b19c7a9 100644
> >>--- a/hw/i386/pc_piix.c
> >>+++ b/hw/i386/pc_piix.c
> >>@@ -50,7 +50,7 @@
> >>  #include "cpu.h"
> >>  #include "qemu/error-report.h"
> >>  #ifdef CONFIG_XEN
> >>-#  include <xen/hvm/hvm_info_table.h>
> >>+#include <xen/hvm/hvm_info_table.h>
> >>  #endif
> >>
> >>  #define MAX_IDE_BUS 2
> >>@@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
> >>  }
> >>
> >>  #ifdef CONFIG_XEN
> >>+static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
> >>+{
> >>+    struct PCIDevice *dev;
> >>+    Error *local_err = NULL;
> >>+    uint16_t device_id = 0xffff;
> >>+
> >>+    /* Currently IGD drivers always need to access PCH by 1f.0. */
> >>+    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
> >>+                            "xen-igd-passthrough-isa-bridge");
> >>+
> >>+    /* Identify PCH card with its own real vendor/device ids.
> >>+     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
> >>+     */
> >>+    if (dev) {
> >>+        device_id = object_property_get_int(OBJECT(dev), "device-id",
> >>+                                            &local_err);
> >>+        if (!local_err && device_id != 0xffff) {
> >>+            pci_config_set_device_id(dev->config, device_id);
> >>+            return;
> >>+        }
> >>+    }
> >>+
> >>+    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
> >>+}
> >>+
> >>  static void pc_xen_hvm_init(MachineState *machine)
> >>  {
> >>      PCIBus *bus;
> >>@@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
> >>      bus = pci_find_primary_bus();
> >>      if (bus != NULL) {
> >>          pci_create_simple(bus, -1, "xen-platform");
> >>+        xen_igd_passthrough_isa_bridge_create(bus);
> >>      }
> >>  }
> >>  #endif
> >
> >Can't we defer this step until the GPU is added?
> 
> Sounds great but I can't figure out where we can to do this exactly.
> 
> >This way there won't be need to poke at host device
> >directly, you could get all info from dev->config
> >of the host device.
> 
> As I understand We have two steps here:
> 
> #1 At first I have to write something to check if we're registering 00:02.0
> & IGD, right? But where? While registering each pci device?

In xen_pt_initfn.
Just check the device and vendor ID against the table you have.


> #2 Then if that condition is matched, we register this ISA bridge on its
> associated bus.
> 
> Thanks
> Tiejun

Yep.

> >Additionally the correct bridge would be initialized automatically.
> >
> >
> >>--
> >>1.9.1
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 07:30:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 07:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqGku-00074K-VC; Mon, 17 Nov 2014 07:29:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linxingnku@gmail.com>) id 1XpUgl-0000Nx-0Z
	for xen-devel@lists.xen.org; Sat, 15 Nov 2014 04:10:19 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	E9/09-02698-A22D6645; Sat, 15 Nov 2014 04:10:18 +0000
X-Env-Sender: linxingnku@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416024616!7298840!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26697 invoked from network); 15 Nov 2014 04:10:16 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 04:10:16 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so21096611wgg.19
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 20:10:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=b0wZ3A4ak2osL9McmduLDOGR/zPUb9vzrWOtfMHjb3E=;
	b=B8emeyA8gwEqItnGtWu4UFo67tVgKB1VmUZuv3zesMNRYMsk1Jl0JfYYnKwdaxkCnl
	4VrnXL0yQlaFBR+0s9uzTO3LMc5H20yZGEPOAMOOIUa9pYdFkiSbE4Jw//VpjrkuA0P8
	8FFN4h/gPQvVQpGP8h1lvmPvTREup8HjqUROpRImCgSYPB3M9PAT7FepY8/VO76DvE1R
	u+WIGcidWA2LFrjaOJTulgSrKURjRaDpNdYkLDjSfi0GBCyCVTa8RJ2p0esqs6S4xWLG
	D+1tqwpnWy9ZW4uU3w8LutXSjMUXCiQ83x3HCk4QBIW8rTAJ+TS7LS4MUgvjrzcYueDz
	WvUQ==
MIME-Version: 1.0
X-Received: by 10.180.90.241 with SMTP id bz17mr13098463wib.41.1416024616323; 
	Fri, 14 Nov 2014 20:10:16 -0800 (PST)
Received: by 10.27.132.215 with HTTP; Fri, 14 Nov 2014 20:10:16 -0800 (PST)
In-Reply-To: <1415955718.31613.34.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
Date: Fri, 14 Nov 2014 21:10:16 -0700
Message-ID: <CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
From: Xing Lin <linxingnku@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Mon, 17 Nov 2014 07:29:48 +0000
Cc: xen-devel@lists.xen.org,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3296379883063420395=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3296379883063420395==
Content-Type: multipart/alternative; boundary=f46d043be0243fd31f0507ddec9e

--f46d043be0243fd31f0507ddec9e
Content-Type: text/plain; charset=UTF-8

Hi,

The wiki page is ready. I am not sure whether I am using the correct format
or not. Please let me know if any changes are need. Thanks,

http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno

-Xing

On Fri, Nov 14, 2014 at 2:01 AM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Thu, 2014-11-13 at 22:54 -0700, Xing Lin wrote:
> > I have been blocked by this problem for almost three weeks and as far
> > as I know, I could not find any online tutorial on setting up xen
> > based compute node for openstack juno. I will document steps I take
> > and share them with the community.
>
> Awesome, thanks!
>
> Having this in the Xen wiki would be awesome. If you would like write
> access to our wiki (which is granted manually due to spammers spoiling
> it for everyone...) then please:
>
>       * Create an account using the "create account" link at the
>         top-right hand side of http://wiki.xen.org/wiki/Main_Page
>       * Fill in this form giving your chosen username:
>
> http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html
>
> You could alternatively drop me a line privately with the user name for
> the second step, but filling in the form might give a quicker response
> time due to reaching multiple people in multiple timezones...
>
> Ian.
>
>

--f46d043be0243fd31f0507ddec9e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div>The wiki page is ready. I am =
not sure whether I am using the correct format or not. Please let me know i=
f any changes are need. Thanks,<div><br></div><div><a href=3D"http://wiki.x=
enproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno">http://wiki.xenproje=
ct.org/wiki/Xen_via_libvirt_for_OpenStack_juno</a><br></div><div><br></div>=
<div>-Xing</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Fri, Nov 14, 2014 at 2:01 AM, Ian Campbell <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@cit=
rix.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"><span class=
=3D"">On Thu, 2014-11-13 at 22:54 -0700, Xing Lin wrote:<br>
&gt; I have been blocked by this problem for almost three weeks and as far<=
br>
&gt; as I know, I could not find any online tutorial on setting up xen<br>
&gt; based compute node for openstack juno. I will document steps I take<br=
>
&gt; and share them with the community.<br>
<br>
</span>Awesome, thanks!<br>
<br>
Having this in the Xen wiki would be awesome. If you would like write<br>
access to our wiki (which is granted manually due to spammers spoiling<br>
it for everyone...) then please:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * Create an account using the &quot;create account&quo=
t; link at the<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 top-right hand side of <a href=3D"http://wiki.x=
en.org/wiki/Main_Page" target=3D"_blank">http://wiki.xen.org/wiki/Main_Page=
</a><br>
=C2=A0 =C2=A0 =C2=A0 * Fill in this form giving your chosen username:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://xenproject.org/component/cont=
ent/article/100-misc/145-request-to-be-made-a-wiki-editor.html" target=3D"_=
blank">http://xenproject.org/component/content/article/100-misc/145-request=
-to-be-made-a-wiki-editor.html</a><br>
<br>
You could alternatively drop me a line privately with the user name for<br>
the second step, but filling in the form might give a quicker response<br>
time due to reaching multiple people in multiple timezones...<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><br></div>

--f46d043be0243fd31f0507ddec9e--


--===============3296379883063420395==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3296379883063420395==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 07:30:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 07:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqGku-00074K-VC; Mon, 17 Nov 2014 07:29:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linxingnku@gmail.com>) id 1XpUgl-0000Nx-0Z
	for xen-devel@lists.xen.org; Sat, 15 Nov 2014 04:10:19 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	E9/09-02698-A22D6645; Sat, 15 Nov 2014 04:10:18 +0000
X-Env-Sender: linxingnku@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416024616!7298840!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26697 invoked from network); 15 Nov 2014 04:10:16 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Nov 2014 04:10:16 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so21096611wgg.19
	for <xen-devel@lists.xen.org>; Fri, 14 Nov 2014 20:10:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=b0wZ3A4ak2osL9McmduLDOGR/zPUb9vzrWOtfMHjb3E=;
	b=B8emeyA8gwEqItnGtWu4UFo67tVgKB1VmUZuv3zesMNRYMsk1Jl0JfYYnKwdaxkCnl
	4VrnXL0yQlaFBR+0s9uzTO3LMc5H20yZGEPOAMOOIUa9pYdFkiSbE4Jw//VpjrkuA0P8
	8FFN4h/gPQvVQpGP8h1lvmPvTREup8HjqUROpRImCgSYPB3M9PAT7FepY8/VO76DvE1R
	u+WIGcidWA2LFrjaOJTulgSrKURjRaDpNdYkLDjSfi0GBCyCVTa8RJ2p0esqs6S4xWLG
	D+1tqwpnWy9ZW4uU3w8LutXSjMUXCiQ83x3HCk4QBIW8rTAJ+TS7LS4MUgvjrzcYueDz
	WvUQ==
MIME-Version: 1.0
X-Received: by 10.180.90.241 with SMTP id bz17mr13098463wib.41.1416024616323; 
	Fri, 14 Nov 2014 20:10:16 -0800 (PST)
Received: by 10.27.132.215 with HTTP; Fri, 14 Nov 2014 20:10:16 -0800 (PST)
In-Reply-To: <1415955718.31613.34.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
Date: Fri, 14 Nov 2014 21:10:16 -0700
Message-ID: <CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
From: Xing Lin <linxingnku@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Mon, 17 Nov 2014 07:29:48 +0000
Cc: xen-devel@lists.xen.org,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3296379883063420395=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3296379883063420395==
Content-Type: multipart/alternative; boundary=f46d043be0243fd31f0507ddec9e

--f46d043be0243fd31f0507ddec9e
Content-Type: text/plain; charset=UTF-8

Hi,

The wiki page is ready. I am not sure whether I am using the correct format
or not. Please let me know if any changes are need. Thanks,

http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno

-Xing

On Fri, Nov 14, 2014 at 2:01 AM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Thu, 2014-11-13 at 22:54 -0700, Xing Lin wrote:
> > I have been blocked by this problem for almost three weeks and as far
> > as I know, I could not find any online tutorial on setting up xen
> > based compute node for openstack juno. I will document steps I take
> > and share them with the community.
>
> Awesome, thanks!
>
> Having this in the Xen wiki would be awesome. If you would like write
> access to our wiki (which is granted manually due to spammers spoiling
> it for everyone...) then please:
>
>       * Create an account using the "create account" link at the
>         top-right hand side of http://wiki.xen.org/wiki/Main_Page
>       * Fill in this form giving your chosen username:
>
> http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html
>
> You could alternatively drop me a line privately with the user name for
> the second step, but filling in the form might give a quicker response
> time due to reaching multiple people in multiple timezones...
>
> Ian.
>
>

--f46d043be0243fd31f0507ddec9e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div>The wiki page is ready. I am =
not sure whether I am using the correct format or not. Please let me know i=
f any changes are need. Thanks,<div><br></div><div><a href=3D"http://wiki.x=
enproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno">http://wiki.xenproje=
ct.org/wiki/Xen_via_libvirt_for_OpenStack_juno</a><br></div><div><br></div>=
<div>-Xing</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Fri, Nov 14, 2014 at 2:01 AM, Ian Campbell <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@cit=
rix.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"><span class=
=3D"">On Thu, 2014-11-13 at 22:54 -0700, Xing Lin wrote:<br>
&gt; I have been blocked by this problem for almost three weeks and as far<=
br>
&gt; as I know, I could not find any online tutorial on setting up xen<br>
&gt; based compute node for openstack juno. I will document steps I take<br=
>
&gt; and share them with the community.<br>
<br>
</span>Awesome, thanks!<br>
<br>
Having this in the Xen wiki would be awesome. If you would like write<br>
access to our wiki (which is granted manually due to spammers spoiling<br>
it for everyone...) then please:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * Create an account using the &quot;create account&quo=
t; link at the<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 top-right hand side of <a href=3D"http://wiki.x=
en.org/wiki/Main_Page" target=3D"_blank">http://wiki.xen.org/wiki/Main_Page=
</a><br>
=C2=A0 =C2=A0 =C2=A0 * Fill in this form giving your chosen username:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://xenproject.org/component/cont=
ent/article/100-misc/145-request-to-be-made-a-wiki-editor.html" target=3D"_=
blank">http://xenproject.org/component/content/article/100-misc/145-request=
-to-be-made-a-wiki-editor.html</a><br>
<br>
You could alternatively drop me a line privately with the user name for<br>
the second step, but filling in the form might give a quicker response<br>
time due to reaching multiple people in multiple timezones...<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><br></div>

--f46d043be0243fd31f0507ddec9e--


--===============3296379883063420395==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3296379883063420395==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 07:31:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 07:31:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqGmU-0007Ae-Nn; Mon, 17 Nov 2014 07:31:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqGmT-0007AZ-Ic
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 07:31:25 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	E6/1F-01660-C44A9645; Mon, 17 Nov 2014 07:31:24 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416209483!8347444!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22027 invoked from network); 17 Nov 2014 07:31:24 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-15.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 07:31:24 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 16 Nov 2014 23:24:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,401,1413270000"; d="scan'208";a="623431300"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by fmsmga001.fm.intel.com with ESMTP; 16 Nov 2014 23:31:20 -0800
Message-ID: <5469A448.40808@intel.com>
Date: Mon, 17 Nov 2014 15:31:20 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<546420CE.1080908@intel.com> <5465671C.4070007@intel.com>
	<5465C99F0200007800047829@mail.emea.novell.com>
In-Reply-To: <5465C99F0200007800047829@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/14 16:21, Jan Beulich wrote:
>>>> On 14.11.14 at 03:21, <tiejun.chen@intel.com> wrote:
>> Even if eventually we'll reorder that sequence, this just change that
>> approach to get BDF. Are you fine to this subsequent change?
>
> You again pass a struct domain pointer to the IOMMU-specific
> function. I already told you not to do so - the domain specific

I remembered this comment but I want to show this may introduce many 
duplicated codes. As I understand this kind of check should be a common 
thing dependent on one given platform.

> aspect should be taken care of by the callback function, i.e. you
> need to make SBDF available to it (just like you already properly
> did in the previous round for BDF). I suppose that'll at once make
> the ugly open coding of for_each_rmrr_device() unnecessary -
> you can just use that construct as replacement for what right
> now is list_for_each_entry().
>

Okay, I will try to go there.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 07:31:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 07:31:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqGmU-0007Ae-Nn; Mon, 17 Nov 2014 07:31:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqGmT-0007AZ-Ic
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 07:31:25 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	E6/1F-01660-C44A9645; Mon, 17 Nov 2014 07:31:24 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416209483!8347444!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22027 invoked from network); 17 Nov 2014 07:31:24 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-15.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 07:31:24 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 16 Nov 2014 23:24:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,401,1413270000"; d="scan'208";a="623431300"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by fmsmga001.fm.intel.com with ESMTP; 16 Nov 2014 23:31:20 -0800
Message-ID: <5469A448.40808@intel.com>
Date: Mon, 17 Nov 2014 15:31:20 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<546420CE.1080908@intel.com> <5465671C.4070007@intel.com>
	<5465C99F0200007800047829@mail.emea.novell.com>
In-Reply-To: <5465C99F0200007800047829@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/14 16:21, Jan Beulich wrote:
>>>> On 14.11.14 at 03:21, <tiejun.chen@intel.com> wrote:
>> Even if eventually we'll reorder that sequence, this just change that
>> approach to get BDF. Are you fine to this subsequent change?
>
> You again pass a struct domain pointer to the IOMMU-specific
> function. I already told you not to do so - the domain specific

I remembered this comment but I want to show this may introduce many 
duplicated codes. As I understand this kind of check should be a common 
thing dependent on one given platform.

> aspect should be taken care of by the callback function, i.e. you
> need to make SBDF available to it (just like you already properly
> did in the previous round for BDF). I suppose that'll at once make
> the ugly open coding of for_each_rmrr_device() unnecessary -
> you can just use that construct as replacement for what right
> now is list_for_each_entry().
>

Okay, I will try to go there.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 07:56:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 07:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqHAT-0007az-RD; Mon, 17 Nov 2014 07:56:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1XqHAS-0007au-Tj
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 07:56:13 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	8C/AC-27785-C1AA9645; Mon, 17 Nov 2014 07:56:12 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416210970!12955310!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3147 invoked from network); 17 Nov 2014 07:56:11 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-2.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 07:56:11 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 16 Nov 2014 23:53:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,401,1413270000"; d="scan'208";a="638107399"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga002.jf.intel.com with ESMTP; 16 Nov 2014 23:56:08 -0800
Received: from pgsmsx106.gar.corp.intel.com (10.221.44.98) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 17 Nov 2014 15:53:46 +0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 17 Nov 2014 15:53:46 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 15:53:44 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: "wei.liu2@citrix.com" <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the
	same device more than once
Thread-Index: AdACNky72y6xMRiETWKGh4z36whGWQ==
Date: Mon, 17 Nov 2014 07:53:44 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E44BE59@shsmsx102.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: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the same
 device more than once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Originally the code allowed users to attach the same device more than
> once. It just stupidly overwrites xenstore entries. This is bogus as
> frontend will be very confused.
>
> Introduce a helper function to check if the device to be written to
> xenstore already exists. A new error code is also introduced.
>
> The check and add are within one xs transaction.
>
> Signed-off-by: Wei Liu <wei....@citrix.com>
> ---

I find this patch will cause the pci-attach failed if more than one virtual function devices are attached to the guest.


>  @@ -148,15 +150,32 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc,
>  uint32_t domid, libxl_d
>       if (!starting)
>           flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 7));
>  
>  -retry_transaction:
>  -    t = xs_transaction_start(ctx->xsh);
>  -    libxl__xs_writev(gc, t, be_path,
>  -                    libxl__xs_kvs_of_flexarray(gc, back, back->count));
>  -    if (!xs_transaction_end(ctx->xsh, t, 0))
>  -        if (errno == EAGAIN)
>  -            goto retry_transaction;
>  +    GCNEW(device);
>  +    libxl__device_from_pcidev(gc, domid, pcidev, device);

>  -    return 0;
>  +    for (;;) {
>  +        rc = libxl__xs_transaction_start(gc, &t);
>  +        if (rc) goto out;
>  +
>  +        rc = libxl__device_exists(gc, t, device);
>  +        if (rc < 0) goto out;
>  +        if (rc == 1) {
>  +            LOG(ERROR, "device already exists in xenstore");
>  +            rc = ERROR_DEVICE_EXISTS;
>  +            goto out;
>  +        } 

The libxl__device_exists will return 1 if more than one PCI devices are attached to the guest, no matter the BDFs are identical or not.
I don't understand why to check this condition here, if the same device was attached more than once the xc_test_assign_device() will return error,
and the libxl__device_pci_add_xenstore() will not be called. It seems unnecessary.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 07:56:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 07:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqHAT-0007az-RD; Mon, 17 Nov 2014 07:56:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1XqHAS-0007au-Tj
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 07:56:13 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	8C/AC-27785-C1AA9645; Mon, 17 Nov 2014 07:56:12 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416210970!12955310!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3147 invoked from network); 17 Nov 2014 07:56:11 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-2.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 07:56:11 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 16 Nov 2014 23:53:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,401,1413270000"; d="scan'208";a="638107399"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga002.jf.intel.com with ESMTP; 16 Nov 2014 23:56:08 -0800
Received: from pgsmsx106.gar.corp.intel.com (10.221.44.98) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 17 Nov 2014 15:53:46 +0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 17 Nov 2014 15:53:46 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 15:53:44 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: "wei.liu2@citrix.com" <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the
	same device more than once
Thread-Index: AdACNky72y6xMRiETWKGh4z36whGWQ==
Date: Mon, 17 Nov 2014 07:53:44 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E44BE59@shsmsx102.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: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the same
 device more than once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Originally the code allowed users to attach the same device more than
> once. It just stupidly overwrites xenstore entries. This is bogus as
> frontend will be very confused.
>
> Introduce a helper function to check if the device to be written to
> xenstore already exists. A new error code is also introduced.
>
> The check and add are within one xs transaction.
>
> Signed-off-by: Wei Liu <wei....@citrix.com>
> ---

I find this patch will cause the pci-attach failed if more than one virtual function devices are attached to the guest.


>  @@ -148,15 +150,32 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc,
>  uint32_t domid, libxl_d
>       if (!starting)
>           flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 7));
>  
>  -retry_transaction:
>  -    t = xs_transaction_start(ctx->xsh);
>  -    libxl__xs_writev(gc, t, be_path,
>  -                    libxl__xs_kvs_of_flexarray(gc, back, back->count));
>  -    if (!xs_transaction_end(ctx->xsh, t, 0))
>  -        if (errno == EAGAIN)
>  -            goto retry_transaction;
>  +    GCNEW(device);
>  +    libxl__device_from_pcidev(gc, domid, pcidev, device);

>  -    return 0;
>  +    for (;;) {
>  +        rc = libxl__xs_transaction_start(gc, &t);
>  +        if (rc) goto out;
>  +
>  +        rc = libxl__device_exists(gc, t, device);
>  +        if (rc < 0) goto out;
>  +        if (rc == 1) {
>  +            LOG(ERROR, "device already exists in xenstore");
>  +            rc = ERROR_DEVICE_EXISTS;
>  +            goto out;
>  +        } 

The libxl__device_exists will return 1 if more than one PCI devices are attached to the guest, no matter the BDFs are identical or not.
I don't understand why to check this condition here, if the same device was attached more than once the xc_test_assign_device() will return error,
and the libxl__device_pci_add_xenstore() will not be called. It seems unnecessary.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 07:57:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 07:57:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqHC4-0007g6-Bs; Mon, 17 Nov 2014 07:57:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqHC2-0007fu-AS
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 07:57:50 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	4E/50-01660-C7AA9645; Mon, 17 Nov 2014 07:57:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416211066!6295468!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8036 invoked from network); 17 Nov 2014 07:57:47 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 07:57:47 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 16 Nov 2014 23:55:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,401,1413270000"; d="scan'208";a="608960324"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga001.jf.intel.com with ESMTP; 16 Nov 2014 23:57:43 -0800
Message-ID: <5469AA77.2070602@intel.com>
Date: Mon, 17 Nov 2014 15:57:43 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
In-Reply-To: <54632EA80200007800046AE5@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/12 16:55, Jan Beulich wrote:
>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>> I don't see any feedback to this point, so I think you still prefer we
>> should do all check in the callback function.
>
> As a draft this looks reasonable, but there are various bugs to be
> dealt with along with cosmetic issues (I'll point out the former, but
> I'm tired of pointing out the latter once again - please go back to
> earlier reviews of patches to refresh e.g. what types to use for
> loop variables).

'earlier reviews' means this subject email? I go back to check this but 
just see this comment related to our loop codes:

"
 >>> +        for ( i = 0; i < xdsr->num_pcidevs; ++i )
 >>> +        {
 >>> +            if ( __copy_from_guest_offset(pcidevs, xdsr->pcidevs, 
i, 1) )
 >>> +            {
 >>> +                xfree(pcidevs);
 >>> +                return -EFAULT;
 >>> +            }
 >>> +        }
 >>
 >> I don't see the need for a loop here. And you definitely can't use the
 >> double-underscore-prefixed variant the way you do.
 >
 > Do you mean this line?
 >
 > copy_from_guest_offset(pcidevs, xdsr->pcidevs, 0,
 > xdsr->num_pcidevs*sizeof(xen_guest_pcidev_info_t))

Almost:

     copy_from_guest(pcidevs, xdsr->pcidevs, xdsr->num_pcidevs * 
sizeof(*pcidevs))
"

Or I need to set as 'unsigned int' here?

Anyway I did this in the following codes firstly. If I'm still wrong I 
will correct that.

>
>> I tried to address this but obviously we have to pass each 'pdf' to
>> callback functions,
>
> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
> but something more neutral (maybe "id"). And you again lost the
> segment there.
>
>> @@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
>>            if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>>                return -ERANGE;
>>
>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> -                                     &rdm, 1) )
>> -            return -EFAULT;
>> +        if ( d->arch.hvm_domain.pci_force )
>> +        {
>> +            if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                         &rdm, 1) )
>> +                return -EFAULT;
>> +        }
>> +        else
>> +        {
>> +            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
>> +            {
>> +                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
>> +                                  d->arch.hvm_domain.pcidevs[i].devfn);
>> +                if ( pt_bdf == bdf )
>> +                    if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                                 &rdm, 1) )
>> +                        return -EFAULT;
>
> I think d->arch.hvm_domain.pcidevs[] shouldn't contain duplicates,
> and hence there's no point continuing the loop if you found a match.
>
>> +            }
>> +        }
>>        }
>>
>>        ++grdm->used_entries;
>
> This should no longer get incremented unconditionally.
>
>> @@ -314,6 +333,7 @@ int compat_memory_op(unsigned int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>                    return -EFAULT;
>>
>>                grdm.used_entries = 0;
>> +            grdm.domain = current->domain;
>>                rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
>>                                                      &grdm);
>>
>
> Maybe I misguided you with an earlier response, or maybe the
> earlier reply was in a different context: There's no point
> communicating current->domain to the callback function; there
> would be a point communicating the domain if it was _not_
> always current->domain.
>

So we need the caller to pass domain ID, right?

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index af613b9..314d7e6 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -22,10 +22,13 @@ struct get_reserved_device_memory {
      unsigned int used_entries;
  };

-static int get_reserved_device_memory(xen_pfn_t start,
-                                      xen_ulong_t nr, void *ctxt)
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, 
u16 seg,
+                                      u16 *ids, int cnt, void *ctxt)
  {
      struct get_reserved_device_memory *grdm = ctxt;
+    struct domain *d = get_domain_by_id(grdm->map.domid);
+    unsigned int i, j;
+    u32 sbdf, pt_sbdf;

      if ( grdm->used_entries < grdm->map.nr_entries )
      {
@@ -36,13 +39,37 @@ static int get_reserved_device_memory(xen_pfn_t start,
          if ( rdm.start_pfn != start || rdm.nr_pages != nr )
              return -ERANGE;

-        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
-                                     &rdm, 1) )
-            return -EFAULT;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( __copy_to_compat_offset(grdm->map.buffer, 
grdm->used_entries,
+                                         &rdm, 1) )
+                return -EFAULT;
+            ++grdm->used_entries;
+        }
+        else
+        {
+            for ( i = 0; i < cnt; i++ )
+            {
+                sbdf = PCI_SBDF(seg, ids[i]);
+                for ( j = 0; j < d->arch.hvm_domain.num_pcidevs; j++ )
+                {
+                    pt_sbdf = PCI_SBDF2(d->arch.hvm_domain.pcidevs[j].seg,
+                                        d->arch.hvm_domain.pcidevs[j].bus,
+ 
d->arch.hvm_domain.pcidevs[j].devfn);
+                    if ( pt_sbdf == sbdf )
+                    {
+                        if ( __copy_to_compat_offset(grdm->map.buffer,
+                                                     grdm->used_entries,
+                                                     &rdm, 1) )
+                            return -EFAULT;
+                        ++grdm->used_entries;
+                        break;
+                    }
+                }
+            }
+        }
      }

-    ++grdm->used_entries;
-
      return 0;
  }
  #endif
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 2177c56..f27b17f 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -698,10 +698,13 @@ struct get_reserved_device_memory {
      unsigned int used_entries;
  };

-static int get_reserved_device_memory(xen_pfn_t start,
-                                      xen_ulong_t nr, void *ctxt)
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, 
u16 seg,
+                                      u16 *ids, int cnt, void *ctxt)
  {
      struct get_reserved_device_memory *grdm = ctxt;
+    struct domain *d = get_domain_by_id(grdm->map.domid);
+    unsigned int i, j;
+    u32 sbdf, pt_sbdf;

      if ( grdm->used_entries < grdm->map.nr_entries )
      {
@@ -709,13 +712,37 @@ static int get_reserved_device_memory(xen_pfn_t start,
              .start_pfn = start, .nr_pages = nr
          };

-        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
-                                    &rdm, 1) )
-            return -EFAULT;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( __copy_to_guest_offset(grdm->map.buffer, 
grdm->used_entries,
+                                        &rdm, 1) )
+                return -EFAULT;
+            ++grdm->used_entries;
+        }
+        else
+        {
+            for ( i = 0; i < cnt; i++ )
+            {
+                sbdf = PCI_SBDF(seg, ids[i]);
+                for ( j = 0; j < d->arch.hvm_domain.num_pcidevs; j++ )
+                {
+                    pt_sbdf = PCI_SBDF2(d->arch.hvm_domain.pcidevs[j].seg,
+                                        d->arch.hvm_domain.pcidevs[j].bus,
+ 
d->arch.hvm_domain.pcidevs[j].devfn);
+                    if ( pt_sbdf == sbdf )
+                    {
+                        if ( __copy_to_guest_offset(grdm->map.buffer,
+                                                    grdm->used_entries,
+                                                    &rdm, 1) )
+                            return -EFAULT;
+                        ++grdm->used_entries;
+                        break;
+                    }
+                }
+            }
+        }
      }

-    ++grdm->used_entries;
-
      return 0;
  }
  #endif
diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 141e735..fa813c5 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -903,6 +903,9 @@ int 
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
      {
          rc = func(PFN_DOWN(rmrr->base_address),
                    PFN_UP(rmrr->end_address) - 
PFN_DOWN(rmrr->base_address),
+                  rmrr->segment,
+                  rmrr->scope.devices,
+                  rmrr->scope.devices_cnt,
                    ctxt);
          if ( rc )
              break;
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index f1b6a48..f8964e1 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -588,6 +588,11 @@ typedef struct xen_reserved_device_memory 
xen_reserved_device_memory_t;
  DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_t);

  struct xen_reserved_device_memory_map {
+    /*
+     * Domain whose reservation is being changed.
+     * Unprivileged domains can specify only DOMID_SELF.
+     */
+    domid_t        domid;
      /* IN/OUT */
      unsigned int nr_entries;
      /* OUT */
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 409f6f8..75c6759 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -120,7 +120,8 @@ void iommu_dt_domain_destroy(struct domain *d);

  struct page_info;

-typedef int iommu_grdm_t(xen_pfn_t start, xen_ulong_t nr, void *ctxt);
+typedef int iommu_grdm_t(xen_pfn_t start, xen_ulong_t nr, u16 seg, u16 
*ids,
+                         int cnt, void *ctxt);

  struct iommu_ops {
      int (*init)(struct domain *d);
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 91520bc..ba881ef 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -31,6 +31,8 @@
  #define PCI_DEVFN2(bdf) ((bdf) & 0xff)
  #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
  #define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))
+#define PCI_SBDF(s,bdf) (((s & 0xffff) << 16) | (bdf & 0xffff))
+#define PCI_SBDF2(s,b,df) (((s & 0xffff) << 16) | PCI_BDF2(b,df))

  struct pci_dev_info {
      bool_t is_extfn;

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 07:57:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 07:57:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqHC4-0007g6-Bs; Mon, 17 Nov 2014 07:57:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqHC2-0007fu-AS
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 07:57:50 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	4E/50-01660-C7AA9645; Mon, 17 Nov 2014 07:57:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416211066!6295468!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8036 invoked from network); 17 Nov 2014 07:57:47 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 07:57:47 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 16 Nov 2014 23:55:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,401,1413270000"; d="scan'208";a="608960324"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga001.jf.intel.com with ESMTP; 16 Nov 2014 23:57:43 -0800
Message-ID: <5469AA77.2070602@intel.com>
Date: Mon, 17 Nov 2014 15:57:43 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
In-Reply-To: <54632EA80200007800046AE5@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/12 16:55, Jan Beulich wrote:
>>>> On 12.11.14 at 04:05, <tiejun.chen@intel.com> wrote:
>> I don't see any feedback to this point, so I think you still prefer we
>> should do all check in the callback function.
>
> As a draft this looks reasonable, but there are various bugs to be
> dealt with along with cosmetic issues (I'll point out the former, but
> I'm tired of pointing out the latter once again - please go back to
> earlier reviews of patches to refresh e.g. what types to use for
> loop variables).

'earlier reviews' means this subject email? I go back to check this but 
just see this comment related to our loop codes:

"
 >>> +        for ( i = 0; i < xdsr->num_pcidevs; ++i )
 >>> +        {
 >>> +            if ( __copy_from_guest_offset(pcidevs, xdsr->pcidevs, 
i, 1) )
 >>> +            {
 >>> +                xfree(pcidevs);
 >>> +                return -EFAULT;
 >>> +            }
 >>> +        }
 >>
 >> I don't see the need for a loop here. And you definitely can't use the
 >> double-underscore-prefixed variant the way you do.
 >
 > Do you mean this line?
 >
 > copy_from_guest_offset(pcidevs, xdsr->pcidevs, 0,
 > xdsr->num_pcidevs*sizeof(xen_guest_pcidev_info_t))

Almost:

     copy_from_guest(pcidevs, xdsr->pcidevs, xdsr->num_pcidevs * 
sizeof(*pcidevs))
"

Or I need to set as 'unsigned int' here?

Anyway I did this in the following codes firstly. If I'm still wrong I 
will correct that.

>
>> I tried to address this but obviously we have to pass each 'pdf' to
>> callback functions,
>
> Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
> but something more neutral (maybe "id"). And you again lost the
> segment there.
>
>> @@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
>>            if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>>                return -ERANGE;
>>
>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> -                                     &rdm, 1) )
>> -            return -EFAULT;
>> +        if ( d->arch.hvm_domain.pci_force )
>> +        {
>> +            if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                         &rdm, 1) )
>> +                return -EFAULT;
>> +        }
>> +        else
>> +        {
>> +            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
>> +            {
>> +                pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
>> +                                  d->arch.hvm_domain.pcidevs[i].devfn);
>> +                if ( pt_bdf == bdf )
>> +                    if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> +                                                 &rdm, 1) )
>> +                        return -EFAULT;
>
> I think d->arch.hvm_domain.pcidevs[] shouldn't contain duplicates,
> and hence there's no point continuing the loop if you found a match.
>
>> +            }
>> +        }
>>        }
>>
>>        ++grdm->used_entries;
>
> This should no longer get incremented unconditionally.
>
>> @@ -314,6 +333,7 @@ int compat_memory_op(unsigned int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>                    return -EFAULT;
>>
>>                grdm.used_entries = 0;
>> +            grdm.domain = current->domain;
>>                rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
>>                                                      &grdm);
>>
>
> Maybe I misguided you with an earlier response, or maybe the
> earlier reply was in a different context: There's no point
> communicating current->domain to the callback function; there
> would be a point communicating the domain if it was _not_
> always current->domain.
>

So we need the caller to pass domain ID, right?

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index af613b9..314d7e6 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -22,10 +22,13 @@ struct get_reserved_device_memory {
      unsigned int used_entries;
  };

-static int get_reserved_device_memory(xen_pfn_t start,
-                                      xen_ulong_t nr, void *ctxt)
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, 
u16 seg,
+                                      u16 *ids, int cnt, void *ctxt)
  {
      struct get_reserved_device_memory *grdm = ctxt;
+    struct domain *d = get_domain_by_id(grdm->map.domid);
+    unsigned int i, j;
+    u32 sbdf, pt_sbdf;

      if ( grdm->used_entries < grdm->map.nr_entries )
      {
@@ -36,13 +39,37 @@ static int get_reserved_device_memory(xen_pfn_t start,
          if ( rdm.start_pfn != start || rdm.nr_pages != nr )
              return -ERANGE;

-        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
-                                     &rdm, 1) )
-            return -EFAULT;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( __copy_to_compat_offset(grdm->map.buffer, 
grdm->used_entries,
+                                         &rdm, 1) )
+                return -EFAULT;
+            ++grdm->used_entries;
+        }
+        else
+        {
+            for ( i = 0; i < cnt; i++ )
+            {
+                sbdf = PCI_SBDF(seg, ids[i]);
+                for ( j = 0; j < d->arch.hvm_domain.num_pcidevs; j++ )
+                {
+                    pt_sbdf = PCI_SBDF2(d->arch.hvm_domain.pcidevs[j].seg,
+                                        d->arch.hvm_domain.pcidevs[j].bus,
+ 
d->arch.hvm_domain.pcidevs[j].devfn);
+                    if ( pt_sbdf == sbdf )
+                    {
+                        if ( __copy_to_compat_offset(grdm->map.buffer,
+                                                     grdm->used_entries,
+                                                     &rdm, 1) )
+                            return -EFAULT;
+                        ++grdm->used_entries;
+                        break;
+                    }
+                }
+            }
+        }
      }

-    ++grdm->used_entries;
-
      return 0;
  }
  #endif
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 2177c56..f27b17f 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -698,10 +698,13 @@ struct get_reserved_device_memory {
      unsigned int used_entries;
  };

-static int get_reserved_device_memory(xen_pfn_t start,
-                                      xen_ulong_t nr, void *ctxt)
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, 
u16 seg,
+                                      u16 *ids, int cnt, void *ctxt)
  {
      struct get_reserved_device_memory *grdm = ctxt;
+    struct domain *d = get_domain_by_id(grdm->map.domid);
+    unsigned int i, j;
+    u32 sbdf, pt_sbdf;

      if ( grdm->used_entries < grdm->map.nr_entries )
      {
@@ -709,13 +712,37 @@ static int get_reserved_device_memory(xen_pfn_t start,
              .start_pfn = start, .nr_pages = nr
          };

-        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
-                                    &rdm, 1) )
-            return -EFAULT;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( __copy_to_guest_offset(grdm->map.buffer, 
grdm->used_entries,
+                                        &rdm, 1) )
+                return -EFAULT;
+            ++grdm->used_entries;
+        }
+        else
+        {
+            for ( i = 0; i < cnt; i++ )
+            {
+                sbdf = PCI_SBDF(seg, ids[i]);
+                for ( j = 0; j < d->arch.hvm_domain.num_pcidevs; j++ )
+                {
+                    pt_sbdf = PCI_SBDF2(d->arch.hvm_domain.pcidevs[j].seg,
+                                        d->arch.hvm_domain.pcidevs[j].bus,
+ 
d->arch.hvm_domain.pcidevs[j].devfn);
+                    if ( pt_sbdf == sbdf )
+                    {
+                        if ( __copy_to_guest_offset(grdm->map.buffer,
+                                                    grdm->used_entries,
+                                                    &rdm, 1) )
+                            return -EFAULT;
+                        ++grdm->used_entries;
+                        break;
+                    }
+                }
+            }
+        }
      }

-    ++grdm->used_entries;
-
      return 0;
  }
  #endif
diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 141e735..fa813c5 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -903,6 +903,9 @@ int 
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
      {
          rc = func(PFN_DOWN(rmrr->base_address),
                    PFN_UP(rmrr->end_address) - 
PFN_DOWN(rmrr->base_address),
+                  rmrr->segment,
+                  rmrr->scope.devices,
+                  rmrr->scope.devices_cnt,
                    ctxt);
          if ( rc )
              break;
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index f1b6a48..f8964e1 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -588,6 +588,11 @@ typedef struct xen_reserved_device_memory 
xen_reserved_device_memory_t;
  DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_t);

  struct xen_reserved_device_memory_map {
+    /*
+     * Domain whose reservation is being changed.
+     * Unprivileged domains can specify only DOMID_SELF.
+     */
+    domid_t        domid;
      /* IN/OUT */
      unsigned int nr_entries;
      /* OUT */
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 409f6f8..75c6759 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -120,7 +120,8 @@ void iommu_dt_domain_destroy(struct domain *d);

  struct page_info;

-typedef int iommu_grdm_t(xen_pfn_t start, xen_ulong_t nr, void *ctxt);
+typedef int iommu_grdm_t(xen_pfn_t start, xen_ulong_t nr, u16 seg, u16 
*ids,
+                         int cnt, void *ctxt);

  struct iommu_ops {
      int (*init)(struct domain *d);
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 91520bc..ba881ef 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -31,6 +31,8 @@
  #define PCI_DEVFN2(bdf) ((bdf) & 0xff)
  #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
  #define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))
+#define PCI_SBDF(s,bdf) (((s & 0xffff) << 16) | (bdf & 0xffff))
+#define PCI_SBDF2(s,b,df) (((s & 0xffff) << 16) | PCI_BDF2(b,df))

  struct pci_dev_info {
      bool_t is_extfn;

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 08:49:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 08:49:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqHzE-0000F4-Kn; Mon, 17 Nov 2014 08:48:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqHzD-0000Ez-Tq
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 08:48:40 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	01/CB-25547-666B9645; Mon, 17 Nov 2014 08:48:38 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416214116!11683826!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2249 invoked from network); 17 Nov 2014 08:48:37 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-31.messagelabs.com with SMTP;
	17 Nov 2014 08:48:37 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 17 Nov 2014 00:46:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,401,1413270000"; d="scan'208";a="638128576"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga002.jf.intel.com with ESMTP; 17 Nov 2014 00:48:33 -0800
Message-ID: <5469B660.6040107@intel.com>
Date: Mon, 17 Nov 2014 16:48:32 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>	<20141105140906.GA4912@redhat.com>
	<546961DC.4040300@intel.com> <20141117061010.GB19718@redhat.com>
In-Reply-To: <20141117061010.GB19718@redhat.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/17 14:10, Michael S. Tsirkin wrote:
> On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
>> On 2014/11/5 22:09, Michael S. Tsirkin wrote:
>>> On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
>>>> Currently IGD drivers always need to access PCH by 1f.0, and
>>>> PCH vendor/device id is used to identify the card.
>>>>
>>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>>> ---
>>>>   hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
>>>>   1 file changed, 27 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>>>> index b559181..b19c7a9 100644
>>>> --- a/hw/i386/pc_piix.c
>>>> +++ b/hw/i386/pc_piix.c
>>>> @@ -50,7 +50,7 @@
>>>>   #include "cpu.h"
>>>>   #include "qemu/error-report.h"
>>>>   #ifdef CONFIG_XEN
>>>> -#  include <xen/hvm/hvm_info_table.h>
>>>> +#include <xen/hvm/hvm_info_table.h>
>>>>   #endif
>>>>
>>>>   #define MAX_IDE_BUS 2
>>>> @@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
>>>>   }
>>>>
>>>>   #ifdef CONFIG_XEN
>>>> +static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
>>>> +{
>>>> +    struct PCIDevice *dev;
>>>> +    Error *local_err = NULL;
>>>> +    uint16_t device_id = 0xffff;
>>>> +
>>>> +    /* Currently IGD drivers always need to access PCH by 1f.0. */
>>>> +    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
>>>> +                            "xen-igd-passthrough-isa-bridge");
>>>> +
>>>> +    /* Identify PCH card with its own real vendor/device ids.
>>>> +     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
>>>> +     */
>>>> +    if (dev) {
>>>> +        device_id = object_property_get_int(OBJECT(dev), "device-id",
>>>> +                                            &local_err);
>>>> +        if (!local_err && device_id != 0xffff) {
>>>> +            pci_config_set_device_id(dev->config, device_id);
>>>> +            return;
>>>> +        }
>>>> +    }
>>>> +
>>>> +    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
>>>> +}
>>>> +
>>>>   static void pc_xen_hvm_init(MachineState *machine)
>>>>   {
>>>>       PCIBus *bus;
>>>> @@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
>>>>       bus = pci_find_primary_bus();
>>>>       if (bus != NULL) {
>>>>           pci_create_simple(bus, -1, "xen-platform");
>>>> +        xen_igd_passthrough_isa_bridge_create(bus);
>>>>       }
>>>>   }
>>>>   #endif
>>>
>>> Can't we defer this step until the GPU is added?
>>
>> Sounds great but I can't figure out where we can to do this exactly.
>>
>>> This way there won't be need to poke at host device
>>> directly, you could get all info from dev->config
>>> of the host device.
>>
>> As I understand We have two steps here:
>>
>> #1 At first I have to write something to check if we're registering 00:02.0
>> & IGD, right? But where? While registering each pci device?
>
> In xen_pt_initfn.
> Just check the device and vendor ID against the table you have.
>

Okay. Please see the follows which is just compiled:

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index c6466dc..f3ea313 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -632,6 +632,94 @@ static const MemoryListener xen_pt_io_listener = {
      .priority = 10,
  };

+typedef struct {
+    uint16_t gpu_device_id;
+    uint16_t pch_device_id;
+} XenIGDDeviceIDInfo;
+
+/* In real world different GPU should have different PCH. But actually
+ * the different PCH DIDs likely map to different PCH SKUs. We do the
+ * same thing for the GPU. For PCH, the different SKUs are going to be
+ * all the same silicon design and implementation, just different
+ * features turn on and off with fuses. The SW interfaces should be
+ * consistent across all SKUs in a given family (eg LPT). But just same
+ * features may not be supported.
+ *
+ * Most of these different PCH features probably don't matter to the
+ * Gfx driver, but obviously any difference in display port connections
+ * will so it should be fine with any PCH in case of passthrough.
+ *
+ * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
+ * scenarios, 0x9cc3 for BDW(Broadwell).
+ */
+static const XenIGDDeviceIDInfo xen_igd_combo_id_infos[] = {
+    /* HSW Classic */
+    {0x0402, 0x8c4e}, /* HSWGT1D, HSWD_w7 */
+    {0x0406, 0x8c4e}, /* HSWGT1M, HSWM_w7 */
+    {0x0412, 0x8c4e}, /* HSWGT2D, HSWD_w7 */
+    {0x0416, 0x8c4e}, /* HSWGT2M, HSWM_w7 */
+    {0x041E, 0x8c4e}, /* HSWGT15D, HSWD_w7 */
+    /* HSW ULT */
+    {0x0A06, 0x8c4e}, /* HSWGT1UT, HSWM_w7 */
+    {0x0A16, 0x8c4e}, /* HSWGT2UT, HSWM_w7 */
+    {0x0A26, 0x8c4e}, /* HSWGT3UT, HSWM_w7 */
+    {0x0A2E, 0x8c4e}, /* HSWGT3UT28W, HSWM_w7 */
+    {0x0A1E, 0x8c4e}, /* HSWGT2UX, HSWM_w7 */
+    {0x0A0E, 0x8c4e}, /* HSWGT1ULX, HSWM_w7 */
+    /* HSW CRW */
+    {0x0D26, 0x8c4e}, /* HSWGT3CW, HSWM_w7 */
+    {0x0D22, 0x8c4e}, /* HSWGT3CWDT, HSWD_w7 */
+    /* HSW Server */
+    {0x041A, 0x8c4e}, /* HSWSVGT2, HSWD_w7 */
+    /* HSW SRVR */
+    {0x040A, 0x8c4e}, /* HSWSVGT1, HSWD_w7 */
+    /* BSW */
+    {0x1606, 0x9cc3}, /* BDWULTGT1, BDWM_w7 */
+    {0x1616, 0x9cc3}, /* BDWULTGT2, BDWM_w7 */
+    {0x1626, 0x9cc3}, /* BDWULTGT3, BDWM_w7 */
+    {0x160E, 0x9cc3}, /* BDWULXGT1, BDWM_w7 */
+    {0x161E, 0x9cc3}, /* BDWULXGT2, BDWM_w7 */
+    {0x1602, 0x9cc3}, /* BDWHALOGT1, BDWM_w7 */
+    {0x1612, 0x9cc3}, /* BDWHALOGT2, BDWM_w7 */
+    {0x1622, 0x9cc3}, /* BDWHALOGT3, BDWM_w7 */
+    {0x162B, 0x9cc3}, /* BDWHALO28W, BDWM_w7 */
+    {0x162A, 0x9cc3}, /* BDWGT3WRKS, BDWM_w7 */
+    {0x162D, 0x9cc3}, /* BDWGT3SRVR, BDWM_w7 */
+};
+
+static void
+xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
+                                      XenHostPCIDevice *dev)
+{
+    struct PCIDevice *pci_dev;
+    int i, num;
+    uint16_t gpu_id = 0xffff, pch_id = 0xffff;
+    PCIDevice *d = &s->dev;
+
+    if (is_vga_passthrough(dev)) {
+        gpu_id = dev->device_id;
+        num = ARRAY_SIZE(xen_igd_combo_id_infos);
+        for (i = 0; i < num; i++)
+            if (gpu_id == xen_igd_combo_id_infos[i].gpu_device_id)
+                pch_id = xen_igd_combo_id_infos[i].pch_device_id;
+
+        /* Currently IGD drivers always need to access PCH by 1f.0. */
+        pci_dev = pci_create_simple(d->bus, PCI_DEVFN(0x1f, 0),
+                                    "xen-igd-passthrough-isa-bridge");
+
+        /*
+         * Identify PCH card with its own real vendor/device ids.
+         * Here that vendor id is always PCI_VENDOR_ID_INTEL.
+         */
+        if (pci_dev) {
+            pci_config_set_device_id(pci_dev->config, pch_id);
+            return;
+        }
+
+        fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge 
failed!\n");
+    }
+}
+
  /* init */

  static int xen_pt_initfn(PCIDevice *d)
@@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
          return -1;
      }

+    /* Register ISA bridge for passthrough GFX. */
+    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
+
      /* reinitialize each config register to be emulated */
      if (xen_pt_config_init(s)) {
          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");

Note I will introduce a inline function in another patch,

+static inline int is_vga_passthrough(XenHostPCIDevice *dev)
+{
+    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
+            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
+}

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 08:49:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 08:49:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqHzE-0000F4-Kn; Mon, 17 Nov 2014 08:48:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqHzD-0000Ez-Tq
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 08:48:40 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	01/CB-25547-666B9645; Mon, 17 Nov 2014 08:48:38 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416214116!11683826!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2249 invoked from network); 17 Nov 2014 08:48:37 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-31.messagelabs.com with SMTP;
	17 Nov 2014 08:48:37 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 17 Nov 2014 00:46:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,401,1413270000"; d="scan'208";a="638128576"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga002.jf.intel.com with ESMTP; 17 Nov 2014 00:48:33 -0800
Message-ID: <5469B660.6040107@intel.com>
Date: Mon, 17 Nov 2014 16:48:32 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>	<20141105140906.GA4912@redhat.com>
	<546961DC.4040300@intel.com> <20141117061010.GB19718@redhat.com>
In-Reply-To: <20141117061010.GB19718@redhat.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/17 14:10, Michael S. Tsirkin wrote:
> On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
>> On 2014/11/5 22:09, Michael S. Tsirkin wrote:
>>> On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
>>>> Currently IGD drivers always need to access PCH by 1f.0, and
>>>> PCH vendor/device id is used to identify the card.
>>>>
>>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>>> ---
>>>>   hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
>>>>   1 file changed, 27 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>>>> index b559181..b19c7a9 100644
>>>> --- a/hw/i386/pc_piix.c
>>>> +++ b/hw/i386/pc_piix.c
>>>> @@ -50,7 +50,7 @@
>>>>   #include "cpu.h"
>>>>   #include "qemu/error-report.h"
>>>>   #ifdef CONFIG_XEN
>>>> -#  include <xen/hvm/hvm_info_table.h>
>>>> +#include <xen/hvm/hvm_info_table.h>
>>>>   #endif
>>>>
>>>>   #define MAX_IDE_BUS 2
>>>> @@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
>>>>   }
>>>>
>>>>   #ifdef CONFIG_XEN
>>>> +static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
>>>> +{
>>>> +    struct PCIDevice *dev;
>>>> +    Error *local_err = NULL;
>>>> +    uint16_t device_id = 0xffff;
>>>> +
>>>> +    /* Currently IGD drivers always need to access PCH by 1f.0. */
>>>> +    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
>>>> +                            "xen-igd-passthrough-isa-bridge");
>>>> +
>>>> +    /* Identify PCH card with its own real vendor/device ids.
>>>> +     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
>>>> +     */
>>>> +    if (dev) {
>>>> +        device_id = object_property_get_int(OBJECT(dev), "device-id",
>>>> +                                            &local_err);
>>>> +        if (!local_err && device_id != 0xffff) {
>>>> +            pci_config_set_device_id(dev->config, device_id);
>>>> +            return;
>>>> +        }
>>>> +    }
>>>> +
>>>> +    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
>>>> +}
>>>> +
>>>>   static void pc_xen_hvm_init(MachineState *machine)
>>>>   {
>>>>       PCIBus *bus;
>>>> @@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
>>>>       bus = pci_find_primary_bus();
>>>>       if (bus != NULL) {
>>>>           pci_create_simple(bus, -1, "xen-platform");
>>>> +        xen_igd_passthrough_isa_bridge_create(bus);
>>>>       }
>>>>   }
>>>>   #endif
>>>
>>> Can't we defer this step until the GPU is added?
>>
>> Sounds great but I can't figure out where we can to do this exactly.
>>
>>> This way there won't be need to poke at host device
>>> directly, you could get all info from dev->config
>>> of the host device.
>>
>> As I understand We have two steps here:
>>
>> #1 At first I have to write something to check if we're registering 00:02.0
>> & IGD, right? But where? While registering each pci device?
>
> In xen_pt_initfn.
> Just check the device and vendor ID against the table you have.
>

Okay. Please see the follows which is just compiled:

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index c6466dc..f3ea313 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -632,6 +632,94 @@ static const MemoryListener xen_pt_io_listener = {
      .priority = 10,
  };

+typedef struct {
+    uint16_t gpu_device_id;
+    uint16_t pch_device_id;
+} XenIGDDeviceIDInfo;
+
+/* In real world different GPU should have different PCH. But actually
+ * the different PCH DIDs likely map to different PCH SKUs. We do the
+ * same thing for the GPU. For PCH, the different SKUs are going to be
+ * all the same silicon design and implementation, just different
+ * features turn on and off with fuses. The SW interfaces should be
+ * consistent across all SKUs in a given family (eg LPT). But just same
+ * features may not be supported.
+ *
+ * Most of these different PCH features probably don't matter to the
+ * Gfx driver, but obviously any difference in display port connections
+ * will so it should be fine with any PCH in case of passthrough.
+ *
+ * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
+ * scenarios, 0x9cc3 for BDW(Broadwell).
+ */
+static const XenIGDDeviceIDInfo xen_igd_combo_id_infos[] = {
+    /* HSW Classic */
+    {0x0402, 0x8c4e}, /* HSWGT1D, HSWD_w7 */
+    {0x0406, 0x8c4e}, /* HSWGT1M, HSWM_w7 */
+    {0x0412, 0x8c4e}, /* HSWGT2D, HSWD_w7 */
+    {0x0416, 0x8c4e}, /* HSWGT2M, HSWM_w7 */
+    {0x041E, 0x8c4e}, /* HSWGT15D, HSWD_w7 */
+    /* HSW ULT */
+    {0x0A06, 0x8c4e}, /* HSWGT1UT, HSWM_w7 */
+    {0x0A16, 0x8c4e}, /* HSWGT2UT, HSWM_w7 */
+    {0x0A26, 0x8c4e}, /* HSWGT3UT, HSWM_w7 */
+    {0x0A2E, 0x8c4e}, /* HSWGT3UT28W, HSWM_w7 */
+    {0x0A1E, 0x8c4e}, /* HSWGT2UX, HSWM_w7 */
+    {0x0A0E, 0x8c4e}, /* HSWGT1ULX, HSWM_w7 */
+    /* HSW CRW */
+    {0x0D26, 0x8c4e}, /* HSWGT3CW, HSWM_w7 */
+    {0x0D22, 0x8c4e}, /* HSWGT3CWDT, HSWD_w7 */
+    /* HSW Server */
+    {0x041A, 0x8c4e}, /* HSWSVGT2, HSWD_w7 */
+    /* HSW SRVR */
+    {0x040A, 0x8c4e}, /* HSWSVGT1, HSWD_w7 */
+    /* BSW */
+    {0x1606, 0x9cc3}, /* BDWULTGT1, BDWM_w7 */
+    {0x1616, 0x9cc3}, /* BDWULTGT2, BDWM_w7 */
+    {0x1626, 0x9cc3}, /* BDWULTGT3, BDWM_w7 */
+    {0x160E, 0x9cc3}, /* BDWULXGT1, BDWM_w7 */
+    {0x161E, 0x9cc3}, /* BDWULXGT2, BDWM_w7 */
+    {0x1602, 0x9cc3}, /* BDWHALOGT1, BDWM_w7 */
+    {0x1612, 0x9cc3}, /* BDWHALOGT2, BDWM_w7 */
+    {0x1622, 0x9cc3}, /* BDWHALOGT3, BDWM_w7 */
+    {0x162B, 0x9cc3}, /* BDWHALO28W, BDWM_w7 */
+    {0x162A, 0x9cc3}, /* BDWGT3WRKS, BDWM_w7 */
+    {0x162D, 0x9cc3}, /* BDWGT3SRVR, BDWM_w7 */
+};
+
+static void
+xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
+                                      XenHostPCIDevice *dev)
+{
+    struct PCIDevice *pci_dev;
+    int i, num;
+    uint16_t gpu_id = 0xffff, pch_id = 0xffff;
+    PCIDevice *d = &s->dev;
+
+    if (is_vga_passthrough(dev)) {
+        gpu_id = dev->device_id;
+        num = ARRAY_SIZE(xen_igd_combo_id_infos);
+        for (i = 0; i < num; i++)
+            if (gpu_id == xen_igd_combo_id_infos[i].gpu_device_id)
+                pch_id = xen_igd_combo_id_infos[i].pch_device_id;
+
+        /* Currently IGD drivers always need to access PCH by 1f.0. */
+        pci_dev = pci_create_simple(d->bus, PCI_DEVFN(0x1f, 0),
+                                    "xen-igd-passthrough-isa-bridge");
+
+        /*
+         * Identify PCH card with its own real vendor/device ids.
+         * Here that vendor id is always PCI_VENDOR_ID_INTEL.
+         */
+        if (pci_dev) {
+            pci_config_set_device_id(pci_dev->config, pch_id);
+            return;
+        }
+
+        fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge 
failed!\n");
+    }
+}
+
  /* init */

  static int xen_pt_initfn(PCIDevice *d)
@@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
          return -1;
      }

+    /* Register ISA bridge for passthrough GFX. */
+    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
+
      /* reinitialize each config register to be emulated */
      if (xen_pt_config_init(s)) {
          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");

Note I will introduce a inline function in another patch,

+static inline int is_vga_passthrough(XenHostPCIDevice *dev)
+{
+    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
+            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
+}

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:03:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIDF-0000a1-Ba; Mon, 17 Nov 2014 09:03:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqIDE-0000Zw-36
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 09:03:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1C/09-09936-BC9B9645; Mon, 17 Nov 2014 09:03:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416214985!13254860!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13782 invoked from network); 17 Nov 2014 09:03:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:03:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,401,1413244800"; d="scan'208";a="191967294"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 04:02:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqICw-0004CM-0l;
	Mon, 17 Nov 2014 09:02:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqICv-0004OR-SS;
	Mon, 17 Nov 2014 09:02:49 +0000
Date: Mon, 17 Nov 2014 09:02:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31626-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31626: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31626 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31626/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 30846 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 Nov 17 09:03:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIDF-0000a1-Ba; Mon, 17 Nov 2014 09:03:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqIDE-0000Zw-36
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 09:03:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1C/09-09936-BC9B9645; Mon, 17 Nov 2014 09:03:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416214985!13254860!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13782 invoked from network); 17 Nov 2014 09:03:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:03:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,401,1413244800"; d="scan'208";a="191967294"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 04:02:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqICw-0004CM-0l;
	Mon, 17 Nov 2014 09:02:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqICv-0004OR-SS;
	Mon, 17 Nov 2014 09:02:49 +0000
Date: Mon, 17 Nov 2014 09:02:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31626-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31626: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31626 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31626/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 30846 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 Nov 17 09:15:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09: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.xen.org>)
	id 1XqIOs-0000nk-JH; Mon, 17 Nov 2014 09:15:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqIOr-0000nf-A5
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:15:09 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	EB/FC-27623-C9CB9645; Mon, 17 Nov 2014 09:15:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416215706!11847317!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7134 invoked from network); 17 Nov 2014 09:15:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:15:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,401,1413244800"; d="scan'208";a="191969702"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 04:15:06 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqI8m-0006De-48;
	Mon, 17 Nov 2014 08:58:32 +0000
Date: Mon, 17 Nov 2014 08:58:31 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141117085831.GC11070@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
	<1415962372.7113.2.camel@citrix.com>
	<1415962535.7113.4.camel@citrix.com>
	<20141114111051.GC31422@zion.uk.xensource.com>
	<1415963996.7113.11.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415963996.7113.11.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, zhigang.x.wang@oracle.com,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
 ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 11:19:56AM +0000, Ian Campbell wrote:
> On Fri, 2014-11-14 at 11:10 +0000, Wei Liu wrote:
> > On Fri, Nov 14, 2014 at 10:55:35AM +0000, Ian Campbell wrote:
> > > On Fri, 2014-11-14 at 10:52 +0000, Ian Campbell wrote:
> > > > On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > > > > Continue when libxl_retrieve_domain_configuration encounters
> > > > > ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
> > > > > configuration pulled from xenstore.  In this case
> > > > > ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
> > > > > error happens along the way.
> > > > > 
> > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> > > > 
> > > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > On second thoughts, I think this really needs an update to libxl.h to
> > > describe the semantics of this function, i.e. to what extent the output
> > > is valid for various error codes, especially ERROR_JSON_CONFIG_EMPTY.
> > > 
> > 
> > Any non-zero return code means the output is invalid (as in "Is this
> > output valid to rebuild a domain?").
> 
> But your second patch prints it as if it is at least somewhat
> meaningful, if not entirely valid. According to what you just said it
> shouldn't do so.
> 
> You effectively have three return states now: Fully valid, domain exists
> but it's configuration is unsure or somehow incomplete (~= JSON EMPTY),
> some sort of error occurred.
> 
> It might even be a good idea to have some new externally visible error
> code for the middle state, since JSON_EMPTY may not be the only reason
> for being in that state (at least in theory).
> 
> Anyway, since this is all more subtle than the existing 0 is good,
> non-zero is completely bad it should be written down.
> 

I'm not very keen on rushing to get ERROR_JSON_CONFIG_EMPTY special
meaning at this point of a release. I think we can deal with this in
next release.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:15:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09: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.xen.org>)
	id 1XqIOs-0000nk-JH; Mon, 17 Nov 2014 09:15:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqIOr-0000nf-A5
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:15:09 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	EB/FC-27623-C9CB9645; Mon, 17 Nov 2014 09:15:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416215706!11847317!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7134 invoked from network); 17 Nov 2014 09:15:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:15:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,401,1413244800"; d="scan'208";a="191969702"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 04:15:06 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqI8m-0006De-48;
	Mon, 17 Nov 2014 08:58:32 +0000
Date: Mon, 17 Nov 2014 08:58:31 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141117085831.GC11070@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-2-git-send-email-wei.liu2@citrix.com>
	<1415962372.7113.2.camel@citrix.com>
	<1415962535.7113.4.camel@citrix.com>
	<20141114111051.GC31422@zion.uk.xensource.com>
	<1415963996.7113.11.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415963996.7113.11.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, zhigang.x.wang@oracle.com,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 1/2] libxl: continue when encounter
 ERROR_JSON_CONFIG_EMPTY
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 11:19:56AM +0000, Ian Campbell wrote:
> On Fri, 2014-11-14 at 11:10 +0000, Wei Liu wrote:
> > On Fri, Nov 14, 2014 at 10:55:35AM +0000, Ian Campbell wrote:
> > > On Fri, 2014-11-14 at 10:52 +0000, Ian Campbell wrote:
> > > > On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > > > > Continue when libxl_retrieve_domain_configuration encounters
> > > > > ERROR_JSON_CONFIG_EMPTY, as caller might be interested in the partial
> > > > > configuration pulled from xenstore.  In this case
> > > > > ERROR_JSON_CONFIG_EMPTY is used as return value as before, if no other
> > > > > error happens along the way.
> > > > > 
> > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > > Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
> > > > 
> > > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > On second thoughts, I think this really needs an update to libxl.h to
> > > describe the semantics of this function, i.e. to what extent the output
> > > is valid for various error codes, especially ERROR_JSON_CONFIG_EMPTY.
> > > 
> > 
> > Any non-zero return code means the output is invalid (as in "Is this
> > output valid to rebuild a domain?").
> 
> But your second patch prints it as if it is at least somewhat
> meaningful, if not entirely valid. According to what you just said it
> shouldn't do so.
> 
> You effectively have three return states now: Fully valid, domain exists
> but it's configuration is unsure or somehow incomplete (~= JSON EMPTY),
> some sort of error occurred.
> 
> It might even be a good idea to have some new externally visible error
> code for the middle state, since JSON_EMPTY may not be the only reason
> for being in that state (at least in theory).
> 
> Anyway, since this is all more subtle than the existing 0 is good,
> non-zero is completely bad it should be written down.
> 

I'm not very keen on rushing to get ERROR_JSON_CONFIG_EMPTY special
meaning at this point of a release. I think we can deal with this in
next release.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:17:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIRK-0000u0-4I; Mon, 17 Nov 2014 09:17:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqIRI-0000tt-H1
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:17:40 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	15/81-27623-33DB9645; Mon, 17 Nov 2014 09:17:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416215857!11692372!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21653 invoked from network); 17 Nov 2014 09:17:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:17:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,401,1413244800"; d="scan'208";a="191970302"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 04:16:59 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqIQd-0006iX-2p;
	Mon, 17 Nov 2014 09:16:59 +0000
Date: Mon, 17 Nov 2014 09:16:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141117091658.GD11070@zion.uk.xensource.com>
References: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxc: don't leak buffer containing
 the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 12:08:33PM +0000, Ian Campbell wrote:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> up leaked.
> 
> The memory pool currently supports mmap'd buffers as well as a directly
> allocated buffers, however the try decode routines make use of realloc and do
> not fit well into this model. Introduce a concept of an external memory block
> to the memory pool and provide an interface to register such memory.
> 
> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> mmap_ prefix since they are now also used for external memory blocks.
> 
> We are only seeing this now because the gzip decoder doesn't leak and it's only
> relatively recently that kernels in the wild have switched to better
> compression.
> 
> This is https://bugs.debian.org/767295
> 
> Reported by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> This is a bug fix and should go into 4.5.
> 
> I have a sneaking suspicion this is going to need to backport a very long way...
> ---
>  tools/libxc/include/xc_dom.h        |   10 ++++--
>  tools/libxc/xc_dom_bzimageloader.c  |   18 +++++++++++
>  tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
>  tools/libxc/xc_dom_decompress_lz4.c |    5 +++
>  4 files changed, 78 insertions(+), 16 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6ae6a9f..07d7224 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -33,8 +33,13 @@ struct xc_dom_seg {
>  
>  struct xc_dom_mem {
>      struct xc_dom_mem *next;
> -    void *mmap_ptr;
> -    size_t mmap_len;
> +    void *ptr;
> +    enum {
> +        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
> +        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
> +        XC_DOM_MEM_TYPE_MMAP,
> +    } type;
> +    size_t len;
>      unsigned char memory[0];
>  };
>  
> @@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
>  /* --- simple memory pool ------------------------------------------ */
>  
>  void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
>  void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>                              const char *filename, size_t * size,
> diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
> index 2225699..991a07b 100644
> --- a/tools/libxc/xc_dom_bzimageloader.c
> +++ b/tools/libxc/xc_dom_bzimageloader.c
> @@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
>  
>      total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
>  
> +    if ( xc_dom_register_external(dom, out_buf, total) )
> +    {
> +        DOMPRINTF("BZIP2: Error registering stream output");
> +        free(out_buf);
> +        goto bzip2_cleanup;
> +    }
> +
>      DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
>                __FUNCTION__, *size, (long unsigned int) total);
>  
> @@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
>          }
>      }
>  
> +    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
> +    {
> +        DOMPRINTF("%s: Error registering stream output", what);
> +        free(out_buf);
> +        goto lzma_cleanup;
> +    }
> +
>      DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
>                __FUNCTION__, what, *size, (size_t)stream->total_out);
>  
> @@ -508,6 +522,10 @@ static int xc_try_lzo1x_decode(
>              if ( out_len != dst_len )
>                  break;
>  
> +            msg = "Error registering stream output";
> +            if ( xc_dom_register_external(dom, out_buf, out_len) )
> +                break;
> +

Is this hunk problematic?

It's called in a loop. Looks like it may register the same ptr multiple
times which leads to freeing same ptr multiple times later.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:17:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIRK-0000u0-4I; Mon, 17 Nov 2014 09:17:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqIRI-0000tt-H1
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:17:40 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	15/81-27623-33DB9645; Mon, 17 Nov 2014 09:17:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416215857!11692372!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21653 invoked from network); 17 Nov 2014 09:17:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:17:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,401,1413244800"; d="scan'208";a="191970302"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 04:16:59 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqIQd-0006iX-2p;
	Mon, 17 Nov 2014 09:16:59 +0000
Date: Mon, 17 Nov 2014 09:16:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141117091658.GD11070@zion.uk.xensource.com>
References: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxc: don't leak buffer containing
 the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 10, 2014 at 12:08:33PM +0000, Ian Campbell wrote:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> up leaked.
> 
> The memory pool currently supports mmap'd buffers as well as a directly
> allocated buffers, however the try decode routines make use of realloc and do
> not fit well into this model. Introduce a concept of an external memory block
> to the memory pool and provide an interface to register such memory.
> 
> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> mmap_ prefix since they are now also used for external memory blocks.
> 
> We are only seeing this now because the gzip decoder doesn't leak and it's only
> relatively recently that kernels in the wild have switched to better
> compression.
> 
> This is https://bugs.debian.org/767295
> 
> Reported by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> This is a bug fix and should go into 4.5.
> 
> I have a sneaking suspicion this is going to need to backport a very long way...
> ---
>  tools/libxc/include/xc_dom.h        |   10 ++++--
>  tools/libxc/xc_dom_bzimageloader.c  |   18 +++++++++++
>  tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
>  tools/libxc/xc_dom_decompress_lz4.c |    5 +++
>  4 files changed, 78 insertions(+), 16 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6ae6a9f..07d7224 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -33,8 +33,13 @@ struct xc_dom_seg {
>  
>  struct xc_dom_mem {
>      struct xc_dom_mem *next;
> -    void *mmap_ptr;
> -    size_t mmap_len;
> +    void *ptr;
> +    enum {
> +        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
> +        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
> +        XC_DOM_MEM_TYPE_MMAP,
> +    } type;
> +    size_t len;
>      unsigned char memory[0];
>  };
>  
> @@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
>  /* --- simple memory pool ------------------------------------------ */
>  
>  void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
>  void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>                              const char *filename, size_t * size,
> diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
> index 2225699..991a07b 100644
> --- a/tools/libxc/xc_dom_bzimageloader.c
> +++ b/tools/libxc/xc_dom_bzimageloader.c
> @@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
>  
>      total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
>  
> +    if ( xc_dom_register_external(dom, out_buf, total) )
> +    {
> +        DOMPRINTF("BZIP2: Error registering stream output");
> +        free(out_buf);
> +        goto bzip2_cleanup;
> +    }
> +
>      DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
>                __FUNCTION__, *size, (long unsigned int) total);
>  
> @@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
>          }
>      }
>  
> +    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
> +    {
> +        DOMPRINTF("%s: Error registering stream output", what);
> +        free(out_buf);
> +        goto lzma_cleanup;
> +    }
> +
>      DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
>                __FUNCTION__, what, *size, (size_t)stream->total_out);
>  
> @@ -508,6 +522,10 @@ static int xc_try_lzo1x_decode(
>              if ( out_len != dst_len )
>                  break;
>  
> +            msg = "Error registering stream output";
> +            if ( xc_dom_register_external(dom, out_buf, out_len) )
> +                break;
> +

Is this hunk problematic?

It's called in a loop. Looks like it may register the same ptr multiple
times which leads to freeing same ptr multiple times later.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:20:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09: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 1XqITm-00012P-NJ; Mon, 17 Nov 2014 09:20:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XqITl-00012G-CA
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:20:13 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	A3/4F-03145-CCDB9645; Mon, 17 Nov 2014 09:20:12 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416216009!12976919!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30476 invoked from network); 17 Nov 2014 09:20:10 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 09:20:10 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 17 Nov 2014 02:20:01 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Mon, 17 Nov 2014 17:19:47 +0800
Message-Id: <1416215987-21571-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently libxl__domain_rename only update /local/domain/<domid>/name,
still some places in xenstore are not updated, including:
/vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 tools/libxl/libxl.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..6671b08 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
     uint32_t stub_dm_domid;
     const char *stub_dm_old_name = NULL, *stub_dm_new_name = NULL;
     int rc;
+    const char *vm_path, *vm_name_path;
+    char** be_dev = NULL;
+    unsigned int ndevs = 0;
 
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) goto x_nomem;
@@ -429,6 +432,58 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
         goto x_fail;
     }
 
+    /* update /vm/<uuid>/name */
+    vm_path = libxl__xs_read(gc, trans, libxl__sprintf(gc, "%s/vm", dom_path));
+    vm_name_path = libxl__sprintf(gc, "%s/name", vm_path);
+    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
+                   " to %s", new_name, vm_name_path);
+        goto x_fail;
+    }
+
+
+    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
+    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
+    if (be_dev && ndevs) {
+        for (int i = 0; i < ndevs; i++, be_dev++) {
+            /* <device>: vbd, vif, vkbd, ... */
+            char** be_dom = NULL;
+            unsigned int ndoms = 0;
+            be_dom = libxl__xs_directory(gc, trans,
+                     GCSPRINTF("/local/domain/0/backend/%s", *be_dev), &ndoms);
+            if (be_dom && ndoms) {
+                for (int j = 0; j < ndoms; j++, be_dom++) {
+                    /* <device>/<domid>: vif/1, vif/2, ...*/
+                    char ** be_devid = NULL;
+                    unsigned int ndevids = 0;
+
+                    if (strcmp(*be_dom, GCSPRINTF("%d", domid)))
+                        continue;
+
+                    be_devid = libxl__xs_directory(gc, trans,
+                                     GCSPRINTF("/local/domain/0/backend/%s/%s",
+                                     *be_dev, *be_dom),
+                                     &ndevids);
+                    if (be_devid && ndevids) {
+                        for (int k = 0; k < ndevids; k++, be_devid++) {
+                            /* <device>/<domid>/<devid>: vif/1/0, vif/1/1, ... */
+                            char *tmp = GCSPRINTF("/local/domain/0/backend/%s/%s/%s/domain",
+                                                  *be_dev, *be_dom, *be_devid);
+                            if (!libxl__xs_read(gc, trans, tmp))
+                                continue;
+
+                            if (libxl__xs_write_checked(gc, trans, tmp, new_name)) {
+                                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
+                                           " to %s", new_name, tmp);
+                                goto x_fail;
+                            }
+                        }
+                    }
+                }
+            }
+        }
+    }
+
     if (stub_dm_domid) {
         rc = libxl__domain_rename(gc, stub_dm_domid,
                                   stub_dm_old_name,
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:20:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09: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 1XqITm-00012P-NJ; Mon, 17 Nov 2014 09:20:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XqITl-00012G-CA
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:20:13 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	A3/4F-03145-CCDB9645; Mon, 17 Nov 2014 09:20:12 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416216009!12976919!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30476 invoked from network); 17 Nov 2014 09:20:10 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 09:20:10 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 17 Nov 2014 02:20:01 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Mon, 17 Nov 2014 17:19:47 +0800
Message-Id: <1416215987-21571-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently libxl__domain_rename only update /local/domain/<domid>/name,
still some places in xenstore are not updated, including:
/vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 tools/libxl/libxl.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..6671b08 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
     uint32_t stub_dm_domid;
     const char *stub_dm_old_name = NULL, *stub_dm_new_name = NULL;
     int rc;
+    const char *vm_path, *vm_name_path;
+    char** be_dev = NULL;
+    unsigned int ndevs = 0;
 
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) goto x_nomem;
@@ -429,6 +432,58 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
         goto x_fail;
     }
 
+    /* update /vm/<uuid>/name */
+    vm_path = libxl__xs_read(gc, trans, libxl__sprintf(gc, "%s/vm", dom_path));
+    vm_name_path = libxl__sprintf(gc, "%s/name", vm_path);
+    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
+                   " to %s", new_name, vm_name_path);
+        goto x_fail;
+    }
+
+
+    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
+    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
+    if (be_dev && ndevs) {
+        for (int i = 0; i < ndevs; i++, be_dev++) {
+            /* <device>: vbd, vif, vkbd, ... */
+            char** be_dom = NULL;
+            unsigned int ndoms = 0;
+            be_dom = libxl__xs_directory(gc, trans,
+                     GCSPRINTF("/local/domain/0/backend/%s", *be_dev), &ndoms);
+            if (be_dom && ndoms) {
+                for (int j = 0; j < ndoms; j++, be_dom++) {
+                    /* <device>/<domid>: vif/1, vif/2, ...*/
+                    char ** be_devid = NULL;
+                    unsigned int ndevids = 0;
+
+                    if (strcmp(*be_dom, GCSPRINTF("%d", domid)))
+                        continue;
+
+                    be_devid = libxl__xs_directory(gc, trans,
+                                     GCSPRINTF("/local/domain/0/backend/%s/%s",
+                                     *be_dev, *be_dom),
+                                     &ndevids);
+                    if (be_devid && ndevids) {
+                        for (int k = 0; k < ndevids; k++, be_devid++) {
+                            /* <device>/<domid>/<devid>: vif/1/0, vif/1/1, ... */
+                            char *tmp = GCSPRINTF("/local/domain/0/backend/%s/%s/%s/domain",
+                                                  *be_dev, *be_dom, *be_devid);
+                            if (!libxl__xs_read(gc, trans, tmp))
+                                continue;
+
+                            if (libxl__xs_write_checked(gc, trans, tmp, new_name)) {
+                                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
+                                           " to %s", new_name, tmp);
+                                goto x_fail;
+                            }
+                        }
+                    }
+                }
+            }
+        }
+    }
+
     if (stub_dm_domid) {
         rc = libxl__domain_rename(gc, stub_dm_domid,
                                   stub_dm_old_name,
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:29:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:29:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIcL-0001Gp-NG; Mon, 17 Nov 2014 09:29:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1XqIcJ-0001Gk-LV
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:29:03 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	FF/5F-02954-EDFB9645; Mon, 17 Nov 2014 09:29:02 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416216541!12977395!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27102 invoked from network); 17 Nov 2014 09:29:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-14.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 09:29:02 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 17 Nov 2014 01:29:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="417515231"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Nov 2014 01:19:44 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Mon, 17 Nov 2014 17:28:58 +0800
Message-Id: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: avoid bringing up vcpus already online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Avoid sending duplicated qmp commands and eliminate the confusing error
messages like "Unable to add CPU: 0, it already exists".

Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
---
 tools/libxl/libxl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..d040e5c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5450,7 +5450,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid,
         LOGE(ERROR, "getting domain info list");
         return ERROR_FAIL;
     }
-    for (i = 0; i <= info.vcpu_max_id; i++) {
+    for (i = info.vcpu_online; i <= info.vcpu_max_id; i++) {
         if (libxl_bitmap_test(cpumap, i)) {
             /* Return value is ignore because it does not tell anything useful
              * on the completion of the command.
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:29:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:29:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIcL-0001Gp-NG; Mon, 17 Nov 2014 09:29:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1XqIcJ-0001Gk-LV
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:29:03 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	FF/5F-02954-EDFB9645; Mon, 17 Nov 2014 09:29:02 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416216541!12977395!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27102 invoked from network); 17 Nov 2014 09:29:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-14.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 09:29:02 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 17 Nov 2014 01:29:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="417515231"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Nov 2014 01:19:44 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Mon, 17 Nov 2014 17:28:58 +0800
Message-Id: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: avoid bringing up vcpus already online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Avoid sending duplicated qmp commands and eliminate the confusing error
messages like "Unable to add CPU: 0, it already exists".

Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
---
 tools/libxl/libxl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..d040e5c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5450,7 +5450,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid,
         LOGE(ERROR, "getting domain info list");
         return ERROR_FAIL;
     }
-    for (i = 0; i <= info.vcpu_max_id; i++) {
+    for (i = info.vcpu_online; i <= info.vcpu_max_id; i++) {
         if (libxl_bitmap_test(cpumap, i)) {
             /* Return value is ignore because it does not tell anything useful
              * on the completion of the command.
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:30:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIdR-0001LG-4w; Mon, 17 Nov 2014 09:30:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1XqIdP-0001L6-7t
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 09:30:11 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	30/34-25727-220C9645; Mon, 17 Nov 2014 09:30:10 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416216608!11851584!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5808 invoked from network); 17 Nov 2014 09:30:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 09:30:09 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAH9P6QH010921
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 17 Nov 2014 04:25:06 -0500
Received: from redhat.com (ovpn-116-95.ams2.redhat.com [10.36.116.95])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sAH9P2Pq020991; Mon, 17 Nov 2014 04:25:03 -0500
Date: Mon, 17 Nov 2014 11:25:01 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141117092501.GA20133@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
	<20141117061010.GB19718@redhat.com> <5469B660.6040107@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5469B660.6040107@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
> On 2014/11/17 14:10, Michael S. Tsirkin wrote:
> >On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
> >>On 2014/11/5 22:09, Michael S. Tsirkin wrote:
> >>>On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
> >>>>Currently IGD drivers always need to access PCH by 1f.0, and
> >>>>PCH vendor/device id is used to identify the card.
> >>>>
> >>>>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>>>---
> >>>>  hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
> >>>>  1 file changed, 27 insertions(+), 1 deletion(-)
> >>>>
> >>>>diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> >>>>index b559181..b19c7a9 100644
> >>>>--- a/hw/i386/pc_piix.c
> >>>>+++ b/hw/i386/pc_piix.c
> >>>>@@ -50,7 +50,7 @@
> >>>>  #include "cpu.h"
> >>>>  #include "qemu/error-report.h"
> >>>>  #ifdef CONFIG_XEN
> >>>>-#  include <xen/hvm/hvm_info_table.h>
> >>>>+#include <xen/hvm/hvm_info_table.h>
> >>>>  #endif
> >>>>
> >>>>  #define MAX_IDE_BUS 2
> >>>>@@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
> >>>>  }
> >>>>
> >>>>  #ifdef CONFIG_XEN
> >>>>+static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
> >>>>+{
> >>>>+    struct PCIDevice *dev;
> >>>>+    Error *local_err = NULL;
> >>>>+    uint16_t device_id = 0xffff;
> >>>>+
> >>>>+    /* Currently IGD drivers always need to access PCH by 1f.0. */
> >>>>+    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
> >>>>+                            "xen-igd-passthrough-isa-bridge");
> >>>>+
> >>>>+    /* Identify PCH card with its own real vendor/device ids.
> >>>>+     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
> >>>>+     */
> >>>>+    if (dev) {
> >>>>+        device_id = object_property_get_int(OBJECT(dev), "device-id",
> >>>>+                                            &local_err);
> >>>>+        if (!local_err && device_id != 0xffff) {
> >>>>+            pci_config_set_device_id(dev->config, device_id);
> >>>>+            return;
> >>>>+        }
> >>>>+    }
> >>>>+
> >>>>+    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
> >>>>+}
> >>>>+
> >>>>  static void pc_xen_hvm_init(MachineState *machine)
> >>>>  {
> >>>>      PCIBus *bus;
> >>>>@@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
> >>>>      bus = pci_find_primary_bus();
> >>>>      if (bus != NULL) {
> >>>>          pci_create_simple(bus, -1, "xen-platform");
> >>>>+        xen_igd_passthrough_isa_bridge_create(bus);
> >>>>      }
> >>>>  }
> >>>>  #endif
> >>>
> >>>Can't we defer this step until the GPU is added?
> >>
> >>Sounds great but I can't figure out where we can to do this exactly.
> >>
> >>>This way there won't be need to poke at host device
> >>>directly, you could get all info from dev->config
> >>>of the host device.
> >>
> >>As I understand We have two steps here:
> >>
> >>#1 At first I have to write something to check if we're registering 00:02.0
> >>& IGD, right? But where? While registering each pci device?
> >
> >In xen_pt_initfn.
> >Just check the device and vendor ID against the table you have.
> >
> 
> Okay. Please see the follows which is just compiled:
> 
> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> index c6466dc..f3ea313 100644
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -632,6 +632,94 @@ static const MemoryListener xen_pt_io_listener = {
>      .priority = 10,
>  };
> 
> +typedef struct {
> +    uint16_t gpu_device_id;
> +    uint16_t pch_device_id;
> +} XenIGDDeviceIDInfo;
> +
> +/* In real world different GPU should have different PCH. But actually
> + * the different PCH DIDs likely map to different PCH SKUs. We do the
> + * same thing for the GPU. For PCH, the different SKUs are going to be
> + * all the same silicon design and implementation, just different
> + * features turn on and off with fuses. The SW interfaces should be
> + * consistent across all SKUs in a given family (eg LPT). But just same
> + * features may not be supported.
> + *
> + * Most of these different PCH features probably don't matter to the
> + * Gfx driver, but obviously any difference in display port connections
> + * will so it should be fine with any PCH in case of passthrough.
> + *
> + * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
> + * scenarios, 0x9cc3 for BDW(Broadwell).
> + */
> +static const XenIGDDeviceIDInfo xen_igd_combo_id_infos[] = {
> +    /* HSW Classic */
> +    {0x0402, 0x8c4e}, /* HSWGT1D, HSWD_w7 */
> +    {0x0406, 0x8c4e}, /* HSWGT1M, HSWM_w7 */
> +    {0x0412, 0x8c4e}, /* HSWGT2D, HSWD_w7 */
> +    {0x0416, 0x8c4e}, /* HSWGT2M, HSWM_w7 */
> +    {0x041E, 0x8c4e}, /* HSWGT15D, HSWD_w7 */
> +    /* HSW ULT */
> +    {0x0A06, 0x8c4e}, /* HSWGT1UT, HSWM_w7 */
> +    {0x0A16, 0x8c4e}, /* HSWGT2UT, HSWM_w7 */
> +    {0x0A26, 0x8c4e}, /* HSWGT3UT, HSWM_w7 */
> +    {0x0A2E, 0x8c4e}, /* HSWGT3UT28W, HSWM_w7 */
> +    {0x0A1E, 0x8c4e}, /* HSWGT2UX, HSWM_w7 */
> +    {0x0A0E, 0x8c4e}, /* HSWGT1ULX, HSWM_w7 */
> +    /* HSW CRW */
> +    {0x0D26, 0x8c4e}, /* HSWGT3CW, HSWM_w7 */
> +    {0x0D22, 0x8c4e}, /* HSWGT3CWDT, HSWD_w7 */
> +    /* HSW Server */
> +    {0x041A, 0x8c4e}, /* HSWSVGT2, HSWD_w7 */
> +    /* HSW SRVR */
> +    {0x040A, 0x8c4e}, /* HSWSVGT1, HSWD_w7 */
> +    /* BSW */
> +    {0x1606, 0x9cc3}, /* BDWULTGT1, BDWM_w7 */
> +    {0x1616, 0x9cc3}, /* BDWULTGT2, BDWM_w7 */
> +    {0x1626, 0x9cc3}, /* BDWULTGT3, BDWM_w7 */
> +    {0x160E, 0x9cc3}, /* BDWULXGT1, BDWM_w7 */
> +    {0x161E, 0x9cc3}, /* BDWULXGT2, BDWM_w7 */
> +    {0x1602, 0x9cc3}, /* BDWHALOGT1, BDWM_w7 */
> +    {0x1612, 0x9cc3}, /* BDWHALOGT2, BDWM_w7 */
> +    {0x1622, 0x9cc3}, /* BDWHALOGT3, BDWM_w7 */
> +    {0x162B, 0x9cc3}, /* BDWHALO28W, BDWM_w7 */
> +    {0x162A, 0x9cc3}, /* BDWGT3WRKS, BDWM_w7 */
> +    {0x162D, 0x9cc3}, /* BDWGT3SRVR, BDWM_w7 */
> +};
> +
> +static void
> +xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
> +                                      XenHostPCIDevice *dev)
> +{
> +    struct PCIDevice *pci_dev;
> +    int i, num;
> +    uint16_t gpu_id = 0xffff,

no need to init gpu_id.

> pch_id = 0xffff;
> +    PCIDevice *d = &s->dev;
> +
> +    if (is_vga_passthrough(dev)) {

I would do if (!is_vga_passthrough) { return; } here.
Makes following code shorter.

> +        gpu_id = dev->device_id;
> +        num = ARRAY_SIZE(xen_igd_combo_id_infos);
> +        for (i = 0; i < num; i++)
> +            if (gpu_id == xen_igd_combo_id_infos[i].gpu_device_id)
> +                pch_id = xen_igd_combo_id_infos[i].pch_device_id;

Add {} to match our coding style please.


At this point I would do

if (pch_id == 0xffff) {
	return;
}


maybe replace 0xffff with 0x0, then you can do if (!pch_id) { return; }.

> +
> +        /* Currently IGD drivers always need to access PCH by 1f.0. */
> +        pci_dev = pci_create_simple(d->bus, PCI_DEVFN(0x1f, 0),
> +                                    "xen-igd-passthrough-isa-bridge");
> +
> +        /*
> +         * Identify PCH card with its own real vendor/device ids.
> +         * Here that vendor id is always PCI_VENDOR_ID_INTEL.

s/Here/Note/

> +         */
> +        if (pci_dev) {
> +            pci_config_set_device_id(pci_dev->config, pch_id);
> +            return;
> +        }
> +
> +        fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge
> failed!\n");


Cleaner:
	 if (!pci_dev) {
		fprintf
		return;
	}
         pci_config_set_device_id(pci_dev->config, pch_id);

> +    }
> +}
> +
>  /* init */
> 
>  static int xen_pt_initfn(PCIDevice *d)
> @@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
>          return -1;
>      }
> 
> +    /* Register ISA bridge for passthrough GFX. */
> +    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
> +
>      /* reinitialize each config register to be emulated */
>      if (xen_pt_config_init(s)) {
>          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
> 
> Note I will introduce a inline function in another patch,
> 
> +static inline int is_vga_passthrough(XenHostPCIDevice *dev)
> +{
> +    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
> +            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
> +}
> 
> Thanks
> Tiejun

Why bother with all these conditions?
Won't it be enough to check dev->vendor_id == PCI_VENDOR_ID_INTEL?


-- 
MST


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:30:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIdR-0001LG-4w; Mon, 17 Nov 2014 09:30:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1XqIdP-0001L6-7t
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 09:30:11 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	30/34-25727-220C9645; Mon, 17 Nov 2014 09:30:10 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416216608!11851584!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5808 invoked from network); 17 Nov 2014 09:30:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 09:30:09 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAH9P6QH010921
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 17 Nov 2014 04:25:06 -0500
Received: from redhat.com (ovpn-116-95.ams2.redhat.com [10.36.116.95])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sAH9P2Pq020991; Mon, 17 Nov 2014 04:25:03 -0500
Date: Mon, 17 Nov 2014 11:25:01 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141117092501.GA20133@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
	<20141117061010.GB19718@redhat.com> <5469B660.6040107@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5469B660.6040107@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
> On 2014/11/17 14:10, Michael S. Tsirkin wrote:
> >On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
> >>On 2014/11/5 22:09, Michael S. Tsirkin wrote:
> >>>On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
> >>>>Currently IGD drivers always need to access PCH by 1f.0, and
> >>>>PCH vendor/device id is used to identify the card.
> >>>>
> >>>>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>>>---
> >>>>  hw/i386/pc_piix.c | 28 +++++++++++++++++++++++++++-
> >>>>  1 file changed, 27 insertions(+), 1 deletion(-)
> >>>>
> >>>>diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> >>>>index b559181..b19c7a9 100644
> >>>>--- a/hw/i386/pc_piix.c
> >>>>+++ b/hw/i386/pc_piix.c
> >>>>@@ -50,7 +50,7 @@
> >>>>  #include "cpu.h"
> >>>>  #include "qemu/error-report.h"
> >>>>  #ifdef CONFIG_XEN
> >>>>-#  include <xen/hvm/hvm_info_table.h>
> >>>>+#include <xen/hvm/hvm_info_table.h>
> >>>>  #endif
> >>>>
> >>>>  #define MAX_IDE_BUS 2
> >>>>@@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
> >>>>  }
> >>>>
> >>>>  #ifdef CONFIG_XEN
> >>>>+static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
> >>>>+{
> >>>>+    struct PCIDevice *dev;
> >>>>+    Error *local_err = NULL;
> >>>>+    uint16_t device_id = 0xffff;
> >>>>+
> >>>>+    /* Currently IGD drivers always need to access PCH by 1f.0. */
> >>>>+    dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
> >>>>+                            "xen-igd-passthrough-isa-bridge");
> >>>>+
> >>>>+    /* Identify PCH card with its own real vendor/device ids.
> >>>>+     * Here that vendor id is always PCI_VENDOR_ID_INTEL.
> >>>>+     */
> >>>>+    if (dev) {
> >>>>+        device_id = object_property_get_int(OBJECT(dev), "device-id",
> >>>>+                                            &local_err);
> >>>>+        if (!local_err && device_id != 0xffff) {
> >>>>+            pci_config_set_device_id(dev->config, device_id);
> >>>>+            return;
> >>>>+        }
> >>>>+    }
> >>>>+
> >>>>+    fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
> >>>>+}
> >>>>+
> >>>>  static void pc_xen_hvm_init(MachineState *machine)
> >>>>  {
> >>>>      PCIBus *bus;
> >>>>@@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
> >>>>      bus = pci_find_primary_bus();
> >>>>      if (bus != NULL) {
> >>>>          pci_create_simple(bus, -1, "xen-platform");
> >>>>+        xen_igd_passthrough_isa_bridge_create(bus);
> >>>>      }
> >>>>  }
> >>>>  #endif
> >>>
> >>>Can't we defer this step until the GPU is added?
> >>
> >>Sounds great but I can't figure out where we can to do this exactly.
> >>
> >>>This way there won't be need to poke at host device
> >>>directly, you could get all info from dev->config
> >>>of the host device.
> >>
> >>As I understand We have two steps here:
> >>
> >>#1 At first I have to write something to check if we're registering 00:02.0
> >>& IGD, right? But where? While registering each pci device?
> >
> >In xen_pt_initfn.
> >Just check the device and vendor ID against the table you have.
> >
> 
> Okay. Please see the follows which is just compiled:
> 
> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> index c6466dc..f3ea313 100644
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -632,6 +632,94 @@ static const MemoryListener xen_pt_io_listener = {
>      .priority = 10,
>  };
> 
> +typedef struct {
> +    uint16_t gpu_device_id;
> +    uint16_t pch_device_id;
> +} XenIGDDeviceIDInfo;
> +
> +/* In real world different GPU should have different PCH. But actually
> + * the different PCH DIDs likely map to different PCH SKUs. We do the
> + * same thing for the GPU. For PCH, the different SKUs are going to be
> + * all the same silicon design and implementation, just different
> + * features turn on and off with fuses. The SW interfaces should be
> + * consistent across all SKUs in a given family (eg LPT). But just same
> + * features may not be supported.
> + *
> + * Most of these different PCH features probably don't matter to the
> + * Gfx driver, but obviously any difference in display port connections
> + * will so it should be fine with any PCH in case of passthrough.
> + *
> + * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
> + * scenarios, 0x9cc3 for BDW(Broadwell).
> + */
> +static const XenIGDDeviceIDInfo xen_igd_combo_id_infos[] = {
> +    /* HSW Classic */
> +    {0x0402, 0x8c4e}, /* HSWGT1D, HSWD_w7 */
> +    {0x0406, 0x8c4e}, /* HSWGT1M, HSWM_w7 */
> +    {0x0412, 0x8c4e}, /* HSWGT2D, HSWD_w7 */
> +    {0x0416, 0x8c4e}, /* HSWGT2M, HSWM_w7 */
> +    {0x041E, 0x8c4e}, /* HSWGT15D, HSWD_w7 */
> +    /* HSW ULT */
> +    {0x0A06, 0x8c4e}, /* HSWGT1UT, HSWM_w7 */
> +    {0x0A16, 0x8c4e}, /* HSWGT2UT, HSWM_w7 */
> +    {0x0A26, 0x8c4e}, /* HSWGT3UT, HSWM_w7 */
> +    {0x0A2E, 0x8c4e}, /* HSWGT3UT28W, HSWM_w7 */
> +    {0x0A1E, 0x8c4e}, /* HSWGT2UX, HSWM_w7 */
> +    {0x0A0E, 0x8c4e}, /* HSWGT1ULX, HSWM_w7 */
> +    /* HSW CRW */
> +    {0x0D26, 0x8c4e}, /* HSWGT3CW, HSWM_w7 */
> +    {0x0D22, 0x8c4e}, /* HSWGT3CWDT, HSWD_w7 */
> +    /* HSW Server */
> +    {0x041A, 0x8c4e}, /* HSWSVGT2, HSWD_w7 */
> +    /* HSW SRVR */
> +    {0x040A, 0x8c4e}, /* HSWSVGT1, HSWD_w7 */
> +    /* BSW */
> +    {0x1606, 0x9cc3}, /* BDWULTGT1, BDWM_w7 */
> +    {0x1616, 0x9cc3}, /* BDWULTGT2, BDWM_w7 */
> +    {0x1626, 0x9cc3}, /* BDWULTGT3, BDWM_w7 */
> +    {0x160E, 0x9cc3}, /* BDWULXGT1, BDWM_w7 */
> +    {0x161E, 0x9cc3}, /* BDWULXGT2, BDWM_w7 */
> +    {0x1602, 0x9cc3}, /* BDWHALOGT1, BDWM_w7 */
> +    {0x1612, 0x9cc3}, /* BDWHALOGT2, BDWM_w7 */
> +    {0x1622, 0x9cc3}, /* BDWHALOGT3, BDWM_w7 */
> +    {0x162B, 0x9cc3}, /* BDWHALO28W, BDWM_w7 */
> +    {0x162A, 0x9cc3}, /* BDWGT3WRKS, BDWM_w7 */
> +    {0x162D, 0x9cc3}, /* BDWGT3SRVR, BDWM_w7 */
> +};
> +
> +static void
> +xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
> +                                      XenHostPCIDevice *dev)
> +{
> +    struct PCIDevice *pci_dev;
> +    int i, num;
> +    uint16_t gpu_id = 0xffff,

no need to init gpu_id.

> pch_id = 0xffff;
> +    PCIDevice *d = &s->dev;
> +
> +    if (is_vga_passthrough(dev)) {

I would do if (!is_vga_passthrough) { return; } here.
Makes following code shorter.

> +        gpu_id = dev->device_id;
> +        num = ARRAY_SIZE(xen_igd_combo_id_infos);
> +        for (i = 0; i < num; i++)
> +            if (gpu_id == xen_igd_combo_id_infos[i].gpu_device_id)
> +                pch_id = xen_igd_combo_id_infos[i].pch_device_id;

Add {} to match our coding style please.


At this point I would do

if (pch_id == 0xffff) {
	return;
}


maybe replace 0xffff with 0x0, then you can do if (!pch_id) { return; }.

> +
> +        /* Currently IGD drivers always need to access PCH by 1f.0. */
> +        pci_dev = pci_create_simple(d->bus, PCI_DEVFN(0x1f, 0),
> +                                    "xen-igd-passthrough-isa-bridge");
> +
> +        /*
> +         * Identify PCH card with its own real vendor/device ids.
> +         * Here that vendor id is always PCI_VENDOR_ID_INTEL.

s/Here/Note/

> +         */
> +        if (pci_dev) {
> +            pci_config_set_device_id(pci_dev->config, pch_id);
> +            return;
> +        }
> +
> +        fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge
> failed!\n");


Cleaner:
	 if (!pci_dev) {
		fprintf
		return;
	}
         pci_config_set_device_id(pci_dev->config, pch_id);

> +    }
> +}
> +
>  /* init */
> 
>  static int xen_pt_initfn(PCIDevice *d)
> @@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
>          return -1;
>      }
> 
> +    /* Register ISA bridge for passthrough GFX. */
> +    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
> +
>      /* reinitialize each config register to be emulated */
>      if (xen_pt_config_init(s)) {
>          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
> 
> Note I will introduce a inline function in another patch,
> 
> +static inline int is_vga_passthrough(XenHostPCIDevice *dev)
> +{
> +    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
> +            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
> +}
> 
> Thanks
> Tiejun

Why bother with all these conditions?
Won't it be enough to check dev->vendor_id == PCI_VENDOR_ID_INTEL?


-- 
MST


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:36:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:36:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIjE-0001dM-51; Mon, 17 Nov 2014 09:36:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqIjC-0001dH-G4
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:36:10 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	E0/D5-19763-981C9645; Mon, 17 Nov 2014 09:36:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416216965!11749031!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2644 invoked from network); 17 Nov 2014 09:36:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:36:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191974397"
Message-ID: <1416216961.27385.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 09:36:01 +0000
In-Reply-To: <20141117091658.GD11070@zion.uk.xensource.com>
References: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
	<20141117091658.GD11070@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxc: don't leak buffer containing
 the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 09:16 +0000, Wei Liu wrote:
> > @@ -508,6 +522,10 @@ static int xc_try_lzo1x_decode(
> >              if ( out_len != dst_len )
> >                  break;
> >  
> > +            msg = "Error registering stream output";
> > +            if ( xc_dom_register_external(dom, out_buf, out_len) )
> > +                break;
> > +
> 
> Is this hunk problematic?
> 
> It's called in a loop. Looks like it may register the same ptr multiple
> times which leads to freeing same ptr multiple times later.

Yes, it is wrong. I mistakenly read this as being the "input stream
done" case, but it's just "a chunk is done". I think the right place to
add this new code is actually in the if true part of:
        dst_len = lzo_read_32(cur);
        if ( !dst_len )
            return 0;

That's the only return within the loop, and any break would take us to
the function epilogue which is the error case and frees the buffer.

Thanks for checking!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:36:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:36:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIjE-0001dM-51; Mon, 17 Nov 2014 09:36:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqIjC-0001dH-G4
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:36:10 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	E0/D5-19763-981C9645; Mon, 17 Nov 2014 09:36:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416216965!11749031!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2644 invoked from network); 17 Nov 2014 09:36:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:36:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191974397"
Message-ID: <1416216961.27385.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 09:36:01 +0000
In-Reply-To: <20141117091658.GD11070@zion.uk.xensource.com>
References: <1415621313-25835-1-git-send-email-ian.campbell@citrix.com>
	<20141117091658.GD11070@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxc: don't leak buffer containing
 the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 09:16 +0000, Wei Liu wrote:
> > @@ -508,6 +522,10 @@ static int xc_try_lzo1x_decode(
> >              if ( out_len != dst_len )
> >                  break;
> >  
> > +            msg = "Error registering stream output";
> > +            if ( xc_dom_register_external(dom, out_buf, out_len) )
> > +                break;
> > +
> 
> Is this hunk problematic?
> 
> It's called in a loop. Looks like it may register the same ptr multiple
> times which leads to freeing same ptr multiple times later.

Yes, it is wrong. I mistakenly read this as being the "input stream
done" case, but it's just "a chunk is done". I think the right place to
add this new code is actually in the if true part of:
        dst_len = lzo_read_32(cur);
        if ( !dst_len )
            return 0;

That's the only return within the loop, and any break would take us to
the function epilogue which is the error case and frees the buffer.

Thanks for checking!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:41:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:41:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIoG-0001m2-19; Mon, 17 Nov 2014 09:41:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqIoF-0001lx-0X
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:41:23 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	A0/D0-27623-2C2C9645; Mon, 17 Nov 2014 09:41:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416217279!11848203!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21800 invoked from network); 17 Nov 2014 09:41:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:41:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193471198"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 04:41:18 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqIo9-0007QU-Rz;
	Mon, 17 Nov 2014 09:41:17 +0000
Date: Mon, 17 Nov 2014 09:41:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chao Peng <chao.p.peng@linux.intel.com>
Message-ID: <20141117094117.GF11070@zion.uk.xensource.com>
References: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: avoid bringing up vcpus already
	online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
> Avoid sending duplicated qmp commands and eliminate the confusing error
> messages like "Unable to add CPU: 0, it already exists".
> 
> Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> ---
>  tools/libxl/libxl.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..d040e5c 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5450,7 +5450,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid,
>          LOGE(ERROR, "getting domain info list");
>          return ERROR_FAIL;
>      }
> -    for (i = 0; i <= info.vcpu_max_id; i++) {
> +    for (i = info.vcpu_online; i <= info.vcpu_max_id; i++) {

I don't think this is right. You're making an assumption that vcpu 0 to
vcpu "info.vcpu_online" are online, which might not be true in hotplug /
hot-unplug scenario.

Wei.

>          if (libxl_bitmap_test(cpumap, i)) {
>              /* Return value is ignore because it does not tell anything useful
>               * on the completion of the command.
> -- 
> 1.7.9.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:41:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:41:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIoG-0001m2-19; Mon, 17 Nov 2014 09:41:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqIoF-0001lx-0X
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:41:23 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	A0/D0-27623-2C2C9645; Mon, 17 Nov 2014 09:41:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416217279!11848203!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21800 invoked from network); 17 Nov 2014 09:41:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:41:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193471198"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 04:41:18 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqIo9-0007QU-Rz;
	Mon, 17 Nov 2014 09:41:17 +0000
Date: Mon, 17 Nov 2014 09:41:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chao Peng <chao.p.peng@linux.intel.com>
Message-ID: <20141117094117.GF11070@zion.uk.xensource.com>
References: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: avoid bringing up vcpus already
	online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
> Avoid sending duplicated qmp commands and eliminate the confusing error
> messages like "Unable to add CPU: 0, it already exists".
> 
> Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> ---
>  tools/libxl/libxl.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..d040e5c 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5450,7 +5450,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid,
>          LOGE(ERROR, "getting domain info list");
>          return ERROR_FAIL;
>      }
> -    for (i = 0; i <= info.vcpu_max_id; i++) {
> +    for (i = info.vcpu_online; i <= info.vcpu_max_id; i++) {

I don't think this is right. You're making an assumption that vcpu 0 to
vcpu "info.vcpu_online" are online, which might not be true in hotplug /
hot-unplug scenario.

Wei.

>          if (libxl_bitmap_test(cpumap, i)) {
>              /* Return value is ignore because it does not tell anything useful
>               * on the completion of the command.
> -- 
> 1.7.9.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:41:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIoi-0001s3-Df; Mon, 17 Nov 2014 09:41:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqIog-0001rr-Vk
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:41:51 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	FD/C1-27623-ED2C9645; Mon, 17 Nov 2014 09:41:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416217308!11870149!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20350 invoked from network); 17 Nov 2014 09:41:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:41:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191975631"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 04:41:47 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqIkD-0007LW-Io;
	Mon, 17 Nov 2014 09:37:13 +0000
Date: Mon, 17 Nov 2014 09:37:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Li, Liang Z" <liang.z.li@intel.com>
Message-ID: <20141117093713.GE11070@zion.uk.xensource.com>
References: <F2CBF3009FA73547804AE4C663CAB28E44BE59@shsmsx102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E44BE59@shsmsx102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the same
 device more than once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 07:53:44AM +0000, Li, Liang Z wrote:
> > Originally the code allowed users to attach the same device more than
> > once. It just stupidly overwrites xenstore entries. This is bogus as
> > frontend will be very confused.
> >
> > Introduce a helper function to check if the device to be written to
> > xenstore already exists. A new error code is also introduced.
> >
> > The check and add are within one xs transaction.
> >
> > Signed-off-by: Wei Liu <wei....@citrix.com>
> > ---
> 
> I find this patch will cause the pci-attach failed if more than one virtual function devices are attached to the guest.
> 

Is this a regression? I think so but I would like to confirm.

> 
> >  @@ -148,15 +150,32 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc,
> >  uint32_t domid, libxl_d
> >       if (!starting)
> >           flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 7));
> >  
> >  -retry_transaction:
> >  -    t = xs_transaction_start(ctx->xsh);
> >  -    libxl__xs_writev(gc, t, be_path,
> >  -                    libxl__xs_kvs_of_flexarray(gc, back, back->count));
> >  -    if (!xs_transaction_end(ctx->xsh, t, 0))
> >  -        if (errno == EAGAIN)
> >  -            goto retry_transaction;
> >  +    GCNEW(device);
> >  +    libxl__device_from_pcidev(gc, domid, pcidev, device);
> 
> >  -    return 0;
> >  +    for (;;) {
> >  +        rc = libxl__xs_transaction_start(gc, &t);
> >  +        if (rc) goto out;
> >  +
> >  +        rc = libxl__device_exists(gc, t, device);
> >  +        if (rc < 0) goto out;
> >  +        if (rc == 1) {
> >  +            LOG(ERROR, "device already exists in xenstore");
> >  +            rc = ERROR_DEVICE_EXISTS;
> >  +            goto out;
> >  +        } 
> 
> The libxl__device_exists will return 1 if more than one PCI devices are attached to the guest, no matter the BDFs are identical or not.

That means this check is problematic. I think the original intention was
to check on BDFs, however it wasn't thoroughly tested. Sorry.

> I don't understand why to check this condition here, if the same device was attached more than once the xc_test_assign_device() will return error,
> and the libxl__device_pci_add_xenstore() will not be called. It seems unnecessary.
> 

It was added to be in line with other devices. However from the look of
it PCI devices need special treatment? Do you have some PCI dev backend
paths at hand?

Does reverting the said patch help?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:41:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIoi-0001s3-Df; Mon, 17 Nov 2014 09:41:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqIog-0001rr-Vk
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:41:51 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	FD/C1-27623-ED2C9645; Mon, 17 Nov 2014 09:41:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416217308!11870149!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20350 invoked from network); 17 Nov 2014 09:41:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:41:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191975631"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 04:41:47 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqIkD-0007LW-Io;
	Mon, 17 Nov 2014 09:37:13 +0000
Date: Mon, 17 Nov 2014 09:37:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Li, Liang Z" <liang.z.li@intel.com>
Message-ID: <20141117093713.GE11070@zion.uk.xensource.com>
References: <F2CBF3009FA73547804AE4C663CAB28E44BE59@shsmsx102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E44BE59@shsmsx102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the same
 device more than once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 07:53:44AM +0000, Li, Liang Z wrote:
> > Originally the code allowed users to attach the same device more than
> > once. It just stupidly overwrites xenstore entries. This is bogus as
> > frontend will be very confused.
> >
> > Introduce a helper function to check if the device to be written to
> > xenstore already exists. A new error code is also introduced.
> >
> > The check and add are within one xs transaction.
> >
> > Signed-off-by: Wei Liu <wei....@citrix.com>
> > ---
> 
> I find this patch will cause the pci-attach failed if more than one virtual function devices are attached to the guest.
> 

Is this a regression? I think so but I would like to confirm.

> 
> >  @@ -148,15 +150,32 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc,
> >  uint32_t domid, libxl_d
> >       if (!starting)
> >           flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 7));
> >  
> >  -retry_transaction:
> >  -    t = xs_transaction_start(ctx->xsh);
> >  -    libxl__xs_writev(gc, t, be_path,
> >  -                    libxl__xs_kvs_of_flexarray(gc, back, back->count));
> >  -    if (!xs_transaction_end(ctx->xsh, t, 0))
> >  -        if (errno == EAGAIN)
> >  -            goto retry_transaction;
> >  +    GCNEW(device);
> >  +    libxl__device_from_pcidev(gc, domid, pcidev, device);
> 
> >  -    return 0;
> >  +    for (;;) {
> >  +        rc = libxl__xs_transaction_start(gc, &t);
> >  +        if (rc) goto out;
> >  +
> >  +        rc = libxl__device_exists(gc, t, device);
> >  +        if (rc < 0) goto out;
> >  +        if (rc == 1) {
> >  +            LOG(ERROR, "device already exists in xenstore");
> >  +            rc = ERROR_DEVICE_EXISTS;
> >  +            goto out;
> >  +        } 
> 
> The libxl__device_exists will return 1 if more than one PCI devices are attached to the guest, no matter the BDFs are identical or not.

That means this check is problematic. I think the original intention was
to check on BDFs, however it wasn't thoroughly tested. Sorry.

> I don't understand why to check this condition here, if the same device was attached more than once the xc_test_assign_device() will return error,
> and the libxl__device_pci_add_xenstore() will not be called. It seems unnecessary.
> 

It was added to be in line with other devices. However from the look of
it PCI devices need special treatment? Do you have some PCI dev backend
paths at hand?

Does reverting the said patch help?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:42:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:42:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIpP-0001yp-R9; Mon, 17 Nov 2014 09:42:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqIpP-0001yY-09
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 09:42:35 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A0/DC-23865-A03C9645; Mon, 17 Nov 2014 09:42:34 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416217353!11870427!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26323 invoked from network); 17 Nov 2014 09:42:33 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-31.messagelabs.com with SMTP;
	17 Nov 2014 09:42:33 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 17 Nov 2014 01:42:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,402,1413270000"; d="scan'208";a="609003934"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 01:42:13 -0800
Message-ID: <5469C2F4.4020304@intel.com>
Date: Mon, 17 Nov 2014 17:42:12 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
	<20141117061010.GB19718@redhat.com> <5469B660.6040107@intel.com>
	<20141117092501.GA20133@redhat.com>
In-Reply-To: <20141117092501.GA20133@redhat.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/17 17:25, Michael S. Tsirkin wrote:
> On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
>> On 2014/11/17 14:10, Michael S. Tsirkin wrote:
>>> On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
>>>> On 2014/11/5 22:09, Michael S. Tsirkin wrote:
>>>>> On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
>>>>>> Currently IGD drivers always need to access PCH by 1f.0, and
>>>>>> PCH vendor/device id is used to identify the card.
>>>>>>
>>>>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>>>>> ---

[snip]

> Cleaner:
> 	 if (!pci_dev) {
> 		fprintf
> 		return;
> 	}
>           pci_config_set_device_id(pci_dev->config, pch_id);

I will address all comments and thanks.

>
>> +    }
>> +}
>> +
>>   /* init */
>>
>>   static int xen_pt_initfn(PCIDevice *d)
>> @@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
>>           return -1;
>>       }
>>
>> +    /* Register ISA bridge for passthrough GFX. */
>> +    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
>> +
>>       /* reinitialize each config register to be emulated */
>>       if (xen_pt_config_init(s)) {
>>           XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
>>
>> Note I will introduce a inline function in another patch,
>>
>> +static inline int is_vga_passthrough(XenHostPCIDevice *dev)
>> +{
>> +    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
>> +            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
>> +}
>>
>> Thanks
>> Tiejun
>
> Why bother with all these conditions?
> Won't it be enough to check dev->vendor_id == PCI_VENDOR_ID_INTEL?
>

If this is just used for IGD, its always fine without checking vendor_id.

So after remove that check, I guess I need to rename that as 
is_igd_vga_passthrough() to make sense.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:42:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:42:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIpP-0001yp-R9; Mon, 17 Nov 2014 09:42:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqIpP-0001yY-09
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 09:42:35 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A0/DC-23865-A03C9645; Mon, 17 Nov 2014 09:42:34 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416217353!11870427!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26323 invoked from network); 17 Nov 2014 09:42:33 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-31.messagelabs.com with SMTP;
	17 Nov 2014 09:42:33 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 17 Nov 2014 01:42:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,402,1413270000"; d="scan'208";a="609003934"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 01:42:13 -0800
Message-ID: <5469C2F4.4020304@intel.com>
Date: Mon, 17 Nov 2014 17:42:12 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
	<20141117061010.GB19718@redhat.com> <5469B660.6040107@intel.com>
	<20141117092501.GA20133@redhat.com>
In-Reply-To: <20141117092501.GA20133@redhat.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/17 17:25, Michael S. Tsirkin wrote:
> On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
>> On 2014/11/17 14:10, Michael S. Tsirkin wrote:
>>> On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
>>>> On 2014/11/5 22:09, Michael S. Tsirkin wrote:
>>>>> On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
>>>>>> Currently IGD drivers always need to access PCH by 1f.0, and
>>>>>> PCH vendor/device id is used to identify the card.
>>>>>>
>>>>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>>>>> ---

[snip]

> Cleaner:
> 	 if (!pci_dev) {
> 		fprintf
> 		return;
> 	}
>           pci_config_set_device_id(pci_dev->config, pch_id);

I will address all comments and thanks.

>
>> +    }
>> +}
>> +
>>   /* init */
>>
>>   static int xen_pt_initfn(PCIDevice *d)
>> @@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
>>           return -1;
>>       }
>>
>> +    /* Register ISA bridge for passthrough GFX. */
>> +    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
>> +
>>       /* reinitialize each config register to be emulated */
>>       if (xen_pt_config_init(s)) {
>>           XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
>>
>> Note I will introduce a inline function in another patch,
>>
>> +static inline int is_vga_passthrough(XenHostPCIDevice *dev)
>> +{
>> +    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
>> +            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
>> +}
>>
>> Thanks
>> Tiejun
>
> Why bother with all these conditions?
> Won't it be enough to check dev->vendor_id == PCI_VENDOR_ID_INTEL?
>

If this is just used for IGD, its always fine without checking vendor_id.

So after remove that check, I guess I need to rename that as 
is_igd_vga_passthrough() to make sense.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:42:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:42:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIpa-00021d-81; Mon, 17 Nov 2014 09:42:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqIpY-00021G-Ir
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:42:44 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	AB/0D-02954-313C9645; Mon, 17 Nov 2014 09:42:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416217362!8346890!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27933 invoked from network); 17 Nov 2014 09:42:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:42:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191975774"
Message-ID: <1416217335.27385.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 17 Nov 2014 09:42:15 +0000
In-Reply-To: <20141116202606.GD9960@lvm>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
	<1415628601-31075-1-git-send-email-ian.campbell@citrix.com>
	<20141116202606.GD9960@lvm>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen: Correction to module@1 (dom0
	kernel) DT node.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2014-11-16 at 12:26 -0800, Christoffer Dall wrote:
> Hi Ian,
> 
> On Mon, Nov 10, 2014 at 02:09:58PM +0000, Ian Campbell wrote:
> > - Include bootargs (kernel command line) property.
> 
> Why?
> 
> The logic I was going for was to reduce duplicate code/entries in the
> DT, and if I read docs/misc/arm/device-tree/booting.txt, the fact that
> we have xen,xen-bootargs but no xen,dom0-bootargs then bootargs added
> further down in Makefile.am will be used.
> 
> Is this not correct or not preferred for some reason?

I thought it wasn't working for me, but it's possible I was tripping
over something else which I fixed by hacking around in this stuff around
the same time and misattributed the fix to this change.

Looking at it now I agree that the code looks like it should work
without this change, so why don't you drop this hunk and if I find
something not working right in the new version I'll investigate again
from scratch.

Ian.

> 
> -Christoffer
> 
> > - Update reg property to match #address-cells and #size-cells in the DTB (both
> >   2).
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  Makefile.am |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 9b6c7e3..ed5acbb 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -69,8 +69,9 @@ XEN_OFFSET	:= 0xA00000
> >  DOM0_OFFSET	:= $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
> >  XEN_BOOTARGS	:= xen,xen-bootargs = \"$(BOOTARGS)\";			\
> >  		   module@1 {						\
> > +			bootargs = \"$(CMDLINE)\";			\
> >  			compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
> > -			reg = <$(DOM0_OFFSET) 0x800000>;		\
> > +			reg = <0 $(DOM0_OFFSET) 0 0x800000>;		\
> >  		   };
> >  endif
> >  
> > -- 
> > 1.7.10.4
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:42:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:42:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIpa-00021d-81; Mon, 17 Nov 2014 09:42:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqIpY-00021G-Ir
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:42:44 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	AB/0D-02954-313C9645; Mon, 17 Nov 2014 09:42:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416217362!8346890!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27933 invoked from network); 17 Nov 2014 09:42:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:42:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191975774"
Message-ID: <1416217335.27385.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 17 Nov 2014 09:42:15 +0000
In-Reply-To: <20141116202606.GD9960@lvm>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
	<1415628601-31075-1-git-send-email-ian.campbell@citrix.com>
	<20141116202606.GD9960@lvm>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen: Correction to module@1 (dom0
	kernel) DT node.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2014-11-16 at 12:26 -0800, Christoffer Dall wrote:
> Hi Ian,
> 
> On Mon, Nov 10, 2014 at 02:09:58PM +0000, Ian Campbell wrote:
> > - Include bootargs (kernel command line) property.
> 
> Why?
> 
> The logic I was going for was to reduce duplicate code/entries in the
> DT, and if I read docs/misc/arm/device-tree/booting.txt, the fact that
> we have xen,xen-bootargs but no xen,dom0-bootargs then bootargs added
> further down in Makefile.am will be used.
> 
> Is this not correct or not preferred for some reason?

I thought it wasn't working for me, but it's possible I was tripping
over something else which I fixed by hacking around in this stuff around
the same time and misattributed the fix to this change.

Looking at it now I agree that the code looks like it should work
without this change, so why don't you drop this hunk and if I find
something not working right in the new version I'll investigate again
from scratch.

Ian.

> 
> -Christoffer
> 
> > - Update reg property to match #address-cells and #size-cells in the DTB (both
> >   2).
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  Makefile.am |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 9b6c7e3..ed5acbb 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -69,8 +69,9 @@ XEN_OFFSET	:= 0xA00000
> >  DOM0_OFFSET	:= $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
> >  XEN_BOOTARGS	:= xen,xen-bootargs = \"$(BOOTARGS)\";			\
> >  		   module@1 {						\
> > +			bootargs = \"$(CMDLINE)\";			\
> >  			compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
> > -			reg = <$(DOM0_OFFSET) 0x800000>;		\
> > +			reg = <0 $(DOM0_OFFSET) 0 0x800000>;		\
> >  		   };
> >  endif
> >  
> > -- 
> > 1.7.10.4
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:44:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:44:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIr9-0002FB-Nh; Mon, 17 Nov 2014 09:44:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqIr8-0002Et-HX
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:44:22 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CE/7F-24532-573C9645; Mon, 17 Nov 2014 09:44:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416217460!13270863!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10972 invoked from network); 17 Nov 2014 09:44:21 -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;
	17 Nov 2014 09:44:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193471969"
Message-ID: <1416217458.27385.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 17 Nov 2014 09:44:18 +0000
In-Reply-To: <20141116210356.GE9960@lvm>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
	<1415628601-31075-2-git-send-email-ian.campbell@citrix.com>
	<20141116210356.GE9960@lvm>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] Fix build when Xen is not enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2014-11-16 at 13:03 -0800, Christoffer Dall wrote:
> On Mon, Nov 10, 2014 at 02:09:59PM +0000, Ian Campbell wrote:
> > If Xen isn't enabled then XEN_IMAGE ends up as "no.o", which obviously doesn't
> > exist. Handle the dependency explicitly.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  Makefile.am |    5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index ed5acbb..6c2786e 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -98,7 +98,10 @@ all: $(IMAGE) $(XIMAGE)
> >  
> >  CLEANFILES = $(IMAGE) boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb
> >  
> > -$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
> > +if XEN
> > +XEN_IMAGE_DEP = $(XEN_IMAGE)
> > +endif
> > +$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE_DEP)
> >  	$(LD) -o $@ --script=model.lds
> >  
> >  %.o: %.S Makefile
> > -- 
> > 1.7.10.4
> > 
> I fixed this differently, see the 'xen-psci-support-for-upstream' branch in:
> http://git.linaro.org/people/christoffer.dall/boot-wrapper-aarch64.git
> 
> Hopefully you're ok with that change.

Sure.

Ian,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:44:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:44:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIr9-0002FB-Nh; Mon, 17 Nov 2014 09:44:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqIr8-0002Et-HX
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:44:22 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CE/7F-24532-573C9645; Mon, 17 Nov 2014 09:44:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416217460!13270863!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10972 invoked from network); 17 Nov 2014 09:44:21 -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;
	17 Nov 2014 09:44:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193471969"
Message-ID: <1416217458.27385.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 17 Nov 2014 09:44:18 +0000
In-Reply-To: <20141116210356.GE9960@lvm>
References: <CAMJs5B-aJb=CzatgdXT2s6rM7aYjvTSwUg5PzSOUeDy=o=bmyA@mail.gmail.com>
	<1415628601-31075-2-git-send-email-ian.campbell@citrix.com>
	<20141116210356.GE9960@lvm>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] Fix build when Xen is not enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2014-11-16 at 13:03 -0800, Christoffer Dall wrote:
> On Mon, Nov 10, 2014 at 02:09:59PM +0000, Ian Campbell wrote:
> > If Xen isn't enabled then XEN_IMAGE ends up as "no.o", which obviously doesn't
> > exist. Handle the dependency explicitly.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  Makefile.am |    5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index ed5acbb..6c2786e 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -98,7 +98,10 @@ all: $(IMAGE) $(XIMAGE)
> >  
> >  CLEANFILES = $(IMAGE) boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb
> >  
> > -$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
> > +if XEN
> > +XEN_IMAGE_DEP = $(XEN_IMAGE)
> > +endif
> > +$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE_DEP)
> >  	$(LD) -o $@ --script=model.lds
> >  
> >  %.o: %.S Makefile
> > -- 
> > 1.7.10.4
> > 
> I fixed this differently, see the 'xen-psci-support-for-upstream' branch in:
> http://git.linaro.org/people/christoffer.dall/boot-wrapper-aarch64.git
> 
> Hopefully you're ok with that change.

Sure.

Ian,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:53:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIzT-0002Zl-Na; Mon, 17 Nov 2014 09:52:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqIzS-0002Zg-Qq
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:52:59 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FC/A2-09936-A75C9645; Mon, 17 Nov 2014 09:52:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416217976!5211982!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2005 invoked from network); 17 Nov 2014 09:52:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:52:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193474122"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 04:52:55 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqIzO-0007ma-H7;
	Mon, 17 Nov 2014 09:52:54 +0000
Date: Mon, 17 Nov 2014 09:52:54 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Message-ID: <20141117095254.GG11070@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416215987-21571-1-git-send-email-cyliu@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 this a regression? Can it wait until 4.6?

On Mon, Nov 17, 2014 at 05:19:47PM +0800, Chunyan Liu wrote:
> Currently libxl__domain_rename only update /local/domain/<domid>/name,
> still some places in xenstore are not updated, including:
> /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> 

I noticed this problem a few days ago and thanks for looking into this.

I have some comments, though.

> Signed-off-by: Chunyan Liu <cyliu@suse.com>
> ---
>  tools/libxl/libxl.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..6671b08 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>      uint32_t stub_dm_domid;
>      const char *stub_dm_old_name = NULL, *stub_dm_new_name = NULL;
>      int rc;
> +    const char *vm_path, *vm_name_path;
> +    char** be_dev = NULL;
> +    unsigned int ndevs = 0;
>  
>      dom_path = libxl__xs_get_dompath(gc, domid);
>      if (!dom_path) goto x_nomem;
> @@ -429,6 +432,58 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>          goto x_fail;
>      }
>  
> +    /* update /vm/<uuid>/name */
> +    vm_path = libxl__xs_read(gc, trans, libxl__sprintf(gc, "%s/vm", dom_path));
> +    vm_name_path = libxl__sprintf(gc, "%s/name", vm_path);
> +    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
> +                   " to %s", new_name, vm_name_path);
> +        goto x_fail;
> +    }
> +
> +
> +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);

The hard-coded 0 cannot work if you have driver domain.

At the very least it should be using LIBXL_TOOLSTACK_DOMID.

> +    if (be_dev && ndevs) {
> +        for (int i = 0; i < ndevs; i++, be_dev++) {
> +            /* <device>: vbd, vif, vkbd, ... */
> +            char** be_dom = NULL;
> +            unsigned int ndoms = 0;
> +            be_dom = libxl__xs_directory(gc, trans,
> +                     GCSPRINTF("/local/domain/0/backend/%s", *be_dev), &ndoms);
> +            if (be_dom && ndoms) {
> +                for (int j = 0; j < ndoms; j++, be_dom++) {
> +                    /* <device>/<domid>: vif/1, vif/2, ...*/
> +                    char ** be_devid = NULL;
> +                    unsigned int ndevids = 0;
> +
> +                    if (strcmp(*be_dom, GCSPRINTF("%d", domid)))
> +                        continue;
> +
> +                    be_devid = libxl__xs_directory(gc, trans,
> +                                     GCSPRINTF("/local/domain/0/backend/%s/%s",
> +                                     *be_dev, *be_dom),
> +                                     &ndevids);
> +                    if (be_devid && ndevids) {
> +                        for (int k = 0; k < ndevids; k++, be_devid++) {
> +                            /* <device>/<domid>/<devid>: vif/1/0, vif/1/1, ... */
> +                            char *tmp = GCSPRINTF("/local/domain/0/backend/%s/%s/%s/domain",
> +                                                  *be_dev, *be_dom, *be_devid);

Same here.

And I would like to request this hunk to be in a separate function if
possible. I got lost when counting the closing "}". ;-)

Wei.

> +                            if (!libxl__xs_read(gc, trans, tmp))
> +                                continue;
> +
> +                            if (libxl__xs_write_checked(gc, trans, tmp, new_name)) {
> +                                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
> +                                           " to %s", new_name, tmp);
> +                                goto x_fail;
> +                            }
> +                        }
> +                    }
> +                }
> +            }
> +        }
> +    }
> +
>      if (stub_dm_domid) {
>          rc = libxl__domain_rename(gc, stub_dm_domid,
>                                    stub_dm_old_name,
> -- 
> 1.8.4.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 09:53:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 09:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqIzT-0002Zl-Na; Mon, 17 Nov 2014 09:52:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqIzS-0002Zg-Qq
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 09:52:59 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FC/A2-09936-A75C9645; Mon, 17 Nov 2014 09:52:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416217976!5211982!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2005 invoked from network); 17 Nov 2014 09:52:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 09:52:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193474122"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 04:52:55 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqIzO-0007ma-H7;
	Mon, 17 Nov 2014 09:52:54 +0000
Date: Mon, 17 Nov 2014 09:52:54 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Message-ID: <20141117095254.GG11070@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416215987-21571-1-git-send-email-cyliu@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 this a regression? Can it wait until 4.6?

On Mon, Nov 17, 2014 at 05:19:47PM +0800, Chunyan Liu wrote:
> Currently libxl__domain_rename only update /local/domain/<domid>/name,
> still some places in xenstore are not updated, including:
> /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> 

I noticed this problem a few days ago and thanks for looking into this.

I have some comments, though.

> Signed-off-by: Chunyan Liu <cyliu@suse.com>
> ---
>  tools/libxl/libxl.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..6671b08 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>      uint32_t stub_dm_domid;
>      const char *stub_dm_old_name = NULL, *stub_dm_new_name = NULL;
>      int rc;
> +    const char *vm_path, *vm_name_path;
> +    char** be_dev = NULL;
> +    unsigned int ndevs = 0;
>  
>      dom_path = libxl__xs_get_dompath(gc, domid);
>      if (!dom_path) goto x_nomem;
> @@ -429,6 +432,58 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>          goto x_fail;
>      }
>  
> +    /* update /vm/<uuid>/name */
> +    vm_path = libxl__xs_read(gc, trans, libxl__sprintf(gc, "%s/vm", dom_path));
> +    vm_name_path = libxl__sprintf(gc, "%s/name", vm_path);
> +    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
> +                   " to %s", new_name, vm_name_path);
> +        goto x_fail;
> +    }
> +
> +
> +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);

The hard-coded 0 cannot work if you have driver domain.

At the very least it should be using LIBXL_TOOLSTACK_DOMID.

> +    if (be_dev && ndevs) {
> +        for (int i = 0; i < ndevs; i++, be_dev++) {
> +            /* <device>: vbd, vif, vkbd, ... */
> +            char** be_dom = NULL;
> +            unsigned int ndoms = 0;
> +            be_dom = libxl__xs_directory(gc, trans,
> +                     GCSPRINTF("/local/domain/0/backend/%s", *be_dev), &ndoms);
> +            if (be_dom && ndoms) {
> +                for (int j = 0; j < ndoms; j++, be_dom++) {
> +                    /* <device>/<domid>: vif/1, vif/2, ...*/
> +                    char ** be_devid = NULL;
> +                    unsigned int ndevids = 0;
> +
> +                    if (strcmp(*be_dom, GCSPRINTF("%d", domid)))
> +                        continue;
> +
> +                    be_devid = libxl__xs_directory(gc, trans,
> +                                     GCSPRINTF("/local/domain/0/backend/%s/%s",
> +                                     *be_dev, *be_dom),
> +                                     &ndevids);
> +                    if (be_devid && ndevids) {
> +                        for (int k = 0; k < ndevids; k++, be_devid++) {
> +                            /* <device>/<domid>/<devid>: vif/1/0, vif/1/1, ... */
> +                            char *tmp = GCSPRINTF("/local/domain/0/backend/%s/%s/%s/domain",
> +                                                  *be_dev, *be_dom, *be_devid);

Same here.

And I would like to request this hunk to be in a separate function if
possible. I got lost when counting the closing "}". ;-)

Wei.

> +                            if (!libxl__xs_read(gc, trans, tmp))
> +                                continue;
> +
> +                            if (libxl__xs_write_checked(gc, trans, tmp, new_name)) {
> +                                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
> +                                           " to %s", new_name, tmp);
> +                                goto x_fail;
> +                            }
> +                        }
> +                    }
> +                }
> +            }
> +        }
> +    }
> +
>      if (stub_dm_domid) {
>          rc = libxl__domain_rename(gc, stub_dm_domid,
>                                    stub_dm_old_name,
> -- 
> 1.8.4.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:06:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJBx-0003LS-Gt; Mon, 17 Nov 2014 10:05:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqJBw-0003LN-IM
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:05:52 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	D4/A2-02559-F78C9645; Mon, 17 Nov 2014 10:05:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416218751!9656399!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13526 invoked from network); 17 Nov 2014 10:05:51 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 10:05:51 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 10:05:50 +0000
Message-Id: <5469D68D0200007800048515@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 10:05:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
In-Reply-To: <5469AA77.2070602@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>       unsigned int used_entries;
>   };
> 
> -static int get_reserved_device_memory(xen_pfn_t start,
> -                                      xen_ulong_t nr, void *ctxt)
> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16 seg,
> +                                      u16 *ids, int cnt, void *ctxt)

While the approach is a lot better than what you did previously, I still
don't like you adding 3 new parameters when one would do (calling
the callback for each SBDF individually): That way you avoid
introducing a hidden dependency on how the VT-d code manages its
internal data.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:06:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJBx-0003LS-Gt; Mon, 17 Nov 2014 10:05:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqJBw-0003LN-IM
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:05:52 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	D4/A2-02559-F78C9645; Mon, 17 Nov 2014 10:05:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416218751!9656399!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13526 invoked from network); 17 Nov 2014 10:05:51 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 10:05:51 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 10:05:50 +0000
Message-Id: <5469D68D0200007800048515@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 10:05:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545354500200007800043D94@mail.emea.novell.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
In-Reply-To: <5469AA77.2070602@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>       unsigned int used_entries;
>   };
> 
> -static int get_reserved_device_memory(xen_pfn_t start,
> -                                      xen_ulong_t nr, void *ctxt)
> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16 seg,
> +                                      u16 *ids, int cnt, void *ctxt)

While the approach is a lot better than what you did previously, I still
don't like you adding 3 new parameters when one would do (calling
the callback for each SBDF individually): That way you avoid
introducing a hidden dependency on how the VT-d code manages its
internal data.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:14:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJJi-0003dn-Ek; Mon, 17 Nov 2014 10:13:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1XqJJg-0003di-Li
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 10:13:52 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	F1/B6-23865-F5AC9645; Mon, 17 Nov 2014 10:13:51 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416219229!9398811!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10639 invoked from network); 17 Nov 2014 10:13:51 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 10:13:51 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAHADk25011966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 17 Nov 2014 05:13:46 -0500
Received: from redhat.com (ovpn-116-95.ams2.redhat.com [10.36.116.95])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sAHADhHF010402; Mon, 17 Nov 2014 05:13:43 -0500
Date: Mon, 17 Nov 2014 12:13:42 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141117101342.GF20133@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
	<20141117061010.GB19718@redhat.com> <5469B660.6040107@intel.com>
	<20141117092501.GA20133@redhat.com> <5469C2F4.4020304@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5469C2F4.4020304@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 05:42:12PM +0800, Chen, Tiejun wrote:
> On 2014/11/17 17:25, Michael S. Tsirkin wrote:
> >On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
> >>On 2014/11/17 14:10, Michael S. Tsirkin wrote:
> >>>On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
> >>>>On 2014/11/5 22:09, Michael S. Tsirkin wrote:
> >>>>>On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
> >>>>>>Currently IGD drivers always need to access PCH by 1f.0, and
> >>>>>>PCH vendor/device id is used to identify the card.
> >>>>>>
> >>>>>>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>>>>>---
> 
> [snip]
> 
> >Cleaner:
> >	 if (!pci_dev) {
> >		fprintf
> >		return;
> >	}
> >          pci_config_set_device_id(pci_dev->config, pch_id);
> 
> I will address all comments and thanks.
> 
> >
> >>+    }
> >>+}
> >>+
> >>  /* init */
> >>
> >>  static int xen_pt_initfn(PCIDevice *d)
> >>@@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
> >>          return -1;
> >>      }
> >>
> >>+    /* Register ISA bridge for passthrough GFX. */
> >>+    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
> >>+
> >>      /* reinitialize each config register to be emulated */
> >>      if (xen_pt_config_init(s)) {
> >>          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
> >>
> >>Note I will introduce a inline function in another patch,
> >>
> >>+static inline int is_vga_passthrough(XenHostPCIDevice *dev)
> >>+{
> >>+    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
> >>+            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
> >>+}
> >>
> >>Thanks
> >>Tiejun
> >
> >Why bother with all these conditions?
> >Won't it be enough to check dev->vendor_id == PCI_VENDOR_ID_INTEL?
> >
> 
> If this is just used for IGD, its always fine without checking vendor_id.

You need to match device ID to *know* it's IGD.

> So after remove that check, I guess I need to rename that as
> is_igd_vga_passthrough() to make sense.
> 
> Thanks
> Tiejun

There is no need to check class code or xen_has_gfx_passthru flag.
Device ID + vendor ID identifies each device uniquely.

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:14:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJJi-0003dn-Ek; Mon, 17 Nov 2014 10:13:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1XqJJg-0003di-Li
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 10:13:52 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	F1/B6-23865-F5AC9645; Mon, 17 Nov 2014 10:13:51 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416219229!9398811!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10639 invoked from network); 17 Nov 2014 10:13:51 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 10:13:51 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAHADk25011966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 17 Nov 2014 05:13:46 -0500
Received: from redhat.com (ovpn-116-95.ams2.redhat.com [10.36.116.95])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sAHADhHF010402; Mon, 17 Nov 2014 05:13:43 -0500
Date: Mon, 17 Nov 2014 12:13:42 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141117101342.GF20133@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
	<20141117061010.GB19718@redhat.com> <5469B660.6040107@intel.com>
	<20141117092501.GA20133@redhat.com> <5469C2F4.4020304@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5469C2F4.4020304@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 05:42:12PM +0800, Chen, Tiejun wrote:
> On 2014/11/17 17:25, Michael S. Tsirkin wrote:
> >On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
> >>On 2014/11/17 14:10, Michael S. Tsirkin wrote:
> >>>On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
> >>>>On 2014/11/5 22:09, Michael S. Tsirkin wrote:
> >>>>>On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
> >>>>>>Currently IGD drivers always need to access PCH by 1f.0, and
> >>>>>>PCH vendor/device id is used to identify the card.
> >>>>>>
> >>>>>>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>>>>>---
> 
> [snip]
> 
> >Cleaner:
> >	 if (!pci_dev) {
> >		fprintf
> >		return;
> >	}
> >          pci_config_set_device_id(pci_dev->config, pch_id);
> 
> I will address all comments and thanks.
> 
> >
> >>+    }
> >>+}
> >>+
> >>  /* init */
> >>
> >>  static int xen_pt_initfn(PCIDevice *d)
> >>@@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
> >>          return -1;
> >>      }
> >>
> >>+    /* Register ISA bridge for passthrough GFX. */
> >>+    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
> >>+
> >>      /* reinitialize each config register to be emulated */
> >>      if (xen_pt_config_init(s)) {
> >>          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
> >>
> >>Note I will introduce a inline function in another patch,
> >>
> >>+static inline int is_vga_passthrough(XenHostPCIDevice *dev)
> >>+{
> >>+    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
> >>+            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
> >>+}
> >>
> >>Thanks
> >>Tiejun
> >
> >Why bother with all these conditions?
> >Won't it be enough to check dev->vendor_id == PCI_VENDOR_ID_INTEL?
> >
> 
> If this is just used for IGD, its always fine without checking vendor_id.

You need to match device ID to *know* it's IGD.

> So after remove that check, I guess I need to rename that as
> is_igd_vga_passthrough() to make sense.
> 
> Thanks
> Tiejun

There is no need to check class code or xen_has_gfx_passthru flag.
Device ID + vendor ID identifies each device uniquely.

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:25:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJV3-0003sA-MP; Mon, 17 Nov 2014 10:25:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqJV1-0003s5-R1
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:25:35 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	1F/F0-02957-F1DC9645; Mon, 17 Nov 2014 10:25:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416219933!12994961!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31266 invoked from network); 17 Nov 2014 10:25:34 -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;
	17 Nov 2014 10:25:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191985889"
Message-ID: <1416219931.27385.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 10:25:31 +0000
In-Reply-To: <20141117095254.GG11070@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Chunyan Liu <cyliu@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> 
> The hard-coded 0 cannot work if you have driver domain.
> 
> At the very least it should be using LIBXL_TOOLSTACK_DOMID.

Does anyone know the purpose of this node, i.e. what consumes it?
docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
xen/include/public/io/*.h AFAICS.

The backend needing to know the name (as opposed to domid) of the
frontend domain seems rather unusual to me.

Perhaps we should just nuke this key?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:25:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJV3-0003sA-MP; Mon, 17 Nov 2014 10:25:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqJV1-0003s5-R1
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:25:35 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	1F/F0-02957-F1DC9645; Mon, 17 Nov 2014 10:25:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416219933!12994961!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31266 invoked from network); 17 Nov 2014 10:25:34 -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;
	17 Nov 2014 10:25:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191985889"
Message-ID: <1416219931.27385.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 10:25:31 +0000
In-Reply-To: <20141117095254.GG11070@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Chunyan Liu <cyliu@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> 
> The hard-coded 0 cannot work if you have driver domain.
> 
> At the very least it should be using LIBXL_TOOLSTACK_DOMID.

Does anyone know the purpose of this node, i.e. what consumes it?
docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
xen/include/public/io/*.h AFAICS.

The backend needing to know the name (as opposed to domid) of the
frontend domain seems rather unusual to me.

Perhaps we should just nuke this key?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:29:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:29:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJYj-000405-9x; Mon, 17 Nov 2014 10:29:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqJYi-000400-IC
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:29:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	58/A0-09936-30EC9645; Mon, 17 Nov 2014 10:29:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416220161!13286555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24569 invoked from network); 17 Nov 2014 10:29:22 -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;
	17 Nov 2014 10:29:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193482158"
Message-ID: <1416220159.27385.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 10:29:19 +0000
In-Reply-To: <20141117094117.GF11070@zion.uk.xensource.com>
References: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141117094117.GF11070@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Chao Peng <chao.p.peng@linux.intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian
	Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: avoid bringing up vcpus already
	online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 09:41 +0000, Wei Liu wrote:
> On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
> > Avoid sending duplicated qmp commands and eliminate the confusing error
> > messages like "Unable to add CPU: 0, it already exists".
> > 
> > Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> > ---
> >  tools/libxl/libxl.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..d040e5c 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -5450,7 +5450,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid,
> >          LOGE(ERROR, "getting domain info list");
> >          return ERROR_FAIL;
> >      }
> > -    for (i = 0; i <= info.vcpu_max_id; i++) {
> > +    for (i = info.vcpu_online; i <= info.vcpu_max_id; i++) {
> 
> I don't think this is right. You're making an assumption that vcpu 0 to
> vcpu "info.vcpu_online" are online, which might not be true in hotplug /
> hot-unplug scenario.

Indeed. Adding Anthony for his input.

> 
> Wei.
> 
> >          if (libxl_bitmap_test(cpumap, i)) {
> >              /* Return value is ignore because it does not tell anything useful
> >               * on the completion of the command.
> > -- 
> > 1.7.9.5



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:29:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:29:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJYj-000405-9x; Mon, 17 Nov 2014 10:29:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqJYi-000400-IC
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:29:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	58/A0-09936-30EC9645; Mon, 17 Nov 2014 10:29:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416220161!13286555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24569 invoked from network); 17 Nov 2014 10:29:22 -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;
	17 Nov 2014 10:29:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193482158"
Message-ID: <1416220159.27385.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 10:29:19 +0000
In-Reply-To: <20141117094117.GF11070@zion.uk.xensource.com>
References: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141117094117.GF11070@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Chao Peng <chao.p.peng@linux.intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian
	Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: avoid bringing up vcpus already
	online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 09:41 +0000, Wei Liu wrote:
> On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
> > Avoid sending duplicated qmp commands and eliminate the confusing error
> > messages like "Unable to add CPU: 0, it already exists".
> > 
> > Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> > ---
> >  tools/libxl/libxl.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..d040e5c 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -5450,7 +5450,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid,
> >          LOGE(ERROR, "getting domain info list");
> >          return ERROR_FAIL;
> >      }
> > -    for (i = 0; i <= info.vcpu_max_id; i++) {
> > +    for (i = info.vcpu_online; i <= info.vcpu_max_id; i++) {
> 
> I don't think this is right. You're making an assumption that vcpu 0 to
> vcpu "info.vcpu_online" are online, which might not be true in hotplug /
> hot-unplug scenario.

Indeed. Adding Anthony for his input.

> 
> Wei.
> 
> >          if (libxl_bitmap_test(cpumap, i)) {
> >              /* Return value is ignore because it does not tell anything useful
> >               * on the completion of the command.
> > -- 
> > 1.7.9.5



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:34:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJe1-0004FL-2h; Mon, 17 Nov 2014 10:34:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqJe0-0004FG-5v
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 10:34:52 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A4/86-23865-B4FC9645; Mon, 17 Nov 2014 10:34:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416220489!11715441!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8003 invoked from network); 17 Nov 2014 10:34:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:34:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191987941"
Message-ID: <1416220487.27385.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Wood <timwood@gwu.edu>
Date: Mon, 17 Nov 2014 10:34:47 +0000
In-Reply-To: <CABm+uF9cqpdqrjbwj3WUaeZXPZsNkCVHdL_=m4xh9MMxKQduUg@mail.gmail.com>
References: <CABm+uF9cqpdqrjbwj3WUaeZXPZsNkCVHdL_=m4xh9MMxKQduUg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Xen devel list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] support for sharing huge pages with grant table?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wrote:
> Hi,
> 
> I am curious if Xen currently supports sharing hugepages between
> domains (specifically ones originally allocated in Dom-0 and shared
> with a guest r/w).  I've seen some references to huge pages in the
> archives of this list, but not in relation to the grant mechanism.

I don't think the grant table has any specific superpage support. It
might be an interesting extension to consider though (for the sorts of
reasons you would like it).

You could grant a superpage using multiple 4K grants to cover whichever
subset of the superpage you need to expose to the other end. Now granted
(no pun intended ;-)) that might suck up 512 grefs in the worst case,
which is a bit mad...

> Also, can someone confirm that "superpages" are another term for "huge
> pages" in Xen?

Yes. Or at least I think so.

> This would be helpful for some work we are doing on high speed
> networking to VMs---DPDK stores packets into huge pages and we'd like
> to get those to VMs as quickly as possible.

This seems like a reasonable usecase to me. Having added this to the
grant table interface I suppose you would also need to consider
extensions to the individual PV I/O protocols (netif.h) to allow them to
signal when a grant was huge. You might have issues with e.g. finding
enough bits to represent the larger sizes...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:34:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJe1-0004FL-2h; Mon, 17 Nov 2014 10:34:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqJe0-0004FG-5v
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 10:34:52 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A4/86-23865-B4FC9645; Mon, 17 Nov 2014 10:34:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416220489!11715441!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8003 invoked from network); 17 Nov 2014 10:34:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:34:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191987941"
Message-ID: <1416220487.27385.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Wood <timwood@gwu.edu>
Date: Mon, 17 Nov 2014 10:34:47 +0000
In-Reply-To: <CABm+uF9cqpdqrjbwj3WUaeZXPZsNkCVHdL_=m4xh9MMxKQduUg@mail.gmail.com>
References: <CABm+uF9cqpdqrjbwj3WUaeZXPZsNkCVHdL_=m4xh9MMxKQduUg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Xen devel list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] support for sharing huge pages with grant table?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wrote:
> Hi,
> 
> I am curious if Xen currently supports sharing hugepages between
> domains (specifically ones originally allocated in Dom-0 and shared
> with a guest r/w).  I've seen some references to huge pages in the
> archives of this list, but not in relation to the grant mechanism.

I don't think the grant table has any specific superpage support. It
might be an interesting extension to consider though (for the sorts of
reasons you would like it).

You could grant a superpage using multiple 4K grants to cover whichever
subset of the superpage you need to expose to the other end. Now granted
(no pun intended ;-)) that might suck up 512 grefs in the worst case,
which is a bit mad...

> Also, can someone confirm that "superpages" are another term for "huge
> pages" in Xen?

Yes. Or at least I think so.

> This would be helpful for some work we are doing on high speed
> networking to VMs---DPDK stores packets into huge pages and we'd like
> to get those to VMs as quickly as possible.

This seems like a reasonable usecase to me. Having added this to the
grant table interface I suppose you would also need to consider
extensions to the individual PV I/O protocols (netif.h) to allow them to
signal when a grant was huge. You might have issues with e.g. finding
enough bits to represent the larger sizes...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:41:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJk6-0004Nt-Ss; Mon, 17 Nov 2014 10:41:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqJk5-0004No-Cb
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:41:09 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	0D/C6-22737-4C0D9645; Mon, 17 Nov 2014 10:41:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416220866!11725147!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24223 invoked from network); 17 Nov 2014 10:41:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:41:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193484505"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 05:41:06 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqJk1-0000KC-Bp;
	Mon, 17 Nov 2014 10:41:05 +0000
Date: Mon, 17 Nov 2014 10:41:05 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141117104105.GH11070@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
	<1416219931.27385.17.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416219931.27385.17.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 10:25:31AM +0000, Ian Campbell wrote:
> On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> > 
> > The hard-coded 0 cannot work if you have driver domain.
> > 
> > At the very least it should be using LIBXL_TOOLSTACK_DOMID.
> 
> Does anyone know the purpose of this node, i.e. what consumes it?
> docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
> xen/include/public/io/*.h AFAICS.
> 
> The backend needing to know the name (as opposed to domid) of the
> frontend domain seems rather unusual to me.
> 

I think it's for consistency but Chunyan might have different opinions.

Wei.

> Perhaps we should just nuke this key?
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:41:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqJk6-0004Nt-Ss; Mon, 17 Nov 2014 10:41:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqJk5-0004No-Cb
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:41:09 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	0D/C6-22737-4C0D9645; Mon, 17 Nov 2014 10:41:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416220866!11725147!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24223 invoked from network); 17 Nov 2014 10:41:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:41:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193484505"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 05:41:06 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqJk1-0000KC-Bp;
	Mon, 17 Nov 2014 10:41:05 +0000
Date: Mon, 17 Nov 2014 10:41:05 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141117104105.GH11070@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
	<1416219931.27385.17.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416219931.27385.17.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 10:25:31AM +0000, Ian Campbell wrote:
> On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> > 
> > The hard-coded 0 cannot work if you have driver domain.
> > 
> > At the very least it should be using LIBXL_TOOLSTACK_DOMID.
> 
> Does anyone know the purpose of this node, i.e. what consumes it?
> docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
> xen/include/public/io/*.h AFAICS.
> 
> The backend needing to know the name (as opposed to domid) of the
> frontend domain seems rather unusual to me.
> 

I think it's for consistency but Chunyan might have different opinions.

Wei.

> Perhaps we should just nuke this key?
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:42:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10: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 1XqJlm-0004ZX-BY; Mon, 17 Nov 2014 10:42:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqJll-0004ZM-D4
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:42:53 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	3D/CA-22737-C21D9645; Mon, 17 Nov 2014 10:42:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416220970!6454684!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16141 invoked from network); 17 Nov 2014 10:42:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:42:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191989154"
Message-ID: <1416220965.27385.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 10:42:45 +0000
In-Reply-To: <20141117104105.GH11070@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
	<1416219931.27385.17.camel@citrix.com>
	<20141117104105.GH11070@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Chunyan Liu <cyliu@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 10:41 +0000, Wei Liu wrote:
> On Mon, Nov 17, 2014 at 10:25:31AM +0000, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > > > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> > > 
> > > The hard-coded 0 cannot work if you have driver domain.
> > > 
> > > At the very least it should be using LIBXL_TOOLSTACK_DOMID.
> > 
> > Does anyone know the purpose of this node, i.e. what consumes it?
> > docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
> > xen/include/public/io/*.h AFAICS.
> > 
> > The backend needing to know the name (as opposed to domid) of the
> > frontend domain seems rather unusual to me.
> > 
> 
> I think it's for consistency but Chunyan might have different opinions.

Consistency of what?

> 
> Wei.
> 
> > Perhaps we should just nuke this key?
> > 
> > Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:42:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10: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 1XqJlm-0004ZX-BY; Mon, 17 Nov 2014 10:42:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqJll-0004ZM-D4
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:42:53 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	3D/CA-22737-C21D9645; Mon, 17 Nov 2014 10:42:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416220970!6454684!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16141 invoked from network); 17 Nov 2014 10:42:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:42:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191989154"
Message-ID: <1416220965.27385.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 10:42:45 +0000
In-Reply-To: <20141117104105.GH11070@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
	<1416219931.27385.17.camel@citrix.com>
	<20141117104105.GH11070@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Chunyan Liu <cyliu@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 10:41 +0000, Wei Liu wrote:
> On Mon, Nov 17, 2014 at 10:25:31AM +0000, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > > > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> > > 
> > > The hard-coded 0 cannot work if you have driver domain.
> > > 
> > > At the very least it should be using LIBXL_TOOLSTACK_DOMID.
> > 
> > Does anyone know the purpose of this node, i.e. what consumes it?
> > docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
> > xen/include/public/io/*.h AFAICS.
> > 
> > The backend needing to know the name (as opposed to domid) of the
> > frontend domain seems rather unusual to me.
> > 
> 
> I think it's for consistency but Chunyan might have different opinions.

Consistency of what?

> 
> Wei.
> 
> > Perhaps we should just nuke this key?
> > 
> > Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:56:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10: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 1XqJy9-0004ph-LI; Mon, 17 Nov 2014 10:55:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1XqJy8-0004pc-IR
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:55:40 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	CE/2A-22737-B24D9645; Mon, 17 Nov 2014 10:55:39 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416221738!11792938!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25079 invoked from network); 17 Nov 2014 10:55:39 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 10:55:39 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 17 Nov 2014 02:55:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="417540718"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Nov 2014 02:46:21 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 17 Nov 2014 18:55:35 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 18:55:34 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: Wei Liu <wei.liu2@citrix.com>
Thread-Topic: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the
	same device more than once
Thread-Index: AdACNky72y6xMRiETWKGh4z36whGWf//oWyA//9uXbA=
Date: Mon, 17 Nov 2014 10:55:34 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E44CF91@shsmsx102.ccr.corp.intel.com>
References: <F2CBF3009FA73547804AE4C663CAB28E44BE59@shsmsx102.ccr.corp.intel.com>
	<20141117093713.GE11070@zion.uk.xensource.com>
In-Reply-To: <20141117093713.GE11070@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the same
 device more than once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > The libxl__device_exists will return 1 if more than one PCI devices are attached to the guest, no matter the BDFs are identical or not.
>
> That means this check is problematic. I think the original intention was to check on BDFs, however it wasn't thoroughly tested. Sorry.
>
> > I don't understand why to check this condition here, if the same 
> > device was attached more than once the xc_test_assign_device() will return error, and the libxl__device_pci_add_xenstore() will not be called. It seems unnecessary.
> > 
>
> It was added to be in line with other devices. However from the look of it PCI devices need special treatment? Do you have some PCI dev backend paths at hand?
>

Backend paths example for tow PCI devices:
/loacal/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
/loacal/domain/0/backend/pci/9/0/key-1/0000:03:10.1

/loacal/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
/loacal/domain/0/backend/pci/9/0/key-2/0000:03:10.2

These paths can help to identify the PCI devices. But I don't think it is a good idea to check all the PCI devices in the backend paths.

> Does reverting the said patch help?

> Wei.


I just remove the if (rc == 1) condition check and it works ok.

Liang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:56:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10: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 1XqJy9-0004ph-LI; Mon, 17 Nov 2014 10:55:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1XqJy8-0004pc-IR
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:55:40 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	CE/2A-22737-B24D9645; Mon, 17 Nov 2014 10:55:39 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416221738!11792938!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25079 invoked from network); 17 Nov 2014 10:55:39 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 10:55:39 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 17 Nov 2014 02:55:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="417540718"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Nov 2014 02:46:21 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 17 Nov 2014 18:55:35 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 18:55:34 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: Wei Liu <wei.liu2@citrix.com>
Thread-Topic: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the
	same device more than once
Thread-Index: AdACNky72y6xMRiETWKGh4z36whGWf//oWyA//9uXbA=
Date: Mon, 17 Nov 2014 10:55:34 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E44CF91@shsmsx102.ccr.corp.intel.com>
References: <F2CBF3009FA73547804AE4C663CAB28E44BE59@shsmsx102.ccr.corp.intel.com>
	<20141117093713.GE11070@zion.uk.xensource.com>
In-Reply-To: <20141117093713.GE11070@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the same
 device more than once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > The libxl__device_exists will return 1 if more than one PCI devices are attached to the guest, no matter the BDFs are identical or not.
>
> That means this check is problematic. I think the original intention was to check on BDFs, however it wasn't thoroughly tested. Sorry.
>
> > I don't understand why to check this condition here, if the same 
> > device was attached more than once the xc_test_assign_device() will return error, and the libxl__device_pci_add_xenstore() will not be called. It seems unnecessary.
> > 
>
> It was added to be in line with other devices. However from the look of it PCI devices need special treatment? Do you have some PCI dev backend paths at hand?
>

Backend paths example for tow PCI devices:
/loacal/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
/loacal/domain/0/backend/pci/9/0/key-1/0000:03:10.1

/loacal/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
/loacal/domain/0/backend/pci/9/0/key-2/0000:03:10.2

These paths can help to identify the PCI devices. But I don't think it is a good idea to check all the PCI devices in the backend paths.

> Does reverting the said patch help?

> Wei.


I just remove the if (rc == 1) condition check and it works ok.

Liang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:57:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:57:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqK0H-0004x8-BU; Mon, 17 Nov 2014 10:57:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqK0F-0004x2-HJ
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:57:51 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	79/A6-02697-EA4D9645; Mon, 17 Nov 2014 10:57:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416221868!11793467!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8134 invoked from network); 17 Nov 2014 10:57:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:57:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191992321"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 05:57:22 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqJqx-0000k9-U9;
	Mon, 17 Nov 2014 10:48:15 +0000
Date: Mon, 17 Nov 2014 10:48:15 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141117104815.GA22480@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
	<1416219931.27385.17.camel@citrix.com>
	<20141117104105.GH11070@zion.uk.xensource.com>
	<1416220965.27385.23.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416220965.27385.23.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 10:42:45AM +0000, Ian Campbell wrote:
> On Mon, 2014-11-17 at 10:41 +0000, Wei Liu wrote:
> > On Mon, Nov 17, 2014 at 10:25:31AM +0000, Ian Campbell wrote:
> > > On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > > > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > > > > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> > > > 
> > > > The hard-coded 0 cannot work if you have driver domain.
> > > > 
> > > > At the very least it should be using LIBXL_TOOLSTACK_DOMID.
> > > 
> > > Does anyone know the purpose of this node, i.e. what consumes it?
> > > docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
> > > xen/include/public/io/*.h AFAICS.
> > > 
> > > The backend needing to know the name (as opposed to domid) of the
> > > frontend domain seems rather unusual to me.
> > > 
> > 
> > I think it's for consistency but Chunyan might have different opinions.
> 
> Consistency of what?
> 

Say, when you look at backend path, it shows the frontend domain has
name of "blah--incoming" because it's migrated; however, in
/local/domain/$DOMID/ there's a different name "blah".

Wei.

> > 
> > Wei.
> > 
> > > Perhaps we should just nuke this key?
> > > 
> > > Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:57:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:57:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqK0H-0004x8-BU; Mon, 17 Nov 2014 10:57:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqK0F-0004x2-HJ
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:57:51 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	79/A6-02697-EA4D9645; Mon, 17 Nov 2014 10:57:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416221868!11793467!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8134 invoked from network); 17 Nov 2014 10:57:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:57:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191992321"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 05:57:22 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqJqx-0000k9-U9;
	Mon, 17 Nov 2014 10:48:15 +0000
Date: Mon, 17 Nov 2014 10:48:15 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141117104815.GA22480@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
	<1416219931.27385.17.camel@citrix.com>
	<20141117104105.GH11070@zion.uk.xensource.com>
	<1416220965.27385.23.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416220965.27385.23.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 10:42:45AM +0000, Ian Campbell wrote:
> On Mon, 2014-11-17 at 10:41 +0000, Wei Liu wrote:
> > On Mon, Nov 17, 2014 at 10:25:31AM +0000, Ian Campbell wrote:
> > > On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > > > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > > > > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> > > > 
> > > > The hard-coded 0 cannot work if you have driver domain.
> > > > 
> > > > At the very least it should be using LIBXL_TOOLSTACK_DOMID.
> > > 
> > > Does anyone know the purpose of this node, i.e. what consumes it?
> > > docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
> > > xen/include/public/io/*.h AFAICS.
> > > 
> > > The backend needing to know the name (as opposed to domid) of the
> > > frontend domain seems rather unusual to me.
> > > 
> > 
> > I think it's for consistency but Chunyan might have different opinions.
> 
> Consistency of what?
> 

Say, when you look at backend path, it shows the frontend domain has
name of "blah--incoming" because it's migrated; however, in
/local/domain/$DOMID/ there's a different name "blah".

Wei.

> > 
> > Wei.
> > 
> > > Perhaps we should just nuke this key?
> > > 
> > > Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:58:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:58:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqK1E-00052X-PT; Mon, 17 Nov 2014 10:58: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 1XqK1D-00052D-DJ
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:58:51 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	A4/EA-19763-AE4D9645; Mon, 17 Nov 2014 10:58:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416221928!11736641!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30402 invoked from network); 17 Nov 2014 10:58:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:58:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191992558"
Message-ID: <1416221926.27385.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 10:58:46 +0000
In-Reply-To: <1416220965.27385.23.camel@citrix.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
	<1416219931.27385.17.camel@citrix.com>
	<20141117104105.GH11070@zion.uk.xensource.com>
	<1416220965.27385.23.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Chunyan Liu <cyliu@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 10:42 +0000, Ian Campbell wrote:
> On Mon, 2014-11-17 at 10:41 +0000, Wei Liu wrote:
> > On Mon, Nov 17, 2014 at 10:25:31AM +0000, Ian Campbell wrote:
> > > On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > > > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > > > > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> > > > 
> > > > The hard-coded 0 cannot work if you have driver domain.
> > > > 
> > > > At the very least it should be using LIBXL_TOOLSTACK_DOMID.
> > > 
> > > Does anyone know the purpose of this node, i.e. what consumes it?
> > > docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
> > > xen/include/public/io/*.h AFAICS.
> > > 
> > > The backend needing to know the name (as opposed to domid) of the
> > > frontend domain seems rather unusual to me.
> > > 
> > 
> > I think it's for consistency but Chunyan might have different opinions.
> 
> Consistency of what?

Dunno if this is relevant but I appear to have this node only for pci
and console backend directories, and not for vbd or vif.

I quick grep for domain\" in both linux/drivers/xen/xen-pciback and
xen/tools/console seems to suggest neither of them are reading it.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:58:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:58:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqK1E-00052X-PT; Mon, 17 Nov 2014 10:58: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 1XqK1D-00052D-DJ
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:58:51 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	A4/EA-19763-AE4D9645; Mon, 17 Nov 2014 10:58:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416221928!11736641!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30402 invoked from network); 17 Nov 2014 10:58:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:58:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191992558"
Message-ID: <1416221926.27385.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 10:58:46 +0000
In-Reply-To: <1416220965.27385.23.camel@citrix.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
	<1416219931.27385.17.camel@citrix.com>
	<20141117104105.GH11070@zion.uk.xensource.com>
	<1416220965.27385.23.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Chunyan Liu <cyliu@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 10:42 +0000, Ian Campbell wrote:
> On Mon, 2014-11-17 at 10:41 +0000, Wei Liu wrote:
> > On Mon, Nov 17, 2014 at 10:25:31AM +0000, Ian Campbell wrote:
> > > On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > > > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > > > > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> > > > 
> > > > The hard-coded 0 cannot work if you have driver domain.
> > > > 
> > > > At the very least it should be using LIBXL_TOOLSTACK_DOMID.
> > > 
> > > Does anyone know the purpose of this node, i.e. what consumes it?
> > > docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
> > > xen/include/public/io/*.h AFAICS.
> > > 
> > > The backend needing to know the name (as opposed to domid) of the
> > > frontend domain seems rather unusual to me.
> > > 
> > 
> > I think it's for consistency but Chunyan might have different opinions.
> 
> Consistency of what?

Dunno if this is relevant but I appear to have this node only for pci
and console backend directories, and not for vbd or vif.

I quick grep for domain\" in both linux/drivers/xen/xen-pciback and
xen/tools/console seems to suggest neither of them are reading it.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:59:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:59:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqK1y-00058N-7Y; Mon, 17 Nov 2014 10:59: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 1XqK1w-00058B-Vx
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:59:37 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	84/C5-26652-815D9645; Mon, 17 Nov 2014 10:59:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416221974!6341459!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24511 invoked from network); 17 Nov 2014 10:59:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:59:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193488227"
Message-ID: <1416221972.27385.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 10:59:32 +0000
In-Reply-To: <20141117104815.GA22480@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
	<1416219931.27385.17.camel@citrix.com>
	<20141117104105.GH11070@zion.uk.xensource.com>
	<1416220965.27385.23.camel@citrix.com>
	<20141117104815.GA22480@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, Chunyan Liu <cyliu@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 10:48 +0000, Wei Liu wrote:
> On Mon, Nov 17, 2014 at 10:42:45AM +0000, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 10:41 +0000, Wei Liu wrote:
> > > On Mon, Nov 17, 2014 at 10:25:31AM +0000, Ian Campbell wrote:
> > > > On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > > > > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > > > > > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> > > > > 
> > > > > The hard-coded 0 cannot work if you have driver domain.
> > > > > 
> > > > > At the very least it should be using LIBXL_TOOLSTACK_DOMID.
> > > > 
> > > > Does anyone know the purpose of this node, i.e. what consumes it?
> > > > docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
> > > > xen/include/public/io/*.h AFAICS.
> > > > 
> > > > The backend needing to know the name (as opposed to domid) of the
> > > > frontend domain seems rather unusual to me.
> > > > 
> > > 
> > > I think it's for consistency but Chunyan might have different opinions.
> > 
> > Consistency of what?
> > 
> 
> Say, when you look at backend path, it shows the frontend domain has
> name of "blah--incoming" because it's migrated; however, in
> /local/domain/$DOMID/ there's a different name "blah".

I'm suggesting we nuke this key entirely because it is meaningless, not
questioning the need for it to be correct if we keep it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 10:59:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 10:59:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqK1y-00058N-7Y; Mon, 17 Nov 2014 10:59: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 1XqK1w-00058B-Vx
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 10:59:37 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	84/C5-26652-815D9645; Mon, 17 Nov 2014 10:59:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416221974!6341459!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24511 invoked from network); 17 Nov 2014 10:59:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 10:59:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193488227"
Message-ID: <1416221972.27385.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 17 Nov 2014 10:59:32 +0000
In-Reply-To: <20141117104815.GA22480@zion.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<20141117095254.GG11070@zion.uk.xensource.com>
	<1416219931.27385.17.camel@citrix.com>
	<20141117104105.GH11070@zion.uk.xensource.com>
	<1416220965.27385.23.camel@citrix.com>
	<20141117104815.GA22480@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, Chunyan Liu <cyliu@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 10:48 +0000, Wei Liu wrote:
> On Mon, Nov 17, 2014 at 10:42:45AM +0000, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 10:41 +0000, Wei Liu wrote:
> > > On Mon, Nov 17, 2014 at 10:25:31AM +0000, Ian Campbell wrote:
> > > > On Mon, 2014-11-17 at 09:52 +0000, Wei Liu wrote:
> > > > > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> > > > > > +    be_dev = libxl__xs_directory(gc, trans, "/local/domain/0/backend", &ndevs);
> > > > > 
> > > > > The hard-coded 0 cannot work if you have driver domain.
> > > > > 
> > > > > At the very least it should be using LIBXL_TOOLSTACK_DOMID.
> > > > 
> > > > Does anyone know the purpose of this node, i.e. what consumes it?
> > > > docs/misc/xenstore-paths.markdown doesn't mention it, neither do any of
> > > > xen/include/public/io/*.h AFAICS.
> > > > 
> > > > The backend needing to know the name (as opposed to domid) of the
> > > > frontend domain seems rather unusual to me.
> > > > 
> > > 
> > > I think it's for consistency but Chunyan might have different opinions.
> > 
> > Consistency of what?
> > 
> 
> Say, when you look at backend path, it shows the frontend domain has
> name of "blah--incoming" because it's migrated; however, in
> /local/domain/$DOMID/ there's a different name "blah".

I'm suggesting we nuke this key entirely because it is meaningless, not
questioning the need for it to be correct if we keep it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:04:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:04:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqK6h-0005V2-0w; Mon, 17 Nov 2014 11:04: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 1XqK6f-0005Uw-8E
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 11:04:29 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	6B/04-09284-C36D9645; Mon, 17 Nov 2014 11:04:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416222266!11874388!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10017 invoked from network); 17 Nov 2014 11:04:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:04:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193489464"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 06:03:47 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqK5z-0001R8-7q;
	Mon, 17 Nov 2014 11:03:47 +0000
Date: Mon, 17 Nov 2014 11:03:47 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Li, Liang Z" <liang.z.li@intel.com>
Message-ID: <20141117110346.GB22480@zion.uk.xensource.com>
References: <F2CBF3009FA73547804AE4C663CAB28E44BE59@shsmsx102.ccr.corp.intel.com>
	<20141117093713.GE11070@zion.uk.xensource.com>
	<F2CBF3009FA73547804AE4C663CAB28E44CF91@shsmsx102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E44CF91@shsmsx102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the same
 device more than once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 10:55:34AM +0000, Li, Liang Z wrote:
> > > The libxl__device_exists will return 1 if more than one PCI devices are attached to the guest, no matter the BDFs are identical or not.
> >
> > That means this check is problematic. I think the original intention was to check on BDFs, however it wasn't thoroughly tested. Sorry.
> >
> > > I don't understand why to check this condition here, if the same 
> > > device was attached more than once the xc_test_assign_device() will return error, and the libxl__device_pci_add_xenstore() will not be called. It seems unnecessary.
> > > 
> >
> > It was added to be in line with other devices. However from the look of it PCI devices need special treatment? Do you have some PCI dev backend paths at hand?
> >
> 
> Backend paths example for tow PCI devices:
> /loacal/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> /loacal/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> 
> /loacal/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> /loacal/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> 
> These paths can help to identify the PCI devices. But I don't think it is a good idea to check all the PCI devices in the backend paths.
> 

So that means that PCI devices have different rules when constructing
backend path. And the check should adapt to these rules.

> > Does reverting the said patch help?
> 
> > Wei.
> 
> 
> I just remove the if (rc == 1) condition check and it works ok.
> 

This is basically reverting that patch.

This is a regression, right? I'm thinking about reverting the hunk to
check device existence at this point and deal with it in 4.6.

Wei.

> Liang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:04:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:04:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqK6h-0005V2-0w; Mon, 17 Nov 2014 11:04: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 1XqK6f-0005Uw-8E
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 11:04:29 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	6B/04-09284-C36D9645; Mon, 17 Nov 2014 11:04:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416222266!11874388!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10017 invoked from network); 17 Nov 2014 11:04:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:04:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193489464"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 06:03:47 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqK5z-0001R8-7q;
	Mon, 17 Nov 2014 11:03:47 +0000
Date: Mon, 17 Nov 2014 11:03:47 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Li, Liang Z" <liang.z.li@intel.com>
Message-ID: <20141117110346.GB22480@zion.uk.xensource.com>
References: <F2CBF3009FA73547804AE4C663CAB28E44BE59@shsmsx102.ccr.corp.intel.com>
	<20141117093713.GE11070@zion.uk.xensource.com>
	<F2CBF3009FA73547804AE4C663CAB28E44CF91@shsmsx102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E44CF91@shsmsx102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the same
 device more than once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 10:55:34AM +0000, Li, Liang Z wrote:
> > > The libxl__device_exists will return 1 if more than one PCI devices are attached to the guest, no matter the BDFs are identical or not.
> >
> > That means this check is problematic. I think the original intention was to check on BDFs, however it wasn't thoroughly tested. Sorry.
> >
> > > I don't understand why to check this condition here, if the same 
> > > device was attached more than once the xc_test_assign_device() will return error, and the libxl__device_pci_add_xenstore() will not be called. It seems unnecessary.
> > > 
> >
> > It was added to be in line with other devices. However from the look of it PCI devices need special treatment? Do you have some PCI dev backend paths at hand?
> >
> 
> Backend paths example for tow PCI devices:
> /loacal/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> /loacal/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> 
> /loacal/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> /loacal/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> 
> These paths can help to identify the PCI devices. But I don't think it is a good idea to check all the PCI devices in the backend paths.
> 

So that means that PCI devices have different rules when constructing
backend path. And the check should adapt to these rules.

> > Does reverting the said patch help?
> 
> > Wei.
> 
> 
> I just remove the if (rc == 1) condition check and it works ok.
> 

This is basically reverting that patch.

This is a regression, right? I'm thinking about reverting the hunk to
check device existence at this point and deal with it in 4.6.

Wei.

> Liang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:05:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11: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 1XqK7Y-0005ZQ-Ik; Mon, 17 Nov 2014 11:05:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1XqK7W-0005Yw-Cs; Mon, 17 Nov 2014 11:05:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FE/92-09842-176D9645; Mon, 17 Nov 2014 11:05:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416222320!13246640!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24288 invoked from network); 17 Nov 2014 11:05:20 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:05:20 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so5299531wid.9
	for <multiple recipients>; Mon, 17 Nov 2014 03:05:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:subject:date:message-id:cc:to:mime-version;
	bh=+yal1sy7DXffIUirBkNUjNMlse2+uukpPnyl6K//qFg=;
	b=LP9vLy0pACp1binQbfUKqyHSFvgRrX1IzJG3w2VXk8cUAbUFYct0oIukvf3yZYDZLh
	2BJuwf11YCSXKiqKGHUOeGYFjjwO004RJJNfvA7WQMeiVoeJK2rXiOi5J7jJqKTgTOG2
	g+LbavoWXeJenYGhhsNVLSiEXtjt8o3ZxI1itPe1cEsfOpvzYB0dyHgVNOIpblcAzuRP
	XDm2hFmk6h559AoPln1+fKchfPwuWlchnpkm0W2TLBWPZjmFIcn0I+/xtY4dsN3i+OMT
	E7SGrSS1zg1uMLmt4KTM9GsK95bGka+ZAz0sVBfx0+IDJ3XdZu017v3MCGXbL52YsYQY
	fYqQ==
X-Received: by 10.180.100.104 with SMTP id ex8mr29396830wib.80.1416222318888; 
	Mon, 17 Nov 2014 03:05:18 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id f7sm14786272wiz.13.2014.11.17.03.05.17
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 17 Nov 2014 03:05:18 -0800 (PST)
From: Lars Kurth <lars.kurth.xen@gmail.com>
Date: Mon, 17 Nov 2014 11:05:14 +0000
Message-Id: <BF4D4F25-A2E3-41F3-AD80-BFC210BB269E@gmail.com>
To: publicity@lists.xenproject.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: [Xen-devel] CfP for LF Collab Summit, closes December 8, 2014
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7011533056440791752=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7011533056440791752==
Content-Type: multipart/alternative; boundary="Apple-Mail=_88D74602-161A-466F-A019-841B56679443"


--Apple-Mail=_88D74602-161A-466F-A019-841B56679443
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

See =
http://events.linuxfoundation.org/events/collaboration-summit/program/cfp
It would be great if we had a number of Xen related submissions=20

As an aside:
* I arranged for 1/2 day public Xen track=20
* And a 1/2 day of space for private meetings for members of the Xen =
community planning to come to Collab Summit

Best Regards
Lars=

--Apple-Mail=_88D74602-161A-466F-A019-841B56679443
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">See&nbsp;<a href="http://events.linuxfoundation.org/events/collaboration-summit/program/cfp">http://events.linuxfoundation.org/events/collaboration-summit/program/cfp</a><div>It would be great if we had a number of Xen related submissions&nbsp;<br><div><br></div><div>As an aside:</div><div>* I arranged for 1/2 day public Xen track&nbsp;</div><div>* And a 1/2 day of space for private meetings for members of the Xen community planning to come to Collab Summit</div><div><br></div><div>Best Regards</div><div>Lars</div></div></body></html>
--Apple-Mail=_88D74602-161A-466F-A019-841B56679443--


--===============7011533056440791752==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7011533056440791752==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 11:05:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11: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 1XqK7Y-0005ZQ-Ik; Mon, 17 Nov 2014 11:05:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1XqK7W-0005Yw-Cs; Mon, 17 Nov 2014 11:05:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FE/92-09842-176D9645; Mon, 17 Nov 2014 11:05:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416222320!13246640!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24288 invoked from network); 17 Nov 2014 11:05:20 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:05:20 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so5299531wid.9
	for <multiple recipients>; Mon, 17 Nov 2014 03:05:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:subject:date:message-id:cc:to:mime-version;
	bh=+yal1sy7DXffIUirBkNUjNMlse2+uukpPnyl6K//qFg=;
	b=LP9vLy0pACp1binQbfUKqyHSFvgRrX1IzJG3w2VXk8cUAbUFYct0oIukvf3yZYDZLh
	2BJuwf11YCSXKiqKGHUOeGYFjjwO004RJJNfvA7WQMeiVoeJK2rXiOi5J7jJqKTgTOG2
	g+LbavoWXeJenYGhhsNVLSiEXtjt8o3ZxI1itPe1cEsfOpvzYB0dyHgVNOIpblcAzuRP
	XDm2hFmk6h559AoPln1+fKchfPwuWlchnpkm0W2TLBWPZjmFIcn0I+/xtY4dsN3i+OMT
	E7SGrSS1zg1uMLmt4KTM9GsK95bGka+ZAz0sVBfx0+IDJ3XdZu017v3MCGXbL52YsYQY
	fYqQ==
X-Received: by 10.180.100.104 with SMTP id ex8mr29396830wib.80.1416222318888; 
	Mon, 17 Nov 2014 03:05:18 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id f7sm14786272wiz.13.2014.11.17.03.05.17
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 17 Nov 2014 03:05:18 -0800 (PST)
From: Lars Kurth <lars.kurth.xen@gmail.com>
Date: Mon, 17 Nov 2014 11:05:14 +0000
Message-Id: <BF4D4F25-A2E3-41F3-AD80-BFC210BB269E@gmail.com>
To: publicity@lists.xenproject.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: [Xen-devel] CfP for LF Collab Summit, closes December 8, 2014
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7011533056440791752=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7011533056440791752==
Content-Type: multipart/alternative; boundary="Apple-Mail=_88D74602-161A-466F-A019-841B56679443"


--Apple-Mail=_88D74602-161A-466F-A019-841B56679443
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

See =
http://events.linuxfoundation.org/events/collaboration-summit/program/cfp
It would be great if we had a number of Xen related submissions=20

As an aside:
* I arranged for 1/2 day public Xen track=20
* And a 1/2 day of space for private meetings for members of the Xen =
community planning to come to Collab Summit

Best Regards
Lars=

--Apple-Mail=_88D74602-161A-466F-A019-841B56679443
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">See&nbsp;<a href="http://events.linuxfoundation.org/events/collaboration-summit/program/cfp">http://events.linuxfoundation.org/events/collaboration-summit/program/cfp</a><div>It would be great if we had a number of Xen related submissions&nbsp;<br><div><br></div><div>As an aside:</div><div>* I arranged for 1/2 day public Xen track&nbsp;</div><div>* And a 1/2 day of space for private meetings for members of the Xen community planning to come to Collab Summit</div><div><br></div><div>Best Regards</div><div>Lars</div></div></body></html>
--Apple-Mail=_88D74602-161A-466F-A019-841B56679443--


--===============7011533056440791752==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7011533056440791752==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 11:09:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKB6-0005mt-Ac; Mon, 17 Nov 2014 11:09:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqKB4-0005mo-BF
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 11:09:03 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	A4/83-02698-D47D9645; Mon, 17 Nov 2014 11:09:01 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416222540!12441811!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22468 invoked from network); 17 Nov 2014 11:09:01 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 11:09:01 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 17 Nov 2014 03:06:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,402,1413270000"; d="scan'208";a="609033639"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 03:08:58 -0800
Message-ID: <5469D749.2040807@intel.com>
Date: Mon, 17 Nov 2014 19:08:57 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
In-Reply-To: <5469D68D0200007800048515@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 2014/11/17 18:05, Jan Beulich wrote:
>>>> On 17.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>>        unsigned int used_entries;
>>    };
>>
>> -static int get_reserved_device_memory(xen_pfn_t start,
>> -                                      xen_ulong_t nr, void *ctxt)
>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16 seg,
>> +                                      u16 *ids, int cnt, void *ctxt)
>
> While the approach is a lot better than what you did previously, I still
> don't like you adding 3 new parameters when one would do (calling
> the callback for each SBDF individually): That way you avoid

Do you mean I should do this?

for_each_rmrr_device ( rmrr, bdf, i )
{
	 sbdf = PCI_SBDF(seg, rmrr->scope.devices[i]);
          rc = func(PFN_DOWN(rmrr->base_address),
                    PFN_UP(rmrr->end_address) - 
PFN_DOWN(rmrr->base_address),
		   sbdf,	
                    ctxt);

But each different sbdf may occupy one same rmrr entry as I said 
previously, so we have to introduce more codes to filter them as one 
identified entry in the callback.

Thanks
Tiejun

> introducing a hidden dependency on how the VT-d code manages its
> internal data.
>
> Jan
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:09:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKB6-0005mt-Ac; Mon, 17 Nov 2014 11:09:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqKB4-0005mo-BF
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 11:09:03 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	A4/83-02698-D47D9645; Mon, 17 Nov 2014 11:09:01 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416222540!12441811!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22468 invoked from network); 17 Nov 2014 11:09:01 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 11:09:01 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 17 Nov 2014 03:06:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,402,1413270000"; d="scan'208";a="609033639"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 03:08:58 -0800
Message-ID: <5469D749.2040807@intel.com>
Date: Mon, 17 Nov 2014 19:08:57 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
In-Reply-To: <5469D68D0200007800048515@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 2014/11/17 18:05, Jan Beulich wrote:
>>>> On 17.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>>        unsigned int used_entries;
>>    };
>>
>> -static int get_reserved_device_memory(xen_pfn_t start,
>> -                                      xen_ulong_t nr, void *ctxt)
>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16 seg,
>> +                                      u16 *ids, int cnt, void *ctxt)
>
> While the approach is a lot better than what you did previously, I still
> don't like you adding 3 new parameters when one would do (calling
> the callback for each SBDF individually): That way you avoid

Do you mean I should do this?

for_each_rmrr_device ( rmrr, bdf, i )
{
	 sbdf = PCI_SBDF(seg, rmrr->scope.devices[i]);
          rc = func(PFN_DOWN(rmrr->base_address),
                    PFN_UP(rmrr->end_address) - 
PFN_DOWN(rmrr->base_address),
		   sbdf,	
                    ctxt);

But each different sbdf may occupy one same rmrr entry as I said 
previously, so we have to introduce more codes to filter them as one 
identified entry in the callback.

Thanks
Tiejun

> introducing a hidden dependency on how the VT-d code manages its
> internal data.
>
> Jan
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:17:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKIz-000662-8F; Mon, 17 Nov 2014 11:17:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqKIx-00065x-LQ
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 11:17:11 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	A0/9E-26858-639D9645; Mon, 17 Nov 2014 11:17:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416223030!11884607!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9791 invoked from network); 17 Nov 2014 11:17:10 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 11:17:10 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 11:17:09 +0000
Message-Id: <5469E74302000078000485B0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 11:17:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
In-Reply-To: <5469D749.2040807@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 12:08, <tiejun.chen@intel.com> wrote:

> On 2014/11/17 18:05, Jan Beulich wrote:
>>>>> On 17.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>>>        unsigned int used_entries;
>>>    };
>>>
>>> -static int get_reserved_device_memory(xen_pfn_t start,
>>> -                                      xen_ulong_t nr, void *ctxt)
>>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16 
> seg,
>>> +                                      u16 *ids, int cnt, void *ctxt)
>>
>> While the approach is a lot better than what you did previously, I still
>> don't like you adding 3 new parameters when one would do (calling
>> the callback for each SBDF individually): That way you avoid
> 
> Do you mean I should do this?
> 
> for_each_rmrr_device ( rmrr, bdf, i )
> {
> 	 sbdf = PCI_SBDF(seg, rmrr->scope.devices[i]);
>           rc = func(PFN_DOWN(rmrr->base_address),
>                     PFN_UP(rmrr->end_address) - 
> PFN_DOWN(rmrr->base_address),
> 		   sbdf,	
>                     ctxt);
> 
> But each different sbdf may occupy one same rmrr entry as I said 
> previously, so we have to introduce more codes to filter them as one 
> identified entry in the callback.

Not really - remember that part of what needs to be done is to make
sure all devices associated with a given RMRR get assigned to the
same guest? Or the callback function could use a special return value
(e.g. 1) to signal that the iteration for the current RMRR can be
terminated (or further entries skipped).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:17:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKIz-000662-8F; Mon, 17 Nov 2014 11:17:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqKIx-00065x-LQ
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 11:17:11 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	A0/9E-26858-639D9645; Mon, 17 Nov 2014 11:17:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416223030!11884607!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9791 invoked from network); 17 Nov 2014 11:17:10 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 11:17:10 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 11:17:09 +0000
Message-Id: <5469E74302000078000485B0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 11:17:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
In-Reply-To: <5469D749.2040807@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 12:08, <tiejun.chen@intel.com> wrote:

> On 2014/11/17 18:05, Jan Beulich wrote:
>>>>> On 17.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>>>        unsigned int used_entries;
>>>    };
>>>
>>> -static int get_reserved_device_memory(xen_pfn_t start,
>>> -                                      xen_ulong_t nr, void *ctxt)
>>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16 
> seg,
>>> +                                      u16 *ids, int cnt, void *ctxt)
>>
>> While the approach is a lot better than what you did previously, I still
>> don't like you adding 3 new parameters when one would do (calling
>> the callback for each SBDF individually): That way you avoid
> 
> Do you mean I should do this?
> 
> for_each_rmrr_device ( rmrr, bdf, i )
> {
> 	 sbdf = PCI_SBDF(seg, rmrr->scope.devices[i]);
>           rc = func(PFN_DOWN(rmrr->base_address),
>                     PFN_UP(rmrr->end_address) - 
> PFN_DOWN(rmrr->base_address),
> 		   sbdf,	
>                     ctxt);
> 
> But each different sbdf may occupy one same rmrr entry as I said 
> previously, so we have to introduce more codes to filter them as one 
> identified entry in the callback.

Not really - remember that part of what needs to be done is to make
sure all devices associated with a given RMRR get assigned to the
same guest? Or the callback function could use a special return value
(e.g. 1) to signal that the iteration for the current RMRR can be
terminated (or further entries skipped).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:18:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKKD-0006AY-Mv; Mon, 17 Nov 2014 11:18:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqKKB-0006AL-Pv
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 11:18:27 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	E1/44-27785-389D9645; Mon, 17 Nov 2014 11:18:27 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416223101!13010299!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18457 invoked from network); 17 Nov 2014 11:18:22 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 11:18:22 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 17 Nov 2014 03:15:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,402,1413270000"; d="scan'208";a="609037194"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 03:18:18 -0800
Message-ID: <5469D979.8050404@intel.com>
Date: Mon, 17 Nov 2014 19:18:17 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
	<20141117061010.GB19718@redhat.com> <5469B660.6040107@intel.com>
	<20141117092501.GA20133@redhat.com> <5469C2F4.4020304@intel.com>
	<20141117101342.GF20133@redhat.com>
In-Reply-To: <20141117101342.GF20133@redhat.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/17 18:13, Michael S. Tsirkin wrote:
> On Mon, Nov 17, 2014 at 05:42:12PM +0800, Chen, Tiejun wrote:
>> On 2014/11/17 17:25, Michael S. Tsirkin wrote:
>>> On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
>>>> On 2014/11/17 14:10, Michael S. Tsirkin wrote:
>>>>> On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/11/5 22:09, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
>>>>>>>> Currently IGD drivers always need to access PCH by 1f.0, and
>>>>>>>> PCH vendor/device id is used to identify the card.
>>>>>>>>
>>>>>>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>>>>>>> ---
>>
>> [snip]
>>
>>> Cleaner:
>>> 	 if (!pci_dev) {
>>> 		fprintf
>>> 		return;
>>> 	}
>>>           pci_config_set_device_id(pci_dev->config, pch_id);
>>
>> I will address all comments and thanks.
>>
>>>
>>>> +    }
>>>> +}
>>>> +
>>>>   /* init */
>>>>
>>>>   static int xen_pt_initfn(PCIDevice *d)
>>>> @@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
>>>>           return -1;
>>>>       }
>>>>
>>>> +    /* Register ISA bridge for passthrough GFX. */
>>>> +    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
>>>> +
>>>>       /* reinitialize each config register to be emulated */
>>>>       if (xen_pt_config_init(s)) {
>>>>           XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
>>>>
>>>> Note I will introduce a inline function in another patch,
>>>>
>>>> +static inline int is_vga_passthrough(XenHostPCIDevice *dev)
>>>> +{
>>>> +    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
>>>> +            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
>>>> +}
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> Why bother with all these conditions?
>>> Won't it be enough to check dev->vendor_id == PCI_VENDOR_ID_INTEL?
>>>
>>
>> If this is just used for IGD, its always fine without checking vendor_id.
>
> You need to match device ID to *know* it's IGD.
>
>> So after remove that check, I guess I need to rename that as
>> is_igd_vga_passthrough() to make sense.
>>
>> Thanks
>> Tiejun
>
> There is no need to check class code or xen_has_gfx_passthru flag.
> Device ID + vendor ID identifies each device uniquely.
>

Yeah.

Here I assume vendor ID is always PCI_VENDOR_ID_INTEL so looks you means 
I also need to check that table to do something like,

is_igd_vga_passthugh(dev)
{	
	int i;
	int num = ARRAY_SIZE(xen_igd_combo_id_infos);
	for (i = 0; i < num; i++) {
		if (dev->device_id == xen_igd_combo_id_infos[i].gpu_device_id)
			return 1;
	return 0;
}

Then we can simplify the subsequent codes based on this, right?

Thanks
Tiejun


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:18:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKKD-0006AY-Mv; Mon, 17 Nov 2014 11:18:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqKKB-0006AL-Pv
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 11:18:27 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	E1/44-27785-389D9645; Mon, 17 Nov 2014 11:18:27 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416223101!13010299!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18457 invoked from network); 17 Nov 2014 11:18:22 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-27.messagelabs.com with SMTP;
	17 Nov 2014 11:18:22 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 17 Nov 2014 03:15:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,402,1413270000"; d="scan'208";a="609037194"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 03:18:18 -0800
Message-ID: <5469D979.8050404@intel.com>
Date: Mon, 17 Nov 2014 19:18:17 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
	<20141117061010.GB19718@redhat.com> <5469B660.6040107@intel.com>
	<20141117092501.GA20133@redhat.com> <5469C2F4.4020304@intel.com>
	<20141117101342.GF20133@redhat.com>
In-Reply-To: <20141117101342.GF20133@redhat.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/17 18:13, Michael S. Tsirkin wrote:
> On Mon, Nov 17, 2014 at 05:42:12PM +0800, Chen, Tiejun wrote:
>> On 2014/11/17 17:25, Michael S. Tsirkin wrote:
>>> On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
>>>> On 2014/11/17 14:10, Michael S. Tsirkin wrote:
>>>>> On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/11/5 22:09, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
>>>>>>>> Currently IGD drivers always need to access PCH by 1f.0, and
>>>>>>>> PCH vendor/device id is used to identify the card.
>>>>>>>>
>>>>>>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>>>>>>> ---
>>
>> [snip]
>>
>>> Cleaner:
>>> 	 if (!pci_dev) {
>>> 		fprintf
>>> 		return;
>>> 	}
>>>           pci_config_set_device_id(pci_dev->config, pch_id);
>>
>> I will address all comments and thanks.
>>
>>>
>>>> +    }
>>>> +}
>>>> +
>>>>   /* init */
>>>>
>>>>   static int xen_pt_initfn(PCIDevice *d)
>>>> @@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
>>>>           return -1;
>>>>       }
>>>>
>>>> +    /* Register ISA bridge for passthrough GFX. */
>>>> +    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
>>>> +
>>>>       /* reinitialize each config register to be emulated */
>>>>       if (xen_pt_config_init(s)) {
>>>>           XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
>>>>
>>>> Note I will introduce a inline function in another patch,
>>>>
>>>> +static inline int is_vga_passthrough(XenHostPCIDevice *dev)
>>>> +{
>>>> +    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
>>>> +            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
>>>> +}
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> Why bother with all these conditions?
>>> Won't it be enough to check dev->vendor_id == PCI_VENDOR_ID_INTEL?
>>>
>>
>> If this is just used for IGD, its always fine without checking vendor_id.
>
> You need to match device ID to *know* it's IGD.
>
>> So after remove that check, I guess I need to rename that as
>> is_igd_vga_passthrough() to make sense.
>>
>> Thanks
>> Tiejun
>
> There is no need to check class code or xen_has_gfx_passthru flag.
> Device ID + vendor ID identifies each device uniquely.
>

Yeah.

Here I assume vendor ID is always PCI_VENDOR_ID_INTEL so looks you means 
I also need to check that table to do something like,

is_igd_vga_passthugh(dev)
{	
	int i;
	int num = ARRAY_SIZE(xen_igd_combo_id_infos);
	for (i = 0; i < num; i++) {
		if (dev->device_id == xen_igd_combo_id_infos[i].gpu_device_id)
			return 1;
	return 0;
}

Then we can simplify the subsequent codes based on this, right?

Thanks
Tiejun


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:26:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:26:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKRy-0006VC-QI; Mon, 17 Nov 2014 11:26:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqKRx-0006V7-79
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 11:26:29 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	10/C5-31453-46BD9645; Mon, 17 Nov 2014 11:26:28 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416223586!8875482!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3208 invoked from network); 17 Nov 2014 11:26:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:26:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191998903"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 06:26:25 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqKJo-0001lD-Cm;
	Mon, 17 Nov 2014 11:18:04 +0000
Date: Mon, 17 Nov 2014 11:17:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Li, Liang Z" <liang.z.li@intel.com>
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E448659@shsmsx102.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411171117230.26318@kaball.uk.xensource.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
	<alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
	<20141114155039.GF5364@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411141634480.26318@kaball.uk.xensource.com>
	<F2CBF3009FA73547804AE4C663CAB28E448659@shsmsx102.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	"aliguori@amazon.com" <aliguori@amazon.com>,
	"qemu-devel@nongun.org" <qemu-devel@nongun.org>,
	Igor Mammedov <imammedo@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
 running 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 Sun, 16 Nov 2014, Li, Liang Z wrote:
> > > > Konrad,
> > > > this is another bug fix for QEMU: pci hotplug doesn't work when
> > > > xen_platform_pci=0 without this.
> > >
> > > Yes.
> > > >
> > > >I think we should have it in 4.5. What do yo  think?
> > >
> > > Do you believe we should first get an Tested-by from the Intel QA folks?
>  
> > Liang at Intel was the one to fix and resend. Liang, could you please test this patch on qemu-xen on xen-unstable? Thanks! 
> 
> I have verified this patch can fix the bug  for QEMU: pci hotplug doesn't work when  xen_platform_pci=0,  my original intention  was to fix this bug, so I resent the patch.

In that case I'll go ahead and backport it to qemu-xen for 4.5.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:26:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:26:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKRy-0006VC-QI; Mon, 17 Nov 2014 11:26:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqKRx-0006V7-79
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 11:26:29 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	10/C5-31453-46BD9645; Mon, 17 Nov 2014 11:26:28 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416223586!8875482!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3208 invoked from network); 17 Nov 2014 11:26:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:26:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191998903"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 06:26:25 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqKJo-0001lD-Cm;
	Mon, 17 Nov 2014 11:18:04 +0000
Date: Mon, 17 Nov 2014 11:17:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Li, Liang Z" <liang.z.li@intel.com>
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E448659@shsmsx102.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1411171117230.26318@kaball.uk.xensource.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
	<alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
	<20141114155039.GF5364@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411141634480.26318@kaball.uk.xensource.com>
	<F2CBF3009FA73547804AE4C663CAB28E448659@shsmsx102.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	"aliguori@amazon.com" <aliguori@amazon.com>,
	"qemu-devel@nongun.org" <qemu-devel@nongun.org>,
	Igor Mammedov <imammedo@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
 running 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 Sun, 16 Nov 2014, Li, Liang Z wrote:
> > > > Konrad,
> > > > this is another bug fix for QEMU: pci hotplug doesn't work when
> > > > xen_platform_pci=0 without this.
> > >
> > > Yes.
> > > >
> > > >I think we should have it in 4.5. What do yo  think?
> > >
> > > Do you believe we should first get an Tested-by from the Intel QA folks?
>  
> > Liang at Intel was the one to fix and resend. Liang, could you please test this patch on qemu-xen on xen-unstable? Thanks! 
> 
> I have verified this patch can fix the bug  for QEMU: pci hotplug doesn't work when  xen_platform_pci=0,  my original intention  was to fix this bug, so I resent the patch.

In that case I'll go ahead and backport it to qemu-xen for 4.5.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:28:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:28:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKTk-0006ar-BK; Mon, 17 Nov 2014 11:28:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqKTi-0006am-J4
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 11:28:18 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	AD/78-18267-1DBD9645; Mon, 17 Nov 2014 11:28:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416223695!9420594!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29949 invoked from network); 17 Nov 2014 11:28:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:28:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191999320"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 06:28:15 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqKTe-00025Z-Qm;
	Mon, 17 Nov 2014 11:28:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqKTe-0000ca-5m;
	Mon, 17 Nov 2014 11:28:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21609.56269.735904.722661@mariner.uk.xensource.com>
Date: Mon, 17 Nov 2014 11:28:13 +0000
To: xen.org <Ian.Jackson@eu.citrix.com>
In-Reply-To: <E1XqAAD-0001TP-NL@osstest.cam.xci-test.com>
References: <E1XqAAD-0001TP-NL@osstest.cam.xci-test.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [rumpuserxen bisection] complete
	test-amd64-i386-rumpuserxen-i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[rumpuserxen bisection] complete test-amd64-i386-rumpuserxen-i386"):
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-rumpuserxen-i386
> test rumpuserxen-demo-xenstorels/xenstorels

We're still on the old osstest here, so this is simply confirmation of
my earlier diagnosis.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:28:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:28:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKTk-0006ar-BK; Mon, 17 Nov 2014 11:28:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqKTi-0006am-J4
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 11:28:18 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	AD/78-18267-1DBD9645; Mon, 17 Nov 2014 11:28:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416223695!9420594!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29949 invoked from network); 17 Nov 2014 11:28:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:28:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="191999320"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 06:28:15 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqKTe-00025Z-Qm;
	Mon, 17 Nov 2014 11:28:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqKTe-0000ca-5m;
	Mon, 17 Nov 2014 11:28:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21609.56269.735904.722661@mariner.uk.xensource.com>
Date: Mon, 17 Nov 2014 11:28:13 +0000
To: xen.org <Ian.Jackson@eu.citrix.com>
In-Reply-To: <E1XqAAD-0001TP-NL@osstest.cam.xci-test.com>
References: <E1XqAAD-0001TP-NL@osstest.cam.xci-test.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [rumpuserxen bisection] complete
	test-amd64-i386-rumpuserxen-i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[rumpuserxen bisection] complete test-amd64-i386-rumpuserxen-i386"):
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-rumpuserxen-i386
> test rumpuserxen-demo-xenstorels/xenstorels

We're still on the old osstest here, so this is simply confirmation of
my earlier diagnosis.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:32:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKY2-0006nz-1R; Mon, 17 Nov 2014 11:32:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqKY0-0006nu-Qs
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 11:32:44 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	0E/51-24859-CDCD9645; Mon, 17 Nov 2014 11:32:44 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416223962!11827771!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4695 invoked from network); 17 Nov 2014 11:32:43 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-31.messagelabs.com with SMTP;
	17 Nov 2014 11:32:43 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 17 Nov 2014 03:30:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,402,1413270000"; d="scan'208";a="609041916"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 03:32:40 -0800
Message-ID: <5469DCD7.4030701@intel.com>
Date: Mon, 17 Nov 2014 19:32:39 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
In-Reply-To: <5469E74302000078000485B0@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/17 19:17, Jan Beulich wrote:
>>>> On 17.11.14 at 12:08, <tiejun.chen@intel.com> wrote:
>
>> On 2014/11/17 18:05, Jan Beulich wrote:
>>>>>> On 17.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
>>>> --- a/xen/common/memory.c
>>>> +++ b/xen/common/memory.c
>>>> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>>>>         unsigned int used_entries;
>>>>     };
>>>>
>>>> -static int get_reserved_device_memory(xen_pfn_t start,
>>>> -                                      xen_ulong_t nr, void *ctxt)
>>>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16
>> seg,
>>>> +                                      u16 *ids, int cnt, void *ctxt)
>>>
>>> While the approach is a lot better than what you did previously, I still
>>> don't like you adding 3 new parameters when one would do (calling
>>> the callback for each SBDF individually): That way you avoid
>>
>> Do you mean I should do this?
>>
>> for_each_rmrr_device ( rmrr, bdf, i )
>> {
>> 	 sbdf = PCI_SBDF(seg, rmrr->scope.devices[i]);
>>            rc = func(PFN_DOWN(rmrr->base_address),
>>                      PFN_UP(rmrr->end_address) -
>> PFN_DOWN(rmrr->base_address),
>> 		   sbdf,	
>>                      ctxt);
>>
>> But each different sbdf may occupy one same rmrr entry as I said
>> previously, so we have to introduce more codes to filter them as one
>> identified entry in the callback.
>
> Not really - remember that part of what needs to be done is to make
> sure all devices associated with a given RMRR get assigned to the
> same guest? Or the callback function could use a special return value

Yes, but I means in the callback,

get_reserved_device_memory()
{
	...
	for(each assigned pci devs:pt_sbdf)
		if (sbdf == pt_sbdf)
			__copy_to_guest_offset(buffer, ...)

Buffer may be copied to include multiple same entries if we have two or 
more assigned devices associated to one give RMRR entry.

Thanks
Tiejun

> (e.g. 1) to signal that the iteration for the current RMRR can be
> terminated (or further entries skipped).
>
> Jan
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:32:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKY2-0006nz-1R; Mon, 17 Nov 2014 11:32:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqKY0-0006nu-Qs
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 11:32:44 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	0E/51-24859-CDCD9645; Mon, 17 Nov 2014 11:32:44 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416223962!11827771!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4695 invoked from network); 17 Nov 2014 11:32:43 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-31.messagelabs.com with SMTP;
	17 Nov 2014 11:32:43 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 17 Nov 2014 03:30:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,402,1413270000"; d="scan'208";a="609041916"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.103])
	([10.238.130.103])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 03:32:40 -0800
Message-ID: <5469DCD7.4030701@intel.com>
Date: Mon, 17 Nov 2014 19:32:39 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
In-Reply-To: <5469E74302000078000485B0@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/17 19:17, Jan Beulich wrote:
>>>> On 17.11.14 at 12:08, <tiejun.chen@intel.com> wrote:
>
>> On 2014/11/17 18:05, Jan Beulich wrote:
>>>>>> On 17.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
>>>> --- a/xen/common/memory.c
>>>> +++ b/xen/common/memory.c
>>>> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>>>>         unsigned int used_entries;
>>>>     };
>>>>
>>>> -static int get_reserved_device_memory(xen_pfn_t start,
>>>> -                                      xen_ulong_t nr, void *ctxt)
>>>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16
>> seg,
>>>> +                                      u16 *ids, int cnt, void *ctxt)
>>>
>>> While the approach is a lot better than what you did previously, I still
>>> don't like you adding 3 new parameters when one would do (calling
>>> the callback for each SBDF individually): That way you avoid
>>
>> Do you mean I should do this?
>>
>> for_each_rmrr_device ( rmrr, bdf, i )
>> {
>> 	 sbdf = PCI_SBDF(seg, rmrr->scope.devices[i]);
>>            rc = func(PFN_DOWN(rmrr->base_address),
>>                      PFN_UP(rmrr->end_address) -
>> PFN_DOWN(rmrr->base_address),
>> 		   sbdf,	
>>                      ctxt);
>>
>> But each different sbdf may occupy one same rmrr entry as I said
>> previously, so we have to introduce more codes to filter them as one
>> identified entry in the callback.
>
> Not really - remember that part of what needs to be done is to make
> sure all devices associated with a given RMRR get assigned to the
> same guest? Or the callback function could use a special return value

Yes, but I means in the callback,

get_reserved_device_memory()
{
	...
	for(each assigned pci devs:pt_sbdf)
		if (sbdf == pt_sbdf)
			__copy_to_guest_offset(buffer, ...)

Buffer may be copied to include multiple same entries if we have two or 
more assigned devices associated to one give RMRR entry.

Thanks
Tiejun

> (e.g. 1) to signal that the iteration for the current RMRR can be
> terminated (or further entries skipped).
>
> Jan
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:35:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11: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 1XqKae-0006wL-Nw; Mon, 17 Nov 2014 11:35:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqKae-0006wF-1h
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 11:35:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1C/6D-24532-F7DD9645; Mon, 17 Nov 2014 11:35:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416224124!13214405!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19067 invoked from network); 17 Nov 2014 11:35:25 -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;
	17 Nov 2014 11:35:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193496279"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 06:35:22 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqKaY-0002Df-07;
	Mon, 17 Nov 2014 11:35:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqKaW-0000eN-D7;
	Mon, 17 Nov 2014 11:35:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21609.56695.785422.653166@mariner.uk.xensource.com>
Date: Mon, 17 Nov 2014 11:35:19 +0000
To: xen.org <Ian.Jackson@eu.citrix.com>
In-Reply-To: <osstest-31525-mainreport@xen.org>
References: <osstest-31525-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31525: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-4.2-testing test] 31525: regressions - FAIL"):
> flight 31525 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31525/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

This was the swiotlb bnx2/mptsas bug, which as existed forever and for
which there are patches pending in various Linux trees.  (It's showing
up as a regression here because the tester picked an affected host.)
There were no other reasons not to push.  I have done a force push as
follows:

  xen@xenbits:~/git/xen.git$ git update-ref -m 'manual force push' \
   refs/heads/stable-4.2 c844974caf1501b6527533ab2a3d27ea8920ab90 \
   fad105dd0ac1a224d91757afee01acd4566f7e82

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:35:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11: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 1XqKae-0006wL-Nw; Mon, 17 Nov 2014 11:35:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqKae-0006wF-1h
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 11:35:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1C/6D-24532-F7DD9645; Mon, 17 Nov 2014 11:35:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416224124!13214405!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19067 invoked from network); 17 Nov 2014 11:35:25 -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;
	17 Nov 2014 11:35:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193496279"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 06:35:22 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqKaY-0002Df-07;
	Mon, 17 Nov 2014 11:35:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqKaW-0000eN-D7;
	Mon, 17 Nov 2014 11:35:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21609.56695.785422.653166@mariner.uk.xensource.com>
Date: Mon, 17 Nov 2014 11:35:19 +0000
To: xen.org <Ian.Jackson@eu.citrix.com>
In-Reply-To: <osstest-31525-mainreport@xen.org>
References: <osstest-31525-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 31525: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-4.2-testing test] 31525: regressions - FAIL"):
> flight 31525 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31525/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

This was the swiotlb bnx2/mptsas bug, which as existed forever and for
which there are patches pending in various Linux trees.  (It's showing
up as a regression here because the tester picked an affected host.)
There were no other reasons not to push.  I have done a force push as
follows:

  xen@xenbits:~/git/xen.git$ git update-ref -m 'manual force push' \
   refs/heads/stable-4.2 c844974caf1501b6527533ab2a3d27ea8920ab90 \
   fad105dd0ac1a224d91757afee01acd4566f7e82

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:42:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:42:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKhh-00078l-JV; Mon, 17 Nov 2014 11:42:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <talex5@gmail.com>) id 1XqKhg-00078e-0I
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 11:42:44 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	42/8A-24124-03FD9645; Mon, 17 Nov 2014 11:42:40 +0000
X-Env-Sender: talex5@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416224558!7641098!1
X-Originating-IP: [209.85.220.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26028 invoked from network); 17 Nov 2014 11:42:39 -0000
Received: from mail-vc0-f182.google.com (HELO mail-vc0-f182.google.com)
	(209.85.220.182)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:42:39 -0000
Received: by mail-vc0-f182.google.com with SMTP id im17so7063939vcb.13
	for <xen-devel@lists.xenproject.org>;
	Mon, 17 Nov 2014 03:42:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=iLhMcCcPjzqgqnJ2lmWXsQEeVZ2bZupgzLeiU1G5HYg=;
	b=WbNhxAMfbJbm74/jBrLzdH+TVpcJQYzg5AbB4aYb7uC/iZgXzfsITZiezadqd7pmQw
	16nS6psrc2RNEuBZxoxiO6pGJ1dscwXibPXk3hSeguBpByPR74Ua+miH0pFuzkSd+7Vl
	08oMkbC40lRflqMl25WVk+KzswB/N5KYEs2qst1xe2Dd1C85+8IFWgZF5sghAeNBEfoP
	3EjethR5/RPdlGm6qh5LSwi8q3Q69JLfWv5JIa1onxZruKTtsIR8dD0+B3ASJm6O8Oy+
	uayJ+YGlavCDOgt3Xo4VHs2WECAr4qalkaKMpGzYOA67mz4AZkv1vKfDyEIAIiK4gbi1
	lw4Q==
MIME-Version: 1.0
X-Received: by 10.221.68.199 with SMTP id xz7mr24332840vcb.7.1416224558621;
	Mon, 17 Nov 2014 03:42:38 -0800 (PST)
Received: by 10.31.130.80 with HTTP; Mon, 17 Nov 2014 03:42:38 -0800 (PST)
In-Reply-To: <CAG4opy8ON6w2dUq+1YtPRQDNQ3E+CzbfPf2aT0RcQQBk=inkug@mail.gmail.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-4-git-send-email-talex5@gmail.com>
	<1413891867.23337.26.camel@citrix.com>
	<20141021215012.GI3481@type.youpi.perso.aquilenet.fr>
	<CAG4opy8H4mk5xnkQT+BLLxMprZ6HFK0hVmQnKoU=NUMmQZw=gQ@mail.gmail.com>
	<20141026095528.GM3695@type.youpi.perso.aquilenet.fr>
	<CAG4opy8ON6w2dUq+1YtPRQDNQ3E+CzbfPf2aT0RcQQBk=inkug@mail.gmail.com>
Date: Mon, 17 Nov 2014 11:42:38 +0000
Message-ID: <CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
From: Thomas Leonard <talex5@gmail.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Thomas Leonard <talex5@gmail.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>, 
	David Scott <Dave.Scott@eu.citrix.com>,
	KarimAllah Ahmed <karim.allah.ahmed@gmail.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH ARM v8 3/4] mini-os: arm: build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjYgT2N0b2JlciAyMDE0IDEwOjI1LCBUaG9tYXMgTGVvbmFyZCA8dGFsZXg1QGdtYWlsLmNv
bT4gd3JvdGU6Cj4gT24gMjYgT2N0b2JlciAyMDE0IDA5OjU1LCBTYW11ZWwgVGhpYmF1bHQgPHNh
bXVlbC50aGliYXVsdEBlbnMtbHlvbi5vcmc+IHdyb3RlOgo+PiBUaG9tYXMgTGVvbmFyZCwgbGUg
U3VuIDI2IE9jdCAyMDE0IDA5OjQ2OjA5ICswMDAwLCBhIMOpY3JpdCA6Cj4+PiBDb3VsZCB5b3Ug
c2F5IGEgYml0IG1vcmUgYWJvdXQgdGhlIGxpbmtlciBwcm9ibGVtcyB5b3UgaGFkPwo+Pgo+PiBS
ZWFsbHkgZGlnZ2luZyBpbiB0aGUgYXJjaGl2ZXMgdGhpcyB0aW1lIDopCj4+Cj4+IGlhNjQtc3Bl
Y2lmaWM6Cj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWlhNjQtZGV2
ZWwvMjAwOC0wMy9tc2cwMDEyNi5odG1sCj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVz
L2h0bWwveGVuLWlhNjQtZGV2ZWwvMjAwOC0xMi9tc2cwMDA3MC5odG1sCj4+IHg4Nl82NC1zcGVj
aWZpYyAobWlzc2luZyByZWQgem9uZSBzdXBwb3J0KQo+PiBodHRwOi8vbGlzdHMueGVuLm9yZy9h
cmNoaXZlcy9odG1sL3hlbi1pYTY0LWRldmVsLzIwMDgtMDIvbXNnMDAyNTEuaHRtbAo+Pgo+PiBT
byBJIGd1ZXNzIGl0IGNvdWxkIGJlIE9LIG9uIGFybSwgYnV0IHlvdSBoYXZlIHRvIG1ha2Ugc3Vy
ZSB0aGF0IE1pbmktT1MKPj4gaW1wbGVtZW50cyB0aGUgd2hvbGUgQUJJIHRoYXQgZ2NjIHdpbGwg
dXNlLiBUZXN0aW5nIGlzIG5vdCBlbm91Z2gsIEkgZ290Cj4+IGhpdCBieSB0aGUgcmVkIHpvbmUg
Zm9yIGluc3RhbmNlLgo+Cj4gT24gQVJNLCB3ZSBoYXZlIGEgc2VwYXJhdGUgc3RhY2sgZm9yIHRo
ZSBJUlEgaGFuZGxlciwgc28gdGhlIHJlZCB6b25lCj4gYXQgbGVhc3Qgc2hvdWxkbid0IGJlIGEg
cHJvYmxlbS4KCkluY2lkZW50YWxseSwgd2h5IGRvZXNuJ3QgTWluaS1PUy94ODYgdXNlIGEgcmVk
IHpvbmU/IEkgYXNzdW1lIHRoZXJlJ3MKYSB3b3J0aHdoaWxlIHBlcmZvcm1hbmNlIGJlbmVmaXQg
dG8gaXQsIGFuZCBpdCB3b3VsZCBwcmV2ZW50IHN1YnRsZQpidWdzIHdoZW4gc29mdHdhcmUgaXMg
YWNjaWRlbnRhbGx5IGNvbXBpbGVkIGZvciB0aGUgbm9ybWFsIEFCSS4KCgotLSAKRHIgVGhvbWFz
IExlb25hcmQgICAgICAgIGh0dHA6Ly8waW5zdGFsbC5uZXQvCkdQRzogOTI0MiA5ODA3IEM5ODUg
M0MwNyA0NEE2ICA4QjlBIEFFMDcgODI4MCA1OUE1IDNDQzEKR1BHOiBEQTk4IDI1QUUgQ0FEMCA4
OTc1IDdDREEgIEJEOEUgMDcxMyAzRjk2IENBNzQgRDhCQQoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:42:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:42:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKhh-00078l-JV; Mon, 17 Nov 2014 11:42:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <talex5@gmail.com>) id 1XqKhg-00078e-0I
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 11:42:44 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	42/8A-24124-03FD9645; Mon, 17 Nov 2014 11:42:40 +0000
X-Env-Sender: talex5@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416224558!7641098!1
X-Originating-IP: [209.85.220.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26028 invoked from network); 17 Nov 2014 11:42:39 -0000
Received: from mail-vc0-f182.google.com (HELO mail-vc0-f182.google.com)
	(209.85.220.182)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:42:39 -0000
Received: by mail-vc0-f182.google.com with SMTP id im17so7063939vcb.13
	for <xen-devel@lists.xenproject.org>;
	Mon, 17 Nov 2014 03:42:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=iLhMcCcPjzqgqnJ2lmWXsQEeVZ2bZupgzLeiU1G5HYg=;
	b=WbNhxAMfbJbm74/jBrLzdH+TVpcJQYzg5AbB4aYb7uC/iZgXzfsITZiezadqd7pmQw
	16nS6psrc2RNEuBZxoxiO6pGJ1dscwXibPXk3hSeguBpByPR74Ua+miH0pFuzkSd+7Vl
	08oMkbC40lRflqMl25WVk+KzswB/N5KYEs2qst1xe2Dd1C85+8IFWgZF5sghAeNBEfoP
	3EjethR5/RPdlGm6qh5LSwi8q3Q69JLfWv5JIa1onxZruKTtsIR8dD0+B3ASJm6O8Oy+
	uayJ+YGlavCDOgt3Xo4VHs2WECAr4qalkaKMpGzYOA67mz4AZkv1vKfDyEIAIiK4gbi1
	lw4Q==
MIME-Version: 1.0
X-Received: by 10.221.68.199 with SMTP id xz7mr24332840vcb.7.1416224558621;
	Mon, 17 Nov 2014 03:42:38 -0800 (PST)
Received: by 10.31.130.80 with HTTP; Mon, 17 Nov 2014 03:42:38 -0800 (PST)
In-Reply-To: <CAG4opy8ON6w2dUq+1YtPRQDNQ3E+CzbfPf2aT0RcQQBk=inkug@mail.gmail.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-4-git-send-email-talex5@gmail.com>
	<1413891867.23337.26.camel@citrix.com>
	<20141021215012.GI3481@type.youpi.perso.aquilenet.fr>
	<CAG4opy8H4mk5xnkQT+BLLxMprZ6HFK0hVmQnKoU=NUMmQZw=gQ@mail.gmail.com>
	<20141026095528.GM3695@type.youpi.perso.aquilenet.fr>
	<CAG4opy8ON6w2dUq+1YtPRQDNQ3E+CzbfPf2aT0RcQQBk=inkug@mail.gmail.com>
Date: Mon, 17 Nov 2014 11:42:38 +0000
Message-ID: <CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
From: Thomas Leonard <talex5@gmail.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Thomas Leonard <talex5@gmail.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>, 
	David Scott <Dave.Scott@eu.citrix.com>,
	KarimAllah Ahmed <karim.allah.ahmed@gmail.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH ARM v8 3/4] mini-os: arm: build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjYgT2N0b2JlciAyMDE0IDEwOjI1LCBUaG9tYXMgTGVvbmFyZCA8dGFsZXg1QGdtYWlsLmNv
bT4gd3JvdGU6Cj4gT24gMjYgT2N0b2JlciAyMDE0IDA5OjU1LCBTYW11ZWwgVGhpYmF1bHQgPHNh
bXVlbC50aGliYXVsdEBlbnMtbHlvbi5vcmc+IHdyb3RlOgo+PiBUaG9tYXMgTGVvbmFyZCwgbGUg
U3VuIDI2IE9jdCAyMDE0IDA5OjQ2OjA5ICswMDAwLCBhIMOpY3JpdCA6Cj4+PiBDb3VsZCB5b3Ug
c2F5IGEgYml0IG1vcmUgYWJvdXQgdGhlIGxpbmtlciBwcm9ibGVtcyB5b3UgaGFkPwo+Pgo+PiBS
ZWFsbHkgZGlnZ2luZyBpbiB0aGUgYXJjaGl2ZXMgdGhpcyB0aW1lIDopCj4+Cj4+IGlhNjQtc3Bl
Y2lmaWM6Cj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWlhNjQtZGV2
ZWwvMjAwOC0wMy9tc2cwMDEyNi5odG1sCj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVz
L2h0bWwveGVuLWlhNjQtZGV2ZWwvMjAwOC0xMi9tc2cwMDA3MC5odG1sCj4+IHg4Nl82NC1zcGVj
aWZpYyAobWlzc2luZyByZWQgem9uZSBzdXBwb3J0KQo+PiBodHRwOi8vbGlzdHMueGVuLm9yZy9h
cmNoaXZlcy9odG1sL3hlbi1pYTY0LWRldmVsLzIwMDgtMDIvbXNnMDAyNTEuaHRtbAo+Pgo+PiBT
byBJIGd1ZXNzIGl0IGNvdWxkIGJlIE9LIG9uIGFybSwgYnV0IHlvdSBoYXZlIHRvIG1ha2Ugc3Vy
ZSB0aGF0IE1pbmktT1MKPj4gaW1wbGVtZW50cyB0aGUgd2hvbGUgQUJJIHRoYXQgZ2NjIHdpbGwg
dXNlLiBUZXN0aW5nIGlzIG5vdCBlbm91Z2gsIEkgZ290Cj4+IGhpdCBieSB0aGUgcmVkIHpvbmUg
Zm9yIGluc3RhbmNlLgo+Cj4gT24gQVJNLCB3ZSBoYXZlIGEgc2VwYXJhdGUgc3RhY2sgZm9yIHRo
ZSBJUlEgaGFuZGxlciwgc28gdGhlIHJlZCB6b25lCj4gYXQgbGVhc3Qgc2hvdWxkbid0IGJlIGEg
cHJvYmxlbS4KCkluY2lkZW50YWxseSwgd2h5IGRvZXNuJ3QgTWluaS1PUy94ODYgdXNlIGEgcmVk
IHpvbmU/IEkgYXNzdW1lIHRoZXJlJ3MKYSB3b3J0aHdoaWxlIHBlcmZvcm1hbmNlIGJlbmVmaXQg
dG8gaXQsIGFuZCBpdCB3b3VsZCBwcmV2ZW50IHN1YnRsZQpidWdzIHdoZW4gc29mdHdhcmUgaXMg
YWNjaWRlbnRhbGx5IGNvbXBpbGVkIGZvciB0aGUgbm9ybWFsIEFCSS4KCgotLSAKRHIgVGhvbWFz
IExlb25hcmQgICAgICAgIGh0dHA6Ly8waW5zdGFsbC5uZXQvCkdQRzogOTI0MiA5ODA3IEM5ODUg
M0MwNyA0NEE2ICA4QjlBIEFFMDcgODI4MCA1OUE1IDNDQzEKR1BHOiBEQTk4IDI1QUUgQ0FEMCA4
OTc1IDdDREEgIEJEOEUgMDcxMyAzRjk2IENBNzQgRDhCQQoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:45:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:45:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKk6-0007FF-54; Mon, 17 Nov 2014 11:45:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqKk4-0007F9-S6
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 11:45:12 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	56/FC-29352-8CFD9645; Mon, 17 Nov 2014 11:45:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416224710!11752473!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22214 invoked from network); 17 Nov 2014 11:45:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:45:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193498380"
Message-ID: <1416224705.5466.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Thomas Leonard <talex5@gmail.com>
Date: Mon, 17 Nov 2014 11:45:05 +0000
In-Reply-To: <CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-4-git-send-email-talex5@gmail.com>
	<1413891867.23337.26.camel@citrix.com>
	<20141021215012.GI3481@type.youpi.perso.aquilenet.fr>
	<CAG4opy8H4mk5xnkQT+BLLxMprZ6HFK0hVmQnKoU=NUMmQZw=gQ@mail.gmail.com>
	<20141026095528.GM3695@type.youpi.perso.aquilenet.fr>
	<CAG4opy8ON6w2dUq+1YtPRQDNQ3E+CzbfPf2aT0RcQQBk=inkug@mail.gmail.com>
	<CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
Organization: Citrix Systems, Inc.
Content-Length: 2092
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 3/4] mini-os: arm: build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDE0LTExLTE3IGF0IDExOjQyICswMDAwLCBUaG9tYXMgTGVvbmFyZCB3cm90ZToK
PiBPbiAyNiBPY3RvYmVyIDIwMTQgMTA6MjUsIFRob21hcyBMZW9uYXJkIDx0YWxleDVAZ21haWwu
Y29tPiB3cm90ZToKPiA+IE9uIDI2IE9jdG9iZXIgMjAxNCAwOTo1NSwgU2FtdWVsIFRoaWJhdWx0
IDxzYW11ZWwudGhpYmF1bHRAZW5zLWx5b24ub3JnPiB3cm90ZToKPiA+PiBUaG9tYXMgTGVvbmFy
ZCwgbGUgU3VuIDI2IE9jdCAyMDE0IDA5OjQ2OjA5ICswMDAwLCBhIMOpY3JpdCA6Cj4gPj4+IENv
dWxkIHlvdSBzYXkgYSBiaXQgbW9yZSBhYm91dCB0aGUgbGlua2VyIHByb2JsZW1zIHlvdSBoYWQ/
Cj4gPj4KPiA+PiBSZWFsbHkgZGlnZ2luZyBpbiB0aGUgYXJjaGl2ZXMgdGhpcyB0aW1lIDopCj4g
Pj4KPiA+PiBpYTY0LXNwZWNpZmljOgo+ID4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVz
L2h0bWwveGVuLWlhNjQtZGV2ZWwvMjAwOC0wMy9tc2cwMDEyNi5odG1sCj4gPj4gaHR0cDovL2xp
c3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4taWE2NC1kZXZlbC8yMDA4LTEyL21zZzAwMDcw
Lmh0bWwKPiA+PiB4ODZfNjQtc3BlY2lmaWMgKG1pc3NpbmcgcmVkIHpvbmUgc3VwcG9ydCkKPiA+
PiBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1pYTY0LWRldmVsLzIwMDgt
MDIvbXNnMDAyNTEuaHRtbAo+ID4+Cj4gPj4gU28gSSBndWVzcyBpdCBjb3VsZCBiZSBPSyBvbiBh
cm0sIGJ1dCB5b3UgaGF2ZSB0byBtYWtlIHN1cmUgdGhhdCBNaW5pLU9TCj4gPj4gaW1wbGVtZW50
cyB0aGUgd2hvbGUgQUJJIHRoYXQgZ2NjIHdpbGwgdXNlLiBUZXN0aW5nIGlzIG5vdCBlbm91Z2gs
IEkgZ290Cj4gPj4gaGl0IGJ5IHRoZSByZWQgem9uZSBmb3IgaW5zdGFuY2UuCj4gPgo+ID4gT24g
QVJNLCB3ZSBoYXZlIGEgc2VwYXJhdGUgc3RhY2sgZm9yIHRoZSBJUlEgaGFuZGxlciwgc28gdGhl
IHJlZCB6b25lCj4gPiBhdCBsZWFzdCBzaG91bGRuJ3QgYmUgYSBwcm9ibGVtLgo+IAo+IEluY2lk
ZW50YWxseSwgd2h5IGRvZXNuJ3QgTWluaS1PUy94ODYgdXNlIGEgcmVkIHpvbmU/IEkgYXNzdW1l
IHRoZXJlJ3MKPiBhIHdvcnRod2hpbGUgcGVyZm9ybWFuY2UgYmVuZWZpdCB0byBpdCwgYW5kIGl0
IHdvdWxkIHByZXZlbnQgc3VidGxlCj4gYnVncyB3aGVuIHNvZnR3YXJlIGlzIGFjY2lkZW50YWxs
eSBjb21waWxlZCBmb3IgdGhlIG5vcm1hbCBBQkkuCgpSZWR6b25lcyBhcmUgaW5jb21wYXRpYmxl
IHdpdGggdGFraW5nIGludGVycnVwdHMgYXQgdGhlIHNhbWUgcHJpdmlsZWdlCmxldmVsICh3aGlj
aCBpbXBsaWVzIG5vIHN0YWNrIHN3aXRjaCwgaGVuY2UgY2xvYmJlcmluZyksIGFuZCBtaW5pLW9z
CnJ1bnMgZXZlcnl0aGluZyBhdCBrZXJuZWwgcHJpdmlsZWdlIGxldmVsLgoKSWFuLgoKCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:45:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:45:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKk6-0007FF-54; Mon, 17 Nov 2014 11:45:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqKk4-0007F9-S6
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 11:45:12 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	56/FC-29352-8CFD9645; Mon, 17 Nov 2014 11:45:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416224710!11752473!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22214 invoked from network); 17 Nov 2014 11:45:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:45:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193498380"
Message-ID: <1416224705.5466.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Thomas Leonard <talex5@gmail.com>
Date: Mon, 17 Nov 2014 11:45:05 +0000
In-Reply-To: <CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-4-git-send-email-talex5@gmail.com>
	<1413891867.23337.26.camel@citrix.com>
	<20141021215012.GI3481@type.youpi.perso.aquilenet.fr>
	<CAG4opy8H4mk5xnkQT+BLLxMprZ6HFK0hVmQnKoU=NUMmQZw=gQ@mail.gmail.com>
	<20141026095528.GM3695@type.youpi.perso.aquilenet.fr>
	<CAG4opy8ON6w2dUq+1YtPRQDNQ3E+CzbfPf2aT0RcQQBk=inkug@mail.gmail.com>
	<CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
Organization: Citrix Systems, Inc.
Content-Length: 2092
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 3/4] mini-os: arm: build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDE0LTExLTE3IGF0IDExOjQyICswMDAwLCBUaG9tYXMgTGVvbmFyZCB3cm90ZToK
PiBPbiAyNiBPY3RvYmVyIDIwMTQgMTA6MjUsIFRob21hcyBMZW9uYXJkIDx0YWxleDVAZ21haWwu
Y29tPiB3cm90ZToKPiA+IE9uIDI2IE9jdG9iZXIgMjAxNCAwOTo1NSwgU2FtdWVsIFRoaWJhdWx0
IDxzYW11ZWwudGhpYmF1bHRAZW5zLWx5b24ub3JnPiB3cm90ZToKPiA+PiBUaG9tYXMgTGVvbmFy
ZCwgbGUgU3VuIDI2IE9jdCAyMDE0IDA5OjQ2OjA5ICswMDAwLCBhIMOpY3JpdCA6Cj4gPj4+IENv
dWxkIHlvdSBzYXkgYSBiaXQgbW9yZSBhYm91dCB0aGUgbGlua2VyIHByb2JsZW1zIHlvdSBoYWQ/
Cj4gPj4KPiA+PiBSZWFsbHkgZGlnZ2luZyBpbiB0aGUgYXJjaGl2ZXMgdGhpcyB0aW1lIDopCj4g
Pj4KPiA+PiBpYTY0LXNwZWNpZmljOgo+ID4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVz
L2h0bWwveGVuLWlhNjQtZGV2ZWwvMjAwOC0wMy9tc2cwMDEyNi5odG1sCj4gPj4gaHR0cDovL2xp
c3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4taWE2NC1kZXZlbC8yMDA4LTEyL21zZzAwMDcw
Lmh0bWwKPiA+PiB4ODZfNjQtc3BlY2lmaWMgKG1pc3NpbmcgcmVkIHpvbmUgc3VwcG9ydCkKPiA+
PiBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1pYTY0LWRldmVsLzIwMDgt
MDIvbXNnMDAyNTEuaHRtbAo+ID4+Cj4gPj4gU28gSSBndWVzcyBpdCBjb3VsZCBiZSBPSyBvbiBh
cm0sIGJ1dCB5b3UgaGF2ZSB0byBtYWtlIHN1cmUgdGhhdCBNaW5pLU9TCj4gPj4gaW1wbGVtZW50
cyB0aGUgd2hvbGUgQUJJIHRoYXQgZ2NjIHdpbGwgdXNlLiBUZXN0aW5nIGlzIG5vdCBlbm91Z2gs
IEkgZ290Cj4gPj4gaGl0IGJ5IHRoZSByZWQgem9uZSBmb3IgaW5zdGFuY2UuCj4gPgo+ID4gT24g
QVJNLCB3ZSBoYXZlIGEgc2VwYXJhdGUgc3RhY2sgZm9yIHRoZSBJUlEgaGFuZGxlciwgc28gdGhl
IHJlZCB6b25lCj4gPiBhdCBsZWFzdCBzaG91bGRuJ3QgYmUgYSBwcm9ibGVtLgo+IAo+IEluY2lk
ZW50YWxseSwgd2h5IGRvZXNuJ3QgTWluaS1PUy94ODYgdXNlIGEgcmVkIHpvbmU/IEkgYXNzdW1l
IHRoZXJlJ3MKPiBhIHdvcnRod2hpbGUgcGVyZm9ybWFuY2UgYmVuZWZpdCB0byBpdCwgYW5kIGl0
IHdvdWxkIHByZXZlbnQgc3VidGxlCj4gYnVncyB3aGVuIHNvZnR3YXJlIGlzIGFjY2lkZW50YWxs
eSBjb21waWxlZCBmb3IgdGhlIG5vcm1hbCBBQkkuCgpSZWR6b25lcyBhcmUgaW5jb21wYXRpYmxl
IHdpdGggdGFraW5nIGludGVycnVwdHMgYXQgdGhlIHNhbWUgcHJpdmlsZWdlCmxldmVsICh3aGlj
aCBpbXBsaWVzIG5vIHN0YWNrIHN3aXRjaCwgaGVuY2UgY2xvYmJlcmluZyksIGFuZCBtaW5pLW9z
CnJ1bnMgZXZlcnl0aGluZyBhdCBrZXJuZWwgcHJpdmlsZWdlIGxldmVsLgoKSWFuLgoKCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:47:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKlm-0007OZ-Lc; Mon, 17 Nov 2014 11:46:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XqKll-0007OR-4p
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 11:46:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	55/CF-09842-030E9645; Mon, 17 Nov 2014 11:46:56 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416224814!13280480!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28317 invoked from network); 17 Nov 2014 11:46:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:46:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="192003197"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 06:46:53 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XqKlh-0002O6-0k;
	Mon, 17 Nov 2014 11:46:53 +0000
Message-ID: <5469E021.70009@eu.citrix.com>
Date: Mon, 17 Nov 2014 11:46:41 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: <fantonifabio@tiscali.it>, Ian Campbell <Ian.Campbell@citrix.com>
References: <5177E6FD.7050707@tiscali.it>
	<1366817792.20256.374.camel@zakaz.uk.xensource.com>
	<517A47B3.4040600@tiscali.it>
	<1366968964.3142.52.camel@zakaz.uk.xensource.com>
	<517A5755.7080302@tiscali.it> <5465C752.1030208@tiscali.it>
In-Reply-To: <5465C752.1030208@tiscali.it>
X-DLP: MIA1
Cc: James Harper <james.harper@bendigoit.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Network not working after restore with qemu-xen
 windows domU and gplpv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 09:11 AM, Fabio Fantoni wrote:
> Il 26/04/2013 12:30, Fabio Fantoni ha scritto:
>> Il 26/04/2013 11:36, Ian Campbell ha scritto:
>>> On Fri, 2013-04-26 at 10:24 +0100, Fabio Fantoni wrote:
>>>> Il 24/04/2013 17:36, Ian Campbell ha scritto:
>>>>> On Wed, 2013-04-24 at 15:06 +0100, Fabio Fantoni wrote:
>>>>>> I send new mail about this bug with details as required by George
>>>>>> Dunlap.
>>>>>> Dom0 is Wheezy 64 bit with kernel from package
>>>>>> linux-image-3.2.0-4-amd64
>>>>>> version 3.2.41-2, package blktap-dkms and all dependency packages for
>>>>>> xen, spice and usb redirection.
>>>>>> xen.git (in this build commit is
>>>>>> 96ef6e88359910738905ac2e1969dc05d7d7e7dc)
>>>>>>
>>>>>> Other details about dom0 installation see here:
>>>>>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02290.html
>>>>>>
>>>>>> DomU is Windows 7 pro 64 bit with gplpv build 372 debug.
>>>>>>
>>>>>> After restore it sees network but is not working, nor lan neither
>>>>>> wan.
>>>>>> Tried with both dhcp and static ip, try also e1000 network card,
>>>>>> tried
>>>>>> also qemu 1.4.
>>>>> Is the vif device present and on the bridge in dom0? What about the
>>>>> emu
>>>>> device?
>>>>>
>>>>> Can you post the output of "xenstore-ls -fp" please.
>>>>>
>>>>> I notice references to openvswitch in your logs -- which script are
>>>>> you
>>>>> using, the one I recently posted or something else?
>>>>>
>>>>> Ian.
>>>>>
>>>>>
>>>> Thanks for reply, the vif and the vif -emu are present, bridge also and
>>>> is working.
>>> Are the both the vif* present on the bridge? What does "ovs-vsctl show"
>>> report?
>>>
>>>> On attachment logs of save, restore, copy of vif and xenstore command
>>>> you told me, both before and after save/restore.
>>> Thanks, I can see that the front and backend devices are connected ok
>>> and appear to be happy and the hotplug scripts were successful.
>>>
>>> However I did notice that the device MAC address seems to have changed!
>>> I can believe this could confuse things...
>>>
>>> Does this issue go away if you specify
>>>           vif=['bridge=xenbr0,mac=00:16:3e:42:ae:8f']
>>> in your configuration?
>>>
>>> Ian.
>>>
>> Thanks, fixed mac solve the problem.
>> Is possible solve for have network working after restore without mac
>> on xl configuration file also on qemu upstream?
>> The last test was without openvswitch, I must redo with it and post
>> "ovs-vsctl show" result?
>>
> This problem is still present and reported also by other users:
> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01267.html

The e-mail you link to there is talking about two different bits of 
functionality.  One is a vif (virtual interface), provided by qemu 
and/or netback; the other is a vf (virtual function), which is related 
to the connection to a physical device..

The question is whether the following configuration now works after 
suspend/resume:

   vif=['']

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:47:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKlm-0007OZ-Lc; Mon, 17 Nov 2014 11:46:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XqKll-0007OR-4p
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 11:46:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	55/CF-09842-030E9645; Mon, 17 Nov 2014 11:46:56 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416224814!13280480!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28317 invoked from network); 17 Nov 2014 11:46:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:46:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="192003197"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 06:46:53 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XqKlh-0002O6-0k;
	Mon, 17 Nov 2014 11:46:53 +0000
Message-ID: <5469E021.70009@eu.citrix.com>
Date: Mon, 17 Nov 2014 11:46:41 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: <fantonifabio@tiscali.it>, Ian Campbell <Ian.Campbell@citrix.com>
References: <5177E6FD.7050707@tiscali.it>
	<1366817792.20256.374.camel@zakaz.uk.xensource.com>
	<517A47B3.4040600@tiscali.it>
	<1366968964.3142.52.camel@zakaz.uk.xensource.com>
	<517A5755.7080302@tiscali.it> <5465C752.1030208@tiscali.it>
In-Reply-To: <5465C752.1030208@tiscali.it>
X-DLP: MIA1
Cc: James Harper <james.harper@bendigoit.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Network not working after restore with qemu-xen
 windows domU and gplpv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 09:11 AM, Fabio Fantoni wrote:
> Il 26/04/2013 12:30, Fabio Fantoni ha scritto:
>> Il 26/04/2013 11:36, Ian Campbell ha scritto:
>>> On Fri, 2013-04-26 at 10:24 +0100, Fabio Fantoni wrote:
>>>> Il 24/04/2013 17:36, Ian Campbell ha scritto:
>>>>> On Wed, 2013-04-24 at 15:06 +0100, Fabio Fantoni wrote:
>>>>>> I send new mail about this bug with details as required by George
>>>>>> Dunlap.
>>>>>> Dom0 is Wheezy 64 bit with kernel from package
>>>>>> linux-image-3.2.0-4-amd64
>>>>>> version 3.2.41-2, package blktap-dkms and all dependency packages for
>>>>>> xen, spice and usb redirection.
>>>>>> xen.git (in this build commit is
>>>>>> 96ef6e88359910738905ac2e1969dc05d7d7e7dc)
>>>>>>
>>>>>> Other details about dom0 installation see here:
>>>>>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02290.html
>>>>>>
>>>>>> DomU is Windows 7 pro 64 bit with gplpv build 372 debug.
>>>>>>
>>>>>> After restore it sees network but is not working, nor lan neither
>>>>>> wan.
>>>>>> Tried with both dhcp and static ip, try also e1000 network card,
>>>>>> tried
>>>>>> also qemu 1.4.
>>>>> Is the vif device present and on the bridge in dom0? What about the
>>>>> emu
>>>>> device?
>>>>>
>>>>> Can you post the output of "xenstore-ls -fp" please.
>>>>>
>>>>> I notice references to openvswitch in your logs -- which script are
>>>>> you
>>>>> using, the one I recently posted or something else?
>>>>>
>>>>> Ian.
>>>>>
>>>>>
>>>> Thanks for reply, the vif and the vif -emu are present, bridge also and
>>>> is working.
>>> Are the both the vif* present on the bridge? What does "ovs-vsctl show"
>>> report?
>>>
>>>> On attachment logs of save, restore, copy of vif and xenstore command
>>>> you told me, both before and after save/restore.
>>> Thanks, I can see that the front and backend devices are connected ok
>>> and appear to be happy and the hotplug scripts were successful.
>>>
>>> However I did notice that the device MAC address seems to have changed!
>>> I can believe this could confuse things...
>>>
>>> Does this issue go away if you specify
>>>           vif=['bridge=xenbr0,mac=00:16:3e:42:ae:8f']
>>> in your configuration?
>>>
>>> Ian.
>>>
>> Thanks, fixed mac solve the problem.
>> Is possible solve for have network working after restore without mac
>> on xl configuration file also on qemu upstream?
>> The last test was without openvswitch, I must redo with it and post
>> "ovs-vsctl show" result?
>>
> This problem is still present and reported also by other users:
> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01267.html

The e-mail you link to there is talking about two different bits of 
functionality.  One is a vif (virtual interface), provided by qemu 
and/or netback; the other is a vf (virtual function), which is related 
to the connection to a physical device..

The question is whether the following configuration now works after 
suspend/resume:

   vif=['']

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:48:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:48:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKmg-0007Vj-8F; Mon, 17 Nov 2014 11:47:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1XqKme-0007VO-Vq
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 11:47:53 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	3A/16-28865-860E9645; Mon, 17 Nov 2014 11:47:52 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416224871!11738139!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16814 invoked from network); 17 Nov 2014 11:47:51 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:47:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413237600"; d="scan'208";a="107596343"
Received: from unknown (HELO type.youpi.perso.aquilenet.fr) ([193.50.110.70])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA;
	17 Nov 2014 12:47:50 +0100
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1XqKmc-0003Wt-LH; Mon, 17 Nov 2014 12:47:50 +0100
Date: Mon, 17 Nov 2014 12:47:50 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Thomas Leonard <talex5@gmail.com>
Message-ID: <20141117114750.GK3953@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Thomas Leonard <talex5@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	David Scott <Dave.Scott@eu.citrix.com>,
	KarimAllah Ahmed <karim.allah.ahmed@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-4-git-send-email-talex5@gmail.com>
	<1413891867.23337.26.camel@citrix.com>
	<20141021215012.GI3481@type.youpi.perso.aquilenet.fr>
	<CAG4opy8H4mk5xnkQT+BLLxMprZ6HFK0hVmQnKoU=NUMmQZw=gQ@mail.gmail.com>
	<20141026095528.GM3695@type.youpi.perso.aquilenet.fr>
	<CAG4opy8ON6w2dUq+1YtPRQDNQ3E+CzbfPf2aT0RcQQBk=inkug@mail.gmail.com>
	<CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
MIME-Version: 1.0
Content-Length: 1365
Content-Disposition: inline
In-Reply-To: <CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH ARM v8 3/4] mini-os: arm: build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thomas Leonard, le Mon 17 Nov 2014 11:42:38 +0000, a =E9crit :
> On 26 October 2014 10:25, Thomas Leonard <talex5@gmail.com> wrote:
> > On 26 October 2014 09:55, Samuel Thibault <samuel.thibault@ens-lyon.org=
> wrote:
> >> Thomas Leonard, le Sun 26 Oct 2014 09:46:09 +0000, a =E9crit :
> >>> Could you say a bit more about the linker problems you had?
> >>
> >> Really digging in the archives this time :)
> >>
> >> ia64-specific:
> >> http://lists.xen.org/archives/html/xen-ia64-devel/2008-03/msg00126.html
> >> http://lists.xen.org/archives/html/xen-ia64-devel/2008-12/msg00070.html
> >> x86_64-specific (missing red zone support)
> >> http://lists.xen.org/archives/html/xen-ia64-devel/2008-02/msg00251.html
> >>
> >> So I guess it could be OK on arm, but you have to make sure that Mini-=
OS
> >> implements the whole ABI that gcc will use. Testing is not enough, I g=
ot
> >> hit by the red zone for instance.
> >
> > On ARM, we have a separate stack for the IRQ handler, so the red zone
> > at least shouldn't be a problem.
> =

> Incidentally, why doesn't Mini-OS/x86 use a red zone?

AIUI, we have nothing in x86 to make interrupts use another stack, so we
can't prevent them from overwriting the red zone even just a bit.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:48:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:48:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKmh-0007Vv-KD; Mon, 17 Nov 2014 11:47:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqKmf-0007VZ-Oe
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 11:47:53 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E6/DD-09936-960E9645; Mon, 17 Nov 2014 11:47:53 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416224871!5251290!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20723 invoked from network); 17 Nov 2014 11:47:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:47:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193498816"
Message-ID: <5469E04D.2090500@citrix.com>
Date: Mon, 17 Nov 2014 11:47:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Thomas Leonard <talex5@gmail.com>, Samuel Thibault
	<samuel.thibault@ens-lyon.org>, Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>, Anil Madhavapeddy
	<anil@recoil.org>, David Scott <Dave.Scott@eu.citrix.com>, KarimAllah Ahmed
	<karim.allah.ahmed@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>	<1412328051-20015-4-git-send-email-talex5@gmail.com>	<1413891867.23337.26.camel@citrix.com>	<20141021215012.GI3481@type.youpi.perso.aquilenet.fr>	<CAG4opy8H4mk5xnkQT+BLLxMprZ6HFK0hVmQnKoU=NUMmQZw=gQ@mail.gmail.com>	<20141026095528.GM3695@type.youpi.perso.aquilenet.fr>	<CAG4opy8ON6w2dUq+1YtPRQDNQ3E+CzbfPf2aT0RcQQBk=inkug@mail.gmail.com>
	<CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
In-Reply-To: <CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
Content-Length: 2071
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH ARM v8 3/4] mini-os: arm: build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTcvMTEvMTQgMTE6NDIsIFRob21hcyBMZW9uYXJkIHdyb3RlOgo+IE9uIDI2IE9jdG9iZXIg
MjAxNCAxMDoyNSwgVGhvbWFzIExlb25hcmQgPHRhbGV4NUBnbWFpbC5jb20+IHdyb3RlOgo+PiBP
biAyNiBPY3RvYmVyIDIwMTQgMDk6NTUsIFNhbXVlbCBUaGliYXVsdCA8c2FtdWVsLnRoaWJhdWx0
QGVucy1seW9uLm9yZz4gd3JvdGU6Cj4+PiBUaG9tYXMgTGVvbmFyZCwgbGUgU3VuIDI2IE9jdCAy
MDE0IDA5OjQ2OjA5ICswMDAwLCBhIMOpY3JpdCA6Cj4+Pj4gQ291bGQgeW91IHNheSBhIGJpdCBt
b3JlIGFib3V0IHRoZSBsaW5rZXIgcHJvYmxlbXMgeW91IGhhZD8KPj4+IFJlYWxseSBkaWdnaW5n
IGluIHRoZSBhcmNoaXZlcyB0aGlzIHRpbWUgOikKPj4+Cj4+PiBpYTY0LXNwZWNpZmljOgo+Pj4g
aHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4taWE2NC1kZXZlbC8yMDA4LTAz
L21zZzAwMTI2Lmh0bWwKPj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVu
LWlhNjQtZGV2ZWwvMjAwOC0xMi9tc2cwMDA3MC5odG1sCj4+PiB4ODZfNjQtc3BlY2lmaWMgKG1p
c3NpbmcgcmVkIHpvbmUgc3VwcG9ydCkKPj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVz
L2h0bWwveGVuLWlhNjQtZGV2ZWwvMjAwOC0wMi9tc2cwMDI1MS5odG1sCj4+Pgo+Pj4gU28gSSBn
dWVzcyBpdCBjb3VsZCBiZSBPSyBvbiBhcm0sIGJ1dCB5b3UgaGF2ZSB0byBtYWtlIHN1cmUgdGhh
dCBNaW5pLU9TCj4+PiBpbXBsZW1lbnRzIHRoZSB3aG9sZSBBQkkgdGhhdCBnY2Mgd2lsbCB1c2Uu
IFRlc3RpbmcgaXMgbm90IGVub3VnaCwgSSBnb3QKPj4+IGhpdCBieSB0aGUgcmVkIHpvbmUgZm9y
IGluc3RhbmNlLgo+PiBPbiBBUk0sIHdlIGhhdmUgYSBzZXBhcmF0ZSBzdGFjayBmb3IgdGhlIElS
USBoYW5kbGVyLCBzbyB0aGUgcmVkIHpvbmUKPj4gYXQgbGVhc3Qgc2hvdWxkbid0IGJlIGEgcHJv
YmxlbS4KPiBJbmNpZGVudGFsbHksIHdoeSBkb2Vzbid0IE1pbmktT1MveDg2IHVzZSBhIHJlZCB6
b25lPyBJIGFzc3VtZSB0aGVyZSdzCj4gYSB3b3J0aHdoaWxlIHBlcmZvcm1hbmNlIGJlbmVmaXQg
dG8gaXQsIGFuZCBpdCB3b3VsZCBwcmV2ZW50IHN1YnRsZQo+IGJ1Z3Mgd2hlbiBzb2Z0d2FyZSBp
cyBhY2NpZGVudGFsbHkgY29tcGlsZWQgZm9yIHRoZSBub3JtYWwgQUJJLgo+Cj4KCktlcm5lbCBj
b2RlIChpbnRlbmRlZCBmb3IgcmluZzApIGNhbm5vdCB1c2UgcmVkIHpvbmVzIGFzIGEgc3RhY2sg
c3dpdGNoCmRvZXNuJ3Qgb2NjdXIgd2hlbiBhbiBleGNlcHRpb24vaW50ZXJydXB0IG9jY3Vycy4g
IENvbXBpbGluZyBhbnkga2VybmVsCmNvZGUgd2l0aCByZWQgem9uZSBzdXBwb3J0IGxlYWRzIHRv
IHN1YnRsZSBjbG9iYmVyaW5nIG9mIHN0YXRlLgoKfkFuZHJldwoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:48:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:48:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKmh-0007Vv-KD; Mon, 17 Nov 2014 11:47:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqKmf-0007VZ-Oe
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 11:47:53 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E6/DD-09936-960E9645; Mon, 17 Nov 2014 11:47:53 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416224871!5251290!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20723 invoked from network); 17 Nov 2014 11:47:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:47:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193498816"
Message-ID: <5469E04D.2090500@citrix.com>
Date: Mon, 17 Nov 2014 11:47:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Thomas Leonard <talex5@gmail.com>, Samuel Thibault
	<samuel.thibault@ens-lyon.org>, Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>, Anil Madhavapeddy
	<anil@recoil.org>, David Scott <Dave.Scott@eu.citrix.com>, KarimAllah Ahmed
	<karim.allah.ahmed@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>	<1412328051-20015-4-git-send-email-talex5@gmail.com>	<1413891867.23337.26.camel@citrix.com>	<20141021215012.GI3481@type.youpi.perso.aquilenet.fr>	<CAG4opy8H4mk5xnkQT+BLLxMprZ6HFK0hVmQnKoU=NUMmQZw=gQ@mail.gmail.com>	<20141026095528.GM3695@type.youpi.perso.aquilenet.fr>	<CAG4opy8ON6w2dUq+1YtPRQDNQ3E+CzbfPf2aT0RcQQBk=inkug@mail.gmail.com>
	<CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
In-Reply-To: <CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
Content-Length: 2071
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH ARM v8 3/4] mini-os: arm: build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTcvMTEvMTQgMTE6NDIsIFRob21hcyBMZW9uYXJkIHdyb3RlOgo+IE9uIDI2IE9jdG9iZXIg
MjAxNCAxMDoyNSwgVGhvbWFzIExlb25hcmQgPHRhbGV4NUBnbWFpbC5jb20+IHdyb3RlOgo+PiBP
biAyNiBPY3RvYmVyIDIwMTQgMDk6NTUsIFNhbXVlbCBUaGliYXVsdCA8c2FtdWVsLnRoaWJhdWx0
QGVucy1seW9uLm9yZz4gd3JvdGU6Cj4+PiBUaG9tYXMgTGVvbmFyZCwgbGUgU3VuIDI2IE9jdCAy
MDE0IDA5OjQ2OjA5ICswMDAwLCBhIMOpY3JpdCA6Cj4+Pj4gQ291bGQgeW91IHNheSBhIGJpdCBt
b3JlIGFib3V0IHRoZSBsaW5rZXIgcHJvYmxlbXMgeW91IGhhZD8KPj4+IFJlYWxseSBkaWdnaW5n
IGluIHRoZSBhcmNoaXZlcyB0aGlzIHRpbWUgOikKPj4+Cj4+PiBpYTY0LXNwZWNpZmljOgo+Pj4g
aHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4taWE2NC1kZXZlbC8yMDA4LTAz
L21zZzAwMTI2Lmh0bWwKPj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVu
LWlhNjQtZGV2ZWwvMjAwOC0xMi9tc2cwMDA3MC5odG1sCj4+PiB4ODZfNjQtc3BlY2lmaWMgKG1p
c3NpbmcgcmVkIHpvbmUgc3VwcG9ydCkKPj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVz
L2h0bWwveGVuLWlhNjQtZGV2ZWwvMjAwOC0wMi9tc2cwMDI1MS5odG1sCj4+Pgo+Pj4gU28gSSBn
dWVzcyBpdCBjb3VsZCBiZSBPSyBvbiBhcm0sIGJ1dCB5b3UgaGF2ZSB0byBtYWtlIHN1cmUgdGhh
dCBNaW5pLU9TCj4+PiBpbXBsZW1lbnRzIHRoZSB3aG9sZSBBQkkgdGhhdCBnY2Mgd2lsbCB1c2Uu
IFRlc3RpbmcgaXMgbm90IGVub3VnaCwgSSBnb3QKPj4+IGhpdCBieSB0aGUgcmVkIHpvbmUgZm9y
IGluc3RhbmNlLgo+PiBPbiBBUk0sIHdlIGhhdmUgYSBzZXBhcmF0ZSBzdGFjayBmb3IgdGhlIElS
USBoYW5kbGVyLCBzbyB0aGUgcmVkIHpvbmUKPj4gYXQgbGVhc3Qgc2hvdWxkbid0IGJlIGEgcHJv
YmxlbS4KPiBJbmNpZGVudGFsbHksIHdoeSBkb2Vzbid0IE1pbmktT1MveDg2IHVzZSBhIHJlZCB6
b25lPyBJIGFzc3VtZSB0aGVyZSdzCj4gYSB3b3J0aHdoaWxlIHBlcmZvcm1hbmNlIGJlbmVmaXQg
dG8gaXQsIGFuZCBpdCB3b3VsZCBwcmV2ZW50IHN1YnRsZQo+IGJ1Z3Mgd2hlbiBzb2Z0d2FyZSBp
cyBhY2NpZGVudGFsbHkgY29tcGlsZWQgZm9yIHRoZSBub3JtYWwgQUJJLgo+Cj4KCktlcm5lbCBj
b2RlIChpbnRlbmRlZCBmb3IgcmluZzApIGNhbm5vdCB1c2UgcmVkIHpvbmVzIGFzIGEgc3RhY2sg
c3dpdGNoCmRvZXNuJ3Qgb2NjdXIgd2hlbiBhbiBleGNlcHRpb24vaW50ZXJydXB0IG9jY3Vycy4g
IENvbXBpbGluZyBhbnkga2VybmVsCmNvZGUgd2l0aCByZWQgem9uZSBzdXBwb3J0IGxlYWRzIHRv
IHN1YnRsZSBjbG9iYmVyaW5nIG9mIHN0YXRlLgoKfkFuZHJldwoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:48:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:48:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKmg-0007Vj-8F; Mon, 17 Nov 2014 11:47:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1XqKme-0007VO-Vq
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 11:47:53 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	3A/16-28865-860E9645; Mon, 17 Nov 2014 11:47:52 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416224871!11738139!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16814 invoked from network); 17 Nov 2014 11:47:51 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 11:47:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413237600"; d="scan'208";a="107596343"
Received: from unknown (HELO type.youpi.perso.aquilenet.fr) ([193.50.110.70])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA;
	17 Nov 2014 12:47:50 +0100
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1XqKmc-0003Wt-LH; Mon, 17 Nov 2014 12:47:50 +0100
Date: Mon, 17 Nov 2014 12:47:50 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Thomas Leonard <talex5@gmail.com>
Message-ID: <20141117114750.GK3953@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Thomas Leonard <talex5@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	David Scott <Dave.Scott@eu.citrix.com>,
	KarimAllah Ahmed <karim.allah.ahmed@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-4-git-send-email-talex5@gmail.com>
	<1413891867.23337.26.camel@citrix.com>
	<20141021215012.GI3481@type.youpi.perso.aquilenet.fr>
	<CAG4opy8H4mk5xnkQT+BLLxMprZ6HFK0hVmQnKoU=NUMmQZw=gQ@mail.gmail.com>
	<20141026095528.GM3695@type.youpi.perso.aquilenet.fr>
	<CAG4opy8ON6w2dUq+1YtPRQDNQ3E+CzbfPf2aT0RcQQBk=inkug@mail.gmail.com>
	<CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
MIME-Version: 1.0
Content-Length: 1365
Content-Disposition: inline
In-Reply-To: <CAG4opy8Uk87Hof5ufyJgfW-1dzxaKLq7_joGKYiGaTPBL6=tMw@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: David Scott <Dave.Scott@eu.citrix.com>, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH ARM v8 3/4] mini-os: arm: build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thomas Leonard, le Mon 17 Nov 2014 11:42:38 +0000, a =E9crit :
> On 26 October 2014 10:25, Thomas Leonard <talex5@gmail.com> wrote:
> > On 26 October 2014 09:55, Samuel Thibault <samuel.thibault@ens-lyon.org=
> wrote:
> >> Thomas Leonard, le Sun 26 Oct 2014 09:46:09 +0000, a =E9crit :
> >>> Could you say a bit more about the linker problems you had?
> >>
> >> Really digging in the archives this time :)
> >>
> >> ia64-specific:
> >> http://lists.xen.org/archives/html/xen-ia64-devel/2008-03/msg00126.html
> >> http://lists.xen.org/archives/html/xen-ia64-devel/2008-12/msg00070.html
> >> x86_64-specific (missing red zone support)
> >> http://lists.xen.org/archives/html/xen-ia64-devel/2008-02/msg00251.html
> >>
> >> So I guess it could be OK on arm, but you have to make sure that Mini-=
OS
> >> implements the whole ABI that gcc will use. Testing is not enough, I g=
ot
> >> hit by the red zone for instance.
> >
> > On ARM, we have a separate stack for the IRQ handler, so the red zone
> > at least shouldn't be a problem.
> =

> Incidentally, why doesn't Mini-OS/x86 use a red zone?

AIUI, we have nothing in x86 to make interrupts use another stack, so we
can't prevent them from overwriting the red zone even just a bit.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:51:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKqS-00081L-9z; Mon, 17 Nov 2014 11:51:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqKqQ-0007xP-6S
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 11:51:46 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	A9/3D-02954-151E9645; Mon, 17 Nov 2014 11:51:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416225104!9687998!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21526 invoked from network); 17 Nov 2014 11:51:44 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 11:51:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 11:51:44 +0000
Message-Id: <5469EF5D0200007800048609@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 11:51:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
In-Reply-To: <5469DCD7.4030701@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 12:32, <tiejun.chen@intel.com> wrote:
> On 2014/11/17 19:17, Jan Beulich wrote:
>>>>> On 17.11.14 at 12:08, <tiejun.chen@intel.com> wrote:
>>
>>> On 2014/11/17 18:05, Jan Beulich wrote:
>>>>>>> On 17.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
>>>>> --- a/xen/common/memory.c
>>>>> +++ b/xen/common/memory.c
>>>>> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>>>>>         unsigned int used_entries;
>>>>>     };
>>>>>
>>>>> -static int get_reserved_device_memory(xen_pfn_t start,
>>>>> -                                      xen_ulong_t nr, void *ctxt)
>>>>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16
>>> seg,
>>>>> +                                      u16 *ids, int cnt, void *ctxt)
>>>>
>>>> While the approach is a lot better than what you did previously, I still
>>>> don't like you adding 3 new parameters when one would do (calling
>>>> the callback for each SBDF individually): That way you avoid
>>>
>>> Do you mean I should do this?
>>>
>>> for_each_rmrr_device ( rmrr, bdf, i )
>>> {
>>> 	 sbdf = PCI_SBDF(seg, rmrr->scope.devices[i]);
>>>            rc = func(PFN_DOWN(rmrr->base_address),
>>>                      PFN_UP(rmrr->end_address) -
>>> PFN_DOWN(rmrr->base_address),
>>> 		   sbdf,	
>>>                      ctxt);
>>>
>>> But each different sbdf may occupy one same rmrr entry as I said
>>> previously, so we have to introduce more codes to filter them as one
>>> identified entry in the callback.
>>
>> Not really - remember that part of what needs to be done is to make
>> sure all devices associated with a given RMRR get assigned to the
>> same guest? Or the callback function could use a special return value
> 
> Yes, but I means in the callback,
> 
> get_reserved_device_memory()
> {
> 	...
> 	for(each assigned pci devs:pt_sbdf)
> 		if (sbdf == pt_sbdf)
> 			__copy_to_guest_offset(buffer, ...)
> 
> Buffer may be copied to include multiple same entries if we have two or 
> more assigned devices associated to one give RMRR entry.

Which would be easily avoided by ...

>> (e.g. 1) to signal that the iteration for the current RMRR can be
>> terminated (or further entries skipped).

... the approach I outlined.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 11:51:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 11:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqKqS-00081L-9z; Mon, 17 Nov 2014 11:51:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqKqQ-0007xP-6S
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 11:51:46 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	A9/3D-02954-151E9645; Mon, 17 Nov 2014 11:51:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416225104!9687998!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21526 invoked from network); 17 Nov 2014 11:51:44 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 11:51:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 11:51:44 +0000
Message-Id: <5469EF5D0200007800048609@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 11:51:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
In-Reply-To: <5469DCD7.4030701@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 12:32, <tiejun.chen@intel.com> wrote:
> On 2014/11/17 19:17, Jan Beulich wrote:
>>>>> On 17.11.14 at 12:08, <tiejun.chen@intel.com> wrote:
>>
>>> On 2014/11/17 18:05, Jan Beulich wrote:
>>>>>>> On 17.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
>>>>> --- a/xen/common/memory.c
>>>>> +++ b/xen/common/memory.c
>>>>> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>>>>>         unsigned int used_entries;
>>>>>     };
>>>>>
>>>>> -static int get_reserved_device_memory(xen_pfn_t start,
>>>>> -                                      xen_ulong_t nr, void *ctxt)
>>>>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16
>>> seg,
>>>>> +                                      u16 *ids, int cnt, void *ctxt)
>>>>
>>>> While the approach is a lot better than what you did previously, I still
>>>> don't like you adding 3 new parameters when one would do (calling
>>>> the callback for each SBDF individually): That way you avoid
>>>
>>> Do you mean I should do this?
>>>
>>> for_each_rmrr_device ( rmrr, bdf, i )
>>> {
>>> 	 sbdf = PCI_SBDF(seg, rmrr->scope.devices[i]);
>>>            rc = func(PFN_DOWN(rmrr->base_address),
>>>                      PFN_UP(rmrr->end_address) -
>>> PFN_DOWN(rmrr->base_address),
>>> 		   sbdf,	
>>>                      ctxt);
>>>
>>> But each different sbdf may occupy one same rmrr entry as I said
>>> previously, so we have to introduce more codes to filter them as one
>>> identified entry in the callback.
>>
>> Not really - remember that part of what needs to be done is to make
>> sure all devices associated with a given RMRR get assigned to the
>> same guest? Or the callback function could use a special return value
> 
> Yes, but I means in the callback,
> 
> get_reserved_device_memory()
> {
> 	...
> 	for(each assigned pci devs:pt_sbdf)
> 		if (sbdf == pt_sbdf)
> 			__copy_to_guest_offset(buffer, ...)
> 
> Buffer may be copied to include multiple same entries if we have two or 
> more assigned devices associated to one give RMRR entry.

Which would be easily avoided by ...

>> (e.g. 1) to signal that the iteration for the current RMRR can be
>> terminated (or further entries skipped).

... the approach I outlined.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:07:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12: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 1XqL4x-00007a-WD; Mon, 17 Nov 2014 12:06:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqL4w-00007T-V9
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:06:47 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	5C/DA-27623-6D4E9645; Mon, 17 Nov 2014 12:06:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416226005!8147054!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 330 invoked from network); 17 Nov 2014 12:06:45 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 12:06:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 12:06:45 +0000
Message-Id: <5469F2E2020000780004862C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 12:06:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Don Dugger" <donald.d.dugger@intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
In-Reply-To: <E1XqDee-0007TD-RN@maat.n0ano.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: eddie.dong@intel.com, will.auld@intel.com, allen.m.kay@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 05:11, <donald.d.dugger@intel.com> wrote:
> @@ -237,6 +254,18 @@
>      }
>  }
>  
> +static void __init parse_snb_timeout(const char *s)
> +{
> +
> +	if (*s == '\0')
> +		snb_igd_timeout = SNB_IGD_TIMEOUT;
> +	else
> +		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
> +	snb_igd_quirk = 1;
> +	return;
> +}
> +custom_param("snb_igd_timeout", parse_snb_timeout);

Rather than adding a new command line option, can't you simply
re-use (by extending) the existing (boolean) one? And similarly
replace the current variable (using a value of zero to indicate no
quirk) rather than adding another one?

Also note that the if() statement above needs spaces inserted to
match our coding style.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:07:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12: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 1XqL4x-00007a-WD; Mon, 17 Nov 2014 12:06:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqL4w-00007T-V9
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:06:47 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	5C/DA-27623-6D4E9645; Mon, 17 Nov 2014 12:06:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416226005!8147054!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 330 invoked from network); 17 Nov 2014 12:06:45 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 12:06:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 12:06:45 +0000
Message-Id: <5469F2E2020000780004862C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 12:06:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Don Dugger" <donald.d.dugger@intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
In-Reply-To: <E1XqDee-0007TD-RN@maat.n0ano.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: eddie.dong@intel.com, will.auld@intel.com, allen.m.kay@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 05:11, <donald.d.dugger@intel.com> wrote:
> @@ -237,6 +254,18 @@
>      }
>  }
>  
> +static void __init parse_snb_timeout(const char *s)
> +{
> +
> +	if (*s == '\0')
> +		snb_igd_timeout = SNB_IGD_TIMEOUT;
> +	else
> +		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
> +	snb_igd_quirk = 1;
> +	return;
> +}
> +custom_param("snb_igd_timeout", parse_snb_timeout);

Rather than adding a new command line option, can't you simply
re-use (by extending) the existing (boolean) one? And similarly
replace the current variable (using a value of zero to indicate no
quirk) rather than adding another one?

Also note that the if() statement above needs spaces inserted to
match our coding style.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:10:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqL8i-0000KB-L8; Mon, 17 Nov 2014 12:10:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqL8h-0000K5-Ec
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:10:39 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	3E/F9-25727-EB5E9645; Mon, 17 Nov 2014 12:10:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416226236!11810885!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7778 invoked from network); 17 Nov 2014 12:10:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:10:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193504263"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 07:10:36 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XqL8c-0002py-Vj;
	Mon, 17 Nov 2014 12:10:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 17 Nov 2014 12:10:34 +0000
Message-ID: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, liang.z.li@intel.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for PCI
	device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The existence check is to make sure a device is not added to a guest
multiple times.

PCI device backend path has different rules from vif, disk etc. For
example:
/local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
/local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
/local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
/local/domain/0/backend/pci/9/0/key-2/0000:03:10.2

The devid for PCI devices is hardcoded 0. libxl__device_exists only
checks up to /local/.../9/0 so it always returns true even the device is
assignable.

Remove invocation of libxl__device_exists. We're sure at this point that
the PCI device is assignable (hence no xenstore entry or JSON entry).
The check is done before hand. For HVM guest it's done by calling
xc_test_assign_device and for PV guest it's done by calling
pciback_dev_is_assigned.

Reported-by: Li, Liang Z <liang.z.li@intel.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
---
This patch fixes a regression in 4.5.

The risk is that I misunderstood semantics of xc_test_assign_device and
pciback_dev_is_assigned and end up adding several entries to JSON config
template. But if the assignable tests are incorrect I think we have a
bigger problem to worry about than duplicated entries in JSON template.

It would be good for someone to have PCI hotplug setup to run a quick test.  I
think Liang confirmed (indrectly) that xc_test_assign_device worked well for
him so I think there's won't be multiple JSON template entries for HVM guests.
However PV side still remains to be tested.
---
 tools/libxl/libxl_pci.c |    8 --------
 1 file changed, 8 deletions(-)

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 9f40100..316643c 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -175,14 +175,6 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
         rc = libxl__xs_transaction_start(gc, &t);
         if (rc) goto out;
 
-        rc = libxl__device_exists(gc, t, device);
-        if (rc < 0) goto out;
-        if (rc == 1) {
-            LOG(ERROR, "device already exists in xenstore");
-            rc = ERROR_DEVICE_EXISTS;
-            goto out;
-        }
-
         rc = libxl__set_domain_configuration(gc, domid, &d_config);
         if (rc) goto out;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:10:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqL8i-0000KB-L8; Mon, 17 Nov 2014 12:10:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqL8h-0000K5-Ec
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:10:39 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	3E/F9-25727-EB5E9645; Mon, 17 Nov 2014 12:10:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416226236!11810885!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7778 invoked from network); 17 Nov 2014 12:10:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:10:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193504263"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 07:10:36 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XqL8c-0002py-Vj;
	Mon, 17 Nov 2014 12:10:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 17 Nov 2014 12:10:34 +0000
Message-ID: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, liang.z.li@intel.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for PCI
	device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The existence check is to make sure a device is not added to a guest
multiple times.

PCI device backend path has different rules from vif, disk etc. For
example:
/local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
/local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
/local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
/local/domain/0/backend/pci/9/0/key-2/0000:03:10.2

The devid for PCI devices is hardcoded 0. libxl__device_exists only
checks up to /local/.../9/0 so it always returns true even the device is
assignable.

Remove invocation of libxl__device_exists. We're sure at this point that
the PCI device is assignable (hence no xenstore entry or JSON entry).
The check is done before hand. For HVM guest it's done by calling
xc_test_assign_device and for PV guest it's done by calling
pciback_dev_is_assigned.

Reported-by: Li, Liang Z <liang.z.li@intel.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
---
This patch fixes a regression in 4.5.

The risk is that I misunderstood semantics of xc_test_assign_device and
pciback_dev_is_assigned and end up adding several entries to JSON config
template. But if the assignable tests are incorrect I think we have a
bigger problem to worry about than duplicated entries in JSON template.

It would be good for someone to have PCI hotplug setup to run a quick test.  I
think Liang confirmed (indrectly) that xc_test_assign_device worked well for
him so I think there's won't be multiple JSON template entries for HVM guests.
However PV side still remains to be tested.
---
 tools/libxl/libxl_pci.c |    8 --------
 1 file changed, 8 deletions(-)

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 9f40100..316643c 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -175,14 +175,6 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
         rc = libxl__xs_transaction_start(gc, &t);
         if (rc) goto out;
 
-        rc = libxl__device_exists(gc, t, device);
-        if (rc < 0) goto out;
-        if (rc == 1) {
-            LOG(ERROR, "device already exists in xenstore");
-            rc = ERROR_DEVICE_EXISTS;
-            goto out;
-        }
-
         rc = libxl__set_domain_configuration(gc, domid, &d_config);
         if (rc) goto out;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:10:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqL8n-0000Ki-0d; Mon, 17 Nov 2014 12:10:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1XqL8l-0000KT-NK
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 12:10:43 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	32/F5-02559-2C5E9645; Mon, 17 Nov 2014 12:10:42 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416226240!13034889!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29861 invoked from network); 17 Nov 2014 12:10:42 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 12:10:42 -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 sAHCAb4n000646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 17 Nov 2014 07:10:37 -0500
Received: from redhat.com (ovpn-116-95.ams2.redhat.com [10.36.116.95])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sAHCAYKK002832; Mon, 17 Nov 2014 07:10:35 -0500
Date: Mon, 17 Nov 2014 14:10:34 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141117121034.GB10709@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
	<20141117061010.GB19718@redhat.com> <5469B660.6040107@intel.com>
	<20141117092501.GA20133@redhat.com> <5469C2F4.4020304@intel.com>
	<20141117101342.GF20133@redhat.com> <5469D979.8050404@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5469D979.8050404@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 07:18:17PM +0800, Chen, Tiejun wrote:
> On 2014/11/17 18:13, Michael S. Tsirkin wrote:
> >On Mon, Nov 17, 2014 at 05:42:12PM +0800, Chen, Tiejun wrote:
> >>On 2014/11/17 17:25, Michael S. Tsirkin wrote:
> >>>On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/11/17 14:10, Michael S. Tsirkin wrote:
> >>>>>On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/11/5 22:09, Michael S. Tsirkin wrote:
> >>>>>>>On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
> >>>>>>>>Currently IGD drivers always need to access PCH by 1f.0, and
> >>>>>>>>PCH vendor/device id is used to identify the card.
> >>>>>>>>
> >>>>>>>>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>>>>>>>---
> >>
> >>[snip]
> >>
> >>>Cleaner:
> >>>	 if (!pci_dev) {
> >>>		fprintf
> >>>		return;
> >>>	}
> >>>          pci_config_set_device_id(pci_dev->config, pch_id);
> >>
> >>I will address all comments and thanks.
> >>
> >>>
> >>>>+    }
> >>>>+}
> >>>>+
> >>>>  /* init */
> >>>>
> >>>>  static int xen_pt_initfn(PCIDevice *d)
> >>>>@@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
> >>>>          return -1;
> >>>>      }
> >>>>
> >>>>+    /* Register ISA bridge for passthrough GFX. */
> >>>>+    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
> >>>>+
> >>>>      /* reinitialize each config register to be emulated */
> >>>>      if (xen_pt_config_init(s)) {
> >>>>          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
> >>>>
> >>>>Note I will introduce a inline function in another patch,
> >>>>
> >>>>+static inline int is_vga_passthrough(XenHostPCIDevice *dev)
> >>>>+{
> >>>>+    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
> >>>>+            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
> >>>>+}
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>Why bother with all these conditions?
> >>>Won't it be enough to check dev->vendor_id == PCI_VENDOR_ID_INTEL?
> >>>
> >>
> >>If this is just used for IGD, its always fine without checking vendor_id.
> >
> >You need to match device ID to *know* it's IGD.
> >
> >>So after remove that check, I guess I need to rename that as
> >>is_igd_vga_passthrough() to make sense.
> >>
> >>Thanks
> >>Tiejun
> >
> >There is no need to check class code or xen_has_gfx_passthru flag.
> >Device ID + vendor ID identifies each device uniquely.
> >
> 
> Yeah.
> 
> Here I assume vendor ID is always PCI_VENDOR_ID_INTEL so looks you means I
> also need to check that table to do something like,
> 
> is_igd_vga_passthugh(dev)
> {	
> 	int i;
> 	int num = ARRAY_SIZE(xen_igd_combo_id_infos);
> 	for (i = 0; i < num; i++) {
> 		if (dev->device_id == xen_igd_combo_id_infos[i].gpu_device_id)
> 			return 1;
> 	return 0;
> }
> 
> Then we can simplify the subsequent codes based on this, right?
> 
> Thanks
> Tiejun

Yea.
Basically let's try to treat this simply as a device quirk,
and see where this gets us.

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:10:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqL8n-0000Ki-0d; Mon, 17 Nov 2014 12:10:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1XqL8l-0000KT-NK
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 12:10:43 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	32/F5-02559-2C5E9645; Mon, 17 Nov 2014 12:10:42 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416226240!13034889!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29861 invoked from network); 17 Nov 2014 12:10:42 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 12:10:42 -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 sAHCAb4n000646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 17 Nov 2014 07:10:37 -0500
Received: from redhat.com (ovpn-116-95.ams2.redhat.com [10.36.116.95])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sAHCAYKK002832; Mon, 17 Nov 2014 07:10:35 -0500
Date: Mon, 17 Nov 2014 14:10:34 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141117121034.GB10709@redhat.com>
References: <1415172179-7965-1-git-send-email-tiejun.chen@intel.com>
	<1415172179-7965-2-git-send-email-tiejun.chen@intel.com>
	<20141105140906.GA4912@redhat.com> <546961DC.4040300@intel.com>
	<20141117061010.GB19718@redhat.com> <5469B660.6040107@intel.com>
	<20141117092501.GA20133@redhat.com> <5469C2F4.4020304@intel.com>
	<20141117101342.GF20133@redhat.com> <5469D979.8050404@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5469D979.8050404@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org,
	aliguori@amazon.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix:
 create isa bridge specific to IGD passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 07:18:17PM +0800, Chen, Tiejun wrote:
> On 2014/11/17 18:13, Michael S. Tsirkin wrote:
> >On Mon, Nov 17, 2014 at 05:42:12PM +0800, Chen, Tiejun wrote:
> >>On 2014/11/17 17:25, Michael S. Tsirkin wrote:
> >>>On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/11/17 14:10, Michael S. Tsirkin wrote:
> >>>>>On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/11/5 22:09, Michael S. Tsirkin wrote:
> >>>>>>>On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
> >>>>>>>>Currently IGD drivers always need to access PCH by 1f.0, and
> >>>>>>>>PCH vendor/device id is used to identify the card.
> >>>>>>>>
> >>>>>>>>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>>>>>>>---
> >>
> >>[snip]
> >>
> >>>Cleaner:
> >>>	 if (!pci_dev) {
> >>>		fprintf
> >>>		return;
> >>>	}
> >>>          pci_config_set_device_id(pci_dev->config, pch_id);
> >>
> >>I will address all comments and thanks.
> >>
> >>>
> >>>>+    }
> >>>>+}
> >>>>+
> >>>>  /* init */
> >>>>
> >>>>  static int xen_pt_initfn(PCIDevice *d)
> >>>>@@ -682,6 +770,9 @@ static int xen_pt_initfn(PCIDevice *d)
> >>>>          return -1;
> >>>>      }
> >>>>
> >>>>+    /* Register ISA bridge for passthrough GFX. */
> >>>>+    xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
> >>>>+
> >>>>      /* reinitialize each config register to be emulated */
> >>>>      if (xen_pt_config_init(s)) {
> >>>>          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
> >>>>
> >>>>Note I will introduce a inline function in another patch,
> >>>>
> >>>>+static inline int is_vga_passthrough(XenHostPCIDevice *dev)
> >>>>+{
> >>>>+    return (xen_has_gfx_passthru && (dev->vendor_id == PCI_VENDOR_ID_INTEL)
> >>>>+            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
> >>>>+}
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>Why bother with all these conditions?
> >>>Won't it be enough to check dev->vendor_id == PCI_VENDOR_ID_INTEL?
> >>>
> >>
> >>If this is just used for IGD, its always fine without checking vendor_id.
> >
> >You need to match device ID to *know* it's IGD.
> >
> >>So after remove that check, I guess I need to rename that as
> >>is_igd_vga_passthrough() to make sense.
> >>
> >>Thanks
> >>Tiejun
> >
> >There is no need to check class code or xen_has_gfx_passthru flag.
> >Device ID + vendor ID identifies each device uniquely.
> >
> 
> Yeah.
> 
> Here I assume vendor ID is always PCI_VENDOR_ID_INTEL so looks you means I
> also need to check that table to do something like,
> 
> is_igd_vga_passthugh(dev)
> {	
> 	int i;
> 	int num = ARRAY_SIZE(xen_igd_combo_id_infos);
> 	for (i = 0; i < num; i++) {
> 		if (dev->device_id == xen_igd_combo_id_infos[i].gpu_device_id)
> 			return 1;
> 	return 0;
> }
> 
> Then we can simplify the subsequent codes based on this, right?
> 
> Thanks
> Tiejun

Yea.
Basically let's try to treat this simply as a device quirk,
and see where this gets us.

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:14:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:14:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLBv-0000d4-7o; Mon, 17 Nov 2014 12:13:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqLBt-0000cp-RR
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 12:13:58 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	E9/33-02702-586E9645; Mon, 17 Nov 2014 12:13:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416226431!13035991!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28097 invoked from network); 17 Nov 2014 12:13:54 -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;
	17 Nov 2014 12:13:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="192009430"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 07:13:50 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqLBm-000578-0E;
	Mon, 17 Nov 2014 12:13:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqLBl-00030w-QD;
	Mon, 17 Nov 2014 12:13:49 +0000
Date: Mon, 17 Nov 2014 12:13:49 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31635-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31635: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31635 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31635/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail pass in 31644-bisect

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:14:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:14:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLBv-0000d4-7o; Mon, 17 Nov 2014 12:13:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqLBt-0000cp-RR
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 12:13:58 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	E9/33-02702-586E9645; Mon, 17 Nov 2014 12:13:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416226431!13035991!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28097 invoked from network); 17 Nov 2014 12:13:54 -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;
	17 Nov 2014 12:13:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="192009430"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 07:13:50 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqLBm-000578-0E;
	Mon, 17 Nov 2014 12:13:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqLBl-00030w-QD;
	Mon, 17 Nov 2014 12:13:49 +0000
Date: Mon, 17 Nov 2014 12:13:49 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31635-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31635: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31635 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31635/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail pass in 31644-bisect

version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-i386-rumpuserxen-i386                             fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9716ed62cb1d73254b552e2077497d684c81639d
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:49:40 2014 +0100

    Add .gitignore for tests/configure autoconf cruft
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47
Merge: 3dec9eb 62d0714
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:44:10 2014 +0100

    Merge pull request #11 from mato/wip-exit
    
    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.

commit 62d07142e5b4c77633bd1283ac06bd71f29d777a
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 16:11:46 2014 +0100

    rumpuser_exit(), _exit(): Cleanly halt Mini-OS.
    
    rumpuser_exit() and _exit() were calling minios_do_exit() which is
    intended to be called from an exception context and/or other "panic"
    situation.  This was causing the stack trace code in minios_do_exit() to
    walk off into never never land when the rumprun-xen application called
    exit() or returned from main().
    
    This commit adds a new minios_do_halt(reason) function, with the reason
    code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently
    only poweroff and crash are implemented.
    
    We then modify the rumpuser_exit() and _exit() functions to correctly
    shut down the domain by calling minios_stop_kernel() followed by
    minios_do_halt(MINIOS_HALT_POWEROFF).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3dec9eb4656a1af934f4c4222476a77384b2c487
Merge: 1eb3666 f5247f8
Author: Martin Lucina <martin@lucina.net>
Date:   Tue Nov 11 15:47:08 2014 +0100

    Merge pull request #10 from mato/wip-xenos
    
    Clean up Mini-OS namespace

commit f5247f87792ab5084664be70b409964691d14f43
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 18:12:34 2014 +0100

    Reinstate old demos
    
    Xen project osstest CI depends on them, and we do not want to remove
    them before a replacement is ready.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 8bd474a4674110ca0fd75d557dc40532a63cc35b
Author: Martin Lucina <martin@lucina.net>
Date:   Mon Nov 10 11:05:31 2014 +0100

    Synchronise x86_32.o with Mini-OS namespace cleanup.
    
    These changes sync the x86_32 arch-specific entrypoints with the Mini-OS
    namespace cleanups. Now builds and runs correctly on x86.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 038ec394c921b5fed8c3e3afee4e09125726dc8c
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:17:00 2014 +0100

    Minor improvement to hello demo
    
    Sleep in the demo to prove at least scheduling is working after all the
    renaming changes.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 18:14:50 2014 +0100

    Localize all non-public Mini-OS symbols
    
    Pass 3 of X in Mini-OS namespace cleanup.
    
    We define a set of prefixes in the Makefile for the symbol namespaces we
    wish to keep. Then, when linking minios.o we use objcopy to localize all
    other symbols. Note the sole exception of the arch-specific startup file
    (x86_64.o) as this is used as the linker %startfile.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 4a8991242b6dc5881fc72a8c37a914afe54de042
Author: Martin Lucina <martin@lucina.net>
Date:   Fri Nov 7 17:52:39 2014 +0100

    Clean up Mini-OS public namespace
    
    Pass 2 of X in cleaning up Mini-OS namespace:
    
    - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
      _minios_* for strictly internal functions, except those in the
      blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
    - In the case of drivers, eg. init|shutdown_blkfront are renamed to
      blkfront_*.
    - All global variables are either manually made local, or placed under
      the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
      and those variables under driver namespaces kept above.
    - All callers are updated to use the new names. Where it makes sense,
      macros such as alloc_page are also renamed into the minios_ namespace.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 255a9da6642ff1b72f6cc3437b480c9322b8c42d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:11:24 2014 +0100

    Build Mini-OS and rump kernel middleware as discrete objects
    
    In order to be able to make Mini-OS symbols local using objcopy we need to
    build Mini-OS as a discrete relocatable object. While we're here, put the
    various rump kernel middleware (libc stubs, rumphyper implementation)
    into its own object file also.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 9fe6b0a5006cace2aaeedeed9442f7b83c39d47d
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 17:06:46 2014 +0100

    Clean up x86_64.o entry point namespace
    
    This is pass 1 of X of cleaning up mini-os symbol namespace:
    
    - Namespace all globals in x86_64.o (except _start) as _minios_XXX.
    - Fix dependent calling code to use the new namespace
      (hypercall-x86_64.h, sched.h, xen/arch/x86/*.c).
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 3a5227edd6ff8329e690a4b282278017188052df
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 11:35:54 2014 +0100

    Update .gitignore
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

commit 1abd7c285ad56b6a53c74405292b9e43d58be888
Author: Martin Lucina <martin@lucina.net>
Date:   Thu Nov 6 10:58:25 2014 +0100

    Remove old demo from build, add simple hello-world test
    
    In preparation for cleaning up minios/xenos to resolve (among other
    things) symbol namespacing issues, remove the old non-app-tools-based
    demo from the build.
    
    As a temporary replacement add in a simple (not configure-based) "Hello,
    world!" in tests/hello.
    
    Signed-off-by: Martin Lucina <martin@lucina.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:25:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLMT-00015u-Dx; Mon, 17 Nov 2014 12:24: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@citrix.com>) id 1XqLMS-00015l-0b
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 12:24:52 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	71/7F-26652-319E9645; Mon, 17 Nov 2014 12:24:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416227089!11747945!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20871 invoked from network); 17 Nov 2014 12:24:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:24:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193507248"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 07:24:48 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqLMN-0003C1-UP;
	Mon, 17 Nov 2014 12:24:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqLMM-0000lT-SN;
	Mon, 17 Nov 2014 12:24:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21609.59662.452571.279233@mariner.uk.xensource.com>
Date: Mon, 17 Nov 2014 12:24:46 +0000
To: <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-31553-mainreport@xen.org>
References: <osstest-31553-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com
Subject: Re: [Xen-devel] [seabios test] 31553: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("[seabios test] 31553: regressions - FAIL"):
> flight 31553 seabios real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31553/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair   18 guest-migrate/dst_host/src_host fail REGR. vs. 30767

This was the swiotlb bug, and everything else here is fine, so I force
pushed (with ap-push).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:25:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLMT-00015u-Dx; Mon, 17 Nov 2014 12:24: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@citrix.com>) id 1XqLMS-00015l-0b
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 12:24:52 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	71/7F-26652-319E9645; Mon, 17 Nov 2014 12:24:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416227089!11747945!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20871 invoked from network); 17 Nov 2014 12:24:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:24:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193507248"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 07:24:48 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqLMN-0003C1-UP;
	Mon, 17 Nov 2014 12:24:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqLMM-0000lT-SN;
	Mon, 17 Nov 2014 12:24:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21609.59662.452571.279233@mariner.uk.xensource.com>
Date: Mon, 17 Nov 2014 12:24:46 +0000
To: <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-31553-mainreport@xen.org>
References: <osstest-31553-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: ian.campbell@eu.citrix.com
Subject: Re: [Xen-devel] [seabios test] 31553: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("[seabios test] 31553: regressions - FAIL"):
> flight 31553 seabios real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31553/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair   18 guest-migrate/dst_host/src_host fail REGR. vs. 30767

This was the swiotlb bug, and everything else here is fine, so I force
pushed (with ap-push).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:26:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:26:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLOA-0001DW-TR; Mon, 17 Nov 2014 12:26:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqLOA-0001DP-84
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 12:26:38 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	54/F7-11608-D79E9645; Mon, 17 Nov 2014 12:26:37 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416227195!11906516!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7199 invoked from network); 17 Nov 2014 12:26:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:26:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193507561"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 07:26:34 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqLO5-0003Dh-Rs;
	Mon, 17 Nov 2014 12:26:33 +0000
Date: Mon, 17 Nov 2014 12:26:33 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Fabio Fantoni <fantonifabio@tiscali.it>
Message-ID: <20141117122633.GA23296@zion.uk.xensource.com>
References: <5177E6FD.7050707@tiscali.it>
	<1366817792.20256.374.camel@zakaz.uk.xensource.com>
	<517A47B3.4040600@tiscali.it>
	<1366968964.3142.52.camel@zakaz.uk.xensource.com>
	<517A5755.7080302@tiscali.it> <5465C752.1030208@tiscali.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5465C752.1030208@tiscali.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	James Harper <james.harper@bendigoit.com.au>
Subject: Re: [Xen-devel] Network not working after restore with qemu-xen
 windows domU and gplpv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Can you make sure you don't specified mac for vif then

$ xl save $WIN saved.img
$ hexdump -C -n1024 saved.img

Look for nics in output and paste the it here. You might want to change
1024 to something larger if you specified many options in your config
file.

A sample output for my PV guest which doesn't have mac specified.

00000000  58 65 6e 20 73 61 76 65  64 20 64 6f 6d 61 69 6e  |Xen saved domain|
00000010  2c 20 78 6c 20 66 6f 72  6d 61 74 0a 20 00 20 0d  |, xl format. . .|
00000020  04 03 02 01 01 00 00 00  00 00 00 00 98 03 00 00  |................|
00000030  94 03 00 00 7b 0a 20 20  20 20 22 63 5f 69 6e 66  |....{.    "c_inf|
00000040  6f 22 3a 20 7b 0a 20 20  20 20 20 20 20 20 22 74  |o": {.        "t|
[...]
000002f0  22 3a 20 31 0a 20 20 20  20 20 20 20 20 7d 0a 20  |": 1.        }. |
00000300  20 20 20 5d 2c 0a 20 20  20 20 22 6e 69 63 73 22  |   ],.    "nics"|
00000310  3a 20 5b 0a 20 20 20 20  20 20 20 20 7b 0a 20 20  |: [.        {.  |
00000320  20 20 20 20 20 20 20 20  20 20 22 64 65 76 69 64  |          "devid|
00000330  22 3a 20 30 2c 0a 20 20  20 20 20 20 20 20 20 20  |": 0,.          |
00000340  20 20 22 6d 61 63 22 3a  20 22 30 30 3a 31 36 3a  |  "mac": "00:16:|
00000350  33 65 3a 36 61 3a 62 37  3a 35 31 22 2c 0a 20 20  |3e:6a:b7:51",.  |
00000360  20 20 20 20 20 20 20 20  20 20 22 62 72 69 64 67  |          "bridg|
00000370  65 22 3a 20 22 78 65 6e  62 72 30 22 0a 20 20 20  |e": "xenbr0".   |
00000380  20 20 20 20 20 7d 0a 20  20 20 20 5d 2c 0a 20 20  |     }.    ],.  |
00000390  20 20 22 6f 6e 5f 72 65  62 6f 6f 74 22 3a 20 22  |  "on_reboot": "|
000003a0  72 65 73 74 61 72 74 22  2c 0a 20 20 20 20 22 6f  |restart",.    "o|
000003b0  6e 5f 63 72 61 73 68 22  3a 20 22 70 72 65 73 65  |n_crash": "prese|
000003c0  72 76 65 22 0a 7d 0a 00  00 00 02 00 00 00 00 00  |rve".}..........|
000003d0  ff ff ff ff ff ff ff ff  40 14 00 00 76 63 70 75  |........@...vcpu|
000003e0  30 14 00 00 7f 03 00 00  00 00 00 00 00 00 00 00  |0...............|
000003f0  00 00 00 00 00 00 00 00  00 00 00 00 80 1f 00 00  |................|

As you can see there's a "mac" in right hand column, which is generated
by libxl and saved.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:26:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:26:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLOA-0001DW-TR; Mon, 17 Nov 2014 12:26:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XqLOA-0001DP-84
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 12:26:38 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	54/F7-11608-D79E9645; Mon, 17 Nov 2014 12:26:37 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416227195!11906516!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7199 invoked from network); 17 Nov 2014 12:26:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:26:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193507561"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 07:26:34 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XqLO5-0003Dh-Rs;
	Mon, 17 Nov 2014 12:26:33 +0000
Date: Mon, 17 Nov 2014 12:26:33 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Fabio Fantoni <fantonifabio@tiscali.it>
Message-ID: <20141117122633.GA23296@zion.uk.xensource.com>
References: <5177E6FD.7050707@tiscali.it>
	<1366817792.20256.374.camel@zakaz.uk.xensource.com>
	<517A47B3.4040600@tiscali.it>
	<1366968964.3142.52.camel@zakaz.uk.xensource.com>
	<517A5755.7080302@tiscali.it> <5465C752.1030208@tiscali.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5465C752.1030208@tiscali.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	James Harper <james.harper@bendigoit.com.au>
Subject: Re: [Xen-devel] Network not working after restore with qemu-xen
 windows domU and gplpv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Can you make sure you don't specified mac for vif then

$ xl save $WIN saved.img
$ hexdump -C -n1024 saved.img

Look for nics in output and paste the it here. You might want to change
1024 to something larger if you specified many options in your config
file.

A sample output for my PV guest which doesn't have mac specified.

00000000  58 65 6e 20 73 61 76 65  64 20 64 6f 6d 61 69 6e  |Xen saved domain|
00000010  2c 20 78 6c 20 66 6f 72  6d 61 74 0a 20 00 20 0d  |, xl format. . .|
00000020  04 03 02 01 01 00 00 00  00 00 00 00 98 03 00 00  |................|
00000030  94 03 00 00 7b 0a 20 20  20 20 22 63 5f 69 6e 66  |....{.    "c_inf|
00000040  6f 22 3a 20 7b 0a 20 20  20 20 20 20 20 20 22 74  |o": {.        "t|
[...]
000002f0  22 3a 20 31 0a 20 20 20  20 20 20 20 20 7d 0a 20  |": 1.        }. |
00000300  20 20 20 5d 2c 0a 20 20  20 20 22 6e 69 63 73 22  |   ],.    "nics"|
00000310  3a 20 5b 0a 20 20 20 20  20 20 20 20 7b 0a 20 20  |: [.        {.  |
00000320  20 20 20 20 20 20 20 20  20 20 22 64 65 76 69 64  |          "devid|
00000330  22 3a 20 30 2c 0a 20 20  20 20 20 20 20 20 20 20  |": 0,.          |
00000340  20 20 22 6d 61 63 22 3a  20 22 30 30 3a 31 36 3a  |  "mac": "00:16:|
00000350  33 65 3a 36 61 3a 62 37  3a 35 31 22 2c 0a 20 20  |3e:6a:b7:51",.  |
00000360  20 20 20 20 20 20 20 20  20 20 22 62 72 69 64 67  |          "bridg|
00000370  65 22 3a 20 22 78 65 6e  62 72 30 22 0a 20 20 20  |e": "xenbr0".   |
00000380  20 20 20 20 20 7d 0a 20  20 20 20 5d 2c 0a 20 20  |     }.    ],.  |
00000390  20 20 22 6f 6e 5f 72 65  62 6f 6f 74 22 3a 20 22  |  "on_reboot": "|
000003a0  72 65 73 74 61 72 74 22  2c 0a 20 20 20 20 22 6f  |restart",.    "o|
000003b0  6e 5f 63 72 61 73 68 22  3a 20 22 70 72 65 73 65  |n_crash": "prese|
000003c0  72 76 65 22 0a 7d 0a 00  00 00 02 00 00 00 00 00  |rve".}..........|
000003d0  ff ff ff ff ff ff ff ff  40 14 00 00 76 63 70 75  |........@...vcpu|
000003e0  30 14 00 00 7f 03 00 00  00 00 00 00 00 00 00 00  |0...............|
000003f0  00 00 00 00 00 00 00 00  00 00 00 00 80 1f 00 00  |................|

As you can see there's a "mac" in right hand column, which is generated
by libxl and saved.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:36:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLXZ-0001YX-6T; Mon, 17 Nov 2014 12:36:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqLXX-0001YS-U4
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:36:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	80/8A-24532-3CBE9645; Mon, 17 Nov 2014 12:36:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416227777!12955200!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10902 invoked from network); 17 Nov 2014 12:36:18 -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;
	17 Nov 2014 12:36:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="192014320"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 07:36:16 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqLXT-0003Pl-Iv;
	Mon, 17 Nov 2014 12:36:15 +0000
Date: Mon, 17 Nov 2014 12:35:57 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Xing Lin <linxingnku@gmail.com>
In-Reply-To: <CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411171221040.26318@kaball.uk.xensource.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1868389143-1416227227=:26318"
Content-ID: <alpine.DEB.2.02.1411171234230.26318@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1868389143-1416227227=:26318
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1411171234231.26318@kaball.uk.xensource.com>

Many thanks for your efforts!

By any chance instead of rebuilding xen from source, have you tried
installing xen-system-amd64 (apt-get install xen-system-amd64), the xen
package for ubuntu?



On Fri, 14 Nov 2014, Xing Lin wrote:
> Hi,
>=20
> The wiki page is ready. I am not sure whether I am using the correct form=
at or not. Please let me know if any changes are need.
> Thanks,
> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
>=20
> -Xing
>=20
> On Fri, Nov 14, 2014 at 2:01 AM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
>       On Thu, 2014-11-13 at 22:54 -0700, Xing Lin wrote:
>       > I have been blocked by this problem for almost three weeks and as=
 far
>       > as I know, I could not find any online tutorial on setting up xen
>       > based compute node for openstack juno. I will document steps I ta=
ke
>       > and share them with the community.
>=20
>       Awesome, thanks!
>=20
>       Having this in the Xen wiki would be awesome. If you would like wri=
te
>       access to our wiki (which is granted manually due to spammers spoil=
ing
>       it for everyone...) then please:
>=20
>       =C2=A0 =C2=A0 =C2=A0 * Create an account using the "create account"=
 link at the
>       =C2=A0 =C2=A0 =C2=A0 =C2=A0 top-right hand side of http://wiki.xen.=
org/wiki/Main_Page
>       =C2=A0 =C2=A0 =C2=A0 * Fill in this form giving your chosen usernam=
e:
>       =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://xenproject.org/component/content=
/article/100-misc/145-request-to-be-made-a-wiki-editor.html
>=20
>       You could alternatively drop me a line privately with the user name=
 for
>       the second step, but filling in the form might give a quicker respo=
nse
>       time due to reaching multiple people in multiple timezones...
>=20
>       Ian.
>=20
>=20
>=20
>=20
--1342847746-1868389143-1416227227=:26318
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1868389143-1416227227=:26318--


From xen-devel-bounces@lists.xen.org Mon Nov 17 12:36:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLXZ-0001YX-6T; Mon, 17 Nov 2014 12:36:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqLXX-0001YS-U4
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:36:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	80/8A-24532-3CBE9645; Mon, 17 Nov 2014 12:36:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416227777!12955200!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10902 invoked from network); 17 Nov 2014 12:36:18 -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;
	17 Nov 2014 12:36:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="192014320"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 07:36:16 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqLXT-0003Pl-Iv;
	Mon, 17 Nov 2014 12:36:15 +0000
Date: Mon, 17 Nov 2014 12:35:57 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Xing Lin <linxingnku@gmail.com>
In-Reply-To: <CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411171221040.26318@kaball.uk.xensource.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1868389143-1416227227=:26318"
Content-ID: <alpine.DEB.2.02.1411171234230.26318@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1868389143-1416227227=:26318
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1411171234231.26318@kaball.uk.xensource.com>

Many thanks for your efforts!

By any chance instead of rebuilding xen from source, have you tried
installing xen-system-amd64 (apt-get install xen-system-amd64), the xen
package for ubuntu?



On Fri, 14 Nov 2014, Xing Lin wrote:
> Hi,
>=20
> The wiki page is ready. I am not sure whether I am using the correct form=
at or not. Please let me know if any changes are need.
> Thanks,
> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
>=20
> -Xing
>=20
> On Fri, Nov 14, 2014 at 2:01 AM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
>       On Thu, 2014-11-13 at 22:54 -0700, Xing Lin wrote:
>       > I have been blocked by this problem for almost three weeks and as=
 far
>       > as I know, I could not find any online tutorial on setting up xen
>       > based compute node for openstack juno. I will document steps I ta=
ke
>       > and share them with the community.
>=20
>       Awesome, thanks!
>=20
>       Having this in the Xen wiki would be awesome. If you would like wri=
te
>       access to our wiki (which is granted manually due to spammers spoil=
ing
>       it for everyone...) then please:
>=20
>       =C2=A0 =C2=A0 =C2=A0 * Create an account using the "create account"=
 link at the
>       =C2=A0 =C2=A0 =C2=A0 =C2=A0 top-right hand side of http://wiki.xen.=
org/wiki/Main_Page
>       =C2=A0 =C2=A0 =C2=A0 * Fill in this form giving your chosen usernam=
e:
>       =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://xenproject.org/component/content=
/article/100-misc/145-request-to-be-made-a-wiki-editor.html
>=20
>       You could alternatively drop me a line privately with the user name=
 for
>       the second step, but filling in the form might give a quicker respo=
nse
>       time due to reaching multiple people in multiple timezones...
>=20
>       Ian.
>=20
>=20
>=20
>=20
--1342847746-1868389143-1416227227=:26318
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1868389143-1416227227=:26318--


From xen-devel-bounces@lists.xen.org Mon Nov 17 12:37:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12: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 1XqLYN-0001cE-K7; Mon, 17 Nov 2014 12:37:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XqLYL-0001c1-Gd
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:37:09 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	78/0B-02576-4FBE9645; Mon, 17 Nov 2014 12:37:08 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416227826!13045268!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28616 invoked from network); 17 Nov 2014 12:37:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:37:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="192014508"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 07:37:06 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XqLYH-0003Pt-Cu;
	Mon, 17 Nov 2014 12:37:05 +0000
Message-ID: <5469EBE5.4070209@eu.citrix.com>
Date: Mon, 17 Nov 2014 12:36:53 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<ian.jackson@citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
	<1415963574.7113.7.camel@citrix.com>
In-Reply-To: <1415963574.7113.7.camel@citrix.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 11:12 AM, Ian Campbell wrote:
> On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
>> Return proper error codes on failure so that scripts can tell whether
>> the command completed properly or not.
>>
>> Also while we're at it, normalize init and dispose of
>> libxl_device_disk structures.  This means calling init and dispose in
>> the actual functions where they are declared.
>>
>> This in turn means changing parse_disk_config_multistring() to not
>> call libxl_device_disk_init.  And that in turn means changes to
>> callers of parse_disk_config().
>>
>> It also means removing libxl_device_disk_init() from
>> libxl.c:libxl_vdev_to_device_disk().  This is only called from
>> xl_cmdimpl.c.
>>
>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>> ---
>> CC: Ian Campbell <ian.campbell@citrix.com>
>> CC: Ian Jackson <ian.jackson@citrix.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Konrad Wilk <konrad.wilk@oracle.com>
>>
>> Release justification: This is a bug fix.  It's a fairly minor one,
>> but it's also a very simple one.
>>
>> v2:
>>   - Restructure functions to make sure init and dispose are properly
>>   called.
> Sadly this bit has somewhat reduced the truth of the second half of your
> release justification, since the patch is a fair bit more subtle though.
> Although IMHO it hasn't invalidated the case for taking the patch for
> 4.5 (modulo comments below).

Well, I think we can take the hacky short-term fix I posted before, 
which is simple, and do a proper fix after the 4.6 dev window opens up; 
or we can do a more complete fix now.

Or, if the valgrind thing is really important, I could use the change 
you suggested, and do "return rc ? 1 : 0;" but I really think that's 
going in the wrong direction...

  -George

>
>> ---
>>   tools/libxl/libxl.c      |  2 --
>>   tools/libxl/xl_cmdimpl.c | 28 +++++++++++++++++++++-------
>>   2 files changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index f7961f6..d9c4ce7 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -2611,8 +2611,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid,
>>       if (devid < 0)
>>           return ERROR_INVAL;
>>   
>> -    libxl_device_disk_init(disk);
> _init functions are idempotent, so this is harmless, I think. Existing
> callers (including things which aren't xl) might be relying on it.
> Outside of a freeze period that might be acceptable (those callers are
> buggy) but since you are asking for a freeze exception I think this may
> be going a step too far in cleaning things up.
>
> In terms of other callers you've missed
> tools/ocaml/libs/xl/xenlight_stubs.c (which appears buggy to me) in
> tree, plus whatever use e.g. libvirt makes of it.
>
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 3c9f146..25af715 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>> @@ -485,8 +485,6 @@ static void parse_disk_config_multistring(XLU_Config **config,
>>   {
>>       int e;
>>   
>> -    libxl_device_disk_init(disk);
> Likewise here, although to a lesser extent since this is xl not libxl.
>>   
>> @@ -6378,13 +6382,17 @@ int main_blockattach(int argc, char **argv)
>>           printf("disk: %s\n", json);
>>           free(json);
>>           if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
>> -        return 0;
> You should set rc = 0 here rather than initing it at declaration to
> catch error paths which don't set the result. (we aren't very consistent
> about this in the code today so I'm only mentioning it because other
> changes seem to be needed, if that turns out not to be the case and
> there's no need for v3 then this shouldn't block acceptance)
>
>> +        goto out;
> I'm not 100% convinced by the use of the goto out error handling style
> for a success path, but it's probably better than duplicating the exit
> path or adding !dryrun checks to all the following operations. Ian,
> since you recently posted updated coding style for things around this,
> what do you think?
>
> Ian.
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:37:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12: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 1XqLYN-0001cE-K7; Mon, 17 Nov 2014 12:37:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XqLYL-0001c1-Gd
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:37:09 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	78/0B-02576-4FBE9645; Mon, 17 Nov 2014 12:37:08 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416227826!13045268!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28616 invoked from network); 17 Nov 2014 12:37:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:37:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="192014508"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 07:37:06 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XqLYH-0003Pt-Cu;
	Mon, 17 Nov 2014 12:37:05 +0000
Message-ID: <5469EBE5.4070209@eu.citrix.com>
Date: Mon, 17 Nov 2014 12:36:53 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<ian.jackson@citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
	<1415963574.7113.7.camel@citrix.com>
In-Reply-To: <1415963574.7113.7.camel@citrix.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 11:12 AM, Ian Campbell wrote:
> On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
>> Return proper error codes on failure so that scripts can tell whether
>> the command completed properly or not.
>>
>> Also while we're at it, normalize init and dispose of
>> libxl_device_disk structures.  This means calling init and dispose in
>> the actual functions where they are declared.
>>
>> This in turn means changing parse_disk_config_multistring() to not
>> call libxl_device_disk_init.  And that in turn means changes to
>> callers of parse_disk_config().
>>
>> It also means removing libxl_device_disk_init() from
>> libxl.c:libxl_vdev_to_device_disk().  This is only called from
>> xl_cmdimpl.c.
>>
>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>> ---
>> CC: Ian Campbell <ian.campbell@citrix.com>
>> CC: Ian Jackson <ian.jackson@citrix.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Konrad Wilk <konrad.wilk@oracle.com>
>>
>> Release justification: This is a bug fix.  It's a fairly minor one,
>> but it's also a very simple one.
>>
>> v2:
>>   - Restructure functions to make sure init and dispose are properly
>>   called.
> Sadly this bit has somewhat reduced the truth of the second half of your
> release justification, since the patch is a fair bit more subtle though.
> Although IMHO it hasn't invalidated the case for taking the patch for
> 4.5 (modulo comments below).

Well, I think we can take the hacky short-term fix I posted before, 
which is simple, and do a proper fix after the 4.6 dev window opens up; 
or we can do a more complete fix now.

Or, if the valgrind thing is really important, I could use the change 
you suggested, and do "return rc ? 1 : 0;" but I really think that's 
going in the wrong direction...

  -George

>
>> ---
>>   tools/libxl/libxl.c      |  2 --
>>   tools/libxl/xl_cmdimpl.c | 28 +++++++++++++++++++++-------
>>   2 files changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index f7961f6..d9c4ce7 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -2611,8 +2611,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid,
>>       if (devid < 0)
>>           return ERROR_INVAL;
>>   
>> -    libxl_device_disk_init(disk);
> _init functions are idempotent, so this is harmless, I think. Existing
> callers (including things which aren't xl) might be relying on it.
> Outside of a freeze period that might be acceptable (those callers are
> buggy) but since you are asking for a freeze exception I think this may
> be going a step too far in cleaning things up.
>
> In terms of other callers you've missed
> tools/ocaml/libs/xl/xenlight_stubs.c (which appears buggy to me) in
> tree, plus whatever use e.g. libvirt makes of it.
>
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 3c9f146..25af715 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>> @@ -485,8 +485,6 @@ static void parse_disk_config_multistring(XLU_Config **config,
>>   {
>>       int e;
>>   
>> -    libxl_device_disk_init(disk);
> Likewise here, although to a lesser extent since this is xl not libxl.
>>   
>> @@ -6378,13 +6382,17 @@ int main_blockattach(int argc, char **argv)
>>           printf("disk: %s\n", json);
>>           free(json);
>>           if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
>> -        return 0;
> You should set rc = 0 here rather than initing it at declaration to
> catch error paths which don't set the result. (we aren't very consistent
> about this in the code today so I'm only mentioning it because other
> changes seem to be needed, if that turns out not to be the case and
> there's no need for v3 then this shouldn't block acceptance)
>
>> +        goto out;
> I'm not 100% convinced by the use of the goto out error handling style
> for a success path, but it's probably better than duplicating the exit
> path or adding !dryrun checks to all the following operations. Ian,
> since you recently posted updated coding style for things around this,
> what do you think?
>
> Ian.
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:39:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLac-0001lc-4z; Mon, 17 Nov 2014 12:39:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqLab-0001lW-IT
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:39:29 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	27/6E-18267-08CE9645; Mon, 17 Nov 2014 12:39:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416227967!11883309!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32177 invoked from network); 17 Nov 2014 12:39:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:39:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="192015176"
Message-ID: <1416227964.5466.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Mon, 17 Nov 2014 12:39:24 +0000
In-Reply-To: <CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:
> Hi,
> 
> 
> The wiki page is ready. I am not sure whether I am using the correct
> format or not. Please let me know if any changes are need. Thanks,
> 
> 
> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno

Thanks for this. WRT the need to install virt manager to avoid the
"cannot open shared object file" issue I expect just running "ldconfig"
would have worked instead.

It would also be good to understand why it is necessary to install from
source. Was it just the lack of the xencommons initscript? Debian and
Ubuntu have their own initscripts and don't reuse the xencommons script.
However it should be fairly easy to add the necessary commands to start
qemu to /etc/init.d/xen instead of rebuilding from source.

I'd expect just adding to the end of the "start)" section of the script
to work. e.g. 

                *) log_end_msg 1; exit ;;
        esac
        log_end_msg 0
+       /usr/local/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize \
+          -monitor /dev/null -serial /dev/null -parallel /dev/null \
+          -pidfile /var/run/qemu-xen-dom0.pid
        ;;
  stop)
        capability_check
        case "$?" in
                0) ;;

(nb, that's not a real patch, I just typed it into my mail client as is)

If you can confirm that this works then I can try and get this fixed in
Debian at least.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:39:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLac-0001lc-4z; Mon, 17 Nov 2014 12:39:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqLab-0001lW-IT
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:39:29 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	27/6E-18267-08CE9645; Mon, 17 Nov 2014 12:39:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416227967!11883309!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32177 invoked from network); 17 Nov 2014 12:39:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:39:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="192015176"
Message-ID: <1416227964.5466.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Mon, 17 Nov 2014 12:39:24 +0000
In-Reply-To: <CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:
> Hi,
> 
> 
> The wiki page is ready. I am not sure whether I am using the correct
> format or not. Please let me know if any changes are need. Thanks,
> 
> 
> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno

Thanks for this. WRT the need to install virt manager to avoid the
"cannot open shared object file" issue I expect just running "ldconfig"
would have worked instead.

It would also be good to understand why it is necessary to install from
source. Was it just the lack of the xencommons initscript? Debian and
Ubuntu have their own initscripts and don't reuse the xencommons script.
However it should be fairly easy to add the necessary commands to start
qemu to /etc/init.d/xen instead of rebuilding from source.

I'd expect just adding to the end of the "start)" section of the script
to work. e.g. 

                *) log_end_msg 1; exit ;;
        esac
        log_end_msg 0
+       /usr/local/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize \
+          -monitor /dev/null -serial /dev/null -parallel /dev/null \
+          -pidfile /var/run/qemu-xen-dom0.pid
        ;;
  stop)
        capability_check
        case "$?" in
                0) ;;

(nb, that's not a real patch, I just typed it into my mail client as is)

If you can confirm that this works then I can try and get this fixed in
Debian at least.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:40:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:40:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLbx-0001tx-QW; Mon, 17 Nov 2014 12:40: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 1XqLbw-0001tq-NN
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:40:52 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	B4/EC-22819-3DCE9645; Mon, 17 Nov 2014 12:40:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416228049!11757333!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1617 invoked from network); 17 Nov 2014 12:40:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:40:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193511135"
Message-ID: <1416228047.5466.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 17 Nov 2014 12:40:47 +0000
In-Reply-To: <alpine.DEB.2.02.1411171221040.26318@kaball.uk.xensource.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<alpine.DEB.2.02.1411171221040.26318@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Xing Lin <linxingnku@gmail.com>, Roger Pau
	=?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 12:35 +0000, Stefano Stabellini wrote:
> Many thanks for your efforts!
> 
> By any chance instead of rebuilding xen from source, have you tried
> installing xen-system-amd64 (apt-get install xen-system-amd64), the xen
> package for ubuntu?

From
https://launchpadlibrarian.net/183469597/buildlog_ubuntu-trusty-i386.nova_1%3A2014.2~b2-0ubuntu1~cloud0_UPLOADING.txt.gz the nova-compute-xen  package depends on:
 Depends: nova-compute-libvirt (= 1:2014.2~b2-0ubuntu1~cloud0), xen-system-amd64 | xen-system-i386
so I think this is already happening. I think the issue is that the
Debian/Ubuntu packages don't use xencommons and therefore haven't yet
picked up the stuff to start dom0's qemu (see my other reply).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 12:40:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 12:40:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqLbx-0001tx-QW; Mon, 17 Nov 2014 12:40: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 1XqLbw-0001tq-NN
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 12:40:52 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	B4/EC-22819-3DCE9645; Mon, 17 Nov 2014 12:40:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416228049!11757333!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1617 invoked from network); 17 Nov 2014 12:40:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 12:40:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="193511135"
Message-ID: <1416228047.5466.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 17 Nov 2014 12:40:47 +0000
In-Reply-To: <alpine.DEB.2.02.1411171221040.26318@kaball.uk.xensource.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<alpine.DEB.2.02.1411171221040.26318@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Xing Lin <linxingnku@gmail.com>, Roger Pau
	=?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 12:35 +0000, Stefano Stabellini wrote:
> Many thanks for your efforts!
> 
> By any chance instead of rebuilding xen from source, have you tried
> installing xen-system-amd64 (apt-get install xen-system-amd64), the xen
> package for ubuntu?

From
https://launchpadlibrarian.net/183469597/buildlog_ubuntu-trusty-i386.nova_1%3A2014.2~b2-0ubuntu1~cloud0_UPLOADING.txt.gz the nova-compute-xen  package depends on:
 Depends: nova-compute-libvirt (= 1:2014.2~b2-0ubuntu1~cloud0), xen-system-amd64 | xen-system-i386
so I think this is already happening. I think the issue is that the
Debian/Ubuntu packages don't use xencommons and therefore haven't yet
picked up the stuff to start dom0's qemu (see my other reply).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:33:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13:33:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqMQC-0003Lf-Ab; Mon, 17 Nov 2014 13:32:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <donald.d.dugger@intel.com>) id 1XqMQA-0003La-Ux
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 13:32:47 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	81/BB-27623-EF8F9645; Mon, 17 Nov 2014 13:32:46 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416231163!11898822!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_DONG,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13809 invoked from network); 17 Nov 2014 13:32:44 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-7.tower-31.messagelabs.com with SMTP;
	17 Nov 2014 13:32:44 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 17 Nov 2014 05:30:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,403,1413270000"; d="scan'208";a="609088271"
Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 05:32:42 -0800
Received: from orsmsx114.amr.corp.intel.com ([169.254.8.209]) by
	ORSMSX101.amr.corp.intel.com ([169.254.8.158]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 05:32:42 -0800
From: "Dugger, Donald D" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout
Thread-Index: AQHQAl8J2Eb74zFpcEWmMrf6ZtSt0Zxk0CmA
Date: Mon, 17 Nov 2014 13:32:41 +0000
Message-ID: <6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
In-Reply-To: <5469F2E2020000780004862C@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Auld, Will" <will.auld@intel.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, good ideas.  How about I change the `snb_igd_quirk' parameter to be:

                snb_igd_quirk                 => current behavior, enable quirk with 1 sec timeout
                snb_igd_quirk=default  => enable quirk with theoretical max timeout of 670 msec
                snb_igd_quirk=n             => enable quirk with timeout of `n' msec

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Monday, November 17, 2014 5:07 AM
To: Dugger, Donald D
Cc: Kay, Allen M; Dong, Eddie; Auld, Will; xen-devel@lists.xen.org
Subject: Re: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout

>>> On 17.11.14 at 05:11, <donald.d.dugger@intel.com> wrote:
> @@ -237,6 +254,18 @@
>      }
>  }
>  
> +static void __init parse_snb_timeout(const char *s) {
> +
> +	if (*s == '\0')
> +		snb_igd_timeout = SNB_IGD_TIMEOUT;
> +	else
> +		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
> +	snb_igd_quirk = 1;
> +	return;
> +}
> +custom_param("snb_igd_timeout", parse_snb_timeout);

Rather than adding a new command line option, can't you simply re-use (by extending) the existing (boolean) one? And similarly replace the current variable (using a value of zero to indicate no
quirk) rather than adding another one?

Also note that the if() statement above needs spaces inserted to match our coding style.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:33:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13:33:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqMQC-0003Lf-Ab; Mon, 17 Nov 2014 13:32:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <donald.d.dugger@intel.com>) id 1XqMQA-0003La-Ux
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 13:32:47 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	81/BB-27623-EF8F9645; Mon, 17 Nov 2014 13:32:46 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416231163!11898822!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_DONG,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13809 invoked from network); 17 Nov 2014 13:32:44 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-7.tower-31.messagelabs.com with SMTP;
	17 Nov 2014 13:32:44 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 17 Nov 2014 05:30:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,403,1413270000"; d="scan'208";a="609088271"
Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 05:32:42 -0800
Received: from orsmsx114.amr.corp.intel.com ([169.254.8.209]) by
	ORSMSX101.amr.corp.intel.com ([169.254.8.158]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 05:32:42 -0800
From: "Dugger, Donald D" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout
Thread-Index: AQHQAl8J2Eb74zFpcEWmMrf6ZtSt0Zxk0CmA
Date: Mon, 17 Nov 2014 13:32:41 +0000
Message-ID: <6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
In-Reply-To: <5469F2E2020000780004862C@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Auld, Will" <will.auld@intel.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, good ideas.  How about I change the `snb_igd_quirk' parameter to be:

                snb_igd_quirk                 => current behavior, enable quirk with 1 sec timeout
                snb_igd_quirk=default  => enable quirk with theoretical max timeout of 670 msec
                snb_igd_quirk=n             => enable quirk with timeout of `n' msec

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Monday, November 17, 2014 5:07 AM
To: Dugger, Donald D
Cc: Kay, Allen M; Dong, Eddie; Auld, Will; xen-devel@lists.xen.org
Subject: Re: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout

>>> On 17.11.14 at 05:11, <donald.d.dugger@intel.com> wrote:
> @@ -237,6 +254,18 @@
>      }
>  }
>  
> +static void __init parse_snb_timeout(const char *s) {
> +
> +	if (*s == '\0')
> +		snb_igd_timeout = SNB_IGD_TIMEOUT;
> +	else
> +		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
> +	snb_igd_quirk = 1;
> +	return;
> +}
> +custom_param("snb_igd_timeout", parse_snb_timeout);

Rather than adding a new command line option, can't you simply re-use (by extending) the existing (boolean) one? And similarly replace the current variable (using a value of zero to indicate no
quirk) rather than adding another one?

Also note that the if() statement above needs spaces inserted to match our coding style.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:35:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13: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 1XqMSi-0003Ud-Tp; Mon, 17 Nov 2014 13:35:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqMSh-0003UT-8V
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 13:35:23 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A2/3F-09936-A99F9645; Mon, 17 Nov 2014 13:35:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416231320!6018991!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31676 invoked from network); 17 Nov 2014 13:35:20 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 13:35:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 13:35:19 +0000
Message-Id: <546A07A502000078000486D0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 13:35:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
	<20141114153208.GD5364@laptop.dumpdata.com>
In-Reply-To: <20141114153208.GD5364@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: roy.franz@linaro.org, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 16:32, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 14, 2014 at 12:37:30PM +0000, Jan Beulich wrote:
>> The specification is kind of vague under what conditions
>> ExitBootServices() may legitimately fail, requiring the OS loader to
>> retry:
>> 
>> "If MapKey value is incorrect, ExitBootServices() returns
>>  EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
>>  be called again. Firmware implementation may choose to do a partial
>>  shutdown of the boot services during the first call to
>>  ExitBootServices(). EFI OS loader should not make calls to any boot
>>  service function other then GetMemoryMap() after the first call to
>>  ExitBootServices()."
>> 
>> While our code guarantees the map key to be valid, there are systems
>> where a firmware internal notification sent while processing
>> ExitBootServices() reportedly results in changes to the memory map.
> 
> s/reportedly/in fact/
>> In that case, make a best effort second try: Avoid any boot service
>> calls other than the two named above, with the possible exception of
>> error paths. Those aren't a problem, since if we end up needing to
>> retry, we're hosed when something goes wrong as much as if we didn't
>> make the retry attempt.
>> 
>> For x86, a minimal adjustment to efi_arch_process_memory_map() is
>> needed for it to cope with potentially being called a second time.
> 
> Wow. Talk about timing. We saw this and were going to see
> doing something similar.

So what are your thoughts then regarding this patch going into 4.5?
And for the LIST_POISON* override one?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:35:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13: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 1XqMSi-0003Ud-Tp; Mon, 17 Nov 2014 13:35:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqMSh-0003UT-8V
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 13:35:23 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A2/3F-09936-A99F9645; Mon, 17 Nov 2014 13:35:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416231320!6018991!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31676 invoked from network); 17 Nov 2014 13:35:20 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 13:35:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 13:35:19 +0000
Message-Id: <546A07A502000078000486D0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 13:35:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
	<20141114153208.GD5364@laptop.dumpdata.com>
In-Reply-To: <20141114153208.GD5364@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: roy.franz@linaro.org, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 16:32, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 14, 2014 at 12:37:30PM +0000, Jan Beulich wrote:
>> The specification is kind of vague under what conditions
>> ExitBootServices() may legitimately fail, requiring the OS loader to
>> retry:
>> 
>> "If MapKey value is incorrect, ExitBootServices() returns
>>  EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
>>  be called again. Firmware implementation may choose to do a partial
>>  shutdown of the boot services during the first call to
>>  ExitBootServices(). EFI OS loader should not make calls to any boot
>>  service function other then GetMemoryMap() after the first call to
>>  ExitBootServices()."
>> 
>> While our code guarantees the map key to be valid, there are systems
>> where a firmware internal notification sent while processing
>> ExitBootServices() reportedly results in changes to the memory map.
> 
> s/reportedly/in fact/
>> In that case, make a best effort second try: Avoid any boot service
>> calls other than the two named above, with the possible exception of
>> error paths. Those aren't a problem, since if we end up needing to
>> retry, we're hosed when something goes wrong as much as if we didn't
>> make the retry attempt.
>> 
>> For x86, a minimal adjustment to efi_arch_process_memory_map() is
>> needed for it to cope with potentially being called a second time.
> 
> Wow. Talk about timing. We saw this and were going to see
> doing something similar.

So what are your thoughts then regarding this patch going into 4.5?
And for the LIST_POISON* override one?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:38:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqMVh-0003eL-ME; Mon, 17 Nov 2014 13:38:29 +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 1XqMVf-0003eC-Ru
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 13:38:27 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	51/BE-02702-35AF9645; Mon, 17 Nov 2014 13:38:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416231506!12485480!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25443 invoked from network); 17 Nov 2014 13:38:26 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 13:38:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 13:38:26 +0000
Message-Id: <546A085F02000078000486D3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 13:38:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Donald D Dugger" <donald.d.dugger@intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
In-Reply-To: <6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, Will Auld <will.auld@intel.com>,
	Allen M Kay <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 14:32, <donald.d.dugger@intel.com> wrote:
> Hmm, good ideas.  How about I change the `snb_igd_quirk' parameter to be:
> 
>                 snb_igd_quirk                 => current behavior, enable quirk with 1 sec timeout
>                 snb_igd_quirk=default  => enable quirk with theoretical max timeout of 670 msec
>                 snb_igd_quirk=n             => enable quirk with timeout of `n' msec

Please retain the current boolean behavior (i.e. =yes, =no, etc should
all continue to be permitted). And the =yes case then would become
what you propose above as =default. Plus I see no reason for the lack
of a specified value to mean 1s - if 670ms is the theoretical may, there's
no need to support the 1s one by means other than the use specifying
that value on the command line.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:38:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqMVh-0003eL-ME; Mon, 17 Nov 2014 13:38:29 +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 1XqMVf-0003eC-Ru
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 13:38:27 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	51/BE-02702-35AF9645; Mon, 17 Nov 2014 13:38:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416231506!12485480!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25443 invoked from network); 17 Nov 2014 13:38:26 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 13:38:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 13:38:26 +0000
Message-Id: <546A085F02000078000486D3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 13:38:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Donald D Dugger" <donald.d.dugger@intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
In-Reply-To: <6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, Will Auld <will.auld@intel.com>,
	Allen M Kay <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 14:32, <donald.d.dugger@intel.com> wrote:
> Hmm, good ideas.  How about I change the `snb_igd_quirk' parameter to be:
> 
>                 snb_igd_quirk                 => current behavior, enable quirk with 1 sec timeout
>                 snb_igd_quirk=default  => enable quirk with theoretical max timeout of 670 msec
>                 snb_igd_quirk=n             => enable quirk with timeout of `n' msec

Please retain the current boolean behavior (i.e. =yes, =no, etc should
all continue to be permitted). And the =yes case then would become
what you propose above as =default. Plus I see no reason for the lack
of a specified value to mean 1s - if 670ms is the theoretical may, there's
no need to support the 1s one by means other than the use specifying
that value on the command line.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:50:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqMgd-00040x-3v; Mon, 17 Nov 2014 13:49:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqMgc-00040s-2a
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 13:49:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F0/1D-09842-9FCF9645; Mon, 17 Nov 2014 13:49:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416232183!9878514!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11869 invoked from network); 17 Nov 2014 13:49:44 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 13:49:44 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHDnf0J024218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 13:49:42 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHDne88022031
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 13:49:41 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHDneo2022026; Mon, 17 Nov 2014 13:49:40 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 05:49:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B6166116CF5; Mon, 17 Nov 2014 08:49:39 -0500 (EST)
Date: Mon, 17 Nov 2014 08:49:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141117134939.GB16549@laptop.dumpdata.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
	<20141114153208.GD5364@laptop.dumpdata.com>
	<546A07A502000078000486D0@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546A07A502000078000486D0@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: roy.franz@linaro.org, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 01:35:17PM +0000, Jan Beulich wrote:
> >>> On 14.11.14 at 16:32, <konrad.wilk@oracle.com> wrote:
> > On Fri, Nov 14, 2014 at 12:37:30PM +0000, Jan Beulich wrote:
> >> The specification is kind of vague under what conditions
> >> ExitBootServices() may legitimately fail, requiring the OS loader to
> >> retry:
> >> 
> >> "If MapKey value is incorrect, ExitBootServices() returns
> >>  EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
> >>  be called again. Firmware implementation may choose to do a partial
> >>  shutdown of the boot services during the first call to
> >>  ExitBootServices(). EFI OS loader should not make calls to any boot
> >>  service function other then GetMemoryMap() after the first call to
> >>  ExitBootServices()."
> >> 
> >> While our code guarantees the map key to be valid, there are systems
> >> where a firmware internal notification sent while processing
> >> ExitBootServices() reportedly results in changes to the memory map.
> > 
> > s/reportedly/in fact/
> >> In that case, make a best effort second try: Avoid any boot service
> >> calls other than the two named above, with the possible exception of
> >> error paths. Those aren't a problem, since if we end up needing to
> >> retry, we're hosed when something goes wrong as much as if we didn't
> >> make the retry attempt.
> >> 
> >> For x86, a minimal adjustment to efi_arch_process_memory_map() is
> >> needed for it to cope with potentially being called a second time.
> > 
> > Wow. Talk about timing. We saw this and were going to see
> > doing something similar.
> 
> So what are your thoughts then regarding this patch going into 4.5?

Definitly should go in - and I would even say backport to earlier
versions of Xen.

> And for the LIST_POISON* override one?

Yes as well please.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:50:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqMgd-00040x-3v; Mon, 17 Nov 2014 13:49:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqMgc-00040s-2a
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 13:49:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F0/1D-09842-9FCF9645; Mon, 17 Nov 2014 13:49:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416232183!9878514!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11869 invoked from network); 17 Nov 2014 13:49:44 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 13:49:44 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHDnf0J024218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 13:49:42 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHDne88022031
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 13:49:41 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHDneo2022026; Mon, 17 Nov 2014 13:49:40 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 05:49:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B6166116CF5; Mon, 17 Nov 2014 08:49:39 -0500 (EST)
Date: Mon, 17 Nov 2014 08:49:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141117134939.GB16549@laptop.dumpdata.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
	<20141114153208.GD5364@laptop.dumpdata.com>
	<546A07A502000078000486D0@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546A07A502000078000486D0@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: roy.franz@linaro.org, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 01:35:17PM +0000, Jan Beulich wrote:
> >>> On 14.11.14 at 16:32, <konrad.wilk@oracle.com> wrote:
> > On Fri, Nov 14, 2014 at 12:37:30PM +0000, Jan Beulich wrote:
> >> The specification is kind of vague under what conditions
> >> ExitBootServices() may legitimately fail, requiring the OS loader to
> >> retry:
> >> 
> >> "If MapKey value is incorrect, ExitBootServices() returns
> >>  EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
> >>  be called again. Firmware implementation may choose to do a partial
> >>  shutdown of the boot services during the first call to
> >>  ExitBootServices(). EFI OS loader should not make calls to any boot
> >>  service function other then GetMemoryMap() after the first call to
> >>  ExitBootServices()."
> >> 
> >> While our code guarantees the map key to be valid, there are systems
> >> where a firmware internal notification sent while processing
> >> ExitBootServices() reportedly results in changes to the memory map.
> > 
> > s/reportedly/in fact/
> >> In that case, make a best effort second try: Avoid any boot service
> >> calls other than the two named above, with the possible exception of
> >> error paths. Those aren't a problem, since if we end up needing to
> >> retry, we're hosed when something goes wrong as much as if we didn't
> >> make the retry attempt.
> >> 
> >> For x86, a minimal adjustment to efi_arch_process_memory_map() is
> >> needed for it to cope with potentially being called a second time.
> > 
> > Wow. Talk about timing. We saw this and were going to see
> > doing something similar.
> 
> So what are your thoughts then regarding this patch going into 4.5?

Definitly should go in - and I would even say backport to earlier
versions of Xen.

> And for the LIST_POISON* override one?

Yes as well please.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:57:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13: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 1XqMnj-0004Fn-1T; Mon, 17 Nov 2014 13:57:07 +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 1XqMnh-0004Fi-TT
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 13:57:06 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	79/5E-02576-1BEF9645; Mon, 17 Nov 2014 13:57:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416232623!13056397!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18423 invoked from network); 17 Nov 2014 13:57:04 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 13:57:04 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHDusFi008605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 13:56:55 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHDue6O014740
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 13:56:43 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHDubWJ014668; Mon, 17 Nov 2014 13:56:38 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 05:56:36 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 648DE116D05; Mon, 17 Nov 2014 08:56:35 -0500 (EST)
Date: Mon, 17 Nov 2014 08:56:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141117135635.GD16549@laptop.dumpdata.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
	<alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
	<20141114155039.GF5364@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411141634480.26318@kaball.uk.xensource.com>
	<F2CBF3009FA73547804AE4C663CAB28E448659@shsmsx102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411171117230.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411171117230.26318@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"mst@redhat.com" <mst@redhat.com>, "Li, Liang Z" <liang.z.li@intel.com>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	"aliguori@amazon.com" <aliguori@amazon.com>,
	"qemu-devel@nongun.org" <qemu-devel@nongun.org>,
	Igor Mammedov <imammedo@redhat.com>, "rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
	running 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, Nov 17, 2014 at 11:17:45AM +0000, Stefano Stabellini wrote:
> On Sun, 16 Nov 2014, Li, Liang Z wrote:
> > > > > Konrad,
> > > > > this is another bug fix for QEMU: pci hotplug doesn't work when
> > > > > xen_platform_pci=0 without this.
> > > >
> > > > Yes.
> > > > >
> > > > >I think we should have it in 4.5. What do yo  think?
> > > >
> > > > Do you believe we should first get an Tested-by from the Intel QA folks?
> >  
> > > Liang at Intel was the one to fix and resend. Liang, could you please test this patch on qemu-xen on xen-unstable? Thanks! 
> > 
> > I have verified this patch can fix the bug  for QEMU: pci hotplug doesn't work when  xen_platform_pci=0,  my original intention  was to fix this bug, so I resent the patch.
> 
> In that case I'll go ahead and backport it to qemu-xen for 4.5.

Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:57:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13: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 1XqMnj-0004Fn-1T; Mon, 17 Nov 2014 13:57:07 +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 1XqMnh-0004Fi-TT
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 13:57:06 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	79/5E-02576-1BEF9645; Mon, 17 Nov 2014 13:57:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416232623!13056397!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18423 invoked from network); 17 Nov 2014 13:57:04 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 13:57:04 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHDusFi008605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 13:56:55 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHDue6O014740
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 13:56:43 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHDubWJ014668; Mon, 17 Nov 2014 13:56:38 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 05:56:36 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 648DE116D05; Mon, 17 Nov 2014 08:56:35 -0500 (EST)
Date: Mon, 17 Nov 2014 08:56:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141117135635.GD16549@laptop.dumpdata.com>
References: <1415845856-24791-1-git-send-email-liang.z.li@intel.com>
	<54648AB7.5010706@redhat.com>
	<alpine.DEB.2.02.1411141355050.26318@kaball.uk.xensource.com>
	<20141114155039.GF5364@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411141634480.26318@kaball.uk.xensource.com>
	<F2CBF3009FA73547804AE4C663CAB28E448659@shsmsx102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1411171117230.26318@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411171117230.26318@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"mst@redhat.com" <mst@redhat.com>, "Li, Liang Z" <liang.z.li@intel.com>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	"aliguori@amazon.com" <aliguori@amazon.com>,
	"qemu-devel@nongun.org" <qemu-devel@nongun.org>,
	Igor Mammedov <imammedo@redhat.com>, "rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when
	running 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, Nov 17, 2014 at 11:17:45AM +0000, Stefano Stabellini wrote:
> On Sun, 16 Nov 2014, Li, Liang Z wrote:
> > > > > Konrad,
> > > > > this is another bug fix for QEMU: pci hotplug doesn't work when
> > > > > xen_platform_pci=0 without this.
> > > >
> > > > Yes.
> > > > >
> > > > >I think we should have it in 4.5. What do yo  think?
> > > >
> > > > Do you believe we should first get an Tested-by from the Intel QA folks?
> >  
> > > Liang at Intel was the one to fix and resend. Liang, could you please test this patch on qemu-xen on xen-unstable? Thanks! 
> > 
> > I have verified this patch can fix the bug  for QEMU: pci hotplug doesn't work when  xen_platform_pci=0,  my original intention  was to fix this bug, so I resent the patch.
> 
> In that case I'll go ahead and backport it to qemu-xen for 4.5.

Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:57:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13:57:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqMoR-0004Jd-F0; Mon, 17 Nov 2014 13:57:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqMoP-0004JP-HM
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 13:57:49 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	EF/0B-02953-CDEF9645; Mon, 17 Nov 2014 13:57:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416232668!8421584!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29601 invoked from network); 17 Nov 2014 13:57:48 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 13:57:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 13:57:47 +0000
Message-Id: <546A0CEA02000078000486FC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 13:57:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
	<20141114153208.GD5364@laptop.dumpdata.com>
	<546A07A502000078000486D0@mail.emea.novell.com>
	<20141117134939.GB16549@laptop.dumpdata.com>
In-Reply-To: <20141117134939.GB16549@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: roy.franz@linaro.org, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.11.14 at 14:49, <konrad.wilk@oracle.com> wrote:
> On Mon, Nov 17, 2014 at 01:35:17PM +0000, Jan Beulich wrote:
>> >>> On 14.11.14 at 16:32, <konrad.wilk@oracle.com> wrote:
>> > On Fri, Nov 14, 2014 at 12:37:30PM +0000, Jan Beulich wrote:
>> >> The specification is kind of vague under what conditions
>> >> ExitBootServices() may legitimately fail, requiring the OS loader to
>> >> retry:
>> >> 
>> >> "If MapKey value is incorrect, ExitBootServices() returns
>> >>  EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
>> >>  be called again. Firmware implementation may choose to do a partial
>> >>  shutdown of the boot services during the first call to
>> >>  ExitBootServices(). EFI OS loader should not make calls to any boot
>> >>  service function other then GetMemoryMap() after the first call to
>> >>  ExitBootServices()."
>> >> 
>> >> While our code guarantees the map key to be valid, there are systems
>> >> where a firmware internal notification sent while processing
>> >> ExitBootServices() reportedly results in changes to the memory map.
>> > 
>> > s/reportedly/in fact/
>> >> In that case, make a best effort second try: Avoid any boot service
>> >> calls other than the two named above, with the possible exception of
>> >> error paths. Those aren't a problem, since if we end up needing to
>> >> retry, we're hosed when something goes wrong as much as if we didn't
>> >> make the retry attempt.
>> >> 
>> >> For x86, a minimal adjustment to efi_arch_process_memory_map() is
>> >> needed for it to cope with potentially being called a second time.
>> > 
>> > Wow. Talk about timing. We saw this and were going to see
>> > doing something similar.
>> 
>> So what are your thoughts then regarding this patch going into 4.5?
> 
> Definitly should go in - and I would even say backport to earlier
> versions of Xen.

Sure, backporting was planned anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 13:57:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 13:57:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqMoR-0004Jd-F0; Mon, 17 Nov 2014 13:57:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqMoP-0004JP-HM
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 13:57:49 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	EF/0B-02953-CDEF9645; Mon, 17 Nov 2014 13:57:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416232668!8421584!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29601 invoked from network); 17 Nov 2014 13:57:48 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 13:57:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 13:57:47 +0000
Message-Id: <546A0CEA02000078000486FC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 13:57:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5466059A0200007800047A4B@mail.emea.novell.com>
	<20141114153208.GD5364@laptop.dumpdata.com>
	<546A07A502000078000486D0@mail.emea.novell.com>
	<20141117134939.GB16549@laptop.dumpdata.com>
In-Reply-To: <20141117134939.GB16549@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: roy.franz@linaro.org, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH RFC] EFI: allow retry of ExitBootServices()
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.11.14 at 14:49, <konrad.wilk@oracle.com> wrote:
> On Mon, Nov 17, 2014 at 01:35:17PM +0000, Jan Beulich wrote:
>> >>> On 14.11.14 at 16:32, <konrad.wilk@oracle.com> wrote:
>> > On Fri, Nov 14, 2014 at 12:37:30PM +0000, Jan Beulich wrote:
>> >> The specification is kind of vague under what conditions
>> >> ExitBootServices() may legitimately fail, requiring the OS loader to
>> >> retry:
>> >> 
>> >> "If MapKey value is incorrect, ExitBootServices() returns
>> >>  EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
>> >>  be called again. Firmware implementation may choose to do a partial
>> >>  shutdown of the boot services during the first call to
>> >>  ExitBootServices(). EFI OS loader should not make calls to any boot
>> >>  service function other then GetMemoryMap() after the first call to
>> >>  ExitBootServices()."
>> >> 
>> >> While our code guarantees the map key to be valid, there are systems
>> >> where a firmware internal notification sent while processing
>> >> ExitBootServices() reportedly results in changes to the memory map.
>> > 
>> > s/reportedly/in fact/
>> >> In that case, make a best effort second try: Avoid any boot service
>> >> calls other than the two named above, with the possible exception of
>> >> error paths. Those aren't a problem, since if we end up needing to
>> >> retry, we're hosed when something goes wrong as much as if we didn't
>> >> make the retry attempt.
>> >> 
>> >> For x86, a minimal adjustment to efi_arch_process_memory_map() is
>> >> needed for it to cope with potentially being called a second time.
>> > 
>> > Wow. Talk about timing. We saw this and were going to see
>> > doing something similar.
>> 
>> So what are your thoughts then regarding this patch going into 4.5?
> 
> Definitly should go in - and I would even say backport to earlier
> versions of Xen.

Sure, backporting was planned anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:12:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14: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 1XqN2R-0004pr-VS; Mon, 17 Nov 2014 14:12:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqN2Q-0004pm-I5
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 14:12:18 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	3B/CA-02699-1420A645; Mon, 17 Nov 2014 14:12:17 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416233534!13069322!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1016 invoked from network); 17 Nov 2014 14:12:16 -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;
	17 Nov 2014 14:12:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192046949"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 09:12:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqN2I-000508-7z;
	Mon, 17 Nov 2014 14:12:10 +0000
Date: Mon, 17 Nov 2014 14:11:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <gregkh@linuxfoundation.org>
Message-ID: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-mips@linux-mips.org, airlied@linux.ie,
	dri-devel@lists.freedesktop.org, xen-devel@lists.xensource.com,
	linux@arm.linux.org.uk, vinod.koul@intel.com, deller@gmx.de,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	jejb@parisc-linux.org, Ian Campbell <Ian.Campbell@citrix.com>,
	alexander.deucher@amd.com, bhelgaas@google.com,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, dwmw2@infradead.org,
	linux-kernel@vger.kernel.org, ralf@linux-mips.org,
	iommu@lists.linux-foundation.org, David Vrabel <david.vrabel@citrix.com>,
	dmaengine@vger.kernel.org, torvalds@linux-foundation.org,
	christian.koenig@amd.com
Subject: [Xen-devel] [RFC] add a struct page* parameter to
	dma_map_ops.unmap_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 am writing this email to ask for your advice.

On architectures where dma addresses are different from physical
addresses, it can be difficult to retrieve the physical address of a
page from its dma address.

Specifically this is the case for Xen on arm and arm64 but I think that
other architectures might have the same issue.

Knowing the physical address is necessary to be able to issue any
required cache maintenance operations when unmap_page,
sync_single_for_cpu and sync_single_for_device are called.

Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
sync_single_for_device would make Linux dma handling on Xen on arm and
arm64 much easier and quicker.

I think that other drivers have similar problems, such as the Intel
IOMMU driver having to call find_iova and walking down an rbtree to get
the physical address in its implementation of unmap_page.

Callers have the struct page* in their hands already from the previous
map_page call so it shouldn't be an issue for them.  A problem does
exist however: there are about 280 callers of dma_unmap_page and
pci_unmap_page. We have even more callers of the dma_sync_single_for_*
functions.



Is such a change even conceivable? How would one go about it?

I think that Xen would not be the only one to gain from it, but I would
like to have a confirmation from others: given the magnitude of the
changes involved I would actually prefer to avoid them unless multiple
drivers/archs/subsystems could really benefit from them.

Cheers,

Stefano


diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d3881..158a765 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -31,8 +31,9 @@ struct dma_map_ops {
 			       unsigned long offset, size_t size,
 			       enum dma_data_direction dir,
 			       struct dma_attrs *attrs);
-	void (*unmap_page)(struct device *dev, dma_addr_t dma_handle,
-			   size_t size, enum dma_data_direction dir,
+	void (*unmap_page)(struct device *dev, struct page *page,
+			   dma_addr_t dma_handle, size_t size,
+			   enum dma_data_direction dir,
 			   struct dma_attrs *attrs);
 	int (*map_sg)(struct device *dev, struct scatterlist *sg,
 		      int nents, enum dma_data_direction dir,
@@ -41,10 +42,10 @@ struct dma_map_ops {
 			 struct scatterlist *sg, int nents,
 			 enum dma_data_direction dir,
 			 struct dma_attrs *attrs);
-	void (*sync_single_for_cpu)(struct device *dev,
+	void (*sync_single_for_cpu)(struct device *dev, struct page *page,
 				    dma_addr_t dma_handle, size_t size,
 				    enum dma_data_direction dir);
-	void (*sync_single_for_device)(struct device *dev,
+	void (*sync_single_for_device)(struct device *dev, struct page *page,
 				       dma_addr_t dma_handle, size_t size,
 				       enum dma_data_direction dir);
 	void (*sync_sg_for_cpu)(struct device *dev,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:12:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14: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 1XqN2R-0004pr-VS; Mon, 17 Nov 2014 14:12:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqN2Q-0004pm-I5
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 14:12:18 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	3B/CA-02699-1420A645; Mon, 17 Nov 2014 14:12:17 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416233534!13069322!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1016 invoked from network); 17 Nov 2014 14:12:16 -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;
	17 Nov 2014 14:12:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192046949"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 09:12:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqN2I-000508-7z;
	Mon, 17 Nov 2014 14:12:10 +0000
Date: Mon, 17 Nov 2014 14:11:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <gregkh@linuxfoundation.org>
Message-ID: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-mips@linux-mips.org, airlied@linux.ie,
	dri-devel@lists.freedesktop.org, xen-devel@lists.xensource.com,
	linux@arm.linux.org.uk, vinod.koul@intel.com, deller@gmx.de,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	jejb@parisc-linux.org, Ian Campbell <Ian.Campbell@citrix.com>,
	alexander.deucher@amd.com, bhelgaas@google.com,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, dwmw2@infradead.org,
	linux-kernel@vger.kernel.org, ralf@linux-mips.org,
	iommu@lists.linux-foundation.org, David Vrabel <david.vrabel@citrix.com>,
	dmaengine@vger.kernel.org, torvalds@linux-foundation.org,
	christian.koenig@amd.com
Subject: [Xen-devel] [RFC] add a struct page* parameter to
	dma_map_ops.unmap_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 am writing this email to ask for your advice.

On architectures where dma addresses are different from physical
addresses, it can be difficult to retrieve the physical address of a
page from its dma address.

Specifically this is the case for Xen on arm and arm64 but I think that
other architectures might have the same issue.

Knowing the physical address is necessary to be able to issue any
required cache maintenance operations when unmap_page,
sync_single_for_cpu and sync_single_for_device are called.

Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
sync_single_for_device would make Linux dma handling on Xen on arm and
arm64 much easier and quicker.

I think that other drivers have similar problems, such as the Intel
IOMMU driver having to call find_iova and walking down an rbtree to get
the physical address in its implementation of unmap_page.

Callers have the struct page* in their hands already from the previous
map_page call so it shouldn't be an issue for them.  A problem does
exist however: there are about 280 callers of dma_unmap_page and
pci_unmap_page. We have even more callers of the dma_sync_single_for_*
functions.



Is such a change even conceivable? How would one go about it?

I think that Xen would not be the only one to gain from it, but I would
like to have a confirmation from others: given the magnitude of the
changes involved I would actually prefer to avoid them unless multiple
drivers/archs/subsystems could really benefit from them.

Cheers,

Stefano


diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d3881..158a765 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -31,8 +31,9 @@ struct dma_map_ops {
 			       unsigned long offset, size_t size,
 			       enum dma_data_direction dir,
 			       struct dma_attrs *attrs);
-	void (*unmap_page)(struct device *dev, dma_addr_t dma_handle,
-			   size_t size, enum dma_data_direction dir,
+	void (*unmap_page)(struct device *dev, struct page *page,
+			   dma_addr_t dma_handle, size_t size,
+			   enum dma_data_direction dir,
 			   struct dma_attrs *attrs);
 	int (*map_sg)(struct device *dev, struct scatterlist *sg,
 		      int nents, enum dma_data_direction dir,
@@ -41,10 +42,10 @@ struct dma_map_ops {
 			 struct scatterlist *sg, int nents,
 			 enum dma_data_direction dir,
 			 struct dma_attrs *attrs);
-	void (*sync_single_for_cpu)(struct device *dev,
+	void (*sync_single_for_cpu)(struct device *dev, struct page *page,
 				    dma_addr_t dma_handle, size_t size,
 				    enum dma_data_direction dir);
-	void (*sync_single_for_device)(struct device *dev,
+	void (*sync_single_for_device)(struct device *dev, struct page *page,
 				       dma_addr_t dma_handle, size_t size,
 				       enum dma_data_direction dir);
 	void (*sync_sg_for_cpu)(struct device *dev,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:28:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNHj-00055a-IF; Mon, 17 Nov 2014 14:28:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <donald.d.dugger@intel.com>) id 1XqNHi-00055S-DC
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:28:06 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	81/C0-14214-5F50A645; Mon, 17 Nov 2014 14:28:05 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416234484!11798430!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 946 invoked from network); 17 Nov 2014 14:28:05 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-6.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 14:28:05 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 17 Nov 2014 06:25:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,403,1413270000"; d="scan'208";a="638271621"
Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130])
	by orsmga002.jf.intel.com with ESMTP; 17 Nov 2014 06:27:59 -0800
Received: from orsmsx114.amr.corp.intel.com ([169.254.8.209]) by
	ORSMSX103.amr.corp.intel.com ([169.254.2.65]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 06:27:59 -0800
From: "Dugger, Donald D" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout
Thread-Index: AQHQAl8J2Eb74zFpcEWmMrf6ZtSt0Zxk0CmAgACIuID//4ZioA==
Date: Mon, 17 Nov 2014 14:27:58 +0000
Message-ID: <6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
	<546A085F02000078000486D3@mail.emea.novell.com>
In-Reply-To: <546A085F02000078000486D3@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Auld, Will" <will.auld@intel.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a big believer in backward compatibility, especially in not doing things that change current defined behavior.  The current `snb_igd_quirk' flag enables the quirk code with a 1sec timeout.  Even though that value is excessive silently changing the meaning of the parameter just seems wrong.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Monday, November 17, 2014 6:38 AM
To: Dugger, Donald D
Cc: Kay, Allen M; Dong, Eddie; Auld, Will; xen-devel@lists.xen.org
Subject: RE: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout

>>> On 17.11.14 at 14:32, <donald.d.dugger@intel.com> wrote:
> Hmm, good ideas.  How about I change the `snb_igd_quirk' parameter to be:
> 
>                 snb_igd_quirk                 => current behavior, enable quirk with 1 sec timeout
>                 snb_igd_quirk=default  => enable quirk with theoretical max timeout of 670 msec
>                 snb_igd_quirk=n             => enable quirk with timeout of `n' msec

Please retain the current boolean behavior (i.e. =yes, =no, etc should all continue to be permitted). And the =yes case then would become what you propose above as =default. Plus I see no reason for the lack of a specified value to mean 1s - if 670ms is the theoretical may, there's no need to support the 1s one by means other than the use specifying that value on the command line.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:28:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNHj-00055a-IF; Mon, 17 Nov 2014 14:28:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <donald.d.dugger@intel.com>) id 1XqNHi-00055S-DC
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:28:06 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	81/C0-14214-5F50A645; Mon, 17 Nov 2014 14:28:05 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416234484!11798430!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 946 invoked from network); 17 Nov 2014 14:28:05 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-6.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 14:28:05 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 17 Nov 2014 06:25:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,403,1413270000"; d="scan'208";a="638271621"
Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130])
	by orsmga002.jf.intel.com with ESMTP; 17 Nov 2014 06:27:59 -0800
Received: from orsmsx114.amr.corp.intel.com ([169.254.8.209]) by
	ORSMSX103.amr.corp.intel.com ([169.254.2.65]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 06:27:59 -0800
From: "Dugger, Donald D" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout
Thread-Index: AQHQAl8J2Eb74zFpcEWmMrf6ZtSt0Zxk0CmAgACIuID//4ZioA==
Date: Mon, 17 Nov 2014 14:27:58 +0000
Message-ID: <6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
	<546A085F02000078000486D3@mail.emea.novell.com>
In-Reply-To: <546A085F02000078000486D3@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Auld, Will" <will.auld@intel.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a big believer in backward compatibility, especially in not doing things that change current defined behavior.  The current `snb_igd_quirk' flag enables the quirk code with a 1sec timeout.  Even though that value is excessive silently changing the meaning of the parameter just seems wrong.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Monday, November 17, 2014 6:38 AM
To: Dugger, Donald D
Cc: Kay, Allen M; Dong, Eddie; Auld, Will; xen-devel@lists.xen.org
Subject: RE: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout

>>> On 17.11.14 at 14:32, <donald.d.dugger@intel.com> wrote:
> Hmm, good ideas.  How about I change the `snb_igd_quirk' parameter to be:
> 
>                 snb_igd_quirk                 => current behavior, enable quirk with 1 sec timeout
>                 snb_igd_quirk=default  => enable quirk with theoretical max timeout of 670 msec
>                 snb_igd_quirk=n             => enable quirk with timeout of `n' msec

Please retain the current boolean behavior (i.e. =yes, =no, etc should all continue to be permitted). And the =yes case then would become what you propose above as =default. Plus I see no reason for the lack of a specified value to mean 1s - if 670ms is the theoretical may, there's no need to support the 1s one by means other than the use specifying that value on the command line.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:41:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNUh-0005IK-3p; Mon, 17 Nov 2014 14:41:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqNUf-0005IF-C9
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:41:29 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	9B/F8-02953-7190A645; Mon, 17 Nov 2014 14:41:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416235287!12502766!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26837 invoked from network); 17 Nov 2014 14:41:27 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 14:41:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 14:41:26 +0000
Message-Id: <546A17240200007800048747@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 14:41:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Donald D Dugger" <donald.d.dugger@intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
	<546A085F02000078000486D3@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
In-Reply-To: <6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, Will Auld <will.auld@intel.com>,
	Allen M Kay <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 15:27, <donald.d.dugger@intel.com> wrote:
> I'm a big believer in backward compatibility, especially in not doing things 
> that change current defined behavior.  The current `snb_igd_quirk' flag 
> enables the quirk code with a 1sec timeout.  Even though that value is 
> excessive silently changing the meaning of the parameter just seems wrong.

But it's the purpose of the patch to change this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:41:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNUh-0005IK-3p; Mon, 17 Nov 2014 14:41:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqNUf-0005IF-C9
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:41:29 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	9B/F8-02953-7190A645; Mon, 17 Nov 2014 14:41:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416235287!12502766!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26837 invoked from network); 17 Nov 2014 14:41:27 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 14:41:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 14:41:26 +0000
Message-Id: <546A17240200007800048747@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 14:41:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Donald D Dugger" <donald.d.dugger@intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
	<546A085F02000078000486D3@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
In-Reply-To: <6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, Will Auld <will.auld@intel.com>,
	Allen M Kay <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 15:27, <donald.d.dugger@intel.com> wrote:
> I'm a big believer in backward compatibility, especially in not doing things 
> that change current defined behavior.  The current `snb_igd_quirk' flag 
> enables the quirk code with a 1sec timeout.  Even though that value is 
> excessive silently changing the meaning of the parameter just seems wrong.

But it's the purpose of the patch to change this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:44:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14: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 1XqNX2-0005W7-4O; Mon, 17 Nov 2014 14:43:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XqNX0-0005Vu-Di
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 14:43:54 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	80/15-02957-9A90A645; Mon, 17 Nov 2014 14:43:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416235431!9737977!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6839 invoked from network); 17 Nov 2014 14:43:53 -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 Nov 2014 14:43:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192058712"
Message-ID: <546A09A2.9090704@citrix.com>
Date: Mon, 17 Nov 2014 14:43:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<gregkh@linuxfoundation.org>
References: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: linux-mips@linux-mips.org, xen-devel@lists.xensource.com,
	linux@arm.linux.org.uk, Ian Campbell <Ian.Campbell@citrix.com>,
	linux-parisc@vger.kernel.org, airlied@linux.ie,
	dwmw2@infradead.org, deller@gmx.de,
	torvalds@linux-foundation.org, jejb@parisc-linux.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	vinod.koul@intel.com, iommu@lists.linux-foundation.org,
	ralf@linux-mips.org, alexander.deucher@amd.com,
	dmaengine@vger.kernel.org, bhelgaas@google.com,
	christian.koenig@amd.com, linux-arm-kernel@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC] add a struct page* parameter to
	dma_map_ops.unmap_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 17/11/14 14:11, Stefano Stabellini wrote:
> Hi all,
> I am writing this email to ask for your advice.
> 
> On architectures where dma addresses are different from physical
> addresses, it can be difficult to retrieve the physical address of a
> page from its dma address.
> 
> Specifically this is the case for Xen on arm and arm64 but I think that
> other architectures might have the same issue.
> 
> Knowing the physical address is necessary to be able to issue any
> required cache maintenance operations when unmap_page,
> sync_single_for_cpu and sync_single_for_device are called.
> 
> Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
> sync_single_for_device would make Linux dma handling on Xen on arm and
> arm64 much easier and quicker.

Using an opaque handle instead of struct page * would be more beneficial
for the Intel IOMMU driver.  e.g.,

typedef dma_addr_t dma_handle_t;

dma_handle_t dma_map_single(struct device *dev,
                            void *va, size_t size,
                            enum dma_data_direction dir);
void dma_unmap_single(struct device *dev,
                      dma_handle_t handle, size_t size,
                      enum dma_data_direction dir);

etc.

Drivers would then use:

dma_addr_t dma_addr(dma_handle_t handle);

To obtain the bus address from the handle.

> I think that other drivers have similar problems, such as the Intel
> IOMMU driver having to call find_iova and walking down an rbtree to get
> the physical address in its implementation of unmap_page.
> 
> Callers have the struct page* in their hands already from the previous
> map_page call so it shouldn't be an issue for them.  A problem does
> exist however: there are about 280 callers of dma_unmap_page and
> pci_unmap_page. We have even more callers of the dma_sync_single_for_*
> functions.

You will also need to fix dma_unmap_single() and pci_unmap_single()
(another 1000+ callers).

You may need to consider a parallel set of map/unmap API calls that
return/accept a handle, and then converting drivers one-by-one as
required, instead of trying to convert every single driver at once.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:44:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14: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 1XqNX2-0005W7-4O; Mon, 17 Nov 2014 14:43:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XqNX0-0005Vu-Di
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 14:43:54 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	80/15-02957-9A90A645; Mon, 17 Nov 2014 14:43:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416235431!9737977!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6839 invoked from network); 17 Nov 2014 14:43:53 -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 Nov 2014 14:43:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192058712"
Message-ID: <546A09A2.9090704@citrix.com>
Date: Mon, 17 Nov 2014 14:43:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<gregkh@linuxfoundation.org>
References: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: linux-mips@linux-mips.org, xen-devel@lists.xensource.com,
	linux@arm.linux.org.uk, Ian Campbell <Ian.Campbell@citrix.com>,
	linux-parisc@vger.kernel.org, airlied@linux.ie,
	dwmw2@infradead.org, deller@gmx.de,
	torvalds@linux-foundation.org, jejb@parisc-linux.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	vinod.koul@intel.com, iommu@lists.linux-foundation.org,
	ralf@linux-mips.org, alexander.deucher@amd.com,
	dmaengine@vger.kernel.org, bhelgaas@google.com,
	christian.koenig@amd.com, linux-arm-kernel@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC] add a struct page* parameter to
	dma_map_ops.unmap_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 17/11/14 14:11, Stefano Stabellini wrote:
> Hi all,
> I am writing this email to ask for your advice.
> 
> On architectures where dma addresses are different from physical
> addresses, it can be difficult to retrieve the physical address of a
> page from its dma address.
> 
> Specifically this is the case for Xen on arm and arm64 but I think that
> other architectures might have the same issue.
> 
> Knowing the physical address is necessary to be able to issue any
> required cache maintenance operations when unmap_page,
> sync_single_for_cpu and sync_single_for_device are called.
> 
> Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
> sync_single_for_device would make Linux dma handling on Xen on arm and
> arm64 much easier and quicker.

Using an opaque handle instead of struct page * would be more beneficial
for the Intel IOMMU driver.  e.g.,

typedef dma_addr_t dma_handle_t;

dma_handle_t dma_map_single(struct device *dev,
                            void *va, size_t size,
                            enum dma_data_direction dir);
void dma_unmap_single(struct device *dev,
                      dma_handle_t handle, size_t size,
                      enum dma_data_direction dir);

etc.

Drivers would then use:

dma_addr_t dma_addr(dma_handle_t handle);

To obtain the bus address from the handle.

> I think that other drivers have similar problems, such as the Intel
> IOMMU driver having to call find_iova and walking down an rbtree to get
> the physical address in its implementation of unmap_page.
> 
> Callers have the struct page* in their hands already from the previous
> map_page call so it shouldn't be an issue for them.  A problem does
> exist however: there are about 280 callers of dma_unmap_page and
> pci_unmap_page. We have even more callers of the dma_sync_single_for_*
> functions.

You will also need to fix dma_unmap_single() and pci_unmap_single()
(another 1000+ callers).

You may need to consider a parallel set of map/unmap API calls that
return/accept a handle, and then converting drivers one-by-one as
required, instead of trying to convert every single driver at once.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:44:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 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.xen.org>)
	id 1XqNXW-0005aF-MH; Mon, 17 Nov 2014 14:44:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XqNXV-0005a1-L3
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:44:25 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	CD/CF-24859-8C90A645; Mon, 17 Nov 2014 14:44:24 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416235463!7493236!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5921 invoked from network); 17 Nov 2014 14:44:24 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-6.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Nov 2014 14:44:24 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>) id 1XqNXT-0001aM-PB
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:44:23 +0000
Message-ID: <546A09C6.70208@canonical.com>
Date: Mon, 17 Nov 2014 15:44:22 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>	<54648EB3.8040703@citrix.com>	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>	<1415955718.31613.34.camel@citrix.com>	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
In-Reply-To: <1416227964.5466.12.camel@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9185386484964241121=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============9185386484964241121==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="HVb5tiqOkxtS9kVkaeLj2aIuEhxe26QTH"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HVb5tiqOkxtS9kVkaeLj2aIuEhxe26QTH
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 17.11.2014 13:39, Ian Campbell wrote:
> On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:
>> Hi,
>>
>>
>> The wiki page is ready. I am not sure whether I am using the correct
>> format or not. Please let me know if any changes are need. Thanks,
>>
>>
>> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
>=20
> Thanks for this. WRT the need to install virt manager to avoid the
> "cannot open shared object file" issue I expect just running "ldconfig"=

> would have worked instead.
>=20
> It would also be good to understand why it is necessary to install from=

> source. Was it just the lack of the xencommons initscript? Debian and
> Ubuntu have their own initscripts and don't reuse the xencommons script=
=2E
> However it should be fairly easy to add the necessary commands to start=

> qemu to /etc/init.d/xen instead of rebuilding from source.
>=20
> I'd expect just adding to the end of the "start)" section of the script=

> to work. e.g.=20
>=20
>                 *) log_end_msg 1; exit ;;
>         esac
>         log_end_msg 0
> +       /usr/local/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name =
dom0 -nographic -M xenpv -daemonize \
> +          -monitor /dev/null -serial /dev/null -parallel /dev/null \
> +          -pidfile /var/run/qemu-xen-dom0.pid
>         ;;
>   stop)
>         capability_check
>         case "$?" in
>                 0) ;;
>=20
> (nb, that's not a real patch, I just typed it into my mail client as is=
)
>=20
> If you can confirm that this works then I can try and get this fixed in=

> Debian at least.

I'd be interested in getting this working in Ubuntu, too. So the wiki cou=
ld drop
the requirement for compiling your own xen. Getting openstack set up is h=
ard
enough. So far it seems like the two things missing would be the patch to=
 qemu
and starting an instance of it for dom0 (maybe), right?

-Stefan

>=20
> Ian.
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--HVb5tiqOkxtS9kVkaeLj2aIuEhxe26QTH
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

iQIcBAEBCgAGBQJUagnHAAoJEOhnXe7L7s6j3jkQAMTFZIc4gWQw8v2UotRy06YS
8JrqdzEAYgXWVTxj7lG39FO0M6jjtDSnv+4PvsepUYq/dYV8tfoBq85BuVTWCppx
eBnbBL/avPbqF2IH11QxVn+wwmEVgVwTucFWIqcZ7x80i3JG/K8g8wBXBM0x4vso
VU/9VD8Tyx+f/hrVRxvOhPa0KQ+noquLhS/jFjJNj6qIdSDHKdLho1HGKGND6zil
JnlIE145gnzgHrVWhuwHn7JQLK8YpF14YsijtMnOLIWAA+9uDHA2498D4n661put
G/HlY3XDR1WvST3MjtPKtJhY+VaaKS1ZocEJMTq+7gtVfVGO+LCEjxGRGxOUC67n
b70vn2NyfJNquwRN6KvoWiL+ZPuN4zpTxzjWznTugXOYrClVILiicFkDIgL0bxAD
tb89zHK/vUuLiP7o4p3bTMWwvM/ilTmtGWsh1qvk3mYIpSa42VQE5YKj9ocKwEuj
WAors1GGLr1RaZR9l2hFq5OvVDzixw+jlDIri9NuU7ajhkB4wrrfBTjiV8b85V4G
V92AJlUWo8B8AGjEs4VYUhuq3cQXW/KavQN+8B4vh4iCtwpD5cenCaJlDJnN4Mo3
A5poEpYjuYgwdIS+pIfe6h4owihuiIgVVWzmNc9ZtVZoVHusFBdZBf/22KrymFyK
iQUEOr9pLZu7rrAy3xFQ
=60N4
-----END PGP SIGNATURE-----

--HVb5tiqOkxtS9kVkaeLj2aIuEhxe26QTH--


--===============9185386484964241121==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9185386484964241121==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 14:44:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 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.xen.org>)
	id 1XqNXW-0005aF-MH; Mon, 17 Nov 2014 14:44:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XqNXV-0005a1-L3
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:44:25 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	CD/CF-24859-8C90A645; Mon, 17 Nov 2014 14:44:24 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416235463!7493236!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5921 invoked from network); 17 Nov 2014 14:44:24 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-6.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Nov 2014 14:44:24 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>) id 1XqNXT-0001aM-PB
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:44:23 +0000
Message-ID: <546A09C6.70208@canonical.com>
Date: Mon, 17 Nov 2014 15:44:22 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>	<54648EB3.8040703@citrix.com>	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>	<1415955718.31613.34.camel@citrix.com>	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
In-Reply-To: <1416227964.5466.12.camel@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9185386484964241121=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============9185386484964241121==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="HVb5tiqOkxtS9kVkaeLj2aIuEhxe26QTH"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HVb5tiqOkxtS9kVkaeLj2aIuEhxe26QTH
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 17.11.2014 13:39, Ian Campbell wrote:
> On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:
>> Hi,
>>
>>
>> The wiki page is ready. I am not sure whether I am using the correct
>> format or not. Please let me know if any changes are need. Thanks,
>>
>>
>> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
>=20
> Thanks for this. WRT the need to install virt manager to avoid the
> "cannot open shared object file" issue I expect just running "ldconfig"=

> would have worked instead.
>=20
> It would also be good to understand why it is necessary to install from=

> source. Was it just the lack of the xencommons initscript? Debian and
> Ubuntu have their own initscripts and don't reuse the xencommons script=
=2E
> However it should be fairly easy to add the necessary commands to start=

> qemu to /etc/init.d/xen instead of rebuilding from source.
>=20
> I'd expect just adding to the end of the "start)" section of the script=

> to work. e.g.=20
>=20
>                 *) log_end_msg 1; exit ;;
>         esac
>         log_end_msg 0
> +       /usr/local/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name =
dom0 -nographic -M xenpv -daemonize \
> +          -monitor /dev/null -serial /dev/null -parallel /dev/null \
> +          -pidfile /var/run/qemu-xen-dom0.pid
>         ;;
>   stop)
>         capability_check
>         case "$?" in
>                 0) ;;
>=20
> (nb, that's not a real patch, I just typed it into my mail client as is=
)
>=20
> If you can confirm that this works then I can try and get this fixed in=

> Debian at least.

I'd be interested in getting this working in Ubuntu, too. So the wiki cou=
ld drop
the requirement for compiling your own xen. Getting openstack set up is h=
ard
enough. So far it seems like the two things missing would be the patch to=
 qemu
and starting an instance of it for dom0 (maybe), right?

-Stefan

>=20
> Ian.
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--HVb5tiqOkxtS9kVkaeLj2aIuEhxe26QTH
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

iQIcBAEBCgAGBQJUagnHAAoJEOhnXe7L7s6j3jkQAMTFZIc4gWQw8v2UotRy06YS
8JrqdzEAYgXWVTxj7lG39FO0M6jjtDSnv+4PvsepUYq/dYV8tfoBq85BuVTWCppx
eBnbBL/avPbqF2IH11QxVn+wwmEVgVwTucFWIqcZ7x80i3JG/K8g8wBXBM0x4vso
VU/9VD8Tyx+f/hrVRxvOhPa0KQ+noquLhS/jFjJNj6qIdSDHKdLho1HGKGND6zil
JnlIE145gnzgHrVWhuwHn7JQLK8YpF14YsijtMnOLIWAA+9uDHA2498D4n661put
G/HlY3XDR1WvST3MjtPKtJhY+VaaKS1ZocEJMTq+7gtVfVGO+LCEjxGRGxOUC67n
b70vn2NyfJNquwRN6KvoWiL+ZPuN4zpTxzjWznTugXOYrClVILiicFkDIgL0bxAD
tb89zHK/vUuLiP7o4p3bTMWwvM/ilTmtGWsh1qvk3mYIpSa42VQE5YKj9ocKwEuj
WAors1GGLr1RaZR9l2hFq5OvVDzixw+jlDIri9NuU7ajhkB4wrrfBTjiV8b85V4G
V92AJlUWo8B8AGjEs4VYUhuq3cQXW/KavQN+8B4vh4iCtwpD5cenCaJlDJnN4Mo3
A5poEpYjuYgwdIS+pIfe6h4owihuiIgVVWzmNc9ZtVZoVHusFBdZBf/22KrymFyK
iQUEOr9pLZu7rrAy3xFQ
=60N4
-----END PGP SIGNATURE-----

--HVb5tiqOkxtS9kVkaeLj2aIuEhxe26QTH--


--===============9185386484964241121==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9185386484964241121==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 14:49:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNcH-0005op-K2; Mon, 17 Nov 2014 14:49:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqNcG-0005oi-4U
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:49:20 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	10/FD-25727-FEA0A645; Mon, 17 Nov 2014 14:49:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416235756!11948828!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2472 invoked from network); 17 Nov 2014 14:49:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 14:49:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="193557099"
Message-ID: <1416235752.5466.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Mon, 17 Nov 2014 14:49:12 +0000
In-Reply-To: <546A09C6.70208@canonical.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com> <546A09C6.70208@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 15:44 +0100, Stefan Bader wrote:
> So far it seems like the two things missing would be the patch to qemu
> and starting an instance of it for dom0 (maybe), right?

Yes to both AFAICT.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:49:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNcH-0005op-K2; Mon, 17 Nov 2014 14:49:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqNcG-0005oi-4U
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:49:20 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	10/FD-25727-FEA0A645; Mon, 17 Nov 2014 14:49:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416235756!11948828!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2472 invoked from network); 17 Nov 2014 14:49:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 14:49:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="193557099"
Message-ID: <1416235752.5466.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Mon, 17 Nov 2014 14:49:12 +0000
In-Reply-To: <546A09C6.70208@canonical.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com> <546A09C6.70208@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 15:44 +0100, Stefan Bader wrote:
> So far it seems like the two things missing would be the patch to qemu
> and starting an instance of it for dom0 (maybe), right?

Yes to both AFAICT.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:52:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14:52:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNeu-00060K-76; Mon, 17 Nov 2014 14:52:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <donald.d.dugger@intel.com>) id 1XqNes-00060E-P5
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:52:02 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	46/6E-29352-29B0A645; Mon, 17 Nov 2014 14:52:02 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416235918!11832586!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20693 invoked from network); 17 Nov 2014 14:52:01 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 14:52:01 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 17 Nov 2014 06:51:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,403,1413270000"; d="scan'208";a="638283170"
Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129])
	by orsmga002.jf.intel.com with ESMTP; 17 Nov 2014 06:51:55 -0800
Received: from orsmsx113.amr.corp.intel.com (10.22.240.9) by
	ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 17 Nov 2014 06:51:55 -0800
Received: from orsmsx114.amr.corp.intel.com ([169.254.8.209]) by
	ORSMSX113.amr.corp.intel.com ([169.254.7.52]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 06:51:54 -0800
From: "Dugger, Donald D" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout
Thread-Index: AQHQAl8J2Eb74zFpcEWmMrf6ZtSt0Zxk0CmAgACIuID//4ZioIAAizoA//97l7A=
Date: Mon, 17 Nov 2014 14:51:53 +0000
Message-ID: <6AF484C0160C61439DE06F17668F3BCB5341E71E@ORSMSX114.amr.corp.intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
	<546A085F02000078000486D3@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
	<546A17240200007800048747@mail.emea.novell.com>
In-Reply-To: <546A17240200007800048747@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Auld, Will" <will.auld@intel.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

My primary goal is to decouple the IGD quirk code from the VTd timeout value, the two are unrelated and shouldn't be using the same define.  In the process we can clean up the IGD code so that, if a user wants, the user can specify a more appropriate timeout value for the quirk code.  There's no need to change the current behavior of the flag, just give the user more options.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Monday, November 17, 2014 7:41 AM
To: Dugger, Donald D
Cc: Kay, Allen M; Dong, Eddie; Auld, Will; xen-devel@lists.xen.org
Subject: RE: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout

>>> On 17.11.14 at 15:27, <donald.d.dugger@intel.com> wrote:
> I'm a big believer in backward compatibility, especially in not doing 
> things that change current defined behavior.  The current 
> `snb_igd_quirk' flag enables the quirk code with a 1sec timeout.  Even 
> though that value is excessive silently changing the meaning of the parameter just seems wrong.

But it's the purpose of the patch to change this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:52:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14:52:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNeu-00060K-76; Mon, 17 Nov 2014 14:52:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <donald.d.dugger@intel.com>) id 1XqNes-00060E-P5
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:52:02 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	46/6E-29352-29B0A645; Mon, 17 Nov 2014 14:52:02 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416235918!11832586!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20693 invoked from network); 17 Nov 2014 14:52:01 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-206.messagelabs.com with SMTP;
	17 Nov 2014 14:52:01 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 17 Nov 2014 06:51:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,403,1413270000"; d="scan'208";a="638283170"
Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129])
	by orsmga002.jf.intel.com with ESMTP; 17 Nov 2014 06:51:55 -0800
Received: from orsmsx113.amr.corp.intel.com (10.22.240.9) by
	ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 17 Nov 2014 06:51:55 -0800
Received: from orsmsx114.amr.corp.intel.com ([169.254.8.209]) by
	ORSMSX113.amr.corp.intel.com ([169.254.7.52]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 06:51:54 -0800
From: "Dugger, Donald D" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout
Thread-Index: AQHQAl8J2Eb74zFpcEWmMrf6ZtSt0Zxk0CmAgACIuID//4ZioIAAizoA//97l7A=
Date: Mon, 17 Nov 2014 14:51:53 +0000
Message-ID: <6AF484C0160C61439DE06F17668F3BCB5341E71E@ORSMSX114.amr.corp.intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
	<546A085F02000078000486D3@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
	<546A17240200007800048747@mail.emea.novell.com>
In-Reply-To: <546A17240200007800048747@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Auld, Will" <will.auld@intel.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

My primary goal is to decouple the IGD quirk code from the VTd timeout value, the two are unrelated and shouldn't be using the same define.  In the process we can clean up the IGD code so that, if a user wants, the user can specify a more appropriate timeout value for the quirk code.  There's no need to change the current behavior of the flag, just give the user more options.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Monday, November 17, 2014 7:41 AM
To: Dugger, Donald D
Cc: Kay, Allen M; Dong, Eddie; Auld, Will; xen-devel@lists.xen.org
Subject: RE: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout

>>> On 17.11.14 at 15:27, <donald.d.dugger@intel.com> wrote:
> I'm a big believer in backward compatibility, especially in not doing 
> things that change current defined behavior.  The current 
> `snb_igd_quirk' flag enables the quirk code with a 1sec timeout.  Even 
> though that value is excessive silently changing the meaning of the parameter just seems wrong.

But it's the purpose of the patch to change this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:58:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNl5-0006Jv-3j; Mon, 17 Nov 2014 14:58:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqNl4-0006Jq-J1
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:58:26 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	1D/16-27623-11D0A645; Mon, 17 Nov 2014 14:58:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416236305!11872724!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17519 invoked from network); 17 Nov 2014 14:58:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 14:58:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 14:58:24 +0000
Message-Id: <546A1B1E0200007800048783@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 14:58:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Donald D Dugger" <donald.d.dugger@intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
	<546A085F02000078000486D3@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
	<546A17240200007800048747@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E71E@ORSMSX114.amr.corp.intel.com>
In-Reply-To: <6AF484C0160C61439DE06F17668F3BCB5341E71E@ORSMSX114.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, Will Auld <will.auld@intel.com>,
	Allen M Kay <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 15:51, <donald.d.dugger@intel.com> wrote:
> My primary goal is to decouple the IGD quirk code from the VTd timeout value, 
> the two are unrelated and shouldn't be using the same define.  In the process 
> we can clean up the IGD code so that, if a user wants, the user can specify a 
> more appropriate timeout value for the quirk code.  There's no need to change 
> the current behavior of the flag, just give the user more options.

It the VT-d maintainers agree with that, I certainly won't stand in the
way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 14:58:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 14:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNl5-0006Jv-3j; Mon, 17 Nov 2014 14:58:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqNl4-0006Jq-J1
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 14:58:26 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	1D/16-27623-11D0A645; Mon, 17 Nov 2014 14:58:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416236305!11872724!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17519 invoked from network); 17 Nov 2014 14:58:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 14:58:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 14:58:24 +0000
Message-Id: <546A1B1E0200007800048783@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 14:58:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Donald D Dugger" <donald.d.dugger@intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
	<546A085F02000078000486D3@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
	<546A17240200007800048747@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E71E@ORSMSX114.amr.corp.intel.com>
In-Reply-To: <6AF484C0160C61439DE06F17668F3BCB5341E71E@ORSMSX114.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, Will Auld <will.auld@intel.com>,
	Allen M Kay <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 15:51, <donald.d.dugger@intel.com> wrote:
> My primary goal is to decouple the IGD quirk code from the VTd timeout value, 
> the two are unrelated and shouldn't be using the same define.  In the process 
> we can clean up the IGD code so that, if a user wants, the user can specify a 
> more appropriate timeout value for the quirk code.  There's no need to change 
> the current behavior of the flag, just give the user more options.

It the VT-d maintainers agree with that, I certainly won't stand in the
way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:09:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNvG-0006as-7q; Mon, 17 Nov 2014 15:08:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <donald.d.dugger@intel.com>) id 1XqNvF-0006an-89
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:08:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	43/B5-09842-88F0A645; Mon, 17 Nov 2014 15:08:56 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416236935!13310064!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18573 invoked from network); 17 Nov 2014 15:08:56 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-21.messagelabs.com with SMTP;
	17 Nov 2014 15:08:56 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 17 Nov 2014 07:08:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,403,1413270000"; d="scan'208";a="623609079"
Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131])
	by fmsmga001.fm.intel.com with ESMTP; 17 Nov 2014 07:07:40 -0800
Received: from orsmsx114.amr.corp.intel.com ([169.254.8.209]) by
	ORSMSX104.amr.corp.intel.com ([169.254.3.116]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 07:07:39 -0800
From: "Dugger, Donald D" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout
Thread-Index: AQHQAl8J2Eb74zFpcEWmMrf6ZtSt0Zxk0CmAgACIuID//4ZioIAAizoA//97l7CAAIkmAP//es5Q
Date: Mon, 17 Nov 2014 15:07:39 +0000
Message-ID: <6AF484C0160C61439DE06F17668F3BCB5341E822@ORSMSX114.amr.corp.intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
	<546A085F02000078000486D3@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
	<546A17240200007800048747@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E71E@ORSMSX114.amr.corp.intel.com>
	<546A1B1E0200007800048783@mail.emea.novell.com>
In-Reply-To: <546A1B1E0200007800048783@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Auld, Will" <will.auld@intel.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Well, Allen (the original VTd maintainer and the author of the IGD quirk code) agrees that the original IGD quirk timeout code just used the VTd timeout as a convenience.  He's the one who identified 670 msec as the theoretical max latency for IGD access but, due to certification issues, suggests we keep the current 1 sec max as a default.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Monday, November 17, 2014 7:58 AM
To: Dugger, Donald D
Cc: Kay, Allen M; Dong, Eddie; Auld, Will; xen-devel@lists.xen.org
Subject: RE: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout

>>> On 17.11.14 at 15:51, <donald.d.dugger@intel.com> wrote:
> My primary goal is to decouple the IGD quirk code from the VTd timeout 
> value, the two are unrelated and shouldn't be using the same define.  
> In the process we can clean up the IGD code so that, if a user wants, 
> the user can specify a more appropriate timeout value for the quirk 
> code.  There's no need to change the current behavior of the flag, just give the user more options.

It the VT-d maintainers agree with that, I certainly won't stand in the way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:09:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqNvG-0006as-7q; Mon, 17 Nov 2014 15:08:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <donald.d.dugger@intel.com>) id 1XqNvF-0006an-89
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:08:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	43/B5-09842-88F0A645; Mon, 17 Nov 2014 15:08:56 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416236935!13310064!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18573 invoked from network); 17 Nov 2014 15:08:56 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-21.messagelabs.com with SMTP;
	17 Nov 2014 15:08:56 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 17 Nov 2014 07:08:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,403,1413270000"; d="scan'208";a="623609079"
Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131])
	by fmsmga001.fm.intel.com with ESMTP; 17 Nov 2014 07:07:40 -0800
Received: from orsmsx114.amr.corp.intel.com ([169.254.8.209]) by
	ORSMSX104.amr.corp.intel.com ([169.254.3.116]) with mapi id
	14.03.0195.001; Mon, 17 Nov 2014 07:07:39 -0800
From: "Dugger, Donald D" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout
Thread-Index: AQHQAl8J2Eb74zFpcEWmMrf6ZtSt0Zxk0CmAgACIuID//4ZioIAAizoA//97l7CAAIkmAP//es5Q
Date: Mon, 17 Nov 2014 15:07:39 +0000
Message-ID: <6AF484C0160C61439DE06F17668F3BCB5341E822@ORSMSX114.amr.corp.intel.com>
References: <E1XqDee-0007TD-RN@maat.n0ano.com>
	<5469F2E2020000780004862C@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E568@ORSMSX114.amr.corp.intel.com>
	<546A085F02000078000486D3@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E69B@ORSMSX114.amr.corp.intel.com>
	<546A17240200007800048747@mail.emea.novell.com>
	<6AF484C0160C61439DE06F17668F3BCB5341E71E@ORSMSX114.amr.corp.intel.com>
	<546A1B1E0200007800048783@mail.emea.novell.com>
In-Reply-To: <546A1B1E0200007800048783@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Auld, Will" <will.auld@intel.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Well, Allen (the original VTd maintainer and the author of the IGD quirk code) agrees that the original IGD quirk timeout code just used the VTd timeout as a convenience.  He's the one who identified 670 msec as the theoretical max latency for IGD access but, due to certification issues, suggests we keep the current 1 sec max as a default.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Monday, November 17, 2014 7:58 AM
To: Dugger, Donald D
Cc: Kay, Allen M; Dong, Eddie; Auld, Will; xen-devel@lists.xen.org
Subject: RE: [PATCH V2] Decouple SnadyBridge quirk form VTd timeout

>>> On 17.11.14 at 15:51, <donald.d.dugger@intel.com> wrote:
> My primary goal is to decouple the IGD quirk code from the VTd timeout 
> value, the two are unrelated and shouldn't be using the same define.  
> In the process we can clean up the IGD code so that, if a user wants, 
> the user can specify a more appropriate timeout value for the quirk 
> code.  There's no need to change the current behavior of the flag, just give the user more options.

It the VT-d maintainers agree with that, I certainly won't stand in the way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:11:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 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.xen.org>)
	id 1XqNxL-0006g8-Ok; Mon, 17 Nov 2014 15:11:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqNxI-0006fw-ME
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:11:06 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	CA/7E-17735-7001A645; Mon, 17 Nov 2014 15:11:03 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416237060!11793583!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3675 invoked from network); 17 Nov 2014 15:11:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 15:11:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192070270"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 10:10:29 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqNwj-00066k-MW;
	Mon, 17 Nov 2014 15:10:29 +0000
Date: Mon, 17 Nov 2014 15:10:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <546A09C6.70208@canonical.com>
Message-ID: <alpine.DEB.2.02.1411171447450.26318@kaball.uk.xensource.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com> <546A09C6.70208@canonical.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Nov 2014, Stefan Bader wrote:
> On 17.11.2014 13:39, Ian Campbell wrote:
> > On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:
> >> Hi,
> >>
> >>
> >> The wiki page is ready. I am not sure whether I am using the correct
> >> format or not. Please let me know if any changes are need. Thanks,
> >>
> >>
> >> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
> > 
> > Thanks for this. WRT the need to install virt manager to avoid the
> > "cannot open shared object file" issue I expect just running "ldconfig"
> > would have worked instead.
> > 
> > It would also be good to understand why it is necessary to install from
> > source. Was it just the lack of the xencommons initscript? Debian and
> > Ubuntu have their own initscripts and don't reuse the xencommons script.
> > However it should be fairly easy to add the necessary commands to start
> > qemu to /etc/init.d/xen instead of rebuilding from source.
> > 
> > I'd expect just adding to the end of the "start)" section of the script
> > to work. e.g. 
> > 
> >                 *) log_end_msg 1; exit ;;
> >         esac
> >         log_end_msg 0
> > +       /usr/local/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize \
> > +          -monitor /dev/null -serial /dev/null -parallel /dev/null \
> > +          -pidfile /var/run/qemu-xen-dom0.pid
> >         ;;
> >   stop)
> >         capability_check
> >         case "$?" in
> >                 0) ;;
> > 
> > (nb, that's not a real patch, I just typed it into my mail client as is)
> > 
> > If you can confirm that this works then I can try and get this fixed in
> > Debian at least.
> 
> I'd be interested in getting this working in Ubuntu, too. So the wiki could drop
> the requirement for compiling your own xen. Getting openstack set up is hard
> enough. So far it seems like the two things missing would be the patch to qemu
> and starting an instance of it for dom0 (maybe), right?

Starting an instance from dom0 is done my xencommons, you can take a
look at the script as it is part of a normal Xen installation. The 3
lines Ian wrote are taken from it.

The patch to QEMU is now in upstream QEMU, qemu-xen for the coming 4.5
release and I have also backported it to the stable 4.4 and 4.3 qemu
tree.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:11:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 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.xen.org>)
	id 1XqNxL-0006g8-Ok; Mon, 17 Nov 2014 15:11:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqNxI-0006fw-ME
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:11:06 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	CA/7E-17735-7001A645; Mon, 17 Nov 2014 15:11:03 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416237060!11793583!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3675 invoked from network); 17 Nov 2014 15:11:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 15:11:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192070270"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 10:10:29 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqNwj-00066k-MW;
	Mon, 17 Nov 2014 15:10:29 +0000
Date: Mon, 17 Nov 2014 15:10:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <546A09C6.70208@canonical.com>
Message-ID: <alpine.DEB.2.02.1411171447450.26318@kaball.uk.xensource.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com> <546A09C6.70208@canonical.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Nov 2014, Stefan Bader wrote:
> On 17.11.2014 13:39, Ian Campbell wrote:
> > On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:
> >> Hi,
> >>
> >>
> >> The wiki page is ready. I am not sure whether I am using the correct
> >> format or not. Please let me know if any changes are need. Thanks,
> >>
> >>
> >> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
> > 
> > Thanks for this. WRT the need to install virt manager to avoid the
> > "cannot open shared object file" issue I expect just running "ldconfig"
> > would have worked instead.
> > 
> > It would also be good to understand why it is necessary to install from
> > source. Was it just the lack of the xencommons initscript? Debian and
> > Ubuntu have their own initscripts and don't reuse the xencommons script.
> > However it should be fairly easy to add the necessary commands to start
> > qemu to /etc/init.d/xen instead of rebuilding from source.
> > 
> > I'd expect just adding to the end of the "start)" section of the script
> > to work. e.g. 
> > 
> >                 *) log_end_msg 1; exit ;;
> >         esac
> >         log_end_msg 0
> > +       /usr/local/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize \
> > +          -monitor /dev/null -serial /dev/null -parallel /dev/null \
> > +          -pidfile /var/run/qemu-xen-dom0.pid
> >         ;;
> >   stop)
> >         capability_check
> >         case "$?" in
> >                 0) ;;
> > 
> > (nb, that's not a real patch, I just typed it into my mail client as is)
> > 
> > If you can confirm that this works then I can try and get this fixed in
> > Debian at least.
> 
> I'd be interested in getting this working in Ubuntu, too. So the wiki could drop
> the requirement for compiling your own xen. Getting openstack set up is hard
> enough. So far it seems like the two things missing would be the patch to qemu
> and starting an instance of it for dom0 (maybe), right?

Starting an instance from dom0 is done my xencommons, you can take a
look at the script as it is part of a normal Xen installation. The 3
lines Ian wrote are taken from it.

The patch to QEMU is now in upstream QEMU, qemu-xen for the coming 4.5
release and I have also backported it to the stable 4.4 and 4.3 qemu
tree.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:20:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqO5s-0006zJ-Tv; Mon, 17 Nov 2014 15:19:56 +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 1XqO5r-0006zE-42
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:19:55 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	BE/6A-02697-A121A645; Mon, 17 Nov 2014 15:19:54 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416237589!7696887!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19840 invoked from network); 17 Nov 2014 15:19:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 15:19:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192074632"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 10:19:48 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XqO5j-0006GR-Li; Mon, 17 Nov 2014 15:19:47 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Mon, 17 Nov 2014 15:19:46 +0000
Message-ID: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
	d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

c/s d1b93ea causes substantial functional regressions in pygrub's ability to
parse bootloader configuration files.

c/s d1b93ea itself changed an an interface which previously used exclusively
integers, to using strings in the case of a grub configuration with explicit
default set, along with changing the code calling the interface to require a
string.  The default value for "default" remained as an integer.

As a result, any Extlinux or Lilo configuration (which drives this interface
exclusively with integers), or Grub configuration which doesn't explicitly
declare a default will die with an AttributeError when attempting to call
"self.cf.default.isdigit()" where "default" is an integer.

Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
which searches partitions for valid bootloader configurations, causing the
issue to be reported as "Unable to find partition containing kernel"

This patch attempts to fix the issue by altering all parts of this interface
to use strings, as opposed to integers.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>

---

This patch is RFC because, while I have dev tested and proved that it unwedges
the specific senario I encountered, I have not yet tested that it contines to
boot all other PV guests.

As for 4.5-ness, this is a must-fix as far as I am concerned

Either:
 1) Revert d1b93ea (original bad changeset) and 4ee393f (attempt 1 to fix)
 2) Take this patch in addition which hopefully fixes the regressions
---
 tools/pygrub/src/ExtLinuxConf.py |    6 +++---
 tools/pygrub/src/GrubConf.py     |    7 ++-----
 tools/pygrub/src/LiloConf.py     |    6 +++---
 3 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/tools/pygrub/src/ExtLinuxConf.py b/tools/pygrub/src/ExtLinuxConf.py
index 510099b..e70fca6 100644
--- a/tools/pygrub/src/ExtLinuxConf.py
+++ b/tools/pygrub/src/ExtLinuxConf.py
@@ -123,7 +123,7 @@ class ExtLinuxConfigFile(object):
         self.filename = fn
         self.images = []
         self.timeout = -1
-        self._default = 0
+        self._default = "0"
 
         if fn is not None:
             self.parse()
@@ -191,8 +191,8 @@ class ExtLinuxConfigFile(object):
     def _get_default(self):
         for i in range(len(self.images)):
             if self.images[i].title == self._default:
-                return i
-        return 0
+                return str(i)
+        return "0"
     def _set_default(self, val):
         self._default = val
     default = property(_get_default, _set_default)
diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
index dea7044..645b6e2 100644
--- a/tools/pygrub/src/GrubConf.py
+++ b/tools/pygrub/src/GrubConf.py
@@ -170,7 +170,7 @@ class _GrubConfigFile(object):
         self.filename = fn
         self.images = []
         self.timeout = -1
-        self._default = 0
+        self._default = "0"
         self.passwordAccess = True
         self.passExc = None
 
@@ -229,12 +229,9 @@ class _GrubConfigFile(object):
         return self._default
     def _set_default(self, val):
         if val == "saved":
-            self._default = 0
+            self._default = "0"
         else:
             self._default = val
-
-        if self._default < 0:
-            raise ValueError, "default must be positive number"
     default = property(_get_default, _set_default)
 
     def set_splash(self, val):
diff --git a/tools/pygrub/src/LiloConf.py b/tools/pygrub/src/LiloConf.py
index 2cb649f..53411e6 100644
--- a/tools/pygrub/src/LiloConf.py
+++ b/tools/pygrub/src/LiloConf.py
@@ -89,7 +89,7 @@ class LiloConfigFile(object):
         self.filename = fn
         self.images = []
         self.timeout = -1
-        self._default = 0
+        self._default = "0"
 
         if fn is not None:
             self.parse()
@@ -156,8 +156,8 @@ class LiloConfigFile(object):
     def _get_default(self):
         for i in range(len(self.images)):
             if self.images[i].title == self._default:
-                return i
-        return 0
+                return str(i)
+        return "0"
     def _set_default(self, val):
         self._default = val
     default = property(_get_default, _set_default)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:20:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqO5s-0006zJ-Tv; Mon, 17 Nov 2014 15:19:56 +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 1XqO5r-0006zE-42
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:19:55 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	BE/6A-02697-A121A645; Mon, 17 Nov 2014 15:19:54 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416237589!7696887!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19840 invoked from network); 17 Nov 2014 15:19:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 15:19:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192074632"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 10:19:48 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XqO5j-0006GR-Li; Mon, 17 Nov 2014 15:19:47 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Mon, 17 Nov 2014 15:19:46 +0000
Message-ID: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
	d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

c/s d1b93ea causes substantial functional regressions in pygrub's ability to
parse bootloader configuration files.

c/s d1b93ea itself changed an an interface which previously used exclusively
integers, to using strings in the case of a grub configuration with explicit
default set, along with changing the code calling the interface to require a
string.  The default value for "default" remained as an integer.

As a result, any Extlinux or Lilo configuration (which drives this interface
exclusively with integers), or Grub configuration which doesn't explicitly
declare a default will die with an AttributeError when attempting to call
"self.cf.default.isdigit()" where "default" is an integer.

Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
which searches partitions for valid bootloader configurations, causing the
issue to be reported as "Unable to find partition containing kernel"

This patch attempts to fix the issue by altering all parts of this interface
to use strings, as opposed to integers.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>

---

This patch is RFC because, while I have dev tested and proved that it unwedges
the specific senario I encountered, I have not yet tested that it contines to
boot all other PV guests.

As for 4.5-ness, this is a must-fix as far as I am concerned

Either:
 1) Revert d1b93ea (original bad changeset) and 4ee393f (attempt 1 to fix)
 2) Take this patch in addition which hopefully fixes the regressions
---
 tools/pygrub/src/ExtLinuxConf.py |    6 +++---
 tools/pygrub/src/GrubConf.py     |    7 ++-----
 tools/pygrub/src/LiloConf.py     |    6 +++---
 3 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/tools/pygrub/src/ExtLinuxConf.py b/tools/pygrub/src/ExtLinuxConf.py
index 510099b..e70fca6 100644
--- a/tools/pygrub/src/ExtLinuxConf.py
+++ b/tools/pygrub/src/ExtLinuxConf.py
@@ -123,7 +123,7 @@ class ExtLinuxConfigFile(object):
         self.filename = fn
         self.images = []
         self.timeout = -1
-        self._default = 0
+        self._default = "0"
 
         if fn is not None:
             self.parse()
@@ -191,8 +191,8 @@ class ExtLinuxConfigFile(object):
     def _get_default(self):
         for i in range(len(self.images)):
             if self.images[i].title == self._default:
-                return i
-        return 0
+                return str(i)
+        return "0"
     def _set_default(self, val):
         self._default = val
     default = property(_get_default, _set_default)
diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
index dea7044..645b6e2 100644
--- a/tools/pygrub/src/GrubConf.py
+++ b/tools/pygrub/src/GrubConf.py
@@ -170,7 +170,7 @@ class _GrubConfigFile(object):
         self.filename = fn
         self.images = []
         self.timeout = -1
-        self._default = 0
+        self._default = "0"
         self.passwordAccess = True
         self.passExc = None
 
@@ -229,12 +229,9 @@ class _GrubConfigFile(object):
         return self._default
     def _set_default(self, val):
         if val == "saved":
-            self._default = 0
+            self._default = "0"
         else:
             self._default = val
-
-        if self._default < 0:
-            raise ValueError, "default must be positive number"
     default = property(_get_default, _set_default)
 
     def set_splash(self, val):
diff --git a/tools/pygrub/src/LiloConf.py b/tools/pygrub/src/LiloConf.py
index 2cb649f..53411e6 100644
--- a/tools/pygrub/src/LiloConf.py
+++ b/tools/pygrub/src/LiloConf.py
@@ -89,7 +89,7 @@ class LiloConfigFile(object):
         self.filename = fn
         self.images = []
         self.timeout = -1
-        self._default = 0
+        self._default = "0"
 
         if fn is not None:
             self.parse()
@@ -156,8 +156,8 @@ class LiloConfigFile(object):
     def _get_default(self):
         for i in range(len(self.images)):
             if self.images[i].title == self._default:
-                return i
-        return 0
+                return str(i)
+        return "0"
     def _set_default(self, val):
         self._default = val
     default = property(_get_default, _set_default)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:32:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15: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 1XqOHX-0007Qw-Ta; Mon, 17 Nov 2014 15:31:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqOHW-0007Qq-Vc
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 15:31:59 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	DE/A2-02696-EE41A645; Mon, 17 Nov 2014 15:31:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416238314!13111814!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12073 invoked from network); 17 Nov 2014 15:31:56 -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;
	17 Nov 2014 15:31:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192079086"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 10:31:04 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqOGe-000656-63;
	Mon, 17 Nov 2014 15:31:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqOGd-0002tB-Uj;
	Mon, 17 Nov 2014 15:31:03 +0000
Date: Mon, 17 Nov 2014 15:31:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31634-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11680
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31634: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6383482982868885161=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6383482982868885161==
Content-Type: text/plain
Content-Length: 11449
Content-Transfer-Encoding: quoted-printable

flight 31634 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31634/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
 test-armhf-armhf-xl           9 guest-start      fail in 31618 REGR. vs. 30603

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl           4 xen-install                 fail pass in 31618
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 31618 pass in 31634

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                4e70f9271dabc58fbf14680843bfac510c193152
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liang <liang.z.li@intel.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12699 lines long.)


--===============6383482982868885161==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6383482982868885161==--

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:32:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15: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 1XqOHX-0007Qw-Ta; Mon, 17 Nov 2014 15:31:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqOHW-0007Qq-Vc
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 15:31:59 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	DE/A2-02696-EE41A645; Mon, 17 Nov 2014 15:31:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416238314!13111814!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12073 invoked from network); 17 Nov 2014 15:31:56 -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;
	17 Nov 2014 15:31:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192079086"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 10:31:04 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqOGe-000656-63;
	Mon, 17 Nov 2014 15:31:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqOGd-0002tB-Uj;
	Mon, 17 Nov 2014 15:31:03 +0000
Date: Mon, 17 Nov 2014 15:31:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31634-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11680
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31634: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6383482982868885161=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6383482982868885161==
Content-Type: text/plain
Content-Length: 11449
Content-Transfer-Encoding: quoted-printable

flight 31634 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31634/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
 test-armhf-armhf-xl           9 guest-start      fail in 31618 REGR. vs. 30603

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl           4 xen-install                 fail pass in 31618
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 31618 pass in 31634

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                4e70f9271dabc58fbf14680843bfac510c193152
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liang <liang.z.li@intel.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12699 lines long.)


--===============6383482982868885161==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6383482982868885161==--

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:39:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15:39:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqOOm-0007lN-0X; Mon, 17 Nov 2014 15:39:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqOOk-0007lI-CV
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:39:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F8/71-09936-DA61A645; Mon, 17 Nov 2014 15:39:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416238761!5324500!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3777 invoked from network); 17 Nov 2014 15:39:25 -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;
	17 Nov 2014 15:39:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192082790"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 10:39:06 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqOOQ-0006dK-1L;
	Mon, 17 Nov 2014 15:39:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqOOP-0001cj-Dp;
	Mon, 17 Nov 2014 15:39:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21610.5784.968036.992847@mariner.uk.xensource.com>
Date: Mon, 17 Nov 2014 15:39:04 +0000
To: Liang Li <liang.z.li@intel.com>
In-Reply-To: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org,
	JBeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> If hardware support the pdpe1gb flag, expose it to guest by default.
> Users don't have to use a 'cpuid= ' option in config file to turn
> it on.

I don't understand what this flag does.  I guess from the name it
turns on 1G pages.  I guess these are supported ?

I would like to see comment from an x86 hypervisor maintainer.

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 Nov 17 15:39:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15:39:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqOOm-0007lN-0X; Mon, 17 Nov 2014 15:39:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqOOk-0007lI-CV
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:39:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F8/71-09936-DA61A645; Mon, 17 Nov 2014 15:39:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416238761!5324500!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3777 invoked from network); 17 Nov 2014 15:39:25 -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;
	17 Nov 2014 15:39:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192082790"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 10:39:06 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqOOQ-0006dK-1L;
	Mon, 17 Nov 2014 15:39:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqOOP-0001cj-Dp;
	Mon, 17 Nov 2014 15:39:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21610.5784.968036.992847@mariner.uk.xensource.com>
Date: Mon, 17 Nov 2014 15:39:04 +0000
To: Liang Li <liang.z.li@intel.com>
In-Reply-To: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org,
	JBeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> If hardware support the pdpe1gb flag, expose it to guest by default.
> Users don't have to use a 'cpuid= ' option in config file to turn
> it on.

I don't understand what this flag does.  I guess from the name it
turns on 1G pages.  I guess these are supported ?

I would like to see comment from an x86 hypervisor maintainer.

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 Nov 17 15:45:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 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.xen.org>)
	id 1XqOUK-00082V-QK; Mon, 17 Nov 2014 15:45:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqOUJ-00082P-T6
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:45:12 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	A2/35-25727-7081A645; Mon, 17 Nov 2014 15:45:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416239106!11898678!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10675 invoked from network); 17 Nov 2014 15:45:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 15:45:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="193582181"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 10:45:03 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqOUB-0006lw-B5;
	Mon, 17 Nov 2014 15:45:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqOUA-0001dh-HC;
	Mon, 17 Nov 2014 15:45:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21610.6141.943750.141913@mariner.uk.xensource.com>
Date: Mon, 17 Nov 2014 15:45:01 +0000
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1416215987-21571-1-git-send-email-cyliu@suse.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Chunyan Liu writes ("[PATCH] fix rename: xenstore not fully updated"):
> Currently libxl__domain_rename only update /local/domain/<domid>/name,
> still some places in xenstore are not updated, including:
> /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.

Thanks.

...
> +    /* update /vm/<uuid>/name */
> +    vm_path = libxl__xs_read(gc, trans, libxl__sprintf(gc, "%s/vm", dom_path));

This seems to be obtaining the uuid from xenstore.  Can't we get it
from the hypervisor ?  That avoids quite a bit of this path fiddling.

> +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */

Um, what on earth creates that ?

Worse, what reads it ?

I think that putting this information in the backend directory is
entirely wrong.

(Also, please use GCSPRINTF, libxl__xs_read_checked, etc., and keep
your lines to less than 75 characters or so.)

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:45:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 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.xen.org>)
	id 1XqOUK-00082V-QK; Mon, 17 Nov 2014 15:45:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqOUJ-00082P-T6
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:45:12 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	A2/35-25727-7081A645; Mon, 17 Nov 2014 15:45:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416239106!11898678!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10675 invoked from network); 17 Nov 2014 15:45:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 15:45:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="193582181"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 10:45:03 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqOUB-0006lw-B5;
	Mon, 17 Nov 2014 15:45:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqOUA-0001dh-HC;
	Mon, 17 Nov 2014 15:45:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21610.6141.943750.141913@mariner.uk.xensource.com>
Date: Mon, 17 Nov 2014 15:45:01 +0000
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1416215987-21571-1-git-send-email-cyliu@suse.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Chunyan Liu writes ("[PATCH] fix rename: xenstore not fully updated"):
> Currently libxl__domain_rename only update /local/domain/<domid>/name,
> still some places in xenstore are not updated, including:
> /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.

Thanks.

...
> +    /* update /vm/<uuid>/name */
> +    vm_path = libxl__xs_read(gc, trans, libxl__sprintf(gc, "%s/vm", dom_path));

This seems to be obtaining the uuid from xenstore.  Can't we get it
from the hypervisor ?  That avoids quite a bit of this path fiddling.

> +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */

Um, what on earth creates that ?

Worse, what reads it ?

I think that putting this information in the backend directory is
entirely wrong.

(Also, please use GCSPRINTF, libxl__xs_read_checked, etc., and keep
your lines to less than 75 characters or so.)

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:47:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqOWx-0008A7-CH; Mon, 17 Nov 2014 15:47:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XqOWw-00089y-2Q
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:47:54 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	09/E4-05632-9A81A645; Mon, 17 Nov 2014 15:47:53 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416239270!11946029!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4457 invoked from network); 17 Nov 2014 15:47:52 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 15:47:52 -0000
Received: from mail-qg0-f53.google.com ([209.85.192.53]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGoYpTQ+UmjGqUXu35zizC03lTl9AMqf@postini.com;
	Mon, 17 Nov 2014 07:47:52 PST
Received: by mail-qg0-f53.google.com with SMTP id z107so15060370qgd.26
	for <xen-devel@lists.xen.org>; Mon, 17 Nov 2014 07:47:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=2XpTY8PgGDYhxGEdm4zu4M/jhvqDAs9cjFSolESGZH4=;
	b=FU8RxI40Z8k+fqdVYyZLdDBPQWJHS9Ci6yDCECHYUITySaowRhx0tgSgsNKLHjaeEy
	oblk1+YvjpaHUhqRmuG+86CQbK9RpKfiEfq7RDUX8b+VhoKjWu8ICqeoPvT03AN3fYFC
	BA93yyIuV0jKR5DBC+N71YLBA2SJyFeKUGghw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=2XpTY8PgGDYhxGEdm4zu4M/jhvqDAs9cjFSolESGZH4=;
	b=c28cC2iWkYD52ePtAFDB6TiKdXpEvzPE2OGfOk/cgG3iHmB8dFvsBChVguxtit5Ld1
	aKJW0Yo7gKbq3b2jbJGwgSV7OiS4YWaI1pBV2A6ab77Ib/84/8SfqsJOp73fJQrhV9IU
	4fciWkUFB9TAj059HsDtFVEPnWMQq/FW+xv2FM34irAiK66KDufzQV39JAMTBWC+l9+h
	/coKot7IuelYuZBl/KB2N8NPy15bZnklijRSdUf30ykbBwlCFb9CbDbgrZPTM7MK0EIv
	VOYqR3FFUFpMCfe6FW/5/xF1qabcC5iDw/yXf/QrA74cK30afiEhtKxvWrUMuojXJNSF
	4sUA==
X-Gm-Message-State: ALoCoQkb9fHHuYQovMGc5A173+jWU5qCsVlNYZ+fib9bpFXr2sBWzr0UiCGQ2r7IMaI2vxEDGvLeQgR+0nUklm4pWLU37NCZ8YStj7Zhp6EwvCaDnsdmuXpCppy9Y6YAUhCOfFU56zmCynlCD2NfOfhoO5OHAiBPtw==
X-Received: by 10.140.107.163 with SMTP id h32mr30181914qgf.34.1416239267021; 
	Mon, 17 Nov 2014 07:47:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.107.163 with SMTP id h32mr30181894qgf.34.1416239266899; 
	Mon, 17 Nov 2014 07:47:46 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Mon, 17 Nov 2014 07:47:46 -0800 (PST)
In-Reply-To: <CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
Date: Mon, 17 Nov 2014 17:47:46 +0200
Message-ID: <CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Issue occurs after the following commit:

commit 5495a512b63bad868c147198f7f049c2617d468c
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Jun 10 15:07:12 2014 +0100

    xen/arm: support HW interrupts, do not request maintenance_interrupts

    If the irq to be injected is an hardware irq (p->desc != NULL), set
    GICH_LR_HW. Do not set GICH_LR_MAINTENANCE_IRQ.


I'm going to debug it deeply.
Stefano - may be you have a feeling what it can be ?

Regards,
Andrii


On Fri, Nov 14, 2014 at 6:40 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> Hi Julien,
>
>> I would be surprised that the next GIC series impact this code as the
>> next driver is only compiled for arm64 (GICv3 doesn't exist on arm32).
>> Though, there was some refactoring.
>
> I meant that code was divided for generic GIC and GICv2 together with
> refactoring. Also in mails I saw that it was initially tested without
> SMP.
> GICv3 has no impacts for sure.
>
>>
>> The interrupt management has also been reworked for Xen 4.5 to avoid
>> maintenance interrupt. I would give a look on this part.
>
> Thanks, this may help.
>
> Regards,
> Andrii
>
>
>>
>> Regards,
>>
>> --
>> Julien Grall
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:47:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqOWx-0008A7-CH; Mon, 17 Nov 2014 15:47:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XqOWw-00089y-2Q
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:47:54 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	09/E4-05632-9A81A645; Mon, 17 Nov 2014 15:47:53 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416239270!11946029!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4457 invoked from network); 17 Nov 2014 15:47:52 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 15:47:52 -0000
Received: from mail-qg0-f53.google.com ([209.85.192.53]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGoYpTQ+UmjGqUXu35zizC03lTl9AMqf@postini.com;
	Mon, 17 Nov 2014 07:47:52 PST
Received: by mail-qg0-f53.google.com with SMTP id z107so15060370qgd.26
	for <xen-devel@lists.xen.org>; Mon, 17 Nov 2014 07:47:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=2XpTY8PgGDYhxGEdm4zu4M/jhvqDAs9cjFSolESGZH4=;
	b=FU8RxI40Z8k+fqdVYyZLdDBPQWJHS9Ci6yDCECHYUITySaowRhx0tgSgsNKLHjaeEy
	oblk1+YvjpaHUhqRmuG+86CQbK9RpKfiEfq7RDUX8b+VhoKjWu8ICqeoPvT03AN3fYFC
	BA93yyIuV0jKR5DBC+N71YLBA2SJyFeKUGghw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=2XpTY8PgGDYhxGEdm4zu4M/jhvqDAs9cjFSolESGZH4=;
	b=c28cC2iWkYD52ePtAFDB6TiKdXpEvzPE2OGfOk/cgG3iHmB8dFvsBChVguxtit5Ld1
	aKJW0Yo7gKbq3b2jbJGwgSV7OiS4YWaI1pBV2A6ab77Ib/84/8SfqsJOp73fJQrhV9IU
	4fciWkUFB9TAj059HsDtFVEPnWMQq/FW+xv2FM34irAiK66KDufzQV39JAMTBWC+l9+h
	/coKot7IuelYuZBl/KB2N8NPy15bZnklijRSdUf30ykbBwlCFb9CbDbgrZPTM7MK0EIv
	VOYqR3FFUFpMCfe6FW/5/xF1qabcC5iDw/yXf/QrA74cK30afiEhtKxvWrUMuojXJNSF
	4sUA==
X-Gm-Message-State: ALoCoQkb9fHHuYQovMGc5A173+jWU5qCsVlNYZ+fib9bpFXr2sBWzr0UiCGQ2r7IMaI2vxEDGvLeQgR+0nUklm4pWLU37NCZ8YStj7Zhp6EwvCaDnsdmuXpCppy9Y6YAUhCOfFU56zmCynlCD2NfOfhoO5OHAiBPtw==
X-Received: by 10.140.107.163 with SMTP id h32mr30181914qgf.34.1416239267021; 
	Mon, 17 Nov 2014 07:47:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.107.163 with SMTP id h32mr30181894qgf.34.1416239266899; 
	Mon, 17 Nov 2014 07:47:46 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Mon, 17 Nov 2014 07:47:46 -0800 (PST)
In-Reply-To: <CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
Date: Mon, 17 Nov 2014 17:47:46 +0200
Message-ID: <CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Issue occurs after the following commit:

commit 5495a512b63bad868c147198f7f049c2617d468c
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Jun 10 15:07:12 2014 +0100

    xen/arm: support HW interrupts, do not request maintenance_interrupts

    If the irq to be injected is an hardware irq (p->desc != NULL), set
    GICH_LR_HW. Do not set GICH_LR_MAINTENANCE_IRQ.


I'm going to debug it deeply.
Stefano - may be you have a feeling what it can be ?

Regards,
Andrii


On Fri, Nov 14, 2014 at 6:40 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> Hi Julien,
>
>> I would be surprised that the next GIC series impact this code as the
>> next driver is only compiled for arm64 (GICv3 doesn't exist on arm32).
>> Though, there was some refactoring.
>
> I meant that code was divided for generic GIC and GICv2 together with
> refactoring. Also in mails I saw that it was initially tested without
> SMP.
> GICv3 has no impacts for sure.
>
>>
>> The interrupt management has also been reworked for Xen 4.5 to avoid
>> maintenance interrupt. I would give a look on this part.
>
> Thanks, this may help.
>
> Regards,
> Andrii
>
>
>>
>> Regards,
>>
>> --
>> Julien Grall
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:53:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqOcF-0008RT-7k; Mon, 17 Nov 2014 15:53:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqOcE-0008RN-0Z
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:53:22 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	19/D5-14727-1F91A645; Mon, 17 Nov 2014 15:53:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416239597!11819320!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3063 invoked from network); 17 Nov 2014 15:53:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 15:53:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="193586023"
Message-ID: <1416239594.5466.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 17 Nov 2014 15:53:14 +0000
In-Reply-To: <21610.6141.943750.141913@mariner.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<21610.6141.943750.141913@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 15:45 +0000, Ian Jackson wrote:
> > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> 
> Um, what on earth creates that ?
> 
> Worse, what reads it ?
> 
> I think that putting this information in the backend directory is
> entirely wrong.

I concluded the same thing.

Chunyan, I think it would be better to simply remove the code which adds
this domain field under the backend dir in the first place, instead of
adding all this complex code to try and keep it up to date.

Can you do that in the next iteration please?

Thanks,

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 15:53:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 15:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqOcF-0008RT-7k; Mon, 17 Nov 2014 15:53:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqOcE-0008RN-0Z
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 15:53:22 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	19/D5-14727-1F91A645; Mon, 17 Nov 2014 15:53:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416239597!11819320!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3063 invoked from network); 17 Nov 2014 15:53:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 15:53:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="193586023"
Message-ID: <1416239594.5466.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 17 Nov 2014 15:53:14 +0000
In-Reply-To: <21610.6141.943750.141913@mariner.uk.xensource.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<21610.6141.943750.141913@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 15:45 +0000, Ian Jackson wrote:
> > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */
> 
> Um, what on earth creates that ?
> 
> Worse, what reads it ?
> 
> I think that putting this information in the backend directory is
> entirely wrong.

I concluded the same thing.

Chunyan, I think it would be better to simply remove the code which adds
this domain field under the backend dir in the first place, instead of
adding all this complex code to try and keep it up to date.

Can you do that in the next iteration please?

Thanks,

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:25:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqP6o-0000uX-Tv; Mon, 17 Nov 2014 16:24:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqP6m-0000uS-QA
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:24:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5B/75-25276-8512A645; Mon, 17 Nov 2014 16:24:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416241493!13331493!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23502 invoked from network); 17 Nov 2014 16:24:53 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:24:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 16:24:52 +0000
Message-Id: <546A2F600200007800048848@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 16:24:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Liang Li" <liang.z.li@intel.com>,"Tim Deegan" <tim@xen.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
In-Reply-To: <21610.5784.968036.992847@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, xen-devel@lists.xen.org, wei.liu2@citrix.com,
	ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>> If hardware support the pdpe1gb flag, expose it to guest by default.
>> Users don't have to use a 'cpuid= ' option in config file to turn
>> it on.
> 
> I don't understand what this flag does.  I guess from the name it
> turns on 1G pages.  I guess these are supported ?
> 
> I would like to see comment from an x86 hypervisor maintainer.

Yes, we support 1Gb pages. The purpose of the patch is to not
unconditionally hide the flag from guests. (I had commented on
v1, but sadly this one wasn't tagged as v2, nor was I included on
the Cc list, hence I didn't spot the new version.)

The one thing I'm not certain about is shadow mode: Only 2Mb
pages may be supported there. Tim?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:25:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqP6o-0000uX-Tv; Mon, 17 Nov 2014 16:24:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqP6m-0000uS-QA
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:24:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5B/75-25276-8512A645; Mon, 17 Nov 2014 16:24:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416241493!13331493!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23502 invoked from network); 17 Nov 2014 16:24:53 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:24:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 16:24:52 +0000
Message-Id: <546A2F600200007800048848@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 16:24:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Liang Li" <liang.z.li@intel.com>,"Tim Deegan" <tim@xen.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
In-Reply-To: <21610.5784.968036.992847@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, xen-devel@lists.xen.org, wei.liu2@citrix.com,
	ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>> If hardware support the pdpe1gb flag, expose it to guest by default.
>> Users don't have to use a 'cpuid= ' option in config file to turn
>> it on.
> 
> I don't understand what this flag does.  I guess from the name it
> turns on 1G pages.  I guess these are supported ?
> 
> I would like to see comment from an x86 hypervisor maintainer.

Yes, we support 1Gb pages. The purpose of the patch is to not
unconditionally hide the flag from guests. (I had commented on
v1, but sadly this one wasn't tagged as v2, nor was I included on
the Cc list, hence I didn't spot the new version.)

The one thing I'm not certain about is shadow mode: Only 2Mb
pages may be supported there. Tim?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:26:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16: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 1XqP8O-00010d-IH; Mon, 17 Nov 2014 16:26:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1XqP8N-00010V-6q
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 16:26:35 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	83/D4-09936-AB12A645; Mon, 17 Nov 2014 16:26:34 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416241584!13399129!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNTE5MTAgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28562 invoked from network); 17 Nov 2014 16:26:24 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 16:26:24 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so2310889wiv.1
	for <xen-devel@lists.xenproject.org>;
	Mon, 17 Nov 2014 08:26:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:subject:message-id:date:to:mime-version;
	bh=JJLMd6Xc+Ve5prXmoK2zINccoQQtv20KCUA2cVIlZJs=;
	b=gP0TrNYLKpk5s0u90d6/ASd2UBxDJYzH3oX0W7PqMq670LX1hj6seIwBWu0cRNh7i9
	tvc/KfXEXetG6gCIXjdyZWer/pdCIeqIaj16ffR1qQXGeoaVKc7k47VU2VLO+i9H4GdY
	KhtYzFfuXdvr8K4e/Fw279z4MKroI2aSR6YIyJ6xR/JAHpLharXABRzzRK5UWJMe92u6
	PsJE8qOIh/zvRhiB8i5cybFSmwBeB/hGJTj10ESr5NMU9tdsTnUw5lMiyEA9hA5wzab3
	VFWt99i3CORgYseR0XpgTb/7pVv1v/R4M1hP+rDBdNARmO3fP2HhE5mcbBYGYKbMnKiY
	UIcA==
X-Received: by 10.194.119.230 with SMTP id kx6mr34165696wjb.80.1416241584292; 
	Mon, 17 Nov 2014 08:26:24 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id
	el6sm15851553wib.23.2014.11.17.08.26.22
	for <xen-devel@lists.xenproject.org>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 17 Nov 2014 08:26:22 -0800 (PST)
From: Lars Kurth <lars.kurth.xen@gmail.com>
Message-Id: <8CD9998A-A30A-4B60-986E-BEDDCD223517@gmail.com>
Date: Mon, 17 Nov 2014 16:26:16 +0000
To: xen-devel <xen-devel@lists.xenproject.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Subject: [Xen-devel] [Vote] Confirm Konrad Rzeszutek Wilk as Xen project
	Hypervisor Committer (please vote by Nov 30th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6560551623559602458=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6560551623559602458==
Content-Type: multipart/alternative; boundary="Apple-Mail=_8688EF64-BC13-4C20-9047-4B8A0AC79F4B"


--Apple-Mail=_8688EF64-BC13-4C20-9047-4B8A0AC79F4B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi all,

last week Ian Jackson nominated Konrad as Xen Project Hypervisor =
committer.

Our governance process requires a formal vote by existing committers to =
confirm Konrad and for me to set up a voting form. Existing committers =
are: Keir Fraser, Ian Campbell, Ian Jackson, Jan Beulich and Tim Deegan. =
Others are welcome to voice support.

The voting form is at =
https://docs.google.com/forms/d/1Hpoda2VjdMMGDsz1zh01tkHPR1vUsVeUVAR0DWhlg=
ik/viewform but if you want to vote in public feel free to just reply to =
this thread.=20

Best Regards
Lars=

--Apple-Mail=_8688EF64-BC13-4C20-9047-4B8A0AC79F4B
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi all,</div><div><br></div><div>last week Ian Jackson nominated Konrad as Xen Project Hypervisor committer.</div><div><br></div><div>Our governance process requires a formal vote by existing committers to confirm Konrad and for me to set up a voting form. Existing committers are: Keir Fraser, Ian Campbell, Ian Jackson, Jan Beulich and Tim Deegan. Others are welcome to voice support.</div><div><br></div><div>The voting form is at&nbsp;<a href="https://docs.google.com/forms/d/1Hpoda2VjdMMGDsz1zh01tkHPR1vUsVeUVAR0DWhlgik/viewform">https://docs.google.com/forms/d/1Hpoda2VjdMMGDsz1zh01tkHPR1vUsVeUVAR0DWhlgik/viewform</a>&nbsp;but if you want to vote in public feel free to just reply to this thread.&nbsp;</div><div><br></div><div>Best Regards</div><div>Lars</div></body></html>
--Apple-Mail=_8688EF64-BC13-4C20-9047-4B8A0AC79F4B--


--===============6560551623559602458==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6560551623559602458==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 16:26:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16: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 1XqP8O-00010d-IH; Mon, 17 Nov 2014 16:26:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1XqP8N-00010V-6q
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 16:26:35 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	83/D4-09936-AB12A645; Mon, 17 Nov 2014 16:26:34 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416241584!13399129!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNTE5MTAgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28562 invoked from network); 17 Nov 2014 16:26:24 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 16:26:24 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so2310889wiv.1
	for <xen-devel@lists.xenproject.org>;
	Mon, 17 Nov 2014 08:26:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:subject:message-id:date:to:mime-version;
	bh=JJLMd6Xc+Ve5prXmoK2zINccoQQtv20KCUA2cVIlZJs=;
	b=gP0TrNYLKpk5s0u90d6/ASd2UBxDJYzH3oX0W7PqMq670LX1hj6seIwBWu0cRNh7i9
	tvc/KfXEXetG6gCIXjdyZWer/pdCIeqIaj16ffR1qQXGeoaVKc7k47VU2VLO+i9H4GdY
	KhtYzFfuXdvr8K4e/Fw279z4MKroI2aSR6YIyJ6xR/JAHpLharXABRzzRK5UWJMe92u6
	PsJE8qOIh/zvRhiB8i5cybFSmwBeB/hGJTj10ESr5NMU9tdsTnUw5lMiyEA9hA5wzab3
	VFWt99i3CORgYseR0XpgTb/7pVv1v/R4M1hP+rDBdNARmO3fP2HhE5mcbBYGYKbMnKiY
	UIcA==
X-Received: by 10.194.119.230 with SMTP id kx6mr34165696wjb.80.1416241584292; 
	Mon, 17 Nov 2014 08:26:24 -0800 (PST)
Received: from [192.168.0.25] (97e553ce.skybroadband.com. [151.229.83.206])
	by mx.google.com with ESMTPSA id
	el6sm15851553wib.23.2014.11.17.08.26.22
	for <xen-devel@lists.xenproject.org>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 17 Nov 2014 08:26:22 -0800 (PST)
From: Lars Kurth <lars.kurth.xen@gmail.com>
Message-Id: <8CD9998A-A30A-4B60-986E-BEDDCD223517@gmail.com>
Date: Mon, 17 Nov 2014 16:26:16 +0000
To: xen-devel <xen-devel@lists.xenproject.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Subject: [Xen-devel] [Vote] Confirm Konrad Rzeszutek Wilk as Xen project
	Hypervisor Committer (please vote by Nov 30th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6560551623559602458=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6560551623559602458==
Content-Type: multipart/alternative; boundary="Apple-Mail=_8688EF64-BC13-4C20-9047-4B8A0AC79F4B"


--Apple-Mail=_8688EF64-BC13-4C20-9047-4B8A0AC79F4B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi all,

last week Ian Jackson nominated Konrad as Xen Project Hypervisor =
committer.

Our governance process requires a formal vote by existing committers to =
confirm Konrad and for me to set up a voting form. Existing committers =
are: Keir Fraser, Ian Campbell, Ian Jackson, Jan Beulich and Tim Deegan. =
Others are welcome to voice support.

The voting form is at =
https://docs.google.com/forms/d/1Hpoda2VjdMMGDsz1zh01tkHPR1vUsVeUVAR0DWhlg=
ik/viewform but if you want to vote in public feel free to just reply to =
this thread.=20

Best Regards
Lars=

--Apple-Mail=_8688EF64-BC13-4C20-9047-4B8A0AC79F4B
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi all,</div><div><br></div><div>last week Ian Jackson nominated Konrad as Xen Project Hypervisor committer.</div><div><br></div><div>Our governance process requires a formal vote by existing committers to confirm Konrad and for me to set up a voting form. Existing committers are: Keir Fraser, Ian Campbell, Ian Jackson, Jan Beulich and Tim Deegan. Others are welcome to voice support.</div><div><br></div><div>The voting form is at&nbsp;<a href="https://docs.google.com/forms/d/1Hpoda2VjdMMGDsz1zh01tkHPR1vUsVeUVAR0DWhlgik/viewform">https://docs.google.com/forms/d/1Hpoda2VjdMMGDsz1zh01tkHPR1vUsVeUVAR0DWhlgik/viewform</a>&nbsp;but if you want to vote in public feel free to just reply to this thread.&nbsp;</div><div><br></div><div>Best Regards</div><div>Lars</div></body></html>
--Apple-Mail=_8688EF64-BC13-4C20-9047-4B8A0AC79F4B--


--===============6560551623559602458==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6560551623559602458==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 16:30:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16: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 1XqPCT-0001F9-B4; Mon, 17 Nov 2014 16:30:49 +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 1XqPCR-0001F3-HS
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:30:47 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	E0/39-14727-6B22A645; Mon, 17 Nov 2014 16:30:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416241845!11855843!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1589 invoked from network); 17 Nov 2014 16:30:46 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:30:46 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XqPBx-000DNG-Co; Mon, 17 Nov 2014 16:30:17 +0000
Date: Mon, 17 Nov 2014 17:30:17 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141117163017.GA29684@deinos.phlegethon.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546A2F600200007800048848@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
> >>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> > Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> >> If hardware support the pdpe1gb flag, expose it to guest by default.
> >> Users don't have to use a 'cpuid= ' option in config file to turn
> >> it on.
> > 
> > I don't understand what this flag does.  I guess from the name it
> > turns on 1G pages.  I guess these are supported ?
> > 
> > I would like to see comment from an x86 hypervisor maintainer.
> 
> Yes, we support 1Gb pages. The purpose of the patch is to not
> unconditionally hide the flag from guests. (I had commented on
> v1, but sadly this one wasn't tagged as v2, nor was I included on
> the Cc list, hence I didn't spot the new version.)
> 
> The one thing I'm not certain about is shadow mode: Only 2Mb
> pages may be supported there. Tim?

Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:30:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16: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 1XqPCT-0001F9-B4; Mon, 17 Nov 2014 16:30:49 +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 1XqPCR-0001F3-HS
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:30:47 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	E0/39-14727-6B22A645; Mon, 17 Nov 2014 16:30:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416241845!11855843!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1589 invoked from network); 17 Nov 2014 16:30:46 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:30:46 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XqPBx-000DNG-Co; Mon, 17 Nov 2014 16:30:17 +0000
Date: Mon, 17 Nov 2014 17:30:17 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141117163017.GA29684@deinos.phlegethon.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546A2F600200007800048848@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
> >>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> > Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> >> If hardware support the pdpe1gb flag, expose it to guest by default.
> >> Users don't have to use a 'cpuid= ' option in config file to turn
> >> it on.
> > 
> > I don't understand what this flag does.  I guess from the name it
> > turns on 1G pages.  I guess these are supported ?
> > 
> > I would like to see comment from an x86 hypervisor maintainer.
> 
> Yes, we support 1Gb pages. The purpose of the patch is to not
> unconditionally hide the flag from guests. (I had commented on
> v1, but sadly this one wasn't tagged as v2, nor was I included on
> the Cc list, hence I didn't spot the new version.)
> 
> The one thing I'm not certain about is shadow mode: Only 2Mb
> pages may be supported there. Tim?

Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:34:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPFz-0001QF-MX; Mon, 17 Nov 2014 16:34:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqPFx-0001Q3-PP
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 16:34:25 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	C2/F8-28865-1932A645; Mon, 17 Nov 2014 16:34:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416242063!6543673!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11360 invoked from network); 17 Nov 2014 16:34:24 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2014 16:34:24 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHGYIZL009552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 16:34:19 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHGYHE7011987
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 16:34:18 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHGYHhe010237; Mon, 17 Nov 2014 16:34:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 08:34:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4D8D5116EE5; Mon, 17 Nov 2014 11:34:16 -0500 (EST)
Date: Mon, 17 Nov 2014 11:34:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141117163416.GA22137@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1402169526.20141114230958@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 11:09:58PM +0100, Sander Eikelenboom wrote:
> 
> Friday, November 14, 2014, 9:25:13 PM, you wrote:
> 
> > On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
> >> 
> >> Friday, November 14, 2014, 4:43:58 PM, you wrote:
> >> 
> >> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
> >> >> If it still helps i could try Andrews suggestion and try out with only 
> >> >> commit aeeea485 ..
> >> 
> >> > Yes, even if it's pretty certain it's the second of the commits, verifying
> >> > this would be helpful (or if the assumption is wrong, the pattern it's
> >> > dying with would change and hence perhaps provide further clues).
> >> 
> >> > Jan
> >> 
> >> 
> >> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
> >> pasta without a panic. So it would probably be indeed that specific commit.
> 
> > Could you try running with these two patches while you enjoy an beer in the evening?
> 
> Hmm i didn't expect it not to panic and reboot anymore :-)

I should have also asked for your to run with 'iommu=verbose,debug', but
that can be done later..

The guest d16 looks to have two PCI passthrough devices:
XEN) [2014-11-14 21:31:26.569] io.c:550: d16: bind: m_gsi=37 g_gsi=36 dev=00.00.5 intx=0
XEN) [2014-11-14 21:31:28.095] io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0

And one of them uses just the GSI while the other uses four MSI-X, is
that about right?

I tried to reproduce that on my AMD box with two NICs:


# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Technical Corp. Device 1111
00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
00:04.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
00:05.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)

# cat /proc/interrupts |grep eth
 36:     384183          0  xen-pirq-ioapic-level  eth0
 63:          1          0  xen-pirq-msi-x     eth1
 64:         24     661961  xen-pirq-msi-x     eth1-rx-0
 65:        205          0  xen-pirq-msi-x     eth1-rx-1
 66:        162          0  xen-pirq-msi-x     eth1-tx-0
 67:        190          0  xen-pirq-msi-x     eth1-tx-1


Is that a similar distribution of IRQ/MSIx you end up having?
> 
> However xl dmesg (complete one attached) showed it would have:
> 
> (XEN) [2014-11-14 21:35:50.646] --MARK--
> (XEN) [2014-11-14 21:35:56.861] grant_table.c:305:d0v0 Increased maptrack size to 9 frames
> (XEN) [2014-11-14 21:36:00.647] --MARK--
> (XEN) [2014-11-14 21:36:10.410] grant_table.c:1299:d16v1 Expanding dom (16) grant table from (5) to (6) frames.
> (XEN) [2014-11-14 21:36:10.820] --MARK--
> (XEN) [2014-11-14 21:36:20.820] --MARK--
> (XEN) [2014-11-14 21:36:30.820] --MARK--
> (XEN) [2014-11-14 21:36:40.821] --MARK--
> (XEN) [2014-11-14 21:36:50.821] --MARK--
> (XEN) [2014-11-14 21:37:00.388] CPU00:
> (XEN) [2014-11-14 21:37:00.399] CPU01:
> (XEN) [2014-11-14 21:37:00.410] d16 OK-softirq 20msec ago, state:1, 41220 count, [prev:ffff83054ef5e3e0, next:ffff83054ef5e3e0]  PIRQ:0
> (XEN) [2014-11-14 21:37:00.445] d16 OK-raise   46msec ago, state:1, 41223 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
> (XEN) [2014-11-14 21:37:00.481] d16 ERR-poison 92msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
> (XEN) [2014-11-14 21:37:00.515] d16 Z-softirq  28853msec ago, state:2, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0

The PIRQ:0 would imply that this is the legacy interrupt - which would be you 0a:00.0 device 
(Conexant Systems, Inc. Device 8210).


And it is pounding on this CPU - and the issue is that the 'test_and_clear_bit' ends
up returning 0 - which means it was not able to set STATE_SCHED:
(!?)
    if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               
        {                                                                       
            hvm_dirq_assist(d, pirq_dpci);                                      
            put_domain(d);                                                      
        }                                                                       
        else                                                                    
        {                                                                       
            _record(&debug->zombie_softirq, pirq_dpci);        

which causes us to record it [Z-softirq],  which says we we are in state 2
(1<<STATE_RUN).

            reset = 1;                                                          
        }                                        

.. eons ago (28853msec).

Hmm. There is something fishy there but the only theory I have is that
we end up doing 'list_del' twice on different CPUs on the same structure.

That should not be possible, but then this check - 'test_and_clear_bit' returned
0 which means that somebody had cleared it (or it failed to clear it?)

But the only other path for 'clearing' it is via the error paths and you are
not hitting any of them.

In the mean-time, could you try this patch. It adds a bit more debug to help
me figure this out.

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 23e5ed1..443975c 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -126,17 +126,17 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         BUG();
 
     now = NOW();
-    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
            d->domid, names[type],
            (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->state, d->count, d->list.prev, d->list.next);
+            d->state, d->count, d->list.prev, d->list.next, d->dpci);
 
     if ( d->dpci )
     {
         struct hvm_pirq_dpci *pirq_dpci = d->dpci;
 
         for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
-            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
+            if ( pirq_dpci->flags & (1 << i) )
                 printk("%s ", names_flag[i]);
 
         printk(" PIRQ:%d", pirq_dpci->pirq);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:34:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPFz-0001QF-MX; Mon, 17 Nov 2014 16:34:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqPFx-0001Q3-PP
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 16:34:25 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	C2/F8-28865-1932A645; Mon, 17 Nov 2014 16:34:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416242063!6543673!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11360 invoked from network); 17 Nov 2014 16:34:24 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2014 16:34:24 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHGYIZL009552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 16:34:19 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHGYHE7011987
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 16:34:18 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHGYHhe010237; Mon, 17 Nov 2014 16:34:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 08:34:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4D8D5116EE5; Mon, 17 Nov 2014 11:34:16 -0500 (EST)
Date: Mon, 17 Nov 2014 11:34:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141117163416.GA22137@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1402169526.20141114230958@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 11:09:58PM +0100, Sander Eikelenboom wrote:
> 
> Friday, November 14, 2014, 9:25:13 PM, you wrote:
> 
> > On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
> >> 
> >> Friday, November 14, 2014, 4:43:58 PM, you wrote:
> >> 
> >> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
> >> >> If it still helps i could try Andrews suggestion and try out with only 
> >> >> commit aeeea485 ..
> >> 
> >> > Yes, even if it's pretty certain it's the second of the commits, verifying
> >> > this would be helpful (or if the assumption is wrong, the pattern it's
> >> > dying with would change and hence perhaps provide further clues).
> >> 
> >> > Jan
> >> 
> >> 
> >> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
> >> pasta without a panic. So it would probably be indeed that specific commit.
> 
> > Could you try running with these two patches while you enjoy an beer in the evening?
> 
> Hmm i didn't expect it not to panic and reboot anymore :-)

I should have also asked for your to run with 'iommu=verbose,debug', but
that can be done later..

The guest d16 looks to have two PCI passthrough devices:
XEN) [2014-11-14 21:31:26.569] io.c:550: d16: bind: m_gsi=37 g_gsi=36 dev=00.00.5 intx=0
XEN) [2014-11-14 21:31:28.095] io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0

And one of them uses just the GSI while the other uses four MSI-X, is
that about right?

I tried to reproduce that on my AMD box with two NICs:


# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Technical Corp. Device 1111
00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
00:04.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
00:05.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)

# cat /proc/interrupts |grep eth
 36:     384183          0  xen-pirq-ioapic-level  eth0
 63:          1          0  xen-pirq-msi-x     eth1
 64:         24     661961  xen-pirq-msi-x     eth1-rx-0
 65:        205          0  xen-pirq-msi-x     eth1-rx-1
 66:        162          0  xen-pirq-msi-x     eth1-tx-0
 67:        190          0  xen-pirq-msi-x     eth1-tx-1


Is that a similar distribution of IRQ/MSIx you end up having?
> 
> However xl dmesg (complete one attached) showed it would have:
> 
> (XEN) [2014-11-14 21:35:50.646] --MARK--
> (XEN) [2014-11-14 21:35:56.861] grant_table.c:305:d0v0 Increased maptrack size to 9 frames
> (XEN) [2014-11-14 21:36:00.647] --MARK--
> (XEN) [2014-11-14 21:36:10.410] grant_table.c:1299:d16v1 Expanding dom (16) grant table from (5) to (6) frames.
> (XEN) [2014-11-14 21:36:10.820] --MARK--
> (XEN) [2014-11-14 21:36:20.820] --MARK--
> (XEN) [2014-11-14 21:36:30.820] --MARK--
> (XEN) [2014-11-14 21:36:40.821] --MARK--
> (XEN) [2014-11-14 21:36:50.821] --MARK--
> (XEN) [2014-11-14 21:37:00.388] CPU00:
> (XEN) [2014-11-14 21:37:00.399] CPU01:
> (XEN) [2014-11-14 21:37:00.410] d16 OK-softirq 20msec ago, state:1, 41220 count, [prev:ffff83054ef5e3e0, next:ffff83054ef5e3e0]  PIRQ:0
> (XEN) [2014-11-14 21:37:00.445] d16 OK-raise   46msec ago, state:1, 41223 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
> (XEN) [2014-11-14 21:37:00.481] d16 ERR-poison 92msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
> (XEN) [2014-11-14 21:37:00.515] d16 Z-softirq  28853msec ago, state:2, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0

The PIRQ:0 would imply that this is the legacy interrupt - which would be you 0a:00.0 device 
(Conexant Systems, Inc. Device 8210).


And it is pounding on this CPU - and the issue is that the 'test_and_clear_bit' ends
up returning 0 - which means it was not able to set STATE_SCHED:
(!?)
    if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               
        {                                                                       
            hvm_dirq_assist(d, pirq_dpci);                                      
            put_domain(d);                                                      
        }                                                                       
        else                                                                    
        {                                                                       
            _record(&debug->zombie_softirq, pirq_dpci);        

which causes us to record it [Z-softirq],  which says we we are in state 2
(1<<STATE_RUN).

            reset = 1;                                                          
        }                                        

.. eons ago (28853msec).

Hmm. There is something fishy there but the only theory I have is that
we end up doing 'list_del' twice on different CPUs on the same structure.

That should not be possible, but then this check - 'test_and_clear_bit' returned
0 which means that somebody had cleared it (or it failed to clear it?)

But the only other path for 'clearing' it is via the error paths and you are
not hitting any of them.

In the mean-time, could you try this patch. It adds a bit more debug to help
me figure this out.

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 23e5ed1..443975c 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -126,17 +126,17 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         BUG();
 
     now = NOW();
-    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
            d->domid, names[type],
            (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->state, d->count, d->list.prev, d->list.next);
+            d->state, d->count, d->list.prev, d->list.next, d->dpci);
 
     if ( d->dpci )
     {
         struct hvm_pirq_dpci *pirq_dpci = d->dpci;
 
         for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
-            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
+            if ( pirq_dpci->flags & (1 << i) )
                 printk("%s ", names_flag[i]);
 
         printk(" PIRQ:%d", pirq_dpci->pirq);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:38:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:38:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPJR-0001Xr-9f; Mon, 17 Nov 2014 16:38:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqPJQ-0001Xl-3m
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:38:00 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	4E/38-02954-7642A645; Mon, 17 Nov 2014 16:37:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416242278!13087241!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29121 invoked from network); 17 Nov 2014 16:37:58 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:37:58 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 16:37:58 +0000
Message-Id: <546A32720200007800048873@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 16:37:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>, <xen-devel@lists.xen.org>,
	"Tamas K Lengyel" <tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
In-Reply-To: <54638141.3010500@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org,
	jun.nakajima@intel.com, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
> On 12/11/14 15:31, Tamas K Lengyel wrote:
>>  xen/include/public/domctl.h         |  44 +--
>>  xen/include/public/hvm/params.h     |   2 +-
>>  xen/include/public/mem_event.h      | 134 -------
>>  xen/include/public/memory.h         |   6 +-
>>  xen/include/public/vm_event.h       | 179 +++++++++
> 
> While in principle I think this series is a very good thing, there is a
> problem with editing the pubic header files.
> 
> The contents of mem_event.h is not currently hidden behind #ifdef
> __XEN_TOOLS__
> 
> As a result, it is strictly speaking part of the VM-visible public
> API/ABI and not permitted to change in a backwards incompatible manor.
> 
> Having said that, it is currently only usable by privileged domains, so
> there is an argument to be made for declaring that it should have been
> hidden behind __XEN_TOOLS__ in the first place, making it permittable to
> change.

I'm not sure I agree - the meaning of "tools" here would seem quite a
bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
an old consumer (remember that for many of these we have at best
fake consumers in the tree) would deal with the now differently
arranged data. I don't see any versioning of the interface, and hence
I can't see how tools would know which of the formats to expect.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:38:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:38:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPJR-0001Xr-9f; Mon, 17 Nov 2014 16:38:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqPJQ-0001Xl-3m
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:38:00 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	4E/38-02954-7642A645; Mon, 17 Nov 2014 16:37:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416242278!13087241!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29121 invoked from network); 17 Nov 2014 16:37:58 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:37:58 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 16:37:58 +0000
Message-Id: <546A32720200007800048873@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 16:37:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>, <xen-devel@lists.xen.org>,
	"Tamas K Lengyel" <tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
In-Reply-To: <54638141.3010500@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org,
	jun.nakajima@intel.com, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
> On 12/11/14 15:31, Tamas K Lengyel wrote:
>>  xen/include/public/domctl.h         |  44 +--
>>  xen/include/public/hvm/params.h     |   2 +-
>>  xen/include/public/mem_event.h      | 134 -------
>>  xen/include/public/memory.h         |   6 +-
>>  xen/include/public/vm_event.h       | 179 +++++++++
> 
> While in principle I think this series is a very good thing, there is a
> problem with editing the pubic header files.
> 
> The contents of mem_event.h is not currently hidden behind #ifdef
> __XEN_TOOLS__
> 
> As a result, it is strictly speaking part of the VM-visible public
> API/ABI and not permitted to change in a backwards incompatible manor.
> 
> Having said that, it is currently only usable by privileged domains, so
> there is an argument to be made for declaring that it should have been
> hidden behind __XEN_TOOLS__ in the first place, making it permittable to
> change.

I'm not sure I agree - the meaning of "tools" here would seem quite a
bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
an old consumer (remember that for many of these we have at best
fake consumers in the tree) would deal with the now differently
arranged data. I don't see any versioning of the interface, and hence
I can't see how tools would know which of the formats to expect.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:39:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPKt-0001dv-Oq; Mon, 17 Nov 2014 16:39:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XqPKs-0001dq-R2
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:39:31 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	CF/89-29352-2C42A645; Mon, 17 Nov 2014 16:39:30 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416242368!11822456!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14106 invoked from network); 17 Nov 2014 16:39:29 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:39:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHGdKQU014644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 16:39:21 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHGdJ6b015469
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 16:39:20 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHGdJRD028658; Mon, 17 Nov 2014 16:39:19 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 08:39:19 -0800
Message-ID: <546A2557.7010300@oracle.com>
Date: Mon, 17 Nov 2014 11:41:59 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/17/2014 10:19 AM, Andrew Cooper wrote:
> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> parse bootloader configuration files.
>
> c/s d1b93ea itself changed an an interface which previously used exclusively
> integers, to using strings in the case of a grub configuration with explicit
> default set, along with changing the code calling the interface to require a
> string.  The default value for "default" remained as an integer.
>
> As a result, any Extlinux or Lilo configuration (which drives this interface
> exclusively with integers), or Grub configuration which doesn't explicitly
> declare a default will die with an AttributeError when attempting to call
> "self.cf.default.isdigit()" where "default" is an integer.
>
> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
> which searches partitions for valid bootloader configurations, causing the
> issue to be reported as "Unable to find partition containing kernel"
>
> This patch attempts to fix the issue by altering all parts of this interface
> to use strings, as opposed to integers.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>
> ---
>
> This patch is RFC because, while I have dev tested and proved that it unwedges
> the specific senario I encountered, I have not yet tested that it contines to
> boot all other PV guests.
>
> As for 4.5-ness, this is a must-fix as far as I am concerned
>
> Either:
>   1) Revert d1b93ea (original bad changeset) and 4ee393f (attempt 1 to fix)
>   2) Take this patch in addition which hopefully fixes the regressions
> ---
>   tools/pygrub/src/ExtLinuxConf.py |    6 +++---
>   tools/pygrub/src/GrubConf.py     |    7 ++-----
>   tools/pygrub/src/LiloConf.py     |    6 +++---
>   3 files changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/tools/pygrub/src/ExtLinuxConf.py b/tools/pygrub/src/ExtLinuxConf.py
> index 510099b..e70fca6 100644
> --- a/tools/pygrub/src/ExtLinuxConf.py
> +++ b/tools/pygrub/src/ExtLinuxConf.py
> @@ -123,7 +123,7 @@ class ExtLinuxConfigFile(object):
>           self.filename = fn
>           self.images = []
>           self.timeout = -1
> -        self._default = 0
> +        self._default = "0"
>   
>           if fn is not None:
>               self.parse()
> @@ -191,8 +191,8 @@ class ExtLinuxConfigFile(object):
>       def _get_default(self):
>           for i in range(len(self.images)):
>               if self.images[i].title == self._default:
> -                return i
> -        return 0
> +                return str(i)
> +        return "0"
>       def _set_default(self, val):
>           self._default = val
>       default = property(_get_default, _set_default)
> diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
> index dea7044..645b6e2 100644
> --- a/tools/pygrub/src/GrubConf.py
> +++ b/tools/pygrub/src/GrubConf.py
> @@ -170,7 +170,7 @@ class _GrubConfigFile(object):
>           self.filename = fn
>           self.images = []
>           self.timeout = -1
> -        self._default = 0
> +        self._default = "0"
>           self.passwordAccess = True
>           self.passExc = None
>   
> @@ -229,12 +229,9 @@ class _GrubConfigFile(object):
>           return self._default
>       def _set_default(self, val):
>           if val == "saved":
> -            self._default = 0
> +            self._default = "0"
>           else:
>               self._default = val

If we are using strings-only value, should this also be str(val)? Here 
and elsewhere. (My python skills are highly questionable so I don't know 
whether this would be needed).

Other than that, I tested this with a few grub2 configurations and it 
worked fine.

-boris

> -
> -        if self._default < 0:
> -            raise ValueError, "default must be positive number"
>       default = property(_get_default, _set_default)
>   
>       def set_splash(self, val):
> diff --git a/tools/pygrub/src/LiloConf.py b/tools/pygrub/src/LiloConf.py
> index 2cb649f..53411e6 100644
> --- a/tools/pygrub/src/LiloConf.py
> +++ b/tools/pygrub/src/LiloConf.py
> @@ -89,7 +89,7 @@ class LiloConfigFile(object):
>           self.filename = fn
>           self.images = []
>           self.timeout = -1
> -        self._default = 0
> +        self._default = "0"
>   
>           if fn is not None:
>               self.parse()
> @@ -156,8 +156,8 @@ class LiloConfigFile(object):
>       def _get_default(self):
>           for i in range(len(self.images)):
>               if self.images[i].title == self._default:
> -                return i
> -        return 0
> +                return str(i)
> +        return "0"
>       def _set_default(self, val):
>           self._default = val
>       default = property(_get_default, _set_default)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:39:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPKt-0001dv-Oq; Mon, 17 Nov 2014 16:39:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XqPKs-0001dq-R2
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:39:31 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	CF/89-29352-2C42A645; Mon, 17 Nov 2014 16:39:30 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416242368!11822456!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14106 invoked from network); 17 Nov 2014 16:39:29 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:39:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHGdKQU014644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 16:39:21 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHGdJ6b015469
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 16:39:20 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHGdJRD028658; Mon, 17 Nov 2014 16:39:19 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 08:39:19 -0800
Message-ID: <546A2557.7010300@oracle.com>
Date: Mon, 17 Nov 2014 11:41:59 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/17/2014 10:19 AM, Andrew Cooper wrote:
> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> parse bootloader configuration files.
>
> c/s d1b93ea itself changed an an interface which previously used exclusively
> integers, to using strings in the case of a grub configuration with explicit
> default set, along with changing the code calling the interface to require a
> string.  The default value for "default" remained as an integer.
>
> As a result, any Extlinux or Lilo configuration (which drives this interface
> exclusively with integers), or Grub configuration which doesn't explicitly
> declare a default will die with an AttributeError when attempting to call
> "self.cf.default.isdigit()" where "default" is an integer.
>
> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
> which searches partitions for valid bootloader configurations, causing the
> issue to be reported as "Unable to find partition containing kernel"
>
> This patch attempts to fix the issue by altering all parts of this interface
> to use strings, as opposed to integers.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>
> ---
>
> This patch is RFC because, while I have dev tested and proved that it unwedges
> the specific senario I encountered, I have not yet tested that it contines to
> boot all other PV guests.
>
> As for 4.5-ness, this is a must-fix as far as I am concerned
>
> Either:
>   1) Revert d1b93ea (original bad changeset) and 4ee393f (attempt 1 to fix)
>   2) Take this patch in addition which hopefully fixes the regressions
> ---
>   tools/pygrub/src/ExtLinuxConf.py |    6 +++---
>   tools/pygrub/src/GrubConf.py     |    7 ++-----
>   tools/pygrub/src/LiloConf.py     |    6 +++---
>   3 files changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/tools/pygrub/src/ExtLinuxConf.py b/tools/pygrub/src/ExtLinuxConf.py
> index 510099b..e70fca6 100644
> --- a/tools/pygrub/src/ExtLinuxConf.py
> +++ b/tools/pygrub/src/ExtLinuxConf.py
> @@ -123,7 +123,7 @@ class ExtLinuxConfigFile(object):
>           self.filename = fn
>           self.images = []
>           self.timeout = -1
> -        self._default = 0
> +        self._default = "0"
>   
>           if fn is not None:
>               self.parse()
> @@ -191,8 +191,8 @@ class ExtLinuxConfigFile(object):
>       def _get_default(self):
>           for i in range(len(self.images)):
>               if self.images[i].title == self._default:
> -                return i
> -        return 0
> +                return str(i)
> +        return "0"
>       def _set_default(self, val):
>           self._default = val
>       default = property(_get_default, _set_default)
> diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
> index dea7044..645b6e2 100644
> --- a/tools/pygrub/src/GrubConf.py
> +++ b/tools/pygrub/src/GrubConf.py
> @@ -170,7 +170,7 @@ class _GrubConfigFile(object):
>           self.filename = fn
>           self.images = []
>           self.timeout = -1
> -        self._default = 0
> +        self._default = "0"
>           self.passwordAccess = True
>           self.passExc = None
>   
> @@ -229,12 +229,9 @@ class _GrubConfigFile(object):
>           return self._default
>       def _set_default(self, val):
>           if val == "saved":
> -            self._default = 0
> +            self._default = "0"
>           else:
>               self._default = val

If we are using strings-only value, should this also be str(val)? Here 
and elsewhere. (My python skills are highly questionable so I don't know 
whether this would be needed).

Other than that, I tested this with a few grub2 configurations and it 
worked fine.

-boris

> -
> -        if self._default < 0:
> -            raise ValueError, "default must be positive number"
>       default = property(_get_default, _set_default)
>   
>       def set_splash(self, val):
> diff --git a/tools/pygrub/src/LiloConf.py b/tools/pygrub/src/LiloConf.py
> index 2cb649f..53411e6 100644
> --- a/tools/pygrub/src/LiloConf.py
> +++ b/tools/pygrub/src/LiloConf.py
> @@ -89,7 +89,7 @@ class LiloConfigFile(object):
>           self.filename = fn
>           self.images = []
>           self.timeout = -1
> -        self._default = 0
> +        self._default = "0"
>   
>           if fn is not None:
>               self.parse()
> @@ -156,8 +156,8 @@ class LiloConfigFile(object):
>       def _get_default(self):
>           for i in range(len(self.images)):
>               if self.images[i].title == self._default:
> -                return i
> -        return 0
> +                return str(i)
> +        return "0"
>       def _set_default(self, val):
>           self._default = val
>       default = property(_get_default, _set_default)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:40:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPLV-0001ik-Cg; Mon, 17 Nov 2014 16:40:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqPLR-0001iA-9i
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:40:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B4/8F-25276-4E42A645; Mon, 17 Nov 2014 16:40:04 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416242401!13400543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2715 invoked from network); 17 Nov 2014 16:40:03 -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;
	17 Nov 2014 16:40:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="193607672"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 11:39:59 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqPLJ-0007wj-S7;
	Mon, 17 Nov 2014 16:39:57 +0000
Date: Mon, 17 Nov 2014 16:39:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Although it is possible that that patch is the cause of your problem,
unfortunately it is part of a significant rework of the GIC driver in
Xen and I am afraid that testing with only a portion of that patch
series might introduce other subtle bugs.  For your reference the series
starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.

If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
might not work correctly on your platform. It wouldn't be the first time
that we see hardware behaving that way, especially if you are using the
GIC secure registers instead of the non-secure register as GICH_LRn.HW
can only deactivate non-secure interrupts. This is usually due to a
configuration error in u-boot.

Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
platform?



On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
> Hi,
> 
> Issue occurs after the following commit:
> 
> commit 5495a512b63bad868c147198f7f049c2617d468c
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Tue Jun 10 15:07:12 2014 +0100
> 
>     xen/arm: support HW interrupts, do not request maintenance_interrupts
> 
>     If the irq to be injected is an hardware irq (p->desc != NULL), set
>     GICH_LR_HW. Do not set GICH_LR_MAINTENANCE_IRQ.
> 
> 
> I'm going to debug it deeply.
> Stefano - may be you have a feeling what it can be ?
> 
> Regards,
> Andrii
> 
> 
> On Fri, Nov 14, 2014 at 6:40 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > Hi Julien,
> >
> >> I would be surprised that the next GIC series impact this code as the
> >> next driver is only compiled for arm64 (GICv3 doesn't exist on arm32).
> >> Though, there was some refactoring.
> >
> > I meant that code was divided for generic GIC and GICv2 together with
> > refactoring. Also in mails I saw that it was initially tested without
> > SMP.
> > GICv3 has no impacts for sure.
> >
> >>
> >> The interrupt management has also been reworked for Xen 4.5 to avoid
> >> maintenance interrupt. I would give a look on this part.
> >
> > Thanks, this may help.
> >
> > Regards,
> > Andrii
> >
> >
> >>
> >> Regards,
> >>
> >> --
> >> Julien Grall
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:40:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPLV-0001ik-Cg; Mon, 17 Nov 2014 16:40:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqPLR-0001iA-9i
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:40:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B4/8F-25276-4E42A645; Mon, 17 Nov 2014 16:40:04 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416242401!13400543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2715 invoked from network); 17 Nov 2014 16:40:03 -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;
	17 Nov 2014 16:40:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="193607672"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 11:39:59 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqPLJ-0007wj-S7;
	Mon, 17 Nov 2014 16:39:57 +0000
Date: Mon, 17 Nov 2014 16:39:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Although it is possible that that patch is the cause of your problem,
unfortunately it is part of a significant rework of the GIC driver in
Xen and I am afraid that testing with only a portion of that patch
series might introduce other subtle bugs.  For your reference the series
starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.

If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
might not work correctly on your platform. It wouldn't be the first time
that we see hardware behaving that way, especially if you are using the
GIC secure registers instead of the non-secure register as GICH_LRn.HW
can only deactivate non-secure interrupts. This is usually due to a
configuration error in u-boot.

Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
platform?



On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
> Hi,
> 
> Issue occurs after the following commit:
> 
> commit 5495a512b63bad868c147198f7f049c2617d468c
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Tue Jun 10 15:07:12 2014 +0100
> 
>     xen/arm: support HW interrupts, do not request maintenance_interrupts
> 
>     If the irq to be injected is an hardware irq (p->desc != NULL), set
>     GICH_LR_HW. Do not set GICH_LR_MAINTENANCE_IRQ.
> 
> 
> I'm going to debug it deeply.
> Stefano - may be you have a feeling what it can be ?
> 
> Regards,
> Andrii
> 
> 
> On Fri, Nov 14, 2014 at 6:40 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > Hi Julien,
> >
> >> I would be surprised that the next GIC series impact this code as the
> >> next driver is only compiled for arm64 (GICv3 doesn't exist on arm32).
> >> Though, there was some refactoring.
> >
> > I meant that code was divided for generic GIC and GICv2 together with
> > refactoring. Also in mails I saw that it was initially tested without
> > SMP.
> > GICv3 has no impacts for sure.
> >
> >>
> >> The interrupt management has also been reworked for Xen 4.5 to avoid
> >> maintenance interrupt. I would give a look on this part.
> >
> > Thanks, this may help.
> >
> > Regards,
> > Andrii
> >
> >
> >>
> >> Regards,
> >>
> >> --
> >> Julien Grall
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:40:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:40:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPM4-0001oK-1L; Mon, 17 Nov 2014 16:40:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqPM2-0001ny-Ny
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:40:42 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FA/C0-25276-A052A645; Mon, 17 Nov 2014 16:40:42 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416242439!13349832!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25232 invoked from network); 17 Nov 2014 16:40:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 16:40:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="192110547"
Message-ID: <546A2503.4000302@citrix.com>
Date: Mon, 17 Nov 2014 16:40:35 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>	<21610.5784.968036.992847@mariner.uk.xensource.com>	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
In-Reply-To: <20141117163017.GA29684@deinos.phlegethon.org>
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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 17/11/14 16:30, Tim Deegan wrote:
> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>> Users don't have to use a 'cpuid= ' option in config file to turn
>>>> it on.
>>> I don't understand what this flag does.  I guess from the name it
>>> turns on 1G pages.  I guess these are supported ?
>>>
>>> I would like to see comment from an x86 hypervisor maintainer.
>> Yes, we support 1Gb pages. The purpose of the patch is to not
>> unconditionally hide the flag from guests. (I had commented on
>> v1, but sadly this one wasn't tagged as v2, nor was I included on
>> the Cc list, hence I didn't spot the new version.)
>>
>> The one thing I'm not certain about is shadow mode: Only 2Mb
>> pages may be supported there. Tim?
> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()

This is yet another case which proves that libxc is the wrong place to
be choosing the cpuid flags exposed to a domain.

Furthermore, guest_supports_1G_superpages() is insufficient as it only
checks whether the host is capable of providing 1G superpages, not
whether the guest has been permitted to use it.

This causes a problem when migrating between hap-capable and
hap-incapable systems.

I do hope to fix all of this with my planned changes to the cpuid
infrastructure.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:40:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:40:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPM4-0001oK-1L; Mon, 17 Nov 2014 16:40:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqPM2-0001ny-Ny
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:40:42 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FA/C0-25276-A052A645; Mon, 17 Nov 2014 16:40:42 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416242439!13349832!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25232 invoked from network); 17 Nov 2014 16:40:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 16:40:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="192110547"
Message-ID: <546A2503.4000302@citrix.com>
Date: Mon, 17 Nov 2014 16:40:35 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>	<21610.5784.968036.992847@mariner.uk.xensource.com>	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
In-Reply-To: <20141117163017.GA29684@deinos.phlegethon.org>
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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 17/11/14 16:30, Tim Deegan wrote:
> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>> Users don't have to use a 'cpuid= ' option in config file to turn
>>>> it on.
>>> I don't understand what this flag does.  I guess from the name it
>>> turns on 1G pages.  I guess these are supported ?
>>>
>>> I would like to see comment from an x86 hypervisor maintainer.
>> Yes, we support 1Gb pages. The purpose of the patch is to not
>> unconditionally hide the flag from guests. (I had commented on
>> v1, but sadly this one wasn't tagged as v2, nor was I included on
>> the Cc list, hence I didn't spot the new version.)
>>
>> The one thing I'm not certain about is shadow mode: Only 2Mb
>> pages may be supported there. Tim?
> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()

This is yet another case which proves that libxc is the wrong place to
be choosing the cpuid flags exposed to a domain.

Furthermore, guest_supports_1G_superpages() is insufficient as it only
checks whether the host is capable of providing 1G superpages, not
whether the guest has been permitted to use it.

This causes a problem when migrating between hap-capable and
hap-incapable systems.

I do hope to fix all of this with my planned changes to the cpuid
infrastructure.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:43:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16: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.xen.org>)
	id 1XqPOw-00026c-Le; Mon, 17 Nov 2014 16:43:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XqPOv-00026R-Jq
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:43:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C5/4A-09842-DB52A645; Mon, 17 Nov 2014 16:43:41 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416242619!13030264!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10872 invoked from network); 17 Nov 2014 16:43:40 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:43:40 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=CNUPefSaC+uEUP4jvQGetkfXCvdin1QA8OCezeyYQxfBG0cWsG3zxNsYBQHPjIuLrf6nUW/gyiOKNY0zFBG72hzPdztEguIjYxaYgNFFRF/sjM6fkvi0qWO9+/285iS5rF1xqBpDeiBqpa7K6I+mXU5yQwSthpXZVhF1NLpMuyu3AdyMY6ko46I2tH4BRJEwNLMikJAZDuDhTUHrFjN7jVx/n/S2D/gpgtYdlUzohlFlI4sjW1bTxWntd6iM1poycLig3O0c6CnjDBsxc6sPDYLR6PcZhSQSPCw2yiNHHDXkGGSY68Y4NrqpbFS09aCQSeSLGvk8DjZxgOjTdJpMhg==;
	h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=
	message-id:date:from:mime-version:to:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding; s=default;
	bh=6yElOv1EYsLw4QU3wz9I0y4yaos=; b=jIIGyO42W6abVYm/fxnAz3OuF6eQ
	IBlkRKtF5So+ZmIJoXlSXGBMbdkzFL/fWigO/h27hv6EyACmeIejsHyYmF9HX2zJ
	h7CRLGirEG4+R9CTTyxC3I/iTANIqtsrpVlCkYFcdadwo2eVEvzYLtql4JzxwsLd
	vBX0ndtjQc2Mw9eWT8EgSq1jU8DhmVnOG2nlbCfO4ND+PiZ/Rshhn0z9y7ZM5QmM
	LW1cmRaT7CEQk6WtpYYQIW7IaPkR3gSE1f8WFBmojZmTCk69tCcf8pgUAnu8sKcU
	uiY13QnIFcMWQQGFqmZM8xz32V2mdjp7ICmSi/JEldmfQUuPk4/uZsHpxw==
Received: (qmail 28342 invoked from network); 17 Nov 2014 18:43:39 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	17 Nov 2014 18:43:39 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id B8103803BF
	for <xen-devel@lists.xen.org>; Mon, 17 Nov 2014 18:43:38 +0200 (EET)
Received: (qmail 27912 invoked from network); 17 Nov 2014 18:43:38 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by smtp03.buh.bitdefender.org with SMTP; 17 Nov 2014 18:43:35 +0200
Message-ID: <546A25BC.3020000@bitdefender.com>
Date: Mon, 17 Nov 2014 18:43:40 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xen.org, Tamas K Lengyel <tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>	<54638141.3010500@citrix.com>
	<546A32720200007800048873@mail.emea.novell.com>
In-Reply-To: <546A32720200007800048873@mail.emea.novell.com>
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.57805
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 373141,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_BEST_COPIES_ADN;
	NN_LEGIT_VALID_REPLY; NN_LEGIT_SUMM_400_WORDS; NN_NO_LINK_NMD;
	NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS;
	NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled], URL: [Enabled], RTDA:
	[Enabled, Hit: No, Details: v1.9.3; Id: 2m1ghdo.196fcibc1.1b84eu],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org,
	jun.nakajima@intel.com, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/17/2014 06:37 PM, Jan Beulich wrote:
>>>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
>> On 12/11/14 15:31, Tamas K Lengyel wrote:
>>>  xen/include/public/domctl.h         |  44 +--
>>>  xen/include/public/hvm/params.h     |   2 +-
>>>  xen/include/public/mem_event.h      | 134 -------
>>>  xen/include/public/memory.h         |   6 +-
>>>  xen/include/public/vm_event.h       | 179 +++++++++
>>
>> While in principle I think this series is a very good thing, there is a
>> problem with editing the pubic header files.
>>
>> The contents of mem_event.h is not currently hidden behind #ifdef
>> __XEN_TOOLS__
>>
>> As a result, it is strictly speaking part of the VM-visible public
>> API/ABI and not permitted to change in a backwards incompatible manor.
>>
>> Having said that, it is currently only usable by privileged domains, so
>> there is an argument to be made for declaring that it should have been
>> hidden behind __XEN_TOOLS__ in the first place, making it permittable to
>> change.
> 
> I'm not sure I agree - the meaning of "tools" here would seem quite a
> bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
> an old consumer (remember that for many of these we have at best
> fake consumers in the tree) would deal with the now differently
> arranged data. I don't see any versioning of the interface, and hence
> I can't see how tools would know which of the formats to expect.

In the initial patch I've sent Tamas I had arranged things as follows,
(so that the layout would stay compatible) but I think we ended up
discussing it and deciding it would look cleaner to just re-do the whole
thing:

+struct mem_event_ept_data {
+    uint64_t gfn;
+    uint64_t offset;
+    uint64_t gla; /* if gla_valid */
+};
+
+struct mem_event_cr_data {
+    uint64_t new_value;
+    uint64_t _pad;
+    uint64_t old_value;
+};
+
+struct mem_event_int3_data {
+    uint64_t gfn;
+    uint64_t _pad;
+    uint64_t eip;
+};
+
+struct mem_event_singlestep_data {
+    uint64_t gfn;
+    uint64_t _pad;
+    uint64_t eip;
+};
+
+struct mem_event_msr_data {
+    uint64_t msr;
+    uint64_t old_value;
+    uint64_t new_value;
+};
+
 typedef struct mem_event_st {
     uint32_t flags;
     uint32_t vcpu_id;

-    uint64_t gfn;
-    uint64_t offset;
-    uint64_t gla; /* if gla_valid */
+    union {
+        struct mem_event_ept_data        ept_event;
+        struct mem_event_cr_data         cr_event;
+        struct mem_event_int3_data       int3_event;
+        struct mem_event_singlestep_data singlestep_event;
+        struct mem_event_msr_data        msr_event;
+    };

     uint32_t p2mt;

Would something like this be more along the right lines?


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:43:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16: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.xen.org>)
	id 1XqPOw-00026c-Le; Mon, 17 Nov 2014 16:43:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XqPOv-00026R-Jq
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:43:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C5/4A-09842-DB52A645; Mon, 17 Nov 2014 16:43:41 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416242619!13030264!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10872 invoked from network); 17 Nov 2014 16:43:40 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:43:40 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=CNUPefSaC+uEUP4jvQGetkfXCvdin1QA8OCezeyYQxfBG0cWsG3zxNsYBQHPjIuLrf6nUW/gyiOKNY0zFBG72hzPdztEguIjYxaYgNFFRF/sjM6fkvi0qWO9+/285iS5rF1xqBpDeiBqpa7K6I+mXU5yQwSthpXZVhF1NLpMuyu3AdyMY6ko46I2tH4BRJEwNLMikJAZDuDhTUHrFjN7jVx/n/S2D/gpgtYdlUzohlFlI4sjW1bTxWntd6iM1poycLig3O0c6CnjDBsxc6sPDYLR6PcZhSQSPCw2yiNHHDXkGGSY68Y4NrqpbFS09aCQSeSLGvk8DjZxgOjTdJpMhg==;
	h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=
	message-id:date:from:mime-version:to:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding; s=default;
	bh=6yElOv1EYsLw4QU3wz9I0y4yaos=; b=jIIGyO42W6abVYm/fxnAz3OuF6eQ
	IBlkRKtF5So+ZmIJoXlSXGBMbdkzFL/fWigO/h27hv6EyACmeIejsHyYmF9HX2zJ
	h7CRLGirEG4+R9CTTyxC3I/iTANIqtsrpVlCkYFcdadwo2eVEvzYLtql4JzxwsLd
	vBX0ndtjQc2Mw9eWT8EgSq1jU8DhmVnOG2nlbCfO4ND+PiZ/Rshhn0z9y7ZM5QmM
	LW1cmRaT7CEQk6WtpYYQIW7IaPkR3gSE1f8WFBmojZmTCk69tCcf8pgUAnu8sKcU
	uiY13QnIFcMWQQGFqmZM8xz32V2mdjp7ICmSi/JEldmfQUuPk4/uZsHpxw==
Received: (qmail 28342 invoked from network); 17 Nov 2014 18:43:39 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	17 Nov 2014 18:43:39 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id B8103803BF
	for <xen-devel@lists.xen.org>; Mon, 17 Nov 2014 18:43:38 +0200 (EET)
Received: (qmail 27912 invoked from network); 17 Nov 2014 18:43:38 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by smtp03.buh.bitdefender.org with SMTP; 17 Nov 2014 18:43:35 +0200
Message-ID: <546A25BC.3020000@bitdefender.com>
Date: Mon, 17 Nov 2014 18:43:40 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xen.org, Tamas K Lengyel <tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>	<54638141.3010500@citrix.com>
	<546A32720200007800048873@mail.emea.novell.com>
In-Reply-To: <546A32720200007800048873@mail.emea.novell.com>
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.57805
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 373141,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_BEST_COPIES_ADN;
	NN_LEGIT_VALID_REPLY; NN_LEGIT_SUMM_400_WORDS; NN_NO_LINK_NMD;
	NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS;
	NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled], URL: [Enabled], RTDA:
	[Enabled, Hit: No, Details: v1.9.3; Id: 2m1ghdo.196fcibc1.1b84eu],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org,
	jun.nakajima@intel.com, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/17/2014 06:37 PM, Jan Beulich wrote:
>>>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
>> On 12/11/14 15:31, Tamas K Lengyel wrote:
>>>  xen/include/public/domctl.h         |  44 +--
>>>  xen/include/public/hvm/params.h     |   2 +-
>>>  xen/include/public/mem_event.h      | 134 -------
>>>  xen/include/public/memory.h         |   6 +-
>>>  xen/include/public/vm_event.h       | 179 +++++++++
>>
>> While in principle I think this series is a very good thing, there is a
>> problem with editing the pubic header files.
>>
>> The contents of mem_event.h is not currently hidden behind #ifdef
>> __XEN_TOOLS__
>>
>> As a result, it is strictly speaking part of the VM-visible public
>> API/ABI and not permitted to change in a backwards incompatible manor.
>>
>> Having said that, it is currently only usable by privileged domains, so
>> there is an argument to be made for declaring that it should have been
>> hidden behind __XEN_TOOLS__ in the first place, making it permittable to
>> change.
> 
> I'm not sure I agree - the meaning of "tools" here would seem quite a
> bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
> an old consumer (remember that for many of these we have at best
> fake consumers in the tree) would deal with the now differently
> arranged data. I don't see any versioning of the interface, and hence
> I can't see how tools would know which of the formats to expect.

In the initial patch I've sent Tamas I had arranged things as follows,
(so that the layout would stay compatible) but I think we ended up
discussing it and deciding it would look cleaner to just re-do the whole
thing:

+struct mem_event_ept_data {
+    uint64_t gfn;
+    uint64_t offset;
+    uint64_t gla; /* if gla_valid */
+};
+
+struct mem_event_cr_data {
+    uint64_t new_value;
+    uint64_t _pad;
+    uint64_t old_value;
+};
+
+struct mem_event_int3_data {
+    uint64_t gfn;
+    uint64_t _pad;
+    uint64_t eip;
+};
+
+struct mem_event_singlestep_data {
+    uint64_t gfn;
+    uint64_t _pad;
+    uint64_t eip;
+};
+
+struct mem_event_msr_data {
+    uint64_t msr;
+    uint64_t old_value;
+    uint64_t new_value;
+};
+
 typedef struct mem_event_st {
     uint32_t flags;
     uint32_t vcpu_id;

-    uint64_t gfn;
-    uint64_t offset;
-    uint64_t gla; /* if gla_valid */
+    union {
+        struct mem_event_ept_data        ept_event;
+        struct mem_event_cr_data         cr_event;
+        struct mem_event_int3_data       int3_event;
+        struct mem_event_singlestep_data singlestep_event;
+        struct mem_event_msr_data        msr_event;
+    };

     uint32_t p2mt;

Would something like this be more along the right lines?


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:44:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPPV-0002A1-2q; Mon, 17 Nov 2014 16:44:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqPPT-00029q-Sf
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:44:15 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	4E/DC-02953-FD52A645; Mon, 17 Nov 2014 16:44:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416242654!13101594!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29372 invoked from network); 17 Nov 2014 16:44:14 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:44:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 16:44:13 +0000
Message-Id: <546A33EA02000078000488A1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 16:44:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tamas K Lengyel" <tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
In-Reply-To: <1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	andres@lagarcavilla.org, jun.nakajima@intel.com,
	rshriram@cs.ubc.ca, dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event
 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

>>> On 12.11.14 at 16:31, <tamas.lengyel@zentific.com> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c

Leaving aside the general reservation I just voiced in reply to 0/7, I
wonder whether - considering that you mostly replace the code
that gets changed in this file - it wouldn't be a nice opportunity to
move these into a separate file, allowing this huge one to not
always only grow.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:44:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPPV-0002A1-2q; Mon, 17 Nov 2014 16:44:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqPPT-00029q-Sf
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:44:15 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	4E/DC-02953-FD52A645; Mon, 17 Nov 2014 16:44:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416242654!13101594!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29372 invoked from network); 17 Nov 2014 16:44:14 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 16:44:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 16:44:13 +0000
Message-Id: <546A33EA02000078000488A1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 16:44:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tamas K Lengyel" <tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
In-Reply-To: <1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	andres@lagarcavilla.org, jun.nakajima@intel.com,
	rshriram@cs.ubc.ca, dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event
 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

>>> On 12.11.14 at 16:31, <tamas.lengyel@zentific.com> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c

Leaving aside the general reservation I just voiced in reply to 0/7, I
wonder whether - considering that you mostly replace the code
that gets changed in this file - it wouldn't be a nice opportunity to
move these into a separate file, allowing this huge one to not
always only grow.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:50:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:50:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPVb-0002Ro-Rw; Mon, 17 Nov 2014 16:50:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqPVa-0002Rj-KF
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:50:34 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	D4/04-03148-A572A645; Mon, 17 Nov 2014 16:50:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416243030!13102349!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3763 invoked from network); 17 Nov 2014 16:50:33 -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;
	17 Nov 2014 16:50:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="192115602"
Message-ID: <546A2751.5040401@citrix.com>
Date: Mon, 17 Nov 2014 16:50:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, Xen-devel
	<xen-devel@lists.xen.org>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<546A2557.7010300@oracle.com>
In-Reply-To: <546A2557.7010300@oracle.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/11/14 16:41, Boris Ostrovsky wrote:
> On 11/17/2014 10:19 AM, Andrew Cooper wrote:
>> c/s d1b93ea causes substantial functional regressions in pygrub's
>> ability to
>> parse bootloader configuration files.
>>
>> c/s d1b93ea itself changed an an interface which previously used
>> exclusively
>> integers, to using strings in the case of a grub configuration with
>> explicit
>> default set, along with changing the code calling the interface to
>> require a
>> string.  The default value for "default" remained as an integer.
>>
>> As a result, any Extlinux or Lilo configuration (which drives this
>> interface
>> exclusively with integers), or Grub configuration which doesn't
>> explicitly
>> declare a default will die with an AttributeError when attempting to
>> call
>> "self.cf.default.isdigit()" where "default" is an integer.
>>
>> Sadly, this AttributeError gets swallowed by the blanket ignore in
>> the loop
>> which searches partitions for valid bootloader configurations,
>> causing the
>> issue to be reported as "Unable to find partition containing kernel"
>>
>> This patch attempts to fix the issue by altering all parts of this
>> interface
>> to use strings, as opposed to integers.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: Ian Campbell <Ian.Campbell@citrix.com>
>> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>
>> ---
>>
>> This patch is RFC because, while I have dev tested and proved that it
>> unwedges
>> the specific senario I encountered, I have not yet tested that it
>> contines to
>> boot all other PV guests.
>>
>> As for 4.5-ness, this is a must-fix as far as I am concerned
>>
>> Either:
>>   1) Revert d1b93ea (original bad changeset) and 4ee393f (attempt 1
>> to fix)
>>   2) Take this patch in addition which hopefully fixes the regressions
>> ---
>>   tools/pygrub/src/ExtLinuxConf.py |    6 +++---
>>   tools/pygrub/src/GrubConf.py     |    7 ++-----
>>   tools/pygrub/src/LiloConf.py     |    6 +++---
>>   3 files changed, 8 insertions(+), 11 deletions(-)
>>
>> diff --git a/tools/pygrub/src/ExtLinuxConf.py
>> b/tools/pygrub/src/ExtLinuxConf.py
>> index 510099b..e70fca6 100644
>> --- a/tools/pygrub/src/ExtLinuxConf.py
>> +++ b/tools/pygrub/src/ExtLinuxConf.py
>> @@ -123,7 +123,7 @@ class ExtLinuxConfigFile(object):
>>           self.filename = fn
>>           self.images = []
>>           self.timeout = -1
>> -        self._default = 0
>> +        self._default = "0"
>>             if fn is not None:
>>               self.parse()
>> @@ -191,8 +191,8 @@ class ExtLinuxConfigFile(object):
>>       def _get_default(self):
>>           for i in range(len(self.images)):
>>               if self.images[i].title == self._default:
>> -                return i
>> -        return 0
>> +                return str(i)
>> +        return "0"
>>       def _set_default(self, val):
>>           self._default = val
>>       default = property(_get_default, _set_default)
>> diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
>> index dea7044..645b6e2 100644
>> --- a/tools/pygrub/src/GrubConf.py
>> +++ b/tools/pygrub/src/GrubConf.py
>> @@ -170,7 +170,7 @@ class _GrubConfigFile(object):
>>           self.filename = fn
>>           self.images = []
>>           self.timeout = -1
>> -        self._default = 0
>> +        self._default = "0"
>>           self.passwordAccess = True
>>           self.passExc = None
>>   @@ -229,12 +229,9 @@ class _GrubConfigFile(object):
>>           return self._default
>>       def _set_default(self, val):
>>           if val == "saved":
>> -            self._default = 0
>> +            self._default = "0"
>>           else:
>>               self._default = val
>
> If we are using strings-only value, should this also be str(val)? Here
> and elsewhere. (My python skills are highly questionable so I don't
> know whether this would be needed).
>
> Other than that, I tested this with a few grub2 configurations and it
> worked fine.

I believe not, as _set_default() is unconditionally called with val as a
string, in all config parsers.

Observe that you switched int(val) -> val in your original change.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:50:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:50:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPVb-0002Ro-Rw; Mon, 17 Nov 2014 16:50:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqPVa-0002Rj-KF
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:50:34 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	D4/04-03148-A572A645; Mon, 17 Nov 2014 16:50:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416243030!13102349!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3763 invoked from network); 17 Nov 2014 16:50:33 -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;
	17 Nov 2014 16:50:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="192115602"
Message-ID: <546A2751.5040401@citrix.com>
Date: Mon, 17 Nov 2014 16:50:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, Xen-devel
	<xen-devel@lists.xen.org>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<546A2557.7010300@oracle.com>
In-Reply-To: <546A2557.7010300@oracle.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/11/14 16:41, Boris Ostrovsky wrote:
> On 11/17/2014 10:19 AM, Andrew Cooper wrote:
>> c/s d1b93ea causes substantial functional regressions in pygrub's
>> ability to
>> parse bootloader configuration files.
>>
>> c/s d1b93ea itself changed an an interface which previously used
>> exclusively
>> integers, to using strings in the case of a grub configuration with
>> explicit
>> default set, along with changing the code calling the interface to
>> require a
>> string.  The default value for "default" remained as an integer.
>>
>> As a result, any Extlinux or Lilo configuration (which drives this
>> interface
>> exclusively with integers), or Grub configuration which doesn't
>> explicitly
>> declare a default will die with an AttributeError when attempting to
>> call
>> "self.cf.default.isdigit()" where "default" is an integer.
>>
>> Sadly, this AttributeError gets swallowed by the blanket ignore in
>> the loop
>> which searches partitions for valid bootloader configurations,
>> causing the
>> issue to be reported as "Unable to find partition containing kernel"
>>
>> This patch attempts to fix the issue by altering all parts of this
>> interface
>> to use strings, as opposed to integers.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: Ian Campbell <Ian.Campbell@citrix.com>
>> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>
>> ---
>>
>> This patch is RFC because, while I have dev tested and proved that it
>> unwedges
>> the specific senario I encountered, I have not yet tested that it
>> contines to
>> boot all other PV guests.
>>
>> As for 4.5-ness, this is a must-fix as far as I am concerned
>>
>> Either:
>>   1) Revert d1b93ea (original bad changeset) and 4ee393f (attempt 1
>> to fix)
>>   2) Take this patch in addition which hopefully fixes the regressions
>> ---
>>   tools/pygrub/src/ExtLinuxConf.py |    6 +++---
>>   tools/pygrub/src/GrubConf.py     |    7 ++-----
>>   tools/pygrub/src/LiloConf.py     |    6 +++---
>>   3 files changed, 8 insertions(+), 11 deletions(-)
>>
>> diff --git a/tools/pygrub/src/ExtLinuxConf.py
>> b/tools/pygrub/src/ExtLinuxConf.py
>> index 510099b..e70fca6 100644
>> --- a/tools/pygrub/src/ExtLinuxConf.py
>> +++ b/tools/pygrub/src/ExtLinuxConf.py
>> @@ -123,7 +123,7 @@ class ExtLinuxConfigFile(object):
>>           self.filename = fn
>>           self.images = []
>>           self.timeout = -1
>> -        self._default = 0
>> +        self._default = "0"
>>             if fn is not None:
>>               self.parse()
>> @@ -191,8 +191,8 @@ class ExtLinuxConfigFile(object):
>>       def _get_default(self):
>>           for i in range(len(self.images)):
>>               if self.images[i].title == self._default:
>> -                return i
>> -        return 0
>> +                return str(i)
>> +        return "0"
>>       def _set_default(self, val):
>>           self._default = val
>>       default = property(_get_default, _set_default)
>> diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
>> index dea7044..645b6e2 100644
>> --- a/tools/pygrub/src/GrubConf.py
>> +++ b/tools/pygrub/src/GrubConf.py
>> @@ -170,7 +170,7 @@ class _GrubConfigFile(object):
>>           self.filename = fn
>>           self.images = []
>>           self.timeout = -1
>> -        self._default = 0
>> +        self._default = "0"
>>           self.passwordAccess = True
>>           self.passExc = None
>>   @@ -229,12 +229,9 @@ class _GrubConfigFile(object):
>>           return self._default
>>       def _set_default(self, val):
>>           if val == "saved":
>> -            self._default = 0
>> +            self._default = "0"
>>           else:
>>               self._default = val
>
> If we are using strings-only value, should this also be str(val)? Here
> and elsewhere. (My python skills are highly questionable so I don't
> know whether this would be needed).
>
> Other than that, I tested this with a few grub2 configurations and it
> worked fine.

I believe not, as _set_default() is unconditionally called with val as a
string, in all config parsers.

Observe that you switched int(val) -> val in your original change.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:58:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPdD-0002h8-WA; Mon, 17 Nov 2014 16:58:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqPdC-0002h3-Tq
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:58:27 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	D9/E2-17735-2392A645; Mon, 17 Nov 2014 16:58:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416243502!11975089!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10602 invoked from network); 17 Nov 2014 16:58:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 16:58:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="193615971"
Message-ID: <1416243498.5466.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon, 17 Nov 2014 16:58:18 +0000
In-Reply-To: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> parse bootloader configuration files.

Please can you and Boris both provide examples of (ideally real-world)
configuration files which exhibit these failures as patches against
tools/pygrub/examples/.

Boris, in your case I mean the one which caused you to write the
original patch, which I should have remembered to ask for at the time.

Andy, in your case it would make sense to include at least one in this
patch I think.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 16:58:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 16:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPdD-0002h8-WA; Mon, 17 Nov 2014 16:58:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqPdC-0002h3-Tq
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 16:58:27 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	D9/E2-17735-2392A645; Mon, 17 Nov 2014 16:58:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416243502!11975089!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10602 invoked from network); 17 Nov 2014 16:58:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 16:58:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="193615971"
Message-ID: <1416243498.5466.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon, 17 Nov 2014 16:58:18 +0000
In-Reply-To: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> parse bootloader configuration files.

Please can you and Boris both provide examples of (ideally real-world)
configuration files which exhibit these failures as patches against
tools/pygrub/examples/.

Boris, in your case I mean the one which caused you to write the
original patch, which I should have remembered to ask for at the time.

Andy, in your case it would make sense to include at least one in this
patch I think.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 17:00:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 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.xen.org>)
	id 1XqPeu-0002oE-GG; Mon, 17 Nov 2014 17:00:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqPes-0002o2-Q0
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:00:10 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	ED/0F-17694-9992A645; Mon, 17 Nov 2014 17:00:09 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416243605!11998737!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8787 invoked from network); 17 Nov 2014 17:00:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 17:00:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="192119269"
Message-ID: <546A2985.5000106@citrix.com>
Date: Mon, 17 Nov 2014 16:59:49 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416243498.5466.27.camel@citrix.com>
In-Reply-To: <1416243498.5466.27.camel@citrix.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/11/14 16:58, Ian Campbell wrote:
> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
>> parse bootloader configuration files.
> Please can you and Boris both provide examples of (ideally real-world)
> configuration files which exhibit these failures as patches against
> tools/pygrub/examples/.
>
> Boris, in your case I mean the one which caused you to write the
> original patch, which I should have remembered to ask for at the time.
>
> Andy, in your case it would make sense to include at least one in this
> patch I think.
>
> Ian.
>

examples/ doesn't help.  The parsers themselves don't exhibit the bug. 
It is only when pygrub itself attempts to interact with the parsed
config does the issue exhibits itself.

I would have provided an example if it would have helped.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 17:00:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 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.xen.org>)
	id 1XqPeu-0002oE-GG; Mon, 17 Nov 2014 17:00:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqPes-0002o2-Q0
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:00:10 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	ED/0F-17694-9992A645; Mon, 17 Nov 2014 17:00:09 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416243605!11998737!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8787 invoked from network); 17 Nov 2014 17:00:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 17:00:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="192119269"
Message-ID: <546A2985.5000106@citrix.com>
Date: Mon, 17 Nov 2014 16:59:49 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416243498.5466.27.camel@citrix.com>
In-Reply-To: <1416243498.5466.27.camel@citrix.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/11/14 16:58, Ian Campbell wrote:
> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
>> parse bootloader configuration files.
> Please can you and Boris both provide examples of (ideally real-world)
> configuration files which exhibit these failures as patches against
> tools/pygrub/examples/.
>
> Boris, in your case I mean the one which caused you to write the
> original patch, which I should have remembered to ask for at the time.
>
> Andy, in your case it would make sense to include at least one in this
> patch I think.
>
> Ian.
>

examples/ doesn't help.  The parsers themselves don't exhibit the bug. 
It is only when pygrub itself attempts to interact with the parsed
config does the issue exhibits itself.

I would have provided an example if it would have helped.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 17:01:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17: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 1XqPfc-0002tJ-3y; Mon, 17 Nov 2014 17:00:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XqPfb-0002t7-9F
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:00:55 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	43/85-27584-6C92A645; Mon, 17 Nov 2014 17:00:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416243652!4255075!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6539 invoked from network); 17 Nov 2014 17:00:52 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 17:00:52 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XqPfE-000DrG-Mz; Mon, 17 Nov 2014 17:00:32 +0000
Date: Mon, 17 Nov 2014 18:00:32 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141117170032.GB29684@deinos.phlegethon.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546A2503.4000302@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
> On 17/11/14 16:30, Tim Deegan wrote:
> > At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
> >>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> >>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> >>>> If hardware support the pdpe1gb flag, expose it to guest by default.
> >>>> Users don't have to use a 'cpuid= ' option in config file to turn
> >>>> it on.
> >>> I don't understand what this flag does.  I guess from the name it
> >>> turns on 1G pages.  I guess these are supported ?
> >>>
> >>> I would like to see comment from an x86 hypervisor maintainer.
> >> Yes, we support 1Gb pages. The purpose of the patch is to not
> >> unconditionally hide the flag from guests. (I had commented on
> >> v1, but sadly this one wasn't tagged as v2, nor was I included on
> >> the Cc list, hence I didn't spot the new version.)
> >>
> >> The one thing I'm not certain about is shadow mode: Only 2Mb
> >> pages may be supported there. Tim?
> > Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
> > guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
> 
> This is yet another case which proves that libxc is the wrong place to
> be choosing the cpuid flags exposed to a domain.
> 
> Furthermore, guest_supports_1G_superpages() is insufficient as it only
> checks whether the host is capable of providing 1G superpages, not
> whether the guest has been permitted to use it.
> 
> This causes a problem when migrating between hap-capable and
> hap-incapable systems.

There's no notion of 'permitted' to use 1G pages, AFAICS, much like
other CPU features.  But of course a _well-behaved_ guest that has
been told in cpuid not to use 1G superpages will have no problems. :)

> I do hope to fix all of this with my planned changes to the cpuid
> infrastructure.

Good luck!

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 17:01:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17: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 1XqPfc-0002tJ-3y; Mon, 17 Nov 2014 17:00:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XqPfb-0002t7-9F
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:00:55 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	43/85-27584-6C92A645; Mon, 17 Nov 2014 17:00:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416243652!4255075!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6539 invoked from network); 17 Nov 2014 17:00:52 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 17:00:52 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XqPfE-000DrG-Mz; Mon, 17 Nov 2014 17:00:32 +0000
Date: Mon, 17 Nov 2014 18:00:32 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141117170032.GB29684@deinos.phlegethon.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546A2503.4000302@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
> On 17/11/14 16:30, Tim Deegan wrote:
> > At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
> >>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> >>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> >>>> If hardware support the pdpe1gb flag, expose it to guest by default.
> >>>> Users don't have to use a 'cpuid= ' option in config file to turn
> >>>> it on.
> >>> I don't understand what this flag does.  I guess from the name it
> >>> turns on 1G pages.  I guess these are supported ?
> >>>
> >>> I would like to see comment from an x86 hypervisor maintainer.
> >> Yes, we support 1Gb pages. The purpose of the patch is to not
> >> unconditionally hide the flag from guests. (I had commented on
> >> v1, but sadly this one wasn't tagged as v2, nor was I included on
> >> the Cc list, hence I didn't spot the new version.)
> >>
> >> The one thing I'm not certain about is shadow mode: Only 2Mb
> >> pages may be supported there. Tim?
> > Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
> > guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
> 
> This is yet another case which proves that libxc is the wrong place to
> be choosing the cpuid flags exposed to a domain.
> 
> Furthermore, guest_supports_1G_superpages() is insufficient as it only
> checks whether the host is capable of providing 1G superpages, not
> whether the guest has been permitted to use it.
> 
> This causes a problem when migrating between hap-capable and
> hap-incapable systems.

There's no notion of 'permitted' to use 1G pages, AFAICS, much like
other CPU features.  But of course a _well-behaved_ guest that has
been told in cpuid not to use 1G superpages will have no problems. :)

> I do hope to fix all of this with my planned changes to the cpuid
> infrastructure.

Good luck!

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 17:04:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17: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 1XqPiz-00039w-VM; Mon, 17 Nov 2014 17:04:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqPiy-00039p-A9
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 17:04:24 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	D1/4F-28865-79A2A645; Mon, 17 Nov 2014 17:04:23 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416243861!4255832!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30927 invoked from network); 17 Nov 2014 17:04:21 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 17 Nov 2014 17:04:21 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:62854 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqPhX-0004qI-Fs; Mon, 17 Nov 2014 18:02:55 +0100
Date: Mon, 17 Nov 2014 18:04:19 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1403873666.20141117180419@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141117163416.GA22137@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0FF0D423E2973E612"
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0FF0D423E2973E612
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Monday, November 17, 2014, 5:34:16 PM, you wrote:

> On Fri, Nov 14, 2014 at 11:09:58PM +0100, Sander Eikelenboom wrote:
>> 
>> Friday, November 14, 2014, 9:25:13 PM, you wrote:
>> 
>> > On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> >> 
>> >> Friday, November 14, 2014, 4:43:58 PM, you wrote:
>> >> 
>> >> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
>> >> >> If it still helps i could try Andrews suggestion and try out with only 
>> >> >> commit aeeea485 ..
>> >> 
>> >> > Yes, even if it's pretty certain it's the second of the commits, verifying
>> >> > this would be helpful (or if the assumption is wrong, the pattern it's
>> >> > dying with would change and hence perhaps provide further clues).
>> >> 
>> >> > Jan
>> >> 
>> >> 
>> >> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
>> >> pasta without a panic. So it would probably be indeed that specific commit.
>> 
>> > Could you try running with these two patches while you enjoy an beer in the evening?
>> 
>> Hmm i didn't expect it not to panic and reboot anymore :-)

> I should have also asked for your to run with 'iommu=verbose,debug', but
> that can be done later..

I was running with iommu=on,verbose,amd-iommu-debug ..


> The guest d16 looks to have two PCI passthrough devices:
> XEN) [2014-11-14 21:31:26.569] io.c:550: d16: bind: m_gsi=37 g_gsi=36 dev=00.00.5 intx=0
> XEN) [2014-11-14 21:31:28.095] io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0

> And one of them uses just the GSI while the other uses four MSI-X, is
> that about right?

Yes guest 16 has 1 USB controller(guest side 00:05.0) which has MSI-X enabled, and 1 conexant video-grabber 
(guest side 00:06.0) which should be MSI capable, but is is not enabled (probably by the driver) so 
using legacy interrupts.

> I tried to reproduce that on my AMD box with two NICs:

> # lspci
> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
> 00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
> 00:02.0 VGA compatible controller: Technical Corp. Device 1111
> 00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
> 00:04.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
> 00:05.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)

> # cat /proc/interrupts |grep eth
>  36:     384183          0  xen-pirq-ioapic-level  eth0
>  63:          1          0  xen-pirq-msi-x     eth1
>  64:         24     661961  xen-pirq-msi-x     eth1-rx-0
>  65:        205          0  xen-pirq-msi-x     eth1-rx-1
>  66:        162          0  xen-pirq-msi-x     eth1-tx-0
>  67:        190          0  xen-pirq-msi-x     eth1-tx-1
> Is that a similar distribution of IRQ/MSIx you end up having?

These are when they are still active and assigned to dom0 (and not owned by 
pci-back) or in the guest ?

I attached my /proc/interrupts for both dom0 as guest 16 with all guests running 
(on a Xen from before the dpci changes). 
With the devices passed through I only see one line with the IRQ of a 
PCI soundcard passed through to a PV guest:
  22:      38959          0          0          0          0          0  xen-pirq-ioapic-level  xen-pciback[0000:03:06.0]

All the other devices passed through (to HVM guests) are not visible in /proc/interrupts of dom0.

In the guest i do get these:
 23:         35          0          0          0  xen-pirq-ioapic-level  uhci_hcd:usb3
 40:   13440077          0          0          0  xen-pirq-ioapic-level  cx25821[1], cx25821[1]
 84:    2956369          0          0          0  xen-pirq-msi-x     xhci_hcd
 85:          0          0          0          0  xen-pirq-msi-x     xhci_hcd
 86:          0          0          0          0  xen-pirq-msi-x     xhci_hcd
 87:          0          0          0          0  xen-pirq-msi-x     xhci_hcd
 88:          0          0          0          0  xen-pirq-msi-x     xhci_hcd

>> 
>> However xl dmesg (complete one attached) showed it would have:
>> 
>> (XEN) [2014-11-14 21:35:50.646] --MARK--
>> (XEN) [2014-11-14 21:35:56.861] grant_table.c:305:d0v0 Increased maptrack size to 9 frames
>> (XEN) [2014-11-14 21:36:00.647] --MARK--
>> (XEN) [2014-11-14 21:36:10.410] grant_table.c:1299:d16v1 Expanding dom (16) grant table from (5) to (6) frames.
>> (XEN) [2014-11-14 21:36:10.820] --MARK--
>> (XEN) [2014-11-14 21:36:20.820] --MARK--
>> (XEN) [2014-11-14 21:36:30.820] --MARK--
>> (XEN) [2014-11-14 21:36:40.821] --MARK--
>> (XEN) [2014-11-14 21:36:50.821] --MARK--
>> (XEN) [2014-11-14 21:37:00.388] CPU00:
>> (XEN) [2014-11-14 21:37:00.399] CPU01:
>> (XEN) [2014-11-14 21:37:00.410] d16 OK-softirq 20msec ago, state:1, 41220 count, [prev:ffff83054ef5e3e0, next:ffff83054ef5e3e0]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.445] d16 OK-raise   46msec ago, state:1, 41223 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.481] d16 ERR-poison 92msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.515] d16 Z-softirq  28853msec ago, state:2, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0

> The PIRQ:0 would imply that this is the legacy interrupt - which would be you 0a:00.0 device 
> (Conexant Systems, Inc. Device 8210).

Correct.

> And it is pounding on this CPU - and the issue is that the 'test_and_clear_bit' ends
> up returning 0 - which means it was not able to set STATE_SCHED:
> (!?)
>     if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               
>         {                                                                       
>             hvm_dirq_assist(d, pirq_dpci);                                      
>             put_domain(d);                                                      
>         }                                                                       
>         else                                                                    
>         {                                                                       
>             _record(&debug->zombie_softirq, pirq_dpci);        

> which causes us to record it [Z-softirq],  which says we we are in state 2
> (1<<STATE_RUN).

>             reset = 1;                                                          
>         }                                        

> .. eons ago (28853msec).

> Hmm. There is something fishy there but the only theory I have is that
> we end up doing 'list_del' twice on different CPUs on the same structure.

The pounding would be correct .. since it's a videograbber ... wouldn't be 
fun not stretching the limits ;-) (however it's running fine for about 2 or 3 years) 


> That should not be possible, but then this check - 'test_and_clear_bit' returned
> 0 which means that somebody had cleared it (or it failed to clear it?)

> But the only other path for 'clearing' it is via the error paths and you are
> not hitting any of them.

> In the mean-time, could you try this patch. It adds a bit more debug to help
> me figure this out.

Ok will do this evening, thx !

> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index 23e5ed1..443975c 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -126,17 +126,17 @@ static void dump_record(struct _debug_f *d, unsigned int type)
>          BUG();
>  
>      now = NOW();
> -    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
> +    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
>             d->domid, names[type],
>             (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->>state, d->count, d->list.prev, d->list.next);
+            d->>state, d->count, d->list.prev, d->list.next, d->dpci);
>  
>      if ( d->dpci )
>      {
>          struct hvm_pirq_dpci *pirq_dpci = d->dpci;
>  
>          for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
> -            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
> +            if ( pirq_dpci->flags & (1 << i) )
>                  printk("%s ", names_flag[i]);
>  
>          printk(" PIRQ:%d", pirq_dpci->pirq);

------------0FF0D423E2973E612
Content-Type: text/plain;
 name="proc-interrupts-dom0.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="proc-interrupts-dom0.txt"

ICAgICAgICAgICAgQ1BVMCAgICAgICBDUFUxICAgICAgIENQVTIgICAgICAgQ1BVMyAgICAg
ICBDUFU0ICAgICAgIENQVTUgICAgICAgCiAgIDE6ICAgICAgICAgIDIgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGlycS1p
b2FwaWMtZWRnZSAgaTgwNDIKICAgODogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLWlvYXBpYy1l
ZGdlICBydGMwCiAgMTI6ICAgICAgICAgIDQgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGlycS1pb2FwaWMtZWRnZSAgaTgw
NDIKICAxNjogICAgICAgIDgyNiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLWlvYXBpYy1sZXZlbCAgc25kX2hkYV9p
bnRlbAogIDE3OiAgICAgICAgICA0ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBpcnEtaW9hcGljLWxldmVsICBlaGNpX2hj
ZDp1c2IxLCBlaGNpX2hjZDp1c2IyLCBlaGNpX2hjZDp1c2IzCiAgMTg6ICAgICA2OTQyMzEg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICB4ZW4tcGlycS1pb2FwaWMtbGV2ZWwgIG9oY2lfaGNkOnVzYjQsIG9oY2lfaGNkOnVzYjUs
IG9oY2lfaGNkOnVzYjYsIG9oY2lfaGNkOnVzYjcKICAyMjogICAgICAzODk1OSAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1w
aXJxLWlvYXBpYy1sZXZlbCAgeGVuLXBjaWJhY2tbMDAwMDowMzowNi4wXQogIDU2OiAgIDEy
MTc3NDQxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgeGVuLXBlcmNwdS12aXJxICAgICAgdGltZXIwCiAgNTc6ICAgICAgICAyNjcg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9jazAKICA1ODogICAgNDY1NDI3NSAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhl
bi1wZXJjcHUtaXBpICAgICAgIHJlc2NoZWQwCiAgNTk6ICAgICAgMjM4MDggICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVy
Y3B1LWlwaSAgICAgICBjYWxsZnVuYzAKICA2MDogICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUt
dmlycSAgICAgIGRlYnVnMAogIDYxOiAgICAgIDgyMzQxICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkgICAg
ICAgY2FsbGZ1bmNzaW5nbGUwCiAgNjI6ICAgICAgICAgIDkgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAg
ICAgICBpcnF3b3JrMAogIDYzOiAgICAgICAgICAwICAgMTQxNTQyNTUgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS12aXJxICAgICAg
dGltZXIxCiAgNjQ6ICAgICAgICAgIDAgICAgICAgIDEzMSAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9j
azEKICA2NTogICAgICAgICAgMCAgIDE1MDIxMTMyICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBpICAgICAgIHJlc2NoZWQxCiAg
NjY6ICAgICAgICAgIDAgICAgICAyNjUxMiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBjYWxsZnVuYzEKICA2Nzog
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgIHhlbi1wZXJjcHUtdmlycSAgICAgIGRlYnVnMQogIDY4OiAgICAgICAg
ICAwICAgICAgODk0MTIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgeGVuLXBlcmNwdS1pcGkgICAgICAgY2FsbGZ1bmNzaW5nbGUxCiAgNjk6ICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBpcnF3b3JrMQogIDcwOiAgICAgICAgICAw
ICAgICAgICAgIDAgICAyMDE4NzY5NSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgeGVuLXBlcmNwdS12aXJxICAgICAgdGltZXIyCiAgNzE6ICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgMTM3ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4t
cGVyY3B1LWlwaSAgICAgICBzcGlubG9jazIKICA3MjogICAgICAgICAgMCAgICAgICAgICAw
ICAgMTM0MjQ3MTEgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJj
cHUtaXBpICAgICAgIHJlc2NoZWQyCiAgNzM6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
IDI1MTg2ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlw
aSAgICAgICBjYWxsZnVuYzIKICA3NDogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtdmlycSAg
ICAgIGRlYnVnMgogIDc1OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICA5NTQyNiAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkgICAgICAgY2Fs
bGZ1bmNzaW5nbGUyCiAgNzY6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICA0ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBp
cnF3b3JrMgogIDc3OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIDIyMDI5
ODUxICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS12aXJxICAgICAgdGltZXIz
CiAgNzg6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAxMzQgICAg
ICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9jazMKICA3
OTogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAxMjY5ODAwNiAgICAgICAg
ICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBpICAgICAgIHJlc2NoZWQzCiAgODA6ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgMjgzNzIgICAgICAgICAgMCAg
ICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBjYWxsZnVuYzMKICA4MTogICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgIHhlbi1wZXJjcHUtdmlycSAgICAgIGRlYnVnMwogIDgyOiAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgMTAwMTg1ICAgICAgICAgIDAgICAgICAgICAgMCAg
eGVuLXBlcmNwdS1pcGkgICAgICAgY2FsbGZ1bmNzaW5nbGUzCiAgODM6ICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDUgICAgICAgICAgMCAgICAgICAgICAw
ICB4ZW4tcGVyY3B1LWlwaSAgICAgICBpcnF3b3JrMwogIDg0OiAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgMjI0NzMzNjggICAgICAgICAgMCAgeGVu
LXBlcmNwdS12aXJxICAgICAgdGltZXI0CiAgODU6ICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgIDEzNSAgICAgICAgICAwICB4ZW4tcGVyY3B1
LWlwaSAgICAgICBzcGlubG9jazQKICA4NjogICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgIDEyMjA0NzkzICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBp
ICAgICAgIHJlc2NoZWQ0CiAgODc6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAyODA1NyAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAg
ICBjYWxsZnVuYzQKICA4ODogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtdmlycSAgICAgIGRl
YnVnNAogIDg5OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAxMDA0NjMgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkgICAgICAgY2FsbGZ1bmNz
aW5nbGU0CiAgOTA6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMyAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBpcnF3b3Jr
NAogIDkxOiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAyMjcxMjk0NCAgeGVuLXBlcmNwdS12aXJxICAgICAgdGltZXI1CiAgOTI6
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgMTIwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9jazUKICA5MzogICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
MTE1OTA5ODkgIHhlbi1wZXJjcHUtaXBpICAgICAgIHJlc2NoZWQ1CiAgOTQ6ICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgIDI4
MDYxICB4ZW4tcGVyY3B1LWlwaSAgICAgICBjYWxsZnVuYzUKICA5NTogICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
IHhlbi1wZXJjcHUtdmlycSAgICAgIGRlYnVnNQogIDk2OiAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICA5ODU2NCAgeGVuLXBl
cmNwdS1pcGkgICAgICAgY2FsbGZ1bmNzaW5nbGU1CiAgOTc6ICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAxICB4ZW4t
cGVyY3B1LWlwaSAgICAgICBpcnF3b3JrNQogIDk4OiAgICAgIDEyNTUyICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4t
ZXZlbnQgICAgIHhlbmJ1cwogIDk5OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS12aXJxICAg
ICAgeGVuLXBjcHUKIDExNDogICAgMjk0MTgwMyAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLW1zaSAgICAgICBhaGNp
MAogMTE1OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBpcnEtbXNpICAgICAgIGFoY2kxCiAxMTY6ICAg
ICAyMDMwMjYgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICB4ZW4tcGlycS1tc2kgICAgICAgYWhjaTIKIDExNzogICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
IHhlbi1waXJxLW1zaSAgICAgICBhaGNpMwogMTE4OiAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBpcnEt
bXNpICAgICAgIGFoY2k0CiAxMTk6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGlycS1tc2kgICAgICAg
YWhjaTUKIDEyMjogICAyMTE4Njk0NyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLW1zaSAgICAgICBldGgwCiAxMjM6
ICAgIDU0MTM2NTIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICB4ZW4tcGlycS1tc2kgICAgICAgZXRoMQogMTI0OiAgICAgICAgIDI4
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgeGVuLXBpcnEtbXNpICAgICAgIHNuZF9oZGFfaW50ZWwKIDEyNTogICAgICAgODY3OCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46b3hlbnN0b3JlZAogMTI2OiAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAxMjc6ICAgICAgICAz
MjggICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDEyODogICAgICAg
IDQ5MSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46eGVuY29uc29sZWQKIDEyOTogICAg
ICA0NjcwOSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBibGtpZi1iYWNrZW5kCiAxMzA6ICAgICA2
OTc3NzMgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMTMxOiAgICAgNjA1
MjczICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjEuMC1xMC10eAogMTMyOiAgICAgICAgICA2
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjEuMC1xMC1yeAogMTMzOiAgICAgNDc1ODU2ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
IHhlbi1keW4tZXZlbnQgICAgIHZpZjEuMC1xMS10eAogMTM0OiAgICAgICAgICAyICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhl
bi1keW4tZXZlbnQgICAgIHZpZjEuMC1xMS1yeAogMTM1OiAgICAgICAgMjE0ICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1k
eW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAxMzY6ICAgICAgICA0NzYgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVu
LWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAxMzc6ICAgICAxMDU5NzcgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
eGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMTM4OiAgIDEyNTIzMzU5ICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhl
bi1keW4tZXZlbnQgICAgIHZpZjIuMC1xMC10eAogMTM5OiAgICAgMTA2MzAxICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1k
eW4tZXZlbnQgICAgIHZpZjIuMC1xMC1yeAogMTQwOiAgICAgICAgMjQzICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4t
ZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAxNDE6ICAgICAgICA0ODUgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5
bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAxNDI6ICAgICAgMzA3NzAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVu
LWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMTQzOiAgICAxMjM4ODUxICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1k
eW4tZXZlbnQgICAgIHZpZjMuMC1xMC10eAogMTQ0OiAgICAgICAyNjMyICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4t
ZXZlbnQgICAgIHZpZjMuMC1xMC1yeAogMTQ1OiAgICAgMTQwMzAyICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZl
bnQgICAgIHZpZjMuMC1xMS10eAogMTQ2OiAgICAgICAgIDQyICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQg
ICAgIHZpZjMuMC1xMS1yeAogMTQ3OiAgICAgICAgMjE0ICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAg
IGV2dGNobjpveGVuc3RvcmVkCiAxNDg6ICAgICAgICA1MDIgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAg
ICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAxNDk6ICAgICAgNTMxNzggICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVu
dCAgICAgYmxraWYtYmFja2VuZAogMTUwOiAgICAxMDc1Mjg5ICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQg
ICAgIHZpZjQuMC1xMC10eAogMTUxOiAgICAgICAxMDMyICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAg
IHZpZjQuMC1xMC1yeAogMTUyOiAgICAgICAgMjE0ICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2
dGNobjpveGVuc3RvcmVkCiAxNTM6ICAgICAgICA1MzAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAg
ZXZ0Y2huOnhlbmNvbnNvbGVkCiAxNTQ6ICAgICAgNTExMTUgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAg
ICAgYmxraWYtYmFja2VuZAogMTU1OiAgICAxMjA1Mzc4ICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAg
IHZpZjUuMC1xMC10eAogMTU2OiAgICAgICA1MDkwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZp
ZjUuMC1xMC1yeAogMTU3OiAgICAgICAgMjE5ICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNo
bjpveGVuc3RvcmVkCiAxNTg6ICAgICAgICA0ODkgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0
Y2huOnhlbmNvbnNvbGVkCiAxNTk6ICAgICAgMTA2NDIgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAg
YmxraWYtYmFja2VuZAogMTYwOiAgICAgIDE5MDM1ICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZp
ZjYuMC1xMC10eAogMTYxOiAgICAgICAgICAxICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjYu
MC1xMC1yeAogMTYyOiAgICAgICAgMjE4ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpv
eGVuc3RvcmVkCiAxNjM6ICAgICAgICA1MzggICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2hu
OnhlbmNvbnNvbGVkCiAxNjQ6ICAgICAgMTExNTcgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxr
aWYtYmFja2VuZAogMTY1OiAgICAgIDMxODUyICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjcu
MC1xMC10eAogMTY2OiAgICAgICAgICAxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjcuMC1x
MC1yeAogMTY3OiAgICAgICAgMjE5ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVu
c3RvcmVkCiAxNjg6ICAgICAgICA0OTAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhl
bmNvbnNvbGVkCiAxNjk6ICAgICAgMTUwOTYgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYt
YmFja2VuZAogMTcwOiAgICAgICAzOTE4ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjguMC1x
MC10eAogMTcxOiAgICAgICAgICAxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjguMC1xMC1y
eAogMTcyOiAgICAgICAgMjQzICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3Rv
cmVkCiAxNzM6ICAgICAgICA1NDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNv
bnNvbGVkCiAxNzQ6ICAgICAgMjQwOTQgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFj
a2VuZAogMTc1OiAgICA2Nzg0ODcxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjkuMC1xMC10
eAogMTc2OiAgICAgIDExMzI4ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjkuMC1xMC1yeAog
MTc3OiAgICA2Mjg0MTcwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjkuMC1xMS10eAogMTc4
OiAgICAgICAxNTEzICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjkuMC1xMS1yeAogMTc5OiAg
ICAgICAgMjE2ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAxODA6
ICAgICAgICA1NTUgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAx
ODE6ICAgICAgMTM1ODYgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMTgy
OiAgICAgICAxNDk1ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjEwLjAtcTAtdHgKIDE4Mzog
ICAgICAgICAgMiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxMC4wLXEwLXJ4CiAxODQ6ICAg
ICAgICAyNDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDE4NTog
ICAgICAgIDU1MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46eGVuY29uc29sZWQKIDE4
NjogICAgICAxNzE0OSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBibGtpZi1iYWNrZW5kCiAxODc6
ICAgIDEyMTQ3MTYgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTEuMC1xMC10eAogMTg4OiAg
ICAgICAgMTc1ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjExLjAtcTAtcngKIDE4OTogICAg
MTExNTMwOSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxMS4wLXExLXR4CiAxOTA6ICAgICAg
ICAgIDcgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTEuMC1xMS1yeAogMTkxOiAgICAgICAg
MjEwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAxOTI6ICAgICAg
ICA1MjkgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAxOTM6ICAg
ICAgMTA0MjIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMTk0OiAgICAg
IDU3OTE4ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjEyLjAtcTAtdHgKIDE5NTogICAgICAg
ICAgMiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxMi4wLXEwLXJ4CiAxOTY6ICAgICAgICAy
NzEgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDE5NzogICAgICAg
IDY0MSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46eGVuY29uc29sZWQKIDE5ODogICAg
ICAgIDM3NSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB4ZW4tcGNpYmFjawogMTk5OiAgICAgIDEw
NjkwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGJsa2lmLWJhY2tlbmQKIDIwMDogICAgICA3MjYy
NyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxMy4wLXEwLXR4CiAyMDE6ICAgICAgICAgODMg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTMuMC1xMC1yeAogMjAyOiAgICAgICAgMjE4ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
IHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAyMDM6ICAgICAgICA1OTcg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAyMDQ6ICAgICAgMTky
MjAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMjA1OiAgICAgODIyODA3
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjE0LjAtcTAtdHgKIDIwNjogICAgICAgICAgMiAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxNC4wLXEwLXJ4CiAyMDc6ICAgICAgICAyMTUgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
eGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDIwODogICAgICAgIDUzNyAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46eGVuY29uc29sZWQKIDIwOTogICAgICAxOTg3
MiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICB4ZW4tZHluLWV2ZW50ICAgICBibGtpZi1iYWNrZW5kCiAyMTA6ICAgICAgICA1MTYg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTUuMC1xMC10eAogMjExOiAgICAgICAgICAxICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
IHhlbi1keW4tZXZlbnQgICAgIHZpZjE1LjAtcTAtcngKIDIxMjogICAgICAgIDUzNyAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4
ZW4tZHluLWV2ZW50ICAgICBldnRjaG46b3hlbnN0b3JlZAogMjEzOiAgICAgICAgICA1ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
IHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjp4ZW5jb25zb2xlZAogMjE0OiAgICAgMzMwNzM4
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpxZW11LXN5c3RlbS1pMzgKIDIxNTogICAg
MjIzNDUwMyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46cWVtdS1zeXN0ZW0taTM4CiAy
MTY6ICAgICAgMjM4MDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnFlbXUtc3lzdGVt
LWkzOAogMjE3OiAgICAgIDIzMjExICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpxZW11
LXN5c3RlbS1pMzgKIDIxODogICAgICAgIDEyMyAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRj
aG46cWVtdS1zeXN0ZW0taTM4CiAyMTk6ICAgICAgICAzNzkgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAg
ICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDIyMDogICAgICAgICAgMSAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50
ICAgICBldnRjaG46eGVuY29uc29sZWQKIDIyMTogICAgIDQwOTM0MSAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2
ZW50ICAgICBldnRjaG46cWVtdS1zeXN0ZW0taTM4CiAyMjI6ICAgICAgIDM3NzQgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVu
LWR5bi1ldmVudCAgICAgZXZ0Y2huOnFlbXUtc3lzdGVtLWkzOAogMjIzOiAgICAgICAxMTM2
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpxZW11LXN5c3RlbS1pMzgKIDIyNDogICAg
ICAgICAzMiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46cWVtdS1zeXN0ZW0taTM4CiAy
MjU6ICAgICAgICA0MjIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOm94ZW5zdG9yZWQK
IDIyNjogICAgICAgICAgOSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46eGVuY29uc29s
ZWQKIDIyNzogICAgIDM2MDUxOCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46cWVtdS1z
eXN0ZW0taTM4CiAyMjg6ICAgICAgIDIzMTQgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2hu
OnFlbXUtc3lzdGVtLWkzOAogMjI5OiAgICAgICAgODk4ICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAg
IGV2dGNobjpxZW11LXN5c3RlbS1pMzgKIDIzMDogICAgICAgMTYyMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2
ZW50ICAgICBldnRjaG46cWVtdS1zeXN0ZW0taTM4CiAyMzE6ICAgICAgICAgOTcgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVu
LWR5bi1ldmVudCAgICAgZXZ0Y2huOnFlbXUtc3lzdGVtLWkzOAogMjMyOiAgICAgIDk0NTg5
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIGJsa2lmLWJhY2tlbmQKIDIzMzogICAgICAzNjgwNCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICB4ZW4tZHluLWV2ZW50ICAgICBibGtpZi1iYWNrZW5kCiAyMzQ6ICAgICAxODgzODggICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
eGVuLWR5bi1ldmVudCAgICAgdmlmMTYuMC1xMC10eAogMjM1OiAgICAgICAgICAxICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhl
bi1keW4tZXZlbnQgICAgIHZpZjE2LjAtcTAtcngKIDIzNjogICAgICA1MzgxMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4t
ZHluLWV2ZW50ICAgICB2aWYxNi4wLXExLXR4CiAyMzc6ICAgICAgICAgIDEgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5
bi1ldmVudCAgICAgdmlmMTYuMC1xMS1yeAogMjM4OiAgICAgIDQ4MDgzICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4t
ZXZlbnQgICAgIHZpZjE2LjAtcTItdHgKIDIzOTogICAgICAgICAgMSAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2
ZW50ICAgICB2aWYxNi4wLXEyLXJ4CiAyNDA6ICAgICAgOTU2OTUgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVu
dCAgICAgdmlmMTYuMC1xMy10eAogMjQxOiAgICAgICAgICAyICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQg
ICAgIHZpZjE2LjAtcTMtcngKIDI0MjogICAgICAxMjUwOCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAg
ICBibGtpZi1iYWNrZW5kCiAyNDM6ICAgICAgNTYxNzQgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAg
dmlmMTcuMC1xMAogMjQ0OiAgICAgIDE1NDM3ICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGJsa2lm
LWJhY2tlbmQKIDI0NTogICAgICAgICA0NiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxOC4w
LXEwLXR4CiAyNDY6ICAgICAgICAgIDEgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTguMC1x
MC1yeAogMjQ3OiAgICAgICAgIDI3ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjE4LjAtcTEt
dHgKIDI0ODogICAgICAgICAgMSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxOC4wLXExLXJ4
CiAyNDk6ICAgICAgICAgIDggICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTguMC1xMi10eAog
MjUwOiAgICAgICAgICAxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjE4LjAtcTItcngKIDI1
MTogICAgICAgICAgOCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxOC4wLXEzLXR4CiAyNTI6
ICAgICAgICAgIDEgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTguMC1xMy1yeAogMjUzOiAg
ICAgICAgMzUyICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAyNTQ6
ICAgICAgICAgIDEgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAy
NTU6ICAgICAxNTkwNDIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnFlbXUtc3lzdGVt
LWkzOAogMjU2OiAgICAgIDM2MTAxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpxZW11
LXN5c3RlbS1pMzgKIDI1NzogICAgICAgIDIwOSAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRj
aG46cWVtdS1zeXN0ZW0taTM4CiAyNTg6ICAgICAgICAzNTUgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAg
ICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDI1OTogICAgICAgICAgNiAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50
ICAgICBldnRjaG46eGVuY29uc29sZWQKIDI2MDogICAgIDIxMTE4NSAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2
ZW50ICAgICBldnRjaG46cWVtdS1zeXN0ZW0taTM4CiAyNjE6ICAgICAgICAxMzIgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVu
LWR5bi1ldmVudCAgICAgZXZ0Y2huOnFlbXUtc3lzdGVtLWkzOAogMjYyOiAgICAgIDQ1Nzg0
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIGJsa2lmLWJhY2tlbmQKIDI2MzogICAgICAgICAgNSAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxOS4wLXEwLXR4CiAyNjQ6ICAgICAgICAgIDEgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
eGVuLWR5bi1ldmVudCAgICAgdmlmMTkuMC1xMC1yeAogMjY1OiAgICAgIDI1MTQwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhl
bi1keW4tZXZlbnQgICAgIGJsa2lmLWJhY2tlbmQKIDI2NjogICAgIDEwMDU5NSAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4t
ZHluLWV2ZW50ICAgICB2aWYyMC4wLXEwCiBOTUk6ICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgTm9uLW1hc2th
YmxlIGludGVycnVwdHMKIExPQzogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBMb2NhbCB0aW1lciBpbnRlcnJ1
cHRzCiBTUFU6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgU3B1cmlvdXMgaW50ZXJydXB0cwogUE1JOiAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgIFBlcmZvcm1hbmNlIG1vbml0b3JpbmcgaW50ZXJydXB0cwogSVdJOiAgICAg
ICAgICA5ICAgICAgICAgIDAgICAgICAgICAgNCAgICAgICAgICA1ICAgICAgICAgIDMgICAg
ICAgICAgMSAgIElSUSB3b3JrIGludGVycnVwdHMKIFJUUjogICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBBUElD
IElDUiByZWFkIHJldHJpZXMKIFJFUzogICAgNDY1NDI3NSAgIDE1MDIxMTMyICAgMTM0MjQ3
MTEgICAxMjY5ODAwNiAgIDEyMjA0NzkzICAgMTE1OTA5ODkgICBSZXNjaGVkdWxpbmcgaW50
ZXJydXB0cwogQ0FMOiAgICAgMTA2MTQ5ICAgICAxMTU5MjQgICAgIDEyMDYxMiAgICAgMTI4
NTU3ICAgICAxMjg1MjAgICAgIDEyNjYyNSAgIEZ1bmN0aW9uIGNhbGwgaW50ZXJydXB0cwog
VExCOiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgIFRMQiBzaG9vdGRvd25zCiBUUk06ICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
VGhlcm1hbCBldmVudCBpbnRlcnJ1cHRzCiBUSFI6ICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgVGhyZXNob2xk
IEFQSUMgaW50ZXJydXB0cwogTUNFOiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIE1hY2hpbmUgY2hlY2sgZXhj
ZXB0aW9ucwogTUNQOiAgICAgICAgMzEwICAgICAgICAzMTAgICAgICAgIDMxMCAgICAgICAg
MzEwICAgICAgICAzMTAgICAgICAgIDMxMCAgIE1hY2hpbmUgY2hlY2sgcG9sbHMKIFRIUjog
ICA4NDQ5ODQwMyAgIDI4OTMyMzAzICAgMzMzNzMwMTUgICAzNDUxNzUxMCAgIDM0NDgwNDc2
ICAgMzQxMTMyNzcgICBIeXBlcnZpc29yIGNhbGxiYWNrIGludGVycnVwdHMKIEVSUjogICAg
ICAgICAgMAogTUlTOiAgICAgICAgICAwCg==
------------0FF0D423E2973E612
Content-Type: text/plain;
 name="proc-interrupts-guest.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="proc-interrupts-guest.txt"

ICAgICAgICAgICBDUFUwICAgICAgIENQVTEgICAgICAgQ1BVMiAgICAgICBDUFUzICAgICAg
IAogIDA6ICAgICAgICAxMzYgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBJ
Ty1BUElDLWVkZ2UgICAgICB0aW1lcgogIDE6ICAgICAgICAgIDkgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLWlvYXBpYy1lZGdlICBpODA0MgogIDQ6ICAg
ICAgICA1MzggICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLWlv
YXBpYy1lZGdlICBzZXJpYWwKICA4OiAgICAgICAgICAyICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICB4ZW4tcGlycS1pb2FwaWMtZWRnZSAgcnRjMAogIDk6ICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBJTy1BUElDLWZhc3Rlb2kg
ICBhY3BpCiAxMjogICAgICAgIDEyNSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgeGVuLXBpcnEtaW9hcGljLWVkZ2UgIGk4MDQyCiAyMzogICAgICAgICAzNSAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBpcnEtaW9hcGljLWxldmVsICB1aGNp
X2hjZDp1c2IzCiA0MDogICAxMzQ0MDA3NyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgeGVuLXBpcnEtaW9hcGljLWxldmVsICBjeDI1ODIxWzFdLCBjeDI1ODIxWzFdCiA0
ODogICAxMzk3MzAzMyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBl
cmNwdS12aXJxICAgICAgdGltZXIwCiA0OTogICAgIDc4MjgyNyAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkgICAgICAgcmVzY2hlZDAKIDUwOiAg
ICAxODI1NTgyICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1
LWlwaSAgICAgICBjYWxsZnVuYzAKIDUxOiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LXZpcnEgICAgICBkZWJ1ZzAKIDUyOiAgICAg
Njk1NTQ4ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlw
aSAgICAgICBjYWxsZnVuY3NpbmdsZTAKIDUzOiAgICAgICA2MDMyICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9jazAKIDU0
OiAgICAgICAgICAwICAgIDkyNTIzOTEgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVy
Y3B1LXZpcnEgICAgICB0aW1lcjEKIDU1OiAgICAgICAgICAwICAgIDM2NjUwMzUgICAgICAg
ICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICByZXNjaGVkMQogNTY6ICAg
ICAgICAgIDAgICAgMTg0MjM2NCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUt
aXBpICAgICAgIGNhbGxmdW5jMQogNTc6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtdmlycSAgICAgIGRlYnVnMQogNTg6ICAgICAg
ICAgIDAgICAgIDYzMTI5OSAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBp
ICAgICAgIGNhbGxmdW5jc2luZ2xlMQogNTk6ICAgICAgICAgIDAgICAgICAgODU4NyAgICAg
ICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBpICAgICAgIHNwaW5sb2NrMQogNjA6
ICAgICAgICAgIDAgICAgICAgICAgMCAgICA4MjM5MDk2ICAgICAgICAgIDAgIHhlbi1wZXJj
cHUtdmlycSAgICAgIHRpbWVyMgogNjE6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAyNTM3
Njc5ICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBpICAgICAgIHJlc2NoZWQyCiA2MjogICAg
ICAgICAgMCAgICAgICAgICAwICAgIDE4NzcwNTAgICAgICAgICAgMCAgeGVuLXBlcmNwdS1p
cGkgICAgICAgY2FsbGZ1bmMyCiA2MzogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS12aXJxICAgICAgZGVidWcyCiA2NDogICAgICAg
ICAgMCAgICAgICAgICAwICAgICA1NDU0MDcgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkg
ICAgICAgY2FsbGZ1bmNzaW5nbGUyCiA2NTogICAgICAgICAgMCAgICAgICAgICAwICAgICAg
IDc5NzQgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkgICAgICAgc3BpbmxvY2syCiA2Njog
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgODA4MzUwMCAgeGVuLXBlcmNw
dS12aXJxICAgICAgdGltZXIzCiA2NzogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgMjAwNDI1NyAgeGVuLXBlcmNwdS1pcGkgICAgICAgcmVzY2hlZDMKIDY4OiAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAxOTE3NTk2ICB4ZW4tcGVyY3B1LWlw
aSAgICAgICBjYWxsZnVuYzMKIDY5OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICB4ZW4tcGVyY3B1LXZpcnEgICAgICBkZWJ1ZzMKIDcwOiAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgNTc4MTc0ICB4ZW4tcGVyY3B1LWlwaSAg
ICAgICBjYWxsZnVuY3NpbmdsZTMKIDcxOiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICA3NDYzICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9jazMKIDcyOiAg
ICAgICAgNTExICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1l
dmVudCAgICAgeGVuYnVzCiA3MzogICAgICAgICAgMiAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGh2Y19jb25zb2xlCiA3NDogICAgIDEw
MTg2OSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQg
ICAgIGJsa2lmCiA3NTogICAgICA2MjAwMyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGJsa2lmCiA3NjogICAgIDE5MTQxNiAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV0aDAtcTAt
dHgKIDc3OiAgICAgMTM4MjM5ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
eGVuLWR5bi1ldmVudCAgICAgZXRoMC1xMC1yeAogNzg6ICAgICAgNTgzNjEgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldGgwLXExLXR4
CiA3OTogICAgIDEzMTEyNyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhl
bi1keW4tZXZlbnQgICAgIGV0aDAtcTEtcngKIDgwOiAgICAgIDUwOTMzICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXRoMC1xMi10eAog
ODE6ICAgICAgNDM5NDIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4t
ZHluLWV2ZW50ICAgICBldGgwLXEyLXJ4CiA4MjogICAgICA5NDE5NyAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV0aDAtcTMtdHgKIDgz
OiAgICAgMTAxNjkyICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5
bi1ldmVudCAgICAgZXRoMC1xMy1yeAogODQ6ICAgIDI5NTYzNjkgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLW1zaS14ICAgICB4aGNpX2hjZAogODU6ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLW1z
aS14ICAgICB4aGNpX2hjZAogODY6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgIHhlbi1waXJxLW1zaS14ICAgICB4aGNpX2hjZAogODc6ICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLW1zaS14ICAg
ICB4aGNpX2hjZAogODg6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgIHhlbi1waXJxLW1zaS14ICAgICB4aGNpX2hjZAogODk6ICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2a2Jk
Ck5NSTogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIE5v
bi1tYXNrYWJsZSBpbnRlcnJ1cHRzCkxPQzogICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgIExvY2FsIHRpbWVyIGludGVycnVwdHMKU1BVOiAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgU3B1cmlvdXMgaW50ZXJy
dXB0cwpQTUk6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICBQZXJmb3JtYW5jZSBtb25pdG9yaW5nIGludGVycnVwdHMKSVdJOiAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgSVJRIHdvcmsgaW50ZXJydXB0cwpS
VFI6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBBUElD
IElDUiByZWFkIHJldHJpZXMKUkVTOiAgICAgNzgyODI3ICAgIDM2NjUwMzUgICAgMjUzNzY3
OSAgICAyMDA0MjU3ICAgUmVzY2hlZHVsaW5nIGludGVycnVwdHMKQ0FMOiA0Mjk0ODU2NTI0
IDQyOTQ5MTE0NDQgNDI5NDk2MjUzNCA0Mjk0OTUzMzUyICAgRnVuY3Rpb24gY2FsbCBpbnRl
cnJ1cHRzClRMQjogICAgMjYzMTkwMiAgICAyNTI5NTE1ICAgIDI0MjcyMTkgICAgMjUwOTcx
NCAgIFRMQiBzaG9vdGRvd25zClRSTTogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgIFRoZXJtYWwgZXZlbnQgaW50ZXJydXB0cwpUSFI6ICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBUaHJlc2hvbGQgQVBJQyBp
bnRlcnJ1cHRzCk1DRTogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgIE1hY2hpbmUgY2hlY2sgZXhjZXB0aW9ucwpNQ1A6ICAgICAgICAzMDggICAgICAg
IDMwOCAgICAgICAgMzA4ICAgICAgICAzMDggICBNYWNoaW5lIGNoZWNrIHBvbGxzClRIUjog
ICAzMzk3ODA3MSAgIDE1Mjk2NDc1ICAgMTMxMzE2NDEgICAxMjUyNjExOSAgIEh5cGVydmlz
b3IgY2FsbGJhY2sgaW50ZXJydXB0cwpFUlI6ICAgICAgICAgIDAKTUlTOiAgICAgICAgICAw
Cg==
------------0FF0D423E2973E612
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0FF0D423E2973E612--



From xen-devel-bounces@lists.xen.org Mon Nov 17 17:04:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17: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 1XqPiz-00039w-VM; Mon, 17 Nov 2014 17:04:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqPiy-00039p-A9
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 17:04:24 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	D1/4F-28865-79A2A645; Mon, 17 Nov 2014 17:04:23 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416243861!4255832!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30927 invoked from network); 17 Nov 2014 17:04:21 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 17 Nov 2014 17:04:21 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:62854 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqPhX-0004qI-Fs; Mon, 17 Nov 2014 18:02:55 +0100
Date: Mon, 17 Nov 2014 18:04:19 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1403873666.20141117180419@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141117163416.GA22137@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0FF0D423E2973E612"
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0FF0D423E2973E612
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Monday, November 17, 2014, 5:34:16 PM, you wrote:

> On Fri, Nov 14, 2014 at 11:09:58PM +0100, Sander Eikelenboom wrote:
>> 
>> Friday, November 14, 2014, 9:25:13 PM, you wrote:
>> 
>> > On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> >> 
>> >> Friday, November 14, 2014, 4:43:58 PM, you wrote:
>> >> 
>> >> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
>> >> >> If it still helps i could try Andrews suggestion and try out with only 
>> >> >> commit aeeea485 ..
>> >> 
>> >> > Yes, even if it's pretty certain it's the second of the commits, verifying
>> >> > this would be helpful (or if the assumption is wrong, the pattern it's
>> >> > dying with would change and hence perhaps provide further clues).
>> >> 
>> >> > Jan
>> >> 
>> >> 
>> >> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
>> >> pasta without a panic. So it would probably be indeed that specific commit.
>> 
>> > Could you try running with these two patches while you enjoy an beer in the evening?
>> 
>> Hmm i didn't expect it not to panic and reboot anymore :-)

> I should have also asked for your to run with 'iommu=verbose,debug', but
> that can be done later..

I was running with iommu=on,verbose,amd-iommu-debug ..


> The guest d16 looks to have two PCI passthrough devices:
> XEN) [2014-11-14 21:31:26.569] io.c:550: d16: bind: m_gsi=37 g_gsi=36 dev=00.00.5 intx=0
> XEN) [2014-11-14 21:31:28.095] io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0

> And one of them uses just the GSI while the other uses four MSI-X, is
> that about right?

Yes guest 16 has 1 USB controller(guest side 00:05.0) which has MSI-X enabled, and 1 conexant video-grabber 
(guest side 00:06.0) which should be MSI capable, but is is not enabled (probably by the driver) so 
using legacy interrupts.

> I tried to reproduce that on my AMD box with two NICs:

> # lspci
> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
> 00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
> 00:02.0 VGA compatible controller: Technical Corp. Device 1111
> 00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
> 00:04.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
> 00:05.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)

> # cat /proc/interrupts |grep eth
>  36:     384183          0  xen-pirq-ioapic-level  eth0
>  63:          1          0  xen-pirq-msi-x     eth1
>  64:         24     661961  xen-pirq-msi-x     eth1-rx-0
>  65:        205          0  xen-pirq-msi-x     eth1-rx-1
>  66:        162          0  xen-pirq-msi-x     eth1-tx-0
>  67:        190          0  xen-pirq-msi-x     eth1-tx-1
> Is that a similar distribution of IRQ/MSIx you end up having?

These are when they are still active and assigned to dom0 (and not owned by 
pci-back) or in the guest ?

I attached my /proc/interrupts for both dom0 as guest 16 with all guests running 
(on a Xen from before the dpci changes). 
With the devices passed through I only see one line with the IRQ of a 
PCI soundcard passed through to a PV guest:
  22:      38959          0          0          0          0          0  xen-pirq-ioapic-level  xen-pciback[0000:03:06.0]

All the other devices passed through (to HVM guests) are not visible in /proc/interrupts of dom0.

In the guest i do get these:
 23:         35          0          0          0  xen-pirq-ioapic-level  uhci_hcd:usb3
 40:   13440077          0          0          0  xen-pirq-ioapic-level  cx25821[1], cx25821[1]
 84:    2956369          0          0          0  xen-pirq-msi-x     xhci_hcd
 85:          0          0          0          0  xen-pirq-msi-x     xhci_hcd
 86:          0          0          0          0  xen-pirq-msi-x     xhci_hcd
 87:          0          0          0          0  xen-pirq-msi-x     xhci_hcd
 88:          0          0          0          0  xen-pirq-msi-x     xhci_hcd

>> 
>> However xl dmesg (complete one attached) showed it would have:
>> 
>> (XEN) [2014-11-14 21:35:50.646] --MARK--
>> (XEN) [2014-11-14 21:35:56.861] grant_table.c:305:d0v0 Increased maptrack size to 9 frames
>> (XEN) [2014-11-14 21:36:00.647] --MARK--
>> (XEN) [2014-11-14 21:36:10.410] grant_table.c:1299:d16v1 Expanding dom (16) grant table from (5) to (6) frames.
>> (XEN) [2014-11-14 21:36:10.820] --MARK--
>> (XEN) [2014-11-14 21:36:20.820] --MARK--
>> (XEN) [2014-11-14 21:36:30.820] --MARK--
>> (XEN) [2014-11-14 21:36:40.821] --MARK--
>> (XEN) [2014-11-14 21:36:50.821] --MARK--
>> (XEN) [2014-11-14 21:37:00.388] CPU00:
>> (XEN) [2014-11-14 21:37:00.399] CPU01:
>> (XEN) [2014-11-14 21:37:00.410] d16 OK-softirq 20msec ago, state:1, 41220 count, [prev:ffff83054ef5e3e0, next:ffff83054ef5e3e0]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.445] d16 OK-raise   46msec ago, state:1, 41223 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.481] d16 ERR-poison 92msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.515] d16 Z-softirq  28853msec ago, state:2, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0

> The PIRQ:0 would imply that this is the legacy interrupt - which would be you 0a:00.0 device 
> (Conexant Systems, Inc. Device 8210).

Correct.

> And it is pounding on this CPU - and the issue is that the 'test_and_clear_bit' ends
> up returning 0 - which means it was not able to set STATE_SCHED:
> (!?)
>     if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               
>         {                                                                       
>             hvm_dirq_assist(d, pirq_dpci);                                      
>             put_domain(d);                                                      
>         }                                                                       
>         else                                                                    
>         {                                                                       
>             _record(&debug->zombie_softirq, pirq_dpci);        

> which causes us to record it [Z-softirq],  which says we we are in state 2
> (1<<STATE_RUN).

>             reset = 1;                                                          
>         }                                        

> .. eons ago (28853msec).

> Hmm. There is something fishy there but the only theory I have is that
> we end up doing 'list_del' twice on different CPUs on the same structure.

The pounding would be correct .. since it's a videograbber ... wouldn't be 
fun not stretching the limits ;-) (however it's running fine for about 2 or 3 years) 


> That should not be possible, but then this check - 'test_and_clear_bit' returned
> 0 which means that somebody had cleared it (or it failed to clear it?)

> But the only other path for 'clearing' it is via the error paths and you are
> not hitting any of them.

> In the mean-time, could you try this patch. It adds a bit more debug to help
> me figure this out.

Ok will do this evening, thx !

> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index 23e5ed1..443975c 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -126,17 +126,17 @@ static void dump_record(struct _debug_f *d, unsigned int type)
>          BUG();
>  
>      now = NOW();
> -    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
> +    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
>             d->domid, names[type],
>             (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->>state, d->count, d->list.prev, d->list.next);
+            d->>state, d->count, d->list.prev, d->list.next, d->dpci);
>  
>      if ( d->dpci )
>      {
>          struct hvm_pirq_dpci *pirq_dpci = d->dpci;
>  
>          for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
> -            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
> +            if ( pirq_dpci->flags & (1 << i) )
>                  printk("%s ", names_flag[i]);
>  
>          printk(" PIRQ:%d", pirq_dpci->pirq);

------------0FF0D423E2973E612
Content-Type: text/plain;
 name="proc-interrupts-dom0.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="proc-interrupts-dom0.txt"

ICAgICAgICAgICAgQ1BVMCAgICAgICBDUFUxICAgICAgIENQVTIgICAgICAgQ1BVMyAgICAg
ICBDUFU0ICAgICAgIENQVTUgICAgICAgCiAgIDE6ICAgICAgICAgIDIgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGlycS1p
b2FwaWMtZWRnZSAgaTgwNDIKICAgODogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLWlvYXBpYy1l
ZGdlICBydGMwCiAgMTI6ICAgICAgICAgIDQgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGlycS1pb2FwaWMtZWRnZSAgaTgw
NDIKICAxNjogICAgICAgIDgyNiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLWlvYXBpYy1sZXZlbCAgc25kX2hkYV9p
bnRlbAogIDE3OiAgICAgICAgICA0ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBpcnEtaW9hcGljLWxldmVsICBlaGNpX2hj
ZDp1c2IxLCBlaGNpX2hjZDp1c2IyLCBlaGNpX2hjZDp1c2IzCiAgMTg6ICAgICA2OTQyMzEg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICB4ZW4tcGlycS1pb2FwaWMtbGV2ZWwgIG9oY2lfaGNkOnVzYjQsIG9oY2lfaGNkOnVzYjUs
IG9oY2lfaGNkOnVzYjYsIG9oY2lfaGNkOnVzYjcKICAyMjogICAgICAzODk1OSAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1w
aXJxLWlvYXBpYy1sZXZlbCAgeGVuLXBjaWJhY2tbMDAwMDowMzowNi4wXQogIDU2OiAgIDEy
MTc3NDQxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgeGVuLXBlcmNwdS12aXJxICAgICAgdGltZXIwCiAgNTc6ICAgICAgICAyNjcg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9jazAKICA1ODogICAgNDY1NDI3NSAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhl
bi1wZXJjcHUtaXBpICAgICAgIHJlc2NoZWQwCiAgNTk6ICAgICAgMjM4MDggICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVy
Y3B1LWlwaSAgICAgICBjYWxsZnVuYzAKICA2MDogICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUt
dmlycSAgICAgIGRlYnVnMAogIDYxOiAgICAgIDgyMzQxICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkgICAg
ICAgY2FsbGZ1bmNzaW5nbGUwCiAgNjI6ICAgICAgICAgIDkgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAg
ICAgICBpcnF3b3JrMAogIDYzOiAgICAgICAgICAwICAgMTQxNTQyNTUgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS12aXJxICAgICAg
dGltZXIxCiAgNjQ6ICAgICAgICAgIDAgICAgICAgIDEzMSAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9j
azEKICA2NTogICAgICAgICAgMCAgIDE1MDIxMTMyICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBpICAgICAgIHJlc2NoZWQxCiAg
NjY6ICAgICAgICAgIDAgICAgICAyNjUxMiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBjYWxsZnVuYzEKICA2Nzog
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgIHhlbi1wZXJjcHUtdmlycSAgICAgIGRlYnVnMQogIDY4OiAgICAgICAg
ICAwICAgICAgODk0MTIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgeGVuLXBlcmNwdS1pcGkgICAgICAgY2FsbGZ1bmNzaW5nbGUxCiAgNjk6ICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBpcnF3b3JrMQogIDcwOiAgICAgICAgICAw
ICAgICAgICAgIDAgICAyMDE4NzY5NSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgeGVuLXBlcmNwdS12aXJxICAgICAgdGltZXIyCiAgNzE6ICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgMTM3ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4t
cGVyY3B1LWlwaSAgICAgICBzcGlubG9jazIKICA3MjogICAgICAgICAgMCAgICAgICAgICAw
ICAgMTM0MjQ3MTEgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJj
cHUtaXBpICAgICAgIHJlc2NoZWQyCiAgNzM6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
IDI1MTg2ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlw
aSAgICAgICBjYWxsZnVuYzIKICA3NDogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtdmlycSAg
ICAgIGRlYnVnMgogIDc1OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICA5NTQyNiAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkgICAgICAgY2Fs
bGZ1bmNzaW5nbGUyCiAgNzY6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICA0ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBp
cnF3b3JrMgogIDc3OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIDIyMDI5
ODUxICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS12aXJxICAgICAgdGltZXIz
CiAgNzg6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAxMzQgICAg
ICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9jazMKICA3
OTogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAxMjY5ODAwNiAgICAgICAg
ICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBpICAgICAgIHJlc2NoZWQzCiAgODA6ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgMjgzNzIgICAgICAgICAgMCAg
ICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBjYWxsZnVuYzMKICA4MTogICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgIHhlbi1wZXJjcHUtdmlycSAgICAgIGRlYnVnMwogIDgyOiAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgMTAwMTg1ICAgICAgICAgIDAgICAgICAgICAgMCAg
eGVuLXBlcmNwdS1pcGkgICAgICAgY2FsbGZ1bmNzaW5nbGUzCiAgODM6ICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDUgICAgICAgICAgMCAgICAgICAgICAw
ICB4ZW4tcGVyY3B1LWlwaSAgICAgICBpcnF3b3JrMwogIDg0OiAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgMjI0NzMzNjggICAgICAgICAgMCAgeGVu
LXBlcmNwdS12aXJxICAgICAgdGltZXI0CiAgODU6ICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgIDEzNSAgICAgICAgICAwICB4ZW4tcGVyY3B1
LWlwaSAgICAgICBzcGlubG9jazQKICA4NjogICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgIDEyMjA0NzkzICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBp
ICAgICAgIHJlc2NoZWQ0CiAgODc6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAyODA1NyAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAg
ICBjYWxsZnVuYzQKICA4ODogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtdmlycSAgICAgIGRl
YnVnNAogIDg5OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAxMDA0NjMgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkgICAgICAgY2FsbGZ1bmNz
aW5nbGU0CiAgOTA6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMyAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBpcnF3b3Jr
NAogIDkxOiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAyMjcxMjk0NCAgeGVuLXBlcmNwdS12aXJxICAgICAgdGltZXI1CiAgOTI6
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgMTIwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9jazUKICA5MzogICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
MTE1OTA5ODkgIHhlbi1wZXJjcHUtaXBpICAgICAgIHJlc2NoZWQ1CiAgOTQ6ICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgIDI4
MDYxICB4ZW4tcGVyY3B1LWlwaSAgICAgICBjYWxsZnVuYzUKICA5NTogICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
IHhlbi1wZXJjcHUtdmlycSAgICAgIGRlYnVnNQogIDk2OiAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICA5ODU2NCAgeGVuLXBl
cmNwdS1pcGkgICAgICAgY2FsbGZ1bmNzaW5nbGU1CiAgOTc6ICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAxICB4ZW4t
cGVyY3B1LWlwaSAgICAgICBpcnF3b3JrNQogIDk4OiAgICAgIDEyNTUyICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4t
ZXZlbnQgICAgIHhlbmJ1cwogIDk5OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS12aXJxICAg
ICAgeGVuLXBjcHUKIDExNDogICAgMjk0MTgwMyAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLW1zaSAgICAgICBhaGNp
MAogMTE1OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBpcnEtbXNpICAgICAgIGFoY2kxCiAxMTY6ICAg
ICAyMDMwMjYgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICB4ZW4tcGlycS1tc2kgICAgICAgYWhjaTIKIDExNzogICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
IHhlbi1waXJxLW1zaSAgICAgICBhaGNpMwogMTE4OiAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBpcnEt
bXNpICAgICAgIGFoY2k0CiAxMTk6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGlycS1tc2kgICAgICAg
YWhjaTUKIDEyMjogICAyMTE4Njk0NyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLW1zaSAgICAgICBldGgwCiAxMjM6
ICAgIDU0MTM2NTIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICB4ZW4tcGlycS1tc2kgICAgICAgZXRoMQogMTI0OiAgICAgICAgIDI4
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgeGVuLXBpcnEtbXNpICAgICAgIHNuZF9oZGFfaW50ZWwKIDEyNTogICAgICAgODY3OCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46b3hlbnN0b3JlZAogMTI2OiAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAxMjc6ICAgICAgICAz
MjggICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDEyODogICAgICAg
IDQ5MSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46eGVuY29uc29sZWQKIDEyOTogICAg
ICA0NjcwOSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBibGtpZi1iYWNrZW5kCiAxMzA6ICAgICA2
OTc3NzMgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMTMxOiAgICAgNjA1
MjczICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjEuMC1xMC10eAogMTMyOiAgICAgICAgICA2
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjEuMC1xMC1yeAogMTMzOiAgICAgNDc1ODU2ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
IHhlbi1keW4tZXZlbnQgICAgIHZpZjEuMC1xMS10eAogMTM0OiAgICAgICAgICAyICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhl
bi1keW4tZXZlbnQgICAgIHZpZjEuMC1xMS1yeAogMTM1OiAgICAgICAgMjE0ICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1k
eW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAxMzY6ICAgICAgICA0NzYgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVu
LWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAxMzc6ICAgICAxMDU5NzcgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
eGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMTM4OiAgIDEyNTIzMzU5ICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhl
bi1keW4tZXZlbnQgICAgIHZpZjIuMC1xMC10eAogMTM5OiAgICAgMTA2MzAxICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1k
eW4tZXZlbnQgICAgIHZpZjIuMC1xMC1yeAogMTQwOiAgICAgICAgMjQzICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4t
ZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAxNDE6ICAgICAgICA0ODUgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5
bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAxNDI6ICAgICAgMzA3NzAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVu
LWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMTQzOiAgICAxMjM4ODUxICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1k
eW4tZXZlbnQgICAgIHZpZjMuMC1xMC10eAogMTQ0OiAgICAgICAyNjMyICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4t
ZXZlbnQgICAgIHZpZjMuMC1xMC1yeAogMTQ1OiAgICAgMTQwMzAyICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZl
bnQgICAgIHZpZjMuMC1xMS10eAogMTQ2OiAgICAgICAgIDQyICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQg
ICAgIHZpZjMuMC1xMS1yeAogMTQ3OiAgICAgICAgMjE0ICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAg
IGV2dGNobjpveGVuc3RvcmVkCiAxNDg6ICAgICAgICA1MDIgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAg
ICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAxNDk6ICAgICAgNTMxNzggICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVu
dCAgICAgYmxraWYtYmFja2VuZAogMTUwOiAgICAxMDc1Mjg5ICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQg
ICAgIHZpZjQuMC1xMC10eAogMTUxOiAgICAgICAxMDMyICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAg
IHZpZjQuMC1xMC1yeAogMTUyOiAgICAgICAgMjE0ICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2
dGNobjpveGVuc3RvcmVkCiAxNTM6ICAgICAgICA1MzAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAg
ZXZ0Y2huOnhlbmNvbnNvbGVkCiAxNTQ6ICAgICAgNTExMTUgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAg
ICAgYmxraWYtYmFja2VuZAogMTU1OiAgICAxMjA1Mzc4ICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAg
IHZpZjUuMC1xMC10eAogMTU2OiAgICAgICA1MDkwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZp
ZjUuMC1xMC1yeAogMTU3OiAgICAgICAgMjE5ICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNo
bjpveGVuc3RvcmVkCiAxNTg6ICAgICAgICA0ODkgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0
Y2huOnhlbmNvbnNvbGVkCiAxNTk6ICAgICAgMTA2NDIgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAg
YmxraWYtYmFja2VuZAogMTYwOiAgICAgIDE5MDM1ICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZp
ZjYuMC1xMC10eAogMTYxOiAgICAgICAgICAxICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjYu
MC1xMC1yeAogMTYyOiAgICAgICAgMjE4ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpv
eGVuc3RvcmVkCiAxNjM6ICAgICAgICA1MzggICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2hu
OnhlbmNvbnNvbGVkCiAxNjQ6ICAgICAgMTExNTcgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxr
aWYtYmFja2VuZAogMTY1OiAgICAgIDMxODUyICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjcu
MC1xMC10eAogMTY2OiAgICAgICAgICAxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjcuMC1x
MC1yeAogMTY3OiAgICAgICAgMjE5ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVu
c3RvcmVkCiAxNjg6ICAgICAgICA0OTAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhl
bmNvbnNvbGVkCiAxNjk6ICAgICAgMTUwOTYgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYt
YmFja2VuZAogMTcwOiAgICAgICAzOTE4ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjguMC1x
MC10eAogMTcxOiAgICAgICAgICAxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjguMC1xMC1y
eAogMTcyOiAgICAgICAgMjQzICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3Rv
cmVkCiAxNzM6ICAgICAgICA1NDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNv
bnNvbGVkCiAxNzQ6ICAgICAgMjQwOTQgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFj
a2VuZAogMTc1OiAgICA2Nzg0ODcxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjkuMC1xMC10
eAogMTc2OiAgICAgIDExMzI4ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjkuMC1xMC1yeAog
MTc3OiAgICA2Mjg0MTcwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjkuMC1xMS10eAogMTc4
OiAgICAgICAxNTEzICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjkuMC1xMS1yeAogMTc5OiAg
ICAgICAgMjE2ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAxODA6
ICAgICAgICA1NTUgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAx
ODE6ICAgICAgMTM1ODYgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMTgy
OiAgICAgICAxNDk1ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjEwLjAtcTAtdHgKIDE4Mzog
ICAgICAgICAgMiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxMC4wLXEwLXJ4CiAxODQ6ICAg
ICAgICAyNDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDE4NTog
ICAgICAgIDU1MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46eGVuY29uc29sZWQKIDE4
NjogICAgICAxNzE0OSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBibGtpZi1iYWNrZW5kCiAxODc6
ICAgIDEyMTQ3MTYgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTEuMC1xMC10eAogMTg4OiAg
ICAgICAgMTc1ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjExLjAtcTAtcngKIDE4OTogICAg
MTExNTMwOSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxMS4wLXExLXR4CiAxOTA6ICAgICAg
ICAgIDcgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTEuMC1xMS1yeAogMTkxOiAgICAgICAg
MjEwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAxOTI6ICAgICAg
ICA1MjkgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAxOTM6ICAg
ICAgMTA0MjIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMTk0OiAgICAg
IDU3OTE4ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjEyLjAtcTAtdHgKIDE5NTogICAgICAg
ICAgMiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxMi4wLXEwLXJ4CiAxOTY6ICAgICAgICAy
NzEgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDE5NzogICAgICAg
IDY0MSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46eGVuY29uc29sZWQKIDE5ODogICAg
ICAgIDM3NSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB4ZW4tcGNpYmFjawogMTk5OiAgICAgIDEw
NjkwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGJsa2lmLWJhY2tlbmQKIDIwMDogICAgICA3MjYy
NyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxMy4wLXEwLXR4CiAyMDE6ICAgICAgICAgODMg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTMuMC1xMC1yeAogMjAyOiAgICAgICAgMjE4ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
IHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAyMDM6ICAgICAgICA1OTcg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAyMDQ6ICAgICAgMTky
MjAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgeGVuLWR5bi1ldmVudCAgICAgYmxraWYtYmFja2VuZAogMjA1OiAgICAgODIyODA3
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjE0LjAtcTAtdHgKIDIwNjogICAgICAgICAgMiAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxNC4wLXEwLXJ4CiAyMDc6ICAgICAgICAyMTUgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
eGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDIwODogICAgICAgIDUzNyAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46eGVuY29uc29sZWQKIDIwOTogICAgICAxOTg3
MiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICB4ZW4tZHluLWV2ZW50ICAgICBibGtpZi1iYWNrZW5kCiAyMTA6ICAgICAgICA1MTYg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTUuMC1xMC10eAogMjExOiAgICAgICAgICAxICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
IHhlbi1keW4tZXZlbnQgICAgIHZpZjE1LjAtcTAtcngKIDIxMjogICAgICAgIDUzNyAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4
ZW4tZHluLWV2ZW50ICAgICBldnRjaG46b3hlbnN0b3JlZAogMjEzOiAgICAgICAgICA1ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
IHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjp4ZW5jb25zb2xlZAogMjE0OiAgICAgMzMwNzM4
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpxZW11LXN5c3RlbS1pMzgKIDIxNTogICAg
MjIzNDUwMyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46cWVtdS1zeXN0ZW0taTM4CiAy
MTY6ICAgICAgMjM4MDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnFlbXUtc3lzdGVt
LWkzOAogMjE3OiAgICAgIDIzMjExICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpxZW11
LXN5c3RlbS1pMzgKIDIxODogICAgICAgIDEyMyAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRj
aG46cWVtdS1zeXN0ZW0taTM4CiAyMTk6ICAgICAgICAzNzkgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAg
ICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDIyMDogICAgICAgICAgMSAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50
ICAgICBldnRjaG46eGVuY29uc29sZWQKIDIyMTogICAgIDQwOTM0MSAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2
ZW50ICAgICBldnRjaG46cWVtdS1zeXN0ZW0taTM4CiAyMjI6ICAgICAgIDM3NzQgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVu
LWR5bi1ldmVudCAgICAgZXZ0Y2huOnFlbXUtc3lzdGVtLWkzOAogMjIzOiAgICAgICAxMTM2
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpxZW11LXN5c3RlbS1pMzgKIDIyNDogICAg
ICAgICAzMiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
ICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46cWVtdS1zeXN0ZW0taTM4CiAy
MjU6ICAgICAgICA0MjIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOm94ZW5zdG9yZWQK
IDIyNjogICAgICAgICAgOSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46eGVuY29uc29s
ZWQKIDIyNzogICAgIDM2MDUxOCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRjaG46cWVtdS1z
eXN0ZW0taTM4CiAyMjg6ICAgICAgIDIzMTQgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2hu
OnFlbXUtc3lzdGVtLWkzOAogMjI5OiAgICAgICAgODk4ICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAg
IGV2dGNobjpxZW11LXN5c3RlbS1pMzgKIDIzMDogICAgICAgMTYyMCAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2
ZW50ICAgICBldnRjaG46cWVtdS1zeXN0ZW0taTM4CiAyMzE6ICAgICAgICAgOTcgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVu
LWR5bi1ldmVudCAgICAgZXZ0Y2huOnFlbXUtc3lzdGVtLWkzOAogMjMyOiAgICAgIDk0NTg5
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIGJsa2lmLWJhY2tlbmQKIDIzMzogICAgICAzNjgwNCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICB4ZW4tZHluLWV2ZW50ICAgICBibGtpZi1iYWNrZW5kCiAyMzQ6ICAgICAxODgzODggICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
eGVuLWR5bi1ldmVudCAgICAgdmlmMTYuMC1xMC10eAogMjM1OiAgICAgICAgICAxICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhl
bi1keW4tZXZlbnQgICAgIHZpZjE2LjAtcTAtcngKIDIzNjogICAgICA1MzgxMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4t
ZHluLWV2ZW50ICAgICB2aWYxNi4wLXExLXR4CiAyMzc6ICAgICAgICAgIDEgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5
bi1ldmVudCAgICAgdmlmMTYuMC1xMS1yeAogMjM4OiAgICAgIDQ4MDgzICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4t
ZXZlbnQgICAgIHZpZjE2LjAtcTItdHgKIDIzOTogICAgICAgICAgMSAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2
ZW50ICAgICB2aWYxNi4wLXEyLXJ4CiAyNDA6ICAgICAgOTU2OTUgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVu
dCAgICAgdmlmMTYuMC1xMy10eAogMjQxOiAgICAgICAgICAyICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQg
ICAgIHZpZjE2LjAtcTMtcngKIDI0MjogICAgICAxMjUwOCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAg
ICBibGtpZi1iYWNrZW5kCiAyNDM6ICAgICAgNTYxNzQgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAg
dmlmMTcuMC1xMAogMjQ0OiAgICAgIDE1NDM3ICAgICAgICAgIDAgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGJsa2lm
LWJhY2tlbmQKIDI0NTogICAgICAgICA0NiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxOC4w
LXEwLXR4CiAyNDY6ICAgICAgICAgIDEgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTguMC1x
MC1yeAogMjQ3OiAgICAgICAgIDI3ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjE4LjAtcTEt
dHgKIDI0ODogICAgICAgICAgMSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxOC4wLXExLXJ4
CiAyNDk6ICAgICAgICAgIDggICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTguMC1xMi10eAog
MjUwOiAgICAgICAgICAxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIHZpZjE4LjAtcTItcngKIDI1
MTogICAgICAgICAgOCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxOC4wLXEzLXR4CiAyNTI6
ICAgICAgICAgIDEgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgdmlmMTguMC1xMy1yeAogMjUzOiAg
ICAgICAgMzUyICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpveGVuc3RvcmVkCiAyNTQ6
ICAgICAgICAgIDEgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnhlbmNvbnNvbGVkCiAy
NTU6ICAgICAxNTkwNDIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXZ0Y2huOnFlbXUtc3lzdGVt
LWkzOAogMjU2OiAgICAgIDM2MTAxICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV2dGNobjpxZW11
LXN5c3RlbS1pMzgKIDI1NzogICAgICAgIDIwOSAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldnRj
aG46cWVtdS1zeXN0ZW0taTM4CiAyNTg6ICAgICAgICAzNTUgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAg
ICAgZXZ0Y2huOm94ZW5zdG9yZWQKIDI1OTogICAgICAgICAgNiAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50
ICAgICBldnRjaG46eGVuY29uc29sZWQKIDI2MDogICAgIDIxMTE4NSAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2
ZW50ICAgICBldnRjaG46cWVtdS1zeXN0ZW0taTM4CiAyNjE6ICAgICAgICAxMzIgICAgICAg
ICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVu
LWR5bi1ldmVudCAgICAgZXZ0Y2huOnFlbXUtc3lzdGVtLWkzOAogMjYyOiAgICAgIDQ1Nzg0
ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgIHhlbi1keW4tZXZlbnQgICAgIGJsa2lmLWJhY2tlbmQKIDI2MzogICAgICAgICAgNSAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICB4ZW4tZHluLWV2ZW50ICAgICB2aWYxOS4wLXEwLXR4CiAyNjQ6ICAgICAgICAgIDEgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
eGVuLWR5bi1ldmVudCAgICAgdmlmMTkuMC1xMC1yeAogMjY1OiAgICAgIDI1MTQwICAgICAg
ICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhl
bi1keW4tZXZlbnQgICAgIGJsa2lmLWJhY2tlbmQKIDI2NjogICAgIDEwMDU5NSAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4t
ZHluLWV2ZW50ICAgICB2aWYyMC4wLXEwCiBOTUk6ICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgTm9uLW1hc2th
YmxlIGludGVycnVwdHMKIExPQzogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBMb2NhbCB0aW1lciBpbnRlcnJ1
cHRzCiBTUFU6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgU3B1cmlvdXMgaW50ZXJydXB0cwogUE1JOiAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAg
ICAgICAgMCAgIFBlcmZvcm1hbmNlIG1vbml0b3JpbmcgaW50ZXJydXB0cwogSVdJOiAgICAg
ICAgICA5ICAgICAgICAgIDAgICAgICAgICAgNCAgICAgICAgICA1ICAgICAgICAgIDMgICAg
ICAgICAgMSAgIElSUSB3b3JrIGludGVycnVwdHMKIFJUUjogICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBBUElD
IElDUiByZWFkIHJldHJpZXMKIFJFUzogICAgNDY1NDI3NSAgIDE1MDIxMTMyICAgMTM0MjQ3
MTEgICAxMjY5ODAwNiAgIDEyMjA0NzkzICAgMTE1OTA5ODkgICBSZXNjaGVkdWxpbmcgaW50
ZXJydXB0cwogQ0FMOiAgICAgMTA2MTQ5ICAgICAxMTU5MjQgICAgIDEyMDYxMiAgICAgMTI4
NTU3ICAgICAxMjg1MjAgICAgIDEyNjYyNSAgIEZ1bmN0aW9uIGNhbGwgaW50ZXJydXB0cwog
VExCOiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgIFRMQiBzaG9vdGRvd25zCiBUUk06ICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
VGhlcm1hbCBldmVudCBpbnRlcnJ1cHRzCiBUSFI6ICAgICAgICAgIDAgICAgICAgICAgMCAg
ICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgVGhyZXNob2xk
IEFQSUMgaW50ZXJydXB0cwogTUNFOiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIE1hY2hpbmUgY2hlY2sgZXhj
ZXB0aW9ucwogTUNQOiAgICAgICAgMzEwICAgICAgICAzMTAgICAgICAgIDMxMCAgICAgICAg
MzEwICAgICAgICAzMTAgICAgICAgIDMxMCAgIE1hY2hpbmUgY2hlY2sgcG9sbHMKIFRIUjog
ICA4NDQ5ODQwMyAgIDI4OTMyMzAzICAgMzMzNzMwMTUgICAzNDUxNzUxMCAgIDM0NDgwNDc2
ICAgMzQxMTMyNzcgICBIeXBlcnZpc29yIGNhbGxiYWNrIGludGVycnVwdHMKIEVSUjogICAg
ICAgICAgMAogTUlTOiAgICAgICAgICAwCg==
------------0FF0D423E2973E612
Content-Type: text/plain;
 name="proc-interrupts-guest.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="proc-interrupts-guest.txt"

ICAgICAgICAgICBDUFUwICAgICAgIENQVTEgICAgICAgQ1BVMiAgICAgICBDUFUzICAgICAg
IAogIDA6ICAgICAgICAxMzYgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBJ
Ty1BUElDLWVkZ2UgICAgICB0aW1lcgogIDE6ICAgICAgICAgIDkgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLWlvYXBpYy1lZGdlICBpODA0MgogIDQ6ICAg
ICAgICA1MzggICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLWlv
YXBpYy1lZGdlICBzZXJpYWwKICA4OiAgICAgICAgICAyICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICB4ZW4tcGlycS1pb2FwaWMtZWRnZSAgcnRjMAogIDk6ICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBJTy1BUElDLWZhc3Rlb2kg
ICBhY3BpCiAxMjogICAgICAgIDEyNSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgeGVuLXBpcnEtaW9hcGljLWVkZ2UgIGk4MDQyCiAyMzogICAgICAgICAzNSAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBpcnEtaW9hcGljLWxldmVsICB1aGNp
X2hjZDp1c2IzCiA0MDogICAxMzQ0MDA3NyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgeGVuLXBpcnEtaW9hcGljLWxldmVsICBjeDI1ODIxWzFdLCBjeDI1ODIxWzFdCiA0
ODogICAxMzk3MzAzMyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgeGVuLXBl
cmNwdS12aXJxICAgICAgdGltZXIwCiA0OTogICAgIDc4MjgyNyAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkgICAgICAgcmVzY2hlZDAKIDUwOiAg
ICAxODI1NTgyICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1
LWlwaSAgICAgICBjYWxsZnVuYzAKIDUxOiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LXZpcnEgICAgICBkZWJ1ZzAKIDUyOiAgICAg
Njk1NTQ4ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlw
aSAgICAgICBjYWxsZnVuY3NpbmdsZTAKIDUzOiAgICAgICA2MDMyICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9jazAKIDU0
OiAgICAgICAgICAwICAgIDkyNTIzOTEgICAgICAgICAgMCAgICAgICAgICAwICB4ZW4tcGVy
Y3B1LXZpcnEgICAgICB0aW1lcjEKIDU1OiAgICAgICAgICAwICAgIDM2NjUwMzUgICAgICAg
ICAgMCAgICAgICAgICAwICB4ZW4tcGVyY3B1LWlwaSAgICAgICByZXNjaGVkMQogNTY6ICAg
ICAgICAgIDAgICAgMTg0MjM2NCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUt
aXBpICAgICAgIGNhbGxmdW5jMQogNTc6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAg
ICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtdmlycSAgICAgIGRlYnVnMQogNTg6ICAgICAg
ICAgIDAgICAgIDYzMTI5OSAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBp
ICAgICAgIGNhbGxmdW5jc2luZ2xlMQogNTk6ICAgICAgICAgIDAgICAgICAgODU4NyAgICAg
ICAgICAwICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBpICAgICAgIHNwaW5sb2NrMQogNjA6
ICAgICAgICAgIDAgICAgICAgICAgMCAgICA4MjM5MDk2ICAgICAgICAgIDAgIHhlbi1wZXJj
cHUtdmlycSAgICAgIHRpbWVyMgogNjE6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAyNTM3
Njc5ICAgICAgICAgIDAgIHhlbi1wZXJjcHUtaXBpICAgICAgIHJlc2NoZWQyCiA2MjogICAg
ICAgICAgMCAgICAgICAgICAwICAgIDE4NzcwNTAgICAgICAgICAgMCAgeGVuLXBlcmNwdS1p
cGkgICAgICAgY2FsbGZ1bmMyCiA2MzogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgeGVuLXBlcmNwdS12aXJxICAgICAgZGVidWcyCiA2NDogICAgICAg
ICAgMCAgICAgICAgICAwICAgICA1NDU0MDcgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkg
ICAgICAgY2FsbGZ1bmNzaW5nbGUyCiA2NTogICAgICAgICAgMCAgICAgICAgICAwICAgICAg
IDc5NzQgICAgICAgICAgMCAgeGVuLXBlcmNwdS1pcGkgICAgICAgc3BpbmxvY2syCiA2Njog
ICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgODA4MzUwMCAgeGVuLXBlcmNw
dS12aXJxICAgICAgdGltZXIzCiA2NzogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgMjAwNDI1NyAgeGVuLXBlcmNwdS1pcGkgICAgICAgcmVzY2hlZDMKIDY4OiAgICAg
ICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAxOTE3NTk2ICB4ZW4tcGVyY3B1LWlw
aSAgICAgICBjYWxsZnVuYzMKIDY5OiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAg
MCAgICAgICAgICAwICB4ZW4tcGVyY3B1LXZpcnEgICAgICBkZWJ1ZzMKIDcwOiAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgNTc4MTc0ICB4ZW4tcGVyY3B1LWlwaSAg
ICAgICBjYWxsZnVuY3NpbmdsZTMKIDcxOiAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgICAgICA3NDYzICB4ZW4tcGVyY3B1LWlwaSAgICAgICBzcGlubG9jazMKIDcyOiAg
ICAgICAgNTExICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1l
dmVudCAgICAgeGVuYnVzCiA3MzogICAgICAgICAgMiAgICAgICAgICAwICAgICAgICAgIDAg
ICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGh2Y19jb25zb2xlCiA3NDogICAgIDEw
MTg2OSAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQg
ICAgIGJsa2lmCiA3NTogICAgICA2MjAwMyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGJsa2lmCiA3NjogICAgIDE5MTQxNiAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV0aDAtcTAt
dHgKIDc3OiAgICAgMTM4MjM5ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAg
eGVuLWR5bi1ldmVudCAgICAgZXRoMC1xMC1yeAogNzg6ICAgICAgNTgzNjEgICAgICAgICAg
MCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICBldGgwLXExLXR4
CiA3OTogICAgIDEzMTEyNyAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIHhl
bi1keW4tZXZlbnQgICAgIGV0aDAtcTEtcngKIDgwOiAgICAgIDUwOTMzICAgICAgICAgIDAg
ICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5bi1ldmVudCAgICAgZXRoMC1xMi10eAog
ODE6ICAgICAgNDM5NDIgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4t
ZHluLWV2ZW50ICAgICBldGgwLXEyLXJ4CiA4MjogICAgICA5NDE5NyAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgIHhlbi1keW4tZXZlbnQgICAgIGV0aDAtcTMtdHgKIDgz
OiAgICAgMTAxNjkyICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgeGVuLWR5
bi1ldmVudCAgICAgZXRoMC1xMy1yeAogODQ6ICAgIDI5NTYzNjkgICAgICAgICAgMCAgICAg
ICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLW1zaS14ICAgICB4aGNpX2hjZAogODU6ICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLW1z
aS14ICAgICB4aGNpX2hjZAogODY6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAw
ICAgICAgICAgIDAgIHhlbi1waXJxLW1zaS14ICAgICB4aGNpX2hjZAogODc6ICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgIHhlbi1waXJxLW1zaS14ICAg
ICB4aGNpX2hjZAogODg6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgIHhlbi1waXJxLW1zaS14ICAgICB4aGNpX2hjZAogODk6ICAgICAgICAgIDAgICAg
ICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICB4ZW4tZHluLWV2ZW50ICAgICB2a2Jk
Ck5NSTogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAgICAgMCAgIE5v
bi1tYXNrYWJsZSBpbnRlcnJ1cHRzCkxPQzogICAgICAgICAgMCAgICAgICAgICAwICAgICAg
ICAgIDAgICAgICAgICAgMCAgIExvY2FsIHRpbWVyIGludGVycnVwdHMKU1BVOiAgICAgICAg
ICAwICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgU3B1cmlvdXMgaW50ZXJy
dXB0cwpQTUk6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAg
ICBQZXJmb3JtYW5jZSBtb25pdG9yaW5nIGludGVycnVwdHMKSVdJOiAgICAgICAgICAwICAg
ICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgSVJRIHdvcmsgaW50ZXJydXB0cwpS
VFI6ICAgICAgICAgIDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBBUElD
IElDUiByZWFkIHJldHJpZXMKUkVTOiAgICAgNzgyODI3ICAgIDM2NjUwMzUgICAgMjUzNzY3
OSAgICAyMDA0MjU3ICAgUmVzY2hlZHVsaW5nIGludGVycnVwdHMKQ0FMOiA0Mjk0ODU2NTI0
IDQyOTQ5MTE0NDQgNDI5NDk2MjUzNCA0Mjk0OTUzMzUyICAgRnVuY3Rpb24gY2FsbCBpbnRl
cnJ1cHRzClRMQjogICAgMjYzMTkwMiAgICAyNTI5NTE1ICAgIDI0MjcyMTkgICAgMjUwOTcx
NCAgIFRMQiBzaG9vdGRvd25zClRSTTogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAg
IDAgICAgICAgICAgMCAgIFRoZXJtYWwgZXZlbnQgaW50ZXJydXB0cwpUSFI6ICAgICAgICAg
IDAgICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICBUaHJlc2hvbGQgQVBJQyBp
bnRlcnJ1cHRzCk1DRTogICAgICAgICAgMCAgICAgICAgICAwICAgICAgICAgIDAgICAgICAg
ICAgMCAgIE1hY2hpbmUgY2hlY2sgZXhjZXB0aW9ucwpNQ1A6ICAgICAgICAzMDggICAgICAg
IDMwOCAgICAgICAgMzA4ICAgICAgICAzMDggICBNYWNoaW5lIGNoZWNrIHBvbGxzClRIUjog
ICAzMzk3ODA3MSAgIDE1Mjk2NDc1ICAgMTMxMzE2NDEgICAxMjUyNjExOSAgIEh5cGVydmlz
b3IgY2FsbGJhY2sgaW50ZXJydXB0cwpFUlI6ICAgICAgICAgIDAKTUlTOiAgICAgICAgICAw
Cg==
------------0FF0D423E2973E612
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0FF0D423E2973E612--



From xen-devel-bounces@lists.xen.org Mon Nov 17 17:05:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17:05:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPkP-0003Ia-L3; Mon, 17 Nov 2014 17:05:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XqPkO-0003IS-Qe
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:05:53 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	E4/28-26652-FEA2A645; Mon, 17 Nov 2014 17:05:51 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416243948!11830859!1
X-Originating-IP: [64.18.0.178]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12553 invoked from network); 17 Nov 2014 17:05:50 -0000
Received: from exprod5og104.obsmtp.com (HELO exprod5og104.obsmtp.com)
	(64.18.0.178)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 17:05:50 -0000
Received: from mail-la0-f54.google.com ([209.85.215.54]) (using TLSv1) by
	exprod5ob104.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGoq7GZRhDbRmG85GfR6ttk8+t/hhjXD@postini.com;
	Mon, 17 Nov 2014 09:05:50 PST
Received: by mail-la0-f54.google.com with SMTP id gf13so6815967lab.27
	for <xen-devel@lists.xen.org>; Mon, 17 Nov 2014 09:05:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=NI912C8KLytYyr+OEYNrQUJMp02IysM2oNS2b/O8Mog=;
	b=SIs/c3FQzYUIWHQri9BMpnb23IfPZSJ4KHwhG1FKsW+sOj3UvAJxiKDPL13avP6tMF
	/yUUWZ+IhTwraSoKS0BdH1uV+E0lWE27Zc2VJukSwlLRdDcxcNlZVwHTx+90gcqYessO
	NFDC/EUlxWXJdlYYqMZcl5AQFB2uQwXtgP064=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=NI912C8KLytYyr+OEYNrQUJMp02IysM2oNS2b/O8Mog=;
	b=bL3NCCXm2iMi7+/BkiVi9qG1ryGklMvMz+549+KvA4/Vxm845N8WEDZFOniU0z1KvF
	YgpiNSK1L0ABJ1e6NqkgWHhTCXN0XyxWA5drebRSwQV5qGMPJJhFRpl1LCHDRNwC5m45
	wh/eqnrGQKk4n5E7a8ZrNEh8OQ5oGJvr2AFkoOkx3wNTTn5OWJ2LzQQNdo9djijTfmuZ
	XeMHN9/t/nD52qkXt5jZ7IKweagvK703rpNEb733apDo/+HtxaN1Y52G0l6N5+BJb0o/
	mK+PWCkrnXzU/V6rzBIx+JRVkeEqAWdgEOrQu6oSTOESvPq8Pyh/q6BOs3CQJTBp8ApM
	rxZw==
X-Gm-Message-State: ALoCoQmjif1CabuPepIqhQW8buRSdjd+0SIWqayqGOOUnXv9o4jO+b5D9rh5G/m302hk524oWMFBolX+YyrbGw58Ikl31caPAWYRBAoR70IyCrw+dDhEkxVUWQPj6H5/nYZ2DURptWLKENI3LtpsnuxM+9uuP3eE4g==
X-Received: by 10.152.21.9 with SMTP id r9mr11859302lae.76.1416243947156;
	Mon, 17 Nov 2014 09:05:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.21.9 with SMTP id r9mr11859211lae.76.1416243946477; Mon,
	17 Nov 2014 09:05:46 -0800 (PST)
Received: by 10.112.61.69 with HTTP; Mon, 17 Nov 2014 09:05:46 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
Date: Mon, 17 Nov 2014 19:05:46 +0200
Message-ID: <CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

Thank you for your answer.

On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> Although it is possible that that patch is the cause of your problem,
> unfortunately it is part of a significant rework of the GIC driver in
> Xen and I am afraid that testing with only a portion of that patch
> series might introduce other subtle bugs.  For your reference the series
> starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
> commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
>

Yes, I tested with and without the whole series.

> If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
> problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
> might not work correctly on your platform. It wouldn't be the first time
> that we see hardware behaving that way, especially if you are using the
> GIC secure registers instead of the non-secure register as GICH_LRn.HW
> can only deactivate non-secure interrupts. This is usually due to a
> configuration error in u-boot.
>
> Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
> platform?
>

I tried this. Unfortunately it doesn't help.

Regards,
Andrii

>
>
> On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi,
>>
>> Issue occurs after the following commit:
>>
>> commit 5495a512b63bad868c147198f7f049c2617d468c
>> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Date:   Tue Jun 10 15:07:12 2014 +0100
>>
>>     xen/arm: support HW interrupts, do not request maintenance_interrupts
>>
>>     If the irq to be injected is an hardware irq (p->desc != NULL), set
>>     GICH_LR_HW. Do not set GICH_LR_MAINTENANCE_IRQ.
>>
>>
>> I'm going to debug it deeply.
>> Stefano - may be you have a feeling what it can be ?
>>
>> Regards,
>> Andrii
>>
>>
>> On Fri, Nov 14, 2014 at 6:40 PM, Andrii Tseglytskyi
>> <andrii.tseglytskyi@globallogic.com> wrote:
>> > Hi Julien,
>> >
>> >> I would be surprised that the next GIC series impact this code as the
>> >> next driver is only compiled for arm64 (GICv3 doesn't exist on arm32).
>> >> Though, there was some refactoring.
>> >
>> > I meant that code was divided for generic GIC and GICv2 together with
>> > refactoring. Also in mails I saw that it was initially tested without
>> > SMP.
>> > GICv3 has no impacts for sure.
>> >
>> >>
>> >> The interrupt management has also been reworked for Xen 4.5 to avoid
>> >> maintenance interrupt. I would give a look on this part.
>> >
>> > Thanks, this may help.
>> >
>> > Regards,
>> > Andrii
>> >
>> >
>> >>
>> >> Regards,
>> >>
>> >> --
>> >> Julien Grall
>> >
>> >
>> >
>> > --
>> >
>> > Andrii Tseglytskyi | Embedded Dev
>> > GlobalLogic
>> > www.globallogic.com
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 17:05:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17:05:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPkP-0003Ia-L3; Mon, 17 Nov 2014 17:05:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XqPkO-0003IS-Qe
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:05:53 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	E4/28-26652-FEA2A645; Mon, 17 Nov 2014 17:05:51 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416243948!11830859!1
X-Originating-IP: [64.18.0.178]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12553 invoked from network); 17 Nov 2014 17:05:50 -0000
Received: from exprod5og104.obsmtp.com (HELO exprod5og104.obsmtp.com)
	(64.18.0.178)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 17:05:50 -0000
Received: from mail-la0-f54.google.com ([209.85.215.54]) (using TLSv1) by
	exprod5ob104.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGoq7GZRhDbRmG85GfR6ttk8+t/hhjXD@postini.com;
	Mon, 17 Nov 2014 09:05:50 PST
Received: by mail-la0-f54.google.com with SMTP id gf13so6815967lab.27
	for <xen-devel@lists.xen.org>; Mon, 17 Nov 2014 09:05:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=NI912C8KLytYyr+OEYNrQUJMp02IysM2oNS2b/O8Mog=;
	b=SIs/c3FQzYUIWHQri9BMpnb23IfPZSJ4KHwhG1FKsW+sOj3UvAJxiKDPL13avP6tMF
	/yUUWZ+IhTwraSoKS0BdH1uV+E0lWE27Zc2VJukSwlLRdDcxcNlZVwHTx+90gcqYessO
	NFDC/EUlxWXJdlYYqMZcl5AQFB2uQwXtgP064=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=NI912C8KLytYyr+OEYNrQUJMp02IysM2oNS2b/O8Mog=;
	b=bL3NCCXm2iMi7+/BkiVi9qG1ryGklMvMz+549+KvA4/Vxm845N8WEDZFOniU0z1KvF
	YgpiNSK1L0ABJ1e6NqkgWHhTCXN0XyxWA5drebRSwQV5qGMPJJhFRpl1LCHDRNwC5m45
	wh/eqnrGQKk4n5E7a8ZrNEh8OQ5oGJvr2AFkoOkx3wNTTn5OWJ2LzQQNdo9djijTfmuZ
	XeMHN9/t/nD52qkXt5jZ7IKweagvK703rpNEb733apDo/+HtxaN1Y52G0l6N5+BJb0o/
	mK+PWCkrnXzU/V6rzBIx+JRVkeEqAWdgEOrQu6oSTOESvPq8Pyh/q6BOs3CQJTBp8ApM
	rxZw==
X-Gm-Message-State: ALoCoQmjif1CabuPepIqhQW8buRSdjd+0SIWqayqGOOUnXv9o4jO+b5D9rh5G/m302hk524oWMFBolX+YyrbGw58Ikl31caPAWYRBAoR70IyCrw+dDhEkxVUWQPj6H5/nYZ2DURptWLKENI3LtpsnuxM+9uuP3eE4g==
X-Received: by 10.152.21.9 with SMTP id r9mr11859302lae.76.1416243947156;
	Mon, 17 Nov 2014 09:05:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.21.9 with SMTP id r9mr11859211lae.76.1416243946477; Mon,
	17 Nov 2014 09:05:46 -0800 (PST)
Received: by 10.112.61.69 with HTTP; Mon, 17 Nov 2014 09:05:46 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
Date: Mon, 17 Nov 2014 19:05:46 +0200
Message-ID: <CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

Thank you for your answer.

On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> Although it is possible that that patch is the cause of your problem,
> unfortunately it is part of a significant rework of the GIC driver in
> Xen and I am afraid that testing with only a portion of that patch
> series might introduce other subtle bugs.  For your reference the series
> starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
> commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
>

Yes, I tested with and without the whole series.

> If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
> problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
> might not work correctly on your platform. It wouldn't be the first time
> that we see hardware behaving that way, especially if you are using the
> GIC secure registers instead of the non-secure register as GICH_LRn.HW
> can only deactivate non-secure interrupts. This is usually due to a
> configuration error in u-boot.
>
> Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
> platform?
>

I tried this. Unfortunately it doesn't help.

Regards,
Andrii

>
>
> On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi,
>>
>> Issue occurs after the following commit:
>>
>> commit 5495a512b63bad868c147198f7f049c2617d468c
>> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Date:   Tue Jun 10 15:07:12 2014 +0100
>>
>>     xen/arm: support HW interrupts, do not request maintenance_interrupts
>>
>>     If the irq to be injected is an hardware irq (p->desc != NULL), set
>>     GICH_LR_HW. Do not set GICH_LR_MAINTENANCE_IRQ.
>>
>>
>> I'm going to debug it deeply.
>> Stefano - may be you have a feeling what it can be ?
>>
>> Regards,
>> Andrii
>>
>>
>> On Fri, Nov 14, 2014 at 6:40 PM, Andrii Tseglytskyi
>> <andrii.tseglytskyi@globallogic.com> wrote:
>> > Hi Julien,
>> >
>> >> I would be surprised that the next GIC series impact this code as the
>> >> next driver is only compiled for arm64 (GICv3 doesn't exist on arm32).
>> >> Though, there was some refactoring.
>> >
>> > I meant that code was divided for generic GIC and GICv2 together with
>> > refactoring. Also in mails I saw that it was initially tested without
>> > SMP.
>> > GICv3 has no impacts for sure.
>> >
>> >>
>> >> The interrupt management has also been reworked for Xen 4.5 to avoid
>> >> maintenance interrupt. I would give a look on this part.
>> >
>> > Thanks, this may help.
>> >
>> > Regards,
>> > Andrii
>> >
>> >
>> >>
>> >> Regards,
>> >>
>> >> --
>> >> Julien Grall
>> >
>> >
>> >
>> > --
>> >
>> > Andrii Tseglytskyi | Embedded Dev
>> > GlobalLogic
>> > www.globallogic.com
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 17:06:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPkp-0003Lm-1p; Mon, 17 Nov 2014 17:06:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XqPkn-0003LT-Vv
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:06:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1F/0D-25276-90B2A645; Mon, 17 Nov 2014 17:06:17 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416243975!13377291!1
X-Originating-IP: [209.85.216.178]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23599 invoked from network); 17 Nov 2014 17:06:16 -0000
Received: from mail-qc0-f178.google.com (HELO mail-qc0-f178.google.com)
	(209.85.216.178)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 17:06:16 -0000
Received: by mail-qc0-f178.google.com with SMTP id b13so18045408qcw.37
	for <xen-devel@lists.xen.org>; Mon, 17 Nov 2014 09:06:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=9p1iojlCLySu7RvcEhkAS9qj0FPuSFOfXkePgCH6dYE=;
	b=frhlRYliB/coHaRS3BPIdUSlQT5+hhjEoqafXVa5PYv2FFsBW+fFdlNR541urmUUr/
	+7KEYBXqZS6eFTtqnqphroOmtpuEEh+1HRuGcad1mLr9cfoGU1gtyPvJbpNpZQTh1f0c
	i1Z7FTIVCD2yZVzfrXMAOVtHAQxzepaltyxXJJt2E2os+73N2W1XTuaQ4swLOwnr4LjW
	2lkvWC2tMAZ0XiJzOlXAcYL0tsOQHabiTJft/pA7m7tCZ9lqM0+1WTt/L2nPzCO30NXv
	1lh2RB4hibYzxEdHul/tPKGRIcR3QUmwRY+kKxYXIkV0+hQt/lMW+FMvAiVTPzYcQMBp
	3hVA==
X-Gm-Message-State: ALoCoQnYAJzxDTGrizMtQj+ho8NqzaFMrmik+GOrfe+Xfj00czQx0Zdfs+YPUDFpVtXGoh/gUDV1
MIME-Version: 1.0
X-Received: by 10.140.92.215 with SMTP id b81mr18543516qge.5.1416243975399;
	Mon, 17 Nov 2014 09:06:15 -0800 (PST)
Received: by 10.229.176.198 with HTTP; Mon, 17 Nov 2014 09:06:15 -0800 (PST)
In-Reply-To: <546A32720200007800048873@mail.emea.novell.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
	<546A32720200007800048873@mail.emea.novell.com>
Date: Mon, 17 Nov 2014 18:06:15 +0100
Message-ID: <CAErYnsgm5F3ThZe2w1Lq=az90ve_1pLhEb+Kpc2k9AfWOvB1FA@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Dong,
	Eddie" <eddie.dong@intel.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3485680186149111372=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3485680186149111372==
Content-Type: multipart/alternative; boundary=001a1139126c11bf69050810ff48

--001a1139126c11bf69050810ff48
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
> > On 12/11/14 15:31, Tamas K Lengyel wrote:
> >>  xen/include/public/domctl.h         |  44 +--
> >>  xen/include/public/hvm/params.h     |   2 +-
> >>  xen/include/public/mem_event.h      | 134 -------
> >>  xen/include/public/memory.h         |   6 +-
> >>  xen/include/public/vm_event.h       | 179 +++++++++
> >
> > While in principle I think this series is a very good thing, there is a
> > problem with editing the pubic header files.
> >
> > The contents of mem_event.h is not currently hidden behind #ifdef
> > __XEN_TOOLS__
> >
> > As a result, it is strictly speaking part of the VM-visible public
> > API/ABI and not permitted to change in a backwards incompatible manor.
> >
> > Having said that, it is currently only usable by privileged domains, so
> > there is an argument to be made for declaring that it should have been
> > hidden behind __XEN_TOOLS__ in the first place, making it permittable to
> > change.
>
> I'm not sure I agree - the meaning of "tools" here would seem quite a
> bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
> an old consumer (remember that for many of these we have at best
> fake consumers in the tree) would deal with the now differently
> arranged data. I don't see any versioning of the interface, and hence
> I can't see how tools would know which of the formats to expect.
>
> Jan
>

The lack of versioning is a real concern which I have aired during the 4.5
development process. For example, when we switched from HVMEM_access_* to
XENMEM_access_* a customer had to do a bunch of manual configure checks to
determine what is supported and what isn't. Furthermore, many of the
related APIs have changed quite radically between Xen 4.1-4.5, some being
abandoned midway just to resurface later in a different context. Going
forward having a clear VM_EVENT_VERSION definition would be very helpful
and would be the cleanest solution IMHO.

Tamas

--001a1139126c11bf69050810ff48
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt;&gt;=
&gt; On 12.11.14 at 16:48, &lt;<a href=3D"mailto:andrew.cooper3@citrix.com"=
>andrew.cooper3@citrix.com</a>&gt; wrote:<br>
&gt; On 12/11/14 15:31, Tamas K Lengyel wrote:<br>
</span><span class=3D"">&gt;&gt;=A0 xen/include/public/domctl.h=A0 =A0 =A0 =
=A0 =A0|=A0 44 +--<br>
&gt;&gt;=A0 xen/include/public/hvm/params.h=A0 =A0 =A0|=A0 =A02 +-<br>
&gt;&gt;=A0 xen/include/public/mem_event.h=A0 =A0 =A0 | 134 -------<br>
&gt;&gt;=A0 xen/include/public/memory.h=A0 =A0 =A0 =A0 =A0|=A0 =A06 +-<br>
&gt;&gt;=A0 xen/include/public/vm_event.h=A0 =A0 =A0 =A0| 179 +++++++++<br>
&gt;<br>
&gt; While in principle I think this series is a very good thing, there is =
a<br>
&gt; problem with editing the pubic header files.<br>
&gt;<br>
&gt; The contents of mem_event.h is not currently hidden behind #ifdef<br>
&gt; __XEN_TOOLS__<br>
&gt;<br>
&gt; As a result, it is strictly speaking part of the VM-visible public<br>
&gt; API/ABI and not permitted to change in a backwards incompatible manor.=
<br>
&gt;<br>
&gt; Having said that, it is currently only usable by privileged domains, s=
o<br>
&gt; there is an argument to be made for declaring that it should have been=
<br>
&gt; hidden behind __XEN_TOOLS__ in the first place, making it permittable =
to<br>
&gt; change.<br>
<br>
</span>I&#39;m not sure I agree - the meaning of &quot;tools&quot; here wou=
ld seem quite a<br>
bit different than e.g. in domctl.h. Looking at patch 1, I can&#39;t see ho=
w<br>
an old consumer (remember that for many of these we have at best<br>
fake consumers in the tree) would deal with the now differently<br>
arranged data. I don&#39;t see any versioning of the interface, and hence<b=
r>
I can&#39;t see how tools would know which of the formats to expect.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br></font></span></blockquote><div><br></div><div>The lack of versionin=
g is a real concern which I have aired during the 4.5 development process. =
For example, when we switched from HVMEM_access_* to XENMEM_access_* a cust=
omer had to do a bunch of manual configure checks to determine what is supp=
orted and what isn&#39;t. Furthermore, many of the related APIs have change=
d quite radically between Xen 4.1-4.5, some being abandoned midway just to =
resurface later in a different context. Going forward having a clear VM_EVE=
NT_VERSION definition would be very helpful and would be the cleanest solut=
ion IMHO.<br><br></div><div>Tamas<br></div></div><br></div></div>

--001a1139126c11bf69050810ff48--


--===============3485680186149111372==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3485680186149111372==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 17:06:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPkp-0003Lm-1p; Mon, 17 Nov 2014 17:06:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XqPkn-0003LT-Vv
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:06:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1F/0D-25276-90B2A645; Mon, 17 Nov 2014 17:06:17 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416243975!13377291!1
X-Originating-IP: [209.85.216.178]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23599 invoked from network); 17 Nov 2014 17:06:16 -0000
Received: from mail-qc0-f178.google.com (HELO mail-qc0-f178.google.com)
	(209.85.216.178)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 17:06:16 -0000
Received: by mail-qc0-f178.google.com with SMTP id b13so18045408qcw.37
	for <xen-devel@lists.xen.org>; Mon, 17 Nov 2014 09:06:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=9p1iojlCLySu7RvcEhkAS9qj0FPuSFOfXkePgCH6dYE=;
	b=frhlRYliB/coHaRS3BPIdUSlQT5+hhjEoqafXVa5PYv2FFsBW+fFdlNR541urmUUr/
	+7KEYBXqZS6eFTtqnqphroOmtpuEEh+1HRuGcad1mLr9cfoGU1gtyPvJbpNpZQTh1f0c
	i1Z7FTIVCD2yZVzfrXMAOVtHAQxzepaltyxXJJt2E2os+73N2W1XTuaQ4swLOwnr4LjW
	2lkvWC2tMAZ0XiJzOlXAcYL0tsOQHabiTJft/pA7m7tCZ9lqM0+1WTt/L2nPzCO30NXv
	1lh2RB4hibYzxEdHul/tPKGRIcR3QUmwRY+kKxYXIkV0+hQt/lMW+FMvAiVTPzYcQMBp
	3hVA==
X-Gm-Message-State: ALoCoQnYAJzxDTGrizMtQj+ho8NqzaFMrmik+GOrfe+Xfj00czQx0Zdfs+YPUDFpVtXGoh/gUDV1
MIME-Version: 1.0
X-Received: by 10.140.92.215 with SMTP id b81mr18543516qge.5.1416243975399;
	Mon, 17 Nov 2014 09:06:15 -0800 (PST)
Received: by 10.229.176.198 with HTTP; Mon, 17 Nov 2014 09:06:15 -0800 (PST)
In-Reply-To: <546A32720200007800048873@mail.emea.novell.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
	<546A32720200007800048873@mail.emea.novell.com>
Date: Mon, 17 Nov 2014 18:06:15 +0100
Message-ID: <CAErYnsgm5F3ThZe2w1Lq=az90ve_1pLhEb+Kpc2k9AfWOvB1FA@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Dong,
	Eddie" <eddie.dong@intel.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3485680186149111372=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3485680186149111372==
Content-Type: multipart/alternative; boundary=001a1139126c11bf69050810ff48

--001a1139126c11bf69050810ff48
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
> > On 12/11/14 15:31, Tamas K Lengyel wrote:
> >>  xen/include/public/domctl.h         |  44 +--
> >>  xen/include/public/hvm/params.h     |   2 +-
> >>  xen/include/public/mem_event.h      | 134 -------
> >>  xen/include/public/memory.h         |   6 +-
> >>  xen/include/public/vm_event.h       | 179 +++++++++
> >
> > While in principle I think this series is a very good thing, there is a
> > problem with editing the pubic header files.
> >
> > The contents of mem_event.h is not currently hidden behind #ifdef
> > __XEN_TOOLS__
> >
> > As a result, it is strictly speaking part of the VM-visible public
> > API/ABI and not permitted to change in a backwards incompatible manor.
> >
> > Having said that, it is currently only usable by privileged domains, so
> > there is an argument to be made for declaring that it should have been
> > hidden behind __XEN_TOOLS__ in the first place, making it permittable to
> > change.
>
> I'm not sure I agree - the meaning of "tools" here would seem quite a
> bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
> an old consumer (remember that for many of these we have at best
> fake consumers in the tree) would deal with the now differently
> arranged data. I don't see any versioning of the interface, and hence
> I can't see how tools would know which of the formats to expect.
>
> Jan
>

The lack of versioning is a real concern which I have aired during the 4.5
development process. For example, when we switched from HVMEM_access_* to
XENMEM_access_* a customer had to do a bunch of manual configure checks to
determine what is supported and what isn't. Furthermore, many of the
related APIs have changed quite radically between Xen 4.1-4.5, some being
abandoned midway just to resurface later in a different context. Going
forward having a clear VM_EVENT_VERSION definition would be very helpful
and would be the cleanest solution IMHO.

Tamas

--001a1139126c11bf69050810ff48
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt;&gt;=
&gt; On 12.11.14 at 16:48, &lt;<a href=3D"mailto:andrew.cooper3@citrix.com"=
>andrew.cooper3@citrix.com</a>&gt; wrote:<br>
&gt; On 12/11/14 15:31, Tamas K Lengyel wrote:<br>
</span><span class=3D"">&gt;&gt;=A0 xen/include/public/domctl.h=A0 =A0 =A0 =
=A0 =A0|=A0 44 +--<br>
&gt;&gt;=A0 xen/include/public/hvm/params.h=A0 =A0 =A0|=A0 =A02 +-<br>
&gt;&gt;=A0 xen/include/public/mem_event.h=A0 =A0 =A0 | 134 -------<br>
&gt;&gt;=A0 xen/include/public/memory.h=A0 =A0 =A0 =A0 =A0|=A0 =A06 +-<br>
&gt;&gt;=A0 xen/include/public/vm_event.h=A0 =A0 =A0 =A0| 179 +++++++++<br>
&gt;<br>
&gt; While in principle I think this series is a very good thing, there is =
a<br>
&gt; problem with editing the pubic header files.<br>
&gt;<br>
&gt; The contents of mem_event.h is not currently hidden behind #ifdef<br>
&gt; __XEN_TOOLS__<br>
&gt;<br>
&gt; As a result, it is strictly speaking part of the VM-visible public<br>
&gt; API/ABI and not permitted to change in a backwards incompatible manor.=
<br>
&gt;<br>
&gt; Having said that, it is currently only usable by privileged domains, s=
o<br>
&gt; there is an argument to be made for declaring that it should have been=
<br>
&gt; hidden behind __XEN_TOOLS__ in the first place, making it permittable =
to<br>
&gt; change.<br>
<br>
</span>I&#39;m not sure I agree - the meaning of &quot;tools&quot; here wou=
ld seem quite a<br>
bit different than e.g. in domctl.h. Looking at patch 1, I can&#39;t see ho=
w<br>
an old consumer (remember that for many of these we have at best<br>
fake consumers in the tree) would deal with the now differently<br>
arranged data. I don&#39;t see any versioning of the interface, and hence<b=
r>
I can&#39;t see how tools would know which of the formats to expect.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br></font></span></blockquote><div><br></div><div>The lack of versionin=
g is a real concern which I have aired during the 4.5 development process. =
For example, when we switched from HVMEM_access_* to XENMEM_access_* a cust=
omer had to do a bunch of manual configure checks to determine what is supp=
orted and what isn&#39;t. Furthermore, many of the related APIs have change=
d quite radically between Xen 4.1-4.5, some being abandoned midway just to =
resurface later in a different context. Going forward having a clear VM_EVE=
NT_VERSION definition would be very helpful and would be the cleanest solut=
ion IMHO.<br><br></div><div>Tamas<br></div></div><br></div></div>

--001a1139126c11bf69050810ff48--


--===============3485680186149111372==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3485680186149111372==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 17:07:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17:07:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPm8-0003Ur-IK; Mon, 17 Nov 2014 17:07:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XqPm6-0003UW-Ru
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:07:39 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	25/64-18267-A5B2A645; Mon, 17 Nov 2014 17:07:38 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416244056!11918674!1
X-Originating-IP: [209.85.192.42]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18402 invoked from network); 17 Nov 2014 17:07:37 -0000
Received: from mail-qg0-f42.google.com (HELO mail-qg0-f42.google.com)
	(209.85.192.42)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 17:07:37 -0000
Received: by mail-qg0-f42.google.com with SMTP id i50so15565907qgf.15
	for <xen-devel@lists.xen.org>; Mon, 17 Nov 2014 09:07:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=zxetx5i/AXTXsLhmLxxKRKe9cW8Jc1PA4Ke6QUuTjtw=;
	b=AMN/q2WiR4OIre/IPkw2Ba2x4HWg87iv7yOgI2sHEJXmRs39TdTT3Zu290A6Lt46TH
	XUMKaMfER1AmPq+fQBwwxKMwwdVVb7P+b3HtVtZ+NFD853oZd2CIJdkOaAiilsBrCopc
	TPLfJb9/gVj0s40HDjmni/XDx6E9tx/y/pRbuxEUfok+3orvn47T8SF5Qq/uJxQrx5g3
	4zh9U3u1SoHgWkSPO8W5alNnDGww6Mto/Pz5opZ/mYgTxkcFrJpG/w1zoiVJ4Z+H8ayq
	Y4CA+FudvpM6RnMYj0/lEtY52nH0zBFTuqFK7WOasCq7tlsS0ZOPhR8PInU8PKPmgCOK
	EmXw==
X-Gm-Message-State: ALoCoQlmGeJvnkdgL1NHwuY6Y7bMxpdwCpztw6ewxGVyfviOKkXBp3cM7UyqCsDc4f7IGm5Cbt3N
MIME-Version: 1.0
X-Received: by 10.224.80.71 with SMTP id s7mr35091318qak.35.1416244056235;
	Mon, 17 Nov 2014 09:07:36 -0800 (PST)
Received: by 10.229.176.198 with HTTP; Mon, 17 Nov 2014 09:07:36 -0800 (PST)
In-Reply-To: <546A33EA02000078000488A1@mail.emea.novell.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
	<546A33EA02000078000488A1@mail.emea.novell.com>
Date: Mon, 17 Nov 2014 18:07:36 +0100
Message-ID: <CAErYnsiKQuBBQTO9239Oa_NR_MKp4EphLEpO_1Z88qr7C8zZaA@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event
	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: multipart/mixed; boundary="===============8846481249730974008=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8846481249730974008==
Content-Type: multipart/alternative; boundary=001a11c2c7ece3343c05081103f2

--001a11c2c7ece3343c05081103f2
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 17, 2014 at 5:44 PM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 12.11.14 at 16:31, <tamas.lengyel@zentific.com> wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
>
> Leaving aside the general reservation I just voiced in reply to 0/7, I
> wonder whether - considering that you mostly replace the code
> that gets changed in this file - it wouldn't be a nice opportunity to
> move these into a separate file, allowing this huge one to not
> always only grow.
>
> Jan
>
>
Agree, that would make sense.

Tamas

--001a11c2c7ece3343c05081103f2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Nov 17, 2014 at 5:44 PM, Jan Beulich <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt;&gt;&gt; On 12.11.14 =
at 16:31, &lt;<a href=3D"mailto:tamas.lengyel@zentific.com">tamas.lengyel@z=
entific.com</a>&gt; wrote:<br>
&gt; --- a/xen/arch/x86/hvm/hvm.c<br>
&gt; +++ b/xen/arch/x86/hvm/hvm.c<br>
<br>
Leaving aside the general reservation I just voiced in reply to 0/7, I<br>
wonder whether - considering that you mostly replace the code<br>
that gets changed in this file - it wouldn&#39;t be a nice opportunity to<b=
r>
move these into a separate file, allowing this huge one to not<br>
always only grow.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br>Agree, that would make sense.<br><br>T=
amas<br></div></div>

--001a11c2c7ece3343c05081103f2--


--===============8846481249730974008==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8846481249730974008==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 17:07:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17:07:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPm8-0003Ur-IK; Mon, 17 Nov 2014 17:07:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1XqPm6-0003UW-Ru
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:07:39 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	25/64-18267-A5B2A645; Mon, 17 Nov 2014 17:07:38 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416244056!11918674!1
X-Originating-IP: [209.85.192.42]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18402 invoked from network); 17 Nov 2014 17:07:37 -0000
Received: from mail-qg0-f42.google.com (HELO mail-qg0-f42.google.com)
	(209.85.192.42)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 17:07:37 -0000
Received: by mail-qg0-f42.google.com with SMTP id i50so15565907qgf.15
	for <xen-devel@lists.xen.org>; Mon, 17 Nov 2014 09:07:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=zxetx5i/AXTXsLhmLxxKRKe9cW8Jc1PA4Ke6QUuTjtw=;
	b=AMN/q2WiR4OIre/IPkw2Ba2x4HWg87iv7yOgI2sHEJXmRs39TdTT3Zu290A6Lt46TH
	XUMKaMfER1AmPq+fQBwwxKMwwdVVb7P+b3HtVtZ+NFD853oZd2CIJdkOaAiilsBrCopc
	TPLfJb9/gVj0s40HDjmni/XDx6E9tx/y/pRbuxEUfok+3orvn47T8SF5Qq/uJxQrx5g3
	4zh9U3u1SoHgWkSPO8W5alNnDGww6Mto/Pz5opZ/mYgTxkcFrJpG/w1zoiVJ4Z+H8ayq
	Y4CA+FudvpM6RnMYj0/lEtY52nH0zBFTuqFK7WOasCq7tlsS0ZOPhR8PInU8PKPmgCOK
	EmXw==
X-Gm-Message-State: ALoCoQlmGeJvnkdgL1NHwuY6Y7bMxpdwCpztw6ewxGVyfviOKkXBp3cM7UyqCsDc4f7IGm5Cbt3N
MIME-Version: 1.0
X-Received: by 10.224.80.71 with SMTP id s7mr35091318qak.35.1416244056235;
	Mon, 17 Nov 2014 09:07:36 -0800 (PST)
Received: by 10.229.176.198 with HTTP; Mon, 17 Nov 2014 09:07:36 -0800 (PST)
In-Reply-To: <546A33EA02000078000488A1@mail.emea.novell.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<1415806309-5206-2-git-send-email-tamas.lengyel@zentific.com>
	<546A33EA02000078000488A1@mail.emea.novell.com>
Date: Mon, 17 Nov 2014 18:07:36 +0100
Message-ID: <CAErYnsiKQuBBQTO9239Oa_NR_MKp4EphLEpO_1Z88qr7C8zZaA@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event
	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: multipart/mixed; boundary="===============8846481249730974008=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8846481249730974008==
Content-Type: multipart/alternative; boundary=001a11c2c7ece3343c05081103f2

--001a11c2c7ece3343c05081103f2
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 17, 2014 at 5:44 PM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 12.11.14 at 16:31, <tamas.lengyel@zentific.com> wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
>
> Leaving aside the general reservation I just voiced in reply to 0/7, I
> wonder whether - considering that you mostly replace the code
> that gets changed in this file - it wouldn't be a nice opportunity to
> move these into a separate file, allowing this huge one to not
> always only grow.
>
> Jan
>
>
Agree, that would make sense.

Tamas

--001a11c2c7ece3343c05081103f2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Nov 17, 2014 at 5:44 PM, Jan Beulich <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt;&gt;&gt; On 12.11.14 =
at 16:31, &lt;<a href=3D"mailto:tamas.lengyel@zentific.com">tamas.lengyel@z=
entific.com</a>&gt; wrote:<br>
&gt; --- a/xen/arch/x86/hvm/hvm.c<br>
&gt; +++ b/xen/arch/x86/hvm/hvm.c<br>
<br>
Leaving aside the general reservation I just voiced in reply to 0/7, I<br>
wonder whether - considering that you mostly replace the code<br>
that gets changed in this file - it wouldn&#39;t be a nice opportunity to<b=
r>
move these into a separate file, allowing this huge one to not<br>
always only grow.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br>Agree, that would make sense.<br><br>T=
amas<br></div></div>

--001a11c2c7ece3343c05081103f2--


--===============8846481249730974008==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8846481249730974008==--


From xen-devel-bounces@lists.xen.org Mon Nov 17 17:12:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17:12:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPqw-0003l7-Bj; Mon, 17 Nov 2014 17:12:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XqPqu-0003kz-6w
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:12:36 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	CD/99-26858-38C2A645; Mon, 17 Nov 2014 17:12:35 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416244353!7533497!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31880 invoked from network); 17 Nov 2014 17:12:34 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 17:12:34 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHHCSwf029897
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 17:12:29 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHHCSKP028027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 17:12:28 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHHCSYI027790; Mon, 17 Nov 2014 17:12:28 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 09:12:27 -0800
Message-ID: <546A2D1C.7040409@oracle.com>
Date: Mon, 17 Nov 2014 12:15:08 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416243498.5466.27.camel@citrix.com> <546A2985.5000106@citrix.com>
In-Reply-To: <546A2985.5000106@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/17/2014 11:59 AM, Andrew Cooper wrote:
> On 17/11/14 16:58, Ian Campbell wrote:
>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>>> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
>>> parse bootloader configuration files.
>> Please can you and Boris both provide examples of (ideally real-world)
>> configuration files which exhibit these failures as patches against
>> tools/pygrub/examples/.
>>
>> Boris, in your case I mean the one which caused you to write the
>> original patch, which I should have remembered to ask for at the time.


I wanted to be able to parse grub2's default values set as strings, such as

    set default="Fedora, with Xen xen and Linux 3.17.0-rc3"

or, for submenus

    set default="Advanced options for Fedora (with Xen 
hypervisor)>Fedora, with Xen xen and Linux 3.17.0-rc3"

Original pygrub would not be able to understand the string and default 
to zero.

-boris


>>
>> Andy, in your case it would make sense to include at least one in this
>> patch I think.
>>
>> Ian.
>>
> examples/ doesn't help.  The parsers themselves don't exhibit the bug.
> It is only when pygrub itself attempts to interact with the parsed
> config does the issue exhibits itself.
>
> I would have provided an example if it would have helped.
>
> ~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 17:12:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17:12:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqPqw-0003l7-Bj; Mon, 17 Nov 2014 17:12:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XqPqu-0003kz-6w
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:12:36 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	CD/99-26858-38C2A645; Mon, 17 Nov 2014 17:12:35 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416244353!7533497!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31880 invoked from network); 17 Nov 2014 17:12:34 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 17:12:34 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHHCSwf029897
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 17:12:29 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHHCSKP028027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 17:12:28 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHHCSYI027790; Mon, 17 Nov 2014 17:12:28 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 09:12:27 -0800
Message-ID: <546A2D1C.7040409@oracle.com>
Date: Mon, 17 Nov 2014 12:15:08 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416243498.5466.27.camel@citrix.com> <546A2985.5000106@citrix.com>
In-Reply-To: <546A2985.5000106@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/17/2014 11:59 AM, Andrew Cooper wrote:
> On 17/11/14 16:58, Ian Campbell wrote:
>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>>> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
>>> parse bootloader configuration files.
>> Please can you and Boris both provide examples of (ideally real-world)
>> configuration files which exhibit these failures as patches against
>> tools/pygrub/examples/.
>>
>> Boris, in your case I mean the one which caused you to write the
>> original patch, which I should have remembered to ask for at the time.


I wanted to be able to parse grub2's default values set as strings, such as

    set default="Fedora, with Xen xen and Linux 3.17.0-rc3"

or, for submenus

    set default="Advanced options for Fedora (with Xen 
hypervisor)>Fedora, with Xen xen and Linux 3.17.0-rc3"

Original pygrub would not be able to understand the string and default 
to zero.

-boris


>>
>> Andy, in your case it would make sense to include at least one in this
>> patch I think.
>>
>> Ian.
>>
> examples/ doesn't help.  The parsers themselves don't exhibit the bug.
> It is only when pygrub itself attempts to interact with the parsed
> config does the issue exhibits itself.
>
> I would have provided an example if it would have helped.
>
> ~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 17:39:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqQGe-0004A7-PT; Mon, 17 Nov 2014 17:39:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqQGd-0004A2-E2
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:39:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A1/6C-09842-EB23A645; Mon, 17 Nov 2014 17:39:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416245947!13390942!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8129 invoked from network); 17 Nov 2014 17:39:10 -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;
	17 Nov 2014 17:39:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="192130396"
Message-ID: <546A2F7D.8050507@citrix.com>
Date: Mon, 17 Nov 2014 17:25:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
In-Reply-To: <20141117170032.GB29684@deinos.phlegethon.org>
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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 17/11/14 17:00, Tim Deegan wrote:
> At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
>> On 17/11/14 16:30, Tim Deegan wrote:
>>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>>>> Users don't have to use a 'cpuid= ' option in config file to turn
>>>>>> it on.
>>>>> I don't understand what this flag does.  I guess from the name it
>>>>> turns on 1G pages.  I guess these are supported ?
>>>>>
>>>>> I would like to see comment from an x86 hypervisor maintainer.
>>>> Yes, we support 1Gb pages. The purpose of the patch is to not
>>>> unconditionally hide the flag from guests. (I had commented on
>>>> v1, but sadly this one wasn't tagged as v2, nor was I included on
>>>> the Cc list, hence I didn't spot the new version.)
>>>>
>>>> The one thing I'm not certain about is shadow mode: Only 2Mb
>>>> pages may be supported there. Tim?
>>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
>>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
>> This is yet another case which proves that libxc is the wrong place to
>> be choosing the cpuid flags exposed to a domain.
>>
>> Furthermore, guest_supports_1G_superpages() is insufficient as it only
>> checks whether the host is capable of providing 1G superpages, not
>> whether the guest has been permitted to use it.
>>
>> This causes a problem when migrating between hap-capable and
>> hap-incapable systems.
> There's no notion of 'permitted' to use 1G pages, AFAICS, much like
> other CPU features.  But of course a _well-behaved_ guest that has
> been told in cpuid not to use 1G superpages will have no problems. :)

That is my point.

If 1GB pages are not supported (i.e. not present in cpuid), then the PS
bit in an L3 is reserved, must be 0, and cause a pagefault if used.

Nothing in Xen currently enforces this because
guest_supports_1G_superpages() doesn't check domain_cpuid().

It does however make me wonder how VMX/SVM non-root mode would enforce
this as it would see the host cpuid, not guest cpuid when performing
paging internally.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 17:39:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 17:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqQGe-0004A7-PT; Mon, 17 Nov 2014 17:39:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqQGd-0004A2-E2
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 17:39:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A1/6C-09842-EB23A645; Mon, 17 Nov 2014 17:39:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416245947!13390942!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8129 invoked from network); 17 Nov 2014 17:39:10 -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;
	17 Nov 2014 17:39:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="192130396"
Message-ID: <546A2F7D.8050507@citrix.com>
Date: Mon, 17 Nov 2014 17:25:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.8.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
In-Reply-To: <20141117170032.GB29684@deinos.phlegethon.org>
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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 17/11/14 17:00, Tim Deegan wrote:
> At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
>> On 17/11/14 16:30, Tim Deegan wrote:
>>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>>>> Users don't have to use a 'cpuid= ' option in config file to turn
>>>>>> it on.
>>>>> I don't understand what this flag does.  I guess from the name it
>>>>> turns on 1G pages.  I guess these are supported ?
>>>>>
>>>>> I would like to see comment from an x86 hypervisor maintainer.
>>>> Yes, we support 1Gb pages. The purpose of the patch is to not
>>>> unconditionally hide the flag from guests. (I had commented on
>>>> v1, but sadly this one wasn't tagged as v2, nor was I included on
>>>> the Cc list, hence I didn't spot the new version.)
>>>>
>>>> The one thing I'm not certain about is shadow mode: Only 2Mb
>>>> pages may be supported there. Tim?
>>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
>>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
>> This is yet another case which proves that libxc is the wrong place to
>> be choosing the cpuid flags exposed to a domain.
>>
>> Furthermore, guest_supports_1G_superpages() is insufficient as it only
>> checks whether the host is capable of providing 1G superpages, not
>> whether the guest has been permitted to use it.
>>
>> This causes a problem when migrating between hap-capable and
>> hap-incapable systems.
> There's no notion of 'permitted' to use 1G pages, AFAICS, much like
> other CPU features.  But of course a _well-behaved_ guest that has
> been told in cpuid not to use 1G superpages will have no problems. :)

That is my point.

If 1GB pages are not supported (i.e. not present in cpuid), then the PS
bit in an L3 is reserved, must be 0, and cause a pagefault if used.

Nothing in Xen currently enforces this because
guest_supports_1G_superpages() doesn't check domain_cpuid().

It does however make me wonder how VMX/SVM non-root mode would enforce
this as it would see the host cpuid, not guest cpuid when performing
paging internally.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 18:01:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 18:01:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqQbv-0004a2-WA; Mon, 17 Nov 2014 18:01:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqQbu-0004Zx-4w
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 18:01:10 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	BC/28-02953-5E73A645; Mon, 17 Nov 2014 18:01:09 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416247264!8482181!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22153 invoked from network); 17 Nov 2014 18:01:05 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 17 Nov 2014 18:01:05 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50076 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqQaR-0000zH-7x; Mon, 17 Nov 2014 18:59:39 +0100
Date: Mon, 17 Nov 2014 19:01:03 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1848367524.20141117190103@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141117163416.GA22137@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------07C1DE16C0EDF9EBB"
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------07C1DE16C0EDF9EBB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Monday, November 17, 2014, 5:34:16 PM, you wrote:

> On Fri, Nov 14, 2014 at 11:09:58PM +0100, Sander Eikelenboom wrote:
>> 
>> Friday, November 14, 2014, 9:25:13 PM, you wrote:
>> 
>> > On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> >> 
>> >> Friday, November 14, 2014, 4:43:58 PM, you wrote:
>> >> 
>> >> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
>> >> >> If it still helps i could try Andrews suggestion and try out with only 
>> >> >> commit aeeea485 ..
>> >> 
>> >> > Yes, even if it's pretty certain it's the second of the commits, verifying
>> >> > this would be helpful (or if the assumption is wrong, the pattern it's
>> >> > dying with would change and hence perhaps provide further clues).
>> >> 
>> >> > Jan
>> >> 
>> >> 
>> >> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
>> >> pasta without a panic. So it would probably be indeed that specific commit.
>> 
>> > Could you try running with these two patches while you enjoy an beer in the evening?
>> 
>> Hmm i didn't expect it not to panic and reboot anymore :-)

> I should have also asked for your to run with 'iommu=verbose,debug', but
> that can be done later..

> The guest d16 looks to have two PCI passthrough devices:
> XEN) [2014-11-14 21:31:26.569] io.c:550: d16: bind: m_gsi=37 g_gsi=36 dev=00.00.5 intx=0
> XEN) [2014-11-14 21:31:28.095] io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0

> And one of them uses just the GSI while the other uses four MSI-X, is
> that about right?

> I tried to reproduce that on my AMD box with two NICs:


> # lspci
> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
> 00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
> 00:02.0 VGA compatible controller: Technical Corp. Device 1111
> 00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
> 00:04.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
> 00:05.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)

> # cat /proc/interrupts |grep eth
>  36:     384183          0  xen-pirq-ioapic-level  eth0
>  63:          1          0  xen-pirq-msi-x     eth1
>  64:         24     661961  xen-pirq-msi-x     eth1-rx-0
>  65:        205          0  xen-pirq-msi-x     eth1-rx-1
>  66:        162          0  xen-pirq-msi-x     eth1-tx-0
>  67:        190          0  xen-pirq-msi-x     eth1-tx-1


> Is that a similar distribution of IRQ/MSIx you end up having?
>> 
>> However xl dmesg (complete one attached) showed it would have:
>> 
>> (XEN) [2014-11-14 21:35:50.646] --MARK--
>> (XEN) [2014-11-14 21:35:56.861] grant_table.c:305:d0v0 Increased maptrack size to 9 frames
>> (XEN) [2014-11-14 21:36:00.647] --MARK--
>> (XEN) [2014-11-14 21:36:10.410] grant_table.c:1299:d16v1 Expanding dom (16) grant table from (5) to (6) frames.
>> (XEN) [2014-11-14 21:36:10.820] --MARK--
>> (XEN) [2014-11-14 21:36:20.820] --MARK--
>> (XEN) [2014-11-14 21:36:30.820] --MARK--
>> (XEN) [2014-11-14 21:36:40.821] --MARK--
>> (XEN) [2014-11-14 21:36:50.821] --MARK--
>> (XEN) [2014-11-14 21:37:00.388] CPU00:
>> (XEN) [2014-11-14 21:37:00.399] CPU01:
>> (XEN) [2014-11-14 21:37:00.410] d16 OK-softirq 20msec ago, state:1, 41220 count, [prev:ffff83054ef5e3e0, next:ffff83054ef5e3e0]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.445] d16 OK-raise   46msec ago, state:1, 41223 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.481] d16 ERR-poison 92msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.515] d16 Z-softirq  28853msec ago, state:2, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0

> The PIRQ:0 would imply that this is the legacy interrupt - which would be you 0a:00.0 device 
> (Conexant Systems, Inc. Device 8210).


> And it is pounding on this CPU - and the issue is that the 'test_and_clear_bit' ends
> up returning 0 - which means it was not able to set STATE_SCHED:
> (!?)
>     if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               
>         {                                                                       
>             hvm_dirq_assist(d, pirq_dpci);                                      
>             put_domain(d);                                                      
>         }                                                                       
>         else                                                                    
>         {                                                                       
>             _record(&debug->zombie_softirq, pirq_dpci);        

> which causes us to record it [Z-softirq],  which says we we are in state 2
> (1<<STATE_RUN).

>             reset = 1;                                                          
>         }                                        

> .. eons ago (28853msec).

> Hmm. There is something fishy there but the only theory I have is that
> we end up doing 'list_del' twice on different CPUs on the same structure.

> That should not be possible, but then this check - 'test_and_clear_bit' returned
> 0 which means that somebody had cleared it (or it failed to clear it?)

> But the only other path for 'clearing' it is via the error paths and you are
> not hitting any of them.

> In the mean-time, could you try this patch. It adds a bit more debug to help
> me figure this out.

> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index 23e5ed1..443975c 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -126,17 +126,17 @@ static void dump_record(struct _debug_f *d, unsigned int type)
>          BUG();
>  
>      now = NOW();
> -    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
> +    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
>             d->domid, names[type],
>             (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->>state, d->count, d->list.prev, d->list.next);
+            d->>state, d->count, d->list.prev, d->list.next, d->dpci);
>  
>      if ( d->dpci )
>      {
>          struct hvm_pirq_dpci *pirq_dpci = d->dpci;
>  
>          for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
> -            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
> +            if ( pirq_dpci->flags & (1 << i) )
>                  printk("%s ", names_flag[i]);
>  
>          printk(" PIRQ:%d", pirq_dpci->pirq);

Hi Konrad,

Here is the xl dmesg output with this patch (attached with debug-key i and M 
output). What i don't get .. is that d16 and d17 each have a device passed through 
that seems to be using the same pirq 87 ?
 
--
Sander

(XEN) [2014-11-17 17:54:18.695] CPU00:
(XEN) [2014-11-17 17:54:18.705] CPU01:
(XEN) [2014-11-17 17:54:18.716] d16 OK-softirq 62msec ago, state:1, 2628 count, [prev:ffff83054ef57e70, next:ffff83054ef57e70] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:18.765] d16 OK-raise   112msec ago, state:1, 2628 count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:18.815] CPU02:
(XEN) [2014-11-17 17:54:18.825] d17 OK-softirq 500msec ago, state:1, 3439 count, [prev:ffff83054ef47e70, next:ffff83054ef47e70] ffff83051a1c8c28<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:18.875] d17 OK-raise   549msec ago, state:1, 3439 count, [prev:0000000000200200, next:0000000000100100] ffff83051a1c8c28<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:18.924] CPU03:
(XEN) [2014-11-17 17:54:18.935] d16 OK-softirq 313msec ago, state:1, 3533 count, [prev:ffff83054ef37e70, next:ffff83054ef37e70] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:18.984] d16 OK-raise   363msec ago, state:1, 3533 count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:19.034] CPU04:
(XEN) [2014-11-17 17:54:19.044] d16 OK-softirq 359msec ago, state:1, 3691 count, [prev:ffff83054ef27e88, next:ffff83054ef27e88] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:19.094] d16 OK-raise   408msec ago, state:1, 3691 count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:19.143] CPU05:
(XEN) [2014-11-17 17:54:19.154] d16 OK-softirq 458msec ago, state:1, 52039 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
(XEN) [2014-11-17 17:54:19.205] d16 OK-raise   489msec ago, state:1, 52049 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
(XEN) [2014-11-17 17:54:19.257] d16 ERR-poison 561msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
(XEN) [2014-11-17 17:54:19.307] d16 Z-softirq  731msec ago, state:3, 3 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
(XEN) [2014-11-17 17:54:19.356] domain_crash called from io.c:938
(XEN) [2014-11-17 17:54:19.356] Domain 16 reported crashed by domain 32767 on cpu#5:
------------07C1DE16C0EDF9EBB
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDM6NDYuMDA0XSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xNyAxNzo0Mzo1Ni4wMDRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3
IDE3OjQ0OjA2LjAwNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDQ6MTYuMDA1
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NDoyNi4wMDVdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE3IDE3OjQ0OjM2LjAwNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTcgMTc6NDQ6NDYuMDA1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NDo1Ni4w
MDZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ1OjA2LjAwNl0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTcgMTc6NDU6MTYuMDA2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xNyAxNzo0NToyNi4wMDZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ1OjM2
LjAwN10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDU6NDYuMDA3XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NTo1Ni4wMDddIC0tTUFSSy0tCihkMSkgWzIwMTQt
MTEtMTcgMTc6NDY6MDUuNzI0XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9y
eQooZDEpIFsyMDE0LTExLTE3IDE3OjQ2OjA1LjcyNF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQu
Li4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDY6MDUuOTkzXSB0cmFwcy5jOjI1Nzk6ZDF2MCBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAw
MDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xNyAxNzo0
NjowNi4wMDddIC0tTUFSSy0tCihkMikgWzIwMTQtMTEtMTcgMTc6NDY6MTEuNzA3XSBtYXBw
aW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDIpIFsyMDE0LTExLTE3IDE3OjQ2
OjExLjcwN10gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6
NDY6MTEuNzg5XSB0cmFwcy5jOjI1Nzk6ZDJ2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAw
MDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAw
MDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NjoxNi4wMDhdIC0tTUFSSy0tCihkMykg
WzIwMTQtMTEtMTcgMTc6NDY6MTcuNDk3XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2Fs
IG1lbW9yeQooZDMpIFsyMDE0LTExLTE3IDE3OjQ2OjE3LjQ5N10gYWJvdXQgdG8gZ2V0IHN0
YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDY6MTcuNTg5XSB0cmFwcy5jOjI1Nzk6
ZDN2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAw
MDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooZDQpIFsyMDE0LTExLTE3
IDE3OjQ2OjIzLjQ3M10gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQ0
KSBbMjAxNC0xMS0xNyAxNzo0NjoyMy40NzNdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihY
RU4pIFsyMDE0LTExLTE3IDE3OjQ2OjIzLjU1MF0gdHJhcHMuYzoyNTc5OmQ0djAgRG9tYWlu
IGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAw
MDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDY6MjQu
MTE1XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRv
IDIgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ2OjI2LjAwOF0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTcgMTc6NDY6MjguNjM0XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIElu
Y3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDMgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE3IDE3
OjQ2OjI4LjY1NV0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sg
c2l6ZSB0byA0IGZyYW1lcwooZDUpIFsyMDE0LTExLTE3IDE3OjQ2OjI5LjMzNV0gbWFwcGlu
ZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQ1KSBbMjAxNC0xMS0xNyAxNzo0Njoy
OS4zMzVdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ2
OjI5LjQxM10gdHJhcHMuYzoyNTc5OmQ1djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAw
MDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAw
ZmZmZi4KKGQ2KSBbMjAxNC0xMS0xNyAxNzo0NjozNS4xODBdIG1hcHBpbmcga2VybmVsIGlu
dG8gcGh5c2ljYWwgbWVtb3J5CihkNikgWzIwMTQtMTEtMTcgMTc6NDY6MzUuMTgwXSBhYm91
dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NjozNS4yOTRdIHRy
YXBzLmM6MjU3OTpkNnYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4p
IFsyMDE0LTExLTE3IDE3OjQ2OjM2LjAwOF0gLS1NQVJLLS0KKGQ3KSBbMjAxNC0xMS0xNyAx
Nzo0Njo0MS4zMDJdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkNykg
WzIwMTQtMTEtMTcgMTc6NDY6NDEuMzAyXSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVO
KSBbMjAxNC0xMS0xNyAxNzo0Njo0MS4zODRdIHRyYXBzLmM6MjU3OTpkN3YwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAw
MCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ2OjQ2LjAw
OF0gLS1NQVJLLS0KKGQ4KSBbMjAxNC0xMS0xNyAxNzo0Njo0Ny4xOTRdIG1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkOCkgWzIwMTQtMTEtMTcgMTc6NDY6NDcuMTk0
XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Njo0Ny4y
NzFdIHRyYXBzLmM6MjU3OTpkOHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYu
CihkOSkgWzIwMTQtMTEtMTcgMTc6NDY6NTMuMjIwXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBo
eXNpY2FsIG1lbW9yeQooZDkpIFsyMDE0LTExLTE3IDE3OjQ2OjUzLjIyMF0gYWJvdXQgdG8g
Z2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDY6NTMuMzM2XSB0cmFwcy5j
OjI1Nzk6ZDl2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJv
bSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAx
NC0xMS0xNyAxNzo0Njo1NC45NDJdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2Vk
IG1hcHRyYWNrIHNpemUgdG8gNSBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDY6NTYu
MDA4XSAtLU1BUkstLQooZDEwKSBbMjAxNC0xMS0xNyAxNzo0NzowMC4wNDRdIG1hcHBpbmcg
a2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTApIFsyMDE0LTExLTE3IDE3OjQ3OjAw
LjA0NF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6
MDAuMTMwXSB0cmFwcy5jOjI1Nzk6ZDEwdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAw
MDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAw
ZmZmZi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MDYuMDA5XSAtLU1BUkstLQooZDExKSBb
MjAxNC0xMS0xNyAxNzo0NzowNi4yNjVdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwg
bWVtb3J5CihkMTEpIFsyMDE0LTExLTE3IDE3OjQ3OjA2LjI2NV0gYWJvdXQgdG8gZ2V0IHN0
YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MDYuMzU5XSB0cmFwcy5jOjI1Nzk6
ZDExdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgw
MDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKGQxMikgWzIwMTQtMTEt
MTcgMTc6NDc6MTIuNDM5XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQoo
ZDEyKSBbMjAxNC0xMS0xNyAxNzo0NzoxMi40MzldIGFib3V0IHRvIGdldCBzdGFydGVkLi4u
CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjEyLjUyOV0gdHJhcHMuYzoyNTc5OmQxMnYwIERv
bWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAw
MDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3
OjE2LjAwOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MTguOTI1XSBBTUQt
Vmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4YTQsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMwooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NzoxOC45MjVdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTQsIHR5cGUgPSAweDcsIHJvb3QgdGFibGUg
PSAweDUxNjZjNDAwMCwgZG9tYWluID0gMTMsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAx
NC0xMS0xNyAxNzo0NzoxOC45MjVdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MDM6MDYuMCBm
cm9tIGRvbTAgdG8gZG9tMTMKKGQxMykgWzIwMTQtMTEtMTcgMTc6NDc6MTguOTM5XSBtYXBw
aW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDEzKSBbMjAxNC0xMS0xNyAxNzo0
NzoxOC45MzldIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE3IDE3
OjQ3OjE5LjE3N10gdHJhcHMuYzoyNTc5OmQxM3YwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1Ig
MDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAw
MDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjIxLjAyNV0gZ3JhbnRfdGFibGUu
YzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA2IGZyYW1lcwooZDE0KSBb
MjAxNC0xMS0xNyAxNzo0NzoyNC45MzNdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwg
bWVtb3J5CihkMTQpIFsyMDE0LTExLTE3IDE3OjQ3OjI0LjkzM10gYWJvdXQgdG8gZ2V0IHN0
YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MjUuMDI0XSB0cmFwcy5jOjI1Nzk6
ZDE0djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgw
MDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEt
MTcgMTc6NDc6MjYuMDA5XSAtLU1BUkstLQooZDE1KSBbMjAxNC0xMS0xNyAxNzo0NzozMS4y
NzJdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTUpIFsyMDE0LTEx
LTE3IDE3OjQ3OjMxLjI3Ml0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQt
MTEtMTcgMTc6NDc6MzEuMzY0XSB0cmFwcy5jOjI1Nzk6ZDE1djAgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4
MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MzYuMDA5XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NzozOS40MDFdIGlvLmM6NTUwOiBkMTY6IGJp
bmQ6IG1fZ3NpPTM3IGdfZ3NpPTM2IGRldj0wMC4wMC41IGludHg9MAooWEVOKSBbMjAxNC0x
MS0xNyAxNzo0NzozOS44MDhdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHg4MDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzoz
OS44MDhdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ODAw
LCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1MWIwZDEwMDAsIGRvbWFpbiA9IDE2LCBw
YWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MzkuODA4XSBBTUQtVmk6
IFJlLWFzc2lnbiAwMDAwOjA4OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE2CihYRU4pIFsyMDE0
LTExLTE3IDE3OjQ3OjQwLjkyN10gaW8uYzo1NTA6IGQxNjogYmluZDogbV9nc2k9NDcgZ19n
c2k9NDAgZGV2PTAwLjAwLjYgaW50eD0wCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjkz
M10gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweGEwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjkzM10gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMDAsIHR5cGUgPSAweDEsIHJv
b3QgdGFibGUgPSAweDUxYjBkMTAwMCwgZG9tYWluID0gMTYsIHBhZ2luZyBtb2RlID0gMwoo
WEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0MC45MzNdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6
MGE6MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTYKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDAu
OTQ0XSBIVk0gTG9hZGVyCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjk0NF0gRGV0ZWN0
ZWQgWGVuIHY0LjUuMC1yYwooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MC45NDRdIFhlbmJ1
cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCAxCihkMTYpIFsyMDE0LTExLTE3
IDE3OjQ3OjQwLjk0NF0gU3lzdGVtIHJlcXVlc3RlZCBTZWFCSU9TCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQwLjk0NF0gQ1BVIHNwZWVkIGlzIDMyMDAgTUh6CihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQwLjk0NF0gUmVsb2NhdGluZyBndWVzdCBtZW1vcnkgZm9yIGxvd21lbSBN
TUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjk0NV0gaXJx
LmM6MjcwOiBEb20xNiBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1CihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQwLjk0NV0gUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUKKFhFTikg
WzIwMTQtMTEtMTcgMTc6NDc6NDAuOTQ1XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEg
Y2hhbmdlZCAwIC0+IDEwCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjk0NV0gUENJLUlT
QSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjk0
NV0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAyIGNoYW5nZWQgMCAtPiAxMQooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MC45NDVdIFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlEx
MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0MC45NDZdIGlycS5jOjI3MDogRG9tMTYgUENJ
IGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MC45NDZd
IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1CihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3
OjQwLjk2M10gcGNpIGRldiAwMToyIElOVEQtPklSUTUKKGQxNikgWzIwMTQtMTEtMTcgMTc6
NDc6NDAuOTY5XSBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTAKKGQxNikgWzIwMTQtMTEtMTcg
MTc6NDc6NDAuOTc0XSBwY2kgZGV2IDAyOjAgSU5UQS0+SVJRMTEKKGQxNikgWzIwMTQtMTEt
MTcgMTc6NDc6NDAuOTg1XSBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQooZDE2KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0MC45OTFdIHBjaSBkZXYgMDU6MCBJTlRBLT5JUlExMAooZDE2KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0MC45OThdIHBjaSBkZXYgMDY6MCBJTlRBLT5JUlExMQooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS4wNDJdIE5vIFJBTSBpbiBoaWdoIG1lbW9yeTsgc2V0dGlu
ZyBoaWdoX21lbSByZXNvdXJjZSBiYXNlIHRvIDEwMDAwMDAwMAooZDE2KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0MS4wNDJdIHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDIwMDAwMDA6IDBm
MDAwMDAwOAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4wNDRdIHBjaSBkZXYgMDI6MCBi
YXIgMTQgc2l6ZSAwMDEwMDAwMDA6IDBmMjAwMDAwOAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0
Nzo0MS4wNDZdIHBjaSBkZXYgMDY6MCBiYXIgMTAgc2l6ZSAwMDAyMDAwMDA6IDBmMzAwMDAw
NAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4wNDZdIG1lbW9yeV9tYXA6YWRkOiBkb20x
NiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0
MS4wNTFdIHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAwNDAwMDA6IDBmMzIwMDAwMAoo
ZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4wNTRdIHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6
ZSAwMDAwMjAwMDA6IDBmMzI0MDAwMAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4wNTRd
IHBjaSBkZXYgMDM6MCBiYXIgMzAgc2l6ZSAwMDAwMTAwMDA6IDBmMzI2MDAwMAooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS4wNTVdIHBjaSBkZXYgMDU6MCBiYXIgMTAgc2l6ZSAwMDAw
MDIwMDA6IDBmMzI3MDAwNAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4wNTVdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKGQxNikgWzIwMTQt
MTEtMTcgMTc6NDc6NDEuMDYyXSBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDAwMDAxMDAw
OiAwZjMyNzIwMDAKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMDYyXSBwY2kgZGV2IDAy
OjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDEKKGQxNikgWzIwMTQtMTEtMTcg
MTc6NDc6NDEuMDY0XSBwY2kgZGV2IDA0OjAgYmFyIDE0IHNpemUgMDAwMDAwMDQwOiAwMDAw
MGMxMDEKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMDY3XSBwY2kgZGV2IDAxOjIgYmFy
IDIwIHNpemUgMDAwMDAwMDIwOiAwMDAwMGMxNDEKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6
NDEuMDY5XSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNjEK
KGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMDcxXSA/IT8hPyE/IT8gZW5hYmxlIElPIG9u
IHByaW1hcnkgdmdhIHBjaSBkZXYgMDM6MCAKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEu
MDcxXSBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKKGQxNikgWzIwMTQtMTEtMTcg
MTc6NDc6NDEuMDk1XSAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMg
Li4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6
NDEuMTIwXSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh
ciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTQ1
XSAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS
cyBbMS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTY5XSAgLSBD
UFUzIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84
XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTY5XSBUZXN0aW5nIEhW
TSBlbnZpcm9ubWVudDoKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTc4XSAgLSBSRVAg
SU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxNikgWzIwMTQtMTEt
MTcgMTc6NDc6NDEuMTgyXSAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2Vk
CihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjE4Ml0gUGFzc2VkIDIgb2YgMiB0ZXN0cwoo
ZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xODJdIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAu
Li4KKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTgzXSBMb2FkaW5nIFNlYUJJT1MgLi4u
CihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjE4M10gQ3JlYXRpbmcgTVAgdGFibGVzIC4u
LgooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xODNdIExvYWRpbmcgQUNQSSAuLi4KKGQx
NikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTg0XSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE2
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xODVdIEJJT1MgbWFwOgooZDE2KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0MS4xODVdICAxMDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE2KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0MS4xODVdICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTYpIFsy
MDE0LTExLTE3IDE3OjQ3OjQxLjE4NV0gRTgyMCB0YWJsZToKKGQxNikgWzIwMTQtMTEtMTcg
MTc6NDc6NDEuMTg1XSAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBh
MDAwMDogUkFNCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjE4NV0gIEhPTEU6IDAwMDAw
MDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwYzAwMDAKKGQxNikgWzIwMTQtMTEtMTcgMTc6
NDc6NDEuMTg1XSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAw
MDogUkVTRVJWRUQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTg1XSAgWzAyXTogMDAw
MDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDozZjgwMDAwMDogUkFNCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQxLjE4NV0gIEhPTEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6
ZmMwMDAwMDAKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTg1XSAgWzAzXTogMDAwMDAw
MDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxNikgWzIwMTQt
MTEtMTcgMTc6NDc6NDEuMTg1XSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE2KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0MS4xODhdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4
OGMtMjAxNDExMTdfMTgxNTQ3LXNlcnZlZXJzdGVydGplKQooZDE2KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0MS4xODhdIAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xODhdIEZvdW5kIFhl
biBoeXBlcnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMAooZDE2KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0MS4xODhdIFJ1bm5pbmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE2KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0MS4xODhdIHhlbjogY29weSBlODIwLi4uCihkMTYpIFsyMDE0LTExLTE3IDE3
OjQ3OjQxLjE4OF0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZTJlOSB0byAweDNmN2Fl
NGYwIChzaXplIDcyMjY3KQooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xOTBdIENQVSBN
aHo9MzIwMgooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xOTZdIEZvdW5kIDEwIFBDSSBk
ZXZpY2VzIChtYXggUENJIGJ1cyBpcyAwMCkKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEu
MTk2XSBBbGxvY2F0ZWQgWGVuIGh5cGVyY2FsbCBwYWdlIGF0IDNmN2ZmMDAwCihkMTYpIFsy
MDE0LTExLTE3IDE3OjQ3OjQxLjE5Nl0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS4xOTZdIHhlbjogY29weSBCSU9TIHRhYmxlcy4uLgooZDE2
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xOTZdIENvcHlpbmcgU01CSU9TIGVudHJ5IHBvaW50
IGZyb20gMHgwMDAxMDAxMCB0byAweDAwMGY1ZGUwCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3
OjQxLjE5Nl0gQ29weWluZyBNUFRBQkxFIGZyb20gMHhmYzAwMTFhMC9mYzAwMTFiMCB0byAw
eDAwMGY1Y2MwCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjE5Nl0gQ29weWluZyBQSVIg
ZnJvbSAweDAwMDEwMDMwIHRvIDB4MDAwZjVjNDAKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6
NDEuMTk2XSBDb3B5aW5nIEFDUEkgUlNEUCBmcm9tIDB4MDAwMTAwYjAgdG8gMHgwMDBmNWMx
MAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xOTZdIFVzaW5nIHBtdGltZXIsIGlvcG9y
dCAweGIwMDgKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTk2XSBTY2FuIGZvciBWR0Eg
b3B0aW9uIHJvbQooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4yMTNdIFJ1bm5pbmcgb3B0
aW9uIHJvbSBhdCBjMDAwOjAwMDMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMjIxXSBz
dGR2Z2EuYzoxNDc6ZDE2djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihk
MTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjI0N10gcG1tIGNhbGwgYXJnMT0wCihkMTYpIFsy
MDE0LTExLTE3IDE3OjQ3OjQxLjI0OF0gVHVybmluZyBvbiB2Z2EgdGV4dCBtb2RlIGNvbnNv
bGUKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzY0XSBTZWFCSU9TICh2ZXJzaW9uIHJl
bC0xLjcuNS0wLWdlNTE0ODhjLTIwMTQxMTE3XzE4MTU0Ny1zZXJ2ZWVyc3RlcnRqZSkKKGQx
NikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzc3XSBNYWNoaW5lIFVVSUQgYjAyNDU1MDktOTIw
NC00Yzk2LWJiNDItOThjMDIwYjEwZjA1CihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM3
N10gLzNmN2FkMDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEu
Mzc3XSB8M2Y3YWQwMDB8IFhIQ0kgaW5pdCBvbiBkZXYgMDA6MDUuMDogcmVncyBAIDB4ZjMy
NzAwMDAsIDQgcG9ydHMsIDMyIHNsb3RzLCAzMiBiCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3
OjQxLjM3N10geXRlIGNvbnRleHRzCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM3N10g
fDNmN2FkMDAwfCBYSENJICAgIGV4dGNhcCAweDEgQCBmMzI3MDUwMAooZDE2KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0MS4zNzddIHwzZjdhZDAwMHwgWEhDSSAgICBwcm90b2NvbCBVU0IgIDMu
MDAsIDIgcG9ydHMgKG9mZnNldCAxKSwgZGVmIDAKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6
NDEuMzc3XSB8M2Y3YWQwMDB8IFhIQ0kgICAgcHJvdG9jb2wgVVNCICAyLjAwLCAyIHBvcnRz
IChvZmZzZXQgMyksIGRlZiAwCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM3OF0gLzNm
N2FiMDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzc4XSAv
M2Y3YWEwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4zNzhd
IHwzZjdhZDAwMHwgVUhDSSBpbml0IG9uIGRldiAwMDowMS4yIChpbz1jMTQwKQooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS4zNzldIC8zZjdhOTAwMFwgU3RhcnQgdGhyZWFkCihkMTYp
IFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM3OV0gLzNmN2E4MDAwXCBTdGFydCB0aHJlYWQKKGQx
NikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzc5XSBGb3VuZCAwIGxwdCBwb3J0cwooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS4zODBdIEZvdW5kIDEgc2VyaWFsIHBvcnRzCihkMTYpIFsy
MDE0LTExLTE3IDE3OjQ3OjQxLjM4MF0gQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0LzAg
KGlycSAxNCBkZXYgOSkKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzgwXSAvM2Y3YTcw
MDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4zODJdIFwzZjdh
ZDAwMC8gRW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4zODJdIC8zZjdh
NjAwMFwgU3RhcnQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM4Ml0gXDNm
N2E2MDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM4Ml0gQVRB
IGNvbnRyb2xsZXIgMiBhdCAxNzAvMzc0LzAgKGlycSAxNSBkZXYgOSkKKGQxNikgWzIwMTQt
MTEtMTcgMTc6NDc6NDEuMzgyXSAvM2Y3YTYwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0MS4zODNdIFwzZjdhNjAwMC8gRW5kIHRocmVhZAooZDE2KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0MS4zODVdIHwzZjdhNzAwMHwgYXRhMC0wOiBRRU1VIEhBUkRESVNL
IEFUQS03IEhhcmQtRGlzayAoMTAyNDAgTWlCeXRlcykKKGQxNikgWzIwMTQtMTEtMTcgMTc6
NDc6NDEuMzg1XSB8M2Y3YTcwMDB8IFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkw
Y2Y4LypAMSwxL2RyaXZlQDAvZGlza0AwCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM4
N10gfDNmN2E3MDAwfCBhdGEwLTE6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgz
MDAgR2lCeXRlcykKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzg3XSB8M2Y3YTcwMDB8
IFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4LypAMSwxL2RyaXZlQDAvZGlz
a0AxCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM4N10gXDNmN2E3MDAwLyBFbmQgdGhy
ZWFkCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjQ0Nl0gfDNmN2E4MDAwfCB1c2JfaGlk
X3NldHVwIDB4M2Y3YWRkYmMKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNDQ2XSBcM2Y3
YTgwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNDQ3XSBcM2Y3
YTkwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNDgxXSAvM2Y3
YTkwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS40ODFdIFwz
ZjdhOTAwMC8gRW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS40ODFdIC8z
ZjdhOTAwMFwgU3RhcnQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjQ4MV0g
XDNmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjQ4Ml0g
LzNmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNDgy
XSBcM2Y3YTkwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNDgy
XSAvM2Y3YTkwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS40
ODVdIHwzZjdhYTAwMHwgUFMyIGtleWJvYXJkIGluaXRpYWxpemVkCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQxLjQ4NV0gXDNmN2FhMDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQxLjUzMl0gfDNmN2E5MDAwfCBYSENJIHBvcnQgIzQ6IDB4MDAyMDBhMDMs
IHBvd2VyZWQsIGVuYWJsZWQsIHBscyAwLCBzcGVlZCAyIFtMb3ddCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQxLjU2Ml0gfDNmN2E5MDAwfCB1c2JfaGlkX3NldHVwIDB4M2Y3ZmVjMjAK
KGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNTYyXSBcM2Y3YTkwMDAvIEVuZCB0aHJlYWQK
KGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNTYzXSB8M2Y3YWIwMDB8IFhIQ0kgbm8gZGV2
aWNlcyBmb3VuZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS41NjhdIFwzZjdhYjAwMC8g
RW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS41NjhdIEFsbCB0aHJlYWRz
IGNvbXBsZXRlLgooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS41NjhdIFNjYW4gZm9yIG9w
dGlvbiByb21zCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjU5NV0gUnVubmluZyBvcHRp
b24gcm9tIGF0IGM5ODA6MDAwMwooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MDFdIHBt
bSBjYWxsIGFyZzE9MQooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MDFdIHBtbSBjYWxs
IGFyZzE9MAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MDNdIHBtbSBjYWxsIGFyZzE9
MQooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MDNdIHBtbSBjYWxsIGFyZzE9MAooZDE2
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MjBdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAv
cGNpQGkwY2Y4LypANAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MjBdIAooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS42MjddIFByZXNzIEYxMiBmb3IgYm9vdCBtZW51LgooZDE2
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MjddIAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0
NC4xODRdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTYpIFsyMDE0LTExLTE3
IDE3OjQ3OjQ0LjE4NF0gZHJpdmUgMHgwMDBmNWJjMDogUENIUz0xNjM4My8xNi82MyB0cmFu
c2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQ0LjE4NF0gZHJpdmUgMHgwMDBmNWI5MDogUENIUz0xNjM4My8xNi82MyB0
cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTYyOTE0NTYwMAooZDE2KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0NC4xODRdIAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0NC4xODRd
IFNwYWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjU2MDAtZjViOTAKKGQx
NikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTg0XSBSZXR1cm5lZCAyNTM5NTIgYnl0ZXMgb2Yg
Wm9uZUhpZ2gKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTg0XSBlODIwIG1hcCBoYXMg
NiBpdGVtczoKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTg1XSAgIDA6IDAwMDAwMDAw
MDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0KKGQxNikgWzIwMTQtMTEtMTcg
MTc6NDc6NDQuMTg1XSAgIDE6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEwMDAw
ID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0NC4xODVdICAgMjogMDAw
MDAwMDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgPSAyIFJFU0VSVkVECihkMTYpIFsy
MDE0LTExLTE3IDE3OjQ3OjQ0LjE4NV0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAw
MDAzZjdmZTAwMCA9IDEgUkFNCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQ0LjE4NV0gICA0
OiAwMDAwMDAwMDNmN2ZlMDAwIC0gMDAwMDAwMDAzZjgwMDAwMCA9IDIgUkVTRVJWRUQKKGQx
NikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTg1XSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAgLSAw
MDAwMDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0
NC4xODZdIGVudGVyIGhhbmRsZV8xOToKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTg2
XSAgIE5VTEwKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTkyXSBCb290aW5nIGZyb20g
SGFyZCBEaXNrLi4uCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQ0LjE5NF0gQm9vdGluZyBm
cm9tIDAwMDA6N2MwMAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0Ni4wMDldIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQ3LjA4OV0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2
MyBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA3IGZyYW1lcwooWEVOKSBbMjAxNC0xMS0x
NyAxNzo0Nzo0OC44OThdIGlvLmM6NTUwOiBkMTc6IGJpbmQ6IG1fZ3NpPTQwIGdfZ3NpPTM2
IGRldj0wMC4wMC41IGludHg9MAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMDJdIEFN
RC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHg0MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMwooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMDJdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NDAwLCB0eXBlID0gMHgxLCByb290IHRh
YmxlID0gMHgzZGE0OTQwMDAsIGRvbWFpbiA9IDE3LCBwYWdpbmcgbW9kZSA9IDMKKFhFTikg
WzIwMTQtMTEtMTcgMTc6NDc6NDkuMTAyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjA0OjAw
LjAgZnJvbSBkb20wIHRvIGRvbTE3CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjExMV0g
SFZNIExvYWRlcgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMTFdIERldGVjdGVkIFhl
biB2NC41LjAtcmMKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMTEyXSBYZW5idXMgcmlu
Z3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgMQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0
Nzo0OS4xMTJdIFN5c3RlbSByZXF1ZXN0ZWQgU2VhQklPUwooZDE3KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0OS4xMTJdIENQVSBzcGVlZCBpcyAzMjAwIE1IegooZDE3KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0OS4xMTJdIFJlbG9jYXRpbmcgZ3Vlc3QgbWVtb3J5IGZvciBsb3dtZW0gTU1JTyBz
cGFjZSBkaXNhYmxlZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMTJdIGlycS5jOjI3
MDogRG9tMTcgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQooZDE3KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0OS4xMTJdIFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1CihYRU4pIFsyMDE0
LTExLTE3IDE3OjQ3OjQ5LjExM10gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAxIGNoYW5n
ZWQgMCAtPiAxMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMTNdIFBDSS1JU0EgbGlu
ayAxIHJvdXRlZCB0byBJUlExMAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMTNdIGly
cS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTEKKGQxNykgWzIwMTQt
MTEtMTcgMTc6NDc6NDkuMTEzXSBQQ0ktSVNBIGxpbmsgMiByb3V0ZWQgdG8gSVJRMTEKKFhF
TikgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMTEzXSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5r
IDMgY2hhbmdlZCAwIC0+IDUKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMTEzXSBQQ0kt
SVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4x
MzNdIHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0
OS4xMzldIHBjaSBkZXYgMDI6MCBJTlRBLT5JUlExMQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0
Nzo0OS4xNTBdIHBjaSBkZXYgMDQ6MCBJTlRBLT5JUlE1CihkMTcpIFsyMDE0LTExLTE3IDE3
OjQ3OjQ5LjE1Nl0gcGNpIGRldiAwNTowIElOVEEtPklSUTEwCihkMTcpIFsyMDE0LTExLTE3
IDE3OjQ3OjQ5LjIwNl0gTm8gUkFNIGluIGhpZ2ggbWVtb3J5OyBzZXR0aW5nIGhpZ2hfbWVt
IHJlc291cmNlIGJhc2UgdG8gMTAwMDAwMDAwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5
LjIwNl0gcGNpIGRldiAwMzowIGJhciAxMCBzaXplIDAwMjAwMDAwMDogMGYwMDAwMDA4Cihk
MTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjIwOF0gcGNpIGRldiAwMjowIGJhciAxNCBzaXpl
IDAwMTAwMDAwMDogMGYyMDAwMDA4CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjIxMF0g
cGNpIGRldiAwNDowIGJhciAzMCBzaXplIDAwMDA0MDAwMDogMGYzMDAwMDAwCihkMTcpIFsy
MDE0LTExLTE3IDE3OjQ3OjQ5LjIxMl0gcGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAwMDAy
MDAwMDogMGYzMDQwMDAwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjIxMl0gcGNpIGRl
diAwMzowIGJhciAzMCBzaXplIDAwMDAxMDAwMDogMGYzMDYwMDAwCihkMTcpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQ5LjIxMl0gcGNpIGRldiAwNTowIGJhciAxMCBzaXplIDAwMDAwMjAwMDog
MGYzMDcwMDA0CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjIxM10gbWVtb3J5X21hcDph
ZGQ6IGRvbTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9MQooZDE3KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0OS4yMThdIHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDA6IDBmMzA3
MjAwMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yMTldIHBjaSBkZXYgMDI6MCBiYXIg
MTAgc2l6ZSAwMDAwMDAxMDA6IDAwMDAwYzAwMQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0
OS4yMjFdIHBjaSBkZXYgMDQ6MCBiYXIgMTQgc2l6ZSAwMDAwMDAwNDA6IDAwMDAwYzEwMQoo
ZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yMjNdIHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6
ZSAwMDAwMDAwMTA6IDAwMDAwYzE0MQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yMjVd
ID8hPyE/IT8hPyBlbmFibGUgSU8gb24gcHJpbWFyeSB2Z2EgcGNpIGRldiAwMzowIAooZDE3
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yMjVdIE11bHRpcHJvY2Vzc29yIGluaXRpYWxpc2F0
aW9uOgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yNDhdICAtIENQVTAgLi4uIDQ4LWJp
dCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLgoo
ZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yNzJdICAtIENQVTEgLi4uIDQ4LWJpdCBwaHlz
IC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLgooZDE3KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0OS4yOTddICAtIENQVTIgLi4uIDQ4LWJpdCBwaHlzIC4uLiBm
aXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLgooZDE3KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0OS4yOTddIFRlc3RpbmcgSFZNIGVudmlyb25tZW50OgooZDE3KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0OS4zMDZdICAtIFJFUCBJTlNCIGFjcm9zcyBwYWdlIGJvdW5kYXJp
ZXMgLi4uIHBhc3NlZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMTFdICAtIEdTIGJh
c2UgTVNScyBhbmQgU1dBUEdTIC4uLiBwYXNzZWQKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6
NDkuMzExXSBQYXNzZWQgMiBvZiAyIHRlc3RzCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5
LjMxMV0gV3JpdGluZyBTTUJJT1MgdGFibGVzIC4uLgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0
Nzo0OS4zMTJdIExvYWRpbmcgU2VhQklPUyAuLi4KKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6
NDkuMzEyXSBDcmVhdGluZyBNUCB0YWJsZXMgLi4uCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3
OjQ5LjMxMl0gTG9hZGluZyBBQ1BJIC4uLgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4z
MTNdIHZtODYgVFNTIGF0IGZjMDBhMjAwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMx
NF0gQklPUyBtYXA6CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxNF0gIDEwMDAwLTEw
MGQzOiBTY3JhdGNoIHNwYWNlCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxNF0gIGMw
MDAwLWZmZmZmOiBNYWluIEJJT1MKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMzE0XSBF
ODIwIHRhYmxlOgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMTRdICBbMDBdOiAwMDAw
MDAwMDowMDAwMDAwMCAtIDAwMDAwMDAwOjAwMGEwMDAwOiBSQU0KKGQxNykgWzIwMTQtMTEt
MTcgMTc6NDc6NDkuMzE0XSAgSE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDow
MDBjMDAwMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMTRdICBbMDFdOiAwMDAwMDAw
MDowMDBjMDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBSRVNFUlZFRAooZDE3KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0OS4zMTRdICBbMDJdOiAwMDAwMDAwMDowMDEwMDAwMCAtIDAwMDAwMDAw
OjFmODAwMDAwOiBSQU0KKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMzE0XSAgSE9MRTog
MDAwMDAwMDA6MWY4MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMAooZDE3KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0OS4zMTRdICBbMDNdOiAwMDAwMDAwMDpmYzAwMDAwMCAtIDAwMDAwMDAxOjAw
MDAwMDAwOiBSRVNFUlZFRAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMTVdIEludm9r
aW5nIFNlYUJJT1MgLi4uCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxN10gU2VhQklP
UyAodmVyc2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTExN18xODE1NDctc2VydmVl
cnN0ZXJ0amUpCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxN10gCihkMTcpIFsyMDE0
LTExLTE3IDE3OjQ3OjQ5LjMxN10gRm91bmQgWGVuIGh5cGVydmlzb3Igc2lnbmF0dXJlIGF0
IDQwMDAwMDAwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxOF0gUnVubmluZyBvbiBR
RU1VIChpNDQwZngpCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxOF0geGVuOiBjb3B5
IGU4MjAuLi4KKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMzE4XSBSZWxvY2F0aW5nIGlu
aXQgZnJvbSAweDAwMGRlMmU5IHRvIDB4MWY3YWU0ZjAgKHNpemUgNzIyNjcpCihkMTcpIFsy
MDE0LTExLTE3IDE3OjQ3OjQ5LjMyMF0gQ1BVIE1oej0zMjAxCihkMTcpIFsyMDE0LTExLTE3
IDE3OjQ3OjQ5LjMyNl0gRm91bmQgOCBQQ0kgZGV2aWNlcyAobWF4IFBDSSBidXMgaXMgMDAp
CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMyNl0gQWxsb2NhdGVkIFhlbiBoeXBlcmNh
bGwgcGFnZSBhdCAxZjdmZjAwMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMjZdIERl
dGVjdGVkIFhlbiB2NC41LjAtcmMKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMzI2XSB4
ZW46IGNvcHkgQklPUyB0YWJsZXMuLi4KKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMzI2
XSBDb3B5aW5nIFNNQklPUyBlbnRyeSBwb2ludCBmcm9tIDB4MDAwMTAwMTAgdG8gMHgwMDBm
NWRlMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMjZdIENvcHlpbmcgTVBUQUJMRSBm
cm9tIDB4ZmMwMDExODAvZmMwMDExOTAgdG8gMHgwMDBmNWNkMAooZDE3KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0OS4zMjZdIENvcHlpbmcgUElSIGZyb20gMHgwMDAxMDAzMCB0byAweDAwMGY1
YzUwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMyNl0gQ29weWluZyBBQ1BJIFJTRFAg
ZnJvbSAweDAwMDEwMGIwIHRvIDB4MDAwZjVjMjAKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6
NDkuMzI2XSBVc2luZyBwbXRpbWVyLCBpb3BvcnQgMHhiMDA4CihkMTcpIFsyMDE0LTExLTE3
IDE3OjQ3OjQ5LjMyNl0gU2NhbiBmb3IgVkdBIG9wdGlvbiByb20KKGQxNykgWzIwMTQtMTEt
MTcgMTc6NDc6NDkuMzQxXSBSdW5uaW5nIG9wdGlvbiByb20gYXQgYzAwMDowMDAzCihYRU4p
IFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjM1MF0gc3RkdmdhLmM6MTQ3OmQxN3YwIGVudGVyaW5n
IHN0ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4z
NzddIHBtbSBjYWxsIGFyZzE9MAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zNzhdIFR1
cm5pbmcgb24gdmdhIHRleHQgbW9kZSBjb25zb2xlCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3
OjQ5LjUwMV0gU2VhQklPUyAodmVyc2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTEx
N18xODE1NDctc2VydmVlcnN0ZXJ0amUpCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjUx
NF0gTWFjaGluZSBVVUlEIDdkMzhhZDM0LTNmZWUtNDdjZS05ZTNiLTg0Yjc1MGMyNmMwYgoo
ZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS41MTRdIC8xZjdhZDAwMFwgU3RhcnQgdGhyZWFk
CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjUxNV0gfDFmN2FkMDAwfCBYSENJIGluaXQg
b24gZGV2IDAwOjA1LjA6IHJlZ3MgQCAweGYzMDcwMDAwLCA0IHBvcnRzLCAzMiBzbG90cywg
MzIgYgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS41MTVdIHl0ZSBjb250ZXh0cwooZDE3
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS41MTVdIHwxZjdhZDAwMHwgWEhDSSAgICBleHRjYXAg
MHgxIEAgZjMwNzA1MDAKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNTE1XSB8MWY3YWQw
MDB8IFhIQ0kgICAgcHJvdG9jb2wgVVNCICAzLjAwLCAyIHBvcnRzIChvZmZzZXQgMSksIGRl
ZiAwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjUxNV0gfDFmN2FkMDAwfCBYSENJICAg
IHByb3RvY29sIFVTQiAgMi4wMCwgMiBwb3J0cyAob2Zmc2V0IDMpLCBkZWYgMAooZDE3KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0OS41MTVdIC8xZjdhYzAwMFwgU3RhcnQgdGhyZWFkCihkMTcp
IFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjUxNV0gLzFmN2FhMDAwXCBTdGFydCB0aHJlYWQKKGQx
NykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNTE2XSBcMWY3YWQwMDAvIEVuZCB0aHJlYWQKKGQx
NykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNTE2XSBGb3VuZCAwIGxwdCBwb3J0cwooZDE3KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0OS41MTZdIEZvdW5kIDEgc2VyaWFsIHBvcnRzCihkMTcpIFsy
MDE0LTExLTE3IDE3OjQ3OjQ5LjUxNl0gQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0LzAg
KGlycSAxNCBkZXYgOSkKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNTE3XSAvMWY3YTkw
MDBcIFN0YXJ0IHRocmVhZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS41MTddIEFUQSBj
b250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUgZGV2IDkpCihkMTcpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQ5LjUxN10gLzFmN2E4MDAwXCBTdGFydCB0aHJlYWQKKGQxNykgWzIwMTQt
MTEtMTcgMTc6NDc6NDkuNTE4XSBcMWY3YTgwMDAvIEVuZCB0aHJlYWQKKGQxNykgWzIwMTQt
MTEtMTcgMTc6NDc6NDkuNTIyXSB8MWY3YTkwMDB8IGF0YTAtMDogUUVNVSBIQVJERElTSyBB
VEEtNyBIYXJkLURpc2sgKDUxMjAgTWlCeXRlcykKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6
NDkuNTIyXSB8MWY3YTkwMDB8IFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4
LypAMSwxL2RyaXZlQDAvZGlza0AwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjUyM10g
XDFmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjYxNl0g
LzFmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNjE2
XSBcMWY3YTkwMDAvIEVuZCB0aHJlYWQKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNjE2
XSAvMWY3YTkwMDBcIFN0YXJ0IHRocmVhZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS42
MTZdIFwxZjdhOTAwMC8gRW5kIHRocmVhZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS42
MTZdIC8xZjdhOTAwMFwgU3RhcnQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5
LjYxNl0gXDFmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5
LjYxNl0gLzFmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6
NDkuNjIwXSB8MWY3YWEwMDB8IFBTMiBrZXlib2FyZCBpbml0aWFsaXplZAooZDE3KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0OS42MjBdIFwxZjdhYTAwMC8gRW5kIHRocmVhZAooZDE3KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0OS42NjddIHwxZjdhOTAwMHwgWEhDSSBwb3J0ICM0OiAweDAwMjAw
ZTAzLCBwb3dlcmVkLCBlbmFibGVkLCBwbHMgMCwgc3BlZWQgMyBbSGlnaF0KKGQxNykgWzIw
MTQtMTEtMTcgMTc6NDc6NDkuNjgxXSBcMWY3YTkwMDAvIEVuZCB0aHJlYWQKKGQxNykgWzIw
MTQtMTEtMTcgMTc6NDc6NDkuNjgxXSB8MWY3YWMwMDB8IFhIQ0kgbm8gZGV2aWNlcyBmb3Vu
ZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS42ODhdIFwxZjdhYzAwMC8gRW5kIHRocmVh
ZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS42ODhdIEFsbCB0aHJlYWRzIGNvbXBsZXRl
LgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS42ODhdIFNjYW4gZm9yIG9wdGlvbiByb21z
CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjcxM10gUnVubmluZyBvcHRpb24gcm9tIGF0
IGM5ODA6MDAwMwooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS43MjBdIHBtbSBjYWxsIGFy
ZzE9MQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS43MjBdIHBtbSBjYWxsIGFyZzE9MAoo
ZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS43MjFdIHBtbSBjYWxsIGFyZzE9MQooZDE3KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0OS43MjJdIHBtbSBjYWxsIGFyZzE9MAooZDE3KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0OS43MzldIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4
LypANAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS43MzldIAooZDE3KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0OS43NDZdIFByZXNzIEYxMiBmb3IgYm9vdCBtZW51LgooZDE3KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0OS43NDddIAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo1MC44MjZdIHN0
ZHZnYS5jOjE1MTpkMTZ2MCBsZWF2aW5nIHN0ZHZnYQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0
Nzo1Mi4zMTNdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTcpIFsyMDE0LTEx
LTE3IDE3OjQ3OjUyLjMxM10gZHJpdmUgMHgwMDBmNWJkMDogUENIUz0xMDQwMi8xNi82MyB0
cmFuc2xhdGlvbj1sYmEgTENIUz02NTIvMjU1LzYzIHM9MTA0ODU3NjAKKGQxNykgWzIwMTQt
MTEtMTcgMTc6NDc6NTIuMzEzXSBTcGFjZSBhdmFpbGFibGUgZm9yIFVNQjogY2E4MDAtZWYw
MDAsIGY1NjAwLWY1YmQwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUyLjMxM10gUmV0dXJu
ZWQgMjUzOTUyIGJ5dGVzIG9mIFpvbmVIaWdoCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUy
LjMxM10gZTgyMCBtYXAgaGFzIDYgaXRlbXM6CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUy
LjMxM10gICAwOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZmMwMCA9IDEgUkFN
CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUyLjMxM10gICAxOiAwMDAwMDAwMDAwMDlmYzAw
IC0gMDAwMDAwMDAwMDBhMDAwMCA9IDIgUkVTRVJWRUQKKGQxNykgWzIwMTQtMTEtMTcgMTc6
NDc6NTIuMzEzXSAgIDI6IDAwMDAwMDAwMDAwZjAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwID0g
MiBSRVNFUlZFRAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo1Mi4zMTNdICAgMzogMDAwMDAw
MDAwMDEwMDAwMCAtIDAwMDAwMDAwMWY3ZmUwMDAgPSAxIFJBTQooZDE3KSBbMjAxNC0xMS0x
NyAxNzo0Nzo1Mi4zMTRdICAgNDogMDAwMDAwMDAxZjdmZTAwMCAtIDAwMDAwMDAwMWY4MDAw
MDAgPSAyIFJFU0VSVkVECihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUyLjMxNF0gICA1OiAw
MDAwMDAwMGZjMDAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCA9IDIgUkVTRVJWRUQKKGQxNykg
WzIwMTQtMTEtMTcgMTc6NDc6NTIuMzE0XSBlbnRlciBoYW5kbGVfMTk6CihkMTcpIFsyMDE0
LTExLTE3IDE3OjQ3OjUyLjMxNV0gICBOVUxMCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUy
LjMyMV0gQm9vdGluZyBmcm9tIEhhcmQgRGlzay4uLgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0
Nzo1Mi4zMjNdIEJvb3RpbmcgZnJvbSAwMDAwOjdjMDAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6
NDc6NTUuNDg2XSBIVk0gTG9hZGVyCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1LjQ4Nl0g
RGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS40ODZd
IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCAxCihkMTgpIFsyMDE0
LTExLTE3IDE3OjQ3OjU1LjQ4N10gU3lzdGVtIHJlcXVlc3RlZCBTZWFCSU9TCihkMTgpIFsy
MDE0LTExLTE3IDE3OjQ3OjU1LjQ4N10gQ1BVIHNwZWVkIGlzIDMyMDAgTUh6CihkMTgpIFsy
MDE0LTExLTE3IDE3OjQ3OjU1LjQ4N10gUmVsb2NhdGluZyBndWVzdCBtZW1vcnkgZm9yIGxv
d21lbSBNTUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjU1LjQ4
N10gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1CihkMTgpIFsy
MDE0LTExLTE3IDE3OjQ3OjU1LjQ4N10gUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNDg3XSBpcnEuYzoyNzA6IERvbTE4IFBDSSBs
aW5rIDEgY2hhbmdlZCAwIC0+IDEwCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1LjQ4N10g
UENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3
OjU1LjQ4N10gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAyIGNoYW5nZWQgMCAtPiAxMQoo
ZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS40ODddIFBDSS1JU0EgbGluayAyIHJvdXRlZCB0
byBJUlExMQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS40ODhdIGlycS5jOjI3MDogRG9t
MTggUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1
NS40ODhdIFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1CihkMTgpIFsyMDE0LTExLTE3
IDE3OjQ3OjU1LjUwNV0gcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihkMTgpIFsyMDE0LTEx
LTE3IDE3OjQ3OjU1LjUwOV0gcGNpIGRldiAwMjowIElOVEEtPklSUTExCihkMTgpIFsyMDE0
LTExLTE3IDE3OjQ3OjU1LjUxOV0gcGNpIGRldiAwNDowIElOVEEtPklSUTUKKGQxOCkgWzIw
MTQtMTEtMTcgMTc6NDc6NTUuNTY2XSBObyBSQU0gaW4gaGlnaCBtZW1vcnk7IHNldHRpbmcg
aGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDAKKGQxOCkgWzIwMTQtMTEtMTcg
MTc6NDc6NTUuNTY2XSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAyMDAwMDAwOiAwZjAw
MDAwMDgKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTY4XSBwY2kgZGV2IDAyOjAgYmFy
IDE0IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6
NTUuNTcwXSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUgMDAwMDQwMDAwOiAwZjMwMDAwMDAK
KGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTcyXSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNp
emUgMDAwMDIwMDAwOiAwZjMwNDAwMDAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTcy
XSBwY2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEwMDAwOiAwZjMwNjAwMDAKKGQxOCkg
WzIwMTQtMTEtMTcgMTc6NDc6NTUuNTc0XSBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDAw
MDAxMDAwOiAwZjMwNzAwMDAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTc0XSBwY2kg
ZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDEKKGQxOCkgWzIwMTQt
MTEtMTcgMTc6NDc6NTUuNTc2XSBwY2kgZGV2IDA0OjAgYmFyIDE0IHNpemUgMDAwMDAwMDQw
OiAwMDAwMGMxMDEKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTc4XSBwY2kgZGV2IDAx
OjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNDEKKGQxOCkgWzIwMTQtMTEtMTcg
MTc6NDc6NTUuNTgwXSA/IT8hPyE/IT8gZW5hYmxlIElPIG9uIHByaW1hcnkgdmdhIHBjaSBk
ZXYgMDM6MCAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTgwXSBNdWx0aXByb2Nlc3Nv
ciBpbml0aWFsaXNhdGlvbjoKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTk5XSAgLSBD
UFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84
XSAuLi4gZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjE1XSAgLSBDUFUxIC4u
LiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4g
ZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjMzXSAgLSBDUFUyIC4uLiA0OC1i
aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4K
KGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjUyXSAgLSBDUFUzIC4uLiA0OC1iaXQgcGh5
cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxOCkg
WzIwMTQtMTEtMTcgMTc6NDc6NTUuNjUyXSBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoKKGQx
OCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjYxXSAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBi
b3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjY2XSAg
LSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCihkMTgpIFsyMDE0LTExLTE3
IDE3OjQ3OjU1LjY2Nl0gUGFzc2VkIDIgb2YgMiB0ZXN0cwooZDE4KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo1NS42NjZdIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KKGQxOCkgWzIwMTQtMTEt
MTcgMTc6NDc6NTUuNjY3XSBMb2FkaW5nIFNlYUJJT1MgLi4uCihkMTgpIFsyMDE0LTExLTE3
IDE3OjQ3OjU1LjY2N10gQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgooZDE4KSBbMjAxNC0xMS0x
NyAxNzo0Nzo1NS42NjddIExvYWRpbmcgQUNQSSAuLi4KKGQxOCkgWzIwMTQtMTEtMTcgMTc6
NDc6NTUuNjY4XSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE4KSBbMjAxNC0xMS0xNyAxNzo0
Nzo1NS42NjldIEJJT1MgbWFwOgooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NjldICAx
MDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42
NjldICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1
LjY2OV0gRTgyMCB0YWJsZToKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjY5XSAgWzAw
XTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkFNCihkMTgpIFsy
MDE0LTExLTE3IDE3OjQ3OjU1LjY2OV0gIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAw
MDAwMDA6MDAwYzAwMDAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjY5XSAgWzAxXTog
MDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQKKGQxOCkg
WzIwMTQtMTEtMTcgMTc6NDc6NTUuNjY5XSAgWzAyXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAw
MDAwMDAwMDozZjgwMDAwMDogUkFNCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1LjY2OV0g
IEhPTEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAwMDAKKGQxOCkgWzIw
MTQtMTEtMTcgMTc6NDc6NTUuNjY5XSAgWzAzXTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAw
MDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjY5
XSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzJd
IFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMTdfMTgxNTQ3
LXNlcnZlZXJzdGVydGplKQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzJdIAooZDE4
KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzJdIEZvdW5kIFhlbiBoeXBlcnZpc29yIHNpZ25h
dHVyZSBhdCA0MDAwMDAwMAooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzJdIFJ1bm5p
bmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzJdIHhl
bjogY29weSBlODIwLi4uCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1LjY3Ml0gUmVsb2Nh
dGluZyBpbml0IGZyb20gMHgwMDBkZTJlOSB0byAweDNmN2FlNGYwIChzaXplIDcyMjY3KQoo
ZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzVdIENQVSBNaHo9MzIwMQooZDE4KSBbMjAx
NC0xMS0xNyAxNzo0Nzo1NS42ODBdIEZvdW5kIDcgUENJIGRldmljZXMgKG1heCBQQ0kgYnVz
IGlzIDAwKQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42ODBdIEFsbG9jYXRlZCBYZW4g
aHlwZXJjYWxsIHBhZ2UgYXQgM2Y3ZmYwMDAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUu
NjgwXSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1
LjY4MF0geGVuOiBjb3B5IEJJT1MgdGFibGVzLi4uCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3
OjU1LjY4MF0gQ29weWluZyBTTUJJT1MgZW50cnkgcG9pbnQgZnJvbSAweDAwMDEwMDEwIHRv
IDB4MDAwZjVkZTAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjgwXSBDb3B5aW5nIE1Q
VEFCTEUgZnJvbSAweGZjMDAxMWEwL2ZjMDAxMWIwIHRvIDB4MDAwZjVjYzAKKGQxOCkgWzIw
MTQtMTEtMTcgMTc6NDc6NTUuNjgwXSBDb3B5aW5nIFBJUiBmcm9tIDB4MDAwMTAwMzAgdG8g
MHgwMDBmNWM0MAooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42ODBdIENvcHlpbmcgQUNQ
SSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAwMGY1YzEwCihkMTgpIFsyMDE0LTExLTE3
IDE3OjQ3OjU1LjY4MF0gVXNpbmcgcG10aW1lciwgaW9wb3J0IDB4YjAwOAooZDE4KSBbMjAx
NC0xMS0xNyAxNzo0Nzo1NS42ODBdIFNjYW4gZm9yIFZHQSBvcHRpb24gcm9tCihkMTgpIFsy
MDE0LTExLTE3IDE3OjQ3OjU1LjY5Nl0gUnVubmluZyBvcHRpb24gcm9tIGF0IGMwMDA6MDAw
MwooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS43MDRdIHN0ZHZnYS5jOjE0NzpkMTh2MCBl
bnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMKKGQxOCkgWzIwMTQtMTEtMTcgMTc6
NDc6NTUuNzI2XSBwbW0gY2FsbCBhcmcxPTAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUu
NzI4XSBUdXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUgY29uc29sZQooZDE4KSBbMjAxNC0xMS0x
NyAxNzo0Nzo1NS44NDFdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMt
MjAxNDExMTdfMTgxNTQ3LXNlcnZlZXJzdGVydGplKQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0
Nzo1NS44NTRdIE1hY2hpbmUgVVVJRCBhNmUyY2Y3NC00YWZiLTRmM2MtOTc3NS0zOGNkZWRk
Zjc2ZjcKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuODU0XSAvM2Y3YWQwMDBcIFN0YXJ0
IHRocmVhZAooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS44NTRdIFwzZjdhZDAwMC8gRW5k
IHRocmVhZAooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS44NTRdIEFsbCB0aHJlYWRzIGNv
bXBsZXRlLgooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS44NTRdIC8zZjdhZDAwMFwgU3Rh
cnQgdGhyZWFkCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1Ljg1NV0gRm91bmQgMCBscHQg
cG9ydHMKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuODU1XSBGb3VuZCAwIHNlcmlhbCBw
b3J0cwooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS44NTZdIEFUQSBjb250cm9sbGVyIDEg
YXQgMWYwLzNmNC8wIChpcnEgMTQgZGV2IDkpCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1
Ljg1Nl0gLzNmN2FjMDAwXCBTdGFydCB0aHJlYWQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6
NTUuODU2XSBBVEEgY29udHJvbGxlciAyIGF0IDE3MC8zNzQvMCAoaXJxIDE1IGRldiA5KQoo
ZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS44NTZdIC8zZjdhYjAwMFwgU3RhcnQgdGhyZWFk
CihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1Ljg1N10gXDNmN2FiMDAwLyBFbmQgdGhyZWFk
CihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1Ljg2MV0gfDNmN2FjMDAwfCBhdGEwLTA6IFFF
TVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgxMDI0MCBNaUJ5dGVzKQooZDE4KSBbMjAx
NC0xMS0xNyAxNzo0Nzo1NS44NjFdIHwzZjdhYzAwMHwgU2VhcmNoaW5nIGJvb3RvcmRlciBm
b3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDAKKGQxOCkgWzIwMTQtMTEtMTcg
MTc6NDc6NTUuODYyXSBcM2Y3YWMwMDAvIEVuZCB0aHJlYWQKKGQxOCkgWzIwMTQtMTEtMTcg
MTc6NDc6NTUuOTU5XSB8M2Y3YWQwMDB8IFBTMiBrZXlib2FyZCBpbml0aWFsaXplZAooZDE4
KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS45NTldIFwzZjdhZDAwMC8gRW5kIHRocmVhZAooZDE4
KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS45NTldIEFsbCB0aHJlYWRzIGNvbXBsZXRlLgooZDE4
KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS45NTldIFNjYW4gZm9yIG9wdGlvbiByb21zCihkMTgp
IFsyMDE0LTExLTE3IDE3OjQ3OjU1Ljk4Ml0gUnVubmluZyBvcHRpb24gcm9tIGF0IGM5ODA6
MDAwMwooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS45ODhdIHBtbSBjYWxsIGFyZzE9MQoo
ZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS45ODhdIHBtbSBjYWxsIGFyZzE9MAooZDE4KSBb
MjAxNC0xMS0xNyAxNzo0Nzo1NS45ODldIHBtbSBjYWxsIGFyZzE9MQooZDE4KSBbMjAxNC0x
MS0xNyAxNzo0Nzo1NS45OTBdIHBtbSBjYWxsIGFyZzE9MAooZDE4KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo1Ni4wMDhdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4LypANAoo
ZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1Ni4wMDhdIAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0
Nzo1Ni4wMDldIC0tTUFSSy0tCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU2LjAxNV0gUHJl
c3MgRjEyIGZvciBib290IG1lbnUuCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU2LjAxNV0g
CihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU3NF0gU2VhcmNoaW5nIGJvb3RvcmRlciBm
b3I6IEhBTFQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTguNTc0XSBkcml2ZSAweDAwMGY1
YmMwOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1LzYz
IHM9MjA5NzE1MjAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTguNTc1XSBTcGFjZSBhdmFp
bGFibGUgZm9yIFVNQjogY2E4MDAtZWYwMDAsIGY1NjAwLWY1YmMwCihkMTgpIFsyMDE0LTEx
LTE3IDE3OjQ3OjU4LjU3NV0gUmV0dXJuZWQgMjU4MDQ4IGJ5dGVzIG9mIFpvbmVIaWdoCihk
MTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU3NV0gZTgyMCBtYXAgaGFzIDYgaXRlbXM6Cihk
MTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU3NV0gICAwOiAwMDAwMDAwMDAwMDAwMDAwIC0g
MDAwMDAwMDAwMDA5ZmMwMCA9IDEgUkFNCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU3
NV0gICAxOiAwMDAwMDAwMDAwMDlmYzAwIC0gMDAwMDAwMDAwMDBhMDAwMCA9IDIgUkVTRVJW
RUQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTguNTc1XSAgIDI6IDAwMDAwMDAwMDAwZjAw
MDAgLSAwMDAwMDAwMDAwMTAwMDAwID0gMiBSRVNFUlZFRAooZDE4KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo1OC41NzVdICAgMzogMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwM2Y3ZmYwMDAg
PSAxIFJBTQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1OC41NzVdICAgNDogMDAwMDAwMDAz
ZjdmZjAwMCAtIDAwMDAwMDAwM2Y4MDAwMDAgPSAyIFJFU0VSVkVECihkMTgpIFsyMDE0LTEx
LTE3IDE3OjQ3OjU4LjU3NV0gICA1OiAwMDAwMDAwMGZjMDAwMDAwIC0gMDAwMDAwMDEwMDAw
MDAwMCA9IDIgUkVTRVJWRUQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTguNTc2XSBlbnRl
ciBoYW5kbGVfMTk6CihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU3Nl0gICBOVUxMCihk
MTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU4Ml0gQm9vdGluZyBmcm9tIEhhcmQgRGlzay4u
LgooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1OC41ODRdIEJvb3RpbmcgZnJvbSAwMDAwOjdj
MDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6NTkuMjI3XSBzdGR2Z2EuYzoxNTE6ZDE3djAg
bGVhdmluZyBzdGR2Z2EKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MDUuMzE1XSBzdGR2Z2Eu
YzoxNTE6ZDE4djAgbGVhdmluZyBzdGR2Z2EKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MDYu
MDA5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoxNi4wMTBdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjE2Ljg2OV0gc3RkdmdhLmM6MTQ3OmQxNnYwIGVu
dGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooWEVOKSBbMjAxNC0xMS0xNyAxNzo0
ODoxOC40NzBdIGlycS5jOjM4MDogRG9tMTYgY2FsbGJhY2sgdmlhIGNoYW5nZWQgdG8gRGly
ZWN0IFZlY3RvciAweGYzCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjE4LjYzN10gc3Rkdmdh
LmM6MTQ3OmQxN3YwIGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooWEVOKSBb
MjAxNC0xMS0xNyAxNzo0ODoyMC4yNDRdIGlycS5jOjM4MDogRG9tMTcgY2FsbGJhY2sgdmlh
IGNoYW5nZWQgdG8gRGlyZWN0IFZlY3RvciAweGYzCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4
OjIxLjY0MF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUg
bnI9MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMS42NDRdIG1lbW9yeV9tYXA6YWRkOiBk
b20xNyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6
MjEuNjQ3XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTcgZ2ZuPWYzMDcwIG1mbj1mZGRmZSBu
cj0xCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIxLjY1MV0gbWVtb3J5X21hcDphZGQ6IGRv
bTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoy
MS42NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5y
PTEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjEuNjU4XSBtZW1vcnlfbWFwOmFkZDogZG9t
MTcgZ2ZuPWYzMDcwIG1mbj1mZGRmZSBucj0xCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIx
LjY2Ml0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9
MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMS42NjddIG1lbW9yeV9tYXA6YWRkOiBkb20x
NyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjEu
NjcwXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTcgZ2ZuPWYzMDcwIG1mbj1mZGRmZSBucj0x
CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIxLjY3NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE3
IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMS42
NzddIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5yPTEK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjEuNjgwXSBtZW1vcnlfbWFwOmFkZDogZG9tMTcg
Z2ZuPWYzMDcwIG1mbj1mZGRmZSBucj0xCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIxLjcw
MV0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCihYRU4pIFsy
MDE0LTExLTE3IDE3OjQ4OjIxLjcwOF0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAxIGNo
YW5nZWQgMTAgLT4gMAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMS43MTRdIGlycS5jOjI3
MDogRG9tMTcgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDAKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NDg6MjEuNzIwXSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDMgY2hhbmdlZCA1IC0+
IDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMDYxXSBtZW1vcnlfbWFwOnJlbW92ZTog
ZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4
OjIyLjA2Nl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9
MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMi4wNzBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBk
b20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6
MjIuMDc0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0x
CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIyLjA3N10gbWVtb3J5X21hcDpyZW1vdmU6IGRv
bTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoy
Mi4wODFdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMDg1XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9t
MTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIy
LjA4OV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQoo
WEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMi4wOTNdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20x
NiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIu
MDk3XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihY
RU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIyLjEwMV0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2
IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMi4x
MDVdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhF
TikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTE1XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYg
Z2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIu
MTIxXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTI2XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9t
MTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6
MjIuMTMxXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0y
MDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTM2XSBtZW1vcnlfbWFwOnJlbW92ZTog
ZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NDg6MjIuMTQyXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBu
cj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTQ4XSBtZW1vcnlfbWFwOnJlbW92
ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NDg6MjIuMTU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIw
MCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTYwXSBtZW1vcnlfbWFwOnJl
bW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEt
MTcgMTc6NDg6MjIuMTY3XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1m
ZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTcyXSBtZW1vcnlfbWFw
OnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQt
MTEtMTcgMTc6NDg6MjIuMTc5XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1m
bj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMjIxXSBpcnEuYzoy
NzA6IERvbTE2IFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDAKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NDg6MjIuMjMzXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAt
PiAwCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIyLjI0Nl0gaXJxLmM6MjcwOiBEb20xNiBQ
Q0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMi4y
NTldIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMAooWEVOKSBb
MjAxNC0xMS0xNyAxNzo0ODoyMy4wNjZdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjIgSW5jcmVh
c2VkIG1hcHRyYWNrIHNpemUgdG8gOCBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6
MjMuNjgwXSBncmFudF90YWJsZS5jOjEyOTk6ZDE2djIgRXhwYW5kaW5nIGRvbSAoMTYpIGdy
YW50IHRhYmxlIGZyb20gKDQpIHRvICg1KSBmcmFtZXMuCihYRU4pIFsyMDE0LTExLTE3IDE3
OjQ4OjI2LjAxMF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjcuNzgzXSBz
dGR2Z2EuYzoxNDc6ZDE4djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihY
RU4pIFsyMDE0LTExLTE3IDE3OjQ4OjI5LjQ0Ml0gaXJxLmM6MzgwOiBEb20xOCBjYWxsYmFj
ayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NDg6MzAuNjkyXSBpcnEuYzoyNzA6IERvbTE4IFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+
IDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MzAuNjk4XSBpcnEuYzoyNzA6IERvbTE4IFBD
SSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjMwLjcw
M10gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMAooWEVOKSBb
MjAxNC0xMS0xNyAxNzo0ODozMC43MDldIGlycS5jOjI3MDogRG9tMTggUENJIGxpbmsgMyBj
aGFuZ2VkIDUgLT4gMAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODozMi4wNThdIGdyYW50X3Rh
YmxlLmM6MTI5OTpkMTh2MSBFeHBhbmRpbmcgZG9tICgxOCkgZ3JhbnQgdGFibGUgZnJvbSAo
NCkgdG8gKDUpIGZyYW1lcy4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MzYuMDEwXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODo0NS40NjldIGdyYW50X3RhYmxlLmM6MzA1
OmQwdjEgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gOSBmcmFtZXMKKFhFTikgWzIwMTQt
MTEtMTcgMTc6NDg6NDYuMDEwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODo1
Ni4wMTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ5OjA2LjAxMF0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDk6MTYuMDEwXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xNyAxNzo0OToyNi4wMTFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ5
OjM2LjAxMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDk6NDYuMDExXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0OTo1Ni4wMTFdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE3IDE3OjUwOjA2LjAxMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTA6MTYuMDEyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1MDoyNi4wMTJdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjUwOjM2LjAxMl0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTcgMTc6NTA6NDYuMDEyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAx
Nzo1MDo1Ni4wMTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjUxOjA2LjAxM10g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTE6MTYuMDEzXSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1MToyMy42MzNdIGdyYW50X3RhYmxlLmM6MTI5OTpkMTZ2MCBF
eHBhbmRpbmcgZG9tICgxNikgZ3JhbnQgdGFibGUgZnJvbSAoNSkgdG8gKDYpIGZyYW1lcy4K
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTE6MjYuMDEzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xNyAxNzo1MTozMy43NzVdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1h
cHRyYWNrIHNpemUgdG8gMTAgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE3IDE3OjUxOjM2LjAx
M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTE6NDYuMDEzXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xNyAxNzo1MTo1Ni4wMTNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE3IDE3OjUyOjA1Ljc0Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTI6MTUu
NzQyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1MjoyNS43NDJdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE3IDE3OjUyOjM1Ljc0Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTcgMTc6NTI6NDUuNzQyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Mjo1
NS43NDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjUzOjA1Ljc0M10gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTM6MTUuNzQzXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1MzoyNS43NDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjUz
OjM1Ljc0M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTM6NDUuNzQ0XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Mzo1NS43NDRdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE3IDE3OjU0OjA1Ljc0NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTQ6MTUuNzQ0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDoxOC42OTVdIENQ
VTAwOiAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6MTguNzA1XSBDUFUwMTogCihYRU4pIFsy
MDE0LTExLTE3IDE3OjU0OjE4LjcxNl0gZDE2IE9LLXNvZnRpcnEgNjJtc2VjIGFnbywgc3Rh
dGU6MSwgMjYyOCBjb3VudCwgW3ByZXY6ZmZmZjgzMDU0ZWY1N2U3MCwgbmV4dDpmZmZmODMw
NTRlZjU3ZTcwXSBmZmZmODMwNTFiOTA0NDI4PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVTVF9N
U0lfU0hJRlQgIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6MTguNzY1XSBkMTYg
T0stcmFpc2UgICAxMTJtc2VjIGFnbywgc3RhdGU6MSwgMjYyOCBjb3VudCwgW3ByZXY6MDAw
MDAwMDAwMDIwMDIwMCwgbmV4dDowMDAwMDAwMDAwMTAwMTAwXSBmZmZmODMwNTFiOTA0NDI4
PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJUlE6ODcKKFhFTikgWzIw
MTQtMTEtMTcgMTc6NTQ6MTguODE1XSBDUFUwMjogCihYRU4pIFsyMDE0LTExLTE3IDE3OjU0
OjE4LjgyNV0gZDE3IE9LLXNvZnRpcnEgNTAwbXNlYyBhZ28sIHN0YXRlOjEsIDM0MzkgY291
bnQsIFtwcmV2OmZmZmY4MzA1NGVmNDdlNzAsIG5leHQ6ZmZmZjgzMDU0ZWY0N2U3MF0gZmZm
ZjgzMDUxYTFjOGMyODxOVUxMPiBNQVBQRURfU0hJRlQgR1VFU1RfTVNJX1NISUZUICBQSVJR
Ojg3CihYRU4pIFsyMDE0LTExLTE3IDE3OjU0OjE4Ljg3NV0gZDE3IE9LLXJhaXNlICAgNTQ5
bXNlYyBhZ28sIHN0YXRlOjEsIDM0MzkgY291bnQsIFtwcmV2OjAwMDAwMDAwMDAyMDAyMDAs
IG5leHQ6MDAwMDAwMDAwMDEwMDEwMF0gZmZmZjgzMDUxYTFjOGMyODxOVUxMPiBNQVBQRURf
U0hJRlQgR1VFU1RfTVNJX1NISUZUICBQSVJROjg3CihYRU4pIFsyMDE0LTExLTE3IDE3OjU0
OjE4LjkyNF0gQ1BVMDM6IAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDoxOC45MzVdIGQxNiBP
Sy1zb2Z0aXJxIDMxM21zZWMgYWdvLCBzdGF0ZToxLCAzNTMzIGNvdW50LCBbcHJldjpmZmZm
ODMwNTRlZjM3ZTcwLCBuZXh0OmZmZmY4MzA1NGVmMzdlNzBdIGZmZmY4MzA1MWI5MDQ0Mjg8
TlVMTD4gTUFQUEVEX1NISUZUIEdVRVNUX01TSV9TSElGVCAgUElSUTo4NwooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1NDoxOC45ODRdIGQxNiBPSy1yYWlzZSAgIDM2M21zZWMgYWdvLCBzdGF0
ZToxLCAzNTMzIGNvdW50LCBbcHJldjowMDAwMDAwMDAwMjAwMjAwLCBuZXh0OjAwMDAwMDAw
MDAxMDAxMDBdIGZmZmY4MzA1MWI5MDQ0Mjg8TlVMTD4gTUFQUEVEX1NISUZUIEdVRVNUX01T
SV9TSElGVCAgUElSUTo4NwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDoxOS4wMzRdIENQVTA0
OiAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6MTkuMDQ0XSBkMTYgT0stc29mdGlycSAzNTlt
c2VjIGFnbywgc3RhdGU6MSwgMzY5MSBjb3VudCwgW3ByZXY6ZmZmZjgzMDU0ZWYyN2U4OCwg
bmV4dDpmZmZmODMwNTRlZjI3ZTg4XSBmZmZmODMwNTFiOTA0NDI4PE5VTEw+IE1BUFBFRF9T
SElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6
MTkuMDk0XSBkMTYgT0stcmFpc2UgICA0MDhtc2VjIGFnbywgc3RhdGU6MSwgMzY5MSBjb3Vu
dCwgW3ByZXY6MDAwMDAwMDAwMDIwMDIwMCwgbmV4dDowMDAwMDAwMDAwMTAwMTAwXSBmZmZm
ODMwNTFiOTA0NDI4PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJUlE6
ODcKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6MTkuMTQzXSBDUFUwNTogCihYRU4pIFsyMDE0
LTExLTE3IDE3OjU0OjE5LjE1NF0gZDE2IE9LLXNvZnRpcnEgNDU4bXNlYyBhZ28sIHN0YXRl
OjEsIDUyMDM5IGNvdW50LCBbcHJldjpmZmZmODMwNTRlZjI4M2UwLCBuZXh0OmZmZmY4MzA1
NGVmMjgzZTBdIGZmZmY4MzA1MWI5NWZkMjhNQUNIX1BDSV9TSElGVCBNQVBQRURfU0hJRlQg
R1VFU1RfUENJX1NISUZUICBQSVJROjAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6MTkuMjA1
XSBkMTYgT0stcmFpc2UgICA0ODltc2VjIGFnbywgc3RhdGU6MSwgNTIwNDkgY291bnQsIFtw
cmV2OjAwMDAwMDAwMDAyMDAyMDAsIG5leHQ6MDAwMDAwMDAwMDEwMDEwMF0gZmZmZjgzMDUx
Yjk1ZmQyOE1BQ0hfUENJX1NISUZUIE1BUFBFRF9TSElGVCBHVUVTVF9QQ0lfU0hJRlQgIFBJ
UlE6MAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDoxOS4yNTddIGQxNiBFUlItcG9pc29uIDU2
MW1zZWMgYWdvLCBzdGF0ZTowLCAxIGNvdW50LCBbcHJldjowMDAwMDAwMDAwMjAwMjAwLCBu
ZXh0OjAwMDAwMDAwMDAxMDAxMDBdIGZmZmY4MzA1MWI5NWZkMjhNQUNIX1BDSV9TSElGVCBN
QVBQRURfU0hJRlQgR1VFU1RfUENJX1NISUZUICBQSVJROjAKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTQ6MTkuMzA3XSBkMTYgWi1zb2Z0aXJxICA3MzFtc2VjIGFnbywgc3RhdGU6MywgMyBj
b3VudCwgW3ByZXY6ZmZmZjgzMDU0ZWYyODNlMCwgbmV4dDpmZmZmODMwNTRlZjI4M2UwXSBm
ZmZmODMwNTFiOTVmZDI4TUFDSF9QQ0lfU0hJRlQgTUFQUEVEX1NISUZUIEdVRVNUX1BDSV9T
SElGVCAgUElSUTowCihYRU4pIFsyMDE0LTExLTE3IDE3OjU0OjE5LjM1Nl0gZG9tYWluX2Ny
YXNoIGNhbGxlZCBmcm9tIGlvLmM6OTM4CihYRU4pIFsyMDE0LTExLTE3IDE3OjU0OjE5LjM1
Nl0gRG9tYWluIDE2IHJlcG9ydGVkIGNyYXNoZWQgYnkgZG9tYWluIDMyNzY3IG9uIGNwdSM1
OgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDoyNS43NTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE3IDE3OjU0OjM1Ljc1Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6
NDUuNzUyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDo1NS43NTNdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjU1OjA1Ljc1M10gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTcgMTc6NTU6MTUuNzUzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1
NToyNS43NTNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjU1OjM1Ljc1M10gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTU6NDUuNzU0XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1NTo1NS43NTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3
OjU2OjA1Ljc1NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6MTUuNzU0XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NjoyNS43NTRdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE3IDE3OjU2OjM1Ljc1NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NDUuNzU1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJd
IElSUSBpbmZvcm1hdGlvbjoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJ
UlE6ICAgMCBhZmZpbml0eTowMSB2ZWM6ZjAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVz
PTAwMDAwMDAwIHRpbWVyX2ludGVycnVwdCgpCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4Ml0gICAgSVJROiAgIDEgYWZmaW5pdHk6MDEgdmVjOjMwIHR5cGU9SU8tQVBJQy1lZGdl
ICAgIHN0YXR1cz0wMDAwMDAzNCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOiAgMSgtLS0p
LAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogICAzIGFmZmluaXR5
OjAxIHZlYzozOCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVk
LCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgIDQg
YWZmaW5pdHk6MDEgdmVjOmYxIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAw
MCBuczE2NTUwX2ludGVycnVwdCgpCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0g
ICAgSVJROiAgIDUgYWZmaW5pdHk6MDEgdmVjOjQwIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0
YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6
NTMuNTgyXSAgICBJUlE6ICAgNiBhZmZpbml0eTowMSB2ZWM6NDggdHlwZT1JTy1BUElDLWVk
Z2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0x
NyAxNzo1Njo1My41ODJdICAgIElSUTogICA3IGFmZmluaXR5OjAxIHZlYzo1MCB0eXBlPUlP
LUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsy
MDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgIDggYWZmaW5pdHk6MDEgdmVjOjU4
IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21h
aW4tbGlzdD0wOiAgOCgtLS0pLAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAg
IElSUTogICA5IGFmZmluaXR5OjNmIHZlYzo2MCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0
dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4Ml0gICAgSVJROiAgMTAgYWZmaW5pdHk6MDEgdmVjOjY4IHR5cGU9SU8tQVBJQy1lZGdl
ICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgyXSAgICBJUlE6ICAxMSBhZmZpbml0eTowMSB2ZWM6NzAgdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDEyIGFmZmluaXR5OjAxIHZlYzo3OCB0
eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWlu
LWxpc3Q9MDogMTIoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJ
UlE6ICAxMyBhZmZpbml0eTozZiB2ZWM6ODggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODJdICAgIElSUTogIDE0IGFmZmluaXR5OjAxIHZlYzo5MCB0eXBlPUlPLUFQSUMtZWRnZSAg
ICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3
OjU2OjUzLjU4Ml0gICAgSVJROiAgMTUgYWZmaW5pdHk6MDEgdmVjOjk4IHR5cGU9SU8tQVBJ
Qy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQt
MTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJUlE6ICAxNiBhZmZpbml0eTowMSB2ZWM6ODkgdHlw
ZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6IDE2KC0tLSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJR
OiAgMTcgYWZmaW5pdHk6MDEgdmVjOmMwIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0w
MDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOiAxNygtLS0pLAooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDE4IGFmZmluaXR5OjAxIHZlYzpiOCB0
eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWlu
LWxpc3Q9MDogMTgoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJ
UlE6ICAxOSBhZmZpbml0eTozZiB2ZWM6MmEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODJdICAgIElSUTogIDIyIGFmZmluaXR5OjAxIHZlYzpiOSB0eXBlPUlPLUFQSUMtbGV2ZWwg
ICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogMjIoLS0tKSwx
MzogMjIoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJUlE6ICAy
NSBhZmZpbml0eTozZiB2ZWM6OWEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAg
IElSUTogIDI4IGFmZmluaXR5OjNmIHZlYzoyMiB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0
dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4Ml0gICAgSVJROiAgMjkgYWZmaW5pdHk6M2YgdmVjOmQ5IHR5cGU9SU8tQVBJQy1sZXZl
bCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgyXSAgICBJUlE6ICAzMiBhZmZpbml0eTozZiB2ZWM6YzkgdHlwZT1JTy1B
UElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDMzIGFmZmluaXR5OjNmIHZlYzpjMSB0
eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihY
RU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgMzYgYWZmaW5pdHk6M2Yg
dmVjOjIxIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVu
Ym91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJUlE6ICAzNyBhZmZp
bml0eToyMCB2ZWM6MjkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiAzNygtTS0pLAooWEVOKSBbMjAxNC0xMS0xNyAx
Nzo1Njo1My41ODJdICAgIElSUTogIDM4IGFmZmluaXR5OjNmIHZlYzphOSB0eXBlPUlPLUFQ
SUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0
LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgNDAgYWZmaW5pdHk6MTAgdmVjOjMxIHR5
cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4t
bGlzdD0xNzogNDAoLU0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJ
UlE6ICA0NiBhZmZpbml0eTozZiB2ZWM6NzIgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODJdICAgIElSUTogIDQ3IGFmZmluaXR5OjIwIHZlYzpkMSB0eXBlPUlPLUFQSUMtbGV2ZWwg
ICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTEgZG9tYWluLWxpc3Q9MTY6IDQ3KFAtTSks
CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgNDggYWZmaW5pdHk6
M2YgdmVjOmQwIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQs
IHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJUlE6ICA1MSBh
ZmZpbml0eTozZiB2ZWM6OGEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElS
UTogIDUyIGFmZmluaXR5OjNmIHZlYzozOSB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9
MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
Ml0gICAgSVJROiAgNTMgYWZmaW5pdHk6M2YgdmVjOmM4IHR5cGU9SU8tQVBJQy1sZXZlbCAg
IHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTY6NTMuNTgyXSAgICBJUlE6ICA1NCBhZmZpbml0eTozZiB2ZWM6ZDggdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0x
MS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDU2IGFmZmluaXR5OjAxIHZlYzoyOCB0eXBl
PUFNRC1JT01NVS1NU0kgICBzdGF0dXM9MDAwMDAwMDAgaW9tbXVfaW50ZXJydXB0X2hhbmRs
ZXIoKQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDU3IGFmZmlu
aXR5OjAxIHZlYzphMCB0eXBlPUhQRVQtTVNJICAgICAgICBzdGF0dXM9MDAwMDAwMDAgaHBl
dF9pbnRlcnJ1cHRfaGFuZGxlcigpCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0g
ICAgSVJROiAgNTggYWZmaW5pdHk6MDQgdmVjOmE4IHR5cGU9SFBFVC1NU0kgICAgICAgIHN0
YXR1cz0wMDAwMDAwMCBocGV0X2ludGVycnVwdF9oYW5kbGVyKCkKKFhFTikgWzIwMTQtMTEt
MTcgMTc6NTY6NTMuNTgyXSAgICBJUlE6ICA1OSBhZmZpbml0eTowOCB2ZWM6YjAgdHlwZT1I
UEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIGhwZXRfaW50ZXJydXB0X2hhbmRsZXIo
KQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDYwIGFmZmluaXR5
OjNmIHZlYzo0MSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVk
LCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgNjEg
YWZmaW5pdHk6M2YgdmVjOjQ5IHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAw
MiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJ
UlE6ICA2MiBhZmZpbml0eTozZiB2ZWM6NTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODNdICAgIElSUTogIDYzIGFmZmluaXR5OjNmIHZlYzo1OSB0eXBlPVBDSS1NU0kgICAgICAg
ICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3
OjU2OjUzLjU4M10gICAgSVJROiAgNjQgYWZmaW5pdHk6M2YgdmVjOjYxIHR5cGU9UENJLU1T
SSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQt
MTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA2NSBhZmZpbml0eTozZiB2ZWM6NjkgdHlw
ZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgIElSUTogIDY2IGFmZmluaXR5OjNmIHZl
Yzo3MSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJv
dW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgSVJROiAgNjcgYWZmaW5p
dHk6M2YgdmVjOjc5IHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBw
ZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA2
OCBhZmZpbml0eTozZiB2ZWM6ODEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAg
IElSUTogIDY5IGFmZmluaXR5OjNmIHZlYzo5MSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0
dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4M10gICAgSVJROiAgNzAgYWZmaW5pdHk6M2YgdmVjOjk5IHR5cGU9UENJLU1TSS8tWCAg
ICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgzXSAgICBJUlE6ICA3MSBhZmZpbml0eTozZiB2ZWM6YTEgdHlwZT1QQ0kt
TVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODNdICAgIElSUTogIDcyIGFmZmluaXR5OjNmIHZlYzpiMSB0
eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihY
RU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgSVJROiAgNzMgYWZmaW5pdHk6MDIg
dmVjOjMyIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9
MCBkb21haW4tbGlzdD0wOjI5MSgtLS0pLAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODNdICAgIElSUTogIDc0IGFmZmluaXR5OjAxIHZlYzozYSB0eXBlPVBDSS1NU0kgICAgICAg
ICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyOTIoLS0tKSwK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA3NSBhZmZpbml0eTox
MCB2ZWM6NDIgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdo
dD0wIGRvbWFpbi1saXN0PTA6MjkzKC0tLSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4M10gICAgSVJROiAgNzYgYWZmaW5pdHk6MDEgdmVjOjRhIHR5cGU9UENJLU1TSSAgICAg
ICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI5NCgtLS0p
LAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgIElSUTogIDc3IGFmZmluaXR5
OjAxIHZlYzo1MiB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxp
Z2h0PTAgZG9tYWluLWxpc3Q9MDoyOTUoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6
NTMuNTgzXSAgICBJUlE6ICA3OCBhZmZpbml0eTowMSB2ZWM6NWEgdHlwZT1QQ0ktTVNJICAg
ICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk2KC0t
LSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgSVJROiAgNzkgYWZmaW5p
dHk6M2YgdmVjOjYyIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBw
ZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA4
MCBhZmZpbml0eTozZiB2ZWM6NmEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAg
IElSUTogIDgxIGFmZmluaXR5OjA4IHZlYzo3YSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0
dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyOTAoLS0tKSwKKFhFTikg
WzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA4MiBhZmZpbml0eTowMSB2ZWM6
OTIgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRv
bWFpbi1saXN0PTA6Mjg5KC0tLSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10g
ICAgSVJROiAgODMgYWZmaW5pdHk6MDEgdmVjOmEyIHR5cGU9UENJLU1TSSAgICAgICAgIHN0
YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI4OCgtLS0pLAooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgIElSUTogIDg0IGFmZmluaXR5OjIwIHZl
YzphYSB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMTAgaW4tZmxpZ2h0PTAg
ZG9tYWluLWxpc3Q9MTc6IDg3KC0tLSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
M10gICAgSVJROiAgODUgYWZmaW5pdHk6MjAgdmVjOmIyIHR5cGU9UENJLU1TSS8tWCAgICAg
IHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0xNzogODYoLS0tKSwK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA4NiBhZmZpbml0eToy
MCB2ZWM6YmEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdo
dD0wIGRvbWFpbi1saXN0PTE3OiA4NSgtLS0pLAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1
My41ODNdICAgIElSUTogIDg3IGFmZmluaXR5OjIwIHZlYzpjMiB0eXBlPVBDSS1NU0kvLVgg
ICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTc6IDg0KC0t
LSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgSVJROiAgODggYWZmaW5p
dHk6MjAgdmVjOmNhIHR5cGU9UENJLU1TSS8tWCAgICAgIHN0YXR1cz0wMDAwMDAxMCBpbi1m
bGlnaHQ9MCBkb21haW4tbGlzdD0xNjogODcoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTY6NTMuNTgzXSAgICBJUlE6ICA4OSBhZmZpbml0eTowNCB2ZWM6ZDIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiA4
NigtLS0pLAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgIElSUTogIDkwIGFm
ZmluaXR5OjA0IHZlYzpkYSB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMzAg
aW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTY6IDg1KC0tLSksCihYRU4pIFsyMDE0LTExLTE3
IDE3OjU2OjUzLjU4M10gICAgSVJROiAgOTEgYWZmaW5pdHk6MDQgdmVjOjIzIHR5cGU9UENJ
LU1TSS8tWCAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0x
NjogODQoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA5
MiBhZmZpbml0eTowNCB2ZWM6MmIgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAw
MDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiA4MygtLS0pLAooWEVOKSBbMjAxNC0x
MS0xNyAxNzo1Njo1My41ODNdIERpcmVjdCB2ZWN0b3IgaW5mb3JtYXRpb246CihYRU4pIFsy
MDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgMHgyMCAtPiBpcnFfbW92ZV9jbGVhbnVwX2lu
dGVycnVwdCgpCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgMHhmOSAtPiBw
bXVfYXBpY19pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAg
IDB4ZmEgLT4gYXBpY190aW1lcl9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1
Njo1My41ODNdICAgIDB4ZmIgLT4gY2FsbF9mdW5jdGlvbl9pbnRlcnJ1cHQoKQooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgIDB4ZmMgLT4gZXZlbnRfY2hlY2tfaW50ZXJy
dXB0KCkKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAweGZkIC0+IGludmFs
aWRhdGVfaW50ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAw
eGZlIC0+IGVycm9yX2ludGVycnVwdCgpCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
M10gICAgMHhmZiAtPiBzcHVyaW91c19pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNyAx
Nzo1Njo1My41ODNdIElPLUFQSUMgaW50ZXJydXB0IGluZm9ybWF0aW9uOgooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODNdICAgICBJUlEgIDAgVmVjMjQwOgooWEVOKSBbMjAxNC0x
MS0xNyAxNzo1Njo1My41ODNdICAgICAgIEFwaWMgMHgwMCwgUGluICAyOiB2ZWM9ZjAgZGVs
aXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1h
c2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgSVJR
ICAxIFZlYyA0ODoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgICBBcGlj
IDB4MDAsIFBpbiAgMTogdmVjPTMwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBw
b2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTEx
LTE3IDE3OjU2OjUzLjU4M10gICAgIElSUSAgMyBWZWMgNTY6CihYRU4pIFsyMDE0LTExLTE3
IDE3OjU2OjUzLjU4M10gICAgICAgQXBpYyAweDAwLCBQaW4gIDM6IHZlYz0zOCBkZWxpdmVy
eT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0w
IGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICBJUlEgIDQg
VmVjMjQxOgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICAgIEFwaWMgMHgw
MCwgUGluICA0OiB2ZWM9ZjEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFy
aXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgzXSAgICAgSVJRICA1IFZlYyA2NDoKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTY6NTMuNTgzXSAgICAgICBBcGljIDB4MDAsIFBpbiAgNTogdmVjPTQwIGRlbGl2ZXJ5PUxv
UHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVz
dF9pZDoxCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgIElSUSAgNiBWZWMg
NzI6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgICAgQXBpYyAweDAwLCBQ
aW4gIDY6IHZlYz00OCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9
MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1
Njo1My41ODNdICAgICBJUlEgIDcgVmVjIDgwOgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1
My41ODNdICAgICAgIEFwaWMgMHgwMCwgUGluICA3OiB2ZWM9NTAgZGVsaXZlcnk9TG9Qcmkg
ZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lk
OjEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgSVJRICA4IFZlYyA4ODoK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgICBBcGljIDB4MDAsIFBpbiAg
ODogdmVjPTU4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGly
cj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4M10gICAgIElSUSAgOSBWZWMgOTY6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
M10gICAgICAgQXBpYyAweDAwLCBQaW4gIDk6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0
PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgSVJRIDEwIFZlYzEwNDoKKFhF
TikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgICBBcGljIDB4MDAsIFBpbiAxMDog
dmVjPTY4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0w
IHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
M10gICAgIElSUSAxMSBWZWMxMTI6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10g
ICAgICAgQXBpYyAweDAwLCBQaW4gMTE6IHZlYz03MCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwg
c3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICBJUlEgMTIgVmVjMTIwOgooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICAgIEFwaWMgMHgwMCwgUGluIDEyOiB2ZWM9
NzggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJp
Zz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAg
ICAgSVJRIDEzIFZlYzEzNjoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAg
ICBBcGljIDB4MDAsIFBpbiAxMzogdmVjPTg4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0
dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICBJUlEgMTQgVmVjMTQ0OgooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODNdICAgICAgIEFwaWMgMHgwMCwgUGluIDE0OiB2ZWM9OTAg
ZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1F
IG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAg
SVJRIDE1IFZlYzE1MjoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgICBB
cGljIDB4MDAsIFBpbiAxNTogdmVjPTk4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9
MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0
LTExLTE3IDE3OjU2OjUzLjU4M10gICAgIElSUSAxNiBWZWMxMzc6CihYRU4pIFsyMDE0LTEx
LTE3IDE3OjU2OjUzLjU4M10gICAgICAgQXBpYyAweDAwLCBQaW4gMTY6IHZlYz04OSBkZWxp
dmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFz
az0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICBJUlEg
MTcgVmVjMTkyOgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICAgIEFwaWMg
MHgwMCwgUGluIDE3OiB2ZWM9YzAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBv
bGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEt
MTcgMTc6NTY6NTMuNTgzXSAgICAgSVJRIDE4IFZlYzE4NDoKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgzXSAgICAgICBBcGljIDB4MDAsIFBpbiAxODogdmVjPWI4IGRlbGl2ZXJ5
PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTAg
ZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgIElSUSAxOSBW
ZWMgNDI6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgICAgQXBpYyAweDAw
LCBQaW4gMTk6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJp
dHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgzXSAgICAgSVJRIDIyIFZlYzE4NToKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTY6NTMuNTgzXSAgICAgICBBcGljIDB4MDAsIFBpbiAyMjogdmVjPWI5IGRlbGl2ZXJ5PUZp
eGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTAgZGVz
dF9pZDoxCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgIElSUSAyNSBWZWMx
NTQ6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4NF0gICAgICAgQXBpYyAweDAxLCBQ
aW4gIDE6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9
MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTY6NTMuNTg0XSAgICAgSVJRIDI4IFZlYyAzNDoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6
NTMuNTg0XSAgICAgICBBcGljIDB4MDEsIFBpbiAgNDogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVk
IGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9p
ZDo2MwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAgICBJUlEgMjkgVmVjMjE3
OgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAgICAgIEFwaWMgMHgwMSwgUGlu
ICA1OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEg
aXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2
OjUzLjU4NF0gICAgIElSUSAzMiBWZWMyMDE6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4NF0gICAgICAgQXBpYyAweDAxLCBQaW4gIDg6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBk
ZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6
NjMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAgICAgSVJRIDMzIFZlYzE5MzoK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAgICAgICBBcGljIDB4MDEsIFBpbiAg
OTogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGly
cj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1
My41ODRdICAgICBJUlEgMzYgVmVjIDMzOgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODRdICAgICAgIEFwaWMgMHgwMSwgUGluIDEyOiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVz
dD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYz
CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4NF0gICAgIElSUSAzNyBWZWMgNDE6CihY
RU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4NF0gICAgICAgQXBpYyAweDAxLCBQaW4gMTM6
IHZlYz0yOSBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9
MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MzIKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMu
NTg0XSAgICAgSVJRIDM4IFZlYzE2OToKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0
XSAgICAgICBBcGljIDB4MDEsIFBpbiAxNDogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9
TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2Mwoo
WEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAgICBJUlEgNDAgVmVjIDQ5OgooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAgICAgIEFwaWMgMHgwMSwgUGluIDE2OiB2
ZWM9MzEgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAg
dHJpZz1MIG1hc2s9MCBkZXN0X2lkOjE2CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
NF0gICAgIElSUSA0NiBWZWMxMTQ6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4NF0g
ICAgICAgQXBpYyAweDAxLCBQaW4gMjI6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwg
c3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhF
TikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAgICAgSVJRIDQ3IFZlYzIwOToKKFhFTikg
WzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAgICAgICBBcGljIDB4MDEsIFBpbiAyMzogdmVj
PWQxIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MSBwb2xhcml0eT0xIGlycj0xIHRy
aWc9TCBtYXNrPTAgZGVzdF9pZDozMgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRd
ICAgICBJUlEgNDggVmVjMjA4OgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAg
ICAgIEFwaWMgMHgwMSwgUGluIDI0OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0
YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4p
IFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4NF0gICAgIElSUSA1MSBWZWMxMzg6CihYRU4pIFsy
MDE0LTExLTE3IDE3OjU2OjUzLjU4NF0gICAgICAgQXBpYyAweDAxLCBQaW4gMjc6IHZlYz0w
MCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmln
PUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAg
ICAgSVJRIDUyIFZlYyA1NzoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAgICAg
ICBBcGljIDB4MDEsIFBpbiAyODogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0
dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAgICBJUlEgNTMgVmVjMjAwOgooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODRdICAgICAgIEFwaWMgMHgwMSwgUGluIDI5OiB2ZWM9MDAg
ZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1M
IG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjYxNV0gICAg
IElSUSA1NCBWZWMyMTY6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjYyOF0gICAgICAg
QXBpYyAweDAxLCBQaW4gMzA6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVz
PTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIw
MTQtMTEtMTcgMTc6NTY6NTUuNzA5XSBNU0kgaW5mb3JtYXRpb246CihYRU4pIFsyMDE0LTEx
LTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAgICAgNTYgdmVjPTI4IGxvd2VzdCAgZWRnZSAgIGFz
c2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8wLz8KKFhFTikgWzIwMTQt
MTEtMTcgMTc6NTY6NTUuNzA5XSAgSFBFVCAgICA1NyB2ZWM9YTAgbG93ZXN0ICBlZGdlICAg
YXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFzaz0xLzAvPwooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1NS43MDldICBIUEVUICAgIDU4IHZlYz1hOCBsb3dlc3QgIGVkZ2Ug
ICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwNCBtYXNrPTEvMC8/CihYRU4pIFsy
MDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIEhQRVQgICAgNTkgdmVjPWIwIGxvd2VzdCAgZWRn
ZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDA4IG1hc2s9MS8wLz8KKFhFTikg
WzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJICAgICA2MCB2ZWM9NDEgbG93ZXN0ICBl
ZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0kgICAgIDYxIHZlYz00OSBsb3dlc3Qg
IGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihY
RU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAgICAgNjIgdmVjPTUxIGxvd2Vz
dCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8K
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJICAgICA2MyB2ZWM9NTkgbG93
ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEv
PwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0kgICAgIDY0IHZlYz02MSBs
b3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAv
MS8/CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAgICAgNjUgdmVjPTY5
IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9
MC8xLz8KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJICAgICA2NiB2ZWM9
NzEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFz
az0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0kgICAgIDY3IHZl
Yz03OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBt
YXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAgICAgNjgg
dmVjPTgxIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNm
IG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJICAgICA2
OSB2ZWM9OTEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAw
M2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0kgICAg
IDcwIHZlYz05OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAw
MDAzZiBtYXNrPTEvMS8xCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAg
ICAgNzEgdmVjPWExIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAw
MDAwMDNmIG1hc2s9MS8xLzEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJ
ICAgICA3MiB2ZWM9YjEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9
MDAwMDAwM2YgbWFzaz0xLzEvMQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBN
U0kgICAgIDczIHZlYz0zMiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVz
dD0wMDAwMDAwMiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0g
IE1TSSAgICAgNzQgdmVjPTNhIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBk
ZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5
XSAgTVNJICAgICA3NSB2ZWM9NDIgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0
IGRlc3Q9MDAwMDAwMDIgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43
MDldICBNU0kgICAgIDc2IHZlYz00YSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dl
c3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1
LjcwOV0gIE1TSSAgICAgNzcgdmVjPTUyIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxv
d2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6
NTUuNzA5XSAgTVNJICAgICA3OCB2ZWM9NWEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cg
bG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1
Njo1NS43MDldICBNU0kgICAgIDc5IHZlYz02MiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxv
ZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE3IDE3
OjU2OjU1LjcwOV0gIE1TSSAgICAgODAgdmVjPTZhIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAg
bG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTUuNzA5XSAgTVNJICAgICA4MSB2ZWM9N2EgbG93ZXN0ICBlZGdlICAgYXNzZXJ0
ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMTAgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0x
NyAxNzo1Njo1NS43MDldICBNU0kgICAgIDgyIHZlYz05MiBsb3dlc3QgIGVkZ2UgICBhc3Nl
cnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAxMCBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTEx
LTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAgICAgODMgdmVjPWEyIGxvd2VzdCAgZWRnZSAgIGFz
c2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQt
MTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJLVggICA4NCB2ZWM9YWEgbG93ZXN0ICBlZGdlICAg
YXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDQgbWFzaz0xLzAvMAooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0ktWCAgIDg1IHZlYz1iMiBsb3dlc3QgIGVkZ2Ug
ICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAyMCBtYXNrPTEvMC8wCihYRU4pIFsy
MDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSS1YICAgODYgdmVjPWJhIGxvd2VzdCAgZWRn
ZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDIwIG1hc2s9MS8wLzAKKFhFTikg
WzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJLVggICA4NyB2ZWM9YzIgbG93ZXN0ICBl
ZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMjAgbWFzaz0xLzAvMAooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0ktWCAgIDg4IHZlYz1jYSBsb3dlc3Qg
IGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAyMCBtYXNrPTEvMC8wCihY
RU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSS1YICAgODkgdmVjPWQyIGxvd2Vz
dCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDA0IG1hc2s9MS8wLzAK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJLVggICA5MCB2ZWM9ZGEgbG93
ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDQgbWFzaz0xLzAv
MAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0ktWCAgIDkxIHZlYz0yMyBs
b3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwNCBtYXNrPTEv
MC8wCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSS1YICAgOTIgdmVjPTJi
IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDA0IG1hc2s9
MS8wLzAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzU1XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1NzowNS43NTVdIC0tTUFSSy0tCg==
------------07C1DE16C0EDF9EBB
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------07C1DE16C0EDF9EBB--



From xen-devel-bounces@lists.xen.org Mon Nov 17 18:01:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 18:01:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqQbv-0004a2-WA; Mon, 17 Nov 2014 18:01:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqQbu-0004Zx-4w
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 18:01:10 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	BC/28-02953-5E73A645; Mon, 17 Nov 2014 18:01:09 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416247264!8482181!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22153 invoked from network); 17 Nov 2014 18:01:05 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 17 Nov 2014 18:01:05 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50076 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqQaR-0000zH-7x; Mon, 17 Nov 2014 18:59:39 +0100
Date: Mon, 17 Nov 2014 19:01:03 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1848367524.20141117190103@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141117163416.GA22137@laptop.dumpdata.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------07C1DE16C0EDF9EBB"
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------07C1DE16C0EDF9EBB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Monday, November 17, 2014, 5:34:16 PM, you wrote:

> On Fri, Nov 14, 2014 at 11:09:58PM +0100, Sander Eikelenboom wrote:
>> 
>> Friday, November 14, 2014, 9:25:13 PM, you wrote:
>> 
>> > On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> >> 
>> >> Friday, November 14, 2014, 4:43:58 PM, you wrote:
>> >> 
>> >> >>>> On 14.11.14 at 16:20, <linux@eikelenboom.it> wrote:
>> >> >> If it still helps i could try Andrews suggestion and try out with only 
>> >> >> commit aeeea485 ..
>> >> 
>> >> > Yes, even if it's pretty certain it's the second of the commits, verifying
>> >> > this would be helpful (or if the assumption is wrong, the pattern it's
>> >> > dying with would change and hence perhaps provide further clues).
>> >> 
>> >> > Jan
>> >> 
>> >> 
>> >> Ok with a revert of f6dd295 .. it survived cooking and eating a nice bowl of 
>> >> pasta without a panic. So it would probably be indeed that specific commit.
>> 
>> > Could you try running with these two patches while you enjoy an beer in the evening?
>> 
>> Hmm i didn't expect it not to panic and reboot anymore :-)

> I should have also asked for your to run with 'iommu=verbose,debug', but
> that can be done later..

> The guest d16 looks to have two PCI passthrough devices:
> XEN) [2014-11-14 21:31:26.569] io.c:550: d16: bind: m_gsi=37 g_gsi=36 dev=00.00.5 intx=0
> XEN) [2014-11-14 21:31:28.095] io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0

> And one of them uses just the GSI while the other uses four MSI-X, is
> that about right?

> I tried to reproduce that on my AMD box with two NICs:


> # lspci
> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
> 00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
> 00:02.0 VGA compatible controller: Technical Corp. Device 1111
> 00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
> 00:04.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
> 00:05.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)

> # cat /proc/interrupts |grep eth
>  36:     384183          0  xen-pirq-ioapic-level  eth0
>  63:          1          0  xen-pirq-msi-x     eth1
>  64:         24     661961  xen-pirq-msi-x     eth1-rx-0
>  65:        205          0  xen-pirq-msi-x     eth1-rx-1
>  66:        162          0  xen-pirq-msi-x     eth1-tx-0
>  67:        190          0  xen-pirq-msi-x     eth1-tx-1


> Is that a similar distribution of IRQ/MSIx you end up having?
>> 
>> However xl dmesg (complete one attached) showed it would have:
>> 
>> (XEN) [2014-11-14 21:35:50.646] --MARK--
>> (XEN) [2014-11-14 21:35:56.861] grant_table.c:305:d0v0 Increased maptrack size to 9 frames
>> (XEN) [2014-11-14 21:36:00.647] --MARK--
>> (XEN) [2014-11-14 21:36:10.410] grant_table.c:1299:d16v1 Expanding dom (16) grant table from (5) to (6) frames.
>> (XEN) [2014-11-14 21:36:10.820] --MARK--
>> (XEN) [2014-11-14 21:36:20.820] --MARK--
>> (XEN) [2014-11-14 21:36:30.820] --MARK--
>> (XEN) [2014-11-14 21:36:40.821] --MARK--
>> (XEN) [2014-11-14 21:36:50.821] --MARK--
>> (XEN) [2014-11-14 21:37:00.388] CPU00:
>> (XEN) [2014-11-14 21:37:00.399] CPU01:
>> (XEN) [2014-11-14 21:37:00.410] d16 OK-softirq 20msec ago, state:1, 41220 count, [prev:ffff83054ef5e3e0, next:ffff83054ef5e3e0]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.445] d16 OK-raise   46msec ago, state:1, 41223 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.481] d16 ERR-poison 92msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0
>> (XEN) [2014-11-14 21:37:00.515] d16 Z-softirq  28853msec ago, state:2, 1 count, [prev:0000000000200200, next:0000000000100100]  PIRQ:0

> The PIRQ:0 would imply that this is the legacy interrupt - which would be you 0a:00.0 device 
> (Conexant Systems, Inc. Device 8210).


> And it is pounding on this CPU - and the issue is that the 'test_and_clear_bit' ends
> up returning 0 - which means it was not able to set STATE_SCHED:
> (!?)
>     if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               
>         {                                                                       
>             hvm_dirq_assist(d, pirq_dpci);                                      
>             put_domain(d);                                                      
>         }                                                                       
>         else                                                                    
>         {                                                                       
>             _record(&debug->zombie_softirq, pirq_dpci);        

> which causes us to record it [Z-softirq],  which says we we are in state 2
> (1<<STATE_RUN).

>             reset = 1;                                                          
>         }                                        

> .. eons ago (28853msec).

> Hmm. There is something fishy there but the only theory I have is that
> we end up doing 'list_del' twice on different CPUs on the same structure.

> That should not be possible, but then this check - 'test_and_clear_bit' returned
> 0 which means that somebody had cleared it (or it failed to clear it?)

> But the only other path for 'clearing' it is via the error paths and you are
> not hitting any of them.

> In the mean-time, could you try this patch. It adds a bit more debug to help
> me figure this out.

> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index 23e5ed1..443975c 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -126,17 +126,17 @@ static void dump_record(struct _debug_f *d, unsigned int type)
>          BUG();
>  
>      now = NOW();
> -    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
> +    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
>             d->domid, names[type],
>             (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->>state, d->count, d->list.prev, d->list.next);
+            d->>state, d->count, d->list.prev, d->list.next, d->dpci);
>  
>      if ( d->dpci )
>      {
>          struct hvm_pirq_dpci *pirq_dpci = d->dpci;
>  
>          for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
> -            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
> +            if ( pirq_dpci->flags & (1 << i) )
>                  printk("%s ", names_flag[i]);
>  
>          printk(" PIRQ:%d", pirq_dpci->pirq);

Hi Konrad,

Here is the xl dmesg output with this patch (attached with debug-key i and M 
output). What i don't get .. is that d16 and d17 each have a device passed through 
that seems to be using the same pirq 87 ?
 
--
Sander

(XEN) [2014-11-17 17:54:18.695] CPU00:
(XEN) [2014-11-17 17:54:18.705] CPU01:
(XEN) [2014-11-17 17:54:18.716] d16 OK-softirq 62msec ago, state:1, 2628 count, [prev:ffff83054ef57e70, next:ffff83054ef57e70] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:18.765] d16 OK-raise   112msec ago, state:1, 2628 count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:18.815] CPU02:
(XEN) [2014-11-17 17:54:18.825] d17 OK-softirq 500msec ago, state:1, 3439 count, [prev:ffff83054ef47e70, next:ffff83054ef47e70] ffff83051a1c8c28<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:18.875] d17 OK-raise   549msec ago, state:1, 3439 count, [prev:0000000000200200, next:0000000000100100] ffff83051a1c8c28<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:18.924] CPU03:
(XEN) [2014-11-17 17:54:18.935] d16 OK-softirq 313msec ago, state:1, 3533 count, [prev:ffff83054ef37e70, next:ffff83054ef37e70] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:18.984] d16 OK-raise   363msec ago, state:1, 3533 count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:19.034] CPU04:
(XEN) [2014-11-17 17:54:19.044] d16 OK-softirq 359msec ago, state:1, 3691 count, [prev:ffff83054ef27e88, next:ffff83054ef27e88] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:19.094] d16 OK-raise   408msec ago, state:1, 3691 count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
(XEN) [2014-11-17 17:54:19.143] CPU05:
(XEN) [2014-11-17 17:54:19.154] d16 OK-softirq 458msec ago, state:1, 52039 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
(XEN) [2014-11-17 17:54:19.205] d16 OK-raise   489msec ago, state:1, 52049 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
(XEN) [2014-11-17 17:54:19.257] d16 ERR-poison 561msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
(XEN) [2014-11-17 17:54:19.307] d16 Z-softirq  731msec ago, state:3, 3 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
(XEN) [2014-11-17 17:54:19.356] domain_crash called from io.c:938
(XEN) [2014-11-17 17:54:19.356] Domain 16 reported crashed by domain 32767 on cpu#5:
------------07C1DE16C0EDF9EBB
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDM6NDYuMDA0XSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xNyAxNzo0Mzo1Ni4wMDRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3
IDE3OjQ0OjA2LjAwNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDQ6MTYuMDA1
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NDoyNi4wMDVdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE3IDE3OjQ0OjM2LjAwNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTcgMTc6NDQ6NDYuMDA1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NDo1Ni4w
MDZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ1OjA2LjAwNl0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTcgMTc6NDU6MTYuMDA2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xNyAxNzo0NToyNi4wMDZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ1OjM2
LjAwN10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDU6NDYuMDA3XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NTo1Ni4wMDddIC0tTUFSSy0tCihkMSkgWzIwMTQt
MTEtMTcgMTc6NDY6MDUuNzI0XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9y
eQooZDEpIFsyMDE0LTExLTE3IDE3OjQ2OjA1LjcyNF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQu
Li4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDY6MDUuOTkzXSB0cmFwcy5jOjI1Nzk6ZDF2MCBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAw
MDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xNyAxNzo0
NjowNi4wMDddIC0tTUFSSy0tCihkMikgWzIwMTQtMTEtMTcgMTc6NDY6MTEuNzA3XSBtYXBw
aW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDIpIFsyMDE0LTExLTE3IDE3OjQ2
OjExLjcwN10gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6
NDY6MTEuNzg5XSB0cmFwcy5jOjI1Nzk6ZDJ2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAw
MDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAw
MDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NjoxNi4wMDhdIC0tTUFSSy0tCihkMykg
WzIwMTQtMTEtMTcgMTc6NDY6MTcuNDk3XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2Fs
IG1lbW9yeQooZDMpIFsyMDE0LTExLTE3IDE3OjQ2OjE3LjQ5N10gYWJvdXQgdG8gZ2V0IHN0
YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDY6MTcuNTg5XSB0cmFwcy5jOjI1Nzk6
ZDN2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAw
MDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooZDQpIFsyMDE0LTExLTE3
IDE3OjQ2OjIzLjQ3M10gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQ0
KSBbMjAxNC0xMS0xNyAxNzo0NjoyMy40NzNdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihY
RU4pIFsyMDE0LTExLTE3IDE3OjQ2OjIzLjU1MF0gdHJhcHMuYzoyNTc5OmQ0djAgRG9tYWlu
IGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAw
MDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDY6MjQu
MTE1XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRv
IDIgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ2OjI2LjAwOF0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTcgMTc6NDY6MjguNjM0XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIElu
Y3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDMgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE3IDE3
OjQ2OjI4LjY1NV0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sg
c2l6ZSB0byA0IGZyYW1lcwooZDUpIFsyMDE0LTExLTE3IDE3OjQ2OjI5LjMzNV0gbWFwcGlu
ZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQ1KSBbMjAxNC0xMS0xNyAxNzo0Njoy
OS4zMzVdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ2
OjI5LjQxM10gdHJhcHMuYzoyNTc5OmQ1djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAw
MDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAw
ZmZmZi4KKGQ2KSBbMjAxNC0xMS0xNyAxNzo0NjozNS4xODBdIG1hcHBpbmcga2VybmVsIGlu
dG8gcGh5c2ljYWwgbWVtb3J5CihkNikgWzIwMTQtMTEtMTcgMTc6NDY6MzUuMTgwXSBhYm91
dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NjozNS4yOTRdIHRy
YXBzLmM6MjU3OTpkNnYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4p
IFsyMDE0LTExLTE3IDE3OjQ2OjM2LjAwOF0gLS1NQVJLLS0KKGQ3KSBbMjAxNC0xMS0xNyAx
Nzo0Njo0MS4zMDJdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkNykg
WzIwMTQtMTEtMTcgMTc6NDY6NDEuMzAyXSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVO
KSBbMjAxNC0xMS0xNyAxNzo0Njo0MS4zODRdIHRyYXBzLmM6MjU3OTpkN3YwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAw
MCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ2OjQ2LjAw
OF0gLS1NQVJLLS0KKGQ4KSBbMjAxNC0xMS0xNyAxNzo0Njo0Ny4xOTRdIG1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkOCkgWzIwMTQtMTEtMTcgMTc6NDY6NDcuMTk0
XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Njo0Ny4y
NzFdIHRyYXBzLmM6MjU3OTpkOHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYu
CihkOSkgWzIwMTQtMTEtMTcgMTc6NDY6NTMuMjIwXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBo
eXNpY2FsIG1lbW9yeQooZDkpIFsyMDE0LTExLTE3IDE3OjQ2OjUzLjIyMF0gYWJvdXQgdG8g
Z2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDY6NTMuMzM2XSB0cmFwcy5j
OjI1Nzk6ZDl2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJv
bSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAx
NC0xMS0xNyAxNzo0Njo1NC45NDJdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2Vk
IG1hcHRyYWNrIHNpemUgdG8gNSBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDY6NTYu
MDA4XSAtLU1BUkstLQooZDEwKSBbMjAxNC0xMS0xNyAxNzo0NzowMC4wNDRdIG1hcHBpbmcg
a2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTApIFsyMDE0LTExLTE3IDE3OjQ3OjAw
LjA0NF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6
MDAuMTMwXSB0cmFwcy5jOjI1Nzk6ZDEwdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAw
MDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAw
ZmZmZi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MDYuMDA5XSAtLU1BUkstLQooZDExKSBb
MjAxNC0xMS0xNyAxNzo0NzowNi4yNjVdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwg
bWVtb3J5CihkMTEpIFsyMDE0LTExLTE3IDE3OjQ3OjA2LjI2NV0gYWJvdXQgdG8gZ2V0IHN0
YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MDYuMzU5XSB0cmFwcy5jOjI1Nzk6
ZDExdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgw
MDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKGQxMikgWzIwMTQtMTEt
MTcgMTc6NDc6MTIuNDM5XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQoo
ZDEyKSBbMjAxNC0xMS0xNyAxNzo0NzoxMi40MzldIGFib3V0IHRvIGdldCBzdGFydGVkLi4u
CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjEyLjUyOV0gdHJhcHMuYzoyNTc5OmQxMnYwIERv
bWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAw
MDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3
OjE2LjAwOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MTguOTI1XSBBTUQt
Vmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4YTQsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMwooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NzoxOC45MjVdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTQsIHR5cGUgPSAweDcsIHJvb3QgdGFibGUg
PSAweDUxNjZjNDAwMCwgZG9tYWluID0gMTMsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAx
NC0xMS0xNyAxNzo0NzoxOC45MjVdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MDM6MDYuMCBm
cm9tIGRvbTAgdG8gZG9tMTMKKGQxMykgWzIwMTQtMTEtMTcgMTc6NDc6MTguOTM5XSBtYXBw
aW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDEzKSBbMjAxNC0xMS0xNyAxNzo0
NzoxOC45MzldIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE3IDE3
OjQ3OjE5LjE3N10gdHJhcHMuYzoyNTc5OmQxM3YwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1Ig
MDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAw
MDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjIxLjAyNV0gZ3JhbnRfdGFibGUu
YzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA2IGZyYW1lcwooZDE0KSBb
MjAxNC0xMS0xNyAxNzo0NzoyNC45MzNdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwg
bWVtb3J5CihkMTQpIFsyMDE0LTExLTE3IDE3OjQ3OjI0LjkzM10gYWJvdXQgdG8gZ2V0IHN0
YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MjUuMDI0XSB0cmFwcy5jOjI1Nzk6
ZDE0djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgw
MDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEt
MTcgMTc6NDc6MjYuMDA5XSAtLU1BUkstLQooZDE1KSBbMjAxNC0xMS0xNyAxNzo0NzozMS4y
NzJdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTUpIFsyMDE0LTEx
LTE3IDE3OjQ3OjMxLjI3Ml0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQt
MTEtMTcgMTc6NDc6MzEuMzY0XSB0cmFwcy5jOjI1Nzk6ZDE1djAgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4
MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MzYuMDA5XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0NzozOS40MDFdIGlvLmM6NTUwOiBkMTY6IGJp
bmQ6IG1fZ3NpPTM3IGdfZ3NpPTM2IGRldj0wMC4wMC41IGludHg9MAooWEVOKSBbMjAxNC0x
MS0xNyAxNzo0NzozOS44MDhdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHg4MDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzoz
OS44MDhdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ODAw
LCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1MWIwZDEwMDAsIGRvbWFpbiA9IDE2LCBw
YWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6MzkuODA4XSBBTUQtVmk6
IFJlLWFzc2lnbiAwMDAwOjA4OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE2CihYRU4pIFsyMDE0
LTExLTE3IDE3OjQ3OjQwLjkyN10gaW8uYzo1NTA6IGQxNjogYmluZDogbV9nc2k9NDcgZ19n
c2k9NDAgZGV2PTAwLjAwLjYgaW50eD0wCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjkz
M10gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweGEwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjkzM10gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMDAsIHR5cGUgPSAweDEsIHJv
b3QgdGFibGUgPSAweDUxYjBkMTAwMCwgZG9tYWluID0gMTYsIHBhZ2luZyBtb2RlID0gMwoo
WEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0MC45MzNdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6
MGE6MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTYKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDAu
OTQ0XSBIVk0gTG9hZGVyCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjk0NF0gRGV0ZWN0
ZWQgWGVuIHY0LjUuMC1yYwooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MC45NDRdIFhlbmJ1
cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCAxCihkMTYpIFsyMDE0LTExLTE3
IDE3OjQ3OjQwLjk0NF0gU3lzdGVtIHJlcXVlc3RlZCBTZWFCSU9TCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQwLjk0NF0gQ1BVIHNwZWVkIGlzIDMyMDAgTUh6CihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQwLjk0NF0gUmVsb2NhdGluZyBndWVzdCBtZW1vcnkgZm9yIGxvd21lbSBN
TUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjk0NV0gaXJx
LmM6MjcwOiBEb20xNiBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1CihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQwLjk0NV0gUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUKKFhFTikg
WzIwMTQtMTEtMTcgMTc6NDc6NDAuOTQ1XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEg
Y2hhbmdlZCAwIC0+IDEwCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjk0NV0gUENJLUlT
QSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQwLjk0
NV0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAyIGNoYW5nZWQgMCAtPiAxMQooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MC45NDVdIFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlEx
MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0MC45NDZdIGlycS5jOjI3MDogRG9tMTYgUENJ
IGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MC45NDZd
IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1CihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3
OjQwLjk2M10gcGNpIGRldiAwMToyIElOVEQtPklSUTUKKGQxNikgWzIwMTQtMTEtMTcgMTc6
NDc6NDAuOTY5XSBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTAKKGQxNikgWzIwMTQtMTEtMTcg
MTc6NDc6NDAuOTc0XSBwY2kgZGV2IDAyOjAgSU5UQS0+SVJRMTEKKGQxNikgWzIwMTQtMTEt
MTcgMTc6NDc6NDAuOTg1XSBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQooZDE2KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0MC45OTFdIHBjaSBkZXYgMDU6MCBJTlRBLT5JUlExMAooZDE2KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0MC45OThdIHBjaSBkZXYgMDY6MCBJTlRBLT5JUlExMQooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS4wNDJdIE5vIFJBTSBpbiBoaWdoIG1lbW9yeTsgc2V0dGlu
ZyBoaWdoX21lbSByZXNvdXJjZSBiYXNlIHRvIDEwMDAwMDAwMAooZDE2KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0MS4wNDJdIHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDIwMDAwMDA6IDBm
MDAwMDAwOAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4wNDRdIHBjaSBkZXYgMDI6MCBi
YXIgMTQgc2l6ZSAwMDEwMDAwMDA6IDBmMjAwMDAwOAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0
Nzo0MS4wNDZdIHBjaSBkZXYgMDY6MCBiYXIgMTAgc2l6ZSAwMDAyMDAwMDA6IDBmMzAwMDAw
NAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4wNDZdIG1lbW9yeV9tYXA6YWRkOiBkb20x
NiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0
MS4wNTFdIHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAwNDAwMDA6IDBmMzIwMDAwMAoo
ZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4wNTRdIHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6
ZSAwMDAwMjAwMDA6IDBmMzI0MDAwMAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4wNTRd
IHBjaSBkZXYgMDM6MCBiYXIgMzAgc2l6ZSAwMDAwMTAwMDA6IDBmMzI2MDAwMAooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS4wNTVdIHBjaSBkZXYgMDU6MCBiYXIgMTAgc2l6ZSAwMDAw
MDIwMDA6IDBmMzI3MDAwNAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4wNTVdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKGQxNikgWzIwMTQt
MTEtMTcgMTc6NDc6NDEuMDYyXSBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDAwMDAxMDAw
OiAwZjMyNzIwMDAKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMDYyXSBwY2kgZGV2IDAy
OjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDEKKGQxNikgWzIwMTQtMTEtMTcg
MTc6NDc6NDEuMDY0XSBwY2kgZGV2IDA0OjAgYmFyIDE0IHNpemUgMDAwMDAwMDQwOiAwMDAw
MGMxMDEKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMDY3XSBwY2kgZGV2IDAxOjIgYmFy
IDIwIHNpemUgMDAwMDAwMDIwOiAwMDAwMGMxNDEKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6
NDEuMDY5XSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNjEK
KGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMDcxXSA/IT8hPyE/IT8gZW5hYmxlIElPIG9u
IHByaW1hcnkgdmdhIHBjaSBkZXYgMDM6MCAKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEu
MDcxXSBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKKGQxNikgWzIwMTQtMTEtMTcg
MTc6NDc6NDEuMDk1XSAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMg
Li4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6
NDEuMTIwXSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh
ciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTQ1
XSAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS
cyBbMS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTY5XSAgLSBD
UFUzIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84
XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTY5XSBUZXN0aW5nIEhW
TSBlbnZpcm9ubWVudDoKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTc4XSAgLSBSRVAg
SU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxNikgWzIwMTQtMTEt
MTcgMTc6NDc6NDEuMTgyXSAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2Vk
CihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjE4Ml0gUGFzc2VkIDIgb2YgMiB0ZXN0cwoo
ZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xODJdIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAu
Li4KKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTgzXSBMb2FkaW5nIFNlYUJJT1MgLi4u
CihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjE4M10gQ3JlYXRpbmcgTVAgdGFibGVzIC4u
LgooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xODNdIExvYWRpbmcgQUNQSSAuLi4KKGQx
NikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTg0XSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE2
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xODVdIEJJT1MgbWFwOgooZDE2KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0MS4xODVdICAxMDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE2KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0MS4xODVdICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTYpIFsy
MDE0LTExLTE3IDE3OjQ3OjQxLjE4NV0gRTgyMCB0YWJsZToKKGQxNikgWzIwMTQtMTEtMTcg
MTc6NDc6NDEuMTg1XSAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBh
MDAwMDogUkFNCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjE4NV0gIEhPTEU6IDAwMDAw
MDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwYzAwMDAKKGQxNikgWzIwMTQtMTEtMTcgMTc6
NDc6NDEuMTg1XSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAw
MDogUkVTRVJWRUQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTg1XSAgWzAyXTogMDAw
MDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDozZjgwMDAwMDogUkFNCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQxLjE4NV0gIEhPTEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6
ZmMwMDAwMDAKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTg1XSAgWzAzXTogMDAwMDAw
MDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxNikgWzIwMTQt
MTEtMTcgMTc6NDc6NDEuMTg1XSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE2KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0MS4xODhdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4
OGMtMjAxNDExMTdfMTgxNTQ3LXNlcnZlZXJzdGVydGplKQooZDE2KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0MS4xODhdIAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xODhdIEZvdW5kIFhl
biBoeXBlcnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMAooZDE2KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0MS4xODhdIFJ1bm5pbmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE2KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0MS4xODhdIHhlbjogY29weSBlODIwLi4uCihkMTYpIFsyMDE0LTExLTE3IDE3
OjQ3OjQxLjE4OF0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZTJlOSB0byAweDNmN2Fl
NGYwIChzaXplIDcyMjY3KQooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xOTBdIENQVSBN
aHo9MzIwMgooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xOTZdIEZvdW5kIDEwIFBDSSBk
ZXZpY2VzIChtYXggUENJIGJ1cyBpcyAwMCkKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEu
MTk2XSBBbGxvY2F0ZWQgWGVuIGh5cGVyY2FsbCBwYWdlIGF0IDNmN2ZmMDAwCihkMTYpIFsy
MDE0LTExLTE3IDE3OjQ3OjQxLjE5Nl0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS4xOTZdIHhlbjogY29weSBCSU9TIHRhYmxlcy4uLgooZDE2
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xOTZdIENvcHlpbmcgU01CSU9TIGVudHJ5IHBvaW50
IGZyb20gMHgwMDAxMDAxMCB0byAweDAwMGY1ZGUwCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3
OjQxLjE5Nl0gQ29weWluZyBNUFRBQkxFIGZyb20gMHhmYzAwMTFhMC9mYzAwMTFiMCB0byAw
eDAwMGY1Y2MwCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjE5Nl0gQ29weWluZyBQSVIg
ZnJvbSAweDAwMDEwMDMwIHRvIDB4MDAwZjVjNDAKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6
NDEuMTk2XSBDb3B5aW5nIEFDUEkgUlNEUCBmcm9tIDB4MDAwMTAwYjAgdG8gMHgwMDBmNWMx
MAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4xOTZdIFVzaW5nIHBtdGltZXIsIGlvcG9y
dCAweGIwMDgKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMTk2XSBTY2FuIGZvciBWR0Eg
b3B0aW9uIHJvbQooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4yMTNdIFJ1bm5pbmcgb3B0
aW9uIHJvbSBhdCBjMDAwOjAwMDMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMjIxXSBz
dGR2Z2EuYzoxNDc6ZDE2djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihk
MTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjI0N10gcG1tIGNhbGwgYXJnMT0wCihkMTYpIFsy
MDE0LTExLTE3IDE3OjQ3OjQxLjI0OF0gVHVybmluZyBvbiB2Z2EgdGV4dCBtb2RlIGNvbnNv
bGUKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzY0XSBTZWFCSU9TICh2ZXJzaW9uIHJl
bC0xLjcuNS0wLWdlNTE0ODhjLTIwMTQxMTE3XzE4MTU0Ny1zZXJ2ZWVyc3RlcnRqZSkKKGQx
NikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzc3XSBNYWNoaW5lIFVVSUQgYjAyNDU1MDktOTIw
NC00Yzk2LWJiNDItOThjMDIwYjEwZjA1CihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM3
N10gLzNmN2FkMDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEu
Mzc3XSB8M2Y3YWQwMDB8IFhIQ0kgaW5pdCBvbiBkZXYgMDA6MDUuMDogcmVncyBAIDB4ZjMy
NzAwMDAsIDQgcG9ydHMsIDMyIHNsb3RzLCAzMiBiCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3
OjQxLjM3N10geXRlIGNvbnRleHRzCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM3N10g
fDNmN2FkMDAwfCBYSENJICAgIGV4dGNhcCAweDEgQCBmMzI3MDUwMAooZDE2KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0MS4zNzddIHwzZjdhZDAwMHwgWEhDSSAgICBwcm90b2NvbCBVU0IgIDMu
MDAsIDIgcG9ydHMgKG9mZnNldCAxKSwgZGVmIDAKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6
NDEuMzc3XSB8M2Y3YWQwMDB8IFhIQ0kgICAgcHJvdG9jb2wgVVNCICAyLjAwLCAyIHBvcnRz
IChvZmZzZXQgMyksIGRlZiAwCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM3OF0gLzNm
N2FiMDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzc4XSAv
M2Y3YWEwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4zNzhd
IHwzZjdhZDAwMHwgVUhDSSBpbml0IG9uIGRldiAwMDowMS4yIChpbz1jMTQwKQooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS4zNzldIC8zZjdhOTAwMFwgU3RhcnQgdGhyZWFkCihkMTYp
IFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM3OV0gLzNmN2E4MDAwXCBTdGFydCB0aHJlYWQKKGQx
NikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzc5XSBGb3VuZCAwIGxwdCBwb3J0cwooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS4zODBdIEZvdW5kIDEgc2VyaWFsIHBvcnRzCihkMTYpIFsy
MDE0LTExLTE3IDE3OjQ3OjQxLjM4MF0gQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0LzAg
KGlycSAxNCBkZXYgOSkKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzgwXSAvM2Y3YTcw
MDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4zODJdIFwzZjdh
ZDAwMC8gRW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS4zODJdIC8zZjdh
NjAwMFwgU3RhcnQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM4Ml0gXDNm
N2E2MDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM4Ml0gQVRB
IGNvbnRyb2xsZXIgMiBhdCAxNzAvMzc0LzAgKGlycSAxNSBkZXYgOSkKKGQxNikgWzIwMTQt
MTEtMTcgMTc6NDc6NDEuMzgyXSAvM2Y3YTYwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0MS4zODNdIFwzZjdhNjAwMC8gRW5kIHRocmVhZAooZDE2KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0MS4zODVdIHwzZjdhNzAwMHwgYXRhMC0wOiBRRU1VIEhBUkRESVNL
IEFUQS03IEhhcmQtRGlzayAoMTAyNDAgTWlCeXRlcykKKGQxNikgWzIwMTQtMTEtMTcgMTc6
NDc6NDEuMzg1XSB8M2Y3YTcwMDB8IFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkw
Y2Y4LypAMSwxL2RyaXZlQDAvZGlza0AwCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM4
N10gfDNmN2E3MDAwfCBhdGEwLTE6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgz
MDAgR2lCeXRlcykKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuMzg3XSB8M2Y3YTcwMDB8
IFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4LypAMSwxL2RyaXZlQDAvZGlz
a0AxCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjM4N10gXDNmN2E3MDAwLyBFbmQgdGhy
ZWFkCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjQ0Nl0gfDNmN2E4MDAwfCB1c2JfaGlk
X3NldHVwIDB4M2Y3YWRkYmMKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNDQ2XSBcM2Y3
YTgwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNDQ3XSBcM2Y3
YTkwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNDgxXSAvM2Y3
YTkwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS40ODFdIFwz
ZjdhOTAwMC8gRW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS40ODFdIC8z
ZjdhOTAwMFwgU3RhcnQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjQ4MV0g
XDNmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjQ4Ml0g
LzNmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNDgy
XSBcM2Y3YTkwMDAvIEVuZCB0aHJlYWQKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNDgy
XSAvM2Y3YTkwMDBcIFN0YXJ0IHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS40
ODVdIHwzZjdhYTAwMHwgUFMyIGtleWJvYXJkIGluaXRpYWxpemVkCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQxLjQ4NV0gXDNmN2FhMDAwLyBFbmQgdGhyZWFkCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQxLjUzMl0gfDNmN2E5MDAwfCBYSENJIHBvcnQgIzQ6IDB4MDAyMDBhMDMs
IHBvd2VyZWQsIGVuYWJsZWQsIHBscyAwLCBzcGVlZCAyIFtMb3ddCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQxLjU2Ml0gfDNmN2E5MDAwfCB1c2JfaGlkX3NldHVwIDB4M2Y3ZmVjMjAK
KGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNTYyXSBcM2Y3YTkwMDAvIEVuZCB0aHJlYWQK
KGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDEuNTYzXSB8M2Y3YWIwMDB8IFhIQ0kgbm8gZGV2
aWNlcyBmb3VuZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS41NjhdIFwzZjdhYjAwMC8g
RW5kIHRocmVhZAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS41NjhdIEFsbCB0aHJlYWRz
IGNvbXBsZXRlLgooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS41NjhdIFNjYW4gZm9yIG9w
dGlvbiByb21zCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQxLjU5NV0gUnVubmluZyBvcHRp
b24gcm9tIGF0IGM5ODA6MDAwMwooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MDFdIHBt
bSBjYWxsIGFyZzE9MQooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MDFdIHBtbSBjYWxs
IGFyZzE9MAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MDNdIHBtbSBjYWxsIGFyZzE9
MQooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MDNdIHBtbSBjYWxsIGFyZzE9MAooZDE2
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MjBdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAv
cGNpQGkwY2Y4LypANAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MjBdIAooZDE2KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0MS42MjddIFByZXNzIEYxMiBmb3IgYm9vdCBtZW51LgooZDE2
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0MS42MjddIAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0
NC4xODRdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTYpIFsyMDE0LTExLTE3
IDE3OjQ3OjQ0LjE4NF0gZHJpdmUgMHgwMDBmNWJjMDogUENIUz0xNjM4My8xNi82MyB0cmFu
c2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwCihkMTYpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQ0LjE4NF0gZHJpdmUgMHgwMDBmNWI5MDogUENIUz0xNjM4My8xNi82MyB0
cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTYyOTE0NTYwMAooZDE2KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0NC4xODRdIAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0NC4xODRd
IFNwYWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjU2MDAtZjViOTAKKGQx
NikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTg0XSBSZXR1cm5lZCAyNTM5NTIgYnl0ZXMgb2Yg
Wm9uZUhpZ2gKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTg0XSBlODIwIG1hcCBoYXMg
NiBpdGVtczoKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTg1XSAgIDA6IDAwMDAwMDAw
MDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0KKGQxNikgWzIwMTQtMTEtMTcg
MTc6NDc6NDQuMTg1XSAgIDE6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEwMDAw
ID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0NC4xODVdICAgMjogMDAw
MDAwMDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgPSAyIFJFU0VSVkVECihkMTYpIFsy
MDE0LTExLTE3IDE3OjQ3OjQ0LjE4NV0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAw
MDAzZjdmZTAwMCA9IDEgUkFNCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQ0LjE4NV0gICA0
OiAwMDAwMDAwMDNmN2ZlMDAwIC0gMDAwMDAwMDAzZjgwMDAwMCA9IDIgUkVTRVJWRUQKKGQx
NikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTg1XSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAgLSAw
MDAwMDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xNyAxNzo0Nzo0
NC4xODZdIGVudGVyIGhhbmRsZV8xOToKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTg2
XSAgIE5VTEwKKGQxNikgWzIwMTQtMTEtMTcgMTc6NDc6NDQuMTkyXSBCb290aW5nIGZyb20g
SGFyZCBEaXNrLi4uCihkMTYpIFsyMDE0LTExLTE3IDE3OjQ3OjQ0LjE5NF0gQm9vdGluZyBm
cm9tIDAwMDA6N2MwMAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0Ni4wMDldIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQ3LjA4OV0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2
MyBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA3IGZyYW1lcwooWEVOKSBbMjAxNC0xMS0x
NyAxNzo0Nzo0OC44OThdIGlvLmM6NTUwOiBkMTc6IGJpbmQ6IG1fZ3NpPTQwIGdfZ3NpPTM2
IGRldj0wMC4wMC41IGludHg9MAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMDJdIEFN
RC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHg0MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMwooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMDJdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NDAwLCB0eXBlID0gMHgxLCByb290IHRh
YmxlID0gMHgzZGE0OTQwMDAsIGRvbWFpbiA9IDE3LCBwYWdpbmcgbW9kZSA9IDMKKFhFTikg
WzIwMTQtMTEtMTcgMTc6NDc6NDkuMTAyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjA0OjAw
LjAgZnJvbSBkb20wIHRvIGRvbTE3CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjExMV0g
SFZNIExvYWRlcgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMTFdIERldGVjdGVkIFhl
biB2NC41LjAtcmMKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMTEyXSBYZW5idXMgcmlu
Z3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgMQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0
Nzo0OS4xMTJdIFN5c3RlbSByZXF1ZXN0ZWQgU2VhQklPUwooZDE3KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0OS4xMTJdIENQVSBzcGVlZCBpcyAzMjAwIE1IegooZDE3KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0OS4xMTJdIFJlbG9jYXRpbmcgZ3Vlc3QgbWVtb3J5IGZvciBsb3dtZW0gTU1JTyBz
cGFjZSBkaXNhYmxlZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMTJdIGlycS5jOjI3
MDogRG9tMTcgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQooZDE3KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0OS4xMTJdIFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1CihYRU4pIFsyMDE0
LTExLTE3IDE3OjQ3OjQ5LjExM10gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAxIGNoYW5n
ZWQgMCAtPiAxMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMTNdIFBDSS1JU0EgbGlu
ayAxIHJvdXRlZCB0byBJUlExMAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4xMTNdIGly
cS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTEKKGQxNykgWzIwMTQt
MTEtMTcgMTc6NDc6NDkuMTEzXSBQQ0ktSVNBIGxpbmsgMiByb3V0ZWQgdG8gSVJRMTEKKFhF
TikgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMTEzXSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5r
IDMgY2hhbmdlZCAwIC0+IDUKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMTEzXSBQQ0kt
SVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4x
MzNdIHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0
OS4xMzldIHBjaSBkZXYgMDI6MCBJTlRBLT5JUlExMQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0
Nzo0OS4xNTBdIHBjaSBkZXYgMDQ6MCBJTlRBLT5JUlE1CihkMTcpIFsyMDE0LTExLTE3IDE3
OjQ3OjQ5LjE1Nl0gcGNpIGRldiAwNTowIElOVEEtPklSUTEwCihkMTcpIFsyMDE0LTExLTE3
IDE3OjQ3OjQ5LjIwNl0gTm8gUkFNIGluIGhpZ2ggbWVtb3J5OyBzZXR0aW5nIGhpZ2hfbWVt
IHJlc291cmNlIGJhc2UgdG8gMTAwMDAwMDAwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5
LjIwNl0gcGNpIGRldiAwMzowIGJhciAxMCBzaXplIDAwMjAwMDAwMDogMGYwMDAwMDA4Cihk
MTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjIwOF0gcGNpIGRldiAwMjowIGJhciAxNCBzaXpl
IDAwMTAwMDAwMDogMGYyMDAwMDA4CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjIxMF0g
cGNpIGRldiAwNDowIGJhciAzMCBzaXplIDAwMDA0MDAwMDogMGYzMDAwMDAwCihkMTcpIFsy
MDE0LTExLTE3IDE3OjQ3OjQ5LjIxMl0gcGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAwMDAy
MDAwMDogMGYzMDQwMDAwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjIxMl0gcGNpIGRl
diAwMzowIGJhciAzMCBzaXplIDAwMDAxMDAwMDogMGYzMDYwMDAwCihkMTcpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQ5LjIxMl0gcGNpIGRldiAwNTowIGJhciAxMCBzaXplIDAwMDAwMjAwMDog
MGYzMDcwMDA0CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjIxM10gbWVtb3J5X21hcDph
ZGQ6IGRvbTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9MQooZDE3KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo0OS4yMThdIHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDA6IDBmMzA3
MjAwMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yMTldIHBjaSBkZXYgMDI6MCBiYXIg
MTAgc2l6ZSAwMDAwMDAxMDA6IDAwMDAwYzAwMQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0
OS4yMjFdIHBjaSBkZXYgMDQ6MCBiYXIgMTQgc2l6ZSAwMDAwMDAwNDA6IDAwMDAwYzEwMQoo
ZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yMjNdIHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6
ZSAwMDAwMDAwMTA6IDAwMDAwYzE0MQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yMjVd
ID8hPyE/IT8hPyBlbmFibGUgSU8gb24gcHJpbWFyeSB2Z2EgcGNpIGRldiAwMzowIAooZDE3
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yMjVdIE11bHRpcHJvY2Vzc29yIGluaXRpYWxpc2F0
aW9uOgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yNDhdICAtIENQVTAgLi4uIDQ4LWJp
dCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLgoo
ZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4yNzJdICAtIENQVTEgLi4uIDQ4LWJpdCBwaHlz
IC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLgooZDE3KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0OS4yOTddICAtIENQVTIgLi4uIDQ4LWJpdCBwaHlzIC4uLiBm
aXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLgooZDE3KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0OS4yOTddIFRlc3RpbmcgSFZNIGVudmlyb25tZW50OgooZDE3KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0OS4zMDZdICAtIFJFUCBJTlNCIGFjcm9zcyBwYWdlIGJvdW5kYXJp
ZXMgLi4uIHBhc3NlZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMTFdICAtIEdTIGJh
c2UgTVNScyBhbmQgU1dBUEdTIC4uLiBwYXNzZWQKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6
NDkuMzExXSBQYXNzZWQgMiBvZiAyIHRlc3RzCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5
LjMxMV0gV3JpdGluZyBTTUJJT1MgdGFibGVzIC4uLgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0
Nzo0OS4zMTJdIExvYWRpbmcgU2VhQklPUyAuLi4KKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6
NDkuMzEyXSBDcmVhdGluZyBNUCB0YWJsZXMgLi4uCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3
OjQ5LjMxMl0gTG9hZGluZyBBQ1BJIC4uLgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4z
MTNdIHZtODYgVFNTIGF0IGZjMDBhMjAwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMx
NF0gQklPUyBtYXA6CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxNF0gIDEwMDAwLTEw
MGQzOiBTY3JhdGNoIHNwYWNlCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxNF0gIGMw
MDAwLWZmZmZmOiBNYWluIEJJT1MKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMzE0XSBF
ODIwIHRhYmxlOgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMTRdICBbMDBdOiAwMDAw
MDAwMDowMDAwMDAwMCAtIDAwMDAwMDAwOjAwMGEwMDAwOiBSQU0KKGQxNykgWzIwMTQtMTEt
MTcgMTc6NDc6NDkuMzE0XSAgSE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDow
MDBjMDAwMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMTRdICBbMDFdOiAwMDAwMDAw
MDowMDBjMDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBSRVNFUlZFRAooZDE3KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0OS4zMTRdICBbMDJdOiAwMDAwMDAwMDowMDEwMDAwMCAtIDAwMDAwMDAw
OjFmODAwMDAwOiBSQU0KKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMzE0XSAgSE9MRTog
MDAwMDAwMDA6MWY4MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMAooZDE3KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0OS4zMTRdICBbMDNdOiAwMDAwMDAwMDpmYzAwMDAwMCAtIDAwMDAwMDAxOjAw
MDAwMDAwOiBSRVNFUlZFRAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMTVdIEludm9r
aW5nIFNlYUJJT1MgLi4uCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxN10gU2VhQklP
UyAodmVyc2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTExN18xODE1NDctc2VydmVl
cnN0ZXJ0amUpCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxN10gCihkMTcpIFsyMDE0
LTExLTE3IDE3OjQ3OjQ5LjMxN10gRm91bmQgWGVuIGh5cGVydmlzb3Igc2lnbmF0dXJlIGF0
IDQwMDAwMDAwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxOF0gUnVubmluZyBvbiBR
RU1VIChpNDQwZngpCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMxOF0geGVuOiBjb3B5
IGU4MjAuLi4KKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMzE4XSBSZWxvY2F0aW5nIGlu
aXQgZnJvbSAweDAwMGRlMmU5IHRvIDB4MWY3YWU0ZjAgKHNpemUgNzIyNjcpCihkMTcpIFsy
MDE0LTExLTE3IDE3OjQ3OjQ5LjMyMF0gQ1BVIE1oej0zMjAxCihkMTcpIFsyMDE0LTExLTE3
IDE3OjQ3OjQ5LjMyNl0gRm91bmQgOCBQQ0kgZGV2aWNlcyAobWF4IFBDSSBidXMgaXMgMDAp
CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMyNl0gQWxsb2NhdGVkIFhlbiBoeXBlcmNh
bGwgcGFnZSBhdCAxZjdmZjAwMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMjZdIERl
dGVjdGVkIFhlbiB2NC41LjAtcmMKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMzI2XSB4
ZW46IGNvcHkgQklPUyB0YWJsZXMuLi4KKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuMzI2
XSBDb3B5aW5nIFNNQklPUyBlbnRyeSBwb2ludCBmcm9tIDB4MDAwMTAwMTAgdG8gMHgwMDBm
NWRlMAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zMjZdIENvcHlpbmcgTVBUQUJMRSBm
cm9tIDB4ZmMwMDExODAvZmMwMDExOTAgdG8gMHgwMDBmNWNkMAooZDE3KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0OS4zMjZdIENvcHlpbmcgUElSIGZyb20gMHgwMDAxMDAzMCB0byAweDAwMGY1
YzUwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjMyNl0gQ29weWluZyBBQ1BJIFJTRFAg
ZnJvbSAweDAwMDEwMGIwIHRvIDB4MDAwZjVjMjAKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6
NDkuMzI2XSBVc2luZyBwbXRpbWVyLCBpb3BvcnQgMHhiMDA4CihkMTcpIFsyMDE0LTExLTE3
IDE3OjQ3OjQ5LjMyNl0gU2NhbiBmb3IgVkdBIG9wdGlvbiByb20KKGQxNykgWzIwMTQtMTEt
MTcgMTc6NDc6NDkuMzQxXSBSdW5uaW5nIG9wdGlvbiByb20gYXQgYzAwMDowMDAzCihYRU4p
IFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjM1MF0gc3RkdmdhLmM6MTQ3OmQxN3YwIGVudGVyaW5n
IHN0ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4z
NzddIHBtbSBjYWxsIGFyZzE9MAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS4zNzhdIFR1
cm5pbmcgb24gdmdhIHRleHQgbW9kZSBjb25zb2xlCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3
OjQ5LjUwMV0gU2VhQklPUyAodmVyc2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTEx
N18xODE1NDctc2VydmVlcnN0ZXJ0amUpCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjUx
NF0gTWFjaGluZSBVVUlEIDdkMzhhZDM0LTNmZWUtNDdjZS05ZTNiLTg0Yjc1MGMyNmMwYgoo
ZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS41MTRdIC8xZjdhZDAwMFwgU3RhcnQgdGhyZWFk
CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjUxNV0gfDFmN2FkMDAwfCBYSENJIGluaXQg
b24gZGV2IDAwOjA1LjA6IHJlZ3MgQCAweGYzMDcwMDAwLCA0IHBvcnRzLCAzMiBzbG90cywg
MzIgYgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS41MTVdIHl0ZSBjb250ZXh0cwooZDE3
KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS41MTVdIHwxZjdhZDAwMHwgWEhDSSAgICBleHRjYXAg
MHgxIEAgZjMwNzA1MDAKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNTE1XSB8MWY3YWQw
MDB8IFhIQ0kgICAgcHJvdG9jb2wgVVNCICAzLjAwLCAyIHBvcnRzIChvZmZzZXQgMSksIGRl
ZiAwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjUxNV0gfDFmN2FkMDAwfCBYSENJICAg
IHByb3RvY29sIFVTQiAgMi4wMCwgMiBwb3J0cyAob2Zmc2V0IDMpLCBkZWYgMAooZDE3KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0OS41MTVdIC8xZjdhYzAwMFwgU3RhcnQgdGhyZWFkCihkMTcp
IFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjUxNV0gLzFmN2FhMDAwXCBTdGFydCB0aHJlYWQKKGQx
NykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNTE2XSBcMWY3YWQwMDAvIEVuZCB0aHJlYWQKKGQx
NykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNTE2XSBGb3VuZCAwIGxwdCBwb3J0cwooZDE3KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0OS41MTZdIEZvdW5kIDEgc2VyaWFsIHBvcnRzCihkMTcpIFsy
MDE0LTExLTE3IDE3OjQ3OjQ5LjUxNl0gQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0LzAg
KGlycSAxNCBkZXYgOSkKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNTE3XSAvMWY3YTkw
MDBcIFN0YXJ0IHRocmVhZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS41MTddIEFUQSBj
b250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUgZGV2IDkpCihkMTcpIFsyMDE0LTEx
LTE3IDE3OjQ3OjQ5LjUxN10gLzFmN2E4MDAwXCBTdGFydCB0aHJlYWQKKGQxNykgWzIwMTQt
MTEtMTcgMTc6NDc6NDkuNTE4XSBcMWY3YTgwMDAvIEVuZCB0aHJlYWQKKGQxNykgWzIwMTQt
MTEtMTcgMTc6NDc6NDkuNTIyXSB8MWY3YTkwMDB8IGF0YTAtMDogUUVNVSBIQVJERElTSyBB
VEEtNyBIYXJkLURpc2sgKDUxMjAgTWlCeXRlcykKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6
NDkuNTIyXSB8MWY3YTkwMDB8IFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4
LypAMSwxL2RyaXZlQDAvZGlza0AwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjUyM10g
XDFmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjYxNl0g
LzFmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNjE2
XSBcMWY3YTkwMDAvIEVuZCB0aHJlYWQKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6NDkuNjE2
XSAvMWY3YTkwMDBcIFN0YXJ0IHRocmVhZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS42
MTZdIFwxZjdhOTAwMC8gRW5kIHRocmVhZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS42
MTZdIC8xZjdhOTAwMFwgU3RhcnQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5
LjYxNl0gXDFmN2E5MDAwLyBFbmQgdGhyZWFkCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5
LjYxNl0gLzFmN2E5MDAwXCBTdGFydCB0aHJlYWQKKGQxNykgWzIwMTQtMTEtMTcgMTc6NDc6
NDkuNjIwXSB8MWY3YWEwMDB8IFBTMiBrZXlib2FyZCBpbml0aWFsaXplZAooZDE3KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0OS42MjBdIFwxZjdhYTAwMC8gRW5kIHRocmVhZAooZDE3KSBbMjAx
NC0xMS0xNyAxNzo0Nzo0OS42NjddIHwxZjdhOTAwMHwgWEhDSSBwb3J0ICM0OiAweDAwMjAw
ZTAzLCBwb3dlcmVkLCBlbmFibGVkLCBwbHMgMCwgc3BlZWQgMyBbSGlnaF0KKGQxNykgWzIw
MTQtMTEtMTcgMTc6NDc6NDkuNjgxXSBcMWY3YTkwMDAvIEVuZCB0aHJlYWQKKGQxNykgWzIw
MTQtMTEtMTcgMTc6NDc6NDkuNjgxXSB8MWY3YWMwMDB8IFhIQ0kgbm8gZGV2aWNlcyBmb3Vu
ZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS42ODhdIFwxZjdhYzAwMC8gRW5kIHRocmVh
ZAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS42ODhdIEFsbCB0aHJlYWRzIGNvbXBsZXRl
LgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS42ODhdIFNjYW4gZm9yIG9wdGlvbiByb21z
CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjQ5LjcxM10gUnVubmluZyBvcHRpb24gcm9tIGF0
IGM5ODA6MDAwMwooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS43MjBdIHBtbSBjYWxsIGFy
ZzE9MQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS43MjBdIHBtbSBjYWxsIGFyZzE9MAoo
ZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS43MjFdIHBtbSBjYWxsIGFyZzE9MQooZDE3KSBb
MjAxNC0xMS0xNyAxNzo0Nzo0OS43MjJdIHBtbSBjYWxsIGFyZzE9MAooZDE3KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0OS43MzldIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4
LypANAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo0OS43MzldIAooZDE3KSBbMjAxNC0xMS0x
NyAxNzo0Nzo0OS43NDZdIFByZXNzIEYxMiBmb3IgYm9vdCBtZW51LgooZDE3KSBbMjAxNC0x
MS0xNyAxNzo0Nzo0OS43NDddIAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo1MC44MjZdIHN0
ZHZnYS5jOjE1MTpkMTZ2MCBsZWF2aW5nIHN0ZHZnYQooZDE3KSBbMjAxNC0xMS0xNyAxNzo0
Nzo1Mi4zMTNdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTcpIFsyMDE0LTEx
LTE3IDE3OjQ3OjUyLjMxM10gZHJpdmUgMHgwMDBmNWJkMDogUENIUz0xMDQwMi8xNi82MyB0
cmFuc2xhdGlvbj1sYmEgTENIUz02NTIvMjU1LzYzIHM9MTA0ODU3NjAKKGQxNykgWzIwMTQt
MTEtMTcgMTc6NDc6NTIuMzEzXSBTcGFjZSBhdmFpbGFibGUgZm9yIFVNQjogY2E4MDAtZWYw
MDAsIGY1NjAwLWY1YmQwCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUyLjMxM10gUmV0dXJu
ZWQgMjUzOTUyIGJ5dGVzIG9mIFpvbmVIaWdoCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUy
LjMxM10gZTgyMCBtYXAgaGFzIDYgaXRlbXM6CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUy
LjMxM10gICAwOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZmMwMCA9IDEgUkFN
CihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUyLjMxM10gICAxOiAwMDAwMDAwMDAwMDlmYzAw
IC0gMDAwMDAwMDAwMDBhMDAwMCA9IDIgUkVTRVJWRUQKKGQxNykgWzIwMTQtMTEtMTcgMTc6
NDc6NTIuMzEzXSAgIDI6IDAwMDAwMDAwMDAwZjAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwID0g
MiBSRVNFUlZFRAooZDE3KSBbMjAxNC0xMS0xNyAxNzo0Nzo1Mi4zMTNdICAgMzogMDAwMDAw
MDAwMDEwMDAwMCAtIDAwMDAwMDAwMWY3ZmUwMDAgPSAxIFJBTQooZDE3KSBbMjAxNC0xMS0x
NyAxNzo0Nzo1Mi4zMTRdICAgNDogMDAwMDAwMDAxZjdmZTAwMCAtIDAwMDAwMDAwMWY4MDAw
MDAgPSAyIFJFU0VSVkVECihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUyLjMxNF0gICA1OiAw
MDAwMDAwMGZjMDAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCA9IDIgUkVTRVJWRUQKKGQxNykg
WzIwMTQtMTEtMTcgMTc6NDc6NTIuMzE0XSBlbnRlciBoYW5kbGVfMTk6CihkMTcpIFsyMDE0
LTExLTE3IDE3OjQ3OjUyLjMxNV0gICBOVUxMCihkMTcpIFsyMDE0LTExLTE3IDE3OjQ3OjUy
LjMyMV0gQm9vdGluZyBmcm9tIEhhcmQgRGlzay4uLgooZDE3KSBbMjAxNC0xMS0xNyAxNzo0
Nzo1Mi4zMjNdIEJvb3RpbmcgZnJvbSAwMDAwOjdjMDAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6
NDc6NTUuNDg2XSBIVk0gTG9hZGVyCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1LjQ4Nl0g
RGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS40ODZd
IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCAxCihkMTgpIFsyMDE0
LTExLTE3IDE3OjQ3OjU1LjQ4N10gU3lzdGVtIHJlcXVlc3RlZCBTZWFCSU9TCihkMTgpIFsy
MDE0LTExLTE3IDE3OjQ3OjU1LjQ4N10gQ1BVIHNwZWVkIGlzIDMyMDAgTUh6CihkMTgpIFsy
MDE0LTExLTE3IDE3OjQ3OjU1LjQ4N10gUmVsb2NhdGluZyBndWVzdCBtZW1vcnkgZm9yIGxv
d21lbSBNTUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3OjU1LjQ4
N10gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1CihkMTgpIFsy
MDE0LTExLTE3IDE3OjQ3OjU1LjQ4N10gUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNDg3XSBpcnEuYzoyNzA6IERvbTE4IFBDSSBs
aW5rIDEgY2hhbmdlZCAwIC0+IDEwCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1LjQ4N10g
UENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ3
OjU1LjQ4N10gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAyIGNoYW5nZWQgMCAtPiAxMQoo
ZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS40ODddIFBDSS1JU0EgbGluayAyIHJvdXRlZCB0
byBJUlExMQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS40ODhdIGlycS5jOjI3MDogRG9t
MTggUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1
NS40ODhdIFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1CihkMTgpIFsyMDE0LTExLTE3
IDE3OjQ3OjU1LjUwNV0gcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihkMTgpIFsyMDE0LTEx
LTE3IDE3OjQ3OjU1LjUwOV0gcGNpIGRldiAwMjowIElOVEEtPklSUTExCihkMTgpIFsyMDE0
LTExLTE3IDE3OjQ3OjU1LjUxOV0gcGNpIGRldiAwNDowIElOVEEtPklSUTUKKGQxOCkgWzIw
MTQtMTEtMTcgMTc6NDc6NTUuNTY2XSBObyBSQU0gaW4gaGlnaCBtZW1vcnk7IHNldHRpbmcg
aGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDAKKGQxOCkgWzIwMTQtMTEtMTcg
MTc6NDc6NTUuNTY2XSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAyMDAwMDAwOiAwZjAw
MDAwMDgKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTY4XSBwY2kgZGV2IDAyOjAgYmFy
IDE0IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6
NTUuNTcwXSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUgMDAwMDQwMDAwOiAwZjMwMDAwMDAK
KGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTcyXSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNp
emUgMDAwMDIwMDAwOiAwZjMwNDAwMDAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTcy
XSBwY2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEwMDAwOiAwZjMwNjAwMDAKKGQxOCkg
WzIwMTQtMTEtMTcgMTc6NDc6NTUuNTc0XSBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDAw
MDAxMDAwOiAwZjMwNzAwMDAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTc0XSBwY2kg
ZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDEKKGQxOCkgWzIwMTQt
MTEtMTcgMTc6NDc6NTUuNTc2XSBwY2kgZGV2IDA0OjAgYmFyIDE0IHNpemUgMDAwMDAwMDQw
OiAwMDAwMGMxMDEKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTc4XSBwY2kgZGV2IDAx
OjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNDEKKGQxOCkgWzIwMTQtMTEtMTcg
MTc6NDc6NTUuNTgwXSA/IT8hPyE/IT8gZW5hYmxlIElPIG9uIHByaW1hcnkgdmdhIHBjaSBk
ZXYgMDM6MCAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTgwXSBNdWx0aXByb2Nlc3Nv
ciBpbml0aWFsaXNhdGlvbjoKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNTk5XSAgLSBD
UFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84
XSAuLi4gZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjE1XSAgLSBDUFUxIC4u
LiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4g
ZG9uZS4KKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjMzXSAgLSBDUFUyIC4uLiA0OC1i
aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4K
KGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjUyXSAgLSBDUFUzIC4uLiA0OC1iaXQgcGh5
cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxOCkg
WzIwMTQtMTEtMTcgMTc6NDc6NTUuNjUyXSBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoKKGQx
OCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjYxXSAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBi
b3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjY2XSAg
LSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCihkMTgpIFsyMDE0LTExLTE3
IDE3OjQ3OjU1LjY2Nl0gUGFzc2VkIDIgb2YgMiB0ZXN0cwooZDE4KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo1NS42NjZdIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KKGQxOCkgWzIwMTQtMTEt
MTcgMTc6NDc6NTUuNjY3XSBMb2FkaW5nIFNlYUJJT1MgLi4uCihkMTgpIFsyMDE0LTExLTE3
IDE3OjQ3OjU1LjY2N10gQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgooZDE4KSBbMjAxNC0xMS0x
NyAxNzo0Nzo1NS42NjddIExvYWRpbmcgQUNQSSAuLi4KKGQxOCkgWzIwMTQtMTEtMTcgMTc6
NDc6NTUuNjY4XSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE4KSBbMjAxNC0xMS0xNyAxNzo0
Nzo1NS42NjldIEJJT1MgbWFwOgooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NjldICAx
MDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42
NjldICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1
LjY2OV0gRTgyMCB0YWJsZToKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjY5XSAgWzAw
XTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkFNCihkMTgpIFsy
MDE0LTExLTE3IDE3OjQ3OjU1LjY2OV0gIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAw
MDAwMDA6MDAwYzAwMDAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjY5XSAgWzAxXTog
MDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQKKGQxOCkg
WzIwMTQtMTEtMTcgMTc6NDc6NTUuNjY5XSAgWzAyXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAw
MDAwMDAwMDozZjgwMDAwMDogUkFNCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1LjY2OV0g
IEhPTEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAwMDAKKGQxOCkgWzIw
MTQtMTEtMTcgMTc6NDc6NTUuNjY5XSAgWzAzXTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAw
MDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjY5
XSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzJd
IFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMTdfMTgxNTQ3
LXNlcnZlZXJzdGVydGplKQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzJdIAooZDE4
KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzJdIEZvdW5kIFhlbiBoeXBlcnZpc29yIHNpZ25h
dHVyZSBhdCA0MDAwMDAwMAooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzJdIFJ1bm5p
bmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzJdIHhl
bjogY29weSBlODIwLi4uCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1LjY3Ml0gUmVsb2Nh
dGluZyBpbml0IGZyb20gMHgwMDBkZTJlOSB0byAweDNmN2FlNGYwIChzaXplIDcyMjY3KQoo
ZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42NzVdIENQVSBNaHo9MzIwMQooZDE4KSBbMjAx
NC0xMS0xNyAxNzo0Nzo1NS42ODBdIEZvdW5kIDcgUENJIGRldmljZXMgKG1heCBQQ0kgYnVz
IGlzIDAwKQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42ODBdIEFsbG9jYXRlZCBYZW4g
aHlwZXJjYWxsIHBhZ2UgYXQgM2Y3ZmYwMDAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUu
NjgwXSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1
LjY4MF0geGVuOiBjb3B5IEJJT1MgdGFibGVzLi4uCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3
OjU1LjY4MF0gQ29weWluZyBTTUJJT1MgZW50cnkgcG9pbnQgZnJvbSAweDAwMDEwMDEwIHRv
IDB4MDAwZjVkZTAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuNjgwXSBDb3B5aW5nIE1Q
VEFCTEUgZnJvbSAweGZjMDAxMWEwL2ZjMDAxMWIwIHRvIDB4MDAwZjVjYzAKKGQxOCkgWzIw
MTQtMTEtMTcgMTc6NDc6NTUuNjgwXSBDb3B5aW5nIFBJUiBmcm9tIDB4MDAwMTAwMzAgdG8g
MHgwMDBmNWM0MAooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS42ODBdIENvcHlpbmcgQUNQ
SSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAwMGY1YzEwCihkMTgpIFsyMDE0LTExLTE3
IDE3OjQ3OjU1LjY4MF0gVXNpbmcgcG10aW1lciwgaW9wb3J0IDB4YjAwOAooZDE4KSBbMjAx
NC0xMS0xNyAxNzo0Nzo1NS42ODBdIFNjYW4gZm9yIFZHQSBvcHRpb24gcm9tCihkMTgpIFsy
MDE0LTExLTE3IDE3OjQ3OjU1LjY5Nl0gUnVubmluZyBvcHRpb24gcm9tIGF0IGMwMDA6MDAw
MwooWEVOKSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS43MDRdIHN0ZHZnYS5jOjE0NzpkMTh2MCBl
bnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMKKGQxOCkgWzIwMTQtMTEtMTcgMTc6
NDc6NTUuNzI2XSBwbW0gY2FsbCBhcmcxPTAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUu
NzI4XSBUdXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUgY29uc29sZQooZDE4KSBbMjAxNC0xMS0x
NyAxNzo0Nzo1NS44NDFdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMt
MjAxNDExMTdfMTgxNTQ3LXNlcnZlZXJzdGVydGplKQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0
Nzo1NS44NTRdIE1hY2hpbmUgVVVJRCBhNmUyY2Y3NC00YWZiLTRmM2MtOTc3NS0zOGNkZWRk
Zjc2ZjcKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuODU0XSAvM2Y3YWQwMDBcIFN0YXJ0
IHRocmVhZAooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS44NTRdIFwzZjdhZDAwMC8gRW5k
IHRocmVhZAooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS44NTRdIEFsbCB0aHJlYWRzIGNv
bXBsZXRlLgooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS44NTRdIC8zZjdhZDAwMFwgU3Rh
cnQgdGhyZWFkCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1Ljg1NV0gRm91bmQgMCBscHQg
cG9ydHMKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTUuODU1XSBGb3VuZCAwIHNlcmlhbCBw
b3J0cwooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS44NTZdIEFUQSBjb250cm9sbGVyIDEg
YXQgMWYwLzNmNC8wIChpcnEgMTQgZGV2IDkpCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1
Ljg1Nl0gLzNmN2FjMDAwXCBTdGFydCB0aHJlYWQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6
NTUuODU2XSBBVEEgY29udHJvbGxlciAyIGF0IDE3MC8zNzQvMCAoaXJxIDE1IGRldiA5KQoo
ZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS44NTZdIC8zZjdhYjAwMFwgU3RhcnQgdGhyZWFk
CihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1Ljg1N10gXDNmN2FiMDAwLyBFbmQgdGhyZWFk
CihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU1Ljg2MV0gfDNmN2FjMDAwfCBhdGEwLTA6IFFF
TVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgxMDI0MCBNaUJ5dGVzKQooZDE4KSBbMjAx
NC0xMS0xNyAxNzo0Nzo1NS44NjFdIHwzZjdhYzAwMHwgU2VhcmNoaW5nIGJvb3RvcmRlciBm
b3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDAKKGQxOCkgWzIwMTQtMTEtMTcg
MTc6NDc6NTUuODYyXSBcM2Y3YWMwMDAvIEVuZCB0aHJlYWQKKGQxOCkgWzIwMTQtMTEtMTcg
MTc6NDc6NTUuOTU5XSB8M2Y3YWQwMDB8IFBTMiBrZXlib2FyZCBpbml0aWFsaXplZAooZDE4
KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS45NTldIFwzZjdhZDAwMC8gRW5kIHRocmVhZAooZDE4
KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS45NTldIEFsbCB0aHJlYWRzIGNvbXBsZXRlLgooZDE4
KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS45NTldIFNjYW4gZm9yIG9wdGlvbiByb21zCihkMTgp
IFsyMDE0LTExLTE3IDE3OjQ3OjU1Ljk4Ml0gUnVubmluZyBvcHRpb24gcm9tIGF0IGM5ODA6
MDAwMwooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS45ODhdIHBtbSBjYWxsIGFyZzE9MQoo
ZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1NS45ODhdIHBtbSBjYWxsIGFyZzE9MAooZDE4KSBb
MjAxNC0xMS0xNyAxNzo0Nzo1NS45ODldIHBtbSBjYWxsIGFyZzE9MQooZDE4KSBbMjAxNC0x
MS0xNyAxNzo0Nzo1NS45OTBdIHBtbSBjYWxsIGFyZzE9MAooZDE4KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo1Ni4wMDhdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4LypANAoo
ZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1Ni4wMDhdIAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0
Nzo1Ni4wMDldIC0tTUFSSy0tCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU2LjAxNV0gUHJl
c3MgRjEyIGZvciBib290IG1lbnUuCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU2LjAxNV0g
CihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU3NF0gU2VhcmNoaW5nIGJvb3RvcmRlciBm
b3I6IEhBTFQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTguNTc0XSBkcml2ZSAweDAwMGY1
YmMwOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1LzYz
IHM9MjA5NzE1MjAKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTguNTc1XSBTcGFjZSBhdmFp
bGFibGUgZm9yIFVNQjogY2E4MDAtZWYwMDAsIGY1NjAwLWY1YmMwCihkMTgpIFsyMDE0LTEx
LTE3IDE3OjQ3OjU4LjU3NV0gUmV0dXJuZWQgMjU4MDQ4IGJ5dGVzIG9mIFpvbmVIaWdoCihk
MTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU3NV0gZTgyMCBtYXAgaGFzIDYgaXRlbXM6Cihk
MTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU3NV0gICAwOiAwMDAwMDAwMDAwMDAwMDAwIC0g
MDAwMDAwMDAwMDA5ZmMwMCA9IDEgUkFNCihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU3
NV0gICAxOiAwMDAwMDAwMDAwMDlmYzAwIC0gMDAwMDAwMDAwMDBhMDAwMCA9IDIgUkVTRVJW
RUQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTguNTc1XSAgIDI6IDAwMDAwMDAwMDAwZjAw
MDAgLSAwMDAwMDAwMDAwMTAwMDAwID0gMiBSRVNFUlZFRAooZDE4KSBbMjAxNC0xMS0xNyAx
Nzo0Nzo1OC41NzVdICAgMzogMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwM2Y3ZmYwMDAg
PSAxIFJBTQooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1OC41NzVdICAgNDogMDAwMDAwMDAz
ZjdmZjAwMCAtIDAwMDAwMDAwM2Y4MDAwMDAgPSAyIFJFU0VSVkVECihkMTgpIFsyMDE0LTEx
LTE3IDE3OjQ3OjU4LjU3NV0gICA1OiAwMDAwMDAwMGZjMDAwMDAwIC0gMDAwMDAwMDEwMDAw
MDAwMCA9IDIgUkVTRVJWRUQKKGQxOCkgWzIwMTQtMTEtMTcgMTc6NDc6NTguNTc2XSBlbnRl
ciBoYW5kbGVfMTk6CihkMTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU3Nl0gICBOVUxMCihk
MTgpIFsyMDE0LTExLTE3IDE3OjQ3OjU4LjU4Ml0gQm9vdGluZyBmcm9tIEhhcmQgRGlzay4u
LgooZDE4KSBbMjAxNC0xMS0xNyAxNzo0Nzo1OC41ODRdIEJvb3RpbmcgZnJvbSAwMDAwOjdj
MDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDc6NTkuMjI3XSBzdGR2Z2EuYzoxNTE6ZDE3djAg
bGVhdmluZyBzdGR2Z2EKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MDUuMzE1XSBzdGR2Z2Eu
YzoxNTE6ZDE4djAgbGVhdmluZyBzdGR2Z2EKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MDYu
MDA5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoxNi4wMTBdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjE2Ljg2OV0gc3RkdmdhLmM6MTQ3OmQxNnYwIGVu
dGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooWEVOKSBbMjAxNC0xMS0xNyAxNzo0
ODoxOC40NzBdIGlycS5jOjM4MDogRG9tMTYgY2FsbGJhY2sgdmlhIGNoYW5nZWQgdG8gRGly
ZWN0IFZlY3RvciAweGYzCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjE4LjYzN10gc3Rkdmdh
LmM6MTQ3OmQxN3YwIGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooWEVOKSBb
MjAxNC0xMS0xNyAxNzo0ODoyMC4yNDRdIGlycS5jOjM4MDogRG9tMTcgY2FsbGJhY2sgdmlh
IGNoYW5nZWQgdG8gRGlyZWN0IFZlY3RvciAweGYzCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4
OjIxLjY0MF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUg
bnI9MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMS42NDRdIG1lbW9yeV9tYXA6YWRkOiBk
b20xNyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6
MjEuNjQ3XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTcgZ2ZuPWYzMDcwIG1mbj1mZGRmZSBu
cj0xCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIxLjY1MV0gbWVtb3J5X21hcDphZGQ6IGRv
bTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoy
MS42NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5y
PTEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjEuNjU4XSBtZW1vcnlfbWFwOmFkZDogZG9t
MTcgZ2ZuPWYzMDcwIG1mbj1mZGRmZSBucj0xCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIx
LjY2Ml0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE3IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9
MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMS42NjddIG1lbW9yeV9tYXA6YWRkOiBkb20x
NyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjEu
NjcwXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTcgZ2ZuPWYzMDcwIG1mbj1mZGRmZSBucj0x
CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIxLjY3NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE3
IGdmbj1mMzA3MCBtZm49ZmRkZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMS42
NzddIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNyBnZm49ZjMwNzAgbWZuPWZkZGZlIG5yPTEK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjEuNjgwXSBtZW1vcnlfbWFwOmFkZDogZG9tMTcg
Z2ZuPWYzMDcwIG1mbj1mZGRmZSBucj0xCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIxLjcw
MV0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCihYRU4pIFsy
MDE0LTExLTE3IDE3OjQ4OjIxLjcwOF0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAxIGNo
YW5nZWQgMTAgLT4gMAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMS43MTRdIGlycS5jOjI3
MDogRG9tMTcgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDAKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NDg6MjEuNzIwXSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDMgY2hhbmdlZCA1IC0+
IDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMDYxXSBtZW1vcnlfbWFwOnJlbW92ZTog
ZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4
OjIyLjA2Nl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9
MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMi4wNzBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBk
b20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6
MjIuMDc0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0x
CihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIyLjA3N10gbWVtb3J5X21hcDpyZW1vdmU6IGRv
bTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoy
Mi4wODFdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMDg1XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9t
MTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIy
LjA4OV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQoo
WEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMi4wOTNdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20x
NiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIu
MDk3XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihY
RU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIyLjEwMV0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2
IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMi4x
MDVdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhF
TikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTE1XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYg
Z2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIu
MTIxXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTI2XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9t
MTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6
MjIuMTMxXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0y
MDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTM2XSBtZW1vcnlfbWFwOnJlbW92ZTog
ZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NDg6MjIuMTQyXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBu
cj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTQ4XSBtZW1vcnlfbWFwOnJlbW92
ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NDg6MjIuMTU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIw
MCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTYwXSBtZW1vcnlfbWFwOnJl
bW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEt
MTcgMTc6NDg6MjIuMTY3XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1m
ZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMTcyXSBtZW1vcnlfbWFw
OnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQt
MTEtMTcgMTc6NDg6MjIuMTc5XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1m
bj1mZTIwMCBucj0yMDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjIuMjIxXSBpcnEuYzoy
NzA6IERvbTE2IFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDAKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NDg6MjIuMjMzXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAt
PiAwCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjIyLjI0Nl0gaXJxLmM6MjcwOiBEb20xNiBQ
Q0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODoyMi4y
NTldIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMAooWEVOKSBb
MjAxNC0xMS0xNyAxNzo0ODoyMy4wNjZdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjIgSW5jcmVh
c2VkIG1hcHRyYWNrIHNpemUgdG8gOCBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6
MjMuNjgwXSBncmFudF90YWJsZS5jOjEyOTk6ZDE2djIgRXhwYW5kaW5nIGRvbSAoMTYpIGdy
YW50IHRhYmxlIGZyb20gKDQpIHRvICg1KSBmcmFtZXMuCihYRU4pIFsyMDE0LTExLTE3IDE3
OjQ4OjI2LjAxMF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MjcuNzgzXSBz
dGR2Z2EuYzoxNDc6ZDE4djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihY
RU4pIFsyMDE0LTExLTE3IDE3OjQ4OjI5LjQ0Ml0gaXJxLmM6MzgwOiBEb20xOCBjYWxsYmFj
ayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NDg6MzAuNjkyXSBpcnEuYzoyNzA6IERvbTE4IFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+
IDAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MzAuNjk4XSBpcnEuYzoyNzA6IERvbTE4IFBD
SSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ4OjMwLjcw
M10gaXJxLmM6MjcwOiBEb20xOCBQQ0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMAooWEVOKSBb
MjAxNC0xMS0xNyAxNzo0ODozMC43MDldIGlycS5jOjI3MDogRG9tMTggUENJIGxpbmsgMyBj
aGFuZ2VkIDUgLT4gMAooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODozMi4wNThdIGdyYW50X3Rh
YmxlLmM6MTI5OTpkMTh2MSBFeHBhbmRpbmcgZG9tICgxOCkgZ3JhbnQgdGFibGUgZnJvbSAo
NCkgdG8gKDUpIGZyYW1lcy4KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDg6MzYuMDEwXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODo0NS40NjldIGdyYW50X3RhYmxlLmM6MzA1
OmQwdjEgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gOSBmcmFtZXMKKFhFTikgWzIwMTQt
MTEtMTcgMTc6NDg6NDYuMDEwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0ODo1
Ni4wMTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ5OjA2LjAxMF0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDk6MTYuMDEwXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xNyAxNzo0OToyNi4wMTFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjQ5
OjM2LjAxMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NDk6NDYuMDExXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo0OTo1Ni4wMTFdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE3IDE3OjUwOjA2LjAxMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTA6MTYuMDEyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1MDoyNi4wMTJdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjUwOjM2LjAxMl0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTcgMTc6NTA6NDYuMDEyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAx
Nzo1MDo1Ni4wMTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjUxOjA2LjAxM10g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTE6MTYuMDEzXSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1MToyMy42MzNdIGdyYW50X3RhYmxlLmM6MTI5OTpkMTZ2MCBF
eHBhbmRpbmcgZG9tICgxNikgZ3JhbnQgdGFibGUgZnJvbSAoNSkgdG8gKDYpIGZyYW1lcy4K
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTE6MjYuMDEzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xNyAxNzo1MTozMy43NzVdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1h
cHRyYWNrIHNpemUgdG8gMTAgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE3IDE3OjUxOjM2LjAx
M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTE6NDYuMDEzXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xNyAxNzo1MTo1Ni4wMTNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE3IDE3OjUyOjA1Ljc0Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTI6MTUu
NzQyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1MjoyNS43NDJdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE3IDE3OjUyOjM1Ljc0Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTcgMTc6NTI6NDUuNzQyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Mjo1
NS43NDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjUzOjA1Ljc0M10gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTM6MTUuNzQzXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1MzoyNS43NDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjUz
OjM1Ljc0M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTM6NDUuNzQ0XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Mzo1NS43NDRdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE3IDE3OjU0OjA1Ljc0NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTQ6MTUuNzQ0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDoxOC42OTVdIENQ
VTAwOiAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6MTguNzA1XSBDUFUwMTogCihYRU4pIFsy
MDE0LTExLTE3IDE3OjU0OjE4LjcxNl0gZDE2IE9LLXNvZnRpcnEgNjJtc2VjIGFnbywgc3Rh
dGU6MSwgMjYyOCBjb3VudCwgW3ByZXY6ZmZmZjgzMDU0ZWY1N2U3MCwgbmV4dDpmZmZmODMw
NTRlZjU3ZTcwXSBmZmZmODMwNTFiOTA0NDI4PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVTVF9N
U0lfU0hJRlQgIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6MTguNzY1XSBkMTYg
T0stcmFpc2UgICAxMTJtc2VjIGFnbywgc3RhdGU6MSwgMjYyOCBjb3VudCwgW3ByZXY6MDAw
MDAwMDAwMDIwMDIwMCwgbmV4dDowMDAwMDAwMDAwMTAwMTAwXSBmZmZmODMwNTFiOTA0NDI4
PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJUlE6ODcKKFhFTikgWzIw
MTQtMTEtMTcgMTc6NTQ6MTguODE1XSBDUFUwMjogCihYRU4pIFsyMDE0LTExLTE3IDE3OjU0
OjE4LjgyNV0gZDE3IE9LLXNvZnRpcnEgNTAwbXNlYyBhZ28sIHN0YXRlOjEsIDM0MzkgY291
bnQsIFtwcmV2OmZmZmY4MzA1NGVmNDdlNzAsIG5leHQ6ZmZmZjgzMDU0ZWY0N2U3MF0gZmZm
ZjgzMDUxYTFjOGMyODxOVUxMPiBNQVBQRURfU0hJRlQgR1VFU1RfTVNJX1NISUZUICBQSVJR
Ojg3CihYRU4pIFsyMDE0LTExLTE3IDE3OjU0OjE4Ljg3NV0gZDE3IE9LLXJhaXNlICAgNTQ5
bXNlYyBhZ28sIHN0YXRlOjEsIDM0MzkgY291bnQsIFtwcmV2OjAwMDAwMDAwMDAyMDAyMDAs
IG5leHQ6MDAwMDAwMDAwMDEwMDEwMF0gZmZmZjgzMDUxYTFjOGMyODxOVUxMPiBNQVBQRURf
U0hJRlQgR1VFU1RfTVNJX1NISUZUICBQSVJROjg3CihYRU4pIFsyMDE0LTExLTE3IDE3OjU0
OjE4LjkyNF0gQ1BVMDM6IAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDoxOC45MzVdIGQxNiBP
Sy1zb2Z0aXJxIDMxM21zZWMgYWdvLCBzdGF0ZToxLCAzNTMzIGNvdW50LCBbcHJldjpmZmZm
ODMwNTRlZjM3ZTcwLCBuZXh0OmZmZmY4MzA1NGVmMzdlNzBdIGZmZmY4MzA1MWI5MDQ0Mjg8
TlVMTD4gTUFQUEVEX1NISUZUIEdVRVNUX01TSV9TSElGVCAgUElSUTo4NwooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1NDoxOC45ODRdIGQxNiBPSy1yYWlzZSAgIDM2M21zZWMgYWdvLCBzdGF0
ZToxLCAzNTMzIGNvdW50LCBbcHJldjowMDAwMDAwMDAwMjAwMjAwLCBuZXh0OjAwMDAwMDAw
MDAxMDAxMDBdIGZmZmY4MzA1MWI5MDQ0Mjg8TlVMTD4gTUFQUEVEX1NISUZUIEdVRVNUX01T
SV9TSElGVCAgUElSUTo4NwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDoxOS4wMzRdIENQVTA0
OiAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6MTkuMDQ0XSBkMTYgT0stc29mdGlycSAzNTlt
c2VjIGFnbywgc3RhdGU6MSwgMzY5MSBjb3VudCwgW3ByZXY6ZmZmZjgzMDU0ZWYyN2U4OCwg
bmV4dDpmZmZmODMwNTRlZjI3ZTg4XSBmZmZmODMwNTFiOTA0NDI4PE5VTEw+IE1BUFBFRF9T
SElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6
MTkuMDk0XSBkMTYgT0stcmFpc2UgICA0MDhtc2VjIGFnbywgc3RhdGU6MSwgMzY5MSBjb3Vu
dCwgW3ByZXY6MDAwMDAwMDAwMDIwMDIwMCwgbmV4dDowMDAwMDAwMDAwMTAwMTAwXSBmZmZm
ODMwNTFiOTA0NDI4PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJUlE6
ODcKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6MTkuMTQzXSBDUFUwNTogCihYRU4pIFsyMDE0
LTExLTE3IDE3OjU0OjE5LjE1NF0gZDE2IE9LLXNvZnRpcnEgNDU4bXNlYyBhZ28sIHN0YXRl
OjEsIDUyMDM5IGNvdW50LCBbcHJldjpmZmZmODMwNTRlZjI4M2UwLCBuZXh0OmZmZmY4MzA1
NGVmMjgzZTBdIGZmZmY4MzA1MWI5NWZkMjhNQUNIX1BDSV9TSElGVCBNQVBQRURfU0hJRlQg
R1VFU1RfUENJX1NISUZUICBQSVJROjAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6MTkuMjA1
XSBkMTYgT0stcmFpc2UgICA0ODltc2VjIGFnbywgc3RhdGU6MSwgNTIwNDkgY291bnQsIFtw
cmV2OjAwMDAwMDAwMDAyMDAyMDAsIG5leHQ6MDAwMDAwMDAwMDEwMDEwMF0gZmZmZjgzMDUx
Yjk1ZmQyOE1BQ0hfUENJX1NISUZUIE1BUFBFRF9TSElGVCBHVUVTVF9QQ0lfU0hJRlQgIFBJ
UlE6MAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDoxOS4yNTddIGQxNiBFUlItcG9pc29uIDU2
MW1zZWMgYWdvLCBzdGF0ZTowLCAxIGNvdW50LCBbcHJldjowMDAwMDAwMDAwMjAwMjAwLCBu
ZXh0OjAwMDAwMDAwMDAxMDAxMDBdIGZmZmY4MzA1MWI5NWZkMjhNQUNIX1BDSV9TSElGVCBN
QVBQRURfU0hJRlQgR1VFU1RfUENJX1NISUZUICBQSVJROjAKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTQ6MTkuMzA3XSBkMTYgWi1zb2Z0aXJxICA3MzFtc2VjIGFnbywgc3RhdGU6MywgMyBj
b3VudCwgW3ByZXY6ZmZmZjgzMDU0ZWYyODNlMCwgbmV4dDpmZmZmODMwNTRlZjI4M2UwXSBm
ZmZmODMwNTFiOTVmZDI4TUFDSF9QQ0lfU0hJRlQgTUFQUEVEX1NISUZUIEdVRVNUX1BDSV9T
SElGVCAgUElSUTowCihYRU4pIFsyMDE0LTExLTE3IDE3OjU0OjE5LjM1Nl0gZG9tYWluX2Ny
YXNoIGNhbGxlZCBmcm9tIGlvLmM6OTM4CihYRU4pIFsyMDE0LTExLTE3IDE3OjU0OjE5LjM1
Nl0gRG9tYWluIDE2IHJlcG9ydGVkIGNyYXNoZWQgYnkgZG9tYWluIDMyNzY3IG9uIGNwdSM1
OgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDoyNS43NTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE3IDE3OjU0OjM1Ljc1Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTQ6
NDUuNzUyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NDo1NS43NTNdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjU1OjA1Ljc1M10gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTcgMTc6NTU6MTUuNzUzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1
NToyNS43NTNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3OjU1OjM1Ljc1M10gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTU6NDUuNzU0XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1NTo1NS43NTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE3IDE3
OjU2OjA1Ljc1NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6MTUuNzU0XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1NjoyNS43NTRdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE3IDE3OjU2OjM1Ljc1NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NDUuNzU1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJd
IElSUSBpbmZvcm1hdGlvbjoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJ
UlE6ICAgMCBhZmZpbml0eTowMSB2ZWM6ZjAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVz
PTAwMDAwMDAwIHRpbWVyX2ludGVycnVwdCgpCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4Ml0gICAgSVJROiAgIDEgYWZmaW5pdHk6MDEgdmVjOjMwIHR5cGU9SU8tQVBJQy1lZGdl
ICAgIHN0YXR1cz0wMDAwMDAzNCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOiAgMSgtLS0p
LAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogICAzIGFmZmluaXR5
OjAxIHZlYzozOCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVk
LCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgIDQg
YWZmaW5pdHk6MDEgdmVjOmYxIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAw
MCBuczE2NTUwX2ludGVycnVwdCgpCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0g
ICAgSVJROiAgIDUgYWZmaW5pdHk6MDEgdmVjOjQwIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0
YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6
NTMuNTgyXSAgICBJUlE6ICAgNiBhZmZpbml0eTowMSB2ZWM6NDggdHlwZT1JTy1BUElDLWVk
Z2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0x
NyAxNzo1Njo1My41ODJdICAgIElSUTogICA3IGFmZmluaXR5OjAxIHZlYzo1MCB0eXBlPUlP
LUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsy
MDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgIDggYWZmaW5pdHk6MDEgdmVjOjU4
IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21h
aW4tbGlzdD0wOiAgOCgtLS0pLAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAg
IElSUTogICA5IGFmZmluaXR5OjNmIHZlYzo2MCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0
dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4Ml0gICAgSVJROiAgMTAgYWZmaW5pdHk6MDEgdmVjOjY4IHR5cGU9SU8tQVBJQy1lZGdl
ICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgyXSAgICBJUlE6ICAxMSBhZmZpbml0eTowMSB2ZWM6NzAgdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDEyIGFmZmluaXR5OjAxIHZlYzo3OCB0
eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWlu
LWxpc3Q9MDogMTIoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJ
UlE6ICAxMyBhZmZpbml0eTozZiB2ZWM6ODggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODJdICAgIElSUTogIDE0IGFmZmluaXR5OjAxIHZlYzo5MCB0eXBlPUlPLUFQSUMtZWRnZSAg
ICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3
OjU2OjUzLjU4Ml0gICAgSVJROiAgMTUgYWZmaW5pdHk6MDEgdmVjOjk4IHR5cGU9SU8tQVBJ
Qy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQt
MTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJUlE6ICAxNiBhZmZpbml0eTowMSB2ZWM6ODkgdHlw
ZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6IDE2KC0tLSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJR
OiAgMTcgYWZmaW5pdHk6MDEgdmVjOmMwIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0w
MDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOiAxNygtLS0pLAooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDE4IGFmZmluaXR5OjAxIHZlYzpiOCB0
eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWlu
LWxpc3Q9MDogMTgoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJ
UlE6ICAxOSBhZmZpbml0eTozZiB2ZWM6MmEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODJdICAgIElSUTogIDIyIGFmZmluaXR5OjAxIHZlYzpiOSB0eXBlPUlPLUFQSUMtbGV2ZWwg
ICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogMjIoLS0tKSwx
MzogMjIoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJUlE6ICAy
NSBhZmZpbml0eTozZiB2ZWM6OWEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAg
IElSUTogIDI4IGFmZmluaXR5OjNmIHZlYzoyMiB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0
dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4Ml0gICAgSVJROiAgMjkgYWZmaW5pdHk6M2YgdmVjOmQ5IHR5cGU9SU8tQVBJQy1sZXZl
bCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgyXSAgICBJUlE6ICAzMiBhZmZpbml0eTozZiB2ZWM6YzkgdHlwZT1JTy1B
UElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDMzIGFmZmluaXR5OjNmIHZlYzpjMSB0
eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihY
RU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgMzYgYWZmaW5pdHk6M2Yg
dmVjOjIxIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVu
Ym91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJUlE6ICAzNyBhZmZp
bml0eToyMCB2ZWM6MjkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiAzNygtTS0pLAooWEVOKSBbMjAxNC0xMS0xNyAx
Nzo1Njo1My41ODJdICAgIElSUTogIDM4IGFmZmluaXR5OjNmIHZlYzphOSB0eXBlPUlPLUFQ
SUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0
LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgNDAgYWZmaW5pdHk6MTAgdmVjOjMxIHR5
cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4t
bGlzdD0xNzogNDAoLU0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJ
UlE6ICA0NiBhZmZpbml0eTozZiB2ZWM6NzIgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODJdICAgIElSUTogIDQ3IGFmZmluaXR5OjIwIHZlYzpkMSB0eXBlPUlPLUFQSUMtbGV2ZWwg
ICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTEgZG9tYWluLWxpc3Q9MTY6IDQ3KFAtTSks
CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgNDggYWZmaW5pdHk6
M2YgdmVjOmQwIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQs
IHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJUlE6ICA1MSBh
ZmZpbml0eTozZiB2ZWM6OGEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElS
UTogIDUyIGFmZmluaXR5OjNmIHZlYzozOSB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9
MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
Ml0gICAgSVJROiAgNTMgYWZmaW5pdHk6M2YgdmVjOmM4IHR5cGU9SU8tQVBJQy1sZXZlbCAg
IHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTY6NTMuNTgyXSAgICBJUlE6ICA1NCBhZmZpbml0eTozZiB2ZWM6ZDggdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0x
MS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDU2IGFmZmluaXR5OjAxIHZlYzoyOCB0eXBl
PUFNRC1JT01NVS1NU0kgICBzdGF0dXM9MDAwMDAwMDAgaW9tbXVfaW50ZXJydXB0X2hhbmRs
ZXIoKQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDU3IGFmZmlu
aXR5OjAxIHZlYzphMCB0eXBlPUhQRVQtTVNJICAgICAgICBzdGF0dXM9MDAwMDAwMDAgaHBl
dF9pbnRlcnJ1cHRfaGFuZGxlcigpCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0g
ICAgSVJROiAgNTggYWZmaW5pdHk6MDQgdmVjOmE4IHR5cGU9SFBFVC1NU0kgICAgICAgIHN0
YXR1cz0wMDAwMDAwMCBocGV0X2ludGVycnVwdF9oYW5kbGVyKCkKKFhFTikgWzIwMTQtMTEt
MTcgMTc6NTY6NTMuNTgyXSAgICBJUlE6ICA1OSBhZmZpbml0eTowOCB2ZWM6YjAgdHlwZT1I
UEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIGhwZXRfaW50ZXJydXB0X2hhbmRsZXIo
KQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODJdICAgIElSUTogIDYwIGFmZmluaXR5
OjNmIHZlYzo0MSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVk
LCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4Ml0gICAgSVJROiAgNjEg
YWZmaW5pdHk6M2YgdmVjOjQ5IHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAw
MiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgyXSAgICBJ
UlE6ICA2MiBhZmZpbml0eTozZiB2ZWM6NTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODNdICAgIElSUTogIDYzIGFmZmluaXR5OjNmIHZlYzo1OSB0eXBlPVBDSS1NU0kgICAgICAg
ICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3
OjU2OjUzLjU4M10gICAgSVJROiAgNjQgYWZmaW5pdHk6M2YgdmVjOjYxIHR5cGU9UENJLU1T
SSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQt
MTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA2NSBhZmZpbml0eTozZiB2ZWM6NjkgdHlw
ZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgIElSUTogIDY2IGFmZmluaXR5OjNmIHZl
Yzo3MSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJv
dW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgSVJROiAgNjcgYWZmaW5p
dHk6M2YgdmVjOjc5IHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBw
ZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA2
OCBhZmZpbml0eTozZiB2ZWM6ODEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAg
IElSUTogIDY5IGFmZmluaXR5OjNmIHZlYzo5MSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0
dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4M10gICAgSVJROiAgNzAgYWZmaW5pdHk6M2YgdmVjOjk5IHR5cGU9UENJLU1TSS8tWCAg
ICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgzXSAgICBJUlE6ICA3MSBhZmZpbml0eTozZiB2ZWM6YTEgdHlwZT1QQ0kt
TVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODNdICAgIElSUTogIDcyIGFmZmluaXR5OjNmIHZlYzpiMSB0
eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihY
RU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgSVJROiAgNzMgYWZmaW5pdHk6MDIg
dmVjOjMyIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9
MCBkb21haW4tbGlzdD0wOjI5MSgtLS0pLAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODNdICAgIElSUTogIDc0IGFmZmluaXR5OjAxIHZlYzozYSB0eXBlPVBDSS1NU0kgICAgICAg
ICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyOTIoLS0tKSwK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA3NSBhZmZpbml0eTox
MCB2ZWM6NDIgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdo
dD0wIGRvbWFpbi1saXN0PTA6MjkzKC0tLSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4M10gICAgSVJROiAgNzYgYWZmaW5pdHk6MDEgdmVjOjRhIHR5cGU9UENJLU1TSSAgICAg
ICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI5NCgtLS0p
LAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgIElSUTogIDc3IGFmZmluaXR5
OjAxIHZlYzo1MiB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxp
Z2h0PTAgZG9tYWluLWxpc3Q9MDoyOTUoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6
NTMuNTgzXSAgICBJUlE6ICA3OCBhZmZpbml0eTowMSB2ZWM6NWEgdHlwZT1QQ0ktTVNJICAg
ICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk2KC0t
LSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgSVJROiAgNzkgYWZmaW5p
dHk6M2YgdmVjOjYyIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBw
ZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA4
MCBhZmZpbml0eTozZiB2ZWM6NmEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAg
IElSUTogIDgxIGFmZmluaXR5OjA4IHZlYzo3YSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0
dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyOTAoLS0tKSwKKFhFTikg
WzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA4MiBhZmZpbml0eTowMSB2ZWM6
OTIgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRv
bWFpbi1saXN0PTA6Mjg5KC0tLSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10g
ICAgSVJROiAgODMgYWZmaW5pdHk6MDEgdmVjOmEyIHR5cGU9UENJLU1TSSAgICAgICAgIHN0
YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI4OCgtLS0pLAooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgIElSUTogIDg0IGFmZmluaXR5OjIwIHZl
YzphYSB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMTAgaW4tZmxpZ2h0PTAg
ZG9tYWluLWxpc3Q9MTc6IDg3KC0tLSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
M10gICAgSVJROiAgODUgYWZmaW5pdHk6MjAgdmVjOmIyIHR5cGU9UENJLU1TSS8tWCAgICAg
IHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0xNzogODYoLS0tKSwK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA4NiBhZmZpbml0eToy
MCB2ZWM6YmEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdo
dD0wIGRvbWFpbi1saXN0PTE3OiA4NSgtLS0pLAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1
My41ODNdICAgIElSUTogIDg3IGFmZmluaXR5OjIwIHZlYzpjMiB0eXBlPVBDSS1NU0kvLVgg
ICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTc6IDg0KC0t
LSksCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgSVJROiAgODggYWZmaW5p
dHk6MjAgdmVjOmNhIHR5cGU9UENJLU1TSS8tWCAgICAgIHN0YXR1cz0wMDAwMDAxMCBpbi1m
bGlnaHQ9MCBkb21haW4tbGlzdD0xNjogODcoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTY6NTMuNTgzXSAgICBJUlE6ICA4OSBhZmZpbml0eTowNCB2ZWM6ZDIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiA4
NigtLS0pLAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgIElSUTogIDkwIGFm
ZmluaXR5OjA0IHZlYzpkYSB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMzAg
aW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTY6IDg1KC0tLSksCihYRU4pIFsyMDE0LTExLTE3
IDE3OjU2OjUzLjU4M10gICAgSVJROiAgOTEgYWZmaW5pdHk6MDQgdmVjOjIzIHR5cGU9UENJ
LU1TSS8tWCAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0x
NjogODQoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICBJUlE6ICA5
MiBhZmZpbml0eTowNCB2ZWM6MmIgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAw
MDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiA4MygtLS0pLAooWEVOKSBbMjAxNC0x
MS0xNyAxNzo1Njo1My41ODNdIERpcmVjdCB2ZWN0b3IgaW5mb3JtYXRpb246CihYRU4pIFsy
MDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgMHgyMCAtPiBpcnFfbW92ZV9jbGVhbnVwX2lu
dGVycnVwdCgpCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgMHhmOSAtPiBw
bXVfYXBpY19pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAg
IDB4ZmEgLT4gYXBpY190aW1lcl9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1
Njo1My41ODNdICAgIDB4ZmIgLT4gY2FsbF9mdW5jdGlvbl9pbnRlcnJ1cHQoKQooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgIDB4ZmMgLT4gZXZlbnRfY2hlY2tfaW50ZXJy
dXB0KCkKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAweGZkIC0+IGludmFs
aWRhdGVfaW50ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAw
eGZlIC0+IGVycm9yX2ludGVycnVwdCgpCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
M10gICAgMHhmZiAtPiBzcHVyaW91c19pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xNyAx
Nzo1Njo1My41ODNdIElPLUFQSUMgaW50ZXJydXB0IGluZm9ybWF0aW9uOgooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODNdICAgICBJUlEgIDAgVmVjMjQwOgooWEVOKSBbMjAxNC0x
MS0xNyAxNzo1Njo1My41ODNdICAgICAgIEFwaWMgMHgwMCwgUGluICAyOiB2ZWM9ZjAgZGVs
aXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1h
c2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgSVJR
ICAxIFZlYyA0ODoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgICBBcGlj
IDB4MDAsIFBpbiAgMTogdmVjPTMwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBw
b2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTEx
LTE3IDE3OjU2OjUzLjU4M10gICAgIElSUSAgMyBWZWMgNTY6CihYRU4pIFsyMDE0LTExLTE3
IDE3OjU2OjUzLjU4M10gICAgICAgQXBpYyAweDAwLCBQaW4gIDM6IHZlYz0zOCBkZWxpdmVy
eT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0w
IGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICBJUlEgIDQg
VmVjMjQxOgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICAgIEFwaWMgMHgw
MCwgUGluICA0OiB2ZWM9ZjEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFy
aXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgzXSAgICAgSVJRICA1IFZlYyA2NDoKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTY6NTMuNTgzXSAgICAgICBBcGljIDB4MDAsIFBpbiAgNTogdmVjPTQwIGRlbGl2ZXJ5PUxv
UHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVz
dF9pZDoxCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgIElSUSAgNiBWZWMg
NzI6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgICAgQXBpYyAweDAwLCBQ
aW4gIDY6IHZlYz00OCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9
MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1
Njo1My41ODNdICAgICBJUlEgIDcgVmVjIDgwOgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1
My41ODNdICAgICAgIEFwaWMgMHgwMCwgUGluICA3OiB2ZWM9NTAgZGVsaXZlcnk9TG9Qcmkg
ZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lk
OjEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgSVJRICA4IFZlYyA4ODoK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgICBBcGljIDB4MDAsIFBpbiAg
ODogdmVjPTU4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGly
cj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4M10gICAgIElSUSAgOSBWZWMgOTY6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
M10gICAgICAgQXBpYyAweDAwLCBQaW4gIDk6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0
PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgSVJRIDEwIFZlYzEwNDoKKFhF
TikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgICBBcGljIDB4MDAsIFBpbiAxMDog
dmVjPTY4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0w
IHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
M10gICAgIElSUSAxMSBWZWMxMTI6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10g
ICAgICAgQXBpYyAweDAwLCBQaW4gMTE6IHZlYz03MCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwg
c3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICBJUlEgMTIgVmVjMTIwOgooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICAgIEFwaWMgMHgwMCwgUGluIDEyOiB2ZWM9
NzggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJp
Zz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAg
ICAgSVJRIDEzIFZlYzEzNjoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAg
ICBBcGljIDB4MDAsIFBpbiAxMzogdmVjPTg4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0
dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICBJUlEgMTQgVmVjMTQ0OgooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODNdICAgICAgIEFwaWMgMHgwMCwgUGluIDE0OiB2ZWM9OTAg
ZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1F
IG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAg
SVJRIDE1IFZlYzE1MjoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTgzXSAgICAgICBB
cGljIDB4MDAsIFBpbiAxNTogdmVjPTk4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9
MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0
LTExLTE3IDE3OjU2OjUzLjU4M10gICAgIElSUSAxNiBWZWMxMzc6CihYRU4pIFsyMDE0LTEx
LTE3IDE3OjU2OjUzLjU4M10gICAgICAgQXBpYyAweDAwLCBQaW4gMTY6IHZlYz04OSBkZWxp
dmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFz
az0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICBJUlEg
MTcgVmVjMTkyOgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODNdICAgICAgIEFwaWMg
MHgwMCwgUGluIDE3OiB2ZWM9YzAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBv
bGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEt
MTcgMTc6NTY6NTMuNTgzXSAgICAgSVJRIDE4IFZlYzE4NDoKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgzXSAgICAgICBBcGljIDB4MDAsIFBpbiAxODogdmVjPWI4IGRlbGl2ZXJ5
PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTAg
ZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgIElSUSAxOSBW
ZWMgNDI6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgICAgQXBpYyAweDAw
LCBQaW4gMTk6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJp
dHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTMuNTgzXSAgICAgSVJRIDIyIFZlYzE4NToKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTY6NTMuNTgzXSAgICAgICBBcGljIDB4MDAsIFBpbiAyMjogdmVjPWI5IGRlbGl2ZXJ5PUZp
eGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTAgZGVz
dF9pZDoxCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4M10gICAgIElSUSAyNSBWZWMx
NTQ6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4NF0gICAgICAgQXBpYyAweDAxLCBQ
aW4gIDE6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9
MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTcgMTc6
NTY6NTMuNTg0XSAgICAgSVJRIDI4IFZlYyAzNDoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6
NTMuNTg0XSAgICAgICBBcGljIDB4MDEsIFBpbiAgNDogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVk
IGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9p
ZDo2MwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAgICBJUlEgMjkgVmVjMjE3
OgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAgICAgIEFwaWMgMHgwMSwgUGlu
ICA1OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEg
aXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2
OjUzLjU4NF0gICAgIElSUSAzMiBWZWMyMDE6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUz
LjU4NF0gICAgICAgQXBpYyAweDAxLCBQaW4gIDg6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBk
ZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6
NjMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAgICAgSVJRIDMzIFZlYzE5MzoK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAgICAgICBBcGljIDB4MDEsIFBpbiAg
OTogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGly
cj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1
My41ODRdICAgICBJUlEgMzYgVmVjIDMzOgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41
ODRdICAgICAgIEFwaWMgMHgwMSwgUGluIDEyOiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVz
dD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYz
CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4NF0gICAgIElSUSAzNyBWZWMgNDE6CihY
RU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4NF0gICAgICAgQXBpYyAweDAxLCBQaW4gMTM6
IHZlYz0yOSBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9
MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MzIKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMu
NTg0XSAgICAgSVJRIDM4IFZlYzE2OToKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0
XSAgICAgICBBcGljIDB4MDEsIFBpbiAxNDogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9
TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2Mwoo
WEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAgICBJUlEgNDAgVmVjIDQ5OgooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAgICAgIEFwaWMgMHgwMSwgUGluIDE2OiB2
ZWM9MzEgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAg
dHJpZz1MIG1hc2s9MCBkZXN0X2lkOjE2CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4
NF0gICAgIElSUSA0NiBWZWMxMTQ6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4NF0g
ICAgICAgQXBpYyAweDAxLCBQaW4gMjI6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwg
c3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhF
TikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAgICAgSVJRIDQ3IFZlYzIwOToKKFhFTikg
WzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAgICAgICBBcGljIDB4MDEsIFBpbiAyMzogdmVj
PWQxIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MSBwb2xhcml0eT0xIGlycj0xIHRy
aWc9TCBtYXNrPTAgZGVzdF9pZDozMgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRd
ICAgICBJUlEgNDggVmVjMjA4OgooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAg
ICAgIEFwaWMgMHgwMSwgUGluIDI0OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0
YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4p
IFsyMDE0LTExLTE3IDE3OjU2OjUzLjU4NF0gICAgIElSUSA1MSBWZWMxMzg6CihYRU4pIFsy
MDE0LTExLTE3IDE3OjU2OjUzLjU4NF0gICAgICAgQXBpYyAweDAxLCBQaW4gMjc6IHZlYz0w
MCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmln
PUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAg
ICAgSVJRIDUyIFZlYyA1NzoKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTMuNTg0XSAgICAg
ICBBcGljIDB4MDEsIFBpbiAyODogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0
dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1Njo1My41ODRdICAgICBJUlEgNTMgVmVjMjAwOgooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1My41ODRdICAgICAgIEFwaWMgMHgwMSwgUGluIDI5OiB2ZWM9MDAg
ZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1M
IG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjYxNV0gICAg
IElSUSA1NCBWZWMyMTY6CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjUzLjYyOF0gICAgICAg
QXBpYyAweDAxLCBQaW4gMzA6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVz
PTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIw
MTQtMTEtMTcgMTc6NTY6NTUuNzA5XSBNU0kgaW5mb3JtYXRpb246CihYRU4pIFsyMDE0LTEx
LTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAgICAgNTYgdmVjPTI4IGxvd2VzdCAgZWRnZSAgIGFz
c2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8wLz8KKFhFTikgWzIwMTQt
MTEtMTcgMTc6NTY6NTUuNzA5XSAgSFBFVCAgICA1NyB2ZWM9YTAgbG93ZXN0ICBlZGdlICAg
YXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFzaz0xLzAvPwooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1NS43MDldICBIUEVUICAgIDU4IHZlYz1hOCBsb3dlc3QgIGVkZ2Ug
ICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwNCBtYXNrPTEvMC8/CihYRU4pIFsy
MDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIEhQRVQgICAgNTkgdmVjPWIwIGxvd2VzdCAgZWRn
ZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDA4IG1hc2s9MS8wLz8KKFhFTikg
WzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJICAgICA2MCB2ZWM9NDEgbG93ZXN0ICBl
ZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0kgICAgIDYxIHZlYz00OSBsb3dlc3Qg
IGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihY
RU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAgICAgNjIgdmVjPTUxIGxvd2Vz
dCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8K
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJICAgICA2MyB2ZWM9NTkgbG93
ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEv
PwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0kgICAgIDY0IHZlYz02MSBs
b3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAv
MS8/CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAgICAgNjUgdmVjPTY5
IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9
MC8xLz8KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJICAgICA2NiB2ZWM9
NzEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFz
az0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0kgICAgIDY3IHZl
Yz03OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBt
YXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAgICAgNjgg
dmVjPTgxIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNm
IG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJICAgICA2
OSB2ZWM9OTEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAw
M2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0kgICAg
IDcwIHZlYz05OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAw
MDAzZiBtYXNrPTEvMS8xCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAg
ICAgNzEgdmVjPWExIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAw
MDAwMDNmIG1hc2s9MS8xLzEKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJ
ICAgICA3MiB2ZWM9YjEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9
MDAwMDAwM2YgbWFzaz0xLzEvMQooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBN
U0kgICAgIDczIHZlYz0zMiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVz
dD0wMDAwMDAwMiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0g
IE1TSSAgICAgNzQgdmVjPTNhIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBk
ZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5
XSAgTVNJICAgICA3NSB2ZWM9NDIgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0
IGRlc3Q9MDAwMDAwMDIgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43
MDldICBNU0kgICAgIDc2IHZlYz00YSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dl
c3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1
LjcwOV0gIE1TSSAgICAgNzcgdmVjPTUyIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxv
d2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6
NTUuNzA5XSAgTVNJICAgICA3OCB2ZWM9NWEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cg
bG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xNyAxNzo1
Njo1NS43MDldICBNU0kgICAgIDc5IHZlYz02MiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxv
ZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE3IDE3
OjU2OjU1LjcwOV0gIE1TSSAgICAgODAgdmVjPTZhIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAg
bG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTcg
MTc6NTY6NTUuNzA5XSAgTVNJICAgICA4MSB2ZWM9N2EgbG93ZXN0ICBlZGdlICAgYXNzZXJ0
ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMTAgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0x
NyAxNzo1Njo1NS43MDldICBNU0kgICAgIDgyIHZlYz05MiBsb3dlc3QgIGVkZ2UgICBhc3Nl
cnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAxMCBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTEx
LTE3IDE3OjU2OjU1LjcwOV0gIE1TSSAgICAgODMgdmVjPWEyIGxvd2VzdCAgZWRnZSAgIGFz
c2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQt
MTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJLVggICA4NCB2ZWM9YWEgbG93ZXN0ICBlZGdlICAg
YXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDQgbWFzaz0xLzAvMAooWEVOKSBbMjAx
NC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0ktWCAgIDg1IHZlYz1iMiBsb3dlc3QgIGVkZ2Ug
ICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAyMCBtYXNrPTEvMC8wCihYRU4pIFsy
MDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSS1YICAgODYgdmVjPWJhIGxvd2VzdCAgZWRn
ZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDIwIG1hc2s9MS8wLzAKKFhFTikg
WzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJLVggICA4NyB2ZWM9YzIgbG93ZXN0ICBl
ZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMjAgbWFzaz0xLzAvMAooWEVO
KSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0ktWCAgIDg4IHZlYz1jYSBsb3dlc3Qg
IGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAyMCBtYXNrPTEvMC8wCihY
RU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSS1YICAgODkgdmVjPWQyIGxvd2Vz
dCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDA0IG1hc2s9MS8wLzAK
KFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzA5XSAgTVNJLVggICA5MCB2ZWM9ZGEgbG93
ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDQgbWFzaz0xLzAv
MAooWEVOKSBbMjAxNC0xMS0xNyAxNzo1Njo1NS43MDldICBNU0ktWCAgIDkxIHZlYz0yMyBs
b3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwNCBtYXNrPTEv
MC8wCihYRU4pIFsyMDE0LTExLTE3IDE3OjU2OjU1LjcwOV0gIE1TSS1YICAgOTIgdmVjPTJi
IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDA0IG1hc2s9
MS8wLzAKKFhFTikgWzIwMTQtMTEtMTcgMTc6NTY6NTUuNzU1XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xNyAxNzo1NzowNS43NTVdIC0tTUFSSy0tCg==
------------07C1DE16C0EDF9EBB
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------07C1DE16C0EDF9EBB--



From xen-devel-bounces@lists.xen.org Mon Nov 17 18:02:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 18: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 1XqQdA-0004eT-N2; Mon, 17 Nov 2014 18:02:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqQd9-0004eI-I7
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 18:02:27 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	12/89-22737-2383A645; Mon, 17 Nov 2014 18:02:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416247343!11893442!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32308 invoked from network); 17 Nov 2014 18:02:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 18:02:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="193642628"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 13:02:20 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqQd1-00012A-Kq;
	Mon, 17 Nov 2014 18:02:19 +0000
Date: Mon, 17 Nov 2014 18:02:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> Thank you for your answer.
> 
> On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > Although it is possible that that patch is the cause of your problem,
> > unfortunately it is part of a significant rework of the GIC driver in
> > Xen and I am afraid that testing with only a portion of that patch
> > series might introduce other subtle bugs.  For your reference the series
> > starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
> > commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
> >
> 
> Yes, I tested with and without the whole series.

And the result is that the series causes the problem?


> > If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
> > problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
> > might not work correctly on your platform. It wouldn't be the first time
> > that we see hardware behaving that way, especially if you are using the
> > GIC secure registers instead of the non-secure register as GICH_LRn.HW
> > can only deactivate non-secure interrupts. This is usually due to a
> > configuration error in u-boot.
> >
> > Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
> > platform?
> >
> 
> I tried this. Unfortunately it doesn't help.

Could you try the following patch on top of
5495a512b63bad868c147198f7f049c2617d468c ?

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 302c031..a286376 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -557,10 +557,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
     BUG_ON(lr < 0);
     BUG_ON(state & ~(GICH_LR_STATE_MASK<<GICH_LR_STATE_SHIFT));
 
-    lr_val = state | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
+    lr_val = state | GICH_LR_MAINTENANCE_IRQ | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
         ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
-    if ( p->desc != NULL )
-        lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
 
     GICH[GICH_LR + lr] = lr_val;
 
@@ -622,6 +620,12 @@ out:
     return;
 }
 
+static void gic_irq_eoi(void *info)
+{
+    int virq = (uintptr_t) info;
+    GICC[GICC_DIR] = virq;
+}
+
 static void gic_update_one_lr(struct vcpu *v, int i)
 {
     struct pending_irq *p;
@@ -639,7 +643,10 @@ static void gic_update_one_lr(struct vcpu *v, int i)
         irq = (lr >> GICH_LR_VIRTUAL_SHIFT) & GICH_LR_VIRTUAL_MASK;
         p = irq_to_pending(v, irq);
         if ( p->desc != NULL )
+        {
+            gic_irq_eoi((void*)(uintptr_t)irq);
             p->desc->status &= ~IRQ_INPROGRESS;
+        }
         clear_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
         if ( test_bit(GIC_IRQ_GUEST_PENDING, &p->status) &&
                 test_bit(GIC_IRQ_GUEST_ENABLED, &p->status))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 18:02:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 18: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 1XqQdA-0004eT-N2; Mon, 17 Nov 2014 18:02:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqQd9-0004eI-I7
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 18:02:27 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	12/89-22737-2383A645; Mon, 17 Nov 2014 18:02:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416247343!11893442!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32308 invoked from network); 17 Nov 2014 18:02:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 18:02:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,404,1413244800"; d="scan'208";a="193642628"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 17 Nov 2014 13:02:20 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqQd1-00012A-Kq;
	Mon, 17 Nov 2014 18:02:19 +0000
Date: Mon, 17 Nov 2014 18:02:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> Thank you for your answer.
> 
> On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > Although it is possible that that patch is the cause of your problem,
> > unfortunately it is part of a significant rework of the GIC driver in
> > Xen and I am afraid that testing with only a portion of that patch
> > series might introduce other subtle bugs.  For your reference the series
> > starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
> > commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
> >
> 
> Yes, I tested with and without the whole series.

And the result is that the series causes the problem?


> > If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
> > problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
> > might not work correctly on your platform. It wouldn't be the first time
> > that we see hardware behaving that way, especially if you are using the
> > GIC secure registers instead of the non-secure register as GICH_LRn.HW
> > can only deactivate non-secure interrupts. This is usually due to a
> > configuration error in u-boot.
> >
> > Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
> > platform?
> >
> 
> I tried this. Unfortunately it doesn't help.

Could you try the following patch on top of
5495a512b63bad868c147198f7f049c2617d468c ?

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 302c031..a286376 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -557,10 +557,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
     BUG_ON(lr < 0);
     BUG_ON(state & ~(GICH_LR_STATE_MASK<<GICH_LR_STATE_SHIFT));
 
-    lr_val = state | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
+    lr_val = state | GICH_LR_MAINTENANCE_IRQ | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
         ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
-    if ( p->desc != NULL )
-        lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
 
     GICH[GICH_LR + lr] = lr_val;
 
@@ -622,6 +620,12 @@ out:
     return;
 }
 
+static void gic_irq_eoi(void *info)
+{
+    int virq = (uintptr_t) info;
+    GICC[GICC_DIR] = virq;
+}
+
 static void gic_update_one_lr(struct vcpu *v, int i)
 {
     struct pending_irq *p;
@@ -639,7 +643,10 @@ static void gic_update_one_lr(struct vcpu *v, int i)
         irq = (lr >> GICH_LR_VIRTUAL_SHIFT) & GICH_LR_VIRTUAL_MASK;
         p = irq_to_pending(v, irq);
         if ( p->desc != NULL )
+        {
+            gic_irq_eoi((void*)(uintptr_t)irq);
             p->desc->status &= ~IRQ_INPROGRESS;
+        }
         clear_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
         if ( test_bit(GIC_IRQ_GUEST_PENDING, &p->status) &&
                 test_bit(GIC_IRQ_GUEST_ENABLED, &p->status))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 19:21:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 19:21:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqRrA-0005bS-HN; Mon, 17 Nov 2014 19:21:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XqRr8-0005bN-E1
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 19:20:58 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	20/51-31453-99A4A645; Mon, 17 Nov 2014 19:20:57 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416252055!11839277!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27386 invoked from network); 17 Nov 2014 19:20:57 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 19:20:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416252055; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=uFMDCTAz2yZAgbrvKlNuh5QR1bRVDuII0gI5kNa05+E=;
	b=4d/DxIEoJejEtfkZYx/9V6XDiOr29dYp4TUTqpRLnKCW7b+L8oD3lek30D8klZ9Z8DJe9BN6SdHBbjUhgiPpaeprs4AiWA4QAH0igUw/mQdcR+r0x9km+qMo6xsi2Lg0AM6AuxI9ry4jXxw2E7FaxxFdZ9UB7B7e7iAu81TBV5A=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 17 Nov 2014 11:20:54 -0800
	id 00000000000305B8.546A4A96.00002EE7
Message-ID: <546A4AD4.3030002@ihonk.com>
Date: Mon, 17 Nov 2014 11:21:56 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, pasik@iki.fi
References: <5457F79B.2020300@ihonk.com>
	<20141104082012.GY12451@reaktio.net>	<5458B55C0200007800044B33@mail.emea.novell.com>	<5460716A.7090905@ihonk.com>	<54608A8B0200007800045E58@mail.emea.novell.com>	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
In-Reply-To: <5461D15C02000078000464D7@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 11/11/2014 0:05, Jan Beulich wrote:
>
>>> And these
>>>
>>>       [  199.775209] pcieport 0000:00:03.0: AER: Multiple Corrected error
>> received: id=0018
>>>       [  199.775238] pcieport 0000:00:03.0: PCIe Bus Error:
>> severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID)
>>>       [  199.775251] pcieport 0000:00:03.0:   device [8086:340a] error
>> status/mask=00001100/00002000
>>>       [  199.775255] pcieport 0000:00:03.0:    [ 8] RELAY_NUM Rollover
>>>       [  199.775258] pcieport 0000:00:03.0:    [12] Replay Timer Timeout
>>>
>>> hint at a problem in the system's design. 00:03.0 is the parent bridge
>>> of 02:00.0 (and from what I can tell that's the only device behind that
>>> bridge), and hence the above messages can only reasonably have
>>> their origin at the passed through VGA device.
>>

Okay, I did a bisection and was not able to correlate the above error 
message with the problem I'm seeing. Not saying it's not related, but I 
had plenty of successful test runs in the presence of that error.

Took me about a week (sometimes it takes as much as 6 hours to produce 
the error), but bisect narrowed it down to this commit:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9a727a813e9b25003e433b3dc3fa47e621f9e238

What do you think?

Thanks!

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 19:21:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 19:21:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqRrA-0005bS-HN; Mon, 17 Nov 2014 19:21:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XqRr8-0005bN-E1
	for xen-devel@lists.xen.org; Mon, 17 Nov 2014 19:20:58 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	20/51-31453-99A4A645; Mon, 17 Nov 2014 19:20:57 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416252055!11839277!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27386 invoked from network); 17 Nov 2014 19:20:57 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 19:20:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416252055; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=uFMDCTAz2yZAgbrvKlNuh5QR1bRVDuII0gI5kNa05+E=;
	b=4d/DxIEoJejEtfkZYx/9V6XDiOr29dYp4TUTqpRLnKCW7b+L8oD3lek30D8klZ9Z8DJe9BN6SdHBbjUhgiPpaeprs4AiWA4QAH0igUw/mQdcR+r0x9km+qMo6xsi2Lg0AM6AuxI9ry4jXxw2E7FaxxFdZ9UB7B7e7iAu81TBV5A=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 17 Nov 2014 11:20:54 -0800
	id 00000000000305B8.546A4A96.00002EE7
Message-ID: <546A4AD4.3030002@ihonk.com>
Date: Mon, 17 Nov 2014 11:21:56 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, pasik@iki.fi
References: <5457F79B.2020300@ihonk.com>
	<20141104082012.GY12451@reaktio.net>	<5458B55C0200007800044B33@mail.emea.novell.com>	<5460716A.7090905@ihonk.com>	<54608A8B0200007800045E58@mail.emea.novell.com>	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
In-Reply-To: <5461D15C02000078000464D7@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 11/11/2014 0:05, Jan Beulich wrote:
>
>>> And these
>>>
>>>       [  199.775209] pcieport 0000:00:03.0: AER: Multiple Corrected error
>> received: id=0018
>>>       [  199.775238] pcieport 0000:00:03.0: PCIe Bus Error:
>> severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID)
>>>       [  199.775251] pcieport 0000:00:03.0:   device [8086:340a] error
>> status/mask=00001100/00002000
>>>       [  199.775255] pcieport 0000:00:03.0:    [ 8] RELAY_NUM Rollover
>>>       [  199.775258] pcieport 0000:00:03.0:    [12] Replay Timer Timeout
>>>
>>> hint at a problem in the system's design. 00:03.0 is the parent bridge
>>> of 02:00.0 (and from what I can tell that's the only device behind that
>>> bridge), and hence the above messages can only reasonably have
>>> their origin at the passed through VGA device.
>>

Okay, I did a bisection and was not able to correlate the above error 
message with the problem I'm seeing. Not saying it's not related, but I 
had plenty of successful test runs in the presence of that error.

Took me about a week (sometimes it takes as much as 6 hours to produce 
the error), but bisect narrowed it down to this commit:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9a727a813e9b25003e433b3dc3fa47e621f9e238

What do you think?

Thanks!

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 20:04:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 20:04:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqSX1-00067K-PN; Mon, 17 Nov 2014 20:04:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XqSWz-00067D-NG
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 20:04:13 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	0A/65-26652-DB45A645; Mon, 17 Nov 2014 20:04:13 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416254651!4278143!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1105 invoked from network); 17 Nov 2014 20:04:12 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 20:04:12 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHK3x1J030028
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 20:04:04 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHK3vwK020313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 20:03:59 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHK3vA0020300; Mon, 17 Nov 2014 20:03:57 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 12:03:57 -0800
Message-ID: <546A54AC.50909@oracle.com>
Date: Mon, 17 Nov 2014 15:03:56 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com>
	<5460D9C5.4020905@oracle.com>
	<1415633435.25176.27.camel@citrix.com>
	<5460DBEF.5000504@oracle.com>
	<1415793797.29592.12.camel@citrix.com>
In-Reply-To: <1415793797.29592.12.camel@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 07:03 AM, Ian Campbell wrote:
> On Mon, 2014-11-10 at 10:38 -0500, Zhigang Wang wrote:
>> OK. Let me try my best:
>>
>>>>> I'm confused by the description of what's going on, in particular the
>>>>> mixing of mem-max commands and target xenstore nodes (since the former
>>>>> doesn't really affect the latter).
>>>>>
>>>>> How was the domain started (memory= and maxmem=).
>>
>> xl create with 'memory = 700', no maxmem been set. I think it means maxmem = memory for this case.
>>
>>>>> What were static-max and target at the point?
>>
>>      /local/domain/3/memory/static-max = "716800"
>>      /local/domain/3/memory/target = "716801"
>>
>>>>> What did they change to when xl mem-max was issued? 
>>
>> When I issue 'xl mem-max <domid> 700', static-max and target in xenstore will not change, but it will cause the command to fail.
>>
>> Because: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"
>>
>>>>> What did you expect them to change to instead?
>>
>> I expect I can set the maxmem to the same value I initially set (700).
> 
> OK, thanks, got it. I think the use of xl mem-max is a bit of a
> red-herring, the issue here is that static-max < target at start of day.
> 
> I suspect there is either a rounding error somewhere or because of
> LIBXL_MAXMEM_CONSTANT being inconsistently applied to the two values
> somewhere along the line.
> 
> We had been planning[0] to remove this early in the 4.5 cycle, but as
> ever it never floated to the top of anyone's list. For 4.5 we should
> probably look at applying this fudge more consistently.
> 
> Ian.
> 
> [0] http://bugs.xenproject.org/xen/bug/23

Here is more info (correct me if something wrong):

1. libxl_types.idl:

    ("video_memkb", MemKB)

    MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT", json_gen_fn = "libxl__uint64_gen_json")

  libxl.h: #define LIBXL_MEMKB_DEFAULT ~0ULL

  So video_memkb = -1 by default.

2. For hvm, we will set it into: 0, 16M, 8M according to hvm.vga.kind (libxl_create.c)

3. For pv guest, we will use default (-1).

4. When we calculate static-max and target memory:

    ents[0] = "memory/static-max";
    ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
    ents[2] = "memory/target";
    ents[3] = GCSPRINTF("%"PRId64, info->target_memkb - info->video_memkb);

  So target = static-max - (-1):
   
      /local/domain/3/memory/static-max = "716800"
      /local/domain/3/memory/target = "716801"

  Maybe this is the root cause why we include LIBXL_MAXMEM_CONSTANT.

Potential solutions:

1. Set b_info->video_memkb = 0; for pv guest.
2. Set LIBXL_MEMKB_DEFAULT = 0 (instead of -1): this will affect a lot things.
3. Also add LIBXL_MAXMEM_CONSTANT before doing comparison. (we should avoid this as we want to remove LIBXL_MAXMEM_CONSTANT)

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 20:04:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 20:04:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqSX1-00067K-PN; Mon, 17 Nov 2014 20:04:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XqSWz-00067D-NG
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 20:04:13 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	0A/65-26652-DB45A645; Mon, 17 Nov 2014 20:04:13 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416254651!4278143!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1105 invoked from network); 17 Nov 2014 20:04:12 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 20:04:12 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHK3x1J030028
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 20:04:04 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHK3vwK020313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Nov 2014 20:03:59 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHK3vA0020300; Mon, 17 Nov 2014 20:03:57 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 12:03:57 -0800
Message-ID: <546A54AC.50909@oracle.com>
Date: Mon, 17 Nov 2014 15:03:56 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com>
	<5460D9C5.4020905@oracle.com>
	<1415633435.25176.27.camel@citrix.com>
	<5460DBEF.5000504@oracle.com>
	<1415793797.29592.12.camel@citrix.com>
In-Reply-To: <1415793797.29592.12.camel@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 07:03 AM, Ian Campbell wrote:
> On Mon, 2014-11-10 at 10:38 -0500, Zhigang Wang wrote:
>> OK. Let me try my best:
>>
>>>>> I'm confused by the description of what's going on, in particular the
>>>>> mixing of mem-max commands and target xenstore nodes (since the former
>>>>> doesn't really affect the latter).
>>>>>
>>>>> How was the domain started (memory= and maxmem=).
>>
>> xl create with 'memory = 700', no maxmem been set. I think it means maxmem = memory for this case.
>>
>>>>> What were static-max and target at the point?
>>
>>      /local/domain/3/memory/static-max = "716800"
>>      /local/domain/3/memory/target = "716801"
>>
>>>>> What did they change to when xl mem-max was issued? 
>>
>> When I issue 'xl mem-max <domid> 700', static-max and target in xenstore will not change, but it will cause the command to fail.
>>
>> Because: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"
>>
>>>>> What did you expect them to change to instead?
>>
>> I expect I can set the maxmem to the same value I initially set (700).
> 
> OK, thanks, got it. I think the use of xl mem-max is a bit of a
> red-herring, the issue here is that static-max < target at start of day.
> 
> I suspect there is either a rounding error somewhere or because of
> LIBXL_MAXMEM_CONSTANT being inconsistently applied to the two values
> somewhere along the line.
> 
> We had been planning[0] to remove this early in the 4.5 cycle, but as
> ever it never floated to the top of anyone's list. For 4.5 we should
> probably look at applying this fudge more consistently.
> 
> Ian.
> 
> [0] http://bugs.xenproject.org/xen/bug/23

Here is more info (correct me if something wrong):

1. libxl_types.idl:

    ("video_memkb", MemKB)

    MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT", json_gen_fn = "libxl__uint64_gen_json")

  libxl.h: #define LIBXL_MEMKB_DEFAULT ~0ULL

  So video_memkb = -1 by default.

2. For hvm, we will set it into: 0, 16M, 8M according to hvm.vga.kind (libxl_create.c)

3. For pv guest, we will use default (-1).

4. When we calculate static-max and target memory:

    ents[0] = "memory/static-max";
    ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
    ents[2] = "memory/target";
    ents[3] = GCSPRINTF("%"PRId64, info->target_memkb - info->video_memkb);

  So target = static-max - (-1):
   
      /local/domain/3/memory/static-max = "716800"
      /local/domain/3/memory/target = "716801"

  Maybe this is the root cause why we include LIBXL_MAXMEM_CONSTANT.

Potential solutions:

1. Set b_info->video_memkb = 0; for pv guest.
2. Set LIBXL_MEMKB_DEFAULT = 0 (instead of -1): this will affect a lot things.
3. Also add LIBXL_MAXMEM_CONSTANT before doing comparison. (we should avoid this as we want to remove LIBXL_MAXMEM_CONSTANT)

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 20:44:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 20:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqT9f-0006XQ-8j; Mon, 17 Nov 2014 20:44:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqT9d-0006XL-FQ
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 20:44:09 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	4C/06-28296-81E5A645; Mon, 17 Nov 2014 20:44:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416257044!7562873!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29129 invoked from network); 17 Nov 2014 20:44:05 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 20:44:05 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHKhrSg012197
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 20:43:55 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHKhotR002149
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Nov 2014 20:43:50 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAHKhnBK006672; Mon, 17 Nov 2014 20:43:49 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 12:43:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 107DF1175E0; Mon, 17 Nov 2014 15:43:47 -0500 (EST)
Date: Mon, 17 Nov 2014 15:43:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141117204347.GA27617@laptop.dumpdata.com>
References: <546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1403873666.20141117180419@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

. snip..
> > # cat /proc/interrupts |grep eth
> >  36:     384183          0  xen-pirq-ioapic-level  eth0
> >  63:          1          0  xen-pirq-msi-x     eth1
> >  64:         24     661961  xen-pirq-msi-x     eth1-rx-0
> >  65:        205          0  xen-pirq-msi-x     eth1-rx-1
> >  66:        162          0  xen-pirq-msi-x     eth1-tx-0
> >  67:        190          0  xen-pirq-msi-x     eth1-tx-1
> > Is that a similar distribution of IRQ/MSIx you end up having?
> 
> These are when they are still active and assigned to dom0 (and not owned by 
> pci-back) or in the guest ?

In the guest.
> 
> I attached my /proc/interrupts for both dom0 as guest 16 with all guests running 
> (on a Xen from before the dpci changes). 
> With the devices passed through I only see one line with the IRQ of a 
> PCI soundcard passed through to a PV guest:
>   22:      38959          0          0          0          0          0  xen-pirq-ioapic-level  xen-pciback[0000:03:06.0]
> 
> All the other devices passed through (to HVM guests) are not visible in /proc/interrupts of dom0.

Right.
> 
> In the guest i do get these:
>  23:         35          0          0          0  xen-pirq-ioapic-level  uhci_hcd:usb3
>  40:   13440077          0          0          0  xen-pirq-ioapic-level  cx25821[1], cx25821[1]

That is a bit odd. You have two 'request_irq' off this sole device, which would
imply that there are _two_ devices which are using the same interrupt line.

But how is that possible when your device:

0a:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
        Flags: bus master, fast devsel, latency 0, IRQ 47
        Memory at fe200000 (64-bit, non-prefetchable) [size=2M]
        Capabilities: [40] Express Endpoint, MSI 00
        Capabilities: [80] Power Management version 3
        Capabilities: [90] Vital Product Data
        Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [200] Virtual Channel
        Kernel driver in use: pciback

Has only one IRQ! What is the name of this device? Perhaps I've another one that
is similar to this. Could you attach

 a) 'lspci -vvvv' from your guest please?

 b) The  the full 'dmesg' from your guest?

 c) the /var/log/xen/qemu-dm-XXX ? Hmm, you are using qemu-xen so it won't log
    that much information. Could you try 'qemu-traditional' or would that
    mess up with XHCI?


In regards to your other question:

	Hi Konrad,

	Here is the xl dmesg output with this patch (attached with debug-key i and M
	output). What i don't get .. is that d16 and d17 each have a device passed through
	that seems to be using the same pirq 87 ?

Those are per guest. They are the MSI values after 84 or so.

Back to your crash:

d16 OK-softirq 458msec ago, state:1, 52039 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
d16 OK-raise   489msec ago, state:1, 52049 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
d16 ERR-poison 561msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
d16 Z-softirq  731msec ago, state:3, 3 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
domain_crash called from io.c:938
Domain 16 reported crashed by domain 32767 on cpu#5:

All of it point to the legacy interrupt - that is the on that starts at Xen IRQ 47 (guest IRQ 40):
 io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0
IRQ:  47 affinity:02 vec:d1 type=IO-APIC-level   status=00000030 in-flight=1 domain-list=16: +47(P-M),

which looks OK.

I am puzzled by the driver binding twice to the same interrupt, but perhaps that
is just a buggy driver.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 20:44:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 20:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqT9f-0006XQ-8j; Mon, 17 Nov 2014 20:44:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqT9d-0006XL-FQ
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 20:44:09 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	4C/06-28296-81E5A645; Mon, 17 Nov 2014 20:44:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416257044!7562873!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29129 invoked from network); 17 Nov 2014 20:44:05 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2014 20:44:05 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAHKhrSg012197
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Nov 2014 20:43:55 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAHKhotR002149
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Nov 2014 20:43:50 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAHKhnBK006672; Mon, 17 Nov 2014 20:43:49 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Nov 2014 12:43:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 107DF1175E0; Mon, 17 Nov 2014 15:43:47 -0500 (EST)
Date: Mon, 17 Nov 2014 15:43:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141117204347.GA27617@laptop.dumpdata.com>
References: <546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1403873666.20141117180419@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

. snip..
> > # cat /proc/interrupts |grep eth
> >  36:     384183          0  xen-pirq-ioapic-level  eth0
> >  63:          1          0  xen-pirq-msi-x     eth1
> >  64:         24     661961  xen-pirq-msi-x     eth1-rx-0
> >  65:        205          0  xen-pirq-msi-x     eth1-rx-1
> >  66:        162          0  xen-pirq-msi-x     eth1-tx-0
> >  67:        190          0  xen-pirq-msi-x     eth1-tx-1
> > Is that a similar distribution of IRQ/MSIx you end up having?
> 
> These are when they are still active and assigned to dom0 (and not owned by 
> pci-back) or in the guest ?

In the guest.
> 
> I attached my /proc/interrupts for both dom0 as guest 16 with all guests running 
> (on a Xen from before the dpci changes). 
> With the devices passed through I only see one line with the IRQ of a 
> PCI soundcard passed through to a PV guest:
>   22:      38959          0          0          0          0          0  xen-pirq-ioapic-level  xen-pciback[0000:03:06.0]
> 
> All the other devices passed through (to HVM guests) are not visible in /proc/interrupts of dom0.

Right.
> 
> In the guest i do get these:
>  23:         35          0          0          0  xen-pirq-ioapic-level  uhci_hcd:usb3
>  40:   13440077          0          0          0  xen-pirq-ioapic-level  cx25821[1], cx25821[1]

That is a bit odd. You have two 'request_irq' off this sole device, which would
imply that there are _two_ devices which are using the same interrupt line.

But how is that possible when your device:

0a:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
        Flags: bus master, fast devsel, latency 0, IRQ 47
        Memory at fe200000 (64-bit, non-prefetchable) [size=2M]
        Capabilities: [40] Express Endpoint, MSI 00
        Capabilities: [80] Power Management version 3
        Capabilities: [90] Vital Product Data
        Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [200] Virtual Channel
        Kernel driver in use: pciback

Has only one IRQ! What is the name of this device? Perhaps I've another one that
is similar to this. Could you attach

 a) 'lspci -vvvv' from your guest please?

 b) The  the full 'dmesg' from your guest?

 c) the /var/log/xen/qemu-dm-XXX ? Hmm, you are using qemu-xen so it won't log
    that much information. Could you try 'qemu-traditional' or would that
    mess up with XHCI?


In regards to your other question:

	Hi Konrad,

	Here is the xl dmesg output with this patch (attached with debug-key i and M
	output). What i don't get .. is that d16 and d17 each have a device passed through
	that seems to be using the same pirq 87 ?

Those are per guest. They are the MSI values after 84 or so.

Back to your crash:

d16 OK-softirq 458msec ago, state:1, 52039 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
d16 OK-raise   489msec ago, state:1, 52049 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
d16 ERR-poison 561msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
d16 Z-softirq  731msec ago, state:3, 3 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
domain_crash called from io.c:938
Domain 16 reported crashed by domain 32767 on cpu#5:

All of it point to the legacy interrupt - that is the on that starts at Xen IRQ 47 (guest IRQ 40):
 io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0
IRQ:  47 affinity:02 vec:d1 type=IO-APIC-level   status=00000030 in-flight=1 domain-list=16: +47(P-M),

which looks OK.

I am puzzled by the driver binding twice to the same interrupt, but perhaps that
is just a buggy driver.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 17 21:59:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 21:59:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqUJg-0007EY-Dn; Mon, 17 Nov 2014 21:58:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqUJf-0007ET-Ap
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 21:58:35 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	75/EE-02698-A8F6A645; Mon, 17 Nov 2014 21:58:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416261512!13173487!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19155 invoked from network); 17 Nov 2014 21:58:33 -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;
	17 Nov 2014 21:58:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,405,1413244800"; d="scan'208";a="192249987"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 16:57:35 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqUIg-0007w7-Vp;
	Mon, 17 Nov 2014 21:57:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqUIg-0007Nu-PY;
	Mon, 17 Nov 2014 21:57:34 +0000
Date: Mon, 17 Nov 2014 21:57:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31601-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31601: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31601 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31601/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31553 REGR. vs. 30767

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot       fail pass in 31553
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31553

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 seabios              b0d42bd03225ad61e5421e12b57f633f84637328
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Hannes Reinecke <hare@suse.de>
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 401 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 Nov 17 21:59:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 21:59:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqUJg-0007EY-Dn; Mon, 17 Nov 2014 21:58:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqUJf-0007ET-Ap
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 21:58:35 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	75/EE-02698-A8F6A645; Mon, 17 Nov 2014 21:58:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416261512!13173487!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19155 invoked from network); 17 Nov 2014 21:58:33 -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;
	17 Nov 2014 21:58:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,405,1413244800"; d="scan'208";a="192249987"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 16:57:35 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqUIg-0007w7-Vp;
	Mon, 17 Nov 2014 21:57:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqUIg-0007Nu-PY;
	Mon, 17 Nov 2014 21:57:34 +0000
Date: Mon, 17 Nov 2014 21:57:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31601-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31601: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31601 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31601/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31553 REGR. vs. 30767

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot       fail pass in 31553
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31553

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 seabios              b0d42bd03225ad61e5421e12b57f633f84637328
baseline version:
 seabios              bfb7b58b30681f5c421e838fdef3dbc358e80f1e

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Hannes Reinecke <hare@suse.de>
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 401 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 Nov 17 22:40:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 22: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 1XqUy2-0007k6-4j; Mon, 17 Nov 2014 22:40:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqUy0-0007k1-Ms
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 22:40:17 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	04/2D-03148-0597A645; Mon, 17 Nov 2014 22:40:16 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416264012!13148899!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4459 invoked from network); 17 Nov 2014 22:40:12 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 17 Nov 2014 22:40:12 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50843 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqUwX-0006Cv-Vt; Mon, 17 Nov 2014 23:38:46 +0100
Date: Mon, 17 Nov 2014 23:40:11 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1271355060.20141117234011@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141117204347.GA27617@laptop.dumpdata.com>
References: <546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0C90EA036019900CC"
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0C90EA036019900CC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Monday, November 17, 2014, 9:43:47 PM, you wrote:

> . snip..
>> > # cat /proc/interrupts |grep eth
>> >  36:     384183          0  xen-pirq-ioapic-level  eth0
>> >  63:          1          0  xen-pirq-msi-x     eth1
>> >  64:         24     661961  xen-pirq-msi-x     eth1-rx-0
>> >  65:        205          0  xen-pirq-msi-x     eth1-rx-1
>> >  66:        162          0  xen-pirq-msi-x     eth1-tx-0
>> >  67:        190          0  xen-pirq-msi-x     eth1-tx-1
>> > Is that a similar distribution of IRQ/MSIx you end up having?
>> 
>> These are when they are still active and assigned to dom0 (and not owned by 
>> pci-back) or in the guest ?

> In the guest.
>> 
>> I attached my /proc/interrupts for both dom0 as guest 16 with all guests running 
>> (on a Xen from before the dpci changes). 
>> With the devices passed through I only see one line with the IRQ of a 
>> PCI soundcard passed through to a PV guest:
>>   22:      38959          0          0          0          0          0  xen-pirq-ioapic-level  xen-pciback[0000:03:06.0]
>> 
>> All the other devices passed through (to HVM guests) are not visible in /proc/interrupts of dom0.

> Right.
>> 
>> In the guest i do get these:
>>  23:         35          0          0          0  xen-pirq-ioapic-level  uhci_hcd:usb3
>>  40:   13440077          0          0          0  xen-pirq-ioapic-level  cx25821[1], cx25821[1]

> That is a bit odd. You have two 'request_irq' off this sole device, which would
> imply that there are _two_ devices which are using the same interrupt line.

> But how is that possible when your device:

> 0a:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
>         Flags: bus master, fast devsel, latency 0, IRQ 47
>         Memory at fe200000 (64-bit, non-prefetchable) [size=2M]
>         Capabilities: [40] Express Endpoint, MSI 00
>         Capabilities: [80] Power Management version 3
>         Capabilities: [90] Vital Product Data
>         Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
>         Capabilities: [100] Advanced Error Reporting
>         Capabilities: [200] Virtual Channel
>         Kernel driver in use: pciback

> Has only one IRQ! What is the name of this device? Perhaps I've another one that
> is similar to this. Could you attach

Well it's a videograbber .. with also one port for audio (not used) that 
registers with alsa. I can have a look if i can disable the audio part and see if it makes a 
difference, i don't use it anyway.


>  a) 'lspci -vvvv' from your guest please?
Attached

>  b) The  the full 'dmesg' from your guest?
Attached

>  c) the /var/log/xen/qemu-dm-XXX ? Hmm, you are using qemu-xen so it won't log
>     that much information. Could you try 'qemu-traditional' or would that
>     mess up with XHCI?
Attached, it contains some info (since i enabled debugging already) but most 
about MSI-X and not much about the legacy irq case though ...

I don't think traditional will mess up XHCI, it's also worth a try.

When looking at the driver /drivers/media/pci/cx25821 it's also clear why it 
doesn't enable MSI, though the card would support it according to lspci, the 
drivers lacks support (when i grep for MSI).

Also the driver seems to have an parameter to do irq debugging .. no idea how 
hard that will flood logs, but it's also worth a try :-)
cx25821-video.c:47:MODULE_PARM_DESC(irq_debug, "enable debug messages [IRQ handler]");


> In regards to your other question:
>         Hi Konrad,
>         Here is the xl dmesg output with this patch (attached with debug-key i and M
>         output). What i don't get .. is that d16 and d17 each have a device passed through
>         that seems to be using the same pirq 87 ?

> Those are per guest. They are the MSI values after 84 or so.
Hrrm yes i had found that already :-) 
All those (legacy) irq, msi, gsi, vector, pirq numbers can be a bit mind boggling ..  what corresponds to what where and when.

> Back to your crash:

> d16 OK-softirq 458msec ago, state:1, 52039 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> d16 OK-raise   489msec ago, state:1, 52049 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> d16 ERR-poison 561msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> d16 Z-softirq  731msec ago, state:3, 3 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> domain_crash called from io.c:938
> Domain 16 reported crashed by domain 32767 on cpu#5:

> All of it point to the legacy interrupt - that is the on that starts at Xen IRQ 47 (guest IRQ 40):
>  io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0
> IRQ:  47 affinity:02 vec:d1 type=IO-APIC-level   status=00000030 in-flight=1 domain-list=16: +47(P-M),

> which looks OK.
OK, i still don't get why the output of debug-key 'i' reports +47 as pirq here instead of the guest value 
(g_gsi of for this legacy interrupt which is 40 ?), like it does when it's a MSI with the PIRQ ?

> I am puzzled by the driver binding twice to the same interrupt, but perhaps that
> is just a buggy driver.

Doesn't that happen more often like with integrated USB controllers ?
  17:          4          0          0          0          0          0  xen-pirq-ioapic-level  ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
  18:       4385          0          0          0          0          0  xen-pirq-ioapic-level  ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7


And on host boot (with still some extra printk's):
[   12.773709] xen: registering gsi 18 triggering 0 polarity 1
[   12.773731] xen: --> pirq=18 -> irq=18 (gsi=18)
[   12.773749] pci 0000:00:12.0: ?!?!? acpi_pci_irq_enable: PCI INT A -> GSI 18 (level, low) -> IRQ/rc 18
[   12.848820] pci 0000:00:12.2: calling quirk_usb_early_handoff+0x0/0x6f0
[   12.848942] xen: registering gsi 17 triggering 0 polarity 1
[   12.848957] xen: --> pirq=17 -> irq=17 (gsi=17)
[   12.848975] pci 0000:00:12.2: ?!?!? acpi_pci_irq_enable: PCI INT B -> GSI 17 (level, low) -> IRQ/rc 17
[   12.849120] pci 0000:00:13.0: calling quirk_usb_early_handoff+0x0/0x6f0
[   12.849236] xen: registering gsi 18 triggering 0 polarity 1
[   12.849240] Already setup the GSI :18
[   12.849245] pci 0000:00:13.0: ?!?!? acpi_pci_irq_enable: PCI INT A -> GSI 18 (level, low) -> IRQ/rc 18
[   12.925464] pci 0000:00:13.2: calling quirk_usb_early_handoff+0x0/0x6f0
[   12.925583] xen: registering gsi 17 triggering 0 polarity 1
[   12.925589] Already setup the GSI :17
[   12.925593] pci 0000:00:13.2: ?!?!? acpi_pci_irq_enable: PCI INT B -> GSI 17 (level, low) -> IRQ/rc 17
[   12.925748] pci 0000:00:14.5: calling quirk_usb_early_handoff+0x0/0x6f0
[   12.925863] xen: registering gsi 18 triggering 0 polarity 1
[   12.925868] Already setup the GSI :18
[   12.925872] pci 0000:00:14.5: ?!?!? acpi_pci_irq_enable: PCI INT C -> GSI 18 (level, low) -> IRQ/rc 18
[   13.002145] pci 0000:00:16.0: calling quirk_usb_early_handoff+0x0/0x6f0
[   13.002264] xen: registering gsi 18 triggering 0 polarity 1
[   13.002269] Already setup the GSI :18
[   13.002273] pci 0000:00:16.0: ?!?!? acpi_pci_irq_enable: PCI INT A -> GSI 18 (level, low) -> IRQ/rc 18
[   13.078814] pci 0000:00:16.2: calling quirk_usb_early_handoff+0x0/0x6f0
------------0C90EA036019900CC
Content-Type: text/plain;
 name="dmesg-guest.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="dmesg-guest.txt"

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAg
MC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAw
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVhY2N0ClsgICAgMC4wMDAwMDBdIExp
bnV4IHZlcnNpb24gMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0eSsgKHJvb3RAc2VjdXJp
dHkpIChnY2MgdmVyc2lvbiA0LjcuMiAoRGViaWFuIDQuNy4yLTUpICkgIzEgU01QIFN1biBO
b3YgMTYgMTQ6NDQ6MjggQ0VUIDIwMTQKWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiBC
T09UX0lNQUdFPS9ib290L3ZtbGludXotMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0eSsg
cm9vdD0vZGV2L3h2ZGExIHJvIGNvbnNvbGU9dHR5MSBjb25zb2xlPXR0eVMwIG5vbW9kZXNl
dApbICAgIDAuMDAwMDAwXSB0c2VnOiAwMDAwMDAwMDAwClsgICAgMC4wMDAwMDBdIGU4MjA6
IEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoKWyAgICAwLjAwMDAwMF0gQklPUy1l
ODIwOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWZiZmZdIHVzYWJs
ZQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMDAwMDlmYzAwLTB4
MDAwMDAwMDAwMDA5ZmZmZl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBb
bWVtIDB4MDAwMDAwMDAwMDBmMDAwMC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkClsg
ICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAw
MDAwMDNmN2ZkZmZmXSB1c2FibGUKWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4
MDAwMDAwMDAzZjdmZTAwMC0weDAwMDAwMDAwM2Y3ZmZmZmZdIHJlc2VydmVkClsgICAgMC4w
MDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwZmMwMDAwMDAtMHgwMDAwMDAwMGZm
ZmZmZmZmXSByZXNlcnZlZApbICAgIDAuMDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBw
cm90ZWN0aW9uOiBhY3RpdmUKWyAgICAwLjAwMDAwMF0gU01CSU9TIDIuNCBwcmVzZW50Lgpb
ICAgIDAuMDAwMDAwXSBETUk6IFhlbiBIVk0gZG9tVSwgQklPUyA0LjUuMC1yYyAxMS8xNy8y
MDE0ClsgICAgMC4wMDAwMDBdIEh5cGVydmlzb3IgZGV0ZWN0ZWQ6IFhlbiBIVk0KWyAgICAw
LjAwMDAwMF0gWGVuIHZlcnNpb24gNC41LgpbICAgIDAuMDAwMDAwXSBYZW4gUGxhdGZvcm0g
UENJOiBJL08gcHJvdG9jb2wgdmVyc2lvbiAxClsgICAgMC4wMDAwMDBdIE5ldGZyb250IGFu
ZCB0aGUgWGVuIHBsYXRmb3JtIFBDSSBkcml2ZXIgaGF2ZSBiZWVuIGNvbXBpbGVkIGZvciB0
aGlzIGtlcm5lbDogdW5wbHVnIGVtdWxhdGVkIE5JQ3MuClsgICAgMC4wMDAwMDBdIEJsa2Zy
b250IGFuZCB0aGUgWGVuIHBsYXRmb3JtIFBDSSBkcml2ZXIgaGF2ZSBiZWVuIGNvbXBpbGVk
IGZvciB0aGlzIGtlcm5lbDogdW5wbHVnIGVtdWxhdGVkIGRpc2tzLgpbICAgIDAuMDAwMDAw
XSBZb3UgbWlnaHQgaGF2ZSB0byBjaGFuZ2UgdGhlIHJvb3QgZGV2aWNlClsgICAgMC4wMDAw
MDBdIGZyb20gL2Rldi9oZFthLWRdIHRvIC9kZXYveHZkW2EtZF0KWyAgICAwLjAwMDAwMF0g
aW4geW91ciByb290PSBrZXJuZWwgY29tbWFuZCBsaW5lIG9wdGlvbgpbICAgIDAuMDAwMDAw
XSBIVk1PUF9wYWdldGFibGVfZHlpbmcgbm90IHN1cHBvcnRlZApbICAgIDAuMDAwMDAwXSBl
ODIwOiB1cGRhdGUgW21lbSAweDAwMDAwMDAwLTB4MDAwMDBmZmZdIHVzYWJsZSA9PT4gcmVz
ZXJ2ZWQKWyAgICAwLjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHgwMDBhMDAwMC0weDAw
MGZmZmZmXSB1c2FibGUKWyAgICAwLjAwMDAwMF0gQUdQOiBObyBBR1AgYnJpZGdlIGZvdW5k
ClsgICAgMC4wMDAwMDBdIGU4MjA6IGxhc3RfcGZuID0gMHgzZjdmZSBtYXhfYXJjaF9wZm4g
PSAweDQwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBNVFJSIGRlZmF1bHQgdHlwZTogd3JpdGUt
YmFjawpbICAgIDAuMDAwMDAwXSBNVFJSIGZpeGVkIHJhbmdlcyBlbmFibGVkOgpbICAgIDAu
MDAwMDAwXSAgIDAwMDAwLTlGRkZGIHdyaXRlLWJhY2sKWyAgICAwLjAwMDAwMF0gICBBMDAw
MC1CRkZGRiB3cml0ZS1jb21iaW5pbmcKWyAgICAwLjAwMDAwMF0gICBDMDAwMC1GRkZGRiB3
cml0ZS1iYWNrClsgICAgMC4wMDAwMDBdIE1UUlIgdmFyaWFibGUgcmFuZ2VzIGVuYWJsZWQ6
ClsgICAgMC4wMDAwMDBdICAgMCBiYXNlIDAwMDBGMDAwMDAwMCBtYXNrIEZGRkZGMDAwMDAw
MCB1bmNhY2hhYmxlClsgICAgMC4wMDAwMDBdICAgMSBkaXNhYmxlZApbICAgIDAuMDAwMDAw
XSAgIDIgZGlzYWJsZWQKWyAgICAwLjAwMDAwMF0gICAzIGRpc2FibGVkClsgICAgMC4wMDAw
MDBdICAgNCBkaXNhYmxlZApbICAgIDAuMDAwMDAwXSAgIDUgZGlzYWJsZWQKWyAgICAwLjAw
MDAwMF0gICA2IGRpc2FibGVkClsgICAgMC4wMDAwMDBdICAgNyBkaXNhYmxlZApbICAgIDAu
MDAwMDAwXSBUT00yOiAwMDAwMDAwNTYwMDAwMDAwIGFrYSAyMjAxNk0KWyAgICAwLjAwMDAw
MF0geDg2IFBBVCBlbmFibGVkOiBjcHUgMCwgb2xkIDB4NzA0MDYwMDA3MDQwNiwgbmV3IDB4
NzAxMDYwMDA3MDEwNgpbICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgW21l
bSAweDAwMGY1Y2MwLTB4MDAwZjVjY2ZdIG1hcHBlZCBhdCBbZmZmZjg4MDAwMDBmNWNjMF0K
WyAgICAwLjAwMDAwMF0gU2Nhbm5pbmcgMSBhcmVhcyBmb3IgbG93IG1lbW9yeSBjb3JydXB0
aW9uClsgICAgMC4wMDAwMDBdIEJhc2UgbWVtb3J5IHRyYW1wb2xpbmUgYXQgW2ZmZmY4ODAw
MDAwOTkwMDBdIDk5MDAwIHNpemUgMjQ1NzYKWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlf
bWFwcGluZzogW21lbSAweDAwMDAwMDAwLTB4MDAwZmZmZmZdClsgICAgMC4wMDAwMDBdICBb
bWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0gcGFnZSA0awpbICAgIDAuMDAwMDAwXSBCUksg
WzB4MDIyZmUwMDAsIDB4MDIyZmVmZmZdIFBHVEFCTEUKWyAgICAwLjAwMDAwMF0gQlJLIFsw
eDAyMmZmMDAwLCAweDAyMmZmZmZmXSBQR1RBQkxFClsgICAgMC4wMDAwMDBdIEJSSyBbMHgw
MjMwMDAwMCwgMHgwMjMwMGZmZl0gUEdUQUJMRQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9y
eV9tYXBwaW5nOiBbbWVtIDB4M2Y0MDAwMDAtMHgzZjVmZmZmZl0KWyAgICAwLjAwMDAwMF0g
IFttZW0gMHgzZjQwMDAwMC0weDNmNWZmZmZmXSBwYWdlIDJNClsgICAgMC4wMDAwMDBdIGlu
aXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgzYzAwMDAwMC0weDNmM2ZmZmZmXQpbICAgIDAu
MDAwMDAwXSAgW21lbSAweDNjMDAwMDAwLTB4M2YzZmZmZmZdIHBhZ2UgMk0KWyAgICAwLjAw
MDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZd
ClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAxMDAwMDAtMHgwMDFmZmZmZl0gcGFnZSA0awpb
ICAgIDAuMDAwMDAwXSAgW21lbSAweDAwMjAwMDAwLTB4M2JmZmZmZmZdIHBhZ2UgMk0KWyAg
ICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDNmNjAwMDAwLTB4M2Y3
ZmRmZmZdClsgICAgMC4wMDAwMDBdICBbbWVtIDB4M2Y2MDAwMDAtMHgzZjdmZGZmZl0gcGFn
ZSA0awpbICAgIDAuMDAwMDAwXSBCUksgWzB4MDIzMDEwMDAsIDB4MDIzMDFmZmZdIFBHVEFC
TEUKWyAgICAwLjAwMDAwMF0gUkFNRElTSzogW21lbSAweDM3YzQ4MDAwLTB4MzdlMWJmZmZd
ClsgICAgMC4wMDAwMDBdIEFDUEk6IEVhcmx5IHRhYmxlIGNoZWNrc3VtIHZlcmlmaWNhdGlv
biBkaXNhYmxlZApbICAgIDAuMDAwMDAwXSBBQ1BJOiBSU0RQIDB4MDAwMDAwMDAwMDBGNUMx
MCAwMDAwMjQgKHYwMiBYZW4gICApClsgICAgMC4wMDAwMDBdIEFDUEk6IFhTRFQgMHgwMDAw
MDAwMEZDMDBBMTQwIDAwMDA1NCAodjAxIFhlbiAgICBIVk0gICAgICAwMDAwMDAwMCBIVk1M
IDAwMDAwMDAwKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBGQUNQIDB4MDAwMDAwMDBGQzAwOUE3
MCAwMDAwRjQgKHYwNCBYZW4gICAgSFZNICAgICAgMDAwMDAwMDAgSFZNTCAwMDAwMDAwMCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogRFNEVCAweDAwMDAwMDAwRkMwMDEzMDAgMDA4NkYwICh2
MDIgWGVuICAgIEhWTSAgICAgIDAwMDAwMDAwIElOVEwgMjAxMDA1MjgpClsgICAgMC4wMDAw
MDBdIEFDUEk6IEZBQ1MgMHgwMDAwMDAwMEZDMDAxMkMwIDAwMDA0MApbICAgIDAuMDAwMDAw
XSBBQ1BJOiBBUElDIDB4MDAwMDAwMDBGQzAwOUI3MCAwMDA0NjAgKHYwMiBYZW4gICAgSFZN
ICAgICAgMDAwMDAwMDAgSFZNTCAwMDAwMDAwMCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSFBF
VCAweDAwMDAwMDAwRkMwMEEwNTAgMDAwMDM4ICh2MDEgWGVuICAgIEhWTSAgICAgIDAwMDAw
MDAwIEhWTUwgMDAwMDAwMDApClsgICAgMC4wMDAwMDBdIEFDUEk6IFdBRVQgMHgwMDAwMDAw
MEZDMDBBMDkwIDAwMDAyOCAodjAxIFhlbiAgICBIVk0gICAgICAwMDAwMDAwMCBIVk1MIDAw
MDAwMDAwKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDB4MDAwMDAwMDBGQzAwQTBDMCAw
MDAwMzEgKHYwMiBYZW4gICAgSFZNICAgICAgMDAwMDAwMDAgSU5UTCAyMDEwMDUyOCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogU1NEVCAweDAwMDAwMDAwRkMwMEExMDAgMDAwMDMxICh2MDIg
WGVuICAgIEhWTSAgICAgIDAwMDAwMDAwIElOVEwgMjAxMDA1MjgpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIE5v
IE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZApbICAgIDAuMDAwMDAwXSBGYWtpbmcgYSBub2Rl
IGF0IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAzZjdmZGZmZl0KWyAgICAw
LjAwMDAwMF0gTk9ERV9EQVRBKDApIGFsbG9jYXRlZCBbbWVtIDB4M2Y3ZjMwMDAtMHgzZjdm
ZGZmZl0KWyAgICAwLjAwMDAwMF0gIFtmZmZmZWEwMDAwMDAwMDAwLWZmZmZlYTAwMDBmZmZm
ZmZdIFBNRCAtPiBbZmZmZjg4MDAzZGUwMDAwMC1mZmZmODgwMDNlZGZmZmZmXSBvbiBub2Rl
IDAKWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6ClsgICAgMC4wMDAwMDBdICAgRE1BICAg
ICAgW21lbSAweDAwMDAxMDAwLTB4MDBmZmZmZmZdClsgICAgMC4wMDAwMDBdICAgRE1BMzIg
ICAgW21lbSAweDAxMDAwMDAwLTB4ZmZmZmZmZmZdClsgICAgMC4wMDAwMDBdICAgTm9ybWFs
ICAgZW1wdHkKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0IGZvciBlYWNoIG5v
ZGUKWyAgICAwLjAwMDAwMF0gRWFybHkgbWVtb3J5IG5vZGUgcmFuZ2VzClsgICAgMC4wMDAw
MDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAwMTAwMC0weDAwMDllZmZmXQpbICAgIDAuMDAw
MDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4MDAxMDAwMDAtMHgzZjdmZGZmZl0KWyAgICAwLjAw
MDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAgW21lbSAweDAwMDAxMDAwLTB4M2Y3ZmRmZmZd
ClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAyNTk5OTYKWyAgICAwLjAw
MDAwMF0gICBETUEgem9uZTogNjQgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAw
MDBdICAgRE1BIHpvbmU6IDIxIHBhZ2VzIHJlc2VydmVkClsgICAgMC4wMDAwMDBdICAgRE1B
IHpvbmU6IDM5OTggcGFnZXMsIExJRk8gYmF0Y2g6MApbICAgIDAuMDAwMDAwXSAgIERNQTMy
IHpvbmU6IDQwMDAgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgRE1B
MzIgem9uZTogMjU1OTk4IHBhZ2VzLCBMSUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdIEFD
UEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4YjAwOApbICAgIDAuMDAwMDAwXSBBQ1BJOiBMb2Nh
bCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDAwXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDA0XSBl
bmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBp
Y19pZFsweDA2XSBlbmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDA0XSBsYXBpY19pZFsweDA4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwYV0gZGlzYWJsZWQpClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MGNdIGRpc2Fi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA3XSBsYXBpY19p
ZFsweDBlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwOF0gbGFwaWNfaWRbMHgxMF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MDldIGxhcGljX2lkWzB4MTJdIGRpc2FibGVkKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBhXSBsYXBpY19pZFsweDE0XSBkaXNhYmxl
ZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwYl0gbGFwaWNfaWRb
MHgxNl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
MGNdIGxhcGljX2lkWzB4MThdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDBkXSBsYXBpY19pZFsweDFhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwZV0gbGFwaWNfaWRbMHgxY10gZGlzYWJsZWQp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGZdIGxhcGljX2lkWzB4
MWVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDEw
XSBsYXBpY19pZFsweDIwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgxMV0gbGFwaWNfaWRbMHgyMl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MTJdIGxhcGljX2lkWzB4MjRdIGRpc2FibGVkKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDEzXSBsYXBpY19pZFsweDI2
XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxNF0g
bGFwaWNfaWRbMHgyOF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4MTVdIGxhcGljX2lkWzB4MmFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDE2XSBsYXBpY19pZFsweDJjXSBkaXNhYmxlZCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxN10gbGFwaWNfaWRbMHgyZV0g
ZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MThdIGxh
cGljX2lkWzB4MzBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDE5XSBsYXBpY19pZFsweDMyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgxYV0gbGFwaWNfaWRbMHgzNF0gZGlzYWJsZWQpClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MWJdIGxhcGljX2lkWzB4MzZdIGRp
c2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDFjXSBsYXBp
Y19pZFsweDM4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgxZF0gbGFwaWNfaWRbMHgzYV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4MWVdIGxhcGljX2lkWzB4M2NdIGRpc2FibGVkKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDFmXSBsYXBpY19pZFsweDNlXSBkaXNh
YmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyMF0gbGFwaWNf
aWRbMHg0MF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MjFdIGxhcGljX2lkWzB4NDJdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDIyXSBsYXBpY19pZFsweDQ0XSBkaXNhYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyM10gbGFwaWNfaWRbMHg0Nl0gZGlzYWJs
ZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MjRdIGxhcGljX2lk
WzB4NDhdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDI1XSBsYXBpY19pZFsweDRhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgyNl0gbGFwaWNfaWRbMHg0Y10gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MjddIGxhcGljX2lkWzB4NGVdIGRpc2FibGVk
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDI4XSBsYXBpY19pZFsw
eDUwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgy
OV0gbGFwaWNfaWRbMHg1Ml0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4MmFdIGxhcGljX2lkWzB4NTRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDJiXSBsYXBpY19pZFsweDU2XSBkaXNhYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyY10gbGFwaWNfaWRbMHg1
OF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MmRd
IGxhcGljX2lkWzB4NWFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDJlXSBsYXBpY19pZFsweDVjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyZl0gbGFwaWNfaWRbMHg1ZV0gZGlzYWJsZWQpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MzBdIGxhcGljX2lkWzB4NjBd
IGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDMxXSBs
YXBpY19pZFsweDYyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgzMl0gbGFwaWNfaWRbMHg2NF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MzNdIGxhcGljX2lkWzB4NjZdIGRpc2FibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDM0XSBsYXBpY19pZFsweDY4XSBk
aXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgzNV0gbGFw
aWNfaWRbMHg2YV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MzZdIGxhcGljX2lkWzB4NmNdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDM3XSBsYXBpY19pZFsweDZlXSBkaXNhYmxlZCkKWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgzOF0gbGFwaWNfaWRbMHg3MF0gZGlz
YWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MzldIGxhcGlj
X2lkWzB4NzJdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDNhXSBsYXBpY19pZFsweDc0XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgzYl0gbGFwaWNfaWRbMHg3Nl0gZGlzYWJsZWQpClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4M2NdIGxhcGljX2lkWzB4NzhdIGRpc2Fi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDNkXSBsYXBpY19p
ZFsweDdhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgzZV0gbGFwaWNfaWRbMHg3Y10gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4M2ZdIGxhcGljX2lkWzB4N2VdIGRpc2FibGVkKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQwXSBsYXBpY19pZFsweDgwXSBkaXNhYmxl
ZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0MV0gbGFwaWNfaWRb
MHg4Ml0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
NDJdIGxhcGljX2lkWzB4ODRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDQzXSBsYXBpY19pZFsweDg2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0NF0gbGFwaWNfaWRbMHg4OF0gZGlzYWJsZWQp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NDVdIGxhcGljX2lkWzB4
OGFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQ2
XSBsYXBpY19pZFsweDhjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHg0N10gbGFwaWNfaWRbMHg4ZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4NDhdIGxhcGljX2lkWzB4OTBdIGRpc2FibGVkKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQ5XSBsYXBpY19pZFsweDky
XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0YV0g
bGFwaWNfaWRbMHg5NF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4NGJdIGxhcGljX2lkWzB4OTZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDRjXSBsYXBpY19pZFsweDk4XSBkaXNhYmxlZCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0ZF0gbGFwaWNfaWRbMHg5YV0g
ZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NGVdIGxh
cGljX2lkWzB4OWNdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDRmXSBsYXBpY19pZFsweDllXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHg1MF0gbGFwaWNfaWRbMHhhMF0gZGlzYWJsZWQpClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NTFdIGxhcGljX2lkWzB4YTJdIGRp
c2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDUyXSBsYXBp
Y19pZFsweGE0XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHg1M10gbGFwaWNfaWRbMHhhNl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4NTRdIGxhcGljX2lkWzB4YThdIGRpc2FibGVkKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDU1XSBsYXBpY19pZFsweGFhXSBkaXNh
YmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1Nl0gbGFwaWNf
aWRbMHhhY10gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4NTddIGxhcGljX2lkWzB4YWVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDU4XSBsYXBpY19pZFsweGIwXSBkaXNhYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1OV0gbGFwaWNfaWRbMHhiMl0gZGlzYWJs
ZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NWFdIGxhcGljX2lk
WzB4YjRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDViXSBsYXBpY19pZFsweGI2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHg1Y10gbGFwaWNfaWRbMHhiOF0gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NWRdIGxhcGljX2lkWzB4YmFdIGRpc2FibGVk
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDVlXSBsYXBpY19pZFsw
eGJjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1
Zl0gbGFwaWNfaWRbMHhiZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4NjBdIGxhcGljX2lkWzB4YzBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDYxXSBsYXBpY19pZFsweGMyXSBkaXNhYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2Ml0gbGFwaWNfaWRbMHhj
NF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NjNd
IGxhcGljX2lkWzB4YzZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDY0XSBsYXBpY19pZFsweGM4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2NV0gbGFwaWNfaWRbMHhjYV0gZGlzYWJsZWQpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NjZdIGxhcGljX2lkWzB4Y2Nd
IGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDY3XSBs
YXBpY19pZFsweGNlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHg2OF0gbGFwaWNfaWRbMHhkMF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4NjldIGxhcGljX2lkWzB4ZDJdIGRpc2FibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDZhXSBsYXBpY19pZFsweGQ0XSBk
aXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2Yl0gbGFw
aWNfaWRbMHhkNl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4NmNdIGxhcGljX2lkWzB4ZDhdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDZkXSBsYXBpY19pZFsweGRhXSBkaXNhYmxlZCkKWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2ZV0gbGFwaWNfaWRbMHhkY10gZGlz
YWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NmZdIGxhcGlj
X2lkWzB4ZGVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDcwXSBsYXBpY19pZFsweGUwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHg3MV0gbGFwaWNfaWRbMHhlMl0gZGlzYWJsZWQpClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NzJdIGxhcGljX2lkWzB4ZTRdIGRpc2Fi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDczXSBsYXBpY19p
ZFsweGU2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHg3NF0gbGFwaWNfaWRbMHhlOF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4NzVdIGxhcGljX2lkWzB4ZWFdIGRpc2FibGVkKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDc2XSBsYXBpY19pZFsweGVjXSBkaXNhYmxl
ZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3N10gbGFwaWNfaWRb
MHhlZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
NzhdIGxhcGljX2lkWzB4ZjBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDc5XSBsYXBpY19pZFsweGYyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3YV0gbGFwaWNfaWRbMHhmNF0gZGlzYWJsZWQp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4N2JdIGxhcGljX2lkWzB4
ZjZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDdj
XSBsYXBpY19pZFsweGY4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHg3ZF0gbGFwaWNfaWRbMHhmYV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4N2VdIGxhcGljX2lkWzB4ZmNdIGRpc2FibGVkKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDdmXSBsYXBpY19pZFsweGZl
XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDAxXSBhZGRy
ZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQpbICAgIDAuMDAwMDAwXSBJT0FQSUNbMF06
IGFwaWNfaWQgMSwgdmVyc2lvbiAxNywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC00Nwpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2Jh
bF9pcnEgMiBkZmwgZGZsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVz
IDAgYnVzX2lycSA1IGdsb2JhbF9pcnEgNSBsb3cgbGV2ZWwpClsgICAgMC4wMDAwMDBdIEFD
UEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDEwIGdsb2JhbF9pcnEgMTAgbG93IGxl
dmVsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAx
MSBnbG9iYWxfaXJxIDExIGxvdyBsZXZlbCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMCB1
c2VkIGJ5IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE1IHVzZWQgYnkgb3Zl
cnJpZGUuClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KWyAg
ICAwLjAwMDAwMF0gQUNQSTogSVJRMTAgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAw
MF0gQUNQSTogSVJRMTEgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAwMF0gVXNpbmcg
QUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uClsgICAgMC4w
MDAwMDBdIEFDUEk6IEhQRVQgaWQ6IDB4ODA4NmEyMDEgYmFzZTogMHhmZWQwMDAwMApbICAg
IDAuMDAwMDAwXSBzbXBib290OiAxMjggUHJvY2Vzc29ycyBleGNlZWRzIE5SX0NQVVMgbGlt
aXQgb2YgOApbICAgIDAuMDAwMDAwXSBzbXBib290OiBBbGxvd2luZyA4IENQVXMsIDQgaG90
cGx1ZyBDUFVzClsgICAgMC4wMDAwMDBdIGU4MjA6IFttZW0gMHgzZjgwMDAwMC0weGZiZmZm
ZmZmXSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2VzClsgICAgMC4wMDAwMDBdIEJvb3Rpbmcg
cGFyYXZpcnR1YWxpemVkIGtlcm5lbCBvbiBYZW4gSFZNClsgICAgMC4wMDAwMDBdIHNldHVw
X3BlcmNwdTogTlJfQ1BVUzo4IG5yX2NwdW1hc2tfYml0czo4IG5yX2NwdV9pZHM6OCBucl9u
b2RlX2lkczoxClsgICAgMC4wMDAwMDBdIFBFUkNQVTogRW1iZWRkZWQgMjkgcGFnZXMvY3B1
IEBmZmZmODgwMDNmNDAwMDAwIHM3OTQ4OCByODE5MiBkMzExMDQgdTI2MjE0NApbICAgIDAu
MDAwMDAwXSBwY3B1LWFsbG9jOiBzNzk0ODggcjgxOTIgZDMxMTA0IHUyNjIxNDQgYWxsb2M9
MSoyMDk3MTUyClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IFswXSAwIDEgMiAzIDQgNSA2
IDcgClsgICAgMC4wMDAwMDBdIHhlbjogUFYgc3BpbmxvY2tzIGVuYWJsZWQKWyAgICAwLjAw
MDAwMF0gQnVpbHQgMSB6b25lbGlzdHMgaW4gTm9kZSBvcmRlciwgbW9iaWxpdHkgZ3JvdXBp
bmcgb24uICBUb3RhbCBwYWdlczogMjU1OTExClsgICAgMC4wMDAwMDBdIFBvbGljeSB6b25l
OiBETUEzMgpbICAgIDAuMDAwMDAwXSBLZXJuZWwgY29tbWFuZCBsaW5lOiBCT09UX0lNQUdF
PS9ib290L3ZtbGludXotMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0eSsgcm9vdD0vZGV2
L3h2ZGExIHJvIGNvbnNvbGU9dHR5MSBjb25zb2xlPXR0eVMwIG5vbW9kZXNldApbICAgIDAu
MDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMywgMzI3Njgg
Ynl0ZXMpClsgICAgMC4wMDAwMDBdIEFHUDogQ2hlY2tpbmcgYXBlcnR1cmUuLi4KWyAgICAw
LjAwMDAwMF0gQUdQOiBObyBBR1AgYnJpZGdlIGZvdW5kClsgICAgMC4wMDAwMDBdIE1lbW9y
eTogMTAwMTEyMEsvMTAzOTk4NEsgYXZhaWxhYmxlICgxMDk0MEsga2VybmVsIGNvZGUsIDg4
NksgcndkYXRhLCAzNTAwSyByb2RhdGEsIDEwNDhLIGluaXQsIDEwNzZLIGJzcywgMzg4NjRL
IHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSBTTFVCOiBIV2FsaWduPTY0LCBPcmRlcj0wLTMs
IE1pbk9iamVjdHM9MCwgQ1BVcz04LCBOb2Rlcz0xClsgICAgMC4wMDAwMDBdIEhpZXJhcmNo
aWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uClsgICAgMC4wMDAwMDBdIAlSQ1UgZHludGljay1p
ZGxlIGdyYWNlLXBlcmlvZCBhY2NlbGVyYXRpb24gaXMgZW5hYmxlZC4KWyAgICAwLjAwMDAw
MF0gTlJfSVJRUzo0MzUyIG5yX2lycXM6ODk2IDAKWyAgICAwLjAwMDAwMF0geGVuOmV2ZW50
czogVXNpbmcgRklGTy1iYXNlZCBBQkkKWyAgICAwLjAwMDAwMF0geGVuOmV2ZW50czogWGVu
IEhWTSBjYWxsYmFjayB2ZWN0b3IgZm9yIGV2ZW50IGRlbGl2ZXJ5IGlzIGVuYWJsZWQKWyAg
ICAwLjAwMDAwMF0gQ29uc29sZTogY29sb3VyIFZHQSsgODB4MjUKWyAgICAwLjAwMDAwMF0g
Y29uc29sZSBbdHR5MV0gZW5hYmxlZApbICAgIDAuMDAwMDAwXSBjb25zb2xlIFt0dHlTMF0g
ZW5hYmxlZApbICAgIDAuMDAwMDAwXSBocGV0IGNsb2NrZXZlbnQgcmVnaXN0ZXJlZApbICAg
IDAuMDAwMDAwXSB0c2M6IERldGVjdGVkIDMyMDAuMTU2IE1IeiBwcm9jZXNzb3IKWyAgICAw
LjAwMDAwMF0gdHNjOiBNYXJraW5nIFRTQyB1bnN0YWJsZSBkdWUgdG8gVFNDcyB1bnN5bmNo
cm9uaXplZApbICAgIDAuMDE2NjY2XSBDYWxpYnJhdGluZyBkZWxheSBsb29wIChza2lwcGVk
KSwgdmFsdWUgY2FsY3VsYXRlZCB1c2luZyB0aW1lciBmcmVxdWVuY3kuLiA2NDAyLjk5IEJv
Z29NSVBTIChscGo9MTA2NjcxODYpClsgICAgMC4wMjY2NzJdIHBpZF9tYXg6IGRlZmF1bHQ6
IDMyNzY4IG1pbmltdW06IDMwMQpbICAgIDAuMDMzMzQ4XSBBQ1BJOiBDb3JlIHJldmlzaW9u
IDIwMTQwOTI2ClsgICAgMC4wNDgwODZdIEFDUEk6IEFsbCBBQ1BJIFRhYmxlcyBzdWNjZXNz
ZnVsbHkgYWNxdWlyZWQKWyAgICAwLjA1NDg2MV0gRGVudHJ5IGNhY2hlIGhhc2ggdGFibGUg
ZW50cmllczogMTMxMDcyIChvcmRlcjogOCwgMTA0ODU3NiBieXRlcykKWyAgICAwLjA2MzU1
OV0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUy
NDI4OCBieXRlcykKWyAgICAwLjA3MzM5NF0gTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRy
aWVzOiAyMDQ4IChvcmRlcjogMiwgMTYzODQgYnl0ZXMpClsgICAgMC4wODAwMDhdIE1vdW50
cG9pbnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChvcmRlcjogMiwgMTYzODQg
Ynl0ZXMpClsgICAgMC4wOTAxNTBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGZyZWV6
ZXIKWyAgICAwLjA5MzM0M10gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgYmxraW8KWyAg
ICAwLjEwMDEzMl0gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6IDAKWyAgICAwLjEwNjY2
OV0gQ1BVOiBQcm9jZXNzb3IgQ29yZSBJRDogMApbICAgIDAuMTEwMDA3XSBtY2U6IENQVSBz
dXBwb3J0cyAyIE1DRSBiYW5rcwpbICAgIDAuMTE2NjkxXSBMYXN0IGxldmVsIGlUTEIgZW50
cmllczogNEtCIDUxMiwgMk1CIDE2LCA0TUIgOApbICAgIDAuMTE2NjkxXSBMYXN0IGxldmVs
IGRUTEIgZW50cmllczogNEtCIDUxMiwgMk1CIDEyOCwgNE1CIDY0LCAxR0IgMApbICAgIDAu
MTMwMjgyXSBGcmVlaW5nIFNNUCBhbHRlcm5hdGl2ZXMgbWVtb3J5OiA0MEsgKGZmZmZmZmZm
ODIxZTUwMDAgLSBmZmZmZmZmZjgyMWVmMDAwKQpbICAgIDAuMTQ4OTc4XSAuLlRJTUVSOiB2
ZWN0b3I9MHgzMCBhcGljMT0wIHBpbjE9MiBhcGljMj0wIHBpbjI9MApbICAgIDAuMTg5NTI5
XSBzbXBib290OiBDUFUwOiBBTUQgUGhlbm9tKHRtKSBJSSBYNiAxMDkwVCBQcm9jZXNzb3Ig
KGZhbTogMTAsIG1vZGVsOiAwYSwgc3RlcHBpbmc6IDAwKQpbICAgIDAuMjAyOTA0XSBYZW46
IHVzaW5nIHZjcHVvcCB0aW1lciBpbnRlcmZhY2UKWyAgICAwLjIwMjkxMV0gaW5zdGFsbGlu
ZyBYZW4gdGltZXIgZm9yIENQVSAwClsgICAgMC4yMDY3NDhdIGNwdSAwIHNwaW5sb2NrIGV2
ZW50IGlycSA1MwpbICAgIDAuMjE3MjY4XSBQZXJmb3JtYW5jZSBFdmVudHM6IEJyb2tlbiBQ
TVUgaGFyZHdhcmUgZGV0ZWN0ZWQsIHVzaW5nIHNvZnR3YXJlIGV2ZW50cyBvbmx5LgpbICAg
IDAuMjIzMzQxXSBGYWlsZWQgdG8gYWNjZXNzIHBlcmZjdHIgbXNyIChNU1IgYzAwMTAwMDQg
aXMgMCkKWyAgICAwLjIyNjkzNl0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAxClsg
ICAgMC4yMzAwNTNdIHg4NjogQm9vdGluZyBTTVAgY29uZmlndXJhdGlvbjoKWyAgICAwLjIz
MzM0MF0gLi4uLiBub2RlICAjMCwgQ1BVczogICAgICAjMWNwdSAxIHNwaW5sb2NrIGV2ZW50
IGlycSA1OQpbICAgIDAuMzM2Nzg5XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDIK
WyAgICAwLjM0MDA1OF0gICMyY3B1IDIgc3BpbmxvY2sgZXZlbnQgaXJxIDY1ClsgICAgMC40
NDAxMjddIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMwpbICAgIDAuNDQzMzk0XSAg
IzNjcHUgMyBzcGlubG9jayBldmVudCBpcnEgNzEKWyAgICAwLjU0MzM4MF0geDg2OiBCb290
ZWQgdXAgMSBub2RlLCA0IENQVXMKWyAgICAwLjU0NjY3Nl0gc21wYm9vdDogVG90YWwgb2Yg
NCBwcm9jZXNzb3JzIGFjdGl2YXRlZCAoMjU2MjguNzEgQm9nb01JUFMpClsgICAgMC41NTM0
NjVdIGRldnRtcGZzOiBpbml0aWFsaXplZApbICAgIDAuNTU2OTYzXSB4b3I6IG1lYXN1cmlu
ZyBzb2Z0d2FyZSBjaGVja3N1bSBzcGVlZApbICAgIDAuNTkzMzQyXSAgICBwcmVmZXRjaDY0
LXNzZTogICA4OTcuNjAwIE1CL3NlYwpbICAgIDAuNjMwMDA0XSAgICBnZW5lcmljX3NzZTog
ICA5MTIuMDAwIE1CL3NlYwpbICAgIDAuNjMzMzM4XSB4b3I6IHVzaW5nIGZ1bmN0aW9uOiBn
ZW5lcmljX3NzZSAoOTEyLjAwMCBNQi9zZWMpClsgICAgMC42MzY3NzNdIE5FVDogUmVnaXN0
ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKWyAgICAwLjY0MDIxM10geGVuYnVzOiB4c19yZXNl
dF93YXRjaGVzIGZhaWxlZDogLTM4ClsgICAgMC42NjMzNDddIGNwdWlkbGU6IHVzaW5nIGdv
dmVybm9yIGxhZGRlcgpbICAgIDAuNjg2Njk0XSBjcHVpZGxlOiB1c2luZyBnb3Zlcm5vciBt
ZW51ClsgICAgMC42OTY0MjldIEFDUEk6IGJ1cyB0eXBlIFBDSSByZWdpc3RlcmVkClsgICAg
MC43MDMzMzldIGFjcGlwaHA6IEFDUEkgSG90IFBsdWcgUENJIENvbnRyb2xsZXIgRHJpdmVy
IHZlcnNpb246IDAuNQpbICAgIDAuNzE0MTk5XSBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24g
dHlwZSAxIGZvciBiYXNlIGFjY2VzcwpbICAgIDAuNzIzMzQyXSBQQ0k6IFVzaW5nIGNvbmZp
Z3VyYXRpb24gdHlwZSAxIGZvciBleHRlbmRlZCBhY2Nlc3MKWyAgICAwLjgwNTMzOV0gcmFp
ZDY6IHNzZTJ4MSAgICAyOTI1IE1CL3MKWyAgICAwLjg2NTMxMV0gcmFpZDY6IHNzZTJ4MiAg
ICAzODk1IE1CL3MKWyAgICAwLjkyNTI4N10gcmFpZDY6IHNzZTJ4NCAgICAzOTQ4IE1CL3MK
WyAgICAwLjkzMDAwN10gcmFpZDY6IHVzaW5nIGFsZ29yaXRobSBzc2UyeDQgKDM5NDggTUIv
cykKWyAgICAwLjkzNjY3M10gcmFpZDY6IHVzaW5nIGludHgxIHJlY292ZXJ5IGFsZ29yaXRo
bQpbICAgIDAuOTQzNDI0XSBBQ1BJOiBBZGRlZCBfT1NJKE1vZHVsZSBEZXZpY2UpClsgICAg
MC45NTAwMDVdIEFDUEk6IEFkZGVkIF9PU0koUHJvY2Vzc29yIERldmljZSkKWyAgICAwLjk1
NjY3N10gQUNQSTogQWRkZWQgX09TSSgzLjAgX1NDUCBFeHRlbnNpb25zKQpbICAgIDAuOTYw
MDA1XSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBBZ2dyZWdhdG9yIERldmljZSkKWyAg
ICAwLjk3NjYwNF0gQUNQSTogSW50ZXJwcmV0ZXIgZW5hYmxlZApbICAgIDAuOTgzMzQyXSBB
Q1BJOiAoc3VwcG9ydHMgUzAgUzUpClsgICAgMC45ODY2NzZdIEFDUEk6IFVzaW5nIElPQVBJ
QyBmb3IgaW50ZXJydXB0IHJvdXRpbmcKWyAgICAwLjk5MzM5M10gUENJOiBVc2luZyBob3N0
IGJyaWRnZSB3aW5kb3dzIGZyb20gQUNQSTsgaWYgbmVjZXNzYXJ5LCB1c2UgInBjaT1ub2Ny
cyIgYW5kIHJlcG9ydCBhIGJ1ZwpbICAgIDEuMDI3NDQwXSBBQ1BJOiBQQ0kgUm9vdCBCcmlk
Z2UgW1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkKWyAgICAxLjAzMDAxMV0gYWNw
aSBQTlAwQTAzOjAwOiBfT1NDOiBPUyBzdXBwb3J0cyBbRXh0ZW5kZWRDb25maWcgQVNQTSBD
bG9ja1BNIFNlZ21lbnRzIE1TSV0KWyAgICAxLjAzMzM0N10gYWNwaSBQTlAwQTAzOjAwOiBf
T1NDIGZhaWxlZCAoQUVfTk9UX0ZPVU5EKTsgZGlzYWJsaW5nIEFTUE0KWyAgICAxLjAzNzYx
M10gYWNwaXBocDogU2xvdCBbM10gcmVnaXN0ZXJlZApbICAgIDEuMDQwMTA4XSBhY3BpcGhw
OiBTbG90IFs0XSByZWdpc3RlcmVkClsgICAgMS4wNDM0MzhdIGFjcGlwaHA6IFNsb3QgWzVd
IHJlZ2lzdGVyZWQKWyAgICAxLjA0Njc4MF0gYWNwaXBocDogU2xvdCBbNl0gcmVnaXN0ZXJl
ZApbICAgIDEuMDUwMTA1XSBhY3BpcGhwOiBTbG90IFs3XSByZWdpc3RlcmVkClsgICAgMS4w
NTM0MzddIGFjcGlwaHA6IFNsb3QgWzhdIHJlZ2lzdGVyZWQKWyAgICAxLjA1Njc3NF0gYWNw
aXBocDogU2xvdCBbOV0gcmVnaXN0ZXJlZApbICAgIDEuMDYwMTQ2XSBhY3BpcGhwOiBTbG90
IFsxMF0gcmVnaXN0ZXJlZApbICAgIDEuMDYzNDQxXSBhY3BpcGhwOiBTbG90IFsxMV0gcmVn
aXN0ZXJlZApbICAgIDEuMDY2NzUyXSBhY3BpcGhwOiBTbG90IFsxMl0gcmVnaXN0ZXJlZApb
ICAgIDEuMDcwMTA5XSBhY3BpcGhwOiBTbG90IFsxM10gcmVnaXN0ZXJlZApbICAgIDEuMDcz
NDUxXSBhY3BpcGhwOiBTbG90IFsxNF0gcmVnaXN0ZXJlZApbICAgIDEuMDc2NzYyXSBhY3Bp
cGhwOiBTbG90IFsxNV0gcmVnaXN0ZXJlZApbICAgIDEuMDgwMDkwXSBhY3BpcGhwOiBTbG90
IFsxNl0gcmVnaXN0ZXJlZApbICAgIDEuMDgzNDE1XSBhY3BpcGhwOiBTbG90IFsxN10gcmVn
aXN0ZXJlZApbICAgIDEuMDg2NzgyXSBhY3BpcGhwOiBTbG90IFsxOF0gcmVnaXN0ZXJlZApb
ICAgIDEuMDkwMDk1XSBhY3BpcGhwOiBTbG90IFsxOV0gcmVnaXN0ZXJlZApbICAgIDEuMDkz
NDI0XSBhY3BpcGhwOiBTbG90IFsyMF0gcmVnaXN0ZXJlZApbICAgIDEuMDk2Nzc2XSBhY3Bp
cGhwOiBTbG90IFsyMV0gcmVnaXN0ZXJlZApbICAgIDEuMTAwMTAwXSBhY3BpcGhwOiBTbG90
IFsyMl0gcmVnaXN0ZXJlZApbICAgIDEuMTAzNDI5XSBhY3BpcGhwOiBTbG90IFsyM10gcmVn
aXN0ZXJlZApbICAgIDEuMTA2ODQ0XSBhY3BpcGhwOiBTbG90IFsyNF0gcmVnaXN0ZXJlZApb
ICAgIDEuMTEwMDg2XSBhY3BpcGhwOiBTbG90IFsyNV0gcmVnaXN0ZXJlZApbICAgIDEuMTEz
NDIyXSBhY3BpcGhwOiBTbG90IFsyNl0gcmVnaXN0ZXJlZApbICAgIDEuMTE2Nzc2XSBhY3Bp
cGhwOiBTbG90IFsyN10gcmVnaXN0ZXJlZApbICAgIDEuMTIwMDk5XSBhY3BpcGhwOiBTbG90
IFsyOF0gcmVnaXN0ZXJlZApbICAgIDEuMTIzNDI2XSBhY3BpcGhwOiBTbG90IFsyOV0gcmVn
aXN0ZXJlZApbICAgIDEuMTI2NzQ4XSBhY3BpcGhwOiBTbG90IFszMF0gcmVnaXN0ZXJlZApb
ICAgIDEuMTMwMDk3XSBhY3BpcGhwOiBTbG90IFszMV0gcmVnaXN0ZXJlZApbICAgIDEuMTMz
NDA0XSBQQ0kgaG9zdCBicmlkZ2UgdG8gYnVzIDAwMDA6MDAKWyAgICAxLjEzNjY3OF0gcGNp
X2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbYnVzIDAwLWZmXQpbICAgIDEuMTQw
MDEwXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFtpbyAgMHgwMDAwLTB4
MGNmN10KWyAgICAxLjE0MzM0M10gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJj
ZSBbaW8gIDB4MGQwMC0weGZmZmZdClsgICAgMS4xNDY2NzhdIHBjaV9idXMgMDAwMDowMDog
cm9vdCBidXMgcmVzb3VyY2UgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsgICAgMS4x
NTAwMTBdIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW21lbSAweGYwMDAw
MDAwLTB4ZmJmZmZmZmZdClsgICAgMS4xNTM2NDRdIHBjaSAwMDAwOjAwOjAwLjA6IFs4MDg2
OjEyMzddIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAKWyAgICAxLjE1NzgzMF0gcGNpIDAwMDA6
MDA6MDEuMDogWzgwODY6NzAwMF0gdHlwZSAwMCBjbGFzcyAweDA2MDEwMApbICAgIDEuMTYx
Mjc4XSBwY2kgMDAwMDowMDowMS4xOiBbODA4Njo3MDEwXSB0eXBlIDAwIGNsYXNzIDB4MDEw
MTgwClsgICAgMS4xNzg4NzBdIHBjaSAwMDAwOjAwOjAxLjE6IHJlZyAweDIwOiBbaW8gIDB4
YzE2MC0weGMxNmZdClsgICAgMS4xODU4NjBdIHBjaSAwMDAwOjAwOjAxLjE6IGxlZ2FjeSBJ
REUgcXVpcms6IHJlZyAweDEwOiBbaW8gIDB4MDFmMC0weDAxZjddClsgICAgMS4xODY2NzVd
IHBjaSAwMDAwOjAwOjAxLjE6IGxlZ2FjeSBJREUgcXVpcms6IHJlZyAweDE0OiBbaW8gIDB4
MDNmNl0KWyAgICAxLjE5MDAwNV0gcGNpIDAwMDA6MDA6MDEuMTogbGVnYWN5IElERSBxdWly
azogcmVnIDB4MTg6IFtpbyAgMHgwMTcwLTB4MDE3N10KWyAgICAxLjE5MzMzOV0gcGNpIDAw
MDA6MDA6MDEuMTogbGVnYWN5IElERSBxdWlyazogcmVnIDB4MWM6IFtpbyAgMHgwMzc2XQpb
ICAgIDEuMTk3NTA3XSBwY2kgMDAwMDowMDowMS4yOiBbODA4Njo3MDIwXSB0eXBlIDAwIGNs
YXNzIDB4MGMwMzAwClsgICAgMS4yMTU1NjFdIHBjaSAwMDAwOjAwOjAxLjI6IHJlZyAweDIw
OiBbaW8gIDB4YzE0MC0weGMxNWZdClsgICAgMS4yMjMyNTVdIHBjaSAwMDAwOjAwOjAxLjM6
IFs4MDg2OjcxMTNdIHR5cGUgMDAgY2xhc3MgMHgwNjgwMDAKWyAgICAxLjIyNjMwNl0gcGNp
IDAwMDA6MDA6MDEuMzogcXVpcms6IFtpbyAgMHhiMDAwLTB4YjAzZl0gY2xhaW1lZCBieSBQ
SUlYNCBBQ1BJClsgICAgMS4yMjY3NDJdIHBjaSAwMDAwOjAwOjAxLjM6IHF1aXJrOiBbaW8g
IDB4YjEwMC0weGIxMGZdIGNsYWltZWQgYnkgUElJWDQgU01CClsgICAgMS4yMzE0MDZdIHBj
aSAwMDAwOjAwOjAyLjA6IFs1ODUzOjAwMDFdIHR5cGUgMDAgY2xhc3MgMHhmZjgwMDAKWyAg
ICAxLjIzNjY3NV0gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDB4MTA6IFtpbyAgMHhjMDAwLTB4
YzBmZl0KWyAgICAxLjI0MzM0M10gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDB4MTQ6IFttZW0g
MHhmMjAwMDAwMC0weGYyZmZmZmZmIHByZWZdClsgICAgMS4yNzc3NjhdIHBjaSAwMDAwOjAw
OjAzLjA6IFsxMDEzOjAwYjhdIHR5cGUgMDAgY2xhc3MgMHgwMzAwMDAKWyAgICAxLjI4MzM2
N10gcGNpIDAwMDA6MDA6MDMuMDogcmVnIDB4MTA6IFttZW0gMHhmMDAwMDAwMC0weGYxZmZm
ZmZmIHByZWZdClsgICAgMS4yOTAwMDldIHBjaSAwMDAwOjAwOjAzLjA6IHJlZyAweDE0OiBb
bWVtIDB4ZjMyNzIwMDAtMHhmMzI3MmZmZl0KWyAgICAxLjMyMzM0M10gcGNpIDAwMDA6MDA6
MDMuMDogcmVnIDB4MzA6IFttZW0gMHhmMzI2MDAwMC0weGYzMjZmZmZmIHByZWZdClsgICAg
MS4zMjUyNTddIHBjaSAwMDAwOjAwOjA1LjA6IFsxMDMzOjAxOTRdIHR5cGUgMDAgY2xhc3Mg
MHgwYzAzMzAKWyAgICAxLjMzMzM1MF0gcGNpIDAwMDA6MDA6MDUuMDogcmVnIDB4MTA6IFtt
ZW0gMHhmMzI3MDAwMC0weGYzMjcxZmZmIDY0Yml0XQpbICAgIDEuMzcxMzgwXSBwY2kgMDAw
MDowMDowNi4wOiBbMTRmMTo4MjEwXSB0eXBlIDAwIGNsYXNzIDB4MDQwMDAwClsgICAgMS4z
NzY2ODNdIHBjaSAwMDAwOjAwOjA2LjA6IHJlZyAweDEwOiBbbWVtIDB4ZjMwMDAwMDAtMHhm
MzFmZmZmZiA2NGJpdF0KWyAgICAxLjQxMzM0M10gcGNpIDAwMDA6MDA6MDYuMDogc3VwcG9y
dHMgRDEgRDIKWyAgICAxLjQxNjMzOV0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktB
XSAoSVJRcyAqNSAxMCAxMSkKWyAgICAxLjQyMzEwNF0gQUNQSTogUENJIEludGVycnVwdCBM
aW5rIFtMTktCXSAoSVJRcyA1ICoxMCAxMSkKWyAgICAxLjQyOTUyNl0gQUNQSTogUENJIElu
dGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyA1IDEwICoxMSkKWyAgICAxLjQzNjMwM10gQUNQ
STogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyAqNSAxMCAxMSkKWyAgICAxLjQ0
MzExMV0gQUNQSTogRW5hYmxlZCAyIEdQRXMgaW4gYmxvY2sgMDAgdG8gMEYKWyAgICAxLjQ0
MzQwN10geGVuOmJhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlcgpbICAgIDEu
NDUwMDQ1XSB4ZW5fYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24gZHJpdmVyClsgICAg
MS40NjY4NjFdIHZnYWFyYjogc2V0dGluZyBhcyBib290IGRldmljZTogUENJOjAwMDA6MDA6
MDMuMApbICAgIDEuNDY5OTk5XSB2Z2FhcmI6IGRldmljZSBhZGRlZDogUENJOjAwMDA6MDA6
MDMuMCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nrcz1ub25lClsgICAgMS40OTAw
MjldIHZnYWFyYjogbG9hZGVkClsgICAgMS40OTMzNDFdIHZnYWFyYjogYnJpZGdlIGNvbnRy
b2wgcG9zc2libGUgMDAwMDowMDowMy4wClsgICAgMS41MDAxMTFdIFNDU0kgc3Vic3lzdGVt
IGluaXRpYWxpemVkClsgICAgMS41MDY3MDBdIGxpYmF0YSB2ZXJzaW9uIDMuMDAgbG9hZGVk
LgpbICAgIDEuNTA2NzU2XSBBQ1BJOiBidXMgdHlwZSBVU0IgcmVnaXN0ZXJlZApbICAgIDEu
NTEzNDA1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmZz
ClsgICAgMS41MjMzOTldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgaHViClsgICAgMS41MzAwNjFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRldmljZSBk
cml2ZXIgdXNiClsgICAgMS41MzY3MzNdIExpbnV4IHZpZGVvIGNhcHR1cmUgaW50ZXJmYWNl
OiB2Mi4wMApbICAgIDEuNTQzMzg5XSBwcHNfY29yZTogTGludXhQUFMgQVBJIHZlci4gMSBy
ZWdpc3RlcmVkClsgICAgMS41NTAwMDddIHBwc19jb3JlOiBTb2Z0d2FyZSB2ZXIuIDUuMy42
IC0gQ29weXJpZ2h0IDIwMDUtMjAwNyBSb2RvbGZvIEdpb21ldHRpIDxnaW9tZXR0aUBsaW51
eC5pdD4KWyAgICAxLjU2MDAzOF0gUFRQIGNsb2NrIHN1cHBvcnQgcmVnaXN0ZXJlZApbICAg
IDEuNTY2NzQwXSBBZHZhbmNlZCBMaW51eCBTb3VuZCBBcmNoaXRlY3R1cmUgRHJpdmVyIElu
aXRpYWxpemVkLgpbICAgIDEuNTczMzQzXSBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0
aW5nClsgICAgMS41ODAwMDldIFBDSTogcGNpX2NhY2hlX2xpbmVfc2l6ZSBzZXQgdG8gNjQg
Ynl0ZXMKWyAgICAxLjU4MTMwNF0gZTgyMDogcmVzZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHgw
MDA5ZmMwMC0weDAwMDlmZmZmXQpbICAgIDEuNTgxMzA2XSBlODIwOiByZXNlcnZlIFJBTSBi
dWZmZXIgW21lbSAweDNmN2ZlMDAwLTB4M2ZmZmZmZmZdClsgICAgMS41ODE0MjddIEJsdWV0
b290aDogQ29yZSB2ZXIgMi4xOQpbICAgIDEuNTg2Njk0XSBORVQ6IFJlZ2lzdGVyZWQgcHJv
dG9jb2wgZmFtaWx5IDMxClsgICAgMS41OTAwMDRdIEJsdWV0b290aDogSENJIGRldmljZSBh
bmQgY29ubmVjdGlvbiBtYW5hZ2VyIGluaXRpYWxpemVkClsgICAgMS42MDAwMTVdIEJsdWV0
b290aDogSENJIHNvY2tldCBsYXllciBpbml0aWFsaXplZApbICAgIDEuNjA2NjgwXSBCbHVl
dG9vdGg6IEwyQ0FQIHNvY2tldCBsYXllciBpbml0aWFsaXplZApbICAgIDEuNjEzMzQ2XSBC
bHVldG9vdGg6IFNDTyBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgICAxLjYyMDA5NV0g
SFBFVDogMyB0aW1lcnMgaW4gdG90YWwsIDAgdGltZXJzIHdpbGwgYmUgdXNlZCBmb3IgcGVy
LWNwdSB0aW1lcgpbICAgIDEuNjI2NjkwXSBocGV0MDogYXQgTU1JTyAweGZlZDAwMDAwLCBJ
UlFzIDIsIDgsIDAKWyAgICAxLjYzODQ1N10gaHBldDA6IDMgY29tcGFyYXRvcnMsIDY0LWJp
dCA2Mi41MDAwMDAgTUh6IGNvdW50ZXIKWyAgICAxLjY1MDA2Nl0gU3dpdGNoZWQgdG8gY2xv
Y2tzb3VyY2UgeGVuClsgICAgMS42NTU2NDBdIEZTLUNhY2hlOiBMb2FkZWQKWyAgICAxLjY1
OTk2MF0gcG5wOiBQblAgQUNQSSBpbml0ClsgICAgMS42NjQ1OThdIHN5c3RlbSAwMDowMDog
W21lbSAweDAwMDAwMDAwLTB4MDAwOWZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAg
IDEuNjcyNjczXSBzeXN0ZW0gMDA6MDA6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElE
cyBQTlAwYzAyIChhY3RpdmUpClsgICAgMS42NzI3NzRdIHN5c3RlbSAwMDowMTogW2lvICAw
eDA4YTAtMHgwOGEzXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDEuNjg1MjE0XSBzeXN0ZW0g
MDA6MDE6IFtpbyAgMHgwY2MwLTB4MGNjZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAxLjY5
MjU3N10gc3lzdGVtIDAwOjAxOiBbaW8gIDB4MDRkMC0weDA0ZDFdIGhhcyBiZWVuIHJlc2Vy
dmVkClsgICAgMS42OTk2ODNdIHN5c3RlbSAwMDowMTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRl
dmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAxLjY5OTcxNV0geGVuOiAtLT4gcGly
cT0xNiAtPiBpcnE9OCAoZ3NpPTgpClsgICAgMS42OTk3MzRdIHBucCAwMDowMjogUGx1ZyBh
bmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBiMDAgKGFjdGl2ZSkKWyAgICAxLjY5OTc3
N10geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTIgKGdzaT0xMikKWyAgICAxLjY5OTc5MF0g
cG5wIDAwOjAzOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGYxMyAoYWN0
aXZlKQpbICAgIDEuNjk5ODA5XSB4ZW46IC0tPiBwaXJxPTE4IC0+IGlycT0xIChnc2k9MSkK
WyAgICAxLjY5OTgxOV0gcG5wIDAwOjA0OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJ
RHMgUE5QMDMwMyBQTlAwMzBiIChhY3RpdmUpClsgICAgMS42OTk4NDBdIHhlbjogLS0+IHBp
cnE9MTkgLT4gaXJxPTYgKGdzaT02KQpbICAgIDEuNjk5ODQzXSBwbnAgMDA6MDU6IFtkbWEg
Ml0KWyAgICAxLjY5OTg1OF0gcG5wIDAwOjA1OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNl
LCBJRHMgUE5QMDcwMCAoYWN0aXZlKQpbICAgIDEuNjk5ODg5XSB4ZW46IC0tPiBwaXJxPTIw
IC0+IGlycT00IChnc2k9NCkKWyAgICAxLjY5OTkxM10gcG5wIDAwOjA2OiBQbHVnIGFuZCBQ
bGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDUwMSAoYWN0aXZlKQpbICAgIDEuNjk5OTc1XSBz
eXN0ZW0gMDA6MDc6IFtpbyAgMHhhZTAwLTB4YWUwZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAg
ICAxLjcwNzIxOV0gc3lzdGVtIDAwOjA3OiBbaW8gIDB4YjA0NC0weGIwNDddIGhhcyBiZWVu
IHJlc2VydmVkClsgICAgMS43MTQ1MDJdIHN5c3RlbSAwMDowNzogUGx1ZyBhbmQgUGxheSBB
Q1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAxLjcxNDg3Nl0gcG5wOiBQ
blAgQUNQSTogZm91bmQgOCBkZXZpY2VzClsgICAgMS43MjkyNDJdIHBjaV9idXMgMDAwMDow
MDogcmVzb3VyY2UgNCBbaW8gIDB4MDAwMC0weDBjZjddClsgICAgMS43MjkyNDVdIHBjaV9i
dXMgMDAwMDowMDogcmVzb3VyY2UgNSBbaW8gIDB4MGQwMC0weGZmZmZdClsgICAgMS43Mjky
NDddIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNiBbbWVtIDB4MDAwYTAwMDAtMHgwMDBi
ZmZmZl0KWyAgICAxLjcyOTI0OF0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA3IFttZW0g
MHhmMDAwMDAwMC0weGZiZmZmZmZmXQpbICAgIDEuNzI5MjcyXSBORVQ6IFJlZ2lzdGVyZWQg
cHJvdG9jb2wgZmFtaWx5IDIKWyAgICAxLjczNTM2NF0gVENQIGVzdGFibGlzaGVkIGhhc2gg
dGFibGUgZW50cmllczogODE5MiAob3JkZXI6IDQsIDY1NTM2IGJ5dGVzKQpbICAgIDEuNzQ0
MDQ0XSBUQ1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDgxOTIgKG9yZGVyOiA1LCAxMzEw
NzIgYnl0ZXMpClsgICAgMS43NTE5MzddIFRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJlZCAo
ZXN0YWJsaXNoZWQgODE5MiBiaW5kIDgxOTIpClsgICAgMS43NTk5MjJdIFRDUDogcmVubyBy
ZWdpc3RlcmVkClsgICAgMS43NjQ1MDRdIFVEUCBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMiAo
b3JkZXI6IDIsIDE2Mzg0IGJ5dGVzKQpbICAgIDEuNzcxODA3XSBVRFAtTGl0ZSBoYXNoIHRh
YmxlIGVudHJpZXM6IDUxMiAob3JkZXI6IDIsIDE2Mzg0IGJ5dGVzKQpbICAgIDEuNzgwMjU4
XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEKWyAgICAxLjc4NjA1OF0gcGNp
IDAwMDA6MDA6MDAuMDogTGltaXRpbmcgZGlyZWN0IFBDSS9QQ0kgdHJhbnNmZXJzClsgICAg
MS43OTMzMDldIHBjaSAwMDAwOjAwOjAxLjA6IFBJSVgzOiBFbmFibGluZyBQYXNzaXZlIFJl
bGVhc2UKWyAgICAxLjgwMDY3M10gcGNpIDAwMDA6MDA6MDEuMDogQWN0aXZhdGluZyBJU0Eg
RE1BIGhhbmcgd29ya2Fyb3VuZHMKWyAgICAxLjgwODg2MV0geGVuOiAtLT4gcGlycT0yMSAt
PiBpcnE9MjMgKGdzaT0yMykKWyAgICAxLjgxMjAwN10gcGNpIDAwMDA6MDA6MDMuMDogVmlk
ZW8gZGV2aWNlIHdpdGggc2hhZG93ZWQgUk9NClsgICAgMS44MTIzODldIHhlbjogLS0+IHBp
cnE9MzcgLT4gaXJxPTM2IChnc2k9MzYpClsgICAgMS44MTQ2OTNdIFBDSTogQ0xTIDAgYnl0
ZXMsIGRlZmF1bHQgNjQKWyAgICAxLjgxNDczMF0gVHJ5aW5nIHRvIHVucGFjayByb290ZnMg
aW1hZ2UgYXMgaW5pdHJhbWZzLi4uClsgICAgMS44NDU1NzBdIEZyZWVpbmcgaW5pdHJkIG1l
bW9yeTogMTg3MksgKGZmZmY4ODAwMzdjNDgwMDAgLSBmZmZmODgwMDM3ZTFjMDAwKQpbICAg
IDEuODU2MDQ1XSBTY2FubmluZyBmb3IgbG93IG1lbW9yeSBjb3JydXB0aW9uIGV2ZXJ5IDYw
IHNlY29uZHMKWyAgICAxLjg2NTk0Nl0gc2hhMV9zc3NlMzogTmVpdGhlciBBVlggbm9yIEFW
WDIgbm9yIFNTU0UzIGlzIGF2YWlsYWJsZS91c2FibGUuClsgICAgMS44NzQ2MjBdIEFWWCBv
ciBBRVMtTkkgaW5zdHJ1Y3Rpb25zIGFyZSBub3QgZGV0ZWN0ZWQuClsgICAgMS44ODEyODZd
IEFWWCBpbnN0cnVjdGlvbnMgYXJlIG5vdCBkZXRlY3RlZC4KWyAgICAxLjg4NzMzMl0gQVZY
IGluc3RydWN0aW9ucyBhcmUgbm90IGRldGVjdGVkLgpbICAgIDEuODkzMTcyXSBmdXRleCBo
YXNoIHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiA1LCAxMzEwNzIgYnl0ZXMpClsgICAg
MS45MDExMjldIGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0bGluayBzdWJzeXMgKGRpc2FibGVk
KQpbICAgIDEuOTA4MDAzXSBhdWRpdDogdHlwZT0yMDAwIGF1ZGl0KDE0MTYyNjE0ODkuMDk3
OjEpOiBpbml0aWFsaXplZApbICAgIDEuOTE1NTU3XSBIdWdlVExCIHJlZ2lzdGVyZWQgMiBN
QiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcwpbICAgIDEuOTI1MTE2XSBWRlM6
IERpc2sgcXVvdGFzIGRxdW90XzYuNS4yClsgICAgMS45MzA3NTJdIERxdW90LWNhY2hlIGhh
c2ggdGFibGUgZW50cmllczogNTEyIChvcmRlciAwLCA0MDk2IGJ5dGVzKQpbICAgIDEuOTM5
NDA0XSBudGZzOiBkcml2ZXIgMi4xLjMxIFtGbGFnczogUi9XXS4KWyAgICAxLjk0NTQyN10g
ZnVzZSBpbml0IChBUEkgdmVyc2lvbiA3LjIzKQpbICAgIDEuOTUxNzA1XSBnZnMyOiBHRlMy
IGluc3RhbGxlZApbICAgIDEuOTU2Mzk1XSBjZXBoOiBsb2FkZWQgKG1kcyBwcm90byAzMikK
WyAgICAxLjk2MTU0N10gbXNnbW5pIGhhcyBiZWVuIHNldCB0byAxOTU5ClsgICAgMS45Njky
MjFdIGJvdW5jZTogcG9vbCBzaXplOiA2NCBwYWdlcwpbICAgIDEuOTc0NjQ1XSBCbG9jayBs
YXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFq
b3IgMjUwKQpbICAgIDEuOTg0NzQwXSBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkClsg
ICAgMS45OTAzNjJdIGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdpc3RlcmVkClsgICAgMS45
OTY0NzldIGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVsdCkKWyAgICAyLjAw
MzA2N10gY3JjMzI6IENSQ19MRV9CSVRTID0gNjQsIENSQ19CRSBCSVRTID0gNjQKWyAgICAy
LjAwOTQ0NV0gY3JjMzI6IHNlbGYgdGVzdHMgcGFzc2VkLCBwcm9jZXNzZWQgMjI1OTQ0IGJ5
dGVzIGluIDEwOTI2NiBuc2VjClsgICAgMi4wMTgyMjBdIGNyYzMyYzogQ1JDX0xFX0JJVFMg
PSA2NApbICAgIDIuMDIzMTQ1XSBjcmMzMmM6IHNlbGYgdGVzdHMgcGFzc2VkLCBwcm9jZXNz
ZWQgMjI1OTQ0IGJ5dGVzIGluIDYxNTkzIG5zZWMKWyAgICAyLjA0MDc4Ml0gY3JjMzJfY29t
YmluZTogODM3MyBzZWxmIHRlc3RzIHBhc3NlZApbICAgIDIuMDU2MjY4XSBjcmMzMmNfY29t
YmluZTogODM3MyBzZWxmIHRlc3RzIHBhc3NlZApbICAgIDIuMDYyNzMyXSBwY2lfaG90cGx1
ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAuNQpbICAgIDIuMDY5Nzg5XSBw
Y2llaHA6IFBDSSBFeHByZXNzIEhvdCBQbHVnIENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246
IDAuNApbICAgIDIuMDc3NzUxXSBjcGNpaHBfenQ1NTUwOiBaVDU1NTAgQ29tcGFjdFBDSSBI
b3QgUGx1ZyBEcml2ZXIgdmVyc2lvbjogMC4yClsgICAgMi4wODU4NDFdIGNwY2locF9nZW5l
cmljOiBHZW5lcmljIHBvcnQgSS9PIENvbXBhY3RQQ0kgSG90IFBsdWcgRHJpdmVyIHZlcnNp
b246IDAuMQpbICAgIDIuMDk1MjcwXSBjcGNpaHBfZ2VuZXJpYzogbm90IGNvbmZpZ3VyZWQs
IGRpc2FibGluZy4KWyAgICAyLjEwMjIyNl0gc2hwY2hwOiBTdGFuZGFyZCBIb3QgUGx1ZyBQ
Q0kgQ29udHJvbGxlciBEcml2ZXIgdmVyc2lvbjogMC40ClsgICAgMi4xMTExMDVdIGFjcGlw
aHBfaWJtOiBpYm1fYWNwaXBocF9pbml0OiBhY3BpX3dhbGtfbmFtZXNwYWNlIGZhaWxlZApb
ICAgIDIuMTE5NTI4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVy
IHVkbGZiClsgICAgMi4xMjcwMzBdIGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2RldmljZXMv
TE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQwClsgICAgMi4xMzcxNDBdIEFD
UEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0KWyAgICAyLjE0MjE4M10gaW5wdXQ6IFNsZWVwIEJ1
dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhTTFBCTjowMC9pbnB1dC9pbnB1dDEK
WyAgICAyLjE1MjAyNV0gQUNQSTogU2xlZXAgQnV0dG9uIFtTTFBGXQpbICAgIDIuMTU3ODI1
XSB4ZW46eGVuX2V2dGNobjogRXZlbnQtY2hhbm5lbCBkZXZpY2UgaW5zdGFsbGVkClsgICAg
Mi4xNjUyNjJdIHhlbjogLS0+IHBpcnE9MjIgLT4gaXJxPTI0IChnc2k9MjQpClsgICAgMi4x
NjU0NTddIHhlbjpncmFudF90YWJsZTogR3JhbnQgdGFibGVzIHVzaW5nIHZlcnNpb24gMSBs
YXlvdXQKWyAgICAyLjE3Mjg4MF0gR3JhbnQgdGFibGUgaW5pdGlhbGl6ZWQKWyAgICAyLjE3
ODM3Nl0gU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcg
ZW5hYmxlZApbICAgIDIuMjI2MDMxXSBzZXJpYWwgMDA6MDY6IHR0eVMwIGF0IEkvTyAweDNm
OCAoaXJxID0gNCwgYmFzZV9iYXVkID0gMTE1MjAwKSBpcyBhIDE2NTUwQQpbICAgIDIuMjM3
MzI3XSBMaW51eCBhZ3BnYXJ0IGludGVyZmFjZSB2MC4xMDMKWyAgICAyLjI0MjkwNF0gSGFu
Z2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sgdGltZXIgMC45LjEgKHRpY2sgaXMgMTgwIHNl
Y29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRzKS4KWyAgICAyLjI1NDg4Nl0gW2RybV0gSW5p
dGlhbGl6ZWQgZHJtIDEuMS4wIDIwMDYwODEwClsgICAgMi4yNjExODhdIFtkcm1dIFZHQUNP
TiBkaXNhYmxlIHJhZGVvbiBrZXJuZWwgbW9kZXNldHRpbmcuClsgICAgMi4yNjg1NDNdIFtk
cm06cmFkZW9uX2luaXRdICpFUlJPUiogTm8gVU1TIHN1cHBvcnQgaW4gcmFkZW9uIG1vZHVs
ZSEKWyAgICAyLjI3ODAyM10gYnJkOiBtb2R1bGUgbG9hZGVkClsgICAgMi4yODM4MTJdIGxv
b3A6IG1vZHVsZSBsb2FkZWQKWyAgICAyLjI5NDUwN10gdHVuOiBVbml2ZXJzYWwgVFVOL1RB
UCBkZXZpY2UgZHJpdmVyLCAxLjYKWyAgICAyLjMwMTY1OV0gYmxrZnJvbnQ6IHh2ZGE6IGZs
dXNoIGRpc2tjYWNoZTogZW5hYmxlZDsgcGVyc2lzdGVudCBncmFudHM6IGVuYWJsZWQ7IGlu
ZGlyZWN0IGRlc2NyaXB0b3JzOiBlbmFibGVkOwpbICAgIDIuMzE4MzU1XSB0dW46IChDKSAx
OTk5LTIwMDQgTWF4IEtyYXNueWFuc2t5IDxtYXhrQHF1YWxjb21tLmNvbT4KWyAgICAyLjMy
MjQ1N10gIHh2ZGE6IHh2ZGExIHh2ZGEyClsgICAgMi4zMjQyMDJdIGJsa2Zyb250OiB4dmRi
OiBmbHVzaCBkaXNrY2FjaGU6IGVuYWJsZWQ7IHBlcnNpc3RlbnQgZ3JhbnRzOiBlbmFibGVk
OyBpbmRpcmVjdCBkZXNjcmlwdG9yczogZW5hYmxlZDsKWyAgICAyLjMzMzA3MV0gIHh2ZGI6
IHVua25vd24gcGFydGl0aW9uIHRhYmxlClsgICAgMi4zNTE4MzJdIGUxMDAwOiBJbnRlbChS
KSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gNy4zLjIxLWs4LU5BUEkKWyAg
ICAyLjM2MDc2OF0gZTEwMDA6IENvcHlyaWdodCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBv
cmF0aW9uLgpbICAgIDIuMzY4MDA0XSBlMTAwMGU6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdv
cmsgRHJpdmVyIC0gMi4zLjItawpbICAgIDIuMzc1NzQ2XSBlMTAwMGU6IENvcHlyaWdodChj
KSAxOTk5IC0gMjAxNCBJbnRlbCBDb3Jwb3JhdGlvbi4KWyAgICAyLjM4MzkwMV0gaWdiOiBJ
bnRlbChSKSBHaWdhYml0IEV0aGVybmV0IE5ldHdvcmsgRHJpdmVyIC0gdmVyc2lvbiA1LjIu
MTUtawpbICAgIDIuMzkzNjg1XSBpZ2I6IENvcHlyaWdodCAoYykgMjAwNy0yMDE0IEludGVs
IENvcnBvcmF0aW9uLgpbICAgIDIuNDAwOTc1XSBpZ2J2ZjogSW50ZWwoUikgR2lnYWJpdCBW
aXJ0dWFsIEZ1bmN0aW9uIE5ldHdvcmsgRHJpdmVyIC0gdmVyc2lvbiAyLjAuMi1rClsgICAg
Mi40MTEyNDddIGlnYnZmOiBDb3B5cmlnaHQgKGMpIDIwMDkgLSAyMDEyIEludGVsIENvcnBv
cmF0aW9uLgpbICAgIDIuNDE4NzkzXSB4ZW5fbmV0ZnJvbnQ6IEluaXRpYWxpc2luZyBYZW4g
dmlydHVhbCBldGhlcm5ldCBkcml2ZXIKWyAgICAyLjQzMTA2Ml0geGhjaV9oY2QgMDAwMDow
MDowNS4wOiB4SENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDIuNDM5NDIwXSB4aGNpX2hjZCAw
MDAwOjAwOjA1LjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1i
ZXIgMQpbICAgIDIuNDU2MDM4XSB1c2IgdXNiMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlk
VmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyClsgICAgMi40NjQ3MTddIHVzYiB1c2IxOiBO
ZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9
MQpbICAgIDIuNDczODg4XSB1c2IgdXNiMTogUHJvZHVjdDogeEhDSSBIb3N0IENvbnRyb2xs
ZXIKWyAgICAyLjQ4MDM5N10gdXNiIHVzYjE6IE1hbnVmYWN0dXJlcjogTGludXggMy4xOC4w
LXJjNC0yMDE0MTExNi1zZWN1cml0eSsgeGhjaS1oY2QKWyAgICAyLjQ4OTgxOF0gdXNiIHVz
YjE6IFNlcmlhbE51bWJlcjogMDAwMDowMDowNS4wClsgICAgMi40OTYyMzldIGh1YiAxLTA6
MS4wOiBVU0IgaHViIGZvdW5kClsgICAgMi41MDE2MzNdIGh1YiAxLTA6MS4wOiAyIHBvcnRz
IGRldGVjdGVkClsgICAgMi41MDcwMDhdIHhoY2lfaGNkIDAwMDA6MDA6MDUuMDogeEhDSSBI
b3N0IENvbnRyb2xsZXIKWyAgICAyLjUxMzc5MV0geGhjaV9oY2QgMDAwMDowMDowNS4wOiBu
ZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDIKWyAgICAyLjUy
NTAwMF0gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBp
ZFByb2R1Y3Q9MDAwMwpbICAgIDIuNTM0MjA0XSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2Ug
c3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKWyAgICAyLjU0MzM0
MF0gdXNiIHVzYjI6IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyClsgICAgMi41NTAx
NDBdIHVzYiB1c2IyOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMTguMC1yYzQtMjAxNDExMTYt
c2VjdXJpdHkrIHhoY2ktaGNkClsgICAgMi41NTk4MzRdIHVzYiB1c2IyOiBTZXJpYWxOdW1i
ZXI6IDAwMDA6MDA6MDUuMApbICAgIDIuNTY2MDA2XSBodWIgMi0wOjEuMDogVVNCIGh1YiBm
b3VuZApbICAgIDIuNTcxMjcxXSBodWIgMi0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApbICAg
IDIuNTc3MDMzXSBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxl
ciAoRUhDSSkgRHJpdmVyClsgICAgMi41ODUyMzRdIGVoY2ktcGNpOiBFSENJIFBDSSBwbGF0
Zm9ybSBkcml2ZXIKWyAgICAyLjU5MTE5NF0gb2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhv
c3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVyClsgICAgMi41OTg4MzFdIG9oY2ktcGNpOiBP
SENJIFBDSSBwbGF0Zm9ybSBkcml2ZXIKWyAgICAyLjYwNDY4OV0gdWhjaV9oY2Q6IFVTQiBV
bml2ZXJzYWwgSG9zdCBDb250cm9sbGVyIEludGVyZmFjZSBkcml2ZXIKWyAgICAyLjYxNTc0
N10gdWhjaV9oY2QgMDAwMDowMDowMS4yOiBVSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDIu
NjIyMzg3XSB1aGNpX2hjZCAwMDAwOjAwOjAxLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs
IGFzc2lnbmVkIGJ1cyBudW1iZXIgMwpbICAgIDIuNjMzMDMzXSB1aGNpX2hjZCAwMDAwOjAw
OjAxLjI6IGlycSAyMywgaW8gYmFzZSAweDAwMDBjMTQwClsgICAgMi42NDA4NDBdIHVzYiB1
c2IzOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAw
MDEKWyAgICAyLjY1MTUyMV0gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xClsgICAgMi42NjA3NjZdIHVzYiB1c2Iz
OiBQcm9kdWN0OiBVSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDIuNjY3MjMxXSB1c2IgdXNi
MzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjE4LjAtcmM0LTIwMTQxMTE2LXNlY3VyaXR5KyB1
aGNpX2hjZApbICAgIDIuNjc2NzQ4XSB1c2IgdXNiMzogU2VyaWFsTnVtYmVyOiAwMDAwOjAw
OjAxLjIKWyAgICAyLjY4MzM2NV0gaHViIDMtMDoxLjA6IFVTQiBodWIgZm91bmQKWyAgICAy
LjY4ODc5MV0gaHViIDMtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKWyAgICAyLjY5NDk1MV0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JscApbICAgIDIu
NzAyNTU0XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1z
dG9yYWdlClsgICAgMi43MTA4NDFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFj
ZSBkcml2ZXIgdXNic2VyaWFsClsgICAgMi43MTg0NDddIHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGludGVyZmFjZSBkcml2ZXIgY3AyMTB4ClsgICAgMi43MjU4NzddIHVzYnNlcmlhbDog
VVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIGNwMjEweApbICAgIDIuNzMzNzQ5
XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGN5cHJlc3NfbTgK
WyAgICAyLjc0MTQzMF0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJl
ZCBmb3IgRGVMb3JtZSBFYXJ0aG1hdGUgVVNCClsgICAgMi43NTExNzJdIHVzYnNlcmlhbDog
VVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIEhJRC0+Q09NIFJTMjMyIEFkYXB0
ZXIKWyAgICAyLjc2MTIxNV0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0
ZXJlZCBmb3IgTm9raWEgQ0EtNDIgVjIgQWRhcHRlcgpbICAgIDIuNzcxMTg4XSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc3MjAKWyAgICAyLjc3ODk4
OV0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hp
cCAyIHBvcnQgYWRhcHRlcgpbICAgIDIuNzg4NzYwXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5l
dyBpbnRlcmZhY2UgZHJpdmVyIG1vczc4NDAKWyAgICAyLjc5NjM5M10gdXNic2VyaWFsOiBV
U0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCA3ODQwLzc4MjAgVVNC
IFNlcmlhbCBEcml2ZXIKWyAgICAyLjgwNzc1NV0gaTgwNDI6IFBOUDogUFMvMiBDb250cm9s
bGVyIFtQTlAwMzAzOlBTMkssUE5QMGYxMzpQUzJNXSBhdCAweDYwLDB4NjQgaXJxIDEsMTIK
WyAgICAyLjgyMjA3OV0gc2VyaW86IGk4MDQyIEtCRCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEg
MQpbICAgIDIuODIzNTE3XSB1c2IgMS0yOiBuZXcgbG93LXNwZWVkIFVTQiBkZXZpY2UgbnVt
YmVyIDIgdXNpbmcgeGhjaV9oY2QKWyAgICAyLjgzNzcyNF0gc2VyaW86IGk4MDQyIEFVWCBw
b3J0IGF0IDB4NjAsMHg2NCBpcnEgMTIKWyAgICAyLjg0NDg5NV0gbW91c2VkZXY6IFBTLzIg
bW91c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UKWyAgICAyLjg1Mzk1NF0gaW5wdXQ6
IEFUIFRyYW5zbGF0ZWQgU2V0IDIga2V5Ym9hcmQgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgw
NDIvc2VyaW8wL2lucHV0L2lucHV0MgpbICAgIDIuODY2MTY3XSBpbnB1dDogWGVuIFZpcnR1
YWwgS2V5Ym9hcmQgYXMgL2RldmljZXMvdmlydHVhbC9pbnB1dC9pbnB1dDUKWyAgICAyLjg4
MjAzOV0gaW5wdXQ6IFhlbiBWaXJ0dWFsIFBvaW50ZXIgYXMgL2RldmljZXMvdmlydHVhbC9p
bnB1dC9pbnB1dDYKWyAgICAyLjg5NDcxN10gcmFuZG9tOiBub25ibG9ja2luZyBwb29sIGlz
IGluaXRpYWxpemVkClsgICAgMi45MDMxOTZdIHJ0Y19jbW9zIDAwOjAyOiBydGMgY29yZTog
cmVnaXN0ZXJlZCBydGNfY21vcyBhcyBydGMwClsgICAgMi45MTIyODhdIHJ0Y19jbW9zIDAw
OjAyOiBhbGFybXMgdXAgdG8gb25lIGRheSwgMTE0IGJ5dGVzIG52cmFtLCBocGV0IGlycXMK
WyAgICAyLjkyMTg1N10gcGlpeDRfc21idXMgMDAwMDowMDowMS4zOiBTTUJ1cyBIb3N0IENv
bnRyb2xsZXIgbm90IGVuYWJsZWQhClsgICAgMi45MzExMjNdIGxpcmNfZGV2OiBJUiBSZW1v
dGUgQ29udHJvbCBkcml2ZXIgcmVnaXN0ZXJlZCwgbWFqb3IgMjQ4IApbICAgIDIuOTM5NDI3
XSBJUiBORUMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDIuOTQ1NTk4XSBJ
UiBSQzUoeC9zeikgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDIuOTUyNTU3
XSBJUiBSQzYgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDIuOTU4Njk5XSBJ
UiBKVkMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDIuOTY1MjEwXSBJUiBT
b255IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQKWyAgICAyLjk3MjAzNF0gSVIgU0FO
WU8gcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDIuOTc4OTM5XSBJUiBTaGFy
cCBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkClsgICAgMi45ODU5MjhdIElSIE1DRSBL
ZXlib2FyZC9tb3VzZSBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkClsgICAgMi45OTM4
ODZdIElSIExJUkMgYnJpZGdlIGhhbmRsZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjAwMDgyOF0g
SVIgWE1QIHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjAwMjE1NV0gdXNi
IDEtMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTEwY2YsIGlkUHJvZHVjdD01
NTAwClsgICAgMy4wMDIxNTZdIHVzYiAxLTI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0xLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wClsgICAgMy4wMDIxNTddIHVzYiAxLTI6
IFByb2R1Y3Q6IFVTQiBLODA1NQpbICAgIDMuMDAyMTU4XSB1c2IgMS0yOiBNYW51ZmFjdHVy
ZXI6IFZlbGxlbWFuIApbICAgIDMuMDAyMjg2XSB1c2IgMS0yOiBlcCAweDgxIC0gcm91bmRp
bmcgaW50ZXJ2YWwgdG8gNjQgbWljcm9mcmFtZXMsIGVwIGRlc2Mgc2F5cyA4MCBtaWNyb2Zy
YW1lcwpbICAgIDMuMDAyMjkwXSB1c2IgMS0yOiBlcCAweDEgLSByb3VuZGluZyBpbnRlcnZh
bCB0byA2NCBtaWNyb2ZyYW1lcywgZXAgZGVzYyBzYXlzIDgwIG1pY3JvZnJhbWVzClsgICAg
My4wMTY4NDVdIHVzYiAzLTE6IG5ldyBmdWxsLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIg
dXNpbmcgdWhjaV9oY2QKWyAgICAzLjA3MjkzMF0gY3gyNTgyMTogZHJpdmVyIHZlcnNpb24g
MC4wLjEwNiBsb2FkZWQKWyAgICAzLjA4MDM0OF0geGVuOiAtLT4gcGlycT00NyAtPiBpcnE9
NDAgKGdzaT00MCkKWyAgICAzLjA4MDU1M10gY3gyNTgyMTogQXRoZW5hIEhhcmR3YXJlIGRl
dmljZSA9IDB4ODIxMApbICAgIDMuMDg3NzE5XSBjeDI1ODIxOiBjeDI1ODIxWzFdOiBzdWJz
eXN0ZW06IDAwMDA6MDAwMCwgYm9hcmQ6IENYMjU4MjEgW2NhcmQ9MSxhdXRvZGV0ZWN0ZWRd
ClsgICAgMy4xNDg0NzldIHVzYiAzLTE6IG5vdCBydW5uaW5nIGF0IHRvcCBzcGVlZDsgY29u
bmVjdCB0byBhIGhpZ2ggc3BlZWQgaHViClsgICAgMy4xODc2NTVdIHVzYiAzLTE6IE5ldyBV
U0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0wNjI3LCBpZFByb2R1Y3Q9MDAwMQpbICAgIDMu
MTk3NTM4XSB1c2IgMy0xOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVj
dD0zLCBTZXJpYWxOdW1iZXI9NQpbICAgIDMuMjA3NDg1XSB1c2IgMy0xOiBQcm9kdWN0OiBR
RU1VIFVTQiBUYWJsZXQKWyAgICAzLjIxNDE0NV0gdXNiIDMtMTogTWFudWZhY3R1cmVyOiBR
RU1VClsgICAgMy4yMjAzMTldIHVzYiAzLTE6IFNlcmlhbE51bWJlcjogNDIKWyAgICAzLjM4
NDI5Nl0gY3gyNTgyMTogSGFyZHdhcmUgcmV2aXNpb24gPSAweDAwClsgICAgMy4zOTA0ODdd
IGN4MjU4MjE6IGN4MjU4MjFbMV0vMDogZm91bmQgYXQgMDAwMDowMDowNi4wLCByZXY6IDAs
IGlycTogNDAsIGxhdGVuY3k6IDAsIG1taW86IDB4ZjMwMDAwMDAKWyAgICAzLjQwMjgyN10g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBwdnJ1c2IyClsgICAg
My40MTA1MTNdIHB2cnVzYjI6IFY0TCBpbi10cmVlIHZlcnNpb246SGF1cHBhdWdlIFdpblRW
LVBWUi1VU0IyIE1QRUcyIEVuY29kZXIvVHVuZXIKWyAgICAzLjQyMTA5OV0gcHZydXNiMjog
RGVidWcgbWFzayBpcyAzMSAoMHgxZikKWyAgICAzLjQyODU3OF0gc3A1MTAwX3RjbzogU1A1
MTAwL1NCODAwIFRDTyBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDUKWyAgICAzLjQzNzE1
MV0gZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuMjguMC1pb2N0bCAoMjAxNC0wOS0xNykgaW5p
dGlhbGlzZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20KWyAgICAzLjQ0ODEyOF0gQmx1ZXRvb3Ro
OiBWaXJ0dWFsIEhDSSBkcml2ZXIgdmVyIDEuNQpbICAgIDMuNDU0NjQ3XSBCbHVldG9vdGg6
IEhDSSBVQVJUIGRyaXZlciB2ZXIgMi4yClsgICAgMy40NjExNjRdIEJsdWV0b290aDogSENJ
IEg0IHByb3RvY29sIGluaXRpYWxpemVkClsgICAgMy40Njg4NjVdIEJsdWV0b290aDogSENJ
IEJDU1AgcHJvdG9jb2wgaW5pdGlhbGl6ZWQKWyAgICAzLjQ3NzAxNl0gQmx1ZXRvb3RoOiBI
Q0lMTCBwcm90b2NvbCBpbml0aWFsaXplZApbICAgIDMuNDg1MTcwXSBCbHVldG9vdGg6IEhD
SUFUSDNLIHByb3RvY29sIGluaXRpYWxpemVkClsgICAgMy40OTM0MzNdIEJsdWV0b290aDog
SENJIFRocmVlLXdpcmUgVUFSVCAoSDUpIHByb3RvY29sIGluaXRpYWxpemVkClsgICAgMy41
MDY4ODNdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgYmNtMjAz
eApbICAgIDMuNTEzNDM4XSBpbnB1dDogSW1FeFBTLzIgR2VuZXJpYyBFeHBsb3JlciBNb3Vz
ZSBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzEvaW5wdXQvaW5wdXQ0ClsgICAg
My41Mjk5ODNdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgYnBh
MTB4ClsgICAgMy41Mzc3MTldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk
cml2ZXIgYmZ1c2IKWyAgICAzLjU0NTE3Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50
ZXJmYWNlIGRyaXZlciBidHVzYgpbICAgIDMuNTUyNTMwXSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIGF0aDNrClsgICAgMy41NTk4ODhdIGhpZHJhdzogcmF3
IEhJRCBldmVudHMgZHJpdmVyIChDKSBKaXJpIEtvc2luYQpbICAgIDMuNTcyOTI4XSBpbnB1
dDogUUVNVSBRRU1VIFVTQiBUYWJsZXQgYXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAw
OjAxLjIvdXNiMy8zLTEvMy0xOjEuMC8wMDAzOjA2Mjc6MDAwMS4wMDAxL2lucHV0L2lucHV0
NwpbICAgIDMuNTg3NjI4XSBoaWQtZ2VuZXJpYyAwMDAzOjA2Mjc6MDAwMS4wMDAxOiBpbnB1
dCxoaWRyYXcwOiBVU0IgSElEIHYwLjAxIFBvaW50ZXIgW1FFTVUgUUVNVSBVU0IgVGFibGV0
XSBvbiB1c2ItMDAwMDowMDowMS4yLTEvaW5wdXQwClsgICAgMy42MDI1NzVdIHVzYmNvcmU6
IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiaGlkClsgICAgMy42MTAyNjFd
IHVzYmhpZDogVVNCIEhJRCBjb3JlIGRyaXZlcgpbICAgIDMuNjE2Mzg0XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItYXVkaW8KWyAgICAzLjYy
NDUzOV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdWEx
MDEKWyAgICAzLjYzMjU5NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRy
aXZlciBzbmQtdXNiLXVzeDJ5ClsgICAgMy42NDA3MDddIHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi1jYWlhcQpbICAgIDMuNjQ5MDY3XSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItNmZpcmUKWyAg
ICAzLjY1NzI1Nl0gTmV0ZmlsdGVyIG1lc3NhZ2VzIHZpYSBORVRMSU5LIHYwLjMwLgpbICAg
IDMuNjYzNzI4XSBuZm5sX2FjY3Q6IHJlZ2lzdGVyaW5nIHdpdGggbmZuZXRsaW5rLgpbICAg
IDMuNjcwMTY3XSBuZl9jb25udHJhY2sgdmVyc2lvbiAwLjUuMCAoNzgzNiBidWNrZXRzLCAz
MTM0NCBtYXgpClsgICAgMy42NzgxNzBdIGN0bmV0bGluayB2MC45MzogcmVnaXN0ZXJpbmcg
d2l0aCBuZm5ldGxpbmsuClsgICAgMy42ODU3NTRdIHh0X3RpbWU6IGtlcm5lbCB0aW1lem9u
ZSBpcyAtMDAwMApbICAgIDMuNjkxOTQ5XSBpcF9zZXQ6IHByb3RvY29sIDYKWyAgICAzLjY5
NjcyMF0gSVBWUzogUmVnaXN0ZXJlZCBwcm90b2NvbHMgKCkKWyAgICAzLjcwMjMxMF0gSVBW
UzogQ29ubmVjdGlvbiBoYXNoIHRhYmxlIGNvbmZpZ3VyZWQgKHNpemU9NDA5NiwgbWVtb3J5
PTY0S2J5dGVzKQpbICAgIDMuNzExNjgyXSBJUFZTOiBDcmVhdGluZyBuZXRucyBzaXplPTEy
MTYgaWQ9MApbICAgIDMuNzE4NTk1XSBJUFZTOiBpcHZzIGxvYWRlZC4KWyAgICAzLjcyMzc3
OF0gaXBfdGFibGVzOiAoQykgMjAwMC0yMDA2IE5ldGZpbHRlciBDb3JlIFRlYW0KWyAgICAz
LjczMTE0Nl0gVENQOiBjdWJpYyByZWdpc3RlcmVkClsgICAgMy43MzYwMTNdIE5FVDogUmVn
aXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcKWyAgICAzLjc0MTkzNl0gYnJpZGdlOiBhdXRv
bWF0aWMgZmlsdGVyaW5nIHZpYSBhcnAvaXAvaXA2dGFibGVzIGhhcyBiZWVuIGRlcHJlY2F0
ZWQuIFVwZGF0ZSB5b3VyIHNjcmlwdHMgdG8gbG9hZCBicl9uZXRmaWx0ZXIgaWYgeW91IG5l
ZWQgdGhpcy4KWyAgICAzLjc1NzQyNl0gQnJpZGdlIGZpcmV3YWxsaW5nIHJlZ2lzdGVyZWQK
WyAgICAzLjc2MzE1NF0gRWJ0YWJsZXMgdjIuMCByZWdpc3RlcmVkClsgICAgMy43Njg2MDJd
IEJsdWV0b290aDogUkZDT01NIFRUWSBsYXllciBpbml0aWFsaXplZApbICAgIDMuNzc1MzAy
XSBCbHVldG9vdGg6IFJGQ09NTSBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjc4
MjMzNF0gQmx1ZXRvb3RoOiBSRkNPTU0gdmVyIDEuMTEKWyAgICAzLjc4NzcxM10gQmx1ZXRv
b3RoOiBCTkVQIChFdGhlcm5ldCBFbXVsYXRpb24pIHZlciAxLjMKWyAgICAzLjc5NDg5MF0g
Qmx1ZXRvb3RoOiBCTkVQIGZpbHRlcnM6IHByb3RvY29sIG11bHRpY2FzdApbICAgIDMuODAx
ODkyXSBCbHVldG9vdGg6IEJORVAgc29ja2V0IGxheWVyIGluaXRpYWxpemVkClsgICAgMy44
MDg1MTBdIEJsdWV0b290aDogSElEUCAoSHVtYW4gSW50ZXJmYWNlIEVtdWxhdGlvbikgdmVy
IDEuMgpbICAgIDMuODE2NTU2XSBCbHVldG9vdGg6IEhJRFAgc29ja2V0IGxheWVyIGluaXRp
YWxpemVkClsgICAgMy44MjI5OTVdIEtleSB0eXBlIGNlcGggcmVnaXN0ZXJlZApbICAgIDMu
ODI4NDU1XSBsaWJjZXBoOiBsb2FkZWQgKG1vbi9vc2QgcHJvdG8gMTUvMjQpClsgICAgMy44
MzU2OTBdIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24gMQpbICAgIDMuODQxOTE4XSBC
dHJmcyBsb2FkZWQKWyAgICAzLjg0OTEwMl0geGVuYnVzX3Byb2JlX2Zyb250ZW5kOiBEZXZp
Y2Ugd2l0aCBubyBkcml2ZXI6IGRldmljZS9wY2kvMApbICAgIDMuODU3NTYyXSBjb25zb2xl
IFtuZXRjb24wXSBlbmFibGVkClsgICAgMy44NjI4MTBdIG5ldGNvbnNvbGU6IG5ldHdvcmsg
bG9nZ2luZyBzdGFydGVkClsgICAgMy44NjkxNDldIHJ0Y19jbW9zIDAwOjAyOiBzZXR0aW5n
IHN5c3RlbSBjbG9jayB0byAyMDE0LTExLTE3IDIxOjU4OjExIFVUQyAoMTQxNjI2MTQ5MSkK
WyAgICAzLjg3OTc0N10gY3gyNTgyMV9hbHNhOiBjeDI1ODIxLzA6IEFMU0Egc3VwcG9ydCBm
b3IgY3gyNTgyMSBib2FyZHMKWyAgICAzLjg4ODM2Ml0gQUxTQSBkZXZpY2UgbGlzdDoKWyAg
ICAzLjg5MzA4NV0gICAjMDogY3gyNTgyMVsxXSBhdCAweGYzMDAwMDAwIGlycSA0MApbICAg
IDMuOTAxODAzXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAxMDQ4SyAoZmZmZmZm
ZmY4MjBkZjAwMCAtIGZmZmZmZmZmODIxZTUwMDApClsgICAgMy45MTI1MDBdIFdyaXRlIHBy
b3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogMTYzODRrClsgICAgMy45MjM2
MTVdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEzMzZLIChmZmZmODgwMDAxYWIy
MDAwIC0gZmZmZjg4MDAwMWMwMDAwMCkKWyAgICAzLjkzNTU3NV0gRnJlZWluZyB1bnVzZWQg
a2VybmVsIG1lbW9yeTogNTk2SyAoZmZmZjg4MDAwMWY2YjAwMCAtIGZmZmY4ODAwMDIwMDAw
MDApClsgICAgMy45NjEwNzVdIHVkZXZkWzE0NzBdOiBzdGFydGluZyB2ZXJzaW9uIDE3NQpb
ICAgIDQuMzE1Njg5XSBFWFQ0LWZzICh4dmRhMSk6IElORk86IHJlY292ZXJ5IHJlcXVpcmVk
IG9uIHJlYWRvbmx5IGZpbGVzeXN0ZW0KWyAgICA0LjMyNDM5Nl0gRVhUNC1mcyAoeHZkYTEp
OiB3cml0ZSBhY2Nlc3Mgd2lsbCBiZSBlbmFibGVkIGR1cmluZyByZWNvdmVyeQpbICAgIDQu
NDkwMzQzXSBFWFQ0LWZzICh4dmRhMSk6IHJlY292ZXJ5IGNvbXBsZXRlClsgICAgNC41MDY4
NjZdIEVYVDQtZnMgKHh2ZGExKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBk
YXRhIG1vZGUuIE9wdHM6IChudWxsKQpbICAgIDUuNDM3MTY0XSB1ZGV2ZFsxOTYwXTogc3Rh
cnRpbmcgdmVyc2lvbiAxNzUKWyAgICA5LjQ4NzEzN10gQWRkaW5nIDc2OTAyMGsgc3dhcCBv
biAvZGV2L3h2ZGEyLiAgUHJpb3JpdHk6LTEgZXh0ZW50czoxIGFjcm9zczo3NjkwMjBrIFNT
ClsgICAgOS41MjIwMzZdIEVYVDQtZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0czogKG51
bGwpClsgICAgOS42OTQ4NDddIEVYVDQtZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0czog
ZXJyb3JzPXJlbW91bnQtcm8KWyAgIDEwLjQ2NDg4MV0gRVhUNC1mcyAoeHZkYik6IG1vdW50
ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBlcnJvcnM9cmVt
b3VudC1ybwo=
------------0C90EA036019900CC
Content-Type: text/plain;
 name="lspci-guest.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-guest.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEludGVsIENvcnBvcmF0aW9uIDQ0MEZYIC0g
ODI0NDFGWCBQTUMgW05hdG9tYV0gWzgwODY6MTIzN10gKHJldiAwMikKCVN1YnN5c3RlbTog
UmVkIEhhdCwgSW5jIFFlbXUgdmlydHVhbCBtYWNoaW5lIFsxYWY0OjExMDBdCglDb250cm9s
OiBJL08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQ
YXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXAt
IDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoKMDA6MDEu
MCBJU0EgYnJpZGdlIFswNjAxXTogSW50ZWwgQ29ycG9yYXRpb24gODIzNzFTQiBQSUlYMyBJ
U0EgW05hdG9tYS9Ucml0b24gSUldIFs4MDg2OjcwMDBdCglTdWJzeXN0ZW06IFJlZCBIYXQs
IEluYyBRZW11IHZpcnR1YWwgbWFjaGluZSBbMWFmNDoxMTAwXQoJUGh5c2ljYWwgU2xvdDog
MQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0
YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0g
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5j
eTogMAoKMDA6MDEuMSBJREUgaW50ZXJmYWNlIFswMTAxXTogSW50ZWwgQ29ycG9yYXRpb24g
ODIzNzFTQiBQSUlYMyBJREUgW05hdG9tYS9Ucml0b24gSUldIFs4MDg2OjcwMTBdIChwcm9n
LWlmIDgwIFtNYXN0ZXJdKQoJU3Vic3lzdGVtOiBSZWQgSGF0LCBJbmMgUWVtdSB2aXJ0dWFs
IG1hY2hpbmUgWzFhZjQ6MTEwMF0KCVBoeXNpY2FsIFNsb3Q6IDEKCUNvbnRyb2w6IEkvTysg
TWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0g
U3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcC0gNjZNSHot
IFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQt
IDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAKCVJlZ2lvbiAwOiBb
dmlydHVhbF0gTWVtb3J5IGF0IDAwMDAwMWYwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUp
IFtzaXplPThdCglSZWdpb24gMTogW3ZpcnR1YWxdIE1lbW9yeSBhdCAwMDAwMDNmMCAodHlw
ZSAzLCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xXQoJUmVnaW9uIDI6IFt2aXJ0dWFsXSBN
ZW1vcnkgYXQgMDAwMDAxNzAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9OF0K
CVJlZ2lvbiAzOiBbdmlydHVhbF0gTWVtb3J5IGF0IDAwMDAwMzcwICh0eXBlIDMsIG5vbi1w
cmVmZXRjaGFibGUpIFtzaXplPTFdCglSZWdpb24gNDogSS9PIHBvcnRzIGF0IGMxNjAgW3Np
emU9MTZdCgowMDowMS4yIFVTQiBjb250cm9sbGVyIFswYzAzXTogSW50ZWwgQ29ycG9yYXRp
b24gODIzNzFTQiBQSUlYMyBVU0IgW05hdG9tYS9Ucml0b24gSUldIFs4MDg2OjcwMjBdIChy
ZXYgMDEpIChwcm9nLWlmIDAwIFtVSENJXSkKCVN1YnN5c3RlbTogUmVkIEhhdCwgSW5jIFFl
bXUgdmlydHVhbCBtYWNoaW5lIFsxYWY0OjExMDBdCglQaHlzaWNhbCBTbG90OiAxCglDb250
cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBD
YXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0g
PFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoJSW50
ZXJydXB0OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDIzCglSZWdpb24gNDogSS9PIHBvcnRzIGF0
IGMxNDAgW3NpemU9MzJdCglLZXJuZWwgZHJpdmVyIGluIHVzZTogdWhjaV9oY2QKCjAwOjAx
LjMgQnJpZGdlIFswNjgwXTogSW50ZWwgQ29ycG9yYXRpb24gODIzNzFBQi9FQi9NQiBQSUlY
NCBBQ1BJIFs4MDg2OjcxMTNdIChyZXYgMDMpCglTdWJzeXN0ZW06IFJlZCBIYXQsIEluYyBR
ZW11IHZpcnR1YWwgbWFjaGluZSBbMWFmNDoxMTAwXQoJUGh5c2ljYWwgU2xvdDogMQoJQ29u
dHJvbDogSS9PLSBNZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9v
cC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czog
Q2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoJ
SW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDkKCjAwOjAyLjAgVW5hc3NpZ25lZCBj
bGFzcyBbZmY4MF06IFhlblNvdXJjZSwgSW5jLiBYZW4gUGxhdGZvcm0gRGV2aWNlIFs1ODUz
OjAwMDFdIChyZXYgMDEpCglTdWJzeXN0ZW06IFhlblNvdXJjZSwgSW5jLiBYZW4gUGxhdGZv
cm0gRGV2aWNlIFs1ODUzOjAwMDFdCglQaHlzaWNhbCBTbG90OiAyCglDb250cm9sOiBJL08r
IE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnIt
IFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXAtIDY2TUh6
LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoJSW50ZXJydXB0OiBw
aW4gQSByb3V0ZWQgdG8gSVJRIDI0CglSZWdpb24gMDogSS9PIHBvcnRzIGF0IGMwMDAgW3Np
emU9MjU2XQoJUmVnaW9uIDE6IE1lbW9yeSBhdCBmMjAwMDAwMCAoMzItYml0LCBwcmVmZXRj
aGFibGUpIFtzaXplPTE2TV0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiB4ZW4tcGxhdGZvcm0t
cGNpCgowMDowMy4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXIgWzAzMDBdOiBDaXJydXMg
TG9naWMgR0QgNTQ0NiBbMTAxMzowMGI4XSAocHJvZy1pZiAwMCBbVkdBIGNvbnRyb2xsZXJd
KQoJU3Vic3lzdGVtOiBSZWQgSGF0LCBJbmMgRGV2aWNlIFsxYWY0OjExMDBdCglQaHlzaWNh
bCBTbG90OiAzCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1l
bVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJ
TlR4LQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJ
TGF0ZW5jeTogMAoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmMDAwMDAwMCAoMzItYml0LCBwcmVm
ZXRjaGFibGUpIFtzaXplPTMyTV0KCVJlZ2lvbiAxOiBNZW1vcnkgYXQgZjMyNzIwMDAgKDMy
LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdCglFeHBhbnNpb24gUk9NIGF0IGYz
MjYwMDAwIFtkaXNhYmxlZF0gW3NpemU9NjRLXQoKMDA6MDUuMCBVU0IgY29udHJvbGxlciBb
MGMwM106IE5FQyBDb3Jwb3JhdGlvbiB1UEQ3MjAyMDAgVVNCIDMuMCBIb3N0IENvbnRyb2xs
ZXIgWzEwMzM6MDE5NF0gKHJldiAwMykgKHByb2ctaWYgMzAgW1hIQ0ldKQoJU3Vic3lzdGVt
OiBBU1VTVGVLIENvbXB1dGVyIEluYy4gUDhQNjcgRGVsdXhlIE1vdGhlcmJvYXJkIFsxMDQz
Ojg0MTNdCglQaHlzaWNhbCBTbG90OiA1CglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
LSBGYXN0QjJCLSBEaXNJTlR4KwoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkIt
IFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt
IDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJ
SW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDM2CglSZWdpb24gMDogTWVtb3J5IGF0
IGYzMjcwMDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPThLXQoJQ2FwYWJp
bGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0s
RDNjb2xkLSkKCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERT
Y2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzcwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8x
IE1hc2thYmxlLSA2NGJpdCsKCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAw
MDAwCglDYXBhYmlsaXRpZXM6IFs5MF0gTVNJLVg6IEVuYWJsZSsgQ291bnQ9OCBNYXNrZWQt
CgkJVmVjdG9yIHRhYmxlOiBCQVI9MCBvZmZzZXQ9MDAwMDEwMDAKCQlQQkE6IEJBUj0wIG9m
ZnNldD0wMDAwMTA4MAoJQ2FwYWJpbGl0aWVzOiBbYTBdIEV4cHJlc3MgKHYyKSBFbmRwb2lu
dCwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAs
IExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkCgkJCUV4dFRhZy0gQXR0bkJ0
bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJy
b3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJCVJs
eGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBheWxv
YWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcwoJCURldlN0YToJQ29yckVyci0g
VW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0KCQlM
bmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDR1cywgTDEgdW5saW1pdGVkCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFj
dFJlcC0gQndOb3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlz
YWJsZWQtIFJldHJhaW4tIENvbW1DbGstCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWRE
aXMtIEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDVHVC9zLCBXaWR0aCB4MSwg
VHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURl
dkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91dERpcysK
CQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERp
cy0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtNmRCCgkJCSBUcmFuc21p
dCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlh
bmNlLSBDb21wbGlhbmNlU09TLQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQgoJ
CUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEIsIEVxdWFsaXphdGlv
bkNvbXBsZXRlLSwgRXF1YWxpemF0aW9uUGhhc2UxLQoJCQkgRXF1YWxpemF0aW9uUGhhc2Uy
LSwgRXF1YWxpemF0aW9uUGhhc2UzLSwgTGlua0VxdWFsaXphdGlvblJlcXVlc3QtCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogeGhjaV9oY2QKCjAwOjA2LjAgTXVsdGltZWRpYSB2aWRlbyBj
b250cm9sbGVyIFswNDAwXTogQ29uZXhhbnQgU3lzdGVtcywgSW5jLiBEZXZpY2UgWzE0ZjE6
ODIxMF0KCVBoeXNpY2FsIFNsb3Q6IDYKCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIr
IFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIt
IEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtCglMYXRlbmN5OiAwCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJ
UlEgNDAKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjMwMDAwMDAgKDY0LWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9Mk1dCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1
bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMKCQkJRXh0VGFnLSBBdHRuQnRuLSBB
dHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9y
ZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsKCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNv
cnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0Nh
cDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRl
bmN5IEwwIDwydXMsIEwxIDw0dXMKCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBC
d05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0g
UmV0cmFpbi0gQ29tbUNsay0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJ
bnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy
LSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0KCUNhcGFiaWxp
dGllczogWzgwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGst
IERTSSsgRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQz
Y29sZC0pCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2Nh
bGU9MCBQTUUtCglDYXBhYmlsaXRpZXM6IFs5MF0gVml0YWwgUHJvZHVjdCBEYXRhCgkJVW5r
bm93biBzbWFsbCByZXNvdXJjZSB0eXBlIDAyLCB3aWxsIG5vdCBkZWNvZGUgbW9yZS4KCUNh
cGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJp
dCsKCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwCglLZXJuZWwgZHJp
dmVyIGluIHVzZTogY3gyNTgyMQoK
------------0C90EA036019900CC
Content-Type: text/plain;
 name="qemu-dm-guest.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="qemu-dm-guest.txt"

Y2hhciBkZXZpY2UgcmVkaXJlY3RlZCB0byAvZGV2L3B0cy8xOSAobGFiZWwgc2VyaWFsMCkN
Cnhlbjogc2hhcmVkIHBhZ2UgYXQgcGZuIGZlZmZkDQp4ZW46IGJ1ZmZlcmVkIGlvIHBhZ2Ug
YXQgcGZuIGZlZmZiDQp2Z2FiaW9zLWNpcnJ1cy5iaW46IFJPTSBpZCAxMDEzMDBiOCAvIFBD
SSBpZCAxMDEzMDBiOA0KZWZpLWUxMDAwLnJvbTogUk9NIGlkIDgwODYxMDBlIC8gUENJIGlk
IDgwODYxMDBlDQp4ZW46IHhlbl9tYWluX2xvb3BfcHJlcGFyZTogSW5pdCBjcHVfYnlfdmNw
dV9pZA0KeGVuOiB4ZW5fbWFpbl9sb29wX3ByZXBhcmU6IGNwdV9ieV92Y3B1X2lkWzBdPTB4
N2Y5YjAxNzU1ZTUwDQp4ZW46IHhlbl9tYWluX2xvb3BfcHJlcGFyZTogY3B1X2J5X3ZjcHVf
aWRbMV09MHg3ZjliMDE3NjgwYjANCnhlbjogeGVuX21haW5fbG9vcF9wcmVwYXJlOiBjcHVf
YnlfdmNwdV9pZFsyXT0weDdmOWIwMTc3ODkzMA0KeGVuOiB4ZW5fbWFpbl9sb29wX3ByZXBh
cmU6IGNwdV9ieV92Y3B1X2lkWzNdPTB4N2Y5YjAxN2IwNTQwDQp4ZW46IEkvTyByZXF1ZXN0
IG5vdCByZWFkeTogMCwgcHRyOiAwLCBwb3J0OiAwLCBkYXRhOiAwLCBjb3VudDogMCwgc2l6
ZTogMA0KeGVuOiBJL08gcmVxdWVzdCBub3QgcmVhZHk6IDAsIHB0cjogMCwgcG9ydDogMCwg
ZGF0YTogMCwgY291bnQ6IDAsIHNpemU6IDANCnhlbjogSS9PIHJlcXVlc3Qgbm90IHJlYWR5
OiAwLCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAwDQp4ZW46
IEkvTyByZXF1ZXN0IG5vdCByZWFkeTogMCwgcHRyOiAwLCBwb3J0OiAwLCBkYXRhOiAwLCBj
b3VudDogMCwgc2l6ZTogMA0KWzAwOjA1LjBdIHhlbl9wdF9pbml0Zm46IEFzc2lnbmluZyBy
ZWFsIHBoeXNpY2FsIGRldmljZSAwODowMC4wIHRvIGRldmZuIDB4MjggIDAwOjA1LjANClsw
MDowNS4wXSB4ZW5fcHRfcmVnaXN0ZXJfcmVnaW9uczogPyE/IT8geGVuX3B0X3JlZ2lzdGVy
X3JlZ2lvbnMgb3RoZXIgZGV2DQpbMDA6MDUuMF0geGVuX3B0X3JlZ2lzdGVyX3JlZ2lvbnM6
IElPIHJlZ2lvbiAwIHJlZ2lzdGVyZWQgKHNpemU9MHgwMDAwMjAwMCBiYXNlX2FkZHI9MHhm
ZTBmZTAwMCB0eXBlOiAweDQpDQpbMDA6MDUuMF0geGVuX3B0X21zaXhfaW5pdDogZ2V0IE1T
SS1YIHRhYmxlIEJBUiBiYXNlIDB4ZmUwZmUwMDANClswMDowNS4wXSB4ZW5fcHRfbXNpeF9p
bml0OiB0YWJsZV9vZmYgPSAweDEwMDAsIHRvdGFsX2VudHJpZXMgPSA4DQpbMDA6MDUuMF0g
eGVuX3B0X21zaXhfaW5pdDogbWFwcGluZyBwaHlzaWNhbCBNU0ktWCB0YWJsZSB0byAweDdm
OWIwMDM1MzAwMA0KWzAwOjA1LjBdIHhlbl9wdF9wY2lfaW50eDogaW50eD0xDQpbMDA6MDUu
MF0geGVuX3B0X2luaXRmbjogUmVhbCBwaHlzaWNhbCBkZXZpY2UgMDg6MDAuMCByZWdpc3Rl
cmVkIHN1Y2Nlc3NmdWxseSENClswMDowNi4wXSB4ZW5fcHRfaW5pdGZuOiBBc3NpZ25pbmcg
cmVhbCBwaHlzaWNhbCBkZXZpY2UgMGE6MDAuMCB0byBkZXZmbiAweDMwICAwMDowNi4wDQpb
MDA6MDYuMF0geGVuX3B0X3JlZ2lzdGVyX3JlZ2lvbnM6ID8hPyE/IHhlbl9wdF9yZWdpc3Rl
cl9yZWdpb25zIG90aGVyIGRldg0KWzAwOjA2LjBdIHhlbl9wdF9yZWdpc3Rlcl9yZWdpb25z
OiBJTyByZWdpb24gMCByZWdpc3RlcmVkIChzaXplPTB4MDAyMDAwMDAgYmFzZV9hZGRyPTB4
ZmUyMDAwMDAgdHlwZTogMHg0KQ0KWzAwOjA2LjBdIHhlbl9wdF9wY2lfaW50eDogaW50eD0x
DQpbMDA6MDYuMF0geGVuX3B0X2luaXRmbjogUmVhbCBwaHlzaWNhbCBkZXZpY2UgMGE6MDAu
MCByZWdpc3RlcmVkIHN1Y2Nlc3NmdWxseSENCnhlbjogcGh5c21hcHBpbmcgZG9lcyBub3Qg
ZXhpc3QgYXQgMDAwMDAwMDBmMzI2MDAwMA0KeGVuOiBtYXBwaW5nIHZyYW0gdG8gZjAwMDAw
MDAgLSBmMDgwMDAwMA0KeGVuOiBwaHlzbWFwcGluZyBkb2VzIG5vdCBleGlzdCBhdCAwMDAw
MDAwMGYzMjAwMDAwDQpbMDA6MDUuMF0geGVuX3B0X3BjaV93cml0ZV9jb25maWc6IFdhcm5p
bmc6IEd1ZXN0IGF0dGVtcHQgdG8gc2V0IGFkZHJlc3MgdG8gdW51c2VkIEJhc2UgQWRkcmVz
cyBSZWdpc3Rlci4gKGFkZHI6IDB4MzAsIGxlbjogNCkNClswMDowNi4wXSB4ZW5fcHRfcGNp
X3dyaXRlX2NvbmZpZzogV2FybmluZzogR3Vlc3QgYXR0ZW1wdCB0byBzZXQgYWRkcmVzcyB0
byB1bnVzZWQgQmFzZSBBZGRyZXNzIFJlZ2lzdGVyLiAoYWRkcjogMHgzMCwgbGVuOiA0KQ0K
PyE/IT8gcGNpX3VucmVnaXN0ZXJfdmdhIDAwOjA0LjA6ICFwY2lfZGV2LT5oYXNfdmdhDQpb
MDA6MDUuMF0geGVuX3B0X3BjaV93cml0ZV9jb25maWc6IFdhcm5pbmc6IEd1ZXN0IGF0dGVt
cHQgdG8gc2V0IGFkZHJlc3MgdG8gdW51c2VkIEJhc2UgQWRkcmVzcyBSZWdpc3Rlci4gKGFk
ZHI6IDB4MzAsIGxlbjogNCkNClswMDowNi4wXSB4ZW5fcHRfcGNpX3dyaXRlX2NvbmZpZzog
V2FybmluZzogR3Vlc3QgYXR0ZW1wdCB0byBzZXQgYWRkcmVzcyB0byB1bnVzZWQgQmFzZSBB
ZGRyZXNzIFJlZ2lzdGVyLiAoYWRkcjogMHgzMCwgbGVuOiA0KQ0KWzAwOjA1LjBdIHhlbl9w
dF9tc2l4Y3RybF9yZWdfd3JpdGU6IGVuYWJsZSBNU0ktWA0KWzAwOjA1LjBdIG1zaV9tc2l4
X3NldHVwOiByZXF1ZXN0ZWQgcGlycSA4NyBmb3IgTVNJLVggKHZlYzogMCwgZW50cnk6IDAp
DQpbMDA6MDUuMF0gbXNpX21zaXhfdXBkYXRlOiBVcGRhdGluZyBNU0ktWCB3aXRoIHBpcnEg
ODcgZ3ZlYyAwIGdmbGFncyAweDMwNTcgKGVudHJ5OiAwKQ0KWzAwOjA1LjBdIG1zaV9tc2l4
X3NldHVwOiByZXF1ZXN0ZWQgcGlycSA4NiBmb3IgTVNJLVggKHZlYzogMCwgZW50cnk6IDB4
MSkNClswMDowNS4wXSBtc2lfbXNpeF91cGRhdGU6IFVwZGF0aW5nIE1TSS1YIHdpdGggcGly
cSA4NiBndmVjIDAgZ2ZsYWdzIDB4MzA1NiAoZW50cnk6IDB4MSkNClswMDowNS4wXSBtc2lf
bXNpeF9zZXR1cDogcmVxdWVzdGVkIHBpcnEgODUgZm9yIE1TSS1YICh2ZWM6IDAsIGVudHJ5
OiAweDIpDQpbMDA6MDUuMF0gbXNpX21zaXhfdXBkYXRlOiBVcGRhdGluZyBNU0ktWCB3aXRo
IHBpcnEgODUgZ3ZlYyAwIGdmbGFncyAweDMwNTUgKGVudHJ5OiAweDIpDQpbMDA6MDUuMF0g
bXNpX21zaXhfc2V0dXA6IHJlcXVlc3RlZCBwaXJxIDg0IGZvciBNU0ktWCAodmVjOiAwLCBl
bnRyeTogMHgzKQ0KWzAwOjA1LjBdIG1zaV9tc2l4X3VwZGF0ZTogVXBkYXRpbmcgTVNJLVgg
d2l0aCBwaXJxIDg0IGd2ZWMgMCBnZmxhZ3MgMHgzMDU0IChlbnRyeTogMHgzKQ0KWzAwOjA1
LjBdIG1zaV9tc2l4X3NldHVwOiByZXF1ZXN0ZWQgcGlycSA4MyBmb3IgTVNJLVggKHZlYzog
MCwgZW50cnk6IDB4NCkNClswMDowNS4wXSBtc2lfbXNpeF91cGRhdGU6IFVwZGF0aW5nIE1T
SS1YIHdpdGggcGlycSA4MyBndmVjIDAgZ2ZsYWdzIDB4MzA1MyAoZW50cnk6IDB4NCkNCnhl
biBiZTogdmtiZC0wOiBpbml0aWFsaXNlKCkgZmFpbGVkDQp4ZW4gYmU6IHZrYmQtMDogaW5p
dGlhbGlzZSgpIGZhaWxlZA0KeGVuIGJlOiB2a2JkLTA6IGluaXRpYWxpc2UoKSBmYWlsZWQN
Cg==
------------0C90EA036019900CC
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0C90EA036019900CC--



From xen-devel-bounces@lists.xen.org Mon Nov 17 22:40:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 22: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 1XqUy2-0007k6-4j; Mon, 17 Nov 2014 22:40:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqUy0-0007k1-Ms
	for xen-devel@lists.xenproject.org; Mon, 17 Nov 2014 22:40:17 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	04/2D-03148-0597A645; Mon, 17 Nov 2014 22:40:16 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416264012!13148899!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4459 invoked from network); 17 Nov 2014 22:40:12 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 17 Nov 2014 22:40:12 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50843 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqUwX-0006Cv-Vt; Mon, 17 Nov 2014 23:38:46 +0100
Date: Mon, 17 Nov 2014 23:40:11 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1271355060.20141117234011@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141117204347.GA27617@laptop.dumpdata.com>
References: <546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0C90EA036019900CC"
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0C90EA036019900CC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Monday, November 17, 2014, 9:43:47 PM, you wrote:

> . snip..
>> > # cat /proc/interrupts |grep eth
>> >  36:     384183          0  xen-pirq-ioapic-level  eth0
>> >  63:          1          0  xen-pirq-msi-x     eth1
>> >  64:         24     661961  xen-pirq-msi-x     eth1-rx-0
>> >  65:        205          0  xen-pirq-msi-x     eth1-rx-1
>> >  66:        162          0  xen-pirq-msi-x     eth1-tx-0
>> >  67:        190          0  xen-pirq-msi-x     eth1-tx-1
>> > Is that a similar distribution of IRQ/MSIx you end up having?
>> 
>> These are when they are still active and assigned to dom0 (and not owned by 
>> pci-back) or in the guest ?

> In the guest.
>> 
>> I attached my /proc/interrupts for both dom0 as guest 16 with all guests running 
>> (on a Xen from before the dpci changes). 
>> With the devices passed through I only see one line with the IRQ of a 
>> PCI soundcard passed through to a PV guest:
>>   22:      38959          0          0          0          0          0  xen-pirq-ioapic-level  xen-pciback[0000:03:06.0]
>> 
>> All the other devices passed through (to HVM guests) are not visible in /proc/interrupts of dom0.

> Right.
>> 
>> In the guest i do get these:
>>  23:         35          0          0          0  xen-pirq-ioapic-level  uhci_hcd:usb3
>>  40:   13440077          0          0          0  xen-pirq-ioapic-level  cx25821[1], cx25821[1]

> That is a bit odd. You have two 'request_irq' off this sole device, which would
> imply that there are _two_ devices which are using the same interrupt line.

> But how is that possible when your device:

> 0a:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
>         Flags: bus master, fast devsel, latency 0, IRQ 47
>         Memory at fe200000 (64-bit, non-prefetchable) [size=2M]
>         Capabilities: [40] Express Endpoint, MSI 00
>         Capabilities: [80] Power Management version 3
>         Capabilities: [90] Vital Product Data
>         Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
>         Capabilities: [100] Advanced Error Reporting
>         Capabilities: [200] Virtual Channel
>         Kernel driver in use: pciback

> Has only one IRQ! What is the name of this device? Perhaps I've another one that
> is similar to this. Could you attach

Well it's a videograbber .. with also one port for audio (not used) that 
registers with alsa. I can have a look if i can disable the audio part and see if it makes a 
difference, i don't use it anyway.


>  a) 'lspci -vvvv' from your guest please?
Attached

>  b) The  the full 'dmesg' from your guest?
Attached

>  c) the /var/log/xen/qemu-dm-XXX ? Hmm, you are using qemu-xen so it won't log
>     that much information. Could you try 'qemu-traditional' or would that
>     mess up with XHCI?
Attached, it contains some info (since i enabled debugging already) but most 
about MSI-X and not much about the legacy irq case though ...

I don't think traditional will mess up XHCI, it's also worth a try.

When looking at the driver /drivers/media/pci/cx25821 it's also clear why it 
doesn't enable MSI, though the card would support it according to lspci, the 
drivers lacks support (when i grep for MSI).

Also the driver seems to have an parameter to do irq debugging .. no idea how 
hard that will flood logs, but it's also worth a try :-)
cx25821-video.c:47:MODULE_PARM_DESC(irq_debug, "enable debug messages [IRQ handler]");


> In regards to your other question:
>         Hi Konrad,
>         Here is the xl dmesg output with this patch (attached with debug-key i and M
>         output). What i don't get .. is that d16 and d17 each have a device passed through
>         that seems to be using the same pirq 87 ?

> Those are per guest. They are the MSI values after 84 or so.
Hrrm yes i had found that already :-) 
All those (legacy) irq, msi, gsi, vector, pirq numbers can be a bit mind boggling ..  what corresponds to what where and when.

> Back to your crash:

> d16 OK-softirq 458msec ago, state:1, 52039 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> d16 OK-raise   489msec ago, state:1, 52049 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> d16 ERR-poison 561msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> d16 Z-softirq  731msec ago, state:3, 3 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> domain_crash called from io.c:938
> Domain 16 reported crashed by domain 32767 on cpu#5:

> All of it point to the legacy interrupt - that is the on that starts at Xen IRQ 47 (guest IRQ 40):
>  io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0
> IRQ:  47 affinity:02 vec:d1 type=IO-APIC-level   status=00000030 in-flight=1 domain-list=16: +47(P-M),

> which looks OK.
OK, i still don't get why the output of debug-key 'i' reports +47 as pirq here instead of the guest value 
(g_gsi of for this legacy interrupt which is 40 ?), like it does when it's a MSI with the PIRQ ?

> I am puzzled by the driver binding twice to the same interrupt, but perhaps that
> is just a buggy driver.

Doesn't that happen more often like with integrated USB controllers ?
  17:          4          0          0          0          0          0  xen-pirq-ioapic-level  ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
  18:       4385          0          0          0          0          0  xen-pirq-ioapic-level  ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7


And on host boot (with still some extra printk's):
[   12.773709] xen: registering gsi 18 triggering 0 polarity 1
[   12.773731] xen: --> pirq=18 -> irq=18 (gsi=18)
[   12.773749] pci 0000:00:12.0: ?!?!? acpi_pci_irq_enable: PCI INT A -> GSI 18 (level, low) -> IRQ/rc 18
[   12.848820] pci 0000:00:12.2: calling quirk_usb_early_handoff+0x0/0x6f0
[   12.848942] xen: registering gsi 17 triggering 0 polarity 1
[   12.848957] xen: --> pirq=17 -> irq=17 (gsi=17)
[   12.848975] pci 0000:00:12.2: ?!?!? acpi_pci_irq_enable: PCI INT B -> GSI 17 (level, low) -> IRQ/rc 17
[   12.849120] pci 0000:00:13.0: calling quirk_usb_early_handoff+0x0/0x6f0
[   12.849236] xen: registering gsi 18 triggering 0 polarity 1
[   12.849240] Already setup the GSI :18
[   12.849245] pci 0000:00:13.0: ?!?!? acpi_pci_irq_enable: PCI INT A -> GSI 18 (level, low) -> IRQ/rc 18
[   12.925464] pci 0000:00:13.2: calling quirk_usb_early_handoff+0x0/0x6f0
[   12.925583] xen: registering gsi 17 triggering 0 polarity 1
[   12.925589] Already setup the GSI :17
[   12.925593] pci 0000:00:13.2: ?!?!? acpi_pci_irq_enable: PCI INT B -> GSI 17 (level, low) -> IRQ/rc 17
[   12.925748] pci 0000:00:14.5: calling quirk_usb_early_handoff+0x0/0x6f0
[   12.925863] xen: registering gsi 18 triggering 0 polarity 1
[   12.925868] Already setup the GSI :18
[   12.925872] pci 0000:00:14.5: ?!?!? acpi_pci_irq_enable: PCI INT C -> GSI 18 (level, low) -> IRQ/rc 18
[   13.002145] pci 0000:00:16.0: calling quirk_usb_early_handoff+0x0/0x6f0
[   13.002264] xen: registering gsi 18 triggering 0 polarity 1
[   13.002269] Already setup the GSI :18
[   13.002273] pci 0000:00:16.0: ?!?!? acpi_pci_irq_enable: PCI INT A -> GSI 18 (level, low) -> IRQ/rc 18
[   13.078814] pci 0000:00:16.2: calling quirk_usb_early_handoff+0x0/0x6f0
------------0C90EA036019900CC
Content-Type: text/plain;
 name="dmesg-guest.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="dmesg-guest.txt"

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAg
MC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAw
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVhY2N0ClsgICAgMC4wMDAwMDBdIExp
bnV4IHZlcnNpb24gMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0eSsgKHJvb3RAc2VjdXJp
dHkpIChnY2MgdmVyc2lvbiA0LjcuMiAoRGViaWFuIDQuNy4yLTUpICkgIzEgU01QIFN1biBO
b3YgMTYgMTQ6NDQ6MjggQ0VUIDIwMTQKWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiBC
T09UX0lNQUdFPS9ib290L3ZtbGludXotMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0eSsg
cm9vdD0vZGV2L3h2ZGExIHJvIGNvbnNvbGU9dHR5MSBjb25zb2xlPXR0eVMwIG5vbW9kZXNl
dApbICAgIDAuMDAwMDAwXSB0c2VnOiAwMDAwMDAwMDAwClsgICAgMC4wMDAwMDBdIGU4MjA6
IEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoKWyAgICAwLjAwMDAwMF0gQklPUy1l
ODIwOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWZiZmZdIHVzYWJs
ZQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMDAwMDlmYzAwLTB4
MDAwMDAwMDAwMDA5ZmZmZl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBb
bWVtIDB4MDAwMDAwMDAwMDBmMDAwMC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkClsg
ICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAw
MDAwMDNmN2ZkZmZmXSB1c2FibGUKWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4
MDAwMDAwMDAzZjdmZTAwMC0weDAwMDAwMDAwM2Y3ZmZmZmZdIHJlc2VydmVkClsgICAgMC4w
MDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwZmMwMDAwMDAtMHgwMDAwMDAwMGZm
ZmZmZmZmXSByZXNlcnZlZApbICAgIDAuMDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBw
cm90ZWN0aW9uOiBhY3RpdmUKWyAgICAwLjAwMDAwMF0gU01CSU9TIDIuNCBwcmVzZW50Lgpb
ICAgIDAuMDAwMDAwXSBETUk6IFhlbiBIVk0gZG9tVSwgQklPUyA0LjUuMC1yYyAxMS8xNy8y
MDE0ClsgICAgMC4wMDAwMDBdIEh5cGVydmlzb3IgZGV0ZWN0ZWQ6IFhlbiBIVk0KWyAgICAw
LjAwMDAwMF0gWGVuIHZlcnNpb24gNC41LgpbICAgIDAuMDAwMDAwXSBYZW4gUGxhdGZvcm0g
UENJOiBJL08gcHJvdG9jb2wgdmVyc2lvbiAxClsgICAgMC4wMDAwMDBdIE5ldGZyb250IGFu
ZCB0aGUgWGVuIHBsYXRmb3JtIFBDSSBkcml2ZXIgaGF2ZSBiZWVuIGNvbXBpbGVkIGZvciB0
aGlzIGtlcm5lbDogdW5wbHVnIGVtdWxhdGVkIE5JQ3MuClsgICAgMC4wMDAwMDBdIEJsa2Zy
b250IGFuZCB0aGUgWGVuIHBsYXRmb3JtIFBDSSBkcml2ZXIgaGF2ZSBiZWVuIGNvbXBpbGVk
IGZvciB0aGlzIGtlcm5lbDogdW5wbHVnIGVtdWxhdGVkIGRpc2tzLgpbICAgIDAuMDAwMDAw
XSBZb3UgbWlnaHQgaGF2ZSB0byBjaGFuZ2UgdGhlIHJvb3QgZGV2aWNlClsgICAgMC4wMDAw
MDBdIGZyb20gL2Rldi9oZFthLWRdIHRvIC9kZXYveHZkW2EtZF0KWyAgICAwLjAwMDAwMF0g
aW4geW91ciByb290PSBrZXJuZWwgY29tbWFuZCBsaW5lIG9wdGlvbgpbICAgIDAuMDAwMDAw
XSBIVk1PUF9wYWdldGFibGVfZHlpbmcgbm90IHN1cHBvcnRlZApbICAgIDAuMDAwMDAwXSBl
ODIwOiB1cGRhdGUgW21lbSAweDAwMDAwMDAwLTB4MDAwMDBmZmZdIHVzYWJsZSA9PT4gcmVz
ZXJ2ZWQKWyAgICAwLjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHgwMDBhMDAwMC0weDAw
MGZmZmZmXSB1c2FibGUKWyAgICAwLjAwMDAwMF0gQUdQOiBObyBBR1AgYnJpZGdlIGZvdW5k
ClsgICAgMC4wMDAwMDBdIGU4MjA6IGxhc3RfcGZuID0gMHgzZjdmZSBtYXhfYXJjaF9wZm4g
PSAweDQwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBNVFJSIGRlZmF1bHQgdHlwZTogd3JpdGUt
YmFjawpbICAgIDAuMDAwMDAwXSBNVFJSIGZpeGVkIHJhbmdlcyBlbmFibGVkOgpbICAgIDAu
MDAwMDAwXSAgIDAwMDAwLTlGRkZGIHdyaXRlLWJhY2sKWyAgICAwLjAwMDAwMF0gICBBMDAw
MC1CRkZGRiB3cml0ZS1jb21iaW5pbmcKWyAgICAwLjAwMDAwMF0gICBDMDAwMC1GRkZGRiB3
cml0ZS1iYWNrClsgICAgMC4wMDAwMDBdIE1UUlIgdmFyaWFibGUgcmFuZ2VzIGVuYWJsZWQ6
ClsgICAgMC4wMDAwMDBdICAgMCBiYXNlIDAwMDBGMDAwMDAwMCBtYXNrIEZGRkZGMDAwMDAw
MCB1bmNhY2hhYmxlClsgICAgMC4wMDAwMDBdICAgMSBkaXNhYmxlZApbICAgIDAuMDAwMDAw
XSAgIDIgZGlzYWJsZWQKWyAgICAwLjAwMDAwMF0gICAzIGRpc2FibGVkClsgICAgMC4wMDAw
MDBdICAgNCBkaXNhYmxlZApbICAgIDAuMDAwMDAwXSAgIDUgZGlzYWJsZWQKWyAgICAwLjAw
MDAwMF0gICA2IGRpc2FibGVkClsgICAgMC4wMDAwMDBdICAgNyBkaXNhYmxlZApbICAgIDAu
MDAwMDAwXSBUT00yOiAwMDAwMDAwNTYwMDAwMDAwIGFrYSAyMjAxNk0KWyAgICAwLjAwMDAw
MF0geDg2IFBBVCBlbmFibGVkOiBjcHUgMCwgb2xkIDB4NzA0MDYwMDA3MDQwNiwgbmV3IDB4
NzAxMDYwMDA3MDEwNgpbICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgW21l
bSAweDAwMGY1Y2MwLTB4MDAwZjVjY2ZdIG1hcHBlZCBhdCBbZmZmZjg4MDAwMDBmNWNjMF0K
WyAgICAwLjAwMDAwMF0gU2Nhbm5pbmcgMSBhcmVhcyBmb3IgbG93IG1lbW9yeSBjb3JydXB0
aW9uClsgICAgMC4wMDAwMDBdIEJhc2UgbWVtb3J5IHRyYW1wb2xpbmUgYXQgW2ZmZmY4ODAw
MDAwOTkwMDBdIDk5MDAwIHNpemUgMjQ1NzYKWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlf
bWFwcGluZzogW21lbSAweDAwMDAwMDAwLTB4MDAwZmZmZmZdClsgICAgMC4wMDAwMDBdICBb
bWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0gcGFnZSA0awpbICAgIDAuMDAwMDAwXSBCUksg
WzB4MDIyZmUwMDAsIDB4MDIyZmVmZmZdIFBHVEFCTEUKWyAgICAwLjAwMDAwMF0gQlJLIFsw
eDAyMmZmMDAwLCAweDAyMmZmZmZmXSBQR1RBQkxFClsgICAgMC4wMDAwMDBdIEJSSyBbMHgw
MjMwMDAwMCwgMHgwMjMwMGZmZl0gUEdUQUJMRQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9y
eV9tYXBwaW5nOiBbbWVtIDB4M2Y0MDAwMDAtMHgzZjVmZmZmZl0KWyAgICAwLjAwMDAwMF0g
IFttZW0gMHgzZjQwMDAwMC0weDNmNWZmZmZmXSBwYWdlIDJNClsgICAgMC4wMDAwMDBdIGlu
aXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgzYzAwMDAwMC0weDNmM2ZmZmZmXQpbICAgIDAu
MDAwMDAwXSAgW21lbSAweDNjMDAwMDAwLTB4M2YzZmZmZmZdIHBhZ2UgMk0KWyAgICAwLjAw
MDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZd
ClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAxMDAwMDAtMHgwMDFmZmZmZl0gcGFnZSA0awpb
ICAgIDAuMDAwMDAwXSAgW21lbSAweDAwMjAwMDAwLTB4M2JmZmZmZmZdIHBhZ2UgMk0KWyAg
ICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDNmNjAwMDAwLTB4M2Y3
ZmRmZmZdClsgICAgMC4wMDAwMDBdICBbbWVtIDB4M2Y2MDAwMDAtMHgzZjdmZGZmZl0gcGFn
ZSA0awpbICAgIDAuMDAwMDAwXSBCUksgWzB4MDIzMDEwMDAsIDB4MDIzMDFmZmZdIFBHVEFC
TEUKWyAgICAwLjAwMDAwMF0gUkFNRElTSzogW21lbSAweDM3YzQ4MDAwLTB4MzdlMWJmZmZd
ClsgICAgMC4wMDAwMDBdIEFDUEk6IEVhcmx5IHRhYmxlIGNoZWNrc3VtIHZlcmlmaWNhdGlv
biBkaXNhYmxlZApbICAgIDAuMDAwMDAwXSBBQ1BJOiBSU0RQIDB4MDAwMDAwMDAwMDBGNUMx
MCAwMDAwMjQgKHYwMiBYZW4gICApClsgICAgMC4wMDAwMDBdIEFDUEk6IFhTRFQgMHgwMDAw
MDAwMEZDMDBBMTQwIDAwMDA1NCAodjAxIFhlbiAgICBIVk0gICAgICAwMDAwMDAwMCBIVk1M
IDAwMDAwMDAwKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBGQUNQIDB4MDAwMDAwMDBGQzAwOUE3
MCAwMDAwRjQgKHYwNCBYZW4gICAgSFZNICAgICAgMDAwMDAwMDAgSFZNTCAwMDAwMDAwMCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogRFNEVCAweDAwMDAwMDAwRkMwMDEzMDAgMDA4NkYwICh2
MDIgWGVuICAgIEhWTSAgICAgIDAwMDAwMDAwIElOVEwgMjAxMDA1MjgpClsgICAgMC4wMDAw
MDBdIEFDUEk6IEZBQ1MgMHgwMDAwMDAwMEZDMDAxMkMwIDAwMDA0MApbICAgIDAuMDAwMDAw
XSBBQ1BJOiBBUElDIDB4MDAwMDAwMDBGQzAwOUI3MCAwMDA0NjAgKHYwMiBYZW4gICAgSFZN
ICAgICAgMDAwMDAwMDAgSFZNTCAwMDAwMDAwMCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSFBF
VCAweDAwMDAwMDAwRkMwMEEwNTAgMDAwMDM4ICh2MDEgWGVuICAgIEhWTSAgICAgIDAwMDAw
MDAwIEhWTUwgMDAwMDAwMDApClsgICAgMC4wMDAwMDBdIEFDUEk6IFdBRVQgMHgwMDAwMDAw
MEZDMDBBMDkwIDAwMDAyOCAodjAxIFhlbiAgICBIVk0gICAgICAwMDAwMDAwMCBIVk1MIDAw
MDAwMDAwKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDB4MDAwMDAwMDBGQzAwQTBDMCAw
MDAwMzEgKHYwMiBYZW4gICAgSFZNICAgICAgMDAwMDAwMDAgSU5UTCAyMDEwMDUyOCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogU1NEVCAweDAwMDAwMDAwRkMwMEExMDAgMDAwMDMxICh2MDIg
WGVuICAgIEhWTSAgICAgIDAwMDAwMDAwIElOVEwgMjAxMDA1MjgpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIE5v
IE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZApbICAgIDAuMDAwMDAwXSBGYWtpbmcgYSBub2Rl
IGF0IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAzZjdmZGZmZl0KWyAgICAw
LjAwMDAwMF0gTk9ERV9EQVRBKDApIGFsbG9jYXRlZCBbbWVtIDB4M2Y3ZjMwMDAtMHgzZjdm
ZGZmZl0KWyAgICAwLjAwMDAwMF0gIFtmZmZmZWEwMDAwMDAwMDAwLWZmZmZlYTAwMDBmZmZm
ZmZdIFBNRCAtPiBbZmZmZjg4MDAzZGUwMDAwMC1mZmZmODgwMDNlZGZmZmZmXSBvbiBub2Rl
IDAKWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6ClsgICAgMC4wMDAwMDBdICAgRE1BICAg
ICAgW21lbSAweDAwMDAxMDAwLTB4MDBmZmZmZmZdClsgICAgMC4wMDAwMDBdICAgRE1BMzIg
ICAgW21lbSAweDAxMDAwMDAwLTB4ZmZmZmZmZmZdClsgICAgMC4wMDAwMDBdICAgTm9ybWFs
ICAgZW1wdHkKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0IGZvciBlYWNoIG5v
ZGUKWyAgICAwLjAwMDAwMF0gRWFybHkgbWVtb3J5IG5vZGUgcmFuZ2VzClsgICAgMC4wMDAw
MDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAwMTAwMC0weDAwMDllZmZmXQpbICAgIDAuMDAw
MDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4MDAxMDAwMDAtMHgzZjdmZGZmZl0KWyAgICAwLjAw
MDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAgW21lbSAweDAwMDAxMDAwLTB4M2Y3ZmRmZmZd
ClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAyNTk5OTYKWyAgICAwLjAw
MDAwMF0gICBETUEgem9uZTogNjQgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAw
MDBdICAgRE1BIHpvbmU6IDIxIHBhZ2VzIHJlc2VydmVkClsgICAgMC4wMDAwMDBdICAgRE1B
IHpvbmU6IDM5OTggcGFnZXMsIExJRk8gYmF0Y2g6MApbICAgIDAuMDAwMDAwXSAgIERNQTMy
IHpvbmU6IDQwMDAgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgRE1B
MzIgem9uZTogMjU1OTk4IHBhZ2VzLCBMSUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdIEFD
UEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4YjAwOApbICAgIDAuMDAwMDAwXSBBQ1BJOiBMb2Nh
bCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDAwXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDA0XSBl
bmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBp
Y19pZFsweDA2XSBlbmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDA0XSBsYXBpY19pZFsweDA4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwYV0gZGlzYWJsZWQpClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MGNdIGRpc2Fi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA3XSBsYXBpY19p
ZFsweDBlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwOF0gbGFwaWNfaWRbMHgxMF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MDldIGxhcGljX2lkWzB4MTJdIGRpc2FibGVkKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBhXSBsYXBpY19pZFsweDE0XSBkaXNhYmxl
ZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwYl0gbGFwaWNfaWRb
MHgxNl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
MGNdIGxhcGljX2lkWzB4MThdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDBkXSBsYXBpY19pZFsweDFhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwZV0gbGFwaWNfaWRbMHgxY10gZGlzYWJsZWQp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGZdIGxhcGljX2lkWzB4
MWVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDEw
XSBsYXBpY19pZFsweDIwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgxMV0gbGFwaWNfaWRbMHgyMl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MTJdIGxhcGljX2lkWzB4MjRdIGRpc2FibGVkKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDEzXSBsYXBpY19pZFsweDI2
XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxNF0g
bGFwaWNfaWRbMHgyOF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4MTVdIGxhcGljX2lkWzB4MmFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDE2XSBsYXBpY19pZFsweDJjXSBkaXNhYmxlZCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxN10gbGFwaWNfaWRbMHgyZV0g
ZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MThdIGxh
cGljX2lkWzB4MzBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDE5XSBsYXBpY19pZFsweDMyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgxYV0gbGFwaWNfaWRbMHgzNF0gZGlzYWJsZWQpClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MWJdIGxhcGljX2lkWzB4MzZdIGRp
c2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDFjXSBsYXBp
Y19pZFsweDM4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgxZF0gbGFwaWNfaWRbMHgzYV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4MWVdIGxhcGljX2lkWzB4M2NdIGRpc2FibGVkKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDFmXSBsYXBpY19pZFsweDNlXSBkaXNh
YmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyMF0gbGFwaWNf
aWRbMHg0MF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MjFdIGxhcGljX2lkWzB4NDJdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDIyXSBsYXBpY19pZFsweDQ0XSBkaXNhYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyM10gbGFwaWNfaWRbMHg0Nl0gZGlzYWJs
ZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MjRdIGxhcGljX2lk
WzB4NDhdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDI1XSBsYXBpY19pZFsweDRhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgyNl0gbGFwaWNfaWRbMHg0Y10gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MjddIGxhcGljX2lkWzB4NGVdIGRpc2FibGVk
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDI4XSBsYXBpY19pZFsw
eDUwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgy
OV0gbGFwaWNfaWRbMHg1Ml0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4MmFdIGxhcGljX2lkWzB4NTRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDJiXSBsYXBpY19pZFsweDU2XSBkaXNhYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyY10gbGFwaWNfaWRbMHg1
OF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MmRd
IGxhcGljX2lkWzB4NWFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDJlXSBsYXBpY19pZFsweDVjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyZl0gbGFwaWNfaWRbMHg1ZV0gZGlzYWJsZWQpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MzBdIGxhcGljX2lkWzB4NjBd
IGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDMxXSBs
YXBpY19pZFsweDYyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgzMl0gbGFwaWNfaWRbMHg2NF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MzNdIGxhcGljX2lkWzB4NjZdIGRpc2FibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDM0XSBsYXBpY19pZFsweDY4XSBk
aXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgzNV0gbGFw
aWNfaWRbMHg2YV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MzZdIGxhcGljX2lkWzB4NmNdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDM3XSBsYXBpY19pZFsweDZlXSBkaXNhYmxlZCkKWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgzOF0gbGFwaWNfaWRbMHg3MF0gZGlz
YWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MzldIGxhcGlj
X2lkWzB4NzJdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDNhXSBsYXBpY19pZFsweDc0XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgzYl0gbGFwaWNfaWRbMHg3Nl0gZGlzYWJsZWQpClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4M2NdIGxhcGljX2lkWzB4NzhdIGRpc2Fi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDNkXSBsYXBpY19p
ZFsweDdhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgzZV0gbGFwaWNfaWRbMHg3Y10gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4M2ZdIGxhcGljX2lkWzB4N2VdIGRpc2FibGVkKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQwXSBsYXBpY19pZFsweDgwXSBkaXNhYmxl
ZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0MV0gbGFwaWNfaWRb
MHg4Ml0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
NDJdIGxhcGljX2lkWzB4ODRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDQzXSBsYXBpY19pZFsweDg2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0NF0gbGFwaWNfaWRbMHg4OF0gZGlzYWJsZWQp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NDVdIGxhcGljX2lkWzB4
OGFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQ2
XSBsYXBpY19pZFsweDhjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHg0N10gbGFwaWNfaWRbMHg4ZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4NDhdIGxhcGljX2lkWzB4OTBdIGRpc2FibGVkKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQ5XSBsYXBpY19pZFsweDky
XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0YV0g
bGFwaWNfaWRbMHg5NF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4NGJdIGxhcGljX2lkWzB4OTZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDRjXSBsYXBpY19pZFsweDk4XSBkaXNhYmxlZCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0ZF0gbGFwaWNfaWRbMHg5YV0g
ZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NGVdIGxh
cGljX2lkWzB4OWNdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDRmXSBsYXBpY19pZFsweDllXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHg1MF0gbGFwaWNfaWRbMHhhMF0gZGlzYWJsZWQpClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NTFdIGxhcGljX2lkWzB4YTJdIGRp
c2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDUyXSBsYXBp
Y19pZFsweGE0XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHg1M10gbGFwaWNfaWRbMHhhNl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4NTRdIGxhcGljX2lkWzB4YThdIGRpc2FibGVkKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDU1XSBsYXBpY19pZFsweGFhXSBkaXNh
YmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1Nl0gbGFwaWNf
aWRbMHhhY10gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4NTddIGxhcGljX2lkWzB4YWVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDU4XSBsYXBpY19pZFsweGIwXSBkaXNhYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1OV0gbGFwaWNfaWRbMHhiMl0gZGlzYWJs
ZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NWFdIGxhcGljX2lk
WzB4YjRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDViXSBsYXBpY19pZFsweGI2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHg1Y10gbGFwaWNfaWRbMHhiOF0gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NWRdIGxhcGljX2lkWzB4YmFdIGRpc2FibGVk
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDVlXSBsYXBpY19pZFsw
eGJjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1
Zl0gbGFwaWNfaWRbMHhiZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4NjBdIGxhcGljX2lkWzB4YzBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDYxXSBsYXBpY19pZFsweGMyXSBkaXNhYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2Ml0gbGFwaWNfaWRbMHhj
NF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NjNd
IGxhcGljX2lkWzB4YzZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDY0XSBsYXBpY19pZFsweGM4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2NV0gbGFwaWNfaWRbMHhjYV0gZGlzYWJsZWQpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NjZdIGxhcGljX2lkWzB4Y2Nd
IGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDY3XSBs
YXBpY19pZFsweGNlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHg2OF0gbGFwaWNfaWRbMHhkMF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4NjldIGxhcGljX2lkWzB4ZDJdIGRpc2FibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDZhXSBsYXBpY19pZFsweGQ0XSBk
aXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2Yl0gbGFw
aWNfaWRbMHhkNl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4NmNdIGxhcGljX2lkWzB4ZDhdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDZkXSBsYXBpY19pZFsweGRhXSBkaXNhYmxlZCkKWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2ZV0gbGFwaWNfaWRbMHhkY10gZGlz
YWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NmZdIGxhcGlj
X2lkWzB4ZGVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDcwXSBsYXBpY19pZFsweGUwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHg3MV0gbGFwaWNfaWRbMHhlMl0gZGlzYWJsZWQpClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NzJdIGxhcGljX2lkWzB4ZTRdIGRpc2Fi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDczXSBsYXBpY19p
ZFsweGU2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHg3NF0gbGFwaWNfaWRbMHhlOF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4NzVdIGxhcGljX2lkWzB4ZWFdIGRpc2FibGVkKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDc2XSBsYXBpY19pZFsweGVjXSBkaXNhYmxl
ZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3N10gbGFwaWNfaWRb
MHhlZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
NzhdIGxhcGljX2lkWzB4ZjBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDc5XSBsYXBpY19pZFsweGYyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3YV0gbGFwaWNfaWRbMHhmNF0gZGlzYWJsZWQp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4N2JdIGxhcGljX2lkWzB4
ZjZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDdj
XSBsYXBpY19pZFsweGY4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHg3ZF0gbGFwaWNfaWRbMHhmYV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4N2VdIGxhcGljX2lkWzB4ZmNdIGRpc2FibGVkKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDdmXSBsYXBpY19pZFsweGZl
XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDAxXSBhZGRy
ZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQpbICAgIDAuMDAwMDAwXSBJT0FQSUNbMF06
IGFwaWNfaWQgMSwgdmVyc2lvbiAxNywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC00Nwpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2Jh
bF9pcnEgMiBkZmwgZGZsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVz
IDAgYnVzX2lycSA1IGdsb2JhbF9pcnEgNSBsb3cgbGV2ZWwpClsgICAgMC4wMDAwMDBdIEFD
UEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDEwIGdsb2JhbF9pcnEgMTAgbG93IGxl
dmVsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAx
MSBnbG9iYWxfaXJxIDExIGxvdyBsZXZlbCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMCB1
c2VkIGJ5IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE1IHVzZWQgYnkgb3Zl
cnJpZGUuClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KWyAg
ICAwLjAwMDAwMF0gQUNQSTogSVJRMTAgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAw
MF0gQUNQSTogSVJRMTEgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAwMF0gVXNpbmcg
QUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uClsgICAgMC4w
MDAwMDBdIEFDUEk6IEhQRVQgaWQ6IDB4ODA4NmEyMDEgYmFzZTogMHhmZWQwMDAwMApbICAg
IDAuMDAwMDAwXSBzbXBib290OiAxMjggUHJvY2Vzc29ycyBleGNlZWRzIE5SX0NQVVMgbGlt
aXQgb2YgOApbICAgIDAuMDAwMDAwXSBzbXBib290OiBBbGxvd2luZyA4IENQVXMsIDQgaG90
cGx1ZyBDUFVzClsgICAgMC4wMDAwMDBdIGU4MjA6IFttZW0gMHgzZjgwMDAwMC0weGZiZmZm
ZmZmXSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2VzClsgICAgMC4wMDAwMDBdIEJvb3Rpbmcg
cGFyYXZpcnR1YWxpemVkIGtlcm5lbCBvbiBYZW4gSFZNClsgICAgMC4wMDAwMDBdIHNldHVw
X3BlcmNwdTogTlJfQ1BVUzo4IG5yX2NwdW1hc2tfYml0czo4IG5yX2NwdV9pZHM6OCBucl9u
b2RlX2lkczoxClsgICAgMC4wMDAwMDBdIFBFUkNQVTogRW1iZWRkZWQgMjkgcGFnZXMvY3B1
IEBmZmZmODgwMDNmNDAwMDAwIHM3OTQ4OCByODE5MiBkMzExMDQgdTI2MjE0NApbICAgIDAu
MDAwMDAwXSBwY3B1LWFsbG9jOiBzNzk0ODggcjgxOTIgZDMxMTA0IHUyNjIxNDQgYWxsb2M9
MSoyMDk3MTUyClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IFswXSAwIDEgMiAzIDQgNSA2
IDcgClsgICAgMC4wMDAwMDBdIHhlbjogUFYgc3BpbmxvY2tzIGVuYWJsZWQKWyAgICAwLjAw
MDAwMF0gQnVpbHQgMSB6b25lbGlzdHMgaW4gTm9kZSBvcmRlciwgbW9iaWxpdHkgZ3JvdXBp
bmcgb24uICBUb3RhbCBwYWdlczogMjU1OTExClsgICAgMC4wMDAwMDBdIFBvbGljeSB6b25l
OiBETUEzMgpbICAgIDAuMDAwMDAwXSBLZXJuZWwgY29tbWFuZCBsaW5lOiBCT09UX0lNQUdF
PS9ib290L3ZtbGludXotMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0eSsgcm9vdD0vZGV2
L3h2ZGExIHJvIGNvbnNvbGU9dHR5MSBjb25zb2xlPXR0eVMwIG5vbW9kZXNldApbICAgIDAu
MDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMywgMzI3Njgg
Ynl0ZXMpClsgICAgMC4wMDAwMDBdIEFHUDogQ2hlY2tpbmcgYXBlcnR1cmUuLi4KWyAgICAw
LjAwMDAwMF0gQUdQOiBObyBBR1AgYnJpZGdlIGZvdW5kClsgICAgMC4wMDAwMDBdIE1lbW9y
eTogMTAwMTEyMEsvMTAzOTk4NEsgYXZhaWxhYmxlICgxMDk0MEsga2VybmVsIGNvZGUsIDg4
NksgcndkYXRhLCAzNTAwSyByb2RhdGEsIDEwNDhLIGluaXQsIDEwNzZLIGJzcywgMzg4NjRL
IHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSBTTFVCOiBIV2FsaWduPTY0LCBPcmRlcj0wLTMs
IE1pbk9iamVjdHM9MCwgQ1BVcz04LCBOb2Rlcz0xClsgICAgMC4wMDAwMDBdIEhpZXJhcmNo
aWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uClsgICAgMC4wMDAwMDBdIAlSQ1UgZHludGljay1p
ZGxlIGdyYWNlLXBlcmlvZCBhY2NlbGVyYXRpb24gaXMgZW5hYmxlZC4KWyAgICAwLjAwMDAw
MF0gTlJfSVJRUzo0MzUyIG5yX2lycXM6ODk2IDAKWyAgICAwLjAwMDAwMF0geGVuOmV2ZW50
czogVXNpbmcgRklGTy1iYXNlZCBBQkkKWyAgICAwLjAwMDAwMF0geGVuOmV2ZW50czogWGVu
IEhWTSBjYWxsYmFjayB2ZWN0b3IgZm9yIGV2ZW50IGRlbGl2ZXJ5IGlzIGVuYWJsZWQKWyAg
ICAwLjAwMDAwMF0gQ29uc29sZTogY29sb3VyIFZHQSsgODB4MjUKWyAgICAwLjAwMDAwMF0g
Y29uc29sZSBbdHR5MV0gZW5hYmxlZApbICAgIDAuMDAwMDAwXSBjb25zb2xlIFt0dHlTMF0g
ZW5hYmxlZApbICAgIDAuMDAwMDAwXSBocGV0IGNsb2NrZXZlbnQgcmVnaXN0ZXJlZApbICAg
IDAuMDAwMDAwXSB0c2M6IERldGVjdGVkIDMyMDAuMTU2IE1IeiBwcm9jZXNzb3IKWyAgICAw
LjAwMDAwMF0gdHNjOiBNYXJraW5nIFRTQyB1bnN0YWJsZSBkdWUgdG8gVFNDcyB1bnN5bmNo
cm9uaXplZApbICAgIDAuMDE2NjY2XSBDYWxpYnJhdGluZyBkZWxheSBsb29wIChza2lwcGVk
KSwgdmFsdWUgY2FsY3VsYXRlZCB1c2luZyB0aW1lciBmcmVxdWVuY3kuLiA2NDAyLjk5IEJv
Z29NSVBTIChscGo9MTA2NjcxODYpClsgICAgMC4wMjY2NzJdIHBpZF9tYXg6IGRlZmF1bHQ6
IDMyNzY4IG1pbmltdW06IDMwMQpbICAgIDAuMDMzMzQ4XSBBQ1BJOiBDb3JlIHJldmlzaW9u
IDIwMTQwOTI2ClsgICAgMC4wNDgwODZdIEFDUEk6IEFsbCBBQ1BJIFRhYmxlcyBzdWNjZXNz
ZnVsbHkgYWNxdWlyZWQKWyAgICAwLjA1NDg2MV0gRGVudHJ5IGNhY2hlIGhhc2ggdGFibGUg
ZW50cmllczogMTMxMDcyIChvcmRlcjogOCwgMTA0ODU3NiBieXRlcykKWyAgICAwLjA2MzU1
OV0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUy
NDI4OCBieXRlcykKWyAgICAwLjA3MzM5NF0gTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRy
aWVzOiAyMDQ4IChvcmRlcjogMiwgMTYzODQgYnl0ZXMpClsgICAgMC4wODAwMDhdIE1vdW50
cG9pbnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChvcmRlcjogMiwgMTYzODQg
Ynl0ZXMpClsgICAgMC4wOTAxNTBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGZyZWV6
ZXIKWyAgICAwLjA5MzM0M10gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgYmxraW8KWyAg
ICAwLjEwMDEzMl0gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6IDAKWyAgICAwLjEwNjY2
OV0gQ1BVOiBQcm9jZXNzb3IgQ29yZSBJRDogMApbICAgIDAuMTEwMDA3XSBtY2U6IENQVSBz
dXBwb3J0cyAyIE1DRSBiYW5rcwpbICAgIDAuMTE2NjkxXSBMYXN0IGxldmVsIGlUTEIgZW50
cmllczogNEtCIDUxMiwgMk1CIDE2LCA0TUIgOApbICAgIDAuMTE2NjkxXSBMYXN0IGxldmVs
IGRUTEIgZW50cmllczogNEtCIDUxMiwgMk1CIDEyOCwgNE1CIDY0LCAxR0IgMApbICAgIDAu
MTMwMjgyXSBGcmVlaW5nIFNNUCBhbHRlcm5hdGl2ZXMgbWVtb3J5OiA0MEsgKGZmZmZmZmZm
ODIxZTUwMDAgLSBmZmZmZmZmZjgyMWVmMDAwKQpbICAgIDAuMTQ4OTc4XSAuLlRJTUVSOiB2
ZWN0b3I9MHgzMCBhcGljMT0wIHBpbjE9MiBhcGljMj0wIHBpbjI9MApbICAgIDAuMTg5NTI5
XSBzbXBib290OiBDUFUwOiBBTUQgUGhlbm9tKHRtKSBJSSBYNiAxMDkwVCBQcm9jZXNzb3Ig
KGZhbTogMTAsIG1vZGVsOiAwYSwgc3RlcHBpbmc6IDAwKQpbICAgIDAuMjAyOTA0XSBYZW46
IHVzaW5nIHZjcHVvcCB0aW1lciBpbnRlcmZhY2UKWyAgICAwLjIwMjkxMV0gaW5zdGFsbGlu
ZyBYZW4gdGltZXIgZm9yIENQVSAwClsgICAgMC4yMDY3NDhdIGNwdSAwIHNwaW5sb2NrIGV2
ZW50IGlycSA1MwpbICAgIDAuMjE3MjY4XSBQZXJmb3JtYW5jZSBFdmVudHM6IEJyb2tlbiBQ
TVUgaGFyZHdhcmUgZGV0ZWN0ZWQsIHVzaW5nIHNvZnR3YXJlIGV2ZW50cyBvbmx5LgpbICAg
IDAuMjIzMzQxXSBGYWlsZWQgdG8gYWNjZXNzIHBlcmZjdHIgbXNyIChNU1IgYzAwMTAwMDQg
aXMgMCkKWyAgICAwLjIyNjkzNl0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAxClsg
ICAgMC4yMzAwNTNdIHg4NjogQm9vdGluZyBTTVAgY29uZmlndXJhdGlvbjoKWyAgICAwLjIz
MzM0MF0gLi4uLiBub2RlICAjMCwgQ1BVczogICAgICAjMWNwdSAxIHNwaW5sb2NrIGV2ZW50
IGlycSA1OQpbICAgIDAuMzM2Nzg5XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDIK
WyAgICAwLjM0MDA1OF0gICMyY3B1IDIgc3BpbmxvY2sgZXZlbnQgaXJxIDY1ClsgICAgMC40
NDAxMjddIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMwpbICAgIDAuNDQzMzk0XSAg
IzNjcHUgMyBzcGlubG9jayBldmVudCBpcnEgNzEKWyAgICAwLjU0MzM4MF0geDg2OiBCb290
ZWQgdXAgMSBub2RlLCA0IENQVXMKWyAgICAwLjU0NjY3Nl0gc21wYm9vdDogVG90YWwgb2Yg
NCBwcm9jZXNzb3JzIGFjdGl2YXRlZCAoMjU2MjguNzEgQm9nb01JUFMpClsgICAgMC41NTM0
NjVdIGRldnRtcGZzOiBpbml0aWFsaXplZApbICAgIDAuNTU2OTYzXSB4b3I6IG1lYXN1cmlu
ZyBzb2Z0d2FyZSBjaGVja3N1bSBzcGVlZApbICAgIDAuNTkzMzQyXSAgICBwcmVmZXRjaDY0
LXNzZTogICA4OTcuNjAwIE1CL3NlYwpbICAgIDAuNjMwMDA0XSAgICBnZW5lcmljX3NzZTog
ICA5MTIuMDAwIE1CL3NlYwpbICAgIDAuNjMzMzM4XSB4b3I6IHVzaW5nIGZ1bmN0aW9uOiBn
ZW5lcmljX3NzZSAoOTEyLjAwMCBNQi9zZWMpClsgICAgMC42MzY3NzNdIE5FVDogUmVnaXN0
ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKWyAgICAwLjY0MDIxM10geGVuYnVzOiB4c19yZXNl
dF93YXRjaGVzIGZhaWxlZDogLTM4ClsgICAgMC42NjMzNDddIGNwdWlkbGU6IHVzaW5nIGdv
dmVybm9yIGxhZGRlcgpbICAgIDAuNjg2Njk0XSBjcHVpZGxlOiB1c2luZyBnb3Zlcm5vciBt
ZW51ClsgICAgMC42OTY0MjldIEFDUEk6IGJ1cyB0eXBlIFBDSSByZWdpc3RlcmVkClsgICAg
MC43MDMzMzldIGFjcGlwaHA6IEFDUEkgSG90IFBsdWcgUENJIENvbnRyb2xsZXIgRHJpdmVy
IHZlcnNpb246IDAuNQpbICAgIDAuNzE0MTk5XSBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24g
dHlwZSAxIGZvciBiYXNlIGFjY2VzcwpbICAgIDAuNzIzMzQyXSBQQ0k6IFVzaW5nIGNvbmZp
Z3VyYXRpb24gdHlwZSAxIGZvciBleHRlbmRlZCBhY2Nlc3MKWyAgICAwLjgwNTMzOV0gcmFp
ZDY6IHNzZTJ4MSAgICAyOTI1IE1CL3MKWyAgICAwLjg2NTMxMV0gcmFpZDY6IHNzZTJ4MiAg
ICAzODk1IE1CL3MKWyAgICAwLjkyNTI4N10gcmFpZDY6IHNzZTJ4NCAgICAzOTQ4IE1CL3MK
WyAgICAwLjkzMDAwN10gcmFpZDY6IHVzaW5nIGFsZ29yaXRobSBzc2UyeDQgKDM5NDggTUIv
cykKWyAgICAwLjkzNjY3M10gcmFpZDY6IHVzaW5nIGludHgxIHJlY292ZXJ5IGFsZ29yaXRo
bQpbICAgIDAuOTQzNDI0XSBBQ1BJOiBBZGRlZCBfT1NJKE1vZHVsZSBEZXZpY2UpClsgICAg
MC45NTAwMDVdIEFDUEk6IEFkZGVkIF9PU0koUHJvY2Vzc29yIERldmljZSkKWyAgICAwLjk1
NjY3N10gQUNQSTogQWRkZWQgX09TSSgzLjAgX1NDUCBFeHRlbnNpb25zKQpbICAgIDAuOTYw
MDA1XSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBBZ2dyZWdhdG9yIERldmljZSkKWyAg
ICAwLjk3NjYwNF0gQUNQSTogSW50ZXJwcmV0ZXIgZW5hYmxlZApbICAgIDAuOTgzMzQyXSBB
Q1BJOiAoc3VwcG9ydHMgUzAgUzUpClsgICAgMC45ODY2NzZdIEFDUEk6IFVzaW5nIElPQVBJ
QyBmb3IgaW50ZXJydXB0IHJvdXRpbmcKWyAgICAwLjk5MzM5M10gUENJOiBVc2luZyBob3N0
IGJyaWRnZSB3aW5kb3dzIGZyb20gQUNQSTsgaWYgbmVjZXNzYXJ5LCB1c2UgInBjaT1ub2Ny
cyIgYW5kIHJlcG9ydCBhIGJ1ZwpbICAgIDEuMDI3NDQwXSBBQ1BJOiBQQ0kgUm9vdCBCcmlk
Z2UgW1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkKWyAgICAxLjAzMDAxMV0gYWNw
aSBQTlAwQTAzOjAwOiBfT1NDOiBPUyBzdXBwb3J0cyBbRXh0ZW5kZWRDb25maWcgQVNQTSBD
bG9ja1BNIFNlZ21lbnRzIE1TSV0KWyAgICAxLjAzMzM0N10gYWNwaSBQTlAwQTAzOjAwOiBf
T1NDIGZhaWxlZCAoQUVfTk9UX0ZPVU5EKTsgZGlzYWJsaW5nIEFTUE0KWyAgICAxLjAzNzYx
M10gYWNwaXBocDogU2xvdCBbM10gcmVnaXN0ZXJlZApbICAgIDEuMDQwMTA4XSBhY3BpcGhw
OiBTbG90IFs0XSByZWdpc3RlcmVkClsgICAgMS4wNDM0MzhdIGFjcGlwaHA6IFNsb3QgWzVd
IHJlZ2lzdGVyZWQKWyAgICAxLjA0Njc4MF0gYWNwaXBocDogU2xvdCBbNl0gcmVnaXN0ZXJl
ZApbICAgIDEuMDUwMTA1XSBhY3BpcGhwOiBTbG90IFs3XSByZWdpc3RlcmVkClsgICAgMS4w
NTM0MzddIGFjcGlwaHA6IFNsb3QgWzhdIHJlZ2lzdGVyZWQKWyAgICAxLjA1Njc3NF0gYWNw
aXBocDogU2xvdCBbOV0gcmVnaXN0ZXJlZApbICAgIDEuMDYwMTQ2XSBhY3BpcGhwOiBTbG90
IFsxMF0gcmVnaXN0ZXJlZApbICAgIDEuMDYzNDQxXSBhY3BpcGhwOiBTbG90IFsxMV0gcmVn
aXN0ZXJlZApbICAgIDEuMDY2NzUyXSBhY3BpcGhwOiBTbG90IFsxMl0gcmVnaXN0ZXJlZApb
ICAgIDEuMDcwMTA5XSBhY3BpcGhwOiBTbG90IFsxM10gcmVnaXN0ZXJlZApbICAgIDEuMDcz
NDUxXSBhY3BpcGhwOiBTbG90IFsxNF0gcmVnaXN0ZXJlZApbICAgIDEuMDc2NzYyXSBhY3Bp
cGhwOiBTbG90IFsxNV0gcmVnaXN0ZXJlZApbICAgIDEuMDgwMDkwXSBhY3BpcGhwOiBTbG90
IFsxNl0gcmVnaXN0ZXJlZApbICAgIDEuMDgzNDE1XSBhY3BpcGhwOiBTbG90IFsxN10gcmVn
aXN0ZXJlZApbICAgIDEuMDg2NzgyXSBhY3BpcGhwOiBTbG90IFsxOF0gcmVnaXN0ZXJlZApb
ICAgIDEuMDkwMDk1XSBhY3BpcGhwOiBTbG90IFsxOV0gcmVnaXN0ZXJlZApbICAgIDEuMDkz
NDI0XSBhY3BpcGhwOiBTbG90IFsyMF0gcmVnaXN0ZXJlZApbICAgIDEuMDk2Nzc2XSBhY3Bp
cGhwOiBTbG90IFsyMV0gcmVnaXN0ZXJlZApbICAgIDEuMTAwMTAwXSBhY3BpcGhwOiBTbG90
IFsyMl0gcmVnaXN0ZXJlZApbICAgIDEuMTAzNDI5XSBhY3BpcGhwOiBTbG90IFsyM10gcmVn
aXN0ZXJlZApbICAgIDEuMTA2ODQ0XSBhY3BpcGhwOiBTbG90IFsyNF0gcmVnaXN0ZXJlZApb
ICAgIDEuMTEwMDg2XSBhY3BpcGhwOiBTbG90IFsyNV0gcmVnaXN0ZXJlZApbICAgIDEuMTEz
NDIyXSBhY3BpcGhwOiBTbG90IFsyNl0gcmVnaXN0ZXJlZApbICAgIDEuMTE2Nzc2XSBhY3Bp
cGhwOiBTbG90IFsyN10gcmVnaXN0ZXJlZApbICAgIDEuMTIwMDk5XSBhY3BpcGhwOiBTbG90
IFsyOF0gcmVnaXN0ZXJlZApbICAgIDEuMTIzNDI2XSBhY3BpcGhwOiBTbG90IFsyOV0gcmVn
aXN0ZXJlZApbICAgIDEuMTI2NzQ4XSBhY3BpcGhwOiBTbG90IFszMF0gcmVnaXN0ZXJlZApb
ICAgIDEuMTMwMDk3XSBhY3BpcGhwOiBTbG90IFszMV0gcmVnaXN0ZXJlZApbICAgIDEuMTMz
NDA0XSBQQ0kgaG9zdCBicmlkZ2UgdG8gYnVzIDAwMDA6MDAKWyAgICAxLjEzNjY3OF0gcGNp
X2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbYnVzIDAwLWZmXQpbICAgIDEuMTQw
MDEwXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFtpbyAgMHgwMDAwLTB4
MGNmN10KWyAgICAxLjE0MzM0M10gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJj
ZSBbaW8gIDB4MGQwMC0weGZmZmZdClsgICAgMS4xNDY2NzhdIHBjaV9idXMgMDAwMDowMDog
cm9vdCBidXMgcmVzb3VyY2UgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsgICAgMS4x
NTAwMTBdIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW21lbSAweGYwMDAw
MDAwLTB4ZmJmZmZmZmZdClsgICAgMS4xNTM2NDRdIHBjaSAwMDAwOjAwOjAwLjA6IFs4MDg2
OjEyMzddIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAKWyAgICAxLjE1NzgzMF0gcGNpIDAwMDA6
MDA6MDEuMDogWzgwODY6NzAwMF0gdHlwZSAwMCBjbGFzcyAweDA2MDEwMApbICAgIDEuMTYx
Mjc4XSBwY2kgMDAwMDowMDowMS4xOiBbODA4Njo3MDEwXSB0eXBlIDAwIGNsYXNzIDB4MDEw
MTgwClsgICAgMS4xNzg4NzBdIHBjaSAwMDAwOjAwOjAxLjE6IHJlZyAweDIwOiBbaW8gIDB4
YzE2MC0weGMxNmZdClsgICAgMS4xODU4NjBdIHBjaSAwMDAwOjAwOjAxLjE6IGxlZ2FjeSBJ
REUgcXVpcms6IHJlZyAweDEwOiBbaW8gIDB4MDFmMC0weDAxZjddClsgICAgMS4xODY2NzVd
IHBjaSAwMDAwOjAwOjAxLjE6IGxlZ2FjeSBJREUgcXVpcms6IHJlZyAweDE0OiBbaW8gIDB4
MDNmNl0KWyAgICAxLjE5MDAwNV0gcGNpIDAwMDA6MDA6MDEuMTogbGVnYWN5IElERSBxdWly
azogcmVnIDB4MTg6IFtpbyAgMHgwMTcwLTB4MDE3N10KWyAgICAxLjE5MzMzOV0gcGNpIDAw
MDA6MDA6MDEuMTogbGVnYWN5IElERSBxdWlyazogcmVnIDB4MWM6IFtpbyAgMHgwMzc2XQpb
ICAgIDEuMTk3NTA3XSBwY2kgMDAwMDowMDowMS4yOiBbODA4Njo3MDIwXSB0eXBlIDAwIGNs
YXNzIDB4MGMwMzAwClsgICAgMS4yMTU1NjFdIHBjaSAwMDAwOjAwOjAxLjI6IHJlZyAweDIw
OiBbaW8gIDB4YzE0MC0weGMxNWZdClsgICAgMS4yMjMyNTVdIHBjaSAwMDAwOjAwOjAxLjM6
IFs4MDg2OjcxMTNdIHR5cGUgMDAgY2xhc3MgMHgwNjgwMDAKWyAgICAxLjIyNjMwNl0gcGNp
IDAwMDA6MDA6MDEuMzogcXVpcms6IFtpbyAgMHhiMDAwLTB4YjAzZl0gY2xhaW1lZCBieSBQ
SUlYNCBBQ1BJClsgICAgMS4yMjY3NDJdIHBjaSAwMDAwOjAwOjAxLjM6IHF1aXJrOiBbaW8g
IDB4YjEwMC0weGIxMGZdIGNsYWltZWQgYnkgUElJWDQgU01CClsgICAgMS4yMzE0MDZdIHBj
aSAwMDAwOjAwOjAyLjA6IFs1ODUzOjAwMDFdIHR5cGUgMDAgY2xhc3MgMHhmZjgwMDAKWyAg
ICAxLjIzNjY3NV0gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDB4MTA6IFtpbyAgMHhjMDAwLTB4
YzBmZl0KWyAgICAxLjI0MzM0M10gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDB4MTQ6IFttZW0g
MHhmMjAwMDAwMC0weGYyZmZmZmZmIHByZWZdClsgICAgMS4yNzc3NjhdIHBjaSAwMDAwOjAw
OjAzLjA6IFsxMDEzOjAwYjhdIHR5cGUgMDAgY2xhc3MgMHgwMzAwMDAKWyAgICAxLjI4MzM2
N10gcGNpIDAwMDA6MDA6MDMuMDogcmVnIDB4MTA6IFttZW0gMHhmMDAwMDAwMC0weGYxZmZm
ZmZmIHByZWZdClsgICAgMS4yOTAwMDldIHBjaSAwMDAwOjAwOjAzLjA6IHJlZyAweDE0OiBb
bWVtIDB4ZjMyNzIwMDAtMHhmMzI3MmZmZl0KWyAgICAxLjMyMzM0M10gcGNpIDAwMDA6MDA6
MDMuMDogcmVnIDB4MzA6IFttZW0gMHhmMzI2MDAwMC0weGYzMjZmZmZmIHByZWZdClsgICAg
MS4zMjUyNTddIHBjaSAwMDAwOjAwOjA1LjA6IFsxMDMzOjAxOTRdIHR5cGUgMDAgY2xhc3Mg
MHgwYzAzMzAKWyAgICAxLjMzMzM1MF0gcGNpIDAwMDA6MDA6MDUuMDogcmVnIDB4MTA6IFtt
ZW0gMHhmMzI3MDAwMC0weGYzMjcxZmZmIDY0Yml0XQpbICAgIDEuMzcxMzgwXSBwY2kgMDAw
MDowMDowNi4wOiBbMTRmMTo4MjEwXSB0eXBlIDAwIGNsYXNzIDB4MDQwMDAwClsgICAgMS4z
NzY2ODNdIHBjaSAwMDAwOjAwOjA2LjA6IHJlZyAweDEwOiBbbWVtIDB4ZjMwMDAwMDAtMHhm
MzFmZmZmZiA2NGJpdF0KWyAgICAxLjQxMzM0M10gcGNpIDAwMDA6MDA6MDYuMDogc3VwcG9y
dHMgRDEgRDIKWyAgICAxLjQxNjMzOV0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktB
XSAoSVJRcyAqNSAxMCAxMSkKWyAgICAxLjQyMzEwNF0gQUNQSTogUENJIEludGVycnVwdCBM
aW5rIFtMTktCXSAoSVJRcyA1ICoxMCAxMSkKWyAgICAxLjQyOTUyNl0gQUNQSTogUENJIElu
dGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyA1IDEwICoxMSkKWyAgICAxLjQzNjMwM10gQUNQ
STogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyAqNSAxMCAxMSkKWyAgICAxLjQ0
MzExMV0gQUNQSTogRW5hYmxlZCAyIEdQRXMgaW4gYmxvY2sgMDAgdG8gMEYKWyAgICAxLjQ0
MzQwN10geGVuOmJhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlcgpbICAgIDEu
NDUwMDQ1XSB4ZW5fYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24gZHJpdmVyClsgICAg
MS40NjY4NjFdIHZnYWFyYjogc2V0dGluZyBhcyBib290IGRldmljZTogUENJOjAwMDA6MDA6
MDMuMApbICAgIDEuNDY5OTk5XSB2Z2FhcmI6IGRldmljZSBhZGRlZDogUENJOjAwMDA6MDA6
MDMuMCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nrcz1ub25lClsgICAgMS40OTAw
MjldIHZnYWFyYjogbG9hZGVkClsgICAgMS40OTMzNDFdIHZnYWFyYjogYnJpZGdlIGNvbnRy
b2wgcG9zc2libGUgMDAwMDowMDowMy4wClsgICAgMS41MDAxMTFdIFNDU0kgc3Vic3lzdGVt
IGluaXRpYWxpemVkClsgICAgMS41MDY3MDBdIGxpYmF0YSB2ZXJzaW9uIDMuMDAgbG9hZGVk
LgpbICAgIDEuNTA2NzU2XSBBQ1BJOiBidXMgdHlwZSBVU0IgcmVnaXN0ZXJlZApbICAgIDEu
NTEzNDA1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmZz
ClsgICAgMS41MjMzOTldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgaHViClsgICAgMS41MzAwNjFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRldmljZSBk
cml2ZXIgdXNiClsgICAgMS41MzY3MzNdIExpbnV4IHZpZGVvIGNhcHR1cmUgaW50ZXJmYWNl
OiB2Mi4wMApbICAgIDEuNTQzMzg5XSBwcHNfY29yZTogTGludXhQUFMgQVBJIHZlci4gMSBy
ZWdpc3RlcmVkClsgICAgMS41NTAwMDddIHBwc19jb3JlOiBTb2Z0d2FyZSB2ZXIuIDUuMy42
IC0gQ29weXJpZ2h0IDIwMDUtMjAwNyBSb2RvbGZvIEdpb21ldHRpIDxnaW9tZXR0aUBsaW51
eC5pdD4KWyAgICAxLjU2MDAzOF0gUFRQIGNsb2NrIHN1cHBvcnQgcmVnaXN0ZXJlZApbICAg
IDEuNTY2NzQwXSBBZHZhbmNlZCBMaW51eCBTb3VuZCBBcmNoaXRlY3R1cmUgRHJpdmVyIElu
aXRpYWxpemVkLgpbICAgIDEuNTczMzQzXSBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0
aW5nClsgICAgMS41ODAwMDldIFBDSTogcGNpX2NhY2hlX2xpbmVfc2l6ZSBzZXQgdG8gNjQg
Ynl0ZXMKWyAgICAxLjU4MTMwNF0gZTgyMDogcmVzZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHgw
MDA5ZmMwMC0weDAwMDlmZmZmXQpbICAgIDEuNTgxMzA2XSBlODIwOiByZXNlcnZlIFJBTSBi
dWZmZXIgW21lbSAweDNmN2ZlMDAwLTB4M2ZmZmZmZmZdClsgICAgMS41ODE0MjddIEJsdWV0
b290aDogQ29yZSB2ZXIgMi4xOQpbICAgIDEuNTg2Njk0XSBORVQ6IFJlZ2lzdGVyZWQgcHJv
dG9jb2wgZmFtaWx5IDMxClsgICAgMS41OTAwMDRdIEJsdWV0b290aDogSENJIGRldmljZSBh
bmQgY29ubmVjdGlvbiBtYW5hZ2VyIGluaXRpYWxpemVkClsgICAgMS42MDAwMTVdIEJsdWV0
b290aDogSENJIHNvY2tldCBsYXllciBpbml0aWFsaXplZApbICAgIDEuNjA2NjgwXSBCbHVl
dG9vdGg6IEwyQ0FQIHNvY2tldCBsYXllciBpbml0aWFsaXplZApbICAgIDEuNjEzMzQ2XSBC
bHVldG9vdGg6IFNDTyBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgICAxLjYyMDA5NV0g
SFBFVDogMyB0aW1lcnMgaW4gdG90YWwsIDAgdGltZXJzIHdpbGwgYmUgdXNlZCBmb3IgcGVy
LWNwdSB0aW1lcgpbICAgIDEuNjI2NjkwXSBocGV0MDogYXQgTU1JTyAweGZlZDAwMDAwLCBJ
UlFzIDIsIDgsIDAKWyAgICAxLjYzODQ1N10gaHBldDA6IDMgY29tcGFyYXRvcnMsIDY0LWJp
dCA2Mi41MDAwMDAgTUh6IGNvdW50ZXIKWyAgICAxLjY1MDA2Nl0gU3dpdGNoZWQgdG8gY2xv
Y2tzb3VyY2UgeGVuClsgICAgMS42NTU2NDBdIEZTLUNhY2hlOiBMb2FkZWQKWyAgICAxLjY1
OTk2MF0gcG5wOiBQblAgQUNQSSBpbml0ClsgICAgMS42NjQ1OThdIHN5c3RlbSAwMDowMDog
W21lbSAweDAwMDAwMDAwLTB4MDAwOWZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAg
IDEuNjcyNjczXSBzeXN0ZW0gMDA6MDA6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElE
cyBQTlAwYzAyIChhY3RpdmUpClsgICAgMS42NzI3NzRdIHN5c3RlbSAwMDowMTogW2lvICAw
eDA4YTAtMHgwOGEzXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDEuNjg1MjE0XSBzeXN0ZW0g
MDA6MDE6IFtpbyAgMHgwY2MwLTB4MGNjZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAxLjY5
MjU3N10gc3lzdGVtIDAwOjAxOiBbaW8gIDB4MDRkMC0weDA0ZDFdIGhhcyBiZWVuIHJlc2Vy
dmVkClsgICAgMS42OTk2ODNdIHN5c3RlbSAwMDowMTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRl
dmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAxLjY5OTcxNV0geGVuOiAtLT4gcGly
cT0xNiAtPiBpcnE9OCAoZ3NpPTgpClsgICAgMS42OTk3MzRdIHBucCAwMDowMjogUGx1ZyBh
bmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBiMDAgKGFjdGl2ZSkKWyAgICAxLjY5OTc3
N10geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTIgKGdzaT0xMikKWyAgICAxLjY5OTc5MF0g
cG5wIDAwOjAzOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGYxMyAoYWN0
aXZlKQpbICAgIDEuNjk5ODA5XSB4ZW46IC0tPiBwaXJxPTE4IC0+IGlycT0xIChnc2k9MSkK
WyAgICAxLjY5OTgxOV0gcG5wIDAwOjA0OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJ
RHMgUE5QMDMwMyBQTlAwMzBiIChhY3RpdmUpClsgICAgMS42OTk4NDBdIHhlbjogLS0+IHBp
cnE9MTkgLT4gaXJxPTYgKGdzaT02KQpbICAgIDEuNjk5ODQzXSBwbnAgMDA6MDU6IFtkbWEg
Ml0KWyAgICAxLjY5OTg1OF0gcG5wIDAwOjA1OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNl
LCBJRHMgUE5QMDcwMCAoYWN0aXZlKQpbICAgIDEuNjk5ODg5XSB4ZW46IC0tPiBwaXJxPTIw
IC0+IGlycT00IChnc2k9NCkKWyAgICAxLjY5OTkxM10gcG5wIDAwOjA2OiBQbHVnIGFuZCBQ
bGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDUwMSAoYWN0aXZlKQpbICAgIDEuNjk5OTc1XSBz
eXN0ZW0gMDA6MDc6IFtpbyAgMHhhZTAwLTB4YWUwZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAg
ICAxLjcwNzIxOV0gc3lzdGVtIDAwOjA3OiBbaW8gIDB4YjA0NC0weGIwNDddIGhhcyBiZWVu
IHJlc2VydmVkClsgICAgMS43MTQ1MDJdIHN5c3RlbSAwMDowNzogUGx1ZyBhbmQgUGxheSBB
Q1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAxLjcxNDg3Nl0gcG5wOiBQ
blAgQUNQSTogZm91bmQgOCBkZXZpY2VzClsgICAgMS43MjkyNDJdIHBjaV9idXMgMDAwMDow
MDogcmVzb3VyY2UgNCBbaW8gIDB4MDAwMC0weDBjZjddClsgICAgMS43MjkyNDVdIHBjaV9i
dXMgMDAwMDowMDogcmVzb3VyY2UgNSBbaW8gIDB4MGQwMC0weGZmZmZdClsgICAgMS43Mjky
NDddIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNiBbbWVtIDB4MDAwYTAwMDAtMHgwMDBi
ZmZmZl0KWyAgICAxLjcyOTI0OF0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA3IFttZW0g
MHhmMDAwMDAwMC0weGZiZmZmZmZmXQpbICAgIDEuNzI5MjcyXSBORVQ6IFJlZ2lzdGVyZWQg
cHJvdG9jb2wgZmFtaWx5IDIKWyAgICAxLjczNTM2NF0gVENQIGVzdGFibGlzaGVkIGhhc2gg
dGFibGUgZW50cmllczogODE5MiAob3JkZXI6IDQsIDY1NTM2IGJ5dGVzKQpbICAgIDEuNzQ0
MDQ0XSBUQ1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDgxOTIgKG9yZGVyOiA1LCAxMzEw
NzIgYnl0ZXMpClsgICAgMS43NTE5MzddIFRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJlZCAo
ZXN0YWJsaXNoZWQgODE5MiBiaW5kIDgxOTIpClsgICAgMS43NTk5MjJdIFRDUDogcmVubyBy
ZWdpc3RlcmVkClsgICAgMS43NjQ1MDRdIFVEUCBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMiAo
b3JkZXI6IDIsIDE2Mzg0IGJ5dGVzKQpbICAgIDEuNzcxODA3XSBVRFAtTGl0ZSBoYXNoIHRh
YmxlIGVudHJpZXM6IDUxMiAob3JkZXI6IDIsIDE2Mzg0IGJ5dGVzKQpbICAgIDEuNzgwMjU4
XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEKWyAgICAxLjc4NjA1OF0gcGNp
IDAwMDA6MDA6MDAuMDogTGltaXRpbmcgZGlyZWN0IFBDSS9QQ0kgdHJhbnNmZXJzClsgICAg
MS43OTMzMDldIHBjaSAwMDAwOjAwOjAxLjA6IFBJSVgzOiBFbmFibGluZyBQYXNzaXZlIFJl
bGVhc2UKWyAgICAxLjgwMDY3M10gcGNpIDAwMDA6MDA6MDEuMDogQWN0aXZhdGluZyBJU0Eg
RE1BIGhhbmcgd29ya2Fyb3VuZHMKWyAgICAxLjgwODg2MV0geGVuOiAtLT4gcGlycT0yMSAt
PiBpcnE9MjMgKGdzaT0yMykKWyAgICAxLjgxMjAwN10gcGNpIDAwMDA6MDA6MDMuMDogVmlk
ZW8gZGV2aWNlIHdpdGggc2hhZG93ZWQgUk9NClsgICAgMS44MTIzODldIHhlbjogLS0+IHBp
cnE9MzcgLT4gaXJxPTM2IChnc2k9MzYpClsgICAgMS44MTQ2OTNdIFBDSTogQ0xTIDAgYnl0
ZXMsIGRlZmF1bHQgNjQKWyAgICAxLjgxNDczMF0gVHJ5aW5nIHRvIHVucGFjayByb290ZnMg
aW1hZ2UgYXMgaW5pdHJhbWZzLi4uClsgICAgMS44NDU1NzBdIEZyZWVpbmcgaW5pdHJkIG1l
bW9yeTogMTg3MksgKGZmZmY4ODAwMzdjNDgwMDAgLSBmZmZmODgwMDM3ZTFjMDAwKQpbICAg
IDEuODU2MDQ1XSBTY2FubmluZyBmb3IgbG93IG1lbW9yeSBjb3JydXB0aW9uIGV2ZXJ5IDYw
IHNlY29uZHMKWyAgICAxLjg2NTk0Nl0gc2hhMV9zc3NlMzogTmVpdGhlciBBVlggbm9yIEFW
WDIgbm9yIFNTU0UzIGlzIGF2YWlsYWJsZS91c2FibGUuClsgICAgMS44NzQ2MjBdIEFWWCBv
ciBBRVMtTkkgaW5zdHJ1Y3Rpb25zIGFyZSBub3QgZGV0ZWN0ZWQuClsgICAgMS44ODEyODZd
IEFWWCBpbnN0cnVjdGlvbnMgYXJlIG5vdCBkZXRlY3RlZC4KWyAgICAxLjg4NzMzMl0gQVZY
IGluc3RydWN0aW9ucyBhcmUgbm90IGRldGVjdGVkLgpbICAgIDEuODkzMTcyXSBmdXRleCBo
YXNoIHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiA1LCAxMzEwNzIgYnl0ZXMpClsgICAg
MS45MDExMjldIGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0bGluayBzdWJzeXMgKGRpc2FibGVk
KQpbICAgIDEuOTA4MDAzXSBhdWRpdDogdHlwZT0yMDAwIGF1ZGl0KDE0MTYyNjE0ODkuMDk3
OjEpOiBpbml0aWFsaXplZApbICAgIDEuOTE1NTU3XSBIdWdlVExCIHJlZ2lzdGVyZWQgMiBN
QiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcwpbICAgIDEuOTI1MTE2XSBWRlM6
IERpc2sgcXVvdGFzIGRxdW90XzYuNS4yClsgICAgMS45MzA3NTJdIERxdW90LWNhY2hlIGhh
c2ggdGFibGUgZW50cmllczogNTEyIChvcmRlciAwLCA0MDk2IGJ5dGVzKQpbICAgIDEuOTM5
NDA0XSBudGZzOiBkcml2ZXIgMi4xLjMxIFtGbGFnczogUi9XXS4KWyAgICAxLjk0NTQyN10g
ZnVzZSBpbml0IChBUEkgdmVyc2lvbiA3LjIzKQpbICAgIDEuOTUxNzA1XSBnZnMyOiBHRlMy
IGluc3RhbGxlZApbICAgIDEuOTU2Mzk1XSBjZXBoOiBsb2FkZWQgKG1kcyBwcm90byAzMikK
WyAgICAxLjk2MTU0N10gbXNnbW5pIGhhcyBiZWVuIHNldCB0byAxOTU5ClsgICAgMS45Njky
MjFdIGJvdW5jZTogcG9vbCBzaXplOiA2NCBwYWdlcwpbICAgIDEuOTc0NjQ1XSBCbG9jayBs
YXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFq
b3IgMjUwKQpbICAgIDEuOTg0NzQwXSBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkClsg
ICAgMS45OTAzNjJdIGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdpc3RlcmVkClsgICAgMS45
OTY0NzldIGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVsdCkKWyAgICAyLjAw
MzA2N10gY3JjMzI6IENSQ19MRV9CSVRTID0gNjQsIENSQ19CRSBCSVRTID0gNjQKWyAgICAy
LjAwOTQ0NV0gY3JjMzI6IHNlbGYgdGVzdHMgcGFzc2VkLCBwcm9jZXNzZWQgMjI1OTQ0IGJ5
dGVzIGluIDEwOTI2NiBuc2VjClsgICAgMi4wMTgyMjBdIGNyYzMyYzogQ1JDX0xFX0JJVFMg
PSA2NApbICAgIDIuMDIzMTQ1XSBjcmMzMmM6IHNlbGYgdGVzdHMgcGFzc2VkLCBwcm9jZXNz
ZWQgMjI1OTQ0IGJ5dGVzIGluIDYxNTkzIG5zZWMKWyAgICAyLjA0MDc4Ml0gY3JjMzJfY29t
YmluZTogODM3MyBzZWxmIHRlc3RzIHBhc3NlZApbICAgIDIuMDU2MjY4XSBjcmMzMmNfY29t
YmluZTogODM3MyBzZWxmIHRlc3RzIHBhc3NlZApbICAgIDIuMDYyNzMyXSBwY2lfaG90cGx1
ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAuNQpbICAgIDIuMDY5Nzg5XSBw
Y2llaHA6IFBDSSBFeHByZXNzIEhvdCBQbHVnIENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246
IDAuNApbICAgIDIuMDc3NzUxXSBjcGNpaHBfenQ1NTUwOiBaVDU1NTAgQ29tcGFjdFBDSSBI
b3QgUGx1ZyBEcml2ZXIgdmVyc2lvbjogMC4yClsgICAgMi4wODU4NDFdIGNwY2locF9nZW5l
cmljOiBHZW5lcmljIHBvcnQgSS9PIENvbXBhY3RQQ0kgSG90IFBsdWcgRHJpdmVyIHZlcnNp
b246IDAuMQpbICAgIDIuMDk1MjcwXSBjcGNpaHBfZ2VuZXJpYzogbm90IGNvbmZpZ3VyZWQs
IGRpc2FibGluZy4KWyAgICAyLjEwMjIyNl0gc2hwY2hwOiBTdGFuZGFyZCBIb3QgUGx1ZyBQ
Q0kgQ29udHJvbGxlciBEcml2ZXIgdmVyc2lvbjogMC40ClsgICAgMi4xMTExMDVdIGFjcGlw
aHBfaWJtOiBpYm1fYWNwaXBocF9pbml0OiBhY3BpX3dhbGtfbmFtZXNwYWNlIGZhaWxlZApb
ICAgIDIuMTE5NTI4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVy
IHVkbGZiClsgICAgMi4xMjcwMzBdIGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2RldmljZXMv
TE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQwClsgICAgMi4xMzcxNDBdIEFD
UEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0KWyAgICAyLjE0MjE4M10gaW5wdXQ6IFNsZWVwIEJ1
dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhTTFBCTjowMC9pbnB1dC9pbnB1dDEK
WyAgICAyLjE1MjAyNV0gQUNQSTogU2xlZXAgQnV0dG9uIFtTTFBGXQpbICAgIDIuMTU3ODI1
XSB4ZW46eGVuX2V2dGNobjogRXZlbnQtY2hhbm5lbCBkZXZpY2UgaW5zdGFsbGVkClsgICAg
Mi4xNjUyNjJdIHhlbjogLS0+IHBpcnE9MjIgLT4gaXJxPTI0IChnc2k9MjQpClsgICAgMi4x
NjU0NTddIHhlbjpncmFudF90YWJsZTogR3JhbnQgdGFibGVzIHVzaW5nIHZlcnNpb24gMSBs
YXlvdXQKWyAgICAyLjE3Mjg4MF0gR3JhbnQgdGFibGUgaW5pdGlhbGl6ZWQKWyAgICAyLjE3
ODM3Nl0gU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcg
ZW5hYmxlZApbICAgIDIuMjI2MDMxXSBzZXJpYWwgMDA6MDY6IHR0eVMwIGF0IEkvTyAweDNm
OCAoaXJxID0gNCwgYmFzZV9iYXVkID0gMTE1MjAwKSBpcyBhIDE2NTUwQQpbICAgIDIuMjM3
MzI3XSBMaW51eCBhZ3BnYXJ0IGludGVyZmFjZSB2MC4xMDMKWyAgICAyLjI0MjkwNF0gSGFu
Z2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sgdGltZXIgMC45LjEgKHRpY2sgaXMgMTgwIHNl
Y29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRzKS4KWyAgICAyLjI1NDg4Nl0gW2RybV0gSW5p
dGlhbGl6ZWQgZHJtIDEuMS4wIDIwMDYwODEwClsgICAgMi4yNjExODhdIFtkcm1dIFZHQUNP
TiBkaXNhYmxlIHJhZGVvbiBrZXJuZWwgbW9kZXNldHRpbmcuClsgICAgMi4yNjg1NDNdIFtk
cm06cmFkZW9uX2luaXRdICpFUlJPUiogTm8gVU1TIHN1cHBvcnQgaW4gcmFkZW9uIG1vZHVs
ZSEKWyAgICAyLjI3ODAyM10gYnJkOiBtb2R1bGUgbG9hZGVkClsgICAgMi4yODM4MTJdIGxv
b3A6IG1vZHVsZSBsb2FkZWQKWyAgICAyLjI5NDUwN10gdHVuOiBVbml2ZXJzYWwgVFVOL1RB
UCBkZXZpY2UgZHJpdmVyLCAxLjYKWyAgICAyLjMwMTY1OV0gYmxrZnJvbnQ6IHh2ZGE6IGZs
dXNoIGRpc2tjYWNoZTogZW5hYmxlZDsgcGVyc2lzdGVudCBncmFudHM6IGVuYWJsZWQ7IGlu
ZGlyZWN0IGRlc2NyaXB0b3JzOiBlbmFibGVkOwpbICAgIDIuMzE4MzU1XSB0dW46IChDKSAx
OTk5LTIwMDQgTWF4IEtyYXNueWFuc2t5IDxtYXhrQHF1YWxjb21tLmNvbT4KWyAgICAyLjMy
MjQ1N10gIHh2ZGE6IHh2ZGExIHh2ZGEyClsgICAgMi4zMjQyMDJdIGJsa2Zyb250OiB4dmRi
OiBmbHVzaCBkaXNrY2FjaGU6IGVuYWJsZWQ7IHBlcnNpc3RlbnQgZ3JhbnRzOiBlbmFibGVk
OyBpbmRpcmVjdCBkZXNjcmlwdG9yczogZW5hYmxlZDsKWyAgICAyLjMzMzA3MV0gIHh2ZGI6
IHVua25vd24gcGFydGl0aW9uIHRhYmxlClsgICAgMi4zNTE4MzJdIGUxMDAwOiBJbnRlbChS
KSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gNy4zLjIxLWs4LU5BUEkKWyAg
ICAyLjM2MDc2OF0gZTEwMDA6IENvcHlyaWdodCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBv
cmF0aW9uLgpbICAgIDIuMzY4MDA0XSBlMTAwMGU6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdv
cmsgRHJpdmVyIC0gMi4zLjItawpbICAgIDIuMzc1NzQ2XSBlMTAwMGU6IENvcHlyaWdodChj
KSAxOTk5IC0gMjAxNCBJbnRlbCBDb3Jwb3JhdGlvbi4KWyAgICAyLjM4MzkwMV0gaWdiOiBJ
bnRlbChSKSBHaWdhYml0IEV0aGVybmV0IE5ldHdvcmsgRHJpdmVyIC0gdmVyc2lvbiA1LjIu
MTUtawpbICAgIDIuMzkzNjg1XSBpZ2I6IENvcHlyaWdodCAoYykgMjAwNy0yMDE0IEludGVs
IENvcnBvcmF0aW9uLgpbICAgIDIuNDAwOTc1XSBpZ2J2ZjogSW50ZWwoUikgR2lnYWJpdCBW
aXJ0dWFsIEZ1bmN0aW9uIE5ldHdvcmsgRHJpdmVyIC0gdmVyc2lvbiAyLjAuMi1rClsgICAg
Mi40MTEyNDddIGlnYnZmOiBDb3B5cmlnaHQgKGMpIDIwMDkgLSAyMDEyIEludGVsIENvcnBv
cmF0aW9uLgpbICAgIDIuNDE4NzkzXSB4ZW5fbmV0ZnJvbnQ6IEluaXRpYWxpc2luZyBYZW4g
dmlydHVhbCBldGhlcm5ldCBkcml2ZXIKWyAgICAyLjQzMTA2Ml0geGhjaV9oY2QgMDAwMDow
MDowNS4wOiB4SENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDIuNDM5NDIwXSB4aGNpX2hjZCAw
MDAwOjAwOjA1LjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1i
ZXIgMQpbICAgIDIuNDU2MDM4XSB1c2IgdXNiMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlk
VmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyClsgICAgMi40NjQ3MTddIHVzYiB1c2IxOiBO
ZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9
MQpbICAgIDIuNDczODg4XSB1c2IgdXNiMTogUHJvZHVjdDogeEhDSSBIb3N0IENvbnRyb2xs
ZXIKWyAgICAyLjQ4MDM5N10gdXNiIHVzYjE6IE1hbnVmYWN0dXJlcjogTGludXggMy4xOC4w
LXJjNC0yMDE0MTExNi1zZWN1cml0eSsgeGhjaS1oY2QKWyAgICAyLjQ4OTgxOF0gdXNiIHVz
YjE6IFNlcmlhbE51bWJlcjogMDAwMDowMDowNS4wClsgICAgMi40OTYyMzldIGh1YiAxLTA6
MS4wOiBVU0IgaHViIGZvdW5kClsgICAgMi41MDE2MzNdIGh1YiAxLTA6MS4wOiAyIHBvcnRz
IGRldGVjdGVkClsgICAgMi41MDcwMDhdIHhoY2lfaGNkIDAwMDA6MDA6MDUuMDogeEhDSSBI
b3N0IENvbnRyb2xsZXIKWyAgICAyLjUxMzc5MV0geGhjaV9oY2QgMDAwMDowMDowNS4wOiBu
ZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDIKWyAgICAyLjUy
NTAwMF0gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBp
ZFByb2R1Y3Q9MDAwMwpbICAgIDIuNTM0MjA0XSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2Ug
c3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKWyAgICAyLjU0MzM0
MF0gdXNiIHVzYjI6IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyClsgICAgMi41NTAx
NDBdIHVzYiB1c2IyOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMTguMC1yYzQtMjAxNDExMTYt
c2VjdXJpdHkrIHhoY2ktaGNkClsgICAgMi41NTk4MzRdIHVzYiB1c2IyOiBTZXJpYWxOdW1i
ZXI6IDAwMDA6MDA6MDUuMApbICAgIDIuNTY2MDA2XSBodWIgMi0wOjEuMDogVVNCIGh1YiBm
b3VuZApbICAgIDIuNTcxMjcxXSBodWIgMi0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApbICAg
IDIuNTc3MDMzXSBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxl
ciAoRUhDSSkgRHJpdmVyClsgICAgMi41ODUyMzRdIGVoY2ktcGNpOiBFSENJIFBDSSBwbGF0
Zm9ybSBkcml2ZXIKWyAgICAyLjU5MTE5NF0gb2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhv
c3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVyClsgICAgMi41OTg4MzFdIG9oY2ktcGNpOiBP
SENJIFBDSSBwbGF0Zm9ybSBkcml2ZXIKWyAgICAyLjYwNDY4OV0gdWhjaV9oY2Q6IFVTQiBV
bml2ZXJzYWwgSG9zdCBDb250cm9sbGVyIEludGVyZmFjZSBkcml2ZXIKWyAgICAyLjYxNTc0
N10gdWhjaV9oY2QgMDAwMDowMDowMS4yOiBVSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDIu
NjIyMzg3XSB1aGNpX2hjZCAwMDAwOjAwOjAxLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs
IGFzc2lnbmVkIGJ1cyBudW1iZXIgMwpbICAgIDIuNjMzMDMzXSB1aGNpX2hjZCAwMDAwOjAw
OjAxLjI6IGlycSAyMywgaW8gYmFzZSAweDAwMDBjMTQwClsgICAgMi42NDA4NDBdIHVzYiB1
c2IzOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAw
MDEKWyAgICAyLjY1MTUyMV0gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xClsgICAgMi42NjA3NjZdIHVzYiB1c2Iz
OiBQcm9kdWN0OiBVSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDIuNjY3MjMxXSB1c2IgdXNi
MzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjE4LjAtcmM0LTIwMTQxMTE2LXNlY3VyaXR5KyB1
aGNpX2hjZApbICAgIDIuNjc2NzQ4XSB1c2IgdXNiMzogU2VyaWFsTnVtYmVyOiAwMDAwOjAw
OjAxLjIKWyAgICAyLjY4MzM2NV0gaHViIDMtMDoxLjA6IFVTQiBodWIgZm91bmQKWyAgICAy
LjY4ODc5MV0gaHViIDMtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKWyAgICAyLjY5NDk1MV0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JscApbICAgIDIu
NzAyNTU0XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1z
dG9yYWdlClsgICAgMi43MTA4NDFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFj
ZSBkcml2ZXIgdXNic2VyaWFsClsgICAgMi43MTg0NDddIHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGludGVyZmFjZSBkcml2ZXIgY3AyMTB4ClsgICAgMi43MjU4NzddIHVzYnNlcmlhbDog
VVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIGNwMjEweApbICAgIDIuNzMzNzQ5
XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGN5cHJlc3NfbTgK
WyAgICAyLjc0MTQzMF0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJl
ZCBmb3IgRGVMb3JtZSBFYXJ0aG1hdGUgVVNCClsgICAgMi43NTExNzJdIHVzYnNlcmlhbDog
VVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIEhJRC0+Q09NIFJTMjMyIEFkYXB0
ZXIKWyAgICAyLjc2MTIxNV0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0
ZXJlZCBmb3IgTm9raWEgQ0EtNDIgVjIgQWRhcHRlcgpbICAgIDIuNzcxMTg4XSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc3MjAKWyAgICAyLjc3ODk4
OV0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hp
cCAyIHBvcnQgYWRhcHRlcgpbICAgIDIuNzg4NzYwXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5l
dyBpbnRlcmZhY2UgZHJpdmVyIG1vczc4NDAKWyAgICAyLjc5NjM5M10gdXNic2VyaWFsOiBV
U0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCA3ODQwLzc4MjAgVVNC
IFNlcmlhbCBEcml2ZXIKWyAgICAyLjgwNzc1NV0gaTgwNDI6IFBOUDogUFMvMiBDb250cm9s
bGVyIFtQTlAwMzAzOlBTMkssUE5QMGYxMzpQUzJNXSBhdCAweDYwLDB4NjQgaXJxIDEsMTIK
WyAgICAyLjgyMjA3OV0gc2VyaW86IGk4MDQyIEtCRCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEg
MQpbICAgIDIuODIzNTE3XSB1c2IgMS0yOiBuZXcgbG93LXNwZWVkIFVTQiBkZXZpY2UgbnVt
YmVyIDIgdXNpbmcgeGhjaV9oY2QKWyAgICAyLjgzNzcyNF0gc2VyaW86IGk4MDQyIEFVWCBw
b3J0IGF0IDB4NjAsMHg2NCBpcnEgMTIKWyAgICAyLjg0NDg5NV0gbW91c2VkZXY6IFBTLzIg
bW91c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UKWyAgICAyLjg1Mzk1NF0gaW5wdXQ6
IEFUIFRyYW5zbGF0ZWQgU2V0IDIga2V5Ym9hcmQgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgw
NDIvc2VyaW8wL2lucHV0L2lucHV0MgpbICAgIDIuODY2MTY3XSBpbnB1dDogWGVuIFZpcnR1
YWwgS2V5Ym9hcmQgYXMgL2RldmljZXMvdmlydHVhbC9pbnB1dC9pbnB1dDUKWyAgICAyLjg4
MjAzOV0gaW5wdXQ6IFhlbiBWaXJ0dWFsIFBvaW50ZXIgYXMgL2RldmljZXMvdmlydHVhbC9p
bnB1dC9pbnB1dDYKWyAgICAyLjg5NDcxN10gcmFuZG9tOiBub25ibG9ja2luZyBwb29sIGlz
IGluaXRpYWxpemVkClsgICAgMi45MDMxOTZdIHJ0Y19jbW9zIDAwOjAyOiBydGMgY29yZTog
cmVnaXN0ZXJlZCBydGNfY21vcyBhcyBydGMwClsgICAgMi45MTIyODhdIHJ0Y19jbW9zIDAw
OjAyOiBhbGFybXMgdXAgdG8gb25lIGRheSwgMTE0IGJ5dGVzIG52cmFtLCBocGV0IGlycXMK
WyAgICAyLjkyMTg1N10gcGlpeDRfc21idXMgMDAwMDowMDowMS4zOiBTTUJ1cyBIb3N0IENv
bnRyb2xsZXIgbm90IGVuYWJsZWQhClsgICAgMi45MzExMjNdIGxpcmNfZGV2OiBJUiBSZW1v
dGUgQ29udHJvbCBkcml2ZXIgcmVnaXN0ZXJlZCwgbWFqb3IgMjQ4IApbICAgIDIuOTM5NDI3
XSBJUiBORUMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDIuOTQ1NTk4XSBJ
UiBSQzUoeC9zeikgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDIuOTUyNTU3
XSBJUiBSQzYgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDIuOTU4Njk5XSBJ
UiBKVkMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDIuOTY1MjEwXSBJUiBT
b255IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQKWyAgICAyLjk3MjAzNF0gSVIgU0FO
WU8gcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDIuOTc4OTM5XSBJUiBTaGFy
cCBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkClsgICAgMi45ODU5MjhdIElSIE1DRSBL
ZXlib2FyZC9tb3VzZSBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkClsgICAgMi45OTM4
ODZdIElSIExJUkMgYnJpZGdlIGhhbmRsZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjAwMDgyOF0g
SVIgWE1QIHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjAwMjE1NV0gdXNi
IDEtMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTEwY2YsIGlkUHJvZHVjdD01
NTAwClsgICAgMy4wMDIxNTZdIHVzYiAxLTI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0xLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wClsgICAgMy4wMDIxNTddIHVzYiAxLTI6
IFByb2R1Y3Q6IFVTQiBLODA1NQpbICAgIDMuMDAyMTU4XSB1c2IgMS0yOiBNYW51ZmFjdHVy
ZXI6IFZlbGxlbWFuIApbICAgIDMuMDAyMjg2XSB1c2IgMS0yOiBlcCAweDgxIC0gcm91bmRp
bmcgaW50ZXJ2YWwgdG8gNjQgbWljcm9mcmFtZXMsIGVwIGRlc2Mgc2F5cyA4MCBtaWNyb2Zy
YW1lcwpbICAgIDMuMDAyMjkwXSB1c2IgMS0yOiBlcCAweDEgLSByb3VuZGluZyBpbnRlcnZh
bCB0byA2NCBtaWNyb2ZyYW1lcywgZXAgZGVzYyBzYXlzIDgwIG1pY3JvZnJhbWVzClsgICAg
My4wMTY4NDVdIHVzYiAzLTE6IG5ldyBmdWxsLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIg
dXNpbmcgdWhjaV9oY2QKWyAgICAzLjA3MjkzMF0gY3gyNTgyMTogZHJpdmVyIHZlcnNpb24g
MC4wLjEwNiBsb2FkZWQKWyAgICAzLjA4MDM0OF0geGVuOiAtLT4gcGlycT00NyAtPiBpcnE9
NDAgKGdzaT00MCkKWyAgICAzLjA4MDU1M10gY3gyNTgyMTogQXRoZW5hIEhhcmR3YXJlIGRl
dmljZSA9IDB4ODIxMApbICAgIDMuMDg3NzE5XSBjeDI1ODIxOiBjeDI1ODIxWzFdOiBzdWJz
eXN0ZW06IDAwMDA6MDAwMCwgYm9hcmQ6IENYMjU4MjEgW2NhcmQ9MSxhdXRvZGV0ZWN0ZWRd
ClsgICAgMy4xNDg0NzldIHVzYiAzLTE6IG5vdCBydW5uaW5nIGF0IHRvcCBzcGVlZDsgY29u
bmVjdCB0byBhIGhpZ2ggc3BlZWQgaHViClsgICAgMy4xODc2NTVdIHVzYiAzLTE6IE5ldyBV
U0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0wNjI3LCBpZFByb2R1Y3Q9MDAwMQpbICAgIDMu
MTk3NTM4XSB1c2IgMy0xOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVj
dD0zLCBTZXJpYWxOdW1iZXI9NQpbICAgIDMuMjA3NDg1XSB1c2IgMy0xOiBQcm9kdWN0OiBR
RU1VIFVTQiBUYWJsZXQKWyAgICAzLjIxNDE0NV0gdXNiIDMtMTogTWFudWZhY3R1cmVyOiBR
RU1VClsgICAgMy4yMjAzMTldIHVzYiAzLTE6IFNlcmlhbE51bWJlcjogNDIKWyAgICAzLjM4
NDI5Nl0gY3gyNTgyMTogSGFyZHdhcmUgcmV2aXNpb24gPSAweDAwClsgICAgMy4zOTA0ODdd
IGN4MjU4MjE6IGN4MjU4MjFbMV0vMDogZm91bmQgYXQgMDAwMDowMDowNi4wLCByZXY6IDAs
IGlycTogNDAsIGxhdGVuY3k6IDAsIG1taW86IDB4ZjMwMDAwMDAKWyAgICAzLjQwMjgyN10g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBwdnJ1c2IyClsgICAg
My40MTA1MTNdIHB2cnVzYjI6IFY0TCBpbi10cmVlIHZlcnNpb246SGF1cHBhdWdlIFdpblRW
LVBWUi1VU0IyIE1QRUcyIEVuY29kZXIvVHVuZXIKWyAgICAzLjQyMTA5OV0gcHZydXNiMjog
RGVidWcgbWFzayBpcyAzMSAoMHgxZikKWyAgICAzLjQyODU3OF0gc3A1MTAwX3RjbzogU1A1
MTAwL1NCODAwIFRDTyBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDUKWyAgICAzLjQzNzE1
MV0gZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuMjguMC1pb2N0bCAoMjAxNC0wOS0xNykgaW5p
dGlhbGlzZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20KWyAgICAzLjQ0ODEyOF0gQmx1ZXRvb3Ro
OiBWaXJ0dWFsIEhDSSBkcml2ZXIgdmVyIDEuNQpbICAgIDMuNDU0NjQ3XSBCbHVldG9vdGg6
IEhDSSBVQVJUIGRyaXZlciB2ZXIgMi4yClsgICAgMy40NjExNjRdIEJsdWV0b290aDogSENJ
IEg0IHByb3RvY29sIGluaXRpYWxpemVkClsgICAgMy40Njg4NjVdIEJsdWV0b290aDogSENJ
IEJDU1AgcHJvdG9jb2wgaW5pdGlhbGl6ZWQKWyAgICAzLjQ3NzAxNl0gQmx1ZXRvb3RoOiBI
Q0lMTCBwcm90b2NvbCBpbml0aWFsaXplZApbICAgIDMuNDg1MTcwXSBCbHVldG9vdGg6IEhD
SUFUSDNLIHByb3RvY29sIGluaXRpYWxpemVkClsgICAgMy40OTM0MzNdIEJsdWV0b290aDog
SENJIFRocmVlLXdpcmUgVUFSVCAoSDUpIHByb3RvY29sIGluaXRpYWxpemVkClsgICAgMy41
MDY4ODNdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgYmNtMjAz
eApbICAgIDMuNTEzNDM4XSBpbnB1dDogSW1FeFBTLzIgR2VuZXJpYyBFeHBsb3JlciBNb3Vz
ZSBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzEvaW5wdXQvaW5wdXQ0ClsgICAg
My41Mjk5ODNdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgYnBh
MTB4ClsgICAgMy41Mzc3MTldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk
cml2ZXIgYmZ1c2IKWyAgICAzLjU0NTE3Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50
ZXJmYWNlIGRyaXZlciBidHVzYgpbICAgIDMuNTUyNTMwXSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIGF0aDNrClsgICAgMy41NTk4ODhdIGhpZHJhdzogcmF3
IEhJRCBldmVudHMgZHJpdmVyIChDKSBKaXJpIEtvc2luYQpbICAgIDMuNTcyOTI4XSBpbnB1
dDogUUVNVSBRRU1VIFVTQiBUYWJsZXQgYXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAw
OjAxLjIvdXNiMy8zLTEvMy0xOjEuMC8wMDAzOjA2Mjc6MDAwMS4wMDAxL2lucHV0L2lucHV0
NwpbICAgIDMuNTg3NjI4XSBoaWQtZ2VuZXJpYyAwMDAzOjA2Mjc6MDAwMS4wMDAxOiBpbnB1
dCxoaWRyYXcwOiBVU0IgSElEIHYwLjAxIFBvaW50ZXIgW1FFTVUgUUVNVSBVU0IgVGFibGV0
XSBvbiB1c2ItMDAwMDowMDowMS4yLTEvaW5wdXQwClsgICAgMy42MDI1NzVdIHVzYmNvcmU6
IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiaGlkClsgICAgMy42MTAyNjFd
IHVzYmhpZDogVVNCIEhJRCBjb3JlIGRyaXZlcgpbICAgIDMuNjE2Mzg0XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItYXVkaW8KWyAgICAzLjYy
NDUzOV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdWEx
MDEKWyAgICAzLjYzMjU5NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRy
aXZlciBzbmQtdXNiLXVzeDJ5ClsgICAgMy42NDA3MDddIHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi1jYWlhcQpbICAgIDMuNjQ5MDY3XSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItNmZpcmUKWyAg
ICAzLjY1NzI1Nl0gTmV0ZmlsdGVyIG1lc3NhZ2VzIHZpYSBORVRMSU5LIHYwLjMwLgpbICAg
IDMuNjYzNzI4XSBuZm5sX2FjY3Q6IHJlZ2lzdGVyaW5nIHdpdGggbmZuZXRsaW5rLgpbICAg
IDMuNjcwMTY3XSBuZl9jb25udHJhY2sgdmVyc2lvbiAwLjUuMCAoNzgzNiBidWNrZXRzLCAz
MTM0NCBtYXgpClsgICAgMy42NzgxNzBdIGN0bmV0bGluayB2MC45MzogcmVnaXN0ZXJpbmcg
d2l0aCBuZm5ldGxpbmsuClsgICAgMy42ODU3NTRdIHh0X3RpbWU6IGtlcm5lbCB0aW1lem9u
ZSBpcyAtMDAwMApbICAgIDMuNjkxOTQ5XSBpcF9zZXQ6IHByb3RvY29sIDYKWyAgICAzLjY5
NjcyMF0gSVBWUzogUmVnaXN0ZXJlZCBwcm90b2NvbHMgKCkKWyAgICAzLjcwMjMxMF0gSVBW
UzogQ29ubmVjdGlvbiBoYXNoIHRhYmxlIGNvbmZpZ3VyZWQgKHNpemU9NDA5NiwgbWVtb3J5
PTY0S2J5dGVzKQpbICAgIDMuNzExNjgyXSBJUFZTOiBDcmVhdGluZyBuZXRucyBzaXplPTEy
MTYgaWQ9MApbICAgIDMuNzE4NTk1XSBJUFZTOiBpcHZzIGxvYWRlZC4KWyAgICAzLjcyMzc3
OF0gaXBfdGFibGVzOiAoQykgMjAwMC0yMDA2IE5ldGZpbHRlciBDb3JlIFRlYW0KWyAgICAz
LjczMTE0Nl0gVENQOiBjdWJpYyByZWdpc3RlcmVkClsgICAgMy43MzYwMTNdIE5FVDogUmVn
aXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcKWyAgICAzLjc0MTkzNl0gYnJpZGdlOiBhdXRv
bWF0aWMgZmlsdGVyaW5nIHZpYSBhcnAvaXAvaXA2dGFibGVzIGhhcyBiZWVuIGRlcHJlY2F0
ZWQuIFVwZGF0ZSB5b3VyIHNjcmlwdHMgdG8gbG9hZCBicl9uZXRmaWx0ZXIgaWYgeW91IG5l
ZWQgdGhpcy4KWyAgICAzLjc1NzQyNl0gQnJpZGdlIGZpcmV3YWxsaW5nIHJlZ2lzdGVyZWQK
WyAgICAzLjc2MzE1NF0gRWJ0YWJsZXMgdjIuMCByZWdpc3RlcmVkClsgICAgMy43Njg2MDJd
IEJsdWV0b290aDogUkZDT01NIFRUWSBsYXllciBpbml0aWFsaXplZApbICAgIDMuNzc1MzAy
XSBCbHVldG9vdGg6IFJGQ09NTSBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjc4
MjMzNF0gQmx1ZXRvb3RoOiBSRkNPTU0gdmVyIDEuMTEKWyAgICAzLjc4NzcxM10gQmx1ZXRv
b3RoOiBCTkVQIChFdGhlcm5ldCBFbXVsYXRpb24pIHZlciAxLjMKWyAgICAzLjc5NDg5MF0g
Qmx1ZXRvb3RoOiBCTkVQIGZpbHRlcnM6IHByb3RvY29sIG11bHRpY2FzdApbICAgIDMuODAx
ODkyXSBCbHVldG9vdGg6IEJORVAgc29ja2V0IGxheWVyIGluaXRpYWxpemVkClsgICAgMy44
MDg1MTBdIEJsdWV0b290aDogSElEUCAoSHVtYW4gSW50ZXJmYWNlIEVtdWxhdGlvbikgdmVy
IDEuMgpbICAgIDMuODE2NTU2XSBCbHVldG9vdGg6IEhJRFAgc29ja2V0IGxheWVyIGluaXRp
YWxpemVkClsgICAgMy44MjI5OTVdIEtleSB0eXBlIGNlcGggcmVnaXN0ZXJlZApbICAgIDMu
ODI4NDU1XSBsaWJjZXBoOiBsb2FkZWQgKG1vbi9vc2QgcHJvdG8gMTUvMjQpClsgICAgMy44
MzU2OTBdIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24gMQpbICAgIDMuODQxOTE4XSBC
dHJmcyBsb2FkZWQKWyAgICAzLjg0OTEwMl0geGVuYnVzX3Byb2JlX2Zyb250ZW5kOiBEZXZp
Y2Ugd2l0aCBubyBkcml2ZXI6IGRldmljZS9wY2kvMApbICAgIDMuODU3NTYyXSBjb25zb2xl
IFtuZXRjb24wXSBlbmFibGVkClsgICAgMy44NjI4MTBdIG5ldGNvbnNvbGU6IG5ldHdvcmsg
bG9nZ2luZyBzdGFydGVkClsgICAgMy44NjkxNDldIHJ0Y19jbW9zIDAwOjAyOiBzZXR0aW5n
IHN5c3RlbSBjbG9jayB0byAyMDE0LTExLTE3IDIxOjU4OjExIFVUQyAoMTQxNjI2MTQ5MSkK
WyAgICAzLjg3OTc0N10gY3gyNTgyMV9hbHNhOiBjeDI1ODIxLzA6IEFMU0Egc3VwcG9ydCBm
b3IgY3gyNTgyMSBib2FyZHMKWyAgICAzLjg4ODM2Ml0gQUxTQSBkZXZpY2UgbGlzdDoKWyAg
ICAzLjg5MzA4NV0gICAjMDogY3gyNTgyMVsxXSBhdCAweGYzMDAwMDAwIGlycSA0MApbICAg
IDMuOTAxODAzXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAxMDQ4SyAoZmZmZmZm
ZmY4MjBkZjAwMCAtIGZmZmZmZmZmODIxZTUwMDApClsgICAgMy45MTI1MDBdIFdyaXRlIHBy
b3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogMTYzODRrClsgICAgMy45MjM2
MTVdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEzMzZLIChmZmZmODgwMDAxYWIy
MDAwIC0gZmZmZjg4MDAwMWMwMDAwMCkKWyAgICAzLjkzNTU3NV0gRnJlZWluZyB1bnVzZWQg
a2VybmVsIG1lbW9yeTogNTk2SyAoZmZmZjg4MDAwMWY2YjAwMCAtIGZmZmY4ODAwMDIwMDAw
MDApClsgICAgMy45NjEwNzVdIHVkZXZkWzE0NzBdOiBzdGFydGluZyB2ZXJzaW9uIDE3NQpb
ICAgIDQuMzE1Njg5XSBFWFQ0LWZzICh4dmRhMSk6IElORk86IHJlY292ZXJ5IHJlcXVpcmVk
IG9uIHJlYWRvbmx5IGZpbGVzeXN0ZW0KWyAgICA0LjMyNDM5Nl0gRVhUNC1mcyAoeHZkYTEp
OiB3cml0ZSBhY2Nlc3Mgd2lsbCBiZSBlbmFibGVkIGR1cmluZyByZWNvdmVyeQpbICAgIDQu
NDkwMzQzXSBFWFQ0LWZzICh4dmRhMSk6IHJlY292ZXJ5IGNvbXBsZXRlClsgICAgNC41MDY4
NjZdIEVYVDQtZnMgKHh2ZGExKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBk
YXRhIG1vZGUuIE9wdHM6IChudWxsKQpbICAgIDUuNDM3MTY0XSB1ZGV2ZFsxOTYwXTogc3Rh
cnRpbmcgdmVyc2lvbiAxNzUKWyAgICA5LjQ4NzEzN10gQWRkaW5nIDc2OTAyMGsgc3dhcCBv
biAvZGV2L3h2ZGEyLiAgUHJpb3JpdHk6LTEgZXh0ZW50czoxIGFjcm9zczo3NjkwMjBrIFNT
ClsgICAgOS41MjIwMzZdIEVYVDQtZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0czogKG51
bGwpClsgICAgOS42OTQ4NDddIEVYVDQtZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0czog
ZXJyb3JzPXJlbW91bnQtcm8KWyAgIDEwLjQ2NDg4MV0gRVhUNC1mcyAoeHZkYik6IG1vdW50
ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBlcnJvcnM9cmVt
b3VudC1ybwo=
------------0C90EA036019900CC
Content-Type: text/plain;
 name="lspci-guest.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-guest.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEludGVsIENvcnBvcmF0aW9uIDQ0MEZYIC0g
ODI0NDFGWCBQTUMgW05hdG9tYV0gWzgwODY6MTIzN10gKHJldiAwMikKCVN1YnN5c3RlbTog
UmVkIEhhdCwgSW5jIFFlbXUgdmlydHVhbCBtYWNoaW5lIFsxYWY0OjExMDBdCglDb250cm9s
OiBJL08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQ
YXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXAt
IDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoKMDA6MDEu
MCBJU0EgYnJpZGdlIFswNjAxXTogSW50ZWwgQ29ycG9yYXRpb24gODIzNzFTQiBQSUlYMyBJ
U0EgW05hdG9tYS9Ucml0b24gSUldIFs4MDg2OjcwMDBdCglTdWJzeXN0ZW06IFJlZCBIYXQs
IEluYyBRZW11IHZpcnR1YWwgbWFjaGluZSBbMWFmNDoxMTAwXQoJUGh5c2ljYWwgU2xvdDog
MQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0
YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0g
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5j
eTogMAoKMDA6MDEuMSBJREUgaW50ZXJmYWNlIFswMTAxXTogSW50ZWwgQ29ycG9yYXRpb24g
ODIzNzFTQiBQSUlYMyBJREUgW05hdG9tYS9Ucml0b24gSUldIFs4MDg2OjcwMTBdIChwcm9n
LWlmIDgwIFtNYXN0ZXJdKQoJU3Vic3lzdGVtOiBSZWQgSGF0LCBJbmMgUWVtdSB2aXJ0dWFs
IG1hY2hpbmUgWzFhZjQ6MTEwMF0KCVBoeXNpY2FsIFNsb3Q6IDEKCUNvbnRyb2w6IEkvTysg
TWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0g
U3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcC0gNjZNSHot
IFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQt
IDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAKCVJlZ2lvbiAwOiBb
dmlydHVhbF0gTWVtb3J5IGF0IDAwMDAwMWYwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUp
IFtzaXplPThdCglSZWdpb24gMTogW3ZpcnR1YWxdIE1lbW9yeSBhdCAwMDAwMDNmMCAodHlw
ZSAzLCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xXQoJUmVnaW9uIDI6IFt2aXJ0dWFsXSBN
ZW1vcnkgYXQgMDAwMDAxNzAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9OF0K
CVJlZ2lvbiAzOiBbdmlydHVhbF0gTWVtb3J5IGF0IDAwMDAwMzcwICh0eXBlIDMsIG5vbi1w
cmVmZXRjaGFibGUpIFtzaXplPTFdCglSZWdpb24gNDogSS9PIHBvcnRzIGF0IGMxNjAgW3Np
emU9MTZdCgowMDowMS4yIFVTQiBjb250cm9sbGVyIFswYzAzXTogSW50ZWwgQ29ycG9yYXRp
b24gODIzNzFTQiBQSUlYMyBVU0IgW05hdG9tYS9Ucml0b24gSUldIFs4MDg2OjcwMjBdIChy
ZXYgMDEpIChwcm9nLWlmIDAwIFtVSENJXSkKCVN1YnN5c3RlbTogUmVkIEhhdCwgSW5jIFFl
bXUgdmlydHVhbCBtYWNoaW5lIFsxYWY0OjExMDBdCglQaHlzaWNhbCBTbG90OiAxCglDb250
cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBD
YXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0g
PFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoJSW50
ZXJydXB0OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDIzCglSZWdpb24gNDogSS9PIHBvcnRzIGF0
IGMxNDAgW3NpemU9MzJdCglLZXJuZWwgZHJpdmVyIGluIHVzZTogdWhjaV9oY2QKCjAwOjAx
LjMgQnJpZGdlIFswNjgwXTogSW50ZWwgQ29ycG9yYXRpb24gODIzNzFBQi9FQi9NQiBQSUlY
NCBBQ1BJIFs4MDg2OjcxMTNdIChyZXYgMDMpCglTdWJzeXN0ZW06IFJlZCBIYXQsIEluYyBR
ZW11IHZpcnR1YWwgbWFjaGluZSBbMWFmNDoxMTAwXQoJUGh5c2ljYWwgU2xvdDogMQoJQ29u
dHJvbDogSS9PLSBNZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9v
cC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czog
Q2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoJ
SW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDkKCjAwOjAyLjAgVW5hc3NpZ25lZCBj
bGFzcyBbZmY4MF06IFhlblNvdXJjZSwgSW5jLiBYZW4gUGxhdGZvcm0gRGV2aWNlIFs1ODUz
OjAwMDFdIChyZXYgMDEpCglTdWJzeXN0ZW06IFhlblNvdXJjZSwgSW5jLiBYZW4gUGxhdGZv
cm0gRGV2aWNlIFs1ODUzOjAwMDFdCglQaHlzaWNhbCBTbG90OiAyCglDb250cm9sOiBJL08r
IE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnIt
IFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXAtIDY2TUh6
LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoJSW50ZXJydXB0OiBw
aW4gQSByb3V0ZWQgdG8gSVJRIDI0CglSZWdpb24gMDogSS9PIHBvcnRzIGF0IGMwMDAgW3Np
emU9MjU2XQoJUmVnaW9uIDE6IE1lbW9yeSBhdCBmMjAwMDAwMCAoMzItYml0LCBwcmVmZXRj
aGFibGUpIFtzaXplPTE2TV0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiB4ZW4tcGxhdGZvcm0t
cGNpCgowMDowMy4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXIgWzAzMDBdOiBDaXJydXMg
TG9naWMgR0QgNTQ0NiBbMTAxMzowMGI4XSAocHJvZy1pZiAwMCBbVkdBIGNvbnRyb2xsZXJd
KQoJU3Vic3lzdGVtOiBSZWQgSGF0LCBJbmMgRGV2aWNlIFsxYWY0OjExMDBdCglQaHlzaWNh
bCBTbG90OiAzCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1l
bVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJ
TlR4LQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJ
TGF0ZW5jeTogMAoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmMDAwMDAwMCAoMzItYml0LCBwcmVm
ZXRjaGFibGUpIFtzaXplPTMyTV0KCVJlZ2lvbiAxOiBNZW1vcnkgYXQgZjMyNzIwMDAgKDMy
LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdCglFeHBhbnNpb24gUk9NIGF0IGYz
MjYwMDAwIFtkaXNhYmxlZF0gW3NpemU9NjRLXQoKMDA6MDUuMCBVU0IgY29udHJvbGxlciBb
MGMwM106IE5FQyBDb3Jwb3JhdGlvbiB1UEQ3MjAyMDAgVVNCIDMuMCBIb3N0IENvbnRyb2xs
ZXIgWzEwMzM6MDE5NF0gKHJldiAwMykgKHByb2ctaWYgMzAgW1hIQ0ldKQoJU3Vic3lzdGVt
OiBBU1VTVGVLIENvbXB1dGVyIEluYy4gUDhQNjcgRGVsdXhlIE1vdGhlcmJvYXJkIFsxMDQz
Ojg0MTNdCglQaHlzaWNhbCBTbG90OiA1CglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
LSBGYXN0QjJCLSBEaXNJTlR4KwoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkIt
IFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt
IDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJ
SW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDM2CglSZWdpb24gMDogTWVtb3J5IGF0
IGYzMjcwMDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPThLXQoJQ2FwYWJp
bGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0s
RDNjb2xkLSkKCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERT
Y2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzcwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8x
IE1hc2thYmxlLSA2NGJpdCsKCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAw
MDAwCglDYXBhYmlsaXRpZXM6IFs5MF0gTVNJLVg6IEVuYWJsZSsgQ291bnQ9OCBNYXNrZWQt
CgkJVmVjdG9yIHRhYmxlOiBCQVI9MCBvZmZzZXQ9MDAwMDEwMDAKCQlQQkE6IEJBUj0wIG9m
ZnNldD0wMDAwMTA4MAoJQ2FwYWJpbGl0aWVzOiBbYTBdIEV4cHJlc3MgKHYyKSBFbmRwb2lu
dCwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAs
IExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkCgkJCUV4dFRhZy0gQXR0bkJ0
bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJy
b3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJCVJs
eGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBheWxv
YWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcwoJCURldlN0YToJQ29yckVyci0g
VW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0KCQlM
bmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDR1cywgTDEgdW5saW1pdGVkCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFj
dFJlcC0gQndOb3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlz
YWJsZWQtIFJldHJhaW4tIENvbW1DbGstCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWRE
aXMtIEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDVHVC9zLCBXaWR0aCB4MSwg
VHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURl
dkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91dERpcysK
CQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERp
cy0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtNmRCCgkJCSBUcmFuc21p
dCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlh
bmNlLSBDb21wbGlhbmNlU09TLQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQgoJ
CUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEIsIEVxdWFsaXphdGlv
bkNvbXBsZXRlLSwgRXF1YWxpemF0aW9uUGhhc2UxLQoJCQkgRXF1YWxpemF0aW9uUGhhc2Uy
LSwgRXF1YWxpemF0aW9uUGhhc2UzLSwgTGlua0VxdWFsaXphdGlvblJlcXVlc3QtCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogeGhjaV9oY2QKCjAwOjA2LjAgTXVsdGltZWRpYSB2aWRlbyBj
b250cm9sbGVyIFswNDAwXTogQ29uZXhhbnQgU3lzdGVtcywgSW5jLiBEZXZpY2UgWzE0ZjE6
ODIxMF0KCVBoeXNpY2FsIFNsb3Q6IDYKCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIr
IFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIt
IEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtCglMYXRlbmN5OiAwCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJ
UlEgNDAKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjMwMDAwMDAgKDY0LWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9Mk1dCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1
bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMKCQkJRXh0VGFnLSBBdHRuQnRuLSBB
dHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9y
ZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsKCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNv
cnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0Nh
cDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRl
bmN5IEwwIDwydXMsIEwxIDw0dXMKCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBC
d05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0g
UmV0cmFpbi0gQ29tbUNsay0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJ
bnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy
LSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0KCUNhcGFiaWxp
dGllczogWzgwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGst
IERTSSsgRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQz
Y29sZC0pCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2Nh
bGU9MCBQTUUtCglDYXBhYmlsaXRpZXM6IFs5MF0gVml0YWwgUHJvZHVjdCBEYXRhCgkJVW5r
bm93biBzbWFsbCByZXNvdXJjZSB0eXBlIDAyLCB3aWxsIG5vdCBkZWNvZGUgbW9yZS4KCUNh
cGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJp
dCsKCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwCglLZXJuZWwgZHJp
dmVyIGluIHVzZTogY3gyNTgyMQoK
------------0C90EA036019900CC
Content-Type: text/plain;
 name="qemu-dm-guest.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="qemu-dm-guest.txt"

Y2hhciBkZXZpY2UgcmVkaXJlY3RlZCB0byAvZGV2L3B0cy8xOSAobGFiZWwgc2VyaWFsMCkN
Cnhlbjogc2hhcmVkIHBhZ2UgYXQgcGZuIGZlZmZkDQp4ZW46IGJ1ZmZlcmVkIGlvIHBhZ2Ug
YXQgcGZuIGZlZmZiDQp2Z2FiaW9zLWNpcnJ1cy5iaW46IFJPTSBpZCAxMDEzMDBiOCAvIFBD
SSBpZCAxMDEzMDBiOA0KZWZpLWUxMDAwLnJvbTogUk9NIGlkIDgwODYxMDBlIC8gUENJIGlk
IDgwODYxMDBlDQp4ZW46IHhlbl9tYWluX2xvb3BfcHJlcGFyZTogSW5pdCBjcHVfYnlfdmNw
dV9pZA0KeGVuOiB4ZW5fbWFpbl9sb29wX3ByZXBhcmU6IGNwdV9ieV92Y3B1X2lkWzBdPTB4
N2Y5YjAxNzU1ZTUwDQp4ZW46IHhlbl9tYWluX2xvb3BfcHJlcGFyZTogY3B1X2J5X3ZjcHVf
aWRbMV09MHg3ZjliMDE3NjgwYjANCnhlbjogeGVuX21haW5fbG9vcF9wcmVwYXJlOiBjcHVf
YnlfdmNwdV9pZFsyXT0weDdmOWIwMTc3ODkzMA0KeGVuOiB4ZW5fbWFpbl9sb29wX3ByZXBh
cmU6IGNwdV9ieV92Y3B1X2lkWzNdPTB4N2Y5YjAxN2IwNTQwDQp4ZW46IEkvTyByZXF1ZXN0
IG5vdCByZWFkeTogMCwgcHRyOiAwLCBwb3J0OiAwLCBkYXRhOiAwLCBjb3VudDogMCwgc2l6
ZTogMA0KeGVuOiBJL08gcmVxdWVzdCBub3QgcmVhZHk6IDAsIHB0cjogMCwgcG9ydDogMCwg
ZGF0YTogMCwgY291bnQ6IDAsIHNpemU6IDANCnhlbjogSS9PIHJlcXVlc3Qgbm90IHJlYWR5
OiAwLCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAwDQp4ZW46
IEkvTyByZXF1ZXN0IG5vdCByZWFkeTogMCwgcHRyOiAwLCBwb3J0OiAwLCBkYXRhOiAwLCBj
b3VudDogMCwgc2l6ZTogMA0KWzAwOjA1LjBdIHhlbl9wdF9pbml0Zm46IEFzc2lnbmluZyBy
ZWFsIHBoeXNpY2FsIGRldmljZSAwODowMC4wIHRvIGRldmZuIDB4MjggIDAwOjA1LjANClsw
MDowNS4wXSB4ZW5fcHRfcmVnaXN0ZXJfcmVnaW9uczogPyE/IT8geGVuX3B0X3JlZ2lzdGVy
X3JlZ2lvbnMgb3RoZXIgZGV2DQpbMDA6MDUuMF0geGVuX3B0X3JlZ2lzdGVyX3JlZ2lvbnM6
IElPIHJlZ2lvbiAwIHJlZ2lzdGVyZWQgKHNpemU9MHgwMDAwMjAwMCBiYXNlX2FkZHI9MHhm
ZTBmZTAwMCB0eXBlOiAweDQpDQpbMDA6MDUuMF0geGVuX3B0X21zaXhfaW5pdDogZ2V0IE1T
SS1YIHRhYmxlIEJBUiBiYXNlIDB4ZmUwZmUwMDANClswMDowNS4wXSB4ZW5fcHRfbXNpeF9p
bml0OiB0YWJsZV9vZmYgPSAweDEwMDAsIHRvdGFsX2VudHJpZXMgPSA4DQpbMDA6MDUuMF0g
eGVuX3B0X21zaXhfaW5pdDogbWFwcGluZyBwaHlzaWNhbCBNU0ktWCB0YWJsZSB0byAweDdm
OWIwMDM1MzAwMA0KWzAwOjA1LjBdIHhlbl9wdF9wY2lfaW50eDogaW50eD0xDQpbMDA6MDUu
MF0geGVuX3B0X2luaXRmbjogUmVhbCBwaHlzaWNhbCBkZXZpY2UgMDg6MDAuMCByZWdpc3Rl
cmVkIHN1Y2Nlc3NmdWxseSENClswMDowNi4wXSB4ZW5fcHRfaW5pdGZuOiBBc3NpZ25pbmcg
cmVhbCBwaHlzaWNhbCBkZXZpY2UgMGE6MDAuMCB0byBkZXZmbiAweDMwICAwMDowNi4wDQpb
MDA6MDYuMF0geGVuX3B0X3JlZ2lzdGVyX3JlZ2lvbnM6ID8hPyE/IHhlbl9wdF9yZWdpc3Rl
cl9yZWdpb25zIG90aGVyIGRldg0KWzAwOjA2LjBdIHhlbl9wdF9yZWdpc3Rlcl9yZWdpb25z
OiBJTyByZWdpb24gMCByZWdpc3RlcmVkIChzaXplPTB4MDAyMDAwMDAgYmFzZV9hZGRyPTB4
ZmUyMDAwMDAgdHlwZTogMHg0KQ0KWzAwOjA2LjBdIHhlbl9wdF9wY2lfaW50eDogaW50eD0x
DQpbMDA6MDYuMF0geGVuX3B0X2luaXRmbjogUmVhbCBwaHlzaWNhbCBkZXZpY2UgMGE6MDAu
MCByZWdpc3RlcmVkIHN1Y2Nlc3NmdWxseSENCnhlbjogcGh5c21hcHBpbmcgZG9lcyBub3Qg
ZXhpc3QgYXQgMDAwMDAwMDBmMzI2MDAwMA0KeGVuOiBtYXBwaW5nIHZyYW0gdG8gZjAwMDAw
MDAgLSBmMDgwMDAwMA0KeGVuOiBwaHlzbWFwcGluZyBkb2VzIG5vdCBleGlzdCBhdCAwMDAw
MDAwMGYzMjAwMDAwDQpbMDA6MDUuMF0geGVuX3B0X3BjaV93cml0ZV9jb25maWc6IFdhcm5p
bmc6IEd1ZXN0IGF0dGVtcHQgdG8gc2V0IGFkZHJlc3MgdG8gdW51c2VkIEJhc2UgQWRkcmVz
cyBSZWdpc3Rlci4gKGFkZHI6IDB4MzAsIGxlbjogNCkNClswMDowNi4wXSB4ZW5fcHRfcGNp
X3dyaXRlX2NvbmZpZzogV2FybmluZzogR3Vlc3QgYXR0ZW1wdCB0byBzZXQgYWRkcmVzcyB0
byB1bnVzZWQgQmFzZSBBZGRyZXNzIFJlZ2lzdGVyLiAoYWRkcjogMHgzMCwgbGVuOiA0KQ0K
PyE/IT8gcGNpX3VucmVnaXN0ZXJfdmdhIDAwOjA0LjA6ICFwY2lfZGV2LT5oYXNfdmdhDQpb
MDA6MDUuMF0geGVuX3B0X3BjaV93cml0ZV9jb25maWc6IFdhcm5pbmc6IEd1ZXN0IGF0dGVt
cHQgdG8gc2V0IGFkZHJlc3MgdG8gdW51c2VkIEJhc2UgQWRkcmVzcyBSZWdpc3Rlci4gKGFk
ZHI6IDB4MzAsIGxlbjogNCkNClswMDowNi4wXSB4ZW5fcHRfcGNpX3dyaXRlX2NvbmZpZzog
V2FybmluZzogR3Vlc3QgYXR0ZW1wdCB0byBzZXQgYWRkcmVzcyB0byB1bnVzZWQgQmFzZSBB
ZGRyZXNzIFJlZ2lzdGVyLiAoYWRkcjogMHgzMCwgbGVuOiA0KQ0KWzAwOjA1LjBdIHhlbl9w
dF9tc2l4Y3RybF9yZWdfd3JpdGU6IGVuYWJsZSBNU0ktWA0KWzAwOjA1LjBdIG1zaV9tc2l4
X3NldHVwOiByZXF1ZXN0ZWQgcGlycSA4NyBmb3IgTVNJLVggKHZlYzogMCwgZW50cnk6IDAp
DQpbMDA6MDUuMF0gbXNpX21zaXhfdXBkYXRlOiBVcGRhdGluZyBNU0ktWCB3aXRoIHBpcnEg
ODcgZ3ZlYyAwIGdmbGFncyAweDMwNTcgKGVudHJ5OiAwKQ0KWzAwOjA1LjBdIG1zaV9tc2l4
X3NldHVwOiByZXF1ZXN0ZWQgcGlycSA4NiBmb3IgTVNJLVggKHZlYzogMCwgZW50cnk6IDB4
MSkNClswMDowNS4wXSBtc2lfbXNpeF91cGRhdGU6IFVwZGF0aW5nIE1TSS1YIHdpdGggcGly
cSA4NiBndmVjIDAgZ2ZsYWdzIDB4MzA1NiAoZW50cnk6IDB4MSkNClswMDowNS4wXSBtc2lf
bXNpeF9zZXR1cDogcmVxdWVzdGVkIHBpcnEgODUgZm9yIE1TSS1YICh2ZWM6IDAsIGVudHJ5
OiAweDIpDQpbMDA6MDUuMF0gbXNpX21zaXhfdXBkYXRlOiBVcGRhdGluZyBNU0ktWCB3aXRo
IHBpcnEgODUgZ3ZlYyAwIGdmbGFncyAweDMwNTUgKGVudHJ5OiAweDIpDQpbMDA6MDUuMF0g
bXNpX21zaXhfc2V0dXA6IHJlcXVlc3RlZCBwaXJxIDg0IGZvciBNU0ktWCAodmVjOiAwLCBl
bnRyeTogMHgzKQ0KWzAwOjA1LjBdIG1zaV9tc2l4X3VwZGF0ZTogVXBkYXRpbmcgTVNJLVgg
d2l0aCBwaXJxIDg0IGd2ZWMgMCBnZmxhZ3MgMHgzMDU0IChlbnRyeTogMHgzKQ0KWzAwOjA1
LjBdIG1zaV9tc2l4X3NldHVwOiByZXF1ZXN0ZWQgcGlycSA4MyBmb3IgTVNJLVggKHZlYzog
MCwgZW50cnk6IDB4NCkNClswMDowNS4wXSBtc2lfbXNpeF91cGRhdGU6IFVwZGF0aW5nIE1T
SS1YIHdpdGggcGlycSA4MyBndmVjIDAgZ2ZsYWdzIDB4MzA1MyAoZW50cnk6IDB4NCkNCnhl
biBiZTogdmtiZC0wOiBpbml0aWFsaXNlKCkgZmFpbGVkDQp4ZW4gYmU6IHZrYmQtMDogaW5p
dGlhbGlzZSgpIGZhaWxlZA0KeGVuIGJlOiB2a2JkLTA6IGluaXRpYWxpc2UoKSBmYWlsZWQN
Cg==
------------0C90EA036019900CC
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0C90EA036019900CC--



From xen-devel-bounces@lists.xen.org Mon Nov 17 22:58:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 22:58:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqVFX-00083j-S2; Mon, 17 Nov 2014 22:58:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqVFW-00083e-3z
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 22:58:22 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	8C/CB-22777-D8D7A645; Mon, 17 Nov 2014 22:58:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416265089!11871418!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1752 invoked from network); 17 Nov 2014 22:58:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 22:58:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,405,1413244800"; d="scan'208";a="192271155"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 17:58:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqVFI-0008E6-5g;
	Mon, 17 Nov 2014 22:58:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqVFH-0007HH-Ry;
	Mon, 17 Nov 2014 22:58:07 +0000
Date: Mon, 17 Nov 2014 22:58:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31641-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31641: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31641 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31641/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 30846 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 Nov 17 22:58:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Nov 2014 22:58:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqVFX-00083j-S2; Mon, 17 Nov 2014 22:58:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqVFW-00083e-3z
	for xen-devel@lists.xensource.com; Mon, 17 Nov 2014 22:58:22 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	8C/CB-22777-D8D7A645; Mon, 17 Nov 2014 22:58:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416265089!11871418!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1752 invoked from network); 17 Nov 2014 22:58:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2014 22:58:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,405,1413244800"; d="scan'208";a="192271155"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 17:58:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqVFI-0008E6-5g;
	Mon, 17 Nov 2014 22:58:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqVFH-0007HH-Ry;
	Mon, 17 Nov 2014 22:58:07 +0000
Date: Mon, 17 Nov 2014 22:58:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31641-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31641: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31641 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31641/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 30846 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 Nov 18 01:40:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 01:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqXm8-0005k7-6v; Tue, 18 Nov 2014 01:40:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XqXm5-0005k2-Td
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 01:40:10 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	13/C6-17694-873AA645; Tue, 18 Nov 2014 01:40:08 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416274805!12016123!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10574 invoked from network); 18 Nov 2014 01:40:08 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 01:40:08 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 18:40:04 -0700
Message-Id: <546B13EE020000660007AF8B@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 18:39:58 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<21610.6141.943750.141913@mariner.uk.xensource.com>
	<1416239594.5466.23.camel@citrix.com>
In-Reply-To: <1416239594.5466.23.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 11/17/2014 at 11:53 PM, in message <1416239594.5466.23.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Mon, 2014-11-17 at 15:45 +0000, Ian Jackson wrote: 
> > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */ 
> >  
> > Um, what on earth creates that ? 
> >  
> > Worse, what reads it ? 
> >  
> > I think that putting this information in the backend directory is 
> > entirely wrong. 
>  
> I concluded the same thing. 
>  
> Chunyan, I think it would be better to simply remove the code which adds 
> this domain field under the backend dir in the first place, instead of 
> adding all this complex code to try and keep it up to date. 
>  
> Can you do that in the next iteration please? 

Sure. I also doubt why the domain field is added to the backend dir, and only
under some device types, like vkbd, console, etc. under vif and vbd, there is
no such filed. If no one uses that field, I'll remove that from backend dir.

- Chunyan

>  
> 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 Nov 18 01:40:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 01:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqXm8-0005k7-6v; Tue, 18 Nov 2014 01:40:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XqXm5-0005k2-Td
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 01:40:10 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	13/C6-17694-873AA645; Tue, 18 Nov 2014 01:40:08 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416274805!12016123!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10574 invoked from network); 18 Nov 2014 01:40:08 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 01:40:08 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 18:40:04 -0700
Message-Id: <546B13EE020000660007AF8B@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 18:39:58 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<21610.6141.943750.141913@mariner.uk.xensource.com>
	<1416239594.5466.23.camel@citrix.com>
In-Reply-To: <1416239594.5466.23.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 11/17/2014 at 11:53 PM, in message <1416239594.5466.23.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Mon, 2014-11-17 at 15:45 +0000, Ian Jackson wrote: 
> > > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */ 
> >  
> > Um, what on earth creates that ? 
> >  
> > Worse, what reads it ? 
> >  
> > I think that putting this information in the backend directory is 
> > entirely wrong. 
>  
> I concluded the same thing. 
>  
> Chunyan, I think it would be better to simply remove the code which adds 
> this domain field under the backend dir in the first place, instead of 
> adding all this complex code to try and keep it up to date. 
>  
> Can you do that in the next iteration please? 

Sure. I also doubt why the domain field is added to the backend dir, and only
under some device types, like vkbd, console, etc. under vif and vbd, there is
no such filed. If no one uses that field, I'll remove that from backend dir.

- Chunyan

>  
> 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 Nov 18 02:13:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 02:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqYIL-0006cF-Lo; Tue, 18 Nov 2014 02:13:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XqYIJ-0006cA-Im
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 02:13:28 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F9/B1-01660-64BAA645; Tue, 18 Nov 2014 02:13:26 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416276802!11881970!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29405 invoked from network); 18 Nov 2014 02:13:24 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 02:13:24 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 19:13:21 -0700
Message-Id: <546B1BBA020000660007AFAB@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 19:13:14 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<21610.6141.943750.141913@mariner.uk.xensource.com>
In-Reply-To: <21610.6141.943750.141913@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 11/17/2014 at 11:45 PM, in message
<21610.6141.943750.141913@mariner.uk.xensource.com>, Ian Jackson
<Ian.Jackson@eu.citrix.com> wrote: 
> Chunyan Liu writes ("[PATCH] fix rename: xenstore not fully updated"): 
> > Currently libxl__domain_rename only update /local/domain/<domid>/name, 
> > still some places in xenstore are not updated, including: 
> > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain. 
>  
> Thanks. 
>  
> ... 
> > +    /* update /vm/<uuid>/name */ 
> > +    vm_path = libxl__xs_read(gc, trans, libxl__sprintf(gc, "%s/vm",  
> dom_path)); 
>  
> This seems to be obtaining the uuid from xenstore.  Can't we get it 
> from the hypervisor ?  That avoids quite a bit of this path fiddling. 

Will update. Thanks.

>  
> > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */ 
>  
> Um, what on earth creates that ? 
>  
> Worse, what reads it ? 
>  
> I think that putting this information in the backend directory is 
> entirely wrong. 
>  
> (Also, please use GCSPRINTF, libxl__xs_read_checked, etc., and keep 
> your lines to less than 75 characters or so.) 
>  
> Thanks, 
> Ian. 
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 02:13:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 02:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqYIL-0006cF-Lo; Tue, 18 Nov 2014 02:13:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XqYIJ-0006cA-Im
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 02:13:28 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F9/B1-01660-64BAA645; Tue, 18 Nov 2014 02:13:26 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416276802!11881970!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29405 invoked from network); 18 Nov 2014 02:13:24 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 02:13:24 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 17 Nov 2014 19:13:21 -0700
Message-Id: <546B1BBA020000660007AFAB@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 17 Nov 2014 19:13:14 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <1416215987-21571-1-git-send-email-cyliu@suse.com>
	<21610.6141.943750.141913@mariner.uk.xensource.com>
In-Reply-To: <21610.6141.943750.141913@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 11/17/2014 at 11:45 PM, in message
<21610.6141.943750.141913@mariner.uk.xensource.com>, Ian Jackson
<Ian.Jackson@eu.citrix.com> wrote: 
> Chunyan Liu writes ("[PATCH] fix rename: xenstore not fully updated"): 
> > Currently libxl__domain_rename only update /local/domain/<domid>/name, 
> > still some places in xenstore are not updated, including: 
> > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain. 
>  
> Thanks. 
>  
> ... 
> > +    /* update /vm/<uuid>/name */ 
> > +    vm_path = libxl__xs_read(gc, trans, libxl__sprintf(gc, "%s/vm",  
> dom_path)); 
>  
> This seems to be obtaining the uuid from xenstore.  Can't we get it 
> from the hypervisor ?  That avoids quite a bit of this path fiddling. 

Will update. Thanks.

>  
> > +    /* update backend /local/domain/0/backend/<device>/<domid>/.../domain */ 
>  
> Um, what on earth creates that ? 
>  
> Worse, what reads it ? 
>  
> I think that putting this information in the backend directory is 
> entirely wrong. 
>  
> (Also, please use GCSPRINTF, libxl__xs_read_checked, etc., and keep 
> your lines to less than 75 characters or so.) 
>  
> Thanks, 
> Ian. 
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 02:37:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 02: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.xen.org>)
	id 1XqYfO-0006yM-IQ; Tue, 18 Nov 2014 02:37:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqYfN-0006yH-1V
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 02:37:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	51/A8-09842-CD0BA645; Tue, 18 Nov 2014 02:37:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416278234!13428349!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4406 invoked from network); 18 Nov 2014 02:37:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 02:37:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,407,1413244800"; d="scan'208";a="192322203"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 21:37:12 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqYfI-0000qi-EM;
	Tue, 18 Nov 2014 02:37:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqYfI-0007EU-35;
	Tue, 18 Nov 2014 02:37:12 +0000
Date: Tue, 18 Nov 2014 02:37:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31604-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31604: 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 31604 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31604/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3  3 host-install(3)    broken REGR. vs. 31489

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31489
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31489

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  902dfd33da08169f08a593a4ef2c45d825cca8c8
baseline version:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Emil Condrea <emilcondrea@gmail.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Juergen Gross <jgross@suse.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  M A Young <m.a.young@durham.ac.uk>
  Meng Xu <mengxu@cis.upenn.edu>
  Michael Young <m.a.young@durham.ac.uk>
  Olaf Hering <olaf@aepfle.de>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-qemut-winxpsp3 host-install(3)

Not pushing.

(No revision log; it would be 390 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 Nov 18 02:37:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 02: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.xen.org>)
	id 1XqYfO-0006yM-IQ; Tue, 18 Nov 2014 02:37:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqYfN-0006yH-1V
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 02:37:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	51/A8-09842-CD0BA645; Tue, 18 Nov 2014 02:37:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416278234!13428349!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4406 invoked from network); 18 Nov 2014 02:37:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 02:37:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,407,1413244800"; d="scan'208";a="192322203"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 17 Nov 2014 21:37:12 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqYfI-0000qi-EM;
	Tue, 18 Nov 2014 02:37:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqYfI-0007EU-35;
	Tue, 18 Nov 2014 02:37:12 +0000
Date: Tue, 18 Nov 2014 02:37:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31604-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31604: 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 31604 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31604/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3  3 host-install(3)    broken REGR. vs. 31489

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31489
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31489

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  902dfd33da08169f08a593a4ef2c45d825cca8c8
baseline version:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Emil Condrea <emilcondrea@gmail.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Juergen Gross <jgross@suse.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  M A Young <m.a.young@durham.ac.uk>
  Meng Xu <mengxu@cis.upenn.edu>
  Michael Young <m.a.young@durham.ac.uk>
  Olaf Hering <olaf@aepfle.de>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-qemut-winxpsp3 host-install(3)

Not pushing.

(No revision log; it would be 390 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 Nov 18 03:09:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 03:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqZ9h-0007Zt-8l; Tue, 18 Nov 2014 03:08:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqZ9g-0007Zn-Fj
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 03:08:36 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C3/AC-02696-338BA645; Tue, 18 Nov 2014 03:08:35 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416280112!8537580!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9153 invoked from network); 18 Nov 2014 03:08:33 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-27.messagelabs.com with SMTP;
	18 Nov 2014 03:08:33 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 17 Nov 2014 19:06:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,407,1413270000"; d="scan'208";a="609509217"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.124])
	([10.238.128.124])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 19:08:30 -0800
Message-ID: <546AB82D.5080305@intel.com>
Date: Tue, 18 Nov 2014 11:08:29 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
In-Reply-To: <5469EF5D0200007800048609@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/17 19:51, Jan Beulich wrote:
>>>> On 17.11.14 at 12:32, <tiejun.chen@intel.com> wrote:
>> On 2014/11/17 19:17, Jan Beulich wrote:
>>>>>> On 17.11.14 at 12:08, <tiejun.chen@intel.com> wrote:
>>>
>>>> On 2014/11/17 18:05, Jan Beulich wrote:
>>>>>>>> On 17.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
>>>>>> --- a/xen/common/memory.c
>>>>>> +++ b/xen/common/memory.c
>>>>>> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>>>>>>          unsigned int used_entries;
>>>>>>      };
>>>>>>
>>>>>> -static int get_reserved_device_memory(xen_pfn_t start,
>>>>>> -                                      xen_ulong_t nr, void *ctxt)
>>>>>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16
>>>> seg,
>>>>>> +                                      u16 *ids, int cnt, void *ctxt)
>>>>>
>>>>> While the approach is a lot better than what you did previously, I still
>>>>> don't like you adding 3 new parameters when one would do (calling
>>>>> the callback for each SBDF individually): That way you avoid
>>>>
>>>> Do you mean I should do this?
>>>>
>>>> for_each_rmrr_device ( rmrr, bdf, i )
>>>> {
>>>> 	 sbdf = PCI_SBDF(seg, rmrr->scope.devices[i]);
>>>>             rc = func(PFN_DOWN(rmrr->base_address),
>>>>                       PFN_UP(rmrr->end_address) -
>>>> PFN_DOWN(rmrr->base_address),
>>>> 		   sbdf,	
>>>>                       ctxt);
>>>>
>>>> But each different sbdf may occupy one same rmrr entry as I said
>>>> previously, so we have to introduce more codes to filter them as one
>>>> identified entry in the callback.
>>>
>>> Not really - remember that part of what needs to be done is to make
>>> sure all devices associated with a given RMRR get assigned to the
>>> same guest? Or the callback function could use a special return value
>>
>> Yes, but I means in the callback,
>>
>> get_reserved_device_memory()
>> {
>> 	...
>> 	for(each assigned pci devs:pt_sbdf)
>> 		if (sbdf == pt_sbdf)
>> 			__copy_to_guest_offset(buffer, ...)
>>
>> Buffer may be copied to include multiple same entries if we have two or
>> more assigned devices associated to one give RMRR entry.
>
> Which would be easily avoided by ...
>
>>> (e.g. 1) to signal that the iteration for the current RMRR can be
>>> terminated (or further entries skipped).
>
> ... the approach I outlined.
>

Here I tried to implement what you want. Note just pick two key 
fragments since others have no big deal.

#1:

@@ -898,14 +898,25 @@ int 
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
      int rc = 0;
+    unsigned int i;
+    u32 id;
+    u16 bdf;

      list_for_each_entry(rmrr, &acpi_rmrr_units, list)
      {
-        rc = func(PFN_DOWN(rmrr->base_address),
-                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
-                  ctxt);
-        if ( rc )
-            break;
+        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
+                    i < rmrr->scope.devices_cnt && !rc; i++)
+        {
+            id = PCI_SBDF(rmrr->segment, bdf);
+            rc = func(PFN_DOWN(rmrr->base_address),
+                               PFN_UP(rmrr->end_address) -
+                                PFN_DOWN(rmrr->base_address),
+                               id,
+                               ctxt);
+            if ( rc < 0 )
+                return rc;
+        }
+        rc = 0;
      }

      return rc;


and #2,

@@ -698,10 +698,13 @@ struct get_reserved_device_memory {
      unsigned int used_entries;
  };

-static int get_reserved_device_memory(xen_pfn_t start,
-                                      xen_ulong_t nr, void *ctxt)
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+                                      u32 id, void *ctxt)
  {
      struct get_reserved_device_memory *grdm = ctxt;
+    struct domain *d = get_domain_by_id(grdm->map.domid);
+    unsigned int i;
+    u32 sbdf;

      if ( grdm->used_entries < grdm->map.nr_entries )
      {
@@ -709,13 +712,34 @@ static int get_reserved_device_memory(xen_pfn_t start,
              .start_pfn = start, .nr_pages = nr
          };

-        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
-                                    &rdm, 1) )
-            return -EFAULT;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( __copy_to_guest_offset(grdm->map.buffer, 
grdm->used_entries,
+                                        &rdm, 1) )
+                return -EFAULT;
+            ++grdm->used_entries;
+            return 1;
+        }
+        else
+        {
+            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
+            {
+                sbdf = PCI_SBDF2(d->arch.hvm_domain.pcidevs[i].seg,
+                                 d->arch.hvm_domain.pcidevs[i].bus,
+                                 d->arch.hvm_domain.pcidevs[i].devfn);
+                if ( sbdf == id )
+                {
+                    if ( __copy_to_guest_offset(grdm->map.buffer,
+                                                grdm->used_entries,
+                                                &rdm, 1) )
+                        return -EFAULT;
+                    ++grdm->used_entries;
+                    return 1;
+                }
+            }
+        }
      }

-    ++grdm->used_entries;
-
      return 0;
  }
  #endif


Thanks
Tiejun


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 03:09:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 03:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqZ9h-0007Zt-8l; Tue, 18 Nov 2014 03:08:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqZ9g-0007Zn-Fj
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 03:08:36 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C3/AC-02696-338BA645; Tue, 18 Nov 2014 03:08:35 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416280112!8537580!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9153 invoked from network); 18 Nov 2014 03:08:33 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-27.messagelabs.com with SMTP;
	18 Nov 2014 03:08:33 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 17 Nov 2014 19:06:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,407,1413270000"; d="scan'208";a="609509217"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.124])
	([10.238.128.124])
	by orsmga001.jf.intel.com with ESMTP; 17 Nov 2014 19:08:30 -0800
Message-ID: <546AB82D.5080305@intel.com>
Date: Tue, 18 Nov 2014 11:08:29 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
In-Reply-To: <5469EF5D0200007800048609@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/17 19:51, Jan Beulich wrote:
>>>> On 17.11.14 at 12:32, <tiejun.chen@intel.com> wrote:
>> On 2014/11/17 19:17, Jan Beulich wrote:
>>>>>> On 17.11.14 at 12:08, <tiejun.chen@intel.com> wrote:
>>>
>>>> On 2014/11/17 18:05, Jan Beulich wrote:
>>>>>>>> On 17.11.14 at 08:57, <tiejun.chen@intel.com> wrote:
>>>>>> --- a/xen/common/memory.c
>>>>>> +++ b/xen/common/memory.c
>>>>>> @@ -698,10 +698,13 @@ struct get_reserved_device_memory {
>>>>>>          unsigned int used_entries;
>>>>>>      };
>>>>>>
>>>>>> -static int get_reserved_device_memory(xen_pfn_t start,
>>>>>> -                                      xen_ulong_t nr, void *ctxt)
>>>>>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr, u16
>>>> seg,
>>>>>> +                                      u16 *ids, int cnt, void *ctxt)
>>>>>
>>>>> While the approach is a lot better than what you did previously, I still
>>>>> don't like you adding 3 new parameters when one would do (calling
>>>>> the callback for each SBDF individually): That way you avoid
>>>>
>>>> Do you mean I should do this?
>>>>
>>>> for_each_rmrr_device ( rmrr, bdf, i )
>>>> {
>>>> 	 sbdf = PCI_SBDF(seg, rmrr->scope.devices[i]);
>>>>             rc = func(PFN_DOWN(rmrr->base_address),
>>>>                       PFN_UP(rmrr->end_address) -
>>>> PFN_DOWN(rmrr->base_address),
>>>> 		   sbdf,	
>>>>                       ctxt);
>>>>
>>>> But each different sbdf may occupy one same rmrr entry as I said
>>>> previously, so we have to introduce more codes to filter them as one
>>>> identified entry in the callback.
>>>
>>> Not really - remember that part of what needs to be done is to make
>>> sure all devices associated with a given RMRR get assigned to the
>>> same guest? Or the callback function could use a special return value
>>
>> Yes, but I means in the callback,
>>
>> get_reserved_device_memory()
>> {
>> 	...
>> 	for(each assigned pci devs:pt_sbdf)
>> 		if (sbdf == pt_sbdf)
>> 			__copy_to_guest_offset(buffer, ...)
>>
>> Buffer may be copied to include multiple same entries if we have two or
>> more assigned devices associated to one give RMRR entry.
>
> Which would be easily avoided by ...
>
>>> (e.g. 1) to signal that the iteration for the current RMRR can be
>>> terminated (or further entries skipped).
>
> ... the approach I outlined.
>

Here I tried to implement what you want. Note just pick two key 
fragments since others have no big deal.

#1:

@@ -898,14 +898,25 @@ int 
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
  {
      struct acpi_rmrr_unit *rmrr;
      int rc = 0;
+    unsigned int i;
+    u32 id;
+    u16 bdf;

      list_for_each_entry(rmrr, &acpi_rmrr_units, list)
      {
-        rc = func(PFN_DOWN(rmrr->base_address),
-                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
-                  ctxt);
-        if ( rc )
-            break;
+        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
+                    i < rmrr->scope.devices_cnt && !rc; i++)
+        {
+            id = PCI_SBDF(rmrr->segment, bdf);
+            rc = func(PFN_DOWN(rmrr->base_address),
+                               PFN_UP(rmrr->end_address) -
+                                PFN_DOWN(rmrr->base_address),
+                               id,
+                               ctxt);
+            if ( rc < 0 )
+                return rc;
+        }
+        rc = 0;
      }

      return rc;


and #2,

@@ -698,10 +698,13 @@ struct get_reserved_device_memory {
      unsigned int used_entries;
  };

-static int get_reserved_device_memory(xen_pfn_t start,
-                                      xen_ulong_t nr, void *ctxt)
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+                                      u32 id, void *ctxt)
  {
      struct get_reserved_device_memory *grdm = ctxt;
+    struct domain *d = get_domain_by_id(grdm->map.domid);
+    unsigned int i;
+    u32 sbdf;

      if ( grdm->used_entries < grdm->map.nr_entries )
      {
@@ -709,13 +712,34 @@ static int get_reserved_device_memory(xen_pfn_t start,
              .start_pfn = start, .nr_pages = nr
          };

-        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
-                                    &rdm, 1) )
-            return -EFAULT;
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( __copy_to_guest_offset(grdm->map.buffer, 
grdm->used_entries,
+                                        &rdm, 1) )
+                return -EFAULT;
+            ++grdm->used_entries;
+            return 1;
+        }
+        else
+        {
+            for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
+            {
+                sbdf = PCI_SBDF2(d->arch.hvm_domain.pcidevs[i].seg,
+                                 d->arch.hvm_domain.pcidevs[i].bus,
+                                 d->arch.hvm_domain.pcidevs[i].devfn);
+                if ( sbdf == id )
+                {
+                    if ( __copy_to_guest_offset(grdm->map.buffer,
+                                                grdm->used_entries,
+                                                &rdm, 1) )
+                        return -EFAULT;
+                    ++grdm->used_entries;
+                    return 1;
+                }
+            }
+        }
      }

-    ++grdm->used_entries;
-
      return 0;
  }
  #endif


Thanks
Tiejun


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 04:35:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 04: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 1XqaVK-0008Hs-KI; Tue, 18 Nov 2014 04:35:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XqaVJ-0008Hn-F9
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 04:35:01 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	8F/BE-02696-47CCA645; Tue, 18 Nov 2014 04:35:00 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416285296!13177237!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22560 invoked from network); 18 Nov 2014 04:34:58 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 04:34:58 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 17 Nov 2014 21:34:43 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 18 Nov 2014 12:34:30 +0800
Message-Id: <1416285270-14768-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH v2] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently libxl__domain_rename only update /local/domain/<domid>/name,
still some places in xenstore are not updated, including:
/vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.

This patch updates /vm/<uuid>/name in xenstore, and removes the unusual
'domain' field under backend directory (the affected are backend/console,
backend/vfb, backend/vkb).

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
Changes:
  * remove unusual 'domain' field from backend dir
  * get uuid from hypervisor rather then from xenstore

 tools/libxl/libxl.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..197433c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
     uint32_t stub_dm_domid;
     const char *stub_dm_old_name = NULL, *stub_dm_new_name = NULL;
     int rc;
+    libxl_dominfo info;
+    char *uuid;
+    const char *vm_name_path;
 
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) goto x_nomem;
@@ -429,6 +432,21 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
         goto x_fail;
     }
 
+    /* update /vm/<uuid>/name */
+    rc = libxl_domain_info(ctx, &info, domid);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                  "fail to get domain info for domain %d", domid);
+        goto x_fail;
+    }
+    uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
+    vm_name_path = GCSPRINTF("/vm/%s/name", uuid);
+    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
+                   " to %s", new_name, vm_name_path);
+        goto x_fail;
+    }
+
     if (stub_dm_domid) {
         rc = libxl__domain_rename(gc, stub_dm_domid,
                                   stub_dm_old_name,
@@ -3605,8 +3623,6 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
     flexarray_append(back, "1");
     flexarray_append(back, "state");
     flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(gc, domid));
     flexarray_append(back, "protocol");
     flexarray_append(back, LIBXL_XENCONSOLE_PROTOCOL);
 
@@ -3943,8 +3959,6 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
     flexarray_append(back, "1");
     flexarray_append(back, "state");
     flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(gc, domid));
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid));
@@ -4041,7 +4055,6 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb)
     flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
     flexarray_append_pair(back, "online", "1");
     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_defbool_val(vfb->vnc.enable) ? "1" : "0");
     flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 04:35:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 04: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 1XqaVK-0008Hs-KI; Tue, 18 Nov 2014 04:35:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XqaVJ-0008Hn-F9
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 04:35:01 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	8F/BE-02696-47CCA645; Tue, 18 Nov 2014 04:35:00 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416285296!13177237!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22560 invoked from network); 18 Nov 2014 04:34:58 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 04:34:58 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 17 Nov 2014 21:34:43 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 18 Nov 2014 12:34:30 +0800
Message-Id: <1416285270-14768-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH v2] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently libxl__domain_rename only update /local/domain/<domid>/name,
still some places in xenstore are not updated, including:
/vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.

This patch updates /vm/<uuid>/name in xenstore, and removes the unusual
'domain' field under backend directory (the affected are backend/console,
backend/vfb, backend/vkb).

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
Changes:
  * remove unusual 'domain' field from backend dir
  * get uuid from hypervisor rather then from xenstore

 tools/libxl/libxl.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..197433c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
     uint32_t stub_dm_domid;
     const char *stub_dm_old_name = NULL, *stub_dm_new_name = NULL;
     int rc;
+    libxl_dominfo info;
+    char *uuid;
+    const char *vm_name_path;
 
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) goto x_nomem;
@@ -429,6 +432,21 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
         goto x_fail;
     }
 
+    /* update /vm/<uuid>/name */
+    rc = libxl_domain_info(ctx, &info, domid);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                  "fail to get domain info for domain %d", domid);
+        goto x_fail;
+    }
+    uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
+    vm_name_path = GCSPRINTF("/vm/%s/name", uuid);
+    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
+                   " to %s", new_name, vm_name_path);
+        goto x_fail;
+    }
+
     if (stub_dm_domid) {
         rc = libxl__domain_rename(gc, stub_dm_domid,
                                   stub_dm_old_name,
@@ -3605,8 +3623,6 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
     flexarray_append(back, "1");
     flexarray_append(back, "state");
     flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(gc, domid));
     flexarray_append(back, "protocol");
     flexarray_append(back, LIBXL_XENCONSOLE_PROTOCOL);
 
@@ -3943,8 +3959,6 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
     flexarray_append(back, "1");
     flexarray_append(back, "state");
     flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(gc, domid));
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid));
@@ -4041,7 +4055,6 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb)
     flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
     flexarray_append_pair(back, "online", "1");
     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_defbool_val(vfb->vnc.enable) ? "1" : "0");
     flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 05:00:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 05: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 1Xqatq-0000KE-3J; Tue, 18 Nov 2014 05:00: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@citrix.com>) id 1Xqato-0000K8-I5
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 05:00:20 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	7D/0F-29352-362DA645; Tue, 18 Nov 2014 05:00:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416286817!6611327!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28363 invoked from network); 18 Nov 2014 05:00:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 05:00:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="193847699"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 00:00:16 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqatj-0001XJ-Lp;
	Tue, 18 Nov 2014 05:00:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqatj-00078u-D9;
	Tue, 18 Nov 2014 05:00:15 +0000
Date: Tue, 18 Nov 2014 05:00:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31647-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31647: 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 31647 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31647/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51
baseline version:
 qemuu                abbbc2f09a53f8f9ee565356ab11a78af006e45e

------------------------------------------------------------
People who touched revisions under test:
  Igor Mammedov <imammedo@redhat.com>
  Li Liang <liang.z.li@intel.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51
+ branch=qemu-upstream-unstable
+ revision=0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : 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
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
   abbbc2f..0c94ca5  0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 05:00:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 05: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 1Xqatq-0000KE-3J; Tue, 18 Nov 2014 05:00: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@citrix.com>) id 1Xqato-0000K8-I5
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 05:00:20 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	7D/0F-29352-362DA645; Tue, 18 Nov 2014 05:00:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416286817!6611327!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28363 invoked from network); 18 Nov 2014 05:00:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 05:00:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="193847699"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 00:00:16 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqatj-0001XJ-Lp;
	Tue, 18 Nov 2014 05:00:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqatj-00078u-D9;
	Tue, 18 Nov 2014 05:00:15 +0000
Date: Tue, 18 Nov 2014 05:00:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31647-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31647: 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 31647 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31647/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51
baseline version:
 qemuu                abbbc2f09a53f8f9ee565356ab11a78af006e45e

------------------------------------------------------------
People who touched revisions under test:
  Igor Mammedov <imammedo@redhat.com>
  Li Liang <liang.z.li@intel.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51
+ branch=qemu-upstream-unstable
+ revision=0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : 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
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
   abbbc2f..0c94ca5  0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 05:33:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 05:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqbPu-0000hM-Rt; Tue, 18 Nov 2014 05:33:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XqbPt-0000hC-6Q
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 05:33:29 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	77/E3-28296-82ADA645; Tue, 18 Nov 2014 05:33:28 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416288807!12057749!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26623 invoked from network); 18 Nov 2014 05:33:27 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 05:33:27 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A3C25AAC3;
	Tue, 18 Nov 2014 05:33:26 +0000 (UTC)
Message-ID: <546ADA25.4000709@suse.com>
Date: Tue, 18 Nov 2014 06:33:25 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	xen-devel@lists.xensource.com, jbeulich@suse.com, 
	konrad.wilk@oracle.com, david.vrabel@citrix.com
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>	<5465FB34.9010606@suse.com>	<54660A16.2090006@citrix.com>	<54660E5C.8030107@suse.com>	<546618D9.5070200@citrix.com>	<54662096.6060603@suse.com>
	<546628F7.4000008@citrix.com>
In-Reply-To: <546628F7.4000008@citrix.com>
Content-Length: 6712
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 05:08 PM, Andrew Cooper wrote:
> On 14/11/14 15:32, Juergen Gross wrote:
>> On 11/14/2014 03:59 PM, Andrew Cooper wrote:
>>> On 14/11/14 14:14, J=FCrgen Gro=DF wrote:
>>>> On 11/14/2014 02:56 PM, Andrew Cooper wrote:
>>>>> On 14/11/14 12:53, Juergen Gross wrote:
>>>>>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>>>>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>>>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>>>>>> currently contains the mfn of the top level page frame of the 3
>>>>>>>> level
>>>>>>>> p2m tree, which is used by the Xen tools during saving and
>>>>>>>> restoring
>>>>>>>> (and live migration) of pv domains and for crash dump analysis.
>>>>>>>> With
>>>>>>>> three levels of the p2m tree it is possible to support up to 512
>>>>>>>> GB of
>>>>>>>> RAM for a 64 bit pv domain.
>>>>>>>>
>>>>>>>> A 32 bit pv domain can support more, as each memory page can hold
>>>>>>>> 1024
>>>>>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>>>>>
>>>>>>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>>>>>>> p2m list.
>>>>>>>>
>>>>>>>> This patch expands struct arch_shared_info with a new p2m list
>>>>>>>> virtual
>>>>>>>> address and the mfn of the page table root. The new information is
>>>>>>>> indicated by the domain to be valid by storing ~0UL into
>>>>>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of
>>>>>>>> this
>>>>>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>>>>>
>>>>>>> How do you envisage this being used?  Are you expecting the tools
>>>>>>> to do
>>>>>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>>>>>
>>>>>> Yes. Not very different compared to today's mapping via the 3 level
>>>>>> p2m tree. Just another entry format, 4 instead of 3 levels and
>>>>>> starting
>>>>>> at an offset.
>>>>>
>>>>> Yes - David and I were discussing this over lunch, and it is not
>>>>> actually very different.
>>>>>
>>>>> In reality, how likely is it that the pages backing this virtual
>>>>> linear
>>>>> array change?
>>>>
>>>> Very unlikely, I think. But not impossible.
>>>>
>>>>> One issue currently is that, during the live part of migration, the
>>>>> toolstack has no way of working out whether the structure of the
>>>>> p2m has
>>>>> changed (intermediate leaves rearranged, or the length increasing).
>>>>>
>>>>> In the case that the VM does change the structure of the p2m under the
>>>>> feet of the toolstack, migration will either blow up in a
>>>>> non-subtle way
>>>>> with a p2m/m2p mismatch, or in a subtle way with the receiving side
>>>>> copying the new p2m over the wrong part of the new domain.
>>>>>
>>>>> I am wondering whether, with this new p2m method, we can take
>>>>> sufficient
>>>>> steps to be able to guarantee mishaps like this can't occur.
>>>>
>>>> This should be easy: I could add a counter in arch_shared_info which is
>>>> incremented whenever a p2m mapping is being changed. The toolstack
>>>> could
>>>> compare the counter values before start and at end of migration and
>>>> redo
>>>> the migration (or fail) if they are different. In order to avoid races
>>>> I would have to increment the counter before and after changing the
>>>> mapping.
>>>>
>>>
>>> That is insufficient I believe.
>>>
>>> Consider:
>>>
>>> * Toolstack walks pagetables and maps the frames containing the
>>> linear p2m
>>> * Live migration starts
>>> * VM remaps a frame in the middle of the linear p2m
>>> * Live migration continues, but the toolstack has a stale frame in the
>>> middle of its view of the p2m.
>>
>> This would be covered by my suggestion. At the end of the memory
>> transfer (with some bogus contents) the toolstack would discover the
>> change of the p2m structure and either fail the migration or start it
>> from the beginning and thus overwriting the bogus frames.
>
> Checking after pause is too late.  The content of the p2m is used verify
> each frame being sent on the wire, so is in active use for the entire
> duration of live migration.
>
> If the toolstack starts verifying frames being sent using information
> from a stale p2m, the best that can be hoped for is that the toolstack
> declares that the p2m and m2p are inconsistent and abort the migrate.
>
>>
>>> As the p2m is almost never expected to change, I think it might be
>>> better to have a flag the toolstack can set to say "The toolstack is
>>> peeking at your p2m behind your back - you must not change its
>>> structure."
>>
>> Be careful here: changes of the structure can be due to two scenarios:
>> - ballooning (invalid entries being populated): this is no problem, as
>>    we can stop the ballooning during live migration.
>> - mapping of grant pages e.g. in a stub domain (first map in an area
>>    former marked as invalid): you can't stop this, as the stub domain
>>    has to do some work. Here a restart of the migration should work, as
>>    the p2m structure change can only happen once for each affected p2m
>>    page.
>
> Migration is not at all possible with a domain referencing foreign frames.
>
> The live part can cope with foreign frames referenced in the ptes.  As
> part of the pause handling in the VM, the frontends must unmap any
> grants they have.  After pause, any remaining foreign frames cause a
> migration failure.
>
>>
>>> Having just thought this through, I think there is also a race condition
>>> between a VM changing an entry in the p2m, and the toolstack doing
>>> verifications of frames being sent.
>>
>> Okay, so the flag you mentioned should just prohibit changes in the
>> p2m list related to memory frames of the affected domain: ballooning
>> up or down, or rearranging the memory layout (does this happen today?).
>> Mapping and unmapping of grant pages should be still allowed.
>
> HVM guests doesn't have any of their p2m updates represented in the
> logdirty bitmap, so ballooning an HVM guest during migrate leads to
> unexpected holes or lack of holes on the resuming side, leading to a
> very confused balloon driver.
>
> At the time I had not found a problem with PV guests, but it is now
> clear that there is a period of time when a guest is altering its p2m
> where the p2m and m2p are out of sync, which will cause a migration
> failure if the toolstack observes this artefact.

So ballooning should be disabled during migration. I think this should
be handled via callbacks triggered by xenstore: one at start of
migration to stop ballooning and one at end to restart it. I wouldn't
want to tie this functionality to the p2m list structure, as it is
not related to it.

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 05:33:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 05:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqbPu-0000hM-Rt; Tue, 18 Nov 2014 05:33:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XqbPt-0000hC-6Q
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 05:33:29 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	77/E3-28296-82ADA645; Tue, 18 Nov 2014 05:33:28 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416288807!12057749!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26623 invoked from network); 18 Nov 2014 05:33:27 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 05:33:27 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A3C25AAC3;
	Tue, 18 Nov 2014 05:33:26 +0000 (UTC)
Message-ID: <546ADA25.4000709@suse.com>
Date: Tue, 18 Nov 2014 06:33:25 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	xen-devel@lists.xensource.com, jbeulich@suse.com, 
	konrad.wilk@oracle.com, david.vrabel@citrix.com
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>	<5465FB34.9010606@suse.com>	<54660A16.2090006@citrix.com>	<54660E5C.8030107@suse.com>	<546618D9.5070200@citrix.com>	<54662096.6060603@suse.com>
	<546628F7.4000008@citrix.com>
In-Reply-To: <546628F7.4000008@citrix.com>
Content-Length: 6712
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 05:08 PM, Andrew Cooper wrote:
> On 14/11/14 15:32, Juergen Gross wrote:
>> On 11/14/2014 03:59 PM, Andrew Cooper wrote:
>>> On 14/11/14 14:14, J=FCrgen Gro=DF wrote:
>>>> On 11/14/2014 02:56 PM, Andrew Cooper wrote:
>>>>> On 14/11/14 12:53, Juergen Gross wrote:
>>>>>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>>>>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>>>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>>>>>> currently contains the mfn of the top level page frame of the 3
>>>>>>>> level
>>>>>>>> p2m tree, which is used by the Xen tools during saving and
>>>>>>>> restoring
>>>>>>>> (and live migration) of pv domains and for crash dump analysis.
>>>>>>>> With
>>>>>>>> three levels of the p2m tree it is possible to support up to 512
>>>>>>>> GB of
>>>>>>>> RAM for a 64 bit pv domain.
>>>>>>>>
>>>>>>>> A 32 bit pv domain can support more, as each memory page can hold
>>>>>>>> 1024
>>>>>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>>>>>
>>>>>>>> To be able to support more RAM on x86-64 switch to a virtual mapped
>>>>>>>> p2m list.
>>>>>>>>
>>>>>>>> This patch expands struct arch_shared_info with a new p2m list
>>>>>>>> virtual
>>>>>>>> address and the mfn of the page table root. The new information is
>>>>>>>> indicated by the domain to be valid by storing ~0UL into
>>>>>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of
>>>>>>>> this
>>>>>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>>>>>
>>>>>>> How do you envisage this being used?  Are you expecting the tools
>>>>>>> to do
>>>>>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>>>>>
>>>>>> Yes. Not very different compared to today's mapping via the 3 level
>>>>>> p2m tree. Just another entry format, 4 instead of 3 levels and
>>>>>> starting
>>>>>> at an offset.
>>>>>
>>>>> Yes - David and I were discussing this over lunch, and it is not
>>>>> actually very different.
>>>>>
>>>>> In reality, how likely is it that the pages backing this virtual
>>>>> linear
>>>>> array change?
>>>>
>>>> Very unlikely, I think. But not impossible.
>>>>
>>>>> One issue currently is that, during the live part of migration, the
>>>>> toolstack has no way of working out whether the structure of the
>>>>> p2m has
>>>>> changed (intermediate leaves rearranged, or the length increasing).
>>>>>
>>>>> In the case that the VM does change the structure of the p2m under the
>>>>> feet of the toolstack, migration will either blow up in a
>>>>> non-subtle way
>>>>> with a p2m/m2p mismatch, or in a subtle way with the receiving side
>>>>> copying the new p2m over the wrong part of the new domain.
>>>>>
>>>>> I am wondering whether, with this new p2m method, we can take
>>>>> sufficient
>>>>> steps to be able to guarantee mishaps like this can't occur.
>>>>
>>>> This should be easy: I could add a counter in arch_shared_info which is
>>>> incremented whenever a p2m mapping is being changed. The toolstack
>>>> could
>>>> compare the counter values before start and at end of migration and
>>>> redo
>>>> the migration (or fail) if they are different. In order to avoid races
>>>> I would have to increment the counter before and after changing the
>>>> mapping.
>>>>
>>>
>>> That is insufficient I believe.
>>>
>>> Consider:
>>>
>>> * Toolstack walks pagetables and maps the frames containing the
>>> linear p2m
>>> * Live migration starts
>>> * VM remaps a frame in the middle of the linear p2m
>>> * Live migration continues, but the toolstack has a stale frame in the
>>> middle of its view of the p2m.
>>
>> This would be covered by my suggestion. At the end of the memory
>> transfer (with some bogus contents) the toolstack would discover the
>> change of the p2m structure and either fail the migration or start it
>> from the beginning and thus overwriting the bogus frames.
>
> Checking after pause is too late.  The content of the p2m is used verify
> each frame being sent on the wire, so is in active use for the entire
> duration of live migration.
>
> If the toolstack starts verifying frames being sent using information
> from a stale p2m, the best that can be hoped for is that the toolstack
> declares that the p2m and m2p are inconsistent and abort the migrate.
>
>>
>>> As the p2m is almost never expected to change, I think it might be
>>> better to have a flag the toolstack can set to say "The toolstack is
>>> peeking at your p2m behind your back - you must not change its
>>> structure."
>>
>> Be careful here: changes of the structure can be due to two scenarios:
>> - ballooning (invalid entries being populated): this is no problem, as
>>    we can stop the ballooning during live migration.
>> - mapping of grant pages e.g. in a stub domain (first map in an area
>>    former marked as invalid): you can't stop this, as the stub domain
>>    has to do some work. Here a restart of the migration should work, as
>>    the p2m structure change can only happen once for each affected p2m
>>    page.
>
> Migration is not at all possible with a domain referencing foreign frames.
>
> The live part can cope with foreign frames referenced in the ptes.  As
> part of the pause handling in the VM, the frontends must unmap any
> grants they have.  After pause, any remaining foreign frames cause a
> migration failure.
>
>>
>>> Having just thought this through, I think there is also a race condition
>>> between a VM changing an entry in the p2m, and the toolstack doing
>>> verifications of frames being sent.
>>
>> Okay, so the flag you mentioned should just prohibit changes in the
>> p2m list related to memory frames of the affected domain: ballooning
>> up or down, or rearranging the memory layout (does this happen today?).
>> Mapping and unmapping of grant pages should be still allowed.
>
> HVM guests doesn't have any of their p2m updates represented in the
> logdirty bitmap, so ballooning an HVM guest during migrate leads to
> unexpected holes or lack of holes on the resuming side, leading to a
> very confused balloon driver.
>
> At the time I had not found a problem with PV guests, but it is now
> clear that there is a period of time when a guest is altering its p2m
> where the p2m and m2p are out of sync, which will cause a migration
> failure if the toolstack observes this artefact.

So ballooning should be disabled during migration. I think this should
be handled via callbacks triggered by xenstore: one at start of
migration to stop ballooning and one at end to restart it. I wouldn't
want to tie this functionality to the p2m list structure, as it is
not related to it.

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 07:31:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 07:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqdFw-0001W3-A8; Tue, 18 Nov 2014 07:31:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqdFu-0001Vy-D3
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 07:31:18 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	CC/6E-03145-BB5FA645; Tue, 18 Nov 2014 07:31:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416295866!13174395!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26331 invoked from network); 18 Nov 2014 07:31:06 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 07:31:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 07:31:03 +0000
Message-Id: <546B03C60200007800048A2E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 07:31:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Razvan Cojocaru" <rcojocaru@bitdefender.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
	<546A32720200007800048873@mail.emea.novell.com>
	<546A25BC.3020000@bitdefender.com>
In-Reply-To: <546A25BC.3020000@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	eddie.dong@intel.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 17:43, <rcojocaru@bitdefender.com> wrote:
> On 11/17/2014 06:37 PM, Jan Beulich wrote:
>>>>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
>>> On 12/11/14 15:31, Tamas K Lengyel wrote:
>>>>  xen/include/public/domctl.h         |  44 +--
>>>>  xen/include/public/hvm/params.h     |   2 +-
>>>>  xen/include/public/mem_event.h      | 134 -------
>>>>  xen/include/public/memory.h         |   6 +-
>>>>  xen/include/public/vm_event.h       | 179 +++++++++
>>>
>>> While in principle I think this series is a very good thing, there is a
>>> problem with editing the pubic header files.
>>>
>>> The contents of mem_event.h is not currently hidden behind #ifdef
>>> __XEN_TOOLS__
>>>
>>> As a result, it is strictly speaking part of the VM-visible public
>>> API/ABI and not permitted to change in a backwards incompatible manor.
>>>
>>> Having said that, it is currently only usable by privileged domains, so
>>> there is an argument to be made for declaring that it should have been
>>> hidden behind __XEN_TOOLS__ in the first place, making it permittable to
>>> change.
>> 
>> I'm not sure I agree - the meaning of "tools" here would seem quite a
>> bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
>> an old consumer (remember that for many of these we have at best
>> fake consumers in the tree) would deal with the now differently
>> arranged data. I don't see any versioning of the interface, and hence
>> I can't see how tools would know which of the formats to expect.
> 
> In the initial patch I've sent Tamas I had arranged things as follows,
> (so that the layout would stay compatible) but I think we ended up
> discussing it and deciding it would look cleaner to just re-do the whole
> thing:
> 
> +struct mem_event_ept_data {
> +    uint64_t gfn;
> +    uint64_t offset;
> +    uint64_t gla; /* if gla_valid */
> +};
> +
> +struct mem_event_cr_data {
> +    uint64_t new_value;
> +    uint64_t _pad;
> +    uint64_t old_value;
> +};
> +
> +struct mem_event_int3_data {
> +    uint64_t gfn;
> +    uint64_t _pad;
> +    uint64_t eip;
> +};
> +
> +struct mem_event_singlestep_data {
> +    uint64_t gfn;
> +    uint64_t _pad;
> +    uint64_t eip;
> +};
> +
> +struct mem_event_msr_data {
> +    uint64_t msr;
> +    uint64_t old_value;
> +    uint64_t new_value;
> +};
> +
>  typedef struct mem_event_st {
>      uint32_t flags;
>      uint32_t vcpu_id;
> 
> -    uint64_t gfn;
> -    uint64_t offset;
> -    uint64_t gla; /* if gla_valid */
> +    union {
> +        struct mem_event_ept_data        ept_event;
> +        struct mem_event_cr_data         cr_event;
> +        struct mem_event_int3_data       int3_event;
> +        struct mem_event_singlestep_data singlestep_event;
> +        struct mem_event_msr_data        msr_event;
> +    };
> 
>      uint32_t p2mt;
> 
> Would something like this be more along the right lines?

Yes, afaic. But tool stack and mm maintainers need to be on the same
page before you should take this as the final route to follow.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 07:31:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 07:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqdFw-0001W3-A8; Tue, 18 Nov 2014 07:31:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqdFu-0001Vy-D3
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 07:31:18 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	CC/6E-03145-BB5FA645; Tue, 18 Nov 2014 07:31:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416295866!13174395!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26331 invoked from network); 18 Nov 2014 07:31:06 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 07:31:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 07:31:03 +0000
Message-Id: <546B03C60200007800048A2E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 07:31:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Razvan Cojocaru" <rcojocaru@bitdefender.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
	<546A32720200007800048873@mail.emea.novell.com>
	<546A25BC.3020000@bitdefender.com>
In-Reply-To: <546A25BC.3020000@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	eddie.dong@intel.com, andres@lagarcavilla.org, jun.nakajima@intel.com,
	Tamas K Lengyel <tamas.lengyel@zentific.com>, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 17:43, <rcojocaru@bitdefender.com> wrote:
> On 11/17/2014 06:37 PM, Jan Beulich wrote:
>>>>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
>>> On 12/11/14 15:31, Tamas K Lengyel wrote:
>>>>  xen/include/public/domctl.h         |  44 +--
>>>>  xen/include/public/hvm/params.h     |   2 +-
>>>>  xen/include/public/mem_event.h      | 134 -------
>>>>  xen/include/public/memory.h         |   6 +-
>>>>  xen/include/public/vm_event.h       | 179 +++++++++
>>>
>>> While in principle I think this series is a very good thing, there is a
>>> problem with editing the pubic header files.
>>>
>>> The contents of mem_event.h is not currently hidden behind #ifdef
>>> __XEN_TOOLS__
>>>
>>> As a result, it is strictly speaking part of the VM-visible public
>>> API/ABI and not permitted to change in a backwards incompatible manor.
>>>
>>> Having said that, it is currently only usable by privileged domains, so
>>> there is an argument to be made for declaring that it should have been
>>> hidden behind __XEN_TOOLS__ in the first place, making it permittable to
>>> change.
>> 
>> I'm not sure I agree - the meaning of "tools" here would seem quite a
>> bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
>> an old consumer (remember that for many of these we have at best
>> fake consumers in the tree) would deal with the now differently
>> arranged data. I don't see any versioning of the interface, and hence
>> I can't see how tools would know which of the formats to expect.
> 
> In the initial patch I've sent Tamas I had arranged things as follows,
> (so that the layout would stay compatible) but I think we ended up
> discussing it and deciding it would look cleaner to just re-do the whole
> thing:
> 
> +struct mem_event_ept_data {
> +    uint64_t gfn;
> +    uint64_t offset;
> +    uint64_t gla; /* if gla_valid */
> +};
> +
> +struct mem_event_cr_data {
> +    uint64_t new_value;
> +    uint64_t _pad;
> +    uint64_t old_value;
> +};
> +
> +struct mem_event_int3_data {
> +    uint64_t gfn;
> +    uint64_t _pad;
> +    uint64_t eip;
> +};
> +
> +struct mem_event_singlestep_data {
> +    uint64_t gfn;
> +    uint64_t _pad;
> +    uint64_t eip;
> +};
> +
> +struct mem_event_msr_data {
> +    uint64_t msr;
> +    uint64_t old_value;
> +    uint64_t new_value;
> +};
> +
>  typedef struct mem_event_st {
>      uint32_t flags;
>      uint32_t vcpu_id;
> 
> -    uint64_t gfn;
> -    uint64_t offset;
> -    uint64_t gla; /* if gla_valid */
> +    union {
> +        struct mem_event_ept_data        ept_event;
> +        struct mem_event_cr_data         cr_event;
> +        struct mem_event_int3_data       int3_event;
> +        struct mem_event_singlestep_data singlestep_event;
> +        struct mem_event_msr_data        msr_event;
> +    };
> 
>      uint32_t p2mt;
> 
> Would something like this be more along the right lines?

Yes, afaic. But tool stack and mm maintainers need to be on the same
page before you should take this as the final route to follow.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 07:32:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 07:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqdH3-0001bW-0G; Tue, 18 Nov 2014 07:32:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqdH2-0001bL-7Q
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 07:32:28 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	F7/6F-26652-B06FA645; Tue, 18 Nov 2014 07:32:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416295946!11899191!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9964 invoked from network); 18 Nov 2014 07:32:26 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 07:32:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 07:32:25 +0000
Message-Id: <546B04180200007800048A31@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 07:32:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tamas K Lengyel" <tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
	<546A32720200007800048873@mail.emea.novell.com>
	<CAErYnsgm5F3ThZe2w1Lq=az90ve_1pLhEb+Kpc2k9AfWOvB1FA@mail.gmail.com>
In-Reply-To: <CAErYnsgm5F3ThZe2w1Lq=az90ve_1pLhEb+Kpc2k9AfWOvB1FA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Eddie Dong <eddie.dong@intel.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 18:06, <tamas.lengyel@zentific.com> wrote:
> On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> >>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
>> > On 12/11/14 15:31, Tamas K Lengyel wrote:
>> >>  xen/include/public/domctl.h         |  44 +--
>> >>  xen/include/public/hvm/params.h     |   2 +-
>> >>  xen/include/public/mem_event.h      | 134 -------
>> >>  xen/include/public/memory.h         |   6 +-
>> >>  xen/include/public/vm_event.h       | 179 +++++++++
>> >
>> > While in principle I think this series is a very good thing, there is a
>> > problem with editing the pubic header files.
>> >
>> > The contents of mem_event.h is not currently hidden behind #ifdef
>> > __XEN_TOOLS__
>> >
>> > As a result, it is strictly speaking part of the VM-visible public
>> > API/ABI and not permitted to change in a backwards incompatible manor.
>> >
>> > Having said that, it is currently only usable by privileged domains, so
>> > there is an argument to be made for declaring that it should have been
>> > hidden behind __XEN_TOOLS__ in the first place, making it permittable to
>> > change.
>>
>> I'm not sure I agree - the meaning of "tools" here would seem quite a
>> bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
>> an old consumer (remember that for many of these we have at best
>> fake consumers in the tree) would deal with the now differently
>> arranged data. I don't see any versioning of the interface, and hence
>> I can't see how tools would know which of the formats to expect.
> 
> The lack of versioning is a real concern which I have aired during the 4.5
> development process. For example, when we switched from HVMEM_access_* to
> XENMEM_access_* a customer had to do a bunch of manual configure checks to
> determine what is supported and what isn't. Furthermore, many of the
> related APIs have changed quite radically between Xen 4.1-4.5, some being
> abandoned midway just to resurface later in a different context. Going
> forward having a clear VM_EVENT_VERSION definition would be very helpful
> and would be the cleanest solution IMHO.

That's a concern different from mine - source compatibility may be
acceptable to get broken. Undetectable binary incompatibilities are
what worry me more.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 07:32:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 07:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqdH3-0001bW-0G; Tue, 18 Nov 2014 07:32:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqdH2-0001bL-7Q
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 07:32:28 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	F7/6F-26652-B06FA645; Tue, 18 Nov 2014 07:32:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416295946!11899191!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9964 invoked from network); 18 Nov 2014 07:32:26 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 07:32:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 07:32:25 +0000
Message-Id: <546B04180200007800048A31@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 07:32:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tamas K Lengyel" <tamas.lengyel@zentific.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
	<546A32720200007800048873@mail.emea.novell.com>
	<CAErYnsgm5F3ThZe2w1Lq=az90ve_1pLhEb+Kpc2k9AfWOvB1FA@mail.gmail.com>
In-Reply-To: <CAErYnsgm5F3ThZe2w1Lq=az90ve_1pLhEb+Kpc2k9AfWOvB1FA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Eddie Dong <eddie.dong@intel.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 18:06, <tamas.lengyel@zentific.com> wrote:
> On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> >>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
>> > On 12/11/14 15:31, Tamas K Lengyel wrote:
>> >>  xen/include/public/domctl.h         |  44 +--
>> >>  xen/include/public/hvm/params.h     |   2 +-
>> >>  xen/include/public/mem_event.h      | 134 -------
>> >>  xen/include/public/memory.h         |   6 +-
>> >>  xen/include/public/vm_event.h       | 179 +++++++++
>> >
>> > While in principle I think this series is a very good thing, there is a
>> > problem with editing the pubic header files.
>> >
>> > The contents of mem_event.h is not currently hidden behind #ifdef
>> > __XEN_TOOLS__
>> >
>> > As a result, it is strictly speaking part of the VM-visible public
>> > API/ABI and not permitted to change in a backwards incompatible manor.
>> >
>> > Having said that, it is currently only usable by privileged domains, so
>> > there is an argument to be made for declaring that it should have been
>> > hidden behind __XEN_TOOLS__ in the first place, making it permittable to
>> > change.
>>
>> I'm not sure I agree - the meaning of "tools" here would seem quite a
>> bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
>> an old consumer (remember that for many of these we have at best
>> fake consumers in the tree) would deal with the now differently
>> arranged data. I don't see any versioning of the interface, and hence
>> I can't see how tools would know which of the formats to expect.
> 
> The lack of versioning is a real concern which I have aired during the 4.5
> development process. For example, when we switched from HVMEM_access_* to
> XENMEM_access_* a customer had to do a bunch of manual configure checks to
> determine what is supported and what isn't. Furthermore, many of the
> related APIs have changed quite radically between Xen 4.1-4.5, some being
> abandoned midway just to resurface later in a different context. Going
> forward having a clear VM_EVENT_VERSION definition would be very helpful
> and would be the cleanest solution IMHO.

That's a concern different from mine - source compatibility may be
acceptable to get broken. Undetectable binary incompatibilities are
what worry me more.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 07:40:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 07: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 1XqdOb-0001pd-8L; Tue, 18 Nov 2014 07:40:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqdOZ-0001pX-T1
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 07:40:16 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C7/FB-22737-FD7FA645; Tue, 18 Nov 2014 07:40:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416296412!6629534!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10403 invoked from network); 18 Nov 2014 07:40:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 07:40:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="193877410"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 02:40:11 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqdOV-0002L4-2m;
	Tue, 18 Nov 2014 07:40:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqdOU-0006Tq-TV;
	Tue, 18 Nov 2014 07:40:10 +0000
Date: Tue, 18 Nov 2014 07:40:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31650-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8148
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.4-testing test] 31650: 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: multipart/mixed; boundary="===============7196062882090314482=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7196062882090314482==
Content-Type: text/plain
Content-Length: 7825
Content-Transfer-Encoding: quoted-printable

flight 31650 qemu-upstream-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31650/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 25336

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)       broken never pass
 test-amd64-i386-libvirt       3 host-install(3)              broken never pass
 test-amd64-i386-xl-win7-amd64  3 host-install(3)             broken never pass
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3)      broken never pass
 test-amd64-i386-xend-winxpsp3  3 host-install(3)             broken never pass
 test-amd64-i386-pv            3 host-install(3)              broken never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                b04df88d41f64fc6b56d193b6e90fb840cedb1d3
baseline version:
 qemuu                65fc9b78ba3d868a26952db0d8e51cecf01d47b4

------------------------------------------------------------
People who touched revisions under test:
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

------------------------------------------------------------
commit b04df88d41f64fc6b56d193b6e90fb840cedb1d3
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Nov 13 18:42:09 2014 +0100

    xen_disk: fix unmapping of persistent grants
    
    This patch fixes two issues with persistent grants and the disk PV backend
    (Qdisk):
    
     - Keep track of memory regions where persistent grants have been mapped
       since we need to unmap them as a whole. It is not possible to unmap a
       single grant if it has been batch-mapped. A new check has also been added
       to make sure persistent grants are only used if the whole mapped region
       can be persistently mapped in the batch_maps case.
     - Unmap persistent grants before switching to the closed state, so the
       frontend can also free them.
    
    upstream-commit-id: 2f01dfacb56bc7a0d4639adc9dff9aae131e6216
    
    Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reported-by: George Dunlap <george.dunlap@eu.citrix.com>
    Cc: Kevin Wolf <kwolf@redhat.com>
    Cc: Stefan Hajnoczi <stefanha@redhat.com>
    Cc: George Dunlap <george.dunlap@eu.citrix.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


--===============7196062882090314482==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7196062882090314482==--

From xen-devel-bounces@lists.xen.org Tue Nov 18 07:40:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 07: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 1XqdOb-0001pd-8L; Tue, 18 Nov 2014 07:40:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqdOZ-0001pX-T1
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 07:40:16 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C7/FB-22737-FD7FA645; Tue, 18 Nov 2014 07:40:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416296412!6629534!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10403 invoked from network); 18 Nov 2014 07:40:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 07:40:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="193877410"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 02:40:11 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqdOV-0002L4-2m;
	Tue, 18 Nov 2014 07:40:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqdOU-0006Tq-TV;
	Tue, 18 Nov 2014 07:40:10 +0000
Date: Tue, 18 Nov 2014 07:40:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31650-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8148
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.4-testing test] 31650: 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: multipart/mixed; boundary="===============7196062882090314482=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7196062882090314482==
Content-Type: text/plain
Content-Length: 7825
Content-Transfer-Encoding: quoted-printable

flight 31650 qemu-upstream-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31650/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 25336

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)       broken never pass
 test-amd64-i386-libvirt       3 host-install(3)              broken never pass
 test-amd64-i386-xl-win7-amd64  3 host-install(3)             broken never pass
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3)      broken never pass
 test-amd64-i386-xend-winxpsp3  3 host-install(3)             broken never pass
 test-amd64-i386-pv            3 host-install(3)              broken never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                b04df88d41f64fc6b56d193b6e90fb840cedb1d3
baseline version:
 qemuu                65fc9b78ba3d868a26952db0d8e51cecf01d47b4

------------------------------------------------------------
People who touched revisions under test:
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

------------------------------------------------------------
commit b04df88d41f64fc6b56d193b6e90fb840cedb1d3
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Nov 13 18:42:09 2014 +0100

    xen_disk: fix unmapping of persistent grants
    
    This patch fixes two issues with persistent grants and the disk PV backend
    (Qdisk):
    
     - Keep track of memory regions where persistent grants have been mapped
       since we need to unmap them as a whole. It is not possible to unmap a
       single grant if it has been batch-mapped. A new check has also been added
       to make sure persistent grants are only used if the whole mapped region
       can be persistently mapped in the batch_maps case.
     - Unmap persistent grants before switching to the closed state, so the
       frontend can also free them.
    
    upstream-commit-id: 2f01dfacb56bc7a0d4639adc9dff9aae131e6216
    
    Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reported-by: George Dunlap <george.dunlap@eu.citrix.com>
    Cc: Kevin Wolf <kwolf@redhat.com>
    Cc: Stefan Hajnoczi <stefanha@redhat.com>
    Cc: George Dunlap <george.dunlap@eu.citrix.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


--===============7196062882090314482==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7196062882090314482==--

From xen-devel-bounces@lists.xen.org Tue Nov 18 07:54:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 07: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 1XqdcX-00021M-C2; Tue, 18 Nov 2014 07:54:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqdcV-00021H-Iv
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 07:54:39 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	DD/3C-03148-E3BFA645; Tue, 18 Nov 2014 07:54:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416297278!8569892!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16919 invoked from network); 18 Nov 2014 07:54:38 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 07:54:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 07:54:37 +0000
Message-Id: <546B094C0200007800048A5C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 07:54:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>,<pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
In-Reply-To: <546A4AD4.3030002@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 20:21, <sflist@ihonk.com> wrote:
> Okay, I did a bisection and was not able to correlate the above error 
> message with the problem I'm seeing. Not saying it's not related, but I 
> had plenty of successful test runs in the presence of that error.
> 
> Took me about a week (sometimes it takes as much as 6 hours to produce 
> the error), but bisect narrowed it down to this commit:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9a727a813e9b25003e433b3d 
> c3fa47e621f9e238
> 
> What do you think?

Thanks for narrowing this, even if this change didn't show any other
bad effects so far (and it's been widely tested by now), and even if
problems here would generally be expected to surface independent
of the use of PCI pass-through. But a hang (rather than a crash)
would indeed be the most natural result of something being wrong
here. To double check the result, could you, in an up-to-date tree,
simply make x86's arch_skip_send_event_check() return 0
unconditionally? Plus, without said adjustment, first just disable the
MWAIT CPU idle driver ("mwait-idle=0") and then, if that didn't make
a difference, use of C states altogether ("cpuidle=0"). If any of this
does make a difference, limiting use of C states without fully
excluding their use may need to be the next step.

Another thing - now that serial logging appears to be working for
you, did you try whether the host, once hung, still reacts to serial
input (perhaps force input to go to Xen right at boot via the
"conswitch=" option)? If so, 'd' debug-key output would likely be
the piece of most interest. If not, try adding "watchdog" on the Xen
command line (this doesn't always work, but should on the CPU you
originally reported the issue for).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 07:54:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 07: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 1XqdcX-00021M-C2; Tue, 18 Nov 2014 07:54:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqdcV-00021H-Iv
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 07:54:39 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	DD/3C-03148-E3BFA645; Tue, 18 Nov 2014 07:54:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416297278!8569892!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16919 invoked from network); 18 Nov 2014 07:54:38 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 07:54:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 07:54:37 +0000
Message-Id: <546B094C0200007800048A5C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 07:54:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>,<pasik@iki.fi>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
In-Reply-To: <546A4AD4.3030002@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 20:21, <sflist@ihonk.com> wrote:
> Okay, I did a bisection and was not able to correlate the above error 
> message with the problem I'm seeing. Not saying it's not related, but I 
> had plenty of successful test runs in the presence of that error.
> 
> Took me about a week (sometimes it takes as much as 6 hours to produce 
> the error), but bisect narrowed it down to this commit:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9a727a813e9b25003e433b3d 
> c3fa47e621f9e238
> 
> What do you think?

Thanks for narrowing this, even if this change didn't show any other
bad effects so far (and it's been widely tested by now), and even if
problems here would generally be expected to surface independent
of the use of PCI pass-through. But a hang (rather than a crash)
would indeed be the most natural result of something being wrong
here. To double check the result, could you, in an up-to-date tree,
simply make x86's arch_skip_send_event_check() return 0
unconditionally? Plus, without said adjustment, first just disable the
MWAIT CPU idle driver ("mwait-idle=0") and then, if that didn't make
a difference, use of C states altogether ("cpuidle=0"). If any of this
does make a difference, limiting use of C states without fully
excluding their use may need to be the next step.

Another thing - now that serial logging appears to be working for
you, did you try whether the host, once hung, still reacts to serial
input (perhaps force input to go to Xen right at boot via the
"conswitch=" option)? If so, 'd' debug-key output would likely be
the piece of most interest. If not, try adding "watchdog" on the Xen
command line (this doesn't always work, but should on the CPU you
originally reported the issue for).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 08:01:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 08:01:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqdjI-0002dE-S5; Tue, 18 Nov 2014 08:01:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqdjH-0002d9-Lm
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 08:01:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	75/7C-25276-3ECFA645; Tue, 18 Nov 2014 08:01:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416297698!13497411!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22080 invoked from network); 18 Nov 2014 08:01:38 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 08:01:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 08:01:38 +0000
Message-Id: <546B0AF00200007800048A69@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 08:01:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
In-Reply-To: <546AB82D.5080305@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 04:08, <tiejun.chen@intel.com> wrote:
> Here I tried to implement what you want. Note just pick two key 
> fragments since others have no big deal.
> 
> #1:
> 
> @@ -898,14 +898,25 @@ int 
> intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>   {
>       struct acpi_rmrr_unit *rmrr;
>       int rc = 0;
> +    unsigned int i;
> +    u32 id;
> +    u16 bdf;
> 
>       list_for_each_entry(rmrr, &acpi_rmrr_units, list)
>       {
> -        rc = func(PFN_DOWN(rmrr->base_address),
> -                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
> -                  ctxt);
> -        if ( rc )
> -            break;
> +        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
> +                    i < rmrr->scope.devices_cnt && !rc; i++)
> +        {
> +            id = PCI_SBDF(rmrr->segment, bdf);
> +            rc = func(PFN_DOWN(rmrr->base_address),
> +                               PFN_UP(rmrr->end_address) -
> +                                PFN_DOWN(rmrr->base_address),
> +                               id,
> +                               ctxt);
> +            if ( rc < 0 )
> +                return rc;
> +        }
> +        rc = 0;

Getting close - the main issue is that (as previously mentioned) you
should avoid open-coding for_each_rmrr_device(). It also doesn't
look like you really need the local variable 'id'.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 08:01:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 08:01:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqdjI-0002dE-S5; Tue, 18 Nov 2014 08:01:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqdjH-0002d9-Lm
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 08:01:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	75/7C-25276-3ECFA645; Tue, 18 Nov 2014 08:01:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416297698!13497411!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22080 invoked from network); 18 Nov 2014 08:01:38 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 08:01:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 08:01:38 +0000
Message-Id: <546B0AF00200007800048A69@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 08:01:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
In-Reply-To: <546AB82D.5080305@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 04:08, <tiejun.chen@intel.com> wrote:
> Here I tried to implement what you want. Note just pick two key 
> fragments since others have no big deal.
> 
> #1:
> 
> @@ -898,14 +898,25 @@ int 
> intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>   {
>       struct acpi_rmrr_unit *rmrr;
>       int rc = 0;
> +    unsigned int i;
> +    u32 id;
> +    u16 bdf;
> 
>       list_for_each_entry(rmrr, &acpi_rmrr_units, list)
>       {
> -        rc = func(PFN_DOWN(rmrr->base_address),
> -                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
> -                  ctxt);
> -        if ( rc )
> -            break;
> +        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
> +                    i < rmrr->scope.devices_cnt && !rc; i++)
> +        {
> +            id = PCI_SBDF(rmrr->segment, bdf);
> +            rc = func(PFN_DOWN(rmrr->base_address),
> +                               PFN_UP(rmrr->end_address) -
> +                                PFN_DOWN(rmrr->base_address),
> +                               id,
> +                               ctxt);
> +            if ( rc < 0 )
> +                return rc;
> +        }
> +        rc = 0;

Getting close - the main issue is that (as previously mentioned) you
should avoid open-coding for_each_rmrr_device(). It also doesn't
look like you really need the local variable 'id'.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 08:16:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 08: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 1XqdxY-0002pU-D2; Tue, 18 Nov 2014 08:16:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqdxX-0002pP-6Q
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 08:16:23 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	0E/A4-28296-6500B645; Tue, 18 Nov 2014 08:16:22 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416298581!11935352!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23573 invoked from network); 18 Nov 2014 08:16:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-31.messagelabs.com with SMTP;
	18 Nov 2014 08:16:21 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 18 Nov 2014 00:16:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,408,1413270000"; d="scan'208";a="624083632"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.124])
	([10.238.128.124])
	by fmsmga001.fm.intel.com with ESMTP; 18 Nov 2014 00:16:12 -0800
Message-ID: <546B004B.6050603@intel.com>
Date: Tue, 18 Nov 2014 16:16:11 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
In-Reply-To: <546B0AF00200007800048A69@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/18 16:01, Jan Beulich wrote:
>>>> On 18.11.14 at 04:08, <tiejun.chen@intel.com> wrote:
>> Here I tried to implement what you want. Note just pick two key
>> fragments since others have no big deal.
>>
>> #1:
>>
>> @@ -898,14 +898,25 @@ int
>> intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>    {
>>        struct acpi_rmrr_unit *rmrr;
>>        int rc = 0;
>> +    unsigned int i;
>> +    u32 id;
>> +    u16 bdf;
>>
>>        list_for_each_entry(rmrr, &acpi_rmrr_units, list)
>>        {
>> -        rc = func(PFN_DOWN(rmrr->base_address),
>> -                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
>> -                  ctxt);
>> -        if ( rc )
>> -            break;
>> +        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
>> +                    i < rmrr->scope.devices_cnt && !rc; i++)
>> +        {
>> +            id = PCI_SBDF(rmrr->segment, bdf);
>> +            rc = func(PFN_DOWN(rmrr->base_address),
>> +                               PFN_UP(rmrr->end_address) -
>> +                                PFN_DOWN(rmrr->base_address),
>> +                               id,
>> +                               ctxt);
>> +            if ( rc < 0 )
>> +                return rc;
>> +        }
>> +        rc = 0;
>
> Getting close - the main issue is that (as previously mentioned) you
> should avoid open-coding for_each_rmrr_device(). It also doesn't

Sorry, are you saying these lines?

 >> +        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
 >> +                    i < rmrr->scope.devices_cnt && !rc; i++)

So without lookuping devices[i], how can we call func() for each sbdf as 
you mentioned?

> look like you really need the local variable 'id'.

Okay, I can pass PCI_SBDF(rmrr->segment, bdf) directly.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 08:16:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 08: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 1XqdxY-0002pU-D2; Tue, 18 Nov 2014 08:16:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XqdxX-0002pP-6Q
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 08:16:23 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	0E/A4-28296-6500B645; Tue, 18 Nov 2014 08:16:22 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416298581!11935352!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23573 invoked from network); 18 Nov 2014 08:16:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-31.messagelabs.com with SMTP;
	18 Nov 2014 08:16:21 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 18 Nov 2014 00:16:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,408,1413270000"; d="scan'208";a="624083632"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.124])
	([10.238.128.124])
	by fmsmga001.fm.intel.com with ESMTP; 18 Nov 2014 00:16:12 -0800
Message-ID: <546B004B.6050603@intel.com>
Date: Tue, 18 Nov 2014 16:16:11 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
In-Reply-To: <546B0AF00200007800048A69@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/18 16:01, Jan Beulich wrote:
>>>> On 18.11.14 at 04:08, <tiejun.chen@intel.com> wrote:
>> Here I tried to implement what you want. Note just pick two key
>> fragments since others have no big deal.
>>
>> #1:
>>
>> @@ -898,14 +898,25 @@ int
>> intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>    {
>>        struct acpi_rmrr_unit *rmrr;
>>        int rc = 0;
>> +    unsigned int i;
>> +    u32 id;
>> +    u16 bdf;
>>
>>        list_for_each_entry(rmrr, &acpi_rmrr_units, list)
>>        {
>> -        rc = func(PFN_DOWN(rmrr->base_address),
>> -                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
>> -                  ctxt);
>> -        if ( rc )
>> -            break;
>> +        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
>> +                    i < rmrr->scope.devices_cnt && !rc; i++)
>> +        {
>> +            id = PCI_SBDF(rmrr->segment, bdf);
>> +            rc = func(PFN_DOWN(rmrr->base_address),
>> +                               PFN_UP(rmrr->end_address) -
>> +                                PFN_DOWN(rmrr->base_address),
>> +                               id,
>> +                               ctxt);
>> +            if ( rc < 0 )
>> +                return rc;
>> +        }
>> +        rc = 0;
>
> Getting close - the main issue is that (as previously mentioned) you
> should avoid open-coding for_each_rmrr_device(). It also doesn't

Sorry, are you saying these lines?

 >> +        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
 >> +                    i < rmrr->scope.devices_cnt && !rc; i++)

So without lookuping devices[i], how can we call func() for each sbdf as 
you mentioned?

> look like you really need the local variable 'id'.

Okay, I can pass PCI_SBDF(rmrr->segment, bdf) directly.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 08:28:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 08: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 1Xqe96-00030E-0X; Tue, 18 Nov 2014 08:28:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xqe94-000309-JN
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 08:28:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E1/EA-09936-1230B645; Tue, 18 Nov 2014 08:28:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416299297!13504450!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23497 invoked from network); 18 Nov 2014 08:28:17 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 08:28:17 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 08:28:17 +0000
Message-Id: <546B112F0200007800048A89@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 08:28:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
In-Reply-To: <1271355060.20141117234011@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 23:40, <linux@eikelenboom.it> wrote:
> OK, i still don't get why the output of debug-key 'i' reports +47 as pirq 
> here instead of the guest value 
> (g_gsi of for this legacy interrupt which is 40 ?), like it does when it's a 
> MSI with the PIRQ ?

No - as you said yourself, it's a matter of who uses which numbers.
Xen can't know the IRQ number the guest OS choses internally. It
can only tell you the number the hypervisor uses internally and the
one it told the guest to use to refer to it (the former is what we
commonly refer to as IRQ, while the latter is the pIRQ). Pin-based
(i.e. IO-APIC) interrupts should always use the same number for
both; MSI ones could only happen to have them match up, but
would use distinct numbers normally.

>> I am puzzled by the driver binding twice to the same interrupt, but perhaps 
> that
>> is just a buggy driver.
> 
> Doesn't that happen more often like with integrated USB controllers ?
>   17:          4          0          0          0          0          0  
> xen-pirq-ioapic-level  ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
>   18:       4385          0          0          0          0          0  
> xen-pirq-ioapic-level  ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, 
> ohci_hcd:usb7

No, these are all distinct devices - if you look at you lspci output,
you should find multiple EHCI and OHCI controller instances. It's
slightly odd that each kind gets grouped onto a single IO-APIC pin,
but that's a (legal) BIOS decision.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 08:28:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 08: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 1Xqe96-00030E-0X; Tue, 18 Nov 2014 08:28:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xqe94-000309-JN
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 08:28:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E1/EA-09936-1230B645; Tue, 18 Nov 2014 08:28:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416299297!13504450!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23497 invoked from network); 18 Nov 2014 08:28:17 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 08:28:17 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 08:28:17 +0000
Message-Id: <546B112F0200007800048A89@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 08:28:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
In-Reply-To: <1271355060.20141117234011@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 23:40, <linux@eikelenboom.it> wrote:
> OK, i still don't get why the output of debug-key 'i' reports +47 as pirq 
> here instead of the guest value 
> (g_gsi of for this legacy interrupt which is 40 ?), like it does when it's a 
> MSI with the PIRQ ?

No - as you said yourself, it's a matter of who uses which numbers.
Xen can't know the IRQ number the guest OS choses internally. It
can only tell you the number the hypervisor uses internally and the
one it told the guest to use to refer to it (the former is what we
commonly refer to as IRQ, while the latter is the pIRQ). Pin-based
(i.e. IO-APIC) interrupts should always use the same number for
both; MSI ones could only happen to have them match up, but
would use distinct numbers normally.

>> I am puzzled by the driver binding twice to the same interrupt, but perhaps 
> that
>> is just a buggy driver.
> 
> Doesn't that happen more often like with integrated USB controllers ?
>   17:          4          0          0          0          0          0  
> xen-pirq-ioapic-level  ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
>   18:       4385          0          0          0          0          0  
> xen-pirq-ioapic-level  ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, 
> ohci_hcd:usb7

No, these are all distinct devices - if you look at you lspci output,
you should find multiple EHCI and OHCI controller instances. It's
slightly odd that each kind gets grouped onto a single IO-APIC pin,
but that's a (legal) BIOS decision.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 08:55:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 08:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqeZU-0003HQ-CY; Tue, 18 Nov 2014 08:55:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqeZT-0003HL-Fw
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 08:55:35 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	0D/63-22777-6890B645; Tue, 18 Nov 2014 08:55:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416300932!7816021!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15855 invoked from network); 18 Nov 2014 08:55:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 08:55:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="192387551"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 03:55:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqeZP-0002hY-5f;
	Tue, 18 Nov 2014 08:55:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqeZP-0006dy-0W;
	Tue, 18 Nov 2014 08:55:31 +0000
Date: Tue, 18 Nov 2014 08:55:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31610-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31610: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31610 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31610/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 build-armhf-pvops             3 host-install(3)         broken REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                5f01feb8b97a4d65caa1456cb12f0f770497347f
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
543 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf-pvops host-install(3)

Not pushing.

(No revision log; it would be 21365 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 Nov 18 08:55:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 08:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqeZU-0003HQ-CY; Tue, 18 Nov 2014 08:55:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqeZT-0003HL-Fw
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 08:55:35 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	0D/63-22777-6890B645; Tue, 18 Nov 2014 08:55:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416300932!7816021!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15855 invoked from network); 18 Nov 2014 08:55:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 08:55:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="192387551"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 03:55:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqeZP-0002hY-5f;
	Tue, 18 Nov 2014 08:55:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqeZP-0006dy-0W;
	Tue, 18 Nov 2014 08:55:31 +0000
Date: Tue, 18 Nov 2014 08:55:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31610-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31610: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31610 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31610/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 build-armhf-pvops             3 host-install(3)         broken REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                5f01feb8b97a4d65caa1456cb12f0f770497347f
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
543 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf-pvops host-install(3)

Not pushing.

(No revision log; it would be 21365 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 Nov 18 09:05:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 09:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqeiy-0003UH-CB; Tue, 18 Nov 2014 09:05:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1Xqeiw-0003UC-Nk
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 09:05:22 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	FC/08-22737-2DB0B645; Tue, 18 Nov 2014 09:05:22 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416301516!11917822!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4605 invoked from network); 18 Nov 2014 09:05:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-206.messagelabs.com with SMTP;
	18 Nov 2014 09:05:21 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 18 Nov 2014 01:05:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,408,1413270000"; d="scan'208";a="633728291"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga002.fm.intel.com with ESMTP; 18 Nov 2014 01:04:46 -0800
Date: Tue, 18 Nov 2014 17:04:44 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141118090444.GA20252@pengc-linux.bj.intel.com>
References: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141117094117.GF11070@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141117094117.GF11070@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: 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] libxl: avoid bringing up vcpus already
	online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Chao Peng <chao.p.peng@linux.intel.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 09:41:17AM +0000, Wei Liu wrote:
> On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
> > Avoid sending duplicated qmp commands and eliminate the confusing error
> > messages like "Unable to add CPU: 0, it already exists".
> > 
> > Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> > ---
> >  tools/libxl/libxl.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..d040e5c 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -5450,7 +5450,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid,
> >          LOGE(ERROR, "getting domain info list");
> >          return ERROR_FAIL;
> >      }
> > -    for (i = 0; i <= info.vcpu_max_id; i++) {
> > +    for (i = info.vcpu_online; i <= info.vcpu_max_id; i++) {
> 
> I don't think this is right. You're making an assumption that vcpu 0 to
> vcpu "info.vcpu_online" are online, which might not be true in hotplug /
> hot-unplug scenario.
> 
You are right. Though the assumption is true right now as QEMU has not
implemented cpu hot-unplug.

The problem is: There is no way to obtain the vcpu online status in xl
as cpu hot-plug/hot-unplug for HVM are all done in QEMU. I guess it's
hard to fix it now. While it's also a minor issue :-)

Chao
> 
> >          if (libxl_bitmap_test(cpumap, i)) {
> >              /* Return value is ignore because it does not tell anything useful
> >               * on the completion of the command.
> > -- 
> > 1.7.9.5
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 09:05:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 09:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqeiy-0003UH-CB; Tue, 18 Nov 2014 09:05:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1Xqeiw-0003UC-Nk
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 09:05:22 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	FC/08-22737-2DB0B645; Tue, 18 Nov 2014 09:05:22 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416301516!11917822!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4605 invoked from network); 18 Nov 2014 09:05:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-206.messagelabs.com with SMTP;
	18 Nov 2014 09:05:21 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 18 Nov 2014 01:05:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,408,1413270000"; d="scan'208";a="633728291"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga002.fm.intel.com with ESMTP; 18 Nov 2014 01:04:46 -0800
Date: Tue, 18 Nov 2014 17:04:44 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141118090444.GA20252@pengc-linux.bj.intel.com>
References: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141117094117.GF11070@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141117094117.GF11070@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: 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] libxl: avoid bringing up vcpus already
	online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Chao Peng <chao.p.peng@linux.intel.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 09:41:17AM +0000, Wei Liu wrote:
> On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
> > Avoid sending duplicated qmp commands and eliminate the confusing error
> > messages like "Unable to add CPU: 0, it already exists".
> > 
> > Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> > ---
> >  tools/libxl/libxl.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..d040e5c 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -5450,7 +5450,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid,
> >          LOGE(ERROR, "getting domain info list");
> >          return ERROR_FAIL;
> >      }
> > -    for (i = 0; i <= info.vcpu_max_id; i++) {
> > +    for (i = info.vcpu_online; i <= info.vcpu_max_id; i++) {
> 
> I don't think this is right. You're making an assumption that vcpu 0 to
> vcpu "info.vcpu_online" are online, which might not be true in hotplug /
> hot-unplug scenario.
> 
You are right. Though the assumption is true right now as QEMU has not
implemented cpu hot-unplug.

The problem is: There is no way to obtain the vcpu online status in xl
as cpu hot-plug/hot-unplug for HVM are all done in QEMU. I guess it's
hard to fix it now. While it's also a minor issue :-)

Chao
> 
> >          if (libxl_bitmap_test(cpumap, i)) {
> >              /* Return value is ignore because it does not tell anything useful
> >               * on the completion of the command.
> > -- 
> > 1.7.9.5
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 09:26:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 09: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.xen.org>)
	id 1Xqf31-0003hJ-Tp; Tue, 18 Nov 2014 09:26:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xqf31-0003hB-8g
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 09:26:07 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	66/10-02702-EA01B645; Tue, 18 Nov 2014 09:26:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416302764!12664336!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9892 invoked from network); 18 Nov 2014 09:26:05 -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;
	18 Nov 2014 09:26:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="192394194"
Message-ID: <1416302762.17982.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Tue, 18 Nov 2014 09:26:02 +0000
In-Reply-To: <546A54AC.50909@oracle.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com> <5460D9C5.4020905@oracle.com>
	<1415633435.25176.27.camel@citrix.com> <5460DBEF.5000504@oracle.com>
	<1415793797.29592.12.camel@citrix.com> <546A54AC.50909@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 15:03 -0500, Zhigang Wang wrote:
> On 11/12/2014 07:03 AM, Ian Campbell wrote:
> > On Mon, 2014-11-10 at 10:38 -0500, Zhigang Wang wrote:
> >> OK. Let me try my best:
> >>
> >>>>> I'm confused by the description of what's going on, in particular the
> >>>>> mixing of mem-max commands and target xenstore nodes (since the former
> >>>>> doesn't really affect the latter).
> >>>>>
> >>>>> How was the domain started (memory= and maxmem=).
> >>
> >> xl create with 'memory = 700', no maxmem been set. I think it means maxmem = memory for this case.
> >>
> >>>>> What were static-max and target at the point?
> >>
> >>      /local/domain/3/memory/static-max = "716800"
> >>      /local/domain/3/memory/target = "716801"
> >>
> >>>>> What did they change to when xl mem-max was issued? 
> >>
> >> When I issue 'xl mem-max <domid> 700', static-max and target in xenstore will not change, but it will cause the command to fail.
> >>
> >> Because: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"
> >>
> >>>>> What did you expect them to change to instead?
> >>
> >> I expect I can set the maxmem to the same value I initially set (700).
> > 
> > OK, thanks, got it. I think the use of xl mem-max is a bit of a
> > red-herring, the issue here is that static-max < target at start of day.
> > 
> > I suspect there is either a rounding error somewhere or because of
> > LIBXL_MAXMEM_CONSTANT being inconsistently applied to the two values
> > somewhere along the line.
> > 
> > We had been planning[0] to remove this early in the 4.5 cycle, but as
> > ever it never floated to the top of anyone's list. For 4.5 we should
> > probably look at applying this fudge more consistently.
> > 
> > Ian.
> > 
> > [0] http://bugs.xenproject.org/xen/bug/23
> 
> Here is more info (correct me if something wrong):
> 
> 1. libxl_types.idl:
> 
>     ("video_memkb", MemKB)
> 
>     MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT", json_gen_fn = "libxl__uint64_gen_json")
> 
>   libxl.h: #define LIBXL_MEMKB_DEFAULT ~0ULL
> 
>   So video_memkb = -1 by default.
> 
> 2. For hvm, we will set it into: 0, 16M, 8M according to hvm.vga.kind (libxl_create.c)
> 
> 3. For pv guest, we will use default (-1).
> 
> 4. When we calculate static-max and target memory:
> 
>     ents[0] = "memory/static-max";
>     ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
>     ents[2] = "memory/target";
>     ents[3] = GCSPRINTF("%"PRId64, info->target_memkb - info->video_memkb);
> 
>   So target = static-max - (-1):

Aha, well spotted!
   
>       /local/domain/3/memory/static-max = "716800"
>       /local/domain/3/memory/target = "716801"
> 
>   Maybe this is the root cause why we include LIBXL_MAXMEM_CONSTANT.

I don't think so, LIBXL_MAXMEM_CONSTANT is the result of some
not-well-understood folklore which predates libxl entirely.

> 
> Potential solutions:
> 
> 1. Set b_info->video_memkb = 0; for pv guest.

We should do this one, in the libxl_domain_build_info_setdefault
function.

> 2. Set LIBXL_MEMKB_DEFAULT = 0 (instead of -1): this will affect a lot things.

Yeah, we can't do that since it would disallow setting certain kinds of
memory to 0, which can make sense.

> 3. Also add LIBXL_MAXMEM_CONSTANT before doing comparison. (we should avoid this as we want to remove LIBXL_MAXMEM_CONSTANT)

Agreed, lets not to this.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 09:26:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 09: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.xen.org>)
	id 1Xqf31-0003hJ-Tp; Tue, 18 Nov 2014 09:26:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xqf31-0003hB-8g
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 09:26:07 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	66/10-02702-EA01B645; Tue, 18 Nov 2014 09:26:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416302764!12664336!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9892 invoked from network); 18 Nov 2014 09:26:05 -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;
	18 Nov 2014 09:26:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="192394194"
Message-ID: <1416302762.17982.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Tue, 18 Nov 2014 09:26:02 +0000
In-Reply-To: <546A54AC.50909@oracle.com>
References: <545BF386.1050106@oracle.com>
	<20141107110512.GA12109@zion.uk.xensource.com>
	<545CD572.9040801@oracle.com>
	<20141110123747.GE28360@zion.uk.xensource.com>
	<1415623447.25176.12.camel@citrix.com> <5460D9C5.4020905@oracle.com>
	<1415633435.25176.27.camel@citrix.com> <5460DBEF.5000504@oracle.com>
	<1415793797.29592.12.camel@citrix.com> <546A54AC.50909@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] xl mem-max error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 15:03 -0500, Zhigang Wang wrote:
> On 11/12/2014 07:03 AM, Ian Campbell wrote:
> > On Mon, 2014-11-10 at 10:38 -0500, Zhigang Wang wrote:
> >> OK. Let me try my best:
> >>
> >>>>> I'm confused by the description of what's going on, in particular the
> >>>>> mixing of mem-max commands and target xenstore nodes (since the former
> >>>>> doesn't really affect the latter).
> >>>>>
> >>>>> How was the domain started (memory= and maxmem=).
> >>
> >> xl create with 'memory = 700', no maxmem been set. I think it means maxmem = memory for this case.
> >>
> >>>>> What were static-max and target at the point?
> >>
> >>      /local/domain/3/memory/static-max = "716800"
> >>      /local/domain/3/memory/target = "716801"
> >>
> >>>>> What did they change to when xl mem-max was issued? 
> >>
> >> When I issue 'xl mem-max <domid> 700', static-max and target in xenstore will not change, but it will cause the command to fail.
> >>
> >> Because: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"
> >>
> >>>>> What did you expect them to change to instead?
> >>
> >> I expect I can set the maxmem to the same value I initially set (700).
> > 
> > OK, thanks, got it. I think the use of xl mem-max is a bit of a
> > red-herring, the issue here is that static-max < target at start of day.
> > 
> > I suspect there is either a rounding error somewhere or because of
> > LIBXL_MAXMEM_CONSTANT being inconsistently applied to the two values
> > somewhere along the line.
> > 
> > We had been planning[0] to remove this early in the 4.5 cycle, but as
> > ever it never floated to the top of anyone's list. For 4.5 we should
> > probably look at applying this fudge more consistently.
> > 
> > Ian.
> > 
> > [0] http://bugs.xenproject.org/xen/bug/23
> 
> Here is more info (correct me if something wrong):
> 
> 1. libxl_types.idl:
> 
>     ("video_memkb", MemKB)
> 
>     MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT", json_gen_fn = "libxl__uint64_gen_json")
> 
>   libxl.h: #define LIBXL_MEMKB_DEFAULT ~0ULL
> 
>   So video_memkb = -1 by default.
> 
> 2. For hvm, we will set it into: 0, 16M, 8M according to hvm.vga.kind (libxl_create.c)
> 
> 3. For pv guest, we will use default (-1).
> 
> 4. When we calculate static-max and target memory:
> 
>     ents[0] = "memory/static-max";
>     ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
>     ents[2] = "memory/target";
>     ents[3] = GCSPRINTF("%"PRId64, info->target_memkb - info->video_memkb);
> 
>   So target = static-max - (-1):

Aha, well spotted!
   
>       /local/domain/3/memory/static-max = "716800"
>       /local/domain/3/memory/target = "716801"
> 
>   Maybe this is the root cause why we include LIBXL_MAXMEM_CONSTANT.

I don't think so, LIBXL_MAXMEM_CONSTANT is the result of some
not-well-understood folklore which predates libxl entirely.

> 
> Potential solutions:
> 
> 1. Set b_info->video_memkb = 0; for pv guest.

We should do this one, in the libxl_domain_build_info_setdefault
function.

> 2. Set LIBXL_MEMKB_DEFAULT = 0 (instead of -1): this will affect a lot things.

Yeah, we can't do that since it would disallow setting certain kinds of
memory to 0, which can make sense.

> 3. Also add LIBXL_MAXMEM_CONSTANT before doing comparison. (we should avoid this as we want to remove LIBXL_MAXMEM_CONSTANT)

Agreed, lets not to this.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 09:30:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 09:30:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqf7I-0003pn-Nb; Tue, 18 Nov 2014 09:30:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xqf7G-0003ph-TS
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 09:30:31 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	E9/4B-18267-6B11B645; Tue, 18 Nov 2014 09:30:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416303028!12132553!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6255 invoked from network); 18 Nov 2014 09:30:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 09:30:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 09:30:26 +0000
Message-Id: <546B1FC10200007800048ABD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 09:30:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1848367524.20141117190103@eikelenboom.it>
In-Reply-To: <1848367524.20141117190103@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 19:01, <linux@eikelenboom.it> wrote:
> (XEN) [2014-11-17 17:54:18.695] CPU00:
> (XEN) [2014-11-17 17:54:18.705] CPU01:
> (XEN) [2014-11-17 17:54:18.716] d16 OK-softirq 62msec ago, state:1, 2628 count, 
> [prev:ffff83054ef57e70, next:ffff83054ef57e70] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:18.765] d16 OK-raise   112msec ago, state:1, 2628 
> count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:18.815] CPU02:
> (XEN) [2014-11-17 17:54:18.825] d17 OK-softirq 500msec ago, state:1, 3439 
> count, [prev:ffff83054ef47e70, next:ffff83054ef47e70] ffff83051a1c8c28<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:18.875] d17 OK-raise   549msec ago, state:1, 3439 
> count, [prev:0000000000200200, next:0000000000100100] ffff83051a1c8c28<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:18.924] CPU03:
> (XEN) [2014-11-17 17:54:18.935] d16 OK-softirq 313msec ago, state:1, 3533 
> count, [prev:ffff83054ef37e70, next:ffff83054ef37e70] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:18.984] d16 OK-raise   363msec ago, state:1, 3533 
> count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:19.034] CPU04:
> (XEN) [2014-11-17 17:54:19.044] d16 OK-softirq 359msec ago, state:1, 3691 
> count, [prev:ffff83054ef27e88, next:ffff83054ef27e88] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:19.094] d16 OK-raise   408msec ago, state:1, 3691 
> count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:19.143] CPU05:
> (XEN) [2014-11-17 17:54:19.154] d16 OK-softirq 458msec ago, state:1, 52039 
> count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] 
> ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> (XEN) [2014-11-17 17:54:19.205] d16 OK-raise   489msec ago, state:1, 52049 
> count, [prev:0000000000200200, next:0000000000100100] 
> ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> (XEN) [2014-11-17 17:54:19.257] d16 ERR-poison 561msec ago, state:0, 1 count, 
> [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT 
> MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> (XEN) [2014-11-17 17:54:19.307] d16 Z-softirq  731msec ago, state:3, 3 count, 
> [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT 
> MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> (XEN) [2014-11-17 17:54:19.356] domain_crash called from io.c:938
> (XEN) [2014-11-17 17:54:19.356] Domain 16 reported crashed by domain 32767 on 
> cpu#5:

I think what would help establishing the sequence of events would
be to at the very least calculate the times printed above relative to
a single NOW() invocation done in dump_debug() rather than
dump_record(). That may, however, yield meaningless values when
done at millisecond granularity. Hence, either using nanosecond
granularity or not using time values but a simple sequence counter
might be a desirable approach.

What puzzles me additionally is that for list_del() to encounter an
already removed entry, I'd expect the entry to (mistakenly) have
got added twice. Yet there's no sign of that (the most recent
OK-raise entry shows the list entry still having poisoned pointers).
Or it would need to have got inserted a second time on another
CPU, but the track record thereof having got overwritten. Perhaps
now that we suspect the legacy IRQ to be the problematic one the
patch could be adjusted to track only operations on non-MSI IRQs
(or separately all three PT_IRQ_TYPE_*)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 09:30:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 09:30:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqf7I-0003pn-Nb; Tue, 18 Nov 2014 09:30:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xqf7G-0003ph-TS
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 09:30:31 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	E9/4B-18267-6B11B645; Tue, 18 Nov 2014 09:30:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416303028!12132553!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6255 invoked from network); 18 Nov 2014 09:30:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 09:30:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 09:30:26 +0000
Message-Id: <546B1FC10200007800048ABD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 09:30:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <193010671.20141114141112@eikelenboom.it>
	<546618620200007800047AD1@mail.emea.novell.com>
	<688701120.20141114153404@eikelenboom.it>
	<546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1848367524.20141117190103@eikelenboom.it>
In-Reply-To: <1848367524.20141117190103@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 19:01, <linux@eikelenboom.it> wrote:
> (XEN) [2014-11-17 17:54:18.695] CPU00:
> (XEN) [2014-11-17 17:54:18.705] CPU01:
> (XEN) [2014-11-17 17:54:18.716] d16 OK-softirq 62msec ago, state:1, 2628 count, 
> [prev:ffff83054ef57e70, next:ffff83054ef57e70] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:18.765] d16 OK-raise   112msec ago, state:1, 2628 
> count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:18.815] CPU02:
> (XEN) [2014-11-17 17:54:18.825] d17 OK-softirq 500msec ago, state:1, 3439 
> count, [prev:ffff83054ef47e70, next:ffff83054ef47e70] ffff83051a1c8c28<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:18.875] d17 OK-raise   549msec ago, state:1, 3439 
> count, [prev:0000000000200200, next:0000000000100100] ffff83051a1c8c28<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:18.924] CPU03:
> (XEN) [2014-11-17 17:54:18.935] d16 OK-softirq 313msec ago, state:1, 3533 
> count, [prev:ffff83054ef37e70, next:ffff83054ef37e70] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:18.984] d16 OK-raise   363msec ago, state:1, 3533 
> count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:19.034] CPU04:
> (XEN) [2014-11-17 17:54:19.044] d16 OK-softirq 359msec ago, state:1, 3691 
> count, [prev:ffff83054ef27e88, next:ffff83054ef27e88] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:19.094] d16 OK-raise   408msec ago, state:1, 3691 
> count, [prev:0000000000200200, next:0000000000100100] ffff83051b904428<NULL> 
> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
> (XEN) [2014-11-17 17:54:19.143] CPU05:
> (XEN) [2014-11-17 17:54:19.154] d16 OK-softirq 458msec ago, state:1, 52039 
> count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] 
> ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> (XEN) [2014-11-17 17:54:19.205] d16 OK-raise   489msec ago, state:1, 52049 
> count, [prev:0000000000200200, next:0000000000100100] 
> ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> (XEN) [2014-11-17 17:54:19.257] d16 ERR-poison 561msec ago, state:0, 1 count, 
> [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT 
> MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> (XEN) [2014-11-17 17:54:19.307] d16 Z-softirq  731msec ago, state:3, 3 count, 
> [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT 
> MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
> (XEN) [2014-11-17 17:54:19.356] domain_crash called from io.c:938
> (XEN) [2014-11-17 17:54:19.356] Domain 16 reported crashed by domain 32767 on 
> cpu#5:

I think what would help establishing the sequence of events would
be to at the very least calculate the times printed above relative to
a single NOW() invocation done in dump_debug() rather than
dump_record(). That may, however, yield meaningless values when
done at millisecond granularity. Hence, either using nanosecond
granularity or not using time values but a simple sequence counter
might be a desirable approach.

What puzzles me additionally is that for list_del() to encounter an
already removed entry, I'd expect the entry to (mistakenly) have
got added twice. Yet there's no sign of that (the most recent
OK-raise entry shows the list entry still having poisoned pointers).
Or it would need to have got inserted a second time on another
CPU, but the track record thereof having got overwritten. Perhaps
now that we suspect the legacy IRQ to be the problematic one the
patch could be adjusted to track only operations on non-MSI IRQs
(or separately all three PT_IRQ_TYPE_*)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 09:34:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 09: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 1XqfAd-0003yr-EW; Tue, 18 Nov 2014 09:33:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqfAc-0003yl-A9
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 09:33:58 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	B8/28-19763-5821B645; Tue, 18 Nov 2014 09:33:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416303236!11989737!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26703 invoked from network); 18 Nov 2014 09:33:56 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 09:33:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 09:33:56 +0000
Message-Id: <546B20910200007800048AC0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 09:33:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
In-Reply-To: <546B004B.6050603@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 09:16, <tiejun.chen@intel.com> wrote:
> On 2014/11/18 16:01, Jan Beulich wrote:
>>>>> On 18.11.14 at 04:08, <tiejun.chen@intel.com> wrote:
>>> Here I tried to implement what you want. Note just pick two key
>>> fragments since others have no big deal.
>>>
>>> #1:
>>>
>>> @@ -898,14 +898,25 @@ int
>>> intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>    {
>>>        struct acpi_rmrr_unit *rmrr;
>>>        int rc = 0;
>>> +    unsigned int i;
>>> +    u32 id;
>>> +    u16 bdf;
>>>
>>>        list_for_each_entry(rmrr, &acpi_rmrr_units, list)
>>>        {
>>> -        rc = func(PFN_DOWN(rmrr->base_address),
>>> -                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
>>> -                  ctxt);
>>> -        if ( rc )
>>> -            break;
>>> +        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
>>> +                    i < rmrr->scope.devices_cnt && !rc; i++)
>>> +        {
>>> +            id = PCI_SBDF(rmrr->segment, bdf);
>>> +            rc = func(PFN_DOWN(rmrr->base_address),
>>> +                               PFN_UP(rmrr->end_address) -
>>> +                                PFN_DOWN(rmrr->base_address),
>>> +                               id,
>>> +                               ctxt);
>>> +            if ( rc < 0 )
>>> +                return rc;
>>> +        }
>>> +        rc = 0;
>>
>> Getting close - the main issue is that (as previously mentioned) you
>> should avoid open-coding for_each_rmrr_device(). It also doesn't
> 
> Sorry, are you saying these lines?
> 
>  >> +        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
>  >> +                    i < rmrr->scope.devices_cnt && !rc; i++)
> 
> So without lookuping devices[i], how can we call func() for each sbdf as 
> you mentioned?

You've got both rmrr and bdf in the body of for_each_rmrr_device().
After all - as I said - you just open-coded it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 09:34:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 09: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 1XqfAd-0003yr-EW; Tue, 18 Nov 2014 09:33:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqfAc-0003yl-A9
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 09:33:58 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	B8/28-19763-5821B645; Tue, 18 Nov 2014 09:33:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416303236!11989737!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26703 invoked from network); 18 Nov 2014 09:33:56 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 09:33:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 09:33:56 +0000
Message-Id: <546B20910200007800048AC0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 09:33:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
In-Reply-To: <546B004B.6050603@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 09:16, <tiejun.chen@intel.com> wrote:
> On 2014/11/18 16:01, Jan Beulich wrote:
>>>>> On 18.11.14 at 04:08, <tiejun.chen@intel.com> wrote:
>>> Here I tried to implement what you want. Note just pick two key
>>> fragments since others have no big deal.
>>>
>>> #1:
>>>
>>> @@ -898,14 +898,25 @@ int
>>> intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>    {
>>>        struct acpi_rmrr_unit *rmrr;
>>>        int rc = 0;
>>> +    unsigned int i;
>>> +    u32 id;
>>> +    u16 bdf;
>>>
>>>        list_for_each_entry(rmrr, &acpi_rmrr_units, list)
>>>        {
>>> -        rc = func(PFN_DOWN(rmrr->base_address),
>>> -                  PFN_UP(rmrr->end_address) - PFN_DOWN(rmrr->base_address),
>>> -                  ctxt);
>>> -        if ( rc )
>>> -            break;
>>> +        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
>>> +                    i < rmrr->scope.devices_cnt && !rc; i++)
>>> +        {
>>> +            id = PCI_SBDF(rmrr->segment, bdf);
>>> +            rc = func(PFN_DOWN(rmrr->base_address),
>>> +                               PFN_UP(rmrr->end_address) -
>>> +                                PFN_DOWN(rmrr->base_address),
>>> +                               id,
>>> +                               ctxt);
>>> +            if ( rc < 0 )
>>> +                return rc;
>>> +        }
>>> +        rc = 0;
>>
>> Getting close - the main issue is that (as previously mentioned) you
>> should avoid open-coding for_each_rmrr_device(). It also doesn't
> 
> Sorry, are you saying these lines?
> 
>  >> +        for (i = 0; (bdf = rmrr->scope.devices[i]) &&
>  >> +                    i < rmrr->scope.devices_cnt && !rc; i++)
> 
> So without lookuping devices[i], how can we call func() for each sbdf as 
> you mentioned?

You've got both rmrr and bdf in the body of for_each_rmrr_device().
After all - as I said - you just open-coded it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 09:43:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 09:43:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqfJj-0004Bf-TP; Tue, 18 Nov 2014 09:43:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqfJi-0004Ba-4s
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 09:43:22 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	A0/97-02696-9B41B645; Tue, 18 Nov 2014 09:43:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416303799!13234944!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26224 invoked from network); 18 Nov 2014 09:43:20 -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;
	18 Nov 2014 09:43:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="193902193"
Message-ID: <1416303766.17982.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 18 Nov 2014 09:42:46 +0000
In-Reply-To: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: liang.z.li@intel.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 12:10 +0000, Wei Liu wrote:
> The existence check is to make sure a device is not added to a guest
> multiple times.
> 
> PCI device backend path has different rules from vif, disk etc. For
> example:
> /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> 
> The devid for PCI devices is hardcoded 0.

FWIW I think "devid" here is effectively the PCI bus ID, and no
toolstack I know of has ever supported multiple PCI buses. In theory it
would be possible though. This means that the 0 corresponds to the
"0000:" too, I think.

This doesn't invalidate your reasoning, just FYI.

>  libxl__device_exists only
> checks up to /local/.../9/0 so it always returns true even the device is
> assignable.
> 
> Remove invocation of libxl__device_exists. We're sure at this point that
> the PCI device is assignable (hence no xenstore entry or JSON entry).
> The check is done before hand. For HVM guest it's done by calling
> xc_test_assign_device and for PV guest it's done by calling
> pciback_dev_is_assigned.
> 
> Reported-by: Li, Liang Z <liang.z.li@intel.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Konrad Wilk <konrad.wilk@oracle.com>
> ---
> This patch fixes a regression in 4.5.
> 
> The risk is that I misunderstood semantics of xc_test_assign_device and
> pciback_dev_is_assigned and end up adding several entries to JSON config
> template. But if the assignable tests are incorrect I think we have a
> bigger problem to worry about than duplicated entries in JSON template.
> 
> It would be good for someone to have PCI hotplug setup to run a quick test.  I
> think Liang confirmed (indrectly) that xc_test_assign_device worked well for
> him so I think there's won't be multiple JSON template entries for HVM guests.
> However PV side still remains to be tested.

I don't think you need any kind of special h/w support to do PV pci
hotplug to guests, do you?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 09:43:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 09:43:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqfJj-0004Bf-TP; Tue, 18 Nov 2014 09:43:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqfJi-0004Ba-4s
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 09:43:22 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	A0/97-02696-9B41B645; Tue, 18 Nov 2014 09:43:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416303799!13234944!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26224 invoked from network); 18 Nov 2014 09:43:20 -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;
	18 Nov 2014 09:43:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="193902193"
Message-ID: <1416303766.17982.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 18 Nov 2014 09:42:46 +0000
In-Reply-To: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: liang.z.li@intel.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 12:10 +0000, Wei Liu wrote:
> The existence check is to make sure a device is not added to a guest
> multiple times.
> 
> PCI device backend path has different rules from vif, disk etc. For
> example:
> /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> 
> The devid for PCI devices is hardcoded 0.

FWIW I think "devid" here is effectively the PCI bus ID, and no
toolstack I know of has ever supported multiple PCI buses. In theory it
would be possible though. This means that the 0 corresponds to the
"0000:" too, I think.

This doesn't invalidate your reasoning, just FYI.

>  libxl__device_exists only
> checks up to /local/.../9/0 so it always returns true even the device is
> assignable.
> 
> Remove invocation of libxl__device_exists. We're sure at this point that
> the PCI device is assignable (hence no xenstore entry or JSON entry).
> The check is done before hand. For HVM guest it's done by calling
> xc_test_assign_device and for PV guest it's done by calling
> pciback_dev_is_assigned.
> 
> Reported-by: Li, Liang Z <liang.z.li@intel.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Konrad Wilk <konrad.wilk@oracle.com>
> ---
> This patch fixes a regression in 4.5.
> 
> The risk is that I misunderstood semantics of xc_test_assign_device and
> pciback_dev_is_assigned and end up adding several entries to JSON config
> template. But if the assignable tests are incorrect I think we have a
> bigger problem to worry about than duplicated entries in JSON template.
> 
> It would be good for someone to have PCI hotplug setup to run a quick test.  I
> think Liang confirmed (indrectly) that xc_test_assign_device worked well for
> him so I think there's won't be multiple JSON template entries for HVM guests.
> However PV side still remains to be tested.

I don't think you need any kind of special h/w support to do PV pci
hotplug to guests, do you?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 10:15:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 10:15:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqfoQ-0004Vm-Ip; Tue, 18 Nov 2014 10:15:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XqfoO-0004Vh-Mv
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 10:15:04 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	26/D8-02559-72C1B645; Tue, 18 Nov 2014 10:15:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416305703!7830427!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11441 invoked from network); 18 Nov 2014 10:15:03 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 10:15:03 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xqfo3-0004Bs-Fa; Tue, 18 Nov 2014 10:14:43 +0000
Date: Tue, 18 Nov 2014 11:14:43 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141118101443.GA13651@deinos.phlegethon.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546A2F7D.8050507@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

At 17:25 +0000 on 17 Nov (1416241517), Andrew Cooper wrote:
> On 17/11/14 17:00, Tim Deegan wrote:
> > At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
> >> On 17/11/14 16:30, Tim Deegan wrote:
> >>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
> >>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> >>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> >>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
> >>>>>> Users don't have to use a 'cpuid= ' option in config file to turn
> >>>>>> it on.
> >>>>> I don't understand what this flag does.  I guess from the name it
> >>>>> turns on 1G pages.  I guess these are supported ?
> >>>>>
> >>>>> I would like to see comment from an x86 hypervisor maintainer.
> >>>> Yes, we support 1Gb pages. The purpose of the patch is to not
> >>>> unconditionally hide the flag from guests. (I had commented on
> >>>> v1, but sadly this one wasn't tagged as v2, nor was I included on
> >>>> the Cc list, hence I didn't spot the new version.)
> >>>>
> >>>> The one thing I'm not certain about is shadow mode: Only 2Mb
> >>>> pages may be supported there. Tim?
> >>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
> >>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
> >> This is yet another case which proves that libxc is the wrong place to
> >> be choosing the cpuid flags exposed to a domain.
> >>
> >> Furthermore, guest_supports_1G_superpages() is insufficient as it only
> >> checks whether the host is capable of providing 1G superpages, not
> >> whether the guest has been permitted to use it.
> >>
> >> This causes a problem when migrating between hap-capable and
> >> hap-incapable systems.
> > There's no notion of 'permitted' to use 1G pages, AFAICS, much like
> > other CPU features.  But of course a _well-behaved_ guest that has
> > been told in cpuid not to use 1G superpages will have no problems. :)
> 
> That is my point.
> 
> If 1GB pages are not supported (i.e. not present in cpuid), then the PS
> bit in an L3 is reserved, must be 0, and cause a pagefault if used.
> 
> Nothing in Xen currently enforces this because
> guest_supports_1G_superpages() doesn't check domain_cpuid().

For shadow mode, Xen DTRT by checking hvm_pse1gb_supported() in the
HVM cpuid handler, so we don't advertise a feature we can't support.

For HAP mode, we _could_ add a cpuid check to the pagetable walker
but...

> It does however make me wonder how VMX/SVM non-root mode would enforce
> this as it would see the host cpuid, not guest cpuid when performing
> paging internally.

...non-emulated PT walks will get to use 1GB superpages anyway.
This is the same for other features (new instructions &c).  We
can mask them out of CPUID but by and large we can't make them fault.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 10:15:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 10:15:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqfoQ-0004Vm-Ip; Tue, 18 Nov 2014 10:15:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XqfoO-0004Vh-Mv
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 10:15:04 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	26/D8-02559-72C1B645; Tue, 18 Nov 2014 10:15:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416305703!7830427!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11441 invoked from network); 18 Nov 2014 10:15:03 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 10:15:03 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xqfo3-0004Bs-Fa; Tue, 18 Nov 2014 10:14:43 +0000
Date: Tue, 18 Nov 2014 11:14:43 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141118101443.GA13651@deinos.phlegethon.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546A2F7D.8050507@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

At 17:25 +0000 on 17 Nov (1416241517), Andrew Cooper wrote:
> On 17/11/14 17:00, Tim Deegan wrote:
> > At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
> >> On 17/11/14 16:30, Tim Deegan wrote:
> >>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
> >>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> >>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> >>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
> >>>>>> Users don't have to use a 'cpuid= ' option in config file to turn
> >>>>>> it on.
> >>>>> I don't understand what this flag does.  I guess from the name it
> >>>>> turns on 1G pages.  I guess these are supported ?
> >>>>>
> >>>>> I would like to see comment from an x86 hypervisor maintainer.
> >>>> Yes, we support 1Gb pages. The purpose of the patch is to not
> >>>> unconditionally hide the flag from guests. (I had commented on
> >>>> v1, but sadly this one wasn't tagged as v2, nor was I included on
> >>>> the Cc list, hence I didn't spot the new version.)
> >>>>
> >>>> The one thing I'm not certain about is shadow mode: Only 2Mb
> >>>> pages may be supported there. Tim?
> >>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
> >>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
> >> This is yet another case which proves that libxc is the wrong place to
> >> be choosing the cpuid flags exposed to a domain.
> >>
> >> Furthermore, guest_supports_1G_superpages() is insufficient as it only
> >> checks whether the host is capable of providing 1G superpages, not
> >> whether the guest has been permitted to use it.
> >>
> >> This causes a problem when migrating between hap-capable and
> >> hap-incapable systems.
> > There's no notion of 'permitted' to use 1G pages, AFAICS, much like
> > other CPU features.  But of course a _well-behaved_ guest that has
> > been told in cpuid not to use 1G superpages will have no problems. :)
> 
> That is my point.
> 
> If 1GB pages are not supported (i.e. not present in cpuid), then the PS
> bit in an L3 is reserved, must be 0, and cause a pagefault if used.
> 
> Nothing in Xen currently enforces this because
> guest_supports_1G_superpages() doesn't check domain_cpuid().

For shadow mode, Xen DTRT by checking hvm_pse1gb_supported() in the
HVM cpuid handler, so we don't advertise a feature we can't support.

For HAP mode, we _could_ add a cpuid check to the pagetable walker
but...

> It does however make me wonder how VMX/SVM non-root mode would enforce
> this as it would see the host cpuid, not guest cpuid when performing
> paging internally.

...non-emulated PT walks will get to use 1GB superpages anyway.
This is the same for other features (new instructions &c).  We
can mask them out of CPUID but by and large we can't make them fault.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 10:41:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 10:41:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqgE4-0004je-Sn; Tue, 18 Nov 2014 10:41:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XqgE2-0004jZ-WD
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 10:41:35 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	DF/8C-09284-E522B645; Tue, 18 Nov 2014 10:41:34 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416307291!7688109!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9738 invoked from network); 18 Nov 2014 10:41:33 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 10:41:33 -0000
Received: from mail-la0-f50.google.com ([209.85.215.50]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGsiWio15+FH6v9ylKx9z7X9WI+2FdQN@postini.com;
	Tue, 18 Nov 2014 02:41:32 PST
Received: by mail-la0-f50.google.com with SMTP id pv20so1119339lab.9
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 02:41:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Vx5HfHD1UEo19wNZMnqX9B262hNCrxJa2jIYk9Ks3XA=;
	b=DRFLtSnb53bhK3TmQ/7Ik6LAgJl3T+kjIdsTCJ6hN/PvI5vqzHrN8ekg6HNWsWPQTj
	rBjnZqd91bJu25U5/TRGXkQxISn43MjBkclxCJqRKoq0CKdPE19f53mBhIJRhcTZbTpH
	PvXslaIwtCWsgS9K4qEF+ccEazdcINcSOOMss=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Vx5HfHD1UEo19wNZMnqX9B262hNCrxJa2jIYk9Ks3XA=;
	b=B2ihXfAtzsV+QoES64+6ZOTCUVWyCV1NBKJ8JoBM++z0wahgp0cJo7nHbB4N6yyKhm
	r4lraJZEBNkVkad5eigJprheYkeBYk7WoobZSCR5DtwnunqYEmpyVpVLNvYSA8bpqjy3
	SeEYJk5HUCdQiGiMmyh5pabOEQdEbJwcRCpUIqSrc6SXzNuLRPx+DL5a+f02a+slRkm3
	mRMFRhtzQzRXlMaQ51whV7xER/rQ20OIFkdJQPVtUDn3B1RT2SaPd6B+Ng9uucOnU8n/
	opGf1dK9o0avJqiJnMB3SNNKRqa5JXq+Ip0KibVE5ZC3fCyNjaYGTdP+/ikBmE1zpxvs
	fEeQ==
X-Gm-Message-State: ALoCoQlL3iqMxyr/oxVsbUqKWVjkYI2bc07dbfKJHRpGfZYVbFpjn+k07jTRiTquAMRULcoajTK4DnwXA2l66DwhsPXmls90c12tkxWn+Jch0pMfO9qyZY98Vk1Ng3SBNRVAmUBLDWXYqFS6df7czuXCM4k1Kcn8jQ==
X-Received: by 10.152.234.227 with SMTP id uh3mr35428960lac.69.1416307289205; 
	Tue, 18 Nov 2014 02:41:29 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.234.227 with SMTP id uh3mr35428947lac.69.1416307289107; 
	Tue, 18 Nov 2014 02:41:29 -0800 (PST)
Received: by 10.112.61.69 with HTTP; Tue, 18 Nov 2014 02:41:29 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
Date: Tue, 18 Nov 2014 12:41:29 +0200
Message-ID: <CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On Mon, Nov 17, 2014 at 8:02 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> Thank you for your answer.
>>
>> On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > Although it is possible that that patch is the cause of your problem,
>> > unfortunately it is part of a significant rework of the GIC driver in
>> > Xen and I am afraid that testing with only a portion of that patch
>> > series might introduce other subtle bugs.  For your reference the series
>> > starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
>> > commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
>> >
>>
>> Yes, I tested with and without the whole series.
>
> And the result is that the series causes the problem?
>

Yes.

>
>> > If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
>> > problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
>> > might not work correctly on your platform. It wouldn't be the first time
>> > that we see hardware behaving that way, especially if you are using the
>> > GIC secure registers instead of the non-secure register as GICH_LRn.HW
>> > can only deactivate non-secure interrupts. This is usually due to a
>> > configuration error in u-boot.
>> >
>> > Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
>> > platform?
>> >
>>
>> I tried this. Unfortunately it doesn't help.
>
> Could you try the following patch on top of
> 5495a512b63bad868c147198f7f049c2617d468c ?
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 302c031..a286376 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -557,10 +557,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>      BUG_ON(lr < 0);
>      BUG_ON(state & ~(GICH_LR_STATE_MASK<<GICH_LR_STATE_SHIFT));
>
> -    lr_val = state | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
> +    lr_val = state | GICH_LR_MAINTENANCE_IRQ | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> -    if ( p->desc != NULL )
> -        lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>
>      GICH[GICH_LR + lr] = lr_val;
>
> @@ -622,6 +620,12 @@ out:
>      return;
>  }
>
> +static void gic_irq_eoi(void *info)
> +{
> +    int virq = (uintptr_t) info;
> +    GICC[GICC_DIR] = virq;
> +}
> +
>  static void gic_update_one_lr(struct vcpu *v, int i)
>  {
>      struct pending_irq *p;
> @@ -639,7 +643,10 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>          irq = (lr >> GICH_LR_VIRTUAL_SHIFT) & GICH_LR_VIRTUAL_MASK;
>          p = irq_to_pending(v, irq);
>          if ( p->desc != NULL )
> +        {
> +            gic_irq_eoi((void*)(uintptr_t)irq);
>              p->desc->status &= ~IRQ_INPROGRESS;
> +        }
>          clear_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
>          if ( test_bit(GIC_IRQ_GUEST_PENDING, &p->status) &&
>                  test_bit(GIC_IRQ_GUEST_ENABLED, &p->status))


It helps! Thank you a lot!
I did about ~30 reboots and got no hangs. The only what is needed - is
to rebase these changes on top of xen/master branch.
Changes in patch can be applied only on top of
5495a512b63bad868c147198f7f049c2617d468c
Will you do this change? Is it acceptable for baseline?

Regards,
Andrii

-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 10:41:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 10:41:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqgE4-0004je-Sn; Tue, 18 Nov 2014 10:41:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XqgE2-0004jZ-WD
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 10:41:35 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	DF/8C-09284-E522B645; Tue, 18 Nov 2014 10:41:34 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416307291!7688109!1
X-Originating-IP: [64.18.0.212]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9738 invoked from network); 18 Nov 2014 10:41:33 -0000
Received: from exprod5og124.obsmtp.com (HELO exprod5og124.obsmtp.com)
	(64.18.0.212)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 10:41:33 -0000
Received: from mail-la0-f50.google.com ([209.85.215.50]) (using TLSv1) by
	exprod5ob124.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGsiWio15+FH6v9ylKx9z7X9WI+2FdQN@postini.com;
	Tue, 18 Nov 2014 02:41:32 PST
Received: by mail-la0-f50.google.com with SMTP id pv20so1119339lab.9
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 02:41:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Vx5HfHD1UEo19wNZMnqX9B262hNCrxJa2jIYk9Ks3XA=;
	b=DRFLtSnb53bhK3TmQ/7Ik6LAgJl3T+kjIdsTCJ6hN/PvI5vqzHrN8ekg6HNWsWPQTj
	rBjnZqd91bJu25U5/TRGXkQxISn43MjBkclxCJqRKoq0CKdPE19f53mBhIJRhcTZbTpH
	PvXslaIwtCWsgS9K4qEF+ccEazdcINcSOOMss=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Vx5HfHD1UEo19wNZMnqX9B262hNCrxJa2jIYk9Ks3XA=;
	b=B2ihXfAtzsV+QoES64+6ZOTCUVWyCV1NBKJ8JoBM++z0wahgp0cJo7nHbB4N6yyKhm
	r4lraJZEBNkVkad5eigJprheYkeBYk7WoobZSCR5DtwnunqYEmpyVpVLNvYSA8bpqjy3
	SeEYJk5HUCdQiGiMmyh5pabOEQdEbJwcRCpUIqSrc6SXzNuLRPx+DL5a+f02a+slRkm3
	mRMFRhtzQzRXlMaQ51whV7xER/rQ20OIFkdJQPVtUDn3B1RT2SaPd6B+Ng9uucOnU8n/
	opGf1dK9o0avJqiJnMB3SNNKRqa5JXq+Ip0KibVE5ZC3fCyNjaYGTdP+/ikBmE1zpxvs
	fEeQ==
X-Gm-Message-State: ALoCoQlL3iqMxyr/oxVsbUqKWVjkYI2bc07dbfKJHRpGfZYVbFpjn+k07jTRiTquAMRULcoajTK4DnwXA2l66DwhsPXmls90c12tkxWn+Jch0pMfO9qyZY98Vk1Ng3SBNRVAmUBLDWXYqFS6df7czuXCM4k1Kcn8jQ==
X-Received: by 10.152.234.227 with SMTP id uh3mr35428960lac.69.1416307289205; 
	Tue, 18 Nov 2014 02:41:29 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.234.227 with SMTP id uh3mr35428947lac.69.1416307289107; 
	Tue, 18 Nov 2014 02:41:29 -0800 (PST)
Received: by 10.112.61.69 with HTTP; Tue, 18 Nov 2014 02:41:29 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
Date: Tue, 18 Nov 2014 12:41:29 +0200
Message-ID: <CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On Mon, Nov 17, 2014 at 8:02 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> Thank you for your answer.
>>
>> On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > Although it is possible that that patch is the cause of your problem,
>> > unfortunately it is part of a significant rework of the GIC driver in
>> > Xen and I am afraid that testing with only a portion of that patch
>> > series might introduce other subtle bugs.  For your reference the series
>> > starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
>> > commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
>> >
>>
>> Yes, I tested with and without the whole series.
>
> And the result is that the series causes the problem?
>

Yes.

>
>> > If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
>> > problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
>> > might not work correctly on your platform. It wouldn't be the first time
>> > that we see hardware behaving that way, especially if you are using the
>> > GIC secure registers instead of the non-secure register as GICH_LRn.HW
>> > can only deactivate non-secure interrupts. This is usually due to a
>> > configuration error in u-boot.
>> >
>> > Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
>> > platform?
>> >
>>
>> I tried this. Unfortunately it doesn't help.
>
> Could you try the following patch on top of
> 5495a512b63bad868c147198f7f049c2617d468c ?
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 302c031..a286376 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -557,10 +557,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>      BUG_ON(lr < 0);
>      BUG_ON(state & ~(GICH_LR_STATE_MASK<<GICH_LR_STATE_SHIFT));
>
> -    lr_val = state | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
> +    lr_val = state | GICH_LR_MAINTENANCE_IRQ | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> -    if ( p->desc != NULL )
> -        lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>
>      GICH[GICH_LR + lr] = lr_val;
>
> @@ -622,6 +620,12 @@ out:
>      return;
>  }
>
> +static void gic_irq_eoi(void *info)
> +{
> +    int virq = (uintptr_t) info;
> +    GICC[GICC_DIR] = virq;
> +}
> +
>  static void gic_update_one_lr(struct vcpu *v, int i)
>  {
>      struct pending_irq *p;
> @@ -639,7 +643,10 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>          irq = (lr >> GICH_LR_VIRTUAL_SHIFT) & GICH_LR_VIRTUAL_MASK;
>          p = irq_to_pending(v, irq);
>          if ( p->desc != NULL )
> +        {
> +            gic_irq_eoi((void*)(uintptr_t)irq);
>              p->desc->status &= ~IRQ_INPROGRESS;
> +        }
>          clear_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
>          if ( test_bit(GIC_IRQ_GUEST_PENDING, &p->status) &&
>                  test_bit(GIC_IRQ_GUEST_ENABLED, &p->status))


It helps! Thank you a lot!
I did about ~30 reboots and got no hangs. The only what is needed - is
to rebase these changes on top of xen/master branch.
Changes in patch can be applied only on top of
5495a512b63bad868c147198f7f049c2617d468c
Will you do this change? Is it acceptable for baseline?

Regards,
Andrii

-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 10:44:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 10:44:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqgGU-0004qG-Gc; Tue, 18 Nov 2014 10:44:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqgGR-0004qA-4F
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 10:44:05 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EA/97-09842-2F22B645; Tue, 18 Nov 2014 10:44:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416307440!10100902!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20032 invoked from network); 18 Nov 2014 10:44:01 -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;
	18 Nov 2014 10:44:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="192411305"
Message-ID: <546B22ED.5020507@citrix.com>
Date: Tue, 18 Nov 2014 10:43:57 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
In-Reply-To: <20141118101443.GA13651@deinos.phlegethon.org>
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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 18/11/14 10:14, Tim Deegan wrote:
> At 17:25 +0000 on 17 Nov (1416241517), Andrew Cooper wrote:
>> On 17/11/14 17:00, Tim Deegan wrote:
>>> At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
>>>> On 17/11/14 16:30, Tim Deegan wrote:
>>>>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>>>>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>>>>>> Users don't have to use a 'cpuid= ' option in config file to turn
>>>>>>>> it on.
>>>>>>> I don't understand what this flag does.  I guess from the name it
>>>>>>> turns on 1G pages.  I guess these are supported ?
>>>>>>>
>>>>>>> I would like to see comment from an x86 hypervisor maintainer.
>>>>>> Yes, we support 1Gb pages. The purpose of the patch is to not
>>>>>> unconditionally hide the flag from guests. (I had commented on
>>>>>> v1, but sadly this one wasn't tagged as v2, nor was I included on
>>>>>> the Cc list, hence I didn't spot the new version.)
>>>>>>
>>>>>> The one thing I'm not certain about is shadow mode: Only 2Mb
>>>>>> pages may be supported there. Tim?
>>>>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
>>>>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
>>>> This is yet another case which proves that libxc is the wrong place to
>>>> be choosing the cpuid flags exposed to a domain.
>>>>
>>>> Furthermore, guest_supports_1G_superpages() is insufficient as it only
>>>> checks whether the host is capable of providing 1G superpages, not
>>>> whether the guest has been permitted to use it.
>>>>
>>>> This causes a problem when migrating between hap-capable and
>>>> hap-incapable systems.
>>> There's no notion of 'permitted' to use 1G pages, AFAICS, much like
>>> other CPU features.  But of course a _well-behaved_ guest that has
>>> been told in cpuid not to use 1G superpages will have no problems. :)
>> That is my point.
>>
>> If 1GB pages are not supported (i.e. not present in cpuid), then the PS
>> bit in an L3 is reserved, must be 0, and cause a pagefault if used.
>>
>> Nothing in Xen currently enforces this because
>> guest_supports_1G_superpages() doesn't check domain_cpuid().
> For shadow mode, Xen DTRT by checking hvm_pse1gb_supported() in the
> HVM cpuid handler, so we don't advertise a feature we can't support.
>
> For HAP mode, we _could_ add a cpuid check to the pagetable walker
> but...
>
>> It does however make me wonder how VMX/SVM non-root mode would enforce
>> this as it would see the host cpuid, not guest cpuid when performing
>> paging internally.
> ...non-emulated PT walks will get to use 1GB superpages anyway.
> This is the same for other features (new instructions &c).  We
> can mask them out of CPUID but by and large we can't make them fault.

Hmm - this is a pitfall waiting to happen.

In the case that there is a heterogeneous setup with one 1G capable and
one 1G incapable server, Xen cannot forcibly prevent the use of 1G pages
on the capable hardware.  Any VM which guesses at hardware support by
means other than cpuid features is liable to explode on migrate.

I suspect this will just have to fall into the category of "here be yet
more dragons with heterogeneous migration"

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 10:44:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 10:44:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqgGU-0004qG-Gc; Tue, 18 Nov 2014 10:44:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqgGR-0004qA-4F
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 10:44:05 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EA/97-09842-2F22B645; Tue, 18 Nov 2014 10:44:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416307440!10100902!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20032 invoked from network); 18 Nov 2014 10:44:01 -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;
	18 Nov 2014 10:44:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="192411305"
Message-ID: <546B22ED.5020507@citrix.com>
Date: Tue, 18 Nov 2014 10:43:57 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
In-Reply-To: <20141118101443.GA13651@deinos.phlegethon.org>
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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 18/11/14 10:14, Tim Deegan wrote:
> At 17:25 +0000 on 17 Nov (1416241517), Andrew Cooper wrote:
>> On 17/11/14 17:00, Tim Deegan wrote:
>>> At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
>>>> On 17/11/14 16:30, Tim Deegan wrote:
>>>>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>>>>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>>>>>> Users don't have to use a 'cpuid= ' option in config file to turn
>>>>>>>> it on.
>>>>>>> I don't understand what this flag does.  I guess from the name it
>>>>>>> turns on 1G pages.  I guess these are supported ?
>>>>>>>
>>>>>>> I would like to see comment from an x86 hypervisor maintainer.
>>>>>> Yes, we support 1Gb pages. The purpose of the patch is to not
>>>>>> unconditionally hide the flag from guests. (I had commented on
>>>>>> v1, but sadly this one wasn't tagged as v2, nor was I included on
>>>>>> the Cc list, hence I didn't spot the new version.)
>>>>>>
>>>>>> The one thing I'm not certain about is shadow mode: Only 2Mb
>>>>>> pages may be supported there. Tim?
>>>>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
>>>>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
>>>> This is yet another case which proves that libxc is the wrong place to
>>>> be choosing the cpuid flags exposed to a domain.
>>>>
>>>> Furthermore, guest_supports_1G_superpages() is insufficient as it only
>>>> checks whether the host is capable of providing 1G superpages, not
>>>> whether the guest has been permitted to use it.
>>>>
>>>> This causes a problem when migrating between hap-capable and
>>>> hap-incapable systems.
>>> There's no notion of 'permitted' to use 1G pages, AFAICS, much like
>>> other CPU features.  But of course a _well-behaved_ guest that has
>>> been told in cpuid not to use 1G superpages will have no problems. :)
>> That is my point.
>>
>> If 1GB pages are not supported (i.e. not present in cpuid), then the PS
>> bit in an L3 is reserved, must be 0, and cause a pagefault if used.
>>
>> Nothing in Xen currently enforces this because
>> guest_supports_1G_superpages() doesn't check domain_cpuid().
> For shadow mode, Xen DTRT by checking hvm_pse1gb_supported() in the
> HVM cpuid handler, so we don't advertise a feature we can't support.
>
> For HAP mode, we _could_ add a cpuid check to the pagetable walker
> but...
>
>> It does however make me wonder how VMX/SVM non-root mode would enforce
>> this as it would see the host cpuid, not guest cpuid when performing
>> paging internally.
> ...non-emulated PT walks will get to use 1GB superpages anyway.
> This is the same for other features (new instructions &c).  We
> can mask them out of CPUID but by and large we can't make them fault.

Hmm - this is a pitfall waiting to happen.

In the case that there is a heterogeneous setup with one 1G capable and
one 1G incapable server, Xen cannot forcibly prevent the use of 1G pages
on the capable hardware.  Any VM which guesses at hardware support by
means other than cpuid features is liable to explode on migrate.

I suspect this will just have to fall into the category of "here be yet
more dragons with heterogeneous migration"

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 10:51:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 10: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 1XqgNn-00051o-Li; Tue, 18 Nov 2014 10:51:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqgNl-00051j-OV
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 10:51:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	34/A8-09842-9B42B645; Tue, 18 Nov 2014 10:51:37 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416307895!6249200!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24051 invoked from network); 18 Nov 2014 10:51:36 -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;
	18 Nov 2014 10:51:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="192412922"
Message-ID: <546B24B4.6070904@citrix.com>
Date: Tue, 18 Nov 2014 10:51:32 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xensource.com>,
	<jbeulich@suse.com>, <konrad.wilk@oracle.com>, <david.vrabel@citrix.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>	<5465FB34.9010606@suse.com>	<54660A16.2090006@citrix.com>	<54660E5C.8030107@suse.com>	<546618D9.5070200@citrix.com>	<54662096.6060603@suse.com>
	<546628F7.4000008@citrix.com> <546ADA25.4000709@suse.com>
In-Reply-To: <546ADA25.4000709@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/11/14 05:33, Juergen Gross wrote:
> On 11/14/2014 05:08 PM, Andrew Cooper wrote:
>> On 14/11/14 15:32, Juergen Gross wrote:
>>> On 11/14/2014 03:59 PM, Andrew Cooper wrote:
>>>> On 14/11/14 14:14, J=FCrgen Gro=DF wrote:
>>>>> On 11/14/2014 02:56 PM, Andrew Cooper wrote:
>>>>>> On 14/11/14 12:53, Juergen Gross wrote:
>>>>>>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>>>>>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>>>>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>>>>>>> currently contains the mfn of the top level page frame of the 3
>>>>>>>>> level
>>>>>>>>> p2m tree, which is used by the Xen tools during saving and
>>>>>>>>> restoring
>>>>>>>>> (and live migration) of pv domains and for crash dump analysis.
>>>>>>>>> With
>>>>>>>>> three levels of the p2m tree it is possible to support up to 512
>>>>>>>>> GB of
>>>>>>>>> RAM for a 64 bit pv domain.
>>>>>>>>>
>>>>>>>>> A 32 bit pv domain can support more, as each memory page can hold
>>>>>>>>> 1024
>>>>>>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>>>>>>
>>>>>>>>> To be able to support more RAM on x86-64 switch to a virtual
>>>>>>>>> mapped
>>>>>>>>> p2m list.
>>>>>>>>>
>>>>>>>>> This patch expands struct arch_shared_info with a new p2m list
>>>>>>>>> virtual
>>>>>>>>> address and the mfn of the page table root. The new
>>>>>>>>> information is
>>>>>>>>> indicated by the domain to be valid by storing ~0UL into
>>>>>>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of
>>>>>>>>> this
>>>>>>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>>>>>>
>>>>>>>> How do you envisage this being used?  Are you expecting the tools
>>>>>>>> to do
>>>>>>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>>>>>>
>>>>>>> Yes. Not very different compared to today's mapping via the 3 level
>>>>>>> p2m tree. Just another entry format, 4 instead of 3 levels and
>>>>>>> starting
>>>>>>> at an offset.
>>>>>>
>>>>>> Yes - David and I were discussing this over lunch, and it is not
>>>>>> actually very different.
>>>>>>
>>>>>> In reality, how likely is it that the pages backing this virtual
>>>>>> linear
>>>>>> array change?
>>>>>
>>>>> Very unlikely, I think. But not impossible.
>>>>>
>>>>>> One issue currently is that, during the live part of migration, the
>>>>>> toolstack has no way of working out whether the structure of the
>>>>>> p2m has
>>>>>> changed (intermediate leaves rearranged, or the length increasing).
>>>>>>
>>>>>> In the case that the VM does change the structure of the p2m
>>>>>> under the
>>>>>> feet of the toolstack, migration will either blow up in a
>>>>>> non-subtle way
>>>>>> with a p2m/m2p mismatch, or in a subtle way with the receiving side
>>>>>> copying the new p2m over the wrong part of the new domain.
>>>>>>
>>>>>> I am wondering whether, with this new p2m method, we can take
>>>>>> sufficient
>>>>>> steps to be able to guarantee mishaps like this can't occur.
>>>>>
>>>>> This should be easy: I could add a counter in arch_shared_info
>>>>> which is
>>>>> incremented whenever a p2m mapping is being changed. The toolstack
>>>>> could
>>>>> compare the counter values before start and at end of migration and
>>>>> redo
>>>>> the migration (or fail) if they are different. In order to avoid
>>>>> races
>>>>> I would have to increment the counter before and after changing the
>>>>> mapping.
>>>>>
>>>>
>>>> That is insufficient I believe.
>>>>
>>>> Consider:
>>>>
>>>> * Toolstack walks pagetables and maps the frames containing the
>>>> linear p2m
>>>> * Live migration starts
>>>> * VM remaps a frame in the middle of the linear p2m
>>>> * Live migration continues, but the toolstack has a stale frame in the
>>>> middle of its view of the p2m.
>>>
>>> This would be covered by my suggestion. At the end of the memory
>>> transfer (with some bogus contents) the toolstack would discover the
>>> change of the p2m structure and either fail the migration or start it
>>> from the beginning and thus overwriting the bogus frames.
>>
>> Checking after pause is too late.  The content of the p2m is used verify
>> each frame being sent on the wire, so is in active use for the entire
>> duration of live migration.
>>
>> If the toolstack starts verifying frames being sent using information
>> from a stale p2m, the best that can be hoped for is that the toolstack
>> declares that the p2m and m2p are inconsistent and abort the migrate.
>>
>>>
>>>> As the p2m is almost never expected to change, I think it might be
>>>> better to have a flag the toolstack can set to say "The toolstack is
>>>> peeking at your p2m behind your back - you must not change its
>>>> structure."
>>>
>>> Be careful here: changes of the structure can be due to two scenarios:
>>> - ballooning (invalid entries being populated): this is no problem, as
>>>    we can stop the ballooning during live migration.
>>> - mapping of grant pages e.g. in a stub domain (first map in an area
>>>    former marked as invalid): you can't stop this, as the stub domain
>>>    has to do some work. Here a restart of the migration should work, as
>>>    the p2m structure change can only happen once for each affected p2m
>>>    page.
>>
>> Migration is not at all possible with a domain referencing foreign
>> frames.
>>
>> The live part can cope with foreign frames referenced in the ptes.  As
>> part of the pause handling in the VM, the frontends must unmap any
>> grants they have.  After pause, any remaining foreign frames cause a
>> migration failure.
>>
>>>
>>>> Having just thought this through, I think there is also a race
>>>> condition
>>>> between a VM changing an entry in the p2m, and the toolstack doing
>>>> verifications of frames being sent.
>>>
>>> Okay, so the flag you mentioned should just prohibit changes in the
>>> p2m list related to memory frames of the affected domain: ballooning
>>> up or down, or rearranging the memory layout (does this happen today?).
>>> Mapping and unmapping of grant pages should be still allowed.
>>
>> HVM guests doesn't have any of their p2m updates represented in the
>> logdirty bitmap, so ballooning an HVM guest during migrate leads to
>> unexpected holes or lack of holes on the resuming side, leading to a
>> very confused balloon driver.
>>
>> At the time I had not found a problem with PV guests, but it is now
>> clear that there is a period of time when a guest is altering its p2m
>> where the p2m and m2p are out of sync, which will cause a migration
>> failure if the toolstack observes this artefact.
>
> So ballooning should be disabled during migration. I think this should
> be handled via callbacks triggered by xenstore: one at start of
> migration to stop ballooning and one at end to restart it. I wouldn't
> want to tie this functionality to the p2m list structure, as it is
> not related to it.

It is not just ballooning.  It is any change to the p2m whatsoever. =

This includes mapping/unmapping grants, XENMEM_exchange, and the guest
simply changing the p2m layout.

I suspect that the only reason this has not been encountered in practice
is that noone has attempted migrating a domain which makes use of
foreign mappings.  It is typically only the backend drivers which map
frontend memory, and dom0 doesn't migrate.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 10:51:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 10: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 1XqgNn-00051o-Li; Tue, 18 Nov 2014 10:51:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XqgNl-00051j-OV
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 10:51:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	34/A8-09842-9B42B645; Tue, 18 Nov 2014 10:51:37 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416307895!6249200!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24051 invoked from network); 18 Nov 2014 10:51:36 -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;
	18 Nov 2014 10:51:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="192412922"
Message-ID: <546B24B4.6070904@citrix.com>
Date: Tue, 18 Nov 2014 10:51:32 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xensource.com>,
	<jbeulich@suse.com>, <konrad.wilk@oracle.com>, <david.vrabel@citrix.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>	<5465FB34.9010606@suse.com>	<54660A16.2090006@citrix.com>	<54660E5C.8030107@suse.com>	<546618D9.5070200@citrix.com>	<54662096.6060603@suse.com>
	<546628F7.4000008@citrix.com> <546ADA25.4000709@suse.com>
In-Reply-To: <546ADA25.4000709@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/11/14 05:33, Juergen Gross wrote:
> On 11/14/2014 05:08 PM, Andrew Cooper wrote:
>> On 14/11/14 15:32, Juergen Gross wrote:
>>> On 11/14/2014 03:59 PM, Andrew Cooper wrote:
>>>> On 14/11/14 14:14, J=FCrgen Gro=DF wrote:
>>>>> On 11/14/2014 02:56 PM, Andrew Cooper wrote:
>>>>>> On 14/11/14 12:53, Juergen Gross wrote:
>>>>>>> On 11/14/2014 12:41 PM, Andrew Cooper wrote:
>>>>>>>> On 14/11/14 09:37, Juergen Gross wrote:
>>>>>>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>>>>>>> currently contains the mfn of the top level page frame of the 3
>>>>>>>>> level
>>>>>>>>> p2m tree, which is used by the Xen tools during saving and
>>>>>>>>> restoring
>>>>>>>>> (and live migration) of pv domains and for crash dump analysis.
>>>>>>>>> With
>>>>>>>>> three levels of the p2m tree it is possible to support up to 512
>>>>>>>>> GB of
>>>>>>>>> RAM for a 64 bit pv domain.
>>>>>>>>>
>>>>>>>>> A 32 bit pv domain can support more, as each memory page can hold
>>>>>>>>> 1024
>>>>>>>>> instead of 512 entries, leading to a limit of 4 TB.
>>>>>>>>>
>>>>>>>>> To be able to support more RAM on x86-64 switch to a virtual
>>>>>>>>> mapped
>>>>>>>>> p2m list.
>>>>>>>>>
>>>>>>>>> This patch expands struct arch_shared_info with a new p2m list
>>>>>>>>> virtual
>>>>>>>>> address and the mfn of the page table root. The new
>>>>>>>>> information is
>>>>>>>>> indicated by the domain to be valid by storing ~0UL into
>>>>>>>>> pfn_to_mfn_frame_list_list. The hypervisor indicates usability of
>>>>>>>>> this
>>>>>>>>> feature by a new flag XENFEAT_virtual_p2m.
>>>>>>>>
>>>>>>>> How do you envisage this being used?  Are you expecting the tools
>>>>>>>> to do
>>>>>>>> manual pagetable walks using xc_map_foreign_xxx() ?
>>>>>>>
>>>>>>> Yes. Not very different compared to today's mapping via the 3 level
>>>>>>> p2m tree. Just another entry format, 4 instead of 3 levels and
>>>>>>> starting
>>>>>>> at an offset.
>>>>>>
>>>>>> Yes - David and I were discussing this over lunch, and it is not
>>>>>> actually very different.
>>>>>>
>>>>>> In reality, how likely is it that the pages backing this virtual
>>>>>> linear
>>>>>> array change?
>>>>>
>>>>> Very unlikely, I think. But not impossible.
>>>>>
>>>>>> One issue currently is that, during the live part of migration, the
>>>>>> toolstack has no way of working out whether the structure of the
>>>>>> p2m has
>>>>>> changed (intermediate leaves rearranged, or the length increasing).
>>>>>>
>>>>>> In the case that the VM does change the structure of the p2m
>>>>>> under the
>>>>>> feet of the toolstack, migration will either blow up in a
>>>>>> non-subtle way
>>>>>> with a p2m/m2p mismatch, or in a subtle way with the receiving side
>>>>>> copying the new p2m over the wrong part of the new domain.
>>>>>>
>>>>>> I am wondering whether, with this new p2m method, we can take
>>>>>> sufficient
>>>>>> steps to be able to guarantee mishaps like this can't occur.
>>>>>
>>>>> This should be easy: I could add a counter in arch_shared_info
>>>>> which is
>>>>> incremented whenever a p2m mapping is being changed. The toolstack
>>>>> could
>>>>> compare the counter values before start and at end of migration and
>>>>> redo
>>>>> the migration (or fail) if they are different. In order to avoid
>>>>> races
>>>>> I would have to increment the counter before and after changing the
>>>>> mapping.
>>>>>
>>>>
>>>> That is insufficient I believe.
>>>>
>>>> Consider:
>>>>
>>>> * Toolstack walks pagetables and maps the frames containing the
>>>> linear p2m
>>>> * Live migration starts
>>>> * VM remaps a frame in the middle of the linear p2m
>>>> * Live migration continues, but the toolstack has a stale frame in the
>>>> middle of its view of the p2m.
>>>
>>> This would be covered by my suggestion. At the end of the memory
>>> transfer (with some bogus contents) the toolstack would discover the
>>> change of the p2m structure and either fail the migration or start it
>>> from the beginning and thus overwriting the bogus frames.
>>
>> Checking after pause is too late.  The content of the p2m is used verify
>> each frame being sent on the wire, so is in active use for the entire
>> duration of live migration.
>>
>> If the toolstack starts verifying frames being sent using information
>> from a stale p2m, the best that can be hoped for is that the toolstack
>> declares that the p2m and m2p are inconsistent and abort the migrate.
>>
>>>
>>>> As the p2m is almost never expected to change, I think it might be
>>>> better to have a flag the toolstack can set to say "The toolstack is
>>>> peeking at your p2m behind your back - you must not change its
>>>> structure."
>>>
>>> Be careful here: changes of the structure can be due to two scenarios:
>>> - ballooning (invalid entries being populated): this is no problem, as
>>>    we can stop the ballooning during live migration.
>>> - mapping of grant pages e.g. in a stub domain (first map in an area
>>>    former marked as invalid): you can't stop this, as the stub domain
>>>    has to do some work. Here a restart of the migration should work, as
>>>    the p2m structure change can only happen once for each affected p2m
>>>    page.
>>
>> Migration is not at all possible with a domain referencing foreign
>> frames.
>>
>> The live part can cope with foreign frames referenced in the ptes.  As
>> part of the pause handling in the VM, the frontends must unmap any
>> grants they have.  After pause, any remaining foreign frames cause a
>> migration failure.
>>
>>>
>>>> Having just thought this through, I think there is also a race
>>>> condition
>>>> between a VM changing an entry in the p2m, and the toolstack doing
>>>> verifications of frames being sent.
>>>
>>> Okay, so the flag you mentioned should just prohibit changes in the
>>> p2m list related to memory frames of the affected domain: ballooning
>>> up or down, or rearranging the memory layout (does this happen today?).
>>> Mapping and unmapping of grant pages should be still allowed.
>>
>> HVM guests doesn't have any of their p2m updates represented in the
>> logdirty bitmap, so ballooning an HVM guest during migrate leads to
>> unexpected holes or lack of holes on the resuming side, leading to a
>> very confused balloon driver.
>>
>> At the time I had not found a problem with PV guests, but it is now
>> clear that there is a period of time when a guest is altering its p2m
>> where the p2m and m2p are out of sync, which will cause a migration
>> failure if the toolstack observes this artefact.
>
> So ballooning should be disabled during migration. I think this should
> be handled via callbacks triggered by xenstore: one at start of
> migration to stop ballooning and one at end to restart it. I wouldn't
> want to tie this functionality to the p2m list structure, as it is
> not related to it.

It is not just ballooning.  It is any change to the p2m whatsoever. =

This includes mapping/unmapping grants, XENMEM_exchange, and the guest
simply changing the p2m layout.

I suspect that the only reason this has not been encountered in practice
is that noone has attempted migrating a domain which makes use of
foreign mappings.  It is typically only the backend drivers which map
frontend memory, and dom0 doesn't migrate.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 10:56:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 10:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqgS8-0005Cp-Kh; Tue, 18 Nov 2014 10:56:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XqgS7-0005Ch-JG
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 10:56:07 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	B9/FF-26858-6C52B645; Tue, 18 Nov 2014 10:56:06 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416308164!12166612!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11470 invoked from network); 18 Nov 2014 10:56:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 10:56:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,409,1413244800"; d="scan'208";a="192413876"
Message-ID: <546B25C2.6090106@citrix.com>
Date: Tue, 18 Nov 2014 10:56:02 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Juergen Gross
	<jgross@suse.com>, <xen-devel@lists.xensource.com>, <jbeulich@suse.com>,
	<konrad.wilk@oracle.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>	<5465FB34.9010606@suse.com>	<54660A16.2090006@citrix.com>	<54660E5C.8030107@suse.com>	<546618D9.5070200@citrix.com>	<54662096.6060603@suse.com>
	<546628F7.4000008@citrix.com> <546ADA25.4000709@suse.com>
	<546B24B4.6070904@citrix.com>
In-Reply-To: <546B24B4.6070904@citrix.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/11/14 10:51, Andrew Cooper wrote:
>>
> It is not just ballooning.  It is any change to the p2m whatsoever. 
> This includes mapping/unmapping grants, XENMEM_exchange, and the guest
> simply changing the p2m layout.

Grants don't matter because they're never saved.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 10:56:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 10:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqgS8-0005Cp-Kh; Tue, 18 Nov 2014 10:56:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XqgS7-0005Ch-JG
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 10:56:07 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	B9/FF-26858-6C52B645; Tue, 18 Nov 2014 10:56:06 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416308164!12166612!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11470 invoked from network); 18 Nov 2014 10:56:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 10:56:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,409,1413244800"; d="scan'208";a="192413876"
Message-ID: <546B25C2.6090106@citrix.com>
Date: Tue, 18 Nov 2014 10:56:02 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Juergen Gross
	<jgross@suse.com>, <xen-devel@lists.xensource.com>, <jbeulich@suse.com>,
	<konrad.wilk@oracle.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<5465EA63.3010007@citrix.com>	<5465FB34.9010606@suse.com>	<54660A16.2090006@citrix.com>	<54660E5C.8030107@suse.com>	<546618D9.5070200@citrix.com>	<54662096.6060603@suse.com>
	<546628F7.4000008@citrix.com> <546ADA25.4000709@suse.com>
	<546B24B4.6070904@citrix.com>
In-Reply-To: <546B24B4.6070904@citrix.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/11/14 10:51, Andrew Cooper wrote:
>>
> It is not just ballooning.  It is any change to the p2m whatsoever. 
> This includes mapping/unmapping grants, XENMEM_exchange, and the guest
> simply changing the p2m layout.

Grants don't matter because they're never saved.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 11:08:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 11:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqgdP-0005Pg-C6; Tue, 18 Nov 2014 11:07:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqgdO-0005Pb-GM
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 11:07:46 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	39/D4-14214-1882B645; Tue, 18 Nov 2014 11:07:45 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416308863!11999388!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4633 invoked from network); 18 Nov 2014 11:07:43 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 18 Nov 2014 11:07:43 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50291 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xqgbt-0001WK-AT; Tue, 18 Nov 2014 12:06:13 +0100
Date: Tue, 18 Nov 2014 12:07:41 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1408328417.20141118120741@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20141118024927.GA32256@andromeda.dapyr.net>
References: <546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, November 18, 2014, 3:49:27 AM, you wrote:

> On Mon, Nov 17, 2014 at 11:40:11PM +0100, Sander Eikelenboom wrote:
>> 
>> Monday, November 17, 2014, 9:43:47 PM, you wrote:
>> 
>> > . snip..
>> >> > # cat /proc/interrupts |grep eth
>> >> >  36:     384183          0  xen-pirq-ioapic-level  eth0
>> >> >  63:          1          0  xen-pirq-msi-x     eth1
>> >> >  64:         24     661961  xen-pirq-msi-x     eth1-rx-0
>> >> >  65:        205          0  xen-pirq-msi-x     eth1-rx-1
>> >> >  66:        162          0  xen-pirq-msi-x     eth1-tx-0
>> >> >  67:        190          0  xen-pirq-msi-x     eth1-tx-1
>> >> > Is that a similar distribution of IRQ/MSIx you end up having?
>> >> 
>> >> These are when they are still active and assigned to dom0 (and not owned by 
>> >> pci-back) or in the guest ?
>> 
>> > In the guest.
>> >> 
>> >> I attached my /proc/interrupts for both dom0 as guest 16 with all guests running 
>> >> (on a Xen from before the dpci changes). 
>> >> With the devices passed through I only see one line with the IRQ of a 
>> >> PCI soundcard passed through to a PV guest:
>> >>   22:      38959          0          0          0          0          0  xen-pirq-ioapic-level  xen-pciback[0000:03:06.0]
>> >> 
>> >> All the other devices passed through (to HVM guests) are not visible in /proc/interrupts of dom0.
>> 
>> > Right.
>> >> 
>> >> In the guest i do get these:
>> >>  23:         35          0          0          0  xen-pirq-ioapic-level  uhci_hcd:usb3
>> >>  40:   13440077          0          0          0  xen-pirq-ioapic-level  cx25821[1], cx25821[1]
>> 
>> > That is a bit odd. You have two 'request_irq' off this sole device, which would
>> > imply that there are _two_ devices which are using the same interrupt line.
>> 
>> > But how is that possible when your device:
>> 
>> > 0a:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
>> >         Flags: bus master, fast devsel, latency 0, IRQ 47
>> >         Memory at fe200000 (64-bit, non-prefetchable) [size=2M]
>> >         Capabilities: [40] Express Endpoint, MSI 00
>> >         Capabilities: [80] Power Management version 3
>> >         Capabilities: [90] Vital Product Data
>> >         Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
>> >         Capabilities: [100] Advanced Error Reporting
>> >         Capabilities: [200] Virtual Channel
>> >         Kernel driver in use: pciback
>> 
>> > Has only one IRQ! What is the name of this device? Perhaps I've another one that
>> > is similar to this. Could you attach
>> 
>> Well it's a videograbber .. with also one port for audio (not used) that 
>> registers with alsa. I can have a look if i can disable the audio part and see if it makes a 
>> difference, i don't use it anyway.

> That is OK. I have a videograbber too - but I could not reproduce
> this.

Ok i disabled the audio part, it now says there isn't a soundcard in the guest 
and the line is just:
40:   13440077          0          0          0  xen-pirq-ioapic-level  cx25821[1]

However .. the guest still crashed tonight, it lasted for about an hour now 
(still with qemu-xen).

<BIG SNIP>
>> > Back to your crash:
>> 
>> > d16 OK-softirq 458msec ago, state:1, 52039 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>> > d16 OK-raise   489msec ago, state:1, 52049 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>> > d16 ERR-poison 561msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>> > d16 Z-softirq  731msec ago, state:3, 3 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>> > domain_crash called from io.c:938
>> > Domain 16 reported crashed by domain 32767 on cpu#5:
>> 
>> > All of it point to the legacy interrupt - that is the on that starts at Xen IRQ 47 (guest IRQ 40):
>> >  io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0
>> > IRQ:  47 affinity:02 vec:d1 type=IO-APIC-level   status=00000030 in-flight=1 domain-list=16: +47(P-M),
>> 
>> > which looks OK.
>> OK, i still don't get why the output of debug-key 'i' reports +47 as pirq here instead of the guest value 
>> (g_gsi of for this legacy interrupt which is 40 ?), like it does when it's a MSI with the PIRQ ?

> The GSIs (m_gsi in here) are hard-wired - one I/O APIC can only handle
> so many of them (24 I believe). Anything above that is via MSI or
> MSI-X which do not require IO-APIC and can be any value that the OS
> wants.

> Xen does it in sequence - so after it has exhaused the GSIs then there
> are MSIs and other vectors.
>> 
>> > I am puzzled by the driver binding twice to the same interrupt, but perhaps that
>> > is just a buggy driver.
>> 
>> Doesn't that happen more often like with integrated USB controllers ?
>>   17:          4          0          0          0          0          0  xen-pirq-ioapic-level  ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
>>   18:       4385          0          0          0          0          0  xen-pirq-ioapic-level  ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7

> That was my thinking too. I passed in all my USB devices that looked
> like that to my guest but it instead of making them be on the same
> IRQ line - QEMU put them on seperate IRQ!
 
> And even with that I couldn't reproduce this crash.
Hmm I am now testing with qemu-xen-traditional, i just noticed the output at 
guest start is different between qemu-xen-traditional and qemu-xen:

qemu-xen-traditional gives:
(XEN) [2014-11-18 08:46:33.409] io.c:550: d16: bind: m_gsi=87 g_gsi=36 dev=00.00.5 intx=0
(XEN) [2014-11-18 08:46:33.798] AMD-Vi: Disable: device id = 0x800, domain = 0, paging mode = 3
(XEN) [2014-11-18 08:46:33.798] AMD-Vi: Setup I/O page table: device id = 0x800, type = 0x1, root table = 0x3fab6a000, domain = 16, paging mode = 3
(XEN) [2014-11-18 08:46:33.798] AMD-Vi: Re-assign 0000:08:00.0 from dom0 to dom16
(XEN) [2014-11-18 08:46:34.917] io.c:550: d16: bind: m_gsi=86 g_gsi=40 dev=00.00.6 intx=0
(XEN) [2014-11-18 08:46:34.923] AMD-Vi: Disable: device id = 0xa00, domain = 0, paging mode = 3
(XEN) [2014-11-18 08:46:34.923] AMD-Vi: Setup I/O page table: device id = 0xa00, type = 0x1, root table = 0x3fab6a000, domain = 16, paging mode = 3
(XEN) [2014-11-18 08:46:34.923] AMD-Vi: Re-assign 0000:0a:00.0 from dom0 to dom16
and when the guest is booting it gives:
(XEN) [2014-11-18 08:47:02.128] io.c:584: d16: unbind: m_gsi=87 g_gsi=36 dev=00:00.5 intx=0
(XEN) [2014-11-18 08:47:02.128] io.c:684: d16 final unmap: m_irq=87 dev=00:00.5 intx=0
(XEN) [2014-11-18 08:47:02.128] io.c:550: d16: bind: m_gsi=37 g_gsi=16 dev=00.00.0 intx=0

with qemu-xen it only gives the first part:
(XEN) [2014-11-18 10:51:18.481] io.c:550: d16: bind: m_gsi=37 g_gsi=36 dev=00.00.5 intx=0
(XEN) [2014-11-18 10:51:18.889] AMD-Vi: Disable: device id = 0x800, domain = 0, paging mode = 3
(XEN) [2014-11-18 10:51:18.889] AMD-Vi: Setup I/O page table: device id = 0x800, type = 0x1, root table = 0x5071a6000, domain = 16, paging mode = 3
(XEN) [2014-11-18 10:51:18.889] AMD-Vi: Re-assign 0000:08:00.0 from dom0 to dom16
(XEN) [2014-11-18 10:51:20.016] io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0
(XEN) [2014-11-18 10:51:20.022] AMD-Vi: Disable: device id = 0xa00, domain = 0, paging mode = 3
(XEN) [2014-11-18 10:51:20.022] AMD-Vi: Setup I/O page table: device id = 0xa00, type = 0x1, root table = 0x5071a6000, domain = 16, paging mode = 3
(XEN) [2014-11-18 10:51:20.022] AMD-Vi: Re-assign 0000:0a:00.0 from dom0 to dom16

Looking at the m_gsi numbers .. could it be "pci_msitranslate=1" is not working for qemu-xen and that this causes this difference in output ?


Another strange thing i noticed with qemu-xen-traditional ..  after a while the 
irq number in /proc/interrupts is "stuck"  .. it doesn't increase anymore
 40:      10851          0          0          0  xen-pirq-ioapic-level  cx25821[1]
however the device still continues to grab video ... 

I left it running for 2 hours, of which at least 1 hour the number of irq's in /proc/interrupts did
not change for the legacy irq 40 of the videograbber. 
The other number of IRQ's in /proc/interrupts do keep increasing (also for the passed
through USB device which enabled MSI-X). 
There is no crash and no debug output or errors in xl dmesg or guest dmesg and the device was
still working until shutdown. 
This is not good for one's sanity .. :-)

> Anyhow I was wondering if you could send (or point me to)
> your xen-syms file(s). I've also attached an extra debug code that
> should give me an idea if the crash/issue shows up in certain
> situations - when we have_two_entries to deal with on one CPU.

> It should apply cleanly on top of the other one.

This one included your previous debug patch, so i had to revert that one,
than it applied cleanly, so no problem !

> Oh, and the xen-syms  - it can be either before this patch or
> after - it won't matter much as I will be looking at the
> assembler code.

> Also what version of GCC compiler are you using ?

# gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.7.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)

That's default Debian wheezy/stable.

> And lastly, the code also has an #ifdef DIFF_LIST - if you
> want to turn that on (just add #define DIFF_LIST 1 at the top of 
> the file) - it might stop the crash. Or not  :-(

> If it does stop the crash then I think we are looking at an
> GCC bug - in which case the xen-syms of that build (with
> the DIFF_LIST) would also be interesting!

Will give this patch with and without the #define DIFF_LIST 1 a shot with qemu-xen and report back.

> Thank you.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 11:08:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 11:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqgdP-0005Pg-C6; Tue, 18 Nov 2014 11:07:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqgdO-0005Pb-GM
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 11:07:46 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	39/D4-14214-1882B645; Tue, 18 Nov 2014 11:07:45 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416308863!11999388!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4633 invoked from network); 18 Nov 2014 11:07:43 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 18 Nov 2014 11:07:43 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50291 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xqgbt-0001WK-AT; Tue, 18 Nov 2014 12:06:13 +0100
Date: Tue, 18 Nov 2014 12:07:41 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1408328417.20141118120741@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20141118024927.GA32256@andromeda.dapyr.net>
References: <546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, November 18, 2014, 3:49:27 AM, you wrote:

> On Mon, Nov 17, 2014 at 11:40:11PM +0100, Sander Eikelenboom wrote:
>> 
>> Monday, November 17, 2014, 9:43:47 PM, you wrote:
>> 
>> > . snip..
>> >> > # cat /proc/interrupts |grep eth
>> >> >  36:     384183          0  xen-pirq-ioapic-level  eth0
>> >> >  63:          1          0  xen-pirq-msi-x     eth1
>> >> >  64:         24     661961  xen-pirq-msi-x     eth1-rx-0
>> >> >  65:        205          0  xen-pirq-msi-x     eth1-rx-1
>> >> >  66:        162          0  xen-pirq-msi-x     eth1-tx-0
>> >> >  67:        190          0  xen-pirq-msi-x     eth1-tx-1
>> >> > Is that a similar distribution of IRQ/MSIx you end up having?
>> >> 
>> >> These are when they are still active and assigned to dom0 (and not owned by 
>> >> pci-back) or in the guest ?
>> 
>> > In the guest.
>> >> 
>> >> I attached my /proc/interrupts for both dom0 as guest 16 with all guests running 
>> >> (on a Xen from before the dpci changes). 
>> >> With the devices passed through I only see one line with the IRQ of a 
>> >> PCI soundcard passed through to a PV guest:
>> >>   22:      38959          0          0          0          0          0  xen-pirq-ioapic-level  xen-pciback[0000:03:06.0]
>> >> 
>> >> All the other devices passed through (to HVM guests) are not visible in /proc/interrupts of dom0.
>> 
>> > Right.
>> >> 
>> >> In the guest i do get these:
>> >>  23:         35          0          0          0  xen-pirq-ioapic-level  uhci_hcd:usb3
>> >>  40:   13440077          0          0          0  xen-pirq-ioapic-level  cx25821[1], cx25821[1]
>> 
>> > That is a bit odd. You have two 'request_irq' off this sole device, which would
>> > imply that there are _two_ devices which are using the same interrupt line.
>> 
>> > But how is that possible when your device:
>> 
>> > 0a:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
>> >         Flags: bus master, fast devsel, latency 0, IRQ 47
>> >         Memory at fe200000 (64-bit, non-prefetchable) [size=2M]
>> >         Capabilities: [40] Express Endpoint, MSI 00
>> >         Capabilities: [80] Power Management version 3
>> >         Capabilities: [90] Vital Product Data
>> >         Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
>> >         Capabilities: [100] Advanced Error Reporting
>> >         Capabilities: [200] Virtual Channel
>> >         Kernel driver in use: pciback
>> 
>> > Has only one IRQ! What is the name of this device? Perhaps I've another one that
>> > is similar to this. Could you attach
>> 
>> Well it's a videograbber .. with also one port for audio (not used) that 
>> registers with alsa. I can have a look if i can disable the audio part and see if it makes a 
>> difference, i don't use it anyway.

> That is OK. I have a videograbber too - but I could not reproduce
> this.

Ok i disabled the audio part, it now says there isn't a soundcard in the guest 
and the line is just:
40:   13440077          0          0          0  xen-pirq-ioapic-level  cx25821[1]

However .. the guest still crashed tonight, it lasted for about an hour now 
(still with qemu-xen).

<BIG SNIP>
>> > Back to your crash:
>> 
>> > d16 OK-softirq 458msec ago, state:1, 52039 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>> > d16 OK-raise   489msec ago, state:1, 52049 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>> > d16 ERR-poison 561msec ago, state:0, 1 count, [prev:0000000000200200, next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>> > d16 Z-softirq  731msec ago, state:3, 3 count, [prev:ffff83054ef283e0, next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>> > domain_crash called from io.c:938
>> > Domain 16 reported crashed by domain 32767 on cpu#5:
>> 
>> > All of it point to the legacy interrupt - that is the on that starts at Xen IRQ 47 (guest IRQ 40):
>> >  io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0
>> > IRQ:  47 affinity:02 vec:d1 type=IO-APIC-level   status=00000030 in-flight=1 domain-list=16: +47(P-M),
>> 
>> > which looks OK.
>> OK, i still don't get why the output of debug-key 'i' reports +47 as pirq here instead of the guest value 
>> (g_gsi of for this legacy interrupt which is 40 ?), like it does when it's a MSI with the PIRQ ?

> The GSIs (m_gsi in here) are hard-wired - one I/O APIC can only handle
> so many of them (24 I believe). Anything above that is via MSI or
> MSI-X which do not require IO-APIC and can be any value that the OS
> wants.

> Xen does it in sequence - so after it has exhaused the GSIs then there
> are MSIs and other vectors.
>> 
>> > I am puzzled by the driver binding twice to the same interrupt, but perhaps that
>> > is just a buggy driver.
>> 
>> Doesn't that happen more often like with integrated USB controllers ?
>>   17:          4          0          0          0          0          0  xen-pirq-ioapic-level  ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
>>   18:       4385          0          0          0          0          0  xen-pirq-ioapic-level  ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7

> That was my thinking too. I passed in all my USB devices that looked
> like that to my guest but it instead of making them be on the same
> IRQ line - QEMU put them on seperate IRQ!
 
> And even with that I couldn't reproduce this crash.
Hmm I am now testing with qemu-xen-traditional, i just noticed the output at 
guest start is different between qemu-xen-traditional and qemu-xen:

qemu-xen-traditional gives:
(XEN) [2014-11-18 08:46:33.409] io.c:550: d16: bind: m_gsi=87 g_gsi=36 dev=00.00.5 intx=0
(XEN) [2014-11-18 08:46:33.798] AMD-Vi: Disable: device id = 0x800, domain = 0, paging mode = 3
(XEN) [2014-11-18 08:46:33.798] AMD-Vi: Setup I/O page table: device id = 0x800, type = 0x1, root table = 0x3fab6a000, domain = 16, paging mode = 3
(XEN) [2014-11-18 08:46:33.798] AMD-Vi: Re-assign 0000:08:00.0 from dom0 to dom16
(XEN) [2014-11-18 08:46:34.917] io.c:550: d16: bind: m_gsi=86 g_gsi=40 dev=00.00.6 intx=0
(XEN) [2014-11-18 08:46:34.923] AMD-Vi: Disable: device id = 0xa00, domain = 0, paging mode = 3
(XEN) [2014-11-18 08:46:34.923] AMD-Vi: Setup I/O page table: device id = 0xa00, type = 0x1, root table = 0x3fab6a000, domain = 16, paging mode = 3
(XEN) [2014-11-18 08:46:34.923] AMD-Vi: Re-assign 0000:0a:00.0 from dom0 to dom16
and when the guest is booting it gives:
(XEN) [2014-11-18 08:47:02.128] io.c:584: d16: unbind: m_gsi=87 g_gsi=36 dev=00:00.5 intx=0
(XEN) [2014-11-18 08:47:02.128] io.c:684: d16 final unmap: m_irq=87 dev=00:00.5 intx=0
(XEN) [2014-11-18 08:47:02.128] io.c:550: d16: bind: m_gsi=37 g_gsi=16 dev=00.00.0 intx=0

with qemu-xen it only gives the first part:
(XEN) [2014-11-18 10:51:18.481] io.c:550: d16: bind: m_gsi=37 g_gsi=36 dev=00.00.5 intx=0
(XEN) [2014-11-18 10:51:18.889] AMD-Vi: Disable: device id = 0x800, domain = 0, paging mode = 3
(XEN) [2014-11-18 10:51:18.889] AMD-Vi: Setup I/O page table: device id = 0x800, type = 0x1, root table = 0x5071a6000, domain = 16, paging mode = 3
(XEN) [2014-11-18 10:51:18.889] AMD-Vi: Re-assign 0000:08:00.0 from dom0 to dom16
(XEN) [2014-11-18 10:51:20.016] io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0
(XEN) [2014-11-18 10:51:20.022] AMD-Vi: Disable: device id = 0xa00, domain = 0, paging mode = 3
(XEN) [2014-11-18 10:51:20.022] AMD-Vi: Setup I/O page table: device id = 0xa00, type = 0x1, root table = 0x5071a6000, domain = 16, paging mode = 3
(XEN) [2014-11-18 10:51:20.022] AMD-Vi: Re-assign 0000:0a:00.0 from dom0 to dom16

Looking at the m_gsi numbers .. could it be "pci_msitranslate=1" is not working for qemu-xen and that this causes this difference in output ?


Another strange thing i noticed with qemu-xen-traditional ..  after a while the 
irq number in /proc/interrupts is "stuck"  .. it doesn't increase anymore
 40:      10851          0          0          0  xen-pirq-ioapic-level  cx25821[1]
however the device still continues to grab video ... 

I left it running for 2 hours, of which at least 1 hour the number of irq's in /proc/interrupts did
not change for the legacy irq 40 of the videograbber. 
The other number of IRQ's in /proc/interrupts do keep increasing (also for the passed
through USB device which enabled MSI-X). 
There is no crash and no debug output or errors in xl dmesg or guest dmesg and the device was
still working until shutdown. 
This is not good for one's sanity .. :-)

> Anyhow I was wondering if you could send (or point me to)
> your xen-syms file(s). I've also attached an extra debug code that
> should give me an idea if the crash/issue shows up in certain
> situations - when we have_two_entries to deal with on one CPU.

> It should apply cleanly on top of the other one.

This one included your previous debug patch, so i had to revert that one,
than it applied cleanly, so no problem !

> Oh, and the xen-syms  - it can be either before this patch or
> after - it won't matter much as I will be looking at the
> assembler code.

> Also what version of GCC compiler are you using ?

# gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.7.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)

That's default Debian wheezy/stable.

> And lastly, the code also has an #ifdef DIFF_LIST - if you
> want to turn that on (just add #define DIFF_LIST 1 at the top of 
> the file) - it might stop the crash. Or not  :-(

> If it does stop the crash then I think we are looking at an
> GCC bug - in which case the xen-syms of that build (with
> the DIFF_LIST) would also be interesting!

Will give this patch with and without the #define DIFF_LIST 1 a shot with qemu-xen and report back.

> Thank you.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 11:32:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 11: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 1Xqh0u-0005g6-D6; Tue, 18 Nov 2014 11:32:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xqh0s-0005g1-OI
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 11:32:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D3/CB-09936-23E2B645; Tue, 18 Nov 2014 11:32:02 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416310319!13525584!1
X-Originating-IP: [64.18.0.143]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27800 invoked from network); 18 Nov 2014 11:32:01 -0000
Received: from exprod5og102.obsmtp.com (HELO exprod5og102.obsmtp.com)
	(64.18.0.143)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 11:32:01 -0000
Received: from mail-qg0-f41.google.com ([209.85.192.41]) (using TLSv1) by
	exprod5ob102.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGsuLy+aLA0WRkZhZAK1HTa3wQXwn3s7@postini.com;
	Tue, 18 Nov 2014 03:32:00 PST
Received: by mail-qg0-f41.google.com with SMTP id j5so2173908qga.14
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 03:31:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=QpHbsP1+vNHOvT7GIeyT5nENX4zhRI0OZ1943zJiPsw=;
	b=NMVDky/7UdA5zQ+u5YTvEyHJHq3EjkGoh65W13sTC3HFHNLH1v/Hz716YpWtP5gHnc
	14kW/p71FujqiGGBOeuUadyhw1Ckt98Tkp2hmUdFSZOYB5AuoxiWuaWgFPUR7sFer13z
	uOhsZhYiRDViC6vSknunR0mPQBSP+AekIrNVE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=QpHbsP1+vNHOvT7GIeyT5nENX4zhRI0OZ1943zJiPsw=;
	b=OGCp4oymAnpSmbW41djgsVJCIeS7t+RZXP8R2SH6oEUU1PDMj001u5igcuYK0hMSpS
	OJVICuKC1G/+mDW29kJn6dn2e0MSsURMW3yaAo1rLS7vfu8gaBOzIXVNEH1wR/fTmY/N
	IwClE3MkrRNCR22bmoCqJ347Kdh45geR601BFYOPd7FtGZVCqyBom9Z+c2+80eDplc7T
	hDRp+RJYQtxKKDS9HTXQ/LDh8kzKZ3i/aH7Q55rv04WM0CUI28Xm2Kf2VcWXCRok0RE0
	zv50h6jD/woU6uttmP42UQDqF5SDlR35zTg1P2SFlVYQGvqA3iKwyKTwe2g1fxifRW/K
	9aBg==
X-Gm-Message-State: ALoCoQkGDqenmBjKK2fZo8NTRFGZvHNh5cgkDmSuH/TI6jO6aA7sE/6k2Gl78Zpx7ok1cEBQGfzQ/iZIDZ44D/yd25UROKNmOBIhmtI7AZoFV/OXV42qGQxRznn1aQ2YSz+mteVbtF+QfJ0jeCLXZYEgRI88bLKkhQ==
X-Received: by 10.140.105.37 with SMTP id b34mr42522046qgf.91.1416310318537;
	Tue, 18 Nov 2014 03:31:58 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.105.37 with SMTP id b34mr42522025qgf.91.1416310318408;
	Tue, 18 Nov 2014 03:31:58 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Tue, 18 Nov 2014 03:31:58 -0800 (PST)
In-Reply-To: <CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
Date: Tue, 18 Nov 2014 13:31:58 +0200
Message-ID: <CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Strange - looks like baseline code already does the same, that you
sent me yesterday. The only what is needed - is to set
PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI.
But baseline contains an issue. And in the same time changes on top of
5495a512b63bad868c147198f7f049c2617d468c work fine.

Regards,
Andrii

On Tue, Nov 18, 2014 at 12:41 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> Hi Stefano,
>
> On Mon, Nov 17, 2014 at 8:02 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
>>> Hi Stefano,
>>>
>>> Thank you for your answer.
>>>
>>> On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>> > Although it is possible that that patch is the cause of your problem,
>>> > unfortunately it is part of a significant rework of the GIC driver in
>>> > Xen and I am afraid that testing with only a portion of that patch
>>> > series might introduce other subtle bugs.  For your reference the series
>>> > starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
>>> > commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
>>> >
>>>
>>> Yes, I tested with and without the whole series.
>>
>> And the result is that the series causes the problem?
>>
>
> Yes.
>
>>
>>> > If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
>>> > problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
>>> > might not work correctly on your platform. It wouldn't be the first time
>>> > that we see hardware behaving that way, especially if you are using the
>>> > GIC secure registers instead of the non-secure register as GICH_LRn.HW
>>> > can only deactivate non-secure interrupts. This is usually due to a
>>> > configuration error in u-boot.
>>> >
>>> > Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
>>> > platform?
>>> >
>>>
>>> I tried this. Unfortunately it doesn't help.
>>
>> Could you try the following patch on top of
>> 5495a512b63bad868c147198f7f049c2617d468c ?
>>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 302c031..a286376 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -557,10 +557,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>>      BUG_ON(lr < 0);
>>      BUG_ON(state & ~(GICH_LR_STATE_MASK<<GICH_LR_STATE_SHIFT));
>>
>> -    lr_val = state | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>> +    lr_val = state | GICH_LR_MAINTENANCE_IRQ | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>>          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>> -    if ( p->desc != NULL )
>> -        lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>>
>>      GICH[GICH_LR + lr] = lr_val;
>>
>> @@ -622,6 +620,12 @@ out:
>>      return;
>>  }
>>
>> +static void gic_irq_eoi(void *info)
>> +{
>> +    int virq = (uintptr_t) info;
>> +    GICC[GICC_DIR] = virq;
>> +}
>> +
>>  static void gic_update_one_lr(struct vcpu *v, int i)
>>  {
>>      struct pending_irq *p;
>> @@ -639,7 +643,10 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>>          irq = (lr >> GICH_LR_VIRTUAL_SHIFT) & GICH_LR_VIRTUAL_MASK;
>>          p = irq_to_pending(v, irq);
>>          if ( p->desc != NULL )
>> +        {
>> +            gic_irq_eoi((void*)(uintptr_t)irq);
>>              p->desc->status &= ~IRQ_INPROGRESS;
>> +        }
>>          clear_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
>>          if ( test_bit(GIC_IRQ_GUEST_PENDING, &p->status) &&
>>                  test_bit(GIC_IRQ_GUEST_ENABLED, &p->status))
>
>
> It helps! Thank you a lot!
> I did about ~30 reboots and got no hangs. The only what is needed - is
> to rebase these changes on top of xen/master branch.
> Changes in patch can be applied only on top of
> 5495a512b63bad868c147198f7f049c2617d468c
> Will you do this change? Is it acceptable for baseline?
>
> Regards,
> Andrii
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 11:32:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 11: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 1Xqh0u-0005g6-D6; Tue, 18 Nov 2014 11:32:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xqh0s-0005g1-OI
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 11:32:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D3/CB-09936-23E2B645; Tue, 18 Nov 2014 11:32:02 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416310319!13525584!1
X-Originating-IP: [64.18.0.143]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27800 invoked from network); 18 Nov 2014 11:32:01 -0000
Received: from exprod5og102.obsmtp.com (HELO exprod5og102.obsmtp.com)
	(64.18.0.143)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 11:32:01 -0000
Received: from mail-qg0-f41.google.com ([209.85.192.41]) (using TLSv1) by
	exprod5ob102.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGsuLy+aLA0WRkZhZAK1HTa3wQXwn3s7@postini.com;
	Tue, 18 Nov 2014 03:32:00 PST
Received: by mail-qg0-f41.google.com with SMTP id j5so2173908qga.14
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 03:31:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=QpHbsP1+vNHOvT7GIeyT5nENX4zhRI0OZ1943zJiPsw=;
	b=NMVDky/7UdA5zQ+u5YTvEyHJHq3EjkGoh65W13sTC3HFHNLH1v/Hz716YpWtP5gHnc
	14kW/p71FujqiGGBOeuUadyhw1Ckt98Tkp2hmUdFSZOYB5AuoxiWuaWgFPUR7sFer13z
	uOhsZhYiRDViC6vSknunR0mPQBSP+AekIrNVE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=QpHbsP1+vNHOvT7GIeyT5nENX4zhRI0OZ1943zJiPsw=;
	b=OGCp4oymAnpSmbW41djgsVJCIeS7t+RZXP8R2SH6oEUU1PDMj001u5igcuYK0hMSpS
	OJVICuKC1G/+mDW29kJn6dn2e0MSsURMW3yaAo1rLS7vfu8gaBOzIXVNEH1wR/fTmY/N
	IwClE3MkrRNCR22bmoCqJ347Kdh45geR601BFYOPd7FtGZVCqyBom9Z+c2+80eDplc7T
	hDRp+RJYQtxKKDS9HTXQ/LDh8kzKZ3i/aH7Q55rv04WM0CUI28Xm2Kf2VcWXCRok0RE0
	zv50h6jD/woU6uttmP42UQDqF5SDlR35zTg1P2SFlVYQGvqA3iKwyKTwe2g1fxifRW/K
	9aBg==
X-Gm-Message-State: ALoCoQkGDqenmBjKK2fZo8NTRFGZvHNh5cgkDmSuH/TI6jO6aA7sE/6k2Gl78Zpx7ok1cEBQGfzQ/iZIDZ44D/yd25UROKNmOBIhmtI7AZoFV/OXV42qGQxRznn1aQ2YSz+mteVbtF+QfJ0jeCLXZYEgRI88bLKkhQ==
X-Received: by 10.140.105.37 with SMTP id b34mr42522046qgf.91.1416310318537;
	Tue, 18 Nov 2014 03:31:58 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.105.37 with SMTP id b34mr42522025qgf.91.1416310318408;
	Tue, 18 Nov 2014 03:31:58 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Tue, 18 Nov 2014 03:31:58 -0800 (PST)
In-Reply-To: <CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
Date: Tue, 18 Nov 2014 13:31:58 +0200
Message-ID: <CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Strange - looks like baseline code already does the same, that you
sent me yesterday. The only what is needed - is to set
PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI.
But baseline contains an issue. And in the same time changes on top of
5495a512b63bad868c147198f7f049c2617d468c work fine.

Regards,
Andrii

On Tue, Nov 18, 2014 at 12:41 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> Hi Stefano,
>
> On Mon, Nov 17, 2014 at 8:02 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
>>> Hi Stefano,
>>>
>>> Thank you for your answer.
>>>
>>> On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>> > Although it is possible that that patch is the cause of your problem,
>>> > unfortunately it is part of a significant rework of the GIC driver in
>>> > Xen and I am afraid that testing with only a portion of that patch
>>> > series might introduce other subtle bugs.  For your reference the series
>>> > starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
>>> > commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
>>> >
>>>
>>> Yes, I tested with and without the whole series.
>>
>> And the result is that the series causes the problem?
>>
>
> Yes.
>
>>
>>> > If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
>>> > problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
>>> > might not work correctly on your platform. It wouldn't be the first time
>>> > that we see hardware behaving that way, especially if you are using the
>>> > GIC secure registers instead of the non-secure register as GICH_LRn.HW
>>> > can only deactivate non-secure interrupts. This is usually due to a
>>> > configuration error in u-boot.
>>> >
>>> > Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
>>> > platform?
>>> >
>>>
>>> I tried this. Unfortunately it doesn't help.
>>
>> Could you try the following patch on top of
>> 5495a512b63bad868c147198f7f049c2617d468c ?
>>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 302c031..a286376 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -557,10 +557,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>>      BUG_ON(lr < 0);
>>      BUG_ON(state & ~(GICH_LR_STATE_MASK<<GICH_LR_STATE_SHIFT));
>>
>> -    lr_val = state | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>> +    lr_val = state | GICH_LR_MAINTENANCE_IRQ | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>>          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>> -    if ( p->desc != NULL )
>> -        lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>>
>>      GICH[GICH_LR + lr] = lr_val;
>>
>> @@ -622,6 +620,12 @@ out:
>>      return;
>>  }
>>
>> +static void gic_irq_eoi(void *info)
>> +{
>> +    int virq = (uintptr_t) info;
>> +    GICC[GICC_DIR] = virq;
>> +}
>> +
>>  static void gic_update_one_lr(struct vcpu *v, int i)
>>  {
>>      struct pending_irq *p;
>> @@ -639,7 +643,10 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>>          irq = (lr >> GICH_LR_VIRTUAL_SHIFT) & GICH_LR_VIRTUAL_MASK;
>>          p = irq_to_pending(v, irq);
>>          if ( p->desc != NULL )
>> +        {
>> +            gic_irq_eoi((void*)(uintptr_t)irq);
>>              p->desc->status &= ~IRQ_INPROGRESS;
>> +        }
>>          clear_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
>>          if ( test_bit(GIC_IRQ_GUEST_PENDING, &p->status) &&
>>                  test_bit(GIC_IRQ_GUEST_ENABLED, &p->status))
>
>
> It helps! Thank you a lot!
> I did about ~30 reboots and got no hangs. The only what is needed - is
> to rebase these changes on top of xen/master branch.
> Changes in patch can be applied only on top of
> 5495a512b63bad868c147198f7f049c2617d468c
> Will you do this change? Is it acceptable for baseline?
>
> Regards,
> Andrii
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 11:42:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 11:42:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqhAp-0005qA-QT; Tue, 18 Nov 2014 11:42:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1XqhAn-0005q4-J9
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 11:42:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8A/A3-09842-8903B645; Tue, 18 Nov 2014 11:42:16 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416310933!13570930!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22408 invoked from network); 18 Nov 2014 11:42:13 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-21.messagelabs.com with SMTP;
	18 Nov 2014 11:42:13 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 18 Nov 2014 03:39:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,409,1413270000"; d="scan'208";a="638905861"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by orsmga002.jf.intel.com with ESMTP; 18 Nov 2014 03:41:49 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 18 Nov 2014 19:41:42 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Tue, 18 Nov 2014 19:41:40 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest
Thread-Index: AQHQAxh40OPG79GTNEGKmyo8ZLinmpxlrM6AgACVuEA=
Date: Tue, 18 Nov 2014 11:41:40 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
In-Reply-To: <546B22ED.5020507@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Li, Liang Z" <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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

Andrew Cooper wrote on 2014-11-18:
> On 18/11/14 10:14, Tim Deegan wrote:
>> At 17:25 +0000 on 17 Nov (1416241517), Andrew Cooper wrote:
>>> On 17/11/14 17:00, Tim Deegan wrote:
>>>> At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
>>>>> On 17/11/14 16:30, Tim Deegan wrote:
>>>>>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag
>>>>>>>> to
> guest"):
>>>>>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>>>>>>> Users don't have to use a 'cpuid= ' option in config file to
>>>>>>>>> turn it on.
>>>>>>>> I don't understand what this flag does.  I guess from the name
>>>>>>>> it turns on 1G pages.  I guess these are supported ?
>>>>>>>> 
>>>>>>>> I would like to see comment from an x86 hypervisor maintainer.
>>>>>>> Yes, we support 1Gb pages. The purpose of the patch is to not
>>>>>>> unconditionally hide the flag from guests. (I had commented on
>>>>>>> v1, but sadly this one wasn't tagged as v2, nor was I included
>>>>>>> on the Cc list, hence I didn't spot the new version.)
>>>>>>> 
>>>>>>> The one thing I'm not certain about is shadow mode: Only 2Mb
>>>>>>> pages may be supported there. Tim?
>>>>>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
>>>>>> 
>>>>>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mod
>>>>>> e_hap()
>>>>> This is yet another case which proves that libxc is the wrong
>>>>> place to be choosing the cpuid flags exposed to a domain.
>>>>> 
>>>>> Furthermore, guest_supports_1G_superpages() is insufficient as it
>>>>> only checks whether the host is capable of providing 1G
>>>>> superpages, not whether the guest has been permitted to use it.
>>>>> 
>>>>> This causes a problem when migrating between hap-capable and
>>>>> hap-incapable systems.
>>>> There's no notion of 'permitted' to use 1G pages, AFAICS, much
>>>> like other CPU features.  But of course a _well-behaved_ guest
>>>> that has been told in cpuid not to use 1G superpages will have no problems.
>>>> :)
>>> That is my point.
>>> 
>>> If 1GB pages are not supported (i.e. not present in cpuid), then
>>> the PS bit in an L3 is reserved, must be 0, and cause a pagefault if used.
>>> 
>>> Nothing in Xen currently enforces this because
>>> guest_supports_1G_superpages() doesn't check domain_cpuid().
>> For shadow mode, Xen DTRT by checking hvm_pse1gb_supported() in the
>> HVM cpuid handler, so we don't advertise a feature we can't support.
>> 
>> For HAP mode, we _could_ add a cpuid check to the pagetable walker
>> but...
>> 
>>> It does however make me wonder how VMX/SVM non-root mode would
>>> enforce this as it would see the host cpuid, not guest cpuid when
>>> performing paging internally.
>> ...non-emulated PT walks will get to use 1GB superpages anyway.
>> This is the same for other features (new instructions &c).  We can
>> mask them out of CPUID but by and large we can't make them fault.

Agree. I will forward this question to internally to see whether they aware of this problem.

> 
> Hmm - this is a pitfall waiting to happen.
> 
> In the case that there is a heterogeneous setup with one 1G capable
> and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
> pages on the capable hardware.  Any VM which guesses at hardware
> support by means other than cpuid features is liable to explode on migrate.

But a normal guest shouldn't to guess it, right?

> 
> I suspect this will just have to fall into the category of "here be
> yet more dragons with heterogeneous migration"
> 
> ~Andrew


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 11:42:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 11:42:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqhAp-0005qA-QT; Tue, 18 Nov 2014 11:42:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1XqhAn-0005q4-J9
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 11:42:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8A/A3-09842-8903B645; Tue, 18 Nov 2014 11:42:16 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416310933!13570930!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22408 invoked from network); 18 Nov 2014 11:42:13 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-21.messagelabs.com with SMTP;
	18 Nov 2014 11:42:13 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 18 Nov 2014 03:39:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,409,1413270000"; d="scan'208";a="638905861"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by orsmga002.jf.intel.com with ESMTP; 18 Nov 2014 03:41:49 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 18 Nov 2014 19:41:42 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Tue, 18 Nov 2014 19:41:40 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest
Thread-Index: AQHQAxh40OPG79GTNEGKmyo8ZLinmpxlrM6AgACVuEA=
Date: Tue, 18 Nov 2014 11:41:40 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
In-Reply-To: <546B22ED.5020507@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Li, Liang Z" <liang.z.li@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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

Andrew Cooper wrote on 2014-11-18:
> On 18/11/14 10:14, Tim Deegan wrote:
>> At 17:25 +0000 on 17 Nov (1416241517), Andrew Cooper wrote:
>>> On 17/11/14 17:00, Tim Deegan wrote:
>>>> At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
>>>>> On 17/11/14 16:30, Tim Deegan wrote:
>>>>>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag
>>>>>>>> to
> guest"):
>>>>>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>>>>>>> Users don't have to use a 'cpuid= ' option in config file to
>>>>>>>>> turn it on.
>>>>>>>> I don't understand what this flag does.  I guess from the name
>>>>>>>> it turns on 1G pages.  I guess these are supported ?
>>>>>>>> 
>>>>>>>> I would like to see comment from an x86 hypervisor maintainer.
>>>>>>> Yes, we support 1Gb pages. The purpose of the patch is to not
>>>>>>> unconditionally hide the flag from guests. (I had commented on
>>>>>>> v1, but sadly this one wasn't tagged as v2, nor was I included
>>>>>>> on the Cc list, hence I didn't spot the new version.)
>>>>>>> 
>>>>>>> The one thing I'm not certain about is shadow mode: Only 2Mb
>>>>>>> pages may be supported there. Tim?
>>>>>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
>>>>>> 
>>>>>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mod
>>>>>> e_hap()
>>>>> This is yet another case which proves that libxc is the wrong
>>>>> place to be choosing the cpuid flags exposed to a domain.
>>>>> 
>>>>> Furthermore, guest_supports_1G_superpages() is insufficient as it
>>>>> only checks whether the host is capable of providing 1G
>>>>> superpages, not whether the guest has been permitted to use it.
>>>>> 
>>>>> This causes a problem when migrating between hap-capable and
>>>>> hap-incapable systems.
>>>> There's no notion of 'permitted' to use 1G pages, AFAICS, much
>>>> like other CPU features.  But of course a _well-behaved_ guest
>>>> that has been told in cpuid not to use 1G superpages will have no problems.
>>>> :)
>>> That is my point.
>>> 
>>> If 1GB pages are not supported (i.e. not present in cpuid), then
>>> the PS bit in an L3 is reserved, must be 0, and cause a pagefault if used.
>>> 
>>> Nothing in Xen currently enforces this because
>>> guest_supports_1G_superpages() doesn't check domain_cpuid().
>> For shadow mode, Xen DTRT by checking hvm_pse1gb_supported() in the
>> HVM cpuid handler, so we don't advertise a feature we can't support.
>> 
>> For HAP mode, we _could_ add a cpuid check to the pagetable walker
>> but...
>> 
>>> It does however make me wonder how VMX/SVM non-root mode would
>>> enforce this as it would see the host cpuid, not guest cpuid when
>>> performing paging internally.
>> ...non-emulated PT walks will get to use 1GB superpages anyway.
>> This is the same for other features (new instructions &c).  We can
>> mask them out of CPUID but by and large we can't make them fault.

Agree. I will forward this question to internally to see whether they aware of this problem.

> 
> Hmm - this is a pitfall waiting to happen.
> 
> In the case that there is a heterogeneous setup with one 1G capable
> and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
> pages on the capable hardware.  Any VM which guesses at hardware
> support by means other than cpuid features is liable to explode on migrate.

But a normal guest shouldn't to guess it, right?

> 
> I suspect this will just have to fall into the category of "here be
> yet more dragons with heterogeneous migration"
> 
> ~Andrew


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 12:19:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 12:19:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqhkG-0006Ff-11; Tue, 18 Nov 2014 12:18:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqhkF-0006Fa-AY
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 12:18:55 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	99/E4-24859-E293B645; Tue, 18 Nov 2014 12:18:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416313131!9699597!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5842 invoked from network); 18 Nov 2014 12:18:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 12:18:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,409,1413244800"; d="scan'208";a="193937316"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 07:18:44 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqhk3-0003gI-L4;
	Tue, 18 Nov 2014 12:18:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqhk3-0007D3-Bp;
	Tue, 18 Nov 2014 12:18:43 +0000
Date: Tue, 18 Nov 2014 12:18:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31651-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11464
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31651: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6686748813729963253=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6686748813729963253==
Content-Type: text/plain
Content-Length: 11229
Content-Transfer-Encoding: quoted-printable

flight 31651 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31651/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                4e70f9271dabc58fbf14680843bfac510c193152
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liang <liang.z.li@intel.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12699 lines long.)


--===============6686748813729963253==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6686748813729963253==--

From xen-devel-bounces@lists.xen.org Tue Nov 18 12:19:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 12:19:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqhkG-0006Ff-11; Tue, 18 Nov 2014 12:18:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqhkF-0006Fa-AY
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 12:18:55 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	99/E4-24859-E293B645; Tue, 18 Nov 2014 12:18:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416313131!9699597!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5842 invoked from network); 18 Nov 2014 12:18:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 12:18:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,409,1413244800"; d="scan'208";a="193937316"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 07:18:44 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqhk3-0003gI-L4;
	Tue, 18 Nov 2014 12:18:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqhk3-0007D3-Bp;
	Tue, 18 Nov 2014 12:18:43 +0000
Date: Tue, 18 Nov 2014 12:18:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31651-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11464
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31651: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6686748813729963253=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6686748813729963253==
Content-Type: text/plain
Content-Length: 11229
Content-Transfer-Encoding: quoted-printable

flight 31651 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31651/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                4e70f9271dabc58fbf14680843bfac510c193152
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liang <liang.z.li@intel.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12699 lines long.)


--===============6686748813729963253==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6686748813729963253==--

From xen-devel-bounces@lists.xen.org Tue Nov 18 12:24:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 12: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 1Xqhpz-0006Rb-TK; Tue, 18 Nov 2014 12:24:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xqhpw-0006Qf-7P; Tue, 18 Nov 2014 12:24:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4E/26-25276-F8A3B645; Tue, 18 Nov 2014 12:24:47 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416313485!13552852!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29542 invoked from network); 18 Nov 2014 12:24:46 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Nov 2014 12:24:46 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XqhpL-0000LT-DX; Tue, 18 Nov 2014 12:24:11 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XqhpL-0003SX-7Z; Tue, 18 Nov 2014 12:24:11 +0000
Date: Tue, 18 Nov 2014 12:24:11 +0000
Message-Id: <E1XqhpL-0003SX-7Z@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 110 (CVE-2014-8595) - Missing
 privilege level checks in x86 emulation of far branches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2014-8595 / XSA-110
                              version 3

    Missing privilege level checks in x86 emulation of far branches

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

The emulation of far branch instructions (CALL, JMP, and RETF in Intel
assembly syntax, LCALL, LJMP, and LRET in AT&T assembly syntax)
incompletely performs privilege checks.

However these instructions are not usually handled by the emulator.
Exceptions to this are
- - when a memory operand lives in (emulated or passed through) memory
  mapped IO space,
- - in the case of guests running in 32-bit PAE mode, when such an
  instruction is (in execution flow) within four instructions of one
  doing a page table update,
- - when an Invalid Opcode exception gets raised by a guest instruction,
  and the guest then (likely maliciously) alters the instruction to
  become one of the affected ones,
- - when the guest is in real mode (in which case there are no privilege
  checks anyway).

IMPACT
======

Malicious HVM guest user mode code may be able to elevate its
privileges to guest supervisor mode, or to crash the guest.

VULNERABLE SYSTEMS
==================

Xen 3.2.1 and onward are vulnerable on x86 systems.

ARM systems are not vulnerable.

Only user processes in x86 HVM guests can take advantage of this
vulnerability.

MITIGATION
==========

Running only PV guests will avoid this issue.

There is no mitigation available for HVM guests.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa110-unstable.patch        xen-unstable, Xen 4.4.x
xsa110-4.3-and-4.2.patch     Xen 4.3.x, Xen 4.2.x

$ sha256sum xsa110*.patch
a114ba586d18125b368112527a077abfe309826ad47aca8cc80ba4549c5f9ae2  xsa110-4.3-and-4.2.patch
eac4691848dcd093903e0a0f5fd7ab15be15d0f10b98575379911e91e5dcbd70  xsa110.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUazojAAoJEIP+FMlX6CvZF18H/1/G49MGk6/Fq6CtpvoEvQsl
u7Q0UHoMuwqN119fRKJOorAh+MPKWDaPBjZoNmfJxIKEHD5tpA1Kr97y67Ye/dtz
UfXxQPiIYpOe/Z59E3erKGDyzC5TLlPfa7fZBvZdeStIWsC+d2pUWDTRBioDHBGZ
IeNnXkrLuhLrjGOs9a4ZNdP/jTFkJQ7vKJXF8nFhcEpK8XZx9D8e2xExTWZ2BJ/N
u6KbWgMAf01M10hcQze99Wm3Fuva/HkVhiza8Rj5cgsV9SD4ZrQMhH9Mm86/YG52
AEwT6j8KWd83zZz8WZjFS30edZ4/eIXW+2e3KuaUFKBiei88tlF6CYWq6upS/5U=
=u7Zi
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa110-4.3-and-4.2.patch"
Content-Disposition: attachment; filename="xsa110-4.3-and-4.2.patch"
Content-Transfer-Encoding: base64

eDg2ZW11bDogZW5mb3JjZSBwcml2aWxlZ2UgbGV2ZWwgcmVzdHJpY3Rpb25z
IHdoZW4gbG9hZGluZyBDUwoKUHJpdmlsZWdlIGxldmVsIGNoZWNrcyB3ZXJl
IGJhc2ljYWxseSBtaXNzaW5nIGZvciB0aGUgQ1MgY2FzZSwgdGhlCm9ubHkg
Y2hlY2sgdGhhdCB3YXMgZG9uZSAoUlBMID09IERQTCBmb3Igbm9uY29uZm9y
bWluZyBzZWdtZW50cykKd2FzIHNvbGVseSBjb3ZlcmluZyBhIHNpbmdsZSBz
cGVjaWFsIGNhc2UgKHJldHVybiB0byBub24tY29uZm9ybWluZwpzZWdtZW50
KS4KCkFkZGl0aW9uYWxseSBpbiBsb25nIG1vZGUgdGhlIEwgYml0IHNldCBy
ZXF1aXJlcyB0aGUgRCBiaXQgdG8gYmUgY2xlYXIsCmFzIHdhcyByZWNlbnRs
eSBwb2ludGVkIG91dCBmb3IgS1ZNIGJ5IE5hZGF2IEFtaXQKPG5hbWl0QGNz
LnRlY2huaW9uLmFjLmlsPi4KCkZpbmFsbHkgd2UgYWxzbyBuZWVkIHRvIGZv
cmNlIHRoZSBsb2FkZWQgc2VsZWN0b3IncyBSUEwgdG8gQ1BMIChhdApsZWFz
dCBhcyBsb25nIGFzIGxyZXQvcmV0ZiBlbXVsYXRpb24gZG9lc24ndCBzdXBw
b3J0IHByaXZpbGVnZSBsZXZlbApjaGFuZ2VzKS4KClRoaXMgaXMgWFNBLTEx
MC4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl
LmNvbT4KUmV2aWV3ZWQtYnk6IFRpbSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoK
LS0tIGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMK
KysrIGIveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMK
QEAgLTExMDcsNyArMTEwNyw3IEBAIHJlYWxtb2RlX2xvYWRfc2VnKAogc3Rh
dGljIGludAogcHJvdG1vZGVfbG9hZF9zZWcoCiAgICAgZW51bSB4ODZfc2Vn
bWVudCBzZWcsCi0gICAgdWludDE2X3Qgc2VsLAorICAgIHVpbnQxNl90IHNl
bCwgYm9vbF90IGlzX3JldCwKICAgICBzdHJ1Y3QgeDg2X2VtdWxhdGVfY3R4
dCAqY3R4dCwKICAgICBjb25zdCBzdHJ1Y3QgeDg2X2VtdWxhdGVfb3BzICpv
cHMpCiB7CkBAIC0xMTc5LDkgKzExNzksMjMgQEAgcHJvdG1vZGVfbG9hZF9z
ZWcoCiAgICAgICAgIC8qIENvZGUgc2VnbWVudD8gKi8KICAgICAgICAgaWYg
KCAhKGRlc2MuYiAmICgxdTw8MTEpKSApCiAgICAgICAgICAgICBnb3RvIHJh
aXNlX2V4bjsKLSAgICAgICAgLyogTm9uLWNvbmZvcm1pbmcgc2VnbWVudDog
Y2hlY2sgRFBMIGFnYWluc3QgUlBMLiAqLwotICAgICAgICBpZiAoICgoZGVz
Yy5iICYgKDZ1PDw5KSkgIT0gKDZ1PDw5KSkgJiYgKGRwbCAhPSBycGwpICkK
KyAgICAgICAgaWYgKCBpc19yZXQKKyAgICAgICAgICAgICA/IC8qCisgICAg
ICAgICAgICAgICAgKiBSZWFsbHkgcnBsIDwgY3BsLCBidXQgb3VyIHNvbGUg
Y2FsbGVyIGRvZXNuJ3QgaGFuZGxlCisgICAgICAgICAgICAgICAgKiBwcml2
aWxlZ2UgbGV2ZWwgY2hhbmdlcy4KKyAgICAgICAgICAgICAgICAqLworICAg
ICAgICAgICAgICAgcnBsICE9IGNwbCB8fCAoZGVzYy5iICYgKDEgPDwgMTAp
ID8gZHBsID4gcnBsIDogZHBsICE9IHJwbCkKKyAgICAgICAgICAgICA6IGRl
c2MuYiAmICgxIDw8IDEwKQorICAgICAgICAgICAgICAgLyogQ29uZm9ybWlu
ZyBzZWdtZW50OiBjaGVjayBEUEwgYWdhaW5zdCBDUEwuICovCisgICAgICAg
ICAgICAgICA/IGRwbCA+IGNwbAorICAgICAgICAgICAgICAgLyogTm9uLWNv
bmZvcm1pbmcgc2VnbWVudDogY2hlY2sgUlBMIGFuZCBEUEwgYWdhaW5zdCBD
UEwuICovCisgICAgICAgICAgICAgICA6IHJwbCA+IGNwbCB8fCBkcGwgIT0g
Y3BsICkKICAgICAgICAgICAgIGdvdG8gcmFpc2VfZXhuOworICAgICAgICAv
KiA2NC1iaXQgY29kZSBzZWdtZW50cyAoTCBiaXQgc2V0KSBtdXN0IGhhdmUg
RCBiaXQgY2xlYXIuICovCisgICAgICAgIGlmICggaW5fbG9uZ21vZGUoY3R4
dCwgb3BzKSAmJgorICAgICAgICAgICAgIChkZXNjLmIgJiAoMSA8PCAyMSkp
ICYmIChkZXNjLmIgJiAoMSA8PCAyMikpICkKKyAgICAgICAgICAgIGdvdG8g
cmFpc2VfZXhuOworICAgICAgICBzZWwgPSAoc2VsIF4gcnBsKSB8IGNwbDsK
ICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSB4ODZfc2VnX3NzOgogICAgICAg
ICAvKiBXcml0YWJsZSBkYXRhIHNlZ21lbnQ/ICovCkBAIC0xMjQ2LDcgKzEy
NjAsNyBAQCBwcm90bW9kZV9sb2FkX3NlZygKIHN0YXRpYyBpbnQKIGxvYWRf
c2VnKAogICAgIGVudW0geDg2X3NlZ21lbnQgc2VnLAotICAgIHVpbnQxNl90
IHNlbCwKKyAgICB1aW50MTZfdCBzZWwsIGJvb2xfdCBpc19yZXQsCiAgICAg
c3RydWN0IHg4Nl9lbXVsYXRlX2N0eHQgKmN0eHQsCiAgICAgY29uc3Qgc3Ry
dWN0IHg4Nl9lbXVsYXRlX29wcyAqb3BzKQogewpAQCAtMTI1NSw3ICsxMjY5
LDcgQEAgbG9hZF9zZWcoCiAgICAgICAgIHJldHVybiBYODZFTVVMX1VOSEFO
RExFQUJMRTsKIAogICAgIGlmICggaW5fcHJvdG1vZGUoY3R4dCwgb3BzKSAp
Ci0gICAgICAgIHJldHVybiBwcm90bW9kZV9sb2FkX3NlZyhzZWcsIHNlbCwg
Y3R4dCwgb3BzKTsKKyAgICAgICAgcmV0dXJuIHByb3Rtb2RlX2xvYWRfc2Vn
KHNlZywgc2VsLCBpc19yZXQsIGN0eHQsIG9wcyk7CiAKICAgICByZXR1cm4g
cmVhbG1vZGVfbG9hZF9zZWcoc2VnLCBzZWwsIGN0eHQsIG9wcyk7CiB9CkBA
IC0xODUyLDcgKzE4NjYsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgaWYg
KCAocmMgPSByZWFkX3Vsb25nKHg4Nl9zZWdfc3MsIHNwX3Bvc3RfaW5jKG9w
X2J5dGVzKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZkc3Qu
dmFsLCBvcF9ieXRlcywgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAg
ICBnb3RvIGRvbmU7Ci0gICAgICAgIGlmICggKHJjID0gbG9hZF9zZWcoc3Jj
LnZhbCwgKHVpbnQxNl90KWRzdC52YWwsIGN0eHQsIG9wcykpICE9IDAgKQor
ICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHNyYy52YWwsIGRzdC52YWws
IDAsIGN0eHQsIG9wcykpICE9IDAgKQogICAgICAgICAgICAgcmV0dXJuIHJj
OwogICAgICAgICBicmVhazsKIApAQCAtMjIyMiw3ICsyMjM2LDcgQEAgeDg2
X2VtdWxhdGUoCiAgICAgICAgIGVudW0geDg2X3NlZ21lbnQgc2VnID0gZGVj
b2RlX3NlZ21lbnQobW9kcm1fcmVnKTsKICAgICAgICAgZ2VuZXJhdGVfZXhj
ZXB0aW9uX2lmKHNlZyA9PSBkZWNvZGVfc2VnbWVudF9mYWlsZWQsIEVYQ19V
RCwgLTEpOwogICAgICAgICBnZW5lcmF0ZV9leGNlcHRpb25faWYoc2VnID09
IHg4Nl9zZWdfY3MsIEVYQ19VRCwgLTEpOwotICAgICAgICBpZiAoIChyYyA9
IGxvYWRfc2VnKHNlZywgKHVpbnQxNl90KXNyYy52YWwsIGN0eHQsIG9wcykp
ICE9IDAgKQorICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHNlZywgc3Jj
LnZhbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAgICBnb3Rv
IGRvbmU7CiAgICAgICAgIGlmICggc2VnID09IHg4Nl9zZWdfc3MgKQogICAg
ICAgICAgICAgY3R4dC0+cmV0aXJlLmZsYWdzLm1vdl9zcyA9IDE7CkBAIC0y
MzAzLDcgKzIzMTcsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZfcmVncy5laXAsIG9wX2J5dGVzLCBjdHh0KSkg
KQogICAgICAgICAgICAgZ290byBkb25lOwogCi0gICAgICAgIGlmICggKHJj
ID0gbG9hZF9zZWcoeDg2X3NlZ19jcywgc2VsLCBjdHh0LCBvcHMpKSAhPSAw
ICkKKyAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4ODZfc2VnX2NzLCBz
ZWwsIDAsIGN0eHQsIG9wcykpICE9IDAgKQogICAgICAgICAgICAgZ290byBk
b25lOwogICAgICAgICBfcmVncy5laXAgPSBlaXA7CiAgICAgICAgIGJyZWFr
OwpAQCAtMjUyNiw3ICsyNTQwLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAg
IGlmICggKHJjID0gcmVhZF91bG9uZyhzcmMubWVtLnNlZywgc3JjLm1lbS5v
ZmYgKyBzcmMuYnl0ZXMsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmc2VsLCAyLCBjdHh0LCBvcHMpKSAhPSAwICkKICAgICAgICAgICAgIGdv
dG8gZG9uZTsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyhkc3QudmFs
LCAodWludDE2X3Qpc2VsLCBjdHh0LCBvcHMpKSAhPSAwICkKKyAgICAgICAg
aWYgKCAocmMgPSBsb2FkX3NlZyhkc3QudmFsLCBzZWwsIDAsIGN0eHQsIG9w
cykpICE9IDAgKQogICAgICAgICAgICAgZ290byBkb25lOwogICAgICAgICBk
c3QudmFsID0gc3JjLnZhbDsKICAgICAgICAgYnJlYWs7CkBAIC0yNjAwLDcg
KzI2MTQsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZkc3QudmFsLCBvcF9ieXRlcywgY3R4dCwgb3BzKSkgfHwK
ICAgICAgICAgICAgICAocmMgPSByZWFkX3Vsb25nKHg4Nl9zZWdfc3MsIHNw
X3Bvc3RfaW5jKG9wX2J5dGVzICsgb2Zmc2V0KSwKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZzcmMudmFsLCBvcF9ieXRlcywgY3R4dCwgb3Bz
KSkgfHwKLSAgICAgICAgICAgICAocmMgPSBsb2FkX3NlZyh4ODZfc2VnX2Nz
LCAodWludDE2X3Qpc3JjLnZhbCwgY3R4dCwgb3BzKSkgKQorICAgICAgICAg
ICAgIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNyYy52YWwsIDEsIGN0
eHQsIG9wcykpICkKICAgICAgICAgICAgIGdvdG8gZG9uZTsKICAgICAgICAg
X3JlZ3MuZWlwID0gZHN0LnZhbDsKICAgICAgICAgYnJlYWs7CkBAIC0yNjQ3
LDcgKzI2NjEsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgX3JlZ3MuZWZs
YWdzICY9IG1hc2s7CiAgICAgICAgIF9yZWdzLmVmbGFncyB8PSAodWludDMy
X3QpKGVmbGFncyAmIH5tYXNrKSB8IDB4MDI7CiAgICAgICAgIF9yZWdzLmVp
cCA9IGVpcDsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4ODZfc2Vn
X2NzLCAodWludDE2X3QpY3MsIGN0eHQsIG9wcykpICE9IDAgKQorICAgICAg
ICBpZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIGNzLCAxLCBjdHh0
LCBvcHMpKSAhPSAwICkKICAgICAgICAgICAgIGdvdG8gZG9uZTsKICAgICAg
ICAgYnJlYWs7CiAgICAgfQpAQCAtMzI3Nyw3ICszMjkxLDcgQEAgeDg2X2Vt
dWxhdGUoCiAgICAgICAgIGdlbmVyYXRlX2V4Y2VwdGlvbl9pZihtb2RlXzY0
Yml0KCksIEVYQ19VRCwgLTEpOwogICAgICAgICBlaXAgPSBpbnNuX2ZldGNo
X2J5dGVzKG9wX2J5dGVzKTsKICAgICAgICAgc2VsID0gaW5zbl9mZXRjaF90
eXBlKHVpbnQxNl90KTsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4
ODZfc2VnX2NzLCBzZWwsIGN0eHQsIG9wcykpICE9IDAgKQorICAgICAgICBp
ZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNlbCwgMCwgY3R4dCwg
b3BzKSkgIT0gMCApCiAgICAgICAgICAgICBnb3RvIGRvbmU7CiAgICAgICAg
IF9yZWdzLmVpcCA9IGVpcDsKICAgICAgICAgYnJlYWs7CkBAIC0zNTkwLDcg
KzM2MDQsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAgICAgICAg
Z290byBkb25lOwogICAgICAgICAgICAgfQogCi0gICAgICAgICAgICBpZiAo
IChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNlbCwgY3R4dCwgb3BzKSkg
IT0gMCApCisgICAgICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9z
ZWdfY3MsIHNlbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAg
ICAgICAgZ290byBkb25lOwogICAgICAgICAgICAgX3JlZ3MuZWlwID0gZHN0
LnZhbDsKIApAQCAtMzY3MSw3ICszNjg1LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIGdlbmVyYXRlX2V4Y2VwdGlvbl9pZighaW5fcHJvdG1vZGUoY3R4
dCwgb3BzKSwgRVhDX1VELCAtMSk7CiAgICAgICAgIGdlbmVyYXRlX2V4Y2Vw
dGlvbl9pZighbW9kZV9yaW5nMCgpLCBFWENfR1AsIDApOwogICAgICAgICBp
ZiAoIChyYyA9IGxvYWRfc2VnKChtb2RybV9yZWcgJiAxKSA/IHg4Nl9zZWdf
dHIgOiB4ODZfc2VnX2xkdHIsCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3JjLnZhbCwgY3R4dCwgb3BzKSkgIT0gMCApCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc3JjLnZhbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCAp
CiAgICAgICAgICAgICBnb3RvIGRvbmU7CiAgICAgICAgIGJyZWFrOwogCg==

--=separator
Content-Type: application/octet-stream; name="xsa110.patch"
Content-Disposition: attachment; filename="xsa110.patch"
Content-Transfer-Encoding: base64

eDg2ZW11bDogZW5mb3JjZSBwcml2aWxlZ2UgbGV2ZWwgcmVzdHJpY3Rpb25z
IHdoZW4gbG9hZGluZyBDUwoKUHJpdmlsZWdlIGxldmVsIGNoZWNrcyB3ZXJl
IGJhc2ljYWxseSBtaXNzaW5nIGZvciB0aGUgQ1MgY2FzZSwgdGhlCm9ubHkg
Y2hlY2sgdGhhdCB3YXMgZG9uZSAoUlBMID09IERQTCBmb3Igbm9uY29uZm9y
bWluZyBzZWdtZW50cykKd2FzIHNvbGVseSBjb3ZlcmluZyBhIHNpbmdsZSBz
cGVjaWFsIGNhc2UgKHJldHVybiB0byBub24tY29uZm9ybWluZwpzZWdtZW50
KS4KCkFkZGl0aW9uYWxseSBpbiBsb25nIG1vZGUgdGhlIEwgYml0IHNldCBy
ZXF1aXJlcyB0aGUgRCBiaXQgdG8gYmUgY2xlYXIsCmFzIHdhcyByZWNlbnRs
eSBwb2ludGVkIG91dCBmb3IgS1ZNIGJ5IE5hZGF2IEFtaXQKPG5hbWl0QGNz
LnRlY2huaW9uLmFjLmlsPi4KCkZpbmFsbHkgd2UgYWxzbyBuZWVkIHRvIGZv
cmNlIHRoZSBsb2FkZWQgc2VsZWN0b3IncyBSUEwgdG8gQ1BMIChhdApsZWFz
dCBhcyBsb25nIGFzIGxyZXQvcmV0ZiBlbXVsYXRpb24gZG9lc24ndCBzdXBw
b3J0IHByaXZpbGVnZSBsZXZlbApjaGFuZ2VzKS4KClRoaXMgaXMgWFNBLTEx
MC4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl
LmNvbT4KUmV2aWV3ZWQtYnk6IFRpbSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoK
LS0tIGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMK
KysrIGIveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMK
QEAgLTExMTksNyArMTExOSw3IEBAIHJlYWxtb2RlX2xvYWRfc2VnKAogc3Rh
dGljIGludAogcHJvdG1vZGVfbG9hZF9zZWcoCiAgICAgZW51bSB4ODZfc2Vn
bWVudCBzZWcsCi0gICAgdWludDE2X3Qgc2VsLAorICAgIHVpbnQxNl90IHNl
bCwgYm9vbF90IGlzX3JldCwKICAgICBzdHJ1Y3QgeDg2X2VtdWxhdGVfY3R4
dCAqY3R4dCwKICAgICBjb25zdCBzdHJ1Y3QgeDg2X2VtdWxhdGVfb3BzICpv
cHMpCiB7CkBAIC0xMTg1LDkgKzExODUsMjMgQEAgcHJvdG1vZGVfbG9hZF9z
ZWcoCiAgICAgICAgIC8qIENvZGUgc2VnbWVudD8gKi8KICAgICAgICAgaWYg
KCAhKGRlc2MuYiAmICgxdTw8MTEpKSApCiAgICAgICAgICAgICBnb3RvIHJh
aXNlX2V4bjsKLSAgICAgICAgLyogTm9uLWNvbmZvcm1pbmcgc2VnbWVudDog
Y2hlY2sgRFBMIGFnYWluc3QgUlBMLiAqLwotICAgICAgICBpZiAoICgoZGVz
Yy5iICYgKDZ1PDw5KSkgIT0gKDZ1PDw5KSkgJiYgKGRwbCAhPSBycGwpICkK
KyAgICAgICAgaWYgKCBpc19yZXQKKyAgICAgICAgICAgICA/IC8qCisgICAg
ICAgICAgICAgICAgKiBSZWFsbHkgcnBsIDwgY3BsLCBidXQgb3VyIHNvbGUg
Y2FsbGVyIGRvZXNuJ3QgaGFuZGxlCisgICAgICAgICAgICAgICAgKiBwcml2
aWxlZ2UgbGV2ZWwgY2hhbmdlcy4KKyAgICAgICAgICAgICAgICAqLworICAg
ICAgICAgICAgICAgcnBsICE9IGNwbCB8fCAoZGVzYy5iICYgKDEgPDwgMTAp
ID8gZHBsID4gcnBsIDogZHBsICE9IHJwbCkKKyAgICAgICAgICAgICA6IGRl
c2MuYiAmICgxIDw8IDEwKQorICAgICAgICAgICAgICAgLyogQ29uZm9ybWlu
ZyBzZWdtZW50OiBjaGVjayBEUEwgYWdhaW5zdCBDUEwuICovCisgICAgICAg
ICAgICAgICA/IGRwbCA+IGNwbAorICAgICAgICAgICAgICAgLyogTm9uLWNv
bmZvcm1pbmcgc2VnbWVudDogY2hlY2sgUlBMIGFuZCBEUEwgYWdhaW5zdCBD
UEwuICovCisgICAgICAgICAgICAgICA6IHJwbCA+IGNwbCB8fCBkcGwgIT0g
Y3BsICkKICAgICAgICAgICAgIGdvdG8gcmFpc2VfZXhuOworICAgICAgICAv
KiA2NC1iaXQgY29kZSBzZWdtZW50cyAoTCBiaXQgc2V0KSBtdXN0IGhhdmUg
RCBiaXQgY2xlYXIuICovCisgICAgICAgIGlmICggaW5fbG9uZ21vZGUoY3R4
dCwgb3BzKSAmJgorICAgICAgICAgICAgIChkZXNjLmIgJiAoMSA8PCAyMSkp
ICYmIChkZXNjLmIgJiAoMSA8PCAyMikpICkKKyAgICAgICAgICAgIGdvdG8g
cmFpc2VfZXhuOworICAgICAgICBzZWwgPSAoc2VsIF4gcnBsKSB8IGNwbDsK
ICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSB4ODZfc2VnX3NzOgogICAgICAg
ICAvKiBXcml0YWJsZSBkYXRhIHNlZ21lbnQ/ICovCkBAIC0xMjUyLDcgKzEy
NjYsNyBAQCBwcm90bW9kZV9sb2FkX3NlZygKIHN0YXRpYyBpbnQKIGxvYWRf
c2VnKAogICAgIGVudW0geDg2X3NlZ21lbnQgc2VnLAotICAgIHVpbnQxNl90
IHNlbCwKKyAgICB1aW50MTZfdCBzZWwsIGJvb2xfdCBpc19yZXQsCiAgICAg
c3RydWN0IHg4Nl9lbXVsYXRlX2N0eHQgKmN0eHQsCiAgICAgY29uc3Qgc3Ry
dWN0IHg4Nl9lbXVsYXRlX29wcyAqb3BzKQogewpAQCAtMTI2MSw3ICsxMjc1
LDcgQEAgbG9hZF9zZWcoCiAgICAgICAgIHJldHVybiBYODZFTVVMX1VOSEFO
RExFQUJMRTsKIAogICAgIGlmICggaW5fcHJvdG1vZGUoY3R4dCwgb3BzKSAp
Ci0gICAgICAgIHJldHVybiBwcm90bW9kZV9sb2FkX3NlZyhzZWcsIHNlbCwg
Y3R4dCwgb3BzKTsKKyAgICAgICAgcmV0dXJuIHByb3Rtb2RlX2xvYWRfc2Vn
KHNlZywgc2VsLCBpc19yZXQsIGN0eHQsIG9wcyk7CiAKICAgICByZXR1cm4g
cmVhbG1vZGVfbG9hZF9zZWcoc2VnLCBzZWwsIGN0eHQsIG9wcyk7CiB9CkBA
IC0yMDAzLDcgKzIwMTcsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgaWYg
KCAocmMgPSByZWFkX3Vsb25nKHg4Nl9zZWdfc3MsIHNwX3Bvc3RfaW5jKG9w
X2J5dGVzKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZkc3Qu
dmFsLCBvcF9ieXRlcywgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAg
ICBnb3RvIGRvbmU7Ci0gICAgICAgIGlmICggKHJjID0gbG9hZF9zZWcoc3Jj
LnZhbCwgKHVpbnQxNl90KWRzdC52YWwsIGN0eHQsIG9wcykpICE9IDAgKQor
ICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHNyYy52YWwsIGRzdC52YWws
IDAsIGN0eHQsIG9wcykpICE9IDAgKQogICAgICAgICAgICAgcmV0dXJuIHJj
OwogICAgICAgICBicmVhazsKIApAQCAtMjM1Nyw3ICsyMzcxLDcgQEAgeDg2
X2VtdWxhdGUoCiAgICAgICAgIGVudW0geDg2X3NlZ21lbnQgc2VnID0gZGVj
b2RlX3NlZ21lbnQobW9kcm1fcmVnKTsKICAgICAgICAgZ2VuZXJhdGVfZXhj
ZXB0aW9uX2lmKHNlZyA9PSBkZWNvZGVfc2VnbWVudF9mYWlsZWQsIEVYQ19V
RCwgLTEpOwogICAgICAgICBnZW5lcmF0ZV9leGNlcHRpb25faWYoc2VnID09
IHg4Nl9zZWdfY3MsIEVYQ19VRCwgLTEpOwotICAgICAgICBpZiAoIChyYyA9
IGxvYWRfc2VnKHNlZywgKHVpbnQxNl90KXNyYy52YWwsIGN0eHQsIG9wcykp
ICE9IDAgKQorICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHNlZywgc3Jj
LnZhbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAgICBnb3Rv
IGRvbmU7CiAgICAgICAgIGlmICggc2VnID09IHg4Nl9zZWdfc3MgKQogICAg
ICAgICAgICAgY3R4dC0+cmV0aXJlLmZsYWdzLm1vdl9zcyA9IDE7CkBAIC0y
NDM4LDcgKzI0NTIsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZfcmVncy5laXAsIG9wX2J5dGVzLCBjdHh0KSkg
KQogICAgICAgICAgICAgZ290byBkb25lOwogCi0gICAgICAgIGlmICggKHJj
ID0gbG9hZF9zZWcoeDg2X3NlZ19jcywgc2VsLCBjdHh0LCBvcHMpKSAhPSAw
ICkKKyAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4ODZfc2VnX2NzLCBz
ZWwsIDAsIGN0eHQsIG9wcykpICE9IDAgKQogICAgICAgICAgICAgZ290byBk
b25lOwogICAgICAgICBfcmVncy5laXAgPSBlaXA7CiAgICAgICAgIGJyZWFr
OwpAQCAtMjY2Miw3ICsyNjc2LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAg
IGlmICggKHJjID0gcmVhZF91bG9uZyhzcmMubWVtLnNlZywgc3JjLm1lbS5v
ZmYgKyBzcmMuYnl0ZXMsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmc2VsLCAyLCBjdHh0LCBvcHMpKSAhPSAwICkKICAgICAgICAgICAgIGdv
dG8gZG9uZTsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyhkc3QudmFs
LCAodWludDE2X3Qpc2VsLCBjdHh0LCBvcHMpKSAhPSAwICkKKyAgICAgICAg
aWYgKCAocmMgPSBsb2FkX3NlZyhkc3QudmFsLCBzZWwsIDAsIGN0eHQsIG9w
cykpICE9IDAgKQogICAgICAgICAgICAgZ290byBkb25lOwogICAgICAgICBk
c3QudmFsID0gc3JjLnZhbDsKICAgICAgICAgYnJlYWs7CkBAIC0yNzM2LDcg
KzI3NTAsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZkc3QudmFsLCBvcF9ieXRlcywgY3R4dCwgb3BzKSkgfHwK
ICAgICAgICAgICAgICAocmMgPSByZWFkX3Vsb25nKHg4Nl9zZWdfc3MsIHNw
X3Bvc3RfaW5jKG9wX2J5dGVzICsgb2Zmc2V0KSwKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZzcmMudmFsLCBvcF9ieXRlcywgY3R4dCwgb3Bz
KSkgfHwKLSAgICAgICAgICAgICAocmMgPSBsb2FkX3NlZyh4ODZfc2VnX2Nz
LCAodWludDE2X3Qpc3JjLnZhbCwgY3R4dCwgb3BzKSkgKQorICAgICAgICAg
ICAgIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNyYy52YWwsIDEsIGN0
eHQsIG9wcykpICkKICAgICAgICAgICAgIGdvdG8gZG9uZTsKICAgICAgICAg
X3JlZ3MuZWlwID0gZHN0LnZhbDsKICAgICAgICAgYnJlYWs7CkBAIC0yNzg1
LDcgKzI3OTksNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgX3JlZ3MuZWZs
YWdzICY9IG1hc2s7CiAgICAgICAgIF9yZWdzLmVmbGFncyB8PSAodWludDMy
X3QpKGVmbGFncyAmIH5tYXNrKSB8IDB4MDI7CiAgICAgICAgIF9yZWdzLmVp
cCA9IGVpcDsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4ODZfc2Vn
X2NzLCAodWludDE2X3QpY3MsIGN0eHQsIG9wcykpICE9IDAgKQorICAgICAg
ICBpZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIGNzLCAxLCBjdHh0
LCBvcHMpKSAhPSAwICkKICAgICAgICAgICAgIGdvdG8gZG9uZTsKICAgICAg
ICAgYnJlYWs7CiAgICAgfQpAQCAtMzQxNSw3ICszNDI5LDcgQEAgeDg2X2Vt
dWxhdGUoCiAgICAgICAgIGdlbmVyYXRlX2V4Y2VwdGlvbl9pZihtb2RlXzY0
Yml0KCksIEVYQ19VRCwgLTEpOwogICAgICAgICBlaXAgPSBpbnNuX2ZldGNo
X2J5dGVzKG9wX2J5dGVzKTsKICAgICAgICAgc2VsID0gaW5zbl9mZXRjaF90
eXBlKHVpbnQxNl90KTsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4
ODZfc2VnX2NzLCBzZWwsIGN0eHQsIG9wcykpICE9IDAgKQorICAgICAgICBp
ZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNlbCwgMCwgY3R4dCwg
b3BzKSkgIT0gMCApCiAgICAgICAgICAgICBnb3RvIGRvbmU7CiAgICAgICAg
IF9yZWdzLmVpcCA9IGVpcDsKICAgICAgICAgYnJlYWs7CkBAIC0zNzE0LDcg
KzM3MjgsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAgICAgICAg
Z290byBkb25lOwogICAgICAgICAgICAgfQogCi0gICAgICAgICAgICBpZiAo
IChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNlbCwgY3R4dCwgb3BzKSkg
IT0gMCApCisgICAgICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9z
ZWdfY3MsIHNlbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAg
ICAgICAgZ290byBkb25lOwogICAgICAgICAgICAgX3JlZ3MuZWlwID0gc3Jj
LnZhbDsKIApAQCAtMzc4MSw3ICszNzk1LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIGdlbmVyYXRlX2V4Y2VwdGlvbl9pZighaW5fcHJvdG1vZGUoY3R4
dCwgb3BzKSwgRVhDX1VELCAtMSk7CiAgICAgICAgIGdlbmVyYXRlX2V4Y2Vw
dGlvbl9pZighbW9kZV9yaW5nMCgpLCBFWENfR1AsIDApOwogICAgICAgICBp
ZiAoIChyYyA9IGxvYWRfc2VnKChtb2RybV9yZWcgJiAxKSA/IHg4Nl9zZWdf
dHIgOiB4ODZfc2VnX2xkdHIsCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3JjLnZhbCwgY3R4dCwgb3BzKSkgIT0gMCApCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc3JjLnZhbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCAp
CiAgICAgICAgICAgICBnb3RvIGRvbmU7CiAgICAgICAgIGJyZWFrOwogCg==

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Tue Nov 18 12:24:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 12: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 1Xqhpz-0006RT-Gq; Tue, 18 Nov 2014 12:24:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xqhpw-0006Qe-5w; Tue, 18 Nov 2014 12:24:48 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	46/DC-02696-F8A3B645; Tue, 18 Nov 2014 12:24:47 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416313485!13298519!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10912 invoked from network); 18 Nov 2014 12:24:46 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Nov 2014 12:24:46 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XqhpC-0000LH-Km; Tue, 18 Nov 2014 12:24:05 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XqhpC-0003RN-5U; Tue, 18 Nov 2014 12:24:02 +0000
Date: Tue, 18 Nov 2014 12:24:02 +0000
Message-Id: <E1XqhpC-0003RN-5U@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 109 (CVE-2014-8594) -
 Insufficient restrictions on certain MMU update hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

             Xen Security Advisory CVE-2014-8594 / XSA-109
                               version 3

        Insufficient restrictions on certain MMU update hypercalls

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

MMU update operations targeting page tables are intended to be used on
PV guests only. The lack of a respective check made it possible for
such operations to access certain function pointers which remain NULL
when the target guest is using Hardware Assisted Paging (HAP).

IMPACT
======

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.

Only PV domains with privilege over other guests can exploit this
vulnerability; and only when those other guests are HVM using HAP, or
PVH.  The vulnerability is therefore exposed to PV domains providing
hardware emulation services to HVM guests.

VULNERABLE SYSTEMS
==================

Xen 4.0 and onward are vulnerable.

Only x86 systems are vulnerable.  ARM systems are not vulnerable.

The vulnerability is only exposed to PV service domains for HVM or
PVH guests which have privilege over the guest.  In a usual
configuration that means only device model emulators (qemu-dm).

In the case of HVM guests whose device model is running in an
unrestricted dom0 process, qemu-dm already has the ability to cause
problems for the whole system.  So in that case the vulnerability is
not applicable.

The situation is more subtle for an HVM guest with a stub qemu-dm.
That is, where the device model runs in a separate domain (in the case
of xl, as requested by "device_model_stubdomain_override=1" in the xl
domain configuration file).  The same applies with a qemu-dm in a dom0
process subjected to some kind kernel-based process privilege
limitation (eg the chroot technique as found in some versions of
XCP/XenServer).

In those latter situations this issue means that the extra isolation
does not provide as good a defence (against denial of service) as
intended.  That is the essence of this vulnerability.

However, the security is still better than with a qemu-dm running as
an unrestricted dom0 process.  Therefore users with these
configurations should not switch to an unrestricted dom0 qemu-dm.

Finally, in a radically disaggregated system: where the HVM or PVH
service domain software (probably, the device model domain image in the
HVM case) is not always supplied by the host administrator, a malicious
service domain administrator can exercise this vulnerability.

MITIGATION
==========

Running only PV guests or HVM guests with shadow paging enabled will
avoid this issue.

In a radically disaggregated system, restricting HVM service domains
to software images approved by the host administrator will avoid the
vulnerability.

CREDITS
=======

This issue was discovered by Roger Pau Monné of Citrix and Jan Beulich
of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa109.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x
xsa109-4.2.patch    Xen 4.2.x

$ sha256sum xsa109*.patch
759d1b8cb8c17e53d17ad045ab89c5aaf52cb85fd93eef07e7acbe230365c56d  xsa109-4.2.patch
729b87c2b9979fbda47c96e934db6fcfaeb10e07b4cfd66bb1e9f746a908576b  xsa109.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUazogAAoJEIP+FMlX6CvZ5NQH/25lTqtBGu5Xt0JwHnLenfv0
z0gVJ5o8YB6aqzV+GHWei0QV/PtCLteykm/K8LJK4my9OtDqI/WPzusyrGB6aNhD
xCQUhRF5/j2c++u4UCBitibttSwKK/CCrswBMWZYqEI/1fJazVw3huyyFv56Wt+K
32geEcIUnWs6lJD+z97W8LPPNLoaF/m6uSh4I2LrT3uBnvEFq5oGgzdWNtEKkSGC
fAuga2m1NhfbCsMD6JSv9/EDSKHTiByZ5Z/zicWrButHfRp4fmGO/pPMwPFkERs1
T/FX/UAfnvisS1SjgMwqufWlzIka5JDzi/Nc5Utgcvo9+9EsI1PCJDzYTJpOSa8=
=yb1z
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa109-4.2.patch"
Content-Disposition: attachment; filename="xsa109-4.2.patch"
Content-Transfer-Encoding: base64

eDg2OiBkb24ndCBhbGxvdyBwYWdlIHRhYmxlIHVwZGF0ZXMgb24gbm9uLVBW
IHBhZ2UgdGFibGVzIGluIGRvX21tdV91cGRhdGUoKQoKcGFnaW5nX3dyaXRl
X2d1ZXN0X2VudHJ5KCkgYW5kIHBhZ2luZ19jbXB4Y2hnX2d1ZXN0X2VudHJ5
KCkgYXJlbid0CmNvbnNpc3RlbnRseSBzdXBwb3J0ZWQgZm9yIG5vbi1QViBn
dWVzdHMgKHRoZXknZCBkZXJlZiBOVUxMIGZvciBQVkggb3IKbm9uLUhBUCBI
Vk0gb25lcykuIERvbid0IGFsbG93IHJlc3BlY3RpdmUgTU1VXyogb3BlcmF0
aW9ucyBvbiB0aGUKcGFnZSB0YWJsZXMgb2Ygc3VjaCBkb21haW5zLgoKVGhp
cyBpcyBYU0EtMTA5LgoKU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpi
ZXVsaWNoQHN1c2UuY29tPgpBY2tlZC1ieTogVGltIERlZWdhbiA8dGltQHhl
bi5vcmc+CgotLS0gYS94ZW4vYXJjaC94ODYvbW0uYworKysgYi94ZW4vYXJj
aC94ODYvbW0uYwpAQCAtMzgwMCw2ICszODAwLDEwIEBAIGxvbmcgZG9fbW11
X3VwZGF0ZSgKICAgICAgICAgewogICAgICAgICAgICAgcDJtX3R5cGVfdCBw
Mm10OwogCisgICAgICAgICAgICByYyA9IC1FT1BOT1RTVVBQOworICAgICAg
ICAgICAgaWYgKCB1bmxpa2VseShwYWdpbmdfbW9kZV9yZWZjb3VudHMocHRf
b3duZXIpKSApCisgICAgICAgICAgICAgICAgYnJlYWs7CisKICAgICAgICAg
ICAgIHJjID0geHNtX21tdV9ub3JtYWxfdXBkYXRlKGQsIHB0X293bmVyLCBw
Z19vd25lciwgcmVxLnZhbCk7CiAgICAgICAgICAgICBpZiAoIHJjICkKICAg
ICAgICAgICAgICAgICBicmVhazsK

--=separator
Content-Type: application/octet-stream; name="xsa109.patch"
Content-Disposition: attachment; filename="xsa109.patch"
Content-Transfer-Encoding: base64

eDg2OiBkb24ndCBhbGxvdyBwYWdlIHRhYmxlIHVwZGF0ZXMgb24gbm9uLVBW
IHBhZ2UgdGFibGVzIGluIGRvX21tdV91cGRhdGUoKQoKcGFnaW5nX3dyaXRl
X2d1ZXN0X2VudHJ5KCkgYW5kIHBhZ2luZ19jbXB4Y2hnX2d1ZXN0X2VudHJ5
KCkgYXJlbid0CmNvbnNpc3RlbnRseSBzdXBwb3J0ZWQgZm9yIG5vbi1QViBn
dWVzdHMgKHRoZXknZCBkZXJlZiBOVUxMIGZvciBQVkggb3IKbm9uLUhBUCBI
Vk0gb25lcykuIERvbid0IGFsbG93IHJlc3BlY3RpdmUgTU1VXyogb3BlcmF0
aW9ucyBvbiB0aGUKcGFnZSB0YWJsZXMgb2Ygc3VjaCBkb21haW5zLgoKVGhp
cyBpcyBYU0EtMTA5LgoKU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpi
ZXVsaWNoQHN1c2UuY29tPgpBY2tlZC1ieTogVGltIERlZWdhbiA8dGltQHhl
bi5vcmc+CgotLS0gYS94ZW4vYXJjaC94ODYvbW0uYworKysgYi94ZW4vYXJj
aC94ODYvbW0uYwpAQCAtMzQ5Myw2ICszNDkzLDEwIEBAIGxvbmcgZG9fbW11
X3VwZGF0ZSgKICAgICAgICAgewogICAgICAgICAgICAgcDJtX3R5cGVfdCBw
Mm10OwogCisgICAgICAgICAgICByYyA9IC1FT1BOT1RTVVBQOworICAgICAg
ICAgICAgaWYgKCB1bmxpa2VseShwYWdpbmdfbW9kZV9yZWZjb3VudHMocHRf
b3duZXIpKSApCisgICAgICAgICAgICAgICAgYnJlYWs7CisKICAgICAgICAg
ICAgIHhzbV9uZWVkZWQgfD0gWFNNX01NVV9OT1JNQUxfVVBEQVRFOwogICAg
ICAgICAgICAgaWYgKCBnZXRfcHRlX2ZsYWdzKHJlcS52YWwpICYgX1BBR0Vf
UFJFU0VOVCApCiAgICAgICAgICAgICB7Cg==

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Tue Nov 18 12:24:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 12: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 1Xqhpz-0006Rb-TK; Tue, 18 Nov 2014 12:24:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xqhpw-0006Qf-7P; Tue, 18 Nov 2014 12:24:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4E/26-25276-F8A3B645; Tue, 18 Nov 2014 12:24:47 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416313485!13552852!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29542 invoked from network); 18 Nov 2014 12:24:46 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Nov 2014 12:24:46 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XqhpL-0000LT-DX; Tue, 18 Nov 2014 12:24:11 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XqhpL-0003SX-7Z; Tue, 18 Nov 2014 12:24:11 +0000
Date: Tue, 18 Nov 2014 12:24:11 +0000
Message-Id: <E1XqhpL-0003SX-7Z@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 110 (CVE-2014-8595) - Missing
 privilege level checks in x86 emulation of far branches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2014-8595 / XSA-110
                              version 3

    Missing privilege level checks in x86 emulation of far branches

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

The emulation of far branch instructions (CALL, JMP, and RETF in Intel
assembly syntax, LCALL, LJMP, and LRET in AT&T assembly syntax)
incompletely performs privilege checks.

However these instructions are not usually handled by the emulator.
Exceptions to this are
- - when a memory operand lives in (emulated or passed through) memory
  mapped IO space,
- - in the case of guests running in 32-bit PAE mode, when such an
  instruction is (in execution flow) within four instructions of one
  doing a page table update,
- - when an Invalid Opcode exception gets raised by a guest instruction,
  and the guest then (likely maliciously) alters the instruction to
  become one of the affected ones,
- - when the guest is in real mode (in which case there are no privilege
  checks anyway).

IMPACT
======

Malicious HVM guest user mode code may be able to elevate its
privileges to guest supervisor mode, or to crash the guest.

VULNERABLE SYSTEMS
==================

Xen 3.2.1 and onward are vulnerable on x86 systems.

ARM systems are not vulnerable.

Only user processes in x86 HVM guests can take advantage of this
vulnerability.

MITIGATION
==========

Running only PV guests will avoid this issue.

There is no mitigation available for HVM guests.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa110-unstable.patch        xen-unstable, Xen 4.4.x
xsa110-4.3-and-4.2.patch     Xen 4.3.x, Xen 4.2.x

$ sha256sum xsa110*.patch
a114ba586d18125b368112527a077abfe309826ad47aca8cc80ba4549c5f9ae2  xsa110-4.3-and-4.2.patch
eac4691848dcd093903e0a0f5fd7ab15be15d0f10b98575379911e91e5dcbd70  xsa110.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUazojAAoJEIP+FMlX6CvZF18H/1/G49MGk6/Fq6CtpvoEvQsl
u7Q0UHoMuwqN119fRKJOorAh+MPKWDaPBjZoNmfJxIKEHD5tpA1Kr97y67Ye/dtz
UfXxQPiIYpOe/Z59E3erKGDyzC5TLlPfa7fZBvZdeStIWsC+d2pUWDTRBioDHBGZ
IeNnXkrLuhLrjGOs9a4ZNdP/jTFkJQ7vKJXF8nFhcEpK8XZx9D8e2xExTWZ2BJ/N
u6KbWgMAf01M10hcQze99Wm3Fuva/HkVhiza8Rj5cgsV9SD4ZrQMhH9Mm86/YG52
AEwT6j8KWd83zZz8WZjFS30edZ4/eIXW+2e3KuaUFKBiei88tlF6CYWq6upS/5U=
=u7Zi
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa110-4.3-and-4.2.patch"
Content-Disposition: attachment; filename="xsa110-4.3-and-4.2.patch"
Content-Transfer-Encoding: base64

eDg2ZW11bDogZW5mb3JjZSBwcml2aWxlZ2UgbGV2ZWwgcmVzdHJpY3Rpb25z
IHdoZW4gbG9hZGluZyBDUwoKUHJpdmlsZWdlIGxldmVsIGNoZWNrcyB3ZXJl
IGJhc2ljYWxseSBtaXNzaW5nIGZvciB0aGUgQ1MgY2FzZSwgdGhlCm9ubHkg
Y2hlY2sgdGhhdCB3YXMgZG9uZSAoUlBMID09IERQTCBmb3Igbm9uY29uZm9y
bWluZyBzZWdtZW50cykKd2FzIHNvbGVseSBjb3ZlcmluZyBhIHNpbmdsZSBz
cGVjaWFsIGNhc2UgKHJldHVybiB0byBub24tY29uZm9ybWluZwpzZWdtZW50
KS4KCkFkZGl0aW9uYWxseSBpbiBsb25nIG1vZGUgdGhlIEwgYml0IHNldCBy
ZXF1aXJlcyB0aGUgRCBiaXQgdG8gYmUgY2xlYXIsCmFzIHdhcyByZWNlbnRs
eSBwb2ludGVkIG91dCBmb3IgS1ZNIGJ5IE5hZGF2IEFtaXQKPG5hbWl0QGNz
LnRlY2huaW9uLmFjLmlsPi4KCkZpbmFsbHkgd2UgYWxzbyBuZWVkIHRvIGZv
cmNlIHRoZSBsb2FkZWQgc2VsZWN0b3IncyBSUEwgdG8gQ1BMIChhdApsZWFz
dCBhcyBsb25nIGFzIGxyZXQvcmV0ZiBlbXVsYXRpb24gZG9lc24ndCBzdXBw
b3J0IHByaXZpbGVnZSBsZXZlbApjaGFuZ2VzKS4KClRoaXMgaXMgWFNBLTEx
MC4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl
LmNvbT4KUmV2aWV3ZWQtYnk6IFRpbSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoK
LS0tIGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMK
KysrIGIveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMK
QEAgLTExMDcsNyArMTEwNyw3IEBAIHJlYWxtb2RlX2xvYWRfc2VnKAogc3Rh
dGljIGludAogcHJvdG1vZGVfbG9hZF9zZWcoCiAgICAgZW51bSB4ODZfc2Vn
bWVudCBzZWcsCi0gICAgdWludDE2X3Qgc2VsLAorICAgIHVpbnQxNl90IHNl
bCwgYm9vbF90IGlzX3JldCwKICAgICBzdHJ1Y3QgeDg2X2VtdWxhdGVfY3R4
dCAqY3R4dCwKICAgICBjb25zdCBzdHJ1Y3QgeDg2X2VtdWxhdGVfb3BzICpv
cHMpCiB7CkBAIC0xMTc5LDkgKzExNzksMjMgQEAgcHJvdG1vZGVfbG9hZF9z
ZWcoCiAgICAgICAgIC8qIENvZGUgc2VnbWVudD8gKi8KICAgICAgICAgaWYg
KCAhKGRlc2MuYiAmICgxdTw8MTEpKSApCiAgICAgICAgICAgICBnb3RvIHJh
aXNlX2V4bjsKLSAgICAgICAgLyogTm9uLWNvbmZvcm1pbmcgc2VnbWVudDog
Y2hlY2sgRFBMIGFnYWluc3QgUlBMLiAqLwotICAgICAgICBpZiAoICgoZGVz
Yy5iICYgKDZ1PDw5KSkgIT0gKDZ1PDw5KSkgJiYgKGRwbCAhPSBycGwpICkK
KyAgICAgICAgaWYgKCBpc19yZXQKKyAgICAgICAgICAgICA/IC8qCisgICAg
ICAgICAgICAgICAgKiBSZWFsbHkgcnBsIDwgY3BsLCBidXQgb3VyIHNvbGUg
Y2FsbGVyIGRvZXNuJ3QgaGFuZGxlCisgICAgICAgICAgICAgICAgKiBwcml2
aWxlZ2UgbGV2ZWwgY2hhbmdlcy4KKyAgICAgICAgICAgICAgICAqLworICAg
ICAgICAgICAgICAgcnBsICE9IGNwbCB8fCAoZGVzYy5iICYgKDEgPDwgMTAp
ID8gZHBsID4gcnBsIDogZHBsICE9IHJwbCkKKyAgICAgICAgICAgICA6IGRl
c2MuYiAmICgxIDw8IDEwKQorICAgICAgICAgICAgICAgLyogQ29uZm9ybWlu
ZyBzZWdtZW50OiBjaGVjayBEUEwgYWdhaW5zdCBDUEwuICovCisgICAgICAg
ICAgICAgICA/IGRwbCA+IGNwbAorICAgICAgICAgICAgICAgLyogTm9uLWNv
bmZvcm1pbmcgc2VnbWVudDogY2hlY2sgUlBMIGFuZCBEUEwgYWdhaW5zdCBD
UEwuICovCisgICAgICAgICAgICAgICA6IHJwbCA+IGNwbCB8fCBkcGwgIT0g
Y3BsICkKICAgICAgICAgICAgIGdvdG8gcmFpc2VfZXhuOworICAgICAgICAv
KiA2NC1iaXQgY29kZSBzZWdtZW50cyAoTCBiaXQgc2V0KSBtdXN0IGhhdmUg
RCBiaXQgY2xlYXIuICovCisgICAgICAgIGlmICggaW5fbG9uZ21vZGUoY3R4
dCwgb3BzKSAmJgorICAgICAgICAgICAgIChkZXNjLmIgJiAoMSA8PCAyMSkp
ICYmIChkZXNjLmIgJiAoMSA8PCAyMikpICkKKyAgICAgICAgICAgIGdvdG8g
cmFpc2VfZXhuOworICAgICAgICBzZWwgPSAoc2VsIF4gcnBsKSB8IGNwbDsK
ICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSB4ODZfc2VnX3NzOgogICAgICAg
ICAvKiBXcml0YWJsZSBkYXRhIHNlZ21lbnQ/ICovCkBAIC0xMjQ2LDcgKzEy
NjAsNyBAQCBwcm90bW9kZV9sb2FkX3NlZygKIHN0YXRpYyBpbnQKIGxvYWRf
c2VnKAogICAgIGVudW0geDg2X3NlZ21lbnQgc2VnLAotICAgIHVpbnQxNl90
IHNlbCwKKyAgICB1aW50MTZfdCBzZWwsIGJvb2xfdCBpc19yZXQsCiAgICAg
c3RydWN0IHg4Nl9lbXVsYXRlX2N0eHQgKmN0eHQsCiAgICAgY29uc3Qgc3Ry
dWN0IHg4Nl9lbXVsYXRlX29wcyAqb3BzKQogewpAQCAtMTI1NSw3ICsxMjY5
LDcgQEAgbG9hZF9zZWcoCiAgICAgICAgIHJldHVybiBYODZFTVVMX1VOSEFO
RExFQUJMRTsKIAogICAgIGlmICggaW5fcHJvdG1vZGUoY3R4dCwgb3BzKSAp
Ci0gICAgICAgIHJldHVybiBwcm90bW9kZV9sb2FkX3NlZyhzZWcsIHNlbCwg
Y3R4dCwgb3BzKTsKKyAgICAgICAgcmV0dXJuIHByb3Rtb2RlX2xvYWRfc2Vn
KHNlZywgc2VsLCBpc19yZXQsIGN0eHQsIG9wcyk7CiAKICAgICByZXR1cm4g
cmVhbG1vZGVfbG9hZF9zZWcoc2VnLCBzZWwsIGN0eHQsIG9wcyk7CiB9CkBA
IC0xODUyLDcgKzE4NjYsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgaWYg
KCAocmMgPSByZWFkX3Vsb25nKHg4Nl9zZWdfc3MsIHNwX3Bvc3RfaW5jKG9w
X2J5dGVzKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZkc3Qu
dmFsLCBvcF9ieXRlcywgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAg
ICBnb3RvIGRvbmU7Ci0gICAgICAgIGlmICggKHJjID0gbG9hZF9zZWcoc3Jj
LnZhbCwgKHVpbnQxNl90KWRzdC52YWwsIGN0eHQsIG9wcykpICE9IDAgKQor
ICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHNyYy52YWwsIGRzdC52YWws
IDAsIGN0eHQsIG9wcykpICE9IDAgKQogICAgICAgICAgICAgcmV0dXJuIHJj
OwogICAgICAgICBicmVhazsKIApAQCAtMjIyMiw3ICsyMjM2LDcgQEAgeDg2
X2VtdWxhdGUoCiAgICAgICAgIGVudW0geDg2X3NlZ21lbnQgc2VnID0gZGVj
b2RlX3NlZ21lbnQobW9kcm1fcmVnKTsKICAgICAgICAgZ2VuZXJhdGVfZXhj
ZXB0aW9uX2lmKHNlZyA9PSBkZWNvZGVfc2VnbWVudF9mYWlsZWQsIEVYQ19V
RCwgLTEpOwogICAgICAgICBnZW5lcmF0ZV9leGNlcHRpb25faWYoc2VnID09
IHg4Nl9zZWdfY3MsIEVYQ19VRCwgLTEpOwotICAgICAgICBpZiAoIChyYyA9
IGxvYWRfc2VnKHNlZywgKHVpbnQxNl90KXNyYy52YWwsIGN0eHQsIG9wcykp
ICE9IDAgKQorICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHNlZywgc3Jj
LnZhbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAgICBnb3Rv
IGRvbmU7CiAgICAgICAgIGlmICggc2VnID09IHg4Nl9zZWdfc3MgKQogICAg
ICAgICAgICAgY3R4dC0+cmV0aXJlLmZsYWdzLm1vdl9zcyA9IDE7CkBAIC0y
MzAzLDcgKzIzMTcsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZfcmVncy5laXAsIG9wX2J5dGVzLCBjdHh0KSkg
KQogICAgICAgICAgICAgZ290byBkb25lOwogCi0gICAgICAgIGlmICggKHJj
ID0gbG9hZF9zZWcoeDg2X3NlZ19jcywgc2VsLCBjdHh0LCBvcHMpKSAhPSAw
ICkKKyAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4ODZfc2VnX2NzLCBz
ZWwsIDAsIGN0eHQsIG9wcykpICE9IDAgKQogICAgICAgICAgICAgZ290byBk
b25lOwogICAgICAgICBfcmVncy5laXAgPSBlaXA7CiAgICAgICAgIGJyZWFr
OwpAQCAtMjUyNiw3ICsyNTQwLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAg
IGlmICggKHJjID0gcmVhZF91bG9uZyhzcmMubWVtLnNlZywgc3JjLm1lbS5v
ZmYgKyBzcmMuYnl0ZXMsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmc2VsLCAyLCBjdHh0LCBvcHMpKSAhPSAwICkKICAgICAgICAgICAgIGdv
dG8gZG9uZTsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyhkc3QudmFs
LCAodWludDE2X3Qpc2VsLCBjdHh0LCBvcHMpKSAhPSAwICkKKyAgICAgICAg
aWYgKCAocmMgPSBsb2FkX3NlZyhkc3QudmFsLCBzZWwsIDAsIGN0eHQsIG9w
cykpICE9IDAgKQogICAgICAgICAgICAgZ290byBkb25lOwogICAgICAgICBk
c3QudmFsID0gc3JjLnZhbDsKICAgICAgICAgYnJlYWs7CkBAIC0yNjAwLDcg
KzI2MTQsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZkc3QudmFsLCBvcF9ieXRlcywgY3R4dCwgb3BzKSkgfHwK
ICAgICAgICAgICAgICAocmMgPSByZWFkX3Vsb25nKHg4Nl9zZWdfc3MsIHNw
X3Bvc3RfaW5jKG9wX2J5dGVzICsgb2Zmc2V0KSwKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZzcmMudmFsLCBvcF9ieXRlcywgY3R4dCwgb3Bz
KSkgfHwKLSAgICAgICAgICAgICAocmMgPSBsb2FkX3NlZyh4ODZfc2VnX2Nz
LCAodWludDE2X3Qpc3JjLnZhbCwgY3R4dCwgb3BzKSkgKQorICAgICAgICAg
ICAgIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNyYy52YWwsIDEsIGN0
eHQsIG9wcykpICkKICAgICAgICAgICAgIGdvdG8gZG9uZTsKICAgICAgICAg
X3JlZ3MuZWlwID0gZHN0LnZhbDsKICAgICAgICAgYnJlYWs7CkBAIC0yNjQ3
LDcgKzI2NjEsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgX3JlZ3MuZWZs
YWdzICY9IG1hc2s7CiAgICAgICAgIF9yZWdzLmVmbGFncyB8PSAodWludDMy
X3QpKGVmbGFncyAmIH5tYXNrKSB8IDB4MDI7CiAgICAgICAgIF9yZWdzLmVp
cCA9IGVpcDsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4ODZfc2Vn
X2NzLCAodWludDE2X3QpY3MsIGN0eHQsIG9wcykpICE9IDAgKQorICAgICAg
ICBpZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIGNzLCAxLCBjdHh0
LCBvcHMpKSAhPSAwICkKICAgICAgICAgICAgIGdvdG8gZG9uZTsKICAgICAg
ICAgYnJlYWs7CiAgICAgfQpAQCAtMzI3Nyw3ICszMjkxLDcgQEAgeDg2X2Vt
dWxhdGUoCiAgICAgICAgIGdlbmVyYXRlX2V4Y2VwdGlvbl9pZihtb2RlXzY0
Yml0KCksIEVYQ19VRCwgLTEpOwogICAgICAgICBlaXAgPSBpbnNuX2ZldGNo
X2J5dGVzKG9wX2J5dGVzKTsKICAgICAgICAgc2VsID0gaW5zbl9mZXRjaF90
eXBlKHVpbnQxNl90KTsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4
ODZfc2VnX2NzLCBzZWwsIGN0eHQsIG9wcykpICE9IDAgKQorICAgICAgICBp
ZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNlbCwgMCwgY3R4dCwg
b3BzKSkgIT0gMCApCiAgICAgICAgICAgICBnb3RvIGRvbmU7CiAgICAgICAg
IF9yZWdzLmVpcCA9IGVpcDsKICAgICAgICAgYnJlYWs7CkBAIC0zNTkwLDcg
KzM2MDQsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAgICAgICAg
Z290byBkb25lOwogICAgICAgICAgICAgfQogCi0gICAgICAgICAgICBpZiAo
IChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNlbCwgY3R4dCwgb3BzKSkg
IT0gMCApCisgICAgICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9z
ZWdfY3MsIHNlbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAg
ICAgICAgZ290byBkb25lOwogICAgICAgICAgICAgX3JlZ3MuZWlwID0gZHN0
LnZhbDsKIApAQCAtMzY3MSw3ICszNjg1LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIGdlbmVyYXRlX2V4Y2VwdGlvbl9pZighaW5fcHJvdG1vZGUoY3R4
dCwgb3BzKSwgRVhDX1VELCAtMSk7CiAgICAgICAgIGdlbmVyYXRlX2V4Y2Vw
dGlvbl9pZighbW9kZV9yaW5nMCgpLCBFWENfR1AsIDApOwogICAgICAgICBp
ZiAoIChyYyA9IGxvYWRfc2VnKChtb2RybV9yZWcgJiAxKSA/IHg4Nl9zZWdf
dHIgOiB4ODZfc2VnX2xkdHIsCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3JjLnZhbCwgY3R4dCwgb3BzKSkgIT0gMCApCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc3JjLnZhbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCAp
CiAgICAgICAgICAgICBnb3RvIGRvbmU7CiAgICAgICAgIGJyZWFrOwogCg==

--=separator
Content-Type: application/octet-stream; name="xsa110.patch"
Content-Disposition: attachment; filename="xsa110.patch"
Content-Transfer-Encoding: base64

eDg2ZW11bDogZW5mb3JjZSBwcml2aWxlZ2UgbGV2ZWwgcmVzdHJpY3Rpb25z
IHdoZW4gbG9hZGluZyBDUwoKUHJpdmlsZWdlIGxldmVsIGNoZWNrcyB3ZXJl
IGJhc2ljYWxseSBtaXNzaW5nIGZvciB0aGUgQ1MgY2FzZSwgdGhlCm9ubHkg
Y2hlY2sgdGhhdCB3YXMgZG9uZSAoUlBMID09IERQTCBmb3Igbm9uY29uZm9y
bWluZyBzZWdtZW50cykKd2FzIHNvbGVseSBjb3ZlcmluZyBhIHNpbmdsZSBz
cGVjaWFsIGNhc2UgKHJldHVybiB0byBub24tY29uZm9ybWluZwpzZWdtZW50
KS4KCkFkZGl0aW9uYWxseSBpbiBsb25nIG1vZGUgdGhlIEwgYml0IHNldCBy
ZXF1aXJlcyB0aGUgRCBiaXQgdG8gYmUgY2xlYXIsCmFzIHdhcyByZWNlbnRs
eSBwb2ludGVkIG91dCBmb3IgS1ZNIGJ5IE5hZGF2IEFtaXQKPG5hbWl0QGNz
LnRlY2huaW9uLmFjLmlsPi4KCkZpbmFsbHkgd2UgYWxzbyBuZWVkIHRvIGZv
cmNlIHRoZSBsb2FkZWQgc2VsZWN0b3IncyBSUEwgdG8gQ1BMIChhdApsZWFz
dCBhcyBsb25nIGFzIGxyZXQvcmV0ZiBlbXVsYXRpb24gZG9lc24ndCBzdXBw
b3J0IHByaXZpbGVnZSBsZXZlbApjaGFuZ2VzKS4KClRoaXMgaXMgWFNBLTEx
MC4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl
LmNvbT4KUmV2aWV3ZWQtYnk6IFRpbSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoK
LS0tIGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMK
KysrIGIveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMK
QEAgLTExMTksNyArMTExOSw3IEBAIHJlYWxtb2RlX2xvYWRfc2VnKAogc3Rh
dGljIGludAogcHJvdG1vZGVfbG9hZF9zZWcoCiAgICAgZW51bSB4ODZfc2Vn
bWVudCBzZWcsCi0gICAgdWludDE2X3Qgc2VsLAorICAgIHVpbnQxNl90IHNl
bCwgYm9vbF90IGlzX3JldCwKICAgICBzdHJ1Y3QgeDg2X2VtdWxhdGVfY3R4
dCAqY3R4dCwKICAgICBjb25zdCBzdHJ1Y3QgeDg2X2VtdWxhdGVfb3BzICpv
cHMpCiB7CkBAIC0xMTg1LDkgKzExODUsMjMgQEAgcHJvdG1vZGVfbG9hZF9z
ZWcoCiAgICAgICAgIC8qIENvZGUgc2VnbWVudD8gKi8KICAgICAgICAgaWYg
KCAhKGRlc2MuYiAmICgxdTw8MTEpKSApCiAgICAgICAgICAgICBnb3RvIHJh
aXNlX2V4bjsKLSAgICAgICAgLyogTm9uLWNvbmZvcm1pbmcgc2VnbWVudDog
Y2hlY2sgRFBMIGFnYWluc3QgUlBMLiAqLwotICAgICAgICBpZiAoICgoZGVz
Yy5iICYgKDZ1PDw5KSkgIT0gKDZ1PDw5KSkgJiYgKGRwbCAhPSBycGwpICkK
KyAgICAgICAgaWYgKCBpc19yZXQKKyAgICAgICAgICAgICA/IC8qCisgICAg
ICAgICAgICAgICAgKiBSZWFsbHkgcnBsIDwgY3BsLCBidXQgb3VyIHNvbGUg
Y2FsbGVyIGRvZXNuJ3QgaGFuZGxlCisgICAgICAgICAgICAgICAgKiBwcml2
aWxlZ2UgbGV2ZWwgY2hhbmdlcy4KKyAgICAgICAgICAgICAgICAqLworICAg
ICAgICAgICAgICAgcnBsICE9IGNwbCB8fCAoZGVzYy5iICYgKDEgPDwgMTAp
ID8gZHBsID4gcnBsIDogZHBsICE9IHJwbCkKKyAgICAgICAgICAgICA6IGRl
c2MuYiAmICgxIDw8IDEwKQorICAgICAgICAgICAgICAgLyogQ29uZm9ybWlu
ZyBzZWdtZW50OiBjaGVjayBEUEwgYWdhaW5zdCBDUEwuICovCisgICAgICAg
ICAgICAgICA/IGRwbCA+IGNwbAorICAgICAgICAgICAgICAgLyogTm9uLWNv
bmZvcm1pbmcgc2VnbWVudDogY2hlY2sgUlBMIGFuZCBEUEwgYWdhaW5zdCBD
UEwuICovCisgICAgICAgICAgICAgICA6IHJwbCA+IGNwbCB8fCBkcGwgIT0g
Y3BsICkKICAgICAgICAgICAgIGdvdG8gcmFpc2VfZXhuOworICAgICAgICAv
KiA2NC1iaXQgY29kZSBzZWdtZW50cyAoTCBiaXQgc2V0KSBtdXN0IGhhdmUg
RCBiaXQgY2xlYXIuICovCisgICAgICAgIGlmICggaW5fbG9uZ21vZGUoY3R4
dCwgb3BzKSAmJgorICAgICAgICAgICAgIChkZXNjLmIgJiAoMSA8PCAyMSkp
ICYmIChkZXNjLmIgJiAoMSA8PCAyMikpICkKKyAgICAgICAgICAgIGdvdG8g
cmFpc2VfZXhuOworICAgICAgICBzZWwgPSAoc2VsIF4gcnBsKSB8IGNwbDsK
ICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSB4ODZfc2VnX3NzOgogICAgICAg
ICAvKiBXcml0YWJsZSBkYXRhIHNlZ21lbnQ/ICovCkBAIC0xMjUyLDcgKzEy
NjYsNyBAQCBwcm90bW9kZV9sb2FkX3NlZygKIHN0YXRpYyBpbnQKIGxvYWRf
c2VnKAogICAgIGVudW0geDg2X3NlZ21lbnQgc2VnLAotICAgIHVpbnQxNl90
IHNlbCwKKyAgICB1aW50MTZfdCBzZWwsIGJvb2xfdCBpc19yZXQsCiAgICAg
c3RydWN0IHg4Nl9lbXVsYXRlX2N0eHQgKmN0eHQsCiAgICAgY29uc3Qgc3Ry
dWN0IHg4Nl9lbXVsYXRlX29wcyAqb3BzKQogewpAQCAtMTI2MSw3ICsxMjc1
LDcgQEAgbG9hZF9zZWcoCiAgICAgICAgIHJldHVybiBYODZFTVVMX1VOSEFO
RExFQUJMRTsKIAogICAgIGlmICggaW5fcHJvdG1vZGUoY3R4dCwgb3BzKSAp
Ci0gICAgICAgIHJldHVybiBwcm90bW9kZV9sb2FkX3NlZyhzZWcsIHNlbCwg
Y3R4dCwgb3BzKTsKKyAgICAgICAgcmV0dXJuIHByb3Rtb2RlX2xvYWRfc2Vn
KHNlZywgc2VsLCBpc19yZXQsIGN0eHQsIG9wcyk7CiAKICAgICByZXR1cm4g
cmVhbG1vZGVfbG9hZF9zZWcoc2VnLCBzZWwsIGN0eHQsIG9wcyk7CiB9CkBA
IC0yMDAzLDcgKzIwMTcsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgaWYg
KCAocmMgPSByZWFkX3Vsb25nKHg4Nl9zZWdfc3MsIHNwX3Bvc3RfaW5jKG9w
X2J5dGVzKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZkc3Qu
dmFsLCBvcF9ieXRlcywgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAg
ICBnb3RvIGRvbmU7Ci0gICAgICAgIGlmICggKHJjID0gbG9hZF9zZWcoc3Jj
LnZhbCwgKHVpbnQxNl90KWRzdC52YWwsIGN0eHQsIG9wcykpICE9IDAgKQor
ICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHNyYy52YWwsIGRzdC52YWws
IDAsIGN0eHQsIG9wcykpICE9IDAgKQogICAgICAgICAgICAgcmV0dXJuIHJj
OwogICAgICAgICBicmVhazsKIApAQCAtMjM1Nyw3ICsyMzcxLDcgQEAgeDg2
X2VtdWxhdGUoCiAgICAgICAgIGVudW0geDg2X3NlZ21lbnQgc2VnID0gZGVj
b2RlX3NlZ21lbnQobW9kcm1fcmVnKTsKICAgICAgICAgZ2VuZXJhdGVfZXhj
ZXB0aW9uX2lmKHNlZyA9PSBkZWNvZGVfc2VnbWVudF9mYWlsZWQsIEVYQ19V
RCwgLTEpOwogICAgICAgICBnZW5lcmF0ZV9leGNlcHRpb25faWYoc2VnID09
IHg4Nl9zZWdfY3MsIEVYQ19VRCwgLTEpOwotICAgICAgICBpZiAoIChyYyA9
IGxvYWRfc2VnKHNlZywgKHVpbnQxNl90KXNyYy52YWwsIGN0eHQsIG9wcykp
ICE9IDAgKQorICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHNlZywgc3Jj
LnZhbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAgICBnb3Rv
IGRvbmU7CiAgICAgICAgIGlmICggc2VnID09IHg4Nl9zZWdfc3MgKQogICAg
ICAgICAgICAgY3R4dC0+cmV0aXJlLmZsYWdzLm1vdl9zcyA9IDE7CkBAIC0y
NDM4LDcgKzI0NTIsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZfcmVncy5laXAsIG9wX2J5dGVzLCBjdHh0KSkg
KQogICAgICAgICAgICAgZ290byBkb25lOwogCi0gICAgICAgIGlmICggKHJj
ID0gbG9hZF9zZWcoeDg2X3NlZ19jcywgc2VsLCBjdHh0LCBvcHMpKSAhPSAw
ICkKKyAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4ODZfc2VnX2NzLCBz
ZWwsIDAsIGN0eHQsIG9wcykpICE9IDAgKQogICAgICAgICAgICAgZ290byBk
b25lOwogICAgICAgICBfcmVncy5laXAgPSBlaXA7CiAgICAgICAgIGJyZWFr
OwpAQCAtMjY2Miw3ICsyNjc2LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAg
IGlmICggKHJjID0gcmVhZF91bG9uZyhzcmMubWVtLnNlZywgc3JjLm1lbS5v
ZmYgKyBzcmMuYnl0ZXMsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmc2VsLCAyLCBjdHh0LCBvcHMpKSAhPSAwICkKICAgICAgICAgICAgIGdv
dG8gZG9uZTsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyhkc3QudmFs
LCAodWludDE2X3Qpc2VsLCBjdHh0LCBvcHMpKSAhPSAwICkKKyAgICAgICAg
aWYgKCAocmMgPSBsb2FkX3NlZyhkc3QudmFsLCBzZWwsIDAsIGN0eHQsIG9w
cykpICE9IDAgKQogICAgICAgICAgICAgZ290byBkb25lOwogICAgICAgICBk
c3QudmFsID0gc3JjLnZhbDsKICAgICAgICAgYnJlYWs7CkBAIC0yNzM2LDcg
KzI3NTAsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZkc3QudmFsLCBvcF9ieXRlcywgY3R4dCwgb3BzKSkgfHwK
ICAgICAgICAgICAgICAocmMgPSByZWFkX3Vsb25nKHg4Nl9zZWdfc3MsIHNw
X3Bvc3RfaW5jKG9wX2J5dGVzICsgb2Zmc2V0KSwKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZzcmMudmFsLCBvcF9ieXRlcywgY3R4dCwgb3Bz
KSkgfHwKLSAgICAgICAgICAgICAocmMgPSBsb2FkX3NlZyh4ODZfc2VnX2Nz
LCAodWludDE2X3Qpc3JjLnZhbCwgY3R4dCwgb3BzKSkgKQorICAgICAgICAg
ICAgIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNyYy52YWwsIDEsIGN0
eHQsIG9wcykpICkKICAgICAgICAgICAgIGdvdG8gZG9uZTsKICAgICAgICAg
X3JlZ3MuZWlwID0gZHN0LnZhbDsKICAgICAgICAgYnJlYWs7CkBAIC0yNzg1
LDcgKzI3OTksNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgX3JlZ3MuZWZs
YWdzICY9IG1hc2s7CiAgICAgICAgIF9yZWdzLmVmbGFncyB8PSAodWludDMy
X3QpKGVmbGFncyAmIH5tYXNrKSB8IDB4MDI7CiAgICAgICAgIF9yZWdzLmVp
cCA9IGVpcDsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4ODZfc2Vn
X2NzLCAodWludDE2X3QpY3MsIGN0eHQsIG9wcykpICE9IDAgKQorICAgICAg
ICBpZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIGNzLCAxLCBjdHh0
LCBvcHMpKSAhPSAwICkKICAgICAgICAgICAgIGdvdG8gZG9uZTsKICAgICAg
ICAgYnJlYWs7CiAgICAgfQpAQCAtMzQxNSw3ICszNDI5LDcgQEAgeDg2X2Vt
dWxhdGUoCiAgICAgICAgIGdlbmVyYXRlX2V4Y2VwdGlvbl9pZihtb2RlXzY0
Yml0KCksIEVYQ19VRCwgLTEpOwogICAgICAgICBlaXAgPSBpbnNuX2ZldGNo
X2J5dGVzKG9wX2J5dGVzKTsKICAgICAgICAgc2VsID0gaW5zbl9mZXRjaF90
eXBlKHVpbnQxNl90KTsKLSAgICAgICAgaWYgKCAocmMgPSBsb2FkX3NlZyh4
ODZfc2VnX2NzLCBzZWwsIGN0eHQsIG9wcykpICE9IDAgKQorICAgICAgICBp
ZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNlbCwgMCwgY3R4dCwg
b3BzKSkgIT0gMCApCiAgICAgICAgICAgICBnb3RvIGRvbmU7CiAgICAgICAg
IF9yZWdzLmVpcCA9IGVpcDsKICAgICAgICAgYnJlYWs7CkBAIC0zNzE0LDcg
KzM3MjgsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgICAgICAgICAg
Z290byBkb25lOwogICAgICAgICAgICAgfQogCi0gICAgICAgICAgICBpZiAo
IChyYyA9IGxvYWRfc2VnKHg4Nl9zZWdfY3MsIHNlbCwgY3R4dCwgb3BzKSkg
IT0gMCApCisgICAgICAgICAgICBpZiAoIChyYyA9IGxvYWRfc2VnKHg4Nl9z
ZWdfY3MsIHNlbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCApCiAgICAgICAgICAg
ICAgICAgZ290byBkb25lOwogICAgICAgICAgICAgX3JlZ3MuZWlwID0gc3Jj
LnZhbDsKIApAQCAtMzc4MSw3ICszNzk1LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIGdlbmVyYXRlX2V4Y2VwdGlvbl9pZighaW5fcHJvdG1vZGUoY3R4
dCwgb3BzKSwgRVhDX1VELCAtMSk7CiAgICAgICAgIGdlbmVyYXRlX2V4Y2Vw
dGlvbl9pZighbW9kZV9yaW5nMCgpLCBFWENfR1AsIDApOwogICAgICAgICBp
ZiAoIChyYyA9IGxvYWRfc2VnKChtb2RybV9yZWcgJiAxKSA/IHg4Nl9zZWdf
dHIgOiB4ODZfc2VnX2xkdHIsCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3JjLnZhbCwgY3R4dCwgb3BzKSkgIT0gMCApCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc3JjLnZhbCwgMCwgY3R4dCwgb3BzKSkgIT0gMCAp
CiAgICAgICAgICAgICBnb3RvIGRvbmU7CiAgICAgICAgIGJyZWFrOwogCg==

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Tue Nov 18 12:24:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 12: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 1Xqhpz-0006RT-Gq; Tue, 18 Nov 2014 12:24:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xqhpw-0006Qe-5w; Tue, 18 Nov 2014 12:24:48 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	46/DC-02696-F8A3B645; Tue, 18 Nov 2014 12:24:47 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416313485!13298519!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10912 invoked from network); 18 Nov 2014 12:24:46 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Nov 2014 12:24:46 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XqhpC-0000LH-Km; Tue, 18 Nov 2014 12:24:05 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XqhpC-0003RN-5U; Tue, 18 Nov 2014 12:24:02 +0000
Date: Tue, 18 Nov 2014 12:24:02 +0000
Message-Id: <E1XqhpC-0003RN-5U@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 109 (CVE-2014-8594) -
 Insufficient restrictions on certain MMU update hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

             Xen Security Advisory CVE-2014-8594 / XSA-109
                               version 3

        Insufficient restrictions on certain MMU update hypercalls

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

MMU update operations targeting page tables are intended to be used on
PV guests only. The lack of a respective check made it possible for
such operations to access certain function pointers which remain NULL
when the target guest is using Hardware Assisted Paging (HAP).

IMPACT
======

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.

Only PV domains with privilege over other guests can exploit this
vulnerability; and only when those other guests are HVM using HAP, or
PVH.  The vulnerability is therefore exposed to PV domains providing
hardware emulation services to HVM guests.

VULNERABLE SYSTEMS
==================

Xen 4.0 and onward are vulnerable.

Only x86 systems are vulnerable.  ARM systems are not vulnerable.

The vulnerability is only exposed to PV service domains for HVM or
PVH guests which have privilege over the guest.  In a usual
configuration that means only device model emulators (qemu-dm).

In the case of HVM guests whose device model is running in an
unrestricted dom0 process, qemu-dm already has the ability to cause
problems for the whole system.  So in that case the vulnerability is
not applicable.

The situation is more subtle for an HVM guest with a stub qemu-dm.
That is, where the device model runs in a separate domain (in the case
of xl, as requested by "device_model_stubdomain_override=1" in the xl
domain configuration file).  The same applies with a qemu-dm in a dom0
process subjected to some kind kernel-based process privilege
limitation (eg the chroot technique as found in some versions of
XCP/XenServer).

In those latter situations this issue means that the extra isolation
does not provide as good a defence (against denial of service) as
intended.  That is the essence of this vulnerability.

However, the security is still better than with a qemu-dm running as
an unrestricted dom0 process.  Therefore users with these
configurations should not switch to an unrestricted dom0 qemu-dm.

Finally, in a radically disaggregated system: where the HVM or PVH
service domain software (probably, the device model domain image in the
HVM case) is not always supplied by the host administrator, a malicious
service domain administrator can exercise this vulnerability.

MITIGATION
==========

Running only PV guests or HVM guests with shadow paging enabled will
avoid this issue.

In a radically disaggregated system, restricting HVM service domains
to software images approved by the host administrator will avoid the
vulnerability.

CREDITS
=======

This issue was discovered by Roger Pau Monné of Citrix and Jan Beulich
of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa109.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x
xsa109-4.2.patch    Xen 4.2.x

$ sha256sum xsa109*.patch
759d1b8cb8c17e53d17ad045ab89c5aaf52cb85fd93eef07e7acbe230365c56d  xsa109-4.2.patch
729b87c2b9979fbda47c96e934db6fcfaeb10e07b4cfd66bb1e9f746a908576b  xsa109.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUazogAAoJEIP+FMlX6CvZ5NQH/25lTqtBGu5Xt0JwHnLenfv0
z0gVJ5o8YB6aqzV+GHWei0QV/PtCLteykm/K8LJK4my9OtDqI/WPzusyrGB6aNhD
xCQUhRF5/j2c++u4UCBitibttSwKK/CCrswBMWZYqEI/1fJazVw3huyyFv56Wt+K
32geEcIUnWs6lJD+z97W8LPPNLoaF/m6uSh4I2LrT3uBnvEFq5oGgzdWNtEKkSGC
fAuga2m1NhfbCsMD6JSv9/EDSKHTiByZ5Z/zicWrButHfRp4fmGO/pPMwPFkERs1
T/FX/UAfnvisS1SjgMwqufWlzIka5JDzi/Nc5Utgcvo9+9EsI1PCJDzYTJpOSa8=
=yb1z
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa109-4.2.patch"
Content-Disposition: attachment; filename="xsa109-4.2.patch"
Content-Transfer-Encoding: base64

eDg2OiBkb24ndCBhbGxvdyBwYWdlIHRhYmxlIHVwZGF0ZXMgb24gbm9uLVBW
IHBhZ2UgdGFibGVzIGluIGRvX21tdV91cGRhdGUoKQoKcGFnaW5nX3dyaXRl
X2d1ZXN0X2VudHJ5KCkgYW5kIHBhZ2luZ19jbXB4Y2hnX2d1ZXN0X2VudHJ5
KCkgYXJlbid0CmNvbnNpc3RlbnRseSBzdXBwb3J0ZWQgZm9yIG5vbi1QViBn
dWVzdHMgKHRoZXknZCBkZXJlZiBOVUxMIGZvciBQVkggb3IKbm9uLUhBUCBI
Vk0gb25lcykuIERvbid0IGFsbG93IHJlc3BlY3RpdmUgTU1VXyogb3BlcmF0
aW9ucyBvbiB0aGUKcGFnZSB0YWJsZXMgb2Ygc3VjaCBkb21haW5zLgoKVGhp
cyBpcyBYU0EtMTA5LgoKU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpi
ZXVsaWNoQHN1c2UuY29tPgpBY2tlZC1ieTogVGltIERlZWdhbiA8dGltQHhl
bi5vcmc+CgotLS0gYS94ZW4vYXJjaC94ODYvbW0uYworKysgYi94ZW4vYXJj
aC94ODYvbW0uYwpAQCAtMzgwMCw2ICszODAwLDEwIEBAIGxvbmcgZG9fbW11
X3VwZGF0ZSgKICAgICAgICAgewogICAgICAgICAgICAgcDJtX3R5cGVfdCBw
Mm10OwogCisgICAgICAgICAgICByYyA9IC1FT1BOT1RTVVBQOworICAgICAg
ICAgICAgaWYgKCB1bmxpa2VseShwYWdpbmdfbW9kZV9yZWZjb3VudHMocHRf
b3duZXIpKSApCisgICAgICAgICAgICAgICAgYnJlYWs7CisKICAgICAgICAg
ICAgIHJjID0geHNtX21tdV9ub3JtYWxfdXBkYXRlKGQsIHB0X293bmVyLCBw
Z19vd25lciwgcmVxLnZhbCk7CiAgICAgICAgICAgICBpZiAoIHJjICkKICAg
ICAgICAgICAgICAgICBicmVhazsK

--=separator
Content-Type: application/octet-stream; name="xsa109.patch"
Content-Disposition: attachment; filename="xsa109.patch"
Content-Transfer-Encoding: base64

eDg2OiBkb24ndCBhbGxvdyBwYWdlIHRhYmxlIHVwZGF0ZXMgb24gbm9uLVBW
IHBhZ2UgdGFibGVzIGluIGRvX21tdV91cGRhdGUoKQoKcGFnaW5nX3dyaXRl
X2d1ZXN0X2VudHJ5KCkgYW5kIHBhZ2luZ19jbXB4Y2hnX2d1ZXN0X2VudHJ5
KCkgYXJlbid0CmNvbnNpc3RlbnRseSBzdXBwb3J0ZWQgZm9yIG5vbi1QViBn
dWVzdHMgKHRoZXknZCBkZXJlZiBOVUxMIGZvciBQVkggb3IKbm9uLUhBUCBI
Vk0gb25lcykuIERvbid0IGFsbG93IHJlc3BlY3RpdmUgTU1VXyogb3BlcmF0
aW9ucyBvbiB0aGUKcGFnZSB0YWJsZXMgb2Ygc3VjaCBkb21haW5zLgoKVGhp
cyBpcyBYU0EtMTA5LgoKU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpi
ZXVsaWNoQHN1c2UuY29tPgpBY2tlZC1ieTogVGltIERlZWdhbiA8dGltQHhl
bi5vcmc+CgotLS0gYS94ZW4vYXJjaC94ODYvbW0uYworKysgYi94ZW4vYXJj
aC94ODYvbW0uYwpAQCAtMzQ5Myw2ICszNDkzLDEwIEBAIGxvbmcgZG9fbW11
X3VwZGF0ZSgKICAgICAgICAgewogICAgICAgICAgICAgcDJtX3R5cGVfdCBw
Mm10OwogCisgICAgICAgICAgICByYyA9IC1FT1BOT1RTVVBQOworICAgICAg
ICAgICAgaWYgKCB1bmxpa2VseShwYWdpbmdfbW9kZV9yZWZjb3VudHMocHRf
b3duZXIpKSApCisgICAgICAgICAgICAgICAgYnJlYWs7CisKICAgICAgICAg
ICAgIHhzbV9uZWVkZWQgfD0gWFNNX01NVV9OT1JNQUxfVVBEQVRFOwogICAg
ICAgICAgICAgaWYgKCBnZXRfcHRlX2ZsYWdzKHJlcS52YWwpICYgX1BBR0Vf
UFJFU0VOVCApCiAgICAgICAgICAgICB7Cg==

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Tue Nov 18 12:28:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 12:28:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqht1-00075G-IZ; Tue, 18 Nov 2014 12:27:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1Xqht0-000750-EN
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 12:27:58 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	8B/CD-03145-D4B3B645; Tue, 18 Nov 2014 12:27:57 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416313675!12726964!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2143 invoked from network); 18 Nov 2014 12:27:56 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 12:27:56 -0000
Received: by mail-qc0-f171.google.com with SMTP id r5so6051103qcx.16
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 04:27:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=FIgyXP9qY/8HFH8IRigg7Kgs9PJE2FgmmSPRfFxbrBo=;
	b=GaNOhznkdk8ISh5mF9JQboXV0r0L6dOLmtOBCCV5XXdrcf25jXcPhPTOIw+fx9Vh49
	VI2HTyI07zwuUlrl4y4GdJioy4wLAdaXr0+kywqNqH89ZzeyM1KlWMhL/mjia31y9wSS
	cCrKOZDHmp/MwW0a3EJWddSJ5E+aT4P8xvEeFF7X5re1Avfx2l9iwGd+GrOAalvQK3xX
	8e1L65BTCzOnmo8sBtT/t+uqZKhw642T8OljuqClUjFprX92izslDI3V2rGqo346ROX3
	PAey1eAzYUJe3pbvkdVfoUEHPyI/kuU1gd4njz/zB4o98fdsse1A66bj6ozEVrFvdVN0
	g61A==
X-Gm-Message-State: ALoCoQmb9CvxO3OLH4wKjZeCJ3L1/tk3dTXyI5cByTGsMsiO/u3lD2Otakw2YIpd95smzEtRfFRP
MIME-Version: 1.0
X-Received: by 10.140.95.225 with SMTP id i88mr42393078qge.2.1416313674259;
	Tue, 18 Nov 2014 04:27:54 -0800 (PST)
Received: by 10.229.176.198 with HTTP; Tue, 18 Nov 2014 04:27:54 -0800 (PST)
In-Reply-To: <546B04180200007800048A31@mail.emea.novell.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
	<546A32720200007800048873@mail.emea.novell.com>
	<CAErYnsgm5F3ThZe2w1Lq=az90ve_1pLhEb+Kpc2k9AfWOvB1FA@mail.gmail.com>
	<546B04180200007800048A31@mail.emea.novell.com>
Date: Tue, 18 Nov 2014 13:27:54 +0100
Message-ID: <CAErYnsjrtUuVa6szB1Mx9+Qi-FeDAnm6gqfEWWUdGOsEpiCUiw@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Eddie Dong <eddie.dong@intel.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0907215947973801366=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0907215947973801366==
Content-Type: multipart/alternative; boundary=001a11c1636071f9e105082139df

--001a11c1636071f9e105082139df
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 18, 2014 at 8:32 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 17.11.14 at 18:06, <tamas.lengyel@zentific.com> wrote:
> > On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >
> >> >>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
> >> > On 12/11/14 15:31, Tamas K Lengyel wrote:
> >> >>  xen/include/public/domctl.h         |  44 +--
> >> >>  xen/include/public/hvm/params.h     |   2 +-
> >> >>  xen/include/public/mem_event.h      | 134 -------
> >> >>  xen/include/public/memory.h         |   6 +-
> >> >>  xen/include/public/vm_event.h       | 179 +++++++++
> >> >
> >> > While in principle I think this series is a very good thing, there is
> a
> >> > problem with editing the pubic header files.
> >> >
> >> > The contents of mem_event.h is not currently hidden behind #ifdef
> >> > __XEN_TOOLS__
> >> >
> >> > As a result, it is strictly speaking part of the VM-visible public
> >> > API/ABI and not permitted to change in a backwards incompatible manor.
> >> >
> >> > Having said that, it is currently only usable by privileged domains,
> so
> >> > there is an argument to be made for declaring that it should have been
> >> > hidden behind __XEN_TOOLS__ in the first place, making it permittable
> to
> >> > change.
> >>
> >> I'm not sure I agree - the meaning of "tools" here would seem quite a
> >> bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
> >> an old consumer (remember that for many of these we have at best
> >> fake consumers in the tree) would deal with the now differently
> >> arranged data. I don't see any versioning of the interface, and hence
> >> I can't see how tools would know which of the formats to expect.
> >
> > The lack of versioning is a real concern which I have aired during the
> 4.5
> > development process. For example, when we switched from HVMEM_access_* to
> > XENMEM_access_* a customer had to do a bunch of manual configure checks
> to
> > determine what is supported and what isn't. Furthermore, many of the
> > related APIs have changed quite radically between Xen 4.1-4.5, some being
> > abandoned midway just to resurface later in a different context. Going
> > forward having a clear VM_EVENT_VERSION definition would be very helpful
> > and would be the cleanest solution IMHO.
>
> That's a concern different from mine - source compatibility may be
> acceptable to get broken. Undetectable binary incompatibilities are
> what worry me more.
>
> Jan
>

To be fair, I don't think there ever was backwards compatibility
established with the usage of that struct in source or binary form. A quick
glance at git log shows that it had been shuffled around and extended quite
a bit over the years. Going forward it would be best to start with
something that's clean before backwards compatibility is enforced IMHO.

Tamas

--001a11c1636071f9e105082139df
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Nov 18, 2014 at 8:32 AM, Jan Beulich <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><di=
v class=3D"h5">&gt;&gt;&gt; On 17.11.14 at 18:06, &lt;<a href=3D"mailto:tam=
as.lengyel@zentific.com">tamas.lengyel@zentific.com</a>&gt; wrote:<br>
&gt; On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; &gt;&gt;&gt; On 12.11.14 at 16:48, &lt;<a href=3D"mailto:andrew.co=
oper3@citrix.com">andrew.cooper3@citrix.com</a>&gt; wrote:<br>
&gt;&gt; &gt; On 12/11/14 15:31, Tamas K Lengyel wrote:<br>
&gt;&gt; &gt;&gt;=A0 xen/include/public/domctl.h=A0 =A0 =A0 =A0 =A0|=A0 44 =
+--<br>
&gt;&gt; &gt;&gt;=A0 xen/include/public/hvm/params.h=A0 =A0 =A0|=A0 =A02 +-=
<br>
&gt;&gt; &gt;&gt;=A0 xen/include/public/mem_event.h=A0 =A0 =A0 | 134 ------=
-<br>
&gt;&gt; &gt;&gt;=A0 xen/include/public/memory.h=A0 =A0 =A0 =A0 =A0|=A0 =A0=
6 +-<br>
&gt;&gt; &gt;&gt;=A0 xen/include/public/vm_event.h=A0 =A0 =A0 =A0| 179 ++++=
+++++<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; While in principle I think this series is a very good thing, =
there is a<br>
&gt;&gt; &gt; problem with editing the pubic header files.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The contents of mem_event.h is not currently hidden behind #i=
fdef<br>
&gt;&gt; &gt; __XEN_TOOLS__<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; As a result, it is strictly speaking part of the VM-visible p=
ublic<br>
&gt;&gt; &gt; API/ABI and not permitted to change in a backwards incompatib=
le manor.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Having said that, it is currently only usable by privileged d=
omains, so<br>
&gt;&gt; &gt; there is an argument to be made for declaring that it should =
have been<br>
&gt;&gt; &gt; hidden behind __XEN_TOOLS__ in the first place, making it per=
mittable to<br>
&gt;&gt; &gt; change.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m not sure I agree - the meaning of &quot;tools&quot; here w=
ould seem quite a<br>
&gt;&gt; bit different than e.g. in domctl.h. Looking at patch 1, I can&#39=
;t see how<br>
&gt;&gt; an old consumer (remember that for many of these we have at best<b=
r>
&gt;&gt; fake consumers in the tree) would deal with the now differently<br=
>
&gt;&gt; arranged data. I don&#39;t see any versioning of the interface, an=
d hence<br>
&gt;&gt; I can&#39;t see how tools would know which of the formats to expec=
t.<br>
&gt;<br>
</div></div><span class=3D"">&gt; The lack of versioning is a real concern =
which I have aired during the 4.5<br>
&gt; development process. For example, when we switched from HVMEM_access_*=
 to<br>
&gt; XENMEM_access_* a customer had to do a bunch of manual configure check=
s to<br>
&gt; determine what is supported and what isn&#39;t. Furthermore, many of t=
he<br>
&gt; related APIs have changed quite radically between Xen 4.1-4.5, some be=
ing<br>
&gt; abandoned midway just to resurface later in a different context. Going=
<br>
&gt; forward having a clear VM_EVENT_VERSION definition would be very helpf=
ul<br>
&gt; and would be the cleanest solution IMHO.<br>
<br>
</span>That&#39;s a concern different from mine - source compatibility may =
be<br>
acceptable to get broken. Undetectable binary incompatibilities are<br>
what worry me more.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br></font></span></blockquote><div><br></div><div>To be fair, I don&#39=
;t think there ever was backwards compatibility established with the usage =
of that struct in source or binary form. A quick glance at git log shows th=
at it had been shuffled around and extended quite a bit over the years. Goi=
ng forward it would be best to start with something that&#39;s clean before=
 backwards compatibility is enforced IMHO.<br><br>Tamas <br></div></div><br=
></div></div>

--001a11c1636071f9e105082139df--


--===============0907215947973801366==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0907215947973801366==--


From xen-devel-bounces@lists.xen.org Tue Nov 18 12:28:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 12:28:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqht1-00075G-IZ; Tue, 18 Nov 2014 12:27:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tamas.lengyel@zentific.com>) id 1Xqht0-000750-EN
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 12:27:58 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	8B/CD-03145-D4B3B645; Tue, 18 Nov 2014 12:27:57 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416313675!12726964!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2143 invoked from network); 18 Nov 2014 12:27:56 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 12:27:56 -0000
Received: by mail-qc0-f171.google.com with SMTP id r5so6051103qcx.16
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 04:27:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=FIgyXP9qY/8HFH8IRigg7Kgs9PJE2FgmmSPRfFxbrBo=;
	b=GaNOhznkdk8ISh5mF9JQboXV0r0L6dOLmtOBCCV5XXdrcf25jXcPhPTOIw+fx9Vh49
	VI2HTyI07zwuUlrl4y4GdJioy4wLAdaXr0+kywqNqH89ZzeyM1KlWMhL/mjia31y9wSS
	cCrKOZDHmp/MwW0a3EJWddSJ5E+aT4P8xvEeFF7X5re1Avfx2l9iwGd+GrOAalvQK3xX
	8e1L65BTCzOnmo8sBtT/t+uqZKhw642T8OljuqClUjFprX92izslDI3V2rGqo346ROX3
	PAey1eAzYUJe3pbvkdVfoUEHPyI/kuU1gd4njz/zB4o98fdsse1A66bj6ozEVrFvdVN0
	g61A==
X-Gm-Message-State: ALoCoQmb9CvxO3OLH4wKjZeCJ3L1/tk3dTXyI5cByTGsMsiO/u3lD2Otakw2YIpd95smzEtRfFRP
MIME-Version: 1.0
X-Received: by 10.140.95.225 with SMTP id i88mr42393078qge.2.1416313674259;
	Tue, 18 Nov 2014 04:27:54 -0800 (PST)
Received: by 10.229.176.198 with HTTP; Tue, 18 Nov 2014 04:27:54 -0800 (PST)
In-Reply-To: <546B04180200007800048A31@mail.emea.novell.com>
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<54638141.3010500@citrix.com>
	<546A32720200007800048873@mail.emea.novell.com>
	<CAErYnsgm5F3ThZe2w1Lq=az90ve_1pLhEb+Kpc2k9AfWOvB1FA@mail.gmail.com>
	<546B04180200007800048A31@mail.emea.novell.com>
Date: Tue, 18 Nov 2014 13:27:54 +0100
Message-ID: <CAErYnsjrtUuVa6szB1Mx9+Qi-FeDAnm6gqfEWWUdGOsEpiCUiw@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Eddie Dong <eddie.dong@intel.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>, rshriram@cs.ubc.ca,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0907215947973801366=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0907215947973801366==
Content-Type: multipart/alternative; boundary=001a11c1636071f9e105082139df

--001a11c1636071f9e105082139df
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 18, 2014 at 8:32 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 17.11.14 at 18:06, <tamas.lengyel@zentific.com> wrote:
> > On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >
> >> >>> On 12.11.14 at 16:48, <andrew.cooper3@citrix.com> wrote:
> >> > On 12/11/14 15:31, Tamas K Lengyel wrote:
> >> >>  xen/include/public/domctl.h         |  44 +--
> >> >>  xen/include/public/hvm/params.h     |   2 +-
> >> >>  xen/include/public/mem_event.h      | 134 -------
> >> >>  xen/include/public/memory.h         |   6 +-
> >> >>  xen/include/public/vm_event.h       | 179 +++++++++
> >> >
> >> > While in principle I think this series is a very good thing, there is
> a
> >> > problem with editing the pubic header files.
> >> >
> >> > The contents of mem_event.h is not currently hidden behind #ifdef
> >> > __XEN_TOOLS__
> >> >
> >> > As a result, it is strictly speaking part of the VM-visible public
> >> > API/ABI and not permitted to change in a backwards incompatible manor.
> >> >
> >> > Having said that, it is currently only usable by privileged domains,
> so
> >> > there is an argument to be made for declaring that it should have been
> >> > hidden behind __XEN_TOOLS__ in the first place, making it permittable
> to
> >> > change.
> >>
> >> I'm not sure I agree - the meaning of "tools" here would seem quite a
> >> bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
> >> an old consumer (remember that for many of these we have at best
> >> fake consumers in the tree) would deal with the now differently
> >> arranged data. I don't see any versioning of the interface, and hence
> >> I can't see how tools would know which of the formats to expect.
> >
> > The lack of versioning is a real concern which I have aired during the
> 4.5
> > development process. For example, when we switched from HVMEM_access_* to
> > XENMEM_access_* a customer had to do a bunch of manual configure checks
> to
> > determine what is supported and what isn't. Furthermore, many of the
> > related APIs have changed quite radically between Xen 4.1-4.5, some being
> > abandoned midway just to resurface later in a different context. Going
> > forward having a clear VM_EVENT_VERSION definition would be very helpful
> > and would be the cleanest solution IMHO.
>
> That's a concern different from mine - source compatibility may be
> acceptable to get broken. Undetectable binary incompatibilities are
> what worry me more.
>
> Jan
>

To be fair, I don't think there ever was backwards compatibility
established with the usage of that struct in source or binary form. A quick
glance at git log shows that it had been shuffled around and extended quite
a bit over the years. Going forward it would be best to start with
something that's clean before backwards compatibility is enforced IMHO.

Tamas

--001a11c1636071f9e105082139df
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Nov 18, 2014 at 8:32 AM, Jan Beulich <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><di=
v class=3D"h5">&gt;&gt;&gt; On 17.11.14 at 18:06, &lt;<a href=3D"mailto:tam=
as.lengyel@zentific.com">tamas.lengyel@zentific.com</a>&gt; wrote:<br>
&gt; On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; &gt;&gt;&gt; On 12.11.14 at 16:48, &lt;<a href=3D"mailto:andrew.co=
oper3@citrix.com">andrew.cooper3@citrix.com</a>&gt; wrote:<br>
&gt;&gt; &gt; On 12/11/14 15:31, Tamas K Lengyel wrote:<br>
&gt;&gt; &gt;&gt;=A0 xen/include/public/domctl.h=A0 =A0 =A0 =A0 =A0|=A0 44 =
+--<br>
&gt;&gt; &gt;&gt;=A0 xen/include/public/hvm/params.h=A0 =A0 =A0|=A0 =A02 +-=
<br>
&gt;&gt; &gt;&gt;=A0 xen/include/public/mem_event.h=A0 =A0 =A0 | 134 ------=
-<br>
&gt;&gt; &gt;&gt;=A0 xen/include/public/memory.h=A0 =A0 =A0 =A0 =A0|=A0 =A0=
6 +-<br>
&gt;&gt; &gt;&gt;=A0 xen/include/public/vm_event.h=A0 =A0 =A0 =A0| 179 ++++=
+++++<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; While in principle I think this series is a very good thing, =
there is a<br>
&gt;&gt; &gt; problem with editing the pubic header files.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The contents of mem_event.h is not currently hidden behind #i=
fdef<br>
&gt;&gt; &gt; __XEN_TOOLS__<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; As a result, it is strictly speaking part of the VM-visible p=
ublic<br>
&gt;&gt; &gt; API/ABI and not permitted to change in a backwards incompatib=
le manor.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Having said that, it is currently only usable by privileged d=
omains, so<br>
&gt;&gt; &gt; there is an argument to be made for declaring that it should =
have been<br>
&gt;&gt; &gt; hidden behind __XEN_TOOLS__ in the first place, making it per=
mittable to<br>
&gt;&gt; &gt; change.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m not sure I agree - the meaning of &quot;tools&quot; here w=
ould seem quite a<br>
&gt;&gt; bit different than e.g. in domctl.h. Looking at patch 1, I can&#39=
;t see how<br>
&gt;&gt; an old consumer (remember that for many of these we have at best<b=
r>
&gt;&gt; fake consumers in the tree) would deal with the now differently<br=
>
&gt;&gt; arranged data. I don&#39;t see any versioning of the interface, an=
d hence<br>
&gt;&gt; I can&#39;t see how tools would know which of the formats to expec=
t.<br>
&gt;<br>
</div></div><span class=3D"">&gt; The lack of versioning is a real concern =
which I have aired during the 4.5<br>
&gt; development process. For example, when we switched from HVMEM_access_*=
 to<br>
&gt; XENMEM_access_* a customer had to do a bunch of manual configure check=
s to<br>
&gt; determine what is supported and what isn&#39;t. Furthermore, many of t=
he<br>
&gt; related APIs have changed quite radically between Xen 4.1-4.5, some be=
ing<br>
&gt; abandoned midway just to resurface later in a different context. Going=
<br>
&gt; forward having a clear VM_EVENT_VERSION definition would be very helpf=
ul<br>
&gt; and would be the cleanest solution IMHO.<br>
<br>
</span>That&#39;s a concern different from mine - source compatibility may =
be<br>
acceptable to get broken. Undetectable binary incompatibilities are<br>
what worry me more.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br></font></span></blockquote><div><br></div><div>To be fair, I don&#39=
;t think there ever was backwards compatibility established with the usage =
of that struct in source or binary form. A quick glance at git log shows th=
at it had been shuffled around and extended quite a bit over the years. Goi=
ng forward it would be best to start with something that&#39;s clean before=
 backwards compatibility is enforced IMHO.<br><br>Tamas <br></div></div><br=
></div></div>

--001a11c1636071f9e105082139df--


--===============0907215947973801366==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0907215947973801366==--


From xen-devel-bounces@lists.xen.org Tue Nov 18 12:35:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 12: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 1Xqi0H-0007kq-QR; Tue, 18 Nov 2014 12:35:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xqi0G-0007ki-Ah
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 12:35:28 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9D/04-09842-F0D3B645; Tue, 18 Nov 2014 12:35:27 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416314124!5551137!1
X-Originating-IP: [64.18.0.24]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16698 invoked from network); 18 Nov 2014 12:35:26 -0000
Received: from exprod5og112.obsmtp.com (HELO exprod5og112.obsmtp.com)
	(64.18.0.24)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 12:35:26 -0000
Received: from mail-la0-f52.google.com ([209.85.215.52]) (using TLSv1) by
	exprod5ob112.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGs9DBQsWjWHh3BPsO9twEDtaRL7lb8d@postini.com;
	Tue, 18 Nov 2014 04:35:26 PST
Received: by mail-la0-f52.google.com with SMTP id q1so2129110lam.39
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 04:35:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Q7Vp8FfIMvWifSIl23HMEv3oeRzBqNoKGk6gQFS8t+U=;
	b=JCJ1d5OB1ouw0YMsNs1F29Oq3at8z1D/yHBhcd3DSiluSX3ST2ce86vJ0+M7Qf6TD/
	Qie3L5Wv4Su2QzQOPHIwSZrIlt9svJK7LH0CbQDRPxSrd55fUBXyvuUGqOlDCn58GP92
	VXTSgDlXjqEENQtovm7Mr7chXCdwLQK3hF0Yk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Q7Vp8FfIMvWifSIl23HMEv3oeRzBqNoKGk6gQFS8t+U=;
	b=EQi+5WhfM5BriTocCcFPNiBHx3SsZTRvHYKMr92I+u9iNHszTyqihNQlBpyeAk25y7
	0hlQQoEbkC+e+CJDRsQKIK19e+p1M2L5ebx83968NH1mZPYVbi6cJgGYnYw5KtyX0Dv4
	FhEjmL5JTYWHW5PLuBIq1ARso1i6VwJDsKzX3IDbaQ+LBlHRZ6ccjLXyGoTXYPQDF+qg
	eQgWJAPdNncQhZtmut/Lf02nBM3NRV7Ilckq2lC90HDMYE3pyFlScKYwDIKquFljAC42
	CAnZVQ1qIaYq7bdx6kqabCairySpDQyfUZ5c+w2AkaRXdksRVwiEuinbXjPxKETSTvxa
	p3bA==
X-Gm-Message-State: ALoCoQlUa/y07QnRp9NgKkktOP5R7hU6fWfr3Ws7iafgTZKV5cA+88wMoyw4IBSyZUVFo9riFq/RnBdQiqY2PXw9aZIvBV9bkVlJ2kpZVew2Y9U4g2hGbSrqJBhrG4WYJlB5al1UXPN0ktdLgNfrU1h1gWbU/w+qtA==
X-Received: by 10.153.11.133 with SMTP id ei5mr18538834lad.75.1416314122772;
	Tue, 18 Nov 2014 04:35:22 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.153.11.133 with SMTP id ei5mr18538814lad.75.1416314122647;
	Tue, 18 Nov 2014 04:35:22 -0800 (PST)
Received: by 10.112.61.69 with HTTP; Tue, 18 Nov 2014 04:35:22 -0800 (PST)
In-Reply-To: <CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
Date: Tue, 18 Nov 2014 14:35:22 +0200
Message-ID: <CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
everything works fine
The following 2 patches fixes xen/master for my platform.

Stefano, could you please take a look to these changes?

commit 3628a0aa35706a8f532af865ed784536ce514eca
Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
Date:   Tue Nov 18 14:20:42 2014 +0200

    xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag

    Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
    Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..093ecdb 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
pending_irq *p,
                                              << GICH_V2_LR_PRIORITY_SHIFT) |
               ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
GICH_V2_LR_VIRTUAL_SHIFT));

-    if ( p->desc != NULL )
+    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
     {
-        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
-            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
-        else
-            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
GICH_V2_LR_PHYSICAL_MASK )
-                            << GICH_V2_LR_PHYSICAL_SHIFT);
+        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
+    }
+    else if ( p->desc != NULL )
+    {
+        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
+                       << GICH_V2_LR_PHYSICAL_SHIFT);
     }

     writel_gich(lr_reg, GICH_LR + lr * 4);

commit 110ad1914f04a5e52ec9d49a9aeb7df488f524b1
Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
Date:   Tue Nov 18 12:14:42 2014 +0200

    xen/arm: dra7: add PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI

    Change-Id: Ic6285d5aea803fb0bfef50ffcc35e20b5bfb7a77
    Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>

diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
index 9d6e504..fb6686f 100644
--- a/xen/arch/arm/platforms/omap5.c
+++ b/xen/arch/arm/platforms/omap5.c
@@ -166,6 +166,11 @@ static const struct dt_device_match
dra7_blacklist_dev[] __initconst =
     { /* sentinel */ },
 };

+static uint32_t dra7_quirks(void)
+{
+    return PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI;
+}
+
 PLATFORM_START(omap5, "TI OMAP5")
     .compatible = omap5_dt_compat,
     .init_time = omap5_init_time,
@@ -186,6 +191,7 @@ PLATFORM_START(dra7, "TI DRA7")
     .dom0_gnttab_start = 0x4b000000,
     .dom0_gnttab_size = 0x20000,
     .blacklist_dev = dra7_blacklist_dev,
+    .quirks = dra7_quirks,
 PLATFORM_END

 /*

On Tue, Nov 18, 2014 at 1:31 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> Strange - looks like baseline code already does the same, that you
> sent me yesterday. The only what is needed - is to set
> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI.
> But baseline contains an issue. And in the same time changes on top of
> 5495a512b63bad868c147198f7f049c2617d468c work fine.
>
> Regards,
> Andrii
>
> On Tue, Nov 18, 2014 at 12:41 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
>> Hi Stefano,
>>
>> On Mon, Nov 17, 2014 at 8:02 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>>> On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
>>>> Hi Stefano,
>>>>
>>>> Thank you for your answer.
>>>>
>>>> On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
>>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>> > Although it is possible that that patch is the cause of your problem,
>>>> > unfortunately it is part of a significant rework of the GIC driver in
>>>> > Xen and I am afraid that testing with only a portion of that patch
>>>> > series might introduce other subtle bugs.  For your reference the series
>>>> > starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
>>>> > commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
>>>> >
>>>>
>>>> Yes, I tested with and without the whole series.
>>>
>>> And the result is that the series causes the problem?
>>>
>>
>> Yes.
>>
>>>
>>>> > If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
>>>> > problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
>>>> > might not work correctly on your platform. It wouldn't be the first time
>>>> > that we see hardware behaving that way, especially if you are using the
>>>> > GIC secure registers instead of the non-secure register as GICH_LRn.HW
>>>> > can only deactivate non-secure interrupts. This is usually due to a
>>>> > configuration error in u-boot.
>>>> >
>>>> > Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
>>>> > platform?
>>>> >
>>>>
>>>> I tried this. Unfortunately it doesn't help.
>>>
>>> Could you try the following patch on top of
>>> 5495a512b63bad868c147198f7f049c2617d468c ?
>>>
>>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> index 302c031..a286376 100644
>>> --- a/xen/arch/arm/gic.c
>>> +++ b/xen/arch/arm/gic.c
>>> @@ -557,10 +557,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>>>      BUG_ON(lr < 0);
>>>      BUG_ON(state & ~(GICH_LR_STATE_MASK<<GICH_LR_STATE_SHIFT));
>>>
>>> -    lr_val = state | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>>> +    lr_val = state | GICH_LR_MAINTENANCE_IRQ | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>>>          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>>> -    if ( p->desc != NULL )
>>> -        lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>>>
>>>      GICH[GICH_LR + lr] = lr_val;
>>>
>>> @@ -622,6 +620,12 @@ out:
>>>      return;
>>>  }
>>>
>>> +static void gic_irq_eoi(void *info)
>>> +{
>>> +    int virq = (uintptr_t) info;
>>> +    GICC[GICC_DIR] = virq;
>>> +}
>>> +
>>>  static void gic_update_one_lr(struct vcpu *v, int i)
>>>  {
>>>      struct pending_irq *p;
>>> @@ -639,7 +643,10 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>>>          irq = (lr >> GICH_LR_VIRTUAL_SHIFT) & GICH_LR_VIRTUAL_MASK;
>>>          p = irq_to_pending(v, irq);
>>>          if ( p->desc != NULL )
>>> +        {
>>> +            gic_irq_eoi((void*)(uintptr_t)irq);
>>>              p->desc->status &= ~IRQ_INPROGRESS;
>>> +        }
>>>          clear_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
>>>          if ( test_bit(GIC_IRQ_GUEST_PENDING, &p->status) &&
>>>                  test_bit(GIC_IRQ_GUEST_ENABLED, &p->status))
>>
>>
>> It helps! Thank you a lot!
>> I did about ~30 reboots and got no hangs. The only what is needed - is
>> to rebase these changes on top of xen/master branch.
>> Changes in patch can be applied only on top of
>> 5495a512b63bad868c147198f7f049c2617d468c
>> Will you do this change? Is it acceptable for baseline?
>>
>> Regards,
>> Andrii
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 12:35:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 12: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 1Xqi0H-0007kq-QR; Tue, 18 Nov 2014 12:35:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xqi0G-0007ki-Ah
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 12:35:28 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9D/04-09842-F0D3B645; Tue, 18 Nov 2014 12:35:27 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416314124!5551137!1
X-Originating-IP: [64.18.0.24]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16698 invoked from network); 18 Nov 2014 12:35:26 -0000
Received: from exprod5og112.obsmtp.com (HELO exprod5og112.obsmtp.com)
	(64.18.0.24)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 12:35:26 -0000
Received: from mail-la0-f52.google.com ([209.85.215.52]) (using TLSv1) by
	exprod5ob112.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGs9DBQsWjWHh3BPsO9twEDtaRL7lb8d@postini.com;
	Tue, 18 Nov 2014 04:35:26 PST
Received: by mail-la0-f52.google.com with SMTP id q1so2129110lam.39
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 04:35:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Q7Vp8FfIMvWifSIl23HMEv3oeRzBqNoKGk6gQFS8t+U=;
	b=JCJ1d5OB1ouw0YMsNs1F29Oq3at8z1D/yHBhcd3DSiluSX3ST2ce86vJ0+M7Qf6TD/
	Qie3L5Wv4Su2QzQOPHIwSZrIlt9svJK7LH0CbQDRPxSrd55fUBXyvuUGqOlDCn58GP92
	VXTSgDlXjqEENQtovm7Mr7chXCdwLQK3hF0Yk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Q7Vp8FfIMvWifSIl23HMEv3oeRzBqNoKGk6gQFS8t+U=;
	b=EQi+5WhfM5BriTocCcFPNiBHx3SsZTRvHYKMr92I+u9iNHszTyqihNQlBpyeAk25y7
	0hlQQoEbkC+e+CJDRsQKIK19e+p1M2L5ebx83968NH1mZPYVbi6cJgGYnYw5KtyX0Dv4
	FhEjmL5JTYWHW5PLuBIq1ARso1i6VwJDsKzX3IDbaQ+LBlHRZ6ccjLXyGoTXYPQDF+qg
	eQgWJAPdNncQhZtmut/Lf02nBM3NRV7Ilckq2lC90HDMYE3pyFlScKYwDIKquFljAC42
	CAnZVQ1qIaYq7bdx6kqabCairySpDQyfUZ5c+w2AkaRXdksRVwiEuinbXjPxKETSTvxa
	p3bA==
X-Gm-Message-State: ALoCoQlUa/y07QnRp9NgKkktOP5R7hU6fWfr3Ws7iafgTZKV5cA+88wMoyw4IBSyZUVFo9riFq/RnBdQiqY2PXw9aZIvBV9bkVlJ2kpZVew2Y9U4g2hGbSrqJBhrG4WYJlB5al1UXPN0ktdLgNfrU1h1gWbU/w+qtA==
X-Received: by 10.153.11.133 with SMTP id ei5mr18538834lad.75.1416314122772;
	Tue, 18 Nov 2014 04:35:22 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.153.11.133 with SMTP id ei5mr18538814lad.75.1416314122647;
	Tue, 18 Nov 2014 04:35:22 -0800 (PST)
Received: by 10.112.61.69 with HTTP; Tue, 18 Nov 2014 04:35:22 -0800 (PST)
In-Reply-To: <CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411141427180.26318@kaball.uk.xensource.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
Date: Tue, 18 Nov 2014 14:35:22 +0200
Message-ID: <CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
everything works fine
The following 2 patches fixes xen/master for my platform.

Stefano, could you please take a look to these changes?

commit 3628a0aa35706a8f532af865ed784536ce514eca
Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
Date:   Tue Nov 18 14:20:42 2014 +0200

    xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag

    Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
    Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..093ecdb 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
pending_irq *p,
                                              << GICH_V2_LR_PRIORITY_SHIFT) |
               ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
GICH_V2_LR_VIRTUAL_SHIFT));

-    if ( p->desc != NULL )
+    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
     {
-        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
-            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
-        else
-            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
GICH_V2_LR_PHYSICAL_MASK )
-                            << GICH_V2_LR_PHYSICAL_SHIFT);
+        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
+    }
+    else if ( p->desc != NULL )
+    {
+        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
+                       << GICH_V2_LR_PHYSICAL_SHIFT);
     }

     writel_gich(lr_reg, GICH_LR + lr * 4);

commit 110ad1914f04a5e52ec9d49a9aeb7df488f524b1
Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
Date:   Tue Nov 18 12:14:42 2014 +0200

    xen/arm: dra7: add PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI

    Change-Id: Ic6285d5aea803fb0bfef50ffcc35e20b5bfb7a77
    Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>

diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
index 9d6e504..fb6686f 100644
--- a/xen/arch/arm/platforms/omap5.c
+++ b/xen/arch/arm/platforms/omap5.c
@@ -166,6 +166,11 @@ static const struct dt_device_match
dra7_blacklist_dev[] __initconst =
     { /* sentinel */ },
 };

+static uint32_t dra7_quirks(void)
+{
+    return PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI;
+}
+
 PLATFORM_START(omap5, "TI OMAP5")
     .compatible = omap5_dt_compat,
     .init_time = omap5_init_time,
@@ -186,6 +191,7 @@ PLATFORM_START(dra7, "TI DRA7")
     .dom0_gnttab_start = 0x4b000000,
     .dom0_gnttab_size = 0x20000,
     .blacklist_dev = dra7_blacklist_dev,
+    .quirks = dra7_quirks,
 PLATFORM_END

 /*

On Tue, Nov 18, 2014 at 1:31 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> Strange - looks like baseline code already does the same, that you
> sent me yesterday. The only what is needed - is to set
> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI.
> But baseline contains an issue. And in the same time changes on top of
> 5495a512b63bad868c147198f7f049c2617d468c work fine.
>
> Regards,
> Andrii
>
> On Tue, Nov 18, 2014 at 12:41 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
>> Hi Stefano,
>>
>> On Mon, Nov 17, 2014 at 8:02 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>>> On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
>>>> Hi Stefano,
>>>>
>>>> Thank you for your answer.
>>>>
>>>> On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
>>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>> > Although it is possible that that patch is the cause of your problem,
>>>> > unfortunately it is part of a significant rework of the GIC driver in
>>>> > Xen and I am afraid that testing with only a portion of that patch
>>>> > series might introduce other subtle bugs.  For your reference the series
>>>> > starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
>>>> > commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
>>>> >
>>>>
>>>> Yes, I tested with and without the whole series.
>>>
>>> And the result is that the series causes the problem?
>>>
>>
>> Yes.
>>
>>>
>>>> > If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
>>>> > problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
>>>> > might not work correctly on your platform. It wouldn't be the first time
>>>> > that we see hardware behaving that way, especially if you are using the
>>>> > GIC secure registers instead of the non-secure register as GICH_LRn.HW
>>>> > can only deactivate non-secure interrupts. This is usually due to a
>>>> > configuration error in u-boot.
>>>> >
>>>> > Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
>>>> > platform?
>>>> >
>>>>
>>>> I tried this. Unfortunately it doesn't help.
>>>
>>> Could you try the following patch on top of
>>> 5495a512b63bad868c147198f7f049c2617d468c ?
>>>
>>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> index 302c031..a286376 100644
>>> --- a/xen/arch/arm/gic.c
>>> +++ b/xen/arch/arm/gic.c
>>> @@ -557,10 +557,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>>>      BUG_ON(lr < 0);
>>>      BUG_ON(state & ~(GICH_LR_STATE_MASK<<GICH_LR_STATE_SHIFT));
>>>
>>> -    lr_val = state | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>>> +    lr_val = state | GICH_LR_MAINTENANCE_IRQ | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>>>          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>>> -    if ( p->desc != NULL )
>>> -        lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>>>
>>>      GICH[GICH_LR + lr] = lr_val;
>>>
>>> @@ -622,6 +620,12 @@ out:
>>>      return;
>>>  }
>>>
>>> +static void gic_irq_eoi(void *info)
>>> +{
>>> +    int virq = (uintptr_t) info;
>>> +    GICC[GICC_DIR] = virq;
>>> +}
>>> +
>>>  static void gic_update_one_lr(struct vcpu *v, int i)
>>>  {
>>>      struct pending_irq *p;
>>> @@ -639,7 +643,10 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>>>          irq = (lr >> GICH_LR_VIRTUAL_SHIFT) & GICH_LR_VIRTUAL_MASK;
>>>          p = irq_to_pending(v, irq);
>>>          if ( p->desc != NULL )
>>> +        {
>>> +            gic_irq_eoi((void*)(uintptr_t)irq);
>>>              p->desc->status &= ~IRQ_INPROGRESS;
>>> +        }
>>>          clear_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
>>>          if ( test_bit(GIC_IRQ_GUEST_PENDING, &p->status) &&
>>>                  test_bit(GIC_IRQ_GUEST_ENABLED, &p->status))
>>
>>
>> It helps! Thank you a lot!
>> I did about ~30 reboots and got no hangs. The only what is needed - is
>> to rebase these changes on top of xen/master branch.
>> Changes in patch can be applied only on top of
>> 5495a512b63bad868c147198f7f049c2617d468c
>> Will you do this change? Is it acceptable for baseline?
>>
>> Regards,
>> Andrii
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:13:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:13:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqjWv-0000OU-8y; Tue, 18 Nov 2014 14:13:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqjWt-0000OP-0j
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:13:15 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	F8/C5-25727-AF35B645; Tue, 18 Nov 2014 14:13:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416319992!12048744!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14444 invoked from network); 18 Nov 2014 14:13:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:13:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192470772"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 09:13:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqjWo-0004VC-SS;
	Tue, 18 Nov 2014 14:13:10 +0000
Date: Tue, 18 Nov 2014 14:12:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Don Slutz <dslutz@verizon.com>
In-Reply-To: <1416259239-13281-1-git-send-email-dslutz@verizon.com>
Message-ID: <alpine.DEB.2.02.1411181410440.27247@kaball.uk.xensource.com>
References: <1416259239-13281-1-git-send-email-dslutz@verizon.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, qemu-stable@nongnu.org,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Xen-devel] [BUGFIX][PATCH for 2.2 1/1] hw/ide/core.c: Prevent
 SIGSEGV during migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad,
I think we should have this fix in Xen 4.5. Should I go ahead and
backport it?

On Mon, 17 Nov 2014, Don Slutz wrote:
> The other callers to blk_set_enable_write_cache() in this file
> already check for s->blk == NULL.
> 
> Signed-off-by: Don Slutz <dslutz@verizon.com>
> ---
> 
> I think this is a bugfix that should be back ported to stable
> releases.
> 
> I also think this should be done in xen's copy of QEMU for 4.5 with
> back port(s) to active stable releases.
> 
> Note: In 2.1 and earlier the routine is
> bdrv_set_enable_write_cache(); variable is s->bs.
> 
>  hw/ide/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/ide/core.c b/hw/ide/core.c
> index 00e21cf..d4af5e2 100644
> --- a/hw/ide/core.c
> +++ b/hw/ide/core.c
> @@ -2401,7 +2401,7 @@ static int ide_drive_post_load(void *opaque, int version_id)
>  {
>      IDEState *s = opaque;
>  
> -    if (s->identify_set) {
> +    if (s->blk && s->identify_set) {
>          blk_set_enable_write_cache(s->blk, !!(s->identify_data[85] & (1 << 5)));
>      }
>      return 0;
> -- 
> 1.8.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:13:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:13:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqjWv-0000OU-8y; Tue, 18 Nov 2014 14:13:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqjWt-0000OP-0j
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:13:15 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	F8/C5-25727-AF35B645; Tue, 18 Nov 2014 14:13:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416319992!12048744!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14444 invoked from network); 18 Nov 2014 14:13:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:13:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192470772"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 09:13:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqjWo-0004VC-SS;
	Tue, 18 Nov 2014 14:13:10 +0000
Date: Tue, 18 Nov 2014 14:12:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Don Slutz <dslutz@verizon.com>
In-Reply-To: <1416259239-13281-1-git-send-email-dslutz@verizon.com>
Message-ID: <alpine.DEB.2.02.1411181410440.27247@kaball.uk.xensource.com>
References: <1416259239-13281-1-git-send-email-dslutz@verizon.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Kevin Wolf <kwolf@redhat.com>, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, qemu-stable@nongnu.org,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Xen-devel] [BUGFIX][PATCH for 2.2 1/1] hw/ide/core.c: Prevent
 SIGSEGV during migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad,
I think we should have this fix in Xen 4.5. Should I go ahead and
backport it?

On Mon, 17 Nov 2014, Don Slutz wrote:
> The other callers to blk_set_enable_write_cache() in this file
> already check for s->blk == NULL.
> 
> Signed-off-by: Don Slutz <dslutz@verizon.com>
> ---
> 
> I think this is a bugfix that should be back ported to stable
> releases.
> 
> I also think this should be done in xen's copy of QEMU for 4.5 with
> back port(s) to active stable releases.
> 
> Note: In 2.1 and earlier the routine is
> bdrv_set_enable_write_cache(); variable is s->bs.
> 
>  hw/ide/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/ide/core.c b/hw/ide/core.c
> index 00e21cf..d4af5e2 100644
> --- a/hw/ide/core.c
> +++ b/hw/ide/core.c
> @@ -2401,7 +2401,7 @@ static int ide_drive_post_load(void *opaque, int version_id)
>  {
>      IDEState *s = opaque;
>  
> -    if (s->identify_set) {
> +    if (s->blk && s->identify_set) {
>          blk_set_enable_write_cache(s->blk, !!(s->identify_data[85] & (1 << 5)));
>      }
>      return 0;
> -- 
> 1.8.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:26:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14: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.xen.org>)
	id 1XqjjT-0000bg-VY; Tue, 18 Nov 2014 14:26:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqjjT-0000bb-1K
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:26:15 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	7A/A9-07724-6075B645; Tue, 18 Nov 2014 14:26:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416320771!12113941!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20534 invoked from network); 18 Nov 2014 14:26:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:26:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="193981090"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 09:26:09 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqjjN-0004jd-BY	for
	xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:26:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqjjM-0004bM-HW	for
	xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:26:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.22271.685111.333514@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 14:26:07 +0000
To: <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-31651-mainreport@xen.org>
References: <osstest-31651-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Subject: Re: [Xen-devel] [qemu-mainline test] 31651: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[qemu-mainline test] 31651: regressions - FAIL"):
> flight 31651 qemu-mainline real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31651/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

This was the swiotlb bnx2/mptsas bug.  I have force pushed it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:26:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14: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.xen.org>)
	id 1XqjjT-0000bg-VY; Tue, 18 Nov 2014 14:26:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqjjT-0000bb-1K
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:26:15 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	7A/A9-07724-6075B645; Tue, 18 Nov 2014 14:26:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416320771!12113941!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20534 invoked from network); 18 Nov 2014 14:26:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:26:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="193981090"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 09:26:09 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqjjN-0004jd-BY	for
	xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:26:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqjjM-0004bM-HW	for
	xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:26:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.22271.685111.333514@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 14:26:07 +0000
To: <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-31651-mainreport@xen.org>
References: <osstest-31651-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Subject: Re: [Xen-devel] [qemu-mainline test] 31651: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[qemu-mainline test] 31651: regressions - FAIL"):
> flight 31651 qemu-mainline real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31651/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

This was the swiotlb bnx2/mptsas bug.  I have force pushed it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:26:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:26:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqjk9-0000eZ-Do; Tue, 18 Nov 2014 14:26:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xqjk8-0000eO-6z
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 14:26:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	04/E5-09936-F275B645; Tue, 18 Nov 2014 14:26:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416320813!13593363!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25751 invoked from network); 18 Nov 2014 14:26:54 -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;
	18 Nov 2014 14:26:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="193981419"
Message-ID: <1416320809.17982.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Tue, 18 Nov 2014 14:26:49 +0000
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li, 
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 11:41 +0000, Zhang, Yang Z wrote:
> > Hmm - this is a pitfall waiting to happen.
> > 
> > In the case that there is a heterogeneous setup with one 1G capable
> > and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
> > pages on the capable hardware.  Any VM which guesses at hardware
> > support by means other than cpuid features is liable to explode on migrate.
> 
> But a normal guest shouldn't to guess it, right?

IMHO any guest which does not use the mechanism explicitly provided for
feature detection deserves to break randomly.

It's basically equivalent to a physical system where the BIOS masks this
cpuid bit because of some hardware errata or something, the underlying
feature might appear to be present but will have more or less subtle
issues.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:26:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:26:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqjk9-0000eZ-Do; Tue, 18 Nov 2014 14:26:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xqjk8-0000eO-6z
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 14:26:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	04/E5-09936-F275B645; Tue, 18 Nov 2014 14:26:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416320813!13593363!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25751 invoked from network); 18 Nov 2014 14:26:54 -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;
	18 Nov 2014 14:26:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="193981419"
Message-ID: <1416320809.17982.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Tue, 18 Nov 2014 14:26:49 +0000
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
References: <1416201409-7462-1-git-send-email-liang.z.li@intel.com>
	<21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li, 
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 11:41 +0000, Zhang, Yang Z wrote:
> > Hmm - this is a pitfall waiting to happen.
> > 
> > In the case that there is a heterogeneous setup with one 1G capable
> > and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
> > pages on the capable hardware.  Any VM which guesses at hardware
> > support by means other than cpuid features is liable to explode on migrate.
> 
> But a normal guest shouldn't to guess it, right?

IMHO any guest which does not use the mechanism explicitly provided for
feature detection deserves to break randomly.

It's basically equivalent to a physical system where the BIOS masks this
cpuid bit because of some hardware errata or something, the underlying
feature might appear to be present but will have more or less subtle
issues.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:32:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:32:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqjov-0000vY-NU; Tue, 18 Nov 2014 14:31:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1Xqjou-0000vT-Ib
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 14:31:52 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	A0/71-28296-7585B645; Tue, 18 Nov 2014 14:31:51 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416321110!12167292!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22027 invoked from network); 18 Nov 2014 14:31:50 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:31:50 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so4109789wgh.26
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 06:31:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=GBFmSX2K4SjsxvTg+3hhi74ZgDjCI2x8yX8UwwLEF/c=;
	b=04a/fi8rgtqhyp+ZQFSm7+00kgucylqAGChZo/97Eop8CRMLeuY0FPXZBp681+zYZJ
	kzn28RBtm/B9CNTm6/ue2J7EtvB/xh3yWjkEhHiWOoSoepzXvJbUQ3lgVc5D0rUdUJvy
	+RZcvPoO8RcvC02ol5HmHl5H/Djvd1nA6Pa9Kt16b0hIXZqPz8Zv6M/KKR8oXncMofVn
	w7qx5yCKByxKtuf7Qjyj/63nuJF5JkcLyh7b8aqPova3txrPs6/4XC30WfZS8dVwKnxH
	nX0gvsmMAXRyi1ZYsKmxCewp9C+gQP6ZL7AeJHvEsmNvXrRdrfCnl/LnmsSlHyLyyN1/
	WMhw==
MIME-Version: 1.0
X-Received: by 10.180.77.79 with SMTP id q15mr4433243wiw.8.1416321110613; Tue,
	18 Nov 2014 06:31:50 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Tue, 18 Nov 2014 06:31:50 -0800 (PST)
In-Reply-To: <CAAULxKKtos6Au5mnAqbWb0fwGb1-DhGJsm9=+FBCUEHUZhLEqA@mail.gmail.com>
References: <CAAULxKKtos6Au5mnAqbWb0fwGb1-DhGJsm9=+FBCUEHUZhLEqA@mail.gmail.com>
Date: Tue, 18 Nov 2014 16:31:50 +0200
Message-ID: <CAAULxKKDakHX9Z6m-Lrw3r4x6TmHUP9tbc10Ga1HvYGepd59NQ@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] Fwd: vTPM should be detached after being destroyed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4846890570920791367=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4846890570920791367==
Content-Type: multipart/alternative; boundary=f46d04389063afa9bd050822f406

--f46d04389063afa9bd050822f406
Content-Type: text/plain; charset=UTF-8

I see that when the vTPM domain is destroyed using xl destroy the
advertised info is not removed from xenstore. I don't see a reason for
which it should remain there.

If something crashes the vTPM it must be destroyed, started again and
attached to domU using xl vtpm-attach. The problem is that because the
previous vTPM was not removed from xenstore, the new one will be seen
different in domU, instead of vtpm0 it will see both vtpm0(unusable) and
vtpm1(working).

For the moment, doing a vtpm-detach before attaching the new vtpm allows
the guest to see the correct vtpm but since vtpm0 will not be usable
anymore why not cleaning stuff on destroy?

Is there something that I miss? Also, I have some errors while running xl
destroy vtpm and maybe this affects correct cleaning:
xl -vvv destroy vtpm also warns that
backend /local/domain/...vtpm/../state wanted state 6 but it was removed. I
see from devstate_watch_callback that this error happens when it could not
find some info in the xenstore.

It is there a synchronization problem and some xenstore info is deleted too
soon and then the destroy operation fails?

After this step, the error is sent to the calling functions:
libxl_device.c:device_backend_callback: unable to remove device with path
/local/domain/...vtpm/58/0
libxl.c:devices_destroy_cb:libxl__devices_destroy failed for 58

What do you think? Is it a good ideea to detach vtpm on destroy? Should I
send a patch with the changes?

Thanks.
Emil Condrea

--f46d04389063afa9bd050822f406
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">I see that whe=
n the vTPM domain is destroyed using xl destroy the advertised info is not =
removed from xenstore. I don&#39;t see a reason for which it should remain =
there.=C2=A0<div><br></div><div>If something crashes the vTPM it must be de=
stroyed, started again and attached to domU using xl vtpm-attach. The probl=
em is that because the previous vTPM was not removed from xenstore, the new=
 one will be seen different in domU, instead of vtpm0 it will see both vtpm=
0(unusable) and vtpm1(working).</div><div><br></div><div>For the moment, do=
ing a vtpm-detach before attaching the new vtpm allows the guest to see the=
 correct vtpm but since vtpm0 will not be usable anymore why not cleaning s=
tuff on destroy?</div><div><br></div><div>Is there something that I miss? A=
lso, I have some errors while running xl destroy vtpm and maybe this affect=
s correct cleaning:</div><div>xl -vvv destroy vtpm also warns that=C2=A0</d=
iv><div>backend /local/domain/...vtpm/../state wanted state 6 but it was re=
moved. I see from devstate_watch_callback that this error happens when it c=
ould not find some info in the xenstore.=C2=A0</div><div><br></div><div>It =
is there a synchronization problem and some xenstore info is deleted too so=
on and then the destroy operation fails?</div><div><br></div><div>After thi=
s step, the error is sent to the calling functions:</div><div>libxl_device.=
c:device_backend_callback: unable to remove device with path /local/domain/=
...vtpm/58/0</div><div>libxl.c:devices_destroy_cb:libxl__devices_destroy fa=
iled for 58</div><div><br></div><div>What do you think? Is it a good ideea =
to detach vtpm on destroy? Should I send a patch with the changes?=C2=A0</d=
iv><div><br></div><div>Thanks.</div><div>Emil Condrea</div><span class=3D"H=
OEnZb"><font color=3D"#888888"><br></font></span></div>
</div><br></div>

--f46d04389063afa9bd050822f406--


--===============4846890570920791367==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4846890570920791367==--


From xen-devel-bounces@lists.xen.org Tue Nov 18 14:32:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:32:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqjov-0000vY-NU; Tue, 18 Nov 2014 14:31:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <emilcondrea@gmail.com>) id 1Xqjou-0000vT-Ib
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 14:31:52 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	A0/71-28296-7585B645; Tue, 18 Nov 2014 14:31:51 +0000
X-Env-Sender: emilcondrea@gmail.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416321110!12167292!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22027 invoked from network); 18 Nov 2014 14:31:50 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:31:50 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so4109789wgh.26
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 06:31:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=GBFmSX2K4SjsxvTg+3hhi74ZgDjCI2x8yX8UwwLEF/c=;
	b=04a/fi8rgtqhyp+ZQFSm7+00kgucylqAGChZo/97Eop8CRMLeuY0FPXZBp681+zYZJ
	kzn28RBtm/B9CNTm6/ue2J7EtvB/xh3yWjkEhHiWOoSoepzXvJbUQ3lgVc5D0rUdUJvy
	+RZcvPoO8RcvC02ol5HmHl5H/Djvd1nA6Pa9Kt16b0hIXZqPz8Zv6M/KKR8oXncMofVn
	w7qx5yCKByxKtuf7Qjyj/63nuJF5JkcLyh7b8aqPova3txrPs6/4XC30WfZS8dVwKnxH
	nX0gvsmMAXRyi1ZYsKmxCewp9C+gQP6ZL7AeJHvEsmNvXrRdrfCnl/LnmsSlHyLyyN1/
	WMhw==
MIME-Version: 1.0
X-Received: by 10.180.77.79 with SMTP id q15mr4433243wiw.8.1416321110613; Tue,
	18 Nov 2014 06:31:50 -0800 (PST)
Received: by 10.216.93.133 with HTTP; Tue, 18 Nov 2014 06:31:50 -0800 (PST)
In-Reply-To: <CAAULxKKtos6Au5mnAqbWb0fwGb1-DhGJsm9=+FBCUEHUZhLEqA@mail.gmail.com>
References: <CAAULxKKtos6Au5mnAqbWb0fwGb1-DhGJsm9=+FBCUEHUZhLEqA@mail.gmail.com>
Date: Tue, 18 Nov 2014 16:31:50 +0200
Message-ID: <CAAULxKKDakHX9Z6m-Lrw3r4x6TmHUP9tbc10Ga1HvYGepd59NQ@mail.gmail.com>
From: Emil Condrea <emilcondrea@gmail.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] Fwd: vTPM should be detached after being destroyed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4846890570920791367=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4846890570920791367==
Content-Type: multipart/alternative; boundary=f46d04389063afa9bd050822f406

--f46d04389063afa9bd050822f406
Content-Type: text/plain; charset=UTF-8

I see that when the vTPM domain is destroyed using xl destroy the
advertised info is not removed from xenstore. I don't see a reason for
which it should remain there.

If something crashes the vTPM it must be destroyed, started again and
attached to domU using xl vtpm-attach. The problem is that because the
previous vTPM was not removed from xenstore, the new one will be seen
different in domU, instead of vtpm0 it will see both vtpm0(unusable) and
vtpm1(working).

For the moment, doing a vtpm-detach before attaching the new vtpm allows
the guest to see the correct vtpm but since vtpm0 will not be usable
anymore why not cleaning stuff on destroy?

Is there something that I miss? Also, I have some errors while running xl
destroy vtpm and maybe this affects correct cleaning:
xl -vvv destroy vtpm also warns that
backend /local/domain/...vtpm/../state wanted state 6 but it was removed. I
see from devstate_watch_callback that this error happens when it could not
find some info in the xenstore.

It is there a synchronization problem and some xenstore info is deleted too
soon and then the destroy operation fails?

After this step, the error is sent to the calling functions:
libxl_device.c:device_backend_callback: unable to remove device with path
/local/domain/...vtpm/58/0
libxl.c:devices_destroy_cb:libxl__devices_destroy failed for 58

What do you think? Is it a good ideea to detach vtpm on destroy? Should I
send a patch with the changes?

Thanks.
Emil Condrea

--f46d04389063afa9bd050822f406
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">I see that whe=
n the vTPM domain is destroyed using xl destroy the advertised info is not =
removed from xenstore. I don&#39;t see a reason for which it should remain =
there.=C2=A0<div><br></div><div>If something crashes the vTPM it must be de=
stroyed, started again and attached to domU using xl vtpm-attach. The probl=
em is that because the previous vTPM was not removed from xenstore, the new=
 one will be seen different in domU, instead of vtpm0 it will see both vtpm=
0(unusable) and vtpm1(working).</div><div><br></div><div>For the moment, do=
ing a vtpm-detach before attaching the new vtpm allows the guest to see the=
 correct vtpm but since vtpm0 will not be usable anymore why not cleaning s=
tuff on destroy?</div><div><br></div><div>Is there something that I miss? A=
lso, I have some errors while running xl destroy vtpm and maybe this affect=
s correct cleaning:</div><div>xl -vvv destroy vtpm also warns that=C2=A0</d=
iv><div>backend /local/domain/...vtpm/../state wanted state 6 but it was re=
moved. I see from devstate_watch_callback that this error happens when it c=
ould not find some info in the xenstore.=C2=A0</div><div><br></div><div>It =
is there a synchronization problem and some xenstore info is deleted too so=
on and then the destroy operation fails?</div><div><br></div><div>After thi=
s step, the error is sent to the calling functions:</div><div>libxl_device.=
c:device_backend_callback: unable to remove device with path /local/domain/=
...vtpm/58/0</div><div>libxl.c:devices_destroy_cb:libxl__devices_destroy fa=
iled for 58</div><div><br></div><div>What do you think? Is it a good ideea =
to detach vtpm on destroy? Should I send a patch with the changes?=C2=A0</d=
iv><div><br></div><div>Thanks.</div><div>Emil Condrea</div><span class=3D"H=
OEnZb"><font color=3D"#888888"><br></font></span></div>
</div><br></div>

--f46d04389063afa9bd050822f406--


--===============4846890570920791367==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4846890570920791367==--


From xen-devel-bounces@lists.xen.org Tue Nov 18 14:37:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:37:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqju9-000161-MG; Tue, 18 Nov 2014 14:37:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xqju7-00015o-SS
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:37:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F8/5A-09936-B995B645; Tue, 18 Nov 2014 14:37:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416321432!10176956!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5060 invoked from network); 18 Nov 2014 14:37:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:37:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="193987554"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 09:36:44 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqjtc-0004Lg-Bb;
	Tue, 18 Nov 2014 14:36:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqjtc-00029O-2F;
	Tue, 18 Nov 2014 14:36:44 +0000
Date: Tue, 18 Nov 2014 14:36:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31652-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 12264
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.3-testing test] 31652: 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: multipart/mixed; boundary="===============9030607660038768763=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9030607660038768763==
Content-Type: text/plain
Content-Length: 12039
Content-Transfer-Encoding: quoted-printable

flight 31652 qemu-upstream-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31652/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                580b1d06aa3eed3ae9c12b4225a1ea1c192ab119
baseline version:
 qemuu                e16435c95be86244bd92c5c26579bd4298aa65a6

------------------------------------------------------------
People who touched revisions under test:
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dqemu-upstream-4.3-testing
+ revision=3D580b1d06aa3eed3ae9c12b4225a1ea1c192ab119
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-4.3-testing 580b1d06aa3eed3ae9c12b4225a1ea1c192ab119
+ branch=3Dqemu-upstream-4.3-testing
+ revision=3D580b1d06aa3eed3ae9c12b4225a1ea1c192ab119
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dqemuu
+ xenbranch=3Dxen-4.3-testing
+ '[' xqemuu =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-4.3-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.3-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-4.3-testing
++ : daily-cron.qemu-upstream-4.3-testing
++ : daily-cron.qemu-upstream-4.3-testing
++ : daily-cron.qemu-upstream-4.3-testing
++ : daily-cron.qemu-upstream-4.3-testing
++ : daily-cron.qemu-upstream-4.3-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git
++ : daily-cron.qemu-upstream-4.3-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-upstream-4.3-testing
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.3-testing.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-upstream-4.3-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-4.3-testing
+ git push osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.3-testing.git 580b1d06aa3eed3ae9c12b4225a1ea1c192ab119:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.3-testing.git
   e16435c..580b1d0  580b1d06aa3eed3ae9c12b4225a1ea1c192ab119 -> master


--===============9030607660038768763==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9030607660038768763==--

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:37:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:37:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqju9-000161-MG; Tue, 18 Nov 2014 14:37:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xqju7-00015o-SS
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:37:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F8/5A-09936-B995B645; Tue, 18 Nov 2014 14:37:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416321432!10176956!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5060 invoked from network); 18 Nov 2014 14:37:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:37:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="193987554"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 09:36:44 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqjtc-0004Lg-Bb;
	Tue, 18 Nov 2014 14:36:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqjtc-00029O-2F;
	Tue, 18 Nov 2014 14:36:44 +0000
Date: Tue, 18 Nov 2014 14:36:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31652-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 12264
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.3-testing test] 31652: 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: multipart/mixed; boundary="===============9030607660038768763=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9030607660038768763==
Content-Type: text/plain
Content-Length: 12039
Content-Transfer-Encoding: quoted-printable

flight 31652 qemu-upstream-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31652/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                580b1d06aa3eed3ae9c12b4225a1ea1c192ab119
baseline version:
 qemuu                e16435c95be86244bd92c5c26579bd4298aa65a6

------------------------------------------------------------
People who touched revisions under test:
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dqemu-upstream-4.3-testing
+ revision=3D580b1d06aa3eed3ae9c12b4225a1ea1c192ab119
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-4.3-testing 580b1d06aa3eed3ae9c12b4225a1ea1c192ab119
+ branch=3Dqemu-upstream-4.3-testing
+ revision=3D580b1d06aa3eed3ae9c12b4225a1ea1c192ab119
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dqemuu
+ xenbranch=3Dxen-4.3-testing
+ '[' xqemuu =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-4.3-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.3-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-4.3-testing
++ : daily-cron.qemu-upstream-4.3-testing
++ : daily-cron.qemu-upstream-4.3-testing
++ : daily-cron.qemu-upstream-4.3-testing
++ : daily-cron.qemu-upstream-4.3-testing
++ : daily-cron.qemu-upstream-4.3-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git
++ : daily-cron.qemu-upstream-4.3-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-upstream-4.3-testing
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.3-testing.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-upstream-4.3-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-4.3-testing
+ git push osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.3-testing.git 580b1d06aa3eed3ae9c12b4225a1ea1c192ab119:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.3-testing.git
   e16435c..580b1d0  580b1d06aa3eed3ae9c12b4225a1ea1c192ab119 -> master


--===============9030607660038768763==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9030607660038768763==--

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkDl-0001N5-F4; Tue, 18 Nov 2014 14:57:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqkDj-0001N0-NH
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:57:31 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	0E/B6-28296-B5E5B645; Tue, 18 Nov 2014 14:57:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416322647!9745943!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17194 invoked from network); 18 Nov 2014 14:57:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:57:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="193998516"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 09:57:26 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqk8w-0005IY-Ag;
	Tue, 18 Nov 2014 14:52:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqk8v-0004tZ-K3;
	Tue, 18 Nov 2014 14:52:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.23857.320533.785208@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 14:52:33 +0000
To: Wei Liu <wei.liu2@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
In-Reply-To: <20141114185656.GB20066@laptop.dumpdata.com>,
	<20141115141856.GA11070@zion.uk.xensource.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
	<20141115141856.GA11070@zion.uk.xensource.com>
	<20141114185656.GB20066@laptop.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE [and 1
	more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("Re: [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE"):
> On Fri, Nov 14, 2014 at 06:52:37PM +0000, Ian Jackson wrote:
> > The structural considerations, error handling patterns, and so on, in
> > libxl have remained undocumented.  This has been a problem during
> > recent code submissions and reviews.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Wei Liu writes ("Re: [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE"):
> Acked-by: Wei Liu <wei.liu2@citrix.com>

Thanks, pushed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkDl-0001N5-F4; Tue, 18 Nov 2014 14:57:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqkDj-0001N0-NH
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 14:57:31 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	0E/B6-28296-B5E5B645; Tue, 18 Nov 2014 14:57:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416322647!9745943!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17194 invoked from network); 18 Nov 2014 14:57:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:57:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="193998516"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 09:57:26 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqk8w-0005IY-Ag;
	Tue, 18 Nov 2014 14:52:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqk8v-0004tZ-K3;
	Tue, 18 Nov 2014 14:52:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.23857.320533.785208@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 14:52:33 +0000
To: Wei Liu <wei.liu2@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
In-Reply-To: <20141114185656.GB20066@laptop.dumpdata.com>,
	<20141115141856.GA11070@zion.uk.xensource.com>
References: <1415991161-11293-1-git-send-email-ian.jackson@eu.citrix.com>
	<20141115141856.GA11070@zion.uk.xensource.com>
	<20141114185656.GB20066@laptop.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE [and 1
	more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("Re: [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE"):
> On Fri, Nov 14, 2014 at 06:52:37PM +0000, Ian Jackson wrote:
> > The structural considerations, error handling patterns, and so on, in
> > libxl have remained undocumented.  This has been a problem during
> > recent code submissions and reviews.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Wei Liu writes ("Re: [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE"):
> Acked-by: Wei Liu <wei.liu2@citrix.com>

Thanks, pushed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:58:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkEK-0001PN-Ry; Tue, 18 Nov 2014 14:58:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqkEI-0001P4-R9
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 14:58:06 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	D0/BF-28865-E7E5B645; Tue, 18 Nov 2014 14:58:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416322681!4452838!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30621 invoked from network); 18 Nov 2014 14:58:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:58:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192492974"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 09:57:40 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqk5d-0005Ez-5u;
	Tue, 18 Nov 2014 14:49:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqk5c-0004g1-K3;
	Tue, 18 Nov 2014 14:49:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.23652.147967.731409@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 14:49:08 +0000
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1416285270-14768-1-git-send-email-cyliu@suse.com>
References: <1416285270-14768-1-git-send-email-cyliu@suse.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Chunyan Liu writes ("[PATCH v2] fix rename: xenstore not fully updated"):
> Currently libxl__domain_rename only update /local/domain/<domid>/name,
> still some places in xenstore are not updated, including:
> /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.

Thanks.  The principle is correct now and so is the broad approach.

> This patch updates /vm/<uuid>/name in xenstore, and removes the unusual
> 'domain' field under backend directory (the affected are backend/console,
> backend/vfb, backend/vkb).

I think this should be a separate patch.

> Signed-off-by: Chunyan Liu <cyliu@suse.com>
> ---
> Changes:
>   * remove unusual 'domain' field from backend dir
>   * get uuid from hypervisor rather then from xenstore
> 
>  tools/libxl/libxl.c | 23 ++++++++++++++++++-----
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..197433c 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
> +    /* update /vm/<uuid>/name */
> +    rc = libxl_domain_info(ctx, &info, domid);
> +    if (rc) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                  "fail to get domain info for domain %d", domid);
> +        goto x_fail;
> +    }

I don't think you need to log here since libxl_domain_info already
does so.  Likewise libxl__xs_write_checked.  But before deleting this,
please let's wait and see whether Wei and Ian C agree.

If you do want to add logging here, it's probably better to use use
LOG rather than LIBXL__LOG.

> +    uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
> +    vm_name_path = GCSPRINTF("/vm/%s/name", uuid);
> +    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
> +                   " to %s", new_name, vm_name_path);
> +        goto x_fail;

I don't think it is necessary to LIBXL__LOG here, since
libxl__xs_write_checked does so.  (See the doc comment in
libxl_internal.h.)

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 14:58:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 14:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkEK-0001PN-Ry; Tue, 18 Nov 2014 14:58:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqkEI-0001P4-R9
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 14:58:06 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	D0/BF-28865-E7E5B645; Tue, 18 Nov 2014 14:58:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416322681!4452838!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30621 invoked from network); 18 Nov 2014 14:58:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 14:58:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192492974"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 09:57:40 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqk5d-0005Ez-5u;
	Tue, 18 Nov 2014 14:49:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqk5c-0004g1-K3;
	Tue, 18 Nov 2014 14:49:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.23652.147967.731409@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 14:49:08 +0000
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1416285270-14768-1-git-send-email-cyliu@suse.com>
References: <1416285270-14768-1-git-send-email-cyliu@suse.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Chunyan Liu writes ("[PATCH v2] fix rename: xenstore not fully updated"):
> Currently libxl__domain_rename only update /local/domain/<domid>/name,
> still some places in xenstore are not updated, including:
> /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.

Thanks.  The principle is correct now and so is the broad approach.

> This patch updates /vm/<uuid>/name in xenstore, and removes the unusual
> 'domain' field under backend directory (the affected are backend/console,
> backend/vfb, backend/vkb).

I think this should be a separate patch.

> Signed-off-by: Chunyan Liu <cyliu@suse.com>
> ---
> Changes:
>   * remove unusual 'domain' field from backend dir
>   * get uuid from hypervisor rather then from xenstore
> 
>  tools/libxl/libxl.c | 23 ++++++++++++++++++-----
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..197433c 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
> +    /* update /vm/<uuid>/name */
> +    rc = libxl_domain_info(ctx, &info, domid);
> +    if (rc) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                  "fail to get domain info for domain %d", domid);
> +        goto x_fail;
> +    }

I don't think you need to log here since libxl_domain_info already
does so.  Likewise libxl__xs_write_checked.  But before deleting this,
please let's wait and see whether Wei and Ian C agree.

If you do want to add logging here, it's probably better to use use
LOG rather than LIBXL__LOG.

> +    uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
> +    vm_name_path = GCSPRINTF("/vm/%s/name", uuid);
> +    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
> +                   " to %s", new_name, vm_name_path);
> +        goto x_fail;

I don't think it is necessary to LIBXL__LOG here, since
libxl__xs_write_checked does so.  (See the doc comment in
libxl_internal.h.)

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:00:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkGj-0001bp-Hn; Tue, 18 Nov 2014 15:00:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqkGi-0001bf-BL
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:00:36 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	48/91-05632-31F5B645; Tue, 18 Nov 2014 15:00:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416322832!12062984!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13021 invoked from network); 18 Nov 2014 15:00:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:00:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192494221"
Message-ID: <1416322801.17982.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 18 Nov 2014 15:00:01 +0000
In-Reply-To: <21611.23652.147967.731409@mariner.uk.xensource.com>
References: <1416285270-14768-1-git-send-email-cyliu@suse.com>
	<21611.23652.147967.731409@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 14:49 +0000, Ian Jackson wrote:
> Chunyan Liu writes ("[PATCH v2] fix rename: xenstore not fully updated"):
> > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > still some places in xenstore are not updated, including:
> > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> 
> Thanks.  The principle is correct now and so is the broad approach.
> 
> > This patch updates /vm/<uuid>/name in xenstore, and removes the unusual
> > 'domain' field under backend directory (the affected are backend/console,
> > backend/vfb, backend/vkb).
> 
> I think this should be a separate patch.
> 
> > Signed-off-by: Chunyan Liu <cyliu@suse.com>
> > ---
> > Changes:
> >   * remove unusual 'domain' field from backend dir
> >   * get uuid from hypervisor rather then from xenstore
> > 
> >  tools/libxl/libxl.c | 23 ++++++++++++++++++-----
> >  1 file changed, 18 insertions(+), 5 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..197433c 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
> > +    /* update /vm/<uuid>/name */
> > +    rc = libxl_domain_info(ctx, &info, domid);
> > +    if (rc) {
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                  "fail to get domain info for domain %d", domid);
> > +        goto x_fail;
> > +    }
> 
> I don't think you need to log here since libxl_domain_info already
> does so.  Likewise libxl__xs_write_checked.  But before deleting this,
> please let's wait and see whether Wei and Ian C agree.

I'm all for removing redundant logging.

Ian

> 
> If you do want to add logging here, it's probably better to use use
> LOG rather than LIBXL__LOG.
> 
> > +    uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
> > +    vm_name_path = GCSPRINTF("/vm/%s/name", uuid);
> > +    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
> > +                   " to %s", new_name, vm_name_path);
> > +        goto x_fail;
> 
> I don't think it is necessary to LIBXL__LOG here, since
> libxl__xs_write_checked does so.  (See the doc comment in
> libxl_internal.h.)
> 
> Thanks,
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:00:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkGj-0001bp-Hn; Tue, 18 Nov 2014 15:00:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqkGi-0001bf-BL
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:00:36 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	48/91-05632-31F5B645; Tue, 18 Nov 2014 15:00:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416322832!12062984!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13021 invoked from network); 18 Nov 2014 15:00:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:00:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192494221"
Message-ID: <1416322801.17982.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 18 Nov 2014 15:00:01 +0000
In-Reply-To: <21611.23652.147967.731409@mariner.uk.xensource.com>
References: <1416285270-14768-1-git-send-email-cyliu@suse.com>
	<21611.23652.147967.731409@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 14:49 +0000, Ian Jackson wrote:
> Chunyan Liu writes ("[PATCH v2] fix rename: xenstore not fully updated"):
> > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > still some places in xenstore are not updated, including:
> > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> 
> Thanks.  The principle is correct now and so is the broad approach.
> 
> > This patch updates /vm/<uuid>/name in xenstore, and removes the unusual
> > 'domain' field under backend directory (the affected are backend/console,
> > backend/vfb, backend/vkb).
> 
> I think this should be a separate patch.
> 
> > Signed-off-by: Chunyan Liu <cyliu@suse.com>
> > ---
> > Changes:
> >   * remove unusual 'domain' field from backend dir
> >   * get uuid from hypervisor rather then from xenstore
> > 
> >  tools/libxl/libxl.c | 23 ++++++++++++++++++-----
> >  1 file changed, 18 insertions(+), 5 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f7961f6..197433c 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
> > +    /* update /vm/<uuid>/name */
> > +    rc = libxl_domain_info(ctx, &info, domid);
> > +    if (rc) {
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                  "fail to get domain info for domain %d", domid);
> > +        goto x_fail;
> > +    }
> 
> I don't think you need to log here since libxl_domain_info already
> does so.  Likewise libxl__xs_write_checked.  But before deleting this,
> please let's wait and see whether Wei and Ian C agree.

I'm all for removing redundant logging.

Ian

> 
> If you do want to add logging here, it's probably better to use use
> LOG rather than LIBXL__LOG.
> 
> > +    uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
> > +    vm_name_path = GCSPRINTF("/vm/%s/name", uuid);
> > +    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to write new name `%s'"
> > +                   " to %s", new_name, vm_name_path);
> > +        goto x_fail;
> 
> I don't think it is necessary to LIBXL__LOG here, since
> libxl__xs_write_checked does so.  (See the doc comment in
> libxl_internal.h.)
> 
> Thanks,
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:00:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:00:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkGs-0001dk-52; Tue, 18 Nov 2014 15:00:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqkGq-0001dI-Bd
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:00:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B7/A8-09936-B1F5B645; Tue, 18 Nov 2014 15:00:43 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416322842!13286367!1
X-Originating-IP: [209.85.217.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5455 invoked from network); 18 Nov 2014 15:00:43 -0000
Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com)
	(209.85.217.174)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:00:43 -0000
Received: by mail-lb0-f174.google.com with SMTP id w7so233830lbi.19
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 07:00:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=VX+grOYNxwQKdNCaDIBH+L8A+Xu0xxZbfFEKy1hH0GM=;
	b=OBNugsCW+5ki2iX+ohyMRyFDnfhdv7WDaCFdvr4KU476oXx5819a7vTnHH240WKXwC
	NYnX9DyUa3qbyRcFqNpWerVdhosK9VcDp4sekJKP3G/kjlmi1f7vxN2Qab4a+SDo3hQ5
	RWhdzhqylwixpwo6He4SKbEPHcKphjM6yxoLQbZ9il7Fbl4umPp3HwHUcwSOp4TWqts4
	Fq4i3u46O0GGDTHPtfFhdqkdzz6ZXq+4c4/+vXKMVhVvwkG2jotti64vYQjl/TOD3c/H
	QOKwgzlPoB4d1++H/akzSpiqH17mVWdTipF4Px1aryVj7L4FpOWj9m5hhG6Su8KIe6MR
	sNfg==
X-Gm-Message-State: ALoCoQmEQ0D9glJxzDclkCMxVxmMUnJa8EN0e5r26CFIUcscZeFLzdg8B+ERmcjORgnmIjdqKp5U
X-Received: by 10.152.243.37 with SMTP id wv5mr33089339lac.10.1416322841846;
	Tue, 18 Nov 2014 07:00:41 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id lu5sm9920007lac.0.2014.11.18.07.00.39
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 07:00:40 -0800 (PST)
Message-ID: <546B5F15.5060702@linaro.org>
Date: Tue, 18 Nov 2014 15:00:37 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
In-Reply-To: <54535E240200007800043DAC@mail.emea.novell.com>
Cc: ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 10/31/2014 09:02 AM, Jan Beulich wrote:
>>>> On 30.10.14 at 19:51, <julien.grall@linaro.org> wrote:
> The naming suggests that the #if really should be around just the
> gic_version field (with a dummy field in the #else case to be C89
> compatible, e.g. a zero width unnamed bitfield) and the
> corresponding #define-s above, ...

Not really related to this patch... but the way to improve it (via
extending createdomain).

I need to create an empty structure. Is the dummy field really needed?
If so, did you meant?

struct
{
   int :0;
}

The C spec declare this kind of structure as undefined. Would an empty
structure and used it be better?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:00:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:00:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkGs-0001dk-52; Tue, 18 Nov 2014 15:00:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqkGq-0001dI-Bd
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:00:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B7/A8-09936-B1F5B645; Tue, 18 Nov 2014 15:00:43 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416322842!13286367!1
X-Originating-IP: [209.85.217.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5455 invoked from network); 18 Nov 2014 15:00:43 -0000
Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com)
	(209.85.217.174)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:00:43 -0000
Received: by mail-lb0-f174.google.com with SMTP id w7so233830lbi.19
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 07:00:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=VX+grOYNxwQKdNCaDIBH+L8A+Xu0xxZbfFEKy1hH0GM=;
	b=OBNugsCW+5ki2iX+ohyMRyFDnfhdv7WDaCFdvr4KU476oXx5819a7vTnHH240WKXwC
	NYnX9DyUa3qbyRcFqNpWerVdhosK9VcDp4sekJKP3G/kjlmi1f7vxN2Qab4a+SDo3hQ5
	RWhdzhqylwixpwo6He4SKbEPHcKphjM6yxoLQbZ9il7Fbl4umPp3HwHUcwSOp4TWqts4
	Fq4i3u46O0GGDTHPtfFhdqkdzz6ZXq+4c4/+vXKMVhVvwkG2jotti64vYQjl/TOD3c/H
	QOKwgzlPoB4d1++H/akzSpiqH17mVWdTipF4Px1aryVj7L4FpOWj9m5hhG6Su8KIe6MR
	sNfg==
X-Gm-Message-State: ALoCoQmEQ0D9glJxzDclkCMxVxmMUnJa8EN0e5r26CFIUcscZeFLzdg8B+ERmcjORgnmIjdqKp5U
X-Received: by 10.152.243.37 with SMTP id wv5mr33089339lac.10.1416322841846;
	Tue, 18 Nov 2014 07:00:41 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id lu5sm9920007lac.0.2014.11.18.07.00.39
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 07:00:40 -0800 (PST)
Message-ID: <546B5F15.5060702@linaro.org>
Date: Tue, 18 Nov 2014 15:00:37 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
In-Reply-To: <54535E240200007800043DAC@mail.emea.novell.com>
Cc: ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 10/31/2014 09:02 AM, Jan Beulich wrote:
>>>> On 30.10.14 at 19:51, <julien.grall@linaro.org> wrote:
> The naming suggests that the #if really should be around just the
> gic_version field (with a dummy field in the #else case to be C89
> compatible, e.g. a zero width unnamed bitfield) and the
> corresponding #define-s above, ...

Not really related to this patch... but the way to improve it (via
extending createdomain).

I need to create an empty structure. Is the dummy field really needed?
If so, did you meant?

struct
{
   int :0;
}

The C spec declare this kind of structure as undefined. Would an empty
structure and used it be better?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:09:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15: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 1XqkPT-00020o-GG; Tue, 18 Nov 2014 15:09:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqkPR-00020j-Sw
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:09:38 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	78/80-25727-1316B645; Tue, 18 Nov 2014 15:09:37 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416323368!12214646!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28936 invoked from network); 18 Nov 2014 15:09:28 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 18 Nov 2014 15:09:28 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52560 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqkNo-0003jt-Kk; Tue, 18 Nov 2014 16:07:57 +0100
Date: Tue, 18 Nov 2014 16:09:25 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <68258140.20141118160925@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <1408328417.20141118120741@eikelenboom.it>
References: <546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0191A1230144FE1ED"
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0191A1230144FE1ED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Tuesday, November 18, 2014, 12:07:41 PM, you wrote:
> Tuesday, November 18, 2014, 3:49:27 AM, you wrote:
>> On Mon, Nov 17, 2014 at 11:40:11PM +0100, Sander Eikelenboom wrote:
>>> 
>>> Monday, November 17, 2014, 9:43:47 PM, you wrote:
>>> 

<BIG SNIP>

>>> 
>>> > I am puzzled by the driver binding twice to the same interrupt, but perhaps that
>>> > is just a buggy driver.
>>> 
>>> Doesn't that happen more often like with integrated USB controllers ?
>>>   17:          4          0          0          0          0          0  xen-pirq-ioapic-level  ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
>>>   18:       4385          0          0          0          0          0  xen-pirq-ioapic-level  ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7

>> That was my thinking too. I passed in all my USB devices that looked
>> like that to my guest but it instead of making them be on the same
>> IRQ line - QEMU put them on seperate IRQ!
>  
>> And even with that I couldn't reproduce this crash.
> Hmm I am now testing with qemu-xen-traditional, i just noticed the output at 
> guest start is different between qemu-xen-traditional and qemu-xen:

> qemu-xen-traditional gives:
> (XEN) [2014-11-18 08:46:33.409] io.c:550: d16: bind: m_gsi=87 g_gsi=36 dev=00.00.5 intx=0
> (XEN) [2014-11-18 08:46:33.798] AMD-Vi: Disable: device id = 0x800, domain = 0, paging mode = 3
> (XEN) [2014-11-18 08:46:33.798] AMD-Vi: Setup I/O page table: device id = 0x800, type = 0x1, root table = 0x3fab6a000, domain = 16, paging mode = 3
> (XEN) [2014-11-18 08:46:33.798] AMD-Vi: Re-assign 0000:08:00.0 from dom0 to dom16
> (XEN) [2014-11-18 08:46:34.917] io.c:550: d16: bind: m_gsi=86 g_gsi=40 dev=00.00.6 intx=0
> (XEN) [2014-11-18 08:46:34.923] AMD-Vi: Disable: device id = 0xa00, domain = 0, paging mode = 3
> (XEN) [2014-11-18 08:46:34.923] AMD-Vi: Setup I/O page table: device id = 0xa00, type = 0x1, root table = 0x3fab6a000, domain = 16, paging mode = 3
> (XEN) [2014-11-18 08:46:34.923] AMD-Vi: Re-assign 0000:0a:00.0 from dom0 to dom16
> and when the guest is booting it gives:
> (XEN) [2014-11-18 08:47:02.128] io.c:584: d16: unbind: m_gsi=87 g_gsi=36 dev=00:00.5 intx=0
> (XEN) [2014-11-18 08:47:02.128] io.c:684: d16 final unmap: m_irq=87 dev=00:00.5 intx=0
> (XEN) [2014-11-18 08:47:02.128] io.c:550: d16: bind: m_gsi=37 g_gsi=16 dev=00.00.0 intx=0

> with qemu-xen it only gives the first part:
> (XEN) [2014-11-18 10:51:18.481] io.c:550: d16: bind: m_gsi=37 g_gsi=36 dev=00.00.5 intx=0
> (XEN) [2014-11-18 10:51:18.889] AMD-Vi: Disable: device id = 0x800, domain = 0, paging mode = 3
> (XEN) [2014-11-18 10:51:18.889] AMD-Vi: Setup I/O page table: device id = 0x800, type = 0x1, root table = 0x5071a6000, domain = 16, paging mode = 3
> (XEN) [2014-11-18 10:51:18.889] AMD-Vi: Re-assign 0000:08:00.0 from dom0 to dom16
> (XEN) [2014-11-18 10:51:20.016] io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0
> (XEN) [2014-11-18 10:51:20.022] AMD-Vi: Disable: device id = 0xa00, domain = 0, paging mode = 3
> (XEN) [2014-11-18 10:51:20.022] AMD-Vi: Setup I/O page table: device id = 0xa00, type = 0x1, root table = 0x5071a6000, domain = 16, paging mode = 3
> (XEN) [2014-11-18 10:51:20.022] AMD-Vi: Re-assign 0000:0a:00.0 from dom0 to dom16

> Looking at the m_gsi numbers .. could it be "pci_msitranslate=1" is not working for qemu-xen and that this causes this difference in output ?


> Another strange thing i noticed with qemu-xen-traditional ..  after a while the 
> irq number in /proc/interrupts is "stuck"  .. it doesn't increase anymore
>  40:      10851          0          0          0  xen-pirq-ioapic-level  cx25821[1]
> however the device still continues to grab video ... 

> I left it running for 2 hours, of which at least 1 hour the number of irq's in /proc/interrupts did
> not change for the legacy irq 40 of the videograbber. 
> The other number of IRQ's in /proc/interrupts do keep increasing (also for the passed
> through USB device which enabled MSI-X). 
> There is no crash and no debug output or errors in xl dmesg or guest dmesg and the device was
> still working until shutdown. 
> This is not good for one's sanity .. :-)

I have to amend this one, the videograbber was still working, however it seemed 
it had some timing issues in the video stream. So it was working, but less than with qemu-xen.
I don't know if that due to the interrupt count anomaly or that it's something else related 
to qemu-xen-traditional (irrespective of the dpci-patches and this issue).

>> Anyhow I was wondering if you could send (or point me to)
>> your xen-syms file(s). I've also attached an extra debug code that
>> should give me an idea if the crash/issue shows up in certain
>> situations - when we have_two_entries to deal with on one CPU.

I have xen-syms available with your latest patch for 
both with and without the #define DIFF_LIST 1 in a tarball at:
http://www.eikelenboom.it/xen-syms.tar.gz

>> It should apply cleanly on top of the other one.

> This one included your previous debug patch, so i had to revert that one,
> than it applied cleanly, so no problem !

>> Oh, and the xen-syms  - it can be either before this patch or
>> after - it won't matter much as I will be looking at the
>> assembler code.

>> Also what version of GCC compiler are you using ?

> # gcc -v
> Using built-in specs.
> COLLECT_GCC=/usr/bin/gcc-4.7.real
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.7.2 (Debian 4.7.2-5)

> That's default Debian wheezy/stable.

>> And lastly, the code also has an #ifdef DIFF_LIST - if you
>> want to turn that on (just add #define DIFF_LIST 1 at the top of 
>> the file) - it might stop the crash. Or not  :-(

>> If it does stop the crash then I think we are looking at an
>> GCC bug - in which case the xen-syms of that build (with
>> the DIFF_LIST) would also be interesting!

> Will give this patch with and without the #define DIFF_LIST 1 a shot with qemu-xen and report back.

Well 3 results here:

Without #define DIFF_LIST 1:
1) The guest still crashes (xl-dmesg-not-defined.txt)

With #define DIFF_LIST 1:
2) Nor the guest or the host crashed (let it run for about an hour and 15 minutes), 
   but the USB XHCI driver bailed out quickly after guest boot, so there were no MSI-X interrupts anymore.
   (xl-dmesg-defined-nousb.txt, dmesg-guest-defined-nousb.txt)
3) On another boot the USB XHCI didn't bail out, after a while the host crashes. (serial.log)
   (XEN) [2014-11-18 14:53:37.364] RIP:    e008:[<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
   which resolves to:
   # addr2line -e xen-syms ffff82d08014a4de
   /usr/src/new/xen-unstable-vanilla/xen/include/xen/list.h:67
   which is:
   static inline void __list_add(struct list_head *new,
                              struct list_head *prev,
                              struct list_head *next)
    {
    next->prev = new;
    new->next = next;
    new->prev = prev;
Here ->    prev->next = new;
    }

When i look at the combination of (2) and (3), It seems it could be an 
interaction between the two passed through devices and/or different IRQ types.

So i will now test without #define DIFF_LIST 1 and not passing through the USB controller, see
if that still crashes, if it doesn't i will see if i can passthrough a device which also only uses legacy
interrupts instead of MSI / MSI-X, see if that crashes or not.

>> Thank you.
------------0191A1230144FE1ED
Content-Type: text/plain;
 name="dmesg-guest-defined-nousb.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="dmesg-guest-defined-nousb.txt"

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAg
MC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAw
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVhY2N0ClsgICAgMC4wMDAwMDBdIExp
bnV4IHZlcnNpb24gMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0eS1ub3NuZCsgKHJvb3RA
c2VjdXJpdHkpIChnY2MgdmVyc2lvbiA0LjcuMiAoRGViaWFuIDQuNy4yLTUpICkgIzEgU01Q
IFR1ZSBOb3YgMTggMDA6MzM6NDMgQ0VUIDIwMTQKWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBs
aW5lOiBCT09UX0lNQUdFPS9ib290L3ZtbGludXotMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1
cml0eS1ub3NuZCsgcm9vdD0vZGV2L3h2ZGExIHJvIGNvbnNvbGU9dHR5MSBjb25zb2xlPXR0
eVMwIG5vbW9kZXNldApbICAgIDAuMDAwMDAwXSB0c2VnOiAwMDAwMDAwMDAwClsgICAgMC4w
MDAwMDBdIGU4MjA6IEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoKWyAgICAwLjAw
MDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAw
OWZiZmZdIHVzYWJsZQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAw
MDAwMDlmYzAwLTB4MDAwMDAwMDAwMDA5ZmZmZl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0g
QklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDAwMDBmMDAwMC0weDAwMDAwMDAwMDAwZmZmZmZd
IHJlc2VydmVkClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwMDAx
MDAwMDAtMHgwMDAwMDAwMDNmN2ZkZmZmXSB1c2FibGUKWyAgICAwLjAwMDAwMF0gQklPUy1l
ODIwOiBbbWVtIDB4MDAwMDAwMDAzZjdmZTAwMC0weDAwMDAwMDAwM2Y3ZmZmZmZdIHJlc2Vy
dmVkClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwZmMwMDAwMDAt
MHgwMDAwMDAwMGZmZmZmZmZmXSByZXNlcnZlZApbICAgIDAuMDAwMDAwXSBOWCAoRXhlY3V0
ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUKWyAgICAwLjAwMDAwMF0gU01CSU9TIDIu
NCBwcmVzZW50LgpbICAgIDAuMDAwMDAwXSBETUk6IFhlbiBIVk0gZG9tVSwgQklPUyA0LjUu
MC1yYyAxMS8xOC8yMDE0ClsgICAgMC4wMDAwMDBdIEh5cGVydmlzb3IgZGV0ZWN0ZWQ6IFhl
biBIVk0KWyAgICAwLjAwMDAwMF0gWGVuIHZlcnNpb24gNC41LgpbICAgIDAuMDAwMDAwXSBY
ZW4gUGxhdGZvcm0gUENJOiBJL08gcHJvdG9jb2wgdmVyc2lvbiAxClsgICAgMC4wMDAwMDBd
IE5ldGZyb250IGFuZCB0aGUgWGVuIHBsYXRmb3JtIFBDSSBkcml2ZXIgaGF2ZSBiZWVuIGNv
bXBpbGVkIGZvciB0aGlzIGtlcm5lbDogdW5wbHVnIGVtdWxhdGVkIE5JQ3MuClsgICAgMC4w
MDAwMDBdIEJsa2Zyb250IGFuZCB0aGUgWGVuIHBsYXRmb3JtIFBDSSBkcml2ZXIgaGF2ZSBi
ZWVuIGNvbXBpbGVkIGZvciB0aGlzIGtlcm5lbDogdW5wbHVnIGVtdWxhdGVkIGRpc2tzLgpb
ICAgIDAuMDAwMDAwXSBZb3UgbWlnaHQgaGF2ZSB0byBjaGFuZ2UgdGhlIHJvb3QgZGV2aWNl
ClsgICAgMC4wMDAwMDBdIGZyb20gL2Rldi9oZFthLWRdIHRvIC9kZXYveHZkW2EtZF0KWyAg
ICAwLjAwMDAwMF0gaW4geW91ciByb290PSBrZXJuZWwgY29tbWFuZCBsaW5lIG9wdGlvbgpb
ICAgIDAuMDAwMDAwXSBIVk1PUF9wYWdldGFibGVfZHlpbmcgbm90IHN1cHBvcnRlZApbICAg
IDAuMDAwMDAwXSBlODIwOiB1cGRhdGUgW21lbSAweDAwMDAwMDAwLTB4MDAwMDBmZmZdIHVz
YWJsZSA9PT4gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHgw
MDBhMDAwMC0weDAwMGZmZmZmXSB1c2FibGUKWyAgICAwLjAwMDAwMF0gQUdQOiBObyBBR1Ag
YnJpZGdlIGZvdW5kClsgICAgMC4wMDAwMDBdIGU4MjA6IGxhc3RfcGZuID0gMHgzZjdmZSBt
YXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBNVFJSIGRlZmF1bHQg
dHlwZTogd3JpdGUtYmFjawpbICAgIDAuMDAwMDAwXSBNVFJSIGZpeGVkIHJhbmdlcyBlbmFi
bGVkOgpbICAgIDAuMDAwMDAwXSAgIDAwMDAwLTlGRkZGIHdyaXRlLWJhY2sKWyAgICAwLjAw
MDAwMF0gICBBMDAwMC1CRkZGRiB3cml0ZS1jb21iaW5pbmcKWyAgICAwLjAwMDAwMF0gICBD
MDAwMC1GRkZGRiB3cml0ZS1iYWNrClsgICAgMC4wMDAwMDBdIE1UUlIgdmFyaWFibGUgcmFu
Z2VzIGVuYWJsZWQ6ClsgICAgMC4wMDAwMDBdICAgMCBiYXNlIDAwMDBGMDAwMDAwMCBtYXNr
IEZGRkZGMDAwMDAwMCB1bmNhY2hhYmxlClsgICAgMC4wMDAwMDBdICAgMSBkaXNhYmxlZApb
ICAgIDAuMDAwMDAwXSAgIDIgZGlzYWJsZWQKWyAgICAwLjAwMDAwMF0gICAzIGRpc2FibGVk
ClsgICAgMC4wMDAwMDBdICAgNCBkaXNhYmxlZApbICAgIDAuMDAwMDAwXSAgIDUgZGlzYWJs
ZWQKWyAgICAwLjAwMDAwMF0gICA2IGRpc2FibGVkClsgICAgMC4wMDAwMDBdICAgNyBkaXNh
YmxlZApbICAgIDAuMDAwMDAwXSBUT00yOiAwMDAwMDAwNTYwMDAwMDAwIGFrYSAyMjAxNk0K
WyAgICAwLjAwMDAwMF0geDg2IFBBVCBlbmFibGVkOiBjcHUgMCwgb2xkIDB4NzA0MDYwMDA3
MDQwNiwgbmV3IDB4NzAxMDYwMDA3MDEwNgpbICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAt
dGFibGUgYXQgW21lbSAweDAwMGYwZTMwLTB4MDAwZjBlM2ZdIG1hcHBlZCBhdCBbZmZmZjg4
MDAwMDBmMGUzMF0KWyAgICAwLjAwMDAwMF0gU2Nhbm5pbmcgMSBhcmVhcyBmb3IgbG93IG1l
bW9yeSBjb3JydXB0aW9uClsgICAgMC4wMDAwMDBdIEJhc2UgbWVtb3J5IHRyYW1wb2xpbmUg
YXQgW2ZmZmY4ODAwMDAwOTkwMDBdIDk5MDAwIHNpemUgMjQ1NzYKWyAgICAwLjAwMDAwMF0g
aW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMDAwMDAwLTB4MDAwZmZmZmZdClsgICAg
MC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0gcGFnZSA0awpbICAgIDAu
MDAwMDAwXSBCUksgWzB4MDIyZmUwMDAsIDB4MDIyZmVmZmZdIFBHVEFCTEUKWyAgICAwLjAw
MDAwMF0gQlJLIFsweDAyMmZmMDAwLCAweDAyMmZmZmZmXSBQR1RBQkxFClsgICAgMC4wMDAw
MDBdIEJSSyBbMHgwMjMwMDAwMCwgMHgwMjMwMGZmZl0gUEdUQUJMRQpbICAgIDAuMDAwMDAw
XSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4M2Y0MDAwMDAtMHgzZjVmZmZmZl0KWyAg
ICAwLjAwMDAwMF0gIFttZW0gMHgzZjQwMDAwMC0weDNmNWZmZmZmXSBwYWdlIDJNClsgICAg
MC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgzYzAwMDAwMC0weDNmM2Zm
ZmZmXQpbICAgIDAuMDAwMDAwXSAgW21lbSAweDNjMDAwMDAwLTB4M2YzZmZmZmZdIHBhZ2Ug
Mk0KWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMTAwMDAw
LTB4M2JmZmZmZmZdClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAxMDAwMDAtMHgwMDFmZmZm
Zl0gcGFnZSA0awpbICAgIDAuMDAwMDAwXSAgW21lbSAweDAwMjAwMDAwLTB4M2JmZmZmZmZd
IHBhZ2UgMk0KWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDNm
NjAwMDAwLTB4M2Y3ZmRmZmZdClsgICAgMC4wMDAwMDBdICBbbWVtIDB4M2Y2MDAwMDAtMHgz
ZjdmZGZmZl0gcGFnZSA0awpbICAgIDAuMDAwMDAwXSBCUksgWzB4MDIzMDEwMDAsIDB4MDIz
MDFmZmZdIFBHVEFCTEUKWyAgICAwLjAwMDAwMF0gUkFNRElTSzogW21lbSAweDM3YzQ4MDAw
LTB4MzdlMWJmZmZdClsgICAgMC4wMDAwMDBdIEFDUEk6IEVhcmx5IHRhYmxlIGNoZWNrc3Vt
IHZlcmlmaWNhdGlvbiBkaXNhYmxlZApbICAgIDAuMDAwMDAwXSBBQ1BJOiBSU0RQIDB4MDAw
MDAwMDAwMDBGMEQ4MCAwMDAwMjQgKHYwMiBYZW4gICApClsgICAgMC4wMDAwMDBdIEFDUEk6
IFhTRFQgMHgwMDAwMDAwMEZDMDBBMTQwIDAwMDA1NCAodjAxIFhlbiAgICBIVk0gICAgICAw
MDAwMDAwMCBIVk1MIDAwMDAwMDAwKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBGQUNQIDB4MDAw
MDAwMDBGQzAwOUE3MCAwMDAwRjQgKHYwNCBYZW4gICAgSFZNICAgICAgMDAwMDAwMDAgSFZN
TCAwMDAwMDAwMCkKWyAgICAwLjAwMDAwMF0gQUNQSTogRFNEVCAweDAwMDAwMDAwRkMwMDEz
MDAgMDA4NkYwICh2MDIgWGVuICAgIEhWTSAgICAgIDAwMDAwMDAwIElOVEwgMjAxMDA1Mjgp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMHgwMDAwMDAwMEZDMDAxMkMwIDAwMDA0MApb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBBUElDIDB4MDAwMDAwMDBGQzAwOUI3MCAwMDA0NjAgKHYw
MiBYZW4gICAgSFZNICAgICAgMDAwMDAwMDAgSFZNTCAwMDAwMDAwMCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogSFBFVCAweDAwMDAwMDAwRkMwMEEwNTAgMDAwMDM4ICh2MDEgWGVuICAgIEhW
TSAgICAgIDAwMDAwMDAwIEhWTUwgMDAwMDAwMDApClsgICAgMC4wMDAwMDBdIEFDUEk6IFdB
RVQgMHgwMDAwMDAwMEZDMDBBMDkwIDAwMDAyOCAodjAxIFhlbiAgICBIVk0gICAgICAwMDAw
MDAwMCBIVk1MIDAwMDAwMDAwKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDB4MDAwMDAw
MDBGQzAwQTBDMCAwMDAwMzEgKHYwMiBYZW4gICAgSFZNICAgICAgMDAwMDAwMDAgSU5UTCAy
MDEwMDUyOCkKWyAgICAwLjAwMDAwMF0gQUNQSTogU1NEVCAweDAwMDAwMDAwRkMwMEExMDAg
MDAwMDMxICh2MDIgWGVuICAgIEhWTSAgICAgIDAwMDAwMDAwIElOVEwgMjAxMDA1MjgpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwClsgICAg
MC4wMDAwMDBdIE5vIE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZApbICAgIDAuMDAwMDAwXSBG
YWtpbmcgYSBub2RlIGF0IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAzZjdm
ZGZmZl0KWyAgICAwLjAwMDAwMF0gTk9ERV9EQVRBKDApIGFsbG9jYXRlZCBbbWVtIDB4M2Y3
ZjMwMDAtMHgzZjdmZGZmZl0KWyAgICAwLjAwMDAwMF0gIFtmZmZmZWEwMDAwMDAwMDAwLWZm
ZmZlYTAwMDBmZmZmZmZdIFBNRCAtPiBbZmZmZjg4MDAzZGUwMDAwMC1mZmZmODgwMDNlZGZm
ZmZmXSBvbiBub2RlIDAKWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6ClsgICAgMC4wMDAw
MDBdICAgRE1BICAgICAgW21lbSAweDAwMDAxMDAwLTB4MDBmZmZmZmZdClsgICAgMC4wMDAw
MDBdICAgRE1BMzIgICAgW21lbSAweDAxMDAwMDAwLTB4ZmZmZmZmZmZdClsgICAgMC4wMDAw
MDBdICAgTm9ybWFsICAgZW1wdHkKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0
IGZvciBlYWNoIG5vZGUKWyAgICAwLjAwMDAwMF0gRWFybHkgbWVtb3J5IG5vZGUgcmFuZ2Vz
ClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAwMTAwMC0weDAwMDllZmZm
XQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4MDAxMDAwMDAtMHgzZjdmZGZm
Zl0KWyAgICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAgW21lbSAweDAwMDAxMDAw
LTB4M2Y3ZmRmZmZdClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAyNTk5
OTYKWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogNjQgcGFnZXMgdXNlZCBmb3IgbWVtbWFw
ClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDIxIHBhZ2VzIHJlc2VydmVkClsgICAgMC4w
MDAwMDBdICAgRE1BIHpvbmU6IDM5OTggcGFnZXMsIExJRk8gYmF0Y2g6MApbICAgIDAuMDAw
MDAwXSAgIERNQTMyIHpvbmU6IDQwMDAgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4w
MDAwMDBdICAgRE1BMzIgem9uZTogMjU1OTk4IHBhZ2VzLCBMSUZPIGJhdGNoOjMxClsgICAg
MC4wMDAwMDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4YjAwOApbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDAwXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAyXSBl
bmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBp
Y19pZFsweDA0XSBlbmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAzXSBsYXBpY19pZFsweDA2XSBlbmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDA4XSBkaXNhYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwYV0gZGlzYWJs
ZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lk
WzB4MGNdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDA3XSBsYXBpY19pZFsweDBlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwOF0gbGFwaWNfaWRbMHgxMF0gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDldIGxhcGljX2lkWzB4MTJdIGRpc2FibGVk
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBhXSBsYXBpY19pZFsw
eDE0XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
Yl0gbGFwaWNfaWRbMHgxNl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4MGNdIGxhcGljX2lkWzB4MThdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBkXSBsYXBpY19pZFsweDFhXSBkaXNhYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwZV0gbGFwaWNfaWRbMHgx
Y10gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGZd
IGxhcGljX2lkWzB4MWVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDEwXSBsYXBpY19pZFsweDIwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxMV0gbGFwaWNfaWRbMHgyMl0gZGlzYWJsZWQpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MTJdIGxhcGljX2lkWzB4MjRd
IGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDEzXSBs
YXBpY19pZFsweDI2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgxNF0gbGFwaWNfaWRbMHgyOF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MTVdIGxhcGljX2lkWzB4MmFdIGRpc2FibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDE2XSBsYXBpY19pZFsweDJjXSBk
aXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxN10gbGFw
aWNfaWRbMHgyZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MThdIGxhcGljX2lkWzB4MzBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDE5XSBsYXBpY19pZFsweDMyXSBkaXNhYmxlZCkKWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxYV0gbGFwaWNfaWRbMHgzNF0gZGlz
YWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MWJdIGxhcGlj
X2lkWzB4MzZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDFjXSBsYXBpY19pZFsweDM4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgxZF0gbGFwaWNfaWRbMHgzYV0gZGlzYWJsZWQpClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MWVdIGxhcGljX2lkWzB4M2NdIGRpc2Fi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDFmXSBsYXBpY19p
ZFsweDNlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgyMF0gbGFwaWNfaWRbMHg0MF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MjFdIGxhcGljX2lkWzB4NDJdIGRpc2FibGVkKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDIyXSBsYXBpY19pZFsweDQ0XSBkaXNhYmxl
ZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyM10gbGFwaWNfaWRb
MHg0Nl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
MjRdIGxhcGljX2lkWzB4NDhdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDI1XSBsYXBpY19pZFsweDRhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyNl0gbGFwaWNfaWRbMHg0Y10gZGlzYWJsZWQp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MjddIGxhcGljX2lkWzB4
NGVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDI4
XSBsYXBpY19pZFsweDUwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgyOV0gbGFwaWNfaWRbMHg1Ml0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MmFdIGxhcGljX2lkWzB4NTRdIGRpc2FibGVkKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDJiXSBsYXBpY19pZFsweDU2
XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyY10g
bGFwaWNfaWRbMHg1OF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4MmRdIGxhcGljX2lkWzB4NWFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDJlXSBsYXBpY19pZFsweDVjXSBkaXNhYmxlZCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyZl0gbGFwaWNfaWRbMHg1ZV0g
ZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MzBdIGxh
cGljX2lkWzB4NjBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDMxXSBsYXBpY19pZFsweDYyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgzMl0gbGFwaWNfaWRbMHg2NF0gZGlzYWJsZWQpClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MzNdIGxhcGljX2lkWzB4NjZdIGRp
c2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDM0XSBsYXBp
Y19pZFsweDY4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgzNV0gbGFwaWNfaWRbMHg2YV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4MzZdIGxhcGljX2lkWzB4NmNdIGRpc2FibGVkKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDM3XSBsYXBpY19pZFsweDZlXSBkaXNh
YmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgzOF0gbGFwaWNf
aWRbMHg3MF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MzldIGxhcGljX2lkWzB4NzJdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDNhXSBsYXBpY19pZFsweDc0XSBkaXNhYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgzYl0gbGFwaWNfaWRbMHg3Nl0gZGlzYWJs
ZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4M2NdIGxhcGljX2lk
WzB4NzhdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDNkXSBsYXBpY19pZFsweDdhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgzZV0gbGFwaWNfaWRbMHg3Y10gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4M2ZdIGxhcGljX2lkWzB4N2VdIGRpc2FibGVk
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQwXSBsYXBpY19pZFsw
eDgwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0
MV0gbGFwaWNfaWRbMHg4Ml0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4NDJdIGxhcGljX2lkWzB4ODRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQzXSBsYXBpY19pZFsweDg2XSBkaXNhYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0NF0gbGFwaWNfaWRbMHg4
OF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NDVd
IGxhcGljX2lkWzB4OGFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDQ2XSBsYXBpY19pZFsweDhjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0N10gbGFwaWNfaWRbMHg4ZV0gZGlzYWJsZWQpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NDhdIGxhcGljX2lkWzB4OTBd
IGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQ5XSBs
YXBpY19pZFsweDkyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHg0YV0gbGFwaWNfaWRbMHg5NF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4NGJdIGxhcGljX2lkWzB4OTZdIGRpc2FibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDRjXSBsYXBpY19pZFsweDk4XSBk
aXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0ZF0gbGFw
aWNfaWRbMHg5YV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4NGVdIGxhcGljX2lkWzB4OWNdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDRmXSBsYXBpY19pZFsweDllXSBkaXNhYmxlZCkKWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1MF0gbGFwaWNfaWRbMHhhMF0gZGlz
YWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NTFdIGxhcGlj
X2lkWzB4YTJdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDUyXSBsYXBpY19pZFsweGE0XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHg1M10gbGFwaWNfaWRbMHhhNl0gZGlzYWJsZWQpClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NTRdIGxhcGljX2lkWzB4YThdIGRpc2Fi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDU1XSBsYXBpY19p
ZFsweGFhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHg1Nl0gbGFwaWNfaWRbMHhhY10gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4NTddIGxhcGljX2lkWzB4YWVdIGRpc2FibGVkKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDU4XSBsYXBpY19pZFsweGIwXSBkaXNhYmxl
ZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1OV0gbGFwaWNfaWRb
MHhiMl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
NWFdIGxhcGljX2lkWzB4YjRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDViXSBsYXBpY19pZFsweGI2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1Y10gbGFwaWNfaWRbMHhiOF0gZGlzYWJsZWQp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NWRdIGxhcGljX2lkWzB4
YmFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDVl
XSBsYXBpY19pZFsweGJjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHg1Zl0gbGFwaWNfaWRbMHhiZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4NjBdIGxhcGljX2lkWzB4YzBdIGRpc2FibGVkKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDYxXSBsYXBpY19pZFsweGMy
XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2Ml0g
bGFwaWNfaWRbMHhjNF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4NjNdIGxhcGljX2lkWzB4YzZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDY0XSBsYXBpY19pZFsweGM4XSBkaXNhYmxlZCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2NV0gbGFwaWNfaWRbMHhjYV0g
ZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NjZdIGxh
cGljX2lkWzB4Y2NdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDY3XSBsYXBpY19pZFsweGNlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHg2OF0gbGFwaWNfaWRbMHhkMF0gZGlzYWJsZWQpClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NjldIGxhcGljX2lkWzB4ZDJdIGRp
c2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDZhXSBsYXBp
Y19pZFsweGQ0XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHg2Yl0gbGFwaWNfaWRbMHhkNl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4NmNdIGxhcGljX2lkWzB4ZDhdIGRpc2FibGVkKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDZkXSBsYXBpY19pZFsweGRhXSBkaXNh
YmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2ZV0gbGFwaWNf
aWRbMHhkY10gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4NmZdIGxhcGljX2lkWzB4ZGVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDcwXSBsYXBpY19pZFsweGUwXSBkaXNhYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3MV0gbGFwaWNfaWRbMHhlMl0gZGlzYWJs
ZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NzJdIGxhcGljX2lk
WzB4ZTRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDczXSBsYXBpY19pZFsweGU2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHg3NF0gbGFwaWNfaWRbMHhlOF0gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NzVdIGxhcGljX2lkWzB4ZWFdIGRpc2FibGVk
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDc2XSBsYXBpY19pZFsw
eGVjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3
N10gbGFwaWNfaWRbMHhlZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4NzhdIGxhcGljX2lkWzB4ZjBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDc5XSBsYXBpY19pZFsweGYyXSBkaXNhYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3YV0gbGFwaWNfaWRbMHhm
NF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4N2Jd
IGxhcGljX2lkWzB4ZjZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDdjXSBsYXBpY19pZFsweGY4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3ZF0gbGFwaWNfaWRbMHhmYV0gZGlzYWJsZWQpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4N2VdIGxhcGljX2lkWzB4ZmNd
IGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDdmXSBs
YXBpY19pZFsweGZlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChp
ZFsweDAxXSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQpbICAgIDAuMDAwMDAw
XSBJT0FQSUNbMF06IGFwaWNfaWQgMSwgdmVyc2lvbiAxNywgYWRkcmVzcyAweGZlYzAwMDAw
LCBHU0kgMC00NwpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRf
U1JDX09WUiAoYnVzIDAgYnVzX2lycSA1IGdsb2JhbF9pcnEgNSBsb3cgbGV2ZWwpClsgICAg
MC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDEwIGdsb2JhbF9p
cnEgMTAgbG93IGxldmVsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVz
IDAgYnVzX2lycSAxMSBnbG9iYWxfaXJxIDExIGxvdyBsZXZlbCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE1
IHVzZWQgYnkgb3ZlcnJpZGUuClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTkgdXNlZCBieSBv
dmVycmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMTAgdXNlZCBieSBvdmVycmlkZS4K
WyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMTEgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAw
MDAwMF0gVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0
aW9uClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgaWQ6IDB4ODA4NmEyMDEgYmFzZTogMHhm
ZWQwMDAwMApbICAgIDAuMDAwMDAwXSBzbXBib290OiAxMjggUHJvY2Vzc29ycyBleGNlZWRz
IE5SX0NQVVMgbGltaXQgb2YgOApbICAgIDAuMDAwMDAwXSBzbXBib290OiBBbGxvd2luZyA4
IENQVXMsIDQgaG90cGx1ZyBDUFVzClsgICAgMC4wMDAwMDBdIGU4MjA6IFttZW0gMHgzZjgw
MDAwMC0weGZiZmZmZmZmXSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2VzClsgICAgMC4wMDAw
MDBdIEJvb3RpbmcgcGFyYXZpcnR1YWxpemVkIGtlcm5lbCBvbiBYZW4gSFZNClsgICAgMC4w
MDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo4IG5yX2NwdW1hc2tfYml0czo4IG5yX2Nw
dV9pZHM6OCBucl9ub2RlX2lkczoxClsgICAgMC4wMDAwMDBdIFBFUkNQVTogRW1iZWRkZWQg
MjkgcGFnZXMvY3B1IEBmZmZmODgwMDNmNDAwMDAwIHM3OTQ4OCByODE5MiBkMzExMDQgdTI2
MjE0NApbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzNzk0ODggcjgxOTIgZDMxMTA0IHUy
NjIxNDQgYWxsb2M9MSoyMDk3MTUyClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IFswXSAw
IDEgMiAzIDQgNSA2IDcgClsgICAgMC4wMDAwMDBdIHhlbjogUFYgc3BpbmxvY2tzIGVuYWJs
ZWQKWyAgICAwLjAwMDAwMF0gQnVpbHQgMSB6b25lbGlzdHMgaW4gTm9kZSBvcmRlciwgbW9i
aWxpdHkgZ3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczogMjU1OTExClsgICAgMC4wMDAwMDBd
IFBvbGljeSB6b25lOiBETUEzMgpbICAgIDAuMDAwMDAwXSBLZXJuZWwgY29tbWFuZCBsaW5l
OiBCT09UX0lNQUdFPS9ib290L3ZtbGludXotMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0
eS1ub3NuZCsgcm9vdD0vZGV2L3h2ZGExIHJvIGNvbnNvbGU9dHR5MSBjb25zb2xlPXR0eVMw
IG5vbW9kZXNldApbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2
IChvcmRlcjogMywgMzI3NjggYnl0ZXMpClsgICAgMC4wMDAwMDBdIEFHUDogQ2hlY2tpbmcg
YXBlcnR1cmUuLi4KWyAgICAwLjAwMDAwMF0gQUdQOiBObyBBR1AgYnJpZGdlIGZvdW5kClsg
ICAgMC4wMDAwMDBdIE1lbW9yeTogMTAwMTEyMEsvMTAzOTk4NEsgYXZhaWxhYmxlICgxMDkz
Nksga2VybmVsIGNvZGUsIDg4NksgcndkYXRhLCAzNDk2SyByb2RhdGEsIDEwNDhLIGluaXQs
IDEwNzZLIGJzcywgMzg4NjRLIHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSBTTFVCOiBIV2Fs
aWduPTY0LCBPcmRlcj0wLTMsIE1pbk9iamVjdHM9MCwgQ1BVcz04LCBOb2Rlcz0xClsgICAg
MC4wMDAwMDBdIEhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uClsgICAgMC4wMDAw
MDBdIAlSQ1UgZHludGljay1pZGxlIGdyYWNlLXBlcmlvZCBhY2NlbGVyYXRpb24gaXMgZW5h
YmxlZC4KWyAgICAwLjAwMDAwMF0gTlJfSVJRUzo0MzUyIG5yX2lycXM6ODk2IDAKWyAgICAw
LjAwMDAwMF0geGVuOmV2ZW50czogVXNpbmcgRklGTy1iYXNlZCBBQkkKWyAgICAwLjAwMDAw
MF0geGVuOmV2ZW50czogWGVuIEhWTSBjYWxsYmFjayB2ZWN0b3IgZm9yIGV2ZW50IGRlbGl2
ZXJ5IGlzIGVuYWJsZWQKWyAgICAwLjAwMDAwMF0gQ29uc29sZTogY29sb3VyIFZHQSsgODB4
MjUKWyAgICAwLjAwMDAwMF0gY29uc29sZSBbdHR5MV0gZW5hYmxlZApbICAgIDAuMDAwMDAw
XSBjb25zb2xlIFt0dHlTMF0gZW5hYmxlZApbICAgIDAuMDAwMDAwXSBocGV0IGNsb2NrZXZl
bnQgcmVnaXN0ZXJlZApbICAgIDAuMDAwMDAwXSB0c2M6IERldGVjdGVkIDMyMDAuMTcyIE1I
eiBwcm9jZXNzb3IKWyAgICAwLjAwMDAwMF0gdHNjOiBNYXJraW5nIFRTQyB1bnN0YWJsZSBk
dWUgdG8gVFNDcyB1bnN5bmNocm9uaXplZApbICAgIDAuMDI5OTk5XSBDYWxpYnJhdGluZyBk
ZWxheSBsb29wIChza2lwcGVkKSwgdmFsdWUgY2FsY3VsYXRlZCB1c2luZyB0aW1lciBmcmVx
dWVuY3kuLiA2NDAyLjAyIEJvZ29NSVBTIChscGo9MTA2NjcyNDApClsgICAgMC4wNTY2NzBd
IHBpZF9tYXg6IGRlZmF1bHQ6IDMyNzY4IG1pbmltdW06IDMwMQpbICAgIDAuMDcwMDE0XSBB
Q1BJOiBDb3JlIHJldmlzaW9uIDIwMTQwOTI2ClsgICAgMC4wOTA2NzhdIEFDUEk6IEFsbCBB
Q1BJIFRhYmxlcyBzdWNjZXNzZnVsbHkgYWNxdWlyZWQKWyAgICAwLjEwNTU1Ml0gRGVudHJ5
IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjogOCwgMTA0ODU3NiBi
eXRlcykKWyAgICAwLjEyMzYyMF0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2
NTUzNiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykKWyAgICAwLjE0MDEzOV0gTW91bnQtY2Fj
aGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChvcmRlcjogMiwgMTYzODQgYnl0ZXMpClsg
ICAgMC4xNjAwMTBdIE1vdW50cG9pbnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4
IChvcmRlcjogMiwgMTYzODQgYnl0ZXMpClsgICAgMC4xODAxNzBdIEluaXRpYWxpemluZyBj
Z3JvdXAgc3Vic3lzIGZyZWV6ZXIKWyAgICAwLjE5MzM0Ml0gSW5pdGlhbGl6aW5nIGNncm91
cCBzdWJzeXMgYmxraW8KWyAgICAwLjIwNjg0Ml0gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3Ig
SUQ6IDAKWyAgICAwLjIxNjY3Ml0gQ1BVOiBQcm9jZXNzb3IgQ29yZSBJRDogMApbICAgIDAu
MjI2NjczXSBtY2U6IENQVSBzdXBwb3J0cyAyIE1DRSBiYW5rcwpbICAgIDAuMjQwMDI2XSBM
YXN0IGxldmVsIGlUTEIgZW50cmllczogNEtCIDUxMiwgMk1CIDE2LCA0TUIgOApbICAgIDAu
MjQwMDI2XSBMYXN0IGxldmVsIGRUTEIgZW50cmllczogNEtCIDUxMiwgMk1CIDEyOCwgNE1C
IDY0LCAxR0IgMApbICAgIDAuMjcwMjk4XSBGcmVlaW5nIFNNUCBhbHRlcm5hdGl2ZXMgbWVt
b3J5OiA0MEsgKGZmZmZmZmZmODIxZTUwMDAgLSBmZmZmZmZmZjgyMWVmMDAwKQpbICAgIDAu
MzAwMzQzXSAuLlRJTUVSOiB2ZWN0b3I9MHgzMCBhcGljMT0wIHBpbjE9MiBhcGljMj0wIHBp
bjI9MApbICAgIDAuMzQ5OTk5XSBzbXBib290OiBDUFUwOiBBTUQgUGhlbm9tKHRtKSBJSSBY
NiAxMDkwVCBQcm9jZXNzb3IgKGZhbTogMTAsIG1vZGVsOiAwYSwgc3RlcHBpbmc6IDAwKQpb
ICAgIDAuMzczMzUxXSBYZW46IHVzaW5nIHZjcHVvcCB0aW1lciBpbnRlcmZhY2UKWyAgICAw
LjM3MzM2NF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAwClsgICAgMC4zODY3NzJd
IGNwdSAwIHNwaW5sb2NrIGV2ZW50IGlycSA1MwpbICAgIDAuMzk4MTcxXSBQZXJmb3JtYW5j
ZSBFdmVudHM6IEJyb2tlbiBQTVUgaGFyZHdhcmUgZGV0ZWN0ZWQsIHVzaW5nIHNvZnR3YXJl
IGV2ZW50cyBvbmx5LgpbICAgIDAuNDAzMzQyXSBGYWlsZWQgdG8gYWNjZXNzIHBlcmZjdHIg
bXNyIChNU1IgYzAwMTAwMDQgaXMgMCkKWyAgICAwLjQwNjk2N10gaW5zdGFsbGluZyBYZW4g
dGltZXIgZm9yIENQVSAxClsgICAgMC40MTAwNzldIHg4NjogQm9vdGluZyBTTVAgY29uZmln
dXJhdGlvbjoKWyAgICAwLjQxMzM0MV0gLi4uLiBub2RlICAjMCwgQ1BVczogICAgICAjMWNw
dSAxIHNwaW5sb2NrIGV2ZW50IGlycSA1OQpbICAgIDAuNTE2ODAyXSBpbnN0YWxsaW5nIFhl
biB0aW1lciBmb3IgQ1BVIDIKWyAgICAwLjUyMDA2Nl0gICMyY3B1IDIgc3BpbmxvY2sgZXZl
bnQgaXJxIDY1ClsgICAgMC42MjM0NTFdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUg
MwpbICAgIDAuNjI2NzM0XSAgIzNjcHUgMyBzcGlubG9jayBldmVudCBpcnEgNzEKWyAgICAw
LjcyNjcwMV0geDg2OiBCb290ZWQgdXAgMSBub2RlLCA0IENQVXMKWyAgICAwLjczMDAxMF0g
c21wYm9vdDogVG90YWwgb2YgNCBwcm9jZXNzb3JzIGFjdGl2YXRlZCAoMjU2MzIuMzIgQm9n
b01JUFMpClsgICAgMC43MzY4MDNdIGRldnRtcGZzOiBpbml0aWFsaXplZApbICAgIDAuNzQw
Mjg2XSB4b3I6IG1lYXN1cmluZyBzb2Z0d2FyZSBjaGVja3N1bSBzcGVlZApbICAgIDAuNzc2
Njc0XSAgICBwcmVmZXRjaDY0LXNzZTogICA4MjQuNDAwIE1CL3NlYwpbICAgIDAuODEzMzM5
XSAgICBnZW5lcmljX3NzZTogICA4MzcuNjAwIE1CL3NlYwpbICAgIDAuODE2Njc1XSB4b3I6
IHVzaW5nIGZ1bmN0aW9uOiBnZW5lcmljX3NzZSAoODM3LjYwMCBNQi9zZWMpClsgICAgMC44
MjAxMjFdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKWyAgICAwLjgyMzUx
NF0geGVuYnVzOiB4c19yZXNldF93YXRjaGVzIGZhaWxlZDogLTM4ClsgICAgMC44NDY3MTdd
IGNwdWlkbGU6IHVzaW5nIGdvdmVybm9yIGxhZGRlcgpbICAgIDAuODc2Njc1XSBjcHVpZGxl
OiB1c2luZyBnb3Zlcm5vciBtZW51ClsgICAgMC44OTI2NjVdIEFDUEk6IGJ1cyB0eXBlIFBD
SSByZWdpc3RlcmVkClsgICAgMC45MDMzNDRdIGFjcGlwaHA6IEFDUEkgSG90IFBsdWcgUENJ
IENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246IDAuNQpbICAgIDAuOTIwNjMwXSBQQ0k6IFVz
aW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBiYXNlIGFjY2VzcwpbICAgIDAuOTMzMzQw
XSBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBleHRlbmRlZCBhY2Nlc3MK
WyAgICAxLjAyMzM1MV0gcmFpZDY6IHNzZTJ4MSAgICAyNjM5IE1CL3MKWyAgICAxLjA4MzM0
NF0gcmFpZDY6IHNzZTJ4MiAgICAzNjU4IE1CL3MKWyAgICAxLjE0MzM1Nl0gcmFpZDY6IHNz
ZTJ4NCAgICAzNjY0IE1CL3MKWyAgICAxLjE0NjY3N10gcmFpZDY6IHVzaW5nIGFsZ29yaXRo
bSBzc2UyeDQgKDM2NjQgTUIvcykKWyAgICAxLjE1MDAxMF0gcmFpZDY6IHVzaW5nIGludHgx
IHJlY292ZXJ5IGFsZ29yaXRobQpbICAgIDEuMTUzNDEyXSBBQ1BJOiBBZGRlZCBfT1NJKE1v
ZHVsZSBEZXZpY2UpClsgICAgMS4xNTY2OTFdIEFDUEk6IEFkZGVkIF9PU0koUHJvY2Vzc29y
IERldmljZSkKWyAgICAxLjE2MDAwOV0gQUNQSTogQWRkZWQgX09TSSgzLjAgX1NDUCBFeHRl
bnNpb25zKQpbICAgIDEuMTYzMzQyXSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBBZ2dy
ZWdhdG9yIERldmljZSkKWyAgICAxLjE3NzYwNl0gQUNQSTogSW50ZXJwcmV0ZXIgZW5hYmxl
ZApbICAgIDEuMTgwMDEwXSBBQ1BJOiAoc3VwcG9ydHMgUzAgUzUpClsgICAgMS4xODMzNDJd
IEFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0IHJvdXRpbmcKWyAgICAxLjE4Njcy
NF0gUENJOiBVc2luZyBob3N0IGJyaWRnZSB3aW5kb3dzIGZyb20gQUNQSTsgaWYgbmVjZXNz
YXJ5LCB1c2UgInBjaT1ub2NycyIgYW5kIHJlcG9ydCBhIGJ1ZwpbICAgIDEuMjE0MTExXSBB
Q1BJOiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkK
WyAgICAxLjIxNjY5NF0gYWNwaSBQTlAwQTAzOjAwOiBfT1NDOiBPUyBzdXBwb3J0cyBbRXh0
ZW5kZWRDb25maWcgQVNQTSBDbG9ja1BNIFNlZ21lbnRzIE1TSV0KWyAgICAxLjIyMDAyOV0g
YWNwaSBQTlAwQTAzOjAwOiBfT1NDIGZhaWxlZCAoQUVfTk9UX0ZPVU5EKTsgZGlzYWJsaW5n
IEFTUE0KWyAgICAxLjIyNDI5MF0gYWNwaXBocDogU2xvdCBbM10gcmVnaXN0ZXJlZApbICAg
IDEuMjI2Nzk4XSBhY3BpcGhwOiBTbG90IFs0XSByZWdpc3RlcmVkClsgICAgMS4yMzAxODdd
IGFjcGlwaHA6IFNsb3QgWzVdIHJlZ2lzdGVyZWQKWyAgICAxLjIzMzQ1NV0gYWNwaXBocDog
U2xvdCBbNl0gcmVnaXN0ZXJlZApbICAgIDEuMjM2ODA1XSBhY3BpcGhwOiBTbG90IFs3XSBy
ZWdpc3RlcmVkClsgICAgMS4yNDAxNTZdIGFjcGlwaHA6IFNsb3QgWzhdIHJlZ2lzdGVyZWQK
WyAgICAxLjI0MzQ0MV0gYWNwaXBocDogU2xvdCBbOV0gcmVnaXN0ZXJlZApbICAgIDEuMjQ2
NzgyXSBhY3BpcGhwOiBTbG90IFsxMF0gcmVnaXN0ZXJlZApbICAgIDEuMjUwMTI1XSBhY3Bp
cGhwOiBTbG90IFsxMV0gcmVnaXN0ZXJlZApbICAgIDEuMjUzNDM1XSBhY3BpcGhwOiBTbG90
IFsxMl0gcmVnaXN0ZXJlZApbICAgIDEuMjU2ODExXSBhY3BpcGhwOiBTbG90IFsxM10gcmVn
aXN0ZXJlZApbICAgIDEuMjYwMTI1XSBhY3BpcGhwOiBTbG90IFsxNF0gcmVnaXN0ZXJlZApb
ICAgIDEuMjYzNDU2XSBhY3BpcGhwOiBTbG90IFsxNV0gcmVnaXN0ZXJlZApbICAgIDEuMjY2
NzkyXSBhY3BpcGhwOiBTbG90IFsxNl0gcmVnaXN0ZXJlZApbICAgIDEuMjcwMTI3XSBhY3Bp
cGhwOiBTbG90IFsxN10gcmVnaXN0ZXJlZApbICAgIDEuMjczNDQzXSBhY3BpcGhwOiBTbG90
IFsxOF0gcmVnaXN0ZXJlZApbICAgIDEuMjc2ODI0XSBhY3BpcGhwOiBTbG90IFsxOV0gcmVn
aXN0ZXJlZApbICAgIDEuMjgwMTI4XSBhY3BpcGhwOiBTbG90IFsyMF0gcmVnaXN0ZXJlZApb
ICAgIDEuMjgzNDY5XSBhY3BpcGhwOiBTbG90IFsyMV0gcmVnaXN0ZXJlZApbICAgIDEuMjg2
ODE3XSBhY3BpcGhwOiBTbG90IFsyMl0gcmVnaXN0ZXJlZApbICAgIDEuMjkwMTA5XSBhY3Bp
cGhwOiBTbG90IFsyM10gcmVnaXN0ZXJlZApbICAgIDEuMjkzNDQ1XSBhY3BpcGhwOiBTbG90
IFsyNF0gcmVnaXN0ZXJlZApbICAgIDEuMjk2Nzg5XSBhY3BpcGhwOiBTbG90IFsyNV0gcmVn
aXN0ZXJlZApbICAgIDEuMzAwMTM2XSBhY3BpcGhwOiBTbG90IFsyNl0gcmVnaXN0ZXJlZApb
ICAgIDEuMzAzNTM1XSBhY3BpcGhwOiBTbG90IFsyN10gcmVnaXN0ZXJlZApbICAgIDEuMzA2
ODgwXSBhY3BpcGhwOiBTbG90IFsyOF0gcmVnaXN0ZXJlZApbICAgIDEuMzEwMTQ5XSBhY3Bp
cGhwOiBTbG90IFsyOV0gcmVnaXN0ZXJlZApbICAgIDEuMzEzNDMzXSBhY3BpcGhwOiBTbG90
IFszMF0gcmVnaXN0ZXJlZApbICAgIDEuMzE2Nzc0XSBhY3BpcGhwOiBTbG90IFszMV0gcmVn
aXN0ZXJlZApbICAgIDEuMzIwMDg5XSBQQ0kgaG9zdCBicmlkZ2UgdG8gYnVzIDAwMDA6MDAK
WyAgICAxLjMyMzM0Ml0gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbYnVz
IDAwLWZmXQpbICAgIDEuMzI2Njc3XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291
cmNlIFtpbyAgMHgwMDAwLTB4MGNmN10KWyAgICAxLjMzMDAxMV0gcGNpX2J1cyAwMDAwOjAw
OiByb290IGJ1cyByZXNvdXJjZSBbaW8gIDB4MGQwMC0weGZmZmZdClsgICAgMS4zMzMzNDFd
IHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW21lbSAweDAwMGEwMDAwLTB4
MDAwYmZmZmZdClsgICAgMS4zMzY2NzddIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVz
b3VyY2UgW21lbSAweGYwMDAwMDAwLTB4ZmJmZmZmZmZdClsgICAgMS4zNDAzMjZdIHBjaSAw
MDAwOjAwOjAwLjA6IFs4MDg2OjEyMzddIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAKWyAgICAx
LjM0NDgzNl0gcGNpIDAwMDA6MDA6MDEuMDogWzgwODY6NzAwMF0gdHlwZSAwMCBjbGFzcyAw
eDA2MDEwMApbICAgIDEuMzQ4NjMwXSBwY2kgMDAwMDowMDowMS4xOiBbODA4Njo3MDEwXSB0
eXBlIDAwIGNsYXNzIDB4MDEwMTgwClsgICAgMS4zNjU2MzldIHBjaSAwMDAwOjAwOjAxLjE6
IHJlZyAweDIwOiBbaW8gIDB4YzE2MC0weGMxNmZdClsgICAgMS4zNzI0ODRdIHBjaSAwMDAw
OjAwOjAxLjE6IGxlZ2FjeSBJREUgcXVpcms6IHJlZyAweDEwOiBbaW8gIDB4MDFmMC0weDAx
ZjddClsgICAgMS4zNzMzMzldIHBjaSAwMDAwOjAwOjAxLjE6IGxlZ2FjeSBJREUgcXVpcms6
IHJlZyAweDE0OiBbaW8gIDB4MDNmNl0KWyAgICAxLjM3NjY3NF0gcGNpIDAwMDA6MDA6MDEu
MTogbGVnYWN5IElERSBxdWlyazogcmVnIDB4MTg6IFtpbyAgMHgwMTcwLTB4MDE3N10KWyAg
ICAxLjM4MDAxMF0gcGNpIDAwMDA6MDA6MDEuMTogbGVnYWN5IElERSBxdWlyazogcmVnIDB4
MWM6IFtpbyAgMHgwMzc2XQpbICAgIDEuMzg0MjY2XSBwY2kgMDAwMDowMDowMS4yOiBbODA4
Njo3MDIwXSB0eXBlIDAwIGNsYXNzIDB4MGMwMzAwClsgICAgMS40MDAwMTJdIHBjaSAwMDAw
OjAwOjAxLjI6IHJlZyAweDIwOiBbaW8gIDB4YzE0MC0weGMxNWZdClsgICAgMS40MDc4Mjld
IHBjaSAwMDAwOjAwOjAxLjM6IFs4MDg2OjcxMTNdIHR5cGUgMDAgY2xhc3MgMHgwNjgwMDAK
WyAgICAxLjQxMTIyOV0gcGNpIDAwMDA6MDA6MDEuMzogcXVpcms6IFtpbyAgMHhiMDAwLTB4
YjAzZl0gY2xhaW1lZCBieSBQSUlYNCBBQ1BJClsgICAgMS40MTM0OTVdIHBjaSAwMDAwOjAw
OjAxLjM6IHF1aXJrOiBbaW8gIDB4YjEwMC0weGIxMGZdIGNsYWltZWQgYnkgUElJWDQgU01C
ClsgICAgMS40MTgyMDldIHBjaSAwMDAwOjAwOjAyLjA6IFs1ODUzOjAwMDFdIHR5cGUgMDAg
Y2xhc3MgMHhmZjgwMDAKWyAgICAxLjQyMzM2OF0gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDB4
MTA6IFtpbyAgMHhjMDAwLTB4YzBmZl0KWyAgICAxLjQzMDAwN10gcGNpIDAwMDA6MDA6MDIu
MDogcmVnIDB4MTQ6IFttZW0gMHhmMjAwMDAwMC0weGYyZmZmZmZmIHByZWZdClsgICAgMS40
NjQ1NTRdIHBjaSAwMDAwOjAwOjAzLjA6IFsxMDEzOjAwYjhdIHR5cGUgMDAgY2xhc3MgMHgw
MzAwMDAKWyAgICAxLjQ3MDAzNF0gcGNpIDAwMDA6MDA6MDMuMDogcmVnIDB4MTA6IFttZW0g
MHhmMDAwMDAwMC0weGYxZmZmZmZmIHByZWZdClsgICAgMS40NzY3MDBdIHBjaSAwMDAwOjAw
OjAzLjA6IHJlZyAweDE0OiBbbWVtIDB4ZjMyNzIwMDAtMHhmMzI3MmZmZl0KWyAgICAxLjUx
MDAzOF0gcGNpIDAwMDA6MDA6MDMuMDogcmVnIDB4MzA6IFttZW0gMHhmMzI2MDAwMC0weGYz
MjZmZmZmIHByZWZdClsgICAgMS41MTIwMzBdIHBjaSAwMDAwOjAwOjA1LjA6IFsxMDMzOjAx
OTRdIHR5cGUgMDAgY2xhc3MgMHgwYzAzMzAKWyAgICAxLjUyMDAyMl0gcGNpIDAwMDA6MDA6
MDUuMDogcmVnIDB4MTA6IFttZW0gMHhmMzI3MDAwMC0weGYzMjcxZmZmIDY0Yml0XQpbICAg
IDEuNTU4MjQyXSBwY2kgMDAwMDowMDowNi4wOiBbMTRmMTo4MjEwXSB0eXBlIDAwIGNsYXNz
IDB4MDQwMDAwClsgICAgMS41NjMzNzddIHBjaSAwMDAwOjAwOjA2LjA6IHJlZyAweDEwOiBb
bWVtIDB4ZjMwMDAwMDAtMHhmMzFmZmZmZiA2NGJpdF0KWyAgICAxLjYwMTE0Ml0gcGNpIDAw
MDA6MDA6MDYuMDogc3VwcG9ydHMgRDEgRDIKWyAgICAxLjYwNDg3M10gQUNQSTogUENJIElu
dGVycnVwdCBMaW5rIFtMTktBXSAoSVJRcyAqNSAxMCAxMSkKWyAgICAxLjYxMzc4NV0gQUNQ
STogUENJIEludGVycnVwdCBMaW5rIFtMTktCXSAoSVJRcyA1ICoxMCAxMSkKWyAgICAxLjYy
MzgxNl0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyA1IDEwICoxMSkK
WyAgICAxLjYzMzgxMF0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyAq
NSAxMCAxMSkKWyAgICAxLjY0NzUyNV0gQUNQSTogRW5hYmxlZCAyIEdQRXMgaW4gYmxvY2sg
MDAgdG8gMEYKWyAgICAxLjY1MDA4M10geGVuOmJhbGxvb246IEluaXRpYWxpc2luZyBiYWxs
b29uIGRyaXZlcgpbICAgIDEuNjU2NzE3XSB4ZW5fYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJh
bGxvb24gZHJpdmVyClsgICAgMS42NzAxNzldIHZnYWFyYjogc2V0dGluZyBhcyBib290IGRl
dmljZTogUENJOjAwMDA6MDA6MDMuMApbICAgIDEuNjczMzMzXSB2Z2FhcmI6IGRldmljZSBh
ZGRlZDogUENJOjAwMDA6MDA6MDMuMCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nr
cz1ub25lClsgICAgMS42NzMzNDRdIHZnYWFyYjogbG9hZGVkClsgICAgMS42NzY2NzddIHZn
YWFyYjogYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowMDowMy4wClsgICAgMS42ODAx
MTVdIFNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkClsgICAgMS42ODMzNzRdIGxpYmF0YSB2
ZXJzaW9uIDMuMDAgbG9hZGVkLgpbICAgIDEuNjgzNDI2XSBBQ1BJOiBidXMgdHlwZSBVU0Ig
cmVnaXN0ZXJlZApbICAgIDEuNjg2NzIzXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRl
cmZhY2UgZHJpdmVyIHVzYmZzClsgICAgMS42OTAwMzRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGludGVyZmFjZSBkcml2ZXIgaHViClsgICAgMS42OTMzOTZdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGRldmljZSBkcml2ZXIgdXNiClsgICAgMS42OTY3MjhdIExpbnV4IHZpZGVv
IGNhcHR1cmUgaW50ZXJmYWNlOiB2Mi4wMApbICAgIDEuNzAwMDQwXSBwcHNfY29yZTogTGlu
dXhQUFMgQVBJIHZlci4gMSByZWdpc3RlcmVkClsgICAgMS43MDMzNDJdIHBwc19jb3JlOiBT
b2Z0d2FyZSB2ZXIuIDUuMy42IC0gQ29weXJpZ2h0IDIwMDUtMjAwNyBSb2RvbGZvIEdpb21l
dHRpIDxnaW9tZXR0aUBsaW51eC5pdD4KWyAgICAxLjcwNjY5M10gUFRQIGNsb2NrIHN1cHBv
cnQgcmVnaXN0ZXJlZApbICAgIDEuNzEwMDcwXSBBZHZhbmNlZCBMaW51eCBTb3VuZCBBcmNo
aXRlY3R1cmUgRHJpdmVyIEluaXRpYWxpemVkLgpbICAgIDEuNzEzMzQ2XSBQQ0k6IFVzaW5n
IEFDUEkgZm9yIElSUSByb3V0aW5nClsgICAgMS43MTY2NzddIFBDSTogcGNpX2NhY2hlX2xp
bmVfc2l6ZSBzZXQgdG8gNjQgYnl0ZXMKWyAgICAxLjcxODAxMV0gZTgyMDogcmVzZXJ2ZSBS
QU0gYnVmZmVyIFttZW0gMHgwMDA5ZmMwMC0weDAwMDlmZmZmXQpbICAgIDEuNzE4MDE0XSBl
ODIwOiByZXNlcnZlIFJBTSBidWZmZXIgW21lbSAweDNmN2ZlMDAwLTB4M2ZmZmZmZmZdClsg
ICAgMS43MTgxNjddIEJsdWV0b290aDogQ29yZSB2ZXIgMi4xOQpbICAgIDEuNzIwMDI4XSBO
RVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDMxClsgICAgMS43MjMzNDJdIEJsdWV0
b290aDogSENJIGRldmljZSBhbmQgY29ubmVjdGlvbiBtYW5hZ2VyIGluaXRpYWxpemVkClsg
ICAgMS43MjY2OTZdIEJsdWV0b290aDogSENJIHNvY2tldCBsYXllciBpbml0aWFsaXplZApb
ICAgIDEuNzMwMDMyXSBCbHVldG9vdGg6IEwyQ0FQIHNvY2tldCBsYXllciBpbml0aWFsaXpl
ZApbICAgIDEuNzMzMzYzXSBCbHVldG9vdGg6IFNDTyBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6
ZWQKWyAgICAxLjczNjc3NF0gSFBFVDogMyB0aW1lcnMgaW4gdG90YWwsIDAgdGltZXJzIHdp
bGwgYmUgdXNlZCBmb3IgcGVyLWNwdSB0aW1lcgpbICAgIDEuNzQwMDIyXSBocGV0MDogYXQg
TU1JTyAweGZlZDAwMDAwLCBJUlFzIDIsIDgsIDAKWyAgICAxLjc1MDAwNV0gaHBldDA6IDMg
Y29tcGFyYXRvcnMsIDY0LWJpdCA2Mi41MDAwMDAgTUh6IGNvdW50ZXIKWyAgICAxLjc1NTQx
M10gU3dpdGNoZWQgdG8gY2xvY2tzb3VyY2UgeGVuClsgICAgMS43NjQ0NjZdIEZTLUNhY2hl
OiBMb2FkZWQKWyAgICAxLjc3Mjk3MV0gcG5wOiBQblAgQUNQSSBpbml0ClsgICAgMS43ODI0
NzFdIHN5c3RlbSAwMDowMDogW21lbSAweDAwMDAwMDAwLTB4MDAwOWZmZmZdIGNvdWxkIG5v
dCBiZSByZXNlcnZlZApbICAgIDEuODAxMzQ2XSBzeXN0ZW0gMDA6MDA6IFBsdWcgYW5kIFBs
YXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3RpdmUpClsgICAgMS44MDE0NDNdIHN5
c3RlbSAwMDowMTogW2lvICAweDA4YTAtMHgwOGEzXSBoYXMgYmVlbiByZXNlcnZlZApbICAg
IDEuODIzNDAxXSBzeXN0ZW0gMDA6MDE6IFtpbyAgMHgwY2MwLTB4MGNjZl0gaGFzIGJlZW4g
cmVzZXJ2ZWQKWyAgICAxLjgzOTY3Nl0gc3lzdGVtIDAwOjAxOiBbaW8gIDB4MDRkMC0weDA0
ZDFdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMS44NTYzMzFdIHN5c3RlbSAwMDowMTogUGx1
ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAxLjg1
NjM2OF0geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9OCAoZ3NpPTgpClsgICAgMS44NTYzOTNd
IHBucCAwMDowMjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBiMDAgKGFj
dGl2ZSkKWyAgICAxLjg1NjQzMF0geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTIgKGdzaT0x
MikKWyAgICAxLjg1NjQ1N10gcG5wIDAwOjAzOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNl
LCBJRHMgUE5QMGYxMyAoYWN0aXZlKQpbICAgIDEuODU2NDg5XSB4ZW46IC0tPiBwaXJxPTE4
IC0+IGlycT0xIChnc2k9MSkKWyAgICAxLjg1NjUwNV0gcG5wIDAwOjA0OiBQbHVnIGFuZCBQ
bGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDMwMyBQTlAwMzBiIChhY3RpdmUpClsgICAgMS44
NTY1MjddIHhlbjogLS0+IHBpcnE9MTkgLT4gaXJxPTYgKGdzaT02KQpbICAgIDEuODU2NTMw
XSBwbnAgMDA6MDU6IFtkbWEgMl0KWyAgICAxLjg1NjU0Nl0gcG5wIDAwOjA1OiBQbHVnIGFu
ZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDcwMCAoYWN0aXZlKQpbICAgIDEuODU2NTc2
XSB4ZW46IC0tPiBwaXJxPTIwIC0+IGlycT00IChnc2k9NCkKWyAgICAxLjg1NjU5Ml0gcG5w
IDAwOjA2OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDUwMSAoYWN0aXZl
KQpbICAgIDEuODU2NjUxXSBzeXN0ZW0gMDA6MDc6IFtpbyAgMHhhZTAwLTB4YWUwZl0gaGFz
IGJlZW4gcmVzZXJ2ZWQKWyAgICAxLjg3MzA0Ml0gc3lzdGVtIDAwOjA3OiBbaW8gIDB4YjA0
NC0weGIwNDddIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMS44ODk3OTFdIHN5c3RlbSAwMDow
NzogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAg
ICAxLjg5MDI2NF0gcG5wOiBQblAgQUNQSTogZm91bmQgOCBkZXZpY2VzClsgICAgMS45MTA4
MjFdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNCBbaW8gIDB4MDAwMC0weDBjZjddClsg
ICAgMS45MTA4MjRdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNSBbaW8gIDB4MGQwMC0w
eGZmZmZdClsgICAgMS45MTA4MjZdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNiBbbWVt
IDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0KWyAgICAxLjkxMDgyOF0gcGNpX2J1cyAwMDAwOjAw
OiByZXNvdXJjZSA3IFttZW0gMHhmMDAwMDAwMC0weGZiZmZmZmZmXQpbICAgIDEuOTEwODU5
XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDIKWyAgICAxLjkyMjg5MF0gVENQ
IGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogODE5MiAob3JkZXI6IDQsIDY1NTM2
IGJ5dGVzKQpbICAgIDEuOTQxNTY2XSBUQ1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDgx
OTIgKG9yZGVyOiA1LCAxMzEwNzIgYnl0ZXMpClsgICAgMS45NTg1MjZdIFRDUDogSGFzaCB0
YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgODE5MiBiaW5kIDgxOTIpClsgICAgMS45
NzUwNjVdIFRDUDogcmVubyByZWdpc3RlcmVkClsgICAgMS45ODQwNzJdIFVEUCBoYXNoIHRh
YmxlIGVudHJpZXM6IDUxMiAob3JkZXI6IDIsIDE2Mzg0IGJ5dGVzKQpbICAgIDEuOTk5ODYy
XSBVRFAtTGl0ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMiAob3JkZXI6IDIsIDE2Mzg0IGJ5
dGVzKQpbICAgIDIuMDE2NDM3XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEK
WyAgICAyLjAzMTIwM10gcGNpIDAwMDA6MDA6MDAuMDogTGltaXRpbmcgZGlyZWN0IFBDSS9Q
Q0kgdHJhbnNmZXJzClsgICAgMi4wNTE0NjRdIHBjaSAwMDAwOjAwOjAxLjA6IFBJSVgzOiBF
bmFibGluZyBQYXNzaXZlIFJlbGVhc2UKWyAgICAyLjA3MjEzNV0gcGNpIDAwMDA6MDA6MDEu
MDogQWN0aXZhdGluZyBJU0EgRE1BIGhhbmcgd29ya2Fyb3VuZHMKWyAgICAyLjA4OTAxMl0g
eGVuOiAtLT4gcGlycT0yMSAtPiBpcnE9MjMgKGdzaT0yMykKWyAgICAyLjA5MjcxN10gcGNp
IDAwMDA6MDA6MDMuMDogVmlkZW8gZGV2aWNlIHdpdGggc2hhZG93ZWQgUk9NClsgICAgMi4w
OTMxNzddIHhlbjogLS0+IHBpcnE9MzcgLT4gaXJxPTM2IChnc2k9MzYpClsgICAgMi4wOTYx
MjJdIFBDSTogQ0xTIDAgYnl0ZXMsIGRlZmF1bHQgNjQKWyAgICAyLjA5NjE3Ml0gVHJ5aW5n
IHRvIHVucGFjayByb290ZnMgaW1hZ2UgYXMgaW5pdHJhbWZzLi4uClsgICAgMi4xNDA1MTdd
IEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogMTg3MksgKGZmZmY4ODAwMzdjNDgwMDAgLSBmZmZm
ODgwMDM3ZTFjMDAwKQpbICAgIDIuMTYxMjgxXSBTY2FubmluZyBmb3IgbG93IG1lbW9yeSBj
b3JydXB0aW9uIGV2ZXJ5IDYwIHNlY29uZHMKWyAgICAyLjE3OTYzNl0gc2hhMV9zc3NlMzog
TmVpdGhlciBBVlggbm9yIEFWWDIgbm9yIFNTU0UzIGlzIGF2YWlsYWJsZS91c2FibGUuClsg
ICAgMi4xOTgwNjRdIEFWWCBvciBBRVMtTkkgaW5zdHJ1Y3Rpb25zIGFyZSBub3QgZGV0ZWN0
ZWQuClsgICAgMi4yMTI1NzddIEFWWCBpbnN0cnVjdGlvbnMgYXJlIG5vdCBkZXRlY3RlZC4K
WyAgICAyLjIyNDgzM10gQVZYIGluc3RydWN0aW9ucyBhcmUgbm90IGRldGVjdGVkLgpbICAg
IDIuMjM3MDg5XSBmdXRleCBoYXNoIHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiA1LCAx
MzEwNzIgYnl0ZXMpClsgICAgMi4yNTI5NDBdIGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0bGlu
ayBzdWJzeXMgKGRpc2FibGVkKQpbICAgIDIuMjY3NDYyXSBhdWRpdDogdHlwZT0yMDAwIGF1
ZGl0KDE0MTYzMTYxMzYuOTcyOjEpOiBpbml0aWFsaXplZApbICAgIDIuMjgzNTE5XSBIdWdl
VExCIHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcwpb
ICAgIDIuMzAxOTU1XSBWRlM6IERpc2sgcXVvdGFzIGRxdW90XzYuNS4yClsgICAgMi4zMTI2
MTNdIERxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTEyIChvcmRlciAwLCA0MDk2
IGJ5dGVzKQpbICAgIDIuMzMwNzE0XSBudGZzOiBkcml2ZXIgMi4xLjMxIFtGbGFnczogUi9X
XS4KWyAgICAyLjM0Mjk2OF0gZnVzZSBpbml0IChBUEkgdmVyc2lvbiA3LjIzKQpbICAgIDIu
MzU2NzAzXSBnZnMyOiBHRlMyIGluc3RhbGxlZApbICAgIDIuMzY2MDgwXSBjZXBoOiBsb2Fk
ZWQgKG1kcyBwcm90byAzMikKWyAgICAyLjM3ODQ4OF0gbXNnbW5pIGhhcyBiZWVuIHNldCB0
byAxOTU5ClsgICAgMi4zOTMxMTFdIGJvdW5jZTogcG9vbCBzaXplOiA2NCBwYWdlcwpbICAg
IDIuNDA0MjU5XSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNp
b24gMC40IGxvYWRlZCAobWFqb3IgMjUwKQpbICAgIDIuNDI2ODU4XSBpbyBzY2hlZHVsZXIg
bm9vcCByZWdpc3RlcmVkClsgICAgMi40Mzc4ODddIGlvIHNjaGVkdWxlciBkZWFkbGluZSBy
ZWdpc3RlcmVkClsgICAgMi40NTIxMzVdIGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAo
ZGVmYXVsdCkKWyAgICAyLjQ2NjM3MF0gY3JjMzI6IENSQ19MRV9CSVRTID0gNjQsIENSQ19C
RSBCSVRTID0gNjQKWyAgICAyLjQ4MjYzM10gY3JjMzI6IHNlbGYgdGVzdHMgcGFzc2VkLCBw
cm9jZXNzZWQgMjI1OTQ0IGJ5dGVzIGluIDEyMjk2MSBuc2VjClsgICAgMi41MDMwNzNdIGNy
YzMyYzogQ1JDX0xFX0JJVFMgPSA2NApbICAgIDIuNTE0MzQwXSBjcmMzMmM6IHNlbGYgdGVz
dHMgcGFzc2VkLCBwcm9jZXNzZWQgMjI1OTQ0IGJ5dGVzIGluIDYxNDQxIG5zZWMKWyAgICAy
LjU0NDcxMF0gY3JjMzJfY29tYmluZTogODM3MyBzZWxmIHRlc3RzIHBhc3NlZApbICAgIDIu
NTY5OTA2XSBjcmMzMmNfY29tYmluZTogODM3MyBzZWxmIHRlc3RzIHBhc3NlZApbICAgIDIu
NTg1NjE1XSBwY2lfaG90cGx1ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAu
NQpbICAgIDIuNjAyOTcxXSBwY2llaHA6IFBDSSBFeHByZXNzIEhvdCBQbHVnIENvbnRyb2xs
ZXIgRHJpdmVyIHZlcnNpb246IDAuNApbICAgIDIuNjIyNDIyXSBjcGNpaHBfenQ1NTUwOiBa
VDU1NTAgQ29tcGFjdFBDSSBIb3QgUGx1ZyBEcml2ZXIgdmVyc2lvbjogMC4yClsgICAgMi42
NDE2MjRdIGNwY2locF9nZW5lcmljOiBHZW5lcmljIHBvcnQgSS9PIENvbXBhY3RQQ0kgSG90
IFBsdWcgRHJpdmVyIHZlcnNpb246IDAuMQpbICAgIDIuNjYyMDAxXSBjcGNpaHBfZ2VuZXJp
Yzogbm90IGNvbmZpZ3VyZWQsIGRpc2FibGluZy4KWyAgICAyLjY3NzYzNV0gc2hwY2hwOiBT
dGFuZGFyZCBIb3QgUGx1ZyBQQ0kgQ29udHJvbGxlciBEcml2ZXIgdmVyc2lvbjogMC40Clsg
ICAgMi42OTU4NjhdIGFjcGlwaHBfaWJtOiBpYm1fYWNwaXBocF9pbml0OiBhY3BpX3dhbGtf
bmFtZXNwYWNlIGZhaWxlZApbICAgIDIuNzE0MzgzXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5l
dyBpbnRlcmZhY2UgZHJpdmVyIHVkbGZiClsgICAgMi43Mjg2NTddIGlucHV0OiBQb3dlciBC
dXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQw
ClsgICAgMi43NDcyNjVdIEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0KWyAgICAyLjc1ODY3
NV0gaW5wdXQ6IFNsZWVwIEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhTTFBC
TjowMC9pbnB1dC9pbnB1dDEKWyAgICAyLjc3Nzc1NV0gQUNQSTogU2xlZXAgQnV0dG9uIFtT
TFBGXQpbICAgIDIuNzg3ODYzXSB4ZW46eGVuX2V2dGNobjogRXZlbnQtY2hhbm5lbCBkZXZp
Y2UgaW5zdGFsbGVkClsgICAgMi44MDMwMDRdIHhlbjogLS0+IHBpcnE9MjIgLT4gaXJxPTI0
IChnc2k9MjQpClsgICAgMi44MDMxODBdIHhlbjpncmFudF90YWJsZTogR3JhbnQgdGFibGVz
IHVzaW5nIHZlcnNpb24gMSBsYXlvdXQKWyAgICAyLjgyMDYyOV0gR3JhbnQgdGFibGUgaW5p
dGlhbGl6ZWQKWyAgICAyLjgzMTI5OF0gU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBw
b3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZApbICAgIDIuODk1MDUyXSBzZXJpYWwgMDA6MDY6
IHR0eVMwIGF0IEkvTyAweDNmOCAoaXJxID0gNCwgYmFzZV9iYXVkID0gMTE1MjAwKSBpcyBh
IDE2NTUwQQpbICAgIDIuOTE4MDEzXSBMaW51eCBhZ3BnYXJ0IGludGVyZmFjZSB2MC4xMDMK
WyAgICAyLjkyOTY1OV0gSGFuZ2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sgdGltZXIgMC45
LjEgKHRpY2sgaXMgMTgwIHNlY29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRzKS4KWyAgICAy
Ljk1NDc3N10gW2RybV0gSW5pdGlhbGl6ZWQgZHJtIDEuMS4wIDIwMDYwODEwClsgICAgMi45
NjgxODFdIFtkcm1dIFZHQUNPTiBkaXNhYmxlIHJhZGVvbiBrZXJuZWwgbW9kZXNldHRpbmcu
ClsgICAgMi45ODQwMDhdIFtkcm06cmFkZW9uX2luaXRdICpFUlJPUiogTm8gVU1TIHN1cHBv
cnQgaW4gcmFkZW9uIG1vZHVsZSEKWyAgICAzLjAwMzkyNF0gYnJkOiBtb2R1bGUgbG9hZGVk
ClsgICAgMy4wMTQyMjZdIGxvb3A6IG1vZHVsZSBsb2FkZWQKWyAgICAzLjAyOTUwOV0gdHVu
OiBVbml2ZXJzYWwgVFVOL1RBUCBkZXZpY2UgZHJpdmVyLCAxLjYKWyAgICAzLjAzODY4Ml0g
YmxrZnJvbnQ6IHh2ZGE6IGZsdXNoIGRpc2tjYWNoZTogZW5hYmxlZDsgcGVyc2lzdGVudCBn
cmFudHM6IGVuYWJsZWQ7IGluZGlyZWN0IGRlc2NyaXB0b3JzOiBlbmFibGVkOwpbICAgIDMu
MDc0MzIyXSB0dW46IChDKSAxOTk5LTIwMDQgTWF4IEtyYXNueWFuc2t5IDxtYXhrQHF1YWxj
b21tLmNvbT4KWyAgICAzLjA5MDkzOV0gZTEwMDA6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdv
cmsgRHJpdmVyIC0gdmVyc2lvbiA3LjMuMjEtazgtTkFQSQpbICAgIDMuMTE2MDU4XSBlMTAw
MDogQ29weXJpZ2h0IChjKSAxOTk5LTIwMDYgSW50ZWwgQ29ycG9yYXRpb24uClsgICAgMy4x
MzM5MjBdIGUxMDAwZTogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBEcml2ZXIgLSAyLjMu
Mi1rClsgICAgMy4xMzc1ODJdICB4dmRhOiB4dmRhMSB4dmRhMgpbICAgIDMuMTM5MzE3XSBi
bGtmcm9udDogeHZkYjogZmx1c2ggZGlza2NhY2hlOiBlbmFibGVkOyBwZXJzaXN0ZW50IGdy
YW50czogZW5hYmxlZDsgaW5kaXJlY3QgZGVzY3JpcHRvcnM6IGVuYWJsZWQ7ClsgICAgMy4x
NDgxODhdICB4dmRiOiB1bmtub3duIHBhcnRpdGlvbiB0YWJsZQpbICAgIDMuMTk4NTk0XSBl
MTAwMGU6IENvcHlyaWdodChjKSAxOTk5IC0gMjAxNCBJbnRlbCBDb3Jwb3JhdGlvbi4KWyAg
ICAzLjIxNjIxNV0gaWdiOiBJbnRlbChSKSBHaWdhYml0IEV0aGVybmV0IE5ldHdvcmsgRHJp
dmVyIC0gdmVyc2lvbiA1LjIuMTUtawpbICAgIDMuMjM4MDE0XSBpZ2I6IENvcHlyaWdodCAo
YykgMjAwNy0yMDE0IEludGVsIENvcnBvcmF0aW9uLgpbICAgIDMuMjU1NjUxXSBpZ2J2Zjog
SW50ZWwoUikgR2lnYWJpdCBWaXJ0dWFsIEZ1bmN0aW9uIE5ldHdvcmsgRHJpdmVyIC0gdmVy
c2lvbiAyLjAuMi1rClsgICAgMy4yNzg3NTFdIGlnYnZmOiBDb3B5cmlnaHQgKGMpIDIwMDkg
LSAyMDEyIEludGVsIENvcnBvcmF0aW9uLgpbICAgIDMuMjk1MjM2XSB4ZW5fbmV0ZnJvbnQ6
IEluaXRpYWxpc2luZyBYZW4gdmlydHVhbCBldGhlcm5ldCBkcml2ZXIKWyAgICAzLjMxODI1
NV0geGhjaV9oY2QgMDAwMDowMDowNS4wOiB4SENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDMu
MzM0OTI2XSB4aGNpX2hjZCAwMDAwOjAwOjA1LjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs
IGFzc2lnbmVkIGJ1cyBudW1iZXIgMQpbICAgIDMuMzU4ODA4XSB1c2IgdXNiMTogTmV3IFVT
QiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyClsgICAgMy4z
NzYwNjRdIHVzYiB1c2IxOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVj
dD0yLCBTZXJpYWxOdW1iZXI9MQpbICAgIDMuMzk0OTg5XSB1c2IgdXNiMTogUHJvZHVjdDog
eEhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICAzLjQwODg4MF0gdXNiIHVzYjE6IE1hbnVmYWN0
dXJlcjogTGludXggMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0eS1ub3NuZCsgeGhjaS1o
Y2QKWyAgICAzLjQzMDE2Nl0gdXNiIHVzYjE6IFNlcmlhbE51bWJlcjogMDAwMDowMDowNS4w
ClsgICAgMy40NDQ0NzhdIGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kClsgICAgMy40NTQ4
MzFdIGh1YiAxLTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkClsgICAgMy40NjY0NzZdIHhoY2lf
aGNkIDAwMDA6MDA6MDUuMDogeEhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICAzLjQ4MzQ3Nl0g
eGhjaV9oY2QgMDAwMDowMDowNS4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25l
ZCBidXMgbnVtYmVyIDIKWyAgICAzLjUwNTAyNV0gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNl
IGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMwpbICAgIDMuNTI0NTQ3XSB1
c2IgdXNiMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2Vy
aWFsTnVtYmVyPTEKWyAgICAzLjU0MzgyMF0gdXNiIHVzYjI6IFByb2R1Y3Q6IHhIQ0kgSG9z
dCBDb250cm9sbGVyClsgICAgMy41NTY5MDFdIHVzYiB1c2IyOiBNYW51ZmFjdHVyZXI6IExp
bnV4IDMuMTguMC1yYzQtMjAxNDExMTYtc2VjdXJpdHktbm9zbmQrIHhoY2ktaGNkClsgICAg
My41Nzc5OTldIHVzYiB1c2IyOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MDUuMApbICAgIDMu
NTkwODA1XSBodWIgMi0wOjEuMDogVVNCIGh1YiBmb3VuZApbICAgIDMuNjAxMzc3XSBodWIg
Mi0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApbICAgIDMuNjEyMzAyXSBlaGNpX2hjZDogVVNC
IDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAoRUhDSSkgRHJpdmVyClsgICAgMy42
Mjk0NDddIGVoY2ktcGNpOiBFSENJIFBDSSBwbGF0Zm9ybSBkcml2ZXIKWyAgICAzLjY0MjAz
M10gb2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJp
dmVyClsgICAgMy42NTgyMzldIG9oY2ktcGNpOiBPSENJIFBDSSBwbGF0Zm9ybSBkcml2ZXIK
WyAgICAzLjY3MDcxMV0gdWhjaV9oY2Q6IFVTQiBVbml2ZXJzYWwgSG9zdCBDb250cm9sbGVy
IEludGVyZmFjZSBkcml2ZXIKWyAgICAzLjY4OTk0OV0gdWhjaV9oY2QgMDAwMDowMDowMS4y
OiBVSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDMuNzA0NDE2XSB1aGNpX2hjZCAwMDAwOjAw
OjAxLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMwpb
ICAgIDMuNzI1NDgyXSB1aGNpX2hjZCAwMDAwOjAwOjAxLjI6IGlycSAyMywgaW8gYmFzZSAw
eDAwMDBjMTQwClsgICAgMy43NDMzNzldIHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBmb3Vu
ZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDEKWyAgICAzLjc2NzM0NF0gdXNiIHVz
YjM6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51
bWJlcj0xClsgICAgMy43ODcxMzJdIHVzYiB1c2IzOiBQcm9kdWN0OiBVSENJIEhvc3QgQ29u
dHJvbGxlcgpbICAgIDMuODAwNjAzXSB1c2IgdXNiMzogTWFudWZhY3R1cmVyOiBMaW51eCAz
LjE4LjAtcmM0LTIwMTQxMTE2LXNlY3VyaXR5LW5vc25kKyB1aGNpX2hjZApbICAgIDMuODIy
MzIwXSB1c2IgdXNiMzogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjAxLjIKWyAgICAzLjgzNzY2
NF0gaHViIDMtMDoxLjA6IFVTQiBodWIgZm91bmQKWyAgICAzLjg0OTU0Ml0gaHViIDMtMDox
LjA6IDIgcG9ydHMgZGV0ZWN0ZWQKWyAgICAzLjg2MjE0MV0gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JscApbICAgIDMuODc4NTA5XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdlClsgICAgMy44ODY3
MTNdIHJhbmRvbTogbm9uYmxvY2tpbmcgcG9vbCBpcyBpbml0aWFsaXplZApbICAgIDMuOTMz
MzgzXSB1c2IgMS0yOiBuZXcgbG93LXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIgdXNpbmcg
eGhjaV9oY2QKWyAgICAzLjkzMzYwM10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJm
YWNlIGRyaXZlciB1c2JzZXJpYWwKWyAgICAzLjkzMzYxN10gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBjcDIxMHgKWyAgICAzLjkzMzYzNV0gdXNic2VyaWFs
OiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgY3AyMTB4ClsgICAgMy45MzM2
NTddIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3lwcmVzc19t
OApbICAgIDMuOTMzNjcwXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3Rl
cmVkIGZvciBEZUxvcm1lIEVhcnRobWF0ZSBVU0IKWyAgICAzLjkzMzY3NV0gdXNic2VyaWFs
OiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgSElELT5DT00gUlMyMzIgQWRh
cHRlcgpbICAgIDMuOTMzNjgyXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdp
c3RlcmVkIGZvciBOb2tpYSBDQS00MiBWMiBBZGFwdGVyClsgICAgMy45MzM2OTddIHVzYmNv
cmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgbW9zNzcyMApbICAgIDMuOTMz
NzEwXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3Nj
aGlwIDIgcG9ydCBhZGFwdGVyClsgICAgMy45MzM3MTldIHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGludGVyZmFjZSBkcml2ZXIgbW9zNzg0MApbICAgIDMuOTMzNzMxXSB1c2JzZXJpYWw6
IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3NjaGlwIDc4NDAvNzgyMCBV
U0IgU2VyaWFsIERyaXZlcgpbICAgIDMuOTMzNzY3XSBpODA0MjogUE5QOiBQUy8yIENvbnRy
b2xsZXIgW1BOUDAzMDM6UFMySyxQTlAwZjEzOlBTMk1dIGF0IDB4NjAsMHg2NCBpcnEgMSwx
MgpbICAgIDMuOTQ0NDg3XSBzZXJpbzogaTgwNDIgS0JEIHBvcnQgYXQgMHg2MCwweDY0IGly
cSAxClsgICAgMy45NDQ0OTNdIHNlcmlvOiBpODA0MiBBVVggcG9ydCBhdCAweDYwLDB4NjQg
aXJxIDEyClsgICAgMy45NDQ2NjNdIG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21t
b24gZm9yIGFsbCBtaWNlClsgICAgMy45NDY2MjZdIGlucHV0OiBYZW4gVmlydHVhbCBLZXli
b2FyZCBhcyAvZGV2aWNlcy92aXJ0dWFsL2lucHV0L2lucHV0MwpbICAgIDMuOTQ2NzI2XSBp
bnB1dDogWGVuIFZpcnR1YWwgUG9pbnRlciBhcyAvZGV2aWNlcy92aXJ0dWFsL2lucHV0L2lu
cHV0NApbICAgIDMuOTQ5NjgyXSBpbnB1dDogQVQgVHJhbnNsYXRlZCBTZXQgMiBrZXlib2Fy
ZCBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzAvaW5wdXQvaW5wdXQyClsgICAg
My45NTIwMDhdIHJ0Y19jbW9zIDAwOjAyOiBydGMgY29yZTogcmVnaXN0ZXJlZCBydGNfY21v
cyBhcyBydGMwClsgICAgMy45NTIwNzFdIHJ0Y19jbW9zIDAwOjAyOiBhbGFybXMgdXAgdG8g
b25lIGRheSwgMTE0IGJ5dGVzIG52cmFtLCBocGV0IGlycXMKWyAgICAzLjk1Mjg4OF0gcGlp
eDRfc21idXMgMDAwMDowMDowMS4zOiBTTUJ1cyBIb3N0IENvbnRyb2xsZXIgbm90IGVuYWJs
ZWQhClsgICAgMy45NTMxNDddIGxpcmNfZGV2OiBJUiBSZW1vdGUgQ29udHJvbCBkcml2ZXIg
cmVnaXN0ZXJlZCwgbWFqb3IgMjQ4IApbICAgIDMuOTUzMTQ5XSBJUiBORUMgcHJvdG9jb2wg
aGFuZGxlciBpbml0aWFsaXplZApbICAgIDMuOTUzMTUwXSBJUiBSQzUoeC9zeikgcHJvdG9j
b2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDMuOTUzMTUxXSBJUiBSQzYgcHJvdG9jb2wg
aGFuZGxlciBpbml0aWFsaXplZApbICAgIDMuOTUzMTUzXSBJUiBKVkMgcHJvdG9jb2wgaGFu
ZGxlciBpbml0aWFsaXplZApbICAgIDMuOTUzMTU0XSBJUiBTb255IHByb3RvY29sIGhhbmRs
ZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjk1MzE1Nl0gSVIgU0FOWU8gcHJvdG9jb2wgaGFuZGxl
ciBpbml0aWFsaXplZApbICAgIDMuOTUzMTU3XSBJUiBTaGFycCBwcm90b2NvbCBoYW5kbGVy
IGluaXRpYWxpemVkClsgICAgMy45NTMxNThdIElSIE1DRSBLZXlib2FyZC9tb3VzZSBwcm90
b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkClsgICAgMy45NTMxNTldIElSIExJUkMgYnJpZGdl
IGhhbmRsZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjk1MzE2MF0gSVIgWE1QIHByb3RvY29sIGhh
bmRsZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjk1MzE2Ml0gY3gyNTgyMTogZHJpdmVyIHZlcnNp
b24gMC4wLjEwNiBsb2FkZWQKWyAgICAzLjk1NDM5M10geGVuOiAtLT4gcGlycT00NyAtPiBp
cnE9NDAgKGdzaT00MCkKWyAgICAzLjk1NDgzOV0gY3gyNTgyMTogQXRoZW5hIEhhcmR3YXJl
IGRldmljZSA9IDB4ODIxMApbICAgIDMuOTU0ODUxXSBjeDI1ODIxOiBjeDI1ODIxWzFdOiBz
dWJzeXN0ZW06IDAwMDA6MDAwMCwgYm9hcmQ6IENYMjU4MjEgW2NhcmQ9MSxhdXRvZGV0ZWN0
ZWRdClsgICAgNC4yMzYyMDNdIGN4MjU4MjE6IEhhcmR3YXJlIHJldmlzaW9uID0gMHgwMApb
ICAgIDQuMjM2ODAzXSBjeDI1ODIxOiBjeDI1ODIxWzFdLzA6IGZvdW5kIGF0IDAwMDA6MDA6
MDYuMCwgcmV2OiAwLCBpcnE6IDQwLCBsYXRlbmN5OiAwLCBtbWlvOiAweGYzMDAwMDAwClsg
ICAgNC4yMzczNjldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIg
cHZydXNiMgpbICAgIDQuMjM3MzcwXSBwdnJ1c2IyOiBWNEwgaW4tdHJlZSB2ZXJzaW9uOkhh
dXBwYXVnZSBXaW5UVi1QVlItVVNCMiBNUEVHMiBFbmNvZGVyL1R1bmVyClsgICAgNC4yMzcz
NzFdIHB2cnVzYjI6IERlYnVnIG1hc2sgaXMgMzEgKDB4MWYpClsgICAgNC4yNDAyNDddIHNw
NTEwMF90Y286IFNQNTEwMC9TQjgwMCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYwLjA1
ClsgICAgNC4yNDA0MjBdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjI4LjAtaW9jdGwgKDIw
MTQtMDktMTcpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tClsgICAgNC4yNDA1
MDddIEJsdWV0b290aDogVmlydHVhbCBIQ0kgZHJpdmVyIHZlciAxLjUKWyAgICA0LjI0MDU2
Ml0gQmx1ZXRvb3RoOiBIQ0kgVUFSVCBkcml2ZXIgdmVyIDIuMgpbICAgIDQuMjQwNTYzXSBC
bHVldG9vdGg6IEhDSSBINCBwcm90b2NvbCBpbml0aWFsaXplZApbICAgIDQuMjQwNTY0XSBC
bHVldG9vdGg6IEhDSSBCQ1NQIHByb3RvY29sIGluaXRpYWxpemVkClsgICAgNC4yNDA1NjVd
IEJsdWV0b290aDogSENJTEwgcHJvdG9jb2wgaW5pdGlhbGl6ZWQKWyAgICA0LjI0MDU2NV0g
Qmx1ZXRvb3RoOiBIQ0lBVEgzSyBwcm90b2NvbCBpbml0aWFsaXplZApbICAgIDQuMjQwNTY2
XSBCbHVldG9vdGg6IEhDSSBUaHJlZS13aXJlIFVBUlQgKEg1KSBwcm90b2NvbCBpbml0aWFs
aXplZApbICAgIDQuMjQwNTg5XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug
ZHJpdmVyIGJjbTIwM3gKWyAgICA0LjI0MDYwNl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBicGExMHgKWyAgICA0LjI0MDYyM10gdXNiY29yZTogcmVnaXN0
ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBiZnVzYgpbICAgIDQuMjQwNjM1XSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGJ0dXNiClsgICAgNC4yNDA2NDhd
IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgYXRoM2sKWyAgICA0
LjI0MDc2MV0gaGlkcmF3OiByYXcgSElEIGV2ZW50cyBkcml2ZXIgKEMpIEppcmkgS29zaW5h
ClsgICAgNC4yNDA5MDhdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgdXNiaGlkClsgICAgNC4yNDA5MDhdIHVzYmhpZDogVVNCIEhJRCBjb3JlIGRyaXZlcgpb
ICAgIDQuMjQxMjQxXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVy
IHNuZC11c2ItYXVkaW8KWyAgICA0LjI0MTI1OV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBzbmQtdWExMDEKWyAgICA0LjI0MTI3OF0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLXVzeDJ5ClsgICAgNC4yNDEy
OTldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi1j
YWlhcQpbICAgIDQuMjQxMzE3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug
ZHJpdmVyIHNuZC11c2ItNmZpcmUKWyAgICA0LjI0MTMzMV0gTmV0ZmlsdGVyIG1lc3NhZ2Vz
IHZpYSBORVRMSU5LIHYwLjMwLgpbICAgIDQuMjQxMzM0XSBuZm5sX2FjY3Q6IHJlZ2lzdGVy
aW5nIHdpdGggbmZuZXRsaW5rLgpbICAgIDQuMjQxMzQ3XSBuZl9jb25udHJhY2sgdmVyc2lv
biAwLjUuMCAoNzgzNiBidWNrZXRzLCAzMTM0NCBtYXgpClsgICAgNC4yNDE0MzZdIGN0bmV0
bGluayB2MC45MzogcmVnaXN0ZXJpbmcgd2l0aCBuZm5ldGxpbmsuClsgICAgNC4yNDE1NTVd
IHh0X3RpbWU6IGtlcm5lbCB0aW1lem9uZSBpcyAtMDAwMApbICAgIDQuMjQxNTU5XSBpcF9z
ZXQ6IHByb3RvY29sIDYKWyAgICA0LjI0MTU3N10gSVBWUzogUmVnaXN0ZXJlZCBwcm90b2Nv
bHMgKCkKWyAgICA0LjI0MTU4NF0gSVBWUzogQ29ubmVjdGlvbiBoYXNoIHRhYmxlIGNvbmZp
Z3VyZWQgKHNpemU9NDA5NiwgbWVtb3J5PTY0S2J5dGVzKQpbICAgIDQuMjQxNjA5XSBJUFZT
OiBDcmVhdGluZyBuZXRucyBzaXplPTEyMTYgaWQ9MApbICAgIDQuNjI1OTI5XSBpbnB1dDog
SW1FeFBTLzIgR2VuZXJpYyBFeHBsb3JlciBNb3VzZSBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9p
ODA0Mi9zZXJpbzEvaW5wdXQvaW5wdXQ2ClsgICAgNC42NDI5MzddIElQVlM6IGlwdnMgbG9h
ZGVkLgpbICAgIDQuODg2NDk3XSBpcF90YWJsZXM6IChDKSAyMDAwLTIwMDYgTmV0ZmlsdGVy
IENvcmUgVGVhbQpbICAgIDQuODg2NTMwXSBUQ1A6IGN1YmljIHJlZ2lzdGVyZWQKWyAgICA0
Ljg4NjUzM10gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNwpbICAgIDQuODg2
NTU2XSBicmlkZ2U6IGF1dG9tYXRpYyBmaWx0ZXJpbmcgdmlhIGFycC9pcC9pcDZ0YWJsZXMg
aGFzIGJlZW4gZGVwcmVjYXRlZC4gVXBkYXRlIHlvdXIgc2NyaXB0cyB0byBsb2FkIGJyX25l
dGZpbHRlciBpZiB5b3UgbmVlZCB0aGlzLgpbICAgIDUuMTkyODQyXSBCcmlkZ2UgZmlyZXdh
bGxpbmcgcmVnaXN0ZXJlZApbICAgIDUuMjAzNzk5XSBFYnRhYmxlcyB2Mi4wIHJlZ2lzdGVy
ZWQKWyAgICA1LjIxMzY5NV0gQmx1ZXRvb3RoOiBSRkNPTU0gVFRZIGxheWVyIGluaXRpYWxp
emVkClsgICAgNS4yMjY2NThdIEJsdWV0b290aDogUkZDT01NIHNvY2tldCBsYXllciBpbml0
aWFsaXplZApbICAgIDUuMjM5ODc1XSBCbHVldG9vdGg6IFJGQ09NTSB2ZXIgMS4xMQpbICAg
IDUuMjUwNDg1XSBCbHVldG9vdGg6IEJORVAgKEV0aGVybmV0IEVtdWxhdGlvbikgdmVyIDEu
MwpbICAgIDUuMjY0MTI2XSBCbHVldG9vdGg6IEJORVAgZmlsdGVyczogcHJvdG9jb2wgbXVs
dGljYXN0ClsgICAgNS4yNzc3NzNdIEJsdWV0b290aDogQk5FUCBzb2NrZXQgbGF5ZXIgaW5p
dGlhbGl6ZWQKWyAgICA1LjI5MTM5MF0gQmx1ZXRvb3RoOiBISURQIChIdW1hbiBJbnRlcmZh
Y2UgRW11bGF0aW9uKSB2ZXIgMS4yClsgICAgNS4zMDY3NTFdIEJsdWV0b290aDogSElEUCBz
b2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgICA1LjMxOTMwNF0gS2V5IHR5cGUgY2VwaCBy
ZWdpc3RlcmVkClsgICAgNS4zMjkxNDNdIGxpYmNlcGg6IGxvYWRlZCAobW9uL29zZCBwcm90
byAxNS8yNCkKWyAgICA1LjM0MjcyOV0gcmVnaXN0ZXJlZCB0YXNrc3RhdHMgdmVyc2lvbiAx
ClsgICAgNS4zNTUwNjZdIEJ0cmZzIGxvYWRlZApbICAgIDUuMzY1NzM5XSB4ZW5idXNfcHJv
YmVfZnJvbnRlbmQ6IERldmljZSB3aXRoIG5vIGRyaXZlcjogZGV2aWNlL3BjaS8wClsgICAg
NS4zODI4NjFdIGNvbnNvbGUgW25ldGNvbjBdIGVuYWJsZWQKWyAgICA1LjM4NjA5N10gdXNi
IDEtMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTEwY2YsIGlkUHJvZHVjdD01
NTAwClsgICAgNS4zODYwOThdIHVzYiAxLTI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0xLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wClsgICAgNS4zODYxMDBdIHVzYiAxLTI6
IFByb2R1Y3Q6IFVTQiBLODA1NQpbICAgIDUuMzg2MTAwXSB1c2IgMS0yOiBNYW51ZmFjdHVy
ZXI6IFZlbGxlbWFuIApbICAgIDUuMzg2MjEyXSB1c2IgMS0yOiBlcCAweDgxIC0gcm91bmRp
bmcgaW50ZXJ2YWwgdG8gNjQgbWljcm9mcmFtZXMsIGVwIGRlc2Mgc2F5cyA4MCBtaWNyb2Zy
YW1lcwpbICAgIDUuMzg2MjE1XSB1c2IgMS0yOiBlcCAweDEgLSByb3VuZGluZyBpbnRlcnZh
bCB0byA2NCBtaWNyb2ZyYW1lcywgZXAgZGVzYyBzYXlzIDgwIG1pY3JvZnJhbWVzClsgICAg
NS4zOTY3MjddIHVzYiAzLTE6IG5ldyBmdWxsLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIg
dXNpbmcgdWhjaV9oY2QKWyAgICA1LjUxMDkzNV0gbmV0Y29uc29sZTogbmV0d29yayBsb2dn
aW5nIHN0YXJ0ZWQKWyAgICA1LjUyNDE3MV0gcnRjX2Ntb3MgMDA6MDI6IHNldHRpbmcgc3lz
dGVtIGNsb2NrIHRvIDIwMTQtMTEtMTggMTM6MDk6MDEgVVRDICgxNDE2MzE2MTQxKQpbICAg
IDUuNTQ1MzQwXSBBTFNBIGRldmljZSBsaXN0OgpbICAgIDUuNTU1NjA3XSAgIE5vIHNvdW5k
Y2FyZHMgZm91bmQuClsgICAgNS41NTU2MTFdIHVzYiAzLTE6IG5vdCBydW5uaW5nIGF0IHRv
cCBzcGVlZDsgY29ubmVjdCB0byBhIGhpZ2ggc3BlZWQgaHViClsgICAgNS41ODY3OTJdIEZy
ZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEwNDhLIChmZmZmZmZmZjgyMGRmMDAwIC0g
ZmZmZmZmZmY4MjFlNTAwMCkKWyAgICA1LjYwNzkyOF0gV3JpdGUgcHJvdGVjdGluZyB0aGUg
a2VybmVsIHJlYWQtb25seSBkYXRhOiAxNjM4NGsKWyAgICA1LjYyODg3Nl0gRnJlZWluZyB1
bnVzZWQga2VybmVsIG1lbW9yeTogMTM0MEsgKGZmZmY4ODAwMDFhYjEwMDAgLSBmZmZmODgw
MDAxYzAwMDAwKQpbICAgIDUuNjUxODA5XSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5
OiA2MDBLIChmZmZmODgwMDAxZjZhMDAwIC0gZmZmZjg4MDAwMjAwMDAwMCkKWyAgICA1LjY3
MjcwNl0gdXNiIDMtMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTA2MjcsIGlk
UHJvZHVjdD0wMDAxClsgICAgNS42NzI3MDldIHVzYiAzLTE6IE5ldyBVU0IgZGV2aWNlIHN0
cmluZ3M6IE1mcj0xLCBQcm9kdWN0PTMsIFNlcmlhbE51bWJlcj01ClsgICAgNS42NzI3MTFd
IHVzYiAzLTE6IFByb2R1Y3Q6IFFFTVUgVVNCIFRhYmxldApbICAgIDUuNjcyNzEyXSB1c2Ig
My0xOiBNYW51ZmFjdHVyZXI6IFFFTVUKWyAgICA1LjY3MjcxM10gdXNiIDMtMTogU2VyaWFs
TnVtYmVyOiA0MgpbICAgIDUuNzQ4MTAyXSBpbnB1dDogUUVNVSBRRU1VIFVTQiBUYWJsZXQg
YXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAwOjAxLjIvdXNiMy8zLTEvMy0xOjEuMC8w
MDAzOjA2Mjc6MDAwMS4wMDAxL2lucHV0L2lucHV0NwpbICAgIDUuNzc0MDkxXSB1ZGV2ZFsx
NDU4XTogc3RhcnRpbmcgdmVyc2lvbiAxNzUKWyAgICA1Ljc5MDE3M10gaGlkLWdlbmVyaWMg
MDAwMzowNjI3OjAwMDEuMDAwMTogaW5wdXQsaGlkcmF3MDogVVNCIEhJRCB2MC4wMSBQb2lu
dGVyIFtRRU1VIFFFTVUgVVNCIFRhYmxldF0gb24gdXNiLTAwMDA6MDA6MDEuMi0xL2lucHV0
MApbICAgIDguOTE5NTUwXSBFWFQ0LWZzICh4dmRhMSk6IElORk86IHJlY292ZXJ5IHJlcXVp
cmVkIG9uIHJlYWRvbmx5IGZpbGVzeXN0ZW0KWyAgICA4Ljk0NjUzNF0gRVhUNC1mcyAoeHZk
YTEpOiB3cml0ZSBhY2Nlc3Mgd2lsbCBiZSBlbmFibGVkIGR1cmluZyByZWNvdmVyeQpbICAg
IDkuNjYzOTYzXSBFWFQ0LWZzICh4dmRhMSk6IHJlY292ZXJ5IGNvbXBsZXRlClsgICAgOS43
NjQ3MjNdIEVYVDQtZnMgKHh2ZGExKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJl
ZCBkYXRhIG1vZGUuIE9wdHM6IChudWxsKQpbICAgMTQuODkwMTc1XSB1ZGV2ZFsxOTU2XTog
c3RhcnRpbmcgdmVyc2lvbiAxNzUKWyAgIDE5LjgwNjUyMV0gQWRkaW5nIDc2OTAyMGsgc3dh
cCBvbiAvZGV2L3h2ZGEyLiAgUHJpb3JpdHk6LTEgZXh0ZW50czoxIGFjcm9zczo3NjkwMjBr
IFNTClsgICAxOS44NTg4NTFdIEVYVDQtZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0czog
KG51bGwpClsgICAyMC4yOTg3NDddIEVYVDQtZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0
czogZXJyb3JzPXJlbW91bnQtcm8KWyAgIDI1Ljg1MDI3Ml0gRVhUNC1mcyAoeHZkYik6IG1v
dW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBlcnJvcnM9
cmVtb3VudC1ybwpbICAgOTQuODAzNDYwXSB4aGNpX2hjZCAwMDAwOjAwOjA1LjA6IHhIQ0kg
aG9zdCBub3QgcmVzcG9uZGluZyB0byBzdG9wIGVuZHBvaW50IGNvbW1hbmQuClsgICA5NC44
MDY3NTddIHhoY2lfaGNkIDAwMDA6MDA6MDUuMDogQXNzdW1pbmcgaG9zdCBpcyBkeWluZywg
aGFsdGluZyBob3N0LgpbICAgOTQuODYyNjg3XSB4aGNpX2hjZCAwMDAwOjAwOjA1LjA6IEhD
IGRpZWQ7IGNsZWFuaW5nIHVwClsgICA5NC44NzY1NzddIHVzYiAxLTI6IFVTQiBkaXNjb25u
ZWN0LCBkZXZpY2UgbnVtYmVyIDIKWyAyNjQ0LjQ5MjcxM10gY3gyNTgyMTogY3gyNTgyMV92
aWRlb193YWtldXA6IDAgYnVmZmVycyBoYW5kbGVkIChzaG91bGQgYmUgMSkK
------------0191A1230144FE1ED
Content-Type: application/octet-stream;
 name="serial.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial.log"

77u/IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgIF9fXyAgICAgICAgICAgICAg
DQogXCBcLyAvX19fIF8gX18gICB8IHx8IHwgIHwgX19ffCAvIF8gXCAgICBfIF9fIF9fXyAN
CiAgXCAgLy8gXyBcICdfIFwgIHwgfHwgfF8gfF9fXyBcfCB8IHwgfF9ffCAnX18vIF9ffA0K
ICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8IHxffCB8X198IHwgfCAoX18gDQog
L18vXF9cX19ffF98IHxffCAgICB8X3woXylfX19fKF8pX19fLyAgIHxffCAgXF9fX3wNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KKFhF
TikgWGVuIHZlcnNpb24gNC41LjAtcmMgKHJvb3RAZHluZG5zLm9yZykgKGdjYy00LjcucmVh
bCAoRGViaWFuIDQuNy4yLTUpIDQuNy4yKSBkZWJ1Zz15IFR1ZSBOb3YgMTggMTI6NTg6NTEg
Q0VUIDIwMTQNCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IE1vbiBOb3YgMTcgMTU6MDc6MDMg
MjAxNCArMDEwMCBnaXQ6MDU0MGI4NS1kaXJ0eQ0KKFhFTikgQm9vdGxvYWRlcjogR1JVQiAx
Ljk5LTI3K2RlYjd1Mg0KKFhFTikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0xNTM2TSxtYXg6
MTUzNk0gbG9nbHZsPWFsbCBsb2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcz1k
YXRlbXMgdmdhPWdmeC0xMjgweDEwMjR4MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBjb20xPTM4
NDAwLDhuMSBjb25zb2xlPXZnYSxjb20xIGl2cnNfaW9hcGljWzZdPTAwOjE0LjAgaW9tbXU9
b24sdmVyYm9zZSxkZWJ1ZyxhbWQtaW9tbXUtZGVidWcgZGVidWcgbGFwaWM9ZGVidWcgYXBp
Y192ZXJib3NpdHk9ZGVidWcgYXBpYz1kZWJ1Zw0KKFhFTikgVmlkZW8gaW5mb3JtYXRpb246
DQooWEVOKSAgVkdBIGlzIGdyYXBoaWNzIG1vZGUgMTI4MHgxMDI0LCAzMiBicHANCihYRU4p
ICBWQkUvRERDIG1ldGhvZHM6IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDEgc2Vjb25kcw0K
KFhFTikgRGlzYyBpbmZvcm1hdGlvbjoNCihYRU4pICBGb3VuZCAyIE1CUiBzaWduYXR1cmVz
DQooWEVOKSAgRm91bmQgMiBFREQgaW5mb3JtYXRpb24gc3RydWN0dXJlcw0KKFhFTikgWGVu
LWU4MjAgUkFNIG1hcDoNCihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5
OTQwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwMDAwOTk0MDAgLSAwMDAwMDAwMDAwMGEw
MDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEw
MDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwOWZm
OTAwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDlmZjkwMDAwIC0gMDAwMDAwMDA5ZmY5
ZTAwMCAoQUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwOWZmOWUwMDAgLSAwMDAwMDAwMDlm
ZmUwMDAwIChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMDlmZmUwMDAwIC0gMDAwMDAwMDBh
MDAwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZmUwMDAwMCAtIDAwMDAwMDAx
MDAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAw
NTYwMDAwMDAwICh1c2FibGUpDQooWEVOKSBBQ1BJOiBSU0RQIDAwMEZCMTAwLCAwMDE0IChy
MCBBQ1BJQU0pDQooWEVOKSBBQ1BJOiBSU0RUIDlGRjkwMDAwLCAwMDQ4IChyMSBNU0kgICAg
T0VNU0xJQyAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IEZBQ1AgOUZG
OTAyMDAsIDAwODQgKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAgICAgIDk3
KQ0KKFhFTikgQUNQSTogRFNEVCA5RkY5MDVFMCwgOTQyNyAocjEgIEE3NjQwIEE3NjQwMTAw
ICAgICAgMTAwIElOVEwgMjAwNTExMTcpDQooWEVOKSBBQ1BJOiBGQUNTIDlGRjlFMDAwLCAw
MDQwDQooWEVOKSBBQ1BJOiBBUElDIDlGRjkwMzkwLCAwMDg4IChyMSA3NjQwTVMgQTc2NDAx
MDAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE1DRkcgOUZGOTA0MjAs
IDAwM0MgKHIxIDc2NDBNUyBPRU1NQ0ZHICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhF
TikgQUNQSTogU0xJQyA5RkY5MDQ2MCwgMDE3NiAocjEgTVNJICAgIE9FTVNMSUMgIDIwMTAw
OTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBPRU1CIDlGRjlFMDQwLCAwMDcyIChy
MSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6
IFNSQVQgOUZGOUE1RTAsIDAxMDggKHIzIEFNRCAgICBGQU1fRl8xMCAgICAgICAgMiBBTUQg
ICAgICAgICAxKQ0KKFhFTikgQUNQSTogSFBFVCA5RkY5QTZGMCwgMDAzOCAocjEgNzY0ME1T
IE9FTUhQRVQgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBJVlJTIDlG
RjlBNzMwLCAwMTEwIChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEgQU1EICAgICAgICAg
MCkNCihYRU4pIEFDUEk6IFNTRFQgOUZGOUE4NDAsIDBEQTQgKHIxIEEgTSBJICBQT1dFUk5P
VyAgICAgICAgMSBBTUQgICAgICAgICAxKQ0KKFhFTikgU3lzdGVtIFJBTTogMjA0NzlNQiAo
MjA5NzA2NjBrQikNCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMCAtPiBOb2RlIDANCihY
RU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAw
IC0+IEFQSUMgMiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMyAtPiBO
b2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAtPiBOb2RlIDANCihYRU4pIFNS
QVQ6IFBYTSAwIC0+IEFQSUMgNSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0g
MCAwLWEwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwLWEwMDAwMDAwDQoo
WEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwMDAwLTU2MDAwMDAwMA0KKFhFTikgTlVN
QTogQWxsb2NhdGVkIG1lbW5vZGVtYXAgZnJvbSA1NWQwYWYwMDAgLSA1NWQwYjUwMDANCihY
RU4pIE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lg0KKFhFTikgRG9tYWluIGhl
YXAgaW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVidWZmZXIgYXQgMHhkMDAwMDAw
MCwgbWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDIwMTAwMCwgdXNpbmcgNjE0NGssIHRvdGFsIDE2
Mzg0aw0KKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwgbGluZWxlbmd0aD01
MTIwLCBmb250IDh4MTYNCihYRU4pIHZlc2FmYjogVHJ1ZWNvbG9yOiBzaXplPTA6ODo4Ojgs
IHNoaWZ0PTA6MTY6ODowDQooWEVOKSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgMDAwZmY3ODAN
CihYRU4pIERNSSBwcmVzZW50Lg0KKFhFTikgQVBJQyBib290IHN0YXRlIGlzICd4YXBpYycN
CihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4pIEFDUEk6IFBNLVRpbWVy
IElPIFBvcnQ6IDB4ODA4DQooWEVOKSBBQ1BJOiBTTEVFUCBJTkZPOiBwbTF4X2NudFsxOjgw
NCwxOjBdLCBwbTF4X2V2dFsxOjgwMCwxOjBdDQooWEVOKSBBQ1BJOiAgICAgICAgICAgICB3
YWtldXBfdmVjWzlmZjllMDBjXSwgdmVjX3NpemVbMjBdDQooWEVOKSBBQ1BJOiBMb2NhbCBB
UElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
MV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMCAwOjEwIEFQ
SUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNf
aWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lv
biAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0g
ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkN
CihYRU4pIFByb2Nlc3NvciAjMyAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFBy
b2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAj
NSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA2XSBh
ZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KKFhFTikgSU9BUElDWzBdOiBhcGlj
X2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNCihYRU4p
IEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsy
NF0pDQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAw
eGZlYzIwMDAwLCBHU0kgMjQtNTUNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBi
dXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQooWEVOKSBBQ1BJOiBJTlRfU1JDX09W
UiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQooWEVOKSBBQ1BJ
OiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3Zl
cnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBFbmFi
bGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MNCihYRU4pIEFDUEk6
IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAwDQooWEVOKSBFUlNUIHRhYmxlIHdh
cyBub3QgZm91bmQNCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJh
dGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgU01QOiBBbGxvd2luZyA2IENQVXMgKDAgaG90cGx1
ZyBDUFVzKQ0KKFhFTikgbWFwcGVkIEFQSUMgdG8gZmZmZjgyY2ZmZmRmYjAwMCAoZmVlMDAw
MDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmNmZmZkZmEwMDAgKGZlYzAwMDAw
KQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjZmZmZGY5MDAwIChmZWMyMDAwMCkN
CihYRU4pIElSUSBsaW1pdHM6IDU2IEdTSSwgMTExMiBNU0kvTVNJLVgNCihYRU4pIFVzaW5n
IHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkNCihYRU4pIERldGVj
dGVkIDMyMDAuMTc2IE1IeiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFy
aW5nLg0KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVk
DQooWEVOKSBhbHQgdGFibGUgZmZmZjgyZDA4MDJkYWYzMCAtPiBmZmZmODJkMDgwMmRiZjUw
DQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUwMDAwMDAwIHNlZ21l
bnQgMDAwMCBidXNlcyAwMCAtIGZmDQooWEVOKSBQQ0k6IE5vdCB1c2luZyBNQ0ZHIGZvciBz
ZWdtZW50IDAwMDAgYnVzIDAwLWZmDQooWEVOKSBBTUQtVmk6IEZvdW5kIE1TSSBjYXBhYmls
aXR5IGJsb2NrIGF0IDB4NTQNCihYRU4pIEFNRC1WaTogQUNQSSBUYWJsZToNCihYRU4pIEFN
RC1WaTogIFNpZ25hdHVyZSBJVlJTDQooWEVOKSBBTUQtVmk6ICBMZW5ndGggMHgxMTANCihY
RU4pIEFNRC1WaTogIFJldmlzaW9uIDB4MQ0KKFhFTikgQU1ELVZpOiAgQ2hlY2tTdW0gMHhl
Yg0KKFhFTikgQU1ELVZpOiAgT0VNX0lkIEFNRCAgDQooWEVOKSBBTUQtVmk6ICBPRU1fVGFi
bGVfSWQgUkQ4OTBTDQooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIwMzENCihY
RU4pIEFNRC1WaTogIENyZWF0b3JfSWQgQU1EIA0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9S
ZXZpc2lvbiAwDQooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6IHR5cGUgMHgxMCBmbGFncyAw
eDNlIGxlbiAweGUwIGlkIDB4Mg0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDMgaWQgMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDAg
LT4gMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAw
eDEwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgz
IGlkIDB4ZjAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHhmMDAg
LT4gMHhmMDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlk
IDB4MTggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAw
eDMgaWQgMHhlMDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweGUw
MCAtPiAweGUwMQ0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIg
aWQgMHgyOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweGQwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
OiB0eXBlIDB4MiBpZCAweDMwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHgyIGlkIDB4YzAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NDggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhiMDAgZmxhZ3MgMA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg1MCBmbGFncyAwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGEwMCBmbGFncyAw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDU4IGZs
YWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgzIGlkIDB4
OTAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg5MDAgLT4gMHg5
MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NjAg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHg1MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAw
eDIgaWQgMHg2MDggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHg4MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeTogdHlwZSAweDIgaWQgMHg2MTAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg3MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg2OCBmbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDQwMCBmbGFncyAwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDg4IGZsYWdzIDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgzIGlkIDB4OTAgZmxh
Z3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+IDB4OTINCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgzIGlkIDB4OTggZmxhZ3MgMA0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTAgZmxhZ3MgMHhkNw0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhMiBmbGFncyAw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGEzIGZs
YWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4
YTQgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDQz
IGlkIDB4MzAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAg
LT4gMHgzZmYgYWxpYXMgMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHhhNSBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4MiBpZCAweGE4IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTkgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgxMDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHhiMCBmbGFncyAwDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAwIGlkIDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAweDQ4IGlkIDAgZmxhZ3MgMHhkNw0KKFhFTikgQU1ELVZp
OiBJVkhEIFNwZWNpYWw6IDAwMDA6MDA6MTQuMCB2YXJpZXR5IDB4MiBoYW5kbGUgMA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDQ4IGlkIDAgZmxhZ3MgMA0K
KFhFTikgQU1ELVZpOiBJVkhEIFNwZWNpYWw6IDAwMDA6MDA6MDAuMSB2YXJpZXR5IDB4MSBo
YW5kbGUgMHg3DQooWEVOKSBBTUQtVmk6IERpc2FibGVkIEhBUCBtZW1vcnkgbWFwIHNoYXJp
bmcgd2l0aCBJT01NVQ0KKFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBJ
L08gdmlydHVhbGlzYXRpb24gZW5hYmxlZA0KKFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVk
DQooWEVOKSBJbnRlcnJ1cHQgcmVtYXBwaW5nIGVuYWJsZWQNCihYRU4pIEdldHRpbmcgVkVS
U0lPTjogODAwNTAwMTANCihYRU4pIEdldHRpbmcgVkVSU0lPTjogODAwNTAwMTANCihYRU4p
IEdldHRpbmcgSUQ6IDANCihYRU4pIEdldHRpbmcgTFZUMDogNzAwDQooWEVOKSBHZXR0aW5n
IExWVDE6IDQwMA0KKFhFTikgZW5hYmxlZCBFeHRJTlQgb24gQ1BVIzANCihYRU4pIEVTUiB2
YWx1ZSBiZWZvcmUgZW5hYmxpbmcgdmVjdG9yOiAweDQgIGFmdGVyOiAwDQooWEVOKSBFTkFC
TElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZA0KKFhF
TikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1BUElDIChhcGljaWQtcGluKSA2LTAs
IDYtMTYsIDYtMTcsIDYtMTgsIDYtMTksIDYtMjAsIDYtMjEsIDYtMjIsIDYtMjMsIDctMCwg
Ny0xLCA3LTIsIDctMywgNy00LCA3LTUsIDctNiwgNy03LCA3LTgsIDctOSwgNy0xMCwgNy0x
MSwgNy0xMiwgNy0xMywgNy0xNCwgNy0xNSwgNy0xNiwgNy0xNywgNy0xOCwgNy0xOSwgNy0y
MCwgNy0yMSwgNy0yMiwgNy0yMywgNy0yNCwgNy0yNSwgNy0yNiwgNy0yNywgNy0yOCwgNy0y
OSwgNy0zMCwgNy0zMSBub3QgY29ubmVjdGVkLg0KKFhFTikgLi5USU1FUjogdmVjdG9yPTB4
RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0tMQ0KKFhFTikgbnVtYmVyIG9mIE1Q
IElSUSBzb3VyY2VzOiAxNS4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM2IHJlZ2lzdGVy
czogMjQuDQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAjNyByZWdpc3RlcnM6IDMyLg0KKFhF
TikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQooWEVOKSBJ
TyBBUElDICM2Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDogMDYwMDAwMDANCihY
RU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNg0KKFhFTikgLi4uLi4uLiAg
ICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAg
OiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzgwMjENCihYRU4pIC4uLi4uLi4g
ICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMTcNCihYRU4pIC4uLi4uLi4gICAg
IDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVy
c2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAjMDI6IDA2MDAwMDAwDQooWEVOKSAu
Li4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KKFhFTikgLi4uLiByZWdpc3RlciAjMDM6
IDA3MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IEJvb3QgRFQgICAgOiAwDQooWEVOKSAu
Li4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJp
ZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAzMA0KKFhFTikgIDAxIDAwMSAwMSAg
MCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzANCihYRU4pICAwMiAwMDEgMDEg
IDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwDQooWEVOKSAgMDMgMDAxIDAx
ICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzOA0KKFhFTikgIDA0IDAwMSAw
MSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjENCihYRU4pICAwNSAwMDEg
MDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwDQooWEVOKSAgMDYgMDAx
IDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA0OA0KKFhFTikgIDA3IDAw
MSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTANCihYRU4pICAwOCAw
MDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4DQooWEVOKSAgMDkg
MDAxIDAxICAxICAgIDEgICAgMCAgIDEgICAwICAgIDEgICAgMCAgICAwMA0KKFhFTikgIDBh
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNjgNCihYRU4pICAw
YiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwDQooWEVOKSAg
MGMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA3OA0KKFhFTikg
IDBkIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgODgNCihYRU4p
ICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwDQooWEVO
KSAgMGYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA5OA0KKFhF
TikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzANCihY
RU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwDQoo
WEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAzMA0K
KFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAN
CihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMw
DQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAz
MA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAg
MzANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAg
IDMwDQooWEVOKSBJTyBBUElDICM3Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDog
MDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNw0KKFhF
TikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBM
VFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxRjgwMjENCihY
RU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMUYNCihYRU4p
IC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4uLi4uICAgICA6
IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAjMDI6IDAwMDAw
MDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwMA0KKFhFTikgLi4uLiBJ
UlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIgTG9nIFBoeSBNYXNrIFRyaWcgSVJS
IFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhFTikgIDAwIDAwMCAwMCAgMSAgICAw
ICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMSAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDIgMDAwIDAwICAxICAg
IDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAzIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDUgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA2IDAwMCAwMCAg
MSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNyAwMDAgMDAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDggMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA5IDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwYSAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGIgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBjIDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwZCAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGUg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBm
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAx
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMWEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMWQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSBVc2luZyB2ZWN0b3ItYmFzZWQgaW5kZXhpbmcNCihYRU4pIElSUSB0
byBwaW4gbWFwcGluZ3M6DQooWEVOKSBJUlEyNDAgLT4gMDoyDQooWEVOKSBJUlE0OCAtPiAw
OjENCihYRU4pIElSUTU2IC0+IDA6Mw0KKFhFTikgSVJRMjQxIC0+IDA6NA0KKFhFTikgSVJR
NjQgLT4gMDo1DQooWEVOKSBJUlE3MiAtPiAwOjYNCihYRU4pIElSUTgwIC0+IDA6Nw0KKFhF
TikgSVJRODggLT4gMDo4DQooWEVOKSBJUlE5NiAtPiAwOjkNCihYRU4pIElSUTEwNCAtPiAw
OjEwDQooWEVOKSBJUlExMTIgLT4gMDoxMQ0KKFhFTikgSVJRMTIwIC0+IDA6MTINCihYRU4p
IElSUTEzNiAtPiAwOjEzDQooWEVOKSBJUlExNDQgLT4gMDoxNA0KKFhFTikgSVJRMTUyIC0+
IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBkb25l
Lg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBpbnRlcnJ1cHRzLg0KKFhFTikgY2Fs
aWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4uLi4uIENQVSBjbG9jayBzcGVlZCBp
cyAzMjAwLjE1NjggTUh6Lg0KKFhFTikgLi4uLi4gaG9zdCBidXMgY2xvY2sgc3BlZWQgaXMg
MjAwLjAwOTcgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3NjYWxlID0gMHhjY2Q3DQooWEVOKSBb
MjAxNC0xMS0xOCAxNDoyNjo0Ny43MTNdIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1IeiBI
UEVUDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny43MzRdIEFsbG9jYXRlZCBjb25zb2xl
IHJpbmcgb2YgNjQgS2lCLg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDcuNzQwXSBIVk06
IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny43NDZdIFNWTTog
U3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6
NDcuNzUyXSAgLSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkNCihYRU4pIFsyMDE0LTExLTE4
IDE0OjI2OjQ3Ljc1OF0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0
aW9uDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny43NjRdICAtIE5leHQtUklQIFNhdmVk
IG9uICNWTUVYSVQNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ3Ljc3MV0gIC0gUGF1c2Ut
SW50ZXJjZXB0IEZpbHRlcg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDcuNzc3XSBIVk06
IFNWTSBlbmFibGVkDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny43ODNdIEhWTTogSGFy
ZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVApIGRldGVjdGVkDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDoyNjo0Ny43ODldIEhWTTogSEFQIHBhZ2Ugc2l6ZXM6IDRrQiwgMk1CLCAxR0INCihY
RU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ3Ljc5Nl0gSFZNOiBQVkggbW9kZSBub3Qgc3VwcG9y
dGVkIG9uIHRoaXMgcGxhdGZvcm0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ3LjgyM10g
bWFza2VkIEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDcuODQ5
XSBtYXNrZWQgRXh0SU5UIG9uIENQVSMyDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny44
NzZdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ3
LjkwMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6
NDcuOTI5XSBtYXNrZWQgRXh0SU5UIG9uIENQVSM1DQooWEVOKSBbMjAxNC0xMS0xOCAxNDoy
Njo0Ny45MzZdIEJyb3VnaHQgdXAgNiBDUFVzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0
Ny45NDZdIEFNRC1WaTogRmFpbGVkIHRvIHNldHVwIEhQRVQgTVNJIHJlbWFwcGluZy4gV3Jv
bmcgSFBFVC4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ3Ljk1Ml0gQU1ELVZpOiBGYWls
ZWQgdG8gc2V0dXAgSFBFVCBNU0kgcmVtYXBwaW5nLiBXcm9uZyBIUEVULg0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6MjY6NDcuOTU5XSBBTUQtVmk6IEZhaWxlZCB0byBzZXR1cCBIUEVUIE1T
SSByZW1hcHBpbmcuIFdyb25nIEhQRVQuDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny45
NjVdIEhQRVQ6IDMgdGltZXJzIHVzYWJsZSBmb3IgYnJvYWRjYXN0ICgzIHRvdGFsKQ0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MjY6NDcuOTkyXSBBQ1BJIHNsZWVwIG1vZGVzOiBTMw0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MjY6NDcuOTk5XSBNQ0E6IFVzZSBodyB0aHJlc2hvbGRpbmcg
dG8gYWRqdXN0IHBvbGxpbmcgZnJlcXVlbmN5DQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0
OC4wMDZdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRl
ZC4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjAxM10gWGVub3Byb2ZpbGU6IEZhaWxl
ZCB0byBzZXR1cCBJQlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZg0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MjY6NDguMDIwXSAqKiogTE9BRElORyBET01BSU4gMCAqKioNCihY
RU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjE4OV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjog
cGFkZHI9MHgxMDAwMDAwIG1lbXN6PTB4MTA2NDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6
MjY6NDguMTk2XSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDIyMDAwMDAgbWVt
c3o9MHgxMDYwMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjIwM10gZWxmX3BhcnNl
X2JpbmFyeTogcGhkcjogcGFkZHI9MHgyMzA2MDAwIG1lbXN6PTB4MTQyODANCihYRU4pIFsy
MDE0LTExLTE4IDE0OjI2OjQ4LjIxMV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9
MHgyMzFiMDAwIG1lbXN6PTB4MTE0MDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDgu
MjE4XSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAtPiAweDM0NWIwMDAN
CihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjIyNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBH
VUVTVF9PUyA9ICJsaW51eCINCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjIzM10gZWxm
X3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiINCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjI2OjQ4LjI0MV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lPTiA9ICJ4
ZW4tMy4wIg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguMjQ4XSBlbGZfeGVuX3BhcnNl
X25vdGU6IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MjY6NDguMjU2XSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZm
ZjgyMzFiMWYwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC4yNjRdIGVsZl94ZW5fcGFy
c2Vfbm90ZTogSFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDANCihYRU4pIFsy
MDE0LTExLTE4IDE0OjI2OjQ4LjI3Ml0gZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9
ICIhd3JpdGFibGVfcGFnZV90YWJsZXN8cGFlX3BnZGlyX2Fib3ZlXzRnYnx3cml0YWJsZV9k
ZXNjcmlwdG9yX3RhYmxlc3xhdXRvX3RyYW5zbGF0ZWRfcGh5c21hcHxzdXBlcnZpc29yX21v
ZGVfa2VybmVsIg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguMjg3XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IFNVUFBPUlRFRF9GRUFUVVJFUyA9IDB4OTBkDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDoyNjo0OC4yOTZdIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIg0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguMzA0XSBlbGZfeGVuX3BhcnNlX25vdGU6IExP
QURFUiA9ICJnZW5lcmljIg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguMzEyXSBlbGZf
eGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNjo0OC4zMjFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5D
RUwgPSAweDENCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjMzMF0gZWxmX3hlbl9wYXJz
ZV9ub3RlOiBNT0RfU1RBUlRfUEZOID0gMHgxDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0
OC4zMzhdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAw
MDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC4zNDddIGVsZl94ZW5fcGFyc2Vf
bm90ZTogUEFERFJfT0ZGU0VUID0gMHgwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC4z
NTZdIGVsZl94ZW5fYWRkcl9jYWxjX2NoZWNrOiBhZGRyZXNzZXM6DQooWEVOKSBbMjAxNC0x
MS0xOCAxNDoyNjo0OC4zNjZdICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZmZjgw
MDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC4zNzVdICAgICBlbGZfcGFkZHJf
b2Zmc2V0ID0gMHgwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC4zODRdICAgICB2aXJ0
X29mZnNldCAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDoyNjo0OC4zOTRdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAw
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC40MDRdICAgICB2aXJ0X2tlbmQgICAgICAg
ID0gMHhmZmZmZmZmZjgzNDViMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC40MTNd
ICAgICB2aXJ0X2VudHJ5ICAgICAgID0gMHhmZmZmZmZmZjgyMzFiMWYwDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNjo0OC40MjNdICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZm
ZmZmZmZmZmZmDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC40MzNdICBYZW4gIGtlcm5l
bDogNjQtYml0LCBsc2IsIGNvbXBhdDMyDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC40
NDNdICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUsIGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+
IDB4MzQ1YjAwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguNDU0XSBQSFlTSUNBTCBN
RU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC40NjRdICBE
b20wIGFsbG9jLjogICAwMDAwMDAwNTQ4MDAwMDAwLT4wMDAwMDAwNTRjMDAwMDAwICgzNzI5
MzggcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDgu
NDc1XSAgSW5pdC4gcmFtZGlzazogMDAwMDAwMDU1ZjBjYTAwMC0+MDAwMDAwMDU1ZmZmZmEw
MA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguNDg2XSBWSVJUVUFMIE1FTU9SWSBBUlJB
TkdFTUVOVDoNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjQ5N10gIExvYWRlZCBrZXJu
ZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODM0NWIwMDANCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjI2OjQ4LjUwOF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAwMDAwMDAwMDAtPjAw
MDAwMDAwMDAwMDAwMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjUxOF0gIFBoeXMt
TWFjaCBtYXA6IGZmZmZmZmZmODM0NWIwMDAtPmZmZmZmZmZmODM3NWIwMDANCihYRU4pIFsy
MDE0LTExLTE4IDE0OjI2OjQ4LjUyOV0gIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODM3NWIw
MDAtPmZmZmZmZmZmODM3NWI0YjQNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjU0MF0g
IFBhZ2UgdGFibGVzOiAgIGZmZmZmZmZmODM3NWMwMDAtPmZmZmZmZmZmODM3N2IwMDANCihY
RU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjU1MV0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZm
ODM3N2IwMDAtPmZmZmZmZmZmODM3N2MwMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4
LjU2Ml0gIFRPVEFMOiAgICAgICAgIGZmZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZmODM4MDAw
MDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjU3M10gIEVOVFJZIEFERFJFU1M6IGZm
ZmZmZmZmODIzMWIxZjANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjU4NV0gRG9tMCBo
YXMgbWF4aW11bSA2IFZDUFVzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC41OTZdIGVs
Zl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZmZmY4MTAwMDAwMCAtPiAweGZmZmZm
ZmZmODIwNjQwMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjYxNF0gZWxmX2xvYWRf
YmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgyMjAwMDAwIC0+IDB4ZmZmZmZmZmY4MjMw
NjAwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguNjI1XSBlbGZfbG9hZF9iaW5hcnk6
IHBoZHIgMiBhdCAweGZmZmZmZmZmODIzMDYwMDAgLT4gMHhmZmZmZmZmZjgyMzFhMjgwDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC42MzddIGVsZl9sb2FkX2JpbmFyeTogcGhkciAz
IGF0IDB4ZmZmZmZmZmY4MjMxYjAwMCAtPiAweGZmZmZmZmZmODI0MjMwMDANCihYRU4pIFsy
MDE0LTExLTE4IDE0OjI2OjQ5LjA0OV0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0
OjI2OjQ5Ljc5MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MCwgdHlwZSA9IDB4Niwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ5LjgwM10gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyLCB0eXBlID0gMHg3LCBy
b290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuODE1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDEwLCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1
NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MjY6NDkuODI3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDE4LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuODQw
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDI4LCB0eXBl
ID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuODUzXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDMwLCB0eXBlID0gMHgyLCByb290IHRh
YmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MjY6NDkuODY2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDQ4LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6
MjY6NDkuODc5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDUwLCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuODkyXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDU4LCB0eXBlID0gMHgy
LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuOTA1XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDYwLCB0eXBlID0gMHgyLCByb290IHRhYmxlID0g
MHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQt
MTEtMTggMTQ6MjY6NDkuOTE5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDY4LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDku
OTMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDg4LCB0
eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuOTQ2XSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwLCB0eXBlID0gMHg3LCByb290
IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuOTYwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDkyLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVl
ZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6MjY6NDkuOTc0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDk4LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuOTg4XSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDlhLCB0eXBlID0g
MHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMDAzXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEwLCB0eXBlID0gMHg3LCByb290IHRhYmxl
ID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6MjY6NTAuMDE3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweGEyLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6
NTAuMDMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEz
LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMDQ3XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE0LCB0eXBlID0gMHg1LCBy
b290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMDYyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweGE1LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1
NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MjY6NTAuMDc3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweGE4LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMDky
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGIwLCB0eXBl
ID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMTA4XSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGIyLCB0eXBlID0gMHg3LCByb290IHRh
YmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MjY6NTAuMTIzXSBBTUQtVmk6IFNraXBwaW5nIGhvc3QgYnJpZGdl
IDAwMDA6MDA6MTguMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMTM5XSBBTUQtVmk6
IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTguMQ0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6MjY6NTAuMTU0XSBBTUQtVmk6IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTgu
Mg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMTY5XSBBTUQtVmk6IFNraXBwaW5nIGhv
c3QgYnJpZGdlIDAwMDA6MDA6MTguMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMTg0
XSBBTUQtVmk6IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTguNA0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6MjY6NTAuMTk5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDQwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2
OjUwLjIxNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1
MDAsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1MC4yMzFdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NjA4LCB0eXBlID0gMHgy
LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMjQ3XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDYxMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9
IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0
LTExLTE4IDE0OjI2OjUwLjI2M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg3MDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1
MC4yNzldIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ODAw
LCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMjk2XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwMCwgdHlwZSA9IDB4MSwg
cm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjUwLjMxMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDEsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAw
eDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDoyNjo1MC4zMjldIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4YTAwLCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAu
MzQ2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGIwMCwg
dHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjUwLjM2M10gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhjMDAsIHR5cGUgPSAweDEsIHJv
b3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1MC4zODFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4ZDAwLCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1
NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MjY6NTAuMzk4XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweGUwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjUwLjQx
Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhlMDEsIHR5
cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1MC40MzRdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ZjAwLCB0eXBlID0gMHgxLCByb290
IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuNDUyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweGYwMSwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRl
ZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4
IDE0OjI2OjUwLjQ3NV0gU2NydWJiaW5nIEZyZWUgUkFNIG9uIDEgbm9kZXMgdXNpbmcgNiBD
UFVzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1MC41ODVdIC4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uZG9uZS4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjUzLjY3OF0gSW5p
dGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1My42OTZdIFN0ZC4gTG9nbGV2ZWw6IEFsbA0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MjY6NTMuNzE0XSBHdWVzdCBMb2dsZXZlbDogQWxsDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDoyNjo1My43MzFdIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBj
b25zb2xlLg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTMuODMzXSAqKiogU2VyaWFsIGlu
cHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0
IHRvIFhlbikNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjUzLjgzNF0gRnJlZWQgMjg0a0Ig
aW5pdCBtZW1vcnkuDQptYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KYWJv
dXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3Jv
dXAgc3Vic3lzIGNwdXNldA0KWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBz
dWJzeXMgY3B1DQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBj
cHVhY2N0DQpbICAgIDAuMDAwMDAwXSBMaW51eCB2ZXJzaW9uIDMuMTguMC1yYzUtMjAxNDEx
MTYtdmFuaWxsYSAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkgKGdjYyB2ZXJzaW9uIDQuNy4yIChE
ZWJpYW4gNC43LjItNSkgKSAjMSBTTVAgVHVlIE5vdiAxOCAxMDoxODoyMyBDRVQgMjAxNA0K
WyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiByb290PS9kZXYvbWFwcGVyL3NlcnZlZXJz
dGVydGplLXJvb3Qgcm8gdmVyYm9zZSBlYXJseXByaW50az14ZW4gbWVtPTE1MzZNIGNvbnNv
bGU9aHZjMCBjb25zb2xlPXR0eTAgdmdhPTc5NCB2aWRlbz12ZXNhZmIgcjgxNjkudXNlX2Rh
Yz0xIGFjcGlfZW5mb3JjZV9yZXNvdXJjZXM9bGF4IG1heF9sb29wPTMwIGxvb3BfbWF4X3Bh
cnQ9MTAgZGVidWcgbG9nbGV2ZWw9MTAgbm9tb2Rlc2V0IHhlbi1wY2liYWNrLmhpZGU9KDAz
OjA2LjApKDA0OjAwLiopKDA3OjAwLiopKDA4OjAwLiopKDA5OjAwLiopKDBhOjAwLjApKDBi
OjAwLjApKDBlOjAwLiopIHI4MTY5LnVzZV9kYWM9MSBhY3BpLmRlYnVnX2xheWVyPTB4NDAw
MDAwIGFjcGkuZGVidWdfbGV2ZWw9MHg0DQpbICAgIDAuMDAwMDAwXSBTZXQgMTI4OTc1MDYz
IHBhZ2UocykgdG8gMS0xIG1hcHBpbmcNClsgICAgMC4wMDAwMDBdIFJlbWFwcGVkIDEwMyBw
YWdlKHMpLCBsYXN0X3Bmbj0zOTMzMTkNClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDAgcGFn
ZShzKQ0KWyAgICAwLjAwMDAwMF0gZTgyMDogQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0g
bWFwOg0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAw
MDAwMDAwMDAwOThmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAw
MDAwMDAwMDA5OTQwMC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAw
MDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMTAwMDAwLTB4MDAwMDAwMDA2MDA2NmZmZl0g
dXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDYwMDY3MDAwLTB4
MDAwMDAwMDA5ZmY4ZmZmZl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwOWZmOTAwMDAtMHgwMDAwMDAwMDlmZjlkZmZmXSBBQ1BJIGRhdGENClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwOWZmOWUwMDAtMHgwMDAwMDAwMDlmZmRm
ZmZmXSBBQ1BJIE5WUw0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA5ZmZl
MDAwMC0weDAwMDAwMDAwOWZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46
IFttZW0gMHgwMDAwMDAwMGY2MDAwMDAwLTB4MDAwMDAwMDBmNjAwM2ZmZl0gcmVzZXJ2ZWQN
ClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAw
MGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAw
MDBmZWMyMDAwMC0weDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAw
XSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBmZWVmZmZmZl0gcmVz
ZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgw
MDAwMDAwMGZmZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwMDEwMDAwMDAwMC0weDAwMDAwMDA1NWZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAu
MDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDBmZDAwMDAwMDAwLTB4MDAwMDAwZmZmZmZmZmZm
Zl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5h
YmxlZA0KWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjog
YWN0aXZlDQpbICAgIDAuMDAwMDAwXSBlODIwOiB1c2VyLWRlZmluZWQgcGh5c2ljYWwgUkFN
IG1hcDoNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4
MDAwMDAwMDAwMDA5OGZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4
MDAwMDAwMDAwMDA5OTQwMC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpbICAgIDAu
MDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAwMDAwNWZmZmZm
ZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwNjAwNjcw
MDAtMHgwMDAwMDAwMDlmZjhmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjog
W21lbSAweDAwMDAwMDAwOWZmOTAwMDAtMHgwMDAwMDAwMDlmZjlkZmZmXSBBQ1BJIGRhdGEN
ClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDlmZjllMDAwLTB4MDAwMDAw
MDA5ZmZkZmZmZl0gQUNQSSBOVlMNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAw
MDAwMDlmZmUwMDAwLTB4MDAwMDAwMDA5ZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGY2MDAwMDAwLTB4MDAwMDAwMDBmNjAwM2ZmZl0g
cmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAw
LTB4MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFtt
ZW0gMHgwMDAwMDAwMGZlYzIwMDAwLTB4MDAwMDAwMDBmZWMyMGZmZl0gcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBm
ZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MGZmZTAwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBd
IHVzZXI6IFttZW0gMHgwMDAwMDAwMTAwMDAwMDAwLTB4MDAwMDAwMDU1ZmZmZmZmZl0gdW51
c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDBmZDAwMDAwMDAwLTB4
MDAwMDAwZmZmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFNNQklPUyAyLjUg
cHJlc2VudC4NClsgICAgMC4wMDAwMDBdIERNSTogTVNJIE1TLTc2NDAvODkwRlhBLUdENzAg
KE1TLTc2NDApICAsIEJJT1MgVjEuOEIxIDA5LzEzLzIwMTANClsgICAgMC4wMDAwMDBdIGU4
MjA6IHVwZGF0ZSBbbWVtIDB4MDAwMDAwMDAtMHgwMDAwMGZmZl0gdXNhYmxlID09PiByZXNl
cnZlZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHgwMDBhMDAwMC0weDAw
MGZmZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIEFHUDogTm8gQUdQIGJyaWRnZSBmb3Vu
ZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDYwMDAwIG1heF9hcmNoX3Bm
biA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBTY2FubmluZyAxIGFyZWFzIGZvciBs
b3cgbWVtb3J5IGNvcnJ1cHRpb24NClsgICAgMC4wMDAwMDBdIEJhc2UgbWVtb3J5IHRyYW1w
b2xpbmUgYXQgW2ZmZmY4ODAwMDAwOTMwMDBdIDkzMDAwIHNpemUgMjQ1NzYNClsgICAgMC4w
MDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgwMDAwMDAwMC0weDAwMGZmZmZm
XQ0KWyAgICAwLjAwMDAwMF0gIFttZW0gMHgwMDAwMDAwMC0weDAwMGZmZmZmXSBwYWdlIDRr
DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4NWZlMDAwMDAt
MHg1ZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4NWZlMDAwMDAtMHg1ZmZmZmZm
Zl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0gQlJLIFsweDAzMjBiMDAwLCAweDAzMjBiZmZm
XSBQR1RBQkxFDQpbICAgIDAuMDAwMDAwXSBCUksgWzB4MDMyMGMwMDAsIDB4MDMyMGNmZmZd
IFBHVEFCTEUNClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHg1
YzAwMDAwMC0weDVmZGZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gIFttZW0gMHg1YzAwMDAwMC0w
eDVmZGZmZmZmXSBwYWdlIDRrDQpbICAgIDAuMDAwMDAwXSBCUksgWzB4MDMyMGQwMDAsIDB4
MDMyMGRmZmZdIFBHVEFCTEUNClsgICAgMC4wMDAwMDBdIEJSSyBbMHgwMzIwZTAwMCwgMHgw
MzIwZWZmZl0gUEdUQUJMRQ0KWyAgICAwLjAwMDAwMF0gQlJLIFsweDAzMjBmMDAwLCAweDAz
MjBmZmZmXSBQR1RBQkxFDQpbICAgIDAuMDAwMDAwXSBCUksgWzB4MDMyMTAwMDAsIDB4MDMy
MTBmZmZdIFBHVEFCTEUNClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFtt
ZW0gMHgwMDEwMDAwMC0weDViZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gIFttZW0gMHgwMDEw
MDAwMC0weDViZmZmZmZmXSBwYWdlIDRrDQpbICAgIDAuMDAwMDAwXSBSQU1ESVNLOiBbbWVt
IDB4MDQwMDAwMDAtMHgwNGYzNWZmZl0NClsgICAgMC4wMDAwMDBdIEFDUEk6IEVhcmx5IHRh
YmxlIGNoZWNrc3VtIHZlcmlmaWNhdGlvbiBkaXNhYmxlZA0KWyAgICAwLjAwMDAwMF0gQUNQ
STogUlNEUCAweDAwMDAwMDAwMDAwRkIxMDAgMDAwMDE0ICh2MDAgQUNQSUFNKQ0KWyAgICAw
LjAwMDAwMF0gQUNQSTogUlNEVCAweDAwMDAwMDAwOUZGOTAwMDAgMDAwMDQ4ICh2MDEgTVNJ
ICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBGQUNQIDB4MDAwMDAwMDA5RkY5MDIwMCAwMDAwODQgKHYwMSA3NjQwTVMgQTc2NDAx
MDAgMjAxMDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IERTRFQg
MHgwMDAwMDAwMDlGRjkwNUUwIDAwOTQyNyAodjAxIEE3NjQwICBBNzY0MDEwMCAwMDAwMDEw
MCBJTlRMIDIwMDUxMTE3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUyAweDAwMDAwMDAw
OUZGOUUwMDAgMDAwMDQwDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBBUElDIDB4MDAwMDAwMDA5
RkY5MDM5MCAwMDAwODggKHYwMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAwMDAw
MDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IE1DRkcgMHgwMDAwMDAwMDlGRjkwNDIwIDAw
MDAzQyAodjAxIDc2NDBNUyBPRU1NQ0ZHICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogU0xJQyAweDAwMDAwMDAwOUZGOTA0NjAgMDAwMTc2ICh2MDEg
TVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBPRU1CIDB4MDAwMDAwMDA5RkY5RTA0MCAwMDAwNzIgKHYwMSA3NjQwTVMgQTc2
NDAxMDAgMjAxMDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNS
QVQgMHgwMDAwMDAwMDlGRjlBNUUwIDAwMDEwOCAodjAzIEFNRCAgICBGQU1fRl8xMCAwMDAw
MDAwMiBBTUQgIDAwMDAwMDAxKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCAweDAwMDAw
MDAwOUZGOUE2RjAgMDAwMDM4ICh2MDEgNzY0ME1TIE9FTUhQRVQgIDIwMTAwOTEzIE1TRlQg
MDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJVlJTIDB4MDAwMDAwMDA5RkY5QTcz
MCAwMDAxMTAgKHYwMSBBTUQgICAgUkQ4OTBTICAgMDAyMDIwMzEgQU1EICAwMDAwMDAwMCkN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQgMHgwMDAwMDAwMDlGRjlBODQwIDAwMERBNCAo
djAxIEEgTSBJICBQT1dFUk5PVyAwMDAwMDAwMSBBTUQgIDAwMDAwMDAxKQ0KWyAgICAwLjAw
MDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAgMC4wMDAw
MDBdIE5VTUEgdHVybmVkIG9mZg0KWyAgICAwLjAwMDAwMF0gRmFraW5nIGEgbm9kZSBhdCBb
bWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwNWZmZmZmZmZdDQpbICAgIDAuMDAw
MDAwXSBOT0RFX0RBVEEoMCkgYWxsb2NhdGVkIFttZW0gMHg1ZmQxNjAwMC0weDVmZDIwZmZm
XQ0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6DQpbICAgIDAuMDAwMDAwXSAgIERNQSAg
ICAgIFttZW0gMHgwMDAwMTAwMC0weDAwZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBETUEz
MiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgTm9y
bWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBmb3IgZWFj
aCBub2RlDQpbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1vcnkgbm9kZSByYW5nZXMNClsgICAg
MC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAwMTAwMC0weDAwMDk4ZmZmXQ0KWyAg
ICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMTAwMDAwLTB4NWZmZmZmZmZdDQpb
ICAgIDAuMDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCBbbWVtIDB4MDAwMDEwMDAtMHg1
ZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAzOTMxMTIN
ClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDY0IHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0K
WyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMjEgcGFnZXMgcmVzZXJ2ZWQNClsgICAgMC4w
MDAwMDBdICAgRE1BIHpvbmU6IDM5OTIgcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAgICAwLjAw
MDAwMF0gICBETUEzMiB6b25lOiA2MDgwIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAw
LjAwMDAwMF0gICBETUEzMiB6b25lOiAzODkxMjAgcGFnZXMsIExJRk8gYmF0Y2g6MzENClsg
ICAgMC4wMDAwMDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4
MDFdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAz
XSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1
XSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDA2XSBhZGRy
ZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KWyAgICAwLjAwMDAwMF0gSU9BUElDWzBd
OiBhcGljX2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIw
MDAwXSBnc2lfYmFzZVsyNF0pDQpbICAgIDAuMDAwMDAwXSBJT0FQSUNbMV06IGFwaWNfaWQg
NywgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUNClsgICAgMC4w
MDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAy
IGRmbCBkZmwpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJ
UlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQg
Ynkgb3ZlcnJpZGUuDQpbICAgIDAuMDAwMDAwXSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01Q
IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQg
aWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAwDQpbICAgIDAuMDAwMDAwXSBzbXBib290OiBB
bGxvd2luZyA2IENQVXMsIDAgaG90cGx1ZyBDUFVzDQpbICAgIDAuMDAwMDAwXSBlODIwOiBb
bWVtIDB4YTAwMDAwMDAtMHhmNWZmZmZmZl0gYXZhaWxhYmxlIGZvciBQQ0kgZGV2aWNlcw0K
WyAgICAwLjAwMDAwMF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbg0K
WyAgICAwLjAwMDAwMF0gWGVuIHZlcnNpb246IDQuNS4wLXJjIChwcmVzZXJ2ZS1BRCkNClsg
ICAgMC4wMDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo4IG5yX2NwdW1hc2tfYml0czo4
IG5yX2NwdV9pZHM6NiBucl9ub2RlX2lkczoxDQpbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVt
YmVkZGVkIDMwIHBhZ2VzL2NwdSBAZmZmZjg4MDA1ZjYwMDAwMCBzODI1NjAgcjgxOTIgZDMy
MTI4IHUyNjIxNDQNClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IHM4MjU2MCByODE5MiBk
MzIxMjggdTI2MjE0NCBhbGxvYz0xKjIwOTcxNTINClsgICAgMC4wMDAwMDBdIHBjcHUtYWxs
b2M6IFswXSAwIDEgMiAzIDQgNSAtIC0gDQpbICAgIDAuMDAwMDAwXSB4ZW46IFBWIHNwaW5s
b2NrcyBlbmFibGVkDQpbICAgIDAuMDAwMDAwXSBCdWlsdCAxIHpvbmVsaXN0cyBpbiBOb2Rl
IG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAzODY5NDcNClsg
ICAgMC4wMDAwMDBdIFBvbGljeSB6b25lOiBETUEzMg0KWyAgICAwLjAwMDAwMF0gS2VybmVs
IGNvbW1hbmQgbGluZTogcm9vdD0vZGV2L21hcHBlci9zZXJ2ZWVyc3RlcnRqZS1yb290IHJv
IHZlcmJvc2UgZWFybHlwcmludGs9eGVuIG1lbT0xNTM2TSBjb25zb2xlPWh2YzAgY29uc29s
ZT10dHkwIHZnYT03OTQgdmlkZW89dmVzYWZiIHI4MTY5LnVzZV9kYWM9MSBhY3BpX2VuZm9y
Y2VfcmVzb3VyY2VzPWxheCBtYXhfbG9vcD0zMCBsb29wX21heF9wYXJ0PTEwIGRlYnVnIGxv
Z2xldmVsPTEwIG5vbW9kZXNldCB4ZW4tcGNpYmFjay5oaWRlPSgwMzowNi4wKSgwNDowMC4q
KSgwNzowMC4qKSgwODowMC4qKSgwOTowMC4qKSgwYTowMC4wKSgwYjowMC4wKSgwZTowMC4q
KSByODE2OS51c2VfZGFjPTEgYWNwaS5kZWJ1Z19sYXllcj0weDQwMDAwMCBhY3BpLmRlYnVn
X2xldmVsPTB4NA0KWyAgICAwLjAwMDAwMF0gUElEIGhhc2ggdGFibGUgZW50cmllczogNDA5
NiAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQ0KWyAgICAwLjAwMDAwMF0gc29mdHdhcmUgSU8g
VExCIFttZW0gMHg1OWMwMDAwMC0weDVkYzAwMDAwXSAoNjRNQikgbWFwcGVkIGF0IFtmZmZm
ODgwMDU5YzAwMDAwLWZmZmY4ODAwNWRiZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBNZW1vcnk6
IDE0MjQxOTJLLzE1NzI0NDhLIGF2YWlsYWJsZSAoMTE5MjBLIGtlcm5lbCBjb2RlLCAxMDQz
SyByd2RhdGEsIDQ0OTZLIHJvZGF0YSwgMTEwNEsgaW5pdCwgMTQxNzZLIGJzcywgMTQ4MjU2
SyByZXNlcnZlZCkNClsgICAgMC4wMDAwMDBdIFNMVUI6IEhXYWxpZ249NjQsIE9yZGVyPTAt
MywgTWluT2JqZWN0cz0wLCBDUFVzPTYsIE5vZGVzPTENClsgICAgMC4wMDAwMDBdIEhpZXJh
cmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDAuMDAwMDAwXSAJUkNVIGR5bnRp
Y2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVuYWJsZWQuDQpbICAgIDAu
MDAwMDAwXSAJQWRkaXRpb25hbCBwZXItQ1BVIGluZm8gcHJpbnRlZCB3aXRoIHN0YWxscy4N
ClsgICAgMC4wMDAwMDBdIAlSQ1UgcmVzdHJpY3RpbmcgQ1BVcyBmcm9tIE5SX0NQVVM9OCB0
byBucl9jcHVfaWRzPTYuDQpbICAgIDAuMDAwMDAwXSBSQ1U6IEFkanVzdGluZyBnZW9tZXRy
eSBmb3IgcmN1X2Zhbm91dF9sZWFmPTE2LCBucl9jcHVfaWRzPTYNClsgICAgMC4wMDAwMDBd
IE5SX0lSUVM6NDM1MiBucl9pcnFzOjEwMTYgMA0KWyAgICAwLjAwMDAwMF0geGVuOmV2ZW50
czogVXNpbmcgRklGTy1iYXNlZCBBQkkNClsgICAgMC4wMDAwMDBdIHhlbjogc2NpIG92ZXJy
aWRlOiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTENClsgICAgMC4wMDAwMDBd
IHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAg
MC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNjo1My45ODZdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg2LTkgLT4gMHg2MCAtPiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQpbICAgIDAuMDAwMDAw
XSB4ZW46IGFjcGkgc2NpIDkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MSAtPiBp
cnE9MSAoZ3NpPTEpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTIgLT4gaXJxPTIg
KGdzaT0yKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0zIC0+IGlycT0zIChnc2k9
MykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NCAtPiBpcnE9NCAoZ3NpPTQpDQpb
ICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTUgLT4gaXJxPTUgKGdzaT01KQ0KWyAgICAw
LjAwMDAwMF0geGVuOiAtLT4gcGlycT02IC0+IGlycT02IChnc2k9NikNClsgICAgMC4wMDAw
MDBdIHhlbjogLS0+IHBpcnE9NyAtPiBpcnE9NyAoZ3NpPTcpDQpbICAgIDAuMDAwMDAwXSB4
ZW46IC0tPiBwaXJxPTggLT4gaXJxPTggKGdzaT04KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAt
LT4gcGlycT0xMCAtPiBpcnE9MTAgKGdzaT0xMCkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+
IHBpcnE9MTEgLT4gaXJxPTExIChnc2k9MTEpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBw
aXJxPTEyIC0+IGlycT0xMiAoZ3NpPTEyKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGly
cT0xMyAtPiBpcnE9MTMgKGdzaT0xMykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9
MTQgLT4gaXJxPTE0IChnc2k9MTQpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTE1
IC0+IGlycT0xNSAoZ3NpPTE1KQ0KWyAgICAwLjAwMDAwMF0gQ29uc29sZTogY29sb3VyIGR1
bW15IGRldmljZSA4MHgyNQ0KWyAgICAwLjAwMDAwMF0gY29uc29sZSBbdHR5MF0gZW5hYmxl
ZA0KWyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW3hlbmJvb3QwXSBkaXNhYmxlZA0KWyAg
ICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQpbICAgIDAu
MDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUNClsgICAgMC4wMDAwMDBd
IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdWFjY3QNClsgICAgMC4wMDAwMDBdIExp
bnV4IHZlcnNpb24gMy4xOC4wLXJjNS0yMDE0MTExNi12YW5pbGxhIChyb290QHNlcnZlZXJz
dGVydGplKSAoZ2NjIHZlcnNpb24gNC43LjIgKERlYmlhbiA0LjcuMi01KSApICMxIFNNUCBU
dWUgTm92IDE4IDEwOjE4OjIzIENFVCAyMDE0DQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxp
bmU6IHJvb3Q9L2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtcm9vdCBybyB2ZXJib3NlIGVh
cmx5cHJpbnRrPXhlbiBtZW09MTUzNk0gY29uc29sZT1odmMwIGNvbnNvbGU9dHR5MCB2Z2E9
Nzk0IHZpZGVvPXZlc2FmYiByODE2OS51c2VfZGFjPTEgYWNwaV9lbmZvcmNlX3Jlc291cmNl
cz1sYXggbWF4X2xvb3A9MzAgbG9vcF9tYXhfcGFydD0xMCBkZWJ1ZyBsb2dsZXZlbD0xMCBu
b21vZGVzZXQgeGVuLXBjaWJhY2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAuKikoMDc6MDAuKiko
MDg6MDAuKikoMDk6MDAuKikoMGE6MDAuMCkoMGI6MDAuMCkoMGU6MDAuKikgcjgxNjkudXNl
X2RhYz0xIGFjcGkuZGVidWdfbGF5ZXI9MHg0MDAwMDAgYWNwaS5kZWJ1Z19sZXZlbD0weDQN
ClsgICAgMC4wMDAwMDBdIHRzZWc6IDAwMDAwMDAwMDANClsgICAgMC4wMDAwMDBdIFNldCAx
Mjg5NzUwNjMgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUmVtYXBw
ZWQgMTAzIHBhZ2UocyksIGxhc3RfcGZuPTM5MzMxOQ0KWyAgICAwLjAwMDAwMF0gUmVsZWFz
ZWQgMCBwYWdlKHMpDQpbICAgIDAuMDAwMDAwXSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNp
Y2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAw
MDAwLTB4MDAwMDAwMDAwMDA5OGZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFtt
ZW0gMHgwMDAwMDAwMDAwMDk5NDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDYw
MDY2ZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwNjAw
NjcwMDAtMHgwMDAwMDAwMDlmZjhmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDA5ZmY5MDAwMC0weDAwMDAwMDAwOWZmOWRmZmZdIEFDUEkgZGF0
YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA5ZmY5ZTAwMC0weDAwMDAw
MDAwOWZmZGZmZmZdIEFDUEkgTlZTDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAw
MDAwMDlmZmUwMDAwLTB4MDAwMDAwMDA5ZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwZjYwMDAwMDAtMHgwMDAwMDAwMGY2MDAzZmZmXSBy
ZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWMwMDAwMC0w
eDAwMDAwMDAwZmVjMDBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0g
MHgwMDAwMDAwMGZlYzIwMDAwLTB4MDAwMDAwMDBmZWMyMGZmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVlMDAwMDAtMHgwMDAwMDAwMGZlZWZm
ZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZmUw
MDAwMC0weDAwMDAwMDAwZmZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46
IFttZW0gMHgwMDAwMDAwMTAwMDAwMDAwLTB4MDAwMDAwMDU1ZmZmZmZmZl0gdW51c2FibGUN
ClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMGZkMDAwMDAwMDAtMHgwMDAwMDBm
ZmZmZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW3hlbmJv
b3QwXSBlbmFibGVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDYwMDAw
MDAwLTB4ZmZmZmZmZmZmZmZmZmZmZV0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBOWCAoRXhl
Y3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUNClsgICAgMC4wMDAwMDBdIGU4MjA6
IHVzZXItZGVmaW5lZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAwLjAwMDAwMF0gdXNlcjog
W21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAwMDAwMDAwMDk4ZmZmXSB1c2FibGUNClsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDk5NDAwLTB4MDAwMDAwMDAw
MDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MDAwMTAwMDAwLTB4MDAwMDAwMDA1ZmZmZmZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1
c2VyOiBbbWVtIDB4MDAwMDAwMDA2MDA2NzAwMC0weDAwMDAwMDAwOWZmOGZmZmZdIHVudXNh
YmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDA5ZmY5MDAwMC0weDAw
MDAwMDAwOWZmOWRmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAw
eDAwMDAwMDAwOWZmOWUwMDAtMHgwMDAwMDAwMDlmZmRmZmZmXSBBQ1BJIE5WUw0KWyAgICAw
LjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwOWZmZTAwMDAtMHgwMDAwMDAwMDlmZmZm
ZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZjYw
MDAwMDAtMHgwMDAwMDAwMGY2MDAzZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNl
cjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZl
ZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmVjMjAwMDAtMHgwMDAw
MDAwMGZlYzIwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAw
MDAwMDAwZmVlMDAwMDAtMHgwMDAwMDAwMGZlZWZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAw
MDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZmZmZm
XSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAxMDAwMDAw
MDAtMHgwMDAwMDAwNTVmZmZmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjog
W21lbSAweDAwMDAwMGZkMDAwMDAwMDAtMHgwMDAwMDBmZmZmZmZmZmZmXSByZXNlcnZlZA0K
WyAgICAwLjAwMDAwMF0gU01CSU9TIDIuNSBwcmVzZW50Lg0KWyAgICAwLjAwMDAwMF0gRE1J
OiBNU0kgTVMtNzY0MC84OTBGWEEtR0Q3MCAoTVMtNzY0MCkgICwgQklPUyBWMS44QjEgMDkv
MTMvMjAxMA0KWyAgICAwLjAwMDAwMF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0w
eDAwMDAwZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOlsg
ICAxNS43NTYyNjZdIHBjaWJhY2sgMDAwMDowODowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNw
YWNlIGF0IG9mZnNldCAweDNjICh3YXMgMHgxMDAsIHdyaXRpbmcgMHgxMDcpDQpbICAgMTUu
NzU2NTEwXSBwY2liYWNrIDAwMDA6MDg6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBh
dCBvZmZzZXQgMHgxMCAod2FzIDB4NCwgd3JpdGluZyAweGZlMGZlMDA0KQ0KWyAgIDE1Ljc1
Njc0MF0gcGNpYmFjayAwMDAwOjA4OjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQg
b2Zmc2V0IDB4YyAod2FzIDB4MCwgd3JpdGluZyAweDEwKQ0KWyAgIDE1Ljc1Njk1NF0gcGNp
YmFjayAwMDAwOjA4OjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4
NCAod2FzIDB4MTAwMDAwLCB3cml0aW5nIDB4MTAwMTAyKQ0KWyAgIDE1Ljc1NzMwOF0geGVu
OiByZWdpc3RlcmluZyBnc2kgMzMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxNS43
NTc0NjBdIHhlbjogLS0+IHBpcnE9MzMgLT4gaXJxPTMzIChnc2k9MzMpDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNjo1Ni45NDFdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg3LTkgLT4gMHhjMSAtPiBJUlEgMzMgTW9kZToxIEFjdGl2ZToxKQ0KWyAgIDE1Ljc4MzAy
OF0gcGNpYmFjayAwMDAwOjA5OjAwLjA6IGVuYWJsaW5nIGRldmljZSAoMDAwMCAtPiAwMDAz
KQ0KWyAgIDE1Ljc4MzIwN10geGVuOiByZWdpc3RlcmluZyBnc2kgMzIgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDENClsgICAxNS43ODMzNTNdIHhlbjogLS0+IHBpcnE9MzIgLT4gaXJxPTMy
IChnc2k9MzIpDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1Ni45NjddIElPQVBJQ1sxXTog
U2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTggLT4gMHhjOSAtPiBJUlEgMzIgTW9kZToxIEFj
dGl2ZToxKQ0KWyAgIDE1LjgwOTY1OF0geGVuOiByZWdpc3RlcmluZyBnc2kgNDcgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAxNS44MDk4MDZdIHhlbjogLS0+IHBpcnE9NDcgLT4g
aXJxPTQ3IChnc2k9NDcpDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1Ni45OTNdIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTIzIC0+IDB4ZDEgLT4gSVJRIDQ3IE1v
ZGU6MSBBY3RpdmU6MSkNClsgICAxNi44MTk2NzBdIHBjaWJhY2sgMDAwMDowYTowMC4wOiBy
ZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweDNjICh3YXMgMHgxMDAsIHdyaXRp
bmcgMHgxMGEpDQpbICAgMTYuODE5OTE3XSBwY2liYWNrIDAwMDA6MGE6MDAuMDogcmVzdG9y
aW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHgxMCAod2FzIDB4NCwgd3JpdGluZyAweGZl
MjAwMDA0KQ0KWyAgIDE2LjgyMDE0OF0gcGNpYmFjayAwMDAwOjBhOjAwLjA6IHJlc3Rvcmlu
ZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4YyAod2FzIDB4MCwgd3JpdGluZyAweDEwKQ0K
WyAgIDE2LjgyMDM2M10gcGNpYmFjayAwMDAwOjBhOjAwLjA6IHJlc3RvcmluZyBjb25maWcg
c3BhY2UgYXQgb2Zmc2V0IDB4NCAod2FzIDB4MTAwMDAwLCB3cml0aW5nIDB4MTAwMTA2KQ0K
WyAgIDE2LjgyNzEwMF0geGVuOiByZWdpc3RlcmluZyBnc2kgNDggdHJpZ2dlcmluZyAwIHBv
bGFyaXR5IDENClsgICAxNi44MzM1OTRdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6NDgNClsg
ICAxNy44NDk1OTZdIHBjaWJhY2sgMDAwMDowYjowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNw
YWNlIGF0IG9mZnNldCAweDNjICh3YXMgMHgxMDAsIHdyaXRpbmcgMHgxMGEpDQpbICAgMTcu
ODU2MzAxXSBwY2liYWNrIDAwMDA6MGI6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBh
dCBvZmZzZXQgMHgxMCAod2FzIDB4NCwgd3JpdGluZyAweGZlNWZlMDA0KQ0KWyAgIDE3Ljg2
MjkyMl0gcGNpYmFjayAwMDAwOjBiOjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQg
b2Zmc2V0IDB4YyAod2FzIDB4MCwgd3JpdGluZyAweDEwKQ0KWyAgIDE3Ljg2OTUwOF0gcGNp
YmFjayAwMDAwOjBiOjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4
NCAod2FzIDB4MTAwMDAwLCB3cml0aW5nIDB4MTAwMTAyKQ0KWyAgIDE3Ljg3NjIxMF0geGVu
OiByZWdpc3RlcmluZyBnc2kgMjkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxNy44
ODI3OTFdIHhlbjogLS0+IHBpcnE9MjkgLT4gaXJxPTI5IChnc2k9MjkpDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNjo1OS4wNzNdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg3LTUgLT4gMHhkOSAtPiBJUlEgMjkgTW9kZToxIEFjdGl2ZToxKQ0KWyAgIDE3LjkxMzAy
N10gcGNpYmFjayAwMDAwOjBlOjAwLjA6IGVuYWJsaW5nIGRldmljZSAoMDAwMCAtPiAwMDAz
KQ0KWyAgIDE3LjkxOTY3OF0geGVuOiByZWdpc3RlcmluZyBnc2kgMjggdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDENClsgICAxNy45MjYzMjRdIHhlbjogLS0+IHBpcnE9MjggLT4gaXJxPTI4
IChnc2k9MjgpDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1OS4xMTZdIElPQVBJQ1sxXTog
U2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTQgLT4gMHgyMiAtPiBJUlEgMjggTW9kZToxIEFj
dGl2ZToxKQ0KWyAgIDE3Ljk1OTkzNV0geGVuX3BjaWJhY2s6IGJhY2tlbmQgaXMgdnBjaQ0K
WyAgIDE3Ljk2NjkyOF0geGVuX2FjcGlfcHJvY2Vzc29yOiBVcGxvYWRpbmcgWGVuIHByb2Nl
c3NvciBQTSBpbmZvDQpbICAgMTcuOTc1MDI2XSBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVy
LCA0IHBvcnRzLCBJUlEgc2hhcmluZyBlbmFibGVkDQpbICAgMTcuOTgyODU2XSBocGV0X2Fj
cGlfYWRkOiBubyBhZGRyZXNzIG9yIGlycXMgaW4gX0NSUw0KWyAgIDE3Ljk4OTcxOF0gTGlu
dXggYWdwZ2FydCBpbnRlcmZhY2UgdjAuMTAzDQpbICAgMTcuOTk2ODE4XSBIYW5nY2hlY2s6
IHN0YXJ0aW5nIGhhbmdjaGVjayB0aW1lciAwLjkuMSAodGljayBpcyAxODAgc2Vjb25kcywg
bWFyZ2luIGlzIDYwIHNlY29uZHMpLg0KWyAgIDE4LjAwMzUwNV0gW2RybV0gSW5pdGlhbGl6
ZWQgZHJtIDEuMS4wIDIwMDYwODEwDQpbICAgMTguMDEwMTE0XSBbZHJtXSBWR0FDT04gZGlz
YWJsZSByYWRlb24ga2VybmVsIG1vZGVzZXR0aW5nLg0KWyAgIDE4LjAxNjY5NV0gW2RybTpy
YWRlb25faW5pdF0gKkVSUk9SKiBObyBVTVMgc3VwcG9ydCBpbiByYWRlb24gbW9kdWxlIQ0K
WyAgIDE4LjAyNjYwNV0gYnJkOiBtb2R1bGUgbG9hZGVkDQpbICAgMTguMDQxMjUwXSBsb29w
OiBtb2R1bGUgbG9hZGVkDQpbICAgMTguMDQ4MTQxXSBhaGNpIDAwMDA6MDA6MTEuMDogdmVy
c2lvbiAzLjANClsgICAxOC4wNTQ3NTVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE5IHRyaWdn
ZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguMDYxMjA3XSB4ZW46IC0tPiBwaXJxPTE5IC0+
IGlycT0xOSAoZ3NpPTE5KQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTkuMjUxXSBJT0FQ
SUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOSAtPiAweDJhIC0+IElSUSAxOSBN
b2RlOjEgQWN0aXZlOjEpDQpbICAgMTguMDY3ODU0XSBhaGNpIDAwMDA6MDA6MTEuMDogQUhD
SSAwMDAxLjAyMDAgMzIgc2xvdHMgNiBwb3J0cyA2IEdicHMgMHgzZiBpbXBsIFNBVEEgbW9k
ZQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTkuMjYzXSAtLU1BUkstLQ0KWyAgIDE4LjA3
NDMwMF0gYWhjaSAwMDAwOjAwOjExLjA6IGZsYWdzOiA2NGJpdCBuY3Egc250ZiBpbGNrIHBt
IGxlZCBjbG8gcG1wIHBpbyBzbHVtIHBhcnQgDQpbICAgMTguMDgzMzUyXSBzY3NpIGhvc3Qw
OiBhaGNpDQpbICAgMTguMDkwMTI2XSBzY3NpIGhvc3QxOiBhaGNpDQpbICAgMTguMDk2NzA0
XSBzY3NpIGhvc3QyOiBhaGNpDQpbICAgMTguMTAzMjAyXSBzY3NpIGhvc3QzOiBhaGNpDQpb
ICAgMTguMTA5NjA3XSBzY3NpIGhvc3Q0OiBhaGNpDQpbICAgMTguMTE1ODk0XSBzY3NpIGhv
c3Q1OiBhaGNpDQpbICAgMTguMTIxODI1XSBhdGExOiBTQVRBIG1heCBVRE1BLzEzMyBhYmFy
IG0xMDI0QDB4ZmRiZmYwMDAgcG9ydCAweGZkYmZmMTAwIGlycSAxMTQNClsgICAxOC4xMjc4
MThdIGF0YTI6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZGJmZjAwMCBwb3J0
IDB4ZmRiZmYxODAgaXJxIDExNQ0KWyAgIDE4LjEzMzczNl0gYXRhMzogU0FUQSBtYXggVURN
QS8xMzMgYWJhciBtMTAyNEAweGZkYmZmMDAwIHBvcnQgMHhmZGJmZjIwMCBpcnEgMTE2DQpb
ICAgMTguMTM5NDYyXSBhdGE0OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmRi
ZmYwMDAgcG9ydCAweGZkYmZmMjgwIGlycSAxMTcNClsgICAxOC4xNDUxOTVdIGF0YTU6IFNB
VEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZGJmZjAwMCBwb3J0IDB4ZmRiZmYzMDAg
aXJxIDExOA0KWyAgIDE4LjE1MDkwOF0gYXRhNjogU0FUQSBtYXggVURNQS8xMzMgYWJhciBt
MTAyNEAweGZkYmZmMDAwIHBvcnQgMHhmZGJmZjM4MCBpcnEgMTE5DQpbICAgMTguMTU2NjYz
XSB0dW46IFVuaXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2ZXIsIDEuNg0KWyAgIDE4LjE2
MjE4NF0gdHVuOiAoQykgMTk5OS0yMDA0IE1heCBLcmFzbnlhbnNreSA8bWF4a0BxdWFsY29t
bS5jb20+DQpbICAgMTguMTY3ODU0XSBlMTAwMDogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29y
ayBEcml2ZXIgLSB2ZXJzaW9uIDcuMy4yMS1rOC1OQVBJDQpbICAgMTguMTczNDc4XSBlMTAw
MDogQ29weXJpZ2h0IChjKSAxOTk5LTIwMDYgSW50ZWwgQ29ycG9yYXRpb24uDQpbICAgMTgu
MTc5MTIxXSBlMTAwMGU6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgRHJpdmVyIC0gMi4z
LjItaw0KWyAgIDE4LjE4NDY1Nl0gZTEwMDBlOiBDb3B5cmlnaHQoYykgMTk5OSAtIDIwMTQg
SW50ZWwgQ29ycG9yYXRpb24uDQpbICAgMTguMTkwMjc4XSBpZ2I6IEludGVsKFIpIEdpZ2Fi
aXQgRXRoZXJuZXQgTmV0d29yayBEcml2ZXIgLSB2ZXJzaW9uIDUuMi4xNS1rDQpbICAgMTgu
MTk1OTM5XSBpZ2I6IENvcHlyaWdodCAoYykgMjAwNy0yMDE0IEludGVsIENvcnBvcmF0aW9u
Lg0KWyAgIDE4LjIwMTczM10gaWdidmY6IEludGVsKFIpIEdpZ2FiaXQgVmlydHVhbCBGdW5j
dGlvbiBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gMi4wLjItaw0KWyAgIDE4LjIwNzQ1Ml0g
aWdidmY6IENvcHlyaWdodCAoYykgMjAwOSAtIDIwMTIgSW50ZWwgQ29ycG9yYXRpb24uDQpb
ICAgMTguMjEzMjM2XSByODE2OSBHaWdhYml0IEV0aGVybmV0IGRyaXZlciAyLjNMSy1OQVBJ
IGxvYWRlZA0KWyAgIDE4LjIxOTAxOF0geGVuOiByZWdpc3RlcmluZyBnc2kgNDYgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAxOC4yMjQ3NjRdIHhlbjogLS0+IHBpcnE9NDYgLT4g
aXJxPTQ2IChnc2k9NDYpDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1OS40MTRdIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTIyIC0+IDB4NzIgLT4gSVJRIDQ2IE1v
ZGU6MSBBY3RpdmU6MSkNClsgICAxOC4yMzA0OTBdIHI4MTY5IDAwMDA6MGQ6MDAuMDogZW5h
YmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTguMjM2NjQ4XSByODE2OSAwMDAwOjBkOjAwLjAg
ZXRoMDogUlRMODE2OGQvODExMWQgYXQgMHhmZmZmYzkwMDAwMzY0MDAwLCA0MDo2MTo4Njpm
NDo2NzpkOSwgWElEIDA4MTAwMGMwIElSUSAxMjINClsgICAxOC4yNDI2MTJdIHI4MTY5IDAw
MDA6MGQ6MDAuMCBldGgwOiBqdW1ibyBmZWF0dXJlcyBbZnJhbWVzOiA5MjAwIGJ5dGVzLCB0
eCBjaGVja3N1bW1pbmc6IGtvXQ0KWyAgIDE4LjI0ODUzMV0gcjgxNjkgR2lnYWJpdCBFdGhl
cm5ldCBkcml2ZXIgMi4zTEstTkFQSSBsb2FkZWQNClsgICAxOC4yNTQ0NjddIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDUxIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguMjYwNDE0
XSB4ZW46IC0tPiBwaXJxPTUxIC0+IGlycT01MSAoZ3NpPTUxKQ0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MjY6NTkuNDUwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0y
NyAtPiAweDhhIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpDQpbICAgMTguMjY2MzUzXSBy
ODE2OSAwMDAwOjBjOjAwLjA6IGVuYWJsaW5nIE1lbS1Xci1JbnZhbA0KWyAgIDE4LjI3MjYw
M10gcjgxNjkgMDAwMDowYzowMC4wIGV0aDE6IFJUTDgxNjhkLzgxMTFkIGF0IDB4ZmZmZmM5
MDAwMDM2NjAwMCwgNDA6NjE6ODY6ZjQ6Njc6ZDgsIFhJRCAwODEwMDBjMCBJUlEgMTIzDQpb
ICAgMTguMjc4NjM0XSByODE2OSAwMDAwOjBjOjAwLjAgZXRoMToganVtYm8gZmVhdHVyZXMg
W2ZyYW1lczogOTIwMCBieXRlcywgdHggY2hlY2tzdW1taW5nOiBrb10NClsgICAxOC4yODQ2
NjldIHhlbl9uZXRmcm9udDogSW5pdGlhbGlzaW5nIFhlbiB2aXJ0dWFsIGV0aGVybmV0IGRy
aXZlcg0KWyAgIDE4LjI5MTAyNF0gZWhjaV9oY2Q6IFVTQiAyLjAgJ0VuaGFuY2VkJyBIb3N0
IENvbnRyb2xsZXIgKEVIQ0kpIERyaXZlcg0KWyAgIDE4LjI5NzEwMV0gZWhjaS1wY2k6IEVI
Q0kgUENJIHBsYXRmb3JtIGRyaXZlcg0KWyAgIDE4LjMwMzM1OV0geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxOC4zMDkzNjddIEFscmVh
ZHkgc2V0dXAgdGhlIEdTSSA6MTcNClsgICAxOC4zMTU0MDVdIFFVSVJLOiBFbmFibGUgQU1E
IFBMTCBmaXgNClsgICAxOC4zMjE0MDBdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogZW5hYmxp
bmcgYnVzIG1hc3RlcmluZw0KWyAgIDE4LjMyNzQyMF0gZWhjaS1wY2kgMDAwMDowMDoxMi4y
OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgIDE4LjMzMzcyMl0gZWhjaS1wY2kgMDAwMDow
MDoxMi4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDEN
ClsgICAxOC4zMzk3MTVdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogYXBwbHlpbmcgQU1EIFNC
NzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kDQpbICAgMTgu
MzQ1Nzg4XSBlaGNpLXBjaSAwMDAwOjAwOjEyLjI6IGRlYnVnIHBvcnQgMQ0KWyAgIDE4LjM1
MTg5MV0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBlbmFibGluZyBNZW0tV3ItSW52YWwNClsg
ICAxOC4zNTc4NzhdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogaXJxIDE3LCBpbyBtZW0gMHhm
ZGJmZjQwMA0KWyAgIDE4LjM3MjkyOF0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBVU0IgMi4w
IHN0YXJ0ZWQsIEVIQ0kgMS4wMA0KWyAgIDE4LjM3ODkwNl0gdXNiIHVzYjE6IE5ldyBVU0Ig
ZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMg0KWyAgIDE4LjM4
NDY5MV0gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0
PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgMTguMzkwNDU4XSB1c2IgdXNiMTogUHJvZHVjdDog
RUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAxOC4zOTYxNzhdIHVzYiB1c2IxOiBNYW51ZmFj
dHVyZXI6IExpbnV4IDMuMTguMC1yYzUtMjAxNDExMTYtdmFuaWxsYSBlaGNpX2hjZA0KWyAg
IDE4LjQwMTk2OV0gdXNiIHVzYjE6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMi4yDQpbICAg
MTguNDA4MzI1XSBodWIgMS0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgIDE4LjQxNDA5N10g
aHViIDEtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQNClsgICAxOC40MjA0NDJdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguNDI2MjMw
XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3DQpbICAgMTguNDMxOTUzXSBlaGNpLXBjaSAw
MDAwOjAwOjEzLjI6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNClsgICAxOC40Mzc2OTFdIGVo
Y2ktcGNpIDAwMDA6MDA6MTMuMjogRUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAxOC40NDM0
ODJdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNz
aWduZWQgYnVzIG51bWJlciAyDQpbICAgMTguNDQ5MjM0XSBlaGNpLXBjaSAwMDAwOjAwOjEz
LjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWgg
d29ya2Fyb3VuZA0KWyAgIDE4LjQ1NTE0Ml0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBkZWJ1
ZyBwb3J0IDENClsgICAxOC40NjExOTJdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogZW5hYmxp
bmcgTWVtLVdyLUludmFsDQpbICAgMTguNDY3MTgzXSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6
IGlycSAxNywgaW8gbWVtIDB4ZmRiZmY4MDANClsgICAxOC40NzYzMTNdIGF0YTY6IFNBVEEg
bGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQ0KWyAgIDE4LjQ4MjU1OF0gYXRh
MjogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApDQpbICAgMTguNDgy
ODQwXSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAw
DQpbICAgMTguNDgyOTE0XSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVu
ZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyDQpbICAgMTguNDgyOTE1XSB1c2IgdXNiMjogTmV3
IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEN
ClsgICAxOC40ODI5MTddIHVzYiB1c2IyOiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxl
cg0KWyAgIDE4LjQ4MjkxOF0gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGludXggMy4xOC4w
LXJjNS0yMDE0MTExNi12YW5pbGxhIGVoY2lfaGNkDQpbICAgMTguNDgyOTE5XSB1c2IgdXNi
MjogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEzLjINClsgICAxOC40ODMyMTJdIGh1YiAyLTA6
MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgMTguNDgzMjIzXSBodWIgMi0wOjEuMDogNSBwb3J0
cyBkZXRlY3RlZA0KWyAgIDE4LjQ4MzY2MF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJp
Z2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxOC40ODM2NjJdIEFscmVhZHkgc2V0dXAgdGhl
IEdTSSA6MTcNClsgICAxOC40ODM2OTBdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogZW5hYmxp
bmcgYnVzIG1hc3RlcmluZw0KWyAgIDE4LjQ4MzcxOF0gZWhjaS1wY2kgMDAwMDowMDoxNi4y
OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgIDE4LjQ4Mzk0OV0gZWhjaS1wY2kgMDAwMDow
MDoxNi4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDMN
ClsgICAxOC40ODM5NTNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogYXBwbHlpbmcgQU1EIFNC
NzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kDQpbICAgMTgu
NDgzOTczXSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGRlYnVnIHBvcnQgMQ0KWyAgIDE4LjQ4
NDA1MV0gZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBlbmFibGluZyBNZW0tV3ItSW52YWwNClsg
ICAxOC40ODQwNjBdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogaXJxIDE3LCBpbyBtZW0gMHhm
ZGJmZmMwMA0KWyAgIDE4LjQ5Mjg0N10gZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBVU0IgMi4w
IHN0YXJ0ZWQsIEVIQ0kgMS4wMA0KWyAgIDE4LjQ5MjkxNl0gdXNiIHVzYjM6IE5ldyBVU0Ig
ZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMg0KWyAgIDE4LjQ5
MjkxOF0gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0
PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgMTguNDkyOTE5XSB1c2IgdXNiMzogUHJvZHVjdDog
RUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAxOC40OTI5MjFdIHVzYiB1c2IzOiBNYW51ZmFj
dHVyZXI6IExpbnV4IDMuMTguMC1yYzUtMjAxNDExMTYtdmFuaWxsYSBlaGNpX2hjZA0KWyAg
IDE4LjQ5MjkyMV0gdXNiIHVzYjM6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxNi4yDQpbICAg
MTguNDkzMjUyXSBodWIgMy0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgIDE4LjQ5MzI2M10g
aHViIDMtMDoxLjA6IDQgcG9ydHMgZGV0ZWN0ZWQNClsgICAxOC40OTM1MTZdIG9oY2lfaGNk
OiBVU0IgMS4xICdPcGVuJyBIb3N0IENvbnRyb2xsZXIgKE9IQ0kpIERyaXZlcg0KWyAgIDE4
LjQ5MzUyN10gb2hjaS1wY2k6IE9IQ0kgUENJIHBsYXRmb3JtIGRyaXZlcg0KWyAgIDE4LjQ5
MzY5Nl0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEN
ClsgICAxOC40OTM2OThdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNClsgICAxOC40OTM3
MjBdIG9oY2ktcGNpIDAwMDA6MDA6MTIuMDogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAg
IDE4LjQ5MzczNF0gb2hjaS1wY2kgMDAwMDowMDoxMi4wOiBPSENJIFBDSSBob3N0IGNvbnRy
b2xsZXINClsgICAxOC40OTM5ODhdIG9oY2ktcGNpIDAwMDA6MDA6MTIuMDogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA0DQpbICAgMTguNDk0MTM5XSBv
aGNpLXBjaSAwMDAwOjAwOjEyLjA6IGlycSAxOCwgaW8gbWVtIDB4ZmRiZjcwMDANClsgICAx
OC41NTA0NjddIHVzYiB1c2I0OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2
YiwgaWRQcm9kdWN0PTAwMDENClsgICAxOC41NTA0NjhdIHVzYiB1c2I0OiBOZXcgVVNCIGRl
dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgIDE4
LjU1MDQ2OV0gdXNiIHVzYjQ6IFByb2R1Y3Q6IE9IQ0kgUENJIGhvc3QgY29udHJvbGxlcg0K
WyAgIDE4LjU1MDQ3MF0gdXNiIHVzYjQ6IE1hbnVmYWN0dXJlcjogTGludXggMy4xOC4wLXJj
NS0yMDE0MTExNi12YW5pbGxhIG9oY2lfaGNkDQpbICAgMTguNTUwNDcxXSB1c2IgdXNiNDog
U2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEyLjANClsgICAxOC41NTA3NzZdIGh1YiA0LTA6MS4w
OiBVU0IgaHViIGZvdW5kDQpbICAgMTguNTUwNzkyXSBodWIgNC0wOjEuMDogNSBwb3J0cyBk
ZXRlY3RlZA0KWyAgIDE4LjU1MTE4MF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAxOC41NTExODNdIEFscmVhZHkgc2V0dXAgdGhlIEdT
SSA6MTgNClsgICAxOC41NTEyMDRdIG9oY2ktcGNpIDAwMDA6MDA6MTMuMDogZW5hYmxpbmcg
YnVzIG1hc3RlcmluZw0KWyAgIDE4LjU1MTIxMl0gb2hjaS1wY2kgMDAwMDowMDoxMy4wOiBP
SENJIFBDSSBob3N0IGNvbnRyb2xsZXINClsgICAxOC41NTE0NDRdIG9oY2ktcGNpIDAwMDA6
MDA6MTMuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA1
DQpbICAgMTguNTUxNTI3XSBvaGNpLXBjaSAwMDAwOjAwOjEzLjA6IGlycSAxOCwgaW8gbWVt
IDB4ZmRiZmMwMDANClsgICAxOC42MDcwOTJdIHVzYiB1c2I1OiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDENClsgICAxOC42MDcwOTRdIHVz
YiB1c2I1OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJp
YWxOdW1iZXI9MQ0KWyAgIDE4LjYwNzA5NV0gdXNiIHVzYjU6IFByb2R1Y3Q6IE9IQ0kgUENJ
IGhvc3QgY29udHJvbGxlcg0KWyAgIDE4LjYwNzA5NV0gdXNiIHVzYjU6IE1hbnVmYWN0dXJl
cjogTGludXggMy4xOC4wLXJjNS0yMDE0MTExNi12YW5pbGxhIG9oY2lfaGNkDQpbICAgMTgu
NjA3MDk2XSB1c2IgdXNiNTogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEzLjANClsgICAxOC42
MDczODJdIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgMTguNjA3Mzk1XSBodWIg
NS0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgIDE4LjYwNzc4N10geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxOC42MDc3OTJdIEFs
cmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNClsgICAxOC42MDc4MTRdIG9oY2ktcGNpIDAwMDA6
MDA6MTQuNTogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAgIDE4LjYwNzgyMV0gb2hjaS1w
Y2kgMDAwMDowMDoxNC41OiBPSENJIFBDSSBob3N0IGNvbnRyb2xsZXINClsgICAxOC42MDgw
NTNdIG9oY2ktcGNpIDAwMDA6MDA6MTQuNTogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNz
aWduZWQgYnVzIG51bWJlciA2DQpbICAgMTguNjA4MTM3XSBvaGNpLXBjaSAwMDAwOjAwOjE0
LjU6IGlycSAxOCwgaW8gbWVtIDB4ZmRiZmQwMDANClsgICAxOC42NjM1NzVdIHVzYiB1c2I2
OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDEN
ClsgICAxOC42NjM1NzddIHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9
MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgIDE4LjY2MzU3OF0gdXNiIHVzYjY6
IFByb2R1Y3Q6IE9IQ0kgUENJIGhvc3QgY29udHJvbGxlcg0KWyAgIDE4LjY2MzU3OV0gdXNi
IHVzYjY6IE1hbnVmYWN0dXJlcjogTGludXggMy4xOC4wLXJjNS0yMDE0MTExNi12YW5pbGxh
IG9oY2lfaGNkDQpbICAgMTguNjYzNTc5XSB1c2IgdXNiNjogU2VyaWFsTnVtYmVyOiAwMDAw
OjAwOjE0LjUNClsgICAxOC42NjM4NjJdIGh1YiA2LTA6MS4wOiBVU0IgaHViIGZvdW5kDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDoyNzowMC4wNDVdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTEgLT4gMHg5YSAtPiBJUlEgMjUgTW9kZToxIEFjdGl2ZToxKQ0KWyAg
IDE4LjY2Mzg3OF0gaHViIDYtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNClsgICAxOC42NjQy
MDBdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpb
ICAgMTguNjY0MjAyXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgMTguNjY0MjI2
XSBvaGNpLXBjaSAwMDAwOjAwOjE2LjA6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNClsgICAx
OC42NjQyMzNdIG9oY2ktcGNpIDAwMDA6MDA6MTYuMDogT0hDSSBQQ0kgaG9zdCBjb250cm9s
bGVyDQpbICAgMTguNjY0Mzg1XSBvaGNpLXBjaSAwMDAwOjAwOjE2LjA6IG5ldyBVU0IgYnVz
IHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNw0KWyAgIDE4LjY2NDQ1OF0gb2hj
aS1wY2kgMDAwMDowMDoxNi4wOiBpcnEgMTgsIGlvIG1lbSAweGZkYmZlMDAwDQpbICAgMTgu
NzIwMjYwXSB1c2IgdXNiNzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs
IGlkUHJvZHVjdD0wMDAxDQpbICAgMTguNzIwMjYyXSB1c2IgdXNiNzogTmV3IFVTQiBkZXZp
Y2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAxOC43
MjAyNjNdIHVzYiB1c2I3OiBQcm9kdWN0OiBPSENJIFBDSSBob3N0IGNvbnRyb2xsZXINClsg
ICAxOC43MjAyNjRdIHVzYiB1c2I3OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMTguMC1yYzUt
MjAxNDExMTYtdmFuaWxsYSBvaGNpX2hjZA0KWyAgIDE4LjcyMDI2NV0gdXNiIHVzYjc6IFNl
cmlhbE51bWJlcjogMDAwMDowMDoxNi4wDQpbICAgMTguNzIwNTUwXSBodWIgNy0wOjEuMDog
VVNCIGh1YiBmb3VuZA0KWyAgIDE4LjcyMDU2Nl0gaHViIDctMDoxLjA6IDQgcG9ydHMgZGV0
ZWN0ZWQNClsgICAxOC43MjA4MjddIHVoY2lfaGNkOiBVU0IgVW5pdmVyc2FsIEhvc3QgQ29u
dHJvbGxlciBJbnRlcmZhY2UgZHJpdmVyDQpbICAgMTguNzIwOTI3XSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmxwDQpbICAgMTguNzIwOTczXSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdlDQpbICAg
MTguNzIxMDQ1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVz
YnNlcmlhbA0KWyAgIDE4LjcyMTA2OV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJm
YWNlIGRyaXZlciBjcDIxMHgNClsgICAxOC43MjExNjldIHVzYnNlcmlhbDogVVNCIFNlcmlh
bCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIGNwMjEweA0KWyAgIDE4LjcyMTIwN10gdXNiY29y
ZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBjeXByZXNzX204DQpbICAgMTgu
NzIxMjI4XSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBE
ZUxvcm1lIEVhcnRobWF0ZSBVU0INClsgICAxOC43MjEyNDhdIHVzYnNlcmlhbDogVVNCIFNl
cmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIEhJRC0+Q09NIFJTMjMyIEFkYXB0ZXINClsg
ICAxOC43MjEyNzJdIHVzYnNlcmlhbDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQg
Zm9yIE5va2lhIENBLTQyIFYyIEFkYXB0ZXINClsgICAxOC43MjEzMDBdIHVzYmNvcmU6IHJl
Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgbW9zNzcyMA0KWyAgIDE4LjcyMTMyMl0g
dXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCAy
IHBvcnQgYWRhcHRlcg0KWyAgIDE4LjcyMTM1MF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBtb3M3ODQwDQpbICAgMTguNzIxMzcyXSB1c2JzZXJpYWw6IFVT
QiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3NjaGlwIDc4NDAvNzgyMCBVU0Ig
U2VyaWFsIERyaXZlcg0KWyAgIDE4LjcyMTQ1Nl0gaTgwNDI6IFBOUDogTm8gUFMvMiBjb250
cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5Lg0KWyAgIDE4LjcyMjE2MV0g
c2VyaW86IGk4MDQyIEtCRCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMQ0KWyAgIDE4LjcyMjE5
N10gc2VyaW86IGk4MDQyIEFVWCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMTINClsgICAxOC43
MjI0MjNdIG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNl
DQpbICAgMTguNzIzMjM4XSBydGNfY21vcyAwMDowMjogUlRDIGNhbiB3YWtlIGZyb20gUzQN
ClsgICAxOC43MjM1OTddIHJ0Y19jbW9zIDAwOjAyOiBydGMgY29yZTogcmVnaXN0ZXJlZCBy
dGNfY21vcyBhcyBydGMwDQpbICAgMTguNzIzNjYyXSBydGNfY21vcyAwMDowMjogYWxhcm1z
IHVwIHRvIG9uZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0NClsgICAxOC43MjM5MjNd
IEFDUEkgV2FybmluZzogU3lzdGVtSU8gcmFuZ2UgMHgwMDAwMDAwMDAwMDAwYjAwLTB4MDAw
MDAwMDAwMDAwMGIwNyBjb25mbGljdHMgd2l0aCBPcFJlZ2lvbiAweDAwMDAwMDAwMDAwMDBi
MDAtMHgwMDAwMDAwMDAwMDAwYjBmIChcU09SMSkgKDIwMTQwOTI2L3V0YWRkcmVzcy0yNTgp
DQpbICAgMTguNzIzOTI1XSBBQ1BJOiBUaGlzIGNvbmZsaWN0IG1heSBjYXVzZSByYW5kb20g
cHJvYmxlbXMgYW5kIHN5c3RlbSBpbnN0YWJpbGl0eQ0KWyAgIDE4LjcyMzkyNV0gQUNQSTog
SWYgYW4gQUNQSSBkcml2ZXIgaXMgYXZhaWxhYmxlIGZvciB0aGlzIGRldmljZSwgeW91IHNo
b3VsZCB1c2UgaXQgaW5zdGVhZCBvZiB0aGUgbmF0aXZlIGRyaXZlcg0KWyAgIDE4LjcyMzkz
MF0gcGlpeDRfc21idXMgMDAwMDowMDoxNC4wOiBTTUJ1cyBIb3N0IENvbnRyb2xsZXIgYXQg
MHhiMDAsIHJldmlzaW9uIDANClsgICAxOC43MjQwMzVdIEFDUEkgV2FybmluZzogU3lzdGVt
SU8gcmFuZ2UgMHgwMDAwMDAwMDAwMDAwYjIwLTB4MDAwMDAwMDAwMDAwMGIyNyBjb25mbGlj
dHMgd2l0aCBPcFJlZ2lvbiAweDAwMDAwMDAwMDAwMDBiMjAtMHgwMDAwMDAwMDAwMDAwYjJm
IChcU09SMikgKDIwMTQwOTI2L3V0YWRkcmVzcy0yNTgpDQpbICAgMTguNzI0MDM2XSBBQ1BJ
OiBUaGlzIGNvbmZsaWN0IG1heSBjYXVzZSByYW5kb20gcHJvYmxlbXMgYW5kIHN5c3RlbSBp
bnN0YWJpbGl0eQ0KWyAgIDE4LjcyNDAzN10gQUNQSTogSWYgYW4gQUNQSSBkcml2ZXIgaXMg
YXZhaWxhYmxlIGZvciB0aGlzIGRldmljZSwgeW91IHNob3VsZCB1c2UgaXQgaW5zdGVhZCBv
ZiB0aGUgbmF0aXZlIGRyaXZlcg0KWyAgIDE4LjcyNDAzOV0gcGlpeDRfc21idXMgMDAwMDow
MDoxNC4wOiBBdXhpbGlhcnkgU01CdXMgSG9zdCBDb250cm9sbGVyIGF0IDB4YjIwDQpbICAg
MTguNzI0MzgzXSBsaXJjX2RldjogSVIgUmVtb3RlIENvbnRyb2wgZHJpdmVyIHJlZ2lzdGVy
ZWQsIG1ham9yIDI0OCANClsgICAxOC43MjQ0MDFdIElSIE5FQyBwcm90b2NvbCBoYW5kbGVy
IGluaXRpYWxpemVkDQpbICAgMTguNzI0NDAzXSBJUiBSQzUoeC9zeikgcHJvdG9jb2wgaGFu
ZGxlciBpbml0aWFsaXplZA0KWyAgIDE4LjcyNDQwNV0gSVIgUkM2IHByb3RvY29sIGhhbmRs
ZXIgaW5pdGlhbGl6ZWQNClsgICAxOC43MjQ0MDddIElSIEpWQyBwcm90b2NvbCBoYW5kbGVy
IGluaXRpYWxpemVkDQpbICAgMTguNzI0NDEwXSBJUiBTb255IHByb3RvY29sIGhhbmRsZXIg
aW5pdGlhbGl6ZWQNClsgICAxOC43MjQ0MTJdIElSIFNBTllPIHByb3RvY29sIGhhbmRsZXIg
aW5pdGlhbGl6ZWQNClsgICAxOC43MjQ0MTRdIElSIFNoYXJwIHByb3RvY29sIGhhbmRsZXIg
aW5pdGlhbGl6ZWQNClsgICAxOC43MjQ0MTZdIElSIE1DRSBLZXlib2FyZC9tb3VzZSBwcm90
b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgMTguNzI0NDE4XSBJUiBMSVJDIGJyaWRn
ZSBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgMTguNzI0NDIwXSBJUiBYTVAgcHJvdG9jb2wg
aGFuZGxlciBpbml0aWFsaXplZA0KWyAgIDE4LjcyNDQyMl0gY3gyNTgyMTogZHJpdmVyIHZl
cnNpb24gMC4wLjEwNiBsb2FkZWQNClsgICAxOC43MjQ2NTldIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgcHZydXNiMg0KWyAgIDE4LjcyNDY2MF0gcHZydXNi
MjogVjRMIGluLXRyZWUgdmVyc2lvbjpIYXVwcGF1Z2UgV2luVFYtUFZSLVVTQjIgTVBFRzIg
RW5jb2Rlci9UdW5lcg0KWyAgIDE4LjcyNDY2MV0gcHZydXNiMjogRGVidWcgbWFzayBpcyAz
MSAoMHgxZikNClsgICAxOC43MjQ3NTZdIGY3MTgwNWY6IFVuc3VwcG9ydGVkIEZpbnRlayBk
ZXZpY2UsIHNraXBwaW5nDQpbICAgMTguNzI0ODU2XSBmNzE4ODJmZzogRm91bmQgZjcxODg5
ZWQgY2hpcCBhdCAweDYwMCwgcmV2aXNpb24gMTYNClsgICAxOC43MjQ4OTldIEFDUEkgV2Fy
bmluZzogU3lzdGVtSU8gcmFuZ2UgMHgwMDAwMDAwMDAwMDAwNjAwLTB4MDAwMDAwMDAwMDAw
MDYwNyBjb25mbGljdHMgd2l0aCBPcFJlZ2lvbiAweDAwMDAwMDAwMDAwMDA2MDUtMHgwMDAw
MDAwMDAwMDAwNjA2IChcSE1PUikgKDIwMTQwOTI2L3V0YWRkcmVzcy0yNTgpDQpbICAgMTgu
NzI0OTAwXSBBQ1BJOiBUaGlzIGNvbmZsaWN0IG1heSBjYXVzZSByYW5kb20gcHJvYmxlbXMg
YW5kIHN5c3RlbSBpbnN0YWJpbGl0eQ0KWyAgIDE4LjcyNDkwMV0gQUNQSTogSWYgYW4gQUNQ
SSBkcml2ZXIgaXMgYXZhaWxhYmxlIGZvciB0aGlzIGRldmljZSwgeW91IHNob3VsZCB1c2Ug
aXQgaW5zdGVhZCBvZiB0aGUgbmF0aXZlIGRyaXZlcg0KWyAgIDE4LjcyNTA1NV0gZjcxODgy
ZmcgZjcxODgyZmcuMTUzNjogRmFuOiAxIGlzIGluIGR1dHktY3ljbGUgbW9kZQ0KWyAgIDE4
LjcyNTA5Nl0gZjcxODgyZmcgZjcxODgyZmcuMTUzNjogRmFuOiAyIGlzIGluIGR1dHktY3lj
bGUgbW9kZQ0KWyAgIDE4LjcyNTEzOV0gZjcxODgyZmcgZjcxODgyZmcuMTUzNjogRmFuOiAz
IGlzIGluIGR1dHktY3ljbGUgbW9kZQ0KWyAgIDE4Ljg1NjMwMV0gc3A1MTAwX3RjbzogU1A1
MTAwL1NCODAwIFRDTyBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDUNClsgICAxOC44NTYz
NjNdIHNwNTEwMF90Y286IFBDSSBSZXZpc2lvbiBJRDogMHg0MQ0KWyAgIDE4Ljg1NjQyMF0g
c3A1MTAwX3RjbzogVXNpbmcgMHhmZWQ4MGIwMCBmb3Igd2F0Y2hkb2cgTU1JTyBhZGRyZXNz
DQpbICAgMTguODU2NDYxXSBzcDUxMDBfdGNvOiBMYXN0IHJlYm9vdCB3YXMgbm90IHRyaWdn
ZXJlZCBieSB3YXRjaGRvZy4NClsgICAxOC44NTY2MjRdIHNwNTEwMF90Y286IGluaXRpYWxp
emVkICgweGZmZmZjOTAwMDAzNzZiMDApLiBoZWFydGJlYXQ9NjAgc2VjIChub3dheW91dD0w
KQ0KWyAgIDE4Ljg1NjYzMF0geGVuX3dkdDogWGVuIFdhdGNoRG9nIFRpbWVyIERyaXZlciB2
MC4wMQ0KWyAgIDE4Ljg1NjY4N10geGVuX3dkdDogY2Fubm90IHJlZ2lzdGVyIG1pc2NkZXYg
b24gbWlub3I9MTMwICgtMTYpDQpbICAgMTguODU2Njk4XSB3ZHQ6IHByb2JlIG9mIHdkdCBm
YWlsZWQgd2l0aCBlcnJvciAtMTYNClsgICAxOC44NTcyNzJdIGRldmljZS1tYXBwZXI6IGlv
Y3RsOiA0LjI4LjAtaW9jdGwgKDIwMTQtMDktMTcpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEBy
ZWRoYXQuY29tDQpbICAgMTguODU3NTk5XSBkZXZpY2UtbWFwcGVyOiBjYWNoZS1wb2xpY3kt
bXE6IHZlcnNpb24gMS4yLjAgbG9hZGVkDQpbICAgMTguODU3NjAxXSBkZXZpY2UtbWFwcGVy
OiBjYWNoZSBjbGVhbmVyOiB2ZXJzaW9uIDEuMC4wIGxvYWRlZA0KWyAgIDE4Ljg1NzYwNF0g
Qmx1ZXRvb3RoOiBWaXJ0dWFsIEhDSSBkcml2ZXIgdmVyIDEuNQ0KWyAgIDE4Ljg1NzgyMl0g
Qmx1ZXRvb3RoOiBIQ0kgVUFSVCBkcml2ZXIgdmVyIDIuMg0KWyAgIDE4Ljg1NzgyNF0gQmx1
ZXRvb3RoOiBIQ0kgSDQgcHJvdG9jb2wgaW5pdGlhbGl6ZWQNClsgICAxOC44NTc4MjVdIEJs
dWV0b290aDogSENJIEJDU1AgcHJvdG9jb2wgaW5pdGlhbGl6ZWQNClsgICAxOC44NTc4MjZd
IEJsdWV0b290aDogSENJTEwgcHJvdG9jb2wgaW5pdGlhbGl6ZWQNClsgICAxOC44NTc4MjZd
IEJsdWV0b290aDogSENJQVRIM0sgcHJvdG9jb2wgaW5pdGlhbGl6ZWQNClsgICAxOC44NTc4
MjddIEJsdWV0b290aDogSENJIFRocmVlLXdpcmUgVUFSVCAoSDUpIHByb3RvY29sIGluaXRp
YWxpemVkDQpbICAgMTguODU3ODY5XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIGJjbTIwM3gNClsgICAxOC44NTc5MDFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGludGVyZmFjZSBkcml2ZXIgYnBhMTB4DQpbICAgMTguODU3OTM1XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGJmdXNiDQpbICAgMTguODU3OTY4XSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGJ0dXNiDQpbICAgMTgu
ODU4MDAyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGF0aDNr
DQpbICAgMTguODU4NzMzXSBoaWRyYXc6IHJhdyBISUQgZXZlbnRzIGRyaXZlciAoQykgSmly
aSBLb3NpbmENClsgICAxOC44NTkwMzNdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy
ZmFjZSBkcml2ZXIgdXNiaGlkDQpbICAgMTguODU5MDMzXSB1c2JoaWQ6IFVTQiBISUQgY29y
ZSBkcml2ZXINClsgICAxOC44NjA2NjFdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdn
ZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguODYwNjY0XSBBbHJlYWR5IHNldHVwIHRoZSBH
U0kgOjE2DQpbICAgMTguODYwNzk4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyNSB0cmlnZ2Vy
aW5nIDAgcG9sYXJpdHkgMQ0KWyAgIDE4Ljg2MTA3MV0geGVuOiAtLT4gcGlycT0yNSAtPiBp
cnE9MjUgKGdzaT0yNSkNClsgICAxOC44NjEyNDFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3
IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi1hdWRpbw0KWyAgIDE4Ljg2MTI4MF0gdXNiY29y
ZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdWExMDENClsgICAxOC44
NjEzMTFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVz
Yi11c3gyeQ0KWyAgIDE4Ljg2MTM0MF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJm
YWNlIGRyaXZlciBzbmQtdXNiLWNhaWFxDQpbICAgMTguODYxMzgzXSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItNmZpcmUNClsgICAxOC44NjE0
NDBdIE5ldGZpbHRlciBtZXNzYWdlcyB2aWEgTkVUTElOSyB2MC4zMC4NClsgICAxOC44NjE0
NDddIG5mbmxfYWNjdDogcmVnaXN0ZXJpbmcgd2l0aCBuZm5ldGxpbmsuDQpbICAgMTguODYx
NTEyXSBuZl9jb25udHJhY2sgdmVyc2lvbiAwLjUuMCAoMTYzODQgYnVja2V0cywgNjU1MzYg
bWF4KQ0KWyAgIDE4Ljg2MTc5OV0gY3RuZXRsaW5rIHYwLjkzOiByZWdpc3RlcmluZyB3aXRo
IG5mbmV0bGluay4NClsgICAxOC44NjIyNzldIHh0X3RpbWU6IGtlcm5lbCB0aW1lem9uZSBp
cyAtMDAwMA0KWyAgIDE4Ljg2MjMwM10gaXBfc2V0OiBwcm90b2NvbCA2DQpbICAgMTguODYy
MzUzXSBJUFZTOiBSZWdpc3RlcmVkIHByb3RvY29scyAoKQ0KWyAgIDE4Ljg2MjQ2NV0gSVBW
UzogQ29ubmVjdGlvbiBoYXNoIHRhYmxlIGNvbmZpZ3VyZWQgKHNpemU9NDA5NiwgbWVtb3J5
PTY0S2J5dGVzKQ0KWyAgIDE4Ljg2MjUzM10gSVBWUzogQ3JlYXRpbmcgbmV0bnMgc2l6ZT0x
ODQwIGlkPTANClsgICAxOC45MTIyODZdIHNvdW5kIGhkYXVkaW9DMEQyOiBhdXRvY29uZmln
OiBsaW5lX291dHM9NCAoMHgxNC8weDE1LzB4MTYvMHgxNy8weDApIHR5cGU6bGluZQ0KWyAg
IDE4LjkxMjI4N10gc291bmQgaGRhdWRpb0MwRDI6ICAgIHNwZWFrZXJfb3V0cz0wICgweDAv
MHgwLzB4MC8weDAvMHgwKQ0KWyAgIDE4LjkxMjI4OV0gc291bmQgaGRhdWRpb0MwRDI6ICAg
IGhwX291dHM9MSAoMHgxYi8weDAvMHgwLzB4MC8weDApDQpbICAgMTguOTEyMjkwXSBzb3Vu
ZCBoZGF1ZGlvQzBEMjogICAgbW9ubzogbW9ub19vdXQ9MHgwDQpbICAgMTguOTEyMjkxXSBz
b3VuZCBoZGF1ZGlvQzBEMjogICAgZGlnLW91dD0weDExLzB4MWUNClsgICAxOC45MTIyOTFd
IHNvdW5kIGhkYXVkaW9DMEQyOiAgICBpbnB1dHM6DQpbICAgMTguOTEyMjkzXSBzb3VuZCBo
ZGF1ZGlvQzBEMjogICAgICBGcm9udCBNaWM9MHgxOQ0KWyAgIDE4LjkxMjI5NF0gc291bmQg
aGRhdWRpb0MwRDI6ICAgICAgUmVhciBNaWM9MHgxOA0KWyAgIDE4LjkxMjI5NV0gc291bmQg
aGRhdWRpb0MwRDI6ICAgICAgTGluZT0weDFhDQpbICAgMTguOTI2MjYwXSB1c2IgNC01OiBu
ZXcgZnVsbC1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciAyIHVzaW5nIG9oY2ktcGNpDQpbICAg
MTguOTMyMzEyXSByYW5kb206IG5vbmJsb2NraW5nIHBvb2wgaXMgaW5pdGlhbGl6ZWQNClsg
ICAxOS4wNDk2MDhdIHVzYiA3LTM6IG5ldyBsb3ctc3BlZWQgVVNCIGRldmljZSBudW1iZXIg
MiB1c2luZyBvaGNpLXBjaQ0KWyAgIDE5LjIwODMyM10gdXNiIDctMzogTmV3IFVTQiBkZXZp
Y2UgZm91bmQsIGlkVmVuZG9yPTA0NmQsIGlkUHJvZHVjdD1jNTE3DQpbICAgMTkuMjA4MzMw
XSB1c2IgNy0zOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVjdD0yLCBT
ZXJpYWxOdW1iZXI9MA0KWyAgIDE5LjIwODMzNV0gdXNiIDctMzogUHJvZHVjdDogVVNCIFJl
Y2VpdmVyDQpbICAgMTkuMjA4MzM5XSB1c2IgNy0zOiBNYW51ZmFjdHVyZXI6IExvZ2l0ZWNo
DQpbICAgMTkuMjE2MDEwXSBpbnB1dDogTG9naXRlY2ggVVNCIFJlY2VpdmVyIGFzIC9kZXZp
Y2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxNi4wL3VzYjcvNy0zLzctMzoxLjAvMDAwMzowNDZE
OkM1MTcuMDAwMS9pbnB1dC9pbnB1dDUNClsgICAxOS4yMTY3NzldIGxvZ2l0ZWNoIDAwMDM6
MDQ2RDpDNTE3LjAwMDE6IGlucHV0LGhpZHJhdzA6IFVTQiBISUQgdjEuMTAgS2V5Ym9hcmQg
W0xvZ2l0ZWNoIFVTQiBSZWNlaXZlcl0gb24gdXNiLTAwMDA6MDA6MTYuMC0zL2lucHV0MA0K
WyAgIDE5LjIyNDQ2NF0gbG9naXRlY2ggMDAwMzowNDZEOkM1MTcuMDAwMjogZml4aW5nIHVw
IExvZ2l0ZWNoIGtleWJvYXJkIHJlcG9ydCBkZXNjcmlwdG9yDQpbICAgMTkuMjI0OTQyXSBp
bnB1dDogTG9naXRlY2ggVVNCIFJlY2VpdmVyIGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAw
MDowMDoxNi4wL3VzYjcvNy0zLzctMzoxLjEvMDAwMzowNDZEOkM1MTcuMDAwMi9pbnB1dC9p
bnB1dDYNClsgICAxOS4yMjU2MTZdIElQVlM6IGlwdnMgbG9hZGVkLg0KWyAgIDE5LjIyNTYy
OF0gbG9naXRlY2ggMDAwMzowNDZEOkM1MTcuMDAwMjogaW5wdXQsaGlkZGV2MCxoaWRyYXcx
OiBVU0IgSElEIHYxLjEwIE1vdXNlIFtMb2dpdGVjaCBVU0IgUmVjZWl2ZXJdIG9uIHVzYi0w
MDAwOjAwOjE2LjAtMy9pbnB1dDENClsgICAxOS4zNTk0MzZdIHVzYiA0LTU6IE5ldyBVU0Ig
ZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0wYTEyLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgIDE5LjM1
OTQzOF0gdXNiIDQtNTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTAsIFByb2R1Y3Q9
MiwgU2VyaWFsTnVtYmVyPTANClsgICAxOS4zNTk0MzldIHVzYiA0LTU6IFByb2R1Y3Q6IEVE
UkNsYXNzb25lDQpbICAgMTkuMzY1Mjg5XSBpcF90YWJsZXM6IChDKSAyMDAwLTIwMDYgTmV0
ZmlsdGVyIENvcmUgVGVhbQ0KWyAgIDE5LjM2NTM1NV0gVENQOiBjdWJpYyByZWdpc3RlcmVk
DQpbICAgMTkuMzY1NzMxXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEwDQpb
ICAgMTkuMzY2NjcwXSBpcDZfdGFibGVzOiAoQykgMjAwMC0yMDA2IE5ldGZpbHRlciBDb3Jl
IFRlYW0NClsgICAxOS40NTI1MzVdIHNpdDogSVB2NiBvdmVyIElQdjQgdHVubmVsaW5nIGRy
aXZlcg0KWyAgIDE5LjQ1Mjg0OF0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAx
Nw0KWyAgIDE5LjQ1MjkxN10gYnJpZGdlOiBhdXRvbWF0aWMgZmlsdGVyaW5nIHZpYSBhcnAv
aXAvaXA2dGFibGVzIGhhcyBiZWVuIGRlcHJlY2F0ZWQuIFVwZGF0ZSB5b3VyIHNjcmlwdHMg
dG8gbG9hZCBicl9uZXRmaWx0ZXIgaWYgeW91IG5lZWQgdGhpcy4NClsgICAxOS42MDg2NDZd
IEJyaWRnZSBmaXJld2FsbGluZyByZWdpc3RlcmVkDQpbICAgMTkuNjA4NjQ5XSBFYnRhYmxl
cyB2Mi4wIHJlZ2lzdGVyZWQNClsgICAxOS42MDg4NzRdIEJsdWV0b290aDogUkZDT01NIFRU
WSBsYXllciBpbml0aWFsaXplZA0KWyAgIDE5LjYwODg4MF0gQmx1ZXRvb3RoOiBSRkNPTU0g
c29ja2V0IGxheWVyIGluaXRpYWxpemVkDQpbICAgMTkuNjA4ODkxXSBCbHVldG9vdGg6IFJG
Q09NTSB2ZXIgMS4xMQ0KWyAgIDE5LjYwODg5OV0gQmx1ZXRvb3RoOiBCTkVQIChFdGhlcm5l
dCBFbXVsYXRpb24pIHZlciAxLjMNClsgICAxOS42MDg5MDBdIEJsdWV0b290aDogQk5FUCBm
aWx0ZXJzOiBwcm90b2NvbCBtdWx0aWNhc3QNClsgICAxOS42MDg5MDNdIEJsdWV0b290aDog
Qk5FUCBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQNClsgICAxOS42MDg5MDVdIEJsdWV0b290
aDogSElEUCAoSHVtYW4gSW50ZXJmYWNlIEVtdWxhdGlvbikgdmVyIDEuMg0KWyAgIDE5LjYw
ODk1M10gQmx1ZXRvb3RoOiBISURQIHNvY2tldCBsYXllciBpbml0aWFsaXplZA0KWyAgIDE5
LjYwODk5M10gS2V5IHR5cGUgY2VwaCByZWdpc3RlcmVkDQpbICAgMTkuNjA5MzQ5XSBsaWJj
ZXBoOiBsb2FkZWQgKG1vbi9vc2QgcHJvdG8gMTUvMjQpDQpbICAgMTkuNjEwNDI2XSByZWdp
c3RlcmVkIHRhc2tzdGF0cyB2ZXJzaW9uIDENClsgICAxOS42MTE5NjNdIEJ0cmZzIGxvYWRl
ZA0KWyAgIDE5LjgzMDEyOV0gY29uc29sZSBbbmV0Y29uMF0gZW5hYmxlZA0KWyAgIDE5Ljgz
MDE2M10gYXRhNDogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApDQpb
ICAgMTkuODMwMjk5XSBhdGE1OiBTQVRBIGxpbmsgZG93biAoU1N0YXR1cyAwIFNDb250cm9s
IDMwMCkNClsgICAxOS44NDg5MjZdIG5ldGNvbnNvbGU6IG5ldHdvcmsgbG9nZ2luZyBzdGFy
dGVkDQpbICAgMTkuODU1MzQyXSBydGNfY21vcyAwMDowMjogc2V0dGluZyBzeXN0ZW0gY2xv
Y2sgdG8gMjAxNC0xMS0xOCAxNDoyNzowMCBVVEMgKDE0MTYzMjA4MjApDQpbICAgMTkuODYy
MTE4XSBBTFNBIGRldmljZSBsaXN0Og0KWyAgIDE5Ljg2ODQ2NF0gICAjMDogSERBIEFUSSBT
QiBhdCAweGZkYmY4MDAwIGlycSAxNg0KWyAgIDE5Ljg3NDc5N10gICAjMTogSERBIEFUSSBI
RE1JIGF0IDB4ZmU5ZmMwMDAgaXJxIDEyNA0KWyAgIDE5Ljk4OTU2MF0gYXRhMzogU0FUQSBs
aW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEyMyBTQ29udHJvbCAzMDApDQpbICAgMTkuOTk3
ODI0XSBhdGExOiBTQVRBIGxpbmsgdXAgNi4wIEdicHMgKFNTdGF0dXMgMTMzIFNDb250cm9s
IDMwMCkNClsgICAyMC4wMDY2MjVdIGF0YTMuMDA6IEFUQS04OiBIaXRhY2hpIEhEUzcyMjAy
MEFMQTMzMCwgSktBT0EyME4sIG1heCBVRE1BLzEzMw0KWyAgIDIwLjAxNDgwNV0gYXRhMy4w
MDogMzkwNzAyOTE2OCBzZWN0b3JzLCBtdWx0aSAwOiBMQkE0OCBOQ1EgKGRlcHRoIDMxLzMy
KSwgQUENClsgICAyMC4wMjM1NzNdIGF0YTEuMDA6IEFUQS04OiBIR1NUIEhETjcyNDA0MEFM
RTY0MCwgTUpBT0E1RTAsIG1heCBVRE1BLzEzMw0KWyAgIDIwLjAzMTYwMV0gYXRhMS4wMDog
NzgxNDAzNzE2OCBzZWN0b3JzLCBtdWx0aSAwOiBMQkE0OCBOQ1EgKGRlcHRoIDMxLzMyKSwg
QUENClsgICAyMC4wNDA0MjddIGF0YTMuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTMzDQpb
ICAgMjAuMDQ5MjU2XSBhdGExLjAwOiBjb25maWd1cmVkIGZvciBVRE1BLzEzMw0KWyAgIDIw
LjA1OTIyMF0gc2NzaSAwOjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBBVEEgICAgICBIR1NU
IEhETjcyNDA0MEFMIEE1RTAgUFE6IDAgQU5TSTogNQ0KWyAgIDIwLjA3MDQ4OV0gc2QgMDow
OjA6MDogW3NkYV0gNzgxNDAzNzE2OCA1MTItYnl0ZSBsb2dpY2FsIGJsb2NrczogKDQuMDAg
VEIvMy42MyBUaUIpDQpbICAgMjAuMDcxMjU1XSBzZCAwOjA6MDowOiBBdHRhY2hlZCBzY3Np
IGdlbmVyaWMgc2cwIHR5cGUgMA0KWyAgIDIwLjA3MzQxNF0gc2NzaSAyOjA6MDowOiBEaXJl
Y3QtQWNjZXNzICAgICBBVEEgICAgICBIaXRhY2hpIEhEUzcyMjAyIEEyME4gUFE6IDAgQU5T
STogNQ0KWyAgIDIwLjA3NTEzMl0gc2QgMjowOjA6MDogW3NkYl0gMzkwNzAyOTE2OCA1MTIt
Ynl0ZSBsb2dpY2FsIGJsb2NrczogKDIuMDAgVEIvMS44MSBUaUIpDQpbICAgMjAuMDc1MjU4
XSBzZCAyOjA6MDowOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMgc2cxIHR5cGUgMA0KWyAgIDIw
LjA3NTgwMV0gc2QgMjowOjA6MDogW3NkYl0gV3JpdGUgUHJvdGVjdCBpcyBvZmYNClsgICAy
MC4wNzU4MDldIHNkIDI6MDowOjA6IFtzZGJdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwDQpb
ICAgMjAuMDc2MDQ1XSBzZCAyOjA6MDowOiBbc2RiXSBXcml0ZSBjYWNoZTogZW5hYmxlZCwg
cmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBGVUENClsgICAy
MC4wODA4NDZdICBzZGI6IHNkYjENClsgICAyMC4wODM2NDddIHNkIDI6MDowOjA6IFtzZGJd
IEF0dGFjaGVkIFNDU0kgZGlzaw0KWyAgIDIwLjE0NDQxMl0gc2QgMDowOjA6MDogW3NkYV0g
NDA5Ni1ieXRlIHBoeXNpY2FsIGJsb2Nrcw0KWyAgIDIwLjE1MTI2Ml0gc2QgMDowOjA6MDog
W3NkYV0gV3JpdGUgUHJvdGVjdCBpcyBvZmYNClsgICAyMC4xNTc4MTFdIHNkIDA6MDowOjA6
IFtzZGFdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwDQpbICAgMjAuMTY0MjQ5XSBzZCAwOjA6
MDowOiBbc2RhXSBXcml0ZSBjYWNoZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwg
ZG9lc24ndCBzdXBwb3J0IERQTyBvciBGVUENClsgICAyMC4yMzY3MTRdICBzZGE6IHNkYTEg
c2RhMiBzZGEzIHNkYTQNClsgICAyMC4yNDcyNDRdIHNkIDA6MDowOjA6IFtzZGFdIEF0dGFj
aGVkIFNDU0kgZGlzaw0KWyAgIDIwLjI1NzUzNl0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1l
bW9yeTogMTEwNEsgKGZmZmZmZmZmODIzMDYwMDAgLSBmZmZmZmZmZjgyNDFhMDAwKQ0KWyAg
IDIwLjI2NTMxMF0gV3JpdGUgcHJvdGVjdGluZyB0aGUga2VybmVsIHJlYWQtb25seSBkYXRh
OiAxODQzMmsNClsgICAyMC4yODc1MjhdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6
IDM1NksgKGZmZmY4ODAwMDFiYTcwMDAgLSBmZmZmODgwMDAxYzAwMDAwKQ0KWyAgIDIwLjI5
NDc2MV0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMTY0OEsgKGZmZmY4ODAwMDIw
NjQwMDAgLSBmZmZmODgwMDAyMjAwMDAwKQ0KWyAgIDIwLjM0MzEyN10gdWRldmRbMTYwNl06
IHN0YXJ0aW5nIHZlcnNpb24gMTc1DQpbICAgMjEuNDQ4MTg4XSBFWFQ0LWZzIChkbS0wKTog
bW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IChudWxs
KQ0KWyAgIDI0LjAyNzI2Ml0gdWRldmRbMTk4OV06IHN0YXJ0aW5nIHZlcnNpb24gMTc1DQpb
ICAgMjcuMzA1MDE1XSBFWFQ0LWZzIChkbS0wKTogcmUtbW91bnRlZC4gT3B0czogKG51bGwp
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNzowOC43MjRdIC0tTUFSSy0tDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNzoxOC43MjRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoy
NzoyOC43MjRdIC0tTUFSSy0tDQpbICAgNTQuMTY5MzI0XSBFWFQ0LWZzIChkbS0wKTogcmUt
bW91bnRlZC4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJvDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNzozOC43MjVdIC0tTUFSSy0tDQpbICAgNTguMjQ1ODcxXSBBZGRpbmcg
MjA5NzE0OGsgc3dhcCBvbiAvZGV2L21hcHBlci9zZXJ2ZWVyc3RlcnRqZS1zd2FwLiAgUHJp
b3JpdHk6LTEgZXh0ZW50czoxIGFjcm9zczoyMDk3MTQ4ayANClsgICA2NC40ODA0NTldIEVY
VDQtZnMgKHNkYTEpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9k
ZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJvDQpbICAgNjYuOTE3NTczXSBy
ODE2OSAwMDAwOjBkOjAwLjAgZXRoMDogbGluayBkb3duDQpbICAgNjYuOTE3NjcwXSByODE2
OSAwMDAwOjBkOjAwLjAgZXRoMDogbGluayBkb3duDQpbICAgNjcuNDE0MjE1XSByODE2OSAw
MDAwOjBjOjAwLjAgZXRoMTogbGluayBkb3duDQpbICAgNjcuNDIxMTg4XSByODE2OSAwMDAw
OjBjOjAwLjAgZXRoMTogbGluayBkb3duDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNzo0OC43
MjVdIC0tTUFSSy0tDQpbICAgNjguNjA5NjE5XSByODE2OSAwMDAwOjBkOjAwLjAgZXRoMDog
bGluayB1cA0KWyAgIDY5LjUxNDc0MF0gcjgxNjkgMDAwMDowYzowMC4wIGV0aDE6IGxpbmsg
dXANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI3OjU4LjcyNV0gLS1NQVJLLS0NCihYRU4pIFsy
MDE0LTExLTE4IDE0OjI4OjA4LjcyNV0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0
OjI4OjE4LjcyNl0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjI4OjI4LjcyNl0g
LS1NQVJLLS0NClsgIDEwOS42Nzc2MDNdIEVYVDQtZnMgKGRtLTIpOiBtb3VudGVkIGZpbGVz
eXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1y
ZW1vdW50LXJvDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyODozOC43MjZdIC0tTUFSSy0tDQpb
ICAxMTkuMzA1MTk1XSBFWFQ0LWZzIChkbS01MCk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRo
IG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8N
CihYRU4pIFsyMDE0LTExLTE4IDE0OjI4OjQ4LjcyNl0gLS1NQVJLLS0NClsgIDEzMC4zODY2
NzBdIEVYVDQtZnMgKGRtLTQ5KTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBk
YXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6Mjg6NTguNzI3XSAtLU1BUkstLQ0KWyAgMTQwLjQ2NDA3NV0gRVhUNC1m
cyAoZG0tNDgpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4g
T3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJvDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDoyOTowOC43MjddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyOToxOC43Mjdd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyOToyOC43MjddIC0tTUFSSy0tDQpb
ICAxNzEuMDM0MDMzXSBFWFQ0LWZzIChkbS00NSk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRo
IG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8N
CihYRU4pIFsyMDE0LTExLTE4IDE0OjI5OjM4LjcyOF0gLS1NQVJLLS0NClsgIDE4NS45OTQw
MTBdIEVYVDQtZnMgKGRtLTQ3KTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBk
YXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6Mjk6NDguNzI4XSAtLU1BUkstLQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6
Mjk6NTguNzI4XSAtLU1BUkstLQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzA6MDguNzI4XSAt
LU1BUkstLQ0KWyAgMjA4LjY1MDA4NF0gRVhUNC1mcyAoZG0tNDYpOiBtb3VudGVkIGZpbGVz
eXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1y
ZW1vdW50LXJvDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMDoxOC43MjldIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDozMDoyOC43MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozMDozOC43MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMDo0
OC43MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMDo1OC43MzBdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMTowOC43MzBdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDozMToxOC43MzBdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozMToyOC43MzFdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMTozOC43MzFd
IC0tTUFSSy0tDQpbICAzMDMuMjkxMTUzXSBFWFQ0LWZzIChzZGIxKTogbW91bnRlZCBmaWxl
c3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9
cmVtb3VudC1ybw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzE6NDguNzMxXSAtLU1BUkstLQ0K
WyAgMzE2LjQ0NDg2MV0gZGV2aWNlIHZpZjEuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUN
CihkMSkgWzIwMTQtMTEtMTggMTQ6MzE6NTcuMTkzXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBo
eXNpY2FsIG1lbW9yeQ0KKGQxKSBbMjAxNC0xMS0xOCAxNDozMTo1Ny4xOTNdIGFib3V0IHRv
IGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMTo1Ny40NjNdIHRyYXBz
LmM6MjU3OTpkMXYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuDQpbICAzMTcu
MjI4MDMxXSB4ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDE3LCBwcm90
b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAgMzE3LjI0MzU4MV0g
eGVuLWJsa2JhY2s6cmluZy1yZWYgOSwgZXZlbnQtY2hhbm5lbCAxOCwgcHJvdG9jb2wgMSAo
eDg2XzY0LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDMxNy4yNjM0NzJdIHZpZiB2aWYt
MS0wIHZpZjEuMDogR3Vlc3QgUnggcmVhZHkNClsgIDMxNy4yNzQ4MzhdIHhlbl9icmlkZ2U6
IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzE3LjI4NjA1
M10geGVuX2JyaWRnZTogcG9ydCAxKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRl
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMTo1OC43MzFdIC0tTUFSSy0tDQpbICAzMjIuMjY3
MDU1XSBkZXZpY2UgdmlmMi4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQyKSBbMjAx
NC0xMS0xOCAxNDozMjowMi45ODJdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVt
b3J5DQooZDIpIFsyMDE0LTExLTE4IDE0OjMyOjAyLjk4Ml0gYWJvdXQgdG8gZ2V0IHN0YXJ0
ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjAzLjA1OV0gdHJhcHMuYzoyNTc5OmQy
djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAw
MDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDMyMi44MTQ1NjhdIHhl
bi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4
Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzMjMuODMwNzIyXSB2aWYgdmlmLTIt
MCB2aWYyLjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzMjMuODQxNjQ1XSB4ZW5fYnJpZGdlOiBw
b3J0IDIodmlmMi4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDMyMy44NTIzNDNd
IHhlbl9icmlkZ2U6IHBvcnQgMih2aWYyLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MzI6MDguNzMyXSAtLU1BUkstLQ0KWyAgMzI4LjE2MTgy
Nl0gZGV2aWNlIHZpZjMuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNCihkMykgWzIwMTQt
MTEtMTggMTQ6MzI6MDguODg1XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9y
eQ0KKGQzKSBbMjAxNC0xMS0xOCAxNDozMjowOC44ODVdIGFib3V0IHRvIGdldCBzdGFydGVk
Li4uDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMjowOC45NzVdIHRyYXBzLmM6MjU3OTpkM3Yw
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAw
MDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuDQpbICAzMjguNzMwMTMzXSB4ZW4t
YmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDE3LCBwcm90b2NvbCAxICh4ODZf
NjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAgMzI5LjkxNzk0NV0gdmlmIHZpZi0zLTAg
dmlmMy4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzI5LjkyODM1MF0geGVuX2JyaWRnZTogcG9y
dCAzKHZpZjMuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzMjkuOTM4NzE0XSB4
ZW5fYnJpZGdlOiBwb3J0IDModmlmMy4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsg
IDMzMi4yODQ2NzJdIHhlbl9icmlkZ2U6IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2Fy
ZGluZyBzdGF0ZQ0KWyAgMzM0LjA3MzA5OF0gZGV2aWNlIHZpZjQuMCBlbnRlcmVkIHByb21p
c2N1b3VzIG1vZGUNCihkNCkgWzIwMTQtMTEtMTggMTQ6MzI6MTQuNzkxXSBtYXBwaW5nIGtl
cm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQ0KSBbMjAxNC0xMS0xOCAxNDozMjoxNC43
OTFdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMjox
NC44NjZdIHRyYXBzLmM6MjU3OTpkNHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZm
ZmYuDQpbICAzMzQuNTUyNzYzXSB4ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFu
bmVsIDEwLCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAg
MzM0LjY5NTc2MF0gdmlmIHZpZi00LTAgdmlmNC4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzM0
LjcwNTUzMF0geGVuX2JyaWRnZTogcG9ydCA0KHZpZjQuMCkgZW50ZXJlZCBmb3J3YXJkaW5n
IHN0YXRlDQpbICAzMzQuNzE1MjMwXSB4ZW5fYnJpZGdlOiBwb3J0IDQodmlmNC4wKSBlbnRl
cmVkIGZvcndhcmRpbmcgc3RhdGUNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjE3LjExMl0g
Z3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byAyIGZy
YW1lcw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzI6MTguNzMyXSAtLU1BUkstLQ0KWyAgMzM4
Ljg5NDYyNF0geGVuX2JyaWRnZTogcG9ydCAyKHZpZjIuMCkgZW50ZXJlZCBmb3J3YXJkaW5n
IHN0YXRlDQpbICAzNDAuMDIyMjc5XSBkZXZpY2UgdmlmNS4wIGVudGVyZWQgcHJvbWlzY3Vv
dXMgbW9kZQ0KKGQ1KSBbMjAxNC0xMS0xOCAxNDozMjoyMC43ODJdIG1hcHBpbmcga2VybmVs
IGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDUpIFsyMDE0LTExLTE4IDE0OjMyOjIwLjc4Ml0g
YWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjIwLjg2
MV0gdHJhcHMuYzoyNTc5OmQ1djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4N
ClsgIDM0MC42MTk0MDZdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwg
MTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzNDEu
NjM1NDA4XSB2aWYgdmlmLTUtMCB2aWY1LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzNDEuNjQ0
NjI2XSB4ZW5fYnJpZGdlOiBwb3J0IDUodmlmNS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3Rh
dGUNClsgIDM0MS42NTM4MjddIHhlbl9icmlkZ2U6IHBvcnQgNSh2aWY1LjApIGVudGVyZWQg
Zm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzQ0Ljk3MTY4Ml0geGVuX2JyaWRnZTogcG9ydCAzKHZp
ZjMuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNDYuMDgxOTUxXSBkZXZpY2Ug
dmlmNi4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ2KSBbMjAxNC0xMS0xOCAxNDoz
MjoyNi44NzldIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDYpIFsy
MDE0LTExLTE4IDE0OjMyOjI2Ljg3OV0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4p
IFsyMDE0LTExLTE4IDE0OjMyOjI2Ljk5Ml0gdHJhcHMuYzoyNTc5OmQ2djAgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAw
IHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM0Ni43MDgzMzZdIHhlbi1ibGtiYWNrOnJp
bmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBl
cnNpc3RlbnQgZ3JhbnRzDQpbICAzNDcuNzI2MDk4XSB2aWYgdmlmLTYtMCB2aWY2LjA6IEd1
ZXN0IFJ4IHJlYWR5DQpbICAzNDcuNzM0NzEwXSB4ZW5fYnJpZGdlOiBwb3J0IDYodmlmNi4w
KSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM0Ny43NDMyNjFdIHhlbl9icmlkZ2U6
IHBvcnQgNih2aWY2LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KKFhFTikgWzIwMTQt
MTEtMTggMTQ6MzI6MjguNzMyXSAtLU1BUkstLQ0KWyAgMzQ5LjcxNjAwOF0geGVuX2JyaWRn
ZTogcG9ydCA0KHZpZjQuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNTIuMTk3
NzQyXSBkZXZpY2UgdmlmNy4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ3KSBbMjAx
NC0xMS0xOCAxNDozMjozMi45MjhdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVt
b3J5DQooZDcpIFsyMDE0LTExLTE4IDE0OjMyOjMyLjkyOF0gYWJvdXQgdG8gZ2V0IHN0YXJ0
ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjMzLjAwN10gdHJhcHMuYzoyNTc5OmQ3
djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAw
MDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM1Mi43NjUyNDddIHhl
bi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4
Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzNTMuNzgxNDg5XSB2aWYgdmlmLTct
MCB2aWY3LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzNTMuNzg5Njg2XSB4ZW5fYnJpZGdlOiBw
b3J0IDcodmlmNy4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM1My43OTc2MjZd
IHhlbl9icmlkZ2U6IHBvcnQgNyh2aWY3LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0K
WyAgMzU2LjY5OTE4Nl0geGVuX2JyaWRnZTogcG9ydCA1KHZpZjUuMCkgZW50ZXJlZCBmb3J3
YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMjozOC43MzJdIC0tTUFSSy0t
DQpbICAzNTguMzAzMjM5XSBkZXZpY2UgdmlmOC4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9k
ZQ0KKGQ4KSBbMjAxNC0xMS0xOCAxNDozMjozOS4wNjBdIG1hcHBpbmcga2VybmVsIGludG8g
cGh5c2ljYWwgbWVtb3J5DQooZDgpIFsyMDE0LTExLTE4IDE0OjMyOjM5LjA2MF0gYWJvdXQg
dG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjM5LjEzOF0gdHJh
cHMuYzoyNTc5OmQ4djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0
IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM1
OC44MjQ2MTNdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHBy
b3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzNTguOTcxNjI1
XSB2aWYgdmlmLTgtMCB2aWY4LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzNTguOTc5MjA0XSB4
ZW5fYnJpZGdlOiBwb3J0IDgodmlmOC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsg
IDM1OC45ODY2NDFdIHhlbl9icmlkZ2U6IHBvcnQgOCh2aWY4LjApIGVudGVyZWQgZm9yd2Fy
ZGluZyBzdGF0ZQ0KWyAgMzYyLjc3NjE3NF0geGVuX2JyaWRnZTogcG9ydCA2KHZpZjYuMCkg
ZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNjQuMzMyNDEzXSBkZXZpY2UgdmlmOS4w
IGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ5KSBbMjAxNC0xMS0xOCAxNDozMjo0NS4z
ODhdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDkpIFsyMDE0LTEx
LTE4IDE0OjMyOjQ1LjM4OF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0
LTExLTE4IDE0OjMyOjQ1LjQ3N10gdHJhcHMuYzoyNTc5OmQ5djAgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4
MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM2NS4yNDAyMjBdIHhlbi1ibGtiYWNrOnJpbmctcmVm
IDgsIGV2ZW50LWNoYW5uZWwgMTcsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3Rl
bnQgZ3JhbnRzDQpbICAzNjYuMjU5NTg0XSB2aWYgdmlmLTktMCB2aWY5LjA6IEd1ZXN0IFJ4
IHJlYWR5DQpbICAzNjYuMjY2MjAxXSB4ZW5fYnJpZGdlOiBwb3J0IDkodmlmOS4wKSBlbnRl
cmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM2Ni4yNzI2NzhdIHhlbl9icmlkZ2U6IHBvcnQg
OSh2aWY5LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6MzI6NDguNzMyXSAtLU1BUkstLQ0KWyAgMzY4Ljc5OTc2OV0geGVuX2JyaWRnZTogcG9y
dCA3KHZpZjcuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozMjo1MC4yNzBdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRy
YWNrIHNpemUgdG8gMyBmcmFtZXMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjUwLjI4OF0g
Z3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA0IGZy
YW1lcw0KWyAgMzcwLjc1OTQxNV0gZGV2aWNlIHZpZjEwLjAgZW50ZXJlZCBwcm9taXNjdW91
cyBtb2RlDQooZDEwKSBbMjAxNC0xMS0xOCAxNDozMjo1MS40NzddIG1hcHBpbmcga2VybmVs
IGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDEwKSBbMjAxNC0xMS0xOCAxNDozMjo1MS40Nzdd
IGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMjo1MS41
NjVdIHRyYXBzLmM6MjU3OTpkMTB2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAw
YzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZm
Lg0KWyAgMzcxLjMxOTI3MV0geGVuLWJsa2JhY2s6cmluZy1yZWYgOCwgZXZlbnQtY2hhbm5l
bCAxMCwgcHJvdG9jb2wgMSAoeDg2XzY0LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDM3
Mi4zMzY1MDBdIHZpZiB2aWYtMTAtMCB2aWYxMC4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzcy
LjM0MzA0Ml0geGVuX2JyaWRnZTogcG9ydCAxMCh2aWYxMC4wKSBlbnRlcmVkIGZvcndhcmRp
bmcgc3RhdGUNClsgIDM3Mi4zNDk4MzBdIHhlbl9icmlkZ2U6IHBvcnQgMTAodmlmMTAuMCkg
ZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNzQuMDIzODY2XSB4ZW5fYnJpZGdlOiBw
b3J0IDgodmlmOC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjMyOjU3LjI1Nl0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFw
dHJhY2sgc2l6ZSB0byA1IGZyYW1lcw0KWyAgMzc2LjkwMjk2N10gZGV2aWNlIHZpZjExLjAg
ZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQooZDExKSBbMjAxNC0xMS0xOCAxNDozMjo1Ny42
MThdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDExKSBbMjAxNC0x
MS0xOCAxNDozMjo1Ny42MThdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDozMjo1Ny43MTVdIHRyYXBzLmM6MjU3OTpkMTF2MCBEb21haW4gYXR0ZW1w
dGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8g
MHgwMDAwMDAwMDAwMDBmZmZmLg0KWyAgMzc3LjQ4MTMwN10geGVuLWJsa2JhY2s6cmluZy1y
ZWYgOCwgZXZlbnQtY2hhbm5lbCAxNywgcHJvdG9jb2wgMSAoeDg2XzY0LWFiaSkgcGVyc2lz
dGVudCBncmFudHMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjU4LjczM10gLS1NQVJLLS0N
ClsgIDM3OC42NTA2MDRdIHZpZiB2aWYtMTEtMCB2aWYxMS4wOiBHdWVzdCBSeCByZWFkeQ0K
WyAgMzc4LjY1NzE4MF0geGVuX2JyaWRnZTogcG9ydCAxMSh2aWYxMS4wKSBlbnRlcmVkIGZv
cndhcmRpbmcgc3RhdGUNClsgIDM3OC42NjM4NTFdIHhlbl9icmlkZ2U6IHBvcnQgMTEodmlm
MTEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzODEuMjczNTU2XSB4ZW5fYnJp
ZGdlOiBwb3J0IDkodmlmOS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM4NC4y
NTkzODddIGRldmljZSB2aWYxMi4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQxMikg
WzIwMTQtMTEtMTggMTQ6MzM6MDQuOTgxXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2Fs
IG1lbW9yeQ0KKGQxMikgWzIwMTQtMTEtMTggMTQ6MzM6MDQuOTgxXSBhYm91dCB0byBnZXQg
c3RhcnRlZC4uLg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MDUuMDczXSB0cmFwcy5jOjI1
Nzk6ZDEydjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20g
MHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM4NC44ODU4
MDNdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29s
IDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzODUuOTAyODg0XSB2aWYg
dmlmLTEyLTAgdmlmMTIuMDogR3Vlc3QgUnggcmVhZHkNClsgIDM4NS45MDk0MjBdIHhlbl9i
cmlkZ2U6IHBvcnQgMTIodmlmMTIuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAz
ODUuOTE2MDYyXSB4ZW5fYnJpZGdlOiBwb3J0IDEyKHZpZjEyLjApIGVudGVyZWQgZm9yd2Fy
ZGluZyBzdGF0ZQ0KWyAgMzg3LjM1MDUwM10geGVuX2JyaWRnZTogcG9ydCAxMCh2aWYxMC4w
KSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMzOjA4
LjczM10gLS1NQVJLLS0NClsgIDM5MC4zNDE0NjldIGRldmljZSB2aWYxMy4wIGVudGVyZWQg
cHJvbWlzY3VvdXMgbW9kZQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MTEuMTA4XSBBTUQt
Vmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4YTQsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MTEuMTA4XSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE0LCB0eXBlID0gMHg3LCByb290IHRhYmxl
ID0gMHg1MDRlNzIwMDAsIGRvbWFpbiA9IDEzLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDE0LTExLTE4IDE0OjMzOjExLjEwOF0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowMzowNi4w
IGZyb20gZG9tMCB0byBkb20xMw0KKGQxMykgWzIwMTQtMTEtMTggMTQ6MzM6MTEuMTE2XSBt
YXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQxMykgWzIwMTQtMTEtMTgg
MTQ6MzM6MTEuMTE2XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLg0KWyAgMzkwLjQ3NTgyOV0g
eGVuX3BjaWJhY2s6IHZwY2k6IDAwMDA6MDM6MDYuMDogYXNzaWduIHRvIHZpcnR1YWwgc2xv
dCAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzoxMS4zMzddIHRyYXBzLmM6MjU3OTpkMTN2
MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAw
MDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLg0KWyAgMzkxLjA5MDk2Nl0geGVu
LWJsa2JhY2s6cmluZy1yZWYgOSwgZXZlbnQtY2hhbm5lbCAxMSwgcHJvdG9jb2wgMSAoeDg2
XzY0LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDM5Mi4xODg5NzJdIHBjaWJhY2sgMDAw
MDowMzowNi4wOiBlbmFibGluZyBkZXZpY2UgKDAwMDAgLT4gMDAwMSkNClsgIDM5Mi4xOTU4
ODhdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDIyIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpb
ICAzOTIuMjAyNzM3XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjIyDQpbICAzOTIuMjEwNzc3
XSBwY2liYWNrIDAwMDA6MDM6MDYuMDogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAgMzky
LjIyOTI4MV0gdmlmIHZpZi0xMy0wIHZpZjEzLjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzOTIu
MjM1ODEyXSB4ZW5fYnJpZGdlOiBwb3J0IDEzKHZpZjEzLjApIGVudGVyZWQgZm9yd2FyZGlu
ZyBzdGF0ZQ0KWyAgMzkyLjI0MjU2Ml0geGVuX2JyaWRnZTogcG9ydCAxMyh2aWYxMy4wKSBl
bnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM5My42OTQwODVdIHhlbl9icmlkZ2U6IHBv
cnQgMTEodmlmMTEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzOTYuNzI4OTQz
XSBkZXZpY2UgdmlmMTQuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNCihkMTQpIFsyMDE0
LTExLTE4IDE0OjMzOjE3LjQ0OF0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1v
cnkNCihkMTQpIFsyMDE0LTExLTE4IDE0OjMzOjE3LjQ0OF0gYWJvdXQgdG8gZ2V0IHN0YXJ0
ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjMzOjE3LjUzOV0gdHJhcHMuYzoyNTc5OmQx
NHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAw
MDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuDQpbICAzOTcuMjk0MDYyXSB4
ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDEwLCBwcm90b2NvbCAxICh4
ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6
MTguNzMzXSAtLU1BUkstLQ0KWyAgMzk4LjMxMjU0OV0gdmlmIHZpZi0xNC0wIHZpZjE0LjA6
IEd1ZXN0IFJ4IHJlYWR5DQpbICAzOTguMzE5MDU3XSB4ZW5fYnJpZGdlOiBwb3J0IDE0KHZp
ZjE0LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzk4LjMyNTY3OV0geGVuX2Jy
aWRnZTogcG9ydCAxNCh2aWYxNC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNCihYRU4p
IFsyMDE0LTExLTE4IDE0OjMzOjE5LjUwOF0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNy
ZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA2IGZyYW1lcw0KWyAgNDAwLjk0Mzc3OV0geGVuX2Jy
aWRnZTogcG9ydCAxMih2aWYxMi4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDQw
Mi43MzIwMTldIGRldmljZSB2aWYxNS4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQx
NSkgWzIwMTQtMTEtMTggMTQ6MzM6MjMuNDY1XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNp
Y2FsIG1lbW9yeQ0KKGQxNSkgWzIwMTQtMTEtMTggMTQ6MzM6MjMuNDY1XSBhYm91dCB0byBn
ZXQgc3RhcnRlZC4uLg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MjMuNTU0XSB0cmFwcy5j
OjI1Nzk6ZDE1djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDQwMy4z
MDk2MzFdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3Rv
Y29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICA0MDQuMzI3MDAxXSB2
aWYgdmlmLTE1LTAgdmlmMTUuMDogR3Vlc3QgUnggcmVhZHkNClsgIDQwNC4zMzM2MTddIHZw
bl9icmlkZ2U6IHBvcnQgMSh2aWYxNS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsg
IDQwNC4zNDAzMTJdIHZwbl9icmlkZ2U6IHBvcnQgMSh2aWYxNS4wKSBlbnRlcmVkIGZvcndh
cmRpbmcgc3RhdGUNClsgIDQwNy4yODczNjRdIHhlbl9icmlkZ2U6IHBvcnQgMTModmlmMTMu
MCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzoy
OC43MzNdIC0tTUFSSy0tDQpbICA0MDkuNjQ1MjgwXSBkZXZpY2UgdmlmMTYuMCBlbnRlcmVk
IHByb21pc2N1b3VzIG1vZGUNClsgIDQwOS44NzkyNjZdIGRldmljZSB2aWYxNi4wLWVtdSBl
bnRlcmVkIHByb21pc2N1b3VzIG1vZGUNClsgIDQwOS44OTE1NDFdIHhlbl9icmlkZ2U6IHBv
cnQgMTYodmlmMTYuMC1lbXUpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgNDA5Ljg5
ODEwM10geGVuX2JyaWRnZTogcG9ydCAxNih2aWYxNi4wLWVtdSkgZW50ZXJlZCBmb3J3YXJk
aW5nIHN0YXRlDQpbICA0MTAuOTgyNDU1XSBwY2liYWNrIDAwMDA6MDg6MDAuMDogcmVzdG9y
aW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHgzYyAod2FzIDB4MTAwLCB3cml0aW5nIDB4
MTA3KQ0KWyAgNDEwLjk5MTAxM10gcGNpYmFjayAwMDAwOjA4OjAwLjA6IHJlc3RvcmluZyBj
b25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4MTAgKHdhcyAweDQsIHdyaXRpbmcgMHhmZTBmZTAw
NCkNClsgIDQxMC45OTk1MjVdIHBjaWJhY2sgMDAwMDowODowMC4wOiByZXN0b3JpbmcgY29u
ZmlnIHNwYWNlIGF0IG9mZnNldCAweGMgKHdhcyAweDAsIHdyaXRpbmcgMHgxMCkNCihYRU4p
IFsyMDE0LTExLTE4IDE0OjMzOjMxLjY2M10gaW8uYzo1NTI6IGQxNjogYmluZDogbV9nc2k9
MzcgZ19nc2k9MzYgZGV2PTAwLjAwLjUgaW50eD0wIGZmZmY4MzA1MTc5NWRkYTgNCihYRU4p
IFsyMDE0LTExLTE4IDE0OjMzOjMyLjA1M10gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweDgwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozMzozMi4wNTNdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4ODAwLCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHgzZmFhZjAwMDAsIGRvbWFp
biA9IDE2LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMzOjMyLjA1
M10gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowODowMC4wIGZyb20gZG9tMCB0byBkb20xNg0K
WyAgNDEyLjQyNDgzN10gcGNpYmFjayAwMDAwOjBhOjAwLjA6IHJlc3RvcmluZyBjb25maWcg
c3BhY2UgYXQgb2Zmc2V0IDB4M2MgKHdhcyAweDEwMCwgd3JpdGluZyAweDEwYSkNClsgIDQx
Mi40MzEzNzRdIHBjaWJhY2sgMDAwMDowYTowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNl
IGF0IG9mZnNldCAweDEwICh3YXMgMHg0LCB3cml0aW5nIDB4ZmUyMDAwMDQpDQpbICA0MTIu
NDM3Nzg2XSBwY2liYWNrIDAwMDA6MGE6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBh
dCBvZmZzZXQgMHhjICh3YXMgMHgwLCB3cml0aW5nIDB4MTApDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozMzozMy4xMDBdIGlvLmM6NTUyOiBkMTY6IGJpbmQ6IG1fZ3NpPTQ3IGdfZ3NpPTQw
IGRldj0wMC4wMC42IGludHg9MCBmZmZmODMwM2ZhYWYyNWE4DQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozMzozMy4xMDVdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHhhMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MzMu
MTA1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEwMCwg
dHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4M2ZhYWYwMDAwLCBkb21haW4gPSAxNiwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzozMy4xMDVdIEFNRC1WaTog
UmUtYXNzaWduIDAwMDA6MGE6MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTYNCihkMTYpIFsyMDE0
LTExLTE4IDE0OjMzOjMzLjExNl0gSFZNIExvYWRlcg0KKGQxNikgWzIwMTQtMTEtMTggMTQ6
MzM6MzMuMTE2XSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjDQooZDE2KSBbMjAxNC0xMS0xOCAx
NDozMzozMy4xMTZdIFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCAx
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4xMTZdIFN5c3RlbSByZXF1ZXN0ZWQgU2Vh
QklPUw0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMTE2XSBDUFUgc3BlZWQgaXMgMzIw
MCBNSHoNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjExNl0gUmVsb2NhdGluZyBndWVz
dCBtZW1vcnkgZm9yIGxvd21lbSBNTUlPIHNwYWNlIGRpc2FibGVkDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozMzozMy4xMTddIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMCBjaGFuZ2Vk
IDAgLT4gNQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMTE3XSBQQ0ktSVNBIGxpbmsg
MCByb3V0ZWQgdG8gSVJRNQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMTE3XSBpcnEu
YzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwDQooZDE2KSBbMjAxNC0x
MS0xOCAxNDozMzozMy4xMTddIFBDSS1JU0EgbGluayAxIHJvdXRlZCB0byBJUlExMA0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMTE4XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5r
IDIgY2hhbmdlZCAwIC0+IDExDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4xMThdIFBD
SS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6
MzMuMTE4XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDMgY2hhbmdlZCAwIC0+IDUNCihk
MTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjExOF0gUENJLUlTQSBsaW5rIDMgcm91dGVkIHRv
IElSUTUNClsgIDQxMi40NzQ1MTNdIHhlbl9wY2liYWNrOiB2cGNpOiAwMDAwOjA4OjAwLjA6
IGFzc2lnbiB0byB2aXJ0dWFsIHNsb3QgMA0KWyAgNDEyLjQ4MTY5NV0geGVuX3BjaWJhY2s6
IHZwY2k6IDAwMDA6MGE6MDAuMDogYXNzaWduIHRvIHZpcnR1YWwgc2xvdCAxDQooZDE2KSBb
MjAxNC0xMS0xOCAxNDozMzozMy4xMzRdIHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1DQooZDE2
KSBbMjAxNC0xMS0xOCAxNDozMzozMy4xNDFdIHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMA0K
KGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMTQ1XSBwY2kgZGV2IDAyOjAgSU5UQS0+SVJR
MTENCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjE1Nl0gcGNpIGRldiAwNDowIElOVEEt
PklSUTUNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjE2Ml0gcGNpIGRldiAwNTowIElO
VEEtPklSUTEwDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4xNjldIHBjaSBkZXYgMDY6
MCBJTlRBLT5JUlExMQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMjE4XSBObyBSQU0g
aW4gaGlnaCBtZW1vcnk7IHNldHRpbmcgaGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAw
MDAwMDANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjIxOF0gcGNpIGRldiAwMzowIGJh
ciAxMCBzaXplIDAwMjAwMDAwMDogMGYwMDAwMDA4DQooZDE2KSBbMjAxNC0xMS0xOCAxNDoz
MzozMy4yMjFdIHBjaSBkZXYgMDI6MCBiYXIgMTQgc2l6ZSAwMDEwMDAwMDA6IDBmMjAwMDAw
OA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMjIzXSBwY2kgZGV2IDA2OjAgYmFyIDEw
IHNpemUgMDAwMjAwMDAwOiAwZjMwMDAwMDQNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMzOjMz
LjIyM10gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAw
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4yMjldIHBjaSBkZXYgMDQ6MCBiYXIgMzAg
c2l6ZSAwMDAwNDAwMDA6IDBmMzIwMDAwMA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMu
MjMxXSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAwMDIwMDAwOiAwZjMyNDAwMDANCihk
MTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjIzMV0gcGNpIGRldiAwMzowIGJhciAzMCBzaXpl
IDAwMDAxMDAwMDogMGYzMjYwMDAwDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4yMzJd
IHBjaSBkZXYgMDU6MCBiYXIgMTAgc2l6ZSAwMDAwMDIwMDA6IDBmMzI3MDAwNA0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MzM6MzMuMjMyXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYz
MjcwIG1mbj1mZTBmZSBucj0xDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4yMzhdIHBj
aSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDA6IDBmMzI3MjAwMA0KKGQxNikgWzIw
MTQtMTEtMTggMTQ6MzM6MzMuMjM5XSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAw
MTAwOiAwMDAwMGMwMDENCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjI0MV0gcGNpIGRl
diAwNDowIGJhciAxNCBzaXplIDAwMDAwMDA0MDogMDAwMDBjMTAxDQooZDE2KSBbMjAxNC0x
MS0xOCAxNDozMzozMy4yNDRdIHBjaSBkZXYgMDE6MiBiYXIgMjAgc2l6ZSAwMDAwMDAwMjA6
IDAwMDAwYzE0MQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMjQ2XSBwY2kgZGV2IDAx
OjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNjENCihkMTYpIFsyMDE0LTExLTE4
IDE0OjMzOjMzLjI0OV0gTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246DQooZDE2KSBb
MjAxNC0xMS0xOCAxNDozMzozMy4yNzJdICAtIENQVTAgLi4uIDQ4LWJpdCBwaHlzIC4uLiBm
aXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLg0KKGQxNikgWzIwMTQt
MTEtMTggMTQ6MzM6MzMuMjk3XSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQg
TVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4NCihkMTYpIFsyMDE0LTExLTE4
IDE0OjMzOjMzLjMyMF0gIC0gQ1BVMiAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJz
IC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuDQooZDE2KSBbMjAxNC0xMS0xOCAxNDoz
MzozMy4zNDRdICAtIENQVTMgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4g
dmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLg0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMu
MzQ0XSBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMz
OjMzLjM1M10gIC0gUkVQIElOU0IgYWNyb3NzIHBhZ2UgYm91bmRhcmllcyAuLi4gcGFzc2Vk
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNTddICAtIEdTIGJhc2UgTVNScyBhbmQg
U1dBUEdTIC4uLiBwYXNzZWQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM1N10gUGFz
c2VkIDIgb2YgMiB0ZXN0cw0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzU3XSBXcml0
aW5nIFNNQklPUyB0YWJsZXMgLi4uDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNThd
IExvYWRpbmcgU2VhQklPUyAuLi4NCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM1OF0g
Q3JlYXRpbmcgTVAgdGFibGVzIC4uLg0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzU4
XSBMb2FkaW5nIEFDUEkgLi4uDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNTldIHZt
ODYgVFNTIGF0IGZjMDBhMjAwDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNjBdIEJJ
T1MgbWFwOg0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzYwXSAgMTAwMDAtMTAwZDM6
IFNjcmF0Y2ggc3BhY2UNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2MF0gIGMwMDAw
LWZmZmZmOiBNYWluIEJJT1MNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2MF0gRTgy
MCB0YWJsZToNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2MF0gIFswMF06IDAwMDAw
MDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJBTQ0KKGQxNikgWzIwMTQtMTEt
MTggMTQ6MzM6MzMuMzYwXSAgSE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDow
MDBjMDAwMA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzYwXSAgWzAxXTogMDAwMDAw
MDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQNCihkMTYpIFsyMDE0
LTExLTE4IDE0OjMzOjMzLjM2MF0gIFswMl06IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAw
MDA6M2Y4MDAwMDA6IFJBTQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzYwXSAgSE9M
RTogMDAwMDAwMDA6M2Y4MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMA0KKGQxNikgWzIwMTQt
MTEtMTggMTQ6MzM6MzMuMzYwXSAgWzAzXTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAw
MTowMDAwMDAwMDogUkVTRVJWRUQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2MF0g
SW52b2tpbmcgU2VhQklPUyAuLi4NCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2M10g
U2VhQklPUyAodmVyc2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTExOF8xMjUyMjMt
c2VydmVlcnN0ZXJ0amUpDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNjNdIA0KKGQx
NikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzYzXSBGb3VuZCBYZW4gaHlwZXJ2aXNvciBzaWdu
YXR1cmUgYXQgNDAwMDAwMDANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2NF0gUnVu
bmluZyBvbiBRRU1VIChpNDQwZngpDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNjRd
IHhlbjogY29weSBlODIwLi4uDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNjRdIFJl
bG9jYXRpbmcgaW5pdCBmcm9tIDB4MDAwZGY2MjkgdG8gMHgzZjdhZTYwMCAoc2l6ZSA3MTk5
NSkNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2Nl0gQ1BVIE1oej0zMjAyDQooZDE2
KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNzFdIEZvdW5kIDEwIFBDSSBkZXZpY2VzIChtYXgg
UENJIGJ1cyBpcyAwMCkNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM3MV0gQWxsb2Nh
dGVkIFhlbiBoeXBlcmNhbGwgcGFnZSBhdCAzZjdmZjAwMA0KKGQxNikgWzIwMTQtMTEtMTgg
MTQ6MzM6MzMuMzcxXSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjDQooZDE2KSBbMjAxNC0xMS0x
OCAxNDozMzozMy4zNzFdIHhlbjogY29weSBCSU9TIHRhYmxlcy4uLg0KKGQxNikgWzIwMTQt
MTEtMTggMTQ6MzM6MzMuMzcxXSBDb3B5aW5nIFNNQklPUyBlbnRyeSBwb2ludCBmcm9tIDB4
MDAwMTAwMTAgdG8gMHgwMDBmMGY1MA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzcx
XSBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMWEwL2ZjMDAxMWIwIHRvIDB4MDAwZjBl
MzANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM3MV0gQ29weWluZyBQSVIgZnJvbSAw
eDAwMDEwMDMwIHRvIDB4MDAwZjBkYjANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM3
MV0gQ29weWluZyBBQ1BJIFJTRFAgZnJvbSAweDAwMDEwMGIwIHRvIDB4MDAwZjBkODANCihk
MTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM3Ml0gVXNpbmcgcG10aW1lciwgaW9wb3J0IDB4
YjAwOA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzcyXSBTY2FuIGZvciBWR0Egb3B0
aW9uIHJvbQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzg3XSBSdW5uaW5nIG9wdGlv
biByb20gYXQgYzAwMDowMDAzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzozMy4zOTVdIHN0
ZHZnYS5jOjE0NzpkMTZ2MCBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMNCihk
MTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjQyMV0gcG1tIGNhbGwgYXJnMT0wDQooZDE2KSBb
MjAxNC0xMS0xOCAxNDozMzozMy40MjNdIFR1cm5pbmcgb24gdmdhIHRleHQgbW9kZSBjb25z
b2xlDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy41NDJdIFNlYUJJT1MgKHZlcnNpb24g
cmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMThfMTI1MjIzLXNlcnZlZXJzdGVydGplKQ0K
KGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNTU1XSBNYWNoaW5lIFVVSUQgNmIwZTU5MWEt
NzIyMy00YmE5LWJlOTUtMDU1NmVhNjdhYWJlDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzoz
My41NTZdIFhIQ0kgaW5pdCBvbiBkZXYgMDA6MDUuMDogcmVncyBAIDB4ZjMyNzAwMDAsIDQg
cG9ydHMsIDMyIHNsb3RzLCAzMiBieXRlIGNvbnRleHQNCihkMTYpIFsyMDE0LTExLTE4IDE0
OjMzOjMzLjU1Nl0gcw0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNTU2XSBYSENJICAg
IGV4dGNhcCAweDEgQCBmMzI3MDUwMA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNTU2
XSBYSENJICAgIHByb3RvY29sIFVTQiAgMy4wMCwgMiBwb3J0cyAob2Zmc2V0IDEpLCBkZWYg
MA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNTU2XSBYSENJICAgIHByb3RvY29sIFVT
QiAgMi4wMCwgMiBwb3J0cyAob2Zmc2V0IDMpLCBkZWYgMA0KKGQxNikgWzIwMTQtMTEtMTgg
MTQ6MzM6MzMuNTU3XSBVSENJIGluaXQgb24gZGV2IDAwOjAxLjIgKGlvPWMxNDApDQooZDE2
KSBbMjAxNC0xMS0xOCAxNDozMzozMy41NThdIEZvdW5kIDAgbHB0IHBvcnRzDQooZDE2KSBb
MjAxNC0xMS0xOCAxNDozMzozMy41NTldIEZvdW5kIDEgc2VyaWFsIHBvcnRzDQooZDE2KSBb
MjAxNC0xMS0xOCAxNDozMzozMy41NjBdIEFUQSBjb250cm9sbGVyIDEgYXQgMWYwLzNmNC8w
IChpcnEgMTQgZGV2IDkpDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy41NjFdIEFUQSBj
b250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUgZGV2IDkpDQooZDE2KSBbMjAxNC0x
MS0xOCAxNDozMzozMy41NjRdIGF0YTAtMDogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURp
c2sgKDEwMjQwIE1pQnl0ZXMpDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy41NjRdIFNl
YXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4LypAMSwxL2RyaXZlQDAvZGlza0Aw
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy41NjZdIGF0YTAtMTogUUVNVSBIQVJERElT
SyBBVEEtNyBIYXJkLURpc2sgKDMwMCBHaUJ5dGVzKQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6
MzM6MzMuNTY2XSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDEsMS9k
cml2ZUAwL2Rpc2tAMQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNjY0XSBQUzIga2V5
Ym9hcmQgaW5pdGlhbGl6ZWQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjcwOF0gWEhD
SSBwb3J0ICM0OiAweDAwMjAwYTAzLCBwb3dlcmVkLCBlbmFibGVkLCBwbHMgMCwgc3BlZWQg
MiBbTG93XQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNzM5XSBYSENJIG5vIGRldmlj
ZXMgZm91bmQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjc1MF0gQWxsIHRocmVhZHMg
Y29tcGxldGUuDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy43NTBdIFNjYW4gZm9yIG9w
dGlvbiByb21zDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy43NzJdIFJ1bm5pbmcgb3B0
aW9uIHJvbSBhdCBjOTgwOjAwMDMNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjc3OV0g
cG1tIGNhbGwgYXJnMT0xDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy43NzldIHBtbSBj
YWxsIGFyZzE9MA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNzgwXSBwbW0gY2FsbCBh
cmcxPTENCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjc4MV0gcG1tIGNhbGwgYXJnMT0w
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy43OTddIFNlYXJjaGluZyBib290b3JkZXIg
Zm9yOiAvcGNpQGkwY2Y4LypANA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNzk3XSAN
CihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjgwM10gUHJlc3MgRjEyIGZvciBib290IG1l
bnUuDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy44MDRdIA0KWyAgNDEzLjM2NDM0OV0g
eGVuX2JyaWRnZTogcG9ydCAxNCh2aWYxNC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUN
CihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjM3Nl0gU2VhcmNoaW5nIGJvb3RvcmRlciBm
b3I6IEhBTFQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjM3N10gZHJpdmUgMHgwMDBm
MGQzMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82
MyBzPTIwOTcxNTIwDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozNi4zNzhdIGRyaXZlIDB4
MDAwZjBkMDA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8y
NTUvNjMgcz02MjkxNDU2MDANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjM3OF0gDQoo
ZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozNi4zNzhdIFNwYWNlIGF2YWlsYWJsZSBmb3IgVU1C
OiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkMDANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2
LjM3OF0gUmV0dXJuZWQgMjUzOTUyIGJ5dGVzIG9mIFpvbmVIaWdoDQooZDE2KSBbMjAxNC0x
MS0xOCAxNDozMzozNi4zNzhdIGU4MjAgbWFwIGhhcyA2IGl0ZW1zOg0KKGQxNikgWzIwMTQt
MTEtMTggMTQ6MzM6MzYuMzc4XSAgIDA6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAw
MDlmYzAwID0gMSBSQU0NCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjM3OV0gICAxOiAw
MDAwMDAwMDAwMDlmYzAwIC0gMDAwMDAwMDAwMDBhMDAwMCA9IDIgUkVTRVJWRUQNCihkMTYp
IFsyMDE0LTExLTE4IDE0OjMzOjM2LjM3OV0gICAyOiAwMDAwMDAwMDAwMGYwMDAwIC0gMDAw
MDAwMDAwMDEwMDAwMCA9IDIgUkVTRVJWRUQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2
LjM3OV0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDAzZjdmZTAwMCA9IDEgUkFN
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozNi4zNzldICAgNDogMDAwMDAwMDAzZjdmZTAw
MCAtIDAwMDAwMDAwM2Y4MDAwMDAgPSAyIFJFU0VSVkVEDQooZDE2KSBbMjAxNC0xMS0xOCAx
NDozMzozNi4zNzldICAgNTogMDAwMDAwMDBmYzAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAg
PSAyIFJFU0VSVkVEDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozNi4zODJdIGVudGVyIGhh
bmRsZV8xOToNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjM4Ml0gICBOVUxMDQooZDE2
KSBbMjAxNC0xMS0xOCAxNDozMzozNi40MDZdIEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4N
CihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjQwOF0gQm9vdGluZyBmcm9tIDAwMDA6N2Mw
MA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MzguNzMzXSAtLU1BUkstLQ0KWyAgNDE5LjE2
NTIyOF0gZGV2aWNlIHZpZjE3LjAgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQpbICA0MTku
MzM0NTkyXSB2cG5fYnJpZGdlOiBwb3J0IDEodmlmMTUuMCkgZW50ZXJlZCBmb3J3YXJkaW5n
IHN0YXRlDQpbICA0MTkuMzM3MzU2XSBkZXZpY2UgdmlmMTcuMC1lbXUgZW50ZXJlZCBwcm9t
aXNjdW91cyBtb2RlDQpbICA0MTkuMzQwNjUwXSB4ZW5fYnJpZGdlOiBwb3J0IDE4KHZpZjE3
LjAtZW11KSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDQxOS4zNDA2NTZdIHhlbl9i
cmlkZ2U6IHBvcnQgMTgodmlmMTcuMC1lbXUpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0K
KGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMDQ3XSBIVk0gTG9hZGVyDQooZDE3KSBbMjAx
NC0xMS0xOCAxNDozMzo0MC4wNDddIERldGVjdGVkIFhlbiB2NC41LjAtcmMNCihkMTcpIFsy
MDE0LTExLTE4IDE0OjMzOjQwLjA0N10gWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBldmVu
dCBjaGFubmVsIDENCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjA0N10gU3lzdGVtIHJl
cXVlc3RlZCBTZWFCSU9TDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4wNDddIENQVSBz
cGVlZCBpcyAzMjAwIE1Ieg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMDQ3XSBSZWxv
Y2F0aW5nIGd1ZXN0IG1lbW9yeSBmb3IgbG93bWVtIE1NSU8gc3BhY2UgZGlzYWJsZWQNCihY
RU4pIFsyMDE0LTExLTE4IDE0OjMzOjQwLjA0OF0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGlu
ayAwIGNoYW5nZWQgMCAtPiA1DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4wNDhdIFBD
SS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzo0
MC4wNDhdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTANCihk
MTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjA0OF0gUENJLUlTQSBsaW5rIDEgcm91dGVkIHRv
IElSUTEwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzo0MC4wNDhdIGlycS5jOjI3MDogRG9t
MTcgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihkMTcpIFsyMDE0LTExLTE4IDE0OjMz
OjQwLjA0OF0gUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozMzo0MC4wNDldIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMyBjaGFuZ2Vk
IDAgLT4gNQ0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMDQ5XSBQQ0ktSVNBIGxpbmsg
MyByb3V0ZWQgdG8gSVJRNQ0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMDY4XSBwY2kg
ZGV2IDAxOjMgSU5UQS0+SVJRMTANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjA3M10g
cGNpIGRldiAwMjowIElOVEEtPklSUTExDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4w
ODRdIHBjaSBkZXYgMDQ6MCBJTlRBLT5JUlE1DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0
MC4xNDBdIE5vIFJBTSBpbiBoaWdoIG1lbW9yeTsgc2V0dGluZyBoaWdoX21lbSByZXNvdXJj
ZSBiYXNlIHRvIDEwMDAwMDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMTQwXSBw
Y2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAyMDAwMDAwOiAwZjAwMDAwMDgNCihkMTcpIFsy
MDE0LTExLTE4IDE0OjMzOjQwLjE0Ml0gcGNpIGRldiAwMjowIGJhciAxNCBzaXplIDAwMTAw
MDAwMDogMGYyMDAwMDA4DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4xNDRdIHBjaSBk
ZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAwNDAwMDA6IDBmMzAwMDAwMA0KKGQxNykgWzIwMTQt
MTEtMTggMTQ6MzM6NDAuMTQ2XSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAwMDIwMDAw
OiAwZjMwNDAwMDANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjE0N10gcGNpIGRldiAw
MzowIGJhciAzMCBzaXplIDAwMDAxMDAwMDogMGYzMDYwMDAwDQooZDE3KSBbMjAxNC0xMS0x
OCAxNDozMzo0MC4xNDldIHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDA6IDBm
MzA3MDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMTQ5XSBwY2kgZGV2IDAyOjAg
YmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDENCihkMTcpIFsyMDE0LTExLTE4IDE0
OjMzOjQwLjE1Ml0gcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDA0MDogMDAwMDBj
MTAxDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4xNTRdIHBjaSBkZXYgMDE6MSBiYXIg
MjAgc2l6ZSAwMDAwMDAwMTA6IDAwMDAwYzE0MQ0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6
NDAuMTU2XSBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoNCihkMTcpIFsyMDE0LTEx
LTE4IDE0OjMzOjQwLjE3OF0gIC0gQ1BVMCAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1U
UlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuDQooZDE3KSBbMjAxNC0xMS0xOCAx
NDozMzo0MC4xOTNdICAtIENQVTEgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAu
Li4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6
NDAuMjEwXSAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh
ciBNVFJScyBbMS84XSAuLi4gZG9uZS4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjIy
Nl0gIC0gQ1BVMyAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRS
UnMgWzEvOF0gLi4uIGRvbmUuDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yMjZdIFRl
c3RpbmcgSFZNIGVudmlyb25tZW50Og0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjM2
XSAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQNCihkMTcp
IFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0MF0gIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1Mg
Li4uIHBhc3NlZA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQwXSBQYXNzZWQgMiBv
ZiAyIHRlc3RzDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNDBdIFdyaXRpbmcgU01C
SU9TIHRhYmxlcyAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0MV0gTG9hZGlu
ZyBTZWFCSU9TIC4uLg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQxXSBDcmVhdGlu
ZyBNUCB0YWJsZXMgLi4uDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNDFdIExvYWRp
bmcgQUNQSSAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0M10gdm04NiBUU1Mg
YXQgZmMwMGEyMDANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0NF0gQklPUyBtYXA6
DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNDRdICAxMDAwMC0xMDBkMzogU2NyYXRj
aCBzcGFjZQ0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ0XSAgYzAwMDAtZmZmZmY6
IE1haW4gQklPUw0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ0XSBFODIwIHRhYmxl
Og0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ0XSAgWzAwXTogMDAwMDAwMDA6MDAw
MDAwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkFNDQooZDE3KSBbMjAxNC0xMS0xOCAxNDoz
Mzo0MC4yNDRdICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGMwMDAw
DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNDRdICBbMDFdOiAwMDAwMDAwMDowMDBj
MDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBSRVNFUlZFRA0KKGQxNykgWzIwMTQtMTEtMTgg
MTQ6MzM6NDAuMjQ0XSAgWzAyXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDozZjgw
MDAwMDogUkFNDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNDRdICBIT0xFOiAwMDAw
MDAwMDozZjgwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwDQooZDE3KSBbMjAxNC0xMS0xOCAx
NDozMzo0MC4yNDRdICBbMDNdOiAwMDAwMDAwMDpmYzAwMDAwMCAtIDAwMDAwMDAxOjAwMDAw
MDAwOiBSRVNFUlZFRA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ0XSBJbnZva2lu
ZyBTZWFCSU9TIC4uLg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ3XSBTZWFCSU9T
ICh2ZXJzaW9uIHJlbC0xLjcuNS0wLWdlNTE0ODhjLTIwMTQxMTE4XzEyNTIyMy1zZXJ2ZWVy
c3RlcnRqZSkNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0N10gDQooZDE3KSBbMjAx
NC0xMS0xOCAxNDozMzo0MC4yNDddIEZvdW5kIFhlbiBoeXBlcnZpc29yIHNpZ25hdHVyZSBh
dCA0MDAwMDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ4XSBSdW5uaW5nIG9u
IFFFTVUgKGk0NDBmeCkNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0OF0geGVuOiBj
b3B5IGU4MjAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0OF0gUmVsb2NhdGlu
ZyBpbml0IGZyb20gMHgwMDBkZjYyOSB0byAweDNmN2FlNjAwIChzaXplIDcxOTk1KQ0KKGQx
NykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjUwXSBDUFUgTWh6PTMyMDENCihkMTcpIFsyMDE0
LTExLTE4IDE0OjMzOjQwLjI1NV0gRm91bmQgNyBQQ0kgZGV2aWNlcyAobWF4IFBDSSBidXMg
aXMgMDApDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNTVdIEFsbG9jYXRlZCBYZW4g
aHlwZXJjYWxsIHBhZ2UgYXQgM2Y3ZmYwMDANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQw
LjI1NV0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYw0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6
NDAuMjU1XSB4ZW46IGNvcHkgQklPUyB0YWJsZXMuLi4NCihkMTcpIFsyMDE0LTExLTE4IDE0
OjMzOjQwLjI1NV0gQ29weWluZyBTTUJJT1MgZW50cnkgcG9pbnQgZnJvbSAweDAwMDEwMDEw
IHRvIDB4MDAwZjBmNTANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI1NV0gQ29weWlu
ZyBNUFRBQkxFIGZyb20gMHhmYzAwMTFhMC9mYzAwMTFiMCB0byAweDAwMGYwZTMwDQooZDE3
KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNTZdIENvcHlpbmcgUElSIGZyb20gMHgwMDAxMDAz
MCB0byAweDAwMGYwZGIwDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNTZdIENvcHlp
bmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAwMGYwZDgwDQooZDE3KSBbMjAx
NC0xMS0xOCAxNDozMzo0MC4yNTZdIFVzaW5nIHBtdGltZXIsIGlvcG9ydCAweGIwMDgNCihk
MTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI1Nl0gU2NhbiBmb3IgVkdBIG9wdGlvbiByb20N
CihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI3M10gUnVubmluZyBvcHRpb24gcm9tIGF0
IGMwMDA6MDAwMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjg0XSBzdGR2Z2EuYzox
NDc6ZDE3djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzDQooZDE3KSBbMjAx
NC0xMS0xOCAxNDozMzo0MC4zMTFdIHBtbSBjYWxsIGFyZzE9MA0KKGQxNykgWzIwMTQtMTEt
MTggMTQ6MzM6NDAuMzEyXSBUdXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUgY29uc29sZQ0KKGQx
NykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuNDQ1XSBTZWFCSU9TICh2ZXJzaW9uIHJlbC0xLjcu
NS0wLWdlNTE0ODhjLTIwMTQxMTE4XzEyNTIyMy1zZXJ2ZWVyc3RlcnRqZSkNCihkMTcpIFsy
MDE0LTExLTE4IDE0OjMzOjQwLjQ2MF0gTWFjaGluZSBVVUlEIDZkNDkzMjI0LTRhNjQtNDdh
YS05MjExLTM3NWIxZjE2NTQ1Yg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuNDYwXSBB
bGwgdGhyZWFkcyBjb21wbGV0ZS4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjQ2MV0g
Rm91bmQgMCBscHQgcG9ydHMNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjQ2Ml0gRm91
bmQgMCBzZXJpYWwgcG9ydHMNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjQ2Ml0gQVRB
IGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0LzAgKGlycSAxNCBkZXYgOSkNCihkMTcpIFsyMDE0
LTExLTE4IDE0OjMzOjQwLjQ2M10gQVRBIGNvbnRyb2xsZXIgMiBhdCAxNzAvMzc0LzAgKGly
cSAxNSBkZXYgOSkNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjQ2OF0gYXRhMC0wOiBR
RU1VIEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAoMTAyNDAgTWlCeXRlcykNCihkMTcpIFsy
MDE0LTExLTE4IDE0OjMzOjQwLjQ2OF0gU2VhcmNoaW5nIGJvb3RvcmRlciBmb3I6IC9wY2lA
aTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQw
LjU2Nl0gUFMyIGtleWJvYXJkIGluaXRpYWxpemVkDQooZDE3KSBbMjAxNC0xMS0xOCAxNDoz
Mzo0MC41NjZdIEFsbCB0aHJlYWRzIGNvbXBsZXRlLg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6
MzM6NDAuNTY2XSBTY2FuIGZvciBvcHRpb24gcm9tcw0KKGQxNykgWzIwMTQtMTEtMTggMTQ6
MzM6NDAuNTkyXSBSdW5uaW5nIG9wdGlvbiByb20gYXQgYzk4MDowMDAzDQooZDE3KSBbMjAx
NC0xMS0xOCAxNDozMzo0MC41OTldIHBtbSBjYWxsIGFyZzE9MQ0KKGQxNykgWzIwMTQtMTEt
MTggMTQ6MzM6NDAuNjAwXSBwbW0gY2FsbCBhcmcxPTANCihkMTcpIFsyMDE0LTExLTE4IDE0
OjMzOjQwLjYwMV0gcG1tIGNhbGwgYXJnMT0xDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0
MC42MDJdIHBtbSBjYWxsIGFyZzE9MA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuNjIx
XSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDQNCihkMTcpIFsyMDE0
LTExLTE4IDE0OjMzOjQwLjYyMV0gDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC42Mjhd
IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAu
NjI5XSANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQzLjE4Nl0gU2VhcmNoaW5nIGJvb3Rv
cmRlciBmb3I6IEhBTFQNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQzLjE4Nl0gZHJpdmUg
MHgwMDBmMGQzMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0
LzI1NS82MyBzPTIwOTcxNTIwDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0My4xODZdIFNw
YWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkMzANCihkMTcp
IFsyMDE0LTExLTE4IDE0OjMzOjQzLjE4Nl0gUmV0dXJuZWQgMjU4MDQ4IGJ5dGVzIG9mIFpv
bmVIaWdoDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0My4xODZdIGU4MjAgbWFwIGhhcyA2
IGl0ZW1zOg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDMuMTg2XSAgIDA6IDAwMDAwMDAw
MDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0NCihkMTcpIFsyMDE0LTExLTE4
IDE0OjMzOjQzLjE4Nl0gICAxOiAwMDAwMDAwMDAwMDlmYzAwIC0gMDAwMDAwMDAwMDBhMDAw
MCA9IDIgUkVTRVJWRUQNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQzLjE4Nl0gICAyOiAw
MDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCA9IDIgUkVTRVJWRUQNCihkMTcp
IFsyMDE0LTExLTE4IDE0OjMzOjQzLjE4Nl0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAw
MDAwMDAzZjdmZjAwMCA9IDEgUkFNDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0My4xODZd
ICAgNDogMDAwMDAwMDAzZjdmZjAwMCAtIDAwMDAwMDAwM2Y4MDAwMDAgPSAyIFJFU0VSVkVE
DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0My4xODZdICAgNTogMDAwMDAwMDBmYzAwMDAw
MCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJFU0VSVkVEDQooZDE3KSBbMjAxNC0xMS0xOCAx
NDozMzo0My4xODddIGVudGVyIGhhbmRsZV8xOToNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMz
OjQzLjE4N10gICBOVUxMDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0My4xOTRdIEJvb3Rp
bmcgZnJvbSBIYXJkIERpc2suLi4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQzLjE5N10g
Qm9vdGluZyBmcm9tIDAwMDA6N2MwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6NDQuNTc1
XSBzdGR2Z2EuYzoxNTE6ZDE2djAgbGVhdmluZyBzdGR2Z2ENClsgIDQyNC45MzE4ODhdIHhl
bl9icmlkZ2U6IHBvcnQgMTYodmlmMTYuMC1lbXUpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0
ZQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6NDUuOTcxXSBncmFudF90YWJsZS5jOjMwNTpk
MHYxIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDcgZnJhbWVzDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozMzo0OC43MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzo1
Mi41NTNdIHN0ZHZnYS5jOjE1MTpkMTd2MCBsZWF2aW5nIHN0ZHZnYQ0KWyAgNDM0LjM2NzEz
M10geGVuX2JyaWRnZTogcG9ydCAxOCh2aWYxNy4wLWVtdSkgZW50ZXJlZCBmb3J3YXJkaW5n
IHN0YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzo1OC43MzRdIC0tTUFSSy0tDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDozNDowOC43MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozNDoxMC4xOTJdIHN0ZHZnYS5jOjE0NzpkMTZ2MCBlbnRlcmluZyBzdGR2Z2EgYW5k
IGNhY2hpbmcgbW9kZXMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjExLjg4Nl0gaXJxLmM6
MzgwOiBEb20xNiBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMN
CihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3Ljc0NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRv
bTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6
MTcuNzQ4XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0x
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDoxNy43NTJdIG1lbW9yeV9tYXA6cmVtb3ZlOiBk
b20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0
OjE3Ljc1N10gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9
MQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcuNzYxXSBtZW1vcnlfbWFwOnJlbW92ZTog
ZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoz
NDoxNy43NjVdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5y
PTENCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3Ljc2OV0gbWVtb3J5X21hcDpyZW1vdmU6
IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6
MzQ6MTcuNzczXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBu
cj0xDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDoxNy43NzddIG1lbW9yeV9tYXA6cmVtb3Zl
OiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDE0
OjM0OjE3Ljc4MV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUg
bnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcuNzg1XSBtZW1vcnlfbWFwOnJlbW92
ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozNDoxNy43ODldIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZl
IG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3LjgwMF0gbWVtb3J5X21hcDpyZW1v
dmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozNDoxNy44MDZdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZl
MjAwIG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcuODEyXSBtZW1vcnlfbWFw
OnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDANCihYRU4pIFsyMDE0
LTExLTE4IDE0OjM0OjE3LjgxOF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBt
Zm49ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDoxNy44MjNdIG1lbW9y
eV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMA0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MzQ6MTcuODI5XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYz
MDAwIG1mbj1mZTIwMCBucj0yMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3LjgzNV0g
bWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDozNDoxNy44NDFdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBn
Zm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcu
ODQ3XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0y
MDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3Ljg1MV0gc3RkdmdhLmM6MTQ3OmQxN3Yw
IGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2Rlcw0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6MzQ6MTcuODUyXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIw
MCBucj0yMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3Ljg1OF0gbWVtb3J5X21hcDpy
ZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozNDoxNy44NjRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZu
PWZlMjAwIG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcuODk2XSBpcnEuYzoy
NzA6IERvbTE2IFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDANCihYRU4pIFsyMDE0LTExLTE4
IDE0OjM0OjE3LjkxNl0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAxIGNoYW5nZWQgMTAg
LT4gMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcuOTM2XSBpcnEuYzoyNzA6IERvbTE2
IFBDSSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDox
Ny45NTVdIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMA0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MzQ6MTguNzM0XSAtLU1BUkstLQ0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MzQ6MTkuNTQzXSBpcnEuYzozODA6IERvbTE3IGNhbGxiYWNrIHZpYSBjaGFuZ2Vk
IHRvIERpcmVjdCBWZWN0b3IgMHhmMw0KWyAgNDU4Ljk4NDcxMl0geGVuLWJsa2JhY2s6cmlu
Zy1yZWYgOCwgZXZlbnQtY2hhbm5lbCAzMiwgcHJvdG9jb2wgMSAoeDg2XzY0LWFiaSkgcGVy
c2lzdGVudCBncmFudHMNClsgIDQ1OC45OTk0NjBdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDks
IGV2ZW50LWNoYW5uZWwgMzMsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQg
Z3JhbnRzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDoxOS45MTVdIGdyYW50X3RhYmxlLmM6
MTI5OTpkMTZ2MiBFeHBhbmRpbmcgZG9tICgxNikgZ3JhbnQgdGFibGUgZnJvbSAoNCkgdG8g
KDUpIGZyYW1lcy4NClsgIDQ1OS4yODc5NDhdIHZpZiB2aWYtMTYtMCB2aWYxNi4wOiBHdWVz
dCBSeCByZWFkeQ0KWyAgNDU5LjI5NDE4M10geGVuX2JyaWRnZTogcG9ydCAxNSh2aWYxNi4w
KSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDQ1OS4zMDAzNTZdIHhlbl9icmlkZ2U6
IHBvcnQgMTUodmlmMTYuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDozNDoyMC42NTVdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMCBjaGFu
Z2VkIDUgLT4gMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MjAuNjYyXSBpcnEuYzoyNzA6
IERvbTE3IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozNDoyMC42NjhdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+
IDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjIwLjY3NF0gaXJxLmM6MjcwOiBEb20xNyBQ
Q0kgbGluayAzIGNoYW5nZWQgNSAtPiAwDQpbICA0NjAuNDkzNjU1XSB4ZW4tYmxrYmFjazpy
aW5nLXJlZiA5LCBldmVudC1jaGFubmVsIDMzLCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBw
ZXJzaXN0ZW50IGdyYW50cw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MjEuMTUyXSBncmFu
dF90YWJsZS5jOjEyOTk6ZDE3djAgRXhwYW5kaW5nIGRvbSAoMTcpIGdyYW50IHRhYmxlIGZy
b20gKDQpIHRvICg1KSBmcmFtZXMuDQpbICA0NjAuNTI4ODY0XSB2aWYgdmlmLTE3LTAgdmlm
MTcuMDogR3Vlc3QgUnggcmVhZHkNClsgIDQ2MC41MzUzNTFdIHhlbl9icmlkZ2U6IHBvcnQg
MTcodmlmMTcuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICA0NjAuNTQxODIxXSB4
ZW5fYnJpZGdlOiBwb3J0IDE3KHZpZjE3LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MjguNzM0XSAtLU1BUkstLQ0KWyAgNDc0LjM0NzMy
N10geGVuX2JyaWRnZTogcG9ydCAxNSh2aWYxNi4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3Rh
dGUNClsgIDQ3NS41NzM0NDRdIHhlbl9icmlkZ2U6IHBvcnQgMTcodmlmMTcuMCkgZW50ZXJl
ZCBmb3J3YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDozOC43MzRdIC0t
TUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDo0OC43MzRdIC0tTUFSSy0tDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDozNDo1OC43MzVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozNTowMi40MzJdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRy
YWNrIHNpemUgdG8gOCBmcmFtZXMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjM1OjA4LjczNV0g
LS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjM1OjE4LjczNV0gLS1NQVJLLS0NCihY
RU4pIFsyMDE0LTExLTE4IDE0OjM1OjI4LjczNV0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjM1OjM4LjczNV0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjM1OjQ4
LjczNl0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjM1OjU4LjczNl0gLS1NQVJL
LS0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjM2OjA3LjY3NV0gZ3JhbnRfdGFibGUuYzoxMjk5
OmQxNnYwIEV4cGFuZGluZyBkb20gKDE2KSBncmFudCB0YWJsZSBmcm9tICg1KSB0byAoNikg
ZnJhbWVzLg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzY6MDcuNjk5XSBncmFudF90YWJsZS5j
OjMwNTpkMHY1IEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDkgZnJhbWVzDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDozNjowOC43MzZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozNjoxOC43MzZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNjoyOC43Mzdd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNjozOC43MzddIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDozNjo0OC43MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozNjo1OC43MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNzow
OC43MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNzoxOC43MzhdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNzoyOC43MzhdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDozNzozOC43MzhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozNzo0OC43MzhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNzo1OC43Mzld
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozODowOC45MjFdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDozODoxOC45MjFdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozODoyOC45MjFdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozODoz
OC45MjJdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozODo0OC45MjJdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozODo1OC45MjJdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDozOTowOC45MjJdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozOToxOC45MjJdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozOToyOC45MjNd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozOTozOC45MjNdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDozOTo0OC45MjNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozOTo1OC45MjNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MDow
OC45MjNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MDoxOC45MjRdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MDoyOC45MjRdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0MDozOC45MjRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0MDo0OC45MjRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MDo1OC45MjRd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MTowOC45MjRdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0MToxOC45MjVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0MToyOC45MjVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MToz
OC45MjVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MTo0OC45MjVdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MTo1OC45MjVdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0MjowOC45MjZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0MjoxOC45MjZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MjoyOC45MjZd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MjozOC45MjZdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0Mjo0OC45MjZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0Mjo1OC45MjddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Mzow
OC45MjddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MzoxOC45MjddIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MzoyOC45MjddIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0MzozOC45MjddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0Mzo0OC45MjddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Mzo1OC45Mjhd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NDowOC45MjhdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0NDoxOC45MjhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0NDoyOC45MjhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NDoz
OC45MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NDo0OC45MjldIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NDo1OC45MjldIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0NTowOC45MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0NToxOC45MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NToyOC45MzBd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NTozOC45MzBdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0NTo0OC45MzBdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0NTo1OC45MzBdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Njow
OC45MzFdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NjoxOC45MzFdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NjoyOC45MzFdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0NjozOC45MzFdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0Njo0OC45MzJdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Njo1OC45MzJd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NzowOC45MzJdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0NzoxOC45MzJdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0NzoyOC45MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Nzoz
OC45MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Nzo0OC45MzNdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Nzo1OC45MzNdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0ODowOC45MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0ODoxOC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0ODoyOC45MzRd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0ODozOC45MzRdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0ODo0OC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0ODo1OC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0OTow
OC45MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0OToxOC45MzNdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0OToyMC4zMzddIGdyYW50X3RhYmxlLmM6MzA1
OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gMTAgZnJhbWVzDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDo0OToyOC45MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0
OTozOC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0OTo0OC45MzRdIC0t
TUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0OTo1OC45MzRdIC0tTUFSSy0tDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDo1MDowOC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDo1MDoxOC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MDoyOC45
MzVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MDozOC45MzVdIC0tTUFSSy0t
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MDo0OC45MzVdIC0tTUFSSy0tDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDo1MDo1OC45MzVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1
MTowOC45MzZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MToxOC45MzZdIC0t
TUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MToyOC45MzZdIC0tTUFSSy0tDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDo1MTozOC45MzZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDo1MTo0OC45MzZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MTo1OC45
MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MjowOC45MzddIC0tTUFSSy0t
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MjoxOC45MzddIC0tTUFSSy0tDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDo1MjoyOC45MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1
MjozOC45MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1Mjo0OC45MzhdIC0t
TUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1Mjo1OC45MzhdIC0tTUFSSy0tDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDo1MzowOC45MzhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDo1MzoxOC45MzhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzoyOC45
MzhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy4zMDZdICAwOiBmZmZm
ODMwM2ZhYWYyNWE4IFtwOmZmZmY4MzA1NGVmMmUzZTAsIG46ZmZmZjgzMDU0ZWYyZTNlMF0N
CihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3LjMzMF0gLS0tLVsgWGVuLTQuNS4wLXJjICB4
ODZfNjQgIGRlYnVnPXkgIE5vdCB0YWludGVkIF0tLS0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo1MzozNy4zNTNdIENQVTogICAgNA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzcuMzY0
XSBSSVA6ICAgIGUwMDg6WzxmZmZmODJkMDgwMTRhNGRlPl0gaHZtX2RvX0lSUV9kcGNpKzB4
ZjQvMHgxMzENCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3LjM4OV0gUkZMQUdTOiAwMDAw
MDAwMDAwMDEwMDgyICAgQ09OVEVYVDogaHlwZXJ2aXNvcg0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6NTM6MzcuNDEwXSByYXg6IGZmZmY4MzA1NGVmMmUzZTAgICByYng6IGZmZmY4MzAzZmFh
ZjI1YTggICByY3g6IGZmZmY4MzAzZmFhZjI2MTANCihYRU4pIFsyMDE0LTExLTE4IDE0OjUz
OjM3LjQzNl0gcmR4OiAwMjAwMjAwMjAwMjAwMjAwICAgcnNpOiAwMDAwMDAwMDAwMDAwMDA2
ICAgcmRpOiAwMDAwMDAwMDZlZjNmMTIzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy40
NjNdIHJicDogZmZmZjgzMDU0ZWYyN2JlOCAgIHJzcDogZmZmZjgzMDU0ZWYyN2JkOCAgIHI4
OiAgZmZmZjgzMDNmYWFmMjAxMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzcuNDkwXSBy
OTogIDAwMDAwMDAwMDAwMDAwMmYgICByMTA6IDAwMDAwMDAwMDAwMDAxMzIgICByMTE6IDAw
MDAwMDAwMDAwMDAwMDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3LjUxN10gcjEyOiBm
ZmZmODMwNTEyNWQ2MDAwICAgcjEzOiAwMDAwMDAwMDAwMDAwMDAwICAgcjE0OiBmZmZmODMw
M2ZhYWYyNTgwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy41NDNdIHIxNTogMDAwMDAw
MDAwMDAwMDAyZiAgIGNyMDogMDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAw
MDZmMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzcuNTcwXSBjcjM6IDAwMDAwMDA1NDQ4
YzAwMDAgICBjcjI6IGZmZmZmZmZmZmY2MDA0MDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjUz
OjM3LjU5MV0gZHM6IDAwMmIgICBlczogMDAyYiAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBz
czogZTAxMCAgIGNzOiBlMDA4DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy42MTZdIFhl
biBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmODMwNTRlZjI3YmQ4Og0KKFhFTikgWzIwMTQt
MTEtMTggMTQ6NTM6MzcuNjM2XSAgICBmZmZmODMwNTRlZjI3YmU4IGZmZmY4MzAzZmFhZjI2
YzAgZmZmZjgzMDU0ZWYyN2M3OCBmZmZmODJkMDgwMTcyMDYwDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDo1MzozNy42NjNdICAgIDAwMDAwMDAwMDAwMDAwMjAgZmZmZjgzMDU0ZWYyN2NmNiAw
MDAwMDAwMDAwMDAwMDQ2IGZmZmY4MzA1NGVmMjdjNzANCihYRU4pIFsyMDE0LTExLTE4IDE0
OjUzOjM3LjY5MF0gICAgZmZmZjgyZDAwMDAwMDAwMCBmZmZmODMwNTVkMDAyZjI0IDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMmY0ZWYyN2M0MA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6
MzcuNzE3XSAgICBmZmZmODMwNTRlZjI3YzQ4IGZmZmY4MmQwODAxNDQzNGYgZmZmZjgzMDU0
ZWYyN2M2MCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy43
NDRdICAgIGZmZmY4MmQwODAyNWVmZGMgMDAwMDAwMDAwMDAwMDIwMCBmZmZmODMwNTRlZjI3
ZDc4IDAwMDAwMDAwMDAwMDAwMDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3Ljc3MV0g
ICAgMDAwMDdjZmFiMTBkODM1NyBmZmZmODJkMDgwMjMzMTIyIDAwMDAwMDAwMDAwMDAwMDMg
ZmZmZjgzMDU0ZWYyN2Q3OA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzcuNzk4XSAgICAw
MDAwMDAwMDAwMDAwMjAwIGZmZmY4MmQwODAyNWVmZGMgZmZmZjgzMDU0ZWYyN2Q2MCAwMDAw
MDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy44MjVdICAgIDAwMDAw
MDAwMDAwMDAwMDMgMDAwMDAwMDAwMDAwMDEzMiAwMDAwMDAwMDAwMDAwMDAzIGZmZmY4MzA1
NGVmODAwMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3Ljg1Ml0gICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzA1NGVmMjAwMDAgMDAwMDAwMDAwMDAw
MDAwYQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzcuODc5XSAgICBmZmZmODJkMDgwMjk2
NmMwIDAwMDAwMGQxMDAwMDAwMDAgZmZmZjgyZDA4MDE0MzliYSAwMDAwMDAwMDAwMDBlMDA4
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy45MDZdICAgIDAwMDAwMDAwMDAwMDAyMDYg
ZmZmZjgzMDU0ZWYyN2QzMCAwMDAwMDAwMDAwMDBlMDEwIGZmZmY4MzA1NGVmMjdkNjANCihY
RU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3LjkzM10gICAgZmZmZjgyZDA4MDMwOTYxZSBmZmZm
ODMwNTRlZjJlMzc4IGZmZmY4MzA1NGVmMjdlMTAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6NTM6MzcuOTYwXSAgICBmZmZmODJkMDgwMjVmMzdlIGZmZmY4MzA1
NGVmMjdkYzAgZmZmZjgyZDA4MDE0M2VkYSBmZmZmODJkMDgwMjk2N2EwDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDo1MzozNy45ODddICAgIDAwMDAwMDAwMDAwMDAwMjggZmZmZjgzMDU0ZWYy
N2RkMCBmZmZmODMwNTRlZjI3ZDkwIGZmZmY4MzA1NGVmMjdkYTANCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjUzOjM4LjAxNF0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODMwM2ZhYWYyNWE4
IGZmZmY4MzA1NGVmMmUzZTAgZmZmZjgzMDU0ZWYyZTNlMA0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6NTM6MzguMDQxXSAgICAwMDAwMDE3ODVkYjc1ODAwIGZmZmY4MzA1NGVmMjdlYjAgZmZm
ZjgyZDA4MDE0OTVjMCBmZmZmODJkMDgwMjMzMTIyDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1
MzozOC4wNjhdICAgIGZmZmY4MzA1NGVmMmUzNzggZmZmZjgzMDU0ZWYyN2UwMCBmZmZmODMw
NTRlZjJlNGUwIGZmZmY4MzA1NGVmMmU0MDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4
LjA5NV0gICAgMDAwMDAwMDMwMDAwMDAwMCBmZmZmODMwNTEyNWQ2MGI4IGZmZmY4MzA1NGVm
MjdlNzAgZmZmZjgzMDU0ZWYyZTNlMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguMTIy
XSAgICBmZmZmODMwNTRlZjJlM2UwIGZmZmY4MzAzZmFhZjI1YTggZmZmZjgzMDU0ZWYyZTNl
MCBmZmZmODMwNTRlZjJlM2UwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozOC4xNTBdICAg
IGZmZmY4MzA1NGVmMmUzNzggMDEwMDEwMDEwMDEwMDEwMCAwMjAwMjAwMjAwMjAwMjAwIGZm
ZmY4MzA1NGVmMmUzNzgNCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4LjE3N10gWGVuIGNh
bGwgdHJhY2U6DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozOC4xODldICAgIFs8ZmZmZjgy
ZDA4MDE0YTRkZT5dIGh2bV9kb19JUlFfZHBjaSsweGY0LzB4MTMxDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo1MzozOC4yMTFdICAgIFs8ZmZmZjgyZDA4MDE3MjA2MD5dIGRvX0lSUSsweDQ5
Yy8weDYyNA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguMjMxXSAgICBbPGZmZmY4MmQw
ODAyMzMxMjI+XSBjb21tb25faW50ZXJydXB0KzB4NjIvMHg3MA0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6NTM6MzguMjUzXSAgICBbPGZmZmY4MmQwODAxNDM5YmE+XSB2cHJpbnRrX2NvbW1v
bisweDEzMS8weDEzZQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguMjc1XSAgICBbPGZm
ZmY4MmQwODAxNDNlZGE+XSBwcmludGsrMHg0Ni8weDQ4DQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo1MzozOC4yOTRdICAgIFs8ZmZmZjgyZDA4MDE0OTVjMD5dIGRwY2lfc29mdGlycSsweDE5
OS8weDNlMg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguMzE1XSAgICBbPGZmZmY4MmQw
ODAxMmJlMzE+XSBfX2RvX3NvZnRpcnErMHg4MS8weDhjDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo1MzozOC4zMzZdICAgIFs8ZmZmZjgyZDA4MDEyYmU4OT5dIGRvX3NvZnRpcnErMHgxMy8w
eDE1DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozOC4zNTZdICAgIFs8ZmZmZjgyZDA4MDE2
MzNlNT5dIGlkbGVfbG9vcCsweDVlLzB4NmUNCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4
LjM3Nl0gDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozOC4zODVdIA0KKFhFTikgWzIwMTQt
MTEtMTggMTQ6NTM6MzguMzk0XSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozOC40MTNdIFBhbmljIG9uIENQVSA0
Og0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguNDI2XSBHRU5FUkFMIFBST1RFQ1RJT04g
RkFVTFQNCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4LjQ0MV0gW2Vycm9yX2NvZGU9MDAw
MF0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4LjQ1NF0gKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguNDcz
XSANCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4LjQ4Ml0gUmVib290IGluIGZpdmUgc2Vj
b25kcy4uLg0K
------------0191A1230144FE1ED
Content-Type: text/plain;
 name="xl-dmesg-defined-nousb.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg-defined-nousb.txt"

ZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgCihYRU4pICAwMCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAwMSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDMwCihYRU4pICAwMiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwCihYRU4pICAwMyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4CihYRU4pICAwNCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYxCihYRU4pICAwNSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwCihYRU4pICAwNiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4CihYRU4pICAwNyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDUwCihYRU4pICAwOCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4CihYRU4pICAwOSAwMDEgMDEgIDEg
ICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAwICAgIDAwCihYRU4pICAwYSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDY4CihYRU4pICAwYiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwCihYRU4pICAwYyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4CihYRU4pICAwZCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDg4CihYRU4pICAwZSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwCihYRU4pICAwZiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDk4CihYRU4pICAxMCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMiAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMyAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNiAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNyAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pIElPIEFQSUMgIzcuLi4u
Li4KKFhFTikgLi4uLiByZWdpc3RlciAjMDA6IDA3MDAwMDAwCihYRU4pIC4uLi4uLi4gICAg
OiBwaHlzaWNhbCBBUElDIGlkOiAwNwooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlw
ZTogMAooWEVOKSAuLi4uLi4uICAgIDogTFRTICAgICAgICAgIDogMAooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMTogMDAxRjgwMjEKKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rp
b24gZW50cmllczogMDAxRgooWEVOKSAuLi4uLi4uICAgICA6IFBSUSBpbXBsZW1lbnRlZDog
MQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMjogMDAwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAgOiBhcmJpdHJhdGlv
bjogMDAKKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6CihYRU4pICBOUiBMb2cg
UGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgCihYRU4pICAw
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
OSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
OSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pIFVz
aW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZwooWEVOKSBJUlEgdG8gcGluIG1hcHBpbmdzOgoo
WEVOKSBJUlEyNDAgLT4gMDoyCihYRU4pIElSUTQ4IC0+IDA6MQooWEVOKSBJUlE1NiAtPiAw
OjMKKFhFTikgSVJRMjQxIC0+IDA6NAooWEVOKSBJUlE2NCAtPiAwOjUKKFhFTikgSVJRNzIg
LT4gMDo2CihYRU4pIElSUTgwIC0+IDA6NwooWEVOKSBJUlE4OCAtPiAwOjgKKFhFTikgSVJR
OTYgLT4gMDo5CihYRU4pIElSUTEwNCAtPiAwOjEwCihYRU4pIElSUTExMiAtPiAwOjExCihY
RU4pIElSUTEyMCAtPiAwOjEyCihYRU4pIElSUTEzNiAtPiAwOjEzCihYRU4pIElSUTE0NCAt
PiAwOjE0CihYRU4pIElSUTE1MiAtPiAwOjE1CihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLiBkb25lLgooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGlu
dGVycnVwdHMuCihYRU4pIGNhbGlicmF0aW5nIEFQSUMgdGltZXIgLi4uCihYRU4pIC4uLi4u
IENQVSBjbG9jayBzcGVlZCBpcyAzMjAwLjE5OTYgTUh6LgooWEVOKSAuLi4uLiBob3N0IGJ1
cyBjbG9jayBzcGVlZCBpcyAyMDAuMDEyNCBNSHouCihYRU4pIC4uLi4uIGJ1c19zY2FsZSA9
IDB4Y2NkNwooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy40NDNdIFBsYXRmb3JtIHRpbWVy
IGlzIDE0LjMxOE1IeiBIUEVUCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI3LjQ2NF0gQWxs
b2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjI3LjQ3MF0gSFZNOiBBU0lEcyBlbmFibGVkLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToy
Ny40NzZdIFNWTTogU3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOgooWEVOKSBbMjAxNC0x
MS0xOCAxMzowMToyNy40ODJdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQooWEVOKSBb
MjAxNC0xMS0xOCAxMzowMToyNy40ODhdICAtIExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBW
aXJ0dWFsaXNhdGlvbgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy40OTRdICAtIE5leHQt
UklQIFNhdmVkIG9uICNWTUVYSVQKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjcuNTAwXSAg
LSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVyCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI3LjUw
Nl0gSFZNOiBTVk0gZW5hYmxlZAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy41MTNdIEhW
TTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVApIGRldGVjdGVkCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjI3LjUxOV0gSFZNOiBIQVAgcGFnZSBzaXplczogNGtCLCAyTUIsIDFH
QgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy41MjZdIEhWTTogUFZIIG1vZGUgbm90IHN1
cHBvcnRlZCBvbiB0aGlzIHBsYXRmb3JtCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI3LjU1
Ml0gbWFza2VkIEV4dElOVCBvbiBDUFUjMQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy41
NzldIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzIKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6Mjcu
NjA1XSBtYXNrZWQgRXh0SU5UIG9uIENQVSMzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI3
LjYzMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjNAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToy
Ny42NTldIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzUKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6
MjcuNjY1XSBCcm91Z2h0IHVwIDYgQ1BVcwooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy42
NzVdIEFNRC1WaTogRmFpbGVkIHRvIHNldHVwIEhQRVQgTVNJIHJlbWFwcGluZy4gV3Jvbmcg
SFBFVC4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjcuNjgyXSBBTUQtVmk6IEZhaWxlZCB0
byBzZXR1cCBIUEVUIE1TSSByZW1hcHBpbmcuIFdyb25nIEhQRVQuCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjI3LjY4OF0gQU1ELVZpOiBGYWlsZWQgdG8gc2V0dXAgSFBFVCBNU0kgcmVt
YXBwaW5nLiBXcm9uZyBIUEVULgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy42OTVdIEhQ
RVQ6IDMgdGltZXJzIHVzYWJsZSBmb3IgYnJvYWRjYXN0ICgzIHRvdGFsKQooWEVOKSBbMjAx
NC0xMS0xOCAxMzowMToyNy43MjJdIEFDUEkgc2xlZXAgbW9kZXM6IFMzCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjI3LjcyOV0gTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVz
dCBwb2xsaW5nIGZyZXF1ZW5jeQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy43MzZdIG1j
aGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4KKFhFTikg
WzIwMTQtMTEtMTggMTM6MDE6MjcuNzQzXSBYZW5vcHJvZmlsZTogRmFpbGVkIHRvIHNldHVw
IElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmCihYRU4pIFsyMDE0LTExLTE4
IDEzOjAxOjI3Ljc1MF0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjI3LjkxOF0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAw
MDAwIG1lbXN6PTB4MTA2NDAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy45MjZdIGVs
Zl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MjIwMDAwMCBtZW1zej0weDEwNjAwMAoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy45MzNdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6
IHBhZGRyPTB4MjMwNjAwMCBtZW1zej0weDE0MjgwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjI3Ljk0MF0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgyMzFiMDAwIG1lbXN6
PTB4MTE0MDAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy45NDhdIGVsZl9wYXJzZV9i
aW5hcnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MzQ1YjAwMAooWEVOKSBbMjAxNC0xMS0x
OCAxMzowMToyNy45NTVdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgi
CihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI3Ljk2M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBH
VUVTVF9WRVJTSU9OID0gIjIuNiIKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjcuOTcwXSBl
bGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjI3Ljk3OF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAw
eGZmZmZmZmZmODAwMDAwMDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjcuOTg1XSBlbGZf
eGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgyMzFiMWYwCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjI3Ljk5M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBIWVBFUkNBTExfUEFH
RSA9IDB4ZmZmZmZmZmY4MTAwMTAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4wMDFd
IGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVz
fHBhZV9wZ2Rpcl9hYm92ZV80Z2J8d3JpdGFibGVfZGVzY3JpcHRvcl90YWJsZXN8YXV0b190
cmFuc2xhdGVkX3BoeXNtYXB8c3VwZXJ2aXNvcl9tb2RlX2tlcm5lbCIKKFhFTikgWzIwMTQt
MTEtMTggMTM6MDE6MjguMDE3XSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVUFBPUlRFRF9GRUFU
VVJFUyA9IDB4OTBkCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjAyNV0gZWxmX3hlbl9w
YXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4
LjAzM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKKFhFTikgWzIw
MTQtMTEtMTggMTM6MDE6MjguMDQyXSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25vd24geGVu
IGVsZiBub3RlICgweGQpCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjA1MF0gZWxmX3hl
bl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQooWEVOKSBbMjAxNC0xMS0xOCAx
MzowMToyOC4wNTldIGVsZl94ZW5fcGFyc2Vfbm90ZTogTU9EX1NUQVJUX1BGTiA9IDB4MQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4wNjhdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZf
U1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjI4LjA3N10gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDAKKFhFTikg
WzIwMTQtMTEtMTggMTM6MDE6MjguMDg2XSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRk
cmVzc2VzOgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4wOTVdICAgICB2aXJ0X2Jhc2Ug
ICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4
LjEwNF0gICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKKFhFTikgWzIwMTQtMTEtMTggMTM6
MDE6MjguMTE0XSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMAoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4xMjNdICAgICB2aXJ0X2tzdGFydCAgICAgID0g
MHhmZmZmZmZmZjgxMDAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjEzM10gICAg
IHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZmZmZmODM0NWIwMDAKKFhFTikgWzIwMTQtMTEt
MTggMTM6MDE6MjguMTQzXSAgICAgdmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MjMx
YjFmMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4xNTNdICAgICBwMm1fYmFzZSAgICAg
ICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjE2
M10gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIKKFhFTikgWzIwMTQtMTEt
MTggMTM6MDE6MjguMTczXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRy
IDB4MTAwMDAwMCAtPiAweDM0NWIwMDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjguMTgz
XSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6CihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjI4LjE5M10gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDA1NDgwMDAwMDAtPjAwMDAwMDA1NGMw
MDAwMDAgKDM3MjkzOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pIFsyMDE0LTExLTE4
IDEzOjAxOjI4LjIwNF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDA1NWYwY2EwMDAtPjAwMDAw
MDA1NWZmZmZhMDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjguMjE1XSBWSVJUVUFMIE1F
TU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjguMjI2XSAgTG9h
ZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MzQ1YjAwMAooWEVOKSBb
MjAxNC0xMS0xOCAxMzowMToyOC4yMzZdICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMDAwMDAw
MDAwLT4wMDAwMDAwMDAwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjI0N10g
IFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODM0NWIwMDAtPmZmZmZmZmZmODM3NWIwMDAKKFhF
TikgWzIwMTQtMTEtMTggMTM6MDE6MjguMjU4XSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4
Mzc1YjAwMC0+ZmZmZmZmZmY4Mzc1YjRiNAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4y
NjldICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzNzVjMDAwLT5mZmZmZmZmZjgzNzdiMDAw
CihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjI4MF0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZm
ZmZmODM3N2IwMDAtPmZmZmZmZmZmODM3N2MwMDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6
MjguMjkxXSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4Mzgw
MDAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4zMDJdICBFTlRSWSBBRERSRVNTOiBm
ZmZmZmZmZjgyMzFiMWYwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjMxM10gRG9tMCBo
YXMgbWF4aW11bSA2IFZDUFVzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjMyNF0gZWxm
X2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZm
ZmY4MjA2NDAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4zNDJdIGVsZl9sb2FkX2Jp
bmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MjIwMDAwMCAtPiAweGZmZmZmZmZmODIzMDYw
MDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjguMzU0XSBlbGZfbG9hZF9iaW5hcnk6IHBo
ZHIgMiBhdCAweGZmZmZmZmZmODIzMDYwMDAgLT4gMHhmZmZmZmZmZjgyMzFhMjgwCihYRU4p
IFsyMDE0LTExLTE4IDEzOjAxOjI4LjM2NV0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDMgYXQg
MHhmZmZmZmZmZjgyMzFiMDAwIC0+IDB4ZmZmZmZmZmY4MjQyMzAwMAooWEVOKSBbMjAxNC0x
MS0xOCAxMzowMToyOC43NzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5
LjUxOV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMCwgdHlw
ZSA9IDB4Niwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuNTMxXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDIsIHR5cGUgPSAweDcsIHJvb3QgdGFi
bGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjI5LjU0M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHgxMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6
MjkuNTU2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDE4
LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOS41NjhdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MjgsIHR5cGUgPSAweDIsIHJv
b3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5LjU4MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgzMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRl
ZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDE6MjkuNTk0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDQ4LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOS42MDddIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NTAsIHR5cGUgPSAw
eDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5LjYyMF0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1OCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9
IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQt
MTEtMTggMTM6MDE6MjkuNjMzXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDYwLCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOS42
NDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NjgsIHR5
cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5LjY2MF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg4OCwgdHlwZSA9IDB4Nywgcm9vdCB0
YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikg
WzIwMTQtMTEtMTggMTM6MDE6MjkuNjc0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDkwLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMzow
MToyOS42ODhdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
OTIsIHR5cGUgPSAweDcsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5LjcwMl0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgdHlwZSA9IDB4Nywg
cm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMK
KFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuNzE2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDlhLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1
NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0x
OCAxMzowMToyOS43MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4YTAsIHR5cGUgPSAweDcsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5Ljc0NV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMiwgdHlwZSA9
IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuNzYwXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEzLCB0eXBlID0gMHg3LCByb290IHRhYmxl
ID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAx
NC0xMS0xOCAxMzowMToyOS43NzVdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4YTQsIHR5cGUgPSAweDUsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5
Ljc5MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhNSwg
dHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuODA1XSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE4LCB0eXBlID0gMHgyLCByb290
IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVO
KSBbMjAxNC0xMS0xOCAxMzowMToyOS44MjBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4YjAsIHR5cGUgPSAweDcsIHJvb3QgdGFibGUgPSAweDU0ZWVk
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjI5LjgzNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHhiMiwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuODUxXSBBTUQt
Vmk6IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTguMAooWEVOKSBbMjAxNC0xMS0x
OCAxMzowMToyOS44NjddIEFNRC1WaTogU2tpcHBpbmcgaG9zdCBicmlkZ2UgMDAwMDowMDox
OC4xCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5Ljg4Ml0gQU1ELVZpOiBTa2lwcGluZyBo
b3N0IGJyaWRnZSAwMDAwOjAwOjE4LjIKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuODk3
XSBBTUQtVmk6IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTguMwooWEVOKSBbMjAx
NC0xMS0xOCAxMzowMToyOS45MTJdIEFNRC1WaTogU2tpcHBpbmcgaG9zdCBicmlkZ2UgMDAw
MDowMDoxOC40CihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5LjkyN10gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDAsIHR5cGUgPSAweDEsIHJvb3Qg
dGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4p
IFsyMDE0LTExLTE4IDEzOjAxOjI5Ljk0M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg1MDAsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVk
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjI5Ljk1OV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHg2MDgsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5Ljk3NV0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg2MTAsIHR5cGUgPSAw
eDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5Ljk5MV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg3MDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUg
PSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjMwLjAwN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg4MDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMw
LjAyM10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDAs
IHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjA0MF0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDEsIHR5cGUgPSAweDEsIHJv
b3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjA1N10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHhhMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0
ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4
IDEzOjAxOjMwLjA3NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHhiMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjA5MV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhjMDAsIHR5cGUg
PSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjEwOF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhkMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFi
bGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjMwLjEyNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHhlMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjMwLjE0NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhl
MDEsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjE2MV0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhmMDAsIHR5cGUgPSAweDEs
IHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
CihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjE3OV0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHhmMDEsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAw
eDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjMwLjIwMl0gU2NydWJiaW5nIEZyZWUgUkFNIG9uIDEgbm9kZXMgdXNpbmcg
NiBDUFVzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjMxM10gLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi5kb25lLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozMy40MDZdIElu
aXRpYWwgbG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMTozMy40MjNdIFN0ZC4gTG9nbGV2ZWw6IEFsbAooWEVO
KSBbMjAxNC0xMS0xOCAxMzowMTozMy40NDFdIEd1ZXN0IExvZ2xldmVsOiBBbGwKKFhFTikg
WzIwMTQtMTEtMTggMTM6MDE6MzMuNDU5XSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29u
c29sZS4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MzMuNTYxXSAqKiogU2VyaWFsIGlucHV0
IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRv
IFhlbikKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MzMuNTYyXSBGcmVlZCAyODRrQiBpbml0
IG1lbW9yeS4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MzMuNzE0XSBJT0FQSUNbMF06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNi05IC0+IDB4NjAgLT4gSVJRIDkgTW9kZToxIEFjdGl2
ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozMy43MzZdIHRyYXBzLmM6MjU3OTpkMHYw
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAw
MDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjA2NV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4wCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjA2NV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yCihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjM0LjA2Nl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2Nl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDow
My4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2Nl0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDowNS4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2N10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDowNi4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2N10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDowOS4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2N10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDowYS4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0
LjA2OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYi4wCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjA2OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYy4wCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjA2OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowZC4wCihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjM0LjA2OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMS4wCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
Mi4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2OV0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxMi4yCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3MF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxMy4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3MF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxMy4yCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3MF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0
LjA3MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4yCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjA3MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4zCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjA3MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC40CihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjM0LjA3MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41CihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3Ml0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
NS4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3Ml0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxNi4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3Ml0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxNi4yCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3M10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxOC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3M10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0
LjA3M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjA3M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4zCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjA3NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40CihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjM0LjA3NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowZjowMC4wCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowZjow
MC4xCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3OV0gUENJIGFkZCBkZXZpY2UgMDAw
MDowZTowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3OV0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowZTowMC4xCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA4NV0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowZDowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA5Ml0g
UENJIGFkZCBkZXZpY2UgMDAwMDowYzowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0
LjA5OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowYjowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjEwNl0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4wCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjExM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4wCihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjM0LjExM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4xCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjExOV0gUENJIGFkZCBkZXZpY2UgMDAwMDowNTow
MC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjEyOV0gUENJIGFkZCBkZXZpY2UgMDAw
MDowNjowMS4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjEzMF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowNjowMi4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjEzMF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowODowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjE0MF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowNzowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0
LjE0MF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjE1MF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMzowNi4wCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjE1MV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYt
MTMgLT4gMHg4OCAtPiBJUlEgMTMgTW9kZTowIEFjdGl2ZTowKQooWEVOKSBbMjAxNC0xMS0x
OCAxMzowMTozNC4xNjVdIFBDSTogVXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAw
MC1mZgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozNC4xNTldIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTggLT4gMHg1OCAtPiBJUlEgOCBNb2RlOjAgQWN0aXZlOjAp
CihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjE3Ml0gSU9BUElDWzBdOiBTZXQgUENJIHJv
dXRpbmcgZW50cnkgKDYtMTggLT4gMHhiOCAtPiBJUlEgMTggTW9kZToxIEFjdGl2ZToxKQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMTozNC4yNDhdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg2LTE3IC0+IDB4YzAgLT4gSVJRIDE3IE1vZGU6MSBBY3RpdmU6MSkKKFhF
TikgWzIwMTQtMTEtMTggMTM6MDE6MzQuNDc5XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNy0yOSAtPiAweGM4IC0+IElSUSA1MyBNb2RlOjEgQWN0aXZlOjEpCihYRU4p
IFsyMDE0LTExLTE4IDEzOjAxOjM0LjQ3OV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDctMjQgLT4gMHhkMCAtPiBJUlEgNDggTW9kZToxIEFjdGl2ZToxKQooWEVOKSBb
MjAxNC0xMS0xOCAxMzowMTozNC40NzldIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTMwIC0+IDB4ZDggLT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIw
MTQtMTEtMTggMTM6MDE6MzQuNDc5XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy0xMiAtPiAweDIxIC0+IElSUSAzNiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjM0LjQ3OV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctMTMgLT4gMHgyOSAtPiBJUlEgMzcgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0x
MS0xOCAxMzowMTozNC40NzldIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTE2IC0+IDB4MzEgLT4gSVJRIDQwIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEt
MTggMTM6MDE6MzQuNTQ2XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0y
OCAtPiAweDM5IC0+IElSUSA1MiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4
IDEzOjAxOjM0LjU0OF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTYg
LT4gMHg4OSAtPiBJUlEgMTYgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAx
MzowMTozNC41NDhdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE0IC0+
IDB4YTkgLT4gSVJRIDM4IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTggMTM6
MDE6MzQuNTk3XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0yMiAtPiAw
eGI5IC0+IElSUSAyMiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjM2LjY2OV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOSAtPiAweGMx
IC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM2
LjY5NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOCAtPiAweGM5IC0+
IElSUSAzMiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM2Ljcy
MV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjMgLT4gMHhkMSAtPiBJ
UlEgNDcgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozOC44MDFd
IElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTUgLT4gMHhkOSAtPiBJUlEg
MjkgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozOC44NDVdIElP
QVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTQgLT4gMHgyMiAtPiBJUlEgMjgg
TW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozOC45NzldIElPQVBJ
Q1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE5IC0+IDB4MmEgLT4gSVJRIDE5IE1v
ZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MzguOTg3XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozOS4xNDJdIElPQVBJQ1sxXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg3LTIyIC0+IDB4NzIgLT4gSVJRIDQ2IE1vZGU6MSBBY3RpdmU6MSkK
KFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MzkuMTc4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy0yNyAtPiAweDhhIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM5Ljc3Nl0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDctMSAtPiAweDlhIC0+IElSUSAyNSBNb2RlOjEgQWN0aXZlOjEpCihYRU4p
IFsyMDE0LTExLTE4IDEzOjAxOjQ4Ljc0MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDE6NTguNzQwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMjowOC43NDBd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjAyOjE4Ljc0MV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6MDI6MjguNzQxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzowMjozOC43NDFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjAyOjQ4Ljc0
MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDI6NTguNzQyXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMzowOC43NDJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAzOjE4Ljc0Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDM6Mjgu
NzQyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMzozOC43NDNdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjAzOjQ4Ljc0M10gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MDM6NTguNzQzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowNDow
OC43NDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjA0OjE4Ljc0M10gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDQ6MjguNzQ0XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzowNDozOC43NDRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjA0
OjQ4Ljc0NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDQ6NTguNzQ0XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowNTowOC43NDVdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjA1OjE4Ljc0NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
MDU6MjguNzQ1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowNTozOC43NDVdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjA1OjQ4Ljc0NV0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6MDU6NTguNzQ2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MzowNjowOC43NDZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjA2OjE4Ljc0Nl0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDY6MjguNzQ2XSAtLU1BUkstLQooZDEp
IFsyMDE0LTExLTE4IDEzOjA2OjM4LjMwMF0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNh
bCBtZW1vcnkKKGQxKSBbMjAxNC0xMS0xOCAxMzowNjozOC4zMDBdIGFib3V0IHRvIGdldCBz
dGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDEzOjA2OjM4LjU2Nl0gdHJhcHMuYzoyNTc5
OmQxdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgw
MDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEt
MTggMTM6MDY6MzguNzQ3XSAtLU1BUkstLQooZDIpIFsyMDE0LTExLTE4IDEzOjA2OjQ0LjE2
NV0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQyKSBbMjAxNC0xMS0x
OCAxMzowNjo0NC4xNjZdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjA2OjQ0LjI0N10gdHJhcHMuYzoyNTc5OmQydjAgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAw
MDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDY6NDguNzQ3XSAtLU1BUkst
LQooZDMpIFsyMDE0LTExLTE4IDEzOjA2OjQ5LjkyMF0gbWFwcGluZyBrZXJuZWwgaW50byBw
aHlzaWNhbCBtZW1vcnkKKGQzKSBbMjAxNC0xMS0xOCAxMzowNjo0OS45MjBdIGFib3V0IHRv
IGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDEzOjA2OjUwLjAxMl0gdHJhcHMu
YzoyNTc5OmQzdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKGQ0KSBbMjAx
NC0xMS0xOCAxMzowNjo1Ni40MjNdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVt
b3J5CihkNCkgWzIwMTQtMTEtMTggMTM6MDY6NTYuNDIzXSBhYm91dCB0byBnZXQgc3RhcnRl
ZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowNjo1Ni41MDJdIHRyYXBzLmM6MjU3OTpkNHYw
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAw
MDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE4IDEz
OjA2OjU4Ljc0N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDY6NTkuNjYwXSBn
cmFudF90YWJsZS5jOjMwNTpkMHYyIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDIgZnJh
bWVzCihkNSkgWzIwMTQtMTEtMTggMTM6MDc6MDIuNDAxXSBtYXBwaW5nIGtlcm5lbCBpbnRv
IHBoeXNpY2FsIG1lbW9yeQooZDUpIFsyMDE0LTExLTE4IDEzOjA3OjAyLjQwMV0gYWJvdXQg
dG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDc6MDIuNDkwXSB0cmFw
cy5jOjI1Nzk6ZDV2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQg
ZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBb
MjAxNC0xMS0xOCAxMzowNzowMy44MTddIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVh
c2VkIG1hcHRyYWNrIHNpemUgdG8gMyBmcmFtZXMKKGQ2KSBbMjAxNC0xMS0xOCAxMzowNzow
OC4zNzddIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkNikgWzIwMTQt
MTEtMTggMTM6MDc6MDguMzc3XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAx
NC0xMS0xOCAxMzowNzowOC40OTFdIHRyYXBzLmM6MjU3OTpkNnYwIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAw
eDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE4IDEzOjA3OjA4Ljc0N10gLS1N
QVJLLS0KKGQ3KSBbMjAxNC0xMS0xOCAxMzowNzoxNC4yNjNdIG1hcHBpbmcga2VybmVsIGlu
dG8gcGh5c2ljYWwgbWVtb3J5CihkNykgWzIwMTQtMTEtMTggMTM6MDc6MTQuMjYzXSBhYm91
dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowNzoxNC4zNDJdIHRy
YXBzLmM6MjU3OTpkN3YwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4p
IFsyMDE0LTExLTE4IDEzOjA3OjE4Ljc0N10gLS1NQVJLLS0KKGQ4KSBbMjAxNC0xMS0xOCAx
MzowNzoyMC4wODRdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkOCkg
WzIwMTQtMTEtMTggMTM6MDc6MjAuMDg0XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVO
KSBbMjAxNC0xMS0xOCAxMzowNzoyMC4xNjJdIHRyYXBzLmM6MjU3OTpkOHYwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAw
MCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihkOSkgWzIwMTQtMTEtMTggMTM6MDc6MjYuMTU1
XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDkpIFsyMDE0LTExLTE4
IDEzOjA3OjI2LjE1NV0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEt
MTggMTM6MDc6MjYuMjUwXSB0cmFwcy5jOjI1Nzk6ZDl2MCBEb21haW4gYXR0ZW1wdGVkIFdS
TVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAw
MDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowNzoyOC43NDhdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjA3OjMwLjAyOV0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2
MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA0IGZyYW1lcwooZDEwKSBbMjAxNC0xMS0x
OCAxMzowNzozMi4wNjBdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5Cihk
MTApIFsyMDE0LTExLTE4IDEzOjA3OjMyLjA2MF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4K
KFhFTikgWzIwMTQtMTEtMTggMTM6MDc6MzIuMTQ0XSB0cmFwcy5jOjI1Nzk6ZDEwdjAgRG9t
YWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAw
MDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDc6
MzguNzQ4XSAtLU1BUkstLQooZDExKSBbMjAxNC0xMS0xOCAxMzowNzozOC43OTZdIG1hcHBp
bmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTEpIFsyMDE0LTExLTE4IDEzOjA3
OjM4Ljc5Nl0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTM6
MDc6MzguODg5XSB0cmFwcy5jOjI1Nzk6ZDExdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAw
MDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAw
MDAwZmZmZi4KKGQxMikgWzIwMTQtMTEtMTggMTM6MDc6NDQuNzI3XSBtYXBwaW5nIGtlcm5l
bCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDEyKSBbMjAxNC0xMS0xOCAxMzowNzo0NC43Mjhd
IGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDEzOjA3OjQ0Ljgy
M10gdHJhcHMuYzoyNTc5OmQxMnYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYu
CihYRU4pIFsyMDE0LTExLTE4IDEzOjA3OjQ1LjY5N10gZ3JhbnRfdGFibGUuYzozMDU6ZDB2
MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA1IGZyYW1lcwooWEVOKSBbMjAxNC0xMS0x
OCAxMzowNzo0NS43MTRdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRy
YWNrIHNpemUgdG8gNiBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDc6NDguNzQ4XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowNzo1MC44MDRdIEFNRC1WaTogRGlzYWJs
ZTogZGV2aWNlIGlkID0gMHhhNCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4p
IFsyMDE0LTExLTE4IDEzOjA3OjUwLjgwNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHhhNCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTE3NWRj
MDAwLCBkb21haW4gPSAxMywgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEz
OjA3OjUwLjgwNF0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowMzowNi4wIGZyb20gZG9tMCB0
byBkb20xMwooZDEzKSBbMjAxNC0xMS0xOCAxMzowNzo1MC44MTFdIG1hcHBpbmcga2VybmVs
IGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTMpIFsyMDE0LTExLTE4IDEzOjA3OjUwLjgxMV0g
YWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDc6NTEuMDU1
XSB0cmFwcy5jOjI1Nzk6ZDEzdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4K
KGQxNCkgWzIwMTQtMTEtMTggMTM6MDc6NTcuMDAyXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBo
eXNpY2FsIG1lbW9yeQooZDE0KSBbMjAxNC0xMS0xOCAxMzowNzo1Ny4wMDJdIGFib3V0IHRv
IGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDEzOjA3OjU3LjA5OF0gdHJhcHMu
YzoyNTc5OmQxNHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsy
MDE0LTExLTE4IDEzOjA3OjU4LjE4MF0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MiBJbmNyZWFz
ZWQgbWFwdHJhY2sgc2l6ZSB0byA3IGZyYW1lcwooWEVOKSBbMjAxNC0xMS0xOCAxMzowNzo1
OC43NDhdIC0tTUFSSy0tCihkMTUpIFsyMDE0LTExLTE4IDEzOjA4OjAzLjUwOF0gbWFwcGlu
ZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQxNSkgWzIwMTQtMTEtMTggMTM6MDg6
MDMuNTA4XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMzow
ODowMy42MDddIHRyYXBzLmM6MjU3OTpkMTV2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAw
MDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAw
MDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowODowOC43NDldIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjA4OjEzLjU0OF0gaW8uYzo1NTI6IGQxNjogYmluZDogbV9nc2k9
MzcgZ19nc2k9MzYgZGV2PTAwLjAwLjUgaW50eD0wIGZmZmY4MzA1MDZkN2Q1MjgKKFhFTikg
WzIwMTQtMTEtMTggMTM6MDg6MTMuOTU4XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9
IDB4ODAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDg6MTMuOTU4XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDgwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTA3ZmNjMDAwLCBkb21haW4g
PSAxNiwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjEzLjk1OF0g
QU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowODowMC4wIGZyb20gZG9tMCB0byBkb20xNgooWEVO
KSBbMjAxNC0xMS0xOCAxMzowODoxNS4wMTVdIGlvLmM6NTUyOiBkMTY6IGJpbmQ6IG1fZ3Np
PTQ3IGdfZ3NpPTQwIGRldj0wMC4wMC42IGludHg9MCBmZmZmODMwNTA2ZDdkZDI4CihYRU4p
IFsyMDE0LTExLTE4IDEzOjA4OjE1LjAyMF0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweGEwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4
IDEzOjA4OjE1LjAyMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHhhMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDUwN2ZjYzAwMCwgZG9tYWlu
ID0gMTYsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoxNS4wMjBd
IEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTYKKGQx
NikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMDMxXSBIVk0gTG9hZGVyCihkMTYpIFsyMDE0LTEx
LTE4IDEzOjA4OjE1LjAzMV0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE2KSBbMjAxNC0x
MS0xOCAxMzowODoxNS4wMzFdIFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hh
bm5lbCAxCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjAzMV0gU3lzdGVtIHJlcXVlc3Rl
ZCBTZWFCSU9TCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjAzMV0gQ1BVIHNwZWVkIGlz
IDMyMDAgTUh6CihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjAzMl0gUmVsb2NhdGluZyBn
dWVzdCBtZW1vcnkgZm9yIGxvd21lbSBNTUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjAzMl0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAwIGNoYW5n
ZWQgMCAtPiA1CihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjAzMl0gUENJLUlTQSBsaW5r
IDAgcm91dGVkIHRvIElSUTUKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMDMzXSBpcnEu
YzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCihkMTYpIFsyMDE0LTEx
LTE4IDEzOjA4OjE1LjAzM10gUENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihYRU4p
IFsyMDE0LTExLTE4IDEzOjA4OjE1LjAzM10gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAy
IGNoYW5nZWQgMCAtPiAxMQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4wMzNdIFBDSS1J
U0EgbGluayAyIHJvdXRlZCB0byBJUlExMQooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoxNS4w
MzNdIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE2KSBb
MjAxNC0xMS0xOCAxMzowODoxNS4wMzNdIFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1
CihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjA1MV0gcGNpIGRldiAwMToyIElOVEQtPklS
UTUKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMDU4XSBwY2kgZGV2IDAxOjMgSU5UQS0+
SVJRMTAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMDYyXSBwY2kgZGV2IDAyOjAgSU5U
QS0+SVJRMTEKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMDc0XSBwY2kgZGV2IDA0OjAg
SU5UQS0+SVJRNQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4wODBdIHBjaSBkZXYgMDU6
MCBJTlRBLT5JUlExMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4wODZdIHBjaSBkZXYg
MDY6MCBJTlRBLT5JUlExMQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xMzJdIE5vIFJB
TSBpbiBoaWdoIG1lbW9yeTsgc2V0dGluZyBoaWdoX21lbSByZXNvdXJjZSBiYXNlIHRvIDEw
MDAwMDAwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xMzNdIHBjaSBkZXYgMDM6MCBi
YXIgMTAgc2l6ZSAwMDIwMDAwMDA6IDBmMDAwMDAwOAooZDE2KSBbMjAxNC0xMS0xOCAxMzow
ODoxNS4xMzVdIHBjaSBkZXYgMDI6MCBiYXIgMTQgc2l6ZSAwMDEwMDAwMDA6IDBmMjAwMDAw
OAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xMzhdIHBjaSBkZXYgMDY6MCBiYXIgMTAg
c2l6ZSAwMDAyMDAwMDA6IDBmMzAwMDAwNAooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoxNS4x
MzhdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAoo
ZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xNDRdIHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6
ZSAwMDAwNDAwMDA6IDBmMzIwMDAwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xNDZd
IHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6ZSAwMDAwMjAwMDA6IDBmMzI0MDAwMAooZDE2KSBb
MjAxNC0xMS0xOCAxMzowODoxNS4xNDZdIHBjaSBkZXYgMDM6MCBiYXIgMzAgc2l6ZSAwMDAw
MTAwMDA6IDBmMzI2MDAwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xNDddIHBjaSBk
ZXYgMDU6MCBiYXIgMTAgc2l6ZSAwMDAwMDIwMDA6IDBmMzI3MDAwNAooWEVOKSBbMjAxNC0x
MS0xOCAxMzowODoxNS4xNDddIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZu
PWZlMGZlIG5yPTEKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMTUzXSBwY2kgZGV2IDAz
OjAgYmFyIDE0IHNpemUgMDAwMDAxMDAwOiAwZjMyNzIwMDAKKGQxNikgWzIwMTQtMTEtMTgg
MTM6MDg6MTUuMTU0XSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAw
MGMwMDEKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMTU2XSBwY2kgZGV2IDA0OjAgYmFy
IDE0IHNpemUgMDAwMDAwMDQwOiAwMDAwMGMxMDEKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6
MTUuMTU4XSBwY2kgZGV2IDAxOjIgYmFyIDIwIHNpemUgMDAwMDAwMDIwOiAwMDAwMGMxNDEK
KGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMTYxXSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNp
emUgMDAwMDAwMDEwOiAwMDAwMGMxNjEKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMTYz
XSBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKKGQxNikgWzIwMTQtMTEtMTggMTM6
MDg6MTUuMTg0XSAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4u
IHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUu
MjAxXSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBN
VFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjE4XSAg
LSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBb
MS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjM0XSAgLSBDUFUz
IC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAu
Li4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjM0XSBUZXN0aW5nIEhWTSBl
bnZpcm9ubWVudDoKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjQzXSAgLSBSRVAgSU5T
QiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxNikgWzIwMTQtMTEtMTgg
MTM6MDg6MTUuMjQ3XSAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCihk
MTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjI0N10gUGFzc2VkIDIgb2YgMiB0ZXN0cwooZDE2
KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNDddIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4K
KGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjQ5XSBMb2FkaW5nIFNlYUJJT1MgLi4uCihk
MTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjI0OV0gQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgoo
ZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNDldIExvYWRpbmcgQUNQSSAuLi4KKGQxNikg
WzIwMTQtMTEtMTggMTM6MDg6MTUuMjUwXSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE2KSBb
MjAxNC0xMS0xOCAxMzowODoxNS4yNTFdIEJJT1MgbWFwOgooZDE2KSBbMjAxNC0xMS0xOCAx
MzowODoxNS4yNTFdICAxMDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE2KSBbMjAxNC0x
MS0xOCAxMzowODoxNS4yNTFdICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjI1MV0gRTgyMCB0YWJsZToKKGQxNikgWzIwMTQtMTEtMTggMTM6
MDg6MTUuMjUxXSAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBhMDAw
MDogUkFNCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjI1MV0gIEhPTEU6IDAwMDAwMDAw
OjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwYzAwMDAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6
MTUuMjUxXSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDog
UkVTRVJWRUQKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjUxXSAgWzAyXTogMDAwMDAw
MDA6MDAxMDAwMDAgLSAwMDAwMDAwMDozZjgwMDAwMDogUkFNCihkMTYpIFsyMDE0LTExLTE4
IDEzOjA4OjE1LjI1MV0gIEhPTEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6ZmMw
MDAwMDAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjUxXSAgWzAzXTogMDAwMDAwMDA6
ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxNikgWzIwMTQtMTEt
MTggMTM6MDg6MTUuMjUxXSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE2KSBbMjAxNC0xMS0x
OCAxMzowODoxNS4yNTVdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMt
MjAxNDExMThfMTI1MjIzLXNlcnZlZXJzdGVydGplKQooZDE2KSBbMjAxNC0xMS0xOCAxMzow
ODoxNS4yNTVdIAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNTVdIEZvdW5kIFhlbiBo
eXBlcnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzow
ODoxNS4yNTVdIFJ1bm5pbmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE2KSBbMjAxNC0xMS0xOCAx
MzowODoxNS4yNTVdIHhlbjogY29weSBlODIwLi4uCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4
OjE1LjI1NV0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZjYyOSB0byAweDNmN2FlNjAw
IChzaXplIDcxOTk1KQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNThdIENQVSBNaHo9
MzIwMQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNjRdIEZvdW5kIDEwIFBDSSBkZXZp
Y2VzIChtYXggUENJIGJ1cyBpcyAwMCkKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjY0
XSBBbGxvY2F0ZWQgWGVuIGh5cGVyY2FsbCBwYWdlIGF0IDNmN2ZmMDAwCihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjI2NF0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE2KSBbMjAx
NC0xMS0xOCAxMzowODoxNS4yNjRdIHhlbjogY29weSBCSU9TIHRhYmxlcy4uLgooZDE2KSBb
MjAxNC0xMS0xOCAxMzowODoxNS4yNjRdIENvcHlpbmcgU01CSU9TIGVudHJ5IHBvaW50IGZy
b20gMHgwMDAxMDAxMCB0byAweDAwMGYwZjUwCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1
LjI2NF0gQ29weWluZyBNUFRBQkxFIGZyb20gMHhmYzAwMTFhMC9mYzAwMTFiMCB0byAweDAw
MGYwZTMwCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjI2NF0gQ29weWluZyBQSVIgZnJv
bSAweDAwMDEwMDMwIHRvIDB4MDAwZjBkYjAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUu
MjY0XSBDb3B5aW5nIEFDUEkgUlNEUCBmcm9tIDB4MDAwMTAwYjAgdG8gMHgwMDBmMGQ4MAoo
ZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNjRdIFVzaW5nIHBtdGltZXIsIGlvcG9ydCAw
eGIwMDgKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjY0XSBTY2FuIGZvciBWR0Egb3B0
aW9uIHJvbQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yODFdIFJ1bm5pbmcgb3B0aW9u
IHJvbSBhdCBjMDAwOjAwMDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjkwXSBzdGR2
Z2EuYzoxNDc6ZDE2djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihkMTYp
IFsyMDE0LTExLTE4IDEzOjA4OjE1LjMxN10gcG1tIGNhbGwgYXJnMT0wCihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjMxOF0gVHVybmluZyBvbiB2Z2EgdGV4dCBtb2RlIGNvbnNvbGUK
KGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuNDQyXSBTZWFCSU9TICh2ZXJzaW9uIHJlbC0x
LjcuNS0wLWdlNTE0ODhjLTIwMTQxMTE4XzEyNTIyMy1zZXJ2ZWVyc3RlcnRqZSkKKGQxNikg
WzIwMTQtMTEtMTggMTM6MDg6MTUuNDU2XSBNYWNoaW5lIFVVSUQgMTc3NTY4NTctMWI0ZS00
YThkLTkxNDktMmM2ZWJhYjAyNjE4CihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjQ1N10g
WEhDSSBpbml0IG9uIGRldiAwMDowNS4wOiByZWdzIEAgMHhmMzI3MDAwMCwgNCBwb3J0cywg
MzIgc2xvdHMsIDMyIGJ5dGUgY29udGV4dAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS40
NTddIHMKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuNDU3XSBYSENJICAgIGV4dGNhcCAw
eDEgQCBmMzI3MDUwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS40NTddIFhIQ0kgICAg
cHJvdG9jb2wgVVNCICAzLjAwLCAyIHBvcnRzIChvZmZzZXQgMSksIGRlZiAwCihkMTYpIFsy
MDE0LTExLTE4IDEzOjA4OjE1LjQ1N10gWEhDSSAgICBwcm90b2NvbCBVU0IgIDIuMDAsIDIg
cG9ydHMgKG9mZnNldCAzKSwgZGVmIDAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuNDU4
XSBVSENJIGluaXQgb24gZGV2IDAwOjAxLjIgKGlvPWMxNDApCihkMTYpIFsyMDE0LTExLTE4
IDEzOjA4OjE1LjQ1OV0gRm91bmQgMCBscHQgcG9ydHMKKGQxNikgWzIwMTQtMTEtMTggMTM6
MDg6MTUuNDU5XSBGb3VuZCAxIHNlcmlhbCBwb3J0cwooZDE2KSBbMjAxNC0xMS0xOCAxMzow
ODoxNS40NjBdIEFUQSBjb250cm9sbGVyIDEgYXQgMWYwLzNmNC8wIChpcnEgMTQgZGV2IDkp
CihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjQ2Ml0gQVRBIGNvbnRyb2xsZXIgMiBhdCAx
NzAvMzc0LzAgKGlycSAxNSBkZXYgOSkKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuNDY1
XSBhdGEwLTA6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgxMDI0MCBNaUJ5dGVz
KQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS40NjVdIFNlYXJjaGluZyBib290b3JkZXIg
Zm9yOiAvcGNpQGkwY2Y4LypAMSwxL2RyaXZlQDAvZGlza0AwCihkMTYpIFsyMDE0LTExLTE4
IDEzOjA4OjE1LjQ2N10gYXRhMC0xOiBRRU1VIEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAo
MzAwIEdpQnl0ZXMpCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjQ2N10gU2VhcmNoaW5n
IGJvb3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDEKKGQxNikg
WzIwMTQtMTEtMTggMTM6MDg6MTUuNTY0XSBQUzIga2V5Ym9hcmQgaW5pdGlhbGl6ZWQKKGQx
NikgWzIwMTQtMTEtMTggMTM6MDg6MTUuNjA5XSBYSENJIHBvcnQgIzQ6IDB4MDAyMDBhMDMs
IHBvd2VyZWQsIGVuYWJsZWQsIHBscyAwLCBzcGVlZCAyIFtMb3ddCihkMTYpIFsyMDE0LTEx
LTE4IDEzOjA4OjE1LjY0MF0gWEhDSSBubyBkZXZpY2VzIGZvdW5kCihkMTYpIFsyMDE0LTEx
LTE4IDEzOjA4OjE1LjY1MV0gQWxsIHRocmVhZHMgY29tcGxldGUuCihkMTYpIFsyMDE0LTEx
LTE4IDEzOjA4OjE1LjY1MV0gU2NhbiBmb3Igb3B0aW9uIHJvbXMKKGQxNikgWzIwMTQtMTEt
MTggMTM6MDg6MTUuNjc1XSBSdW5uaW5nIG9wdGlvbiByb20gYXQgYzk4MDowMDAzCihkMTYp
IFsyMDE0LTExLTE4IDEzOjA4OjE1LjY4MV0gcG1tIGNhbGwgYXJnMT0xCihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjY4Ml0gcG1tIGNhbGwgYXJnMT0wCihkMTYpIFsyMDE0LTExLTE4
IDEzOjA4OjE1LjY4M10gcG1tIGNhbGwgYXJnMT0xCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4
OjE1LjY4M10gcG1tIGNhbGwgYXJnMT0wCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1Ljcw
MF0gU2VhcmNoaW5nIGJvb3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkA0CihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjcwMF0gCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjcwN10g
UHJlc3MgRjEyIGZvciBib290IG1lbnUuCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1Ljcw
OF0gCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE4LjI0N10gU2VhcmNoaW5nIGJvb3RvcmRl
ciBmb3I6IEhBTFQKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTguMjQ3XSBkcml2ZSAweDAw
MGYwZDMwOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1
LzYzIHM9MjA5NzE1MjAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTguMjQ3XSBkcml2ZSAw
eDAwMGYwZDAwOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQv
MjU1LzYzIHM9NjI5MTQ1NjAwCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE4LjI0N10gCihk
MTYpIFsyMDE0LTExLTE4IDEzOjA4OjE4LjI0N10gU3BhY2UgYXZhaWxhYmxlIGZvciBVTUI6
IGNhODAwLWVmMDAwLCBmMDAwMC1mMGQwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxOC4y
NDddIFJldHVybmVkIDI1Mzk1MiBieXRlcyBvZiBab25lSGlnaAooZDE2KSBbMjAxNC0xMS0x
OCAxMzowODoxOC4yNDddIGU4MjAgbWFwIGhhcyA2IGl0ZW1zOgooZDE2KSBbMjAxNC0xMS0x
OCAxMzowODoxOC4yNDddICAgMDogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWZj
MDAgPSAxIFJBTQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxOC4yNDddICAgMTogMDAwMDAw
MDAwMDA5ZmMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgPSAyIFJFU0VSVkVECihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE4LjI0N10gICAyOiAwMDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAw
MDEwMDAwMCA9IDIgUkVTRVJWRUQKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTguMjQ3XSAg
IDM6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDNmN2ZlMDAwID0gMSBSQU0KKGQxNikg
WzIwMTQtMTEtMTggMTM6MDg6MTguMjQ3XSAgIDQ6IDAwMDAwMDAwM2Y3ZmUwMDAgLSAwMDAw
MDAwMDNmODAwMDAwID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxOC4y
NDddICAgNTogMDAwMDAwMDBmYzAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJFU0VS
VkVECihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE4LjI0OF0gZW50ZXIgaGFuZGxlXzE5Ogoo
ZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxOC4yNDhdICAgTlVMTAooZDE2KSBbMjAxNC0xMS0x
OCAxMzowODoxOC4yNTVdIEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4KKGQxNikgWzIwMTQt
MTEtMTggMTM6MDg6MTguMjU3XSBCb290aW5nIGZyb20gMDAwMDo3YzAwCihYRU4pIFsyMDE0
LTExLTE4IDEzOjA4OjE4Ljc0OV0gLS1NQVJLLS0KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuNDY3XSBIVk0gTG9hZGVyCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjQ2N10gRGV0
ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi40NjddIFhl
bmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCAxCihkMTcpIFsyMDE0LTEx
LTE4IDEzOjA4OjIyLjQ2OF0gU3lzdGVtIHJlcXVlc3RlZCBTZWFCSU9TCihkMTcpIFsyMDE0
LTExLTE4IDEzOjA4OjIyLjQ2OF0gQ1BVIHNwZWVkIGlzIDMyMDAgTUh6CihkMTcpIFsyMDE0
LTExLTE4IDEzOjA4OjIyLjQ2OF0gUmVsb2NhdGluZyBndWVzdCBtZW1vcnkgZm9yIGxvd21l
bSBNTUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjIyLjQ2OF0g
aXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1CihkMTcpIFsyMDE0
LTExLTE4IDEzOjA4OjIyLjQ2OF0gUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUKKFhF
TikgWzIwMTQtMTEtMTggMTM6MDg6MjIuNDY4XSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5r
IDEgY2hhbmdlZCAwIC0+IDEwCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjQ2OF0gUENJ
LUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjIy
LjQ2OF0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAyIGNoYW5nZWQgMCAtPiAxMQooZDE3
KSBbMjAxNC0xMS0xOCAxMzowODoyMi40NjldIFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJ
UlExMQooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoyMi40NjldIGlycS5jOjI3MDogRG9tMTcg
UENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi40
NjldIFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1CihkMTcpIFsyMDE0LTExLTE4IDEz
OjA4OjIyLjQ4Nl0gcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihkMTcpIFsyMDE0LTExLTE4
IDEzOjA4OjIyLjQ5Ml0gcGNpIGRldiAwMjowIElOVEEtPklSUTExCihkMTcpIFsyMDE0LTEx
LTE4IDEzOjA4OjIyLjUwMl0gcGNpIGRldiAwNDowIElOVEEtPklSUTUKKGQxNykgWzIwMTQt
MTEtMTggMTM6MDg6MjIuNTQ5XSBObyBSQU0gaW4gaGlnaCBtZW1vcnk7IHNldHRpbmcgaGln
aF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTM6
MDg6MjIuNTUwXSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAyMDAwMDAwOiAwZjAwMDAw
MDgKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNTUyXSBwY2kgZGV2IDAyOjAgYmFyIDE0
IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIu
NTUzXSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUgMDAwMDQwMDAwOiAwZjMwMDAwMDAKKGQx
NykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNTU1XSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUg
MDAwMDIwMDAwOiAwZjMwNDAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNTU1XSBw
Y2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEwMDAwOiAwZjMwNjAwMDAKKGQxNykgWzIw
MTQtMTEtMTggMTM6MDg6MjIuNTU3XSBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDAwMDAx
MDAwOiAwZjMwNzAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNTU3XSBwY2kgZGV2
IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDEKKGQxNykgWzIwMTQtMTEt
MTggMTM6MDg6MjIuNTU5XSBwY2kgZGV2IDA0OjAgYmFyIDE0IHNpemUgMDAwMDAwMDQwOiAw
MDAwMGMxMDEKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNTYxXSBwY2kgZGV2IDAxOjEg
YmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNDEKKGQxNykgWzIwMTQtMTEtMTggMTM6
MDg6MjIuNTYzXSBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKKGQxNykgWzIwMTQt
MTEtMTggMTM6MDg6MjIuNTgyXSAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQg
TVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTgg
MTM6MDg6MjIuNjAwXSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMg
Li4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuNjE4XSAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh
ciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjM2
XSAgLSBDUFUzIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS
cyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjM2XSBUZXN0
aW5nIEhWTSBlbnZpcm9ubWVudDoKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjQ2XSAg
LSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxNykgWzIw
MTQtMTEtMTggMTM6MDg6MjIuNjUwXSAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4g
cGFzc2VkCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY1MF0gUGFzc2VkIDIgb2YgMiB0
ZXN0cwooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTBdIFdyaXRpbmcgU01CSU9TIHRh
YmxlcyAuLi4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjUxXSBMb2FkaW5nIFNlYUJJ
T1MgLi4uCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY1MV0gQ3JlYXRpbmcgTVAgdGFi
bGVzIC4uLgooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTFdIExvYWRpbmcgQUNQSSAu
Li4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjUzXSB2bTg2IFRTUyBhdCBmYzAwYTIw
MAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTNdIEJJT1MgbWFwOgooZDE3KSBbMjAx
NC0xMS0xOCAxMzowODoyMi42NTNdICAxMDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE3
KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTNdICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihk
MTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY1M10gRTgyMCB0YWJsZToKKGQxNykgWzIwMTQt
MTEtMTggMTM6MDg6MjIuNjUzXSAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAw
MDowMDBhMDAwMDogUkFNCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY1M10gIEhPTEU6
IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwYzAwMDAKKGQxNykgWzIwMTQtMTEt
MTggMTM6MDg6MjIuNjUzXSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDow
MDEwMDAwMDogUkVTRVJWRUQKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjUzXSAgWzAy
XTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDozZjgwMDAwMDogUkFNCihkMTcpIFsy
MDE0LTExLTE4IDEzOjA4OjIyLjY1M10gIEhPTEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAw
MDAwMDA6ZmMwMDAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjUzXSAgWzAzXTog
MDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxNykg
WzIwMTQtMTEtMTggMTM6MDg6MjIuNjU0XSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE3KSBb
MjAxNC0xMS0xOCAxMzowODoyMi42NTZdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAt
Z2U1MTQ4OGMtMjAxNDExMThfMTI1MjIzLXNlcnZlZXJzdGVydGplKQooZDE3KSBbMjAxNC0x
MS0xOCAxMzowODoyMi42NTZdIAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTZdIEZv
dW5kIFhlbiBoeXBlcnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMAooZDE3KSBbMjAxNC0x
MS0xOCAxMzowODoyMi42NTZdIFJ1bm5pbmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE3KSBbMjAx
NC0xMS0xOCAxMzowODoyMi42NTZdIHhlbjogY29weSBlODIwLi4uCihkMTcpIFsyMDE0LTEx
LTE4IDEzOjA4OjIyLjY1Nl0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZjYyOSB0byAw
eDNmN2FlNjAwIChzaXplIDcxOTk1KQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTld
IENQVSBNaHo9MzIwMQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NjNdIEZvdW5kIDcg
UENJIGRldmljZXMgKG1heCBQQ0kgYnVzIGlzIDAwKQooZDE3KSBbMjAxNC0xMS0xOCAxMzow
ODoyMi42NjNdIEFsbG9jYXRlZCBYZW4gaHlwZXJjYWxsIHBhZ2UgYXQgM2Y3ZmYwMDAKKGQx
NykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjYzXSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihk
MTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY2M10geGVuOiBjb3B5IEJJT1MgdGFibGVzLi4u
CihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY2M10gQ29weWluZyBTTUJJT1MgZW50cnkg
cG9pbnQgZnJvbSAweDAwMDEwMDEwIHRvIDB4MDAwZjBmNTAKKGQxNykgWzIwMTQtMTEtMTgg
MTM6MDg6MjIuNjYzXSBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMWEwL2ZjMDAxMWIw
IHRvIDB4MDAwZjBlMzAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjYzXSBDb3B5aW5n
IFBJUiBmcm9tIDB4MDAwMTAwMzAgdG8gMHgwMDBmMGRiMAooZDE3KSBbMjAxNC0xMS0xOCAx
MzowODoyMi42NjNdIENvcHlpbmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAw
MGYwZDgwCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY2M10gVXNpbmcgcG10aW1lciwg
aW9wb3J0IDB4YjAwOAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NjNdIFNjYW4gZm9y
IFZHQSBvcHRpb24gcm9tCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY3OV0gUnVubmlu
ZyBvcHRpb24gcm9tIGF0IGMwMDA6MDAwMwooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoyMi42
ODhdIHN0ZHZnYS5jOjE0NzpkMTd2MCBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9k
ZXMKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNzA3XSBwbW0gY2FsbCBhcmcxPTAKKGQx
NykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNzA4XSBUdXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUg
Y29uc29sZQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi44MzRdIFNlYUJJT1MgKHZlcnNp
b24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMThfMTI1MjIzLXNlcnZlZXJzdGVydGpl
KQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi44NDddIE1hY2hpbmUgVVVJRCAzZDczNDUz
MS0wZWQ2LTQwNTEtODA4Yi00Y2Q3YTNkNmFkMDIKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuODQ4XSBBbGwgdGhyZWFkcyBjb21wbGV0ZS4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuODQ4XSBGb3VuZCAwIGxwdCBwb3J0cwooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi44
NDldIEZvdW5kIDAgc2VyaWFsIHBvcnRzCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjg0
OV0gQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0LzAgKGlycSAxNCBkZXYgOSkKKGQxNykg
WzIwMTQtMTEtMTggMTM6MDg6MjIuODUwXSBBVEEgY29udHJvbGxlciAyIGF0IDE3MC8zNzQv
MCAoaXJxIDE1IGRldiA5KQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi44NTRdIGF0YTAt
MDogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDEwMjQwIE1pQnl0ZXMpCihkMTcp
IFsyMDE0LTExLTE4IDEzOjA4OjIyLjg1NF0gU2VhcmNoaW5nIGJvb3RvcmRlciBmb3I6IC9w
Y2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuOTUyXSBQUzIga2V5Ym9hcmQgaW5pdGlhbGl6ZWQKKGQxNykgWzIwMTQtMTEtMTggMTM6
MDg6MjIuOTUyXSBBbGwgdGhyZWFkcyBjb21wbGV0ZS4KKGQxNykgWzIwMTQtMTEtMTggMTM6
MDg6MjIuOTUyXSBTY2FuIGZvciBvcHRpb24gcm9tcwooZDE3KSBbMjAxNC0xMS0xOCAxMzow
ODoyMi45NzVdIFJ1bm5pbmcgb3B0aW9uIHJvbSBhdCBjOTgwOjAwMDMKKGQxNykgWzIwMTQt
MTEtMTggMTM6MDg6MjIuOTgxXSBwbW0gY2FsbCBhcmcxPTEKKGQxNykgWzIwMTQtMTEtMTgg
MTM6MDg6MjIuOTgyXSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuOTgzXSBwbW0gY2FsbCBhcmcxPTEKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuOTgz
XSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjMuMDAwXSBTZWFy
Y2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDQKKGQxNykgWzIwMTQtMTEtMTgg
MTM6MDg6MjMuMDAwXSAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjMuMDA2XSBQcmVzcyBG
MTIgZm9yIGJvb3QgbWVudS4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjMuMDA2XSAKKFhF
TikgWzIwMTQtMTEtMTggMTM6MDg6MjMuNzcxXSBzdGR2Z2EuYzoxNTE6ZDE2djAgbGVhdmlu
ZyBzdGR2Z2EKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjUuNTUxXSBTZWFyY2hpbmcgYm9v
dG9yZGVyIGZvcjogSEFMVAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyNS41NTJdIGRyaXZl
IDB4MDAwZjBkMzA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAy
NC8yNTUvNjMgcz0yMDk3MTUyMAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyNS41NTJdIFNw
YWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkMzAKKGQxNykg
WzIwMTQtMTEtMTggMTM6MDg6MjUuNTUyXSBSZXR1cm5lZCAyNTgwNDggYnl0ZXMgb2YgWm9u
ZUhpZ2gKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjUuNTUyXSBlODIwIG1hcCBoYXMgNiBp
dGVtczoKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjUuNTUyXSAgIDA6IDAwMDAwMDAwMDAw
MDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0KKGQxNykgWzIwMTQtMTEtMTggMTM6
MDg6MjUuNTUyXSAgIDE6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEwMDAwID0g
MiBSRVNFUlZFRAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyNS41NTJdICAgMjogMDAwMDAw
MDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgPSAyIFJFU0VSVkVECihkMTcpIFsyMDE0
LTExLTE4IDEzOjA4OjI1LjU1Ml0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDAz
ZjdmZjAwMCA9IDEgUkFNCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjI1LjU1Ml0gICA0OiAw
MDAwMDAwMDNmN2ZmMDAwIC0gMDAwMDAwMDAzZjgwMDAwMCA9IDIgUkVTRVJWRUQKKGQxNykg
WzIwMTQtMTEtMTggMTM6MDg6MjUuNTUyXSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAgLSAwMDAw
MDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyNS41
NTNdIGVudGVyIGhhbmRsZV8xOToKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjUuNTUzXSAg
IE5VTEwKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjUuNTU5XSBCb290aW5nIGZyb20gSGFy
ZCBEaXNrLi4uCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjI1LjU2MV0gQm9vdGluZyBmcm9t
IDAwMDA6N2MwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoyOC4xMjFdIGdyYW50X3RhYmxl
LmM6MzA1OmQwdjQgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gOCBmcmFtZXMKKFhFTikg
WzIwMTQtMTEtMTggMTM6MDg6MjguNzQ5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MzowODozMi4wMzhdIHN0ZHZnYS5jOjE1MTpkMTd2MCBsZWF2aW5nIHN0ZHZnYQooWEVOKSBb
MjAxNC0xMS0xOCAxMzowODozOC43NDldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjA4OjQ4Ljc0OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6NDkuNTQ4XSBz
dGR2Z2EuYzoxNDc6ZDE2djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihY
RU4pIFsyMDE0LTExLTE4IDEzOjA4OjUxLjE1N10gaXJxLmM6MzgwOiBEb20xNiBjYWxsYmFj
ayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMKKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDg6NTYuNTEzXSBzdGR2Z2EuYzoxNDc6ZDE3djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBj
YWNoaW5nIG1vZGVzCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU2Ljk5OV0gbWVtb3J5X21h
cDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0x
MS0xOCAxMzowODo1Ny4wMDRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZu
PWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6NTcuMDA4XSBtZW1vcnlfbWFw
OnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjA4OjU3LjAxM10gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49
ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xOCAxMzowODo1Ny4wMTddIG1lbW9yeV9tYXA6
cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEt
MTggMTM6MDg6NTcuMDIzXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1m
ZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjAyN10gbWVtb3J5X21hcDpy
ZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0x
OCAxMzowODo1Ny4wMzJdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZl
MGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6NTcuMDM2XSBtZW1vcnlfbWFwOnJl
bW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE4
IDEzOjA4OjU3LjA0MF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUw
ZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xOCAxMzowODo1Ny4wNDRdIG1lbW9yeV9tYXA6cmVt
b3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDg6NTcuMDQ5XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBm
ZSBucj0xCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjA1OV0gbWVtb3J5X21hcDpyZW1v
dmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4
IDEzOjA4OjU3LjA2Nl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUy
MDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjA3Ml0gbWVtb3J5X21hcDpy
ZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjA4OjU3LjA3OF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBtZm49
ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjA4M10gbWVtb3J5X21h
cDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0
LTExLTE4IDEzOjA4OjU3LjA4OV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBt
Zm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjA5NV0gbWVtb3J5
X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsy
MDE0LTExLTE4IDEzOjA4OjU3LjEwMV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAw
MCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjEwN10gbWVt
b3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4p
IFsyMDE0LTExLTE4IDEzOjA4OjU3LjExM10gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1m
MzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjExOF0g
bWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihY
RU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjEyNF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdm
bj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjE1
OV0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCihYRU4pIFsy
MDE0LTExLTE4IDEzOjA4OjU3LjE4MF0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAxIGNo
YW5nZWQgMTAgLT4gMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowODo1Ny4yMDFdIGlycS5jOjI3
MDogRG9tMTYgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDAKKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDg6NTcuMjI2XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDMgY2hhbmdlZCA1IC0+
IDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6NTguMjAxXSBpcnEuYzozODA6IERvbTE3IGNh
bGxiYWNrIHZpYSBjaGFuZ2VkIHRvIERpcmVjdCBWZWN0b3IgMHhmMwooWEVOKSBbMjAxNC0x
MS0xOCAxMzowODo1OC43NDldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU5
LjIxNV0gZ3JhbnRfdGFibGUuYzoxMjk5OmQxNnYzIEV4cGFuZGluZyBkb20gKDE2KSBncmFu
dCB0YWJsZSBmcm9tICg0KSB0byAoNSkgZnJhbWVzLgooWEVOKSBbMjAxNC0xMS0xOCAxMzow
ODo1OS4zMDVdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMAoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowODo1OS4zMTFdIGlycS5jOjI3MDogRG9tMTcgUENJIGxp
bmsgMSBjaGFuZ2VkIDEwIC0+IDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6NTkuMzE3XSBp
cnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwCihYRU4pIFsyMDE0
LTExLTE4IDEzOjA4OjU5LjMyMl0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAzIGNoYW5n
ZWQgNSAtPiAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU5Ljc5MF0gZ3JhbnRfdGFibGUu
YzoxMjk5OmQxN3YyIEV4cGFuZGluZyBkb20gKDE3KSBncmFudCB0YWJsZSBmcm9tICg0KSB0
byAoNSkgZnJhbWVzLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowOTowOC43NDldIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjA5OjE4Ljc1MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MDk6MjguNzUwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowOToy
OS42NDVdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUg
dG8gOSBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDk6MzguNzUwXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowOTo0OC43NTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjA5OjU4Ljc1MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTA6MDgu
NzUwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxMDoxOC43NTFdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjEwOjI4Ljc1MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MTA6MzguNzUxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxMDo0
OC43NTFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjEwOjU4Ljc1MV0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTE6MDguNzUyXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzoxMToxMi4yNzhdIGdyYW50X3RhYmxlLmM6MTI5OTpkMTZ2MSBFeHBhbmRp
bmcgZG9tICgxNikgZ3JhbnQgdGFibGUgZnJvbSAoNSkgdG8gKDYpIGZyYW1lcy4KKFhFTikg
WzIwMTQtMTEtMTggMTM6MTE6MTIuNTE3XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIEluY3Jl
YXNlZCBtYXB0cmFjayBzaXplIHRvIDEwIGZyYW1lcwooWEVOKSBbMjAxNC0xMS0xOCAxMzox
MToxOC43NTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjExOjI4Ljc1Ml0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTE6MzguNzUyXSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMzoxMTo0OC43NTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjExOjU4Ljc1M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTI6MDguNzUzXSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxMjoxOC43NTNdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjEyOjI4Ljc1M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6MTI6MzguNzUzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxMjo0OC44Nzld
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjEyOjU4Ljg4MF0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6MTM6MDguODgwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzoxMzoxOC44ODBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjEzOjI4Ljg4
MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTM6MzguODgwXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzoxMzo0OC44ODFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjEzOjU4Ljg4MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTQ6MDgu
ODgxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxNDoxOC44ODFdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjE0OjI4Ljg4MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MTQ6MzguODgxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxNDo0
OC44ODFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE0OjU4Ljg4Ml0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTU6MDguODgyXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzoxNToxOC44ODJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE1
OjI4Ljg4Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTU6MzguODgyXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxNTo0OC44ODJdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjE1OjU4Ljg4M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
MTY6MDguODgzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxNjoxOC44ODNdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE2OjI4Ljg4M10gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6MTY6MzguODgzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MzoxNjo0OC44ODNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE2OjU4Ljg4NF0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTc6MDguODg0XSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxMzoxNzoxOC44ODRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDEzOjE3OjI4Ljg4NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTc6MzguODg0
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxNzo0OC44ODRdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDEzOjE3OjU4Ljg4NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTM6MTg6MDguODg1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxODoxOC44
ODVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE4OjI4Ljg4NV0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTM6MTg6MzguODg1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMzoxODo0OC44ODVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE4OjU4
Ljg4NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTk6MDguODg2XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxOToxOC44ODZdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDEzOjE5OjI4Ljg4Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTk6
MzguODg2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxOTo0NS4zNzldIGdyYW50
X3RhYmxlLmM6MTI5OTpkMTZ2MiBFeHBhbmRpbmcgZG9tICgxNikgZ3JhbnQgdGFibGUgZnJv
bSAoNikgdG8gKDcpIGZyYW1lcy4KKFhFTikgWzIwMTQtMTEtMTggMTM6MTk6NDguODg2XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxOTo1OC44ODddIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjIwOjA4Ljg4N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6MjA6MTguODg3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyMDoyOC44ODdd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjIwOjM4Ljg4N10gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6MjA6NDguODg4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzoyMDo1OC44ODhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjIxOjA4Ljg4
OF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjE6MTguODg4XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzoyMToyOC44ODhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjIxOjM4Ljg4OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjE6NDgu
ODg5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyMTo1OC44ODldIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjIyOjA4Ljg4OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MjI6MTguODg5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyMjoy
OC44ODldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjIyOjM4Ljg5MF0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjI6NDguODkwXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzoyMjo1OC44OTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjIz
OjA4Ljg5MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjM6MTguODkwXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyMzoyOC44OTFdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjIzOjM4Ljg5MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
MjM6NDguODkxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyMzo1OC44OTFdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI0OjA4Ljg5MV0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6MjQ6MTguODkyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MzoyNDoyOC44OTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI0OjM4Ljg5Ml0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjQ6NDguODkyXSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxMzoyNDo1OC44OTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDEzOjI1OjA4Ljg5M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjU6MTguODkz
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyNToyOC44OTNdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDEzOjI1OjM4Ljg5M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTM6MjU6NDguODk0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyNTo1OC44
OTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI2OjA4Ljg5NF0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTM6MjY6MTguODk0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMzoyNjoyOC44OTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI2OjM4
Ljg5NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjY6NDguODk1XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyNjo1OC44OTVdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDEzOjI3OjA4Ljg5NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mjc6
MTguODk1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyNzoyOC44OTVdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI3OjM4Ljg5Nl0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTM6Mjc6NDguODk2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoy
Nzo1OC44OTZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI4OjA4Ljg5Nl0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mjg6MTguODk2XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMzoyODoyOC44OTddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjI4OjM4Ljg5N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mjg6NDguODk3XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyODo1OC44OTddIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjI5OjA4Ljg5N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6Mjk6MTguODk4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyOToyOC44OThd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI5OjM4Ljg5OF0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6Mjk6NDguODk4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzoyOTo1OC44OTldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjMwOjA4Ljg5
OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzA6MTguODk5XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzozMDoyOC44OTldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjMwOjM4Ljg5OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzA6NDgu
OTAwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozMDo1OC45MDBdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjMxOjA4LjkwMF0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MzE6MTguOTAwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozMToy
OC45MDBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjMxOjM4LjkwMV0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzE6NDguOTAxXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzozMTo1OC45MDFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjMy
OjA4LjkwMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzI6MTguOTAxXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozMjoyOC45MDJdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjMyOjM4LjkwMl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
MzI6NDguOTAyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozMjo1OC45MDJdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjMzOjA4LjkwM10gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6MzM6MTguOTAzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MzozMzoyOC45MDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjMzOjM4LjkwM10g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzM6NDguOTA0XSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxMzozMzo1OC45MDRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDEzOjM0OjA4LjkwNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzQ6MTguOTA0
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozNDoyOC45MDRdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDEzOjM0OjM4LjkwNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTM6MzQ6NDguOTA0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozNDo1OC45
MDVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM1OjA4LjkwNV0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTM6MzU6MTguOTA1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMzozNToyOC45MDVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM1OjM4
LjkwNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzU6NDguOTA2XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzozNTo1OC45MDZdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDEzOjM2OjA4LjkwNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzY6
MTguOTA2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozNjoyOC45MDddIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM2OjM4LjkwN10gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTM6MzY6NDguOTA3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoz
Njo1OC45MDddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM3OjA4LjkwOF0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mzc6MTguOTA4XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMzozNzoyOC45MDhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjM3OjM4LjkwOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mzc6NDguOTA4XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozNzo1OC45MDldIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjM4OjA4LjkwOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6Mzg6MTguOTA5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozODoyOC45MDld
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM4OjM4LjkwOV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6Mzg6NDguOTEwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzozODo1OC45MTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM5OjA4Ljkx
MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mzk6MTguOTEwXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzozOToyOC45MTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjM5OjM4LjkxMF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mzk6NDgu
OTExXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozOTo1OC45MTFdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjQwOjA4LjkxMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6NDA6MTguOTExXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0MDoy
OC45MTFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQwOjM4LjkxMl0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDA6NDguOTEyXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzo0MDo1OC45MTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQx
OjA4LjkxMl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDE6MTguOTEyXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0MToyOC45MTJdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjQxOjM4LjkxM10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
NDE6NDguOTEzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0MTo1OC45MTNdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQyOjA4LjkxM10gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6NDI6MTguOTEzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
Mzo0MjoyOC45MTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQyOjM4LjkxNF0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDI6NDguOTE0XSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxMzo0Mjo1OC45MTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDEzOjQzOjA4LjkxNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDM6MTguOTE0
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0MzoyOC45MTRdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDEzOjQzOjM4LjkxNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTM6NDM6NDguOTE1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0Mzo1OC45
MTVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ0OjA4LjkxNV0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTM6NDQ6MTguOTE1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMzo0NDoyOC45MTVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ0OjM4
LjkxNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDQ6NDguOTE2XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0NDo1OC45MTZdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDEzOjQ1OjA4LjkxNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDU6
MTguOTE2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0NToyOC45MTZdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ1OjM4LjkxN10gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTM6NDU6NDguOTEzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0
NTo1OC45MTNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ2OjA4LjkxM10gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDY6MTguOTE0XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMzo0NjoyOC45MTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjQ2OjM4LjkxNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDY6NDguOTE0XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0Njo1OC45MTRdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjQ3OjA4LjkxNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6NDc6MTguOTE1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0NzoyOC45MTVd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ3OjM4LjkxNV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6NDc6NDguOTE1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzo0Nzo1OC45MTVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ4OjA4Ljkx
Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDg6MTguOTE2XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzo0ODoyOC45MTZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjQ4OjM4LjkxNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDg6NDgu
OTE2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0ODo1OC45MTZdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjQ5OjA4LjkxN10gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6NDk6MTguOTE3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0OToy
OC45MTddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ5OjM4LjkxN10gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDk6NDguOTE3XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzo0OTo1OC45MTddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjUw
OjA4LjkxOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTA6MTguOTE4XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1MDoyOC45MThdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjUwOjM4LjkxOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
NTA6NDguOTE4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1MDo1OC45MTldIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjUxOjA4LjkxOV0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6NTE6MTguOTE5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
Mzo1MToyOC45MTldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjUxOjM4LjkxOV0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTE6NDguOTIwXSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxMzo1MTo1OC45MjBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDEzOjUyOjA4LjkyMF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTI6MTguOTIw
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1MjoyOC45MjBdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDEzOjUyOjM4LjkyMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTM6NTI6NDguOTIxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1Mjo1OC45
MjFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjUzOjA4LjkyMV0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTM6NTM6MTguOTIyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMzo1MzoyOC45MjJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjUzOjM4
LjkyMl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTM6NDguOTIyXSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1Mzo1OC45MjJdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDEzOjU0OjA4LjkyM10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTQ6
MTguOTIzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1NDoyOC45MjNdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU0OjM4LjkyM10gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTM6NTQ6NDguOTIzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1
NDo1OC45MjRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU1OjA4LjkyNF0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTU6MTguOTI0XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMzo1NToyOC45MjRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjU1OjM4LjkyNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTU6NDguOTI1XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1NTo1OC45MjVdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjU2OjA4LjkyNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6NTY6MTguOTI1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1NjoyOC45MjVd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU2OjM4LjkyNV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6NTY6NDguOTI1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzo1Njo1OC45MjVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU3OjA4Ljky
Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTc6MTguOTI2XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzo1NzoyOC45MjZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjU3OjM4LjkyNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTc6NDgu
OTI3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1Nzo1OC45MjddIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjU4OjA4LjkyN10gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6NTg6MTguOTI3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1ODoy
OC45MjhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU4OjM4LjkyOF0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTg6NDguOTI4XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzo1ODo1OC45MjhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU5
OjA4LjkyOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTk6MTguOTI4XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1OToyOC45MjldIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjU5OjM4LjkyOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
NTk6NDguOTI5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1OTo1OC45MjldIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjAwOjA4LjkyOV0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MDA6MTguOTMwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
NDowMDoyOC45MzBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjAwOjM4LjkzMF0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDA6NDguOTMwXSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxNDowMDo1OC45MzBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDE0OjAxOjA4LjkzMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDE6MTguOTMx
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowMToyOC45MzFdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDE0OjAxOjM4LjkzMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MDE6NDguOTMxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowMTo1OC45
MzJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjAyOjA4LjkzMl0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MDI6MTguOTMyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxNDowMjoyOC45MzJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjAyOjM4
LjkzMl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDI6NDguOTMzXSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxNDowMjo1OC45MzNdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDE0OjAzOjA4LjkzM10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDM6
MTguOTMzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowMzoyOC45MzRdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjAzOjM4LjkzNF0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6MDM6NDguOTM0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDow
Mzo1OC45MzRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA0OjA4LjkzNF0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDQ6MTguOTM0XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxNDowNDoyOC45MzVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0
OjA0OjM4LjkzNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDQ6NDguOTM1XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowNDo1OC45MzVdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDE0OjA1OjA4LjkzNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6MDU6MTguOTM2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowNToyOC45MzZd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA1OjM4LjkzNl0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MDU6NDguOTM2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxNDowNTo1OC45MzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA2OjA4Ljkz
N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDY6MTguOTM3XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDowNjoyOC45MzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjA2OjM4LjkzN10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDY6NDgu
OTM4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowNjo1OC45MzhdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDE0OjA3OjA4LjkzOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTQ6MDc6MTguOTM4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowNzoy
OC45MzhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA3OjM4LjkzOV0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDc6NDguOTM1XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxNDowNzo1OC45MzVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA4
OjA4LjkzNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDg6MTguOTM2XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowODoyOC45MzZdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDE0OjA4OjM4LjkzNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6
MDg6NDguOTM2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowODo1OC45MzZdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA5OjA4LjkzNl0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MDk6MTguOTM3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
NDowOToyOC45MzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA5OjM4LjkzN10g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDk6NDguOTM3XSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxNDowOTo1OC45MzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDE0OjEwOjA4LjkzOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MTA6MTguOTM4
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDoxMDoyOC45MzhdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDE0OjEwOjM4LjkzOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MTA6NDguOTM4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDoxMDo1OC45
MzldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjExOjA4LjkzOV0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MTE6MTguOTM5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxNDoxMToyOC45MzldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjExOjM4
LjkzOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MTE6NDguOTQwXSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxNDoxMTo1OC45NDBdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDE0OjEyOjA4Ljk0MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MTI6
MTguOTQwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDoxMjoyOC45NDBdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjEyOjM4Ljk0MV0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6MTI6NDguOTQxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDox
Mjo1OC45NDFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjEzOjA4Ljk0MV0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MTM6MTguOTQxXSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxNDoxMzoyOC45NDFdIC0tTUFSSy0tCg==
------------0191A1230144FE1ED
Content-Type: text/plain;
 name="xl-dmesg-not-defined.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg-not-defined.txt"

fCB8IHwgfF9fICAgX3wgX19fKSB8IHxffCB8X198IHwgfCAoX18gCiAvXy9cX1xfX198X3wg
fF98ICAgIHxffChfKV9fX18oXylfX18vICAgfF98ICBcX19ffAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKKFhFTikgWGVuIHZlcnNpb24g
NC41LjAtcmMgKHJvb3RAZHluZG5zLm9yZykgKGdjYy00LjcucmVhbCAoRGViaWFuIDQuNy4y
LTUpIDQuNy4yKSBkZWJ1Zz15IFR1ZSBOb3YgMTggMTI6MTk6MTAgQ0VUIDIwMTQKKFhFTikg
TGF0ZXN0IENoYW5nZVNldDogTW9uIE5vdiAxNyAxNTowNzowMyAyMDE0ICswMTAwIGdpdDow
NTQwYjg1LWRpcnR5CihYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OS0yNytkZWI3dTIKKFhF
TikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0xNTM2TSxtYXg6MTUzNk0gbG9nbHZsPWFsbCBs
b2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcz1kYXRlbXMgdmdhPWdmeC0xMjgw
eDEwMjR4MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBjb20xPTM4NDAwLDhuMSBjb25zb2xlPXZn
YSxjb20xIGl2cnNfaW9hcGljWzZdPTAwOjE0LjAgaW9tbXU9b24sdmVyYm9zZSxkZWJ1Zyxh
bWQtaW9tbXUtZGVidWcgZGVidWcgbGFwaWM9ZGVidWcgYXBpY192ZXJib3NpdHk9ZGVidWcg
YXBpYz1kZWJ1ZwooWEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoKKFhFTikgIFZHQSBpcyBncmFw
aGljcyBtb2RlIDEyODB4MTAyNCwgMzIgYnBwCihYRU4pICBWQkUvRERDIG1ldGhvZHM6IFYy
OyBFRElEIHRyYW5zZmVyIHRpbWU6IDEgc2Vjb25kcwooWEVOKSBEaXNjIGluZm9ybWF0aW9u
OgooWEVOKSAgRm91bmQgMiBNQlIgc2lnbmF0dXJlcwooWEVOKSAgRm91bmQgMiBFREQgaW5m
b3JtYXRpb24gc3RydWN0dXJlcwooWEVOKSBYZW4tZTgyMCBSQU0gbWFwOgooWEVOKSAgMDAw
MDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOTk0MDAgKHVzYWJsZSkKKFhFTikgIDAwMDAw
MDAwMDAwOTk0MDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAw
MDAwMDAwZTQwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAw
MDAwMDAxMDAwMDAgLSAwMDAwMDAwMDlmZjkwMDAwICh1c2FibGUpCihYRU4pICAwMDAwMDAw
MDlmZjkwMDAwIC0gMDAwMDAwMDA5ZmY5ZTAwMCAoQUNQSSBkYXRhKQooWEVOKSAgMDAwMDAw
MDA5ZmY5ZTAwMCAtIDAwMDAwMDAwOWZmZTAwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAw
MDA5ZmZlMDAwMCAtIDAwMDAwMDAwYTAwMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAw
MDBmZmUwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAw
MDEwMDAwMDAwMCAtIDAwMDAwMDA1NjAwMDAwMDAgKHVzYWJsZSkKKFhFTikgQUNQSTogUlNE
UCAwMDBGQjEwMCwgMDAxNCAocjAgQUNQSUFNKQooWEVOKSBBQ1BJOiBSU0RUIDlGRjkwMDAw
LCAwMDQ4IChyMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykKKFhF
TikgQUNQSTogRkFDUCA5RkY5MDIwMCwgMDA4NCAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAw
OTEzIE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6IERTRFQgOUZGOTA1RTAsIDk0MjcgKHIx
ICBBNzY0MCBBNzY0MDEwMCAgICAgIDEwMCBJTlRMIDIwMDUxMTE3KQooWEVOKSBBQ1BJOiBG
QUNTIDlGRjlFMDAwLCAwMDQwCihYRU4pIEFDUEk6IEFQSUMgOUZGOTAzOTAsIDAwODggKHIx
IDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBN
Q0ZHIDlGRjkwNDIwLCAwMDNDIChyMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAg
ICAgICA5NykKKFhFTikgQUNQSTogU0xJQyA5RkY5MDQ2MCwgMDE3NiAocjEgTVNJICAgIE9F
TVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6IE9FTUIgOUZGOUUw
NDAsIDAwNzIgKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQoo
WEVOKSBBQ1BJOiBTUkFUIDlGRjlBNUUwLCAwMTA4IChyMyBBTUQgICAgRkFNX0ZfMTAgICAg
ICAgIDIgQU1EICAgICAgICAgMSkKKFhFTikgQUNQSTogSFBFVCA5RkY5QTZGMCwgMDAzOCAo
cjEgNzY0ME1TIE9FTUhQRVQgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6
IElWUlMgOUZGOUE3MzAsIDAxMTAgKHIxICBBTUQgICAgIFJEODkwUyAgIDIwMjAzMSBBTUQg
ICAgICAgICAwKQooWEVOKSBBQ1BJOiBTU0RUIDlGRjlBODQwLCAwREE0IChyMSBBIE0gSSAg
UE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkKKFhFTikgU3lzdGVtIFJBTTogMjA0
NzlNQiAoMjA5NzA2NjBrQikKKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUg
MAooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDEgLT4gTm9kZSAwCihYRU4pIFNSQVQ6IFBY
TSAwIC0+IEFQSUMgMiAtPiBOb2RlIDAKKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAzIC0+
IE5vZGUgMAooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDQgLT4gTm9kZSAwCihYRU4pIFNS
QVQ6IFBYTSAwIC0+IEFQSUMgNSAtPiBOb2RlIDAKKFhFTikgU1JBVDogTm9kZSAwIFBYTSAw
IDAtYTAwMDAKKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMC1hMDAwMDAwMAooWEVO
KSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwMDAwLTU2MDAwMDAwMAooWEVOKSBOVU1BOiBB
bGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDU1ZDBhZjAwMCAtIDU1ZDBiNTAwMAooWEVOKSBO
VU1BOiBVc2luZyA4IGZvciB0aGUgaGFzaCBzaGlmdC4KKFhFTikgRG9tYWluIGhlYXAgaW5p
dGlhbGlzZWQKKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGQwMDAwMDAwLCBtYXBw
ZWQgdG8gMHhmZmZmODJjMDAwMjAxMDAwLCB1c2luZyA2MTQ0aywgdG90YWwgMTYzODRrCihY
RU4pIHZlc2FmYjogbW9kZSBpcyAxMjgweDEwMjR4MzIsIGxpbmVsZW5ndGg9NTEyMCwgZm9u
dCA4eDE2CihYRU4pIHZlc2FmYjogVHJ1ZWNvbG9yOiBzaXplPTA6ODo4OjgsIHNoaWZ0PTA6
MTY6ODowCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAwMDBmZjc4MAooWEVOKSBETUkg
cHJlc2VudC4KKFhFTikgQVBJQyBib290IHN0YXRlIGlzICd4YXBpYycKKFhFTikgVXNpbmcg
QVBJQyBkcml2ZXIgZGVmYXVsdAooWEVOKSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgw
OAooWEVOKSBBQ1BJOiBTTEVFUCBJTkZPOiBwbTF4X2NudFsxOjgwNCwxOjBdLCBwbTF4X2V2
dFsxOjgwMCwxOjBdCihYRU4pIEFDUEk6ICAgICAgICAgICAgIHdha2V1cF92ZWNbOWZmOWUw
MGNdLCB2ZWNfc2l6ZVsyMF0KKFhFTikgQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVl
MDAwMDAKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0g
ZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMwIDA6MTAgQVBJQyB2ZXJzaW9uIDE2CihYRU4p
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpCihY
RU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQooWEVOKSBQcm9jZXNz
b3IgIzIgMDoxMCBBUElDIHZlcnNpb24gMTYKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMzIDA6MTAg
QVBJQyB2ZXJzaW9uIDE2CihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGlj
X2lkWzB4MDRdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lv
biAxNgooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBl
bmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzUgMDoxMCBBUElDIHZlcnNpb24gMTYKKFhFTikg
QUNQSTogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBd
KQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgNiwgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZl
YzAwMDAwLCBHU0kgMC0yMwooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3Nb
MHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRdKQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywg
dmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUKKFhFTikgQUNQSTog
SU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKKFhF
TikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93
IGxldmVsKQooWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEFDUEk6
IElSUTIgdXNlZCBieSBvdmVycmlkZS4KKFhFTikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJy
aWRlLgooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJ
Q3MKKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MzAwIGJhc2U6IDB4ZmVkMDAwMDAKKFhFTikg
RVJTVCB0YWJsZSB3YXMgbm90IGZvdW5kCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBT
TVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BV
cyAoMCBob3RwbHVnIENQVXMpCihYRU4pIG1hcHBlZCBBUElDIHRvIGZmZmY4MmNmZmZkZmIw
MDAgKGZlZTAwMDAwKQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmNmZmZkZmEwMDAg
KGZlYzAwMDAwKQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmNmZmZkZjkwMDAgKGZl
YzIwMDAwKQooWEVOKSBJUlEgbGltaXRzOiA1NiBHU0ksIDExMTIgTVNJL01TSS1YCihYRU4p
IFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKKFhFTikg
RGV0ZWN0ZWQgMzIwMC4yMDUgTUh6IHByb2Nlc3Nvci4KKFhFTikgSW5pdGluZyBtZW1vcnkg
c2hhcmluZy4KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFi
bGVkCihYRU4pIGFsdCB0YWJsZSBmZmZmODJkMDgwMmRhZjMwIC0+IGZmZmY4MmQwODAyZGJm
NTAKKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdt
ZW50IDAwMDAgYnVzZXMgMDAgLSBmZgooWEVOKSBQQ0k6IE5vdCB1c2luZyBNQ0ZHIGZvciBz
ZWdtZW50IDAwMDAgYnVzIDAwLWZmCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNhcGFiaWxp
dHkgYmxvY2sgYXQgMHg1NAooWEVOKSBBTUQtVmk6IEFDUEkgVGFibGU6CihYRU4pIEFNRC1W
aTogIFNpZ25hdHVyZSBJVlJTCihYRU4pIEFNRC1WaTogIExlbmd0aCAweDExMAooWEVOKSBB
TUQtVmk6ICBSZXZpc2lvbiAweDEKKFhFTikgQU1ELVZpOiAgQ2hlY2tTdW0gMHhlYgooWEVO
KSBBTUQtVmk6ICBPRU1fSWQgQU1EICAKKFhFTikgQU1ELVZpOiAgT0VNX1RhYmxlX0lkIFJE
ODkwUwooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIwMzEKKFhFTikgQU1ELVZp
OiAgQ3JlYXRvcl9JZCBBTUQgCihYRU4pIEFNRC1WaTogIENyZWF0b3JfUmV2aXNpb24gMAoo
WEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6IHR5cGUgMHgxMCBmbGFncyAweDNlIGxlbiAweGUw
IGlkIDB4MgooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAw
IGZsYWdzIDAKKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAwIC0+IDB4MgooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDEwIGZsYWdzIDAKKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHhmMDAgZmxhZ3Mg
MAooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4ZjAwIC0+IDB4ZjAxCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MTggZmxhZ3MgMAooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweGUwMCBmbGFncyAw
CihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHhlMDAgLT4gMHhlMDEKKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgyOCBmbGFncyAwCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4ZDAwIGZsYWdzIDAK
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgzMCBmbGFn
cyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YzAw
IGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHg0OCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgy
IGlkIDB4YjAwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlw
ZSAweDIgaWQgMHg1MCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMHgyIGlkIDB4YTAwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeTogdHlwZSAweDIgaWQgMHg1OCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6IHR5cGUgMHgzIGlkIDB4OTAwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweDkwMCAtPiAweDkwMQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4MiBpZCAweDYwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeTogdHlwZSAweDIgaWQgMHg1MDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDYwOCBmbGFncyAwCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4ODAwIGZsYWdzIDAKKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg2MTAgZmxhZ3MgMAooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDcwMCBmbGFncyAw
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NjggZmxh
Z3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDQw
MCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlk
IDB4ODggZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MyBpZCAweDkwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+
IDB4OTIKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHg5
OCBmbGFncyAwCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg5OCAtPiAweDlhCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTAgZmxhZ3Mg
MHhkNwooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGEy
IGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHhhMyBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgy
IGlkIDB4YTQgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4NDMgaWQgMHgzMDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4
MzAwIC0+IDB4M2ZmIGFsaWFzIDB4YTQKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eTogdHlwZSAweDIgaWQgMHhhNSBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHgyIGlkIDB4YTggZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGE5IGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgxMDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweGIwIGZsYWdzIDAKKFhFTikgQU1E
LVZpOiAgRGV2X0lkIFJhbmdlOiAweGIwIC0+IDB4YjIKKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeTogdHlwZSAwIGlkIDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5OiB0eXBlIDB4NDggaWQgMCBmbGFncyAweGQ3CihYRU4pIEFNRC1WaTogSVZI
RCBTcGVjaWFsOiAwMDAwOjAwOjE0LjAgdmFyaWV0eSAweDIgaGFuZGxlIDAKKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDQ4IGlkIDAgZmxhZ3MgMAooWEVOKSBB
TUQtVmk6IElWSEQgU3BlY2lhbDogMDAwMDowMDowMC4xIHZhcmlldHkgMHgxIGhhbmRsZSAw
eDcKKFhFTikgQU1ELVZpOiBEaXNhYmxlZCBIQVAgbWVtb3J5IG1hcCBzaGFyaW5nIHdpdGgg
SU9NTVUKKFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuCihYRU4pIEkvTyB2aXJ0dWFs
aXNhdGlvbiBlbmFibGVkCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZAooWEVOKSBJbnRl
cnJ1cHQgcmVtYXBwaW5nIGVuYWJsZWQKKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAx
MAooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwCihYRU4pIEdldHRpbmcgSUQ6IDAK
KFhFTikgR2V0dGluZyBMVlQwOiA3MDAKKFhFTikgR2V0dGluZyBMVlQxOiA0MDAKKFhFTikg
ZW5hYmxlZCBFeHRJTlQgb24gQ1BVIzAKKFhFTikgRVNSIHZhbHVlIGJlZm9yZSBlbmFibGlu
ZyB2ZWN0b3I6IDB4NCAgYWZ0ZXI6IDAKKFhFTikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzCihY
RU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZAooWEVOKSBpbml0IElPX0FQSUMgSVJRcwoo
WEVOKSAgSU8tQVBJQyAoYXBpY2lkLXBpbikgNi0wLCA2LTE2LCA2LTE3LCA2LTE4LCA2LTE5
LCA2LTIwLCA2LTIxLCA2LTIyLCA2LTIzLCA3LTAsIDctMSwgNy0yLCA3LTMsIDctNCwgNy01
LCA3LTYsIDctNywgNy04LCA3LTksIDctMTAsIDctMTEsIDctMTIsIDctMTMsIDctMTQsIDct
MTUsIDctMTYsIDctMTcsIDctMTgsIDctMTksIDctMjAsIDctMjEsIDctMjIsIDctMjMsIDct
MjQsIDctMjUsIDctMjYsIDctMjcsIDctMjgsIDctMjksIDctMzAsIDctMzEgbm90IGNvbm5l
Y3RlZC4KKFhFTikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9
LTEgcGluMj0tMQooWEVOKSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1LgooWEVOKSBu
dW1iZXIgb2YgSU8tQVBJQyAjNiByZWdpc3RlcnM6IDI0LgooWEVOKSBudW1iZXIgb2YgSU8t
QVBJQyAjNyByZWdpc3RlcnM6IDMyLgooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4KKFhFTikgSU8gQVBJQyAjNi4uLi4uLgooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMDogMDYwMDAwMDAKKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMg
aWQ6IDA2CihYRU4pIC4uLi4uLi4gICAgOiBEZWxpdmVyeSBUeXBlOiAwCihYRU4pIC4uLi4u
Li4gICAgOiBMVFMgICAgICAgICAgOiAwCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3
ODAyMQooWEVOKSAuLi4uLi4uICAgICA6IG1heCByZWRpcmVjdGlvbiBlbnRyaWVzOiAwMDE3
CihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxCihYRU4pIC4uLi4uLi4g
ICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAyOiAw
NjAwMDAwMAooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNgooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMzogMDcwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAgOiBCb290IERUICAg
IDogMAooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToKKFhFTikgIE5SIExvZyBQ
aHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICAKKFhFTikgIDAw
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDAx
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzAKKFhFTikgIDAy
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjAKKFhFTikgIDAz
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzgKKFhFTikgIDA0
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjEKKFhFTikgIDA1
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDAKKFhFTikgIDA2
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDgKKFhFTikgIDA3
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTAKKFhFTikgIDA4
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTgKKFhFTikgIDA5
IDAwMSAwMSAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDAgICAgMDAKKFhFTikgIDBh
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNjgKKFhFTikgIDBi
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzAKKFhFTikgIDBj
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzgKKFhFTikgIDBk
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgODgKKFhFTikgIDBl
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgOTAKKFhFTikgIDBm
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgOTgKKFhFTikgIDEw
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDEx
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDEy
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDEz
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDE0
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDE1
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDE2
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDE3
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgSU8g
QVBJQyAjNy4uLi4uLgooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDogMDcwMDAwMDAKKFhFTikg
Li4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA3CihYRU4pIC4uLi4uLi4gICAgOiBE
ZWxpdmVyeSBUeXBlOiAwCihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwCihY
RU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDFGODAyMQooWEVOKSAuLi4uLi4uICAgICA6IG1h
eCByZWRpcmVjdGlvbiBlbnRyaWVzOiAwMDFGCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGlt
cGxlbWVudGVkOiAxCihYRU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIx
CihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAyOiAwMDAwMDAwMAooWEVOKSAuLi4uLi4uICAgICA6
IGFyYml0cmF0aW9uOiAwMAooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToKKFhF
TikgIE5SIExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDog
ICAKKFhFTikgIDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDAxIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDAyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDAzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBlIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgVXNpbmcgdmVjdG9yLWJhc2VkIGluZGV4aW5nCihYRU4pIElSUSB0byBwaW4g
bWFwcGluZ3M6CihYRU4pIElSUTI0MCAtPiAwOjIKKFhFTikgSVJRNDggLT4gMDoxCihYRU4p
IElSUTU2IC0+IDA6MwooWEVOKSBJUlEyNDEgLT4gMDo0CihYRU4pIElSUTY0IC0+IDA6NQoo
WEVOKSBJUlE3MiAtPiAwOjYKKFhFTikgSVJRODAgLT4gMDo3CihYRU4pIElSUTg4IC0+IDA6
OAooWEVOKSBJUlE5NiAtPiAwOjkKKFhFTikgSVJRMTA0IC0+IDA6MTAKKFhFTikgSVJRMTEy
IC0+IDA6MTEKKFhFTikgSVJRMTIwIC0+IDA6MTIKKFhFTikgSVJRMTM2IC0+IDA6MTMKKFhF
TikgSVJRMTQ0IC0+IDA6MTQKKFhFTikgSVJRMTUyIC0+IDA6MTUKKFhFTikgLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIGRvbmUuCihYRU4pIFVzaW5nIGxvY2FsIEFQ
SUMgdGltZXIgaW50ZXJydXB0cy4KKFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4K
KFhFTikgLi4uLi4gQ1BVIGNsb2NrIHNwZWVkIGlzIDMyMDAuMTg1NiBNSHouCihYRU4pIC4u
Li4uIGhvc3QgYnVzIGNsb2NrIHNwZWVkIGlzIDIwMC4wMTE1IE1Iei4KKFhFTikgLi4uLi4g
YnVzX3NjYWxlID0gMHhjY2Q3CihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUyLjk4Nl0gUGxh
dGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6
NTMuMDA3XSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4KKFhFTikgWzIwMTQt
MTEtMTggMTE6MjY6NTMuMDEzXSBIVk06IEFTSURzIGVuYWJsZWQuCihYRU4pIFsyMDE0LTEx
LTE4IDExOjI2OjUzLjAxOV0gU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6CihY
RU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjAyNV0gIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChO
UFQpCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjAzMV0gIC0gTGFzdCBCcmFuY2ggUmVj
b3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjAz
N10gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVAooWEVOKSBbMjAxNC0xMS0xOCAxMToy
Njo1My4wNDNdICAtIFBhdXNlLUludGVyY2VwdCBGaWx0ZXIKKFhFTikgWzIwMTQtMTEtMTgg
MTE6MjY6NTMuMDQ5XSBIVk06IFNWTSBlbmFibGVkCihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjUzLjA1Nl0gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQK
KFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuMDYyXSBIVk06IEhBUCBwYWdlIHNpemVzOiA0
a0IsIDJNQiwgMUdCCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjA2OV0gSFZNOiBQVkgg
bW9kZSBub3Qgc3VwcG9ydGVkIG9uIHRoaXMgcGxhdGZvcm0KKFhFTikgWzIwMTQtMTEtMTgg
MTE6MjY6NTMuMDk1XSBtYXNrZWQgRXh0SU5UIG9uIENQVSMxCihYRU4pIFsyMDE0LTExLTE4
IDExOjI2OjUzLjEyMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjMgooWEVOKSBbMjAxNC0xMS0x
OCAxMToyNjo1My4xNDhdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzMKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTMuMTc1XSBtYXNrZWQgRXh0SU5UIG9uIENQVSM0CihYRU4pIFsyMDE0LTEx
LTE4IDExOjI2OjUzLjIwMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjNQooWEVOKSBbMjAxNC0x
MS0xOCAxMToyNjo1My4yMDhdIEJyb3VnaHQgdXAgNiBDUFVzCihYRU4pIFsyMDE0LTExLTE4
IDExOjI2OjUzLjIxOF0gQU1ELVZpOiBGYWlsZWQgdG8gc2V0dXAgSFBFVCBNU0kgcmVtYXBw
aW5nLiBXcm9uZyBIUEVULgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My4yMjVdIEFNRC1W
aTogRmFpbGVkIHRvIHNldHVwIEhQRVQgTVNJIHJlbWFwcGluZy4gV3JvbmcgSFBFVC4KKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTMuMjMxXSBBTUQtVmk6IEZhaWxlZCB0byBzZXR1cCBI
UEVUIE1TSSByZW1hcHBpbmcuIFdyb25nIEhQRVQuCihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjUzLjIzOF0gSFBFVDogMyB0aW1lcnMgdXNhYmxlIGZvciBicm9hZGNhc3QgKDMgdG90YWwp
CihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjI2NV0gQUNQSSBzbGVlcCBtb2RlczogUzMK
KFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuMjcyXSBNQ0E6IFVzZSBodyB0aHJlc2hvbGRp
bmcgdG8gYWRqdXN0IHBvbGxpbmcgZnJlcXVlbmN5CihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjUzLjI3OF0gbWNoZWNrX3BvbGw6IE1hY2hpbmUgY2hlY2sgcG9sbGluZyB0aW1lciBzdGFy
dGVkLgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My4yODZdIFhlbm9wcm9maWxlOiBGYWls
ZWQgdG8gc2V0dXAgSUJTIExWVCBvZmZzZXQsIElCU0NUTCA9IDB4ZmZmZmZmZmYKKFhFTikg
WzIwMTQtMTEtMTggMTE6MjY6NTMuMjkzXSAqKiogTE9BRElORyBET01BSU4gMCAqKioKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTMuNDYxXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBw
YWRkcj0weDEwMDAwMDAgbWVtc3o9MHgxMDY0MDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjUzLjQ2OV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgyMjAwMDAwIG1lbXN6
PTB4MTA2MDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjQ3Nl0gZWxmX3BhcnNlX2Jp
bmFyeTogcGhkcjogcGFkZHI9MHgyMzA2MDAwIG1lbXN6PTB4MTQyODAKKFhFTikgWzIwMTQt
MTEtMTggMTE6MjY6NTMuNDgzXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDIz
MWIwMDAgbWVtc3o9MHgxMTQwMDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjQ5MV0g
ZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5OiAweDEwMDAwMDAgLT4gMHgzNDViMDAwCihYRU4p
IFsyMDE0LTExLTE4IDExOjI2OjUzLjQ5OF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9P
UyA9ICJsaW51eCIKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuNTA2XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42IgooWEVOKSBbMjAxNC0xMS0xOCAxMToy
Njo1My41MTRdIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVOX1ZFUlNJT04gPSAieGVuLTMuMCIK
KFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuNTIxXSBlbGZfeGVuX3BhcnNlX25vdGU6IFZJ
UlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1
My41MjldIGVsZl94ZW5fcGFyc2Vfbm90ZTogRU5UUlkgPSAweGZmZmZmZmZmODIzMWIxZjAK
KFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuNTM3XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZ
UEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZmZjgxMDAxMDAwCihYRU4pIFsyMDE0LTExLTE4IDEx
OjI2OjUzLjU0NV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIhd3JpdGFibGVf
cGFnZV90YWJsZXN8cGFlX3BnZGlyX2Fib3ZlXzRnYnx3cml0YWJsZV9kZXNjcmlwdG9yX3Rh
Ymxlc3xhdXRvX3RyYW5zbGF0ZWRfcGh5c21hcHxzdXBlcnZpc29yX21vZGVfa2VybmVsIgoo
WEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My41NjFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VQ
UE9SVEVEX0ZFQVRVUkVTID0gMHg5MGQKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuNTY5
XSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTMuNTc4XSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURFUiA9ICJnZW5lcmlj
IgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My41ODZdIGVsZl94ZW5fcGFyc2Vfbm90ZTog
dW5rbm93biB4ZW4gZWxmIG5vdGUgKDB4ZCkKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMu
NTk1XSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxCihYRU4pIFsy
MDE0LTExLTE4IDExOjI2OjUzLjYwNF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBNT0RfU1RBUlRf
UEZOID0gMHgxCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjYxM10gZWxmX3hlbl9wYXJz
ZV9ub3RlOiBIVl9TVEFSVF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDAKKFhFTikgWzIwMTQt
MTEtMTggMTE6MjY6NTMuNjIyXSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9
IDB4MAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My42MzFdIGVsZl94ZW5fYWRkcl9jYWxj
X2NoZWNrOiBhZGRyZXNzZXM6CihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjY0MF0gICAg
IHZpcnRfYmFzZSAgICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTMuNjUwXSAgICAgZWxmX3BhZGRyX29mZnNldCA9IDB4MAooWEVOKSBbMjAx
NC0xMS0xOCAxMToyNjo1My42NTldICAgICB2aXJ0X29mZnNldCAgICAgID0gMHhmZmZmZmZm
ZjgwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjY2OV0gICAgIHZpcnRfa3N0
YXJ0ICAgICAgPSAweGZmZmZmZmZmODEwMDAwMDAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6
NTMuNjc5XSAgICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZmZmZmZmY4MzQ1YjAwMAooWEVO
KSBbMjAxNC0xMS0xOCAxMToyNjo1My42ODldICAgICB2aXJ0X2VudHJ5ICAgICAgID0gMHhm
ZmZmZmZmZjgyMzFiMWYwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjY5OF0gICAgIHAy
bV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYKKFhFTikgWzIwMTQtMTEtMTgg
MTE6MjY6NTMuNzA4XSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMgooWEVO
KSBbMjAxNC0xMS0xOCAxMToyNjo1My43MTldICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUs
IGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+IDB4MzQ1YjAwMAooWEVOKSBbMjAxNC0xMS0xOCAx
MToyNjo1My43MjldIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgWzIwMTQt
MTEtMTggMTE6MjY6NTMuNzM5XSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDU0ODAwMDAwMC0+
MDAwMDAwMDU0YzAwMDAwMCAoMzcyOTM4IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkKKFhFTikg
WzIwMTQtMTEtMTggMTE6MjY6NTMuNzUxXSAgSW5pdC4gcmFtZGlzazogMDAwMDAwMDU1ZjBj
YTAwMC0+MDAwMDAwMDU1ZmZmZmEwMAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My43NjFd
IFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1
My43NzJdICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgzNDVi
MDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjc4M10gIEluaXQuIHJhbWRpc2s6IDAw
MDAwMDAwMDAwMDAwMDAtPjAwMDAwMDAwMDAwMDAwMDAKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTMuNzkzXSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4MzQ1YjAwMC0+ZmZmZmZmZmY4
Mzc1YjAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My44MDRdICBTdGFydCBpbmZvOiAg
ICBmZmZmZmZmZjgzNzViMDAwLT5mZmZmZmZmZjgzNzViNGI0CihYRU4pIFsyMDE0LTExLTE4
IDExOjI2OjUzLjgxNV0gIFBhZ2UgdGFibGVzOiAgIGZmZmZmZmZmODM3NWMwMDAtPmZmZmZm
ZmZmODM3N2IwMDAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuODI2XSAgQm9vdCBzdGFj
azogICAgZmZmZmZmZmY4Mzc3YjAwMC0+ZmZmZmZmZmY4Mzc3YzAwMAooWEVOKSBbMjAxNC0x
MS0xOCAxMToyNjo1My44MzddICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5m
ZmZmZmZmZjgzODAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjg0OF0gIEVOVFJZ
IEFERFJFU1M6IGZmZmZmZmZmODIzMWIxZjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMu
ODYwXSBEb20wIGhhcyBtYXhpbXVtIDYgVkNQVXMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6
NTMuODcxXSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMCBhdCAweGZmZmZmZmZmODEwMDAwMDAg
LT4gMHhmZmZmZmZmZjgyMDY0MDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjg4OV0g
ZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgyMjAwMDAwIC0+IDB4ZmZm
ZmZmZmY4MjMwNjAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My45MDBdIGVsZl9sb2Fk
X2JpbmFyeTogcGhkciAyIGF0IDB4ZmZmZmZmZmY4MjMwNjAwMCAtPiAweGZmZmZmZmZmODIz
MWEyODAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuOTEyXSBlbGZfbG9hZF9iaW5hcnk6
IHBoZHIgMyBhdCAweGZmZmZmZmZmODIzMWIwMDAgLT4gMHhmZmZmZmZmZjgyNDIzMDAwCihY
RU4pIFsyMDE0LTExLTE4IDExOjI2OjU0LjMyN10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTUuMDc0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAwLCB0eXBlID0gMHg2LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4wODVdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MiwgdHlwZSA9IDB4
Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuMDk3XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDEwLCB0eXBlID0gMHgyLCByb290IHRhYmxlID0g
MHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0x
MS0xOCAxMToyNjo1NS4xMTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MTgsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU1LjEy
Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyOCwgdHlw
ZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuMTM1XSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDMwLCB0eXBlID0gMHgyLCByb290IHRh
YmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBb
MjAxNC0xMS0xOCAxMToyNjo1NS4xNDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4NDgsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjU1LjE2MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1
MCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuMTczXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDU4LCB0eXBlID0gMHgyLCBy
b290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwoo
WEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4xODddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4NjAsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0
ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4
IDExOjI2OjU1LjIwMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHg2OCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuMjEzXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDg4LCB0eXBlID0g
MHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4yMjddIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4OTAsIHR5cGUgPSAweDcsIHJvb3QgdGFibGUg
PSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0
LTExLTE4IDExOjI2OjU1LjI0MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg5MiwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUu
MjU1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDk4LCB0
eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4yNjldIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4OWEsIHR5cGUgPSAweDcsIHJvb3Qg
dGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4p
IFsyMDE0LTExLTE4IDExOjI2OjU1LjI4M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHhhMCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRi
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTUuMjk4XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eGEyLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4zMTJdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTMsIHR5cGUgPSAweDcs
IHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
CihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU1LjMyN10gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhNCwgdHlwZSA9IDB4NSwgcm9vdCB0YWJsZSA9IDB4
NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTUuMzQyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweGE1LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4zNTdd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTgsIHR5cGUg
PSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU1LjM3Ml0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJs
ZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTUuMzg3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweGIyLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1
NS40MDNdIEFNRC1WaTogU2tpcHBpbmcgaG9zdCBicmlkZ2UgMDAwMDowMDoxOC4wCihYRU4p
IFsyMDE0LTExLTE4IDExOjI2OjU1LjQxOF0gQU1ELVZpOiBTa2lwcGluZyBob3N0IGJyaWRn
ZSAwMDAwOjAwOjE4LjEKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNDMzXSBBTUQtVmk6
IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTguMgooWEVOKSBbMjAxNC0xMS0xOCAx
MToyNjo1NS40NDhdIEFNRC1WaTogU2tpcHBpbmcgaG9zdCBicmlkZ2UgMDAwMDowMDoxOC4z
CihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU1LjQ2M10gQU1ELVZpOiBTa2lwcGluZyBob3N0
IGJyaWRnZSAwMDAwOjAwOjE4LjQKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNDc4XSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDQwMCwgdHlwZSA9
IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNDkzXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDUwMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJs
ZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTUuNTA5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDYwOCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6
NTUuNTI1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDYx
MCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNTQxXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDcwMCwgdHlwZSA9IDB4MSwg
cm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMK
KFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNTU3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDgwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4
NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTUuNTczXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDkwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNTkw
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwMSwgdHlw
ZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNjA2XSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEwMCwgdHlwZSA9IDB4MSwgcm9vdCB0
YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikg
WzIwMTQtMTEtMTggMTE6MjY6NTUuNjIzXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweGIwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRi
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTUuNjQwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eGMwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNjU3XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGQwMCwgdHlwZSA9IDB4
MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNjc1XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGUwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9
IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQt
MTEtMTggMTE6MjY6NTUuNjkyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweGUwMSwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUu
NzEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGYwMCwg
dHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNzI4XSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGYwMSwgdHlwZSA9IDB4MSwgcm9v
dCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNzUxXSBTY3J1YmJpbmcgRnJlZSBSQU0gb24gMSBu
b2RlcyB1c2luZyA2IENQVXMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuODYxXSAuLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuCihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjU4Ljk1NF0gSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQw
MDAgcGFnZXMuCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU4Ljk3MV0gU3RkLiBMb2dsZXZl
bDogQWxsCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU4Ljk4OV0gR3Vlc3QgTG9nbGV2ZWw6
IEFsbAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1OS4wMDZdIFhlbiBpcyByZWxpbnF1aXNo
aW5nIFZHQSBjb25zb2xlLgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1OS4xMDhdICoqKiBT
ZXJpYWwgaW5wdXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0
Y2ggaW5wdXQgdG8gWGVuKQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1OS4xMDldIEZyZWVk
IDI4NGtCIGluaXQgbWVtb3J5LgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1OS4yNjFdIElP
QVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg2MCAtPiBJUlEgOSBN
b2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU5LjI4M10gdHJhcHMu
YzoyNTc5OmQwdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjE4XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAwLjAKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAw
LjIKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjE5XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjAyLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIwXSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjAzLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIwXSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjA1LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIwXSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjA2LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTku
NjIxXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjA5LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTkuNjIxXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBhLjAKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTkuNjIxXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBiLjAKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjIyXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBjLjAKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIyXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBk
LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIyXSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjExLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIzXSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjEyLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIzXSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjEyLjIKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIzXSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjEzLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTku
NjI0XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjEzLjIKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTkuNjI0XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjAKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTkuNjI0XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjIKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjI1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjMKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0
LjQKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI1XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjE0LjUKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI2XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjE1LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI2XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjE2LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI2XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjE2LjIKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTku
NjI2XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTkuNjI3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjEKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTkuNjI3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjIKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjI3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjMKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4
LjQKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI4XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjBmOjAwLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI4XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjBmOjAwLjEKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjM2XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjBlOjAwLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjM2XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjBlOjAwLjEKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTku
NjQzXSBQQ0kgYWRkIGRldmljZSAwMDAwOjBkOjAwLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTkuNjUwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjBjOjAwLjAKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTkuNjU2XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBiOjAwLjAKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjYzXSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjAKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjcwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjA5OjAw
LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjcwXSBQQ0kgYWRkIGRldmljZSAwMDAw
OjA5OjAwLjEKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjc2XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjA1OjAwLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjgzXSBQQ0kgYWRk
IGRldmljZSAwMDAwOjA2OjAxLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjgzXSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjA2OjAyLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTku
Njg0XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA4OjAwLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTkuNjkwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjA3OjAwLjAKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTkuNjkwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjAKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjk3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAzOjA2LjAKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjk3XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNi0xMyAtPiAweDg4IC0+IElSUSAxMyBNb2RlOjAgQWN0aXZlOjApCihYRU4p
IFsyMDE0LTExLTE4IDExOjI2OjU5LjcxMl0gUENJOiBVc2luZyBNQ0ZHIGZvciBzZWdtZW50
IDAwMDAgYnVzIDAwLWZmCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU5LjcwOV0gSU9BUElD
WzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOCAtPiAweDU4IC0+IElSUSA4IE1vZGU6
MCBBY3RpdmU6MCkKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNzIzXSBJT0FQSUNbMF06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOCAtPiAweGI4IC0+IElSUSAxOCBNb2RlOjEg
QWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU5Ljc5OF0gSU9BUElDWzBdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTcgLT4gMHhjMCAtPiBJUlEgMTcgTW9kZToxIEFj
dGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNzowMC4wMjldIElPQVBJQ1sxXTogU2V0
IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI5IC0+IDB4YzggLT4gSVJRIDUzIE1vZGU6MSBBY3Rp
dmU6MSkKKFhFTikgWzIwMTQtMTEtMTggMTE6Mjc6MDAuMDI5XSBJT0FQSUNbMV06IFNldCBQ
Q0kgcm91dGluZyBlbnRyeSAoNy0yNCAtPiAweGQwIC0+IElSUSA0OCBNb2RlOjEgQWN0aXZl
OjEpCihYRU4pIFsyMDE0LTExLTE4IDExOjI3OjAwLjAyOV0gSU9BUElDWzFdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDctMzAgLT4gMHhkOCAtPiBJUlEgNTQgTW9kZToxIEFjdGl2ZTox
KQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNzowMC4wMjldIElPQVBJQ1sxXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg3LTEyIC0+IDB4MjEgLT4gSVJRIDM2IE1vZGU6MSBBY3RpdmU6MSkK
KFhFTikgWzIwMTQtMTEtMTggMTE6Mjc6MDAuMDI5XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy0xMyAtPiAweDI5IC0+IElSUSAzNyBNb2RlOjEgQWN0aXZlOjEpCihY
RU4pIFsyMDE0LTExLTE4IDExOjI3OjAwLjAyOV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDctMTYgLT4gMHgzMSAtPiBJUlEgNDAgTW9kZToxIEFjdGl2ZToxKQooWEVO
KSBbMjAxNC0xMS0xOCAxMToyNzowMC4wOTZdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5n
IGVudHJ5ICg3LTI4IC0+IDB4MzkgLT4gSVJRIDUyIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikg
WzIwMTQtMTEtMTggMTE6Mjc6MDAuMDk4XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNi0xNiAtPiAweDg5IC0+IElSUSAxNiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsy
MDE0LTExLTE4IDExOjI3OjAwLjA5OV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDctMTQgLT4gMHhhOSAtPiBJUlEgMzggTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAx
NC0xMS0xOCAxMToyNzowMC4xNDhdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg2LTIyIC0+IDB4YjkgLT4gSVJRIDIyIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQt
MTEtMTggMTE6Mjc6MDIuMjE5XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAo
Ny05IC0+IDB4YzEgLT4gSVJRIDMzIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEt
MTggMTE6Mjc6MDIuMjQ1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy04
IC0+IDB4YzkgLT4gSVJRIDMyIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTgg
MTE6Mjc6MDIuMjcyXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAt
PiAweGQxIC0+IElSUSA0NyBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDEx
OjI3OjA0LjM1MV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNSAtPiAw
eGQ5IC0+IElSUSAyOSBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDExOjI3
OjA0LjM5NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNCAtPiAweDIy
IC0+IElSUSAyOCBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDExOjI3OjA0
LjUzMF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTkgLT4gMHgyYSAt
PiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNzowNC41
MzhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjI3OjA0LjY5M10gSU9BUElDWzFd
OiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjIgLT4gMHg3MiAtPiBJUlEgNDYgTW9kZTox
IEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNzowNC43MjldIElPQVBJQ1sxXTog
U2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI3IC0+IDB4OGEgLT4gSVJRIDUxIE1vZGU6MSBB
Y3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTggMTE6Mjc6MDUuMzI2XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xIC0+IDB4OWEgLT4gSVJRIDI1IE1vZGU6MSBBY3Rp
dmU6MSkKKFhFTikgWzIwMTQtMTEtMTggMTE6Mjc6MTMuNzA5XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMToyNzoyMy43MDldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEx
OjI3OjMzLjcxMF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mjc6NDMuNzEwXSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNzo1My43MTBdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDExOjI4OjAzLjcxMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTE6Mjg6MTMuNzExXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMToyODoyMy43MTFd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjI4OjMzLjcxMV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTE6Mjg6NDMuNzEyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMToyODo1My43MTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjI5OjAzLjcx
Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mjk6MTMuNzEyXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMToyOToyMy43MTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDExOjI5OjMzLjcxM10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mjk6NDMu
NzEzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMToyOTo1My43MTNdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDExOjMwOjAzLjcxM10gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTE6MzA6MTMuNzE0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozMDoy
My43MTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjMwOjMzLjcxNF0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzA6NDMuNzE0XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMTozMDo1My43MTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjMx
OjAzLjcxNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzE6MTMuNzE0XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozMToyMy43MTRdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDExOjMxOjMzLjcxNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6
MzE6NDMuNzE1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozMTo1My43MTVdIC0t
TUFSSy0tCihkMSkgWzIwMTQtMTEtMTggMTE6MzE6NTkuODM2XSBtYXBwaW5nIGtlcm5lbCBp
bnRvIHBoeXNpY2FsIG1lbW9yeQooZDEpIFsyMDE0LTExLTE4IDExOjMxOjU5LjgzN10gYWJv
dXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzI6MDAuMDk3XSB0
cmFwcy5jOjI1Nzk6ZDF2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAw
MDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVO
KSBbMjAxNC0xMS0xOCAxMTozMjowMy43MTVdIC0tTUFSSy0tCihkMikgWzIwMTQtMTEtMTgg
MTE6MzI6MDUuOTM2XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDIp
IFsyMDE0LTExLTE4IDExOjMyOjA1LjkzNl0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhF
TikgWzIwMTQtMTEtMTggMTE6MzI6MDYuMDEyXSB0cmFwcy5jOjI1Nzk6ZDJ2MCBEb21haW4g
YXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAw
MDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooZDMpIFsyMDE0LTExLTE4IDExOjMyOjExLjc2
MV0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQzKSBbMjAxNC0xMS0x
OCAxMTozMjoxMS43NjFdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTEx
LTE4IDExOjMyOjExLjg1MV0gdHJhcHMuYzoyNTc5OmQzdjAgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAw
MDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzI6MTMuNzE2XSAtLU1BUkst
LQooZDQpIFsyMDE0LTExLTE4IDExOjMyOjE3Ljk3NF0gbWFwcGluZyBrZXJuZWwgaW50byBw
aHlzaWNhbCBtZW1vcnkKKGQ0KSBbMjAxNC0xMS0xOCAxMTozMjoxNy45NzRdIGFib3V0IHRv
IGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDExOjMyOjE4LjA1MF0gdHJhcHMu
YzoyNTc5OmQ0djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIw
MTQtMTEtMTggMTE6MzI6MjAuNzIzXSBncmFudF90YWJsZS5jOjMwNTpkMHYwIEluY3JlYXNl
ZCBtYXB0cmFjayBzaXplIHRvIDIgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE4IDExOjMyOjIz
LjcxNl0gLS1NQVJLLS0KKGQ1KSBbMjAxNC0xMS0xOCAxMTozMjoyMy43ODNdIG1hcHBpbmcg
a2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkNSkgWzIwMTQtMTEtMTggMTE6MzI6MjMu
NzgzXSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMTozMjoy
My44NTldIHRyYXBzLmM6MjU3OTpkNXYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZm
ZmYuCihkNikgWzIwMTQtMTEtMTggMTE6MzI6MjkuNjExXSBtYXBwaW5nIGtlcm5lbCBpbnRv
IHBoeXNpY2FsIG1lbW9yeQooZDYpIFsyMDE0LTExLTE4IDExOjMyOjI5LjYxMV0gYWJvdXQg
dG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzI6MjkuNzI3XSB0cmFw
cy5jOjI1Nzk6ZDZ2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQg
ZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBb
MjAxNC0xMS0xOCAxMTozMjozMy4xMzddIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVh
c2VkIG1hcHRyYWNrIHNpemUgdG8gMyBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTggMTE6MzI6
MzMuMTk4XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXpl
IHRvIDQgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE4IDExOjMyOjMzLjcxNl0gLS1NQVJLLS0K
KGQ3KSBbMjAxNC0xMS0xOCAxMTozMjozNS42MzldIG1hcHBpbmcga2VybmVsIGludG8gcGh5
c2ljYWwgbWVtb3J5CihkNykgWzIwMTQtMTEtMTggMTE6MzI6MzUuNjM5XSBhYm91dCB0byBn
ZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMTozMjozNS43MTNdIHRyYXBzLmM6
MjU3OTpkN3YwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9t
IDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihkOCkgWzIwMTQt
MTEtMTggMTE6MzI6NDEuNTE3XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9y
eQooZDgpIFsyMDE0LTExLTE4IDExOjMyOjQxLjUxN10gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQu
Li4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzI6NDEuNTkzXSB0cmFwcy5jOjI1Nzk6ZDh2MCBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAw
MDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xOCAxMToz
Mjo0My43MTZdIC0tTUFSSy0tCihkOSkgWzIwMTQtMTEtMTggMTE6MzI6NDguNDAzXSBtYXBw
aW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDkpIFsyMDE0LTExLTE4IDExOjMy
OjQ4LjQwM10gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTE6
MzI6NDguNDkyXSB0cmFwcy5jOjI1Nzk6ZDl2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAw
MDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAw
MDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xOCAxMTozMjo1My43MTddIC0tTUFSSy0tCihkMTAp
IFsyMDE0LTExLTE4IDExOjMyOjU0LjMxNF0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNh
bCBtZW1vcnkKKGQxMCkgWzIwMTQtMTEtMTggMTE6MzI6NTQuMzE0XSBhYm91dCB0byBnZXQg
c3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMTozMjo1NC4zOTldIHRyYXBzLmM6MjU3
OTpkMTB2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAw
eDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0x
MS0xOCAxMTozMjo1Ni4xNzBdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1h
cHRyYWNrIHNpemUgdG8gNSBmcmFtZXMKKGQxMSkgWzIwMTQtMTEtMTggMTE6MzM6MDAuMzgz
XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDExKSBbMjAxNC0xMS0x
OCAxMTozMzowMC4zODNdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTEx
LTE4IDExOjMzOjAwLjQ4Nl0gdHJhcHMuYzoyNTc5OmQxMXYwIERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAw
MDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE4IDExOjMzOjAzLjcxN10gLS1NQVJL
LS0KKGQxMikgWzIwMTQtMTEtMTggMTE6MzM6MDYuNDI2XSBtYXBwaW5nIGtlcm5lbCBpbnRv
IHBoeXNpY2FsIG1lbW9yeQooZDEyKSBbMjAxNC0xMS0xOCAxMTozMzowNi40MjZdIGFib3V0
IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDExOjMzOjA2LjUxOF0gdHJh
cHMuYzoyNTc5OmQxMnYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4p
IFsyMDE0LTExLTE4IDExOjMzOjEyLjYzMF0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweGE0LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTgg
MTE6MzM6MTIuNjMwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweGE0LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1MTc2ZGIwMDAsIGRvbWFpbiA9
IDEzLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MTIuNjMwXSBB
TUQtVmk6IFJlLWFzc2lnbiAwMDAwOjAzOjA2LjAgZnJvbSBkb20wIHRvIGRvbTEzCihkMTMp
IFsyMDE0LTExLTE4IDExOjMzOjEyLjYzN10gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNh
bCBtZW1vcnkKKGQxMykgWzIwMTQtMTEtMTggMTE6MzM6MTIuNjM3XSBhYm91dCB0byBnZXQg
c3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzoxMi44NjFdIHRyYXBzLmM6MjU3
OTpkMTN2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAw
eDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0x
MS0xOCAxMTozMzoxMy43MTddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjMzOjE4
LjYyOF0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0
byA2IGZyYW1lcwooZDE0KSBbMjAxNC0xMS0xOCAxMTozMzoxOC44NzddIG1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTQpIFsyMDE0LTExLTE4IDExOjMzOjE4Ljg3
N10gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MTgu
OTY3XSB0cmFwcy5jOjI1Nzk6ZDE0djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZm
Zi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MjMuNzE3XSAtLU1BUkstLQooZDE1KSBbMjAx
NC0xMS0xOCAxMTozMzoyNC45NzRdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVt
b3J5CihkMTUpIFsyMDE0LTExLTE4IDExOjMzOjI0Ljk3NF0gYWJvdXQgdG8gZ2V0IHN0YXJ0
ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MjUuMDY2XSB0cmFwcy5jOjI1Nzk6ZDE1
djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAw
MDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTgg
MTE6MzM6MzIuODk0XSBpby5jOjU1MDogZDE2OiBiaW5kOiBtX2dzaT0zNyBnX2dzaT0zNiBk
ZXY9MDAuMDAuNSBpbnR4PTAgZmZmZjgzMDUwODVmZjUyOAooWEVOKSBbMjAxNC0xMS0xOCAx
MTozMzozMy4yODhdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHg4MDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzozMy4yODhd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ODAwLCB0eXBl
ID0gMHgxLCByb290IHRhYmxlID0gMHgzZmFiMWQwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcg
bW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MzMuMjg4XSBBTUQtVmk6IFJlLWFz
c2lnbiAwMDAwOjA4OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE2CihYRU4pIFsyMDE0LTExLTE4
IDExOjMzOjMzLjcxN10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MzQuMzQx
XSBpby5jOjU1MDogZDE2OiBiaW5kOiBtX2dzaT00NyBnX2dzaT00MCBkZXY9MDAuMDAuNiBp
bnR4PTAgZmZmZjgzMDUwODVmZmQyOAooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNDZd
IEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHhhMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNDZdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTAwLCB0eXBlID0gMHgxLCByb290
IHRhYmxlID0gMHgzZmFiMWQwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcgbW9kZSA9IDMKKFhF
TikgWzIwMTQtMTEtMTggMTE6MzM6MzQuMzQ2XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBh
OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE2CihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjM1
N10gSFZNIExvYWRlcgooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNTddIERldGVjdGVk
IFhlbiB2NC41LjAtcmMKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuMzU3XSBYZW5idXMg
cmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgMQooZDE2KSBbMjAxNC0xMS0xOCAx
MTozMzozNC4zNTddIFN5c3RlbSByZXF1ZXN0ZWQgU2VhQklPUwooZDE2KSBbMjAxNC0xMS0x
OCAxMTozMzozNC4zNTddIENQVSBzcGVlZCBpcyAzMjAwIE1IegooZDE2KSBbMjAxNC0xMS0x
OCAxMTozMzozNC4zNThdIFJlbG9jYXRpbmcgZ3Vlc3QgbWVtb3J5IGZvciBsb3dtZW0gTU1J
TyBzcGFjZSBkaXNhYmxlZAooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNThdIGlycS5j
OjI3MDogRG9tMTYgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQooZDE2KSBbMjAxNC0xMS0x
OCAxMTozMzozNC4zNThdIFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1CihYRU4pIFsy
MDE0LTExLTE4IDExOjMzOjM0LjM1OF0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAxIGNo
YW5nZWQgMCAtPiAxMAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNThdIFBDSS1JU0Eg
bGluayAxIHJvdXRlZCB0byBJUlExMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNThd
IGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTEKKGQxNikgWzIw
MTQtMTEtMTggMTE6MzM6MzQuMzU4XSBQQ0ktSVNBIGxpbmsgMiByb3V0ZWQgdG8gSVJRMTEK
KFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MzQuMzU5XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBs
aW5rIDMgY2hhbmdlZCAwIC0+IDUKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuMzU5XSBQ
Q0ktSVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzoz
NC4zNzVdIHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1CihkMTYpIFsyMDE0LTExLTE4IDExOjMz
OjM0LjM4MV0gcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihkMTYpIFsyMDE0LTExLTE4IDEx
OjMzOjM0LjM4Nl0gcGNpIGRldiAwMjowIElOVEEtPklSUTExCihkMTYpIFsyMDE0LTExLTE4
IDExOjMzOjM0LjM5N10gcGNpIGRldiAwNDowIElOVEEtPklSUTUKKGQxNikgWzIwMTQtMTEt
MTggMTE6MzM6MzQuNDAzXSBwY2kgZGV2IDA1OjAgSU5UQS0+SVJRMTAKKGQxNikgWzIwMTQt
MTEtMTggMTE6MzM6MzQuNDA5XSBwY2kgZGV2IDA2OjAgSU5UQS0+SVJRMTEKKGQxNikgWzIw
MTQtMTEtMTggMTE6MzM6MzQuNDU1XSBObyBSQU0gaW4gaGlnaCBtZW1vcnk7IHNldHRpbmcg
aGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDAKKGQxNikgWzIwMTQtMTEtMTgg
MTE6MzM6MzQuNDU1XSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAyMDAwMDAwOiAwZjAw
MDAwMDgKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNDU3XSBwY2kgZGV2IDAyOjAgYmFy
IDE0IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6
MzQuNDYwXSBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMjAwMDAwOiAwZjMwMDAwMDQK
KFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNDYwXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYg
Z2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQu
NDY2XSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUgMDAwMDQwMDAwOiAwZjMyMDAwMDAKKGQx
NikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNDY4XSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUg
MDAwMDIwMDAwOiAwZjMyNDAwMDAKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNDY4XSBw
Y2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEwMDAwOiAwZjMyNjAwMDAKKGQxNikgWzIw
MTQtMTEtMTggMTE6MzM6MzQuNDY5XSBwY2kgZGV2IDA1OjAgYmFyIDEwIHNpemUgMDAwMDAy
MDAwOiAwZjMyNzAwMDQKKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNDY5XSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihkMTYpIFsyMDE0LTEx
LTE4IDExOjMzOjM0LjQ3Nl0gcGNpIGRldiAwMzowIGJhciAxNCBzaXplIDAwMDAwMTAwMDog
MGYzMjcyMDAwCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjQ3Nl0gcGNpIGRldiAwMjow
IGJhciAxMCBzaXplIDAwMDAwMDEwMDogMDAwMDBjMDAxCihkMTYpIFsyMDE0LTExLTE4IDEx
OjMzOjM0LjQ3OV0gcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDA0MDogMDAwMDBj
MTAxCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjQ4Ml0gcGNpIGRldiAwMToyIGJhciAy
MCBzaXplIDAwMDAwMDAyMDogMDAwMDBjMTQxCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0
LjQ4NF0gcGNpIGRldiAwMToxIGJhciAyMCBzaXplIDAwMDAwMDAxMDogMDAwMDBjMTYxCihk
MTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjQ4N10gTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlz
YXRpb246CihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjUwOV0gIC0gQ1BVMCAuLi4gNDgt
Yml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUu
CihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjUzMV0gIC0gQ1BVMSAuLi4gNDgtYml0IHBo
eXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYp
IFsyMDE0LTExLTE4IDExOjMzOjM0LjU1N10gIC0gQ1BVMiAuLi4gNDgtYml0IHBoeXMgLi4u
IGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0
LTExLTE4IDExOjMzOjM0LjU3OF0gIC0gQ1BVMyAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVk
IE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0LTExLTE4
IDExOjMzOjM0LjU3OF0gVGVzdGluZyBIVk0gZW52aXJvbm1lbnQ6CihkMTYpIFsyMDE0LTEx
LTE4IDExOjMzOjM0LjU4N10gIC0gUkVQIElOU0IgYWNyb3NzIHBhZ2UgYm91bmRhcmllcyAu
Li4gcGFzc2VkCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjU5MV0gIC0gR1MgYmFzZSBN
U1JzIGFuZCBTV0FQR1MgLi4uIHBhc3NlZAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC41
OTFdIFBhc3NlZCAyIG9mIDIgdGVzdHMKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTkx
XSBXcml0aW5nIFNNQklPUyB0YWJsZXMgLi4uCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0
LjU5Ml0gTG9hZGluZyBTZWFCSU9TIC4uLgooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC41
OTJdIENyZWF0aW5nIE1QIHRhYmxlcyAuLi4KKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQu
NTkyXSBMb2FkaW5nIEFDUEkgLi4uCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjU5M10g
dm04NiBUU1MgYXQgZmMwMGEyMDAKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk0XSBC
SU9TIG1hcDoKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk0XSAgMTAwMDAtMTAwZDM6
IFNjcmF0Y2ggc3BhY2UKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk0XSAgYzAwMDAt
ZmZmZmY6IE1haW4gQklPUwooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC41OTRdIEU4MjAg
dGFibGU6CihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjU5NF0gIFswMF06IDAwMDAwMDAw
OjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJBTQooZDE2KSBbMjAxNC0xMS0xOCAx
MTozMzozNC41OTRdICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGMw
MDAwCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjU5NF0gIFswMV06IDAwMDAwMDAwOjAw
MGMwMDAwIC0gMDAwMDAwMDA6MDAxMDAwMDA6IFJFU0VSVkVECihkMTYpIFsyMDE0LTExLTE4
IDExOjMzOjM0LjU5NF0gIFswMl06IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAwMDA6M2Y4
MDAwMDA6IFJBTQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC41OTRdICBIT0xFOiAwMDAw
MDAwMDozZjgwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwCihkMTYpIFsyMDE0LTExLTE4IDEx
OjMzOjM0LjU5NF0gIFswM106IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAwMDAwMDE6MDAwMDAw
MDA6IFJFU0VSVkVECihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjU5NV0gSW52b2tpbmcg
U2VhQklPUyAuLi4KKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk3XSBTZWFCSU9TICh2
ZXJzaW9uIHJlbC0xLjcuNS0wLWdlNTE0ODhjLTIwMTQxMTE4XzEyMTE0NS1zZXJ2ZWVyc3Rl
cnRqZSkKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk3XSAKKGQxNikgWzIwMTQtMTEt
MTggMTE6MzM6MzQuNTk3XSBGb3VuZCBYZW4gaHlwZXJ2aXNvciBzaWduYXR1cmUgYXQgNDAw
MDAwMDAKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk4XSBSdW5uaW5nIG9uIFFFTVUg
KGk0NDBmeCkKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk4XSB4ZW46IGNvcHkgZTgy
MC4uLgooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC41OThdIFJlbG9jYXRpbmcgaW5pdCBm
cm9tIDB4MDAwZGY2MjkgdG8gMHgzZjdhZTYwMCAoc2l6ZSA3MTk5NSkKKGQxNikgWzIwMTQt
MTEtMTggMTE6MzM6MzQuNjAwXSBDUFUgTWh6PTMyMDEKKGQxNikgWzIwMTQtMTEtMTggMTE6
MzM6MzQuNjA2XSBGb3VuZCAxMCBQQ0kgZGV2aWNlcyAobWF4IFBDSSBidXMgaXMgMDApCihk
MTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjYwNl0gQWxsb2NhdGVkIFhlbiBoeXBlcmNhbGwg
cGFnZSBhdCAzZjdmZjAwMAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC42MDZdIERldGVj
dGVkIFhlbiB2NC41LjAtcmMKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNjA2XSB4ZW46
IGNvcHkgQklPUyB0YWJsZXMuLi4KKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNjA2XSBD
b3B5aW5nIFNNQklPUyBlbnRyeSBwb2ludCBmcm9tIDB4MDAwMTAwMTAgdG8gMHgwMDBmMGY1
MAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC42MDZdIENvcHlpbmcgTVBUQUJMRSBmcm9t
IDB4ZmMwMDExYTAvZmMwMDExYjAgdG8gMHgwMDBmMGUzMAooZDE2KSBbMjAxNC0xMS0xOCAx
MTozMzozNC42MDZdIENvcHlpbmcgUElSIGZyb20gMHgwMDAxMDAzMCB0byAweDAwMGYwZGIw
CihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjYwNl0gQ29weWluZyBBQ1BJIFJTRFAgZnJv
bSAweDAwMDEwMGIwIHRvIDB4MDAwZjBkODAKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQu
NjA2XSBVc2luZyBwbXRpbWVyLCBpb3BvcnQgMHhiMDA4CihkMTYpIFsyMDE0LTExLTE4IDEx
OjMzOjM0LjYwNl0gU2NhbiBmb3IgVkdBIG9wdGlvbiByb20KKGQxNikgWzIwMTQtMTEtMTgg
MTE6MzM6MzQuNjI0XSBSdW5uaW5nIG9wdGlvbiByb20gYXQgYzAwMDowMDAzCihYRU4pIFsy
MDE0LTExLTE4IDExOjMzOjM0LjYzM10gc3RkdmdhLmM6MTQ3OmQxNnYwIGVudGVyaW5nIHN0
ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC42NjJd
IHBtbSBjYWxsIGFyZzE9MAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC42NjRdIFR1cm5p
bmcgb24gdmdhIHRleHQgbW9kZSBjb25zb2xlCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0
Ljc4MV0gU2VhQklPUyAodmVyc2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTExOF8x
MjExNDUtc2VydmVlcnN0ZXJ0amUpCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0Ljc5NV0g
TWFjaGluZSBVVUlEIDY0NDg1ZmZjLWY0NTctNGJlMi05ZjI1LTdiMmFhNTg0ZDYxYQooZDE2
KSBbMjAxNC0xMS0xOCAxMTozMzozNC43OTVdIFhIQ0kgaW5pdCBvbiBkZXYgMDA6MDUuMDog
cmVncyBAIDB4ZjMyNzAwMDAsIDQgcG9ydHMsIDMyIHNsb3RzLCAzMiBieXRlIGNvbnRleHQK
KGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNzk1XSBzCihkMTYpIFsyMDE0LTExLTE4IDEx
OjMzOjM0Ljc5NV0gWEhDSSAgICBleHRjYXAgMHgxIEAgZjMyNzA1MDAKKGQxNikgWzIwMTQt
MTEtMTggMTE6MzM6MzQuNzk1XSBYSENJICAgIHByb3RvY29sIFVTQiAgMy4wMCwgMiBwb3J0
cyAob2Zmc2V0IDEpLCBkZWYgMAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC43OTVdIFhI
Q0kgICAgcHJvdG9jb2wgVVNCICAyLjAwLCAyIHBvcnRzIChvZmZzZXQgMyksIGRlZiAwCihk
MTYpIFsyMDE0LTExLTE4IDExOjMzOjM0Ljc5Nl0gVUhDSSBpbml0IG9uIGRldiAwMDowMS4y
IChpbz1jMTQwKQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC43OTddIEZvdW5kIDAgbHB0
IHBvcnRzCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0Ljc5OF0gRm91bmQgMSBzZXJpYWwg
cG9ydHMKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNzk5XSBBVEEgY29udHJvbGxlciAx
IGF0IDFmMC8zZjQvMCAoaXJxIDE0IGRldiA5KQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzoz
NC44MDBdIEFUQSBjb250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUgZGV2IDkpCihk
MTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjgwM10gYXRhMC0wOiBRRU1VIEhBUkRESVNLIEFU
QS03IEhhcmQtRGlzayAoMTAyNDAgTWlCeXRlcykKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6
MzQuODAzXSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDEsMS9kcml2
ZUAwL2Rpc2tAMAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC44MDVdIGF0YTAtMTogUUVN
VSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDMwMCBHaUJ5dGVzKQooZDE2KSBbMjAxNC0x
MS0xOCAxMTozMzozNC44MDVdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4
LypAMSwxL2RyaXZlQDAvZGlza0AxCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjkwM10g
UFMyIGtleWJvYXJkIGluaXRpYWxpemVkCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0Ljk0
OF0gWEhDSSBwb3J0ICM0OiAweDAwMjAwYTAzLCBwb3dlcmVkLCBlbmFibGVkLCBwbHMgMCwg
c3BlZWQgMiBbTG93XQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC45NzhdIFhIQ0kgbm8g
ZGV2aWNlcyBmb3VuZAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC45ODldIEFsbCB0aHJl
YWRzIGNvbXBsZXRlLgooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC45ODldIFNjYW4gZm9y
IG9wdGlvbiByb21zCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM1LjAxM10gUnVubmluZyBv
cHRpb24gcm9tIGF0IGM5ODA6MDAwMwooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wMjFd
IHBtbSBjYWxsIGFyZzE9MQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wMjFdIHBtbSBj
YWxsIGFyZzE9MAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wMjNdIHBtbSBjYWxsIGFy
ZzE9MQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wMjNdIHBtbSBjYWxsIGFyZzE9MAoo
ZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wNDNdIFNlYXJjaGluZyBib290b3JkZXIgZm9y
OiAvcGNpQGkwY2Y4LypANAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wNDNdIAooZDE2
KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wNTBdIFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lgoo
ZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wNTFdIAooZDE2KSBbMjAxNC0xMS0xOCAxMToz
MzozNy42MjVdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTYpIFsyMDE0LTEx
LTE4IDExOjMzOjM3LjYyNV0gZHJpdmUgMHgwMDBmMGQzMDogUENIUz0xNjM4My8xNi82MyB0
cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwCihkMTYpIFsyMDE0
LTExLTE4IDExOjMzOjM3LjYyNV0gZHJpdmUgMHgwMDBmMGQwMDogUENIUz0xNjM4My8xNi82
MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTYyOTE0NTYwMAooZDE2KSBb
MjAxNC0xMS0xOCAxMTozMzozNy42MjVdIAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNy42
MjVdIFNwYWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkMDAK
KGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzcuNjI1XSBSZXR1cm5lZCAyNTM5NTIgYnl0ZXMg
b2YgWm9uZUhpZ2gKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzcuNjI1XSBlODIwIG1hcCBo
YXMgNiBpdGVtczoKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzcuNjI1XSAgIDA6IDAwMDAw
MDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0KKGQxNikgWzIwMTQtMTEt
MTggMTE6MzM6MzcuNjI1XSAgIDE6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEw
MDAwID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNy42MjVdICAgMjog
MDAwMDAwMDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgPSAyIFJFU0VSVkVECihkMTYp
IFsyMDE0LTExLTE4IDExOjMzOjM3LjYyNl0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAw
MDAwMDAzZjdmZTAwMCA9IDEgUkFNCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM3LjYyNl0g
ICA0OiAwMDAwMDAwMDNmN2ZlMDAwIC0gMDAwMDAwMDAzZjgwMDAwMCA9IDIgUkVTRVJWRUQK
KGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzcuNjI2XSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAg
LSAwMDAwMDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xOCAxMToz
MzozNy42MjZdIGVudGVyIGhhbmRsZV8xOToKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6Mzcu
NjI2XSAgIE5VTEwKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzcuNjMzXSBCb290aW5nIGZy
b20gSGFyZCBEaXNrLi4uCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM3LjYzNl0gQm9vdGlu
ZyBmcm9tIDAwMDA6N2MwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzo0MC4wNzddIGdyYW50
X3RhYmxlLmM6MzA1OmQwdjQgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gNyBmcmFtZXMK
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNTg0XSBIVk0gTG9hZGVyCihkMTcpIFsyMDE0
LTExLTE4IDExOjMzOjQxLjU4NF0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE3KSBbMjAx
NC0xMS0xOCAxMTozMzo0MS41ODRdIFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQg
Y2hhbm5lbCAxCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjU4NV0gU3lzdGVtIHJlcXVl
c3RlZCBTZWFCSU9TCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjU4NV0gQ1BVIHNwZWVk
IGlzIDMyMDAgTUh6CihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjU4NV0gUmVsb2NhdGlu
ZyBndWVzdCBtZW1vcnkgZm9yIGxvd21lbSBNTUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsy
MDE0LTExLTE4IDExOjMzOjQxLjU4NV0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAwIGNo
YW5nZWQgMCAtPiA1CihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjU4NV0gUENJLUlTQSBs
aW5rIDAgcm91dGVkIHRvIElSUTUKKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6NDEuNTg1XSBp
cnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCihkMTcpIFsyMDE0
LTExLTE4IDExOjMzOjQxLjU4NV0gUENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihY
RU4pIFsyMDE0LTExLTE4IDExOjMzOjQxLjU4NV0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGlu
ayAyIGNoYW5nZWQgMCAtPiAxMQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS41ODVdIFBD
SS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzo0
MS41ODZdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE3
KSBbMjAxNC0xMS0xOCAxMTozMzo0MS41ODZdIFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJ
UlE1CihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjYwMl0gcGNpIGRldiAwMTozIElOVEEt
PklSUTEwCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjYwN10gcGNpIGRldiAwMjowIElO
VEEtPklSUTExCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjYxN10gcGNpIGRldiAwNDow
IElOVEEtPklSUTUKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjY0XSBObyBSQU0gaW4g
aGlnaCBtZW1vcnk7IHNldHRpbmcgaGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAw
MDAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjY1XSBwY2kgZGV2IDAzOjAgYmFyIDEw
IHNpemUgMDAyMDAwMDAwOiAwZjAwMDAwMDgKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEu
NjY2XSBwY2kgZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQx
NykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjY4XSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUg
MDAwMDQwMDAwOiAwZjMwMDAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjcwXSBw
Y2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAwMDIwMDAwOiAwZjMwNDAwMDAKKGQxNykgWzIw
MTQtMTEtMTggMTE6MzM6NDEuNjcwXSBwY2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEw
MDAwOiAwZjMwNjAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjcyXSBwY2kgZGV2
IDAzOjAgYmFyIDE0IHNpemUgMDAwMDAxMDAwOiAwZjMwNzAwMDAKKGQxNykgWzIwMTQtMTEt
MTggMTE6MzM6NDEuNjcyXSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAw
MDAwMGMwMDEKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjc0XSBwY2kgZGV2IDA0OjAg
YmFyIDE0IHNpemUgMDAwMDAwMDQwOiAwMDAwMGMxMDEKKGQxNykgWzIwMTQtMTEtMTggMTE6
MzM6NDEuNjc2XSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMx
NDEKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjc4XSBNdWx0aXByb2Nlc3NvciBpbml0
aWFsaXNhdGlvbjoKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjk4XSAgLSBDUFUwIC4u
LiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4g
ZG9uZS4KKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzE4XSAgLSBDUFUxIC4uLiA0OC1i
aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4K
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzM3XSAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5
cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykg
WzIwMTQtMTEtMTggMTE6MzM6NDEuNzU3XSAgLSBDUFUzIC4uLiA0OC1iaXQgcGh5cyAuLi4g
Zml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQt
MTEtMTggMTE6MzM6NDEuNzU3XSBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoKKGQxNykgWzIw
MTQtMTEtMTggMTE6MzM6NDEuNzY3XSAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFy
aWVzIC4uLiBwYXNzZWQKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzcyXSAgLSBHUyBi
YXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCihkMTcpIFsyMDE0LTExLTE4IDExOjMz
OjQxLjc3Ml0gUGFzc2VkIDIgb2YgMiB0ZXN0cwooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0
MS43NzJdIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KKGQxNykgWzIwMTQtMTEtMTggMTE6
MzM6NDEuNzczXSBMb2FkaW5nIFNlYUJJT1MgLi4uCihkMTcpIFsyMDE0LTExLTE4IDExOjMz
OjQxLjc3M10gQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgooZDE3KSBbMjAxNC0xMS0xOCAxMToz
Mzo0MS43NzNdIExvYWRpbmcgQUNQSSAuLi4KKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEu
Nzc1XSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43
NzVdIEJJT1MgbWFwOgooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzVdICAxMDAwMC0x
MDBkMzogU2NyYXRjaCBzcGFjZQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzVdICBj
MDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjc3NV0g
RTgyMCB0YWJsZToKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzc1XSAgWzAwXTogMDAw
MDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkFNCihkMTcpIFsyMDE0LTEx
LTE4IDExOjMzOjQxLjc3NV0gIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6
MDAwYzAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzc1XSAgWzAxXTogMDAwMDAw
MDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQKKGQxNykgWzIwMTQt
MTEtMTggMTE6MzM6NDEuNzc2XSAgWzAyXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAw
MDozZjgwMDAwMDogUkFNCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjc3Nl0gIEhPTEU6
IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAwMDAKKGQxNykgWzIwMTQtMTEt
MTggMTE6MzM6NDEuNzc2XSAgWzAzXTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTow
MDAwMDAwMDogUkVTRVJWRUQKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzc2XSBJbnZv
a2luZyBTZWFCSU9TIC4uLgooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzldIFNlYUJJ
T1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMThfMTIxMTQ1LXNlcnZl
ZXJzdGVydGplKQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzldIAooZDE3KSBbMjAx
NC0xMS0xOCAxMTozMzo0MS43NzldIEZvdW5kIFhlbiBoeXBlcnZpc29yIHNpZ25hdHVyZSBh
dCA0MDAwMDAwMAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzldIFJ1bm5pbmcgb24g
UUVNVSAoaTQ0MGZ4KQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzldIHhlbjogY29w
eSBlODIwLi4uCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjc3OV0gUmVsb2NhdGluZyBp
bml0IGZyb20gMHgwMDBkZjYyOSB0byAweDNmN2FlNjAwIChzaXplIDcxOTk1KQooZDE3KSBb
MjAxNC0xMS0xOCAxMTozMzo0MS43ODJdIENQVSBNaHo9MzIwMgooZDE3KSBbMjAxNC0xMS0x
OCAxMTozMzo0MS43ODddIEZvdW5kIDcgUENJIGRldmljZXMgKG1heCBQQ0kgYnVzIGlzIDAw
KQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43ODddIEFsbG9jYXRlZCBYZW4gaHlwZXJj
YWxsIHBhZ2UgYXQgM2Y3ZmYwMDAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzg3XSBE
ZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjc4N10g
eGVuOiBjb3B5IEJJT1MgdGFibGVzLi4uCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjc4
N10gQ29weWluZyBTTUJJT1MgZW50cnkgcG9pbnQgZnJvbSAweDAwMDEwMDEwIHRvIDB4MDAw
ZjBmNTAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzg3XSBDb3B5aW5nIE1QVEFCTEUg
ZnJvbSAweGZjMDAxMWEwL2ZjMDAxMWIwIHRvIDB4MDAwZjBlMzAKKGQxNykgWzIwMTQtMTEt
MTggMTE6MzM6NDEuNzg3XSBDb3B5aW5nIFBJUiBmcm9tIDB4MDAwMTAwMzAgdG8gMHgwMDBm
MGRiMAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43ODddIENvcHlpbmcgQUNQSSBSU0RQ
IGZyb20gMHgwMDAxMDBiMCB0byAweDAwMGYwZDgwCihkMTcpIFsyMDE0LTExLTE4IDExOjMz
OjQxLjc4N10gVXNpbmcgcG10aW1lciwgaW9wb3J0IDB4YjAwOAooZDE3KSBbMjAxNC0xMS0x
OCAxMTozMzo0MS43ODddIFNjYW4gZm9yIFZHQSBvcHRpb24gcm9tCihkMTcpIFsyMDE0LTEx
LTE4IDExOjMzOjQxLjgwMl0gUnVubmluZyBvcHRpb24gcm9tIGF0IGMwMDA6MDAwMwooWEVO
KSBbMjAxNC0xMS0xOCAxMTozMzo0MS44MTJdIHN0ZHZnYS5jOjE0NzpkMTd2MCBlbnRlcmlu
ZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEu
ODI5XSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuODMxXSBU
dXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUgY29uc29sZQooZDE3KSBbMjAxNC0xMS0xOCAxMToz
Mzo0MS45NDZdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDEx
MThfMTIxMTQ1LXNlcnZlZXJzdGVydGplKQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS45
NjBdIE1hY2hpbmUgVVVJRCA0NzQ3ZjMwNi1jNjBkLTQ0OGUtYWEzYS0zM2M3YmQ5MTNiNzMK
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuOTYxXSBBbGwgdGhyZWFkcyBjb21wbGV0ZS4K
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuOTYyXSBGb3VuZCAwIGxwdCBwb3J0cwooZDE3
KSBbMjAxNC0xMS0xOCAxMTozMzo0MS45NjJdIEZvdW5kIDAgc2VyaWFsIHBvcnRzCihkMTcp
IFsyMDE0LTExLTE4IDExOjMzOjQxLjk2Ml0gQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0
LzAgKGlycSAxNCBkZXYgOSkKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuOTYzXSBBVEEg
Y29udHJvbGxlciAyIGF0IDE3MC8zNzQvMCAoaXJxIDE1IGRldiA5KQooZDE3KSBbMjAxNC0x
MS0xOCAxMTozMzo0MS45NjddIGF0YTAtMDogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURp
c2sgKDEwMjQwIE1pQnl0ZXMpCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjk2N10gU2Vh
cmNoaW5nIGJvb3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDAK
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDY2XSBQUzIga2V5Ym9hcmQgaW5pdGlhbGl6
ZWQKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDY2XSBBbGwgdGhyZWFkcyBjb21wbGV0
ZS4KKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDY2XSBTY2FuIGZvciBvcHRpb24gcm9t
cwooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0Mi4wODhdIFJ1bm5pbmcgb3B0aW9uIHJvbSBh
dCBjOTgwOjAwMDMKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDk0XSBwbW0gY2FsbCBh
cmcxPTEKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDk0XSBwbW0gY2FsbCBhcmcxPTAK
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDk2XSBwbW0gY2FsbCBhcmcxPTEKKGQxNykg
WzIwMTQtMTEtMTggMTE6MzM6NDIuMDk2XSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIwMTQt
MTEtMTggMTE6MzM6NDIuMTEzXSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNm
OC8qQDQKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMTEzXSAKKGQxNykgWzIwMTQtMTEt
MTggMTE6MzM6NDIuMTIwXSBQcmVzcyBGMTIgZm9yIGJvb3QgbWVudS4KKGQxNykgWzIwMTQt
MTEtMTggMTE6MzM6NDIuMTIwXSAKKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6NDMuNzE4XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzo0NC40NzBdIHN0ZHZnYS5jOjE1MTpk
MTZ2MCBsZWF2aW5nIHN0ZHZnYQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NTVdIFNl
YXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQ0
LjY1Nl0gZHJpdmUgMHgwMDBmMGQzMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1s
YmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwCihkMTcpIFsyMDE0LTExLTE4IDExOjMz
OjQ0LjY1Nl0gU3BhY2UgYXZhaWxhYmxlIGZvciBVTUI6IGNhODAwLWVmMDAwLCBmMDAwMC1m
MGQzMAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NTZdIFJldHVybmVkIDI1ODA0OCBi
eXRlcyBvZiBab25lSGlnaAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NTZdIGU4MjAg
bWFwIGhhcyA2IGl0ZW1zOgooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NTZdICAgMDog
MDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWZjMDAgPSAxIFJBTQooZDE3KSBbMjAx
NC0xMS0xOCAxMTozMzo0NC42NTZdICAgMTogMDAwMDAwMDAwMDA5ZmMwMCAtIDAwMDAwMDAw
MDAwYTAwMDAgPSAyIFJFU0VSVkVECihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQ0LjY1Nl0g
ICAyOiAwMDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCA9IDIgUkVTRVJWRUQK
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDQuNjU2XSAgIDM6IDAwMDAwMDAwMDAxMDAwMDAg
LSAwMDAwMDAwMDNmN2ZmMDAwID0gMSBSQU0KKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDQu
NjU2XSAgIDQ6IDAwMDAwMDAwM2Y3ZmYwMDAgLSAwMDAwMDAwMDNmODAwMDAwID0gMiBSRVNF
UlZFRAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NTZdICAgNTogMDAwMDAwMDBmYzAw
MDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJFU0VSVkVECihkMTcpIFsyMDE0LTExLTE4
IDExOjMzOjQ0LjY1N10gZW50ZXIgaGFuZGxlXzE5OgooZDE3KSBbMjAxNC0xMS0xOCAxMToz
Mzo0NC42NTddICAgTlVMTAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NjJdIEJvb3Rp
bmcgZnJvbSBIYXJkIERpc2suLi4KKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDQuNjY0XSBC
b290aW5nIGZyb20gMDAwMDo3YzAwCihYRU4pIFsyMDE0LTExLTE4IDExOjMzOjUxLjc0MF0g
c3RkdmdhLmM6MTUxOmQxN3YwIGxlYXZpbmcgc3RkdmdhCihYRU4pIFsyMDE0LTExLTE4IDEx
OjMzOjUzLjcxOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6MDMuNzE4XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDowOS45OTVdIHN0ZHZnYS5jOjE0Nzpk
MTZ2MCBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMKKFhFTikgWzIwMTQtMTEt
MTggMTE6MzQ6MTEuNjQzXSBpcnEuYzozODA6IERvbTE2IGNhbGxiYWNrIHZpYSBjaGFuZ2Vk
IHRvIERpcmVjdCBWZWN0b3IgMHhmMwooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxMy43MThd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjE3LjUyMV0gc3RkdmdhLmM6MTQ3
OmQxN3YwIGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooWEVOKSBbMjAxNC0x
MS0xOCAxMTozNDoxNy42MDddIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAg
bWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6MTcuNjEyXSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTEx
LTE4IDExOjM0OjE3LjYxNl0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBt
Zm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy42MjBdIG1lbW9yeV9t
YXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEt
MTggMTE6MzQ6MTcuNjI1XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1m
bj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjE3LjYyOV0gbWVtb3J5X21h
cDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0x
OCAxMTozNDoxNy42MzNdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZu
PWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6MTcuNjM4XSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE4
IDExOjM0OjE3LjY0Ml0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49
ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy42NDZdIG1lbW9yeV9tYXA6
YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTgg
MTE6MzQ6MTcuNjUwXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1m
ZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjE3LjY1NV0gbWVtb3J5X21hcDph
ZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xOCAx
MTozNDoxNy42NjZdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZl
MjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy42NzJdIG1lbW9yeV9tYXA6
YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0x
OCAxMTozNDoxNy42NzhdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMDAgbWZu
PWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy42ODRdIG1lbW9yeV9t
YXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0x
MS0xOCAxMTozNDoxNy42ODldIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMDAg
bWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy42OTVdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAx
NC0xMS0xOCAxMTozNDoxNy43MDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMw
MDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy43MDZdIG1l
bW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBb
MjAxNC0xMS0xOCAxMTozNDoxNy43MTJdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49
ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy43MThd
IG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVO
KSBbMjAxNC0xMS0xOCAxMTozNDoxNy43MjNdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBn
Zm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy43
MjldIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAoo
WEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy43NjFdIGlycS5jOjI3MDogRG9tMTYgUENJIGxp
bmsgMCBjaGFuZ2VkIDUgLT4gMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy43ODFdIGly
cS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMSBjaGFuZ2VkIDEwIC0+IDAKKFhFTikgWzIwMTQt
MTEtMTggMTE6MzQ6MTcuODAwXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDIgY2hhbmdl
ZCAxMSAtPiAwCihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjE3LjgyMV0gaXJxLmM6MjcwOiBE
b20xNiBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwCihYRU4pIFsyMDE0LTExLTE4IDExOjM0
OjE5LjI2NV0gaXJxLmM6MzgwOiBEb20xNyBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJl
Y3QgVmVjdG9yIDB4ZjMKKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6MTkuNzg2XSBncmFudF90
YWJsZS5jOjEyOTk6ZDE2djMgRXhwYW5kaW5nIGRvbSAoMTYpIGdyYW50IHRhYmxlIGZyb20g
KDQpIHRvICg1KSBmcmFtZXMuCihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjIwLjM3Nl0gaXJx
LmM6MjcwOiBEb20xNyBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCihYRU4pIFsyMDE0LTEx
LTE4IDExOjM0OjIwLjM4MV0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAxIGNoYW5nZWQg
MTAgLT4gMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoyMC4zODddIGlycS5jOjI3MDogRG9t
MTcgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDAKKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6
MjAuMzkyXSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDMgY2hhbmdlZCA1IC0+IDAKKFhF
TikgWzIwMTQtMTEtMTggMTE6MzQ6MjAuODY3XSBncmFudF90YWJsZS5jOjEyOTk6ZDE3djIg
RXhwYW5kaW5nIGRvbSAoMTcpIGdyYW50IHRhYmxlIGZyb20gKDQpIHRvICg1KSBmcmFtZXMu
CihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjIzLjcxOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTE6MzQ6MzMuNzE4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoz
NC43NjRdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUg
dG8gOCBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6NDMuNzE5XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMTozNDo1My43MTldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDExOjM1OjAzLjcxOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzU6MTMu
NzE5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNToyMy43MTldIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDExOjM1OjMzLjcxOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTE6MzU6NDMuNzIwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNTo1
My43MjBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM2OjAzLjcyMF0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzY6MDYuODE5XSBncmFudF90YWJsZS5jOjEyOTk6
ZDE2djIgRXhwYW5kaW5nIGRvbSAoMTYpIGdyYW50IHRhYmxlIGZyb20gKDUpIHRvICg2KSBm
cmFtZXMuCihYRU4pIFsyMDE0LTExLTE4IDExOjM2OjEzLjcyMF0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTE6MzY6MjMuNzIxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MTozNjozMy43MjFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM2OjQzLjcyMV0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzY6NDQuNzcwXSBncmFudF90YWJsZS5j
OjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDkgZnJhbWVzCihYRU4pIFsy
MDE0LTExLTE4IDExOjM2OjUzLjcyMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6
Mzc6MDMuNzIxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNzoxMy43MjFdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM3OjIzLjcyMV0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTE6Mzc6MzMuNzIyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MTozNzo0My43MjJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM3OjUzLjcyMl0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mzc6NTcuODkxXSBncmFudF90YWJsZS5j
OjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDEwIGZyYW1lcwooWEVOKSBb
MjAxNC0xMS0xOCAxMTozODowMy43MjJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEx
OjM4OjEzLjg0NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mzg6MjMuODQ0XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozODozMy44NDRdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDExOjM4OjQzLjg0NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTE6Mzg6NTMuODQ1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozOTowMy44NDVd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM5OjEzLjg0NV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTE6Mzk6MjMuODQ1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMTozOTozMy44NDVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM5OjQzLjg0
NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mzk6NTMuODQ1XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMTo0MDowMy44NDVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDExOjQwOjEzLjg0Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDA6MjMu
ODQ2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0MDozMy44NDZdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDExOjQwOjQzLjg0Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTE6NDA6NTMuODQ2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0MTow
My44NDZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQxOjEzLjg0Nl0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDE6MjMuODQ3XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMTo0MTozMy44NDddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQx
OjQzLjg0N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDE6NTMuODQ3XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0MjowMy44NDddIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDExOjQyOjEzLjg0N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6
NDI6MjMuODQ4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0MjozMy44NDhdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQyOjQzLjg0OF0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTE6NDI6NTMuODQ4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0MzowMy44NDhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjEzLjg0OF0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTguOTkzXSAgMDogZmZmZjgzMDUw
ODVmZmQyOCBbcDpmZmZmODMwNTRlZjI3ZTg4LCBuOmZmZmY4MzA1NGVmMjdlODhdCihYRU4p
IFsyMDE0LTExLTE4IDExOjQzOjE5LjAxOF0gIDE6IGZmZmY4MzA1MDg1ZmZkMjggW3A6MDIw
MDIwMDIwMDIwMDIwMCwgbjowMTAwMTAwMTAwMTAwMTAwXQooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0MzoxOS4wNDNdIENQVTAwOiAKKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTkuMDU0XSBk
MTYgT0stc29mdGlycSAxODZtc2VjIGFnbywgc3RhdGU6MSwgMzI1NyBjb3VudCwgW3ByZXY6
ZmZmZjgyZDA4MDJlN2U4OCwgbmV4dDpmZmZmODJkMDgwMmU3ZTg4XSBmZmZmODMwNTA5NGEz
OWE4PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJUlE6ODcKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDM6MTkuMTAzXSBkMTYgT0stcmFpc2UgICAyMzZtc2VjIGFnbywg
c3RhdGU6MSwgMzI1NyBjb3VudCwgW3ByZXY6MDIwMDIwMDIwMDIwMDIwMCwgbmV4dDowMTAw
MTAwMTAwMTAwMTAwXSBmZmZmODMwNTA5NGEzOWE4PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVT
VF9NU0lfU0hJRlQgIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTkuMTUyXSBD
UFUwMTogCihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjE5LjE2M10gZDE2IE9LLXNvZnRpcnEg
MjMybXNlYyBhZ28sIHN0YXRlOjEsIDI5NzggY291bnQsIFtwcmV2OmZmZmY4MzA1NGVmNTdl
NzAsIG5leHQ6ZmZmZjgzMDU0ZWY1N2U3MF0gZmZmZjgzMDUwOTRhMzlhODxOVUxMPiBNQVBQ
RURfU0hJRlQgR1VFU1RfTVNJX1NISUZUICBQSVJROjg3CihYRU4pIFsyMDE0LTExLTE4IDEx
OjQzOjE5LjIxMl0gZDE2IE9LLXJhaXNlICAgMjgxbXNlYyBhZ28sIHN0YXRlOjEsIDI5Nzgg
Y291bnQsIFtwcmV2OjAyMDAyMDAyMDAyMDAyMDAsIG5leHQ6MDEwMDEwMDEwMDEwMDEwMF0g
ZmZmZjgzMDUwOTRhMzlhODxOVUxMPiBNQVBQRURfU0hJRlQgR1VFU1RfTVNJX1NISUZUICBQ
SVJROjg3CihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjE5LjI2Ml0gQ1BVMDI6IAooWEVOKSBb
MjAxNC0xMS0xOCAxMTo0MzoxOS4yNzJdIGQxNiBPSy1zb2Z0aXJxIDM3M21zZWMgYWdvLCBz
dGF0ZToxLCAyMzc4IGNvdW50LCBbcHJldjpmZmZmODMwNTRlZjQ3ZTcwLCBuZXh0OmZmZmY4
MzA1NGVmNDdlNzBdIGZmZmY4MzA1MDk0YTM5YTg8TlVMTD4gTUFQUEVEX1NISUZUIEdVRVNU
X01TSV9TSElGVCAgUElSUTo4NwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0MzoxOS4zMjJdIGQx
NiBPSy1yYWlzZSAgIDQyM21zZWMgYWdvLCBzdGF0ZToxLCAyMzc4IGNvdW50LCBbcHJldjow
MjAwMjAwMjAwMjAwMjAwLCBuZXh0OjAxMDAxMDAxMDAxMDAxMDBdIGZmZmY4MzA1MDk0YTM5
YTg8TlVMTD4gTUFQUEVEX1NISUZUIEdVRVNUX01TSV9TSElGVCAgUElSUTo4NwooWEVOKSBb
MjAxNC0xMS0xOCAxMTo0MzoxOS4zNzFdIENQVTAzOiAKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDM6MTkuMzgyXSBkMTYgT0stc29mdGlycSA4Njdtc2VjIGFnbywgc3RhdGU6MSwgMjc0NCBj
b3VudCwgW3ByZXY6ZmZmZjgzMDU0ZWYzN2U3MCwgbmV4dDpmZmZmODMwNTRlZjM3ZTcwXSBm
ZmZmODMwNTA5NGEzOWE4PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJ
UlE6ODcKKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTkuNDMxXSBkMTYgT0stcmFpc2UgICA5
MTZtc2VjIGFnbywgc3RhdGU6MSwgMjc0NCBjb3VudCwgW3ByZXY6MDIwMDIwMDIwMDIwMDIw
MCwgbmV4dDowMTAwMTAwMTAwMTAwMTAwXSBmZmZmODMwNTA5NGEzOWE4PE5VTEw+IE1BUFBF
RF9TSElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDM6MTkuNDgxXSBDUFUwNDogCihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjE5LjQ5MV0gZDE2
IE9LLXNvZnRpcnEgNDk3bXNlYyBhZ28sIHN0YXRlOjEsIDc2OTEwIGNvdW50LCBbcHJldjpm
ZmZmODMwNTRlZjJlM2UwLCBuZXh0OmZmZmY4MzA1NGVmMmUzZTBdIGZmZmY4MzA1MDg1ZmZk
MjhNQUNIX1BDSV9TSElGVCBNQVBQRURfU0hJRlQgR1VFU1RfUENJX1NISUZUICBQSVJROjAK
KFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTkuNTQzXSBkMTYgT0stcmFpc2UgICA0ODltc2Vj
IGFnbywgc3RhdGU6MSwgNzY5MTYgY291bnQsIFtwcmV2OmZmZmY4MzA1NGVmMmUzZTAsIG5l
eHQ6ZmZmZjgzMDU0ZWYyZTNlMF0gZmZmZjgzMDUwODVmZmQyOE1BQ0hfUENJX1NISUZUIE1B
UFBFRF9TSElGVCBHVUVTVF9QQ0lfU0hJRlQgIFBJUlE6MAooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0MzoxOS41OTRdIGQxNiBFUlItcG9pc29uIDYwMG1zZWMgYWdvLCBzdGF0ZTowLCAxIGNv
dW50LCBbcHJldjowMjAwMjAwMjAwMjAwMjAwLCBuZXh0OjAxMDAxMDAxMDAxMDAxMDBdIGZm
ZmY4MzA1MDg1ZmZkMjhNQUNIX1BDSV9TSElGVCBNQVBQRURfU0hJRlQgR1VFU1RfUENJX1NI
SUZUICBQSVJROjAKKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTkuNjQ1XSBDUFUwNTogCihY
RU4pIFsyMDE0LTExLTE4IDExOjQzOjE5LjY1NV0gZDE2IE9LLXNvZnRpcnEgODUybXNlYyBh
Z28sIHN0YXRlOjEsIDIyMDcgY291bnQsIFtwcmV2OmZmZmY4MzA1NGVmMWZlNzAsIG5leHQ6
ZmZmZjgzMDU0ZWYxZmU3MF0gZmZmZjgzMDUwOTRhMzlhODxOVUxMPiBNQVBQRURfU0hJRlQg
R1VFU1RfTVNJX1NISUZUICBQSVJROjg3CihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjE5Ljcw
NV0gZDE2IE9LLXJhaXNlICAgOTAybXNlYyBhZ28sIHN0YXRlOjEsIDIyMDcgY291bnQsIFtw
cmV2OjAyMDAyMDAyMDAyMDAyMDAsIG5leHQ6MDEwMDEwMDEwMDEwMDEwMF0gZmZmZjgzMDUw
OTRhMzlhODxOVUxMPiBNQVBQRURfU0hJRlQgR1VFU1RfTVNJX1NISUZUICBQSVJROjg3CihY
RU4pIFsyMDE0LTExLTE4IDExOjQzOjE5Ljc1M10gZG9tYWluX2NyYXNoIGNhbGxlZCBmcm9t
IGlvLmM6OTY0CihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjE5Ljc1M10gRG9tYWluIDE2IHJl
cG9ydGVkIGNyYXNoZWQgYnkgZG9tYWluIDcgb24gY3B1IzQ6CihYRU4pIFsyMDE0LTExLTE4
IDExOjQzOjIzLjg0OF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MzMuODQ5
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Mzo0My44NDldIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDExOjQzOjUzLjg0OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTE6NDQ6MDMuODQ5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0NDoxMy44
NTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQ0OjIzLjg1MF0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTE6NDQ6MzMuODUwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0NDo0My44NTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQ0OjUz
Ljg1MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDU6MDMuODUxXSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0NToxMy44NTFdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDExOjQ1OjIzLjg1MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDU6
MzMuODUxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0NTo0My44NTJdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQ1OjUzLjg1Ml0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTE6NDY6MDMuODUyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0
NjoxMy44NTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjIzLjg1M10gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6MzMuODUzXSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMTo0Njo0My44NTNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjUzLjg1NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI1XSBJ
UlEgaW5mb3JtYXRpb246CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNV0gICAgSVJR
OiAgIDAgYWZmaW5pdHk6MDEgdmVjOmYwIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0w
MDAwMDAwMCB0aW1lcl9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41
MjZdICAgIElSUTogICAxIGFmZmluaXR5OjAxIHZlYzozMCB0eXBlPUlPLUFQSUMtZWRnZSAg
ICBzdGF0dXM9MDAwMDAwMzQgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogIDEoLS0tKSwK
KFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICAgMyBhZmZpbml0eTow
MSB2ZWM6MzggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwg
dW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogICA0IGFm
ZmluaXR5OjAxIHZlYzpmMSB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDAg
bnMxNjU1MF9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAg
IElSUTogICA1IGFmZmluaXR5OjAxIHZlYzo0MCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0
dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1
LjUyNl0gICAgSVJROiAgIDYgYWZmaW5pdHk6MDEgdmVjOjQ4IHR5cGU9SU8tQVBJQy1lZGdl
ICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTgg
MTE6NDY6NTUuNTI2XSAgICBJUlE6ICAgNyBhZmZpbml0eTowMSB2ZWM6NTAgdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAx
NC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogICA4IGFmZmluaXR5OjAxIHZlYzo1OCB0
eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWlu
LWxpc3Q9MDogIDgoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJ
UlE6ICAgOSBhZmZpbml0eTozZiB2ZWM6NjAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41
MjZdICAgIElSUTogIDEwIGFmZmluaXR5OjAxIHZlYzo2OCB0eXBlPUlPLUFQSUMtZWRnZSAg
ICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjU1LjUyNl0gICAgSVJROiAgMTEgYWZmaW5pdHk6MDEgdmVjOjcwIHR5cGU9SU8tQVBJ
Qy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQt
MTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICAxMiBhZmZpbml0eTowMSB2ZWM6NzggdHlw
ZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6IDEyKC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJR
OiAgMTMgYWZmaW5pdHk6M2YgdmVjOjg4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0w
MDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2
XSAgICBJUlE6ICAxNCBhZmZpbml0eTowMSB2ZWM6OTAgdHlwZT1JTy1BUElDLWVkZ2UgICAg
c3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0
Njo1NS41MjZdICAgIElSUTogIDE1IGFmZmluaXR5OjAxIHZlYzo5OCB0eXBlPUlPLUFQSUMt
ZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTEx
LTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgMTYgYWZmaW5pdHk6MDEgdmVjOjg5IHR5cGU9
SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlz
dD0wOiAxNigtLS0pLAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTog
IDE3IGFmZmluaXR5OjAxIHZlYzpjMCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAw
MDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogMTcoLS0tKSwKKFhFTikgWzIwMTQt
MTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICAxOCBhZmZpbml0eTowMSB2ZWM6YjggdHlw
ZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6IDE4KC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJR
OiAgMTkgYWZmaW5pdHk6M2YgdmVjOjJhIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0w
MDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2
XSAgICBJUlE6ICAyMiBhZmZpbml0eToyMCB2ZWM6YjkgdHlwZT1JTy1BUElDLWxldmVsICAg
c3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDIyKC0tLSksMTM6
IDIyKC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgMjUg
YWZmaW5pdHk6M2YgdmVjOjlhIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAw
MiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJ
UlE6ICAyOCBhZmZpbml0eTozZiB2ZWM6MjIgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41
MjZdICAgIElSUTogIDI5IGFmZmluaXR5OjNmIHZlYzpkOSB0eXBlPUlPLUFQSUMtbGV2ZWwg
ICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjU1LjUyNl0gICAgSVJROiAgMzIgYWZmaW5pdHk6M2YgdmVjOmM5IHR5cGU9SU8tQVBJ
Qy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQt
MTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICAzMyBhZmZpbml0eTozZiB2ZWM6YzEgdHlw
ZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVO
KSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDM2IGFmZmluaXR5OjNmIHZl
YzoyMSB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJv
dW5kCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgMzcgYWZmaW5p
dHk6MTAgdmVjOjI5IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAxMCBpbi1m
bGlnaHQ9MCBkb21haW4tbGlzdD0xNjogMzcoLU0tKSwKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDY6NTUuNTI2XSAgICBJUlE6ICAzOCBhZmZpbml0eTozZiB2ZWM6YTkgdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDQwIGFmZmluaXR5OjNmIHZlYzozMSB0eXBl
PUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4p
IFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNDYgYWZmaW5pdHk6M2YgdmVj
OjcyIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91
bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA0NyBhZmZpbml0
eToxMCB2ZWM6ZDEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZs
aWdodD0xIGRvbWFpbi1saXN0PTE2OiA0NyhQLU0pLAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0
Njo1NS41MjZdICAgIElSUTogIDQ4IGFmZmluaXR5OjNmIHZlYzpkMCB0eXBlPUlPLUFQSUMt
bGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTEx
LTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNTEgYWZmaW5pdHk6M2YgdmVjOjhhIHR5cGU9
SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA1MiBhZmZpbml0eTozZiB2ZWM6
MzkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu
ZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDUzIGFmZmluaXR5
OjNmIHZlYzpjOCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVk
LCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNTQg
YWZmaW5pdHk6M2YgdmVjOmQ4IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAw
MiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJ
UlE6ICA1NiBhZmZpbml0eTowMSB2ZWM6MjggdHlwZT1BTUQtSU9NTVUtTVNJICAgc3RhdHVz
PTAwMDAwMDAwIGlvbW11X2ludGVycnVwdF9oYW5kbGVyKCkKKFhFTikgWzIwMTQtMTEtMTgg
MTE6NDY6NTUuNTI2XSAgICBJUlE6ICA1NyBhZmZpbml0eTowNCB2ZWM6YTAgdHlwZT1IUEVU
LU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIGhwZXRfaW50ZXJydXB0X2hhbmRsZXIoKQoo
WEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDU4IGFmZmluaXR5OjA4
IHZlYzphOCB0eXBlPUhQRVQtTVNJICAgICAgICBzdGF0dXM9MDAwMDAwMDAgaHBldF9pbnRl
cnJ1cHRfaGFuZGxlcigpCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJR
OiAgNTkgYWZmaW5pdHk6MDIgdmVjOmIwIHR5cGU9SFBFVC1NU0kgICAgICAgIHN0YXR1cz0w
MDAwMDAwMCBocGV0X2ludGVycnVwdF9oYW5kbGVyKCkKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDY6NTUuNTI2XSAgICBJUlE6ICA2MCBhZmZpbml0eTozZiB2ZWM6NDEgdHlwZT1QQ0ktTVNJ
ICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDYxIGFmZmluaXR5OjNmIHZlYzo0OSB0eXBl
PVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4p
IFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNjIgYWZmaW5pdHk6M2YgdmVj
OjUxIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91
bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA2MyBhZmZpbml0
eTozZiB2ZWM6NTkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl
ZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDY0
IGFmZmluaXR5OjNmIHZlYzo2MSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAw
MDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAg
SVJROiAgNjUgYWZmaW5pdHk6M2YgdmVjOjY5IHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1
cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUu
NTI2XSAgICBJUlE6ICA2NiBhZmZpbml0eTozZiB2ZWM6NzEgdHlwZT1QQ0ktTVNJICAgICAg
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0Njo1NS41MjZdICAgIElSUTogIDY3IGFmZmluaXR5OjNmIHZlYzo3OSB0eXBlPVBDSS1N
U0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0
LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNjggYWZmaW5pdHk6M2YgdmVjOjgxIHR5
cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhF
TikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA2OSBhZmZpbml0eTozZiB2
ZWM6OTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5i
b3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDcwIGFmZmlu
aXR5OjNmIHZlYzo5OSB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMDIgbWFw
cGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAg
NzEgYWZmaW5pdHk6M2YgdmVjOmExIHR5cGU9UENJLU1TSS8tWCAgICAgIHN0YXR1cz0wMDAw
MDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAg
ICBJUlE6ICA3MiBhZmZpbml0eTozZiB2ZWM6YjEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3Rh
dHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1
NS41MjZdICAgIElSUTogIDczIGFmZmluaXR5OjAyIHZlYzozMiB0eXBlPVBDSS1NU0kgICAg
ICAgICBzdGF0dXM9MDAwMDAwMTAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyOTEoLS0t
KSwKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA3NCBhZmZpbml0
eTowMSB2ZWM6M2EgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZs
aWdodD0wIGRvbWFpbi1saXN0PTA6MjkyKC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2
OjU1LjUyNl0gICAgSVJROiAgNzUgYWZmaW5pdHk6MDIgdmVjOjQyIHR5cGU9UENJLU1TSSAg
ICAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI5Mygt
LS0pLAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDc2IGFmZmlu
aXR5OjAxIHZlYzo0YSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMzAgaW4t
ZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyOTQoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDY6NTUuNTI2XSAgICBJUlE6ICA3NyBhZmZpbml0eTowMSB2ZWM6NTIgdHlwZT1QQ0ktTVNJ
ICAgICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk1
KC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNzggYWZm
aW5pdHk6MDEgdmVjOjVhIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAzMCBp
bi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI5NigtLS0pLAooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0Njo1NS41MjZdICAgIElSUTogIDc5IGFmZmluaXR5OjNmIHZlYzo2MiB0eXBlPVBDSS1N
U0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0
LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgODAgYWZmaW5pdHk6M2YgdmVjOjZhIHR5
cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhF
TikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA4MSBhZmZpbml0eTowMiB2
ZWM6N2EgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0w
IGRvbWFpbi1saXN0PTA6MjkwKC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUy
Nl0gICAgSVJROiAgODIgYWZmaW5pdHk6MDIgdmVjOjkyIHR5cGU9UENJLU1TSSAgICAgICAg
IHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI4OSgtLS0pLAoo
WEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDgzIGFmZmluaXR5OjAx
IHZlYzphMiB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0
PTAgZG9tYWluLWxpc3Q9MDoyODgoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUu
NTI2XSAgICBJUlE6ICA4NCBhZmZpbml0eTowOCB2ZWM6YWEgdHlwZT1QQ0ktTVNJLy1YICAg
ICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiA4NyhQLS0p
LAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDg1IGFmZmluaXR5
OjA0IHZlYzpiMiB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxp
Z2h0PTAgZG9tYWluLWxpc3Q9MTY6IDg2KC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2
OjU1LjUyNl0gICAgSVJROiAgODYgYWZmaW5pdHk6MDQgdmVjOmJhIHR5cGU9UENJLU1TSS8t
WCAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0xNjogODUo
LS0tKSwKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA4NyBhZmZp
bml0eTowNCB2ZWM6YzIgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDMwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiA4NCgtLS0pLAooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0Njo1NS41MjZdICAgIElSUTogIDg4IGFmZmluaXR5OjA0IHZlYzpjYSB0eXBlPVBDSS1N
U0kvLVggICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTY6
IDgzKC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gRGlyZWN0IHZlY3Rv
ciBpbmZvcm1hdGlvbjoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICAweDIw
IC0+IGlycV9tb3ZlX2NsZWFudXBfaW50ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDY6NTUuNTI3XSAgICAweGY5IC0+IHBtdV9hcGljX2ludGVycnVwdCgpCihYRU4pIFsyMDE0
LTExLTE4IDExOjQ2OjU1LjUyN10gICAgMHhmYSAtPiBhcGljX3RpbWVyX2ludGVycnVwdCgp
CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgMHhmYiAtPiBjYWxsX2Z1bmN0
aW9uX2ludGVycnVwdCgpCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgMHhm
YyAtPiBldmVudF9jaGVja19pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1
NS41MjddICAgIDB4ZmQgLT4gaW52YWxpZGF0ZV9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0Njo1NS41MjddICAgIDB4ZmUgLT4gZXJyb3JfaW50ZXJydXB0KCkKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAweGZmIC0+IHNwdXJpb3VzX2ludGVycnVw
dCgpCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gSU8tQVBJQyBpbnRlcnJ1cHQg
aW5mb3JtYXRpb246CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElSUSAg
MCBWZWMyNDA6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBpYyAw
eDAwLCBQaW4gIDI6IHZlYz1mMCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9s
YXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0x
OCAxMTo0Njo1NS41MjddICAgICBJUlEgIDEgVmVjIDQ4OgooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwgUGluICAxOiB2ZWM9MzAgZGVsaXZlcnk9
TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBk
ZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRICAzIFZl
YyA1NjoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDAs
IFBpbiAgMzogdmVjPTM4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0
eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjU1LjUyN10gICAgIElSUSAgNCBWZWMyNDE6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2
OjU1LjUyN10gICAgICAgQXBpYyAweDAwLCBQaW4gIDQ6IHZlYz1mMSBkZWxpdmVyeT1Mb1By
aSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3Rf
aWQ6MQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgIDUgVmVjIDY0
OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwgUGlu
ICA1OiB2ZWM9NDAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAg
aXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6
NTUuNTI3XSAgICAgSVJRICA2IFZlYyA3MjoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUu
NTI3XSAgICAgICBBcGljIDB4MDAsIFBpbiAgNjogdmVjPTQ4IGRlbGl2ZXJ5PUxvUHJpIGRl
c3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDox
CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElSUSAgNyBWZWMgODA6CihY
RU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBpYyAweDAwLCBQaW4gIDc6
IHZlYz01MCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9
MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41
MjddICAgICBJUlEgIDggVmVjIDg4OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41Mjdd
ICAgICAgIEFwaWMgMHgwMCwgUGluICA4OiB2ZWM9NTggZGVsaXZlcnk9TG9QcmkgZGVzdD1M
IHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhF
TikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRICA5IFZlYyA5NjoKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDAsIFBpbiAgOTogdmVj
PTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRy
aWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41Mjdd
ICAgICBJUlEgMTAgVmVjMTA0OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAg
ICAgIEFwaWMgMHgwMCwgUGluIDEwOiB2ZWM9NjggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0
YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRIDExIFZlYzExMjoKKFhFTikgWzIw
MTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDAsIFBpbiAxMTogdmVjPTcw
IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9
RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAg
IElSUSAxMiBWZWMxMjA6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAg
QXBpYyAweDAwLCBQaW4gMTI6IHZlYz03OCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVz
PTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAx
NC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgMTMgVmVjMTM2OgooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwgUGluIDEzOiB2ZWM9ODggZGVs
aXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1h
c2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElS
USAxNCBWZWMxNDQ6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBp
YyAweDAwLCBQaW4gMTQ6IHZlYz05MCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAg
cG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgMTUgVmVjMTUyOgooWEVOKSBbMjAxNC0xMS0x
OCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwgUGluIDE1OiB2ZWM9OTggZGVsaXZl
cnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9
MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRIDE2
IFZlYzEzNzoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4
MDAsIFBpbiAxNjogdmVjPTg5IGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xh
cml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE4
IDExOjQ2OjU1LjUyN10gICAgIElSUSAxNyBWZWMxOTI6CihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjU1LjUyN10gICAgICAgQXBpYyAweDAwLCBQaW4gMTc6IHZlYz1jMCBkZWxpdmVyeT1G
aXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRl
c3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgMTggVmVj
MTg0OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwg
UGluIDE4OiB2ZWM9YjggZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5
PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDY6NTUuNTI3XSAgICAgSVJRIDE5IFZlYyA0MjoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6
NTUuNTI3XSAgICAgICBBcGljIDB4MDAsIFBpbiAxOTogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVk
IGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9p
ZDo2MwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgMjIgVmVjMTg1
OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwgUGlu
IDIyOiB2ZWM9YjkgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEg
aXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjMyCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2
OjU1LjUyN10gICAgIElSUSAyNSBWZWMxNTQ6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1
LjUyN10gICAgICAgQXBpYyAweDAxLCBQaW4gIDE6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBk
ZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6
NjMKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRIDI4IFZlYyAzNDoK
KFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDEsIFBpbiAg
NDogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGly
cj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1
NS41MjddICAgICBJUlEgMjkgVmVjMjE3OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41
MjddICAgICAgIEFwaWMgMHgwMSwgUGluICA1OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVz
dD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYz
CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElSUSAzMiBWZWMyMDE6CihY
RU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBpYyAweDAxLCBQaW4gIDg6
IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9
MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUu
NTI3XSAgICAgSVJRIDMzIFZlYzE5MzoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3
XSAgICAgICBBcGljIDB4MDEsIFBpbiAgOTogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9
TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2Mwoo
WEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgMzYgVmVjIDMzOgooWEVO
KSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMSwgUGluIDEyOiB2
ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAg
dHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUy
N10gICAgIElSUSAzNyBWZWMgNDE6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10g
ICAgICAgQXBpYyAweDAxLCBQaW4gMTM6IHZlYz0yOSBkZWxpdmVyeT1GaXhlZCBkZXN0PUwg
c3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MTYKKFhF
TikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRIDM4IFZlYzE2OToKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDEsIFBpbiAxNDogdmVj
PTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRy
aWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41Mjdd
ICAgICBJUlEgNDAgVmVjIDQ5OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAg
ICAgIEFwaWMgMHgwMSwgUGluIDE2OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0
YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4p
IFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElSUSA0NiBWZWMxMTQ6CihYRU4pIFsy
MDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBpYyAweDAxLCBQaW4gMjI6IHZlYz0w
MCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmln
PUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAg
ICAgSVJRIDQ3IFZlYzIwOToKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAg
ICBBcGljIDB4MDEsIFBpbiAyMzogdmVjPWQxIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0
dXM9MSBwb2xhcml0eT0xIGlycj0xIHRyaWc9TCBtYXNrPTAgZGVzdF9pZDoxNgooWEVOKSBb
MjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgNDggVmVjMjA4OgooWEVOKSBbMjAx
NC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMSwgUGluIDI0OiB2ZWM9MDAg
ZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1M
IG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAg
IElSUSA1MSBWZWMxMzg6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAg
QXBpYyAweDAxLCBQaW4gMjc6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVz
PTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIw
MTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRIDUyIFZlYyA1NzoKKFhFTikgWzIwMTQt
MTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDEsIFBpbiAyODogdmVjPTAwIGRl
bGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBt
YXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJ
UlEgNTMgVmVjMjAwOgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFw
aWMgMHgwMSwgUGluIDI5OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0
LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElSUSA1NCBWZWMyMTY6CihYRU4pIFsyMDE0LTEx
LTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBpYyAweDAxLCBQaW4gMzA6IHZlYz0wMCBkZWxp
dmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFz
az0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTMzXSBNU0kgaW5m
b3JtYXRpb246CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzM10gIE1TSSAgICAgNTYg
dmVjPTI4IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAx
IG1hc2s9MC8wLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTMzXSAgSFBFVCAgICA1
NyB2ZWM9YTAgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAw
MDQgbWFzaz0xLzAvPwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzNdICBIUEVUICAg
IDU4IHZlYz1hOCBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAw
MDAwOCBtYXNrPTEvMC8/CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzM10gIEhQRVQg
ICAgNTkgdmVjPWIwIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAw
MDAwMDAyIG1hc2s9MS8wLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTMzXSAgTVNJ
ICAgICA2MCB2ZWM9NDEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9
MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzNdICBN
U0kgICAgIDYxIHZlYz00OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVz
dD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzM10g
IE1TSSAgICAgNjIgdmVjPTUxIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBk
ZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTMz
XSAgTVNJICAgICA2MyB2ZWM9NTkgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0
IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41
MzNdICBNU0kgICAgIDY0IHZlYz02MSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dl
c3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3
LjUzM10gIE1TSSAgICAgNjUgdmVjPTY5IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxv
d2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6
NTcuNTMzXSAgTVNJICAgICA2NiB2ZWM9NzEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cg
bG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0
Njo1Ny41MzNdICBNU0kgICAgIDY3IHZlYz03OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxv
ZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjU3LjUzM10gIE1TSSAgICAgNjggdmVjPTgxIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAg
bG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTgg
MTE6NDY6NTcuNTMzXSAgTVNJICAgICA2OSB2ZWM9OTEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0
ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0x
OCAxMTo0Njo1Ny41MzNdICBNU0kgICAgIDcwIHZlYz05OSBsb3dlc3QgIGVkZ2UgICBhc3Nl
cnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTEvMS8xCihYRU4pIFsyMDE0LTEx
LTE4IDExOjQ2OjU3LjUzM10gIE1TSSAgICAgNzEgdmVjPWExIGxvd2VzdCAgZWRnZSAgIGFz
c2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MS8xLzEKKFhFTikgWzIwMTQt
MTEtMTggMTE6NDY6NTcuNTMzXSAgTVNJICAgICA3MiB2ZWM9YjEgbG93ZXN0ICBlZGdlICAg
YXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0xLzEvMQooWEVOKSBbMjAx
NC0xMS0xOCAxMTo0Njo1Ny41MzNdICBNU0kgICAgIDczIHZlYz0zMiBsb3dlc3QgIGVkZ2Ug
ICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8/CihYRU4pIFsy
MDE0LTExLTE4IDExOjQ2OjU3LjUzM10gIE1TSSAgICAgNzQgdmVjPTNhIGxvd2VzdCAgZWRn
ZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8KKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTcuNTMzXSAgTVNJICAgICA3NSB2ZWM9NDIgbG93ZXN0ICBl
ZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDIgbWFzaz0wLzEvPwooWEVO
KSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzNdICBNU0kgICAgIDc2IHZlYz00YSBsb3dlc3Qg
IGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8/CihY
RU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzM10gIE1TSSAgICAgNzcgdmVjPTUyIGxvd2Vz
dCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8K
KFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTMzXSAgTVNJICAgICA3OCB2ZWM9NWEgbG93
ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFzaz0wLzEv
PwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzRdICBNU0kgICAgIDc5IHZlYz02MiBs
b3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAv
MS8/CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzNF0gIE1TSSAgICAgODAgdmVjPTZh
IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9
MC8xLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTM0XSAgTVNJICAgICA4MSB2ZWM9
N2EgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFz
az0wLzEvPwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzRdICBNU0kgICAgIDgyIHZl
Yz05MiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBt
YXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzNF0gIE1TSSAgICAgODMg
dmVjPWEyIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAx
IG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTM0XSAgTVNJLVggICA4
NCB2ZWM9YWEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAw
MDggbWFzaz0xLzAvMAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzRdICBNU0ktWCAg
IDg1IHZlYz1iMiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAw
MDAwNCBtYXNrPTEvMC8wCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzNF0gIE1TSS1Y
ICAgODYgdmVjPWJhIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAw
MDAwMDA0IG1hc2s9MS8wLzAKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTM0XSAgTVNJ
LVggICA4NyB2ZWM9YzIgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9
MDAwMDAwMDQgbWFzaz0xLzAvMAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzRdICBN
U0ktWCAgIDg4IHZlYz1jYSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVz
dD0wMDAwMDAwNCBtYXNrPTEvMC8wCg==
------------0191A1230144FE1ED
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0191A1230144FE1ED--



From xen-devel-bounces@lists.xen.org Tue Nov 18 15:09:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15: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 1XqkPT-00020o-GG; Tue, 18 Nov 2014 15:09:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqkPR-00020j-Sw
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:09:38 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	78/80-25727-1316B645; Tue, 18 Nov 2014 15:09:37 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416323368!12214646!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28936 invoked from network); 18 Nov 2014 15:09:28 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 18 Nov 2014 15:09:28 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52560 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqkNo-0003jt-Kk; Tue, 18 Nov 2014 16:07:57 +0100
Date: Tue, 18 Nov 2014 16:09:25 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <68258140.20141118160925@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <1408328417.20141118120741@eikelenboom.it>
References: <546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0191A1230144FE1ED"
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0191A1230144FE1ED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Tuesday, November 18, 2014, 12:07:41 PM, you wrote:
> Tuesday, November 18, 2014, 3:49:27 AM, you wrote:
>> On Mon, Nov 17, 2014 at 11:40:11PM +0100, Sander Eikelenboom wrote:
>>> 
>>> Monday, November 17, 2014, 9:43:47 PM, you wrote:
>>> 

<BIG SNIP>

>>> 
>>> > I am puzzled by the driver binding twice to the same interrupt, but perhaps that
>>> > is just a buggy driver.
>>> 
>>> Doesn't that happen more often like with integrated USB controllers ?
>>>   17:          4          0          0          0          0          0  xen-pirq-ioapic-level  ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
>>>   18:       4385          0          0          0          0          0  xen-pirq-ioapic-level  ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7

>> That was my thinking too. I passed in all my USB devices that looked
>> like that to my guest but it instead of making them be on the same
>> IRQ line - QEMU put them on seperate IRQ!
>  
>> And even with that I couldn't reproduce this crash.
> Hmm I am now testing with qemu-xen-traditional, i just noticed the output at 
> guest start is different between qemu-xen-traditional and qemu-xen:

> qemu-xen-traditional gives:
> (XEN) [2014-11-18 08:46:33.409] io.c:550: d16: bind: m_gsi=87 g_gsi=36 dev=00.00.5 intx=0
> (XEN) [2014-11-18 08:46:33.798] AMD-Vi: Disable: device id = 0x800, domain = 0, paging mode = 3
> (XEN) [2014-11-18 08:46:33.798] AMD-Vi: Setup I/O page table: device id = 0x800, type = 0x1, root table = 0x3fab6a000, domain = 16, paging mode = 3
> (XEN) [2014-11-18 08:46:33.798] AMD-Vi: Re-assign 0000:08:00.0 from dom0 to dom16
> (XEN) [2014-11-18 08:46:34.917] io.c:550: d16: bind: m_gsi=86 g_gsi=40 dev=00.00.6 intx=0
> (XEN) [2014-11-18 08:46:34.923] AMD-Vi: Disable: device id = 0xa00, domain = 0, paging mode = 3
> (XEN) [2014-11-18 08:46:34.923] AMD-Vi: Setup I/O page table: device id = 0xa00, type = 0x1, root table = 0x3fab6a000, domain = 16, paging mode = 3
> (XEN) [2014-11-18 08:46:34.923] AMD-Vi: Re-assign 0000:0a:00.0 from dom0 to dom16
> and when the guest is booting it gives:
> (XEN) [2014-11-18 08:47:02.128] io.c:584: d16: unbind: m_gsi=87 g_gsi=36 dev=00:00.5 intx=0
> (XEN) [2014-11-18 08:47:02.128] io.c:684: d16 final unmap: m_irq=87 dev=00:00.5 intx=0
> (XEN) [2014-11-18 08:47:02.128] io.c:550: d16: bind: m_gsi=37 g_gsi=16 dev=00.00.0 intx=0

> with qemu-xen it only gives the first part:
> (XEN) [2014-11-18 10:51:18.481] io.c:550: d16: bind: m_gsi=37 g_gsi=36 dev=00.00.5 intx=0
> (XEN) [2014-11-18 10:51:18.889] AMD-Vi: Disable: device id = 0x800, domain = 0, paging mode = 3
> (XEN) [2014-11-18 10:51:18.889] AMD-Vi: Setup I/O page table: device id = 0x800, type = 0x1, root table = 0x5071a6000, domain = 16, paging mode = 3
> (XEN) [2014-11-18 10:51:18.889] AMD-Vi: Re-assign 0000:08:00.0 from dom0 to dom16
> (XEN) [2014-11-18 10:51:20.016] io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0
> (XEN) [2014-11-18 10:51:20.022] AMD-Vi: Disable: device id = 0xa00, domain = 0, paging mode = 3
> (XEN) [2014-11-18 10:51:20.022] AMD-Vi: Setup I/O page table: device id = 0xa00, type = 0x1, root table = 0x5071a6000, domain = 16, paging mode = 3
> (XEN) [2014-11-18 10:51:20.022] AMD-Vi: Re-assign 0000:0a:00.0 from dom0 to dom16

> Looking at the m_gsi numbers .. could it be "pci_msitranslate=1" is not working for qemu-xen and that this causes this difference in output ?


> Another strange thing i noticed with qemu-xen-traditional ..  after a while the 
> irq number in /proc/interrupts is "stuck"  .. it doesn't increase anymore
>  40:      10851          0          0          0  xen-pirq-ioapic-level  cx25821[1]
> however the device still continues to grab video ... 

> I left it running for 2 hours, of which at least 1 hour the number of irq's in /proc/interrupts did
> not change for the legacy irq 40 of the videograbber. 
> The other number of IRQ's in /proc/interrupts do keep increasing (also for the passed
> through USB device which enabled MSI-X). 
> There is no crash and no debug output or errors in xl dmesg or guest dmesg and the device was
> still working until shutdown. 
> This is not good for one's sanity .. :-)

I have to amend this one, the videograbber was still working, however it seemed 
it had some timing issues in the video stream. So it was working, but less than with qemu-xen.
I don't know if that due to the interrupt count anomaly or that it's something else related 
to qemu-xen-traditional (irrespective of the dpci-patches and this issue).

>> Anyhow I was wondering if you could send (or point me to)
>> your xen-syms file(s). I've also attached an extra debug code that
>> should give me an idea if the crash/issue shows up in certain
>> situations - when we have_two_entries to deal with on one CPU.

I have xen-syms available with your latest patch for 
both with and without the #define DIFF_LIST 1 in a tarball at:
http://www.eikelenboom.it/xen-syms.tar.gz

>> It should apply cleanly on top of the other one.

> This one included your previous debug patch, so i had to revert that one,
> than it applied cleanly, so no problem !

>> Oh, and the xen-syms  - it can be either before this patch or
>> after - it won't matter much as I will be looking at the
>> assembler code.

>> Also what version of GCC compiler are you using ?

> # gcc -v
> Using built-in specs.
> COLLECT_GCC=/usr/bin/gcc-4.7.real
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.7.2 (Debian 4.7.2-5)

> That's default Debian wheezy/stable.

>> And lastly, the code also has an #ifdef DIFF_LIST - if you
>> want to turn that on (just add #define DIFF_LIST 1 at the top of 
>> the file) - it might stop the crash. Or not  :-(

>> If it does stop the crash then I think we are looking at an
>> GCC bug - in which case the xen-syms of that build (with
>> the DIFF_LIST) would also be interesting!

> Will give this patch with and without the #define DIFF_LIST 1 a shot with qemu-xen and report back.

Well 3 results here:

Without #define DIFF_LIST 1:
1) The guest still crashes (xl-dmesg-not-defined.txt)

With #define DIFF_LIST 1:
2) Nor the guest or the host crashed (let it run for about an hour and 15 minutes), 
   but the USB XHCI driver bailed out quickly after guest boot, so there were no MSI-X interrupts anymore.
   (xl-dmesg-defined-nousb.txt, dmesg-guest-defined-nousb.txt)
3) On another boot the USB XHCI didn't bail out, after a while the host crashes. (serial.log)
   (XEN) [2014-11-18 14:53:37.364] RIP:    e008:[<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
   which resolves to:
   # addr2line -e xen-syms ffff82d08014a4de
   /usr/src/new/xen-unstable-vanilla/xen/include/xen/list.h:67
   which is:
   static inline void __list_add(struct list_head *new,
                              struct list_head *prev,
                              struct list_head *next)
    {
    next->prev = new;
    new->next = next;
    new->prev = prev;
Here ->    prev->next = new;
    }

When i look at the combination of (2) and (3), It seems it could be an 
interaction between the two passed through devices and/or different IRQ types.

So i will now test without #define DIFF_LIST 1 and not passing through the USB controller, see
if that still crashes, if it doesn't i will see if i can passthrough a device which also only uses legacy
interrupts instead of MSI / MSI-X, see if that crashes or not.

>> Thank you.
------------0191A1230144FE1ED
Content-Type: text/plain;
 name="dmesg-guest-defined-nousb.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="dmesg-guest-defined-nousb.txt"

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAg
MC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAw
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVhY2N0ClsgICAgMC4wMDAwMDBdIExp
bnV4IHZlcnNpb24gMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0eS1ub3NuZCsgKHJvb3RA
c2VjdXJpdHkpIChnY2MgdmVyc2lvbiA0LjcuMiAoRGViaWFuIDQuNy4yLTUpICkgIzEgU01Q
IFR1ZSBOb3YgMTggMDA6MzM6NDMgQ0VUIDIwMTQKWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBs
aW5lOiBCT09UX0lNQUdFPS9ib290L3ZtbGludXotMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1
cml0eS1ub3NuZCsgcm9vdD0vZGV2L3h2ZGExIHJvIGNvbnNvbGU9dHR5MSBjb25zb2xlPXR0
eVMwIG5vbW9kZXNldApbICAgIDAuMDAwMDAwXSB0c2VnOiAwMDAwMDAwMDAwClsgICAgMC4w
MDAwMDBdIGU4MjA6IEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoKWyAgICAwLjAw
MDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAw
OWZiZmZdIHVzYWJsZQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAw
MDAwMDlmYzAwLTB4MDAwMDAwMDAwMDA5ZmZmZl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0g
QklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDAwMDBmMDAwMC0weDAwMDAwMDAwMDAwZmZmZmZd
IHJlc2VydmVkClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwMDAx
MDAwMDAtMHgwMDAwMDAwMDNmN2ZkZmZmXSB1c2FibGUKWyAgICAwLjAwMDAwMF0gQklPUy1l
ODIwOiBbbWVtIDB4MDAwMDAwMDAzZjdmZTAwMC0weDAwMDAwMDAwM2Y3ZmZmZmZdIHJlc2Vy
dmVkClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwZmMwMDAwMDAt
MHgwMDAwMDAwMGZmZmZmZmZmXSByZXNlcnZlZApbICAgIDAuMDAwMDAwXSBOWCAoRXhlY3V0
ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUKWyAgICAwLjAwMDAwMF0gU01CSU9TIDIu
NCBwcmVzZW50LgpbICAgIDAuMDAwMDAwXSBETUk6IFhlbiBIVk0gZG9tVSwgQklPUyA0LjUu
MC1yYyAxMS8xOC8yMDE0ClsgICAgMC4wMDAwMDBdIEh5cGVydmlzb3IgZGV0ZWN0ZWQ6IFhl
biBIVk0KWyAgICAwLjAwMDAwMF0gWGVuIHZlcnNpb24gNC41LgpbICAgIDAuMDAwMDAwXSBY
ZW4gUGxhdGZvcm0gUENJOiBJL08gcHJvdG9jb2wgdmVyc2lvbiAxClsgICAgMC4wMDAwMDBd
IE5ldGZyb250IGFuZCB0aGUgWGVuIHBsYXRmb3JtIFBDSSBkcml2ZXIgaGF2ZSBiZWVuIGNv
bXBpbGVkIGZvciB0aGlzIGtlcm5lbDogdW5wbHVnIGVtdWxhdGVkIE5JQ3MuClsgICAgMC4w
MDAwMDBdIEJsa2Zyb250IGFuZCB0aGUgWGVuIHBsYXRmb3JtIFBDSSBkcml2ZXIgaGF2ZSBi
ZWVuIGNvbXBpbGVkIGZvciB0aGlzIGtlcm5lbDogdW5wbHVnIGVtdWxhdGVkIGRpc2tzLgpb
ICAgIDAuMDAwMDAwXSBZb3UgbWlnaHQgaGF2ZSB0byBjaGFuZ2UgdGhlIHJvb3QgZGV2aWNl
ClsgICAgMC4wMDAwMDBdIGZyb20gL2Rldi9oZFthLWRdIHRvIC9kZXYveHZkW2EtZF0KWyAg
ICAwLjAwMDAwMF0gaW4geW91ciByb290PSBrZXJuZWwgY29tbWFuZCBsaW5lIG9wdGlvbgpb
ICAgIDAuMDAwMDAwXSBIVk1PUF9wYWdldGFibGVfZHlpbmcgbm90IHN1cHBvcnRlZApbICAg
IDAuMDAwMDAwXSBlODIwOiB1cGRhdGUgW21lbSAweDAwMDAwMDAwLTB4MDAwMDBmZmZdIHVz
YWJsZSA9PT4gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHgw
MDBhMDAwMC0weDAwMGZmZmZmXSB1c2FibGUKWyAgICAwLjAwMDAwMF0gQUdQOiBObyBBR1Ag
YnJpZGdlIGZvdW5kClsgICAgMC4wMDAwMDBdIGU4MjA6IGxhc3RfcGZuID0gMHgzZjdmZSBt
YXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBNVFJSIGRlZmF1bHQg
dHlwZTogd3JpdGUtYmFjawpbICAgIDAuMDAwMDAwXSBNVFJSIGZpeGVkIHJhbmdlcyBlbmFi
bGVkOgpbICAgIDAuMDAwMDAwXSAgIDAwMDAwLTlGRkZGIHdyaXRlLWJhY2sKWyAgICAwLjAw
MDAwMF0gICBBMDAwMC1CRkZGRiB3cml0ZS1jb21iaW5pbmcKWyAgICAwLjAwMDAwMF0gICBD
MDAwMC1GRkZGRiB3cml0ZS1iYWNrClsgICAgMC4wMDAwMDBdIE1UUlIgdmFyaWFibGUgcmFu
Z2VzIGVuYWJsZWQ6ClsgICAgMC4wMDAwMDBdICAgMCBiYXNlIDAwMDBGMDAwMDAwMCBtYXNr
IEZGRkZGMDAwMDAwMCB1bmNhY2hhYmxlClsgICAgMC4wMDAwMDBdICAgMSBkaXNhYmxlZApb
ICAgIDAuMDAwMDAwXSAgIDIgZGlzYWJsZWQKWyAgICAwLjAwMDAwMF0gICAzIGRpc2FibGVk
ClsgICAgMC4wMDAwMDBdICAgNCBkaXNhYmxlZApbICAgIDAuMDAwMDAwXSAgIDUgZGlzYWJs
ZWQKWyAgICAwLjAwMDAwMF0gICA2IGRpc2FibGVkClsgICAgMC4wMDAwMDBdICAgNyBkaXNh
YmxlZApbICAgIDAuMDAwMDAwXSBUT00yOiAwMDAwMDAwNTYwMDAwMDAwIGFrYSAyMjAxNk0K
WyAgICAwLjAwMDAwMF0geDg2IFBBVCBlbmFibGVkOiBjcHUgMCwgb2xkIDB4NzA0MDYwMDA3
MDQwNiwgbmV3IDB4NzAxMDYwMDA3MDEwNgpbICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAt
dGFibGUgYXQgW21lbSAweDAwMGYwZTMwLTB4MDAwZjBlM2ZdIG1hcHBlZCBhdCBbZmZmZjg4
MDAwMDBmMGUzMF0KWyAgICAwLjAwMDAwMF0gU2Nhbm5pbmcgMSBhcmVhcyBmb3IgbG93IG1l
bW9yeSBjb3JydXB0aW9uClsgICAgMC4wMDAwMDBdIEJhc2UgbWVtb3J5IHRyYW1wb2xpbmUg
YXQgW2ZmZmY4ODAwMDAwOTkwMDBdIDk5MDAwIHNpemUgMjQ1NzYKWyAgICAwLjAwMDAwMF0g
aW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMDAwMDAwLTB4MDAwZmZmZmZdClsgICAg
MC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0gcGFnZSA0awpbICAgIDAu
MDAwMDAwXSBCUksgWzB4MDIyZmUwMDAsIDB4MDIyZmVmZmZdIFBHVEFCTEUKWyAgICAwLjAw
MDAwMF0gQlJLIFsweDAyMmZmMDAwLCAweDAyMmZmZmZmXSBQR1RBQkxFClsgICAgMC4wMDAw
MDBdIEJSSyBbMHgwMjMwMDAwMCwgMHgwMjMwMGZmZl0gUEdUQUJMRQpbICAgIDAuMDAwMDAw
XSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4M2Y0MDAwMDAtMHgzZjVmZmZmZl0KWyAg
ICAwLjAwMDAwMF0gIFttZW0gMHgzZjQwMDAwMC0weDNmNWZmZmZmXSBwYWdlIDJNClsgICAg
MC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgzYzAwMDAwMC0weDNmM2Zm
ZmZmXQpbICAgIDAuMDAwMDAwXSAgW21lbSAweDNjMDAwMDAwLTB4M2YzZmZmZmZdIHBhZ2Ug
Mk0KWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMTAwMDAw
LTB4M2JmZmZmZmZdClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAxMDAwMDAtMHgwMDFmZmZm
Zl0gcGFnZSA0awpbICAgIDAuMDAwMDAwXSAgW21lbSAweDAwMjAwMDAwLTB4M2JmZmZmZmZd
IHBhZ2UgMk0KWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDNm
NjAwMDAwLTB4M2Y3ZmRmZmZdClsgICAgMC4wMDAwMDBdICBbbWVtIDB4M2Y2MDAwMDAtMHgz
ZjdmZGZmZl0gcGFnZSA0awpbICAgIDAuMDAwMDAwXSBCUksgWzB4MDIzMDEwMDAsIDB4MDIz
MDFmZmZdIFBHVEFCTEUKWyAgICAwLjAwMDAwMF0gUkFNRElTSzogW21lbSAweDM3YzQ4MDAw
LTB4MzdlMWJmZmZdClsgICAgMC4wMDAwMDBdIEFDUEk6IEVhcmx5IHRhYmxlIGNoZWNrc3Vt
IHZlcmlmaWNhdGlvbiBkaXNhYmxlZApbICAgIDAuMDAwMDAwXSBBQ1BJOiBSU0RQIDB4MDAw
MDAwMDAwMDBGMEQ4MCAwMDAwMjQgKHYwMiBYZW4gICApClsgICAgMC4wMDAwMDBdIEFDUEk6
IFhTRFQgMHgwMDAwMDAwMEZDMDBBMTQwIDAwMDA1NCAodjAxIFhlbiAgICBIVk0gICAgICAw
MDAwMDAwMCBIVk1MIDAwMDAwMDAwKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBGQUNQIDB4MDAw
MDAwMDBGQzAwOUE3MCAwMDAwRjQgKHYwNCBYZW4gICAgSFZNICAgICAgMDAwMDAwMDAgSFZN
TCAwMDAwMDAwMCkKWyAgICAwLjAwMDAwMF0gQUNQSTogRFNEVCAweDAwMDAwMDAwRkMwMDEz
MDAgMDA4NkYwICh2MDIgWGVuICAgIEhWTSAgICAgIDAwMDAwMDAwIElOVEwgMjAxMDA1Mjgp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMHgwMDAwMDAwMEZDMDAxMkMwIDAwMDA0MApb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBBUElDIDB4MDAwMDAwMDBGQzAwOUI3MCAwMDA0NjAgKHYw
MiBYZW4gICAgSFZNICAgICAgMDAwMDAwMDAgSFZNTCAwMDAwMDAwMCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogSFBFVCAweDAwMDAwMDAwRkMwMEEwNTAgMDAwMDM4ICh2MDEgWGVuICAgIEhW
TSAgICAgIDAwMDAwMDAwIEhWTUwgMDAwMDAwMDApClsgICAgMC4wMDAwMDBdIEFDUEk6IFdB
RVQgMHgwMDAwMDAwMEZDMDBBMDkwIDAwMDAyOCAodjAxIFhlbiAgICBIVk0gICAgICAwMDAw
MDAwMCBIVk1MIDAwMDAwMDAwKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDB4MDAwMDAw
MDBGQzAwQTBDMCAwMDAwMzEgKHYwMiBYZW4gICAgSFZNICAgICAgMDAwMDAwMDAgSU5UTCAy
MDEwMDUyOCkKWyAgICAwLjAwMDAwMF0gQUNQSTogU1NEVCAweDAwMDAwMDAwRkMwMEExMDAg
MDAwMDMxICh2MDIgWGVuICAgIEhWTSAgICAgIDAwMDAwMDAwIElOVEwgMjAxMDA1MjgpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwClsgICAg
MC4wMDAwMDBdIE5vIE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZApbICAgIDAuMDAwMDAwXSBG
YWtpbmcgYSBub2RlIGF0IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAzZjdm
ZGZmZl0KWyAgICAwLjAwMDAwMF0gTk9ERV9EQVRBKDApIGFsbG9jYXRlZCBbbWVtIDB4M2Y3
ZjMwMDAtMHgzZjdmZGZmZl0KWyAgICAwLjAwMDAwMF0gIFtmZmZmZWEwMDAwMDAwMDAwLWZm
ZmZlYTAwMDBmZmZmZmZdIFBNRCAtPiBbZmZmZjg4MDAzZGUwMDAwMC1mZmZmODgwMDNlZGZm
ZmZmXSBvbiBub2RlIDAKWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6ClsgICAgMC4wMDAw
MDBdICAgRE1BICAgICAgW21lbSAweDAwMDAxMDAwLTB4MDBmZmZmZmZdClsgICAgMC4wMDAw
MDBdICAgRE1BMzIgICAgW21lbSAweDAxMDAwMDAwLTB4ZmZmZmZmZmZdClsgICAgMC4wMDAw
MDBdICAgTm9ybWFsICAgZW1wdHkKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0
IGZvciBlYWNoIG5vZGUKWyAgICAwLjAwMDAwMF0gRWFybHkgbWVtb3J5IG5vZGUgcmFuZ2Vz
ClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAwMTAwMC0weDAwMDllZmZm
XQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4MDAxMDAwMDAtMHgzZjdmZGZm
Zl0KWyAgICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAgW21lbSAweDAwMDAxMDAw
LTB4M2Y3ZmRmZmZdClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAyNTk5
OTYKWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogNjQgcGFnZXMgdXNlZCBmb3IgbWVtbWFw
ClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDIxIHBhZ2VzIHJlc2VydmVkClsgICAgMC4w
MDAwMDBdICAgRE1BIHpvbmU6IDM5OTggcGFnZXMsIExJRk8gYmF0Y2g6MApbICAgIDAuMDAw
MDAwXSAgIERNQTMyIHpvbmU6IDQwMDAgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4w
MDAwMDBdICAgRE1BMzIgem9uZTogMjU1OTk4IHBhZ2VzLCBMSUZPIGJhdGNoOjMxClsgICAg
MC4wMDAwMDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4YjAwOApbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDAwXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAyXSBl
bmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBp
Y19pZFsweDA0XSBlbmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAzXSBsYXBpY19pZFsweDA2XSBlbmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDA4XSBkaXNhYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwYV0gZGlzYWJs
ZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lk
WzB4MGNdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDA3XSBsYXBpY19pZFsweDBlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwOF0gbGFwaWNfaWRbMHgxMF0gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDldIGxhcGljX2lkWzB4MTJdIGRpc2FibGVk
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBhXSBsYXBpY19pZFsw
eDE0XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
Yl0gbGFwaWNfaWRbMHgxNl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4MGNdIGxhcGljX2lkWzB4MThdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBkXSBsYXBpY19pZFsweDFhXSBkaXNhYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwZV0gbGFwaWNfaWRbMHgx
Y10gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGZd
IGxhcGljX2lkWzB4MWVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDEwXSBsYXBpY19pZFsweDIwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxMV0gbGFwaWNfaWRbMHgyMl0gZGlzYWJsZWQpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MTJdIGxhcGljX2lkWzB4MjRd
IGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDEzXSBs
YXBpY19pZFsweDI2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgxNF0gbGFwaWNfaWRbMHgyOF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MTVdIGxhcGljX2lkWzB4MmFdIGRpc2FibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDE2XSBsYXBpY19pZFsweDJjXSBk
aXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxN10gbGFw
aWNfaWRbMHgyZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MThdIGxhcGljX2lkWzB4MzBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDE5XSBsYXBpY19pZFsweDMyXSBkaXNhYmxlZCkKWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxYV0gbGFwaWNfaWRbMHgzNF0gZGlz
YWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MWJdIGxhcGlj
X2lkWzB4MzZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDFjXSBsYXBpY19pZFsweDM4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgxZF0gbGFwaWNfaWRbMHgzYV0gZGlzYWJsZWQpClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MWVdIGxhcGljX2lkWzB4M2NdIGRpc2Fi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDFmXSBsYXBpY19p
ZFsweDNlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgyMF0gbGFwaWNfaWRbMHg0MF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MjFdIGxhcGljX2lkWzB4NDJdIGRpc2FibGVkKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDIyXSBsYXBpY19pZFsweDQ0XSBkaXNhYmxl
ZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyM10gbGFwaWNfaWRb
MHg0Nl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
MjRdIGxhcGljX2lkWzB4NDhdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDI1XSBsYXBpY19pZFsweDRhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyNl0gbGFwaWNfaWRbMHg0Y10gZGlzYWJsZWQp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MjddIGxhcGljX2lkWzB4
NGVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDI4
XSBsYXBpY19pZFsweDUwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgyOV0gbGFwaWNfaWRbMHg1Ml0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MmFdIGxhcGljX2lkWzB4NTRdIGRpc2FibGVkKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDJiXSBsYXBpY19pZFsweDU2
XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyY10g
bGFwaWNfaWRbMHg1OF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4MmRdIGxhcGljX2lkWzB4NWFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDJlXSBsYXBpY19pZFsweDVjXSBkaXNhYmxlZCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyZl0gbGFwaWNfaWRbMHg1ZV0g
ZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MzBdIGxh
cGljX2lkWzB4NjBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDMxXSBsYXBpY19pZFsweDYyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgzMl0gbGFwaWNfaWRbMHg2NF0gZGlzYWJsZWQpClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MzNdIGxhcGljX2lkWzB4NjZdIGRp
c2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDM0XSBsYXBp
Y19pZFsweDY4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgzNV0gbGFwaWNfaWRbMHg2YV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4MzZdIGxhcGljX2lkWzB4NmNdIGRpc2FibGVkKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDM3XSBsYXBpY19pZFsweDZlXSBkaXNh
YmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgzOF0gbGFwaWNf
aWRbMHg3MF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MzldIGxhcGljX2lkWzB4NzJdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDNhXSBsYXBpY19pZFsweDc0XSBkaXNhYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgzYl0gbGFwaWNfaWRbMHg3Nl0gZGlzYWJs
ZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4M2NdIGxhcGljX2lk
WzB4NzhdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDNkXSBsYXBpY19pZFsweDdhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgzZV0gbGFwaWNfaWRbMHg3Y10gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4M2ZdIGxhcGljX2lkWzB4N2VdIGRpc2FibGVk
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQwXSBsYXBpY19pZFsw
eDgwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0
MV0gbGFwaWNfaWRbMHg4Ml0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4NDJdIGxhcGljX2lkWzB4ODRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQzXSBsYXBpY19pZFsweDg2XSBkaXNhYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0NF0gbGFwaWNfaWRbMHg4
OF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NDVd
IGxhcGljX2lkWzB4OGFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDQ2XSBsYXBpY19pZFsweDhjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0N10gbGFwaWNfaWRbMHg4ZV0gZGlzYWJsZWQpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NDhdIGxhcGljX2lkWzB4OTBd
IGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDQ5XSBs
YXBpY19pZFsweDkyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHg0YV0gbGFwaWNfaWRbMHg5NF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4NGJdIGxhcGljX2lkWzB4OTZdIGRpc2FibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDRjXSBsYXBpY19pZFsweDk4XSBk
aXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg0ZF0gbGFw
aWNfaWRbMHg5YV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4NGVdIGxhcGljX2lkWzB4OWNdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDRmXSBsYXBpY19pZFsweDllXSBkaXNhYmxlZCkKWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1MF0gbGFwaWNfaWRbMHhhMF0gZGlz
YWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NTFdIGxhcGlj
X2lkWzB4YTJdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDUyXSBsYXBpY19pZFsweGE0XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHg1M10gbGFwaWNfaWRbMHhhNl0gZGlzYWJsZWQpClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NTRdIGxhcGljX2lkWzB4YThdIGRpc2Fi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDU1XSBsYXBpY19p
ZFsweGFhXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHg1Nl0gbGFwaWNfaWRbMHhhY10gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4NTddIGxhcGljX2lkWzB4YWVdIGRpc2FibGVkKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDU4XSBsYXBpY19pZFsweGIwXSBkaXNhYmxl
ZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1OV0gbGFwaWNfaWRb
MHhiMl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
NWFdIGxhcGljX2lkWzB4YjRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDViXSBsYXBpY19pZFsweGI2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg1Y10gbGFwaWNfaWRbMHhiOF0gZGlzYWJsZWQp
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NWRdIGxhcGljX2lkWzB4
YmFdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDVl
XSBsYXBpY19pZFsweGJjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHg1Zl0gbGFwaWNfaWRbMHhiZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4NjBdIGxhcGljX2lkWzB4YzBdIGRpc2FibGVkKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDYxXSBsYXBpY19pZFsweGMy
XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2Ml0g
bGFwaWNfaWRbMHhjNF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4NjNdIGxhcGljX2lkWzB4YzZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDY0XSBsYXBpY19pZFsweGM4XSBkaXNhYmxlZCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2NV0gbGFwaWNfaWRbMHhjYV0g
ZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NjZdIGxh
cGljX2lkWzB4Y2NdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDY3XSBsYXBpY19pZFsweGNlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHg2OF0gbGFwaWNfaWRbMHhkMF0gZGlzYWJsZWQpClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NjldIGxhcGljX2lkWzB4ZDJdIGRp
c2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDZhXSBsYXBp
Y19pZFsweGQ0XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHg2Yl0gbGFwaWNfaWRbMHhkNl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4NmNdIGxhcGljX2lkWzB4ZDhdIGRpc2FibGVkKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDZkXSBsYXBpY19pZFsweGRhXSBkaXNh
YmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg2ZV0gbGFwaWNf
aWRbMHhkY10gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4NmZdIGxhcGljX2lkWzB4ZGVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDcwXSBsYXBpY19pZFsweGUwXSBkaXNhYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3MV0gbGFwaWNfaWRbMHhlMl0gZGlzYWJs
ZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NzJdIGxhcGljX2lk
WzB4ZTRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDczXSBsYXBpY19pZFsweGU2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHg3NF0gbGFwaWNfaWRbMHhlOF0gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4NzVdIGxhcGljX2lkWzB4ZWFdIGRpc2FibGVk
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDc2XSBsYXBpY19pZFsw
eGVjXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3
N10gbGFwaWNfaWRbMHhlZV0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4NzhdIGxhcGljX2lkWzB4ZjBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDc5XSBsYXBpY19pZFsweGYyXSBkaXNhYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3YV0gbGFwaWNfaWRbMHhm
NF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4N2Jd
IGxhcGljX2lkWzB4ZjZdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDdjXSBsYXBpY19pZFsweGY4XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHg3ZF0gbGFwaWNfaWRbMHhmYV0gZGlzYWJsZWQpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4N2VdIGxhcGljX2lkWzB4ZmNd
IGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDdmXSBs
YXBpY19pZFsweGZlXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChp
ZFsweDAxXSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQpbICAgIDAuMDAwMDAw
XSBJT0FQSUNbMF06IGFwaWNfaWQgMSwgdmVyc2lvbiAxNywgYWRkcmVzcyAweGZlYzAwMDAw
LCBHU0kgMC00NwpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRf
U1JDX09WUiAoYnVzIDAgYnVzX2lycSA1IGdsb2JhbF9pcnEgNSBsb3cgbGV2ZWwpClsgICAg
MC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDEwIGdsb2JhbF9p
cnEgMTAgbG93IGxldmVsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVz
IDAgYnVzX2lycSAxMSBnbG9iYWxfaXJxIDExIGxvdyBsZXZlbCkKWyAgICAwLjAwMDAwMF0g
QUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE1
IHVzZWQgYnkgb3ZlcnJpZGUuClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTkgdXNlZCBieSBv
dmVycmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMTAgdXNlZCBieSBvdmVycmlkZS4K
WyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMTEgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAw
MDAwMF0gVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0
aW9uClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgaWQ6IDB4ODA4NmEyMDEgYmFzZTogMHhm
ZWQwMDAwMApbICAgIDAuMDAwMDAwXSBzbXBib290OiAxMjggUHJvY2Vzc29ycyBleGNlZWRz
IE5SX0NQVVMgbGltaXQgb2YgOApbICAgIDAuMDAwMDAwXSBzbXBib290OiBBbGxvd2luZyA4
IENQVXMsIDQgaG90cGx1ZyBDUFVzClsgICAgMC4wMDAwMDBdIGU4MjA6IFttZW0gMHgzZjgw
MDAwMC0weGZiZmZmZmZmXSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2VzClsgICAgMC4wMDAw
MDBdIEJvb3RpbmcgcGFyYXZpcnR1YWxpemVkIGtlcm5lbCBvbiBYZW4gSFZNClsgICAgMC4w
MDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo4IG5yX2NwdW1hc2tfYml0czo4IG5yX2Nw
dV9pZHM6OCBucl9ub2RlX2lkczoxClsgICAgMC4wMDAwMDBdIFBFUkNQVTogRW1iZWRkZWQg
MjkgcGFnZXMvY3B1IEBmZmZmODgwMDNmNDAwMDAwIHM3OTQ4OCByODE5MiBkMzExMDQgdTI2
MjE0NApbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzNzk0ODggcjgxOTIgZDMxMTA0IHUy
NjIxNDQgYWxsb2M9MSoyMDk3MTUyClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IFswXSAw
IDEgMiAzIDQgNSA2IDcgClsgICAgMC4wMDAwMDBdIHhlbjogUFYgc3BpbmxvY2tzIGVuYWJs
ZWQKWyAgICAwLjAwMDAwMF0gQnVpbHQgMSB6b25lbGlzdHMgaW4gTm9kZSBvcmRlciwgbW9i
aWxpdHkgZ3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczogMjU1OTExClsgICAgMC4wMDAwMDBd
IFBvbGljeSB6b25lOiBETUEzMgpbICAgIDAuMDAwMDAwXSBLZXJuZWwgY29tbWFuZCBsaW5l
OiBCT09UX0lNQUdFPS9ib290L3ZtbGludXotMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0
eS1ub3NuZCsgcm9vdD0vZGV2L3h2ZGExIHJvIGNvbnNvbGU9dHR5MSBjb25zb2xlPXR0eVMw
IG5vbW9kZXNldApbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2
IChvcmRlcjogMywgMzI3NjggYnl0ZXMpClsgICAgMC4wMDAwMDBdIEFHUDogQ2hlY2tpbmcg
YXBlcnR1cmUuLi4KWyAgICAwLjAwMDAwMF0gQUdQOiBObyBBR1AgYnJpZGdlIGZvdW5kClsg
ICAgMC4wMDAwMDBdIE1lbW9yeTogMTAwMTEyMEsvMTAzOTk4NEsgYXZhaWxhYmxlICgxMDkz
Nksga2VybmVsIGNvZGUsIDg4NksgcndkYXRhLCAzNDk2SyByb2RhdGEsIDEwNDhLIGluaXQs
IDEwNzZLIGJzcywgMzg4NjRLIHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSBTTFVCOiBIV2Fs
aWduPTY0LCBPcmRlcj0wLTMsIE1pbk9iamVjdHM9MCwgQ1BVcz04LCBOb2Rlcz0xClsgICAg
MC4wMDAwMDBdIEhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uClsgICAgMC4wMDAw
MDBdIAlSQ1UgZHludGljay1pZGxlIGdyYWNlLXBlcmlvZCBhY2NlbGVyYXRpb24gaXMgZW5h
YmxlZC4KWyAgICAwLjAwMDAwMF0gTlJfSVJRUzo0MzUyIG5yX2lycXM6ODk2IDAKWyAgICAw
LjAwMDAwMF0geGVuOmV2ZW50czogVXNpbmcgRklGTy1iYXNlZCBBQkkKWyAgICAwLjAwMDAw
MF0geGVuOmV2ZW50czogWGVuIEhWTSBjYWxsYmFjayB2ZWN0b3IgZm9yIGV2ZW50IGRlbGl2
ZXJ5IGlzIGVuYWJsZWQKWyAgICAwLjAwMDAwMF0gQ29uc29sZTogY29sb3VyIFZHQSsgODB4
MjUKWyAgICAwLjAwMDAwMF0gY29uc29sZSBbdHR5MV0gZW5hYmxlZApbICAgIDAuMDAwMDAw
XSBjb25zb2xlIFt0dHlTMF0gZW5hYmxlZApbICAgIDAuMDAwMDAwXSBocGV0IGNsb2NrZXZl
bnQgcmVnaXN0ZXJlZApbICAgIDAuMDAwMDAwXSB0c2M6IERldGVjdGVkIDMyMDAuMTcyIE1I
eiBwcm9jZXNzb3IKWyAgICAwLjAwMDAwMF0gdHNjOiBNYXJraW5nIFRTQyB1bnN0YWJsZSBk
dWUgdG8gVFNDcyB1bnN5bmNocm9uaXplZApbICAgIDAuMDI5OTk5XSBDYWxpYnJhdGluZyBk
ZWxheSBsb29wIChza2lwcGVkKSwgdmFsdWUgY2FsY3VsYXRlZCB1c2luZyB0aW1lciBmcmVx
dWVuY3kuLiA2NDAyLjAyIEJvZ29NSVBTIChscGo9MTA2NjcyNDApClsgICAgMC4wNTY2NzBd
IHBpZF9tYXg6IGRlZmF1bHQ6IDMyNzY4IG1pbmltdW06IDMwMQpbICAgIDAuMDcwMDE0XSBB
Q1BJOiBDb3JlIHJldmlzaW9uIDIwMTQwOTI2ClsgICAgMC4wOTA2NzhdIEFDUEk6IEFsbCBB
Q1BJIFRhYmxlcyBzdWNjZXNzZnVsbHkgYWNxdWlyZWQKWyAgICAwLjEwNTU1Ml0gRGVudHJ5
IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjogOCwgMTA0ODU3NiBi
eXRlcykKWyAgICAwLjEyMzYyMF0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2
NTUzNiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykKWyAgICAwLjE0MDEzOV0gTW91bnQtY2Fj
aGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChvcmRlcjogMiwgMTYzODQgYnl0ZXMpClsg
ICAgMC4xNjAwMTBdIE1vdW50cG9pbnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4
IChvcmRlcjogMiwgMTYzODQgYnl0ZXMpClsgICAgMC4xODAxNzBdIEluaXRpYWxpemluZyBj
Z3JvdXAgc3Vic3lzIGZyZWV6ZXIKWyAgICAwLjE5MzM0Ml0gSW5pdGlhbGl6aW5nIGNncm91
cCBzdWJzeXMgYmxraW8KWyAgICAwLjIwNjg0Ml0gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3Ig
SUQ6IDAKWyAgICAwLjIxNjY3Ml0gQ1BVOiBQcm9jZXNzb3IgQ29yZSBJRDogMApbICAgIDAu
MjI2NjczXSBtY2U6IENQVSBzdXBwb3J0cyAyIE1DRSBiYW5rcwpbICAgIDAuMjQwMDI2XSBM
YXN0IGxldmVsIGlUTEIgZW50cmllczogNEtCIDUxMiwgMk1CIDE2LCA0TUIgOApbICAgIDAu
MjQwMDI2XSBMYXN0IGxldmVsIGRUTEIgZW50cmllczogNEtCIDUxMiwgMk1CIDEyOCwgNE1C
IDY0LCAxR0IgMApbICAgIDAuMjcwMjk4XSBGcmVlaW5nIFNNUCBhbHRlcm5hdGl2ZXMgbWVt
b3J5OiA0MEsgKGZmZmZmZmZmODIxZTUwMDAgLSBmZmZmZmZmZjgyMWVmMDAwKQpbICAgIDAu
MzAwMzQzXSAuLlRJTUVSOiB2ZWN0b3I9MHgzMCBhcGljMT0wIHBpbjE9MiBhcGljMj0wIHBp
bjI9MApbICAgIDAuMzQ5OTk5XSBzbXBib290OiBDUFUwOiBBTUQgUGhlbm9tKHRtKSBJSSBY
NiAxMDkwVCBQcm9jZXNzb3IgKGZhbTogMTAsIG1vZGVsOiAwYSwgc3RlcHBpbmc6IDAwKQpb
ICAgIDAuMzczMzUxXSBYZW46IHVzaW5nIHZjcHVvcCB0aW1lciBpbnRlcmZhY2UKWyAgICAw
LjM3MzM2NF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAwClsgICAgMC4zODY3NzJd
IGNwdSAwIHNwaW5sb2NrIGV2ZW50IGlycSA1MwpbICAgIDAuMzk4MTcxXSBQZXJmb3JtYW5j
ZSBFdmVudHM6IEJyb2tlbiBQTVUgaGFyZHdhcmUgZGV0ZWN0ZWQsIHVzaW5nIHNvZnR3YXJl
IGV2ZW50cyBvbmx5LgpbICAgIDAuNDAzMzQyXSBGYWlsZWQgdG8gYWNjZXNzIHBlcmZjdHIg
bXNyIChNU1IgYzAwMTAwMDQgaXMgMCkKWyAgICAwLjQwNjk2N10gaW5zdGFsbGluZyBYZW4g
dGltZXIgZm9yIENQVSAxClsgICAgMC40MTAwNzldIHg4NjogQm9vdGluZyBTTVAgY29uZmln
dXJhdGlvbjoKWyAgICAwLjQxMzM0MV0gLi4uLiBub2RlICAjMCwgQ1BVczogICAgICAjMWNw
dSAxIHNwaW5sb2NrIGV2ZW50IGlycSA1OQpbICAgIDAuNTE2ODAyXSBpbnN0YWxsaW5nIFhl
biB0aW1lciBmb3IgQ1BVIDIKWyAgICAwLjUyMDA2Nl0gICMyY3B1IDIgc3BpbmxvY2sgZXZl
bnQgaXJxIDY1ClsgICAgMC42MjM0NTFdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUg
MwpbICAgIDAuNjI2NzM0XSAgIzNjcHUgMyBzcGlubG9jayBldmVudCBpcnEgNzEKWyAgICAw
LjcyNjcwMV0geDg2OiBCb290ZWQgdXAgMSBub2RlLCA0IENQVXMKWyAgICAwLjczMDAxMF0g
c21wYm9vdDogVG90YWwgb2YgNCBwcm9jZXNzb3JzIGFjdGl2YXRlZCAoMjU2MzIuMzIgQm9n
b01JUFMpClsgICAgMC43MzY4MDNdIGRldnRtcGZzOiBpbml0aWFsaXplZApbICAgIDAuNzQw
Mjg2XSB4b3I6IG1lYXN1cmluZyBzb2Z0d2FyZSBjaGVja3N1bSBzcGVlZApbICAgIDAuNzc2
Njc0XSAgICBwcmVmZXRjaDY0LXNzZTogICA4MjQuNDAwIE1CL3NlYwpbICAgIDAuODEzMzM5
XSAgICBnZW5lcmljX3NzZTogICA4MzcuNjAwIE1CL3NlYwpbICAgIDAuODE2Njc1XSB4b3I6
IHVzaW5nIGZ1bmN0aW9uOiBnZW5lcmljX3NzZSAoODM3LjYwMCBNQi9zZWMpClsgICAgMC44
MjAxMjFdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKWyAgICAwLjgyMzUx
NF0geGVuYnVzOiB4c19yZXNldF93YXRjaGVzIGZhaWxlZDogLTM4ClsgICAgMC44NDY3MTdd
IGNwdWlkbGU6IHVzaW5nIGdvdmVybm9yIGxhZGRlcgpbICAgIDAuODc2Njc1XSBjcHVpZGxl
OiB1c2luZyBnb3Zlcm5vciBtZW51ClsgICAgMC44OTI2NjVdIEFDUEk6IGJ1cyB0eXBlIFBD
SSByZWdpc3RlcmVkClsgICAgMC45MDMzNDRdIGFjcGlwaHA6IEFDUEkgSG90IFBsdWcgUENJ
IENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246IDAuNQpbICAgIDAuOTIwNjMwXSBQQ0k6IFVz
aW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBiYXNlIGFjY2VzcwpbICAgIDAuOTMzMzQw
XSBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBleHRlbmRlZCBhY2Nlc3MK
WyAgICAxLjAyMzM1MV0gcmFpZDY6IHNzZTJ4MSAgICAyNjM5IE1CL3MKWyAgICAxLjA4MzM0
NF0gcmFpZDY6IHNzZTJ4MiAgICAzNjU4IE1CL3MKWyAgICAxLjE0MzM1Nl0gcmFpZDY6IHNz
ZTJ4NCAgICAzNjY0IE1CL3MKWyAgICAxLjE0NjY3N10gcmFpZDY6IHVzaW5nIGFsZ29yaXRo
bSBzc2UyeDQgKDM2NjQgTUIvcykKWyAgICAxLjE1MDAxMF0gcmFpZDY6IHVzaW5nIGludHgx
IHJlY292ZXJ5IGFsZ29yaXRobQpbICAgIDEuMTUzNDEyXSBBQ1BJOiBBZGRlZCBfT1NJKE1v
ZHVsZSBEZXZpY2UpClsgICAgMS4xNTY2OTFdIEFDUEk6IEFkZGVkIF9PU0koUHJvY2Vzc29y
IERldmljZSkKWyAgICAxLjE2MDAwOV0gQUNQSTogQWRkZWQgX09TSSgzLjAgX1NDUCBFeHRl
bnNpb25zKQpbICAgIDEuMTYzMzQyXSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBBZ2dy
ZWdhdG9yIERldmljZSkKWyAgICAxLjE3NzYwNl0gQUNQSTogSW50ZXJwcmV0ZXIgZW5hYmxl
ZApbICAgIDEuMTgwMDEwXSBBQ1BJOiAoc3VwcG9ydHMgUzAgUzUpClsgICAgMS4xODMzNDJd
IEFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0IHJvdXRpbmcKWyAgICAxLjE4Njcy
NF0gUENJOiBVc2luZyBob3N0IGJyaWRnZSB3aW5kb3dzIGZyb20gQUNQSTsgaWYgbmVjZXNz
YXJ5LCB1c2UgInBjaT1ub2NycyIgYW5kIHJlcG9ydCBhIGJ1ZwpbICAgIDEuMjE0MTExXSBB
Q1BJOiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkK
WyAgICAxLjIxNjY5NF0gYWNwaSBQTlAwQTAzOjAwOiBfT1NDOiBPUyBzdXBwb3J0cyBbRXh0
ZW5kZWRDb25maWcgQVNQTSBDbG9ja1BNIFNlZ21lbnRzIE1TSV0KWyAgICAxLjIyMDAyOV0g
YWNwaSBQTlAwQTAzOjAwOiBfT1NDIGZhaWxlZCAoQUVfTk9UX0ZPVU5EKTsgZGlzYWJsaW5n
IEFTUE0KWyAgICAxLjIyNDI5MF0gYWNwaXBocDogU2xvdCBbM10gcmVnaXN0ZXJlZApbICAg
IDEuMjI2Nzk4XSBhY3BpcGhwOiBTbG90IFs0XSByZWdpc3RlcmVkClsgICAgMS4yMzAxODdd
IGFjcGlwaHA6IFNsb3QgWzVdIHJlZ2lzdGVyZWQKWyAgICAxLjIzMzQ1NV0gYWNwaXBocDog
U2xvdCBbNl0gcmVnaXN0ZXJlZApbICAgIDEuMjM2ODA1XSBhY3BpcGhwOiBTbG90IFs3XSBy
ZWdpc3RlcmVkClsgICAgMS4yNDAxNTZdIGFjcGlwaHA6IFNsb3QgWzhdIHJlZ2lzdGVyZWQK
WyAgICAxLjI0MzQ0MV0gYWNwaXBocDogU2xvdCBbOV0gcmVnaXN0ZXJlZApbICAgIDEuMjQ2
NzgyXSBhY3BpcGhwOiBTbG90IFsxMF0gcmVnaXN0ZXJlZApbICAgIDEuMjUwMTI1XSBhY3Bp
cGhwOiBTbG90IFsxMV0gcmVnaXN0ZXJlZApbICAgIDEuMjUzNDM1XSBhY3BpcGhwOiBTbG90
IFsxMl0gcmVnaXN0ZXJlZApbICAgIDEuMjU2ODExXSBhY3BpcGhwOiBTbG90IFsxM10gcmVn
aXN0ZXJlZApbICAgIDEuMjYwMTI1XSBhY3BpcGhwOiBTbG90IFsxNF0gcmVnaXN0ZXJlZApb
ICAgIDEuMjYzNDU2XSBhY3BpcGhwOiBTbG90IFsxNV0gcmVnaXN0ZXJlZApbICAgIDEuMjY2
NzkyXSBhY3BpcGhwOiBTbG90IFsxNl0gcmVnaXN0ZXJlZApbICAgIDEuMjcwMTI3XSBhY3Bp
cGhwOiBTbG90IFsxN10gcmVnaXN0ZXJlZApbICAgIDEuMjczNDQzXSBhY3BpcGhwOiBTbG90
IFsxOF0gcmVnaXN0ZXJlZApbICAgIDEuMjc2ODI0XSBhY3BpcGhwOiBTbG90IFsxOV0gcmVn
aXN0ZXJlZApbICAgIDEuMjgwMTI4XSBhY3BpcGhwOiBTbG90IFsyMF0gcmVnaXN0ZXJlZApb
ICAgIDEuMjgzNDY5XSBhY3BpcGhwOiBTbG90IFsyMV0gcmVnaXN0ZXJlZApbICAgIDEuMjg2
ODE3XSBhY3BpcGhwOiBTbG90IFsyMl0gcmVnaXN0ZXJlZApbICAgIDEuMjkwMTA5XSBhY3Bp
cGhwOiBTbG90IFsyM10gcmVnaXN0ZXJlZApbICAgIDEuMjkzNDQ1XSBhY3BpcGhwOiBTbG90
IFsyNF0gcmVnaXN0ZXJlZApbICAgIDEuMjk2Nzg5XSBhY3BpcGhwOiBTbG90IFsyNV0gcmVn
aXN0ZXJlZApbICAgIDEuMzAwMTM2XSBhY3BpcGhwOiBTbG90IFsyNl0gcmVnaXN0ZXJlZApb
ICAgIDEuMzAzNTM1XSBhY3BpcGhwOiBTbG90IFsyN10gcmVnaXN0ZXJlZApbICAgIDEuMzA2
ODgwXSBhY3BpcGhwOiBTbG90IFsyOF0gcmVnaXN0ZXJlZApbICAgIDEuMzEwMTQ5XSBhY3Bp
cGhwOiBTbG90IFsyOV0gcmVnaXN0ZXJlZApbICAgIDEuMzEzNDMzXSBhY3BpcGhwOiBTbG90
IFszMF0gcmVnaXN0ZXJlZApbICAgIDEuMzE2Nzc0XSBhY3BpcGhwOiBTbG90IFszMV0gcmVn
aXN0ZXJlZApbICAgIDEuMzIwMDg5XSBQQ0kgaG9zdCBicmlkZ2UgdG8gYnVzIDAwMDA6MDAK
WyAgICAxLjMyMzM0Ml0gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbYnVz
IDAwLWZmXQpbICAgIDEuMzI2Njc3XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291
cmNlIFtpbyAgMHgwMDAwLTB4MGNmN10KWyAgICAxLjMzMDAxMV0gcGNpX2J1cyAwMDAwOjAw
OiByb290IGJ1cyByZXNvdXJjZSBbaW8gIDB4MGQwMC0weGZmZmZdClsgICAgMS4zMzMzNDFd
IHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW21lbSAweDAwMGEwMDAwLTB4
MDAwYmZmZmZdClsgICAgMS4zMzY2NzddIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVz
b3VyY2UgW21lbSAweGYwMDAwMDAwLTB4ZmJmZmZmZmZdClsgICAgMS4zNDAzMjZdIHBjaSAw
MDAwOjAwOjAwLjA6IFs4MDg2OjEyMzddIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAKWyAgICAx
LjM0NDgzNl0gcGNpIDAwMDA6MDA6MDEuMDogWzgwODY6NzAwMF0gdHlwZSAwMCBjbGFzcyAw
eDA2MDEwMApbICAgIDEuMzQ4NjMwXSBwY2kgMDAwMDowMDowMS4xOiBbODA4Njo3MDEwXSB0
eXBlIDAwIGNsYXNzIDB4MDEwMTgwClsgICAgMS4zNjU2MzldIHBjaSAwMDAwOjAwOjAxLjE6
IHJlZyAweDIwOiBbaW8gIDB4YzE2MC0weGMxNmZdClsgICAgMS4zNzI0ODRdIHBjaSAwMDAw
OjAwOjAxLjE6IGxlZ2FjeSBJREUgcXVpcms6IHJlZyAweDEwOiBbaW8gIDB4MDFmMC0weDAx
ZjddClsgICAgMS4zNzMzMzldIHBjaSAwMDAwOjAwOjAxLjE6IGxlZ2FjeSBJREUgcXVpcms6
IHJlZyAweDE0OiBbaW8gIDB4MDNmNl0KWyAgICAxLjM3NjY3NF0gcGNpIDAwMDA6MDA6MDEu
MTogbGVnYWN5IElERSBxdWlyazogcmVnIDB4MTg6IFtpbyAgMHgwMTcwLTB4MDE3N10KWyAg
ICAxLjM4MDAxMF0gcGNpIDAwMDA6MDA6MDEuMTogbGVnYWN5IElERSBxdWlyazogcmVnIDB4
MWM6IFtpbyAgMHgwMzc2XQpbICAgIDEuMzg0MjY2XSBwY2kgMDAwMDowMDowMS4yOiBbODA4
Njo3MDIwXSB0eXBlIDAwIGNsYXNzIDB4MGMwMzAwClsgICAgMS40MDAwMTJdIHBjaSAwMDAw
OjAwOjAxLjI6IHJlZyAweDIwOiBbaW8gIDB4YzE0MC0weGMxNWZdClsgICAgMS40MDc4Mjld
IHBjaSAwMDAwOjAwOjAxLjM6IFs4MDg2OjcxMTNdIHR5cGUgMDAgY2xhc3MgMHgwNjgwMDAK
WyAgICAxLjQxMTIyOV0gcGNpIDAwMDA6MDA6MDEuMzogcXVpcms6IFtpbyAgMHhiMDAwLTB4
YjAzZl0gY2xhaW1lZCBieSBQSUlYNCBBQ1BJClsgICAgMS40MTM0OTVdIHBjaSAwMDAwOjAw
OjAxLjM6IHF1aXJrOiBbaW8gIDB4YjEwMC0weGIxMGZdIGNsYWltZWQgYnkgUElJWDQgU01C
ClsgICAgMS40MTgyMDldIHBjaSAwMDAwOjAwOjAyLjA6IFs1ODUzOjAwMDFdIHR5cGUgMDAg
Y2xhc3MgMHhmZjgwMDAKWyAgICAxLjQyMzM2OF0gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDB4
MTA6IFtpbyAgMHhjMDAwLTB4YzBmZl0KWyAgICAxLjQzMDAwN10gcGNpIDAwMDA6MDA6MDIu
MDogcmVnIDB4MTQ6IFttZW0gMHhmMjAwMDAwMC0weGYyZmZmZmZmIHByZWZdClsgICAgMS40
NjQ1NTRdIHBjaSAwMDAwOjAwOjAzLjA6IFsxMDEzOjAwYjhdIHR5cGUgMDAgY2xhc3MgMHgw
MzAwMDAKWyAgICAxLjQ3MDAzNF0gcGNpIDAwMDA6MDA6MDMuMDogcmVnIDB4MTA6IFttZW0g
MHhmMDAwMDAwMC0weGYxZmZmZmZmIHByZWZdClsgICAgMS40NzY3MDBdIHBjaSAwMDAwOjAw
OjAzLjA6IHJlZyAweDE0OiBbbWVtIDB4ZjMyNzIwMDAtMHhmMzI3MmZmZl0KWyAgICAxLjUx
MDAzOF0gcGNpIDAwMDA6MDA6MDMuMDogcmVnIDB4MzA6IFttZW0gMHhmMzI2MDAwMC0weGYz
MjZmZmZmIHByZWZdClsgICAgMS41MTIwMzBdIHBjaSAwMDAwOjAwOjA1LjA6IFsxMDMzOjAx
OTRdIHR5cGUgMDAgY2xhc3MgMHgwYzAzMzAKWyAgICAxLjUyMDAyMl0gcGNpIDAwMDA6MDA6
MDUuMDogcmVnIDB4MTA6IFttZW0gMHhmMzI3MDAwMC0weGYzMjcxZmZmIDY0Yml0XQpbICAg
IDEuNTU4MjQyXSBwY2kgMDAwMDowMDowNi4wOiBbMTRmMTo4MjEwXSB0eXBlIDAwIGNsYXNz
IDB4MDQwMDAwClsgICAgMS41NjMzNzddIHBjaSAwMDAwOjAwOjA2LjA6IHJlZyAweDEwOiBb
bWVtIDB4ZjMwMDAwMDAtMHhmMzFmZmZmZiA2NGJpdF0KWyAgICAxLjYwMTE0Ml0gcGNpIDAw
MDA6MDA6MDYuMDogc3VwcG9ydHMgRDEgRDIKWyAgICAxLjYwNDg3M10gQUNQSTogUENJIElu
dGVycnVwdCBMaW5rIFtMTktBXSAoSVJRcyAqNSAxMCAxMSkKWyAgICAxLjYxMzc4NV0gQUNQ
STogUENJIEludGVycnVwdCBMaW5rIFtMTktCXSAoSVJRcyA1ICoxMCAxMSkKWyAgICAxLjYy
MzgxNl0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyA1IDEwICoxMSkK
WyAgICAxLjYzMzgxMF0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyAq
NSAxMCAxMSkKWyAgICAxLjY0NzUyNV0gQUNQSTogRW5hYmxlZCAyIEdQRXMgaW4gYmxvY2sg
MDAgdG8gMEYKWyAgICAxLjY1MDA4M10geGVuOmJhbGxvb246IEluaXRpYWxpc2luZyBiYWxs
b29uIGRyaXZlcgpbICAgIDEuNjU2NzE3XSB4ZW5fYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJh
bGxvb24gZHJpdmVyClsgICAgMS42NzAxNzldIHZnYWFyYjogc2V0dGluZyBhcyBib290IGRl
dmljZTogUENJOjAwMDA6MDA6MDMuMApbICAgIDEuNjczMzMzXSB2Z2FhcmI6IGRldmljZSBh
ZGRlZDogUENJOjAwMDA6MDA6MDMuMCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nr
cz1ub25lClsgICAgMS42NzMzNDRdIHZnYWFyYjogbG9hZGVkClsgICAgMS42NzY2NzddIHZn
YWFyYjogYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowMDowMy4wClsgICAgMS42ODAx
MTVdIFNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkClsgICAgMS42ODMzNzRdIGxpYmF0YSB2
ZXJzaW9uIDMuMDAgbG9hZGVkLgpbICAgIDEuNjgzNDI2XSBBQ1BJOiBidXMgdHlwZSBVU0Ig
cmVnaXN0ZXJlZApbICAgIDEuNjg2NzIzXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRl
cmZhY2UgZHJpdmVyIHVzYmZzClsgICAgMS42OTAwMzRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGludGVyZmFjZSBkcml2ZXIgaHViClsgICAgMS42OTMzOTZdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGRldmljZSBkcml2ZXIgdXNiClsgICAgMS42OTY3MjhdIExpbnV4IHZpZGVv
IGNhcHR1cmUgaW50ZXJmYWNlOiB2Mi4wMApbICAgIDEuNzAwMDQwXSBwcHNfY29yZTogTGlu
dXhQUFMgQVBJIHZlci4gMSByZWdpc3RlcmVkClsgICAgMS43MDMzNDJdIHBwc19jb3JlOiBT
b2Z0d2FyZSB2ZXIuIDUuMy42IC0gQ29weXJpZ2h0IDIwMDUtMjAwNyBSb2RvbGZvIEdpb21l
dHRpIDxnaW9tZXR0aUBsaW51eC5pdD4KWyAgICAxLjcwNjY5M10gUFRQIGNsb2NrIHN1cHBv
cnQgcmVnaXN0ZXJlZApbICAgIDEuNzEwMDcwXSBBZHZhbmNlZCBMaW51eCBTb3VuZCBBcmNo
aXRlY3R1cmUgRHJpdmVyIEluaXRpYWxpemVkLgpbICAgIDEuNzEzMzQ2XSBQQ0k6IFVzaW5n
IEFDUEkgZm9yIElSUSByb3V0aW5nClsgICAgMS43MTY2NzddIFBDSTogcGNpX2NhY2hlX2xp
bmVfc2l6ZSBzZXQgdG8gNjQgYnl0ZXMKWyAgICAxLjcxODAxMV0gZTgyMDogcmVzZXJ2ZSBS
QU0gYnVmZmVyIFttZW0gMHgwMDA5ZmMwMC0weDAwMDlmZmZmXQpbICAgIDEuNzE4MDE0XSBl
ODIwOiByZXNlcnZlIFJBTSBidWZmZXIgW21lbSAweDNmN2ZlMDAwLTB4M2ZmZmZmZmZdClsg
ICAgMS43MTgxNjddIEJsdWV0b290aDogQ29yZSB2ZXIgMi4xOQpbICAgIDEuNzIwMDI4XSBO
RVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDMxClsgICAgMS43MjMzNDJdIEJsdWV0
b290aDogSENJIGRldmljZSBhbmQgY29ubmVjdGlvbiBtYW5hZ2VyIGluaXRpYWxpemVkClsg
ICAgMS43MjY2OTZdIEJsdWV0b290aDogSENJIHNvY2tldCBsYXllciBpbml0aWFsaXplZApb
ICAgIDEuNzMwMDMyXSBCbHVldG9vdGg6IEwyQ0FQIHNvY2tldCBsYXllciBpbml0aWFsaXpl
ZApbICAgIDEuNzMzMzYzXSBCbHVldG9vdGg6IFNDTyBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6
ZWQKWyAgICAxLjczNjc3NF0gSFBFVDogMyB0aW1lcnMgaW4gdG90YWwsIDAgdGltZXJzIHdp
bGwgYmUgdXNlZCBmb3IgcGVyLWNwdSB0aW1lcgpbICAgIDEuNzQwMDIyXSBocGV0MDogYXQg
TU1JTyAweGZlZDAwMDAwLCBJUlFzIDIsIDgsIDAKWyAgICAxLjc1MDAwNV0gaHBldDA6IDMg
Y29tcGFyYXRvcnMsIDY0LWJpdCA2Mi41MDAwMDAgTUh6IGNvdW50ZXIKWyAgICAxLjc1NTQx
M10gU3dpdGNoZWQgdG8gY2xvY2tzb3VyY2UgeGVuClsgICAgMS43NjQ0NjZdIEZTLUNhY2hl
OiBMb2FkZWQKWyAgICAxLjc3Mjk3MV0gcG5wOiBQblAgQUNQSSBpbml0ClsgICAgMS43ODI0
NzFdIHN5c3RlbSAwMDowMDogW21lbSAweDAwMDAwMDAwLTB4MDAwOWZmZmZdIGNvdWxkIG5v
dCBiZSByZXNlcnZlZApbICAgIDEuODAxMzQ2XSBzeXN0ZW0gMDA6MDA6IFBsdWcgYW5kIFBs
YXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3RpdmUpClsgICAgMS44MDE0NDNdIHN5
c3RlbSAwMDowMTogW2lvICAweDA4YTAtMHgwOGEzXSBoYXMgYmVlbiByZXNlcnZlZApbICAg
IDEuODIzNDAxXSBzeXN0ZW0gMDA6MDE6IFtpbyAgMHgwY2MwLTB4MGNjZl0gaGFzIGJlZW4g
cmVzZXJ2ZWQKWyAgICAxLjgzOTY3Nl0gc3lzdGVtIDAwOjAxOiBbaW8gIDB4MDRkMC0weDA0
ZDFdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMS44NTYzMzFdIHN5c3RlbSAwMDowMTogUGx1
ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAxLjg1
NjM2OF0geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9OCAoZ3NpPTgpClsgICAgMS44NTYzOTNd
IHBucCAwMDowMjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBiMDAgKGFj
dGl2ZSkKWyAgICAxLjg1NjQzMF0geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTIgKGdzaT0x
MikKWyAgICAxLjg1NjQ1N10gcG5wIDAwOjAzOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNl
LCBJRHMgUE5QMGYxMyAoYWN0aXZlKQpbICAgIDEuODU2NDg5XSB4ZW46IC0tPiBwaXJxPTE4
IC0+IGlycT0xIChnc2k9MSkKWyAgICAxLjg1NjUwNV0gcG5wIDAwOjA0OiBQbHVnIGFuZCBQ
bGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDMwMyBQTlAwMzBiIChhY3RpdmUpClsgICAgMS44
NTY1MjddIHhlbjogLS0+IHBpcnE9MTkgLT4gaXJxPTYgKGdzaT02KQpbICAgIDEuODU2NTMw
XSBwbnAgMDA6MDU6IFtkbWEgMl0KWyAgICAxLjg1NjU0Nl0gcG5wIDAwOjA1OiBQbHVnIGFu
ZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDcwMCAoYWN0aXZlKQpbICAgIDEuODU2NTc2
XSB4ZW46IC0tPiBwaXJxPTIwIC0+IGlycT00IChnc2k9NCkKWyAgICAxLjg1NjU5Ml0gcG5w
IDAwOjA2OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDUwMSAoYWN0aXZl
KQpbICAgIDEuODU2NjUxXSBzeXN0ZW0gMDA6MDc6IFtpbyAgMHhhZTAwLTB4YWUwZl0gaGFz
IGJlZW4gcmVzZXJ2ZWQKWyAgICAxLjg3MzA0Ml0gc3lzdGVtIDAwOjA3OiBbaW8gIDB4YjA0
NC0weGIwNDddIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMS44ODk3OTFdIHN5c3RlbSAwMDow
NzogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAg
ICAxLjg5MDI2NF0gcG5wOiBQblAgQUNQSTogZm91bmQgOCBkZXZpY2VzClsgICAgMS45MTA4
MjFdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNCBbaW8gIDB4MDAwMC0weDBjZjddClsg
ICAgMS45MTA4MjRdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNSBbaW8gIDB4MGQwMC0w
eGZmZmZdClsgICAgMS45MTA4MjZdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNiBbbWVt
IDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0KWyAgICAxLjkxMDgyOF0gcGNpX2J1cyAwMDAwOjAw
OiByZXNvdXJjZSA3IFttZW0gMHhmMDAwMDAwMC0weGZiZmZmZmZmXQpbICAgIDEuOTEwODU5
XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDIKWyAgICAxLjkyMjg5MF0gVENQ
IGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogODE5MiAob3JkZXI6IDQsIDY1NTM2
IGJ5dGVzKQpbICAgIDEuOTQxNTY2XSBUQ1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDgx
OTIgKG9yZGVyOiA1LCAxMzEwNzIgYnl0ZXMpClsgICAgMS45NTg1MjZdIFRDUDogSGFzaCB0
YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgODE5MiBiaW5kIDgxOTIpClsgICAgMS45
NzUwNjVdIFRDUDogcmVubyByZWdpc3RlcmVkClsgICAgMS45ODQwNzJdIFVEUCBoYXNoIHRh
YmxlIGVudHJpZXM6IDUxMiAob3JkZXI6IDIsIDE2Mzg0IGJ5dGVzKQpbICAgIDEuOTk5ODYy
XSBVRFAtTGl0ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMiAob3JkZXI6IDIsIDE2Mzg0IGJ5
dGVzKQpbICAgIDIuMDE2NDM3XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEK
WyAgICAyLjAzMTIwM10gcGNpIDAwMDA6MDA6MDAuMDogTGltaXRpbmcgZGlyZWN0IFBDSS9Q
Q0kgdHJhbnNmZXJzClsgICAgMi4wNTE0NjRdIHBjaSAwMDAwOjAwOjAxLjA6IFBJSVgzOiBF
bmFibGluZyBQYXNzaXZlIFJlbGVhc2UKWyAgICAyLjA3MjEzNV0gcGNpIDAwMDA6MDA6MDEu
MDogQWN0aXZhdGluZyBJU0EgRE1BIGhhbmcgd29ya2Fyb3VuZHMKWyAgICAyLjA4OTAxMl0g
eGVuOiAtLT4gcGlycT0yMSAtPiBpcnE9MjMgKGdzaT0yMykKWyAgICAyLjA5MjcxN10gcGNp
IDAwMDA6MDA6MDMuMDogVmlkZW8gZGV2aWNlIHdpdGggc2hhZG93ZWQgUk9NClsgICAgMi4w
OTMxNzddIHhlbjogLS0+IHBpcnE9MzcgLT4gaXJxPTM2IChnc2k9MzYpClsgICAgMi4wOTYx
MjJdIFBDSTogQ0xTIDAgYnl0ZXMsIGRlZmF1bHQgNjQKWyAgICAyLjA5NjE3Ml0gVHJ5aW5n
IHRvIHVucGFjayByb290ZnMgaW1hZ2UgYXMgaW5pdHJhbWZzLi4uClsgICAgMi4xNDA1MTdd
IEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogMTg3MksgKGZmZmY4ODAwMzdjNDgwMDAgLSBmZmZm
ODgwMDM3ZTFjMDAwKQpbICAgIDIuMTYxMjgxXSBTY2FubmluZyBmb3IgbG93IG1lbW9yeSBj
b3JydXB0aW9uIGV2ZXJ5IDYwIHNlY29uZHMKWyAgICAyLjE3OTYzNl0gc2hhMV9zc3NlMzog
TmVpdGhlciBBVlggbm9yIEFWWDIgbm9yIFNTU0UzIGlzIGF2YWlsYWJsZS91c2FibGUuClsg
ICAgMi4xOTgwNjRdIEFWWCBvciBBRVMtTkkgaW5zdHJ1Y3Rpb25zIGFyZSBub3QgZGV0ZWN0
ZWQuClsgICAgMi4yMTI1NzddIEFWWCBpbnN0cnVjdGlvbnMgYXJlIG5vdCBkZXRlY3RlZC4K
WyAgICAyLjIyNDgzM10gQVZYIGluc3RydWN0aW9ucyBhcmUgbm90IGRldGVjdGVkLgpbICAg
IDIuMjM3MDg5XSBmdXRleCBoYXNoIHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiA1LCAx
MzEwNzIgYnl0ZXMpClsgICAgMi4yNTI5NDBdIGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0bGlu
ayBzdWJzeXMgKGRpc2FibGVkKQpbICAgIDIuMjY3NDYyXSBhdWRpdDogdHlwZT0yMDAwIGF1
ZGl0KDE0MTYzMTYxMzYuOTcyOjEpOiBpbml0aWFsaXplZApbICAgIDIuMjgzNTE5XSBIdWdl
VExCIHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcwpb
ICAgIDIuMzAxOTU1XSBWRlM6IERpc2sgcXVvdGFzIGRxdW90XzYuNS4yClsgICAgMi4zMTI2
MTNdIERxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTEyIChvcmRlciAwLCA0MDk2
IGJ5dGVzKQpbICAgIDIuMzMwNzE0XSBudGZzOiBkcml2ZXIgMi4xLjMxIFtGbGFnczogUi9X
XS4KWyAgICAyLjM0Mjk2OF0gZnVzZSBpbml0IChBUEkgdmVyc2lvbiA3LjIzKQpbICAgIDIu
MzU2NzAzXSBnZnMyOiBHRlMyIGluc3RhbGxlZApbICAgIDIuMzY2MDgwXSBjZXBoOiBsb2Fk
ZWQgKG1kcyBwcm90byAzMikKWyAgICAyLjM3ODQ4OF0gbXNnbW5pIGhhcyBiZWVuIHNldCB0
byAxOTU5ClsgICAgMi4zOTMxMTFdIGJvdW5jZTogcG9vbCBzaXplOiA2NCBwYWdlcwpbICAg
IDIuNDA0MjU5XSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNp
b24gMC40IGxvYWRlZCAobWFqb3IgMjUwKQpbICAgIDIuNDI2ODU4XSBpbyBzY2hlZHVsZXIg
bm9vcCByZWdpc3RlcmVkClsgICAgMi40Mzc4ODddIGlvIHNjaGVkdWxlciBkZWFkbGluZSBy
ZWdpc3RlcmVkClsgICAgMi40NTIxMzVdIGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAo
ZGVmYXVsdCkKWyAgICAyLjQ2NjM3MF0gY3JjMzI6IENSQ19MRV9CSVRTID0gNjQsIENSQ19C
RSBCSVRTID0gNjQKWyAgICAyLjQ4MjYzM10gY3JjMzI6IHNlbGYgdGVzdHMgcGFzc2VkLCBw
cm9jZXNzZWQgMjI1OTQ0IGJ5dGVzIGluIDEyMjk2MSBuc2VjClsgICAgMi41MDMwNzNdIGNy
YzMyYzogQ1JDX0xFX0JJVFMgPSA2NApbICAgIDIuNTE0MzQwXSBjcmMzMmM6IHNlbGYgdGVz
dHMgcGFzc2VkLCBwcm9jZXNzZWQgMjI1OTQ0IGJ5dGVzIGluIDYxNDQxIG5zZWMKWyAgICAy
LjU0NDcxMF0gY3JjMzJfY29tYmluZTogODM3MyBzZWxmIHRlc3RzIHBhc3NlZApbICAgIDIu
NTY5OTA2XSBjcmMzMmNfY29tYmluZTogODM3MyBzZWxmIHRlc3RzIHBhc3NlZApbICAgIDIu
NTg1NjE1XSBwY2lfaG90cGx1ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAu
NQpbICAgIDIuNjAyOTcxXSBwY2llaHA6IFBDSSBFeHByZXNzIEhvdCBQbHVnIENvbnRyb2xs
ZXIgRHJpdmVyIHZlcnNpb246IDAuNApbICAgIDIuNjIyNDIyXSBjcGNpaHBfenQ1NTUwOiBa
VDU1NTAgQ29tcGFjdFBDSSBIb3QgUGx1ZyBEcml2ZXIgdmVyc2lvbjogMC4yClsgICAgMi42
NDE2MjRdIGNwY2locF9nZW5lcmljOiBHZW5lcmljIHBvcnQgSS9PIENvbXBhY3RQQ0kgSG90
IFBsdWcgRHJpdmVyIHZlcnNpb246IDAuMQpbICAgIDIuNjYyMDAxXSBjcGNpaHBfZ2VuZXJp
Yzogbm90IGNvbmZpZ3VyZWQsIGRpc2FibGluZy4KWyAgICAyLjY3NzYzNV0gc2hwY2hwOiBT
dGFuZGFyZCBIb3QgUGx1ZyBQQ0kgQ29udHJvbGxlciBEcml2ZXIgdmVyc2lvbjogMC40Clsg
ICAgMi42OTU4NjhdIGFjcGlwaHBfaWJtOiBpYm1fYWNwaXBocF9pbml0OiBhY3BpX3dhbGtf
bmFtZXNwYWNlIGZhaWxlZApbICAgIDIuNzE0MzgzXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5l
dyBpbnRlcmZhY2UgZHJpdmVyIHVkbGZiClsgICAgMi43Mjg2NTddIGlucHV0OiBQb3dlciBC
dXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQw
ClsgICAgMi43NDcyNjVdIEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0KWyAgICAyLjc1ODY3
NV0gaW5wdXQ6IFNsZWVwIEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhTTFBC
TjowMC9pbnB1dC9pbnB1dDEKWyAgICAyLjc3Nzc1NV0gQUNQSTogU2xlZXAgQnV0dG9uIFtT
TFBGXQpbICAgIDIuNzg3ODYzXSB4ZW46eGVuX2V2dGNobjogRXZlbnQtY2hhbm5lbCBkZXZp
Y2UgaW5zdGFsbGVkClsgICAgMi44MDMwMDRdIHhlbjogLS0+IHBpcnE9MjIgLT4gaXJxPTI0
IChnc2k9MjQpClsgICAgMi44MDMxODBdIHhlbjpncmFudF90YWJsZTogR3JhbnQgdGFibGVz
IHVzaW5nIHZlcnNpb24gMSBsYXlvdXQKWyAgICAyLjgyMDYyOV0gR3JhbnQgdGFibGUgaW5p
dGlhbGl6ZWQKWyAgICAyLjgzMTI5OF0gU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBw
b3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZApbICAgIDIuODk1MDUyXSBzZXJpYWwgMDA6MDY6
IHR0eVMwIGF0IEkvTyAweDNmOCAoaXJxID0gNCwgYmFzZV9iYXVkID0gMTE1MjAwKSBpcyBh
IDE2NTUwQQpbICAgIDIuOTE4MDEzXSBMaW51eCBhZ3BnYXJ0IGludGVyZmFjZSB2MC4xMDMK
WyAgICAyLjkyOTY1OV0gSGFuZ2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sgdGltZXIgMC45
LjEgKHRpY2sgaXMgMTgwIHNlY29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRzKS4KWyAgICAy
Ljk1NDc3N10gW2RybV0gSW5pdGlhbGl6ZWQgZHJtIDEuMS4wIDIwMDYwODEwClsgICAgMi45
NjgxODFdIFtkcm1dIFZHQUNPTiBkaXNhYmxlIHJhZGVvbiBrZXJuZWwgbW9kZXNldHRpbmcu
ClsgICAgMi45ODQwMDhdIFtkcm06cmFkZW9uX2luaXRdICpFUlJPUiogTm8gVU1TIHN1cHBv
cnQgaW4gcmFkZW9uIG1vZHVsZSEKWyAgICAzLjAwMzkyNF0gYnJkOiBtb2R1bGUgbG9hZGVk
ClsgICAgMy4wMTQyMjZdIGxvb3A6IG1vZHVsZSBsb2FkZWQKWyAgICAzLjAyOTUwOV0gdHVu
OiBVbml2ZXJzYWwgVFVOL1RBUCBkZXZpY2UgZHJpdmVyLCAxLjYKWyAgICAzLjAzODY4Ml0g
YmxrZnJvbnQ6IHh2ZGE6IGZsdXNoIGRpc2tjYWNoZTogZW5hYmxlZDsgcGVyc2lzdGVudCBn
cmFudHM6IGVuYWJsZWQ7IGluZGlyZWN0IGRlc2NyaXB0b3JzOiBlbmFibGVkOwpbICAgIDMu
MDc0MzIyXSB0dW46IChDKSAxOTk5LTIwMDQgTWF4IEtyYXNueWFuc2t5IDxtYXhrQHF1YWxj
b21tLmNvbT4KWyAgICAzLjA5MDkzOV0gZTEwMDA6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdv
cmsgRHJpdmVyIC0gdmVyc2lvbiA3LjMuMjEtazgtTkFQSQpbICAgIDMuMTE2MDU4XSBlMTAw
MDogQ29weXJpZ2h0IChjKSAxOTk5LTIwMDYgSW50ZWwgQ29ycG9yYXRpb24uClsgICAgMy4x
MzM5MjBdIGUxMDAwZTogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBEcml2ZXIgLSAyLjMu
Mi1rClsgICAgMy4xMzc1ODJdICB4dmRhOiB4dmRhMSB4dmRhMgpbICAgIDMuMTM5MzE3XSBi
bGtmcm9udDogeHZkYjogZmx1c2ggZGlza2NhY2hlOiBlbmFibGVkOyBwZXJzaXN0ZW50IGdy
YW50czogZW5hYmxlZDsgaW5kaXJlY3QgZGVzY3JpcHRvcnM6IGVuYWJsZWQ7ClsgICAgMy4x
NDgxODhdICB4dmRiOiB1bmtub3duIHBhcnRpdGlvbiB0YWJsZQpbICAgIDMuMTk4NTk0XSBl
MTAwMGU6IENvcHlyaWdodChjKSAxOTk5IC0gMjAxNCBJbnRlbCBDb3Jwb3JhdGlvbi4KWyAg
ICAzLjIxNjIxNV0gaWdiOiBJbnRlbChSKSBHaWdhYml0IEV0aGVybmV0IE5ldHdvcmsgRHJp
dmVyIC0gdmVyc2lvbiA1LjIuMTUtawpbICAgIDMuMjM4MDE0XSBpZ2I6IENvcHlyaWdodCAo
YykgMjAwNy0yMDE0IEludGVsIENvcnBvcmF0aW9uLgpbICAgIDMuMjU1NjUxXSBpZ2J2Zjog
SW50ZWwoUikgR2lnYWJpdCBWaXJ0dWFsIEZ1bmN0aW9uIE5ldHdvcmsgRHJpdmVyIC0gdmVy
c2lvbiAyLjAuMi1rClsgICAgMy4yNzg3NTFdIGlnYnZmOiBDb3B5cmlnaHQgKGMpIDIwMDkg
LSAyMDEyIEludGVsIENvcnBvcmF0aW9uLgpbICAgIDMuMjk1MjM2XSB4ZW5fbmV0ZnJvbnQ6
IEluaXRpYWxpc2luZyBYZW4gdmlydHVhbCBldGhlcm5ldCBkcml2ZXIKWyAgICAzLjMxODI1
NV0geGhjaV9oY2QgMDAwMDowMDowNS4wOiB4SENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDMu
MzM0OTI2XSB4aGNpX2hjZCAwMDAwOjAwOjA1LjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs
IGFzc2lnbmVkIGJ1cyBudW1iZXIgMQpbICAgIDMuMzU4ODA4XSB1c2IgdXNiMTogTmV3IFVT
QiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyClsgICAgMy4z
NzYwNjRdIHVzYiB1c2IxOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVj
dD0yLCBTZXJpYWxOdW1iZXI9MQpbICAgIDMuMzk0OTg5XSB1c2IgdXNiMTogUHJvZHVjdDog
eEhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICAzLjQwODg4MF0gdXNiIHVzYjE6IE1hbnVmYWN0
dXJlcjogTGludXggMy4xOC4wLXJjNC0yMDE0MTExNi1zZWN1cml0eS1ub3NuZCsgeGhjaS1o
Y2QKWyAgICAzLjQzMDE2Nl0gdXNiIHVzYjE6IFNlcmlhbE51bWJlcjogMDAwMDowMDowNS4w
ClsgICAgMy40NDQ0NzhdIGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kClsgICAgMy40NTQ4
MzFdIGh1YiAxLTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkClsgICAgMy40NjY0NzZdIHhoY2lf
aGNkIDAwMDA6MDA6MDUuMDogeEhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICAzLjQ4MzQ3Nl0g
eGhjaV9oY2QgMDAwMDowMDowNS4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25l
ZCBidXMgbnVtYmVyIDIKWyAgICAzLjUwNTAyNV0gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNl
IGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMwpbICAgIDMuNTI0NTQ3XSB1
c2IgdXNiMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2Vy
aWFsTnVtYmVyPTEKWyAgICAzLjU0MzgyMF0gdXNiIHVzYjI6IFByb2R1Y3Q6IHhIQ0kgSG9z
dCBDb250cm9sbGVyClsgICAgMy41NTY5MDFdIHVzYiB1c2IyOiBNYW51ZmFjdHVyZXI6IExp
bnV4IDMuMTguMC1yYzQtMjAxNDExMTYtc2VjdXJpdHktbm9zbmQrIHhoY2ktaGNkClsgICAg
My41Nzc5OTldIHVzYiB1c2IyOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MDUuMApbICAgIDMu
NTkwODA1XSBodWIgMi0wOjEuMDogVVNCIGh1YiBmb3VuZApbICAgIDMuNjAxMzc3XSBodWIg
Mi0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApbICAgIDMuNjEyMzAyXSBlaGNpX2hjZDogVVNC
IDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAoRUhDSSkgRHJpdmVyClsgICAgMy42
Mjk0NDddIGVoY2ktcGNpOiBFSENJIFBDSSBwbGF0Zm9ybSBkcml2ZXIKWyAgICAzLjY0MjAz
M10gb2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJp
dmVyClsgICAgMy42NTgyMzldIG9oY2ktcGNpOiBPSENJIFBDSSBwbGF0Zm9ybSBkcml2ZXIK
WyAgICAzLjY3MDcxMV0gdWhjaV9oY2Q6IFVTQiBVbml2ZXJzYWwgSG9zdCBDb250cm9sbGVy
IEludGVyZmFjZSBkcml2ZXIKWyAgICAzLjY4OTk0OV0gdWhjaV9oY2QgMDAwMDowMDowMS4y
OiBVSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDMuNzA0NDE2XSB1aGNpX2hjZCAwMDAwOjAw
OjAxLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMwpb
ICAgIDMuNzI1NDgyXSB1aGNpX2hjZCAwMDAwOjAwOjAxLjI6IGlycSAyMywgaW8gYmFzZSAw
eDAwMDBjMTQwClsgICAgMy43NDMzNzldIHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBmb3Vu
ZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDEKWyAgICAzLjc2NzM0NF0gdXNiIHVz
YjM6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51
bWJlcj0xClsgICAgMy43ODcxMzJdIHVzYiB1c2IzOiBQcm9kdWN0OiBVSENJIEhvc3QgQ29u
dHJvbGxlcgpbICAgIDMuODAwNjAzXSB1c2IgdXNiMzogTWFudWZhY3R1cmVyOiBMaW51eCAz
LjE4LjAtcmM0LTIwMTQxMTE2LXNlY3VyaXR5LW5vc25kKyB1aGNpX2hjZApbICAgIDMuODIy
MzIwXSB1c2IgdXNiMzogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjAxLjIKWyAgICAzLjgzNzY2
NF0gaHViIDMtMDoxLjA6IFVTQiBodWIgZm91bmQKWyAgICAzLjg0OTU0Ml0gaHViIDMtMDox
LjA6IDIgcG9ydHMgZGV0ZWN0ZWQKWyAgICAzLjg2MjE0MV0gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JscApbICAgIDMuODc4NTA5XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdlClsgICAgMy44ODY3
MTNdIHJhbmRvbTogbm9uYmxvY2tpbmcgcG9vbCBpcyBpbml0aWFsaXplZApbICAgIDMuOTMz
MzgzXSB1c2IgMS0yOiBuZXcgbG93LXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIgdXNpbmcg
eGhjaV9oY2QKWyAgICAzLjkzMzYwM10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJm
YWNlIGRyaXZlciB1c2JzZXJpYWwKWyAgICAzLjkzMzYxN10gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBjcDIxMHgKWyAgICAzLjkzMzYzNV0gdXNic2VyaWFs
OiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgY3AyMTB4ClsgICAgMy45MzM2
NTddIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3lwcmVzc19t
OApbICAgIDMuOTMzNjcwXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3Rl
cmVkIGZvciBEZUxvcm1lIEVhcnRobWF0ZSBVU0IKWyAgICAzLjkzMzY3NV0gdXNic2VyaWFs
OiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgSElELT5DT00gUlMyMzIgQWRh
cHRlcgpbICAgIDMuOTMzNjgyXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdp
c3RlcmVkIGZvciBOb2tpYSBDQS00MiBWMiBBZGFwdGVyClsgICAgMy45MzM2OTddIHVzYmNv
cmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgbW9zNzcyMApbICAgIDMuOTMz
NzEwXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3Nj
aGlwIDIgcG9ydCBhZGFwdGVyClsgICAgMy45MzM3MTldIHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGludGVyZmFjZSBkcml2ZXIgbW9zNzg0MApbICAgIDMuOTMzNzMxXSB1c2JzZXJpYWw6
IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3NjaGlwIDc4NDAvNzgyMCBV
U0IgU2VyaWFsIERyaXZlcgpbICAgIDMuOTMzNzY3XSBpODA0MjogUE5QOiBQUy8yIENvbnRy
b2xsZXIgW1BOUDAzMDM6UFMySyxQTlAwZjEzOlBTMk1dIGF0IDB4NjAsMHg2NCBpcnEgMSwx
MgpbICAgIDMuOTQ0NDg3XSBzZXJpbzogaTgwNDIgS0JEIHBvcnQgYXQgMHg2MCwweDY0IGly
cSAxClsgICAgMy45NDQ0OTNdIHNlcmlvOiBpODA0MiBBVVggcG9ydCBhdCAweDYwLDB4NjQg
aXJxIDEyClsgICAgMy45NDQ2NjNdIG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21t
b24gZm9yIGFsbCBtaWNlClsgICAgMy45NDY2MjZdIGlucHV0OiBYZW4gVmlydHVhbCBLZXli
b2FyZCBhcyAvZGV2aWNlcy92aXJ0dWFsL2lucHV0L2lucHV0MwpbICAgIDMuOTQ2NzI2XSBp
bnB1dDogWGVuIFZpcnR1YWwgUG9pbnRlciBhcyAvZGV2aWNlcy92aXJ0dWFsL2lucHV0L2lu
cHV0NApbICAgIDMuOTQ5NjgyXSBpbnB1dDogQVQgVHJhbnNsYXRlZCBTZXQgMiBrZXlib2Fy
ZCBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzAvaW5wdXQvaW5wdXQyClsgICAg
My45NTIwMDhdIHJ0Y19jbW9zIDAwOjAyOiBydGMgY29yZTogcmVnaXN0ZXJlZCBydGNfY21v
cyBhcyBydGMwClsgICAgMy45NTIwNzFdIHJ0Y19jbW9zIDAwOjAyOiBhbGFybXMgdXAgdG8g
b25lIGRheSwgMTE0IGJ5dGVzIG52cmFtLCBocGV0IGlycXMKWyAgICAzLjk1Mjg4OF0gcGlp
eDRfc21idXMgMDAwMDowMDowMS4zOiBTTUJ1cyBIb3N0IENvbnRyb2xsZXIgbm90IGVuYWJs
ZWQhClsgICAgMy45NTMxNDddIGxpcmNfZGV2OiBJUiBSZW1vdGUgQ29udHJvbCBkcml2ZXIg
cmVnaXN0ZXJlZCwgbWFqb3IgMjQ4IApbICAgIDMuOTUzMTQ5XSBJUiBORUMgcHJvdG9jb2wg
aGFuZGxlciBpbml0aWFsaXplZApbICAgIDMuOTUzMTUwXSBJUiBSQzUoeC9zeikgcHJvdG9j
b2wgaGFuZGxlciBpbml0aWFsaXplZApbICAgIDMuOTUzMTUxXSBJUiBSQzYgcHJvdG9jb2wg
aGFuZGxlciBpbml0aWFsaXplZApbICAgIDMuOTUzMTUzXSBJUiBKVkMgcHJvdG9jb2wgaGFu
ZGxlciBpbml0aWFsaXplZApbICAgIDMuOTUzMTU0XSBJUiBTb255IHByb3RvY29sIGhhbmRs
ZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjk1MzE1Nl0gSVIgU0FOWU8gcHJvdG9jb2wgaGFuZGxl
ciBpbml0aWFsaXplZApbICAgIDMuOTUzMTU3XSBJUiBTaGFycCBwcm90b2NvbCBoYW5kbGVy
IGluaXRpYWxpemVkClsgICAgMy45NTMxNThdIElSIE1DRSBLZXlib2FyZC9tb3VzZSBwcm90
b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkClsgICAgMy45NTMxNTldIElSIExJUkMgYnJpZGdl
IGhhbmRsZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjk1MzE2MF0gSVIgWE1QIHByb3RvY29sIGhh
bmRsZXIgaW5pdGlhbGl6ZWQKWyAgICAzLjk1MzE2Ml0gY3gyNTgyMTogZHJpdmVyIHZlcnNp
b24gMC4wLjEwNiBsb2FkZWQKWyAgICAzLjk1NDM5M10geGVuOiAtLT4gcGlycT00NyAtPiBp
cnE9NDAgKGdzaT00MCkKWyAgICAzLjk1NDgzOV0gY3gyNTgyMTogQXRoZW5hIEhhcmR3YXJl
IGRldmljZSA9IDB4ODIxMApbICAgIDMuOTU0ODUxXSBjeDI1ODIxOiBjeDI1ODIxWzFdOiBz
dWJzeXN0ZW06IDAwMDA6MDAwMCwgYm9hcmQ6IENYMjU4MjEgW2NhcmQ9MSxhdXRvZGV0ZWN0
ZWRdClsgICAgNC4yMzYyMDNdIGN4MjU4MjE6IEhhcmR3YXJlIHJldmlzaW9uID0gMHgwMApb
ICAgIDQuMjM2ODAzXSBjeDI1ODIxOiBjeDI1ODIxWzFdLzA6IGZvdW5kIGF0IDAwMDA6MDA6
MDYuMCwgcmV2OiAwLCBpcnE6IDQwLCBsYXRlbmN5OiAwLCBtbWlvOiAweGYzMDAwMDAwClsg
ICAgNC4yMzczNjldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIg
cHZydXNiMgpbICAgIDQuMjM3MzcwXSBwdnJ1c2IyOiBWNEwgaW4tdHJlZSB2ZXJzaW9uOkhh
dXBwYXVnZSBXaW5UVi1QVlItVVNCMiBNUEVHMiBFbmNvZGVyL1R1bmVyClsgICAgNC4yMzcz
NzFdIHB2cnVzYjI6IERlYnVnIG1hc2sgaXMgMzEgKDB4MWYpClsgICAgNC4yNDAyNDddIHNw
NTEwMF90Y286IFNQNTEwMC9TQjgwMCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYwLjA1
ClsgICAgNC4yNDA0MjBdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjI4LjAtaW9jdGwgKDIw
MTQtMDktMTcpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tClsgICAgNC4yNDA1
MDddIEJsdWV0b290aDogVmlydHVhbCBIQ0kgZHJpdmVyIHZlciAxLjUKWyAgICA0LjI0MDU2
Ml0gQmx1ZXRvb3RoOiBIQ0kgVUFSVCBkcml2ZXIgdmVyIDIuMgpbICAgIDQuMjQwNTYzXSBC
bHVldG9vdGg6IEhDSSBINCBwcm90b2NvbCBpbml0aWFsaXplZApbICAgIDQuMjQwNTY0XSBC
bHVldG9vdGg6IEhDSSBCQ1NQIHByb3RvY29sIGluaXRpYWxpemVkClsgICAgNC4yNDA1NjVd
IEJsdWV0b290aDogSENJTEwgcHJvdG9jb2wgaW5pdGlhbGl6ZWQKWyAgICA0LjI0MDU2NV0g
Qmx1ZXRvb3RoOiBIQ0lBVEgzSyBwcm90b2NvbCBpbml0aWFsaXplZApbICAgIDQuMjQwNTY2
XSBCbHVldG9vdGg6IEhDSSBUaHJlZS13aXJlIFVBUlQgKEg1KSBwcm90b2NvbCBpbml0aWFs
aXplZApbICAgIDQuMjQwNTg5XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug
ZHJpdmVyIGJjbTIwM3gKWyAgICA0LjI0MDYwNl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBicGExMHgKWyAgICA0LjI0MDYyM10gdXNiY29yZTogcmVnaXN0
ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBiZnVzYgpbICAgIDQuMjQwNjM1XSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGJ0dXNiClsgICAgNC4yNDA2NDhd
IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgYXRoM2sKWyAgICA0
LjI0MDc2MV0gaGlkcmF3OiByYXcgSElEIGV2ZW50cyBkcml2ZXIgKEMpIEppcmkgS29zaW5h
ClsgICAgNC4yNDA5MDhdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgdXNiaGlkClsgICAgNC4yNDA5MDhdIHVzYmhpZDogVVNCIEhJRCBjb3JlIGRyaXZlcgpb
ICAgIDQuMjQxMjQxXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVy
IHNuZC11c2ItYXVkaW8KWyAgICA0LjI0MTI1OV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBzbmQtdWExMDEKWyAgICA0LjI0MTI3OF0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLXVzeDJ5ClsgICAgNC4yNDEy
OTldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi1j
YWlhcQpbICAgIDQuMjQxMzE3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug
ZHJpdmVyIHNuZC11c2ItNmZpcmUKWyAgICA0LjI0MTMzMV0gTmV0ZmlsdGVyIG1lc3NhZ2Vz
IHZpYSBORVRMSU5LIHYwLjMwLgpbICAgIDQuMjQxMzM0XSBuZm5sX2FjY3Q6IHJlZ2lzdGVy
aW5nIHdpdGggbmZuZXRsaW5rLgpbICAgIDQuMjQxMzQ3XSBuZl9jb25udHJhY2sgdmVyc2lv
biAwLjUuMCAoNzgzNiBidWNrZXRzLCAzMTM0NCBtYXgpClsgICAgNC4yNDE0MzZdIGN0bmV0
bGluayB2MC45MzogcmVnaXN0ZXJpbmcgd2l0aCBuZm5ldGxpbmsuClsgICAgNC4yNDE1NTVd
IHh0X3RpbWU6IGtlcm5lbCB0aW1lem9uZSBpcyAtMDAwMApbICAgIDQuMjQxNTU5XSBpcF9z
ZXQ6IHByb3RvY29sIDYKWyAgICA0LjI0MTU3N10gSVBWUzogUmVnaXN0ZXJlZCBwcm90b2Nv
bHMgKCkKWyAgICA0LjI0MTU4NF0gSVBWUzogQ29ubmVjdGlvbiBoYXNoIHRhYmxlIGNvbmZp
Z3VyZWQgKHNpemU9NDA5NiwgbWVtb3J5PTY0S2J5dGVzKQpbICAgIDQuMjQxNjA5XSBJUFZT
OiBDcmVhdGluZyBuZXRucyBzaXplPTEyMTYgaWQ9MApbICAgIDQuNjI1OTI5XSBpbnB1dDog
SW1FeFBTLzIgR2VuZXJpYyBFeHBsb3JlciBNb3VzZSBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9p
ODA0Mi9zZXJpbzEvaW5wdXQvaW5wdXQ2ClsgICAgNC42NDI5MzddIElQVlM6IGlwdnMgbG9h
ZGVkLgpbICAgIDQuODg2NDk3XSBpcF90YWJsZXM6IChDKSAyMDAwLTIwMDYgTmV0ZmlsdGVy
IENvcmUgVGVhbQpbICAgIDQuODg2NTMwXSBUQ1A6IGN1YmljIHJlZ2lzdGVyZWQKWyAgICA0
Ljg4NjUzM10gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNwpbICAgIDQuODg2
NTU2XSBicmlkZ2U6IGF1dG9tYXRpYyBmaWx0ZXJpbmcgdmlhIGFycC9pcC9pcDZ0YWJsZXMg
aGFzIGJlZW4gZGVwcmVjYXRlZC4gVXBkYXRlIHlvdXIgc2NyaXB0cyB0byBsb2FkIGJyX25l
dGZpbHRlciBpZiB5b3UgbmVlZCB0aGlzLgpbICAgIDUuMTkyODQyXSBCcmlkZ2UgZmlyZXdh
bGxpbmcgcmVnaXN0ZXJlZApbICAgIDUuMjAzNzk5XSBFYnRhYmxlcyB2Mi4wIHJlZ2lzdGVy
ZWQKWyAgICA1LjIxMzY5NV0gQmx1ZXRvb3RoOiBSRkNPTU0gVFRZIGxheWVyIGluaXRpYWxp
emVkClsgICAgNS4yMjY2NThdIEJsdWV0b290aDogUkZDT01NIHNvY2tldCBsYXllciBpbml0
aWFsaXplZApbICAgIDUuMjM5ODc1XSBCbHVldG9vdGg6IFJGQ09NTSB2ZXIgMS4xMQpbICAg
IDUuMjUwNDg1XSBCbHVldG9vdGg6IEJORVAgKEV0aGVybmV0IEVtdWxhdGlvbikgdmVyIDEu
MwpbICAgIDUuMjY0MTI2XSBCbHVldG9vdGg6IEJORVAgZmlsdGVyczogcHJvdG9jb2wgbXVs
dGljYXN0ClsgICAgNS4yNzc3NzNdIEJsdWV0b290aDogQk5FUCBzb2NrZXQgbGF5ZXIgaW5p
dGlhbGl6ZWQKWyAgICA1LjI5MTM5MF0gQmx1ZXRvb3RoOiBISURQIChIdW1hbiBJbnRlcmZh
Y2UgRW11bGF0aW9uKSB2ZXIgMS4yClsgICAgNS4zMDY3NTFdIEJsdWV0b290aDogSElEUCBz
b2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgICA1LjMxOTMwNF0gS2V5IHR5cGUgY2VwaCBy
ZWdpc3RlcmVkClsgICAgNS4zMjkxNDNdIGxpYmNlcGg6IGxvYWRlZCAobW9uL29zZCBwcm90
byAxNS8yNCkKWyAgICA1LjM0MjcyOV0gcmVnaXN0ZXJlZCB0YXNrc3RhdHMgdmVyc2lvbiAx
ClsgICAgNS4zNTUwNjZdIEJ0cmZzIGxvYWRlZApbICAgIDUuMzY1NzM5XSB4ZW5idXNfcHJv
YmVfZnJvbnRlbmQ6IERldmljZSB3aXRoIG5vIGRyaXZlcjogZGV2aWNlL3BjaS8wClsgICAg
NS4zODI4NjFdIGNvbnNvbGUgW25ldGNvbjBdIGVuYWJsZWQKWyAgICA1LjM4NjA5N10gdXNi
IDEtMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTEwY2YsIGlkUHJvZHVjdD01
NTAwClsgICAgNS4zODYwOThdIHVzYiAxLTI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0xLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wClsgICAgNS4zODYxMDBdIHVzYiAxLTI6
IFByb2R1Y3Q6IFVTQiBLODA1NQpbICAgIDUuMzg2MTAwXSB1c2IgMS0yOiBNYW51ZmFjdHVy
ZXI6IFZlbGxlbWFuIApbICAgIDUuMzg2MjEyXSB1c2IgMS0yOiBlcCAweDgxIC0gcm91bmRp
bmcgaW50ZXJ2YWwgdG8gNjQgbWljcm9mcmFtZXMsIGVwIGRlc2Mgc2F5cyA4MCBtaWNyb2Zy
YW1lcwpbICAgIDUuMzg2MjE1XSB1c2IgMS0yOiBlcCAweDEgLSByb3VuZGluZyBpbnRlcnZh
bCB0byA2NCBtaWNyb2ZyYW1lcywgZXAgZGVzYyBzYXlzIDgwIG1pY3JvZnJhbWVzClsgICAg
NS4zOTY3MjddIHVzYiAzLTE6IG5ldyBmdWxsLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIg
dXNpbmcgdWhjaV9oY2QKWyAgICA1LjUxMDkzNV0gbmV0Y29uc29sZTogbmV0d29yayBsb2dn
aW5nIHN0YXJ0ZWQKWyAgICA1LjUyNDE3MV0gcnRjX2Ntb3MgMDA6MDI6IHNldHRpbmcgc3lz
dGVtIGNsb2NrIHRvIDIwMTQtMTEtMTggMTM6MDk6MDEgVVRDICgxNDE2MzE2MTQxKQpbICAg
IDUuNTQ1MzQwXSBBTFNBIGRldmljZSBsaXN0OgpbICAgIDUuNTU1NjA3XSAgIE5vIHNvdW5k
Y2FyZHMgZm91bmQuClsgICAgNS41NTU2MTFdIHVzYiAzLTE6IG5vdCBydW5uaW5nIGF0IHRv
cCBzcGVlZDsgY29ubmVjdCB0byBhIGhpZ2ggc3BlZWQgaHViClsgICAgNS41ODY3OTJdIEZy
ZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEwNDhLIChmZmZmZmZmZjgyMGRmMDAwIC0g
ZmZmZmZmZmY4MjFlNTAwMCkKWyAgICA1LjYwNzkyOF0gV3JpdGUgcHJvdGVjdGluZyB0aGUg
a2VybmVsIHJlYWQtb25seSBkYXRhOiAxNjM4NGsKWyAgICA1LjYyODg3Nl0gRnJlZWluZyB1
bnVzZWQga2VybmVsIG1lbW9yeTogMTM0MEsgKGZmZmY4ODAwMDFhYjEwMDAgLSBmZmZmODgw
MDAxYzAwMDAwKQpbICAgIDUuNjUxODA5XSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5
OiA2MDBLIChmZmZmODgwMDAxZjZhMDAwIC0gZmZmZjg4MDAwMjAwMDAwMCkKWyAgICA1LjY3
MjcwNl0gdXNiIDMtMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTA2MjcsIGlk
UHJvZHVjdD0wMDAxClsgICAgNS42NzI3MDldIHVzYiAzLTE6IE5ldyBVU0IgZGV2aWNlIHN0
cmluZ3M6IE1mcj0xLCBQcm9kdWN0PTMsIFNlcmlhbE51bWJlcj01ClsgICAgNS42NzI3MTFd
IHVzYiAzLTE6IFByb2R1Y3Q6IFFFTVUgVVNCIFRhYmxldApbICAgIDUuNjcyNzEyXSB1c2Ig
My0xOiBNYW51ZmFjdHVyZXI6IFFFTVUKWyAgICA1LjY3MjcxM10gdXNiIDMtMTogU2VyaWFs
TnVtYmVyOiA0MgpbICAgIDUuNzQ4MTAyXSBpbnB1dDogUUVNVSBRRU1VIFVTQiBUYWJsZXQg
YXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAwOjAxLjIvdXNiMy8zLTEvMy0xOjEuMC8w
MDAzOjA2Mjc6MDAwMS4wMDAxL2lucHV0L2lucHV0NwpbICAgIDUuNzc0MDkxXSB1ZGV2ZFsx
NDU4XTogc3RhcnRpbmcgdmVyc2lvbiAxNzUKWyAgICA1Ljc5MDE3M10gaGlkLWdlbmVyaWMg
MDAwMzowNjI3OjAwMDEuMDAwMTogaW5wdXQsaGlkcmF3MDogVVNCIEhJRCB2MC4wMSBQb2lu
dGVyIFtRRU1VIFFFTVUgVVNCIFRhYmxldF0gb24gdXNiLTAwMDA6MDA6MDEuMi0xL2lucHV0
MApbICAgIDguOTE5NTUwXSBFWFQ0LWZzICh4dmRhMSk6IElORk86IHJlY292ZXJ5IHJlcXVp
cmVkIG9uIHJlYWRvbmx5IGZpbGVzeXN0ZW0KWyAgICA4Ljk0NjUzNF0gRVhUNC1mcyAoeHZk
YTEpOiB3cml0ZSBhY2Nlc3Mgd2lsbCBiZSBlbmFibGVkIGR1cmluZyByZWNvdmVyeQpbICAg
IDkuNjYzOTYzXSBFWFQ0LWZzICh4dmRhMSk6IHJlY292ZXJ5IGNvbXBsZXRlClsgICAgOS43
NjQ3MjNdIEVYVDQtZnMgKHh2ZGExKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJl
ZCBkYXRhIG1vZGUuIE9wdHM6IChudWxsKQpbICAgMTQuODkwMTc1XSB1ZGV2ZFsxOTU2XTog
c3RhcnRpbmcgdmVyc2lvbiAxNzUKWyAgIDE5LjgwNjUyMV0gQWRkaW5nIDc2OTAyMGsgc3dh
cCBvbiAvZGV2L3h2ZGEyLiAgUHJpb3JpdHk6LTEgZXh0ZW50czoxIGFjcm9zczo3NjkwMjBr
IFNTClsgICAxOS44NTg4NTFdIEVYVDQtZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0czog
KG51bGwpClsgICAyMC4yOTg3NDddIEVYVDQtZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0
czogZXJyb3JzPXJlbW91bnQtcm8KWyAgIDI1Ljg1MDI3Ml0gRVhUNC1mcyAoeHZkYik6IG1v
dW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBlcnJvcnM9
cmVtb3VudC1ybwpbICAgOTQuODAzNDYwXSB4aGNpX2hjZCAwMDAwOjAwOjA1LjA6IHhIQ0kg
aG9zdCBub3QgcmVzcG9uZGluZyB0byBzdG9wIGVuZHBvaW50IGNvbW1hbmQuClsgICA5NC44
MDY3NTddIHhoY2lfaGNkIDAwMDA6MDA6MDUuMDogQXNzdW1pbmcgaG9zdCBpcyBkeWluZywg
aGFsdGluZyBob3N0LgpbICAgOTQuODYyNjg3XSB4aGNpX2hjZCAwMDAwOjAwOjA1LjA6IEhD
IGRpZWQ7IGNsZWFuaW5nIHVwClsgICA5NC44NzY1NzddIHVzYiAxLTI6IFVTQiBkaXNjb25u
ZWN0LCBkZXZpY2UgbnVtYmVyIDIKWyAyNjQ0LjQ5MjcxM10gY3gyNTgyMTogY3gyNTgyMV92
aWRlb193YWtldXA6IDAgYnVmZmVycyBoYW5kbGVkIChzaG91bGQgYmUgMSkK
------------0191A1230144FE1ED
Content-Type: application/octet-stream;
 name="serial.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial.log"

77u/IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgIF9fXyAgICAgICAgICAgICAg
DQogXCBcLyAvX19fIF8gX18gICB8IHx8IHwgIHwgX19ffCAvIF8gXCAgICBfIF9fIF9fXyAN
CiAgXCAgLy8gXyBcICdfIFwgIHwgfHwgfF8gfF9fXyBcfCB8IHwgfF9ffCAnX18vIF9ffA0K
ICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8IHxffCB8X198IHwgfCAoX18gDQog
L18vXF9cX19ffF98IHxffCAgICB8X3woXylfX19fKF8pX19fLyAgIHxffCAgXF9fX3wNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KKFhF
TikgWGVuIHZlcnNpb24gNC41LjAtcmMgKHJvb3RAZHluZG5zLm9yZykgKGdjYy00LjcucmVh
bCAoRGViaWFuIDQuNy4yLTUpIDQuNy4yKSBkZWJ1Zz15IFR1ZSBOb3YgMTggMTI6NTg6NTEg
Q0VUIDIwMTQNCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IE1vbiBOb3YgMTcgMTU6MDc6MDMg
MjAxNCArMDEwMCBnaXQ6MDU0MGI4NS1kaXJ0eQ0KKFhFTikgQm9vdGxvYWRlcjogR1JVQiAx
Ljk5LTI3K2RlYjd1Mg0KKFhFTikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0xNTM2TSxtYXg6
MTUzNk0gbG9nbHZsPWFsbCBsb2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcz1k
YXRlbXMgdmdhPWdmeC0xMjgweDEwMjR4MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBjb20xPTM4
NDAwLDhuMSBjb25zb2xlPXZnYSxjb20xIGl2cnNfaW9hcGljWzZdPTAwOjE0LjAgaW9tbXU9
b24sdmVyYm9zZSxkZWJ1ZyxhbWQtaW9tbXUtZGVidWcgZGVidWcgbGFwaWM9ZGVidWcgYXBp
Y192ZXJib3NpdHk9ZGVidWcgYXBpYz1kZWJ1Zw0KKFhFTikgVmlkZW8gaW5mb3JtYXRpb246
DQooWEVOKSAgVkdBIGlzIGdyYXBoaWNzIG1vZGUgMTI4MHgxMDI0LCAzMiBicHANCihYRU4p
ICBWQkUvRERDIG1ldGhvZHM6IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDEgc2Vjb25kcw0K
KFhFTikgRGlzYyBpbmZvcm1hdGlvbjoNCihYRU4pICBGb3VuZCAyIE1CUiBzaWduYXR1cmVz
DQooWEVOKSAgRm91bmQgMiBFREQgaW5mb3JtYXRpb24gc3RydWN0dXJlcw0KKFhFTikgWGVu
LWU4MjAgUkFNIG1hcDoNCihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5
OTQwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwMDAwOTk0MDAgLSAwMDAwMDAwMDAwMGEw
MDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEw
MDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwOWZm
OTAwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDlmZjkwMDAwIC0gMDAwMDAwMDA5ZmY5
ZTAwMCAoQUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwOWZmOWUwMDAgLSAwMDAwMDAwMDlm
ZmUwMDAwIChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMDlmZmUwMDAwIC0gMDAwMDAwMDBh
MDAwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZmUwMDAwMCAtIDAwMDAwMDAx
MDAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAw
NTYwMDAwMDAwICh1c2FibGUpDQooWEVOKSBBQ1BJOiBSU0RQIDAwMEZCMTAwLCAwMDE0IChy
MCBBQ1BJQU0pDQooWEVOKSBBQ1BJOiBSU0RUIDlGRjkwMDAwLCAwMDQ4IChyMSBNU0kgICAg
T0VNU0xJQyAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IEZBQ1AgOUZG
OTAyMDAsIDAwODQgKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAgICAgIDk3
KQ0KKFhFTikgQUNQSTogRFNEVCA5RkY5MDVFMCwgOTQyNyAocjEgIEE3NjQwIEE3NjQwMTAw
ICAgICAgMTAwIElOVEwgMjAwNTExMTcpDQooWEVOKSBBQ1BJOiBGQUNTIDlGRjlFMDAwLCAw
MDQwDQooWEVOKSBBQ1BJOiBBUElDIDlGRjkwMzkwLCAwMDg4IChyMSA3NjQwTVMgQTc2NDAx
MDAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE1DRkcgOUZGOTA0MjAs
IDAwM0MgKHIxIDc2NDBNUyBPRU1NQ0ZHICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhF
TikgQUNQSTogU0xJQyA5RkY5MDQ2MCwgMDE3NiAocjEgTVNJICAgIE9FTVNMSUMgIDIwMTAw
OTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBPRU1CIDlGRjlFMDQwLCAwMDcyIChy
MSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6
IFNSQVQgOUZGOUE1RTAsIDAxMDggKHIzIEFNRCAgICBGQU1fRl8xMCAgICAgICAgMiBBTUQg
ICAgICAgICAxKQ0KKFhFTikgQUNQSTogSFBFVCA5RkY5QTZGMCwgMDAzOCAocjEgNzY0ME1T
IE9FTUhQRVQgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBJVlJTIDlG
RjlBNzMwLCAwMTEwIChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEgQU1EICAgICAgICAg
MCkNCihYRU4pIEFDUEk6IFNTRFQgOUZGOUE4NDAsIDBEQTQgKHIxIEEgTSBJICBQT1dFUk5P
VyAgICAgICAgMSBBTUQgICAgICAgICAxKQ0KKFhFTikgU3lzdGVtIFJBTTogMjA0NzlNQiAo
MjA5NzA2NjBrQikNCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMCAtPiBOb2RlIDANCihY
RU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAw
IC0+IEFQSUMgMiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMyAtPiBO
b2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAtPiBOb2RlIDANCihYRU4pIFNS
QVQ6IFBYTSAwIC0+IEFQSUMgNSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0g
MCAwLWEwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwLWEwMDAwMDAwDQoo
WEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwMDAwLTU2MDAwMDAwMA0KKFhFTikgTlVN
QTogQWxsb2NhdGVkIG1lbW5vZGVtYXAgZnJvbSA1NWQwYWYwMDAgLSA1NWQwYjUwMDANCihY
RU4pIE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lg0KKFhFTikgRG9tYWluIGhl
YXAgaW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVidWZmZXIgYXQgMHhkMDAwMDAw
MCwgbWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDIwMTAwMCwgdXNpbmcgNjE0NGssIHRvdGFsIDE2
Mzg0aw0KKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwgbGluZWxlbmd0aD01
MTIwLCBmb250IDh4MTYNCihYRU4pIHZlc2FmYjogVHJ1ZWNvbG9yOiBzaXplPTA6ODo4Ojgs
IHNoaWZ0PTA6MTY6ODowDQooWEVOKSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgMDAwZmY3ODAN
CihYRU4pIERNSSBwcmVzZW50Lg0KKFhFTikgQVBJQyBib290IHN0YXRlIGlzICd4YXBpYycN
CihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4pIEFDUEk6IFBNLVRpbWVy
IElPIFBvcnQ6IDB4ODA4DQooWEVOKSBBQ1BJOiBTTEVFUCBJTkZPOiBwbTF4X2NudFsxOjgw
NCwxOjBdLCBwbTF4X2V2dFsxOjgwMCwxOjBdDQooWEVOKSBBQ1BJOiAgICAgICAgICAgICB3
YWtldXBfdmVjWzlmZjllMDBjXSwgdmVjX3NpemVbMjBdDQooWEVOKSBBQ1BJOiBMb2NhbCBB
UElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
MV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMCAwOjEwIEFQ
SUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNf
aWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lv
biAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0g
ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkN
CihYRU4pIFByb2Nlc3NvciAjMyAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFBy
b2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAj
NSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA2XSBh
ZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KKFhFTikgSU9BUElDWzBdOiBhcGlj
X2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNCihYRU4p
IEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsy
NF0pDQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAw
eGZlYzIwMDAwLCBHU0kgMjQtNTUNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBi
dXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQooWEVOKSBBQ1BJOiBJTlRfU1JDX09W
UiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQooWEVOKSBBQ1BJ
OiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3Zl
cnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBFbmFi
bGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MNCihYRU4pIEFDUEk6
IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAwDQooWEVOKSBFUlNUIHRhYmxlIHdh
cyBub3QgZm91bmQNCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJh
dGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgU01QOiBBbGxvd2luZyA2IENQVXMgKDAgaG90cGx1
ZyBDUFVzKQ0KKFhFTikgbWFwcGVkIEFQSUMgdG8gZmZmZjgyY2ZmZmRmYjAwMCAoZmVlMDAw
MDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmNmZmZkZmEwMDAgKGZlYzAwMDAw
KQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjZmZmZGY5MDAwIChmZWMyMDAwMCkN
CihYRU4pIElSUSBsaW1pdHM6IDU2IEdTSSwgMTExMiBNU0kvTVNJLVgNCihYRU4pIFVzaW5n
IHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkNCihYRU4pIERldGVj
dGVkIDMyMDAuMTc2IE1IeiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFy
aW5nLg0KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVk
DQooWEVOKSBhbHQgdGFibGUgZmZmZjgyZDA4MDJkYWYzMCAtPiBmZmZmODJkMDgwMmRiZjUw
DQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUwMDAwMDAwIHNlZ21l
bnQgMDAwMCBidXNlcyAwMCAtIGZmDQooWEVOKSBQQ0k6IE5vdCB1c2luZyBNQ0ZHIGZvciBz
ZWdtZW50IDAwMDAgYnVzIDAwLWZmDQooWEVOKSBBTUQtVmk6IEZvdW5kIE1TSSBjYXBhYmls
aXR5IGJsb2NrIGF0IDB4NTQNCihYRU4pIEFNRC1WaTogQUNQSSBUYWJsZToNCihYRU4pIEFN
RC1WaTogIFNpZ25hdHVyZSBJVlJTDQooWEVOKSBBTUQtVmk6ICBMZW5ndGggMHgxMTANCihY
RU4pIEFNRC1WaTogIFJldmlzaW9uIDB4MQ0KKFhFTikgQU1ELVZpOiAgQ2hlY2tTdW0gMHhl
Yg0KKFhFTikgQU1ELVZpOiAgT0VNX0lkIEFNRCAgDQooWEVOKSBBTUQtVmk6ICBPRU1fVGFi
bGVfSWQgUkQ4OTBTDQooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIwMzENCihY
RU4pIEFNRC1WaTogIENyZWF0b3JfSWQgQU1EIA0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9S
ZXZpc2lvbiAwDQooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6IHR5cGUgMHgxMCBmbGFncyAw
eDNlIGxlbiAweGUwIGlkIDB4Mg0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDMgaWQgMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDAg
LT4gMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAw
eDEwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgz
IGlkIDB4ZjAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHhmMDAg
LT4gMHhmMDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlk
IDB4MTggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAw
eDMgaWQgMHhlMDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweGUw
MCAtPiAweGUwMQ0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIg
aWQgMHgyOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweGQwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
OiB0eXBlIDB4MiBpZCAweDMwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHgyIGlkIDB4YzAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NDggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhiMDAgZmxhZ3MgMA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg1MCBmbGFncyAwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGEwMCBmbGFncyAw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDU4IGZs
YWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgzIGlkIDB4
OTAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg5MDAgLT4gMHg5
MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NjAg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHg1MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAw
eDIgaWQgMHg2MDggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHg4MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeTogdHlwZSAweDIgaWQgMHg2MTAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg3MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg2OCBmbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDQwMCBmbGFncyAwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDg4IGZsYWdzIDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgzIGlkIDB4OTAgZmxh
Z3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+IDB4OTINCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgzIGlkIDB4OTggZmxhZ3MgMA0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTAgZmxhZ3MgMHhkNw0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhMiBmbGFncyAw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGEzIGZs
YWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4
YTQgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDQz
IGlkIDB4MzAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAg
LT4gMHgzZmYgYWxpYXMgMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHhhNSBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4MiBpZCAweGE4IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTkgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgxMDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHhiMCBmbGFncyAwDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAwIGlkIDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAweDQ4IGlkIDAgZmxhZ3MgMHhkNw0KKFhFTikgQU1ELVZp
OiBJVkhEIFNwZWNpYWw6IDAwMDA6MDA6MTQuMCB2YXJpZXR5IDB4MiBoYW5kbGUgMA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDQ4IGlkIDAgZmxhZ3MgMA0K
KFhFTikgQU1ELVZpOiBJVkhEIFNwZWNpYWw6IDAwMDA6MDA6MDAuMSB2YXJpZXR5IDB4MSBo
YW5kbGUgMHg3DQooWEVOKSBBTUQtVmk6IERpc2FibGVkIEhBUCBtZW1vcnkgbWFwIHNoYXJp
bmcgd2l0aCBJT01NVQ0KKFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBJ
L08gdmlydHVhbGlzYXRpb24gZW5hYmxlZA0KKFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVk
DQooWEVOKSBJbnRlcnJ1cHQgcmVtYXBwaW5nIGVuYWJsZWQNCihYRU4pIEdldHRpbmcgVkVS
U0lPTjogODAwNTAwMTANCihYRU4pIEdldHRpbmcgVkVSU0lPTjogODAwNTAwMTANCihYRU4p
IEdldHRpbmcgSUQ6IDANCihYRU4pIEdldHRpbmcgTFZUMDogNzAwDQooWEVOKSBHZXR0aW5n
IExWVDE6IDQwMA0KKFhFTikgZW5hYmxlZCBFeHRJTlQgb24gQ1BVIzANCihYRU4pIEVTUiB2
YWx1ZSBiZWZvcmUgZW5hYmxpbmcgdmVjdG9yOiAweDQgIGFmdGVyOiAwDQooWEVOKSBFTkFC
TElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZA0KKFhF
TikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1BUElDIChhcGljaWQtcGluKSA2LTAs
IDYtMTYsIDYtMTcsIDYtMTgsIDYtMTksIDYtMjAsIDYtMjEsIDYtMjIsIDYtMjMsIDctMCwg
Ny0xLCA3LTIsIDctMywgNy00LCA3LTUsIDctNiwgNy03LCA3LTgsIDctOSwgNy0xMCwgNy0x
MSwgNy0xMiwgNy0xMywgNy0xNCwgNy0xNSwgNy0xNiwgNy0xNywgNy0xOCwgNy0xOSwgNy0y
MCwgNy0yMSwgNy0yMiwgNy0yMywgNy0yNCwgNy0yNSwgNy0yNiwgNy0yNywgNy0yOCwgNy0y
OSwgNy0zMCwgNy0zMSBub3QgY29ubmVjdGVkLg0KKFhFTikgLi5USU1FUjogdmVjdG9yPTB4
RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0tMQ0KKFhFTikgbnVtYmVyIG9mIE1Q
IElSUSBzb3VyY2VzOiAxNS4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM2IHJlZ2lzdGVy
czogMjQuDQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAjNyByZWdpc3RlcnM6IDMyLg0KKFhF
TikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQooWEVOKSBJ
TyBBUElDICM2Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDogMDYwMDAwMDANCihY
RU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNg0KKFhFTikgLi4uLi4uLiAg
ICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAg
OiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzgwMjENCihYRU4pIC4uLi4uLi4g
ICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMTcNCihYRU4pIC4uLi4uLi4gICAg
IDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVy
c2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAjMDI6IDA2MDAwMDAwDQooWEVOKSAu
Li4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KKFhFTikgLi4uLiByZWdpc3RlciAjMDM6
IDA3MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IEJvb3QgRFQgICAgOiAwDQooWEVOKSAu
Li4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJp
ZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAzMA0KKFhFTikgIDAxIDAwMSAwMSAg
MCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzANCihYRU4pICAwMiAwMDEgMDEg
IDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwDQooWEVOKSAgMDMgMDAxIDAx
ICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzOA0KKFhFTikgIDA0IDAwMSAw
MSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjENCihYRU4pICAwNSAwMDEg
MDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwDQooWEVOKSAgMDYgMDAx
IDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA0OA0KKFhFTikgIDA3IDAw
MSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTANCihYRU4pICAwOCAw
MDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4DQooWEVOKSAgMDkg
MDAxIDAxICAxICAgIDEgICAgMCAgIDEgICAwICAgIDEgICAgMCAgICAwMA0KKFhFTikgIDBh
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNjgNCihYRU4pICAw
YiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwDQooWEVOKSAg
MGMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA3OA0KKFhFTikg
IDBkIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgODgNCihYRU4p
ICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwDQooWEVO
KSAgMGYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA5OA0KKFhF
TikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzANCihY
RU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwDQoo
WEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAzMA0K
KFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAN
CihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMw
DQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAz
MA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAg
MzANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAg
IDMwDQooWEVOKSBJTyBBUElDICM3Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDog
MDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNw0KKFhF
TikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBM
VFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxRjgwMjENCihY
RU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMUYNCihYRU4p
IC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4uLi4uICAgICA6
IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAjMDI6IDAwMDAw
MDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwMA0KKFhFTikgLi4uLiBJ
UlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIgTG9nIFBoeSBNYXNrIFRyaWcgSVJS
IFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhFTikgIDAwIDAwMCAwMCAgMSAgICAw
ICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMSAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDIgMDAwIDAwICAxICAg
IDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAzIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDUgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA2IDAwMCAwMCAg
MSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNyAwMDAgMDAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDggMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA5IDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwYSAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGIgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBjIDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwZCAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGUg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBm
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAx
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMWEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMWQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSBVc2luZyB2ZWN0b3ItYmFzZWQgaW5kZXhpbmcNCihYRU4pIElSUSB0
byBwaW4gbWFwcGluZ3M6DQooWEVOKSBJUlEyNDAgLT4gMDoyDQooWEVOKSBJUlE0OCAtPiAw
OjENCihYRU4pIElSUTU2IC0+IDA6Mw0KKFhFTikgSVJRMjQxIC0+IDA6NA0KKFhFTikgSVJR
NjQgLT4gMDo1DQooWEVOKSBJUlE3MiAtPiAwOjYNCihYRU4pIElSUTgwIC0+IDA6Nw0KKFhF
TikgSVJRODggLT4gMDo4DQooWEVOKSBJUlE5NiAtPiAwOjkNCihYRU4pIElSUTEwNCAtPiAw
OjEwDQooWEVOKSBJUlExMTIgLT4gMDoxMQ0KKFhFTikgSVJRMTIwIC0+IDA6MTINCihYRU4p
IElSUTEzNiAtPiAwOjEzDQooWEVOKSBJUlExNDQgLT4gMDoxNA0KKFhFTikgSVJRMTUyIC0+
IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBkb25l
Lg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBpbnRlcnJ1cHRzLg0KKFhFTikgY2Fs
aWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4uLi4uIENQVSBjbG9jayBzcGVlZCBp
cyAzMjAwLjE1NjggTUh6Lg0KKFhFTikgLi4uLi4gaG9zdCBidXMgY2xvY2sgc3BlZWQgaXMg
MjAwLjAwOTcgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3NjYWxlID0gMHhjY2Q3DQooWEVOKSBb
MjAxNC0xMS0xOCAxNDoyNjo0Ny43MTNdIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1IeiBI
UEVUDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny43MzRdIEFsbG9jYXRlZCBjb25zb2xl
IHJpbmcgb2YgNjQgS2lCLg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDcuNzQwXSBIVk06
IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny43NDZdIFNWTTog
U3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6
NDcuNzUyXSAgLSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkNCihYRU4pIFsyMDE0LTExLTE4
IDE0OjI2OjQ3Ljc1OF0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0
aW9uDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny43NjRdICAtIE5leHQtUklQIFNhdmVk
IG9uICNWTUVYSVQNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ3Ljc3MV0gIC0gUGF1c2Ut
SW50ZXJjZXB0IEZpbHRlcg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDcuNzc3XSBIVk06
IFNWTSBlbmFibGVkDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny43ODNdIEhWTTogSGFy
ZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVApIGRldGVjdGVkDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDoyNjo0Ny43ODldIEhWTTogSEFQIHBhZ2Ugc2l6ZXM6IDRrQiwgMk1CLCAxR0INCihY
RU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ3Ljc5Nl0gSFZNOiBQVkggbW9kZSBub3Qgc3VwcG9y
dGVkIG9uIHRoaXMgcGxhdGZvcm0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ3LjgyM10g
bWFza2VkIEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDcuODQ5
XSBtYXNrZWQgRXh0SU5UIG9uIENQVSMyDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny44
NzZdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ3
LjkwMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6
NDcuOTI5XSBtYXNrZWQgRXh0SU5UIG9uIENQVSM1DQooWEVOKSBbMjAxNC0xMS0xOCAxNDoy
Njo0Ny45MzZdIEJyb3VnaHQgdXAgNiBDUFVzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0
Ny45NDZdIEFNRC1WaTogRmFpbGVkIHRvIHNldHVwIEhQRVQgTVNJIHJlbWFwcGluZy4gV3Jv
bmcgSFBFVC4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ3Ljk1Ml0gQU1ELVZpOiBGYWls
ZWQgdG8gc2V0dXAgSFBFVCBNU0kgcmVtYXBwaW5nLiBXcm9uZyBIUEVULg0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6MjY6NDcuOTU5XSBBTUQtVmk6IEZhaWxlZCB0byBzZXR1cCBIUEVUIE1T
SSByZW1hcHBpbmcuIFdyb25nIEhQRVQuDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0Ny45
NjVdIEhQRVQ6IDMgdGltZXJzIHVzYWJsZSBmb3IgYnJvYWRjYXN0ICgzIHRvdGFsKQ0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MjY6NDcuOTkyXSBBQ1BJIHNsZWVwIG1vZGVzOiBTMw0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MjY6NDcuOTk5XSBNQ0E6IFVzZSBodyB0aHJlc2hvbGRpbmcg
dG8gYWRqdXN0IHBvbGxpbmcgZnJlcXVlbmN5DQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0
OC4wMDZdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRl
ZC4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjAxM10gWGVub3Byb2ZpbGU6IEZhaWxl
ZCB0byBzZXR1cCBJQlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZg0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MjY6NDguMDIwXSAqKiogTE9BRElORyBET01BSU4gMCAqKioNCihY
RU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjE4OV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjog
cGFkZHI9MHgxMDAwMDAwIG1lbXN6PTB4MTA2NDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6
MjY6NDguMTk2XSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDIyMDAwMDAgbWVt
c3o9MHgxMDYwMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjIwM10gZWxmX3BhcnNl
X2JpbmFyeTogcGhkcjogcGFkZHI9MHgyMzA2MDAwIG1lbXN6PTB4MTQyODANCihYRU4pIFsy
MDE0LTExLTE4IDE0OjI2OjQ4LjIxMV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9
MHgyMzFiMDAwIG1lbXN6PTB4MTE0MDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDgu
MjE4XSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAtPiAweDM0NWIwMDAN
CihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjIyNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBH
VUVTVF9PUyA9ICJsaW51eCINCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjIzM10gZWxm
X3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiINCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjI2OjQ4LjI0MV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lPTiA9ICJ4
ZW4tMy4wIg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguMjQ4XSBlbGZfeGVuX3BhcnNl
X25vdGU6IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MjY6NDguMjU2XSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZm
ZjgyMzFiMWYwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC4yNjRdIGVsZl94ZW5fcGFy
c2Vfbm90ZTogSFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDANCihYRU4pIFsy
MDE0LTExLTE4IDE0OjI2OjQ4LjI3Ml0gZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9
ICIhd3JpdGFibGVfcGFnZV90YWJsZXN8cGFlX3BnZGlyX2Fib3ZlXzRnYnx3cml0YWJsZV9k
ZXNjcmlwdG9yX3RhYmxlc3xhdXRvX3RyYW5zbGF0ZWRfcGh5c21hcHxzdXBlcnZpc29yX21v
ZGVfa2VybmVsIg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguMjg3XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IFNVUFBPUlRFRF9GRUFUVVJFUyA9IDB4OTBkDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDoyNjo0OC4yOTZdIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIg0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguMzA0XSBlbGZfeGVuX3BhcnNlX25vdGU6IExP
QURFUiA9ICJnZW5lcmljIg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguMzEyXSBlbGZf
eGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNjo0OC4zMjFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5D
RUwgPSAweDENCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjMzMF0gZWxmX3hlbl9wYXJz
ZV9ub3RlOiBNT0RfU1RBUlRfUEZOID0gMHgxDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0
OC4zMzhdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAw
MDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC4zNDddIGVsZl94ZW5fcGFyc2Vf
bm90ZTogUEFERFJfT0ZGU0VUID0gMHgwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC4z
NTZdIGVsZl94ZW5fYWRkcl9jYWxjX2NoZWNrOiBhZGRyZXNzZXM6DQooWEVOKSBbMjAxNC0x
MS0xOCAxNDoyNjo0OC4zNjZdICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZmZjgw
MDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC4zNzVdICAgICBlbGZfcGFkZHJf
b2Zmc2V0ID0gMHgwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC4zODRdICAgICB2aXJ0
X29mZnNldCAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDoyNjo0OC4zOTRdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAw
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC40MDRdICAgICB2aXJ0X2tlbmQgICAgICAg
ID0gMHhmZmZmZmZmZjgzNDViMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC40MTNd
ICAgICB2aXJ0X2VudHJ5ICAgICAgID0gMHhmZmZmZmZmZjgyMzFiMWYwDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNjo0OC40MjNdICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZm
ZmZmZmZmZmZmDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC40MzNdICBYZW4gIGtlcm5l
bDogNjQtYml0LCBsc2IsIGNvbXBhdDMyDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC40
NDNdICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUsIGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+
IDB4MzQ1YjAwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguNDU0XSBQSFlTSUNBTCBN
RU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC40NjRdICBE
b20wIGFsbG9jLjogICAwMDAwMDAwNTQ4MDAwMDAwLT4wMDAwMDAwNTRjMDAwMDAwICgzNzI5
MzggcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDgu
NDc1XSAgSW5pdC4gcmFtZGlzazogMDAwMDAwMDU1ZjBjYTAwMC0+MDAwMDAwMDU1ZmZmZmEw
MA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguNDg2XSBWSVJUVUFMIE1FTU9SWSBBUlJB
TkdFTUVOVDoNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjQ5N10gIExvYWRlZCBrZXJu
ZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODM0NWIwMDANCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjI2OjQ4LjUwOF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAwMDAwMDAwMDAtPjAw
MDAwMDAwMDAwMDAwMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjUxOF0gIFBoeXMt
TWFjaCBtYXA6IGZmZmZmZmZmODM0NWIwMDAtPmZmZmZmZmZmODM3NWIwMDANCihYRU4pIFsy
MDE0LTExLTE4IDE0OjI2OjQ4LjUyOV0gIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODM3NWIw
MDAtPmZmZmZmZmZmODM3NWI0YjQNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjU0MF0g
IFBhZ2UgdGFibGVzOiAgIGZmZmZmZmZmODM3NWMwMDAtPmZmZmZmZmZmODM3N2IwMDANCihY
RU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjU1MV0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZm
ODM3N2IwMDAtPmZmZmZmZmZmODM3N2MwMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4
LjU2Ml0gIFRPVEFMOiAgICAgICAgIGZmZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZmODM4MDAw
MDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjU3M10gIEVOVFJZIEFERFJFU1M6IGZm
ZmZmZmZmODIzMWIxZjANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjU4NV0gRG9tMCBo
YXMgbWF4aW11bSA2IFZDUFVzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC41OTZdIGVs
Zl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZmZmY4MTAwMDAwMCAtPiAweGZmZmZm
ZmZmODIwNjQwMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ4LjYxNF0gZWxmX2xvYWRf
YmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgyMjAwMDAwIC0+IDB4ZmZmZmZmZmY4MjMw
NjAwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDguNjI1XSBlbGZfbG9hZF9iaW5hcnk6
IHBoZHIgMiBhdCAweGZmZmZmZmZmODIzMDYwMDAgLT4gMHhmZmZmZmZmZjgyMzFhMjgwDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo0OC42MzddIGVsZl9sb2FkX2JpbmFyeTogcGhkciAz
IGF0IDB4ZmZmZmZmZmY4MjMxYjAwMCAtPiAweGZmZmZmZmZmODI0MjMwMDANCihYRU4pIFsy
MDE0LTExLTE4IDE0OjI2OjQ5LjA0OV0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0
OjI2OjQ5Ljc5MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MCwgdHlwZSA9IDB4Niwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjQ5LjgwM10gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyLCB0eXBlID0gMHg3LCBy
b290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuODE1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDEwLCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1
NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MjY6NDkuODI3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDE4LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuODQw
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDI4LCB0eXBl
ID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuODUzXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDMwLCB0eXBlID0gMHgyLCByb290IHRh
YmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MjY6NDkuODY2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDQ4LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6
MjY6NDkuODc5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDUwLCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuODkyXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDU4LCB0eXBlID0gMHgy
LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuOTA1XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDYwLCB0eXBlID0gMHgyLCByb290IHRhYmxlID0g
MHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQt
MTEtMTggMTQ6MjY6NDkuOTE5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDY4LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDku
OTMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDg4LCB0
eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuOTQ2XSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwLCB0eXBlID0gMHg3LCByb290
IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuOTYwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDkyLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVl
ZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6MjY6NDkuOTc0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDk4LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NDkuOTg4XSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDlhLCB0eXBlID0g
MHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMDAzXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEwLCB0eXBlID0gMHg3LCByb290IHRhYmxl
ID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6MjY6NTAuMDE3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweGEyLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6
NTAuMDMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEz
LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMDQ3XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE0LCB0eXBlID0gMHg1LCBy
b290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMDYyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweGE1LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1
NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MjY6NTAuMDc3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweGE4LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMDky
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGIwLCB0eXBl
ID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMTA4XSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGIyLCB0eXBlID0gMHg3LCByb290IHRh
YmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MjY6NTAuMTIzXSBBTUQtVmk6IFNraXBwaW5nIGhvc3QgYnJpZGdl
IDAwMDA6MDA6MTguMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMTM5XSBBTUQtVmk6
IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTguMQ0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6MjY6NTAuMTU0XSBBTUQtVmk6IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTgu
Mg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMTY5XSBBTUQtVmk6IFNraXBwaW5nIGhv
c3QgYnJpZGdlIDAwMDA6MDA6MTguMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMTg0
XSBBTUQtVmk6IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTguNA0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6MjY6NTAuMTk5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDQwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2
OjUwLjIxNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1
MDAsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1MC4yMzFdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NjA4LCB0eXBlID0gMHgy
LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMjQ3XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDYxMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9
IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0
LTExLTE4IDE0OjI2OjUwLjI2M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg3MDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1
MC4yNzldIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ODAw
LCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuMjk2XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwMCwgdHlwZSA9IDB4MSwg
cm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjUwLjMxMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDEsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAw
eDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDoyNjo1MC4zMjldIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4YTAwLCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTAu
MzQ2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGIwMCwg
dHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjUwLjM2M10gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhjMDAsIHR5cGUgPSAweDEsIHJv
b3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1MC4zODFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4ZDAwLCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1
NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MjY6NTAuMzk4XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweGUwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjUwLjQx
Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhlMDEsIHR5
cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1MC40MzRdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ZjAwLCB0eXBlID0gMHgxLCByb290
IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MjY6NTAuNDUyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweGYwMSwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRl
ZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4
IDE0OjI2OjUwLjQ3NV0gU2NydWJiaW5nIEZyZWUgUkFNIG9uIDEgbm9kZXMgdXNpbmcgNiBD
UFVzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1MC41ODVdIC4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uZG9uZS4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjUzLjY3OF0gSW5p
dGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1My42OTZdIFN0ZC4gTG9nbGV2ZWw6IEFsbA0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MjY6NTMuNzE0XSBHdWVzdCBMb2dsZXZlbDogQWxsDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDoyNjo1My43MzFdIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBj
b25zb2xlLg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTMuODMzXSAqKiogU2VyaWFsIGlu
cHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0
IHRvIFhlbikNCihYRU4pIFsyMDE0LTExLTE4IDE0OjI2OjUzLjgzNF0gRnJlZWQgMjg0a0Ig
aW5pdCBtZW1vcnkuDQptYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KYWJv
dXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3Jv
dXAgc3Vic3lzIGNwdXNldA0KWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBz
dWJzeXMgY3B1DQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBj
cHVhY2N0DQpbICAgIDAuMDAwMDAwXSBMaW51eCB2ZXJzaW9uIDMuMTguMC1yYzUtMjAxNDEx
MTYtdmFuaWxsYSAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkgKGdjYyB2ZXJzaW9uIDQuNy4yIChE
ZWJpYW4gNC43LjItNSkgKSAjMSBTTVAgVHVlIE5vdiAxOCAxMDoxODoyMyBDRVQgMjAxNA0K
WyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiByb290PS9kZXYvbWFwcGVyL3NlcnZlZXJz
dGVydGplLXJvb3Qgcm8gdmVyYm9zZSBlYXJseXByaW50az14ZW4gbWVtPTE1MzZNIGNvbnNv
bGU9aHZjMCBjb25zb2xlPXR0eTAgdmdhPTc5NCB2aWRlbz12ZXNhZmIgcjgxNjkudXNlX2Rh
Yz0xIGFjcGlfZW5mb3JjZV9yZXNvdXJjZXM9bGF4IG1heF9sb29wPTMwIGxvb3BfbWF4X3Bh
cnQ9MTAgZGVidWcgbG9nbGV2ZWw9MTAgbm9tb2Rlc2V0IHhlbi1wY2liYWNrLmhpZGU9KDAz
OjA2LjApKDA0OjAwLiopKDA3OjAwLiopKDA4OjAwLiopKDA5OjAwLiopKDBhOjAwLjApKDBi
OjAwLjApKDBlOjAwLiopIHI4MTY5LnVzZV9kYWM9MSBhY3BpLmRlYnVnX2xheWVyPTB4NDAw
MDAwIGFjcGkuZGVidWdfbGV2ZWw9MHg0DQpbICAgIDAuMDAwMDAwXSBTZXQgMTI4OTc1MDYz
IHBhZ2UocykgdG8gMS0xIG1hcHBpbmcNClsgICAgMC4wMDAwMDBdIFJlbWFwcGVkIDEwMyBw
YWdlKHMpLCBsYXN0X3Bmbj0zOTMzMTkNClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDAgcGFn
ZShzKQ0KWyAgICAwLjAwMDAwMF0gZTgyMDogQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0g
bWFwOg0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAw
MDAwMDAwMDAwOThmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAw
MDAwMDAwMDA5OTQwMC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAw
MDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMTAwMDAwLTB4MDAwMDAwMDA2MDA2NmZmZl0g
dXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDYwMDY3MDAwLTB4
MDAwMDAwMDA5ZmY4ZmZmZl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwOWZmOTAwMDAtMHgwMDAwMDAwMDlmZjlkZmZmXSBBQ1BJIGRhdGENClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwOWZmOWUwMDAtMHgwMDAwMDAwMDlmZmRm
ZmZmXSBBQ1BJIE5WUw0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA5ZmZl
MDAwMC0weDAwMDAwMDAwOWZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46
IFttZW0gMHgwMDAwMDAwMGY2MDAwMDAwLTB4MDAwMDAwMDBmNjAwM2ZmZl0gcmVzZXJ2ZWQN
ClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAw
MGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAw
MDBmZWMyMDAwMC0weDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAw
XSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBmZWVmZmZmZl0gcmVz
ZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgw
MDAwMDAwMGZmZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwMDEwMDAwMDAwMC0weDAwMDAwMDA1NWZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAu
MDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDBmZDAwMDAwMDAwLTB4MDAwMDAwZmZmZmZmZmZm
Zl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5h
YmxlZA0KWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjog
YWN0aXZlDQpbICAgIDAuMDAwMDAwXSBlODIwOiB1c2VyLWRlZmluZWQgcGh5c2ljYWwgUkFN
IG1hcDoNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4
MDAwMDAwMDAwMDA5OGZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4
MDAwMDAwMDAwMDA5OTQwMC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpbICAgIDAu
MDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAwMDAwNWZmZmZm
ZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwNjAwNjcw
MDAtMHgwMDAwMDAwMDlmZjhmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjog
W21lbSAweDAwMDAwMDAwOWZmOTAwMDAtMHgwMDAwMDAwMDlmZjlkZmZmXSBBQ1BJIGRhdGEN
ClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDlmZjllMDAwLTB4MDAwMDAw
MDA5ZmZkZmZmZl0gQUNQSSBOVlMNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAw
MDAwMDlmZmUwMDAwLTB4MDAwMDAwMDA5ZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGY2MDAwMDAwLTB4MDAwMDAwMDBmNjAwM2ZmZl0g
cmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAw
LTB4MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFtt
ZW0gMHgwMDAwMDAwMGZlYzIwMDAwLTB4MDAwMDAwMDBmZWMyMGZmZl0gcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBm
ZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MGZmZTAwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBd
IHVzZXI6IFttZW0gMHgwMDAwMDAwMTAwMDAwMDAwLTB4MDAwMDAwMDU1ZmZmZmZmZl0gdW51
c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDBmZDAwMDAwMDAwLTB4
MDAwMDAwZmZmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFNNQklPUyAyLjUg
cHJlc2VudC4NClsgICAgMC4wMDAwMDBdIERNSTogTVNJIE1TLTc2NDAvODkwRlhBLUdENzAg
KE1TLTc2NDApICAsIEJJT1MgVjEuOEIxIDA5LzEzLzIwMTANClsgICAgMC4wMDAwMDBdIGU4
MjA6IHVwZGF0ZSBbbWVtIDB4MDAwMDAwMDAtMHgwMDAwMGZmZl0gdXNhYmxlID09PiByZXNl
cnZlZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHgwMDBhMDAwMC0weDAw
MGZmZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIEFHUDogTm8gQUdQIGJyaWRnZSBmb3Vu
ZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDYwMDAwIG1heF9hcmNoX3Bm
biA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBTY2FubmluZyAxIGFyZWFzIGZvciBs
b3cgbWVtb3J5IGNvcnJ1cHRpb24NClsgICAgMC4wMDAwMDBdIEJhc2UgbWVtb3J5IHRyYW1w
b2xpbmUgYXQgW2ZmZmY4ODAwMDAwOTMwMDBdIDkzMDAwIHNpemUgMjQ1NzYNClsgICAgMC4w
MDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgwMDAwMDAwMC0weDAwMGZmZmZm
XQ0KWyAgICAwLjAwMDAwMF0gIFttZW0gMHgwMDAwMDAwMC0weDAwMGZmZmZmXSBwYWdlIDRr
DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4NWZlMDAwMDAt
MHg1ZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4NWZlMDAwMDAtMHg1ZmZmZmZm
Zl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0gQlJLIFsweDAzMjBiMDAwLCAweDAzMjBiZmZm
XSBQR1RBQkxFDQpbICAgIDAuMDAwMDAwXSBCUksgWzB4MDMyMGMwMDAsIDB4MDMyMGNmZmZd
IFBHVEFCTEUNClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHg1
YzAwMDAwMC0weDVmZGZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gIFttZW0gMHg1YzAwMDAwMC0w
eDVmZGZmZmZmXSBwYWdlIDRrDQpbICAgIDAuMDAwMDAwXSBCUksgWzB4MDMyMGQwMDAsIDB4
MDMyMGRmZmZdIFBHVEFCTEUNClsgICAgMC4wMDAwMDBdIEJSSyBbMHgwMzIwZTAwMCwgMHgw
MzIwZWZmZl0gUEdUQUJMRQ0KWyAgICAwLjAwMDAwMF0gQlJLIFsweDAzMjBmMDAwLCAweDAz
MjBmZmZmXSBQR1RBQkxFDQpbICAgIDAuMDAwMDAwXSBCUksgWzB4MDMyMTAwMDAsIDB4MDMy
MTBmZmZdIFBHVEFCTEUNClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFtt
ZW0gMHgwMDEwMDAwMC0weDViZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gIFttZW0gMHgwMDEw
MDAwMC0weDViZmZmZmZmXSBwYWdlIDRrDQpbICAgIDAuMDAwMDAwXSBSQU1ESVNLOiBbbWVt
IDB4MDQwMDAwMDAtMHgwNGYzNWZmZl0NClsgICAgMC4wMDAwMDBdIEFDUEk6IEVhcmx5IHRh
YmxlIGNoZWNrc3VtIHZlcmlmaWNhdGlvbiBkaXNhYmxlZA0KWyAgICAwLjAwMDAwMF0gQUNQ
STogUlNEUCAweDAwMDAwMDAwMDAwRkIxMDAgMDAwMDE0ICh2MDAgQUNQSUFNKQ0KWyAgICAw
LjAwMDAwMF0gQUNQSTogUlNEVCAweDAwMDAwMDAwOUZGOTAwMDAgMDAwMDQ4ICh2MDEgTVNJ
ICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBGQUNQIDB4MDAwMDAwMDA5RkY5MDIwMCAwMDAwODQgKHYwMSA3NjQwTVMgQTc2NDAx
MDAgMjAxMDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IERTRFQg
MHgwMDAwMDAwMDlGRjkwNUUwIDAwOTQyNyAodjAxIEE3NjQwICBBNzY0MDEwMCAwMDAwMDEw
MCBJTlRMIDIwMDUxMTE3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUyAweDAwMDAwMDAw
OUZGOUUwMDAgMDAwMDQwDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBBUElDIDB4MDAwMDAwMDA5
RkY5MDM5MCAwMDAwODggKHYwMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAwMDAw
MDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IE1DRkcgMHgwMDAwMDAwMDlGRjkwNDIwIDAw
MDAzQyAodjAxIDc2NDBNUyBPRU1NQ0ZHICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogU0xJQyAweDAwMDAwMDAwOUZGOTA0NjAgMDAwMTc2ICh2MDEg
TVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBPRU1CIDB4MDAwMDAwMDA5RkY5RTA0MCAwMDAwNzIgKHYwMSA3NjQwTVMgQTc2
NDAxMDAgMjAxMDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNS
QVQgMHgwMDAwMDAwMDlGRjlBNUUwIDAwMDEwOCAodjAzIEFNRCAgICBGQU1fRl8xMCAwMDAw
MDAwMiBBTUQgIDAwMDAwMDAxKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCAweDAwMDAw
MDAwOUZGOUE2RjAgMDAwMDM4ICh2MDEgNzY0ME1TIE9FTUhQRVQgIDIwMTAwOTEzIE1TRlQg
MDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJVlJTIDB4MDAwMDAwMDA5RkY5QTcz
MCAwMDAxMTAgKHYwMSBBTUQgICAgUkQ4OTBTICAgMDAyMDIwMzEgQU1EICAwMDAwMDAwMCkN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQgMHgwMDAwMDAwMDlGRjlBODQwIDAwMERBNCAo
djAxIEEgTSBJICBQT1dFUk5PVyAwMDAwMDAwMSBBTUQgIDAwMDAwMDAxKQ0KWyAgICAwLjAw
MDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAgMC4wMDAw
MDBdIE5VTUEgdHVybmVkIG9mZg0KWyAgICAwLjAwMDAwMF0gRmFraW5nIGEgbm9kZSBhdCBb
bWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwNWZmZmZmZmZdDQpbICAgIDAuMDAw
MDAwXSBOT0RFX0RBVEEoMCkgYWxsb2NhdGVkIFttZW0gMHg1ZmQxNjAwMC0weDVmZDIwZmZm
XQ0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6DQpbICAgIDAuMDAwMDAwXSAgIERNQSAg
ICAgIFttZW0gMHgwMDAwMTAwMC0weDAwZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBETUEz
MiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgTm9y
bWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBmb3IgZWFj
aCBub2RlDQpbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1vcnkgbm9kZSByYW5nZXMNClsgICAg
MC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAwMTAwMC0weDAwMDk4ZmZmXQ0KWyAg
ICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMTAwMDAwLTB4NWZmZmZmZmZdDQpb
ICAgIDAuMDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCBbbWVtIDB4MDAwMDEwMDAtMHg1
ZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAzOTMxMTIN
ClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDY0IHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0K
WyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMjEgcGFnZXMgcmVzZXJ2ZWQNClsgICAgMC4w
MDAwMDBdICAgRE1BIHpvbmU6IDM5OTIgcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAgICAwLjAw
MDAwMF0gICBETUEzMiB6b25lOiA2MDgwIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAw
LjAwMDAwMF0gICBETUEzMiB6b25lOiAzODkxMjAgcGFnZXMsIExJRk8gYmF0Y2g6MzENClsg
ICAgMC4wMDAwMDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4
MDFdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAz
XSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1
XSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDA2XSBhZGRy
ZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KWyAgICAwLjAwMDAwMF0gSU9BUElDWzBd
OiBhcGljX2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIw
MDAwXSBnc2lfYmFzZVsyNF0pDQpbICAgIDAuMDAwMDAwXSBJT0FQSUNbMV06IGFwaWNfaWQg
NywgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUNClsgICAgMC4w
MDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAy
IGRmbCBkZmwpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJ
UlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQg
Ynkgb3ZlcnJpZGUuDQpbICAgIDAuMDAwMDAwXSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01Q
IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQg
aWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAwDQpbICAgIDAuMDAwMDAwXSBzbXBib290OiBB
bGxvd2luZyA2IENQVXMsIDAgaG90cGx1ZyBDUFVzDQpbICAgIDAuMDAwMDAwXSBlODIwOiBb
bWVtIDB4YTAwMDAwMDAtMHhmNWZmZmZmZl0gYXZhaWxhYmxlIGZvciBQQ0kgZGV2aWNlcw0K
WyAgICAwLjAwMDAwMF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbg0K
WyAgICAwLjAwMDAwMF0gWGVuIHZlcnNpb246IDQuNS4wLXJjIChwcmVzZXJ2ZS1BRCkNClsg
ICAgMC4wMDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo4IG5yX2NwdW1hc2tfYml0czo4
IG5yX2NwdV9pZHM6NiBucl9ub2RlX2lkczoxDQpbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVt
YmVkZGVkIDMwIHBhZ2VzL2NwdSBAZmZmZjg4MDA1ZjYwMDAwMCBzODI1NjAgcjgxOTIgZDMy
MTI4IHUyNjIxNDQNClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IHM4MjU2MCByODE5MiBk
MzIxMjggdTI2MjE0NCBhbGxvYz0xKjIwOTcxNTINClsgICAgMC4wMDAwMDBdIHBjcHUtYWxs
b2M6IFswXSAwIDEgMiAzIDQgNSAtIC0gDQpbICAgIDAuMDAwMDAwXSB4ZW46IFBWIHNwaW5s
b2NrcyBlbmFibGVkDQpbICAgIDAuMDAwMDAwXSBCdWlsdCAxIHpvbmVsaXN0cyBpbiBOb2Rl
IG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAzODY5NDcNClsg
ICAgMC4wMDAwMDBdIFBvbGljeSB6b25lOiBETUEzMg0KWyAgICAwLjAwMDAwMF0gS2VybmVs
IGNvbW1hbmQgbGluZTogcm9vdD0vZGV2L21hcHBlci9zZXJ2ZWVyc3RlcnRqZS1yb290IHJv
IHZlcmJvc2UgZWFybHlwcmludGs9eGVuIG1lbT0xNTM2TSBjb25zb2xlPWh2YzAgY29uc29s
ZT10dHkwIHZnYT03OTQgdmlkZW89dmVzYWZiIHI4MTY5LnVzZV9kYWM9MSBhY3BpX2VuZm9y
Y2VfcmVzb3VyY2VzPWxheCBtYXhfbG9vcD0zMCBsb29wX21heF9wYXJ0PTEwIGRlYnVnIGxv
Z2xldmVsPTEwIG5vbW9kZXNldCB4ZW4tcGNpYmFjay5oaWRlPSgwMzowNi4wKSgwNDowMC4q
KSgwNzowMC4qKSgwODowMC4qKSgwOTowMC4qKSgwYTowMC4wKSgwYjowMC4wKSgwZTowMC4q
KSByODE2OS51c2VfZGFjPTEgYWNwaS5kZWJ1Z19sYXllcj0weDQwMDAwMCBhY3BpLmRlYnVn
X2xldmVsPTB4NA0KWyAgICAwLjAwMDAwMF0gUElEIGhhc2ggdGFibGUgZW50cmllczogNDA5
NiAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQ0KWyAgICAwLjAwMDAwMF0gc29mdHdhcmUgSU8g
VExCIFttZW0gMHg1OWMwMDAwMC0weDVkYzAwMDAwXSAoNjRNQikgbWFwcGVkIGF0IFtmZmZm
ODgwMDU5YzAwMDAwLWZmZmY4ODAwNWRiZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBNZW1vcnk6
IDE0MjQxOTJLLzE1NzI0NDhLIGF2YWlsYWJsZSAoMTE5MjBLIGtlcm5lbCBjb2RlLCAxMDQz
SyByd2RhdGEsIDQ0OTZLIHJvZGF0YSwgMTEwNEsgaW5pdCwgMTQxNzZLIGJzcywgMTQ4MjU2
SyByZXNlcnZlZCkNClsgICAgMC4wMDAwMDBdIFNMVUI6IEhXYWxpZ249NjQsIE9yZGVyPTAt
MywgTWluT2JqZWN0cz0wLCBDUFVzPTYsIE5vZGVzPTENClsgICAgMC4wMDAwMDBdIEhpZXJh
cmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDAuMDAwMDAwXSAJUkNVIGR5bnRp
Y2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVuYWJsZWQuDQpbICAgIDAu
MDAwMDAwXSAJQWRkaXRpb25hbCBwZXItQ1BVIGluZm8gcHJpbnRlZCB3aXRoIHN0YWxscy4N
ClsgICAgMC4wMDAwMDBdIAlSQ1UgcmVzdHJpY3RpbmcgQ1BVcyBmcm9tIE5SX0NQVVM9OCB0
byBucl9jcHVfaWRzPTYuDQpbICAgIDAuMDAwMDAwXSBSQ1U6IEFkanVzdGluZyBnZW9tZXRy
eSBmb3IgcmN1X2Zhbm91dF9sZWFmPTE2LCBucl9jcHVfaWRzPTYNClsgICAgMC4wMDAwMDBd
IE5SX0lSUVM6NDM1MiBucl9pcnFzOjEwMTYgMA0KWyAgICAwLjAwMDAwMF0geGVuOmV2ZW50
czogVXNpbmcgRklGTy1iYXNlZCBBQkkNClsgICAgMC4wMDAwMDBdIHhlbjogc2NpIG92ZXJy
aWRlOiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTENClsgICAgMC4wMDAwMDBd
IHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAg
MC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNjo1My45ODZdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg2LTkgLT4gMHg2MCAtPiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQpbICAgIDAuMDAwMDAw
XSB4ZW46IGFjcGkgc2NpIDkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MSAtPiBp
cnE9MSAoZ3NpPTEpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTIgLT4gaXJxPTIg
KGdzaT0yKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0zIC0+IGlycT0zIChnc2k9
MykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NCAtPiBpcnE9NCAoZ3NpPTQpDQpb
ICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTUgLT4gaXJxPTUgKGdzaT01KQ0KWyAgICAw
LjAwMDAwMF0geGVuOiAtLT4gcGlycT02IC0+IGlycT02IChnc2k9NikNClsgICAgMC4wMDAw
MDBdIHhlbjogLS0+IHBpcnE9NyAtPiBpcnE9NyAoZ3NpPTcpDQpbICAgIDAuMDAwMDAwXSB4
ZW46IC0tPiBwaXJxPTggLT4gaXJxPTggKGdzaT04KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAt
LT4gcGlycT0xMCAtPiBpcnE9MTAgKGdzaT0xMCkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+
IHBpcnE9MTEgLT4gaXJxPTExIChnc2k9MTEpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBw
aXJxPTEyIC0+IGlycT0xMiAoZ3NpPTEyKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGly
cT0xMyAtPiBpcnE9MTMgKGdzaT0xMykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9
MTQgLT4gaXJxPTE0IChnc2k9MTQpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTE1
IC0+IGlycT0xNSAoZ3NpPTE1KQ0KWyAgICAwLjAwMDAwMF0gQ29uc29sZTogY29sb3VyIGR1
bW15IGRldmljZSA4MHgyNQ0KWyAgICAwLjAwMDAwMF0gY29uc29sZSBbdHR5MF0gZW5hYmxl
ZA0KWyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW3hlbmJvb3QwXSBkaXNhYmxlZA0KWyAg
ICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQpbICAgIDAu
MDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUNClsgICAgMC4wMDAwMDBd
IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdWFjY3QNClsgICAgMC4wMDAwMDBdIExp
bnV4IHZlcnNpb24gMy4xOC4wLXJjNS0yMDE0MTExNi12YW5pbGxhIChyb290QHNlcnZlZXJz
dGVydGplKSAoZ2NjIHZlcnNpb24gNC43LjIgKERlYmlhbiA0LjcuMi01KSApICMxIFNNUCBU
dWUgTm92IDE4IDEwOjE4OjIzIENFVCAyMDE0DQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxp
bmU6IHJvb3Q9L2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtcm9vdCBybyB2ZXJib3NlIGVh
cmx5cHJpbnRrPXhlbiBtZW09MTUzNk0gY29uc29sZT1odmMwIGNvbnNvbGU9dHR5MCB2Z2E9
Nzk0IHZpZGVvPXZlc2FmYiByODE2OS51c2VfZGFjPTEgYWNwaV9lbmZvcmNlX3Jlc291cmNl
cz1sYXggbWF4X2xvb3A9MzAgbG9vcF9tYXhfcGFydD0xMCBkZWJ1ZyBsb2dsZXZlbD0xMCBu
b21vZGVzZXQgeGVuLXBjaWJhY2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAuKikoMDc6MDAuKiko
MDg6MDAuKikoMDk6MDAuKikoMGE6MDAuMCkoMGI6MDAuMCkoMGU6MDAuKikgcjgxNjkudXNl
X2RhYz0xIGFjcGkuZGVidWdfbGF5ZXI9MHg0MDAwMDAgYWNwaS5kZWJ1Z19sZXZlbD0weDQN
ClsgICAgMC4wMDAwMDBdIHRzZWc6IDAwMDAwMDAwMDANClsgICAgMC4wMDAwMDBdIFNldCAx
Mjg5NzUwNjMgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUmVtYXBw
ZWQgMTAzIHBhZ2UocyksIGxhc3RfcGZuPTM5MzMxOQ0KWyAgICAwLjAwMDAwMF0gUmVsZWFz
ZWQgMCBwYWdlKHMpDQpbICAgIDAuMDAwMDAwXSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNp
Y2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAw
MDAwLTB4MDAwMDAwMDAwMDA5OGZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFtt
ZW0gMHgwMDAwMDAwMDAwMDk5NDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDYw
MDY2ZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwNjAw
NjcwMDAtMHgwMDAwMDAwMDlmZjhmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDA5ZmY5MDAwMC0weDAwMDAwMDAwOWZmOWRmZmZdIEFDUEkgZGF0
YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA5ZmY5ZTAwMC0weDAwMDAw
MDAwOWZmZGZmZmZdIEFDUEkgTlZTDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAw
MDAwMDlmZmUwMDAwLTB4MDAwMDAwMDA5ZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwZjYwMDAwMDAtMHgwMDAwMDAwMGY2MDAzZmZmXSBy
ZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWMwMDAwMC0w
eDAwMDAwMDAwZmVjMDBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0g
MHgwMDAwMDAwMGZlYzIwMDAwLTB4MDAwMDAwMDBmZWMyMGZmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVlMDAwMDAtMHgwMDAwMDAwMGZlZWZm
ZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZmUw
MDAwMC0weDAwMDAwMDAwZmZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46
IFttZW0gMHgwMDAwMDAwMTAwMDAwMDAwLTB4MDAwMDAwMDU1ZmZmZmZmZl0gdW51c2FibGUN
ClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMGZkMDAwMDAwMDAtMHgwMDAwMDBm
ZmZmZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW3hlbmJv
b3QwXSBlbmFibGVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDYwMDAw
MDAwLTB4ZmZmZmZmZmZmZmZmZmZmZV0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBOWCAoRXhl
Y3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUNClsgICAgMC4wMDAwMDBdIGU4MjA6
IHVzZXItZGVmaW5lZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAwLjAwMDAwMF0gdXNlcjog
W21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAwMDAwMDAwMDk4ZmZmXSB1c2FibGUNClsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDk5NDAwLTB4MDAwMDAwMDAw
MDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MDAwMTAwMDAwLTB4MDAwMDAwMDA1ZmZmZmZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1
c2VyOiBbbWVtIDB4MDAwMDAwMDA2MDA2NzAwMC0weDAwMDAwMDAwOWZmOGZmZmZdIHVudXNh
YmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDA5ZmY5MDAwMC0weDAw
MDAwMDAwOWZmOWRmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAw
eDAwMDAwMDAwOWZmOWUwMDAtMHgwMDAwMDAwMDlmZmRmZmZmXSBBQ1BJIE5WUw0KWyAgICAw
LjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwOWZmZTAwMDAtMHgwMDAwMDAwMDlmZmZm
ZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZjYw
MDAwMDAtMHgwMDAwMDAwMGY2MDAzZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNl
cjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZl
ZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmVjMjAwMDAtMHgwMDAw
MDAwMGZlYzIwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAw
MDAwMDAwZmVlMDAwMDAtMHgwMDAwMDAwMGZlZWZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAw
MDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZmZmZm
XSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAxMDAwMDAw
MDAtMHgwMDAwMDAwNTVmZmZmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjog
W21lbSAweDAwMDAwMGZkMDAwMDAwMDAtMHgwMDAwMDBmZmZmZmZmZmZmXSByZXNlcnZlZA0K
WyAgICAwLjAwMDAwMF0gU01CSU9TIDIuNSBwcmVzZW50Lg0KWyAgICAwLjAwMDAwMF0gRE1J
OiBNU0kgTVMtNzY0MC84OTBGWEEtR0Q3MCAoTVMtNzY0MCkgICwgQklPUyBWMS44QjEgMDkv
MTMvMjAxMA0KWyAgICAwLjAwMDAwMF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0w
eDAwMDAwZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOlsg
ICAxNS43NTYyNjZdIHBjaWJhY2sgMDAwMDowODowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNw
YWNlIGF0IG9mZnNldCAweDNjICh3YXMgMHgxMDAsIHdyaXRpbmcgMHgxMDcpDQpbICAgMTUu
NzU2NTEwXSBwY2liYWNrIDAwMDA6MDg6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBh
dCBvZmZzZXQgMHgxMCAod2FzIDB4NCwgd3JpdGluZyAweGZlMGZlMDA0KQ0KWyAgIDE1Ljc1
Njc0MF0gcGNpYmFjayAwMDAwOjA4OjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQg
b2Zmc2V0IDB4YyAod2FzIDB4MCwgd3JpdGluZyAweDEwKQ0KWyAgIDE1Ljc1Njk1NF0gcGNp
YmFjayAwMDAwOjA4OjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4
NCAod2FzIDB4MTAwMDAwLCB3cml0aW5nIDB4MTAwMTAyKQ0KWyAgIDE1Ljc1NzMwOF0geGVu
OiByZWdpc3RlcmluZyBnc2kgMzMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxNS43
NTc0NjBdIHhlbjogLS0+IHBpcnE9MzMgLT4gaXJxPTMzIChnc2k9MzMpDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNjo1Ni45NDFdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg3LTkgLT4gMHhjMSAtPiBJUlEgMzMgTW9kZToxIEFjdGl2ZToxKQ0KWyAgIDE1Ljc4MzAy
OF0gcGNpYmFjayAwMDAwOjA5OjAwLjA6IGVuYWJsaW5nIGRldmljZSAoMDAwMCAtPiAwMDAz
KQ0KWyAgIDE1Ljc4MzIwN10geGVuOiByZWdpc3RlcmluZyBnc2kgMzIgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDENClsgICAxNS43ODMzNTNdIHhlbjogLS0+IHBpcnE9MzIgLT4gaXJxPTMy
IChnc2k9MzIpDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1Ni45NjddIElPQVBJQ1sxXTog
U2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTggLT4gMHhjOSAtPiBJUlEgMzIgTW9kZToxIEFj
dGl2ZToxKQ0KWyAgIDE1LjgwOTY1OF0geGVuOiByZWdpc3RlcmluZyBnc2kgNDcgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAxNS44MDk4MDZdIHhlbjogLS0+IHBpcnE9NDcgLT4g
aXJxPTQ3IChnc2k9NDcpDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1Ni45OTNdIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTIzIC0+IDB4ZDEgLT4gSVJRIDQ3IE1v
ZGU6MSBBY3RpdmU6MSkNClsgICAxNi44MTk2NzBdIHBjaWJhY2sgMDAwMDowYTowMC4wOiBy
ZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweDNjICh3YXMgMHgxMDAsIHdyaXRp
bmcgMHgxMGEpDQpbICAgMTYuODE5OTE3XSBwY2liYWNrIDAwMDA6MGE6MDAuMDogcmVzdG9y
aW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHgxMCAod2FzIDB4NCwgd3JpdGluZyAweGZl
MjAwMDA0KQ0KWyAgIDE2LjgyMDE0OF0gcGNpYmFjayAwMDAwOjBhOjAwLjA6IHJlc3Rvcmlu
ZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4YyAod2FzIDB4MCwgd3JpdGluZyAweDEwKQ0K
WyAgIDE2LjgyMDM2M10gcGNpYmFjayAwMDAwOjBhOjAwLjA6IHJlc3RvcmluZyBjb25maWcg
c3BhY2UgYXQgb2Zmc2V0IDB4NCAod2FzIDB4MTAwMDAwLCB3cml0aW5nIDB4MTAwMTA2KQ0K
WyAgIDE2LjgyNzEwMF0geGVuOiByZWdpc3RlcmluZyBnc2kgNDggdHJpZ2dlcmluZyAwIHBv
bGFyaXR5IDENClsgICAxNi44MzM1OTRdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6NDgNClsg
ICAxNy44NDk1OTZdIHBjaWJhY2sgMDAwMDowYjowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNw
YWNlIGF0IG9mZnNldCAweDNjICh3YXMgMHgxMDAsIHdyaXRpbmcgMHgxMGEpDQpbICAgMTcu
ODU2MzAxXSBwY2liYWNrIDAwMDA6MGI6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBh
dCBvZmZzZXQgMHgxMCAod2FzIDB4NCwgd3JpdGluZyAweGZlNWZlMDA0KQ0KWyAgIDE3Ljg2
MjkyMl0gcGNpYmFjayAwMDAwOjBiOjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQg
b2Zmc2V0IDB4YyAod2FzIDB4MCwgd3JpdGluZyAweDEwKQ0KWyAgIDE3Ljg2OTUwOF0gcGNp
YmFjayAwMDAwOjBiOjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4
NCAod2FzIDB4MTAwMDAwLCB3cml0aW5nIDB4MTAwMTAyKQ0KWyAgIDE3Ljg3NjIxMF0geGVu
OiByZWdpc3RlcmluZyBnc2kgMjkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxNy44
ODI3OTFdIHhlbjogLS0+IHBpcnE9MjkgLT4gaXJxPTI5IChnc2k9MjkpDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNjo1OS4wNzNdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg3LTUgLT4gMHhkOSAtPiBJUlEgMjkgTW9kZToxIEFjdGl2ZToxKQ0KWyAgIDE3LjkxMzAy
N10gcGNpYmFjayAwMDAwOjBlOjAwLjA6IGVuYWJsaW5nIGRldmljZSAoMDAwMCAtPiAwMDAz
KQ0KWyAgIDE3LjkxOTY3OF0geGVuOiByZWdpc3RlcmluZyBnc2kgMjggdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDENClsgICAxNy45MjYzMjRdIHhlbjogLS0+IHBpcnE9MjggLT4gaXJxPTI4
IChnc2k9MjgpDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1OS4xMTZdIElPQVBJQ1sxXTog
U2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTQgLT4gMHgyMiAtPiBJUlEgMjggTW9kZToxIEFj
dGl2ZToxKQ0KWyAgIDE3Ljk1OTkzNV0geGVuX3BjaWJhY2s6IGJhY2tlbmQgaXMgdnBjaQ0K
WyAgIDE3Ljk2NjkyOF0geGVuX2FjcGlfcHJvY2Vzc29yOiBVcGxvYWRpbmcgWGVuIHByb2Nl
c3NvciBQTSBpbmZvDQpbICAgMTcuOTc1MDI2XSBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVy
LCA0IHBvcnRzLCBJUlEgc2hhcmluZyBlbmFibGVkDQpbICAgMTcuOTgyODU2XSBocGV0X2Fj
cGlfYWRkOiBubyBhZGRyZXNzIG9yIGlycXMgaW4gX0NSUw0KWyAgIDE3Ljk4OTcxOF0gTGlu
dXggYWdwZ2FydCBpbnRlcmZhY2UgdjAuMTAzDQpbICAgMTcuOTk2ODE4XSBIYW5nY2hlY2s6
IHN0YXJ0aW5nIGhhbmdjaGVjayB0aW1lciAwLjkuMSAodGljayBpcyAxODAgc2Vjb25kcywg
bWFyZ2luIGlzIDYwIHNlY29uZHMpLg0KWyAgIDE4LjAwMzUwNV0gW2RybV0gSW5pdGlhbGl6
ZWQgZHJtIDEuMS4wIDIwMDYwODEwDQpbICAgMTguMDEwMTE0XSBbZHJtXSBWR0FDT04gZGlz
YWJsZSByYWRlb24ga2VybmVsIG1vZGVzZXR0aW5nLg0KWyAgIDE4LjAxNjY5NV0gW2RybTpy
YWRlb25faW5pdF0gKkVSUk9SKiBObyBVTVMgc3VwcG9ydCBpbiByYWRlb24gbW9kdWxlIQ0K
WyAgIDE4LjAyNjYwNV0gYnJkOiBtb2R1bGUgbG9hZGVkDQpbICAgMTguMDQxMjUwXSBsb29w
OiBtb2R1bGUgbG9hZGVkDQpbICAgMTguMDQ4MTQxXSBhaGNpIDAwMDA6MDA6MTEuMDogdmVy
c2lvbiAzLjANClsgICAxOC4wNTQ3NTVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE5IHRyaWdn
ZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguMDYxMjA3XSB4ZW46IC0tPiBwaXJxPTE5IC0+
IGlycT0xOSAoZ3NpPTE5KQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTkuMjUxXSBJT0FQ
SUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOSAtPiAweDJhIC0+IElSUSAxOSBN
b2RlOjEgQWN0aXZlOjEpDQpbICAgMTguMDY3ODU0XSBhaGNpIDAwMDA6MDA6MTEuMDogQUhD
SSAwMDAxLjAyMDAgMzIgc2xvdHMgNiBwb3J0cyA2IEdicHMgMHgzZiBpbXBsIFNBVEEgbW9k
ZQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MjY6NTkuMjYzXSAtLU1BUkstLQ0KWyAgIDE4LjA3
NDMwMF0gYWhjaSAwMDAwOjAwOjExLjA6IGZsYWdzOiA2NGJpdCBuY3Egc250ZiBpbGNrIHBt
IGxlZCBjbG8gcG1wIHBpbyBzbHVtIHBhcnQgDQpbICAgMTguMDgzMzUyXSBzY3NpIGhvc3Qw
OiBhaGNpDQpbICAgMTguMDkwMTI2XSBzY3NpIGhvc3QxOiBhaGNpDQpbICAgMTguMDk2NzA0
XSBzY3NpIGhvc3QyOiBhaGNpDQpbICAgMTguMTAzMjAyXSBzY3NpIGhvc3QzOiBhaGNpDQpb
ICAgMTguMTA5NjA3XSBzY3NpIGhvc3Q0OiBhaGNpDQpbICAgMTguMTE1ODk0XSBzY3NpIGhv
c3Q1OiBhaGNpDQpbICAgMTguMTIxODI1XSBhdGExOiBTQVRBIG1heCBVRE1BLzEzMyBhYmFy
IG0xMDI0QDB4ZmRiZmYwMDAgcG9ydCAweGZkYmZmMTAwIGlycSAxMTQNClsgICAxOC4xMjc4
MThdIGF0YTI6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZGJmZjAwMCBwb3J0
IDB4ZmRiZmYxODAgaXJxIDExNQ0KWyAgIDE4LjEzMzczNl0gYXRhMzogU0FUQSBtYXggVURN
QS8xMzMgYWJhciBtMTAyNEAweGZkYmZmMDAwIHBvcnQgMHhmZGJmZjIwMCBpcnEgMTE2DQpb
ICAgMTguMTM5NDYyXSBhdGE0OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmRi
ZmYwMDAgcG9ydCAweGZkYmZmMjgwIGlycSAxMTcNClsgICAxOC4xNDUxOTVdIGF0YTU6IFNB
VEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZGJmZjAwMCBwb3J0IDB4ZmRiZmYzMDAg
aXJxIDExOA0KWyAgIDE4LjE1MDkwOF0gYXRhNjogU0FUQSBtYXggVURNQS8xMzMgYWJhciBt
MTAyNEAweGZkYmZmMDAwIHBvcnQgMHhmZGJmZjM4MCBpcnEgMTE5DQpbICAgMTguMTU2NjYz
XSB0dW46IFVuaXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2ZXIsIDEuNg0KWyAgIDE4LjE2
MjE4NF0gdHVuOiAoQykgMTk5OS0yMDA0IE1heCBLcmFzbnlhbnNreSA8bWF4a0BxdWFsY29t
bS5jb20+DQpbICAgMTguMTY3ODU0XSBlMTAwMDogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29y
ayBEcml2ZXIgLSB2ZXJzaW9uIDcuMy4yMS1rOC1OQVBJDQpbICAgMTguMTczNDc4XSBlMTAw
MDogQ29weXJpZ2h0IChjKSAxOTk5LTIwMDYgSW50ZWwgQ29ycG9yYXRpb24uDQpbICAgMTgu
MTc5MTIxXSBlMTAwMGU6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgRHJpdmVyIC0gMi4z
LjItaw0KWyAgIDE4LjE4NDY1Nl0gZTEwMDBlOiBDb3B5cmlnaHQoYykgMTk5OSAtIDIwMTQg
SW50ZWwgQ29ycG9yYXRpb24uDQpbICAgMTguMTkwMjc4XSBpZ2I6IEludGVsKFIpIEdpZ2Fi
aXQgRXRoZXJuZXQgTmV0d29yayBEcml2ZXIgLSB2ZXJzaW9uIDUuMi4xNS1rDQpbICAgMTgu
MTk1OTM5XSBpZ2I6IENvcHlyaWdodCAoYykgMjAwNy0yMDE0IEludGVsIENvcnBvcmF0aW9u
Lg0KWyAgIDE4LjIwMTczM10gaWdidmY6IEludGVsKFIpIEdpZ2FiaXQgVmlydHVhbCBGdW5j
dGlvbiBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gMi4wLjItaw0KWyAgIDE4LjIwNzQ1Ml0g
aWdidmY6IENvcHlyaWdodCAoYykgMjAwOSAtIDIwMTIgSW50ZWwgQ29ycG9yYXRpb24uDQpb
ICAgMTguMjEzMjM2XSByODE2OSBHaWdhYml0IEV0aGVybmV0IGRyaXZlciAyLjNMSy1OQVBJ
IGxvYWRlZA0KWyAgIDE4LjIxOTAxOF0geGVuOiByZWdpc3RlcmluZyBnc2kgNDYgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAxOC4yMjQ3NjRdIHhlbjogLS0+IHBpcnE9NDYgLT4g
aXJxPTQ2IChnc2k9NDYpDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNjo1OS40MTRdIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTIyIC0+IDB4NzIgLT4gSVJRIDQ2IE1v
ZGU6MSBBY3RpdmU6MSkNClsgICAxOC4yMzA0OTBdIHI4MTY5IDAwMDA6MGQ6MDAuMDogZW5h
YmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTguMjM2NjQ4XSByODE2OSAwMDAwOjBkOjAwLjAg
ZXRoMDogUlRMODE2OGQvODExMWQgYXQgMHhmZmZmYzkwMDAwMzY0MDAwLCA0MDo2MTo4Njpm
NDo2NzpkOSwgWElEIDA4MTAwMGMwIElSUSAxMjINClsgICAxOC4yNDI2MTJdIHI4MTY5IDAw
MDA6MGQ6MDAuMCBldGgwOiBqdW1ibyBmZWF0dXJlcyBbZnJhbWVzOiA5MjAwIGJ5dGVzLCB0
eCBjaGVja3N1bW1pbmc6IGtvXQ0KWyAgIDE4LjI0ODUzMV0gcjgxNjkgR2lnYWJpdCBFdGhl
cm5ldCBkcml2ZXIgMi4zTEstTkFQSSBsb2FkZWQNClsgICAxOC4yNTQ0NjddIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDUxIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguMjYwNDE0
XSB4ZW46IC0tPiBwaXJxPTUxIC0+IGlycT01MSAoZ3NpPTUxKQ0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MjY6NTkuNDUwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0y
NyAtPiAweDhhIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpDQpbICAgMTguMjY2MzUzXSBy
ODE2OSAwMDAwOjBjOjAwLjA6IGVuYWJsaW5nIE1lbS1Xci1JbnZhbA0KWyAgIDE4LjI3MjYw
M10gcjgxNjkgMDAwMDowYzowMC4wIGV0aDE6IFJUTDgxNjhkLzgxMTFkIGF0IDB4ZmZmZmM5
MDAwMDM2NjAwMCwgNDA6NjE6ODY6ZjQ6Njc6ZDgsIFhJRCAwODEwMDBjMCBJUlEgMTIzDQpb
ICAgMTguMjc4NjM0XSByODE2OSAwMDAwOjBjOjAwLjAgZXRoMToganVtYm8gZmVhdHVyZXMg
W2ZyYW1lczogOTIwMCBieXRlcywgdHggY2hlY2tzdW1taW5nOiBrb10NClsgICAxOC4yODQ2
NjldIHhlbl9uZXRmcm9udDogSW5pdGlhbGlzaW5nIFhlbiB2aXJ0dWFsIGV0aGVybmV0IGRy
aXZlcg0KWyAgIDE4LjI5MTAyNF0gZWhjaV9oY2Q6IFVTQiAyLjAgJ0VuaGFuY2VkJyBIb3N0
IENvbnRyb2xsZXIgKEVIQ0kpIERyaXZlcg0KWyAgIDE4LjI5NzEwMV0gZWhjaS1wY2k6IEVI
Q0kgUENJIHBsYXRmb3JtIGRyaXZlcg0KWyAgIDE4LjMwMzM1OV0geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxOC4zMDkzNjddIEFscmVh
ZHkgc2V0dXAgdGhlIEdTSSA6MTcNClsgICAxOC4zMTU0MDVdIFFVSVJLOiBFbmFibGUgQU1E
IFBMTCBmaXgNClsgICAxOC4zMjE0MDBdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogZW5hYmxp
bmcgYnVzIG1hc3RlcmluZw0KWyAgIDE4LjMyNzQyMF0gZWhjaS1wY2kgMDAwMDowMDoxMi4y
OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgIDE4LjMzMzcyMl0gZWhjaS1wY2kgMDAwMDow
MDoxMi4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDEN
ClsgICAxOC4zMzk3MTVdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogYXBwbHlpbmcgQU1EIFNC
NzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kDQpbICAgMTgu
MzQ1Nzg4XSBlaGNpLXBjaSAwMDAwOjAwOjEyLjI6IGRlYnVnIHBvcnQgMQ0KWyAgIDE4LjM1
MTg5MV0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBlbmFibGluZyBNZW0tV3ItSW52YWwNClsg
ICAxOC4zNTc4NzhdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogaXJxIDE3LCBpbyBtZW0gMHhm
ZGJmZjQwMA0KWyAgIDE4LjM3MjkyOF0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBVU0IgMi4w
IHN0YXJ0ZWQsIEVIQ0kgMS4wMA0KWyAgIDE4LjM3ODkwNl0gdXNiIHVzYjE6IE5ldyBVU0Ig
ZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMg0KWyAgIDE4LjM4
NDY5MV0gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0
PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgMTguMzkwNDU4XSB1c2IgdXNiMTogUHJvZHVjdDog
RUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAxOC4zOTYxNzhdIHVzYiB1c2IxOiBNYW51ZmFj
dHVyZXI6IExpbnV4IDMuMTguMC1yYzUtMjAxNDExMTYtdmFuaWxsYSBlaGNpX2hjZA0KWyAg
IDE4LjQwMTk2OV0gdXNiIHVzYjE6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMi4yDQpbICAg
MTguNDA4MzI1XSBodWIgMS0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgIDE4LjQxNDA5N10g
aHViIDEtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQNClsgICAxOC40MjA0NDJdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguNDI2MjMw
XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3DQpbICAgMTguNDMxOTUzXSBlaGNpLXBjaSAw
MDAwOjAwOjEzLjI6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNClsgICAxOC40Mzc2OTFdIGVo
Y2ktcGNpIDAwMDA6MDA6MTMuMjogRUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAxOC40NDM0
ODJdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNz
aWduZWQgYnVzIG51bWJlciAyDQpbICAgMTguNDQ5MjM0XSBlaGNpLXBjaSAwMDAwOjAwOjEz
LjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWgg
d29ya2Fyb3VuZA0KWyAgIDE4LjQ1NTE0Ml0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBkZWJ1
ZyBwb3J0IDENClsgICAxOC40NjExOTJdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogZW5hYmxp
bmcgTWVtLVdyLUludmFsDQpbICAgMTguNDY3MTgzXSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6
IGlycSAxNywgaW8gbWVtIDB4ZmRiZmY4MDANClsgICAxOC40NzYzMTNdIGF0YTY6IFNBVEEg
bGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQ0KWyAgIDE4LjQ4MjU1OF0gYXRh
MjogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApDQpbICAgMTguNDgy
ODQwXSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAw
DQpbICAgMTguNDgyOTE0XSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVu
ZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyDQpbICAgMTguNDgyOTE1XSB1c2IgdXNiMjogTmV3
IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEN
ClsgICAxOC40ODI5MTddIHVzYiB1c2IyOiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxl
cg0KWyAgIDE4LjQ4MjkxOF0gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGludXggMy4xOC4w
LXJjNS0yMDE0MTExNi12YW5pbGxhIGVoY2lfaGNkDQpbICAgMTguNDgyOTE5XSB1c2IgdXNi
MjogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEzLjINClsgICAxOC40ODMyMTJdIGh1YiAyLTA6
MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgMTguNDgzMjIzXSBodWIgMi0wOjEuMDogNSBwb3J0
cyBkZXRlY3RlZA0KWyAgIDE4LjQ4MzY2MF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJp
Z2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxOC40ODM2NjJdIEFscmVhZHkgc2V0dXAgdGhl
IEdTSSA6MTcNClsgICAxOC40ODM2OTBdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogZW5hYmxp
bmcgYnVzIG1hc3RlcmluZw0KWyAgIDE4LjQ4MzcxOF0gZWhjaS1wY2kgMDAwMDowMDoxNi4y
OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgIDE4LjQ4Mzk0OV0gZWhjaS1wY2kgMDAwMDow
MDoxNi4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDMN
ClsgICAxOC40ODM5NTNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogYXBwbHlpbmcgQU1EIFNC
NzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kDQpbICAgMTgu
NDgzOTczXSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGRlYnVnIHBvcnQgMQ0KWyAgIDE4LjQ4
NDA1MV0gZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBlbmFibGluZyBNZW0tV3ItSW52YWwNClsg
ICAxOC40ODQwNjBdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogaXJxIDE3LCBpbyBtZW0gMHhm
ZGJmZmMwMA0KWyAgIDE4LjQ5Mjg0N10gZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBVU0IgMi4w
IHN0YXJ0ZWQsIEVIQ0kgMS4wMA0KWyAgIDE4LjQ5MjkxNl0gdXNiIHVzYjM6IE5ldyBVU0Ig
ZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMg0KWyAgIDE4LjQ5
MjkxOF0gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0
PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgMTguNDkyOTE5XSB1c2IgdXNiMzogUHJvZHVjdDog
RUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAxOC40OTI5MjFdIHVzYiB1c2IzOiBNYW51ZmFj
dHVyZXI6IExpbnV4IDMuMTguMC1yYzUtMjAxNDExMTYtdmFuaWxsYSBlaGNpX2hjZA0KWyAg
IDE4LjQ5MjkyMV0gdXNiIHVzYjM6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxNi4yDQpbICAg
MTguNDkzMjUyXSBodWIgMy0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgIDE4LjQ5MzI2M10g
aHViIDMtMDoxLjA6IDQgcG9ydHMgZGV0ZWN0ZWQNClsgICAxOC40OTM1MTZdIG9oY2lfaGNk
OiBVU0IgMS4xICdPcGVuJyBIb3N0IENvbnRyb2xsZXIgKE9IQ0kpIERyaXZlcg0KWyAgIDE4
LjQ5MzUyN10gb2hjaS1wY2k6IE9IQ0kgUENJIHBsYXRmb3JtIGRyaXZlcg0KWyAgIDE4LjQ5
MzY5Nl0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEN
ClsgICAxOC40OTM2OThdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNClsgICAxOC40OTM3
MjBdIG9oY2ktcGNpIDAwMDA6MDA6MTIuMDogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAg
IDE4LjQ5MzczNF0gb2hjaS1wY2kgMDAwMDowMDoxMi4wOiBPSENJIFBDSSBob3N0IGNvbnRy
b2xsZXINClsgICAxOC40OTM5ODhdIG9oY2ktcGNpIDAwMDA6MDA6MTIuMDogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA0DQpbICAgMTguNDk0MTM5XSBv
aGNpLXBjaSAwMDAwOjAwOjEyLjA6IGlycSAxOCwgaW8gbWVtIDB4ZmRiZjcwMDANClsgICAx
OC41NTA0NjddIHVzYiB1c2I0OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2
YiwgaWRQcm9kdWN0PTAwMDENClsgICAxOC41NTA0NjhdIHVzYiB1c2I0OiBOZXcgVVNCIGRl
dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgIDE4
LjU1MDQ2OV0gdXNiIHVzYjQ6IFByb2R1Y3Q6IE9IQ0kgUENJIGhvc3QgY29udHJvbGxlcg0K
WyAgIDE4LjU1MDQ3MF0gdXNiIHVzYjQ6IE1hbnVmYWN0dXJlcjogTGludXggMy4xOC4wLXJj
NS0yMDE0MTExNi12YW5pbGxhIG9oY2lfaGNkDQpbICAgMTguNTUwNDcxXSB1c2IgdXNiNDog
U2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEyLjANClsgICAxOC41NTA3NzZdIGh1YiA0LTA6MS4w
OiBVU0IgaHViIGZvdW5kDQpbICAgMTguNTUwNzkyXSBodWIgNC0wOjEuMDogNSBwb3J0cyBk
ZXRlY3RlZA0KWyAgIDE4LjU1MTE4MF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAxOC41NTExODNdIEFscmVhZHkgc2V0dXAgdGhlIEdT
SSA6MTgNClsgICAxOC41NTEyMDRdIG9oY2ktcGNpIDAwMDA6MDA6MTMuMDogZW5hYmxpbmcg
YnVzIG1hc3RlcmluZw0KWyAgIDE4LjU1MTIxMl0gb2hjaS1wY2kgMDAwMDowMDoxMy4wOiBP
SENJIFBDSSBob3N0IGNvbnRyb2xsZXINClsgICAxOC41NTE0NDRdIG9oY2ktcGNpIDAwMDA6
MDA6MTMuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA1
DQpbICAgMTguNTUxNTI3XSBvaGNpLXBjaSAwMDAwOjAwOjEzLjA6IGlycSAxOCwgaW8gbWVt
IDB4ZmRiZmMwMDANClsgICAxOC42MDcwOTJdIHVzYiB1c2I1OiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDENClsgICAxOC42MDcwOTRdIHVz
YiB1c2I1OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJp
YWxOdW1iZXI9MQ0KWyAgIDE4LjYwNzA5NV0gdXNiIHVzYjU6IFByb2R1Y3Q6IE9IQ0kgUENJ
IGhvc3QgY29udHJvbGxlcg0KWyAgIDE4LjYwNzA5NV0gdXNiIHVzYjU6IE1hbnVmYWN0dXJl
cjogTGludXggMy4xOC4wLXJjNS0yMDE0MTExNi12YW5pbGxhIG9oY2lfaGNkDQpbICAgMTgu
NjA3MDk2XSB1c2IgdXNiNTogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEzLjANClsgICAxOC42
MDczODJdIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgMTguNjA3Mzk1XSBodWIg
NS0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgIDE4LjYwNzc4N10geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxOC42MDc3OTJdIEFs
cmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNClsgICAxOC42MDc4MTRdIG9oY2ktcGNpIDAwMDA6
MDA6MTQuNTogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAgIDE4LjYwNzgyMV0gb2hjaS1w
Y2kgMDAwMDowMDoxNC41OiBPSENJIFBDSSBob3N0IGNvbnRyb2xsZXINClsgICAxOC42MDgw
NTNdIG9oY2ktcGNpIDAwMDA6MDA6MTQuNTogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNz
aWduZWQgYnVzIG51bWJlciA2DQpbICAgMTguNjA4MTM3XSBvaGNpLXBjaSAwMDAwOjAwOjE0
LjU6IGlycSAxOCwgaW8gbWVtIDB4ZmRiZmQwMDANClsgICAxOC42NjM1NzVdIHVzYiB1c2I2
OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDEN
ClsgICAxOC42NjM1NzddIHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9
MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgIDE4LjY2MzU3OF0gdXNiIHVzYjY6
IFByb2R1Y3Q6IE9IQ0kgUENJIGhvc3QgY29udHJvbGxlcg0KWyAgIDE4LjY2MzU3OV0gdXNi
IHVzYjY6IE1hbnVmYWN0dXJlcjogTGludXggMy4xOC4wLXJjNS0yMDE0MTExNi12YW5pbGxh
IG9oY2lfaGNkDQpbICAgMTguNjYzNTc5XSB1c2IgdXNiNjogU2VyaWFsTnVtYmVyOiAwMDAw
OjAwOjE0LjUNClsgICAxOC42NjM4NjJdIGh1YiA2LTA6MS4wOiBVU0IgaHViIGZvdW5kDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDoyNzowMC4wNDVdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTEgLT4gMHg5YSAtPiBJUlEgMjUgTW9kZToxIEFjdGl2ZToxKQ0KWyAg
IDE4LjY2Mzg3OF0gaHViIDYtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNClsgICAxOC42NjQy
MDBdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpb
ICAgMTguNjY0MjAyXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgMTguNjY0MjI2
XSBvaGNpLXBjaSAwMDAwOjAwOjE2LjA6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNClsgICAx
OC42NjQyMzNdIG9oY2ktcGNpIDAwMDA6MDA6MTYuMDogT0hDSSBQQ0kgaG9zdCBjb250cm9s
bGVyDQpbICAgMTguNjY0Mzg1XSBvaGNpLXBjaSAwMDAwOjAwOjE2LjA6IG5ldyBVU0IgYnVz
IHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNw0KWyAgIDE4LjY2NDQ1OF0gb2hj
aS1wY2kgMDAwMDowMDoxNi4wOiBpcnEgMTgsIGlvIG1lbSAweGZkYmZlMDAwDQpbICAgMTgu
NzIwMjYwXSB1c2IgdXNiNzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs
IGlkUHJvZHVjdD0wMDAxDQpbICAgMTguNzIwMjYyXSB1c2IgdXNiNzogTmV3IFVTQiBkZXZp
Y2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAxOC43
MjAyNjNdIHVzYiB1c2I3OiBQcm9kdWN0OiBPSENJIFBDSSBob3N0IGNvbnRyb2xsZXINClsg
ICAxOC43MjAyNjRdIHVzYiB1c2I3OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMTguMC1yYzUt
MjAxNDExMTYtdmFuaWxsYSBvaGNpX2hjZA0KWyAgIDE4LjcyMDI2NV0gdXNiIHVzYjc6IFNl
cmlhbE51bWJlcjogMDAwMDowMDoxNi4wDQpbICAgMTguNzIwNTUwXSBodWIgNy0wOjEuMDog
VVNCIGh1YiBmb3VuZA0KWyAgIDE4LjcyMDU2Nl0gaHViIDctMDoxLjA6IDQgcG9ydHMgZGV0
ZWN0ZWQNClsgICAxOC43MjA4MjddIHVoY2lfaGNkOiBVU0IgVW5pdmVyc2FsIEhvc3QgQ29u
dHJvbGxlciBJbnRlcmZhY2UgZHJpdmVyDQpbICAgMTguNzIwOTI3XSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmxwDQpbICAgMTguNzIwOTczXSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdlDQpbICAg
MTguNzIxMDQ1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVz
YnNlcmlhbA0KWyAgIDE4LjcyMTA2OV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJm
YWNlIGRyaXZlciBjcDIxMHgNClsgICAxOC43MjExNjldIHVzYnNlcmlhbDogVVNCIFNlcmlh
bCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIGNwMjEweA0KWyAgIDE4LjcyMTIwN10gdXNiY29y
ZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBjeXByZXNzX204DQpbICAgMTgu
NzIxMjI4XSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBE
ZUxvcm1lIEVhcnRobWF0ZSBVU0INClsgICAxOC43MjEyNDhdIHVzYnNlcmlhbDogVVNCIFNl
cmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIEhJRC0+Q09NIFJTMjMyIEFkYXB0ZXINClsg
ICAxOC43MjEyNzJdIHVzYnNlcmlhbDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQg
Zm9yIE5va2lhIENBLTQyIFYyIEFkYXB0ZXINClsgICAxOC43MjEzMDBdIHVzYmNvcmU6IHJl
Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgbW9zNzcyMA0KWyAgIDE4LjcyMTMyMl0g
dXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCAy
IHBvcnQgYWRhcHRlcg0KWyAgIDE4LjcyMTM1MF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBtb3M3ODQwDQpbICAgMTguNzIxMzcyXSB1c2JzZXJpYWw6IFVT
QiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3NjaGlwIDc4NDAvNzgyMCBVU0Ig
U2VyaWFsIERyaXZlcg0KWyAgIDE4LjcyMTQ1Nl0gaTgwNDI6IFBOUDogTm8gUFMvMiBjb250
cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5Lg0KWyAgIDE4LjcyMjE2MV0g
c2VyaW86IGk4MDQyIEtCRCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMQ0KWyAgIDE4LjcyMjE5
N10gc2VyaW86IGk4MDQyIEFVWCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMTINClsgICAxOC43
MjI0MjNdIG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNl
DQpbICAgMTguNzIzMjM4XSBydGNfY21vcyAwMDowMjogUlRDIGNhbiB3YWtlIGZyb20gUzQN
ClsgICAxOC43MjM1OTddIHJ0Y19jbW9zIDAwOjAyOiBydGMgY29yZTogcmVnaXN0ZXJlZCBy
dGNfY21vcyBhcyBydGMwDQpbICAgMTguNzIzNjYyXSBydGNfY21vcyAwMDowMjogYWxhcm1z
IHVwIHRvIG9uZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0NClsgICAxOC43MjM5MjNd
IEFDUEkgV2FybmluZzogU3lzdGVtSU8gcmFuZ2UgMHgwMDAwMDAwMDAwMDAwYjAwLTB4MDAw
MDAwMDAwMDAwMGIwNyBjb25mbGljdHMgd2l0aCBPcFJlZ2lvbiAweDAwMDAwMDAwMDAwMDBi
MDAtMHgwMDAwMDAwMDAwMDAwYjBmIChcU09SMSkgKDIwMTQwOTI2L3V0YWRkcmVzcy0yNTgp
DQpbICAgMTguNzIzOTI1XSBBQ1BJOiBUaGlzIGNvbmZsaWN0IG1heSBjYXVzZSByYW5kb20g
cHJvYmxlbXMgYW5kIHN5c3RlbSBpbnN0YWJpbGl0eQ0KWyAgIDE4LjcyMzkyNV0gQUNQSTog
SWYgYW4gQUNQSSBkcml2ZXIgaXMgYXZhaWxhYmxlIGZvciB0aGlzIGRldmljZSwgeW91IHNo
b3VsZCB1c2UgaXQgaW5zdGVhZCBvZiB0aGUgbmF0aXZlIGRyaXZlcg0KWyAgIDE4LjcyMzkz
MF0gcGlpeDRfc21idXMgMDAwMDowMDoxNC4wOiBTTUJ1cyBIb3N0IENvbnRyb2xsZXIgYXQg
MHhiMDAsIHJldmlzaW9uIDANClsgICAxOC43MjQwMzVdIEFDUEkgV2FybmluZzogU3lzdGVt
SU8gcmFuZ2UgMHgwMDAwMDAwMDAwMDAwYjIwLTB4MDAwMDAwMDAwMDAwMGIyNyBjb25mbGlj
dHMgd2l0aCBPcFJlZ2lvbiAweDAwMDAwMDAwMDAwMDBiMjAtMHgwMDAwMDAwMDAwMDAwYjJm
IChcU09SMikgKDIwMTQwOTI2L3V0YWRkcmVzcy0yNTgpDQpbICAgMTguNzI0MDM2XSBBQ1BJ
OiBUaGlzIGNvbmZsaWN0IG1heSBjYXVzZSByYW5kb20gcHJvYmxlbXMgYW5kIHN5c3RlbSBp
bnN0YWJpbGl0eQ0KWyAgIDE4LjcyNDAzN10gQUNQSTogSWYgYW4gQUNQSSBkcml2ZXIgaXMg
YXZhaWxhYmxlIGZvciB0aGlzIGRldmljZSwgeW91IHNob3VsZCB1c2UgaXQgaW5zdGVhZCBv
ZiB0aGUgbmF0aXZlIGRyaXZlcg0KWyAgIDE4LjcyNDAzOV0gcGlpeDRfc21idXMgMDAwMDow
MDoxNC4wOiBBdXhpbGlhcnkgU01CdXMgSG9zdCBDb250cm9sbGVyIGF0IDB4YjIwDQpbICAg
MTguNzI0MzgzXSBsaXJjX2RldjogSVIgUmVtb3RlIENvbnRyb2wgZHJpdmVyIHJlZ2lzdGVy
ZWQsIG1ham9yIDI0OCANClsgICAxOC43MjQ0MDFdIElSIE5FQyBwcm90b2NvbCBoYW5kbGVy
IGluaXRpYWxpemVkDQpbICAgMTguNzI0NDAzXSBJUiBSQzUoeC9zeikgcHJvdG9jb2wgaGFu
ZGxlciBpbml0aWFsaXplZA0KWyAgIDE4LjcyNDQwNV0gSVIgUkM2IHByb3RvY29sIGhhbmRs
ZXIgaW5pdGlhbGl6ZWQNClsgICAxOC43MjQ0MDddIElSIEpWQyBwcm90b2NvbCBoYW5kbGVy
IGluaXRpYWxpemVkDQpbICAgMTguNzI0NDEwXSBJUiBTb255IHByb3RvY29sIGhhbmRsZXIg
aW5pdGlhbGl6ZWQNClsgICAxOC43MjQ0MTJdIElSIFNBTllPIHByb3RvY29sIGhhbmRsZXIg
aW5pdGlhbGl6ZWQNClsgICAxOC43MjQ0MTRdIElSIFNoYXJwIHByb3RvY29sIGhhbmRsZXIg
aW5pdGlhbGl6ZWQNClsgICAxOC43MjQ0MTZdIElSIE1DRSBLZXlib2FyZC9tb3VzZSBwcm90
b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgMTguNzI0NDE4XSBJUiBMSVJDIGJyaWRn
ZSBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgMTguNzI0NDIwXSBJUiBYTVAgcHJvdG9jb2wg
aGFuZGxlciBpbml0aWFsaXplZA0KWyAgIDE4LjcyNDQyMl0gY3gyNTgyMTogZHJpdmVyIHZl
cnNpb24gMC4wLjEwNiBsb2FkZWQNClsgICAxOC43MjQ2NTldIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgcHZydXNiMg0KWyAgIDE4LjcyNDY2MF0gcHZydXNi
MjogVjRMIGluLXRyZWUgdmVyc2lvbjpIYXVwcGF1Z2UgV2luVFYtUFZSLVVTQjIgTVBFRzIg
RW5jb2Rlci9UdW5lcg0KWyAgIDE4LjcyNDY2MV0gcHZydXNiMjogRGVidWcgbWFzayBpcyAz
MSAoMHgxZikNClsgICAxOC43MjQ3NTZdIGY3MTgwNWY6IFVuc3VwcG9ydGVkIEZpbnRlayBk
ZXZpY2UsIHNraXBwaW5nDQpbICAgMTguNzI0ODU2XSBmNzE4ODJmZzogRm91bmQgZjcxODg5
ZWQgY2hpcCBhdCAweDYwMCwgcmV2aXNpb24gMTYNClsgICAxOC43MjQ4OTldIEFDUEkgV2Fy
bmluZzogU3lzdGVtSU8gcmFuZ2UgMHgwMDAwMDAwMDAwMDAwNjAwLTB4MDAwMDAwMDAwMDAw
MDYwNyBjb25mbGljdHMgd2l0aCBPcFJlZ2lvbiAweDAwMDAwMDAwMDAwMDA2MDUtMHgwMDAw
MDAwMDAwMDAwNjA2IChcSE1PUikgKDIwMTQwOTI2L3V0YWRkcmVzcy0yNTgpDQpbICAgMTgu
NzI0OTAwXSBBQ1BJOiBUaGlzIGNvbmZsaWN0IG1heSBjYXVzZSByYW5kb20gcHJvYmxlbXMg
YW5kIHN5c3RlbSBpbnN0YWJpbGl0eQ0KWyAgIDE4LjcyNDkwMV0gQUNQSTogSWYgYW4gQUNQ
SSBkcml2ZXIgaXMgYXZhaWxhYmxlIGZvciB0aGlzIGRldmljZSwgeW91IHNob3VsZCB1c2Ug
aXQgaW5zdGVhZCBvZiB0aGUgbmF0aXZlIGRyaXZlcg0KWyAgIDE4LjcyNTA1NV0gZjcxODgy
ZmcgZjcxODgyZmcuMTUzNjogRmFuOiAxIGlzIGluIGR1dHktY3ljbGUgbW9kZQ0KWyAgIDE4
LjcyNTA5Nl0gZjcxODgyZmcgZjcxODgyZmcuMTUzNjogRmFuOiAyIGlzIGluIGR1dHktY3lj
bGUgbW9kZQ0KWyAgIDE4LjcyNTEzOV0gZjcxODgyZmcgZjcxODgyZmcuMTUzNjogRmFuOiAz
IGlzIGluIGR1dHktY3ljbGUgbW9kZQ0KWyAgIDE4Ljg1NjMwMV0gc3A1MTAwX3RjbzogU1A1
MTAwL1NCODAwIFRDTyBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDUNClsgICAxOC44NTYz
NjNdIHNwNTEwMF90Y286IFBDSSBSZXZpc2lvbiBJRDogMHg0MQ0KWyAgIDE4Ljg1NjQyMF0g
c3A1MTAwX3RjbzogVXNpbmcgMHhmZWQ4MGIwMCBmb3Igd2F0Y2hkb2cgTU1JTyBhZGRyZXNz
DQpbICAgMTguODU2NDYxXSBzcDUxMDBfdGNvOiBMYXN0IHJlYm9vdCB3YXMgbm90IHRyaWdn
ZXJlZCBieSB3YXRjaGRvZy4NClsgICAxOC44NTY2MjRdIHNwNTEwMF90Y286IGluaXRpYWxp
emVkICgweGZmZmZjOTAwMDAzNzZiMDApLiBoZWFydGJlYXQ9NjAgc2VjIChub3dheW91dD0w
KQ0KWyAgIDE4Ljg1NjYzMF0geGVuX3dkdDogWGVuIFdhdGNoRG9nIFRpbWVyIERyaXZlciB2
MC4wMQ0KWyAgIDE4Ljg1NjY4N10geGVuX3dkdDogY2Fubm90IHJlZ2lzdGVyIG1pc2NkZXYg
b24gbWlub3I9MTMwICgtMTYpDQpbICAgMTguODU2Njk4XSB3ZHQ6IHByb2JlIG9mIHdkdCBm
YWlsZWQgd2l0aCBlcnJvciAtMTYNClsgICAxOC44NTcyNzJdIGRldmljZS1tYXBwZXI6IGlv
Y3RsOiA0LjI4LjAtaW9jdGwgKDIwMTQtMDktMTcpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEBy
ZWRoYXQuY29tDQpbICAgMTguODU3NTk5XSBkZXZpY2UtbWFwcGVyOiBjYWNoZS1wb2xpY3kt
bXE6IHZlcnNpb24gMS4yLjAgbG9hZGVkDQpbICAgMTguODU3NjAxXSBkZXZpY2UtbWFwcGVy
OiBjYWNoZSBjbGVhbmVyOiB2ZXJzaW9uIDEuMC4wIGxvYWRlZA0KWyAgIDE4Ljg1NzYwNF0g
Qmx1ZXRvb3RoOiBWaXJ0dWFsIEhDSSBkcml2ZXIgdmVyIDEuNQ0KWyAgIDE4Ljg1NzgyMl0g
Qmx1ZXRvb3RoOiBIQ0kgVUFSVCBkcml2ZXIgdmVyIDIuMg0KWyAgIDE4Ljg1NzgyNF0gQmx1
ZXRvb3RoOiBIQ0kgSDQgcHJvdG9jb2wgaW5pdGlhbGl6ZWQNClsgICAxOC44NTc4MjVdIEJs
dWV0b290aDogSENJIEJDU1AgcHJvdG9jb2wgaW5pdGlhbGl6ZWQNClsgICAxOC44NTc4MjZd
IEJsdWV0b290aDogSENJTEwgcHJvdG9jb2wgaW5pdGlhbGl6ZWQNClsgICAxOC44NTc4MjZd
IEJsdWV0b290aDogSENJQVRIM0sgcHJvdG9jb2wgaW5pdGlhbGl6ZWQNClsgICAxOC44NTc4
MjddIEJsdWV0b290aDogSENJIFRocmVlLXdpcmUgVUFSVCAoSDUpIHByb3RvY29sIGluaXRp
YWxpemVkDQpbICAgMTguODU3ODY5XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIGJjbTIwM3gNClsgICAxOC44NTc5MDFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGludGVyZmFjZSBkcml2ZXIgYnBhMTB4DQpbICAgMTguODU3OTM1XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGJmdXNiDQpbICAgMTguODU3OTY4XSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGJ0dXNiDQpbICAgMTgu
ODU4MDAyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGF0aDNr
DQpbICAgMTguODU4NzMzXSBoaWRyYXc6IHJhdyBISUQgZXZlbnRzIGRyaXZlciAoQykgSmly
aSBLb3NpbmENClsgICAxOC44NTkwMzNdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy
ZmFjZSBkcml2ZXIgdXNiaGlkDQpbICAgMTguODU5MDMzXSB1c2JoaWQ6IFVTQiBISUQgY29y
ZSBkcml2ZXINClsgICAxOC44NjA2NjFdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdn
ZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguODYwNjY0XSBBbHJlYWR5IHNldHVwIHRoZSBH
U0kgOjE2DQpbICAgMTguODYwNzk4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyNSB0cmlnZ2Vy
aW5nIDAgcG9sYXJpdHkgMQ0KWyAgIDE4Ljg2MTA3MV0geGVuOiAtLT4gcGlycT0yNSAtPiBp
cnE9MjUgKGdzaT0yNSkNClsgICAxOC44NjEyNDFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3
IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi1hdWRpbw0KWyAgIDE4Ljg2MTI4MF0gdXNiY29y
ZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdWExMDENClsgICAxOC44
NjEzMTFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVz
Yi11c3gyeQ0KWyAgIDE4Ljg2MTM0MF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJm
YWNlIGRyaXZlciBzbmQtdXNiLWNhaWFxDQpbICAgMTguODYxMzgzXSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItNmZpcmUNClsgICAxOC44NjE0
NDBdIE5ldGZpbHRlciBtZXNzYWdlcyB2aWEgTkVUTElOSyB2MC4zMC4NClsgICAxOC44NjE0
NDddIG5mbmxfYWNjdDogcmVnaXN0ZXJpbmcgd2l0aCBuZm5ldGxpbmsuDQpbICAgMTguODYx
NTEyXSBuZl9jb25udHJhY2sgdmVyc2lvbiAwLjUuMCAoMTYzODQgYnVja2V0cywgNjU1MzYg
bWF4KQ0KWyAgIDE4Ljg2MTc5OV0gY3RuZXRsaW5rIHYwLjkzOiByZWdpc3RlcmluZyB3aXRo
IG5mbmV0bGluay4NClsgICAxOC44NjIyNzldIHh0X3RpbWU6IGtlcm5lbCB0aW1lem9uZSBp
cyAtMDAwMA0KWyAgIDE4Ljg2MjMwM10gaXBfc2V0OiBwcm90b2NvbCA2DQpbICAgMTguODYy
MzUzXSBJUFZTOiBSZWdpc3RlcmVkIHByb3RvY29scyAoKQ0KWyAgIDE4Ljg2MjQ2NV0gSVBW
UzogQ29ubmVjdGlvbiBoYXNoIHRhYmxlIGNvbmZpZ3VyZWQgKHNpemU9NDA5NiwgbWVtb3J5
PTY0S2J5dGVzKQ0KWyAgIDE4Ljg2MjUzM10gSVBWUzogQ3JlYXRpbmcgbmV0bnMgc2l6ZT0x
ODQwIGlkPTANClsgICAxOC45MTIyODZdIHNvdW5kIGhkYXVkaW9DMEQyOiBhdXRvY29uZmln
OiBsaW5lX291dHM9NCAoMHgxNC8weDE1LzB4MTYvMHgxNy8weDApIHR5cGU6bGluZQ0KWyAg
IDE4LjkxMjI4N10gc291bmQgaGRhdWRpb0MwRDI6ICAgIHNwZWFrZXJfb3V0cz0wICgweDAv
MHgwLzB4MC8weDAvMHgwKQ0KWyAgIDE4LjkxMjI4OV0gc291bmQgaGRhdWRpb0MwRDI6ICAg
IGhwX291dHM9MSAoMHgxYi8weDAvMHgwLzB4MC8weDApDQpbICAgMTguOTEyMjkwXSBzb3Vu
ZCBoZGF1ZGlvQzBEMjogICAgbW9ubzogbW9ub19vdXQ9MHgwDQpbICAgMTguOTEyMjkxXSBz
b3VuZCBoZGF1ZGlvQzBEMjogICAgZGlnLW91dD0weDExLzB4MWUNClsgICAxOC45MTIyOTFd
IHNvdW5kIGhkYXVkaW9DMEQyOiAgICBpbnB1dHM6DQpbICAgMTguOTEyMjkzXSBzb3VuZCBo
ZGF1ZGlvQzBEMjogICAgICBGcm9udCBNaWM9MHgxOQ0KWyAgIDE4LjkxMjI5NF0gc291bmQg
aGRhdWRpb0MwRDI6ICAgICAgUmVhciBNaWM9MHgxOA0KWyAgIDE4LjkxMjI5NV0gc291bmQg
aGRhdWRpb0MwRDI6ICAgICAgTGluZT0weDFhDQpbICAgMTguOTI2MjYwXSB1c2IgNC01OiBu
ZXcgZnVsbC1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciAyIHVzaW5nIG9oY2ktcGNpDQpbICAg
MTguOTMyMzEyXSByYW5kb206IG5vbmJsb2NraW5nIHBvb2wgaXMgaW5pdGlhbGl6ZWQNClsg
ICAxOS4wNDk2MDhdIHVzYiA3LTM6IG5ldyBsb3ctc3BlZWQgVVNCIGRldmljZSBudW1iZXIg
MiB1c2luZyBvaGNpLXBjaQ0KWyAgIDE5LjIwODMyM10gdXNiIDctMzogTmV3IFVTQiBkZXZp
Y2UgZm91bmQsIGlkVmVuZG9yPTA0NmQsIGlkUHJvZHVjdD1jNTE3DQpbICAgMTkuMjA4MzMw
XSB1c2IgNy0zOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVjdD0yLCBT
ZXJpYWxOdW1iZXI9MA0KWyAgIDE5LjIwODMzNV0gdXNiIDctMzogUHJvZHVjdDogVVNCIFJl
Y2VpdmVyDQpbICAgMTkuMjA4MzM5XSB1c2IgNy0zOiBNYW51ZmFjdHVyZXI6IExvZ2l0ZWNo
DQpbICAgMTkuMjE2MDEwXSBpbnB1dDogTG9naXRlY2ggVVNCIFJlY2VpdmVyIGFzIC9kZXZp
Y2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxNi4wL3VzYjcvNy0zLzctMzoxLjAvMDAwMzowNDZE
OkM1MTcuMDAwMS9pbnB1dC9pbnB1dDUNClsgICAxOS4yMTY3NzldIGxvZ2l0ZWNoIDAwMDM6
MDQ2RDpDNTE3LjAwMDE6IGlucHV0LGhpZHJhdzA6IFVTQiBISUQgdjEuMTAgS2V5Ym9hcmQg
W0xvZ2l0ZWNoIFVTQiBSZWNlaXZlcl0gb24gdXNiLTAwMDA6MDA6MTYuMC0zL2lucHV0MA0K
WyAgIDE5LjIyNDQ2NF0gbG9naXRlY2ggMDAwMzowNDZEOkM1MTcuMDAwMjogZml4aW5nIHVw
IExvZ2l0ZWNoIGtleWJvYXJkIHJlcG9ydCBkZXNjcmlwdG9yDQpbICAgMTkuMjI0OTQyXSBp
bnB1dDogTG9naXRlY2ggVVNCIFJlY2VpdmVyIGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAw
MDowMDoxNi4wL3VzYjcvNy0zLzctMzoxLjEvMDAwMzowNDZEOkM1MTcuMDAwMi9pbnB1dC9p
bnB1dDYNClsgICAxOS4yMjU2MTZdIElQVlM6IGlwdnMgbG9hZGVkLg0KWyAgIDE5LjIyNTYy
OF0gbG9naXRlY2ggMDAwMzowNDZEOkM1MTcuMDAwMjogaW5wdXQsaGlkZGV2MCxoaWRyYXcx
OiBVU0IgSElEIHYxLjEwIE1vdXNlIFtMb2dpdGVjaCBVU0IgUmVjZWl2ZXJdIG9uIHVzYi0w
MDAwOjAwOjE2LjAtMy9pbnB1dDENClsgICAxOS4zNTk0MzZdIHVzYiA0LTU6IE5ldyBVU0Ig
ZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0wYTEyLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgIDE5LjM1
OTQzOF0gdXNiIDQtNTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTAsIFByb2R1Y3Q9
MiwgU2VyaWFsTnVtYmVyPTANClsgICAxOS4zNTk0MzldIHVzYiA0LTU6IFByb2R1Y3Q6IEVE
UkNsYXNzb25lDQpbICAgMTkuMzY1Mjg5XSBpcF90YWJsZXM6IChDKSAyMDAwLTIwMDYgTmV0
ZmlsdGVyIENvcmUgVGVhbQ0KWyAgIDE5LjM2NTM1NV0gVENQOiBjdWJpYyByZWdpc3RlcmVk
DQpbICAgMTkuMzY1NzMxXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEwDQpb
ICAgMTkuMzY2NjcwXSBpcDZfdGFibGVzOiAoQykgMjAwMC0yMDA2IE5ldGZpbHRlciBDb3Jl
IFRlYW0NClsgICAxOS40NTI1MzVdIHNpdDogSVB2NiBvdmVyIElQdjQgdHVubmVsaW5nIGRy
aXZlcg0KWyAgIDE5LjQ1Mjg0OF0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAx
Nw0KWyAgIDE5LjQ1MjkxN10gYnJpZGdlOiBhdXRvbWF0aWMgZmlsdGVyaW5nIHZpYSBhcnAv
aXAvaXA2dGFibGVzIGhhcyBiZWVuIGRlcHJlY2F0ZWQuIFVwZGF0ZSB5b3VyIHNjcmlwdHMg
dG8gbG9hZCBicl9uZXRmaWx0ZXIgaWYgeW91IG5lZWQgdGhpcy4NClsgICAxOS42MDg2NDZd
IEJyaWRnZSBmaXJld2FsbGluZyByZWdpc3RlcmVkDQpbICAgMTkuNjA4NjQ5XSBFYnRhYmxl
cyB2Mi4wIHJlZ2lzdGVyZWQNClsgICAxOS42MDg4NzRdIEJsdWV0b290aDogUkZDT01NIFRU
WSBsYXllciBpbml0aWFsaXplZA0KWyAgIDE5LjYwODg4MF0gQmx1ZXRvb3RoOiBSRkNPTU0g
c29ja2V0IGxheWVyIGluaXRpYWxpemVkDQpbICAgMTkuNjA4ODkxXSBCbHVldG9vdGg6IFJG
Q09NTSB2ZXIgMS4xMQ0KWyAgIDE5LjYwODg5OV0gQmx1ZXRvb3RoOiBCTkVQIChFdGhlcm5l
dCBFbXVsYXRpb24pIHZlciAxLjMNClsgICAxOS42MDg5MDBdIEJsdWV0b290aDogQk5FUCBm
aWx0ZXJzOiBwcm90b2NvbCBtdWx0aWNhc3QNClsgICAxOS42MDg5MDNdIEJsdWV0b290aDog
Qk5FUCBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQNClsgICAxOS42MDg5MDVdIEJsdWV0b290
aDogSElEUCAoSHVtYW4gSW50ZXJmYWNlIEVtdWxhdGlvbikgdmVyIDEuMg0KWyAgIDE5LjYw
ODk1M10gQmx1ZXRvb3RoOiBISURQIHNvY2tldCBsYXllciBpbml0aWFsaXplZA0KWyAgIDE5
LjYwODk5M10gS2V5IHR5cGUgY2VwaCByZWdpc3RlcmVkDQpbICAgMTkuNjA5MzQ5XSBsaWJj
ZXBoOiBsb2FkZWQgKG1vbi9vc2QgcHJvdG8gMTUvMjQpDQpbICAgMTkuNjEwNDI2XSByZWdp
c3RlcmVkIHRhc2tzdGF0cyB2ZXJzaW9uIDENClsgICAxOS42MTE5NjNdIEJ0cmZzIGxvYWRl
ZA0KWyAgIDE5LjgzMDEyOV0gY29uc29sZSBbbmV0Y29uMF0gZW5hYmxlZA0KWyAgIDE5Ljgz
MDE2M10gYXRhNDogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApDQpb
ICAgMTkuODMwMjk5XSBhdGE1OiBTQVRBIGxpbmsgZG93biAoU1N0YXR1cyAwIFNDb250cm9s
IDMwMCkNClsgICAxOS44NDg5MjZdIG5ldGNvbnNvbGU6IG5ldHdvcmsgbG9nZ2luZyBzdGFy
dGVkDQpbICAgMTkuODU1MzQyXSBydGNfY21vcyAwMDowMjogc2V0dGluZyBzeXN0ZW0gY2xv
Y2sgdG8gMjAxNC0xMS0xOCAxNDoyNzowMCBVVEMgKDE0MTYzMjA4MjApDQpbICAgMTkuODYy
MTE4XSBBTFNBIGRldmljZSBsaXN0Og0KWyAgIDE5Ljg2ODQ2NF0gICAjMDogSERBIEFUSSBT
QiBhdCAweGZkYmY4MDAwIGlycSAxNg0KWyAgIDE5Ljg3NDc5N10gICAjMTogSERBIEFUSSBI
RE1JIGF0IDB4ZmU5ZmMwMDAgaXJxIDEyNA0KWyAgIDE5Ljk4OTU2MF0gYXRhMzogU0FUQSBs
aW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEyMyBTQ29udHJvbCAzMDApDQpbICAgMTkuOTk3
ODI0XSBhdGExOiBTQVRBIGxpbmsgdXAgNi4wIEdicHMgKFNTdGF0dXMgMTMzIFNDb250cm9s
IDMwMCkNClsgICAyMC4wMDY2MjVdIGF0YTMuMDA6IEFUQS04OiBIaXRhY2hpIEhEUzcyMjAy
MEFMQTMzMCwgSktBT0EyME4sIG1heCBVRE1BLzEzMw0KWyAgIDIwLjAxNDgwNV0gYXRhMy4w
MDogMzkwNzAyOTE2OCBzZWN0b3JzLCBtdWx0aSAwOiBMQkE0OCBOQ1EgKGRlcHRoIDMxLzMy
KSwgQUENClsgICAyMC4wMjM1NzNdIGF0YTEuMDA6IEFUQS04OiBIR1NUIEhETjcyNDA0MEFM
RTY0MCwgTUpBT0E1RTAsIG1heCBVRE1BLzEzMw0KWyAgIDIwLjAzMTYwMV0gYXRhMS4wMDog
NzgxNDAzNzE2OCBzZWN0b3JzLCBtdWx0aSAwOiBMQkE0OCBOQ1EgKGRlcHRoIDMxLzMyKSwg
QUENClsgICAyMC4wNDA0MjddIGF0YTMuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTMzDQpb
ICAgMjAuMDQ5MjU2XSBhdGExLjAwOiBjb25maWd1cmVkIGZvciBVRE1BLzEzMw0KWyAgIDIw
LjA1OTIyMF0gc2NzaSAwOjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBBVEEgICAgICBIR1NU
IEhETjcyNDA0MEFMIEE1RTAgUFE6IDAgQU5TSTogNQ0KWyAgIDIwLjA3MDQ4OV0gc2QgMDow
OjA6MDogW3NkYV0gNzgxNDAzNzE2OCA1MTItYnl0ZSBsb2dpY2FsIGJsb2NrczogKDQuMDAg
VEIvMy42MyBUaUIpDQpbICAgMjAuMDcxMjU1XSBzZCAwOjA6MDowOiBBdHRhY2hlZCBzY3Np
IGdlbmVyaWMgc2cwIHR5cGUgMA0KWyAgIDIwLjA3MzQxNF0gc2NzaSAyOjA6MDowOiBEaXJl
Y3QtQWNjZXNzICAgICBBVEEgICAgICBIaXRhY2hpIEhEUzcyMjAyIEEyME4gUFE6IDAgQU5T
STogNQ0KWyAgIDIwLjA3NTEzMl0gc2QgMjowOjA6MDogW3NkYl0gMzkwNzAyOTE2OCA1MTIt
Ynl0ZSBsb2dpY2FsIGJsb2NrczogKDIuMDAgVEIvMS44MSBUaUIpDQpbICAgMjAuMDc1MjU4
XSBzZCAyOjA6MDowOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMgc2cxIHR5cGUgMA0KWyAgIDIw
LjA3NTgwMV0gc2QgMjowOjA6MDogW3NkYl0gV3JpdGUgUHJvdGVjdCBpcyBvZmYNClsgICAy
MC4wNzU4MDldIHNkIDI6MDowOjA6IFtzZGJdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwDQpb
ICAgMjAuMDc2MDQ1XSBzZCAyOjA6MDowOiBbc2RiXSBXcml0ZSBjYWNoZTogZW5hYmxlZCwg
cmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBGVUENClsgICAy
MC4wODA4NDZdICBzZGI6IHNkYjENClsgICAyMC4wODM2NDddIHNkIDI6MDowOjA6IFtzZGJd
IEF0dGFjaGVkIFNDU0kgZGlzaw0KWyAgIDIwLjE0NDQxMl0gc2QgMDowOjA6MDogW3NkYV0g
NDA5Ni1ieXRlIHBoeXNpY2FsIGJsb2Nrcw0KWyAgIDIwLjE1MTI2Ml0gc2QgMDowOjA6MDog
W3NkYV0gV3JpdGUgUHJvdGVjdCBpcyBvZmYNClsgICAyMC4xNTc4MTFdIHNkIDA6MDowOjA6
IFtzZGFdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwDQpbICAgMjAuMTY0MjQ5XSBzZCAwOjA6
MDowOiBbc2RhXSBXcml0ZSBjYWNoZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwg
ZG9lc24ndCBzdXBwb3J0IERQTyBvciBGVUENClsgICAyMC4yMzY3MTRdICBzZGE6IHNkYTEg
c2RhMiBzZGEzIHNkYTQNClsgICAyMC4yNDcyNDRdIHNkIDA6MDowOjA6IFtzZGFdIEF0dGFj
aGVkIFNDU0kgZGlzaw0KWyAgIDIwLjI1NzUzNl0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1l
bW9yeTogMTEwNEsgKGZmZmZmZmZmODIzMDYwMDAgLSBmZmZmZmZmZjgyNDFhMDAwKQ0KWyAg
IDIwLjI2NTMxMF0gV3JpdGUgcHJvdGVjdGluZyB0aGUga2VybmVsIHJlYWQtb25seSBkYXRh
OiAxODQzMmsNClsgICAyMC4yODc1MjhdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6
IDM1NksgKGZmZmY4ODAwMDFiYTcwMDAgLSBmZmZmODgwMDAxYzAwMDAwKQ0KWyAgIDIwLjI5
NDc2MV0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMTY0OEsgKGZmZmY4ODAwMDIw
NjQwMDAgLSBmZmZmODgwMDAyMjAwMDAwKQ0KWyAgIDIwLjM0MzEyN10gdWRldmRbMTYwNl06
IHN0YXJ0aW5nIHZlcnNpb24gMTc1DQpbICAgMjEuNDQ4MTg4XSBFWFQ0LWZzIChkbS0wKTog
bW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IChudWxs
KQ0KWyAgIDI0LjAyNzI2Ml0gdWRldmRbMTk4OV06IHN0YXJ0aW5nIHZlcnNpb24gMTc1DQpb
ICAgMjcuMzA1MDE1XSBFWFQ0LWZzIChkbS0wKTogcmUtbW91bnRlZC4gT3B0czogKG51bGwp
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNzowOC43MjRdIC0tTUFSSy0tDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNzoxOC43MjRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoy
NzoyOC43MjRdIC0tTUFSSy0tDQpbICAgNTQuMTY5MzI0XSBFWFQ0LWZzIChkbS0wKTogcmUt
bW91bnRlZC4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJvDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDoyNzozOC43MjVdIC0tTUFSSy0tDQpbICAgNTguMjQ1ODcxXSBBZGRpbmcg
MjA5NzE0OGsgc3dhcCBvbiAvZGV2L21hcHBlci9zZXJ2ZWVyc3RlcnRqZS1zd2FwLiAgUHJp
b3JpdHk6LTEgZXh0ZW50czoxIGFjcm9zczoyMDk3MTQ4ayANClsgICA2NC40ODA0NTldIEVY
VDQtZnMgKHNkYTEpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9k
ZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJvDQpbICAgNjYuOTE3NTczXSBy
ODE2OSAwMDAwOjBkOjAwLjAgZXRoMDogbGluayBkb3duDQpbICAgNjYuOTE3NjcwXSByODE2
OSAwMDAwOjBkOjAwLjAgZXRoMDogbGluayBkb3duDQpbICAgNjcuNDE0MjE1XSByODE2OSAw
MDAwOjBjOjAwLjAgZXRoMTogbGluayBkb3duDQpbICAgNjcuNDIxMTg4XSByODE2OSAwMDAw
OjBjOjAwLjAgZXRoMTogbGluayBkb3duDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyNzo0OC43
MjVdIC0tTUFSSy0tDQpbICAgNjguNjA5NjE5XSByODE2OSAwMDAwOjBkOjAwLjAgZXRoMDog
bGluayB1cA0KWyAgIDY5LjUxNDc0MF0gcjgxNjkgMDAwMDowYzowMC4wIGV0aDE6IGxpbmsg
dXANCihYRU4pIFsyMDE0LTExLTE4IDE0OjI3OjU4LjcyNV0gLS1NQVJLLS0NCihYRU4pIFsy
MDE0LTExLTE4IDE0OjI4OjA4LjcyNV0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0
OjI4OjE4LjcyNl0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjI4OjI4LjcyNl0g
LS1NQVJLLS0NClsgIDEwOS42Nzc2MDNdIEVYVDQtZnMgKGRtLTIpOiBtb3VudGVkIGZpbGVz
eXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1y
ZW1vdW50LXJvDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyODozOC43MjZdIC0tTUFSSy0tDQpb
ICAxMTkuMzA1MTk1XSBFWFQ0LWZzIChkbS01MCk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRo
IG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8N
CihYRU4pIFsyMDE0LTExLTE4IDE0OjI4OjQ4LjcyNl0gLS1NQVJLLS0NClsgIDEzMC4zODY2
NzBdIEVYVDQtZnMgKGRtLTQ5KTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBk
YXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6Mjg6NTguNzI3XSAtLU1BUkstLQ0KWyAgMTQwLjQ2NDA3NV0gRVhUNC1m
cyAoZG0tNDgpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4g
T3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJvDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDoyOTowOC43MjddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyOToxOC43Mjdd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoyOToyOC43MjddIC0tTUFSSy0tDQpb
ICAxNzEuMDM0MDMzXSBFWFQ0LWZzIChkbS00NSk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRo
IG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8N
CihYRU4pIFsyMDE0LTExLTE4IDE0OjI5OjM4LjcyOF0gLS1NQVJLLS0NClsgIDE4NS45OTQw
MTBdIEVYVDQtZnMgKGRtLTQ3KTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBk
YXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6Mjk6NDguNzI4XSAtLU1BUkstLQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6
Mjk6NTguNzI4XSAtLU1BUkstLQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzA6MDguNzI4XSAt
LU1BUkstLQ0KWyAgMjA4LjY1MDA4NF0gRVhUNC1mcyAoZG0tNDYpOiBtb3VudGVkIGZpbGVz
eXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1y
ZW1vdW50LXJvDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMDoxOC43MjldIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDozMDoyOC43MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozMDozOC43MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMDo0
OC43MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMDo1OC43MzBdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMTowOC43MzBdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDozMToxOC43MzBdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozMToyOC43MzFdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMTozOC43MzFd
IC0tTUFSSy0tDQpbICAzMDMuMjkxMTUzXSBFWFQ0LWZzIChzZGIxKTogbW91bnRlZCBmaWxl
c3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9
cmVtb3VudC1ybw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzE6NDguNzMxXSAtLU1BUkstLQ0K
WyAgMzE2LjQ0NDg2MV0gZGV2aWNlIHZpZjEuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUN
CihkMSkgWzIwMTQtMTEtMTggMTQ6MzE6NTcuMTkzXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBo
eXNpY2FsIG1lbW9yeQ0KKGQxKSBbMjAxNC0xMS0xOCAxNDozMTo1Ny4xOTNdIGFib3V0IHRv
IGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMTo1Ny40NjNdIHRyYXBz
LmM6MjU3OTpkMXYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuDQpbICAzMTcu
MjI4MDMxXSB4ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDE3LCBwcm90
b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAgMzE3LjI0MzU4MV0g
eGVuLWJsa2JhY2s6cmluZy1yZWYgOSwgZXZlbnQtY2hhbm5lbCAxOCwgcHJvdG9jb2wgMSAo
eDg2XzY0LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDMxNy4yNjM0NzJdIHZpZiB2aWYt
MS0wIHZpZjEuMDogR3Vlc3QgUnggcmVhZHkNClsgIDMxNy4yNzQ4MzhdIHhlbl9icmlkZ2U6
IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzE3LjI4NjA1
M10geGVuX2JyaWRnZTogcG9ydCAxKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRl
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMTo1OC43MzFdIC0tTUFSSy0tDQpbICAzMjIuMjY3
MDU1XSBkZXZpY2UgdmlmMi4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQyKSBbMjAx
NC0xMS0xOCAxNDozMjowMi45ODJdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVt
b3J5DQooZDIpIFsyMDE0LTExLTE4IDE0OjMyOjAyLjk4Ml0gYWJvdXQgdG8gZ2V0IHN0YXJ0
ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjAzLjA1OV0gdHJhcHMuYzoyNTc5OmQy
djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAw
MDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDMyMi44MTQ1NjhdIHhl
bi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4
Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzMjMuODMwNzIyXSB2aWYgdmlmLTIt
MCB2aWYyLjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzMjMuODQxNjQ1XSB4ZW5fYnJpZGdlOiBw
b3J0IDIodmlmMi4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDMyMy44NTIzNDNd
IHhlbl9icmlkZ2U6IHBvcnQgMih2aWYyLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MzI6MDguNzMyXSAtLU1BUkstLQ0KWyAgMzI4LjE2MTgy
Nl0gZGV2aWNlIHZpZjMuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNCihkMykgWzIwMTQt
MTEtMTggMTQ6MzI6MDguODg1XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9y
eQ0KKGQzKSBbMjAxNC0xMS0xOCAxNDozMjowOC44ODVdIGFib3V0IHRvIGdldCBzdGFydGVk
Li4uDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMjowOC45NzVdIHRyYXBzLmM6MjU3OTpkM3Yw
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAw
MDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuDQpbICAzMjguNzMwMTMzXSB4ZW4t
YmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDE3LCBwcm90b2NvbCAxICh4ODZf
NjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAgMzI5LjkxNzk0NV0gdmlmIHZpZi0zLTAg
dmlmMy4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzI5LjkyODM1MF0geGVuX2JyaWRnZTogcG9y
dCAzKHZpZjMuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzMjkuOTM4NzE0XSB4
ZW5fYnJpZGdlOiBwb3J0IDModmlmMy4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsg
IDMzMi4yODQ2NzJdIHhlbl9icmlkZ2U6IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2Fy
ZGluZyBzdGF0ZQ0KWyAgMzM0LjA3MzA5OF0gZGV2aWNlIHZpZjQuMCBlbnRlcmVkIHByb21p
c2N1b3VzIG1vZGUNCihkNCkgWzIwMTQtMTEtMTggMTQ6MzI6MTQuNzkxXSBtYXBwaW5nIGtl
cm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQ0KSBbMjAxNC0xMS0xOCAxNDozMjoxNC43
OTFdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMjox
NC44NjZdIHRyYXBzLmM6MjU3OTpkNHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZm
ZmYuDQpbICAzMzQuNTUyNzYzXSB4ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFu
bmVsIDEwLCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAg
MzM0LjY5NTc2MF0gdmlmIHZpZi00LTAgdmlmNC4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzM0
LjcwNTUzMF0geGVuX2JyaWRnZTogcG9ydCA0KHZpZjQuMCkgZW50ZXJlZCBmb3J3YXJkaW5n
IHN0YXRlDQpbICAzMzQuNzE1MjMwXSB4ZW5fYnJpZGdlOiBwb3J0IDQodmlmNC4wKSBlbnRl
cmVkIGZvcndhcmRpbmcgc3RhdGUNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjE3LjExMl0g
Z3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byAyIGZy
YW1lcw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzI6MTguNzMyXSAtLU1BUkstLQ0KWyAgMzM4
Ljg5NDYyNF0geGVuX2JyaWRnZTogcG9ydCAyKHZpZjIuMCkgZW50ZXJlZCBmb3J3YXJkaW5n
IHN0YXRlDQpbICAzNDAuMDIyMjc5XSBkZXZpY2UgdmlmNS4wIGVudGVyZWQgcHJvbWlzY3Vv
dXMgbW9kZQ0KKGQ1KSBbMjAxNC0xMS0xOCAxNDozMjoyMC43ODJdIG1hcHBpbmcga2VybmVs
IGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDUpIFsyMDE0LTExLTE4IDE0OjMyOjIwLjc4Ml0g
YWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjIwLjg2
MV0gdHJhcHMuYzoyNTc5OmQ1djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4N
ClsgIDM0MC42MTk0MDZdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwg
MTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzNDEu
NjM1NDA4XSB2aWYgdmlmLTUtMCB2aWY1LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzNDEuNjQ0
NjI2XSB4ZW5fYnJpZGdlOiBwb3J0IDUodmlmNS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3Rh
dGUNClsgIDM0MS42NTM4MjddIHhlbl9icmlkZ2U6IHBvcnQgNSh2aWY1LjApIGVudGVyZWQg
Zm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzQ0Ljk3MTY4Ml0geGVuX2JyaWRnZTogcG9ydCAzKHZp
ZjMuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNDYuMDgxOTUxXSBkZXZpY2Ug
dmlmNi4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ2KSBbMjAxNC0xMS0xOCAxNDoz
MjoyNi44NzldIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDYpIFsy
MDE0LTExLTE4IDE0OjMyOjI2Ljg3OV0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4p
IFsyMDE0LTExLTE4IDE0OjMyOjI2Ljk5Ml0gdHJhcHMuYzoyNTc5OmQ2djAgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAw
IHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM0Ni43MDgzMzZdIHhlbi1ibGtiYWNrOnJp
bmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBl
cnNpc3RlbnQgZ3JhbnRzDQpbICAzNDcuNzI2MDk4XSB2aWYgdmlmLTYtMCB2aWY2LjA6IEd1
ZXN0IFJ4IHJlYWR5DQpbICAzNDcuNzM0NzEwXSB4ZW5fYnJpZGdlOiBwb3J0IDYodmlmNi4w
KSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM0Ny43NDMyNjFdIHhlbl9icmlkZ2U6
IHBvcnQgNih2aWY2LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KKFhFTikgWzIwMTQt
MTEtMTggMTQ6MzI6MjguNzMyXSAtLU1BUkstLQ0KWyAgMzQ5LjcxNjAwOF0geGVuX2JyaWRn
ZTogcG9ydCA0KHZpZjQuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNTIuMTk3
NzQyXSBkZXZpY2UgdmlmNy4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ3KSBbMjAx
NC0xMS0xOCAxNDozMjozMi45MjhdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVt
b3J5DQooZDcpIFsyMDE0LTExLTE4IDE0OjMyOjMyLjkyOF0gYWJvdXQgdG8gZ2V0IHN0YXJ0
ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjMzLjAwN10gdHJhcHMuYzoyNTc5OmQ3
djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAw
MDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM1Mi43NjUyNDddIHhl
bi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4
Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzNTMuNzgxNDg5XSB2aWYgdmlmLTct
MCB2aWY3LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzNTMuNzg5Njg2XSB4ZW5fYnJpZGdlOiBw
b3J0IDcodmlmNy4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM1My43OTc2MjZd
IHhlbl9icmlkZ2U6IHBvcnQgNyh2aWY3LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0K
WyAgMzU2LjY5OTE4Nl0geGVuX2JyaWRnZTogcG9ydCA1KHZpZjUuMCkgZW50ZXJlZCBmb3J3
YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMjozOC43MzJdIC0tTUFSSy0t
DQpbICAzNTguMzAzMjM5XSBkZXZpY2UgdmlmOC4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9k
ZQ0KKGQ4KSBbMjAxNC0xMS0xOCAxNDozMjozOS4wNjBdIG1hcHBpbmcga2VybmVsIGludG8g
cGh5c2ljYWwgbWVtb3J5DQooZDgpIFsyMDE0LTExLTE4IDE0OjMyOjM5LjA2MF0gYWJvdXQg
dG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjM5LjEzOF0gdHJh
cHMuYzoyNTc5OmQ4djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0
IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM1
OC44MjQ2MTNdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHBy
b3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzNTguOTcxNjI1
XSB2aWYgdmlmLTgtMCB2aWY4LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzNTguOTc5MjA0XSB4
ZW5fYnJpZGdlOiBwb3J0IDgodmlmOC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsg
IDM1OC45ODY2NDFdIHhlbl9icmlkZ2U6IHBvcnQgOCh2aWY4LjApIGVudGVyZWQgZm9yd2Fy
ZGluZyBzdGF0ZQ0KWyAgMzYyLjc3NjE3NF0geGVuX2JyaWRnZTogcG9ydCA2KHZpZjYuMCkg
ZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNjQuMzMyNDEzXSBkZXZpY2UgdmlmOS4w
IGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ5KSBbMjAxNC0xMS0xOCAxNDozMjo0NS4z
ODhdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDkpIFsyMDE0LTEx
LTE4IDE0OjMyOjQ1LjM4OF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0
LTExLTE4IDE0OjMyOjQ1LjQ3N10gdHJhcHMuYzoyNTc5OmQ5djAgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4
MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM2NS4yNDAyMjBdIHhlbi1ibGtiYWNrOnJpbmctcmVm
IDgsIGV2ZW50LWNoYW5uZWwgMTcsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3Rl
bnQgZ3JhbnRzDQpbICAzNjYuMjU5NTg0XSB2aWYgdmlmLTktMCB2aWY5LjA6IEd1ZXN0IFJ4
IHJlYWR5DQpbICAzNjYuMjY2MjAxXSB4ZW5fYnJpZGdlOiBwb3J0IDkodmlmOS4wKSBlbnRl
cmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM2Ni4yNzI2NzhdIHhlbl9icmlkZ2U6IHBvcnQg
OSh2aWY5LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6MzI6NDguNzMyXSAtLU1BUkstLQ0KWyAgMzY4Ljc5OTc2OV0geGVuX2JyaWRnZTogcG9y
dCA3KHZpZjcuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozMjo1MC4yNzBdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRy
YWNrIHNpemUgdG8gMyBmcmFtZXMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjUwLjI4OF0g
Z3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA0IGZy
YW1lcw0KWyAgMzcwLjc1OTQxNV0gZGV2aWNlIHZpZjEwLjAgZW50ZXJlZCBwcm9taXNjdW91
cyBtb2RlDQooZDEwKSBbMjAxNC0xMS0xOCAxNDozMjo1MS40NzddIG1hcHBpbmcga2VybmVs
IGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDEwKSBbMjAxNC0xMS0xOCAxNDozMjo1MS40Nzdd
IGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMjo1MS41
NjVdIHRyYXBzLmM6MjU3OTpkMTB2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAw
YzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZm
Lg0KWyAgMzcxLjMxOTI3MV0geGVuLWJsa2JhY2s6cmluZy1yZWYgOCwgZXZlbnQtY2hhbm5l
bCAxMCwgcHJvdG9jb2wgMSAoeDg2XzY0LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDM3
Mi4zMzY1MDBdIHZpZiB2aWYtMTAtMCB2aWYxMC4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzcy
LjM0MzA0Ml0geGVuX2JyaWRnZTogcG9ydCAxMCh2aWYxMC4wKSBlbnRlcmVkIGZvcndhcmRp
bmcgc3RhdGUNClsgIDM3Mi4zNDk4MzBdIHhlbl9icmlkZ2U6IHBvcnQgMTAodmlmMTAuMCkg
ZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNzQuMDIzODY2XSB4ZW5fYnJpZGdlOiBw
b3J0IDgodmlmOC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjMyOjU3LjI1Nl0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFw
dHJhY2sgc2l6ZSB0byA1IGZyYW1lcw0KWyAgMzc2LjkwMjk2N10gZGV2aWNlIHZpZjExLjAg
ZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQooZDExKSBbMjAxNC0xMS0xOCAxNDozMjo1Ny42
MThdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDExKSBbMjAxNC0x
MS0xOCAxNDozMjo1Ny42MThdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDozMjo1Ny43MTVdIHRyYXBzLmM6MjU3OTpkMTF2MCBEb21haW4gYXR0ZW1w
dGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8g
MHgwMDAwMDAwMDAwMDBmZmZmLg0KWyAgMzc3LjQ4MTMwN10geGVuLWJsa2JhY2s6cmluZy1y
ZWYgOCwgZXZlbnQtY2hhbm5lbCAxNywgcHJvdG9jb2wgMSAoeDg2XzY0LWFiaSkgcGVyc2lz
dGVudCBncmFudHMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMyOjU4LjczM10gLS1NQVJLLS0N
ClsgIDM3OC42NTA2MDRdIHZpZiB2aWYtMTEtMCB2aWYxMS4wOiBHdWVzdCBSeCByZWFkeQ0K
WyAgMzc4LjY1NzE4MF0geGVuX2JyaWRnZTogcG9ydCAxMSh2aWYxMS4wKSBlbnRlcmVkIGZv
cndhcmRpbmcgc3RhdGUNClsgIDM3OC42NjM4NTFdIHhlbl9icmlkZ2U6IHBvcnQgMTEodmlm
MTEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzODEuMjczNTU2XSB4ZW5fYnJp
ZGdlOiBwb3J0IDkodmlmOS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM4NC4y
NTkzODddIGRldmljZSB2aWYxMi4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQxMikg
WzIwMTQtMTEtMTggMTQ6MzM6MDQuOTgxXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2Fs
IG1lbW9yeQ0KKGQxMikgWzIwMTQtMTEtMTggMTQ6MzM6MDQuOTgxXSBhYm91dCB0byBnZXQg
c3RhcnRlZC4uLg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MDUuMDczXSB0cmFwcy5jOjI1
Nzk6ZDEydjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20g
MHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM4NC44ODU4
MDNdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29s
IDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzODUuOTAyODg0XSB2aWYg
dmlmLTEyLTAgdmlmMTIuMDogR3Vlc3QgUnggcmVhZHkNClsgIDM4NS45MDk0MjBdIHhlbl9i
cmlkZ2U6IHBvcnQgMTIodmlmMTIuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAz
ODUuOTE2MDYyXSB4ZW5fYnJpZGdlOiBwb3J0IDEyKHZpZjEyLjApIGVudGVyZWQgZm9yd2Fy
ZGluZyBzdGF0ZQ0KWyAgMzg3LjM1MDUwM10geGVuX2JyaWRnZTogcG9ydCAxMCh2aWYxMC4w
KSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMzOjA4
LjczM10gLS1NQVJLLS0NClsgIDM5MC4zNDE0NjldIGRldmljZSB2aWYxMy4wIGVudGVyZWQg
cHJvbWlzY3VvdXMgbW9kZQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MTEuMTA4XSBBTUQt
Vmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4YTQsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MTEuMTA4XSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE0LCB0eXBlID0gMHg3LCByb290IHRhYmxl
ID0gMHg1MDRlNzIwMDAsIGRvbWFpbiA9IDEzLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDE0LTExLTE4IDE0OjMzOjExLjEwOF0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowMzowNi4w
IGZyb20gZG9tMCB0byBkb20xMw0KKGQxMykgWzIwMTQtMTEtMTggMTQ6MzM6MTEuMTE2XSBt
YXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQxMykgWzIwMTQtMTEtMTgg
MTQ6MzM6MTEuMTE2XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLg0KWyAgMzkwLjQ3NTgyOV0g
eGVuX3BjaWJhY2s6IHZwY2k6IDAwMDA6MDM6MDYuMDogYXNzaWduIHRvIHZpcnR1YWwgc2xv
dCAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzoxMS4zMzddIHRyYXBzLmM6MjU3OTpkMTN2
MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAw
MDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLg0KWyAgMzkxLjA5MDk2Nl0geGVu
LWJsa2JhY2s6cmluZy1yZWYgOSwgZXZlbnQtY2hhbm5lbCAxMSwgcHJvdG9jb2wgMSAoeDg2
XzY0LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDM5Mi4xODg5NzJdIHBjaWJhY2sgMDAw
MDowMzowNi4wOiBlbmFibGluZyBkZXZpY2UgKDAwMDAgLT4gMDAwMSkNClsgIDM5Mi4xOTU4
ODhdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDIyIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpb
ICAzOTIuMjAyNzM3XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjIyDQpbICAzOTIuMjEwNzc3
XSBwY2liYWNrIDAwMDA6MDM6MDYuMDogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAgMzky
LjIyOTI4MV0gdmlmIHZpZi0xMy0wIHZpZjEzLjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzOTIu
MjM1ODEyXSB4ZW5fYnJpZGdlOiBwb3J0IDEzKHZpZjEzLjApIGVudGVyZWQgZm9yd2FyZGlu
ZyBzdGF0ZQ0KWyAgMzkyLjI0MjU2Ml0geGVuX2JyaWRnZTogcG9ydCAxMyh2aWYxMy4wKSBl
bnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM5My42OTQwODVdIHhlbl9icmlkZ2U6IHBv
cnQgMTEodmlmMTEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzOTYuNzI4OTQz
XSBkZXZpY2UgdmlmMTQuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNCihkMTQpIFsyMDE0
LTExLTE4IDE0OjMzOjE3LjQ0OF0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1v
cnkNCihkMTQpIFsyMDE0LTExLTE4IDE0OjMzOjE3LjQ0OF0gYWJvdXQgdG8gZ2V0IHN0YXJ0
ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDE0OjMzOjE3LjUzOV0gdHJhcHMuYzoyNTc5OmQx
NHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAw
MDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuDQpbICAzOTcuMjk0MDYyXSB4
ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDEwLCBwcm90b2NvbCAxICh4
ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6
MTguNzMzXSAtLU1BUkstLQ0KWyAgMzk4LjMxMjU0OV0gdmlmIHZpZi0xNC0wIHZpZjE0LjA6
IEd1ZXN0IFJ4IHJlYWR5DQpbICAzOTguMzE5MDU3XSB4ZW5fYnJpZGdlOiBwb3J0IDE0KHZp
ZjE0LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzk4LjMyNTY3OV0geGVuX2Jy
aWRnZTogcG9ydCAxNCh2aWYxNC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNCihYRU4p
IFsyMDE0LTExLTE4IDE0OjMzOjE5LjUwOF0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNy
ZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA2IGZyYW1lcw0KWyAgNDAwLjk0Mzc3OV0geGVuX2Jy
aWRnZTogcG9ydCAxMih2aWYxMi4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDQw
Mi43MzIwMTldIGRldmljZSB2aWYxNS4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQx
NSkgWzIwMTQtMTEtMTggMTQ6MzM6MjMuNDY1XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNp
Y2FsIG1lbW9yeQ0KKGQxNSkgWzIwMTQtMTEtMTggMTQ6MzM6MjMuNDY1XSBhYm91dCB0byBn
ZXQgc3RhcnRlZC4uLg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MjMuNTU0XSB0cmFwcy5j
OjI1Nzk6ZDE1djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDQwMy4z
MDk2MzFdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3Rv
Y29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICA0MDQuMzI3MDAxXSB2
aWYgdmlmLTE1LTAgdmlmMTUuMDogR3Vlc3QgUnggcmVhZHkNClsgIDQwNC4zMzM2MTddIHZw
bl9icmlkZ2U6IHBvcnQgMSh2aWYxNS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsg
IDQwNC4zNDAzMTJdIHZwbl9icmlkZ2U6IHBvcnQgMSh2aWYxNS4wKSBlbnRlcmVkIGZvcndh
cmRpbmcgc3RhdGUNClsgIDQwNy4yODczNjRdIHhlbl9icmlkZ2U6IHBvcnQgMTModmlmMTMu
MCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzoy
OC43MzNdIC0tTUFSSy0tDQpbICA0MDkuNjQ1MjgwXSBkZXZpY2UgdmlmMTYuMCBlbnRlcmVk
IHByb21pc2N1b3VzIG1vZGUNClsgIDQwOS44NzkyNjZdIGRldmljZSB2aWYxNi4wLWVtdSBl
bnRlcmVkIHByb21pc2N1b3VzIG1vZGUNClsgIDQwOS44OTE1NDFdIHhlbl9icmlkZ2U6IHBv
cnQgMTYodmlmMTYuMC1lbXUpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgNDA5Ljg5
ODEwM10geGVuX2JyaWRnZTogcG9ydCAxNih2aWYxNi4wLWVtdSkgZW50ZXJlZCBmb3J3YXJk
aW5nIHN0YXRlDQpbICA0MTAuOTgyNDU1XSBwY2liYWNrIDAwMDA6MDg6MDAuMDogcmVzdG9y
aW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHgzYyAod2FzIDB4MTAwLCB3cml0aW5nIDB4
MTA3KQ0KWyAgNDEwLjk5MTAxM10gcGNpYmFjayAwMDAwOjA4OjAwLjA6IHJlc3RvcmluZyBj
b25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4MTAgKHdhcyAweDQsIHdyaXRpbmcgMHhmZTBmZTAw
NCkNClsgIDQxMC45OTk1MjVdIHBjaWJhY2sgMDAwMDowODowMC4wOiByZXN0b3JpbmcgY29u
ZmlnIHNwYWNlIGF0IG9mZnNldCAweGMgKHdhcyAweDAsIHdyaXRpbmcgMHgxMCkNCihYRU4p
IFsyMDE0LTExLTE4IDE0OjMzOjMxLjY2M10gaW8uYzo1NTI6IGQxNjogYmluZDogbV9nc2k9
MzcgZ19nc2k9MzYgZGV2PTAwLjAwLjUgaW50eD0wIGZmZmY4MzA1MTc5NWRkYTgNCihYRU4p
IFsyMDE0LTExLTE4IDE0OjMzOjMyLjA1M10gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweDgwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozMzozMi4wNTNdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4ODAwLCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHgzZmFhZjAwMDAsIGRvbWFp
biA9IDE2LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMzOjMyLjA1
M10gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowODowMC4wIGZyb20gZG9tMCB0byBkb20xNg0K
WyAgNDEyLjQyNDgzN10gcGNpYmFjayAwMDAwOjBhOjAwLjA6IHJlc3RvcmluZyBjb25maWcg
c3BhY2UgYXQgb2Zmc2V0IDB4M2MgKHdhcyAweDEwMCwgd3JpdGluZyAweDEwYSkNClsgIDQx
Mi40MzEzNzRdIHBjaWJhY2sgMDAwMDowYTowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNl
IGF0IG9mZnNldCAweDEwICh3YXMgMHg0LCB3cml0aW5nIDB4ZmUyMDAwMDQpDQpbICA0MTIu
NDM3Nzg2XSBwY2liYWNrIDAwMDA6MGE6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBh
dCBvZmZzZXQgMHhjICh3YXMgMHgwLCB3cml0aW5nIDB4MTApDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozMzozMy4xMDBdIGlvLmM6NTUyOiBkMTY6IGJpbmQ6IG1fZ3NpPTQ3IGdfZ3NpPTQw
IGRldj0wMC4wMC42IGludHg9MCBmZmZmODMwM2ZhYWYyNWE4DQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozMzozMy4xMDVdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHhhMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MzMu
MTA1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEwMCwg
dHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4M2ZhYWYwMDAwLCBkb21haW4gPSAxNiwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzozMy4xMDVdIEFNRC1WaTog
UmUtYXNzaWduIDAwMDA6MGE6MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTYNCihkMTYpIFsyMDE0
LTExLTE4IDE0OjMzOjMzLjExNl0gSFZNIExvYWRlcg0KKGQxNikgWzIwMTQtMTEtMTggMTQ6
MzM6MzMuMTE2XSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjDQooZDE2KSBbMjAxNC0xMS0xOCAx
NDozMzozMy4xMTZdIFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCAx
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4xMTZdIFN5c3RlbSByZXF1ZXN0ZWQgU2Vh
QklPUw0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMTE2XSBDUFUgc3BlZWQgaXMgMzIw
MCBNSHoNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjExNl0gUmVsb2NhdGluZyBndWVz
dCBtZW1vcnkgZm9yIGxvd21lbSBNTUlPIHNwYWNlIGRpc2FibGVkDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozMzozMy4xMTddIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMCBjaGFuZ2Vk
IDAgLT4gNQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMTE3XSBQQ0ktSVNBIGxpbmsg
MCByb3V0ZWQgdG8gSVJRNQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMTE3XSBpcnEu
YzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwDQooZDE2KSBbMjAxNC0x
MS0xOCAxNDozMzozMy4xMTddIFBDSS1JU0EgbGluayAxIHJvdXRlZCB0byBJUlExMA0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMTE4XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5r
IDIgY2hhbmdlZCAwIC0+IDExDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4xMThdIFBD
SS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6
MzMuMTE4XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDMgY2hhbmdlZCAwIC0+IDUNCihk
MTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjExOF0gUENJLUlTQSBsaW5rIDMgcm91dGVkIHRv
IElSUTUNClsgIDQxMi40NzQ1MTNdIHhlbl9wY2liYWNrOiB2cGNpOiAwMDAwOjA4OjAwLjA6
IGFzc2lnbiB0byB2aXJ0dWFsIHNsb3QgMA0KWyAgNDEyLjQ4MTY5NV0geGVuX3BjaWJhY2s6
IHZwY2k6IDAwMDA6MGE6MDAuMDogYXNzaWduIHRvIHZpcnR1YWwgc2xvdCAxDQooZDE2KSBb
MjAxNC0xMS0xOCAxNDozMzozMy4xMzRdIHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1DQooZDE2
KSBbMjAxNC0xMS0xOCAxNDozMzozMy4xNDFdIHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMA0K
KGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMTQ1XSBwY2kgZGV2IDAyOjAgSU5UQS0+SVJR
MTENCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjE1Nl0gcGNpIGRldiAwNDowIElOVEEt
PklSUTUNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjE2Ml0gcGNpIGRldiAwNTowIElO
VEEtPklSUTEwDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4xNjldIHBjaSBkZXYgMDY6
MCBJTlRBLT5JUlExMQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMjE4XSBObyBSQU0g
aW4gaGlnaCBtZW1vcnk7IHNldHRpbmcgaGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAw
MDAwMDANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjIxOF0gcGNpIGRldiAwMzowIGJh
ciAxMCBzaXplIDAwMjAwMDAwMDogMGYwMDAwMDA4DQooZDE2KSBbMjAxNC0xMS0xOCAxNDoz
MzozMy4yMjFdIHBjaSBkZXYgMDI6MCBiYXIgMTQgc2l6ZSAwMDEwMDAwMDA6IDBmMjAwMDAw
OA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMjIzXSBwY2kgZGV2IDA2OjAgYmFyIDEw
IHNpemUgMDAwMjAwMDAwOiAwZjMwMDAwMDQNCihYRU4pIFsyMDE0LTExLTE4IDE0OjMzOjMz
LjIyM10gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAw
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4yMjldIHBjaSBkZXYgMDQ6MCBiYXIgMzAg
c2l6ZSAwMDAwNDAwMDA6IDBmMzIwMDAwMA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMu
MjMxXSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAwMDIwMDAwOiAwZjMyNDAwMDANCihk
MTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjIzMV0gcGNpIGRldiAwMzowIGJhciAzMCBzaXpl
IDAwMDAxMDAwMDogMGYzMjYwMDAwDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4yMzJd
IHBjaSBkZXYgMDU6MCBiYXIgMTAgc2l6ZSAwMDAwMDIwMDA6IDBmMzI3MDAwNA0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MzM6MzMuMjMyXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYz
MjcwIG1mbj1mZTBmZSBucj0xDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4yMzhdIHBj
aSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDA6IDBmMzI3MjAwMA0KKGQxNikgWzIw
MTQtMTEtMTggMTQ6MzM6MzMuMjM5XSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAw
MTAwOiAwMDAwMGMwMDENCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjI0MV0gcGNpIGRl
diAwNDowIGJhciAxNCBzaXplIDAwMDAwMDA0MDogMDAwMDBjMTAxDQooZDE2KSBbMjAxNC0x
MS0xOCAxNDozMzozMy4yNDRdIHBjaSBkZXYgMDE6MiBiYXIgMjAgc2l6ZSAwMDAwMDAwMjA6
IDAwMDAwYzE0MQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMjQ2XSBwY2kgZGV2IDAx
OjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNjENCihkMTYpIFsyMDE0LTExLTE4
IDE0OjMzOjMzLjI0OV0gTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246DQooZDE2KSBb
MjAxNC0xMS0xOCAxNDozMzozMy4yNzJdICAtIENQVTAgLi4uIDQ4LWJpdCBwaHlzIC4uLiBm
aXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLg0KKGQxNikgWzIwMTQt
MTEtMTggMTQ6MzM6MzMuMjk3XSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQg
TVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4NCihkMTYpIFsyMDE0LTExLTE4
IDE0OjMzOjMzLjMyMF0gIC0gQ1BVMiAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJz
IC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuDQooZDE2KSBbMjAxNC0xMS0xOCAxNDoz
MzozMy4zNDRdICAtIENQVTMgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4g
dmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLg0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMu
MzQ0XSBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMz
OjMzLjM1M10gIC0gUkVQIElOU0IgYWNyb3NzIHBhZ2UgYm91bmRhcmllcyAuLi4gcGFzc2Vk
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNTddICAtIEdTIGJhc2UgTVNScyBhbmQg
U1dBUEdTIC4uLiBwYXNzZWQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM1N10gUGFz
c2VkIDIgb2YgMiB0ZXN0cw0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzU3XSBXcml0
aW5nIFNNQklPUyB0YWJsZXMgLi4uDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNThd
IExvYWRpbmcgU2VhQklPUyAuLi4NCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM1OF0g
Q3JlYXRpbmcgTVAgdGFibGVzIC4uLg0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzU4
XSBMb2FkaW5nIEFDUEkgLi4uDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNTldIHZt
ODYgVFNTIGF0IGZjMDBhMjAwDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNjBdIEJJ
T1MgbWFwOg0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzYwXSAgMTAwMDAtMTAwZDM6
IFNjcmF0Y2ggc3BhY2UNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2MF0gIGMwMDAw
LWZmZmZmOiBNYWluIEJJT1MNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2MF0gRTgy
MCB0YWJsZToNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2MF0gIFswMF06IDAwMDAw
MDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJBTQ0KKGQxNikgWzIwMTQtMTEt
MTggMTQ6MzM6MzMuMzYwXSAgSE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDow
MDBjMDAwMA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzYwXSAgWzAxXTogMDAwMDAw
MDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQNCihkMTYpIFsyMDE0
LTExLTE4IDE0OjMzOjMzLjM2MF0gIFswMl06IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAw
MDA6M2Y4MDAwMDA6IFJBTQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzYwXSAgSE9M
RTogMDAwMDAwMDA6M2Y4MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMA0KKGQxNikgWzIwMTQt
MTEtMTggMTQ6MzM6MzMuMzYwXSAgWzAzXTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAw
MTowMDAwMDAwMDogUkVTRVJWRUQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2MF0g
SW52b2tpbmcgU2VhQklPUyAuLi4NCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2M10g
U2VhQklPUyAodmVyc2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTExOF8xMjUyMjMt
c2VydmVlcnN0ZXJ0amUpDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNjNdIA0KKGQx
NikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzYzXSBGb3VuZCBYZW4gaHlwZXJ2aXNvciBzaWdu
YXR1cmUgYXQgNDAwMDAwMDANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2NF0gUnVu
bmluZyBvbiBRRU1VIChpNDQwZngpDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNjRd
IHhlbjogY29weSBlODIwLi4uDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNjRdIFJl
bG9jYXRpbmcgaW5pdCBmcm9tIDB4MDAwZGY2MjkgdG8gMHgzZjdhZTYwMCAoc2l6ZSA3MTk5
NSkNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM2Nl0gQ1BVIE1oej0zMjAyDQooZDE2
KSBbMjAxNC0xMS0xOCAxNDozMzozMy4zNzFdIEZvdW5kIDEwIFBDSSBkZXZpY2VzIChtYXgg
UENJIGJ1cyBpcyAwMCkNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM3MV0gQWxsb2Nh
dGVkIFhlbiBoeXBlcmNhbGwgcGFnZSBhdCAzZjdmZjAwMA0KKGQxNikgWzIwMTQtMTEtMTgg
MTQ6MzM6MzMuMzcxXSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjDQooZDE2KSBbMjAxNC0xMS0x
OCAxNDozMzozMy4zNzFdIHhlbjogY29weSBCSU9TIHRhYmxlcy4uLg0KKGQxNikgWzIwMTQt
MTEtMTggMTQ6MzM6MzMuMzcxXSBDb3B5aW5nIFNNQklPUyBlbnRyeSBwb2ludCBmcm9tIDB4
MDAwMTAwMTAgdG8gMHgwMDBmMGY1MA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzcx
XSBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMWEwL2ZjMDAxMWIwIHRvIDB4MDAwZjBl
MzANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM3MV0gQ29weWluZyBQSVIgZnJvbSAw
eDAwMDEwMDMwIHRvIDB4MDAwZjBkYjANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM3
MV0gQ29weWluZyBBQ1BJIFJTRFAgZnJvbSAweDAwMDEwMGIwIHRvIDB4MDAwZjBkODANCihk
MTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjM3Ml0gVXNpbmcgcG10aW1lciwgaW9wb3J0IDB4
YjAwOA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzcyXSBTY2FuIGZvciBWR0Egb3B0
aW9uIHJvbQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuMzg3XSBSdW5uaW5nIG9wdGlv
biByb20gYXQgYzAwMDowMDAzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzozMy4zOTVdIHN0
ZHZnYS5jOjE0NzpkMTZ2MCBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMNCihk
MTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjQyMV0gcG1tIGNhbGwgYXJnMT0wDQooZDE2KSBb
MjAxNC0xMS0xOCAxNDozMzozMy40MjNdIFR1cm5pbmcgb24gdmdhIHRleHQgbW9kZSBjb25z
b2xlDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy41NDJdIFNlYUJJT1MgKHZlcnNpb24g
cmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMThfMTI1MjIzLXNlcnZlZXJzdGVydGplKQ0K
KGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNTU1XSBNYWNoaW5lIFVVSUQgNmIwZTU5MWEt
NzIyMy00YmE5LWJlOTUtMDU1NmVhNjdhYWJlDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzoz
My41NTZdIFhIQ0kgaW5pdCBvbiBkZXYgMDA6MDUuMDogcmVncyBAIDB4ZjMyNzAwMDAsIDQg
cG9ydHMsIDMyIHNsb3RzLCAzMiBieXRlIGNvbnRleHQNCihkMTYpIFsyMDE0LTExLTE4IDE0
OjMzOjMzLjU1Nl0gcw0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNTU2XSBYSENJICAg
IGV4dGNhcCAweDEgQCBmMzI3MDUwMA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNTU2
XSBYSENJICAgIHByb3RvY29sIFVTQiAgMy4wMCwgMiBwb3J0cyAob2Zmc2V0IDEpLCBkZWYg
MA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNTU2XSBYSENJICAgIHByb3RvY29sIFVT
QiAgMi4wMCwgMiBwb3J0cyAob2Zmc2V0IDMpLCBkZWYgMA0KKGQxNikgWzIwMTQtMTEtMTgg
MTQ6MzM6MzMuNTU3XSBVSENJIGluaXQgb24gZGV2IDAwOjAxLjIgKGlvPWMxNDApDQooZDE2
KSBbMjAxNC0xMS0xOCAxNDozMzozMy41NThdIEZvdW5kIDAgbHB0IHBvcnRzDQooZDE2KSBb
MjAxNC0xMS0xOCAxNDozMzozMy41NTldIEZvdW5kIDEgc2VyaWFsIHBvcnRzDQooZDE2KSBb
MjAxNC0xMS0xOCAxNDozMzozMy41NjBdIEFUQSBjb250cm9sbGVyIDEgYXQgMWYwLzNmNC8w
IChpcnEgMTQgZGV2IDkpDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy41NjFdIEFUQSBj
b250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUgZGV2IDkpDQooZDE2KSBbMjAxNC0x
MS0xOCAxNDozMzozMy41NjRdIGF0YTAtMDogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURp
c2sgKDEwMjQwIE1pQnl0ZXMpDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy41NjRdIFNl
YXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4LypAMSwxL2RyaXZlQDAvZGlza0Aw
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy41NjZdIGF0YTAtMTogUUVNVSBIQVJERElT
SyBBVEEtNyBIYXJkLURpc2sgKDMwMCBHaUJ5dGVzKQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6
MzM6MzMuNTY2XSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDEsMS9k
cml2ZUAwL2Rpc2tAMQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNjY0XSBQUzIga2V5
Ym9hcmQgaW5pdGlhbGl6ZWQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjcwOF0gWEhD
SSBwb3J0ICM0OiAweDAwMjAwYTAzLCBwb3dlcmVkLCBlbmFibGVkLCBwbHMgMCwgc3BlZWQg
MiBbTG93XQ0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNzM5XSBYSENJIG5vIGRldmlj
ZXMgZm91bmQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjc1MF0gQWxsIHRocmVhZHMg
Y29tcGxldGUuDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy43NTBdIFNjYW4gZm9yIG9w
dGlvbiByb21zDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy43NzJdIFJ1bm5pbmcgb3B0
aW9uIHJvbSBhdCBjOTgwOjAwMDMNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjc3OV0g
cG1tIGNhbGwgYXJnMT0xDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy43NzldIHBtbSBj
YWxsIGFyZzE9MA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNzgwXSBwbW0gY2FsbCBh
cmcxPTENCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjc4MV0gcG1tIGNhbGwgYXJnMT0w
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy43OTddIFNlYXJjaGluZyBib290b3JkZXIg
Zm9yOiAvcGNpQGkwY2Y4LypANA0KKGQxNikgWzIwMTQtMTEtMTggMTQ6MzM6MzMuNzk3XSAN
CihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjMzLjgwM10gUHJlc3MgRjEyIGZvciBib290IG1l
bnUuDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozMy44MDRdIA0KWyAgNDEzLjM2NDM0OV0g
eGVuX2JyaWRnZTogcG9ydCAxNCh2aWYxNC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUN
CihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjM3Nl0gU2VhcmNoaW5nIGJvb3RvcmRlciBm
b3I6IEhBTFQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjM3N10gZHJpdmUgMHgwMDBm
MGQzMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82
MyBzPTIwOTcxNTIwDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozNi4zNzhdIGRyaXZlIDB4
MDAwZjBkMDA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8y
NTUvNjMgcz02MjkxNDU2MDANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjM3OF0gDQoo
ZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozNi4zNzhdIFNwYWNlIGF2YWlsYWJsZSBmb3IgVU1C
OiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkMDANCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2
LjM3OF0gUmV0dXJuZWQgMjUzOTUyIGJ5dGVzIG9mIFpvbmVIaWdoDQooZDE2KSBbMjAxNC0x
MS0xOCAxNDozMzozNi4zNzhdIGU4MjAgbWFwIGhhcyA2IGl0ZW1zOg0KKGQxNikgWzIwMTQt
MTEtMTggMTQ6MzM6MzYuMzc4XSAgIDA6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAw
MDlmYzAwID0gMSBSQU0NCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjM3OV0gICAxOiAw
MDAwMDAwMDAwMDlmYzAwIC0gMDAwMDAwMDAwMDBhMDAwMCA9IDIgUkVTRVJWRUQNCihkMTYp
IFsyMDE0LTExLTE4IDE0OjMzOjM2LjM3OV0gICAyOiAwMDAwMDAwMDAwMGYwMDAwIC0gMDAw
MDAwMDAwMDEwMDAwMCA9IDIgUkVTRVJWRUQNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2
LjM3OV0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDAzZjdmZTAwMCA9IDEgUkFN
DQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozNi4zNzldICAgNDogMDAwMDAwMDAzZjdmZTAw
MCAtIDAwMDAwMDAwM2Y4MDAwMDAgPSAyIFJFU0VSVkVEDQooZDE2KSBbMjAxNC0xMS0xOCAx
NDozMzozNi4zNzldICAgNTogMDAwMDAwMDBmYzAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAg
PSAyIFJFU0VSVkVEDQooZDE2KSBbMjAxNC0xMS0xOCAxNDozMzozNi4zODJdIGVudGVyIGhh
bmRsZV8xOToNCihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjM4Ml0gICBOVUxMDQooZDE2
KSBbMjAxNC0xMS0xOCAxNDozMzozNi40MDZdIEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4N
CihkMTYpIFsyMDE0LTExLTE4IDE0OjMzOjM2LjQwOF0gQm9vdGluZyBmcm9tIDAwMDA6N2Mw
MA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6MzguNzMzXSAtLU1BUkstLQ0KWyAgNDE5LjE2
NTIyOF0gZGV2aWNlIHZpZjE3LjAgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQpbICA0MTku
MzM0NTkyXSB2cG5fYnJpZGdlOiBwb3J0IDEodmlmMTUuMCkgZW50ZXJlZCBmb3J3YXJkaW5n
IHN0YXRlDQpbICA0MTkuMzM3MzU2XSBkZXZpY2UgdmlmMTcuMC1lbXUgZW50ZXJlZCBwcm9t
aXNjdW91cyBtb2RlDQpbICA0MTkuMzQwNjUwXSB4ZW5fYnJpZGdlOiBwb3J0IDE4KHZpZjE3
LjAtZW11KSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDQxOS4zNDA2NTZdIHhlbl9i
cmlkZ2U6IHBvcnQgMTgodmlmMTcuMC1lbXUpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0K
KGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMDQ3XSBIVk0gTG9hZGVyDQooZDE3KSBbMjAx
NC0xMS0xOCAxNDozMzo0MC4wNDddIERldGVjdGVkIFhlbiB2NC41LjAtcmMNCihkMTcpIFsy
MDE0LTExLTE4IDE0OjMzOjQwLjA0N10gWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBldmVu
dCBjaGFubmVsIDENCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjA0N10gU3lzdGVtIHJl
cXVlc3RlZCBTZWFCSU9TDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4wNDddIENQVSBz
cGVlZCBpcyAzMjAwIE1Ieg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMDQ3XSBSZWxv
Y2F0aW5nIGd1ZXN0IG1lbW9yeSBmb3IgbG93bWVtIE1NSU8gc3BhY2UgZGlzYWJsZWQNCihY
RU4pIFsyMDE0LTExLTE4IDE0OjMzOjQwLjA0OF0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGlu
ayAwIGNoYW5nZWQgMCAtPiA1DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4wNDhdIFBD
SS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzo0
MC4wNDhdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTANCihk
MTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjA0OF0gUENJLUlTQSBsaW5rIDEgcm91dGVkIHRv
IElSUTEwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzo0MC4wNDhdIGlycS5jOjI3MDogRG9t
MTcgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihkMTcpIFsyMDE0LTExLTE4IDE0OjMz
OjQwLjA0OF0gUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozMzo0MC4wNDldIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMyBjaGFuZ2Vk
IDAgLT4gNQ0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMDQ5XSBQQ0ktSVNBIGxpbmsg
MyByb3V0ZWQgdG8gSVJRNQ0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMDY4XSBwY2kg
ZGV2IDAxOjMgSU5UQS0+SVJRMTANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjA3M10g
cGNpIGRldiAwMjowIElOVEEtPklSUTExDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4w
ODRdIHBjaSBkZXYgMDQ6MCBJTlRBLT5JUlE1DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0
MC4xNDBdIE5vIFJBTSBpbiBoaWdoIG1lbW9yeTsgc2V0dGluZyBoaWdoX21lbSByZXNvdXJj
ZSBiYXNlIHRvIDEwMDAwMDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMTQwXSBw
Y2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAyMDAwMDAwOiAwZjAwMDAwMDgNCihkMTcpIFsy
MDE0LTExLTE4IDE0OjMzOjQwLjE0Ml0gcGNpIGRldiAwMjowIGJhciAxNCBzaXplIDAwMTAw
MDAwMDogMGYyMDAwMDA4DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4xNDRdIHBjaSBk
ZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAwNDAwMDA6IDBmMzAwMDAwMA0KKGQxNykgWzIwMTQt
MTEtMTggMTQ6MzM6NDAuMTQ2XSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAwMDIwMDAw
OiAwZjMwNDAwMDANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjE0N10gcGNpIGRldiAw
MzowIGJhciAzMCBzaXplIDAwMDAxMDAwMDogMGYzMDYwMDAwDQooZDE3KSBbMjAxNC0xMS0x
OCAxNDozMzo0MC4xNDldIHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDA6IDBm
MzA3MDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMTQ5XSBwY2kgZGV2IDAyOjAg
YmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDENCihkMTcpIFsyMDE0LTExLTE4IDE0
OjMzOjQwLjE1Ml0gcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDA0MDogMDAwMDBj
MTAxDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4xNTRdIHBjaSBkZXYgMDE6MSBiYXIg
MjAgc2l6ZSAwMDAwMDAwMTA6IDAwMDAwYzE0MQ0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6
NDAuMTU2XSBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoNCihkMTcpIFsyMDE0LTEx
LTE4IDE0OjMzOjQwLjE3OF0gIC0gQ1BVMCAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1U
UlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuDQooZDE3KSBbMjAxNC0xMS0xOCAx
NDozMzo0MC4xOTNdICAtIENQVTEgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAu
Li4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6
NDAuMjEwXSAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh
ciBNVFJScyBbMS84XSAuLi4gZG9uZS4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjIy
Nl0gIC0gQ1BVMyAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRS
UnMgWzEvOF0gLi4uIGRvbmUuDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yMjZdIFRl
c3RpbmcgSFZNIGVudmlyb25tZW50Og0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjM2
XSAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQNCihkMTcp
IFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0MF0gIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1Mg
Li4uIHBhc3NlZA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQwXSBQYXNzZWQgMiBv
ZiAyIHRlc3RzDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNDBdIFdyaXRpbmcgU01C
SU9TIHRhYmxlcyAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0MV0gTG9hZGlu
ZyBTZWFCSU9TIC4uLg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQxXSBDcmVhdGlu
ZyBNUCB0YWJsZXMgLi4uDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNDFdIExvYWRp
bmcgQUNQSSAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0M10gdm04NiBUU1Mg
YXQgZmMwMGEyMDANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0NF0gQklPUyBtYXA6
DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNDRdICAxMDAwMC0xMDBkMzogU2NyYXRj
aCBzcGFjZQ0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ0XSAgYzAwMDAtZmZmZmY6
IE1haW4gQklPUw0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ0XSBFODIwIHRhYmxl
Og0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ0XSAgWzAwXTogMDAwMDAwMDA6MDAw
MDAwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkFNDQooZDE3KSBbMjAxNC0xMS0xOCAxNDoz
Mzo0MC4yNDRdICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGMwMDAw
DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNDRdICBbMDFdOiAwMDAwMDAwMDowMDBj
MDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBSRVNFUlZFRA0KKGQxNykgWzIwMTQtMTEtMTgg
MTQ6MzM6NDAuMjQ0XSAgWzAyXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDozZjgw
MDAwMDogUkFNDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNDRdICBIT0xFOiAwMDAw
MDAwMDozZjgwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwDQooZDE3KSBbMjAxNC0xMS0xOCAx
NDozMzo0MC4yNDRdICBbMDNdOiAwMDAwMDAwMDpmYzAwMDAwMCAtIDAwMDAwMDAxOjAwMDAw
MDAwOiBSRVNFUlZFRA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ0XSBJbnZva2lu
ZyBTZWFCSU9TIC4uLg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ3XSBTZWFCSU9T
ICh2ZXJzaW9uIHJlbC0xLjcuNS0wLWdlNTE0ODhjLTIwMTQxMTE4XzEyNTIyMy1zZXJ2ZWVy
c3RlcnRqZSkNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0N10gDQooZDE3KSBbMjAx
NC0xMS0xOCAxNDozMzo0MC4yNDddIEZvdW5kIFhlbiBoeXBlcnZpc29yIHNpZ25hdHVyZSBh
dCA0MDAwMDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjQ4XSBSdW5uaW5nIG9u
IFFFTVUgKGk0NDBmeCkNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0OF0geGVuOiBj
b3B5IGU4MjAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI0OF0gUmVsb2NhdGlu
ZyBpbml0IGZyb20gMHgwMDBkZjYyOSB0byAweDNmN2FlNjAwIChzaXplIDcxOTk1KQ0KKGQx
NykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjUwXSBDUFUgTWh6PTMyMDENCihkMTcpIFsyMDE0
LTExLTE4IDE0OjMzOjQwLjI1NV0gRm91bmQgNyBQQ0kgZGV2aWNlcyAobWF4IFBDSSBidXMg
aXMgMDApDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNTVdIEFsbG9jYXRlZCBYZW4g
aHlwZXJjYWxsIHBhZ2UgYXQgM2Y3ZmYwMDANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQw
LjI1NV0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYw0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6
NDAuMjU1XSB4ZW46IGNvcHkgQklPUyB0YWJsZXMuLi4NCihkMTcpIFsyMDE0LTExLTE4IDE0
OjMzOjQwLjI1NV0gQ29weWluZyBTTUJJT1MgZW50cnkgcG9pbnQgZnJvbSAweDAwMDEwMDEw
IHRvIDB4MDAwZjBmNTANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI1NV0gQ29weWlu
ZyBNUFRBQkxFIGZyb20gMHhmYzAwMTFhMC9mYzAwMTFiMCB0byAweDAwMGYwZTMwDQooZDE3
KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNTZdIENvcHlpbmcgUElSIGZyb20gMHgwMDAxMDAz
MCB0byAweDAwMGYwZGIwDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC4yNTZdIENvcHlp
bmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAwMGYwZDgwDQooZDE3KSBbMjAx
NC0xMS0xOCAxNDozMzo0MC4yNTZdIFVzaW5nIHBtdGltZXIsIGlvcG9ydCAweGIwMDgNCihk
MTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI1Nl0gU2NhbiBmb3IgVkdBIG9wdGlvbiByb20N
CihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjI3M10gUnVubmluZyBvcHRpb24gcm9tIGF0
IGMwMDA6MDAwMw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6NDAuMjg0XSBzdGR2Z2EuYzox
NDc6ZDE3djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzDQooZDE3KSBbMjAx
NC0xMS0xOCAxNDozMzo0MC4zMTFdIHBtbSBjYWxsIGFyZzE9MA0KKGQxNykgWzIwMTQtMTEt
MTggMTQ6MzM6NDAuMzEyXSBUdXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUgY29uc29sZQ0KKGQx
NykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuNDQ1XSBTZWFCSU9TICh2ZXJzaW9uIHJlbC0xLjcu
NS0wLWdlNTE0ODhjLTIwMTQxMTE4XzEyNTIyMy1zZXJ2ZWVyc3RlcnRqZSkNCihkMTcpIFsy
MDE0LTExLTE4IDE0OjMzOjQwLjQ2MF0gTWFjaGluZSBVVUlEIDZkNDkzMjI0LTRhNjQtNDdh
YS05MjExLTM3NWIxZjE2NTQ1Yg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuNDYwXSBB
bGwgdGhyZWFkcyBjb21wbGV0ZS4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjQ2MV0g
Rm91bmQgMCBscHQgcG9ydHMNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjQ2Ml0gRm91
bmQgMCBzZXJpYWwgcG9ydHMNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjQ2Ml0gQVRB
IGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0LzAgKGlycSAxNCBkZXYgOSkNCihkMTcpIFsyMDE0
LTExLTE4IDE0OjMzOjQwLjQ2M10gQVRBIGNvbnRyb2xsZXIgMiBhdCAxNzAvMzc0LzAgKGly
cSAxNSBkZXYgOSkNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQwLjQ2OF0gYXRhMC0wOiBR
RU1VIEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAoMTAyNDAgTWlCeXRlcykNCihkMTcpIFsy
MDE0LTExLTE4IDE0OjMzOjQwLjQ2OF0gU2VhcmNoaW5nIGJvb3RvcmRlciBmb3I6IC9wY2lA
aTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQw
LjU2Nl0gUFMyIGtleWJvYXJkIGluaXRpYWxpemVkDQooZDE3KSBbMjAxNC0xMS0xOCAxNDoz
Mzo0MC41NjZdIEFsbCB0aHJlYWRzIGNvbXBsZXRlLg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6
MzM6NDAuNTY2XSBTY2FuIGZvciBvcHRpb24gcm9tcw0KKGQxNykgWzIwMTQtMTEtMTggMTQ6
MzM6NDAuNTkyXSBSdW5uaW5nIG9wdGlvbiByb20gYXQgYzk4MDowMDAzDQooZDE3KSBbMjAx
NC0xMS0xOCAxNDozMzo0MC41OTldIHBtbSBjYWxsIGFyZzE9MQ0KKGQxNykgWzIwMTQtMTEt
MTggMTQ6MzM6NDAuNjAwXSBwbW0gY2FsbCBhcmcxPTANCihkMTcpIFsyMDE0LTExLTE4IDE0
OjMzOjQwLjYwMV0gcG1tIGNhbGwgYXJnMT0xDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0
MC42MDJdIHBtbSBjYWxsIGFyZzE9MA0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAuNjIx
XSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDQNCihkMTcpIFsyMDE0
LTExLTE4IDE0OjMzOjQwLjYyMV0gDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0MC42Mjhd
IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDAu
NjI5XSANCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQzLjE4Nl0gU2VhcmNoaW5nIGJvb3Rv
cmRlciBmb3I6IEhBTFQNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQzLjE4Nl0gZHJpdmUg
MHgwMDBmMGQzMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0
LzI1NS82MyBzPTIwOTcxNTIwDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0My4xODZdIFNw
YWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkMzANCihkMTcp
IFsyMDE0LTExLTE4IDE0OjMzOjQzLjE4Nl0gUmV0dXJuZWQgMjU4MDQ4IGJ5dGVzIG9mIFpv
bmVIaWdoDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0My4xODZdIGU4MjAgbWFwIGhhcyA2
IGl0ZW1zOg0KKGQxNykgWzIwMTQtMTEtMTggMTQ6MzM6NDMuMTg2XSAgIDA6IDAwMDAwMDAw
MDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0NCihkMTcpIFsyMDE0LTExLTE4
IDE0OjMzOjQzLjE4Nl0gICAxOiAwMDAwMDAwMDAwMDlmYzAwIC0gMDAwMDAwMDAwMDBhMDAw
MCA9IDIgUkVTRVJWRUQNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQzLjE4Nl0gICAyOiAw
MDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCA9IDIgUkVTRVJWRUQNCihkMTcp
IFsyMDE0LTExLTE4IDE0OjMzOjQzLjE4Nl0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAw
MDAwMDAzZjdmZjAwMCA9IDEgUkFNDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0My4xODZd
ICAgNDogMDAwMDAwMDAzZjdmZjAwMCAtIDAwMDAwMDAwM2Y4MDAwMDAgPSAyIFJFU0VSVkVE
DQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0My4xODZdICAgNTogMDAwMDAwMDBmYzAwMDAw
MCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJFU0VSVkVEDQooZDE3KSBbMjAxNC0xMS0xOCAx
NDozMzo0My4xODddIGVudGVyIGhhbmRsZV8xOToNCihkMTcpIFsyMDE0LTExLTE4IDE0OjMz
OjQzLjE4N10gICBOVUxMDQooZDE3KSBbMjAxNC0xMS0xOCAxNDozMzo0My4xOTRdIEJvb3Rp
bmcgZnJvbSBIYXJkIERpc2suLi4NCihkMTcpIFsyMDE0LTExLTE4IDE0OjMzOjQzLjE5N10g
Qm9vdGluZyBmcm9tIDAwMDA6N2MwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6NDQuNTc1
XSBzdGR2Z2EuYzoxNTE6ZDE2djAgbGVhdmluZyBzdGR2Z2ENClsgIDQyNC45MzE4ODhdIHhl
bl9icmlkZ2U6IHBvcnQgMTYodmlmMTYuMC1lbXUpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0
ZQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzM6NDUuOTcxXSBncmFudF90YWJsZS5jOjMwNTpk
MHYxIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDcgZnJhbWVzDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozMzo0OC43MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzo1
Mi41NTNdIHN0ZHZnYS5jOjE1MTpkMTd2MCBsZWF2aW5nIHN0ZHZnYQ0KWyAgNDM0LjM2NzEz
M10geGVuX2JyaWRnZTogcG9ydCAxOCh2aWYxNy4wLWVtdSkgZW50ZXJlZCBmb3J3YXJkaW5n
IHN0YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozMzo1OC43MzRdIC0tTUFSSy0tDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDozNDowOC43MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozNDoxMC4xOTJdIHN0ZHZnYS5jOjE0NzpkMTZ2MCBlbnRlcmluZyBzdGR2Z2EgYW5k
IGNhY2hpbmcgbW9kZXMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjExLjg4Nl0gaXJxLmM6
MzgwOiBEb20xNiBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMN
CihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3Ljc0NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRv
bTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6
MTcuNzQ4XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0x
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDoxNy43NTJdIG1lbW9yeV9tYXA6cmVtb3ZlOiBk
b20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0
OjE3Ljc1N10gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9
MQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcuNzYxXSBtZW1vcnlfbWFwOnJlbW92ZTog
ZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xDQooWEVOKSBbMjAxNC0xMS0xOCAxNDoz
NDoxNy43NjVdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5y
PTENCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3Ljc2OV0gbWVtb3J5X21hcDpyZW1vdmU6
IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6
MzQ6MTcuNzczXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBu
cj0xDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDoxNy43NzddIG1lbW9yeV9tYXA6cmVtb3Zl
OiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDE0
OjM0OjE3Ljc4MV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUg
bnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcuNzg1XSBtZW1vcnlfbWFwOnJlbW92
ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozNDoxNy43ODldIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZl
IG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3LjgwMF0gbWVtb3J5X21hcDpyZW1v
dmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozNDoxNy44MDZdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZl
MjAwIG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcuODEyXSBtZW1vcnlfbWFw
OnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDANCihYRU4pIFsyMDE0
LTExLTE4IDE0OjM0OjE3LjgxOF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBt
Zm49ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDoxNy44MjNdIG1lbW9y
eV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMA0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MzQ6MTcuODI5XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYz
MDAwIG1mbj1mZTIwMCBucj0yMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3LjgzNV0g
bWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDozNDoxNy44NDFdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBn
Zm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcu
ODQ3XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0y
MDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3Ljg1MV0gc3RkdmdhLmM6MTQ3OmQxN3Yw
IGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2Rlcw0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6MzQ6MTcuODUyXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIw
MCBucj0yMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjE3Ljg1OF0gbWVtb3J5X21hcDpy
ZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozNDoxNy44NjRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZu
PWZlMjAwIG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcuODk2XSBpcnEuYzoy
NzA6IERvbTE2IFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDANCihYRU4pIFsyMDE0LTExLTE4
IDE0OjM0OjE3LjkxNl0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAxIGNoYW5nZWQgMTAg
LT4gMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MTcuOTM2XSBpcnEuYzoyNzA6IERvbTE2
IFBDSSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDox
Ny45NTVdIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMA0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MzQ6MTguNzM0XSAtLU1BUkstLQ0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MzQ6MTkuNTQzXSBpcnEuYzozODA6IERvbTE3IGNhbGxiYWNrIHZpYSBjaGFuZ2Vk
IHRvIERpcmVjdCBWZWN0b3IgMHhmMw0KWyAgNDU4Ljk4NDcxMl0geGVuLWJsa2JhY2s6cmlu
Zy1yZWYgOCwgZXZlbnQtY2hhbm5lbCAzMiwgcHJvdG9jb2wgMSAoeDg2XzY0LWFiaSkgcGVy
c2lzdGVudCBncmFudHMNClsgIDQ1OC45OTk0NjBdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDks
IGV2ZW50LWNoYW5uZWwgMzMsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQg
Z3JhbnRzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDoxOS45MTVdIGdyYW50X3RhYmxlLmM6
MTI5OTpkMTZ2MiBFeHBhbmRpbmcgZG9tICgxNikgZ3JhbnQgdGFibGUgZnJvbSAoNCkgdG8g
KDUpIGZyYW1lcy4NClsgIDQ1OS4yODc5NDhdIHZpZiB2aWYtMTYtMCB2aWYxNi4wOiBHdWVz
dCBSeCByZWFkeQ0KWyAgNDU5LjI5NDE4M10geGVuX2JyaWRnZTogcG9ydCAxNSh2aWYxNi4w
KSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDQ1OS4zMDAzNTZdIHhlbl9icmlkZ2U6
IHBvcnQgMTUodmlmMTYuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDozNDoyMC42NTVdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMCBjaGFu
Z2VkIDUgLT4gMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MjAuNjYyXSBpcnEuYzoyNzA6
IERvbTE3IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozNDoyMC42NjhdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+
IDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjM0OjIwLjY3NF0gaXJxLmM6MjcwOiBEb20xNyBQ
Q0kgbGluayAzIGNoYW5nZWQgNSAtPiAwDQpbICA0NjAuNDkzNjU1XSB4ZW4tYmxrYmFjazpy
aW5nLXJlZiA5LCBldmVudC1jaGFubmVsIDMzLCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBw
ZXJzaXN0ZW50IGdyYW50cw0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MjEuMTUyXSBncmFu
dF90YWJsZS5jOjEyOTk6ZDE3djAgRXhwYW5kaW5nIGRvbSAoMTcpIGdyYW50IHRhYmxlIGZy
b20gKDQpIHRvICg1KSBmcmFtZXMuDQpbICA0NjAuNTI4ODY0XSB2aWYgdmlmLTE3LTAgdmlm
MTcuMDogR3Vlc3QgUnggcmVhZHkNClsgIDQ2MC41MzUzNTFdIHhlbl9icmlkZ2U6IHBvcnQg
MTcodmlmMTcuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICA0NjAuNTQxODIxXSB4
ZW5fYnJpZGdlOiBwb3J0IDE3KHZpZjE3LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MzQ6MjguNzM0XSAtLU1BUkstLQ0KWyAgNDc0LjM0NzMy
N10geGVuX2JyaWRnZTogcG9ydCAxNSh2aWYxNi4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3Rh
dGUNClsgIDQ3NS41NzM0NDRdIHhlbl9icmlkZ2U6IHBvcnQgMTcodmlmMTcuMCkgZW50ZXJl
ZCBmb3J3YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDozOC43MzRdIC0t
TUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNDo0OC43MzRdIC0tTUFSSy0tDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDozNDo1OC43MzVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDozNTowMi40MzJdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRy
YWNrIHNpemUgdG8gOCBmcmFtZXMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjM1OjA4LjczNV0g
LS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjM1OjE4LjczNV0gLS1NQVJLLS0NCihY
RU4pIFsyMDE0LTExLTE4IDE0OjM1OjI4LjczNV0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjM1OjM4LjczNV0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjM1OjQ4
LjczNl0gLS1NQVJLLS0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjM1OjU4LjczNl0gLS1NQVJL
LS0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjM2OjA3LjY3NV0gZ3JhbnRfdGFibGUuYzoxMjk5
OmQxNnYwIEV4cGFuZGluZyBkb20gKDE2KSBncmFudCB0YWJsZSBmcm9tICg1KSB0byAoNikg
ZnJhbWVzLg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MzY6MDcuNjk5XSBncmFudF90YWJsZS5j
OjMwNTpkMHY1IEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDkgZnJhbWVzDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDozNjowOC43MzZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozNjoxOC43MzZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNjoyOC43Mzdd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNjozOC43MzddIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDozNjo0OC43MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozNjo1OC43MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNzow
OC43MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNzoxOC43MzhdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNzoyOC43MzhdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDozNzozOC43MzhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozNzo0OC43MzhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozNzo1OC43Mzld
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozODowOC45MjFdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDozODoxOC45MjFdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozODoyOC45MjFdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozODoz
OC45MjJdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozODo0OC45MjJdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozODo1OC45MjJdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDozOTowOC45MjJdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDozOToxOC45MjJdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozOToyOC45MjNd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDozOTozOC45MjNdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDozOTo0OC45MjNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDozOTo1OC45MjNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MDow
OC45MjNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MDoxOC45MjRdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MDoyOC45MjRdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0MDozOC45MjRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0MDo0OC45MjRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MDo1OC45MjRd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MTowOC45MjRdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0MToxOC45MjVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0MToyOC45MjVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MToz
OC45MjVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MTo0OC45MjVdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MTo1OC45MjVdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0MjowOC45MjZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0MjoxOC45MjZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MjoyOC45MjZd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MjozOC45MjZdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0Mjo0OC45MjZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0Mjo1OC45MjddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Mzow
OC45MjddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MzoxOC45MjddIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0MzoyOC45MjddIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0MzozOC45MjddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0Mzo0OC45MjddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Mzo1OC45Mjhd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NDowOC45MjhdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0NDoxOC45MjhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0NDoyOC45MjhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NDoz
OC45MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NDo0OC45MjldIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NDo1OC45MjldIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0NTowOC45MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0NToxOC45MjldIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NToyOC45MzBd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NTozOC45MzBdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0NTo0OC45MzBdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0NTo1OC45MzBdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Njow
OC45MzFdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NjoxOC45MzFdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NjoyOC45MzFdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0NjozOC45MzFdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0Njo0OC45MzJdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Njo1OC45MzJd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0NzowOC45MzJdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0NzoxOC45MzJdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0NzoyOC45MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Nzoz
OC45MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Nzo0OC45MzNdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0Nzo1OC45MzNdIC0tTUFSSy0tDQooWEVOKSBb
MjAxNC0xMS0xOCAxNDo0ODowOC45MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo0ODoxOC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0ODoyOC45MzRd
IC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0ODozOC45MzRdIC0tTUFSSy0tDQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDo0ODo0OC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo0ODo1OC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0OTow
OC45MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0OToxOC45MzNdIC0tTUFS
Sy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0OToyMC4zMzddIGdyYW50X3RhYmxlLmM6MzA1
OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gMTAgZnJhbWVzDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDo0OToyOC45MzNdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0
OTozOC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0OTo0OC45MzRdIC0t
TUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo0OTo1OC45MzRdIC0tTUFSSy0tDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDo1MDowOC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDo1MDoxOC45MzRdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MDoyOC45
MzVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MDozOC45MzVdIC0tTUFSSy0t
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MDo0OC45MzVdIC0tTUFSSy0tDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDo1MDo1OC45MzVdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1
MTowOC45MzZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MToxOC45MzZdIC0t
TUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MToyOC45MzZdIC0tTUFSSy0tDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDo1MTozOC45MzZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDo1MTo0OC45MzZdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MTo1OC45
MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MjowOC45MzddIC0tTUFSSy0t
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MjoxOC45MzddIC0tTUFSSy0tDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDo1MjoyOC45MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1
MjozOC45MzddIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1Mjo0OC45MzhdIC0t
TUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1Mjo1OC45MzhdIC0tTUFSSy0tDQooWEVO
KSBbMjAxNC0xMS0xOCAxNDo1MzowOC45MzhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDo1MzoxOC45MzhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzoyOC45
MzhdIC0tTUFSSy0tDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy4zMDZdICAwOiBmZmZm
ODMwM2ZhYWYyNWE4IFtwOmZmZmY4MzA1NGVmMmUzZTAsIG46ZmZmZjgzMDU0ZWYyZTNlMF0N
CihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3LjMzMF0gLS0tLVsgWGVuLTQuNS4wLXJjICB4
ODZfNjQgIGRlYnVnPXkgIE5vdCB0YWludGVkIF0tLS0tDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo1MzozNy4zNTNdIENQVTogICAgNA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzcuMzY0
XSBSSVA6ICAgIGUwMDg6WzxmZmZmODJkMDgwMTRhNGRlPl0gaHZtX2RvX0lSUV9kcGNpKzB4
ZjQvMHgxMzENCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3LjM4OV0gUkZMQUdTOiAwMDAw
MDAwMDAwMDEwMDgyICAgQ09OVEVYVDogaHlwZXJ2aXNvcg0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6NTM6MzcuNDEwXSByYXg6IGZmZmY4MzA1NGVmMmUzZTAgICByYng6IGZmZmY4MzAzZmFh
ZjI1YTggICByY3g6IGZmZmY4MzAzZmFhZjI2MTANCihYRU4pIFsyMDE0LTExLTE4IDE0OjUz
OjM3LjQzNl0gcmR4OiAwMjAwMjAwMjAwMjAwMjAwICAgcnNpOiAwMDAwMDAwMDAwMDAwMDA2
ICAgcmRpOiAwMDAwMDAwMDZlZjNmMTIzDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy40
NjNdIHJicDogZmZmZjgzMDU0ZWYyN2JlOCAgIHJzcDogZmZmZjgzMDU0ZWYyN2JkOCAgIHI4
OiAgZmZmZjgzMDNmYWFmMjAxMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzcuNDkwXSBy
OTogIDAwMDAwMDAwMDAwMDAwMmYgICByMTA6IDAwMDAwMDAwMDAwMDAxMzIgICByMTE6IDAw
MDAwMDAwMDAwMDAwMDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3LjUxN10gcjEyOiBm
ZmZmODMwNTEyNWQ2MDAwICAgcjEzOiAwMDAwMDAwMDAwMDAwMDAwICAgcjE0OiBmZmZmODMw
M2ZhYWYyNTgwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy41NDNdIHIxNTogMDAwMDAw
MDAwMDAwMDAyZiAgIGNyMDogMDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAw
MDZmMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzcuNTcwXSBjcjM6IDAwMDAwMDA1NDQ4
YzAwMDAgICBjcjI6IGZmZmZmZmZmZmY2MDA0MDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjUz
OjM3LjU5MV0gZHM6IDAwMmIgICBlczogMDAyYiAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBz
czogZTAxMCAgIGNzOiBlMDA4DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy42MTZdIFhl
biBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmODMwNTRlZjI3YmQ4Og0KKFhFTikgWzIwMTQt
MTEtMTggMTQ6NTM6MzcuNjM2XSAgICBmZmZmODMwNTRlZjI3YmU4IGZmZmY4MzAzZmFhZjI2
YzAgZmZmZjgzMDU0ZWYyN2M3OCBmZmZmODJkMDgwMTcyMDYwDQooWEVOKSBbMjAxNC0xMS0x
OCAxNDo1MzozNy42NjNdICAgIDAwMDAwMDAwMDAwMDAwMjAgZmZmZjgzMDU0ZWYyN2NmNiAw
MDAwMDAwMDAwMDAwMDQ2IGZmZmY4MzA1NGVmMjdjNzANCihYRU4pIFsyMDE0LTExLTE4IDE0
OjUzOjM3LjY5MF0gICAgZmZmZjgyZDAwMDAwMDAwMCBmZmZmODMwNTVkMDAyZjI0IDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMmY0ZWYyN2M0MA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6
MzcuNzE3XSAgICBmZmZmODMwNTRlZjI3YzQ4IGZmZmY4MmQwODAxNDQzNGYgZmZmZjgzMDU0
ZWYyN2M2MCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy43
NDRdICAgIGZmZmY4MmQwODAyNWVmZGMgMDAwMDAwMDAwMDAwMDIwMCBmZmZmODMwNTRlZjI3
ZDc4IDAwMDAwMDAwMDAwMDAwMDMNCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3Ljc3MV0g
ICAgMDAwMDdjZmFiMTBkODM1NyBmZmZmODJkMDgwMjMzMTIyIDAwMDAwMDAwMDAwMDAwMDMg
ZmZmZjgzMDU0ZWYyN2Q3OA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzcuNzk4XSAgICAw
MDAwMDAwMDAwMDAwMjAwIGZmZmY4MmQwODAyNWVmZGMgZmZmZjgzMDU0ZWYyN2Q2MCAwMDAw
MDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy44MjVdICAgIDAwMDAw
MDAwMDAwMDAwMDMgMDAwMDAwMDAwMDAwMDEzMiAwMDAwMDAwMDAwMDAwMDAzIGZmZmY4MzA1
NGVmODAwMDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3Ljg1Ml0gICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzA1NGVmMjAwMDAgMDAwMDAwMDAwMDAw
MDAwYQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzcuODc5XSAgICBmZmZmODJkMDgwMjk2
NmMwIDAwMDAwMGQxMDAwMDAwMDAgZmZmZjgyZDA4MDE0MzliYSAwMDAwMDAwMDAwMDBlMDA4
DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozNy45MDZdICAgIDAwMDAwMDAwMDAwMDAyMDYg
ZmZmZjgzMDU0ZWYyN2QzMCAwMDAwMDAwMDAwMDBlMDEwIGZmZmY4MzA1NGVmMjdkNjANCihY
RU4pIFsyMDE0LTExLTE4IDE0OjUzOjM3LjkzM10gICAgZmZmZjgyZDA4MDMwOTYxZSBmZmZm
ODMwNTRlZjJlMzc4IGZmZmY4MzA1NGVmMjdlMTAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6NTM6MzcuOTYwXSAgICBmZmZmODJkMDgwMjVmMzdlIGZmZmY4MzA1
NGVmMjdkYzAgZmZmZjgyZDA4MDE0M2VkYSBmZmZmODJkMDgwMjk2N2EwDQooWEVOKSBbMjAx
NC0xMS0xOCAxNDo1MzozNy45ODddICAgIDAwMDAwMDAwMDAwMDAwMjggZmZmZjgzMDU0ZWYy
N2RkMCBmZmZmODMwNTRlZjI3ZDkwIGZmZmY4MzA1NGVmMjdkYTANCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjUzOjM4LjAxNF0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODMwM2ZhYWYyNWE4
IGZmZmY4MzA1NGVmMmUzZTAgZmZmZjgzMDU0ZWYyZTNlMA0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6NTM6MzguMDQxXSAgICAwMDAwMDE3ODVkYjc1ODAwIGZmZmY4MzA1NGVmMjdlYjAgZmZm
ZjgyZDA4MDE0OTVjMCBmZmZmODJkMDgwMjMzMTIyDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1
MzozOC4wNjhdICAgIGZmZmY4MzA1NGVmMmUzNzggZmZmZjgzMDU0ZWYyN2UwMCBmZmZmODMw
NTRlZjJlNGUwIGZmZmY4MzA1NGVmMmU0MDANCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4
LjA5NV0gICAgMDAwMDAwMDMwMDAwMDAwMCBmZmZmODMwNTEyNWQ2MGI4IGZmZmY4MzA1NGVm
MjdlNzAgZmZmZjgzMDU0ZWYyZTNlMA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguMTIy
XSAgICBmZmZmODMwNTRlZjJlM2UwIGZmZmY4MzAzZmFhZjI1YTggZmZmZjgzMDU0ZWYyZTNl
MCBmZmZmODMwNTRlZjJlM2UwDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozOC4xNTBdICAg
IGZmZmY4MzA1NGVmMmUzNzggMDEwMDEwMDEwMDEwMDEwMCAwMjAwMjAwMjAwMjAwMjAwIGZm
ZmY4MzA1NGVmMmUzNzgNCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4LjE3N10gWGVuIGNh
bGwgdHJhY2U6DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozOC4xODldICAgIFs8ZmZmZjgy
ZDA4MDE0YTRkZT5dIGh2bV9kb19JUlFfZHBjaSsweGY0LzB4MTMxDQooWEVOKSBbMjAxNC0x
MS0xOCAxNDo1MzozOC4yMTFdICAgIFs8ZmZmZjgyZDA4MDE3MjA2MD5dIGRvX0lSUSsweDQ5
Yy8weDYyNA0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguMjMxXSAgICBbPGZmZmY4MmQw
ODAyMzMxMjI+XSBjb21tb25faW50ZXJydXB0KzB4NjIvMHg3MA0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6NTM6MzguMjUzXSAgICBbPGZmZmY4MmQwODAxNDM5YmE+XSB2cHJpbnRrX2NvbW1v
bisweDEzMS8weDEzZQ0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguMjc1XSAgICBbPGZm
ZmY4MmQwODAxNDNlZGE+XSBwcmludGsrMHg0Ni8weDQ4DQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo1MzozOC4yOTRdICAgIFs8ZmZmZjgyZDA4MDE0OTVjMD5dIGRwY2lfc29mdGlycSsweDE5
OS8weDNlMg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguMzE1XSAgICBbPGZmZmY4MmQw
ODAxMmJlMzE+XSBfX2RvX3NvZnRpcnErMHg4MS8weDhjDQooWEVOKSBbMjAxNC0xMS0xOCAx
NDo1MzozOC4zMzZdICAgIFs8ZmZmZjgyZDA4MDEyYmU4OT5dIGRvX3NvZnRpcnErMHgxMy8w
eDE1DQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozOC4zNTZdICAgIFs8ZmZmZjgyZDA4MDE2
MzNlNT5dIGlkbGVfbG9vcCsweDVlLzB4NmUNCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4
LjM3Nl0gDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozOC4zODVdIA0KKFhFTikgWzIwMTQt
MTEtMTggMTQ6NTM6MzguMzk0XSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqDQooWEVOKSBbMjAxNC0xMS0xOCAxNDo1MzozOC40MTNdIFBhbmljIG9uIENQVSA0
Og0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguNDI2XSBHRU5FUkFMIFBST1RFQ1RJT04g
RkFVTFQNCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4LjQ0MV0gW2Vycm9yX2NvZGU9MDAw
MF0NCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4LjQ1NF0gKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKg0KKFhFTikgWzIwMTQtMTEtMTggMTQ6NTM6MzguNDcz
XSANCihYRU4pIFsyMDE0LTExLTE4IDE0OjUzOjM4LjQ4Ml0gUmVib290IGluIGZpdmUgc2Vj
b25kcy4uLg0K
------------0191A1230144FE1ED
Content-Type: text/plain;
 name="xl-dmesg-defined-nousb.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg-defined-nousb.txt"

ZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgCihYRU4pICAwMCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAwMSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDMwCihYRU4pICAwMiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwCihYRU4pICAwMyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4CihYRU4pICAwNCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYxCihYRU4pICAwNSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwCihYRU4pICAwNiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4CihYRU4pICAwNyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDUwCihYRU4pICAwOCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4CihYRU4pICAwOSAwMDEgMDEgIDEg
ICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAwICAgIDAwCihYRU4pICAwYSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDY4CihYRU4pICAwYiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwCihYRU4pICAwYyAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4CihYRU4pICAwZCAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDg4CihYRU4pICAwZSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwCihYRU4pICAwZiAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDk4CihYRU4pICAxMCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMiAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxMyAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNiAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pICAxNyAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwCihYRU4pIElPIEFQSUMgIzcuLi4u
Li4KKFhFTikgLi4uLiByZWdpc3RlciAjMDA6IDA3MDAwMDAwCihYRU4pIC4uLi4uLi4gICAg
OiBwaHlzaWNhbCBBUElDIGlkOiAwNwooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlw
ZTogMAooWEVOKSAuLi4uLi4uICAgIDogTFRTICAgICAgICAgIDogMAooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMTogMDAxRjgwMjEKKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rp
b24gZW50cmllczogMDAxRgooWEVOKSAuLi4uLi4uICAgICA6IFBSUSBpbXBsZW1lbnRlZDog
MQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMjogMDAwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAgOiBhcmJpdHJhdGlv
bjogMDAKKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6CihYRU4pICBOUiBMb2cg
UGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgCihYRU4pICAw
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
NyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
OSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
YyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
ZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
OSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
YyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
ZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pIFVz
aW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZwooWEVOKSBJUlEgdG8gcGluIG1hcHBpbmdzOgoo
WEVOKSBJUlEyNDAgLT4gMDoyCihYRU4pIElSUTQ4IC0+IDA6MQooWEVOKSBJUlE1NiAtPiAw
OjMKKFhFTikgSVJRMjQxIC0+IDA6NAooWEVOKSBJUlE2NCAtPiAwOjUKKFhFTikgSVJRNzIg
LT4gMDo2CihYRU4pIElSUTgwIC0+IDA6NwooWEVOKSBJUlE4OCAtPiAwOjgKKFhFTikgSVJR
OTYgLT4gMDo5CihYRU4pIElSUTEwNCAtPiAwOjEwCihYRU4pIElSUTExMiAtPiAwOjExCihY
RU4pIElSUTEyMCAtPiAwOjEyCihYRU4pIElSUTEzNiAtPiAwOjEzCihYRU4pIElSUTE0NCAt
PiAwOjE0CihYRU4pIElSUTE1MiAtPiAwOjE1CihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLiBkb25lLgooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGlu
dGVycnVwdHMuCihYRU4pIGNhbGlicmF0aW5nIEFQSUMgdGltZXIgLi4uCihYRU4pIC4uLi4u
IENQVSBjbG9jayBzcGVlZCBpcyAzMjAwLjE5OTYgTUh6LgooWEVOKSAuLi4uLiBob3N0IGJ1
cyBjbG9jayBzcGVlZCBpcyAyMDAuMDEyNCBNSHouCihYRU4pIC4uLi4uIGJ1c19zY2FsZSA9
IDB4Y2NkNwooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy40NDNdIFBsYXRmb3JtIHRpbWVy
IGlzIDE0LjMxOE1IeiBIUEVUCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI3LjQ2NF0gQWxs
b2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjI3LjQ3MF0gSFZNOiBBU0lEcyBlbmFibGVkLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToy
Ny40NzZdIFNWTTogU3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOgooWEVOKSBbMjAxNC0x
MS0xOCAxMzowMToyNy40ODJdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQooWEVOKSBb
MjAxNC0xMS0xOCAxMzowMToyNy40ODhdICAtIExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBW
aXJ0dWFsaXNhdGlvbgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy40OTRdICAtIE5leHQt
UklQIFNhdmVkIG9uICNWTUVYSVQKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjcuNTAwXSAg
LSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVyCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI3LjUw
Nl0gSFZNOiBTVk0gZW5hYmxlZAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy41MTNdIEhW
TTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVApIGRldGVjdGVkCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjI3LjUxOV0gSFZNOiBIQVAgcGFnZSBzaXplczogNGtCLCAyTUIsIDFH
QgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy41MjZdIEhWTTogUFZIIG1vZGUgbm90IHN1
cHBvcnRlZCBvbiB0aGlzIHBsYXRmb3JtCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI3LjU1
Ml0gbWFza2VkIEV4dElOVCBvbiBDUFUjMQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy41
NzldIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzIKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6Mjcu
NjA1XSBtYXNrZWQgRXh0SU5UIG9uIENQVSMzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI3
LjYzMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjNAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToy
Ny42NTldIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzUKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6
MjcuNjY1XSBCcm91Z2h0IHVwIDYgQ1BVcwooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy42
NzVdIEFNRC1WaTogRmFpbGVkIHRvIHNldHVwIEhQRVQgTVNJIHJlbWFwcGluZy4gV3Jvbmcg
SFBFVC4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjcuNjgyXSBBTUQtVmk6IEZhaWxlZCB0
byBzZXR1cCBIUEVUIE1TSSByZW1hcHBpbmcuIFdyb25nIEhQRVQuCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjI3LjY4OF0gQU1ELVZpOiBGYWlsZWQgdG8gc2V0dXAgSFBFVCBNU0kgcmVt
YXBwaW5nLiBXcm9uZyBIUEVULgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy42OTVdIEhQ
RVQ6IDMgdGltZXJzIHVzYWJsZSBmb3IgYnJvYWRjYXN0ICgzIHRvdGFsKQooWEVOKSBbMjAx
NC0xMS0xOCAxMzowMToyNy43MjJdIEFDUEkgc2xlZXAgbW9kZXM6IFMzCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjI3LjcyOV0gTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVz
dCBwb2xsaW5nIGZyZXF1ZW5jeQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy43MzZdIG1j
aGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4KKFhFTikg
WzIwMTQtMTEtMTggMTM6MDE6MjcuNzQzXSBYZW5vcHJvZmlsZTogRmFpbGVkIHRvIHNldHVw
IElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmCihYRU4pIFsyMDE0LTExLTE4
IDEzOjAxOjI3Ljc1MF0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjI3LjkxOF0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAw
MDAwIG1lbXN6PTB4MTA2NDAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy45MjZdIGVs
Zl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MjIwMDAwMCBtZW1zej0weDEwNjAwMAoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy45MzNdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6
IHBhZGRyPTB4MjMwNjAwMCBtZW1zej0weDE0MjgwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjI3Ljk0MF0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgyMzFiMDAwIG1lbXN6
PTB4MTE0MDAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyNy45NDhdIGVsZl9wYXJzZV9i
aW5hcnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MzQ1YjAwMAooWEVOKSBbMjAxNC0xMS0x
OCAxMzowMToyNy45NTVdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgi
CihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI3Ljk2M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBH
VUVTVF9WRVJTSU9OID0gIjIuNiIKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjcuOTcwXSBl
bGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjI3Ljk3OF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAw
eGZmZmZmZmZmODAwMDAwMDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjcuOTg1XSBlbGZf
eGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgyMzFiMWYwCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjI3Ljk5M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBIWVBFUkNBTExfUEFH
RSA9IDB4ZmZmZmZmZmY4MTAwMTAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4wMDFd
IGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVz
fHBhZV9wZ2Rpcl9hYm92ZV80Z2J8d3JpdGFibGVfZGVzY3JpcHRvcl90YWJsZXN8YXV0b190
cmFuc2xhdGVkX3BoeXNtYXB8c3VwZXJ2aXNvcl9tb2RlX2tlcm5lbCIKKFhFTikgWzIwMTQt
MTEtMTggMTM6MDE6MjguMDE3XSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVUFBPUlRFRF9GRUFU
VVJFUyA9IDB4OTBkCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjAyNV0gZWxmX3hlbl9w
YXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4
LjAzM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKKFhFTikgWzIw
MTQtMTEtMTggMTM6MDE6MjguMDQyXSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25vd24geGVu
IGVsZiBub3RlICgweGQpCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjA1MF0gZWxmX3hl
bl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQooWEVOKSBbMjAxNC0xMS0xOCAx
MzowMToyOC4wNTldIGVsZl94ZW5fcGFyc2Vfbm90ZTogTU9EX1NUQVJUX1BGTiA9IDB4MQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4wNjhdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZf
U1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjI4LjA3N10gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDAKKFhFTikg
WzIwMTQtMTEtMTggMTM6MDE6MjguMDg2XSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRk
cmVzc2VzOgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4wOTVdICAgICB2aXJ0X2Jhc2Ug
ICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4
LjEwNF0gICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKKFhFTikgWzIwMTQtMTEtMTggMTM6
MDE6MjguMTE0XSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMAoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4xMjNdICAgICB2aXJ0X2tzdGFydCAgICAgID0g
MHhmZmZmZmZmZjgxMDAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjEzM10gICAg
IHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZmZmZmODM0NWIwMDAKKFhFTikgWzIwMTQtMTEt
MTggMTM6MDE6MjguMTQzXSAgICAgdmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MjMx
YjFmMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4xNTNdICAgICBwMm1fYmFzZSAgICAg
ICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjE2
M10gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIKKFhFTikgWzIwMTQtMTEt
MTggMTM6MDE6MjguMTczXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRy
IDB4MTAwMDAwMCAtPiAweDM0NWIwMDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjguMTgz
XSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6CihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjI4LjE5M10gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDA1NDgwMDAwMDAtPjAwMDAwMDA1NGMw
MDAwMDAgKDM3MjkzOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pIFsyMDE0LTExLTE4
IDEzOjAxOjI4LjIwNF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDA1NWYwY2EwMDAtPjAwMDAw
MDA1NWZmZmZhMDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjguMjE1XSBWSVJUVUFMIE1F
TU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjguMjI2XSAgTG9h
ZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MzQ1YjAwMAooWEVOKSBb
MjAxNC0xMS0xOCAxMzowMToyOC4yMzZdICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMDAwMDAw
MDAwLT4wMDAwMDAwMDAwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjI0N10g
IFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODM0NWIwMDAtPmZmZmZmZmZmODM3NWIwMDAKKFhF
TikgWzIwMTQtMTEtMTggMTM6MDE6MjguMjU4XSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4
Mzc1YjAwMC0+ZmZmZmZmZmY4Mzc1YjRiNAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4y
NjldICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzNzVjMDAwLT5mZmZmZmZmZjgzNzdiMDAw
CihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjI4MF0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZm
ZmZmODM3N2IwMDAtPmZmZmZmZmZmODM3N2MwMDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6
MjguMjkxXSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4Mzgw
MDAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4zMDJdICBFTlRSWSBBRERSRVNTOiBm
ZmZmZmZmZjgyMzFiMWYwCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjMxM10gRG9tMCBo
YXMgbWF4aW11bSA2IFZDUFVzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI4LjMyNF0gZWxm
X2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZm
ZmY4MjA2NDAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOC4zNDJdIGVsZl9sb2FkX2Jp
bmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MjIwMDAwMCAtPiAweGZmZmZmZmZmODIzMDYw
MDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjguMzU0XSBlbGZfbG9hZF9iaW5hcnk6IHBo
ZHIgMiBhdCAweGZmZmZmZmZmODIzMDYwMDAgLT4gMHhmZmZmZmZmZjgyMzFhMjgwCihYRU4p
IFsyMDE0LTExLTE4IDEzOjAxOjI4LjM2NV0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDMgYXQg
MHhmZmZmZmZmZjgyMzFiMDAwIC0+IDB4ZmZmZmZmZmY4MjQyMzAwMAooWEVOKSBbMjAxNC0x
MS0xOCAxMzowMToyOC43NzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5
LjUxOV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMCwgdHlw
ZSA9IDB4Niwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuNTMxXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDIsIHR5cGUgPSAweDcsIHJvb3QgdGFi
bGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjI5LjU0M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHgxMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6
MjkuNTU2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDE4
LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOS41NjhdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MjgsIHR5cGUgPSAweDIsIHJv
b3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5LjU4MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgzMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRl
ZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDE6MjkuNTk0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDQ4LCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOS42MDddIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NTAsIHR5cGUgPSAw
eDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5LjYyMF0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1OCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9
IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQt
MTEtMTggMTM6MDE6MjkuNjMzXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDYwLCB0eXBlID0gMHgyLCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMzowMToyOS42
NDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NjgsIHR5
cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5LjY2MF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg4OCwgdHlwZSA9IDB4Nywgcm9vdCB0
YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikg
WzIwMTQtMTEtMTggMTM6MDE6MjkuNjc0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDkwLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMzow
MToyOS42ODhdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
OTIsIHR5cGUgPSAweDcsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5LjcwMl0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgdHlwZSA9IDB4Nywg
cm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMK
KFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuNzE2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDlhLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1
NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0x
OCAxMzowMToyOS43MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4YTAsIHR5cGUgPSAweDcsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5Ljc0NV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMiwgdHlwZSA9
IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuNzYwXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEzLCB0eXBlID0gMHg3LCByb290IHRhYmxl
ID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAx
NC0xMS0xOCAxMzowMToyOS43NzVdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4YTQsIHR5cGUgPSAweDUsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5
Ljc5MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhNSwg
dHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuODA1XSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE4LCB0eXBlID0gMHgyLCByb290
IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVO
KSBbMjAxNC0xMS0xOCAxMzowMToyOS44MjBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4YjAsIHR5cGUgPSAweDcsIHJvb3QgdGFibGUgPSAweDU0ZWVk
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjI5LjgzNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHhiMiwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuODUxXSBBTUQt
Vmk6IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTguMAooWEVOKSBbMjAxNC0xMS0x
OCAxMzowMToyOS44NjddIEFNRC1WaTogU2tpcHBpbmcgaG9zdCBicmlkZ2UgMDAwMDowMDox
OC4xCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5Ljg4Ml0gQU1ELVZpOiBTa2lwcGluZyBo
b3N0IGJyaWRnZSAwMDAwOjAwOjE4LjIKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MjkuODk3
XSBBTUQtVmk6IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTguMwooWEVOKSBbMjAx
NC0xMS0xOCAxMzowMToyOS45MTJdIEFNRC1WaTogU2tpcHBpbmcgaG9zdCBicmlkZ2UgMDAw
MDowMDoxOC40CihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5LjkyN10gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDAsIHR5cGUgPSAweDEsIHJvb3Qg
dGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4p
IFsyMDE0LTExLTE4IDEzOjAxOjI5Ljk0M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg1MDAsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVk
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjI5Ljk1OV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHg2MDgsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5Ljk3NV0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg2MTAsIHR5cGUgPSAw
eDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjI5Ljk5MV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg3MDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUg
PSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjMwLjAwN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg4MDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMw
LjAyM10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDAs
IHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjA0MF0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDEsIHR5cGUgPSAweDEsIHJv
b3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjA1N10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHhhMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0
ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4
IDEzOjAxOjMwLjA3NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHhiMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjA5MV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhjMDAsIHR5cGUg
PSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjEwOF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhkMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFi
bGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjMwLjEyNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHhlMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjMwLjE0NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhl
MDEsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjE2MV0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhmMDAsIHR5cGUgPSAweDEs
IHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
CihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjE3OV0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHhmMDEsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAw
eDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjMwLjIwMl0gU2NydWJiaW5nIEZyZWUgUkFNIG9uIDEgbm9kZXMgdXNpbmcg
NiBDUFVzCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjMwLjMxM10gLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi5kb25lLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozMy40MDZdIElu
aXRpYWwgbG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMTozMy40MjNdIFN0ZC4gTG9nbGV2ZWw6IEFsbAooWEVO
KSBbMjAxNC0xMS0xOCAxMzowMTozMy40NDFdIEd1ZXN0IExvZ2xldmVsOiBBbGwKKFhFTikg
WzIwMTQtMTEtMTggMTM6MDE6MzMuNDU5XSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29u
c29sZS4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MzMuNTYxXSAqKiogU2VyaWFsIGlucHV0
IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRv
IFhlbikKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MzMuNTYyXSBGcmVlZCAyODRrQiBpbml0
IG1lbW9yeS4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MzMuNzE0XSBJT0FQSUNbMF06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNi05IC0+IDB4NjAgLT4gSVJRIDkgTW9kZToxIEFjdGl2
ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozMy43MzZdIHRyYXBzLmM6MjU3OTpkMHYw
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAw
MDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjA2NV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4wCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjA2NV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yCihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjM0LjA2Nl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2Nl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDow
My4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2Nl0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDowNS4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2N10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDowNi4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2N10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDowOS4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2N10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDowYS4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0
LjA2OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYi4wCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjA2OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYy4wCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjA2OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowZC4wCihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjM0LjA2OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMS4wCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
Mi4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA2OV0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxMi4yCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3MF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxMy4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3MF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxMy4yCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3MF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0
LjA3MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4yCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjA3MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4zCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjA3MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC40CihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjM0LjA3MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41CihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3Ml0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
NS4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3Ml0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxNi4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3Ml0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxNi4yCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3M10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxOC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3M10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0
LjA3M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjA3M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4zCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjA3NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40CihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjM0LjA3NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowZjowMC4wCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowZjow
MC4xCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3OV0gUENJIGFkZCBkZXZpY2UgMDAw
MDowZTowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA3OV0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowZTowMC4xCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA4NV0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowZDowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjA5Ml0g
UENJIGFkZCBkZXZpY2UgMDAwMDowYzowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0
LjA5OV0gUENJIGFkZCBkZXZpY2UgMDAwMDowYjowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjEwNl0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4wCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjExM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4wCihYRU4pIFsy
MDE0LTExLTE4IDEzOjAxOjM0LjExM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4xCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjExOV0gUENJIGFkZCBkZXZpY2UgMDAwMDowNTow
MC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjEyOV0gUENJIGFkZCBkZXZpY2UgMDAw
MDowNjowMS4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjEzMF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowNjowMi4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjEzMF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowODowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjE0MF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowNzowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0
LjE0MF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4wCihYRU4pIFsyMDE0LTExLTE4IDEz
OjAxOjM0LjE1MF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMzowNi4wCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAxOjM0LjE1MV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYt
MTMgLT4gMHg4OCAtPiBJUlEgMTMgTW9kZTowIEFjdGl2ZTowKQooWEVOKSBbMjAxNC0xMS0x
OCAxMzowMTozNC4xNjVdIFBDSTogVXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAw
MC1mZgooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozNC4xNTldIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTggLT4gMHg1OCAtPiBJUlEgOCBNb2RlOjAgQWN0aXZlOjAp
CihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM0LjE3Ml0gSU9BUElDWzBdOiBTZXQgUENJIHJv
dXRpbmcgZW50cnkgKDYtMTggLT4gMHhiOCAtPiBJUlEgMTggTW9kZToxIEFjdGl2ZToxKQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMTozNC4yNDhdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg2LTE3IC0+IDB4YzAgLT4gSVJRIDE3IE1vZGU6MSBBY3RpdmU6MSkKKFhF
TikgWzIwMTQtMTEtMTggMTM6MDE6MzQuNDc5XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNy0yOSAtPiAweGM4IC0+IElSUSA1MyBNb2RlOjEgQWN0aXZlOjEpCihYRU4p
IFsyMDE0LTExLTE4IDEzOjAxOjM0LjQ3OV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDctMjQgLT4gMHhkMCAtPiBJUlEgNDggTW9kZToxIEFjdGl2ZToxKQooWEVOKSBb
MjAxNC0xMS0xOCAxMzowMTozNC40NzldIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTMwIC0+IDB4ZDggLT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIw
MTQtMTEtMTggMTM6MDE6MzQuNDc5XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy0xMiAtPiAweDIxIC0+IElSUSAzNiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0
LTExLTE4IDEzOjAxOjM0LjQ3OV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctMTMgLT4gMHgyOSAtPiBJUlEgMzcgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0x
MS0xOCAxMzowMTozNC40NzldIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTE2IC0+IDB4MzEgLT4gSVJRIDQwIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEt
MTggMTM6MDE6MzQuNTQ2XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0y
OCAtPiAweDM5IC0+IElSUSA1MiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4
IDEzOjAxOjM0LjU0OF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTYg
LT4gMHg4OSAtPiBJUlEgMTYgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAx
MzowMTozNC41NDhdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE0IC0+
IDB4YTkgLT4gSVJRIDM4IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTggMTM6
MDE6MzQuNTk3XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0yMiAtPiAw
eGI5IC0+IElSUSAyMiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDEzOjAx
OjM2LjY2OV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOSAtPiAweGMx
IC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM2
LjY5NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOCAtPiAweGM5IC0+
IElSUSAzMiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDEzOjAxOjM2Ljcy
MV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjMgLT4gMHhkMSAtPiBJ
UlEgNDcgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozOC44MDFd
IElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTUgLT4gMHhkOSAtPiBJUlEg
MjkgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozOC44NDVdIElP
QVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTQgLT4gMHgyMiAtPiBJUlEgMjgg
TW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozOC45NzldIElPQVBJ
Q1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE5IC0+IDB4MmEgLT4gSVJRIDE5IE1v
ZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MzguOTg3XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMTozOS4xNDJdIElPQVBJQ1sxXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg3LTIyIC0+IDB4NzIgLT4gSVJRIDQ2IE1vZGU6MSBBY3RpdmU6MSkK
KFhFTikgWzIwMTQtMTEtMTggMTM6MDE6MzkuMTc4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy0yNyAtPiAweDhhIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpCihY
RU4pIFsyMDE0LTExLTE4IDEzOjAxOjM5Ljc3Nl0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDctMSAtPiAweDlhIC0+IElSUSAyNSBNb2RlOjEgQWN0aXZlOjEpCihYRU4p
IFsyMDE0LTExLTE4IDEzOjAxOjQ4Ljc0MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDE6NTguNzQwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMjowOC43NDBd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjAyOjE4Ljc0MV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6MDI6MjguNzQxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzowMjozOC43NDFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjAyOjQ4Ljc0
MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDI6NTguNzQyXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowMzowOC43NDJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjAzOjE4Ljc0Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDM6Mjgu
NzQyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowMzozOC43NDNdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjAzOjQ4Ljc0M10gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MDM6NTguNzQzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowNDow
OC43NDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjA0OjE4Ljc0M10gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDQ6MjguNzQ0XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzowNDozOC43NDRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjA0
OjQ4Ljc0NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDQ6NTguNzQ0XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowNTowOC43NDVdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjA1OjE4Ljc0NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
MDU6MjguNzQ1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowNTozOC43NDVdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjA1OjQ4Ljc0NV0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6MDU6NTguNzQ2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MzowNjowOC43NDZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjA2OjE4Ljc0Nl0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDY6MjguNzQ2XSAtLU1BUkstLQooZDEp
IFsyMDE0LTExLTE4IDEzOjA2OjM4LjMwMF0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNh
bCBtZW1vcnkKKGQxKSBbMjAxNC0xMS0xOCAxMzowNjozOC4zMDBdIGFib3V0IHRvIGdldCBz
dGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDEzOjA2OjM4LjU2Nl0gdHJhcHMuYzoyNTc5
OmQxdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgw
MDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEt
MTggMTM6MDY6MzguNzQ3XSAtLU1BUkstLQooZDIpIFsyMDE0LTExLTE4IDEzOjA2OjQ0LjE2
NV0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQyKSBbMjAxNC0xMS0x
OCAxMzowNjo0NC4xNjZdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjA2OjQ0LjI0N10gdHJhcHMuYzoyNTc5OmQydjAgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAw
MDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDY6NDguNzQ3XSAtLU1BUkst
LQooZDMpIFsyMDE0LTExLTE4IDEzOjA2OjQ5LjkyMF0gbWFwcGluZyBrZXJuZWwgaW50byBw
aHlzaWNhbCBtZW1vcnkKKGQzKSBbMjAxNC0xMS0xOCAxMzowNjo0OS45MjBdIGFib3V0IHRv
IGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDEzOjA2OjUwLjAxMl0gdHJhcHMu
YzoyNTc5OmQzdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKGQ0KSBbMjAx
NC0xMS0xOCAxMzowNjo1Ni40MjNdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVt
b3J5CihkNCkgWzIwMTQtMTEtMTggMTM6MDY6NTYuNDIzXSBhYm91dCB0byBnZXQgc3RhcnRl
ZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowNjo1Ni41MDJdIHRyYXBzLmM6MjU3OTpkNHYw
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAw
MDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE4IDEz
OjA2OjU4Ljc0N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDY6NTkuNjYwXSBn
cmFudF90YWJsZS5jOjMwNTpkMHYyIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDIgZnJh
bWVzCihkNSkgWzIwMTQtMTEtMTggMTM6MDc6MDIuNDAxXSBtYXBwaW5nIGtlcm5lbCBpbnRv
IHBoeXNpY2FsIG1lbW9yeQooZDUpIFsyMDE0LTExLTE4IDEzOjA3OjAyLjQwMV0gYWJvdXQg
dG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDc6MDIuNDkwXSB0cmFw
cy5jOjI1Nzk6ZDV2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQg
ZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBb
MjAxNC0xMS0xOCAxMzowNzowMy44MTddIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVh
c2VkIG1hcHRyYWNrIHNpemUgdG8gMyBmcmFtZXMKKGQ2KSBbMjAxNC0xMS0xOCAxMzowNzow
OC4zNzddIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkNikgWzIwMTQt
MTEtMTggMTM6MDc6MDguMzc3XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAx
NC0xMS0xOCAxMzowNzowOC40OTFdIHRyYXBzLmM6MjU3OTpkNnYwIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAw
eDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE4IDEzOjA3OjA4Ljc0N10gLS1N
QVJLLS0KKGQ3KSBbMjAxNC0xMS0xOCAxMzowNzoxNC4yNjNdIG1hcHBpbmcga2VybmVsIGlu
dG8gcGh5c2ljYWwgbWVtb3J5CihkNykgWzIwMTQtMTEtMTggMTM6MDc6MTQuMjYzXSBhYm91
dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowNzoxNC4zNDJdIHRy
YXBzLmM6MjU3OTpkN3YwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4p
IFsyMDE0LTExLTE4IDEzOjA3OjE4Ljc0N10gLS1NQVJLLS0KKGQ4KSBbMjAxNC0xMS0xOCAx
MzowNzoyMC4wODRdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkOCkg
WzIwMTQtMTEtMTggMTM6MDc6MjAuMDg0XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVO
KSBbMjAxNC0xMS0xOCAxMzowNzoyMC4xNjJdIHRyYXBzLmM6MjU3OTpkOHYwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAw
MCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihkOSkgWzIwMTQtMTEtMTggMTM6MDc6MjYuMTU1
XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDkpIFsyMDE0LTExLTE4
IDEzOjA3OjI2LjE1NV0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEt
MTggMTM6MDc6MjYuMjUwXSB0cmFwcy5jOjI1Nzk6ZDl2MCBEb21haW4gYXR0ZW1wdGVkIFdS
TVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAw
MDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowNzoyOC43NDhdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjA3OjMwLjAyOV0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2
MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA0IGZyYW1lcwooZDEwKSBbMjAxNC0xMS0x
OCAxMzowNzozMi4wNjBdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5Cihk
MTApIFsyMDE0LTExLTE4IDEzOjA3OjMyLjA2MF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4K
KFhFTikgWzIwMTQtMTEtMTggMTM6MDc6MzIuMTQ0XSB0cmFwcy5jOjI1Nzk6ZDEwdjAgRG9t
YWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAw
MDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDc6
MzguNzQ4XSAtLU1BUkstLQooZDExKSBbMjAxNC0xMS0xOCAxMzowNzozOC43OTZdIG1hcHBp
bmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTEpIFsyMDE0LTExLTE4IDEzOjA3
OjM4Ljc5Nl0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTM6
MDc6MzguODg5XSB0cmFwcy5jOjI1Nzk6ZDExdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAw
MDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAw
MDAwZmZmZi4KKGQxMikgWzIwMTQtMTEtMTggMTM6MDc6NDQuNzI3XSBtYXBwaW5nIGtlcm5l
bCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDEyKSBbMjAxNC0xMS0xOCAxMzowNzo0NC43Mjhd
IGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDEzOjA3OjQ0Ljgy
M10gdHJhcHMuYzoyNTc5OmQxMnYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYu
CihYRU4pIFsyMDE0LTExLTE4IDEzOjA3OjQ1LjY5N10gZ3JhbnRfdGFibGUuYzozMDU6ZDB2
MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA1IGZyYW1lcwooWEVOKSBbMjAxNC0xMS0x
OCAxMzowNzo0NS43MTRdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRy
YWNrIHNpemUgdG8gNiBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDc6NDguNzQ4XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowNzo1MC44MDRdIEFNRC1WaTogRGlzYWJs
ZTogZGV2aWNlIGlkID0gMHhhNCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4p
IFsyMDE0LTExLTE4IDEzOjA3OjUwLjgwNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHhhNCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTE3NWRj
MDAwLCBkb21haW4gPSAxMywgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEz
OjA3OjUwLjgwNF0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowMzowNi4wIGZyb20gZG9tMCB0
byBkb20xMwooZDEzKSBbMjAxNC0xMS0xOCAxMzowNzo1MC44MTFdIG1hcHBpbmcga2VybmVs
IGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTMpIFsyMDE0LTExLTE4IDEzOjA3OjUwLjgxMV0g
YWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTM6MDc6NTEuMDU1
XSB0cmFwcy5jOjI1Nzk6ZDEzdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4K
KGQxNCkgWzIwMTQtMTEtMTggMTM6MDc6NTcuMDAyXSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBo
eXNpY2FsIG1lbW9yeQooZDE0KSBbMjAxNC0xMS0xOCAxMzowNzo1Ny4wMDJdIGFib3V0IHRv
IGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDEzOjA3OjU3LjA5OF0gdHJhcHMu
YzoyNTc5OmQxNHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsy
MDE0LTExLTE4IDEzOjA3OjU4LjE4MF0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MiBJbmNyZWFz
ZWQgbWFwdHJhY2sgc2l6ZSB0byA3IGZyYW1lcwooWEVOKSBbMjAxNC0xMS0xOCAxMzowNzo1
OC43NDhdIC0tTUFSSy0tCihkMTUpIFsyMDE0LTExLTE4IDEzOjA4OjAzLjUwOF0gbWFwcGlu
ZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQxNSkgWzIwMTQtMTEtMTggMTM6MDg6
MDMuNTA4XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMzow
ODowMy42MDddIHRyYXBzLmM6MjU3OTpkMTV2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAw
MDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAw
MDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowODowOC43NDldIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjA4OjEzLjU0OF0gaW8uYzo1NTI6IGQxNjogYmluZDogbV9nc2k9
MzcgZ19nc2k9MzYgZGV2PTAwLjAwLjUgaW50eD0wIGZmZmY4MzA1MDZkN2Q1MjgKKFhFTikg
WzIwMTQtMTEtMTggMTM6MDg6MTMuOTU4XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9
IDB4ODAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDg6MTMuOTU4XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDgwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTA3ZmNjMDAwLCBkb21haW4g
PSAxNiwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjEzLjk1OF0g
QU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowODowMC4wIGZyb20gZG9tMCB0byBkb20xNgooWEVO
KSBbMjAxNC0xMS0xOCAxMzowODoxNS4wMTVdIGlvLmM6NTUyOiBkMTY6IGJpbmQ6IG1fZ3Np
PTQ3IGdfZ3NpPTQwIGRldj0wMC4wMC42IGludHg9MCBmZmZmODMwNTA2ZDdkZDI4CihYRU4p
IFsyMDE0LTExLTE4IDEzOjA4OjE1LjAyMF0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweGEwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4
IDEzOjA4OjE1LjAyMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHhhMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDUwN2ZjYzAwMCwgZG9tYWlu
ID0gMTYsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoxNS4wMjBd
IEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTYKKGQx
NikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMDMxXSBIVk0gTG9hZGVyCihkMTYpIFsyMDE0LTEx
LTE4IDEzOjA4OjE1LjAzMV0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE2KSBbMjAxNC0x
MS0xOCAxMzowODoxNS4wMzFdIFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hh
bm5lbCAxCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjAzMV0gU3lzdGVtIHJlcXVlc3Rl
ZCBTZWFCSU9TCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjAzMV0gQ1BVIHNwZWVkIGlz
IDMyMDAgTUh6CihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjAzMl0gUmVsb2NhdGluZyBn
dWVzdCBtZW1vcnkgZm9yIGxvd21lbSBNTUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjAzMl0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAwIGNoYW5n
ZWQgMCAtPiA1CihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjAzMl0gUENJLUlTQSBsaW5r
IDAgcm91dGVkIHRvIElSUTUKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMDMzXSBpcnEu
YzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCihkMTYpIFsyMDE0LTEx
LTE4IDEzOjA4OjE1LjAzM10gUENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihYRU4p
IFsyMDE0LTExLTE4IDEzOjA4OjE1LjAzM10gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAy
IGNoYW5nZWQgMCAtPiAxMQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4wMzNdIFBDSS1J
U0EgbGluayAyIHJvdXRlZCB0byBJUlExMQooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoxNS4w
MzNdIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE2KSBb
MjAxNC0xMS0xOCAxMzowODoxNS4wMzNdIFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1
CihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjA1MV0gcGNpIGRldiAwMToyIElOVEQtPklS
UTUKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMDU4XSBwY2kgZGV2IDAxOjMgSU5UQS0+
SVJRMTAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMDYyXSBwY2kgZGV2IDAyOjAgSU5U
QS0+SVJRMTEKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMDc0XSBwY2kgZGV2IDA0OjAg
SU5UQS0+SVJRNQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4wODBdIHBjaSBkZXYgMDU6
MCBJTlRBLT5JUlExMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4wODZdIHBjaSBkZXYg
MDY6MCBJTlRBLT5JUlExMQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xMzJdIE5vIFJB
TSBpbiBoaWdoIG1lbW9yeTsgc2V0dGluZyBoaWdoX21lbSByZXNvdXJjZSBiYXNlIHRvIDEw
MDAwMDAwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xMzNdIHBjaSBkZXYgMDM6MCBi
YXIgMTAgc2l6ZSAwMDIwMDAwMDA6IDBmMDAwMDAwOAooZDE2KSBbMjAxNC0xMS0xOCAxMzow
ODoxNS4xMzVdIHBjaSBkZXYgMDI6MCBiYXIgMTQgc2l6ZSAwMDEwMDAwMDA6IDBmMjAwMDAw
OAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xMzhdIHBjaSBkZXYgMDY6MCBiYXIgMTAg
c2l6ZSAwMDAyMDAwMDA6IDBmMzAwMDAwNAooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoxNS4x
MzhdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAoo
ZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xNDRdIHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6
ZSAwMDAwNDAwMDA6IDBmMzIwMDAwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xNDZd
IHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6ZSAwMDAwMjAwMDA6IDBmMzI0MDAwMAooZDE2KSBb
MjAxNC0xMS0xOCAxMzowODoxNS4xNDZdIHBjaSBkZXYgMDM6MCBiYXIgMzAgc2l6ZSAwMDAw
MTAwMDA6IDBmMzI2MDAwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4xNDddIHBjaSBk
ZXYgMDU6MCBiYXIgMTAgc2l6ZSAwMDAwMDIwMDA6IDBmMzI3MDAwNAooWEVOKSBbMjAxNC0x
MS0xOCAxMzowODoxNS4xNDddIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZu
PWZlMGZlIG5yPTEKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMTUzXSBwY2kgZGV2IDAz
OjAgYmFyIDE0IHNpemUgMDAwMDAxMDAwOiAwZjMyNzIwMDAKKGQxNikgWzIwMTQtMTEtMTgg
MTM6MDg6MTUuMTU0XSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAw
MGMwMDEKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMTU2XSBwY2kgZGV2IDA0OjAgYmFy
IDE0IHNpemUgMDAwMDAwMDQwOiAwMDAwMGMxMDEKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6
MTUuMTU4XSBwY2kgZGV2IDAxOjIgYmFyIDIwIHNpemUgMDAwMDAwMDIwOiAwMDAwMGMxNDEK
KGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMTYxXSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNp
emUgMDAwMDAwMDEwOiAwMDAwMGMxNjEKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMTYz
XSBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKKGQxNikgWzIwMTQtMTEtMTggMTM6
MDg6MTUuMTg0XSAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4u
IHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUu
MjAxXSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBN
VFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjE4XSAg
LSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBb
MS84XSAuLi4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjM0XSAgLSBDUFUz
IC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAu
Li4gZG9uZS4KKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjM0XSBUZXN0aW5nIEhWTSBl
bnZpcm9ubWVudDoKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjQzXSAgLSBSRVAgSU5T
QiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxNikgWzIwMTQtMTEtMTgg
MTM6MDg6MTUuMjQ3XSAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCihk
MTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjI0N10gUGFzc2VkIDIgb2YgMiB0ZXN0cwooZDE2
KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNDddIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4K
KGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjQ5XSBMb2FkaW5nIFNlYUJJT1MgLi4uCihk
MTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjI0OV0gQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgoo
ZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNDldIExvYWRpbmcgQUNQSSAuLi4KKGQxNikg
WzIwMTQtMTEtMTggMTM6MDg6MTUuMjUwXSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE2KSBb
MjAxNC0xMS0xOCAxMzowODoxNS4yNTFdIEJJT1MgbWFwOgooZDE2KSBbMjAxNC0xMS0xOCAx
MzowODoxNS4yNTFdICAxMDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE2KSBbMjAxNC0x
MS0xOCAxMzowODoxNS4yNTFdICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjI1MV0gRTgyMCB0YWJsZToKKGQxNikgWzIwMTQtMTEtMTggMTM6
MDg6MTUuMjUxXSAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBhMDAw
MDogUkFNCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjI1MV0gIEhPTEU6IDAwMDAwMDAw
OjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwYzAwMDAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6
MTUuMjUxXSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDog
UkVTRVJWRUQKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjUxXSAgWzAyXTogMDAwMDAw
MDA6MDAxMDAwMDAgLSAwMDAwMDAwMDozZjgwMDAwMDogUkFNCihkMTYpIFsyMDE0LTExLTE4
IDEzOjA4OjE1LjI1MV0gIEhPTEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6ZmMw
MDAwMDAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjUxXSAgWzAzXTogMDAwMDAwMDA6
ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxNikgWzIwMTQtMTEt
MTggMTM6MDg6MTUuMjUxXSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE2KSBbMjAxNC0xMS0x
OCAxMzowODoxNS4yNTVdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMt
MjAxNDExMThfMTI1MjIzLXNlcnZlZXJzdGVydGplKQooZDE2KSBbMjAxNC0xMS0xOCAxMzow
ODoxNS4yNTVdIAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNTVdIEZvdW5kIFhlbiBo
eXBlcnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzow
ODoxNS4yNTVdIFJ1bm5pbmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE2KSBbMjAxNC0xMS0xOCAx
MzowODoxNS4yNTVdIHhlbjogY29weSBlODIwLi4uCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4
OjE1LjI1NV0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZjYyOSB0byAweDNmN2FlNjAw
IChzaXplIDcxOTk1KQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNThdIENQVSBNaHo9
MzIwMQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNjRdIEZvdW5kIDEwIFBDSSBkZXZp
Y2VzIChtYXggUENJIGJ1cyBpcyAwMCkKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjY0
XSBBbGxvY2F0ZWQgWGVuIGh5cGVyY2FsbCBwYWdlIGF0IDNmN2ZmMDAwCihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjI2NF0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE2KSBbMjAx
NC0xMS0xOCAxMzowODoxNS4yNjRdIHhlbjogY29weSBCSU9TIHRhYmxlcy4uLgooZDE2KSBb
MjAxNC0xMS0xOCAxMzowODoxNS4yNjRdIENvcHlpbmcgU01CSU9TIGVudHJ5IHBvaW50IGZy
b20gMHgwMDAxMDAxMCB0byAweDAwMGYwZjUwCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1
LjI2NF0gQ29weWluZyBNUFRBQkxFIGZyb20gMHhmYzAwMTFhMC9mYzAwMTFiMCB0byAweDAw
MGYwZTMwCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjI2NF0gQ29weWluZyBQSVIgZnJv
bSAweDAwMDEwMDMwIHRvIDB4MDAwZjBkYjAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUu
MjY0XSBDb3B5aW5nIEFDUEkgUlNEUCBmcm9tIDB4MDAwMTAwYjAgdG8gMHgwMDBmMGQ4MAoo
ZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yNjRdIFVzaW5nIHBtdGltZXIsIGlvcG9ydCAw
eGIwMDgKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjY0XSBTY2FuIGZvciBWR0Egb3B0
aW9uIHJvbQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS4yODFdIFJ1bm5pbmcgb3B0aW9u
IHJvbSBhdCBjMDAwOjAwMDMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6MTUuMjkwXSBzdGR2
Z2EuYzoxNDc6ZDE2djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihkMTYp
IFsyMDE0LTExLTE4IDEzOjA4OjE1LjMxN10gcG1tIGNhbGwgYXJnMT0wCihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjMxOF0gVHVybmluZyBvbiB2Z2EgdGV4dCBtb2RlIGNvbnNvbGUK
KGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuNDQyXSBTZWFCSU9TICh2ZXJzaW9uIHJlbC0x
LjcuNS0wLWdlNTE0ODhjLTIwMTQxMTE4XzEyNTIyMy1zZXJ2ZWVyc3RlcnRqZSkKKGQxNikg
WzIwMTQtMTEtMTggMTM6MDg6MTUuNDU2XSBNYWNoaW5lIFVVSUQgMTc3NTY4NTctMWI0ZS00
YThkLTkxNDktMmM2ZWJhYjAyNjE4CihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjQ1N10g
WEhDSSBpbml0IG9uIGRldiAwMDowNS4wOiByZWdzIEAgMHhmMzI3MDAwMCwgNCBwb3J0cywg
MzIgc2xvdHMsIDMyIGJ5dGUgY29udGV4dAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS40
NTddIHMKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuNDU3XSBYSENJICAgIGV4dGNhcCAw
eDEgQCBmMzI3MDUwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS40NTddIFhIQ0kgICAg
cHJvdG9jb2wgVVNCICAzLjAwLCAyIHBvcnRzIChvZmZzZXQgMSksIGRlZiAwCihkMTYpIFsy
MDE0LTExLTE4IDEzOjA4OjE1LjQ1N10gWEhDSSAgICBwcm90b2NvbCBVU0IgIDIuMDAsIDIg
cG9ydHMgKG9mZnNldCAzKSwgZGVmIDAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuNDU4
XSBVSENJIGluaXQgb24gZGV2IDAwOjAxLjIgKGlvPWMxNDApCihkMTYpIFsyMDE0LTExLTE4
IDEzOjA4OjE1LjQ1OV0gRm91bmQgMCBscHQgcG9ydHMKKGQxNikgWzIwMTQtMTEtMTggMTM6
MDg6MTUuNDU5XSBGb3VuZCAxIHNlcmlhbCBwb3J0cwooZDE2KSBbMjAxNC0xMS0xOCAxMzow
ODoxNS40NjBdIEFUQSBjb250cm9sbGVyIDEgYXQgMWYwLzNmNC8wIChpcnEgMTQgZGV2IDkp
CihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjQ2Ml0gQVRBIGNvbnRyb2xsZXIgMiBhdCAx
NzAvMzc0LzAgKGlycSAxNSBkZXYgOSkKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTUuNDY1
XSBhdGEwLTA6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgxMDI0MCBNaUJ5dGVz
KQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxNS40NjVdIFNlYXJjaGluZyBib290b3JkZXIg
Zm9yOiAvcGNpQGkwY2Y4LypAMSwxL2RyaXZlQDAvZGlza0AwCihkMTYpIFsyMDE0LTExLTE4
IDEzOjA4OjE1LjQ2N10gYXRhMC0xOiBRRU1VIEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAo
MzAwIEdpQnl0ZXMpCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjQ2N10gU2VhcmNoaW5n
IGJvb3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDEKKGQxNikg
WzIwMTQtMTEtMTggMTM6MDg6MTUuNTY0XSBQUzIga2V5Ym9hcmQgaW5pdGlhbGl6ZWQKKGQx
NikgWzIwMTQtMTEtMTggMTM6MDg6MTUuNjA5XSBYSENJIHBvcnQgIzQ6IDB4MDAyMDBhMDMs
IHBvd2VyZWQsIGVuYWJsZWQsIHBscyAwLCBzcGVlZCAyIFtMb3ddCihkMTYpIFsyMDE0LTEx
LTE4IDEzOjA4OjE1LjY0MF0gWEhDSSBubyBkZXZpY2VzIGZvdW5kCihkMTYpIFsyMDE0LTEx
LTE4IDEzOjA4OjE1LjY1MV0gQWxsIHRocmVhZHMgY29tcGxldGUuCihkMTYpIFsyMDE0LTEx
LTE4IDEzOjA4OjE1LjY1MV0gU2NhbiBmb3Igb3B0aW9uIHJvbXMKKGQxNikgWzIwMTQtMTEt
MTggMTM6MDg6MTUuNjc1XSBSdW5uaW5nIG9wdGlvbiByb20gYXQgYzk4MDowMDAzCihkMTYp
IFsyMDE0LTExLTE4IDEzOjA4OjE1LjY4MV0gcG1tIGNhbGwgYXJnMT0xCihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjY4Ml0gcG1tIGNhbGwgYXJnMT0wCihkMTYpIFsyMDE0LTExLTE4
IDEzOjA4OjE1LjY4M10gcG1tIGNhbGwgYXJnMT0xCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4
OjE1LjY4M10gcG1tIGNhbGwgYXJnMT0wCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1Ljcw
MF0gU2VhcmNoaW5nIGJvb3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkA0CihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE1LjcwMF0gCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1LjcwN10g
UHJlc3MgRjEyIGZvciBib290IG1lbnUuCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE1Ljcw
OF0gCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE4LjI0N10gU2VhcmNoaW5nIGJvb3RvcmRl
ciBmb3I6IEhBTFQKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTguMjQ3XSBkcml2ZSAweDAw
MGYwZDMwOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1
LzYzIHM9MjA5NzE1MjAKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTguMjQ3XSBkcml2ZSAw
eDAwMGYwZDAwOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQv
MjU1LzYzIHM9NjI5MTQ1NjAwCihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE4LjI0N10gCihk
MTYpIFsyMDE0LTExLTE4IDEzOjA4OjE4LjI0N10gU3BhY2UgYXZhaWxhYmxlIGZvciBVTUI6
IGNhODAwLWVmMDAwLCBmMDAwMC1mMGQwMAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxOC4y
NDddIFJldHVybmVkIDI1Mzk1MiBieXRlcyBvZiBab25lSGlnaAooZDE2KSBbMjAxNC0xMS0x
OCAxMzowODoxOC4yNDddIGU4MjAgbWFwIGhhcyA2IGl0ZW1zOgooZDE2KSBbMjAxNC0xMS0x
OCAxMzowODoxOC4yNDddICAgMDogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWZj
MDAgPSAxIFJBTQooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxOC4yNDddICAgMTogMDAwMDAw
MDAwMDA5ZmMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgPSAyIFJFU0VSVkVECihkMTYpIFsyMDE0
LTExLTE4IDEzOjA4OjE4LjI0N10gICAyOiAwMDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAw
MDEwMDAwMCA9IDIgUkVTRVJWRUQKKGQxNikgWzIwMTQtMTEtMTggMTM6MDg6MTguMjQ3XSAg
IDM6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDNmN2ZlMDAwID0gMSBSQU0KKGQxNikg
WzIwMTQtMTEtMTggMTM6MDg6MTguMjQ3XSAgIDQ6IDAwMDAwMDAwM2Y3ZmUwMDAgLSAwMDAw
MDAwMDNmODAwMDAwID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxOC4y
NDddICAgNTogMDAwMDAwMDBmYzAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJFU0VS
VkVECihkMTYpIFsyMDE0LTExLTE4IDEzOjA4OjE4LjI0OF0gZW50ZXIgaGFuZGxlXzE5Ogoo
ZDE2KSBbMjAxNC0xMS0xOCAxMzowODoxOC4yNDhdICAgTlVMTAooZDE2KSBbMjAxNC0xMS0x
OCAxMzowODoxOC4yNTVdIEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4KKGQxNikgWzIwMTQt
MTEtMTggMTM6MDg6MTguMjU3XSBCb290aW5nIGZyb20gMDAwMDo3YzAwCihYRU4pIFsyMDE0
LTExLTE4IDEzOjA4OjE4Ljc0OV0gLS1NQVJLLS0KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuNDY3XSBIVk0gTG9hZGVyCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjQ2N10gRGV0
ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi40NjddIFhl
bmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCAxCihkMTcpIFsyMDE0LTEx
LTE4IDEzOjA4OjIyLjQ2OF0gU3lzdGVtIHJlcXVlc3RlZCBTZWFCSU9TCihkMTcpIFsyMDE0
LTExLTE4IDEzOjA4OjIyLjQ2OF0gQ1BVIHNwZWVkIGlzIDMyMDAgTUh6CihkMTcpIFsyMDE0
LTExLTE4IDEzOjA4OjIyLjQ2OF0gUmVsb2NhdGluZyBndWVzdCBtZW1vcnkgZm9yIGxvd21l
bSBNTUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjIyLjQ2OF0g
aXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1CihkMTcpIFsyMDE0
LTExLTE4IDEzOjA4OjIyLjQ2OF0gUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUKKFhF
TikgWzIwMTQtMTEtMTggMTM6MDg6MjIuNDY4XSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5r
IDEgY2hhbmdlZCAwIC0+IDEwCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjQ2OF0gUENJ
LUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjIy
LjQ2OF0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAyIGNoYW5nZWQgMCAtPiAxMQooZDE3
KSBbMjAxNC0xMS0xOCAxMzowODoyMi40NjldIFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJ
UlExMQooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoyMi40NjldIGlycS5jOjI3MDogRG9tMTcg
UENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi40
NjldIFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1CihkMTcpIFsyMDE0LTExLTE4IDEz
OjA4OjIyLjQ4Nl0gcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihkMTcpIFsyMDE0LTExLTE4
IDEzOjA4OjIyLjQ5Ml0gcGNpIGRldiAwMjowIElOVEEtPklSUTExCihkMTcpIFsyMDE0LTEx
LTE4IDEzOjA4OjIyLjUwMl0gcGNpIGRldiAwNDowIElOVEEtPklSUTUKKGQxNykgWzIwMTQt
MTEtMTggMTM6MDg6MjIuNTQ5XSBObyBSQU0gaW4gaGlnaCBtZW1vcnk7IHNldHRpbmcgaGln
aF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTM6
MDg6MjIuNTUwXSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAyMDAwMDAwOiAwZjAwMDAw
MDgKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNTUyXSBwY2kgZGV2IDAyOjAgYmFyIDE0
IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIu
NTUzXSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUgMDAwMDQwMDAwOiAwZjMwMDAwMDAKKGQx
NykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNTU1XSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUg
MDAwMDIwMDAwOiAwZjMwNDAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNTU1XSBw
Y2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEwMDAwOiAwZjMwNjAwMDAKKGQxNykgWzIw
MTQtMTEtMTggMTM6MDg6MjIuNTU3XSBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDAwMDAx
MDAwOiAwZjMwNzAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNTU3XSBwY2kgZGV2
IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDEKKGQxNykgWzIwMTQtMTEt
MTggMTM6MDg6MjIuNTU5XSBwY2kgZGV2IDA0OjAgYmFyIDE0IHNpemUgMDAwMDAwMDQwOiAw
MDAwMGMxMDEKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNTYxXSBwY2kgZGV2IDAxOjEg
YmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMxNDEKKGQxNykgWzIwMTQtMTEtMTggMTM6
MDg6MjIuNTYzXSBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKKGQxNykgWzIwMTQt
MTEtMTggMTM6MDg6MjIuNTgyXSAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQg
TVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTgg
MTM6MDg6MjIuNjAwXSAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMg
Li4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuNjE4XSAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh
ciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjM2
XSAgLSBDUFUzIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS
cyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjM2XSBUZXN0
aW5nIEhWTSBlbnZpcm9ubWVudDoKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjQ2XSAg
LSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKGQxNykgWzIw
MTQtMTEtMTggMTM6MDg6MjIuNjUwXSAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4g
cGFzc2VkCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY1MF0gUGFzc2VkIDIgb2YgMiB0
ZXN0cwooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTBdIFdyaXRpbmcgU01CSU9TIHRh
YmxlcyAuLi4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjUxXSBMb2FkaW5nIFNlYUJJ
T1MgLi4uCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY1MV0gQ3JlYXRpbmcgTVAgdGFi
bGVzIC4uLgooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTFdIExvYWRpbmcgQUNQSSAu
Li4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjUzXSB2bTg2IFRTUyBhdCBmYzAwYTIw
MAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTNdIEJJT1MgbWFwOgooZDE3KSBbMjAx
NC0xMS0xOCAxMzowODoyMi42NTNdICAxMDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQooZDE3
KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTNdICBjMDAwMC1mZmZmZjogTWFpbiBCSU9TCihk
MTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY1M10gRTgyMCB0YWJsZToKKGQxNykgWzIwMTQt
MTEtMTggMTM6MDg6MjIuNjUzXSAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAw
MDowMDBhMDAwMDogUkFNCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY1M10gIEhPTEU6
IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwYzAwMDAKKGQxNykgWzIwMTQtMTEt
MTggMTM6MDg6MjIuNjUzXSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDow
MDEwMDAwMDogUkVTRVJWRUQKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjUzXSAgWzAy
XTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDozZjgwMDAwMDogUkFNCihkMTcpIFsy
MDE0LTExLTE4IDEzOjA4OjIyLjY1M10gIEhPTEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAw
MDAwMDA6ZmMwMDAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjUzXSAgWzAzXTog
MDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKKGQxNykg
WzIwMTQtMTEtMTggMTM6MDg6MjIuNjU0XSBJbnZva2luZyBTZWFCSU9TIC4uLgooZDE3KSBb
MjAxNC0xMS0xOCAxMzowODoyMi42NTZdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAt
Z2U1MTQ4OGMtMjAxNDExMThfMTI1MjIzLXNlcnZlZXJzdGVydGplKQooZDE3KSBbMjAxNC0x
MS0xOCAxMzowODoyMi42NTZdIAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTZdIEZv
dW5kIFhlbiBoeXBlcnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMAooZDE3KSBbMjAxNC0x
MS0xOCAxMzowODoyMi42NTZdIFJ1bm5pbmcgb24gUUVNVSAoaTQ0MGZ4KQooZDE3KSBbMjAx
NC0xMS0xOCAxMzowODoyMi42NTZdIHhlbjogY29weSBlODIwLi4uCihkMTcpIFsyMDE0LTEx
LTE4IDEzOjA4OjIyLjY1Nl0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZjYyOSB0byAw
eDNmN2FlNjAwIChzaXplIDcxOTk1KQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NTld
IENQVSBNaHo9MzIwMQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NjNdIEZvdW5kIDcg
UENJIGRldmljZXMgKG1heCBQQ0kgYnVzIGlzIDAwKQooZDE3KSBbMjAxNC0xMS0xOCAxMzow
ODoyMi42NjNdIEFsbG9jYXRlZCBYZW4gaHlwZXJjYWxsIHBhZ2UgYXQgM2Y3ZmYwMDAKKGQx
NykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjYzXSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihk
MTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY2M10geGVuOiBjb3B5IEJJT1MgdGFibGVzLi4u
CihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY2M10gQ29weWluZyBTTUJJT1MgZW50cnkg
cG9pbnQgZnJvbSAweDAwMDEwMDEwIHRvIDB4MDAwZjBmNTAKKGQxNykgWzIwMTQtMTEtMTgg
MTM6MDg6MjIuNjYzXSBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMWEwL2ZjMDAxMWIw
IHRvIDB4MDAwZjBlMzAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNjYzXSBDb3B5aW5n
IFBJUiBmcm9tIDB4MDAwMTAwMzAgdG8gMHgwMDBmMGRiMAooZDE3KSBbMjAxNC0xMS0xOCAx
MzowODoyMi42NjNdIENvcHlpbmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAw
MGYwZDgwCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY2M10gVXNpbmcgcG10aW1lciwg
aW9wb3J0IDB4YjAwOAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi42NjNdIFNjYW4gZm9y
IFZHQSBvcHRpb24gcm9tCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjY3OV0gUnVubmlu
ZyBvcHRpb24gcm9tIGF0IGMwMDA6MDAwMwooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoyMi42
ODhdIHN0ZHZnYS5jOjE0NzpkMTd2MCBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9k
ZXMKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNzA3XSBwbW0gY2FsbCBhcmcxPTAKKGQx
NykgWzIwMTQtMTEtMTggMTM6MDg6MjIuNzA4XSBUdXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUg
Y29uc29sZQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi44MzRdIFNlYUJJT1MgKHZlcnNp
b24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMThfMTI1MjIzLXNlcnZlZXJzdGVydGpl
KQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi44NDddIE1hY2hpbmUgVVVJRCAzZDczNDUz
MS0wZWQ2LTQwNTEtODA4Yi00Y2Q3YTNkNmFkMDIKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuODQ4XSBBbGwgdGhyZWFkcyBjb21wbGV0ZS4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuODQ4XSBGb3VuZCAwIGxwdCBwb3J0cwooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi44
NDldIEZvdW5kIDAgc2VyaWFsIHBvcnRzCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjIyLjg0
OV0gQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0LzAgKGlycSAxNCBkZXYgOSkKKGQxNykg
WzIwMTQtMTEtMTggMTM6MDg6MjIuODUwXSBBVEEgY29udHJvbGxlciAyIGF0IDE3MC8zNzQv
MCAoaXJxIDE1IGRldiA5KQooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyMi44NTRdIGF0YTAt
MDogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDEwMjQwIE1pQnl0ZXMpCihkMTcp
IFsyMDE0LTExLTE4IDEzOjA4OjIyLjg1NF0gU2VhcmNoaW5nIGJvb3RvcmRlciBmb3I6IC9w
Y2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuOTUyXSBQUzIga2V5Ym9hcmQgaW5pdGlhbGl6ZWQKKGQxNykgWzIwMTQtMTEtMTggMTM6
MDg6MjIuOTUyXSBBbGwgdGhyZWFkcyBjb21wbGV0ZS4KKGQxNykgWzIwMTQtMTEtMTggMTM6
MDg6MjIuOTUyXSBTY2FuIGZvciBvcHRpb24gcm9tcwooZDE3KSBbMjAxNC0xMS0xOCAxMzow
ODoyMi45NzVdIFJ1bm5pbmcgb3B0aW9uIHJvbSBhdCBjOTgwOjAwMDMKKGQxNykgWzIwMTQt
MTEtMTggMTM6MDg6MjIuOTgxXSBwbW0gY2FsbCBhcmcxPTEKKGQxNykgWzIwMTQtMTEtMTgg
MTM6MDg6MjIuOTgyXSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6
MjIuOTgzXSBwbW0gY2FsbCBhcmcxPTEKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjIuOTgz
XSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjMuMDAwXSBTZWFy
Y2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDQKKGQxNykgWzIwMTQtMTEtMTgg
MTM6MDg6MjMuMDAwXSAKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjMuMDA2XSBQcmVzcyBG
MTIgZm9yIGJvb3QgbWVudS4KKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjMuMDA2XSAKKFhF
TikgWzIwMTQtMTEtMTggMTM6MDg6MjMuNzcxXSBzdGR2Z2EuYzoxNTE6ZDE2djAgbGVhdmlu
ZyBzdGR2Z2EKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjUuNTUxXSBTZWFyY2hpbmcgYm9v
dG9yZGVyIGZvcjogSEFMVAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyNS41NTJdIGRyaXZl
IDB4MDAwZjBkMzA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAy
NC8yNTUvNjMgcz0yMDk3MTUyMAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyNS41NTJdIFNw
YWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkMzAKKGQxNykg
WzIwMTQtMTEtMTggMTM6MDg6MjUuNTUyXSBSZXR1cm5lZCAyNTgwNDggYnl0ZXMgb2YgWm9u
ZUhpZ2gKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjUuNTUyXSBlODIwIG1hcCBoYXMgNiBp
dGVtczoKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjUuNTUyXSAgIDA6IDAwMDAwMDAwMDAw
MDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0KKGQxNykgWzIwMTQtMTEtMTggMTM6
MDg6MjUuNTUyXSAgIDE6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEwMDAwID0g
MiBSRVNFUlZFRAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyNS41NTJdICAgMjogMDAwMDAw
MDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgPSAyIFJFU0VSVkVECihkMTcpIFsyMDE0
LTExLTE4IDEzOjA4OjI1LjU1Ml0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDAz
ZjdmZjAwMCA9IDEgUkFNCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjI1LjU1Ml0gICA0OiAw
MDAwMDAwMDNmN2ZmMDAwIC0gMDAwMDAwMDAzZjgwMDAwMCA9IDIgUkVTRVJWRUQKKGQxNykg
WzIwMTQtMTEtMTggMTM6MDg6MjUuNTUyXSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAgLSAwMDAw
MDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRAooZDE3KSBbMjAxNC0xMS0xOCAxMzowODoyNS41
NTNdIGVudGVyIGhhbmRsZV8xOToKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjUuNTUzXSAg
IE5VTEwKKGQxNykgWzIwMTQtMTEtMTggMTM6MDg6MjUuNTU5XSBCb290aW5nIGZyb20gSGFy
ZCBEaXNrLi4uCihkMTcpIFsyMDE0LTExLTE4IDEzOjA4OjI1LjU2MV0gQm9vdGluZyBmcm9t
IDAwMDA6N2MwMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowODoyOC4xMjFdIGdyYW50X3RhYmxl
LmM6MzA1OmQwdjQgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gOCBmcmFtZXMKKFhFTikg
WzIwMTQtMTEtMTggMTM6MDg6MjguNzQ5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MzowODozMi4wMzhdIHN0ZHZnYS5jOjE1MTpkMTd2MCBsZWF2aW5nIHN0ZHZnYQooWEVOKSBb
MjAxNC0xMS0xOCAxMzowODozOC43NDldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjA4OjQ4Ljc0OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6NDkuNTQ4XSBz
dGR2Z2EuYzoxNDc6ZDE2djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihY
RU4pIFsyMDE0LTExLTE4IDEzOjA4OjUxLjE1N10gaXJxLmM6MzgwOiBEb20xNiBjYWxsYmFj
ayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMKKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDg6NTYuNTEzXSBzdGR2Z2EuYzoxNDc6ZDE3djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBj
YWNoaW5nIG1vZGVzCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU2Ljk5OV0gbWVtb3J5X21h
cDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0x
MS0xOCAxMzowODo1Ny4wMDRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZu
PWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6NTcuMDA4XSBtZW1vcnlfbWFw
OnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjA4OjU3LjAxM10gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49
ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xOCAxMzowODo1Ny4wMTddIG1lbW9yeV9tYXA6
cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEt
MTggMTM6MDg6NTcuMDIzXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1m
ZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjAyN10gbWVtb3J5X21hcDpy
ZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0x
OCAxMzowODo1Ny4wMzJdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZl
MGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6NTcuMDM2XSBtZW1vcnlfbWFwOnJl
bW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE4
IDEzOjA4OjU3LjA0MF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUw
ZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xOCAxMzowODo1Ny4wNDRdIG1lbW9yeV9tYXA6cmVt
b3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDg6NTcuMDQ5XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBm
ZSBucj0xCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjA1OV0gbWVtb3J5X21hcDpyZW1v
dmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4
IDEzOjA4OjU3LjA2Nl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUy
MDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjA3Ml0gbWVtb3J5X21hcDpy
ZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjA4OjU3LjA3OF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBtZm49
ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjA4M10gbWVtb3J5X21h
cDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0
LTExLTE4IDEzOjA4OjU3LjA4OV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBt
Zm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjA5NV0gbWVtb3J5
X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsy
MDE0LTExLTE4IDEzOjA4OjU3LjEwMV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAw
MCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjEwN10gbWVt
b3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4p
IFsyMDE0LTExLTE4IDEzOjA4OjU3LjExM10gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1m
MzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjExOF0g
bWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihY
RU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjEyNF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdm
bj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU3LjE1
OV0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCihYRU4pIFsy
MDE0LTExLTE4IDEzOjA4OjU3LjE4MF0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAxIGNo
YW5nZWQgMTAgLT4gMAooWEVOKSBbMjAxNC0xMS0xOCAxMzowODo1Ny4yMDFdIGlycS5jOjI3
MDogRG9tMTYgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDAKKFhFTikgWzIwMTQtMTEtMTgg
MTM6MDg6NTcuMjI2XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDMgY2hhbmdlZCA1IC0+
IDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6NTguMjAxXSBpcnEuYzozODA6IERvbTE3IGNh
bGxiYWNrIHZpYSBjaGFuZ2VkIHRvIERpcmVjdCBWZWN0b3IgMHhmMwooWEVOKSBbMjAxNC0x
MS0xOCAxMzowODo1OC43NDldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU5
LjIxNV0gZ3JhbnRfdGFibGUuYzoxMjk5OmQxNnYzIEV4cGFuZGluZyBkb20gKDE2KSBncmFu
dCB0YWJsZSBmcm9tICg0KSB0byAoNSkgZnJhbWVzLgooWEVOKSBbMjAxNC0xMS0xOCAxMzow
ODo1OS4zMDVdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMAoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowODo1OS4zMTFdIGlycS5jOjI3MDogRG9tMTcgUENJIGxp
bmsgMSBjaGFuZ2VkIDEwIC0+IDAKKFhFTikgWzIwMTQtMTEtMTggMTM6MDg6NTkuMzE3XSBp
cnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwCihYRU4pIFsyMDE0
LTExLTE4IDEzOjA4OjU5LjMyMl0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAzIGNoYW5n
ZWQgNSAtPiAwCihYRU4pIFsyMDE0LTExLTE4IDEzOjA4OjU5Ljc5MF0gZ3JhbnRfdGFibGUu
YzoxMjk5OmQxN3YyIEV4cGFuZGluZyBkb20gKDE3KSBncmFudCB0YWJsZSBmcm9tICg0KSB0
byAoNSkgZnJhbWVzLgooWEVOKSBbMjAxNC0xMS0xOCAxMzowOTowOC43NDldIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjA5OjE4Ljc1MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MDk6MjguNzUwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzowOToy
OS42NDVdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUg
dG8gOSBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTggMTM6MDk6MzguNzUwXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzowOTo0OC43NTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjA5OjU4Ljc1MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTA6MDgu
NzUwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxMDoxOC43NTFdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjEwOjI4Ljc1MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MTA6MzguNzUxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxMDo0
OC43NTFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjEwOjU4Ljc1MV0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTE6MDguNzUyXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzoxMToxMi4yNzhdIGdyYW50X3RhYmxlLmM6MTI5OTpkMTZ2MSBFeHBhbmRp
bmcgZG9tICgxNikgZ3JhbnQgdGFibGUgZnJvbSAoNSkgdG8gKDYpIGZyYW1lcy4KKFhFTikg
WzIwMTQtMTEtMTggMTM6MTE6MTIuNTE3XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIEluY3Jl
YXNlZCBtYXB0cmFjayBzaXplIHRvIDEwIGZyYW1lcwooWEVOKSBbMjAxNC0xMS0xOCAxMzox
MToxOC43NTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjExOjI4Ljc1Ml0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTE6MzguNzUyXSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMzoxMTo0OC43NTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjExOjU4Ljc1M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTI6MDguNzUzXSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxMjoxOC43NTNdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjEyOjI4Ljc1M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6MTI6MzguNzUzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxMjo0OC44Nzld
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjEyOjU4Ljg4MF0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6MTM6MDguODgwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzoxMzoxOC44ODBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjEzOjI4Ljg4
MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTM6MzguODgwXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzoxMzo0OC44ODFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjEzOjU4Ljg4MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTQ6MDgu
ODgxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxNDoxOC44ODFdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjE0OjI4Ljg4MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MTQ6MzguODgxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxNDo0
OC44ODFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE0OjU4Ljg4Ml0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTU6MDguODgyXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzoxNToxOC44ODJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE1
OjI4Ljg4Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTU6MzguODgyXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxNTo0OC44ODJdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjE1OjU4Ljg4M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
MTY6MDguODgzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxNjoxOC44ODNdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE2OjI4Ljg4M10gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6MTY6MzguODgzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MzoxNjo0OC44ODNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE2OjU4Ljg4NF0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTc6MDguODg0XSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxMzoxNzoxOC44ODRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDEzOjE3OjI4Ljg4NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTc6MzguODg0
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxNzo0OC44ODRdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDEzOjE3OjU4Ljg4NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTM6MTg6MDguODg1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxODoxOC44
ODVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE4OjI4Ljg4NV0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTM6MTg6MzguODg1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMzoxODo0OC44ODVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjE4OjU4
Ljg4NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTk6MDguODg2XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxOToxOC44ODZdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDEzOjE5OjI4Ljg4Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MTk6
MzguODg2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxOTo0NS4zNzldIGdyYW50
X3RhYmxlLmM6MTI5OTpkMTZ2MiBFeHBhbmRpbmcgZG9tICgxNikgZ3JhbnQgdGFibGUgZnJv
bSAoNikgdG8gKDcpIGZyYW1lcy4KKFhFTikgWzIwMTQtMTEtMTggMTM6MTk6NDguODg2XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoxOTo1OC44ODddIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjIwOjA4Ljg4N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6MjA6MTguODg3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyMDoyOC44ODdd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjIwOjM4Ljg4N10gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6MjA6NDguODg4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzoyMDo1OC44ODhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjIxOjA4Ljg4
OF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjE6MTguODg4XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzoyMToyOC44ODhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjIxOjM4Ljg4OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjE6NDgu
ODg5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyMTo1OC44ODldIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjIyOjA4Ljg4OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MjI6MTguODg5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyMjoy
OC44ODldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjIyOjM4Ljg5MF0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjI6NDguODkwXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzoyMjo1OC44OTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjIz
OjA4Ljg5MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjM6MTguODkwXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyMzoyOC44OTFdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjIzOjM4Ljg5MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
MjM6NDguODkxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyMzo1OC44OTFdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI0OjA4Ljg5MV0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6MjQ6MTguODkyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MzoyNDoyOC44OTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI0OjM4Ljg5Ml0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjQ6NDguODkyXSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxMzoyNDo1OC44OTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDEzOjI1OjA4Ljg5M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjU6MTguODkz
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyNToyOC44OTNdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDEzOjI1OjM4Ljg5M10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTM6MjU6NDguODk0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyNTo1OC44
OTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI2OjA4Ljg5NF0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTM6MjY6MTguODk0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMzoyNjoyOC44OTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI2OjM4
Ljg5NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MjY6NDguODk1XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyNjo1OC44OTVdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDEzOjI3OjA4Ljg5NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mjc6
MTguODk1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyNzoyOC44OTVdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI3OjM4Ljg5Nl0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTM6Mjc6NDguODk2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoy
Nzo1OC44OTZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI4OjA4Ljg5Nl0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mjg6MTguODk2XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMzoyODoyOC44OTddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjI4OjM4Ljg5N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mjg6NDguODk3XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyODo1OC44OTddIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjI5OjA4Ljg5N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6Mjk6MTguODk4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoyOToyOC44OThd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjI5OjM4Ljg5OF0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6Mjk6NDguODk4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzoyOTo1OC44OTldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjMwOjA4Ljg5
OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzA6MTguODk5XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzozMDoyOC44OTldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjMwOjM4Ljg5OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzA6NDgu
OTAwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozMDo1OC45MDBdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjMxOjA4LjkwMF0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6MzE6MTguOTAwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozMToy
OC45MDBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjMxOjM4LjkwMV0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzE6NDguOTAxXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzozMTo1OC45MDFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjMy
OjA4LjkwMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzI6MTguOTAxXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozMjoyOC45MDJdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjMyOjM4LjkwMl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
MzI6NDguOTAyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozMjo1OC45MDJdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjMzOjA4LjkwM10gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6MzM6MTguOTAzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MzozMzoyOC45MDNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjMzOjM4LjkwM10g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzM6NDguOTA0XSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxMzozMzo1OC45MDRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDEzOjM0OjA4LjkwNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzQ6MTguOTA0
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozNDoyOC45MDRdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDEzOjM0OjM4LjkwNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTM6MzQ6NDguOTA0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozNDo1OC45
MDVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM1OjA4LjkwNV0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTM6MzU6MTguOTA1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMzozNToyOC45MDVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM1OjM4
LjkwNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzU6NDguOTA2XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzozNTo1OC45MDZdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDEzOjM2OjA4LjkwNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6MzY6
MTguOTA2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozNjoyOC45MDddIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM2OjM4LjkwN10gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTM6MzY6NDguOTA3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzoz
Njo1OC45MDddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM3OjA4LjkwOF0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mzc6MTguOTA4XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMzozNzoyOC45MDhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjM3OjM4LjkwOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mzc6NDguOTA4XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozNzo1OC45MDldIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjM4OjA4LjkwOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6Mzg6MTguOTA5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozODoyOC45MDld
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM4OjM4LjkwOV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6Mzg6NDguOTEwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzozODo1OC45MTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjM5OjA4Ljkx
MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mzk6MTguOTEwXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzozOToyOC45MTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjM5OjM4LjkxMF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6Mzk6NDgu
OTExXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzozOTo1OC45MTFdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjQwOjA4LjkxMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6NDA6MTguOTExXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0MDoy
OC45MTFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQwOjM4LjkxMl0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDA6NDguOTEyXSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzo0MDo1OC45MTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQx
OjA4LjkxMl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDE6MTguOTEyXSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0MToyOC45MTJdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjQxOjM4LjkxM10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
NDE6NDguOTEzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0MTo1OC45MTNdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQyOjA4LjkxM10gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6NDI6MTguOTEzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
Mzo0MjoyOC45MTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQyOjM4LjkxNF0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDI6NDguOTE0XSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxMzo0Mjo1OC45MTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDEzOjQzOjA4LjkxNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDM6MTguOTE0
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0MzoyOC45MTRdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDEzOjQzOjM4LjkxNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTM6NDM6NDguOTE1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0Mzo1OC45
MTVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ0OjA4LjkxNV0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTM6NDQ6MTguOTE1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMzo0NDoyOC45MTVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ0OjM4
LjkxNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDQ6NDguOTE2XSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0NDo1OC45MTZdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDEzOjQ1OjA4LjkxNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDU6
MTguOTE2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0NToyOC45MTZdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ1OjM4LjkxN10gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTM6NDU6NDguOTEzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0
NTo1OC45MTNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ2OjA4LjkxM10gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDY6MTguOTE0XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMzo0NjoyOC45MTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjQ2OjM4LjkxNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDY6NDguOTE0XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0Njo1OC45MTRdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjQ3OjA4LjkxNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6NDc6MTguOTE1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0NzoyOC45MTVd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ3OjM4LjkxNV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6NDc6NDguOTE1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzo0Nzo1OC45MTVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ4OjA4Ljkx
Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDg6MTguOTE2XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzo0ODoyOC45MTZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjQ4OjM4LjkxNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDg6NDgu
OTE2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0ODo1OC45MTZdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjQ5OjA4LjkxN10gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6NDk6MTguOTE3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo0OToy
OC45MTddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjQ5OjM4LjkxN10gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NDk6NDguOTE3XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzo0OTo1OC45MTddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjUw
OjA4LjkxOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTA6MTguOTE4XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1MDoyOC45MThdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjUwOjM4LjkxOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
NTA6NDguOTE4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1MDo1OC45MTldIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjUxOjA4LjkxOV0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTM6NTE6MTguOTE5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
Mzo1MToyOC45MTldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjUxOjM4LjkxOV0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTE6NDguOTIwXSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxMzo1MTo1OC45MjBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDEzOjUyOjA4LjkyMF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTI6MTguOTIw
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1MjoyOC45MjBdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDEzOjUyOjM4LjkyMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTM6NTI6NDguOTIxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1Mjo1OC45
MjFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjUzOjA4LjkyMV0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTM6NTM6MTguOTIyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMzo1MzoyOC45MjJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjUzOjM4
LjkyMl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTM6NDguOTIyXSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1Mzo1OC45MjJdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDEzOjU0OjA4LjkyM10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTQ6
MTguOTIzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1NDoyOC45MjNdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU0OjM4LjkyM10gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTM6NTQ6NDguOTIzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1
NDo1OC45MjRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU1OjA4LjkyNF0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTU6MTguOTI0XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMzo1NToyOC45MjRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEz
OjU1OjM4LjkyNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTU6NDguOTI1XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1NTo1OC45MjVdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDEzOjU2OjA4LjkyNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTM6NTY6MTguOTI1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1NjoyOC45MjVd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU2OjM4LjkyNV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTM6NTY6NDguOTI1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMzo1Njo1OC45MjVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU3OjA4Ljky
Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTc6MTguOTI2XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMzo1NzoyOC45MjZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDEzOjU3OjM4LjkyNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTc6NDgu
OTI3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1Nzo1OC45MjddIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDEzOjU4OjA4LjkyN10gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTM6NTg6MTguOTI3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1ODoy
OC45MjhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU4OjM4LjkyOF0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTg6NDguOTI4XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMzo1ODo1OC45MjhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEzOjU5
OjA4LjkyOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6NTk6MTguOTI4XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1OToyOC45MjldIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDEzOjU5OjM4LjkyOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTM6
NTk6NDguOTI5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMzo1OTo1OC45MjldIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjAwOjA4LjkyOV0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MDA6MTguOTMwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
NDowMDoyOC45MzBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjAwOjM4LjkzMF0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDA6NDguOTMwXSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxNDowMDo1OC45MzBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDE0OjAxOjA4LjkzMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDE6MTguOTMx
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowMToyOC45MzFdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDE0OjAxOjM4LjkzMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MDE6NDguOTMxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowMTo1OC45
MzJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjAyOjA4LjkzMl0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MDI6MTguOTMyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxNDowMjoyOC45MzJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjAyOjM4
LjkzMl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDI6NDguOTMzXSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxNDowMjo1OC45MzNdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDE0OjAzOjA4LjkzM10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDM6
MTguOTMzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowMzoyOC45MzRdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjAzOjM4LjkzNF0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6MDM6NDguOTM0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDow
Mzo1OC45MzRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA0OjA4LjkzNF0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDQ6MTguOTM0XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxNDowNDoyOC45MzVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0
OjA0OjM4LjkzNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDQ6NDguOTM1XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowNDo1OC45MzVdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDE0OjA1OjA4LjkzNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTQ6MDU6MTguOTM2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowNToyOC45MzZd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA1OjM4LjkzNl0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTQ6MDU6NDguOTM2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxNDowNTo1OC45MzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA2OjA4Ljkz
N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDY6MTguOTM3XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxNDowNjoyOC45MzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDE0OjA2OjM4LjkzN10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDY6NDgu
OTM4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowNjo1OC45MzhdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDE0OjA3OjA4LjkzOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTQ6MDc6MTguOTM4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowNzoy
OC45MzhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA3OjM4LjkzOV0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDc6NDguOTM1XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxNDowNzo1OC45MzVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA4
OjA4LjkzNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDg6MTguOTM2XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowODoyOC45MzZdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDE0OjA4OjM4LjkzNl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6
MDg6NDguOTM2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDowODo1OC45MzZdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA5OjA4LjkzNl0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTQ6MDk6MTguOTM3XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
NDowOToyOC45MzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjA5OjM4LjkzN10g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MDk6NDguOTM3XSAtLU1BUkstLQooWEVO
KSBbMjAxNC0xMS0xOCAxNDowOTo1OC45MzddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4
IDE0OjEwOjA4LjkzOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MTA6MTguOTM4
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDoxMDoyOC45MzhdIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDE0OjEwOjM4LjkzOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTQ6MTA6NDguOTM4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDoxMDo1OC45
MzldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjExOjA4LjkzOV0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTQ6MTE6MTguOTM5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxNDoxMToyOC45MzldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjExOjM4
LjkzOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MTE6NDguOTQwXSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxNDoxMTo1OC45NDBdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDE0OjEyOjA4Ljk0MF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MTI6
MTguOTQwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDoxMjoyOC45NDBdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjEyOjM4Ljk0MV0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTQ6MTI6NDguOTQxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxNDox
Mjo1OC45NDFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDE0OjEzOjA4Ljk0MV0gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTQ6MTM6MTguOTQxXSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxNDoxMzoyOC45NDFdIC0tTUFSSy0tCg==
------------0191A1230144FE1ED
Content-Type: text/plain;
 name="xl-dmesg-not-defined.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg-not-defined.txt"

fCB8IHwgfF9fICAgX3wgX19fKSB8IHxffCB8X198IHwgfCAoX18gCiAvXy9cX1xfX198X3wg
fF98ICAgIHxffChfKV9fX18oXylfX18vICAgfF98ICBcX19ffAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKKFhFTikgWGVuIHZlcnNpb24g
NC41LjAtcmMgKHJvb3RAZHluZG5zLm9yZykgKGdjYy00LjcucmVhbCAoRGViaWFuIDQuNy4y
LTUpIDQuNy4yKSBkZWJ1Zz15IFR1ZSBOb3YgMTggMTI6MTk6MTAgQ0VUIDIwMTQKKFhFTikg
TGF0ZXN0IENoYW5nZVNldDogTW9uIE5vdiAxNyAxNTowNzowMyAyMDE0ICswMTAwIGdpdDow
NTQwYjg1LWRpcnR5CihYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OS0yNytkZWI3dTIKKFhF
TikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0xNTM2TSxtYXg6MTUzNk0gbG9nbHZsPWFsbCBs
b2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcz1kYXRlbXMgdmdhPWdmeC0xMjgw
eDEwMjR4MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBjb20xPTM4NDAwLDhuMSBjb25zb2xlPXZn
YSxjb20xIGl2cnNfaW9hcGljWzZdPTAwOjE0LjAgaW9tbXU9b24sdmVyYm9zZSxkZWJ1Zyxh
bWQtaW9tbXUtZGVidWcgZGVidWcgbGFwaWM9ZGVidWcgYXBpY192ZXJib3NpdHk9ZGVidWcg
YXBpYz1kZWJ1ZwooWEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoKKFhFTikgIFZHQSBpcyBncmFw
aGljcyBtb2RlIDEyODB4MTAyNCwgMzIgYnBwCihYRU4pICBWQkUvRERDIG1ldGhvZHM6IFYy
OyBFRElEIHRyYW5zZmVyIHRpbWU6IDEgc2Vjb25kcwooWEVOKSBEaXNjIGluZm9ybWF0aW9u
OgooWEVOKSAgRm91bmQgMiBNQlIgc2lnbmF0dXJlcwooWEVOKSAgRm91bmQgMiBFREQgaW5m
b3JtYXRpb24gc3RydWN0dXJlcwooWEVOKSBYZW4tZTgyMCBSQU0gbWFwOgooWEVOKSAgMDAw
MDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOTk0MDAgKHVzYWJsZSkKKFhFTikgIDAwMDAw
MDAwMDAwOTk0MDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAw
MDAwMDAwZTQwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAw
MDAwMDAxMDAwMDAgLSAwMDAwMDAwMDlmZjkwMDAwICh1c2FibGUpCihYRU4pICAwMDAwMDAw
MDlmZjkwMDAwIC0gMDAwMDAwMDA5ZmY5ZTAwMCAoQUNQSSBkYXRhKQooWEVOKSAgMDAwMDAw
MDA5ZmY5ZTAwMCAtIDAwMDAwMDAwOWZmZTAwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAw
MDA5ZmZlMDAwMCAtIDAwMDAwMDAwYTAwMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAw
MDBmZmUwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAw
MDEwMDAwMDAwMCAtIDAwMDAwMDA1NjAwMDAwMDAgKHVzYWJsZSkKKFhFTikgQUNQSTogUlNE
UCAwMDBGQjEwMCwgMDAxNCAocjAgQUNQSUFNKQooWEVOKSBBQ1BJOiBSU0RUIDlGRjkwMDAw
LCAwMDQ4IChyMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykKKFhF
TikgQUNQSTogRkFDUCA5RkY5MDIwMCwgMDA4NCAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAw
OTEzIE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6IERTRFQgOUZGOTA1RTAsIDk0MjcgKHIx
ICBBNzY0MCBBNzY0MDEwMCAgICAgIDEwMCBJTlRMIDIwMDUxMTE3KQooWEVOKSBBQ1BJOiBG
QUNTIDlGRjlFMDAwLCAwMDQwCihYRU4pIEFDUEk6IEFQSUMgOUZGOTAzOTAsIDAwODggKHIx
IDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBN
Q0ZHIDlGRjkwNDIwLCAwMDNDIChyMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAg
ICAgICA5NykKKFhFTikgQUNQSTogU0xJQyA5RkY5MDQ2MCwgMDE3NiAocjEgTVNJICAgIE9F
TVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6IE9FTUIgOUZGOUUw
NDAsIDAwNzIgKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQoo
WEVOKSBBQ1BJOiBTUkFUIDlGRjlBNUUwLCAwMTA4IChyMyBBTUQgICAgRkFNX0ZfMTAgICAg
ICAgIDIgQU1EICAgICAgICAgMSkKKFhFTikgQUNQSTogSFBFVCA5RkY5QTZGMCwgMDAzOCAo
cjEgNzY0ME1TIE9FTUhQRVQgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6
IElWUlMgOUZGOUE3MzAsIDAxMTAgKHIxICBBTUQgICAgIFJEODkwUyAgIDIwMjAzMSBBTUQg
ICAgICAgICAwKQooWEVOKSBBQ1BJOiBTU0RUIDlGRjlBODQwLCAwREE0IChyMSBBIE0gSSAg
UE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkKKFhFTikgU3lzdGVtIFJBTTogMjA0
NzlNQiAoMjA5NzA2NjBrQikKKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUg
MAooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDEgLT4gTm9kZSAwCihYRU4pIFNSQVQ6IFBY
TSAwIC0+IEFQSUMgMiAtPiBOb2RlIDAKKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAzIC0+
IE5vZGUgMAooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDQgLT4gTm9kZSAwCihYRU4pIFNS
QVQ6IFBYTSAwIC0+IEFQSUMgNSAtPiBOb2RlIDAKKFhFTikgU1JBVDogTm9kZSAwIFBYTSAw
IDAtYTAwMDAKKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMC1hMDAwMDAwMAooWEVO
KSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwMDAwLTU2MDAwMDAwMAooWEVOKSBOVU1BOiBB
bGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDU1ZDBhZjAwMCAtIDU1ZDBiNTAwMAooWEVOKSBO
VU1BOiBVc2luZyA4IGZvciB0aGUgaGFzaCBzaGlmdC4KKFhFTikgRG9tYWluIGhlYXAgaW5p
dGlhbGlzZWQKKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGQwMDAwMDAwLCBtYXBw
ZWQgdG8gMHhmZmZmODJjMDAwMjAxMDAwLCB1c2luZyA2MTQ0aywgdG90YWwgMTYzODRrCihY
RU4pIHZlc2FmYjogbW9kZSBpcyAxMjgweDEwMjR4MzIsIGxpbmVsZW5ndGg9NTEyMCwgZm9u
dCA4eDE2CihYRU4pIHZlc2FmYjogVHJ1ZWNvbG9yOiBzaXplPTA6ODo4OjgsIHNoaWZ0PTA6
MTY6ODowCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAwMDBmZjc4MAooWEVOKSBETUkg
cHJlc2VudC4KKFhFTikgQVBJQyBib290IHN0YXRlIGlzICd4YXBpYycKKFhFTikgVXNpbmcg
QVBJQyBkcml2ZXIgZGVmYXVsdAooWEVOKSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgw
OAooWEVOKSBBQ1BJOiBTTEVFUCBJTkZPOiBwbTF4X2NudFsxOjgwNCwxOjBdLCBwbTF4X2V2
dFsxOjgwMCwxOjBdCihYRU4pIEFDUEk6ICAgICAgICAgICAgIHdha2V1cF92ZWNbOWZmOWUw
MGNdLCB2ZWNfc2l6ZVsyMF0KKFhFTikgQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVl
MDAwMDAKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0g
ZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMwIDA6MTAgQVBJQyB2ZXJzaW9uIDE2CihYRU4p
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpCihY
RU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQooWEVOKSBQcm9jZXNz
b3IgIzIgMDoxMCBBUElDIHZlcnNpb24gMTYKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMzIDA6MTAg
QVBJQyB2ZXJzaW9uIDE2CihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGlj
X2lkWzB4MDRdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lv
biAxNgooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBl
bmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzUgMDoxMCBBUElDIHZlcnNpb24gMTYKKFhFTikg
QUNQSTogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBd
KQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgNiwgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZl
YzAwMDAwLCBHU0kgMC0yMwooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3Nb
MHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRdKQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywg
dmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUKKFhFTikgQUNQSTog
SU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKKFhF
TikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93
IGxldmVsKQooWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEFDUEk6
IElSUTIgdXNlZCBieSBvdmVycmlkZS4KKFhFTikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJy
aWRlLgooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJ
Q3MKKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MzAwIGJhc2U6IDB4ZmVkMDAwMDAKKFhFTikg
RVJTVCB0YWJsZSB3YXMgbm90IGZvdW5kCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBT
TVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BV
cyAoMCBob3RwbHVnIENQVXMpCihYRU4pIG1hcHBlZCBBUElDIHRvIGZmZmY4MmNmZmZkZmIw
MDAgKGZlZTAwMDAwKQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmNmZmZkZmEwMDAg
KGZlYzAwMDAwKQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmNmZmZkZjkwMDAgKGZl
YzIwMDAwKQooWEVOKSBJUlEgbGltaXRzOiA1NiBHU0ksIDExMTIgTVNJL01TSS1YCihYRU4p
IFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKKFhFTikg
RGV0ZWN0ZWQgMzIwMC4yMDUgTUh6IHByb2Nlc3Nvci4KKFhFTikgSW5pdGluZyBtZW1vcnkg
c2hhcmluZy4KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFi
bGVkCihYRU4pIGFsdCB0YWJsZSBmZmZmODJkMDgwMmRhZjMwIC0+IGZmZmY4MmQwODAyZGJm
NTAKKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdt
ZW50IDAwMDAgYnVzZXMgMDAgLSBmZgooWEVOKSBQQ0k6IE5vdCB1c2luZyBNQ0ZHIGZvciBz
ZWdtZW50IDAwMDAgYnVzIDAwLWZmCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNhcGFiaWxp
dHkgYmxvY2sgYXQgMHg1NAooWEVOKSBBTUQtVmk6IEFDUEkgVGFibGU6CihYRU4pIEFNRC1W
aTogIFNpZ25hdHVyZSBJVlJTCihYRU4pIEFNRC1WaTogIExlbmd0aCAweDExMAooWEVOKSBB
TUQtVmk6ICBSZXZpc2lvbiAweDEKKFhFTikgQU1ELVZpOiAgQ2hlY2tTdW0gMHhlYgooWEVO
KSBBTUQtVmk6ICBPRU1fSWQgQU1EICAKKFhFTikgQU1ELVZpOiAgT0VNX1RhYmxlX0lkIFJE
ODkwUwooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIwMzEKKFhFTikgQU1ELVZp
OiAgQ3JlYXRvcl9JZCBBTUQgCihYRU4pIEFNRC1WaTogIENyZWF0b3JfUmV2aXNpb24gMAoo
WEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6IHR5cGUgMHgxMCBmbGFncyAweDNlIGxlbiAweGUw
IGlkIDB4MgooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAw
IGZsYWdzIDAKKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAwIC0+IDB4MgooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDEwIGZsYWdzIDAKKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHhmMDAgZmxhZ3Mg
MAooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4ZjAwIC0+IDB4ZjAxCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MTggZmxhZ3MgMAooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweGUwMCBmbGFncyAw
CihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHhlMDAgLT4gMHhlMDEKKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgyOCBmbGFncyAwCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4ZDAwIGZsYWdzIDAK
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgzMCBmbGFn
cyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YzAw
IGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHg0OCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgy
IGlkIDB4YjAwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlw
ZSAweDIgaWQgMHg1MCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMHgyIGlkIDB4YTAwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeTogdHlwZSAweDIgaWQgMHg1OCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6IHR5cGUgMHgzIGlkIDB4OTAwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweDkwMCAtPiAweDkwMQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4MiBpZCAweDYwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeTogdHlwZSAweDIgaWQgMHg1MDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDYwOCBmbGFncyAwCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4ODAwIGZsYWdzIDAKKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg2MTAgZmxhZ3MgMAooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDcwMCBmbGFncyAw
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NjggZmxh
Z3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDQw
MCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlk
IDB4ODggZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MyBpZCAweDkwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+
IDB4OTIKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHg5
OCBmbGFncyAwCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg5OCAtPiAweDlhCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTAgZmxhZ3Mg
MHhkNwooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGEy
IGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHhhMyBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgy
IGlkIDB4YTQgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4NDMgaWQgMHgzMDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4
MzAwIC0+IDB4M2ZmIGFsaWFzIDB4YTQKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eTogdHlwZSAweDIgaWQgMHhhNSBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHgyIGlkIDB4YTggZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGE5IGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgxMDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweGIwIGZsYWdzIDAKKFhFTikgQU1E
LVZpOiAgRGV2X0lkIFJhbmdlOiAweGIwIC0+IDB4YjIKKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeTogdHlwZSAwIGlkIDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5OiB0eXBlIDB4NDggaWQgMCBmbGFncyAweGQ3CihYRU4pIEFNRC1WaTogSVZI
RCBTcGVjaWFsOiAwMDAwOjAwOjE0LjAgdmFyaWV0eSAweDIgaGFuZGxlIDAKKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDQ4IGlkIDAgZmxhZ3MgMAooWEVOKSBB
TUQtVmk6IElWSEQgU3BlY2lhbDogMDAwMDowMDowMC4xIHZhcmlldHkgMHgxIGhhbmRsZSAw
eDcKKFhFTikgQU1ELVZpOiBEaXNhYmxlZCBIQVAgbWVtb3J5IG1hcCBzaGFyaW5nIHdpdGgg
SU9NTVUKKFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuCihYRU4pIEkvTyB2aXJ0dWFs
aXNhdGlvbiBlbmFibGVkCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZAooWEVOKSBJbnRl
cnJ1cHQgcmVtYXBwaW5nIGVuYWJsZWQKKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAx
MAooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwCihYRU4pIEdldHRpbmcgSUQ6IDAK
KFhFTikgR2V0dGluZyBMVlQwOiA3MDAKKFhFTikgR2V0dGluZyBMVlQxOiA0MDAKKFhFTikg
ZW5hYmxlZCBFeHRJTlQgb24gQ1BVIzAKKFhFTikgRVNSIHZhbHVlIGJlZm9yZSBlbmFibGlu
ZyB2ZWN0b3I6IDB4NCAgYWZ0ZXI6IDAKKFhFTikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzCihY
RU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZAooWEVOKSBpbml0IElPX0FQSUMgSVJRcwoo
WEVOKSAgSU8tQVBJQyAoYXBpY2lkLXBpbikgNi0wLCA2LTE2LCA2LTE3LCA2LTE4LCA2LTE5
LCA2LTIwLCA2LTIxLCA2LTIyLCA2LTIzLCA3LTAsIDctMSwgNy0yLCA3LTMsIDctNCwgNy01
LCA3LTYsIDctNywgNy04LCA3LTksIDctMTAsIDctMTEsIDctMTIsIDctMTMsIDctMTQsIDct
MTUsIDctMTYsIDctMTcsIDctMTgsIDctMTksIDctMjAsIDctMjEsIDctMjIsIDctMjMsIDct
MjQsIDctMjUsIDctMjYsIDctMjcsIDctMjgsIDctMjksIDctMzAsIDctMzEgbm90IGNvbm5l
Y3RlZC4KKFhFTikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9
LTEgcGluMj0tMQooWEVOKSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1LgooWEVOKSBu
dW1iZXIgb2YgSU8tQVBJQyAjNiByZWdpc3RlcnM6IDI0LgooWEVOKSBudW1iZXIgb2YgSU8t
QVBJQyAjNyByZWdpc3RlcnM6IDMyLgooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4KKFhFTikgSU8gQVBJQyAjNi4uLi4uLgooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMDogMDYwMDAwMDAKKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMg
aWQ6IDA2CihYRU4pIC4uLi4uLi4gICAgOiBEZWxpdmVyeSBUeXBlOiAwCihYRU4pIC4uLi4u
Li4gICAgOiBMVFMgICAgICAgICAgOiAwCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3
ODAyMQooWEVOKSAuLi4uLi4uICAgICA6IG1heCByZWRpcmVjdGlvbiBlbnRyaWVzOiAwMDE3
CihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxCihYRU4pIC4uLi4uLi4g
ICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAyOiAw
NjAwMDAwMAooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNgooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMzogMDcwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAgOiBCb290IERUICAg
IDogMAooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToKKFhFTikgIE5SIExvZyBQ
aHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICAKKFhFTikgIDAw
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDAx
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzAKKFhFTikgIDAy
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjAKKFhFTikgIDAz
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzgKKFhFTikgIDA0
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjEKKFhFTikgIDA1
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDAKKFhFTikgIDA2
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDgKKFhFTikgIDA3
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTAKKFhFTikgIDA4
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTgKKFhFTikgIDA5
IDAwMSAwMSAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDAgICAgMDAKKFhFTikgIDBh
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNjgKKFhFTikgIDBi
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzAKKFhFTikgIDBj
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzgKKFhFTikgIDBk
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgODgKKFhFTikgIDBl
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgOTAKKFhFTikgIDBm
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgOTgKKFhFTikgIDEw
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDEx
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDEy
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDEz
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDE0
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDE1
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDE2
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgIDE3
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzAKKFhFTikgSU8g
QVBJQyAjNy4uLi4uLgooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDogMDcwMDAwMDAKKFhFTikg
Li4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA3CihYRU4pIC4uLi4uLi4gICAgOiBE
ZWxpdmVyeSBUeXBlOiAwCihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwCihY
RU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDFGODAyMQooWEVOKSAuLi4uLi4uICAgICA6IG1h
eCByZWRpcmVjdGlvbiBlbnRyaWVzOiAwMDFGCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGlt
cGxlbWVudGVkOiAxCihYRU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIx
CihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAyOiAwMDAwMDAwMAooWEVOKSAuLi4uLi4uICAgICA6
IGFyYml0cmF0aW9uOiAwMAooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToKKFhF
TikgIE5SIExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDog
ICAKKFhFTikgIDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDAxIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDAyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDAzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDA5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBlIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDAKKFhFTikgVXNpbmcgdmVjdG9yLWJhc2VkIGluZGV4aW5nCihYRU4pIElSUSB0byBwaW4g
bWFwcGluZ3M6CihYRU4pIElSUTI0MCAtPiAwOjIKKFhFTikgSVJRNDggLT4gMDoxCihYRU4p
IElSUTU2IC0+IDA6MwooWEVOKSBJUlEyNDEgLT4gMDo0CihYRU4pIElSUTY0IC0+IDA6NQoo
WEVOKSBJUlE3MiAtPiAwOjYKKFhFTikgSVJRODAgLT4gMDo3CihYRU4pIElSUTg4IC0+IDA6
OAooWEVOKSBJUlE5NiAtPiAwOjkKKFhFTikgSVJRMTA0IC0+IDA6MTAKKFhFTikgSVJRMTEy
IC0+IDA6MTEKKFhFTikgSVJRMTIwIC0+IDA6MTIKKFhFTikgSVJRMTM2IC0+IDA6MTMKKFhF
TikgSVJRMTQ0IC0+IDA6MTQKKFhFTikgSVJRMTUyIC0+IDA6MTUKKFhFTikgLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIGRvbmUuCihYRU4pIFVzaW5nIGxvY2FsIEFQ
SUMgdGltZXIgaW50ZXJydXB0cy4KKFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4K
KFhFTikgLi4uLi4gQ1BVIGNsb2NrIHNwZWVkIGlzIDMyMDAuMTg1NiBNSHouCihYRU4pIC4u
Li4uIGhvc3QgYnVzIGNsb2NrIHNwZWVkIGlzIDIwMC4wMTE1IE1Iei4KKFhFTikgLi4uLi4g
YnVzX3NjYWxlID0gMHhjY2Q3CihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUyLjk4Nl0gUGxh
dGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6
NTMuMDA3XSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4KKFhFTikgWzIwMTQt
MTEtMTggMTE6MjY6NTMuMDEzXSBIVk06IEFTSURzIGVuYWJsZWQuCihYRU4pIFsyMDE0LTEx
LTE4IDExOjI2OjUzLjAxOV0gU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6CihY
RU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjAyNV0gIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChO
UFQpCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjAzMV0gIC0gTGFzdCBCcmFuY2ggUmVj
b3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjAz
N10gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVAooWEVOKSBbMjAxNC0xMS0xOCAxMToy
Njo1My4wNDNdICAtIFBhdXNlLUludGVyY2VwdCBGaWx0ZXIKKFhFTikgWzIwMTQtMTEtMTgg
MTE6MjY6NTMuMDQ5XSBIVk06IFNWTSBlbmFibGVkCihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjUzLjA1Nl0gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQK
KFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuMDYyXSBIVk06IEhBUCBwYWdlIHNpemVzOiA0
a0IsIDJNQiwgMUdCCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjA2OV0gSFZNOiBQVkgg
bW9kZSBub3Qgc3VwcG9ydGVkIG9uIHRoaXMgcGxhdGZvcm0KKFhFTikgWzIwMTQtMTEtMTgg
MTE6MjY6NTMuMDk1XSBtYXNrZWQgRXh0SU5UIG9uIENQVSMxCihYRU4pIFsyMDE0LTExLTE4
IDExOjI2OjUzLjEyMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjMgooWEVOKSBbMjAxNC0xMS0x
OCAxMToyNjo1My4xNDhdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzMKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTMuMTc1XSBtYXNrZWQgRXh0SU5UIG9uIENQVSM0CihYRU4pIFsyMDE0LTEx
LTE4IDExOjI2OjUzLjIwMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjNQooWEVOKSBbMjAxNC0x
MS0xOCAxMToyNjo1My4yMDhdIEJyb3VnaHQgdXAgNiBDUFVzCihYRU4pIFsyMDE0LTExLTE4
IDExOjI2OjUzLjIxOF0gQU1ELVZpOiBGYWlsZWQgdG8gc2V0dXAgSFBFVCBNU0kgcmVtYXBw
aW5nLiBXcm9uZyBIUEVULgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My4yMjVdIEFNRC1W
aTogRmFpbGVkIHRvIHNldHVwIEhQRVQgTVNJIHJlbWFwcGluZy4gV3JvbmcgSFBFVC4KKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTMuMjMxXSBBTUQtVmk6IEZhaWxlZCB0byBzZXR1cCBI
UEVUIE1TSSByZW1hcHBpbmcuIFdyb25nIEhQRVQuCihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjUzLjIzOF0gSFBFVDogMyB0aW1lcnMgdXNhYmxlIGZvciBicm9hZGNhc3QgKDMgdG90YWwp
CihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjI2NV0gQUNQSSBzbGVlcCBtb2RlczogUzMK
KFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuMjcyXSBNQ0E6IFVzZSBodyB0aHJlc2hvbGRp
bmcgdG8gYWRqdXN0IHBvbGxpbmcgZnJlcXVlbmN5CihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjUzLjI3OF0gbWNoZWNrX3BvbGw6IE1hY2hpbmUgY2hlY2sgcG9sbGluZyB0aW1lciBzdGFy
dGVkLgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My4yODZdIFhlbm9wcm9maWxlOiBGYWls
ZWQgdG8gc2V0dXAgSUJTIExWVCBvZmZzZXQsIElCU0NUTCA9IDB4ZmZmZmZmZmYKKFhFTikg
WzIwMTQtMTEtMTggMTE6MjY6NTMuMjkzXSAqKiogTE9BRElORyBET01BSU4gMCAqKioKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTMuNDYxXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBw
YWRkcj0weDEwMDAwMDAgbWVtc3o9MHgxMDY0MDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjUzLjQ2OV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgyMjAwMDAwIG1lbXN6
PTB4MTA2MDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjQ3Nl0gZWxmX3BhcnNlX2Jp
bmFyeTogcGhkcjogcGFkZHI9MHgyMzA2MDAwIG1lbXN6PTB4MTQyODAKKFhFTikgWzIwMTQt
MTEtMTggMTE6MjY6NTMuNDgzXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDIz
MWIwMDAgbWVtc3o9MHgxMTQwMDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjQ5MV0g
ZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5OiAweDEwMDAwMDAgLT4gMHgzNDViMDAwCihYRU4p
IFsyMDE0LTExLTE4IDExOjI2OjUzLjQ5OF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9P
UyA9ICJsaW51eCIKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuNTA2XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42IgooWEVOKSBbMjAxNC0xMS0xOCAxMToy
Njo1My41MTRdIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVOX1ZFUlNJT04gPSAieGVuLTMuMCIK
KFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuNTIxXSBlbGZfeGVuX3BhcnNlX25vdGU6IFZJ
UlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1
My41MjldIGVsZl94ZW5fcGFyc2Vfbm90ZTogRU5UUlkgPSAweGZmZmZmZmZmODIzMWIxZjAK
KFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuNTM3XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZ
UEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZmZjgxMDAxMDAwCihYRU4pIFsyMDE0LTExLTE4IDEx
OjI2OjUzLjU0NV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIhd3JpdGFibGVf
cGFnZV90YWJsZXN8cGFlX3BnZGlyX2Fib3ZlXzRnYnx3cml0YWJsZV9kZXNjcmlwdG9yX3Rh
Ymxlc3xhdXRvX3RyYW5zbGF0ZWRfcGh5c21hcHxzdXBlcnZpc29yX21vZGVfa2VybmVsIgoo
WEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My41NjFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VQ
UE9SVEVEX0ZFQVRVUkVTID0gMHg5MGQKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuNTY5
XSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTMuNTc4XSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURFUiA9ICJnZW5lcmlj
IgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My41ODZdIGVsZl94ZW5fcGFyc2Vfbm90ZTog
dW5rbm93biB4ZW4gZWxmIG5vdGUgKDB4ZCkKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMu
NTk1XSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxCihYRU4pIFsy
MDE0LTExLTE4IDExOjI2OjUzLjYwNF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBNT0RfU1RBUlRf
UEZOID0gMHgxCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjYxM10gZWxmX3hlbl9wYXJz
ZV9ub3RlOiBIVl9TVEFSVF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDAKKFhFTikgWzIwMTQt
MTEtMTggMTE6MjY6NTMuNjIyXSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9
IDB4MAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My42MzFdIGVsZl94ZW5fYWRkcl9jYWxj
X2NoZWNrOiBhZGRyZXNzZXM6CihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjY0MF0gICAg
IHZpcnRfYmFzZSAgICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTMuNjUwXSAgICAgZWxmX3BhZGRyX29mZnNldCA9IDB4MAooWEVOKSBbMjAx
NC0xMS0xOCAxMToyNjo1My42NTldICAgICB2aXJ0X29mZnNldCAgICAgID0gMHhmZmZmZmZm
ZjgwMDAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjY2OV0gICAgIHZpcnRfa3N0
YXJ0ICAgICAgPSAweGZmZmZmZmZmODEwMDAwMDAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6
NTMuNjc5XSAgICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZmZmZmZmY4MzQ1YjAwMAooWEVO
KSBbMjAxNC0xMS0xOCAxMToyNjo1My42ODldICAgICB2aXJ0X2VudHJ5ICAgICAgID0gMHhm
ZmZmZmZmZjgyMzFiMWYwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjY5OF0gICAgIHAy
bV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYKKFhFTikgWzIwMTQtMTEtMTgg
MTE6MjY6NTMuNzA4XSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMgooWEVO
KSBbMjAxNC0xMS0xOCAxMToyNjo1My43MTldICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUs
IGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+IDB4MzQ1YjAwMAooWEVOKSBbMjAxNC0xMS0xOCAx
MToyNjo1My43MjldIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgWzIwMTQt
MTEtMTggMTE6MjY6NTMuNzM5XSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDU0ODAwMDAwMC0+
MDAwMDAwMDU0YzAwMDAwMCAoMzcyOTM4IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkKKFhFTikg
WzIwMTQtMTEtMTggMTE6MjY6NTMuNzUxXSAgSW5pdC4gcmFtZGlzazogMDAwMDAwMDU1ZjBj
YTAwMC0+MDAwMDAwMDU1ZmZmZmEwMAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My43NjFd
IFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1
My43NzJdICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgzNDVi
MDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjc4M10gIEluaXQuIHJhbWRpc2s6IDAw
MDAwMDAwMDAwMDAwMDAtPjAwMDAwMDAwMDAwMDAwMDAKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTMuNzkzXSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4MzQ1YjAwMC0+ZmZmZmZmZmY4
Mzc1YjAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My44MDRdICBTdGFydCBpbmZvOiAg
ICBmZmZmZmZmZjgzNzViMDAwLT5mZmZmZmZmZjgzNzViNGI0CihYRU4pIFsyMDE0LTExLTE4
IDExOjI2OjUzLjgxNV0gIFBhZ2UgdGFibGVzOiAgIGZmZmZmZmZmODM3NWMwMDAtPmZmZmZm
ZmZmODM3N2IwMDAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuODI2XSAgQm9vdCBzdGFj
azogICAgZmZmZmZmZmY4Mzc3YjAwMC0+ZmZmZmZmZmY4Mzc3YzAwMAooWEVOKSBbMjAxNC0x
MS0xOCAxMToyNjo1My44MzddICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5m
ZmZmZmZmZjgzODAwMDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjg0OF0gIEVOVFJZ
IEFERFJFU1M6IGZmZmZmZmZmODIzMWIxZjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMu
ODYwXSBEb20wIGhhcyBtYXhpbXVtIDYgVkNQVXMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6
NTMuODcxXSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMCBhdCAweGZmZmZmZmZmODEwMDAwMDAg
LT4gMHhmZmZmZmZmZjgyMDY0MDAwCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjUzLjg4OV0g
ZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgyMjAwMDAwIC0+IDB4ZmZm
ZmZmZmY4MjMwNjAwMAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1My45MDBdIGVsZl9sb2Fk
X2JpbmFyeTogcGhkciAyIGF0IDB4ZmZmZmZmZmY4MjMwNjAwMCAtPiAweGZmZmZmZmZmODIz
MWEyODAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTMuOTEyXSBlbGZfbG9hZF9iaW5hcnk6
IHBoZHIgMyBhdCAweGZmZmZmZmZmODIzMWIwMDAgLT4gMHhmZmZmZmZmZjgyNDIzMDAwCihY
RU4pIFsyMDE0LTExLTE4IDExOjI2OjU0LjMyN10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTUuMDc0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAwLCB0eXBlID0gMHg2LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4wODVdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MiwgdHlwZSA9IDB4
Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuMDk3XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDEwLCB0eXBlID0gMHgyLCByb290IHRhYmxlID0g
MHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0x
MS0xOCAxMToyNjo1NS4xMTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MTgsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU1LjEy
Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyOCwgdHlw
ZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuMTM1XSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDMwLCB0eXBlID0gMHgyLCByb290IHRh
YmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBb
MjAxNC0xMS0xOCAxMToyNjo1NS4xNDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4NDgsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjU1LjE2MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1
MCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuMTczXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDU4LCB0eXBlID0gMHgyLCBy
b290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwoo
WEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4xODddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4NjAsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0
ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4
IDExOjI2OjU1LjIwMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHg2OCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuMjEzXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDg4LCB0eXBlID0g
MHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4yMjddIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4OTAsIHR5cGUgPSAweDcsIHJvb3QgdGFibGUg
PSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4pIFsyMDE0
LTExLTE4IDExOjI2OjU1LjI0MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg5MiwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUu
MjU1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDk4LCB0
eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4yNjldIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4OWEsIHR5cGUgPSAweDcsIHJvb3Qg
dGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzCihYRU4p
IFsyMDE0LTExLTE4IDExOjI2OjU1LjI4M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHhhMCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRi
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTUuMjk4XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eGEyLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4zMTJdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTMsIHR5cGUgPSAweDcs
IHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
CihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU1LjMyN10gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhNCwgdHlwZSA9IDB4NSwgcm9vdCB0YWJsZSA9IDB4
NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTUuMzQyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweGE1LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1NS4zNTdd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTgsIHR5cGUg
PSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU1LjM3Ml0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJs
ZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTUuMzg3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweGIyLCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1NGVlZGIwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1
NS40MDNdIEFNRC1WaTogU2tpcHBpbmcgaG9zdCBicmlkZ2UgMDAwMDowMDoxOC4wCihYRU4p
IFsyMDE0LTExLTE4IDExOjI2OjU1LjQxOF0gQU1ELVZpOiBTa2lwcGluZyBob3N0IGJyaWRn
ZSAwMDAwOjAwOjE4LjEKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNDMzXSBBTUQtVmk6
IFNraXBwaW5nIGhvc3QgYnJpZGdlIDAwMDA6MDA6MTguMgooWEVOKSBbMjAxNC0xMS0xOCAx
MToyNjo1NS40NDhdIEFNRC1WaTogU2tpcHBpbmcgaG9zdCBicmlkZ2UgMDAwMDowMDoxOC4z
CihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU1LjQ2M10gQU1ELVZpOiBTa2lwcGluZyBob3N0
IGJyaWRnZSAwMDAwOjAwOjE4LjQKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNDc4XSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDQwMCwgdHlwZSA9
IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNDkzXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDUwMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJs
ZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTUuNTA5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDYwOCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6
NTUuNTI1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDYx
MCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNTQxXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDcwMCwgdHlwZSA9IDB4MSwg
cm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMK
KFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNTU3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDgwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4
NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTUuNTczXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDkwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNTkw
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwMSwgdHlw
ZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNjA2XSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEwMCwgdHlwZSA9IDB4MSwgcm9vdCB0
YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikg
WzIwMTQtMTEtMTggMTE6MjY6NTUuNjIzXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweGIwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRi
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTUuNjQwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eGMwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNjU3XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGQwMCwgdHlwZSA9IDB4
MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNjc1XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGUwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9
IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQt
MTEtMTggMTE6MjY6NTUuNjkyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweGUwMSwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUu
NzEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGYwMCwg
dHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNzI4XSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGYwMSwgdHlwZSA9IDB4MSwgcm9v
dCB0YWJsZSA9IDB4NTRlZWRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTUuNzUxXSBTY3J1YmJpbmcgRnJlZSBSQU0gb24gMSBu
b2RlcyB1c2luZyA2IENQVXMKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTUuODYxXSAuLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuCihYRU4pIFsyMDE0LTExLTE4IDExOjI2
OjU4Ljk1NF0gSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQw
MDAgcGFnZXMuCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU4Ljk3MV0gU3RkLiBMb2dsZXZl
bDogQWxsCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU4Ljk4OV0gR3Vlc3QgTG9nbGV2ZWw6
IEFsbAooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1OS4wMDZdIFhlbiBpcyByZWxpbnF1aXNo
aW5nIFZHQSBjb25zb2xlLgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1OS4xMDhdICoqKiBT
ZXJpYWwgaW5wdXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0
Y2ggaW5wdXQgdG8gWGVuKQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1OS4xMDldIEZyZWVk
IDI4NGtCIGluaXQgbWVtb3J5LgooWEVOKSBbMjAxNC0xMS0xOCAxMToyNjo1OS4yNjFdIElP
QVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg2MCAtPiBJUlEgOSBN
b2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU5LjI4M10gdHJhcHMu
YzoyNTc5OmQwdjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjE4XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAwLjAKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAw
LjIKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjE5XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjAyLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIwXSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjAzLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIwXSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjA1LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIwXSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjA2LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTku
NjIxXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjA5LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTkuNjIxXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBhLjAKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTkuNjIxXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBiLjAKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjIyXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBjLjAKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIyXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBk
LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIyXSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjExLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIzXSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjEyLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIzXSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjEyLjIKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjIzXSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjEzLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTku
NjI0XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjEzLjIKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTkuNjI0XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjAKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTkuNjI0XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjIKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjI1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjMKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0
LjQKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI1XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjE0LjUKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI2XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjE1LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI2XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjE2LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI2XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjE2LjIKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTku
NjI2XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTkuNjI3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjEKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTkuNjI3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjIKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjI3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjMKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4
LjQKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI4XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjBmOjAwLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjI4XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjBmOjAwLjEKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjM2XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjBlOjAwLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjM2XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjBlOjAwLjEKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTku
NjQzXSBQQ0kgYWRkIGRldmljZSAwMDAwOjBkOjAwLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTkuNjUwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjBjOjAwLjAKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTkuNjU2XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBiOjAwLjAKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjYzXSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjAKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjcwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjA5OjAw
LjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjcwXSBQQ0kgYWRkIGRldmljZSAwMDAw
OjA5OjAwLjEKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjc2XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjA1OjAwLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjgzXSBQQ0kgYWRk
IGRldmljZSAwMDAwOjA2OjAxLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjgzXSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjA2OjAyLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTku
Njg0XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA4OjAwLjAKKFhFTikgWzIwMTQtMTEtMTggMTE6
MjY6NTkuNjkwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjA3OjAwLjAKKFhFTikgWzIwMTQtMTEt
MTggMTE6MjY6NTkuNjkwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjAKKFhFTikgWzIw
MTQtMTEtMTggMTE6MjY6NTkuNjk3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAzOjA2LjAKKFhF
TikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNjk3XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNi0xMyAtPiAweDg4IC0+IElSUSAxMyBNb2RlOjAgQWN0aXZlOjApCihYRU4p
IFsyMDE0LTExLTE4IDExOjI2OjU5LjcxMl0gUENJOiBVc2luZyBNQ0ZHIGZvciBzZWdtZW50
IDAwMDAgYnVzIDAwLWZmCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU5LjcwOV0gSU9BUElD
WzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOCAtPiAweDU4IC0+IElSUSA4IE1vZGU6
MCBBY3RpdmU6MCkKKFhFTikgWzIwMTQtMTEtMTggMTE6MjY6NTkuNzIzXSBJT0FQSUNbMF06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOCAtPiAweGI4IC0+IElSUSAxOCBNb2RlOjEg
QWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDExOjI2OjU5Ljc5OF0gSU9BUElDWzBdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTcgLT4gMHhjMCAtPiBJUlEgMTcgTW9kZToxIEFj
dGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNzowMC4wMjldIElPQVBJQ1sxXTogU2V0
IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI5IC0+IDB4YzggLT4gSVJRIDUzIE1vZGU6MSBBY3Rp
dmU6MSkKKFhFTikgWzIwMTQtMTEtMTggMTE6Mjc6MDAuMDI5XSBJT0FQSUNbMV06IFNldCBQ
Q0kgcm91dGluZyBlbnRyeSAoNy0yNCAtPiAweGQwIC0+IElSUSA0OCBNb2RlOjEgQWN0aXZl
OjEpCihYRU4pIFsyMDE0LTExLTE4IDExOjI3OjAwLjAyOV0gSU9BUElDWzFdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDctMzAgLT4gMHhkOCAtPiBJUlEgNTQgTW9kZToxIEFjdGl2ZTox
KQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNzowMC4wMjldIElPQVBJQ1sxXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg3LTEyIC0+IDB4MjEgLT4gSVJRIDM2IE1vZGU6MSBBY3RpdmU6MSkK
KFhFTikgWzIwMTQtMTEtMTggMTE6Mjc6MDAuMDI5XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy0xMyAtPiAweDI5IC0+IElSUSAzNyBNb2RlOjEgQWN0aXZlOjEpCihY
RU4pIFsyMDE0LTExLTE4IDExOjI3OjAwLjAyOV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDctMTYgLT4gMHgzMSAtPiBJUlEgNDAgTW9kZToxIEFjdGl2ZToxKQooWEVO
KSBbMjAxNC0xMS0xOCAxMToyNzowMC4wOTZdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5n
IGVudHJ5ICg3LTI4IC0+IDB4MzkgLT4gSVJRIDUyIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikg
WzIwMTQtMTEtMTggMTE6Mjc6MDAuMDk4XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNi0xNiAtPiAweDg5IC0+IElSUSAxNiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsy
MDE0LTExLTE4IDExOjI3OjAwLjA5OV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDctMTQgLT4gMHhhOSAtPiBJUlEgMzggTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAx
NC0xMS0xOCAxMToyNzowMC4xNDhdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg2LTIyIC0+IDB4YjkgLT4gSVJRIDIyIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQt
MTEtMTggMTE6Mjc6MDIuMjE5XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAo
Ny05IC0+IDB4YzEgLT4gSVJRIDMzIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEt
MTggMTE6Mjc6MDIuMjQ1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy04
IC0+IDB4YzkgLT4gSVJRIDMyIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTgg
MTE6Mjc6MDIuMjcyXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAt
PiAweGQxIC0+IElSUSA0NyBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDEx
OjI3OjA0LjM1MV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNSAtPiAw
eGQ5IC0+IElSUSAyOSBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDExOjI3
OjA0LjM5NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNCAtPiAweDIy
IC0+IElSUSAyOCBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDE0LTExLTE4IDExOjI3OjA0
LjUzMF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTkgLT4gMHgyYSAt
PiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNzowNC41
MzhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjI3OjA0LjY5M10gSU9BUElDWzFd
OiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjIgLT4gMHg3MiAtPiBJUlEgNDYgTW9kZTox
IEFjdGl2ZToxKQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNzowNC43MjldIElPQVBJQ1sxXTog
U2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI3IC0+IDB4OGEgLT4gSVJRIDUxIE1vZGU6MSBB
Y3RpdmU6MSkKKFhFTikgWzIwMTQtMTEtMTggMTE6Mjc6MDUuMzI2XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xIC0+IDB4OWEgLT4gSVJRIDI1IE1vZGU6MSBBY3Rp
dmU6MSkKKFhFTikgWzIwMTQtMTEtMTggMTE6Mjc6MTMuNzA5XSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMToyNzoyMy43MDldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEx
OjI3OjMzLjcxMF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mjc6NDMuNzEwXSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMToyNzo1My43MTBdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDExOjI4OjAzLjcxMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTE6Mjg6MTMuNzExXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMToyODoyMy43MTFd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjI4OjMzLjcxMV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTE6Mjg6NDMuNzEyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMToyODo1My43MTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjI5OjAzLjcx
Ml0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mjk6MTMuNzEyXSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMToyOToyMy43MTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDExOjI5OjMzLjcxM10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mjk6NDMu
NzEzXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMToyOTo1My43MTNdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDExOjMwOjAzLjcxM10gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTE6MzA6MTMuNzE0XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozMDoy
My43MTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjMwOjMzLjcxNF0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzA6NDMuNzE0XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMTozMDo1My43MTRdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjMx
OjAzLjcxNF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzE6MTMuNzE0XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozMToyMy43MTRdIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDExOjMxOjMzLjcxNV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6
MzE6NDMuNzE1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozMTo1My43MTVdIC0t
TUFSSy0tCihkMSkgWzIwMTQtMTEtMTggMTE6MzE6NTkuODM2XSBtYXBwaW5nIGtlcm5lbCBp
bnRvIHBoeXNpY2FsIG1lbW9yeQooZDEpIFsyMDE0LTExLTE4IDExOjMxOjU5LjgzN10gYWJv
dXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzI6MDAuMDk3XSB0
cmFwcy5jOjI1Nzk6ZDF2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAw
MDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVO
KSBbMjAxNC0xMS0xOCAxMTozMjowMy43MTVdIC0tTUFSSy0tCihkMikgWzIwMTQtMTEtMTgg
MTE6MzI6MDUuOTM2XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDIp
IFsyMDE0LTExLTE4IDExOjMyOjA1LjkzNl0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhF
TikgWzIwMTQtMTEtMTggMTE6MzI6MDYuMDEyXSB0cmFwcy5jOjI1Nzk6ZDJ2MCBEb21haW4g
YXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAw
MDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooZDMpIFsyMDE0LTExLTE4IDExOjMyOjExLjc2
MV0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKKGQzKSBbMjAxNC0xMS0x
OCAxMTozMjoxMS43NjFdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTEx
LTE4IDExOjMyOjExLjg1MV0gdHJhcHMuYzoyNTc5OmQzdjAgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAw
MDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzI6MTMuNzE2XSAtLU1BUkst
LQooZDQpIFsyMDE0LTExLTE4IDExOjMyOjE3Ljk3NF0gbWFwcGluZyBrZXJuZWwgaW50byBw
aHlzaWNhbCBtZW1vcnkKKGQ0KSBbMjAxNC0xMS0xOCAxMTozMjoxNy45NzRdIGFib3V0IHRv
IGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDExOjMyOjE4LjA1MF0gdHJhcHMu
YzoyNTc5OmQ0djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIw
MTQtMTEtMTggMTE6MzI6MjAuNzIzXSBncmFudF90YWJsZS5jOjMwNTpkMHYwIEluY3JlYXNl
ZCBtYXB0cmFjayBzaXplIHRvIDIgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE4IDExOjMyOjIz
LjcxNl0gLS1NQVJLLS0KKGQ1KSBbMjAxNC0xMS0xOCAxMTozMjoyMy43ODNdIG1hcHBpbmcg
a2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkNSkgWzIwMTQtMTEtMTggMTE6MzI6MjMu
NzgzXSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMTozMjoy
My44NTldIHRyYXBzLmM6MjU3OTpkNXYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZm
ZmYuCihkNikgWzIwMTQtMTEtMTggMTE6MzI6MjkuNjExXSBtYXBwaW5nIGtlcm5lbCBpbnRv
IHBoeXNpY2FsIG1lbW9yeQooZDYpIFsyMDE0LTExLTE4IDExOjMyOjI5LjYxMV0gYWJvdXQg
dG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzI6MjkuNzI3XSB0cmFw
cy5jOjI1Nzk6ZDZ2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQg
ZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBb
MjAxNC0xMS0xOCAxMTozMjozMy4xMzddIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVh
c2VkIG1hcHRyYWNrIHNpemUgdG8gMyBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTggMTE6MzI6
MzMuMTk4XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXpl
IHRvIDQgZnJhbWVzCihYRU4pIFsyMDE0LTExLTE4IDExOjMyOjMzLjcxNl0gLS1NQVJLLS0K
KGQ3KSBbMjAxNC0xMS0xOCAxMTozMjozNS42MzldIG1hcHBpbmcga2VybmVsIGludG8gcGh5
c2ljYWwgbWVtb3J5CihkNykgWzIwMTQtMTEtMTggMTE6MzI6MzUuNjM5XSBhYm91dCB0byBn
ZXQgc3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMTozMjozNS43MTNdIHRyYXBzLmM6
MjU3OTpkN3YwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9t
IDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihkOCkgWzIwMTQt
MTEtMTggMTE6MzI6NDEuNTE3XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9y
eQooZDgpIFsyMDE0LTExLTE4IDExOjMyOjQxLjUxN10gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQu
Li4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzI6NDEuNTkzXSB0cmFwcy5jOjI1Nzk6ZDh2MCBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAw
MDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xOCAxMToz
Mjo0My43MTZdIC0tTUFSSy0tCihkOSkgWzIwMTQtMTEtMTggMTE6MzI6NDguNDAzXSBtYXBw
aW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDkpIFsyMDE0LTExLTE4IDExOjMy
OjQ4LjQwM10gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTE6
MzI6NDguNDkyXSB0cmFwcy5jOjI1Nzk6ZDl2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAw
MDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAw
MDBmZmZmLgooWEVOKSBbMjAxNC0xMS0xOCAxMTozMjo1My43MTddIC0tTUFSSy0tCihkMTAp
IFsyMDE0LTExLTE4IDExOjMyOjU0LjMxNF0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNh
bCBtZW1vcnkKKGQxMCkgWzIwMTQtMTEtMTggMTE6MzI6NTQuMzE0XSBhYm91dCB0byBnZXQg
c3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMTozMjo1NC4zOTldIHRyYXBzLmM6MjU3
OTpkMTB2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAw
eDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0x
MS0xOCAxMTozMjo1Ni4xNzBdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1h
cHRyYWNrIHNpemUgdG8gNSBmcmFtZXMKKGQxMSkgWzIwMTQtMTEtMTggMTE6MzM6MDAuMzgz
XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQooZDExKSBbMjAxNC0xMS0x
OCAxMTozMzowMC4zODNdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTEx
LTE4IDExOjMzOjAwLjQ4Nl0gdHJhcHMuYzoyNTc5OmQxMXYwIERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAw
MDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDE0LTExLTE4IDExOjMzOjAzLjcxN10gLS1NQVJL
LS0KKGQxMikgWzIwMTQtMTEtMTggMTE6MzM6MDYuNDI2XSBtYXBwaW5nIGtlcm5lbCBpbnRv
IHBoeXNpY2FsIG1lbW9yeQooZDEyKSBbMjAxNC0xMS0xOCAxMTozMzowNi40MjZdIGFib3V0
IHRvIGdldCBzdGFydGVkLi4uCihYRU4pIFsyMDE0LTExLTE4IDExOjMzOjA2LjUxOF0gdHJh
cHMuYzoyNTc5OmQxMnYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4p
IFsyMDE0LTExLTE4IDExOjMzOjEyLjYzMF0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweGE0LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTgg
MTE6MzM6MTIuNjMwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweGE0LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0gMHg1MTc2ZGIwMDAsIGRvbWFpbiA9
IDEzLCBwYWdpbmcgbW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MTIuNjMwXSBB
TUQtVmk6IFJlLWFzc2lnbiAwMDAwOjAzOjA2LjAgZnJvbSBkb20wIHRvIGRvbTEzCihkMTMp
IFsyMDE0LTExLTE4IDExOjMzOjEyLjYzN10gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNh
bCBtZW1vcnkKKGQxMykgWzIwMTQtMTEtMTggMTE6MzM6MTIuNjM3XSBhYm91dCB0byBnZXQg
c3RhcnRlZC4uLgooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzoxMi44NjFdIHRyYXBzLmM6MjU3
OTpkMTN2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAw
eDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxNC0x
MS0xOCAxMTozMzoxMy43MTddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjMzOjE4
LjYyOF0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0
byA2IGZyYW1lcwooZDE0KSBbMjAxNC0xMS0xOCAxMTozMzoxOC44NzddIG1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5CihkMTQpIFsyMDE0LTExLTE4IDExOjMzOjE4Ljg3
N10gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MTgu
OTY3XSB0cmFwcy5jOjI1Nzk6ZDE0djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZm
Zi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MjMuNzE3XSAtLU1BUkstLQooZDE1KSBbMjAx
NC0xMS0xOCAxMTozMzoyNC45NzRdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVt
b3J5CihkMTUpIFsyMDE0LTExLTE4IDExOjMzOjI0Ljk3NF0gYWJvdXQgdG8gZ2V0IHN0YXJ0
ZWQuLi4KKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MjUuMDY2XSB0cmFwcy5jOjI1Nzk6ZDE1
djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAw
MDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTQtMTEtMTgg
MTE6MzM6MzIuODk0XSBpby5jOjU1MDogZDE2OiBiaW5kOiBtX2dzaT0zNyBnX2dzaT0zNiBk
ZXY9MDAuMDAuNSBpbnR4PTAgZmZmZjgzMDUwODVmZjUyOAooWEVOKSBbMjAxNC0xMS0xOCAx
MTozMzozMy4yODhdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHg4MDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzozMy4yODhd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ODAwLCB0eXBl
ID0gMHgxLCByb290IHRhYmxlID0gMHgzZmFiMWQwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcg
bW9kZSA9IDMKKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MzMuMjg4XSBBTUQtVmk6IFJlLWFz
c2lnbiAwMDAwOjA4OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE2CihYRU4pIFsyMDE0LTExLTE4
IDExOjMzOjMzLjcxN10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MzQuMzQx
XSBpby5jOjU1MDogZDE2OiBiaW5kOiBtX2dzaT00NyBnX2dzaT00MCBkZXY9MDAuMDAuNiBp
bnR4PTAgZmZmZjgzMDUwODVmZmQyOAooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNDZd
IEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHhhMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMwooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNDZdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTAwLCB0eXBlID0gMHgxLCByb290
IHRhYmxlID0gMHgzZmFiMWQwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcgbW9kZSA9IDMKKFhF
TikgWzIwMTQtMTEtMTggMTE6MzM6MzQuMzQ2XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBh
OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE2CihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjM1
N10gSFZNIExvYWRlcgooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNTddIERldGVjdGVk
IFhlbiB2NC41LjAtcmMKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuMzU3XSBYZW5idXMg
cmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgMQooZDE2KSBbMjAxNC0xMS0xOCAx
MTozMzozNC4zNTddIFN5c3RlbSByZXF1ZXN0ZWQgU2VhQklPUwooZDE2KSBbMjAxNC0xMS0x
OCAxMTozMzozNC4zNTddIENQVSBzcGVlZCBpcyAzMjAwIE1IegooZDE2KSBbMjAxNC0xMS0x
OCAxMTozMzozNC4zNThdIFJlbG9jYXRpbmcgZ3Vlc3QgbWVtb3J5IGZvciBsb3dtZW0gTU1J
TyBzcGFjZSBkaXNhYmxlZAooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNThdIGlycS5j
OjI3MDogRG9tMTYgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQooZDE2KSBbMjAxNC0xMS0x
OCAxMTozMzozNC4zNThdIFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1CihYRU4pIFsy
MDE0LTExLTE4IDExOjMzOjM0LjM1OF0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAxIGNo
YW5nZWQgMCAtPiAxMAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNThdIFBDSS1JU0Eg
bGluayAxIHJvdXRlZCB0byBJUlExMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzozNC4zNThd
IGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTEKKGQxNikgWzIw
MTQtMTEtMTggMTE6MzM6MzQuMzU4XSBQQ0ktSVNBIGxpbmsgMiByb3V0ZWQgdG8gSVJRMTEK
KFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MzQuMzU5XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBs
aW5rIDMgY2hhbmdlZCAwIC0+IDUKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuMzU5XSBQ
Q0ktSVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzoz
NC4zNzVdIHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1CihkMTYpIFsyMDE0LTExLTE4IDExOjMz
OjM0LjM4MV0gcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihkMTYpIFsyMDE0LTExLTE4IDEx
OjMzOjM0LjM4Nl0gcGNpIGRldiAwMjowIElOVEEtPklSUTExCihkMTYpIFsyMDE0LTExLTE4
IDExOjMzOjM0LjM5N10gcGNpIGRldiAwNDowIElOVEEtPklSUTUKKGQxNikgWzIwMTQtMTEt
MTggMTE6MzM6MzQuNDAzXSBwY2kgZGV2IDA1OjAgSU5UQS0+SVJRMTAKKGQxNikgWzIwMTQt
MTEtMTggMTE6MzM6MzQuNDA5XSBwY2kgZGV2IDA2OjAgSU5UQS0+SVJRMTEKKGQxNikgWzIw
MTQtMTEtMTggMTE6MzM6MzQuNDU1XSBObyBSQU0gaW4gaGlnaCBtZW1vcnk7IHNldHRpbmcg
aGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDAKKGQxNikgWzIwMTQtMTEtMTgg
MTE6MzM6MzQuNDU1XSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAyMDAwMDAwOiAwZjAw
MDAwMDgKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNDU3XSBwY2kgZGV2IDAyOjAgYmFy
IDE0IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6
MzQuNDYwXSBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMjAwMDAwOiAwZjMwMDAwMDQK
KFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNDYwXSBtZW1vcnlfbWFwOmFkZDogZG9tMTYg
Z2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDAKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQu
NDY2XSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUgMDAwMDQwMDAwOiAwZjMyMDAwMDAKKGQx
NikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNDY4XSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUg
MDAwMDIwMDAwOiAwZjMyNDAwMDAKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNDY4XSBw
Y2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEwMDAwOiAwZjMyNjAwMDAKKGQxNikgWzIw
MTQtMTEtMTggMTE6MzM6MzQuNDY5XSBwY2kgZGV2IDA1OjAgYmFyIDEwIHNpemUgMDAwMDAy
MDAwOiAwZjMyNzAwMDQKKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNDY5XSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihkMTYpIFsyMDE0LTEx
LTE4IDExOjMzOjM0LjQ3Nl0gcGNpIGRldiAwMzowIGJhciAxNCBzaXplIDAwMDAwMTAwMDog
MGYzMjcyMDAwCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjQ3Nl0gcGNpIGRldiAwMjow
IGJhciAxMCBzaXplIDAwMDAwMDEwMDogMDAwMDBjMDAxCihkMTYpIFsyMDE0LTExLTE4IDEx
OjMzOjM0LjQ3OV0gcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDA0MDogMDAwMDBj
MTAxCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjQ4Ml0gcGNpIGRldiAwMToyIGJhciAy
MCBzaXplIDAwMDAwMDAyMDogMDAwMDBjMTQxCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0
LjQ4NF0gcGNpIGRldiAwMToxIGJhciAyMCBzaXplIDAwMDAwMDAxMDogMDAwMDBjMTYxCihk
MTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjQ4N10gTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlz
YXRpb246CihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjUwOV0gIC0gQ1BVMCAuLi4gNDgt
Yml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUu
CihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjUzMV0gIC0gQ1BVMSAuLi4gNDgtYml0IHBo
eXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYp
IFsyMDE0LTExLTE4IDExOjMzOjM0LjU1N10gIC0gQ1BVMiAuLi4gNDgtYml0IHBoeXMgLi4u
IGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0
LTExLTE4IDExOjMzOjM0LjU3OF0gIC0gQ1BVMyAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVk
IE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuCihkMTYpIFsyMDE0LTExLTE4
IDExOjMzOjM0LjU3OF0gVGVzdGluZyBIVk0gZW52aXJvbm1lbnQ6CihkMTYpIFsyMDE0LTEx
LTE4IDExOjMzOjM0LjU4N10gIC0gUkVQIElOU0IgYWNyb3NzIHBhZ2UgYm91bmRhcmllcyAu
Li4gcGFzc2VkCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjU5MV0gIC0gR1MgYmFzZSBN
U1JzIGFuZCBTV0FQR1MgLi4uIHBhc3NlZAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC41
OTFdIFBhc3NlZCAyIG9mIDIgdGVzdHMKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTkx
XSBXcml0aW5nIFNNQklPUyB0YWJsZXMgLi4uCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0
LjU5Ml0gTG9hZGluZyBTZWFCSU9TIC4uLgooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC41
OTJdIENyZWF0aW5nIE1QIHRhYmxlcyAuLi4KKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQu
NTkyXSBMb2FkaW5nIEFDUEkgLi4uCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjU5M10g
dm04NiBUU1MgYXQgZmMwMGEyMDAKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk0XSBC
SU9TIG1hcDoKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk0XSAgMTAwMDAtMTAwZDM6
IFNjcmF0Y2ggc3BhY2UKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk0XSAgYzAwMDAt
ZmZmZmY6IE1haW4gQklPUwooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC41OTRdIEU4MjAg
dGFibGU6CihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjU5NF0gIFswMF06IDAwMDAwMDAw
OjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJBTQooZDE2KSBbMjAxNC0xMS0xOCAx
MTozMzozNC41OTRdICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGMw
MDAwCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjU5NF0gIFswMV06IDAwMDAwMDAwOjAw
MGMwMDAwIC0gMDAwMDAwMDA6MDAxMDAwMDA6IFJFU0VSVkVECihkMTYpIFsyMDE0LTExLTE4
IDExOjMzOjM0LjU5NF0gIFswMl06IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAwMDA6M2Y4
MDAwMDA6IFJBTQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC41OTRdICBIT0xFOiAwMDAw
MDAwMDozZjgwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwCihkMTYpIFsyMDE0LTExLTE4IDEx
OjMzOjM0LjU5NF0gIFswM106IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAwMDAwMDE6MDAwMDAw
MDA6IFJFU0VSVkVECihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjU5NV0gSW52b2tpbmcg
U2VhQklPUyAuLi4KKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk3XSBTZWFCSU9TICh2
ZXJzaW9uIHJlbC0xLjcuNS0wLWdlNTE0ODhjLTIwMTQxMTE4XzEyMTE0NS1zZXJ2ZWVyc3Rl
cnRqZSkKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk3XSAKKGQxNikgWzIwMTQtMTEt
MTggMTE6MzM6MzQuNTk3XSBGb3VuZCBYZW4gaHlwZXJ2aXNvciBzaWduYXR1cmUgYXQgNDAw
MDAwMDAKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk4XSBSdW5uaW5nIG9uIFFFTVUg
KGk0NDBmeCkKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNTk4XSB4ZW46IGNvcHkgZTgy
MC4uLgooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC41OThdIFJlbG9jYXRpbmcgaW5pdCBm
cm9tIDB4MDAwZGY2MjkgdG8gMHgzZjdhZTYwMCAoc2l6ZSA3MTk5NSkKKGQxNikgWzIwMTQt
MTEtMTggMTE6MzM6MzQuNjAwXSBDUFUgTWh6PTMyMDEKKGQxNikgWzIwMTQtMTEtMTggMTE6
MzM6MzQuNjA2XSBGb3VuZCAxMCBQQ0kgZGV2aWNlcyAobWF4IFBDSSBidXMgaXMgMDApCihk
MTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjYwNl0gQWxsb2NhdGVkIFhlbiBoeXBlcmNhbGwg
cGFnZSBhdCAzZjdmZjAwMAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC42MDZdIERldGVj
dGVkIFhlbiB2NC41LjAtcmMKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNjA2XSB4ZW46
IGNvcHkgQklPUyB0YWJsZXMuLi4KKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNjA2XSBD
b3B5aW5nIFNNQklPUyBlbnRyeSBwb2ludCBmcm9tIDB4MDAwMTAwMTAgdG8gMHgwMDBmMGY1
MAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC42MDZdIENvcHlpbmcgTVBUQUJMRSBmcm9t
IDB4ZmMwMDExYTAvZmMwMDExYjAgdG8gMHgwMDBmMGUzMAooZDE2KSBbMjAxNC0xMS0xOCAx
MTozMzozNC42MDZdIENvcHlpbmcgUElSIGZyb20gMHgwMDAxMDAzMCB0byAweDAwMGYwZGIw
CihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjYwNl0gQ29weWluZyBBQ1BJIFJTRFAgZnJv
bSAweDAwMDEwMGIwIHRvIDB4MDAwZjBkODAKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQu
NjA2XSBVc2luZyBwbXRpbWVyLCBpb3BvcnQgMHhiMDA4CihkMTYpIFsyMDE0LTExLTE4IDEx
OjMzOjM0LjYwNl0gU2NhbiBmb3IgVkdBIG9wdGlvbiByb20KKGQxNikgWzIwMTQtMTEtMTgg
MTE6MzM6MzQuNjI0XSBSdW5uaW5nIG9wdGlvbiByb20gYXQgYzAwMDowMDAzCihYRU4pIFsy
MDE0LTExLTE4IDExOjMzOjM0LjYzM10gc3RkdmdhLmM6MTQ3OmQxNnYwIGVudGVyaW5nIHN0
ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC42NjJd
IHBtbSBjYWxsIGFyZzE9MAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC42NjRdIFR1cm5p
bmcgb24gdmdhIHRleHQgbW9kZSBjb25zb2xlCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0
Ljc4MV0gU2VhQklPUyAodmVyc2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTExOF8x
MjExNDUtc2VydmVlcnN0ZXJ0amUpCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0Ljc5NV0g
TWFjaGluZSBVVUlEIDY0NDg1ZmZjLWY0NTctNGJlMi05ZjI1LTdiMmFhNTg0ZDYxYQooZDE2
KSBbMjAxNC0xMS0xOCAxMTozMzozNC43OTVdIFhIQ0kgaW5pdCBvbiBkZXYgMDA6MDUuMDog
cmVncyBAIDB4ZjMyNzAwMDAsIDQgcG9ydHMsIDMyIHNsb3RzLCAzMiBieXRlIGNvbnRleHQK
KGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNzk1XSBzCihkMTYpIFsyMDE0LTExLTE4IDEx
OjMzOjM0Ljc5NV0gWEhDSSAgICBleHRjYXAgMHgxIEAgZjMyNzA1MDAKKGQxNikgWzIwMTQt
MTEtMTggMTE6MzM6MzQuNzk1XSBYSENJICAgIHByb3RvY29sIFVTQiAgMy4wMCwgMiBwb3J0
cyAob2Zmc2V0IDEpLCBkZWYgMAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC43OTVdIFhI
Q0kgICAgcHJvdG9jb2wgVVNCICAyLjAwLCAyIHBvcnRzIChvZmZzZXQgMyksIGRlZiAwCihk
MTYpIFsyMDE0LTExLTE4IDExOjMzOjM0Ljc5Nl0gVUhDSSBpbml0IG9uIGRldiAwMDowMS4y
IChpbz1jMTQwKQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC43OTddIEZvdW5kIDAgbHB0
IHBvcnRzCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0Ljc5OF0gRm91bmQgMSBzZXJpYWwg
cG9ydHMKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzQuNzk5XSBBVEEgY29udHJvbGxlciAx
IGF0IDFmMC8zZjQvMCAoaXJxIDE0IGRldiA5KQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzoz
NC44MDBdIEFUQSBjb250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUgZGV2IDkpCihk
MTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjgwM10gYXRhMC0wOiBRRU1VIEhBUkRESVNLIEFU
QS03IEhhcmQtRGlzayAoMTAyNDAgTWlCeXRlcykKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6
MzQuODAzXSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDEsMS9kcml2
ZUAwL2Rpc2tAMAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC44MDVdIGF0YTAtMTogUUVN
VSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDMwMCBHaUJ5dGVzKQooZDE2KSBbMjAxNC0x
MS0xOCAxMTozMzozNC44MDVdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4
LypAMSwxL2RyaXZlQDAvZGlza0AxCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0LjkwM10g
UFMyIGtleWJvYXJkIGluaXRpYWxpemVkCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM0Ljk0
OF0gWEhDSSBwb3J0ICM0OiAweDAwMjAwYTAzLCBwb3dlcmVkLCBlbmFibGVkLCBwbHMgMCwg
c3BlZWQgMiBbTG93XQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC45NzhdIFhIQ0kgbm8g
ZGV2aWNlcyBmb3VuZAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC45ODldIEFsbCB0aHJl
YWRzIGNvbXBsZXRlLgooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNC45ODldIFNjYW4gZm9y
IG9wdGlvbiByb21zCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM1LjAxM10gUnVubmluZyBv
cHRpb24gcm9tIGF0IGM5ODA6MDAwMwooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wMjFd
IHBtbSBjYWxsIGFyZzE9MQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wMjFdIHBtbSBj
YWxsIGFyZzE9MAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wMjNdIHBtbSBjYWxsIGFy
ZzE9MQooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wMjNdIHBtbSBjYWxsIGFyZzE9MAoo
ZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wNDNdIFNlYXJjaGluZyBib290b3JkZXIgZm9y
OiAvcGNpQGkwY2Y4LypANAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wNDNdIAooZDE2
KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wNTBdIFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lgoo
ZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNS4wNTFdIAooZDE2KSBbMjAxNC0xMS0xOCAxMToz
MzozNy42MjVdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTYpIFsyMDE0LTEx
LTE4IDExOjMzOjM3LjYyNV0gZHJpdmUgMHgwMDBmMGQzMDogUENIUz0xNjM4My8xNi82MyB0
cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwCihkMTYpIFsyMDE0
LTExLTE4IDExOjMzOjM3LjYyNV0gZHJpdmUgMHgwMDBmMGQwMDogUENIUz0xNjM4My8xNi82
MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTYyOTE0NTYwMAooZDE2KSBb
MjAxNC0xMS0xOCAxMTozMzozNy42MjVdIAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNy42
MjVdIFNwYWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkMDAK
KGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzcuNjI1XSBSZXR1cm5lZCAyNTM5NTIgYnl0ZXMg
b2YgWm9uZUhpZ2gKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzcuNjI1XSBlODIwIG1hcCBo
YXMgNiBpdGVtczoKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzcuNjI1XSAgIDA6IDAwMDAw
MDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0KKGQxNikgWzIwMTQtMTEt
MTggMTE6MzM6MzcuNjI1XSAgIDE6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEw
MDAwID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xOCAxMTozMzozNy42MjVdICAgMjog
MDAwMDAwMDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgPSAyIFJFU0VSVkVECihkMTYp
IFsyMDE0LTExLTE4IDExOjMzOjM3LjYyNl0gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAw
MDAwMDAzZjdmZTAwMCA9IDEgUkFNCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM3LjYyNl0g
ICA0OiAwMDAwMDAwMDNmN2ZlMDAwIC0gMDAwMDAwMDAzZjgwMDAwMCA9IDIgUkVTRVJWRUQK
KGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzcuNjI2XSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAg
LSAwMDAwMDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRAooZDE2KSBbMjAxNC0xMS0xOCAxMToz
MzozNy42MjZdIGVudGVyIGhhbmRsZV8xOToKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6Mzcu
NjI2XSAgIE5VTEwKKGQxNikgWzIwMTQtMTEtMTggMTE6MzM6MzcuNjMzXSBCb290aW5nIGZy
b20gSGFyZCBEaXNrLi4uCihkMTYpIFsyMDE0LTExLTE4IDExOjMzOjM3LjYzNl0gQm9vdGlu
ZyBmcm9tIDAwMDA6N2MwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzo0MC4wNzddIGdyYW50
X3RhYmxlLmM6MzA1OmQwdjQgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gNyBmcmFtZXMK
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNTg0XSBIVk0gTG9hZGVyCihkMTcpIFsyMDE0
LTExLTE4IDExOjMzOjQxLjU4NF0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYwooZDE3KSBbMjAx
NC0xMS0xOCAxMTozMzo0MS41ODRdIFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQg
Y2hhbm5lbCAxCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjU4NV0gU3lzdGVtIHJlcXVl
c3RlZCBTZWFCSU9TCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjU4NV0gQ1BVIHNwZWVk
IGlzIDMyMDAgTUh6CihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjU4NV0gUmVsb2NhdGlu
ZyBndWVzdCBtZW1vcnkgZm9yIGxvd21lbSBNTUlPIHNwYWNlIGRpc2FibGVkCihYRU4pIFsy
MDE0LTExLTE4IDExOjMzOjQxLjU4NV0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAwIGNo
YW5nZWQgMCAtPiA1CihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjU4NV0gUENJLUlTQSBs
aW5rIDAgcm91dGVkIHRvIElSUTUKKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6NDEuNTg1XSBp
cnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCihkMTcpIFsyMDE0
LTExLTE4IDExOjMzOjQxLjU4NV0gUENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCihY
RU4pIFsyMDE0LTExLTE4IDExOjMzOjQxLjU4NV0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGlu
ayAyIGNoYW5nZWQgMCAtPiAxMQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS41ODVdIFBD
SS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzo0
MS41ODZdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooZDE3
KSBbMjAxNC0xMS0xOCAxMTozMzo0MS41ODZdIFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJ
UlE1CihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjYwMl0gcGNpIGRldiAwMTozIElOVEEt
PklSUTEwCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjYwN10gcGNpIGRldiAwMjowIElO
VEEtPklSUTExCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjYxN10gcGNpIGRldiAwNDow
IElOVEEtPklSUTUKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjY0XSBObyBSQU0gaW4g
aGlnaCBtZW1vcnk7IHNldHRpbmcgaGlnaF9tZW0gcmVzb3VyY2UgYmFzZSB0byAxMDAwMDAw
MDAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjY1XSBwY2kgZGV2IDAzOjAgYmFyIDEw
IHNpemUgMDAyMDAwMDAwOiAwZjAwMDAwMDgKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEu
NjY2XSBwY2kgZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAxMDAwMDAwOiAwZjIwMDAwMDgKKGQx
NykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjY4XSBwY2kgZGV2IDA0OjAgYmFyIDMwIHNpemUg
MDAwMDQwMDAwOiAwZjMwMDAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjcwXSBw
Y2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAwMDIwMDAwOiAwZjMwNDAwMDAKKGQxNykgWzIw
MTQtMTEtMTggMTE6MzM6NDEuNjcwXSBwY2kgZGV2IDAzOjAgYmFyIDMwIHNpemUgMDAwMDEw
MDAwOiAwZjMwNjAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjcyXSBwY2kgZGV2
IDAzOjAgYmFyIDE0IHNpemUgMDAwMDAxMDAwOiAwZjMwNzAwMDAKKGQxNykgWzIwMTQtMTEt
MTggMTE6MzM6NDEuNjcyXSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAw
MDAwMGMwMDEKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjc0XSBwY2kgZGV2IDA0OjAg
YmFyIDE0IHNpemUgMDAwMDAwMDQwOiAwMDAwMGMxMDEKKGQxNykgWzIwMTQtMTEtMTggMTE6
MzM6NDEuNjc2XSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMx
NDEKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjc4XSBNdWx0aXByb2Nlc3NvciBpbml0
aWFsaXNhdGlvbjoKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNjk4XSAgLSBDUFUwIC4u
LiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4g
ZG9uZS4KKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzE4XSAgLSBDUFUxIC4uLiA0OC1i
aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4K
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzM3XSAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5
cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykg
WzIwMTQtMTEtMTggMTE6MzM6NDEuNzU3XSAgLSBDUFUzIC4uLiA0OC1iaXQgcGh5cyAuLi4g
Zml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4KKGQxNykgWzIwMTQt
MTEtMTggMTE6MzM6NDEuNzU3XSBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoKKGQxNykgWzIw
MTQtMTEtMTggMTE6MzM6NDEuNzY3XSAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFy
aWVzIC4uLiBwYXNzZWQKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzcyXSAgLSBHUyBi
YXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCihkMTcpIFsyMDE0LTExLTE4IDExOjMz
OjQxLjc3Ml0gUGFzc2VkIDIgb2YgMiB0ZXN0cwooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0
MS43NzJdIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KKGQxNykgWzIwMTQtMTEtMTggMTE6
MzM6NDEuNzczXSBMb2FkaW5nIFNlYUJJT1MgLi4uCihkMTcpIFsyMDE0LTExLTE4IDExOjMz
OjQxLjc3M10gQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgooZDE3KSBbMjAxNC0xMS0xOCAxMToz
Mzo0MS43NzNdIExvYWRpbmcgQUNQSSAuLi4KKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEu
Nzc1XSB2bTg2IFRTUyBhdCBmYzAwYTIwMAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43
NzVdIEJJT1MgbWFwOgooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzVdICAxMDAwMC0x
MDBkMzogU2NyYXRjaCBzcGFjZQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzVdICBj
MDAwMC1mZmZmZjogTWFpbiBCSU9TCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjc3NV0g
RTgyMCB0YWJsZToKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzc1XSAgWzAwXTogMDAw
MDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkFNCihkMTcpIFsyMDE0LTEx
LTE4IDExOjMzOjQxLjc3NV0gIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6
MDAwYzAwMDAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzc1XSAgWzAxXTogMDAwMDAw
MDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQKKGQxNykgWzIwMTQt
MTEtMTggMTE6MzM6NDEuNzc2XSAgWzAyXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAw
MDozZjgwMDAwMDogUkFNCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjc3Nl0gIEhPTEU6
IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAwMDAKKGQxNykgWzIwMTQtMTEt
MTggMTE6MzM6NDEuNzc2XSAgWzAzXTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTow
MDAwMDAwMDogUkVTRVJWRUQKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzc2XSBJbnZv
a2luZyBTZWFCSU9TIC4uLgooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzldIFNlYUJJ
T1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMThfMTIxMTQ1LXNlcnZl
ZXJzdGVydGplKQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzldIAooZDE3KSBbMjAx
NC0xMS0xOCAxMTozMzo0MS43NzldIEZvdW5kIFhlbiBoeXBlcnZpc29yIHNpZ25hdHVyZSBh
dCA0MDAwMDAwMAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzldIFJ1bm5pbmcgb24g
UUVNVSAoaTQ0MGZ4KQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43NzldIHhlbjogY29w
eSBlODIwLi4uCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjc3OV0gUmVsb2NhdGluZyBp
bml0IGZyb20gMHgwMDBkZjYyOSB0byAweDNmN2FlNjAwIChzaXplIDcxOTk1KQooZDE3KSBb
MjAxNC0xMS0xOCAxMTozMzo0MS43ODJdIENQVSBNaHo9MzIwMgooZDE3KSBbMjAxNC0xMS0x
OCAxMTozMzo0MS43ODddIEZvdW5kIDcgUENJIGRldmljZXMgKG1heCBQQ0kgYnVzIGlzIDAw
KQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43ODddIEFsbG9jYXRlZCBYZW4gaHlwZXJj
YWxsIHBhZ2UgYXQgM2Y3ZmYwMDAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzg3XSBE
ZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjc4N10g
eGVuOiBjb3B5IEJJT1MgdGFibGVzLi4uCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjc4
N10gQ29weWluZyBTTUJJT1MgZW50cnkgcG9pbnQgZnJvbSAweDAwMDEwMDEwIHRvIDB4MDAw
ZjBmNTAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuNzg3XSBDb3B5aW5nIE1QVEFCTEUg
ZnJvbSAweGZjMDAxMWEwL2ZjMDAxMWIwIHRvIDB4MDAwZjBlMzAKKGQxNykgWzIwMTQtMTEt
MTggMTE6MzM6NDEuNzg3XSBDb3B5aW5nIFBJUiBmcm9tIDB4MDAwMTAwMzAgdG8gMHgwMDBm
MGRiMAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS43ODddIENvcHlpbmcgQUNQSSBSU0RQ
IGZyb20gMHgwMDAxMDBiMCB0byAweDAwMGYwZDgwCihkMTcpIFsyMDE0LTExLTE4IDExOjMz
OjQxLjc4N10gVXNpbmcgcG10aW1lciwgaW9wb3J0IDB4YjAwOAooZDE3KSBbMjAxNC0xMS0x
OCAxMTozMzo0MS43ODddIFNjYW4gZm9yIFZHQSBvcHRpb24gcm9tCihkMTcpIFsyMDE0LTEx
LTE4IDExOjMzOjQxLjgwMl0gUnVubmluZyBvcHRpb24gcm9tIGF0IGMwMDA6MDAwMwooWEVO
KSBbMjAxNC0xMS0xOCAxMTozMzo0MS44MTJdIHN0ZHZnYS5jOjE0NzpkMTd2MCBlbnRlcmlu
ZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEu
ODI5XSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuODMxXSBU
dXJuaW5nIG9uIHZnYSB0ZXh0IG1vZGUgY29uc29sZQooZDE3KSBbMjAxNC0xMS0xOCAxMToz
Mzo0MS45NDZdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDEx
MThfMTIxMTQ1LXNlcnZlZXJzdGVydGplKQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0MS45
NjBdIE1hY2hpbmUgVVVJRCA0NzQ3ZjMwNi1jNjBkLTQ0OGUtYWEzYS0zM2M3YmQ5MTNiNzMK
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuOTYxXSBBbGwgdGhyZWFkcyBjb21wbGV0ZS4K
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuOTYyXSBGb3VuZCAwIGxwdCBwb3J0cwooZDE3
KSBbMjAxNC0xMS0xOCAxMTozMzo0MS45NjJdIEZvdW5kIDAgc2VyaWFsIHBvcnRzCihkMTcp
IFsyMDE0LTExLTE4IDExOjMzOjQxLjk2Ml0gQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0
LzAgKGlycSAxNCBkZXYgOSkKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDEuOTYzXSBBVEEg
Y29udHJvbGxlciAyIGF0IDE3MC8zNzQvMCAoaXJxIDE1IGRldiA5KQooZDE3KSBbMjAxNC0x
MS0xOCAxMTozMzo0MS45NjddIGF0YTAtMDogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURp
c2sgKDEwMjQwIE1pQnl0ZXMpCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQxLjk2N10gU2Vh
cmNoaW5nIGJvb3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDAK
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDY2XSBQUzIga2V5Ym9hcmQgaW5pdGlhbGl6
ZWQKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDY2XSBBbGwgdGhyZWFkcyBjb21wbGV0
ZS4KKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDY2XSBTY2FuIGZvciBvcHRpb24gcm9t
cwooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0Mi4wODhdIFJ1bm5pbmcgb3B0aW9uIHJvbSBh
dCBjOTgwOjAwMDMKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDk0XSBwbW0gY2FsbCBh
cmcxPTEKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDk0XSBwbW0gY2FsbCBhcmcxPTAK
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMDk2XSBwbW0gY2FsbCBhcmcxPTEKKGQxNykg
WzIwMTQtMTEtMTggMTE6MzM6NDIuMDk2XSBwbW0gY2FsbCBhcmcxPTAKKGQxNykgWzIwMTQt
MTEtMTggMTE6MzM6NDIuMTEzXSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNm
OC8qQDQKKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDIuMTEzXSAKKGQxNykgWzIwMTQtMTEt
MTggMTE6MzM6NDIuMTIwXSBQcmVzcyBGMTIgZm9yIGJvb3QgbWVudS4KKGQxNykgWzIwMTQt
MTEtMTggMTE6MzM6NDIuMTIwXSAKKFhFTikgWzIwMTQtMTEtMTggMTE6MzM6NDMuNzE4XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozMzo0NC40NzBdIHN0ZHZnYS5jOjE1MTpk
MTZ2MCBsZWF2aW5nIHN0ZHZnYQooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NTVdIFNl
YXJjaGluZyBib290b3JkZXIgZm9yOiBIQUxUCihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQ0
LjY1Nl0gZHJpdmUgMHgwMDBmMGQzMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1s
YmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwCihkMTcpIFsyMDE0LTExLTE4IDExOjMz
OjQ0LjY1Nl0gU3BhY2UgYXZhaWxhYmxlIGZvciBVTUI6IGNhODAwLWVmMDAwLCBmMDAwMC1m
MGQzMAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NTZdIFJldHVybmVkIDI1ODA0OCBi
eXRlcyBvZiBab25lSGlnaAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NTZdIGU4MjAg
bWFwIGhhcyA2IGl0ZW1zOgooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NTZdICAgMDog
MDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWZjMDAgPSAxIFJBTQooZDE3KSBbMjAx
NC0xMS0xOCAxMTozMzo0NC42NTZdICAgMTogMDAwMDAwMDAwMDA5ZmMwMCAtIDAwMDAwMDAw
MDAwYTAwMDAgPSAyIFJFU0VSVkVECihkMTcpIFsyMDE0LTExLTE4IDExOjMzOjQ0LjY1Nl0g
ICAyOiAwMDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCA9IDIgUkVTRVJWRUQK
KGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDQuNjU2XSAgIDM6IDAwMDAwMDAwMDAxMDAwMDAg
LSAwMDAwMDAwMDNmN2ZmMDAwID0gMSBSQU0KKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDQu
NjU2XSAgIDQ6IDAwMDAwMDAwM2Y3ZmYwMDAgLSAwMDAwMDAwMDNmODAwMDAwID0gMiBSRVNF
UlZFRAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NTZdICAgNTogMDAwMDAwMDBmYzAw
MDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJFU0VSVkVECihkMTcpIFsyMDE0LTExLTE4
IDExOjMzOjQ0LjY1N10gZW50ZXIgaGFuZGxlXzE5OgooZDE3KSBbMjAxNC0xMS0xOCAxMToz
Mzo0NC42NTddICAgTlVMTAooZDE3KSBbMjAxNC0xMS0xOCAxMTozMzo0NC42NjJdIEJvb3Rp
bmcgZnJvbSBIYXJkIERpc2suLi4KKGQxNykgWzIwMTQtMTEtMTggMTE6MzM6NDQuNjY0XSBC
b290aW5nIGZyb20gMDAwMDo3YzAwCihYRU4pIFsyMDE0LTExLTE4IDExOjMzOjUxLjc0MF0g
c3RkdmdhLmM6MTUxOmQxN3YwIGxlYXZpbmcgc3RkdmdhCihYRU4pIFsyMDE0LTExLTE4IDEx
OjMzOjUzLjcxOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6MDMuNzE4XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDowOS45OTVdIHN0ZHZnYS5jOjE0Nzpk
MTZ2MCBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMKKFhFTikgWzIwMTQtMTEt
MTggMTE6MzQ6MTEuNjQzXSBpcnEuYzozODA6IERvbTE2IGNhbGxiYWNrIHZpYSBjaGFuZ2Vk
IHRvIERpcmVjdCBWZWN0b3IgMHhmMwooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxMy43MThd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjE3LjUyMV0gc3RkdmdhLmM6MTQ3
OmQxN3YwIGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2RlcwooWEVOKSBbMjAxNC0x
MS0xOCAxMTozNDoxNy42MDddIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAg
bWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6MTcuNjEyXSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTEx
LTE4IDExOjM0OjE3LjYxNl0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBt
Zm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy42MjBdIG1lbW9yeV9t
YXA6YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEt
MTggMTE6MzQ6MTcuNjI1XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1m
bj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjE3LjYyOV0gbWVtb3J5X21h
cDphZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0x
OCAxMTozNDoxNy42MzNdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZu
PWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6MTcuNjM4XSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE4
IDExOjM0OjE3LjY0Ml0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49
ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy42NDZdIG1lbW9yeV9tYXA6
YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTEKKFhFTikgWzIwMTQtMTEtMTgg
MTE6MzQ6MTcuNjUwXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1m
ZTBmZSBucj0xCihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjE3LjY1NV0gbWVtb3J5X21hcDph
ZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQooWEVOKSBbMjAxNC0xMS0xOCAx
MTozNDoxNy42NjZdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZl
MjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy42NzJdIG1lbW9yeV9tYXA6
YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0x
OCAxMTozNDoxNy42NzhdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMDAgbWZu
PWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy42ODRdIG1lbW9yeV9t
YXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0x
MS0xOCAxMTozNDoxNy42ODldIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMDAg
bWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy42OTVdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAx
NC0xMS0xOCAxMTozNDoxNy43MDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMw
MDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy43MDZdIG1l
bW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBb
MjAxNC0xMS0xOCAxMTozNDoxNy43MTJdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49
ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy43MThd
IG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVO
KSBbMjAxNC0xMS0xOCAxMTozNDoxNy43MjNdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBn
Zm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy43
MjldIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMAoo
WEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy43NjFdIGlycS5jOjI3MDogRG9tMTYgUENJIGxp
bmsgMCBjaGFuZ2VkIDUgLT4gMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoxNy43ODFdIGly
cS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMSBjaGFuZ2VkIDEwIC0+IDAKKFhFTikgWzIwMTQt
MTEtMTggMTE6MzQ6MTcuODAwXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDIgY2hhbmdl
ZCAxMSAtPiAwCihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjE3LjgyMV0gaXJxLmM6MjcwOiBE
b20xNiBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwCihYRU4pIFsyMDE0LTExLTE4IDExOjM0
OjE5LjI2NV0gaXJxLmM6MzgwOiBEb20xNyBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJl
Y3QgVmVjdG9yIDB4ZjMKKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6MTkuNzg2XSBncmFudF90
YWJsZS5jOjEyOTk6ZDE2djMgRXhwYW5kaW5nIGRvbSAoMTYpIGdyYW50IHRhYmxlIGZyb20g
KDQpIHRvICg1KSBmcmFtZXMuCihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjIwLjM3Nl0gaXJx
LmM6MjcwOiBEb20xNyBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCihYRU4pIFsyMDE0LTEx
LTE4IDExOjM0OjIwLjM4MV0gaXJxLmM6MjcwOiBEb20xNyBQQ0kgbGluayAxIGNoYW5nZWQg
MTAgLT4gMAooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoyMC4zODddIGlycS5jOjI3MDogRG9t
MTcgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDAKKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6
MjAuMzkyXSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDMgY2hhbmdlZCA1IC0+IDAKKFhF
TikgWzIwMTQtMTEtMTggMTE6MzQ6MjAuODY3XSBncmFudF90YWJsZS5jOjEyOTk6ZDE3djIg
RXhwYW5kaW5nIGRvbSAoMTcpIGdyYW50IHRhYmxlIGZyb20gKDQpIHRvICg1KSBmcmFtZXMu
CihYRU4pIFsyMDE0LTExLTE4IDExOjM0OjIzLjcxOF0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTE6MzQ6MzMuNzE4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNDoz
NC43NjRdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUg
dG8gOCBmcmFtZXMKKFhFTikgWzIwMTQtMTEtMTggMTE6MzQ6NDMuNzE5XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMTozNDo1My43MTldIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDExOjM1OjAzLjcxOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzU6MTMu
NzE5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNToyMy43MTldIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDExOjM1OjMzLjcxOV0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTE6MzU6NDMuNzIwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNTo1
My43MjBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM2OjAzLjcyMF0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzY6MDYuODE5XSBncmFudF90YWJsZS5jOjEyOTk6
ZDE2djIgRXhwYW5kaW5nIGRvbSAoMTYpIGdyYW50IHRhYmxlIGZyb20gKDUpIHRvICg2KSBm
cmFtZXMuCihYRU4pIFsyMDE0LTExLTE4IDExOjM2OjEzLjcyMF0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTE6MzY6MjMuNzIxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MTozNjozMy43MjFdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM2OjQzLjcyMV0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6MzY6NDQuNzcwXSBncmFudF90YWJsZS5j
OjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDkgZnJhbWVzCihYRU4pIFsy
MDE0LTExLTE4IDExOjM2OjUzLjcyMV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6
Mzc6MDMuNzIxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozNzoxMy43MjFdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM3OjIzLjcyMV0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTE6Mzc6MzMuNzIyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MTozNzo0My43MjJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM3OjUzLjcyMl0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mzc6NTcuODkxXSBncmFudF90YWJsZS5j
OjMwNTpkMHYwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDEwIGZyYW1lcwooWEVOKSBb
MjAxNC0xMS0xOCAxMTozODowMy43MjJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEx
OjM4OjEzLjg0NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mzg6MjMuODQ0XSAt
LU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozODozMy44NDRdIC0tTUFSSy0tCihYRU4p
IFsyMDE0LTExLTE4IDExOjM4OjQzLjg0NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTgg
MTE6Mzg6NTMuODQ1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTozOTowMy44NDVd
IC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM5OjEzLjg0NV0gLS1NQVJLLS0KKFhF
TikgWzIwMTQtMTEtMTggMTE6Mzk6MjMuODQ1XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0x
OCAxMTozOTozMy44NDVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjM5OjQzLjg0
NV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6Mzk6NTMuODQ1XSAtLU1BUkstLQoo
WEVOKSBbMjAxNC0xMS0xOCAxMTo0MDowMy44NDVdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTEx
LTE4IDExOjQwOjEzLjg0Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDA6MjMu
ODQ2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0MDozMy44NDZdIC0tTUFSSy0t
CihYRU4pIFsyMDE0LTExLTE4IDExOjQwOjQzLjg0Nl0gLS1NQVJLLS0KKFhFTikgWzIwMTQt
MTEtMTggMTE6NDA6NTMuODQ2XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0MTow
My44NDZdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQxOjEzLjg0Nl0gLS1NQVJL
LS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDE6MjMuODQ3XSAtLU1BUkstLQooWEVOKSBbMjAx
NC0xMS0xOCAxMTo0MTozMy44NDddIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQx
OjQzLjg0N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDE6NTMuODQ3XSAtLU1B
UkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0MjowMy44NDddIC0tTUFSSy0tCihYRU4pIFsy
MDE0LTExLTE4IDExOjQyOjEzLjg0N10gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6
NDI6MjMuODQ4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0MjozMy44NDhdIC0t
TUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQyOjQzLjg0OF0gLS1NQVJLLS0KKFhFTikg
WzIwMTQtMTEtMTggMTE6NDI6NTMuODQ4XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0MzowMy44NDhdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjEzLjg0OF0g
LS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTguOTkzXSAgMDogZmZmZjgzMDUw
ODVmZmQyOCBbcDpmZmZmODMwNTRlZjI3ZTg4LCBuOmZmZmY4MzA1NGVmMjdlODhdCihYRU4p
IFsyMDE0LTExLTE4IDExOjQzOjE5LjAxOF0gIDE6IGZmZmY4MzA1MDg1ZmZkMjggW3A6MDIw
MDIwMDIwMDIwMDIwMCwgbjowMTAwMTAwMTAwMTAwMTAwXQooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0MzoxOS4wNDNdIENQVTAwOiAKKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTkuMDU0XSBk
MTYgT0stc29mdGlycSAxODZtc2VjIGFnbywgc3RhdGU6MSwgMzI1NyBjb3VudCwgW3ByZXY6
ZmZmZjgyZDA4MDJlN2U4OCwgbmV4dDpmZmZmODJkMDgwMmU3ZTg4XSBmZmZmODMwNTA5NGEz
OWE4PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJUlE6ODcKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDM6MTkuMTAzXSBkMTYgT0stcmFpc2UgICAyMzZtc2VjIGFnbywg
c3RhdGU6MSwgMzI1NyBjb3VudCwgW3ByZXY6MDIwMDIwMDIwMDIwMDIwMCwgbmV4dDowMTAw
MTAwMTAwMTAwMTAwXSBmZmZmODMwNTA5NGEzOWE4PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVT
VF9NU0lfU0hJRlQgIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTkuMTUyXSBD
UFUwMTogCihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjE5LjE2M10gZDE2IE9LLXNvZnRpcnEg
MjMybXNlYyBhZ28sIHN0YXRlOjEsIDI5NzggY291bnQsIFtwcmV2OmZmZmY4MzA1NGVmNTdl
NzAsIG5leHQ6ZmZmZjgzMDU0ZWY1N2U3MF0gZmZmZjgzMDUwOTRhMzlhODxOVUxMPiBNQVBQ
RURfU0hJRlQgR1VFU1RfTVNJX1NISUZUICBQSVJROjg3CihYRU4pIFsyMDE0LTExLTE4IDEx
OjQzOjE5LjIxMl0gZDE2IE9LLXJhaXNlICAgMjgxbXNlYyBhZ28sIHN0YXRlOjEsIDI5Nzgg
Y291bnQsIFtwcmV2OjAyMDAyMDAyMDAyMDAyMDAsIG5leHQ6MDEwMDEwMDEwMDEwMDEwMF0g
ZmZmZjgzMDUwOTRhMzlhODxOVUxMPiBNQVBQRURfU0hJRlQgR1VFU1RfTVNJX1NISUZUICBQ
SVJROjg3CihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjE5LjI2Ml0gQ1BVMDI6IAooWEVOKSBb
MjAxNC0xMS0xOCAxMTo0MzoxOS4yNzJdIGQxNiBPSy1zb2Z0aXJxIDM3M21zZWMgYWdvLCBz
dGF0ZToxLCAyMzc4IGNvdW50LCBbcHJldjpmZmZmODMwNTRlZjQ3ZTcwLCBuZXh0OmZmZmY4
MzA1NGVmNDdlNzBdIGZmZmY4MzA1MDk0YTM5YTg8TlVMTD4gTUFQUEVEX1NISUZUIEdVRVNU
X01TSV9TSElGVCAgUElSUTo4NwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0MzoxOS4zMjJdIGQx
NiBPSy1yYWlzZSAgIDQyM21zZWMgYWdvLCBzdGF0ZToxLCAyMzc4IGNvdW50LCBbcHJldjow
MjAwMjAwMjAwMjAwMjAwLCBuZXh0OjAxMDAxMDAxMDAxMDAxMDBdIGZmZmY4MzA1MDk0YTM5
YTg8TlVMTD4gTUFQUEVEX1NISUZUIEdVRVNUX01TSV9TSElGVCAgUElSUTo4NwooWEVOKSBb
MjAxNC0xMS0xOCAxMTo0MzoxOS4zNzFdIENQVTAzOiAKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDM6MTkuMzgyXSBkMTYgT0stc29mdGlycSA4Njdtc2VjIGFnbywgc3RhdGU6MSwgMjc0NCBj
b3VudCwgW3ByZXY6ZmZmZjgzMDU0ZWYzN2U3MCwgbmV4dDpmZmZmODMwNTRlZjM3ZTcwXSBm
ZmZmODMwNTA5NGEzOWE4PE5VTEw+IE1BUFBFRF9TSElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJ
UlE6ODcKKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTkuNDMxXSBkMTYgT0stcmFpc2UgICA5
MTZtc2VjIGFnbywgc3RhdGU6MSwgMjc0NCBjb3VudCwgW3ByZXY6MDIwMDIwMDIwMDIwMDIw
MCwgbmV4dDowMTAwMTAwMTAwMTAwMTAwXSBmZmZmODMwNTA5NGEzOWE4PE5VTEw+IE1BUFBF
RF9TSElGVCBHVUVTVF9NU0lfU0hJRlQgIFBJUlE6ODcKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDM6MTkuNDgxXSBDUFUwNDogCihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjE5LjQ5MV0gZDE2
IE9LLXNvZnRpcnEgNDk3bXNlYyBhZ28sIHN0YXRlOjEsIDc2OTEwIGNvdW50LCBbcHJldjpm
ZmZmODMwNTRlZjJlM2UwLCBuZXh0OmZmZmY4MzA1NGVmMmUzZTBdIGZmZmY4MzA1MDg1ZmZk
MjhNQUNIX1BDSV9TSElGVCBNQVBQRURfU0hJRlQgR1VFU1RfUENJX1NISUZUICBQSVJROjAK
KFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTkuNTQzXSBkMTYgT0stcmFpc2UgICA0ODltc2Vj
IGFnbywgc3RhdGU6MSwgNzY5MTYgY291bnQsIFtwcmV2OmZmZmY4MzA1NGVmMmUzZTAsIG5l
eHQ6ZmZmZjgzMDU0ZWYyZTNlMF0gZmZmZjgzMDUwODVmZmQyOE1BQ0hfUENJX1NISUZUIE1B
UFBFRF9TSElGVCBHVUVTVF9QQ0lfU0hJRlQgIFBJUlE6MAooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0MzoxOS41OTRdIGQxNiBFUlItcG9pc29uIDYwMG1zZWMgYWdvLCBzdGF0ZTowLCAxIGNv
dW50LCBbcHJldjowMjAwMjAwMjAwMjAwMjAwLCBuZXh0OjAxMDAxMDAxMDAxMDAxMDBdIGZm
ZmY4MzA1MDg1ZmZkMjhNQUNIX1BDSV9TSElGVCBNQVBQRURfU0hJRlQgR1VFU1RfUENJX1NI
SUZUICBQSVJROjAKKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MTkuNjQ1XSBDUFUwNTogCihY
RU4pIFsyMDE0LTExLTE4IDExOjQzOjE5LjY1NV0gZDE2IE9LLXNvZnRpcnEgODUybXNlYyBh
Z28sIHN0YXRlOjEsIDIyMDcgY291bnQsIFtwcmV2OmZmZmY4MzA1NGVmMWZlNzAsIG5leHQ6
ZmZmZjgzMDU0ZWYxZmU3MF0gZmZmZjgzMDUwOTRhMzlhODxOVUxMPiBNQVBQRURfU0hJRlQg
R1VFU1RfTVNJX1NISUZUICBQSVJROjg3CihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjE5Ljcw
NV0gZDE2IE9LLXJhaXNlICAgOTAybXNlYyBhZ28sIHN0YXRlOjEsIDIyMDcgY291bnQsIFtw
cmV2OjAyMDAyMDAyMDAyMDAyMDAsIG5leHQ6MDEwMDEwMDEwMDEwMDEwMF0gZmZmZjgzMDUw
OTRhMzlhODxOVUxMPiBNQVBQRURfU0hJRlQgR1VFU1RfTVNJX1NISUZUICBQSVJROjg3CihY
RU4pIFsyMDE0LTExLTE4IDExOjQzOjE5Ljc1M10gZG9tYWluX2NyYXNoIGNhbGxlZCBmcm9t
IGlvLmM6OTY0CihYRU4pIFsyMDE0LTExLTE4IDExOjQzOjE5Ljc1M10gRG9tYWluIDE2IHJl
cG9ydGVkIGNyYXNoZWQgYnkgZG9tYWluIDcgb24gY3B1IzQ6CihYRU4pIFsyMDE0LTExLTE4
IDExOjQzOjIzLjg0OF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDM6MzMuODQ5
XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Mzo0My44NDldIC0tTUFSSy0tCihY
RU4pIFsyMDE0LTExLTE4IDExOjQzOjUzLjg0OV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEt
MTggMTE6NDQ6MDMuODQ5XSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0NDoxMy44
NTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQ0OjIzLjg1MF0gLS1NQVJLLS0K
KFhFTikgWzIwMTQtMTEtMTggMTE6NDQ6MzMuODUwXSAtLU1BUkstLQooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0NDo0My44NTBdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQ0OjUz
Ljg1MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDU6MDMuODUxXSAtLU1BUkst
LQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0NToxMy44NTFdIC0tTUFSSy0tCihYRU4pIFsyMDE0
LTExLTE4IDExOjQ1OjIzLjg1MV0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDU6
MzMuODUxXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0NTo0My44NTJdIC0tTUFS
Sy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQ1OjUzLjg1Ml0gLS1NQVJLLS0KKFhFTikgWzIw
MTQtMTEtMTggMTE6NDY6MDMuODUyXSAtLU1BUkstLQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0
NjoxMy44NTJdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjIzLjg1M10gLS1N
QVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6MzMuODUzXSAtLU1BUkstLQooWEVOKSBb
MjAxNC0xMS0xOCAxMTo0Njo0My44NTNdIC0tTUFSSy0tCihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjUzLjg1NF0gLS1NQVJLLS0KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI1XSBJ
UlEgaW5mb3JtYXRpb246CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNV0gICAgSVJR
OiAgIDAgYWZmaW5pdHk6MDEgdmVjOmYwIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0w
MDAwMDAwMCB0aW1lcl9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41
MjZdICAgIElSUTogICAxIGFmZmluaXR5OjAxIHZlYzozMCB0eXBlPUlPLUFQSUMtZWRnZSAg
ICBzdGF0dXM9MDAwMDAwMzQgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogIDEoLS0tKSwK
KFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICAgMyBhZmZpbml0eTow
MSB2ZWM6MzggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwg
dW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogICA0IGFm
ZmluaXR5OjAxIHZlYzpmMSB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDAg
bnMxNjU1MF9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAg
IElSUTogICA1IGFmZmluaXR5OjAxIHZlYzo0MCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0
dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1
LjUyNl0gICAgSVJROiAgIDYgYWZmaW5pdHk6MDEgdmVjOjQ4IHR5cGU9SU8tQVBJQy1lZGdl
ICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTgg
MTE6NDY6NTUuNTI2XSAgICBJUlE6ICAgNyBhZmZpbml0eTowMSB2ZWM6NTAgdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAx
NC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogICA4IGFmZmluaXR5OjAxIHZlYzo1OCB0
eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWlu
LWxpc3Q9MDogIDgoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJ
UlE6ICAgOSBhZmZpbml0eTozZiB2ZWM6NjAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41
MjZdICAgIElSUTogIDEwIGFmZmluaXR5OjAxIHZlYzo2OCB0eXBlPUlPLUFQSUMtZWRnZSAg
ICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjU1LjUyNl0gICAgSVJROiAgMTEgYWZmaW5pdHk6MDEgdmVjOjcwIHR5cGU9SU8tQVBJ
Qy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQt
MTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICAxMiBhZmZpbml0eTowMSB2ZWM6NzggdHlw
ZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6IDEyKC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJR
OiAgMTMgYWZmaW5pdHk6M2YgdmVjOjg4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0w
MDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2
XSAgICBJUlE6ICAxNCBhZmZpbml0eTowMSB2ZWM6OTAgdHlwZT1JTy1BUElDLWVkZ2UgICAg
c3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0
Njo1NS41MjZdICAgIElSUTogIDE1IGFmZmluaXR5OjAxIHZlYzo5OCB0eXBlPUlPLUFQSUMt
ZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTEx
LTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgMTYgYWZmaW5pdHk6MDEgdmVjOjg5IHR5cGU9
SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlz
dD0wOiAxNigtLS0pLAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTog
IDE3IGFmZmluaXR5OjAxIHZlYzpjMCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAw
MDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogMTcoLS0tKSwKKFhFTikgWzIwMTQt
MTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICAxOCBhZmZpbml0eTowMSB2ZWM6YjggdHlw
ZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6IDE4KC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJR
OiAgMTkgYWZmaW5pdHk6M2YgdmVjOjJhIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0w
MDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2
XSAgICBJUlE6ICAyMiBhZmZpbml0eToyMCB2ZWM6YjkgdHlwZT1JTy1BUElDLWxldmVsICAg
c3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDIyKC0tLSksMTM6
IDIyKC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgMjUg
YWZmaW5pdHk6M2YgdmVjOjlhIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAw
MiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJ
UlE6ICAyOCBhZmZpbml0eTozZiB2ZWM6MjIgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41
MjZdICAgIElSUTogIDI5IGFmZmluaXR5OjNmIHZlYzpkOSB0eXBlPUlPLUFQSUMtbGV2ZWwg
ICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjU1LjUyNl0gICAgSVJROiAgMzIgYWZmaW5pdHk6M2YgdmVjOmM5IHR5cGU9SU8tQVBJ
Qy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQt
MTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICAzMyBhZmZpbml0eTozZiB2ZWM6YzEgdHlw
ZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVO
KSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDM2IGFmZmluaXR5OjNmIHZl
YzoyMSB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJv
dW5kCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgMzcgYWZmaW5p
dHk6MTAgdmVjOjI5IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAxMCBpbi1m
bGlnaHQ9MCBkb21haW4tbGlzdD0xNjogMzcoLU0tKSwKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDY6NTUuNTI2XSAgICBJUlE6ICAzOCBhZmZpbml0eTozZiB2ZWM6YTkgdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDQwIGFmZmluaXR5OjNmIHZlYzozMSB0eXBl
PUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4p
IFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNDYgYWZmaW5pdHk6M2YgdmVj
OjcyIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91
bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA0NyBhZmZpbml0
eToxMCB2ZWM6ZDEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZs
aWdodD0xIGRvbWFpbi1saXN0PTE2OiA0NyhQLU0pLAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0
Njo1NS41MjZdICAgIElSUTogIDQ4IGFmZmluaXR5OjNmIHZlYzpkMCB0eXBlPUlPLUFQSUMt
bGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTEx
LTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNTEgYWZmaW5pdHk6M2YgdmVjOjhhIHR5cGU9
SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA1MiBhZmZpbml0eTozZiB2ZWM6
MzkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu
ZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDUzIGFmZmluaXR5
OjNmIHZlYzpjOCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVk
LCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNTQg
YWZmaW5pdHk6M2YgdmVjOmQ4IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAw
MiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJ
UlE6ICA1NiBhZmZpbml0eTowMSB2ZWM6MjggdHlwZT1BTUQtSU9NTVUtTVNJICAgc3RhdHVz
PTAwMDAwMDAwIGlvbW11X2ludGVycnVwdF9oYW5kbGVyKCkKKFhFTikgWzIwMTQtMTEtMTgg
MTE6NDY6NTUuNTI2XSAgICBJUlE6ICA1NyBhZmZpbml0eTowNCB2ZWM6YTAgdHlwZT1IUEVU
LU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIGhwZXRfaW50ZXJydXB0X2hhbmRsZXIoKQoo
WEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDU4IGFmZmluaXR5OjA4
IHZlYzphOCB0eXBlPUhQRVQtTVNJICAgICAgICBzdGF0dXM9MDAwMDAwMDAgaHBldF9pbnRl
cnJ1cHRfaGFuZGxlcigpCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJR
OiAgNTkgYWZmaW5pdHk6MDIgdmVjOmIwIHR5cGU9SFBFVC1NU0kgICAgICAgIHN0YXR1cz0w
MDAwMDAwMCBocGV0X2ludGVycnVwdF9oYW5kbGVyKCkKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDY6NTUuNTI2XSAgICBJUlE6ICA2MCBhZmZpbml0eTozZiB2ZWM6NDEgdHlwZT1QQ0ktTVNJ
ICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDYxIGFmZmluaXR5OjNmIHZlYzo0OSB0eXBl
PVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4p
IFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNjIgYWZmaW5pdHk6M2YgdmVj
OjUxIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91
bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA2MyBhZmZpbml0
eTozZiB2ZWM6NTkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl
ZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDY0
IGFmZmluaXR5OjNmIHZlYzo2MSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAw
MDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAg
SVJROiAgNjUgYWZmaW5pdHk6M2YgdmVjOjY5IHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1
cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUu
NTI2XSAgICBJUlE6ICA2NiBhZmZpbml0eTozZiB2ZWM6NzEgdHlwZT1QQ0ktTVNJICAgICAg
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0Njo1NS41MjZdICAgIElSUTogIDY3IGFmZmluaXR5OjNmIHZlYzo3OSB0eXBlPVBDSS1N
U0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0
LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNjggYWZmaW5pdHk6M2YgdmVjOjgxIHR5
cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhF
TikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA2OSBhZmZpbml0eTozZiB2
ZWM6OTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5i
b3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDcwIGFmZmlu
aXR5OjNmIHZlYzo5OSB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMDIgbWFw
cGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAg
NzEgYWZmaW5pdHk6M2YgdmVjOmExIHR5cGU9UENJLU1TSS8tWCAgICAgIHN0YXR1cz0wMDAw
MDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAg
ICBJUlE6ICA3MiBhZmZpbml0eTozZiB2ZWM6YjEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3Rh
dHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1
NS41MjZdICAgIElSUTogIDczIGFmZmluaXR5OjAyIHZlYzozMiB0eXBlPVBDSS1NU0kgICAg
ICAgICBzdGF0dXM9MDAwMDAwMTAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyOTEoLS0t
KSwKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA3NCBhZmZpbml0
eTowMSB2ZWM6M2EgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZs
aWdodD0wIGRvbWFpbi1saXN0PTA6MjkyKC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2
OjU1LjUyNl0gICAgSVJROiAgNzUgYWZmaW5pdHk6MDIgdmVjOjQyIHR5cGU9UENJLU1TSSAg
ICAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI5Mygt
LS0pLAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDc2IGFmZmlu
aXR5OjAxIHZlYzo0YSB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMzAgaW4t
ZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDoyOTQoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDY6NTUuNTI2XSAgICBJUlE6ICA3NyBhZmZpbml0eTowMSB2ZWM6NTIgdHlwZT1QQ0ktTVNJ
ICAgICAgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk1
KC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgNzggYWZm
aW5pdHk6MDEgdmVjOjVhIHR5cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAzMCBp
bi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI5NigtLS0pLAooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0Njo1NS41MjZdICAgIElSUTogIDc5IGFmZmluaXR5OjNmIHZlYzo2MiB0eXBlPVBDSS1N
U0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pIFsyMDE0
LTExLTE4IDExOjQ2OjU1LjUyNl0gICAgSVJROiAgODAgYWZmaW5pdHk6M2YgdmVjOjZhIHR5
cGU9UENJLU1TSSAgICAgICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhF
TikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA4MSBhZmZpbml0eTowMiB2
ZWM6N2EgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0w
IGRvbWFpbi1saXN0PTA6MjkwKC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUy
Nl0gICAgSVJROiAgODIgYWZmaW5pdHk6MDIgdmVjOjkyIHR5cGU9UENJLU1TSSAgICAgICAg
IHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOjI4OSgtLS0pLAoo
WEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDgzIGFmZmluaXR5OjAx
IHZlYzphMiB0eXBlPVBDSS1NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0
PTAgZG9tYWluLWxpc3Q9MDoyODgoLS0tKSwKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUu
NTI2XSAgICBJUlE6ICA4NCBhZmZpbml0eTowOCB2ZWM6YWEgdHlwZT1QQ0ktTVNJLy1YICAg
ICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiA4NyhQLS0p
LAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjZdICAgIElSUTogIDg1IGFmZmluaXR5
OjA0IHZlYzpiMiB0eXBlPVBDSS1NU0kvLVggICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxp
Z2h0PTAgZG9tYWluLWxpc3Q9MTY6IDg2KC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2
OjU1LjUyNl0gICAgSVJROiAgODYgYWZmaW5pdHk6MDQgdmVjOmJhIHR5cGU9UENJLU1TSS8t
WCAgICAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0xNjogODUo
LS0tKSwKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICBJUlE6ICA4NyBhZmZp
bml0eTowNCB2ZWM6YzIgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDMwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTE2OiA4NCgtLS0pLAooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0Njo1NS41MjZdICAgIElSUTogIDg4IGFmZmluaXR5OjA0IHZlYzpjYSB0eXBlPVBDSS1N
U0kvLVggICAgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MTY6
IDgzKC0tLSksCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyNl0gRGlyZWN0IHZlY3Rv
ciBpbmZvcm1hdGlvbjoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI2XSAgICAweDIw
IC0+IGlycV9tb3ZlX2NsZWFudXBfaW50ZXJydXB0KCkKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDY6NTUuNTI3XSAgICAweGY5IC0+IHBtdV9hcGljX2ludGVycnVwdCgpCihYRU4pIFsyMDE0
LTExLTE4IDExOjQ2OjU1LjUyN10gICAgMHhmYSAtPiBhcGljX3RpbWVyX2ludGVycnVwdCgp
CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgMHhmYiAtPiBjYWxsX2Z1bmN0
aW9uX2ludGVycnVwdCgpCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgMHhm
YyAtPiBldmVudF9jaGVja19pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1
NS41MjddICAgIDB4ZmQgLT4gaW52YWxpZGF0ZV9pbnRlcnJ1cHQoKQooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0Njo1NS41MjddICAgIDB4ZmUgLT4gZXJyb3JfaW50ZXJydXB0KCkKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAweGZmIC0+IHNwdXJpb3VzX2ludGVycnVw
dCgpCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gSU8tQVBJQyBpbnRlcnJ1cHQg
aW5mb3JtYXRpb246CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElSUSAg
MCBWZWMyNDA6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBpYyAw
eDAwLCBQaW4gIDI6IHZlYz1mMCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9s
YXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0x
OCAxMTo0Njo1NS41MjddICAgICBJUlEgIDEgVmVjIDQ4OgooWEVOKSBbMjAxNC0xMS0xOCAx
MTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwgUGluICAxOiB2ZWM9MzAgZGVsaXZlcnk9
TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBk
ZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRICAzIFZl
YyA1NjoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDAs
IFBpbiAgMzogdmVjPTM4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0
eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjU1LjUyN10gICAgIElSUSAgNCBWZWMyNDE6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2
OjU1LjUyN10gICAgICAgQXBpYyAweDAwLCBQaW4gIDQ6IHZlYz1mMSBkZWxpdmVyeT1Mb1By
aSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3Rf
aWQ6MQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgIDUgVmVjIDY0
OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwgUGlu
ICA1OiB2ZWM9NDAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAg
aXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6
NTUuNTI3XSAgICAgSVJRICA2IFZlYyA3MjoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUu
NTI3XSAgICAgICBBcGljIDB4MDAsIFBpbiAgNjogdmVjPTQ4IGRlbGl2ZXJ5PUxvUHJpIGRl
c3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDox
CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElSUSAgNyBWZWMgODA6CihY
RU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBpYyAweDAwLCBQaW4gIDc6
IHZlYz01MCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MCBpcnI9
MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41
MjddICAgICBJUlEgIDggVmVjIDg4OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41Mjdd
ICAgICAgIEFwaWMgMHgwMCwgUGluICA4OiB2ZWM9NTggZGVsaXZlcnk9TG9QcmkgZGVzdD1M
IHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhF
TikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRICA5IFZlYyA5NjoKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDAsIFBpbiAgOTogdmVj
PTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRy
aWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41Mjdd
ICAgICBJUlEgMTAgVmVjMTA0OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAg
ICAgIEFwaWMgMHgwMCwgUGluIDEwOiB2ZWM9NjggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0
YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRIDExIFZlYzExMjoKKFhFTikgWzIw
MTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDAsIFBpbiAxMTogdmVjPTcw
IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9
RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAg
IElSUSAxMiBWZWMxMjA6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAg
QXBpYyAweDAwLCBQaW4gMTI6IHZlYz03OCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVz
PTAgcG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAx
NC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgMTMgVmVjMTM2OgooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwgUGluIDEzOiB2ZWM9ODggZGVs
aXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1h
c2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElS
USAxNCBWZWMxNDQ6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBp
YyAweDAwLCBQaW4gMTQ6IHZlYz05MCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAg
cG9sYXJpdHk9MCBpcnI9MCB0cmlnPUUgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSBbMjAxNC0x
MS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgMTUgVmVjMTUyOgooWEVOKSBbMjAxNC0xMS0x
OCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwgUGluIDE1OiB2ZWM9OTggZGVsaXZl
cnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9
MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRIDE2
IFZlYzEzNzoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4
MDAsIFBpbiAxNjogdmVjPTg5IGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xh
cml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTAgZGVzdF9pZDoxCihYRU4pIFsyMDE0LTExLTE4
IDExOjQ2OjU1LjUyN10gICAgIElSUSAxNyBWZWMxOTI6CihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjU1LjUyN10gICAgICAgQXBpYyAweDAwLCBQaW4gMTc6IHZlYz1jMCBkZWxpdmVyeT1G
aXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRl
c3RfaWQ6MQooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgMTggVmVj
MTg0OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwg
UGluIDE4OiB2ZWM9YjggZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5
PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjEKKFhFTikgWzIwMTQtMTEtMTggMTE6
NDY6NTUuNTI3XSAgICAgSVJRIDE5IFZlYyA0MjoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6
NTUuNTI3XSAgICAgICBBcGljIDB4MDAsIFBpbiAxOTogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVk
IGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9p
ZDo2MwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgMjIgVmVjMTg1
OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMCwgUGlu
IDIyOiB2ZWM9YjkgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEg
aXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjMyCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2
OjU1LjUyN10gICAgIElSUSAyNSBWZWMxNTQ6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1
LjUyN10gICAgICAgQXBpYyAweDAxLCBQaW4gIDE6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBk
ZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6
NjMKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRIDI4IFZlYyAzNDoK
KFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDEsIFBpbiAg
NDogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGly
cj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1
NS41MjddICAgICBJUlEgMjkgVmVjMjE3OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41
MjddICAgICAgIEFwaWMgMHgwMSwgUGluICA1OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVz
dD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYz
CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElSUSAzMiBWZWMyMDE6CihY
RU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBpYyAweDAxLCBQaW4gIDg6
IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9
MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUu
NTI3XSAgICAgSVJRIDMzIFZlYzE5MzoKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3
XSAgICAgICBBcGljIDB4MDEsIFBpbiAgOTogdmVjPTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9
TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2Mwoo
WEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgMzYgVmVjIDMzOgooWEVO
KSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMSwgUGluIDEyOiB2
ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAg
dHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUy
N10gICAgIElSUSAzNyBWZWMgNDE6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10g
ICAgICAgQXBpYyAweDAxLCBQaW4gMTM6IHZlYz0yOSBkZWxpdmVyeT1GaXhlZCBkZXN0PUwg
c3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MTYKKFhF
TikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRIDM4IFZlYzE2OToKKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDEsIFBpbiAxNDogdmVj
PTAwIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRy
aWc9TCBtYXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41Mjdd
ICAgICBJUlEgNDAgVmVjIDQ5OgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAg
ICAgIEFwaWMgMHgwMSwgUGluIDE2OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0
YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4p
IFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElSUSA0NiBWZWMxMTQ6CihYRU4pIFsy
MDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBpYyAweDAxLCBQaW4gMjI6IHZlYz0w
MCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmln
PUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAg
ICAgSVJRIDQ3IFZlYzIwOToKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAg
ICBBcGljIDB4MDEsIFBpbiAyMzogdmVjPWQxIGRlbGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0
dXM9MSBwb2xhcml0eT0xIGlycj0xIHRyaWc9TCBtYXNrPTAgZGVzdF9pZDoxNgooWEVOKSBb
MjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJUlEgNDggVmVjMjA4OgooWEVOKSBbMjAx
NC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFwaWMgMHgwMSwgUGluIDI0OiB2ZWM9MDAg
ZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1M
IG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAg
IElSUSA1MSBWZWMxMzg6CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU1LjUyN10gICAgICAg
QXBpYyAweDAxLCBQaW4gMjc6IHZlYz0wMCBkZWxpdmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVz
PTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMKKFhFTikgWzIw
MTQtMTEtMTggMTE6NDY6NTUuNTI3XSAgICAgSVJRIDUyIFZlYyA1NzoKKFhFTikgWzIwMTQt
MTEtMTggMTE6NDY6NTUuNTI3XSAgICAgICBBcGljIDB4MDEsIFBpbiAyODogdmVjPTAwIGRl
bGl2ZXJ5PUZpeGVkIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBt
YXNrPTEgZGVzdF9pZDo2MwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICBJ
UlEgNTMgVmVjMjAwOgooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1NS41MjddICAgICAgIEFw
aWMgMHgwMSwgUGluIDI5OiB2ZWM9MDAgZGVsaXZlcnk9Rml4ZWQgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzCihYRU4pIFsyMDE0
LTExLTE4IDExOjQ2OjU1LjUyN10gICAgIElSUSA1NCBWZWMyMTY6CihYRU4pIFsyMDE0LTEx
LTE4IDExOjQ2OjU1LjUyN10gICAgICAgQXBpYyAweDAxLCBQaW4gMzA6IHZlYz0wMCBkZWxp
dmVyeT1GaXhlZCBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFz
az0xIGRlc3RfaWQ6NjMKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTMzXSBNU0kgaW5m
b3JtYXRpb246CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzM10gIE1TSSAgICAgNTYg
dmVjPTI4IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAx
IG1hc2s9MC8wLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTMzXSAgSFBFVCAgICA1
NyB2ZWM9YTAgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAw
MDQgbWFzaz0xLzAvPwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzNdICBIUEVUICAg
IDU4IHZlYz1hOCBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAw
MDAwOCBtYXNrPTEvMC8/CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzM10gIEhQRVQg
ICAgNTkgdmVjPWIwIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAw
MDAwMDAyIG1hc2s9MS8wLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTMzXSAgTVNJ
ICAgICA2MCB2ZWM9NDEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9
MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzNdICBN
U0kgICAgIDYxIHZlYz00OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVz
dD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzM10g
IE1TSSAgICAgNjIgdmVjPTUxIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBk
ZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTMz
XSAgTVNJICAgICA2MyB2ZWM9NTkgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0
IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41
MzNdICBNU0kgICAgIDY0IHZlYz02MSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dl
c3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3
LjUzM10gIE1TSSAgICAgNjUgdmVjPTY5IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxv
d2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6
NTcuNTMzXSAgTVNJICAgICA2NiB2ZWM9NzEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cg
bG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0
Njo1Ny41MzNdICBNU0kgICAgIDY3IHZlYz03OSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxv
ZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE4IDEx
OjQ2OjU3LjUzM10gIE1TSSAgICAgNjggdmVjPTgxIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAg
bG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTgg
MTE6NDY6NTcuNTMzXSAgTVNJICAgICA2OSB2ZWM9OTEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0
ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0wLzEvPwooWEVOKSBbMjAxNC0xMS0x
OCAxMTo0Njo1Ny41MzNdICBNU0kgICAgIDcwIHZlYz05OSBsb3dlc3QgIGVkZ2UgICBhc3Nl
cnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTEvMS8xCihYRU4pIFsyMDE0LTEx
LTE4IDExOjQ2OjU3LjUzM10gIE1TSSAgICAgNzEgdmVjPWExIGxvd2VzdCAgZWRnZSAgIGFz
c2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9MS8xLzEKKFhFTikgWzIwMTQt
MTEtMTggMTE6NDY6NTcuNTMzXSAgTVNJICAgICA3MiB2ZWM9YjEgbG93ZXN0ICBlZGdlICAg
YXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwM2YgbWFzaz0xLzEvMQooWEVOKSBbMjAx
NC0xMS0xOCAxMTo0Njo1Ny41MzNdICBNU0kgICAgIDczIHZlYz0zMiBsb3dlc3QgIGVkZ2Ug
ICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8/CihYRU4pIFsy
MDE0LTExLTE4IDExOjQ2OjU3LjUzM10gIE1TSSAgICAgNzQgdmVjPTNhIGxvd2VzdCAgZWRn
ZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8KKFhFTikg
WzIwMTQtMTEtMTggMTE6NDY6NTcuNTMzXSAgTVNJICAgICA3NSB2ZWM9NDIgbG93ZXN0ICBl
ZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDIgbWFzaz0wLzEvPwooWEVO
KSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzNdICBNU0kgICAgIDc2IHZlYz00YSBsb3dlc3Qg
IGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8/CihY
RU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzM10gIE1TSSAgICAgNzcgdmVjPTUyIGxvd2Vz
dCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAxIG1hc2s9MC8xLz8K
KFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTMzXSAgTVNJICAgICA3OCB2ZWM9NWEgbG93
ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFzaz0wLzEv
PwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzRdICBNU0kgICAgIDc5IHZlYz02MiBs
b3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAv
MS8/CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzNF0gIE1TSSAgICAgODAgdmVjPTZh
IGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDNmIG1hc2s9
MC8xLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTM0XSAgTVNJICAgICA4MSB2ZWM9
N2EgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAwMDEgbWFz
az0wLzEvPwooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzRdICBNU0kgICAgIDgyIHZl
Yz05MiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBt
YXNrPTAvMS8/CihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzNF0gIE1TSSAgICAgODMg
dmVjPWEyIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAwMDAwMDAx
IG1hc2s9MC8xLz8KKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTM0XSAgTVNJLVggICA4
NCB2ZWM9YWEgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9MDAwMDAw
MDggbWFzaz0xLzAvMAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzRdICBNU0ktWCAg
IDg1IHZlYz1iMiBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAw
MDAwNCBtYXNrPTEvMC8wCihYRU4pIFsyMDE0LTExLTE4IDExOjQ2OjU3LjUzNF0gIE1TSS1Y
ICAgODYgdmVjPWJhIGxvd2VzdCAgZWRnZSAgIGFzc2VydCAgbG9nIGxvd2VzdCBkZXN0PTAw
MDAwMDA0IG1hc2s9MS8wLzAKKFhFTikgWzIwMTQtMTEtMTggMTE6NDY6NTcuNTM0XSAgTVNJ
LVggICA4NyB2ZWM9YzIgbG93ZXN0ICBlZGdlICAgYXNzZXJ0ICBsb2cgbG93ZXN0IGRlc3Q9
MDAwMDAwMDQgbWFzaz0xLzAvMAooWEVOKSBbMjAxNC0xMS0xOCAxMTo0Njo1Ny41MzRdICBN
U0ktWCAgIDg4IHZlYz1jYSBsb3dlc3QgIGVkZ2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVz
dD0wMDAwMDAwNCBtYXNrPTEvMC8wCg==
------------0191A1230144FE1ED
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0191A1230144FE1ED--



From xen-devel-bounces@lists.xen.org Tue Nov 18 15:13:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:13:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkSy-0002AB-Qi; Tue, 18 Nov 2014 15:13:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqkSx-0002A2-UP
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:13:16 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	9B/0E-29352-B026B645; Tue, 18 Nov 2014 15:13:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416323522!12064199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23172 invoked from network); 18 Nov 2014 15:13:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:13:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194005889"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 10:10:05 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqkPs-0005ma-Mq;
	Tue, 18 Nov 2014 15:10:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqkPr-0004wC-Sa;
	Tue, 18 Nov 2014 15:10:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.24907.144396.509457@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 15:10:03 +0000
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <546B5F15.5060702@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: ian.campbell@citrix.com, Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	tim@xen.org, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
> I need to create an empty structure. Is the dummy field really needed?

Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
would be very surprised if clang didn't support them too.

AIUI our policy, gcc extensions are fine except in the Xen public
headers.

> If so, did you meant?
> 
> struct
> {
>    int :0;
> }

Whatever you do, don't do this!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:13:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:13:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkSy-0002AB-Qi; Tue, 18 Nov 2014 15:13:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqkSx-0002A2-UP
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:13:16 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	9B/0E-29352-B026B645; Tue, 18 Nov 2014 15:13:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416323522!12064199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23172 invoked from network); 18 Nov 2014 15:13:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:13:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194005889"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 10:10:05 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqkPs-0005ma-Mq;
	Tue, 18 Nov 2014 15:10:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqkPr-0004wC-Sa;
	Tue, 18 Nov 2014 15:10:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.24907.144396.509457@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 15:10:03 +0000
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <546B5F15.5060702@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: ian.campbell@citrix.com, Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	tim@xen.org, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
> I need to create an empty structure. Is the dummy field really needed?

Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
would be very surprised if clang didn't support them too.

AIUI our policy, gcc extensions are fine except in the Xen public
headers.

> If so, did you meant?
> 
> struct
> {
>    int :0;
> }

Whatever you do, don't do this!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:16:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:16:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkVg-0002KB-GN; Tue, 18 Nov 2014 15:16:04 +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 1XqkVe-0002K2-OU
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:16:02 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	41/4E-03148-2B26B645; Tue, 18 Nov 2014 15:16:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416323761!13313971!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11723 invoked from network); 18 Nov 2014 15:16:01 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 15:16:01 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XqkVK-0008zf-Ue; Tue, 18 Nov 2014 15:15:42 +0000
Date: Tue, 18 Nov 2014 16:15:42 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141118151542.GB13651@deinos.phlegethon.org>
References: <21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416320809.17982.14.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li,
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang, Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

At 14:26 +0000 on 18 Nov (1416317209), Ian Campbell wrote:
> On Tue, 2014-11-18 at 11:41 +0000, Zhang, Yang Z wrote:
> > > Hmm - this is a pitfall waiting to happen.
> > > 
> > > In the case that there is a heterogeneous setup with one 1G capable
> > > and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
> > > pages on the capable hardware.  Any VM which guesses at hardware
> > > support by means other than cpuid features is liable to explode on migrate.
> > 
> > But a normal guest shouldn't to guess it, right?
> 
> IMHO any guest which does not use the mechanism explicitly provided for
> feature detection deserves to break randomly.

Yes, that's a reasonable position (notwithstanding that we know such
software exists).

In this case, the guest is entitled to _expect_ pagefaults on 1GB
mappings if CPUID claims they are not supported.  That sounds like an
unlikely thing for the guest to be relying on, but Xen itself does
something similar for the SHOPT_FAST_FAULT_PATH (and now also for
IOMMU entries for the deferred caching attribute updates).

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 Nov 18 15:16:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:16:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkVg-0002KB-GN; Tue, 18 Nov 2014 15:16:04 +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 1XqkVe-0002K2-OU
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:16:02 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	41/4E-03148-2B26B645; Tue, 18 Nov 2014 15:16:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416323761!13313971!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11723 invoked from network); 18 Nov 2014 15:16:01 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 15:16:01 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XqkVK-0008zf-Ue; Tue, 18 Nov 2014 15:15:42 +0000
Date: Tue, 18 Nov 2014 16:15:42 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141118151542.GB13651@deinos.phlegethon.org>
References: <21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416320809.17982.14.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li,
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang, Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

At 14:26 +0000 on 18 Nov (1416317209), Ian Campbell wrote:
> On Tue, 2014-11-18 at 11:41 +0000, Zhang, Yang Z wrote:
> > > Hmm - this is a pitfall waiting to happen.
> > > 
> > > In the case that there is a heterogeneous setup with one 1G capable
> > > and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
> > > pages on the capable hardware.  Any VM which guesses at hardware
> > > support by means other than cpuid features is liable to explode on migrate.
> > 
> > But a normal guest shouldn't to guess it, right?
> 
> IMHO any guest which does not use the mechanism explicitly provided for
> feature detection deserves to break randomly.

Yes, that's a reasonable position (notwithstanding that we know such
software exists).

In this case, the guest is entitled to _expect_ pagefaults on 1GB
mappings if CPUID claims they are not supported.  That sounds like an
unlikely thing for the guest to be relying on, but Xen itself does
something similar for the SHOPT_FAST_FAULT_PATH (and now also for
IOMMU entries for the deferred caching attribute updates).

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 Nov 18 15:26:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15: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 1XqkfR-0002Xb-V4; Tue, 18 Nov 2014 15:26:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqkfR-0002XW-GG
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:26:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FF/5B-25276-0156B645; Tue, 18 Nov 2014 15:26:08 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416324368!13611728!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1057 invoked from network); 18 Nov 2014 15:26:08 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:26:08 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so4346380wgh.40
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 07:26:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=y44P1/xC/IibvepsHYJ1/0EX4GNnSZwUdA5GklWb7uc=;
	b=WL7BzWY8T49W03b/jBuceZK9BHQal/uq6FBmrbR50IEGyuDWTQzdiIjpFTB4gSni7y
	VFp/hk9pl6ls7OTPsUAngl2Ljcn5rKQYYXvR7BtqRjeHa5k4OgK1bN69Rrijv7VPhtFU
	6/383/TxrenYuqxi3qimtkWVipDGH9aTWJUmfIzQtGJyh0EcHqu2To2rPv4isVmQk812
	+QVyGFLaJChnoE3+t3OMYKeH7cgKlPWrFCo2cMqs/lrNjhH8QnOHn+m+ixdH3FR/QxNJ
	hl3O0eYuNBjDRVqXComFwGv0O1lRl9cHalFiNho0HI3QuIf2VBGI2zRYzKXfGCkcbl2Q
	IIgQ==
X-Gm-Message-State: ALoCoQk8zckTAUglFCJXXgcqZRhPDVe7WhaRjiaC3SINPGP5L5UVR7dysgNfi1HP6aT45rwzKbIZ
X-Received: by 10.194.172.4 with SMTP id ay4mr24983053wjc.13.1416324367930;
	Tue, 18 Nov 2014 07:26:07 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id b6sm19919340wiy.22.2014.11.18.07.26.06
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 07:26:07 -0800 (PST)
Message-ID: <546B650D.8040304@linaro.org>
Date: Tue, 18 Nov 2014 15:26:05 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>	<54535E240200007800043DAC@mail.emea.novell.com>	<546B5F15.5060702@linaro.org>
	<21611.24907.144396.509457@mariner.uk.xensource.com>
In-Reply-To: <21611.24907.144396.509457@mariner.uk.xensource.com>
Cc: ian.campbell@citrix.com, Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	tim@xen.org, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/18/2014 03:10 PM, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
>> I need to create an empty structure. Is the dummy field really needed?
> 
> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
> would be very surprised if clang didn't support them too.

AFAIK, clang doesn't complain about empty structures.

> AIUI our policy, gcc extensions are fine except in the Xen public
> headers.

We have at least 2 "empty" structure on the ARM public header.

>> If so, did you meant?
>>
>> struct
>> {
>>    int :0;
>> }
> 
> Whatever you do, don't do this!

Would something like below be better?

struct
{
  int dummy:1
};

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:26:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15: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 1XqkfR-0002Xb-V4; Tue, 18 Nov 2014 15:26:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqkfR-0002XW-GG
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:26:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FF/5B-25276-0156B645; Tue, 18 Nov 2014 15:26:08 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416324368!13611728!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1057 invoked from network); 18 Nov 2014 15:26:08 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:26:08 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so4346380wgh.40
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 07:26:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=y44P1/xC/IibvepsHYJ1/0EX4GNnSZwUdA5GklWb7uc=;
	b=WL7BzWY8T49W03b/jBuceZK9BHQal/uq6FBmrbR50IEGyuDWTQzdiIjpFTB4gSni7y
	VFp/hk9pl6ls7OTPsUAngl2Ljcn5rKQYYXvR7BtqRjeHa5k4OgK1bN69Rrijv7VPhtFU
	6/383/TxrenYuqxi3qimtkWVipDGH9aTWJUmfIzQtGJyh0EcHqu2To2rPv4isVmQk812
	+QVyGFLaJChnoE3+t3OMYKeH7cgKlPWrFCo2cMqs/lrNjhH8QnOHn+m+ixdH3FR/QxNJ
	hl3O0eYuNBjDRVqXComFwGv0O1lRl9cHalFiNho0HI3QuIf2VBGI2zRYzKXfGCkcbl2Q
	IIgQ==
X-Gm-Message-State: ALoCoQk8zckTAUglFCJXXgcqZRhPDVe7WhaRjiaC3SINPGP5L5UVR7dysgNfi1HP6aT45rwzKbIZ
X-Received: by 10.194.172.4 with SMTP id ay4mr24983053wjc.13.1416324367930;
	Tue, 18 Nov 2014 07:26:07 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id b6sm19919340wiy.22.2014.11.18.07.26.06
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 07:26:07 -0800 (PST)
Message-ID: <546B650D.8040304@linaro.org>
Date: Tue, 18 Nov 2014 15:26:05 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>	<54535E240200007800043DAC@mail.emea.novell.com>	<546B5F15.5060702@linaro.org>
	<21611.24907.144396.509457@mariner.uk.xensource.com>
In-Reply-To: <21611.24907.144396.509457@mariner.uk.xensource.com>
Cc: ian.campbell@citrix.com, Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	tim@xen.org, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/18/2014 03:10 PM, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
>> I need to create an empty structure. Is the dummy field really needed?
> 
> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
> would be very surprised if clang didn't support them too.

AFAIK, clang doesn't complain about empty structures.

> AIUI our policy, gcc extensions are fine except in the Xen public
> headers.

We have at least 2 "empty" structure on the ARM public header.

>> If so, did you meant?
>>
>> struct
>> {
>>    int :0;
>> }
> 
> Whatever you do, don't do this!

Would something like below be better?

struct
{
  int dummy:1
};

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:27:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkgK-0002bt-EE; Tue, 18 Nov 2014 15:27:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkoch@verizon.com>) id 1XqkgJ-0002bi-68
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:27:03 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	3F/69-16982-5456B645; Tue, 18 Nov 2014 15:27:01 +0000
X-Env-Sender: dkoch@verizon.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416324419!12182092!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32500 invoked from network); 18 Nov 2014 15:27:01 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 15:27:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dkoch@verizon.com; q=dns/txt; s=corp;
	t=1416324421; x=1447860421;
	h=from:to:cc:subject:date:message-id;
	bh=i2tN/52rH5T7Grsn3DSbk7PUcowb4q7kd0uhk7wwtg8=;
	b=A80kiiTyYZ/hyENP5UvOtnaQ4jOki38W+UxZ5XTZ02DVe0BW1+3sc4J/
	6WTaG1VihOjNy21eOrNOWj0APKtuFUa1Vmeg6hY08O0ZTqwZ2cHlVHr8Z
	+40yUhgxBGHYs1yLIEYpMh25sZqZRoIYoNN1OilVbz7LTCY0di1uDF2c7 Q=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by fldsmtpe04.verizon.com with ESMTP; 18 Nov 2014 15:26:36 +0000
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="907772021"
Received: from unknown (HELO yoyo.cloudswitch.com) ([162.47.4.186])
	by fldsmtpi01.verizon.com with ESMTP; 18 Nov 2014 15:26:35 +0000
From: Don Koch <dkoch@verizon.com>
To: xen-devel@lists.xen.org
Date: Tue, 18 Nov 2014 10:26:31 -0500
Message-Id: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
X-Mailer: git-send-email 1.8.3.1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Don Koch <dkoch@verizon.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 we restore an xsave area from an older xen that has a larger
size than the xcr0 bit call for, it is possible to have non-zero
data in the unused area if an xsave has ever been done that used
that area (e.g. during a context switch). Since the vcpu's xsave
area is never zeroed after the initial allocation, that data is
still there. Since we are told that said area was not written to
during the save or migration, there is no need to restore it.

Signed-off-by: Don Koch <dkoch@verizon.com>
---
Turns out the assertion that the unused xsave area is zero
is wrong. Unfortunately, that leaves the following as the
only way I can think of to work around it (and is no worse
than xsave/xrestore during context switches). Alternate
suggestions welcome.

 xen/arch/x86/hvm/hvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..b2c0bc4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
                 printk(XENLOG_G_WARNING
                        "HVM%d.%u restore mismatch: xsave length %#x > %#x (non-zero data at %#x)\n",
                        d->domain_id, vcpuid, desc->length, size, i);
-                return -EOPNOTSUPP;
+                break;
             }
         }
         printk(XENLOG_G_WARNING
-- 
1.8.3.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:27:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkgK-0002bt-EE; Tue, 18 Nov 2014 15:27:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkoch@verizon.com>) id 1XqkgJ-0002bi-68
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:27:03 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	3F/69-16982-5456B645; Tue, 18 Nov 2014 15:27:01 +0000
X-Env-Sender: dkoch@verizon.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416324419!12182092!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32500 invoked from network); 18 Nov 2014 15:27:01 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 15:27:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dkoch@verizon.com; q=dns/txt; s=corp;
	t=1416324421; x=1447860421;
	h=from:to:cc:subject:date:message-id;
	bh=i2tN/52rH5T7Grsn3DSbk7PUcowb4q7kd0uhk7wwtg8=;
	b=A80kiiTyYZ/hyENP5UvOtnaQ4jOki38W+UxZ5XTZ02DVe0BW1+3sc4J/
	6WTaG1VihOjNy21eOrNOWj0APKtuFUa1Vmeg6hY08O0ZTqwZ2cHlVHr8Z
	+40yUhgxBGHYs1yLIEYpMh25sZqZRoIYoNN1OilVbz7LTCY0di1uDF2c7 Q=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by fldsmtpe04.verizon.com with ESMTP; 18 Nov 2014 15:26:36 +0000
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="907772021"
Received: from unknown (HELO yoyo.cloudswitch.com) ([162.47.4.186])
	by fldsmtpi01.verizon.com with ESMTP; 18 Nov 2014 15:26:35 +0000
From: Don Koch <dkoch@verizon.com>
To: xen-devel@lists.xen.org
Date: Tue, 18 Nov 2014 10:26:31 -0500
Message-Id: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
X-Mailer: git-send-email 1.8.3.1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Don Koch <dkoch@verizon.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 we restore an xsave area from an older xen that has a larger
size than the xcr0 bit call for, it is possible to have non-zero
data in the unused area if an xsave has ever been done that used
that area (e.g. during a context switch). Since the vcpu's xsave
area is never zeroed after the initial allocation, that data is
still there. Since we are told that said area was not written to
during the save or migration, there is no need to restore it.

Signed-off-by: Don Koch <dkoch@verizon.com>
---
Turns out the assertion that the unused xsave area is zero
is wrong. Unfortunately, that leaves the following as the
only way I can think of to work around it (and is no worse
than xsave/xrestore during context switches). Alternate
suggestions welcome.

 xen/arch/x86/hvm/hvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..b2c0bc4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
                 printk(XENLOG_G_WARNING
                        "HVM%d.%u restore mismatch: xsave length %#x > %#x (non-zero data at %#x)\n",
                        d->domain_id, vcpuid, desc->length, size, i);
-                return -EOPNOTSUPP;
+                break;
             }
         }
         printk(XENLOG_G_WARNING
-- 
1.8.3.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:29:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:29:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqki7-0002kh-2L; Tue, 18 Nov 2014 15:28:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1Xqki5-0002kR-98
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:28:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	65/A0-25276-4B56B645; Tue, 18 Nov 2014 15:28:52 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416324531!13665835!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15468 invoked from network); 18 Nov 2014 15:28:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:28:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="26941225"
Date: Tue, 18 Nov 2014 15:28:49 +0000
From: Euan Harris <euan.harris@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141118152848.GE31225@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-12-10)
X-DLP: AMS1
Subject: [Xen-devel] libxl: Is the nic param to libxl_network_device_add an
 (in)_out parameter?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

If I call libxl_device_nic_add and pass in a mostly-default
libxl_device_nic structure, the function fills in the unspecified default
config fields with data for the NIC which it has just created:

	libxl_device_nic nic;
   	libxl_device_nic_init(&nic);
	/* 
	   nic.devid == -1 
	   nic.mac == 00:00:00:00:00:00 
           nic.model == null
	   etc.
	 */

	libxl_device_nic_add(ctx, domid, &nic, NULL);
	/* 
	   nic.devid == 3 
	   nic.mac == 00:16:3e:1b:7b:12
           nic.model == rtl8139
	   etc.
	 */

Is this behaviour an intentional part of the API which I can rely on,
or just an artefact of the current implementation?  In other words, is
nic meant to be an (in)_out parameter?  If it's not, what is the correct
way to find out the device ID which was allocated for the new device,
for example?

Thanks,
Euan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:29:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:29:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqki7-0002kh-2L; Tue, 18 Nov 2014 15:28:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1Xqki5-0002kR-98
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:28:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	65/A0-25276-4B56B645; Tue, 18 Nov 2014 15:28:52 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416324531!13665835!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15468 invoked from network); 18 Nov 2014 15:28:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:28:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="26941225"
Date: Tue, 18 Nov 2014 15:28:49 +0000
From: Euan Harris <euan.harris@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141118152848.GE31225@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-12-10)
X-DLP: AMS1
Subject: [Xen-devel] libxl: Is the nic param to libxl_network_device_add an
 (in)_out parameter?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

If I call libxl_device_nic_add and pass in a mostly-default
libxl_device_nic structure, the function fills in the unspecified default
config fields with data for the NIC which it has just created:

	libxl_device_nic nic;
   	libxl_device_nic_init(&nic);
	/* 
	   nic.devid == -1 
	   nic.mac == 00:00:00:00:00:00 
           nic.model == null
	   etc.
	 */

	libxl_device_nic_add(ctx, domid, &nic, NULL);
	/* 
	   nic.devid == 3 
	   nic.mac == 00:16:3e:1b:7b:12
           nic.model == rtl8139
	   etc.
	 */

Is this behaviour an intentional part of the API which I can rely on,
or just an artefact of the current implementation?  In other words, is
nic meant to be an (in)_out parameter?  If it's not, what is the correct
way to find out the device ID which was allocated for the new device,
for example?

Thanks,
Euan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:36:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:36:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkpY-00031u-MQ; Tue, 18 Nov 2014 15:36:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqkpX-00031n-EO
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:36:35 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	BA/64-02696-2876B645; Tue, 18 Nov 2014 15:36:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416324992!8708704!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9725 invoked from network); 18 Nov 2014 15:36:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:36:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192513845"
Message-ID: <1416324924.17982.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Tue, 18 Nov 2014 15:35:24 +0000
In-Reply-To: <20141118152848.GE31225@citrix.com>
References: <20141118152848.GE31225@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add
 an (in)_out parameter?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 15:28 +0000, Euan Harris wrote:
> Hi,
> 
> If I call libxl_device_nic_add and pass in a mostly-default
> libxl_device_nic structure, the function fills in the unspecified default
> config fields with data for the NIC which it has just created:
> 
> 	libxl_device_nic nic;
>    	libxl_device_nic_init(&nic);
> 	/* 
> 	   nic.devid == -1 
> 	   nic.mac == 00:00:00:00:00:00 
>            nic.model == null
> 	   etc.
> 	 */
> 
> 	libxl_device_nic_add(ctx, domid, &nic, NULL);
> 	/* 
> 	   nic.devid == 3 
> 	   nic.mac == 00:16:3e:1b:7b:12
>            nic.model == rtl8139
> 	   etc.
> 	 */
> 
> Is this behaviour an intentional part of the API which I can rely on,
> or just an artefact of the current implementation?  In other words, is
> nic meant to be an (in)_out parameter?

I believe so, yes. The comment under "Devices" in libxl.h probably ought
to be adjusted to say so explicitly.

Ian (J) -- do you agree?

>   If it's not, what is the correct
> way to find out the device ID which was allocated for the new device,
> for example?

You would have to libxl_device_<type>_list and look for it, which is
clearly suboptimal.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:36:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:36:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkpT-00031a-AP; Tue, 18 Nov 2014 15:36:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqkpR-00031R-U8
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:36:30 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	FD/0F-25547-D776B645; Tue, 18 Nov 2014 15:36:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416324985!12251954!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13530 invoked from network); 18 Nov 2014 15:36:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:36:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194020098"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 10:35:47 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqkol-0006Pe-0w;
	Tue, 18 Nov 2014 15:35:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqkok-00050g-HV;
	Tue, 18 Nov 2014 15:35:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.26449.963393.613516@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 15:35:45 +0000
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <546B650D.8040304@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
	<21611.24907.144396.509457@mariner.uk.xensource.com>
	<546B650D.8040304@linaro.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: ian.campbell@citrix.com, Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	tim@xen.org, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
> On 11/18/2014 03:10 PM, Ian Jackson wrote:
> > Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
> > would be very surprised if clang didn't support them too.
> 
> AFAIK, clang doesn't complain about empty structures.

Right.

> > AIUI our policy, gcc extensions are fine except in the Xen public
> > headers.
> 
> We have at least 2 "empty" structure on the ARM public header.

That ought to be fixed, in case anyone ever wants to build ARM guests
with Norcroft C or something.

Does the size of these structs matter ?

> Would something like below be better?
> 
> struct
> {
>   int dummy:1
> };

I don't see why you wouldn't just do
   struct blah { char dummy; };
or even int dummy;

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:36:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:36:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkpY-00031u-MQ; Tue, 18 Nov 2014 15:36:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqkpX-00031n-EO
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:36:35 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	BA/64-02696-2876B645; Tue, 18 Nov 2014 15:36:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416324992!8708704!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9725 invoked from network); 18 Nov 2014 15:36:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:36:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192513845"
Message-ID: <1416324924.17982.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Tue, 18 Nov 2014 15:35:24 +0000
In-Reply-To: <20141118152848.GE31225@citrix.com>
References: <20141118152848.GE31225@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add
 an (in)_out parameter?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 15:28 +0000, Euan Harris wrote:
> Hi,
> 
> If I call libxl_device_nic_add and pass in a mostly-default
> libxl_device_nic structure, the function fills in the unspecified default
> config fields with data for the NIC which it has just created:
> 
> 	libxl_device_nic nic;
>    	libxl_device_nic_init(&nic);
> 	/* 
> 	   nic.devid == -1 
> 	   nic.mac == 00:00:00:00:00:00 
>            nic.model == null
> 	   etc.
> 	 */
> 
> 	libxl_device_nic_add(ctx, domid, &nic, NULL);
> 	/* 
> 	   nic.devid == 3 
> 	   nic.mac == 00:16:3e:1b:7b:12
>            nic.model == rtl8139
> 	   etc.
> 	 */
> 
> Is this behaviour an intentional part of the API which I can rely on,
> or just an artefact of the current implementation?  In other words, is
> nic meant to be an (in)_out parameter?

I believe so, yes. The comment under "Devices" in libxl.h probably ought
to be adjusted to say so explicitly.

Ian (J) -- do you agree?

>   If it's not, what is the correct
> way to find out the device ID which was allocated for the new device,
> for example?

You would have to libxl_device_<type>_list and look for it, which is
clearly suboptimal.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:36:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:36:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkpT-00031a-AP; Tue, 18 Nov 2014 15:36:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqkpR-00031R-U8
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:36:30 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	FD/0F-25547-D776B645; Tue, 18 Nov 2014 15:36:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416324985!12251954!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13530 invoked from network); 18 Nov 2014 15:36:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:36:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194020098"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 10:35:47 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqkol-0006Pe-0w;
	Tue, 18 Nov 2014 15:35:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqkok-00050g-HV;
	Tue, 18 Nov 2014 15:35:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.26449.963393.613516@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 15:35:45 +0000
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <546B650D.8040304@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
	<21611.24907.144396.509457@mariner.uk.xensource.com>
	<546B650D.8040304@linaro.org>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: ian.campbell@citrix.com, Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	tim@xen.org, stefano.stabellini@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
> On 11/18/2014 03:10 PM, Ian Jackson wrote:
> > Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
> > would be very surprised if clang didn't support them too.
> 
> AFAIK, clang doesn't complain about empty structures.

Right.

> > AIUI our policy, gcc extensions are fine except in the Xen public
> > headers.
> 
> We have at least 2 "empty" structure on the ARM public header.

That ought to be fixed, in case anyone ever wants to build ARM guests
with Norcroft C or something.

Does the size of these structs matter ?

> Would something like below be better?
> 
> struct
> {
>   int dummy:1
> };

I don't see why you wouldn't just do
   struct blah { char dummy; };
or even int dummy;

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:40:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqktZ-0003Gp-HC; Tue, 18 Nov 2014 15:40:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqktW-0003Gf-R8
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:40:44 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E3/A0-23865-A786B645; Tue, 18 Nov 2014 15:40:42 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416325237!12152860!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5132 invoked from network); 18 Nov 2014 15:40:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:40:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194022179"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 10:40:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xqkt8-0006ZL-2U;
	Tue, 18 Nov 2014 15:40:18 +0000
Date: Tue, 18 Nov 2014 15:39:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> everything works fine
> The following 2 patches fixes xen/master for my platform.
> 
> Stefano, could you please take a look to these changes?
> 
> commit 3628a0aa35706a8f532af865ed784536ce514eca
> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> Date:   Tue Nov 18 14:20:42 2014 +0200
> 
>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> 
>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 31fb81a..093ecdb 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> pending_irq *p,
>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> GICH_V2_LR_VIRTUAL_SHIFT));
> 
> -    if ( p->desc != NULL )
> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>      {
> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> -        else
> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> GICH_V2_LR_PHYSICAL_MASK )
> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> +    }
> +    else if ( p->desc != NULL )
> +    {
> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>      }
> 
>      writel_gich(lr_reg, GICH_LR + lr * 4);

Actually in case p->desc == NULL (the irq is not an hardware irq, it
could be the virtual timer irq or the evtchn irq), you shouldn't need
the maintenance interrupt, if the bug was really due to GICH_LR_HW not
working correctly on OMAP5. This changes might only be better at
"hiding" the real issue.

Maybe the problem is exactly the opposite: the new scheme for avoiding
maintenance interrupts doesn't work for software interrupts.
The commit that should make them work correctly after the
no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
If you look at the changes to gic_update_one_lr in that commit, you'll
see that is going to set a software irq as PENDING if it is already ACTIVE.
Maybe that doesn't work correctly on OMAP5.

Could you try this patch on top of
394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
if the problem is specifically with software irqs.


diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b7516c0..d8a17c9 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
 /* Maximum cpu interface per GIC */
 #define NR_GIC_CPU_IF 8
 
-#undef GIC_DEBUG
+#define GIC_DEBUG 1
 
 static void gic_update_one_lr(struct vcpu *v, int i);
 
@@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
         ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
     if ( p->desc != NULL )
         lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
+    else
+        lr_val |= GICH_LR_MAINTENANCE_IRQ;
 
     GICH[GICH_LR + lr] = lr_val;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:40:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqktZ-0003Gp-HC; Tue, 18 Nov 2014 15:40:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqktW-0003Gf-R8
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:40:44 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E3/A0-23865-A786B645; Tue, 18 Nov 2014 15:40:42 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416325237!12152860!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5132 invoked from network); 18 Nov 2014 15:40:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:40:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194022179"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 10:40:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xqkt8-0006ZL-2U;
	Tue, 18 Nov 2014 15:40:18 +0000
Date: Tue, 18 Nov 2014 15:39:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> everything works fine
> The following 2 patches fixes xen/master for my platform.
> 
> Stefano, could you please take a look to these changes?
> 
> commit 3628a0aa35706a8f532af865ed784536ce514eca
> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> Date:   Tue Nov 18 14:20:42 2014 +0200
> 
>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> 
>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 31fb81a..093ecdb 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> pending_irq *p,
>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> GICH_V2_LR_VIRTUAL_SHIFT));
> 
> -    if ( p->desc != NULL )
> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>      {
> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> -        else
> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> GICH_V2_LR_PHYSICAL_MASK )
> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> +    }
> +    else if ( p->desc != NULL )
> +    {
> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>      }
> 
>      writel_gich(lr_reg, GICH_LR + lr * 4);

Actually in case p->desc == NULL (the irq is not an hardware irq, it
could be the virtual timer irq or the evtchn irq), you shouldn't need
the maintenance interrupt, if the bug was really due to GICH_LR_HW not
working correctly on OMAP5. This changes might only be better at
"hiding" the real issue.

Maybe the problem is exactly the opposite: the new scheme for avoiding
maintenance interrupts doesn't work for software interrupts.
The commit that should make them work correctly after the
no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
If you look at the changes to gic_update_one_lr in that commit, you'll
see that is going to set a software irq as PENDING if it is already ACTIVE.
Maybe that doesn't work correctly on OMAP5.

Could you try this patch on top of
394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
if the problem is specifically with software irqs.


diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b7516c0..d8a17c9 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
 /* Maximum cpu interface per GIC */
 #define NR_GIC_CPU_IF 8
 
-#undef GIC_DEBUG
+#define GIC_DEBUG 1
 
 static void gic_update_one_lr(struct vcpu *v, int i);
 
@@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
         ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
     if ( p->desc != NULL )
         lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
+    else
+        lr_val |= GICH_LR_MAINTENANCE_IRQ;
 
     GICH[GICH_LR + lr] = lr_val;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:41:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkuB-0003Lz-G0; Tue, 18 Nov 2014 15:41:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqkuA-0003Ld-6p
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:41:22 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	83/CA-02576-1A86B645; Tue, 18 Nov 2014 15:41:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416325278!13319434!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28414 invoked from network); 18 Nov 2014 15:41:20 -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;
	18 Nov 2014 15:41:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192516424"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 10:41:12 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqku0-0006aC-40;
	Tue, 18 Nov 2014 15:41:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqktz-00051Y-T0;
	Tue, 18 Nov 2014 15:41:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.26775.594669.510363@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 15:41:11 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416324924.17982.21.camel@citrix.com>
References: <20141118152848.GE31225@citrix.com>
	<1416324924.17982.21.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Euan Harris <euan.harris@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add
 an (in)_out parameter?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add an (in)_out parameter?"):
> On Tue, 2014-11-18 at 15:28 +0000, Euan Harris wrote:
> > If I call libxl_device_nic_add and pass in a mostly-default
> > libxl_device_nic structure, the function fills in the unspecified default
> > config fields with data for the NIC which it has just created:
...
> > Is this behaviour an intentional part of the API which I can rely on,
> > or just an artefact of the current implementation?  In other words, is
> > nic meant to be an (in)_out parameter?

Yes.

> I believe so, yes. The comment under "Devices" in libxl.h probably ought
> to be adjusted to say so explicitly.
> 
> Ian (J) -- do you agree?

I do.  I think this applies to other kinds of device too, which might
have unspecified parameters which get filled in.

Euan, would you like to send us a doc patch for libxl.h ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:41:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqkuB-0003Lz-G0; Tue, 18 Nov 2014 15:41:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqkuA-0003Ld-6p
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:41:22 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	83/CA-02576-1A86B645; Tue, 18 Nov 2014 15:41:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416325278!13319434!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28414 invoked from network); 18 Nov 2014 15:41:20 -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;
	18 Nov 2014 15:41:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192516424"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 10:41:12 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqku0-0006aC-40;
	Tue, 18 Nov 2014 15:41:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqktz-00051Y-T0;
	Tue, 18 Nov 2014 15:41:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.26775.594669.510363@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 15:41:11 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416324924.17982.21.camel@citrix.com>
References: <20141118152848.GE31225@citrix.com>
	<1416324924.17982.21.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Euan Harris <euan.harris@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add
 an (in)_out parameter?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add an (in)_out parameter?"):
> On Tue, 2014-11-18 at 15:28 +0000, Euan Harris wrote:
> > If I call libxl_device_nic_add and pass in a mostly-default
> > libxl_device_nic structure, the function fills in the unspecified default
> > config fields with data for the NIC which it has just created:
...
> > Is this behaviour an intentional part of the API which I can rely on,
> > or just an artefact of the current implementation?  In other words, is
> > nic meant to be an (in)_out parameter?

Yes.

> I believe so, yes. The comment under "Devices" in libxl.h probably ought
> to be adjusted to say so explicitly.
> 
> Ian (J) -- do you agree?

I do.  I think this applies to other kinds of device too, which might
have unspecified parameters which get filled in.

Euan, would you like to send us a doc patch for libxl.h ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:44:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqkx4-0003ZL-53; Tue, 18 Nov 2014 15:44: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 1Xqkx3-0003ZE-EC
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:44:21 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	E8/29-11581-4596B645; Tue, 18 Nov 2014 15:44:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416325456!12072030!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2486 invoked from network); 18 Nov 2014 15:44:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:44:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192517663"
Message-ID: <1416325453.17982.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 18 Nov 2014 15:44:13 +0000
In-Reply-To: <21611.26775.594669.510363@mariner.uk.xensource.com>
References: <20141118152848.GE31225@citrix.com>
	<1416324924.17982.21.camel@citrix.com>
	<21611.26775.594669.510363@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Euan Harris <euan.harris@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add
 an (in)_out parameter?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 15:41 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add an (in)_out parameter?"):
> > On Tue, 2014-11-18 at 15:28 +0000, Euan Harris wrote:
> > > If I call libxl_device_nic_add and pass in a mostly-default
> > > libxl_device_nic structure, the function fills in the unspecified default
> > > config fields with data for the NIC which it has just created:
> ...
> > > Is this behaviour an intentional part of the API which I can rely on,
> > > or just an artefact of the current implementation?  In other words, is
> > > nic meant to be an (in)_out parameter?
> 
> Yes.
> 
> > I believe so, yes. The comment under "Devices" in libxl.h probably ought
> > to be adjusted to say so explicitly.
> > 
> > Ian (J) -- do you agree?
> 
> I do.  I think this applies to other kinds of device too, which might
> have unspecified parameters which get filled in.

Agreed. The docs section I was referring to is generic to all devices,
not just nics (i.e. it talks about libxl_device_<type>_add etc), so a
comment change would (and should) apply to everything.

> 
> Euan, would you like to send us a doc patch for libxl.h ?
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:44:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqkx4-0003ZL-53; Tue, 18 Nov 2014 15:44: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 1Xqkx3-0003ZE-EC
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 15:44:21 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	E8/29-11581-4596B645; Tue, 18 Nov 2014 15:44:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416325456!12072030!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2486 invoked from network); 18 Nov 2014 15:44:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:44:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192517663"
Message-ID: <1416325453.17982.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 18 Nov 2014 15:44:13 +0000
In-Reply-To: <21611.26775.594669.510363@mariner.uk.xensource.com>
References: <20141118152848.GE31225@citrix.com>
	<1416324924.17982.21.camel@citrix.com>
	<21611.26775.594669.510363@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Euan Harris <euan.harris@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add
 an (in)_out parameter?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 15:41 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add an (in)_out parameter?"):
> > On Tue, 2014-11-18 at 15:28 +0000, Euan Harris wrote:
> > > If I call libxl_device_nic_add and pass in a mostly-default
> > > libxl_device_nic structure, the function fills in the unspecified default
> > > config fields with data for the NIC which it has just created:
> ...
> > > Is this behaviour an intentional part of the API which I can rely on,
> > > or just an artefact of the current implementation?  In other words, is
> > > nic meant to be an (in)_out parameter?
> 
> Yes.
> 
> > I believe so, yes. The comment under "Devices" in libxl.h probably ought
> > to be adjusted to say so explicitly.
> > 
> > Ian (J) -- do you agree?
> 
> I do.  I think this applies to other kinds of device too, which might
> have unspecified parameters which get filled in.

Agreed. The docs section I was referring to is generic to all devices,
not just nics (i.e. it talks about libxl_device_<type>_add etc), so a
comment change would (and should) apply to everything.

> 
> Euan, would you like to send us a doc patch for libxl.h ?
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:50:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:50:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xql2c-0003mp-5C; Tue, 18 Nov 2014 15:50:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xql2X-0003mh-GI
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:50:01 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	94/F7-28296-8AA6B645; Tue, 18 Nov 2014 15:50:00 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416325799!12211527!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8662 invoked from network); 18 Nov 2014 15:50:00 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:50:00 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so2299968wiv.11
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 07:49:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=GaBfqHZagIwjTp8Ow/LKj1AY6ajpnvSl8zL3uOe7SzU=;
	b=K+RV3K+uHyFu5325S0PhWeQboerdzJVKnRoCkF8uxXFN2491nm7Q9NjfvdIo3XFviw
	EDjArvYd0Eqykz2DrRmRg2O0jxBKpbpt+bp/vU/sPqkd5DYjNgkmRDmU0sn5VF+MKWYI
	TSjDMD6rLImVVkilfQ70CxvueNGZRCp9jK9MrtlSSluWSs+nwCUGTU6YR05BOGSSZhU5
	Yj0THImIIY8qISNXoBJv20OxaUR5Fmn+aQrP6wVxj0yWAbrKo03/aWZqji4XXzsc34xn
	bN54oxLKOkZZ76dnFbuZNL0DmkOqAI5NiA/smtRmX1HaSvKJClka7ZYWwbvkOnZ0mJj7
	b2Fw==
X-Gm-Message-State: ALoCoQn+F4Y6cg4Kj1wjvyZiXiA/fqc6xSH0aQAc7citCHTb/nbSBaYkoJLETJa86ZRrp2YtGkLW
X-Received: by 10.194.170.232 with SMTP id ap8mr48964275wjc.2.1416325799651;
	Tue, 18 Nov 2014 07:49:59 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	l10sm19992477wif.20.2014.11.18.07.49.58 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 07:49:58 -0800 (PST)
Message-ID: <546B6AA5.1050409@linaro.org>
Date: Tue, 18 Nov 2014 15:49:57 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>	<54535E240200007800043DAC@mail.emea.novell.com>	<546B5F15.5060702@linaro.org>	<21611.24907.144396.509457@mariner.uk.xensource.com>	<546B650D.8040304@linaro.org>
	<21611.26449.963393.613516@mariner.uk.xensource.com>
In-Reply-To: <21611.26449.963393.613516@mariner.uk.xensource.com>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com,
	ian.campbell@citrix.com, Jan Beulich <JBeulich@suse.com>, tim@xen.org
Subject: [Xen-devel] Empty struct in public headers Was: Re: [PATCH for Xen
 4.5] xen/arm: Add support for GICv3 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(Rename the mail and strip the cc list)

On 11/18/2014 03:35 PM, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
>> On 11/18/2014 03:10 PM, Ian Jackson wrote:
>>> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
>>> would be very surprised if clang didn't support them too.
>>
>> AFAIK, clang doesn't complain about empty structures.
> 
> Right.
> 
>>> AIUI our policy, gcc extensions are fine except in the Xen public
>>> headers.
>>
>> We have at least 2 "empty" structure on the ARM public header.
> 
> That ought to be fixed, in case anyone ever wants to build ARM guests
> with Norcroft C or something.
> 
> Does the size of these structs matter ?

The 2 structures are arch_vcpu_info and arch_shared_info.

They are used only at the end of the structure vcpu_info (resp.
shared_info). So I guess we could fix it?

>> Would something like below be better?
>>
>> struct
>> {
>>   int dummy:1
>> };
> 
> I don't see why you wouldn't just do
>    struct blah { char dummy; };
> or even int dummy;

It was to avoid using more bit than necessary. I will use your solution.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 15:50:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 15:50:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xql2c-0003mp-5C; Tue, 18 Nov 2014 15:50:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xql2X-0003mh-GI
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 15:50:01 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	94/F7-28296-8AA6B645; Tue, 18 Nov 2014 15:50:00 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416325799!12211527!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8662 invoked from network); 18 Nov 2014 15:50:00 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 15:50:00 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so2299968wiv.11
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 07:49:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=GaBfqHZagIwjTp8Ow/LKj1AY6ajpnvSl8zL3uOe7SzU=;
	b=K+RV3K+uHyFu5325S0PhWeQboerdzJVKnRoCkF8uxXFN2491nm7Q9NjfvdIo3XFviw
	EDjArvYd0Eqykz2DrRmRg2O0jxBKpbpt+bp/vU/sPqkd5DYjNgkmRDmU0sn5VF+MKWYI
	TSjDMD6rLImVVkilfQ70CxvueNGZRCp9jK9MrtlSSluWSs+nwCUGTU6YR05BOGSSZhU5
	Yj0THImIIY8qISNXoBJv20OxaUR5Fmn+aQrP6wVxj0yWAbrKo03/aWZqji4XXzsc34xn
	bN54oxLKOkZZ76dnFbuZNL0DmkOqAI5NiA/smtRmX1HaSvKJClka7ZYWwbvkOnZ0mJj7
	b2Fw==
X-Gm-Message-State: ALoCoQn+F4Y6cg4Kj1wjvyZiXiA/fqc6xSH0aQAc7citCHTb/nbSBaYkoJLETJa86ZRrp2YtGkLW
X-Received: by 10.194.170.232 with SMTP id ap8mr48964275wjc.2.1416325799651;
	Tue, 18 Nov 2014 07:49:59 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	l10sm19992477wif.20.2014.11.18.07.49.58 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 07:49:58 -0800 (PST)
Message-ID: <546B6AA5.1050409@linaro.org>
Date: Tue, 18 Nov 2014 15:49:57 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>	<54535E240200007800043DAC@mail.emea.novell.com>	<546B5F15.5060702@linaro.org>	<21611.24907.144396.509457@mariner.uk.xensource.com>	<546B650D.8040304@linaro.org>
	<21611.26449.963393.613516@mariner.uk.xensource.com>
In-Reply-To: <21611.26449.963393.613516@mariner.uk.xensource.com>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com,
	ian.campbell@citrix.com, Jan Beulich <JBeulich@suse.com>, tim@xen.org
Subject: [Xen-devel] Empty struct in public headers Was: Re: [PATCH for Xen
 4.5] xen/arm: Add support for GICv3 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(Rename the mail and strip the cc list)

On 11/18/2014 03:35 PM, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
>> On 11/18/2014 03:10 PM, Ian Jackson wrote:
>>> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
>>> would be very surprised if clang didn't support them too.
>>
>> AFAIK, clang doesn't complain about empty structures.
> 
> Right.
> 
>>> AIUI our policy, gcc extensions are fine except in the Xen public
>>> headers.
>>
>> We have at least 2 "empty" structure on the ARM public header.
> 
> That ought to be fixed, in case anyone ever wants to build ARM guests
> with Norcroft C or something.
> 
> Does the size of these structs matter ?

The 2 structures are arch_vcpu_info and arch_shared_info.

They are used only at the end of the structure vcpu_info (resp.
shared_info). So I guess we could fix it?

>> Would something like below be better?
>>
>> struct
>> {
>>   int dummy:1
>> };
> 
> I don't see why you wouldn't just do
>    struct blah { char dummy; };
> or even int dummy;

It was to avoid using more bit than necessary. I will use your solution.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlIu-0004UR-Cf; Tue, 18 Nov 2014 16:06:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqlIt-0004UM-EK
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:06:55 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	EB/11-25714-E9E6B645; Tue, 18 Nov 2014 16:06:54 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416326814!6763952!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31848 invoked from network); 18 Nov 2014 16:06:54 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 18 Nov 2014 16:06:54 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52846 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqlHP-0008HC-Kn; Tue, 18 Nov 2014 17:05:23 +0100
Date: Tue, 18 Nov 2014 17:06:51 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1253521355.20141118170651@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <68258140.20141118160925@eikelenboom.it>
References: <546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, November 18, 2014, 4:09:25 PM, you wrote:


> Tuesday, November 18, 2014, 12:07:41 PM, you wrote:
>> Tuesday, November 18, 2014, 3:49:27 AM, you wrote:
>>> On Mon, Nov 17, 2014 at 11:40:11PM +0100, Sander Eikelenboom wrote:
>>>> 
>>>> Monday, November 17, 2014, 9:43:47 PM, you wrote:
>>>> 

<VERY BIG SNIP>

> When i look at the combination of (2) and (3), It seems it could be an 
> interaction between the two passed through devices and/or different IRQ types.

> So i will now test without #define DIFF_LIST 1 and not passing through the USB controller, see
> if that still crashes, if it doesn't i will see if i can passthrough a device which also only uses legacy
> interrupts instead of MSI / MSI-X, see if that crashes or not.

Just tested without #define DIFF_LIST 1 and only the videograbber passed through 
to that guest and the guest crashed. So that hunch is also debunked.

Hope the xen-syms give you a clue.
--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlIu-0004UR-Cf; Tue, 18 Nov 2014 16:06:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqlIt-0004UM-EK
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:06:55 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	EB/11-25714-E9E6B645; Tue, 18 Nov 2014 16:06:54 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416326814!6763952!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31848 invoked from network); 18 Nov 2014 16:06:54 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 18 Nov 2014 16:06:54 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52846 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqlHP-0008HC-Kn; Tue, 18 Nov 2014 17:05:23 +0100
Date: Tue, 18 Nov 2014 17:06:51 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1253521355.20141118170651@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <68258140.20141118160925@eikelenboom.it>
References: <546629510200007800047BC3@mail.emea.novell.com>
	<1224708950.20141114162052@eikelenboom.it>
	<5466314E0200007800047C90@mail.emea.novell.com>
	<1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, November 18, 2014, 4:09:25 PM, you wrote:


> Tuesday, November 18, 2014, 12:07:41 PM, you wrote:
>> Tuesday, November 18, 2014, 3:49:27 AM, you wrote:
>>> On Mon, Nov 17, 2014 at 11:40:11PM +0100, Sander Eikelenboom wrote:
>>>> 
>>>> Monday, November 17, 2014, 9:43:47 PM, you wrote:
>>>> 

<VERY BIG SNIP>

> When i look at the combination of (2) and (3), It seems it could be an 
> interaction between the two passed through devices and/or different IRQ types.

> So i will now test without #define DIFF_LIST 1 and not passing through the USB controller, see
> if that still crashes, if it doesn't i will see if i can passthrough a device which also only uses legacy
> interrupts instead of MSI / MSI-X, see if that crashes or not.

Just tested without #define DIFF_LIST 1 and only the videograbber passed through 
to that guest and the guest crashed. So that hunch is also debunked.

Hope the xen-syms give you a clue.
--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:11:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:11:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlN6-0004d0-70; Tue, 18 Nov 2014 16:11:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XqlN4-0004cs-En
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:11:14 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	DB/9E-17694-1AF6B645; Tue, 18 Nov 2014 16:11:13 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416327070!12143878!1
X-Originating-IP: [64.18.0.246]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26282 invoked from network); 18 Nov 2014 16:11:12 -0000
Received: from exprod5og115.obsmtp.com (HELO exprod5og115.obsmtp.com)
	(64.18.0.246)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:11:12 -0000
Received: from mail-wi0-f179.google.com ([209.85.212.179]) (using TLSv1) by
	exprod5ob115.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGtvna6SGITSsEE/A4uKeEVALKIu0mhH@postini.com;
	Tue, 18 Nov 2014 08:11:12 PST
Received: by mail-wi0-f179.google.com with SMTP id ex7so13273203wid.0
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:11:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=SFrk2J3bkU8ZuedpNDjLriElIE72v8uXPbw/zpShVCI=;
	b=ICMGp1WxgkuYYlsmbEu7jncdzQAhpHawCZ/NK3gLPSck1Z0DVGMinbcaPiHyTCIWgO
	40TIVioPxH4flOTIZBTWHR+piRuJxDEbwLFBOwAriO3HAfM0l+GlAsQ34hRJ08vEIL3/
	KU/y9TCK0TDYA/tQVRoLhtNqozwsDwB17tezk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=SFrk2J3bkU8ZuedpNDjLriElIE72v8uXPbw/zpShVCI=;
	b=C7h/IpCqTFC6YRAcLHUG1VgDasCtSWB1J33VTnQxnyh2bibXBgzgfNI7/9Dj2ldjla
	K+ktibQfXenqJC3UAKPeQeIMgYd5jiRKUUklNGhJ4d0UBw+0cEyVUfpQb1eUDYmfowqP
	WeRN3BWGgkiflCuS6E7h4ogl7fmLOrZ8fJ5T+iAXNJw0dFPLUmXojjvGh+pFEbusqoH2
	jAIv9wdeWRF/zitw9dJ9nC6HdQnxIDHqdlxtmkYfuWzypFDKFH17payhCw5CSN5VwXeg
	wY3MnberbbwtyA9RE6qG7XFjuJjnmBLmLi7km/4WDWz2oBIC/mAVUVFq6cPGIc4Jm9DA
	y/XA==
X-Gm-Message-State: ALoCoQls/gJ629UgmyNgMS/Xq4PGN3PmGU44P4l/8SJrVd6ejPvnqoMZjQ3NwBPDW2Q0DIqBClzb0TAF43u7Ia4OLzWF5ysHo4XVWNM3/w/NXUoniI0L9KvEAF6papHFdwXphBWSRAelH3m92Rar4KKsMyzGO219Vg==
X-Received: by 10.194.189.81 with SMTP id gg17mr21402520wjc.115.1416327068855; 
	Tue, 18 Nov 2014 08:11:08 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.189.81 with SMTP id gg17mr21402495wjc.115.1416327068688; 
	Tue, 18 Nov 2014 08:11:08 -0800 (PST)
Received: by 10.112.61.69 with HTTP; Tue, 18 Nov 2014 08:11:08 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
Date: Tue, 18 Nov 2014 18:11:08 +0200
Message-ID: <CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

What if I try on top of current master branch the following code:

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..6764ab7 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -36,6 +36,8 @@
 #include <asm/io.h>
 #include <asm/gic.h>

+#define GIC_DEBUG 1
+
 /*
  * LR register definitions are GIC v2 specific.
  * Moved these definitions from header file to here
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index bcaded9..c03d6a6 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);

 #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
gic_hw_ops->info->nr_lrs) - 1))

-#undef GIC_DEBUG
+#define GIC_DEBUG 1

 static void gic_update_one_lr(struct vcpu *v, int i);

It is equivalent to what you proposing - my code contains
PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
be executed:
 lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function

regards,
Andrii

On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>> everything works fine
>> The following 2 patches fixes xen/master for my platform.
>>
>> Stefano, could you please take a look to these changes?
>>
>> commit 3628a0aa35706a8f532af865ed784536ce514eca
>> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> Date:   Tue Nov 18 14:20:42 2014 +0200
>>
>>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>>
>>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index 31fb81a..093ecdb 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>> pending_irq *p,
>>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>> GICH_V2_LR_VIRTUAL_SHIFT));
>>
>> -    if ( p->desc != NULL )
>> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>>      {
>> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> -        else
>> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>> GICH_V2_LR_PHYSICAL_MASK )
>> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> +    }
>> +    else if ( p->desc != NULL )
>> +    {
>> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>>      }
>>
>>      writel_gich(lr_reg, GICH_LR + lr * 4);
>
> Actually in case p->desc == NULL (the irq is not an hardware irq, it
> could be the virtual timer irq or the evtchn irq), you shouldn't need
> the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> working correctly on OMAP5. This changes might only be better at
> "hiding" the real issue.
>
> Maybe the problem is exactly the opposite: the new scheme for avoiding
> maintenance interrupts doesn't work for software interrupts.
> The commit that should make them work correctly after the
> no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> If you look at the changes to gic_update_one_lr in that commit, you'll
> see that is going to set a software irq as PENDING if it is already ACTIVE.
> Maybe that doesn't work correctly on OMAP5.
>
> Could you try this patch on top of
> 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> if the problem is specifically with software irqs.
>
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index b7516c0..d8a17c9 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>  /* Maximum cpu interface per GIC */
>  #define NR_GIC_CPU_IF 8
>
> -#undef GIC_DEBUG
> +#define GIC_DEBUG 1
>
>  static void gic_update_one_lr(struct vcpu *v, int i);
>
> @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>      if ( p->desc != NULL )
>          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> +    else
> +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>
>      GICH[GICH_LR + lr] = lr_val;
>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:11:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:11:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlN6-0004d0-70; Tue, 18 Nov 2014 16:11:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XqlN4-0004cs-En
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:11:14 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	DB/9E-17694-1AF6B645; Tue, 18 Nov 2014 16:11:13 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416327070!12143878!1
X-Originating-IP: [64.18.0.246]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26282 invoked from network); 18 Nov 2014 16:11:12 -0000
Received: from exprod5og115.obsmtp.com (HELO exprod5og115.obsmtp.com)
	(64.18.0.246)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:11:12 -0000
Received: from mail-wi0-f179.google.com ([209.85.212.179]) (using TLSv1) by
	exprod5ob115.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGtvna6SGITSsEE/A4uKeEVALKIu0mhH@postini.com;
	Tue, 18 Nov 2014 08:11:12 PST
Received: by mail-wi0-f179.google.com with SMTP id ex7so13273203wid.0
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:11:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=SFrk2J3bkU8ZuedpNDjLriElIE72v8uXPbw/zpShVCI=;
	b=ICMGp1WxgkuYYlsmbEu7jncdzQAhpHawCZ/NK3gLPSck1Z0DVGMinbcaPiHyTCIWgO
	40TIVioPxH4flOTIZBTWHR+piRuJxDEbwLFBOwAriO3HAfM0l+GlAsQ34hRJ08vEIL3/
	KU/y9TCK0TDYA/tQVRoLhtNqozwsDwB17tezk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=SFrk2J3bkU8ZuedpNDjLriElIE72v8uXPbw/zpShVCI=;
	b=C7h/IpCqTFC6YRAcLHUG1VgDasCtSWB1J33VTnQxnyh2bibXBgzgfNI7/9Dj2ldjla
	K+ktibQfXenqJC3UAKPeQeIMgYd5jiRKUUklNGhJ4d0UBw+0cEyVUfpQb1eUDYmfowqP
	WeRN3BWGgkiflCuS6E7h4ogl7fmLOrZ8fJ5T+iAXNJw0dFPLUmXojjvGh+pFEbusqoH2
	jAIv9wdeWRF/zitw9dJ9nC6HdQnxIDHqdlxtmkYfuWzypFDKFH17payhCw5CSN5VwXeg
	wY3MnberbbwtyA9RE6qG7XFjuJjnmBLmLi7km/4WDWz2oBIC/mAVUVFq6cPGIc4Jm9DA
	y/XA==
X-Gm-Message-State: ALoCoQls/gJ629UgmyNgMS/Xq4PGN3PmGU44P4l/8SJrVd6ejPvnqoMZjQ3NwBPDW2Q0DIqBClzb0TAF43u7Ia4OLzWF5ysHo4XVWNM3/w/NXUoniI0L9KvEAF6papHFdwXphBWSRAelH3m92Rar4KKsMyzGO219Vg==
X-Received: by 10.194.189.81 with SMTP id gg17mr21402520wjc.115.1416327068855; 
	Tue, 18 Nov 2014 08:11:08 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.189.81 with SMTP id gg17mr21402495wjc.115.1416327068688; 
	Tue, 18 Nov 2014 08:11:08 -0800 (PST)
Received: by 10.112.61.69 with HTTP; Tue, 18 Nov 2014 08:11:08 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMPUSvKwkOKYapEC5Ajyk83yVCiS3MopVgGcCO+Y0HWChg@mail.gmail.com>
	<alpine.DEB.2.02.1411141520470.26318@kaball.uk.xensource.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
Date: Tue, 18 Nov 2014 18:11:08 +0200
Message-ID: <CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

What if I try on top of current master branch the following code:

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..6764ab7 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -36,6 +36,8 @@
 #include <asm/io.h>
 #include <asm/gic.h>

+#define GIC_DEBUG 1
+
 /*
  * LR register definitions are GIC v2 specific.
  * Moved these definitions from header file to here
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index bcaded9..c03d6a6 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);

 #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
gic_hw_ops->info->nr_lrs) - 1))

-#undef GIC_DEBUG
+#define GIC_DEBUG 1

 static void gic_update_one_lr(struct vcpu *v, int i);

It is equivalent to what you proposing - my code contains
PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
be executed:
 lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function

regards,
Andrii

On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>> everything works fine
>> The following 2 patches fixes xen/master for my platform.
>>
>> Stefano, could you please take a look to these changes?
>>
>> commit 3628a0aa35706a8f532af865ed784536ce514eca
>> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> Date:   Tue Nov 18 14:20:42 2014 +0200
>>
>>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>>
>>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index 31fb81a..093ecdb 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>> pending_irq *p,
>>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>> GICH_V2_LR_VIRTUAL_SHIFT));
>>
>> -    if ( p->desc != NULL )
>> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>>      {
>> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> -        else
>> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>> GICH_V2_LR_PHYSICAL_MASK )
>> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> +    }
>> +    else if ( p->desc != NULL )
>> +    {
>> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>>      }
>>
>>      writel_gich(lr_reg, GICH_LR + lr * 4);
>
> Actually in case p->desc == NULL (the irq is not an hardware irq, it
> could be the virtual timer irq or the evtchn irq), you shouldn't need
> the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> working correctly on OMAP5. This changes might only be better at
> "hiding" the real issue.
>
> Maybe the problem is exactly the opposite: the new scheme for avoiding
> maintenance interrupts doesn't work for software interrupts.
> The commit that should make them work correctly after the
> no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> If you look at the changes to gic_update_one_lr in that commit, you'll
> see that is going to set a software irq as PENDING if it is already ACTIVE.
> Maybe that doesn't work correctly on OMAP5.
>
> Could you try this patch on top of
> 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> if the problem is specifically with software irqs.
>
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index b7516c0..d8a17c9 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>  /* Maximum cpu interface per GIC */
>  #define NR_GIC_CPU_IF 8
>
> -#undef GIC_DEBUG
> +#define GIC_DEBUG 1
>
>  static void gic_update_one_lr(struct vcpu *v, int i);
>
> @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>      if ( p->desc != NULL )
>          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> +    else
> +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>
>      GICH[GICH_LR + lr] = lr_val;
>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:15:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 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 1XqlR2-0004ol-0y; Tue, 18 Nov 2014 16:15:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqlR1-0004of-7q
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:15:19 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	48/FC-09842-6907B645; Tue, 18 Nov 2014 16:15:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416327315!13663116!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25968 invoked from network); 18 Nov 2014 16:15:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:15:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194039554"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:14:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqlQU-0007jh-Tb;
	Tue, 18 Nov 2014 16:14:46 +0000
Date: Tue, 18 Nov 2014 16:14:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
for non-hardware irqs (desc == NULL) and keep avoiding
GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.

Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
other potential bugs introduced later.

On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> What if I try on top of current master branch the following code:
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 31fb81a..6764ab7 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -36,6 +36,8 @@
>  #include <asm/io.h>
>  #include <asm/gic.h>
> 
> +#define GIC_DEBUG 1
> +
>  /*
>   * LR register definitions are GIC v2 specific.
>   * Moved these definitions from header file to here
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index bcaded9..c03d6a6 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> 
>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> gic_hw_ops->info->nr_lrs) - 1))
> 
> -#undef GIC_DEBUG
> +#define GIC_DEBUG 1
> 
>  static void gic_update_one_lr(struct vcpu *v, int i);
> 
> It is equivalent to what you proposing - my code contains
> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> be executed:
>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> 
> regards,
> Andrii
> 
> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> >> everything works fine
> >> The following 2 patches fixes xen/master for my platform.
> >>
> >> Stefano, could you please take a look to these changes?
> >>
> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> >>
> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> >>
> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >>
> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> index 31fb81a..093ecdb 100644
> >> --- a/xen/arch/arm/gic-v2.c
> >> +++ b/xen/arch/arm/gic-v2.c
> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> >> pending_irq *p,
> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> >> GICH_V2_LR_VIRTUAL_SHIFT));
> >>
> >> -    if ( p->desc != NULL )
> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >>      {
> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> -        else
> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> >> GICH_V2_LR_PHYSICAL_MASK )
> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> +    }
> >> +    else if ( p->desc != NULL )
> >> +    {
> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> >>      }
> >>
> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> >
> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> > working correctly on OMAP5. This changes might only be better at
> > "hiding" the real issue.
> >
> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> > maintenance interrupts doesn't work for software interrupts.
> > The commit that should make them work correctly after the
> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> > If you look at the changes to gic_update_one_lr in that commit, you'll
> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> > Maybe that doesn't work correctly on OMAP5.
> >
> > Could you try this patch on top of
> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> > if the problem is specifically with software irqs.
> >
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index b7516c0..d8a17c9 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> >  /* Maximum cpu interface per GIC */
> >  #define NR_GIC_CPU_IF 8
> >
> > -#undef GIC_DEBUG
> > +#define GIC_DEBUG 1
> >
> >  static void gic_update_one_lr(struct vcpu *v, int i);
> >
> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >      if ( p->desc != NULL )
> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> > +    else
> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> >
> >      GICH[GICH_LR + lr] = lr_val;
> >
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:15:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 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 1XqlR2-0004ol-0y; Tue, 18 Nov 2014 16:15:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqlR1-0004of-7q
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:15:19 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	48/FC-09842-6907B645; Tue, 18 Nov 2014 16:15:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416327315!13663116!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25968 invoked from network); 18 Nov 2014 16:15:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:15:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194039554"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:14:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqlQU-0007jh-Tb;
	Tue, 18 Nov 2014 16:14:46 +0000
Date: Tue, 18 Nov 2014 16:14:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
for non-hardware irqs (desc == NULL) and keep avoiding
GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.

Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
other potential bugs introduced later.

On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> What if I try on top of current master branch the following code:
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 31fb81a..6764ab7 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -36,6 +36,8 @@
>  #include <asm/io.h>
>  #include <asm/gic.h>
> 
> +#define GIC_DEBUG 1
> +
>  /*
>   * LR register definitions are GIC v2 specific.
>   * Moved these definitions from header file to here
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index bcaded9..c03d6a6 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> 
>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> gic_hw_ops->info->nr_lrs) - 1))
> 
> -#undef GIC_DEBUG
> +#define GIC_DEBUG 1
> 
>  static void gic_update_one_lr(struct vcpu *v, int i);
> 
> It is equivalent to what you proposing - my code contains
> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> be executed:
>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> 
> regards,
> Andrii
> 
> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> >> everything works fine
> >> The following 2 patches fixes xen/master for my platform.
> >>
> >> Stefano, could you please take a look to these changes?
> >>
> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> >>
> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> >>
> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >>
> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> index 31fb81a..093ecdb 100644
> >> --- a/xen/arch/arm/gic-v2.c
> >> +++ b/xen/arch/arm/gic-v2.c
> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> >> pending_irq *p,
> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> >> GICH_V2_LR_VIRTUAL_SHIFT));
> >>
> >> -    if ( p->desc != NULL )
> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >>      {
> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> -        else
> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> >> GICH_V2_LR_PHYSICAL_MASK )
> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> +    }
> >> +    else if ( p->desc != NULL )
> >> +    {
> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> >>      }
> >>
> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> >
> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> > working correctly on OMAP5. This changes might only be better at
> > "hiding" the real issue.
> >
> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> > maintenance interrupts doesn't work for software interrupts.
> > The commit that should make them work correctly after the
> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> > If you look at the changes to gic_update_one_lr in that commit, you'll
> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> > Maybe that doesn't work correctly on OMAP5.
> >
> > Could you try this patch on top of
> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> > if the problem is specifically with software irqs.
> >
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index b7516c0..d8a17c9 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> >  /* Maximum cpu interface per GIC */
> >  #define NR_GIC_CPU_IF 8
> >
> > -#undef GIC_DEBUG
> > +#define GIC_DEBUG 1
> >
> >  static void gic_update_one_lr(struct vcpu *v, int i);
> >
> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >      if ( p->desc != NULL )
> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> > +    else
> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> >
> >      GICH[GICH_LR + lr] = lr_val;
> >
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:15:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:15:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlRL-0004rM-Lb; Tue, 18 Nov 2014 16:15:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqlRK-0004r6-7E
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:15:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	56/9D-09842-9A07B645; Tue, 18 Nov 2014 16:15:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416327336!6352730!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11001 invoked from network); 18 Nov 2014 16:15:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:15:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 16:15:35 +0000
Message-Id: <546B7EB60200007800048D20@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 16:15:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
In-Reply-To: <546B5F15.5060702@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 16:00, <julien.grall@linaro.org> wrote:
> On 10/31/2014 09:02 AM, Jan Beulich wrote:
>>>>> On 30.10.14 at 19:51, <julien.grall@linaro.org> wrote:
>> The naming suggests that the #if really should be around just the
>> gic_version field (with a dummy field in the #else case to be C89
>> compatible, e.g. a zero width unnamed bitfield) and the
>> corresponding #define-s above, ...
> 
> Not really related to this patch... but the way to improve it (via
> extending createdomain).
> 
> I need to create an empty structure. Is the dummy field really needed?
> If so, did you meant?
> 
> struct
> {
>    int :0;
> }

Yes.

> The C spec declare this kind of structure as undefined.

I can't find anything saying so.

> Would an empty structure and used it be better?

Empty structures (and unions) aren't valid in standard C afaics, up to
and including C11. That was the whole point of suggesting the above
alternative, with me (maybe wrongly) believing that this would be valid.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:15:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:15:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlRL-0004rM-Lb; Tue, 18 Nov 2014 16:15:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqlRK-0004r6-7E
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:15:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	56/9D-09842-9A07B645; Tue, 18 Nov 2014 16:15:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416327336!6352730!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11001 invoked from network); 18 Nov 2014 16:15:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:15:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 16:15:35 +0000
Message-Id: <546B7EB60200007800048D20@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 16:15:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
In-Reply-To: <546B5F15.5060702@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 16:00, <julien.grall@linaro.org> wrote:
> On 10/31/2014 09:02 AM, Jan Beulich wrote:
>>>>> On 30.10.14 at 19:51, <julien.grall@linaro.org> wrote:
>> The naming suggests that the #if really should be around just the
>> gic_version field (with a dummy field in the #else case to be C89
>> compatible, e.g. a zero width unnamed bitfield) and the
>> corresponding #define-s above, ...
> 
> Not really related to this patch... but the way to improve it (via
> extending createdomain).
> 
> I need to create an empty structure. Is the dummy field really needed?
> If so, did you meant?
> 
> struct
> {
>    int :0;
> }

Yes.

> The C spec declare this kind of structure as undefined.

I can't find anything saying so.

> Would an empty structure and used it be better?

Empty structures (and unions) aren't valid in standard C afaics, up to
and including C11. That was the whole point of suggesting the above
alternative, with me (maybe wrongly) believing that this would be valid.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:17:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:17:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlSn-000522-82; Tue, 18 Nov 2014 16:17:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqlSl-00051a-Su
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:17:08 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	D6/93-02697-3017B645; Tue, 18 Nov 2014 16:17:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416327425!12044140!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20143 invoked from network); 18 Nov 2014 16:17:06 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:17:06 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIGGt0N018215
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Nov 2014 16:16:55 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIGGsFc018435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 18 Nov 2014 16:16:55 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIGGrPo005004; Tue, 18 Nov 2014 16:16:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 08:16:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0726C1179AB; Tue, 18 Nov 2014 11:16:50 -0500 (EST)
Date: Tue, 18 Nov 2014 11:16:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141118161650.GC17095@laptop.dumpdata.com>
References: <1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <68258140.20141118160925@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Without #define DIFF_LIST 1:
> 1) The guest still crashes (xl-dmesg-not-defined.txt)

AHA!

 --MARK--
  0: ffff8305085ffd28 [p:ffff83054ef27e88, n:ffff83054ef27e88]
  1: ffff8305085ffd28 [p:0200200200200200, n:0100100100100100]

The same pirq_dpci structure is put twice on the list. That
will surely make it unhappy. The reason the #define DIFF_LIST 1
would work is that it has code to deal with that odd scenario.

But .. more importantly - the code should not allow you to
put _two_ of the same 'pirq_dpci' structures on the list.

 CPU00: 
 d16 OK-softirq 186msec ago, state:1, 3257 count, [prev:ffff82d0802e7e88, next:ffff82d0802e7e88] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 d16 OK-raise   236msec ago, state:1, 3257 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 CPU01: 
 d16 OK-softirq 232msec ago, state:1, 2978 count, [prev:ffff83054ef57e70, next:ffff83054ef57e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 d16 OK-raise   281msec ago, state:1, 2978 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 CPU02: 
 d16 OK-softirq 373msec ago, state:1, 2378 count, [prev:ffff83054ef47e70, next:ffff83054ef47e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 d16 OK-raise   423msec ago, state:1, 2378 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 CPU03: 
 d16 OK-softirq 867msec ago, state:1, 2744 count, [prev:ffff83054ef37e70, next:ffff83054ef37e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 d16 OK-raise   916msec ago, state:1, 2744 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 CPU04: 
 d16 OK-softirq 497msec ago, state:1, 76910 count, [prev:ffff83054ef2e3e0, next:ffff83054ef2e3e0] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
 d16 OK-raise   489msec ago, state:1, 76916 count, [prev:ffff83054ef2e3e0, next:ffff83054ef2e3e0] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
 d16 ERR-poison 600msec ago, state:0, 1 count, [prev:0200200200200200, next:0100100100100100] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
 CPU05: 
 d16 OK-softirq 852msec ago, state:1, 2207 count, [prev:ffff83054ef1fe70, next:ffff83054ef1fe70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 d16 OK-raise   902msec ago, state:1, 2207 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 domain_crash called from io.c:964
 Domain 16 reported crashed by domain 7 on cpu#4:


> 
> With #define DIFF_LIST 1:
> 2) Nor the guest or the host crashed (let it run for about an hour and 15 minutes), 
>    but the USB XHCI driver bailed out quickly after guest boot, so there were no MSI-X interrupts anymore.
>    (xl-dmesg-defined-nousb.txt, dmesg-guest-defined-nousb.txt)

Hm, that is odd. Can you tell me how you get your SeaBIOS to add those
extra statements? I don't seem to see them with my SeaBIOS (I've an XHCI
controlled hooked up to the guest too). Maybe I am missing an CONFIG in the
SeaBIOS build.

> 3) On another boot the USB XHCI didn't bail out, after a while the host crashes. (serial.log)
>    (XEN) [2014-11-18 14:53:37.364] RIP:    e008:[<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
>    which resolves to:
>    # addr2line -e xen-syms ffff82d08014a4de
>    /usr/src/new/xen-unstable-vanilla/xen/include/xen/list.h:67
>    which is:
>    static inline void __list_add(struct list_head *new,
>                               struct list_head *prev,
>                               struct list_head *next)
>     {
>     next->prev = new;
>     new->next = next;
>     new->prev = prev;
> Here ->    prev->next = new;
>     }

Looking at the stack:


(XEN) [2014-11-18 14:53:37.306]  0: ffff8303faaf25a8 [p:ffff83054ef2e3e0, n:ffff83054ef2e3e0]

We detected that the list was poison and were printing it, while an:

 ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
 CPU:    4
 RIP:    e008:[<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
 RFLAGS: 0000000000010082   CONTEXT: hypervisor
 rax: ffff83054ef2e3e0   rbx: ffff8303faaf25a8   rcx: ffff8303faaf2610
 rdx: 0200200200200200   rsi: 0000000000000006   rdi: 000000006ef3f123
 rbp: ffff83054ef27be8   rsp: ffff83054ef27bd8   r8:  ffff8303faaf2010
 r9:  000000000000002f   r10: 0000000000000132   r11: 0000000000000003
 r12: ffff8305125d6000   r13: 0000000000000000   r14: ffff8303faaf2580
 r15: 000000000000002f   cr0: 000000008005003b   cr4: 00000000000006f0
 cr3: 00000005448c0000   cr2: ffffffffff600400
 ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
 Xen stack trace from rsp=ffff83054ef27bd8:
    ffff83054ef27be8 ffff8303faaf26c0 ffff83054ef27c78 ffff82d080172060
    0000000000000020 ffff83054ef27cf6 0000000000000046 ffff83054ef27c70
    ffff82d000000000 ffff83055d002f24 0000000000000000 0000002f4ef27c40
    ffff83054ef27c48 ffff82d08014434f ffff83054ef27c60 0000000000000000
    ffff82d08025efdc 0000000000000200 ffff83054ef27d78 0000000000000003
    00007cfab10d8357 ffff82d080233122 0000000000000003 ffff83054ef27d78
    0000000000000200 ffff82d08025efdc ffff83054ef27d60 0000000000000000
    0000000000000003 0000000000000132 0000000000000003 ffff83054ef80000
    0000000000000000 0000000000000000 ffff83054ef20000 000000000000000a
    ffff82d0802966c0 000000d100000000 ffff82d0801439ba 000000000000e008
    0000000000000206 ffff83054ef27d30 000000000000e010 ffff83054ef27d60
    ffff82d08030961e ffff83054ef2e378 ffff83054ef27e10 0000000000000000
    ffff82d08025f37e ffff83054ef27dc0 ffff82d080143eda ffff82d0802967a0
    0000000000000028 ffff83054ef27dd0 ffff83054ef27d90 ffff83054ef27da0
    0000000000000000 ffff8303faaf25a8 ffff83054ef2e3e0 ffff83054ef2e3e0
    000001785db75800 ffff83054ef27eb0 ffff82d0801495c0 ffff82d080233122
    ffff83054ef2e378 ffff83054ef27e00 ffff83054ef2e4e0 ffff83054ef2e400
    0000000300000000 ffff8305125d60b8 ffff83054ef27e70 ffff83054ef2e3e0
    ffff83054ef2e3e0 ffff8303faaf25a8 ffff83054ef2e3e0 ffff83054ef2e3e0
    ffff83054ef2e378 0100100100100100 0200200200200200 ffff83054ef2e378
 Xen call trace:
    [<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
    [<ffff82d080172060>] do_IRQ+0x49c/0x624

and interrupt came in. Said interrupt ended up calling 'raise_softirq'
and added itself on the list. But the list is corrupted and
it below up.

Now the oddidity is that the 'prev' in this case is the per-cpu list -
which should be cleared with 'list_splice_init' which INIT_LIST_HEAD() which
resets the list!

First of it should not even enter in the 'raise_softirq' as:
[I suppose that ffff8303faaf25a8 has already been cleared but the
second item in the dpci_list is also ffff8303faaf25a8].

 186     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )                     
 187         return;                                                                 

is set..  

    [<ffff82d080233122>] common_interrupt+0x62/0x70
    [<ffff82d0801439ba>] vprintk_common+0x131/0x13e
    [<ffff82d080143eda>] printk+0x46/0x48
    [<ffff82d0801495c0>] dpci_softirq+0x199/0x3e2
    [<ffff82d08012be31>] __do_softirq+0x81/0x8c
    [<ffff82d08012be89>] do_softirq+0x13/0x15
    [<ffff82d0801633e5>] idle_loop+0x5e/0x6e

OK, so it looks like a couple of things are not happening on your
machine:

 1) test_and_[set|clear]_bit sometimes return unexpected values.
    [But this might be invalid as the addition of the ffff8303faaf25a8
     might be correct - as the second dpci the softirq is processing
     could be the MSI one]
 2) INIT_LIST_HEAD operations on the same CPU are not honored.

> 
> When i look at the combination of (2) and (3), It seems it could be an 
> interaction between the two passed through devices and/or different IRQ types.

Could be - as in it is causing this issue to show up faster than
expected. Or it is the one that triggers more than one dpci happening
at the same time.
> 
> So i will now test without #define DIFF_LIST 1 and not passing through the USB controller, see
> if that still crashes, if it doesn't i will see if i can passthrough a device which also only uses legacy
> interrupts instead of MSI / MSI-X, see if that crashes or not.

Right. I believe the issue you are triggering is that two or more
'pirq_dpci' are added on the per-cpu list. Having them different
is fine (so one serving MSI the other IRQ), but having them the same is a no-go.
Somehow you are triggering the later.


Is your machine by any chance set to 'Aggressive' memory setting? My ASUS
box has that setting and while it works great with games, Xen ends up hitting
some rather strange lockups that I can only blame on that.

> 
> >> Thank you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:17:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:17:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlSn-000522-82; Tue, 18 Nov 2014 16:17:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqlSl-00051a-Su
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:17:08 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	D6/93-02697-3017B645; Tue, 18 Nov 2014 16:17:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416327425!12044140!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20143 invoked from network); 18 Nov 2014 16:17:06 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:17:06 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIGGt0N018215
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Nov 2014 16:16:55 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIGGsFc018435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 18 Nov 2014 16:16:55 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIGGrPo005004; Tue, 18 Nov 2014 16:16:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 08:16:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0726C1179AB; Tue, 18 Nov 2014 11:16:50 -0500 (EST)
Date: Tue, 18 Nov 2014 11:16:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141118161650.GC17095@laptop.dumpdata.com>
References: <1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <68258140.20141118160925@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Without #define DIFF_LIST 1:
> 1) The guest still crashes (xl-dmesg-not-defined.txt)

AHA!

 --MARK--
  0: ffff8305085ffd28 [p:ffff83054ef27e88, n:ffff83054ef27e88]
  1: ffff8305085ffd28 [p:0200200200200200, n:0100100100100100]

The same pirq_dpci structure is put twice on the list. That
will surely make it unhappy. The reason the #define DIFF_LIST 1
would work is that it has code to deal with that odd scenario.

But .. more importantly - the code should not allow you to
put _two_ of the same 'pirq_dpci' structures on the list.

 CPU00: 
 d16 OK-softirq 186msec ago, state:1, 3257 count, [prev:ffff82d0802e7e88, next:ffff82d0802e7e88] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 d16 OK-raise   236msec ago, state:1, 3257 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 CPU01: 
 d16 OK-softirq 232msec ago, state:1, 2978 count, [prev:ffff83054ef57e70, next:ffff83054ef57e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 d16 OK-raise   281msec ago, state:1, 2978 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 CPU02: 
 d16 OK-softirq 373msec ago, state:1, 2378 count, [prev:ffff83054ef47e70, next:ffff83054ef47e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 d16 OK-raise   423msec ago, state:1, 2378 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 CPU03: 
 d16 OK-softirq 867msec ago, state:1, 2744 count, [prev:ffff83054ef37e70, next:ffff83054ef37e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 d16 OK-raise   916msec ago, state:1, 2744 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 CPU04: 
 d16 OK-softirq 497msec ago, state:1, 76910 count, [prev:ffff83054ef2e3e0, next:ffff83054ef2e3e0] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
 d16 OK-raise   489msec ago, state:1, 76916 count, [prev:ffff83054ef2e3e0, next:ffff83054ef2e3e0] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
 d16 ERR-poison 600msec ago, state:0, 1 count, [prev:0200200200200200, next:0100100100100100] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
 CPU05: 
 d16 OK-softirq 852msec ago, state:1, 2207 count, [prev:ffff83054ef1fe70, next:ffff83054ef1fe70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 d16 OK-raise   902msec ago, state:1, 2207 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 domain_crash called from io.c:964
 Domain 16 reported crashed by domain 7 on cpu#4:


> 
> With #define DIFF_LIST 1:
> 2) Nor the guest or the host crashed (let it run for about an hour and 15 minutes), 
>    but the USB XHCI driver bailed out quickly after guest boot, so there were no MSI-X interrupts anymore.
>    (xl-dmesg-defined-nousb.txt, dmesg-guest-defined-nousb.txt)

Hm, that is odd. Can you tell me how you get your SeaBIOS to add those
extra statements? I don't seem to see them with my SeaBIOS (I've an XHCI
controlled hooked up to the guest too). Maybe I am missing an CONFIG in the
SeaBIOS build.

> 3) On another boot the USB XHCI didn't bail out, after a while the host crashes. (serial.log)
>    (XEN) [2014-11-18 14:53:37.364] RIP:    e008:[<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
>    which resolves to:
>    # addr2line -e xen-syms ffff82d08014a4de
>    /usr/src/new/xen-unstable-vanilla/xen/include/xen/list.h:67
>    which is:
>    static inline void __list_add(struct list_head *new,
>                               struct list_head *prev,
>                               struct list_head *next)
>     {
>     next->prev = new;
>     new->next = next;
>     new->prev = prev;
> Here ->    prev->next = new;
>     }

Looking at the stack:


(XEN) [2014-11-18 14:53:37.306]  0: ffff8303faaf25a8 [p:ffff83054ef2e3e0, n:ffff83054ef2e3e0]

We detected that the list was poison and were printing it, while an:

 ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
 CPU:    4
 RIP:    e008:[<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
 RFLAGS: 0000000000010082   CONTEXT: hypervisor
 rax: ffff83054ef2e3e0   rbx: ffff8303faaf25a8   rcx: ffff8303faaf2610
 rdx: 0200200200200200   rsi: 0000000000000006   rdi: 000000006ef3f123
 rbp: ffff83054ef27be8   rsp: ffff83054ef27bd8   r8:  ffff8303faaf2010
 r9:  000000000000002f   r10: 0000000000000132   r11: 0000000000000003
 r12: ffff8305125d6000   r13: 0000000000000000   r14: ffff8303faaf2580
 r15: 000000000000002f   cr0: 000000008005003b   cr4: 00000000000006f0
 cr3: 00000005448c0000   cr2: ffffffffff600400
 ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
 Xen stack trace from rsp=ffff83054ef27bd8:
    ffff83054ef27be8 ffff8303faaf26c0 ffff83054ef27c78 ffff82d080172060
    0000000000000020 ffff83054ef27cf6 0000000000000046 ffff83054ef27c70
    ffff82d000000000 ffff83055d002f24 0000000000000000 0000002f4ef27c40
    ffff83054ef27c48 ffff82d08014434f ffff83054ef27c60 0000000000000000
    ffff82d08025efdc 0000000000000200 ffff83054ef27d78 0000000000000003
    00007cfab10d8357 ffff82d080233122 0000000000000003 ffff83054ef27d78
    0000000000000200 ffff82d08025efdc ffff83054ef27d60 0000000000000000
    0000000000000003 0000000000000132 0000000000000003 ffff83054ef80000
    0000000000000000 0000000000000000 ffff83054ef20000 000000000000000a
    ffff82d0802966c0 000000d100000000 ffff82d0801439ba 000000000000e008
    0000000000000206 ffff83054ef27d30 000000000000e010 ffff83054ef27d60
    ffff82d08030961e ffff83054ef2e378 ffff83054ef27e10 0000000000000000
    ffff82d08025f37e ffff83054ef27dc0 ffff82d080143eda ffff82d0802967a0
    0000000000000028 ffff83054ef27dd0 ffff83054ef27d90 ffff83054ef27da0
    0000000000000000 ffff8303faaf25a8 ffff83054ef2e3e0 ffff83054ef2e3e0
    000001785db75800 ffff83054ef27eb0 ffff82d0801495c0 ffff82d080233122
    ffff83054ef2e378 ffff83054ef27e00 ffff83054ef2e4e0 ffff83054ef2e400
    0000000300000000 ffff8305125d60b8 ffff83054ef27e70 ffff83054ef2e3e0
    ffff83054ef2e3e0 ffff8303faaf25a8 ffff83054ef2e3e0 ffff83054ef2e3e0
    ffff83054ef2e378 0100100100100100 0200200200200200 ffff83054ef2e378
 Xen call trace:
    [<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
    [<ffff82d080172060>] do_IRQ+0x49c/0x624

and interrupt came in. Said interrupt ended up calling 'raise_softirq'
and added itself on the list. But the list is corrupted and
it below up.

Now the oddidity is that the 'prev' in this case is the per-cpu list -
which should be cleared with 'list_splice_init' which INIT_LIST_HEAD() which
resets the list!

First of it should not even enter in the 'raise_softirq' as:
[I suppose that ffff8303faaf25a8 has already been cleared but the
second item in the dpci_list is also ffff8303faaf25a8].

 186     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )                     
 187         return;                                                                 

is set..  

    [<ffff82d080233122>] common_interrupt+0x62/0x70
    [<ffff82d0801439ba>] vprintk_common+0x131/0x13e
    [<ffff82d080143eda>] printk+0x46/0x48
    [<ffff82d0801495c0>] dpci_softirq+0x199/0x3e2
    [<ffff82d08012be31>] __do_softirq+0x81/0x8c
    [<ffff82d08012be89>] do_softirq+0x13/0x15
    [<ffff82d0801633e5>] idle_loop+0x5e/0x6e

OK, so it looks like a couple of things are not happening on your
machine:

 1) test_and_[set|clear]_bit sometimes return unexpected values.
    [But this might be invalid as the addition of the ffff8303faaf25a8
     might be correct - as the second dpci the softirq is processing
     could be the MSI one]
 2) INIT_LIST_HEAD operations on the same CPU are not honored.

> 
> When i look at the combination of (2) and (3), It seems it could be an 
> interaction between the two passed through devices and/or different IRQ types.

Could be - as in it is causing this issue to show up faster than
expected. Or it is the one that triggers more than one dpci happening
at the same time.
> 
> So i will now test without #define DIFF_LIST 1 and not passing through the USB controller, see
> if that still crashes, if it doesn't i will see if i can passthrough a device which also only uses legacy
> interrupts instead of MSI / MSI-X, see if that crashes or not.

Right. I believe the issue you are triggering is that two or more
'pirq_dpci' are added on the per-cpu list. Having them different
is fine (so one serving MSI the other IRQ), but having them the same is a no-go.
Somehow you are triggering the later.


Is your machine by any chance set to 'Aggressive' memory setting? My ASUS
box has that setting and while it works great with games, Xen ends up hitting
some rather strange lockups that I can only blame on that.

> 
> >> Thank you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:19:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlUe-0005BY-TQ; Tue, 18 Nov 2014 16:19:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XqlUb-0005BM-KV
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:19:03 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	5C/89-25714-4717B645; Tue, 18 Nov 2014 16:19:00 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416327537!12048246!1
X-Originating-IP: [64.18.0.245]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22266 invoked from network); 18 Nov 2014 16:18:59 -0000
Received: from exprod5og125.obsmtp.com (HELO exprod5og125.obsmtp.com)
	(64.18.0.245)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:18:59 -0000
Received: from mail-wi0-f170.google.com ([209.85.212.170]) (using TLSv1) by
	exprod5ob125.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGtxcTMNaAwUM3roWp3Wd9fpX9cCwlNG@postini.com;
	Tue, 18 Nov 2014 08:18:59 PST
Received: by mail-wi0-f170.google.com with SMTP id bs8so6776000wib.5
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:18:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=s4Q3PSDcVhYvSdsannpl1KGRk9zfhv/7NCCEXD18iZs=;
	b=bXUCqqHHCYf+9xPh86uslDt3V6fDJ9avsDfmssO1IVY3768F6wUldTAzXeHLndDvXF
	9PTIfKGSU5iQoYUb9MldnNW8i+ZHKOsW56Q/OZQ5yswrfAO8Kq7qvCi3U0Ctw8LMuQl8
	5xelJb3+LvUCQ8N+IN+qCn6MMFk7brdtm5HD8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=s4Q3PSDcVhYvSdsannpl1KGRk9zfhv/7NCCEXD18iZs=;
	b=juQ2V4AdKNNYyvBcMfjV8M1KeVyOoIe3Pl933X/cclYvWi68kffG3McDx+elNaFP+J
	mnl10Zz4DNpCCx9B+kxfSYirxy7qskd3EcdMToAeUO8NOSUQzAedDIMUtT3a8ySJ+/5l
	+f6kJF9ys3GKVIjY33pJCN0Tuzv7qbSua1SFubjNVMMP6+Ar+NfqH73YFuOvn6+I3Uen
	yK3szw8tQu+Y5qvLzwuP/LIGZz31T617JZXic5ed9CeqBxMRwuvkDA/oADig/Q2DiS5x
	e9yr2809BQT1bYrwVCzQqw81gXWF+zdzari2JB5Fo2XkAg7ESIBFTIIZY+NtkNgCXEDH
	yK+Q==
X-Gm-Message-State: ALoCoQmRcy/oIRZramdZX/KCxi/JGl997bVBjeMW7EIy2YU1syPdg4Gv61F4/jB2TaPRlfGh91I6EorMzH17IxRnM0nALbPhOeivJidOrrucXzbUuBQOCTK2S5FT5t43NXOUrPLgj40xWy0Yb1bLuw8DUZKqlMN8IA==
X-Received: by 10.194.236.200 with SMTP id uw8mr49991198wjc.50.1416327536018; 
	Tue, 18 Nov 2014 08:18:56 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.236.200 with SMTP id uw8mr49991159wjc.50.1416327535785; 
	Tue, 18 Nov 2014 08:18:55 -0800 (PST)
Received: by 10.112.61.69 with HTTP; Tue, 18 Nov 2014 08:18:55 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
Date: Tue, 18 Nov 2014 18:18:55 +0200
Message-ID: <CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

OK got it. Give me a few mins

On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> for non-hardware irqs (desc == NULL) and keep avoiding
> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
>
> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> other potential bugs introduced later.
>
> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> What if I try on top of current master branch the following code:
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index 31fb81a..6764ab7 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -36,6 +36,8 @@
>>  #include <asm/io.h>
>>  #include <asm/gic.h>
>>
>> +#define GIC_DEBUG 1
>> +
>>  /*
>>   * LR register definitions are GIC v2 specific.
>>   * Moved these definitions from header file to here
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index bcaded9..c03d6a6 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
>>
>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
>> gic_hw_ops->info->nr_lrs) - 1))
>>
>> -#undef GIC_DEBUG
>> +#define GIC_DEBUG 1
>>
>>  static void gic_update_one_lr(struct vcpu *v, int i);
>>
>> It is equivalent to what you proposing - my code contains
>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
>> be executed:
>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
>>
>> regards,
>> Andrii
>>
>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>> >> everything works fine
>> >> The following 2 patches fixes xen/master for my platform.
>> >>
>> >> Stefano, could you please take a look to these changes?
>> >>
>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
>> >>
>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>> >>
>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >>
>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >> index 31fb81a..093ecdb 100644
>> >> --- a/xen/arch/arm/gic-v2.c
>> >> +++ b/xen/arch/arm/gic-v2.c
>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>> >> pending_irq *p,
>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>> >> GICH_V2_LR_VIRTUAL_SHIFT));
>> >>
>> >> -    if ( p->desc != NULL )
>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >>      {
>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> -        else
>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>> >> GICH_V2_LR_PHYSICAL_MASK )
>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> +    }
>> >> +    else if ( p->desc != NULL )
>> >> +    {
>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>> >>      }
>> >>
>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
>> >
>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
>> > working correctly on OMAP5. This changes might only be better at
>> > "hiding" the real issue.
>> >
>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
>> > maintenance interrupts doesn't work for software interrupts.
>> > The commit that should make them work correctly after the
>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
>> > If you look at the changes to gic_update_one_lr in that commit, you'll
>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
>> > Maybe that doesn't work correctly on OMAP5.
>> >
>> > Could you try this patch on top of
>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
>> > if the problem is specifically with software irqs.
>> >
>> >
>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> > index b7516c0..d8a17c9 100644
>> > --- a/xen/arch/arm/gic.c
>> > +++ b/xen/arch/arm/gic.c
>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>> >  /* Maximum cpu interface per GIC */
>> >  #define NR_GIC_CPU_IF 8
>> >
>> > -#undef GIC_DEBUG
>> > +#define GIC_DEBUG 1
>> >
>> >  static void gic_update_one_lr(struct vcpu *v, int i);
>> >
>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>> >      if ( p->desc != NULL )
>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>> > +    else
>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>> >
>> >      GICH[GICH_LR + lr] = lr_val;
>> >
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:19:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlUe-0005BY-TQ; Tue, 18 Nov 2014 16:19:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XqlUb-0005BM-KV
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:19:03 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	5C/89-25714-4717B645; Tue, 18 Nov 2014 16:19:00 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416327537!12048246!1
X-Originating-IP: [64.18.0.245]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22266 invoked from network); 18 Nov 2014 16:18:59 -0000
Received: from exprod5og125.obsmtp.com (HELO exprod5og125.obsmtp.com)
	(64.18.0.245)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:18:59 -0000
Received: from mail-wi0-f170.google.com ([209.85.212.170]) (using TLSv1) by
	exprod5ob125.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGtxcTMNaAwUM3roWp3Wd9fpX9cCwlNG@postini.com;
	Tue, 18 Nov 2014 08:18:59 PST
Received: by mail-wi0-f170.google.com with SMTP id bs8so6776000wib.5
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:18:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=s4Q3PSDcVhYvSdsannpl1KGRk9zfhv/7NCCEXD18iZs=;
	b=bXUCqqHHCYf+9xPh86uslDt3V6fDJ9avsDfmssO1IVY3768F6wUldTAzXeHLndDvXF
	9PTIfKGSU5iQoYUb9MldnNW8i+ZHKOsW56Q/OZQ5yswrfAO8Kq7qvCi3U0Ctw8LMuQl8
	5xelJb3+LvUCQ8N+IN+qCn6MMFk7brdtm5HD8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=s4Q3PSDcVhYvSdsannpl1KGRk9zfhv/7NCCEXD18iZs=;
	b=juQ2V4AdKNNYyvBcMfjV8M1KeVyOoIe3Pl933X/cclYvWi68kffG3McDx+elNaFP+J
	mnl10Zz4DNpCCx9B+kxfSYirxy7qskd3EcdMToAeUO8NOSUQzAedDIMUtT3a8ySJ+/5l
	+f6kJF9ys3GKVIjY33pJCN0Tuzv7qbSua1SFubjNVMMP6+Ar+NfqH73YFuOvn6+I3Uen
	yK3szw8tQu+Y5qvLzwuP/LIGZz31T617JZXic5ed9CeqBxMRwuvkDA/oADig/Q2DiS5x
	e9yr2809BQT1bYrwVCzQqw81gXWF+zdzari2JB5Fo2XkAg7ESIBFTIIZY+NtkNgCXEDH
	yK+Q==
X-Gm-Message-State: ALoCoQmRcy/oIRZramdZX/KCxi/JGl997bVBjeMW7EIy2YU1syPdg4Gv61F4/jB2TaPRlfGh91I6EorMzH17IxRnM0nALbPhOeivJidOrrucXzbUuBQOCTK2S5FT5t43NXOUrPLgj40xWy0Yb1bLuw8DUZKqlMN8IA==
X-Received: by 10.194.236.200 with SMTP id uw8mr49991198wjc.50.1416327536018; 
	Tue, 18 Nov 2014 08:18:56 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.236.200 with SMTP id uw8mr49991159wjc.50.1416327535785; 
	Tue, 18 Nov 2014 08:18:55 -0800 (PST)
Received: by 10.112.61.69 with HTTP; Tue, 18 Nov 2014 08:18:55 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
Date: Tue, 18 Nov 2014 18:18:55 +0200
Message-ID: <CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

OK got it. Give me a few mins

On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> for non-hardware irqs (desc == NULL) and keep avoiding
> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
>
> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> other potential bugs introduced later.
>
> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> What if I try on top of current master branch the following code:
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index 31fb81a..6764ab7 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -36,6 +36,8 @@
>>  #include <asm/io.h>
>>  #include <asm/gic.h>
>>
>> +#define GIC_DEBUG 1
>> +
>>  /*
>>   * LR register definitions are GIC v2 specific.
>>   * Moved these definitions from header file to here
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index bcaded9..c03d6a6 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
>>
>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
>> gic_hw_ops->info->nr_lrs) - 1))
>>
>> -#undef GIC_DEBUG
>> +#define GIC_DEBUG 1
>>
>>  static void gic_update_one_lr(struct vcpu *v, int i);
>>
>> It is equivalent to what you proposing - my code contains
>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
>> be executed:
>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
>>
>> regards,
>> Andrii
>>
>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>> >> everything works fine
>> >> The following 2 patches fixes xen/master for my platform.
>> >>
>> >> Stefano, could you please take a look to these changes?
>> >>
>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
>> >>
>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>> >>
>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >>
>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >> index 31fb81a..093ecdb 100644
>> >> --- a/xen/arch/arm/gic-v2.c
>> >> +++ b/xen/arch/arm/gic-v2.c
>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>> >> pending_irq *p,
>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>> >> GICH_V2_LR_VIRTUAL_SHIFT));
>> >>
>> >> -    if ( p->desc != NULL )
>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >>      {
>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> -        else
>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>> >> GICH_V2_LR_PHYSICAL_MASK )
>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> +    }
>> >> +    else if ( p->desc != NULL )
>> >> +    {
>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>> >>      }
>> >>
>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
>> >
>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
>> > working correctly on OMAP5. This changes might only be better at
>> > "hiding" the real issue.
>> >
>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
>> > maintenance interrupts doesn't work for software interrupts.
>> > The commit that should make them work correctly after the
>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
>> > If you look at the changes to gic_update_one_lr in that commit, you'll
>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
>> > Maybe that doesn't work correctly on OMAP5.
>> >
>> > Could you try this patch on top of
>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
>> > if the problem is specifically with software irqs.
>> >
>> >
>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> > index b7516c0..d8a17c9 100644
>> > --- a/xen/arch/arm/gic.c
>> > +++ b/xen/arch/arm/gic.c
>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>> >  /* Maximum cpu interface per GIC */
>> >  #define NR_GIC_CPU_IF 8
>> >
>> > -#undef GIC_DEBUG
>> > +#define GIC_DEBUG 1
>> >
>> >  static void gic_update_one_lr(struct vcpu *v, int i);
>> >
>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>> >      if ( p->desc != NULL )
>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>> > +    else
>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>> >
>> >      GICH[GICH_LR + lr] = lr_val;
>> >
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:20:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1XqlVg-0005HK-Cx; Tue, 18 Nov 2014 16:20:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqlVe-0005H2-F3
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:20:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	89/C5-09842-5B17B645; Tue, 18 Nov 2014 16:20:05 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416327605!13680700!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2745 invoked from network); 18 Nov 2014 16:20:05 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:20:05 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so6656271wgh.30
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 08:20:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=l2617E9K6mg1xpDGIJNTR3nok/MnE7c6mVKvVlhtl+A=;
	b=HXpprx5kxcy7pAP1B+g5ZjP8OxoE/unn1c61R89THmcPAZE4xqm1KFQCndiRmOLzB5
	6bojC+zt/ZFa9TkE8sgYHgwACX7bI4WiOSBTl+OG5+v5/a7xGGbo63ACeOntumhDdPc2
	z8cVVT/383/sTF+RIU41EZl5mU73e/H4FqkYgJThcx+KVA63B2VylwBFoICFgLvCFxI0
	gCi7BKAfMwmtzNekdae0r2UOPd2XdTp9s3HUDMrLLDfdKCvuRSiBcbkkYQlOiYVS8wzu
	LyJVIX9Cmj6fUPaWyZEHz2jM+cgv2dQ3AQ08ovJPvMD+72elJX6fYO+ko8JyixJI7Fov
	biXA==
X-Gm-Message-State: ALoCoQl4Xrgh998vJGQWhYIvDwI6EGd4L72MUWrdEmXl/8g+FKJNniEDfmDeme4vT66ydQHQRSiT
X-Received: by 10.180.101.102 with SMTP id ff6mr41781815wib.0.1416327592053;
	Tue, 18 Nov 2014 08:19:52 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	ge17sm20151463wic.0.2014.11.18.08.19.50 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 08:19:51 -0800 (PST)
Message-ID: <546B71A5.2060104@linaro.org>
Date: Tue, 18 Nov 2014 16:19:49 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
	<546B7EB60200007800048D20@mail.emea.novell.com>
In-Reply-To: <546B7EB60200007800048D20@mail.emea.novell.com>
Cc: ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/18/2014 04:15 PM, Jan Beulich wrote:
>>>> On 18.11.14 at 16:00, <julien.grall@linaro.org> wrote:
>> On 10/31/2014 09:02 AM, Jan Beulich wrote:
>>>>>> On 30.10.14 at 19:51, <julien.grall@linaro.org> wrote:
>>> The naming suggests that the #if really should be around just the
>>> gic_version field (with a dummy field in the #else case to be C89
>>> compatible, e.g. a zero width unnamed bitfield) and the
>>> corresponding #define-s above, ...
>>
>> Not really related to this patch... but the way to improve it (via
>> extending createdomain).
>>
>> I need to create an empty structure. Is the dummy field really needed?
>> If so, did you meant?
>>
>> struct
>> {
>>    int :0;
>> }
> 
> Yes.
> 
>> The C spec declare this kind of structure as undefined.
> 
> I can't find anything saying so.

http://c0x.coding-guidelines.com/6.7.2.1.html

"1401 If the struct-declaration-list contains no named members, the
behavior is undefined."

>> Would an empty structure and used it be better?
> 
> Empty structures (and unions) aren't valid in standard C afaics, up to
> and including C11. That was the whole point of suggesting the above
> alternative, with me (maybe wrongly) believing that this would be valid.

Right, this is an extension of GCC. As neither of the 2 solutions are
valid, Ian Jackson was suggesting to use

struct {
   char dummy;
}

Would it be ok for you?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:20:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1XqlVg-0005HK-Cx; Tue, 18 Nov 2014 16:20:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqlVe-0005H2-F3
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:20:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	89/C5-09842-5B17B645; Tue, 18 Nov 2014 16:20:05 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416327605!13680700!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2745 invoked from network); 18 Nov 2014 16:20:05 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:20:05 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so6656271wgh.30
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 08:20:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=l2617E9K6mg1xpDGIJNTR3nok/MnE7c6mVKvVlhtl+A=;
	b=HXpprx5kxcy7pAP1B+g5ZjP8OxoE/unn1c61R89THmcPAZE4xqm1KFQCndiRmOLzB5
	6bojC+zt/ZFa9TkE8sgYHgwACX7bI4WiOSBTl+OG5+v5/a7xGGbo63ACeOntumhDdPc2
	z8cVVT/383/sTF+RIU41EZl5mU73e/H4FqkYgJThcx+KVA63B2VylwBFoICFgLvCFxI0
	gCi7BKAfMwmtzNekdae0r2UOPd2XdTp9s3HUDMrLLDfdKCvuRSiBcbkkYQlOiYVS8wzu
	LyJVIX9Cmj6fUPaWyZEHz2jM+cgv2dQ3AQ08ovJPvMD+72elJX6fYO+ko8JyixJI7Fov
	biXA==
X-Gm-Message-State: ALoCoQl4Xrgh998vJGQWhYIvDwI6EGd4L72MUWrdEmXl/8g+FKJNniEDfmDeme4vT66ydQHQRSiT
X-Received: by 10.180.101.102 with SMTP id ff6mr41781815wib.0.1416327592053;
	Tue, 18 Nov 2014 08:19:52 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	ge17sm20151463wic.0.2014.11.18.08.19.50 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 08:19:51 -0800 (PST)
Message-ID: <546B71A5.2060104@linaro.org>
Date: Tue, 18 Nov 2014 16:19:49 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
	<546B7EB60200007800048D20@mail.emea.novell.com>
In-Reply-To: <546B7EB60200007800048D20@mail.emea.novell.com>
Cc: ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
	for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/18/2014 04:15 PM, Jan Beulich wrote:
>>>> On 18.11.14 at 16:00, <julien.grall@linaro.org> wrote:
>> On 10/31/2014 09:02 AM, Jan Beulich wrote:
>>>>>> On 30.10.14 at 19:51, <julien.grall@linaro.org> wrote:
>>> The naming suggests that the #if really should be around just the
>>> gic_version field (with a dummy field in the #else case to be C89
>>> compatible, e.g. a zero width unnamed bitfield) and the
>>> corresponding #define-s above, ...
>>
>> Not really related to this patch... but the way to improve it (via
>> extending createdomain).
>>
>> I need to create an empty structure. Is the dummy field really needed?
>> If so, did you meant?
>>
>> struct
>> {
>>    int :0;
>> }
> 
> Yes.
> 
>> The C spec declare this kind of structure as undefined.
> 
> I can't find anything saying so.

http://c0x.coding-guidelines.com/6.7.2.1.html

"1401 If the struct-declaration-list contains no named members, the
behavior is undefined."

>> Would an empty structure and used it be better?
> 
> Empty structures (and unions) aren't valid in standard C afaics, up to
> and including C11. That was the whole point of suggesting the above
> alternative, with me (maybe wrongly) believing that this would be valid.

Right, this is an extension of GCC. As neither of the 2 solutions are
valid, Ian Jackson was suggesting to use

struct {
   char dummy;
}

Would it be ok for you?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:22:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1XqlY1-0005WB-5o; Tue, 18 Nov 2014 16:22: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 1XqlXz-0005Vs-Ko
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:22:31 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	3E/34-26652-6427B645; Tue, 18 Nov 2014 16:22:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416327747!12036979!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19611 invoked from network); 18 Nov 2014 16:22:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:22:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192536373"
Message-ID: <1416327662.17982.24.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Tue, 18 Nov 2014 16:21:02 +0000
In-Reply-To: <546B6AA5.1050409@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
	<21611.24907.144396.509457@mariner.uk.xensource.com>
	<546B650D.8040304@linaro.org>
	<21611.26449.963393.613516@mariner.uk.xensource.com>
	<546B6AA5.1050409@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Empty struct in public headers Was: Re: [PATCH for
 Xen 4.5] xen/arm: Add support for GICv3 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 15:49 +0000, Julien Grall wrote:
> (Rename the mail and strip the cc list)
> 
> On 11/18/2014 03:35 PM, Ian Jackson wrote:
> > Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
> >> On 11/18/2014 03:10 PM, Ian Jackson wrote:
> >>> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
> >>> would be very surprised if clang didn't support them too.
> >>
> >> AFAIK, clang doesn't complain about empty structures.
> > 
> > Right.
> > 
> >>> AIUI our policy, gcc extensions are fine except in the Xen public
> >>> headers.
> >>
> >> We have at least 2 "empty" structure on the ARM public header.
> > 
> > That ought to be fixed, in case anyone ever wants to build ARM guests
> > with Norcroft C or something.
> > 
> > Does the size of these structs matter ?
> 
> The 2 structures are arch_vcpu_info and arch_shared_info.
> 
> They are used only at the end of the structure vcpu_info (resp.
> shared_info). So I guess we could fix it?

arch_vcpu_info isn't at the end of vcpu_info (vcpu_time_info follows it)
and also vcpu_info is part of an array at the start of shared_info (an
array of 1 on ARM, but things still follow it). I'm also not sure of the
impact on the vcpu placement hypercall or the uses of it.

So it looks like changing vcpu_info at least will be hard/impossible. If
we want rid of these empty structs then I think an ifdef at the point of
use is the only option :-(

> >> Would something like below be better?
> >>
> >> struct
> >> {
> >>   int dummy:1
> >> };
> > 
> > I don't see why you wouldn't just do
> >    struct blah { char dummy; };
> > or even int dummy;
> 
> It was to avoid using more bit than necessary. I will use your solution.
> 
> Regards,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:22:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1XqlY1-0005WB-5o; Tue, 18 Nov 2014 16:22: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 1XqlXz-0005Vs-Ko
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:22:31 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	3E/34-26652-6427B645; Tue, 18 Nov 2014 16:22:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416327747!12036979!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19611 invoked from network); 18 Nov 2014 16:22:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:22:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192536373"
Message-ID: <1416327662.17982.24.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Tue, 18 Nov 2014 16:21:02 +0000
In-Reply-To: <546B6AA5.1050409@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
	<21611.24907.144396.509457@mariner.uk.xensource.com>
	<546B650D.8040304@linaro.org>
	<21611.26449.963393.613516@mariner.uk.xensource.com>
	<546B6AA5.1050409@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Empty struct in public headers Was: Re: [PATCH for
 Xen 4.5] xen/arm: Add support for GICv3 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 15:49 +0000, Julien Grall wrote:
> (Rename the mail and strip the cc list)
> 
> On 11/18/2014 03:35 PM, Ian Jackson wrote:
> > Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
> >> On 11/18/2014 03:10 PM, Ian Jackson wrote:
> >>> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
> >>> would be very surprised if clang didn't support them too.
> >>
> >> AFAIK, clang doesn't complain about empty structures.
> > 
> > Right.
> > 
> >>> AIUI our policy, gcc extensions are fine except in the Xen public
> >>> headers.
> >>
> >> We have at least 2 "empty" structure on the ARM public header.
> > 
> > That ought to be fixed, in case anyone ever wants to build ARM guests
> > with Norcroft C or something.
> > 
> > Does the size of these structs matter ?
> 
> The 2 structures are arch_vcpu_info and arch_shared_info.
> 
> They are used only at the end of the structure vcpu_info (resp.
> shared_info). So I guess we could fix it?

arch_vcpu_info isn't at the end of vcpu_info (vcpu_time_info follows it)
and also vcpu_info is part of an array at the start of shared_info (an
array of 1 on ARM, but things still follow it). I'm also not sure of the
impact on the vcpu placement hypercall or the uses of it.

So it looks like changing vcpu_info at least will be hard/impossible. If
we want rid of these empty structs then I think an ifdef at the point of
use is the only option :-(

> >> Would something like below be better?
> >>
> >> struct
> >> {
> >>   int dummy:1
> >> };
> > 
> > I don't see why you wouldn't just do
> >    struct blah { char dummy; };
> > or even int dummy;
> 
> It was to avoid using more bit than necessary. I will use your solution.
> 
> Regards,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:24:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:24:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlZf-0005fR-Nh; Tue, 18 Nov 2014 16:24:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1XqlZe-0005fC-3j
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:24:14 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	97/E8-08051-DA27B645; Tue, 18 Nov 2014 16:24:13 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416327851!13381558!1
X-Originating-IP: [209.85.192.52]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17786 invoked from network); 18 Nov 2014 16:24:12 -0000
Received: from mail-qg0-f52.google.com (HELO mail-qg0-f52.google.com)
	(209.85.192.52)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:24:12 -0000
Received: by mail-qg0-f52.google.com with SMTP id a108so5429294qge.25
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:24:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=WpSmfWoLE2UnN9BwtVubZsdUcHVGJ7GC7urzs9vX+AQ=;
	b=oQCQWzGsDTzVoFxDP242f8SSvYNj3uXUmUWM/7REzKFSJuyspoy8uV/IapPj+dB2X/
	waxOexedKmDWPSaqJhPc6ROmOyv2k87a5dELXOcwMCNM1D4smuVmUJvOc+CUSmTTu52d
	KIGwhFHUWbEZaEo3td/JqF3PcaQLEiJyZ5tmdmuHtlVA94Xjy4QvqDHnDcp+HxjGE74x
	jQlG1M6sVpGPIylbEJZZ9sZUmC7lULrZ4+htQ2FXfm02xRtKPiBp/qHNI2mA8pYWMW78
	Lwy9oIfMP4df9UjjcDeUP5qe0Z+8zXTiZDOSrALYua9sEd+ebgc6D7CSzObGsoNnblCA
	sK2Q==
X-Received: by 10.224.38.130 with SMTP id b2mr44958339qae.11.1416327850097;
	Tue, 18 Nov 2014 08:24:10 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.99])
	by mx.google.com with ESMTPSA id
	p10sm33015388qab.39.2014.11.18.08.24.08 for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Tue, 18 Nov 2014 08:24:09 -0800 (PST)
Date: Tue, 18 Nov 2014 13:24:05 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <19872515.20141118132405@gmail.com>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5465CB080200007800047845@mail.emea.novell.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Hello Jan,

Friday, November 14, 2014, 5:27:36 AM, you wrote:

>>> I implied your earlier statement to mean that. But - did you also
>>> verify that the three flags actually end up set (ideally from both
>>> DomU and Dom0 perspective)? The PCI backend may be screwing
>>> up things...
>> 
>> Yes I do verify the write. How do I check this from Dom0?

> Just use lspci.

I've just checked this with lspci. I see that the IO is being enabled.
Any   other   idea   on   why I might be reading back 0xff for all PCI
memory area reads? The lspci output follows.

Before starting DomU

smartin@smartin-xen:~$ lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00

After DomU initialisation

smartin@smartin-xen:~$ lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 02 00 10 00 04 00 00 02 00 00 00 00

After stopping DomU

smartin@smartin-xen:~$ lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:24:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:24:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlZf-0005fR-Nh; Tue, 18 Nov 2014 16:24:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1XqlZe-0005fC-3j
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:24:14 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	97/E8-08051-DA27B645; Tue, 18 Nov 2014 16:24:13 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416327851!13381558!1
X-Originating-IP: [209.85.192.52]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17786 invoked from network); 18 Nov 2014 16:24:12 -0000
Received: from mail-qg0-f52.google.com (HELO mail-qg0-f52.google.com)
	(209.85.192.52)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:24:12 -0000
Received: by mail-qg0-f52.google.com with SMTP id a108so5429294qge.25
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:24:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=WpSmfWoLE2UnN9BwtVubZsdUcHVGJ7GC7urzs9vX+AQ=;
	b=oQCQWzGsDTzVoFxDP242f8SSvYNj3uXUmUWM/7REzKFSJuyspoy8uV/IapPj+dB2X/
	waxOexedKmDWPSaqJhPc6ROmOyv2k87a5dELXOcwMCNM1D4smuVmUJvOc+CUSmTTu52d
	KIGwhFHUWbEZaEo3td/JqF3PcaQLEiJyZ5tmdmuHtlVA94Xjy4QvqDHnDcp+HxjGE74x
	jQlG1M6sVpGPIylbEJZZ9sZUmC7lULrZ4+htQ2FXfm02xRtKPiBp/qHNI2mA8pYWMW78
	Lwy9oIfMP4df9UjjcDeUP5qe0Z+8zXTiZDOSrALYua9sEd+ebgc6D7CSzObGsoNnblCA
	sK2Q==
X-Received: by 10.224.38.130 with SMTP id b2mr44958339qae.11.1416327850097;
	Tue, 18 Nov 2014 08:24:10 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.99])
	by mx.google.com with ESMTPSA id
	p10sm33015388qab.39.2014.11.18.08.24.08 for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Tue, 18 Nov 2014 08:24:09 -0800 (PST)
Date: Tue, 18 Nov 2014 13:24:05 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <19872515.20141118132405@gmail.com>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5465CB080200007800047845@mail.emea.novell.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Hello Jan,

Friday, November 14, 2014, 5:27:36 AM, you wrote:

>>> I implied your earlier statement to mean that. But - did you also
>>> verify that the three flags actually end up set (ideally from both
>>> DomU and Dom0 perspective)? The PCI backend may be screwing
>>> up things...
>> 
>> Yes I do verify the write. How do I check this from Dom0?

> Just use lspci.

I've just checked this with lspci. I see that the IO is being enabled.
Any   other   idea   on   why I might be reading back 0xff for all PCI
memory area reads? The lspci output follows.

Before starting DomU

smartin@smartin-xen:~$ lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00

After DomU initialisation

smartin@smartin-xen:~$ lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 02 00 10 00 04 00 00 02 00 00 00 00

After stopping DomU

smartin@smartin-xen:~$ lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:26:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1XqlbL-0005oF-AD; Tue, 18 Nov 2014 16:25:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1XqlbJ-0005o6-I6
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:25:58 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	46/52-18267-4137B645; Tue, 18 Nov 2014 16:25:56 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416327954!12244426!1
X-Originating-IP: [209.85.192.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30927 invoked from network); 18 Nov 2014 16:25:55 -0000
Received: from mail-qg0-f54.google.com (HELO mail-qg0-f54.google.com)
	(209.85.192.54)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:25:55 -0000
Received: by mail-qg0-f54.google.com with SMTP id q107so1101461qgd.41
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:25:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type;
	bh=ZsZsao1tgDsm7IjhAXn8b1wP1OLChG47SYfKW5B3sVQ=;
	b=jUm3nHMARvOwCs2y3FzNYzK8a8pRogcYUjdduCQvmKsIv3tdYIOkTs7CXK0keZONKg
	/hIf27nQupx0bdmSQptZZYlMsRwpzqyQYB4ppv8mxNZjLQlyRBkWKdlsG4FIPpyL/9jK
	aSAKUfMS28a9d/fkOiAzSp0AKGdt5z1omnl1KyQglvGBNXwreg6STTTjSsLvST2I1p0e
	7RLIH0y9bELIA2UpqVgb/Z5d925yzaOl5+SESYKSpuvE45zZtbDNezyAhGTKqWC6Y639
	bCRh8FK22JymfS84alU8K5LVG9eeRKpUsP2EMdf2LQZOeAX7Rgui1s0UUsflwla4gLty
	VRBA==
X-Received: by 10.224.88.134 with SMTP id a6mr44654999qam.28.1416327951938;
	Tue, 18 Nov 2014 08:25:51 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.99])
	by mx.google.com with ESMTPSA id 91sm30938839qgy.15.2014.11.18.08.25.46
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Tue, 18 Nov 2014 08:25:51 -0800 (PST)
Date: Tue, 18 Nov 2014 13:25:44 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <1335313968.20141118132544@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141113192915.GA12502@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<20141113190338.GB11211@laptop.dumpdata.com>
	<1747475571.20141113162148@gmail.com>
	<20141113192915.GA12502@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0410070F03E0EB1B3"
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0410070F03E0EB1B3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Konrad,

Thursday, November 13, 2014, 4:29:15 PM, you wrote:

> On Thu, Nov 13, 2014 at 04:21:48PM -0300, Simon Martin wrote:
>> Thanks Konrad,
>> 
>> Thursday, November 13, 2014, 4:03:38 PM, you wrote:
>> 
>> >> Yes I do verify the write. How do I check this from Dom0?
>> 
>> > You can crank up the debug volume in xen-pciback. Recompile the kernel
>> > and put '#define DEBUG 1' at the start of the .c files.
>> 
>> > Interestingly enough I saw this issue as well - and it looked to me
>> > that Xen pciback was stuck in '7' state (Reconfiguring) and never
>> > excited it.
>> 
>> > But I hadn't had a chance to dig in this.
>> 
>> This  might  be related to something that I reported a while ago, that
>> when   I   shutdown  the PV it takes a long time for the corresponding
>> Dom0 processes to stop.
>> 
>> I'll set the debug level and see what's going on. That'll be on Monday
>> now.

I attach the output from xl dmesg and dmesg. As far as I can see,
everything looks to be OK.


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com
------------0410070F03E0EB1B3
Content-Type: application/octet-stream;
 name=xl_dmesg
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename=xl_dmesg

IFhlbiA0LjUuMC1yYwooWEVOKSBYZW4gdmVyc2lvbiA0LjUuMC1yYyAocm9vdEBuZW1vLmNs
KSAoZ2NjIChEZWJpYW4gNC43LjItNSkgNC43LjIpIGRlYnVnPXkgTW9uIE5vdiAxNyAxNjoy
NDo0MCBDTFNUIDIwMTQKKFhFTikgTGF0ZXN0IENoYW5nZVNldDogVGh1IE5vdiA2IDEwOjQx
OjI4IDIwMTQgKzAwMDAgZ2l0OmU2ZmE2M2QtZGlydHkKKFhFTikgQm9vdGxvYWRlcjogR1JV
QiAxLjk5LTI3K2RlYjd1MgooWEVOKSBDb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVyIHRpbWVy
X3Nsb3A9MCBkb20wX21heF92Y3B1cz0yIGRvbTBfdmNwdXNfcGluIGxvZ2x2bD1hbGwgaW9t
bXU9ZGVidWcKKFhFTikgVmlkZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBt
b2RlIDgweDI1LCBmb250IDh4MTYKKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQg
dHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4p
ICBGb3VuZCAyIE1CUiBzaWduYXR1cmVzCihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlv
biBzdHJ1Y3R1cmVzCihYRU4pIFhlbi1lODIwIFJBTSBtYXA6CihYRU4pICAwMDAwMDAwMDAw
MDAwMDAwIC0gMDAwMDAwMDAwMDA5ZDgwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDAwMDA5
ZDgwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDBl
MDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDEw
MDAwMCAtIDAwMDAwMDAwYzg1MjIwMDAgKHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwYzg1MjIw
MDAgLSAwMDAwMDAwMGM4NTI5MDAwIChBQ1BJIE5WUykKKFhFTikgIDAwMDAwMDAwYzg1Mjkw
MDAgLSAwMDAwMDAwMGRiYTg1MDAwICh1c2FibGUpCihYRU4pICAwMDAwMDAwMGRiYTg1MDAw
IC0gMDAwMDAwMDBkYmIwZjAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGRiYjBmMDAw
IC0gMDAwMDAwMDBkYmIyOTAwMCAoQUNQSSBkYXRhKQooWEVOKSAgMDAwMDAwMDBkYmIyOTAw
MCAtIDAwMDAwMDAwZGJjOTIwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBkYmM5MjAw
MCAtIDAwMDAwMDAwZGJmZmYwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBkYmZmZjAw
MCAtIDAwMDAwMDAwZGMwMDAwMDAgKHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwZGQwMDAwMDAg
LSAwMDAwMDAwMGRmMjAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZjgwMDAwMDAg
LSAwMDAwMDAwMGZjMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVjMDAwMDAg
LSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVkMDAwMDAg
LSAwMDAwMDAwMGZlZDA0MDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVkMWMwMDAg
LSAwMDAwMDAwMGZlZDIwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVlMDAwMDAg
LSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmYwMDAwMDAg
LSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAg
LSAwMDAwMDAwMTFmZTAwMDAwICh1c2FibGUpCihYRU4pIEFDUEk6IFJTRFAgMDAwRjA0OTAs
IDAwMjQgKHIyICBJTlRFTCkKKFhFTikgQUNQSTogWFNEVCBEQkIxNDA4MCwgMDA4NCAocjEg
SU5URUwgIEQzNDAxMFdZICAgICAgIDE2IEFNSSAgICAgMTAwMTMpCihYRU4pIEFDUEk6IEZB
Q1AgREJCMjNBMDgsIDAxMEMgKHI1IElOVEVMICBEMzQwMTBXWSAgICAgICAxNiBBTUkgICAg
IDEwMDEzKQooWEVOKSBBQ1BJOiBEU0RUIERCQjE0MTk4LCBGODcwIChyMiBJTlRFTCAgRDM0
MDEwV1kgICAgICAgMTYgSU5UTCAyMDEyMDcxMSkKKFhFTikgQUNQSTogRkFDUyBEQkM5MDA4
MCwgMDA0MAooWEVOKSBBQ1BJOiBBUElDIERCQjIzQjE4LCAwMDcyIChyMyBJTlRFTCAgRDM0
MDEwV1kgICAgICAgMTYgQU1JICAgICAxMDAxMykKKFhFTikgQUNQSTogRlBEVCBEQkIyM0I5
MCwgMDA0NCAocjEgSU5URUwgIEQzNDAxMFdZICAgICAgIDE2IEFNSSAgICAgMTAwMTMpCihY
RU4pIEFDUEk6IExQSVQgREJCMjNCRDgsIDAwNUMgKHIxIElOVEVMICBEMzQwMTBXWSAgICAg
ICAxNiBBTUkuICAgICAgICA1KQooWEVOKSBBQ1BJOiBTU0RUIERCQjIzQzM4LCAwNDk0IChy
MSBJTlRFTCAgRDM0MDEwV1kgICAgICAgMTYgSU5UTCAyMDEyMDcxMSkKKFhFTikgQUNQSTog
U1NEVCBEQkIyNDBEMCwgMEFEOCAocjEgSU5URUwgIEQzNDAxMFdZICAgICAgIDE2IElOVEwg
MjAxMjA3MTEpCihYRU4pIEFDUEk6IE1DRkcgREJCMjRCQTgsIDAwM0MgKHIxIElOVEVMICBE
MzQwMTBXWSAgICAgICAxNiBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBIUEVUIERCQjI0
QkU4LCAwMDM4IChyMSBJTlRFTCAgRDM0MDEwV1kgICAgICAgMTYgQU1JLiAgICAgICAgNSkK
KFhFTikgQUNQSTogU1NEVCBEQkIyNEMyMCwgMDMxNSAocjEgSU5URUwgIEQzNDAxMFdZICAg
ICAgIDE2IElOVEwgMjAxMjA3MTEpCihYRU4pIEFDUEk6IFNTRFQgREJCMjRGMzgsIDMwMDQg
KHIxIElOVEVMICBEMzQwMTBXWSAgICAgICAxNiBJTlRMIDIwMDkxMTEyKQooWEVOKSBBQ1BJ
OiBETUFSIERCQjI3RjQwLCAwMTkwIChyMSBJTlRFTCAgRDM0MDEwV1kgICAgICAgMTYgSU5U
TCAgICAgICAgMSkKKFhFTikgQUNQSTogQ1NSVCBEQkIyODBEMCwgMDBDNCAocjEgSU5URUwg
IEQzNDAxMFdZICAgICAgIDE2IElOVEwgMjAxMDA1MjgpCihYRU4pIFN5c3RlbSBSQU06IDQw
MjRNQiAoNDEyMDY4OGtCKQooWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQKKFhF
TikgRmFraW5nIGEgbm9kZSBhdCAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAxMWZlMDAwMDAK
KFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQKKFhFTikgZm91bmQgU01QIE1QLXRhYmxl
IGF0IDAwMGZkNzIwCihYRU4pIERNSSAyLjcgcHJlc2VudC4KKFhFTikgVXNpbmcgQVBJQyBk
cml2ZXIgZGVmYXVsdAooWEVOKSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDE4MDgKKFhF
TikgQUNQSTogdjUgU0xFRVAgSU5GTzogY29udHJvbFswOjBdLCBzdGF0dXNbMDowXQooWEVO
KSBBQ1BJOiBTTEVFUCBJTkZPOiBwbTF4X2NudFsxOjE4MDQsMTowXSwgcG0xeF9ldnRbMTox
ODAwLDE6MF0KKFhFTikgQUNQSTogMzIvNjRYIEZBQ1MgYWRkcmVzcyBtaXNtYXRjaCBpbiBG
QURUIC0gZGJjOTAwODAvMDAwMDAwMDAwMDAwMDAwMCwgdXNpbmcgMzIKKFhFTikgQUNQSTog
ICAgICAgICAgICAgd2FrZXVwX3ZlY1tkYmM5MDA4Y10sIHZlY19zaXplWzIwXQooWEVOKSBB
Q1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMAooWEVOKSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3Ig
IzAgNjo1IEFQSUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAy
XSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzIgNjo1IEFQSUMg
dmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsw
eDAxXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzEgNjo1IEFQSUMgdmVyc2lvbiAyMQoo
WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAzXSBlbmFibGVk
KQooWEVOKSBQcm9jZXNzb3IgIzMgNjo1IEFQSUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBM
QVBJQ19OTUkgKGFjcGlfaWRbMHhmZl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQ
STogSU9BUElDIChpZFsweDAyXSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQoo
WEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgMiwgdmVyc2lvbiAzMiwgYWRkcmVzcyAweGZlYzAw
MDAwLCBHU0kgMC0zOQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAw
IGdsb2JhbF9pcnEgMiBkZmwgZGZsKQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAg
YnVzX2lycSA5IGdsb2JhbF9pcnEgOSBoaWdoIGxldmVsKQooWEVOKSBBQ1BJOiBJUlEwIHVz
ZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4KKFhF
TikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBFbmFibGluZyBBUElDIG1v
ZGU6ICBGbGF0LiAgVXNpbmcgMSBJL08gQVBJQ3MKKFhFTikgQUNQSTogSFBFVCBpZDogMHg4
MDg2YTcwMSBiYXNlOiAweGZlZDAwMDAwCihYRU4pIFtWVC1EXWRtYXIuYzo3ODg6IEhvc3Qg
YWRkcmVzcyB3aWR0aCAzOQooWEVOKSBbVlQtRF1kbWFyLmM6ODAyOiBmb3VuZCBBQ1BJX0RN
QVJfRFJIRDoKKFhFTikgW1ZULURdZG1hci5jOjQ3MjogICBkbWFydS0+YWRkcmVzcyA9IGZl
ZDkwMDAwCihYRU4pIFtWVC1EXWlvbW11LmM6MTE0NjogZHJoZC0+YWRkcmVzcyA9IGZlZDkw
MDAwIGlvbW11LT5yZWcgPSBmZmZmODJjMDAwMjAxMDAwCihYRU4pIFtWVC1EXWlvbW11LmM6
MTE0ODogY2FwID0gYzAwMDAwMjA2NjA0NjIgZWNhcCA9IGYwMTAxYQooWEVOKSBbVlQtRF1k
bWFyLmM6MzgzOiAgZW5kcG9pbnQ6IDAwMDA6MDA6MDIuMAooWEVOKSBbVlQtRF1kbWFyLmM6
ODAyOiBmb3VuZCBBQ1BJX0RNQVJfRFJIRDoKKFhFTikgW1ZULURdZG1hci5jOjQ3MjogICBk
bWFydS0+YWRkcmVzcyA9IGZlZDkxMDAwCihYRU4pIFtWVC1EXWlvbW11LmM6MTE0NjogZHJo
ZC0+YWRkcmVzcyA9IGZlZDkxMDAwIGlvbW11LT5yZWcgPSBmZmZmODJjMDAwMjAzMDAwCihY
RU4pIFtWVC1EXWlvbW11LmM6MTE0ODogY2FwID0gZDIwMDgwMjA2NjA0NjIgZWNhcCA9IGYw
MTBkYQooWEVOKSBbVlQtRF1kbWFyLmM6Mzk3OiAgSU9BUElDOiAwMDAwOmYwOjFmLjAKKFhF
TikgW1ZULURdZG1hci5jOjM2MTogIE1TSSBIUEVUOiAwMDAwOmYwOjBmLjAKKFhFTikgW1ZU
LURdVW5rbm93biBzY29wZSB0eXBlIDB4NQooWEVOKSBbVlQtRF1Vbmtub3duIHNjb3BlIHR5
cGUgMHg1CihYRU4pIFtWVC1EXVVua25vd24gc2NvcGUgdHlwZSAweDUKKFhFTikgW1ZULURd
VW5rbm93biBzY29wZSB0eXBlIDB4NQooWEVOKSBbVlQtRF1Vbmtub3duIHNjb3BlIHR5cGUg
MHg1CihYRU4pIFtWVC1EXVVua25vd24gc2NvcGUgdHlwZSAweDUKKFhFTikgW1ZULURdVW5r
bm93biBzY29wZSB0eXBlIDB4NQooWEVOKSBbVlQtRF1kbWFyLmM6NDg2OiAgIGZsYWdzOiBJ
TkNMVURFX0FMTAooWEVOKSBbVlQtRF1kbWFyLmM6ODA3OiBmb3VuZCBBQ1BJX0RNQVJfUk1S
UjoKKFhFTikgW1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFkLjAKKFhF
TikgW1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjE0LjAKKFhFTikgW1ZU
LURdZG1hci5jOjY3NjogICBSTVJSIHJlZ2lvbjogYmFzZV9hZGRyIGRiZWIxMDAwIGVuZF9h
ZGRyZXNzIGRiZWJmZmZmCihYRU4pIFtWVC1EXWRtYXIuYzo4MDc6IGZvdW5kIEFDUElfRE1B
Ul9STVJSOgooWEVOKSBbVlQtRF1kbWFyLmM6MzgzOiAgZW5kcG9pbnQ6IDAwMDA6MDA6MDIu
MAooWEVOKSBbVlQtRF1kbWFyLmM6Njc2OiAgIFJNUlIgcmVnaW9uOiBiYXNlX2FkZHIgZGQw
MDAwMDAgZW5kX2FkZHJlc3MgZGYxZmZmZmYKKFhFTikgW1ZULURdZG1hci5jOjgyMzogSWdu
b3JlIHVua25vd24gRE1BUiBzdHJ1Y3R1cmUgdHlwZSAoMHg0KQooWEVOKSBFUlNUIHRhYmxl
IHdhcyBub3QgZm91bmQKKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1
cmF0aW9uIGluZm9ybWF0aW9uCihYRU4pIFNNUDogQWxsb3dpbmcgNCBDUFVzICgwIGhvdHBs
dWcgQ1BVcykKKFhFTikgSVJRIGxpbWl0czogNDAgR1NJLCA3NDQgTVNJL01TSS1YCihYRU4p
IFN3aXRjaGVkIHRvIEFQSUMgZHJpdmVyIHgyYXBpY19jbHVzdGVyLgooWEVOKSBVc2luZyBz
Y2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVkaXQpCihYRU4pIERldGVjdGVk
IDE2OTYuMTQ2IE1IeiBwcm9jZXNzb3IuCihYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcu
CihYRU4pIHhzdGF0ZV9pbml0OiB1c2luZyBjbnR4dF9zaXplOiAweDM0MCBhbmQgc3RhdGVz
OiAweDcKKFhFTikgbWNlX2ludGVsLmM6NzE5OiBNQ0EgQ2FwYWJpbGl0eTogQkNBU1QgMSBT
RVIgMCBDTUNJIDEgZmlyc3RiYW5rIDAgZXh0ZW5kZWQgTUNFIE1TUiAwCihYRU4pIEludGVs
IG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQKKFhFTikgYWx0IHRhYmxlIGZmZmY4
MmQwODAyZDhjZjAgLT4gZmZmZjgyZDA4MDJkOWQxMAooWEVOKSBQQ0k6IE1DRkcgY29uZmln
dXJhdGlvbiAwOiBiYXNlIGY4MDAwMDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIDNmCihY
RU4pIFBDSTogTUNGRyBhcmVhIGF0IGY4MDAwMDAwIHJlc2VydmVkIGluIEU4MjAKKFhFTikg
UENJOiBVc2luZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAwLTNmCihYRU4pIEludGVs
IFZULWQgaW9tbXUgMCBzdXBwb3J0ZWQgcGFnZSBzaXplczogNGtCLgooWEVOKSBJbnRlbCBW
VC1kIGlvbW11IDEgc3VwcG9ydGVkIHBhZ2Ugc2l6ZXM6IDRrQi4KKFhFTikgSW50ZWwgVlQt
ZCBTbm9vcCBDb250cm9sIG5vdCBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIERvbTAgRE1B
IFBhc3N0aHJvdWdoIG5vdCBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIFF1ZXVlZCBJbnZh
bGlkYXRpb24gZW5hYmxlZC4KKFhFTikgSW50ZWwgVlQtZCBJbnRlcnJ1cHQgUmVtYXBwaW5n
IGVuYWJsZWQuCihYRU4pIEludGVsIFZULWQgU2hhcmVkIEVQVCB0YWJsZXMgbm90IGVuYWJs
ZWQuCihYRU4pIEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVkCihYRU4pICAtIERvbTAgbW9k
ZTogUmVsYXhlZAooWEVOKSBJbnRlcnJ1cHQgcmVtYXBwaW5nIGVuYWJsZWQKKFhFTikgRW5h
YmxlZCBkaXJlY3RlZCBFT0kgd2l0aCBpb2FwaWNfYWNrX29sZCBvbiEKKFhFTikgRU5BQkxJ
TkcgSU8tQVBJQyBJUlFzCihYRU4pICAtPiBVc2luZyBvbGQgQUNLIG1ldGhvZAooWEVOKSAu
LlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCihY
RU4pIFRTQyBkZWFkbGluZSB0aW1lciBlbmFibGVkCihYRU4pIFBsYXRmb3JtIHRpbWVyIGlz
IDE0LjMxOE1IeiBIUEVUCihYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcgb2YgMzIgS2lC
LgooWEVOKSBtd2FpdC1pZGxlOiBNV0FJVCBzdWJzdGF0ZXM6IDB4MTExNDIxMjAKKFhFTikg
bXdhaXQtaWRsZTogdjAuNCBtb2RlbCAweDQ1CihYRU4pIG13YWl0LWlkbGU6IGxhcGljX3Rp
bWVyX3JlbGlhYmxlX3N0YXRlcyAweGZmZmZmZmZmCihYRU4pIG13YWl0LWlkbGU6IG1heCBD
LXN0YXRlIGNvdW50IG9mIDggcmVhY2hlZAooWEVOKSBWTVg6IFN1cHBvcnRlZCBhZHZhbmNl
ZCBmZWF0dXJlczoKKFhFTikgIC0gQVBJQyBNTUlPIGFjY2VzcyB2aXJ0dWFsaXNhdGlvbgoo
WEVOKSAgLSBBUElDIFRQUiBzaGFkb3cKKFhFTikgIC0gRXh0ZW5kZWQgUGFnZSBUYWJsZXMg
KEVQVCkKKFhFTikgIC0gVmlydHVhbC1Qcm9jZXNzb3IgSWRlbnRpZmllcnMgKFZQSUQpCihY
RU4pICAtIFZpcnR1YWwgTk1JCihYRU4pICAtIE1TUiBkaXJlY3QtYWNjZXNzIGJpdG1hcAoo
WEVOKSAgLSBVbnJlc3RyaWN0ZWQgR3Vlc3QKKFhFTikgSFZNOiBBU0lEcyBlbmFibGVkLgoo
WEVOKSBIVk06IFZNWCBlbmFibGVkCihYRU4pIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFn
aW5nIChIQVApIGRldGVjdGVkCihYRU4pIEhWTTogSEFQIHBhZ2Ugc2l6ZXM6IDRrQiwgMk1C
LCAxR0IKKFhFTikgbXdhaXQtaWRsZTogbWF4IEMtc3RhdGUgY291bnQgb2YgOCByZWFjaGVk
CihYRU4pIG13YWl0LWlkbGU6IG1heCBDLXN0YXRlIGNvdW50IG9mIDggcmVhY2hlZAooWEVO
KSBtd2FpdC1pZGxlOiBtYXggQy1zdGF0ZSBjb3VudCBvZiA4IHJlYWNoZWQKKFhFTikgQnJv
dWdodCB1cCA0IENQVXMKKFhFTikgQUNQSSBzbGVlcCBtb2RlczogUzMKKFhFTikgbWNoZWNr
X3BvbGw6IE1hY2hpbmUgY2hlY2sgcG9sbGluZyB0aW1lciBzdGFydGVkLgooWEVOKSAqKiog
TE9BRElORyBET01BSU4gMCAqKioKKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFk
ZHI9MHgxMDAwMDAwIG1lbXN6PTB4N2M4MDAwCihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBo
ZHI6IHBhZGRyPTB4MTgwMDAwMCBtZW1zej0weGViMDAwCihYRU4pIGVsZl9wYXJzZV9iaW5h
cnk6IHBoZHI6IHBhZGRyPTB4MThlYjAwMCBtZW1zej0weDE0ZWMwCihYRU4pIGVsZl9wYXJz
ZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTkwMDAwMCBtZW1zej0weDYxNTAwMAooWEVOKSBl
bGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAtPiAweDFmMTUwMDAKKFhFTikg
ZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9PUyA9ICJsaW51eCIKKFhFTikgZWxmX3hlbl9w
YXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiIKKFhFTikgZWxmX3hlbl9wYXJzZV9u
b3RlOiBYRU5fVkVSU0lPTiA9ICJ4ZW4tMy4wIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6
IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMAooWEVOKSBlbGZfeGVuX3BhcnNlX25v
dGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxOTAwMWYwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90
ZTogSFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDAKKFhFTikgZWxmX3hlbl9w
YXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIhd3JpdGFibGVfcGFnZV90YWJsZXN8cGFlX3BnZGly
X2Fib3ZlXzRnYnx3cml0YWJsZV9kZXNjcmlwdG9yX3RhYmxlc3xhdXRvX3RyYW5zbGF0ZWRf
cGh5c21hcHxzdXBlcnZpc29yX21vZGVfa2VybmVsIgooWEVOKSBlbGZfeGVuX3BhcnNlX25v
dGU6IFNVUFBPUlRFRF9GRUFUVVJFUyA9IDB4OTBkCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90
ZTogUEFFX01PREUgPSAieWVzIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURFUiA9
ICJnZW5lcmljIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBu
b3RlICgweGQpCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAw
eDEKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBIVl9TVEFSVF9MT1cgPSAweGZmZmY4MDAw
MDAwMDAwMDAKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDAK
KFhFTikgZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoKKFhFTikgICAgIHZp
cnRfYmFzZSAgICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgICAgIGVsZl9wYWRk
cl9vZmZzZXQgPSAweDAKKFhFTikgICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweGZmZmZmZmZm
ODAwMDAwMDAKKFhFTikgICAgIHZpcnRfa3N0YXJ0ICAgICAgPSAweGZmZmZmZmZmODEwMDAw
MDAKKFhFTikgICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZmZmZmODFmMTUwMDAKKFhF
TikgICAgIHZpcnRfZW50cnkgICAgICAgPSAweGZmZmZmZmZmODE5MDAxZjAKKFhFTikgICAg
IHAybV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYKKFhFTikgIFhlbiAga2Vy
bmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIKKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQs
IFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHgxZjE1MDAwCihYRU4pIFBIWVNJQ0FM
IE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAxMTQw
MDAwMDAtPjAwMDAwMDAxMTgwMDAwMDAgKDk1NDA3MyBwYWdlcyB0byBiZSBhbGxvY2F0ZWQp
CihYRU4pICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMTFkMzY2MDAwLT4wMDAwMDAwMTFmZGZm
YTAwCihYRU4pIFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgTG9hZGVkIGtl
cm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MWYxNTAwMAooWEVOKSAgSW5pdC4g
cmFtZGlzazogZmZmZmZmZmY4MWYxNTAwMC0+ZmZmZmZmZmY4NDlhZWEwMAooWEVOKSAgUGh5
cy1NYWNoIG1hcDogZmZmZmZmZmY4NDlhZjAwMC0+ZmZmZmZmZmY4NTEyYmI5OAooWEVOKSAg
U3RhcnQgaW5mbzogICAgZmZmZmZmZmY4NTEyYzAwMC0+ZmZmZmZmZmY4NTEyYzRiNAooWEVO
KSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4NTEyZDAwMC0+ZmZmZmZmZmY4NTE1YTAwMAoo
WEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4NTE1YTAwMC0+ZmZmZmZmZmY4NTE1YjAw
MAooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NTQw
MDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MTkwMDFmMAooWEVOKSBEb20w
IGhhcyBtYXhpbXVtIDIgVkNQVXMKKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQg
MHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MTdjODAwMAooWEVOKSBlbGZfbG9h
ZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODE4MDAwMDAgLT4gMHhmZmZmZmZmZjgx
OGViMDAwCihYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAyIGF0IDB4ZmZmZmZmZmY4MThl
YjAwMCAtPiAweGZmZmZmZmZmODE4ZmZlYzAKKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRy
IDMgYXQgMHhmZmZmZmZmZjgxOTAwMDAwIC0+IDB4ZmZmZmZmZmY4MWExZTAwMAooWEVOKSBb
VlQtRF1pb21tdS5jOjE0MzA6IGQwOkhvc3RicmlkZ2U6IHNraXAgMDAwMDowMDowMC4wIG1h
cAooWEVOKSBCb2d1cyBETUlCQVIgMHhmZWQxODAwMSBvbiAwMDAwOjAwOjAwLjAKKFhFTikg
W1ZULURdaW9tbXUuYzoxNDU2OiBkMDpQQ0k6IG1hcCAwMDAwOjAwOjAyLjAKKFhFTikgW1ZU
LURdaW9tbXUuYzoxNDQ0OiBkMDpQQ0llOiBtYXAgMDAwMDowMDowMy4wCihYRU4pIFtWVC1E
XWlvbW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxNC4wCihYRU4pIFtWVC1EXWlv
bW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxNi4wCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxOS4wCihYRU4pIFtWVC1EXWlvbW11LmM6
MTQ0NDogZDA6UENJZTogbWFwIDAwMDA6MDA6MWIuMAooWEVOKSBbVlQtRF1pb21tdS5jOjE0
NTY6IGQwOlBDSTogbWFwIDAwMDA6MDA6MWQuMAooWEVOKSBbVlQtRF1pb21tdS5jOjE0NTY6
IGQwOlBDSTogbWFwIDAwMDA6MDA6MWYuMAooWEVOKSBbVlQtRF1pb21tdS5jOjE0NTY6IGQw
OlBDSTogbWFwIDAwMDA6MDA6MWYuMgooWEVOKSBbVlQtRF1pb21tdS5jOjE0NTY6IGQwOlBD
STogbWFwIDAwMDA6MDA6MWYuMwooWEVOKSBbVlQtRF1pb21tdS5jOjE0NDQ6IGQwOlBDSWU6
IG1hcCAwMDAwOjAyOjAwLjAKKFhFTikgW1ZULURdaW9tbXUuYzo3Mzk6IGlvbW11X2VuYWJs
ZV90cmFuc2xhdGlvbjogaW9tbXUtPnJlZyA9IGZmZmY4MmMwMDAyMDEwMDAKKFhFTikgW1ZU
LURdaW9tbXUuYzo3Mzk6IGlvbW11X2VuYWJsZV90cmFuc2xhdGlvbjogaW9tbXUtPnJlZyA9
IGZmZmY4MmMwMDAyMDMwMDAKKFhFTikgU2NydWJiaW5nIEZyZWUgUkFNIG9uIDEgbm9kZXMg
dXNpbmcgMiBDUFVzCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuCihYRU4pIEluaXRp
YWwgbG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgooWEVO
KSBTdGQuIExvZ2xldmVsOiBBbGwKKFhFTikgR3Vlc3QgTG9nbGV2ZWw6IEFsbAooWEVOKSBY
ZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4KKFhFTikgKioqIFNlcmlhbCBpbnB1
dCAtPiBET00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0
byBYZW4pCihYRU4pIEZyZWVkIDI5MmtCIGluaXQgbWVtb3J5LgooWEVOKSBCb2d1cyBETUlC
QVIgMHhmZWQxODAwMSBvbiAwMDAwOjAwOjAwLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw
MDowMDowMC4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDIuMAooWEVOKSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjAzLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
NC4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTYuMAooWEVOKSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjE5LjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxYi4wCihY
RU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MWMuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAw
MDAwOjAwOjFjLjMKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxZC4wCihYRU4pIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDA6MWYuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw
OjFmLjIKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxZi4zCihYRU4pIFBDSSBhZGQg
ZGV2aWNlIDAwMDA6MDI6MDAuMAooWEVOKSB0cmFwcy5jOjMxNTE6IEdQRiAoMDAwMCk6IGZm
ZmY4MmQwODAxOTI1OTYgLT4gZmZmZjgyZDA4MDIzNWQzMQooWEVOKSB0cmFwcy5jOjI1Nzk6
ZDB2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwMDAwMDAwNzkgZnJvbSAweDAw
MDAwMDAwMDAwMDAwMDAgdG8gMHhmZmZmYzkwMDAwNmYzMDMwLgooWEVOKSB0cmFwcy5jOjMx
NTE6IEdQRiAoMDAwMCk6IGZmZmY4MmQwODAxOTI1OTYgLT4gZmZmZjgyZDA4MDIzNWQzMQoo
WEVOKSB0cmFwcy5jOjI1Nzk6ZDB2MSBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAw
MDAwMDAwNzkgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHhmZmZmYzkwMDA0NzkzMDMw
LgooWEVOKSB0cmFwcy5jOjMxNTE6IEdQRiAoMDAwMCk6IGZmZmY4MmQwODAxOTI5MzUgLT4g
ZmZmZjgyZDA4MDIzNWQ1NwooWEVOKSB0cmFwcy5jOjMxNTE6IEdQRiAoMDAwMCk6IGZmZmY4
MmQwODAxOTI5MzUgLT4gZmZmZjgyZDA4MDIzNWQ1NwooWEVOKSB0cmFwcy5jOjMxNTE6IEdQ
RiAoMDAwMCk6IGZmZmY4MmQwODAxOTI5MzUgLT4gZmZmZjgyZDA4MDIzNWQ1NwooWEVOKSB0
cmFwcy5jOjMxNTE6IEdQRiAoMDAwMCk6IGZmZmY4MmQwODAxOTI5MzUgLT4gZmZmZjgyZDA4
MDIzNWQ1NwooZDEpIEhWTSBMb2FkZXIKKGQxKSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihk
MSkgWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBldmVudCBjaGFubmVsIDEKKGQxKSBTeXN0
ZW0gcmVxdWVzdGVkIFNlYUJJT1MKKGQxKSBDUFUgc3BlZWQgaXMgMTY5NiBNSHoKKGQxKSBS
ZWxvY2F0aW5nIGd1ZXN0IG1lbW9yeSBmb3IgbG93bWVtIE1NSU8gc3BhY2UgZGlzYWJsZWQK
KFhFTikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUKKGQxKSBQ
Q0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJRNQooWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJ
IGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKKGQxKSBQQ0ktSVNBIGxpbmsgMSByb3V0ZWQgdG8g
SVJRMTAKKFhFTikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDIgY2hhbmdlZCAwIC0+IDEx
CihkMSkgUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExCihYRU4pIGlycS5jOjI3MDog
RG9tMSBQQ0kgbGluayAzIGNoYW5nZWQgMCAtPiA1CihkMSkgUENJLUlTQSBsaW5rIDMgcm91
dGVkIHRvIElSUTUKKGQxKSBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTAKKGQxKSBwY2kgZGV2
IDAyOjAgSU5UQS0+SVJRMTEKKGQxKSBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQooZDEpIE5v
IFJBTSBpbiBoaWdoIG1lbW9yeTsgc2V0dGluZyBoaWdoX21lbSByZXNvdXJjZSBiYXNlIHRv
IDEwMDAwMDAwMAooZDEpIHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDIwMDAwMDA6IDBm
MDAwMDAwOAooZDEpIHBjaSBkZXYgMDI6MCBiYXIgMTQgc2l6ZSAwMDEwMDAwMDA6IDBmMjAw
MDAwOAooZDEpIHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAwNDAwMDA6IDBmMzAwMDAw
MAooZDEpIHBjaSBkZXYgMDM6MCBiYXIgMzAgc2l6ZSAwMDAwMTAwMDA6IDBmMzA0MDAwMAoo
ZDEpIHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDA6IDBmMzA1MDAwMAooZDEp
IHBjaSBkZXYgMDI6MCBiYXIgMTAgc2l6ZSAwMDAwMDAxMDA6IDAwMDAwYzAwMQooZDEpIHBj
aSBkZXYgMDQ6MCBiYXIgMTAgc2l6ZSAwMDAwMDAxMDA6IDAwMDAwYzEwMQooZDEpIHBjaSBk
ZXYgMDQ6MCBiYXIgMTQgc2l6ZSAwMDAwMDAxMDA6IDBmMzA1MTAwMAooZDEpIHBjaSBkZXYg
MDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAwMTA6IDAwMDAwYzIwMQooZDEpIE11bHRpcHJvY2Vz
c29yIGluaXRpYWxpc2F0aW9uOgooZDEpICAtIENQVTAgLi4uIDM5LWJpdCBwaHlzIC4uLiBm
aXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLgooZDEpICAtIENQVTEg
Li4uIDM5LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4u
LiBkb25lLgooZDEpIFRlc3RpbmcgSFZNIGVudmlyb25tZW50OgooZDEpICAtIFJFUCBJTlNC
IGFjcm9zcyBwYWdlIGJvdW5kYXJpZXMgLi4uIHBhc3NlZAooZDEpICAtIEdTIGJhc2UgTVNS
cyBhbmQgU1dBUEdTIC4uLiBwYXNzZWQKKGQxKSBQYXNzZWQgMiBvZiAyIHRlc3RzCihkMSkg
V3JpdGluZyBTTUJJT1MgdGFibGVzIC4uLgooZDEpIExvYWRpbmcgU2VhQklPUyAuLi4KKGQx
KSBDcmVhdGluZyBNUCB0YWJsZXMgLi4uCihkMSkgTG9hZGluZyBBQ1BJIC4uLgooZDEpIHZt
ODYgVFNTIGF0IGZjMDBhMTgwCihkMSkgQklPUyBtYXA6CihkMSkgIDEwMDAwLTEwMGQzOiBT
Y3JhdGNoIHNwYWNlCihkMSkgIGMwMDAwLWZmZmZmOiBNYWluIEJJT1MKKGQxKSBFODIwIHRh
YmxlOgooZDEpICBbMDBdOiAwMDAwMDAwMDowMDAwMDAwMCAtIDAwMDAwMDAwOjAwMGEwMDAw
OiBSQU0KKGQxKSAgSE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDowMDBjMDAw
MAooZDEpICBbMDFdOiAwMDAwMDAwMDowMDBjMDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBS
RVNFUlZFRAooZDEpICBbMDJdOiAwMDAwMDAwMDowMDEwMDAwMCAtIDAwMDAwMDAwOjdmODAw
MDAwOiBSQU0KKGQxKSAgSE9MRTogMDAwMDAwMDA6N2Y4MDAwMDAgLSAwMDAwMDAwMDpmYzAw
MDAwMAooZDEpICBbMDNdOiAwMDAwMDAwMDpmYzAwMDAwMCAtIDAwMDAwMDAxOjAwMDAwMDAw
OiBSRVNFUlZFRAooZDEpIEludm9raW5nIFNlYUJJT1MgLi4uCihkMSkgU2VhQklPUyAodmVy
c2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTExMl8xNzAwMzgtc21hcnRpbi14ZW4p
CihkMSkgCihkMSkgRm91bmQgWGVuIGh5cGVydmlzb3Igc2lnbmF0dXJlIGF0IDQwMDAwMTAw
CihkMSkgUnVubmluZyBvbiBRRU1VIChpNDQwZngpCihkMSkgeGVuOiBjb3B5IGU4MjAuLi4K
KGQxKSBSZWxvY2F0aW5nIGluaXQgZnJvbSAweDAwMGRmNjI5IHRvIDB4N2Y3YWU2MDAgKHNp
emUgNzE5OTUpCihkMSkgQ1BVIE1oej0xNjk2CihkMSkgRm91bmQgNyBQQ0kgZGV2aWNlcyAo
bWF4IFBDSSBidXMgaXMgMDApCihkMSkgQWxsb2NhdGVkIFhlbiBoeXBlcmNhbGwgcGFnZSBh
dCA3ZjdmZjAwMAooZDEpIERldGVjdGVkIFhlbiB2NC41LjAtcmMKKGQxKSB4ZW46IGNvcHkg
QklPUyB0YWJsZXMuLi4KKGQxKSBDb3B5aW5nIFNNQklPUyBlbnRyeSBwb2ludCBmcm9tIDB4
MDAwMTAwMTAgdG8gMHgwMDBmMGY1MAooZDEpIENvcHlpbmcgTVBUQUJMRSBmcm9tIDB4ZmMw
MDExNjAvZmMwMDExNzAgdG8gMHgwMDBmMGU1MAooZDEpIENvcHlpbmcgUElSIGZyb20gMHgw
MDAxMDAzMCB0byAweDAwMGYwZGQwCihkMSkgQ29weWluZyBBQ1BJIFJTRFAgZnJvbSAweDAw
MDEwMGIwIHRvIDB4MDAwZjBkYTAKKGQxKSBVc2luZyBwbXRpbWVyLCBpb3BvcnQgMHhiMDA4
CihkMSkgU2NhbiBmb3IgVkdBIG9wdGlvbiByb20KKGQxKSBSdW5uaW5nIG9wdGlvbiByb20g
YXQgYzAwMDowMDAzCihYRU4pIHN0ZHZnYS5jOjE0NzpkMXYwIGVudGVyaW5nIHN0ZHZnYSBh
bmQgY2FjaGluZyBtb2RlcwooZDEpIHBtbSBjYWxsIGFyZzE9MAooZDEpIFR1cm5pbmcgb24g
dmdhIHRleHQgbW9kZSBjb25zb2xlCihkMSkgU2VhQklPUyAodmVyc2lvbiByZWwtMS43LjUt
MC1nZTUxNDg4Yy0yMDE0MTExMl8xNzAwMzgtc21hcnRpbi14ZW4pCihkMSkgTWFjaGluZSBV
VUlEIDU4ZDMwNDNkLTllZGMtNDgwNy04ZTI3LTkwZjYxZGI1MWE1OAooZDEpIEFsbCB0aHJl
YWRzIGNvbXBsZXRlLgooZDEpIEZvdW5kIDAgbHB0IHBvcnRzCihkMSkgRm91bmQgMCBzZXJp
YWwgcG9ydHMKKGQxKSBBVEEgY29udHJvbGxlciAxIGF0IDFmMC8zZjQvMCAoaXJxIDE0IGRl
diA5KQooZDEpIEFUQSBjb250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUgZGV2IDkp
CihkMSkgYXRhMC0wOiBRRU1VIEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAoNzggR2lCeXRl
cykKKGQxKSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDEsMS9kcml2
ZUAwL2Rpc2tAMAooZDEpIFBTMiBrZXlib2FyZCBpbml0aWFsaXplZAooZDEpIEFsbCB0aHJl
YWRzIGNvbXBsZXRlLgooZDEpIFNjYW4gZm9yIG9wdGlvbiByb21zCihkMSkgUnVubmluZyBv
cHRpb24gcm9tIGF0IGM5ODA6MDAwMwooZDEpIHBtbSBjYWxsIGFyZzE9MQooZDEpIHBtbSBj
YWxsIGFyZzE9MAooZDEpIHBtbSBjYWxsIGFyZzE9MQooZDEpIHBtbSBjYWxsIGFyZzE9MAoo
ZDEpIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4LypANAooZDEpIAooZDEp
IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51LgooZDEpIAooZDEpIFNlYXJjaGluZyBib290b3Jk
ZXIgZm9yOiBIQUxUCihkMSkgZHJpdmUgMHgwMDBmMGQ1MDogUENIUz0xNjM4My8xNi82MyB0
cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTE2NDE0MTIwOAooZDEpIAooZDEp
IFNwYWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkNTAKKGQx
KSBSZXR1cm5lZCAyNTgwNDggYnl0ZXMgb2YgWm9uZUhpZ2gKKGQxKSBlODIwIG1hcCBoYXMg
NiBpdGVtczoKKGQxKSAgIDA6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAw
ID0gMSBSQU0KKGQxKSAgIDE6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEwMDAw
ID0gMiBSRVNFUlZFRAooZDEpICAgMjogMDAwMDAwMDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAx
MDAwMDAgPSAyIFJFU0VSVkVECihkMSkgICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAw
MDA3ZjdmZjAwMCA9IDEgUkFNCihkMSkgICA0OiAwMDAwMDAwMDdmN2ZmMDAwIC0gMDAwMDAw
MDA3ZjgwMDAwMCA9IDIgUkVTRVJWRUQKKGQxKSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAgLSAw
MDAwMDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRAooZDEpIGVudGVyIGhhbmRsZV8xOToKKGQx
KSAgIE5VTEwKKGQxKSBCb290aW5nIGZyb20gSGFyZCBEaXNrLi4uCihkMSkgQm9vdGluZyBm
cm9tIDAwMDA6N2MwMAooWEVOKSBzdGR2Z2EuYzoxNTE6ZDF2MCBsZWF2aW5nIHN0ZHZnYQoo
WEVOKSBkMTogVklSSURJQU4gR1VFU1RfT1NfSUQ6IHZlbmRvcjogMSBvczogNCBtYWpvcjog
NiBtaW5vcjogMSBzcDogMSBidWlsZDogMWRiMQooWEVOKSBkMTogVklSSURJQU4gSFlQRVJD
QUxMOiBlbmFibGVkOiAxIHBmbjogM2ZmZmYKKFhFTikgZDF2MDogVklSSURJQU4gQVBJQ19B
U1NJU1Q6IGVuYWJsZWQ6IDEgcGZuOiAzZmZmZQooWEVOKSBkMXYxOiBWSVJJRElBTiBBUElD
X0FTU0lTVDogZW5hYmxlZDogMSBwZm46IDNmZmZkCihYRU4pIGlycS5jOjI3MDogRG9tMSBQ
Q0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCihYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGlu
ayAxIGNoYW5nZWQgMTAgLT4gMAooWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxpbmsgMiBj
aGFuZ2VkIDExIC0+IDAKKFhFTikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDMgY2hhbmdl
ZCA1IC0+IDAKKFhFTikgZ3JhbnRfdGFibGUuYzoxMjk5OmQxdjAgRXhwYW5kaW5nIGRvbSAo
MSkgZ3JhbnQgdGFibGUgZnJvbSAoNCkgdG8gKDMyKSBmcmFtZXMuCihYRU4pIGlycS5jOjM4
MDogRG9tMSBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBHU0kgMjQKKFhFTikgW1ZULURdaW9t
bXUuYzoxNTkzOiBkMDpQQ0k6IHVubWFwIDAwMDA6MDA6MTkuMAooWEVOKSBbVlQtRF1pb21t
dS5jOjE0NTY6IGQyOlBDSTogbWFwIDAwMDA6MDA6MTkuMAooZDIpIDAwOjAwOjAwLjAwMCBz
cmMva2VybmVsLmNAMDAwNjU6IG1pY3JvX3B2IHN0YXJ0ZWQKKGQyKSAwMDowMDowMC4wMDAg
c3JjL2h5cGVydmlzb3IuY0AwMDE0NDogQWxsb2NhdGVkIG1lbW9yeSBwYWdlcyAgICAgICAg
ICAgOiAzMjc2OAooZDIpIDAwOjAwOjAwLjAwMCBzcmMvaHlwZXJ2aXNvci5jQDAwMTQ1OiBB
bGxvY2F0ZWQgbWVtb3J5IE1CICAgICAgICAgICAgICA6IDEyOAooZDIpIDAwOjAwOjAwLjAw
MCBzcmMvaHlwZXJ2aXNvci5jQDAwMTQ2OiBNYWNoaW5lIGFkZHJlc3Mgb2Ygc2hhcmVkIG1l
bW9yeSA6IDB4YzMzY2IwMDAKKGQyKSAwMDowMDowMC4wMDAgc3JjL3hlbm1tdS5jQDAwMDk1
OiBQaHlzaWNhbCBhZGRyZXNzIDB4MTAwMCBtYXBwZWQgdG8gbWFjaGluZSBhZGRyZXNzIDB4
YzMzY2IwMDAgZm9yIGEgbGVuZ3RoIG9mIDEgcGFnZXMKKGQyKSAwMzowNTo1OS43MDkgc3Jj
L3hlbmV2ZW50cy5jQDAwMTY4OiB1bm1hc2sgcG9ydCAyCihkMikgMDM6MDU6NTkuNzA5IHNy
Yy94ZW50aW1lLmNAMDAxNzM6IEluaXRpYWxpc2luZyB0aW1lciBpbnRlcmZhY2UKKGQyKSAx
NToxODo0Ni44OTMgc3JjL3hlbmV2ZW50cy5jQDAwMTY4OiB1bm1hc2sgcG9ydCAxCihkMikg
MTU6MTg6NDYuODk0IHNyYy94ZW5nbnR0YWIuY0AwMDM0NzogV2UgYXJlIHVzaW5nIGdyYW50
IHZlcnNpb24gMQooZDIpIDE1OjE4OjQ2Ljg5NCBzcmMveGVuZ250dGFiLmNAMDAzNzI6IGZy
YW1lWzBdPTExNzJjYyBtYXBwZWQgdG8gMHgxMTgwMDAKKGQyKSAxNToxODo0Ni44OTQgc3Jj
L3hlbm1tdS5jQDAwMDk1OiBQaHlzaWNhbCBhZGRyZXNzIDB4MTE4MDAwIG1hcHBlZCB0byBt
YWNoaW5lIGFkZHJlc3MgMHgxMTcyY2MwMDAgZm9yIGEgbGVuZ3RoIG9mIDEgcGFnZXMKKGQy
KSAxNToxODo0Ni44OTQgc3JjL3hlbmdudHRhYi5jQDAwMzcyOiBmcmFtZVsxXT0xMDAwNTAg
bWFwcGVkIHRvIDB4MTE5MDAwCihkMikgMTU6MTg6NDYuODk0IHNyYy94ZW5tbXUuY0AwMDA5
NTogUGh5c2ljYWwgYWRkcmVzcyAweDExOTAwMCBtYXBwZWQgdG8gbWFjaGluZSBhZGRyZXNz
IDB4MTAwMDUwMDAwIGZvciBhIGxlbmd0aCBvZiAxIHBhZ2VzCihkMikgMTU6MTg6NDYuODk0
IHNyYy94ZW5nbnR0YWIuY0AwMDM3MjogZnJhbWVbMl09MTE2OWQwIG1hcHBlZCB0byAweDEx
YTAwMAooZDIpIDE1OjE4OjQ2Ljg5NCBzcmMveGVubW11LmNAMDAwOTU6IFBoeXNpY2FsIGFk
ZHJlc3MgMHgxMWEwMDAgbWFwcGVkIHRvIG1hY2hpbmUgYWRkcmVzcyAweDExNjlkMDAwMCBm
b3IgYSBsZW5ndGggb2YgMSBwYWdlcwooZDIpIDE1OjE4OjQ2Ljg5NCBzcmMveGVuZ250dGFi
LmNAMDAzNzI6IGZyYW1lWzNdPTExNzBjMCBtYXBwZWQgdG8gMHgxMWIwMDAKKGQyKSAxNTox
ODo0Ni44OTQgc3JjL3hlbm1tdS5jQDAwMDk1OiBQaHlzaWNhbCBhZGRyZXNzIDB4MTFiMDAw
IG1hcHBlZCB0byBtYWNoaW5lIGFkZHJlc3MgMHgxMTcwYzAwMDAgZm9yIGEgbGVuZ3RoIG9m
IDEgcGFnZXMKKGQyKSAxNToxODo0Ni44OTQgc3JjL3hlbmV2ZW50cy5jQDAwMTY4OiB1bm1h
c2sgcG9ydCAzCihkMikgMTU6MTg6NDYuODk0IHNyYy9rZXJuZWwuY0AwMDA3MTogY2FsbGlu
ZyBtYWluCihkMikgMTU6MTg6NDYuODk0IHNyYy94ZW5ldmVudHMuY0AwMDE2ODogdW5tYXNr
IHBvcnQgNAooZDIpIDE1OjE4OjQ2Ljg5NCBzcmMveGVuZ250dGFiLmNAMDAzMDQ6IHBoeXNp
Y2FsX2FkZHJlc3M9MHgzM2YwMDAgbWFwcGVkIHRvIG1hY2hpbmVfYWRkcmVzcz0xMDFiOTMw
MDAgd2l0aCBncmFudF9yZWY9MjA0NwooZDIpIDE1OjE4OjQ2Ljg5NCBzcmMveGVuc3RvcmUu
Y0AwMDMwNTogV1JJVEUgZGV2aWNlL3BjaS8wL3BjaS1vcC1yZWYgLSAyMDQ3CihkMikgMTU6
MTg6NDYuODk0IHNyYy94ZW5zdG9yZS5jQDAwMzA1OiBXUklURSBkZXZpY2UvcGNpLzAvZXZl
bnQtY2hhbm5lbCAtIDQKKGQyKSAxNToxODo0Ni44OTUgc3JjL3hlbnN0b3JlLmNAMDAzMDU6
IFdSSVRFIGRldmljZS9wY2kvMC9tYWdpYyAtIDcKKGQyKSAxNToxODo0Ni44OTUgc3JjL3hl
bnN0b3JlLmNAMDAzMDU6IFdSSVRFIGRldmljZS9wY2kvMC9zdGF0ZSAtIDMKKGQyKSAxNTox
ODo0Ni44OTggc3JjL3hlbnN0b3JlLmNAMDAzMDU6IFdSSVRFIGRldmljZS9wY2kvMC9zdGF0
ZSAtIDQKKGQyKSAxNToxODo0Ni44OTkgc3JjL3hlbnBjaS5jQDAwMjk1OiBWaXJ0dWFsIERl
dmljZT0wMDAwOjAwOjAwLjAwCihkMikgMTU6MTg6NDYuODk5IHNyYy94ZW5wY2kuY0AwMDA2
ODogcGNpX2V2ZW50CihkMikgMTU6MTg6NDYuODk5IHNyYy94ZW5wY2kuY0AwMDA2ODogcGNp
X2V2ZW50CihkMikgMTU6MTg6NDYuODk5IHNyYy94ZW5wY2kuY0AwMDA2ODogcGNpX2V2ZW50
CihkMikgMTU6MTg6NDYuODk5IHNyYy94ZW5wY2kuY0AwMDA2ODogcGNpX2V2ZW50CihkMikg
MTU6MTg6NDYuODk5IHNyYy94ZW5wY2kuY0AwMDMxMDogMDAwMDowMDowMC4wMCAwMjAwOiA4
MDg2OjE1NTkgKHJldiAwNCkKKGQyKSAxNToxODo0Ni44OTkgc3JjL3hlbnBjaS5jQDAwMDY4
OiBwY2lfZXZlbnQKKGQyKSAxNToxODo0Ni44OTkgc3JjL3hlbnBjaS5jQDAwMDY4OiBwY2lf
ZXZlbnQKKGQyKSAxNToxODo0Ni44OTkgc3JjL3hlbnBjaS5jQDAwMDY4OiBwY2lfZXZlbnQK
KGQyKSAxNToxODo0Ni44OTkgc3JjL3hlbnBjaS5jQDAwMDY4OiBwY2lfZXZlbnQKKGQyKSAx
NToxODo0Ni44OTkgc3JjL2UxMDAwZS5jQDAwMTE5OiBSZWNvZ25pemVkIEV0aGVybmV0IE5J
QwooZDIpIDE1OjE4OjQ2LjkxNCBzcmMveGVuZ250dGFiLmNAMDAyMzE6IGdyYW50X2hhbmRs
ZSAwIGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzMxMDAwIG1hcHBlZCB0byBkb209MCB3aXRo
IGdyYW50X3JlZj0xNQooZDIpIDE1OjE4OjQ2LjkxNCBzcmMveGVuZ250dGFiLmNAMDAyMzE6
IGdyYW50X2hhbmRsZSAxIGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzMyMDAwIG1hcHBlZCB0
byBkb209MCB3aXRoIGdyYW50X3JlZj0xNgooZDIpIDE1OjE4OjQ2LjkxNCBzcmMveGVuZ250
dGFiLmNAMDAyMzE6IGdyYW50X2hhbmRsZSAyIGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzMz
MDAwIG1hcHBlZCB0byBkb209MCB3aXRoIGdyYW50X3JlZj0xNwooZDIpIDE1OjE4OjQ2Ljkx
NCBzcmMveGVuZ250dGFiLmNAMDAyMzE6IGdyYW50X2hhbmRsZSAzIGZvciBwaHlzaWNhbF9h
ZGRyZXNzPTB4MzM1MDAwIG1hcHBlZCB0byBkb209MCB3aXRoIGdyYW50X3JlZj0xOAooZDIp
IDE1OjE4OjQ2LjkxNSBzcmMveGVuZ250dGFiLmNAMDAyMzE6IGdyYW50X2hhbmRsZSA0IGZv
ciBwaHlzaWNhbF9hZGRyZXNzPTB4MzM2MDAwIG1hcHBlZCB0byBkb209MCB3aXRoIGdyYW50
X3JlZj0xOQooZDIpIDE1OjE4OjQ2LjkxNSBzcmMveGVuZ250dGFiLmNAMDAyMzE6IGdyYW50
X2hhbmRsZSA1IGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzM3MDAwIG1hcHBlZCB0byBkb209
MCB3aXRoIGdyYW50X3JlZj0yMAooZDIpIDE1OjE4OjQ2LjkxNSBzcmMveGVuZ250dGFiLmNA
MDAyMzE6IGdyYW50X2hhbmRsZSA2IGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzM4MDAwIG1h
cHBlZCB0byBkb209MCB3aXRoIGdyYW50X3JlZj0yMQooZDIpIDE1OjE4OjQ2LjkxNSBzcmMv
ZTEwMDBlLmNAMDAzMTA6IEVuYWJsZSBQQ0kgTWVtb3J5IEFjY2VzcwooZDIpIDE1OjE4OjQ2
LjkxNSBzcmMveGVucGNpLmNAMDAwNjg6IHBjaV9ldmVudAooZDIpIDE1OjE4OjQ2LjkxNSBz
cmMvZTEwMDBlLmNAMDAzMTQ6IFdhaXQgZm9yIFBDSQooZDIpIDE1OjE4OjQ3LjkxNSBzcmMv
eGVucGNpLmNAMDAwNjg6IHBjaV9ldmVudAooZDIpIDE1OjE4OjQ3LjkxNSBzcmMvZTEwMDBl
LmNAMDAzMjA6IEVuYWJsZSBQQ0kgTWVtb3J5IEFjY2Vzcz0zCihkMikgMTU6MTg6NDcuOTE1
IHNyYy9lMTAwMGUuY0AwMDMzMDogbmljX21hY2hpbmVfcHRyPWY3ZDAwMDAwIG5pY19sZW5n
dGg9MAooZDIpIDE1OjE4OjQ3LjkxNiBzcmMveGVubW11LmNAMDAwOTU6IFBoeXNpY2FsIGFk
ZHJlc3MgMHgzNDEwMDAgbWFwcGVkIHRvIG1hY2hpbmUgYWRkcmVzcyAweGY3ZDAwMDAwIGZv
ciBhIGxlbmd0aCBvZiAzMiBwYWdlcwooZDIpIDE1OjE4OjQ3LjkxNiBzcmMvZTEwMDBlLmNA
MDAzMzc6IG5pY19wdHI9MHgzNDEwMDAKKGQyKSAxNToxODo0Ny45MTYgc3JjL2UxMDAwZS5j
QDAwMzkwOiBXYWl0IGZvciByZXNldCAxMTE2MDczMjgzOTc5NSAxMTE2MDc1MjgzOTcyNiAy
MDAwMDAwMAooZDIpIDE1OjE4OjQ3LjkzNiBzcmMvZTEwMDBlLmNAMDA0MTE6IE1BQ19HZW5l
cmFsX0xFRENUTCAgICAgICAgICAgICA9MDAwMDBlZjQKKGQyKSAxNToxODo0Ny45MzYgc3Jj
L2UxMDAwZS5jQDAwNDIzOiBNQUMgYWRkcmVzcz1lYzphODo2YjpmZTowNTozZgooZDIpIDE1
OjE4OjQ3LjkzNiBzcmMvZTEwMDBlLmNAMDA0MjY6IEV0aGVybmV0IE5JQyBzdGFydGVkCihk
MikgMTU6MTk6MTAuOTI0IHNyYy9QVjQ5OU1haW4uY0AwMDEyODogQ2xlYW51cCBzdGFydHMK
KGQyKSAxNToxOToxMC45MjQgc3JjL1BWNDk5UENJLmNAMDAwODU6IFN0b3BwaW5nIGRldmlj
ZSBkZXZpY2UvcGNpLzAKKGQyKSAxNToxOToxMC45MjQgc3JjL2UxMDAwZS5jQDAwNDk0OiBF
dGhlcm5ldCBOSUMgc3RvcHBpbmcKKGQyKSAxNToxOToxMC45MjQgc3JjL3hlbnBjaS5jQDAw
MDY4OiBwY2lfZXZlbnQKKGQyKSAxNToxOToxMC45MjQgc3JjL2UxMDAwZS5jQDAwNTMxOiBF
dGhlcm5ldCBOSUMgc3RvcHBlZAooZDIpIDE1OjE5OjEwLjkyNCBzcmMvUFY0OTlQQ0kuY0Aw
MDA4OTogRGV2aWNlIGRldmljZS9wY2kvMCBzdG9wcGVkCihkMikgMTU6MTk6MTAuOTI1IHNy
Yy94ZW5zdG9yZS5jQDAwMzA1OiBXUklURSBkZXZpY2UvcGNpLzAvc3RhdGUgLSA1CihkMikg
MTU6MTk6MTAuOTI2IHNyYy94ZW5zdG9yZS5jQDAwMzA1OiBXUklURSBkZXZpY2UvcGNpLzAv
c3RhdGUgLSA2CihkMikgMTU6MTk6MTAuOTI3IHNyYy94ZW5zdG9yZS5jQDAwMzA1OiBXUklU
RSBkZXZpY2UvcGNpLzAvc3RhdGUgLSAwCihkMikgMTU6MTk6MTAuOTI3IHNyYy94ZW5nbnR0
YWIuY0AwMDI2NjogdW5tYXBwaW5nIGdyYW50X3JlZj0yMDQ3CihkMikgMTU6MTk6MTAuOTI3
IHNyYy94ZW5nbnR0YWIuY0AwMDIzODogVW5tYXAgaGFuZGxlPTAgZm9yIHBoeXNpY2FsX2Fk
ZHJlc3M9MHgzMzEwMDAKKGQyKSAxNToxOToxMC45Mjcgc3JjL3hlbmdudHRhYi5jQDAwMjM4
OiBVbm1hcCBoYW5kbGU9MSBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzMjAwMAooZDIpIDE1
OjE5OjEwLjkyNyBzcmMveGVuZ250dGFiLmNAMDAyMzg6IFVubWFwIGhhbmRsZT0yIGZvciBw
aHlzaWNhbF9hZGRyZXNzPTB4MzMzMDAwCihkMikgMTU6MTk6MTAuOTI3IHNyYy94ZW5nbnR0
YWIuY0AwMDIzODogVW5tYXAgaGFuZGxlPTMgZm9yIHBoeXNpY2FsX2FkZHJlc3M9MHgzMzUw
MDAKKGQyKSAxNToxOToxMC45Mjggc3JjL3hlbmdudHRhYi5jQDAwMjM4OiBVbm1hcCBoYW5k
bGU9NCBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzNjAwMAooZDIpIDE1OjE5OjEwLjkyOCBz
cmMveGVuZ250dGFiLmNAMDAyMzg6IFVubWFwIGhhbmRsZT01IGZvciBwaHlzaWNhbF9hZGRy
ZXNzPTB4MzM3MDAwCihkMikgMTU6MTk6MTAuOTI4IHNyYy94ZW5nbnR0YWIuY0AwMDIzODog
VW5tYXAgaGFuZGxlPTYgZm9yIHBoeXNpY2FsX2FkZHJlc3M9MHgzMzgwMDAKKGQyKSAxNTox
OToxMC45Mjggc3JjL1BWNDk5TWFpbi5jQDAwMTM0OiBDbGVhbnVwIHN0b3BzCihkMikgMTU6
MTk6MTAuOTI4IHNyYy94ZW5zY2hlZHVsZS5jQDAwMTU0OiBtaWNyb3B2X2V4aXQgY2FsbGVk
IQooWEVOKSBbVlQtRF1pb21tdS5jOjE1OTM6IGQyOlBDSTogdW5tYXAgMDAwMDowMDoxOS4w
CihYRU4pIFtWVC1EXWlvbW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxOS4wCihY
RU4pIFtWVC1EXWlvbW11LmM6MTU5MzogZDA6UENJOiB1bm1hcCAwMDAwOjAwOjE5LjAKKFhF
TikgW1ZULURdaW9tbXUuYzoxNDU2OiBkNDpQQ0k6IG1hcCAwMDAwOjAwOjE5LjAKKGQ0KSAw
MDowMDowMC4wMDAgc3JjL2tlcm5lbC5jQDAwMDY1OiBtaWNyb19wdiBzdGFydGVkCihkNCkg
MDA6MDA6MDAuMDAwIHNyYy9oeXBlcnZpc29yLmNAMDAxNDQ6IEFsbG9jYXRlZCBtZW1vcnkg
cGFnZXMgICAgICAgICAgIDogMzI3NjgKKGQ0KSAwMDowMDowMC4wMDAgc3JjL2h5cGVydmlz
b3IuY0AwMDE0NTogQWxsb2NhdGVkIG1lbW9yeSBNQiAgICAgICAgICAgICAgOiAxMjgKKGQ0
KSAwMDowMDowMC4wMDAgc3JjL2h5cGVydmlzb3IuY0AwMDE0NjogTWFjaGluZSBhZGRyZXNz
IG9mIHNoYXJlZCBtZW1vcnkgOiAweGJjYjljMDAwCihkNCkgMDA6MDA6MDAuMDAwIHNyYy94
ZW5tbXUuY0AwMDA5NTogUGh5c2ljYWwgYWRkcmVzcyAweDEwMDAgbWFwcGVkIHRvIG1hY2hp
bmUgYWRkcmVzcyAweGJjYjljMDAwIGZvciBhIGxlbmd0aCBvZiAxIHBhZ2VzCihkNCkgMDM6
MDY6NTMuODA3IHNyYy94ZW5ldmVudHMuY0AwMDE2ODogdW5tYXNrIHBvcnQgMgooZDQpIDAz
OjA2OjUzLjgwNyBzcmMveGVudGltZS5jQDAwMTczOiBJbml0aWFsaXNpbmcgdGltZXIgaW50
ZXJmYWNlCihkNCkgMTU6MTk6NDAuOTkwIHNyYy94ZW5ldmVudHMuY0AwMDE2ODogdW5tYXNr
IHBvcnQgMQooZDQpIDE1OjE5OjQwLjk5MSBzcmMveGVuZ250dGFiLmNAMDAzNDc6IFdlIGFy
ZSB1c2luZyBncmFudCB2ZXJzaW9uIDEKKGQ0KSAxNToxOTo0MC45OTEgc3JjL3hlbmdudHRh
Yi5jQDAwMzcyOiBmcmFtZVswXT0xMWQ5M2MgbWFwcGVkIHRvIDB4MTE4MDAwCihkNCkgMTU6
MTk6NDAuOTkxIHNyYy94ZW5tbXUuY0AwMDA5NTogUGh5c2ljYWwgYWRkcmVzcyAweDExODAw
MCBtYXBwZWQgdG8gbWFjaGluZSBhZGRyZXNzIDB4MTFkOTNjMDAwIGZvciBhIGxlbmd0aCBv
ZiAxIHBhZ2VzCihkNCkgMTU6MTk6NDAuOTkxIHNyYy94ZW5nbnR0YWIuY0AwMDM3MjogZnJh
bWVbMV09MTE2MjMzIG1hcHBlZCB0byAweDExOTAwMAooZDQpIDE1OjE5OjQwLjk5MSBzcmMv
eGVubW11LmNAMDAwOTU6IFBoeXNpY2FsIGFkZHJlc3MgMHgxMTkwMDAgbWFwcGVkIHRvIG1h
Y2hpbmUgYWRkcmVzcyAweDExNjIzMzAwMCBmb3IgYSBsZW5ndGggb2YgMSBwYWdlcwooZDQp
IDE1OjE5OjQwLjk5MSBzcmMveGVuZ250dGFiLmNAMDAzNzI6IGZyYW1lWzJdPTExNmI0MCBt
YXBwZWQgdG8gMHgxMWEwMDAKKGQ0KSAxNToxOTo0MC45OTEgc3JjL3hlbm1tdS5jQDAwMDk1
OiBQaHlzaWNhbCBhZGRyZXNzIDB4MTFhMDAwIG1hcHBlZCB0byBtYWNoaW5lIGFkZHJlc3Mg
MHgxMTZiNDAwMDAgZm9yIGEgbGVuZ3RoIG9mIDEgcGFnZXMKKGQ0KSAxNToxOTo0MC45OTEg
c3JjL3hlbmdudHRhYi5jQDAwMzcyOiBmcmFtZVszXT0xMWVjNWIgbWFwcGVkIHRvIDB4MTFi
MDAwCihkNCkgMTU6MTk6NDAuOTkxIHNyYy94ZW5tbXUuY0AwMDA5NTogUGh5c2ljYWwgYWRk
cmVzcyAweDExYjAwMCBtYXBwZWQgdG8gbWFjaGluZSBhZGRyZXNzIDB4MTFlYzViMDAwIGZv
ciBhIGxlbmd0aCBvZiAxIHBhZ2VzCihkNCkgMTU6MTk6NDAuOTkxIHNyYy94ZW5ldmVudHMu
Y0AwMDE2ODogdW5tYXNrIHBvcnQgMwooZDQpIDE1OjE5OjQwLjk5MSBzcmMva2VybmVsLmNA
MDAwNzE6IGNhbGxpbmcgbWFpbgooZDQpIDE1OjE5OjQwLjk5MSBzcmMveGVuZXZlbnRzLmNA
MDAxNjg6IHVubWFzayBwb3J0IDQKKGQ0KSAxNToxOTo0MC45OTEgc3JjL3hlbmdudHRhYi5j
QDAwMzA0OiBwaHlzaWNhbF9hZGRyZXNzPTB4MzNmMDAwIG1hcHBlZCB0byBtYWNoaW5lX2Fk
ZHJlc3M9MTAwMzQ5MDAwIHdpdGggZ3JhbnRfcmVmPTIwNDcKKGQ0KSAxNToxOTo0MC45OTEg
c3JjL3hlbnN0b3JlLmNAMDAzMDU6IFdSSVRFIGRldmljZS9wY2kvMC9wY2ktb3AtcmVmIC0g
MjA0NwooZDQpIDE1OjE5OjQwLjk5MSBzcmMveGVuc3RvcmUuY0AwMDMwNTogV1JJVEUgZGV2
aWNlL3BjaS8wL2V2ZW50LWNoYW5uZWwgLSA0CihkNCkgMTU6MTk6NDAuOTkxIHNyYy94ZW5z
dG9yZS5jQDAwMzA1OiBXUklURSBkZXZpY2UvcGNpLzAvbWFnaWMgLSA3CihkNCkgMTU6MTk6
NDAuOTkxIHNyYy94ZW5zdG9yZS5jQDAwMzA1OiBXUklURSBkZXZpY2UvcGNpLzAvc3RhdGUg
LSAzCihkNCkgMTU6MTk6NDAuOTk2IHNyYy94ZW5zdG9yZS5jQDAwMzA1OiBXUklURSBkZXZp
Y2UvcGNpLzAvc3RhdGUgLSA0CihkNCkgMTU6MTk6NDAuOTk2IHNyYy94ZW5wY2kuY0AwMDI5
NTogVmlydHVhbCBEZXZpY2U9MDAwMDowMDowMC4wMAooZDQpIDE1OjE5OjQwLjk5NiBzcmMv
eGVucGNpLmNAMDAwNjg6IHBjaV9ldmVudAooZDQpIDE1OjE5OjQwLjk5NiBzcmMveGVucGNp
LmNAMDAwNjg6IHBjaV9ldmVudAooZDQpIDE1OjE5OjQwLjk5NiBzcmMveGVucGNpLmNAMDAw
Njg6IHBjaV9ldmVudAooZDQpIDE1OjE5OjQwLjk5NiBzcmMveGVucGNpLmNAMDAwNjg6IHBj
aV9ldmVudAooZDQpIDE1OjE5OjQwLjk5NiBzcmMveGVucGNpLmNAMDAzMTA6IDAwMDA6MDA6
MDAuMDAgMDIwMDogODA4NjoxNTU5IChyZXYgMDQpCihkNCkgMTU6MTk6NDAuOTk2IHNyYy94
ZW5wY2kuY0AwMDA2ODogcGNpX2V2ZW50CihkNCkgMTU6MTk6NDAuOTk2IHNyYy94ZW5wY2ku
Y0AwMDA2ODogcGNpX2V2ZW50CihkNCkgMTU6MTk6NDAuOTk2IHNyYy94ZW5wY2kuY0AwMDA2
ODogcGNpX2V2ZW50CihkNCkgMTU6MTk6NDAuOTk2IHNyYy94ZW5wY2kuY0AwMDA2ODogcGNp
X2V2ZW50CihkNCkgMTU6MTk6NDAuOTk2IHNyYy9lMTAwMGUuY0AwMDExOTogUmVjb2duaXpl
ZCBFdGhlcm5ldCBOSUMKKGQ0KSAxNToxOTo0MS4wMTEgc3JjL3hlbmdudHRhYi5jQDAwMjMx
OiBncmFudF9oYW5kbGUgMCBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzMTAwMCBtYXBwZWQg
dG8gZG9tPTAgd2l0aCBncmFudF9yZWY9MjEKKGQ0KSAxNToxOTo0MS4wMTEgc3JjL3hlbmdu
dHRhYi5jQDAwMjMxOiBncmFudF9oYW5kbGUgMSBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMz
MjAwMCBtYXBwZWQgdG8gZG9tPTAgd2l0aCBncmFudF9yZWY9MjAKKGQ0KSAxNToxOTo0MS4w
MTEgc3JjL3hlbmdudHRhYi5jQDAwMjMxOiBncmFudF9oYW5kbGUgMiBmb3IgcGh5c2ljYWxf
YWRkcmVzcz0weDMzMzAwMCBtYXBwZWQgdG8gZG9tPTAgd2l0aCBncmFudF9yZWY9MTkKKGQ0
KSAxNToxOTo0MS4wMTEgc3JjL3hlbmdudHRhYi5jQDAwMjMxOiBncmFudF9oYW5kbGUgMyBm
b3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzNTAwMCBtYXBwZWQgdG8gZG9tPTAgd2l0aCBncmFu
dF9yZWY9MTgKKGQ0KSAxNToxOTo0MS4wMTEgc3JjL3hlbmdudHRhYi5jQDAwMjMxOiBncmFu
dF9oYW5kbGUgNCBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzNjAwMCBtYXBwZWQgdG8gZG9t
PTAgd2l0aCBncmFudF9yZWY9MTcKKGQ0KSAxNToxOTo0MS4wMTEgc3JjL3hlbmdudHRhYi5j
QDAwMjMxOiBncmFudF9oYW5kbGUgNSBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzNzAwMCBt
YXBwZWQgdG8gZG9tPTAgd2l0aCBncmFudF9yZWY9MTYKKGQ0KSAxNToxOTo0MS4wMTEgc3Jj
L3hlbmdudHRhYi5jQDAwMjMxOiBncmFudF9oYW5kbGUgNiBmb3IgcGh5c2ljYWxfYWRkcmVz
cz0weDMzODAwMCBtYXBwZWQgdG8gZG9tPTAgd2l0aCBncmFudF9yZWY9MTUKKGQ0KSAxNTox
OTo0MS4wMTEgc3JjL2UxMDAwZS5jQDAwMzEwOiBFbmFibGUgUENJIE1lbW9yeSBBY2Nlc3MK
KGQ0KSAxNToxOTo0MS4wMTIgc3JjL3hlbnBjaS5jQDAwMDY4OiBwY2lfZXZlbnQKKGQ0KSAx
NToxOTo0MS4wMTIgc3JjL2UxMDAwZS5jQDAwMzE0OiBXYWl0IGZvciBQQ0kKKGQ0KSAxNTox
OTo0Mi4wMTIgc3JjL3hlbnBjaS5jQDAwMDY4OiBwY2lfZXZlbnQKKGQ0KSAxNToxOTo0Mi4w
MTIgc3JjL2UxMDAwZS5jQDAwMzIwOiBFbmFibGUgUENJIE1lbW9yeSBBY2Nlc3M9MwooZDQp
IDE1OjE5OjQyLjAxMiBzcmMvZTEwMDBlLmNAMDAzMzA6IG5pY19tYWNoaW5lX3B0cj1mN2Qw
MDAwMCBuaWNfbGVuZ3RoPTAKKGQ0KSAxNToxOTo0Mi4wMTIgc3JjL3hlbm1tdS5jQDAwMDk1
OiBQaHlzaWNhbCBhZGRyZXNzIDB4MzQxMDAwIG1hcHBlZCB0byBtYWNoaW5lIGFkZHJlc3Mg
MHhmN2QwMDAwMCBmb3IgYSBsZW5ndGggb2YgMzIgcGFnZXMKKGQ0KSAxNToxOTo0Mi4wMTIg
c3JjL2UxMDAwZS5jQDAwMzM3OiBuaWNfcHRyPTB4MzQxMDAwCihkNCkgMTU6MTk6NDIuMDEy
IHNyYy9lMTAwMGUuY0AwMDM5MDogV2FpdCBmb3IgcmVzZXQgMTEyMTQ4MjkyMjc0MzcgMTEy
MTQ4NDkyMjczNjkgMjAwMDAwMDAKKGQ0KSAxNToxOTo0Mi4wMzIgc3JjL2UxMDAwZS5jQDAw
NDExOiBNQUNfR2VuZXJhbF9MRURDVEwgICAgICAgICAgICAgPWZmZmZmZmZmCihkNCkgMTU6
MTk6NDIuMDMyIHNyYy9lMTAwMGUuY0AwMDQyMzogTUFDIGFkZHJlc3M9ZmY6ZmY6ZmY6ZmY6
ZmY6ZmYKKGQ0KSAxNToxOTo0Mi4wMzIgc3JjL2UxMDAwZS5jQDAwNDI2OiBFdGhlcm5ldCBO
SUMgc3RhcnRlZAooZDQpIDE1OjE5OjQyLjAzMiBzcmMvZTEwMDBlLmNAMDA0NDU6IExJTksg
VVAKKGQ0KSAxNToxOTo0OC4wMjEgc3JjL1BWNDk5TWFpbi5jQDAwMTI4OiBDbGVhbnVwIHN0
YXJ0cwooZDQpIDE1OjE5OjQ4LjAyMSBzcmMvUFY0OTlQQ0kuY0AwMDA4NTogU3RvcHBpbmcg
ZGV2aWNlIGRldmljZS9wY2kvMAooZDQpIDE1OjE5OjQ4LjAyMSBzcmMvZTEwMDBlLmNAMDA0
OTQ6IEV0aGVybmV0IE5JQyBzdG9wcGluZwooZDQpIDE1OjE5OjQ4LjAyMSBzcmMveGVucGNp
LmNAMDAwNjg6IHBjaV9ldmVudAooZDQpIDE1OjE5OjQ4LjAyMSBzcmMvZTEwMDBlLmNAMDA1
MzE6IEV0aGVybmV0IE5JQyBzdG9wcGVkCihkNCkgMTU6MTk6NDguMDIxIHNyYy9QVjQ5OVBD
SS5jQDAwMDg5OiBEZXZpY2UgZGV2aWNlL3BjaS8wIHN0b3BwZWQKKGQ0KSAxNToxOTo0OC4w
MjEgc3JjL3hlbnN0b3JlLmNAMDAzMDU6IFdSSVRFIGRldmljZS9wY2kvMC9zdGF0ZSAtIDUK
KGQ0KSAxNToxOTo0OC4wMjIgc3JjL3hlbnN0b3JlLmNAMDAzMDU6IFdSSVRFIGRldmljZS9w
Y2kvMC9zdGF0ZSAtIDYKKGQ0KSAxNToxOTo0OC4wMjQgc3JjL3hlbnN0b3JlLmNAMDAzMDU6
IFdSSVRFIGRldmljZS9wY2kvMC9zdGF0ZSAtIDAKKGQ0KSAxNToxOTo0OC4wMjQgc3JjL3hl
bmdudHRhYi5jQDAwMjY2OiB1bm1hcHBpbmcgZ3JhbnRfcmVmPTIwNDcKKGQ0KSAxNToxOTo0
OC4wMjQgc3JjL3hlbmdudHRhYi5jQDAwMjM4OiBVbm1hcCBoYW5kbGU9MCBmb3IgcGh5c2lj
YWxfYWRkcmVzcz0weDMzMTAwMAooZDQpIDE1OjE5OjQ4LjAyNCBzcmMveGVuZ250dGFiLmNA
MDAyMzg6IFVubWFwIGhhbmRsZT0xIGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzMyMDAwCihk
NCkgMTU6MTk6NDguMDI0IHNyYy94ZW5nbnR0YWIuY0AwMDIzODogVW5tYXAgaGFuZGxlPTIg
Zm9yIHBoeXNpY2FsX2FkZHJlc3M9MHgzMzMwMDAKKGQ0KSAxNToxOTo0OC4wMjQgc3JjL3hl
bmdudHRhYi5jQDAwMjM4OiBVbm1hcCBoYW5kbGU9MyBmb3IgcGh5c2ljYWxfYWRkcmVzcz0w
eDMzNTAwMAooZDQpIDE1OjE5OjQ4LjAyNCBzcmMveGVuZ250dGFiLmNAMDAyMzg6IFVubWFw
IGhhbmRsZT00IGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzM2MDAwCihkNCkgMTU6MTk6NDgu
MDI0IHNyYy94ZW5nbnR0YWIuY0AwMDIzODogVW5tYXAgaGFuZGxlPTUgZm9yIHBoeXNpY2Fs
X2FkZHJlc3M9MHgzMzcwMDAKKGQ0KSAxNToxOTo0OC4wMjQgc3JjL3hlbmdudHRhYi5jQDAw
MjM4OiBVbm1hcCBoYW5kbGU9NiBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzODAwMAooZDQp
IDE1OjE5OjQ4LjAyNCBzcmMvUFY0OTlNYWluLmNAMDAxMzQ6IENsZWFudXAgc3RvcHMKKGQ0
KSAxNToxOTo0OC4wMjQgc3JjL3hlbnNjaGVkdWxlLmNAMDAxNTQ6IG1pY3JvcHZfZXhpdCBj
YWxsZWQhCihYRU4pIFtWVC1EXWlvbW11LmM6MTU5MzogZDQ6UENJOiB1bm1hcCAwMDAwOjAw
OjE5LjAKKFhFTikgW1ZULURdaW9tbXUuYzoxNDU2OiBkMDpQQ0k6IG1hcCAwMDAwOjAwOjE5
LjAK
------------0410070F03E0EB1B3
Content-Type: application/octet-stream;
 name=dmesg
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename=dmesg

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAg
MC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAw
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVhY2N0ClsgICAgMC4wMDAwMDBdIExp
bnV4IHZlcnNpb24gMy4xNi0wLmJwby4zLWFtZDY0IChkZWJpYW4ta2VybmVsQGxpc3RzLmRl
Ymlhbi5vcmcpIChnY2MgdmVyc2lvbiA0LjYuMyAoRGViaWFuIDQuNi4zLTE0KSApICMxIFNN
UCBEZWJpYW4gMy4xNi41LTF+YnBvNzArMSAoMjAxNC0xMS0wMikKWyAgICAwLjAwMDAwMF0g
Q29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciByb290PVVVSUQ9OWQyZjgwZjktOGJkYy00NzA2
LWI3NGEtYjQ3NjA1NjkyMmQ3IHJvIHF1aWV0ClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgOWQt
MTAwIHBmbiByYW5nZTogOTkgcGFnZXMgZnJlZWQKWyAgICAwLjAwMDAwMF0gMS0xIG1hcHBp
bmcgb24gOWQtPjEwMApbICAgIDAuMDAwMDAwXSBGcmVlaW5nIGM4NTIyLWM4NTI5IHBmbiBy
YW5nZTogNyBwYWdlcyBmcmVlZApbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiBjODUy
Mi0+Yzg1MjkKWyAgICAwLjAwMDAwMF0gRnJlZWluZyBkYmE4NS1kYmZmZiBwZm4gcmFuZ2U6
IDE0MDIgcGFnZXMgZnJlZWQKWyAgICAwLjAwMDAwMF0gMS0xIG1hcHBpbmcgb24gZGJhODUt
PmRiZmZmClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgZGMwMDAtZWY5NzMgcGZuIHJhbmdlOiA4
MDI0MyBwYWdlcyBmcmVlZApbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiBkYzAwMC0+
MTAwMDAwClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDgxNzUxIHBhZ2VzIG9mIHVudXNlZCBt
ZW1vcnkKWyAgICAwLjAwMDAwMF0gU2V0IDE0ODk2NCBwYWdlKHMpIHRvIDEtMSBtYXBwaW5n
ClsgICAgMC4wMDAwMDBdIFBvcHVsYXRpbmcgMTAwMDAwLTExM2Y1NyBwZm4gcmFuZ2U6IDgx
NzUxIHBhZ2VzIGFkZGVkClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIDExZmUwMC0+
ODAwMDAwMApbICAgIDAuMDAwMDAwXSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJB
TSBtYXA6ClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgw
MDAwMDAwMDAwMDljZmZmXSB1c2FibGUKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAw
MDAwMDAwMDA5ZDgwMC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMGM4NTIxZmZmXSB1
c2FibGUKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBjODUyMjAwMC0weDAw
MDAwMDAwYzg1MjhmZmZdIEFDUEkgTlZTClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAw
MDAwMDAwYzg1MjkwMDAtMHgwMDAwMDAwMGRiYTg0ZmZmXSB1c2FibGUKWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBkYmE4NTAwMC0weDAwMDAwMDAwZGJiMGVmZmZdIHJl
c2VydmVkClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZGJiMGYwMDAtMHgw
MDAwMDAwMGRiYjI4ZmZmXSBBQ1BJIGRhdGEKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwMDBkYmIyOTAwMC0weDAwMDAwMDAwZGJjOTFmZmZdIEFDUEkgTlZTClsgICAgMC4w
MDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZGJjOTIwMDAtMHgwMDAwMDAwMGRiZmZlZmZm
XSByZXNlcnZlZApbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGRiZmZmMDAw
LTB4MDAwMDAwMDBkYmZmZmZmZl0gdXNhYmxlClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwZGQwMDAwMDAtMHgwMDAwMDAwMGRmMWZmZmZmXSByZXNlcnZlZApbICAgIDAu
MDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGY4MDAwMDAwLTB4MDAwMDAwMDBmYmZmZmZm
Zl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWMwMDAw
MC0weDAwMDAwMDAwZmVjMDBmZmZdIHJlc2VydmVkClsgICAgMC4wMDAwMDBdIFhlbjogW21l
bSAweDAwMDAwMDAwZmVkMDAwMDAtMHgwMDAwMDAwMGZlZDAzZmZmXSByZXNlcnZlZApbICAg
IDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZDFjMDAwLTB4MDAwMDAwMDBmZWQx
ZmZmZl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWQ5
MDAwMC0weDAwMDAwMDAwZmVkOTFmZmZdIHJlc2VydmVkClsgICAgMC4wMDAwMDBdIFhlbjog
W21lbSAweDAwMDAwMDAwZmVlMDAwMDAtMHgwMDAwMDAwMGZlZWZmZmZmXSByZXNlcnZlZApb
ICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmMDAwMDAwLTB4MDAwMDAwMDBm
ZmZmZmZmZl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDEw
MDAwMDAwMC0weDAwMDAwMDAxMWZkZmZmZmZdIHVzYWJsZQpbICAgIDAuMDAwMDAwXSBOWCAo
RXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUKWyAgICAwLjAwMDAwMF0gU01C
SU9TIDIuOCBwcmVzZW50LgpbICAgIDAuMDAwMDAwXSBETUk6ICAgICAgICAgICAgICAgICAg
L0QzNDAxMFdZSywgQklPUyBXWUxQVDEwSC44NkEuMDAyMi4yMDEzLjExMjEuMTc1NyAxMS8y
MS8yMDEzClsgICAgMC4wMDAwMDBdIGU4MjA6IHVwZGF0ZSBbbWVtIDB4MDAwMDAwMDAtMHgw
MDAwMGZmZl0gdXNhYmxlID09PiByZXNlcnZlZApbICAgIDAuMDAwMDAwXSBlODIwOiByZW1v
dmUgW21lbSAweDAwMGEwMDAwLTB4MDAwZmZmZmZdIHVzYWJsZQpbICAgIDAuMDAwMDAwXSBB
R1A6IE5vIEFHUCBicmlkZ2UgZm91bmQKWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4g
PSAweDExZmUwMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBl
ODIwOiBsYXN0X3BmbiA9IDB4ZGMwMDAgbWF4X2FyY2hfcGZuID0gMHg0MDAwMDAwMDAKWyAg
ICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBhdCBbZmZmZjg4MDAwMDA5NzAw
MF0gOTcwMDAgc2l6ZSAyNDU3NgpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5n
OiBbbWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0KWyAgICAwLjAwMDAwMF0gIFttZW0gMHgw
MDAwMDAwMC0weDAwMGZmZmZmXSBwYWdlIDRrClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5
X21hcHBpbmc6IFttZW0gMHgxMTNjMDAwMDAtMHgxMTNkZmZmZmZdClsgICAgMC4wMDAwMDBd
ICBbbWVtIDB4MTEzYzAwMDAwLTB4MTEzZGZmZmZmXSBwYWdlIDRrClsgICAgMC4wMDAwMDBd
IEJSSyBbMHgwMWIwYTAwMCwgMHgwMWIwYWZmZl0gUEdUQUJMRQpbICAgIDAuMDAwMDAwXSBC
UksgWzB4MDFiMGIwMDAsIDB4MDFiMGJmZmZdIFBHVEFCTEUKWyAgICAwLjAwMDAwMF0gaW5p
dF9tZW1vcnlfbWFwcGluZzogW21lbSAweDExMDAwMDAwMC0weDExM2JmZmZmZl0KWyAgICAw
LjAwMDAwMF0gIFttZW0gMHgxMTAwMDAwMDAtMHgxMTNiZmZmZmZdIHBhZ2UgNGsKWyAgICAw
LjAwMDAwMF0gQlJLIFsweDAxYjBjMDAwLCAweDAxYjBjZmZmXSBQR1RBQkxFClsgICAgMC4w
MDAwMDBdIEJSSyBbMHgwMWIwZDAwMCwgMHgwMWIwZGZmZl0gUEdUQUJMRQpbICAgIDAuMDAw
MDAwXSBCUksgWzB4MDFiMGUwMDAsIDB4MDFiMGVmZmZdIFBHVEFCTEUKWyAgICAwLjAwMDAw
MF0gQlJLIFsweDAxYjBmMDAwLCAweDAxYjBmZmZmXSBQR1RBQkxFClsgICAgMC4wMDAwMDBd
IGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgxMDAwMDAwMDAtMHgxMGZmZmZmZmZdClsg
ICAgMC4wMDAwMDBdICBbbWVtIDB4MTAwMDAwMDAwLTB4MTBmZmZmZmZmXSBwYWdlIDRrClsg
ICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgwMDEwMDAwMC0weGM4
NTIxZmZmXQpbICAgIDAuMDAwMDAwXSAgW21lbSAweDAwMTAwMDAwLTB4Yzg1MjFmZmZdIHBh
Z2UgNGsKWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweGM4NTI5
MDAwLTB4ZGJhODRmZmZdClsgICAgMC4wMDAwMDBdICBbbWVtIDB4Yzg1MjkwMDAtMHhkYmE4
NGZmZl0gcGFnZSA0awpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVt
IDB4ZGJmZmYwMDAtMHhkYmZmZmZmZl0KWyAgICAwLjAwMDAwMF0gIFttZW0gMHhkYmZmZjAw
MC0weGRiZmZmZmZmXSBwYWdlIDRrClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBp
bmc6IFttZW0gMHgxMTNlMDAwMDAtMHgxMWZkZmZmZmZdClsgICAgMC4wMDAwMDBdICBbbWVt
IDB4MTEzZTAwMDAwLTB4MTFmZGZmZmZmXSBwYWdlIDRrClsgICAgMC4wMDAwMDBdIFJBTURJ
U0s6IFttZW0gMHgwMWYxNTAwMC0weDA0OWFlZmZmXQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBF
YXJseSB0YWJsZSBjaGVja3N1bSB2ZXJpZmljYXRpb24gZGlzYWJsZWQKWyAgICAwLjAwMDAw
MF0gQUNQSTogUlNEUCAweDAwMDAwMDAwMDAwRjA0OTAgMDAwMDI0ICh2MDIgSU5URUwgKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBYU0RUIDB4MDAwMDAwMDBEQkIxNDA4MCAwMDAwODQgKHYw
MSBJTlRFTCAgRDM0MDEwV1kgMDAwMDAwMTYgQU1JICAwMDAxMDAxMykKWyAgICAwLjAwMDAw
MF0gQUNQSTogRkFDUCAweDAwMDAwMDAwREJCMjNBMDggMDAwMTBDICh2MDUgSU5URUwgIEQz
NDAxMFdZIDAwMDAwMDE2IEFNSSAgMDAwMTAwMTMpClsgICAgMC4wMDAwMDBdIEFDUEk6IERT
RFQgMHgwMDAwMDAwMERCQjE0MTk4IDAwRjg3MCAodjAyIElOVEVMICBEMzQwMTBXWSAwMDAw
MDAxNiBJTlRMIDIwMTIwNzExKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBGQUNTIDB4MDAwMDAw
MDBEQkM5MDA4MCAwMDAwNDAKWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAweDAwMDAwMDAw
REJCMjNCMTggMDAwMDcyICh2MDMgSU5URUwgIEQzNDAxMFdZIDAwMDAwMDE2IEFNSSAgMDAw
MTAwMTMpClsgICAgMC4wMDAwMDBdIEFDUEk6IEZQRFQgMHgwMDAwMDAwMERCQjIzQjkwIDAw
MDA0NCAodjAxIElOVEVMICBEMzQwMTBXWSAwMDAwMDAxNiBBTUkgIDAwMDEwMDEzKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMUElUIDB4MDAwMDAwMDBEQkIyM0JEOCAwMDAwNUMgKHYwMSBJ
TlRFTCAgRDM0MDEwV1kgMDAwMDAwMTYgQU1JLiAwMDAwMDAwNSkKWyAgICAwLjAwMDAwMF0g
QUNQSTogU1NEVCAweDAwMDAwMDAwREJCMjNDMzggMDAwNDk0ICh2MDEgSU5URUwgIEQzNDAx
MFdZIDAwMDAwMDE2IElOVEwgMjAxMjA3MTEpClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQg
MHgwMDAwMDAwMERCQjI0MEQwIDAwMEFEOCAodjAxIElOVEVMICBEMzQwMTBXWSAwMDAwMDAx
NiBJTlRMIDIwMTIwNzExKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDB4MDAwMDAwMDBE
QkIyNEJBOCAwMDAwM0MgKHYwMSBJTlRFTCAgRDM0MDEwV1kgMDAwMDAwMTYgTVNGVCAwMDAw
MDA5NykKWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCAweDAwMDAwMDAwREJCMjRCRTggMDAw
MDM4ICh2MDEgSU5URUwgIEQzNDAxMFdZIDAwMDAwMDE2IEFNSS4gMDAwMDAwMDUpClsgICAg
MC4wMDAwMDBdIEFDUEk6IFNTRFQgMHgwMDAwMDAwMERCQjI0QzIwIDAwMDMxNSAodjAxIElO
VEVMICBEMzQwMTBXWSAwMDAwMDAxNiBJTlRMIDIwMTIwNzExKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBTU0RUIDB4MDAwMDAwMDBEQkIyNEYzOCAwMDMwMDQgKHYwMSBJTlRFTCAgRDM0MDEw
V1kgMDAwMDAwMTYgSU5UTCAyMDA5MTExMikKWyAgICAwLjAwMDAwMF0gQUNQSTogWE1BUiAw
eDAwMDAwMDAwREJCMjdGNDAgMDAwMTkwICh2MDEgSU5URUwgIEQzNDAxMFdZIDAwMDAwMDE2
IElOVEwgMDAwMDAwMDEpClsgICAgMC4wMDAwMDBdIEFDUEk6IENTUlQgMHgwMDAwMDAwMERC
QjI4MEQwIDAwMDBDNCAodjAxIElOVEVMICBEMzQwMTBXWSAwMDAwMDAxNiBJTlRMIDIwMTAw
NTI4KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAw
MApbICAgIDAuMDAwMDAwXSBOVU1BIHR1cm5lZCBvZmYKWyAgICAwLjAwMDAwMF0gRmFraW5n
IGEgbm9kZSBhdCBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAxMWZkZmZmZmZd
ClsgICAgMC4wMDAwMDBdIEluaXRtZW0gc2V0dXAgbm9kZSAwIFttZW0gMHgwMDAwMDAwMC0w
eDExZmRmZmZmZl0KWyAgICAwLjAwMDAwMF0gICBOT0RFX0RBVEEgW21lbSAweDExM2Y1MjAw
MC0weDExM2Y1NmZmZl0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6ClsgICAgMC4wMDAw
MDBdICAgRE1BICAgICAgW21lbSAweDAwMDAxMDAwLTB4MDBmZmZmZmZdClsgICAgMC4wMDAw
MDBdICAgRE1BMzIgICAgW21lbSAweDAxMDAwMDAwLTB4ZmZmZmZmZmZdClsgICAgMC4wMDAw
MDBdICAgTm9ybWFsICAgW21lbSAweDEwMDAwMDAwMC0weDExZmRmZmZmZl0KWyAgICAwLjAw
MDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0IGZvciBlYWNoIG5vZGUKWyAgICAwLjAwMDAwMF0g
RWFybHkgbWVtb3J5IG5vZGUgcmFuZ2VzClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFtt
ZW0gMHgwMDAwMTAwMC0weDAwMDljZmZmXQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBb
bWVtIDB4MDAxMDAwMDAtMHhjODUyMWZmZl0KWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDog
W21lbSAweGM4NTI5MDAwLTB4ZGJhODRmZmZdClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6
IFttZW0gMHhkYmZmZjAwMC0weGRiZmZmZmZmXQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAw
OiBbbWVtIDB4MTAwMDAwMDAwLTB4MTFmZGZmZmZmXQpbICAgIDAuMDAwMDAwXSBPbiBub2Rl
IDAgdG90YWxwYWdlczogMTAzMDE3MQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiA1NiBw
YWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMjEgcGFn
ZXMgcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMzk5NiBwYWdlcywgTElG
TyBiYXRjaDowClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogMTIyNDUgcGFnZXMgdXNl
ZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogODk1NjE1IHBhZ2Vz
LCBMSUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdICAgTm9ybWFsIHpvbmU6IDE3ODUgcGFn
ZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgTm9ybWFsIHpvbmU6IDEzMDU2
MCBwYWdlcywgTElGTyBiYXRjaDozMQpbICAgIDAuMDAwMDAwXSBSZXNlcnZpbmcgSW50ZWwg
Z3JhcGhpY3Mgc3RvbGVuIG1lbW9yeSBhdCAweGRkMjAwMDAwLTB4ZGYxZmZmZmYKWyAgICAw
LjAwMDAwMF0gQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHgxODA4ClsgICAgMC4wMDAwMDBd
IEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDJdIGVu
YWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGlj
X2lkWzB4MDFdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDX05NSSAoYWNwaV9pZFsweGZmXSBoaWdoIGVkZ2UgbGludFsweDFdKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDJdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jh
c2VbMF0pClsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCAyLCB2ZXJzaW9uIDMy
LCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTM5ClsgICAgMC4wMDAwMDBdIEFDUEk6IElO
VF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpClsgICAg
MC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2ly
cSA5IGhpZ2ggbGV2ZWwpClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTAgdXNlZCBieSBvdmVy
cmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuClsgICAgMC4wMDAwMDBd
IFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBIUEVUIGlkOiAweDgwODZhNzAxIGJhc2U6IDB4ZmVkMDAw
MDAKWyAgICAwLjAwMDAwMF0gc21wYm9vdDogQWxsb3dpbmcgNCBDUFVzLCAwIGhvdHBsdWcg
Q1BVcwpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogNTYKWyAgICAwLjAwMDAwMF0gUE06
IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweDAwMDlkMDAwLTB4MDAwOWRmZmZd
ClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHgw
MDA5ZTAwMC0weDAwMGZmZmZmXQpbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3Nh
dmUgbWVtb3J5OiBbbWVtIDB4Yzg1MjIwMDAtMHhjODUyOGZmZl0KWyAgICAwLjAwMDAwMF0g
UE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGRiYTg1MDAwLTB4ZGJiMGVm
ZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0g
MHhkYmIwZjAwMC0weGRiYjI4ZmZmXQpbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBu
b3NhdmUgbWVtb3J5OiBbbWVtIDB4ZGJiMjkwMDAtMHhkYmM5MWZmZl0KWyAgICAwLjAwMDAw
MF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGRiYzkyMDAwLTB4ZGJm
ZmVmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFtt
ZW0gMHhkYzAwMDAwMC0weGRjZmZmZmZmXQpbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJl
ZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZGQwMDAwMDAtMHhkZjFmZmZmZl0KWyAgICAwLjAw
MDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGRmMjAwMDAwLTB4
ZjdmZmZmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6
IFttZW0gMHhmODAwMDAwMC0weGZiZmZmZmZmXQpbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0
ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZmMwMDAwMDAtMHhmZWJmZmZmZl0KWyAgICAw
LjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGZlYzAwMDAw
LTB4ZmVjMDBmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v
cnk6IFttZW0gMHhmZWMwMTAwMC0weGZlY2ZmZmZmXQpbICAgIDAuMDAwMDAwXSBQTTogUmVn
aXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZmVkMDAwMDAtMHhmZWQwM2ZmZl0KWyAg
ICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGZlZDA0
MDAwLTB4ZmVkMWJmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBt
ZW1vcnk6IFttZW0gMHhmZWQxYzAwMC0weGZlZDFmZmZmXQpbICAgIDAuMDAwMDAwXSBQTTog
UmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZmVkMjAwMDAtMHhmZWQ4ZmZmZl0K
WyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGZl
ZDkwMDAwLTB4ZmVkOTFmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2
ZSBtZW1vcnk6IFttZW0gMHhmZWQ5MjAwMC0weGZlZGZmZmZmXQpbICAgIDAuMDAwMDAwXSBQ
TTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZmVlMDAwMDAtMHhmZWVmZmZm
Zl0KWyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAw
eGZlZjAwMDAwLTB4ZmVmZmZmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5v
c2F2ZSBtZW1vcnk6IFttZW0gMHhmZjAwMDAwMC0weGZmZmZmZmZmXQpbICAgIDAuMDAwMDAw
XSBlODIwOiBbbWVtIDB4ZGYyMDAwMDAtMHhmN2ZmZmZmZl0gYXZhaWxhYmxlIGZvciBQQ0kg
ZGV2aWNlcwpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwg
b24gWGVuClsgICAgMC4wMDAwMDBdIFhlbiB2ZXJzaW9uOiA0LjUuMC1yYyAocHJlc2VydmUt
QUQpClsgICAgMC4wMDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo1MTIgbnJfY3B1bWFz
a19iaXRzOjUxMiBucl9jcHVfaWRzOjQgbnJfbm9kZV9pZHM6MQpbICAgIDAuMDAwMDAwXSBQ
RVJDUFU6IEVtYmVkZGVkIDI4IHBhZ2VzL2NwdSBAZmZmZjg4MDExMmMwMDAwMCBzODU2OTYg
cjgxOTIgZDIwODAwIHU1MjQyODgKWyAgICAwLjAwMDAwMF0gcGNwdS1hbGxvYzogczg1Njk2
IHI4MTkyIGQyMDgwMCB1NTI0Mjg4IGFsbG9jPTEqMjA5NzE1MgpbICAgIDAuMDAwMDAwXSBw
Y3B1LWFsbG9jOiBbMF0gMCAxIDIgMyAKWyAgICAwLjAwMDAwMF0gQnVpbHQgMSB6b25lbGlz
dHMgaW4gTm9kZSBvcmRlciwgbW9iaWxpdHkgZ3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczog
MTAxNjA2NApbICAgIDAuMDAwMDAwXSBQb2xpY3kgem9uZTogTm9ybWFsClsgICAgMC4wMDAw
MDBdIEtlcm5lbCBjb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVyIHJvb3Q9VVVJRD05ZDJmODBm
OS04YmRjLTQ3MDYtYjc0YS1iNDc2MDU2OTIyZDcgcm8gcXVpZXQKWyAgICAwLjAwMDAwMF0g
UElEIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQpb
ICAgIDAuMDAwMDAwXSB4c2F2ZTogZW5hYmxlZCB4c3RhdGVfYnYgMHg3LCBjbnR4dCBzaXpl
IDB4MzQwClsgICAgMC4wMDAwMDBdIHNvZnR3YXJlIElPIFRMQiBbbWVtIDB4MTBhZTAwMDAw
LTB4MTBlZTAwMDAwXSAoNjRNQikgbWFwcGVkIGF0IFtmZmZmODgwMTBhZTAwMDAwLWZmZmY4
ODAxMGVkZmZmZmZdClsgICAgMC4wMDAwMDBdIE1lbW9yeTogMzczMDQ0OEsvNDEyMDY4NEsg
YXZhaWxhYmxlICg1NDI2SyBrZXJuZWwgY29kZSwgOTM2SyByd2RhdGEsIDE4MjRLIHJvZGF0
YSwgMTIwNEsgaW5pdCwgODQwSyBic3MsIDM5MDIzNksgcmVzZXJ2ZWQpClsgICAgMC4wMDAw
MDBdIEhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uClsgICAgMC4wMDAwMDBdIAlS
Q1UgZHludGljay1pZGxlIGdyYWNlLXBlcmlvZCBhY2NlbGVyYXRpb24gaXMgZW5hYmxlZC4K
WyAgICAwLjAwMDAwMF0gCVJDVSByZXN0cmljdGluZyBDUFVzIGZyb20gTlJfQ1BVUz01MTIg
dG8gbnJfY3B1X2lkcz0yLgpbICAgIDAuMDAwMDAwXSBSQ1U6IEFkanVzdGluZyBnZW9tZXRy
eSBmb3IgcmN1X2Zhbm91dF9sZWFmPTE2LCBucl9jcHVfaWRzPTIKWyAgICAwLjAwMDAwMF0g
TlJfSVJRUzozMzAyNCBucl9pcnFzOjUxMiAxNgpbICAgIDAuMDAwMDAwXSB4ZW46ZXZlbnRz
OiBVc2luZyBGSUZPLWJhc2VkIEFCSQpbICAgIDAuMDAwMDAwXSB4ZW46IHNjaSBvdmVycmlk
ZTogZ2xvYmFsX2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0wClsgICAgMC4wMDAwMDBdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDAKWyAgICAwLjAw
MDAwMF0geGVuOiAtLT4gcGlycT05IC0+IGlycT05IChnc2k9OSkKWyAgICAwLjAwMDAwMF0g
eGVuOiBhY3BpIHNjaSA5ClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9
MSAoZ3NpPTEpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3Np
PTIpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MyAtPiBpcnE9MyAoZ3NpPTMpClsg
ICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NCAtPiBpcnE9NCAoZ3NpPTQpClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9NSAtPiBpcnE9NSAoZ3NpPTUpClsgICAgMC4wMDAwMDBd
IHhlbjogLS0+IHBpcnE9NiAtPiBpcnE9NiAoZ3NpPTYpClsgICAgMC4wMDAwMDBdIHhlbjog
LS0+IHBpcnE9NyAtPiBpcnE9NyAoZ3NpPTcpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBp
cnE9OCAtPiBpcnE9OCAoZ3NpPTgpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTAg
LT4gaXJxPTEwIChnc2k9MTApClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTEgLT4g
aXJxPTExIChnc2k9MTEpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTIgLT4gaXJx
PTEyIChnc2k9MTIpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTMgLT4gaXJxPTEz
IChnc2k9MTMpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTQgLT4gaXJxPTE0IChn
c2k9MTQpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTUgLT4gaXJxPTE1IChnc2k9
MTUpClsgICAgMC4wMDAwMDBdIENvbnNvbGU6IGNvbG91ciBWR0ErIDgweDI1ClsgICAgMC4w
MDAwMDBdIGNvbnNvbGUgW3R0eTBdIGVuYWJsZWQKWyAgICAwLjAwMDAwMF0gWGVuOiB1c2lu
ZyB2Y3B1b3AgdGltZXIgaW50ZXJmYWNlClsgICAgMC4wMDAwMDBdIGluc3RhbGxpbmcgWGVu
IHRpbWVyIGZvciBDUFUgMApbICAgIDAuMDAwMDAwXSB0c2M6IERldGVjdGVkIDE2OTYuMTQ2
IE1IeiBwcm9jZXNzb3IKWyAgICAzLjQ4MzM0Ml0gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcCAo
c2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gMzM5
Mi4yOSBCb2dvTUlQUyAobHBqPTY3ODQ1ODQpClsgICAgMy40ODMzNDZdIHBpZF9tYXg6IGRl
ZmF1bHQ6IDMyNzY4IG1pbmltdW06IDMwMQpbICAgIDMuNDgzMzU2XSBBQ1BJOiBDb3JlIHJl
dmlzaW9uIDIwMTQwNDI0ClsgICAgMy40OTkzNjldIEFDUEk6IEFsbCBBQ1BJIFRhYmxlcyBz
dWNjZXNzZnVsbHkgYWNxdWlyZWQKWyAgICAzLjUwMDAxMF0gU2VjdXJpdHkgRnJhbWV3b3Jr
IGluaXRpYWxpemVkClsgICAgMy41MDAwMjBdIEFwcEFybW9yOiBBcHBBcm1vciBkaXNhYmxl
ZCBieSBib290IHRpbWUgcGFyYW1ldGVyClsgICAgMy41MDAwMjJdIFlhbWE6IGRpc2FibGVk
IGJ5IGRlZmF1bHQ7IGVuYWJsZSB3aXRoIHN5c2N0bCBrZXJuZWwueWFtYS4qClsgICAgMy41
MDEwMTFdIERlbnRyeSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUyNDI4OCAob3JkZXI6
IDEwLCA0MTk0MzA0IGJ5dGVzKQpbICAgIDMuNTAyMzg1XSBJbm9kZS1jYWNoZSBoYXNoIHRh
YmxlIGVudHJpZXM6IDI2MjE0NCAob3JkZXI6IDksIDIwOTcxNTIgYnl0ZXMpClsgICAgMy41
MDI4MTBdIE1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogODE5MiAob3JkZXI6IDQs
IDY1NTM2IGJ5dGVzKQpbICAgIDMuNTAyODI4XSBNb3VudHBvaW50LWNhY2hlIGhhc2ggdGFi
bGUgZW50cmllczogODE5MiAob3JkZXI6IDQsIDY1NTM2IGJ5dGVzKQpbICAgIDMuNTAzMTE0
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBtZW1vcnkKWyAgICAzLjUwMzExOV0gSW5p
dGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZGV2aWNlcwpbICAgIDMuNTAzMTI3XSBJbml0aWFs
aXppbmcgY2dyb3VwIHN1YnN5cyBmcmVlemVyClsgICAgMy41MDMxMzBdIEluaXRpYWxpemlu
ZyBjZ3JvdXAgc3Vic3lzIG5ldF9jbHMKWyAgICAzLjUwMzEzNF0gSW5pdGlhbGl6aW5nIGNn
cm91cCBzdWJzeXMgYmxraW8KWyAgICAzLjUwMzEzOF0gSW5pdGlhbGl6aW5nIGNncm91cCBz
dWJzeXMgcGVyZl9ldmVudApbICAgIDMuNTAzMTQxXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1
YnN5cyBuZXRfcHJpbwpbICAgIDMuNTAzMjE3XSBFTkVSR1lfUEVSRl9CSUFTOiBTZXQgdG8g
J25vcm1hbCcsIHdhcyAncGVyZm9ybWFuY2UnClsgICAgMy41MDMyMTddIEVORVJHWV9QRVJG
X0JJQVM6IFZpZXcgYW5kIHVwZGF0ZSB3aXRoIHg4Nl9lbmVyZ3lfcGVyZl9wb2xpY3koOCkK
WyAgICAzLjUwMzIyMl0gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6IDAKWyAgICAzLjUw
MzIyM10gQ1BVOiBQcm9jZXNzb3IgQ29yZSBJRDogMApbICAgIDMuNTA0Mzk3XSBtY2U6IENQ
VSBzdXBwb3J0cyAyIE1DRSBiYW5rcwpbICAgIDMuNTA0NDE4XSBMYXN0IGxldmVsIGlUTEIg
ZW50cmllczogNEtCIDEwMjQsIDJNQiAxMDI0LCA0TUIgMTAyNApbICAgIDMuNTA0NDE4XSBM
YXN0IGxldmVsIGRUTEIgZW50cmllczogNEtCIDEwMjQsIDJNQiAxMDI0LCA0TUIgMTAyNCwg
MUdCIDQKWyAgICAzLjUwNDQxOF0gdGxiX2ZsdXNoYWxsX3NoaWZ0OiA2ClsgICAgMy41MDQ1
MjJdIEZyZWVpbmcgU01QIGFsdGVybmF0aXZlcyBtZW1vcnk6IDIwSyAoZmZmZmZmZmY4MWEx
ODAwMCAtIGZmZmZmZmZmODFhMWQwMDApClsgICAgMy41MDU2ODJdIGZ0cmFjZTogYWxsb2Nh
dGluZyAyMTU0NCBlbnRyaWVzIGluIDg1IHBhZ2VzClsgICAgMy41MTU3OTRdIFBlcmZvcm1h
bmNlIEV2ZW50czogdW5zdXBwb3J0ZWQgcDYgQ1BVIG1vZGVsIDY5IG5vIFBNVSBkcml2ZXIs
IHNvZnR3YXJlIGV2ZW50cyBvbmx5LgpbICAgIDMuNTE3NTc1XSBOTUkgd2F0Y2hkb2c6IGRp
c2FibGVkIChjcHUwKTogaGFyZHdhcmUgZXZlbnRzIG5vdCBlbmFibGVkClsgICAgMy41MTc2
ODJdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMQpbICAgIDMuNTE5MTQxXSB4ODY6
IEJvb3RlZCB1cCAxIG5vZGUsIDIgQ1BVcwpbICAgIDMuNTE5MzQ3XSBkZXZ0bXBmczogaW5p
dGlhbGl6ZWQKWyAgICAzLjUyMzg2OF0gUE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJlZ2lv
biBbbWVtIDB4Yzg1MjIwMDAtMHhjODUyOGZmZl0gKDI4NjcyIGJ5dGVzKQpbICAgIDMuNTIz
ODcxXSBQTTogUmVnaXN0ZXJpbmcgQUNQSSBOVlMgcmVnaW9uIFttZW0gMHhkYmIyOTAwMC0w
eGRiYzkxZmZmXSAoMTQ3ODY1NiBieXRlcykKWyAgICAzLjUyNDkwNV0gcGluY3RybCBjb3Jl
OiBpbml0aWFsaXplZCBwaW5jdHJsIHN1YnN5c3RlbQpbICAgIDMuNTI1MDA3XSBORVQ6IFJl
Z2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE2ClsgICAgMy41MjUwMjFdIHhlbjpncmFudF90
YWJsZTogR3JhbnQgdGFibGVzIHVzaW5nIHZlcnNpb24gMSBsYXlvdXQKWyAgICAzLjUyNTAz
NV0gR3JhbnQgdGFibGUgaW5pdGlhbGl6ZWQKWyAgICAzLjUyNTM0MV0gQUNQSSBGQURUIGRl
Y2xhcmVzIHRoZSBzeXN0ZW0gZG9lc24ndCBzdXBwb3J0IFBDSWUgQVNQTSwgc28gZGlzYWJs
ZSBpdApbICAgIDMuNTI1MzQ0XSBBQ1BJOiBidXMgdHlwZSBQQ0kgcmVnaXN0ZXJlZApbICAg
IDMuNTI1MzQ2XSBhY3BpcGhwOiBBQ1BJIEhvdCBQbHVnIFBDSSBDb250cm9sbGVyIERyaXZl
ciB2ZXJzaW9uOiAwLjUKWyAgICAzLjUyNTU1N10gUENJOiBNTUNPTkZJRyBmb3IgZG9tYWlu
IDAwMDAgW2J1cyAwMC0zZl0gYXQgW21lbSAweGY4MDAwMDAwLTB4ZmJmZmZmZmZdIChiYXNl
IDB4ZjgwMDAwMDApClsgICAgMy41MjU1NjBdIFBDSTogTU1DT05GSUcgYXQgW21lbSAweGY4
MDAwMDAwLTB4ZmJmZmZmZmZdIHJlc2VydmVkIGluIEU4MjAKWyAgICAzLjUzNjE0NF0gUENJ
OiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgYmFzZSBhY2Nlc3MKWyAgICAzLjU0
ODUzNF0gQUNQSTogQWRkZWQgX09TSShNb2R1bGUgRGV2aWNlKQpbICAgIDMuNTQ4NTM4XSBB
Q1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBEZXZpY2UpClsgICAgMy41NDg1NDBdIEFDUEk6
IEFkZGVkIF9PU0koMy4wIF9TQ1AgRXh0ZW5zaW9ucykKWyAgICAzLjU0ODU0Ml0gQUNQSTog
QWRkZWQgX09TSShQcm9jZXNzb3IgQWdncmVnYXRvciBEZXZpY2UpClsgICAgMy41NTM2OTBd
IEFDUEk6IEV4ZWN1dGVkIDEgYmxvY2tzIG9mIG1vZHVsZS1sZXZlbCBleGVjdXRhYmxlIEFN
TCBjb2RlClsgICAgMy41Njc0MjVdIFtGaXJtd2FyZSBCdWddOiBBQ1BJOiBCSU9TIF9PU0ko
TGludXgpIHF1ZXJ5IGlnbm9yZWQKWyAgICAzLjU3OTczN10gQUNQSTogRHluYW1pYyBPRU0g
VGFibGUgTG9hZDoKWyAgICAzLjU3OTc0N10gQUNQSTogU1NEVCAweEZGRkY4ODAxMEExODE4
MDAgMDAwM0QzICh2MDEgUG1SZWYgIENwdTBDc3QgIDAwMDAzMDAxIElOVEwgMjAxMjA3MTEp
ClsgICAgMy41OTIxMTRdIEFDUEk6IER5bmFtaWMgT0VNIFRhYmxlIExvYWQ6ClsgICAgMy41
OTIxMjRdIEFDUEk6IFNTRFQgMHhGRkZGODgwMTBBMTcxMDAwIDAwMDVBQSAodjAxIFBtUmVm
ICBBcElzdCAgICAwMDAwMzAwMCBJTlRMIDIwMTIwNzExKQpbICAgIDMuNjA0MTIxXSBBQ1BJ
OiBEeW5hbWljIE9FTSBUYWJsZSBMb2FkOgpbICAgIDMuNjA0MTI5XSBBQ1BJOiBTU0RUIDB4
RkZGRjg4MDEwQTE4REEwMCAwMDAxMTkgKHYwMSBQbVJlZiAgQXBDc3QgICAgMDAwMDMwMDAg
SU5UTCAyMDEyMDcxMSkKWyAgICAzLjYxNjY1NV0gQUNQSTogSW50ZXJwcmV0ZXIgZW5hYmxl
ZApbICAgIDMuNjE2NjY2XSBBQ1BJIEV4Y2VwdGlvbjogQUVfTk9UX0ZPVU5ELCBXaGlsZSBl
dmFsdWF0aW5nIFNsZWVwIFN0YXRlIFtcX1MxX10gKDIwMTQwNDI0L2h3eGZhY2UtNTgwKQpb
ICAgIDMuNjE2Njc0XSBBQ1BJIEV4Y2VwdGlvbjogQUVfTk9UX0ZPVU5ELCBXaGlsZSBldmFs
dWF0aW5nIFNsZWVwIFN0YXRlIFtcX1MyX10gKDIwMTQwNDI0L2h3eGZhY2UtNTgwKQpbICAg
IDMuNjE2Njk2XSBBQ1BJOiAoc3VwcG9ydHMgUzAgUzMgUzQgUzUpClsgICAgMy42MTY2OThd
IEFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0IHJvdXRpbmcKWyAgICAzLjYxNjc0
NF0gUENJOiBVc2luZyBob3N0IGJyaWRnZSB3aW5kb3dzIGZyb20gQUNQSTsgaWYgbmVjZXNz
YXJ5LCB1c2UgInBjaT1ub2NycyIgYW5kIHJlcG9ydCBhIGJ1ZwpbICAgIDMuNjI5Mzc1XSBB
Q1BJOiBQb3dlciBSZXNvdXJjZSBbRk4wMF0gKG9mZikKWyAgICAzLjYyOTQ2OF0gQUNQSTog
UG93ZXIgUmVzb3VyY2UgW0ZOMDFdIChvZmYpClsgICAgMy42Mjk1NTddIEFDUEk6IFBvd2Vy
IFJlc291cmNlIFtGTjAyXSAob2ZmKQpbICAgIDMuNjI5NjQ0XSBBQ1BJOiBQb3dlciBSZXNv
dXJjZSBbRk4wM10gKG9mZikKWyAgICAzLjYyOTczNF0gQUNQSTogUG93ZXIgUmVzb3VyY2Ug
W0ZOMDRdIChvZmYpClsgICAgMy42MzA3MDJdIEFDUEk6IFBDSSBSb290IEJyaWRnZSBbUENJ
MF0gKGRvbWFpbiAwMDAwIFtidXMgMDAtM2VdKQpbICAgIDMuNjMwNzA5XSBhY3BpIFBOUDBB
MDg6MDA6IF9PU0M6IE9TIHN1cHBvcnRzIFtFeHRlbmRlZENvbmZpZyBBU1BNIENsb2NrUE0g
U2VnbWVudHMgTVNJXQpbICAgIDMuNjMxOTUwXSBhY3BpIFBOUDBBMDg6MDA6IF9PU0M6IHBs
YXRmb3JtIGRvZXMgbm90IHN1cHBvcnQgW1BDSWVIb3RwbHVnIFBNRV0KWyAgICAzLjYzMjEx
MV0gYWNwaSBQTlAwQTA4OjAwOiBfT1NDOiBPUyBub3cgY29udHJvbHMgW0FFUiBQQ0llQ2Fw
YWJpbGl0eV0KWyAgICAzLjYzMzAwOV0gUENJIGhvc3QgYnJpZGdlIHRvIGJ1cyAwMDAwOjAw
ClsgICAgMy42MzMwMTNdIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2J1
cyAwMC0zZV0KWyAgICAzLjYzMzAxNV0gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNv
dXJjZSBbaW8gIDB4MDAwMC0weDBjZjddClsgICAgMy42MzMwMTddIHBjaV9idXMgMDAwMDow
MDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDBkMDAtMHhmZmZmXQpbICAgIDMuNjMzMDE5
XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBhMDAwMC0w
eDAwMGJmZmZmXQpbICAgIDMuNjMzMDIxXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJl
c291cmNlIFttZW0gMHgwMDBkMDAwMC0weDAwMGQzZmZmXQpbICAgIDMuNjMzMDIzXSBwY2lf
YnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBkNDAwMC0weDAwMGQ3
ZmZmXQpbICAgIDMuNjMzMDI0XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNl
IFttZW0gMHgwMDBkODAwMC0weDAwMGRiZmZmXQpbICAgIDMuNjMzMDI2XSBwY2lfYnVzIDAw
MDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBkYzAwMC0weDAwMGRmZmZmXQpb
ICAgIDMuNjMzMDI4XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0g
MHgwMDBlMDAwMC0weDAwMGUzZmZmXQpbICAgIDMuNjMzMDMwXSBwY2lfYnVzIDAwMDA6MDA6
IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBlNDAwMC0weDAwMGU3ZmZmXQpbICAgIDMu
NjMzMDMxXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHhkZjIw
MDAwMC0weGZlYWZmZmZmXQpbICAgIDMuNjMzMDUxXSBwY2kgMDAwMDowMDowMC4wOiBbODA4
NjowYTA0XSB0eXBlIDAwIGNsYXNzIDB4MDYwMDAwClsgICAgMy42MzMyODldIHBjaSAwMDAw
OjAwOjAyLjA6IFs4MDg2OjBhMTZdIHR5cGUgMDAgY2xhc3MgMHgwMzAwMDAKWyAgICAzLjYz
MzMzM10gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDB4MTA6IFttZW0gMHhmNzgwMDAwMC0weGY3
YmZmZmZmIDY0Yml0XQpbICAgIDMuNjMzMzU2XSBwY2kgMDAwMDowMDowMi4wOiByZWcgMHgx
ODogW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmYgNjRiaXQgcHJlZl0KWyAgICAzLjYzMzM3
Ml0gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDB4MjA6IFtpbyAgMHhmMDAwLTB4ZjAzZl0KWyAg
ICAzLjYzMzU5MV0gcGNpIDAwMDA6MDA6MDMuMDogWzgwODY6MGEwY10gdHlwZSAwMCBjbGFz
cyAweDA0MDMwMApbICAgIDMuNjMzNjIxXSBwY2kgMDAwMDowMDowMy4wOiByZWcgMHgxMDog
W21lbSAweGY3ZDM0MDAwLTB4ZjdkMzdmZmYgNjRiaXRdClsgICAgMy42MzM5MDhdIHBjaSAw
MDAwOjAwOjE0LjA6IFs4MDg2OjljMzFdIHR5cGUgMDAgY2xhc3MgMHgwYzAzMzAKWyAgICAz
LjYzMzk1NV0gcGNpIDAwMDA6MDA6MTQuMDogcmVnIDB4MTA6IFttZW0gMHhmN2QyMDAwMC0w
eGY3ZDJmZmZmIDY0Yml0XQpbICAgIDMuNjM0MTA3XSBwY2kgMDAwMDowMDoxNC4wOiBQTUUj
IHN1cHBvcnRlZCBmcm9tIEQzaG90IEQzY29sZApbICAgIDMuNjM0MTY5XSBwY2kgMDAwMDow
MDoxNC4wOiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkKWyAgICAzLjYzNDI0OV0g
cGNpIDAwMDA6MDA6MTYuMDogWzgwODY6OWMzYV0gdHlwZSAwMCBjbGFzcyAweDA3ODAwMApb
ICAgIDMuNjM0Mjk3XSBwY2kgMDAwMDowMDoxNi4wOiByZWcgMHgxMDogW21lbSAweGY3ZDNl
MDAwLTB4ZjdkM2UwMWYgNjRiaXRdClsgICAgMy42MzQ0NTldIHBjaSAwMDAwOjAwOjE2LjA6
IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgMy42MzQ2MTNdIHBj
aSAwMDAwOjAwOjE5LjA6IFs4MDg2OjE1NTldIHR5cGUgMDAgY2xhc3MgMHgwMjAwMDAKWyAg
ICAzLjYzNDY1NF0gcGNpIDAwMDA6MDA6MTkuMDogcmVnIDB4MTA6IFttZW0gMHhmN2QwMDAw
MC0weGY3ZDFmZmZmXQpbICAgIDMuNjM0NjcyXSBwY2kgMDAwMDowMDoxOS4wOiByZWcgMHgx
NDogW21lbSAweGY3ZDNjMDAwLTB4ZjdkM2NmZmZdClsgICAgMy42MzQ2OTBdIHBjaSAwMDAw
OjAwOjE5LjA6IHJlZyAweDE4OiBbaW8gIDB4ZjA4MC0weGYwOWZdClsgICAgMy42MzQ4Mzld
IHBjaSAwMDAwOjAwOjE5LjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xk
ClsgICAgMy42MzQ5MDNdIHBjaSAwMDAwOjAwOjE5LjA6IFN5c3RlbSB3YWtldXAgZGlzYWJs
ZWQgYnkgQUNQSQpbICAgIDMuNjM0OTg3XSBwY2kgMDAwMDowMDoxYi4wOiBbODA4Njo5YzIw
XSB0eXBlIDAwIGNsYXNzIDB4MDQwMzAwClsgICAgMy42MzUwMjJdIHBjaSAwMDAwOjAwOjFi
LjA6IHJlZyAweDEwOiBbbWVtIDB4ZjdkMzAwMDAtMHhmN2QzM2ZmZiA2NGJpdF0KWyAgICAz
LjYzNTE4OV0gcGNpIDAwMDA6MDA6MWIuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hv
dCBEM2NvbGQKWyAgICAzLjYzNTI1NF0gcGNpIDAwMDA6MDA6MWIuMDogU3lzdGVtIHdha2V1
cCBkaXNhYmxlZCBieSBBQ1BJClsgICAgMy42MzUzMzNdIHBjaSAwMDAwOjAwOjFjLjA6IFs4
MDg2OjljMTBdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDAKWyAgICAzLjYzNTUxM10gcGNpIDAw
MDA6MDA6MWMuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICAz
LjYzNTU3M10gcGNpIDAwMDA6MDA6MWMuMDogRW5hYmxpbmcgTVBDIElSQk5DRQpbICAgIDMu
NjM1NTc3XSBwY2kgMDAwMDowMDoxYy4wOiBJbnRlbCBQQ0ggcm9vdCBwb3J0IEFDUyB3b3Jr
YXJvdW5kIGVuYWJsZWQKWyAgICAzLjYzNTYyMF0gcGNpIDAwMDA6MDA6MWMuMDogU3lzdGVt
IHdha2V1cCBkaXNhYmxlZCBieSBBQ1BJClsgICAgMy42MzU3MTFdIHBjaSAwMDAwOjAwOjFj
LjM6IFs4MDg2OjljMTZdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDAKWyAgICAzLjYzNTg5NV0g
cGNpIDAwMDA6MDA6MWMuMzogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQK
WyAgICAzLjYzNTk1MF0gcGNpIDAwMDA6MDA6MWMuMzogRW5hYmxpbmcgTVBDIElSQk5DRQpb
ICAgIDMuNjM1OTU0XSBwY2kgMDAwMDowMDoxYy4zOiBJbnRlbCBQQ0ggcm9vdCBwb3J0IEFD
UyB3b3JrYXJvdW5kIGVuYWJsZWQKWyAgICAzLjYzNTk5N10gcGNpIDAwMDA6MDA6MWMuMzog
U3lzdGVtIHdha2V1cCBkaXNhYmxlZCBieSBBQ1BJClsgICAgMy42MzYwOTZdIHBjaSAwMDAw
OjAwOjFkLjA6IFs4MDg2OjljMjZdIHR5cGUgMDAgY2xhc3MgMHgwYzAzMjAKWyAgICAzLjYz
NjE0MV0gcGNpIDAwMDA6MDA6MWQuMDogcmVnIDB4MTA6IFttZW0gMHhmN2QzYjAwMC0weGY3
ZDNiM2ZmXQpbICAgIDMuNjM2MzU2XSBwY2kgMDAwMDowMDoxZC4wOiBQTUUjIHN1cHBvcnRl
ZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDMuNjM2NDQ1XSBwY2kgMDAwMDowMDoxZC4w
OiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkKWyAgICAzLjYzNjUyNV0gcGNpIDAw
MDA6MDA6MWYuMDogWzgwODY6OWM0M10gdHlwZSAwMCBjbGFzcyAweDA2MDEwMApbICAgIDMu
NjM2ODgyXSBwY2kgMDAwMDowMDoxZi4yOiBbODA4Njo5YzAzXSB0eXBlIDAwIGNsYXNzIDB4
MDEwNjAxClsgICAgMy42MzY5MjRdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAweDEwOiBbaW8g
IDB4ZjBkMC0weGYwZDddClsgICAgMy42MzY5NDFdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAw
eDE0OiBbaW8gIDB4ZjBjMC0weGYwYzNdClsgICAgMy42MzY5NTldIHBjaSAwMDAwOjAwOjFm
LjI6IHJlZyAweDE4OiBbaW8gIDB4ZjBiMC0weGYwYjddClsgICAgMy42MzY5NzZdIHBjaSAw
MDAwOjAwOjFmLjI6IHJlZyAweDFjOiBbaW8gIDB4ZjBhMC0weGYwYTNdClsgICAgMy42MzY5
OTNdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAweDIwOiBbaW8gIDB4ZjA2MC0weGYwN2ZdClsg
ICAgMy42MzcwMTFdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAweDI0OiBbbWVtIDB4ZjdkM2Ew
MDAtMHhmN2QzYTdmZl0KWyAgICAzLjYzNzExMF0gcGNpIDAwMDA6MDA6MWYuMjogUE1FIyBz
dXBwb3J0ZWQgZnJvbSBEM2hvdApbICAgIDMuNjM3MjMzXSBwY2kgMDAwMDowMDoxZi4zOiBb
ODA4Njo5YzIyXSB0eXBlIDAwIGNsYXNzIDB4MGMwNTAwClsgICAgMy42MzcyNjhdIHBjaSAw
MDAwOjAwOjFmLjM6IHJlZyAweDEwOiBbbWVtIDB4ZjdkMzkwMDAtMHhmN2QzOTBmZiA2NGJp
dF0KWyAgICAzLjYzNzMxOF0gcGNpIDAwMDA6MDA6MWYuMzogcmVnIDB4MjA6IFtpbyAgMHhm
MDQwLTB4ZjA1Zl0KWyAgICAzLjYzNzYxMF0gYWNwaXBocDogU2xvdCBbMV0gcmVnaXN0ZXJl
ZApbICAgIDMuNjM3NjI2XSBwY2kgMDAwMDowMDoxYy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMg
MDFdClsgICAgMy42Mzc4NDRdIHBjaSAwMDAwOjAyOjAwLjA6IFs4MDg2OjA4ODddIHR5cGUg
MDAgY2xhc3MgMHgwMjgwMDAKWyAgICAzLjYzNzkwMl0gcGNpIDAwMDA6MDI6MDAuMDogcmVn
IDB4MTA6IFttZW0gMHhmN2MwMDAwMC0weGY3YzAxZmZmIDY0Yml0XQpbICAgIDMuNjM4MTcy
XSBwY2kgMDAwMDowMjowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29s
ZApbICAgIDMuNjM4MjI4XSBwY2kgMDAwMDowMjowMC4wOiBTeXN0ZW0gd2FrZXVwIGRpc2Fi
bGVkIGJ5IEFDUEkKWyAgICAzLjY0ODQ0Nl0gcGNpIDAwMDA6MDA6MWMuMzogUENJIGJyaWRn
ZSB0byBbYnVzIDAyXQpbICAgIDMuNjQ4NDYzXSBwY2kgMDAwMDowMDoxYy4zOiAgIGJyaWRn
ZSB3aW5kb3cgW21lbSAweGY3YzAwMDAwLTB4ZjdjZmZmZmZdClsgICAgMy42NDg1MzNdIGFj
cGkgUE5QMEEwODowMDogRGlzYWJsaW5nIEFTUE0gKEZBRFQgaW5kaWNhdGVzIGl0IGlzIHVu
c3VwcG9ydGVkKQpbICAgIDMuNjQ5NzU2XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xO
S0FdIChJUlFzIDMgNCA1IDYgMTAgKjExIDEyIDE0IDE1KQpbICAgIDMuNjQ5ODE5XSBBQ1BJ
OiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0JdIChJUlFzIDMgNCA1IDYgMTAgMTEgMTIgMTQg
MTUpICowLCBkaXNhYmxlZC4KWyAgICAzLjY0OTg3OV0gQUNQSTogUENJIEludGVycnVwdCBM
aW5rIFtMTktDXSAoSVJRcyAzIDQgNSA2ICoxMCAxMSAxMiAxNCAxNSkKWyAgICAzLjY0OTkz
OF0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyAzIDQgNSA2ICoxMCAx
MSAxMiAxNCAxNSkKWyAgICAzLjY0OTk5Nl0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtM
TktFXSAoSVJRcyAzIDQgKjUgNiAxMCAxMSAxMiAxNCAxNSkKWyAgICAzLjY1MDA1OF0gQUNQ
STogUENJIEludGVycnVwdCBMaW5rIFtMTktGXSAoSVJRcyAzIDQgNSA2IDEwIDExIDEyIDE0
IDE1KSAqMCwgZGlzYWJsZWQuClsgICAgMy42NTAxMTddIEFDUEk6IFBDSSBJbnRlcnJ1cHQg
TGluayBbTE5LR10gKElSUXMgKjMgNCA1IDYgMTAgMTEgMTIgMTQgMTUpClsgICAgMy42NTAx
NzRdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LSF0gKElSUXMgMyA0IDUgNiAxMCAq
MTEgMTIgMTQgMTUpClsgICAgMy42NTA1NTRdIEFDUEk6IEVuYWJsZWQgNSBHUEVzIGluIGJs
b2NrIDAwIHRvIDdGClsgICAgMy42NTA2MjJdIHhlbjpiYWxsb29uOiBJbml0aWFsaXNpbmcg
YmFsbG9vbiBkcml2ZXIKWyAgICAzLjY1MTQyNl0geGVuX2JhbGxvb246IEluaXRpYWxpc2lu
ZyBiYWxsb29uIGRyaXZlcgpbICAgIDMuNjUxNTU4XSB2Z2FhcmI6IHNldHRpbmcgYXMgYm9v
dCBkZXZpY2U6IFBDSTowMDAwOjAwOjAyLjAKWyAgICAzLjY1MTU2MF0gdmdhYXJiOiBkZXZp
Y2UgYWRkZWQ6IFBDSTowMDAwOjAwOjAyLjAsZGVjb2Rlcz1pbyttZW0sb3ducz1pbyttZW0s
bG9ja3M9bm9uZQpbICAgIDMuNjUxNTY0XSB2Z2FhcmI6IGxvYWRlZApbICAgIDMuNjUxNTY1
XSB2Z2FhcmI6IGJyaWRnZSBjb250cm9sIHBvc3NpYmxlIDAwMDA6MDA6MDIuMApbICAgIDMu
NjUxNjM3XSBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nClsgICAgMy42NTU3ODNd
IFBDSTogcGNpX2NhY2hlX2xpbmVfc2l6ZSBzZXQgdG8gNjQgYnl0ZXMKWyAgICAzLjY1NTg2
Ml0gZTgyMDogcmVzZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHgwMDA5ZDAwMC0weDAwMDlmZmZm
XQpbICAgIDMuNjU1ODY0XSBlODIwOiByZXNlcnZlIFJBTSBidWZmZXIgW21lbSAweGM4NTIy
MDAwLTB4Y2JmZmZmZmZdClsgICAgMy42NTU4NjVdIGU4MjA6IHJlc2VydmUgUkFNIGJ1ZmZl
ciBbbWVtIDB4ZGJhODUwMDAtMHhkYmZmZmZmZl0KWyAgICAzLjY1NTg2N10gZTgyMDogcmVz
ZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHgxMWZlMDAwMDAtMHgxMWZmZmZmZmZdClsgICAgMy42
NTYwNjddIFN3aXRjaGVkIHRvIGNsb2Nrc291cmNlIHhlbgpbICAgIDMuNjYxOTQ0XSBwbnA6
IFBuUCBBQ1BJIGluaXQKWyAgICAzLjY2MTk2Ml0gQUNQSTogYnVzIHR5cGUgUE5QIHJlZ2lz
dGVyZWQKWyAgICAzLjY2MjA1Nl0gc3lzdGVtIDAwOjAwOiBbbWVtIDB4ZmVkNDAwMDAtMHhm
ZWQ0NGZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjA2MF0gc3lzdGVtIDAwOjAw
OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMSAoYWN0aXZlKQpbICAg
IDMuNjYyMjcwXSBzeXN0ZW0gMDA6MDE6IFtpbyAgMHgwNjgwLTB4MDY5Zl0gaGFzIGJlZW4g
cmVzZXJ2ZWQKWyAgICAzLjY2MjI3M10gc3lzdGVtIDAwOjAxOiBbaW8gIDB4ZmZmZl0gaGFz
IGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjI3NV0gc3lzdGVtIDAwOjAxOiBbaW8gIDB4ZmZm
Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjI3N10gc3lzdGVtIDAwOjAxOiBbaW8g
IDB4ZmZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjI4MF0gc3lzdGVtIDAwOjAx
OiBbaW8gIDB4MWMwMC0weDFjZmVdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42NjIyODJd
IHN5c3RlbSAwMDowMTogW2lvICAweDFkMDAtMHgxZGZlXSBoYXMgYmVlbiByZXNlcnZlZApb
ICAgIDMuNjYyMjg0XSBzeXN0ZW0gMDA6MDE6IFtpbyAgMHgxZTAwLTB4MWVmZV0gaGFzIGJl
ZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjI4Nl0gc3lzdGVtIDAwOjAxOiBbaW8gIDB4MWYwMC0w
eDFmZmVdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42NjIyODhdIHN5c3RlbSAwMDowMTog
W2lvICAweDE4MDAtMHgxOGZlXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICAzLjY2MjI5
MF0gc3lzdGVtIDAwOjAxOiBbaW8gIDB4MTY0ZS0weDE2NGZdIGhhcyBiZWVuIHJlc2VydmVk
ClsgICAgMy42NjIyOTNdIHN5c3RlbSAwMDowMTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmlj
ZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAzLjY2MjMwM10geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgOCB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMApbICAgIDMuNjYyMzUwXSBwbnAgMDA6
MDI6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYjAwIChhY3RpdmUpClsg
ICAgMy42NjI0MDddIHN5c3RlbSAwMDowMzogW2lvICAweDE4NTQtMHgxODU3XSBoYXMgYmVl
biByZXNlcnZlZApbICAgIDMuNjYyNDA5XSBzeXN0ZW0gMDA6MDM6IFBsdWcgYW5kIFBsYXkg
QUNQSSBkZXZpY2UsIElEcyBJTlQzZjBkIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAzLjY2MjUz
MV0gc3lzdGVtIDAwOjA0OiBbaW8gIDB4MGEwMC0weDBhMWZdIGhhcyBiZWVuIHJlc2VydmVk
ClsgICAgMy42NjI1MzNdIHN5c3RlbSAwMDowNDogW2lvICAweDBhMDAtMHgwYTBmXSBoYXMg
YmVlbiByZXNlcnZlZApbICAgIDMuNjYyNTM2XSBzeXN0ZW0gMDA6MDQ6IFBsdWcgYW5kIFBs
YXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3RpdmUpClsgICAgMy42NjI2NjldIHBu
cCAwMDowNTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIE5UTjA1MzAgKGRpc2Fi
bGVkKQpbICAgIDMuNjYyNzI0XSBzeXN0ZW0gMDA6MDY6IFtpbyAgMHgwNGQwLTB4MDRkMV0g
aGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjcyN10gc3lzdGVtIDAwOjA2OiBQbHVnIGFu
ZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMiAoYWN0aXZlKQpbICAgIDMuNjgwMjg1
XSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEwMjAwMC0weGZlMTAyZmZmXSBoYXMgYmVlbiBy
ZXNlcnZlZApbICAgIDMuNjgwMjkwXSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEwNDAwMC0w
eGZlMTA0ZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwMjkzXSBzeXN0ZW0gMDA6
MDc6IFttZW0gMHhmZTEwNjAwMC0weGZlMTA2ZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAg
IDMuNjgwMjk1XSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEwODAwMC0weGZlMTA4ZmZmXSBo
YXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwMjk3XSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhm
ZTEwYTAwMC0weGZlMTBhZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwMjk5XSBz
eXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEwYzAwMC0weGZlMTBjZmZmXSBoYXMgYmVlbiByZXNl
cnZlZApbICAgIDMuNjgwMzAxXSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEwZTAwMC0weGZl
MTBlZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwMzAzXSBzeXN0ZW0gMDA6MDc6
IFttZW0gMHhmZTExMjAwMC0weGZlMTEyZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMu
NjgwMzA2XSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTExMTAwMC0weGZlMTExMDA3XSBoYXMg
YmVlbiByZXNlcnZlZApbICAgIDMuNjgwMzA4XSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEx
MTAxNC0weGZlMTExZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwMzEyXSBzeXN0
ZW0gMDA6MDc6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3Rp
dmUpClsgICAgMy42ODA3NzBdIHN5c3RlbSAwMDowODogW21lbSAweGZlZDFjMDAwLTB4ZmVk
MWZmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42ODA3NzJdIHN5c3RlbSAwMDowODog
W21lbSAweGZlZDEwMDAwLTB4ZmVkMTdmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42
ODA3NzRdIHN5c3RlbSAwMDowODogW21lbSAweGZlZDE4MDAwLTB4ZmVkMThmZmZdIGhhcyBi
ZWVuIHJlc2VydmVkClsgICAgMy42ODA3NzZdIHN5c3RlbSAwMDowODogW21lbSAweGZlZDE5
MDAwLTB4ZmVkMTlmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42ODA3NzldIHN5c3Rl
bSAwMDowODogW21lbSAweGY4MDAwMDAwLTB4ZmJmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVk
ClsgICAgMy42ODA3ODFdIHN5c3RlbSAwMDowODogW21lbSAweGZlZDIwMDAwLTB4ZmVkM2Zm
ZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42ODA3ODNdIHN5c3RlbSAwMDowODogW21l
bSAweGZlZDkwMDAwLTB4ZmVkOTNmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDMu
NjgwNzg1XSBzeXN0ZW0gMDA6MDg6IFttZW0gMHhmZWQ0NTAwMC0weGZlZDhmZmZmXSBoYXMg
YmVlbiByZXNlcnZlZApbICAgIDMuNjgwNzg3XSBzeXN0ZW0gMDA6MDg6IFttZW0gMHhmZjAw
MDAwMC0weGZmZmZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwNzkwXSBzeXN0
ZW0gMDA6MDg6IFttZW0gMHhmZWUwMDAwMC0weGZlZWZmZmZmXSBoYXMgYmVlbiByZXNlcnZl
ZApbICAgIDMuNjgwNzkyXSBzeXN0ZW0gMDA6MDg6IFttZW0gMHhmN2ZkZjAwMC0weGY3ZmRm
ZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwNzk0XSBzeXN0ZW0gMDA6MDg6IFtt
ZW0gMHhmN2ZlMDAwMC0weGY3ZmVmZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgw
Nzk2XSBzeXN0ZW0gMDA6MDg6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAw
YzAyIChhY3RpdmUpClsgICAgMy42ODEwNjNdIHBucDogUG5QIEFDUEk6IGZvdW5kIDkgZGV2
aWNlcwpbICAgIDMuNjgxMDY1XSBBQ1BJOiBidXMgdHlwZSBQTlAgdW5yZWdpc3RlcmVkClsg
ICAgMy42OTE5MjRdIFBNLVRpbWVyIGZhaWxlZCBjb25zaXN0ZW5jeSBjaGVjayAgKDB4ZmZm
ZmZmKSAtIGFib3J0aW5nLgpbICAgIDMuNjkxOTY4XSBwY2kgMDAwMDowMDoxYy4wOiBQQ0kg
YnJpZGdlIHRvIFtidXMgMDFdClsgICAgMy42OTE5OTJdIHBjaSAwMDAwOjAwOjFjLjM6IFBD
SSBicmlkZ2UgdG8gW2J1cyAwMl0KWyAgICAzLjY5MjAwMV0gcGNpIDAwMDA6MDA6MWMuMzog
ICBicmlkZ2Ugd2luZG93IFttZW0gMHhmN2MwMDAwMC0weGY3Y2ZmZmZmXQpbICAgIDMuNjky
MDE4XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDQgW2lvICAweDAwMDAtMHgwY2Y3XQpb
ICAgIDMuNjkyMDIwXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDUgW2lvICAweDBkMDAt
MHhmZmZmXQpbICAgIDMuNjkyMDIyXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDYgW21l
bSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsgICAgMy42OTIwMjRdIHBjaV9idXMgMDAwMDow
MDogcmVzb3VyY2UgNyBbbWVtIDB4MDAwZDAwMDAtMHgwMDBkM2ZmZl0KWyAgICAzLjY5MjAy
Nl0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA4IFttZW0gMHgwMDBkNDAwMC0weDAwMGQ3
ZmZmXQpbICAgIDMuNjkyMDI3XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDkgW21lbSAw
eDAwMGQ4MDAwLTB4MDAwZGJmZmZdClsgICAgMy42OTIwMjldIHBjaV9idXMgMDAwMDowMDog
cmVzb3VyY2UgMTAgW21lbSAweDAwMGRjMDAwLTB4MDAwZGZmZmZdClsgICAgMy42OTIwMzFd
IHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgMTEgW21lbSAweDAwMGUwMDAwLTB4MDAwZTNm
ZmZdClsgICAgMy42OTIwMzNdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgMTIgW21lbSAw
eDAwMGU0MDAwLTB4MDAwZTdmZmZdClsgICAgMy42OTIwMzRdIHBjaV9idXMgMDAwMDowMDog
cmVzb3VyY2UgMTMgW21lbSAweGRmMjAwMDAwLTB4ZmVhZmZmZmZdClsgICAgMy42OTIwMzdd
IHBjaV9idXMgMDAwMDowMjogcmVzb3VyY2UgMSBbbWVtIDB4ZjdjMDAwMDAtMHhmN2NmZmZm
Zl0KWyAgICAzLjY5MjEzMF0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAyClsg
ICAgMy42OTI0NjFdIFRDUCBlc3RhYmxpc2hlZCBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4
IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQpbICAgIDMuNjkyNjIzXSBUQ1AgYmluZCBoYXNo
IHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjogNywgNTI0Mjg4IGJ5dGVzKQpbICAgIDMu
NjkyNjg2XSBUQ1A6IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDMyNzY4
IGJpbmQgMzI3NjgpClsgICAgMy42OTI3MDZdIFRDUDogcmVubyByZWdpc3RlcmVkClsgICAg
My42OTI3MjZdIFVEUCBoYXNoIHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiA0LCA2NTUz
NiBieXRlcykKWyAgICAzLjY5Mjc1NF0gVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAy
MDQ4IChvcmRlcjogNCwgNjU1MzYgYnl0ZXMpClsgICAgMy42OTI4MzNdIE5FVDogUmVnaXN0
ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQpbICAgIDMuNjkyODU5XSBwY2kgMDAwMDowMDowMi4w
OiBWaWRlbyBkZXZpY2Ugd2l0aCBzaGFkb3dlZCBST00KWyAgICAzLjY5Mjk1OF0geGVuOiBy
ZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICAzLjY5Mjk3
MV0geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9MTYgKGdzaT0xNikKWyAgICAzLjY5MzIzNl0g
eGVuOiByZWdpc3RlcmluZyBnc2kgMjMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICAz
LjY5MzI0M10geGVuOiAtLT4gcGlycT0yMyAtPiBpcnE9MjMgKGdzaT0yMykKWyAgICAzLjcx
MjIyNF0gUENJOiBDTFMgNjQgYnl0ZXMsIGRlZmF1bHQgNjQKWyAgICAzLjcxMjI3M10gVW5w
YWNraW5nIGluaXRyYW1mcy4uLgpbICAgIDMuNzU3MDU4XSBGcmVlaW5nIGluaXRyZCBtZW1v
cnk6IDQzNjI0SyAoZmZmZjg4MDAwMWYxNTAwMCAtIGZmZmY4ODAwMDQ5YWYwMDApClsgICAg
My43NTczMThdIFJBUEwgUE1VIGRldGVjdGVkLCBodyB1bml0IDJeLTE0IEpvdWxlcywgQVBJ
IHVuaXQgaXMgMl4tMzIgSm91bGVzLCA0IGZpeGVkIGNvdW50ZXJzIDY1NTM2MCBtcyBvdmZs
IHRpbWVyClsgICAgMy43NTczNzRdIG1pY3JvY29kZTogQ1BVMCBzaWc9MHg0MDY1MSwgcGY9
MHg0MCwgcmV2aXNpb249MHgxNgpbICAgIDMuNzU3Mzg2XSBtaWNyb2NvZGU6IENQVTEgc2ln
PTB4NDA2NTEsIHBmPTB4NDAsIHJldmlzaW9uPTB4MTYKWyAgICAzLjc1NzQ3MF0gbWljcm9j
b2RlOiBNaWNyb2NvZGUgVXBkYXRlIERyaXZlcjogdjIuMDAgPHRpZ3JhbkBhaXZhemlhbi5m
c25ldC5jby51az4sIFBldGVyIE9ydWJhClsgICAgMy43NTc4MTldIGZ1dGV4IGhhc2ggdGFi
bGUgZW50cmllczogNTEyIChvcmRlcjogMywgMzI3NjggYnl0ZXMpClsgICAgMy43NTc4NzFd
IGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0bGluayBzdWJzeXMgKGRpc2FibGVkKQpbICAgIDMu
NzU3ODkwXSBhdWRpdDogdHlwZT0yMDAwIGF1ZGl0KDE0MTYzMTI3NzIuMTAxOjEpOiBpbml0
aWFsaXplZApbICAgIDMuNzU4Mjg0XSBIdWdlVExCIHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNp
emUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcwpbICAgIDMuNzU4MzE0XSB6YnVkOiBsb2FkZWQK
WyAgICAzLjc1ODU3NV0gVkZTOiBEaXNrIHF1b3RhcyBkcXVvdF82LjUuMgpbICAgIDMuNzU4
NTk4XSBEcXVvdC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMiAob3JkZXIgMCwgNDA5
NiBieXRlcykKWyAgICAzLjc1ODY2M10gbXNnbW5pIGhhcyBiZWVuIHNldCB0byA3MzcxClsg
ICAgMy43NTkxOTFdIGFsZzogTm8gdGVzdCBmb3Igc3Rkcm5nIChrcm5nKQpbICAgIDMuNzU5
MjM2XSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40
IGxvYWRlZCAobWFqb3IgMjUyKQpbICAgIDMuNzU5MzEyXSBpbyBzY2hlZHVsZXIgbm9vcCBy
ZWdpc3RlcmVkClsgICAgMy43NTkzMTddIGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdpc3Rl
cmVkClsgICAgMy43NTkzNjNdIGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVs
dCkKWyAgICAzLjc1OTU1NF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDEKWyAgICAzLjc1OTU1OV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNgpb
ICAgIDMuNzU5NzIyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9s
YXJpdHkgMQpbICAgIDMuNzU5NzM2XSB4ZW46IC0tPiBwaXJxPTE5IC0+IGlycT0xOSAoZ3Np
PTE5KQpbICAgIDMuNzU5ODg3XSBwY2lfaG90cGx1ZzogUENJIEhvdCBQbHVnIFBDSSBDb3Jl
IHZlcnNpb246IDAuNQpbICAgIDMuNzU5OTA5XSBwY2llaHA6IFBDSSBFeHByZXNzIEhvdCBQ
bHVnIENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246IDAuNApbICAgIDMuNzU5OTYyXSBpbnRl
bF9pZGxlOiBNV0FJVCBzdWJzdGF0ZXM6IDB4MTExNDIxMjAKWyAgICAzLjc1OTk2M10gaW50
ZWxfaWRsZTogdjAuNCBtb2RlbCAweDQ1ClsgICAgMy43NTk5NjVdIGludGVsX2lkbGU6IGxh
cGljX3RpbWVyX3JlbGlhYmxlX3N0YXRlcyAweGZmZmZmZmZmClsgICAgMy43NTk5ODddIGlu
dGVsX2lkbGU6IGludGVsX2lkbGUgeWllbGRpbmcgdG8gbm9uZQpbICAgIDMuNzYwMDM4XSBH
SEVTOiBIRVNUIGlzIG5vdCBlbmFibGVkIQpbICAgIDMuNzYwNjk0XSBTZXJpYWw6IDgyNTAv
MTY1NTAgZHJpdmVyLCA0IHBvcnRzLCBJUlEgc2hhcmluZyBlbmFibGVkClsgICAgMy43ODE1
NzhdIHNlcmlhbDgyNTA6IHR0eVMwIGF0IEkvTyAweDNmOCAoaXJxID0gNCwgYmFzZV9iYXVk
ID0gMTE1MjAwKSBpcyBhIDE2NTUwQQpbICAgIDMuNzgyMTE0XSBocGV0X2FjcGlfYWRkOiBu
byBhZGRyZXNzIG9yIGlycXMgaW4gX0NSUwpbICAgIDMuNzgyMTQ5XSBMaW51eCBhZ3BnYXJ0
IGludGVyZmFjZSB2MC4xMDMKWyAgICAzLjc4MjI3MV0gaTgwNDI6IFBOUDogTm8gUFMvMiBj
b250cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5LgpbICAgIDQuODM1MDc3
XSBpODA0MjogTm8gY29udHJvbGxlciBmb3VuZApbICAgIDQuODM1MjQ4XSBtb3VzZWRldjog
UFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWljZQpbICAgIDQuODM1MzAyXSBy
dGNfY21vcyAwMDowMjogUlRDIGNhbiB3YWtlIGZyb20gUzQKWyAgICA0LjgzNTUwMl0gcnRj
X2Ntb3MgMDA6MDI6IHJ0YyBjb3JlOiByZWdpc3RlcmVkIHJ0Y19jbW9zIGFzIHJ0YzAKWyAg
ICA0LjgzNTU3MV0gcnRjX2Ntb3MgMDA6MDI6IGFsYXJtcyB1cCB0byBvbmUgbW9udGgsIHkz
aywgMjQyIGJ5dGVzIG52cmFtClsgICAgNC44MzU1ODddIGxlZHRyaWctY3B1OiByZWdpc3Rl
cmVkIHRvIGluZGljYXRlIGFjdGl2aXR5IG9uIENQVXMKWyAgICA0LjgzNjAzM10gQU1EIElP
TU1VdjIgZHJpdmVyIGJ5IEpvZXJnIFJvZWRlbCA8am9lcmcucm9lZGVsQGFtZC5jb20+Clsg
ICAgNC44MzYwMzRdIEFNRCBJT01NVXYyIGZ1bmN0aW9uYWxpdHkgbm90IGF2YWlsYWJsZSBv
biB0aGlzIHN5c3RlbQpbICAgIDQuODM2MTY1XSBUQ1A6IGN1YmljIHJlZ2lzdGVyZWQKWyAg
ICA0LjgzNjIzM10gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMApbICAgIDQu
ODM2NDY5XSBtaXA2OiBNb2JpbGUgSVB2NgpbICAgIDQuODM2NDcyXSBORVQ6IFJlZ2lzdGVy
ZWQgcHJvdG9jb2wgZmFtaWx5IDE3ClsgICAgNC44MzY0NzhdIG1wbHNfZ3NvOiBNUExTIEdT
TyBzdXBwb3J0ClsgICAgNC44MzY4MzhdIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24g
MQpbICAgIDQuODM3NDU2XSBydGNfY21vcyAwMDowMjogc2V0dGluZyBzeXN0ZW0gY2xvY2sg
dG8gMjAxNC0xMS0xOCAxMjoxMjo1MiBVVEMgKDE0MTYzMTI3NzIpClsgICAgNC44Mzc1NDZd
IFBNOiBIaWJlcm5hdGlvbiBpbWFnZSBub3QgcHJlc2VudCBvciBjb3VsZCBub3QgYmUgbG9h
ZGVkLgpbICAgIDQuODM4MTMyXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAxMjA0
SyAoZmZmZmZmZmY4MThlYjAwMCAtIGZmZmZmZmZmODFhMTgwMDApClsgICAgNC44MzgxMzRd
IFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogODE5MmsKWyAg
ICA0Ljg0MTc1OV0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogNzA4SyAoZmZmZjg4
MDAwMTU0ZjAwMCAtIGZmZmY4ODAwMDE2MDAwMDApClsgICAgNC44NDE4OTldIEZyZWVpbmcg
dW51c2VkIGtlcm5lbCBtZW1vcnk6IDIyNEsgKGZmZmY4ODAwMDE3YzgwMDAgLSBmZmZmODgw
MDAxODAwMDAwKQpbICAgIDQuODc1MTUxXSB1ZGV2ZFs2MV06IHN0YXJ0aW5nIHZlcnNpb24g
MTc1ClsgICAgNC45MjMzNTJdIHBwc19jb3JlOiBMaW51eFBQUyBBUEkgdmVyLiAxIHJlZ2lz
dGVyZWQKWyAgICA0LjkyMzM1Nl0gcHBzX2NvcmU6IFNvZnR3YXJlIHZlci4gNS4zLjYgLSBD
b3B5cmlnaHQgMjAwNS0yMDA3IFJvZG9sZm8gR2lvbWV0dGkgPGdpb21ldHRpQGxpbnV4Lml0
PgpbICAgIDQuOTI0MDYwXSBQVFAgY2xvY2sgc3VwcG9ydCByZWdpc3RlcmVkClsgICAgNC45
NDI3NjFdIGUxMDAwZTogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBEcml2ZXIgLSAyLjMu
Mi1rClsgICAgNC45NDI3NjVdIGUxMDAwZTogQ29weXJpZ2h0KGMpIDE5OTkgLSAyMDE0IElu
dGVsIENvcnBvcmF0aW9uLgpbICAgIDQuOTQyOTM3XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAy
MCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuOTQyOTU2XSB4ZW46IC0tPiBwaXJx
PTIwIC0+IGlycT0yMCAoZ3NpPTIwKQpbICAgIDQuOTQzMTMxXSBlMTAwMGUgMDAwMDowMDox
OS4wOiBJbnRlcnJ1cHQgVGhyb3R0bGluZyBSYXRlIChpbnRzL3NlYykgc2V0IHRvIGR5bmFt
aWMgY29uc2VydmF0aXZlIG1vZGUKWyAgICA0Ljk1MjI1NV0gQUNQSTogYnVzIHR5cGUgVVNC
IHJlZ2lzdGVyZWQKWyAgICA0Ljk1MjMwN10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50
ZXJmYWNlIGRyaXZlciB1c2JmcwpbICAgIDQuOTUyMzI3XSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIGh1YgpbICAgIDQuOTY1NjQxXSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBkZXZpY2UgZHJpdmVyIHVzYgpbICAgIDUuMDA3MDkxXSBBQ1BJOiBGYW4g
W0ZBTjBdIChvZmYpClsgICAgNS4wMDcxNTZdIEFDUEk6IEZhbiBbRkFOMV0gKG9mZikKWyAg
ICA1LjAwNzIxMF0gQUNQSTogRmFuIFtGQU4yXSAob2ZmKQpbICAgIDUuMDA3MjcxXSBBQ1BJ
OiBGYW4gW0ZBTjNdIChvZmYpClsgICAgNS4wMDczMzJdIEFDUEk6IEZhbiBbRkFONF0gKG9m
ZikKWyAgICA1LjAxNTY1NV0gZWhjaV9oY2Q6IFVTQiAyLjAgJ0VuaGFuY2VkJyBIb3N0IENv
bnRyb2xsZXIgKEVIQ0kpIERyaXZlcgpbICAgIDUuMDI5NzM0XSBTQ1NJIHN1YnN5c3RlbSBp
bml0aWFsaXplZApbICAgIDUuMDM1MDQwXSBlaGNpLXBjaTogRUhDSSBQQ0kgcGxhdGZvcm0g
ZHJpdmVyClsgICAgNS4wNDg2MTVdIGxpYmF0YSB2ZXJzaW9uIDMuMDAgbG9hZGVkLgpbICAg
IDUuMTk5NzY2XSBzZGhjaTogU2VjdXJlIERpZ2l0YWwgSG9zdCBDb250cm9sbGVyIEludGVy
ZmFjZSBkcml2ZXIKWyAgICA1LjE5OTc3MF0gc2RoY2k6IENvcHlyaWdodChjKSBQaWVycmUg
T3NzbWFuClsgICAgNS4yMzAxNzRdIHRoZXJtYWwgTE5YVEhFUk06MDA6IHJlZ2lzdGVyZWQg
YXMgdGhlcm1hbF96b25lMApbICAgIDUuMjMwMTc5XSBBQ1BJOiBUaGVybWFsIFpvbmUgW1Ra
MDBdICgyOCBDKQpbICAgIDUuMjMwNDkyXSB0aGVybWFsIExOWFRIRVJNOjAxOiByZWdpc3Rl
cmVkIGFzIHRoZXJtYWxfem9uZTEKWyAgICA1LjIzMDQ5NF0gQUNQSTogVGhlcm1hbCBab25l
IFtUWjAxXSAoMzAgQykKWyAgICA1LjM2MDY3NV0gaGlkcmF3OiByYXcgSElEIGV2ZW50cyBk
cml2ZXIgKEMpIEppcmkgS29zaW5hClsgICAgNS42Mjc2MDhdIGUxMDAwZSAwMDAwOjAwOjE5
LjAgZXRoMDogcmVnaXN0ZXJlZCBQSEMgY2xvY2sKWyAgICA1LjYyNzYxNV0gZTEwMDBlIDAw
MDA6MDA6MTkuMCBldGgwOiAoUENJIEV4cHJlc3M6Mi41R1QvczpXaWR0aCB4MSkgZWM6YTg6
NmI6ZmU6MDU6M2YKWyAgICA1LjYyNzYxOF0gZTEwMDBlIDAwMDA6MDA6MTkuMCBldGgwOiBJ
bnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24KWyAgICA1LjYyNzY1NV0gZTEw
MDBlIDAwMDA6MDA6MTkuMCBldGgwOiBNQUM6IDExLCBQSFk6IDEyLCBQQkEgTm86IEZGRkZG
Ri0wRkYKWyAgICA1LjYyNzgwMF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmlu
ZyAwIHBvbGFyaXR5IDEKWyAgICA1LjYyNzgwNV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDox
NgpbICAgIDUuNjI3ODU5XSB4aGNpX2hjZCAwMDAwOjAwOjE0LjA6IHhIQ0kgSG9zdCBDb250
cm9sbGVyClsgICAgNS42Mjc4NjhdIHhoY2lfaGNkIDAwMDA6MDA6MTQuMDogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxClsgICAgNS42Mjc5NTZdIHho
Y2lfaGNkIDAwMDA6MDA6MTQuMDogY2FjaGUgbGluZSBzaXplIG9mIDY0IGlzIG5vdCBzdXBw
b3J0ZWQKWyAgICA1LjYyODE2N10gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBp
ZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMgpbICAgIDUuNjI4MTc3XSB1c2IgdXNiMTog
TmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVy
PTEKWyAgICA1LjYyODE4MF0gdXNiIHVzYjE6IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9s
bGVyClsgICAgNS42MjgxODNdIHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMTYt
MC5icG8uMy1hbWQ2NCB4aGNpX2hjZApbICAgIDUuNjI4MTkyXSB1c2IgdXNiMTogU2VyaWFs
TnVtYmVyOiAwMDAwOjAwOjE0LjAKWyAgICA1LjYyODM5NF0gaHViIDEtMDoxLjA6IFVTQiBo
dWIgZm91bmQKWyAgICA1LjYyODQxMF0gaHViIDEtMDoxLjA6IDkgcG9ydHMgZGV0ZWN0ZWQK
WyAgICA1LjYzMTk1MF0geGhjaV9oY2QgMDAwMDowMDoxNC4wOiB4SENJIEhvc3QgQ29udHJv
bGxlcgpbICAgIDUuNjMxOTU2XSB4aGNpX2hjZCAwMDAwOjAwOjE0LjA6IG5ldyBVU0IgYnVz
IHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMgpbICAgIDUuNjMyMDAxXSB1c2Ig
dXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0w
MDAzClsgICAgNS42MzIwMDNdIHVzYiB1c2IyOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBN
ZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQpbICAgIDUuNjMyMDA1XSB1c2IgdXNi
MjogUHJvZHVjdDogeEhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA1LjYzMjAwN10gdXNiIHVz
YjI6IE1hbnVmYWN0dXJlcjogTGludXggMy4xNi0wLmJwby4zLWFtZDY0IHhoY2lfaGNkClsg
ICAgNS42MzIwMDhdIHVzYiB1c2IyOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTQuMApbICAg
IDUuNjMyMjA2XSBodWIgMi0wOjEuMDogVVNCIGh1YiBmb3VuZApbICAgIDUuNjMyMjIxXSBo
dWIgMi0wOjEuMDogNCBwb3J0cyBkZXRlY3RlZApbICAgIDUuNjMzMzM3XSB4ZW46IHJlZ2lz
dGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDUuNjMzMzQzXSBB
bHJlYWR5IHNldHVwIHRoZSBHU0kgOjIzClsgICAgNS42MzMzODhdIGVoY2ktcGNpIDAwMDA6
MDA6MWQuMDogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA1LjYzMzM5N10gZWhjaS1wY2kg
MDAwMDowMDoxZC4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVt
YmVyIDMKWyAgICA1LjYzMzQyNF0gZWhjaS1wY2kgMDAwMDowMDoxZC4wOiBkZWJ1ZyBwb3J0
IDIKWyAgICA1LjYzNzM4Ml0gZWhjaS1wY2kgMDAwMDowMDoxZC4wOiBjYWNoZSBsaW5lIHNp
emUgb2YgNjQgaXMgbm90IHN1cHBvcnRlZApbICAgIDUuNjM3NDQ2XSBlaGNpLXBjaSAwMDAw
OjAwOjFkLjA6IGlycSAyMywgaW8gbWVtIDB4ZjdkM2IwMDAKWyAgICA1LjY0ODEwOV0gZWhj
aS1wY2kgMDAwMDowMDoxZC4wOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMApbICAgIDUu
NjQ4Mjk0XSB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs
IGlkUHJvZHVjdD0wMDAyClsgICAgNS42NDgyOTddIHVzYiB1c2IzOiBOZXcgVVNCIGRldmlj
ZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQpbICAgIDUuNjQ4
Mjk5XSB1c2IgdXNiMzogUHJvZHVjdDogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA1LjY0
ODMwMV0gdXNiIHVzYjM6IE1hbnVmYWN0dXJlcjogTGludXggMy4xNi0wLmJwby4zLWFtZDY0
IGVoY2lfaGNkClsgICAgNS42NDgzMDNdIHVzYiB1c2IzOiBTZXJpYWxOdW1iZXI6IDAwMDA6
MDA6MWQuMApbICAgIDUuNjQ4NDk1XSBodWIgMy0wOjEuMDogVVNCIGh1YiBmb3VuZApbICAg
IDUuNjQ4NTA5XSBodWIgMy0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApbICAgIDUuNjQ4NzQ3
XSBhaGNpIDAwMDA6MDA6MWYuMjogdmVyc2lvbiAzLjAKWyAgICA1LjY0ODg5M10geGVuOiBy
ZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICA1LjY0ODg5
OV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOQpbICAgIDUuNjQ5MDc5XSBhaGNpIDAwMDA6
MDA6MWYuMjogQUhDSSAwMDAxLjAzMDAgMzIgc2xvdHMgMiBwb3J0cyA2IEdicHMgMHg4IGlt
cGwgU0FUQSBtb2RlClsgICAgNS42NDkwODVdIGFoY2kgMDAwMDowMDoxZi4yOiBmbGFnczog
NjRiaXQgbmNxIHBtIGxlZCBjbG8gb25seSBwaW8gc2x1bSBwYXJ0IGRlc28gc2FkbSBzZHMg
YXBzdCAKWyAgICA1LjY1MDU5N10gc2NzaTAgOiBhaGNpClsgICAgNS42NTEzMDddIHNjc2kx
IDogYWhjaQpbICAgIDUuNjUxNTEzXSBzY3NpMiA6IGFoY2kKWyAgICA1LjY1MTczOV0gc2Nz
aTMgOiBhaGNpClsgICAgNS42NTE4MjddIGF0YTE6IERVTU1ZClsgICAgNS42NTE4MzBdIGF0
YTI6IERVTU1ZClsgICAgNS42NTE4MzJdIGF0YTM6IERVTU1ZClsgICAgNS42NTE4MzVdIGF0
YTQ6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmN2QzYTAwMCBwb3J0IDB4Zjdk
M2EyODAgaXJxIDczClsgICAgNS45NzIxNjNdIGF0YTQ6IFNBVEEgbGluayB1cCA2LjAgR2Jw
cyAoU1N0YXR1cyAxMzMgU0NvbnRyb2wgMzAwKQpbICAgIDUuOTcyNjE5XSBhdGE0LjAwOiBz
dXBwb3J0cyBEUk0gZnVuY3Rpb25zIGFuZCBtYXkgbm90IGJlIGZ1bGx5IGFjY2Vzc2libGUK
WyAgICA1Ljk3NTU5MV0gYXRhNC4wMDogZGlzYWJsaW5nIHF1ZXVlZCBUUklNIHN1cHBvcnQK
WyAgICA1Ljk3NTU5Nl0gYXRhNC4wMDogQVRBLTk6IENydWNpYWxfQ1QxMjBNNTAwU1NEMywg
TVUwMywgbWF4IFVETUEvMTMzClsgICAgNS45NzU1OTldIGF0YTQuMDA6IDIzNDQ0MTY0OCBz
ZWN0b3JzLCBtdWx0aSAxNjogTEJBNDggTkNRIChkZXB0aCAzMS8zMiksIEFBClsgICAgNS45
NzkzMjddIGF0YTQuMDA6IHN1cHBvcnRzIERSTSBmdW5jdGlvbnMgYW5kIG1heSBub3QgYmUg
ZnVsbHkgYWNjZXNzaWJsZQpbICAgIDUuOTgyMjUyXSBhdGE0LjAwOiBkaXNhYmxpbmcgcXVl
dWVkIFRSSU0gc3VwcG9ydApbICAgIDUuOTg1NDk5XSBhdGE0LjAwOiBjb25maWd1cmVkIGZv
ciBVRE1BLzEzMwpbICAgIDUuOTg1NjY5XSBzY3NpIDM6MDowOjA6IERpcmVjdC1BY2Nlc3Mg
ICAgIEFUQSAgICAgIENydWNpYWxfQ1QxMjBNNTAgTVUwMyBQUTogMCBBTlNJOiA1ClsgICAg
NS45OTc3NjZdIHNkIDM6MDowOjA6IFtzZGFdIDIzNDQ0MTY0OCA1MTItYnl0ZSBsb2dpY2Fs
IGJsb2NrczogKDEyMCBHQi8xMTEgR2lCKQpbICAgIDUuOTk3NzcyXSBzZCAzOjA6MDowOiBb
c2RhXSA0MDk2LWJ5dGUgcGh5c2ljYWwgYmxvY2tzClsgICAgNS45OTc4NjldIHNkIDM6MDow
OjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmClsgICAgNS45OTc4NzRdIHNkIDM6MDow
OjA6IFtzZGFdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwClsgICAgNS45OTc4OThdIHNkIDM6
MDowOjA6IFtzZGFdIFdyaXRlIGNhY2hlOiBlbmFibGVkLCByZWFkIGNhY2hlOiBlbmFibGVk
LCBkb2Vzbid0IHN1cHBvcnQgRFBPIG9yIEZVQQpbICAgIDUuOTk4NzM0XSAgc2RhOiBzZGEx
IHNkYTIgc2RhMwpbICAgIDUuOTk5MjcwXSBzZCAzOjA6MDowOiBbc2RhXSBBdHRhY2hlZCBT
Q1NJIGRpc2sKWyAgICA2LjAwMzE0NF0gc2QgMzowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5l
cmljIHNnMCB0eXBlIDAKWyAgICA2LjA1MjIyMl0gdXNiIDEtNDogbmV3IGZ1bGwtc3BlZWQg
VVNCIGRldmljZSBudW1iZXIgNCB1c2luZyB4aGNpX2hjZApbICAgIDYuMDcxOTQ1XSBwbGF0
Zm9ybSBtaWNyb2NvZGU6IGZpcm13YXJlOiBkaXJlY3QtbG9hZGluZyBmaXJtd2FyZSBpbnRl
bC11Y29kZS8wNi00NS0wMQpbICAgIDYuMDcxOTg0XSBtaWNyb2NvZGU6IENQVTAgc2lnPTB4
NDA2NTEsIHBmPTB4NDAsIHJldmlzaW9uPTB4MTYKWyAgICA2LjA3MjAwMV0gbWljcm9jb2Rl
OiBDUFUwIHVwZGF0ZSB0byByZXZpc2lvbiAweDE4IGZhaWxlZApbICAgIDYuMDcyMDgwXSBw
bGF0Zm9ybSBtaWNyb2NvZGU6IGZpcm13YXJlOiBkaXJlY3QtbG9hZGluZyBmaXJtd2FyZSBp
bnRlbC11Y29kZS8wNi00NS0wMQpbICAgIDYuMDcyMTM0XSBtaWNyb2NvZGU6IENQVTEgc2ln
PTB4NDA2NTEsIHBmPTB4NDAsIHJldmlzaW9uPTB4MTYKWyAgICA2LjA3MjE1MV0gbWljcm9j
b2RlOiBDUFUxIHVwZGF0ZSB0byByZXZpc2lvbiAweDE4IGZhaWxlZApbICAgIDYuMDkwMTgx
XSBQTTogU3RhcnRpbmcgbWFudWFsIHJlc3VtZSBmcm9tIGRpc2sKWyAgICA2LjA5MDE4Nl0g
UE06IEhpYmVybmF0aW9uIGltYWdlIHBhcnRpdGlvbiA4OjIgcHJlc2VudApbICAgIDYuMDkw
MTg4XSBQTTogTG9va2luZyBmb3IgaGliZXJuYXRpb24gaW1hZ2UuClsgICAgNi4wOTA0MThd
IFBNOiBJbWFnZSBub3QgZm91bmQgKGNvZGUgLTIyKQpbICAgIDYuMDkwNDIwXSBQTTogSGli
ZXJuYXRpb24gaW1hZ2Ugbm90IHByZXNlbnQgb3IgY291bGQgbm90IGJlIGxvYWRlZC4KWyAg
ICA2LjEwNjAyMl0gRVhUNC1mcyAoc2RhMSk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9y
ZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiAobnVsbCkKWyAgICA2LjE4NDYzMV0gdXNiIDEtNDog
TmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTA0NWUsIGlkUHJvZHVjdD0wNzQ1Clsg
ICAgNi4xODQ2MzddIHVzYiAxLTQ6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0xLCBQ
cm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wClsgICAgNi4xODQ2NDFdIHVzYiAxLTQ6IFByb2R1
Y3Q6IE1pY3Jvc29mdFx4ZmZmZmZmYzJceGZmZmZmZmFlXHhmZmZmZmZhZSBOYW5vIFRyYW5z
Y2VpdmVyIHYyLjAKWyAgICA2LjE4NDY0NF0gdXNiIDEtNDogTWFudWZhY3R1cmVyOiBNaWNy
b3NvZnQKWyAgICA2LjM1MjExOF0gdXNiIDEtNzogbmV3IGZ1bGwtc3BlZWQgVVNCIGRldmlj
ZSBudW1iZXIgNSB1c2luZyB4aGNpX2hjZApbICAgIDYuNDgzNzUyXSB1c2IgMS03OiBOZXcg
VVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9ODA4NywgaWRQcm9kdWN0PTA3ZGEKWyAgICA2
LjQ4Mzc1OF0gdXNiIDEtNzogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTAsIFByb2R1
Y3Q9MCwgU2VyaWFsTnVtYmVyPTAKWyAgICA2LjUyNTk1Ml0gdWRldmRbNDc0XTogc3RhcnRp
bmcgdmVyc2lvbiAxNzUKWyAgICA2LjY5MjA5MF0gW2RybV0gSW5pdGlhbGl6ZWQgZHJtIDEu
MS4wIDIwMDYwODEwClsgICAgNi42OTYyNDVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRy
aWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNi42OTYyNTNdIEFscmVhZHkgc2V0dXAgdGhl
IEdTSSA6MTYKWyAgICA2LjY5OTE5MF0gTW9uaXRvci1Nd2FpdCB3aWxsIGJlIHVzZWQgdG8g
ZW50ZXIgQy0xIHN0YXRlClsgICAgNi43MDAxMjldIE1vbml0b3ItTXdhaXQgd2lsbCBiZSB1
c2VkIHRvIGVudGVyIEMtMiBzdGF0ZQpbICAgIDYuNzA0MjUyXSBXYXJuaW5nOiBQcm9jZXNz
b3IgUGxhdGZvcm0gTGltaXQgbm90IHN1cHBvcnRlZC4KWyAgICA2LjcyMTgwMl0gaW5wdXQ6
IFBvd2VyIEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhTWUJVUzowMC9QTlAw
QzBDOjAwL2lucHV0L2lucHV0MApbICAgIDYuNzIxODExXSBBQ1BJOiBQb3dlciBCdXR0b24g
W1BXUkJdClsgICAgNi43MjQzOTBdIHVzYiAyLTE6IG5ldyBTdXBlclNwZWVkIFVTQiBkZXZp
Y2UgbnVtYmVyIDIgdXNpbmcgeGhjaV9oY2QKWyAgICA2LjcyOTE4M10gaW5wdXQ6IFBvd2Vy
IEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhQV1JCTjowMC9pbnB1dC9pbnB1
dDEKWyAgICA2LjcyOTE5MV0gQUNQSTogUG93ZXIgQnV0dG9uIFtQV1JGXQpbICAgIDYuNzQw
OTY5XSB1c2IgMi0xOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MTc0YywgaWRQ
cm9kdWN0PTU1YWEKWyAgICA2Ljc0MDk3NV0gdXNiIDItMTogTmV3IFVTQiBkZXZpY2Ugc3Ry
aW5nczogTWZyPTIsIFByb2R1Y3Q9MywgU2VyaWFsTnVtYmVyPTEKWyAgICA2Ljc0MDk3OF0g
dXNiIDItMTogUHJvZHVjdDogQVNNMTA1MwpbICAgIDYuNzQwOTg0XSB1c2IgMi0xOiBNYW51
ZmFjdHVyZXI6IEFzbWVkaWEKWyAgICA2Ljc0MDk4N10gdXNiIDItMTogU2VyaWFsTnVtYmVy
OiAwMTIzNDU2Nzg5QUJDREVGMDEyNApbICAgIDYuNzU1NzQ0XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAxNiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDYuNzU1NzUzXSBBbHJlYWR5
IHNldHVwIHRoZSBHU0kgOjE2ClsgICAgNi43ODE2ODZdIFtkcm1dIE1lbW9yeSB1c2FibGUg
YnkgZ3JhcGhpY3MgZGV2aWNlID0gMjA0OE0KWyAgICA2Ljc4MTY5MV0gW2RybV0gUmVwbGFj
aW5nIFZHQSBjb25zb2xlIGRyaXZlcgpbICAgIDYuNzgzMDU5XSBDb25zb2xlOiBzd2l0Y2hp
bmcgdG8gY29sb3VyIGR1bW15IGRldmljZSA4MHgyNQpbICAgIDYuODk5NTUwXSByYW5kb206
IG5vbmJsb2NraW5nIHBvb2wgaXMgaW5pdGlhbGl6ZWQKWyAgICA2Ljk4MDY3OF0gdXNiIDIt
MzogbmV3IFN1cGVyU3BlZWQgVVNCIGRldmljZSBudW1iZXIgMyB1c2luZyB4aGNpX2hjZApb
ICAgIDcuMDA4NDM5XSB1c2IgMi0zOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9
MGI5NSwgaWRQcm9kdWN0PTE3OTAKWyAgICA3LjAwODQ0NV0gdXNiIDItMzogTmV3IFVTQiBk
ZXZpY2Ugc3RyaW5nczogTWZyPTEsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTMKWyAgICA3
LjAwODQ0OF0gdXNiIDItMzogUHJvZHVjdDogQVg4ODE3OQpbICAgIDcuMDA4NDUxXSB1c2Ig
Mi0zOiBNYW51ZmFjdHVyZXI6IEFTSVggRWxlYy4gQ29ycC4KWyAgICA3LjAwODQ1M10gdXNi
IDItMzogU2VyaWFsTnVtYmVyOiAwMDAwMjQ5QjBFMjAyQgpbICAgIDcuMTI4MTI0XSB1c2Ig
My0xOiBuZXcgaGlnaC1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciAyIHVzaW5nIGVoY2ktcGNp
ClsgICAgNy4xMzgyOThdIG51dm90b24tY2lyIDAwOjA1OiBbaW8gIDB4MDI0MC0weDAyNGZd
ClsgICAgNy4xMzgzMzRdIG51dm90b24tY2lyIDAwOjA1OiB1bmFibGUgdG8gYXNzaWduIHJl
c291cmNlcwpbICAgIDcuMTM4MzQxXSBudXZvdG9uLWNpciAwMDowNTogQ291bGQgbm90IGFj
dGl2YXRlIFBOUCBkZXZpY2UhClsgICAgNy4xNjY4MjVdIEZhaWxlZCB0byBhZGQgV0MgTVRS
UiBmb3IgWzAwMDAwMDAwZTAwMDAwMDAtMDAwMDAwMDBlZmZmZmZmZl07IHBlcmZvcm1hbmNl
IG1heSBzdWZmZXIuClsgICAgNy4xODgyMzRdIFtkcm1dIFN1cHBvcnRzIHZibGFuayB0aW1l
c3RhbXAgY2FjaGluZyBSZXYgMiAoMjEuMTAuMjAxMykuClsgICAgNy4xODgyMzldIFtkcm1d
IERyaXZlciBzdXBwb3J0cyBwcmVjaXNlIHZibGFuayB0aW1lc3RhbXAgcXVlcnkuClsgICAg
Ny4xODgyNzldIHZnYWFyYjogZGV2aWNlIGNoYW5nZWQgZGVjb2RlczogUENJOjAwMDA6MDA6
MDIuMCxvbGRkZWNvZGVzPWlvK21lbSxkZWNvZGVzPWlvK21lbTpvd25zPWlvK21lbQpbICAg
IDcuMjYxMDI3XSB1c2IgMy0xOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9ODA4
NywgaWRQcm9kdWN0PTgwMDAKWyAgICA3LjI2MTAzM10gdXNiIDMtMTogTmV3IFVTQiBkZXZp
Y2Ugc3RyaW5nczogTWZyPTAsIFByb2R1Y3Q9MCwgU2VyaWFsTnVtYmVyPTAKWyAgICA3LjI2
MTQ3OF0gaHViIDMtMToxLjA6IFVTQiBodWIgZm91bmQKWyAgICA3LjI2MTY0Nl0gaHViIDMt
MToxLjA6IDggcG9ydHMgZGV0ZWN0ZWQKWyAgICA3LjM0MDk1MF0gaW5wdXQ6IFBDIFNwZWFr
ZXIgYXMgL2RldmljZXMvcGxhdGZvcm0vcGNzcGtyL2lucHV0L2lucHV0MwpbICAgIDcuMzg4
MDE2XSBBVlgyIHZlcnNpb24gb2YgZ2NtX2VuYy9kZWMgZW5nYWdlZC4KWyAgICA3LjM4ODk2
M10gY2ZnODAyMTE6IENhbGxpbmcgQ1JEQSB0byB1cGRhdGUgd29ybGQgcmVndWxhdG9yeSBk
b21haW4KWyAgICA3LjQxMTgwOV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciB1c2JoaWQKWyAgICA3LjQxMTgxNF0gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJp
dmVyClsgICAgNy40MTkzODVdIEJsdWV0b290aDogQ29yZSB2ZXIgMi4xOQpbICAgIDcuNDE5
NDA2XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDMxClsgICAgNy40MTk0MDhd
IEJsdWV0b290aDogSENJIGRldmljZSBhbmQgY29ubmVjdGlvbiBtYW5hZ2VyIGluaXRpYWxp
emVkClsgICAgNy40MTk0MTddIEJsdWV0b290aDogSENJIHNvY2tldCBsYXllciBpbml0aWFs
aXplZApbICAgIDcuNDE5NDIxXSBCbHVldG9vdGg6IEwyQ0FQIHNvY2tldCBsYXllciBpbml0
aWFsaXplZApbICAgIDcuNDE5NDMyXSBCbHVldG9vdGg6IFNDTyBzb2NrZXQgbGF5ZXIgaW5p
dGlhbGl6ZWQKWyAgICA3LjQyMTYzM10gSW50ZWwoUikgV2lyZWxlc3MgV2lGaSBkcml2ZXIg
Zm9yIExpbnV4LCBpbi10cmVlOgpbICAgIDcuNDIxNjM3XSBDb3B5cmlnaHQoYykgMjAwMy0g
MjAxNCBJbnRlbCBDb3Jwb3JhdGlvbgpbICAgIDcuNDIxODMzXSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDcuNDIxODQwXSBBbHJlYWR5
IHNldHVwIHRoZSBHU0kgOjE5ClsgICAgNy40MjE4NTddIGl3bHdpZmkgMDAwMDowMjowMC4w
OiBjYW4ndCBkaXNhYmxlIEFTUE07IE9TIGRvZXNuJ3QgaGF2ZSBBU1BNIGNvbnRyb2wKWyAg
ICA3LjQzNzUyMV0gaXdsd2lmaSAwMDAwOjAyOjAwLjA6IGZpcm13YXJlOiBkaXJlY3QtbG9h
ZGluZyBmaXJtd2FyZSBpd2x3aWZpLTIwMzAtNi51Y29kZQpbICAgIDcuNDM4MjQ0XSBpd2x3
aWZpIDAwMDA6MDI6MDAuMDogbG9hZGVkIGZpcm13YXJlIHZlcnNpb24gMTguMTY4LjYuMSBv
cF9tb2RlIGl3bGR2bQpbICAgIDcuNDQyOTQzXSBhbGc6IE5vIHRlc3QgZm9yIF9fZ2NtLWFl
cy1hZXNuaSAoX19kcml2ZXItZ2NtLWFlcy1hZXNuaSkKWyAgICA3LjQ1ODg0Ml0gaXdsd2lm
aSAwMDAwOjAyOjAwLjA6IENPTkZJR19JV0xXSUZJX0RFQlVHIGRpc2FibGVkClsgICAgNy40
NTg4NDhdIGl3bHdpZmkgMDAwMDowMjowMC4wOiBDT05GSUdfSVdMV0lGSV9ERUJVR0ZTIGRp
c2FibGVkClsgICAgNy40NTg4NTFdIGl3bHdpZmkgMDAwMDowMjowMC4wOiBDT05GSUdfSVdM
V0lGSV9ERVZJQ0VfVFJBQ0lORyBkaXNhYmxlZApbICAgIDcuNDU4ODU0XSBpd2x3aWZpIDAw
MDA6MDI6MDAuMDogRGV0ZWN0ZWQgSW50ZWwoUikgQ2VudHJpbm8oUikgV2lyZWxlc3MtTiAy
MjMwIEJHTiwgUkVWPTB4QzgKWyAgICA3LjQ1OTAxMl0gaXdsd2lmaSAwMDAwOjAyOjAwLjA6
IEwxIERpc2FibGVkOyBFbmFibGluZyBMMFMKWyAgICA3LjUwNzcwNF0gaW5wdXQ6IE1pY3Jv
c29mdCBNaWNyb3NvZnRceGZmZmZmZmMyXHhmZmZmZmZhZVx4ZmZmZmZmYWUgTmFubyBUcmFu
c2NlaXZlciB2Mi4wIGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxNC4wL3VzYjEv
MS00LzEtNDoxLjAvMDAwMzowNDVFOjA3NDUuMDAwMS9pbnB1dC9pbnB1dDQKWyAgICA3LjUx
Njc5Ml0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBidHVzYgpb
ICAgIDcuNTI1NDE4XSBoaWQtZ2VuZXJpYyAwMDAzOjA0NUU6MDc0NS4wMDAxOiBpbnB1dCxo
aWRyYXcwOiBVU0IgSElEIHYxLjExIEtleWJvYXJkIFtNaWNyb3NvZnQgTWljcm9zb2Z0XHhm
ZmZmZmZjMlx4ZmZmZmZmYWVceGZmZmZmZmFlIE5hbm8gVHJhbnNjZWl2ZXIgdjIuMF0gb24g
dXNiLTAwMDA6MDA6MTQuMC00L2lucHV0MApbICAgIDcuNTI1OTYyXSBpbnB1dDogTWljcm9z
b2Z0IE1pY3Jvc29mdFx4ZmZmZmZmYzJceGZmZmZmZmFlXHhmZmZmZmZhZSBOYW5vIFRyYW5z
Y2VpdmVyIHYyLjAgYXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAwOjE0LjAvdXNiMS8x
LTQvMS00OjEuMS8wMDAzOjA0NUU6MDc0NS4wMDAyL2lucHV0L2lucHV0NQpbICAgIDcuNTI4
Nzk0XSBoaWQtZ2VuZXJpYyAwMDAzOjA0NUU6MDc0NS4wMDAyOiBpbnB1dCxoaWRyYXcxOiBV
U0IgSElEIHYxLjExIE1vdXNlIFtNaWNyb3NvZnQgTWljcm9zb2Z0XHhmZmZmZmZjMlx4ZmZm
ZmZmYWVceGZmZmZmZmFlIE5hbm8gVHJhbnNjZWl2ZXIgdjIuMF0gb24gdXNiLTAwMDA6MDA6
MTQuMC00L2lucHV0MQpbICAgIDcuNTM5MjUzXSBpbnB1dDogTWljcm9zb2Z0IE1pY3Jvc29m
dFx4ZmZmZmZmYzJceGZmZmZmZmFlXHhmZmZmZmZhZSBOYW5vIFRyYW5zY2VpdmVyIHYyLjAg
YXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAwOjE0LjAvdXNiMS8xLTQvMS00OjEuMi8w
MDAzOjA0NUU6MDc0NS4wMDAzL2lucHV0L2lucHV0NgpbICAgIDcuNTQwNjc3XSBoaWQtZ2Vu
ZXJpYyAwMDAzOjA0NUU6MDc0NS4wMDAzOiBpbnB1dCxoaWRkZXYwLGhpZHJhdzI6IFVTQiBI
SUQgdjEuMTEgRGV2aWNlIFtNaWNyb3NvZnQgTWljcm9zb2Z0XHhmZmZmZmZjMlx4ZmZmZmZm
YWVceGZmZmZmZmFlIE5hbm8gVHJhbnNjZWl2ZXIgdjIuMF0gb24gdXNiLTAwMDA6MDA6MTQu
MC00L2lucHV0MgpbICAgIDcuNTgyODMyXSBpZWVlODAyMTEgcGh5MDogU2VsZWN0ZWQgcmF0
ZSBjb250cm9sIGFsZ29yaXRobSAnaXdsLWFnbi1ycycKWyAgICA3LjYxMjM2NV0gY2ZnODAy
MTE6IFdvcmxkIHJlZ3VsYXRvcnkgZG9tYWluIHVwZGF0ZWQ6ClsgICAgNy42MTIzNzBdIGNm
ZzgwMjExOiAgREZTIE1hc3RlciByZWdpb246IHVuc2V0ClsgICAgNy42MTIzNzJdIGNmZzgw
MjExOiAgIChzdGFydF9mcmVxIC0gZW5kX2ZyZXEgQCBiYW5kd2lkdGgpLCAobWF4X2FudGVu
bmFfZ2FpbiwgbWF4X2VpcnApLCAoZGZzX2NhY190aW1lKQpbICAgIDcuNjEyMzc2XSBjZmc4
MDIxMTogICAoMjQwMjAwMCBLSHogLSAyNDcyMDAwIEtIeiBAIDQwMDAwIEtIeiksIChOL0Es
IDIwMDAgbUJtKSwgKE4vQSkKWyAgICA3LjYxMjM3OV0gY2ZnODAyMTE6ICAgKDI0NTcwMDAg
S0h6IC0gMjQ4MjAwMCBLSHogQCA0MDAwMCBLSHopLCAoTi9BLCAyMDAwIG1CbSksIChOL0Ep
ClsgICAgNy42MTIzODJdIGNmZzgwMjExOiAgICgyNDc0MDAwIEtIeiAtIDI0OTQwMDAgS0h6
IEAgMjAwMDAgS0h6KSwgKE4vQSwgMjAwMCBtQm0pLCAoTi9BKQpbICAgIDcuNjEyMzg0XSBj
Zmc4MDIxMTogICAoNTE3MDAwMCBLSHogLSA1MjUwMDAwIEtIeiBAIDE2MDAwMCBLSHopLCAo
Ti9BLCAyMDAwIG1CbSksIChOL0EpClsgICAgNy42MTIzODhdIGNmZzgwMjExOiAgICg1MjUw
MDAwIEtIeiAtIDUzMzAwMDAgS0h6IEAgMTYwMDAwIEtIeiksIChOL0EsIDIwMDAgbUJtKSwg
KDAgcykKWyAgICA3LjYxMjM5MF0gY2ZnODAyMTE6ICAgKDU0OTAwMDAgS0h6IC0gNTczMDAw
MCBLSHogQCAxNjAwMDAgS0h6KSwgKE4vQSwgMjAwMCBtQm0pLCAoMCBzKQpbICAgIDcuNjEy
MzkzXSBjZmc4MDIxMTogICAoNTczNTAwMCBLSHogLSA1ODM1MDAwIEtIeiBAIDgwMDAwIEtI
eiksIChOL0EsIDIwMDAgbUJtKSwgKE4vQSkKWyAgICA3LjYxMjM5NV0gY2ZnODAyMTE6ICAg
KDU3MjQwMDAwIEtIeiAtIDYzNzIwMDAwIEtIeiBAIDIxNjAwMDAgS0h6KSwgKE4vQSwgMCBt
Qm0pLCAoTi9BKQpbICAgIDcuNjE5NjEzXSBhbGc6IE5vIHRlc3QgZm9yIGNyYzMyIChjcmMz
Mi1wY2xtdWwpClsgICAgNy42MjgwMTZdIHVzYi1zdG9yYWdlIDItMToxLjA6IFVTQiBNYXNz
IFN0b3JhZ2UgZGV2aWNlIGRldGVjdGVkClsgICAgNy42NDI3NzhdIHVzYi1zdG9yYWdlIDIt
MToxLjA6IFF1aXJrcyBtYXRjaCBmb3IgdmlkIDE3NGMgcGlkIDU1YWE6IDQwMDAwMApbICAg
IDcuNjQzNDk4XSBzY3NpNCA6IHVzYi1zdG9yYWdlIDItMToxLjAKWyAgICA3LjY0Mzc5MV0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Itc3RvcmFnZQpb
ICAgIDcuOTkwMDgzXSBheDg4MTc5XzE3OGEgMi0zOjEuMCBldGgxOiByZWdpc3RlciAnYXg4
ODE3OV8xNzhhJyBhdCB1c2ItMDAwMDowMDoxNC4wLTMsIEFTSVggQVg4ODE3OSBVU0IgMy4w
IEdpZ2FiaXQgRXRoZXJuZXQsIDAwOjI0OjliOjBlOjIwOjJiClsgICAgNy45OTAxMjZdIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgYXg4ODE3OV8xNzhhClsg
ICAgOC4zODc1MDFdIGZiY29uOiBpbnRlbGRybWZiIChmYjApIGlzIHByaW1hcnkgZGV2aWNl
ClsgICAgOC40NzIyMDFdIENvbnNvbGU6IHN3aXRjaGluZyB0byBjb2xvdXIgZnJhbWUgYnVm
ZmVyIGRldmljZSAxNjB4NjQKWyAgICA4LjYxNjU5Ml0gaTkxNSAwMDAwOjAwOjAyLjA6IGZi
MDogaW50ZWxkcm1mYiBmcmFtZSBidWZmZXIgZGV2aWNlClsgICAgOC42MTY1OTVdIGk5MTUg
MDAwMDowMDowMi4wOiByZWdpc3RlcmVkIHBhbmljIG5vdGlmaWVyClsgICAgOC42NDA2MjZd
IHNjc2kgNDowOjA6MDogRGlyZWN0LUFjY2VzcyAgICAgQVNNVCAgICAgMjEwNSAgICAgICAg
ICAgICAwICAgIFBROiAwIEFOU0k6IDYKWyAgICA4LjY0MDk3OV0gc2QgNDowOjA6MDogQXR0
YWNoZWQgc2NzaSBnZW5lcmljIHNnMSB0eXBlIDAKWyAgICA4LjY0MTIwNl0gc2QgNDowOjA6
MDogW3NkYl0gMTk1MzUyNTE2OCA1MTItYnl0ZSBsb2dpY2FsIGJsb2NrczogKDEuMDAgVEIv
OTMxIEdpQikKWyAgICA4LjY0MTUxMF0gc2QgNDowOjA6MDogW3NkYl0gV3JpdGUgUHJvdGVj
dCBpcyBvZmYKWyAgICA4LjY0MTUxNV0gc2QgNDowOjA6MDogW3NkYl0gTW9kZSBTZW5zZTog
NDMgMDAgMDAgMDAKWyAgICA4LjY0MTgxNl0gc2QgNDowOjA6MDogW3NkYl0gV3JpdGUgY2Fj
aGU6IGVuYWJsZWQsIHJlYWQgY2FjaGU6IGVuYWJsZWQsIGRvZXNuJ3Qgc3VwcG9ydCBEUE8g
b3IgRlVBClsgICAgOC42Nzk4OTFdIEFDUEk6IFZpZGVvIERldmljZSBbR0ZYMF0gKG11bHRp
LWhlYWQ6IHllcyAgcm9tOiBubyAgcG9zdDogbm8pClsgICAgOC42ODA1MTddIGFjcGkgZGV2
aWNlOjYwOiByZWdpc3RlcmVkIGFzIGNvb2xpbmdfZGV2aWNlOApbICAgIDguNjgwNjQ5XSBp
bnB1dDogVmlkZW8gQnVzIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL0xOWFNZQlVTOjAwL1BO
UDBBMDg6MDAvTE5YVklERU86MDAvaW5wdXQvaW5wdXQ3ClsgICAgOC42ODEwNzhdIFtkcm1d
IEluaXRpYWxpemVkIGk5MTUgMS42LjAgMjAwODA3MzAgZm9yIDAwMDA6MDA6MDIuMCBvbiBt
aW5vciAwClsgICAgOC42ODEzNDNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJp
bmcgMCBwb2xhcml0eSAxClsgICAgOC42ODEzNDldIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTYKWyAgICA4LjY4MTQ4M10geGVuOiByZWdpc3RlcmluZyBnc2kgMjIgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDEKWyAgICA4LjY4MTUwMV0geGVuOiAtLT4gcGlycT0yMiAtPiBpcnE9MjIg
KGdzaT0yMikKWyAgICA4LjY4MjE5NF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDEKWyAgICA4LjY4MjIwOV0geGVuOiAtLT4gcGlycT0xOCAtPiBp
cnE9MTggKGdzaT0xOCkKWyAgICA4LjY4MjI0NV0gQUNQSSBXYXJuaW5nOiBTeXN0ZW1JTyBy
YW5nZSAweDAwMDAwMDAwMDAwMGYwNDAtMHgwMDAwMDAwMDAwMDBmMDVmIGNvbmZsaWN0cyB3
aXRoIE9wUmVnaW9uIDB4MDAwMDAwMDAwMDAwZjA0MC0weDAwMDAwMDAwMDAwMGYwNGYgKFxf
U0JfLlBDSTAuU0JVUy5TTUJJKSAoMjAxNDA0MjQvdXRhZGRyZXNzLTI1OCkKWyAgICA4LjY4
MjI1NF0gQUNQSTogSWYgYW4gQUNQSSBkcml2ZXIgaXMgYXZhaWxhYmxlIGZvciB0aGlzIGRl
dmljZSwgeW91IHNob3VsZCB1c2UgaXQgaW5zdGVhZCBvZiB0aGUgbmF0aXZlIGRyaXZlcgpb
ICAgIDguNzAyMTA5XSBpVENPX3ZlbmRvcl9zdXBwb3J0OiB2ZW5kb3Itc3VwcG9ydD0wClsg
ICAgOC43MDUxMDhdIGlUQ09fd2R0OiBJbnRlbCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJpdmVy
IHYxLjExClsgICAgOC43MDUxNzFdIGlUQ09fd2R0OiBGb3VuZCBhIEx5bnggUG9pbnRfTFAg
VENPIGRldmljZSAoVmVyc2lvbj0yLCBUQ09CQVNFPTB4MTg2MCkKWyAgICA4LjcwNjkzNV0g
aVRDT193ZHQ6IGluaXRpYWxpemVkLiBoZWFydGJlYXQ9MzAgc2VjIChub3dheW91dD0wKQpb
ICAgIDguNzEzMTU5XSBzb3VuZCBoZGF1ZGlvQzFEMDogYXV0b2NvbmZpZzogbGluZV9vdXRz
PTEgKDB4MjEvMHgwLzB4MC8weDAvMHgwKSB0eXBlOmhwClsgICAgOC43MTMxNjVdIHNvdW5k
IGhkYXVkaW9DMUQwOiAgICBzcGVha2VyX291dHM9MCAoMHgwLzB4MC8weDAvMHgwLzB4MCkK
WyAgICA4LjcxMzE2OV0gc291bmQgaGRhdWRpb0MxRDA6ICAgIGhwX291dHM9MCAoMHgwLzB4
MC8weDAvMHgwLzB4MCkKWyAgICA4LjcxMzE3Ml0gc291bmQgaGRhdWRpb0MxRDA6ICAgIG1v
bm86IG1vbm9fb3V0PTB4MApbICAgIDguNzEzMTc0XSBzb3VuZCBoZGF1ZGlvQzFEMDogICAg
aW5wdXRzOgpbICAgIDguNzEzMTc4XSBzb3VuZCBoZGF1ZGlvQzFEMDogICAgICBNaWM9MHgx
OQpbICAgIDguNzE5NTIzXSBpbnB1dDogSERBIEludGVsIEhETUkgSERNSS9EUCxwY209MyBh
cyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MDMuMC9zb3VuZC9jYXJkMC9pbnB1dDkK
WyAgICA4LjcxOTc3NV0gaW5wdXQ6IEhEQSBJbnRlbCBIRE1JIEhETUkvRFAscGNtPTcgYXMg
L2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAwOjAzLjAvc291bmQvY2FyZDAvaW5wdXQxMApb
ICAgIDguNzI2MzIxXSBpbnB1dDogSERBIERpZ2l0YWwgUENCZWVwIGFzIC9kZXZpY2VzL3Bj
aTAwMDA6MDAvMDAwMDowMDoxYi4wL3NvdW5kL2NhcmQxL2hkYXVkaW9DMUQwL2lucHV0OApb
ICAgIDguNzI3MDAwXSBpbnB1dDogSERBIEludGVsIFBDSCBNaWMgYXMgL2RldmljZXMvcGNp
MDAwMDowMC8wMDAwOjAwOjFiLjAvc291bmQvY2FyZDEvaW5wdXQxMQpbICAgIDguNzI3MjQ1
XSBpbnB1dDogSERBIEludGVsIFBDSCBIZWFkcGhvbmUgYXMgL2RldmljZXMvcGNpMDAwMDow
MC8wMDAwOjAwOjFiLjAvc291bmQvY2FyZDEvaW5wdXQxMgpbICAgIDkuMjg1MTA0XSBBZGRp
bmcgNTg1NTY4OGsgc3dhcCBvbiAvZGV2L3NkYTIuICBQcmlvcml0eTotMSBleHRlbnRzOjEg
YWNyb3NzOjU4NTU2ODhrIFNTRlMKWyAgICA5LjMwODQ1Ml0gW2RybV0gRW5hYmxpbmcgUkM2
IHN0YXRlczogUkM2IG9uLCBSQzZwIG9mZiwgUkM2cHAgb2ZmClsgICAgOS4zMjQ0MThdIEVY
VDQtZnMgKHNkYTEpOiByZS1tb3VudGVkLiBPcHRzOiAobnVsbCkKWyAgICA5LjQxMDQxMl0g
RVhUNC1mcyAoc2RhMSk6IHJlLW1vdW50ZWQuIE9wdHM6IGVycm9ycz1yZW1vdW50LXJvClsg
ICAxMS4zMDg1NDFdIEJyaWRnZSBmaXJld2FsbGluZyByZWdpc3RlcmVkClsgICAxMS4zMTg4
MTNdIGRldmljZSBldGgxIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQpbICAgMTEuNjM4NTA0
XSBJUHY2OiBBRERSQ09ORihORVRERVZfVVApOiBldGgxOiBsaW5rIGlzIG5vdCByZWFkeQpb
ICAgMTEuNjQxMjk1XSBJUHY2OiBBRERSQ09ORihORVRERVZfVVApOiB4ZW5icjA6IGxpbmsg
aXMgbm90IHJlYWR5ClsgICAxMi4xOTg2MDNdICBzZGI6IHNkYjEKWyAgIDEyLjIwMjIwMl0g
c2QgNDowOjA6MDogW3NkYl0gQXR0YWNoZWQgU0NTSSBkaXNrClsgICAxMi4yOTk4NTddIFJQ
QzogUmVnaXN0ZXJlZCBuYW1lZCBVTklYIHNvY2tldCB0cmFuc3BvcnQgbW9kdWxlLgpbICAg
MTIuMjk5ODYxXSBSUEM6IFJlZ2lzdGVyZWQgdWRwIHRyYW5zcG9ydCBtb2R1bGUuClsgICAx
Mi4yOTk4NjJdIFJQQzogUmVnaXN0ZXJlZCB0Y3AgdHJhbnNwb3J0IG1vZHVsZS4KWyAgIDEy
LjI5OTg2M10gUlBDOiBSZWdpc3RlcmVkIHRjcCBORlN2NC4xIGJhY2tjaGFubmVsIHRyYW5z
cG9ydCBtb2R1bGUuClsgICAxMi4zMDg2NTldIEZTLUNhY2hlOiBMb2FkZWQKWyAgIDEyLjMx
OTQyNV0gRlMtQ2FjaGU6IE5ldGZzICduZnMnIHJlZ2lzdGVyZWQgZm9yIGNhY2hpbmcKWyAg
IDEyLjMzNDU3OV0gSW5zdGFsbGluZyBrbmZzZCAoY29weXJpZ2h0IChDKSAxOTk2IG9raXJA
bW9uYWQuc3diLmRlKS4KWyAgIDEzLjM3OTkzNF0gYXg4ODE3OV8xNzhhIDItMzoxLjAgZXRo
MTogYXg4ODE3OSAtIExpbmsgc3RhdHVzIGlzOiAxClsgICAxMy4zODE3MjZdIElQdjY6IEFE
RFJDT05GKE5FVERFVl9DSEFOR0UpOiBldGgxOiBsaW5rIGJlY29tZXMgcmVhZHkKWyAgIDEz
LjM4MzQ2MF0geGVuYnIwOiBwb3J0IDEoZXRoMSkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRl
ClsgICAxMy4zODM0NzJdIHhlbmJyMDogcG9ydCAxKGV0aDEpIGVudGVyZWQgZm9yd2FyZGlu
ZyBzdGF0ZQpbICAgMTMuMzgzNDk0XSBJUHY2OiBBRERSQ09ORihORVRERVZfQ0hBTkdFKTog
eGVuYnIwOiBsaW5rIGJlY29tZXMgcmVhZHkKWyAgIDEzLjg1NDIwMF0gS2V5IHR5cGUgZG5z
X3Jlc29sdmVyIHJlZ2lzdGVyZWQKWyAgIDEzLjg2MTc0OV0gTkZTOiBSZWdpc3RlcmluZyB0
aGUgaWRfcmVzb2x2ZXIga2V5IHR5cGUKWyAgIDEzLjg2MTc2MF0gS2V5IHR5cGUgaWRfcmVz
b2x2ZXIgcmVnaXN0ZXJlZApbICAgMTMuODYxNzYxXSBLZXkgdHlwZSBpZF9sZWdhY3kgcmVn
aXN0ZXJlZApbICAgMTcuOTYzNTY0XSBpcF90YWJsZXM6IChDKSAyMDAwLTIwMDYgTmV0Zmls
dGVyIENvcmUgVGVhbQpbICAgMTguMzI4OTg2XSBCbHVldG9vdGg6IEJORVAgKEV0aGVybmV0
IEVtdWxhdGlvbikgdmVyIDEuMwpbICAgMTguMzI4OTkyXSBCbHVldG9vdGg6IEJORVAgZmls
dGVyczogcHJvdG9jb2wgbXVsdGljYXN0ClsgICAxOC4zMjkwMDNdIEJsdWV0b290aDogQk5F
UCBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgIDE4LjM1MDQ0M10gQmx1ZXRvb3RoOiBS
RkNPTU0gVFRZIGxheWVyIGluaXRpYWxpemVkClsgICAxOC4zNTA0NTldIEJsdWV0b290aDog
UkZDT01NIHNvY2tldCBsYXllciBpbml0aWFsaXplZApbICAgMTguMzUwNDY3XSBCbHVldG9v
dGg6IFJGQ09NTSB2ZXIgMS4xMQpbICAgMjIuODUzMjA4XSB4ZW46eGVuX2V2dGNobjogRXZl
bnQtY2hhbm5lbCBkZXZpY2UgaW5zdGFsbGVkClsgICAyMi45OTQ2MDddIHhlbl9wY2liYWNr
OiBiYWNrZW5kIGlzIHZwY2kKWyAgIDIzLjExMzA0OV0geGVuX2FjcGlfcHJvY2Vzc29yOiBV
cGxvYWRpbmcgWGVuIHByb2Nlc3NvciBQTSBpbmZvClsgICAyMy41MjgxOThdIGFoY2kgMDAw
MDowMDoxZi4yOiBwb3J0IGRvZXMgbm90IHN1cHBvcnQgZGV2aWNlIHNsZWVwClsgICAyOC40
MTYyODVdIHhlbmJyMDogcG9ydCAxKGV0aDEpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQpb
ICAgNDAuMzMzNTgyXSB0dW46IFVuaXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2ZXIsIDEu
NgpbICAgNDAuMzMzNTg3XSB0dW46IChDKSAxOTk5LTIwMDQgTWF4IEtyYXNueWFuc2t5IDxt
YXhrQHF1YWxjb21tLmNvbT4KWyAgIDQwLjQ4NjY1MV0gSVB2NjogQUREUkNPTkYoTkVUREVW
X1VQKTogdmlmMS4wOiBsaW5rIGlzIG5vdCByZWFkeQpbICAgNDAuNTg4NzYxXSBkZXZpY2Ug
dmlmMS4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQpbICAgNDAuNTkyNDQyXSBJUHY2OiBB
RERSQ09ORihORVRERVZfVVApOiB2aWYxLjA6IGxpbmsgaXMgbm90IHJlYWR5ClsgICA0MC43
NzI1MjZdIGRldmljZSB2aWYxLjAtZW11IGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQpbICAg
NDAuNzc2Mjg0XSB4ZW5icjA6IHBvcnQgMyh2aWYxLjAtZW11KSBlbnRlcmVkIGZvcndhcmRp
bmcgc3RhdGUKWyAgIDQwLjc3NjI5NV0geGVuYnIwOiBwb3J0IDModmlmMS4wLWVtdSkgZW50
ZXJlZCBmb3J3YXJkaW5nIHN0YXRlClsgICA1NS44MDg3NDddIHhlbmJyMDogcG9ydCAzKHZp
ZjEuMC1lbXUpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQpbICAgODYuNTU2OTY3XSB4ZW4t
YmxrYmFjazpyaW5nLXJlZiAxNjM4MywgZXZlbnQtY2hhbm5lbCA3LCBwcm90b2NvbCAxICh4
ODZfNjQtYWJpKSAKWyAgIDg5LjY1NDg2MF0gSVB2NjogQUREUkNPTkYoTkVUREVWX0NIQU5H
RSk6IHZpZjEuMDogbGluayBiZWNvbWVzIHJlYWR5ClsgICA4OS42NTQ5MTVdIHhlbmJyMDog
cG9ydCAyKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlClsgICA4OS42NTQ5Mjld
IHhlbmJyMDogcG9ydCAyKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlClsgIDEw
NC43MDU2ODhdIHhlbmJyMDogcG9ydCAyKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0
YXRlClsgIDIzMi40NTYxNjBdIGRldmljZS1tYXBwZXI6IHVldmVudDogdmVyc2lvbiAxLjAu
MwpbICAyMzIuNDU2NDAxXSBkZXZpY2UtbWFwcGVyOiBpb2N0bDogNC4yNy4wLWlvY3RsICgy
MDEzLTEwLTMwKSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAcmVkaGF0LmNvbQpbICAzMDAuMjE1
NTY4XSBFWFQ0LWZzIChzZGIxKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBk
YXRhIG1vZGUuIE9wdHM6IChudWxsKQpbMTA5OTguMjkyODk4XSBwY2liYWNrIDAwMDA6MDA6
MDAuMDogcHJvYmluZy4uLgpbMTA5OTguMjkyOTM1XSBwY2liYWNrIDAwMDA6MDA6MWYuMzog
cHJvYmluZy4uLgpbMTA5OTguMjkzMTE2XSB4ZW5fcGNpYmFjazogYmFja2VuZCBpcyB2cGNp
ClsxMTA0Ny4xMjU5MDhdIGdudGFsbG9jOiBkaXNhZ3JlZXMgYWJvdXQgdmVyc2lvbiBvZiBz
eW1ib2wgbW9kdWxlX2xheW91dApbMTExNTguMTIwMDExXSBlMTAwMGUgMDAwMDowMDoxOS4w
IGV0aDA6IHJlbW92ZWQgUEhDClsxMTE1OC4xNDEzNDhdIHhlbl9wY2liYWNrOiB3YW50cyB0
byBzZWl6ZSAwMDAwOjAwOjE5LjAKWzExMTU4LjE0MTM5NF0gcGNpYmFjayAwMDAwOjAwOjE5
LjA6IHByb2JpbmcuLi4KWzExMTU4LjE0MTM5OF0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IHNl
aXppbmcgZGV2aWNlClsxMTE1OC4xNDE0MDFdIHBjaWJhY2sgMDAwMDowMDoxOS4wOiBwY2lz
dHViX2RldmljZV9hbGxvYwpbMTExNTguMTQxNDA0XSBwY2liYWNrIDAwMDA6MDA6MTkuMDog
aW5pdGlhbGl6aW5nLi4uClsxMTE1OC4xNDE0MTNdIHBjaWJhY2sgMDAwMDowMDoxOS4wOiBp
bml0aWFsaXppbmcgY29uZmlnClsxMTE1OC4xNDE0NTZdIHBjaWJhY2sgMDAwMDowMDoxOS4w
OiBpbml0aWFsaXppbmcgdmlydHVhbCBjb25maWd1cmF0aW9uIHNwYWNlClsxMTE1OC4xNDE0
NjJdIHBjaWJhY2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0
IDB4MDAKWzExMTU4LjE0MTQ2NV0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZp
ZyBmaWVsZCBhdCBvZmZzZXQgMHgwMgpbMTExNTguMTQxNDY4XSBwY2liYWNrIDAwMDA6MDA6
MTkuMDogYWRkZWQgY29uZmlnIGZpZWxkIGF0IG9mZnNldCAweDA0ClsxMTE1OC4xNDE0NzFd
IHBjaWJhY2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4
M2MKWzExMTU4LjE0MTQ3NF0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBm
aWVsZCBhdCBvZmZzZXQgMHgzZApbMTExNTguMTQxNDc3XSBwY2liYWNrIDAwMDA6MDA6MTku
MDogYWRkZWQgY29uZmlnIGZpZWxkIGF0IG9mZnNldCAweDBjClsxMTE1OC4xNDE0ODNdIHBj
aWJhY2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4MGQK
WzExMTU4LjE0MTQ4Nl0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBmaWVs
ZCBhdCBvZmZzZXQgMHgwZgpbMTExNTguMTQxNDkwXSBwY2liYWNrIDAwMDA6MDA6MTkuMDog
YWRkZWQgY29uZmlnIGZpZWxkIGF0IG9mZnNldCAweDEwClsxMTE1OC4xNDE0OTVdIHBjaWJh
Y2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4MTQKWzEx
MTU4LjE0MTQ5OV0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBmaWVsZCBh
dCBvZmZzZXQgMHgxOApbMTExNTguMTQxNTAyXSBwY2liYWNrIDAwMDA6MDA6MTkuMDogYWRk
ZWQgY29uZmlnIGZpZWxkIGF0IG9mZnNldCAweDFjClsxMTE1OC4xNDE1MDddIHBjaWJhY2sg
MDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4MjAKWzExMTU4
LjE0MTUxMV0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBmaWVsZCBhdCBv
ZmZzZXQgMHgyNApbMTExNTguMTQxNTE1XSBwY2liYWNrIDAwMDA6MDA6MTkuMDogYWRkZWQg
Y29uZmlnIGZpZWxkIGF0IG9mZnNldCAweDMwClsxMTE1OC4xNDE1NTRdIHBjaWJhY2sgMDAw
MDowMDoxOS4wOiBGb3VuZCBjYXBhYmlsaXR5IDB4MSBhdCAweGM4ClsxMTE1OC4xNDE1NThd
IHBjaWJhY2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4
YzgKWzExMTU4LjE0MTU2MV0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBm
aWVsZCBhdCBvZmZzZXQgMHhjYQpbMTExNTguMTQxNTY4XSBwY2liYWNrIDAwMDA6MDA6MTku
MDogYWRkZWQgY29uZmlnIGZpZWxkIGF0IG9mZnNldCAweGNjClsxMTE1OC4xNDE1NzFdIHBj
aWJhY2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4Y2UK
WzExMTU4LjE0MTU3M10gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBmaWVs
ZCBhdCBvZmZzZXQgMHhjZgpbMTExNTguMTQxNTc2XSBwY2liYWNrIDAwMDA6MDA6MTkuMDog
ZW5hYmxpbmcgZGV2aWNlClsxMTE1OC4xNDE3MjVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDIw
IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsxMTE1OC4xNDE3MzFdIEFscmVhZHkgc2V0dXAg
dGhlIEdTSSA6MjAKWzExMTU4LjE0MTc0M10gcGNpYmFjayAwMDAwOjAwOjE5LjA6IHNhdmUg
c3RhdGUgb2YgZGV2aWNlClsxMTE1OC4xNDE4MTJdIHBjaWJhY2sgMDAwMDowMDoxOS4wOiBy
ZXNldHRpbmcgKEZMUiwgRDMsIGV0YykgdGhlIGRldmljZQpbMTExNTguMjQ0MzEwXSBwY2li
YWNrIDAwMDA6MDA6MTkuMDogcmVzZXQgZGV2aWNlClsxMTE1OS42NjY0OTRdIHhlbi1wY2li
YWNrIHBjaS0yLTA6IGFsbG9jYXRlZCBwZGV2IEAgMHhmZmZmODgwMGQ5ZjVmNTgwClsxMTE1
OS42NjgxODJdIHhlbi1wY2liYWNrIHBjaS0yLTA6IGdldHRpbmcgYmUgc2V0dXAKWzExMTU5
LjY2ODc4Nl0geGVuLXBjaWJhY2sgcGNpLTItMDogZXhwb3J0aW5nIGRvbSAwIGJ1cyAwIHNs
b3QgMTkgZnVuYyAwClsxMTE1OS42Njg3OTJdIHhlbl9wY2liYWNrOiB2cGNpOiAwMDAwOjAw
OjE5LjA6IGFzc2lnbiB0byB2aXJ0dWFsIHNsb3QgMApbMTExNTkuNjY4OTUzXSBwY2liYWNr
IDAwMDA6MDA6MTkuMDogcmVnaXN0ZXJpbmcgZm9yIDIKWzExMTU5LjY2OTM1OV0geGVuLXBj
aWJhY2sgcGNpLTItMDogUHVibGlzaGluZyBwY2kgcm9vdHMKWzExMTU5LjY2OTQ4NV0geGVu
LXBjaWJhY2sgcGNpLTItMDogd3JpdGluZyByb290IDAgYXQgMDAwMDowMApbMTExNTkuNjc2
ODY0XSB4ZW4tcGNpYmFjayBwY2ktMi0wOiBmZSBzdGF0ZSBjaGFuZ2VkIDEKWzExMTU5Ljcx
MjQ4Ml0geGVuLXBjaWJhY2sgcGNpLTItMDogZmUgc3RhdGUgY2hhbmdlZCAzClsxMTE1OS43
MTI5MDldIHhlbi1wY2liYWNrIHBjaS0yLTA6IFJlYWRpbmcgZnJvbnRlbmQgY29uZmlnClsx
MTE1OS43MTMyOTddIHhlbi1wY2liYWNrIHBjaS0yLTA6IEF0dGFjaGluZyB0byBmcm9udGVu
ZCByZXNvdXJjZXMgLSBnbnRfcmVmPTIwNDcgZXZ0Y2huPTQKWzExMTU5LjcxMzM0NF0geGVu
LXBjaWJhY2sgcGNpLTItMDogQXR0YWNoZWQhClsxMTE1OS43MTMzNDhdIHhlbi1wY2liYWNr
IHBjaS0yLTA6IENvbm5lY3RpbmcuLi4KWzExMTU5LjcxNTIwNF0geGVuLXBjaWJhY2sgcGNp
LTItMDogQ29ubmVjdGVkPyAwClsxMTE1OS43MTU4ODhdIHhlbi1wY2liYWNrIHBjaS0yLTA6
IGZlIHN0YXRlIGNoYW5nZWQgNApbMTExNTkuNzMyMjA3XSBwY2liYWNrIDAwMDA6MDA6MTku
MDogZW5hYmxpbmcgZGV2aWNlICgwMDAwIC0+IDAwMDMpClsxMTE1OS43MzIzNjNdIHhlbjog
cmVnaXN0ZXJpbmcgZ3NpIDIwIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsxMTE1OS43MzIz
NzBdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjAKWzExMTU5LjczMjM4OV0gcGNpYmFjayAw
MDAwOjAwOjE5LjA6IHhlbi1wY2liYWNrWzAwMDA6MDA6MTkuMF06ICMyMCBvbiAgZGlzYWJs
ZS0+IGVuYWJsZQpbMTExNTkuNzMyNDUxXSBwY2liYWNrIDAwMDA6MDA6MTkuMDogeGVuLXBj
aWJhY2tbMDAwMDowMDoxOS4wXTogIzIwIG9uICBlbmFibGVkClsxMTE4My43NDE2MTFdIHBj
aWJhY2sgMDAwMDowMDoxOS4wOiB4ZW4tcGNpYmFja1swMDAwOjAwOjE5LjBdOiAjMjAgb2Zm
ICBlbmFibGUtPiBkaXNhYmxlClsxMTE4My43NDE2NTFdIHBjaWJhY2sgMDAwMDowMDoxOS4w
OiB4ZW4tcGNpYmFja1swMDAwOjAwOjE5LjBdOiAjMCBvZmYgIGRpc2FibGVkClsxMTE4My43
NDIzNzNdIHhlbi1wY2liYWNrIHBjaS0yLTA6IGZlIHN0YXRlIGNoYW5nZWQgNQpbMTExODMu
NzQzNDUxXSB4ZW4tcGNpYmFjayBwY2ktMi0wOiBmZSBzdGF0ZSBjaGFuZ2VkIDYKWzExMTgz
Ljc0NDUwNV0geGVuLXBjaWJhY2sgcGNpLTItMDogZmUgc3RhdGUgY2hhbmdlZCAwClsxMTE4
My43NDQ1MTBdIHhlbi1wY2liYWNrIHBjaS0yLTA6IGZyb250ZW5kIGlzIGdvbmUhIHVucmVn
aXN0ZXIgZGV2aWNlClsxMTE4My44NDU5NzhdIHBjaWJhY2sgMDAwMDowMDoxOS4wOiByZXNl
dHRpbmcgdmlydHVhbCBjb25maWd1cmF0aW9uIHNwYWNlClsxMTE4My44NDU5OTFdIHBjaWJh
Y2sgMDAwMDowMDoxOS4wOiBmcmVlLWluZyBkeW5hbWljYWxseSBhbGxvY2F0ZWQgdmlydHVh
bCBjb25maWd1cmF0aW9uIHNwYWNlIGZpZWxkcwpbMTEyMTMuNzc5MDkzXSB4ZW4tcGNpYmFj
ayBwY2ktNC0wOiBhbGxvY2F0ZWQgcGRldiBAIDB4ZmZmZjg4MDAyY2Q5ZDA0MApbMTEyMTMu
NzgwNDM1XSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBnZXR0aW5nIGJlIHNldHVwClsxMTIxMy43
ODA2NzZdIHhlbi1wY2liYWNrIHBjaS00LTA6IGV4cG9ydGluZyBkb20gMCBidXMgMCBzbG90
IDE5IGZ1bmMgMApbMTEyMTMuNzgwNjgyXSB4ZW5fcGNpYmFjazogdnBjaTogMDAwMDowMDox
OS4wOiBhc3NpZ24gdG8gdmlydHVhbCBzbG90IDAKWzExMjEzLjc4MDg2MF0gcGNpYmFjayAw
MDAwOjAwOjE5LjA6IHJlZ2lzdGVyaW5nIGZvciA0ClsxMTIxMy43ODEyMTddIHhlbi1wY2li
YWNrIHBjaS00LTA6IFB1Ymxpc2hpbmcgcGNpIHJvb3RzClsxMTIxMy43ODE0ODFdIHhlbi1w
Y2liYWNrIHBjaS00LTA6IHdyaXRpbmcgcm9vdCAwIGF0IDAwMDA6MDAKWzExMjEzLjc5MDIx
Ml0geGVuLXBjaWJhY2sgcGNpLTQtMDogZmUgc3RhdGUgY2hhbmdlZCAxClsxMTIxMy44MTE0
NzhdIHhlbi1wY2liYWNrIHBjaS00LTA6IGZlIHN0YXRlIGNoYW5nZWQgMwpbMTEyMTMuODEx
Njc1XSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBSZWFkaW5nIGZyb250ZW5kIGNvbmZpZwpbMTEy
MTMuODEyMjgxXSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBBdHRhY2hpbmcgdG8gZnJvbnRlbmQg
cmVzb3VyY2VzIC0gZ250X3JlZj0yMDQ3IGV2dGNobj00ClsxMTIxMy44MTIzNDZdIHhlbi1w
Y2liYWNrIHBjaS00LTA6IEF0dGFjaGVkIQpbMTEyMTMuODEyMzUyXSB4ZW4tcGNpYmFjayBw
Y2ktNC0wOiBDb25uZWN0aW5nLi4uClsxMTIxMy44MTI5NzddIHhlbi1wY2liYWNrIHBjaS00
LTA6IENvbm5lY3RlZD8gMApbMTEyMTMuODEzMzkwXSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBm
ZSBzdGF0ZSBjaGFuZ2VkIDQKWzExMjEzLjgyODY2Ml0gcGNpYmFjayAwMDAwOjAwOjE5LjA6
IGVuYWJsaW5nIGRldmljZSAoMDAwMCAtPiAwMDAzKQpbMTEyMTMuODI4Nzc1XSB4ZW46IHJl
Z2lzdGVyaW5nIGdzaSAyMCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbMTEyMTMuODI4Nzgw
XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjIwClsxMTIxMy44Mjg3OTRdIHBjaWJhY2sgMDAw
MDowMDoxOS4wOiB4ZW4tcGNpYmFja1swMDAwOjAwOjE5LjBdOiAjMjAgb24gIGRpc2FibGUt
PiBlbmFibGUKWzExMjEzLjgyODg0M10gcGNpYmFjayAwMDAwOjAwOjE5LjA6IHhlbi1wY2li
YWNrWzAwMDA6MDA6MTkuMF06ICMyMCBvbiAgZW5hYmxlZApbMTEyMjAuODM4MjYzXSBwY2li
YWNrIDAwMDA6MDA6MTkuMDogeGVuLXBjaWJhY2tbMDAwMDowMDoxOS4wXTogIzIwIG9mZiAg
ZW5hYmxlLT4gZGlzYWJsZQpbMTEyMjAuODM4MzAyXSBwY2liYWNrIDAwMDA6MDA6MTkuMDog
eGVuLXBjaWJhY2tbMDAwMDowMDoxOS4wXTogIzAgb2ZmICBkaXNhYmxlZApbMTEyMjAuODM4
Nzg1XSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBmZSBzdGF0ZSBjaGFuZ2VkIDUKWzExMjIwLjgz
OTgyNF0geGVuLXBjaWJhY2sgcGNpLTQtMDogZmUgc3RhdGUgY2hhbmdlZCA2ClsxMTIyMC44
NDEzNjddIHhlbi1wY2liYWNrIHBjaS00LTA6IGZlIHN0YXRlIGNoYW5nZWQgMApbMTEyMjAu
ODQxMzcyXSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBmcm9udGVuZCBpcyBnb25lISB1bnJlZ2lz
dGVyIGRldmljZQpbMTEyMjAuOTQ0MDYwXSBwY2liYWNrIDAwMDA6MDA6MTkuMDogcmVzZXR0
aW5nIHZpcnR1YWwgY29uZmlndXJhdGlvbiBzcGFjZQpbMTEyMjAuOTQ0MDc4XSBwY2liYWNr
IDAwMDA6MDA6MTkuMDogZnJlZS1pbmcgZHluYW1pY2FsbHkgYWxsb2NhdGVkIHZpcnR1YWwg
Y29uZmlndXJhdGlvbiBzcGFjZSBmaWVsZHMK
------------0410070F03E0EB1B3
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0410070F03E0EB1B3--



From xen-devel-bounces@lists.xen.org Tue Nov 18 16:26:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1XqlbL-0005oF-AD; Tue, 18 Nov 2014 16:25:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1XqlbJ-0005o6-I6
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:25:58 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	46/52-18267-4137B645; Tue, 18 Nov 2014 16:25:56 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416327954!12244426!1
X-Originating-IP: [209.85.192.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30927 invoked from network); 18 Nov 2014 16:25:55 -0000
Received: from mail-qg0-f54.google.com (HELO mail-qg0-f54.google.com)
	(209.85.192.54)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:25:55 -0000
Received: by mail-qg0-f54.google.com with SMTP id q107so1101461qgd.41
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:25:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type;
	bh=ZsZsao1tgDsm7IjhAXn8b1wP1OLChG47SYfKW5B3sVQ=;
	b=jUm3nHMARvOwCs2y3FzNYzK8a8pRogcYUjdduCQvmKsIv3tdYIOkTs7CXK0keZONKg
	/hIf27nQupx0bdmSQptZZYlMsRwpzqyQYB4ppv8mxNZjLQlyRBkWKdlsG4FIPpyL/9jK
	aSAKUfMS28a9d/fkOiAzSp0AKGdt5z1omnl1KyQglvGBNXwreg6STTTjSsLvST2I1p0e
	7RLIH0y9bELIA2UpqVgb/Z5d925yzaOl5+SESYKSpuvE45zZtbDNezyAhGTKqWC6Y639
	bCRh8FK22JymfS84alU8K5LVG9eeRKpUsP2EMdf2LQZOeAX7Rgui1s0UUsflwla4gLty
	VRBA==
X-Received: by 10.224.88.134 with SMTP id a6mr44654999qam.28.1416327951938;
	Tue, 18 Nov 2014 08:25:51 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.99])
	by mx.google.com with ESMTPSA id 91sm30938839qgy.15.2014.11.18.08.25.46
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Tue, 18 Nov 2014 08:25:51 -0800 (PST)
Date: Tue, 18 Nov 2014 13:25:44 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <1335313968.20141118132544@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141113192915.GA12502@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<20141113190338.GB11211@laptop.dumpdata.com>
	<1747475571.20141113162148@gmail.com>
	<20141113192915.GA12502@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0410070F03E0EB1B3"
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0410070F03E0EB1B3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Konrad,

Thursday, November 13, 2014, 4:29:15 PM, you wrote:

> On Thu, Nov 13, 2014 at 04:21:48PM -0300, Simon Martin wrote:
>> Thanks Konrad,
>> 
>> Thursday, November 13, 2014, 4:03:38 PM, you wrote:
>> 
>> >> Yes I do verify the write. How do I check this from Dom0?
>> 
>> > You can crank up the debug volume in xen-pciback. Recompile the kernel
>> > and put '#define DEBUG 1' at the start of the .c files.
>> 
>> > Interestingly enough I saw this issue as well - and it looked to me
>> > that Xen pciback was stuck in '7' state (Reconfiguring) and never
>> > excited it.
>> 
>> > But I hadn't had a chance to dig in this.
>> 
>> This  might  be related to something that I reported a while ago, that
>> when   I   shutdown  the PV it takes a long time for the corresponding
>> Dom0 processes to stop.
>> 
>> I'll set the debug level and see what's going on. That'll be on Monday
>> now.

I attach the output from xl dmesg and dmesg. As far as I can see,
everything looks to be OK.


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com
------------0410070F03E0EB1B3
Content-Type: application/octet-stream;
 name=xl_dmesg
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename=xl_dmesg

IFhlbiA0LjUuMC1yYwooWEVOKSBYZW4gdmVyc2lvbiA0LjUuMC1yYyAocm9vdEBuZW1vLmNs
KSAoZ2NjIChEZWJpYW4gNC43LjItNSkgNC43LjIpIGRlYnVnPXkgTW9uIE5vdiAxNyAxNjoy
NDo0MCBDTFNUIDIwMTQKKFhFTikgTGF0ZXN0IENoYW5nZVNldDogVGh1IE5vdiA2IDEwOjQx
OjI4IDIwMTQgKzAwMDAgZ2l0OmU2ZmE2M2QtZGlydHkKKFhFTikgQm9vdGxvYWRlcjogR1JV
QiAxLjk5LTI3K2RlYjd1MgooWEVOKSBDb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVyIHRpbWVy
X3Nsb3A9MCBkb20wX21heF92Y3B1cz0yIGRvbTBfdmNwdXNfcGluIGxvZ2x2bD1hbGwgaW9t
bXU9ZGVidWcKKFhFTikgVmlkZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBt
b2RlIDgweDI1LCBmb250IDh4MTYKKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQg
dHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4p
ICBGb3VuZCAyIE1CUiBzaWduYXR1cmVzCihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlv
biBzdHJ1Y3R1cmVzCihYRU4pIFhlbi1lODIwIFJBTSBtYXA6CihYRU4pICAwMDAwMDAwMDAw
MDAwMDAwIC0gMDAwMDAwMDAwMDA5ZDgwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDAwMDA5
ZDgwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDBl
MDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDEw
MDAwMCAtIDAwMDAwMDAwYzg1MjIwMDAgKHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwYzg1MjIw
MDAgLSAwMDAwMDAwMGM4NTI5MDAwIChBQ1BJIE5WUykKKFhFTikgIDAwMDAwMDAwYzg1Mjkw
MDAgLSAwMDAwMDAwMGRiYTg1MDAwICh1c2FibGUpCihYRU4pICAwMDAwMDAwMGRiYTg1MDAw
IC0gMDAwMDAwMDBkYmIwZjAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGRiYjBmMDAw
IC0gMDAwMDAwMDBkYmIyOTAwMCAoQUNQSSBkYXRhKQooWEVOKSAgMDAwMDAwMDBkYmIyOTAw
MCAtIDAwMDAwMDAwZGJjOTIwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBkYmM5MjAw
MCAtIDAwMDAwMDAwZGJmZmYwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBkYmZmZjAw
MCAtIDAwMDAwMDAwZGMwMDAwMDAgKHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwZGQwMDAwMDAg
LSAwMDAwMDAwMGRmMjAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZjgwMDAwMDAg
LSAwMDAwMDAwMGZjMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVjMDAwMDAg
LSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVkMDAwMDAg
LSAwMDAwMDAwMGZlZDA0MDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVkMWMwMDAg
LSAwMDAwMDAwMGZlZDIwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVlMDAwMDAg
LSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmYwMDAwMDAg
LSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAg
LSAwMDAwMDAwMTFmZTAwMDAwICh1c2FibGUpCihYRU4pIEFDUEk6IFJTRFAgMDAwRjA0OTAs
IDAwMjQgKHIyICBJTlRFTCkKKFhFTikgQUNQSTogWFNEVCBEQkIxNDA4MCwgMDA4NCAocjEg
SU5URUwgIEQzNDAxMFdZICAgICAgIDE2IEFNSSAgICAgMTAwMTMpCihYRU4pIEFDUEk6IEZB
Q1AgREJCMjNBMDgsIDAxMEMgKHI1IElOVEVMICBEMzQwMTBXWSAgICAgICAxNiBBTUkgICAg
IDEwMDEzKQooWEVOKSBBQ1BJOiBEU0RUIERCQjE0MTk4LCBGODcwIChyMiBJTlRFTCAgRDM0
MDEwV1kgICAgICAgMTYgSU5UTCAyMDEyMDcxMSkKKFhFTikgQUNQSTogRkFDUyBEQkM5MDA4
MCwgMDA0MAooWEVOKSBBQ1BJOiBBUElDIERCQjIzQjE4LCAwMDcyIChyMyBJTlRFTCAgRDM0
MDEwV1kgICAgICAgMTYgQU1JICAgICAxMDAxMykKKFhFTikgQUNQSTogRlBEVCBEQkIyM0I5
MCwgMDA0NCAocjEgSU5URUwgIEQzNDAxMFdZICAgICAgIDE2IEFNSSAgICAgMTAwMTMpCihY
RU4pIEFDUEk6IExQSVQgREJCMjNCRDgsIDAwNUMgKHIxIElOVEVMICBEMzQwMTBXWSAgICAg
ICAxNiBBTUkuICAgICAgICA1KQooWEVOKSBBQ1BJOiBTU0RUIERCQjIzQzM4LCAwNDk0IChy
MSBJTlRFTCAgRDM0MDEwV1kgICAgICAgMTYgSU5UTCAyMDEyMDcxMSkKKFhFTikgQUNQSTog
U1NEVCBEQkIyNDBEMCwgMEFEOCAocjEgSU5URUwgIEQzNDAxMFdZICAgICAgIDE2IElOVEwg
MjAxMjA3MTEpCihYRU4pIEFDUEk6IE1DRkcgREJCMjRCQTgsIDAwM0MgKHIxIElOVEVMICBE
MzQwMTBXWSAgICAgICAxNiBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBIUEVUIERCQjI0
QkU4LCAwMDM4IChyMSBJTlRFTCAgRDM0MDEwV1kgICAgICAgMTYgQU1JLiAgICAgICAgNSkK
KFhFTikgQUNQSTogU1NEVCBEQkIyNEMyMCwgMDMxNSAocjEgSU5URUwgIEQzNDAxMFdZICAg
ICAgIDE2IElOVEwgMjAxMjA3MTEpCihYRU4pIEFDUEk6IFNTRFQgREJCMjRGMzgsIDMwMDQg
KHIxIElOVEVMICBEMzQwMTBXWSAgICAgICAxNiBJTlRMIDIwMDkxMTEyKQooWEVOKSBBQ1BJ
OiBETUFSIERCQjI3RjQwLCAwMTkwIChyMSBJTlRFTCAgRDM0MDEwV1kgICAgICAgMTYgSU5U
TCAgICAgICAgMSkKKFhFTikgQUNQSTogQ1NSVCBEQkIyODBEMCwgMDBDNCAocjEgSU5URUwg
IEQzNDAxMFdZICAgICAgIDE2IElOVEwgMjAxMDA1MjgpCihYRU4pIFN5c3RlbSBSQU06IDQw
MjRNQiAoNDEyMDY4OGtCKQooWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQKKFhF
TikgRmFraW5nIGEgbm9kZSBhdCAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAxMWZlMDAwMDAK
KFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQKKFhFTikgZm91bmQgU01QIE1QLXRhYmxl
IGF0IDAwMGZkNzIwCihYRU4pIERNSSAyLjcgcHJlc2VudC4KKFhFTikgVXNpbmcgQVBJQyBk
cml2ZXIgZGVmYXVsdAooWEVOKSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDE4MDgKKFhF
TikgQUNQSTogdjUgU0xFRVAgSU5GTzogY29udHJvbFswOjBdLCBzdGF0dXNbMDowXQooWEVO
KSBBQ1BJOiBTTEVFUCBJTkZPOiBwbTF4X2NudFsxOjE4MDQsMTowXSwgcG0xeF9ldnRbMTox
ODAwLDE6MF0KKFhFTikgQUNQSTogMzIvNjRYIEZBQ1MgYWRkcmVzcyBtaXNtYXRjaCBpbiBG
QURUIC0gZGJjOTAwODAvMDAwMDAwMDAwMDAwMDAwMCwgdXNpbmcgMzIKKFhFTikgQUNQSTog
ICAgICAgICAgICAgd2FrZXVwX3ZlY1tkYmM5MDA4Y10sIHZlY19zaXplWzIwXQooWEVOKSBB
Q1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMAooWEVOKSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3Ig
IzAgNjo1IEFQSUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAy
XSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzIgNjo1IEFQSUMg
dmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsw
eDAxXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzEgNjo1IEFQSUMgdmVyc2lvbiAyMQoo
WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAzXSBlbmFibGVk
KQooWEVOKSBQcm9jZXNzb3IgIzMgNjo1IEFQSUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBM
QVBJQ19OTUkgKGFjcGlfaWRbMHhmZl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQ
STogSU9BUElDIChpZFsweDAyXSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQoo
WEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgMiwgdmVyc2lvbiAzMiwgYWRkcmVzcyAweGZlYzAw
MDAwLCBHU0kgMC0zOQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAw
IGdsb2JhbF9pcnEgMiBkZmwgZGZsKQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAg
YnVzX2lycSA5IGdsb2JhbF9pcnEgOSBoaWdoIGxldmVsKQooWEVOKSBBQ1BJOiBJUlEwIHVz
ZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4KKFhF
TikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBFbmFibGluZyBBUElDIG1v
ZGU6ICBGbGF0LiAgVXNpbmcgMSBJL08gQVBJQ3MKKFhFTikgQUNQSTogSFBFVCBpZDogMHg4
MDg2YTcwMSBiYXNlOiAweGZlZDAwMDAwCihYRU4pIFtWVC1EXWRtYXIuYzo3ODg6IEhvc3Qg
YWRkcmVzcyB3aWR0aCAzOQooWEVOKSBbVlQtRF1kbWFyLmM6ODAyOiBmb3VuZCBBQ1BJX0RN
QVJfRFJIRDoKKFhFTikgW1ZULURdZG1hci5jOjQ3MjogICBkbWFydS0+YWRkcmVzcyA9IGZl
ZDkwMDAwCihYRU4pIFtWVC1EXWlvbW11LmM6MTE0NjogZHJoZC0+YWRkcmVzcyA9IGZlZDkw
MDAwIGlvbW11LT5yZWcgPSBmZmZmODJjMDAwMjAxMDAwCihYRU4pIFtWVC1EXWlvbW11LmM6
MTE0ODogY2FwID0gYzAwMDAwMjA2NjA0NjIgZWNhcCA9IGYwMTAxYQooWEVOKSBbVlQtRF1k
bWFyLmM6MzgzOiAgZW5kcG9pbnQ6IDAwMDA6MDA6MDIuMAooWEVOKSBbVlQtRF1kbWFyLmM6
ODAyOiBmb3VuZCBBQ1BJX0RNQVJfRFJIRDoKKFhFTikgW1ZULURdZG1hci5jOjQ3MjogICBk
bWFydS0+YWRkcmVzcyA9IGZlZDkxMDAwCihYRU4pIFtWVC1EXWlvbW11LmM6MTE0NjogZHJo
ZC0+YWRkcmVzcyA9IGZlZDkxMDAwIGlvbW11LT5yZWcgPSBmZmZmODJjMDAwMjAzMDAwCihY
RU4pIFtWVC1EXWlvbW11LmM6MTE0ODogY2FwID0gZDIwMDgwMjA2NjA0NjIgZWNhcCA9IGYw
MTBkYQooWEVOKSBbVlQtRF1kbWFyLmM6Mzk3OiAgSU9BUElDOiAwMDAwOmYwOjFmLjAKKFhF
TikgW1ZULURdZG1hci5jOjM2MTogIE1TSSBIUEVUOiAwMDAwOmYwOjBmLjAKKFhFTikgW1ZU
LURdVW5rbm93biBzY29wZSB0eXBlIDB4NQooWEVOKSBbVlQtRF1Vbmtub3duIHNjb3BlIHR5
cGUgMHg1CihYRU4pIFtWVC1EXVVua25vd24gc2NvcGUgdHlwZSAweDUKKFhFTikgW1ZULURd
VW5rbm93biBzY29wZSB0eXBlIDB4NQooWEVOKSBbVlQtRF1Vbmtub3duIHNjb3BlIHR5cGUg
MHg1CihYRU4pIFtWVC1EXVVua25vd24gc2NvcGUgdHlwZSAweDUKKFhFTikgW1ZULURdVW5r
bm93biBzY29wZSB0eXBlIDB4NQooWEVOKSBbVlQtRF1kbWFyLmM6NDg2OiAgIGZsYWdzOiBJ
TkNMVURFX0FMTAooWEVOKSBbVlQtRF1kbWFyLmM6ODA3OiBmb3VuZCBBQ1BJX0RNQVJfUk1S
UjoKKFhFTikgW1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFkLjAKKFhF
TikgW1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjE0LjAKKFhFTikgW1ZU
LURdZG1hci5jOjY3NjogICBSTVJSIHJlZ2lvbjogYmFzZV9hZGRyIGRiZWIxMDAwIGVuZF9h
ZGRyZXNzIGRiZWJmZmZmCihYRU4pIFtWVC1EXWRtYXIuYzo4MDc6IGZvdW5kIEFDUElfRE1B
Ul9STVJSOgooWEVOKSBbVlQtRF1kbWFyLmM6MzgzOiAgZW5kcG9pbnQ6IDAwMDA6MDA6MDIu
MAooWEVOKSBbVlQtRF1kbWFyLmM6Njc2OiAgIFJNUlIgcmVnaW9uOiBiYXNlX2FkZHIgZGQw
MDAwMDAgZW5kX2FkZHJlc3MgZGYxZmZmZmYKKFhFTikgW1ZULURdZG1hci5jOjgyMzogSWdu
b3JlIHVua25vd24gRE1BUiBzdHJ1Y3R1cmUgdHlwZSAoMHg0KQooWEVOKSBFUlNUIHRhYmxl
IHdhcyBub3QgZm91bmQKKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1
cmF0aW9uIGluZm9ybWF0aW9uCihYRU4pIFNNUDogQWxsb3dpbmcgNCBDUFVzICgwIGhvdHBs
dWcgQ1BVcykKKFhFTikgSVJRIGxpbWl0czogNDAgR1NJLCA3NDQgTVNJL01TSS1YCihYRU4p
IFN3aXRjaGVkIHRvIEFQSUMgZHJpdmVyIHgyYXBpY19jbHVzdGVyLgooWEVOKSBVc2luZyBz
Y2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVkaXQpCihYRU4pIERldGVjdGVk
IDE2OTYuMTQ2IE1IeiBwcm9jZXNzb3IuCihYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcu
CihYRU4pIHhzdGF0ZV9pbml0OiB1c2luZyBjbnR4dF9zaXplOiAweDM0MCBhbmQgc3RhdGVz
OiAweDcKKFhFTikgbWNlX2ludGVsLmM6NzE5OiBNQ0EgQ2FwYWJpbGl0eTogQkNBU1QgMSBT
RVIgMCBDTUNJIDEgZmlyc3RiYW5rIDAgZXh0ZW5kZWQgTUNFIE1TUiAwCihYRU4pIEludGVs
IG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQKKFhFTikgYWx0IHRhYmxlIGZmZmY4
MmQwODAyZDhjZjAgLT4gZmZmZjgyZDA4MDJkOWQxMAooWEVOKSBQQ0k6IE1DRkcgY29uZmln
dXJhdGlvbiAwOiBiYXNlIGY4MDAwMDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIDNmCihY
RU4pIFBDSTogTUNGRyBhcmVhIGF0IGY4MDAwMDAwIHJlc2VydmVkIGluIEU4MjAKKFhFTikg
UENJOiBVc2luZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAwLTNmCihYRU4pIEludGVs
IFZULWQgaW9tbXUgMCBzdXBwb3J0ZWQgcGFnZSBzaXplczogNGtCLgooWEVOKSBJbnRlbCBW
VC1kIGlvbW11IDEgc3VwcG9ydGVkIHBhZ2Ugc2l6ZXM6IDRrQi4KKFhFTikgSW50ZWwgVlQt
ZCBTbm9vcCBDb250cm9sIG5vdCBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIERvbTAgRE1B
IFBhc3N0aHJvdWdoIG5vdCBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIFF1ZXVlZCBJbnZh
bGlkYXRpb24gZW5hYmxlZC4KKFhFTikgSW50ZWwgVlQtZCBJbnRlcnJ1cHQgUmVtYXBwaW5n
IGVuYWJsZWQuCihYRU4pIEludGVsIFZULWQgU2hhcmVkIEVQVCB0YWJsZXMgbm90IGVuYWJs
ZWQuCihYRU4pIEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVkCihYRU4pICAtIERvbTAgbW9k
ZTogUmVsYXhlZAooWEVOKSBJbnRlcnJ1cHQgcmVtYXBwaW5nIGVuYWJsZWQKKFhFTikgRW5h
YmxlZCBkaXJlY3RlZCBFT0kgd2l0aCBpb2FwaWNfYWNrX29sZCBvbiEKKFhFTikgRU5BQkxJ
TkcgSU8tQVBJQyBJUlFzCihYRU4pICAtPiBVc2luZyBvbGQgQUNLIG1ldGhvZAooWEVOKSAu
LlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCihY
RU4pIFRTQyBkZWFkbGluZSB0aW1lciBlbmFibGVkCihYRU4pIFBsYXRmb3JtIHRpbWVyIGlz
IDE0LjMxOE1IeiBIUEVUCihYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcgb2YgMzIgS2lC
LgooWEVOKSBtd2FpdC1pZGxlOiBNV0FJVCBzdWJzdGF0ZXM6IDB4MTExNDIxMjAKKFhFTikg
bXdhaXQtaWRsZTogdjAuNCBtb2RlbCAweDQ1CihYRU4pIG13YWl0LWlkbGU6IGxhcGljX3Rp
bWVyX3JlbGlhYmxlX3N0YXRlcyAweGZmZmZmZmZmCihYRU4pIG13YWl0LWlkbGU6IG1heCBD
LXN0YXRlIGNvdW50IG9mIDggcmVhY2hlZAooWEVOKSBWTVg6IFN1cHBvcnRlZCBhZHZhbmNl
ZCBmZWF0dXJlczoKKFhFTikgIC0gQVBJQyBNTUlPIGFjY2VzcyB2aXJ0dWFsaXNhdGlvbgoo
WEVOKSAgLSBBUElDIFRQUiBzaGFkb3cKKFhFTikgIC0gRXh0ZW5kZWQgUGFnZSBUYWJsZXMg
KEVQVCkKKFhFTikgIC0gVmlydHVhbC1Qcm9jZXNzb3IgSWRlbnRpZmllcnMgKFZQSUQpCihY
RU4pICAtIFZpcnR1YWwgTk1JCihYRU4pICAtIE1TUiBkaXJlY3QtYWNjZXNzIGJpdG1hcAoo
WEVOKSAgLSBVbnJlc3RyaWN0ZWQgR3Vlc3QKKFhFTikgSFZNOiBBU0lEcyBlbmFibGVkLgoo
WEVOKSBIVk06IFZNWCBlbmFibGVkCihYRU4pIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFn
aW5nIChIQVApIGRldGVjdGVkCihYRU4pIEhWTTogSEFQIHBhZ2Ugc2l6ZXM6IDRrQiwgMk1C
LCAxR0IKKFhFTikgbXdhaXQtaWRsZTogbWF4IEMtc3RhdGUgY291bnQgb2YgOCByZWFjaGVk
CihYRU4pIG13YWl0LWlkbGU6IG1heCBDLXN0YXRlIGNvdW50IG9mIDggcmVhY2hlZAooWEVO
KSBtd2FpdC1pZGxlOiBtYXggQy1zdGF0ZSBjb3VudCBvZiA4IHJlYWNoZWQKKFhFTikgQnJv
dWdodCB1cCA0IENQVXMKKFhFTikgQUNQSSBzbGVlcCBtb2RlczogUzMKKFhFTikgbWNoZWNr
X3BvbGw6IE1hY2hpbmUgY2hlY2sgcG9sbGluZyB0aW1lciBzdGFydGVkLgooWEVOKSAqKiog
TE9BRElORyBET01BSU4gMCAqKioKKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFk
ZHI9MHgxMDAwMDAwIG1lbXN6PTB4N2M4MDAwCihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBo
ZHI6IHBhZGRyPTB4MTgwMDAwMCBtZW1zej0weGViMDAwCihYRU4pIGVsZl9wYXJzZV9iaW5h
cnk6IHBoZHI6IHBhZGRyPTB4MThlYjAwMCBtZW1zej0weDE0ZWMwCihYRU4pIGVsZl9wYXJz
ZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTkwMDAwMCBtZW1zej0weDYxNTAwMAooWEVOKSBl
bGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAtPiAweDFmMTUwMDAKKFhFTikg
ZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9PUyA9ICJsaW51eCIKKFhFTikgZWxmX3hlbl9w
YXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiIKKFhFTikgZWxmX3hlbl9wYXJzZV9u
b3RlOiBYRU5fVkVSU0lPTiA9ICJ4ZW4tMy4wIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6
IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMAooWEVOKSBlbGZfeGVuX3BhcnNlX25v
dGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxOTAwMWYwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90
ZTogSFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDAKKFhFTikgZWxmX3hlbl9w
YXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIhd3JpdGFibGVfcGFnZV90YWJsZXN8cGFlX3BnZGly
X2Fib3ZlXzRnYnx3cml0YWJsZV9kZXNjcmlwdG9yX3RhYmxlc3xhdXRvX3RyYW5zbGF0ZWRf
cGh5c21hcHxzdXBlcnZpc29yX21vZGVfa2VybmVsIgooWEVOKSBlbGZfeGVuX3BhcnNlX25v
dGU6IFNVUFBPUlRFRF9GRUFUVVJFUyA9IDB4OTBkCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90
ZTogUEFFX01PREUgPSAieWVzIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURFUiA9
ICJnZW5lcmljIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBu
b3RlICgweGQpCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAw
eDEKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBIVl9TVEFSVF9MT1cgPSAweGZmZmY4MDAw
MDAwMDAwMDAKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDAK
KFhFTikgZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoKKFhFTikgICAgIHZp
cnRfYmFzZSAgICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgICAgIGVsZl9wYWRk
cl9vZmZzZXQgPSAweDAKKFhFTikgICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweGZmZmZmZmZm
ODAwMDAwMDAKKFhFTikgICAgIHZpcnRfa3N0YXJ0ICAgICAgPSAweGZmZmZmZmZmODEwMDAw
MDAKKFhFTikgICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZmZmZmODFmMTUwMDAKKFhF
TikgICAgIHZpcnRfZW50cnkgICAgICAgPSAweGZmZmZmZmZmODE5MDAxZjAKKFhFTikgICAg
IHAybV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYKKFhFTikgIFhlbiAga2Vy
bmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIKKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQs
IFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHgxZjE1MDAwCihYRU4pIFBIWVNJQ0FM
IE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAxMTQw
MDAwMDAtPjAwMDAwMDAxMTgwMDAwMDAgKDk1NDA3MyBwYWdlcyB0byBiZSBhbGxvY2F0ZWQp
CihYRU4pICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMTFkMzY2MDAwLT4wMDAwMDAwMTFmZGZm
YTAwCihYRU4pIFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgTG9hZGVkIGtl
cm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MWYxNTAwMAooWEVOKSAgSW5pdC4g
cmFtZGlzazogZmZmZmZmZmY4MWYxNTAwMC0+ZmZmZmZmZmY4NDlhZWEwMAooWEVOKSAgUGh5
cy1NYWNoIG1hcDogZmZmZmZmZmY4NDlhZjAwMC0+ZmZmZmZmZmY4NTEyYmI5OAooWEVOKSAg
U3RhcnQgaW5mbzogICAgZmZmZmZmZmY4NTEyYzAwMC0+ZmZmZmZmZmY4NTEyYzRiNAooWEVO
KSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4NTEyZDAwMC0+ZmZmZmZmZmY4NTE1YTAwMAoo
WEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4NTE1YTAwMC0+ZmZmZmZmZmY4NTE1YjAw
MAooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NTQw
MDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MTkwMDFmMAooWEVOKSBEb20w
IGhhcyBtYXhpbXVtIDIgVkNQVXMKKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQg
MHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MTdjODAwMAooWEVOKSBlbGZfbG9h
ZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODE4MDAwMDAgLT4gMHhmZmZmZmZmZjgx
OGViMDAwCihYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAyIGF0IDB4ZmZmZmZmZmY4MThl
YjAwMCAtPiAweGZmZmZmZmZmODE4ZmZlYzAKKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRy
IDMgYXQgMHhmZmZmZmZmZjgxOTAwMDAwIC0+IDB4ZmZmZmZmZmY4MWExZTAwMAooWEVOKSBb
VlQtRF1pb21tdS5jOjE0MzA6IGQwOkhvc3RicmlkZ2U6IHNraXAgMDAwMDowMDowMC4wIG1h
cAooWEVOKSBCb2d1cyBETUlCQVIgMHhmZWQxODAwMSBvbiAwMDAwOjAwOjAwLjAKKFhFTikg
W1ZULURdaW9tbXUuYzoxNDU2OiBkMDpQQ0k6IG1hcCAwMDAwOjAwOjAyLjAKKFhFTikgW1ZU
LURdaW9tbXUuYzoxNDQ0OiBkMDpQQ0llOiBtYXAgMDAwMDowMDowMy4wCihYRU4pIFtWVC1E
XWlvbW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxNC4wCihYRU4pIFtWVC1EXWlv
bW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxNi4wCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxOS4wCihYRU4pIFtWVC1EXWlvbW11LmM6
MTQ0NDogZDA6UENJZTogbWFwIDAwMDA6MDA6MWIuMAooWEVOKSBbVlQtRF1pb21tdS5jOjE0
NTY6IGQwOlBDSTogbWFwIDAwMDA6MDA6MWQuMAooWEVOKSBbVlQtRF1pb21tdS5jOjE0NTY6
IGQwOlBDSTogbWFwIDAwMDA6MDA6MWYuMAooWEVOKSBbVlQtRF1pb21tdS5jOjE0NTY6IGQw
OlBDSTogbWFwIDAwMDA6MDA6MWYuMgooWEVOKSBbVlQtRF1pb21tdS5jOjE0NTY6IGQwOlBD
STogbWFwIDAwMDA6MDA6MWYuMwooWEVOKSBbVlQtRF1pb21tdS5jOjE0NDQ6IGQwOlBDSWU6
IG1hcCAwMDAwOjAyOjAwLjAKKFhFTikgW1ZULURdaW9tbXUuYzo3Mzk6IGlvbW11X2VuYWJs
ZV90cmFuc2xhdGlvbjogaW9tbXUtPnJlZyA9IGZmZmY4MmMwMDAyMDEwMDAKKFhFTikgW1ZU
LURdaW9tbXUuYzo3Mzk6IGlvbW11X2VuYWJsZV90cmFuc2xhdGlvbjogaW9tbXUtPnJlZyA9
IGZmZmY4MmMwMDAyMDMwMDAKKFhFTikgU2NydWJiaW5nIEZyZWUgUkFNIG9uIDEgbm9kZXMg
dXNpbmcgMiBDUFVzCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuCihYRU4pIEluaXRp
YWwgbG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgooWEVO
KSBTdGQuIExvZ2xldmVsOiBBbGwKKFhFTikgR3Vlc3QgTG9nbGV2ZWw6IEFsbAooWEVOKSBY
ZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4KKFhFTikgKioqIFNlcmlhbCBpbnB1
dCAtPiBET00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0
byBYZW4pCihYRU4pIEZyZWVkIDI5MmtCIGluaXQgbWVtb3J5LgooWEVOKSBCb2d1cyBETUlC
QVIgMHhmZWQxODAwMSBvbiAwMDAwOjAwOjAwLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw
MDowMDowMC4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDIuMAooWEVOKSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjAzLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
NC4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTYuMAooWEVOKSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjE5LjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxYi4wCihY
RU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MWMuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAw
MDAwOjAwOjFjLjMKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxZC4wCihYRU4pIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDA6MWYuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw
OjFmLjIKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxZi4zCihYRU4pIFBDSSBhZGQg
ZGV2aWNlIDAwMDA6MDI6MDAuMAooWEVOKSB0cmFwcy5jOjMxNTE6IEdQRiAoMDAwMCk6IGZm
ZmY4MmQwODAxOTI1OTYgLT4gZmZmZjgyZDA4MDIzNWQzMQooWEVOKSB0cmFwcy5jOjI1Nzk6
ZDB2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwMDAwMDAwNzkgZnJvbSAweDAw
MDAwMDAwMDAwMDAwMDAgdG8gMHhmZmZmYzkwMDAwNmYzMDMwLgooWEVOKSB0cmFwcy5jOjMx
NTE6IEdQRiAoMDAwMCk6IGZmZmY4MmQwODAxOTI1OTYgLT4gZmZmZjgyZDA4MDIzNWQzMQoo
WEVOKSB0cmFwcy5jOjI1Nzk6ZDB2MSBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAw
MDAwMDAwNzkgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHhmZmZmYzkwMDA0NzkzMDMw
LgooWEVOKSB0cmFwcy5jOjMxNTE6IEdQRiAoMDAwMCk6IGZmZmY4MmQwODAxOTI5MzUgLT4g
ZmZmZjgyZDA4MDIzNWQ1NwooWEVOKSB0cmFwcy5jOjMxNTE6IEdQRiAoMDAwMCk6IGZmZmY4
MmQwODAxOTI5MzUgLT4gZmZmZjgyZDA4MDIzNWQ1NwooWEVOKSB0cmFwcy5jOjMxNTE6IEdQ
RiAoMDAwMCk6IGZmZmY4MmQwODAxOTI5MzUgLT4gZmZmZjgyZDA4MDIzNWQ1NwooWEVOKSB0
cmFwcy5jOjMxNTE6IEdQRiAoMDAwMCk6IGZmZmY4MmQwODAxOTI5MzUgLT4gZmZmZjgyZDA4
MDIzNWQ1NwooZDEpIEhWTSBMb2FkZXIKKGQxKSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJjCihk
MSkgWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBldmVudCBjaGFubmVsIDEKKGQxKSBTeXN0
ZW0gcmVxdWVzdGVkIFNlYUJJT1MKKGQxKSBDUFUgc3BlZWQgaXMgMTY5NiBNSHoKKGQxKSBS
ZWxvY2F0aW5nIGd1ZXN0IG1lbW9yeSBmb3IgbG93bWVtIE1NSU8gc3BhY2UgZGlzYWJsZWQK
KFhFTikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUKKGQxKSBQ
Q0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJRNQooWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJ
IGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKKGQxKSBQQ0ktSVNBIGxpbmsgMSByb3V0ZWQgdG8g
SVJRMTAKKFhFTikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDIgY2hhbmdlZCAwIC0+IDEx
CihkMSkgUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExCihYRU4pIGlycS5jOjI3MDog
RG9tMSBQQ0kgbGluayAzIGNoYW5nZWQgMCAtPiA1CihkMSkgUENJLUlTQSBsaW5rIDMgcm91
dGVkIHRvIElSUTUKKGQxKSBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTAKKGQxKSBwY2kgZGV2
IDAyOjAgSU5UQS0+SVJRMTEKKGQxKSBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQooZDEpIE5v
IFJBTSBpbiBoaWdoIG1lbW9yeTsgc2V0dGluZyBoaWdoX21lbSByZXNvdXJjZSBiYXNlIHRv
IDEwMDAwMDAwMAooZDEpIHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDIwMDAwMDA6IDBm
MDAwMDAwOAooZDEpIHBjaSBkZXYgMDI6MCBiYXIgMTQgc2l6ZSAwMDEwMDAwMDA6IDBmMjAw
MDAwOAooZDEpIHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAwNDAwMDA6IDBmMzAwMDAw
MAooZDEpIHBjaSBkZXYgMDM6MCBiYXIgMzAgc2l6ZSAwMDAwMTAwMDA6IDBmMzA0MDAwMAoo
ZDEpIHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDA6IDBmMzA1MDAwMAooZDEp
IHBjaSBkZXYgMDI6MCBiYXIgMTAgc2l6ZSAwMDAwMDAxMDA6IDAwMDAwYzAwMQooZDEpIHBj
aSBkZXYgMDQ6MCBiYXIgMTAgc2l6ZSAwMDAwMDAxMDA6IDAwMDAwYzEwMQooZDEpIHBjaSBk
ZXYgMDQ6MCBiYXIgMTQgc2l6ZSAwMDAwMDAxMDA6IDBmMzA1MTAwMAooZDEpIHBjaSBkZXYg
MDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAwMTA6IDAwMDAwYzIwMQooZDEpIE11bHRpcHJvY2Vz
c29yIGluaXRpYWxpc2F0aW9uOgooZDEpICAtIENQVTAgLi4uIDM5LWJpdCBwaHlzIC4uLiBm
aXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLgooZDEpICAtIENQVTEg
Li4uIDM5LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4u
LiBkb25lLgooZDEpIFRlc3RpbmcgSFZNIGVudmlyb25tZW50OgooZDEpICAtIFJFUCBJTlNC
IGFjcm9zcyBwYWdlIGJvdW5kYXJpZXMgLi4uIHBhc3NlZAooZDEpICAtIEdTIGJhc2UgTVNS
cyBhbmQgU1dBUEdTIC4uLiBwYXNzZWQKKGQxKSBQYXNzZWQgMiBvZiAyIHRlc3RzCihkMSkg
V3JpdGluZyBTTUJJT1MgdGFibGVzIC4uLgooZDEpIExvYWRpbmcgU2VhQklPUyAuLi4KKGQx
KSBDcmVhdGluZyBNUCB0YWJsZXMgLi4uCihkMSkgTG9hZGluZyBBQ1BJIC4uLgooZDEpIHZt
ODYgVFNTIGF0IGZjMDBhMTgwCihkMSkgQklPUyBtYXA6CihkMSkgIDEwMDAwLTEwMGQzOiBT
Y3JhdGNoIHNwYWNlCihkMSkgIGMwMDAwLWZmZmZmOiBNYWluIEJJT1MKKGQxKSBFODIwIHRh
YmxlOgooZDEpICBbMDBdOiAwMDAwMDAwMDowMDAwMDAwMCAtIDAwMDAwMDAwOjAwMGEwMDAw
OiBSQU0KKGQxKSAgSE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDowMDBjMDAw
MAooZDEpICBbMDFdOiAwMDAwMDAwMDowMDBjMDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBS
RVNFUlZFRAooZDEpICBbMDJdOiAwMDAwMDAwMDowMDEwMDAwMCAtIDAwMDAwMDAwOjdmODAw
MDAwOiBSQU0KKGQxKSAgSE9MRTogMDAwMDAwMDA6N2Y4MDAwMDAgLSAwMDAwMDAwMDpmYzAw
MDAwMAooZDEpICBbMDNdOiAwMDAwMDAwMDpmYzAwMDAwMCAtIDAwMDAwMDAxOjAwMDAwMDAw
OiBSRVNFUlZFRAooZDEpIEludm9raW5nIFNlYUJJT1MgLi4uCihkMSkgU2VhQklPUyAodmVy
c2lvbiByZWwtMS43LjUtMC1nZTUxNDg4Yy0yMDE0MTExMl8xNzAwMzgtc21hcnRpbi14ZW4p
CihkMSkgCihkMSkgRm91bmQgWGVuIGh5cGVydmlzb3Igc2lnbmF0dXJlIGF0IDQwMDAwMTAw
CihkMSkgUnVubmluZyBvbiBRRU1VIChpNDQwZngpCihkMSkgeGVuOiBjb3B5IGU4MjAuLi4K
KGQxKSBSZWxvY2F0aW5nIGluaXQgZnJvbSAweDAwMGRmNjI5IHRvIDB4N2Y3YWU2MDAgKHNp
emUgNzE5OTUpCihkMSkgQ1BVIE1oej0xNjk2CihkMSkgRm91bmQgNyBQQ0kgZGV2aWNlcyAo
bWF4IFBDSSBidXMgaXMgMDApCihkMSkgQWxsb2NhdGVkIFhlbiBoeXBlcmNhbGwgcGFnZSBh
dCA3ZjdmZjAwMAooZDEpIERldGVjdGVkIFhlbiB2NC41LjAtcmMKKGQxKSB4ZW46IGNvcHkg
QklPUyB0YWJsZXMuLi4KKGQxKSBDb3B5aW5nIFNNQklPUyBlbnRyeSBwb2ludCBmcm9tIDB4
MDAwMTAwMTAgdG8gMHgwMDBmMGY1MAooZDEpIENvcHlpbmcgTVBUQUJMRSBmcm9tIDB4ZmMw
MDExNjAvZmMwMDExNzAgdG8gMHgwMDBmMGU1MAooZDEpIENvcHlpbmcgUElSIGZyb20gMHgw
MDAxMDAzMCB0byAweDAwMGYwZGQwCihkMSkgQ29weWluZyBBQ1BJIFJTRFAgZnJvbSAweDAw
MDEwMGIwIHRvIDB4MDAwZjBkYTAKKGQxKSBVc2luZyBwbXRpbWVyLCBpb3BvcnQgMHhiMDA4
CihkMSkgU2NhbiBmb3IgVkdBIG9wdGlvbiByb20KKGQxKSBSdW5uaW5nIG9wdGlvbiByb20g
YXQgYzAwMDowMDAzCihYRU4pIHN0ZHZnYS5jOjE0NzpkMXYwIGVudGVyaW5nIHN0ZHZnYSBh
bmQgY2FjaGluZyBtb2RlcwooZDEpIHBtbSBjYWxsIGFyZzE9MAooZDEpIFR1cm5pbmcgb24g
dmdhIHRleHQgbW9kZSBjb25zb2xlCihkMSkgU2VhQklPUyAodmVyc2lvbiByZWwtMS43LjUt
MC1nZTUxNDg4Yy0yMDE0MTExMl8xNzAwMzgtc21hcnRpbi14ZW4pCihkMSkgTWFjaGluZSBV
VUlEIDU4ZDMwNDNkLTllZGMtNDgwNy04ZTI3LTkwZjYxZGI1MWE1OAooZDEpIEFsbCB0aHJl
YWRzIGNvbXBsZXRlLgooZDEpIEZvdW5kIDAgbHB0IHBvcnRzCihkMSkgRm91bmQgMCBzZXJp
YWwgcG9ydHMKKGQxKSBBVEEgY29udHJvbGxlciAxIGF0IDFmMC8zZjQvMCAoaXJxIDE0IGRl
diA5KQooZDEpIEFUQSBjb250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUgZGV2IDkp
CihkMSkgYXRhMC0wOiBRRU1VIEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAoNzggR2lCeXRl
cykKKGQxKSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjogL3BjaUBpMGNmOC8qQDEsMS9kcml2
ZUAwL2Rpc2tAMAooZDEpIFBTMiBrZXlib2FyZCBpbml0aWFsaXplZAooZDEpIEFsbCB0aHJl
YWRzIGNvbXBsZXRlLgooZDEpIFNjYW4gZm9yIG9wdGlvbiByb21zCihkMSkgUnVubmluZyBv
cHRpb24gcm9tIGF0IGM5ODA6MDAwMwooZDEpIHBtbSBjYWxsIGFyZzE9MQooZDEpIHBtbSBj
YWxsIGFyZzE9MAooZDEpIHBtbSBjYWxsIGFyZzE9MQooZDEpIHBtbSBjYWxsIGFyZzE9MAoo
ZDEpIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4LypANAooZDEpIAooZDEp
IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51LgooZDEpIAooZDEpIFNlYXJjaGluZyBib290b3Jk
ZXIgZm9yOiBIQUxUCihkMSkgZHJpdmUgMHgwMDBmMGQ1MDogUENIUz0xNjM4My8xNi82MyB0
cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTE2NDE0MTIwOAooZDEpIAooZDEp
IFNwYWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkNTAKKGQx
KSBSZXR1cm5lZCAyNTgwNDggYnl0ZXMgb2YgWm9uZUhpZ2gKKGQxKSBlODIwIG1hcCBoYXMg
NiBpdGVtczoKKGQxKSAgIDA6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAw
ID0gMSBSQU0KKGQxKSAgIDE6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEwMDAw
ID0gMiBSRVNFUlZFRAooZDEpICAgMjogMDAwMDAwMDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAx
MDAwMDAgPSAyIFJFU0VSVkVECihkMSkgICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAw
MDA3ZjdmZjAwMCA9IDEgUkFNCihkMSkgICA0OiAwMDAwMDAwMDdmN2ZmMDAwIC0gMDAwMDAw
MDA3ZjgwMDAwMCA9IDIgUkVTRVJWRUQKKGQxKSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAgLSAw
MDAwMDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRAooZDEpIGVudGVyIGhhbmRsZV8xOToKKGQx
KSAgIE5VTEwKKGQxKSBCb290aW5nIGZyb20gSGFyZCBEaXNrLi4uCihkMSkgQm9vdGluZyBm
cm9tIDAwMDA6N2MwMAooWEVOKSBzdGR2Z2EuYzoxNTE6ZDF2MCBsZWF2aW5nIHN0ZHZnYQoo
WEVOKSBkMTogVklSSURJQU4gR1VFU1RfT1NfSUQ6IHZlbmRvcjogMSBvczogNCBtYWpvcjog
NiBtaW5vcjogMSBzcDogMSBidWlsZDogMWRiMQooWEVOKSBkMTogVklSSURJQU4gSFlQRVJD
QUxMOiBlbmFibGVkOiAxIHBmbjogM2ZmZmYKKFhFTikgZDF2MDogVklSSURJQU4gQVBJQ19B
U1NJU1Q6IGVuYWJsZWQ6IDEgcGZuOiAzZmZmZQooWEVOKSBkMXYxOiBWSVJJRElBTiBBUElD
X0FTU0lTVDogZW5hYmxlZDogMSBwZm46IDNmZmZkCihYRU4pIGlycS5jOjI3MDogRG9tMSBQ
Q0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCihYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGlu
ayAxIGNoYW5nZWQgMTAgLT4gMAooWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxpbmsgMiBj
aGFuZ2VkIDExIC0+IDAKKFhFTikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDMgY2hhbmdl
ZCA1IC0+IDAKKFhFTikgZ3JhbnRfdGFibGUuYzoxMjk5OmQxdjAgRXhwYW5kaW5nIGRvbSAo
MSkgZ3JhbnQgdGFibGUgZnJvbSAoNCkgdG8gKDMyKSBmcmFtZXMuCihYRU4pIGlycS5jOjM4
MDogRG9tMSBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBHU0kgMjQKKFhFTikgW1ZULURdaW9t
bXUuYzoxNTkzOiBkMDpQQ0k6IHVubWFwIDAwMDA6MDA6MTkuMAooWEVOKSBbVlQtRF1pb21t
dS5jOjE0NTY6IGQyOlBDSTogbWFwIDAwMDA6MDA6MTkuMAooZDIpIDAwOjAwOjAwLjAwMCBz
cmMva2VybmVsLmNAMDAwNjU6IG1pY3JvX3B2IHN0YXJ0ZWQKKGQyKSAwMDowMDowMC4wMDAg
c3JjL2h5cGVydmlzb3IuY0AwMDE0NDogQWxsb2NhdGVkIG1lbW9yeSBwYWdlcyAgICAgICAg
ICAgOiAzMjc2OAooZDIpIDAwOjAwOjAwLjAwMCBzcmMvaHlwZXJ2aXNvci5jQDAwMTQ1OiBB
bGxvY2F0ZWQgbWVtb3J5IE1CICAgICAgICAgICAgICA6IDEyOAooZDIpIDAwOjAwOjAwLjAw
MCBzcmMvaHlwZXJ2aXNvci5jQDAwMTQ2OiBNYWNoaW5lIGFkZHJlc3Mgb2Ygc2hhcmVkIG1l
bW9yeSA6IDB4YzMzY2IwMDAKKGQyKSAwMDowMDowMC4wMDAgc3JjL3hlbm1tdS5jQDAwMDk1
OiBQaHlzaWNhbCBhZGRyZXNzIDB4MTAwMCBtYXBwZWQgdG8gbWFjaGluZSBhZGRyZXNzIDB4
YzMzY2IwMDAgZm9yIGEgbGVuZ3RoIG9mIDEgcGFnZXMKKGQyKSAwMzowNTo1OS43MDkgc3Jj
L3hlbmV2ZW50cy5jQDAwMTY4OiB1bm1hc2sgcG9ydCAyCihkMikgMDM6MDU6NTkuNzA5IHNy
Yy94ZW50aW1lLmNAMDAxNzM6IEluaXRpYWxpc2luZyB0aW1lciBpbnRlcmZhY2UKKGQyKSAx
NToxODo0Ni44OTMgc3JjL3hlbmV2ZW50cy5jQDAwMTY4OiB1bm1hc2sgcG9ydCAxCihkMikg
MTU6MTg6NDYuODk0IHNyYy94ZW5nbnR0YWIuY0AwMDM0NzogV2UgYXJlIHVzaW5nIGdyYW50
IHZlcnNpb24gMQooZDIpIDE1OjE4OjQ2Ljg5NCBzcmMveGVuZ250dGFiLmNAMDAzNzI6IGZy
YW1lWzBdPTExNzJjYyBtYXBwZWQgdG8gMHgxMTgwMDAKKGQyKSAxNToxODo0Ni44OTQgc3Jj
L3hlbm1tdS5jQDAwMDk1OiBQaHlzaWNhbCBhZGRyZXNzIDB4MTE4MDAwIG1hcHBlZCB0byBt
YWNoaW5lIGFkZHJlc3MgMHgxMTcyY2MwMDAgZm9yIGEgbGVuZ3RoIG9mIDEgcGFnZXMKKGQy
KSAxNToxODo0Ni44OTQgc3JjL3hlbmdudHRhYi5jQDAwMzcyOiBmcmFtZVsxXT0xMDAwNTAg
bWFwcGVkIHRvIDB4MTE5MDAwCihkMikgMTU6MTg6NDYuODk0IHNyYy94ZW5tbXUuY0AwMDA5
NTogUGh5c2ljYWwgYWRkcmVzcyAweDExOTAwMCBtYXBwZWQgdG8gbWFjaGluZSBhZGRyZXNz
IDB4MTAwMDUwMDAwIGZvciBhIGxlbmd0aCBvZiAxIHBhZ2VzCihkMikgMTU6MTg6NDYuODk0
IHNyYy94ZW5nbnR0YWIuY0AwMDM3MjogZnJhbWVbMl09MTE2OWQwIG1hcHBlZCB0byAweDEx
YTAwMAooZDIpIDE1OjE4OjQ2Ljg5NCBzcmMveGVubW11LmNAMDAwOTU6IFBoeXNpY2FsIGFk
ZHJlc3MgMHgxMWEwMDAgbWFwcGVkIHRvIG1hY2hpbmUgYWRkcmVzcyAweDExNjlkMDAwMCBm
b3IgYSBsZW5ndGggb2YgMSBwYWdlcwooZDIpIDE1OjE4OjQ2Ljg5NCBzcmMveGVuZ250dGFi
LmNAMDAzNzI6IGZyYW1lWzNdPTExNzBjMCBtYXBwZWQgdG8gMHgxMWIwMDAKKGQyKSAxNTox
ODo0Ni44OTQgc3JjL3hlbm1tdS5jQDAwMDk1OiBQaHlzaWNhbCBhZGRyZXNzIDB4MTFiMDAw
IG1hcHBlZCB0byBtYWNoaW5lIGFkZHJlc3MgMHgxMTcwYzAwMDAgZm9yIGEgbGVuZ3RoIG9m
IDEgcGFnZXMKKGQyKSAxNToxODo0Ni44OTQgc3JjL3hlbmV2ZW50cy5jQDAwMTY4OiB1bm1h
c2sgcG9ydCAzCihkMikgMTU6MTg6NDYuODk0IHNyYy9rZXJuZWwuY0AwMDA3MTogY2FsbGlu
ZyBtYWluCihkMikgMTU6MTg6NDYuODk0IHNyYy94ZW5ldmVudHMuY0AwMDE2ODogdW5tYXNr
IHBvcnQgNAooZDIpIDE1OjE4OjQ2Ljg5NCBzcmMveGVuZ250dGFiLmNAMDAzMDQ6IHBoeXNp
Y2FsX2FkZHJlc3M9MHgzM2YwMDAgbWFwcGVkIHRvIG1hY2hpbmVfYWRkcmVzcz0xMDFiOTMw
MDAgd2l0aCBncmFudF9yZWY9MjA0NwooZDIpIDE1OjE4OjQ2Ljg5NCBzcmMveGVuc3RvcmUu
Y0AwMDMwNTogV1JJVEUgZGV2aWNlL3BjaS8wL3BjaS1vcC1yZWYgLSAyMDQ3CihkMikgMTU6
MTg6NDYuODk0IHNyYy94ZW5zdG9yZS5jQDAwMzA1OiBXUklURSBkZXZpY2UvcGNpLzAvZXZl
bnQtY2hhbm5lbCAtIDQKKGQyKSAxNToxODo0Ni44OTUgc3JjL3hlbnN0b3JlLmNAMDAzMDU6
IFdSSVRFIGRldmljZS9wY2kvMC9tYWdpYyAtIDcKKGQyKSAxNToxODo0Ni44OTUgc3JjL3hl
bnN0b3JlLmNAMDAzMDU6IFdSSVRFIGRldmljZS9wY2kvMC9zdGF0ZSAtIDMKKGQyKSAxNTox
ODo0Ni44OTggc3JjL3hlbnN0b3JlLmNAMDAzMDU6IFdSSVRFIGRldmljZS9wY2kvMC9zdGF0
ZSAtIDQKKGQyKSAxNToxODo0Ni44OTkgc3JjL3hlbnBjaS5jQDAwMjk1OiBWaXJ0dWFsIERl
dmljZT0wMDAwOjAwOjAwLjAwCihkMikgMTU6MTg6NDYuODk5IHNyYy94ZW5wY2kuY0AwMDA2
ODogcGNpX2V2ZW50CihkMikgMTU6MTg6NDYuODk5IHNyYy94ZW5wY2kuY0AwMDA2ODogcGNp
X2V2ZW50CihkMikgMTU6MTg6NDYuODk5IHNyYy94ZW5wY2kuY0AwMDA2ODogcGNpX2V2ZW50
CihkMikgMTU6MTg6NDYuODk5IHNyYy94ZW5wY2kuY0AwMDA2ODogcGNpX2V2ZW50CihkMikg
MTU6MTg6NDYuODk5IHNyYy94ZW5wY2kuY0AwMDMxMDogMDAwMDowMDowMC4wMCAwMjAwOiA4
MDg2OjE1NTkgKHJldiAwNCkKKGQyKSAxNToxODo0Ni44OTkgc3JjL3hlbnBjaS5jQDAwMDY4
OiBwY2lfZXZlbnQKKGQyKSAxNToxODo0Ni44OTkgc3JjL3hlbnBjaS5jQDAwMDY4OiBwY2lf
ZXZlbnQKKGQyKSAxNToxODo0Ni44OTkgc3JjL3hlbnBjaS5jQDAwMDY4OiBwY2lfZXZlbnQK
KGQyKSAxNToxODo0Ni44OTkgc3JjL3hlbnBjaS5jQDAwMDY4OiBwY2lfZXZlbnQKKGQyKSAx
NToxODo0Ni44OTkgc3JjL2UxMDAwZS5jQDAwMTE5OiBSZWNvZ25pemVkIEV0aGVybmV0IE5J
QwooZDIpIDE1OjE4OjQ2LjkxNCBzcmMveGVuZ250dGFiLmNAMDAyMzE6IGdyYW50X2hhbmRs
ZSAwIGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzMxMDAwIG1hcHBlZCB0byBkb209MCB3aXRo
IGdyYW50X3JlZj0xNQooZDIpIDE1OjE4OjQ2LjkxNCBzcmMveGVuZ250dGFiLmNAMDAyMzE6
IGdyYW50X2hhbmRsZSAxIGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzMyMDAwIG1hcHBlZCB0
byBkb209MCB3aXRoIGdyYW50X3JlZj0xNgooZDIpIDE1OjE4OjQ2LjkxNCBzcmMveGVuZ250
dGFiLmNAMDAyMzE6IGdyYW50X2hhbmRsZSAyIGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzMz
MDAwIG1hcHBlZCB0byBkb209MCB3aXRoIGdyYW50X3JlZj0xNwooZDIpIDE1OjE4OjQ2Ljkx
NCBzcmMveGVuZ250dGFiLmNAMDAyMzE6IGdyYW50X2hhbmRsZSAzIGZvciBwaHlzaWNhbF9h
ZGRyZXNzPTB4MzM1MDAwIG1hcHBlZCB0byBkb209MCB3aXRoIGdyYW50X3JlZj0xOAooZDIp
IDE1OjE4OjQ2LjkxNSBzcmMveGVuZ250dGFiLmNAMDAyMzE6IGdyYW50X2hhbmRsZSA0IGZv
ciBwaHlzaWNhbF9hZGRyZXNzPTB4MzM2MDAwIG1hcHBlZCB0byBkb209MCB3aXRoIGdyYW50
X3JlZj0xOQooZDIpIDE1OjE4OjQ2LjkxNSBzcmMveGVuZ250dGFiLmNAMDAyMzE6IGdyYW50
X2hhbmRsZSA1IGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzM3MDAwIG1hcHBlZCB0byBkb209
MCB3aXRoIGdyYW50X3JlZj0yMAooZDIpIDE1OjE4OjQ2LjkxNSBzcmMveGVuZ250dGFiLmNA
MDAyMzE6IGdyYW50X2hhbmRsZSA2IGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzM4MDAwIG1h
cHBlZCB0byBkb209MCB3aXRoIGdyYW50X3JlZj0yMQooZDIpIDE1OjE4OjQ2LjkxNSBzcmMv
ZTEwMDBlLmNAMDAzMTA6IEVuYWJsZSBQQ0kgTWVtb3J5IEFjY2VzcwooZDIpIDE1OjE4OjQ2
LjkxNSBzcmMveGVucGNpLmNAMDAwNjg6IHBjaV9ldmVudAooZDIpIDE1OjE4OjQ2LjkxNSBz
cmMvZTEwMDBlLmNAMDAzMTQ6IFdhaXQgZm9yIFBDSQooZDIpIDE1OjE4OjQ3LjkxNSBzcmMv
eGVucGNpLmNAMDAwNjg6IHBjaV9ldmVudAooZDIpIDE1OjE4OjQ3LjkxNSBzcmMvZTEwMDBl
LmNAMDAzMjA6IEVuYWJsZSBQQ0kgTWVtb3J5IEFjY2Vzcz0zCihkMikgMTU6MTg6NDcuOTE1
IHNyYy9lMTAwMGUuY0AwMDMzMDogbmljX21hY2hpbmVfcHRyPWY3ZDAwMDAwIG5pY19sZW5n
dGg9MAooZDIpIDE1OjE4OjQ3LjkxNiBzcmMveGVubW11LmNAMDAwOTU6IFBoeXNpY2FsIGFk
ZHJlc3MgMHgzNDEwMDAgbWFwcGVkIHRvIG1hY2hpbmUgYWRkcmVzcyAweGY3ZDAwMDAwIGZv
ciBhIGxlbmd0aCBvZiAzMiBwYWdlcwooZDIpIDE1OjE4OjQ3LjkxNiBzcmMvZTEwMDBlLmNA
MDAzMzc6IG5pY19wdHI9MHgzNDEwMDAKKGQyKSAxNToxODo0Ny45MTYgc3JjL2UxMDAwZS5j
QDAwMzkwOiBXYWl0IGZvciByZXNldCAxMTE2MDczMjgzOTc5NSAxMTE2MDc1MjgzOTcyNiAy
MDAwMDAwMAooZDIpIDE1OjE4OjQ3LjkzNiBzcmMvZTEwMDBlLmNAMDA0MTE6IE1BQ19HZW5l
cmFsX0xFRENUTCAgICAgICAgICAgICA9MDAwMDBlZjQKKGQyKSAxNToxODo0Ny45MzYgc3Jj
L2UxMDAwZS5jQDAwNDIzOiBNQUMgYWRkcmVzcz1lYzphODo2YjpmZTowNTozZgooZDIpIDE1
OjE4OjQ3LjkzNiBzcmMvZTEwMDBlLmNAMDA0MjY6IEV0aGVybmV0IE5JQyBzdGFydGVkCihk
MikgMTU6MTk6MTAuOTI0IHNyYy9QVjQ5OU1haW4uY0AwMDEyODogQ2xlYW51cCBzdGFydHMK
KGQyKSAxNToxOToxMC45MjQgc3JjL1BWNDk5UENJLmNAMDAwODU6IFN0b3BwaW5nIGRldmlj
ZSBkZXZpY2UvcGNpLzAKKGQyKSAxNToxOToxMC45MjQgc3JjL2UxMDAwZS5jQDAwNDk0OiBF
dGhlcm5ldCBOSUMgc3RvcHBpbmcKKGQyKSAxNToxOToxMC45MjQgc3JjL3hlbnBjaS5jQDAw
MDY4OiBwY2lfZXZlbnQKKGQyKSAxNToxOToxMC45MjQgc3JjL2UxMDAwZS5jQDAwNTMxOiBF
dGhlcm5ldCBOSUMgc3RvcHBlZAooZDIpIDE1OjE5OjEwLjkyNCBzcmMvUFY0OTlQQ0kuY0Aw
MDA4OTogRGV2aWNlIGRldmljZS9wY2kvMCBzdG9wcGVkCihkMikgMTU6MTk6MTAuOTI1IHNy
Yy94ZW5zdG9yZS5jQDAwMzA1OiBXUklURSBkZXZpY2UvcGNpLzAvc3RhdGUgLSA1CihkMikg
MTU6MTk6MTAuOTI2IHNyYy94ZW5zdG9yZS5jQDAwMzA1OiBXUklURSBkZXZpY2UvcGNpLzAv
c3RhdGUgLSA2CihkMikgMTU6MTk6MTAuOTI3IHNyYy94ZW5zdG9yZS5jQDAwMzA1OiBXUklU
RSBkZXZpY2UvcGNpLzAvc3RhdGUgLSAwCihkMikgMTU6MTk6MTAuOTI3IHNyYy94ZW5nbnR0
YWIuY0AwMDI2NjogdW5tYXBwaW5nIGdyYW50X3JlZj0yMDQ3CihkMikgMTU6MTk6MTAuOTI3
IHNyYy94ZW5nbnR0YWIuY0AwMDIzODogVW5tYXAgaGFuZGxlPTAgZm9yIHBoeXNpY2FsX2Fk
ZHJlc3M9MHgzMzEwMDAKKGQyKSAxNToxOToxMC45Mjcgc3JjL3hlbmdudHRhYi5jQDAwMjM4
OiBVbm1hcCBoYW5kbGU9MSBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzMjAwMAooZDIpIDE1
OjE5OjEwLjkyNyBzcmMveGVuZ250dGFiLmNAMDAyMzg6IFVubWFwIGhhbmRsZT0yIGZvciBw
aHlzaWNhbF9hZGRyZXNzPTB4MzMzMDAwCihkMikgMTU6MTk6MTAuOTI3IHNyYy94ZW5nbnR0
YWIuY0AwMDIzODogVW5tYXAgaGFuZGxlPTMgZm9yIHBoeXNpY2FsX2FkZHJlc3M9MHgzMzUw
MDAKKGQyKSAxNToxOToxMC45Mjggc3JjL3hlbmdudHRhYi5jQDAwMjM4OiBVbm1hcCBoYW5k
bGU9NCBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzNjAwMAooZDIpIDE1OjE5OjEwLjkyOCBz
cmMveGVuZ250dGFiLmNAMDAyMzg6IFVubWFwIGhhbmRsZT01IGZvciBwaHlzaWNhbF9hZGRy
ZXNzPTB4MzM3MDAwCihkMikgMTU6MTk6MTAuOTI4IHNyYy94ZW5nbnR0YWIuY0AwMDIzODog
VW5tYXAgaGFuZGxlPTYgZm9yIHBoeXNpY2FsX2FkZHJlc3M9MHgzMzgwMDAKKGQyKSAxNTox
OToxMC45Mjggc3JjL1BWNDk5TWFpbi5jQDAwMTM0OiBDbGVhbnVwIHN0b3BzCihkMikgMTU6
MTk6MTAuOTI4IHNyYy94ZW5zY2hlZHVsZS5jQDAwMTU0OiBtaWNyb3B2X2V4aXQgY2FsbGVk
IQooWEVOKSBbVlQtRF1pb21tdS5jOjE1OTM6IGQyOlBDSTogdW5tYXAgMDAwMDowMDoxOS4w
CihYRU4pIFtWVC1EXWlvbW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxOS4wCihY
RU4pIFtWVC1EXWlvbW11LmM6MTU5MzogZDA6UENJOiB1bm1hcCAwMDAwOjAwOjE5LjAKKFhF
TikgW1ZULURdaW9tbXUuYzoxNDU2OiBkNDpQQ0k6IG1hcCAwMDAwOjAwOjE5LjAKKGQ0KSAw
MDowMDowMC4wMDAgc3JjL2tlcm5lbC5jQDAwMDY1OiBtaWNyb19wdiBzdGFydGVkCihkNCkg
MDA6MDA6MDAuMDAwIHNyYy9oeXBlcnZpc29yLmNAMDAxNDQ6IEFsbG9jYXRlZCBtZW1vcnkg
cGFnZXMgICAgICAgICAgIDogMzI3NjgKKGQ0KSAwMDowMDowMC4wMDAgc3JjL2h5cGVydmlz
b3IuY0AwMDE0NTogQWxsb2NhdGVkIG1lbW9yeSBNQiAgICAgICAgICAgICAgOiAxMjgKKGQ0
KSAwMDowMDowMC4wMDAgc3JjL2h5cGVydmlzb3IuY0AwMDE0NjogTWFjaGluZSBhZGRyZXNz
IG9mIHNoYXJlZCBtZW1vcnkgOiAweGJjYjljMDAwCihkNCkgMDA6MDA6MDAuMDAwIHNyYy94
ZW5tbXUuY0AwMDA5NTogUGh5c2ljYWwgYWRkcmVzcyAweDEwMDAgbWFwcGVkIHRvIG1hY2hp
bmUgYWRkcmVzcyAweGJjYjljMDAwIGZvciBhIGxlbmd0aCBvZiAxIHBhZ2VzCihkNCkgMDM6
MDY6NTMuODA3IHNyYy94ZW5ldmVudHMuY0AwMDE2ODogdW5tYXNrIHBvcnQgMgooZDQpIDAz
OjA2OjUzLjgwNyBzcmMveGVudGltZS5jQDAwMTczOiBJbml0aWFsaXNpbmcgdGltZXIgaW50
ZXJmYWNlCihkNCkgMTU6MTk6NDAuOTkwIHNyYy94ZW5ldmVudHMuY0AwMDE2ODogdW5tYXNr
IHBvcnQgMQooZDQpIDE1OjE5OjQwLjk5MSBzcmMveGVuZ250dGFiLmNAMDAzNDc6IFdlIGFy
ZSB1c2luZyBncmFudCB2ZXJzaW9uIDEKKGQ0KSAxNToxOTo0MC45OTEgc3JjL3hlbmdudHRh
Yi5jQDAwMzcyOiBmcmFtZVswXT0xMWQ5M2MgbWFwcGVkIHRvIDB4MTE4MDAwCihkNCkgMTU6
MTk6NDAuOTkxIHNyYy94ZW5tbXUuY0AwMDA5NTogUGh5c2ljYWwgYWRkcmVzcyAweDExODAw
MCBtYXBwZWQgdG8gbWFjaGluZSBhZGRyZXNzIDB4MTFkOTNjMDAwIGZvciBhIGxlbmd0aCBv
ZiAxIHBhZ2VzCihkNCkgMTU6MTk6NDAuOTkxIHNyYy94ZW5nbnR0YWIuY0AwMDM3MjogZnJh
bWVbMV09MTE2MjMzIG1hcHBlZCB0byAweDExOTAwMAooZDQpIDE1OjE5OjQwLjk5MSBzcmMv
eGVubW11LmNAMDAwOTU6IFBoeXNpY2FsIGFkZHJlc3MgMHgxMTkwMDAgbWFwcGVkIHRvIG1h
Y2hpbmUgYWRkcmVzcyAweDExNjIzMzAwMCBmb3IgYSBsZW5ndGggb2YgMSBwYWdlcwooZDQp
IDE1OjE5OjQwLjk5MSBzcmMveGVuZ250dGFiLmNAMDAzNzI6IGZyYW1lWzJdPTExNmI0MCBt
YXBwZWQgdG8gMHgxMWEwMDAKKGQ0KSAxNToxOTo0MC45OTEgc3JjL3hlbm1tdS5jQDAwMDk1
OiBQaHlzaWNhbCBhZGRyZXNzIDB4MTFhMDAwIG1hcHBlZCB0byBtYWNoaW5lIGFkZHJlc3Mg
MHgxMTZiNDAwMDAgZm9yIGEgbGVuZ3RoIG9mIDEgcGFnZXMKKGQ0KSAxNToxOTo0MC45OTEg
c3JjL3hlbmdudHRhYi5jQDAwMzcyOiBmcmFtZVszXT0xMWVjNWIgbWFwcGVkIHRvIDB4MTFi
MDAwCihkNCkgMTU6MTk6NDAuOTkxIHNyYy94ZW5tbXUuY0AwMDA5NTogUGh5c2ljYWwgYWRk
cmVzcyAweDExYjAwMCBtYXBwZWQgdG8gbWFjaGluZSBhZGRyZXNzIDB4MTFlYzViMDAwIGZv
ciBhIGxlbmd0aCBvZiAxIHBhZ2VzCihkNCkgMTU6MTk6NDAuOTkxIHNyYy94ZW5ldmVudHMu
Y0AwMDE2ODogdW5tYXNrIHBvcnQgMwooZDQpIDE1OjE5OjQwLjk5MSBzcmMva2VybmVsLmNA
MDAwNzE6IGNhbGxpbmcgbWFpbgooZDQpIDE1OjE5OjQwLjk5MSBzcmMveGVuZXZlbnRzLmNA
MDAxNjg6IHVubWFzayBwb3J0IDQKKGQ0KSAxNToxOTo0MC45OTEgc3JjL3hlbmdudHRhYi5j
QDAwMzA0OiBwaHlzaWNhbF9hZGRyZXNzPTB4MzNmMDAwIG1hcHBlZCB0byBtYWNoaW5lX2Fk
ZHJlc3M9MTAwMzQ5MDAwIHdpdGggZ3JhbnRfcmVmPTIwNDcKKGQ0KSAxNToxOTo0MC45OTEg
c3JjL3hlbnN0b3JlLmNAMDAzMDU6IFdSSVRFIGRldmljZS9wY2kvMC9wY2ktb3AtcmVmIC0g
MjA0NwooZDQpIDE1OjE5OjQwLjk5MSBzcmMveGVuc3RvcmUuY0AwMDMwNTogV1JJVEUgZGV2
aWNlL3BjaS8wL2V2ZW50LWNoYW5uZWwgLSA0CihkNCkgMTU6MTk6NDAuOTkxIHNyYy94ZW5z
dG9yZS5jQDAwMzA1OiBXUklURSBkZXZpY2UvcGNpLzAvbWFnaWMgLSA3CihkNCkgMTU6MTk6
NDAuOTkxIHNyYy94ZW5zdG9yZS5jQDAwMzA1OiBXUklURSBkZXZpY2UvcGNpLzAvc3RhdGUg
LSAzCihkNCkgMTU6MTk6NDAuOTk2IHNyYy94ZW5zdG9yZS5jQDAwMzA1OiBXUklURSBkZXZp
Y2UvcGNpLzAvc3RhdGUgLSA0CihkNCkgMTU6MTk6NDAuOTk2IHNyYy94ZW5wY2kuY0AwMDI5
NTogVmlydHVhbCBEZXZpY2U9MDAwMDowMDowMC4wMAooZDQpIDE1OjE5OjQwLjk5NiBzcmMv
eGVucGNpLmNAMDAwNjg6IHBjaV9ldmVudAooZDQpIDE1OjE5OjQwLjk5NiBzcmMveGVucGNp
LmNAMDAwNjg6IHBjaV9ldmVudAooZDQpIDE1OjE5OjQwLjk5NiBzcmMveGVucGNpLmNAMDAw
Njg6IHBjaV9ldmVudAooZDQpIDE1OjE5OjQwLjk5NiBzcmMveGVucGNpLmNAMDAwNjg6IHBj
aV9ldmVudAooZDQpIDE1OjE5OjQwLjk5NiBzcmMveGVucGNpLmNAMDAzMTA6IDAwMDA6MDA6
MDAuMDAgMDIwMDogODA4NjoxNTU5IChyZXYgMDQpCihkNCkgMTU6MTk6NDAuOTk2IHNyYy94
ZW5wY2kuY0AwMDA2ODogcGNpX2V2ZW50CihkNCkgMTU6MTk6NDAuOTk2IHNyYy94ZW5wY2ku
Y0AwMDA2ODogcGNpX2V2ZW50CihkNCkgMTU6MTk6NDAuOTk2IHNyYy94ZW5wY2kuY0AwMDA2
ODogcGNpX2V2ZW50CihkNCkgMTU6MTk6NDAuOTk2IHNyYy94ZW5wY2kuY0AwMDA2ODogcGNp
X2V2ZW50CihkNCkgMTU6MTk6NDAuOTk2IHNyYy9lMTAwMGUuY0AwMDExOTogUmVjb2duaXpl
ZCBFdGhlcm5ldCBOSUMKKGQ0KSAxNToxOTo0MS4wMTEgc3JjL3hlbmdudHRhYi5jQDAwMjMx
OiBncmFudF9oYW5kbGUgMCBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzMTAwMCBtYXBwZWQg
dG8gZG9tPTAgd2l0aCBncmFudF9yZWY9MjEKKGQ0KSAxNToxOTo0MS4wMTEgc3JjL3hlbmdu
dHRhYi5jQDAwMjMxOiBncmFudF9oYW5kbGUgMSBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMz
MjAwMCBtYXBwZWQgdG8gZG9tPTAgd2l0aCBncmFudF9yZWY9MjAKKGQ0KSAxNToxOTo0MS4w
MTEgc3JjL3hlbmdudHRhYi5jQDAwMjMxOiBncmFudF9oYW5kbGUgMiBmb3IgcGh5c2ljYWxf
YWRkcmVzcz0weDMzMzAwMCBtYXBwZWQgdG8gZG9tPTAgd2l0aCBncmFudF9yZWY9MTkKKGQ0
KSAxNToxOTo0MS4wMTEgc3JjL3hlbmdudHRhYi5jQDAwMjMxOiBncmFudF9oYW5kbGUgMyBm
b3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzNTAwMCBtYXBwZWQgdG8gZG9tPTAgd2l0aCBncmFu
dF9yZWY9MTgKKGQ0KSAxNToxOTo0MS4wMTEgc3JjL3hlbmdudHRhYi5jQDAwMjMxOiBncmFu
dF9oYW5kbGUgNCBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzNjAwMCBtYXBwZWQgdG8gZG9t
PTAgd2l0aCBncmFudF9yZWY9MTcKKGQ0KSAxNToxOTo0MS4wMTEgc3JjL3hlbmdudHRhYi5j
QDAwMjMxOiBncmFudF9oYW5kbGUgNSBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzNzAwMCBt
YXBwZWQgdG8gZG9tPTAgd2l0aCBncmFudF9yZWY9MTYKKGQ0KSAxNToxOTo0MS4wMTEgc3Jj
L3hlbmdudHRhYi5jQDAwMjMxOiBncmFudF9oYW5kbGUgNiBmb3IgcGh5c2ljYWxfYWRkcmVz
cz0weDMzODAwMCBtYXBwZWQgdG8gZG9tPTAgd2l0aCBncmFudF9yZWY9MTUKKGQ0KSAxNTox
OTo0MS4wMTEgc3JjL2UxMDAwZS5jQDAwMzEwOiBFbmFibGUgUENJIE1lbW9yeSBBY2Nlc3MK
KGQ0KSAxNToxOTo0MS4wMTIgc3JjL3hlbnBjaS5jQDAwMDY4OiBwY2lfZXZlbnQKKGQ0KSAx
NToxOTo0MS4wMTIgc3JjL2UxMDAwZS5jQDAwMzE0OiBXYWl0IGZvciBQQ0kKKGQ0KSAxNTox
OTo0Mi4wMTIgc3JjL3hlbnBjaS5jQDAwMDY4OiBwY2lfZXZlbnQKKGQ0KSAxNToxOTo0Mi4w
MTIgc3JjL2UxMDAwZS5jQDAwMzIwOiBFbmFibGUgUENJIE1lbW9yeSBBY2Nlc3M9MwooZDQp
IDE1OjE5OjQyLjAxMiBzcmMvZTEwMDBlLmNAMDAzMzA6IG5pY19tYWNoaW5lX3B0cj1mN2Qw
MDAwMCBuaWNfbGVuZ3RoPTAKKGQ0KSAxNToxOTo0Mi4wMTIgc3JjL3hlbm1tdS5jQDAwMDk1
OiBQaHlzaWNhbCBhZGRyZXNzIDB4MzQxMDAwIG1hcHBlZCB0byBtYWNoaW5lIGFkZHJlc3Mg
MHhmN2QwMDAwMCBmb3IgYSBsZW5ndGggb2YgMzIgcGFnZXMKKGQ0KSAxNToxOTo0Mi4wMTIg
c3JjL2UxMDAwZS5jQDAwMzM3OiBuaWNfcHRyPTB4MzQxMDAwCihkNCkgMTU6MTk6NDIuMDEy
IHNyYy9lMTAwMGUuY0AwMDM5MDogV2FpdCBmb3IgcmVzZXQgMTEyMTQ4MjkyMjc0MzcgMTEy
MTQ4NDkyMjczNjkgMjAwMDAwMDAKKGQ0KSAxNToxOTo0Mi4wMzIgc3JjL2UxMDAwZS5jQDAw
NDExOiBNQUNfR2VuZXJhbF9MRURDVEwgICAgICAgICAgICAgPWZmZmZmZmZmCihkNCkgMTU6
MTk6NDIuMDMyIHNyYy9lMTAwMGUuY0AwMDQyMzogTUFDIGFkZHJlc3M9ZmY6ZmY6ZmY6ZmY6
ZmY6ZmYKKGQ0KSAxNToxOTo0Mi4wMzIgc3JjL2UxMDAwZS5jQDAwNDI2OiBFdGhlcm5ldCBO
SUMgc3RhcnRlZAooZDQpIDE1OjE5OjQyLjAzMiBzcmMvZTEwMDBlLmNAMDA0NDU6IExJTksg
VVAKKGQ0KSAxNToxOTo0OC4wMjEgc3JjL1BWNDk5TWFpbi5jQDAwMTI4OiBDbGVhbnVwIHN0
YXJ0cwooZDQpIDE1OjE5OjQ4LjAyMSBzcmMvUFY0OTlQQ0kuY0AwMDA4NTogU3RvcHBpbmcg
ZGV2aWNlIGRldmljZS9wY2kvMAooZDQpIDE1OjE5OjQ4LjAyMSBzcmMvZTEwMDBlLmNAMDA0
OTQ6IEV0aGVybmV0IE5JQyBzdG9wcGluZwooZDQpIDE1OjE5OjQ4LjAyMSBzcmMveGVucGNp
LmNAMDAwNjg6IHBjaV9ldmVudAooZDQpIDE1OjE5OjQ4LjAyMSBzcmMvZTEwMDBlLmNAMDA1
MzE6IEV0aGVybmV0IE5JQyBzdG9wcGVkCihkNCkgMTU6MTk6NDguMDIxIHNyYy9QVjQ5OVBD
SS5jQDAwMDg5OiBEZXZpY2UgZGV2aWNlL3BjaS8wIHN0b3BwZWQKKGQ0KSAxNToxOTo0OC4w
MjEgc3JjL3hlbnN0b3JlLmNAMDAzMDU6IFdSSVRFIGRldmljZS9wY2kvMC9zdGF0ZSAtIDUK
KGQ0KSAxNToxOTo0OC4wMjIgc3JjL3hlbnN0b3JlLmNAMDAzMDU6IFdSSVRFIGRldmljZS9w
Y2kvMC9zdGF0ZSAtIDYKKGQ0KSAxNToxOTo0OC4wMjQgc3JjL3hlbnN0b3JlLmNAMDAzMDU6
IFdSSVRFIGRldmljZS9wY2kvMC9zdGF0ZSAtIDAKKGQ0KSAxNToxOTo0OC4wMjQgc3JjL3hl
bmdudHRhYi5jQDAwMjY2OiB1bm1hcHBpbmcgZ3JhbnRfcmVmPTIwNDcKKGQ0KSAxNToxOTo0
OC4wMjQgc3JjL3hlbmdudHRhYi5jQDAwMjM4OiBVbm1hcCBoYW5kbGU9MCBmb3IgcGh5c2lj
YWxfYWRkcmVzcz0weDMzMTAwMAooZDQpIDE1OjE5OjQ4LjAyNCBzcmMveGVuZ250dGFiLmNA
MDAyMzg6IFVubWFwIGhhbmRsZT0xIGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzMyMDAwCihk
NCkgMTU6MTk6NDguMDI0IHNyYy94ZW5nbnR0YWIuY0AwMDIzODogVW5tYXAgaGFuZGxlPTIg
Zm9yIHBoeXNpY2FsX2FkZHJlc3M9MHgzMzMwMDAKKGQ0KSAxNToxOTo0OC4wMjQgc3JjL3hl
bmdudHRhYi5jQDAwMjM4OiBVbm1hcCBoYW5kbGU9MyBmb3IgcGh5c2ljYWxfYWRkcmVzcz0w
eDMzNTAwMAooZDQpIDE1OjE5OjQ4LjAyNCBzcmMveGVuZ250dGFiLmNAMDAyMzg6IFVubWFw
IGhhbmRsZT00IGZvciBwaHlzaWNhbF9hZGRyZXNzPTB4MzM2MDAwCihkNCkgMTU6MTk6NDgu
MDI0IHNyYy94ZW5nbnR0YWIuY0AwMDIzODogVW5tYXAgaGFuZGxlPTUgZm9yIHBoeXNpY2Fs
X2FkZHJlc3M9MHgzMzcwMDAKKGQ0KSAxNToxOTo0OC4wMjQgc3JjL3hlbmdudHRhYi5jQDAw
MjM4OiBVbm1hcCBoYW5kbGU9NiBmb3IgcGh5c2ljYWxfYWRkcmVzcz0weDMzODAwMAooZDQp
IDE1OjE5OjQ4LjAyNCBzcmMvUFY0OTlNYWluLmNAMDAxMzQ6IENsZWFudXAgc3RvcHMKKGQ0
KSAxNToxOTo0OC4wMjQgc3JjL3hlbnNjaGVkdWxlLmNAMDAxNTQ6IG1pY3JvcHZfZXhpdCBj
YWxsZWQhCihYRU4pIFtWVC1EXWlvbW11LmM6MTU5MzogZDQ6UENJOiB1bm1hcCAwMDAwOjAw
OjE5LjAKKFhFTikgW1ZULURdaW9tbXUuYzoxNDU2OiBkMDpQQ0k6IG1hcCAwMDAwOjAwOjE5
LjAK
------------0410070F03E0EB1B3
Content-Type: application/octet-stream;
 name=dmesg
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename=dmesg

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAg
MC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAw
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVhY2N0ClsgICAgMC4wMDAwMDBdIExp
bnV4IHZlcnNpb24gMy4xNi0wLmJwby4zLWFtZDY0IChkZWJpYW4ta2VybmVsQGxpc3RzLmRl
Ymlhbi5vcmcpIChnY2MgdmVyc2lvbiA0LjYuMyAoRGViaWFuIDQuNi4zLTE0KSApICMxIFNN
UCBEZWJpYW4gMy4xNi41LTF+YnBvNzArMSAoMjAxNC0xMS0wMikKWyAgICAwLjAwMDAwMF0g
Q29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciByb290PVVVSUQ9OWQyZjgwZjktOGJkYy00NzA2
LWI3NGEtYjQ3NjA1NjkyMmQ3IHJvIHF1aWV0ClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgOWQt
MTAwIHBmbiByYW5nZTogOTkgcGFnZXMgZnJlZWQKWyAgICAwLjAwMDAwMF0gMS0xIG1hcHBp
bmcgb24gOWQtPjEwMApbICAgIDAuMDAwMDAwXSBGcmVlaW5nIGM4NTIyLWM4NTI5IHBmbiBy
YW5nZTogNyBwYWdlcyBmcmVlZApbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiBjODUy
Mi0+Yzg1MjkKWyAgICAwLjAwMDAwMF0gRnJlZWluZyBkYmE4NS1kYmZmZiBwZm4gcmFuZ2U6
IDE0MDIgcGFnZXMgZnJlZWQKWyAgICAwLjAwMDAwMF0gMS0xIG1hcHBpbmcgb24gZGJhODUt
PmRiZmZmClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgZGMwMDAtZWY5NzMgcGZuIHJhbmdlOiA4
MDI0MyBwYWdlcyBmcmVlZApbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiBkYzAwMC0+
MTAwMDAwClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDgxNzUxIHBhZ2VzIG9mIHVudXNlZCBt
ZW1vcnkKWyAgICAwLjAwMDAwMF0gU2V0IDE0ODk2NCBwYWdlKHMpIHRvIDEtMSBtYXBwaW5n
ClsgICAgMC4wMDAwMDBdIFBvcHVsYXRpbmcgMTAwMDAwLTExM2Y1NyBwZm4gcmFuZ2U6IDgx
NzUxIHBhZ2VzIGFkZGVkClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIDExZmUwMC0+
ODAwMDAwMApbICAgIDAuMDAwMDAwXSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJB
TSBtYXA6ClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgw
MDAwMDAwMDAwMDljZmZmXSB1c2FibGUKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAw
MDAwMDAwMDA5ZDgwMC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMGM4NTIxZmZmXSB1
c2FibGUKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBjODUyMjAwMC0weDAw
MDAwMDAwYzg1MjhmZmZdIEFDUEkgTlZTClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAw
MDAwMDAwYzg1MjkwMDAtMHgwMDAwMDAwMGRiYTg0ZmZmXSB1c2FibGUKWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBkYmE4NTAwMC0weDAwMDAwMDAwZGJiMGVmZmZdIHJl
c2VydmVkClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZGJiMGYwMDAtMHgw
MDAwMDAwMGRiYjI4ZmZmXSBBQ1BJIGRhdGEKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwMDBkYmIyOTAwMC0weDAwMDAwMDAwZGJjOTFmZmZdIEFDUEkgTlZTClsgICAgMC4w
MDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZGJjOTIwMDAtMHgwMDAwMDAwMGRiZmZlZmZm
XSByZXNlcnZlZApbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGRiZmZmMDAw
LTB4MDAwMDAwMDBkYmZmZmZmZl0gdXNhYmxlClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwZGQwMDAwMDAtMHgwMDAwMDAwMGRmMWZmZmZmXSByZXNlcnZlZApbICAgIDAu
MDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGY4MDAwMDAwLTB4MDAwMDAwMDBmYmZmZmZm
Zl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWMwMDAw
MC0weDAwMDAwMDAwZmVjMDBmZmZdIHJlc2VydmVkClsgICAgMC4wMDAwMDBdIFhlbjogW21l
bSAweDAwMDAwMDAwZmVkMDAwMDAtMHgwMDAwMDAwMGZlZDAzZmZmXSByZXNlcnZlZApbICAg
IDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZDFjMDAwLTB4MDAwMDAwMDBmZWQx
ZmZmZl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWQ5
MDAwMC0weDAwMDAwMDAwZmVkOTFmZmZdIHJlc2VydmVkClsgICAgMC4wMDAwMDBdIFhlbjog
W21lbSAweDAwMDAwMDAwZmVlMDAwMDAtMHgwMDAwMDAwMGZlZWZmZmZmXSByZXNlcnZlZApb
ICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmMDAwMDAwLTB4MDAwMDAwMDBm
ZmZmZmZmZl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDEw
MDAwMDAwMC0weDAwMDAwMDAxMWZkZmZmZmZdIHVzYWJsZQpbICAgIDAuMDAwMDAwXSBOWCAo
RXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUKWyAgICAwLjAwMDAwMF0gU01C
SU9TIDIuOCBwcmVzZW50LgpbICAgIDAuMDAwMDAwXSBETUk6ICAgICAgICAgICAgICAgICAg
L0QzNDAxMFdZSywgQklPUyBXWUxQVDEwSC44NkEuMDAyMi4yMDEzLjExMjEuMTc1NyAxMS8y
MS8yMDEzClsgICAgMC4wMDAwMDBdIGU4MjA6IHVwZGF0ZSBbbWVtIDB4MDAwMDAwMDAtMHgw
MDAwMGZmZl0gdXNhYmxlID09PiByZXNlcnZlZApbICAgIDAuMDAwMDAwXSBlODIwOiByZW1v
dmUgW21lbSAweDAwMGEwMDAwLTB4MDAwZmZmZmZdIHVzYWJsZQpbICAgIDAuMDAwMDAwXSBB
R1A6IE5vIEFHUCBicmlkZ2UgZm91bmQKWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4g
PSAweDExZmUwMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBl
ODIwOiBsYXN0X3BmbiA9IDB4ZGMwMDAgbWF4X2FyY2hfcGZuID0gMHg0MDAwMDAwMDAKWyAg
ICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBhdCBbZmZmZjg4MDAwMDA5NzAw
MF0gOTcwMDAgc2l6ZSAyNDU3NgpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5n
OiBbbWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0KWyAgICAwLjAwMDAwMF0gIFttZW0gMHgw
MDAwMDAwMC0weDAwMGZmZmZmXSBwYWdlIDRrClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5
X21hcHBpbmc6IFttZW0gMHgxMTNjMDAwMDAtMHgxMTNkZmZmZmZdClsgICAgMC4wMDAwMDBd
ICBbbWVtIDB4MTEzYzAwMDAwLTB4MTEzZGZmZmZmXSBwYWdlIDRrClsgICAgMC4wMDAwMDBd
IEJSSyBbMHgwMWIwYTAwMCwgMHgwMWIwYWZmZl0gUEdUQUJMRQpbICAgIDAuMDAwMDAwXSBC
UksgWzB4MDFiMGIwMDAsIDB4MDFiMGJmZmZdIFBHVEFCTEUKWyAgICAwLjAwMDAwMF0gaW5p
dF9tZW1vcnlfbWFwcGluZzogW21lbSAweDExMDAwMDAwMC0weDExM2JmZmZmZl0KWyAgICAw
LjAwMDAwMF0gIFttZW0gMHgxMTAwMDAwMDAtMHgxMTNiZmZmZmZdIHBhZ2UgNGsKWyAgICAw
LjAwMDAwMF0gQlJLIFsweDAxYjBjMDAwLCAweDAxYjBjZmZmXSBQR1RBQkxFClsgICAgMC4w
MDAwMDBdIEJSSyBbMHgwMWIwZDAwMCwgMHgwMWIwZGZmZl0gUEdUQUJMRQpbICAgIDAuMDAw
MDAwXSBCUksgWzB4MDFiMGUwMDAsIDB4MDFiMGVmZmZdIFBHVEFCTEUKWyAgICAwLjAwMDAw
MF0gQlJLIFsweDAxYjBmMDAwLCAweDAxYjBmZmZmXSBQR1RBQkxFClsgICAgMC4wMDAwMDBd
IGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgxMDAwMDAwMDAtMHgxMGZmZmZmZmZdClsg
ICAgMC4wMDAwMDBdICBbbWVtIDB4MTAwMDAwMDAwLTB4MTBmZmZmZmZmXSBwYWdlIDRrClsg
ICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgwMDEwMDAwMC0weGM4
NTIxZmZmXQpbICAgIDAuMDAwMDAwXSAgW21lbSAweDAwMTAwMDAwLTB4Yzg1MjFmZmZdIHBh
Z2UgNGsKWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweGM4NTI5
MDAwLTB4ZGJhODRmZmZdClsgICAgMC4wMDAwMDBdICBbbWVtIDB4Yzg1MjkwMDAtMHhkYmE4
NGZmZl0gcGFnZSA0awpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVt
IDB4ZGJmZmYwMDAtMHhkYmZmZmZmZl0KWyAgICAwLjAwMDAwMF0gIFttZW0gMHhkYmZmZjAw
MC0weGRiZmZmZmZmXSBwYWdlIDRrClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBp
bmc6IFttZW0gMHgxMTNlMDAwMDAtMHgxMWZkZmZmZmZdClsgICAgMC4wMDAwMDBdICBbbWVt
IDB4MTEzZTAwMDAwLTB4MTFmZGZmZmZmXSBwYWdlIDRrClsgICAgMC4wMDAwMDBdIFJBTURJ
U0s6IFttZW0gMHgwMWYxNTAwMC0weDA0OWFlZmZmXQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBF
YXJseSB0YWJsZSBjaGVja3N1bSB2ZXJpZmljYXRpb24gZGlzYWJsZWQKWyAgICAwLjAwMDAw
MF0gQUNQSTogUlNEUCAweDAwMDAwMDAwMDAwRjA0OTAgMDAwMDI0ICh2MDIgSU5URUwgKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBYU0RUIDB4MDAwMDAwMDBEQkIxNDA4MCAwMDAwODQgKHYw
MSBJTlRFTCAgRDM0MDEwV1kgMDAwMDAwMTYgQU1JICAwMDAxMDAxMykKWyAgICAwLjAwMDAw
MF0gQUNQSTogRkFDUCAweDAwMDAwMDAwREJCMjNBMDggMDAwMTBDICh2MDUgSU5URUwgIEQz
NDAxMFdZIDAwMDAwMDE2IEFNSSAgMDAwMTAwMTMpClsgICAgMC4wMDAwMDBdIEFDUEk6IERT
RFQgMHgwMDAwMDAwMERCQjE0MTk4IDAwRjg3MCAodjAyIElOVEVMICBEMzQwMTBXWSAwMDAw
MDAxNiBJTlRMIDIwMTIwNzExKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBGQUNTIDB4MDAwMDAw
MDBEQkM5MDA4MCAwMDAwNDAKWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAweDAwMDAwMDAw
REJCMjNCMTggMDAwMDcyICh2MDMgSU5URUwgIEQzNDAxMFdZIDAwMDAwMDE2IEFNSSAgMDAw
MTAwMTMpClsgICAgMC4wMDAwMDBdIEFDUEk6IEZQRFQgMHgwMDAwMDAwMERCQjIzQjkwIDAw
MDA0NCAodjAxIElOVEVMICBEMzQwMTBXWSAwMDAwMDAxNiBBTUkgIDAwMDEwMDEzKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMUElUIDB4MDAwMDAwMDBEQkIyM0JEOCAwMDAwNUMgKHYwMSBJ
TlRFTCAgRDM0MDEwV1kgMDAwMDAwMTYgQU1JLiAwMDAwMDAwNSkKWyAgICAwLjAwMDAwMF0g
QUNQSTogU1NEVCAweDAwMDAwMDAwREJCMjNDMzggMDAwNDk0ICh2MDEgSU5URUwgIEQzNDAx
MFdZIDAwMDAwMDE2IElOVEwgMjAxMjA3MTEpClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQg
MHgwMDAwMDAwMERCQjI0MEQwIDAwMEFEOCAodjAxIElOVEVMICBEMzQwMTBXWSAwMDAwMDAx
NiBJTlRMIDIwMTIwNzExKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDB4MDAwMDAwMDBE
QkIyNEJBOCAwMDAwM0MgKHYwMSBJTlRFTCAgRDM0MDEwV1kgMDAwMDAwMTYgTVNGVCAwMDAw
MDA5NykKWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCAweDAwMDAwMDAwREJCMjRCRTggMDAw
MDM4ICh2MDEgSU5URUwgIEQzNDAxMFdZIDAwMDAwMDE2IEFNSS4gMDAwMDAwMDUpClsgICAg
MC4wMDAwMDBdIEFDUEk6IFNTRFQgMHgwMDAwMDAwMERCQjI0QzIwIDAwMDMxNSAodjAxIElO
VEVMICBEMzQwMTBXWSAwMDAwMDAxNiBJTlRMIDIwMTIwNzExKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBTU0RUIDB4MDAwMDAwMDBEQkIyNEYzOCAwMDMwMDQgKHYwMSBJTlRFTCAgRDM0MDEw
V1kgMDAwMDAwMTYgSU5UTCAyMDA5MTExMikKWyAgICAwLjAwMDAwMF0gQUNQSTogWE1BUiAw
eDAwMDAwMDAwREJCMjdGNDAgMDAwMTkwICh2MDEgSU5URUwgIEQzNDAxMFdZIDAwMDAwMDE2
IElOVEwgMDAwMDAwMDEpClsgICAgMC4wMDAwMDBdIEFDUEk6IENTUlQgMHgwMDAwMDAwMERC
QjI4MEQwIDAwMDBDNCAodjAxIElOVEVMICBEMzQwMTBXWSAwMDAwMDAxNiBJTlRMIDIwMTAw
NTI4KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAw
MApbICAgIDAuMDAwMDAwXSBOVU1BIHR1cm5lZCBvZmYKWyAgICAwLjAwMDAwMF0gRmFraW5n
IGEgbm9kZSBhdCBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAxMWZkZmZmZmZd
ClsgICAgMC4wMDAwMDBdIEluaXRtZW0gc2V0dXAgbm9kZSAwIFttZW0gMHgwMDAwMDAwMC0w
eDExZmRmZmZmZl0KWyAgICAwLjAwMDAwMF0gICBOT0RFX0RBVEEgW21lbSAweDExM2Y1MjAw
MC0weDExM2Y1NmZmZl0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6ClsgICAgMC4wMDAw
MDBdICAgRE1BICAgICAgW21lbSAweDAwMDAxMDAwLTB4MDBmZmZmZmZdClsgICAgMC4wMDAw
MDBdICAgRE1BMzIgICAgW21lbSAweDAxMDAwMDAwLTB4ZmZmZmZmZmZdClsgICAgMC4wMDAw
MDBdICAgTm9ybWFsICAgW21lbSAweDEwMDAwMDAwMC0weDExZmRmZmZmZl0KWyAgICAwLjAw
MDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0IGZvciBlYWNoIG5vZGUKWyAgICAwLjAwMDAwMF0g
RWFybHkgbWVtb3J5IG5vZGUgcmFuZ2VzClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFtt
ZW0gMHgwMDAwMTAwMC0weDAwMDljZmZmXQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBb
bWVtIDB4MDAxMDAwMDAtMHhjODUyMWZmZl0KWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDog
W21lbSAweGM4NTI5MDAwLTB4ZGJhODRmZmZdClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6
IFttZW0gMHhkYmZmZjAwMC0weGRiZmZmZmZmXQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAw
OiBbbWVtIDB4MTAwMDAwMDAwLTB4MTFmZGZmZmZmXQpbICAgIDAuMDAwMDAwXSBPbiBub2Rl
IDAgdG90YWxwYWdlczogMTAzMDE3MQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiA1NiBw
YWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMjEgcGFn
ZXMgcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMzk5NiBwYWdlcywgTElG
TyBiYXRjaDowClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogMTIyNDUgcGFnZXMgdXNl
ZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogODk1NjE1IHBhZ2Vz
LCBMSUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdICAgTm9ybWFsIHpvbmU6IDE3ODUgcGFn
ZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgTm9ybWFsIHpvbmU6IDEzMDU2
MCBwYWdlcywgTElGTyBiYXRjaDozMQpbICAgIDAuMDAwMDAwXSBSZXNlcnZpbmcgSW50ZWwg
Z3JhcGhpY3Mgc3RvbGVuIG1lbW9yeSBhdCAweGRkMjAwMDAwLTB4ZGYxZmZmZmYKWyAgICAw
LjAwMDAwMF0gQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHgxODA4ClsgICAgMC4wMDAwMDBd
IEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDJdIGVu
YWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGlj
X2lkWzB4MDFdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDX05NSSAoYWNwaV9pZFsweGZmXSBoaWdoIGVkZ2UgbGludFsweDFdKQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDJdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jh
c2VbMF0pClsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCAyLCB2ZXJzaW9uIDMy
LCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTM5ClsgICAgMC4wMDAwMDBdIEFDUEk6IElO
VF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpClsgICAg
MC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2ly
cSA5IGhpZ2ggbGV2ZWwpClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTAgdXNlZCBieSBvdmVy
cmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuClsgICAgMC4wMDAwMDBd
IFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBIUEVUIGlkOiAweDgwODZhNzAxIGJhc2U6IDB4ZmVkMDAw
MDAKWyAgICAwLjAwMDAwMF0gc21wYm9vdDogQWxsb3dpbmcgNCBDUFVzLCAwIGhvdHBsdWcg
Q1BVcwpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogNTYKWyAgICAwLjAwMDAwMF0gUE06
IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweDAwMDlkMDAwLTB4MDAwOWRmZmZd
ClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHgw
MDA5ZTAwMC0weDAwMGZmZmZmXQpbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3Nh
dmUgbWVtb3J5OiBbbWVtIDB4Yzg1MjIwMDAtMHhjODUyOGZmZl0KWyAgICAwLjAwMDAwMF0g
UE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGRiYTg1MDAwLTB4ZGJiMGVm
ZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0g
MHhkYmIwZjAwMC0weGRiYjI4ZmZmXQpbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBu
b3NhdmUgbWVtb3J5OiBbbWVtIDB4ZGJiMjkwMDAtMHhkYmM5MWZmZl0KWyAgICAwLjAwMDAw
MF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGRiYzkyMDAwLTB4ZGJm
ZmVmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFtt
ZW0gMHhkYzAwMDAwMC0weGRjZmZmZmZmXQpbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJl
ZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZGQwMDAwMDAtMHhkZjFmZmZmZl0KWyAgICAwLjAw
MDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGRmMjAwMDAwLTB4
ZjdmZmZmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6
IFttZW0gMHhmODAwMDAwMC0weGZiZmZmZmZmXQpbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0
ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZmMwMDAwMDAtMHhmZWJmZmZmZl0KWyAgICAw
LjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGZlYzAwMDAw
LTB4ZmVjMDBmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v
cnk6IFttZW0gMHhmZWMwMTAwMC0weGZlY2ZmZmZmXQpbICAgIDAuMDAwMDAwXSBQTTogUmVn
aXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZmVkMDAwMDAtMHhmZWQwM2ZmZl0KWyAg
ICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGZlZDA0
MDAwLTB4ZmVkMWJmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBt
ZW1vcnk6IFttZW0gMHhmZWQxYzAwMC0weGZlZDFmZmZmXQpbICAgIDAuMDAwMDAwXSBQTTog
UmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZmVkMjAwMDAtMHhmZWQ4ZmZmZl0K
WyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweGZl
ZDkwMDAwLTB4ZmVkOTFmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2
ZSBtZW1vcnk6IFttZW0gMHhmZWQ5MjAwMC0weGZlZGZmZmZmXQpbICAgIDAuMDAwMDAwXSBQ
TTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZmVlMDAwMDAtMHhmZWVmZmZm
Zl0KWyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAw
eGZlZjAwMDAwLTB4ZmVmZmZmZmZdClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5v
c2F2ZSBtZW1vcnk6IFttZW0gMHhmZjAwMDAwMC0weGZmZmZmZmZmXQpbICAgIDAuMDAwMDAw
XSBlODIwOiBbbWVtIDB4ZGYyMDAwMDAtMHhmN2ZmZmZmZl0gYXZhaWxhYmxlIGZvciBQQ0kg
ZGV2aWNlcwpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwg
b24gWGVuClsgICAgMC4wMDAwMDBdIFhlbiB2ZXJzaW9uOiA0LjUuMC1yYyAocHJlc2VydmUt
QUQpClsgICAgMC4wMDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo1MTIgbnJfY3B1bWFz
a19iaXRzOjUxMiBucl9jcHVfaWRzOjQgbnJfbm9kZV9pZHM6MQpbICAgIDAuMDAwMDAwXSBQ
RVJDUFU6IEVtYmVkZGVkIDI4IHBhZ2VzL2NwdSBAZmZmZjg4MDExMmMwMDAwMCBzODU2OTYg
cjgxOTIgZDIwODAwIHU1MjQyODgKWyAgICAwLjAwMDAwMF0gcGNwdS1hbGxvYzogczg1Njk2
IHI4MTkyIGQyMDgwMCB1NTI0Mjg4IGFsbG9jPTEqMjA5NzE1MgpbICAgIDAuMDAwMDAwXSBw
Y3B1LWFsbG9jOiBbMF0gMCAxIDIgMyAKWyAgICAwLjAwMDAwMF0gQnVpbHQgMSB6b25lbGlz
dHMgaW4gTm9kZSBvcmRlciwgbW9iaWxpdHkgZ3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczog
MTAxNjA2NApbICAgIDAuMDAwMDAwXSBQb2xpY3kgem9uZTogTm9ybWFsClsgICAgMC4wMDAw
MDBdIEtlcm5lbCBjb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVyIHJvb3Q9VVVJRD05ZDJmODBm
OS04YmRjLTQ3MDYtYjc0YS1iNDc2MDU2OTIyZDcgcm8gcXVpZXQKWyAgICAwLjAwMDAwMF0g
UElEIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQpb
ICAgIDAuMDAwMDAwXSB4c2F2ZTogZW5hYmxlZCB4c3RhdGVfYnYgMHg3LCBjbnR4dCBzaXpl
IDB4MzQwClsgICAgMC4wMDAwMDBdIHNvZnR3YXJlIElPIFRMQiBbbWVtIDB4MTBhZTAwMDAw
LTB4MTBlZTAwMDAwXSAoNjRNQikgbWFwcGVkIGF0IFtmZmZmODgwMTBhZTAwMDAwLWZmZmY4
ODAxMGVkZmZmZmZdClsgICAgMC4wMDAwMDBdIE1lbW9yeTogMzczMDQ0OEsvNDEyMDY4NEsg
YXZhaWxhYmxlICg1NDI2SyBrZXJuZWwgY29kZSwgOTM2SyByd2RhdGEsIDE4MjRLIHJvZGF0
YSwgMTIwNEsgaW5pdCwgODQwSyBic3MsIDM5MDIzNksgcmVzZXJ2ZWQpClsgICAgMC4wMDAw
MDBdIEhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uClsgICAgMC4wMDAwMDBdIAlS
Q1UgZHludGljay1pZGxlIGdyYWNlLXBlcmlvZCBhY2NlbGVyYXRpb24gaXMgZW5hYmxlZC4K
WyAgICAwLjAwMDAwMF0gCVJDVSByZXN0cmljdGluZyBDUFVzIGZyb20gTlJfQ1BVUz01MTIg
dG8gbnJfY3B1X2lkcz0yLgpbICAgIDAuMDAwMDAwXSBSQ1U6IEFkanVzdGluZyBnZW9tZXRy
eSBmb3IgcmN1X2Zhbm91dF9sZWFmPTE2LCBucl9jcHVfaWRzPTIKWyAgICAwLjAwMDAwMF0g
TlJfSVJRUzozMzAyNCBucl9pcnFzOjUxMiAxNgpbICAgIDAuMDAwMDAwXSB4ZW46ZXZlbnRz
OiBVc2luZyBGSUZPLWJhc2VkIEFCSQpbICAgIDAuMDAwMDAwXSB4ZW46IHNjaSBvdmVycmlk
ZTogZ2xvYmFsX2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0wClsgICAgMC4wMDAwMDBdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDAKWyAgICAwLjAw
MDAwMF0geGVuOiAtLT4gcGlycT05IC0+IGlycT05IChnc2k9OSkKWyAgICAwLjAwMDAwMF0g
eGVuOiBhY3BpIHNjaSA5ClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9
MSAoZ3NpPTEpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3Np
PTIpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MyAtPiBpcnE9MyAoZ3NpPTMpClsg
ICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NCAtPiBpcnE9NCAoZ3NpPTQpClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9NSAtPiBpcnE9NSAoZ3NpPTUpClsgICAgMC4wMDAwMDBd
IHhlbjogLS0+IHBpcnE9NiAtPiBpcnE9NiAoZ3NpPTYpClsgICAgMC4wMDAwMDBdIHhlbjog
LS0+IHBpcnE9NyAtPiBpcnE9NyAoZ3NpPTcpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBp
cnE9OCAtPiBpcnE9OCAoZ3NpPTgpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTAg
LT4gaXJxPTEwIChnc2k9MTApClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTEgLT4g
aXJxPTExIChnc2k9MTEpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTIgLT4gaXJx
PTEyIChnc2k9MTIpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTMgLT4gaXJxPTEz
IChnc2k9MTMpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTQgLT4gaXJxPTE0IChn
c2k9MTQpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTUgLT4gaXJxPTE1IChnc2k9
MTUpClsgICAgMC4wMDAwMDBdIENvbnNvbGU6IGNvbG91ciBWR0ErIDgweDI1ClsgICAgMC4w
MDAwMDBdIGNvbnNvbGUgW3R0eTBdIGVuYWJsZWQKWyAgICAwLjAwMDAwMF0gWGVuOiB1c2lu
ZyB2Y3B1b3AgdGltZXIgaW50ZXJmYWNlClsgICAgMC4wMDAwMDBdIGluc3RhbGxpbmcgWGVu
IHRpbWVyIGZvciBDUFUgMApbICAgIDAuMDAwMDAwXSB0c2M6IERldGVjdGVkIDE2OTYuMTQ2
IE1IeiBwcm9jZXNzb3IKWyAgICAzLjQ4MzM0Ml0gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcCAo
c2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gMzM5
Mi4yOSBCb2dvTUlQUyAobHBqPTY3ODQ1ODQpClsgICAgMy40ODMzNDZdIHBpZF9tYXg6IGRl
ZmF1bHQ6IDMyNzY4IG1pbmltdW06IDMwMQpbICAgIDMuNDgzMzU2XSBBQ1BJOiBDb3JlIHJl
dmlzaW9uIDIwMTQwNDI0ClsgICAgMy40OTkzNjldIEFDUEk6IEFsbCBBQ1BJIFRhYmxlcyBz
dWNjZXNzZnVsbHkgYWNxdWlyZWQKWyAgICAzLjUwMDAxMF0gU2VjdXJpdHkgRnJhbWV3b3Jr
IGluaXRpYWxpemVkClsgICAgMy41MDAwMjBdIEFwcEFybW9yOiBBcHBBcm1vciBkaXNhYmxl
ZCBieSBib290IHRpbWUgcGFyYW1ldGVyClsgICAgMy41MDAwMjJdIFlhbWE6IGRpc2FibGVk
IGJ5IGRlZmF1bHQ7IGVuYWJsZSB3aXRoIHN5c2N0bCBrZXJuZWwueWFtYS4qClsgICAgMy41
MDEwMTFdIERlbnRyeSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUyNDI4OCAob3JkZXI6
IDEwLCA0MTk0MzA0IGJ5dGVzKQpbICAgIDMuNTAyMzg1XSBJbm9kZS1jYWNoZSBoYXNoIHRh
YmxlIGVudHJpZXM6IDI2MjE0NCAob3JkZXI6IDksIDIwOTcxNTIgYnl0ZXMpClsgICAgMy41
MDI4MTBdIE1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogODE5MiAob3JkZXI6IDQs
IDY1NTM2IGJ5dGVzKQpbICAgIDMuNTAyODI4XSBNb3VudHBvaW50LWNhY2hlIGhhc2ggdGFi
bGUgZW50cmllczogODE5MiAob3JkZXI6IDQsIDY1NTM2IGJ5dGVzKQpbICAgIDMuNTAzMTE0
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBtZW1vcnkKWyAgICAzLjUwMzExOV0gSW5p
dGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZGV2aWNlcwpbICAgIDMuNTAzMTI3XSBJbml0aWFs
aXppbmcgY2dyb3VwIHN1YnN5cyBmcmVlemVyClsgICAgMy41MDMxMzBdIEluaXRpYWxpemlu
ZyBjZ3JvdXAgc3Vic3lzIG5ldF9jbHMKWyAgICAzLjUwMzEzNF0gSW5pdGlhbGl6aW5nIGNn
cm91cCBzdWJzeXMgYmxraW8KWyAgICAzLjUwMzEzOF0gSW5pdGlhbGl6aW5nIGNncm91cCBz
dWJzeXMgcGVyZl9ldmVudApbICAgIDMuNTAzMTQxXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1
YnN5cyBuZXRfcHJpbwpbICAgIDMuNTAzMjE3XSBFTkVSR1lfUEVSRl9CSUFTOiBTZXQgdG8g
J25vcm1hbCcsIHdhcyAncGVyZm9ybWFuY2UnClsgICAgMy41MDMyMTddIEVORVJHWV9QRVJG
X0JJQVM6IFZpZXcgYW5kIHVwZGF0ZSB3aXRoIHg4Nl9lbmVyZ3lfcGVyZl9wb2xpY3koOCkK
WyAgICAzLjUwMzIyMl0gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6IDAKWyAgICAzLjUw
MzIyM10gQ1BVOiBQcm9jZXNzb3IgQ29yZSBJRDogMApbICAgIDMuNTA0Mzk3XSBtY2U6IENQ
VSBzdXBwb3J0cyAyIE1DRSBiYW5rcwpbICAgIDMuNTA0NDE4XSBMYXN0IGxldmVsIGlUTEIg
ZW50cmllczogNEtCIDEwMjQsIDJNQiAxMDI0LCA0TUIgMTAyNApbICAgIDMuNTA0NDE4XSBM
YXN0IGxldmVsIGRUTEIgZW50cmllczogNEtCIDEwMjQsIDJNQiAxMDI0LCA0TUIgMTAyNCwg
MUdCIDQKWyAgICAzLjUwNDQxOF0gdGxiX2ZsdXNoYWxsX3NoaWZ0OiA2ClsgICAgMy41MDQ1
MjJdIEZyZWVpbmcgU01QIGFsdGVybmF0aXZlcyBtZW1vcnk6IDIwSyAoZmZmZmZmZmY4MWEx
ODAwMCAtIGZmZmZmZmZmODFhMWQwMDApClsgICAgMy41MDU2ODJdIGZ0cmFjZTogYWxsb2Nh
dGluZyAyMTU0NCBlbnRyaWVzIGluIDg1IHBhZ2VzClsgICAgMy41MTU3OTRdIFBlcmZvcm1h
bmNlIEV2ZW50czogdW5zdXBwb3J0ZWQgcDYgQ1BVIG1vZGVsIDY5IG5vIFBNVSBkcml2ZXIs
IHNvZnR3YXJlIGV2ZW50cyBvbmx5LgpbICAgIDMuNTE3NTc1XSBOTUkgd2F0Y2hkb2c6IGRp
c2FibGVkIChjcHUwKTogaGFyZHdhcmUgZXZlbnRzIG5vdCBlbmFibGVkClsgICAgMy41MTc2
ODJdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMQpbICAgIDMuNTE5MTQxXSB4ODY6
IEJvb3RlZCB1cCAxIG5vZGUsIDIgQ1BVcwpbICAgIDMuNTE5MzQ3XSBkZXZ0bXBmczogaW5p
dGlhbGl6ZWQKWyAgICAzLjUyMzg2OF0gUE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJlZ2lv
biBbbWVtIDB4Yzg1MjIwMDAtMHhjODUyOGZmZl0gKDI4NjcyIGJ5dGVzKQpbICAgIDMuNTIz
ODcxXSBQTTogUmVnaXN0ZXJpbmcgQUNQSSBOVlMgcmVnaW9uIFttZW0gMHhkYmIyOTAwMC0w
eGRiYzkxZmZmXSAoMTQ3ODY1NiBieXRlcykKWyAgICAzLjUyNDkwNV0gcGluY3RybCBjb3Jl
OiBpbml0aWFsaXplZCBwaW5jdHJsIHN1YnN5c3RlbQpbICAgIDMuNTI1MDA3XSBORVQ6IFJl
Z2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE2ClsgICAgMy41MjUwMjFdIHhlbjpncmFudF90
YWJsZTogR3JhbnQgdGFibGVzIHVzaW5nIHZlcnNpb24gMSBsYXlvdXQKWyAgICAzLjUyNTAz
NV0gR3JhbnQgdGFibGUgaW5pdGlhbGl6ZWQKWyAgICAzLjUyNTM0MV0gQUNQSSBGQURUIGRl
Y2xhcmVzIHRoZSBzeXN0ZW0gZG9lc24ndCBzdXBwb3J0IFBDSWUgQVNQTSwgc28gZGlzYWJs
ZSBpdApbICAgIDMuNTI1MzQ0XSBBQ1BJOiBidXMgdHlwZSBQQ0kgcmVnaXN0ZXJlZApbICAg
IDMuNTI1MzQ2XSBhY3BpcGhwOiBBQ1BJIEhvdCBQbHVnIFBDSSBDb250cm9sbGVyIERyaXZl
ciB2ZXJzaW9uOiAwLjUKWyAgICAzLjUyNTU1N10gUENJOiBNTUNPTkZJRyBmb3IgZG9tYWlu
IDAwMDAgW2J1cyAwMC0zZl0gYXQgW21lbSAweGY4MDAwMDAwLTB4ZmJmZmZmZmZdIChiYXNl
IDB4ZjgwMDAwMDApClsgICAgMy41MjU1NjBdIFBDSTogTU1DT05GSUcgYXQgW21lbSAweGY4
MDAwMDAwLTB4ZmJmZmZmZmZdIHJlc2VydmVkIGluIEU4MjAKWyAgICAzLjUzNjE0NF0gUENJ
OiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgYmFzZSBhY2Nlc3MKWyAgICAzLjU0
ODUzNF0gQUNQSTogQWRkZWQgX09TSShNb2R1bGUgRGV2aWNlKQpbICAgIDMuNTQ4NTM4XSBB
Q1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBEZXZpY2UpClsgICAgMy41NDg1NDBdIEFDUEk6
IEFkZGVkIF9PU0koMy4wIF9TQ1AgRXh0ZW5zaW9ucykKWyAgICAzLjU0ODU0Ml0gQUNQSTog
QWRkZWQgX09TSShQcm9jZXNzb3IgQWdncmVnYXRvciBEZXZpY2UpClsgICAgMy41NTM2OTBd
IEFDUEk6IEV4ZWN1dGVkIDEgYmxvY2tzIG9mIG1vZHVsZS1sZXZlbCBleGVjdXRhYmxlIEFN
TCBjb2RlClsgICAgMy41Njc0MjVdIFtGaXJtd2FyZSBCdWddOiBBQ1BJOiBCSU9TIF9PU0ko
TGludXgpIHF1ZXJ5IGlnbm9yZWQKWyAgICAzLjU3OTczN10gQUNQSTogRHluYW1pYyBPRU0g
VGFibGUgTG9hZDoKWyAgICAzLjU3OTc0N10gQUNQSTogU1NEVCAweEZGRkY4ODAxMEExODE4
MDAgMDAwM0QzICh2MDEgUG1SZWYgIENwdTBDc3QgIDAwMDAzMDAxIElOVEwgMjAxMjA3MTEp
ClsgICAgMy41OTIxMTRdIEFDUEk6IER5bmFtaWMgT0VNIFRhYmxlIExvYWQ6ClsgICAgMy41
OTIxMjRdIEFDUEk6IFNTRFQgMHhGRkZGODgwMTBBMTcxMDAwIDAwMDVBQSAodjAxIFBtUmVm
ICBBcElzdCAgICAwMDAwMzAwMCBJTlRMIDIwMTIwNzExKQpbICAgIDMuNjA0MTIxXSBBQ1BJ
OiBEeW5hbWljIE9FTSBUYWJsZSBMb2FkOgpbICAgIDMuNjA0MTI5XSBBQ1BJOiBTU0RUIDB4
RkZGRjg4MDEwQTE4REEwMCAwMDAxMTkgKHYwMSBQbVJlZiAgQXBDc3QgICAgMDAwMDMwMDAg
SU5UTCAyMDEyMDcxMSkKWyAgICAzLjYxNjY1NV0gQUNQSTogSW50ZXJwcmV0ZXIgZW5hYmxl
ZApbICAgIDMuNjE2NjY2XSBBQ1BJIEV4Y2VwdGlvbjogQUVfTk9UX0ZPVU5ELCBXaGlsZSBl
dmFsdWF0aW5nIFNsZWVwIFN0YXRlIFtcX1MxX10gKDIwMTQwNDI0L2h3eGZhY2UtNTgwKQpb
ICAgIDMuNjE2Njc0XSBBQ1BJIEV4Y2VwdGlvbjogQUVfTk9UX0ZPVU5ELCBXaGlsZSBldmFs
dWF0aW5nIFNsZWVwIFN0YXRlIFtcX1MyX10gKDIwMTQwNDI0L2h3eGZhY2UtNTgwKQpbICAg
IDMuNjE2Njk2XSBBQ1BJOiAoc3VwcG9ydHMgUzAgUzMgUzQgUzUpClsgICAgMy42MTY2OThd
IEFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0IHJvdXRpbmcKWyAgICAzLjYxNjc0
NF0gUENJOiBVc2luZyBob3N0IGJyaWRnZSB3aW5kb3dzIGZyb20gQUNQSTsgaWYgbmVjZXNz
YXJ5LCB1c2UgInBjaT1ub2NycyIgYW5kIHJlcG9ydCBhIGJ1ZwpbICAgIDMuNjI5Mzc1XSBB
Q1BJOiBQb3dlciBSZXNvdXJjZSBbRk4wMF0gKG9mZikKWyAgICAzLjYyOTQ2OF0gQUNQSTog
UG93ZXIgUmVzb3VyY2UgW0ZOMDFdIChvZmYpClsgICAgMy42Mjk1NTddIEFDUEk6IFBvd2Vy
IFJlc291cmNlIFtGTjAyXSAob2ZmKQpbICAgIDMuNjI5NjQ0XSBBQ1BJOiBQb3dlciBSZXNv
dXJjZSBbRk4wM10gKG9mZikKWyAgICAzLjYyOTczNF0gQUNQSTogUG93ZXIgUmVzb3VyY2Ug
W0ZOMDRdIChvZmYpClsgICAgMy42MzA3MDJdIEFDUEk6IFBDSSBSb290IEJyaWRnZSBbUENJ
MF0gKGRvbWFpbiAwMDAwIFtidXMgMDAtM2VdKQpbICAgIDMuNjMwNzA5XSBhY3BpIFBOUDBB
MDg6MDA6IF9PU0M6IE9TIHN1cHBvcnRzIFtFeHRlbmRlZENvbmZpZyBBU1BNIENsb2NrUE0g
U2VnbWVudHMgTVNJXQpbICAgIDMuNjMxOTUwXSBhY3BpIFBOUDBBMDg6MDA6IF9PU0M6IHBs
YXRmb3JtIGRvZXMgbm90IHN1cHBvcnQgW1BDSWVIb3RwbHVnIFBNRV0KWyAgICAzLjYzMjEx
MV0gYWNwaSBQTlAwQTA4OjAwOiBfT1NDOiBPUyBub3cgY29udHJvbHMgW0FFUiBQQ0llQ2Fw
YWJpbGl0eV0KWyAgICAzLjYzMzAwOV0gUENJIGhvc3QgYnJpZGdlIHRvIGJ1cyAwMDAwOjAw
ClsgICAgMy42MzMwMTNdIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2J1
cyAwMC0zZV0KWyAgICAzLjYzMzAxNV0gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNv
dXJjZSBbaW8gIDB4MDAwMC0weDBjZjddClsgICAgMy42MzMwMTddIHBjaV9idXMgMDAwMDow
MDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDBkMDAtMHhmZmZmXQpbICAgIDMuNjMzMDE5
XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBhMDAwMC0w
eDAwMGJmZmZmXQpbICAgIDMuNjMzMDIxXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJl
c291cmNlIFttZW0gMHgwMDBkMDAwMC0weDAwMGQzZmZmXQpbICAgIDMuNjMzMDIzXSBwY2lf
YnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBkNDAwMC0weDAwMGQ3
ZmZmXQpbICAgIDMuNjMzMDI0XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNl
IFttZW0gMHgwMDBkODAwMC0weDAwMGRiZmZmXQpbICAgIDMuNjMzMDI2XSBwY2lfYnVzIDAw
MDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBkYzAwMC0weDAwMGRmZmZmXQpb
ICAgIDMuNjMzMDI4XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0g
MHgwMDBlMDAwMC0weDAwMGUzZmZmXQpbICAgIDMuNjMzMDMwXSBwY2lfYnVzIDAwMDA6MDA6
IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBlNDAwMC0weDAwMGU3ZmZmXQpbICAgIDMu
NjMzMDMxXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHhkZjIw
MDAwMC0weGZlYWZmZmZmXQpbICAgIDMuNjMzMDUxXSBwY2kgMDAwMDowMDowMC4wOiBbODA4
NjowYTA0XSB0eXBlIDAwIGNsYXNzIDB4MDYwMDAwClsgICAgMy42MzMyODldIHBjaSAwMDAw
OjAwOjAyLjA6IFs4MDg2OjBhMTZdIHR5cGUgMDAgY2xhc3MgMHgwMzAwMDAKWyAgICAzLjYz
MzMzM10gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDB4MTA6IFttZW0gMHhmNzgwMDAwMC0weGY3
YmZmZmZmIDY0Yml0XQpbICAgIDMuNjMzMzU2XSBwY2kgMDAwMDowMDowMi4wOiByZWcgMHgx
ODogW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmYgNjRiaXQgcHJlZl0KWyAgICAzLjYzMzM3
Ml0gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDB4MjA6IFtpbyAgMHhmMDAwLTB4ZjAzZl0KWyAg
ICAzLjYzMzU5MV0gcGNpIDAwMDA6MDA6MDMuMDogWzgwODY6MGEwY10gdHlwZSAwMCBjbGFz
cyAweDA0MDMwMApbICAgIDMuNjMzNjIxXSBwY2kgMDAwMDowMDowMy4wOiByZWcgMHgxMDog
W21lbSAweGY3ZDM0MDAwLTB4ZjdkMzdmZmYgNjRiaXRdClsgICAgMy42MzM5MDhdIHBjaSAw
MDAwOjAwOjE0LjA6IFs4MDg2OjljMzFdIHR5cGUgMDAgY2xhc3MgMHgwYzAzMzAKWyAgICAz
LjYzMzk1NV0gcGNpIDAwMDA6MDA6MTQuMDogcmVnIDB4MTA6IFttZW0gMHhmN2QyMDAwMC0w
eGY3ZDJmZmZmIDY0Yml0XQpbICAgIDMuNjM0MTA3XSBwY2kgMDAwMDowMDoxNC4wOiBQTUUj
IHN1cHBvcnRlZCBmcm9tIEQzaG90IEQzY29sZApbICAgIDMuNjM0MTY5XSBwY2kgMDAwMDow
MDoxNC4wOiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkKWyAgICAzLjYzNDI0OV0g
cGNpIDAwMDA6MDA6MTYuMDogWzgwODY6OWMzYV0gdHlwZSAwMCBjbGFzcyAweDA3ODAwMApb
ICAgIDMuNjM0Mjk3XSBwY2kgMDAwMDowMDoxNi4wOiByZWcgMHgxMDogW21lbSAweGY3ZDNl
MDAwLTB4ZjdkM2UwMWYgNjRiaXRdClsgICAgMy42MzQ0NTldIHBjaSAwMDAwOjAwOjE2LjA6
IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgMy42MzQ2MTNdIHBj
aSAwMDAwOjAwOjE5LjA6IFs4MDg2OjE1NTldIHR5cGUgMDAgY2xhc3MgMHgwMjAwMDAKWyAg
ICAzLjYzNDY1NF0gcGNpIDAwMDA6MDA6MTkuMDogcmVnIDB4MTA6IFttZW0gMHhmN2QwMDAw
MC0weGY3ZDFmZmZmXQpbICAgIDMuNjM0NjcyXSBwY2kgMDAwMDowMDoxOS4wOiByZWcgMHgx
NDogW21lbSAweGY3ZDNjMDAwLTB4ZjdkM2NmZmZdClsgICAgMy42MzQ2OTBdIHBjaSAwMDAw
OjAwOjE5LjA6IHJlZyAweDE4OiBbaW8gIDB4ZjA4MC0weGYwOWZdClsgICAgMy42MzQ4Mzld
IHBjaSAwMDAwOjAwOjE5LjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xk
ClsgICAgMy42MzQ5MDNdIHBjaSAwMDAwOjAwOjE5LjA6IFN5c3RlbSB3YWtldXAgZGlzYWJs
ZWQgYnkgQUNQSQpbICAgIDMuNjM0OTg3XSBwY2kgMDAwMDowMDoxYi4wOiBbODA4Njo5YzIw
XSB0eXBlIDAwIGNsYXNzIDB4MDQwMzAwClsgICAgMy42MzUwMjJdIHBjaSAwMDAwOjAwOjFi
LjA6IHJlZyAweDEwOiBbbWVtIDB4ZjdkMzAwMDAtMHhmN2QzM2ZmZiA2NGJpdF0KWyAgICAz
LjYzNTE4OV0gcGNpIDAwMDA6MDA6MWIuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hv
dCBEM2NvbGQKWyAgICAzLjYzNTI1NF0gcGNpIDAwMDA6MDA6MWIuMDogU3lzdGVtIHdha2V1
cCBkaXNhYmxlZCBieSBBQ1BJClsgICAgMy42MzUzMzNdIHBjaSAwMDAwOjAwOjFjLjA6IFs4
MDg2OjljMTBdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDAKWyAgICAzLjYzNTUxM10gcGNpIDAw
MDA6MDA6MWMuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICAz
LjYzNTU3M10gcGNpIDAwMDA6MDA6MWMuMDogRW5hYmxpbmcgTVBDIElSQk5DRQpbICAgIDMu
NjM1NTc3XSBwY2kgMDAwMDowMDoxYy4wOiBJbnRlbCBQQ0ggcm9vdCBwb3J0IEFDUyB3b3Jr
YXJvdW5kIGVuYWJsZWQKWyAgICAzLjYzNTYyMF0gcGNpIDAwMDA6MDA6MWMuMDogU3lzdGVt
IHdha2V1cCBkaXNhYmxlZCBieSBBQ1BJClsgICAgMy42MzU3MTFdIHBjaSAwMDAwOjAwOjFj
LjM6IFs4MDg2OjljMTZdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDAKWyAgICAzLjYzNTg5NV0g
cGNpIDAwMDA6MDA6MWMuMzogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQK
WyAgICAzLjYzNTk1MF0gcGNpIDAwMDA6MDA6MWMuMzogRW5hYmxpbmcgTVBDIElSQk5DRQpb
ICAgIDMuNjM1OTU0XSBwY2kgMDAwMDowMDoxYy4zOiBJbnRlbCBQQ0ggcm9vdCBwb3J0IEFD
UyB3b3JrYXJvdW5kIGVuYWJsZWQKWyAgICAzLjYzNTk5N10gcGNpIDAwMDA6MDA6MWMuMzog
U3lzdGVtIHdha2V1cCBkaXNhYmxlZCBieSBBQ1BJClsgICAgMy42MzYwOTZdIHBjaSAwMDAw
OjAwOjFkLjA6IFs4MDg2OjljMjZdIHR5cGUgMDAgY2xhc3MgMHgwYzAzMjAKWyAgICAzLjYz
NjE0MV0gcGNpIDAwMDA6MDA6MWQuMDogcmVnIDB4MTA6IFttZW0gMHhmN2QzYjAwMC0weGY3
ZDNiM2ZmXQpbICAgIDMuNjM2MzU2XSBwY2kgMDAwMDowMDoxZC4wOiBQTUUjIHN1cHBvcnRl
ZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDMuNjM2NDQ1XSBwY2kgMDAwMDowMDoxZC4w
OiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkKWyAgICAzLjYzNjUyNV0gcGNpIDAw
MDA6MDA6MWYuMDogWzgwODY6OWM0M10gdHlwZSAwMCBjbGFzcyAweDA2MDEwMApbICAgIDMu
NjM2ODgyXSBwY2kgMDAwMDowMDoxZi4yOiBbODA4Njo5YzAzXSB0eXBlIDAwIGNsYXNzIDB4
MDEwNjAxClsgICAgMy42MzY5MjRdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAweDEwOiBbaW8g
IDB4ZjBkMC0weGYwZDddClsgICAgMy42MzY5NDFdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAw
eDE0OiBbaW8gIDB4ZjBjMC0weGYwYzNdClsgICAgMy42MzY5NTldIHBjaSAwMDAwOjAwOjFm
LjI6IHJlZyAweDE4OiBbaW8gIDB4ZjBiMC0weGYwYjddClsgICAgMy42MzY5NzZdIHBjaSAw
MDAwOjAwOjFmLjI6IHJlZyAweDFjOiBbaW8gIDB4ZjBhMC0weGYwYTNdClsgICAgMy42MzY5
OTNdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAweDIwOiBbaW8gIDB4ZjA2MC0weGYwN2ZdClsg
ICAgMy42MzcwMTFdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAweDI0OiBbbWVtIDB4ZjdkM2Ew
MDAtMHhmN2QzYTdmZl0KWyAgICAzLjYzNzExMF0gcGNpIDAwMDA6MDA6MWYuMjogUE1FIyBz
dXBwb3J0ZWQgZnJvbSBEM2hvdApbICAgIDMuNjM3MjMzXSBwY2kgMDAwMDowMDoxZi4zOiBb
ODA4Njo5YzIyXSB0eXBlIDAwIGNsYXNzIDB4MGMwNTAwClsgICAgMy42MzcyNjhdIHBjaSAw
MDAwOjAwOjFmLjM6IHJlZyAweDEwOiBbbWVtIDB4ZjdkMzkwMDAtMHhmN2QzOTBmZiA2NGJp
dF0KWyAgICAzLjYzNzMxOF0gcGNpIDAwMDA6MDA6MWYuMzogcmVnIDB4MjA6IFtpbyAgMHhm
MDQwLTB4ZjA1Zl0KWyAgICAzLjYzNzYxMF0gYWNwaXBocDogU2xvdCBbMV0gcmVnaXN0ZXJl
ZApbICAgIDMuNjM3NjI2XSBwY2kgMDAwMDowMDoxYy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMg
MDFdClsgICAgMy42Mzc4NDRdIHBjaSAwMDAwOjAyOjAwLjA6IFs4MDg2OjA4ODddIHR5cGUg
MDAgY2xhc3MgMHgwMjgwMDAKWyAgICAzLjYzNzkwMl0gcGNpIDAwMDA6MDI6MDAuMDogcmVn
IDB4MTA6IFttZW0gMHhmN2MwMDAwMC0weGY3YzAxZmZmIDY0Yml0XQpbICAgIDMuNjM4MTcy
XSBwY2kgMDAwMDowMjowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29s
ZApbICAgIDMuNjM4MjI4XSBwY2kgMDAwMDowMjowMC4wOiBTeXN0ZW0gd2FrZXVwIGRpc2Fi
bGVkIGJ5IEFDUEkKWyAgICAzLjY0ODQ0Nl0gcGNpIDAwMDA6MDA6MWMuMzogUENJIGJyaWRn
ZSB0byBbYnVzIDAyXQpbICAgIDMuNjQ4NDYzXSBwY2kgMDAwMDowMDoxYy4zOiAgIGJyaWRn
ZSB3aW5kb3cgW21lbSAweGY3YzAwMDAwLTB4ZjdjZmZmZmZdClsgICAgMy42NDg1MzNdIGFj
cGkgUE5QMEEwODowMDogRGlzYWJsaW5nIEFTUE0gKEZBRFQgaW5kaWNhdGVzIGl0IGlzIHVu
c3VwcG9ydGVkKQpbICAgIDMuNjQ5NzU2XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xO
S0FdIChJUlFzIDMgNCA1IDYgMTAgKjExIDEyIDE0IDE1KQpbICAgIDMuNjQ5ODE5XSBBQ1BJ
OiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0JdIChJUlFzIDMgNCA1IDYgMTAgMTEgMTIgMTQg
MTUpICowLCBkaXNhYmxlZC4KWyAgICAzLjY0OTg3OV0gQUNQSTogUENJIEludGVycnVwdCBM
aW5rIFtMTktDXSAoSVJRcyAzIDQgNSA2ICoxMCAxMSAxMiAxNCAxNSkKWyAgICAzLjY0OTkz
OF0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyAzIDQgNSA2ICoxMCAx
MSAxMiAxNCAxNSkKWyAgICAzLjY0OTk5Nl0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtM
TktFXSAoSVJRcyAzIDQgKjUgNiAxMCAxMSAxMiAxNCAxNSkKWyAgICAzLjY1MDA1OF0gQUNQ
STogUENJIEludGVycnVwdCBMaW5rIFtMTktGXSAoSVJRcyAzIDQgNSA2IDEwIDExIDEyIDE0
IDE1KSAqMCwgZGlzYWJsZWQuClsgICAgMy42NTAxMTddIEFDUEk6IFBDSSBJbnRlcnJ1cHQg
TGluayBbTE5LR10gKElSUXMgKjMgNCA1IDYgMTAgMTEgMTIgMTQgMTUpClsgICAgMy42NTAx
NzRdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LSF0gKElSUXMgMyA0IDUgNiAxMCAq
MTEgMTIgMTQgMTUpClsgICAgMy42NTA1NTRdIEFDUEk6IEVuYWJsZWQgNSBHUEVzIGluIGJs
b2NrIDAwIHRvIDdGClsgICAgMy42NTA2MjJdIHhlbjpiYWxsb29uOiBJbml0aWFsaXNpbmcg
YmFsbG9vbiBkcml2ZXIKWyAgICAzLjY1MTQyNl0geGVuX2JhbGxvb246IEluaXRpYWxpc2lu
ZyBiYWxsb29uIGRyaXZlcgpbICAgIDMuNjUxNTU4XSB2Z2FhcmI6IHNldHRpbmcgYXMgYm9v
dCBkZXZpY2U6IFBDSTowMDAwOjAwOjAyLjAKWyAgICAzLjY1MTU2MF0gdmdhYXJiOiBkZXZp
Y2UgYWRkZWQ6IFBDSTowMDAwOjAwOjAyLjAsZGVjb2Rlcz1pbyttZW0sb3ducz1pbyttZW0s
bG9ja3M9bm9uZQpbICAgIDMuNjUxNTY0XSB2Z2FhcmI6IGxvYWRlZApbICAgIDMuNjUxNTY1
XSB2Z2FhcmI6IGJyaWRnZSBjb250cm9sIHBvc3NpYmxlIDAwMDA6MDA6MDIuMApbICAgIDMu
NjUxNjM3XSBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nClsgICAgMy42NTU3ODNd
IFBDSTogcGNpX2NhY2hlX2xpbmVfc2l6ZSBzZXQgdG8gNjQgYnl0ZXMKWyAgICAzLjY1NTg2
Ml0gZTgyMDogcmVzZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHgwMDA5ZDAwMC0weDAwMDlmZmZm
XQpbICAgIDMuNjU1ODY0XSBlODIwOiByZXNlcnZlIFJBTSBidWZmZXIgW21lbSAweGM4NTIy
MDAwLTB4Y2JmZmZmZmZdClsgICAgMy42NTU4NjVdIGU4MjA6IHJlc2VydmUgUkFNIGJ1ZmZl
ciBbbWVtIDB4ZGJhODUwMDAtMHhkYmZmZmZmZl0KWyAgICAzLjY1NTg2N10gZTgyMDogcmVz
ZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHgxMWZlMDAwMDAtMHgxMWZmZmZmZmZdClsgICAgMy42
NTYwNjddIFN3aXRjaGVkIHRvIGNsb2Nrc291cmNlIHhlbgpbICAgIDMuNjYxOTQ0XSBwbnA6
IFBuUCBBQ1BJIGluaXQKWyAgICAzLjY2MTk2Ml0gQUNQSTogYnVzIHR5cGUgUE5QIHJlZ2lz
dGVyZWQKWyAgICAzLjY2MjA1Nl0gc3lzdGVtIDAwOjAwOiBbbWVtIDB4ZmVkNDAwMDAtMHhm
ZWQ0NGZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjA2MF0gc3lzdGVtIDAwOjAw
OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMSAoYWN0aXZlKQpbICAg
IDMuNjYyMjcwXSBzeXN0ZW0gMDA6MDE6IFtpbyAgMHgwNjgwLTB4MDY5Zl0gaGFzIGJlZW4g
cmVzZXJ2ZWQKWyAgICAzLjY2MjI3M10gc3lzdGVtIDAwOjAxOiBbaW8gIDB4ZmZmZl0gaGFz
IGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjI3NV0gc3lzdGVtIDAwOjAxOiBbaW8gIDB4ZmZm
Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjI3N10gc3lzdGVtIDAwOjAxOiBbaW8g
IDB4ZmZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjI4MF0gc3lzdGVtIDAwOjAx
OiBbaW8gIDB4MWMwMC0weDFjZmVdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42NjIyODJd
IHN5c3RlbSAwMDowMTogW2lvICAweDFkMDAtMHgxZGZlXSBoYXMgYmVlbiByZXNlcnZlZApb
ICAgIDMuNjYyMjg0XSBzeXN0ZW0gMDA6MDE6IFtpbyAgMHgxZTAwLTB4MWVmZV0gaGFzIGJl
ZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjI4Nl0gc3lzdGVtIDAwOjAxOiBbaW8gIDB4MWYwMC0w
eDFmZmVdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42NjIyODhdIHN5c3RlbSAwMDowMTog
W2lvICAweDE4MDAtMHgxOGZlXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICAzLjY2MjI5
MF0gc3lzdGVtIDAwOjAxOiBbaW8gIDB4MTY0ZS0weDE2NGZdIGhhcyBiZWVuIHJlc2VydmVk
ClsgICAgMy42NjIyOTNdIHN5c3RlbSAwMDowMTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmlj
ZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAzLjY2MjMwM10geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgOCB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMApbICAgIDMuNjYyMzUwXSBwbnAgMDA6
MDI6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYjAwIChhY3RpdmUpClsg
ICAgMy42NjI0MDddIHN5c3RlbSAwMDowMzogW2lvICAweDE4NTQtMHgxODU3XSBoYXMgYmVl
biByZXNlcnZlZApbICAgIDMuNjYyNDA5XSBzeXN0ZW0gMDA6MDM6IFBsdWcgYW5kIFBsYXkg
QUNQSSBkZXZpY2UsIElEcyBJTlQzZjBkIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAzLjY2MjUz
MV0gc3lzdGVtIDAwOjA0OiBbaW8gIDB4MGEwMC0weDBhMWZdIGhhcyBiZWVuIHJlc2VydmVk
ClsgICAgMy42NjI1MzNdIHN5c3RlbSAwMDowNDogW2lvICAweDBhMDAtMHgwYTBmXSBoYXMg
YmVlbiByZXNlcnZlZApbICAgIDMuNjYyNTM2XSBzeXN0ZW0gMDA6MDQ6IFBsdWcgYW5kIFBs
YXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3RpdmUpClsgICAgMy42NjI2NjldIHBu
cCAwMDowNTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIE5UTjA1MzAgKGRpc2Fi
bGVkKQpbICAgIDMuNjYyNzI0XSBzeXN0ZW0gMDA6MDY6IFtpbyAgMHgwNGQwLTB4MDRkMV0g
aGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjY2MjcyN10gc3lzdGVtIDAwOjA2OiBQbHVnIGFu
ZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMiAoYWN0aXZlKQpbICAgIDMuNjgwMjg1
XSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEwMjAwMC0weGZlMTAyZmZmXSBoYXMgYmVlbiBy
ZXNlcnZlZApbICAgIDMuNjgwMjkwXSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEwNDAwMC0w
eGZlMTA0ZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwMjkzXSBzeXN0ZW0gMDA6
MDc6IFttZW0gMHhmZTEwNjAwMC0weGZlMTA2ZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAg
IDMuNjgwMjk1XSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEwODAwMC0weGZlMTA4ZmZmXSBo
YXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwMjk3XSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhm
ZTEwYTAwMC0weGZlMTBhZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwMjk5XSBz
eXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEwYzAwMC0weGZlMTBjZmZmXSBoYXMgYmVlbiByZXNl
cnZlZApbICAgIDMuNjgwMzAxXSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEwZTAwMC0weGZl
MTBlZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwMzAzXSBzeXN0ZW0gMDA6MDc6
IFttZW0gMHhmZTExMjAwMC0weGZlMTEyZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMu
NjgwMzA2XSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTExMTAwMC0weGZlMTExMDA3XSBoYXMg
YmVlbiByZXNlcnZlZApbICAgIDMuNjgwMzA4XSBzeXN0ZW0gMDA6MDc6IFttZW0gMHhmZTEx
MTAxNC0weGZlMTExZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwMzEyXSBzeXN0
ZW0gMDA6MDc6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3Rp
dmUpClsgICAgMy42ODA3NzBdIHN5c3RlbSAwMDowODogW21lbSAweGZlZDFjMDAwLTB4ZmVk
MWZmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42ODA3NzJdIHN5c3RlbSAwMDowODog
W21lbSAweGZlZDEwMDAwLTB4ZmVkMTdmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42
ODA3NzRdIHN5c3RlbSAwMDowODogW21lbSAweGZlZDE4MDAwLTB4ZmVkMThmZmZdIGhhcyBi
ZWVuIHJlc2VydmVkClsgICAgMy42ODA3NzZdIHN5c3RlbSAwMDowODogW21lbSAweGZlZDE5
MDAwLTB4ZmVkMTlmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42ODA3NzldIHN5c3Rl
bSAwMDowODogW21lbSAweGY4MDAwMDAwLTB4ZmJmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVk
ClsgICAgMy42ODA3ODFdIHN5c3RlbSAwMDowODogW21lbSAweGZlZDIwMDAwLTB4ZmVkM2Zm
ZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy42ODA3ODNdIHN5c3RlbSAwMDowODogW21l
bSAweGZlZDkwMDAwLTB4ZmVkOTNmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDMu
NjgwNzg1XSBzeXN0ZW0gMDA6MDg6IFttZW0gMHhmZWQ0NTAwMC0weGZlZDhmZmZmXSBoYXMg
YmVlbiByZXNlcnZlZApbICAgIDMuNjgwNzg3XSBzeXN0ZW0gMDA6MDg6IFttZW0gMHhmZjAw
MDAwMC0weGZmZmZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwNzkwXSBzeXN0
ZW0gMDA6MDg6IFttZW0gMHhmZWUwMDAwMC0weGZlZWZmZmZmXSBoYXMgYmVlbiByZXNlcnZl
ZApbICAgIDMuNjgwNzkyXSBzeXN0ZW0gMDA6MDg6IFttZW0gMHhmN2ZkZjAwMC0weGY3ZmRm
ZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgwNzk0XSBzeXN0ZW0gMDA6MDg6IFtt
ZW0gMHhmN2ZlMDAwMC0weGY3ZmVmZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuNjgw
Nzk2XSBzeXN0ZW0gMDA6MDg6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAw
YzAyIChhY3RpdmUpClsgICAgMy42ODEwNjNdIHBucDogUG5QIEFDUEk6IGZvdW5kIDkgZGV2
aWNlcwpbICAgIDMuNjgxMDY1XSBBQ1BJOiBidXMgdHlwZSBQTlAgdW5yZWdpc3RlcmVkClsg
ICAgMy42OTE5MjRdIFBNLVRpbWVyIGZhaWxlZCBjb25zaXN0ZW5jeSBjaGVjayAgKDB4ZmZm
ZmZmKSAtIGFib3J0aW5nLgpbICAgIDMuNjkxOTY4XSBwY2kgMDAwMDowMDoxYy4wOiBQQ0kg
YnJpZGdlIHRvIFtidXMgMDFdClsgICAgMy42OTE5OTJdIHBjaSAwMDAwOjAwOjFjLjM6IFBD
SSBicmlkZ2UgdG8gW2J1cyAwMl0KWyAgICAzLjY5MjAwMV0gcGNpIDAwMDA6MDA6MWMuMzog
ICBicmlkZ2Ugd2luZG93IFttZW0gMHhmN2MwMDAwMC0weGY3Y2ZmZmZmXQpbICAgIDMuNjky
MDE4XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDQgW2lvICAweDAwMDAtMHgwY2Y3XQpb
ICAgIDMuNjkyMDIwXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDUgW2lvICAweDBkMDAt
MHhmZmZmXQpbICAgIDMuNjkyMDIyXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDYgW21l
bSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsgICAgMy42OTIwMjRdIHBjaV9idXMgMDAwMDow
MDogcmVzb3VyY2UgNyBbbWVtIDB4MDAwZDAwMDAtMHgwMDBkM2ZmZl0KWyAgICAzLjY5MjAy
Nl0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA4IFttZW0gMHgwMDBkNDAwMC0weDAwMGQ3
ZmZmXQpbICAgIDMuNjkyMDI3XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDkgW21lbSAw
eDAwMGQ4MDAwLTB4MDAwZGJmZmZdClsgICAgMy42OTIwMjldIHBjaV9idXMgMDAwMDowMDog
cmVzb3VyY2UgMTAgW21lbSAweDAwMGRjMDAwLTB4MDAwZGZmZmZdClsgICAgMy42OTIwMzFd
IHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgMTEgW21lbSAweDAwMGUwMDAwLTB4MDAwZTNm
ZmZdClsgICAgMy42OTIwMzNdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgMTIgW21lbSAw
eDAwMGU0MDAwLTB4MDAwZTdmZmZdClsgICAgMy42OTIwMzRdIHBjaV9idXMgMDAwMDowMDog
cmVzb3VyY2UgMTMgW21lbSAweGRmMjAwMDAwLTB4ZmVhZmZmZmZdClsgICAgMy42OTIwMzdd
IHBjaV9idXMgMDAwMDowMjogcmVzb3VyY2UgMSBbbWVtIDB4ZjdjMDAwMDAtMHhmN2NmZmZm
Zl0KWyAgICAzLjY5MjEzMF0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAyClsg
ICAgMy42OTI0NjFdIFRDUCBlc3RhYmxpc2hlZCBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4
IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQpbICAgIDMuNjkyNjIzXSBUQ1AgYmluZCBoYXNo
IHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjogNywgNTI0Mjg4IGJ5dGVzKQpbICAgIDMu
NjkyNjg2XSBUQ1A6IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDMyNzY4
IGJpbmQgMzI3NjgpClsgICAgMy42OTI3MDZdIFRDUDogcmVubyByZWdpc3RlcmVkClsgICAg
My42OTI3MjZdIFVEUCBoYXNoIHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiA0LCA2NTUz
NiBieXRlcykKWyAgICAzLjY5Mjc1NF0gVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAy
MDQ4IChvcmRlcjogNCwgNjU1MzYgYnl0ZXMpClsgICAgMy42OTI4MzNdIE5FVDogUmVnaXN0
ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQpbICAgIDMuNjkyODU5XSBwY2kgMDAwMDowMDowMi4w
OiBWaWRlbyBkZXZpY2Ugd2l0aCBzaGFkb3dlZCBST00KWyAgICAzLjY5Mjk1OF0geGVuOiBy
ZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICAzLjY5Mjk3
MV0geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9MTYgKGdzaT0xNikKWyAgICAzLjY5MzIzNl0g
eGVuOiByZWdpc3RlcmluZyBnc2kgMjMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICAz
LjY5MzI0M10geGVuOiAtLT4gcGlycT0yMyAtPiBpcnE9MjMgKGdzaT0yMykKWyAgICAzLjcx
MjIyNF0gUENJOiBDTFMgNjQgYnl0ZXMsIGRlZmF1bHQgNjQKWyAgICAzLjcxMjI3M10gVW5w
YWNraW5nIGluaXRyYW1mcy4uLgpbICAgIDMuNzU3MDU4XSBGcmVlaW5nIGluaXRyZCBtZW1v
cnk6IDQzNjI0SyAoZmZmZjg4MDAwMWYxNTAwMCAtIGZmZmY4ODAwMDQ5YWYwMDApClsgICAg
My43NTczMThdIFJBUEwgUE1VIGRldGVjdGVkLCBodyB1bml0IDJeLTE0IEpvdWxlcywgQVBJ
IHVuaXQgaXMgMl4tMzIgSm91bGVzLCA0IGZpeGVkIGNvdW50ZXJzIDY1NTM2MCBtcyBvdmZs
IHRpbWVyClsgICAgMy43NTczNzRdIG1pY3JvY29kZTogQ1BVMCBzaWc9MHg0MDY1MSwgcGY9
MHg0MCwgcmV2aXNpb249MHgxNgpbICAgIDMuNzU3Mzg2XSBtaWNyb2NvZGU6IENQVTEgc2ln
PTB4NDA2NTEsIHBmPTB4NDAsIHJldmlzaW9uPTB4MTYKWyAgICAzLjc1NzQ3MF0gbWljcm9j
b2RlOiBNaWNyb2NvZGUgVXBkYXRlIERyaXZlcjogdjIuMDAgPHRpZ3JhbkBhaXZhemlhbi5m
c25ldC5jby51az4sIFBldGVyIE9ydWJhClsgICAgMy43NTc4MTldIGZ1dGV4IGhhc2ggdGFi
bGUgZW50cmllczogNTEyIChvcmRlcjogMywgMzI3NjggYnl0ZXMpClsgICAgMy43NTc4NzFd
IGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0bGluayBzdWJzeXMgKGRpc2FibGVkKQpbICAgIDMu
NzU3ODkwXSBhdWRpdDogdHlwZT0yMDAwIGF1ZGl0KDE0MTYzMTI3NzIuMTAxOjEpOiBpbml0
aWFsaXplZApbICAgIDMuNzU4Mjg0XSBIdWdlVExCIHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNp
emUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcwpbICAgIDMuNzU4MzE0XSB6YnVkOiBsb2FkZWQK
WyAgICAzLjc1ODU3NV0gVkZTOiBEaXNrIHF1b3RhcyBkcXVvdF82LjUuMgpbICAgIDMuNzU4
NTk4XSBEcXVvdC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMiAob3JkZXIgMCwgNDA5
NiBieXRlcykKWyAgICAzLjc1ODY2M10gbXNnbW5pIGhhcyBiZWVuIHNldCB0byA3MzcxClsg
ICAgMy43NTkxOTFdIGFsZzogTm8gdGVzdCBmb3Igc3Rkcm5nIChrcm5nKQpbICAgIDMuNzU5
MjM2XSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40
IGxvYWRlZCAobWFqb3IgMjUyKQpbICAgIDMuNzU5MzEyXSBpbyBzY2hlZHVsZXIgbm9vcCBy
ZWdpc3RlcmVkClsgICAgMy43NTkzMTddIGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdpc3Rl
cmVkClsgICAgMy43NTkzNjNdIGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVs
dCkKWyAgICAzLjc1OTU1NF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDEKWyAgICAzLjc1OTU1OV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNgpb
ICAgIDMuNzU5NzIyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9s
YXJpdHkgMQpbICAgIDMuNzU5NzM2XSB4ZW46IC0tPiBwaXJxPTE5IC0+IGlycT0xOSAoZ3Np
PTE5KQpbICAgIDMuNzU5ODg3XSBwY2lfaG90cGx1ZzogUENJIEhvdCBQbHVnIFBDSSBDb3Jl
IHZlcnNpb246IDAuNQpbICAgIDMuNzU5OTA5XSBwY2llaHA6IFBDSSBFeHByZXNzIEhvdCBQ
bHVnIENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246IDAuNApbICAgIDMuNzU5OTYyXSBpbnRl
bF9pZGxlOiBNV0FJVCBzdWJzdGF0ZXM6IDB4MTExNDIxMjAKWyAgICAzLjc1OTk2M10gaW50
ZWxfaWRsZTogdjAuNCBtb2RlbCAweDQ1ClsgICAgMy43NTk5NjVdIGludGVsX2lkbGU6IGxh
cGljX3RpbWVyX3JlbGlhYmxlX3N0YXRlcyAweGZmZmZmZmZmClsgICAgMy43NTk5ODddIGlu
dGVsX2lkbGU6IGludGVsX2lkbGUgeWllbGRpbmcgdG8gbm9uZQpbICAgIDMuNzYwMDM4XSBH
SEVTOiBIRVNUIGlzIG5vdCBlbmFibGVkIQpbICAgIDMuNzYwNjk0XSBTZXJpYWw6IDgyNTAv
MTY1NTAgZHJpdmVyLCA0IHBvcnRzLCBJUlEgc2hhcmluZyBlbmFibGVkClsgICAgMy43ODE1
NzhdIHNlcmlhbDgyNTA6IHR0eVMwIGF0IEkvTyAweDNmOCAoaXJxID0gNCwgYmFzZV9iYXVk
ID0gMTE1MjAwKSBpcyBhIDE2NTUwQQpbICAgIDMuNzgyMTE0XSBocGV0X2FjcGlfYWRkOiBu
byBhZGRyZXNzIG9yIGlycXMgaW4gX0NSUwpbICAgIDMuNzgyMTQ5XSBMaW51eCBhZ3BnYXJ0
IGludGVyZmFjZSB2MC4xMDMKWyAgICAzLjc4MjI3MV0gaTgwNDI6IFBOUDogTm8gUFMvMiBj
b250cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5LgpbICAgIDQuODM1MDc3
XSBpODA0MjogTm8gY29udHJvbGxlciBmb3VuZApbICAgIDQuODM1MjQ4XSBtb3VzZWRldjog
UFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWljZQpbICAgIDQuODM1MzAyXSBy
dGNfY21vcyAwMDowMjogUlRDIGNhbiB3YWtlIGZyb20gUzQKWyAgICA0LjgzNTUwMl0gcnRj
X2Ntb3MgMDA6MDI6IHJ0YyBjb3JlOiByZWdpc3RlcmVkIHJ0Y19jbW9zIGFzIHJ0YzAKWyAg
ICA0LjgzNTU3MV0gcnRjX2Ntb3MgMDA6MDI6IGFsYXJtcyB1cCB0byBvbmUgbW9udGgsIHkz
aywgMjQyIGJ5dGVzIG52cmFtClsgICAgNC44MzU1ODddIGxlZHRyaWctY3B1OiByZWdpc3Rl
cmVkIHRvIGluZGljYXRlIGFjdGl2aXR5IG9uIENQVXMKWyAgICA0LjgzNjAzM10gQU1EIElP
TU1VdjIgZHJpdmVyIGJ5IEpvZXJnIFJvZWRlbCA8am9lcmcucm9lZGVsQGFtZC5jb20+Clsg
ICAgNC44MzYwMzRdIEFNRCBJT01NVXYyIGZ1bmN0aW9uYWxpdHkgbm90IGF2YWlsYWJsZSBv
biB0aGlzIHN5c3RlbQpbICAgIDQuODM2MTY1XSBUQ1A6IGN1YmljIHJlZ2lzdGVyZWQKWyAg
ICA0LjgzNjIzM10gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMApbICAgIDQu
ODM2NDY5XSBtaXA2OiBNb2JpbGUgSVB2NgpbICAgIDQuODM2NDcyXSBORVQ6IFJlZ2lzdGVy
ZWQgcHJvdG9jb2wgZmFtaWx5IDE3ClsgICAgNC44MzY0NzhdIG1wbHNfZ3NvOiBNUExTIEdT
TyBzdXBwb3J0ClsgICAgNC44MzY4MzhdIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24g
MQpbICAgIDQuODM3NDU2XSBydGNfY21vcyAwMDowMjogc2V0dGluZyBzeXN0ZW0gY2xvY2sg
dG8gMjAxNC0xMS0xOCAxMjoxMjo1MiBVVEMgKDE0MTYzMTI3NzIpClsgICAgNC44Mzc1NDZd
IFBNOiBIaWJlcm5hdGlvbiBpbWFnZSBub3QgcHJlc2VudCBvciBjb3VsZCBub3QgYmUgbG9h
ZGVkLgpbICAgIDQuODM4MTMyXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAxMjA0
SyAoZmZmZmZmZmY4MThlYjAwMCAtIGZmZmZmZmZmODFhMTgwMDApClsgICAgNC44MzgxMzRd
IFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogODE5MmsKWyAg
ICA0Ljg0MTc1OV0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogNzA4SyAoZmZmZjg4
MDAwMTU0ZjAwMCAtIGZmZmY4ODAwMDE2MDAwMDApClsgICAgNC44NDE4OTldIEZyZWVpbmcg
dW51c2VkIGtlcm5lbCBtZW1vcnk6IDIyNEsgKGZmZmY4ODAwMDE3YzgwMDAgLSBmZmZmODgw
MDAxODAwMDAwKQpbICAgIDQuODc1MTUxXSB1ZGV2ZFs2MV06IHN0YXJ0aW5nIHZlcnNpb24g
MTc1ClsgICAgNC45MjMzNTJdIHBwc19jb3JlOiBMaW51eFBQUyBBUEkgdmVyLiAxIHJlZ2lz
dGVyZWQKWyAgICA0LjkyMzM1Nl0gcHBzX2NvcmU6IFNvZnR3YXJlIHZlci4gNS4zLjYgLSBD
b3B5cmlnaHQgMjAwNS0yMDA3IFJvZG9sZm8gR2lvbWV0dGkgPGdpb21ldHRpQGxpbnV4Lml0
PgpbICAgIDQuOTI0MDYwXSBQVFAgY2xvY2sgc3VwcG9ydCByZWdpc3RlcmVkClsgICAgNC45
NDI3NjFdIGUxMDAwZTogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBEcml2ZXIgLSAyLjMu
Mi1rClsgICAgNC45NDI3NjVdIGUxMDAwZTogQ29weXJpZ2h0KGMpIDE5OTkgLSAyMDE0IElu
dGVsIENvcnBvcmF0aW9uLgpbICAgIDQuOTQyOTM3XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAy
MCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuOTQyOTU2XSB4ZW46IC0tPiBwaXJx
PTIwIC0+IGlycT0yMCAoZ3NpPTIwKQpbICAgIDQuOTQzMTMxXSBlMTAwMGUgMDAwMDowMDox
OS4wOiBJbnRlcnJ1cHQgVGhyb3R0bGluZyBSYXRlIChpbnRzL3NlYykgc2V0IHRvIGR5bmFt
aWMgY29uc2VydmF0aXZlIG1vZGUKWyAgICA0Ljk1MjI1NV0gQUNQSTogYnVzIHR5cGUgVVNC
IHJlZ2lzdGVyZWQKWyAgICA0Ljk1MjMwN10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50
ZXJmYWNlIGRyaXZlciB1c2JmcwpbICAgIDQuOTUyMzI3XSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIGh1YgpbICAgIDQuOTY1NjQxXSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBkZXZpY2UgZHJpdmVyIHVzYgpbICAgIDUuMDA3MDkxXSBBQ1BJOiBGYW4g
W0ZBTjBdIChvZmYpClsgICAgNS4wMDcxNTZdIEFDUEk6IEZhbiBbRkFOMV0gKG9mZikKWyAg
ICA1LjAwNzIxMF0gQUNQSTogRmFuIFtGQU4yXSAob2ZmKQpbICAgIDUuMDA3MjcxXSBBQ1BJ
OiBGYW4gW0ZBTjNdIChvZmYpClsgICAgNS4wMDczMzJdIEFDUEk6IEZhbiBbRkFONF0gKG9m
ZikKWyAgICA1LjAxNTY1NV0gZWhjaV9oY2Q6IFVTQiAyLjAgJ0VuaGFuY2VkJyBIb3N0IENv
bnRyb2xsZXIgKEVIQ0kpIERyaXZlcgpbICAgIDUuMDI5NzM0XSBTQ1NJIHN1YnN5c3RlbSBp
bml0aWFsaXplZApbICAgIDUuMDM1MDQwXSBlaGNpLXBjaTogRUhDSSBQQ0kgcGxhdGZvcm0g
ZHJpdmVyClsgICAgNS4wNDg2MTVdIGxpYmF0YSB2ZXJzaW9uIDMuMDAgbG9hZGVkLgpbICAg
IDUuMTk5NzY2XSBzZGhjaTogU2VjdXJlIERpZ2l0YWwgSG9zdCBDb250cm9sbGVyIEludGVy
ZmFjZSBkcml2ZXIKWyAgICA1LjE5OTc3MF0gc2RoY2k6IENvcHlyaWdodChjKSBQaWVycmUg
T3NzbWFuClsgICAgNS4yMzAxNzRdIHRoZXJtYWwgTE5YVEhFUk06MDA6IHJlZ2lzdGVyZWQg
YXMgdGhlcm1hbF96b25lMApbICAgIDUuMjMwMTc5XSBBQ1BJOiBUaGVybWFsIFpvbmUgW1Ra
MDBdICgyOCBDKQpbICAgIDUuMjMwNDkyXSB0aGVybWFsIExOWFRIRVJNOjAxOiByZWdpc3Rl
cmVkIGFzIHRoZXJtYWxfem9uZTEKWyAgICA1LjIzMDQ5NF0gQUNQSTogVGhlcm1hbCBab25l
IFtUWjAxXSAoMzAgQykKWyAgICA1LjM2MDY3NV0gaGlkcmF3OiByYXcgSElEIGV2ZW50cyBk
cml2ZXIgKEMpIEppcmkgS29zaW5hClsgICAgNS42Mjc2MDhdIGUxMDAwZSAwMDAwOjAwOjE5
LjAgZXRoMDogcmVnaXN0ZXJlZCBQSEMgY2xvY2sKWyAgICA1LjYyNzYxNV0gZTEwMDBlIDAw
MDA6MDA6MTkuMCBldGgwOiAoUENJIEV4cHJlc3M6Mi41R1QvczpXaWR0aCB4MSkgZWM6YTg6
NmI6ZmU6MDU6M2YKWyAgICA1LjYyNzYxOF0gZTEwMDBlIDAwMDA6MDA6MTkuMCBldGgwOiBJ
bnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24KWyAgICA1LjYyNzY1NV0gZTEw
MDBlIDAwMDA6MDA6MTkuMCBldGgwOiBNQUM6IDExLCBQSFk6IDEyLCBQQkEgTm86IEZGRkZG
Ri0wRkYKWyAgICA1LjYyNzgwMF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmlu
ZyAwIHBvbGFyaXR5IDEKWyAgICA1LjYyNzgwNV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDox
NgpbICAgIDUuNjI3ODU5XSB4aGNpX2hjZCAwMDAwOjAwOjE0LjA6IHhIQ0kgSG9zdCBDb250
cm9sbGVyClsgICAgNS42Mjc4NjhdIHhoY2lfaGNkIDAwMDA6MDA6MTQuMDogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxClsgICAgNS42Mjc5NTZdIHho
Y2lfaGNkIDAwMDA6MDA6MTQuMDogY2FjaGUgbGluZSBzaXplIG9mIDY0IGlzIG5vdCBzdXBw
b3J0ZWQKWyAgICA1LjYyODE2N10gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBp
ZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMgpbICAgIDUuNjI4MTc3XSB1c2IgdXNiMTog
TmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVy
PTEKWyAgICA1LjYyODE4MF0gdXNiIHVzYjE6IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9s
bGVyClsgICAgNS42MjgxODNdIHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMTYt
MC5icG8uMy1hbWQ2NCB4aGNpX2hjZApbICAgIDUuNjI4MTkyXSB1c2IgdXNiMTogU2VyaWFs
TnVtYmVyOiAwMDAwOjAwOjE0LjAKWyAgICA1LjYyODM5NF0gaHViIDEtMDoxLjA6IFVTQiBo
dWIgZm91bmQKWyAgICA1LjYyODQxMF0gaHViIDEtMDoxLjA6IDkgcG9ydHMgZGV0ZWN0ZWQK
WyAgICA1LjYzMTk1MF0geGhjaV9oY2QgMDAwMDowMDoxNC4wOiB4SENJIEhvc3QgQ29udHJv
bGxlcgpbICAgIDUuNjMxOTU2XSB4aGNpX2hjZCAwMDAwOjAwOjE0LjA6IG5ldyBVU0IgYnVz
IHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMgpbICAgIDUuNjMyMDAxXSB1c2Ig
dXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0w
MDAzClsgICAgNS42MzIwMDNdIHVzYiB1c2IyOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBN
ZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQpbICAgIDUuNjMyMDA1XSB1c2IgdXNi
MjogUHJvZHVjdDogeEhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA1LjYzMjAwN10gdXNiIHVz
YjI6IE1hbnVmYWN0dXJlcjogTGludXggMy4xNi0wLmJwby4zLWFtZDY0IHhoY2lfaGNkClsg
ICAgNS42MzIwMDhdIHVzYiB1c2IyOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTQuMApbICAg
IDUuNjMyMjA2XSBodWIgMi0wOjEuMDogVVNCIGh1YiBmb3VuZApbICAgIDUuNjMyMjIxXSBo
dWIgMi0wOjEuMDogNCBwb3J0cyBkZXRlY3RlZApbICAgIDUuNjMzMzM3XSB4ZW46IHJlZ2lz
dGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDUuNjMzMzQzXSBB
bHJlYWR5IHNldHVwIHRoZSBHU0kgOjIzClsgICAgNS42MzMzODhdIGVoY2ktcGNpIDAwMDA6
MDA6MWQuMDogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA1LjYzMzM5N10gZWhjaS1wY2kg
MDAwMDowMDoxZC4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVt
YmVyIDMKWyAgICA1LjYzMzQyNF0gZWhjaS1wY2kgMDAwMDowMDoxZC4wOiBkZWJ1ZyBwb3J0
IDIKWyAgICA1LjYzNzM4Ml0gZWhjaS1wY2kgMDAwMDowMDoxZC4wOiBjYWNoZSBsaW5lIHNp
emUgb2YgNjQgaXMgbm90IHN1cHBvcnRlZApbICAgIDUuNjM3NDQ2XSBlaGNpLXBjaSAwMDAw
OjAwOjFkLjA6IGlycSAyMywgaW8gbWVtIDB4ZjdkM2IwMDAKWyAgICA1LjY0ODEwOV0gZWhj
aS1wY2kgMDAwMDowMDoxZC4wOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMApbICAgIDUu
NjQ4Mjk0XSB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs
IGlkUHJvZHVjdD0wMDAyClsgICAgNS42NDgyOTddIHVzYiB1c2IzOiBOZXcgVVNCIGRldmlj
ZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQpbICAgIDUuNjQ4
Mjk5XSB1c2IgdXNiMzogUHJvZHVjdDogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA1LjY0
ODMwMV0gdXNiIHVzYjM6IE1hbnVmYWN0dXJlcjogTGludXggMy4xNi0wLmJwby4zLWFtZDY0
IGVoY2lfaGNkClsgICAgNS42NDgzMDNdIHVzYiB1c2IzOiBTZXJpYWxOdW1iZXI6IDAwMDA6
MDA6MWQuMApbICAgIDUuNjQ4NDk1XSBodWIgMy0wOjEuMDogVVNCIGh1YiBmb3VuZApbICAg
IDUuNjQ4NTA5XSBodWIgMy0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApbICAgIDUuNjQ4NzQ3
XSBhaGNpIDAwMDA6MDA6MWYuMjogdmVyc2lvbiAzLjAKWyAgICA1LjY0ODg5M10geGVuOiBy
ZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICA1LjY0ODg5
OV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOQpbICAgIDUuNjQ5MDc5XSBhaGNpIDAwMDA6
MDA6MWYuMjogQUhDSSAwMDAxLjAzMDAgMzIgc2xvdHMgMiBwb3J0cyA2IEdicHMgMHg4IGlt
cGwgU0FUQSBtb2RlClsgICAgNS42NDkwODVdIGFoY2kgMDAwMDowMDoxZi4yOiBmbGFnczog
NjRiaXQgbmNxIHBtIGxlZCBjbG8gb25seSBwaW8gc2x1bSBwYXJ0IGRlc28gc2FkbSBzZHMg
YXBzdCAKWyAgICA1LjY1MDU5N10gc2NzaTAgOiBhaGNpClsgICAgNS42NTEzMDddIHNjc2kx
IDogYWhjaQpbICAgIDUuNjUxNTEzXSBzY3NpMiA6IGFoY2kKWyAgICA1LjY1MTczOV0gc2Nz
aTMgOiBhaGNpClsgICAgNS42NTE4MjddIGF0YTE6IERVTU1ZClsgICAgNS42NTE4MzBdIGF0
YTI6IERVTU1ZClsgICAgNS42NTE4MzJdIGF0YTM6IERVTU1ZClsgICAgNS42NTE4MzVdIGF0
YTQ6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmN2QzYTAwMCBwb3J0IDB4Zjdk
M2EyODAgaXJxIDczClsgICAgNS45NzIxNjNdIGF0YTQ6IFNBVEEgbGluayB1cCA2LjAgR2Jw
cyAoU1N0YXR1cyAxMzMgU0NvbnRyb2wgMzAwKQpbICAgIDUuOTcyNjE5XSBhdGE0LjAwOiBz
dXBwb3J0cyBEUk0gZnVuY3Rpb25zIGFuZCBtYXkgbm90IGJlIGZ1bGx5IGFjY2Vzc2libGUK
WyAgICA1Ljk3NTU5MV0gYXRhNC4wMDogZGlzYWJsaW5nIHF1ZXVlZCBUUklNIHN1cHBvcnQK
WyAgICA1Ljk3NTU5Nl0gYXRhNC4wMDogQVRBLTk6IENydWNpYWxfQ1QxMjBNNTAwU1NEMywg
TVUwMywgbWF4IFVETUEvMTMzClsgICAgNS45NzU1OTldIGF0YTQuMDA6IDIzNDQ0MTY0OCBz
ZWN0b3JzLCBtdWx0aSAxNjogTEJBNDggTkNRIChkZXB0aCAzMS8zMiksIEFBClsgICAgNS45
NzkzMjddIGF0YTQuMDA6IHN1cHBvcnRzIERSTSBmdW5jdGlvbnMgYW5kIG1heSBub3QgYmUg
ZnVsbHkgYWNjZXNzaWJsZQpbICAgIDUuOTgyMjUyXSBhdGE0LjAwOiBkaXNhYmxpbmcgcXVl
dWVkIFRSSU0gc3VwcG9ydApbICAgIDUuOTg1NDk5XSBhdGE0LjAwOiBjb25maWd1cmVkIGZv
ciBVRE1BLzEzMwpbICAgIDUuOTg1NjY5XSBzY3NpIDM6MDowOjA6IERpcmVjdC1BY2Nlc3Mg
ICAgIEFUQSAgICAgIENydWNpYWxfQ1QxMjBNNTAgTVUwMyBQUTogMCBBTlNJOiA1ClsgICAg
NS45OTc3NjZdIHNkIDM6MDowOjA6IFtzZGFdIDIzNDQ0MTY0OCA1MTItYnl0ZSBsb2dpY2Fs
IGJsb2NrczogKDEyMCBHQi8xMTEgR2lCKQpbICAgIDUuOTk3NzcyXSBzZCAzOjA6MDowOiBb
c2RhXSA0MDk2LWJ5dGUgcGh5c2ljYWwgYmxvY2tzClsgICAgNS45OTc4NjldIHNkIDM6MDow
OjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmClsgICAgNS45OTc4NzRdIHNkIDM6MDow
OjA6IFtzZGFdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwClsgICAgNS45OTc4OThdIHNkIDM6
MDowOjA6IFtzZGFdIFdyaXRlIGNhY2hlOiBlbmFibGVkLCByZWFkIGNhY2hlOiBlbmFibGVk
LCBkb2Vzbid0IHN1cHBvcnQgRFBPIG9yIEZVQQpbICAgIDUuOTk4NzM0XSAgc2RhOiBzZGEx
IHNkYTIgc2RhMwpbICAgIDUuOTk5MjcwXSBzZCAzOjA6MDowOiBbc2RhXSBBdHRhY2hlZCBT
Q1NJIGRpc2sKWyAgICA2LjAwMzE0NF0gc2QgMzowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5l
cmljIHNnMCB0eXBlIDAKWyAgICA2LjA1MjIyMl0gdXNiIDEtNDogbmV3IGZ1bGwtc3BlZWQg
VVNCIGRldmljZSBudW1iZXIgNCB1c2luZyB4aGNpX2hjZApbICAgIDYuMDcxOTQ1XSBwbGF0
Zm9ybSBtaWNyb2NvZGU6IGZpcm13YXJlOiBkaXJlY3QtbG9hZGluZyBmaXJtd2FyZSBpbnRl
bC11Y29kZS8wNi00NS0wMQpbICAgIDYuMDcxOTg0XSBtaWNyb2NvZGU6IENQVTAgc2lnPTB4
NDA2NTEsIHBmPTB4NDAsIHJldmlzaW9uPTB4MTYKWyAgICA2LjA3MjAwMV0gbWljcm9jb2Rl
OiBDUFUwIHVwZGF0ZSB0byByZXZpc2lvbiAweDE4IGZhaWxlZApbICAgIDYuMDcyMDgwXSBw
bGF0Zm9ybSBtaWNyb2NvZGU6IGZpcm13YXJlOiBkaXJlY3QtbG9hZGluZyBmaXJtd2FyZSBp
bnRlbC11Y29kZS8wNi00NS0wMQpbICAgIDYuMDcyMTM0XSBtaWNyb2NvZGU6IENQVTEgc2ln
PTB4NDA2NTEsIHBmPTB4NDAsIHJldmlzaW9uPTB4MTYKWyAgICA2LjA3MjE1MV0gbWljcm9j
b2RlOiBDUFUxIHVwZGF0ZSB0byByZXZpc2lvbiAweDE4IGZhaWxlZApbICAgIDYuMDkwMTgx
XSBQTTogU3RhcnRpbmcgbWFudWFsIHJlc3VtZSBmcm9tIGRpc2sKWyAgICA2LjA5MDE4Nl0g
UE06IEhpYmVybmF0aW9uIGltYWdlIHBhcnRpdGlvbiA4OjIgcHJlc2VudApbICAgIDYuMDkw
MTg4XSBQTTogTG9va2luZyBmb3IgaGliZXJuYXRpb24gaW1hZ2UuClsgICAgNi4wOTA0MThd
IFBNOiBJbWFnZSBub3QgZm91bmQgKGNvZGUgLTIyKQpbICAgIDYuMDkwNDIwXSBQTTogSGli
ZXJuYXRpb24gaW1hZ2Ugbm90IHByZXNlbnQgb3IgY291bGQgbm90IGJlIGxvYWRlZC4KWyAg
ICA2LjEwNjAyMl0gRVhUNC1mcyAoc2RhMSk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9y
ZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiAobnVsbCkKWyAgICA2LjE4NDYzMV0gdXNiIDEtNDog
TmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTA0NWUsIGlkUHJvZHVjdD0wNzQ1Clsg
ICAgNi4xODQ2MzddIHVzYiAxLTQ6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0xLCBQ
cm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wClsgICAgNi4xODQ2NDFdIHVzYiAxLTQ6IFByb2R1
Y3Q6IE1pY3Jvc29mdFx4ZmZmZmZmYzJceGZmZmZmZmFlXHhmZmZmZmZhZSBOYW5vIFRyYW5z
Y2VpdmVyIHYyLjAKWyAgICA2LjE4NDY0NF0gdXNiIDEtNDogTWFudWZhY3R1cmVyOiBNaWNy
b3NvZnQKWyAgICA2LjM1MjExOF0gdXNiIDEtNzogbmV3IGZ1bGwtc3BlZWQgVVNCIGRldmlj
ZSBudW1iZXIgNSB1c2luZyB4aGNpX2hjZApbICAgIDYuNDgzNzUyXSB1c2IgMS03OiBOZXcg
VVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9ODA4NywgaWRQcm9kdWN0PTA3ZGEKWyAgICA2
LjQ4Mzc1OF0gdXNiIDEtNzogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTAsIFByb2R1
Y3Q9MCwgU2VyaWFsTnVtYmVyPTAKWyAgICA2LjUyNTk1Ml0gdWRldmRbNDc0XTogc3RhcnRp
bmcgdmVyc2lvbiAxNzUKWyAgICA2LjY5MjA5MF0gW2RybV0gSW5pdGlhbGl6ZWQgZHJtIDEu
MS4wIDIwMDYwODEwClsgICAgNi42OTYyNDVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRy
aWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNi42OTYyNTNdIEFscmVhZHkgc2V0dXAgdGhl
IEdTSSA6MTYKWyAgICA2LjY5OTE5MF0gTW9uaXRvci1Nd2FpdCB3aWxsIGJlIHVzZWQgdG8g
ZW50ZXIgQy0xIHN0YXRlClsgICAgNi43MDAxMjldIE1vbml0b3ItTXdhaXQgd2lsbCBiZSB1
c2VkIHRvIGVudGVyIEMtMiBzdGF0ZQpbICAgIDYuNzA0MjUyXSBXYXJuaW5nOiBQcm9jZXNz
b3IgUGxhdGZvcm0gTGltaXQgbm90IHN1cHBvcnRlZC4KWyAgICA2LjcyMTgwMl0gaW5wdXQ6
IFBvd2VyIEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhTWUJVUzowMC9QTlAw
QzBDOjAwL2lucHV0L2lucHV0MApbICAgIDYuNzIxODExXSBBQ1BJOiBQb3dlciBCdXR0b24g
W1BXUkJdClsgICAgNi43MjQzOTBdIHVzYiAyLTE6IG5ldyBTdXBlclNwZWVkIFVTQiBkZXZp
Y2UgbnVtYmVyIDIgdXNpbmcgeGhjaV9oY2QKWyAgICA2LjcyOTE4M10gaW5wdXQ6IFBvd2Vy
IEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhQV1JCTjowMC9pbnB1dC9pbnB1
dDEKWyAgICA2LjcyOTE5MV0gQUNQSTogUG93ZXIgQnV0dG9uIFtQV1JGXQpbICAgIDYuNzQw
OTY5XSB1c2IgMi0xOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MTc0YywgaWRQ
cm9kdWN0PTU1YWEKWyAgICA2Ljc0MDk3NV0gdXNiIDItMTogTmV3IFVTQiBkZXZpY2Ugc3Ry
aW5nczogTWZyPTIsIFByb2R1Y3Q9MywgU2VyaWFsTnVtYmVyPTEKWyAgICA2Ljc0MDk3OF0g
dXNiIDItMTogUHJvZHVjdDogQVNNMTA1MwpbICAgIDYuNzQwOTg0XSB1c2IgMi0xOiBNYW51
ZmFjdHVyZXI6IEFzbWVkaWEKWyAgICA2Ljc0MDk4N10gdXNiIDItMTogU2VyaWFsTnVtYmVy
OiAwMTIzNDU2Nzg5QUJDREVGMDEyNApbICAgIDYuNzU1NzQ0XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAxNiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDYuNzU1NzUzXSBBbHJlYWR5
IHNldHVwIHRoZSBHU0kgOjE2ClsgICAgNi43ODE2ODZdIFtkcm1dIE1lbW9yeSB1c2FibGUg
YnkgZ3JhcGhpY3MgZGV2aWNlID0gMjA0OE0KWyAgICA2Ljc4MTY5MV0gW2RybV0gUmVwbGFj
aW5nIFZHQSBjb25zb2xlIGRyaXZlcgpbICAgIDYuNzgzMDU5XSBDb25zb2xlOiBzd2l0Y2hp
bmcgdG8gY29sb3VyIGR1bW15IGRldmljZSA4MHgyNQpbICAgIDYuODk5NTUwXSByYW5kb206
IG5vbmJsb2NraW5nIHBvb2wgaXMgaW5pdGlhbGl6ZWQKWyAgICA2Ljk4MDY3OF0gdXNiIDIt
MzogbmV3IFN1cGVyU3BlZWQgVVNCIGRldmljZSBudW1iZXIgMyB1c2luZyB4aGNpX2hjZApb
ICAgIDcuMDA4NDM5XSB1c2IgMi0zOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9
MGI5NSwgaWRQcm9kdWN0PTE3OTAKWyAgICA3LjAwODQ0NV0gdXNiIDItMzogTmV3IFVTQiBk
ZXZpY2Ugc3RyaW5nczogTWZyPTEsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTMKWyAgICA3
LjAwODQ0OF0gdXNiIDItMzogUHJvZHVjdDogQVg4ODE3OQpbICAgIDcuMDA4NDUxXSB1c2Ig
Mi0zOiBNYW51ZmFjdHVyZXI6IEFTSVggRWxlYy4gQ29ycC4KWyAgICA3LjAwODQ1M10gdXNi
IDItMzogU2VyaWFsTnVtYmVyOiAwMDAwMjQ5QjBFMjAyQgpbICAgIDcuMTI4MTI0XSB1c2Ig
My0xOiBuZXcgaGlnaC1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciAyIHVzaW5nIGVoY2ktcGNp
ClsgICAgNy4xMzgyOThdIG51dm90b24tY2lyIDAwOjA1OiBbaW8gIDB4MDI0MC0weDAyNGZd
ClsgICAgNy4xMzgzMzRdIG51dm90b24tY2lyIDAwOjA1OiB1bmFibGUgdG8gYXNzaWduIHJl
c291cmNlcwpbICAgIDcuMTM4MzQxXSBudXZvdG9uLWNpciAwMDowNTogQ291bGQgbm90IGFj
dGl2YXRlIFBOUCBkZXZpY2UhClsgICAgNy4xNjY4MjVdIEZhaWxlZCB0byBhZGQgV0MgTVRS
UiBmb3IgWzAwMDAwMDAwZTAwMDAwMDAtMDAwMDAwMDBlZmZmZmZmZl07IHBlcmZvcm1hbmNl
IG1heSBzdWZmZXIuClsgICAgNy4xODgyMzRdIFtkcm1dIFN1cHBvcnRzIHZibGFuayB0aW1l
c3RhbXAgY2FjaGluZyBSZXYgMiAoMjEuMTAuMjAxMykuClsgICAgNy4xODgyMzldIFtkcm1d
IERyaXZlciBzdXBwb3J0cyBwcmVjaXNlIHZibGFuayB0aW1lc3RhbXAgcXVlcnkuClsgICAg
Ny4xODgyNzldIHZnYWFyYjogZGV2aWNlIGNoYW5nZWQgZGVjb2RlczogUENJOjAwMDA6MDA6
MDIuMCxvbGRkZWNvZGVzPWlvK21lbSxkZWNvZGVzPWlvK21lbTpvd25zPWlvK21lbQpbICAg
IDcuMjYxMDI3XSB1c2IgMy0xOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9ODA4
NywgaWRQcm9kdWN0PTgwMDAKWyAgICA3LjI2MTAzM10gdXNiIDMtMTogTmV3IFVTQiBkZXZp
Y2Ugc3RyaW5nczogTWZyPTAsIFByb2R1Y3Q9MCwgU2VyaWFsTnVtYmVyPTAKWyAgICA3LjI2
MTQ3OF0gaHViIDMtMToxLjA6IFVTQiBodWIgZm91bmQKWyAgICA3LjI2MTY0Nl0gaHViIDMt
MToxLjA6IDggcG9ydHMgZGV0ZWN0ZWQKWyAgICA3LjM0MDk1MF0gaW5wdXQ6IFBDIFNwZWFr
ZXIgYXMgL2RldmljZXMvcGxhdGZvcm0vcGNzcGtyL2lucHV0L2lucHV0MwpbICAgIDcuMzg4
MDE2XSBBVlgyIHZlcnNpb24gb2YgZ2NtX2VuYy9kZWMgZW5nYWdlZC4KWyAgICA3LjM4ODk2
M10gY2ZnODAyMTE6IENhbGxpbmcgQ1JEQSB0byB1cGRhdGUgd29ybGQgcmVndWxhdG9yeSBk
b21haW4KWyAgICA3LjQxMTgwOV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciB1c2JoaWQKWyAgICA3LjQxMTgxNF0gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJp
dmVyClsgICAgNy40MTkzODVdIEJsdWV0b290aDogQ29yZSB2ZXIgMi4xOQpbICAgIDcuNDE5
NDA2XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDMxClsgICAgNy40MTk0MDhd
IEJsdWV0b290aDogSENJIGRldmljZSBhbmQgY29ubmVjdGlvbiBtYW5hZ2VyIGluaXRpYWxp
emVkClsgICAgNy40MTk0MTddIEJsdWV0b290aDogSENJIHNvY2tldCBsYXllciBpbml0aWFs
aXplZApbICAgIDcuNDE5NDIxXSBCbHVldG9vdGg6IEwyQ0FQIHNvY2tldCBsYXllciBpbml0
aWFsaXplZApbICAgIDcuNDE5NDMyXSBCbHVldG9vdGg6IFNDTyBzb2NrZXQgbGF5ZXIgaW5p
dGlhbGl6ZWQKWyAgICA3LjQyMTYzM10gSW50ZWwoUikgV2lyZWxlc3MgV2lGaSBkcml2ZXIg
Zm9yIExpbnV4LCBpbi10cmVlOgpbICAgIDcuNDIxNjM3XSBDb3B5cmlnaHQoYykgMjAwMy0g
MjAxNCBJbnRlbCBDb3Jwb3JhdGlvbgpbICAgIDcuNDIxODMzXSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDcuNDIxODQwXSBBbHJlYWR5
IHNldHVwIHRoZSBHU0kgOjE5ClsgICAgNy40MjE4NTddIGl3bHdpZmkgMDAwMDowMjowMC4w
OiBjYW4ndCBkaXNhYmxlIEFTUE07IE9TIGRvZXNuJ3QgaGF2ZSBBU1BNIGNvbnRyb2wKWyAg
ICA3LjQzNzUyMV0gaXdsd2lmaSAwMDAwOjAyOjAwLjA6IGZpcm13YXJlOiBkaXJlY3QtbG9h
ZGluZyBmaXJtd2FyZSBpd2x3aWZpLTIwMzAtNi51Y29kZQpbICAgIDcuNDM4MjQ0XSBpd2x3
aWZpIDAwMDA6MDI6MDAuMDogbG9hZGVkIGZpcm13YXJlIHZlcnNpb24gMTguMTY4LjYuMSBv
cF9tb2RlIGl3bGR2bQpbICAgIDcuNDQyOTQzXSBhbGc6IE5vIHRlc3QgZm9yIF9fZ2NtLWFl
cy1hZXNuaSAoX19kcml2ZXItZ2NtLWFlcy1hZXNuaSkKWyAgICA3LjQ1ODg0Ml0gaXdsd2lm
aSAwMDAwOjAyOjAwLjA6IENPTkZJR19JV0xXSUZJX0RFQlVHIGRpc2FibGVkClsgICAgNy40
NTg4NDhdIGl3bHdpZmkgMDAwMDowMjowMC4wOiBDT05GSUdfSVdMV0lGSV9ERUJVR0ZTIGRp
c2FibGVkClsgICAgNy40NTg4NTFdIGl3bHdpZmkgMDAwMDowMjowMC4wOiBDT05GSUdfSVdM
V0lGSV9ERVZJQ0VfVFJBQ0lORyBkaXNhYmxlZApbICAgIDcuNDU4ODU0XSBpd2x3aWZpIDAw
MDA6MDI6MDAuMDogRGV0ZWN0ZWQgSW50ZWwoUikgQ2VudHJpbm8oUikgV2lyZWxlc3MtTiAy
MjMwIEJHTiwgUkVWPTB4QzgKWyAgICA3LjQ1OTAxMl0gaXdsd2lmaSAwMDAwOjAyOjAwLjA6
IEwxIERpc2FibGVkOyBFbmFibGluZyBMMFMKWyAgICA3LjUwNzcwNF0gaW5wdXQ6IE1pY3Jv
c29mdCBNaWNyb3NvZnRceGZmZmZmZmMyXHhmZmZmZmZhZVx4ZmZmZmZmYWUgTmFubyBUcmFu
c2NlaXZlciB2Mi4wIGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxNC4wL3VzYjEv
MS00LzEtNDoxLjAvMDAwMzowNDVFOjA3NDUuMDAwMS9pbnB1dC9pbnB1dDQKWyAgICA3LjUx
Njc5Ml0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBidHVzYgpb
ICAgIDcuNTI1NDE4XSBoaWQtZ2VuZXJpYyAwMDAzOjA0NUU6MDc0NS4wMDAxOiBpbnB1dCxo
aWRyYXcwOiBVU0IgSElEIHYxLjExIEtleWJvYXJkIFtNaWNyb3NvZnQgTWljcm9zb2Z0XHhm
ZmZmZmZjMlx4ZmZmZmZmYWVceGZmZmZmZmFlIE5hbm8gVHJhbnNjZWl2ZXIgdjIuMF0gb24g
dXNiLTAwMDA6MDA6MTQuMC00L2lucHV0MApbICAgIDcuNTI1OTYyXSBpbnB1dDogTWljcm9z
b2Z0IE1pY3Jvc29mdFx4ZmZmZmZmYzJceGZmZmZmZmFlXHhmZmZmZmZhZSBOYW5vIFRyYW5z
Y2VpdmVyIHYyLjAgYXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAwOjE0LjAvdXNiMS8x
LTQvMS00OjEuMS8wMDAzOjA0NUU6MDc0NS4wMDAyL2lucHV0L2lucHV0NQpbICAgIDcuNTI4
Nzk0XSBoaWQtZ2VuZXJpYyAwMDAzOjA0NUU6MDc0NS4wMDAyOiBpbnB1dCxoaWRyYXcxOiBV
U0IgSElEIHYxLjExIE1vdXNlIFtNaWNyb3NvZnQgTWljcm9zb2Z0XHhmZmZmZmZjMlx4ZmZm
ZmZmYWVceGZmZmZmZmFlIE5hbm8gVHJhbnNjZWl2ZXIgdjIuMF0gb24gdXNiLTAwMDA6MDA6
MTQuMC00L2lucHV0MQpbICAgIDcuNTM5MjUzXSBpbnB1dDogTWljcm9zb2Z0IE1pY3Jvc29m
dFx4ZmZmZmZmYzJceGZmZmZmZmFlXHhmZmZmZmZhZSBOYW5vIFRyYW5zY2VpdmVyIHYyLjAg
YXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAwOjE0LjAvdXNiMS8xLTQvMS00OjEuMi8w
MDAzOjA0NUU6MDc0NS4wMDAzL2lucHV0L2lucHV0NgpbICAgIDcuNTQwNjc3XSBoaWQtZ2Vu
ZXJpYyAwMDAzOjA0NUU6MDc0NS4wMDAzOiBpbnB1dCxoaWRkZXYwLGhpZHJhdzI6IFVTQiBI
SUQgdjEuMTEgRGV2aWNlIFtNaWNyb3NvZnQgTWljcm9zb2Z0XHhmZmZmZmZjMlx4ZmZmZmZm
YWVceGZmZmZmZmFlIE5hbm8gVHJhbnNjZWl2ZXIgdjIuMF0gb24gdXNiLTAwMDA6MDA6MTQu
MC00L2lucHV0MgpbICAgIDcuNTgyODMyXSBpZWVlODAyMTEgcGh5MDogU2VsZWN0ZWQgcmF0
ZSBjb250cm9sIGFsZ29yaXRobSAnaXdsLWFnbi1ycycKWyAgICA3LjYxMjM2NV0gY2ZnODAy
MTE6IFdvcmxkIHJlZ3VsYXRvcnkgZG9tYWluIHVwZGF0ZWQ6ClsgICAgNy42MTIzNzBdIGNm
ZzgwMjExOiAgREZTIE1hc3RlciByZWdpb246IHVuc2V0ClsgICAgNy42MTIzNzJdIGNmZzgw
MjExOiAgIChzdGFydF9mcmVxIC0gZW5kX2ZyZXEgQCBiYW5kd2lkdGgpLCAobWF4X2FudGVu
bmFfZ2FpbiwgbWF4X2VpcnApLCAoZGZzX2NhY190aW1lKQpbICAgIDcuNjEyMzc2XSBjZmc4
MDIxMTogICAoMjQwMjAwMCBLSHogLSAyNDcyMDAwIEtIeiBAIDQwMDAwIEtIeiksIChOL0Es
IDIwMDAgbUJtKSwgKE4vQSkKWyAgICA3LjYxMjM3OV0gY2ZnODAyMTE6ICAgKDI0NTcwMDAg
S0h6IC0gMjQ4MjAwMCBLSHogQCA0MDAwMCBLSHopLCAoTi9BLCAyMDAwIG1CbSksIChOL0Ep
ClsgICAgNy42MTIzODJdIGNmZzgwMjExOiAgICgyNDc0MDAwIEtIeiAtIDI0OTQwMDAgS0h6
IEAgMjAwMDAgS0h6KSwgKE4vQSwgMjAwMCBtQm0pLCAoTi9BKQpbICAgIDcuNjEyMzg0XSBj
Zmc4MDIxMTogICAoNTE3MDAwMCBLSHogLSA1MjUwMDAwIEtIeiBAIDE2MDAwMCBLSHopLCAo
Ti9BLCAyMDAwIG1CbSksIChOL0EpClsgICAgNy42MTIzODhdIGNmZzgwMjExOiAgICg1MjUw
MDAwIEtIeiAtIDUzMzAwMDAgS0h6IEAgMTYwMDAwIEtIeiksIChOL0EsIDIwMDAgbUJtKSwg
KDAgcykKWyAgICA3LjYxMjM5MF0gY2ZnODAyMTE6ICAgKDU0OTAwMDAgS0h6IC0gNTczMDAw
MCBLSHogQCAxNjAwMDAgS0h6KSwgKE4vQSwgMjAwMCBtQm0pLCAoMCBzKQpbICAgIDcuNjEy
MzkzXSBjZmc4MDIxMTogICAoNTczNTAwMCBLSHogLSA1ODM1MDAwIEtIeiBAIDgwMDAwIEtI
eiksIChOL0EsIDIwMDAgbUJtKSwgKE4vQSkKWyAgICA3LjYxMjM5NV0gY2ZnODAyMTE6ICAg
KDU3MjQwMDAwIEtIeiAtIDYzNzIwMDAwIEtIeiBAIDIxNjAwMDAgS0h6KSwgKE4vQSwgMCBt
Qm0pLCAoTi9BKQpbICAgIDcuNjE5NjEzXSBhbGc6IE5vIHRlc3QgZm9yIGNyYzMyIChjcmMz
Mi1wY2xtdWwpClsgICAgNy42MjgwMTZdIHVzYi1zdG9yYWdlIDItMToxLjA6IFVTQiBNYXNz
IFN0b3JhZ2UgZGV2aWNlIGRldGVjdGVkClsgICAgNy42NDI3NzhdIHVzYi1zdG9yYWdlIDIt
MToxLjA6IFF1aXJrcyBtYXRjaCBmb3IgdmlkIDE3NGMgcGlkIDU1YWE6IDQwMDAwMApbICAg
IDcuNjQzNDk4XSBzY3NpNCA6IHVzYi1zdG9yYWdlIDItMToxLjAKWyAgICA3LjY0Mzc5MV0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Itc3RvcmFnZQpb
ICAgIDcuOTkwMDgzXSBheDg4MTc5XzE3OGEgMi0zOjEuMCBldGgxOiByZWdpc3RlciAnYXg4
ODE3OV8xNzhhJyBhdCB1c2ItMDAwMDowMDoxNC4wLTMsIEFTSVggQVg4ODE3OSBVU0IgMy4w
IEdpZ2FiaXQgRXRoZXJuZXQsIDAwOjI0OjliOjBlOjIwOjJiClsgICAgNy45OTAxMjZdIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgYXg4ODE3OV8xNzhhClsg
ICAgOC4zODc1MDFdIGZiY29uOiBpbnRlbGRybWZiIChmYjApIGlzIHByaW1hcnkgZGV2aWNl
ClsgICAgOC40NzIyMDFdIENvbnNvbGU6IHN3aXRjaGluZyB0byBjb2xvdXIgZnJhbWUgYnVm
ZmVyIGRldmljZSAxNjB4NjQKWyAgICA4LjYxNjU5Ml0gaTkxNSAwMDAwOjAwOjAyLjA6IGZi
MDogaW50ZWxkcm1mYiBmcmFtZSBidWZmZXIgZGV2aWNlClsgICAgOC42MTY1OTVdIGk5MTUg
MDAwMDowMDowMi4wOiByZWdpc3RlcmVkIHBhbmljIG5vdGlmaWVyClsgICAgOC42NDA2MjZd
IHNjc2kgNDowOjA6MDogRGlyZWN0LUFjY2VzcyAgICAgQVNNVCAgICAgMjEwNSAgICAgICAg
ICAgICAwICAgIFBROiAwIEFOU0k6IDYKWyAgICA4LjY0MDk3OV0gc2QgNDowOjA6MDogQXR0
YWNoZWQgc2NzaSBnZW5lcmljIHNnMSB0eXBlIDAKWyAgICA4LjY0MTIwNl0gc2QgNDowOjA6
MDogW3NkYl0gMTk1MzUyNTE2OCA1MTItYnl0ZSBsb2dpY2FsIGJsb2NrczogKDEuMDAgVEIv
OTMxIEdpQikKWyAgICA4LjY0MTUxMF0gc2QgNDowOjA6MDogW3NkYl0gV3JpdGUgUHJvdGVj
dCBpcyBvZmYKWyAgICA4LjY0MTUxNV0gc2QgNDowOjA6MDogW3NkYl0gTW9kZSBTZW5zZTog
NDMgMDAgMDAgMDAKWyAgICA4LjY0MTgxNl0gc2QgNDowOjA6MDogW3NkYl0gV3JpdGUgY2Fj
aGU6IGVuYWJsZWQsIHJlYWQgY2FjaGU6IGVuYWJsZWQsIGRvZXNuJ3Qgc3VwcG9ydCBEUE8g
b3IgRlVBClsgICAgOC42Nzk4OTFdIEFDUEk6IFZpZGVvIERldmljZSBbR0ZYMF0gKG11bHRp
LWhlYWQ6IHllcyAgcm9tOiBubyAgcG9zdDogbm8pClsgICAgOC42ODA1MTddIGFjcGkgZGV2
aWNlOjYwOiByZWdpc3RlcmVkIGFzIGNvb2xpbmdfZGV2aWNlOApbICAgIDguNjgwNjQ5XSBp
bnB1dDogVmlkZW8gQnVzIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL0xOWFNZQlVTOjAwL1BO
UDBBMDg6MDAvTE5YVklERU86MDAvaW5wdXQvaW5wdXQ3ClsgICAgOC42ODEwNzhdIFtkcm1d
IEluaXRpYWxpemVkIGk5MTUgMS42LjAgMjAwODA3MzAgZm9yIDAwMDA6MDA6MDIuMCBvbiBt
aW5vciAwClsgICAgOC42ODEzNDNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJp
bmcgMCBwb2xhcml0eSAxClsgICAgOC42ODEzNDldIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTYKWyAgICA4LjY4MTQ4M10geGVuOiByZWdpc3RlcmluZyBnc2kgMjIgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDEKWyAgICA4LjY4MTUwMV0geGVuOiAtLT4gcGlycT0yMiAtPiBpcnE9MjIg
KGdzaT0yMikKWyAgICA4LjY4MjE5NF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDEKWyAgICA4LjY4MjIwOV0geGVuOiAtLT4gcGlycT0xOCAtPiBp
cnE9MTggKGdzaT0xOCkKWyAgICA4LjY4MjI0NV0gQUNQSSBXYXJuaW5nOiBTeXN0ZW1JTyBy
YW5nZSAweDAwMDAwMDAwMDAwMGYwNDAtMHgwMDAwMDAwMDAwMDBmMDVmIGNvbmZsaWN0cyB3
aXRoIE9wUmVnaW9uIDB4MDAwMDAwMDAwMDAwZjA0MC0weDAwMDAwMDAwMDAwMGYwNGYgKFxf
U0JfLlBDSTAuU0JVUy5TTUJJKSAoMjAxNDA0MjQvdXRhZGRyZXNzLTI1OCkKWyAgICA4LjY4
MjI1NF0gQUNQSTogSWYgYW4gQUNQSSBkcml2ZXIgaXMgYXZhaWxhYmxlIGZvciB0aGlzIGRl
dmljZSwgeW91IHNob3VsZCB1c2UgaXQgaW5zdGVhZCBvZiB0aGUgbmF0aXZlIGRyaXZlcgpb
ICAgIDguNzAyMTA5XSBpVENPX3ZlbmRvcl9zdXBwb3J0OiB2ZW5kb3Itc3VwcG9ydD0wClsg
ICAgOC43MDUxMDhdIGlUQ09fd2R0OiBJbnRlbCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJpdmVy
IHYxLjExClsgICAgOC43MDUxNzFdIGlUQ09fd2R0OiBGb3VuZCBhIEx5bnggUG9pbnRfTFAg
VENPIGRldmljZSAoVmVyc2lvbj0yLCBUQ09CQVNFPTB4MTg2MCkKWyAgICA4LjcwNjkzNV0g
aVRDT193ZHQ6IGluaXRpYWxpemVkLiBoZWFydGJlYXQ9MzAgc2VjIChub3dheW91dD0wKQpb
ICAgIDguNzEzMTU5XSBzb3VuZCBoZGF1ZGlvQzFEMDogYXV0b2NvbmZpZzogbGluZV9vdXRz
PTEgKDB4MjEvMHgwLzB4MC8weDAvMHgwKSB0eXBlOmhwClsgICAgOC43MTMxNjVdIHNvdW5k
IGhkYXVkaW9DMUQwOiAgICBzcGVha2VyX291dHM9MCAoMHgwLzB4MC8weDAvMHgwLzB4MCkK
WyAgICA4LjcxMzE2OV0gc291bmQgaGRhdWRpb0MxRDA6ICAgIGhwX291dHM9MCAoMHgwLzB4
MC8weDAvMHgwLzB4MCkKWyAgICA4LjcxMzE3Ml0gc291bmQgaGRhdWRpb0MxRDA6ICAgIG1v
bm86IG1vbm9fb3V0PTB4MApbICAgIDguNzEzMTc0XSBzb3VuZCBoZGF1ZGlvQzFEMDogICAg
aW5wdXRzOgpbICAgIDguNzEzMTc4XSBzb3VuZCBoZGF1ZGlvQzFEMDogICAgICBNaWM9MHgx
OQpbICAgIDguNzE5NTIzXSBpbnB1dDogSERBIEludGVsIEhETUkgSERNSS9EUCxwY209MyBh
cyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MDMuMC9zb3VuZC9jYXJkMC9pbnB1dDkK
WyAgICA4LjcxOTc3NV0gaW5wdXQ6IEhEQSBJbnRlbCBIRE1JIEhETUkvRFAscGNtPTcgYXMg
L2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAwOjAzLjAvc291bmQvY2FyZDAvaW5wdXQxMApb
ICAgIDguNzI2MzIxXSBpbnB1dDogSERBIERpZ2l0YWwgUENCZWVwIGFzIC9kZXZpY2VzL3Bj
aTAwMDA6MDAvMDAwMDowMDoxYi4wL3NvdW5kL2NhcmQxL2hkYXVkaW9DMUQwL2lucHV0OApb
ICAgIDguNzI3MDAwXSBpbnB1dDogSERBIEludGVsIFBDSCBNaWMgYXMgL2RldmljZXMvcGNp
MDAwMDowMC8wMDAwOjAwOjFiLjAvc291bmQvY2FyZDEvaW5wdXQxMQpbICAgIDguNzI3MjQ1
XSBpbnB1dDogSERBIEludGVsIFBDSCBIZWFkcGhvbmUgYXMgL2RldmljZXMvcGNpMDAwMDow
MC8wMDAwOjAwOjFiLjAvc291bmQvY2FyZDEvaW5wdXQxMgpbICAgIDkuMjg1MTA0XSBBZGRp
bmcgNTg1NTY4OGsgc3dhcCBvbiAvZGV2L3NkYTIuICBQcmlvcml0eTotMSBleHRlbnRzOjEg
YWNyb3NzOjU4NTU2ODhrIFNTRlMKWyAgICA5LjMwODQ1Ml0gW2RybV0gRW5hYmxpbmcgUkM2
IHN0YXRlczogUkM2IG9uLCBSQzZwIG9mZiwgUkM2cHAgb2ZmClsgICAgOS4zMjQ0MThdIEVY
VDQtZnMgKHNkYTEpOiByZS1tb3VudGVkLiBPcHRzOiAobnVsbCkKWyAgICA5LjQxMDQxMl0g
RVhUNC1mcyAoc2RhMSk6IHJlLW1vdW50ZWQuIE9wdHM6IGVycm9ycz1yZW1vdW50LXJvClsg
ICAxMS4zMDg1NDFdIEJyaWRnZSBmaXJld2FsbGluZyByZWdpc3RlcmVkClsgICAxMS4zMTg4
MTNdIGRldmljZSBldGgxIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQpbICAgMTEuNjM4NTA0
XSBJUHY2OiBBRERSQ09ORihORVRERVZfVVApOiBldGgxOiBsaW5rIGlzIG5vdCByZWFkeQpb
ICAgMTEuNjQxMjk1XSBJUHY2OiBBRERSQ09ORihORVRERVZfVVApOiB4ZW5icjA6IGxpbmsg
aXMgbm90IHJlYWR5ClsgICAxMi4xOTg2MDNdICBzZGI6IHNkYjEKWyAgIDEyLjIwMjIwMl0g
c2QgNDowOjA6MDogW3NkYl0gQXR0YWNoZWQgU0NTSSBkaXNrClsgICAxMi4yOTk4NTddIFJQ
QzogUmVnaXN0ZXJlZCBuYW1lZCBVTklYIHNvY2tldCB0cmFuc3BvcnQgbW9kdWxlLgpbICAg
MTIuMjk5ODYxXSBSUEM6IFJlZ2lzdGVyZWQgdWRwIHRyYW5zcG9ydCBtb2R1bGUuClsgICAx
Mi4yOTk4NjJdIFJQQzogUmVnaXN0ZXJlZCB0Y3AgdHJhbnNwb3J0IG1vZHVsZS4KWyAgIDEy
LjI5OTg2M10gUlBDOiBSZWdpc3RlcmVkIHRjcCBORlN2NC4xIGJhY2tjaGFubmVsIHRyYW5z
cG9ydCBtb2R1bGUuClsgICAxMi4zMDg2NTldIEZTLUNhY2hlOiBMb2FkZWQKWyAgIDEyLjMx
OTQyNV0gRlMtQ2FjaGU6IE5ldGZzICduZnMnIHJlZ2lzdGVyZWQgZm9yIGNhY2hpbmcKWyAg
IDEyLjMzNDU3OV0gSW5zdGFsbGluZyBrbmZzZCAoY29weXJpZ2h0IChDKSAxOTk2IG9raXJA
bW9uYWQuc3diLmRlKS4KWyAgIDEzLjM3OTkzNF0gYXg4ODE3OV8xNzhhIDItMzoxLjAgZXRo
MTogYXg4ODE3OSAtIExpbmsgc3RhdHVzIGlzOiAxClsgICAxMy4zODE3MjZdIElQdjY6IEFE
RFJDT05GKE5FVERFVl9DSEFOR0UpOiBldGgxOiBsaW5rIGJlY29tZXMgcmVhZHkKWyAgIDEz
LjM4MzQ2MF0geGVuYnIwOiBwb3J0IDEoZXRoMSkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRl
ClsgICAxMy4zODM0NzJdIHhlbmJyMDogcG9ydCAxKGV0aDEpIGVudGVyZWQgZm9yd2FyZGlu
ZyBzdGF0ZQpbICAgMTMuMzgzNDk0XSBJUHY2OiBBRERSQ09ORihORVRERVZfQ0hBTkdFKTog
eGVuYnIwOiBsaW5rIGJlY29tZXMgcmVhZHkKWyAgIDEzLjg1NDIwMF0gS2V5IHR5cGUgZG5z
X3Jlc29sdmVyIHJlZ2lzdGVyZWQKWyAgIDEzLjg2MTc0OV0gTkZTOiBSZWdpc3RlcmluZyB0
aGUgaWRfcmVzb2x2ZXIga2V5IHR5cGUKWyAgIDEzLjg2MTc2MF0gS2V5IHR5cGUgaWRfcmVz
b2x2ZXIgcmVnaXN0ZXJlZApbICAgMTMuODYxNzYxXSBLZXkgdHlwZSBpZF9sZWdhY3kgcmVn
aXN0ZXJlZApbICAgMTcuOTYzNTY0XSBpcF90YWJsZXM6IChDKSAyMDAwLTIwMDYgTmV0Zmls
dGVyIENvcmUgVGVhbQpbICAgMTguMzI4OTg2XSBCbHVldG9vdGg6IEJORVAgKEV0aGVybmV0
IEVtdWxhdGlvbikgdmVyIDEuMwpbICAgMTguMzI4OTkyXSBCbHVldG9vdGg6IEJORVAgZmls
dGVyczogcHJvdG9jb2wgbXVsdGljYXN0ClsgICAxOC4zMjkwMDNdIEJsdWV0b290aDogQk5F
UCBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgIDE4LjM1MDQ0M10gQmx1ZXRvb3RoOiBS
RkNPTU0gVFRZIGxheWVyIGluaXRpYWxpemVkClsgICAxOC4zNTA0NTldIEJsdWV0b290aDog
UkZDT01NIHNvY2tldCBsYXllciBpbml0aWFsaXplZApbICAgMTguMzUwNDY3XSBCbHVldG9v
dGg6IFJGQ09NTSB2ZXIgMS4xMQpbICAgMjIuODUzMjA4XSB4ZW46eGVuX2V2dGNobjogRXZl
bnQtY2hhbm5lbCBkZXZpY2UgaW5zdGFsbGVkClsgICAyMi45OTQ2MDddIHhlbl9wY2liYWNr
OiBiYWNrZW5kIGlzIHZwY2kKWyAgIDIzLjExMzA0OV0geGVuX2FjcGlfcHJvY2Vzc29yOiBV
cGxvYWRpbmcgWGVuIHByb2Nlc3NvciBQTSBpbmZvClsgICAyMy41MjgxOThdIGFoY2kgMDAw
MDowMDoxZi4yOiBwb3J0IGRvZXMgbm90IHN1cHBvcnQgZGV2aWNlIHNsZWVwClsgICAyOC40
MTYyODVdIHhlbmJyMDogcG9ydCAxKGV0aDEpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQpb
ICAgNDAuMzMzNTgyXSB0dW46IFVuaXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2ZXIsIDEu
NgpbICAgNDAuMzMzNTg3XSB0dW46IChDKSAxOTk5LTIwMDQgTWF4IEtyYXNueWFuc2t5IDxt
YXhrQHF1YWxjb21tLmNvbT4KWyAgIDQwLjQ4NjY1MV0gSVB2NjogQUREUkNPTkYoTkVUREVW
X1VQKTogdmlmMS4wOiBsaW5rIGlzIG5vdCByZWFkeQpbICAgNDAuNTg4NzYxXSBkZXZpY2Ug
dmlmMS4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQpbICAgNDAuNTkyNDQyXSBJUHY2OiBB
RERSQ09ORihORVRERVZfVVApOiB2aWYxLjA6IGxpbmsgaXMgbm90IHJlYWR5ClsgICA0MC43
NzI1MjZdIGRldmljZSB2aWYxLjAtZW11IGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQpbICAg
NDAuNzc2Mjg0XSB4ZW5icjA6IHBvcnQgMyh2aWYxLjAtZW11KSBlbnRlcmVkIGZvcndhcmRp
bmcgc3RhdGUKWyAgIDQwLjc3NjI5NV0geGVuYnIwOiBwb3J0IDModmlmMS4wLWVtdSkgZW50
ZXJlZCBmb3J3YXJkaW5nIHN0YXRlClsgICA1NS44MDg3NDddIHhlbmJyMDogcG9ydCAzKHZp
ZjEuMC1lbXUpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQpbICAgODYuNTU2OTY3XSB4ZW4t
YmxrYmFjazpyaW5nLXJlZiAxNjM4MywgZXZlbnQtY2hhbm5lbCA3LCBwcm90b2NvbCAxICh4
ODZfNjQtYWJpKSAKWyAgIDg5LjY1NDg2MF0gSVB2NjogQUREUkNPTkYoTkVUREVWX0NIQU5H
RSk6IHZpZjEuMDogbGluayBiZWNvbWVzIHJlYWR5ClsgICA4OS42NTQ5MTVdIHhlbmJyMDog
cG9ydCAyKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlClsgICA4OS42NTQ5Mjld
IHhlbmJyMDogcG9ydCAyKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlClsgIDEw
NC43MDU2ODhdIHhlbmJyMDogcG9ydCAyKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0
YXRlClsgIDIzMi40NTYxNjBdIGRldmljZS1tYXBwZXI6IHVldmVudDogdmVyc2lvbiAxLjAu
MwpbICAyMzIuNDU2NDAxXSBkZXZpY2UtbWFwcGVyOiBpb2N0bDogNC4yNy4wLWlvY3RsICgy
MDEzLTEwLTMwKSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAcmVkaGF0LmNvbQpbICAzMDAuMjE1
NTY4XSBFWFQ0LWZzIChzZGIxKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBk
YXRhIG1vZGUuIE9wdHM6IChudWxsKQpbMTA5OTguMjkyODk4XSBwY2liYWNrIDAwMDA6MDA6
MDAuMDogcHJvYmluZy4uLgpbMTA5OTguMjkyOTM1XSBwY2liYWNrIDAwMDA6MDA6MWYuMzog
cHJvYmluZy4uLgpbMTA5OTguMjkzMTE2XSB4ZW5fcGNpYmFjazogYmFja2VuZCBpcyB2cGNp
ClsxMTA0Ny4xMjU5MDhdIGdudGFsbG9jOiBkaXNhZ3JlZXMgYWJvdXQgdmVyc2lvbiBvZiBz
eW1ib2wgbW9kdWxlX2xheW91dApbMTExNTguMTIwMDExXSBlMTAwMGUgMDAwMDowMDoxOS4w
IGV0aDA6IHJlbW92ZWQgUEhDClsxMTE1OC4xNDEzNDhdIHhlbl9wY2liYWNrOiB3YW50cyB0
byBzZWl6ZSAwMDAwOjAwOjE5LjAKWzExMTU4LjE0MTM5NF0gcGNpYmFjayAwMDAwOjAwOjE5
LjA6IHByb2JpbmcuLi4KWzExMTU4LjE0MTM5OF0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IHNl
aXppbmcgZGV2aWNlClsxMTE1OC4xNDE0MDFdIHBjaWJhY2sgMDAwMDowMDoxOS4wOiBwY2lz
dHViX2RldmljZV9hbGxvYwpbMTExNTguMTQxNDA0XSBwY2liYWNrIDAwMDA6MDA6MTkuMDog
aW5pdGlhbGl6aW5nLi4uClsxMTE1OC4xNDE0MTNdIHBjaWJhY2sgMDAwMDowMDoxOS4wOiBp
bml0aWFsaXppbmcgY29uZmlnClsxMTE1OC4xNDE0NTZdIHBjaWJhY2sgMDAwMDowMDoxOS4w
OiBpbml0aWFsaXppbmcgdmlydHVhbCBjb25maWd1cmF0aW9uIHNwYWNlClsxMTE1OC4xNDE0
NjJdIHBjaWJhY2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0
IDB4MDAKWzExMTU4LjE0MTQ2NV0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZp
ZyBmaWVsZCBhdCBvZmZzZXQgMHgwMgpbMTExNTguMTQxNDY4XSBwY2liYWNrIDAwMDA6MDA6
MTkuMDogYWRkZWQgY29uZmlnIGZpZWxkIGF0IG9mZnNldCAweDA0ClsxMTE1OC4xNDE0NzFd
IHBjaWJhY2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4
M2MKWzExMTU4LjE0MTQ3NF0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBm
aWVsZCBhdCBvZmZzZXQgMHgzZApbMTExNTguMTQxNDc3XSBwY2liYWNrIDAwMDA6MDA6MTku
MDogYWRkZWQgY29uZmlnIGZpZWxkIGF0IG9mZnNldCAweDBjClsxMTE1OC4xNDE0ODNdIHBj
aWJhY2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4MGQK
WzExMTU4LjE0MTQ4Nl0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBmaWVs
ZCBhdCBvZmZzZXQgMHgwZgpbMTExNTguMTQxNDkwXSBwY2liYWNrIDAwMDA6MDA6MTkuMDog
YWRkZWQgY29uZmlnIGZpZWxkIGF0IG9mZnNldCAweDEwClsxMTE1OC4xNDE0OTVdIHBjaWJh
Y2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4MTQKWzEx
MTU4LjE0MTQ5OV0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBmaWVsZCBh
dCBvZmZzZXQgMHgxOApbMTExNTguMTQxNTAyXSBwY2liYWNrIDAwMDA6MDA6MTkuMDogYWRk
ZWQgY29uZmlnIGZpZWxkIGF0IG9mZnNldCAweDFjClsxMTE1OC4xNDE1MDddIHBjaWJhY2sg
MDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4MjAKWzExMTU4
LjE0MTUxMV0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBmaWVsZCBhdCBv
ZmZzZXQgMHgyNApbMTExNTguMTQxNTE1XSBwY2liYWNrIDAwMDA6MDA6MTkuMDogYWRkZWQg
Y29uZmlnIGZpZWxkIGF0IG9mZnNldCAweDMwClsxMTE1OC4xNDE1NTRdIHBjaWJhY2sgMDAw
MDowMDoxOS4wOiBGb3VuZCBjYXBhYmlsaXR5IDB4MSBhdCAweGM4ClsxMTE1OC4xNDE1NThd
IHBjaWJhY2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4
YzgKWzExMTU4LjE0MTU2MV0gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBm
aWVsZCBhdCBvZmZzZXQgMHhjYQpbMTExNTguMTQxNTY4XSBwY2liYWNrIDAwMDA6MDA6MTku
MDogYWRkZWQgY29uZmlnIGZpZWxkIGF0IG9mZnNldCAweGNjClsxMTE1OC4xNDE1NzFdIHBj
aWJhY2sgMDAwMDowMDoxOS4wOiBhZGRlZCBjb25maWcgZmllbGQgYXQgb2Zmc2V0IDB4Y2UK
WzExMTU4LjE0MTU3M10gcGNpYmFjayAwMDAwOjAwOjE5LjA6IGFkZGVkIGNvbmZpZyBmaWVs
ZCBhdCBvZmZzZXQgMHhjZgpbMTExNTguMTQxNTc2XSBwY2liYWNrIDAwMDA6MDA6MTkuMDog
ZW5hYmxpbmcgZGV2aWNlClsxMTE1OC4xNDE3MjVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDIw
IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsxMTE1OC4xNDE3MzFdIEFscmVhZHkgc2V0dXAg
dGhlIEdTSSA6MjAKWzExMTU4LjE0MTc0M10gcGNpYmFjayAwMDAwOjAwOjE5LjA6IHNhdmUg
c3RhdGUgb2YgZGV2aWNlClsxMTE1OC4xNDE4MTJdIHBjaWJhY2sgMDAwMDowMDoxOS4wOiBy
ZXNldHRpbmcgKEZMUiwgRDMsIGV0YykgdGhlIGRldmljZQpbMTExNTguMjQ0MzEwXSBwY2li
YWNrIDAwMDA6MDA6MTkuMDogcmVzZXQgZGV2aWNlClsxMTE1OS42NjY0OTRdIHhlbi1wY2li
YWNrIHBjaS0yLTA6IGFsbG9jYXRlZCBwZGV2IEAgMHhmZmZmODgwMGQ5ZjVmNTgwClsxMTE1
OS42NjgxODJdIHhlbi1wY2liYWNrIHBjaS0yLTA6IGdldHRpbmcgYmUgc2V0dXAKWzExMTU5
LjY2ODc4Nl0geGVuLXBjaWJhY2sgcGNpLTItMDogZXhwb3J0aW5nIGRvbSAwIGJ1cyAwIHNs
b3QgMTkgZnVuYyAwClsxMTE1OS42Njg3OTJdIHhlbl9wY2liYWNrOiB2cGNpOiAwMDAwOjAw
OjE5LjA6IGFzc2lnbiB0byB2aXJ0dWFsIHNsb3QgMApbMTExNTkuNjY4OTUzXSBwY2liYWNr
IDAwMDA6MDA6MTkuMDogcmVnaXN0ZXJpbmcgZm9yIDIKWzExMTU5LjY2OTM1OV0geGVuLXBj
aWJhY2sgcGNpLTItMDogUHVibGlzaGluZyBwY2kgcm9vdHMKWzExMTU5LjY2OTQ4NV0geGVu
LXBjaWJhY2sgcGNpLTItMDogd3JpdGluZyByb290IDAgYXQgMDAwMDowMApbMTExNTkuNjc2
ODY0XSB4ZW4tcGNpYmFjayBwY2ktMi0wOiBmZSBzdGF0ZSBjaGFuZ2VkIDEKWzExMTU5Ljcx
MjQ4Ml0geGVuLXBjaWJhY2sgcGNpLTItMDogZmUgc3RhdGUgY2hhbmdlZCAzClsxMTE1OS43
MTI5MDldIHhlbi1wY2liYWNrIHBjaS0yLTA6IFJlYWRpbmcgZnJvbnRlbmQgY29uZmlnClsx
MTE1OS43MTMyOTddIHhlbi1wY2liYWNrIHBjaS0yLTA6IEF0dGFjaGluZyB0byBmcm9udGVu
ZCByZXNvdXJjZXMgLSBnbnRfcmVmPTIwNDcgZXZ0Y2huPTQKWzExMTU5LjcxMzM0NF0geGVu
LXBjaWJhY2sgcGNpLTItMDogQXR0YWNoZWQhClsxMTE1OS43MTMzNDhdIHhlbi1wY2liYWNr
IHBjaS0yLTA6IENvbm5lY3RpbmcuLi4KWzExMTU5LjcxNTIwNF0geGVuLXBjaWJhY2sgcGNp
LTItMDogQ29ubmVjdGVkPyAwClsxMTE1OS43MTU4ODhdIHhlbi1wY2liYWNrIHBjaS0yLTA6
IGZlIHN0YXRlIGNoYW5nZWQgNApbMTExNTkuNzMyMjA3XSBwY2liYWNrIDAwMDA6MDA6MTku
MDogZW5hYmxpbmcgZGV2aWNlICgwMDAwIC0+IDAwMDMpClsxMTE1OS43MzIzNjNdIHhlbjog
cmVnaXN0ZXJpbmcgZ3NpIDIwIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsxMTE1OS43MzIz
NzBdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjAKWzExMTU5LjczMjM4OV0gcGNpYmFjayAw
MDAwOjAwOjE5LjA6IHhlbi1wY2liYWNrWzAwMDA6MDA6MTkuMF06ICMyMCBvbiAgZGlzYWJs
ZS0+IGVuYWJsZQpbMTExNTkuNzMyNDUxXSBwY2liYWNrIDAwMDA6MDA6MTkuMDogeGVuLXBj
aWJhY2tbMDAwMDowMDoxOS4wXTogIzIwIG9uICBlbmFibGVkClsxMTE4My43NDE2MTFdIHBj
aWJhY2sgMDAwMDowMDoxOS4wOiB4ZW4tcGNpYmFja1swMDAwOjAwOjE5LjBdOiAjMjAgb2Zm
ICBlbmFibGUtPiBkaXNhYmxlClsxMTE4My43NDE2NTFdIHBjaWJhY2sgMDAwMDowMDoxOS4w
OiB4ZW4tcGNpYmFja1swMDAwOjAwOjE5LjBdOiAjMCBvZmYgIGRpc2FibGVkClsxMTE4My43
NDIzNzNdIHhlbi1wY2liYWNrIHBjaS0yLTA6IGZlIHN0YXRlIGNoYW5nZWQgNQpbMTExODMu
NzQzNDUxXSB4ZW4tcGNpYmFjayBwY2ktMi0wOiBmZSBzdGF0ZSBjaGFuZ2VkIDYKWzExMTgz
Ljc0NDUwNV0geGVuLXBjaWJhY2sgcGNpLTItMDogZmUgc3RhdGUgY2hhbmdlZCAwClsxMTE4
My43NDQ1MTBdIHhlbi1wY2liYWNrIHBjaS0yLTA6IGZyb250ZW5kIGlzIGdvbmUhIHVucmVn
aXN0ZXIgZGV2aWNlClsxMTE4My44NDU5NzhdIHBjaWJhY2sgMDAwMDowMDoxOS4wOiByZXNl
dHRpbmcgdmlydHVhbCBjb25maWd1cmF0aW9uIHNwYWNlClsxMTE4My44NDU5OTFdIHBjaWJh
Y2sgMDAwMDowMDoxOS4wOiBmcmVlLWluZyBkeW5hbWljYWxseSBhbGxvY2F0ZWQgdmlydHVh
bCBjb25maWd1cmF0aW9uIHNwYWNlIGZpZWxkcwpbMTEyMTMuNzc5MDkzXSB4ZW4tcGNpYmFj
ayBwY2ktNC0wOiBhbGxvY2F0ZWQgcGRldiBAIDB4ZmZmZjg4MDAyY2Q5ZDA0MApbMTEyMTMu
NzgwNDM1XSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBnZXR0aW5nIGJlIHNldHVwClsxMTIxMy43
ODA2NzZdIHhlbi1wY2liYWNrIHBjaS00LTA6IGV4cG9ydGluZyBkb20gMCBidXMgMCBzbG90
IDE5IGZ1bmMgMApbMTEyMTMuNzgwNjgyXSB4ZW5fcGNpYmFjazogdnBjaTogMDAwMDowMDox
OS4wOiBhc3NpZ24gdG8gdmlydHVhbCBzbG90IDAKWzExMjEzLjc4MDg2MF0gcGNpYmFjayAw
MDAwOjAwOjE5LjA6IHJlZ2lzdGVyaW5nIGZvciA0ClsxMTIxMy43ODEyMTddIHhlbi1wY2li
YWNrIHBjaS00LTA6IFB1Ymxpc2hpbmcgcGNpIHJvb3RzClsxMTIxMy43ODE0ODFdIHhlbi1w
Y2liYWNrIHBjaS00LTA6IHdyaXRpbmcgcm9vdCAwIGF0IDAwMDA6MDAKWzExMjEzLjc5MDIx
Ml0geGVuLXBjaWJhY2sgcGNpLTQtMDogZmUgc3RhdGUgY2hhbmdlZCAxClsxMTIxMy44MTE0
NzhdIHhlbi1wY2liYWNrIHBjaS00LTA6IGZlIHN0YXRlIGNoYW5nZWQgMwpbMTEyMTMuODEx
Njc1XSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBSZWFkaW5nIGZyb250ZW5kIGNvbmZpZwpbMTEy
MTMuODEyMjgxXSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBBdHRhY2hpbmcgdG8gZnJvbnRlbmQg
cmVzb3VyY2VzIC0gZ250X3JlZj0yMDQ3IGV2dGNobj00ClsxMTIxMy44MTIzNDZdIHhlbi1w
Y2liYWNrIHBjaS00LTA6IEF0dGFjaGVkIQpbMTEyMTMuODEyMzUyXSB4ZW4tcGNpYmFjayBw
Y2ktNC0wOiBDb25uZWN0aW5nLi4uClsxMTIxMy44MTI5NzddIHhlbi1wY2liYWNrIHBjaS00
LTA6IENvbm5lY3RlZD8gMApbMTEyMTMuODEzMzkwXSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBm
ZSBzdGF0ZSBjaGFuZ2VkIDQKWzExMjEzLjgyODY2Ml0gcGNpYmFjayAwMDAwOjAwOjE5LjA6
IGVuYWJsaW5nIGRldmljZSAoMDAwMCAtPiAwMDAzKQpbMTEyMTMuODI4Nzc1XSB4ZW46IHJl
Z2lzdGVyaW5nIGdzaSAyMCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbMTEyMTMuODI4Nzgw
XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjIwClsxMTIxMy44Mjg3OTRdIHBjaWJhY2sgMDAw
MDowMDoxOS4wOiB4ZW4tcGNpYmFja1swMDAwOjAwOjE5LjBdOiAjMjAgb24gIGRpc2FibGUt
PiBlbmFibGUKWzExMjEzLjgyODg0M10gcGNpYmFjayAwMDAwOjAwOjE5LjA6IHhlbi1wY2li
YWNrWzAwMDA6MDA6MTkuMF06ICMyMCBvbiAgZW5hYmxlZApbMTEyMjAuODM4MjYzXSBwY2li
YWNrIDAwMDA6MDA6MTkuMDogeGVuLXBjaWJhY2tbMDAwMDowMDoxOS4wXTogIzIwIG9mZiAg
ZW5hYmxlLT4gZGlzYWJsZQpbMTEyMjAuODM4MzAyXSBwY2liYWNrIDAwMDA6MDA6MTkuMDog
eGVuLXBjaWJhY2tbMDAwMDowMDoxOS4wXTogIzAgb2ZmICBkaXNhYmxlZApbMTEyMjAuODM4
Nzg1XSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBmZSBzdGF0ZSBjaGFuZ2VkIDUKWzExMjIwLjgz
OTgyNF0geGVuLXBjaWJhY2sgcGNpLTQtMDogZmUgc3RhdGUgY2hhbmdlZCA2ClsxMTIyMC44
NDEzNjddIHhlbi1wY2liYWNrIHBjaS00LTA6IGZlIHN0YXRlIGNoYW5nZWQgMApbMTEyMjAu
ODQxMzcyXSB4ZW4tcGNpYmFjayBwY2ktNC0wOiBmcm9udGVuZCBpcyBnb25lISB1bnJlZ2lz
dGVyIGRldmljZQpbMTEyMjAuOTQ0MDYwXSBwY2liYWNrIDAwMDA6MDA6MTkuMDogcmVzZXR0
aW5nIHZpcnR1YWwgY29uZmlndXJhdGlvbiBzcGFjZQpbMTEyMjAuOTQ0MDc4XSBwY2liYWNr
IDAwMDA6MDA6MTkuMDogZnJlZS1pbmcgZHluYW1pY2FsbHkgYWxsb2NhdGVkIHZpcnR1YWwg
Y29uZmlndXJhdGlvbiBzcGFjZSBmaWVsZHMK
------------0410070F03E0EB1B3
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0410070F03E0EB1B3--



From xen-devel-bounces@lists.xen.org Tue Nov 18 16:26:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlc6-0005uL-26; Tue, 18 Nov 2014 16:26:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xqlc4-0005u3-26
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:26:44 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	6D/4B-26858-3437B645; Tue, 18 Nov 2014 16:26:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416328002!12147660!1
X-Originating-IP: [81.169.146.220]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23056 invoked from network); 18 Nov 2014 16:26:42 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:26:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416328002; l=1980;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=7BizFHAEC4valZ6/4zZFn1yUBEY=;
	b=xRUlGuJAjamMP+SUxzM3rEstV+V3hCB0el4bwGOWHMF0s/VAf8Rmk/WEDDOnPftHZrF
	1XHcuBhdYxMrsTczhqmDYw8UclSAbnMuEmtcCnCGSOay9NH/hm+q/D7w99GfTjF1M+uHo
	/jBF+m+q4+FUj8637ku8g+j9cNaTB0qaYJM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.12 AUTH) with ESMTPSA id 601677qAIGQbJJ1
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 18 Nov 2014 17:26:37 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id F3A4450172; Tue, 18 Nov 2014 17:26:36 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Tue, 18 Nov 2014 17:26:34 +0100
Message-Id: <1416327994-29619-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen: use more fixed strings to build 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>
MIME-Version: 1.0
Content-Type: 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 expected that repeated builds of identical sources results in
identical binaries on different hosts at different build times. This
fails for xen.gz and xen.efi because unstable strings are included in
the binaries.

In addition to existing variables use XEN_BUILD_DATE, XEN_BUILD_TIME and
XEN_BUILD_HOST to specify fixed strings during build.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---
 xen/Makefile | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index 72c1313..47f003c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -8,6 +8,9 @@ export XEN_FULLVERSION   = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
 
 export XEN_WHOAMI	?= $(USER)
 export XEN_DOMAIN	?= $(shell ([ -x /bin/dnsdomainname ] && /bin/dnsdomainname) || ([ -x /bin/domainname ] && /bin/domainname || echo [unknown]))
+export XEN_BUILD_DATE	?= $(shell LC_ALL=C date)
+export XEN_BUILD_TIME	?= $(shell LC_ALL=C date +%T)
+export XEN_BUILD_HOST	?= $(shell hostname)
 
 export BASEDIR := $(CURDIR)
 export XEN_ROOT := $(BASEDIR)/..
@@ -126,11 +129,11 @@ delete-unfresh-files:
 
 # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
 include/xen/compile.h: include/xen/compile.h.in .banner
-	@sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
-	    -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
+	@sed -e 's/@@date@@/$(XEN_BUILD_DATE)/g' \
+	    -e 's/@@time@@/$(XEN_BUILD_TIME)/g' \
 	    -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
 	    -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
-	    -e 's/@@hostname@@/$(shell hostname)/g' \
+	    -e 's/@@hostname@@/$(XEN_BUILD_HOST)/g' \
 	    -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
 	    -e 's/@@version@@/$(XEN_VERSION)/g' \
 	    -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:26:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlc6-0005uL-26; Tue, 18 Nov 2014 16:26:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xqlc4-0005u3-26
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:26:44 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	6D/4B-26858-3437B645; Tue, 18 Nov 2014 16:26:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416328002!12147660!1
X-Originating-IP: [81.169.146.220]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23056 invoked from network); 18 Nov 2014 16:26:42 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:26:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416328002; l=1980;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=7BizFHAEC4valZ6/4zZFn1yUBEY=;
	b=xRUlGuJAjamMP+SUxzM3rEstV+V3hCB0el4bwGOWHMF0s/VAf8Rmk/WEDDOnPftHZrF
	1XHcuBhdYxMrsTczhqmDYw8UclSAbnMuEmtcCnCGSOay9NH/hm+q/D7w99GfTjF1M+uHo
	/jBF+m+q4+FUj8637ku8g+j9cNaTB0qaYJM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.12 AUTH) with ESMTPSA id 601677qAIGQbJJ1
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 18 Nov 2014 17:26:37 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id F3A4450172; Tue, 18 Nov 2014 17:26:36 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Tue, 18 Nov 2014 17:26:34 +0100
Message-Id: <1416327994-29619-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen: use more fixed strings to build 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>
MIME-Version: 1.0
Content-Type: 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 expected that repeated builds of identical sources results in
identical binaries on different hosts at different build times. This
fails for xen.gz and xen.efi because unstable strings are included in
the binaries.

In addition to existing variables use XEN_BUILD_DATE, XEN_BUILD_TIME and
XEN_BUILD_HOST to specify fixed strings during build.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---
 xen/Makefile | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index 72c1313..47f003c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -8,6 +8,9 @@ export XEN_FULLVERSION   = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
 
 export XEN_WHOAMI	?= $(USER)
 export XEN_DOMAIN	?= $(shell ([ -x /bin/dnsdomainname ] && /bin/dnsdomainname) || ([ -x /bin/domainname ] && /bin/domainname || echo [unknown]))
+export XEN_BUILD_DATE	?= $(shell LC_ALL=C date)
+export XEN_BUILD_TIME	?= $(shell LC_ALL=C date +%T)
+export XEN_BUILD_HOST	?= $(shell hostname)
 
 export BASEDIR := $(CURDIR)
 export XEN_ROOT := $(BASEDIR)/..
@@ -126,11 +129,11 @@ delete-unfresh-files:
 
 # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
 include/xen/compile.h: include/xen/compile.h.in .banner
-	@sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
-	    -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
+	@sed -e 's/@@date@@/$(XEN_BUILD_DATE)/g' \
+	    -e 's/@@time@@/$(XEN_BUILD_TIME)/g' \
 	    -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
 	    -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
-	    -e 's/@@hostname@@/$(shell hostname)/g' \
+	    -e 's/@@hostname@@/$(XEN_BUILD_HOST)/g' \
 	    -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
 	    -e 's/@@version@@/$(XEN_VERSION)/g' \
 	    -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:29:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:29:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqleN-00066Q-MZ; Tue, 18 Nov 2014 16:29:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqleM-00066F-S3
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:29:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	62/D4-09842-2D37B645; Tue, 18 Nov 2014 16:29:06 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416328145!13633142!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16227 invoked from network); 18 Nov 2014 16:29:05 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:29:05 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so13226977wid.6
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 08:29:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=jSHClDWaT2umAqyFkSVfdwfaiYqW54R68IyT/iKtEJk=;
	b=NDLskJrtro2+AMJviGWiENxx7FpZCjUidNmh43fsBRnOjF9p9JNNyPaVo3TyDNDO7Y
	YzFJooF/eYaavxOsoQNNkCDRjefeMG0i4+s22UJK7nzSaM3A4fAVagS3CUOU2h2k6tWE
	d976CNisxd8gMV2scuHeIIfQ5qQybq2R6pMhHRrNnZ3+RziNiUf+Hy6LsuqoB78AWbR2
	1dO5EFAIXGbvBCI1F/Hge93Fbn9DnRBomO9YkqYTLlTHf4l4kckTPsZImygE5XcDZ6mP
	JUfBpIRTj8EFBhRd/BehfiN1CwfWESki2Ed8C0cr9FlBm+14kZ5QUfSnkBf7ec5RUvje
	ImbQ==
X-Gm-Message-State: ALoCoQnGVCk9upit/xFqROfuWHEB3u2kD/q1G3ekKUW9GNXzR9pnF2H1YGmLIDRNqFpAbG9u3vFI
X-Received: by 10.180.100.104 with SMTP id ex8mr5206370wib.80.1416328143177;
	Tue, 18 Nov 2014 08:29:03 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	bj7sm56437031wjc.33.2014.11.18.08.29.01 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 08:29:02 -0800 (PST)
Message-ID: <546B73CC.3030308@linaro.org>
Date: Tue, 18 Nov 2014 16:29:00 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>		<54535E240200007800043DAC@mail.emea.novell.com>		<546B5F15.5060702@linaro.org>		<21611.24907.144396.509457@mariner.uk.xensource.com>		<546B650D.8040304@linaro.org>	
	<21611.26449.963393.613516@mariner.uk.xensource.com>	
	<546B6AA5.1050409@linaro.org>
	<1416327662.17982.24.camel@citrix.com>
In-Reply-To: <1416327662.17982.24.camel@citrix.com>
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Empty struct in public headers Was: Re: [PATCH for
 Xen 4.5] xen/arm: Add support for GICv3 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/18/2014 04:21 PM, Ian Campbell wrote:
> On Tue, 2014-11-18 at 15:49 +0000, Julien Grall wrote:
>> (Rename the mail and strip the cc list)
>>
>> On 11/18/2014 03:35 PM, Ian Jackson wrote:
>>> Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
>>>> On 11/18/2014 03:10 PM, Ian Jackson wrote:
>>>>> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
>>>>> would be very surprised if clang didn't support them too.
>>>>
>>>> AFAIK, clang doesn't complain about empty structures.
>>>
>>> Right.
>>>
>>>>> AIUI our policy, gcc extensions are fine except in the Xen public
>>>>> headers.
>>>>
>>>> We have at least 2 "empty" structure on the ARM public header.
>>>
>>> That ought to be fixed, in case anyone ever wants to build ARM guests
>>> with Norcroft C or something.
>>>
>>> Does the size of these structs matter ?
>>
>> The 2 structures are arch_vcpu_info and arch_shared_info.
>>
>> They are used only at the end of the structure vcpu_info (resp.
>> shared_info). So I guess we could fix it?
> 
> arch_vcpu_info isn't at the end of vcpu_info (vcpu_time_info follows it)
> and also vcpu_info is part of an array at the start of shared_info (an
> array of 1 on ARM, but things still follow it). I'm also not sure of the
> impact on the vcpu placement hypercall or the uses of it.

Oops, right. I looked too quickly to the code, sorry.

> So it looks like changing vcpu_info at least will be hard/impossible. If
> we want rid of these empty structs then I think an ifdef at the point of
> use is the only option :-(

I will send a patch to ifdef arch_vcpu and arch_shared_info when Xen 4.6
windows will be opened.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:29:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:29:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqleN-00066Q-MZ; Tue, 18 Nov 2014 16:29:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqleM-00066F-S3
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:29:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	62/D4-09842-2D37B645; Tue, 18 Nov 2014 16:29:06 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416328145!13633142!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16227 invoked from network); 18 Nov 2014 16:29:05 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:29:05 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so13226977wid.6
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 08:29:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=jSHClDWaT2umAqyFkSVfdwfaiYqW54R68IyT/iKtEJk=;
	b=NDLskJrtro2+AMJviGWiENxx7FpZCjUidNmh43fsBRnOjF9p9JNNyPaVo3TyDNDO7Y
	YzFJooF/eYaavxOsoQNNkCDRjefeMG0i4+s22UJK7nzSaM3A4fAVagS3CUOU2h2k6tWE
	d976CNisxd8gMV2scuHeIIfQ5qQybq2R6pMhHRrNnZ3+RziNiUf+Hy6LsuqoB78AWbR2
	1dO5EFAIXGbvBCI1F/Hge93Fbn9DnRBomO9YkqYTLlTHf4l4kckTPsZImygE5XcDZ6mP
	JUfBpIRTj8EFBhRd/BehfiN1CwfWESki2Ed8C0cr9FlBm+14kZ5QUfSnkBf7ec5RUvje
	ImbQ==
X-Gm-Message-State: ALoCoQnGVCk9upit/xFqROfuWHEB3u2kD/q1G3ekKUW9GNXzR9pnF2H1YGmLIDRNqFpAbG9u3vFI
X-Received: by 10.180.100.104 with SMTP id ex8mr5206370wib.80.1416328143177;
	Tue, 18 Nov 2014 08:29:03 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	bj7sm56437031wjc.33.2014.11.18.08.29.01 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 08:29:02 -0800 (PST)
Message-ID: <546B73CC.3030308@linaro.org>
Date: Tue, 18 Nov 2014 16:29:00 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>		<54535E240200007800043DAC@mail.emea.novell.com>		<546B5F15.5060702@linaro.org>		<21611.24907.144396.509457@mariner.uk.xensource.com>		<546B650D.8040304@linaro.org>	
	<21611.26449.963393.613516@mariner.uk.xensource.com>	
	<546B6AA5.1050409@linaro.org>
	<1416327662.17982.24.camel@citrix.com>
In-Reply-To: <1416327662.17982.24.camel@citrix.com>
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Empty struct in public headers Was: Re: [PATCH for
 Xen 4.5] xen/arm: Add support for GICv3 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/18/2014 04:21 PM, Ian Campbell wrote:
> On Tue, 2014-11-18 at 15:49 +0000, Julien Grall wrote:
>> (Rename the mail and strip the cc list)
>>
>> On 11/18/2014 03:35 PM, Ian Jackson wrote:
>>> Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
>>>> On 11/18/2014 03:10 PM, Ian Jackson wrote:
>>>>> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
>>>>> would be very surprised if clang didn't support them too.
>>>>
>>>> AFAIK, clang doesn't complain about empty structures.
>>>
>>> Right.
>>>
>>>>> AIUI our policy, gcc extensions are fine except in the Xen public
>>>>> headers.
>>>>
>>>> We have at least 2 "empty" structure on the ARM public header.
>>>
>>> That ought to be fixed, in case anyone ever wants to build ARM guests
>>> with Norcroft C or something.
>>>
>>> Does the size of these structs matter ?
>>
>> The 2 structures are arch_vcpu_info and arch_shared_info.
>>
>> They are used only at the end of the structure vcpu_info (resp.
>> shared_info). So I guess we could fix it?
> 
> arch_vcpu_info isn't at the end of vcpu_info (vcpu_time_info follows it)
> and also vcpu_info is part of an array at the start of shared_info (an
> array of 1 on ARM, but things still follow it). I'm also not sure of the
> impact on the vcpu placement hypercall or the uses of it.

Oops, right. I looked too quickly to the code, sorry.

> So it looks like changing vcpu_info at least will be hard/impossible. If
> we want rid of these empty structs then I think an ifdef at the point of
> use is the only option :-(

I will send a patch to ifdef arch_vcpu and arch_shared_info when Xen 4.6
windows will be opened.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:32:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:32:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlhJ-0006Ga-DD; Tue, 18 Nov 2014 16:32:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqlhI-0006GR-Ha
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:32:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	53/17-25276-7847B645; Tue, 18 Nov 2014 16:32:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416328322!13660745!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20966 invoked from network); 18 Nov 2014 16:32:07 -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;
	18 Nov 2014 16:32:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192542148"
Message-ID: <1416328305.17982.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Tue, 18 Nov 2014 16:31:45 +0000
In-Reply-To: <546B73CC.3030308@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
	<21611.24907.144396.509457@mariner.uk.xensource.com>
	<546B650D.8040304@linaro.org>
	<21611.26449.963393.613516@mariner.uk.xensource.com>
	<546B6AA5.1050409@linaro.org> <1416327662.17982.24.camel@citrix.com>
	<546B73CC.3030308@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Empty struct in public headers Was: Re: [PATCH for
 Xen 4.5] xen/arm: Add support for GICv3 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 16:29 +0000, Julien Grall wrote:
> On 11/18/2014 04:21 PM, Ian Campbell wrote:
> > On Tue, 2014-11-18 at 15:49 +0000, Julien Grall wrote:
> >> (Rename the mail and strip the cc list)
> >>
> >> On 11/18/2014 03:35 PM, Ian Jackson wrote:
> >>> Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
> >>>> On 11/18/2014 03:10 PM, Ian Jackson wrote:
> >>>>> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
> >>>>> would be very surprised if clang didn't support them too.
> >>>>
> >>>> AFAIK, clang doesn't complain about empty structures.
> >>>
> >>> Right.
> >>>
> >>>>> AIUI our policy, gcc extensions are fine except in the Xen public
> >>>>> headers.
> >>>>
> >>>> We have at least 2 "empty" structure on the ARM public header.
> >>>
> >>> That ought to be fixed, in case anyone ever wants to build ARM guests
> >>> with Norcroft C or something.
> >>>
> >>> Does the size of these structs matter ?
> >>
> >> The 2 structures are arch_vcpu_info and arch_shared_info.
> >>
> >> They are used only at the end of the structure vcpu_info (resp.
> >> shared_info). So I guess we could fix it?
> > 
> > arch_vcpu_info isn't at the end of vcpu_info (vcpu_time_info follows it)
> > and also vcpu_info is part of an array at the start of shared_info (an
> > array of 1 on ARM, but things still follow it). I'm also not sure of the
> > impact on the vcpu placement hypercall or the uses of it.
> 
> Oops, right. I looked too quickly to the code, sorry.
> 
> > So it looks like changing vcpu_info at least will be hard/impossible. If
> > we want rid of these empty structs then I think an ifdef at the point of
> > use is the only option :-(
> 
> I will send a patch to ifdef arch_vcpu and arch_shared_info when Xen 4.6
> windows will be opened.

Sounds good. The approach we've used in this area before is XEN_HAVE_FOO
(e.g. PV_UPCALL_MASK), so I suppose XEN_HAVE_ARCH_VCPU and
XEN_HAVE_ARCH_SHARED_INFO defined for x86 would be the most consistent
way to go.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:32:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:32:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlhJ-0006Ga-DD; Tue, 18 Nov 2014 16:32:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqlhI-0006GR-Ha
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:32:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	53/17-25276-7847B645; Tue, 18 Nov 2014 16:32:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416328322!13660745!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20966 invoked from network); 18 Nov 2014 16:32:07 -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;
	18 Nov 2014 16:32:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192542148"
Message-ID: <1416328305.17982.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Tue, 18 Nov 2014 16:31:45 +0000
In-Reply-To: <546B73CC.3030308@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
	<21611.24907.144396.509457@mariner.uk.xensource.com>
	<546B650D.8040304@linaro.org>
	<21611.26449.963393.613516@mariner.uk.xensource.com>
	<546B6AA5.1050409@linaro.org> <1416327662.17982.24.camel@citrix.com>
	<546B73CC.3030308@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Empty struct in public headers Was: Re: [PATCH for
 Xen 4.5] xen/arm: Add support for GICv3 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 16:29 +0000, Julien Grall wrote:
> On 11/18/2014 04:21 PM, Ian Campbell wrote:
> > On Tue, 2014-11-18 at 15:49 +0000, Julien Grall wrote:
> >> (Rename the mail and strip the cc list)
> >>
> >> On 11/18/2014 03:35 PM, Ian Jackson wrote:
> >>> Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
> >>>> On 11/18/2014 03:10 PM, Ian Jackson wrote:
> >>>>> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
> >>>>> would be very surprised if clang didn't support them too.
> >>>>
> >>>> AFAIK, clang doesn't complain about empty structures.
> >>>
> >>> Right.
> >>>
> >>>>> AIUI our policy, gcc extensions are fine except in the Xen public
> >>>>> headers.
> >>>>
> >>>> We have at least 2 "empty" structure on the ARM public header.
> >>>
> >>> That ought to be fixed, in case anyone ever wants to build ARM guests
> >>> with Norcroft C or something.
> >>>
> >>> Does the size of these structs matter ?
> >>
> >> The 2 structures are arch_vcpu_info and arch_shared_info.
> >>
> >> They are used only at the end of the structure vcpu_info (resp.
> >> shared_info). So I guess we could fix it?
> > 
> > arch_vcpu_info isn't at the end of vcpu_info (vcpu_time_info follows it)
> > and also vcpu_info is part of an array at the start of shared_info (an
> > array of 1 on ARM, but things still follow it). I'm also not sure of the
> > impact on the vcpu placement hypercall or the uses of it.
> 
> Oops, right. I looked too quickly to the code, sorry.
> 
> > So it looks like changing vcpu_info at least will be hard/impossible. If
> > we want rid of these empty structs then I think an ifdef at the point of
> > use is the only option :-(
> 
> I will send a patch to ifdef arch_vcpu and arch_shared_info when Xen 4.6
> windows will be opened.

Sounds good. The approach we've used in this area before is XEN_HAVE_FOO
(e.g. PV_UPCALL_MASK), so I suppose XEN_HAVE_ARCH_VCPU and
XEN_HAVE_ARCH_SHARED_INFO defined for x86 would be the most consistent
way to go.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:33:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:33:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqliA-0006Kl-SQ; Tue, 18 Nov 2014 16:33:02 +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 1Xqli9-0006Kc-Ct
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:33:01 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	68/E5-02954-CB47B645; Tue, 18 Nov 2014 16:33:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416328378!13344930!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10985 invoked from network); 18 Nov 2014 16:33:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:33:00 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIGWpxI012002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Nov 2014 16:32:52 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIGWnhn007269
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 18 Nov 2014 16:32:50 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIGWnxq023498; Tue, 18 Nov 2014 16:32:49 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 08:32:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1747B117A10; Tue, 18 Nov 2014 11:32:48 -0500 (EST)
Date: Tue, 18 Nov 2014 11:32:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Don Koch <dkoch@verizon.com>
Message-ID: <20141118163247.GF17095@laptop.dumpdata.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH] Ignore non-zero data in unused
 xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 10:26:31AM -0500, Don Koch wrote:
> If we restore an xsave area from an older xen that has a larger
> size than the xcr0 bit call for, it is possible to have non-zero
> data in the unused area if an xsave has ever been done that used
> that area (e.g. during a context switch). Since the vcpu's xsave
> area is never zeroed after the initial allocation, that data is
> still there. Since we are told that said area was not written to
> during the save or migration, there is no need to restore it.
> 
> Signed-off-by: Don Koch <dkoch@verizon.com>
> ---
> Turns out the assertion that the unused xsave area is zero
> is wrong. Unfortunately, that leaves the following as the
> only way I can think of to work around it (and is no worse
> than xsave/xrestore during context switches). Alternate
> suggestions welcome.

This is Xen 4.5 material I presume.

> 
>  xen/arch/x86/hvm/hvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 8f49b44..b2c0bc4 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
>                  printk(XENLOG_G_WARNING
>                         "HVM%d.%u restore mismatch: xsave length %#x > %#x (non-zero data at %#x)\n",
>                         d->domain_id, vcpuid, desc->length, size, i);
> -                return -EOPNOTSUPP;
> +                break;
>              }
>          }
>          printk(XENLOG_G_WARNING
> -- 
> 1.8.3.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:33:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:33:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqliA-0006Kl-SQ; Tue, 18 Nov 2014 16:33:02 +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 1Xqli9-0006Kc-Ct
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:33:01 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	68/E5-02954-CB47B645; Tue, 18 Nov 2014 16:33:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416328378!13344930!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10985 invoked from network); 18 Nov 2014 16:33:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:33:00 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIGWpxI012002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Nov 2014 16:32:52 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIGWnhn007269
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 18 Nov 2014 16:32:50 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIGWnxq023498; Tue, 18 Nov 2014 16:32:49 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 08:32:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1747B117A10; Tue, 18 Nov 2014 11:32:48 -0500 (EST)
Date: Tue, 18 Nov 2014 11:32:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Don Koch <dkoch@verizon.com>
Message-ID: <20141118163247.GF17095@laptop.dumpdata.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH] Ignore non-zero data in unused
 xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 10:26:31AM -0500, Don Koch wrote:
> If we restore an xsave area from an older xen that has a larger
> size than the xcr0 bit call for, it is possible to have non-zero
> data in the unused area if an xsave has ever been done that used
> that area (e.g. during a context switch). Since the vcpu's xsave
> area is never zeroed after the initial allocation, that data is
> still there. Since we are told that said area was not written to
> during the save or migration, there is no need to restore it.
> 
> Signed-off-by: Don Koch <dkoch@verizon.com>
> ---
> Turns out the assertion that the unused xsave area is zero
> is wrong. Unfortunately, that leaves the following as the
> only way I can think of to work around it (and is no worse
> than xsave/xrestore during context switches). Alternate
> suggestions welcome.

This is Xen 4.5 material I presume.

> 
>  xen/arch/x86/hvm/hvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 8f49b44..b2c0bc4 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
>                  printk(XENLOG_G_WARNING
>                         "HVM%d.%u restore mismatch: xsave length %#x > %#x (non-zero data at %#x)\n",
>                         d->domain_id, vcpuid, desc->length, size, i);
> -                return -EOPNOTSUPP;
> +                break;
>              }
>          }
>          printk(XENLOG_G_WARNING
> -- 
> 1.8.3.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:35:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlko-0006VW-GR; Tue, 18 Nov 2014 16:35:46 +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 1Xqlkn-0006VQ-Qu
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:35:45 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	93/0A-02576-1657B645; Tue, 18 Nov 2014 16:35:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416328544!13384417!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15824 invoked from network); 18 Nov 2014 16:35:44 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:35:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 16:35:44 +0000
Message-Id: <546B836E0200007800048D91@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 16:35:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Don Koch" <dkoch@verizon.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
In-Reply-To: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 16:26, <dkoch@verizon.com> wrote:
> If we restore an xsave area from an older xen that has a larger
> size than the xcr0 bit call for, it is possible to have non-zero
> data in the unused area if an xsave has ever been done that used
> that area (e.g. during a context switch). Since the vcpu's xsave
> area is never zeroed after the initial allocation, that data is
> still there.

This needs more explanation: xcr0_accum is named this way
because bits never disappear from it. Hence afaics any piece of
the xsave area ever having got written with a non-zero value
would be part of the data actually used on migration.

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
>                  printk(XENLOG_G_WARNING
>                         "HVM%d.%u restore mismatch: xsave length %#x > %#x (non-zero data at %#x)\n",
>                         d->domain_id, vcpuid, desc->length, size, i);
> -                return -EOPNOTSUPP;
> +                break;
>              }
>          }
>          printk(XENLOG_G_WARNING

Even if we really have to go this route, you should recall the
discussion on the earlier patch of yours: The end result should
not be that two messages get logged for a single event.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:35:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlko-0006VW-GR; Tue, 18 Nov 2014 16:35:46 +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 1Xqlkn-0006VQ-Qu
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:35:45 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	93/0A-02576-1657B645; Tue, 18 Nov 2014 16:35:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416328544!13384417!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15824 invoked from network); 18 Nov 2014 16:35:44 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:35:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 16:35:44 +0000
Message-Id: <546B836E0200007800048D91@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 16:35:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Don Koch" <dkoch@verizon.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
In-Reply-To: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 16:26, <dkoch@verizon.com> wrote:
> If we restore an xsave area from an older xen that has a larger
> size than the xcr0 bit call for, it is possible to have non-zero
> data in the unused area if an xsave has ever been done that used
> that area (e.g. during a context switch). Since the vcpu's xsave
> area is never zeroed after the initial allocation, that data is
> still there.

This needs more explanation: xcr0_accum is named this way
because bits never disappear from it. Hence afaics any piece of
the xsave area ever having got written with a non-zero value
would be part of the data actually used on migration.

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
>                  printk(XENLOG_G_WARNING
>                         "HVM%d.%u restore mismatch: xsave length %#x > %#x (non-zero data at %#x)\n",
>                         d->domain_id, vcpuid, desc->length, size, i);
> -                return -EOPNOTSUPP;
> +                break;
>              }
>          }
>          printk(XENLOG_G_WARNING

Even if we really have to go this route, you should recall the
discussion on the earlier patch of yours: The end result should
not be that two messages get logged for a single event.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:37:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:37:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlmL-0006dF-2a; Tue, 18 Nov 2014 16:37:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqlmJ-0006d7-T2
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:37:20 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	E9/22-28296-FB57B645; Tue, 18 Nov 2014 16:37:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416328635!12167591!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26943 invoked from network); 18 Nov 2014 16:37:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:37:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192544590"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:36:11 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqllD-0008IW-4J;
	Tue, 18 Nov 2014 16:36:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqllC-0005AV-Mx;
	Tue, 18 Nov 2014 16:36:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.30074.302907.667308@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 16:36:10 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1416327994-29619-1-git-send-email-olaf@aepfle.de>
References: <1416327994-29619-1-git-send-email-olaf@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen: use more fixed strings to build 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

Olaf Hering writes ("[PATCH] xen: use more fixed strings to build the hypervisor"):
> It is expected that repeated builds of identical sources results in
> identical binaries on different hosts at different build times. This
> fails for xen.gz and xen.efi because unstable strings are included in
> the binaries.

I like the idea of making our builds more reproducible.  And your
patch looks correct (although I haven't tested it).

> In addition to existing variables use XEN_BUILD_DATE, XEN_BUILD_TIME and
> XEN_BUILD_HOST to specify fixed strings during build.

But your commit message is rather odd.

The first paragrah describes an expectation which as far as I can tell
is not fulfilled by your patch.  Your patch just makes it easier to
fulfil.

And the second paragraph seems to have an English grammar issue.  "Use
[blah] to specify fixed strings during build" means, when found in a
commit message "this commit uses [blah] to specify ...".  But your
commit doesn't.  It merely provides a facility for others to do so.

How about

   It should be possible to repeatedly build identical sources
   and get identical binaries, even on different hosts at different
   build times.  This fails [etc. etc. ...]

   Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and XEN_BUILD_HOST
   which the build environment can set to fixed strings to get a
   reproducible build.

or some such.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:37:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:37:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlmL-0006dF-2a; Tue, 18 Nov 2014 16:37:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqlmJ-0006d7-T2
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:37:20 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	E9/22-28296-FB57B645; Tue, 18 Nov 2014 16:37:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416328635!12167591!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26943 invoked from network); 18 Nov 2014 16:37:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:37:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192544590"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:36:11 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqllD-0008IW-4J;
	Tue, 18 Nov 2014 16:36:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqllC-0005AV-Mx;
	Tue, 18 Nov 2014 16:36:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.30074.302907.667308@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 16:36:10 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1416327994-29619-1-git-send-email-olaf@aepfle.de>
References: <1416327994-29619-1-git-send-email-olaf@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen: use more fixed strings to build 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

Olaf Hering writes ("[PATCH] xen: use more fixed strings to build the hypervisor"):
> It is expected that repeated builds of identical sources results in
> identical binaries on different hosts at different build times. This
> fails for xen.gz and xen.efi because unstable strings are included in
> the binaries.

I like the idea of making our builds more reproducible.  And your
patch looks correct (although I haven't tested it).

> In addition to existing variables use XEN_BUILD_DATE, XEN_BUILD_TIME and
> XEN_BUILD_HOST to specify fixed strings during build.

But your commit message is rather odd.

The first paragrah describes an expectation which as far as I can tell
is not fulfilled by your patch.  Your patch just makes it easier to
fulfil.

And the second paragraph seems to have an English grammar issue.  "Use
[blah] to specify fixed strings during build" means, when found in a
commit message "this commit uses [blah] to specify ...".  But your
commit doesn't.  It merely provides a facility for others to do so.

How about

   It should be possible to repeatedly build identical sources
   and get identical binaries, even on different hosts at different
   build times.  This fails [etc. etc. ...]

   Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and XEN_BUILD_HOST
   which the build environment can set to fixed strings to get a
   reproducible build.

or some such.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:37:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:37:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlme-0006gL-Fl; Tue, 18 Nov 2014 16:37:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xqlmc-0006fw-E9
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:37:38 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	55/68-31453-1D57B645; Tue, 18 Nov 2014 16:37:37 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416328653!6770497!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18011 invoked from network); 18 Nov 2014 16:37:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:37:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192544799"
Message-ID: <546B758F.9020207@citrix.com>
Date: Tue, 18 Nov 2014 16:36:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Don Koch
	<dkoch@verizon.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
	<20141118163247.GF17095@laptop.dumpdata.com>
In-Reply-To: <20141118163247.GF17095@laptop.dumpdata.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH] Ignore non-zero data in unused
 xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/11/14 16:32, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 18, 2014 at 10:26:31AM -0500, Don Koch wrote:
>> If we restore an xsave area from an older xen that has a larger
>> size than the xcr0 bit call for, it is possible to have non-zero
>> data in the unused area if an xsave has ever been done that used

Do you mean "has never been done".

i.e. the non-zero data is actually Xen heap junk?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:37:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:37:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlme-0006gL-Fl; Tue, 18 Nov 2014 16:37:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xqlmc-0006fw-E9
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:37:38 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	55/68-31453-1D57B645; Tue, 18 Nov 2014 16:37:37 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416328653!6770497!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18011 invoked from network); 18 Nov 2014 16:37:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:37:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192544799"
Message-ID: <546B758F.9020207@citrix.com>
Date: Tue, 18 Nov 2014 16:36:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Don Koch
	<dkoch@verizon.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
	<20141118163247.GF17095@laptop.dumpdata.com>
In-Reply-To: <20141118163247.GF17095@laptop.dumpdata.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH] Ignore non-zero data in unused
 xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/11/14 16:32, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 18, 2014 at 10:26:31AM -0500, Don Koch wrote:
>> If we restore an xsave area from an older xen that has a larger
>> size than the xcr0 bit call for, it is possible to have non-zero
>> data in the unused area if an xsave has ever been done that used

Do you mean "has never been done".

i.e. the non-zero data is actually Xen heap junk?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:44:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlsy-00071f-Q5; Tue, 18 Nov 2014 16:44:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xqlsx-00071L-2a
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:44:11 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	21/6E-22737-A577B645; Tue, 18 Nov 2014 16:44:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416329048!7942274!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21803 invoked from network); 18 Nov 2014 16:44:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:44:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194056433"
Message-ID: <1416329045.17982.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:44:05 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH 0/4 for-4.5] xen: arm: xgene bug fixes + support
	for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These patches:

      * fix up an off by one bug in the xgene mapping of additional PCI
        bus resources, which would cause an additional extra page to be
        mapped
      * correct the size of the mapped regions to match the docs
      * adds support for the other 4 PCI buses on the chip, which
        enables mcdivitt and presumably most other Xgene based platforms
        which uses PCI buses other than pcie0.
      * adds earlyprintk for the mcdivitt platform

McDivitt is the X-Gene based HP Moonshot cartridge (McDivitt is the code
name, I think the product is called m400, not quite sure).

Other than the bug fixes I'd like to see the mcdivitt support
(specifically the "other 4 PCI buses" one) in 4.5 because Moonshot is an
interesting and exciting platform for arm64. It is also being used for
ongoing work on Xen on ARM on Openstack in Linaro. The earlyprintk patch
is totally harmless unless it's explicitly enabled at compile time, IMHO
if we are taking the rest we may as well throw it in...

The risk here is that we break the existing support for the Mustang
platform, which would be the most likely failure case for the second
patch. I've tested these on a Mustang, including firing up a PCI NIC
device. The new mappings are a superset of the existing ones so the
potential for breakage should be quite small.

I've also successfully tested on a McDivitt.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:44:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlsy-00071f-Q5; Tue, 18 Nov 2014 16:44:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xqlsx-00071L-2a
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:44:11 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	21/6E-22737-A577B645; Tue, 18 Nov 2014 16:44:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416329048!7942274!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21803 invoked from network); 18 Nov 2014 16:44:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:44:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194056433"
Message-ID: <1416329045.17982.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:44:05 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH 0/4 for-4.5] xen: arm: xgene bug fixes + support
	for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These patches:

      * fix up an off by one bug in the xgene mapping of additional PCI
        bus resources, which would cause an additional extra page to be
        mapped
      * correct the size of the mapped regions to match the docs
      * adds support for the other 4 PCI buses on the chip, which
        enables mcdivitt and presumably most other Xgene based platforms
        which uses PCI buses other than pcie0.
      * adds earlyprintk for the mcdivitt platform

McDivitt is the X-Gene based HP Moonshot cartridge (McDivitt is the code
name, I think the product is called m400, not quite sure).

Other than the bug fixes I'd like to see the mcdivitt support
(specifically the "other 4 PCI buses" one) in 4.5 because Moonshot is an
interesting and exciting platform for arm64. It is also being used for
ongoing work on Xen on ARM on Openstack in Linaro. The earlyprintk patch
is totally harmless unless it's explicitly enabled at compile time, IMHO
if we are taking the rest we may as well throw it in...

The risk here is that we break the existing support for the Mustang
platform, which would be the most likely failure case for the second
patch. I've tested these on a Mustang, including firing up a PCI NIC
device. The new mappings are a superset of the existing ones so the
potential for breakage should be quite small.

I've also successfully tested on a McDivitt.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:44:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlsp-00070P-7R; Tue, 18 Nov 2014 16:44:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xqlsn-00070E-9E
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:44:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1B/B3-09936-0577B645; Tue, 18 Nov 2014 16:44:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416329040!6360027!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16409 invoked from network); 18 Nov 2014 16:44:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:44:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 16:43:59 +0000
Message-Id: <546B855E0200007800048DB5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 16:43:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
	<546B7EB60200007800048D20@mail.emea.novell.com>
	<546B71A5.2060104@linaro.org>
In-Reply-To: <546B71A5.2060104@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 17:19, <julien.grall@linaro.org> wrote:
> On 11/18/2014 04:15 PM, Jan Beulich wrote:
>>>>> On 18.11.14 at 16:00, <julien.grall@linaro.org> wrote:
>>> On 10/31/2014 09:02 AM, Jan Beulich wrote:
>>>>>>> On 30.10.14 at 19:51, <julien.grall@linaro.org> wrote:
>>>> The naming suggests that the #if really should be around just the
>>>> gic_version field (with a dummy field in the #else case to be C89
>>>> compatible, e.g. a zero width unnamed bitfield) and the
>>>> corresponding #define-s above, ...
>>>
>>> Not really related to this patch... but the way to improve it (via
>>> extending createdomain).
>>>
>>> I need to create an empty structure. Is the dummy field really needed?
>>> If so, did you meant?
>>>
>>> struct
>>> {
>>>    int :0;
>>> }
>> 
>> Yes.
>> 
>>> The C spec declare this kind of structure as undefined.
>> 
>> I can't find anything saying so.
> 
> http://c0x.coding-guidelines.com/6.7.2.1.html 
> 
> "1401 If the struct-declaration-list contains no named members, the
> behavior is undefined."

Ah, indeed. I overlooked that clause in the standard, and all compilers
I have at hand have no problem compiling such a struct.

>>> Would an empty structure and used it be better?
>> 
>> Empty structures (and unions) aren't valid in standard C afaics, up to
>> and including C11. That was the whole point of suggesting the above
>> alternative, with me (maybe wrongly) believing that this would be valid.
> 
> Right, this is an extension of GCC. As neither of the 2 solutions are
> valid, Ian Jackson was suggesting to use
> 
> struct {
>    char dummy;
> }
> 
> Would it be ok for you?

Sure - whatever is the smallest possible placeholder (unless, as seems
to emerge from the other sub-thread, you need to go with #ifdef-s
anyway).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:44:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlsp-00070P-7R; Tue, 18 Nov 2014 16:44:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xqlsn-00070E-9E
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:44:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1B/B3-09936-0577B645; Tue, 18 Nov 2014 16:44:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416329040!6360027!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16409 invoked from network); 18 Nov 2014 16:44:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:44:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 16:43:59 +0000
Message-Id: <546B855E0200007800048DB5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 16:43:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org>
	<54535E240200007800043DAC@mail.emea.novell.com>
	<546B5F15.5060702@linaro.org>
	<546B7EB60200007800048D20@mail.emea.novell.com>
	<546B71A5.2060104@linaro.org>
In-Reply-To: <546B71A5.2060104@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, tim@xen.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3
 for domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 17:19, <julien.grall@linaro.org> wrote:
> On 11/18/2014 04:15 PM, Jan Beulich wrote:
>>>>> On 18.11.14 at 16:00, <julien.grall@linaro.org> wrote:
>>> On 10/31/2014 09:02 AM, Jan Beulich wrote:
>>>>>>> On 30.10.14 at 19:51, <julien.grall@linaro.org> wrote:
>>>> The naming suggests that the #if really should be around just the
>>>> gic_version field (with a dummy field in the #else case to be C89
>>>> compatible, e.g. a zero width unnamed bitfield) and the
>>>> corresponding #define-s above, ...
>>>
>>> Not really related to this patch... but the way to improve it (via
>>> extending createdomain).
>>>
>>> I need to create an empty structure. Is the dummy field really needed?
>>> If so, did you meant?
>>>
>>> struct
>>> {
>>>    int :0;
>>> }
>> 
>> Yes.
>> 
>>> The C spec declare this kind of structure as undefined.
>> 
>> I can't find anything saying so.
> 
> http://c0x.coding-guidelines.com/6.7.2.1.html 
> 
> "1401 If the struct-declaration-list contains no named members, the
> behavior is undefined."

Ah, indeed. I overlooked that clause in the standard, and all compilers
I have at hand have no problem compiling such a struct.

>>> Would an empty structure and used it be better?
>> 
>> Empty structures (and unions) aren't valid in standard C afaics, up to
>> and including C11. That was the whole point of suggesting the above
>> alternative, with me (maybe wrongly) believing that this would be valid.
> 
> Right, this is an extension of GCC. As neither of the 2 solutions are
> valid, Ian Jackson was suggesting to use
> 
> struct {
>    char dummy;
> }
> 
> Would it be ok for you?

Sure - whatever is the smallest possible placeholder (unless, as seems
to emerge from the other sub-thread, you need to go with #ifdef-s
anyway).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:45:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:45:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqltt-00079V-8V; Tue, 18 Nov 2014 16:45: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 1Xqltr-00079A-7n
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:45:07 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	6E/38-31453-2977B645; Tue, 18 Nov 2014 16:45:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416329100!12057485!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14854 invoked from network); 18 Nov 2014 16:45:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:45:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194056781"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:44:49 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XqltY-0008T1-K2;
	Tue, 18 Nov 2014 16:44:49 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Tue, 18 Nov
	2014 16:44:48 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:44:45 +0000
Message-ID: <1416329088-23328-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416329045.17982.27.camel@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH for-4.5 1/4] xen: arm: Add earlyprintk for
	McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Rules.mk |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 572d854..ef887a5 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -95,6 +95,12 @@ EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0x1c020000
 EARLY_UART_REG_SHIFT := 2
 endif
+ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
+EARLY_PRINTK_INC := 8250
+EARLY_PRINTK_BAUD := 9600
+EARLY_UART_BASE_ADDRESS := 0x1c021000
+EARLY_UART_REG_SHIFT := 2
+endif
 ifeq ($(CONFIG_EARLY_PRINTK), juno)
 EARLY_PRINTK_INC := pl011
 EARLY_PRINTK_BAUD := 115200
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:45:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:45:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqltt-00079V-8V; Tue, 18 Nov 2014 16:45: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 1Xqltr-00079A-7n
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:45:07 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	6E/38-31453-2977B645; Tue, 18 Nov 2014 16:45:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416329100!12057485!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14854 invoked from network); 18 Nov 2014 16:45:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:45:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194056781"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:44:49 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XqltY-0008T1-K2;
	Tue, 18 Nov 2014 16:44:49 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Tue, 18 Nov
	2014 16:44:48 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:44:45 +0000
Message-ID: <1416329088-23328-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416329045.17982.27.camel@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH for-4.5 1/4] xen: arm: Add earlyprintk for
	McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Rules.mk |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 572d854..ef887a5 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -95,6 +95,12 @@ EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0x1c020000
 EARLY_UART_REG_SHIFT := 2
 endif
+ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
+EARLY_PRINTK_INC := 8250
+EARLY_PRINTK_BAUD := 9600
+EARLY_UART_BASE_ADDRESS := 0x1c021000
+EARLY_UART_REG_SHIFT := 2
+endif
 ifeq ($(CONFIG_EARLY_PRINTK), juno)
 EARLY_PRINTK_INC := pl011
 EARLY_PRINTK_BAUD := 115200
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:45:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1XqluD-0007D7-LP; Tue, 18 Nov 2014 16:45:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqluD-0007Co-7a
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:45:29 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	2C/10-25727-8A77B645; Tue, 18 Nov 2014 16:45:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416329125!12266735!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27309 invoked from network); 18 Nov 2014 16:45:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:45:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194056788"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:44:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xqlta-0008T6-MK;
	Tue, 18 Nov 2014 16:44:51 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Tue, 18 Nov
	2014 16:44:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:44:47 +0000
Message-ID: <1416329088-23328-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416329045.17982.27.camel@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH for-4.5 3/4] xen: arm: correct specific mappings
	for PCIE0 on X-Gene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 region assigned to PCIE0, according to the docs, is 0x0e000000000 to
0x10000000000. They make no distinction between PCI CFG and PCI IO mem within
this range (in fact, I'm not sure that isn't up to the driver).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/platforms/xgene-storm.c |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 38674cd..6c432a1 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -89,22 +89,8 @@ static int xgene_storm_specific_mapping(struct domain *d)
     int ret;
 
     /* Map the PCIe bus resources */
-    ret = map_one_mmio(d, "PCI MEM REGION", paddr_to_pfn(0xe000000000UL),
-                                            paddr_to_pfn(0xe010000000UL));
-    if ( ret )
-        goto err;
-
-    ret = map_one_mmio(d, "PCI IO REGION", paddr_to_pfn(0xe080000000UL),
-                                           paddr_to_pfn(0xe080010000UL));
-    if ( ret )
-        goto err;
-
-    ret = map_one_mmio(d, "PCI CFG REGION", paddr_to_pfn(0xe0d0000000UL),
-                                            paddr_to_pfn(0xe0d0200000UL));
-    if ( ret )
-        goto err;
-    ret = map_one_mmio(d, "PCI MSI REGION", paddr_to_pfn(0xe010000000UL),
-                                            paddr_to_pfn(0xe010800000UL));
+    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
+                                        paddr_to_pfn(0x01000000000UL));
     if ( ret )
         goto err;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:45:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1XqluE-0007DG-1i; Tue, 18 Nov 2014 16:45:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqluD-0007Cj-7d
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:45:29 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	8F/7E-17694-7A77B645; Tue, 18 Nov 2014 16:45:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416329125!12266735!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27210 invoked from network); 18 Nov 2014 16:45:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:45:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194056786"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:44:50 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XqltZ-0008T3-LJ;
	Tue, 18 Nov 2014 16:44:50 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Tue, 18 Nov
	2014 16:44:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:44:46 +0000
Message-ID: <1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416329045.17982.27.camel@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH for-4.5 2/4] xen: arm: correct off by one in
	xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 callers pass the end as the pfn immediately *after* the last page to be
mapped, therefore adding one is incorrect and causes an additional page to be
mapped.

At the same time correct the printing of the mfn values, zero-padding them to
16 digits as for a paddr when they are frame numbers is just confusing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/platforms/xgene-storm.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 29c4752..38674cd 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -45,9 +45,9 @@ static int map_one_mmio(struct domain *d, const char *what,
 {
     int ret;
 
-    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
+    printk("Additional MMIO %lx-%lx (%s)\n",
            start, end, what);
-    ret = map_mmio_regions(d, start, end - start + 1, start);
+    ret = map_mmio_regions(d, start, end - start, start);
     if ( ret )
         printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
                what, start, d->domain_id);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:45:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1XqluD-0007D7-LP; Tue, 18 Nov 2014 16:45:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqluD-0007Co-7a
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:45:29 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	2C/10-25727-8A77B645; Tue, 18 Nov 2014 16:45:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416329125!12266735!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27309 invoked from network); 18 Nov 2014 16:45:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:45:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194056788"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:44:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xqlta-0008T6-MK;
	Tue, 18 Nov 2014 16:44:51 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Tue, 18 Nov
	2014 16:44:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:44:47 +0000
Message-ID: <1416329088-23328-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416329045.17982.27.camel@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH for-4.5 3/4] xen: arm: correct specific mappings
	for PCIE0 on X-Gene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 region assigned to PCIE0, according to the docs, is 0x0e000000000 to
0x10000000000. They make no distinction between PCI CFG and PCI IO mem within
this range (in fact, I'm not sure that isn't up to the driver).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/platforms/xgene-storm.c |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 38674cd..6c432a1 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -89,22 +89,8 @@ static int xgene_storm_specific_mapping(struct domain *d)
     int ret;
 
     /* Map the PCIe bus resources */
-    ret = map_one_mmio(d, "PCI MEM REGION", paddr_to_pfn(0xe000000000UL),
-                                            paddr_to_pfn(0xe010000000UL));
-    if ( ret )
-        goto err;
-
-    ret = map_one_mmio(d, "PCI IO REGION", paddr_to_pfn(0xe080000000UL),
-                                           paddr_to_pfn(0xe080010000UL));
-    if ( ret )
-        goto err;
-
-    ret = map_one_mmio(d, "PCI CFG REGION", paddr_to_pfn(0xe0d0000000UL),
-                                            paddr_to_pfn(0xe0d0200000UL));
-    if ( ret )
-        goto err;
-    ret = map_one_mmio(d, "PCI MSI REGION", paddr_to_pfn(0xe010000000UL),
-                                            paddr_to_pfn(0xe010800000UL));
+    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
+                                        paddr_to_pfn(0x01000000000UL));
     if ( ret )
         goto err;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:45:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1XqluE-0007DG-1i; Tue, 18 Nov 2014 16:45:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XqluD-0007Cj-7d
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:45:29 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	8F/7E-17694-7A77B645; Tue, 18 Nov 2014 16:45:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416329125!12266735!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27210 invoked from network); 18 Nov 2014 16:45:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:45:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="194056786"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:44:50 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1XqltZ-0008T3-LJ;
	Tue, 18 Nov 2014 16:44:50 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Tue, 18 Nov
	2014 16:44:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:44:46 +0000
Message-ID: <1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416329045.17982.27.camel@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH for-4.5 2/4] xen: arm: correct off by one in
	xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 callers pass the end as the pfn immediately *after* the last page to be
mapped, therefore adding one is incorrect and causes an additional page to be
mapped.

At the same time correct the printing of the mfn values, zero-padding them to
16 digits as for a paddr when they are frame numbers is just confusing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/platforms/xgene-storm.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 29c4752..38674cd 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -45,9 +45,9 @@ static int map_one_mmio(struct domain *d, const char *what,
 {
     int ret;
 
-    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
+    printk("Additional MMIO %lx-%lx (%s)\n",
            start, end, what);
-    ret = map_mmio_regions(d, start, end - start + 1, start);
+    ret = map_mmio_regions(d, start, end - start, start);
     if ( ret )
         printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
                what, start, d->domain_id);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:46:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqluv-0007Nk-In; Tue, 18 Nov 2014 16:46: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 1Xqluu-0007ND-0r
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:46:12 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C4/DA-29352-FC77B645; Tue, 18 Nov 2014 16:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416329164!6654814!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2406 invoked from network); 18 Nov 2014 16:46:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:46:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192549502"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:44:52 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xqltb-0008T9-NM;
	Tue, 18 Nov 2014 16:44:52 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Tue, 18 Nov
	2014 16:44:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:44:48 +0000
Message-ID: <1416329088-23328-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416329045.17982.27.camel@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4 PCI
	buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only establish specific mappings for pcie0, which is
used on the Mustang platform. However at least McDivitt uses pcie3.
So wire up all the others, based on whether the corresponding DT node
is marked as available.

This results in no change for Mustang.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/platforms/xgene-storm.c |   84 ++++++++++++++++++++++++++++------
 1 file changed, 71 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 6c432a1..926c325 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -78,35 +78,31 @@ static int map_one_spi(struct domain *d, const char *what,
     return ret;
 }
 
-/*
- * Xen does not currently support mapping MMIO regions and interrupt
- * for bus child devices (referenced via the "ranges" and
- * "interrupt-map" properties to domain 0). Instead for now map the
- * necessary resources manually.
- */
-static int xgene_storm_specific_mapping(struct domain *d)
+/* Creates MMIO mappings base..end as well as 4 SPIs from the given base. */
+static int xgene_storm_pcie_specific_mapping(struct domain *d,
+                                             paddr_t base, paddr_t end,
+                                             int base_spi)
 {
     int ret;
 
     /* Map the PCIe bus resources */
-    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
-                                        paddr_to_pfn(0x01000000000UL));
+    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(base), paddr_to_pfn(end));
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTA", 0xc2, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTA", base_spi+0, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTB", 0xc3, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTB", base_spi+1, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTC", 0xc4, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTC", base_spi+2, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTD", 0xc5, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTD", base_spi+3, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
@@ -115,6 +111,68 @@ err:
     return ret;
 }
 
+/*
+ * Xen does not currently support mapping MMIO regions and interrupt
+ * for bus child devices (referenced via the "ranges" and
+ * "interrupt-map" properties to domain 0). Instead for now map the
+ * necessary resources manually.
+ */
+static int xgene_storm_specific_mapping(struct domain *d)
+{
+    struct dt_device_node *node = NULL;
+    int ret;
+
+    while ( (node = dt_find_compatible_node(node, "pci", "apm,xgene-pcie")) )
+    {
+        u64 addr;
+
+        /* Identify the bus via it's control register address */
+        ret = dt_device_get_address(node, 0, &addr, NULL);
+        if ( ret < 0 )
+            return ret;
+
+        if ( !dt_device_is_available(node) )
+            continue;
+
+       switch ( addr )
+        {
+        case 0x1f2b0000: /* PCIe0 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                0x0e000000000UL, 0x10000000000UL, 0xc2);
+            break;
+        case 0x1f2c0000: /* PCIe1 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                0x0d000000000UL, 0x0e000000000UL, 0xc8);
+            break;
+        case 0x1f2d0000: /* PCIe2 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                0x09000000000UL, 0x0a000000000UL, 0xce);
+            break;
+        case 0x1f500000: /* PCIe3 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                0x0a000000000UL, 0x0c000000000UL, 0xd4);
+            break;
+        case 0x1f510000: /* PCIe4 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                0x0c000000000UL, 0x0d000000000UL, 0xda);
+            break;
+
+        default:
+            /* Ignore unknown PCI busses */
+            ret = 0;
+            break;
+        }
+
+        if ( ret < 0 )
+            return ret;
+
+        printk("Mapped additional regions for PCIe device at 0x%"PRIx64"\n",
+               addr);
+    }
+
+    return 0;
+}
+
 static void xgene_storm_reset(void)
 {
     void __iomem *addr;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:46:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqluv-0007Nk-In; Tue, 18 Nov 2014 16:46: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 1Xqluu-0007ND-0r
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:46:12 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C4/DA-29352-FC77B645; Tue, 18 Nov 2014 16:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416329164!6654814!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2406 invoked from network); 18 Nov 2014 16:46:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:46:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192549502"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:44:52 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xqltb-0008T9-NM;
	Tue, 18 Nov 2014 16:44:52 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Tue, 18 Nov
	2014 16:44:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:44:48 +0000
Message-ID: <1416329088-23328-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416329045.17982.27.camel@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4 PCI
	buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only establish specific mappings for pcie0, which is
used on the Mustang platform. However at least McDivitt uses pcie3.
So wire up all the others, based on whether the corresponding DT node
is marked as available.

This results in no change for Mustang.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/platforms/xgene-storm.c |   84 ++++++++++++++++++++++++++++------
 1 file changed, 71 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 6c432a1..926c325 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -78,35 +78,31 @@ static int map_one_spi(struct domain *d, const char *what,
     return ret;
 }
 
-/*
- * Xen does not currently support mapping MMIO regions and interrupt
- * for bus child devices (referenced via the "ranges" and
- * "interrupt-map" properties to domain 0). Instead for now map the
- * necessary resources manually.
- */
-static int xgene_storm_specific_mapping(struct domain *d)
+/* Creates MMIO mappings base..end as well as 4 SPIs from the given base. */
+static int xgene_storm_pcie_specific_mapping(struct domain *d,
+                                             paddr_t base, paddr_t end,
+                                             int base_spi)
 {
     int ret;
 
     /* Map the PCIe bus resources */
-    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
-                                        paddr_to_pfn(0x01000000000UL));
+    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(base), paddr_to_pfn(end));
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTA", 0xc2, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTA", base_spi+0, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTB", 0xc3, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTB", base_spi+1, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTC", 0xc4, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTC", base_spi+2, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTD", 0xc5, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTD", base_spi+3, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
@@ -115,6 +111,68 @@ err:
     return ret;
 }
 
+/*
+ * Xen does not currently support mapping MMIO regions and interrupt
+ * for bus child devices (referenced via the "ranges" and
+ * "interrupt-map" properties to domain 0). Instead for now map the
+ * necessary resources manually.
+ */
+static int xgene_storm_specific_mapping(struct domain *d)
+{
+    struct dt_device_node *node = NULL;
+    int ret;
+
+    while ( (node = dt_find_compatible_node(node, "pci", "apm,xgene-pcie")) )
+    {
+        u64 addr;
+
+        /* Identify the bus via it's control register address */
+        ret = dt_device_get_address(node, 0, &addr, NULL);
+        if ( ret < 0 )
+            return ret;
+
+        if ( !dt_device_is_available(node) )
+            continue;
+
+       switch ( addr )
+        {
+        case 0x1f2b0000: /* PCIe0 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                0x0e000000000UL, 0x10000000000UL, 0xc2);
+            break;
+        case 0x1f2c0000: /* PCIe1 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                0x0d000000000UL, 0x0e000000000UL, 0xc8);
+            break;
+        case 0x1f2d0000: /* PCIe2 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                0x09000000000UL, 0x0a000000000UL, 0xce);
+            break;
+        case 0x1f500000: /* PCIe3 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                0x0a000000000UL, 0x0c000000000UL, 0xd4);
+            break;
+        case 0x1f510000: /* PCIe4 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                0x0c000000000UL, 0x0d000000000UL, 0xda);
+            break;
+
+        default:
+            /* Ignore unknown PCI busses */
+            ret = 0;
+            break;
+        }
+
+        if ( ret < 0 )
+            return ret;
+
+        printk("Mapped additional regions for PCIe device at 0x%"PRIx64"\n",
+               addr);
+    }
+
+    return 0;
+}
+
 static void xgene_storm_reset(void)
 {
     void __iomem *addr;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:46:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 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 1Xqlv5-0007Qh-VF; Tue, 18 Nov 2014 16:46:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xqlv3-0007Pz-TS
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:46:22 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	63/DA-31453-DD77B645; Tue, 18 Nov 2014 16:46:21 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416329177!12106163!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20515 invoked from network); 18 Nov 2014 16:46:19 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:46:19 -0000
Received: from mail-qg0-f42.google.com ([209.85.192.42]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGt32GowgUAlt2iYvGKo1wDK42lbqC9w@postini.com;
	Tue, 18 Nov 2014 08:46:18 PST
Received: by mail-qg0-f42.google.com with SMTP id i50so17452666qgf.15
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:46:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=MVnok6dEYP69q7CTawP9q5dez4D++iKF5kjvY4Txot8=;
	b=gFlZZdErE7yadcsP5VZJsUiRlPKa0AgHSKZpOaQYlCjJi8W/vqUp+jkOB7hYcPEv/7
	WqetMRQ5UgUeb1xhEykuTyt84fsbkZyZ76aNCQ04NaMl2n3Ajdhrcj42TOoOVDozz3Yb
	v+S6Un4f8syZeXWPiuR6uUPlMFjmO85MwkxG4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=MVnok6dEYP69q7CTawP9q5dez4D++iKF5kjvY4Txot8=;
	b=D3lrAKbh31JJljgQJVXp0BhJTDh9SAZ9w+jACx4G9fRe9yqAHV0keqOfQ5H07uDEPD
	XbpNHH9mBk/VyeazxjpE06CqYDyLCyK8EEFDiIyZBvdaBdMOW/kXp1E7eYZUFsF/2Et3
	W8hnUCDUjff8hoa+9anMn6K4RdU2+X31uVMdnlAd50vBLDLbAsfafwuhHqdC5UMpB+LF
	LzaG2vnE91lQeuTGRYbd51vz5HpFLrHFJ+MdRTVWXSoVtAo7Ro7ZiaAjj/DEPsOp8XgA
	om3nJO9PX2zt8nJjnAW/KP6Er6zY34MXIH3aShl0mqjsMNeLvnd/T/cJae8OOZv9ctdJ
	X33Q==
X-Gm-Message-State: ALoCoQk4VaQWJUSE69Ex+ayCF9DdgPRMzlA3uIxuQe8C2t8t+8MCIDEamR5dLabJosg8/0vM9jfD6vJhWJ0C4X4IwDHy9PpOvABvQNsy5ijy5M5MD74BuDZq5swu1KHr3dW/6FqCpgy0Gyn7+RJup/erJh0o9nc2PA==
X-Received: by 10.229.7.138 with SMTP id d10mr2581790qcd.18.1416329176492;
	Tue, 18 Nov 2014 08:46:16 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.229.7.138 with SMTP id d10mr2581771qcd.18.1416329176366;
	Tue, 18 Nov 2014 08:46:16 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Tue, 18 Nov 2014 08:46:15 -0800 (PST)
In-Reply-To: <CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
Date: Tue, 18 Nov 2014 18:46:15 +0200
Message-ID: <CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

No hangs with this change.
Complete log is the following:

U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
DRA752 ES1.0
<ethaddr> not set. Validating first E-fuse MAC
cpsw
- UART enabled -
- CPU 00000000 booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 0000000080000000 - 000000009fffffff
(XEN) RAM: 00000000a0000000 - 00000000bfffffff
(XEN) RAM: 00000000c0000000 - 00000000dfffffff
(XEN)
(XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
(XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
(XEN) MODULE[3]: 0000000000000000 - 0000000000000000
(XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
(XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
(XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
(XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
(XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
(XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
(XEN)
(XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
(XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
(XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
(XEN) Dom heap: 344064 pages
(XEN) Domain heap initialised
(XEN) Looking for UART console serial0
 Xen 4.5-unstable
(XEN) Xen version 4.5-unstable (atseglytskyi@)
(arm-linux-gnueabihf-gcc (crosstool-NG
linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
20130328 (prerelease)) debu4
(XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
(XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
(XEN) 32-bit Execution:
(XEN)   Processor Features: 00001131:00011011
(XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
(XEN)     Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 00000000
(XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
(XEN) Platform: TI DRA7
(XEN) /psci method must be smc, but is: "hvc"
(XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
(XEN) Set AuxCoreBoot0 to 0x20
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
(XEN) Using generic timer at 6144 KHz
(XEN) GIC initialization:
(XEN)         gic_dist_addr=0000000048211000
(XEN)         gic_cpu_addr=0000000048212000
(XEN)         gic_hyp_addr=0000000048214000
(XEN)         gic_vcpu_addr=0000000048216000
(XEN)         gic_maintenance_irq=25
(XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) I/O virtualisation disabled
(XEN) Allocated console ring of 16 KiB.
(XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
(XEN) Bringing up CPU1
- CPU 00000001 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 1 booted.
(XEN) Brought up 2 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module 2
(XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
(XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
(XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 272kB init memory.
(XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
already pending in LR0
(XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
already pending in LR0
[    0.000000] /cpus/cpu@0 missing clock-frequency property
[    0.000000] /cpus/cpu@1 missing clock-frequency property
[    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
[    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
[    0.273437] i2c i2c-1: of_i2c: invalid reg on
/ocp/i2c@48072000/camera_ov10635
[    0.437500] ldo3: operation not allowed
[    0.437500] omapdss HDMI error: can't set the voltage regulator
[    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
[    0.468750] ov1063x 1-0030: No deserializer node found
[    0.468750] ov1063x 1-0030: No serializer node found
[    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
[    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
[    0.578125] ahci ahci.0.auto: can't get clock
[    0.898437] ldc_module_init
[    1.304687] Missing dual_emac_res_vlan in DT.
[    1.304687] Using 1 as Reserved VLAN for 0 slave
[    1.312500] Missing dual_emac_res_vlan in DT.
[    1.320312] Using 2 as Reserved VLAN for 1 slave
[    1.382812] Freeing init memory: 236K
sh: write error: No such device
Cannot identify '/dev/camera0': 2, No such file or directory
Parsing config from /xen/images/DomUAndroid.cfg
XSM Disabled: seclabel not supported
(XEN) do_physdev_op 16 cmd=13: not implemented yet
libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
dom1 access to irq 53: Function not implemented
(XEN) do_physdev_op 16 cmd=13: not implemented yet
libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
dom1 access to irq 71: Function not implemented
(XEN) do_physdev_op 16 cmd=13: not implemented yet
libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
dom1 access to irq 173: Function not implemented
(XEN) do_physdev_op 16 cmd=13: not implemented yet
libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
dom1 access to irq 174: Function not implemented
Turning on vfb in domain 1
(XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
still lr_pending
(XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
still lr_pending
Parsing config from /xen/images/DomUQNX.cfg
XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
inject irq=2 into d0v0, when it is still lr_pending

(XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
still lr_pending
[    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
[    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
found: Invalid kernel
libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
failed: No such file or directory
libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
(re-)build domain: -3
(XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
still lr_pending
(XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
still lr_pending
Turning on 'vsnd' in domain '1' (dev_id: '0')
Turning on vkbd in domain 1
(XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
still lr_pending
(XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
still lr_pending
(XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
still lr_pending

Please press Enter to activate this console. (XEN) gic.c:617:d0v1
trying to inject irq=2 into d0v0, when it is still lr_pending

On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> OK got it. Give me a few mins
>
> On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
>> for non-hardware irqs (desc == NULL) and keep avoiding
>> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
>>
>> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
>> other potential bugs introduced later.
>>
>> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>>> What if I try on top of current master branch the following code:
>>>
>>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>>> index 31fb81a..6764ab7 100644
>>> --- a/xen/arch/arm/gic-v2.c
>>> +++ b/xen/arch/arm/gic-v2.c
>>> @@ -36,6 +36,8 @@
>>>  #include <asm/io.h>
>>>  #include <asm/gic.h>
>>>
>>> +#define GIC_DEBUG 1
>>> +
>>>  /*
>>>   * LR register definitions are GIC v2 specific.
>>>   * Moved these definitions from header file to here
>>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> index bcaded9..c03d6a6 100644
>>> --- a/xen/arch/arm/gic.c
>>> +++ b/xen/arch/arm/gic.c
>>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
>>>
>>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
>>> gic_hw_ops->info->nr_lrs) - 1))
>>>
>>> -#undef GIC_DEBUG
>>> +#define GIC_DEBUG 1
>>>
>>>  static void gic_update_one_lr(struct vcpu *v, int i);
>>>
>>> It is equivalent to what you proposing - my code contains
>>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
>>> be executed:
>>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
>>>
>>> regards,
>>> Andrii
>>>
>>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>>> >> everything works fine
>>> >> The following 2 patches fixes xen/master for my platform.
>>> >>
>>> >> Stefano, could you please take a look to these changes?
>>> >>
>>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
>>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
>>> >>
>>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>>> >>
>>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>>> >>
>>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>>> >> index 31fb81a..093ecdb 100644
>>> >> --- a/xen/arch/arm/gic-v2.c
>>> >> +++ b/xen/arch/arm/gic-v2.c
>>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>>> >> pending_irq *p,
>>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>>> >> GICH_V2_LR_VIRTUAL_SHIFT));
>>> >>
>>> >> -    if ( p->desc != NULL )
>>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>>> >>      {
>>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>>> >> -        else
>>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>>> >> GICH_V2_LR_PHYSICAL_MASK )
>>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>>> >> +    }
>>> >> +    else if ( p->desc != NULL )
>>> >> +    {
>>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>>> >>      }
>>> >>
>>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
>>> >
>>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
>>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
>>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
>>> > working correctly on OMAP5. This changes might only be better at
>>> > "hiding" the real issue.
>>> >
>>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
>>> > maintenance interrupts doesn't work for software interrupts.
>>> > The commit that should make them work correctly after the
>>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
>>> > If you look at the changes to gic_update_one_lr in that commit, you'll
>>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
>>> > Maybe that doesn't work correctly on OMAP5.
>>> >
>>> > Could you try this patch on top of
>>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
>>> > if the problem is specifically with software irqs.
>>> >
>>> >
>>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> > index b7516c0..d8a17c9 100644
>>> > --- a/xen/arch/arm/gic.c
>>> > +++ b/xen/arch/arm/gic.c
>>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>>> >  /* Maximum cpu interface per GIC */
>>> >  #define NR_GIC_CPU_IF 8
>>> >
>>> > -#undef GIC_DEBUG
>>> > +#define GIC_DEBUG 1
>>> >
>>> >  static void gic_update_one_lr(struct vcpu *v, int i);
>>> >
>>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>>> >      if ( p->desc != NULL )
>>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>>> > +    else
>>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>>> >
>>> >      GICH[GICH_LR + lr] = lr_val;
>>> >
>>>
>>>
>>>
>>> --
>>>
>>> Andrii Tseglytskyi | Embedded Dev
>>> GlobalLogic
>>> www.globallogic.com
>>>
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:46:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 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 1Xqlv5-0007Qh-VF; Tue, 18 Nov 2014 16:46:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xqlv3-0007Pz-TS
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:46:22 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	63/DA-31453-DD77B645; Tue, 18 Nov 2014 16:46:21 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416329177!12106163!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20515 invoked from network); 18 Nov 2014 16:46:19 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:46:19 -0000
Received: from mail-qg0-f42.google.com ([209.85.192.42]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGt32GowgUAlt2iYvGKo1wDK42lbqC9w@postini.com;
	Tue, 18 Nov 2014 08:46:18 PST
Received: by mail-qg0-f42.google.com with SMTP id i50so17452666qgf.15
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:46:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=MVnok6dEYP69q7CTawP9q5dez4D++iKF5kjvY4Txot8=;
	b=gFlZZdErE7yadcsP5VZJsUiRlPKa0AgHSKZpOaQYlCjJi8W/vqUp+jkOB7hYcPEv/7
	WqetMRQ5UgUeb1xhEykuTyt84fsbkZyZ76aNCQ04NaMl2n3Ajdhrcj42TOoOVDozz3Yb
	v+S6Un4f8syZeXWPiuR6uUPlMFjmO85MwkxG4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=MVnok6dEYP69q7CTawP9q5dez4D++iKF5kjvY4Txot8=;
	b=D3lrAKbh31JJljgQJVXp0BhJTDh9SAZ9w+jACx4G9fRe9yqAHV0keqOfQ5H07uDEPD
	XbpNHH9mBk/VyeazxjpE06CqYDyLCyK8EEFDiIyZBvdaBdMOW/kXp1E7eYZUFsF/2Et3
	W8hnUCDUjff8hoa+9anMn6K4RdU2+X31uVMdnlAd50vBLDLbAsfafwuhHqdC5UMpB+LF
	LzaG2vnE91lQeuTGRYbd51vz5HpFLrHFJ+MdRTVWXSoVtAo7Ro7ZiaAjj/DEPsOp8XgA
	om3nJO9PX2zt8nJjnAW/KP6Er6zY34MXIH3aShl0mqjsMNeLvnd/T/cJae8OOZv9ctdJ
	X33Q==
X-Gm-Message-State: ALoCoQk4VaQWJUSE69Ex+ayCF9DdgPRMzlA3uIxuQe8C2t8t+8MCIDEamR5dLabJosg8/0vM9jfD6vJhWJ0C4X4IwDHy9PpOvABvQNsy5ijy5M5MD74BuDZq5swu1KHr3dW/6FqCpgy0Gyn7+RJup/erJh0o9nc2PA==
X-Received: by 10.229.7.138 with SMTP id d10mr2581790qcd.18.1416329176492;
	Tue, 18 Nov 2014 08:46:16 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.229.7.138 with SMTP id d10mr2581771qcd.18.1416329176366;
	Tue, 18 Nov 2014 08:46:16 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Tue, 18 Nov 2014 08:46:15 -0800 (PST)
In-Reply-To: <CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNoQB1-XDYMzesNVXs5ZLiGKnF200O15KZ-wKLM24fH1Q@mail.gmail.com>
	<alpine.DEB.2.02.1411141613470.26318@kaball.uk.xensource.com>
	<CAH_mUMPgAyZgg7X2aSp9dsjmc7oX3nKBkqwPQucX0TnD6zNKAQ@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
Date: Tue, 18 Nov 2014 18:46:15 +0200
Message-ID: <CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

No hangs with this change.
Complete log is the following:

U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
DRA752 ES1.0
<ethaddr> not set. Validating first E-fuse MAC
cpsw
- UART enabled -
- CPU 00000000 booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 0000000080000000 - 000000009fffffff
(XEN) RAM: 00000000a0000000 - 00000000bfffffff
(XEN) RAM: 00000000c0000000 - 00000000dfffffff
(XEN)
(XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
(XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
(XEN) MODULE[3]: 0000000000000000 - 0000000000000000
(XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
(XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
(XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
(XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
(XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
(XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
(XEN)
(XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
(XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
(XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
(XEN) Dom heap: 344064 pages
(XEN) Domain heap initialised
(XEN) Looking for UART console serial0
 Xen 4.5-unstable
(XEN) Xen version 4.5-unstable (atseglytskyi@)
(arm-linux-gnueabihf-gcc (crosstool-NG
linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
20130328 (prerelease)) debu4
(XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
(XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
(XEN) 32-bit Execution:
(XEN)   Processor Features: 00001131:00011011
(XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
(XEN)     Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 00000000
(XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
(XEN) Platform: TI DRA7
(XEN) /psci method must be smc, but is: "hvc"
(XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
(XEN) Set AuxCoreBoot0 to 0x20
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
(XEN) Using generic timer at 6144 KHz
(XEN) GIC initialization:
(XEN)         gic_dist_addr=0000000048211000
(XEN)         gic_cpu_addr=0000000048212000
(XEN)         gic_hyp_addr=0000000048214000
(XEN)         gic_vcpu_addr=0000000048216000
(XEN)         gic_maintenance_irq=25
(XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) I/O virtualisation disabled
(XEN) Allocated console ring of 16 KiB.
(XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
(XEN) Bringing up CPU1
- CPU 00000001 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 1 booted.
(XEN) Brought up 2 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module 2
(XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
(XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
(XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 272kB init memory.
(XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
already pending in LR0
(XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
already pending in LR0
[    0.000000] /cpus/cpu@0 missing clock-frequency property
[    0.000000] /cpus/cpu@1 missing clock-frequency property
[    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
[    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
[    0.273437] i2c i2c-1: of_i2c: invalid reg on
/ocp/i2c@48072000/camera_ov10635
[    0.437500] ldo3: operation not allowed
[    0.437500] omapdss HDMI error: can't set the voltage regulator
[    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
[    0.468750] ov1063x 1-0030: No deserializer node found
[    0.468750] ov1063x 1-0030: No serializer node found
[    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
[    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
[    0.578125] ahci ahci.0.auto: can't get clock
[    0.898437] ldc_module_init
[    1.304687] Missing dual_emac_res_vlan in DT.
[    1.304687] Using 1 as Reserved VLAN for 0 slave
[    1.312500] Missing dual_emac_res_vlan in DT.
[    1.320312] Using 2 as Reserved VLAN for 1 slave
[    1.382812] Freeing init memory: 236K
sh: write error: No such device
Cannot identify '/dev/camera0': 2, No such file or directory
Parsing config from /xen/images/DomUAndroid.cfg
XSM Disabled: seclabel not supported
(XEN) do_physdev_op 16 cmd=13: not implemented yet
libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
dom1 access to irq 53: Function not implemented
(XEN) do_physdev_op 16 cmd=13: not implemented yet
libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
dom1 access to irq 71: Function not implemented
(XEN) do_physdev_op 16 cmd=13: not implemented yet
libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
dom1 access to irq 173: Function not implemented
(XEN) do_physdev_op 16 cmd=13: not implemented yet
libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
dom1 access to irq 174: Function not implemented
Turning on vfb in domain 1
(XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
still lr_pending
(XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
still lr_pending
Parsing config from /xen/images/DomUQNX.cfg
XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
inject irq=2 into d0v0, when it is still lr_pending

(XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
still lr_pending
[    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
[    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
found: Invalid kernel
libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
failed: No such file or directory
libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
(re-)build domain: -3
(XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
still lr_pending
(XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
still lr_pending
Turning on 'vsnd' in domain '1' (dev_id: '0')
Turning on vkbd in domain 1
(XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
still lr_pending
(XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
still lr_pending
(XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
still lr_pending

Please press Enter to activate this console. (XEN) gic.c:617:d0v1
trying to inject irq=2 into d0v0, when it is still lr_pending

On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> OK got it. Give me a few mins
>
> On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
>> for non-hardware irqs (desc == NULL) and keep avoiding
>> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
>>
>> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
>> other potential bugs introduced later.
>>
>> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>>> What if I try on top of current master branch the following code:
>>>
>>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>>> index 31fb81a..6764ab7 100644
>>> --- a/xen/arch/arm/gic-v2.c
>>> +++ b/xen/arch/arm/gic-v2.c
>>> @@ -36,6 +36,8 @@
>>>  #include <asm/io.h>
>>>  #include <asm/gic.h>
>>>
>>> +#define GIC_DEBUG 1
>>> +
>>>  /*
>>>   * LR register definitions are GIC v2 specific.
>>>   * Moved these definitions from header file to here
>>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> index bcaded9..c03d6a6 100644
>>> --- a/xen/arch/arm/gic.c
>>> +++ b/xen/arch/arm/gic.c
>>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
>>>
>>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
>>> gic_hw_ops->info->nr_lrs) - 1))
>>>
>>> -#undef GIC_DEBUG
>>> +#define GIC_DEBUG 1
>>>
>>>  static void gic_update_one_lr(struct vcpu *v, int i);
>>>
>>> It is equivalent to what you proposing - my code contains
>>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
>>> be executed:
>>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
>>>
>>> regards,
>>> Andrii
>>>
>>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>>> >> everything works fine
>>> >> The following 2 patches fixes xen/master for my platform.
>>> >>
>>> >> Stefano, could you please take a look to these changes?
>>> >>
>>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
>>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
>>> >>
>>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>>> >>
>>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>>> >>
>>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>>> >> index 31fb81a..093ecdb 100644
>>> >> --- a/xen/arch/arm/gic-v2.c
>>> >> +++ b/xen/arch/arm/gic-v2.c
>>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>>> >> pending_irq *p,
>>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>>> >> GICH_V2_LR_VIRTUAL_SHIFT));
>>> >>
>>> >> -    if ( p->desc != NULL )
>>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>>> >>      {
>>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>>> >> -        else
>>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>>> >> GICH_V2_LR_PHYSICAL_MASK )
>>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>>> >> +    }
>>> >> +    else if ( p->desc != NULL )
>>> >> +    {
>>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>>> >>      }
>>> >>
>>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
>>> >
>>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
>>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
>>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
>>> > working correctly on OMAP5. This changes might only be better at
>>> > "hiding" the real issue.
>>> >
>>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
>>> > maintenance interrupts doesn't work for software interrupts.
>>> > The commit that should make them work correctly after the
>>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
>>> > If you look at the changes to gic_update_one_lr in that commit, you'll
>>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
>>> > Maybe that doesn't work correctly on OMAP5.
>>> >
>>> > Could you try this patch on top of
>>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
>>> > if the problem is specifically with software irqs.
>>> >
>>> >
>>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> > index b7516c0..d8a17c9 100644
>>> > --- a/xen/arch/arm/gic.c
>>> > +++ b/xen/arch/arm/gic.c
>>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>>> >  /* Maximum cpu interface per GIC */
>>> >  #define NR_GIC_CPU_IF 8
>>> >
>>> > -#undef GIC_DEBUG
>>> > +#define GIC_DEBUG 1
>>> >
>>> >  static void gic_update_one_lr(struct vcpu *v, int i);
>>> >
>>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>>> >      if ( p->desc != NULL )
>>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>>> > +    else
>>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>>> >
>>> >      GICH[GICH_LR + lr] = lr_val;
>>> >
>>>
>>>
>>>
>>> --
>>>
>>> Andrii Tseglytskyi | Embedded Dev
>>> GlobalLogic
>>> www.globallogic.com
>>>
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:47:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 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.xen.org>)
	id 1Xqlw4-0007eo-M5; Tue, 18 Nov 2014 16:47:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkoch@verizon.com>) id 1Xqlw3-0007eV-4y
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:47:23 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	E4/07-17958-A187B645; Tue, 18 Nov 2014 16:47:22 +0000
X-Env-Sender: dkoch@verizon.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416329240!12226200!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17268 invoked from network); 18 Nov 2014 16:47:21 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:47:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dkoch@verizon.com; q=dns/txt; s=corp;
	t=1416329241; x=1447865241;
	h=date:from:to:cc:subject:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=VtLJz/cSJaiu2OZB5eIiyYApp/z25bYP4TeLD7TAWzo=;
	b=sAW4a68izS/FViL2GCrwyKzUf8+5Ng6F6QnpzqZQbhVANrsy1h9miK3q
	qUZtnb7U6/C1PQ/pb5mB0yJDN82uiQW/ozW2+KlmuZbskDBH6EqZXN9Oe
	58Wb9kh5G66wxrHxlNmrxG8V+IZGxHbe2bbdUOu8qiioefHSKA9rEI+Az E=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 18 Nov 2014 16:47:19 +0000
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="907870807"
Received: from unknown (HELO yoyo) ([162.47.6.23])
	by fldsmtpi01.verizon.com with SMTP; 18 Nov 2014 16:47:18 +0000
Date: Tue, 18 Nov 2014 11:47:18 -0500
From: Don Koch <dkoch@verizon.com>
To: Jan Beulich <JBeulich@suse.com>
Message-Id: <20141118114718.fbf2abb1c47eb595f383c6b3@verizon.com>
In-Reply-To: <546B836E0200007800048D91@mail.emea.novell.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
	<546B836E0200007800048D91@mail.emea.novell.com>
X-Mailer: Sylpheed 3.4.0beta6 (GTK+ 2.24.22; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 18 Nov 2014 16:35:42 +0000
Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 18.11.14 at 16:26, <dkoch@verizon.com> wrote:
> > If we restore an xsave area from an older xen that has a larger
> > size than the xcr0 bit call for, it is possible to have non-zero
> > data in the unused area if an xsave has ever been done that used
> > that area (e.g. during a context switch). Since the vcpu's xsave
> > area is never zeroed after the initial allocation, that data is
> > still there.
> 
> This needs more explanation: xcr0_accum is named this way
> because bits never disappear from it. Hence afaics any piece of
> the xsave area ever having got written with a non-zero value
> would be part of the data actually used on migration.

Let me investigate this further. Since the initial xsave area is cleared
when allocated, I see no other way to get anything in there.

> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
> >                  printk(XENLOG_G_WARNING
> >                         "HVM%d.%u restore mismatch: xsave length %#x > %#x (non-zero data at %#x)\n",
> >                         d->domain_id, vcpuid, desc->length, size, i);
> > -                return -EOPNOTSUPP;
> > +                break;
> >              }
> >          }
> >          printk(XENLOG_G_WARNING
> 
> Even if we really have to go this route, you should recall the
> discussion on the earlier patch of yours: The end result should
> not be that two messages get logged for a single event.

Ah, yes. Agreed. Will fix if my investigation reveals what occurred.

> Jan
> 

Konrad: Yes, this will be 4.5 fodder, pending the aforementioned
investigation.

Thanks,
-d

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:47:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 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.xen.org>)
	id 1Xqlw4-0007eo-M5; Tue, 18 Nov 2014 16:47:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkoch@verizon.com>) id 1Xqlw3-0007eV-4y
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:47:23 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	E4/07-17958-A187B645; Tue, 18 Nov 2014 16:47:22 +0000
X-Env-Sender: dkoch@verizon.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416329240!12226200!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17268 invoked from network); 18 Nov 2014 16:47:21 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:47:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dkoch@verizon.com; q=dns/txt; s=corp;
	t=1416329241; x=1447865241;
	h=date:from:to:cc:subject:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=VtLJz/cSJaiu2OZB5eIiyYApp/z25bYP4TeLD7TAWzo=;
	b=sAW4a68izS/FViL2GCrwyKzUf8+5Ng6F6QnpzqZQbhVANrsy1h9miK3q
	qUZtnb7U6/C1PQ/pb5mB0yJDN82uiQW/ozW2+KlmuZbskDBH6EqZXN9Oe
	58Wb9kh5G66wxrHxlNmrxG8V+IZGxHbe2bbdUOu8qiioefHSKA9rEI+Az E=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 18 Nov 2014 16:47:19 +0000
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="907870807"
Received: from unknown (HELO yoyo) ([162.47.6.23])
	by fldsmtpi01.verizon.com with SMTP; 18 Nov 2014 16:47:18 +0000
Date: Tue, 18 Nov 2014 11:47:18 -0500
From: Don Koch <dkoch@verizon.com>
To: Jan Beulich <JBeulich@suse.com>
Message-Id: <20141118114718.fbf2abb1c47eb595f383c6b3@verizon.com>
In-Reply-To: <546B836E0200007800048D91@mail.emea.novell.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
	<546B836E0200007800048D91@mail.emea.novell.com>
X-Mailer: Sylpheed 3.4.0beta6 (GTK+ 2.24.22; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 18 Nov 2014 16:35:42 +0000
Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 18.11.14 at 16:26, <dkoch@verizon.com> wrote:
> > If we restore an xsave area from an older xen that has a larger
> > size than the xcr0 bit call for, it is possible to have non-zero
> > data in the unused area if an xsave has ever been done that used
> > that area (e.g. during a context switch). Since the vcpu's xsave
> > area is never zeroed after the initial allocation, that data is
> > still there.
> 
> This needs more explanation: xcr0_accum is named this way
> because bits never disappear from it. Hence afaics any piece of
> the xsave area ever having got written with a non-zero value
> would be part of the data actually used on migration.

Let me investigate this further. Since the initial xsave area is cleared
when allocated, I see no other way to get anything in there.

> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
> >                  printk(XENLOG_G_WARNING
> >                         "HVM%d.%u restore mismatch: xsave length %#x > %#x (non-zero data at %#x)\n",
> >                         d->domain_id, vcpuid, desc->length, size, i);
> > -                return -EOPNOTSUPP;
> > +                break;
> >              }
> >          }
> >          printk(XENLOG_G_WARNING
> 
> Even if we really have to go this route, you should recall the
> discussion on the earlier patch of yours: The end result should
> not be that two messages get logged for a single event.

Ah, yes. Agreed. Will fix if my investigation reveals what occurred.

> Jan
> 

Konrad: Yes, this will be 4.5 fodder, pending the aforementioned
investigation.

Thanks,
-d

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:49:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:49:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlxu-0007yp-86; Tue, 18 Nov 2014 16:49:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xqlxs-0007yW-JZ
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:49:16 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	A3/2C-02576-B887B645; Tue, 18 Nov 2014 16:49:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416329355!13368087!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6315 invoked from network); 18 Nov 2014 16:49:15 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:49:15 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 16:49:15 +0000
Message-Id: <546B86990200007800048DBF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 16:49:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Simon Martin" <furryfuttock@gmail.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
In-Reply-To: <19872515.20141118132405@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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 18.11.14 at 17:24, <furryfuttock@gmail.com> wrote:
> Hello Jan,
> 
> Friday, November 14, 2014, 5:27:36 AM, you wrote:
> 
>>>> I implied your earlier statement to mean that. But - did you also
>>>> verify that the three flags actually end up set (ideally from both
>>>> DomU and Dom0 perspective)? The PCI backend may be screwing
>>>> up things...
>>> 
>>> Yes I do verify the write. How do I check this from Dom0?
> 
>> Just use lspci.
> 
> I've just checked this with lspci. I see that the IO is being enabled.

Memory you mean.

> Any   other   idea   on   why I might be reading back 0xff for all PCI
> memory area reads? The lspci output follows.

Since this isn't behind a bridge - no, not really. Did you try this with
any other device for comparison purposes?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:49:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:49:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqlxu-0007yp-86; Tue, 18 Nov 2014 16:49:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xqlxs-0007yW-JZ
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:49:16 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	A3/2C-02576-B887B645; Tue, 18 Nov 2014 16:49:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416329355!13368087!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6315 invoked from network); 18 Nov 2014 16:49:15 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 16:49:15 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 16:49:15 +0000
Message-Id: <546B86990200007800048DBF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 16:49:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Simon Martin" <furryfuttock@gmail.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
In-Reply-To: <19872515.20141118132405@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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 18.11.14 at 17:24, <furryfuttock@gmail.com> wrote:
> Hello Jan,
> 
> Friday, November 14, 2014, 5:27:36 AM, you wrote:
> 
>>>> I implied your earlier statement to mean that. But - did you also
>>>> verify that the three flags actually end up set (ideally from both
>>>> DomU and Dom0 perspective)? The PCI backend may be screwing
>>>> up things...
>>> 
>>> Yes I do verify the write. How do I check this from Dom0?
> 
>> Just use lspci.
> 
> I've just checked this with lspci. I see that the IO is being enabled.

Memory you mean.

> Any   other   idea   on   why I might be reading back 0xff for all PCI
> memory area reads? The lspci output follows.

Since this isn't behind a bridge - no, not really. Did you try this with
any other device for comparison purposes?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlyP-000840-Ke; Tue, 18 Nov 2014 16:49:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqlyP-00083o-6a
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 16:49:49 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	A3/2A-22737-CA87B645; Tue, 18 Nov 2014 16:49:48 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416329386!12080794!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11954 invoked from network); 18 Nov 2014 16:49:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:49:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192551837"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:49:40 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqlyG-00005k-JN;
	Tue, 18 Nov 2014 16:49:40 +0000
Date: Tue, 18 Nov 2014 16:49:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <linux@arm.linux.org.uk>
In-Reply-To: <alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411181649000.27247@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, linux@arm.linux.org.uk,
	Ian Campbell <Ian.Campbell@citrix.com>, catalin.marinas@arm.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 05/13] arm: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ping?

On Fri, 14 Nov 2014, Stefano Stabellini wrote:
> Russell,
> this patch needs your feedback.
> 
> - Stefano
> 
> On Wed, 12 Nov 2014, Stefano Stabellini wrote:
> > Introduce a boolean flag and an accessor function to check whether a
> > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > CC: linux@arm.linux.org.uk
> > ---
> >  arch/arm/include/asm/device.h      |    1 +
> >  arch/arm/include/asm/dma-mapping.h |    6 ++++++
> >  2 files changed, 7 insertions(+)
> > 
> > diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> > index dc662fc..4111592 100644
> > --- a/arch/arm/include/asm/device.h
> > +++ b/arch/arm/include/asm/device.h
> > @@ -17,6 +17,7 @@ struct dev_archdata {
> >  #ifdef CONFIG_ARM_DMA_USE_IOMMU
> >  	struct dma_iommu_mapping	*mapping;
> >  #endif
> > +	bool dma_coherent;
> >  };
> >  
> >  struct omap_device;
> > diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> > index 85738b2..8c3b616 100644
> > --- a/arch/arm/include/asm/dma-mapping.h
> > +++ b/arch/arm/include/asm/dma-mapping.h
> > @@ -123,11 +123,17 @@ static inline unsigned long dma_max_pfn(struct device *dev)
> >  
> >  static inline int set_arch_dma_coherent_ops(struct device *dev)
> >  {
> > +	dev->archdata.dma_coherent = true;
> >  	set_dma_ops(dev, &arm_coherent_dma_ops);
> >  	return 0;
> >  }
> >  #define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
> >  
> > +static inline bool is_device_dma_coherent(struct device *dev)
> > +{
> > +	return dev->archdata.dma_coherent;
> > +}
> > +
> >  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
> >  {
> >  	unsigned int offset = paddr & ~PAGE_MASK;
> > -- 
> > 1.7.10.4
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqlyP-000840-Ke; Tue, 18 Nov 2014 16:49:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XqlyP-00083o-6a
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 16:49:49 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	A3/2A-22737-CA87B645; Tue, 18 Nov 2014 16:49:48 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416329386!12080794!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11954 invoked from network); 18 Nov 2014 16:49:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:49:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192551837"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 11:49:40 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqlyG-00005k-JN;
	Tue, 18 Nov 2014 16:49:40 +0000
Date: Tue, 18 Nov 2014 16:49:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <linux@arm.linux.org.uk>
In-Reply-To: <alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411181649000.27247@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, linux@arm.linux.org.uk,
	Ian Campbell <Ian.Campbell@citrix.com>, catalin.marinas@arm.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 05/13] arm: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ping?

On Fri, 14 Nov 2014, Stefano Stabellini wrote:
> Russell,
> this patch needs your feedback.
> 
> - Stefano
> 
> On Wed, 12 Nov 2014, Stefano Stabellini wrote:
> > Introduce a boolean flag and an accessor function to check whether a
> > device is dma_coherent. Set the flag from set_arch_dma_coherent_ops.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > CC: linux@arm.linux.org.uk
> > ---
> >  arch/arm/include/asm/device.h      |    1 +
> >  arch/arm/include/asm/dma-mapping.h |    6 ++++++
> >  2 files changed, 7 insertions(+)
> > 
> > diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> > index dc662fc..4111592 100644
> > --- a/arch/arm/include/asm/device.h
> > +++ b/arch/arm/include/asm/device.h
> > @@ -17,6 +17,7 @@ struct dev_archdata {
> >  #ifdef CONFIG_ARM_DMA_USE_IOMMU
> >  	struct dma_iommu_mapping	*mapping;
> >  #endif
> > +	bool dma_coherent;
> >  };
> >  
> >  struct omap_device;
> > diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> > index 85738b2..8c3b616 100644
> > --- a/arch/arm/include/asm/dma-mapping.h
> > +++ b/arch/arm/include/asm/dma-mapping.h
> > @@ -123,11 +123,17 @@ static inline unsigned long dma_max_pfn(struct device *dev)
> >  
> >  static inline int set_arch_dma_coherent_ops(struct device *dev)
> >  {
> > +	dev->archdata.dma_coherent = true;
> >  	set_dma_ops(dev, &arm_coherent_dma_ops);
> >  	return 0;
> >  }
> >  #define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
> >  
> > +static inline bool is_device_dma_coherent(struct device *dev)
> > +{
> > +	return dev->archdata.dma_coherent;
> > +}
> > +
> >  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
> >  {
> >  	unsigned int offset = paddr & ~PAGE_MASK;
> > -- 
> > 1.7.10.4
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:52:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1Xqm0a-0008J3-Nc; Tue, 18 Nov 2014 16:52: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 1Xqm0Z-0008Iu-Jt
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:52:03 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	54/42-14214-2397B645; Tue, 18 Nov 2014 16:52:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416329518!12081257!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17247 invoked from network); 18 Nov 2014 16:52:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:52:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192552865"
Message-ID: <1416329502.17982.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:51:42 +0000
In-Reply-To: <1416329045.17982.27.camel@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/4 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 16:44 +0000, Ian Campbell wrote:
> These patches:

... which are also at
        git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v1

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 16:52:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 16: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 1Xqm0a-0008J3-Nc; Tue, 18 Nov 2014 16:52: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 1Xqm0Z-0008Iu-Jt
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:52:03 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	54/42-14214-2397B645; Tue, 18 Nov 2014 16:52:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416329518!12081257!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17247 invoked from network); 18 Nov 2014 16:52:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:52:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="192552865"
Message-ID: <1416329502.17982.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 16:51:42 +0000
In-Reply-To: <1416329045.17982.27.camel@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/4 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 16:44 +0000, Ian Campbell wrote:
> These patches:

... which are also at
        git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v1

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:00:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqm88-000090-1w; Tue, 18 Nov 2014 16:59:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xqm87-00008v-2U
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:59:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BA/7F-25276-60B7B645; Tue, 18 Nov 2014 16:59:50 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416329989!13690571!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14184 invoked from network); 18 Nov 2014 16:59:50 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:59:50 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so13472815wid.0
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:59:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=yrKYbKslzekI1FTZp2BGUzKiUgnrH82nCR0SRfMia38=;
	b=ZbxsZtxCuAYw7qj4NjpySMczmxgCVCO12HZ0Qn+eLKKinP8t2KhpJx0+n/WZgVqe8H
	OLlfAal1JCiU63DdmTheTO6iAS9DkamNPtlGyC4PCBfkaItmOt1W2Ifk3DNuTGwd+Gzo
	s6wAPfQRy8dHxxMpMVs23a0hQeApcjtYcDS6WWFW6mImexfLlWTEGcEoDF/HbxBm5DqD
	P1vqwwGZfwlFBa9wvIT2+fJMfHXehnPPWxUPAd3B2k2uRKvxtpEhK2KshkFKGimq/W8R
	GXDAf4WAjZeo41Ls8WP6Hghjo2QpVgpfrojnvzGU5uMg3aCPyRmKIasm3rwVdR4BSSST
	/KaQ==
X-Gm-Message-State: ALoCoQnCHuivnPg9wLUR/0V/TGUDSqArtBNLi0XAskm5mLjdz6d5omu7bqkA+4qOE7x9ikhTqaHb
X-Received: by 10.194.19.4 with SMTP id a4mr49026282wje.3.1416329989819;
	Tue, 18 Nov 2014 08:59:49 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	j17sm42784202wjn.32.2014.11.18.08.59.48 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 08:59:49 -0800 (PST)
Message-ID: <546B7B02.6050104@linaro.org>
Date: Tue, 18 Nov 2014 16:59:46 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416329088-23328-1-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 1/4] xen: arm: Add earlyprintk for
	McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/18/2014 04:44 PM, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/Rules.mk |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index 572d854..ef887a5 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -95,6 +95,12 @@ EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0x1c020000
>  EARLY_UART_REG_SHIFT := 2
>  endif
> +ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
> +EARLY_PRINTK_INC := 8250
> +EARLY_PRINTK_BAUD := 9600

EARLY_PRINTK_BAUD is not necessary as we don't use the initialization
function (EARLY_PRINTK_INIT_UART is not set).

With the EARLY_PRINTK_BAUD dropped, this could be merged with the
xgene-storm  early printk (I didn't really understand why the baud rate
is different). But I don't think it's 4.5 material.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:00:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqm88-000090-1w; Tue, 18 Nov 2014 16:59:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xqm87-00008v-2U
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 16:59:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BA/7F-25276-60B7B645; Tue, 18 Nov 2014 16:59:50 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416329989!13690571!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14184 invoked from network); 18 Nov 2014 16:59:50 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 16:59:50 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so13472815wid.0
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 08:59:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=yrKYbKslzekI1FTZp2BGUzKiUgnrH82nCR0SRfMia38=;
	b=ZbxsZtxCuAYw7qj4NjpySMczmxgCVCO12HZ0Qn+eLKKinP8t2KhpJx0+n/WZgVqe8H
	OLlfAal1JCiU63DdmTheTO6iAS9DkamNPtlGyC4PCBfkaItmOt1W2Ifk3DNuTGwd+Gzo
	s6wAPfQRy8dHxxMpMVs23a0hQeApcjtYcDS6WWFW6mImexfLlWTEGcEoDF/HbxBm5DqD
	P1vqwwGZfwlFBa9wvIT2+fJMfHXehnPPWxUPAd3B2k2uRKvxtpEhK2KshkFKGimq/W8R
	GXDAf4WAjZeo41Ls8WP6Hghjo2QpVgpfrojnvzGU5uMg3aCPyRmKIasm3rwVdR4BSSST
	/KaQ==
X-Gm-Message-State: ALoCoQnCHuivnPg9wLUR/0V/TGUDSqArtBNLi0XAskm5mLjdz6d5omu7bqkA+4qOE7x9ikhTqaHb
X-Received: by 10.194.19.4 with SMTP id a4mr49026282wje.3.1416329989819;
	Tue, 18 Nov 2014 08:59:49 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	j17sm42784202wjn.32.2014.11.18.08.59.48 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 08:59:49 -0800 (PST)
Message-ID: <546B7B02.6050104@linaro.org>
Date: Tue, 18 Nov 2014 16:59:46 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416329088-23328-1-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 1/4] xen: arm: Add earlyprintk for
	McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/18/2014 04:44 PM, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/Rules.mk |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index 572d854..ef887a5 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -95,6 +95,12 @@ EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0x1c020000
>  EARLY_UART_REG_SHIFT := 2
>  endif
> +ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
> +EARLY_PRINTK_INC := 8250
> +EARLY_PRINTK_BAUD := 9600

EARLY_PRINTK_BAUD is not necessary as we don't use the initialization
function (EARLY_PRINTK_INIT_UART is not set).

With the EARLY_PRINTK_BAUD dropped, this could be merged with the
xgene-storm  early printk (I didn't really understand why the baud rate
is different). But I don't think it's 4.5 material.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:01:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:01:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqm9y-0000Hp-KM; Tue, 18 Nov 2014 17:01:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xqm9x-0000HY-Dq
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:01:45 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	E3/3A-29352-87B7B645; Tue, 18 Nov 2014 17:01:44 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416330104!12041720!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15646 invoked from network); 18 Nov 2014 17:01:44 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:01:44 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so6944636wiv.14
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 09:01:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=LPRZFVdxpSASlHHFWPDm+hCuuCpGCCT08oDwozxNUr8=;
	b=MBCG1oCb+zPKleqdnVMtMOgn5VbsUiuCF1q07RJ2/aN7+BbrJ65MsmmcoMuyAGScra
	rPOgE98HFdN6j+eg3wB4HTqoXLfADbSppL+n/pFL3/3L6j5dgHuMvSZNHusUOPb4HrnI
	O2HeHj03Ut2J8nVrzZvu1pJH6ITO11dkoQ2FQBvtQnzXzHWwnpP1C4pnHYqdayvwQ8lF
	ILFBGOQmbtMx5/wk8Kp+h1VchOQE87ygVdsBKxsk76Dmcrs6nfx5nhXCZmLzdK6PQmhA
	dvfPkuj0x8lFY2dTK9hAd6ZMo4TwcFbdFg9w7uR0tTLgiTiKLuurATMEADKs36/aEH+C
	w3mA==
X-Gm-Message-State: ALoCoQlhB1yPy/kZvYlgQuwZ6J38EF4UkcJbK9++TTcp4O1cqdjCAlAvNVwwavZGTzQsnCRqm7Ta
X-Received: by 10.180.14.226 with SMTP id s2mr40733328wic.61.1416330103836;
	Tue, 18 Nov 2014 09:01:43 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id j2sm25378209wjs.28.2014.11.18.09.01.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 09:01:42 -0800 (PST)
Message-ID: <546B7B74.2090909@linaro.org>
Date: Tue, 18 Nov 2014 17:01:40 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 2/4] xen: arm: correct off by one in
 xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/18/2014 04:44 PM, Ian Campbell wrote:
> The callers pass the end as the pfn immediately *after* the last page to be
> mapped, therefore adding one is incorrect and causes an additional page to be
> mapped.
> 
> At the same time correct the printing of the mfn values, zero-padding them to
> 16 digits as for a paddr when they are frame numbers is just confusing.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/platforms/xgene-storm.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 29c4752..38674cd 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -45,9 +45,9 @@ static int map_one_mmio(struct domain *d, const char *what,
>  {
>      int ret;
>  
> -    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
> +    printk("Additional MMIO %lx-%lx (%s)\n",
>             start, end, what);
> -    ret = map_mmio_regions(d, start, end - start + 1, start);
> +    ret = map_mmio_regions(d, start, end - start, start);
>      if ( ret )
>          printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
>                 what, start, d->domain_id);

As you fixed the previous printf format. I would fix this one too.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:01:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:01:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqm9y-0000Hp-KM; Tue, 18 Nov 2014 17:01:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xqm9x-0000HY-Dq
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:01:45 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	E3/3A-29352-87B7B645; Tue, 18 Nov 2014 17:01:44 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416330104!12041720!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15646 invoked from network); 18 Nov 2014 17:01:44 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:01:44 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so6944636wiv.14
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 09:01:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=LPRZFVdxpSASlHHFWPDm+hCuuCpGCCT08oDwozxNUr8=;
	b=MBCG1oCb+zPKleqdnVMtMOgn5VbsUiuCF1q07RJ2/aN7+BbrJ65MsmmcoMuyAGScra
	rPOgE98HFdN6j+eg3wB4HTqoXLfADbSppL+n/pFL3/3L6j5dgHuMvSZNHusUOPb4HrnI
	O2HeHj03Ut2J8nVrzZvu1pJH6ITO11dkoQ2FQBvtQnzXzHWwnpP1C4pnHYqdayvwQ8lF
	ILFBGOQmbtMx5/wk8Kp+h1VchOQE87ygVdsBKxsk76Dmcrs6nfx5nhXCZmLzdK6PQmhA
	dvfPkuj0x8lFY2dTK9hAd6ZMo4TwcFbdFg9w7uR0tTLgiTiKLuurATMEADKs36/aEH+C
	w3mA==
X-Gm-Message-State: ALoCoQlhB1yPy/kZvYlgQuwZ6J38EF4UkcJbK9++TTcp4O1cqdjCAlAvNVwwavZGTzQsnCRqm7Ta
X-Received: by 10.180.14.226 with SMTP id s2mr40733328wic.61.1416330103836;
	Tue, 18 Nov 2014 09:01:43 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id j2sm25378209wjs.28.2014.11.18.09.01.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 09:01:42 -0800 (PST)
Message-ID: <546B7B74.2090909@linaro.org>
Date: Tue, 18 Nov 2014 17:01:40 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 2/4] xen: arm: correct off by one in
 xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/18/2014 04:44 PM, Ian Campbell wrote:
> The callers pass the end as the pfn immediately *after* the last page to be
> mapped, therefore adding one is incorrect and causes an additional page to be
> mapped.
> 
> At the same time correct the printing of the mfn values, zero-padding them to
> 16 digits as for a paddr when they are frame numbers is just confusing.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/platforms/xgene-storm.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 29c4752..38674cd 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -45,9 +45,9 @@ static int map_one_mmio(struct domain *d, const char *what,
>  {
>      int ret;
>  
> -    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
> +    printk("Additional MMIO %lx-%lx (%s)\n",
>             start, end, what);
> -    ret = map_mmio_regions(d, start, end - start + 1, start);
> +    ret = map_mmio_regions(d, start, end - start, start);
>      if ( ret )
>          printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
>                 what, start, d->domain_id);

As you fixed the previous printf format. I would fix this one too.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:03:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmBf-0000S7-6W; Tue, 18 Nov 2014 17:03:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqmBd-0000Rt-Go
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 17:03:29 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	34/0D-02559-0EB7B645; Tue, 18 Nov 2014 17:03:28 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416330206!13339508!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18281 invoked from network); 18 Nov 2014 17:03:26 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 18 Nov 2014 17:03:26 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52946 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqmA5-0004JH-RU; Tue, 18 Nov 2014 18:01:53 +0100
Date: Tue, 18 Nov 2014 18:03:23 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1222042576.20141118180323@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141118161650.GC17095@laptop.dumpdata.com>
References: <1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, November 18, 2014, 5:16:50 PM, you wrote:

>> Without #define DIFF_LIST 1:
>> 1) The guest still crashes (xl-dmesg-not-defined.txt)

> AHA!

>  --MARK--
>   0: ffff8305085ffd28 [p:ffff83054ef27e88, n:ffff83054ef27e88]
>   1: ffff8305085ffd28 [p:0200200200200200, n:0100100100100100]

> The same pirq_dpci structure is put twice on the list. That
> will surely make it unhappy. The reason the #define DIFF_LIST 1
> would work is that it has code to deal with that odd scenario.

> But .. more importantly - the code should not allow you to
> put _two_ of the same 'pirq_dpci' structures on the list.

>  CPU00: 
>  d16 OK-softirq 186msec ago, state:1, 3257 count, [prev:ffff82d0802e7e88, next:ffff82d0802e7e88] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  d16 OK-raise   236msec ago, state:1, 3257 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  CPU01: 
>  d16 OK-softirq 232msec ago, state:1, 2978 count, [prev:ffff83054ef57e70, next:ffff83054ef57e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  d16 OK-raise   281msec ago, state:1, 2978 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  CPU02: 
>  d16 OK-softirq 373msec ago, state:1, 2378 count, [prev:ffff83054ef47e70, next:ffff83054ef47e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  d16 OK-raise   423msec ago, state:1, 2378 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  CPU03: 
>  d16 OK-softirq 867msec ago, state:1, 2744 count, [prev:ffff83054ef37e70, next:ffff83054ef37e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  d16 OK-raise   916msec ago, state:1, 2744 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  CPU04: 
>  d16 OK-softirq 497msec ago, state:1, 76910 count, [prev:ffff83054ef2e3e0, next:ffff83054ef2e3e0] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>  d16 OK-raise   489msec ago, state:1, 76916 count, [prev:ffff83054ef2e3e0, next:ffff83054ef2e3e0] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>  d16 ERR-poison 600msec ago, state:0, 1 count, [prev:0200200200200200, next:0100100100100100] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>  CPU05: 
>  d16 OK-softirq 852msec ago, state:1, 2207 count, [prev:ffff83054ef1fe70, next:ffff83054ef1fe70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  d16 OK-raise   902msec ago, state:1, 2207 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  domain_crash called from io.c:964
>  Domain 16 reported crashed by domain 7 on cpu#4:


>> 
>> With #define DIFF_LIST 1:
>> 2) Nor the guest or the host crashed (let it run for about an hour and 15 minutes), 
>>    but the USB XHCI driver bailed out quickly after guest boot, so there were no MSI-X interrupts anymore.
>>    (xl-dmesg-defined-nousb.txt, dmesg-guest-defined-nousb.txt)

> Hm, that is odd. Can you tell me how you get your SeaBIOS to add those
> extra statements? I don't seem to see them with my SeaBIOS (I've an XHCI
> controlled hooked up to the guest too). Maybe I am missing an CONFIG in the
> SeaBIOS build.

Uhmm i thought i had these switched off (due to problems earlier and then forgot 
about them .. however looking at the earlier reports these lines were also in 
those reports).

The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
branch), so the qemu-xen and seabios defined with that were also freshly cloned 
and had a new default seabios config. (just to rule out anything stale in my tree)

If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
seabios config) are not the most recent (they don't get updated automatically 
when you just do a git pull on the main tree) ?

In /tools/firmware/seabios-dir/.config i have:
CONFIG_USB=y
CONFIG_USB_UHCI=y
CONFIG_USB_OHCI=y
CONFIG_USB_EHCI=y
CONFIG_USB_XHCI=y
CONFIG_USB_MSC=y
CONFIG_USB_UAS=y
CONFIG_USB_HUB=y
CONFIG_USB_KEYBOARD=y
CONFIG_USB_MOUSE=y

And this is all just from a:
- git clone git://xenbits.xen.org/xen.git -b staging
- make clean && ./configure && make -j6 && make -j6 install

>> 3) On another boot the USB XHCI didn't bail out, after a while the host crashes. (serial.log)
>>    (XEN) [2014-11-18 14:53:37.364] RIP:    e008:[<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
>>    which resolves to:
>>    # addr2line -e xen-syms ffff82d08014a4de
>>    /usr/src/new/xen-unstable-vanilla/xen/include/xen/list.h:67
>>    which is:
>>    static inline void __list_add(struct list_head *new,
>>                               struct list_head *prev,
>>                               struct list_head *next)
>>     {
>>     next->prev = new;
>>     new->next = next;
>>     new->prev = prev;
>> Here ->    prev->next = new;
>>     }

> Looking at the stack:


> (XEN) [2014-11-18 14:53:37.306]  0: ffff8303faaf25a8 [p:ffff83054ef2e3e0, n:ffff83054ef2e3e0]

> We detected that the list was poison and were printing it, while an:

>  ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>  CPU:    4
>  RIP:    e008:[<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
>  RFLAGS: 0000000000010082   CONTEXT: hypervisor
>  rax: ffff83054ef2e3e0   rbx: ffff8303faaf25a8   rcx: ffff8303faaf2610
>  rdx: 0200200200200200   rsi: 0000000000000006   rdi: 000000006ef3f123
>  rbp: ffff83054ef27be8   rsp: ffff83054ef27bd8   r8:  ffff8303faaf2010
>  r9:  000000000000002f   r10: 0000000000000132   r11: 0000000000000003
>  r12: ffff8305125d6000   r13: 0000000000000000   r14: ffff8303faaf2580
>  r15: 000000000000002f   cr0: 000000008005003b   cr4: 00000000000006f0
>  cr3: 00000005448c0000   cr2: ffffffffff600400
>  ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
>  Xen stack trace from rsp=ffff83054ef27bd8:
>     ffff83054ef27be8 ffff8303faaf26c0 ffff83054ef27c78 ffff82d080172060
>     0000000000000020 ffff83054ef27cf6 0000000000000046 ffff83054ef27c70
>     ffff82d000000000 ffff83055d002f24 0000000000000000 0000002f4ef27c40
>     ffff83054ef27c48 ffff82d08014434f ffff83054ef27c60 0000000000000000
>     ffff82d08025efdc 0000000000000200 ffff83054ef27d78 0000000000000003
>     00007cfab10d8357 ffff82d080233122 0000000000000003 ffff83054ef27d78
>     0000000000000200 ffff82d08025efdc ffff83054ef27d60 0000000000000000
>     0000000000000003 0000000000000132 0000000000000003 ffff83054ef80000
>     0000000000000000 0000000000000000 ffff83054ef20000 000000000000000a
>     ffff82d0802966c0 000000d100000000 ffff82d0801439ba 000000000000e008
>     0000000000000206 ffff83054ef27d30 000000000000e010 ffff83054ef27d60
>     ffff82d08030961e ffff83054ef2e378 ffff83054ef27e10 0000000000000000
>     ffff82d08025f37e ffff83054ef27dc0 ffff82d080143eda ffff82d0802967a0
>     0000000000000028 ffff83054ef27dd0 ffff83054ef27d90 ffff83054ef27da0
>     0000000000000000 ffff8303faaf25a8 ffff83054ef2e3e0 ffff83054ef2e3e0
>     000001785db75800 ffff83054ef27eb0 ffff82d0801495c0 ffff82d080233122
>     ffff83054ef2e378 ffff83054ef27e00 ffff83054ef2e4e0 ffff83054ef2e400
>     0000000300000000 ffff8305125d60b8 ffff83054ef27e70 ffff83054ef2e3e0
>     ffff83054ef2e3e0 ffff8303faaf25a8 ffff83054ef2e3e0 ffff83054ef2e3e0
>     ffff83054ef2e378 0100100100100100 0200200200200200 ffff83054ef2e378
>  Xen call trace:
>     [<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
>     [<ffff82d080172060>] do_IRQ+0x49c/0x624

> and interrupt came in. Said interrupt ended up calling 'raise_softirq'
> and added itself on the list. But the list is corrupted and
> it below up.

> Now the oddidity is that the 'prev' in this case is the per-cpu list -
> which should be cleared with 'list_splice_init' which INIT_LIST_HEAD() which
> resets the list!

> First of it should not even enter in the 'raise_softirq' as:
> [I suppose that ffff8303faaf25a8 has already been cleared but the
> second item in the dpci_list is also ffff8303faaf25a8].

>  186     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )                     
>  187         return;                                                                 

> is set..  

>     [<ffff82d080233122>] common_interrupt+0x62/0x70
>     [<ffff82d0801439ba>] vprintk_common+0x131/0x13e
>     [<ffff82d080143eda>] printk+0x46/0x48
>     [<ffff82d0801495c0>] dpci_softirq+0x199/0x3e2
>     [<ffff82d08012be31>] __do_softirq+0x81/0x8c
>     [<ffff82d08012be89>] do_softirq+0x13/0x15
>     [<ffff82d0801633e5>] idle_loop+0x5e/0x6e

> OK, so it looks like a couple of things are not happening on your
> machine:

>  1) test_and_[set|clear]_bit sometimes return unexpected values.
>     [But this might be invalid as the addition of the ffff8303faaf25a8
>      might be correct - as the second dpci the softirq is processing
>      could be the MSI one]

Would there be an easy way to stress test this function separately in some 
debugging function to see if it indeed is returning unexpected values ?

>  2) INIT_LIST_HEAD operations on the same CPU are not honored.

Just curious, have you also tested the patches on AMD hardware ?

 
>> When i look at the combination of (2) and (3), It seems it could be an 
>> interaction between the two passed through devices and/or different IRQ types.

> Could be - as in it is causing this issue to show up faster than
> expected. Or it is the one that triggers more than one dpci happening
> at the same time.

Well that didn't seem to be it (see separate amendment i mailed previously)

>> 
>> So i will now test without #define DIFF_LIST 1 and not passing through the USB controller, see
>> if that still crashes, if it doesn't i will see if i can passthrough a device which also only uses legacy
>> interrupts instead of MSI / MSI-X, see if that crashes or not.

> Right. I believe the issue you are triggering is that two or more
> 'pirq_dpci' are added on the per-cpu list. Having them different
> is fine (so one serving MSI the other IRQ), but having them the same is a no-go.
> Somehow you are triggering the later.


> Is your machine by any chance set to 'Aggressive' memory setting? My ASUS
> box has that setting and while it works great with games, Xen ends up hitting
> some rather strange lockups that I can only blame on that.

Nope memory stuff in the bios is on 'auto', i haven't been in the bios in ages, 
so it hasn't changed recently. Could run a memtestx86 to try to rule bad memory 
out, but i don't have high hopes.

>> 
>> >> Thank you.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:03:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmBf-0000S7-6W; Tue, 18 Nov 2014 17:03:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XqmBd-0000Rt-Go
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 17:03:29 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	34/0D-02559-0EB7B645; Tue, 18 Nov 2014 17:03:28 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416330206!13339508!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18281 invoked from network); 18 Nov 2014 17:03:26 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 18 Nov 2014 17:03:26 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52946 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XqmA5-0004JH-RU; Tue, 18 Nov 2014 18:01:53 +0100
Date: Tue, 18 Nov 2014 18:03:23 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1222042576.20141118180323@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141118161650.GC17095@laptop.dumpdata.com>
References: <1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, November 18, 2014, 5:16:50 PM, you wrote:

>> Without #define DIFF_LIST 1:
>> 1) The guest still crashes (xl-dmesg-not-defined.txt)

> AHA!

>  --MARK--
>   0: ffff8305085ffd28 [p:ffff83054ef27e88, n:ffff83054ef27e88]
>   1: ffff8305085ffd28 [p:0200200200200200, n:0100100100100100]

> The same pirq_dpci structure is put twice on the list. That
> will surely make it unhappy. The reason the #define DIFF_LIST 1
> would work is that it has code to deal with that odd scenario.

> But .. more importantly - the code should not allow you to
> put _two_ of the same 'pirq_dpci' structures on the list.

>  CPU00: 
>  d16 OK-softirq 186msec ago, state:1, 3257 count, [prev:ffff82d0802e7e88, next:ffff82d0802e7e88] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  d16 OK-raise   236msec ago, state:1, 3257 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  CPU01: 
>  d16 OK-softirq 232msec ago, state:1, 2978 count, [prev:ffff83054ef57e70, next:ffff83054ef57e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  d16 OK-raise   281msec ago, state:1, 2978 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  CPU02: 
>  d16 OK-softirq 373msec ago, state:1, 2378 count, [prev:ffff83054ef47e70, next:ffff83054ef47e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  d16 OK-raise   423msec ago, state:1, 2378 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  CPU03: 
>  d16 OK-softirq 867msec ago, state:1, 2744 count, [prev:ffff83054ef37e70, next:ffff83054ef37e70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  d16 OK-raise   916msec ago, state:1, 2744 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  CPU04: 
>  d16 OK-softirq 497msec ago, state:1, 76910 count, [prev:ffff83054ef2e3e0, next:ffff83054ef2e3e0] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>  d16 OK-raise   489msec ago, state:1, 76916 count, [prev:ffff83054ef2e3e0, next:ffff83054ef2e3e0] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>  d16 ERR-poison 600msec ago, state:0, 1 count, [prev:0200200200200200, next:0100100100100100] ffff8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
>  CPU05: 
>  d16 OK-softirq 852msec ago, state:1, 2207 count, [prev:ffff83054ef1fe70, next:ffff83054ef1fe70] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  d16 OK-raise   902msec ago, state:1, 2207 count, [prev:0200200200200200, next:0100100100100100] ffff8305094a39a8<NULL> MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
>  domain_crash called from io.c:964
>  Domain 16 reported crashed by domain 7 on cpu#4:


>> 
>> With #define DIFF_LIST 1:
>> 2) Nor the guest or the host crashed (let it run for about an hour and 15 minutes), 
>>    but the USB XHCI driver bailed out quickly after guest boot, so there were no MSI-X interrupts anymore.
>>    (xl-dmesg-defined-nousb.txt, dmesg-guest-defined-nousb.txt)

> Hm, that is odd. Can you tell me how you get your SeaBIOS to add those
> extra statements? I don't seem to see them with my SeaBIOS (I've an XHCI
> controlled hooked up to the guest too). Maybe I am missing an CONFIG in the
> SeaBIOS build.

Uhmm i thought i had these switched off (due to problems earlier and then forgot 
about them .. however looking at the earlier reports these lines were also in 
those reports).

The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
branch), so the qemu-xen and seabios defined with that were also freshly cloned 
and had a new default seabios config. (just to rule out anything stale in my tree)

If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
seabios config) are not the most recent (they don't get updated automatically 
when you just do a git pull on the main tree) ?

In /tools/firmware/seabios-dir/.config i have:
CONFIG_USB=y
CONFIG_USB_UHCI=y
CONFIG_USB_OHCI=y
CONFIG_USB_EHCI=y
CONFIG_USB_XHCI=y
CONFIG_USB_MSC=y
CONFIG_USB_UAS=y
CONFIG_USB_HUB=y
CONFIG_USB_KEYBOARD=y
CONFIG_USB_MOUSE=y

And this is all just from a:
- git clone git://xenbits.xen.org/xen.git -b staging
- make clean && ./configure && make -j6 && make -j6 install

>> 3) On another boot the USB XHCI didn't bail out, after a while the host crashes. (serial.log)
>>    (XEN) [2014-11-18 14:53:37.364] RIP:    e008:[<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
>>    which resolves to:
>>    # addr2line -e xen-syms ffff82d08014a4de
>>    /usr/src/new/xen-unstable-vanilla/xen/include/xen/list.h:67
>>    which is:
>>    static inline void __list_add(struct list_head *new,
>>                               struct list_head *prev,
>>                               struct list_head *next)
>>     {
>>     next->prev = new;
>>     new->next = next;
>>     new->prev = prev;
>> Here ->    prev->next = new;
>>     }

> Looking at the stack:


> (XEN) [2014-11-18 14:53:37.306]  0: ffff8303faaf25a8 [p:ffff83054ef2e3e0, n:ffff83054ef2e3e0]

> We detected that the list was poison and were printing it, while an:

>  ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>  CPU:    4
>  RIP:    e008:[<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
>  RFLAGS: 0000000000010082   CONTEXT: hypervisor
>  rax: ffff83054ef2e3e0   rbx: ffff8303faaf25a8   rcx: ffff8303faaf2610
>  rdx: 0200200200200200   rsi: 0000000000000006   rdi: 000000006ef3f123
>  rbp: ffff83054ef27be8   rsp: ffff83054ef27bd8   r8:  ffff8303faaf2010
>  r9:  000000000000002f   r10: 0000000000000132   r11: 0000000000000003
>  r12: ffff8305125d6000   r13: 0000000000000000   r14: ffff8303faaf2580
>  r15: 000000000000002f   cr0: 000000008005003b   cr4: 00000000000006f0
>  cr3: 00000005448c0000   cr2: ffffffffff600400
>  ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
>  Xen stack trace from rsp=ffff83054ef27bd8:
>     ffff83054ef27be8 ffff8303faaf26c0 ffff83054ef27c78 ffff82d080172060
>     0000000000000020 ffff83054ef27cf6 0000000000000046 ffff83054ef27c70
>     ffff82d000000000 ffff83055d002f24 0000000000000000 0000002f4ef27c40
>     ffff83054ef27c48 ffff82d08014434f ffff83054ef27c60 0000000000000000
>     ffff82d08025efdc 0000000000000200 ffff83054ef27d78 0000000000000003
>     00007cfab10d8357 ffff82d080233122 0000000000000003 ffff83054ef27d78
>     0000000000000200 ffff82d08025efdc ffff83054ef27d60 0000000000000000
>     0000000000000003 0000000000000132 0000000000000003 ffff83054ef80000
>     0000000000000000 0000000000000000 ffff83054ef20000 000000000000000a
>     ffff82d0802966c0 000000d100000000 ffff82d0801439ba 000000000000e008
>     0000000000000206 ffff83054ef27d30 000000000000e010 ffff83054ef27d60
>     ffff82d08030961e ffff83054ef2e378 ffff83054ef27e10 0000000000000000
>     ffff82d08025f37e ffff83054ef27dc0 ffff82d080143eda ffff82d0802967a0
>     0000000000000028 ffff83054ef27dd0 ffff83054ef27d90 ffff83054ef27da0
>     0000000000000000 ffff8303faaf25a8 ffff83054ef2e3e0 ffff83054ef2e3e0
>     000001785db75800 ffff83054ef27eb0 ffff82d0801495c0 ffff82d080233122
>     ffff83054ef2e378 ffff83054ef27e00 ffff83054ef2e4e0 ffff83054ef2e400
>     0000000300000000 ffff8305125d60b8 ffff83054ef27e70 ffff83054ef2e3e0
>     ffff83054ef2e3e0 ffff8303faaf25a8 ffff83054ef2e3e0 ffff83054ef2e3e0
>     ffff83054ef2e378 0100100100100100 0200200200200200 ffff83054ef2e378
>  Xen call trace:
>     [<ffff82d08014a4de>] hvm_do_IRQ_dpci+0xf4/0x131
>     [<ffff82d080172060>] do_IRQ+0x49c/0x624

> and interrupt came in. Said interrupt ended up calling 'raise_softirq'
> and added itself on the list. But the list is corrupted and
> it below up.

> Now the oddidity is that the 'prev' in this case is the per-cpu list -
> which should be cleared with 'list_splice_init' which INIT_LIST_HEAD() which
> resets the list!

> First of it should not even enter in the 'raise_softirq' as:
> [I suppose that ffff8303faaf25a8 has already been cleared but the
> second item in the dpci_list is also ffff8303faaf25a8].

>  186     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )                     
>  187         return;                                                                 

> is set..  

>     [<ffff82d080233122>] common_interrupt+0x62/0x70
>     [<ffff82d0801439ba>] vprintk_common+0x131/0x13e
>     [<ffff82d080143eda>] printk+0x46/0x48
>     [<ffff82d0801495c0>] dpci_softirq+0x199/0x3e2
>     [<ffff82d08012be31>] __do_softirq+0x81/0x8c
>     [<ffff82d08012be89>] do_softirq+0x13/0x15
>     [<ffff82d0801633e5>] idle_loop+0x5e/0x6e

> OK, so it looks like a couple of things are not happening on your
> machine:

>  1) test_and_[set|clear]_bit sometimes return unexpected values.
>     [But this might be invalid as the addition of the ffff8303faaf25a8
>      might be correct - as the second dpci the softirq is processing
>      could be the MSI one]

Would there be an easy way to stress test this function separately in some 
debugging function to see if it indeed is returning unexpected values ?

>  2) INIT_LIST_HEAD operations on the same CPU are not honored.

Just curious, have you also tested the patches on AMD hardware ?

 
>> When i look at the combination of (2) and (3), It seems it could be an 
>> interaction between the two passed through devices and/or different IRQ types.

> Could be - as in it is causing this issue to show up faster than
> expected. Or it is the one that triggers more than one dpci happening
> at the same time.

Well that didn't seem to be it (see separate amendment i mailed previously)

>> 
>> So i will now test without #define DIFF_LIST 1 and not passing through the USB controller, see
>> if that still crashes, if it doesn't i will see if i can passthrough a device which also only uses legacy
>> interrupts instead of MSI / MSI-X, see if that crashes or not.

> Right. I believe the issue you are triggering is that two or more
> 'pirq_dpci' are added on the per-cpu list. Having them different
> is fine (so one serving MSI the other IRQ), but having them the same is a no-go.
> Somehow you are triggering the later.


> Is your machine by any chance set to 'Aggressive' memory setting? My ASUS
> box has that setting and while it works great with games, Xen ends up hitting
> some rather strange lockups that I can only blame on that.

Nope memory stuff in the bios is on 'auto', i haven't been in the bios in ages, 
so it hasn't changed recently. Could run a memtestx86 to try to rule bad memory 
out, but i don't have high hopes.

>> 
>> >> Thank you.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:04:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17: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 1XqmCm-0000b0-S7; Tue, 18 Nov 2014 17:04:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqmCl-0000ar-RY
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:04:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C8/06-25276-72C7B645; Tue, 18 Nov 2014 17:04:39 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416330278!13675680!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11450 invoked from network); 18 Nov 2014 17:04:38 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:04:38 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so9020922wgg.14
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 09:04:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=K9oeha72oaScO2ogBo6Fq1O+TcLkZH7tj/zpRG/fA2Q=;
	b=gNPYQn2fYLOV3GUylVbC70m/pxfYaj6wUrHloqJme8q44EszLBcMWuu5ungmTO7J3y
	4ckYqQwG1zXgXTrrTUZRLyqiV9NGLSWM0KsGSSONgkHtdW3jgLdRQ6XhPYzfvwmaLFsL
	T3fpf2atrT7G6NZ8CPWQGwagLYL5WJqexK76lj7Hop2vmnp2a2TG2/e4bK6mqIW5/OHs
	5iwE19PdmdX3u6fjXl9mPbCpQ5YFPfNjLu0qHj2UJunxUclECwX6188g7DLn7DnU6kQO
	eRh13x8MZo7M35YuKYrE+mL1jEfuZFvjBy0XDNZ1Y7lKvfVMEMKztR3b4RKeLM9TDqgE
	R+QA==
X-Gm-Message-State: ALoCoQkgUaHvAH5E0Pl0m401TDY9MXme7bpwQV6XF4SubzfWBP4VooknLPpii1Euv42zCoWDCmaS
X-Received: by 10.194.174.40 with SMTP id bp8mr48529383wjc.104.1416330267017; 
	Tue, 18 Nov 2014 09:04:27 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id n4sm20251614wiz.17.2014.11.18.09.04.25
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 09:04:26 -0800 (PST)
Message-ID: <546B7C18.7000102@linaro.org>
Date: Tue, 18 Nov 2014 17:04:24 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-3-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416329088-23328-3-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 3/4] xen: arm: correct specific
 mappings for PCIE0 on X-Gene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/18/2014 04:44 PM, Ian Campbell wrote:
> The region assigned to PCIE0, according to the docs, is 0x0e000000000 to
> 0x10000000000. They make no distinction between PCI CFG and PCI IO mem within
> this range (in fact, I'm not sure that isn't up to the driver).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:04:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17: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 1XqmCm-0000b0-S7; Tue, 18 Nov 2014 17:04:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqmCl-0000ar-RY
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:04:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C8/06-25276-72C7B645; Tue, 18 Nov 2014 17:04:39 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416330278!13675680!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11450 invoked from network); 18 Nov 2014 17:04:38 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:04:38 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so9020922wgg.14
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 09:04:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=K9oeha72oaScO2ogBo6Fq1O+TcLkZH7tj/zpRG/fA2Q=;
	b=gNPYQn2fYLOV3GUylVbC70m/pxfYaj6wUrHloqJme8q44EszLBcMWuu5ungmTO7J3y
	4ckYqQwG1zXgXTrrTUZRLyqiV9NGLSWM0KsGSSONgkHtdW3jgLdRQ6XhPYzfvwmaLFsL
	T3fpf2atrT7G6NZ8CPWQGwagLYL5WJqexK76lj7Hop2vmnp2a2TG2/e4bK6mqIW5/OHs
	5iwE19PdmdX3u6fjXl9mPbCpQ5YFPfNjLu0qHj2UJunxUclECwX6188g7DLn7DnU6kQO
	eRh13x8MZo7M35YuKYrE+mL1jEfuZFvjBy0XDNZ1Y7lKvfVMEMKztR3b4RKeLM9TDqgE
	R+QA==
X-Gm-Message-State: ALoCoQkgUaHvAH5E0Pl0m401TDY9MXme7bpwQV6XF4SubzfWBP4VooknLPpii1Euv42zCoWDCmaS
X-Received: by 10.194.174.40 with SMTP id bp8mr48529383wjc.104.1416330267017; 
	Tue, 18 Nov 2014 09:04:27 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id n4sm20251614wiz.17.2014.11.18.09.04.25
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 09:04:26 -0800 (PST)
Message-ID: <546B7C18.7000102@linaro.org>
Date: Tue, 18 Nov 2014 17:04:24 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-3-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416329088-23328-3-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 3/4] xen: arm: correct specific
 mappings for PCIE0 on X-Gene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/18/2014 04:44 PM, Ian Campbell wrote:
> The region assigned to PCIE0, according to the docs, is 0x0e000000000 to
> 0x10000000000. They make no distinction between PCI CFG and PCI IO mem within
> this range (in fact, I'm not sure that isn't up to the driver).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:07:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmFr-0000vM-I0; Tue, 18 Nov 2014 17:07:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1XqmFq-0000vA-7a
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:07:50 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	C6/DE-02954-5EC7B645; Tue, 18 Nov 2014 17:07:49 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416330468!13360443!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28852 invoked from network); 18 Nov 2014 17:07:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:07:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="26944831"
From: Euan Harris <euan.harris@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 17:07:41 +0000
Message-ID: <1416330461-11985-1-git-send-email-euan.harris@citrix.com>
X-Mailer: git-send-email 1.9.3
MIME-Version: 1.0
X-DLP: AMS1
Cc: Euan Harris <euan.harris@citrix.com>, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: Document device parameter of
	libxl_device_<type>_add 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

The device parameter of libxl_device_<type>_add is an in/out parameter.
Unspecified fields are filled in with appropriate values for the created
device when the function returns.  Document this behaviour.

Signed-off-by: Euan Harris <euan.harris@citrix.com>
---
 tools/libxl/libxl.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c3451bd..41d6e8d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1109,6 +1109,10 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms);
  *   domain to connect to the device and therefore cannot block on the
  *   guest.
  *
+ *   device is an in/out parameter:  fields left unspecified when the
+ *   structure is passed in are filled in with appropriate values for
+ *   the device created.
+ *
  * libxl_device_<type>_remove(ctx, domid, device):
  *
  *   Removes the given device from the specified domain by performing
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:07:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmFr-0000vM-I0; Tue, 18 Nov 2014 17:07:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1XqmFq-0000vA-7a
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:07:50 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	C6/DE-02954-5EC7B645; Tue, 18 Nov 2014 17:07:49 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416330468!13360443!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28852 invoked from network); 18 Nov 2014 17:07:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:07:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="26944831"
From: Euan Harris <euan.harris@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 18 Nov 2014 17:07:41 +0000
Message-ID: <1416330461-11985-1-git-send-email-euan.harris@citrix.com>
X-Mailer: git-send-email 1.9.3
MIME-Version: 1.0
X-DLP: AMS1
Cc: Euan Harris <euan.harris@citrix.com>, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: Document device parameter of
	libxl_device_<type>_add 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

The device parameter of libxl_device_<type>_add is an in/out parameter.
Unspecified fields are filled in with appropriate values for the created
device when the function returns.  Document this behaviour.

Signed-off-by: Euan Harris <euan.harris@citrix.com>
---
 tools/libxl/libxl.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c3451bd..41d6e8d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1109,6 +1109,10 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms);
  *   domain to connect to the device and therefore cannot block on the
  *   guest.
  *
+ *   device is an in/out parameter:  fields left unspecified when the
+ *   structure is passed in are filled in with appropriate values for
+ *   the device created.
+ *
  * libxl_device_<type>_remove(ctx, domid, device):
  *
  *   Removes the given device from the specified domain by performing
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:09:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:09:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmGx-00011I-1c; Tue, 18 Nov 2014 17:08:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1XqmGw-00011C-Lh
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:08:58 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	CF/09-02699-92D7B645; Tue, 18 Nov 2014 17:08:57 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416330537!13340657!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25835 invoked from network); 18 Nov 2014 17:08:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:08:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="26944855"
Date: Tue, 18 Nov 2014 17:08:54 +0000
From: Euan Harris <euan.harris@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141118170854.GF31225@citrix.com>
References: <20141118152848.GE31225@citrix.com>
	<1416324924.17982.21.camel@citrix.com>
	<21611.26775.594669.510363@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21611.26775.594669.510363@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
X-DLP: AMS1
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add
 an (in)_out parameter?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > I believe so, yes. The comment under "Devices" in libxl.h probably ought
> > to be adjusted to say so explicitly.
> > 
> > Ian (J) -- do you agree?
> 
> I do.  I think this applies to other kinds of device too, which might
> have unspecified parameters which get filled in.
> 
> Euan, would you like to send us a doc patch for libxl.h ?

I have sent a patch for the Devices comment.   If I come across more
functions which behave similarly I'll send more patches.

Thanks,
Euan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:09:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:09:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmGx-00011I-1c; Tue, 18 Nov 2014 17:08:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1XqmGw-00011C-Lh
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:08:58 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	CF/09-02699-92D7B645; Tue, 18 Nov 2014 17:08:57 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416330537!13340657!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25835 invoked from network); 18 Nov 2014 17:08:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:08:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,410,1413244800"; d="scan'208";a="26944855"
Date: Tue, 18 Nov 2014 17:08:54 +0000
From: Euan Harris <euan.harris@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141118170854.GF31225@citrix.com>
References: <20141118152848.GE31225@citrix.com>
	<1416324924.17982.21.camel@citrix.com>
	<21611.26775.594669.510363@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21611.26775.594669.510363@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
X-DLP: AMS1
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add
 an (in)_out parameter?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > I believe so, yes. The comment under "Devices" in libxl.h probably ought
> > to be adjusted to say so explicitly.
> > 
> > Ian (J) -- do you agree?
> 
> I do.  I think this applies to other kinds of device too, which might
> have unspecified parameters which get filled in.
> 
> Euan, would you like to send us a doc patch for libxl.h ?

I have sent a patch for the Devices comment.   If I come across more
functions which behave similarly I'll send more patches.

Thanks,
Euan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:15:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:15:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmN2-0001I4-3D; Tue, 18 Nov 2014 17:15:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqmN0-0001Hz-Ui
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:15:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D8/DD-09842-2AE7B645; Tue, 18 Nov 2014 17:15:14 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416330913!13640687!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16611 invoked from network); 18 Nov 2014 17:15:13 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:15:13 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so1855278wgh.3
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 09:15:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=kVzlS4LSM8Gm8CKbUn1Jy2AYwgpkhebJ3Invmrc2VK8=;
	b=HsVYV12CHP3StnHDc42Z17lcJAwFdxSnbtS8DrBfiqo8Tl+xOSjSeDn9i/pv2mqvA3
	9k1YWPwu7EBkN3FJi55murhyKyraNDT8QpDHeVUq9P91Dxyy0Z5U47qyxI48AS9KCouL
	jQ3n5FWmG+XxDEiUOp3HohDyPEdUKFsqrz4069O5Jg5i+vykO4Zyoe07kDAzReWfIfE9
	u8R9Kivg3+vsflCCswglyCVq/FyJu82kh2ti0/6LdlrPKkZXuaTXIFxhAZ0nkB2NCnwx
	a65PWOdhfiD0xWlikg0MkWFgwwxVL2rHclxxAFCGmY2MWFxf7lTaulBQBXIJrbEzW3sq
	auWQ==
X-Gm-Message-State: ALoCoQnR1qh3KlBc189RtrmeidtlaXFFQu+s0NMDO7bf6wTe9/NxLD5Hqw4oQ7rYH/7MvsedrGHk
X-Received: by 10.180.91.137 with SMTP id ce9mr5785174wib.60.1416330913241;
	Tue, 18 Nov 2014 09:15:13 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id b6sm20287565wiy.22.2014.11.18.09.15.11
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 09:15:12 -0800 (PST)
Message-ID: <546B7E9E.9040806@linaro.org>
Date: Tue, 18 Nov 2014 17:15:10 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-4-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416329088-23328-4-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4
 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/18/2014 04:44 PM, Ian Campbell wrote:
> Currently we only establish specific mappings for pcie0, which is
> used on the Mustang platform. However at least McDivitt uses pcie3.
> So wire up all the others, based on whether the corresponding DT node
> is marked as available.
> 
> This results in no change for Mustang.

Hopefully, we will support PCI DT parsing in Xen 4.6!

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> +/*
> + * Xen does not currently support mapping MMIO regions and interrupt
> + * for bus child devices (referenced via the "ranges" and
> + * "interrupt-map" properties to domain 0). Instead for now map the
> + * necessary resources manually.
> + */
> +static int xgene_storm_specific_mapping(struct domain *d)
> +{
> +    struct dt_device_node *node = NULL;

NIT: const struct

> +    int ret;
> +
> +    while ( (node = dt_find_compatible_node(node, "pci", "apm,xgene-pcie")) )
> +    {
> +        u64 addr;
> +
> +        /* Identify the bus via it's control register address */
> +        ret = dt_device_get_address(node, 0, &addr, NULL);
> +        if ( ret < 0 )
> +            return ret;
> +
> +        if ( !dt_device_is_available(node) )
> +            continue;
> +
> +       switch ( addr )
> +        {
> +        case 0x1f2b0000: /* PCIe0 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                0x0e000000000UL, 0x10000000000UL, 0xc2);
> +            break;
> +        case 0x1f2c0000: /* PCIe1 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                0x0d000000000UL, 0x0e000000000UL, 0xc8);
> +            break;
> +        case 0x1f2d0000: /* PCIe2 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                0x09000000000UL, 0x0a000000000UL, 0xce);
> +            break;
> +        case 0x1f500000: /* PCIe3 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                0x0a000000000UL, 0x0c000000000UL, 0xd4);
> +            break;
> +        case 0x1f510000: /* PCIe4 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                0x0c000000000UL, 0x0d000000000UL, 0xda);
> +            break;
> +
> +        default:
> +            /* Ignore unknown PCI busses */

I would add a
printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));

> +            ret = 0;
> +            break;

continue? You can't assume the order of the PCI busses in the device tree.

> +        }
> +
> +        if ( ret < 0 )
> +            return ret;
> +
> +        printk("Mapped additional regions for PCIe device at 0x%"PRIx64"\n",
> +               addr);

Printing the device tree path would be more helpful than the address.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:15:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:15:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmN2-0001I4-3D; Tue, 18 Nov 2014 17:15:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqmN0-0001Hz-Ui
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:15:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D8/DD-09842-2AE7B645; Tue, 18 Nov 2014 17:15:14 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416330913!13640687!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16611 invoked from network); 18 Nov 2014 17:15:13 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:15:13 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so1855278wgh.3
	for <xen-devel@lists.xen.org>; Tue, 18 Nov 2014 09:15:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=kVzlS4LSM8Gm8CKbUn1Jy2AYwgpkhebJ3Invmrc2VK8=;
	b=HsVYV12CHP3StnHDc42Z17lcJAwFdxSnbtS8DrBfiqo8Tl+xOSjSeDn9i/pv2mqvA3
	9k1YWPwu7EBkN3FJi55murhyKyraNDT8QpDHeVUq9P91Dxyy0Z5U47qyxI48AS9KCouL
	jQ3n5FWmG+XxDEiUOp3HohDyPEdUKFsqrz4069O5Jg5i+vykO4Zyoe07kDAzReWfIfE9
	u8R9Kivg3+vsflCCswglyCVq/FyJu82kh2ti0/6LdlrPKkZXuaTXIFxhAZ0nkB2NCnwx
	a65PWOdhfiD0xWlikg0MkWFgwwxVL2rHclxxAFCGmY2MWFxf7lTaulBQBXIJrbEzW3sq
	auWQ==
X-Gm-Message-State: ALoCoQnR1qh3KlBc189RtrmeidtlaXFFQu+s0NMDO7bf6wTe9/NxLD5Hqw4oQ7rYH/7MvsedrGHk
X-Received: by 10.180.91.137 with SMTP id ce9mr5785174wib.60.1416330913241;
	Tue, 18 Nov 2014 09:15:13 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id b6sm20287565wiy.22.2014.11.18.09.15.11
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 09:15:12 -0800 (PST)
Message-ID: <546B7E9E.9040806@linaro.org>
Date: Tue, 18 Nov 2014 17:15:10 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-4-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416329088-23328-4-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4
 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/18/2014 04:44 PM, Ian Campbell wrote:
> Currently we only establish specific mappings for pcie0, which is
> used on the Mustang platform. However at least McDivitt uses pcie3.
> So wire up all the others, based on whether the corresponding DT node
> is marked as available.
> 
> This results in no change for Mustang.

Hopefully, we will support PCI DT parsing in Xen 4.6!

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> +/*
> + * Xen does not currently support mapping MMIO regions and interrupt
> + * for bus child devices (referenced via the "ranges" and
> + * "interrupt-map" properties to domain 0). Instead for now map the
> + * necessary resources manually.
> + */
> +static int xgene_storm_specific_mapping(struct domain *d)
> +{
> +    struct dt_device_node *node = NULL;

NIT: const struct

> +    int ret;
> +
> +    while ( (node = dt_find_compatible_node(node, "pci", "apm,xgene-pcie")) )
> +    {
> +        u64 addr;
> +
> +        /* Identify the bus via it's control register address */
> +        ret = dt_device_get_address(node, 0, &addr, NULL);
> +        if ( ret < 0 )
> +            return ret;
> +
> +        if ( !dt_device_is_available(node) )
> +            continue;
> +
> +       switch ( addr )
> +        {
> +        case 0x1f2b0000: /* PCIe0 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                0x0e000000000UL, 0x10000000000UL, 0xc2);
> +            break;
> +        case 0x1f2c0000: /* PCIe1 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                0x0d000000000UL, 0x0e000000000UL, 0xc8);
> +            break;
> +        case 0x1f2d0000: /* PCIe2 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                0x09000000000UL, 0x0a000000000UL, 0xce);
> +            break;
> +        case 0x1f500000: /* PCIe3 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                0x0a000000000UL, 0x0c000000000UL, 0xd4);
> +            break;
> +        case 0x1f510000: /* PCIe4 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                0x0c000000000UL, 0x0d000000000UL, 0xda);
> +            break;
> +
> +        default:
> +            /* Ignore unknown PCI busses */

I would add a
printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));

> +            ret = 0;
> +            break;

continue? You can't assume the order of the PCI busses in the device tree.

> +        }
> +
> +        if ( ret < 0 )
> +            return ret;
> +
> +        printk("Mapped additional regions for PCIe device at 0x%"PRIx64"\n",
> +               addr);

Printing the device tree path would be more helpful than the address.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:21:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmSS-0001R6-3Y; Tue, 18 Nov 2014 17:20:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqmSP-0001R0-Sy
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 17:20:50 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	99/A9-17735-1FF7B645; Tue, 18 Nov 2014 17:20:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416331247!12190245!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28075 invoked from network); 18 Nov 2014 17:20:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 17:20:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 17:20:46 +0000
Message-Id: <546B8DFC0200007800048E21@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 17:20:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
In-Reply-To: <1222042576.20141118180323@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 18:03, <linux@eikelenboom.it> wrote:
> Tuesday, November 18, 2014, 5:16:50 PM, you wrote:
>>  1) test_and_[set|clear]_bit sometimes return unexpected values.
>>     [But this might be invalid as the addition of the ffff8303faaf25a8
>>      might be correct - as the second dpci the softirq is processing
>>      could be the MSI one]
> 
> Would there be an easy way to stress test this function separately in some 
> debugging function to see if it indeed is returning unexpected values ?

I don't think there's a reasonable chance of these functions to return
"unexpected" values - they're being used elsewhere, and you'd have
had other problems in the past if they didn't behave as expected.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:21:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmSS-0001R6-3Y; Tue, 18 Nov 2014 17:20:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XqmSP-0001R0-Sy
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 17:20:50 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	99/A9-17735-1FF7B645; Tue, 18 Nov 2014 17:20:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416331247!12190245!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28075 invoked from network); 18 Nov 2014 17:20:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 17:20:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 17:20:46 +0000
Message-Id: <546B8DFC0200007800048E21@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 17:20:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1393541150.20141114175923@eikelenboom.it>
	<20141114202513.GA3281@laptop.dumpdata.com>
	<1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
In-Reply-To: <1222042576.20141118180323@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 18:03, <linux@eikelenboom.it> wrote:
> Tuesday, November 18, 2014, 5:16:50 PM, you wrote:
>>  1) test_and_[set|clear]_bit sometimes return unexpected values.
>>     [But this might be invalid as the addition of the ffff8303faaf25a8
>>      might be correct - as the second dpci the softirq is processing
>>      could be the MSI one]
> 
> Would there be an easy way to stress test this function separately in some 
> debugging function to see if it indeed is returning unexpected values ?

I don't think there's a reasonable chance of these functions to return
"unexpected" values - they're being used elsewhere, and you'd have
had other problems in the past if they didn't behave as expected.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:44:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmpH-0001tu-3L; Tue, 18 Nov 2014 17:44: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@citrix.com>) id 1XqmpG-0001tp-02
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:44:26 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B6/4C-22737-8758B645; Tue, 18 Nov 2014 17:44:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416332662!12052176!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9818 invoked from network); 18 Nov 2014 17:44:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:44:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,411,1413244800"; d="scan'208";a="192577521"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 12:44:21 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqmpB-0000vH-Dm;
	Tue, 18 Nov 2014 17:44:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqmpB-0005Jf-0a;
	Tue, 18 Nov 2014 17:44:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.34164.318838.773459@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 17:44:20 +0000
To: Euan Harris <euan.harris@citrix.com>, Konrad Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1416330461-11985-1-git-send-email-euan.harris@citrix.com>
References: <1416330461-11985-1-git-send-email-euan.harris@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Document device parameter of
	libxl_device_<type>_add 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

Euan Harris writes ("[PATCH] libxl: Document device parameter of libxl_device_<type>_add functions"):
> The device parameter of libxl_device_<type>_add is an in/out parameter.
> Unspecified fields are filled in with appropriate values for the created
> device when the function returns.  Document this behaviour.

Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Konrad, this should go into 4.5 IMO because it's a doc comment
describing existing behaviour which we want everyone to rely on.

Ian.

> Signed-off-by: Euan Harris <euan.harris@citrix.com>
> ---
>  tools/libxl/libxl.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index c3451bd..41d6e8d 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1109,6 +1109,10 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms);
>   *   domain to connect to the device and therefore cannot block on the
>   *   guest.
>   *
> + *   device is an in/out parameter:  fields left unspecified when the
> + *   structure is passed in are filled in with appropriate values for
> + *   the device created.
> + *
>   * libxl_device_<type>_remove(ctx, domid, device):
>   *
>   *   Removes the given device from the specified domain by performing
> -- 
> 1.9.3
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:44:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqmpH-0001tu-3L; Tue, 18 Nov 2014 17:44: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@citrix.com>) id 1XqmpG-0001tp-02
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:44:26 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B6/4C-22737-8758B645; Tue, 18 Nov 2014 17:44:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416332662!12052176!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9818 invoked from network); 18 Nov 2014 17:44:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:44:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,411,1413244800"; d="scan'208";a="192577521"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 12:44:21 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqmpB-0000vH-Dm;
	Tue, 18 Nov 2014 17:44:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqmpB-0005Jf-0a;
	Tue, 18 Nov 2014 17:44:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.34164.318838.773459@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 17:44:20 +0000
To: Euan Harris <euan.harris@citrix.com>, Konrad Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1416330461-11985-1-git-send-email-euan.harris@citrix.com>
References: <1416330461-11985-1-git-send-email-euan.harris@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Document device parameter of
	libxl_device_<type>_add 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

Euan Harris writes ("[PATCH] libxl: Document device parameter of libxl_device_<type>_add functions"):
> The device parameter of libxl_device_<type>_add is an in/out parameter.
> Unspecified fields are filled in with appropriate values for the created
> device when the function returns.  Document this behaviour.

Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Konrad, this should go into 4.5 IMO because it's a doc comment
describing existing behaviour which we want everyone to rely on.

Ian.

> Signed-off-by: Euan Harris <euan.harris@citrix.com>
> ---
>  tools/libxl/libxl.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index c3451bd..41d6e8d 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1109,6 +1109,10 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms);
>   *   domain to connect to the device and therefore cannot block on the
>   *   guest.
>   *
> + *   device is an in/out parameter:  fields left unspecified when the
> + *   structure is passed in are filled in with appropriate values for
> + *   the device created.
> + *
>   * libxl_device_<type>_remove(ctx, domid, device):
>   *
>   *   Removes the given device from the specified domain by performing
> -- 
> 1.9.3
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:52:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:52:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqmwg-00023J-8C; Tue, 18 Nov 2014 17:52: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@citrix.com>) id 1Xqmwf-00023E-J7
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:52:05 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	27/B7-24124-4478B645; Tue, 18 Nov 2014 17:52:04 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416333122!12091334!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5679 invoked from network); 18 Nov 2014 17:52:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:52:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,411,1413244800"; d="scan'208";a="192580033"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 12:51:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqmwX-00013f-Cy;
	Tue, 18 Nov 2014 17:51:57 +0000
Date: Tue, 18 Nov 2014 17:51:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Andrii,
we are getting closer :-)

It would help if you post the output with GIC_DEBUG defined but without
the other change that "fixes" the issue.

I think the problem is probably due to software irqs.
You are getting too many

gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending

messages. That means you are loosing virtual SGIs (guest VCPU to guest
VCPU). It would be best to investigate why, especially if you get many
more of the same messages without the MAINTENANCE_IRQ change I
suggested.

This patch might also help understading the problem more:


diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b7516c0..5eaeca2 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
     list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
     {
         i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
-        if ( i >= nr_lrs ) return;
+        if ( i >= nr_lrs )
+        {
+            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
+                    p->irq, v->domain->domain_id, v->vcpu_id);
+            continue;
+        }
 
         spin_lock_irqsave(&gic.lock, flags);
         gic_set_lr(i, p, GICH_LR_PENDING);




On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> No hangs with this change.
> Complete log is the following:
> 
> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> DRA752 ES1.0
> <ethaddr> not set. Validating first E-fuse MAC
> cpsw
> - UART enabled -
> - CPU 00000000 booting -
> - Xen starting in Hyp mode -
> - Zero BSS -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Checking for initrd in /chosen
> (XEN) RAM: 0000000080000000 - 000000009fffffff
> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> (XEN)
> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> (XEN)
> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> (XEN) Dom heap: 344064 pages
> (XEN) Domain heap initialised
> (XEN) Looking for UART console serial0
>  Xen 4.5-unstable
> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> (arm-linux-gnueabihf-gcc (crosstool-NG
> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> 20130328 (prerelease)) debu4
> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> (XEN) 32-bit Execution:
> (XEN)   Processor Features: 00001131:00011011
> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> (XEN)     Extensions: GenericTimer Security
> (XEN)   Debug Features: 02010555
> (XEN)   Auxiliary Features: 00000000
> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> (XEN) Platform: TI DRA7
> (XEN) /psci method must be smc, but is: "hvc"
> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> (XEN) Set AuxCoreBoot0 to 0x20
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> (XEN) Using generic timer at 6144 KHz
> (XEN) GIC initialization:
> (XEN)         gic_dist_addr=0000000048211000
> (XEN)         gic_cpu_addr=0000000048212000
> (XEN)         gic_hyp_addr=0000000048214000
> (XEN)         gic_vcpu_addr=0000000048216000
> (XEN)         gic_maintenance_irq=25
> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) I/O virtualisation disabled
> (XEN) Allocated console ring of 16 KiB.
> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> (XEN) Bringing up CPU1
> - CPU 00000001 booting -
> - Xen starting in Hyp mode -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 1 booted.
> (XEN) Brought up 2 CPUs
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading kernel from boot module 2
> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> input to Xen)
> (XEN) Freed 272kB init memory.
> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> already pending in LR0
> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> already pending in LR0
> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> /ocp/i2c@48072000/camera_ov10635
> [    0.437500] ldo3: operation not allowed
> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> [    0.468750] ov1063x 1-0030: No deserializer node found
> [    0.468750] ov1063x 1-0030: No serializer node found
> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> [    0.578125] ahci ahci.0.auto: can't get clock
> [    0.898437] ldc_module_init
> [    1.304687] Missing dual_emac_res_vlan in DT.
> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> [    1.312500] Missing dual_emac_res_vlan in DT.
> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> [    1.382812] Freeing init memory: 236K
> sh: write error: No such device
> Cannot identify '/dev/camera0': 2, No such file or directory
> Parsing config from /xen/images/DomUAndroid.cfg
> XSM Disabled: seclabel not supported
> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> dom1 access to irq 53: Function not implemented
> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> dom1 access to irq 71: Function not implemented
> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> dom1 access to irq 173: Function not implemented
> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> dom1 access to irq 174: Function not implemented
> Turning on vfb in domain 1
> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> still lr_pending
> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> still lr_pending
> Parsing config from /xen/images/DomUQNX.cfg
> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> inject irq=2 into d0v0, when it is still lr_pending
> 
> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> still lr_pending
> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> found: Invalid kernel
> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> failed: No such file or directory
> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> (re-)build domain: -3
> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> still lr_pending
> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> still lr_pending
> Turning on 'vsnd' in domain '1' (dev_id: '0')
> Turning on vkbd in domain 1
> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> still lr_pending
> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> still lr_pending
> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> still lr_pending
> 
> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> trying to inject irq=2 into d0v0, when it is still lr_pending
> 
> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > OK got it. Give me a few mins
> >
> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> >> for non-hardware irqs (desc == NULL) and keep avoiding
> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> >>
> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> >> other potential bugs introduced later.
> >>
> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >>> What if I try on top of current master branch the following code:
> >>>
> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >>> index 31fb81a..6764ab7 100644
> >>> --- a/xen/arch/arm/gic-v2.c
> >>> +++ b/xen/arch/arm/gic-v2.c
> >>> @@ -36,6 +36,8 @@
> >>>  #include <asm/io.h>
> >>>  #include <asm/gic.h>
> >>>
> >>> +#define GIC_DEBUG 1
> >>> +
> >>>  /*
> >>>   * LR register definitions are GIC v2 specific.
> >>>   * Moved these definitions from header file to here
> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> index bcaded9..c03d6a6 100644
> >>> --- a/xen/arch/arm/gic.c
> >>> +++ b/xen/arch/arm/gic.c
> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> >>>
> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> >>> gic_hw_ops->info->nr_lrs) - 1))
> >>>
> >>> -#undef GIC_DEBUG
> >>> +#define GIC_DEBUG 1
> >>>
> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> >>>
> >>> It is equivalent to what you proposing - my code contains
> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> >>> be executed:
> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> >>>
> >>> regards,
> >>> Andrii
> >>>
> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> >>> >> everything works fine
> >>> >> The following 2 patches fixes xen/master for my platform.
> >>> >>
> >>> >> Stefano, could you please take a look to these changes?
> >>> >>
> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> >>> >>
> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> >>> >>
> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >>> >>
> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >>> >> index 31fb81a..093ecdb 100644
> >>> >> --- a/xen/arch/arm/gic-v2.c
> >>> >> +++ b/xen/arch/arm/gic-v2.c
> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> >>> >> pending_irq *p,
> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> >>> >>
> >>> >> -    if ( p->desc != NULL )
> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >>> >>      {
> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >>> >> -        else
> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >>> >> +    }
> >>> >> +    else if ( p->desc != NULL )
> >>> >> +    {
> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> >>> >>      }
> >>> >>
> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> >>> >
> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> >>> > working correctly on OMAP5. This changes might only be better at
> >>> > "hiding" the real issue.
> >>> >
> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> >>> > maintenance interrupts doesn't work for software interrupts.
> >>> > The commit that should make them work correctly after the
> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> >>> > Maybe that doesn't work correctly on OMAP5.
> >>> >
> >>> > Could you try this patch on top of
> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> >>> > if the problem is specifically with software irqs.
> >>> >
> >>> >
> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> > index b7516c0..d8a17c9 100644
> >>> > --- a/xen/arch/arm/gic.c
> >>> > +++ b/xen/arch/arm/gic.c
> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> >>> >  /* Maximum cpu interface per GIC */
> >>> >  #define NR_GIC_CPU_IF 8
> >>> >
> >>> > -#undef GIC_DEBUG
> >>> > +#define GIC_DEBUG 1
> >>> >
> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> >>> >
> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >>> >      if ( p->desc != NULL )
> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> >>> > +    else
> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> >>> >
> >>> >      GICH[GICH_LR + lr] = lr_val;
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Andrii Tseglytskyi | Embedded Dev
> >>> GlobalLogic
> >>> www.globallogic.com
> >>>
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 17:52:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 17:52:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqmwg-00023J-8C; Tue, 18 Nov 2014 17:52: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@citrix.com>) id 1Xqmwf-00023E-J7
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 17:52:05 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	27/B7-24124-4478B645; Tue, 18 Nov 2014 17:52:04 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416333122!12091334!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5679 invoked from network); 18 Nov 2014 17:52:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 17:52:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,411,1413244800"; d="scan'208";a="192580033"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 12:51:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XqmwX-00013f-Cy;
	Tue, 18 Nov 2014 17:51:57 +0000
Date: Tue, 18 Nov 2014 17:51:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Andrii,
we are getting closer :-)

It would help if you post the output with GIC_DEBUG defined but without
the other change that "fixes" the issue.

I think the problem is probably due to software irqs.
You are getting too many

gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending

messages. That means you are loosing virtual SGIs (guest VCPU to guest
VCPU). It would be best to investigate why, especially if you get many
more of the same messages without the MAINTENANCE_IRQ change I
suggested.

This patch might also help understading the problem more:


diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b7516c0..5eaeca2 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
     list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
     {
         i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
-        if ( i >= nr_lrs ) return;
+        if ( i >= nr_lrs )
+        {
+            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
+                    p->irq, v->domain->domain_id, v->vcpu_id);
+            continue;
+        }
 
         spin_lock_irqsave(&gic.lock, flags);
         gic_set_lr(i, p, GICH_LR_PENDING);




On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> No hangs with this change.
> Complete log is the following:
> 
> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> DRA752 ES1.0
> <ethaddr> not set. Validating first E-fuse MAC
> cpsw
> - UART enabled -
> - CPU 00000000 booting -
> - Xen starting in Hyp mode -
> - Zero BSS -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Checking for initrd in /chosen
> (XEN) RAM: 0000000080000000 - 000000009fffffff
> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> (XEN)
> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> (XEN)
> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> (XEN) Dom heap: 344064 pages
> (XEN) Domain heap initialised
> (XEN) Looking for UART console serial0
>  Xen 4.5-unstable
> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> (arm-linux-gnueabihf-gcc (crosstool-NG
> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> 20130328 (prerelease)) debu4
> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> (XEN) 32-bit Execution:
> (XEN)   Processor Features: 00001131:00011011
> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> (XEN)     Extensions: GenericTimer Security
> (XEN)   Debug Features: 02010555
> (XEN)   Auxiliary Features: 00000000
> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> (XEN) Platform: TI DRA7
> (XEN) /psci method must be smc, but is: "hvc"
> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> (XEN) Set AuxCoreBoot0 to 0x20
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> (XEN) Using generic timer at 6144 KHz
> (XEN) GIC initialization:
> (XEN)         gic_dist_addr=0000000048211000
> (XEN)         gic_cpu_addr=0000000048212000
> (XEN)         gic_hyp_addr=0000000048214000
> (XEN)         gic_vcpu_addr=0000000048216000
> (XEN)         gic_maintenance_irq=25
> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) I/O virtualisation disabled
> (XEN) Allocated console ring of 16 KiB.
> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> (XEN) Bringing up CPU1
> - CPU 00000001 booting -
> - Xen starting in Hyp mode -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 1 booted.
> (XEN) Brought up 2 CPUs
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading kernel from boot module 2
> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> input to Xen)
> (XEN) Freed 272kB init memory.
> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> already pending in LR0
> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> already pending in LR0
> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> /ocp/i2c@48072000/camera_ov10635
> [    0.437500] ldo3: operation not allowed
> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> [    0.468750] ov1063x 1-0030: No deserializer node found
> [    0.468750] ov1063x 1-0030: No serializer node found
> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> [    0.578125] ahci ahci.0.auto: can't get clock
> [    0.898437] ldc_module_init
> [    1.304687] Missing dual_emac_res_vlan in DT.
> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> [    1.312500] Missing dual_emac_res_vlan in DT.
> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> [    1.382812] Freeing init memory: 236K
> sh: write error: No such device
> Cannot identify '/dev/camera0': 2, No such file or directory
> Parsing config from /xen/images/DomUAndroid.cfg
> XSM Disabled: seclabel not supported
> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> dom1 access to irq 53: Function not implemented
> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> dom1 access to irq 71: Function not implemented
> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> dom1 access to irq 173: Function not implemented
> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> dom1 access to irq 174: Function not implemented
> Turning on vfb in domain 1
> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> still lr_pending
> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> still lr_pending
> Parsing config from /xen/images/DomUQNX.cfg
> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> inject irq=2 into d0v0, when it is still lr_pending
> 
> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> still lr_pending
> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> found: Invalid kernel
> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> failed: No such file or directory
> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> (re-)build domain: -3
> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> still lr_pending
> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> still lr_pending
> Turning on 'vsnd' in domain '1' (dev_id: '0')
> Turning on vkbd in domain 1
> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> still lr_pending
> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> still lr_pending
> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> still lr_pending
> 
> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> trying to inject irq=2 into d0v0, when it is still lr_pending
> 
> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > OK got it. Give me a few mins
> >
> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> >> for non-hardware irqs (desc == NULL) and keep avoiding
> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> >>
> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> >> other potential bugs introduced later.
> >>
> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >>> What if I try on top of current master branch the following code:
> >>>
> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >>> index 31fb81a..6764ab7 100644
> >>> --- a/xen/arch/arm/gic-v2.c
> >>> +++ b/xen/arch/arm/gic-v2.c
> >>> @@ -36,6 +36,8 @@
> >>>  #include <asm/io.h>
> >>>  #include <asm/gic.h>
> >>>
> >>> +#define GIC_DEBUG 1
> >>> +
> >>>  /*
> >>>   * LR register definitions are GIC v2 specific.
> >>>   * Moved these definitions from header file to here
> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> index bcaded9..c03d6a6 100644
> >>> --- a/xen/arch/arm/gic.c
> >>> +++ b/xen/arch/arm/gic.c
> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> >>>
> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> >>> gic_hw_ops->info->nr_lrs) - 1))
> >>>
> >>> -#undef GIC_DEBUG
> >>> +#define GIC_DEBUG 1
> >>>
> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> >>>
> >>> It is equivalent to what you proposing - my code contains
> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> >>> be executed:
> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> >>>
> >>> regards,
> >>> Andrii
> >>>
> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> >>> >> everything works fine
> >>> >> The following 2 patches fixes xen/master for my platform.
> >>> >>
> >>> >> Stefano, could you please take a look to these changes?
> >>> >>
> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> >>> >>
> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> >>> >>
> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >>> >>
> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >>> >> index 31fb81a..093ecdb 100644
> >>> >> --- a/xen/arch/arm/gic-v2.c
> >>> >> +++ b/xen/arch/arm/gic-v2.c
> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> >>> >> pending_irq *p,
> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> >>> >>
> >>> >> -    if ( p->desc != NULL )
> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >>> >>      {
> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >>> >> -        else
> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >>> >> +    }
> >>> >> +    else if ( p->desc != NULL )
> >>> >> +    {
> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> >>> >>      }
> >>> >>
> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> >>> >
> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> >>> > working correctly on OMAP5. This changes might only be better at
> >>> > "hiding" the real issue.
> >>> >
> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> >>> > maintenance interrupts doesn't work for software interrupts.
> >>> > The commit that should make them work correctly after the
> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> >>> > Maybe that doesn't work correctly on OMAP5.
> >>> >
> >>> > Could you try this patch on top of
> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> >>> > if the problem is specifically with software irqs.
> >>> >
> >>> >
> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> > index b7516c0..d8a17c9 100644
> >>> > --- a/xen/arch/arm/gic.c
> >>> > +++ b/xen/arch/arm/gic.c
> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> >>> >  /* Maximum cpu interface per GIC */
> >>> >  #define NR_GIC_CPU_IF 8
> >>> >
> >>> > -#undef GIC_DEBUG
> >>> > +#define GIC_DEBUG 1
> >>> >
> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> >>> >
> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >>> >      if ( p->desc != NULL )
> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> >>> > +    else
> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> >>> >
> >>> >      GICH[GICH_LR + lr] = lr_val;
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Andrii Tseglytskyi | Embedded Dev
> >>> GlobalLogic
> >>> www.globallogic.com
> >>>
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 18:04:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 18: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 1Xqn8D-0002Ob-4D; Tue, 18 Nov 2014 18:04:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1Xqn8B-0002OS-8C
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 18:03:59 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	C8/D9-28296-E0A8B645; Tue, 18 Nov 2014 18:03:58 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416333835!12105999!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21343 invoked from network); 18 Nov 2014 18:03:56 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-15.tower-31.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 18 Nov 2014 18:03:56 -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 S997006AbaKRSDn (ORCPT <rfc822;xen-devel@lists.xenproject.org>);
	Tue, 18 Nov 2014 19:03:43 +0100
Date: Tue, 18 Nov 2014 19:03:43 +0100
From: Daniel Kiper <dkiper@net-space.pl>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com
Message-ID: <20141118180343.GA12891@router-fw-old.local.net-space.pl>
References: <5464827B0200007800047188@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464827B0200007800047188@mail.emea.novell.com>
User-Agent: Mutt/1.3.28i
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] delaying 4.4.2 and 4.3.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 09:05:47AM +0000, Jan Beulich wrote:
> All,
>
> while the 3 month period since the previous stable releases would
> expire at the beginning of December, looking at the number of
> changes in the stable trees I don't think starting preparations right
> now would make much sense. Unless I hear severe objections to
> this plan, and unless 4.5 gets significantly delayed, I think we
> should look at RC1s for them once 4.5 is (almost) out the door.
> That'll also minimize collisions between testing needs 4.5 and the
> stable releases have.

By the way, what I should do to have commit f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
(tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4.3?
I am asking about that more than five months. This patch fixes real bug.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 18:04:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 18: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 1Xqn8D-0002Ob-4D; Tue, 18 Nov 2014 18:04:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1Xqn8B-0002OS-8C
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 18:03:59 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	C8/D9-28296-E0A8B645; Tue, 18 Nov 2014 18:03:58 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416333835!12105999!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21343 invoked from network); 18 Nov 2014 18:03:56 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-15.tower-31.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 18 Nov 2014 18:03:56 -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 S997006AbaKRSDn (ORCPT <rfc822;xen-devel@lists.xenproject.org>);
	Tue, 18 Nov 2014 19:03:43 +0100
Date: Tue, 18 Nov 2014 19:03:43 +0100
From: Daniel Kiper <dkiper@net-space.pl>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com
Message-ID: <20141118180343.GA12891@router-fw-old.local.net-space.pl>
References: <5464827B0200007800047188@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5464827B0200007800047188@mail.emea.novell.com>
User-Agent: Mutt/1.3.28i
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] delaying 4.4.2 and 4.3.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 09:05:47AM +0000, Jan Beulich wrote:
> All,
>
> while the 3 month period since the previous stable releases would
> expire at the beginning of December, looking at the number of
> changes in the stable trees I don't think starting preparations right
> now would make much sense. Unless I hear severe objections to
> this plan, and unless 4.5 gets significantly delayed, I think we
> should look at RC1s for them once 4.5 is (almost) out the door.
> That'll also minimize collisions between testing needs 4.5 and the
> stable releases have.

By the way, what I should do to have commit f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
(tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4.3?
I am asking about that more than five months. This patch fixes real bug.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 18:20:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 18:20:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqnNT-0002pX-3s; Tue, 18 Nov 2014 18:19:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqnNR-0002pS-9l
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 18:19:45 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	38/86-18267-0CD8B645; Tue, 18 Nov 2014 18:19:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416334780!12188064!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20879 invoked from network); 18 Nov 2014 18:19:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 18:19:42 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIIJWQJ010453
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Nov 2014 18:19:33 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIIJVuO007506
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Nov 2014 18:19:32 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAIIJUXn029696; Tue, 18 Nov 2014 18:19:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 10:19:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 05B33117AE9; Tue, 18 Nov 2014 13:19:27 -0500 (EST)
Date: Tue, 18 Nov 2014 13:19:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141118181927.GA24283@laptop.dumpdata.com>
References: <1416330461-11985-1-git-send-email-euan.harris@citrix.com>
	<21611.34164.318838.773459@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21611.34164.318838.773459@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Euan Harris <euan.harris@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Document device parameter of
 libxl_device_<type>_add 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, Nov 18, 2014 at 05:44:20PM +0000, Ian Jackson wrote:
> Euan Harris writes ("[PATCH] libxl: Document device parameter of libxl_device_<type>_add functions"):
> > The device parameter of libxl_device_<type>_add is an in/out parameter.
> > Unspecified fields are filled in with appropriate values for the created
> > device when the function returns.  Document this behaviour.
> 
> Thanks.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Konrad, this should go into 4.5 IMO because it's a doc comment
> describing existing behaviour which we want everyone to rely on.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Ian.
> 
> > Signed-off-by: Euan Harris <euan.harris@citrix.com>
> > ---
> >  tools/libxl/libxl.h | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index c3451bd..41d6e8d 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -1109,6 +1109,10 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms);
> >   *   domain to connect to the device and therefore cannot block on the
> >   *   guest.
> >   *
> > + *   device is an in/out parameter:  fields left unspecified when the
> > + *   structure is passed in are filled in with appropriate values for
> > + *   the device created.
> > + *
> >   * libxl_device_<type>_remove(ctx, domid, device):
> >   *
> >   *   Removes the given device from the specified domain by performing
> > -- 
> > 1.9.3
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 18:20:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 18:20:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqnNT-0002pX-3s; Tue, 18 Nov 2014 18:19:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqnNR-0002pS-9l
	for xen-devel@lists.xen.org; Tue, 18 Nov 2014 18:19:45 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	38/86-18267-0CD8B645; Tue, 18 Nov 2014 18:19:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416334780!12188064!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20879 invoked from network); 18 Nov 2014 18:19:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 18:19:42 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIIJWQJ010453
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Nov 2014 18:19:33 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIIJVuO007506
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Nov 2014 18:19:32 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAIIJUXn029696; Tue, 18 Nov 2014 18:19:30 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 10:19:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 05B33117AE9; Tue, 18 Nov 2014 13:19:27 -0500 (EST)
Date: Tue, 18 Nov 2014 13:19:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141118181927.GA24283@laptop.dumpdata.com>
References: <1416330461-11985-1-git-send-email-euan.harris@citrix.com>
	<21611.34164.318838.773459@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21611.34164.318838.773459@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Euan Harris <euan.harris@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Document device parameter of
 libxl_device_<type>_add 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, Nov 18, 2014 at 05:44:20PM +0000, Ian Jackson wrote:
> Euan Harris writes ("[PATCH] libxl: Document device parameter of libxl_device_<type>_add functions"):
> > The device parameter of libxl_device_<type>_add is an in/out parameter.
> > Unspecified fields are filled in with appropriate values for the created
> > device when the function returns.  Document this behaviour.
> 
> Thanks.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Konrad, this should go into 4.5 IMO because it's a doc comment
> describing existing behaviour which we want everyone to rely on.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Ian.
> 
> > Signed-off-by: Euan Harris <euan.harris@citrix.com>
> > ---
> >  tools/libxl/libxl.h | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index c3451bd..41d6e8d 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -1109,6 +1109,10 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms);
> >   *   domain to connect to the device and therefore cannot block on the
> >   *   guest.
> >   *
> > + *   device is an in/out parameter:  fields left unspecified when the
> > + *   structure is passed in are filled in with appropriate values for
> > + *   the device created.
> > + *
> >   * libxl_device_<type>_remove(ctx, domid, device):
> >   *
> >   *   Removes the given device from the specified domain by performing
> > -- 
> > 1.9.3
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 18:24:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 18:24:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqnSF-0002xR-VZ; Tue, 18 Nov 2014 18:24: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@citrix.com>) id 1XqnSE-0002xJ-Lv
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 18:24:42 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	BC/F6-31453-9EE8B645; Tue, 18 Nov 2014 18:24:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416335079!9197481!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8120 invoked from network); 18 Nov 2014 18:24:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 18:24:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,411,1413244800"; d="scan'208";a="192593229"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 13:24:31 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqnS3-0001e5-FC;
	Tue, 18 Nov 2014 18:24:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqnS3-0005Oe-6v;
	Tue, 18 Nov 2014 18:24:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.36575.47438.496721@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 18:24:31 +0000
To: Daniel Kiper <dkiper@net-space.pl>
In-Reply-To: <20141118180343.GA12891@router-fw-old.local.net-space.pl>
References: <5464827B0200007800047188@mail.emea.novell.com>
	<20141118180343.GA12891@router-fw-old.local.net-space.pl>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Charles Arnold <carnold@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Campbell <ian.campbell@citrix.com>, jbeulich@suse.com
Subject: [Xen-devel] Backport request for "tools/hotplug: set mtu from
	bridge for tap 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

Daniel Kiper writes ("Re: [Xen-devel] delaying 4.4.2 and 4.3.4"):
> By the way, what I should do to have commit f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
> (tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4.3?
> I am asking about that more than five months. This patch fixes real bug.

I don't seem to be able to find these mails from you but my mailbox is
very big.  The normal thing ought to be for you to post a backport
request and CC the stable tools maintainer (ie me).  I'm sorry if I
dropped your message.

The patch looks reasonable to backport.  I have put it on my list for
backporting later.  I'll wait a bit to see if anyone objects.
(I have also CC'd the patch's original author and also Ian C because
he acked it for unstable.)

Does it apply cleanly to 4.3 and 4.4?  I haven't checked.  Daniel, if
you could check that, that would be helpful.  If it doesn't then the
normal process would be for the backport requestor (ie you) to post
the revised patch against 4.3 and/or 4.4.

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 Nov 18 18:24:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 18:24:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqnSF-0002xR-VZ; Tue, 18 Nov 2014 18:24: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@citrix.com>) id 1XqnSE-0002xJ-Lv
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 18:24:42 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	BC/F6-31453-9EE8B645; Tue, 18 Nov 2014 18:24:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416335079!9197481!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8120 invoked from network); 18 Nov 2014 18:24:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 18:24:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,411,1413244800"; d="scan'208";a="192593229"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 18 Nov 2014 13:24:31 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqnS3-0001e5-FC;
	Tue, 18 Nov 2014 18:24:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqnS3-0005Oe-6v;
	Tue, 18 Nov 2014 18:24:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21611.36575.47438.496721@mariner.uk.xensource.com>
Date: Tue, 18 Nov 2014 18:24:31 +0000
To: Daniel Kiper <dkiper@net-space.pl>
In-Reply-To: <20141118180343.GA12891@router-fw-old.local.net-space.pl>
References: <5464827B0200007800047188@mail.emea.novell.com>
	<20141118180343.GA12891@router-fw-old.local.net-space.pl>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Charles Arnold <carnold@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Campbell <ian.campbell@citrix.com>, jbeulich@suse.com
Subject: [Xen-devel] Backport request for "tools/hotplug: set mtu from
	bridge for tap 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

Daniel Kiper writes ("Re: [Xen-devel] delaying 4.4.2 and 4.3.4"):
> By the way, what I should do to have commit f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
> (tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4.3?
> I am asking about that more than five months. This patch fixes real bug.

I don't seem to be able to find these mails from you but my mailbox is
very big.  The normal thing ought to be for you to post a backport
request and CC the stable tools maintainer (ie me).  I'm sorry if I
dropped your message.

The patch looks reasonable to backport.  I have put it on my list for
backporting later.  I'll wait a bit to see if anyone objects.
(I have also CC'd the patch's original author and also Ian C because
he acked it for unstable.)

Does it apply cleanly to 4.3 and 4.4?  I haven't checked.  Daniel, if
you could check that, that would be helpful.  If it doesn't then the
normal process would be for the backport requestor (ie you) to post
the revised patch against 4.3 and/or 4.4.

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 Nov 18 19:20:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 19: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 1XqoJy-0003p2-Ic; Tue, 18 Nov 2014 19:20:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqoJr-0003ou-7M
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 19:20:13 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	6F/A7-19763-6EB9B645; Tue, 18 Nov 2014 19:20:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416338403!12081819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5092 invoked from network); 18 Nov 2014 19:20:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 19:20:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,411,1413244800"; d="scan'208";a="192617005"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 14:20:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqoJl-0005i0-E5;
	Tue, 18 Nov 2014 19:20:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqoJl-00042k-20;
	Tue, 18 Nov 2014 19:20:01 +0000
Date: Tue, 18 Nov 2014 19:20:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31630-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31630: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31630 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31630/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             5 kernel-build              fail REGR. vs. 30594
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu  5 xen-boot                    fail pass in 31592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot              fail pass in 31592
 test-i386-i386-pair           7 xen-boot/src_host           fail pass in 31592
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail in 31592 pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31630
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31630
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31630
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31630

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-amd64-pv           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1)             blocked n/a
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-pair         1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)               blocked n/a
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail in 31592 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31592 never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 31592 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31592 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 31592 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31592 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31592 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 31592 never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop            fail in 31592 never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop      fail in 31592 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         blocked 
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           blocked 
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 19:20:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 19: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 1XqoK7-0003pN-Uw; Tue, 18 Nov 2014 19:20:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carnold@suse.com>) id 1XqoK6-0003pG-Oo
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 19:20:22 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	06/E2-16982-5FB9B645; Tue, 18 Nov 2014 19:20:21 +0000
X-Env-Sender: carnold@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416338419!12199934!1
X-Originating-IP: [137.65.248.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27387 invoked from network); 18 Nov 2014 19:20:21 -0000
Received: from prv-mh.provo.novell.com (HELO prv-mh.provo.novell.com)
	(137.65.248.74)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 19:20:21 -0000
Received: from INET-PRV-MTA by prv-mh.provo.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 12:20:18 -0700
Message-Id: <546B398002000091000E3582@prv-mh.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 12:20:16 -0700
From: "Charles Arnold" <carnold@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Daniel Kiper" <dkiper@net-space.pl>
References: <5464827B0200007800047188@mail.emea.novell.com>
	<20141118180343.GA12891@router-fw-old.local.net-space.pl>
	<21611.36575.47438.496721@mariner.uk.xensource.com>
In-Reply-To: <21611.36575.47438.496721@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Backport request for "tools/hotplug: set mtu from
 bridge for tap 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 11/18/2014 at 11:24 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: 
> Daniel Kiper writes ("Re: [Xen-devel] delaying 4.4.2 and 4.3.4"):
>> By the way, what I should do to have commit 
> f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
>> (tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4.3?
>> I am asking about that more than five months. This patch fixes real bug.
> 
> I don't seem to be able to find these mails from you but my mailbox is
> very big.  The normal thing ought to be for you to post a backport
> request and CC the stable tools maintainer (ie me).  I'm sorry if I
> dropped your message.
> 
> The patch looks reasonable to backport.  I have put it on my list for
> backporting later.  I'll wait a bit to see if anyone objects.
> (I have also CC'd the patch's original author and also Ian C because
> he acked it for unstable.)

It should backport without problem.  I would also recommend this small
change that adds quotes around $bridge and $dev to handle spaces in names.
This should also go into unstable.

diff --git a/tools/hotplug/Linux/vif-bridge b/tools/hotplug/Linux/vif-bridge
index 3d72ca4..8b67b0a 100644
--- a/tools/hotplug/Linux/vif-bridge
+++ b/tools/hotplug/Linux/vif-bridge
@@ -77,7 +77,7 @@ fi
 case "$command" in
     online)
         setup_virtual_bridge_port "$dev"
-        set_mtu $bridge $dev
+        set_mtu "$bridge" "$dev"
         add_to_bridge "$bridge" "$dev"
         ;;
 
@@ -88,7 +88,7 @@ case "$command" in
 
     add)
         setup_virtual_bridge_port "$dev"
-        set_mtu $bridge $dev
+        set_mtu "$bridge" "$dev"
         add_to_bridge "$bridge" "$dev"
         ;;
 esac



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 19:20:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 19: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 1XqoJy-0003p2-Ic; Tue, 18 Nov 2014 19:20:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqoJr-0003ou-7M
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 19:20:13 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	6F/A7-19763-6EB9B645; Tue, 18 Nov 2014 19:20:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416338403!12081819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5092 invoked from network); 18 Nov 2014 19:20:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 19:20:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,411,1413244800"; d="scan'208";a="192617005"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 14:20:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqoJl-0005i0-E5;
	Tue, 18 Nov 2014 19:20:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqoJl-00042k-20;
	Tue, 18 Nov 2014 19:20:01 +0000
Date: Tue, 18 Nov 2014 19:20:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31630-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31630: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31630 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31630/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             5 kernel-build              fail REGR. vs. 30594
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu  5 xen-boot                    fail pass in 31592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot              fail pass in 31592
 test-i386-i386-pair           7 xen-boot/src_host           fail pass in 31592
 test-amd64-i386-pair     17 guest-migrate/src_host/dst_host fail pass in 31451
 test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail in 31592 pass in 31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31630
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31630
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31630
 test-amd64-i386-pv            7 debian-install     fail in 31451 pass in 31630

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-amd64-pv           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1)             blocked n/a
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-pair         1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)               blocked n/a
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail in 31592 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31592 never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 31592 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31592 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 31592 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31592 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31592 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 31592 never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop            fail in 31592 never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop      fail in 31592 never pass

version targeted for testing:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen                  fad105dd0ac1a224d91757afee01acd4566f7e82

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         blocked 
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           blocked 
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 c844974caf1501b6527533ab2a3d27ea8920ab90
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Oct 31 11:23:17 2014 +0100

    x86/paging: make log-dirty operations preemptible
    
    Both the freeing and the inspection of the bitmap get done in (nested)
    loops which - besides having a rather high iteration count in general,
    albeit that would be covered by XSA-77 - have the number of non-trivial
    iterations they need to perform (indirectly) controllable by both the
    guest they are for and any domain controlling the guest (including the
    one running qemu for it).
    
    Note that the tying of the continuations to the invoking domain (which
    previously [wrongly] used the invoking vCPU instead) implies that the
    tools requesting such operations have to make sure they don't issue
    multiple similar operations in parallel.
    
    Note further that this breaks supervisor-mode kernel assumptions in
    hypercall_create_continuation() (where regs->eip gets rewound to the
    current hypercall stub beginning), but otoh
    hypercall_cancel_continuation() doesn't work in that mode either.
    Perhaps time to rip out all the remains of that feature?
    
    This is part of CVE-2014-5146 / XSA-97.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
    master date: 2014-10-06 11:22:04 +0200
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 19:20:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 19: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 1XqoK7-0003pN-Uw; Tue, 18 Nov 2014 19:20:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carnold@suse.com>) id 1XqoK6-0003pG-Oo
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 19:20:22 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	06/E2-16982-5FB9B645; Tue, 18 Nov 2014 19:20:21 +0000
X-Env-Sender: carnold@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416338419!12199934!1
X-Originating-IP: [137.65.248.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27387 invoked from network); 18 Nov 2014 19:20:21 -0000
Received: from prv-mh.provo.novell.com (HELO prv-mh.provo.novell.com)
	(137.65.248.74)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 19:20:21 -0000
Received: from INET-PRV-MTA by prv-mh.provo.novell.com
	with Novell_GroupWise; Tue, 18 Nov 2014 12:20:18 -0700
Message-Id: <546B398002000091000E3582@prv-mh.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 18 Nov 2014 12:20:16 -0700
From: "Charles Arnold" <carnold@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Daniel Kiper" <dkiper@net-space.pl>
References: <5464827B0200007800047188@mail.emea.novell.com>
	<20141118180343.GA12891@router-fw-old.local.net-space.pl>
	<21611.36575.47438.496721@mariner.uk.xensource.com>
In-Reply-To: <21611.36575.47438.496721@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Backport request for "tools/hotplug: set mtu from
 bridge for tap 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 11/18/2014 at 11:24 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: 
> Daniel Kiper writes ("Re: [Xen-devel] delaying 4.4.2 and 4.3.4"):
>> By the way, what I should do to have commit 
> f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
>> (tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4.3?
>> I am asking about that more than five months. This patch fixes real bug.
> 
> I don't seem to be able to find these mails from you but my mailbox is
> very big.  The normal thing ought to be for you to post a backport
> request and CC the stable tools maintainer (ie me).  I'm sorry if I
> dropped your message.
> 
> The patch looks reasonable to backport.  I have put it on my list for
> backporting later.  I'll wait a bit to see if anyone objects.
> (I have also CC'd the patch's original author and also Ian C because
> he acked it for unstable.)

It should backport without problem.  I would also recommend this small
change that adds quotes around $bridge and $dev to handle spaces in names.
This should also go into unstable.

diff --git a/tools/hotplug/Linux/vif-bridge b/tools/hotplug/Linux/vif-bridge
index 3d72ca4..8b67b0a 100644
--- a/tools/hotplug/Linux/vif-bridge
+++ b/tools/hotplug/Linux/vif-bridge
@@ -77,7 +77,7 @@ fi
 case "$command" in
     online)
         setup_virtual_bridge_port "$dev"
-        set_mtu $bridge $dev
+        set_mtu "$bridge" "$dev"
         add_to_bridge "$bridge" "$dev"
         ;;
 
@@ -88,7 +88,7 @@ case "$command" in
 
     add)
         setup_virtual_bridge_port "$dev"
-        set_mtu $bridge $dev
+        set_mtu "$bridge" "$dev"
         add_to_bridge "$bridge" "$dev"
         ;;
 esac



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 19:21:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 19: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 1XqoKr-0003ue-T5; Tue, 18 Nov 2014 19:21:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqoKq-0003uO-Bw
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 19:21:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	58/54-09936-32C9B645; Tue, 18 Nov 2014 19:21:07 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416338465!13664443!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29267 invoked from network); 18 Nov 2014 19:21:05 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 19:21:05 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so3007674wiv.11
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 11:21:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=KopJ2v8W8GKNDTwXIVOCRG8G3aqgb/4Dzp2VAGUJ0eM=;
	b=Xqcm5rtrU5qeSql69eRv242iDvn5Z4wepqXWVGJ3fmreeMGz/Yzi2FcThyo+NZ2F8G
	dhVtcr+27pwugPHLdqpexQRkQQDLKJ/8zt6ptBq2Hd8vnggXPtnTAC/zGNqmbjVoBuAv
	rQAFaUbfi3FbUIVGaelWA6rk7EG3XE0j1p6RgvGAuVthD/OEZmA5YhJo2r4UK5hh+mQT
	6TKxUXreH0K8v8g24x22q3Ep951VjEtUmjlME6+wuBg1zl+Imz4JVz8qJmX0VnnceTke
	VLYGwwPtZNER/7R1wN7PcamjA/ov2wi3stKQoHL81+gn1V4KcA8F3EDs2XqfF0EqHBY7
	3L5A==
X-Gm-Message-State: ALoCoQkxUm11hDdRd6/mLwaAQIVAkAPoUin9uXFZLx4zk9CKrj4Zz6IoGs0jZh8prf6P/wgyS+cJ
X-Received: by 10.194.3.45 with SMTP id 13mr49102121wjz.47.1416338465365;
	Tue, 18 Nov 2014 11:21:05 -0800 (PST)
Received: from belegaer.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id
	bc1sm20697769wib.16.2014.11.18.11.21.03 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 11:21:04 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 18 Nov 2014 19:20:36 +0000
Message-Id: <1416338436-3293-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 1.7.10.4
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	Keir Fraser <keir@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [RFC for 4.6] xen: Extend DOMCTL createdomain to
	support arch 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM the virtual GIC may differ between each guest (emulated GIC version,
number of SPIs...). Those informations are already known at the domain creation
and can never change.

For now only the gic_version is set. In long run, there will be more parameters
such as the number of SPIs. All will be required to be set at the same time.

A new arch-specific structure arch_domainconfig has been created, the x86
one doesn't have any specific configuration, a dummy structure
(C-spec compliant) has been created to factorize the code on the toolstack.

Some external tools (qemu, xenstore) may require to create a domain. Rather
than asking them to take care of the arch-specific domain configuration, let
the current function (xc_domain_create) to chose a default configuration and
introduce a new one (xc_domain_create_config).

This patch also drop the previously DOMCTL arm_configure_domain introduced
in Xen 4.5, as it has been made useless.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>

---
    This is a follow-up of http://lists.xen.org/archives/html/xen-devel/2014-11/msg00522.html

    TODO: What about migration? For now the configuration lives in internal
    libxl structure. We need a way to pass the domain configuration to the
    other end.

    I'm not sure if we should care of this right now as migration doesn't
    yet exists on ARM.

    For the xc_domain_create, Stefano S. was looking to drop PV domain
    creation support in QEMU. So maybe I could simply extend xc_domain_create
    and drop the xc_domain_create_config.
---
 tools/flask/policy/policy/modules/xen/xen.if |    2 +-
 tools/libxc/include/xenctrl.h                |   14 ++++----
 tools/libxc/xc_domain.c                      |   46 +++++++++++++++-----------
 tools/libxl/libxl_arch.h                     |    6 ++++
 tools/libxl/libxl_arm.c                      |   28 ++++++++++------
 tools/libxl/libxl_create.c                   |   21 +++++++++---
 tools/libxl/libxl_dm.c                       |    3 +-
 tools/libxl/libxl_dom.c                      |    2 +-
 tools/libxl/libxl_internal.h                 |    7 ++--
 tools/libxl/libxl_x86.c                      |   10 ++++++
 xen/arch/arm/domain.c                        |   28 +++++++++++++++-
 xen/arch/arm/domctl.c                        |   34 -------------------
 xen/arch/arm/mm.c                            |    6 ++--
 xen/arch/arm/setup.c                         |    6 +++-
 xen/arch/x86/domain.c                        |    3 +-
 xen/arch/x86/mm.c                            |    6 ++--
 xen/arch/x86/setup.c                         |    4 ++-
 xen/common/domain.c                          |    6 ++--
 xen/common/domctl.c                          |    3 +-
 xen/common/schedule.c                        |    3 +-
 xen/include/public/arch-arm.h                |    9 +++++
 xen/include/public/arch-x86/xen.h            |    5 +++
 xen/include/public/domctl.h                  |   20 ++---------
 xen/include/xen/domain.h                     |    3 +-
 xen/include/xen/sched.h                      |    8 +++--
 xen/xsm/flask/hooks.c                        |    3 --
 xen/xsm/flask/policy/access_vectors          |    2 --
 27 files changed, 168 insertions(+), 120 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index fa69c9d..641c797 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -49,7 +49,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			getscheduler getvcpuinfo getvcpuextstate getaddrsize
 			getaffinity setaffinity };
-	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
+	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 45e282c..9976ab1 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -477,18 +477,20 @@ typedef union
 } start_info_any_t;
 #endif
 
+
+typedef arch_domainconfig_t xc_domain_configuration_t;
+int xc_domain_create_config(xc_interface *xch,
+                            uint32_t ssidref,
+                            xen_domain_handle_t handle,
+                            uint32_t flags,
+                            uint32_t *pdomid,
+                            xc_domain_configuration_t *config);
 int xc_domain_create(xc_interface *xch,
                      uint32_t ssidref,
                      xen_domain_handle_t handle,
                      uint32_t flags,
                      uint32_t *pdomid);
 
-#if defined(__arm__) || defined(__aarch64__)
-typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
-
-int xc_domain_configure(xc_interface *xch, uint32_t domid,
-                        xc_domain_configuration_t *config);
-#endif
 
 /* Functions to produce a dump of a given domain
  *  xc_domain_dumpcore - produces a dump to a specified file
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index b071dea..a24a156 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -27,11 +27,12 @@
 #include <xen/memory.h>
 #include <xen/hvm/hvm_op.h>
 
-int xc_domain_create(xc_interface *xch,
-                     uint32_t ssidref,
-                     xen_domain_handle_t handle,
-                     uint32_t flags,
-                     uint32_t *pdomid)
+int xc_domain_create_config(xc_interface *xch,
+                            uint32_t ssidref,
+                            xen_domain_handle_t handle,
+                            uint32_t flags,
+                            uint32_t *pdomid,
+                            xc_domain_configuration_t *config)
 {
     int err;
     DECLARE_DOMCTL;
@@ -41,32 +42,39 @@ int xc_domain_create(xc_interface *xch,
     domctl.u.createdomain.ssidref = ssidref;
     domctl.u.createdomain.flags   = flags;
     memcpy(domctl.u.createdomain.handle, handle, sizeof(xen_domain_handle_t));
+    /* xc_domain_configure_t is an alias of arch_domainconfig_t */
+    memcpy(&domctl.u.createdomain.config, config, sizeof(*config));
     if ( (err = do_domctl(xch, &domctl)) != 0 )
         return err;
 
     *pdomid = (uint16_t)domctl.domain;
+    memcpy(config, &domctl.u.createdomain.config, sizeof(*config));
+
     return 0;
 }
 
-#if defined(__arm__) || defined(__aarch64__)
-int xc_domain_configure(xc_interface *xch, uint32_t domid,
-                        xc_domain_configuration_t *config)
+int xc_domain_create(xc_interface *xch,
+                     uint32_t ssidref,
+                     xen_domain_handle_t handle,
+                     uint32_t flags,
+                     uint32_t *pdomid)
 {
-    int rc;
-    DECLARE_DOMCTL;
+    xc_domain_configuration_t config;
 
-    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
-    domctl.domain = (domid_t)domid;
-    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
-    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
+    memset(&config, 0, sizeof(config));
 
-    rc = do_domctl(xch, &domctl);
-    if ( !rc )
-        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
+#if defined (__i386) || defined(__x86_64__)
+    /* No arch-specific configuration for now */
+#elif defined (__arm__) || defined(__aarch64__)
+    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
+#else
+    errno = ENOSYS;
+    return -1;
+#endif
 
-    return rc;
+    return xc_domain_create_config(xch, ssidref, handle,
+                                   flags, pdomid, &config);
 }
-#endif
 
 int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
                          xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index d3bc136..f806ed1 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -15,6 +15,11 @@
 #ifndef LIBXL_ARCH_H
 #define LIBXL_ARCH_H
 
+/* fill the arch specific configuration for the domain */
+int libxl__arch_domain_prepare_config(libxl__gc *gc,
+                                      libxl_domain_config *d_config,
+                                      xc_domain_configuration_t *xc_config);
+
 /* arch specific internal domain creation function */
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                uint32_t domid);
@@ -22,6 +27,7 @@ int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 /* setup arch specific hardware description, i.e. DTB on ARM */
 int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl_domain_build_info *info,
+                                           libxl__domain_build_state *state,
                                            struct xc_dom_image *dom);
 /* finalize arch specific hardware description. */
 int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 448ac07..50e59ff 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -35,6 +35,15 @@ static const char *gicv_to_string(uint8_t gic_version)
     }
 }
 
+int libxl__arch_domain_prepare_config(libxl__gc *gc,
+                                      libxl_domain_config *d_config,
+                                      xc_domain_configuration_t *xc_config)
+{
+    xc_config->gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
+
+    return 0;
+}
+
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                               uint32_t domid)
 {
@@ -516,9 +525,9 @@ out:
 
 int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl_domain_build_info *info,
+                                           libxl__domain_build_state *state,
                                            struct xc_dom_image *dom)
 {
-    xc_domain_configuration_t config;
     void *fdt = NULL;
     int rc, res;
     size_t fdt_size = 0;
@@ -526,6 +535,9 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
     const libxl_version_info *vers;
     const struct arch_info *ainfo;
 
+    /* convenience aliases */
+    xc_domain_configuration_t *xc_config = &state->config;
+
     assert(info->type == LIBXL_DOMAIN_TYPE_PV);
 
     vers = libxl_get_version_info(CTX);
@@ -534,16 +546,9 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
     ainfo = get_arch_info(gc, dom);
     if (ainfo == NULL) return ERROR_FAIL;
 
-    LOG(DEBUG, "configure the domain");
-    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
-    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
-        LOG(ERROR, "couldn't configure the domain");
-        return ERROR_FAIL;
-    }
-
     LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
         vers->xen_version_major, vers->xen_version_minor);
-    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
+    LOG(DEBUG, " - vGIC version: %s\n", gicv_to_string(xc_config->gic_version));
 
 /*
  * Call "call" handling FDR_ERR_*. Will either:
@@ -592,7 +597,7 @@ next_resize:
 
         FDT( make_memory_nodes(gc, fdt, dom) );
 
-        switch (config.gic_version) {
+        switch (xc_config->gic_version) {
         case XEN_DOMCTL_CONFIG_GIC_V2:
             FDT( make_gicv2_node(gc, fdt,
                                  GUEST_GICD_BASE, GUEST_GICD_SIZE,
@@ -602,7 +607,8 @@ next_resize:
             FDT( make_gicv3_node(gc, fdt) );
             break;
         default:
-            LOG(ERROR, "Unknown GIC version %d", config.gic_version);
+            LOG(ERROR, "Unknown GIC version %s",
+                gicv_to_string(xc_config->gic_version));
             rc = ERROR_FAIL;
             goto out;
         }
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..15120f8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -487,8 +487,8 @@ out:
     return ret;
 }
 
-int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
-                       uint32_t *domid)
+int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
+                       uint32_t *domid, xc_domain_configuration_t *xc_config)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags, ret, rc, nb_vm;
@@ -501,6 +501,8 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
     xen_domain_handle_t handle;
     libxl_vminfo *vm_list;
 
+    /* convenience aliases */
+    libxl_domain_create_info *info = &d_config->c_info;
 
     assert(!libxl_domid_valid_guest(*domid));
 
@@ -529,7 +531,16 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
     /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
     libxl_uuid_copy(ctx, (libxl_uuid *)handle, &info->uuid);
 
-    ret = xc_domain_create(ctx->xch, info->ssidref, handle, flags, domid);
+    ret = libxl__arch_domain_prepare_config(gc, d_config, xc_config);
+    if (ret < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fail to get domain config");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    ret = xc_domain_create_config(ctx->xch, info->ssidref,
+                                  handle, flags, domid,
+                                  xc_config);
     if (ret < 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "domain creation fail");
         rc = ERROR_FAIL;
@@ -762,9 +773,11 @@ static void initiate_domain_create(libxl__egc *egc,
 
     /* convenience aliases */
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
     const int restore_fd = dcs->restore_fd;
     memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
+
     domid = 0;
 
     if (d_config->c_info.ssid_label) {
@@ -846,7 +859,7 @@ static void initiate_domain_create(libxl__egc *egc,
     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);
+    ret = libxl__domain_make(gc, d_config, &domid, &state->config);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
         dcs->guest_domid = domid;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..17eb926 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1052,7 +1052,8 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
     stubdom_state->pv_ramdisk.path = "";
 
     /* fixme: this function can leak the stubdom if it fails */
-    ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid);
+    ret = libxl__domain_make(gc, dm_config, &sdss->pvqemu.guest_domid,
+                             &stubdom_state->config);
     if (ret)
         goto out;
     uint32_t dm_domid = sdss->pvqemu.guest_domid;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..f468e63 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -583,7 +583,7 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LOGE(ERROR, "xc_dom_parse_image failed");
         goto out;
     }
-    if ( (ret = libxl__arch_domain_init_hw_description(gc, info, dom)) != 0 ) {
+    if ( (ret = libxl__arch_domain_init_hw_description(gc, info, state, dom)) != 0 ) {
         LOGE(ERROR, "libxl__arch_domain_init_hw_description failed");
         goto out;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..d475487 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -971,6 +971,8 @@ typedef struct {
     libxl__file_reference pv_ramdisk;
     const char * pv_cmdline;
     bool pvh_enabled;
+
+    xc_domain_configuration_t config;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
@@ -1460,8 +1462,9 @@ _hidden  void libxl__exec(libxl__gc *gc, int stdinfd, int stdoutfd,
  /* on entry, libxl_domid_valid_guest(domid) must be false;
   * on exit (even error exit), domid may be valid and refer to a domain */
 _hidden int libxl__domain_make(libxl__gc *gc,
-                               libxl_domain_create_info *info,
-                               uint32_t *domid);
+                               libxl_domain_config *d_config,
+                               uint32_t *domid,
+                               xc_domain_configuration_t *xc_config);
 
 _hidden int libxl__domain_build(libxl__gc *gc,
                                 libxl_domain_config *d_config,
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 7589060..e0a0cff 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -1,6 +1,15 @@
 #include "libxl_internal.h"
 #include "libxl_arch.h"
 
+int libxl__arch_domain_prepare_config(libxl__gc *gc,
+                                      libxl_domain_config *d_config,
+                                      xc_domain_configuration_t *xc_config)
+{
+    /* No specific configuration right now */
+
+    return 0;
+}
+
 static const char *e820_names(int type)
 {
     switch (type) {
@@ -313,6 +322,7 @@ int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 
 int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl_domain_build_info *info,
+                                           libxl__domain_build_state *state,
                                            struct xc_dom_image *dom)
 {
     return 0;
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7221bc8..da97730 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -504,9 +504,11 @@ 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)
+int arch_domain_create(struct domain *d, unsigned int domcr_flags,
+                       arch_domainconfig_t *config)
 {
     int rc;
+    uint8_t gic_version;
 
     d->arch.relmem = RELMEM_not_started;
 
@@ -514,6 +516,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( is_idle_domain(d) )
         return 0;
 
+    ASSERT(config != NULL);
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
@@ -534,6 +537,29 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = p2m_alloc_table(d)) != 0 )
         goto fail;
 
+    /*
+     * Currently the vGIC is emulating the same version of the
+     * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
+     * is allowed. The DOMCTL will return the actual version of the
+     * GIC.
+     */
+    rc = -EOPNOTSUPP;
+    if ( config->gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
+        goto fail;
+
+    switch ( gic_hw_version() )
+    {
+    case GIC_V3:
+        gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+        break;
+    case GIC_V2:
+        gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
+        break;
+    default:
+        BUG();
+    }
+    config->gic_version = gic_version;
+
     if ( (rc = gicv_setup(d)) != 0 )
         goto fail;
 
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index d246e84..485d3aa 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -32,40 +32,6 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 
         return p2m_cache_flush(d, s, e);
     }
-    case XEN_DOMCTL_arm_configure_domain:
-    {
-        uint8_t gic_version;
-
-        /*
-         * Currently the vGIC is emulating the same version of the
-         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
-         * is allowed. The DOMCTL will return the actual version of the
-         * GIC.
-         */
-        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
-            return -EOPNOTSUPP;
-
-        switch ( gic_hw_version() )
-        {
-        case GIC_V3:
-            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
-            break;
-        case GIC_V2:
-            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
-            break;
-        default:
-            BUG();
-        }
-
-        domctl->u.configuredomain.gic_version = gic_version;
-
-        /* TODO: Make the copy generic for all ARCH domctl */
-        if ( __copy_to_guest(u_domctl, domctl, 1) )
-            return -EFAULT;
-
-        return 0;
-    }
-
     default:
         return subarch_do_domctl(domctl, d, u_domctl);
     }
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index ca0aa69..903e5ae 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -399,7 +399,7 @@ void __init arch_init_memory(void)
      * Any Xen-heap pages that we will allow to be mapped will have
      * their domain field set to dom_xen.
      */
-    dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0);
+    dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_xen));
 
     /*
@@ -407,14 +407,14 @@ void __init arch_init_memory(void)
      * This domain owns I/O pages that are within the range of the page_info
      * array. Mappings occur at the priv of the caller.
      */
-    dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0);
+    dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_io));
 
     /*
      * Initialise our COW domain.
      * This domain owns sharable pages.
      */
-    dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0);
+    dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_cow));
 }
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 67fd9c9..1547d8a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -697,6 +697,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     const char *cmdline;
     struct bootmodule *xen_bootmodule;
     struct domain *dom0;
+    struct arch_domainconfig config;
 
     setup_cache();
 
@@ -811,7 +812,10 @@ void __init start_xen(unsigned long boot_phys_offset,
     do_initcalls();
 
     /* Create initial domain 0. */
-    dom0 = domain_create(0, 0, 0);
+    /* Emulate the same version as the hardware GIC */
+    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
+
+    dom0 = domain_create(0, 0, 0, &config);
     if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
             panic("Error creating domain 0");
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 73d01bb..ffffe4c 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -514,7 +514,8 @@ void vcpu_destroy(struct vcpu *v)
         xfree(v->arch.pv_vcpu.trap_ctxt);
 }
 
-int arch_domain_create(struct domain *d, unsigned int domcr_flags)
+int arch_domain_create(struct domain *d, unsigned int domcr_flags,
+                       arch_domainconfig_t *config)
 {
     int i, paging_initialised = 0;
     int rc = -ENOMEM;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 8ee9938..523596d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -275,7 +275,7 @@ void __init arch_init_memory(void)
      * Hidden PCI devices will also be associated with this domain
      * (but be [partly] controlled by Dom0 nevertheless).
      */
-    dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0);
+    dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_xen));
     INIT_LIST_HEAD(&dom_xen->arch.pdev_list);
 
@@ -284,14 +284,14 @@ void __init arch_init_memory(void)
      * This domain owns I/O pages that are within the range of the page_info
      * array. Mappings occur at the priv of the caller.
      */
-    dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0);
+    dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_io));
     
     /*
      * Initialise our COW domain.
      * This domain owns sharable pages.
      */
-    dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0);
+    dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_cow));
 
     /* First 1MB of RAM is historically marked as I/O. */
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 73e95c6..3cc24f0 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -540,6 +540,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     int i, j, e820_warn = 0, bytes = 0;
     bool_t acpi_boot_table_init_done = 0;
     struct domain *dom0;
+    struct arch_domainconfig config;
     struct ns16550_defaults ns16550 = {
         .data_bits = 8,
         .parity    = 'n',
@@ -1347,7 +1348,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
         domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
 
     /* Create initial domain 0. */
-    dom0 = domain_create(0, domcr_flags, 0);
+    memset(&config, 0, sizeof(config));
+    dom0 = domain_create(0, domcr_flags, 0, &config);
     if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
         panic("Error creating domain 0");
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 4a62c1d..bd118ec 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -242,8 +242,8 @@ static void __init parse_extra_guest_irqs(const char *s)
 }
 custom_param("extra_guest_irqs", parse_extra_guest_irqs);
 
-struct domain *domain_create(
-    domid_t domid, unsigned int domcr_flags, uint32_t ssidref)
+struct domain *domain_create(domid_t domid, unsigned int domcr_flags,
+                             uint32_t ssidref, arch_domainconfig_t *config)
 {
     struct domain *d, **pd, *old_hwdom = NULL;
     enum { INIT_xsm = 1u<<0, INIT_watchdog = 1u<<1, INIT_rangeset = 1u<<2,
@@ -352,7 +352,7 @@ struct domain *domain_create(
             goto fail;
     }
 
-    if ( (err = arch_domain_create(d, domcr_flags)) != 0 )
+    if ( (err = arch_domain_create(d, domcr_flags, config)) != 0 )
         goto fail;
     init_status |= INIT_arch;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d9c2635..c7b68c6 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -583,7 +583,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
             domcr_flags |= DOMCRF_oos_off;
 
-        d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref);
+        d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref,
+                          &op->u.createdomain.config);
         if ( IS_ERR(d) )
         {
             ret = PTR_ERR(d);
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 6285a6e..ab2561a 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1421,7 +1421,8 @@ void __init scheduler_init(void)
         sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
     }
 
-    idle_domain = domain_create(DOMID_IDLE, 0, 0);
+    /* There is no need of arch-specific configuration for an idle domain */
+    idle_domain = domain_create(DOMID_IDLE, 0, 0, NULL);
     BUG_ON(IS_ERR(idle_domain));
     idle_domain->vcpu = idle_vcpu;
     idle_domain->max_vcpus = nr_cpu_ids;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 72d641f..9c53294 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -314,6 +314,15 @@ struct arch_shared_info {
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
+#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
+#define XEN_DOMCTL_CONFIG_GIC_V2        1
+#define XEN_DOMCTL_CONFIG_GIC_V3        2
+struct arch_domainconfig {
+    /* IN/OUT */
+    uint8_t gic_version;
+};
+typedef struct arch_domainconfig arch_domainconfig_t;
+
 #endif
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index f35804b..5b1c678 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -228,6 +228,11 @@ struct arch_shared_info {
 };
 typedef struct arch_shared_info arch_shared_info_t;
 
+struct arch_domainconfig {
+    char dummy;
+};
+typedef struct arch_domainconfig arch_domainconfig_t;
+
 #endif /* !__ASSEMBLY__ */
 
 /*
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 8da204e..5ac41f6 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -39,7 +39,7 @@
 
 #define XEN_DOMCTL_INTERFACE_VERSION 0x0000000a
 
-/*
+/* 
  * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
  * If it is specified as zero, an id is auto-allocated and returned.
  */
@@ -64,23 +64,11 @@ struct xen_domctl_createdomain {
 #define _XEN_DOMCTL_CDF_pvh_guest     4
 #define XEN_DOMCTL_CDF_pvh_guest      (1U<<_XEN_DOMCTL_CDF_pvh_guest)
     uint32_t flags;
+    struct arch_domainconfig config;
 };
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
 
-#if defined(__arm__) || defined(__aarch64__)
-#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
-#define XEN_DOMCTL_CONFIG_GIC_V2        1
-#define XEN_DOMCTL_CONFIG_GIC_V3        2
-/* XEN_DOMCTL_configure_domain */
-struct xen_domctl_arm_configuredomain {
-    /* IN/OUT parameters */
-    uint8_t gic_version;
-};
-typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
-DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
-#endif
-
 /* XEN_DOMCTL_getdomaininfo */
 struct xen_domctl_getdomaininfo {
     /* OUT variables. */
@@ -1069,7 +1057,6 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_vcpu_msrs                 73
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
-#define XEN_DOMCTL_arm_configure_domain          76
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1078,9 +1065,6 @@ struct xen_domctl {
     domid_t  domain;
     union {
         struct xen_domctl_createdomain      createdomain;
-#if defined(__arm__) || defined(__aarch64__)
-        struct xen_domctl_arm_configuredomain configuredomain;
-#endif
         struct xen_domctl_getdomaininfo     getdomaininfo;
         struct xen_domctl_getmemlist        getmemlist;
         struct xen_domctl_getpageframeinfo  getpageframeinfo;
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 9215b0e..6918cc2 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -55,7 +55,8 @@ void vcpu_destroy(struct vcpu *v);
 int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset);
 void unmap_vcpu_info(struct vcpu *v);
 
-int arch_domain_create(struct domain *d, unsigned int domcr_flags);
+int arch_domain_create(struct domain *d, unsigned int domcr_flags,
+                       arch_domainconfig_t *config);
 
 void arch_domain_destroy(struct domain *d);
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 46fc6e3..95a464c 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -525,8 +525,12 @@ static inline void get_knownalive_domain(struct domain *d)
 int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity);
 void domain_update_node_affinity(struct domain *d);
 
-struct domain *domain_create(
-    domid_t domid, unsigned int domcr_flags, uint32_t ssidref);
+/*
+ * Create a domain: the configuration is only necessary for real domain
+ * (i.e !DOMCRF_dummy, excluded idle domain)
+ */
+struct domain *domain_create(domid_t domid, unsigned int domcr_flags,
+                             uint32_t ssidref, arch_domainconfig_t *config);
  /* DOMCRF_hvm: Create an HVM domain, as opposed to a PV domain. */
 #define _DOMCRF_hvm           0
 #define DOMCRF_hvm            (1U<<_DOMCRF_hvm)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0ba2ce9..6d0fe72 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -727,9 +727,6 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_psr_cmt_op:
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
 
-    case XEN_DOMCTL_arm_configure_domain:
-        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
-
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
         return -EPERM;
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1cd451e..b6d0cbe 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -216,8 +216,6 @@ class domain2
     get_vnumainfo
 # XEN_DOMCTL_psr_cmt_op
     psr_cmt_op
-# XEN_DOMCTL_configure_domain
-    configure_domain
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 19:21:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 19: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 1XqoKr-0003ue-T5; Tue, 18 Nov 2014 19:21:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XqoKq-0003uO-Bw
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 19:21:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	58/54-09936-32C9B645; Tue, 18 Nov 2014 19:21:07 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416338465!13664443!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29267 invoked from network); 18 Nov 2014 19:21:05 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 19:21:05 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so3007674wiv.11
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 11:21:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=KopJ2v8W8GKNDTwXIVOCRG8G3aqgb/4Dzp2VAGUJ0eM=;
	b=Xqcm5rtrU5qeSql69eRv242iDvn5Z4wepqXWVGJ3fmreeMGz/Yzi2FcThyo+NZ2F8G
	dhVtcr+27pwugPHLdqpexQRkQQDLKJ/8zt6ptBq2Hd8vnggXPtnTAC/zGNqmbjVoBuAv
	rQAFaUbfi3FbUIVGaelWA6rk7EG3XE0j1p6RgvGAuVthD/OEZmA5YhJo2r4UK5hh+mQT
	6TKxUXreH0K8v8g24x22q3Ep951VjEtUmjlME6+wuBg1zl+Imz4JVz8qJmX0VnnceTke
	VLYGwwPtZNER/7R1wN7PcamjA/ov2wi3stKQoHL81+gn1V4KcA8F3EDs2XqfF0EqHBY7
	3L5A==
X-Gm-Message-State: ALoCoQkxUm11hDdRd6/mLwaAQIVAkAPoUin9uXFZLx4zk9CKrj4Zz6IoGs0jZh8prf6P/wgyS+cJ
X-Received: by 10.194.3.45 with SMTP id 13mr49102121wjz.47.1416338465365;
	Tue, 18 Nov 2014 11:21:05 -0800 (PST)
Received: from belegaer.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id
	bc1sm20697769wib.16.2014.11.18.11.21.03 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 11:21:04 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 18 Nov 2014 19:20:36 +0000
Message-Id: <1416338436-3293-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 1.7.10.4
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	Keir Fraser <keir@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [RFC for 4.6] xen: Extend DOMCTL createdomain to
	support arch 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM the virtual GIC may differ between each guest (emulated GIC version,
number of SPIs...). Those informations are already known at the domain creation
and can never change.

For now only the gic_version is set. In long run, there will be more parameters
such as the number of SPIs. All will be required to be set at the same time.

A new arch-specific structure arch_domainconfig has been created, the x86
one doesn't have any specific configuration, a dummy structure
(C-spec compliant) has been created to factorize the code on the toolstack.

Some external tools (qemu, xenstore) may require to create a domain. Rather
than asking them to take care of the arch-specific domain configuration, let
the current function (xc_domain_create) to chose a default configuration and
introduce a new one (xc_domain_create_config).

This patch also drop the previously DOMCTL arm_configure_domain introduced
in Xen 4.5, as it has been made useless.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>

---
    This is a follow-up of http://lists.xen.org/archives/html/xen-devel/2014-11/msg00522.html

    TODO: What about migration? For now the configuration lives in internal
    libxl structure. We need a way to pass the domain configuration to the
    other end.

    I'm not sure if we should care of this right now as migration doesn't
    yet exists on ARM.

    For the xc_domain_create, Stefano S. was looking to drop PV domain
    creation support in QEMU. So maybe I could simply extend xc_domain_create
    and drop the xc_domain_create_config.
---
 tools/flask/policy/policy/modules/xen/xen.if |    2 +-
 tools/libxc/include/xenctrl.h                |   14 ++++----
 tools/libxc/xc_domain.c                      |   46 +++++++++++++++-----------
 tools/libxl/libxl_arch.h                     |    6 ++++
 tools/libxl/libxl_arm.c                      |   28 ++++++++++------
 tools/libxl/libxl_create.c                   |   21 +++++++++---
 tools/libxl/libxl_dm.c                       |    3 +-
 tools/libxl/libxl_dom.c                      |    2 +-
 tools/libxl/libxl_internal.h                 |    7 ++--
 tools/libxl/libxl_x86.c                      |   10 ++++++
 xen/arch/arm/domain.c                        |   28 +++++++++++++++-
 xen/arch/arm/domctl.c                        |   34 -------------------
 xen/arch/arm/mm.c                            |    6 ++--
 xen/arch/arm/setup.c                         |    6 +++-
 xen/arch/x86/domain.c                        |    3 +-
 xen/arch/x86/mm.c                            |    6 ++--
 xen/arch/x86/setup.c                         |    4 ++-
 xen/common/domain.c                          |    6 ++--
 xen/common/domctl.c                          |    3 +-
 xen/common/schedule.c                        |    3 +-
 xen/include/public/arch-arm.h                |    9 +++++
 xen/include/public/arch-x86/xen.h            |    5 +++
 xen/include/public/domctl.h                  |   20 ++---------
 xen/include/xen/domain.h                     |    3 +-
 xen/include/xen/sched.h                      |    8 +++--
 xen/xsm/flask/hooks.c                        |    3 --
 xen/xsm/flask/policy/access_vectors          |    2 --
 27 files changed, 168 insertions(+), 120 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index fa69c9d..641c797 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -49,7 +49,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			getscheduler getvcpuinfo getvcpuextstate getaddrsize
 			getaffinity setaffinity };
-	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
+	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 45e282c..9976ab1 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -477,18 +477,20 @@ typedef union
 } start_info_any_t;
 #endif
 
+
+typedef arch_domainconfig_t xc_domain_configuration_t;
+int xc_domain_create_config(xc_interface *xch,
+                            uint32_t ssidref,
+                            xen_domain_handle_t handle,
+                            uint32_t flags,
+                            uint32_t *pdomid,
+                            xc_domain_configuration_t *config);
 int xc_domain_create(xc_interface *xch,
                      uint32_t ssidref,
                      xen_domain_handle_t handle,
                      uint32_t flags,
                      uint32_t *pdomid);
 
-#if defined(__arm__) || defined(__aarch64__)
-typedef xen_domctl_arm_configuredomain_t xc_domain_configuration_t;
-
-int xc_domain_configure(xc_interface *xch, uint32_t domid,
-                        xc_domain_configuration_t *config);
-#endif
 
 /* Functions to produce a dump of a given domain
  *  xc_domain_dumpcore - produces a dump to a specified file
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index b071dea..a24a156 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -27,11 +27,12 @@
 #include <xen/memory.h>
 #include <xen/hvm/hvm_op.h>
 
-int xc_domain_create(xc_interface *xch,
-                     uint32_t ssidref,
-                     xen_domain_handle_t handle,
-                     uint32_t flags,
-                     uint32_t *pdomid)
+int xc_domain_create_config(xc_interface *xch,
+                            uint32_t ssidref,
+                            xen_domain_handle_t handle,
+                            uint32_t flags,
+                            uint32_t *pdomid,
+                            xc_domain_configuration_t *config)
 {
     int err;
     DECLARE_DOMCTL;
@@ -41,32 +42,39 @@ int xc_domain_create(xc_interface *xch,
     domctl.u.createdomain.ssidref = ssidref;
     domctl.u.createdomain.flags   = flags;
     memcpy(domctl.u.createdomain.handle, handle, sizeof(xen_domain_handle_t));
+    /* xc_domain_configure_t is an alias of arch_domainconfig_t */
+    memcpy(&domctl.u.createdomain.config, config, sizeof(*config));
     if ( (err = do_domctl(xch, &domctl)) != 0 )
         return err;
 
     *pdomid = (uint16_t)domctl.domain;
+    memcpy(config, &domctl.u.createdomain.config, sizeof(*config));
+
     return 0;
 }
 
-#if defined(__arm__) || defined(__aarch64__)
-int xc_domain_configure(xc_interface *xch, uint32_t domid,
-                        xc_domain_configuration_t *config)
+int xc_domain_create(xc_interface *xch,
+                     uint32_t ssidref,
+                     xen_domain_handle_t handle,
+                     uint32_t flags,
+                     uint32_t *pdomid)
 {
-    int rc;
-    DECLARE_DOMCTL;
+    xc_domain_configuration_t config;
 
-    domctl.cmd = XEN_DOMCTL_arm_configure_domain;
-    domctl.domain = (domid_t)domid;
-    /* xc_domain_configure_t is an alias of xen_domctl_arm_configuredomain */
-    memcpy(&domctl.u.configuredomain, config, sizeof(*config));
+    memset(&config, 0, sizeof(config));
 
-    rc = do_domctl(xch, &domctl);
-    if ( !rc )
-        memcpy(config, &domctl.u.configuredomain, sizeof(*config));
+#if defined (__i386) || defined(__x86_64__)
+    /* No arch-specific configuration for now */
+#elif defined (__arm__) || defined(__aarch64__)
+    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
+#else
+    errno = ENOSYS;
+    return -1;
+#endif
 
-    return rc;
+    return xc_domain_create_config(xch, ssidref, handle,
+                                   flags, pdomid, &config);
 }
-#endif
 
 int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
                          xen_pfn_t start_pfn, xen_pfn_t nr_pfns)
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index d3bc136..f806ed1 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -15,6 +15,11 @@
 #ifndef LIBXL_ARCH_H
 #define LIBXL_ARCH_H
 
+/* fill the arch specific configuration for the domain */
+int libxl__arch_domain_prepare_config(libxl__gc *gc,
+                                      libxl_domain_config *d_config,
+                                      xc_domain_configuration_t *xc_config);
+
 /* arch specific internal domain creation function */
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                uint32_t domid);
@@ -22,6 +27,7 @@ int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 /* setup arch specific hardware description, i.e. DTB on ARM */
 int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl_domain_build_info *info,
+                                           libxl__domain_build_state *state,
                                            struct xc_dom_image *dom);
 /* finalize arch specific hardware description. */
 int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 448ac07..50e59ff 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -35,6 +35,15 @@ static const char *gicv_to_string(uint8_t gic_version)
     }
 }
 
+int libxl__arch_domain_prepare_config(libxl__gc *gc,
+                                      libxl_domain_config *d_config,
+                                      xc_domain_configuration_t *xc_config)
+{
+    xc_config->gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
+
+    return 0;
+}
+
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                               uint32_t domid)
 {
@@ -516,9 +525,9 @@ out:
 
 int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl_domain_build_info *info,
+                                           libxl__domain_build_state *state,
                                            struct xc_dom_image *dom)
 {
-    xc_domain_configuration_t config;
     void *fdt = NULL;
     int rc, res;
     size_t fdt_size = 0;
@@ -526,6 +535,9 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
     const libxl_version_info *vers;
     const struct arch_info *ainfo;
 
+    /* convenience aliases */
+    xc_domain_configuration_t *xc_config = &state->config;
+
     assert(info->type == LIBXL_DOMAIN_TYPE_PV);
 
     vers = libxl_get_version_info(CTX);
@@ -534,16 +546,9 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
     ainfo = get_arch_info(gc, dom);
     if (ainfo == NULL) return ERROR_FAIL;
 
-    LOG(DEBUG, "configure the domain");
-    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
-    if (xc_domain_configure(CTX->xch, dom->guest_domid, &config) != 0) {
-        LOG(ERROR, "couldn't configure the domain");
-        return ERROR_FAIL;
-    }
-
     LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
         vers->xen_version_major, vers->xen_version_minor);
-    LOG(DEBUG, "  - vGIC version: %s", gicv_to_string(config.gic_version));
+    LOG(DEBUG, " - vGIC version: %s\n", gicv_to_string(xc_config->gic_version));
 
 /*
  * Call "call" handling FDR_ERR_*. Will either:
@@ -592,7 +597,7 @@ next_resize:
 
         FDT( make_memory_nodes(gc, fdt, dom) );
 
-        switch (config.gic_version) {
+        switch (xc_config->gic_version) {
         case XEN_DOMCTL_CONFIG_GIC_V2:
             FDT( make_gicv2_node(gc, fdt,
                                  GUEST_GICD_BASE, GUEST_GICD_SIZE,
@@ -602,7 +607,8 @@ next_resize:
             FDT( make_gicv3_node(gc, fdt) );
             break;
         default:
-            LOG(ERROR, "Unknown GIC version %d", config.gic_version);
+            LOG(ERROR, "Unknown GIC version %s",
+                gicv_to_string(xc_config->gic_version));
             rc = ERROR_FAIL;
             goto out;
         }
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..15120f8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -487,8 +487,8 @@ out:
     return ret;
 }
 
-int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
-                       uint32_t *domid)
+int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
+                       uint32_t *domid, xc_domain_configuration_t *xc_config)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags, ret, rc, nb_vm;
@@ -501,6 +501,8 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
     xen_domain_handle_t handle;
     libxl_vminfo *vm_list;
 
+    /* convenience aliases */
+    libxl_domain_create_info *info = &d_config->c_info;
 
     assert(!libxl_domid_valid_guest(*domid));
 
@@ -529,7 +531,16 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
     /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
     libxl_uuid_copy(ctx, (libxl_uuid *)handle, &info->uuid);
 
-    ret = xc_domain_create(ctx->xch, info->ssidref, handle, flags, domid);
+    ret = libxl__arch_domain_prepare_config(gc, d_config, xc_config);
+    if (ret < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fail to get domain config");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    ret = xc_domain_create_config(ctx->xch, info->ssidref,
+                                  handle, flags, domid,
+                                  xc_config);
     if (ret < 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "domain creation fail");
         rc = ERROR_FAIL;
@@ -762,9 +773,11 @@ static void initiate_domain_create(libxl__egc *egc,
 
     /* convenience aliases */
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
     const int restore_fd = dcs->restore_fd;
     memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
+
     domid = 0;
 
     if (d_config->c_info.ssid_label) {
@@ -846,7 +859,7 @@ static void initiate_domain_create(libxl__egc *egc,
     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);
+    ret = libxl__domain_make(gc, d_config, &domid, &state->config);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
         dcs->guest_domid = domid;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..17eb926 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1052,7 +1052,8 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
     stubdom_state->pv_ramdisk.path = "";
 
     /* fixme: this function can leak the stubdom if it fails */
-    ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid);
+    ret = libxl__domain_make(gc, dm_config, &sdss->pvqemu.guest_domid,
+                             &stubdom_state->config);
     if (ret)
         goto out;
     uint32_t dm_domid = sdss->pvqemu.guest_domid;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..f468e63 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -583,7 +583,7 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LOGE(ERROR, "xc_dom_parse_image failed");
         goto out;
     }
-    if ( (ret = libxl__arch_domain_init_hw_description(gc, info, dom)) != 0 ) {
+    if ( (ret = libxl__arch_domain_init_hw_description(gc, info, state, dom)) != 0 ) {
         LOGE(ERROR, "libxl__arch_domain_init_hw_description failed");
         goto out;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..d475487 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -971,6 +971,8 @@ typedef struct {
     libxl__file_reference pv_ramdisk;
     const char * pv_cmdline;
     bool pvh_enabled;
+
+    xc_domain_configuration_t config;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
@@ -1460,8 +1462,9 @@ _hidden  void libxl__exec(libxl__gc *gc, int stdinfd, int stdoutfd,
  /* on entry, libxl_domid_valid_guest(domid) must be false;
   * on exit (even error exit), domid may be valid and refer to a domain */
 _hidden int libxl__domain_make(libxl__gc *gc,
-                               libxl_domain_create_info *info,
-                               uint32_t *domid);
+                               libxl_domain_config *d_config,
+                               uint32_t *domid,
+                               xc_domain_configuration_t *xc_config);
 
 _hidden int libxl__domain_build(libxl__gc *gc,
                                 libxl_domain_config *d_config,
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 7589060..e0a0cff 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -1,6 +1,15 @@
 #include "libxl_internal.h"
 #include "libxl_arch.h"
 
+int libxl__arch_domain_prepare_config(libxl__gc *gc,
+                                      libxl_domain_config *d_config,
+                                      xc_domain_configuration_t *xc_config)
+{
+    /* No specific configuration right now */
+
+    return 0;
+}
+
 static const char *e820_names(int type)
 {
     switch (type) {
@@ -313,6 +322,7 @@ int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 
 int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl_domain_build_info *info,
+                                           libxl__domain_build_state *state,
                                            struct xc_dom_image *dom)
 {
     return 0;
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7221bc8..da97730 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -504,9 +504,11 @@ 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)
+int arch_domain_create(struct domain *d, unsigned int domcr_flags,
+                       arch_domainconfig_t *config)
 {
     int rc;
+    uint8_t gic_version;
 
     d->arch.relmem = RELMEM_not_started;
 
@@ -514,6 +516,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( is_idle_domain(d) )
         return 0;
 
+    ASSERT(config != NULL);
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
@@ -534,6 +537,29 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = p2m_alloc_table(d)) != 0 )
         goto fail;
 
+    /*
+     * Currently the vGIC is emulating the same version of the
+     * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
+     * is allowed. The DOMCTL will return the actual version of the
+     * GIC.
+     */
+    rc = -EOPNOTSUPP;
+    if ( config->gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
+        goto fail;
+
+    switch ( gic_hw_version() )
+    {
+    case GIC_V3:
+        gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+        break;
+    case GIC_V2:
+        gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
+        break;
+    default:
+        BUG();
+    }
+    config->gic_version = gic_version;
+
     if ( (rc = gicv_setup(d)) != 0 )
         goto fail;
 
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index d246e84..485d3aa 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -32,40 +32,6 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 
         return p2m_cache_flush(d, s, e);
     }
-    case XEN_DOMCTL_arm_configure_domain:
-    {
-        uint8_t gic_version;
-
-        /*
-         * Currently the vGIC is emulating the same version of the
-         * hardware GIC. Only the value XEN_DOMCTL_CONFIG_GIC_DEFAULT
-         * is allowed. The DOMCTL will return the actual version of the
-         * GIC.
-         */
-        if ( domctl->u.configuredomain.gic_version != XEN_DOMCTL_CONFIG_GIC_DEFAULT )
-            return -EOPNOTSUPP;
-
-        switch ( gic_hw_version() )
-        {
-        case GIC_V3:
-            gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
-            break;
-        case GIC_V2:
-            gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
-            break;
-        default:
-            BUG();
-        }
-
-        domctl->u.configuredomain.gic_version = gic_version;
-
-        /* TODO: Make the copy generic for all ARCH domctl */
-        if ( __copy_to_guest(u_domctl, domctl, 1) )
-            return -EFAULT;
-
-        return 0;
-    }
-
     default:
         return subarch_do_domctl(domctl, d, u_domctl);
     }
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index ca0aa69..903e5ae 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -399,7 +399,7 @@ void __init arch_init_memory(void)
      * Any Xen-heap pages that we will allow to be mapped will have
      * their domain field set to dom_xen.
      */
-    dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0);
+    dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_xen));
 
     /*
@@ -407,14 +407,14 @@ void __init arch_init_memory(void)
      * This domain owns I/O pages that are within the range of the page_info
      * array. Mappings occur at the priv of the caller.
      */
-    dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0);
+    dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_io));
 
     /*
      * Initialise our COW domain.
      * This domain owns sharable pages.
      */
-    dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0);
+    dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_cow));
 }
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 67fd9c9..1547d8a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -697,6 +697,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     const char *cmdline;
     struct bootmodule *xen_bootmodule;
     struct domain *dom0;
+    struct arch_domainconfig config;
 
     setup_cache();
 
@@ -811,7 +812,10 @@ void __init start_xen(unsigned long boot_phys_offset,
     do_initcalls();
 
     /* Create initial domain 0. */
-    dom0 = domain_create(0, 0, 0);
+    /* Emulate the same version as the hardware GIC */
+    config.gic_version = XEN_DOMCTL_CONFIG_GIC_DEFAULT;
+
+    dom0 = domain_create(0, 0, 0, &config);
     if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
             panic("Error creating domain 0");
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 73d01bb..ffffe4c 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -514,7 +514,8 @@ void vcpu_destroy(struct vcpu *v)
         xfree(v->arch.pv_vcpu.trap_ctxt);
 }
 
-int arch_domain_create(struct domain *d, unsigned int domcr_flags)
+int arch_domain_create(struct domain *d, unsigned int domcr_flags,
+                       arch_domainconfig_t *config)
 {
     int i, paging_initialised = 0;
     int rc = -ENOMEM;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 8ee9938..523596d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -275,7 +275,7 @@ void __init arch_init_memory(void)
      * Hidden PCI devices will also be associated with this domain
      * (but be [partly] controlled by Dom0 nevertheless).
      */
-    dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0);
+    dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_xen));
     INIT_LIST_HEAD(&dom_xen->arch.pdev_list);
 
@@ -284,14 +284,14 @@ void __init arch_init_memory(void)
      * This domain owns I/O pages that are within the range of the page_info
      * array. Mappings occur at the priv of the caller.
      */
-    dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0);
+    dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_io));
     
     /*
      * Initialise our COW domain.
      * This domain owns sharable pages.
      */
-    dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0);
+    dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0, NULL);
     BUG_ON(IS_ERR(dom_cow));
 
     /* First 1MB of RAM is historically marked as I/O. */
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 73e95c6..3cc24f0 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -540,6 +540,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     int i, j, e820_warn = 0, bytes = 0;
     bool_t acpi_boot_table_init_done = 0;
     struct domain *dom0;
+    struct arch_domainconfig config;
     struct ns16550_defaults ns16550 = {
         .data_bits = 8,
         .parity    = 'n',
@@ -1347,7 +1348,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
         domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
 
     /* Create initial domain 0. */
-    dom0 = domain_create(0, domcr_flags, 0);
+    memset(&config, 0, sizeof(config));
+    dom0 = domain_create(0, domcr_flags, 0, &config);
     if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
         panic("Error creating domain 0");
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 4a62c1d..bd118ec 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -242,8 +242,8 @@ static void __init parse_extra_guest_irqs(const char *s)
 }
 custom_param("extra_guest_irqs", parse_extra_guest_irqs);
 
-struct domain *domain_create(
-    domid_t domid, unsigned int domcr_flags, uint32_t ssidref)
+struct domain *domain_create(domid_t domid, unsigned int domcr_flags,
+                             uint32_t ssidref, arch_domainconfig_t *config)
 {
     struct domain *d, **pd, *old_hwdom = NULL;
     enum { INIT_xsm = 1u<<0, INIT_watchdog = 1u<<1, INIT_rangeset = 1u<<2,
@@ -352,7 +352,7 @@ struct domain *domain_create(
             goto fail;
     }
 
-    if ( (err = arch_domain_create(d, domcr_flags)) != 0 )
+    if ( (err = arch_domain_create(d, domcr_flags, config)) != 0 )
         goto fail;
     init_status |= INIT_arch;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d9c2635..c7b68c6 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -583,7 +583,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
             domcr_flags |= DOMCRF_oos_off;
 
-        d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref);
+        d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref,
+                          &op->u.createdomain.config);
         if ( IS_ERR(d) )
         {
             ret = PTR_ERR(d);
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 6285a6e..ab2561a 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1421,7 +1421,8 @@ void __init scheduler_init(void)
         sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
     }
 
-    idle_domain = domain_create(DOMID_IDLE, 0, 0);
+    /* There is no need of arch-specific configuration for an idle domain */
+    idle_domain = domain_create(DOMID_IDLE, 0, 0, NULL);
     BUG_ON(IS_ERR(idle_domain));
     idle_domain->vcpu = idle_vcpu;
     idle_domain->max_vcpus = nr_cpu_ids;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 72d641f..9c53294 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -314,6 +314,15 @@ struct arch_shared_info {
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
+#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
+#define XEN_DOMCTL_CONFIG_GIC_V2        1
+#define XEN_DOMCTL_CONFIG_GIC_V3        2
+struct arch_domainconfig {
+    /* IN/OUT */
+    uint8_t gic_version;
+};
+typedef struct arch_domainconfig arch_domainconfig_t;
+
 #endif
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index f35804b..5b1c678 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -228,6 +228,11 @@ struct arch_shared_info {
 };
 typedef struct arch_shared_info arch_shared_info_t;
 
+struct arch_domainconfig {
+    char dummy;
+};
+typedef struct arch_domainconfig arch_domainconfig_t;
+
 #endif /* !__ASSEMBLY__ */
 
 /*
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 8da204e..5ac41f6 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -39,7 +39,7 @@
 
 #define XEN_DOMCTL_INTERFACE_VERSION 0x0000000a
 
-/*
+/* 
  * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
  * If it is specified as zero, an id is auto-allocated and returned.
  */
@@ -64,23 +64,11 @@ struct xen_domctl_createdomain {
 #define _XEN_DOMCTL_CDF_pvh_guest     4
 #define XEN_DOMCTL_CDF_pvh_guest      (1U<<_XEN_DOMCTL_CDF_pvh_guest)
     uint32_t flags;
+    struct arch_domainconfig config;
 };
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
 
-#if defined(__arm__) || defined(__aarch64__)
-#define XEN_DOMCTL_CONFIG_GIC_DEFAULT   0
-#define XEN_DOMCTL_CONFIG_GIC_V2        1
-#define XEN_DOMCTL_CONFIG_GIC_V3        2
-/* XEN_DOMCTL_configure_domain */
-struct xen_domctl_arm_configuredomain {
-    /* IN/OUT parameters */
-    uint8_t gic_version;
-};
-typedef struct xen_domctl_arm_configuredomain xen_domctl_arm_configuredomain_t;
-DEFINE_XEN_GUEST_HANDLE(xen_domctl_arm_configuredomain_t);
-#endif
-
 /* XEN_DOMCTL_getdomaininfo */
 struct xen_domctl_getdomaininfo {
     /* OUT variables. */
@@ -1069,7 +1057,6 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_vcpu_msrs                 73
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
-#define XEN_DOMCTL_arm_configure_domain          76
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1078,9 +1065,6 @@ struct xen_domctl {
     domid_t  domain;
     union {
         struct xen_domctl_createdomain      createdomain;
-#if defined(__arm__) || defined(__aarch64__)
-        struct xen_domctl_arm_configuredomain configuredomain;
-#endif
         struct xen_domctl_getdomaininfo     getdomaininfo;
         struct xen_domctl_getmemlist        getmemlist;
         struct xen_domctl_getpageframeinfo  getpageframeinfo;
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 9215b0e..6918cc2 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -55,7 +55,8 @@ void vcpu_destroy(struct vcpu *v);
 int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset);
 void unmap_vcpu_info(struct vcpu *v);
 
-int arch_domain_create(struct domain *d, unsigned int domcr_flags);
+int arch_domain_create(struct domain *d, unsigned int domcr_flags,
+                       arch_domainconfig_t *config);
 
 void arch_domain_destroy(struct domain *d);
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 46fc6e3..95a464c 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -525,8 +525,12 @@ static inline void get_knownalive_domain(struct domain *d)
 int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity);
 void domain_update_node_affinity(struct domain *d);
 
-struct domain *domain_create(
-    domid_t domid, unsigned int domcr_flags, uint32_t ssidref);
+/*
+ * Create a domain: the configuration is only necessary for real domain
+ * (i.e !DOMCRF_dummy, excluded idle domain)
+ */
+struct domain *domain_create(domid_t domid, unsigned int domcr_flags,
+                             uint32_t ssidref, arch_domainconfig_t *config);
  /* DOMCRF_hvm: Create an HVM domain, as opposed to a PV domain. */
 #define _DOMCRF_hvm           0
 #define DOMCRF_hvm            (1U<<_DOMCRF_hvm)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0ba2ce9..6d0fe72 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -727,9 +727,6 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_psr_cmt_op:
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
 
-    case XEN_DOMCTL_arm_configure_domain:
-        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
-
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
         return -EPERM;
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1cd451e..b6d0cbe 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -216,8 +216,6 @@ class domain2
     get_vnumainfo
 # XEN_DOMCTL_psr_cmt_op
     psr_cmt_op
-# XEN_DOMCTL_configure_domain
-    configure_domain
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 19:54:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 19: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 1XqoqP-0004gK-Pu; Tue, 18 Nov 2014 19:53:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <timwood@email.gwu.edu>) id 1Xqonx-0004dU-RC
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 19:51:14 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	97/A5-05632-133AB645; Tue, 18 Nov 2014 19:51:13 +0000
X-Env-Sender: timwood@email.gwu.edu
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416340270!12259567!1
X-Originating-IP: [74.125.150.94]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1989 invoked from network); 18 Nov 2014 19:51:11 -0000
Received: from na6sys009bog027.obsmtp.com (HELO na6sys009bog027.obsmtp.com)
	(74.125.150.94)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 19:51:11 -0000
Received: from mail-qc0-f178.google.com ([209.85.216.178]) (using TLSv1) by
	na6sys009bob027.postini.com ([74.125.148.12]) with SMTP
	ID DSNKVGujLnykmUcoxz2MkOUFG4gE5nOGgT7n@postini.com;
	Tue, 18 Nov 2014 11:51:11 PST
Received: by mail-qc0-f178.google.com with SMTP id b13so21142179qcw.9
	for <xen-devel@lists.xensource.com>;
	Tue, 18 Nov 2014 11:51:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:reply-to:in-reply-to:references
	:from:date:message-id:subject:to:cc:content-type;
	bh=ZaNfzt3GK9hMgNwiCkOUe20OXg+ZSkOWIWatvVxcxwI=;
	b=lXpjWyIQlYxuYHeKN1Fg6hqnzxVg1KrU0SYf+cLwI8Gsjq821vq2vT2giS6cCyD9t1
	GIxzz08irAWcDCsz4N1aaLlFKIj6cFTmszNSKGVEd8JeOVHcLteq/SFG/o6nzuKLwm7M
	/5O3m5rkisa2tSjZXCzbkoIRYtY38fku0rOT692ryaZI/92tk76WzU6L7z/bXmIvSNAS
	fISEmSx6fpIlqhla4LxH4Iy11ta6FRdfXLx1iy0wBpwqOQVhpDPoWy9f1zjkbujCh4Z3
	iUiPdnJzOVL9qoF4m8ZNtK2M6SLEZNaF9hNibxQZLpJWny8CdS9/ORiNik0hHCx907F2
	fzXA==
X-Gm-Message-State: ALoCoQnDmDfcQcJsJTq0XXojXqKLT2S40t+Hus3R2SCwYBWqz7fFmKyx0XK+dpPdS+HAqzz2Vt3klOlc6pammC1KK/5u1ZD636Z/hxocBWbYs9gCyqGL64eJqQiAivalFfA9UOk5wQ4mS43Gc2WpGSwBXVrD1olYqA==
X-Received: by 10.229.203.9 with SMTP id fg9mr35189119qcb.20.1416340269153;
	Tue, 18 Nov 2014 11:51:09 -0800 (PST)
X-Received: by 10.229.203.9 with SMTP id fg9mr35189106qcb.20.1416340269025;
	Tue, 18 Nov 2014 11:51:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.207.135 with HTTP; Tue, 18 Nov 2014 11:50:38 -0800 (PST)
In-Reply-To: <1416220487.27385.22.camel@citrix.com>
References: <CABm+uF9cqpdqrjbwj3WUaeZXPZsNkCVHdL_=m4xh9MMxKQduUg@mail.gmail.com>
	<1416220487.27385.22.camel@citrix.com>
From: Timothy Wood <timwood@gwu.edu>
Date: Tue, 18 Nov 2014 14:50:38 -0500
Message-ID: <CAC8jeWMffRsnj0u4Ro_gBOV5ZsY+tS7hp-bZneE9NfgCRDR9iQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Tue, 18 Nov 2014 19:53:44 +0000
Cc: Xen devel list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] support for sharing huge pages with grant table?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: timwood@gwu.edu
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7876591610761347090=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7876591610761347090==
Content-Type: multipart/alternative; boundary=001a11c2f62e9dfa760508276adb

--001a11c2f62e9dfa760508276adb
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 17, 2014 at 5:34 AM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wrote:
> > Hi,
> >
> > I am curious if Xen currently supports sharing hugepages between
> > domains (specifically ones originally allocated in Dom-0 and shared
> > with a guest r/w).  I've seen some references to huge pages in the
> > archives of this list, but not in relation to the grant mechanism.
>
> I don't think the grant table has any specific superpage support. It
> might be an interesting extension to consider though (for the sorts of
> reasons you would like it).
>
> You could grant a superpage using multiple 4K grants to cover whichever
> subset of the superpage you need to expose to the other end. Now granted
> (no pun intended ;-)) that might suck up 512 grefs in the worst case,
> which is a bit mad...
>

If the grants just need to be setup once at system startup and then are
never changed, is this likely to pose any particular problem (i.e., does
the size of the grant table only affect things when new grants are being
setup, or is it checked regularly at runtime)?


>
> > Also, can someone confirm that "superpages" are another term for "huge
> > pages" in Xen?
>
> Yes. Or at least I think so.
>
> > This would be helpful for some work we are doing on high speed
> > networking to VMs---DPDK stores packets into huge pages and we'd like
> > to get those to VMs as quickly as possible.
>
> This seems like a reasonable usecase to me. Having added this to the
> grant table interface I suppose you would also need to consider
> extensions to the individual PV I/O protocols (netif.h) to allow them to
> signal when a grant was huge. You might have issues with e.g. finding
> enough bits to represent the larger sizes...
>

I hope you guys will think it is useful enough to someday implement it..
I've got a handful of undergrad and grad students who work with me, but
this might be beyond our capabilities at this point ;)

In our prior system, we did this on KVM.  In that case we used QEMU to
define a virtual PCI device that mapped memory from the host OS and let it
be accessed by a VM.  Any thoughts on whether the same approach would work
with Xen?  I'd originally thought just using the grant table to enable
sharing would make this a lot easier in Xen, but maybe not since it doesn't
support huge pages.

thanks!

--001a11c2f62e9dfa760508276adb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div><div class=3D"gmail_signat=
ure">On Mon, Nov 17, 2014 at 5:34 AM, Ian Campbell <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@cit=
rix.com</a>&gt;</span> wrote:<br></div></div><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wro=
te:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I am curious if Xen currently supports sharing hugepages between<br>
&gt; domains (specifically ones originally allocated in Dom-0 and shared<br=
>
&gt; with a guest r/w).=C2=A0 I&#39;ve seen some references to huge pages i=
n the<br>
&gt; archives of this list, but not in relation to the grant mechanism.<br>
<br>
I don&#39;t think the grant table has any specific superpage support. It<br=
>
might be an interesting extension to consider though (for the sorts of<br>
reasons you would like it).<br>
<br>
You could grant a superpage using multiple 4K grants to cover whichever<br>
subset of the superpage you need to expose to the other end. Now granted<br=
>
(no pun intended ;-)) that might suck up 512 grefs in the worst case,<br>
which is a bit mad...<br></blockquote><div><br></div><div>If the grants jus=
t need to be setup once at system startup and then are never changed, is th=
is likely to pose any particular problem (i.e., does the size of the grant =
table only affect things when new grants are being setup, or is it checked =
regularly at runtime)?</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<br>
&gt; Also, can someone confirm that &quot;superpages&quot; are another term=
 for &quot;huge<br>
&gt; pages&quot; in Xen?<br>
<br>
Yes. Or at least I think so.<br>
<br>
&gt; This would be helpful for some work we are doing on high speed<br>
&gt; networking to VMs---DPDK stores packets into huge pages and we&#39;d l=
ike<br>
&gt; to get those to VMs as quickly as possible.<br>
<br>
This seems like a reasonable usecase to me. Having added this to the<br>
grant table interface I suppose you would also need to consider<br>
extensions to the individual PV I/O protocols (netif.h) to allow them to<br=
>
signal when a grant was huge. You might have issues with e.g. finding<br>
enough bits to represent the larger sizes...<br></blockquote><div><br></div=
><div>I hope you guys will think it is useful enough to someday implement i=
t.. I&#39;ve got a handful of undergrad and grad students who work with me,=
 but this might be beyond our capabilities at this point ;)</div><div><br><=
/div><div>In our prior system, we did this on KVM.=C2=A0 In that case we us=
ed QEMU to define a virtual PCI device that mapped memory from the host OS =
and let it be accessed by a VM.=C2=A0 Any thoughts on whether the same appr=
oach would work with Xen?=C2=A0 I&#39;d originally thought just using the g=
rant table to enable sharing would make this a lot easier in Xen, but maybe=
 not since it doesn&#39;t support huge pages.</div><div><br></div><div>than=
ks!</div><div><br></div></div></div></div>

--001a11c2f62e9dfa760508276adb--


--===============7876591610761347090==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7876591610761347090==--


From xen-devel-bounces@lists.xen.org Tue Nov 18 19:54:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 19: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 1XqoqP-0004gK-Pu; Tue, 18 Nov 2014 19:53:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <timwood@email.gwu.edu>) id 1Xqonx-0004dU-RC
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 19:51:14 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	97/A5-05632-133AB645; Tue, 18 Nov 2014 19:51:13 +0000
X-Env-Sender: timwood@email.gwu.edu
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416340270!12259567!1
X-Originating-IP: [74.125.150.94]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1989 invoked from network); 18 Nov 2014 19:51:11 -0000
Received: from na6sys009bog027.obsmtp.com (HELO na6sys009bog027.obsmtp.com)
	(74.125.150.94)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 19:51:11 -0000
Received: from mail-qc0-f178.google.com ([209.85.216.178]) (using TLSv1) by
	na6sys009bob027.postini.com ([74.125.148.12]) with SMTP
	ID DSNKVGujLnykmUcoxz2MkOUFG4gE5nOGgT7n@postini.com;
	Tue, 18 Nov 2014 11:51:11 PST
Received: by mail-qc0-f178.google.com with SMTP id b13so21142179qcw.9
	for <xen-devel@lists.xensource.com>;
	Tue, 18 Nov 2014 11:51:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:reply-to:in-reply-to:references
	:from:date:message-id:subject:to:cc:content-type;
	bh=ZaNfzt3GK9hMgNwiCkOUe20OXg+ZSkOWIWatvVxcxwI=;
	b=lXpjWyIQlYxuYHeKN1Fg6hqnzxVg1KrU0SYf+cLwI8Gsjq821vq2vT2giS6cCyD9t1
	GIxzz08irAWcDCsz4N1aaLlFKIj6cFTmszNSKGVEd8JeOVHcLteq/SFG/o6nzuKLwm7M
	/5O3m5rkisa2tSjZXCzbkoIRYtY38fku0rOT692ryaZI/92tk76WzU6L7z/bXmIvSNAS
	fISEmSx6fpIlqhla4LxH4Iy11ta6FRdfXLx1iy0wBpwqOQVhpDPoWy9f1zjkbujCh4Z3
	iUiPdnJzOVL9qoF4m8ZNtK2M6SLEZNaF9hNibxQZLpJWny8CdS9/ORiNik0hHCx907F2
	fzXA==
X-Gm-Message-State: ALoCoQnDmDfcQcJsJTq0XXojXqKLT2S40t+Hus3R2SCwYBWqz7fFmKyx0XK+dpPdS+HAqzz2Vt3klOlc6pammC1KK/5u1ZD636Z/hxocBWbYs9gCyqGL64eJqQiAivalFfA9UOk5wQ4mS43Gc2WpGSwBXVrD1olYqA==
X-Received: by 10.229.203.9 with SMTP id fg9mr35189119qcb.20.1416340269153;
	Tue, 18 Nov 2014 11:51:09 -0800 (PST)
X-Received: by 10.229.203.9 with SMTP id fg9mr35189106qcb.20.1416340269025;
	Tue, 18 Nov 2014 11:51:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.207.135 with HTTP; Tue, 18 Nov 2014 11:50:38 -0800 (PST)
In-Reply-To: <1416220487.27385.22.camel@citrix.com>
References: <CABm+uF9cqpdqrjbwj3WUaeZXPZsNkCVHdL_=m4xh9MMxKQduUg@mail.gmail.com>
	<1416220487.27385.22.camel@citrix.com>
From: Timothy Wood <timwood@gwu.edu>
Date: Tue, 18 Nov 2014 14:50:38 -0500
Message-ID: <CAC8jeWMffRsnj0u4Ro_gBOV5ZsY+tS7hp-bZneE9NfgCRDR9iQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Tue, 18 Nov 2014 19:53:44 +0000
Cc: Xen devel list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] support for sharing huge pages with grant table?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: timwood@gwu.edu
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7876591610761347090=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7876591610761347090==
Content-Type: multipart/alternative; boundary=001a11c2f62e9dfa760508276adb

--001a11c2f62e9dfa760508276adb
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 17, 2014 at 5:34 AM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wrote:
> > Hi,
> >
> > I am curious if Xen currently supports sharing hugepages between
> > domains (specifically ones originally allocated in Dom-0 and shared
> > with a guest r/w).  I've seen some references to huge pages in the
> > archives of this list, but not in relation to the grant mechanism.
>
> I don't think the grant table has any specific superpage support. It
> might be an interesting extension to consider though (for the sorts of
> reasons you would like it).
>
> You could grant a superpage using multiple 4K grants to cover whichever
> subset of the superpage you need to expose to the other end. Now granted
> (no pun intended ;-)) that might suck up 512 grefs in the worst case,
> which is a bit mad...
>

If the grants just need to be setup once at system startup and then are
never changed, is this likely to pose any particular problem (i.e., does
the size of the grant table only affect things when new grants are being
setup, or is it checked regularly at runtime)?


>
> > Also, can someone confirm that "superpages" are another term for "huge
> > pages" in Xen?
>
> Yes. Or at least I think so.
>
> > This would be helpful for some work we are doing on high speed
> > networking to VMs---DPDK stores packets into huge pages and we'd like
> > to get those to VMs as quickly as possible.
>
> This seems like a reasonable usecase to me. Having added this to the
> grant table interface I suppose you would also need to consider
> extensions to the individual PV I/O protocols (netif.h) to allow them to
> signal when a grant was huge. You might have issues with e.g. finding
> enough bits to represent the larger sizes...
>

I hope you guys will think it is useful enough to someday implement it..
I've got a handful of undergrad and grad students who work with me, but
this might be beyond our capabilities at this point ;)

In our prior system, we did this on KVM.  In that case we used QEMU to
define a virtual PCI device that mapped memory from the host OS and let it
be accessed by a VM.  Any thoughts on whether the same approach would work
with Xen?  I'd originally thought just using the grant table to enable
sharing would make this a lot easier in Xen, but maybe not since it doesn't
support huge pages.

thanks!

--001a11c2f62e9dfa760508276adb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div><div class=3D"gmail_signat=
ure">On Mon, Nov 17, 2014 at 5:34 AM, Ian Campbell <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@cit=
rix.com</a>&gt;</span> wrote:<br></div></div><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wro=
te:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I am curious if Xen currently supports sharing hugepages between<br>
&gt; domains (specifically ones originally allocated in Dom-0 and shared<br=
>
&gt; with a guest r/w).=C2=A0 I&#39;ve seen some references to huge pages i=
n the<br>
&gt; archives of this list, but not in relation to the grant mechanism.<br>
<br>
I don&#39;t think the grant table has any specific superpage support. It<br=
>
might be an interesting extension to consider though (for the sorts of<br>
reasons you would like it).<br>
<br>
You could grant a superpage using multiple 4K grants to cover whichever<br>
subset of the superpage you need to expose to the other end. Now granted<br=
>
(no pun intended ;-)) that might suck up 512 grefs in the worst case,<br>
which is a bit mad...<br></blockquote><div><br></div><div>If the grants jus=
t need to be setup once at system startup and then are never changed, is th=
is likely to pose any particular problem (i.e., does the size of the grant =
table only affect things when new grants are being setup, or is it checked =
regularly at runtime)?</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<br>
&gt; Also, can someone confirm that &quot;superpages&quot; are another term=
 for &quot;huge<br>
&gt; pages&quot; in Xen?<br>
<br>
Yes. Or at least I think so.<br>
<br>
&gt; This would be helpful for some work we are doing on high speed<br>
&gt; networking to VMs---DPDK stores packets into huge pages and we&#39;d l=
ike<br>
&gt; to get those to VMs as quickly as possible.<br>
<br>
This seems like a reasonable usecase to me. Having added this to the<br>
grant table interface I suppose you would also need to consider<br>
extensions to the individual PV I/O protocols (netif.h) to allow them to<br=
>
signal when a grant was huge. You might have issues with e.g. finding<br>
enough bits to represent the larger sizes...<br></blockquote><div><br></div=
><div>I hope you guys will think it is useful enough to someday implement i=
t.. I&#39;ve got a handful of undergrad and grad students who work with me,=
 but this might be beyond our capabilities at this point ;)</div><div><br><=
/div><div>In our prior system, we did this on KVM.=C2=A0 In that case we us=
ed QEMU to define a virtual PCI device that mapped memory from the host OS =
and let it be accessed by a VM.=C2=A0 Any thoughts on whether the same appr=
oach would work with Xen?=C2=A0 I&#39;d originally thought just using the g=
rant table to enable sharing would make this a lot easier in Xen, but maybe=
 not since it doesn&#39;t support huge pages.</div><div><br></div><div>than=
ks!</div><div><br></div></div></div></div>

--001a11c2f62e9dfa760508276adb--


--===============7876591610761347090==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7876591610761347090==--


From xen-devel-bounces@lists.xen.org Tue Nov 18 20:04:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 20:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqp0P-00057r-CB; Tue, 18 Nov 2014 20:04:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xqp0O-00057m-EV
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 20:04:04 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	9D/BE-29352-336AB645; Tue, 18 Nov 2014 20:04:03 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416341042!12115700!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7583 invoked from network); 18 Nov 2014 20:04:03 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 20:04:03 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so3142154wid.3
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 12:04:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=GcUVmlPKktA8MqsNMGZQpWlyEahnhjmA5P/oCXrK/UI=;
	b=Dxet9LhhfrK/y5uGaEzk0Rke3cFAL06YLFEAz31EUnc3VfI8fHcNO9TsOVaaBMJGVz
	TtMVjeqkx9hRCh5OMEi8UCSBmjF080V5OpiOEnZ8OnYbyUhnfV5KFYqYnSFSlMGgOQ/j
	ARMHFwnWVBeWOgFRlv/Em9GElLRpB37yM9qksjWyjMcqEx33OF4GxzeoiIrpwHQula/y
	ZXOSriFRejXFZmsGRp5TkGkB4R243DlxrUILvIYgmbakIZ5O9Fkr42ShUvW6IjCdQiFT
	BWFFZbRf0sLsg8Wxi7IoCpNDjLwmmJTBoRLnm5lPRv5JxtMiMRP5y/inC9PDPfisfUvW
	J1Ww==
X-Gm-Message-State: ALoCoQn63zosMte3sGgEpPr772A6FZaz/Gshde8p612+TRrk1+HkoS3rjB1y3dz4IxAhh30QWa62
X-Received: by 10.194.184.199 with SMTP id ew7mr51939056wjc.85.1416341042402; 
	Tue, 18 Nov 2014 12:04:02 -0800 (PST)
Received: from belegaer.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id
	l10sm20816585wif.20.2014.11.18.12.04.00 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 12:04:01 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 18 Nov 2014 20:03:51 +0000
Message-Id: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 1.7.10.4
Cc: Julien Grall <julien.grall@linaro.org>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, Don Slutz <dslutz@verizon.com>
Subject: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl: Correctly CC
	the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

By default, the script get_maintainer.pl will remove duplicates email as soon
as it appends the list of maintainers of a new file, and therefore override
the role of the developper.

On complex patch (see [1]), this will result to ommitting randomly some
maintainers.

This could be fixed by not removing the duplicate email in the list. Once the
list is created, when it's necessary, the script will drop the "REST" people
and remove duplicata.

Example:

Patch: https://patches.linaro.org/41083/

Before:

Daniel De Graaf <dgdegra@tycho.nsa.gov>
Ian Jackson <ian.jackson@eu.citrix.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Wei Liu <wei.liu2@citrix.com>
George Dunlap <george.dunlap@eu.citrix.com>
xen-devel@lists.xen.org

After:

Daniel De Graaf <dgdegra@tycho.nsa.gov>
Ian Jackson <ian.jackson@eu.citrix.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Wei Liu <wei.liu2@citrix.com>
Stefano Stabellini <stefano.stabellini@citrix.com>
Tim Deegan <tim@xen.org>
Keir Fraser <keir@xen.org>
Jan Beulich <jbeulich@suse.com>
George Dunlap <george.dunlap@eu.citrix.com>
xen-devel@lists.xen.org

[1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html

Signed-off-by: Julien Grall <julien.grall@linaro.org>
CC: Don Slutz <dslutz@verizon.com>

---
    I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
    time the script has been introduced).

    Developpers using this script won't ommitted to cc some maintainers, and it
    will avoid maintainers complaining about miss CC.

    The only drawbacks I can see is there is too much people CCed (the
    patch d67738db was intended to avoid CCing Keir too often).

    Also, if the maintainers is referenced twice in the file MAINTAINERS with
    different email, the script won't notice it's duplicated and list 2 times.
    Though, for this one it could be fixed by modifying  the MAINTAINERS file.
    Is it worth for Xen 4.5? For know, it seems to only happen with Stefano.
---
 scripts/get_maintainer.pl |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index df920e2..cc445cd 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -35,7 +35,7 @@ my $email_git_min_percent = 5;
 my $email_git_since = "1-year-ago";
 my $email_hg_since = "-365";
 my $interactive = 0;
-my $email_remove_duplicates = 1;
+my $email_remove_duplicates = 0;
 my $email_use_mailmap = 1;
 my $email_drop_the_rest_supporter_if_supporter_found = 1;
 my $output_multiline = 1;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 20:04:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 20:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqp0P-00057r-CB; Tue, 18 Nov 2014 20:04:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xqp0O-00057m-EV
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 20:04:04 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	9D/BE-29352-336AB645; Tue, 18 Nov 2014 20:04:03 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416341042!12115700!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7583 invoked from network); 18 Nov 2014 20:04:03 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 20:04:03 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so3142154wid.3
	for <xen-devel@lists.xenproject.org>;
	Tue, 18 Nov 2014 12:04:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=GcUVmlPKktA8MqsNMGZQpWlyEahnhjmA5P/oCXrK/UI=;
	b=Dxet9LhhfrK/y5uGaEzk0Rke3cFAL06YLFEAz31EUnc3VfI8fHcNO9TsOVaaBMJGVz
	TtMVjeqkx9hRCh5OMEi8UCSBmjF080V5OpiOEnZ8OnYbyUhnfV5KFYqYnSFSlMGgOQ/j
	ARMHFwnWVBeWOgFRlv/Em9GElLRpB37yM9qksjWyjMcqEx33OF4GxzeoiIrpwHQula/y
	ZXOSriFRejXFZmsGRp5TkGkB4R243DlxrUILvIYgmbakIZ5O9Fkr42ShUvW6IjCdQiFT
	BWFFZbRf0sLsg8Wxi7IoCpNDjLwmmJTBoRLnm5lPRv5JxtMiMRP5y/inC9PDPfisfUvW
	J1Ww==
X-Gm-Message-State: ALoCoQn63zosMte3sGgEpPr772A6FZaz/Gshde8p612+TRrk1+HkoS3rjB1y3dz4IxAhh30QWa62
X-Received: by 10.194.184.199 with SMTP id ew7mr51939056wjc.85.1416341042402; 
	Tue, 18 Nov 2014 12:04:02 -0800 (PST)
Received: from belegaer.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id
	l10sm20816585wif.20.2014.11.18.12.04.00 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 12:04:01 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 18 Nov 2014 20:03:51 +0000
Message-Id: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 1.7.10.4
Cc: Julien Grall <julien.grall@linaro.org>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, Don Slutz <dslutz@verizon.com>
Subject: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl: Correctly CC
	the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

By default, the script get_maintainer.pl will remove duplicates email as soon
as it appends the list of maintainers of a new file, and therefore override
the role of the developper.

On complex patch (see [1]), this will result to ommitting randomly some
maintainers.

This could be fixed by not removing the duplicate email in the list. Once the
list is created, when it's necessary, the script will drop the "REST" people
and remove duplicata.

Example:

Patch: https://patches.linaro.org/41083/

Before:

Daniel De Graaf <dgdegra@tycho.nsa.gov>
Ian Jackson <ian.jackson@eu.citrix.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Wei Liu <wei.liu2@citrix.com>
George Dunlap <george.dunlap@eu.citrix.com>
xen-devel@lists.xen.org

After:

Daniel De Graaf <dgdegra@tycho.nsa.gov>
Ian Jackson <ian.jackson@eu.citrix.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Wei Liu <wei.liu2@citrix.com>
Stefano Stabellini <stefano.stabellini@citrix.com>
Tim Deegan <tim@xen.org>
Keir Fraser <keir@xen.org>
Jan Beulich <jbeulich@suse.com>
George Dunlap <george.dunlap@eu.citrix.com>
xen-devel@lists.xen.org

[1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html

Signed-off-by: Julien Grall <julien.grall@linaro.org>
CC: Don Slutz <dslutz@verizon.com>

---
    I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
    time the script has been introduced).

    Developpers using this script won't ommitted to cc some maintainers, and it
    will avoid maintainers complaining about miss CC.

    The only drawbacks I can see is there is too much people CCed (the
    patch d67738db was intended to avoid CCing Keir too often).

    Also, if the maintainers is referenced twice in the file MAINTAINERS with
    different email, the script won't notice it's duplicated and list 2 times.
    Though, for this one it could be fixed by modifying  the MAINTAINERS file.
    Is it worth for Xen 4.5? For know, it seems to only happen with Stefano.
---
 scripts/get_maintainer.pl |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index df920e2..cc445cd 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -35,7 +35,7 @@ my $email_git_min_percent = 5;
 my $email_git_since = "1-year-ago";
 my $email_hg_since = "-365";
 my $interactive = 0;
-my $email_remove_duplicates = 1;
+my $email_remove_duplicates = 0;
 my $email_use_mailmap = 1;
 my $email_drop_the_rest_supporter_if_supporter_found = 1;
 my $output_multiline = 1;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 20:34:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 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.xen.org>)
	id 1XqpTu-0005hq-1U; Tue, 18 Nov 2014 20:34:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqpTs-0005hl-Tf
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 20:34:33 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	EE/96-09936-85DAB645; Tue, 18 Nov 2014 20:34:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416342869!13707772!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13566 invoked from network); 18 Nov 2014 20:34:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 20:34:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIKYHkW030103
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Nov 2014 20:34:18 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAIKYFMi019439
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 18 Nov 2014 20:34:16 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIKYFkM015591; Tue, 18 Nov 2014 20:34:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 12:34:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BDAEA117BAA; Tue, 18 Nov 2014 15:34:12 -0500 (EST)
Date: Tue, 18 Nov 2014 15:34:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141118203412.GA6540@laptop.dumpdata.com>
References: <20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<546B8DFC0200007800048E21@mail.emea.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg"
Content-Disposition: inline
In-Reply-To: <546B8DFC0200007800048E21@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Nov 18, 2014 at 05:20:44PM +0000, Jan Beulich wrote:
> >>> On 18.11.14 at 18:03, <linux@eikelenboom.it> wrote:
> > Tuesday, November 18, 2014, 5:16:50 PM, you wrote:
> >>  1) test_and_[set|clear]_bit sometimes return unexpected values.
> >>     [But this might be invalid as the addition of the ffff8303faaf25a8
> >>      might be correct - as the second dpci the softirq is processing
> >>      could be the MSI one]
> > 
> > Would there be an easy way to stress test this function separately in some 
> > debugging function to see if it indeed is returning unexpected values ?
> 
> I don't think there's a reasonable chance of these functions to return
> "unexpected" values - they're being used elsewhere, and you'd have
> had other problems in the past if they didn't behave as expected.

Interestingly most of the 'test_and_[set|clear]_bit operate on 'unsigned long'
while we do 'unsigned int' here. But the 'test_and'' are all btXl so double-word
safe.

The fact that Sander is able to get 'test_and_clear_bit(STATE_SCHED)' to return
zero - when in fact it should return a positive value - implies that some actor
is messing with the 'state' outside our raise/softirq dialogue.

pt_irq_guest_eoi does pirq_dpci->state = 0 unconditionally!

Lets see if this debug + potential patch helps. This should be applied
on top of the other patch you had. Just in case I am attaching all four
to this email.

>From 8093140e374fceb9121ccd07726fb3898b212bfb Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 18 Nov 2014 15:08:15 -0500
Subject: [PATCH 4/5] DEBUG4: Add an 'stamp' and potential fix.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 57 +++++++++++++++++++++++++++++++-------------
 xen/include/xen/hvm/irq.h    |  1 +
 2 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index b786bd2..8a8fc62 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -26,6 +26,8 @@
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
+#include <xen/console.h>
+
 
 static DEFINE_PER_CPU(struct list_head, dpci_list);
 
@@ -61,21 +63,29 @@ struct _debug_f {
     struct list_head list;
     unsigned int state;
     struct hvm_pirq_dpci *dpci;
+    unsigned long stamp;
 };
 
 struct __debug {
     struct _debug_f ok;
     struct _debug_f poison;
     struct _debug_f raise;
+    struct _debug_f busy_raise;
     struct _debug_f reset;
     struct _debug_f zombie_softirq;
     struct _debug_f zombie_raise;
+    struct _debug_f timeout;
+    struct _debug_f clear;
 };
 
 static DEFINE_PER_CPU(struct __debug, _d);
 
 void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
 {
+
+    if (pirq_dpci->pirq)
+        return;
+
     if (pirq_dpci->dom)
         d->domid = pirq_dpci->dom->domain_id;
     else
@@ -86,6 +96,7 @@ void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
     d->list.prev = pirq_dpci->softirq_list.prev;
     d->state = pirq_dpci->state;
     d->dpci = pirq_dpci;
+    d->stamp = pirq_dpci->stamp++;
 }
 
 enum {
@@ -95,6 +106,9 @@ enum {
     OK_SOFTIRQ,
     OK_RAISE,
     OK_RESET,
+    OK_TIMEOUT,
+    OK_BUSY,
+    OK_CLEAR,
 };
 
 static void dump_record(struct _debug_f *d, unsigned int type)
@@ -106,7 +120,11 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         [OK_SOFTIRQ] = "OK-softirq",
         [OK_RAISE]   = "OK-raise  ",
         [OK_RESET]   = "OK-reset  ",
+        [OK_TIMEOUT] = "OK-timeout",
+        [OK_BUSY]    = "OK-busy   ",
+        [OK_CLEAR]   = "OK-clear  ",
     };
+#if 0
 #define LONG(x) [_HVM_IRQ_DPCI_##x] = #x
     static const char *const names_flag[] = {
         LONG(MACH_PCI_SHIFT),
@@ -117,6 +135,7 @@ static void dump_record(struct _debug_f *d, unsigned int type)
     };
 #undef LONG
     unsigned int i;
+#endif
     s_time_t now;
 
     if ( d->domid == 0 )
@@ -126,20 +145,21 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         BUG();
 
     now = NOW();
-    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p %lx",
            d->domid, names[type],
            (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->state, d->count, d->list.prev, d->list.next, d->dpci);
+            d->state, d->count, d->list.prev, d->list.next, d->dpci, d->stamp);
 
     if ( d->dpci )
     {
         struct hvm_pirq_dpci *pirq_dpci = d->dpci;
-
+#if 0
         for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
             if ( pirq_dpci->flags & (1 << i) )
                 printk("%s ", names_flag[i]);
 
         printk(" PIRQ:%d", pirq_dpci->pirq);
+#endif
         if (pirq_dpci->line)
             printk(" LINE: %d", pirq_dpci->line);
     }
@@ -159,7 +179,10 @@ static void dump_debug(unsigned char key)
         printk("CPU%02d: \n" ,cpu);
         dump_record(&d->ok, OK_SOFTIRQ);
         dump_record(&d->raise, OK_RAISE);
+        dump_record(&d->busy_raise, OK_RAISE);
         dump_record(&d->reset, OK_RESET);
+        dump_record(&d->timeout, OK_TIMEOUT);
+        dump_record(&d->clear, OK_TIMEOUT);
         dump_record(&d->poison, ERR_POISON);
         dump_record(&d->zombie_softirq, Z_SOFTIRQ);
         dump_record(&d->zombie_raise, Z_RAISE);
@@ -184,8 +207,10 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
         return;
     }
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+    {
+        _record(&d->busy_raise, pirq_dpci);
         return;
-
+    }
     _record(&d->raise, pirq_dpci);
 
     get_knownalive_domain(pirq_dpci->dom);
@@ -264,10 +289,14 @@ bool_t pt_irq_need_timer(uint32_t flags)
 static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
                             void *arg)
 {
+    struct __debug *debug = &__get_cpu_var(_d);
+
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        _record(&debug->clear, pirq_dpci);
+        pt_pirq_softirq_reset(pirq_dpci);
+        /* pirq_dpci->state = 0; <= OUCH! */
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -280,11 +309,13 @@ static void pt_irq_time_out(void *data)
     struct hvm_pirq_dpci *irq_map = data;
     const struct hvm_irq_dpci *dpci;
     const struct dev_intx_gsi_link *digl;
-
+    struct __debug *d = &__get_cpu_var(_d);
     spin_lock(&irq_map->dom->event_lock);
 
     dpci = domain_get_irq_dpci(irq_map->dom);
     ASSERT(dpci);
+
+    _record(&d->timeout, irq_map);
     list_for_each_entry ( digl, &irq_map->digl_list, list )
     {
         unsigned int guest_gsi = hvm_pci_intx_gsi(digl->device, digl->intx);
@@ -302,6 +333,9 @@ static void pt_irq_time_out(void *data)
     pt_pirq_iterate(irq_map->dom, pt_irq_guest_eoi, NULL);
 
     spin_unlock(&irq_map->dom->event_lock);
+    console_start_sync();
+    dump_debug((char)0);
+    console_end_sync();
 }
 
 struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *d)
@@ -901,8 +935,6 @@ unlock:
     spin_unlock(&d->event_lock);
 }
 
-#include <xen/console.h>
-
 /*
  * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
  * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
@@ -919,26 +951,17 @@ static void dpci_softirq(void)
             struct hvm_pirq_dpci *dpci;
     } l[4];
     unsigned int i = 0;
-#if DIFF_LIST
-    struct hvm_pirq_dpci *n;
-#endif
     debug = &per_cpu(_d, cpu);
 
     local_irq_disable();
     list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
     local_irq_enable();
-#if DIFF_LIST
-    list_for_each_entry_safe(pirq_dpci, n, &our_list, softirq_list)
-#else
     while ( !list_empty(&our_list) )
-#endif
     {
         struct domain *d;
         struct list_head *entry;
 
-#ifndef DIFF_LIST
         pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
-#endif
         entry = &pirq_dpci->softirq_list;
         if ( i <= 3 )
         {
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 1fb1292..f5b6061 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -102,6 +102,7 @@ struct hvm_pirq_dpci {
     struct list_head softirq_list;
     unsigned int pirq;
     unsigned int line;
+    unsigned long stamp;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-dpci-Add-ZOMBIE-state.patch"

>From b8c267ea34663a9585e1aee9c09dede240b546f9 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 12:15:26 -0500
Subject: [PATCH 1/5] dpci: Add ZOMBIE state.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..8e9141e 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -50,20 +50,25 @@ static DEFINE_PER_CPU(struct list_head, dpci_list);
 
 enum {
     STATE_SCHED,
-    STATE_RUN
+    STATE_RUN,
+    STATE_ZOMBIE
 };
 
 /*
  * This can be called multiple times, but the softirq is only raised once.
- * That is until the STATE_SCHED state has been cleared. The state can be
- * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
- * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
- * the softirq had a chance to run).
+ * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
+ * STATE_SCHED and STATE_ZOMBIE state can be cleared by the 'dpci_softirq'
+ * (when it has executed 'hvm_dirq_assist'). The STATE_SCHED can be cleared
+ * by 'pt_pirq_softirq_reset' (which will try to clear the state before the
+ * softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
 
+    if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+        return;
+
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
@@ -85,7 +90,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
  */
 bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 {
-    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
         return 1;
 
     /*
@@ -109,7 +114,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
 
     ASSERT(spin_is_locked(&d->event_lock));
 
-    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
         /*
@@ -120,6 +125,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
         /* fallthrough. */
     case (1 << STATE_RUN):
     case (1 << STATE_RUN) | (1 << STATE_SCHED):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
         /*
          * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
@@ -779,6 +785,7 @@ unlock:
 static void dpci_softirq(void)
 {
     unsigned int cpu = smp_processor_id();
+    unsigned int reset = 0;
     LIST_HEAD(our_list);
 
     local_irq_disable();
@@ -805,7 +812,15 @@ static void dpci_softirq(void)
             hvm_dirq_assist(d, pirq_dpci);
             put_domain(d);
         }
+        else
+            reset = 1;
+
         clear_bit(STATE_RUN, &pirq_dpci->state);
+        if ( reset )
+        {
+            clear_bit(STATE_ZOMBIE, &pirq_dpci->state);
+            reset = 0;
+        }
     }
 }
 
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0002-debug.patch"

>From a4171fa12583eabd126bc5b4c305f49b2fb2b515 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 15:00:39 -0500
Subject: [PATCH 2/5] debug:

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 180 ++++++++++++++++++++++++++++++++++++++++++-
 xen/include/xen/hvm/irq.h    |   2 +
 2 files changed, 178 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 8e9141e..23e5ed1 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -54,6 +54,117 @@ enum {
     STATE_ZOMBIE
 };
 
+struct _debug_f {
+    unsigned int domid;
+    unsigned long count;
+    s_time_t last;
+    struct list_head list;
+    unsigned int state;
+    struct hvm_pirq_dpci *dpci;
+};
+
+struct __debug {
+    struct _debug_f ok;
+    struct _debug_f poison;
+    struct _debug_f raise;
+    struct _debug_f reset;
+    struct _debug_f zombie_softirq;
+    struct _debug_f zombie_raise;
+};
+
+static DEFINE_PER_CPU(struct __debug, _d);
+
+void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
+{
+    if (pirq_dpci->dom)
+        d->domid = pirq_dpci->dom->domain_id;
+    else
+        d->domid = 0xdead;
+    d->count ++;
+    d->last = NOW();
+    d->list.next = pirq_dpci->softirq_list.next;
+    d->list.prev = pirq_dpci->softirq_list.prev;
+    d->state = pirq_dpci->state;
+    d->dpci = pirq_dpci;
+}
+
+enum {
+    Z_SOFTIRQ,
+    Z_RAISE,
+    ERR_POISON,
+    OK_SOFTIRQ,
+    OK_RAISE,
+    OK_RESET,
+};
+
+static void dump_record(struct _debug_f *d, unsigned int type)
+{
+    static const char *const names[] = {
+        [Z_SOFTIRQ]  = "Z-softirq ",
+        [Z_RAISE]    = "Z-raise   ",
+        [ERR_POISON] = "ERR-poison",
+        [OK_SOFTIRQ] = "OK-softirq",
+        [OK_RAISE]   = "OK-raise  ",
+        [OK_RESET]   = "OK-reset  ",
+    };
+#define LONG(x) [_HVM_IRQ_DPCI_##x] = #x
+    static const char *const names_flag[] = {
+        LONG(MACH_PCI_SHIFT),
+        LONG(MAPPED_SHIFT),
+        LONG(EOI_LATCH_SHIFT),
+        LONG(GUEST_PCI_SHIFT),
+        LONG(GUEST_MSI_SHIFT),
+    };
+#undef LONG
+    unsigned int i;
+    s_time_t now;
+
+    if ( d->domid == 0 )
+        return;
+
+    if ( type >= ARRAY_SIZE(names) )
+        BUG();
+
+    now = NOW();
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
+           d->domid, names[type],
+           (unsigned long)((now - d->last) / MILLISECS(1)),
+            d->state, d->count, d->list.prev, d->list.next);
+
+    if ( d->dpci )
+    {
+        struct hvm_pirq_dpci *pirq_dpci = d->dpci;
+
+        for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
+            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
+                printk("%s ", names_flag[i]);
+
+        printk(" PIRQ:%d", pirq_dpci->pirq);
+        if (pirq_dpci->line)
+            printk(" LINE: %d", pirq_dpci->line);
+    }
+    printk("\n");
+    memset(d, 0, sizeof(struct _debug_f));
+}
+
+static void dump_debug(unsigned char key)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu ( cpu )
+    {
+        struct __debug *d;
+        d = &per_cpu(_d, cpu);
+
+        printk("CPU%02d: \n" ,cpu);
+        dump_record(&d->ok, OK_SOFTIRQ);
+        dump_record(&d->raise, OK_RAISE);
+        dump_record(&d->reset, OK_RESET);
+        dump_record(&d->poison, ERR_POISON);
+        dump_record(&d->zombie_softirq, Z_SOFTIRQ);
+        dump_record(&d->zombie_raise, Z_RAISE);
+    }
+}
 /*
  * This can be called multiple times, but the softirq is only raised once.
  * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
@@ -65,13 +176,18 @@ enum {
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
+    struct __debug *d = &__get_cpu_var(_d);
 
     if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+    {
+        _record(&d->zombie_raise, pirq_dpci);
         return;
-
+    }
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
+    _record(&d->raise, pirq_dpci);
+
     get_knownalive_domain(pirq_dpci->dom);
 
     local_irq_save(flags);
@@ -111,9 +227,12 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
 {
     struct domain *d = pirq_dpci->dom;
+    struct __debug *debug = &__get_cpu_var(_d);
 
     ASSERT(spin_is_locked(&d->event_lock));
 
+    _record(&debug->reset, pirq_dpci);
+
     switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
@@ -277,6 +396,7 @@ int pt_irq_create_bind(
              * As such on every 'pt_irq_create_bind' call we MUST set it.
              */
             pirq_dpci->dom = d;
+            pirq_dpci->pirq = pirq;
             /* bind after hvm_irq_dpci is setup to avoid race with irq handler*/
             rc = pirq_guest_bind(d->vcpu[0], info, 0);
             if ( rc == 0 && pt_irq_bind->u.msi.gtable )
@@ -291,6 +411,7 @@ int pt_irq_create_bind(
                      * to be scheduled but we must deal with the one that may be
                      * in the queue.
                      */
+                    pirq_dpci->line = __LINE__;
                     pt_pirq_softirq_reset(pirq_dpci);
                 }
             }
@@ -300,6 +421,7 @@ int pt_irq_create_bind(
                 pirq_dpci->gmsi.gvec = 0;
                 pirq_dpci->dom = NULL;
                 pirq_dpci->flags = 0;
+                pirq_dpci->pirq = -pirq;
                 pirq_cleanup_check(info, d);
                 spin_unlock(&d->event_lock);
                 return rc;
@@ -544,6 +666,7 @@ int pt_irq_destroy_bind(
          * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
          * call to pt_pirq_softirq_reset.
          */
+        pirq_dpci->line = __LINE__;
         pt_pirq_softirq_reset(pirq_dpci);
 
         pirq_cleanup_check(pirq, d);
@@ -778,6 +901,8 @@ unlock:
     spin_unlock(&d->event_lock);
 }
 
+#include <xen/console.h>
+
 /*
  * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
  * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
@@ -787,6 +912,9 @@ static void dpci_softirq(void)
     unsigned int cpu = smp_processor_id();
     unsigned int reset = 0;
     LIST_HEAD(our_list);
+    struct __debug *debug;
+
+    debug = &per_cpu(_d, cpu);
 
     local_irq_disable();
     list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
@@ -796,9 +924,22 @@ static void dpci_softirq(void)
     {
         struct hvm_pirq_dpci *pirq_dpci;
         struct domain *d;
+        struct list_head *entry;
 
         pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
-        list_del(&pirq_dpci->softirq_list);
+        entry = &pirq_dpci->softirq_list;
+        if ( entry->next == LIST_POISON1 || entry->next == LIST_POISON2 ||
+             entry->prev == LIST_POISON2 || entry->prev == LIST_POISON2 )
+        {
+            _record(&debug->poison, pirq_dpci);
+            console_start_sync();
+            dump_debug((char)0);
+            console_end_sync();
+            domain_crash(pirq_dpci->dom);
+            break;
+        }
+        _record(&debug->ok, pirq_dpci);
+        list_del(entry);
 
         d = pirq_dpci->dom;
         smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
@@ -813,8 +954,10 @@ static void dpci_softirq(void)
             put_domain(d);
         }
         else
+        {
+            _record(&debug->zombie_softirq, pirq_dpci);
             reset = 1;
-
+        }
         clear_bit(STATE_RUN, &pirq_dpci->state);
         if ( reset )
         {
@@ -833,6 +976,7 @@ static int cpu_callback(
     {
     case CPU_UP_PREPARE:
         INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        memset(&per_cpu(_d, cpu), 0, sizeof(struct __debug));
         break;
     case CPU_UP_CANCELED:
     case CPU_DEAD:
@@ -854,15 +998,43 @@ static struct notifier_block cpu_nfb = {
     .notifier_call = cpu_callback,
 };
 
+#include <xen/keyhandler.h>
+
+static struct keyhandler dump_debug_keyhandler = {
+    .diagnostic = 1,
+    .u.fn = dump_debug,
+    .desc = "dpci debug stats"
+};
+static struct timer debug_timer;
+static s_time_t last_time = 0;
+static unsigned int debug_cnt = 0;
+
+static void debug_timer_fn(void *d)
+{
+    if ( ( debug_cnt ++ % 10 ) == 0 )
+        printk("--MARK--\n");
+
+    last_time = NOW();
+    set_timer(&debug_timer, last_time + SECONDS(1));
+}
+
 static int __init setup_dpci_softirq(void)
 {
     unsigned int cpu;
 
     for_each_online_cpu(cpu)
+    {
         INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
-
+        memset(&per_cpu(_d, cpu), 0, sizeof(struct __debug));
+    }
     open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
     register_cpu_notifier(&cpu_nfb);
+
+    init_timer(&debug_timer, debug_timer_fn, NULL, smp_processor_id());
+    last_time = NOW();
+    set_timer(&debug_timer, NOW() + SECONDS(1));
+    register_keyhandler('k', &dump_debug_keyhandler);
+
     return 0;
 }
 __initcall(setup_dpci_softirq);
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..1fb1292 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -100,6 +100,8 @@ struct hvm_pirq_dpci {
     struct hvm_gmsi_info gmsi;
     struct timer timer;
     struct list_head softirq_list;
+    unsigned int pirq;
+    unsigned int line;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0003-DEBUG-2.patch"

>From 3163117e2ceb8dfcc11545dcc385aa3d147614e8 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 17 Nov 2014 17:32:43 -0500
Subject: [PATCH 3/5] DEBUG 2

---
 xen/drivers/passthrough/io.c | 42 ++++++++++++++++++++++++++++++++++--------
 1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 23e5ed1..b786bd2 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -126,17 +126,17 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         BUG();
 
     now = NOW();
-    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
            d->domid, names[type],
            (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->state, d->count, d->list.prev, d->list.next);
+            d->state, d->count, d->list.prev, d->list.next, d->dpci);
 
     if ( d->dpci )
     {
         struct hvm_pirq_dpci *pirq_dpci = d->dpci;
 
         for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
-            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
+            if ( pirq_dpci->flags & (1 << i) )
                 printk("%s ", names_flag[i]);
 
         printk(" PIRQ:%d", pirq_dpci->pirq);
@@ -545,9 +545,9 @@ int pt_irq_create_bind(
 
         if ( iommu_verbose )
             dprintk(XENLOG_G_INFO,
-                    "d%d: bind: m_gsi=%u g_gsi=%u dev=%02x.%02x.%u intx=%u\n",
+                    "d%d: bind: m_gsi=%u g_gsi=%u dev=%02x.%02x.%u intx=%u %p\n",
                     d->domain_id, pirq, guest_gsi, bus,
-                    PCI_SLOT(device), PCI_FUNC(device), intx);
+                    PCI_SLOT(device), PCI_FUNC(device), intx, pirq_dpci);
         break;
     }
 
@@ -913,26 +913,52 @@ static void dpci_softirq(void)
     unsigned int reset = 0;
     LIST_HEAD(our_list);
     struct __debug *debug;
-
+    struct hvm_pirq_dpci *pirq_dpci;
+    struct __x {
+            struct list_head l;
+            struct hvm_pirq_dpci *dpci;
+    } l[4];
+    unsigned int i = 0;
+#if DIFF_LIST
+    struct hvm_pirq_dpci *n;
+#endif
     debug = &per_cpu(_d, cpu);
 
     local_irq_disable();
     list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
     local_irq_enable();
-
+#if DIFF_LIST
+    list_for_each_entry_safe(pirq_dpci, n, &our_list, softirq_list)
+#else
     while ( !list_empty(&our_list) )
+#endif
     {
-        struct hvm_pirq_dpci *pirq_dpci;
         struct domain *d;
         struct list_head *entry;
 
+#ifndef DIFF_LIST
         pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
+#endif
         entry = &pirq_dpci->softirq_list;
+        if ( i <= 3 )
+        {
+            struct __x *p;
+
+            p = &l[i];
+            p->dpci = pirq_dpci;
+            p->l.prev = entry->prev;
+            p->l.next = entry->next;
+            i++;
+        }
         if ( entry->next == LIST_POISON1 || entry->next == LIST_POISON2 ||
              entry->prev == LIST_POISON2 || entry->prev == LIST_POISON2 )
         {
+            unsigned int j;
+
             _record(&debug->poison, pirq_dpci);
             console_start_sync();
+            for (j=0; j < i;j++)
+                printk(" %u: %p [p:%p, n:%p]\n", j, l[j].dpci, l[j].l.prev, l[j].l.next);
             dump_debug((char)0);
             console_end_sync();
             domain_crash(pirq_dpci->dom);
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0004-DEBUG4-Add-an-stamp-and-potential-fix.patch"

>From 8093140e374fceb9121ccd07726fb3898b212bfb Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 18 Nov 2014 15:08:15 -0500
Subject: [PATCH 4/5] DEBUG4: Add an 'stamp' and potential fix.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 57 +++++++++++++++++++++++++++++++-------------
 xen/include/xen/hvm/irq.h    |  1 +
 2 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index b786bd2..8a8fc62 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -26,6 +26,8 @@
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
+#include <xen/console.h>
+
 
 static DEFINE_PER_CPU(struct list_head, dpci_list);
 
@@ -61,21 +63,29 @@ struct _debug_f {
     struct list_head list;
     unsigned int state;
     struct hvm_pirq_dpci *dpci;
+    unsigned long stamp;
 };
 
 struct __debug {
     struct _debug_f ok;
     struct _debug_f poison;
     struct _debug_f raise;
+    struct _debug_f busy_raise;
     struct _debug_f reset;
     struct _debug_f zombie_softirq;
     struct _debug_f zombie_raise;
+    struct _debug_f timeout;
+    struct _debug_f clear;
 };
 
 static DEFINE_PER_CPU(struct __debug, _d);
 
 void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
 {
+
+    if (pirq_dpci->pirq)
+        return;
+
     if (pirq_dpci->dom)
         d->domid = pirq_dpci->dom->domain_id;
     else
@@ -86,6 +96,7 @@ void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
     d->list.prev = pirq_dpci->softirq_list.prev;
     d->state = pirq_dpci->state;
     d->dpci = pirq_dpci;
+    d->stamp = pirq_dpci->stamp++;
 }
 
 enum {
@@ -95,6 +106,9 @@ enum {
     OK_SOFTIRQ,
     OK_RAISE,
     OK_RESET,
+    OK_TIMEOUT,
+    OK_BUSY,
+    OK_CLEAR,
 };
 
 static void dump_record(struct _debug_f *d, unsigned int type)
@@ -106,7 +120,11 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         [OK_SOFTIRQ] = "OK-softirq",
         [OK_RAISE]   = "OK-raise  ",
         [OK_RESET]   = "OK-reset  ",
+        [OK_TIMEOUT] = "OK-timeout",
+        [OK_BUSY]    = "OK-busy   ",
+        [OK_CLEAR]   = "OK-clear  ",
     };
+#if 0
 #define LONG(x) [_HVM_IRQ_DPCI_##x] = #x
     static const char *const names_flag[] = {
         LONG(MACH_PCI_SHIFT),
@@ -117,6 +135,7 @@ static void dump_record(struct _debug_f *d, unsigned int type)
     };
 #undef LONG
     unsigned int i;
+#endif
     s_time_t now;
 
     if ( d->domid == 0 )
@@ -126,20 +145,21 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         BUG();
 
     now = NOW();
-    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p %lx",
            d->domid, names[type],
            (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->state, d->count, d->list.prev, d->list.next, d->dpci);
+            d->state, d->count, d->list.prev, d->list.next, d->dpci, d->stamp);
 
     if ( d->dpci )
     {
         struct hvm_pirq_dpci *pirq_dpci = d->dpci;
-
+#if 0
         for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
             if ( pirq_dpci->flags & (1 << i) )
                 printk("%s ", names_flag[i]);
 
         printk(" PIRQ:%d", pirq_dpci->pirq);
+#endif
         if (pirq_dpci->line)
             printk(" LINE: %d", pirq_dpci->line);
     }
@@ -159,7 +179,10 @@ static void dump_debug(unsigned char key)
         printk("CPU%02d: \n" ,cpu);
         dump_record(&d->ok, OK_SOFTIRQ);
         dump_record(&d->raise, OK_RAISE);
+        dump_record(&d->busy_raise, OK_RAISE);
         dump_record(&d->reset, OK_RESET);
+        dump_record(&d->timeout, OK_TIMEOUT);
+        dump_record(&d->clear, OK_TIMEOUT);
         dump_record(&d->poison, ERR_POISON);
         dump_record(&d->zombie_softirq, Z_SOFTIRQ);
         dump_record(&d->zombie_raise, Z_RAISE);
@@ -184,8 +207,10 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
         return;
     }
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+    {
+        _record(&d->busy_raise, pirq_dpci);
         return;
-
+    }
     _record(&d->raise, pirq_dpci);
 
     get_knownalive_domain(pirq_dpci->dom);
@@ -264,10 +289,14 @@ bool_t pt_irq_need_timer(uint32_t flags)
 static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
                             void *arg)
 {
+    struct __debug *debug = &__get_cpu_var(_d);
+
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        _record(&debug->clear, pirq_dpci);
+        pt_pirq_softirq_reset(pirq_dpci);
+        /* pirq_dpci->state = 0; <= OUCH! */
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -280,11 +309,13 @@ static void pt_irq_time_out(void *data)
     struct hvm_pirq_dpci *irq_map = data;
     const struct hvm_irq_dpci *dpci;
     const struct dev_intx_gsi_link *digl;
-
+    struct __debug *d = &__get_cpu_var(_d);
     spin_lock(&irq_map->dom->event_lock);
 
     dpci = domain_get_irq_dpci(irq_map->dom);
     ASSERT(dpci);
+
+    _record(&d->timeout, irq_map);
     list_for_each_entry ( digl, &irq_map->digl_list, list )
     {
         unsigned int guest_gsi = hvm_pci_intx_gsi(digl->device, digl->intx);
@@ -302,6 +333,9 @@ static void pt_irq_time_out(void *data)
     pt_pirq_iterate(irq_map->dom, pt_irq_guest_eoi, NULL);
 
     spin_unlock(&irq_map->dom->event_lock);
+    console_start_sync();
+    dump_debug((char)0);
+    console_end_sync();
 }
 
 struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *d)
@@ -901,8 +935,6 @@ unlock:
     spin_unlock(&d->event_lock);
 }
 
-#include <xen/console.h>
-
 /*
  * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
  * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
@@ -919,26 +951,17 @@ static void dpci_softirq(void)
             struct hvm_pirq_dpci *dpci;
     } l[4];
     unsigned int i = 0;
-#if DIFF_LIST
-    struct hvm_pirq_dpci *n;
-#endif
     debug = &per_cpu(_d, cpu);
 
     local_irq_disable();
     list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
     local_irq_enable();
-#if DIFF_LIST
-    list_for_each_entry_safe(pirq_dpci, n, &our_list, softirq_list)
-#else
     while ( !list_empty(&our_list) )
-#endif
     {
         struct domain *d;
         struct list_head *entry;
 
-#ifndef DIFF_LIST
         pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
-#endif
         entry = &pirq_dpci->softirq_list;
         if ( i <= 3 )
         {
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 1fb1292..f5b6061 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -102,6 +102,7 @@ struct hvm_pirq_dpci {
     struct list_head softirq_list;
     unsigned int pirq;
     unsigned int line;
+    unsigned long stamp;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0005-debug-Remove-the-MARK-code.patch"

>From 8e0edc1e6d51eeb5a401f686adccefa623332bcd Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 18 Nov 2014 15:29:12 -0500
Subject: [PATCH 5/5] debug: Remove the --MARK-- code.

We could use it to check every 1msec for some case and print
data, but we never used it.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 8a8fc62..aad5607 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -1054,18 +1054,6 @@ static struct keyhandler dump_debug_keyhandler = {
     .u.fn = dump_debug,
     .desc = "dpci debug stats"
 };
-static struct timer debug_timer;
-static s_time_t last_time = 0;
-static unsigned int debug_cnt = 0;
-
-static void debug_timer_fn(void *d)
-{
-    if ( ( debug_cnt ++ % 10 ) == 0 )
-        printk("--MARK--\n");
-
-    last_time = NOW();
-    set_timer(&debug_timer, last_time + SECONDS(1));
-}
 
 static int __init setup_dpci_softirq(void)
 {
@@ -1079,9 +1067,6 @@ static int __init setup_dpci_softirq(void)
     open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
     register_cpu_notifier(&cpu_nfb);
 
-    init_timer(&debug_timer, debug_timer_fn, NULL, smp_processor_id());
-    last_time = NOW();
-    set_timer(&debug_timer, NOW() + SECONDS(1));
     register_keyhandler('k', &dump_debug_keyhandler);
 
     return 0;
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--gKMricLos+KVdGMg--


From xen-devel-bounces@lists.xen.org Tue Nov 18 20:34:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 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.xen.org>)
	id 1XqpTu-0005hq-1U; Tue, 18 Nov 2014 20:34:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqpTs-0005hl-Tf
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 20:34:33 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	EE/96-09936-85DAB645; Tue, 18 Nov 2014 20:34:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416342869!13707772!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13566 invoked from network); 18 Nov 2014 20:34:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 20:34:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIKYHkW030103
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Nov 2014 20:34:18 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAIKYFMi019439
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 18 Nov 2014 20:34:16 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIKYFkM015591; Tue, 18 Nov 2014 20:34:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 12:34:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BDAEA117BAA; Tue, 18 Nov 2014 15:34:12 -0500 (EST)
Date: Tue, 18 Nov 2014 15:34:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141118203412.GA6540@laptop.dumpdata.com>
References: <20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<546B8DFC0200007800048E21@mail.emea.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg"
Content-Disposition: inline
In-Reply-To: <546B8DFC0200007800048E21@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Nov 18, 2014 at 05:20:44PM +0000, Jan Beulich wrote:
> >>> On 18.11.14 at 18:03, <linux@eikelenboom.it> wrote:
> > Tuesday, November 18, 2014, 5:16:50 PM, you wrote:
> >>  1) test_and_[set|clear]_bit sometimes return unexpected values.
> >>     [But this might be invalid as the addition of the ffff8303faaf25a8
> >>      might be correct - as the second dpci the softirq is processing
> >>      could be the MSI one]
> > 
> > Would there be an easy way to stress test this function separately in some 
> > debugging function to see if it indeed is returning unexpected values ?
> 
> I don't think there's a reasonable chance of these functions to return
> "unexpected" values - they're being used elsewhere, and you'd have
> had other problems in the past if they didn't behave as expected.

Interestingly most of the 'test_and_[set|clear]_bit operate on 'unsigned long'
while we do 'unsigned int' here. But the 'test_and'' are all btXl so double-word
safe.

The fact that Sander is able to get 'test_and_clear_bit(STATE_SCHED)' to return
zero - when in fact it should return a positive value - implies that some actor
is messing with the 'state' outside our raise/softirq dialogue.

pt_irq_guest_eoi does pirq_dpci->state = 0 unconditionally!

Lets see if this debug + potential patch helps. This should be applied
on top of the other patch you had. Just in case I am attaching all four
to this email.

>From 8093140e374fceb9121ccd07726fb3898b212bfb Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 18 Nov 2014 15:08:15 -0500
Subject: [PATCH 4/5] DEBUG4: Add an 'stamp' and potential fix.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 57 +++++++++++++++++++++++++++++++-------------
 xen/include/xen/hvm/irq.h    |  1 +
 2 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index b786bd2..8a8fc62 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -26,6 +26,8 @@
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
+#include <xen/console.h>
+
 
 static DEFINE_PER_CPU(struct list_head, dpci_list);
 
@@ -61,21 +63,29 @@ struct _debug_f {
     struct list_head list;
     unsigned int state;
     struct hvm_pirq_dpci *dpci;
+    unsigned long stamp;
 };
 
 struct __debug {
     struct _debug_f ok;
     struct _debug_f poison;
     struct _debug_f raise;
+    struct _debug_f busy_raise;
     struct _debug_f reset;
     struct _debug_f zombie_softirq;
     struct _debug_f zombie_raise;
+    struct _debug_f timeout;
+    struct _debug_f clear;
 };
 
 static DEFINE_PER_CPU(struct __debug, _d);
 
 void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
 {
+
+    if (pirq_dpci->pirq)
+        return;
+
     if (pirq_dpci->dom)
         d->domid = pirq_dpci->dom->domain_id;
     else
@@ -86,6 +96,7 @@ void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
     d->list.prev = pirq_dpci->softirq_list.prev;
     d->state = pirq_dpci->state;
     d->dpci = pirq_dpci;
+    d->stamp = pirq_dpci->stamp++;
 }
 
 enum {
@@ -95,6 +106,9 @@ enum {
     OK_SOFTIRQ,
     OK_RAISE,
     OK_RESET,
+    OK_TIMEOUT,
+    OK_BUSY,
+    OK_CLEAR,
 };
 
 static void dump_record(struct _debug_f *d, unsigned int type)
@@ -106,7 +120,11 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         [OK_SOFTIRQ] = "OK-softirq",
         [OK_RAISE]   = "OK-raise  ",
         [OK_RESET]   = "OK-reset  ",
+        [OK_TIMEOUT] = "OK-timeout",
+        [OK_BUSY]    = "OK-busy   ",
+        [OK_CLEAR]   = "OK-clear  ",
     };
+#if 0
 #define LONG(x) [_HVM_IRQ_DPCI_##x] = #x
     static const char *const names_flag[] = {
         LONG(MACH_PCI_SHIFT),
@@ -117,6 +135,7 @@ static void dump_record(struct _debug_f *d, unsigned int type)
     };
 #undef LONG
     unsigned int i;
+#endif
     s_time_t now;
 
     if ( d->domid == 0 )
@@ -126,20 +145,21 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         BUG();
 
     now = NOW();
-    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p %lx",
            d->domid, names[type],
            (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->state, d->count, d->list.prev, d->list.next, d->dpci);
+            d->state, d->count, d->list.prev, d->list.next, d->dpci, d->stamp);
 
     if ( d->dpci )
     {
         struct hvm_pirq_dpci *pirq_dpci = d->dpci;
-
+#if 0
         for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
             if ( pirq_dpci->flags & (1 << i) )
                 printk("%s ", names_flag[i]);
 
         printk(" PIRQ:%d", pirq_dpci->pirq);
+#endif
         if (pirq_dpci->line)
             printk(" LINE: %d", pirq_dpci->line);
     }
@@ -159,7 +179,10 @@ static void dump_debug(unsigned char key)
         printk("CPU%02d: \n" ,cpu);
         dump_record(&d->ok, OK_SOFTIRQ);
         dump_record(&d->raise, OK_RAISE);
+        dump_record(&d->busy_raise, OK_RAISE);
         dump_record(&d->reset, OK_RESET);
+        dump_record(&d->timeout, OK_TIMEOUT);
+        dump_record(&d->clear, OK_TIMEOUT);
         dump_record(&d->poison, ERR_POISON);
         dump_record(&d->zombie_softirq, Z_SOFTIRQ);
         dump_record(&d->zombie_raise, Z_RAISE);
@@ -184,8 +207,10 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
         return;
     }
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+    {
+        _record(&d->busy_raise, pirq_dpci);
         return;
-
+    }
     _record(&d->raise, pirq_dpci);
 
     get_knownalive_domain(pirq_dpci->dom);
@@ -264,10 +289,14 @@ bool_t pt_irq_need_timer(uint32_t flags)
 static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
                             void *arg)
 {
+    struct __debug *debug = &__get_cpu_var(_d);
+
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        _record(&debug->clear, pirq_dpci);
+        pt_pirq_softirq_reset(pirq_dpci);
+        /* pirq_dpci->state = 0; <= OUCH! */
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -280,11 +309,13 @@ static void pt_irq_time_out(void *data)
     struct hvm_pirq_dpci *irq_map = data;
     const struct hvm_irq_dpci *dpci;
     const struct dev_intx_gsi_link *digl;
-
+    struct __debug *d = &__get_cpu_var(_d);
     spin_lock(&irq_map->dom->event_lock);
 
     dpci = domain_get_irq_dpci(irq_map->dom);
     ASSERT(dpci);
+
+    _record(&d->timeout, irq_map);
     list_for_each_entry ( digl, &irq_map->digl_list, list )
     {
         unsigned int guest_gsi = hvm_pci_intx_gsi(digl->device, digl->intx);
@@ -302,6 +333,9 @@ static void pt_irq_time_out(void *data)
     pt_pirq_iterate(irq_map->dom, pt_irq_guest_eoi, NULL);
 
     spin_unlock(&irq_map->dom->event_lock);
+    console_start_sync();
+    dump_debug((char)0);
+    console_end_sync();
 }
 
 struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *d)
@@ -901,8 +935,6 @@ unlock:
     spin_unlock(&d->event_lock);
 }
 
-#include <xen/console.h>
-
 /*
  * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
  * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
@@ -919,26 +951,17 @@ static void dpci_softirq(void)
             struct hvm_pirq_dpci *dpci;
     } l[4];
     unsigned int i = 0;
-#if DIFF_LIST
-    struct hvm_pirq_dpci *n;
-#endif
     debug = &per_cpu(_d, cpu);
 
     local_irq_disable();
     list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
     local_irq_enable();
-#if DIFF_LIST
-    list_for_each_entry_safe(pirq_dpci, n, &our_list, softirq_list)
-#else
     while ( !list_empty(&our_list) )
-#endif
     {
         struct domain *d;
         struct list_head *entry;
 
-#ifndef DIFF_LIST
         pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
-#endif
         entry = &pirq_dpci->softirq_list;
         if ( i <= 3 )
         {
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 1fb1292..f5b6061 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -102,6 +102,7 @@ struct hvm_pirq_dpci {
     struct list_head softirq_list;
     unsigned int pirq;
     unsigned int line;
+    unsigned long stamp;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-dpci-Add-ZOMBIE-state.patch"

>From b8c267ea34663a9585e1aee9c09dede240b546f9 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 12:15:26 -0500
Subject: [PATCH 1/5] dpci: Add ZOMBIE state.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..8e9141e 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -50,20 +50,25 @@ static DEFINE_PER_CPU(struct list_head, dpci_list);
 
 enum {
     STATE_SCHED,
-    STATE_RUN
+    STATE_RUN,
+    STATE_ZOMBIE
 };
 
 /*
  * This can be called multiple times, but the softirq is only raised once.
- * That is until the STATE_SCHED state has been cleared. The state can be
- * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
- * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
- * the softirq had a chance to run).
+ * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
+ * STATE_SCHED and STATE_ZOMBIE state can be cleared by the 'dpci_softirq'
+ * (when it has executed 'hvm_dirq_assist'). The STATE_SCHED can be cleared
+ * by 'pt_pirq_softirq_reset' (which will try to clear the state before the
+ * softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
 
+    if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+        return;
+
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
@@ -85,7 +90,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
  */
 bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 {
-    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
         return 1;
 
     /*
@@ -109,7 +114,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
 
     ASSERT(spin_is_locked(&d->event_lock));
 
-    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
         /*
@@ -120,6 +125,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
         /* fallthrough. */
     case (1 << STATE_RUN):
     case (1 << STATE_RUN) | (1 << STATE_SCHED):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
         /*
          * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
@@ -779,6 +785,7 @@ unlock:
 static void dpci_softirq(void)
 {
     unsigned int cpu = smp_processor_id();
+    unsigned int reset = 0;
     LIST_HEAD(our_list);
 
     local_irq_disable();
@@ -805,7 +812,15 @@ static void dpci_softirq(void)
             hvm_dirq_assist(d, pirq_dpci);
             put_domain(d);
         }
+        else
+            reset = 1;
+
         clear_bit(STATE_RUN, &pirq_dpci->state);
+        if ( reset )
+        {
+            clear_bit(STATE_ZOMBIE, &pirq_dpci->state);
+            reset = 0;
+        }
     }
 }
 
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0002-debug.patch"

>From a4171fa12583eabd126bc5b4c305f49b2fb2b515 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 15:00:39 -0500
Subject: [PATCH 2/5] debug:

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 180 ++++++++++++++++++++++++++++++++++++++++++-
 xen/include/xen/hvm/irq.h    |   2 +
 2 files changed, 178 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 8e9141e..23e5ed1 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -54,6 +54,117 @@ enum {
     STATE_ZOMBIE
 };
 
+struct _debug_f {
+    unsigned int domid;
+    unsigned long count;
+    s_time_t last;
+    struct list_head list;
+    unsigned int state;
+    struct hvm_pirq_dpci *dpci;
+};
+
+struct __debug {
+    struct _debug_f ok;
+    struct _debug_f poison;
+    struct _debug_f raise;
+    struct _debug_f reset;
+    struct _debug_f zombie_softirq;
+    struct _debug_f zombie_raise;
+};
+
+static DEFINE_PER_CPU(struct __debug, _d);
+
+void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
+{
+    if (pirq_dpci->dom)
+        d->domid = pirq_dpci->dom->domain_id;
+    else
+        d->domid = 0xdead;
+    d->count ++;
+    d->last = NOW();
+    d->list.next = pirq_dpci->softirq_list.next;
+    d->list.prev = pirq_dpci->softirq_list.prev;
+    d->state = pirq_dpci->state;
+    d->dpci = pirq_dpci;
+}
+
+enum {
+    Z_SOFTIRQ,
+    Z_RAISE,
+    ERR_POISON,
+    OK_SOFTIRQ,
+    OK_RAISE,
+    OK_RESET,
+};
+
+static void dump_record(struct _debug_f *d, unsigned int type)
+{
+    static const char *const names[] = {
+        [Z_SOFTIRQ]  = "Z-softirq ",
+        [Z_RAISE]    = "Z-raise   ",
+        [ERR_POISON] = "ERR-poison",
+        [OK_SOFTIRQ] = "OK-softirq",
+        [OK_RAISE]   = "OK-raise  ",
+        [OK_RESET]   = "OK-reset  ",
+    };
+#define LONG(x) [_HVM_IRQ_DPCI_##x] = #x
+    static const char *const names_flag[] = {
+        LONG(MACH_PCI_SHIFT),
+        LONG(MAPPED_SHIFT),
+        LONG(EOI_LATCH_SHIFT),
+        LONG(GUEST_PCI_SHIFT),
+        LONG(GUEST_MSI_SHIFT),
+    };
+#undef LONG
+    unsigned int i;
+    s_time_t now;
+
+    if ( d->domid == 0 )
+        return;
+
+    if ( type >= ARRAY_SIZE(names) )
+        BUG();
+
+    now = NOW();
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
+           d->domid, names[type],
+           (unsigned long)((now - d->last) / MILLISECS(1)),
+            d->state, d->count, d->list.prev, d->list.next);
+
+    if ( d->dpci )
+    {
+        struct hvm_pirq_dpci *pirq_dpci = d->dpci;
+
+        for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
+            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
+                printk("%s ", names_flag[i]);
+
+        printk(" PIRQ:%d", pirq_dpci->pirq);
+        if (pirq_dpci->line)
+            printk(" LINE: %d", pirq_dpci->line);
+    }
+    printk("\n");
+    memset(d, 0, sizeof(struct _debug_f));
+}
+
+static void dump_debug(unsigned char key)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu ( cpu )
+    {
+        struct __debug *d;
+        d = &per_cpu(_d, cpu);
+
+        printk("CPU%02d: \n" ,cpu);
+        dump_record(&d->ok, OK_SOFTIRQ);
+        dump_record(&d->raise, OK_RAISE);
+        dump_record(&d->reset, OK_RESET);
+        dump_record(&d->poison, ERR_POISON);
+        dump_record(&d->zombie_softirq, Z_SOFTIRQ);
+        dump_record(&d->zombie_raise, Z_RAISE);
+    }
+}
 /*
  * This can be called multiple times, but the softirq is only raised once.
  * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
@@ -65,13 +176,18 @@ enum {
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
+    struct __debug *d = &__get_cpu_var(_d);
 
     if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+    {
+        _record(&d->zombie_raise, pirq_dpci);
         return;
-
+    }
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
+    _record(&d->raise, pirq_dpci);
+
     get_knownalive_domain(pirq_dpci->dom);
 
     local_irq_save(flags);
@@ -111,9 +227,12 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
 {
     struct domain *d = pirq_dpci->dom;
+    struct __debug *debug = &__get_cpu_var(_d);
 
     ASSERT(spin_is_locked(&d->event_lock));
 
+    _record(&debug->reset, pirq_dpci);
+
     switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
@@ -277,6 +396,7 @@ int pt_irq_create_bind(
              * As such on every 'pt_irq_create_bind' call we MUST set it.
              */
             pirq_dpci->dom = d;
+            pirq_dpci->pirq = pirq;
             /* bind after hvm_irq_dpci is setup to avoid race with irq handler*/
             rc = pirq_guest_bind(d->vcpu[0], info, 0);
             if ( rc == 0 && pt_irq_bind->u.msi.gtable )
@@ -291,6 +411,7 @@ int pt_irq_create_bind(
                      * to be scheduled but we must deal with the one that may be
                      * in the queue.
                      */
+                    pirq_dpci->line = __LINE__;
                     pt_pirq_softirq_reset(pirq_dpci);
                 }
             }
@@ -300,6 +421,7 @@ int pt_irq_create_bind(
                 pirq_dpci->gmsi.gvec = 0;
                 pirq_dpci->dom = NULL;
                 pirq_dpci->flags = 0;
+                pirq_dpci->pirq = -pirq;
                 pirq_cleanup_check(info, d);
                 spin_unlock(&d->event_lock);
                 return rc;
@@ -544,6 +666,7 @@ int pt_irq_destroy_bind(
          * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
          * call to pt_pirq_softirq_reset.
          */
+        pirq_dpci->line = __LINE__;
         pt_pirq_softirq_reset(pirq_dpci);
 
         pirq_cleanup_check(pirq, d);
@@ -778,6 +901,8 @@ unlock:
     spin_unlock(&d->event_lock);
 }
 
+#include <xen/console.h>
+
 /*
  * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
  * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
@@ -787,6 +912,9 @@ static void dpci_softirq(void)
     unsigned int cpu = smp_processor_id();
     unsigned int reset = 0;
     LIST_HEAD(our_list);
+    struct __debug *debug;
+
+    debug = &per_cpu(_d, cpu);
 
     local_irq_disable();
     list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
@@ -796,9 +924,22 @@ static void dpci_softirq(void)
     {
         struct hvm_pirq_dpci *pirq_dpci;
         struct domain *d;
+        struct list_head *entry;
 
         pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
-        list_del(&pirq_dpci->softirq_list);
+        entry = &pirq_dpci->softirq_list;
+        if ( entry->next == LIST_POISON1 || entry->next == LIST_POISON2 ||
+             entry->prev == LIST_POISON2 || entry->prev == LIST_POISON2 )
+        {
+            _record(&debug->poison, pirq_dpci);
+            console_start_sync();
+            dump_debug((char)0);
+            console_end_sync();
+            domain_crash(pirq_dpci->dom);
+            break;
+        }
+        _record(&debug->ok, pirq_dpci);
+        list_del(entry);
 
         d = pirq_dpci->dom;
         smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
@@ -813,8 +954,10 @@ static void dpci_softirq(void)
             put_domain(d);
         }
         else
+        {
+            _record(&debug->zombie_softirq, pirq_dpci);
             reset = 1;
-
+        }
         clear_bit(STATE_RUN, &pirq_dpci->state);
         if ( reset )
         {
@@ -833,6 +976,7 @@ static int cpu_callback(
     {
     case CPU_UP_PREPARE:
         INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
+        memset(&per_cpu(_d, cpu), 0, sizeof(struct __debug));
         break;
     case CPU_UP_CANCELED:
     case CPU_DEAD:
@@ -854,15 +998,43 @@ static struct notifier_block cpu_nfb = {
     .notifier_call = cpu_callback,
 };
 
+#include <xen/keyhandler.h>
+
+static struct keyhandler dump_debug_keyhandler = {
+    .diagnostic = 1,
+    .u.fn = dump_debug,
+    .desc = "dpci debug stats"
+};
+static struct timer debug_timer;
+static s_time_t last_time = 0;
+static unsigned int debug_cnt = 0;
+
+static void debug_timer_fn(void *d)
+{
+    if ( ( debug_cnt ++ % 10 ) == 0 )
+        printk("--MARK--\n");
+
+    last_time = NOW();
+    set_timer(&debug_timer, last_time + SECONDS(1));
+}
+
 static int __init setup_dpci_softirq(void)
 {
     unsigned int cpu;
 
     for_each_online_cpu(cpu)
+    {
         INIT_LIST_HEAD(&per_cpu(dpci_list, cpu));
-
+        memset(&per_cpu(_d, cpu), 0, sizeof(struct __debug));
+    }
     open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
     register_cpu_notifier(&cpu_nfb);
+
+    init_timer(&debug_timer, debug_timer_fn, NULL, smp_processor_id());
+    last_time = NOW();
+    set_timer(&debug_timer, NOW() + SECONDS(1));
+    register_keyhandler('k', &dump_debug_keyhandler);
+
     return 0;
 }
 __initcall(setup_dpci_softirq);
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..1fb1292 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -100,6 +100,8 @@ struct hvm_pirq_dpci {
     struct hvm_gmsi_info gmsi;
     struct timer timer;
     struct list_head softirq_list;
+    unsigned int pirq;
+    unsigned int line;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0003-DEBUG-2.patch"

>From 3163117e2ceb8dfcc11545dcc385aa3d147614e8 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 17 Nov 2014 17:32:43 -0500
Subject: [PATCH 3/5] DEBUG 2

---
 xen/drivers/passthrough/io.c | 42 ++++++++++++++++++++++++++++++++++--------
 1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 23e5ed1..b786bd2 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -126,17 +126,17 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         BUG();
 
     now = NOW();
-    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] ",
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
            d->domid, names[type],
            (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->state, d->count, d->list.prev, d->list.next);
+            d->state, d->count, d->list.prev, d->list.next, d->dpci);
 
     if ( d->dpci )
     {
         struct hvm_pirq_dpci *pirq_dpci = d->dpci;
 
         for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
-            if ( pirq_dpci->flags & 1 << _HVM_IRQ_DPCI_TRANSLATE_SHIFT )
+            if ( pirq_dpci->flags & (1 << i) )
                 printk("%s ", names_flag[i]);
 
         printk(" PIRQ:%d", pirq_dpci->pirq);
@@ -545,9 +545,9 @@ int pt_irq_create_bind(
 
         if ( iommu_verbose )
             dprintk(XENLOG_G_INFO,
-                    "d%d: bind: m_gsi=%u g_gsi=%u dev=%02x.%02x.%u intx=%u\n",
+                    "d%d: bind: m_gsi=%u g_gsi=%u dev=%02x.%02x.%u intx=%u %p\n",
                     d->domain_id, pirq, guest_gsi, bus,
-                    PCI_SLOT(device), PCI_FUNC(device), intx);
+                    PCI_SLOT(device), PCI_FUNC(device), intx, pirq_dpci);
         break;
     }
 
@@ -913,26 +913,52 @@ static void dpci_softirq(void)
     unsigned int reset = 0;
     LIST_HEAD(our_list);
     struct __debug *debug;
-
+    struct hvm_pirq_dpci *pirq_dpci;
+    struct __x {
+            struct list_head l;
+            struct hvm_pirq_dpci *dpci;
+    } l[4];
+    unsigned int i = 0;
+#if DIFF_LIST
+    struct hvm_pirq_dpci *n;
+#endif
     debug = &per_cpu(_d, cpu);
 
     local_irq_disable();
     list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
     local_irq_enable();
-
+#if DIFF_LIST
+    list_for_each_entry_safe(pirq_dpci, n, &our_list, softirq_list)
+#else
     while ( !list_empty(&our_list) )
+#endif
     {
-        struct hvm_pirq_dpci *pirq_dpci;
         struct domain *d;
         struct list_head *entry;
 
+#ifndef DIFF_LIST
         pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
+#endif
         entry = &pirq_dpci->softirq_list;
+        if ( i <= 3 )
+        {
+            struct __x *p;
+
+            p = &l[i];
+            p->dpci = pirq_dpci;
+            p->l.prev = entry->prev;
+            p->l.next = entry->next;
+            i++;
+        }
         if ( entry->next == LIST_POISON1 || entry->next == LIST_POISON2 ||
              entry->prev == LIST_POISON2 || entry->prev == LIST_POISON2 )
         {
+            unsigned int j;
+
             _record(&debug->poison, pirq_dpci);
             console_start_sync();
+            for (j=0; j < i;j++)
+                printk(" %u: %p [p:%p, n:%p]\n", j, l[j].dpci, l[j].l.prev, l[j].l.next);
             dump_debug((char)0);
             console_end_sync();
             domain_crash(pirq_dpci->dom);
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0004-DEBUG4-Add-an-stamp-and-potential-fix.patch"

>From 8093140e374fceb9121ccd07726fb3898b212bfb Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 18 Nov 2014 15:08:15 -0500
Subject: [PATCH 4/5] DEBUG4: Add an 'stamp' and potential fix.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 57 +++++++++++++++++++++++++++++++-------------
 xen/include/xen/hvm/irq.h    |  1 +
 2 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index b786bd2..8a8fc62 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -26,6 +26,8 @@
 #include <asm/hvm/iommu.h>
 #include <asm/hvm/support.h>
 #include <xen/hvm/irq.h>
+#include <xen/console.h>
+
 
 static DEFINE_PER_CPU(struct list_head, dpci_list);
 
@@ -61,21 +63,29 @@ struct _debug_f {
     struct list_head list;
     unsigned int state;
     struct hvm_pirq_dpci *dpci;
+    unsigned long stamp;
 };
 
 struct __debug {
     struct _debug_f ok;
     struct _debug_f poison;
     struct _debug_f raise;
+    struct _debug_f busy_raise;
     struct _debug_f reset;
     struct _debug_f zombie_softirq;
     struct _debug_f zombie_raise;
+    struct _debug_f timeout;
+    struct _debug_f clear;
 };
 
 static DEFINE_PER_CPU(struct __debug, _d);
 
 void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
 {
+
+    if (pirq_dpci->pirq)
+        return;
+
     if (pirq_dpci->dom)
         d->domid = pirq_dpci->dom->domain_id;
     else
@@ -86,6 +96,7 @@ void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
     d->list.prev = pirq_dpci->softirq_list.prev;
     d->state = pirq_dpci->state;
     d->dpci = pirq_dpci;
+    d->stamp = pirq_dpci->stamp++;
 }
 
 enum {
@@ -95,6 +106,9 @@ enum {
     OK_SOFTIRQ,
     OK_RAISE,
     OK_RESET,
+    OK_TIMEOUT,
+    OK_BUSY,
+    OK_CLEAR,
 };
 
 static void dump_record(struct _debug_f *d, unsigned int type)
@@ -106,7 +120,11 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         [OK_SOFTIRQ] = "OK-softirq",
         [OK_RAISE]   = "OK-raise  ",
         [OK_RESET]   = "OK-reset  ",
+        [OK_TIMEOUT] = "OK-timeout",
+        [OK_BUSY]    = "OK-busy   ",
+        [OK_CLEAR]   = "OK-clear  ",
     };
+#if 0
 #define LONG(x) [_HVM_IRQ_DPCI_##x] = #x
     static const char *const names_flag[] = {
         LONG(MACH_PCI_SHIFT),
@@ -117,6 +135,7 @@ static void dump_record(struct _debug_f *d, unsigned int type)
     };
 #undef LONG
     unsigned int i;
+#endif
     s_time_t now;
 
     if ( d->domid == 0 )
@@ -126,20 +145,21 @@ static void dump_record(struct _debug_f *d, unsigned int type)
         BUG();
 
     now = NOW();
-    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p",
+    printk("d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p %lx",
            d->domid, names[type],
            (unsigned long)((now - d->last) / MILLISECS(1)),
-            d->state, d->count, d->list.prev, d->list.next, d->dpci);
+            d->state, d->count, d->list.prev, d->list.next, d->dpci, d->stamp);
 
     if ( d->dpci )
     {
         struct hvm_pirq_dpci *pirq_dpci = d->dpci;
-
+#if 0
         for ( i = 0; i <= _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
             if ( pirq_dpci->flags & (1 << i) )
                 printk("%s ", names_flag[i]);
 
         printk(" PIRQ:%d", pirq_dpci->pirq);
+#endif
         if (pirq_dpci->line)
             printk(" LINE: %d", pirq_dpci->line);
     }
@@ -159,7 +179,10 @@ static void dump_debug(unsigned char key)
         printk("CPU%02d: \n" ,cpu);
         dump_record(&d->ok, OK_SOFTIRQ);
         dump_record(&d->raise, OK_RAISE);
+        dump_record(&d->busy_raise, OK_RAISE);
         dump_record(&d->reset, OK_RESET);
+        dump_record(&d->timeout, OK_TIMEOUT);
+        dump_record(&d->clear, OK_TIMEOUT);
         dump_record(&d->poison, ERR_POISON);
         dump_record(&d->zombie_softirq, Z_SOFTIRQ);
         dump_record(&d->zombie_raise, Z_RAISE);
@@ -184,8 +207,10 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
         return;
     }
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
+    {
+        _record(&d->busy_raise, pirq_dpci);
         return;
-
+    }
     _record(&d->raise, pirq_dpci);
 
     get_knownalive_domain(pirq_dpci->dom);
@@ -264,10 +289,14 @@ bool_t pt_irq_need_timer(uint32_t flags)
 static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
                             void *arg)
 {
+    struct __debug *debug = &__get_cpu_var(_d);
+
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        _record(&debug->clear, pirq_dpci);
+        pt_pirq_softirq_reset(pirq_dpci);
+        /* pirq_dpci->state = 0; <= OUCH! */
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -280,11 +309,13 @@ static void pt_irq_time_out(void *data)
     struct hvm_pirq_dpci *irq_map = data;
     const struct hvm_irq_dpci *dpci;
     const struct dev_intx_gsi_link *digl;
-
+    struct __debug *d = &__get_cpu_var(_d);
     spin_lock(&irq_map->dom->event_lock);
 
     dpci = domain_get_irq_dpci(irq_map->dom);
     ASSERT(dpci);
+
+    _record(&d->timeout, irq_map);
     list_for_each_entry ( digl, &irq_map->digl_list, list )
     {
         unsigned int guest_gsi = hvm_pci_intx_gsi(digl->device, digl->intx);
@@ -302,6 +333,9 @@ static void pt_irq_time_out(void *data)
     pt_pirq_iterate(irq_map->dom, pt_irq_guest_eoi, NULL);
 
     spin_unlock(&irq_map->dom->event_lock);
+    console_start_sync();
+    dump_debug((char)0);
+    console_end_sync();
 }
 
 struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *d)
@@ -901,8 +935,6 @@ unlock:
     spin_unlock(&d->event_lock);
 }
 
-#include <xen/console.h>
-
 /*
  * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
  * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
@@ -919,26 +951,17 @@ static void dpci_softirq(void)
             struct hvm_pirq_dpci *dpci;
     } l[4];
     unsigned int i = 0;
-#if DIFF_LIST
-    struct hvm_pirq_dpci *n;
-#endif
     debug = &per_cpu(_d, cpu);
 
     local_irq_disable();
     list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
     local_irq_enable();
-#if DIFF_LIST
-    list_for_each_entry_safe(pirq_dpci, n, &our_list, softirq_list)
-#else
     while ( !list_empty(&our_list) )
-#endif
     {
         struct domain *d;
         struct list_head *entry;
 
-#ifndef DIFF_LIST
         pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
-#endif
         entry = &pirq_dpci->softirq_list;
         if ( i <= 3 )
         {
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 1fb1292..f5b6061 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -102,6 +102,7 @@ struct hvm_pirq_dpci {
     struct list_head softirq_list;
     unsigned int pirq;
     unsigned int line;
+    unsigned long stamp;
 };
 
 void pt_pirq_init(struct domain *, struct hvm_pirq_dpci *);
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0005-debug-Remove-the-MARK-code.patch"

>From 8e0edc1e6d51eeb5a401f686adccefa623332bcd Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 18 Nov 2014 15:29:12 -0500
Subject: [PATCH 5/5] debug: Remove the --MARK-- code.

We could use it to check every 1msec for some case and print
data, but we never used it.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 8a8fc62..aad5607 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -1054,18 +1054,6 @@ static struct keyhandler dump_debug_keyhandler = {
     .u.fn = dump_debug,
     .desc = "dpci debug stats"
 };
-static struct timer debug_timer;
-static s_time_t last_time = 0;
-static unsigned int debug_cnt = 0;
-
-static void debug_timer_fn(void *d)
-{
-    if ( ( debug_cnt ++ % 10 ) == 0 )
-        printk("--MARK--\n");
-
-    last_time = NOW();
-    set_timer(&debug_timer, last_time + SECONDS(1));
-}
 
 static int __init setup_dpci_softirq(void)
 {
@@ -1079,9 +1067,6 @@ static int __init setup_dpci_softirq(void)
     open_softirq(HVM_DPCI_SOFTIRQ, dpci_softirq);
     register_cpu_notifier(&cpu_nfb);
 
-    init_timer(&debug_timer, debug_timer_fn, NULL, smp_processor_id());
-    last_time = NOW();
-    set_timer(&debug_timer, NOW() + SECONDS(1));
     register_keyhandler('k', &dump_debug_keyhandler);
 
     return 0;
-- 
1.9.3


--gKMricLos+KVdGMg
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--gKMricLos+KVdGMg--


From xen-devel-bounces@lists.xen.org Tue Nov 18 20:57:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 20: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 1XqppV-0005w1-SX; Tue, 18 Nov 2014 20:56:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqppT-0005vw-Ry
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 20:56:52 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	E6/61-25547-392BB645; Tue, 18 Nov 2014 20:56:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416344208!12248237!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30864 invoked from network); 18 Nov 2014 20:56:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 20:56:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIKubFv020799
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Nov 2014 20:56:38 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIKuZEX019452
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 18 Nov 2014 20:56:36 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIKuZ5m017116; Tue, 18 Nov 2014 20:56:35 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 12:56:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7600C117BC9; Tue, 18 Nov 2014 15:56:33 -0500 (EST)
Date: Tue, 18 Nov 2014 15:56:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141118205633.GB6540@laptop.dumpdata.com>
References: <1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1222042576.20141118180323@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
> about them .. however looking at the earlier reports these lines were also in 
> those reports).
> 
> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
> and had a new default seabios config. (just to rule out anything stale in my tree)
> 
> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
> seabios config) are not the most recent (they don't get updated automatically 
> when you just do a git pull on the main tree) ?
> 
> In /tools/firmware/seabios-dir/.config i have:
> CONFIG_USB=y
> CONFIG_USB_UHCI=y
> CONFIG_USB_OHCI=y
> CONFIG_USB_EHCI=y
> CONFIG_USB_XHCI=y
> CONFIG_USB_MSC=y
> CONFIG_USB_UAS=y
> CONFIG_USB_HUB=y
> CONFIG_USB_KEYBOARD=y
> CONFIG_USB_MOUSE=y
> 

I seem to have the same thing. Perhaps it is my XHCI controller being wonky.

> And this is all just from a:
> - git clone git://xenbits.xen.org/xen.git -b staging
> - make clean && ./configure && make -j6 && make -j6 install

Aye. 
.. snip..
> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
> >     [But this might be invalid as the addition of the ffff8303faaf25a8
> >      might be correct - as the second dpci the softirq is processing
> >      could be the MSI one]
> 
> Would there be an easy way to stress test this function separately in some 
> debugging function to see if it indeed is returning unexpected values ?

Sadly no. But you got me looking in the right direction when you mentioned
'timeout'.
> 
> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
> 
> Just curious, have you also tested the patches on AMD hardware ?

Yes. To reproduce this the first thing I did was to get an AMD box.

> 
>  
> >> When i look at the combination of (2) and (3), It seems it could be an 
> >> interaction between the two passed through devices and/or different IRQ types.
> 
> > Could be - as in it is causing this issue to show up faster than
> > expected. Or it is the one that triggers more than one dpci happening
> > at the same time.
> 
> Well that didn't seem to be it (see separate amendment i mailed previously)

Right, the current theory I've is that the interrupts are not being
Acked within 8 milisecond and we reset the 'state' - and at the same
time we get an interrupt and schedule it - while we are still processing
the same interrupt. This would explain why the 'test_and_clear_bit'
got the wrong value.

In regards to the list poison - following this thread of logic - with
the 'state = 0' set we open the floodgates for any CPU to put the same
'struct hvm_pirq_dpci' on its list.

We do reset the 'state' on _every_ GSI that is mapped to a guest - so
we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:

CPUX:				CPUY:
pt_irq_time_out:
state = 0;			
[out of timer coder, the		raise_softirq
 pirq_dpci is on the dpci_list]		[adds the pirq_dpci as state == 0]

softirq_dpci				softirq_dpci:
	list_del
	[entries poison]
						list_del <= BOOM
			
Is what I believe is happening.

The INTX device - once I put a load on it - does not trigger
any pt_irq_time_out, so that would explain why I cannot hit this.

But I believe your card hits these "hiccups".	

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 20:57:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 20: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 1XqppV-0005w1-SX; Tue, 18 Nov 2014 20:56:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XqppT-0005vw-Ry
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 20:56:52 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	E6/61-25547-392BB645; Tue, 18 Nov 2014 20:56:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416344208!12248237!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30864 invoked from network); 18 Nov 2014 20:56:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 20:56:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIKubFv020799
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Nov 2014 20:56:38 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIKuZEX019452
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 18 Nov 2014 20:56:36 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIKuZ5m017116; Tue, 18 Nov 2014 20:56:35 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 12:56:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7600C117BC9; Tue, 18 Nov 2014 15:56:33 -0500 (EST)
Date: Tue, 18 Nov 2014 15:56:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141118205633.GB6540@laptop.dumpdata.com>
References: <1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1222042576.20141118180323@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
> about them .. however looking at the earlier reports these lines were also in 
> those reports).
> 
> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
> and had a new default seabios config. (just to rule out anything stale in my tree)
> 
> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
> seabios config) are not the most recent (they don't get updated automatically 
> when you just do a git pull on the main tree) ?
> 
> In /tools/firmware/seabios-dir/.config i have:
> CONFIG_USB=y
> CONFIG_USB_UHCI=y
> CONFIG_USB_OHCI=y
> CONFIG_USB_EHCI=y
> CONFIG_USB_XHCI=y
> CONFIG_USB_MSC=y
> CONFIG_USB_UAS=y
> CONFIG_USB_HUB=y
> CONFIG_USB_KEYBOARD=y
> CONFIG_USB_MOUSE=y
> 

I seem to have the same thing. Perhaps it is my XHCI controller being wonky.

> And this is all just from a:
> - git clone git://xenbits.xen.org/xen.git -b staging
> - make clean && ./configure && make -j6 && make -j6 install

Aye. 
.. snip..
> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
> >     [But this might be invalid as the addition of the ffff8303faaf25a8
> >      might be correct - as the second dpci the softirq is processing
> >      could be the MSI one]
> 
> Would there be an easy way to stress test this function separately in some 
> debugging function to see if it indeed is returning unexpected values ?

Sadly no. But you got me looking in the right direction when you mentioned
'timeout'.
> 
> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
> 
> Just curious, have you also tested the patches on AMD hardware ?

Yes. To reproduce this the first thing I did was to get an AMD box.

> 
>  
> >> When i look at the combination of (2) and (3), It seems it could be an 
> >> interaction between the two passed through devices and/or different IRQ types.
> 
> > Could be - as in it is causing this issue to show up faster than
> > expected. Or it is the one that triggers more than one dpci happening
> > at the same time.
> 
> Well that didn't seem to be it (see separate amendment i mailed previously)

Right, the current theory I've is that the interrupts are not being
Acked within 8 milisecond and we reset the 'state' - and at the same
time we get an interrupt and schedule it - while we are still processing
the same interrupt. This would explain why the 'test_and_clear_bit'
got the wrong value.

In regards to the list poison - following this thread of logic - with
the 'state = 0' set we open the floodgates for any CPU to put the same
'struct hvm_pirq_dpci' on its list.

We do reset the 'state' on _every_ GSI that is mapped to a guest - so
we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:

CPUX:				CPUY:
pt_irq_time_out:
state = 0;			
[out of timer coder, the		raise_softirq
 pirq_dpci is on the dpci_list]		[adds the pirq_dpci as state == 0]

softirq_dpci				softirq_dpci:
	list_del
	[entries poison]
						list_del <= BOOM
			
Is what I believe is happening.

The INTX device - once I put a load on it - does not trigger
any pt_irq_time_out, so that would explain why I cannot hit this.

But I believe your card hits these "hiccups".	

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 20:58:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 20:58:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqpqs-00061P-CZ; Tue, 18 Nov 2014 20:58:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1Xqpqq-00061F-HV
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 20:58:16 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	AB/9B-07724-7E2BB645; Tue, 18 Nov 2014 20:58:15 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416344293!12313657!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27172 invoked from network); 18 Nov 2014 20:58:15 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 20:58:15 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIKwCFx023138
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Tue, 18 Nov 2014 20:58:13 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAIKwCwx005053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Tue, 18 Nov 2014 20:58:12 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIKwB59000317
	for <xen-devel@lists.xenproject.org>; Tue, 18 Nov 2014 20:58:11 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 12:58:11 -0800
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue, 18 Nov 2014 15:57:08 -0500
Message-Id: <1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1416302762.17982.1.camel@citrix.com>
References: <1416302762.17982.1.camel@citrix.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Before this patch, pv guest video_memkb is -1, which is an invalid value.
And it will cause the xenstore 'memory/targe' calculation wrong:

    memory/target = info->target_memkb - info->video_memkb

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
---
 tools/libxl/libxl_create.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..1198225 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -357,6 +357,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
+        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->video_memkb = 0;
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
         if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
-- 
1.8.3.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 20:58:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 20:58:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqpqs-00061P-CZ; Tue, 18 Nov 2014 20:58:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1Xqpqq-00061F-HV
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 20:58:16 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	AB/9B-07724-7E2BB645; Tue, 18 Nov 2014 20:58:15 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416344293!12313657!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27172 invoked from network); 18 Nov 2014 20:58:15 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2014 20:58:15 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAIKwCFx023138
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Tue, 18 Nov 2014 20:58:13 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAIKwCwx005053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Tue, 18 Nov 2014 20:58:12 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAIKwB59000317
	for <xen-devel@lists.xenproject.org>; Tue, 18 Nov 2014 20:58:11 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 12:58:11 -0800
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue, 18 Nov 2014 15:57:08 -0500
Message-Id: <1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1416302762.17982.1.camel@citrix.com>
References: <1416302762.17982.1.camel@citrix.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Before this patch, pv guest video_memkb is -1, which is an invalid value.
And it will cause the xenstore 'memory/targe' calculation wrong:

    memory/target = info->target_memkb - info->video_memkb

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
---
 tools/libxl/libxl_create.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..1198225 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -357,6 +357,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
+        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->video_memkb = 0;
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
         if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
-- 
1.8.3.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 21:06:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 21:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqpz5-0006Jz-Ly; Tue, 18 Nov 2014 21:06: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@citrix.com>) id 1Xqpz4-0006Jt-Fj
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 21:06:46 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F3/D1-17958-5E4BB645; Tue, 18 Nov 2014 21:06:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416344803!12216234!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22653 invoked from network); 18 Nov 2014 21:06:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 21:06:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,412,1413244800"; d="scan'208";a="192661017"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 16:06:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqpyS-0006Dc-4e;
	Tue, 18 Nov 2014 21:06:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqpyR-00047y-MS;
	Tue, 18 Nov 2014 21:06:07 +0000
Date: Tue, 18 Nov 2014 21:06:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31657-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31657: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31657 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31657/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 30846 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 Nov 18 21:06:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 21:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqpz5-0006Jz-Ly; Tue, 18 Nov 2014 21:06: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@citrix.com>) id 1Xqpz4-0006Jt-Fj
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 21:06:46 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F3/D1-17958-5E4BB645; Tue, 18 Nov 2014 21:06:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416344803!12216234!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22653 invoked from network); 18 Nov 2014 21:06:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 21:06:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,412,1413244800"; d="scan'208";a="192661017"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 16:06:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqpyS-0006Dc-4e;
	Tue, 18 Nov 2014 21:06:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqpyR-00047y-MS;
	Tue, 18 Nov 2014 21:06:07 +0000
Date: Tue, 18 Nov 2014 21:06:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31657-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31657: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31657 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31657/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 30846 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 Nov 18 22:13:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 22:13:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqr1B-0007JD-4M; Tue, 18 Nov 2014 22:13:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1Xqr19-0007J8-7o
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 22:12:59 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	58/F1-27584-A64CB645; Tue, 18 Nov 2014 22:12:58 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416348776!12125310!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2728 invoked from network); 18 Nov 2014 22:12:56 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 18 Nov 2014 22:12:56 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54969 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xqqzb-0003oF-CU; Tue, 18 Nov 2014 23:11:23 +0100
Date: Tue, 18 Nov 2014 23:12:54 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <348130555.20141118231254@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141118205633.GB6540@laptop.dumpdata.com>
References: <1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<20141118205633.GB6540@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------1231500C116741850"
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------1231500C116741850
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Tuesday, November 18, 2014, 9:56:33 PM, you wrote:

>> 
>> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
>> about them .. however looking at the earlier reports these lines were also in 
>> those reports).
>> 
>> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
>> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
>> and had a new default seabios config. (just to rule out anything stale in my tree)
>> 
>> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
>> seabios config) are not the most recent (they don't get updated automatically 
>> when you just do a git pull on the main tree) ?
>> 
>> In /tools/firmware/seabios-dir/.config i have:
>> CONFIG_USB=y
>> CONFIG_USB_UHCI=y
>> CONFIG_USB_OHCI=y
>> CONFIG_USB_EHCI=y
>> CONFIG_USB_XHCI=y
>> CONFIG_USB_MSC=y
>> CONFIG_USB_UAS=y
>> CONFIG_USB_HUB=y
>> CONFIG_USB_KEYBOARD=y
>> CONFIG_USB_MOUSE=y
>> 

> I seem to have the same thing. Perhaps it is my XHCI controller being wonky.

>> And this is all just from a:
>> - git clone git://xenbits.xen.org/xen.git -b staging
>> - make clean && ./configure && make -j6 && make -j6 install

> Aye. 
> .. snip..
>> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
>> >     [But this might be invalid as the addition of the ffff8303faaf25a8
>> >      might be correct - as the second dpci the softirq is processing
>> >      could be the MSI one]
>> 
>> Would there be an easy way to stress test this function separately in some 
>> debugging function to see if it indeed is returning unexpected values ?

> Sadly no. But you got me looking in the right direction when you mentioned
> 'timeout'.
>> 
>> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
>> 
>> Just curious, have you also tested the patches on AMD hardware ?

> Yes. To reproduce this the first thing I did was to get an AMD box.

>> 
>>  
>> >> When i look at the combination of (2) and (3), It seems it could be an 
>> >> interaction between the two passed through devices and/or different IRQ types.
>> 
>> > Could be - as in it is causing this issue to show up faster than
>> > expected. Or it is the one that triggers more than one dpci happening
>> > at the same time.
>> 
>> Well that didn't seem to be it (see separate amendment i mailed previously)

> Right, the current theory I've is that the interrupts are not being
> Acked within 8 milisecond and we reset the 'state' - and at the same
> time we get an interrupt and schedule it - while we are still processing
> the same interrupt. This would explain why the 'test_and_clear_bit'
> got the wrong value.

> In regards to the list poison - following this thread of logic - with
> the 'state = 0' set we open the floodgates for any CPU to put the same
> 'struct hvm_pirq_dpci' on its list.

> We do reset the 'state' on _every_ GSI that is mapped to a guest - so
> we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:

> CPUX:                           CPUY:
> pt_irq_time_out:
> state = 0;                      
> [out of timer coder, the                raise_softirq
>  pirq_dpci is on the dpci_list]         [adds the pirq_dpci as state == 0]

> softirq_dpci                            softirq_dpci:
>         list_del
>         [entries poison]
>                                                 list_del <= BOOM
>                         
> Is what I believe is happening.

> The INTX device - once I put a load on it - does not trigger
> any pt_irq_time_out, so that would explain why I cannot hit this.

> But I believe your card hits these "hiccups".   


Hi Konrad,

I just tested you 5 patches and as a result i still got an(other) host crash:
(complete serial log attached)

(XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) [2014-11-18 21:55:41.591] CPU:    0
(XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08012c7e7>]CPU:    2
(XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
(XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010006    _spin_unlock+0x1f/0x30CONTEXT: hypervisor
(XEN) [2014-11-18 21:55:41.591] 
(XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010246   rax: 0000000000000000   rbx: ffff8303773450a8   rcx: 0000000000000001
(XEN) [2014-11-18 21:55:41.591] CONTEXT: hypervisor
(XEN) [2014-11-18 21:55:41.591] rdx: 0000000000000000   rsi: ffff83054ef4ef98   rdi: 0000000012aa5400
(XEN) [2014-11-18 21:55:41.591] rax: ffff82d080328da0   rbx: ffff8305186c5d80   rcx: 0000000000000000
(XEN) [2014-11-18 21:55:41.591] rbp: ffff83054ef47c88   rsp: ffff83054ef47c78   r8:  ffff8305186c58d0
(XEN) [2014-11-18 21:55:41.591] r9:  000000000000002f   r10: 00000000000000d0   r11: ffffffff829084b0
(XEN) [2014-11-18 21:55:41.591] rdx: ffff82d0802e0000   rsi: ffff83050aead2a8   rdi: 00000000000000b8
(XEN) [2014-11-18 21:55:41.591] rbp: ffff82d0802e7df8   rsp: ffff82d0802e7df8   r8:  ffff82d0802e7d28
(XEN) [2014-11-18 21:55:41.591] r9:  0000000000000040   r10: 0000000000000000   r11: ffffffffffffffc0
(XEN) [2014-11-18 21:55:41.591] r12: ffff8305186c5d80   r13: ffff8303773450a8   r14: ffff8303773450b8
(XEN) [2014-11-18 21:55:41.591] r15: ffff8305186c5b00   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2014-11-18 21:55:41.591] r12: ffff830515b5b000   r13: 0000000000000000   r14: ffff830377345080
(XEN) [2014-11-18 21:55:41.591] cr3: 000000054a215000   cr2: 00000000000000b8
(XEN) [2014-11-18 21:55:41.591] r15: 000000000000002f   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2014-11-18 21:55:41.591] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) [2014-11-18 21:55:41.591] cr3: 000000054a215000   cr2: 0000000000000160
(XEN) [2014-11-18 21:55:41.591] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) [2014-11-18 21:55:41.591] Xen stack trace from rsp=ffff82d0802e7df8:
(XEN) [2014-11-18 21:55:41.591]    ffff82d0802e7e48Xen stack trace from rsp=ffff83054ef47c78:
(XEN) [2014-11-18 21:55:41.591]    ffff82d08014a395 ffff83009fd2d060 ffff83054ef47c88 ffff8303773450b8
(XEN) [2014-11-18 21:55:41.591]    ffffc900141f2b20 ffff82d080328f80 ffff830377345140 ffff82d08014a26e ffff8303773450a8 ffff83054ef47d18
(XEN) [2014-11-18 21:55:41.591]    ffff82d080172060 000000943f43e518 ffff88002b227e18 ffff82d0802e7e78
(XEN) [2014-11-18 21:55:41.591]    ffff82d08012f2c3 0000000000000286
(XEN) [2014-11-18 21:55:41.591]    0000000100000031 ffff82d08018b20f ffff82d080328f80 ffff83050b0bb5e0 ffff83054ef47cf8 ffff82d080178846 ffff8303773450e0
(XEN) [2014-11-18 21:55:41.591]   
(XEN) [2014-11-18 21:55:41.591]    ffff82d0802e7ec8 ffff82d08012f3c3 ffff82d0802e7ef8 0000000000000000 ffff82d08022d5a1
(XEN) [2014-11-18 21:55:41.591]    000000943f65d8b4 ffff83055d002f24 0000000000000000 0000002f9ff88000
(XEN) [2014-11-18 21:55:41.591]    ffff82d0802fff80 ffff83054ef47d28 000000000055d126 ffff83054ef12000 ffff82d0802fff80 ffffffffffffffff
(XEN) [2014-11-18 21:55:41.591]    ffff830515b5b0b8 ffff82d0802e0000 ffff88002b227e18
(XEN) [2014-11-18 21:55:41.591]    ffff82d0802e7ef8 ffff82d0802fff80 ffff82d08012be31 ffff8303773450a8 ffff830515b5b000
(XEN) [2014-11-18 21:55:41.591]    0200200200200200 ffff83009fd2d000
(XEN) [2014-11-18 21:55:41.591]    00007cfab10b82b7 0000000000000001 ffff82d080233122 0200200200200200 ffff830515b5b000
(XEN) [2014-11-18 21:55:41.591]    0000000000000001 ffff88005925a1e8
(XEN) [2014-11-18 21:55:41.591]    ffff8303773450a8 ffff82d0802fff80 ffff82d0802e7f08 ffff82d08012be89 ffff83054ef47dd8 00007d2f7fd180c7 ffff830515b5b0b8 ffff82d080232cd1
(XEN) [2014-11-18 21:55:41.591]    ffff88002b227e18 ffff88005925a1e8
(XEN) [2014-11-18 21:55:41.591]    0000000000000001 0000000000000001
(XEN) [2014-11-18 21:55:41.591]    ffff88002b227bb8 ffffffff829084b0 ffff88005f6d35a8 0000000000000000 0000000000000000
(XEN) [2014-11-18 21:55:41.591]    00000000000000d0 000000943f4e172d 0000000000000000 ffff830377345150 0000000000005776 ffffffff81c10cc0
(XEN) [2014-11-18 21:55:41.591]    000000943f43e300 0000000000000000
(XEN) [2014-11-18 21:55:41.591]    0000000000000001 0000000000000001 0000000000000000 ffff83054ef4ef98
(XEN) [2014-11-18 21:55:41.591]    ffff830515b5b0bc 000000b900000000 ffff82d08012c69f ffff88005925a180 ffff88005f6d3500 000000000000e008 000000fa00000000
(XEN) [2014-11-18 21:55:41.591]    0000000000000246
(XEN) [2014-11-18 21:55:41.591]    ffffffff810eab63 ffff83054ef47dd0 000000000000e033 0000000000000000 0000000000000286 ffff830377345110 ffff88002b227b68
(XEN) [2014-11-18 21:55:41.591]   
(XEN) [2014-11-18 21:55:41.591]    000000000000e02b ffff83054ef47ec8 ffff82d08014962d 000000000000beef 0000000000000100 ffff82d080328da0
(XEN) [2014-11-18 21:55:41.591]    000000000000beef 000000000000beef
(XEN) [2014-11-18 21:55:41.591]    000000000000beef 0000000000000000 ffff83009fd2d000 ffff830512b6c068 0000000000000000 ffff83054ef4e540
(XEN) [2014-11-18 21:55:41.591]    ffff83054ef4e400 0000000000000000
(XEN) [2014-11-18 21:55:41.591] Xen call trace:
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d08012c7e7>] _spin_unlock+0x1f/0x30
(XEN) [2014-11-18 21:55:41.591]  ffff830515b5b0b8
(XEN) [2014-11-18 21:55:41.591]    0000000100000000 ffff83054ef47e88   [<ffff82d08014a395>] pt_irq_time_out+0x127/0x136
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d08012f2c3>] execute_timer+0x4e/0x6c
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d08012f3c3>] timer_softirq_action+0xe2/0x220
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d08012be31>] __do_softirq+0x81/0x8c
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d08012be89>] do_softirq+0x13/0x15
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d080232cd1>] process_softirqs+0x21/0x30
(XEN) [2014-11-18 21:55:41.591] 
(XEN) [2014-11-18 21:55:41.591]  ffff83054ef47e88 ffff83054ef47e88Pagetable walk from 00000000000000b8:
(XEN) [2014-11-18 21:55:41.591] 
(XEN) [2014-11-18 21:55:41.591]    ffff8303773450a8 L4[0x000] = 0000000000000000 ffffffffffffffff
(XEN) [2014-11-18 21:55:41.591]  0000000000000082 ffff8303773450a8
(XEN) [2014-11-18 21:55:43.260] ****************************************
(XEN) [2014-11-18 21:55:43.280]  ffff830377345150Panic on CPU 0:
(XEN) [2014-11-18 21:55:43.297] FATAL PAGE FAULT
(XEN) [2014-11-18 21:55:43.310] [error_code=0000]
(XEN) [2014-11-18 21:55:43.323] Faulting linear address: 00000000000000b8
(XEN) [2014-11-18 21:55:43.343] ****************************************
(XEN) [2014-11-18 21:55:43.362] 
(XEN) [2014-11-18 21:55:43.371] Reboot in five seconds...
(XEN) [2014-11-18 21:55:43.386] 
(XEN) [2014-11-18 21:55:43.395]    ffff830515b5b000 0000000000000001 ffff830377345080 000000000000002f
(XEN) [2014-11-18 21:55:43.422]    ffff83054ef47f08 ffff82d0801721a3 ffff83054ef47e88 ffff83054ef47e88
(XEN) [2014-11-18 21:55:43.449]    00000ecc00000004 ffff82d080300080 ffff82d0802fff80 ffffffffffffffff
(XEN) [2014-11-18 21:55:43.476]    ffff83054ef40000 0000000000000001 ffff83054ef47ef8 ffff82d08012be31
(XEN) [2014-11-18 21:55:43.503]    ffff83009ff88000 ffffffff83081590 ffffffff8221c520 ffffffff8221cc20
(XEN) [2014-11-18 21:55:43.530] Xen call trace:
(XEN) [2014-11-18 21:55:43.543]    [<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
(XEN) [2014-11-18 21:55:43.565]    [<ffff82d080172060>] do_IRQ+0x49c/0x624
(XEN) [2014-11-18 21:55:43.584]    [<ffff82d080233122>] common_interrupt+0x62/0x70
(XEN) [2014-11-18 21:55:43.606]    [<ffff82d08012c69f>] _spin_lock+0x1a/0x54
(XEN) [2014-11-18 21:55:43.626]    [<ffff82d08014962d>] dpci_softirq+0x241/0x3ad
(XEN) [2014-11-18 21:55:43.648]    [<ffff82d08012be31>] __do_softirq+0x81/0x8c
(XEN) [2014-11-18 21:55:43.669]    [<ffff82d08012be89>] do_softirq+0x13/0x15
(XEN) [2014-11-18 21:55:43.689]    [<ffff82d080232cd1>] process_softirqs+0x21/0x30
(XEN) [2014-11-18 21:55:43.711] 
(XEN) [2014-11-18 21:55:43.720] Pagetable walk from 0000000000000160:
(XEN) [2014-11-18 21:55:43.738]  L4[0x000] = 0000000000000000 ffffffffffffffff
(XEN) [2014-11-18 21:55:43.759] 
(XEN) [2014-11-18 21:55:43.768] ****************************************
(XEN) [2014-11-18 21:55:43.787] Panic on CPU 2:
(XEN) [2014-11-18 21:55:43.800] FATAL PAGE FAULT
(XEN) [2014-11-18 21:55:43.813] [error_code=0002]
(XEN) [2014-11-18 21:55:43.826] Faulting linear address: 0000000000000160
(XEN) [2014-11-18 21:55:43.845] ****************************************
(XEN) [2014-11-18 21:55:43.865] 
(XEN) [2014-11-18 21:55:43.873] Reboot in five seconds...

# addr2line -e xen-syms ffff82d08012c7e7
/usr/src/new/xen-unstable-vanilla/xen/include/asm/spinlock.h:18
# addr2line -e xen-syms ffff82d08014a461
/usr/src/new/xen-unstable-vanilla/xen/include/asm/atomic.h:172
# addr2line -e xen-syms ffff82d080172060
/usr/src/new/xen-unstable-vanilla/xen/arch/x86/irq.c:1175
# addr2line -e xen-syms ffff82d080233122
/usr/src/new/xen-unstable-vanilla/xen/arch/x86/x86_64/entry.S:487
# addr2line -e xen-syms ffff82d08012c69f
/usr/src/new/xen-unstable-vanilla/xen/common/spinlock.c:126
# addr2line -e xen-syms ffff82d08014962d
/usr/src/new/xen-unstable-vanilla/xen/drivers/passthrough/io.c:835
# addr2line -e xen-syms ffff82d08014a395
/usr/src/new/xen-unstable-vanilla/xen/drivers/passthrough/io.c:339
# addr2line -e xen-syms ffff82d08012f2c3
/usr/src/new/xen-unstable-vanilla/xen/common/timer.c:426
------------1231500C116741850
Content-Type: application/octet-stream;
 name="serial.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial.log"

77u/IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgIF9fXyAgICAgICAgICAgICAg
DQogXCBcLyAvX19fIF8gX18gICB8IHx8IHwgIHwgX19ffCAvIF8gXCAgICBfIF9fIF9fXyAN
CiAgXCAgLy8gXyBcICdfIFwgIHwgfHwgfF8gfF9fXyBcfCB8IHwgfF9ffCAnX18vIF9ffA0K
ICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8IHxffCB8X198IHwgfCAoX18gDQog
L18vXF9cX19ffF98IHxffCAgICB8X3woXylfX19fKF8pX19fLyAgIHxffCAgXF9fX3wNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KKFhF
TikgWGVuIHZlcnNpb24gNC41LjAtcmMgKHJvb3RAZHluZG5zLm9yZykgKGdjYy00LjcucmVh
bCAoRGViaWFuIDQuNy4yLTUpIDQuNy4yKSBkZWJ1Zz15IFR1ZSBOb3YgMTggMjI6Mzc6NTgg
Q0VUIDIwMTQNCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IFdlZCBOb3YgNSAxNDozMjo0NyAy
MDE0ICswMDAwIGdpdDowOWZmOGVhLWRpcnR5DQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEu
OTktMjcrZGViN3UyDQooWEVOKSBDb21tYW5kIGxpbmU6IGRvbTBfbWVtPTE1MzZNLG1heDox
NTM2TSBsb2dsdmw9YWxsIGxvZ2x2bF9ndWVzdD1hbGwgY29uc29sZV90aW1lc3RhbXBzPWRh
dGVtcyB2Z2E9Z2Z4LTEyODB4MTAyNHgzMiBuby1jcHVpZGxlIGNvbTE9Mzg0MDAsOG4xIGNv
bnNvbGU9dmdhLGNvbTEgaXZyc19pb2FwaWNbNl09MDA6MTQuMCBpb21tdT1vbix2ZXJib3Nl
LGRlYnVnLGFtZC1pb21tdS1kZWJ1ZyBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGljX3ZlcmJvc2l0
eT1kZWJ1ZyBhcGljPWRlYnVnDQooWEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoNCihYRU4pICBW
R0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgweDEwMjQsIDMyIGJwcA0KKFhFTikgIFZCRS9EREMg
bWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzDQooWEVOKSBEaXNj
IGluZm9ybWF0aW9uOg0KKFhFTikgIEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMNCihYRU4pICBG
b3VuZCAyIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzDQooWEVOKSBYZW4tZTgyMCBSQU0g
bWFwOg0KKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDk5NDAwICh1c2Fi
bGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5OTQwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2Vy
dmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAwZTQwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNl
cnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDA5ZmY5MDAwMCAodXNh
YmxlKQ0KKFhFTikgIDAwMDAwMDAwOWZmOTAwMDAgLSAwMDAwMDAwMDlmZjllMDAwIChBQ1BJ
IGRhdGEpDQooWEVOKSAgMDAwMDAwMDA5ZmY5ZTAwMCAtIDAwMDAwMDAwOWZmZTAwMDAgKEFD
UEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAwOWZmZTAwMDAgLSAwMDAwMDAwMGEwMDAwMDAwIChy
ZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAo
cmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDA1NjAwMDAwMDAg
KHVzYWJsZSkNCihYRU4pIEFDUEk6IFJTRFAgMDAwRkIxMDAsIDAwMTQgKHIwIEFDUElBTSkN
CihYRU4pIEFDUEk6IFJTRFQgOUZGOTAwMDAsIDAwNDggKHIxIE1TSSAgICBPRU1TTElDICAy
MDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogRkFDUCA5RkY5MDIwMCwgMDA4
NCAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBB
Q1BJOiBEU0RUIDlGRjkwNUUwLCA5NDI3IChyMSAgQTc2NDAgQTc2NDAxMDAgICAgICAxMDAg
SU5UTCAyMDA1MTExNykNCihYRU4pIEFDUEk6IEZBQ1MgOUZGOUUwMDAsIDAwNDANCihYRU4p
IEFDUEk6IEFQSUMgOUZGOTAzOTAsIDAwODggKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkx
MyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogTUNGRyA5RkY5MDQyMCwgMDAzQyAocjEg
NzY0ME1TIE9FTU1DRkcgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBT
TElDIDlGRjkwNDYwLCAwMTc2IChyMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA5MTMgTVNGVCAg
ICAgICA5NykNCihYRU4pIEFDUEk6IE9FTUIgOUZGOUUwNDAsIDAwNzIgKHIxIDc2NDBNUyBB
NzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogU1JBVCA5RkY5
QTVFMCwgMDEwOCAocjMgQU1EICAgIEZBTV9GXzEwICAgICAgICAyIEFNRCAgICAgICAgIDEp
DQooWEVOKSBBQ1BJOiBIUEVUIDlGRjlBNkYwLCAwMDM4IChyMSA3NjQwTVMgT0VNSFBFVCAg
MjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IElWUlMgOUZGOUE3MzAsIDAx
MTAgKHIxICBBTUQgICAgIFJEODkwUyAgIDIwMjAzMSBBTUQgICAgICAgICAwKQ0KKFhFTikg
QUNQSTogU1NEVCA5RkY5QTg0MCwgMERBNCAocjEgQSBNIEkgIFBPV0VSTk9XICAgICAgICAx
IEFNRCAgICAgICAgIDEpDQooWEVOKSBTeXN0ZW0gUkFNOiAyMDQ3OU1CICgyMDk3MDY2MGtC
KQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUgMA0KKFhFTikgU1JBVDog
UFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAy
IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAzIC0+IE5vZGUgMA0KKFhF
TikgU1JBVDogUFhNIDAgLT4gQVBJQyA0IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAg
LT4gQVBJQyA1IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDAtYTAwMDAN
CihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAtYTAwMDAwMDANCihYRU4pIFNSQVQ6
IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtNTYwMDAwMDAwDQooWEVOKSBOVU1BOiBBbGxvY2F0
ZWQgbWVtbm9kZW1hcCBmcm9tIDU1ZDBhZjAwMCAtIDU1ZDBiNTAwMA0KKFhFTikgTlVNQTog
VXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQooWEVOKSBEb21haW4gaGVhcCBpbml0aWFs
aXNlZA0KKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGQwMDAwMDAwLCBtYXBwZWQg
dG8gMHhmZmZmODJjMDAwMjAxMDAwLCB1c2luZyA2MTQ0aywgdG90YWwgMTYzODRrDQooWEVO
KSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMyLCBsaW5lbGVuZ3RoPTUxMjAsIGZvbnQg
OHgxNg0KKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6IHNpemU9MDo4Ojg6OCwgc2hpZnQ9MDox
Njo4OjANCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAwMDBmZjc4MA0KKFhFTikgRE1J
IHByZXNlbnQuDQooWEVOKSBBUElDIGJvb3Qgc3RhdGUgaXMgJ3hhcGljJw0KKFhFTikgVXNp
bmcgQVBJQyBkcml2ZXIgZGVmYXVsdA0KKFhFTikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDog
MHg4MDgNCihYRU4pIEFDUEk6IFNMRUVQIElORk86IHBtMXhfY250WzE6ODA0LDE6MF0sIHBt
MXhfZXZ0WzE6ODAwLDE6MF0NCihYRU4pIEFDUEk6ICAgICAgICAgICAgIHdha2V1cF92ZWNb
OWZmOWUwMGNdLCB2ZWNfc2l6ZVsyMF0NCihYRU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVz
cyAweGZlZTAwMDAwDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19p
ZFsweDAwXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMwIDA6MTAgQVBJQyB2ZXJzaW9u
IDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBl
bmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMxIDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0K
KFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAzXSBlbmFibGVkKQ0KKFhFTikgUHJv
Y2Vzc29yICMzIDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICM0
IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2
XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICM1IDA6MTAgQVBJ
QyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDZdIGFkZHJlc3NbMHhm
ZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pDQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgNiwgdmVy
c2lvbiAzMywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0yMw0KKFhFTikgQUNQSTogSU9B
UElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVjMjAwMDBdIGdzaV9iYXNlWzI0XSkNCihYRU4p
IElPQVBJQ1sxXTogYXBpY19pZCA3LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMjAwMDAs
IEdTSSAyNC01NQ0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBn
bG9iYWxfaXJxIDIgZGZsIGRmbCkNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBi
dXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZlbCkNCihYRU4pIEFDUEk6IElSUTAgdXNl
ZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NCihY
RU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEVuYWJsaW5nIEFQSUMg
bW9kZTogIEZsYXQuICBVc2luZyAyIEkvTyBBUElDcw0KKFhFTikgQUNQSTogSFBFVCBpZDog
MHg4MzAwIGJhc2U6IDB4ZmVkMDAwMDANCihYRU4pIEVSU1QgdGFibGUgd2FzIG5vdCBmb3Vu
ZA0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9y
bWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBob3RwbHVnIENQVXMpDQoo
WEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjZmZmZGZiMDAwIChmZWUwMDAwMCkNCihYRU4p
IG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyY2ZmZmRmYTAwMCAoZmVjMDAwMDApDQooWEVOKSBt
YXBwZWQgSU9BUElDIHRvIGZmZmY4MmNmZmZkZjkwMDAgKGZlYzIwMDAwKQ0KKFhFTikgSVJR
IGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWA0KKFhFTikgVXNpbmcgc2NoZWR1bGVy
OiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikgRGV0ZWN0ZWQgMzIwMC4x
MzIgTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuDQooWEVO
KSBBTUQgRmFtMTBoIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQNCihYRU4pIGFs
dCB0YWJsZSBmZmZmODJkMDgwMmQ5ZWYwIC0+IGZmZmY4MmQwODAyZGFmMTANCihYRU4pIFBD
STogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAgc2VnbWVudCAwMDAwIGJ1
c2VzIDAwIC0gZmYNCihYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21lbnQgMDAw
MCBidXMgMDAtZmYNCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNhcGFiaWxpdHkgYmxvY2sg
YXQgMHg1NA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhFTikgQU1ELVZpOiAgU2ln
bmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweDExMA0KKFhFTikgQU1ELVZp
OiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBDaGVja1N1bSAweGViDQooWEVOKSBB
TUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1WaTogIE9FTV9UYWJsZV9JZCBSRDg5
MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAweDIwMjAzMQ0KKFhFTikgQU1ELVZp
OiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6ICBDcmVhdG9yX1JldmlzaW9uIDAN
CihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazogdHlwZSAweDEwIGZsYWdzIDB4M2UgbGVuIDB4
ZTAgaWQgMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBp
ZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDINCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MTAgZmxhZ3Mg
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHhmMDAg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweGYwMCAtPiAweGYwMQ0K
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgxOCBmbGFn
cyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweGUw
MCBmbGFncyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4ZTAwIC0+IDB4ZTAx
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDI4IGZs
YWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4
ZDAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgy
IGlkIDB4MzAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlw
ZSAweDIgaWQgMHhjMDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eTogdHlwZSAweDIgaWQgMHg0OCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5OiB0eXBlIDB4MiBpZCAweGIwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDUwIGZsYWdzIDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTAwIGZsYWdzIDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NTggZmxhZ3MgMA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHg5MDAgZmxhZ3Mg
MA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwMCAtPiAweDkwMQ0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg2MCBmbGFncyAwDQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDUwMCBmbGFn
cyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDYw
OCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBp
ZCAweDgwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweDYxMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
OiB0eXBlIDB4MiBpZCAweDcwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5OiB0eXBlIDB4MiBpZCAweDY4IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NDAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4ODggZmxhZ3MgMA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHg5MCBmbGFncyAwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4OTAgLT4gMHg5Mg0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHg5OCBmbGFncyAwDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgUmFuZ2U6IDB4OTggLT4gMHg5YQ0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhMCBmbGFncyAweGQ3DQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGEyIGZsYWdzIDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTMgZmxhZ3MgMA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhNCBmbGFncyAw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4NDMgaWQgMHgzMDAg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDMwMCAtPiAweDNmZiBh
bGlhcyAweGE0DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBp
ZCAweGE1IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUg
MHgyIGlkIDB4YTggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHhhOSBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4MiBpZCAweDEwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweGIwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERl
dl9JZCBSYW5nZTogMHhiMCAtPiAweGIyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDAgaWQgMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4NDggaWQgMCBmbGFncyAweGQ3DQooWEVOKSBBTUQtVmk6IElWSEQgU3Bl
Y2lhbDogMDAwMDowMDoxNC4wIHZhcmlldHkgMHgyIGhhbmRsZSAwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4NDggaWQgMCBmbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgU3BlY2lhbDogMDAwMDowMDowMC4xIHZhcmlldHkgMHgxIGhhbmRsZSAweDcN
CihYRU4pIEFNRC1WaTogRGlzYWJsZWQgSEFQIG1lbW9yeSBtYXAgc2hhcmluZyB3aXRoIElP
TU1VDQooWEVOKSBBTUQtVmk6IElPTU1VIDAgRW5hYmxlZC4NCihYRU4pIEkvTyB2aXJ0dWFs
aXNhdGlvbiBlbmFibGVkDQooWEVOKSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQNCihYRU4pIElu
dGVycnVwdCByZW1hcHBpbmcgZW5hYmxlZA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1
MDAxMA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBJ
RDogMA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDANCihYRU4pIEdldHRpbmcgTFZUMTogNDAw
DQooWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUjMA0KKFhFTikgRVNSIHZhbHVlIGJlZm9y
ZSBlbmFibGluZyB2ZWN0b3I6IDB4NCAgYWZ0ZXI6IDANCihYRU4pIEVOQUJMSU5HIElPLUFQ
SUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9kDQooWEVOKSBpbml0IElP
X0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFwaWNpZC1waW4pIDYtMCwgNi0xNiwgNi0x
NywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0yMiwgNi0yMywgNy0wLCA3LTEsIDctMiwg
Ny0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwgNy05LCA3LTEwLCA3LTExLCA3LTEyLCA3
LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3
LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3
LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0w
IHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVOKSBudW1iZXIgb2YgTVAgSVJRIHNvdXJj
ZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQSUMgIzYgcmVnaXN0ZXJzOiAyNC4NCihY
RU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lzdGVyczogMzIuDQooWEVOKSB0ZXN0aW5n
IHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCihYRU4pIElPIEFQSUMgIzYu
Li4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwNjAwMDAwMA0KKFhFTikgLi4uLi4u
LiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZl
cnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4p
IC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXgg
cmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1w
bGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIx
DQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAg
IDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMzogMDcwMDAwMDAN
CihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAgICA6IDANCihYRU4pIC4uLi4gSVJRIHJl
ZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wg
U3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4pICAwMCAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAxICAgIDMwDQooWEVOKSAgMDEgMDAxIDAxICAwICAgIDAgICAg
MCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhFTikgIDAyIDAwMSAwMSAgMCAgICAwICAg
IDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihYRU4pICAwMyAwMDEgMDEgIDAgICAgMCAg
ICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQooWEVOKSAgMDQgMDAxIDAxICAwICAgIDAg
ICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0KKFhFTikgIDA1IDAwMSAwMSAgMCAgICAw
ICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDANCihYRU4pICAwNiAwMDEgMDEgIDAgICAg
MCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4DQooWEVOKSAgMDcgMDAxIDAxICAwICAg
IDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1MA0KKFhFTikgIDA4IDAwMSAwMSAgMCAg
ICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTgNCihYRU4pICAwOSAwMDEgMDEgIDEg
ICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAwICAgIDAwDQooWEVOKSAgMGEgMDAxIDAxICAw
ICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA2OA0KKFhFTikgIDBiIDAwMSAwMSAg
MCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzANCihYRU4pICAwYyAwMDEgMDEg
IDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4DQooWEVOKSAgMGQgMDAxIDAx
ICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA4OA0KKFhFTikgIDBlIDAwMSAw
MSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgOTANCihYRU4pICAwZiAwMDEg
MDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDk4DQooWEVOKSAgMTAgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAzMA0KKFhFTikgIDExIDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzANCihYRU4pICAxMiAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwDQooWEVOKSAgMTMg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAzMA0KKFhFTikgIDE0
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzANCihYRU4pICAx
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwDQooWEVOKSAg
MTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAzMA0KKFhFTikg
IDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzANCihYRU4p
IElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwNzAwMDAwMA0K
KFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA3DQooWEVOKSAuLi4uLi4u
ICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExUUyAgICAgICAg
ICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDFGODAyMQ0KKFhFTikgLi4uLi4u
LiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxRg0KKFhFTikgLi4uLi4uLiAg
ICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2
ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDAwMDAwMDANCihYRU4p
IC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVj
dGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQg
RGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAxIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMiAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDMgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA0IDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNSAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDYgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA3IDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwOCAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDkgMDAwIDAwICAxICAgIDAg
ICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBhIDAwMCAwMCAgMSAgICAw
ICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwYiAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGMgMDAwIDAwICAxICAg
IDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBkIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwZSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGYgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEwIDAwMCAwMCAg
MSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNyAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTgg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE5
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAx
YSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZw0KKFhFTikgSVJRIHRvIHBpbiBtYXBw
aW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihYRU4pIElSUTQ4IC0+IDA6MQ0KKFhFTikg
SVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4gMDo0DQooWEVOKSBJUlE2NCAtPiAwOjUN
CihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJRODAgLT4gMDo3DQooWEVOKSBJUlE4OCAt
PiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhFTikgSVJRMTA0IC0+IDA6MTANCihYRU4p
IElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAgLT4gMDoxMg0KKFhFTikgSVJRMTM2IC0+
IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQooWEVOKSBJUlExNTIgLT4gMDoxNQ0KKFhF
TikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIGRvbmUuDQooWEVOKSBV
c2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVwdHMuDQooWEVOKSBjYWxpYnJhdGluZyBB
UElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BVIGNsb2NrIHNwZWVkIGlzIDMyMDAuMjA5
MyBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBjbG9jayBzcGVlZCBpcyAyMDAuMDEzMCBN
SHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAweGNjZDcNCihYRU4pIFsyMDE0LTExLTE4
IDIxOjQ1OjExLjU2Ml0gUGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjExLjU4M10gQWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2
NCBLaUIuDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS41ODldIEhWTTogQVNJRHMgZW5h
YmxlZC4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjU5NV0gU1ZNOiBTdXBwb3J0ZWQg
YWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS42MDFdICAt
IE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTEu
NjA3XSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24NCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjExLjYxNF0gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJ
VA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTEuNjIwXSAgLSBQYXVzZS1JbnRlcmNlcHQg
RmlsdGVyDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS42MjZdIEhWTTogU1ZNIGVuYWJs
ZWQNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjYzMl0gSFZNOiBIYXJkd2FyZSBBc3Np
c3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEx
LjYzOV0gSFZNOiBIQVAgcGFnZSBzaXplczogNGtCLCAyTUIsIDFHQg0KKFhFTikgWzIwMTQt
MTEtMTggMjE6NDU6MTEuNjQ1XSBIVk06IFBWSCBtb2RlIG5vdCBzdXBwb3J0ZWQgb24gdGhp
cyBwbGF0Zm9ybQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTEuNjcyXSBtYXNrZWQgRXh0
SU5UIG9uIENQVSMxDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS42OThdIG1hc2tlZCBF
eHRJTlQgb24gQ1BVIzINCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjcyNV0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTEuNzUyXSBtYXNr
ZWQgRXh0SU5UIG9uIENQVSM0DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS43NzhdIG1h
c2tlZCBFeHRJTlQgb24gQ1BVIzUNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjc4NV0g
QnJvdWdodCB1cCA2IENQVXMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjgxNV0gQUNQ
SSBzbGVlcCBtb2RlczogUzMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjgyMV0gTUNB
OiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NDU6MTEuODI4XSBtY2hlY2tfcG9sbDogTWFjaGluZSBjaGVj
ayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS44
MzVdIFhlbm9wcm9maWxlOiBGYWlsZWQgdG8gc2V0dXAgSUJTIExWVCBvZmZzZXQsIElCU0NU
TCA9IDB4ZmZmZmZmZmYNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjg0MV0gKioqIExP
QURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4wMTBdIGVs
Zl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weDEwNjQwMDAN
CihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEyLjAxN10gZWxmX3BhcnNlX2JpbmFyeTogcGhk
cjogcGFkZHI9MHgyMjAwMDAwIG1lbXN6PTB4MTA2MDAwDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo0NToxMi4wMjRdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MjMwNjAwMCBt
ZW1zej0weDE0MjgwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4wMzFdIGVsZl9wYXJz
ZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MjMxYjAwMCBtZW1zej0weDExNDAwMDANCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjEyLjAzOF0gZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5OiAw
eDEwMDAwMDAgLT4gMHgzNDViMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4wNDVd
IGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAxNC0x
MS0xOCAyMTo0NToxMi4wNTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9
ICIyLjYiDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4wNjBdIGVsZl94ZW5fcGFyc2Vf
bm90ZTogWEVOX1ZFUlNJT04gPSAieGVuLTMuMCINCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1
OjEyLjA2N10gZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAw
MDAwMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEyLjA3NV0gZWxmX3hlbl9wYXJzZV9u
b3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4MjMxYjFmMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NDU6MTIuMDgyXSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZm
ZmZmZjgxMDAxMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4wOTBdIGVsZl94ZW5f
cGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rp
cl9hYm92ZV80Z2J8d3JpdGFibGVfZGVzY3JpcHRvcl90YWJsZXN8YXV0b190cmFuc2xhdGVk
X3BoeXNtYXB8c3VwZXJ2aXNvcl9tb2RlX2tlcm5lbCINCihYRU4pIFsyMDE0LTExLTE4IDIx
OjQ1OjEyLjEwNV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVBQT1JURURfRkVBVFVSRVMgPSAw
eDkwZA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMTEzXSBlbGZfeGVuX3BhcnNlX25v
dGU6IFBBRV9NT0RFID0gInllcyINCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEyLjEyMV0g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyINCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjQ1OjEyLjEyOV0gZWxmX3hlbl9wYXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYg
bm90ZSAoMHhkKQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMTM3XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0
NToxMi4xNDVdIGVsZl94ZW5fcGFyc2Vfbm90ZTogTU9EX1NUQVJUX1BGTiA9IDB4MQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMTU0XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhWX1NU
QVJUX0xPVyA9IDB4ZmZmZjgwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6
MTIuMTYyXSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MA0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NDU6MTIuMTcxXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRk
cmVzc2VzOg0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMTc5XSAgICAgdmlydF9iYXNl
ICAgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6
MTIuMTg4XSAgICAgZWxmX3BhZGRyX29mZnNldCA9IDB4MA0KKFhFTikgWzIwMTQtMTEtMTgg
MjE6NDU6MTIuMTk3XSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAw
MA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMjA2XSAgICAgdmlydF9rc3RhcnQgICAg
ICA9IDB4ZmZmZmZmZmY4MTAwMDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMjE1
XSAgICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZmZmZmZmY4MzQ1YjAwMA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NDU6MTIuMjI0XSAgICAgdmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZm
ZmY4MjMxYjFmMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMjMzXSAgICAgcDJtX2Jh
c2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZmZg0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NDU6MTIuMjQzXSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMg0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NDU6MTIuMjUyXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBs
c2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDM0NWIwMDANCihYRU4pIFsyMDE0LTExLTE4IDIx
OjQ1OjEyLjI2M10gUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTQt
MTEtMTggMjE6NDU6MTIuMjcyXSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDU0ODAwMDAwMC0+
MDAwMDAwMDU0YzAwMDAwMCAoMzcyOTM4IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjEyLjI4M10gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDA1NWYw
Y2EwMDAtPjAwMDAwMDA1NWZmZmZhMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEyLjI5
NF0gVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0
NToxMi4zMDRdICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgz
NDViMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4zMTRdICBJbml0LiByYW1kaXNr
OiAwMDAwMDAwMDAwMDAwMDAwLT4wMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo0NToxMi4zMjVdICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgzNDViMDAwLT5mZmZm
ZmZmZjgzNzViMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4zMzVdICBTdGFydCBp
bmZvOiAgICBmZmZmZmZmZjgzNzViMDAwLT5mZmZmZmZmZjgzNzViNGI0DQooWEVOKSBbMjAx
NC0xMS0xOCAyMTo0NToxMi4zNDZdICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzNzVjMDAw
LT5mZmZmZmZmZjgzNzdiMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4zNTddICBC
b290IHN0YWNrOiAgICBmZmZmZmZmZjgzNzdiMDAwLT5mZmZmZmZmZjgzNzdjMDAwDQooWEVO
KSBbMjAxNC0xMS0xOCAyMTo0NToxMi4zNjhdICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgw
MDAwMDAwLT5mZmZmZmZmZjgzODAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4z
NzhdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgyMzFiMWYwDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo0NToxMi4zOTBdIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcw0KKFhFTikgWzIwMTQt
MTEtMTggMjE6NDU6MTIuNDAxXSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMCBhdCAweGZmZmZm
ZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgyMDY0MDAwDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo0NToxMi40MTldIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MjIw
MDAwMCAtPiAweGZmZmZmZmZmODIzMDYwMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEy
LjQzMF0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgyMzA2MDAwIC0+
IDB4ZmZmZmZmZmY4MjMxYTI4MA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuNDQxXSBl
bGZfbG9hZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODIzMWIwMDAgLT4gMHhmZmZm
ZmZmZjgyNDIzMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMy41ODJdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDAsIHR5cGUgPSAweDYsIHJvb3Qg
dGFibGUgPSAweDU0ZWVkYzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVO
KSBbMjAxNC0xMS0xOCAyMTo0NToxMy41OTNdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MiwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRj
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIx
OjQ1OjEzLjYwNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgxMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjYxN10gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgxOCwgdHlwZSA9IDB4
Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjYyOV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyOCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9
IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0
LTExLTE4IDIxOjQ1OjEzLjY0MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgzMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEz
LjY1NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0OCwg
dHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjY2Nl0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1MCwgdHlwZSA9IDB4Miwgcm9v
dCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjY3OV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHg1OCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRl
ZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4
IDIxOjQ1OjEzLjY5Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHg2MCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjcwNl0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg2OCwgdHlwZSA9
IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjcxOV0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg4OCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJs
ZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDE0LTExLTE4IDIxOjQ1OjEzLjczM10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHg5MCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1
OjEzLjc0N10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5
MiwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjc2MV0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgdHlwZSA9IDB4Nywg
cm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjc3NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5YSwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4
NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjQ1OjEzLjc4OV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHhhMCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjgw
M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMiwgdHlw
ZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjgxOF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMywgdHlwZSA9IDB4Nywgcm9vdCB0
YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjEzLjgzM10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHhhNCwgdHlwZSA9IDB4NSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRj
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIx
OjQ1OjEzLjg0N10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHhhNSwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjg2Ml0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhOCwgdHlwZSA9IDB4
Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjg3N10gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9
IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0
LTExLTE4IDIxOjQ1OjEzLjg5M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHhiMiwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEz
LjkwOF0gQU1ELVZpOiBTa2lwcGluZyBob3N0IGJyaWRnZSAwMDAwOjAwOjE4LjANCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjEzLjkyM10gQU1ELVZpOiBTa2lwcGluZyBob3N0IGJyaWRn
ZSAwMDAwOjAwOjE4LjENCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjkzOV0gQU1ELVZp
OiBTa2lwcGluZyBob3N0IGJyaWRnZSAwMDAwOjAwOjE4LjINCihYRU4pIFsyMDE0LTExLTE4
IDIxOjQ1OjEzLjk1NF0gQU1ELVZpOiBTa2lwcGluZyBob3N0IGJyaWRnZSAwMDAwOjAwOjE4
LjMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjk2OV0gQU1ELVZpOiBTa2lwcGluZyBo
b3N0IGJyaWRnZSAwMDAwOjAwOjE4LjQNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjk4
NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDAsIHR5
cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYzAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMy45OTldIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NTAwLCB0eXBlID0gMHgyLCByb290
IHRhYmxlID0gMHg1NGVlZGMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NDU6MTQuMDE1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDYwOCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRl
ZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4
IDIxOjQ1OjE0LjAzMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHg2MTAsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYzAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxNC4wNDZd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NzAwLCB0eXBl
ID0gMHgxLCByb290IHRhYmxlID0gMHg1NGVlZGMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTQuMDYzXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDgwMCwgdHlwZSA9IDB4MSwgcm9vdCB0
YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjE0LjA3OV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg5MDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVk
YzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo0NToxNC4wOTVdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4OTAxLCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1NGVlZGMwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTQuMTEyXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEwMCwgdHlwZSA9
IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjE0LjEyOV0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFi
bGUgPSAweDU0ZWVkYzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxNC0xMS0xOCAyMTo0NToxNC4xNDZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4YzAwLCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1NGVlZGMw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NDU6MTQuMTYzXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eGQwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjE0LjE4MF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhlMDAsIHR5cGUgPSAw
eDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxNC4xOTddIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ZTAxLCB0eXBlID0gMHgxLCByb290IHRhYmxl
ID0gMHg1NGVlZGMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NDU6MTQuMjE1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweGYwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1
OjE0LjIzM10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhm
MDEsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYzAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxNC4yNTZdIFNjcnVi
YmluZyBGcmVlIFJBTSBvbiAxIG5vZGVzIHVzaW5nIDYgQ1BVcw0KKFhFTikgWzIwMTQtMTEt
MTggMjE6NDU6MTQuMzY2XSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuDQoo
WEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxNy40NTldIEluaXRpYWwgbG93IG1lbW9yeSB2aXJx
IHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLg0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NDU6MTcuNDc3XSBTdGQuIExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1
OjE3LjQ5NV0gR3Vlc3QgTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6
MTcuNTEyXSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihYRU4pIFsyMDE0
LTExLTE4IDIxOjQ1OjE3LjYxNF0gKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdD
VFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4pDQooWEVOKSBbMjAx
NC0xMS0xOCAyMTo0NToxNy42MTVdIEZyZWVkIDI4OGtCIGluaXQgbWVtb3J5Lg0KbWFwcGlu
ZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkNCmFib3V0IHRvIGdldCBzdGFydGVkLi4u
DQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVzZXQNClsg
ICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQ0KWyAgICAwLjAw
MDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1YWNjdA0KWyAgICAwLjAwMDAw
MF0gTGludXggdmVyc2lvbiAzLjE4LjAtcmM1LTIwMTQxMTE2LXZhbmlsbGEgKHJvb3RAc2Vy
dmVlcnN0ZXJ0amUpIChnY2MgdmVyc2lvbiA0LjcuMiAoRGViaWFuIDQuNy4yLTUpICkgIzEg
U01QIFR1ZSBOb3YgMTggMTA6MTg6MjMgQ0VUIDIwMTQNClsgICAgMC4wMDAwMDBdIENvbW1h
bmQgbGluZTogcm9vdD0vZGV2L21hcHBlci9zZXJ2ZWVyc3RlcnRqZS1yb290IHJvIHZlcmJv
c2UgZWFybHlwcmludGs9eGVuIG1lbT0xNTM2TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkw
IHZnYT03OTQgdmlkZW89dmVzYWZiIHI4MTY5LnVzZV9kYWM9MSBhY3BpX2VuZm9yY2VfcmVz
b3VyY2VzPWxheCBtYXhfbG9vcD0zMCBsb29wX21heF9wYXJ0PTEwIGRlYnVnIGxvZ2xldmVs
PTEwIG5vbW9kZXNldCB4ZW4tcGNpYmFjay5oaWRlPSgwMzowNi4wKSgwNDowMC4qKSgwNzow
MC4qKSgwODowMC4qKSgwOTowMC4qKSgwYTowMC4wKSgwYjowMC4wKSgwZTowMC4qKSByODE2
OS51c2VfZGFjPTEgYWNwaS5kZWJ1Z19sYXllcj0weDQwMDAwMCBhY3BpLmRlYnVnX2xldmVs
PTB4NA0KWyAgICAwLjAwMDAwMF0gU2V0IDEyODk3NTA2MyBwYWdlKHMpIHRvIDEtMSBtYXBw
aW5nDQpbICAgIDAuMDAwMDAwXSBSZW1hcHBlZCAxMDMgcGFnZShzKSwgbGFzdF9wZm49Mzkz
MzE5DQpbICAgIDAuMDAwMDAwXSBSZWxlYXNlZCAwIHBhZ2UocykNClsgICAgMC4wMDAwMDBd
IGU4MjA6IEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBd
IFhlbjogW21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAwMDAwMDAwMDk4ZmZmXSB1c2Fi
bGUNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwMDAwOTk0MDAtMHgwMDAw
MDAwMDAwMGZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAw
MDAwMDAwMDEwMDAwMC0weDAwMDAwMDAwNjAwNjZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA2MDA2NzAwMC0weDAwMDAwMDAwOWZmOGZmZmZdIHVu
dXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDlmZjkwMDAwLTB4
MDAwMDAwMDA5ZmY5ZGZmZl0gQUNQSSBkYXRhDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0g
MHgwMDAwMDAwMDlmZjllMDAwLTB4MDAwMDAwMDA5ZmZkZmZmZl0gQUNQSSBOVlMNClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwOWZmZTAwMDAtMHgwMDAwMDAwMDlmZmZm
ZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmNjAw
MDAwMC0weDAwMDAwMDAwZjYwMDNmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46
IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQN
ClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVjMjAwMDAtMHgwMDAwMDAw
MGZlYzIwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAw
MDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAw
XSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVz
ZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAxMDAwMDAwMDAtMHgw
MDAwMDAwNTVmZmZmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwZmQwMDAwMDAwMC0weDAwMDAwMGZmZmZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAu
MDAwMDAwXSBib290Y29uc29sZSBbeGVuYm9vdDBdIGVuYWJsZWQNClsgICAgMC4wMDAwMDBd
IE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQ0KWyAgICAwLjAwMDAw
MF0gZTgyMDogdXNlci1kZWZpbmVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAw
XSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOThmZmZdIHVz
YWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwMDAwOTk0MDAtMHgw
MDAwMDAwMDAwMGZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAw
eDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDVmZmZmZmZmXSB1c2FibGUNClsgICAgMC4w
MDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDYwMDY3MDAwLTB4MDAwMDAwMDA5ZmY4ZmZm
Zl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDlmZjkw
MDAwLTB4MDAwMDAwMDA5ZmY5ZGZmZl0gQUNQSSBkYXRhDQpbICAgIDAuMDAwMDAwXSB1c2Vy
OiBbbWVtIDB4MDAwMDAwMDA5ZmY5ZTAwMC0weDAwMDAwMDAwOWZmZGZmZmZdIEFDUEkgTlZT
DQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDA5ZmZlMDAwMC0weDAwMDAw
MDAwOWZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAw
MDAwMDBmNjAwMDAwMC0weDAwMDAwMDAwZjYwMDNmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZWMwMDAwMC0weDAwMDAwMDAwZmVjMDBmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZWMyMDAw
MC0weDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBb
bWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlZmZmZmZdIHJlc2VydmVkDQpb
ICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZmUwMDAwMC0weDAwMDAwMDAw
ZmZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAw
MDEwMDAwMDAwMC0weDAwMDAwMDA1NWZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAw
XSB1c2VyOiBbbWVtIDB4MDAwMDAwZmQwMDAwMDAwMC0weDAwMDAwMGZmZmZmZmZmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBTTUJJT1MgMi41IHByZXNlbnQuDQpbICAgIDAuMDAw
MDAwXSBETUk6IE1TSSBNUy03NjQwLzg5MEZYQS1HRDcwIChNUy03NjQwKSAgLCBCSU9TIFYx
LjhCMSAwOS8xMy8yMDEwDQpbICAgIDAuMDAwMDAwXSBlODIwOiB1cGRhdGUgW21lbSAweDAw
MDAwMDAwLTB4MDAwMDBmZmZdIHVzYWJsZSA9PT4gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBd
IGU4MjA6IHJlbW92ZSBbbWVtIDB4MDAwYTAwMDAtMHgwMDBmZmZmZl0gdXNhYmxlDQpbICAg
IDAuMDAwMDAwXSBBR1A6IE5vIEFHUCBicmlkZ2UgZm91bmQNClsgICAgMC4wMDAwMDBdIGU4
MjA6IGxhc3RfcGZuID0gMHg2MDAwMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMA0KWyAg
ICAwLjAwMDAwMF0gU2Nhbm5pbmcgMSBhcmVhcyBmb3IgbG93IG1lbW9yeSBjb3JydXB0aW9u
DQpbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAw
MDkzMDAwXSA5MzAwMCBzaXplIDI0NTc2DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9t
YXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0NClsgICAgMC4wMDAwMDBdICBb
bWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0gaW5p
dF9tZW1vcnlfbWFwcGluZzogW21lbSAweDVmZTAwMDAwLTB4NWZmZmZmZmZdDQpbICAgIDAu
MDAwMDAwXSAgW21lbSAweDVmZTAwMDAwLTB4NWZmZmZmZmZdIHBhZ2UgNGsNClsgICAgMC4w
MDAwMDBdIEJSSyBbMHgwMzIwYjAwMCwgMHgwMzIwYmZmZl0gUEdUQUJMRQ0KWyAgICAwLjAw
MDAwMF0gQlJLIFsweDAzMjBjMDAwLCAweDAzMjBjZmZmXSBQR1RBQkxFDQpbICAgIDAuMDAw
MDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4NWMwMDAwMDAtMHg1ZmRmZmZmZl0N
ClsgICAgMC4wMDAwMDBdICBbbWVtIDB4NWMwMDAwMDAtMHg1ZmRmZmZmZl0gcGFnZSA0aw0K
WyAgICAwLjAwMDAwMF0gQlJLIFsweDAzMjBkMDAwLCAweDAzMjBkZmZmXSBQR1RBQkxFDQpb
ICAgIDAuMDAwMDAwXSBCUksgWzB4MDMyMGUwMDAsIDB4MDMyMGVmZmZdIFBHVEFCTEUNClsg
ICAgMC4wMDAwMDBdIEJSSyBbMHgwMzIwZjAwMCwgMHgwMzIwZmZmZl0gUEdUQUJMRQ0KWyAg
ICAwLjAwMDAwMF0gQlJLIFsweDAzMjEwMDAwLCAweDAzMjEwZmZmXSBQR1RBQkxFDQpbICAg
IDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAxMDAwMDAtMHg1YmZm
ZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAxMDAwMDAtMHg1YmZmZmZmZl0gcGFn
ZSA0aw0KWyAgICAwLjAwMDAwMF0gUkFNRElTSzogW21lbSAweDA0MDAwMDAwLTB4MDRmMzVm
ZmZdDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBFYXJseSB0YWJsZSBjaGVja3N1bSB2ZXJpZmlj
YXRpb24gZGlzYWJsZWQNClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMHgwMDAwMDAwMDAw
MEZCMTAwIDAwMDAxNCAodjAwIEFDUElBTSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFQg
MHgwMDAwMDAwMDlGRjkwMDAwIDAwMDA0OCAodjAxIE1TSSAgICBPRU1TTElDICAyMDEwMDkx
MyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUCAweDAwMDAwMDAw
OUZGOTAyMDAgMDAwMDg0ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAw
MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDB4MDAwMDAwMDA5RkY5MDVFMCAw
MDk0MjcgKHYwMSBBNzY0MCAgQTc2NDAxMDAgMDAwMDAxMDAgSU5UTCAyMDA1MTExNykNClsg
ICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMHgwMDAwMDAwMDlGRjlFMDAwIDAwMDA0MA0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogQVBJQyAweDAwMDAwMDAwOUZGOTAzOTAgMDAwMDg4ICh2MDEg
NzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBNQ0ZHIDB4MDAwMDAwMDA5RkY5MDQyMCAwMDAwM0MgKHYwMSA3NjQwTVMgT0VN
TUNGRyAgMjAxMDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNM
SUMgMHgwMDAwMDAwMDlGRjkwNDYwIDAwMDE3NiAodjAxIE1TSSAgICBPRU1TTElDICAyMDEw
MDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogT0VNQiAweDAwMDAw
MDAwOUZGOUUwNDAgMDAwMDcyICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQg
MDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTUkFUIDB4MDAwMDAwMDA5RkY5QTVF
MCAwMDAxMDggKHYwMyBBTUQgICAgRkFNX0ZfMTAgMDAwMDAwMDIgQU1EICAwMDAwMDAwMSkN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgMHgwMDAwMDAwMDlGRjlBNkYwIDAwMDAzOCAo
djAxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAw
MDAwMF0gQUNQSTogSVZSUyAweDAwMDAwMDAwOUZGOUE3MzAgMDAwMTEwICh2MDEgQU1EICAg
IFJEODkwUyAgIDAwMjAyMDMxIEFNRCAgMDAwMDAwMDApDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBTU0RUIDB4MDAwMDAwMDA5RkY5QTg0MCAwMDBEQTQgKHYwMSBBIE0gSSAgUE9XRVJOT1cg
MDAwMDAwMDEgQU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQ
SUMgYWRkcmVzcyAweGZlZTAwMDAwDQpbICAgIDAuMDAwMDAwXSBOVU1BIHR1cm5lZCBvZmYN
ClsgICAgMC4wMDAwMDBdIEZha2luZyBhIG5vZGUgYXQgW21lbSAweDAwMDAwMDAwMDAwMDAw
MDAtMHgwMDAwMDAwMDVmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gTk9ERV9EQVRBKDApIGFs
bG9jYXRlZCBbbWVtIDB4NWZkMTYwMDAtMHg1ZmQyMGZmZl0NClsgICAgMC4wMDAwMDBdIFpv
bmUgcmFuZ2VzOg0KWyAgICAwLjAwMDAwMF0gICBETUEgICAgICBbbWVtIDB4MDAwMDEwMDAt
MHgwMGZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAgW21lbSAweDAxMDAwMDAw
LTB4ZmZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5vcm1hbCAgIGVtcHR5DQpbICAgIDAu
MDAwMDAwXSBNb3ZhYmxlIHpvbmUgc3RhcnQgZm9yIGVhY2ggbm9kZQ0KWyAgICAwLjAwMDAw
MF0gRWFybHkgbWVtb3J5IG5vZGUgcmFuZ2VzDQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAw
OiBbbWVtIDB4MDAwMDEwMDAtMHgwMDA5OGZmZl0NClsgICAgMC4wMDAwMDBdICAgbm9kZSAg
IDA6IFttZW0gMHgwMDEwMDAwMC0weDVmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gSW5pdG1l
bSBzZXR1cCBub2RlIDAgW21lbSAweDAwMDAxMDAwLTB4NWZmZmZmZmZdDQpbICAgIDAuMDAw
MDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczogMzkzMTEyDQpbICAgIDAuMDAwMDAwXSAgIERN
QSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBtZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1B
IHpvbmU6IDIxIHBhZ2VzIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAz
OTkyIHBhZ2VzLCBMSUZPIGJhdGNoOjANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTog
NjA4MCBwYWdlcyB1c2VkIGZvciBtZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9u
ZTogMzg5MTIwIHBhZ2VzLCBMSUZPIGJhdGNoOjMxDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBQ
TS1UaW1lciBJTyBQb3J0OiAweDgwOA0KWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJ
QyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5h
YmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGlj
X2lkWzB4MDNdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lf
YmFzZVswXSkNClsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9u
IDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRdKQ0K
WyAgICAwLjAwMDAwMF0gSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJl
c3MgMHhmZWMyMDAwMCwgR1NJIDI0LTU1DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JD
X09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KWyAgICAwLjAw
MDAwMF0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkg
bG93IGxldmVsKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRl
Lg0KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0KWyAgICAw
LjAwMDAwMF0gVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9y
bWF0aW9uDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhm
ZWQwMDAwMA0KWyAgICAwLjAwMDAwMF0gc21wYm9vdDogQWxsb3dpbmcgNiBDUFVzLCAwIGhv
dHBsdWcgQ1BVcw0KWyAgICAwLjAwMDAwMF0gZTgyMDogW21lbSAweGEwMDAwMDAwLTB4ZjVm
ZmZmZmZdIGF2YWlsYWJsZSBmb3IgUENJIGRldmljZXMNClsgICAgMC4wMDAwMDBdIEJvb3Rp
bmcgcGFyYXZpcnR1YWxpemVkIGtlcm5lbCBvbiBYZW4NClsgICAgMC4wMDAwMDBdIFhlbiB2
ZXJzaW9uOiA0LjUuMC1yYyAocHJlc2VydmUtQUQpDQpbICAgIDAuMDAwMDAwXSBzZXR1cF9w
ZXJjcHU6IE5SX0NQVVM6OCBucl9jcHVtYXNrX2JpdHM6OCBucl9jcHVfaWRzOjYgbnJfbm9k
ZV9pZHM6MQ0KWyAgICAwLjAwMDAwMF0gUEVSQ1BVOiBFbWJlZGRlZCAzMCBwYWdlcy9jcHUg
QGZmZmY4ODAwNWY2MDAwMDAgczgyNTYwIHI4MTkyIGQzMjEyOCB1MjYyMTQ0DQpbICAgIDAu
MDAwMDAwXSBwY3B1LWFsbG9jOiBzODI1NjAgcjgxOTIgZDMyMTI4IHUyNjIxNDQgYWxsb2M9
MSoyMDk3MTUyDQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBbMF0gMCAxIDIgMyA0IDUg
LSAtIA0KWyAgICAwLjAwMDAwMF0geGVuOiBQViBzcGlubG9ja3MgZW5hYmxlZA0KWyAgICAw
LjAwMDAwMF0gQnVpbHQgMSB6b25lbGlzdHMgaW4gTm9kZSBvcmRlciwgbW9iaWxpdHkgZ3Jv
dXBpbmcgb24uICBUb3RhbCBwYWdlczogMzg2OTQ3DQpbICAgIDAuMDAwMDAwXSBQb2xpY3kg
em9uZTogRE1BMzINClsgICAgMC4wMDAwMDBdIEtlcm5lbCBjb21tYW5kIGxpbmU6IHJvb3Q9
L2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtcm9vdCBybyB2ZXJib3NlIGVhcmx5cHJpbnRr
PXhlbiBtZW09MTUzNk0gY29uc29sZT1odmMwIGNvbnNvbGU9dHR5MCB2Z2E9Nzk0IHZpZGVv
PXZlc2FmYiByODE2OS51c2VfZGFjPTEgYWNwaV9lbmZvcmNlX3Jlc291cmNlcz1sYXggbWF4
X2xvb3A9MzAgbG9vcF9tYXhfcGFydD0xMCBkZWJ1ZyBsb2dsZXZlbD0xMCBub21vZGVzZXQg
eGVuLXBjaWJhY2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAuKikoMDc6MDAuKikoMDg6MDAuKiko
MDk6MDAuKikoMGE6MDAuMCkoMGI6MDAuMCkoMGU6MDAuKikgcjgxNjkudXNlX2RhYz0xIGFj
cGkuZGVidWdfbGF5ZXI9MHg0MDAwMDAgYWNwaS5kZWJ1Z19sZXZlbD0weDQNClsgICAgMC4w
MDAwMDBdIFBJRCBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBi
eXRlcykNClsgICAgMC4wMDAwMDBdIHNvZnR3YXJlIElPIFRMQiBbbWVtIDB4NTljMDAwMDAt
MHg1ZGMwMDAwMF0gKDY0TUIpIG1hcHBlZCBhdCBbZmZmZjg4MDA1OWMwMDAwMC1mZmZmODgw
MDVkYmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gTWVtb3J5OiAxNDI0MTkySy8xNTcyNDQ4SyBh
dmFpbGFibGUgKDExOTIwSyBrZXJuZWwgY29kZSwgMTA0M0sgcndkYXRhLCA0NDk2SyByb2Rh
dGEsIDExMDRLIGluaXQsIDE0MTc2SyBic3MsIDE0ODI1NksgcmVzZXJ2ZWQpDQpbICAgIDAu
MDAwMDAwXSBTTFVCOiBIV2FsaWduPTY0LCBPcmRlcj0wLTMsIE1pbk9iamVjdHM9MCwgQ1BV
cz02LCBOb2Rlcz0xDQpbICAgIDAuMDAwMDAwXSBIaWVyYXJjaGljYWwgUkNVIGltcGxlbWVu
dGF0aW9uLg0KWyAgICAwLjAwMDAwMF0gCVJDVSBkeW50aWNrLWlkbGUgZ3JhY2UtcGVyaW9k
IGFjY2VsZXJhdGlvbiBpcyBlbmFibGVkLg0KWyAgICAwLjAwMDAwMF0gCUFkZGl0aW9uYWwg
cGVyLUNQVSBpbmZvIHByaW50ZWQgd2l0aCBzdGFsbHMuDQpbICAgIDAuMDAwMDAwXSAJUkNV
IHJlc3RyaWN0aW5nIENQVXMgZnJvbSBOUl9DUFVTPTggdG8gbnJfY3B1X2lkcz02Lg0KWyAg
ICAwLjAwMDAwMF0gUkNVOiBBZGp1c3RpbmcgZ2VvbWV0cnkgZm9yIHJjdV9mYW5vdXRfbGVh
Zj0xNiwgbnJfY3B1X2lkcz02DQpbICAgIDAuMDAwMDAwXSBOUl9JUlFTOjQzNTIgbnJfaXJx
czoxMDE2IDANClsgICAgMC4wMDAwMDBdIHhlbjpldmVudHM6IFVzaW5nIEZJRk8tYmFzZWQg
QUJJDQpbICAgIDAuMDAwMDAwXSB4ZW46IHNjaSBvdmVycmlkZTogZ2xvYmFsX2lycT05IHRy
aWdnZXI9MCBwb2xhcml0eT0xDQpbICAgIDAuMDAwMDAwXSB4ZW46IHJlZ2lzdGVyaW5nIGdz
aSA5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBw
aXJxPTkgLT4gaXJxPTkgKGdzaT05KQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTcuNzY4
XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi05IC0+IDB4NjAgLT4gSVJR
IDkgTW9kZToxIEFjdGl2ZToxKQ0KWyAgICAwLjAwMDAwMF0geGVuOiBhY3BpIHNjaSA5DQpb
ICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTEgLT4gaXJxPTEgKGdzaT0xKQ0KWyAgICAw
LjAwMDAwMF0geGVuOiAtLT4gcGlycT0yIC0+IGlycT0yIChnc2k9MikNClsgICAgMC4wMDAw
MDBdIHhlbjogLS0+IHBpcnE9MyAtPiBpcnE9MyAoZ3NpPTMpDQpbICAgIDAuMDAwMDAwXSB4
ZW46IC0tPiBwaXJxPTQgLT4gaXJxPTQgKGdzaT00KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAt
LT4gcGlycT01IC0+IGlycT01IChnc2k9NSkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBp
cnE9NiAtPiBpcnE9NiAoZ3NpPTYpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTcg
LT4gaXJxPTcgKGdzaT03KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT04IC0+IGly
cT04IChnc2k9OCkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTAgLT4gaXJxPTEw
IChnc2k9MTApDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTExIC0+IGlycT0xMSAo
Z3NpPTExKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMiAtPiBpcnE9MTIgKGdz
aT0xMikNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTMgLT4gaXJxPTEzIChnc2k9
MTMpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTE0IC0+IGlycT0xNCAoZ3NpPTE0
KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNSAtPiBpcnE9MTUgKGdzaT0xNSkN
ClsgICAgMC4wMDAwMDBdIENvbnNvbGU6IGNvbG91ciBkdW1teSBkZXZpY2UgODB4MjUNClsg
ICAgMC4wMDAwMDBdIGNvbnNvbGUgW3R0eTBdIGVuYWJsZWQNClsgICAgMC4wMDAwMDBdIGJv
b3Rjb25zb2xlIFt4ZW5ib290MF0gZGlzYWJsZWQNClsgICAgMC4wMDAwMDBdIEluaXRpYWxp
emluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldA0KWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5n
IGNncm91cCBzdWJzeXMgY3B1DQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3Vw
IHN1YnN5cyBjcHVhY2N0DQpbICAgIDAuMDAwMDAwXSBMaW51eCB2ZXJzaW9uIDMuMTguMC1y
YzUtMjAxNDExMTYtdmFuaWxsYSAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkgKGdjYyB2ZXJzaW9u
IDQuNy4yIChEZWJpYW4gNC43LjItNSkgKSAjMSBTTVAgVHVlIE5vdiAxOCAxMDoxODoyMyBD
RVQgMjAxNA0KWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiByb290PS9kZXYvbWFwcGVy
L3NlcnZlZXJzdGVydGplLXJvb3Qgcm8gdmVyYm9zZSBlYXJseXByaW50az14ZW4gbWVtPTE1
MzZNIGNvbnNvbGU9aHZjMCBjb25zb2xlPXR0eTAgdmdhPTc5NCB2aWRlbz12ZXNhZmIgcjgx
NjkudXNlX2RhYz0xIGFjcGlfZW5mb3JjZV9yZXNvdXJjZXM9bGF4IG1heF9sb29wPTMwIGxv
b3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9MTAgbm9tb2Rlc2V0IHhlbi1wY2liYWNr
LmhpZGU9KDAzOjA2LjApKDA0OjAwLiopKDA3OjAwLiopKDA4OjAwLiopKDA5OjAwLiopKDBh
OjAwLjApKDBiOjAwLjApKDBlOjAwLiopIHI4MTY5LnVzZV9kYWM9MSBhY3BpLmRlYnVnX2xh
eWVyPTB4NDAwMDAwIGFjcGkuZGVidWdfbGV2ZWw9MHg0DQpbICAgIDAuMDAwMDAwXSB0c2Vn
OiAwMDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBTZXQgMTI4OTc1MDYzIHBhZ2UocykgdG8g
MS0xIG1hcHBpbmcNClsgICAgMC4wMDAwMDBdIFJlbWFwcGVkIDEwMyBwYWdlKHMpLCBsYXN0
X3Bmbj0zOTMzMTkNClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDAgcGFnZShzKQ0KWyAgICAw
LjAwMDAwMF0gZTgyMDogQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAw
LjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOThm
ZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDA5OTQw
MC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFtt
ZW0gMHgwMDAwMDAwMDAwMTAwMDAwLTB4MDAwMDAwMDA2MDA2NmZmZl0gdXNhYmxlDQpbICAg
IDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDYwMDY3MDAwLTB4MDAwMDAwMDA5ZmY4
ZmZmZl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwOWZm
OTAwMDAtMHgwMDAwMDAwMDlmZjlkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIFhl
bjogW21lbSAweDAwMDAwMDAwOWZmOWUwMDAtMHgwMDAwMDAwMDlmZmRmZmZmXSBBQ1BJIE5W
Uw0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA5ZmZlMDAwMC0weDAwMDAw
MDAwOWZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAw
MDAwMGY2MDAwMDAwLTB4MDAwMDAwMDBmNjAwM2ZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSBy
ZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWMyMDAwMC0w
eDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0g
MHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBmZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZm
ZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDEwMDAw
MDAwMC0weDAwMDAwMDA1NWZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46
IFttZW0gMHgwMDAwMDBmZDAwMDAwMDAwLTB4MDAwMDAwZmZmZmZmZmZmZl0gcmVzZXJ2ZWQN
ClsgICAgMC4wMDAwMDBdIGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAw
LjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHg2MDAwMDAwMC0weGZmZmZmZmZmZmZmZmZm
ZmVdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVj
dGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAwXSBlODIwOiB1c2VyLWRlZmluZWQgcGh5c2lj
YWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDAw
MDAwLTB4MDAwMDAwMDAwMDA5OGZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBb
bWVtIDB4MDAwMDAwMDAwMDA5OTQwMC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpb
ICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAwMDAw
NWZmZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAw
NjAwNjcwMDAtMHgwMDAwMDAwMDlmZjhmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0g
dXNlcjogW21lbSAweDAwMDAwMDAwOWZmOTAwMDAtMHgwMDAwMDAwMDlmZjlkZmZmXSBBQ1BJ
IGRhdGENClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDlmZjllMDAwLTB4
MDAwMDAwMDA5ZmZkZmZmZl0gQUNQSSBOVlMNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0g
MHgwMDAwMDAwMDlmZmUwMDAwLTB4MDAwMDAwMDA5ZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGY2MDAwMDAwLTB4MDAwMDAwMDBmNjAw
M2ZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZl
YzAwMDAwLTB4MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVz
ZXI6IFttZW0gMHgwMDAwMDAwMGZlYzIwMDAwLTB4MDAwMDAwMDBmZWMyMGZmZl0gcmVzZXJ2
ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAw
MDAwMDBmZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgw
MDAwMDAwMGZmZTAwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4w
MDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMTAwMDAwMDAwLTB4MDAwMDAwMDU1ZmZmZmZm
Zl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDBmZDAwMDAw
MDAwLTB4MDAwMDAwZmZmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFNNQklP
UyAyLjUgcHJlc2VudC4NClsgICAgMC4wMDAwMDBdIERNSTogTVNJIE1TLTc2NDAvODkwRlhB
LUdENzAgKE1TLTc2NDApICAsIEJJT1MgVjEuOEIxIDA5LzEzLzIwMTANClsgICAgMC4wMDAw
MDBdIGU4MjA6IHVwZGF0ZSBbbWVtIDB4MDAwMDAwMDAtMHgwMDAwMGZmZl0gdXNhYmxlID09
PiByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gZTgyMDpbICAgMTUuNTUzOTA1XSBwY2liYWNr
IDAwMDA6MDg6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHgzYyAo
d2FzIDB4MTAwLCB3cml0aW5nIDB4MTA3KQ0KWyAgIDE1LjU1NDE0OV0gcGNpYmFjayAwMDAw
OjA4OjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4MTAgKHdhcyAw
eDQsIHdyaXRpbmcgMHhmZTBmZTAwNCkNClsgICAxNS41NTQzNzhdIHBjaWJhY2sgMDAwMDow
ODowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweGMgKHdhcyAweDAs
IHdyaXRpbmcgMHgxMCkNClsgICAxNS41NTQ1OTNdIHBjaWJhY2sgMDAwMDowODowMC4wOiBy
ZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweDQgKHdhcyAweDEwMDAwMCwgd3Jp
dGluZyAweDEwMDEwMikNClsgICAxNS41NTQ5NDNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDMz
IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTUuNTU1MDg5XSB4ZW46IC0tPiBwaXJx
PTMzIC0+IGlycT0zMyAoZ3NpPTMzKQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MjAuNzM3
XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy05IC0+IDB4YTkgLT4gSVJR
IDMzIE1vZGU6MSBBY3RpdmU6MSkNClsgICAxNS41ODA2NjVdIHBjaWJhY2sgMDAwMDowOTow
MC4wOiBlbmFibGluZyBkZXZpY2UgKDAwMDAgLT4gMDAwMykNClsgICAxNS41ODA4NDNdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDMyIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTUu
NTgwOTg5XSB4ZW46IC0tPiBwaXJxPTMyIC0+IGlycT0zMiAoZ3NpPTMyKQ0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NDU6MjAuNzYyXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy04IC0+IDB4YjEgLT4gSVJRIDMyIE1vZGU6MSBBY3RpdmU6MSkNClsgICAxNS42MDcy
NjZdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDQ3IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpb
ICAgMTUuNjA3NDE1XSB4ZW46IC0tPiBwaXJxPTQ3IC0+IGlycT00NyAoZ3NpPTQ3KQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NDU6MjAuNzg5XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNy0yMyAtPiAweGI5IC0+IElSUSA0NyBNb2RlOjEgQWN0aXZlOjEpDQpbICAg
MTYuNjE3Mjc1XSBwY2liYWNrIDAwMDA6MGE6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFj
ZSBhdCBvZmZzZXQgMHgzYyAod2FzIDB4MTAwLCB3cml0aW5nIDB4MTBhKQ0KWyAgIDE2LjYx
NzUyMV0gcGNpYmFjayAwMDAwOjBhOjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQg
b2Zmc2V0IDB4MTAgKHdhcyAweDQsIHdyaXRpbmcgMHhmZTIwMDAwNCkNClsgICAxNi42MTc3
NTRdIHBjaWJhY2sgMDAwMDowYTowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9m
ZnNldCAweGMgKHdhcyAweDAsIHdyaXRpbmcgMHgxMCkNClsgICAxNi42MTc5NjldIHBjaWJh
Y2sgMDAwMDowYTowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweDQg
KHdhcyAweDEwMDAwMCwgd3JpdGluZyAweDEwMDEwNikNClsgICAxNi42MjQ1OTVdIHhlbjog
cmVnaXN0ZXJpbmcgZ3NpIDQ4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTYuNjMx
MDg3XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjQ4DQpbICAgMTcuNjQ3MTcxXSBwY2liYWNr
IDAwMDA6MGI6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHgzYyAo
d2FzIDB4MTAwLCB3cml0aW5nIDB4MTBhKQ0KWyAgIDE3LjY1Mzg4Nl0gcGNpYmFjayAwMDAw
OjBiOjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4MTAgKHdhcyAw
eDQsIHdyaXRpbmcgMHhmZTVmZTAwNCkNClsgICAxNy42NjA1MTNdIHBjaWJhY2sgMDAwMDow
YjowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweGMgKHdhcyAweDAs
IHdyaXRpbmcgMHgxMCkNClsgICAxNy42NjcxMTBdIHBjaWJhY2sgMDAwMDowYjowMC4wOiBy
ZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweDQgKHdhcyAweDEwMDAwMCwgd3Jp
dGluZyAweDEwMDEwMikNClsgICAxNy42NzM4MDhdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDI5
IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTcuNjgwMzkyXSB4ZW46IC0tPiBwaXJx
PTI5IC0+IGlycT0yOSAoZ3NpPTI5KQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MjIuODY4
XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy01IC0+IDB4YzEgLT4gSVJR
IDI5IE1vZGU6MSBBY3RpdmU6MSkNClsgICAxNy43MTA2NzJdIHBjaWJhY2sgMDAwMDowZTow
MC4wOiBlbmFibGluZyBkZXZpY2UgKDAwMDAgLT4gMDAwMykNClsgICAxNy43MTczMThdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDI4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTcu
NzIzOTY2XSB4ZW46IC0tPiBwaXJxPTI4IC0+IGlycT0yOCAoZ3NpPTI4KQ0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NDU6MjIuOTEyXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy00IC0+IDB4YzkgLT4gSVJRIDI4IE1vZGU6MSBBY3RpdmU6MSkNClsgICAxNy43NTc1
NTFdIHhlbl9wY2liYWNrOiBiYWNrZW5kIGlzIHZwY2kNClsgICAxNy43NjQ1MjddIHhlbl9h
Y3BpX3Byb2Nlc3NvcjogVXBsb2FkaW5nIFhlbiBwcm9jZXNzb3IgUE0gaW5mbw0KWyAgIDE3
Ljc3MjQ3M10gU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJp
bmcgZW5hYmxlZA0KWyAgIDE3Ljc4MDI4NF0gaHBldF9hY3BpX2FkZDogbm8gYWRkcmVzcyBv
ciBpcnFzIGluIF9DUlMNClsgICAxNy43ODcxNjRdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNl
IHYwLjEwMw0KWyAgIDE3Ljc5NDIyM10gSGFuZ2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sg
dGltZXIgMC45LjEgKHRpY2sgaXMgMTgwIHNlY29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRz
KS4NClsgICAxNy44MDA5MTFdIFtkcm1dIEluaXRpYWxpemVkIGRybSAxLjEuMCAyMDA2MDgx
MA0KWyAgIDE3LjgwNzUyNV0gW2RybV0gVkdBQ09OIGRpc2FibGUgcmFkZW9uIGtlcm5lbCBt
b2Rlc2V0dGluZy4NClsgICAxNy44MTQwODhdIFtkcm06cmFkZW9uX2luaXRdICpFUlJPUiog
Tm8gVU1TIHN1cHBvcnQgaW4gcmFkZW9uIG1vZHVsZSENClsgICAxNy44MjM5NTRdIGJyZDog
bW9kdWxlIGxvYWRlZA0KWyAgIDE3LjgzODY2NV0gbG9vcDogbW9kdWxlIGxvYWRlZA0KWyAg
IDE3Ljg0NTYwN10gYWhjaSAwMDAwOjAwOjExLjA6IHZlcnNpb24gMy4wDQpbICAgMTcuODUy
MjM1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0K
WyAgIDE3Ljg1ODY5MV0geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkNCihY
RU4pIFsyMDE0LTExLTE4IDIxOjQ1OjIzLjA0Nl0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDYtMTkgLT4gMHhkMSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQ0KWyAg
IDE3Ljg2NTMxN10gYWhjaSAwMDAwOjAwOjExLjA6IEFIQ0kgMDAwMS4wMjAwIDMyIHNsb3Rz
IDYgcG9ydHMgNiBHYnBzIDB4M2YgaW1wbCBTQVRBIG1vZGUNClsgICAxNy44NzE3NzFdIGFo
Y2kgMDAwMDowMDoxMS4wOiBmbGFnczogNjRiaXQgbmNxIHNudGYgaWxjayBwbSBsZWQgY2xv
IHBtcCBwaW8gc2x1bSBwYXJ0IA0KWyAgIDE3Ljg4MDY1N10gc2NzaSBob3N0MDogYWhjaQ0K
WyAgIDE3Ljg4NzU3Ml0gc2NzaSBob3N0MTogYWhjaQ0KWyAgIDE3Ljg5NDEyNl0gc2NzaSBo
b3N0MjogYWhjaQ0KWyAgIDE3LjkwMDUxOV0gc2NzaSBob3N0MzogYWhjaQ0KWyAgIDE3Ljkw
Njg5NF0gc2NzaSBob3N0NDogYWhjaQ0KWyAgIDE3LjkxMzI3OF0gc2NzaSBob3N0NTogYWhj
aQ0KWyAgIDE3LjkxOTI0Ml0gYXRhMTogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAw
eGZkYmZmMDAwIHBvcnQgMHhmZGJmZjEwMCBpcnEgMTE0DQpbICAgMTcuOTI1MjcyXSBhdGEy
OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmRiZmYwMDAgcG9ydCAweGZkYmZm
MTgwIGlycSAxMTUNClsgICAxNy45MzExNzJdIGF0YTM6IFNBVEEgbWF4IFVETUEvMTMzIGFi
YXIgbTEwMjRAMHhmZGJmZjAwMCBwb3J0IDB4ZmRiZmYyMDAgaXJxIDExNg0KWyAgIDE3Ljkz
NjkxM10gYXRhNDogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGZkYmZmMDAwIHBv
cnQgMHhmZGJmZjI4MCBpcnEgMTE3DQpbICAgMTcuOTQyNjgxXSBhdGE1OiBTQVRBIG1heCBV
RE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmRiZmYwMDAgcG9ydCAweGZkYmZmMzAwIGlycSAxMTgN
ClsgICAxNy45NDgzNzFdIGF0YTY6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhm
ZGJmZjAwMCBwb3J0IDB4ZmRiZmYzODAgaXJxIDExOQ0KWyAgIDE3Ljk1NDEzNl0gdHVuOiBV
bml2ZXJzYWwgVFVOL1RBUCBkZXZpY2UgZHJpdmVyLCAxLjYNClsgICAxNy45NTk2NzVdIHR1
bjogKEMpIDE5OTktMjAwNCBNYXggS3Jhc255YW5za3kgPG1heGtAcXVhbGNvbW0uY29tPg0K
WyAgIDE3Ljk2NTM5MF0gZTEwMDA6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgRHJpdmVy
IC0gdmVyc2lvbiA3LjMuMjEtazgtTkFQSQ0KWyAgIDE3Ljk3MTAyMV0gZTEwMDA6IENvcHly
aWdodCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBvcmF0aW9uLg0KWyAgIDE3Ljk3NjY3Nl0g
ZTEwMDBlOiBJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIDIuMy4yLWsNClsg
ICAxNy45ODIyMzVdIGUxMDAwZTogQ29weXJpZ2h0KGMpIDE5OTkgLSAyMDE0IEludGVsIENv
cnBvcmF0aW9uLg0KWyAgIDE3Ljk4Nzg3MV0gaWdiOiBJbnRlbChSKSBHaWdhYml0IEV0aGVy
bmV0IE5ldHdvcmsgRHJpdmVyIC0gdmVyc2lvbiA1LjIuMTUtaw0KWyAgIDE3Ljk5MzUzNV0g
aWdiOiBDb3B5cmlnaHQgKGMpIDIwMDctMjAxNCBJbnRlbCBDb3Jwb3JhdGlvbi4NClsgICAx
Ny45OTkyOTldIGlnYnZmOiBJbnRlbChSKSBHaWdhYml0IFZpcnR1YWwgRnVuY3Rpb24gTmV0
d29yayBEcml2ZXIgLSB2ZXJzaW9uIDIuMC4yLWsNClsgICAxOC4wMDUwNTBdIGlnYnZmOiBD
b3B5cmlnaHQgKGMpIDIwMDkgLSAyMDEyIEludGVsIENvcnBvcmF0aW9uLg0KWyAgIDE4LjAx
MDg1MV0gcjgxNjkgR2lnYWJpdCBFdGhlcm5ldCBkcml2ZXIgMi4zTEstTkFQSSBsb2FkZWQN
ClsgICAxOC4wMTY2NDNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDQ2IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgMTguMDIyMzk5XSB4ZW46IC0tPiBwaXJxPTQ2IC0+IGlycT00NiAo
Z3NpPTQ2KQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MjMuMjA5XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMiAtPiAweDVhIC0+IElSUSA0NiBNb2RlOjEgQWN0
aXZlOjEpDQpbICAgMTguMDI4MTIzXSByODE2OSAwMDAwOjBkOjAwLjA6IGVuYWJsaW5nIE1l
bS1Xci1JbnZhbA0KWyAgIDE4LjAzNDMyN10gcjgxNjkgMDAwMDowZDowMC4wIGV0aDA6IFJU
TDgxNjhkLzgxMTFkIGF0IDB4ZmZmZmM5MDAwMDM2NDAwMCwgNDA6NjE6ODY6ZjQ6Njc6ZDks
IFhJRCAwODEwMDBjMCBJUlEgMTIyDQpbICAgMTguMDQwMjY3XSByODE2OSAwMDAwOjBkOjAw
LjAgZXRoMDoganVtYm8gZmVhdHVyZXMgW2ZyYW1lczogOTIwMCBieXRlcywgdHggY2hlY2tz
dW1taW5nOiBrb10NClsgICAxOC4wNDYyMThdIHI4MTY5IEdpZ2FiaXQgRXRoZXJuZXQgZHJp
dmVyIDIuM0xLLU5BUEkgbG9hZGVkDQpbICAgMTguMDUyMTU1XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSA1MSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgIDE4LjA1ODA3Ml0geGVuOiAt
LT4gcGlycT01MSAtPiBpcnE9NTEgKGdzaT01MSkNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1
OjIzLjI0NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjcgLT4gMHg2
YSAtPiBJUlEgNTEgTW9kZToxIEFjdGl2ZToxKQ0KWyAgIDE4LjA2NDAzNl0gcjgxNjkgMDAw
MDowYzowMC4wOiBlbmFibGluZyBNZW0tV3ItSW52YWwNClsgICAxOC4wNzAyNjddIHI4MTY5
IDAwMDA6MGM6MDAuMCBldGgxOiBSVEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMDAzNjYw
MDAsIDQwOjYxOjg2OmY0OjY3OmQ4LCBYSUQgMDgxMDAwYzAgSVJRIDEyMw0KWyAgIDE4LjA3
NjMxMl0gcjgxNjkgMDAwMDowYzowMC4wIGV0aDE6IGp1bWJvIGZlYXR1cmVzIFtmcmFtZXM6
IDkyMDAgYnl0ZXMsIHR4IGNoZWNrc3VtbWluZzoga29dDQpbICAgMTguMDgyMzYzXSB4ZW5f
bmV0ZnJvbnQ6IEluaXRpYWxpc2luZyBYZW4gdmlydHVhbCBldGhlcm5ldCBkcml2ZXINClsg
ICAxOC4wODg4MTldIGVoY2lfaGNkOiBVU0IgMi4wICdFbmhhbmNlZCcgSG9zdCBDb250cm9s
bGVyIChFSENJKSBEcml2ZXINClsgICAxOC4wOTQ5MDZdIGVoY2ktcGNpOiBFSENJIFBDSSBw
bGF0Zm9ybSBkcml2ZXINClsgICAxOC4xMDEyMDNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE3
IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguMTA3MjIyXSBBbHJlYWR5IHNldHVw
IHRoZSBHU0kgOjE3DQpbICAgMTguMTEzMjY2XSBRVUlSSzogRW5hYmxlIEFNRCBQTEwgZml4
DQpbICAgMTguMTE5MjMzXSBlaGNpLXBjaSAwMDAwOjAwOjEyLjI6IGVuYWJsaW5nIGJ1cyBt
YXN0ZXJpbmcNClsgICAxOC4xMjUyODBdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogRUhDSSBI
b3N0IENvbnRyb2xsZXINClsgICAxOC4xMzE1NjldIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjog
bmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxDQpbICAgMTgu
MTM3NTczXSBlaGNpLXBjaSAwMDAwOjAwOjEyLjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgw
MC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZA0KWyAgIDE4LjE0MzY4NV0g
ZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBkZWJ1ZyBwb3J0IDENClsgICAxOC4xNDk4MjFdIGVo
Y2ktcGNpIDAwMDA6MDA6MTIuMjogZW5hYmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTguMTU1
NzYzXSBlaGNpLXBjaSAwMDAwOjAwOjEyLjI6IGlycSAxNywgaW8gbWVtIDB4ZmRiZmY0MDAN
ClsgICAxOC4xNzA1OTddIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogVVNCIDIuMCBzdGFydGVk
LCBFSENJIDEuMDANClsgICAxOC4xNzY1ODVdIHVzYiB1c2IxOiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINClsgICAxOC4xODIzODVdIHVz
YiB1c2IxOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJp
YWxOdW1iZXI9MQ0KWyAgIDE4LjE4ODE1NV0gdXNiIHVzYjE6IFByb2R1Y3Q6IEVIQ0kgSG9z
dCBDb250cm9sbGVyDQpbICAgMTguMTkzODYwXSB1c2IgdXNiMTogTWFudWZhY3R1cmVyOiBM
aW51eCAzLjE4LjAtcmM1LTIwMTQxMTE2LXZhbmlsbGEgZWhjaV9oY2QNClsgICAxOC4xOTk2
MzFdIHVzYiB1c2IxOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTIuMg0KWyAgIDE4LjIwNTk2
Ml0gaHViIDEtMDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAxOC4yMTE3NjNdIGh1YiAxLTA6
MS4wOiA1IHBvcnRzIGRldGVjdGVkDQpbICAgMTguMjE4MDc1XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgIDE4LjIyMzg2OF0gQWxyZWFk
eSBzZXR1cCB0aGUgR1NJIDoxNw0KWyAgIDE4LjIyOTU5M10gZWhjaS1wY2kgMDAwMDowMDox
My4yOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQpbICAgMTguMjM1MzQwXSBlaGNpLXBjaSAw
MDAwOjAwOjEzLjI6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgMTguMjQxMTA2XSBlaGNp
LXBjaSAwMDAwOjAwOjEzLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1
cyBudW1iZXIgMg0KWyAgIDE4LjI0Njg1Ml0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBhcHBs
eWluZyBBTUQgU0I3MDAvU0I4MDAvSHVkc29uLTIvMyBFSENJIGR1bW15IHFoIHdvcmthcm91
bmQNClsgICAxOC4yNTI3NjJdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogZGVidWcgcG9ydCAx
DQpbICAgMTguMjU4NzgwXSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IGVuYWJsaW5nIE1lbS1X
ci1JbnZhbA0KWyAgIDE4LjI2NDgwOF0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBpcnEgMTcs
IGlvIG1lbSAweGZkYmZmODAwDQpbICAgMTguMjczODk0XSBhdGE1OiBTQVRBIGxpbmsgZG93
biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkNClsgICAxOC4yODAxNjRdIGF0YTY6IFNBVEEg
bGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQ0KWyAgIDE4LjI4MDQ0MF0gZWhj
aS1wY2kgMDAwMDowMDoxMy4yOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMA0KWyAgIDE4
LjI4MDUyNV0gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZi
LCBpZFByb2R1Y3Q9MDAwMg0KWyAgIDE4LjI4MDUyNl0gdXNiIHVzYjI6IE5ldyBVU0IgZGV2
aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgMTgu
MjgwNTI3XSB1c2IgdXNiMjogUHJvZHVjdDogRUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAx
OC4yODA1MjhdIHVzYiB1c2IyOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMTguMC1yYzUtMjAx
NDExMTYtdmFuaWxsYSBlaGNpX2hjZA0KWyAgIDE4LjI4MDUyOV0gdXNiIHVzYjI6IFNlcmlh
bE51bWJlcjogMDAwMDowMDoxMy4yDQpbICAgMTguMjgwODE1XSBodWIgMi0wOjEuMDogVVNC
IGh1YiBmb3VuZA0KWyAgIDE4LjI4MDgyNV0gaHViIDItMDoxLjA6IDUgcG9ydHMgZGV0ZWN0
ZWQNClsgICAxOC4yODEyNTFdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcg
MCBwb2xhcml0eSAxDQpbICAgMTguMjgxMjUzXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3
DQpbICAgMTguMjgxMjc2XSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGVuYWJsaW5nIGJ1cyBt
YXN0ZXJpbmcNClsgICAxOC4yODEzMDNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogRUhDSSBI
b3N0IENvbnRyb2xsZXINClsgICAxOC4yODE0NjJdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjog
bmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAzDQpbICAgMTgu
MjgxNDc3XSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgw
MC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZA0KWyAgIDE4LjI4MTQ5N10g
ZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBkZWJ1ZyBwb3J0IDENClsgICAxOC4yODE1NzVdIGVo
Y2ktcGNpIDAwMDA6MDA6MTYuMjogZW5hYmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTguMjgx
NTg0XSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGlycSAxNywgaW8gbWVtIDB4ZmRiZmZjMDAN
ClsgICAxOC4yOTA0NDFdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogVVNCIDIuMCBzdGFydGVk
LCBFSENJIDEuMDANClsgICAxOC4yOTA0OTldIHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINClsgICAxOC4yOTA1MDBdIHVz
YiB1c2IzOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJp
YWxOdW1iZXI9MQ0KWyAgIDE4LjI5MDUwMV0gdXNiIHVzYjM6IFByb2R1Y3Q6IEVIQ0kgSG9z
dCBDb250cm9sbGVyDQpbICAgMTguMjkwNTAzXSB1c2IgdXNiMzogTWFudWZhY3R1cmVyOiBM
aW51eCAzLjE4LjAtcmM1LTIwMTQxMTE2LXZhbmlsbGEgZWhjaV9oY2QNClsgICAxOC4yOTA1
MDNdIHVzYiB1c2IzOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMg0KWyAgIDE4LjI5MDc1
N10gaHViIDMtMDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAxOC4yOTA3NjhdIGh1YiAzLTA6
MS4wOiA0IHBvcnRzIGRldGVjdGVkDQpbICAgMTguMjkxMDI2XSBvaGNpX2hjZDogVVNCIDEu
MSAnT3BlbicgSG9zdCBDb250cm9sbGVyIChPSENJKSBEcml2ZXINClsgICAxOC4yOTEwMzhd
IG9oY2ktcGNpOiBPSENJIFBDSSBwbGF0Zm9ybSBkcml2ZXINClsgICAxOC4yOTEyMTBdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTgu
MjkxMjEyXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgMTguMjkxMjM3XSBvaGNp
LXBjaSAwMDAwOjAwOjEyLjA6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNClsgICAxOC4yOTEy
NTFdIG9oY2ktcGNpIDAwMDA6MDA6MTIuMDogT0hDSSBQQ0kgaG9zdCBjb250cm9sbGVyDQpb
ICAgMTguMjkxNDg1XSBvaGNpLXBjaSAwMDAwOjAwOjEyLjA6IG5ldyBVU0IgYnVzIHJlZ2lz
dGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNA0KWyAgIDE4LjI5MTYyOV0gb2hjaS1wY2kg
MDAwMDowMDoxMi4wOiBpcnEgMTgsIGlvIG1lbSAweGZkYmY3MDAwDQpbICAgMTguMzQ4MDY3
XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJv
ZHVjdD0wMDAxDQpbICAgMTguMzQ4MDY5XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ugc3Ry
aW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAxOC4zNDgwNzBd
IHVzYiB1c2I0OiBQcm9kdWN0OiBPSENJIFBDSSBob3N0IGNvbnRyb2xsZXINClsgICAxOC4z
NDgwNzFdIHVzYiB1c2I0OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMTguMC1yYzUtMjAxNDEx
MTYtdmFuaWxsYSBvaGNpX2hjZA0KWyAgIDE4LjM0ODA3Ml0gdXNiIHVzYjQ6IFNlcmlhbE51
bWJlcjogMDAwMDowMDoxMi4wDQpbICAgMTguMzQ4MzYwXSBodWIgNC0wOjEuMDogVVNCIGh1
YiBmb3VuZA0KWyAgIDE4LjM0ODM3Nl0gaHViIDQtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQN
ClsgICAxOC4zNDg3NzZdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgMTguMzQ4Nzc4XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpb
ICAgMTguMzQ4Nzk5XSBvaGNpLXBjaSAwMDAwOjAwOjEzLjA6IGVuYWJsaW5nIGJ1cyBtYXN0
ZXJpbmcNClsgICAxOC4zNDg4MDZdIG9oY2ktcGNpIDAwMDA6MDA6MTMuMDogT0hDSSBQQ0kg
aG9zdCBjb250cm9sbGVyDQpbICAgMTguMzQ4OTk4XSBvaGNpLXBjaSAwMDAwOjAwOjEzLjA6
IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNQ0KWyAgIDE4
LjM0OTA3NF0gb2hjaS1wY2kgMDAwMDowMDoxMy4wOiBpcnEgMTgsIGlvIG1lbSAweGZkYmZj
MDAwDQpbICAgMTguNDA0NTY3XSB1c2IgdXNiNTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlk
VmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgMTguNDA0NTY5XSB1c2IgdXNiNTog
TmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVy
PTENClsgICAxOC40MDQ1NzBdIHVzYiB1c2I1OiBQcm9kdWN0OiBPSENJIFBDSSBob3N0IGNv
bnRyb2xsZXINClsgICAxOC40MDQ1NzFdIHVzYiB1c2I1OiBNYW51ZmFjdHVyZXI6IExpbnV4
IDMuMTguMC1yYzUtMjAxNDExMTYtdmFuaWxsYSBvaGNpX2hjZA0KWyAgIDE4LjQwNDU3Ml0g
dXNiIHVzYjU6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMy4wDQpbICAgMTguNDA0ODU2XSBo
dWIgNS0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgIDE4LjQwNDg3MV0gaHViIDUtMDoxLjA6
IDUgcG9ydHMgZGV0ZWN0ZWQNClsgICAxOC40MDUyNjhdIHhlbjogcmVnaXN0ZXJpbmcgZ3Np
IDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguNDA1MjcwXSBBbHJlYWR5IHNl
dHVwIHRoZSBHU0kgOjE4DQpbICAgMTguNDA1MjkyXSBvaGNpLXBjaSAwMDAwOjAwOjE0LjU6
IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNClsgICAxOC40MDUyOTldIG9oY2ktcGNpIDAwMDA6
MDA6MTQuNTogT0hDSSBQQ0kgaG9zdCBjb250cm9sbGVyDQpbICAgMTguNDA1NDk5XSBvaGNp
LXBjaSAwMDAwOjAwOjE0LjU6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1
cyBudW1iZXIgNg0KWyAgIDE4LjQwNTU5MV0gb2hjaS1wY2kgMDAwMDowMDoxNC41OiBpcnEg
MTgsIGlvIG1lbSAweGZkYmZkMDAwDQpbICAgMTguNDYxMTk2XSB1c2IgdXNiNjogTmV3IFVT
QiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgMTgu
NDYxMTk3XSB1c2IgdXNiNjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1
Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAxOC40NjExOThdIHVzYiB1c2I2OiBQcm9kdWN0
OiBPSENJIFBDSSBob3N0IGNvbnRyb2xsZXINClsgICAxOC40NjExOTldIHVzYiB1c2I2OiBN
YW51ZmFjdHVyZXI6IExpbnV4IDMuMTguMC1yYzUtMjAxNDExMTYtdmFuaWxsYSBvaGNpX2hj
ZA0KWyAgIDE4LjQ2MTIwMF0gdXNiIHVzYjY6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxNC41
DQpbICAgMTguNDYxNDgwXSBodWIgNi0wOjEuMDogVVNCIGh1YiBmb3VuZA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NDU6MjMuODQwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy0xIC0+IDB4N2EgLT4gSVJRIDI1IE1vZGU6MSBBY3RpdmU6MSkNClsgICAxOC40NjE0
OTRdIGh1YiA2LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQpbICAgMTguNDYxODE5XSB4ZW46
IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgIDE4LjQ2
MTgyMV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KWyAgIDE4LjQ2MTg0Nl0gb2hjaS1w
Y2kgMDAwMDowMDoxNi4wOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQpbICAgMTguNDYxODUz
XSBvaGNpLXBjaSAwMDAwOjAwOjE2LjA6IE9IQ0kgUENJIGhvc3QgY29udHJvbGxlcg0KWyAg
IDE4LjQ2MjEwN10gb2hjaS1wY2kgMDAwMDowMDoxNi4wOiBuZXcgVVNCIGJ1cyByZWdpc3Rl
cmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDcNClsgICAxOC40NjIxOTZdIG9oY2ktcGNpIDAw
MDA6MDA6MTYuMDogaXJxIDE4LCBpbyBtZW0gMHhmZGJmZTAwMA0KWyAgIDE4LjUxNzkzOF0g
dXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1
Y3Q9MDAwMQ0KWyAgIDE4LjUxNzk0MF0gdXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIHN0cmlu
Z3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgMTguNTE3OTQxXSB1
c2IgdXNiNzogUHJvZHVjdDogT0hDSSBQQ0kgaG9zdCBjb250cm9sbGVyDQpbICAgMTguNTE3
OTQyXSB1c2IgdXNiNzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjE4LjAtcmM1LTIwMTQxMTE2
LXZhbmlsbGEgb2hjaV9oY2QNClsgICAxOC41MTc5NDJdIHVzYiB1c2I3OiBTZXJpYWxOdW1i
ZXI6IDAwMDA6MDA6MTYuMA0KWyAgIDE4LjUxODIyOV0gaHViIDctMDoxLjA6IFVTQiBodWIg
Zm91bmQNClsgICAxOC41MTgyNDVdIGh1YiA3LTA6MS4wOiA0IHBvcnRzIGRldGVjdGVkDQpb
ICAgMTguNTE4NTAyXSB1aGNpX2hjZDogVVNCIFVuaXZlcnNhbCBIb3N0IENvbnRyb2xsZXIg
SW50ZXJmYWNlIGRyaXZlcg0KWyAgIDE4LjUxODU5N10gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JscA0KWyAgIDE4LjUxODY0OF0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Itc3RvcmFnZQ0KWyAgIDE4LjUxODcy
Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JzZXJpYWwN
ClsgICAxOC41MTg3NTBdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgY3AyMTB4DQpbICAgMTguNTE4ODU1XSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9y
dCByZWdpc3RlcmVkIGZvciBjcDIxMHgNClsgICAxOC41MTg4OTFdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3lwcmVzc19tOA0KWyAgIDE4LjUxODkxMV0g
dXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgRGVMb3JtZSBF
YXJ0aG1hdGUgVVNCDQpbICAgMTguNTE4OTMyXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3Vw
cG9ydCByZWdpc3RlcmVkIGZvciBISUQtPkNPTSBSUzIzMiBBZGFwdGVyDQpbICAgMTguNTE4
OTUyXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBOb2tp
YSBDQS00MiBWMiBBZGFwdGVyDQpbICAgMTguNTE4OTgxXSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc3MjANClsgICAxOC41MTkwMDNdIHVzYnNlcmlh
bDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIE1vc2NoaXAgMiBwb3J0IGFk
YXB0ZXINClsgICAxOC41MTkwMzRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFj
ZSBkcml2ZXIgbW9zNzg0MA0KWyAgIDE4LjUxOTA1NF0gdXNic2VyaWFsOiBVU0IgU2VyaWFs
IHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCA3ODQwLzc4MjAgVVNCIFNlcmlhbCBE
cml2ZXINClsgICAxOC41MTkxMzVdIGk4MDQyOiBQTlA6IE5vIFBTLzIgY29udHJvbGxlciBm
b3VuZC4gUHJvYmluZyBwb3J0cyBkaXJlY3RseS4NClsgICAxOC41MTk4MjJdIHNlcmlvOiBp
ODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDENClsgICAxOC41MTk4NThdIHNlcmlv
OiBpODA0MiBBVVggcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEyDQpbICAgMTguNTIwMDc3XSBt
b3VzZWRldjogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWljZQ0KWyAgIDE4
LjUyMDkyNl0gcnRjX2Ntb3MgMDA6MDI6IFJUQyBjYW4gd2FrZSBmcm9tIFM0DQpbICAgMTgu
NTIxMzk1XSBydGNfY21vcyAwMDowMjogcnRjIGNvcmU6IHJlZ2lzdGVyZWQgcnRjX2Ntb3Mg
YXMgcnRjMA0KWyAgIDE4LjUyMTQ1N10gcnRjX2Ntb3MgMDA6MDI6IGFsYXJtcyB1cCB0byBv
bmUgbW9udGgsIHkzaywgMTE0IGJ5dGVzIG52cmFtDQpbICAgMTguNTIxNzI2XSBBQ1BJIFdh
cm5pbmc6IFN5c3RlbUlPIHJhbmdlIDB4MDAwMDAwMDAwMDAwMGIwMC0weDAwMDAwMDAwMDAw
MDBiMDcgY29uZmxpY3RzIHdpdGggT3BSZWdpb24gMHgwMDAwMDAwMDAwMDAwYjAwLTB4MDAw
MDAwMDAwMDAwMGIwZiAoXFNPUjEpICgyMDE0MDkyNi91dGFkZHJlc3MtMjU4KQ0KWyAgIDE4
LjUyMTcyOF0gQUNQSTogVGhpcyBjb25mbGljdCBtYXkgY2F1c2UgcmFuZG9tIHByb2JsZW1z
IGFuZCBzeXN0ZW0gaW5zdGFiaWxpdHkNClsgICAxOC41MjE3MjhdIEFDUEk6IElmIGFuIEFD
UEkgZHJpdmVyIGlzIGF2YWlsYWJsZSBmb3IgdGhpcyBkZXZpY2UsIHlvdSBzaG91bGQgdXNl
IGl0IGluc3RlYWQgb2YgdGhlIG5hdGl2ZSBkcml2ZXINClsgICAxOC41MjE3MzRdIHBpaXg0
X3NtYnVzIDAwMDA6MDA6MTQuMDogU01CdXMgSG9zdCBDb250cm9sbGVyIGF0IDB4YjAwLCBy
ZXZpc2lvbiAwDQpbICAgMTguNTIxODM5XSBBQ1BJIFdhcm5pbmc6IFN5c3RlbUlPIHJhbmdl
IDB4MDAwMDAwMDAwMDAwMGIyMC0weDAwMDAwMDAwMDAwMDBiMjcgY29uZmxpY3RzIHdpdGgg
T3BSZWdpb24gMHgwMDAwMDAwMDAwMDAwYjIwLTB4MDAwMDAwMDAwMDAwMGIyZiAoXFNPUjIp
ICgyMDE0MDkyNi91dGFkZHJlc3MtMjU4KQ0KWyAgIDE4LjUyMTg0MF0gQUNQSTogVGhpcyBj
b25mbGljdCBtYXkgY2F1c2UgcmFuZG9tIHByb2JsZW1zIGFuZCBzeXN0ZW0gaW5zdGFiaWxp
dHkNClsgICAxOC41MjE4NDFdIEFDUEk6IElmIGFuIEFDUEkgZHJpdmVyIGlzIGF2YWlsYWJs
ZSBmb3IgdGhpcyBkZXZpY2UsIHlvdSBzaG91bGQgdXNlIGl0IGluc3RlYWQgb2YgdGhlIG5h
dGl2ZSBkcml2ZXINClsgICAxOC41MjE4NDJdIHBpaXg0X3NtYnVzIDAwMDA6MDA6MTQuMDog
QXV4aWxpYXJ5IFNNQnVzIEhvc3QgQ29udHJvbGxlciBhdCAweGIyMA0KWyAgIDE4LjUyMjE3
Nl0gbGlyY19kZXY6IElSIFJlbW90ZSBDb250cm9sIGRyaXZlciByZWdpc3RlcmVkLCBtYWpv
ciAyNDggDQpbICAgMTguNTIyMTk0XSBJUiBORUMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFs
aXplZA0KWyAgIDE4LjUyMjE5N10gSVIgUkM1KHgvc3opIHByb3RvY29sIGhhbmRsZXIgaW5p
dGlhbGl6ZWQNClsgICAxOC41MjIxOTldIElSIFJDNiBwcm90b2NvbCBoYW5kbGVyIGluaXRp
YWxpemVkDQpbICAgMTguNTIyMjAwXSBJUiBKVkMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFs
aXplZA0KWyAgIDE4LjUyMjIwM10gSVIgU29ueSBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxp
emVkDQpbICAgMTguNTIyMjA1XSBJUiBTQU5ZTyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxp
emVkDQpbICAgMTguNTIyMjA3XSBJUiBTaGFycCBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxp
emVkDQpbICAgMTguNTIyMjEwXSBJUiBNQ0UgS2V5Ym9hcmQvbW91c2UgcHJvdG9jb2wgaGFu
ZGxlciBpbml0aWFsaXplZA0KWyAgIDE4LjUyMjIxMl0gSVIgTElSQyBicmlkZ2UgaGFuZGxl
ciBpbml0aWFsaXplZA0KWyAgIDE4LjUyMjIxNF0gSVIgWE1QIHByb3RvY29sIGhhbmRsZXIg
aW5pdGlhbGl6ZWQNClsgICAxOC41MjIyMTZdIGN4MjU4MjE6IGRyaXZlciB2ZXJzaW9uIDAu
MC4xMDYgbG9hZGVkDQpbICAgMTguNTIyNDE2XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBp
bnRlcmZhY2UgZHJpdmVyIHB2cnVzYjINClsgICAxOC41MjI0MTddIHB2cnVzYjI6IFY0TCBp
bi10cmVlIHZlcnNpb246SGF1cHBhdWdlIFdpblRWLVBWUi1VU0IyIE1QRUcyIEVuY29kZXIv
VHVuZXINClsgICAxOC41MjI0MThdIHB2cnVzYjI6IERlYnVnIG1hc2sgaXMgMzEgKDB4MWYp
DQpbICAgMTguNTIyNTEzXSBmNzE4MDVmOiBVbnN1cHBvcnRlZCBGaW50ZWsgZGV2aWNlLCBz
a2lwcGluZw0KWyAgIDE4LjUyMjYwN10gZjcxODgyZmc6IEZvdW5kIGY3MTg4OWVkIGNoaXAg
YXQgMHg2MDAsIHJldmlzaW9uIDE2DQpbICAgMTguNTIyNjM4XSBBQ1BJIFdhcm5pbmc6IFN5
c3RlbUlPIHJhbmdlIDB4MDAwMDAwMDAwMDAwMDYwMC0weDAwMDAwMDAwMDAwMDA2MDcgY29u
ZmxpY3RzIHdpdGggT3BSZWdpb24gMHgwMDAwMDAwMDAwMDAwNjA1LTB4MDAwMDAwMDAwMDAw
MDYwNiAoXEhNT1IpICgyMDE0MDkyNi91dGFkZHJlc3MtMjU4KQ0KWyAgIDE4LjUyMjYzOV0g
QUNQSTogVGhpcyBjb25mbGljdCBtYXkgY2F1c2UgcmFuZG9tIHByb2JsZW1zIGFuZCBzeXN0
ZW0gaW5zdGFiaWxpdHkNClsgICAxOC41MjI2NDBdIEFDUEk6IElmIGFuIEFDUEkgZHJpdmVy
IGlzIGF2YWlsYWJsZSBmb3IgdGhpcyBkZXZpY2UsIHlvdSBzaG91bGQgdXNlIGl0IGluc3Rl
YWQgb2YgdGhlIG5hdGl2ZSBkcml2ZXINClsgICAxOC41MjI3OTNdIGY3MTg4MmZnIGY3MTg4
MmZnLjE1MzY6IEZhbjogMSBpcyBpbiBkdXR5LWN5Y2xlIG1vZGUNClsgICAxOC41MjI4Mzhd
IGY3MTg4MmZnIGY3MTg4MmZnLjE1MzY6IEZhbjogMiBpcyBpbiBkdXR5LWN5Y2xlIG1vZGUN
ClsgICAxOC41MjI4ODJdIGY3MTg4MmZnIGY3MTg4MmZnLjE1MzY6IEZhbjogMyBpcyBpbiBk
dXR5LWN5Y2xlIG1vZGUNClsgICAxOC42NTM5NzNdIHNwNTEwMF90Y286IFNQNTEwMC9TQjgw
MCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYwLjA1DQpbICAgMTguNjU0MDM4XSBzcDUx
MDBfdGNvOiBQQ0kgUmV2aXNpb24gSUQ6IDB4NDENClsgICAxOC42NTQxMDZdIHNwNTEwMF90
Y286IFVzaW5nIDB4ZmVkODBiMDAgZm9yIHdhdGNoZG9nIE1NSU8gYWRkcmVzcw0KWyAgIDE4
LjY1NDE0MF0gc3A1MTAwX3RjbzogTGFzdCByZWJvb3Qgd2FzIG5vdCB0cmlnZ2VyZWQgYnkg
d2F0Y2hkb2cuDQpbICAgMTguNjU0MzIyXSBzcDUxMDBfdGNvOiBpbml0aWFsaXplZCAoMHhm
ZmZmYzkwMDAwMzc2YjAwKS4gaGVhcnRiZWF0PTYwIHNlYyAobm93YXlvdXQ9MCkNClsgICAx
OC42NTQzMjhdIHhlbl93ZHQ6IFhlbiBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDENClsg
ICAxOC42NTQzODJdIHhlbl93ZHQ6IGNhbm5vdCByZWdpc3RlciBtaXNjZGV2IG9uIG1pbm9y
PTEzMCAoLTE2KQ0KWyAgIDE4LjY1NDM5Ml0gd2R0OiBwcm9iZSBvZiB3ZHQgZmFpbGVkIHdp
dGggZXJyb3IgLTE2DQpbICAgMTguNjU0OTY2XSBkZXZpY2UtbWFwcGVyOiBpb2N0bDogNC4y
OC4wLWlvY3RsICgyMDE0LTA5LTE3KSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAcmVkaGF0LmNv
bQ0KWyAgIDE4LjY1NTI3MF0gZGV2aWNlLW1hcHBlcjogY2FjaGUtcG9saWN5LW1xOiB2ZXJz
aW9uIDEuMi4wIGxvYWRlZA0KWyAgIDE4LjY1NTI3Ml0gZGV2aWNlLW1hcHBlcjogY2FjaGUg
Y2xlYW5lcjogdmVyc2lvbiAxLjAuMCBsb2FkZWQNClsgICAxOC42NTUyNzVdIEJsdWV0b290
aDogVmlydHVhbCBIQ0kgZHJpdmVyIHZlciAxLjUNClsgICAxOC42NTUzODhdIEJsdWV0b290
aDogSENJIFVBUlQgZHJpdmVyIHZlciAyLjINClsgICAxOC42NTUzOTBdIEJsdWV0b290aDog
SENJIEg0IHByb3RvY29sIGluaXRpYWxpemVkDQpbICAgMTguNjU1MzkwXSBCbHVldG9vdGg6
IEhDSSBCQ1NQIHByb3RvY29sIGluaXRpYWxpemVkDQpbICAgMTguNjU1MzkxXSBCbHVldG9v
dGg6IEhDSUxMIHByb3RvY29sIGluaXRpYWxpemVkDQpbICAgMTguNjU1MzkxXSBCbHVldG9v
dGg6IEhDSUFUSDNLIHByb3RvY29sIGluaXRpYWxpemVkDQpbICAgMTguNjU1MzkyXSBCbHVl
dG9vdGg6IEhDSSBUaHJlZS13aXJlIFVBUlQgKEg1KSBwcm90b2NvbCBpbml0aWFsaXplZA0K
WyAgIDE4LjY1NTQzMl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZl
ciBiY20yMDN4DQpbICAgMTguNjU1NDY0XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRl
cmZhY2UgZHJpdmVyIGJwYTEweA0KWyAgIDE4LjY1NTQ5Nl0gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBiZnVzYg0KWyAgIDE4LjY1NTUyOF0gdXNiY29yZTog
cmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBidHVzYg0KWyAgIDE4LjY1NTU1OV0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBhdGgzaw0KWyAgIDE4
LjY1NjI1NV0gaGlkcmF3OiByYXcgSElEIGV2ZW50cyBkcml2ZXIgKEMpIEppcmkgS29zaW5h
DQpbICAgMTguNjU2NTMwXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJp
dmVyIHVzYmhpZA0KWyAgIDE4LjY1NjUzMF0gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJpdmVy
DQpbICAgMTguNjU4MTE0XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNiB0cmlnZ2VyaW5nIDAg
cG9sYXJpdHkgMQ0KWyAgIDE4LjY1ODExOV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNg0K
WyAgIDE4LjY1ODIyM10geGVuOiByZWdpc3RlcmluZyBnc2kgMjUgdHJpZ2dlcmluZyAwIHBv
bGFyaXR5IDENClsgICAxOC42NTgyMzddIHhlbjogLS0+IHBpcnE9MjUgLT4gaXJxPTI1IChn
c2k9MjUpDQpbICAgMTguNjU4NDI3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIHNuZC11c2ItYXVkaW8NClsgICAxOC42NTg3NDJdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVhMTAxDQpbICAgMTguNjU4Nzg5XSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItdXN4MnkN
ClsgICAxOC42NTg4MjRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgc25kLXVzYi1jYWlhcQ0KWyAgIDE4LjY1ODg1Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLTZmaXJlDQpbICAgMTguNjU4OTEyXSBOZXRm
aWx0ZXIgbWVzc2FnZXMgdmlhIE5FVExJTksgdjAuMzAuDQpbICAgMTguNjU4OTE5XSBuZm5s
X2FjY3Q6IHJlZ2lzdGVyaW5nIHdpdGggbmZuZXRsaW5rLg0KWyAgIDE4LjY1ODk4MF0gbmZf
Y29ubnRyYWNrIHZlcnNpb24gMC41LjAgKDE2Mzg0IGJ1Y2tldHMsIDY1NTM2IG1heCkNClsg
ICAxOC42NTkyNTRdIGN0bmV0bGluayB2MC45MzogcmVnaXN0ZXJpbmcgd2l0aCBuZm5ldGxp
bmsuDQpbICAgMTguNjU5NjUzXSB4dF90aW1lOiBrZXJuZWwgdGltZXpvbmUgaXMgLTAwMDAN
ClsgICAxOC42NTk2ODBdIGlwX3NldDogcHJvdG9jb2wgNg0KWyAgIDE4LjY1OTc2N10gSVBW
UzogUmVnaXN0ZXJlZCBwcm90b2NvbHMgKCkNClsgICAxOC42NTk4ODRdIElQVlM6IENvbm5l
Y3Rpb24gaGFzaCB0YWJsZSBjb25maWd1cmVkIChzaXplPTQwOTYsIG1lbW9yeT02NEtieXRl
cykNClsgICAxOC42NTk5NDldIElQVlM6IENyZWF0aW5nIG5ldG5zIHNpemU9MTg0MCBpZD0w
DQpbICAgMTguNzEwNDM4XSBzb3VuZCBoZGF1ZGlvQzBEMjogYXV0b2NvbmZpZzogbGluZV9v
dXRzPTQgKDB4MTQvMHgxNS8weDE2LzB4MTcvMHgwKSB0eXBlOmxpbmUNClsgICAxOC43MTA0
NDBdIHNvdW5kIGhkYXVkaW9DMEQyOiAgICBzcGVha2VyX291dHM9MCAoMHgwLzB4MC8weDAv
MHgwLzB4MCkNClsgICAxOC43MTA0NDJdIHNvdW5kIGhkYXVkaW9DMEQyOiAgICBocF9vdXRz
PTEgKDB4MWIvMHgwLzB4MC8weDAvMHgwKQ0KWyAgIDE4LjcxMDQ0M10gc291bmQgaGRhdWRp
b0MwRDI6ICAgIG1vbm86IG1vbm9fb3V0PTB4MA0KWyAgIDE4LjcxMDQ0NF0gc291bmQgaGRh
dWRpb0MwRDI6ICAgIGRpZy1vdXQ9MHgxMS8weDFlDQpbICAgMTguNzEwNDQ1XSBzb3VuZCBo
ZGF1ZGlvQzBEMjogICAgaW5wdXRzOg0KWyAgIDE4LjcxMDQ0Nl0gc291bmQgaGRhdWRpb0Mw
RDI6ICAgICAgRnJvbnQgTWljPTB4MTkNClsgICAxOC43MTA0NDddIHNvdW5kIGhkYXVkaW9D
MEQyOiAgICAgIFJlYXIgTWljPTB4MTgNClsgICAxOC43MTA0NDldIHNvdW5kIGhkYXVkaW9D
MEQyOiAgICAgIExpbmU9MHgxYQ0KWyAgIDE4LjcyNDAwNF0gdXNiIDQtNTogbmV3IGZ1bGwt
c3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2luZyBvaGNpLXBjaQ0KWyAgIDE4LjczMDc2
Nl0gcmFuZG9tOiBub25ibG9ja2luZyBwb29sIGlzIGluaXRpYWxpemVkDQpbICAgMTguODQw
NjA5XSB1c2IgNy0zOiBuZXcgbG93LXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIgdXNpbmcg
b2hjaS1wY2kNClsgICAxOS4wMDA5ODZdIHVzYiA3LTM6IE5ldyBVU0IgZGV2aWNlIGZvdW5k
LCBpZFZlbmRvcj0wNDZkLCBpZFByb2R1Y3Q9YzUxNw0KWyAgIDE5LjAwMDk5Ml0gdXNiIDct
MzogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTEsIFByb2R1Y3Q9MiwgU2VyaWFsTnVt
YmVyPTANClsgICAxOS4wMDA5OTddIHVzYiA3LTM6IFByb2R1Y3Q6IFVTQiBSZWNlaXZlcg0K
WyAgIDE5LjAwMTAwMV0gdXNiIDctMzogTWFudWZhY3R1cmVyOiBMb2dpdGVjaA0KWyAgIDE5
LjAwODY1OV0gaW5wdXQ6IExvZ2l0ZWNoIFVTQiBSZWNlaXZlciBhcyAvZGV2aWNlcy9wY2kw
MDAwOjAwLzAwMDA6MDA6MTYuMC91c2I3LzctMy83LTM6MS4wLzAwMDM6MDQ2RDpDNTE3LjAw
MDEvaW5wdXQvaW5wdXQ1DQpbICAgMTkuMDA5NDE3XSBsb2dpdGVjaCAwMDAzOjA0NkQ6QzUx
Ny4wMDAxOiBpbnB1dCxoaWRyYXcwOiBVU0IgSElEIHYxLjEwIEtleWJvYXJkIFtMb2dpdGVj
aCBVU0IgUmVjZWl2ZXJdIG9uIHVzYi0wMDAwOjAwOjE2LjAtMy9pbnB1dDANClsgICAxOS4w
MTU2MjZdIElQVlM6IGlwdnMgbG9hZGVkLg0KWyAgIDE5LjAxNzAxM10gbG9naXRlY2ggMDAw
MzowNDZEOkM1MTcuMDAwMjogZml4aW5nIHVwIExvZ2l0ZWNoIGtleWJvYXJkIHJlcG9ydCBk
ZXNjcmlwdG9yDQpbICAgMTkuMDE3NTAzXSBpbnB1dDogTG9naXRlY2ggVVNCIFJlY2VpdmVy
IGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxNi4wL3VzYjcvNy0zLzctMzoxLjEv
MDAwMzowNDZEOkM1MTcuMDAwMi9pbnB1dC9pbnB1dDYNClsgICAxOS4wMTgyNTBdIGxvZ2l0
ZWNoIDAwMDM6MDQ2RDpDNTE3LjAwMDI6IGlucHV0LGhpZGRldjAsaGlkcmF3MTogVVNCIEhJ
RCB2MS4xMCBNb3VzZSBbTG9naXRlY2ggVVNCIFJlY2VpdmVyXSBvbiB1c2ItMDAwMDowMDox
Ni4wLTMvaW5wdXQxDQpbICAgMTkuMTU0MDM0XSB1c2IgNC01OiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MGExMiwgaWRQcm9kdWN0PTAwMDENClsgICAxOS4xNTQwMzZdIHVz
YiA0LTU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0wLCBQcm9kdWN0PTIsIFNlcmlh
bE51bWJlcj0wDQpbICAgMTkuMTU0MDM3XSB1c2IgNC01OiBQcm9kdWN0OiBFRFJDbGFzc29u
ZQ0KWyAgIDE5LjE1NDE1NF0gaXBfdGFibGVzOiAoQykgMjAwMC0yMDA2IE5ldGZpbHRlciBD
b3JlIFRlYW0NClsgICAxOS4xNTQyMzZdIFRDUDogY3ViaWMgcmVnaXN0ZXJlZA0KWyAgIDE5
LjE1NDg5Ml0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMA0KWyAgIDE5LjE1
NTczOV0gaXA2X3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtDQpb
ICAgMTkuMjQxNzUxXSBzaXQ6IElQdjYgb3ZlciBJUHY0IHR1bm5lbGluZyBkcml2ZXINClsg
ICAxOS4yNDIwNTRdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcNClsgICAx
OS4yNDIxMjRdIGJyaWRnZTogYXV0b21hdGljIGZpbHRlcmluZyB2aWEgYXJwL2lwL2lwNnRh
YmxlcyBoYXMgYmVlbiBkZXByZWNhdGVkLiBVcGRhdGUgeW91ciBzY3JpcHRzIHRvIGxvYWQg
YnJfbmV0ZmlsdGVyIGlmIHlvdSBuZWVkIHRoaXMuDQpbICAgMTkuMzk4ODg1XSBCcmlkZ2Ug
ZmlyZXdhbGxpbmcgcmVnaXN0ZXJlZA0KWyAgIDE5LjM5ODg4OV0gRWJ0YWJsZXMgdjIuMCBy
ZWdpc3RlcmVkDQpbICAgMTkuMzk5MTYwXSBCbHVldG9vdGg6IFJGQ09NTSBUVFkgbGF5ZXIg
aW5pdGlhbGl6ZWQNClsgICAxOS4zOTkxNzFdIEJsdWV0b290aDogUkZDT01NIHNvY2tldCBs
YXllciBpbml0aWFsaXplZA0KWyAgIDE5LjM5OTE4MV0gQmx1ZXRvb3RoOiBSRkNPTU0gdmVy
IDEuMTENClsgICAxOS4zOTkxODldIEJsdWV0b290aDogQk5FUCAoRXRoZXJuZXQgRW11bGF0
aW9uKSB2ZXIgMS4zDQpbICAgMTkuMzk5MTkwXSBCbHVldG9vdGg6IEJORVAgZmlsdGVyczog
cHJvdG9jb2wgbXVsdGljYXN0DQpbICAgMTkuMzk5MjExXSBCbHVldG9vdGg6IEJORVAgc29j
a2V0IGxheWVyIGluaXRpYWxpemVkDQpbICAgMTkuMzk5MjEzXSBCbHVldG9vdGg6IEhJRFAg
KEh1bWFuIEludGVyZmFjZSBFbXVsYXRpb24pIHZlciAxLjINClsgICAxOS4zOTkyMTZdIEJs
dWV0b290aDogSElEUCBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQNClsgICAxOS4zOTkyNjZd
IEtleSB0eXBlIGNlcGggcmVnaXN0ZXJlZA0KWyAgIDE5LjM5OTUyNF0gbGliY2VwaDogbG9h
ZGVkIChtb24vb3NkIHByb3RvIDE1LzI0KQ0KWyAgIDE5LjQwMDUwN10gcmVnaXN0ZXJlZCB0
YXNrc3RhdHMgdmVyc2lvbiAxDQpbICAgMTkuNDAyMTc0XSBCdHJmcyBsb2FkZWQNClsgICAx
OS42MjQ5MzBdIGF0YTQ6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAw
KQ0KWyAgIDE5LjYyNDk3MF0gY29uc29sZSBbbmV0Y29uMF0gZW5hYmxlZA0KWyAgIDE5LjYy
NDk3MV0gbmV0Y29uc29sZTogbmV0d29yayBsb2dnaW5nIHN0YXJ0ZWQNClsgICAxOS42MzEy
MzFdIHJ0Y19jbW9zIDAwOjAyOiBzZXR0aW5nIHN5c3RlbSBjbG9jayB0byAyMDE0LTExLTE4
IDIxOjQ1OjI0IFVUQyAoMTQxNjM0NzEyNCkNClsgICAxOS42NTA0ODVdIGF0YTI6IFNBVEEg
bGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQ0KWyAgIDE5LjY1MDU4N10gQUxT
QSBkZXZpY2UgbGlzdDoNClsgICAxOS42NTA1ODhdICAgIzA6IEhEQSBBVEkgU0IgYXQgMHhm
ZGJmODAwMCBpcnEgMTYNClsgICAxOS42NTA1ODldICAgIzE6IEhEQSBBVEkgSERNSSBhdCAw
eGZlOWZjMDAwIGlycSAxMjQNClsgICAxOS44MzM4NzZdIGF0YTE6IFNBVEEgbGluayB1cCA2
LjAgR2JwcyAoU1N0YXR1cyAxMzMgU0NvbnRyb2wgMzAwKQ0KWyAgIDE5Ljg0MjE2N10gYXRh
MzogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEyMyBTQ29udHJvbCAzMDApDQpb
ICAgMTkuODUxNDc1XSBhdGExLjAwOiBBVEEtODogSEdTVCBIRE43MjQwNDBBTEU2NDAsIE1K
QU9BNUUwLCBtYXggVURNQS8xMzMNClsgICAxOS44NTk2MTldIGF0YTEuMDA6IDc4MTQwMzcx
Njggc2VjdG9ycywgbXVsdGkgMDogTEJBNDggTkNRIChkZXB0aCAzMS8zMiksIEFBDQpbICAg
MTkuODY4NDM2XSBhdGEzLjAwOiBBVEEtODogSGl0YWNoaSBIRFM3MjIwMjBBTEEzMzAsIEpL
QU9BMjBOLCBtYXggVURNQS8xMzMNClsgICAxOS44NzY2MzVdIGF0YTMuMDA6IDM5MDcwMjkx
Njggc2VjdG9ycywgbXVsdGkgMDogTEJBNDggTkNRIChkZXB0aCAzMS8zMiksIEFBDQpbICAg
MTkuODg1NDg5XSBhdGExLjAwOiBjb25maWd1cmVkIGZvciBVRE1BLzEzMw0KWyAgIDE5Ljg5
NDU4NV0gYXRhMy4wMDogY29uZmlndXJlZCBmb3IgVURNQS8xMzMNClsgICAxOS44OTU4NDRd
IHNjc2kgMDowOjA6MDogRGlyZWN0LUFjY2VzcyAgICAgQVRBICAgICAgSEdTVCBIRE43MjQw
NDBBTCBBNUUwIFBROiAwIEFOU0k6IDUNClsgICAxOS44OTk1MTBdIHNkIDA6MDowOjA6IFtz
ZGFdIDc4MTQwMzcxNjggNTEyLWJ5dGUgbG9naWNhbCBibG9ja3M6ICg0LjAwIFRCLzMuNjMg
VGlCKQ0KWyAgIDE5Ljg5OTUxN10gc2QgMDowOjA6MDogW3NkYV0gNDA5Ni1ieXRlIHBoeXNp
Y2FsIGJsb2Nrcw0KWyAgIDE5LjkwMDE5MV0gc2QgMDowOjA6MDogQXR0YWNoZWQgc2NzaSBn
ZW5lcmljIHNnMCB0eXBlIDANClsgICAxOS45MDA1MDddIHNkIDA6MDowOjA6IFtzZGFdIFdy
aXRlIFByb3RlY3QgaXMgb2ZmDQpbICAgMTkuOTAwNTE2XSBzZCAwOjA6MDowOiBbc2RhXSBN
b2RlIFNlbnNlOiAwMCAzYSAwMCAwMA0KWyAgIDE5LjkwMDg0MF0gc2QgMDowOjA6MDogW3Nk
YV0gV3JpdGUgY2FjaGU6IGVuYWJsZWQsIHJlYWQgY2FjaGU6IGVuYWJsZWQsIGRvZXNuJ3Qg
c3VwcG9ydCBEUE8gb3IgRlVBDQpbICAgMTkuOTUzNTMxXSBzY3NpIDI6MDowOjA6IERpcmVj
dC1BY2Nlc3MgICAgIEFUQSAgICAgIEhpdGFjaGkgSERTNzIyMDIgQTIwTiBQUTogMCBBTlNJ
OiA1DQpbICAgMTkuOTYwNzI3XSBzZCAyOjA6MDowOiBbc2RiXSAzOTA3MDI5MTY4IDUxMi1i
eXRlIGxvZ2ljYWwgYmxvY2tzOiAoMi4wMCBUQi8xLjgxIFRpQikNClsgICAxOS45NjA3NzFd
IHNkIDI6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJpYyBzZzEgdHlwZSAwDQpbICAgMTku
OTcwMjUyXSAgc2RhOiBzZGExIHNkYTIgc2RhMyBzZGE0DQpbICAgMTkuOTcxNjI2XSBzZCAw
OjA6MDowOiBbc2RhXSBBdHRhY2hlZCBTQ1NJIGRpc2sNClsgICAxOS45ODc3MTZdIHNkIDI6
MDowOjA6IFtzZGJdIFdyaXRlIFByb3RlY3QgaXMgb2ZmDQpbICAgMTkuOTk0MjQ5XSBzZCAy
OjA6MDowOiBbc2RiXSBNb2RlIFNlbnNlOiAwMCAzYSAwMCAwMA0KWyAgIDIwLjAwMDY0NV0g
c2QgMjowOjA6MDogW3NkYl0gV3JpdGUgY2FjaGU6IGVuYWJsZWQsIHJlYWQgY2FjaGU6IGVu
YWJsZWQsIGRvZXNuJ3Qgc3VwcG9ydCBEUE8gb3IgRlVBDQpbICAgMjAuMDExMjE2XSAgc2Ri
OiBzZGIxDQpbICAgMjAuMDE3ODQ4XSBzZCAyOjA6MDowOiBbc2RiXSBBdHRhY2hlZCBTQ1NJ
IGRpc2sNClsgICAyMC4wMjUxMTJdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEx
MDRLIChmZmZmZmZmZjgyMzA2MDAwIC0gZmZmZmZmZmY4MjQxYTAwMCkNClsgICAyMC4wMzEy
MjNdIFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogMTg0MzJr
DQpbICAgMjAuMDQ2MTAxXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAzNTZLIChm
ZmZmODgwMDAxYmE3MDAwIC0gZmZmZjg4MDAwMWMwMDAwMCkNClsgICAyMC4wNTMzNzBdIEZy
ZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDE2NDhLIChmZmZmODgwMDAyMDY0MDAwIC0g
ZmZmZjg4MDAwMjIwMDAwMCkNClsgICAyMC4xMDE1OTBdIHVkZXZkWzE2MDZdOiBzdGFydGlu
ZyB2ZXJzaW9uIDE3NQ0KWyAgIDIxLjA5Njg1NF0gRVhUNC1mcyAoZG0tMCk6IG1vdW50ZWQg
ZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiAobnVsbCkNClsgICAy
My42ODY2MzNdIHVkZXZkWzE5ODhdOiBzdGFydGluZyB2ZXJzaW9uIDE3NQ0KWyAgIDI2Ljk2
ODU5MF0gRVhUNC1mcyAoZG0tMCk6IHJlLW1vdW50ZWQuIE9wdHM6IChudWxsKQ0KWyAgIDUz
LjUwOTAzNF0gRVhUNC1mcyAoZG0tMCk6IHJlLW1vdW50ZWQuIE9wdHM6IGJhcnJpZXI9MSxl
cnJvcnM9cmVtb3VudC1ybw0KWyAgIDU3LjczNDQ4M10gQWRkaW5nIDIwOTcxNDhrIHN3YXAg
b24gL2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtc3dhcC4gIFByaW9yaXR5Oi0xIGV4dGVu
dHM6MSBhY3Jvc3M6MjA5NzE0OGsgDQpbICAgNjMuOTA2NDM3XSBFWFQ0LWZzIChzZGExKTog
bW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJp
ZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAgIDY1Ljk0MTc4Nl0gcjgxNjkgMDAwMDowZDow
MC4wIGV0aDA6IGxpbmsgZG93bg0KWyAgIDY1Ljk0MTg3M10gcjgxNjkgMDAwMDowZDowMC4w
IGV0aDA6IGxpbmsgZG93bg0KWyAgIDY2LjAxNTIyOF0gcjgxNjkgMDAwMDowYzowMC4wIGV0
aDE6IGxpbmsgZG93bg0KWyAgIDY2LjAxNTI3M10gcjgxNjkgMDAwMDowYzowMC4wIGV0aDE6
IGxpbmsgZG93bg0KWyAgIDY3LjgzNDQ3OF0gcjgxNjkgMDAwMDowZDowMC4wIGV0aDA6IGxp
bmsgdXANClsgICA2OC42MzE1ODldIHI4MTY5IDAwMDA6MGM6MDAuMCBldGgxOiBsaW5rIHVw
DQpbICAgODEuMDI1NjgxXSBuZl9jb25udHJhY2s6IGF1dG9tYXRpYyBoZWxwZXIgYXNzaWdu
bWVudCBpcyBkZXByZWNhdGVkIGFuZCBpdCB3aWxsIGJlIHJlbW92ZWQgc29vbi4gVXNlIHRo
ZSBpcHRhYmxlcyBDVCB0YXJnZXQgdG8gYXR0YWNoIGhlbHBlcnMgaW5zdGVhZC4NClsgIDEw
Ni4zNTMzMzNdIEVYVDQtZnMgKGRtLTIpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRl
cmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJvDQpbICAx
MTYuMzA3MzcxXSBFWFQ0LWZzIChkbS01MCk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9y
ZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8NClsg
IDEyOS43NDYyMzJdIEVYVDQtZnMgKGRtLTQ5KTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGgg
b3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0K
WyAgMTM5LjY2NjE1OF0gRVhUNC1mcyAoZG0tNDgpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0
aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJv
DQpbICAxNjcuNzg2NzY1XSBFWFQ0LWZzIChkbS00NSk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3
aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQt
cm8NClsgIDE4NC41NDU0MjVdIEVYVDQtZnMgKGRtLTQ3KTogbW91bnRlZCBmaWxlc3lzdGVt
IHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3Vu
dC1ybw0KWyAgMjA0LjU0Njc0M10gRVhUNC1mcyAoZG0tNDYpOiBtb3VudGVkIGZpbGVzeXN0
ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1v
dW50LXJvDQpbICAyOTguNDcxMzY1XSBFWFQ0LWZzIChzZGIxKTogbW91bnRlZCBmaWxlc3lz
dGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVt
b3VudC1ybw0KWyAgMzE0LjExMzc2MF0gZGV2aWNlIHZpZjEuMCBlbnRlcmVkIHByb21pc2N1
b3VzIG1vZGUNCihkMSkgWzIwMTQtMTEtMTggMjE6NTA6MTkuMTU3XSBtYXBwaW5nIGtlcm5l
bCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQxKSBbMjAxNC0xMS0xOCAyMTo1MDoxOS4xNTdd
IGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MDoxOS40
MThdIHRyYXBzLmM6MjU3OTpkMXYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYu
DQpbICAzMTQuOTM5MzU4XSB4ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVs
IDE3LCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAgMzE0
Ljk1NTAwNl0geGVuLWJsa2JhY2s6cmluZy1yZWYgOSwgZXZlbnQtY2hhbm5lbCAxOCwgcHJv
dG9jb2wgMSAoeDg2XzY0LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDMxNi4xMTg1NDhd
IHZpZiB2aWYtMS0wIHZpZjEuMDogR3Vlc3QgUnggcmVhZHkNClsgIDMxNi4xMjk3MTFdIHhl
bl9icmlkZ2U6IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAg
MzE2LjE0MDcyNF0geGVuX2JyaWRnZTogcG9ydCAxKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJk
aW5nIHN0YXRlDQpbICAzMjAuMTE0NTI5XSBkZXZpY2UgdmlmMi4wIGVudGVyZWQgcHJvbWlz
Y3VvdXMgbW9kZQ0KKGQyKSBbMjAxNC0xMS0xOCAyMTo1MDoyNS4xNzddIG1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDIpIFsyMDE0LTExLTE4IDIxOjUwOjI1LjE3
N10gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjUwOjI1
LjI1M10gdHJhcHMuYzoyNTc5OmQydjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZm
Zi4NClsgIDMyMC43NzU0MjFdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5u
ZWwgMTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAz
MjEuNzkxOTQyXSB2aWYgdmlmLTItMCB2aWYyLjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzMjEu
ODAyODc3XSB4ZW5fYnJpZGdlOiBwb3J0IDIodmlmMi4wKSBlbnRlcmVkIGZvcndhcmRpbmcg
c3RhdGUNClsgIDMyMS44MTM2NjBdIHhlbl9icmlkZ2U6IHBvcnQgMih2aWYyLjApIGVudGVy
ZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzI2LjAxNDQ4Ml0gZGV2aWNlIHZpZjMuMCBlbnRl
cmVkIHByb21pc2N1b3VzIG1vZGUNCihkMykgWzIwMTQtMTEtMTggMjE6NTA6MzAuOTY0XSBt
YXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQzKSBbMjAxNC0xMS0xOCAy
MTo1MDozMC45NjRdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1MDozMS4wNTZdIHRyYXBzLmM6MjU3OTpkM3YwIERvbWFpbiBhdHRlbXB0ZWQgV1JN
U1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAw
MDAwMDAwMGZmZmYuDQpbICAzMjYuNjk3Mzg1XSB4ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBl
dmVudC1jaGFubmVsIDE3LCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdy
YW50cw0KWyAgMzI3LjcxNjcwM10gdmlmIHZpZi0zLTAgdmlmMy4wOiBHdWVzdCBSeCByZWFk
eQ0KWyAgMzI3LjcyNzEwOV0geGVuX2JyaWRnZTogcG9ydCAzKHZpZjMuMCkgZW50ZXJlZCBm
b3J3YXJkaW5nIHN0YXRlDQpbICAzMjcuNzM3NDY2XSB4ZW5fYnJpZGdlOiBwb3J0IDModmlm
My4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDMzMS4xNjE4NjNdIHhlbl9icmlk
Z2U6IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzMxLjg5
MjI0MF0gZGV2aWNlIHZpZjQuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNCihkNCkgWzIw
MTQtMTEtMTggMjE6NTA6MzYuODQ3XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1l
bW9yeQ0KKGQ0KSBbMjAxNC0xMS0xOCAyMTo1MDozNi44NDddIGFib3V0IHRvIGdldCBzdGFy
dGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MDozNi45MjRdIHRyYXBzLmM6MjU3OTpk
NHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAw
MDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuDQpbICAzMzIuNDQ5NjQ5XSB4
ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDEwLCBwcm90b2NvbCAxICh4
ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAgMzMzLjQ2NjE4Ml0gdmlmIHZpZi00
LTAgdmlmNC4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzMzLjQ3NjEyNF0geGVuX2JyaWRnZTog
cG9ydCA0KHZpZjQuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzMzMuNDg2MTQy
XSB4ZW5fYnJpZGdlOiBwb3J0IDQodmlmNC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUN
CihYRU4pIFsyMDE0LTExLTE4IDIxOjUwOjM5LjEwOF0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2
MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byAyIGZyYW1lcw0KWyAgMzM2Ljg3MTM2MV0g
eGVuX2JyaWRnZTogcG9ydCAyKHZpZjIuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpb
ICAzMzcuNjY0ODI4XSBkZXZpY2UgdmlmNS4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0K
KGQ1KSBbMjAxNC0xMS0xOCAyMTo1MDo0Mi42MTNdIG1hcHBpbmcga2VybmVsIGludG8gcGh5
c2ljYWwgbWVtb3J5DQooZDUpIFsyMDE0LTExLTE4IDIxOjUwOjQyLjYxNF0gYWJvdXQgdG8g
Z2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjUwOjQyLjY5NF0gdHJhcHMu
YzoyNTc5OmQ1djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDMzOC4y
MjAwNjJdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3Rv
Y29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzMzkuMjM2MTM3XSB2
aWYgdmlmLTUtMCB2aWY1LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzMzkuMjQ1NTc5XSB4ZW5f
YnJpZGdlOiBwb3J0IDUodmlmNS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDMz
OS4yNTUwMDBdIHhlbl9icmlkZ2U6IHBvcnQgNSh2aWY1LjApIGVudGVyZWQgZm9yd2FyZGlu
ZyBzdGF0ZQ0KWyAgMzQyLjc5NDMyOV0geGVuX2JyaWRnZTogcG9ydCAzKHZpZjMuMCkgZW50
ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNDMuNzExMDg3XSBkZXZpY2UgdmlmNi4wIGVu
dGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ2KSBbMjAxNC0xMS0xOCAyMTo1MDo0OC42NjZd
IG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDYpIFsyMDE0LTExLTE4
IDIxOjUwOjQ4LjY2Nl0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjUwOjQ4Ljc4OV0gdHJhcHMuYzoyNTc5OmQ2djAgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAw
MDAwMDAwMDAwZmZmZi4NClsgIDM0NC4zMTUyMjBdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgs
IGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQg
Z3JhbnRzDQpbICAzNDUuMzMxNzQ0XSB2aWYgdmlmLTYtMCB2aWY2LjA6IEd1ZXN0IFJ4IHJl
YWR5DQpbICAzNDUuMzQwNjQ3XSB4ZW5fYnJpZGdlOiBwb3J0IDYodmlmNi4wKSBlbnRlcmVk
IGZvcndhcmRpbmcgc3RhdGUNClsgIDM0NS4zNDk0NThdIHhlbl9icmlkZ2U6IHBvcnQgNih2
aWY2LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzQ4LjUwMzg1OF0geGVuX2Jy
aWRnZTogcG9ydCA0KHZpZjQuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNDku
NjkwNjA5XSBkZXZpY2UgdmlmNy4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ3KSBb
MjAxNC0xMS0xOCAyMTo1MDo1NC42MzddIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwg
bWVtb3J5DQooZDcpIFsyMDE0LTExLTE4IDIxOjUwOjU0LjYzN10gYWJvdXQgdG8gZ2V0IHN0
YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjUwOjU0LjcxMV0gdHJhcHMuYzoyNTc5
OmQ3djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgw
MDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM1MC4yMzc0ODhd
IHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEg
KHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzNTEuMjU2MDU0XSB2aWYgdmlm
LTctMCB2aWY3LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzNTEuMjY0NDE0XSB4ZW5fYnJpZGdl
OiBwb3J0IDcodmlmNy4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM1MS4yNzI2
MDddIHhlbl9icmlkZ2U6IHBvcnQgNyh2aWY3LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0
ZQ0KWyAgMzU0LjI2Njg3MV0geGVuX2JyaWRnZTogcG9ydCA1KHZpZjUuMCkgZW50ZXJlZCBm
b3J3YXJkaW5nIHN0YXRlDQpbICAzNTUuNzIxNjcwXSBkZXZpY2UgdmlmOC4wIGVudGVyZWQg
cHJvbWlzY3VvdXMgbW9kZQ0KKGQ4KSBbMjAxNC0xMS0xOCAyMTo1MTowMC43NjRdIG1hcHBp
bmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDgpIFsyMDE0LTExLTE4IDIxOjUx
OjAwLjc2NF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDIx
OjUxOjAwLjgzOF0gdHJhcHMuYzoyNTc5OmQ4djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAw
MDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAw
MDAwZmZmZi4NClsgIDM1Ni4zNjM0MzZdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50
LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRz
DQpbICAzNTcuMzgwODYxXSB2aWYgdmlmLTgtMCB2aWY4LjA6IEd1ZXN0IFJ4IHJlYWR5DQpb
ICAzNTcuMzg4NzE5XSB4ZW5fYnJpZGdlOiBwb3J0IDgodmlmOC4wKSBlbnRlcmVkIGZvcndh
cmRpbmcgc3RhdGUNClsgIDM1Ny4zOTYzODBdIHhlbl9icmlkZ2U6IHBvcnQgOCh2aWY4LjAp
IGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzYwLjQwMzE0M10geGVuX2JyaWRnZTog
cG9ydCA2KHZpZjYuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNjEuODQwMzQ4
XSBkZXZpY2UgdmlmOS4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ5KSBbMjAxNC0x
MS0xOCAyMTo1MTowNi43OTRdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5
DQooZDkpIFsyMDE0LTExLTE4IDIxOjUxOjA2Ljc5NF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQu
Li4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjUxOjA2Ljg4MV0gdHJhcHMuYzoyNTc5OmQ5djAg
RG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAw
MDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM2Mi40MTA5MjddIHhlbi1i
bGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTcsIHByb3RvY29sIDEgKHg4Nl82
NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzNjIuNDc3MTkwXSB2aWYgdmlmLTktMCB2
aWY5LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzNjIuNDg0MjQ3XSB4ZW5fYnJpZGdlOiBwb3J0
IDkodmlmOS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM2Mi40OTA5NTRdIHhl
bl9icmlkZ2U6IHBvcnQgOSh2aWY5LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NTE6MDcuNDI5XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIElu
Y3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDMgZnJhbWVzDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1MTowNy40NDZdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNr
IHNpemUgdG8gNCBmcmFtZXMNClsgIDM2Ni4zMjYxMzRdIHhlbl9icmlkZ2U6IHBvcnQgNyh2
aWY3LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzY4LjIyNDE3Ml0gZGV2aWNl
IHZpZjEwLjAgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQooZDEwKSBbMjAxNC0xMS0xOCAy
MTo1MToxMy4xNzddIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDEw
KSBbMjAxNC0xMS0xOCAyMTo1MToxMy4xNzddIGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQoo
WEVOKSBbMjAxNC0xMS0xOCAyMTo1MToxMy4yNTZdIHRyYXBzLmM6MjU3OTpkMTB2MCBEb21h
aW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAw
MDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLg0KWyAgMzY4LjcyMDAwNF0geGVuLWJsa2Jh
Y2s6cmluZy1yZWYgOCwgZXZlbnQtY2hhbm5lbCAxMCwgcHJvdG9jb2wgMSAoeDg2XzY0LWFi
aSkgcGVyc2lzdGVudCBncmFudHMNClsgIDM2OC44ODU4NDFdIHZpZiB2aWYtMTAtMCB2aWYx
MC4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzY4Ljg5MjcxMl0geGVuX2JyaWRnZTogcG9ydCAx
MCh2aWYxMC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM2OC44OTk2NjNdIHhl
bl9icmlkZ2U6IHBvcnQgMTAodmlmMTAuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpb
ICAzNzIuNDA5MTg1XSB4ZW5fYnJpZGdlOiBwb3J0IDgodmlmOC4wKSBlbnRlcmVkIGZvcndh
cmRpbmcgc3RhdGUNCihYRU4pIFsyMDE0LTExLTE4IDIxOjUxOjE4Ljg2MF0gZ3JhbnRfdGFi
bGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA1IGZyYW1lcw0KWyAg
Mzc0LjM1NzQ3OV0gZGV2aWNlIHZpZjExLjAgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQoo
ZDExKSBbMjAxNC0xMS0xOCAyMTo1MToxOS4zMTBdIG1hcHBpbmcga2VybmVsIGludG8gcGh5
c2ljYWwgbWVtb3J5DQooZDExKSBbMjAxNC0xMS0xOCAyMTo1MToxOS4zMTBdIGFib3V0IHRv
IGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MToxOS40MDddIHRyYXBz
LmM6MjU3OTpkMTF2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQg
ZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLg0KWyAgMzc0
Ljk1MjMzNF0geGVuLWJsa2JhY2s6cmluZy1yZWYgOCwgZXZlbnQtY2hhbm5lbCAxNywgcHJv
dG9jb2wgMSAoeDg2XzY0LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDM3NS4wMTg3Njld
IHZpZiB2aWYtMTEtMCB2aWYxMS4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzc1LjAyNTYxN10g
eGVuX2JyaWRnZTogcG9ydCAxMSh2aWYxMS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUN
ClsgIDM3NS4wMzI0NDhdIHhlbl9icmlkZ2U6IHBvcnQgMTEodmlmMTEuMCkgZW50ZXJlZCBm
b3J3YXJkaW5nIHN0YXRlDQpbICAzNzcuNTMxNzcxXSB4ZW5fYnJpZGdlOiBwb3J0IDkodmlm
OS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM4MC43Mzc4MzJdIGRldmljZSB2
aWYxMi4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQxMikgWzIwMTQtMTEtMTggMjE6
NTE6MjUuNjg5XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQxMikg
WzIwMTQtMTEtMTggMjE6NTE6MjUuNjg5XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLg0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NTE6MjUuNzgwXSB0cmFwcy5jOjI1Nzk6ZDEydjAgRG9tYWlu
IGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAw
MDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM4MS4yNDE2ODVdIHhlbi1ibGtiYWNr
OnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkp
IHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzODEuMzgxMTcyXSB2aWYgdmlmLTEyLTAgdmlmMTIu
MDogR3Vlc3QgUnggcmVhZHkNClsgIDM4MS4zODgwNDVdIHhlbl9icmlkZ2U6IHBvcnQgMTIo
dmlmMTIuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzODEuMzk1MDM0XSB4ZW5f
YnJpZGdlOiBwb3J0IDEyKHZpZjEyLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAg
MzgzLjkzNTAzNV0geGVuX2JyaWRnZTogcG9ydCAxMCh2aWYxMC4wKSBlbnRlcmVkIGZvcndh
cmRpbmcgc3RhdGUNClsgIDM4Ni44NzA0MThdIGRldmljZSB2aWYxMy4wIGVudGVyZWQgcHJv
bWlzY3VvdXMgbW9kZQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTE6MzEuODY2XSBBTUQtVmk6
IERpc2FibGU6IGRldmljZSBpZCA9IDB4YTQsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTE6MzEuODY2XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE0LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0g
MHg1MTIzZjYwMDAsIGRvbWFpbiA9IDEzLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0
LTExLTE4IDIxOjUxOjMxLjg2Nl0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowMzowNi4wIGZy
b20gZG9tMCB0byBkb20xMw0KKGQxMykgWzIwMTQtMTEtMTggMjE6NTE6MzEuODcyXSBtYXBw
aW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQxMykgWzIwMTQtMTEtMTggMjE6
NTE6MzEuODcyXSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLg0KWyAgMzg3LjAwNDI1MF0geGVu
X3BjaWJhY2s6IHZwY2k6IDAwMDA6MDM6MDYuMDogYXNzaWduIHRvIHZpcnR1YWwgc2xvdCAw
DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTozMi4xMDhdIHRyYXBzLmM6MjU3OTpkMTN2MCBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAw
MDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLg0KWyAgMzg3LjYyMTQ2NF0geGVuLWJs
a2JhY2s6cmluZy1yZWYgOSwgZXZlbnQtY2hhbm5lbCAxMSwgcHJvdG9jb2wgMSAoeDg2XzY0
LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDM4OC42Mzk1NDhdIHZpZiB2aWYtMTMtMCB2
aWYxMy4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzg4LjY0NjM2MF0geGVuX2JyaWRnZTogcG9y
dCAxMyh2aWYxMy4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM4OC42NTMxNzZd
IHhlbl9icmlkZ2U6IHBvcnQgMTModmlmMTMuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRl
DQpbICAzODguNzE1NzIzXSBwY2liYWNrIDAwMDA6MDM6MDYuMDogZW5hYmxpbmcgZGV2aWNl
ICgwMDAwIC0+IDAwMDEpDQpbICAzODguNzIyNDI1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAy
MiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgMzg4LjcyOTA3MF0gQWxyZWFkeSBzZXR1
cCB0aGUgR1NJIDoyMg0KWyAgMzg4LjczNjcxNl0gcGNpYmFjayAwMDAwOjAzOjA2LjA6IGVu
YWJsaW5nIGJ1cyBtYXN0ZXJpbmcNClsgIDM5MC4wNzEzOTldIHhlbl9icmlkZ2U6IHBvcnQg
MTEodmlmMTEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzOTIuOTUzMzg3XSBk
ZXZpY2UgdmlmMTQuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNCihkMTQpIFsyMDE0LTEx
LTE4IDIxOjUxOjM3LjkyMl0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkN
CihkMTQpIFsyMDE0LTExLTE4IDIxOjUxOjM3LjkyMl0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQu
Li4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjUxOjM4LjAxMl0gdHJhcHMuYzoyNTc5OmQxNHYw
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAw
MDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuDQpbICAzOTMuNTQxOTQ4XSB4ZW4t
YmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDEwLCBwcm90b2NvbCAxICh4ODZf
NjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAgMzk0LjU2MjA4NF0gdmlmIHZpZi0xNC0w
IHZpZjE0LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzOTQuNTY4ODI0XSB4ZW5fYnJpZGdlOiBw
b3J0IDE0KHZpZjE0LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzk0LjU3NTcy
Ml0geGVuX2JyaWRnZTogcG9ydCAxNCh2aWYxNC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3Rh
dGUNClsgIDM5Ni40MjEzMzNdIHhlbl9icmlkZ2U6IHBvcnQgMTIodmlmMTIuMCkgZW50ZXJl
ZCBmb3J3YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTo0Mi4wODRdIGdy
YW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gNiBmcmFt
ZXMNClsgIDM5OC45Njk3MjRdIGRldmljZSB2aWYxNS4wIGVudGVyZWQgcHJvbWlzY3VvdXMg
bW9kZQ0KKGQxNSkgWzIwMTQtMTEtMTggMjE6NTE6NDMuOTI0XSBtYXBwaW5nIGtlcm5lbCBp
bnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQxNSkgWzIwMTQtMTEtMTggMjE6NTE6NDMuOTI0XSBh
Ym91dCB0byBnZXQgc3RhcnRlZC4uLg0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTE6NDQuMDE0
XSB0cmFwcy5jOjI1Nzk6ZDE1djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4N
ClsgIDM5OS41Mzg5MzZdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwg
MTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICA0MDAu
NTU2NzcxXSB2aWYgdmlmLTE1LTAgdmlmMTUuMDogR3Vlc3QgUnggcmVhZHkNClsgIDQwMC41
NjM0MzBdIHZwbl9icmlkZ2U6IHBvcnQgMSh2aWYxNS4wKSBlbnRlcmVkIGZvcndhcmRpbmcg
c3RhdGUNClsgIDQwMC41NzAxODddIHZwbl9icmlkZ2U6IHBvcnQgMSh2aWYxNS4wKSBlbnRl
cmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDQwMy42NzgyNTVdIHhlbl9icmlkZ2U6IHBvcnQg
MTModmlmMTMuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICA0MDUuMTE5MTU1XSBk
ZXZpY2UgdmlmMTYuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNClsgIDQwNS4zMzkzNjdd
IGRldmljZSB2aWYxNi4wLWVtdSBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNClsgIDQwNS4z
NTE5MDZdIHhlbl9icmlkZ2U6IHBvcnQgMTYodmlmMTYuMC1lbXUpIGVudGVyZWQgZm9yd2Fy
ZGluZyBzdGF0ZQ0KWyAgNDA1LjM1ODU4OV0geGVuX2JyaWRnZTogcG9ydCAxNih2aWYxNi4w
LWVtdSkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICA0MDYuNDM5OTM3XSBwY2liYWNr
IDAwMDA6MDg6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHgzYyAo
d2FzIDB4MTAwLCB3cml0aW5nIDB4MTA3KQ0KWyAgNDA2LjQ0ODczMl0gcGNpYmFjayAwMDAw
OjA4OjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4MTAgKHdhcyAw
eDQsIHdyaXRpbmcgMHhmZTBmZTAwNCkNClsgIDQwNi40NTczMzVdIHBjaWJhY2sgMDAwMDow
ODowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweGMgKHdhcyAweDAs
IHdyaXRpbmcgMHgxMCkNCihYRU4pIFsyMDE0LTExLTE4IDIxOjUxOjUxLjM1MV0gaW8uYzo1
ODQ6IGQxNjogYmluZDogbV9nc2k9MzcgZ19nc2k9MzYgZGV2PTAwLjAwLjUgaW50eD0wIGZm
ZmY4MzA1MTg2YzU4MjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjUxOjUxLjc1Ml0gQU1ELVZp
OiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDgwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTo1MS43NTJdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ODAwLCB0eXBlID0gMHgxLCByb290IHRhYmxl
ID0gMHg1MDhhYTAwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDE0LTExLTE4IDIxOjUxOjUxLjc1Ml0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowODowMC4w
IGZyb20gZG9tMCB0byBkb20xNg0KWyAgNDA3Ljg5NDAwOV0gcGNpYmFjayAwMDAwOjBhOjAw
LjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4M2MgKHdhcyAweDEwMCwg
d3JpdGluZyAweDEwYSkNClsgIDQwNy45MDE5MDRdIHBjaWJhY2sgMDAwMDowYTowMC4wOiBy
ZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweDEwICh3YXMgMHg0LCB3cml0aW5n
IDB4ZmUyMDAwMDQpDQpbICA0MDcuOTA4NDA5XSBwY2liYWNrIDAwMDA6MGE6MDAuMDogcmVz
dG9yaW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHhjICh3YXMgMHgwLCB3cml0aW5nIDB4
MTApDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MDJdIGlvLmM6NTg0OiBkMTY6IGJp
bmQ6IG1fZ3NpPTQ3IGdfZ3NpPTQwIGRldj0wMC4wMC42IGludHg9MCBmZmZmODMwMzc3MzQ1
MGE4DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MDhdIEFNRC1WaTogRGlzYWJsZTog
ZGV2aWNlIGlkID0gMHhhMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NTE6NTIuODA4XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweGEwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTA4YWEw
MDAwLCBkb21haW4gPSAxNiwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1MTo1Mi44MDhdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMCBmcm9tIGRvbTAg
dG8gZG9tMTYNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUyLjgxOV0gSFZNIExvYWRlcg0K
KGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIuODE5XSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJj
DQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MTldIFhlbmJ1cyByaW5ncyBAMHhmZWZm
YzAwMCwgZXZlbnQgY2hhbm5lbCAxDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MTld
IFN5c3RlbSByZXF1ZXN0ZWQgU2VhQklPUw0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIu
ODE5XSBDUFUgc3BlZWQgaXMgMzIwMCBNSHoNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUy
LjgxOV0gUmVsb2NhdGluZyBndWVzdCBtZW1vcnkgZm9yIGxvd21lbSBNTUlPIHNwYWNlIGRp
c2FibGVkDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MTldIGlycS5jOjI3MDogRG9t
MTYgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6
NTIuODE5XSBQQ0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJRNQ0KKFhFTikgWzIwMTQtMTEt
MTggMjE6NTE6NTIuODIwXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAw
IC0+IDEwDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MjBdIFBDSS1JU0EgbGluayAx
IHJvdXRlZCB0byBJUlExMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTE6NTIuODIwXSBpcnEu
YzoyNzA6IERvbTE2IFBDSSBsaW5rIDIgY2hhbmdlZCAwIC0+IDExDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1Mi44MjBdIFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NTE6NTIuODIwXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5r
IDMgY2hhbmdlZCAwIC0+IDUNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUyLjgyMF0gUENJ
LUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUNClsgIDQwNy45NDgyNThdIHhlbl9wY2liYWNr
OiB2cGNpOiAwMDAwOjA4OjAwLjA6IGFzc2lnbiB0byB2aXJ0dWFsIHNsb3QgMA0KWyAgNDA3
Ljk1NTcyMV0geGVuX3BjaWJhY2s6IHZwY2k6IDAwMDA6MGE6MDAuMDogYXNzaWduIHRvIHZp
cnR1YWwgc2xvdCAxDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MzddIHBjaSBkZXYg
MDE6MiBJTlRELT5JUlE1DQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44NDNdIHBjaSBk
ZXYgMDE6MyBJTlRBLT5JUlExMA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIuODQ4XSBw
Y2kgZGV2IDAyOjAgSU5UQS0+SVJRMTENCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUyLjg1
OF0gcGNpIGRldiAwNDowIElOVEEtPklSUTUNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUy
Ljg2NV0gcGNpIGRldiAwNTowIElOVEEtPklSUTEwDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1
MTo1Mi44NzFdIHBjaSBkZXYgMDY6MCBJTlRBLT5JUlExMQ0KKGQxNikgWzIwMTQtMTEtMTgg
MjE6NTE6NTIuOTE2XSBObyBSQU0gaW4gaGlnaCBtZW1vcnk7IHNldHRpbmcgaGlnaF9tZW0g
cmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDANCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUy
LjkxNl0gcGNpIGRldiAwMzowIGJhciAxMCBzaXplIDAwMjAwMDAwMDogMGYwMDAwMDA4DQoo
ZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi45MThdIHBjaSBkZXYgMDI6MCBiYXIgMTQgc2l6
ZSAwMDEwMDAwMDA6IDBmMjAwMDAwOA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIuOTIx
XSBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMjAwMDAwOiAwZjMwMDAwMDQNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjUxOjUyLjkyMV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1m
MzAwMCBtZm49ZmUyMDAgbnI9MjAwDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi45MjZd
IHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAwNDAwMDA6IDBmMzIwMDAwMA0KKGQxNikg
WzIwMTQtMTEtMTggMjE6NTE6NTIuOTI5XSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAw
MDIwMDAwOiAwZjMyNDAwMDANCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUyLjkyOV0gcGNp
IGRldiAwMzowIGJhciAzMCBzaXplIDAwMDAxMDAwMDogMGYzMjYwMDAwDQooZDE2KSBbMjAx
NC0xMS0xOCAyMTo1MTo1Mi45MzBdIHBjaSBkZXYgMDU6MCBiYXIgMTAgc2l6ZSAwMDAwMDIw
MDA6IDBmMzI3MDAwNA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTE6NTIuOTMwXSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1Mi45MzZdIHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDA6
IDBmMzI3MjAwMA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIuOTM3XSBwY2kgZGV2IDAy
OjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDENCihkMTYpIFsyMDE0LTExLTE4
IDIxOjUxOjUyLjkzOV0gcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDA0MDogMDAw
MDBjMTAxDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi45NDJdIHBjaSBkZXYgMDE6MiBi
YXIgMjAgc2l6ZSAwMDAwMDAwMjA6IDAwMDAwYzE0MQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6
NTE6NTIuOTQ0XSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMx
NjENCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUyLjk0N10gTXVsdGlwcm9jZXNzb3IgaW5p
dGlhbGlzYXRpb246DQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi45NzJdICAtIENQVTAg
Li4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4u
LiBkb25lLg0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIuOTk0XSAgLSBDUFUxIC4uLiA0
OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9u
ZS4NCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjAxM10gIC0gQ1BVMiAuLi4gNDgtYml0
IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuDQoo
ZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4wMzNdICAtIENQVTMgLi4uIDQ4LWJpdCBwaHlz
IC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLg0KKGQxNikg
WzIwMTQtMTEtMTggMjE6NTE6NTMuMDMzXSBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoNCihk
MTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjA0Ml0gIC0gUkVQIElOU0IgYWNyb3NzIHBhZ2Ug
Ym91bmRhcmllcyAuLi4gcGFzc2VkDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4wNDZd
ICAtIEdTIGJhc2UgTVNScyBhbmQgU1dBUEdTIC4uLiBwYXNzZWQNCihkMTYpIFsyMDE0LTEx
LTE4IDIxOjUxOjUzLjA0Nl0gUGFzc2VkIDIgb2YgMiB0ZXN0cw0KKGQxNikgWzIwMTQtMTEt
MTggMjE6NTE6NTMuMDQ2XSBXcml0aW5nIFNNQklPUyB0YWJsZXMgLi4uDQooZDE2KSBbMjAx
NC0xMS0xOCAyMTo1MTo1My4wNDddIExvYWRpbmcgU2VhQklPUyAuLi4NCihkMTYpIFsyMDE0
LTExLTE4IDIxOjUxOjUzLjA0N10gQ3JlYXRpbmcgTVAgdGFibGVzIC4uLg0KKGQxNikgWzIw
MTQtMTEtMTggMjE6NTE6NTMuMDQ4XSBMb2FkaW5nIEFDUEkgLi4uDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1My4wNDldIHZtODYgVFNTIGF0IGZjMDBhMjAwDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1My4wNTBdIEJJT1MgbWFwOg0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6
NTMuMDUwXSAgMTAwMDAtMTAwZDM6IFNjcmF0Y2ggc3BhY2UNCihkMTYpIFsyMDE0LTExLTE4
IDIxOjUxOjUzLjA1MF0gIGMwMDAwLWZmZmZmOiBNYWluIEJJT1MNCihkMTYpIFsyMDE0LTEx
LTE4IDIxOjUxOjUzLjA1MF0gRTgyMCB0YWJsZToNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUx
OjUzLjA1MF0gIFswMF06IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6
IFJBTQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMDUwXSAgSE9MRTogMDAwMDAwMDA6
MDAwYTAwMDAgLSAwMDAwMDAwMDowMDBjMDAwMA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6
NTMuMDUwXSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDog
UkVTRVJWRUQNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjA1MF0gIFswMl06IDAwMDAw
MDAwOjAwMTAwMDAwIC0gMDAwMDAwMDA6M2Y4MDAwMDA6IFJBTQ0KKGQxNikgWzIwMTQtMTEt
MTggMjE6NTE6NTMuMDUwXSAgSE9MRTogMDAwMDAwMDA6M2Y4MDAwMDAgLSAwMDAwMDAwMDpm
YzAwMDAwMA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMDUwXSAgWzAzXTogMDAwMDAw
MDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQNCihkMTYpIFsyMDE0
LTExLTE4IDIxOjUxOjUzLjA1MF0gSW52b2tpbmcgU2VhQklPUyAuLi4NCihkMTYpIFsyMDE0
LTExLTE4IDIxOjUxOjUzLjA1M10gU2VhQklPUyAodmVyc2lvbiByZWwtMS43LjUtMC1nZTUx
NDg4Yy0yMDE0MTExOF8yMjMwNDMtc2VydmVlcnN0ZXJ0amUpDQooZDE2KSBbMjAxNC0xMS0x
OCAyMTo1MTo1My4wNTNdIA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMDUzXSBGb3Vu
ZCBYZW4gaHlwZXJ2aXNvciBzaWduYXR1cmUgYXQgNDAwMDAwMDANCihkMTYpIFsyMDE0LTEx
LTE4IDIxOjUxOjUzLjA1M10gUnVubmluZyBvbiBRRU1VIChpNDQwZngpDQooZDE2KSBbMjAx
NC0xMS0xOCAyMTo1MTo1My4wNTNdIHhlbjogY29weSBlODIwLi4uDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1My4wNTNdIFJlbG9jYXRpbmcgaW5pdCBmcm9tIDB4MDAwZGY2MjkgdG8g
MHgzZjdhZTYwMCAoc2l6ZSA3MTk5NSkNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjA1
Nl0gQ1BVIE1oej0zMjAxDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4wNjFdIEZvdW5k
IDEwIFBDSSBkZXZpY2VzIChtYXggUENJIGJ1cyBpcyAwMCkNCihkMTYpIFsyMDE0LTExLTE4
IDIxOjUxOjUzLjA2MV0gQWxsb2NhdGVkIFhlbiBoeXBlcmNhbGwgcGFnZSBhdCAzZjdmZjAw
MA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMDYxXSBEZXRlY3RlZCBYZW4gdjQuNS4w
LXJjDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4wNjFdIHhlbjogY29weSBCSU9TIHRh
Ymxlcy4uLg0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMDYxXSBDb3B5aW5nIFNNQklP
UyBlbnRyeSBwb2ludCBmcm9tIDB4MDAwMTAwMTAgdG8gMHgwMDBmMGY1MA0KKGQxNikgWzIw
MTQtMTEtMTggMjE6NTE6NTMuMDYxXSBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMWEw
L2ZjMDAxMWIwIHRvIDB4MDAwZjBlMzANCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjA2
MV0gQ29weWluZyBQSVIgZnJvbSAweDAwMDEwMDMwIHRvIDB4MDAwZjBkYjANCihkMTYpIFsy
MDE0LTExLTE4IDIxOjUxOjUzLjA2MV0gQ29weWluZyBBQ1BJIFJTRFAgZnJvbSAweDAwMDEw
MGIwIHRvIDB4MDAwZjBkODANCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjA2Ml0gVXNp
bmcgcG10aW1lciwgaW9wb3J0IDB4YjAwOA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMu
MDYyXSBTY2FuIGZvciBWR0Egb3B0aW9uIHJvbQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6
NTMuMDc5XSBSdW5uaW5nIG9wdGlvbiByb20gYXQgYzAwMDowMDAzDQooWEVOKSBbMjAxNC0x
MS0xOCAyMTo1MTo1My4wODhdIHN0ZHZnYS5jOjE0NzpkMTZ2MCBlbnRlcmluZyBzdGR2Z2Eg
YW5kIGNhY2hpbmcgbW9kZXMNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjExNV0gcG1t
IGNhbGwgYXJnMT0wDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4xMTZdIFR1cm5pbmcg
b24gdmdhIHRleHQgbW9kZSBjb25zb2xlDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4y
MzRdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMThfMjIz
MDQzLXNlcnZlZXJzdGVydGplKQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMjQ4XSBN
YWNoaW5lIFVVSUQgYzM5YTYwNzktMDUzNi00NDJmLWE2YjUtZjhkMzAzNjk3YzFhDQooZDE2
KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNDhdIFhIQ0kgaW5pdCBvbiBkZXYgMDA6MDUuMDog
cmVncyBAIDB4ZjMyNzAwMDAsIDQgcG9ydHMsIDMyIHNsb3RzLCAzMiBieXRlIGNvbnRleHQN
CihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjI0OF0gcw0KKGQxNikgWzIwMTQtMTEtMTgg
MjE6NTE6NTMuMjQ4XSBYSENJICAgIGV4dGNhcCAweDEgQCBmMzI3MDUwMA0KKGQxNikgWzIw
MTQtMTEtMTggMjE6NTE6NTMuMjQ4XSBYSENJICAgIHByb3RvY29sIFVTQiAgMy4wMCwgMiBw
b3J0cyAob2Zmc2V0IDEpLCBkZWYgMA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMjQ4
XSBYSENJICAgIHByb3RvY29sIFVTQiAgMi4wMCwgMiBwb3J0cyAob2Zmc2V0IDMpLCBkZWYg
MA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMjQ5XSBVSENJIGluaXQgb24gZGV2IDAw
OjAxLjIgKGlvPWMxNDApDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNTBdIEZvdW5k
IDAgbHB0IHBvcnRzDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNTFdIEZvdW5kIDEg
c2VyaWFsIHBvcnRzDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNTJdIEFUQSBjb250
cm9sbGVyIDEgYXQgMWYwLzNmNC8wIChpcnEgMTQgZGV2IDkpDQooZDE2KSBbMjAxNC0xMS0x
OCAyMTo1MTo1My4yNTNdIEFUQSBjb250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUg
ZGV2IDkpDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNTZdIGF0YTAtMDogUUVNVSBI
QVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDEwMjQwIE1pQnl0ZXMpDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1My4yNTZdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4
LypAMSwxL2RyaXZlQDAvZGlza0AwDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNThd
IGF0YTAtMTogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDMwMCBHaUJ5dGVzKQ0K
KGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMjU4XSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZv
cjogL3BjaUBpMGNmOC8qQDEsMS9kcml2ZUAwL2Rpc2tAMQ0KKGQxNikgWzIwMTQtMTEtMTgg
MjE6NTE6NTMuMzU2XSBQUzIga2V5Ym9hcmQgaW5pdGlhbGl6ZWQNCihkMTYpIFsyMDE0LTEx
LTE4IDIxOjUxOjUzLjQwMV0gWEhDSSBwb3J0ICM0OiAweDAwMjAwYTAzLCBwb3dlcmVkLCBl
bmFibGVkLCBwbHMgMCwgc3BlZWQgMiBbTG93XQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6
NTMuNDMxXSBYSENJIG5vIGRldmljZXMgZm91bmQNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUx
OjUzLjQ0Ml0gQWxsIHRocmVhZHMgY29tcGxldGUuDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1
MTo1My40NDJdIFNjYW4gZm9yIG9wdGlvbiByb21zDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1
MTo1My40NjhdIFJ1bm5pbmcgb3B0aW9uIHJvbSBhdCBjOTgwOjAwMDMNCihkMTYpIFsyMDE0
LTExLTE4IDIxOjUxOjUzLjQ3NV0gcG1tIGNhbGwgYXJnMT0xDQooZDE2KSBbMjAxNC0xMS0x
OCAyMTo1MTo1My40NzZdIHBtbSBjYWxsIGFyZzE9MA0KKGQxNikgWzIwMTQtMTEtMTggMjE6
NTE6NTMuNDc3XSBwbW0gY2FsbCBhcmcxPTENCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUz
LjQ3OF0gcG1tIGNhbGwgYXJnMT0wDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My40OTRd
IFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4LypANA0KKGQxNikgWzIwMTQt
MTEtMTggMjE6NTE6NTMuNDk0XSANCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjUwMV0g
UHJlc3MgRjEyIGZvciBib290IG1lbnUuDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My41
MDJdIA0KWyAgNDA5LjYwMTI3N10geGVuX2JyaWRnZTogcG9ydCAxNCh2aWYxNC4wKSBlbnRl
cmVkIGZvcndhcmRpbmcgc3RhdGUNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjU2LjA0N10g
U2VhcmNoaW5nIGJvb3RvcmRlciBmb3I6IEhBTFQNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUx
OjU2LjA0N10gZHJpdmUgMHgwMDBmMGQzMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlv
bj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwDQooZDE2KSBbMjAxNC0xMS0xOCAy
MTo1MTo1Ni4wNDddIGRyaXZlIDB4MDAwZjBkMDA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNs
YXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMgcz02MjkxNDU2MDANCihkMTYpIFsyMDE0LTEx
LTE4IDIxOjUxOjU2LjA0N10gDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Ni4wNDddIFNw
YWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkMDANCihkMTYp
IFsyMDE0LTExLTE4IDIxOjUxOjU2LjA0N10gUmV0dXJuZWQgMjUzOTUyIGJ5dGVzIG9mIFpv
bmVIaWdoDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Ni4wNDddIGU4MjAgbWFwIGhhcyA2
IGl0ZW1zOg0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTYuMDQ3XSAgIDA6IDAwMDAwMDAw
MDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0NCihkMTYpIFsyMDE0LTExLTE4
IDIxOjUxOjU2LjA0N10gICAxOiAwMDAwMDAwMDAwMDlmYzAwIC0gMDAwMDAwMDAwMDBhMDAw
MCA9IDIgUkVTRVJWRUQNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjU2LjA0N10gICAyOiAw
MDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCA9IDIgUkVTRVJWRUQNCihkMTYp
IFsyMDE0LTExLTE4IDIxOjUxOjU2LjA0N10gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAw
MDAwMDAzZjdmZTAwMCA9IDEgUkFNDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Ni4wNDdd
ICAgNDogMDAwMDAwMDAzZjdmZTAwMCAtIDAwMDAwMDAwM2Y4MDAwMDAgPSAyIFJFU0VSVkVE
DQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Ni4wNDddICAgNTogMDAwMDAwMDBmYzAwMDAw
MCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJFU0VSVkVEDQooZDE2KSBbMjAxNC0xMS0xOCAy
MTo1MTo1Ni4wNDhdIGVudGVyIGhhbmRsZV8xOToNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUx
OjU2LjA0OF0gICBOVUxMDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Ni4wNTRdIEJvb3Rp
bmcgZnJvbSBIYXJkIERpc2suLi4NCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjU2LjA1N10g
Qm9vdGluZyBmcm9tIDAwMDA6N2MwMA0KWyAgNDE0LjkyNTU3Nl0gZGV2aWNlIHZpZjE3LjAg
ZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQpbICA0MTUuMDkzMDYwXSBkZXZpY2UgdmlmMTcu
MC1lbXUgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQpbICA0MTUuMTAzMjYzXSB4ZW5fYnJp
ZGdlOiBwb3J0IDE4KHZpZjE3LjAtZW11KSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsg
IDQxNS4xMDk3OTJdIHhlbl9icmlkZ2U6IHBvcnQgMTgodmlmMTcuMC1lbXUpIGVudGVyZWQg
Zm9yd2FyZGluZyBzdGF0ZQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMDUxXSBIVk0g
TG9hZGVyDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4wNTFdIERldGVjdGVkIFhlbiB2
NC41LjAtcmMNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjA1MV0gWGVuYnVzIHJpbmdz
IEAweGZlZmZjMDAwLCBldmVudCBjaGFubmVsIDENCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjA1MV0gU3lzdGVtIHJlcXVlc3RlZCBTZWFCSU9TDQooZDE3KSBbMjAxNC0xMS0xOCAy
MTo1MjowMC4wNTFdIENQVSBzcGVlZCBpcyAzMjAwIE1Ieg0KKGQxNykgWzIwMTQtMTEtMTgg
MjE6NTI6MDAuMDUxXSBSZWxvY2F0aW5nIGd1ZXN0IG1lbW9yeSBmb3IgbG93bWVtIE1NSU8g
c3BhY2UgZGlzYWJsZWQNCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjAwLjA1Ml0gaXJxLmM6
MjcwOiBEb20xNyBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1DQooZDE3KSBbMjAxNC0xMS0x
OCAyMTo1MjowMC4wNTJdIFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1DQooWEVOKSBb
MjAxNC0xMS0xOCAyMTo1MjowMC4wNTJdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMSBj
aGFuZ2VkIDAgLT4gMTANCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjA1Ml0gUENJLUlT
QSBsaW5rIDEgcm91dGVkIHRvIElSUTEwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjowMC4w
NTJdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihkMTcp
IFsyMDE0LTExLTE4IDIxOjUyOjAwLjA1Ml0gUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElS
UTExDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjowMC4wNTJdIGlycS5jOjI3MDogRG9tMTcg
UENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAu
MDUyXSBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQ0KKGQxNykgWzIwMTQtMTEtMTgg
MjE6NTI6MDAuMDcxXSBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTANCihkMTcpIFsyMDE0LTEx
LTE4IDIxOjUyOjAwLjA3NV0gcGNpIGRldiAwMjowIElOVEEtPklSUTExDQooZDE3KSBbMjAx
NC0xMS0xOCAyMTo1MjowMC4wODZdIHBjaSBkZXYgMDQ6MCBJTlRBLT5JUlE1DQooZDE3KSBb
MjAxNC0xMS0xOCAyMTo1MjowMC4xNDVdIE5vIFJBTSBpbiBoaWdoIG1lbW9yeTsgc2V0dGlu
ZyBoaWdoX21lbSByZXNvdXJjZSBiYXNlIHRvIDEwMDAwMDAwMA0KKGQxNykgWzIwMTQtMTEt
MTggMjE6NTI6MDAuMTQ1XSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAyMDAwMDAwOiAw
ZjAwMDAwMDgNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjE0N10gcGNpIGRldiAwMjow
IGJhciAxNCBzaXplIDAwMTAwMDAwMDogMGYyMDAwMDA4DQooZDE3KSBbMjAxNC0xMS0xOCAy
MTo1MjowMC4xNDldIHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAwNDAwMDA6IDBmMzAw
MDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMTUxXSBwY2kgZGV2IDA0OjAgYmFy
IDEwIHNpemUgMDAwMDIwMDAwOiAwZjMwNDAwMDANCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjE1MV0gcGNpIGRldiAwMzowIGJhciAzMCBzaXplIDAwMDAxMDAwMDogMGYzMDYwMDAw
DQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4xNTRdIHBjaSBkZXYgMDM6MCBiYXIgMTQg
c2l6ZSAwMDAwMDEwMDA6IDBmMzA3MDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAu
MTU0XSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDENCihk
MTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjE1Nl0gcGNpIGRldiAwNDowIGJhciAxNCBzaXpl
IDAwMDAwMDA0MDogMDAwMDBjMTAxDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4xNThd
IHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAwMTA6IDAwMDAwYzE0MQ0KKGQxNykg
WzIwMTQtMTEtMTggMjE6NTI6MDAuMTYwXSBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlv
bjoNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjE4Ml0gIC0gQ1BVMCAuLi4gNDgtYml0
IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuDQoo
ZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yMDJdICAtIENQVTEgLi4uIDQ4LWJpdCBwaHlz
IC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLg0KKGQxNykg
WzIwMTQtMTEtMTggMjE6NTI6MDAuMjIwXSAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4g
Zml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4NCihkMTcpIFsyMDE0
LTExLTE4IDIxOjUyOjAwLjI0MV0gIC0gQ1BVMyAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVk
IE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuDQooZDE3KSBbMjAxNC0xMS0x
OCAyMTo1MjowMC4yNDFdIFRlc3RpbmcgSFZNIGVudmlyb25tZW50Og0KKGQxNykgWzIwMTQt
MTEtMTggMjE6NTI6MDAuMjUwXSAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVz
IC4uLiBwYXNzZWQNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjI1NF0gIC0gR1MgYmFz
ZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBhc3NlZA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6
MDAuMjU0XSBQYXNzZWQgMiBvZiAyIHRlc3RzDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1Mjow
MC4yNTRdIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDIx
OjUyOjAwLjI1Nl0gTG9hZGluZyBTZWFCSU9TIC4uLg0KKGQxNykgWzIwMTQtMTEtMTggMjE6
NTI6MDAuMjU2XSBDcmVhdGluZyBNUCB0YWJsZXMgLi4uDQooZDE3KSBbMjAxNC0xMS0xOCAy
MTo1MjowMC4yNTZdIExvYWRpbmcgQUNQSSAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjI1N10gdm04NiBUU1MgYXQgZmMwMGEyMDANCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjI1OF0gQklPUyBtYXA6DQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNThdICAx
MDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAu
MjU4XSAgYzAwMDAtZmZmZmY6IE1haW4gQklPUw0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6
MDAuMjU4XSBFODIwIHRhYmxlOg0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMjU4XSAg
WzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkFNDQooZDE3
KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNThdICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAt
IDAwMDAwMDAwOjAwMGMwMDAwDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNThdICBb
MDFdOiAwMDAwMDAwMDowMDBjMDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBSRVNFUlZFRA0K
KGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMjU4XSAgWzAyXTogMDAwMDAwMDA6MDAxMDAw
MDAgLSAwMDAwMDAwMDozZjgwMDAwMDogUkFNDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1Mjow
MC4yNThdICBIT0xFOiAwMDAwMDAwMDozZjgwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwDQoo
ZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNThdICBbMDNdOiAwMDAwMDAwMDpmYzAwMDAw
MCAtIDAwMDAwMDAxOjAwMDAwMDAwOiBSRVNFUlZFRA0KKGQxNykgWzIwMTQtMTEtMTggMjE6
NTI6MDAuMjU4XSBJbnZva2luZyBTZWFCSU9TIC4uLg0KKGQxNykgWzIwMTQtMTEtMTggMjE6
NTI6MDAuMjYxXSBTZWFCSU9TICh2ZXJzaW9uIHJlbC0xLjcuNS0wLWdlNTE0ODhjLTIwMTQx
MTE4XzIyMzA0My1zZXJ2ZWVyc3RlcnRqZSkNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAw
LjI2MV0gDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNjFdIEZvdW5kIFhlbiBoeXBl
cnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6
MDAuMjYxXSBSdW5uaW5nIG9uIFFFTVUgKGk0NDBmeCkNCihkMTcpIFsyMDE0LTExLTE4IDIx
OjUyOjAwLjI2MV0geGVuOiBjb3B5IGU4MjAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjI2MV0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZjYyOSB0byAweDNmN2FlNjAw
IChzaXplIDcxOTk1KQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMjY0XSBDUFUgTWh6
PTMyMDENCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjI2OF0gRm91bmQgNyBQQ0kgZGV2
aWNlcyAobWF4IFBDSSBidXMgaXMgMDApDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4y
NjhdIEFsbG9jYXRlZCBYZW4gaHlwZXJjYWxsIHBhZ2UgYXQgM2Y3ZmYwMDANCihkMTcpIFsy
MDE0LTExLTE4IDIxOjUyOjAwLjI2OF0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYw0KKGQxNykg
WzIwMTQtMTEtMTggMjE6NTI6MDAuMjY4XSB4ZW46IGNvcHkgQklPUyB0YWJsZXMuLi4NCihk
MTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjI2OF0gQ29weWluZyBTTUJJT1MgZW50cnkgcG9p
bnQgZnJvbSAweDAwMDEwMDEwIHRvIDB4MDAwZjBmNTANCihkMTcpIFsyMDE0LTExLTE4IDIx
OjUyOjAwLjI2OF0gQ29weWluZyBNUFRBQkxFIGZyb20gMHhmYzAwMTFhMC9mYzAwMTFiMCB0
byAweDAwMGYwZTMwDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNjhdIENvcHlpbmcg
UElSIGZyb20gMHgwMDAxMDAzMCB0byAweDAwMGYwZGIwDQooZDE3KSBbMjAxNC0xMS0xOCAy
MTo1MjowMC4yNjhdIENvcHlpbmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAw
MGYwZDgwDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNjhdIFVzaW5nIHBtdGltZXIs
IGlvcG9ydCAweGIwMDgNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjI2OF0gU2NhbiBm
b3IgVkdBIG9wdGlvbiByb20NCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjI4NF0gUnVu
bmluZyBvcHRpb24gcm9tIGF0IGMwMDA6MDAwMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6
MDAuMjkyXSBzdGR2Z2EuYzoxNDc6ZDE3djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5n
IG1vZGVzDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4zMTFdIHBtbSBjYWxsIGFyZzE9
MA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMzEyXSBUdXJuaW5nIG9uIHZnYSB0ZXh0
IG1vZGUgY29uc29sZQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNDI4XSBTZWFCSU9T
ICh2ZXJzaW9uIHJlbC0xLjcuNS0wLWdlNTE0ODhjLTIwMTQxMTE4XzIyMzA0My1zZXJ2ZWVy
c3RlcnRqZSkNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjQ0MF0gTWFjaGluZSBVVUlE
IGJmYmFmM2NjLTVmNDgtNDBkNS1hNWY5LTNiOTg4ZGY2YzExNA0KKGQxNykgWzIwMTQtMTEt
MTggMjE6NTI6MDAuNDQxXSBBbGwgdGhyZWFkcyBjb21wbGV0ZS4NCihkMTcpIFsyMDE0LTEx
LTE4IDIxOjUyOjAwLjQ0Ml0gRm91bmQgMCBscHQgcG9ydHMNCihkMTcpIFsyMDE0LTExLTE4
IDIxOjUyOjAwLjQ0Ml0gRm91bmQgMCBzZXJpYWwgcG9ydHMNCihkMTcpIFsyMDE0LTExLTE4
IDIxOjUyOjAwLjQ0Ml0gQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0LzAgKGlycSAxNCBk
ZXYgOSkNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjQ0M10gQVRBIGNvbnRyb2xsZXIg
MiBhdCAxNzAvMzc0LzAgKGlycSAxNSBkZXYgOSkNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjQ0OF0gYXRhMC0wOiBRRU1VIEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAoMTAyNDAg
TWlCeXRlcykNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjQ0OF0gU2VhcmNoaW5nIGJv
b3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDANClsgIDQxNS42
MzA5MTFdIHZwbl9icmlkZ2U6IHBvcnQgMSh2aWYxNS4wKSBlbnRlcmVkIGZvcndhcmRpbmcg
c3RhdGUNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjU0NV0gUFMyIGtleWJvYXJkIGlu
aXRpYWxpemVkDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC41NDVdIEFsbCB0aHJlYWRz
IGNvbXBsZXRlLg0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNTQ1XSBTY2FuIGZvciBv
cHRpb24gcm9tcw0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNTY1XSBSdW5uaW5nIG9w
dGlvbiByb20gYXQgYzk4MDowMDAzDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC41NzFd
IHBtbSBjYWxsIGFyZzE9MQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNTcxXSBwbW0g
Y2FsbCBhcmcxPTANCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjU3M10gcG1tIGNhbGwg
YXJnMT0xDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC41NzNdIHBtbSBjYWxsIGFyZzE9
MA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNTg5XSBTZWFyY2hpbmcgYm9vdG9yZGVy
IGZvcjogL3BjaUBpMGNmOC8qQDQNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjU4OV0g
DQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC41OTVdIFByZXNzIEYxMiBmb3IgYm9vdCBt
ZW51Lg0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNTk2XSANCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjUyOjAxLjg2MV0gc3RkdmdhLmM6MTUxOmQxNnYwIGxlYXZpbmcgc3RkdmdhDQoo
ZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMy4xMzJdIFNlYXJjaGluZyBib290b3JkZXIgZm9y
OiBIQUxUDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMy4xMzJdIGRyaXZlIDB4MDAwZjBk
MzA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMg
cz0yMDk3MTUyMA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDMuMTMyXSBTcGFjZSBhdmFp
bGFibGUgZm9yIFVNQjogY2E4MDAtZWYwMDAsIGYwMDAwLWYwZDMwDQooZDE3KSBbMjAxNC0x
MS0xOCAyMTo1MjowMy4xMzJdIFJldHVybmVkIDI1ODA0OCBieXRlcyBvZiBab25lSGlnaA0K
KGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDMuMTMyXSBlODIwIG1hcCBoYXMgNiBpdGVtczoN
CihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAzLjEzMl0gICAwOiAwMDAwMDAwMDAwMDAwMDAw
IC0gMDAwMDAwMDAwMDA5ZmMwMCA9IDEgUkFNDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1Mjow
My4xMzJdICAgMTogMDAwMDAwMDAwMDA5ZmMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgPSAyIFJF
U0VSVkVEDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMy4xMzJdICAgMjogMDAwMDAwMDAw
MDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgPSAyIFJFU0VSVkVEDQooZDE3KSBbMjAxNC0x
MS0xOCAyMTo1MjowMy4xMzJdICAgMzogMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwM2Y3
ZmYwMDAgPSAxIFJBTQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDMuMTMyXSAgIDQ6IDAw
MDAwMDAwM2Y3ZmYwMDAgLSAwMDAwMDAwMDNmODAwMDAwID0gMiBSRVNFUlZFRA0KKGQxNykg
WzIwMTQtMTEtMTggMjE6NTI6MDMuMTMyXSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAgLSAwMDAw
MDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDMu
MTMzXSBlbnRlciBoYW5kbGVfMTk6DQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMy4xMzNd
ICAgTlVMTA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDMuMTM5XSBCb290aW5nIGZyb20g
SGFyZCBEaXNrLi4uDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMy4xNDFdIEJvb3Rpbmcg
ZnJvbSAwMDAwOjdjMDANClsgIDQyMC4zNzk5NjldIHhlbl9icmlkZ2U6IHBvcnQgMTYodmlm
MTYuMC1lbXUpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KKFhFTikgWzIwMTQtMTEtMTgg
MjE6NTI6MTMuMDU5XSBzdGR2Z2EuYzoxNTE6ZDE3djAgbGVhdmluZyBzdGR2Z2ENClsgIDQz
MC4xNDQ5NTZdIHhlbl9icmlkZ2U6IHBvcnQgMTgodmlmMTcuMC1lbXUpIGVudGVyZWQgZm9y
d2FyZGluZyBzdGF0ZQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MjcuNDM0XSBzdGR2Z2Eu
YzoxNDc6ZDE2djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzDQooWEVOKSBb
MjAxNC0xMS0xOCAyMTo1MjoyOS4wMjNdIGlycS5jOjM4MDogRG9tMTYgY2FsbGJhY2sgdmlh
IGNoYW5nZWQgdG8gRGlyZWN0IFZlY3RvciAweGYzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1
MjozNS4zMjldIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZl
IG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM1LjMzNF0gbWVtb3J5X21hcDphZGQ6
IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NTI6MzUuMzM4XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBm
ZSBucj0xDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS4zNDJdIG1lbW9yeV9tYXA6YWRk
OiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDIx
OjUyOjM1LjM0N10gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUw
ZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzUuMzUyXSBtZW1vcnlfbWFwOmFk
ZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1MjozNS4zNTVdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZl
MGZlIG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM1LjM1OV0gbWVtb3J5X21hcDph
ZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTgg
MjE6NTI6MzUuMzY0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1m
ZTBmZSBucj0xDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS4zNjldIG1lbW9yeV9tYXA6
YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTENCihYRU4pIFsyMDE0LTExLTE4
IDIxOjUyOjM1LjM3NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49
ZmUwZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzUuMzgwXSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1MjozNS4zOTNdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMDAgbWZu
PWZlMjAwIG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzUuNDAxXSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDANCihYRU4pIFsyMDE0
LTExLTE4IDIxOjUyOjM1LjQwN10gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAw
MCBtZm49ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS40MTRdIG1l
bW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMA0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NTI6MzUuNDIwXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2Zu
PWYzMDAwIG1mbj1mZTIwMCBucj0yMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM1LjQy
Nl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwDQoo
WEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS40MzNdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20x
NiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6
MzUuNDM5XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0y
MDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM1LjQ0NV0gbWVtb3J5X21hcDpyZW1vdmU6
IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1MjozNS40NTJdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAw
IG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzUuNDU4XSBtZW1vcnlfbWFwOnJl
bW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDANCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjUyOjM1LjQ2NV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBtZm49
ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS41MDFdIGlycS5jOjI3
MDogRG9tMTYgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMA0KKFhFTikgWzIwMTQtMTEtMTgg
MjE6NTI6MzUuNTI1XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAt
PiAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS41NDVdIGlycS5jOjI3MDogRG9tMTYg
UENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM1
LjU2Nl0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwDQooWEVO
KSBbMjAxNC0xMS0xOCAyMTo1MjozNy4xMjddIHN0ZHZnYS5jOjE0NzpkMTd2MCBlbnRlcmlu
ZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMNClsgIDQ1Mi4zMTYwODJdIHhlbi1ibGtiYWNr
OnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMzIsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkp
IHBlcnNpc3RlbnQgZ3JhbnRzDQpbICA0NTIuMzMwMDc1XSB4ZW4tYmxrYmFjazpyaW5nLXJl
ZiA5LCBldmVudC1jaGFubmVsIDMzLCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0
ZW50IGdyYW50cw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzcuNDYyXSBncmFudF90YWJs
ZS5jOjEyOTk6ZDE2djEgRXhwYW5kaW5nIGRvbSAoMTYpIGdyYW50IHRhYmxlIGZyb20gKDQp
IHRvICg1KSBmcmFtZXMuDQpbICA0NTIuNjAyMzk2XSB2aWYgdmlmLTE2LTAgdmlmMTYuMDog
R3Vlc3QgUnggcmVhZHkNClsgIDQ1Mi42MDg3NTVdIHhlbl9icmlkZ2U6IHBvcnQgMTUodmlm
MTYuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICA0NTIuNjE1MDQ1XSB4ZW5fYnJp
ZGdlOiBwb3J0IDE1KHZpZjE2LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NTI6MzguODkyXSBpcnEuYzozODA6IERvbTE3IGNhbGxiYWNrIHZp
YSBjaGFuZ2VkIHRvIERpcmVjdCBWZWN0b3IgMHhmMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NTI6MzkuOTY0XSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDAN
CihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM5Ljk3MF0gaXJxLmM6MjcwOiBEb20xNyBQQ0kg
bGluayAxIGNoYW5nZWQgMTAgLT4gMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzkuOTc2
XSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwDQooWEVOKSBb
MjAxNC0xMS0xOCAyMTo1MjozOS45ODJdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMyBj
aGFuZ2VkIDUgLT4gMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6NDAuNTAzXSBncmFudF90
YWJsZS5jOjEyOTk6ZDE3djEgRXhwYW5kaW5nIGRvbSAoMTcpIGdyYW50IHRhYmxlIGZyb20g
KDQpIHRvICg1KSBmcmFtZXMuDQpbICA0NTUuNjQxMDU2XSB4ZW4tYmxrYmFjazpyaW5nLXJl
ZiA5LCBldmVudC1jaGFubmVsIDMzLCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0
ZW50IGdyYW50cw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6NDAuNTM2XSBncmFudF90YWJs
ZS5jOjMwNTpkMHY0IEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDcgZnJhbWVzDQpbICA0
NTUuNjYzNTU3XSB2aWYgdmlmLTE3LTAgdmlmMTcuMDogR3Vlc3QgUnggcmVhZHkNClsgIDQ1
NS42NzAxNDVdIHhlbl9icmlkZ2U6IHBvcnQgMTcodmlmMTcuMCkgZW50ZXJlZCBmb3J3YXJk
aW5nIHN0YXRlDQpbICA0NTUuNjc2NjQ5XSB4ZW5fYnJpZGdlOiBwb3J0IDE3KHZpZjE3LjAp
IGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgNDY3LjY1NzEyOF0geGVuX2JyaWRnZTog
cG9ydCAxNSh2aWYxNi4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDQ3MC42OTg3
NzddIHhlbl9icmlkZ2U6IHBvcnQgMTcodmlmMTcuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0
YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1Mjo1OC40MDldIGdyYW50X3RhYmxlLmM6MzA1
OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gOCBmcmFtZXMNCihYRU4pIFsyMDE0
LTExLTE4IDIxOjU1OjQxLjU5MV0gLS0tLVsgWGVuLTQuNS4wLXJjICB4ODZfNjQgIGRlYnVn
PXkgIE5vdCB0YWludGVkIF0tLS0tDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFd
IENQVTogICAgMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAtLS0tWyBYZW4t
NC41LjAtcmMgIHg4Nl82NCAgZGVidWc9eSAgTm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIFsy
MDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gUklQOiAgICBlMDA4Ols8ZmZmZjgyZDA4MDEyYzdl
Nz5dQ1BVOiAgICAyDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdIFJJUDogICAg
ZTAwODpbPGZmZmY4MmQwODAxNGE0NjE+XSBodm1fZG9fSVJRX2RwY2krMHhiZC8weDEzYw0K
KFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSBSRkxBR1M6IDAwMDAwMDAwMDAwMTAw
MDYgICAgX3NwaW5fdW5sb2NrKzB4MWYvMHgzMENPTlRFWFQ6IGh5cGVydmlzb3INCihYRU4p
IFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0
MS41OTFdIFJGTEFHUzogMDAwMDAwMDAwMDAxMDI0NiAgIHJheDogMDAwMDAwMDAwMDAwMDAw
MCAgIHJieDogZmZmZjgzMDM3NzM0NTBhOCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwMQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSBDT05URVhUOiBoeXBlcnZpc29yDQooWEVO
KSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdIHJkeDogMDAwMDAwMDAwMDAwMDAwMCAgIHJz
aTogZmZmZjgzMDU0ZWY0ZWY5OCAgIHJkaTogMDAwMDAwMDAxMmFhNTQwMA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NTU6NDEuNTkxXSByYXg6IGZmZmY4MmQwODAzMjhkYTAgICByYng6IGZm
ZmY4MzA1MTg2YzVkODAgICByY3g6IDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjU1OjQxLjU5MV0gcmJwOiBmZmZmODMwNTRlZjQ3Yzg4ICAgcnNwOiBmZmZmODMw
NTRlZjQ3Yzc4ICAgcjg6ICBmZmZmODMwNTE4NmM1OGQwDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1NTo0MS41OTFdIHI5OiAgMDAwMDAwMDAwMDAwMDAyZiAgIHIxMDogMDAwMDAwMDAwMDAw
MDBkMCAgIHIxMTogZmZmZmZmZmY4MjkwODRiMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6
NDEuNTkxXSByZHg6IGZmZmY4MmQwODAyZTAwMDAgICByc2k6IGZmZmY4MzA1MGFlYWQyYTgg
ICByZGk6IDAwMDAwMDAwMDAwMDAwYjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5
MV0gcmJwOiBmZmZmODJkMDgwMmU3ZGY4ICAgcnNwOiBmZmZmODJkMDgwMmU3ZGY4ICAgcjg6
ICBmZmZmODJkMDgwMmU3ZDI4DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdIHI5
OiAgMDAwMDAwMDAwMDAwMDA0MCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogZmZm
ZmZmZmZmZmZmZmZjMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSByMTI6IGZm
ZmY4MzA1MTg2YzVkODAgICByMTM6IGZmZmY4MzAzNzczNDUwYTggICByMTQ6IGZmZmY4MzAz
NzczNDUwYjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gcjE1OiBmZmZmODMw
NTE4NmM1YjAwICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAw
NmYwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdIHIxMjogZmZmZjgzMDUxNWI1
YjAwMCAgIHIxMzogMDAwMDAwMDAwMDAwMDAwMCAgIHIxNDogZmZmZjgzMDM3NzM0NTA4MA0K
KFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSBjcjM6IDAwMDAwMDA1NGEyMTUwMDAg
ICBjcjI6IDAwMDAwMDAwMDAwMDAwYjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5
MV0gcjE1OiAwMDAwMDAwMDAwMDAwMDJmICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0
OiAwMDAwMDAwMDAwMDAwNmYwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdIGRz
OiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IDAwMDAgICBj
czogZTAwOA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSBjcjM6IDAwMDAwMDA1
NGEyMTUwMDAgICBjcjI6IDAwMDAwMDAwMDAwMDAxNjANCihYRU4pIFsyMDE0LTExLTE4IDIx
OjU1OjQxLjU5MV0gZHM6IDAwMDAgICBlczogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAwMDAg
ICBzczogMDAwMCAgIGNzOiBlMDA4DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFd
IFhlbiBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmODJkMDgwMmU3ZGY4Og0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODJkMDgwMmU3ZTQ4WGVuIHN0YWNrIHRy
YWNlIGZyb20gcnNwPWZmZmY4MzA1NGVmNDdjNzg6DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1
NTo0MS41OTFdICAgIGZmZmY4MmQwODAxNGEzOTUgZmZmZjgzMDA5ZmQyZDA2MCBmZmZmODMw
NTRlZjQ3Yzg4IGZmZmY4MzAzNzczNDUwYjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQx
LjU5MV0gICAgZmZmZmM5MDAxNDFmMmIyMCBmZmZmODJkMDgwMzI4ZjgwIGZmZmY4MzAzNzcz
NDUxNDAgZmZmZjgyZDA4MDE0YTI2ZSBmZmZmODMwMzc3MzQ1MGE4IGZmZmY4MzA1NGVmNDdk
MTgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgZmZmZjgyZDA4MDE3MjA2
MCAwMDAwMDA5NDNmNDNlNTE4IGZmZmY4ODAwMmIyMjdlMTggZmZmZjgyZDA4MDJlN2U3OA0K
KFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODJkMDgwMTJmMmMzIDAw
MDAwMDAwMDAwMDAyODYNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgMDAw
MDAwMDEwMDAwMDAzMSBmZmZmODJkMDgwMThiMjBmIGZmZmY4MmQwODAzMjhmODAgZmZmZjgz
MDUwYjBiYjVlMCBmZmZmODMwNTRlZjQ3Y2Y4IGZmZmY4MmQwODAxNzg4NDYgZmZmZjgzMDM3
NzM0NTBlMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgIA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODJkMDgwMmU3ZWM4IGZmZmY4MmQwODAx
MmYzYzMgZmZmZjgyZDA4MDJlN2VmOCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MmQwODAyMmQ1
YTENCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgMDAwMDAwOTQzZjY1ZDhi
NCBmZmZmODMwNTVkMDAyZjI0IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMmY5ZmY4ODAwMA0K
KFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODJkMDgwMmZmZjgwIGZm
ZmY4MzA1NGVmNDdkMjggMDAwMDAwMDAwMDU1ZDEyNiBmZmZmODMwNTRlZjEyMDAwIGZmZmY4
MmQwODAyZmZmODAgZmZmZmZmZmZmZmZmZmZmZg0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6
NDEuNTkxXSAgICBmZmZmODMwNTE1YjViMGI4IGZmZmY4MmQwODAyZTAwMDAgZmZmZjg4MDAy
YjIyN2UxOA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODJkMDgw
MmU3ZWY4IGZmZmY4MmQwODAyZmZmODAgZmZmZjgyZDA4MDEyYmUzMSBmZmZmODMwMzc3MzQ1
MGE4IGZmZmY4MzA1MTViNWIwMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0g
ICAgMDIwMDIwMDIwMDIwMDIwMCBmZmZmODMwMDlmZDJkMDAwDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0MS41OTFdICAgIDAwMDA3Y2ZhYjEwYjgyYjcgMDAwMDAwMDAwMDAwMDAwMSBm
ZmZmODJkMDgwMjMzMTIyIDAyMDAyMDAyMDAyMDAyMDAgZmZmZjgzMDUxNWI1YjAwMA0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICAwMDAwMDAwMDAwMDAwMDAxIGZmZmY4
ODAwNTkyNWExZTgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgZmZmZjgz
MDM3NzM0NTBhOCBmZmZmODJkMDgwMmZmZjgwIGZmZmY4MmQwODAyZTdmMDggZmZmZjgyZDA4
MDEyYmU4OSBmZmZmODMwNTRlZjQ3ZGQ4IDAwMDA3ZDJmN2ZkMTgwYzcgZmZmZjgzMDUxNWI1
YjBiOCBmZmZmODJkMDgwMjMyY2QxDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFd
ICAgIGZmZmY4ODAwMmIyMjdlMTggZmZmZjg4MDA1OTI1YTFlOA0KKFhFTikgWzIwMTQtMTEt
MTggMjE6NTU6NDEuNTkxXSAgICAwMDAwMDAwMDAwMDAwMDAxIDAwMDAwMDAwMDAwMDAwMDEN
CihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgZmZmZjg4MDAyYjIyN2JiOCBm
ZmZmZmZmZjgyOTA4NGIwIGZmZmY4ODAwNWY2ZDM1YTggMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIDAwMDAw
MDAwMDAwMDAwZDAgMDAwMDAwOTQzZjRlMTcyZCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAz
NzczNDUxNTAgMDAwMDAwMDAwMDAwNTc3NiBmZmZmZmZmZjgxYzEwY2MwDQooWEVOKSBbMjAx
NC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIDAwMDAwMDk0M2Y0M2UzMDAgMDAwMDAwMDAwMDAw
MDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICAwMDAwMDAwMDAwMDAw
MDAxIDAwMDAwMDAwMDAwMDAwMDEgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODMwNTRlZjRlZjk4
DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIGZmZmY4MzA1MTViNWIwYmMg
MDAwMDAwYjkwMDAwMDAwMCBmZmZmODJkMDgwMTJjNjlmIGZmZmY4ODAwNTkyNWExODAgZmZm
Zjg4MDA1ZjZkMzUwMCAwMDAwMDAwMDAwMDBlMDA4IDAwMDAwMGZhMDAwMDAwMDANCihYRU4p
IFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgMDAwMDAwMDAwMDAwMDI0Ng0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmZmZmZjgxMGVhYjYzIGZmZmY4MzA1
NGVmNDdkZDAgMDAwMDAwMDAwMDAwZTAzMyAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAyODYgZmZmZjgzMDM3NzM0NTExMCBmZmZmODgwMDJiMjI3YjY4DQooWEVOKSBbMjAxNC0x
MS0xOCAyMTo1NTo0MS41OTFdICAgDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFd
ICAgIDAwMDAwMDAwMDAwMGUwMmIgZmZmZjgzMDU0ZWY0N2VjOCBmZmZmODJkMDgwMTQ5NjJk
IDAwMDAwMDAwMDAwMGJlZWYgMDAwMDAwMDAwMDAwMDEwMCBmZmZmODJkMDgwMzI4ZGEwDQoo
WEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIDAwMDAwMDAwMDAwMGJlZWYgMDAw
MDAwMDAwMDAwYmVlZg0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICAwMDAw
MDAwMDAwMDBiZWVmIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDA5ZmQyZDAwMCBmZmZmODMw
NTEyYjZjMDY4IDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDU0ZWY0ZTU0MA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODMwNTRlZjRlNDAwIDAwMDAwMDAwMDAw
MDAwMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gWGVuIGNhbGwgdHJhY2U6
DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIFs8ZmZmZjgyZDA4MDEyYzdl
Nz5dIF9zcGluX3VubG9jaysweDFmLzB4MzANCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQx
LjU5MV0gIGZmZmY4MzA1MTViNWIwYjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5
MV0gICAgMDAwMDAwMDEwMDAwMDAwMCBmZmZmODMwNTRlZjQ3ZTg4ICAgWzxmZmZmODJkMDgw
MTRhMzk1Pl0gcHRfaXJxX3RpbWVfb3V0KzB4MTI3LzB4MTM2DQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0MS41OTFdICAgIFs8ZmZmZjgyZDA4MDEyZjJjMz5dIGV4ZWN1dGVfdGltZXIr
MHg0ZS8weDZjDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIFs8ZmZmZjgy
ZDA4MDEyZjNjMz5dIHRpbWVyX3NvZnRpcnFfYWN0aW9uKzB4ZTIvMHgyMjANCihYRU4pIFsy
MDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgWzxmZmZmODJkMDgwMTJiZTMxPl0gX19kb19z
b2Z0aXJxKzB4ODEvMHg4Yw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBb
PGZmZmY4MmQwODAxMmJlODk+XSBkb19zb2Z0aXJxKzB4MTMvMHgxNQ0KKFhFTikgWzIwMTQt
MTEtMTggMjE6NTU6NDEuNTkxXSAgICBbPGZmZmY4MmQwODAyMzJjZDE+XSBwcm9jZXNzX3Nv
ZnRpcnFzKzB4MjEvMHgzMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSANCihY
RU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gIGZmZmY4MzA1NGVmNDdlODggZmZmZjgz
MDU0ZWY0N2U4OFBhZ2V0YWJsZSB3YWxrIGZyb20gMDAwMDAwMDAwMDAwMDBiODoNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0
MS41OTFdICAgIGZmZmY4MzAzNzczNDUwYTggTDRbMHgwMDBdID0gMDAwMDAwMDAwMDAwMDAw
MCBmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAw
MDAwMDAwMDAwMDAwMDgyIGZmZmY4MzAzNzczNDUwYTgNCihYRU4pIFsyMDE0LTExLTE4IDIx
OjU1OjQzLjI2MF0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K
KFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDMuMjgwXSAgZmZmZjgzMDM3NzM0NTE1MFBhbmlj
IG9uIENQVSAwOg0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDMuMjk3XSBGQVRBTCBQQUdF
IEZBVUxUDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My4zMTBdIFtlcnJvcl9jb2RlPTAw
MDBdDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My4zMjNdIEZhdWx0aW5nIGxpbmVhciBh
ZGRyZXNzOiAwMDAwMDAwMDAwMDAwMGI4DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My4z
NDNdICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCihYRU4pIFsy
MDE0LTExLTE4IDIxOjU1OjQzLjM2Ml0gDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My4z
NzFdIFJlYm9vdCBpbiBmaXZlIHNlY29uZHMuLi4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1
OjQzLjM4Nl0gDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My4zOTVdICAgIGZmZmY4MzA1
MTViNWIwMDAgMDAwMDAwMDAwMDAwMDAwMSBmZmZmODMwMzc3MzQ1MDgwIDAwMDAwMDAwMDAw
MDAwMmYNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjQyMl0gICAgZmZmZjgzMDU0ZWY0
N2YwOCBmZmZmODJkMDgwMTcyMWEzIGZmZmY4MzA1NGVmNDdlODggZmZmZjgzMDU0ZWY0N2U4
OA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDMuNDQ5XSAgICAwMDAwMGVjYzAwMDAwMDA0
IGZmZmY4MmQwODAzMDAwODAgZmZmZjgyZDA4MDJmZmY4MCBmZmZmZmZmZmZmZmZmZmZmDQoo
WEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My40NzZdICAgIGZmZmY4MzA1NGVmNDAwMDAgMDAw
MDAwMDAwMDAwMDAwMSBmZmZmODMwNTRlZjQ3ZWY4IGZmZmY4MmQwODAxMmJlMzENCihYRU4p
IFsyMDE0LTExLTE4IDIxOjU1OjQzLjUwM10gICAgZmZmZjgzMDA5ZmY4ODAwMCBmZmZmZmZm
ZjgzMDgxNTkwIGZmZmZmZmZmODIyMWM1MjAgZmZmZmZmZmY4MjIxY2MyMA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NTU6NDMuNTMwXSBYZW4gY2FsbCB0cmFjZToNCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjU1OjQzLjU0M10gICAgWzxmZmZmODJkMDgwMTRhNDYxPl0gaHZtX2RvX0lSUV9k
cGNpKzB4YmQvMHgxM2MNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjU2NV0gICAgWzxm
ZmZmODJkMDgwMTcyMDYwPl0gZG9fSVJRKzB4NDljLzB4NjI0DQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0My41ODRdICAgIFs8ZmZmZjgyZDA4MDIzMzEyMj5dIGNvbW1vbl9pbnRlcnJ1
cHQrMHg2Mi8weDcwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My42MDZdICAgIFs8ZmZm
ZjgyZDA4MDEyYzY5Zj5dIF9zcGluX2xvY2srMHgxYS8weDU0DQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0My42MjZdICAgIFs8ZmZmZjgyZDA4MDE0OTYyZD5dIGRwY2lfc29mdGlycSsw
eDI0MS8weDNhZA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDMuNjQ4XSAgICBbPGZmZmY4
MmQwODAxMmJlMzE+XSBfX2RvX3NvZnRpcnErMHg4MS8weDhjDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0My42NjldICAgIFs8ZmZmZjgyZDA4MDEyYmU4OT5dIGRvX3NvZnRpcnErMHgx
My8weDE1DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My42ODldICAgIFs8ZmZmZjgyZDA4
MDIzMmNkMT5dIHByb2Nlc3Nfc29mdGlycXMrMHgyMS8weDMwDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0My43MTFdIA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDMuNzIwXSBQYWdl
dGFibGUgd2FsayBmcm9tIDAwMDAwMDAwMDAwMDAxNjA6DQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1NTo0My43MzhdICBMNFsweDAwMF0gPSAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmZmZm
ZmZmZmYNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjc1OV0gDQooWEVOKSBbMjAxNC0x
MS0xOCAyMTo1NTo0My43NjhdICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjc4N10gUGFuaWMgb24gQ1BVIDI6
DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My44MDBdIEZBVEFMIFBBR0UgRkFVTFQNCihY
RU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjgxM10gW2Vycm9yX2NvZGU9MDAwMl0NCihYRU4p
IFsyMDE0LTExLTE4IDIxOjU1OjQzLjgyNl0gRmF1bHRpbmcgbGluZWFyIGFkZHJlc3M6IDAw
MDAwMDAwMDAwMDAxNjANCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjg0NV0gKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKFhFTikgWzIwMTQtMTEtMTgg
MjE6NTU6NDMuODY1XSANCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjg3M10gUmVib290
IGluIGZpdmUgc2Vjb25kcy4uLg0K
------------1231500C116741850
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------1231500C116741850--



From xen-devel-bounces@lists.xen.org Tue Nov 18 22:13:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 22:13:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqr1B-0007JD-4M; Tue, 18 Nov 2014 22:13:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1Xqr19-0007J8-7o
	for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 22:12:59 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	58/F1-27584-A64CB645; Tue, 18 Nov 2014 22:12:58 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416348776!12125310!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2728 invoked from network); 18 Nov 2014 22:12:56 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 18 Nov 2014 22:12:56 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54969 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xqqzb-0003oF-CU; Tue, 18 Nov 2014 23:11:23 +0100
Date: Tue, 18 Nov 2014 23:12:54 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <348130555.20141118231254@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141118205633.GB6540@laptop.dumpdata.com>
References: <1402169526.20141114230958@eikelenboom.it>
	<20141117163416.GA22137@laptop.dumpdata.com>
	<1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<20141118205633.GB6540@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------1231500C116741850"
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------1231500C116741850
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Tuesday, November 18, 2014, 9:56:33 PM, you wrote:

>> 
>> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
>> about them .. however looking at the earlier reports these lines were also in 
>> those reports).
>> 
>> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
>> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
>> and had a new default seabios config. (just to rule out anything stale in my tree)
>> 
>> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
>> seabios config) are not the most recent (they don't get updated automatically 
>> when you just do a git pull on the main tree) ?
>> 
>> In /tools/firmware/seabios-dir/.config i have:
>> CONFIG_USB=y
>> CONFIG_USB_UHCI=y
>> CONFIG_USB_OHCI=y
>> CONFIG_USB_EHCI=y
>> CONFIG_USB_XHCI=y
>> CONFIG_USB_MSC=y
>> CONFIG_USB_UAS=y
>> CONFIG_USB_HUB=y
>> CONFIG_USB_KEYBOARD=y
>> CONFIG_USB_MOUSE=y
>> 

> I seem to have the same thing. Perhaps it is my XHCI controller being wonky.

>> And this is all just from a:
>> - git clone git://xenbits.xen.org/xen.git -b staging
>> - make clean && ./configure && make -j6 && make -j6 install

> Aye. 
> .. snip..
>> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
>> >     [But this might be invalid as the addition of the ffff8303faaf25a8
>> >      might be correct - as the second dpci the softirq is processing
>> >      could be the MSI one]
>> 
>> Would there be an easy way to stress test this function separately in some 
>> debugging function to see if it indeed is returning unexpected values ?

> Sadly no. But you got me looking in the right direction when you mentioned
> 'timeout'.
>> 
>> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
>> 
>> Just curious, have you also tested the patches on AMD hardware ?

> Yes. To reproduce this the first thing I did was to get an AMD box.

>> 
>>  
>> >> When i look at the combination of (2) and (3), It seems it could be an 
>> >> interaction between the two passed through devices and/or different IRQ types.
>> 
>> > Could be - as in it is causing this issue to show up faster than
>> > expected. Or it is the one that triggers more than one dpci happening
>> > at the same time.
>> 
>> Well that didn't seem to be it (see separate amendment i mailed previously)

> Right, the current theory I've is that the interrupts are not being
> Acked within 8 milisecond and we reset the 'state' - and at the same
> time we get an interrupt and schedule it - while we are still processing
> the same interrupt. This would explain why the 'test_and_clear_bit'
> got the wrong value.

> In regards to the list poison - following this thread of logic - with
> the 'state = 0' set we open the floodgates for any CPU to put the same
> 'struct hvm_pirq_dpci' on its list.

> We do reset the 'state' on _every_ GSI that is mapped to a guest - so
> we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:

> CPUX:                           CPUY:
> pt_irq_time_out:
> state = 0;                      
> [out of timer coder, the                raise_softirq
>  pirq_dpci is on the dpci_list]         [adds the pirq_dpci as state == 0]

> softirq_dpci                            softirq_dpci:
>         list_del
>         [entries poison]
>                                                 list_del <= BOOM
>                         
> Is what I believe is happening.

> The INTX device - once I put a load on it - does not trigger
> any pt_irq_time_out, so that would explain why I cannot hit this.

> But I believe your card hits these "hiccups".   


Hi Konrad,

I just tested you 5 patches and as a result i still got an(other) host crash:
(complete serial log attached)

(XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) [2014-11-18 21:55:41.591] CPU:    0
(XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08012c7e7>]CPU:    2
(XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
(XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010006    _spin_unlock+0x1f/0x30CONTEXT: hypervisor
(XEN) [2014-11-18 21:55:41.591] 
(XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010246   rax: 0000000000000000   rbx: ffff8303773450a8   rcx: 0000000000000001
(XEN) [2014-11-18 21:55:41.591] CONTEXT: hypervisor
(XEN) [2014-11-18 21:55:41.591] rdx: 0000000000000000   rsi: ffff83054ef4ef98   rdi: 0000000012aa5400
(XEN) [2014-11-18 21:55:41.591] rax: ffff82d080328da0   rbx: ffff8305186c5d80   rcx: 0000000000000000
(XEN) [2014-11-18 21:55:41.591] rbp: ffff83054ef47c88   rsp: ffff83054ef47c78   r8:  ffff8305186c58d0
(XEN) [2014-11-18 21:55:41.591] r9:  000000000000002f   r10: 00000000000000d0   r11: ffffffff829084b0
(XEN) [2014-11-18 21:55:41.591] rdx: ffff82d0802e0000   rsi: ffff83050aead2a8   rdi: 00000000000000b8
(XEN) [2014-11-18 21:55:41.591] rbp: ffff82d0802e7df8   rsp: ffff82d0802e7df8   r8:  ffff82d0802e7d28
(XEN) [2014-11-18 21:55:41.591] r9:  0000000000000040   r10: 0000000000000000   r11: ffffffffffffffc0
(XEN) [2014-11-18 21:55:41.591] r12: ffff8305186c5d80   r13: ffff8303773450a8   r14: ffff8303773450b8
(XEN) [2014-11-18 21:55:41.591] r15: ffff8305186c5b00   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2014-11-18 21:55:41.591] r12: ffff830515b5b000   r13: 0000000000000000   r14: ffff830377345080
(XEN) [2014-11-18 21:55:41.591] cr3: 000000054a215000   cr2: 00000000000000b8
(XEN) [2014-11-18 21:55:41.591] r15: 000000000000002f   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2014-11-18 21:55:41.591] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) [2014-11-18 21:55:41.591] cr3: 000000054a215000   cr2: 0000000000000160
(XEN) [2014-11-18 21:55:41.591] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) [2014-11-18 21:55:41.591] Xen stack trace from rsp=ffff82d0802e7df8:
(XEN) [2014-11-18 21:55:41.591]    ffff82d0802e7e48Xen stack trace from rsp=ffff83054ef47c78:
(XEN) [2014-11-18 21:55:41.591]    ffff82d08014a395 ffff83009fd2d060 ffff83054ef47c88 ffff8303773450b8
(XEN) [2014-11-18 21:55:41.591]    ffffc900141f2b20 ffff82d080328f80 ffff830377345140 ffff82d08014a26e ffff8303773450a8 ffff83054ef47d18
(XEN) [2014-11-18 21:55:41.591]    ffff82d080172060 000000943f43e518 ffff88002b227e18 ffff82d0802e7e78
(XEN) [2014-11-18 21:55:41.591]    ffff82d08012f2c3 0000000000000286
(XEN) [2014-11-18 21:55:41.591]    0000000100000031 ffff82d08018b20f ffff82d080328f80 ffff83050b0bb5e0 ffff83054ef47cf8 ffff82d080178846 ffff8303773450e0
(XEN) [2014-11-18 21:55:41.591]   
(XEN) [2014-11-18 21:55:41.591]    ffff82d0802e7ec8 ffff82d08012f3c3 ffff82d0802e7ef8 0000000000000000 ffff82d08022d5a1
(XEN) [2014-11-18 21:55:41.591]    000000943f65d8b4 ffff83055d002f24 0000000000000000 0000002f9ff88000
(XEN) [2014-11-18 21:55:41.591]    ffff82d0802fff80 ffff83054ef47d28 000000000055d126 ffff83054ef12000 ffff82d0802fff80 ffffffffffffffff
(XEN) [2014-11-18 21:55:41.591]    ffff830515b5b0b8 ffff82d0802e0000 ffff88002b227e18
(XEN) [2014-11-18 21:55:41.591]    ffff82d0802e7ef8 ffff82d0802fff80 ffff82d08012be31 ffff8303773450a8 ffff830515b5b000
(XEN) [2014-11-18 21:55:41.591]    0200200200200200 ffff83009fd2d000
(XEN) [2014-11-18 21:55:41.591]    00007cfab10b82b7 0000000000000001 ffff82d080233122 0200200200200200 ffff830515b5b000
(XEN) [2014-11-18 21:55:41.591]    0000000000000001 ffff88005925a1e8
(XEN) [2014-11-18 21:55:41.591]    ffff8303773450a8 ffff82d0802fff80 ffff82d0802e7f08 ffff82d08012be89 ffff83054ef47dd8 00007d2f7fd180c7 ffff830515b5b0b8 ffff82d080232cd1
(XEN) [2014-11-18 21:55:41.591]    ffff88002b227e18 ffff88005925a1e8
(XEN) [2014-11-18 21:55:41.591]    0000000000000001 0000000000000001
(XEN) [2014-11-18 21:55:41.591]    ffff88002b227bb8 ffffffff829084b0 ffff88005f6d35a8 0000000000000000 0000000000000000
(XEN) [2014-11-18 21:55:41.591]    00000000000000d0 000000943f4e172d 0000000000000000 ffff830377345150 0000000000005776 ffffffff81c10cc0
(XEN) [2014-11-18 21:55:41.591]    000000943f43e300 0000000000000000
(XEN) [2014-11-18 21:55:41.591]    0000000000000001 0000000000000001 0000000000000000 ffff83054ef4ef98
(XEN) [2014-11-18 21:55:41.591]    ffff830515b5b0bc 000000b900000000 ffff82d08012c69f ffff88005925a180 ffff88005f6d3500 000000000000e008 000000fa00000000
(XEN) [2014-11-18 21:55:41.591]    0000000000000246
(XEN) [2014-11-18 21:55:41.591]    ffffffff810eab63 ffff83054ef47dd0 000000000000e033 0000000000000000 0000000000000286 ffff830377345110 ffff88002b227b68
(XEN) [2014-11-18 21:55:41.591]   
(XEN) [2014-11-18 21:55:41.591]    000000000000e02b ffff83054ef47ec8 ffff82d08014962d 000000000000beef 0000000000000100 ffff82d080328da0
(XEN) [2014-11-18 21:55:41.591]    000000000000beef 000000000000beef
(XEN) [2014-11-18 21:55:41.591]    000000000000beef 0000000000000000 ffff83009fd2d000 ffff830512b6c068 0000000000000000 ffff83054ef4e540
(XEN) [2014-11-18 21:55:41.591]    ffff83054ef4e400 0000000000000000
(XEN) [2014-11-18 21:55:41.591] Xen call trace:
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d08012c7e7>] _spin_unlock+0x1f/0x30
(XEN) [2014-11-18 21:55:41.591]  ffff830515b5b0b8
(XEN) [2014-11-18 21:55:41.591]    0000000100000000 ffff83054ef47e88   [<ffff82d08014a395>] pt_irq_time_out+0x127/0x136
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d08012f2c3>] execute_timer+0x4e/0x6c
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d08012f3c3>] timer_softirq_action+0xe2/0x220
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d08012be31>] __do_softirq+0x81/0x8c
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d08012be89>] do_softirq+0x13/0x15
(XEN) [2014-11-18 21:55:41.591]    [<ffff82d080232cd1>] process_softirqs+0x21/0x30
(XEN) [2014-11-18 21:55:41.591] 
(XEN) [2014-11-18 21:55:41.591]  ffff83054ef47e88 ffff83054ef47e88Pagetable walk from 00000000000000b8:
(XEN) [2014-11-18 21:55:41.591] 
(XEN) [2014-11-18 21:55:41.591]    ffff8303773450a8 L4[0x000] = 0000000000000000 ffffffffffffffff
(XEN) [2014-11-18 21:55:41.591]  0000000000000082 ffff8303773450a8
(XEN) [2014-11-18 21:55:43.260] ****************************************
(XEN) [2014-11-18 21:55:43.280]  ffff830377345150Panic on CPU 0:
(XEN) [2014-11-18 21:55:43.297] FATAL PAGE FAULT
(XEN) [2014-11-18 21:55:43.310] [error_code=0000]
(XEN) [2014-11-18 21:55:43.323] Faulting linear address: 00000000000000b8
(XEN) [2014-11-18 21:55:43.343] ****************************************
(XEN) [2014-11-18 21:55:43.362] 
(XEN) [2014-11-18 21:55:43.371] Reboot in five seconds...
(XEN) [2014-11-18 21:55:43.386] 
(XEN) [2014-11-18 21:55:43.395]    ffff830515b5b000 0000000000000001 ffff830377345080 000000000000002f
(XEN) [2014-11-18 21:55:43.422]    ffff83054ef47f08 ffff82d0801721a3 ffff83054ef47e88 ffff83054ef47e88
(XEN) [2014-11-18 21:55:43.449]    00000ecc00000004 ffff82d080300080 ffff82d0802fff80 ffffffffffffffff
(XEN) [2014-11-18 21:55:43.476]    ffff83054ef40000 0000000000000001 ffff83054ef47ef8 ffff82d08012be31
(XEN) [2014-11-18 21:55:43.503]    ffff83009ff88000 ffffffff83081590 ffffffff8221c520 ffffffff8221cc20
(XEN) [2014-11-18 21:55:43.530] Xen call trace:
(XEN) [2014-11-18 21:55:43.543]    [<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
(XEN) [2014-11-18 21:55:43.565]    [<ffff82d080172060>] do_IRQ+0x49c/0x624
(XEN) [2014-11-18 21:55:43.584]    [<ffff82d080233122>] common_interrupt+0x62/0x70
(XEN) [2014-11-18 21:55:43.606]    [<ffff82d08012c69f>] _spin_lock+0x1a/0x54
(XEN) [2014-11-18 21:55:43.626]    [<ffff82d08014962d>] dpci_softirq+0x241/0x3ad
(XEN) [2014-11-18 21:55:43.648]    [<ffff82d08012be31>] __do_softirq+0x81/0x8c
(XEN) [2014-11-18 21:55:43.669]    [<ffff82d08012be89>] do_softirq+0x13/0x15
(XEN) [2014-11-18 21:55:43.689]    [<ffff82d080232cd1>] process_softirqs+0x21/0x30
(XEN) [2014-11-18 21:55:43.711] 
(XEN) [2014-11-18 21:55:43.720] Pagetable walk from 0000000000000160:
(XEN) [2014-11-18 21:55:43.738]  L4[0x000] = 0000000000000000 ffffffffffffffff
(XEN) [2014-11-18 21:55:43.759] 
(XEN) [2014-11-18 21:55:43.768] ****************************************
(XEN) [2014-11-18 21:55:43.787] Panic on CPU 2:
(XEN) [2014-11-18 21:55:43.800] FATAL PAGE FAULT
(XEN) [2014-11-18 21:55:43.813] [error_code=0002]
(XEN) [2014-11-18 21:55:43.826] Faulting linear address: 0000000000000160
(XEN) [2014-11-18 21:55:43.845] ****************************************
(XEN) [2014-11-18 21:55:43.865] 
(XEN) [2014-11-18 21:55:43.873] Reboot in five seconds...

# addr2line -e xen-syms ffff82d08012c7e7
/usr/src/new/xen-unstable-vanilla/xen/include/asm/spinlock.h:18
# addr2line -e xen-syms ffff82d08014a461
/usr/src/new/xen-unstable-vanilla/xen/include/asm/atomic.h:172
# addr2line -e xen-syms ffff82d080172060
/usr/src/new/xen-unstable-vanilla/xen/arch/x86/irq.c:1175
# addr2line -e xen-syms ffff82d080233122
/usr/src/new/xen-unstable-vanilla/xen/arch/x86/x86_64/entry.S:487
# addr2line -e xen-syms ffff82d08012c69f
/usr/src/new/xen-unstable-vanilla/xen/common/spinlock.c:126
# addr2line -e xen-syms ffff82d08014962d
/usr/src/new/xen-unstable-vanilla/xen/drivers/passthrough/io.c:835
# addr2line -e xen-syms ffff82d08014a395
/usr/src/new/xen-unstable-vanilla/xen/drivers/passthrough/io.c:339
# addr2line -e xen-syms ffff82d08012f2c3
/usr/src/new/xen-unstable-vanilla/xen/common/timer.c:426
------------1231500C116741850
Content-Type: application/octet-stream;
 name="serial.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial.log"

77u/IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgIF9fXyAgICAgICAgICAgICAg
DQogXCBcLyAvX19fIF8gX18gICB8IHx8IHwgIHwgX19ffCAvIF8gXCAgICBfIF9fIF9fXyAN
CiAgXCAgLy8gXyBcICdfIFwgIHwgfHwgfF8gfF9fXyBcfCB8IHwgfF9ffCAnX18vIF9ffA0K
ICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8IHxffCB8X198IHwgfCAoX18gDQog
L18vXF9cX19ffF98IHxffCAgICB8X3woXylfX19fKF8pX19fLyAgIHxffCAgXF9fX3wNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KKFhF
TikgWGVuIHZlcnNpb24gNC41LjAtcmMgKHJvb3RAZHluZG5zLm9yZykgKGdjYy00LjcucmVh
bCAoRGViaWFuIDQuNy4yLTUpIDQuNy4yKSBkZWJ1Zz15IFR1ZSBOb3YgMTggMjI6Mzc6NTgg
Q0VUIDIwMTQNCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IFdlZCBOb3YgNSAxNDozMjo0NyAy
MDE0ICswMDAwIGdpdDowOWZmOGVhLWRpcnR5DQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEu
OTktMjcrZGViN3UyDQooWEVOKSBDb21tYW5kIGxpbmU6IGRvbTBfbWVtPTE1MzZNLG1heDox
NTM2TSBsb2dsdmw9YWxsIGxvZ2x2bF9ndWVzdD1hbGwgY29uc29sZV90aW1lc3RhbXBzPWRh
dGVtcyB2Z2E9Z2Z4LTEyODB4MTAyNHgzMiBuby1jcHVpZGxlIGNvbTE9Mzg0MDAsOG4xIGNv
bnNvbGU9dmdhLGNvbTEgaXZyc19pb2FwaWNbNl09MDA6MTQuMCBpb21tdT1vbix2ZXJib3Nl
LGRlYnVnLGFtZC1pb21tdS1kZWJ1ZyBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGljX3ZlcmJvc2l0
eT1kZWJ1ZyBhcGljPWRlYnVnDQooWEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoNCihYRU4pICBW
R0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgweDEwMjQsIDMyIGJwcA0KKFhFTikgIFZCRS9EREMg
bWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzDQooWEVOKSBEaXNj
IGluZm9ybWF0aW9uOg0KKFhFTikgIEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMNCihYRU4pICBG
b3VuZCAyIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzDQooWEVOKSBYZW4tZTgyMCBSQU0g
bWFwOg0KKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDk5NDAwICh1c2Fi
bGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5OTQwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2Vy
dmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAwZTQwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNl
cnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDA5ZmY5MDAwMCAodXNh
YmxlKQ0KKFhFTikgIDAwMDAwMDAwOWZmOTAwMDAgLSAwMDAwMDAwMDlmZjllMDAwIChBQ1BJ
IGRhdGEpDQooWEVOKSAgMDAwMDAwMDA5ZmY5ZTAwMCAtIDAwMDAwMDAwOWZmZTAwMDAgKEFD
UEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAwOWZmZTAwMDAgLSAwMDAwMDAwMGEwMDAwMDAwIChy
ZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAo
cmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDA1NjAwMDAwMDAg
KHVzYWJsZSkNCihYRU4pIEFDUEk6IFJTRFAgMDAwRkIxMDAsIDAwMTQgKHIwIEFDUElBTSkN
CihYRU4pIEFDUEk6IFJTRFQgOUZGOTAwMDAsIDAwNDggKHIxIE1TSSAgICBPRU1TTElDICAy
MDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogRkFDUCA5RkY5MDIwMCwgMDA4
NCAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBB
Q1BJOiBEU0RUIDlGRjkwNUUwLCA5NDI3IChyMSAgQTc2NDAgQTc2NDAxMDAgICAgICAxMDAg
SU5UTCAyMDA1MTExNykNCihYRU4pIEFDUEk6IEZBQ1MgOUZGOUUwMDAsIDAwNDANCihYRU4p
IEFDUEk6IEFQSUMgOUZGOTAzOTAsIDAwODggKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkx
MyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogTUNGRyA5RkY5MDQyMCwgMDAzQyAocjEg
NzY0ME1TIE9FTU1DRkcgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBT
TElDIDlGRjkwNDYwLCAwMTc2IChyMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA5MTMgTVNGVCAg
ICAgICA5NykNCihYRU4pIEFDUEk6IE9FTUIgOUZGOUUwNDAsIDAwNzIgKHIxIDc2NDBNUyBB
NzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogU1JBVCA5RkY5
QTVFMCwgMDEwOCAocjMgQU1EICAgIEZBTV9GXzEwICAgICAgICAyIEFNRCAgICAgICAgIDEp
DQooWEVOKSBBQ1BJOiBIUEVUIDlGRjlBNkYwLCAwMDM4IChyMSA3NjQwTVMgT0VNSFBFVCAg
MjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IElWUlMgOUZGOUE3MzAsIDAx
MTAgKHIxICBBTUQgICAgIFJEODkwUyAgIDIwMjAzMSBBTUQgICAgICAgICAwKQ0KKFhFTikg
QUNQSTogU1NEVCA5RkY5QTg0MCwgMERBNCAocjEgQSBNIEkgIFBPV0VSTk9XICAgICAgICAx
IEFNRCAgICAgICAgIDEpDQooWEVOKSBTeXN0ZW0gUkFNOiAyMDQ3OU1CICgyMDk3MDY2MGtC
KQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUgMA0KKFhFTikgU1JBVDog
UFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAy
IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAzIC0+IE5vZGUgMA0KKFhF
TikgU1JBVDogUFhNIDAgLT4gQVBJQyA0IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAg
LT4gQVBJQyA1IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDAtYTAwMDAN
CihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAtYTAwMDAwMDANCihYRU4pIFNSQVQ6
IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtNTYwMDAwMDAwDQooWEVOKSBOVU1BOiBBbGxvY2F0
ZWQgbWVtbm9kZW1hcCBmcm9tIDU1ZDBhZjAwMCAtIDU1ZDBiNTAwMA0KKFhFTikgTlVNQTog
VXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQooWEVOKSBEb21haW4gaGVhcCBpbml0aWFs
aXNlZA0KKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGQwMDAwMDAwLCBtYXBwZWQg
dG8gMHhmZmZmODJjMDAwMjAxMDAwLCB1c2luZyA2MTQ0aywgdG90YWwgMTYzODRrDQooWEVO
KSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMyLCBsaW5lbGVuZ3RoPTUxMjAsIGZvbnQg
OHgxNg0KKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6IHNpemU9MDo4Ojg6OCwgc2hpZnQ9MDox
Njo4OjANCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAwMDBmZjc4MA0KKFhFTikgRE1J
IHByZXNlbnQuDQooWEVOKSBBUElDIGJvb3Qgc3RhdGUgaXMgJ3hhcGljJw0KKFhFTikgVXNp
bmcgQVBJQyBkcml2ZXIgZGVmYXVsdA0KKFhFTikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDog
MHg4MDgNCihYRU4pIEFDUEk6IFNMRUVQIElORk86IHBtMXhfY250WzE6ODA0LDE6MF0sIHBt
MXhfZXZ0WzE6ODAwLDE6MF0NCihYRU4pIEFDUEk6ICAgICAgICAgICAgIHdha2V1cF92ZWNb
OWZmOWUwMGNdLCB2ZWNfc2l6ZVsyMF0NCihYRU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVz
cyAweGZlZTAwMDAwDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19p
ZFsweDAwXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMwIDA6MTAgQVBJQyB2ZXJzaW9u
IDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBl
bmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMxIDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0K
KFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAzXSBlbmFibGVkKQ0KKFhFTikgUHJv
Y2Vzc29yICMzIDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICM0
IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2
XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICM1IDA6MTAgQVBJ
QyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDZdIGFkZHJlc3NbMHhm
ZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pDQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgNiwgdmVy
c2lvbiAzMywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0yMw0KKFhFTikgQUNQSTogSU9B
UElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVjMjAwMDBdIGdzaV9iYXNlWzI0XSkNCihYRU4p
IElPQVBJQ1sxXTogYXBpY19pZCA3LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMjAwMDAs
IEdTSSAyNC01NQ0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBn
bG9iYWxfaXJxIDIgZGZsIGRmbCkNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBi
dXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZlbCkNCihYRU4pIEFDUEk6IElSUTAgdXNl
ZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NCihY
RU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEVuYWJsaW5nIEFQSUMg
bW9kZTogIEZsYXQuICBVc2luZyAyIEkvTyBBUElDcw0KKFhFTikgQUNQSTogSFBFVCBpZDog
MHg4MzAwIGJhc2U6IDB4ZmVkMDAwMDANCihYRU4pIEVSU1QgdGFibGUgd2FzIG5vdCBmb3Vu
ZA0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9y
bWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBob3RwbHVnIENQVXMpDQoo
WEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjZmZmZGZiMDAwIChmZWUwMDAwMCkNCihYRU4p
IG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyY2ZmZmRmYTAwMCAoZmVjMDAwMDApDQooWEVOKSBt
YXBwZWQgSU9BUElDIHRvIGZmZmY4MmNmZmZkZjkwMDAgKGZlYzIwMDAwKQ0KKFhFTikgSVJR
IGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWA0KKFhFTikgVXNpbmcgc2NoZWR1bGVy
OiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikgRGV0ZWN0ZWQgMzIwMC4x
MzIgTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuDQooWEVO
KSBBTUQgRmFtMTBoIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQNCihYRU4pIGFs
dCB0YWJsZSBmZmZmODJkMDgwMmQ5ZWYwIC0+IGZmZmY4MmQwODAyZGFmMTANCihYRU4pIFBD
STogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAgc2VnbWVudCAwMDAwIGJ1
c2VzIDAwIC0gZmYNCihYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21lbnQgMDAw
MCBidXMgMDAtZmYNCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNhcGFiaWxpdHkgYmxvY2sg
YXQgMHg1NA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhFTikgQU1ELVZpOiAgU2ln
bmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweDExMA0KKFhFTikgQU1ELVZp
OiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBDaGVja1N1bSAweGViDQooWEVOKSBB
TUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1WaTogIE9FTV9UYWJsZV9JZCBSRDg5
MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAweDIwMjAzMQ0KKFhFTikgQU1ELVZp
OiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6ICBDcmVhdG9yX1JldmlzaW9uIDAN
CihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazogdHlwZSAweDEwIGZsYWdzIDB4M2UgbGVuIDB4
ZTAgaWQgMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBp
ZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDINCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MTAgZmxhZ3Mg
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHhmMDAg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweGYwMCAtPiAweGYwMQ0K
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgxOCBmbGFn
cyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweGUw
MCBmbGFncyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4ZTAwIC0+IDB4ZTAx
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDI4IGZs
YWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4
ZDAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgy
IGlkIDB4MzAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlw
ZSAweDIgaWQgMHhjMDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eTogdHlwZSAweDIgaWQgMHg0OCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5OiB0eXBlIDB4MiBpZCAweGIwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDUwIGZsYWdzIDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTAwIGZsYWdzIDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NTggZmxhZ3MgMA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHg5MDAgZmxhZ3Mg
MA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwMCAtPiAweDkwMQ0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg2MCBmbGFncyAwDQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDUwMCBmbGFn
cyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDYw
OCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBp
ZCAweDgwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweDYxMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
OiB0eXBlIDB4MiBpZCAweDcwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5OiB0eXBlIDB4MiBpZCAweDY4IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NDAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4ODggZmxhZ3MgMA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHg5MCBmbGFncyAwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4OTAgLT4gMHg5Mg0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeTogdHlwZSAweDMgaWQgMHg5OCBmbGFncyAwDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgUmFuZ2U6IDB4OTggLT4gMHg5YQ0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhMCBmbGFncyAweGQ3DQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGEyIGZsYWdzIDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTMgZmxhZ3MgMA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhNCBmbGFncyAw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4NDMgaWQgMHgzMDAg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDMwMCAtPiAweDNmZiBh
bGlhcyAweGE0DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBp
ZCAweGE1IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUg
MHgyIGlkIDB4YTggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHhhOSBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4MiBpZCAweDEwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweGIwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERl
dl9JZCBSYW5nZTogMHhiMCAtPiAweGIyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDAgaWQgMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4NDggaWQgMCBmbGFncyAweGQ3DQooWEVOKSBBTUQtVmk6IElWSEQgU3Bl
Y2lhbDogMDAwMDowMDoxNC4wIHZhcmlldHkgMHgyIGhhbmRsZSAwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4NDggaWQgMCBmbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgU3BlY2lhbDogMDAwMDowMDowMC4xIHZhcmlldHkgMHgxIGhhbmRsZSAweDcN
CihYRU4pIEFNRC1WaTogRGlzYWJsZWQgSEFQIG1lbW9yeSBtYXAgc2hhcmluZyB3aXRoIElP
TU1VDQooWEVOKSBBTUQtVmk6IElPTU1VIDAgRW5hYmxlZC4NCihYRU4pIEkvTyB2aXJ0dWFs
aXNhdGlvbiBlbmFibGVkDQooWEVOKSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQNCihYRU4pIElu
dGVycnVwdCByZW1hcHBpbmcgZW5hYmxlZA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1
MDAxMA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBJ
RDogMA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDANCihYRU4pIEdldHRpbmcgTFZUMTogNDAw
DQooWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUjMA0KKFhFTikgRVNSIHZhbHVlIGJlZm9y
ZSBlbmFibGluZyB2ZWN0b3I6IDB4NCAgYWZ0ZXI6IDANCihYRU4pIEVOQUJMSU5HIElPLUFQ
SUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9kDQooWEVOKSBpbml0IElP
X0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFwaWNpZC1waW4pIDYtMCwgNi0xNiwgNi0x
NywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0yMiwgNi0yMywgNy0wLCA3LTEsIDctMiwg
Ny0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwgNy05LCA3LTEwLCA3LTExLCA3LTEyLCA3
LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3
LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3
LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0w
IHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVOKSBudW1iZXIgb2YgTVAgSVJRIHNvdXJj
ZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQSUMgIzYgcmVnaXN0ZXJzOiAyNC4NCihY
RU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lzdGVyczogMzIuDQooWEVOKSB0ZXN0aW5n
IHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCihYRU4pIElPIEFQSUMgIzYu
Li4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwNjAwMDAwMA0KKFhFTikgLi4uLi4u
LiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZl
cnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4p
IC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXgg
cmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1w
bGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIx
DQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAg
IDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMzogMDcwMDAwMDAN
CihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAgICA6IDANCihYRU4pIC4uLi4gSVJRIHJl
ZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wg
U3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4pICAwMCAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAxICAgIDMwDQooWEVOKSAgMDEgMDAxIDAxICAwICAgIDAgICAg
MCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhFTikgIDAyIDAwMSAwMSAgMCAgICAwICAg
IDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihYRU4pICAwMyAwMDEgMDEgIDAgICAgMCAg
ICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQooWEVOKSAgMDQgMDAxIDAxICAwICAgIDAg
ICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0KKFhFTikgIDA1IDAwMSAwMSAgMCAgICAw
ICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDANCihYRU4pICAwNiAwMDEgMDEgIDAgICAg
MCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4DQooWEVOKSAgMDcgMDAxIDAxICAwICAg
IDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1MA0KKFhFTikgIDA4IDAwMSAwMSAgMCAg
ICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTgNCihYRU4pICAwOSAwMDEgMDEgIDEg
ICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAwICAgIDAwDQooWEVOKSAgMGEgMDAxIDAxICAw
ICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA2OA0KKFhFTikgIDBiIDAwMSAwMSAg
MCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzANCihYRU4pICAwYyAwMDEgMDEg
IDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4DQooWEVOKSAgMGQgMDAxIDAx
ICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA4OA0KKFhFTikgIDBlIDAwMSAw
MSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgOTANCihYRU4pICAwZiAwMDEg
MDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDk4DQooWEVOKSAgMTAgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAzMA0KKFhFTikgIDExIDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzANCihYRU4pICAxMiAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwDQooWEVOKSAgMTMg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAzMA0KKFhFTikgIDE0
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzANCihYRU4pICAx
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAxICAgIDMwDQooWEVOKSAg
MTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMSAgICAzMA0KKFhFTikg
IDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDEgICAgMzANCihYRU4p
IElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwNzAwMDAwMA0K
KFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA3DQooWEVOKSAuLi4uLi4u
ICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExUUyAgICAgICAg
ICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDFGODAyMQ0KKFhFTikgLi4uLi4u
LiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxRg0KKFhFTikgLi4uLi4uLiAg
ICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2
ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDAwMDAwMDANCihYRU4p
IC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVj
dGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQg
RGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAxIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMiAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDMgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA0IDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNSAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDYgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA3IDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwOCAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDkgMDAwIDAwICAxICAgIDAg
ICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBhIDAwMCAwMCAgMSAgICAw
ICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwYiAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGMgMDAwIDAwICAxICAg
IDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBkIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwZSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGYgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEwIDAwMCAwMCAg
MSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNyAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTgg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE5
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAx
YSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZw0KKFhFTikgSVJRIHRvIHBpbiBtYXBw
aW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihYRU4pIElSUTQ4IC0+IDA6MQ0KKFhFTikg
SVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4gMDo0DQooWEVOKSBJUlE2NCAtPiAwOjUN
CihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJRODAgLT4gMDo3DQooWEVOKSBJUlE4OCAt
PiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhFTikgSVJRMTA0IC0+IDA6MTANCihYRU4p
IElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAgLT4gMDoxMg0KKFhFTikgSVJRMTM2IC0+
IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQooWEVOKSBJUlExNTIgLT4gMDoxNQ0KKFhF
TikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIGRvbmUuDQooWEVOKSBV
c2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVwdHMuDQooWEVOKSBjYWxpYnJhdGluZyBB
UElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BVIGNsb2NrIHNwZWVkIGlzIDMyMDAuMjA5
MyBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBjbG9jayBzcGVlZCBpcyAyMDAuMDEzMCBN
SHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAweGNjZDcNCihYRU4pIFsyMDE0LTExLTE4
IDIxOjQ1OjExLjU2Ml0gUGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjExLjU4M10gQWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2
NCBLaUIuDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS41ODldIEhWTTogQVNJRHMgZW5h
YmxlZC4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjU5NV0gU1ZNOiBTdXBwb3J0ZWQg
YWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS42MDFdICAt
IE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTEu
NjA3XSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24NCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjExLjYxNF0gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJ
VA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTEuNjIwXSAgLSBQYXVzZS1JbnRlcmNlcHQg
RmlsdGVyDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS42MjZdIEhWTTogU1ZNIGVuYWJs
ZWQNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjYzMl0gSFZNOiBIYXJkd2FyZSBBc3Np
c3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEx
LjYzOV0gSFZNOiBIQVAgcGFnZSBzaXplczogNGtCLCAyTUIsIDFHQg0KKFhFTikgWzIwMTQt
MTEtMTggMjE6NDU6MTEuNjQ1XSBIVk06IFBWSCBtb2RlIG5vdCBzdXBwb3J0ZWQgb24gdGhp
cyBwbGF0Zm9ybQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTEuNjcyXSBtYXNrZWQgRXh0
SU5UIG9uIENQVSMxDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS42OThdIG1hc2tlZCBF
eHRJTlQgb24gQ1BVIzINCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjcyNV0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTEuNzUyXSBtYXNr
ZWQgRXh0SU5UIG9uIENQVSM0DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS43NzhdIG1h
c2tlZCBFeHRJTlQgb24gQ1BVIzUNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjc4NV0g
QnJvdWdodCB1cCA2IENQVXMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjgxNV0gQUNQ
SSBzbGVlcCBtb2RlczogUzMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjgyMV0gTUNB
OiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NDU6MTEuODI4XSBtY2hlY2tfcG9sbDogTWFjaGluZSBjaGVj
ayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMS44
MzVdIFhlbm9wcm9maWxlOiBGYWlsZWQgdG8gc2V0dXAgSUJTIExWVCBvZmZzZXQsIElCU0NU
TCA9IDB4ZmZmZmZmZmYNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjExLjg0MV0gKioqIExP
QURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4wMTBdIGVs
Zl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weDEwNjQwMDAN
CihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEyLjAxN10gZWxmX3BhcnNlX2JpbmFyeTogcGhk
cjogcGFkZHI9MHgyMjAwMDAwIG1lbXN6PTB4MTA2MDAwDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo0NToxMi4wMjRdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MjMwNjAwMCBt
ZW1zej0weDE0MjgwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4wMzFdIGVsZl9wYXJz
ZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MjMxYjAwMCBtZW1zej0weDExNDAwMDANCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjEyLjAzOF0gZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5OiAw
eDEwMDAwMDAgLT4gMHgzNDViMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4wNDVd
IGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAxNC0x
MS0xOCAyMTo0NToxMi4wNTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9
ICIyLjYiDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4wNjBdIGVsZl94ZW5fcGFyc2Vf
bm90ZTogWEVOX1ZFUlNJT04gPSAieGVuLTMuMCINCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1
OjEyLjA2N10gZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAw
MDAwMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEyLjA3NV0gZWxmX3hlbl9wYXJzZV9u
b3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4MjMxYjFmMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NDU6MTIuMDgyXSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZm
ZmZmZjgxMDAxMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4wOTBdIGVsZl94ZW5f
cGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rp
cl9hYm92ZV80Z2J8d3JpdGFibGVfZGVzY3JpcHRvcl90YWJsZXN8YXV0b190cmFuc2xhdGVk
X3BoeXNtYXB8c3VwZXJ2aXNvcl9tb2RlX2tlcm5lbCINCihYRU4pIFsyMDE0LTExLTE4IDIx
OjQ1OjEyLjEwNV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVBQT1JURURfRkVBVFVSRVMgPSAw
eDkwZA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMTEzXSBlbGZfeGVuX3BhcnNlX25v
dGU6IFBBRV9NT0RFID0gInllcyINCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEyLjEyMV0g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyINCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjQ1OjEyLjEyOV0gZWxmX3hlbl9wYXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYg
bm90ZSAoMHhkKQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMTM3XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0
NToxMi4xNDVdIGVsZl94ZW5fcGFyc2Vfbm90ZTogTU9EX1NUQVJUX1BGTiA9IDB4MQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMTU0XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhWX1NU
QVJUX0xPVyA9IDB4ZmZmZjgwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6
MTIuMTYyXSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MA0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NDU6MTIuMTcxXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRk
cmVzc2VzOg0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMTc5XSAgICAgdmlydF9iYXNl
ICAgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6
MTIuMTg4XSAgICAgZWxmX3BhZGRyX29mZnNldCA9IDB4MA0KKFhFTikgWzIwMTQtMTEtMTgg
MjE6NDU6MTIuMTk3XSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAw
MA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMjA2XSAgICAgdmlydF9rc3RhcnQgICAg
ICA9IDB4ZmZmZmZmZmY4MTAwMDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMjE1
XSAgICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZmZmZmZmY4MzQ1YjAwMA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NDU6MTIuMjI0XSAgICAgdmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZm
ZmY4MjMxYjFmMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuMjMzXSAgICAgcDJtX2Jh
c2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZmZg0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NDU6MTIuMjQzXSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMg0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NDU6MTIuMjUyXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBs
c2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDM0NWIwMDANCihYRU4pIFsyMDE0LTExLTE4IDIx
OjQ1OjEyLjI2M10gUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTQt
MTEtMTggMjE6NDU6MTIuMjcyXSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDU0ODAwMDAwMC0+
MDAwMDAwMDU0YzAwMDAwMCAoMzcyOTM4IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjEyLjI4M10gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDA1NWYw
Y2EwMDAtPjAwMDAwMDA1NWZmZmZhMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEyLjI5
NF0gVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0
NToxMi4zMDRdICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgz
NDViMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4zMTRdICBJbml0LiByYW1kaXNr
OiAwMDAwMDAwMDAwMDAwMDAwLT4wMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo0NToxMi4zMjVdICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgzNDViMDAwLT5mZmZm
ZmZmZjgzNzViMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4zMzVdICBTdGFydCBp
bmZvOiAgICBmZmZmZmZmZjgzNzViMDAwLT5mZmZmZmZmZjgzNzViNGI0DQooWEVOKSBbMjAx
NC0xMS0xOCAyMTo0NToxMi4zNDZdICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzNzVjMDAw
LT5mZmZmZmZmZjgzNzdiMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4zNTddICBC
b290IHN0YWNrOiAgICBmZmZmZmZmZjgzNzdiMDAwLT5mZmZmZmZmZjgzNzdjMDAwDQooWEVO
KSBbMjAxNC0xMS0xOCAyMTo0NToxMi4zNjhdICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgw
MDAwMDAwLT5mZmZmZmZmZjgzODAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMi4z
NzhdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgyMzFiMWYwDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo0NToxMi4zOTBdIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcw0KKFhFTikgWzIwMTQt
MTEtMTggMjE6NDU6MTIuNDAxXSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMCBhdCAweGZmZmZm
ZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgyMDY0MDAwDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo0NToxMi40MTldIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MjIw
MDAwMCAtPiAweGZmZmZmZmZmODIzMDYwMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEy
LjQzMF0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgyMzA2MDAwIC0+
IDB4ZmZmZmZmZmY4MjMxYTI4MA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTIuNDQxXSBl
bGZfbG9hZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODIzMWIwMDAgLT4gMHhmZmZm
ZmZmZjgyNDIzMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMy41ODJdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDAsIHR5cGUgPSAweDYsIHJvb3Qg
dGFibGUgPSAweDU0ZWVkYzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVO
KSBbMjAxNC0xMS0xOCAyMTo0NToxMy41OTNdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MiwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRj
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIx
OjQ1OjEzLjYwNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgxMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjYxN10gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgxOCwgdHlwZSA9IDB4
Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjYyOV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyOCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9
IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0
LTExLTE4IDIxOjQ1OjEzLjY0MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgzMCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEz
LjY1NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0OCwg
dHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjY2Nl0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1MCwgdHlwZSA9IDB4Miwgcm9v
dCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjY3OV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHg1OCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRl
ZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4
IDIxOjQ1OjEzLjY5Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHg2MCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjcwNl0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg2OCwgdHlwZSA9
IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjcxOV0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg4OCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJs
ZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDE0LTExLTE4IDIxOjQ1OjEzLjczM10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHg5MCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1
OjEzLjc0N10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5
MiwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjc2MV0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgdHlwZSA9IDB4Nywg
cm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjc3NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5YSwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4
NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjQ1OjEzLjc4OV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHhhMCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjgw
M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMiwgdHlw
ZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjgxOF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMywgdHlwZSA9IDB4Nywgcm9vdCB0
YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjEzLjgzM10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHhhNCwgdHlwZSA9IDB4NSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRj
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIx
OjQ1OjEzLjg0N10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHhhNSwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjg2Ml0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhOCwgdHlwZSA9IDB4
Miwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjg3N10gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMCwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9
IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0
LTExLTE4IDIxOjQ1OjEzLjg5M10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHhiMiwgdHlwZSA9IDB4Nywgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEz
LjkwOF0gQU1ELVZpOiBTa2lwcGluZyBob3N0IGJyaWRnZSAwMDAwOjAwOjE4LjANCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjEzLjkyM10gQU1ELVZpOiBTa2lwcGluZyBob3N0IGJyaWRn
ZSAwMDAwOjAwOjE4LjENCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjkzOV0gQU1ELVZp
OiBTa2lwcGluZyBob3N0IGJyaWRnZSAwMDAwOjAwOjE4LjINCihYRU4pIFsyMDE0LTExLTE4
IDIxOjQ1OjEzLjk1NF0gQU1ELVZpOiBTa2lwcGluZyBob3N0IGJyaWRnZSAwMDAwOjAwOjE4
LjMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjk2OV0gQU1ELVZpOiBTa2lwcGluZyBo
b3N0IGJyaWRnZSAwMDAwOjAwOjE4LjQNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjEzLjk4
NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDAsIHR5
cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYzAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxMy45OTldIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NTAwLCB0eXBlID0gMHgyLCByb290
IHRhYmxlID0gMHg1NGVlZGMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NDU6MTQuMDE1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDYwOCwgdHlwZSA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4NTRl
ZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4
IDIxOjQ1OjE0LjAzMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHg2MTAsIHR5cGUgPSAweDIsIHJvb3QgdGFibGUgPSAweDU0ZWVkYzAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxNC4wNDZd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NzAwLCB0eXBl
ID0gMHgxLCByb290IHRhYmxlID0gMHg1NGVlZGMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTQuMDYzXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDgwMCwgdHlwZSA9IDB4MSwgcm9vdCB0
YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjQ1OjE0LjA3OV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg5MDAsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVk
YzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo0NToxNC4wOTVdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4OTAxLCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1NGVlZGMwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTQuMTEyXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEwMCwgdHlwZSA9
IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjE0LjEyOV0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMDAsIHR5cGUgPSAweDEsIHJvb3QgdGFi
bGUgPSAweDU0ZWVkYzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxNC0xMS0xOCAyMTo0NToxNC4xNDZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4YzAwLCB0eXBlID0gMHgxLCByb290IHRhYmxlID0gMHg1NGVlZGMw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NDU6MTQuMTYzXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eGQwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1OjE0LjE4MF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhlMDAsIHR5cGUgPSAw
eDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxNC4xOTddIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ZTAxLCB0eXBlID0gMHgxLCByb290IHRhYmxl
ID0gMHg1NGVlZGMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NDU6MTQuMjE1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweGYwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTRlZWRjMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1
OjE0LjIzM10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhm
MDEsIHR5cGUgPSAweDEsIHJvb3QgdGFibGUgPSAweDU0ZWVkYzAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxNC4yNTZdIFNjcnVi
YmluZyBGcmVlIFJBTSBvbiAxIG5vZGVzIHVzaW5nIDYgQ1BVcw0KKFhFTikgWzIwMTQtMTEt
MTggMjE6NDU6MTQuMzY2XSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuDQoo
WEVOKSBbMjAxNC0xMS0xOCAyMTo0NToxNy40NTldIEluaXRpYWwgbG93IG1lbW9yeSB2aXJx
IHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLg0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NDU6MTcuNDc3XSBTdGQuIExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1
OjE3LjQ5NV0gR3Vlc3QgTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6
MTcuNTEyXSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihYRU4pIFsyMDE0
LTExLTE4IDIxOjQ1OjE3LjYxNF0gKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdD
VFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4pDQooWEVOKSBbMjAx
NC0xMS0xOCAyMTo0NToxNy42MTVdIEZyZWVkIDI4OGtCIGluaXQgbWVtb3J5Lg0KbWFwcGlu
ZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkNCmFib3V0IHRvIGdldCBzdGFydGVkLi4u
DQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVzZXQNClsg
ICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQ0KWyAgICAwLjAw
MDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1YWNjdA0KWyAgICAwLjAwMDAw
MF0gTGludXggdmVyc2lvbiAzLjE4LjAtcmM1LTIwMTQxMTE2LXZhbmlsbGEgKHJvb3RAc2Vy
dmVlcnN0ZXJ0amUpIChnY2MgdmVyc2lvbiA0LjcuMiAoRGViaWFuIDQuNy4yLTUpICkgIzEg
U01QIFR1ZSBOb3YgMTggMTA6MTg6MjMgQ0VUIDIwMTQNClsgICAgMC4wMDAwMDBdIENvbW1h
bmQgbGluZTogcm9vdD0vZGV2L21hcHBlci9zZXJ2ZWVyc3RlcnRqZS1yb290IHJvIHZlcmJv
c2UgZWFybHlwcmludGs9eGVuIG1lbT0xNTM2TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkw
IHZnYT03OTQgdmlkZW89dmVzYWZiIHI4MTY5LnVzZV9kYWM9MSBhY3BpX2VuZm9yY2VfcmVz
b3VyY2VzPWxheCBtYXhfbG9vcD0zMCBsb29wX21heF9wYXJ0PTEwIGRlYnVnIGxvZ2xldmVs
PTEwIG5vbW9kZXNldCB4ZW4tcGNpYmFjay5oaWRlPSgwMzowNi4wKSgwNDowMC4qKSgwNzow
MC4qKSgwODowMC4qKSgwOTowMC4qKSgwYTowMC4wKSgwYjowMC4wKSgwZTowMC4qKSByODE2
OS51c2VfZGFjPTEgYWNwaS5kZWJ1Z19sYXllcj0weDQwMDAwMCBhY3BpLmRlYnVnX2xldmVs
PTB4NA0KWyAgICAwLjAwMDAwMF0gU2V0IDEyODk3NTA2MyBwYWdlKHMpIHRvIDEtMSBtYXBw
aW5nDQpbICAgIDAuMDAwMDAwXSBSZW1hcHBlZCAxMDMgcGFnZShzKSwgbGFzdF9wZm49Mzkz
MzE5DQpbICAgIDAuMDAwMDAwXSBSZWxlYXNlZCAwIHBhZ2UocykNClsgICAgMC4wMDAwMDBd
IGU4MjA6IEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBd
IFhlbjogW21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAwMDAwMDAwMDk4ZmZmXSB1c2Fi
bGUNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwMDAwOTk0MDAtMHgwMDAw
MDAwMDAwMGZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAw
MDAwMDAwMDEwMDAwMC0weDAwMDAwMDAwNjAwNjZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA2MDA2NzAwMC0weDAwMDAwMDAwOWZmOGZmZmZdIHVu
dXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDlmZjkwMDAwLTB4
MDAwMDAwMDA5ZmY5ZGZmZl0gQUNQSSBkYXRhDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0g
MHgwMDAwMDAwMDlmZjllMDAwLTB4MDAwMDAwMDA5ZmZkZmZmZl0gQUNQSSBOVlMNClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwOWZmZTAwMDAtMHgwMDAwMDAwMDlmZmZm
ZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmNjAw
MDAwMC0weDAwMDAwMDAwZjYwMDNmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46
IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQN
ClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVjMjAwMDAtMHgwMDAwMDAw
MGZlYzIwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAw
MDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAw
XSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVz
ZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAxMDAwMDAwMDAtMHgw
MDAwMDAwNTVmZmZmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwZmQwMDAwMDAwMC0weDAwMDAwMGZmZmZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAu
MDAwMDAwXSBib290Y29uc29sZSBbeGVuYm9vdDBdIGVuYWJsZWQNClsgICAgMC4wMDAwMDBd
IE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQ0KWyAgICAwLjAwMDAw
MF0gZTgyMDogdXNlci1kZWZpbmVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAw
XSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOThmZmZdIHVz
YWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwMDAwOTk0MDAtMHgw
MDAwMDAwMDAwMGZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAw
eDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDVmZmZmZmZmXSB1c2FibGUNClsgICAgMC4w
MDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDYwMDY3MDAwLTB4MDAwMDAwMDA5ZmY4ZmZm
Zl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDlmZjkw
MDAwLTB4MDAwMDAwMDA5ZmY5ZGZmZl0gQUNQSSBkYXRhDQpbICAgIDAuMDAwMDAwXSB1c2Vy
OiBbbWVtIDB4MDAwMDAwMDA5ZmY5ZTAwMC0weDAwMDAwMDAwOWZmZGZmZmZdIEFDUEkgTlZT
DQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDA5ZmZlMDAwMC0weDAwMDAw
MDAwOWZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAw
MDAwMDBmNjAwMDAwMC0weDAwMDAwMDAwZjYwMDNmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZWMwMDAwMC0weDAwMDAwMDAwZmVjMDBmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZWMyMDAw
MC0weDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBb
bWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlZmZmZmZdIHJlc2VydmVkDQpb
ICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZmUwMDAwMC0weDAwMDAwMDAw
ZmZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAw
MDEwMDAwMDAwMC0weDAwMDAwMDA1NWZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAw
XSB1c2VyOiBbbWVtIDB4MDAwMDAwZmQwMDAwMDAwMC0weDAwMDAwMGZmZmZmZmZmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBTTUJJT1MgMi41IHByZXNlbnQuDQpbICAgIDAuMDAw
MDAwXSBETUk6IE1TSSBNUy03NjQwLzg5MEZYQS1HRDcwIChNUy03NjQwKSAgLCBCSU9TIFYx
LjhCMSAwOS8xMy8yMDEwDQpbICAgIDAuMDAwMDAwXSBlODIwOiB1cGRhdGUgW21lbSAweDAw
MDAwMDAwLTB4MDAwMDBmZmZdIHVzYWJsZSA9PT4gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBd
IGU4MjA6IHJlbW92ZSBbbWVtIDB4MDAwYTAwMDAtMHgwMDBmZmZmZl0gdXNhYmxlDQpbICAg
IDAuMDAwMDAwXSBBR1A6IE5vIEFHUCBicmlkZ2UgZm91bmQNClsgICAgMC4wMDAwMDBdIGU4
MjA6IGxhc3RfcGZuID0gMHg2MDAwMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMA0KWyAg
ICAwLjAwMDAwMF0gU2Nhbm5pbmcgMSBhcmVhcyBmb3IgbG93IG1lbW9yeSBjb3JydXB0aW9u
DQpbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAw
MDkzMDAwXSA5MzAwMCBzaXplIDI0NTc2DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9t
YXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0NClsgICAgMC4wMDAwMDBdICBb
bWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0gaW5p
dF9tZW1vcnlfbWFwcGluZzogW21lbSAweDVmZTAwMDAwLTB4NWZmZmZmZmZdDQpbICAgIDAu
MDAwMDAwXSAgW21lbSAweDVmZTAwMDAwLTB4NWZmZmZmZmZdIHBhZ2UgNGsNClsgICAgMC4w
MDAwMDBdIEJSSyBbMHgwMzIwYjAwMCwgMHgwMzIwYmZmZl0gUEdUQUJMRQ0KWyAgICAwLjAw
MDAwMF0gQlJLIFsweDAzMjBjMDAwLCAweDAzMjBjZmZmXSBQR1RBQkxFDQpbICAgIDAuMDAw
MDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4NWMwMDAwMDAtMHg1ZmRmZmZmZl0N
ClsgICAgMC4wMDAwMDBdICBbbWVtIDB4NWMwMDAwMDAtMHg1ZmRmZmZmZl0gcGFnZSA0aw0K
WyAgICAwLjAwMDAwMF0gQlJLIFsweDAzMjBkMDAwLCAweDAzMjBkZmZmXSBQR1RBQkxFDQpb
ICAgIDAuMDAwMDAwXSBCUksgWzB4MDMyMGUwMDAsIDB4MDMyMGVmZmZdIFBHVEFCTEUNClsg
ICAgMC4wMDAwMDBdIEJSSyBbMHgwMzIwZjAwMCwgMHgwMzIwZmZmZl0gUEdUQUJMRQ0KWyAg
ICAwLjAwMDAwMF0gQlJLIFsweDAzMjEwMDAwLCAweDAzMjEwZmZmXSBQR1RBQkxFDQpbICAg
IDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAxMDAwMDAtMHg1YmZm
ZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAxMDAwMDAtMHg1YmZmZmZmZl0gcGFn
ZSA0aw0KWyAgICAwLjAwMDAwMF0gUkFNRElTSzogW21lbSAweDA0MDAwMDAwLTB4MDRmMzVm
ZmZdDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBFYXJseSB0YWJsZSBjaGVja3N1bSB2ZXJpZmlj
YXRpb24gZGlzYWJsZWQNClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMHgwMDAwMDAwMDAw
MEZCMTAwIDAwMDAxNCAodjAwIEFDUElBTSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFQg
MHgwMDAwMDAwMDlGRjkwMDAwIDAwMDA0OCAodjAxIE1TSSAgICBPRU1TTElDICAyMDEwMDkx
MyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUCAweDAwMDAwMDAw
OUZGOTAyMDAgMDAwMDg0ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAw
MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDB4MDAwMDAwMDA5RkY5MDVFMCAw
MDk0MjcgKHYwMSBBNzY0MCAgQTc2NDAxMDAgMDAwMDAxMDAgSU5UTCAyMDA1MTExNykNClsg
ICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMHgwMDAwMDAwMDlGRjlFMDAwIDAwMDA0MA0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogQVBJQyAweDAwMDAwMDAwOUZGOTAzOTAgMDAwMDg4ICh2MDEg
NzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBNQ0ZHIDB4MDAwMDAwMDA5RkY5MDQyMCAwMDAwM0MgKHYwMSA3NjQwTVMgT0VN
TUNGRyAgMjAxMDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNM
SUMgMHgwMDAwMDAwMDlGRjkwNDYwIDAwMDE3NiAodjAxIE1TSSAgICBPRU1TTElDICAyMDEw
MDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogT0VNQiAweDAwMDAw
MDAwOUZGOUUwNDAgMDAwMDcyICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQg
MDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTUkFUIDB4MDAwMDAwMDA5RkY5QTVF
MCAwMDAxMDggKHYwMyBBTUQgICAgRkFNX0ZfMTAgMDAwMDAwMDIgQU1EICAwMDAwMDAwMSkN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgMHgwMDAwMDAwMDlGRjlBNkYwIDAwMDAzOCAo
djAxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAw
MDAwMF0gQUNQSTogSVZSUyAweDAwMDAwMDAwOUZGOUE3MzAgMDAwMTEwICh2MDEgQU1EICAg
IFJEODkwUyAgIDAwMjAyMDMxIEFNRCAgMDAwMDAwMDApDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBTU0RUIDB4MDAwMDAwMDA5RkY5QTg0MCAwMDBEQTQgKHYwMSBBIE0gSSAgUE9XRVJOT1cg
MDAwMDAwMDEgQU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQ
SUMgYWRkcmVzcyAweGZlZTAwMDAwDQpbICAgIDAuMDAwMDAwXSBOVU1BIHR1cm5lZCBvZmYN
ClsgICAgMC4wMDAwMDBdIEZha2luZyBhIG5vZGUgYXQgW21lbSAweDAwMDAwMDAwMDAwMDAw
MDAtMHgwMDAwMDAwMDVmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gTk9ERV9EQVRBKDApIGFs
bG9jYXRlZCBbbWVtIDB4NWZkMTYwMDAtMHg1ZmQyMGZmZl0NClsgICAgMC4wMDAwMDBdIFpv
bmUgcmFuZ2VzOg0KWyAgICAwLjAwMDAwMF0gICBETUEgICAgICBbbWVtIDB4MDAwMDEwMDAt
MHgwMGZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAgW21lbSAweDAxMDAwMDAw
LTB4ZmZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5vcm1hbCAgIGVtcHR5DQpbICAgIDAu
MDAwMDAwXSBNb3ZhYmxlIHpvbmUgc3RhcnQgZm9yIGVhY2ggbm9kZQ0KWyAgICAwLjAwMDAw
MF0gRWFybHkgbWVtb3J5IG5vZGUgcmFuZ2VzDQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAw
OiBbbWVtIDB4MDAwMDEwMDAtMHgwMDA5OGZmZl0NClsgICAgMC4wMDAwMDBdICAgbm9kZSAg
IDA6IFttZW0gMHgwMDEwMDAwMC0weDVmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gSW5pdG1l
bSBzZXR1cCBub2RlIDAgW21lbSAweDAwMDAxMDAwLTB4NWZmZmZmZmZdDQpbICAgIDAuMDAw
MDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczogMzkzMTEyDQpbICAgIDAuMDAwMDAwXSAgIERN
QSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBtZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1B
IHpvbmU6IDIxIHBhZ2VzIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAz
OTkyIHBhZ2VzLCBMSUZPIGJhdGNoOjANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTog
NjA4MCBwYWdlcyB1c2VkIGZvciBtZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9u
ZTogMzg5MTIwIHBhZ2VzLCBMSUZPIGJhdGNoOjMxDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBQ
TS1UaW1lciBJTyBQb3J0OiAweDgwOA0KWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJ
QyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5h
YmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGlj
X2lkWzB4MDNdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lf
YmFzZVswXSkNClsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9u
IDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRdKQ0K
WyAgICAwLjAwMDAwMF0gSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJl
c3MgMHhmZWMyMDAwMCwgR1NJIDI0LTU1DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JD
X09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KWyAgICAwLjAw
MDAwMF0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkg
bG93IGxldmVsKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRl
Lg0KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0KWyAgICAw
LjAwMDAwMF0gVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9y
bWF0aW9uDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhm
ZWQwMDAwMA0KWyAgICAwLjAwMDAwMF0gc21wYm9vdDogQWxsb3dpbmcgNiBDUFVzLCAwIGhv
dHBsdWcgQ1BVcw0KWyAgICAwLjAwMDAwMF0gZTgyMDogW21lbSAweGEwMDAwMDAwLTB4ZjVm
ZmZmZmZdIGF2YWlsYWJsZSBmb3IgUENJIGRldmljZXMNClsgICAgMC4wMDAwMDBdIEJvb3Rp
bmcgcGFyYXZpcnR1YWxpemVkIGtlcm5lbCBvbiBYZW4NClsgICAgMC4wMDAwMDBdIFhlbiB2
ZXJzaW9uOiA0LjUuMC1yYyAocHJlc2VydmUtQUQpDQpbICAgIDAuMDAwMDAwXSBzZXR1cF9w
ZXJjcHU6IE5SX0NQVVM6OCBucl9jcHVtYXNrX2JpdHM6OCBucl9jcHVfaWRzOjYgbnJfbm9k
ZV9pZHM6MQ0KWyAgICAwLjAwMDAwMF0gUEVSQ1BVOiBFbWJlZGRlZCAzMCBwYWdlcy9jcHUg
QGZmZmY4ODAwNWY2MDAwMDAgczgyNTYwIHI4MTkyIGQzMjEyOCB1MjYyMTQ0DQpbICAgIDAu
MDAwMDAwXSBwY3B1LWFsbG9jOiBzODI1NjAgcjgxOTIgZDMyMTI4IHUyNjIxNDQgYWxsb2M9
MSoyMDk3MTUyDQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBbMF0gMCAxIDIgMyA0IDUg
LSAtIA0KWyAgICAwLjAwMDAwMF0geGVuOiBQViBzcGlubG9ja3MgZW5hYmxlZA0KWyAgICAw
LjAwMDAwMF0gQnVpbHQgMSB6b25lbGlzdHMgaW4gTm9kZSBvcmRlciwgbW9iaWxpdHkgZ3Jv
dXBpbmcgb24uICBUb3RhbCBwYWdlczogMzg2OTQ3DQpbICAgIDAuMDAwMDAwXSBQb2xpY3kg
em9uZTogRE1BMzINClsgICAgMC4wMDAwMDBdIEtlcm5lbCBjb21tYW5kIGxpbmU6IHJvb3Q9
L2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtcm9vdCBybyB2ZXJib3NlIGVhcmx5cHJpbnRr
PXhlbiBtZW09MTUzNk0gY29uc29sZT1odmMwIGNvbnNvbGU9dHR5MCB2Z2E9Nzk0IHZpZGVv
PXZlc2FmYiByODE2OS51c2VfZGFjPTEgYWNwaV9lbmZvcmNlX3Jlc291cmNlcz1sYXggbWF4
X2xvb3A9MzAgbG9vcF9tYXhfcGFydD0xMCBkZWJ1ZyBsb2dsZXZlbD0xMCBub21vZGVzZXQg
eGVuLXBjaWJhY2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAuKikoMDc6MDAuKikoMDg6MDAuKiko
MDk6MDAuKikoMGE6MDAuMCkoMGI6MDAuMCkoMGU6MDAuKikgcjgxNjkudXNlX2RhYz0xIGFj
cGkuZGVidWdfbGF5ZXI9MHg0MDAwMDAgYWNwaS5kZWJ1Z19sZXZlbD0weDQNClsgICAgMC4w
MDAwMDBdIFBJRCBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBi
eXRlcykNClsgICAgMC4wMDAwMDBdIHNvZnR3YXJlIElPIFRMQiBbbWVtIDB4NTljMDAwMDAt
MHg1ZGMwMDAwMF0gKDY0TUIpIG1hcHBlZCBhdCBbZmZmZjg4MDA1OWMwMDAwMC1mZmZmODgw
MDVkYmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gTWVtb3J5OiAxNDI0MTkySy8xNTcyNDQ4SyBh
dmFpbGFibGUgKDExOTIwSyBrZXJuZWwgY29kZSwgMTA0M0sgcndkYXRhLCA0NDk2SyByb2Rh
dGEsIDExMDRLIGluaXQsIDE0MTc2SyBic3MsIDE0ODI1NksgcmVzZXJ2ZWQpDQpbICAgIDAu
MDAwMDAwXSBTTFVCOiBIV2FsaWduPTY0LCBPcmRlcj0wLTMsIE1pbk9iamVjdHM9MCwgQ1BV
cz02LCBOb2Rlcz0xDQpbICAgIDAuMDAwMDAwXSBIaWVyYXJjaGljYWwgUkNVIGltcGxlbWVu
dGF0aW9uLg0KWyAgICAwLjAwMDAwMF0gCVJDVSBkeW50aWNrLWlkbGUgZ3JhY2UtcGVyaW9k
IGFjY2VsZXJhdGlvbiBpcyBlbmFibGVkLg0KWyAgICAwLjAwMDAwMF0gCUFkZGl0aW9uYWwg
cGVyLUNQVSBpbmZvIHByaW50ZWQgd2l0aCBzdGFsbHMuDQpbICAgIDAuMDAwMDAwXSAJUkNV
IHJlc3RyaWN0aW5nIENQVXMgZnJvbSBOUl9DUFVTPTggdG8gbnJfY3B1X2lkcz02Lg0KWyAg
ICAwLjAwMDAwMF0gUkNVOiBBZGp1c3RpbmcgZ2VvbWV0cnkgZm9yIHJjdV9mYW5vdXRfbGVh
Zj0xNiwgbnJfY3B1X2lkcz02DQpbICAgIDAuMDAwMDAwXSBOUl9JUlFTOjQzNTIgbnJfaXJx
czoxMDE2IDANClsgICAgMC4wMDAwMDBdIHhlbjpldmVudHM6IFVzaW5nIEZJRk8tYmFzZWQg
QUJJDQpbICAgIDAuMDAwMDAwXSB4ZW46IHNjaSBvdmVycmlkZTogZ2xvYmFsX2lycT05IHRy
aWdnZXI9MCBwb2xhcml0eT0xDQpbICAgIDAuMDAwMDAwXSB4ZW46IHJlZ2lzdGVyaW5nIGdz
aSA5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBw
aXJxPTkgLT4gaXJxPTkgKGdzaT05KQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MTcuNzY4
XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi05IC0+IDB4NjAgLT4gSVJR
IDkgTW9kZToxIEFjdGl2ZToxKQ0KWyAgICAwLjAwMDAwMF0geGVuOiBhY3BpIHNjaSA5DQpb
ICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTEgLT4gaXJxPTEgKGdzaT0xKQ0KWyAgICAw
LjAwMDAwMF0geGVuOiAtLT4gcGlycT0yIC0+IGlycT0yIChnc2k9MikNClsgICAgMC4wMDAw
MDBdIHhlbjogLS0+IHBpcnE9MyAtPiBpcnE9MyAoZ3NpPTMpDQpbICAgIDAuMDAwMDAwXSB4
ZW46IC0tPiBwaXJxPTQgLT4gaXJxPTQgKGdzaT00KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAt
LT4gcGlycT01IC0+IGlycT01IChnc2k9NSkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBp
cnE9NiAtPiBpcnE9NiAoZ3NpPTYpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTcg
LT4gaXJxPTcgKGdzaT03KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT04IC0+IGly
cT04IChnc2k9OCkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTAgLT4gaXJxPTEw
IChnc2k9MTApDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTExIC0+IGlycT0xMSAo
Z3NpPTExKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMiAtPiBpcnE9MTIgKGdz
aT0xMikNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTMgLT4gaXJxPTEzIChnc2k9
MTMpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTE0IC0+IGlycT0xNCAoZ3NpPTE0
KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNSAtPiBpcnE9MTUgKGdzaT0xNSkN
ClsgICAgMC4wMDAwMDBdIENvbnNvbGU6IGNvbG91ciBkdW1teSBkZXZpY2UgODB4MjUNClsg
ICAgMC4wMDAwMDBdIGNvbnNvbGUgW3R0eTBdIGVuYWJsZWQNClsgICAgMC4wMDAwMDBdIGJv
b3Rjb25zb2xlIFt4ZW5ib290MF0gZGlzYWJsZWQNClsgICAgMC4wMDAwMDBdIEluaXRpYWxp
emluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldA0KWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5n
IGNncm91cCBzdWJzeXMgY3B1DQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3Vw
IHN1YnN5cyBjcHVhY2N0DQpbICAgIDAuMDAwMDAwXSBMaW51eCB2ZXJzaW9uIDMuMTguMC1y
YzUtMjAxNDExMTYtdmFuaWxsYSAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkgKGdjYyB2ZXJzaW9u
IDQuNy4yIChEZWJpYW4gNC43LjItNSkgKSAjMSBTTVAgVHVlIE5vdiAxOCAxMDoxODoyMyBD
RVQgMjAxNA0KWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiByb290PS9kZXYvbWFwcGVy
L3NlcnZlZXJzdGVydGplLXJvb3Qgcm8gdmVyYm9zZSBlYXJseXByaW50az14ZW4gbWVtPTE1
MzZNIGNvbnNvbGU9aHZjMCBjb25zb2xlPXR0eTAgdmdhPTc5NCB2aWRlbz12ZXNhZmIgcjgx
NjkudXNlX2RhYz0xIGFjcGlfZW5mb3JjZV9yZXNvdXJjZXM9bGF4IG1heF9sb29wPTMwIGxv
b3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9MTAgbm9tb2Rlc2V0IHhlbi1wY2liYWNr
LmhpZGU9KDAzOjA2LjApKDA0OjAwLiopKDA3OjAwLiopKDA4OjAwLiopKDA5OjAwLiopKDBh
OjAwLjApKDBiOjAwLjApKDBlOjAwLiopIHI4MTY5LnVzZV9kYWM9MSBhY3BpLmRlYnVnX2xh
eWVyPTB4NDAwMDAwIGFjcGkuZGVidWdfbGV2ZWw9MHg0DQpbICAgIDAuMDAwMDAwXSB0c2Vn
OiAwMDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBTZXQgMTI4OTc1MDYzIHBhZ2UocykgdG8g
MS0xIG1hcHBpbmcNClsgICAgMC4wMDAwMDBdIFJlbWFwcGVkIDEwMyBwYWdlKHMpLCBsYXN0
X3Bmbj0zOTMzMTkNClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDAgcGFnZShzKQ0KWyAgICAw
LjAwMDAwMF0gZTgyMDogQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAw
LjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOThm
ZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDA5OTQw
MC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFtt
ZW0gMHgwMDAwMDAwMDAwMTAwMDAwLTB4MDAwMDAwMDA2MDA2NmZmZl0gdXNhYmxlDQpbICAg
IDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDYwMDY3MDAwLTB4MDAwMDAwMDA5ZmY4
ZmZmZl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwOWZm
OTAwMDAtMHgwMDAwMDAwMDlmZjlkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIFhl
bjogW21lbSAweDAwMDAwMDAwOWZmOWUwMDAtMHgwMDAwMDAwMDlmZmRmZmZmXSBBQ1BJIE5W
Uw0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA5ZmZlMDAwMC0weDAwMDAw
MDAwOWZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAw
MDAwMGY2MDAwMDAwLTB4MDAwMDAwMDBmNjAwM2ZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSBy
ZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWMyMDAwMC0w
eDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0g
MHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBmZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZm
ZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDEwMDAw
MDAwMC0weDAwMDAwMDA1NWZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46
IFttZW0gMHgwMDAwMDBmZDAwMDAwMDAwLTB4MDAwMDAwZmZmZmZmZmZmZl0gcmVzZXJ2ZWQN
ClsgICAgMC4wMDAwMDBdIGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAw
LjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHg2MDAwMDAwMC0weGZmZmZmZmZmZmZmZmZm
ZmVdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVj
dGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAwXSBlODIwOiB1c2VyLWRlZmluZWQgcGh5c2lj
YWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDAw
MDAwLTB4MDAwMDAwMDAwMDA5OGZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBb
bWVtIDB4MDAwMDAwMDAwMDA5OTQwMC0weDAwMDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpb
ICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAwMDAw
NWZmZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAw
NjAwNjcwMDAtMHgwMDAwMDAwMDlmZjhmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0g
dXNlcjogW21lbSAweDAwMDAwMDAwOWZmOTAwMDAtMHgwMDAwMDAwMDlmZjlkZmZmXSBBQ1BJ
IGRhdGENClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDlmZjllMDAwLTB4
MDAwMDAwMDA5ZmZkZmZmZl0gQUNQSSBOVlMNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0g
MHgwMDAwMDAwMDlmZmUwMDAwLTB4MDAwMDAwMDA5ZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGY2MDAwMDAwLTB4MDAwMDAwMDBmNjAw
M2ZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZl
YzAwMDAwLTB4MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVz
ZXI6IFttZW0gMHgwMDAwMDAwMGZlYzIwMDAwLTB4MDAwMDAwMDBmZWMyMGZmZl0gcmVzZXJ2
ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAw
MDAwMDBmZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgw
MDAwMDAwMGZmZTAwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4w
MDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMTAwMDAwMDAwLTB4MDAwMDAwMDU1ZmZmZmZm
Zl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDBmZDAwMDAw
MDAwLTB4MDAwMDAwZmZmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFNNQklP
UyAyLjUgcHJlc2VudC4NClsgICAgMC4wMDAwMDBdIERNSTogTVNJIE1TLTc2NDAvODkwRlhB
LUdENzAgKE1TLTc2NDApICAsIEJJT1MgVjEuOEIxIDA5LzEzLzIwMTANClsgICAgMC4wMDAw
MDBdIGU4MjA6IHVwZGF0ZSBbbWVtIDB4MDAwMDAwMDAtMHgwMDAwMGZmZl0gdXNhYmxlID09
PiByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gZTgyMDpbICAgMTUuNTUzOTA1XSBwY2liYWNr
IDAwMDA6MDg6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHgzYyAo
d2FzIDB4MTAwLCB3cml0aW5nIDB4MTA3KQ0KWyAgIDE1LjU1NDE0OV0gcGNpYmFjayAwMDAw
OjA4OjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4MTAgKHdhcyAw
eDQsIHdyaXRpbmcgMHhmZTBmZTAwNCkNClsgICAxNS41NTQzNzhdIHBjaWJhY2sgMDAwMDow
ODowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweGMgKHdhcyAweDAs
IHdyaXRpbmcgMHgxMCkNClsgICAxNS41NTQ1OTNdIHBjaWJhY2sgMDAwMDowODowMC4wOiBy
ZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweDQgKHdhcyAweDEwMDAwMCwgd3Jp
dGluZyAweDEwMDEwMikNClsgICAxNS41NTQ5NDNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDMz
IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTUuNTU1MDg5XSB4ZW46IC0tPiBwaXJx
PTMzIC0+IGlycT0zMyAoZ3NpPTMzKQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MjAuNzM3
XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy05IC0+IDB4YTkgLT4gSVJR
IDMzIE1vZGU6MSBBY3RpdmU6MSkNClsgICAxNS41ODA2NjVdIHBjaWJhY2sgMDAwMDowOTow
MC4wOiBlbmFibGluZyBkZXZpY2UgKDAwMDAgLT4gMDAwMykNClsgICAxNS41ODA4NDNdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDMyIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTUu
NTgwOTg5XSB4ZW46IC0tPiBwaXJxPTMyIC0+IGlycT0zMiAoZ3NpPTMyKQ0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NDU6MjAuNzYyXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy04IC0+IDB4YjEgLT4gSVJRIDMyIE1vZGU6MSBBY3RpdmU6MSkNClsgICAxNS42MDcy
NjZdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDQ3IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpb
ICAgMTUuNjA3NDE1XSB4ZW46IC0tPiBwaXJxPTQ3IC0+IGlycT00NyAoZ3NpPTQ3KQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NDU6MjAuNzg5XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNy0yMyAtPiAweGI5IC0+IElSUSA0NyBNb2RlOjEgQWN0aXZlOjEpDQpbICAg
MTYuNjE3Mjc1XSBwY2liYWNrIDAwMDA6MGE6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFj
ZSBhdCBvZmZzZXQgMHgzYyAod2FzIDB4MTAwLCB3cml0aW5nIDB4MTBhKQ0KWyAgIDE2LjYx
NzUyMV0gcGNpYmFjayAwMDAwOjBhOjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQg
b2Zmc2V0IDB4MTAgKHdhcyAweDQsIHdyaXRpbmcgMHhmZTIwMDAwNCkNClsgICAxNi42MTc3
NTRdIHBjaWJhY2sgMDAwMDowYTowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9m
ZnNldCAweGMgKHdhcyAweDAsIHdyaXRpbmcgMHgxMCkNClsgICAxNi42MTc5NjldIHBjaWJh
Y2sgMDAwMDowYTowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweDQg
KHdhcyAweDEwMDAwMCwgd3JpdGluZyAweDEwMDEwNikNClsgICAxNi42MjQ1OTVdIHhlbjog
cmVnaXN0ZXJpbmcgZ3NpIDQ4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTYuNjMx
MDg3XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjQ4DQpbICAgMTcuNjQ3MTcxXSBwY2liYWNr
IDAwMDA6MGI6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHgzYyAo
d2FzIDB4MTAwLCB3cml0aW5nIDB4MTBhKQ0KWyAgIDE3LjY1Mzg4Nl0gcGNpYmFjayAwMDAw
OjBiOjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4MTAgKHdhcyAw
eDQsIHdyaXRpbmcgMHhmZTVmZTAwNCkNClsgICAxNy42NjA1MTNdIHBjaWJhY2sgMDAwMDow
YjowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweGMgKHdhcyAweDAs
IHdyaXRpbmcgMHgxMCkNClsgICAxNy42NjcxMTBdIHBjaWJhY2sgMDAwMDowYjowMC4wOiBy
ZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweDQgKHdhcyAweDEwMDAwMCwgd3Jp
dGluZyAweDEwMDEwMikNClsgICAxNy42NzM4MDhdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDI5
IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTcuNjgwMzkyXSB4ZW46IC0tPiBwaXJx
PTI5IC0+IGlycT0yOSAoZ3NpPTI5KQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MjIuODY4
XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy01IC0+IDB4YzEgLT4gSVJR
IDI5IE1vZGU6MSBBY3RpdmU6MSkNClsgICAxNy43MTA2NzJdIHBjaWJhY2sgMDAwMDowZTow
MC4wOiBlbmFibGluZyBkZXZpY2UgKDAwMDAgLT4gMDAwMykNClsgICAxNy43MTczMThdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDI4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTcu
NzIzOTY2XSB4ZW46IC0tPiBwaXJxPTI4IC0+IGlycT0yOCAoZ3NpPTI4KQ0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NDU6MjIuOTEyXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy00IC0+IDB4YzkgLT4gSVJRIDI4IE1vZGU6MSBBY3RpdmU6MSkNClsgICAxNy43NTc1
NTFdIHhlbl9wY2liYWNrOiBiYWNrZW5kIGlzIHZwY2kNClsgICAxNy43NjQ1MjddIHhlbl9h
Y3BpX3Byb2Nlc3NvcjogVXBsb2FkaW5nIFhlbiBwcm9jZXNzb3IgUE0gaW5mbw0KWyAgIDE3
Ljc3MjQ3M10gU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJp
bmcgZW5hYmxlZA0KWyAgIDE3Ljc4MDI4NF0gaHBldF9hY3BpX2FkZDogbm8gYWRkcmVzcyBv
ciBpcnFzIGluIF9DUlMNClsgICAxNy43ODcxNjRdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNl
IHYwLjEwMw0KWyAgIDE3Ljc5NDIyM10gSGFuZ2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sg
dGltZXIgMC45LjEgKHRpY2sgaXMgMTgwIHNlY29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRz
KS4NClsgICAxNy44MDA5MTFdIFtkcm1dIEluaXRpYWxpemVkIGRybSAxLjEuMCAyMDA2MDgx
MA0KWyAgIDE3LjgwNzUyNV0gW2RybV0gVkdBQ09OIGRpc2FibGUgcmFkZW9uIGtlcm5lbCBt
b2Rlc2V0dGluZy4NClsgICAxNy44MTQwODhdIFtkcm06cmFkZW9uX2luaXRdICpFUlJPUiog
Tm8gVU1TIHN1cHBvcnQgaW4gcmFkZW9uIG1vZHVsZSENClsgICAxNy44MjM5NTRdIGJyZDog
bW9kdWxlIGxvYWRlZA0KWyAgIDE3LjgzODY2NV0gbG9vcDogbW9kdWxlIGxvYWRlZA0KWyAg
IDE3Ljg0NTYwN10gYWhjaSAwMDAwOjAwOjExLjA6IHZlcnNpb24gMy4wDQpbICAgMTcuODUy
MjM1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0K
WyAgIDE3Ljg1ODY5MV0geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkNCihY
RU4pIFsyMDE0LTExLTE4IDIxOjQ1OjIzLjA0Nl0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDYtMTkgLT4gMHhkMSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQ0KWyAg
IDE3Ljg2NTMxN10gYWhjaSAwMDAwOjAwOjExLjA6IEFIQ0kgMDAwMS4wMjAwIDMyIHNsb3Rz
IDYgcG9ydHMgNiBHYnBzIDB4M2YgaW1wbCBTQVRBIG1vZGUNClsgICAxNy44NzE3NzFdIGFo
Y2kgMDAwMDowMDoxMS4wOiBmbGFnczogNjRiaXQgbmNxIHNudGYgaWxjayBwbSBsZWQgY2xv
IHBtcCBwaW8gc2x1bSBwYXJ0IA0KWyAgIDE3Ljg4MDY1N10gc2NzaSBob3N0MDogYWhjaQ0K
WyAgIDE3Ljg4NzU3Ml0gc2NzaSBob3N0MTogYWhjaQ0KWyAgIDE3Ljg5NDEyNl0gc2NzaSBo
b3N0MjogYWhjaQ0KWyAgIDE3LjkwMDUxOV0gc2NzaSBob3N0MzogYWhjaQ0KWyAgIDE3Ljkw
Njg5NF0gc2NzaSBob3N0NDogYWhjaQ0KWyAgIDE3LjkxMzI3OF0gc2NzaSBob3N0NTogYWhj
aQ0KWyAgIDE3LjkxOTI0Ml0gYXRhMTogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAw
eGZkYmZmMDAwIHBvcnQgMHhmZGJmZjEwMCBpcnEgMTE0DQpbICAgMTcuOTI1MjcyXSBhdGEy
OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmRiZmYwMDAgcG9ydCAweGZkYmZm
MTgwIGlycSAxMTUNClsgICAxNy45MzExNzJdIGF0YTM6IFNBVEEgbWF4IFVETUEvMTMzIGFi
YXIgbTEwMjRAMHhmZGJmZjAwMCBwb3J0IDB4ZmRiZmYyMDAgaXJxIDExNg0KWyAgIDE3Ljkz
NjkxM10gYXRhNDogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGZkYmZmMDAwIHBv
cnQgMHhmZGJmZjI4MCBpcnEgMTE3DQpbICAgMTcuOTQyNjgxXSBhdGE1OiBTQVRBIG1heCBV
RE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmRiZmYwMDAgcG9ydCAweGZkYmZmMzAwIGlycSAxMTgN
ClsgICAxNy45NDgzNzFdIGF0YTY6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhm
ZGJmZjAwMCBwb3J0IDB4ZmRiZmYzODAgaXJxIDExOQ0KWyAgIDE3Ljk1NDEzNl0gdHVuOiBV
bml2ZXJzYWwgVFVOL1RBUCBkZXZpY2UgZHJpdmVyLCAxLjYNClsgICAxNy45NTk2NzVdIHR1
bjogKEMpIDE5OTktMjAwNCBNYXggS3Jhc255YW5za3kgPG1heGtAcXVhbGNvbW0uY29tPg0K
WyAgIDE3Ljk2NTM5MF0gZTEwMDA6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgRHJpdmVy
IC0gdmVyc2lvbiA3LjMuMjEtazgtTkFQSQ0KWyAgIDE3Ljk3MTAyMV0gZTEwMDA6IENvcHly
aWdodCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBvcmF0aW9uLg0KWyAgIDE3Ljk3NjY3Nl0g
ZTEwMDBlOiBJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIDIuMy4yLWsNClsg
ICAxNy45ODIyMzVdIGUxMDAwZTogQ29weXJpZ2h0KGMpIDE5OTkgLSAyMDE0IEludGVsIENv
cnBvcmF0aW9uLg0KWyAgIDE3Ljk4Nzg3MV0gaWdiOiBJbnRlbChSKSBHaWdhYml0IEV0aGVy
bmV0IE5ldHdvcmsgRHJpdmVyIC0gdmVyc2lvbiA1LjIuMTUtaw0KWyAgIDE3Ljk5MzUzNV0g
aWdiOiBDb3B5cmlnaHQgKGMpIDIwMDctMjAxNCBJbnRlbCBDb3Jwb3JhdGlvbi4NClsgICAx
Ny45OTkyOTldIGlnYnZmOiBJbnRlbChSKSBHaWdhYml0IFZpcnR1YWwgRnVuY3Rpb24gTmV0
d29yayBEcml2ZXIgLSB2ZXJzaW9uIDIuMC4yLWsNClsgICAxOC4wMDUwNTBdIGlnYnZmOiBD
b3B5cmlnaHQgKGMpIDIwMDkgLSAyMDEyIEludGVsIENvcnBvcmF0aW9uLg0KWyAgIDE4LjAx
MDg1MV0gcjgxNjkgR2lnYWJpdCBFdGhlcm5ldCBkcml2ZXIgMi4zTEstTkFQSSBsb2FkZWQN
ClsgICAxOC4wMTY2NDNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDQ2IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgMTguMDIyMzk5XSB4ZW46IC0tPiBwaXJxPTQ2IC0+IGlycT00NiAo
Z3NpPTQ2KQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NDU6MjMuMjA5XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMiAtPiAweDVhIC0+IElSUSA0NiBNb2RlOjEgQWN0
aXZlOjEpDQpbICAgMTguMDI4MTIzXSByODE2OSAwMDAwOjBkOjAwLjA6IGVuYWJsaW5nIE1l
bS1Xci1JbnZhbA0KWyAgIDE4LjAzNDMyN10gcjgxNjkgMDAwMDowZDowMC4wIGV0aDA6IFJU
TDgxNjhkLzgxMTFkIGF0IDB4ZmZmZmM5MDAwMDM2NDAwMCwgNDA6NjE6ODY6ZjQ6Njc6ZDks
IFhJRCAwODEwMDBjMCBJUlEgMTIyDQpbICAgMTguMDQwMjY3XSByODE2OSAwMDAwOjBkOjAw
LjAgZXRoMDoganVtYm8gZmVhdHVyZXMgW2ZyYW1lczogOTIwMCBieXRlcywgdHggY2hlY2tz
dW1taW5nOiBrb10NClsgICAxOC4wNDYyMThdIHI4MTY5IEdpZ2FiaXQgRXRoZXJuZXQgZHJp
dmVyIDIuM0xLLU5BUEkgbG9hZGVkDQpbICAgMTguMDUyMTU1XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSA1MSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgIDE4LjA1ODA3Ml0geGVuOiAt
LT4gcGlycT01MSAtPiBpcnE9NTEgKGdzaT01MSkNCihYRU4pIFsyMDE0LTExLTE4IDIxOjQ1
OjIzLjI0NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjcgLT4gMHg2
YSAtPiBJUlEgNTEgTW9kZToxIEFjdGl2ZToxKQ0KWyAgIDE4LjA2NDAzNl0gcjgxNjkgMDAw
MDowYzowMC4wOiBlbmFibGluZyBNZW0tV3ItSW52YWwNClsgICAxOC4wNzAyNjddIHI4MTY5
IDAwMDA6MGM6MDAuMCBldGgxOiBSVEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMDAzNjYw
MDAsIDQwOjYxOjg2OmY0OjY3OmQ4LCBYSUQgMDgxMDAwYzAgSVJRIDEyMw0KWyAgIDE4LjA3
NjMxMl0gcjgxNjkgMDAwMDowYzowMC4wIGV0aDE6IGp1bWJvIGZlYXR1cmVzIFtmcmFtZXM6
IDkyMDAgYnl0ZXMsIHR4IGNoZWNrc3VtbWluZzoga29dDQpbICAgMTguMDgyMzYzXSB4ZW5f
bmV0ZnJvbnQ6IEluaXRpYWxpc2luZyBYZW4gdmlydHVhbCBldGhlcm5ldCBkcml2ZXINClsg
ICAxOC4wODg4MTldIGVoY2lfaGNkOiBVU0IgMi4wICdFbmhhbmNlZCcgSG9zdCBDb250cm9s
bGVyIChFSENJKSBEcml2ZXINClsgICAxOC4wOTQ5MDZdIGVoY2ktcGNpOiBFSENJIFBDSSBw
bGF0Zm9ybSBkcml2ZXINClsgICAxOC4xMDEyMDNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE3
IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguMTA3MjIyXSBBbHJlYWR5IHNldHVw
IHRoZSBHU0kgOjE3DQpbICAgMTguMTEzMjY2XSBRVUlSSzogRW5hYmxlIEFNRCBQTEwgZml4
DQpbICAgMTguMTE5MjMzXSBlaGNpLXBjaSAwMDAwOjAwOjEyLjI6IGVuYWJsaW5nIGJ1cyBt
YXN0ZXJpbmcNClsgICAxOC4xMjUyODBdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogRUhDSSBI
b3N0IENvbnRyb2xsZXINClsgICAxOC4xMzE1NjldIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjog
bmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxDQpbICAgMTgu
MTM3NTczXSBlaGNpLXBjaSAwMDAwOjAwOjEyLjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgw
MC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZA0KWyAgIDE4LjE0MzY4NV0g
ZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBkZWJ1ZyBwb3J0IDENClsgICAxOC4xNDk4MjFdIGVo
Y2ktcGNpIDAwMDA6MDA6MTIuMjogZW5hYmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTguMTU1
NzYzXSBlaGNpLXBjaSAwMDAwOjAwOjEyLjI6IGlycSAxNywgaW8gbWVtIDB4ZmRiZmY0MDAN
ClsgICAxOC4xNzA1OTddIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogVVNCIDIuMCBzdGFydGVk
LCBFSENJIDEuMDANClsgICAxOC4xNzY1ODVdIHVzYiB1c2IxOiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINClsgICAxOC4xODIzODVdIHVz
YiB1c2IxOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJp
YWxOdW1iZXI9MQ0KWyAgIDE4LjE4ODE1NV0gdXNiIHVzYjE6IFByb2R1Y3Q6IEVIQ0kgSG9z
dCBDb250cm9sbGVyDQpbICAgMTguMTkzODYwXSB1c2IgdXNiMTogTWFudWZhY3R1cmVyOiBM
aW51eCAzLjE4LjAtcmM1LTIwMTQxMTE2LXZhbmlsbGEgZWhjaV9oY2QNClsgICAxOC4xOTk2
MzFdIHVzYiB1c2IxOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTIuMg0KWyAgIDE4LjIwNTk2
Ml0gaHViIDEtMDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAxOC4yMTE3NjNdIGh1YiAxLTA6
MS4wOiA1IHBvcnRzIGRldGVjdGVkDQpbICAgMTguMjE4MDc1XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgIDE4LjIyMzg2OF0gQWxyZWFk
eSBzZXR1cCB0aGUgR1NJIDoxNw0KWyAgIDE4LjIyOTU5M10gZWhjaS1wY2kgMDAwMDowMDox
My4yOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQpbICAgMTguMjM1MzQwXSBlaGNpLXBjaSAw
MDAwOjAwOjEzLjI6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgMTguMjQxMTA2XSBlaGNp
LXBjaSAwMDAwOjAwOjEzLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1
cyBudW1iZXIgMg0KWyAgIDE4LjI0Njg1Ml0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBhcHBs
eWluZyBBTUQgU0I3MDAvU0I4MDAvSHVkc29uLTIvMyBFSENJIGR1bW15IHFoIHdvcmthcm91
bmQNClsgICAxOC4yNTI3NjJdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogZGVidWcgcG9ydCAx
DQpbICAgMTguMjU4NzgwXSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IGVuYWJsaW5nIE1lbS1X
ci1JbnZhbA0KWyAgIDE4LjI2NDgwOF0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBpcnEgMTcs
IGlvIG1lbSAweGZkYmZmODAwDQpbICAgMTguMjczODk0XSBhdGE1OiBTQVRBIGxpbmsgZG93
biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkNClsgICAxOC4yODAxNjRdIGF0YTY6IFNBVEEg
bGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQ0KWyAgIDE4LjI4MDQ0MF0gZWhj
aS1wY2kgMDAwMDowMDoxMy4yOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMA0KWyAgIDE4
LjI4MDUyNV0gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZi
LCBpZFByb2R1Y3Q9MDAwMg0KWyAgIDE4LjI4MDUyNl0gdXNiIHVzYjI6IE5ldyBVU0IgZGV2
aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgMTgu
MjgwNTI3XSB1c2IgdXNiMjogUHJvZHVjdDogRUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAx
OC4yODA1MjhdIHVzYiB1c2IyOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMTguMC1yYzUtMjAx
NDExMTYtdmFuaWxsYSBlaGNpX2hjZA0KWyAgIDE4LjI4MDUyOV0gdXNiIHVzYjI6IFNlcmlh
bE51bWJlcjogMDAwMDowMDoxMy4yDQpbICAgMTguMjgwODE1XSBodWIgMi0wOjEuMDogVVNC
IGh1YiBmb3VuZA0KWyAgIDE4LjI4MDgyNV0gaHViIDItMDoxLjA6IDUgcG9ydHMgZGV0ZWN0
ZWQNClsgICAxOC4yODEyNTFdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcg
MCBwb2xhcml0eSAxDQpbICAgMTguMjgxMjUzXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3
DQpbICAgMTguMjgxMjc2XSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGVuYWJsaW5nIGJ1cyBt
YXN0ZXJpbmcNClsgICAxOC4yODEzMDNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogRUhDSSBI
b3N0IENvbnRyb2xsZXINClsgICAxOC4yODE0NjJdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjog
bmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAzDQpbICAgMTgu
MjgxNDc3XSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgw
MC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZA0KWyAgIDE4LjI4MTQ5N10g
ZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBkZWJ1ZyBwb3J0IDENClsgICAxOC4yODE1NzVdIGVo
Y2ktcGNpIDAwMDA6MDA6MTYuMjogZW5hYmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTguMjgx
NTg0XSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGlycSAxNywgaW8gbWVtIDB4ZmRiZmZjMDAN
ClsgICAxOC4yOTA0NDFdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogVVNCIDIuMCBzdGFydGVk
LCBFSENJIDEuMDANClsgICAxOC4yOTA0OTldIHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINClsgICAxOC4yOTA1MDBdIHVz
YiB1c2IzOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJp
YWxOdW1iZXI9MQ0KWyAgIDE4LjI5MDUwMV0gdXNiIHVzYjM6IFByb2R1Y3Q6IEVIQ0kgSG9z
dCBDb250cm9sbGVyDQpbICAgMTguMjkwNTAzXSB1c2IgdXNiMzogTWFudWZhY3R1cmVyOiBM
aW51eCAzLjE4LjAtcmM1LTIwMTQxMTE2LXZhbmlsbGEgZWhjaV9oY2QNClsgICAxOC4yOTA1
MDNdIHVzYiB1c2IzOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMg0KWyAgIDE4LjI5MDc1
N10gaHViIDMtMDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAxOC4yOTA3NjhdIGh1YiAzLTA6
MS4wOiA0IHBvcnRzIGRldGVjdGVkDQpbICAgMTguMjkxMDI2XSBvaGNpX2hjZDogVVNCIDEu
MSAnT3BlbicgSG9zdCBDb250cm9sbGVyIChPSENJKSBEcml2ZXINClsgICAxOC4yOTEwMzhd
IG9oY2ktcGNpOiBPSENJIFBDSSBwbGF0Zm9ybSBkcml2ZXINClsgICAxOC4yOTEyMTBdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTgu
MjkxMjEyXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgMTguMjkxMjM3XSBvaGNp
LXBjaSAwMDAwOjAwOjEyLjA6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNClsgICAxOC4yOTEy
NTFdIG9oY2ktcGNpIDAwMDA6MDA6MTIuMDogT0hDSSBQQ0kgaG9zdCBjb250cm9sbGVyDQpb
ICAgMTguMjkxNDg1XSBvaGNpLXBjaSAwMDAwOjAwOjEyLjA6IG5ldyBVU0IgYnVzIHJlZ2lz
dGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNA0KWyAgIDE4LjI5MTYyOV0gb2hjaS1wY2kg
MDAwMDowMDoxMi4wOiBpcnEgMTgsIGlvIG1lbSAweGZkYmY3MDAwDQpbICAgMTguMzQ4MDY3
XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJv
ZHVjdD0wMDAxDQpbICAgMTguMzQ4MDY5XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ugc3Ry
aW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAxOC4zNDgwNzBd
IHVzYiB1c2I0OiBQcm9kdWN0OiBPSENJIFBDSSBob3N0IGNvbnRyb2xsZXINClsgICAxOC4z
NDgwNzFdIHVzYiB1c2I0OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMTguMC1yYzUtMjAxNDEx
MTYtdmFuaWxsYSBvaGNpX2hjZA0KWyAgIDE4LjM0ODA3Ml0gdXNiIHVzYjQ6IFNlcmlhbE51
bWJlcjogMDAwMDowMDoxMi4wDQpbICAgMTguMzQ4MzYwXSBodWIgNC0wOjEuMDogVVNCIGh1
YiBmb3VuZA0KWyAgIDE4LjM0ODM3Nl0gaHViIDQtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQN
ClsgICAxOC4zNDg3NzZdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgMTguMzQ4Nzc4XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpb
ICAgMTguMzQ4Nzk5XSBvaGNpLXBjaSAwMDAwOjAwOjEzLjA6IGVuYWJsaW5nIGJ1cyBtYXN0
ZXJpbmcNClsgICAxOC4zNDg4MDZdIG9oY2ktcGNpIDAwMDA6MDA6MTMuMDogT0hDSSBQQ0kg
aG9zdCBjb250cm9sbGVyDQpbICAgMTguMzQ4OTk4XSBvaGNpLXBjaSAwMDAwOjAwOjEzLjA6
IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNQ0KWyAgIDE4
LjM0OTA3NF0gb2hjaS1wY2kgMDAwMDowMDoxMy4wOiBpcnEgMTgsIGlvIG1lbSAweGZkYmZj
MDAwDQpbICAgMTguNDA0NTY3XSB1c2IgdXNiNTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlk
VmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgMTguNDA0NTY5XSB1c2IgdXNiNTog
TmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVy
PTENClsgICAxOC40MDQ1NzBdIHVzYiB1c2I1OiBQcm9kdWN0OiBPSENJIFBDSSBob3N0IGNv
bnRyb2xsZXINClsgICAxOC40MDQ1NzFdIHVzYiB1c2I1OiBNYW51ZmFjdHVyZXI6IExpbnV4
IDMuMTguMC1yYzUtMjAxNDExMTYtdmFuaWxsYSBvaGNpX2hjZA0KWyAgIDE4LjQwNDU3Ml0g
dXNiIHVzYjU6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMy4wDQpbICAgMTguNDA0ODU2XSBo
dWIgNS0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgIDE4LjQwNDg3MV0gaHViIDUtMDoxLjA6
IDUgcG9ydHMgZGV0ZWN0ZWQNClsgICAxOC40MDUyNjhdIHhlbjogcmVnaXN0ZXJpbmcgZ3Np
IDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgMTguNDA1MjcwXSBBbHJlYWR5IHNl
dHVwIHRoZSBHU0kgOjE4DQpbICAgMTguNDA1MjkyXSBvaGNpLXBjaSAwMDAwOjAwOjE0LjU6
IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNClsgICAxOC40MDUyOTldIG9oY2ktcGNpIDAwMDA6
MDA6MTQuNTogT0hDSSBQQ0kgaG9zdCBjb250cm9sbGVyDQpbICAgMTguNDA1NDk5XSBvaGNp
LXBjaSAwMDAwOjAwOjE0LjU6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1
cyBudW1iZXIgNg0KWyAgIDE4LjQwNTU5MV0gb2hjaS1wY2kgMDAwMDowMDoxNC41OiBpcnEg
MTgsIGlvIG1lbSAweGZkYmZkMDAwDQpbICAgMTguNDYxMTk2XSB1c2IgdXNiNjogTmV3IFVT
QiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgMTgu
NDYxMTk3XSB1c2IgdXNiNjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1
Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAxOC40NjExOThdIHVzYiB1c2I2OiBQcm9kdWN0
OiBPSENJIFBDSSBob3N0IGNvbnRyb2xsZXINClsgICAxOC40NjExOTldIHVzYiB1c2I2OiBN
YW51ZmFjdHVyZXI6IExpbnV4IDMuMTguMC1yYzUtMjAxNDExMTYtdmFuaWxsYSBvaGNpX2hj
ZA0KWyAgIDE4LjQ2MTIwMF0gdXNiIHVzYjY6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxNC41
DQpbICAgMTguNDYxNDgwXSBodWIgNi0wOjEuMDogVVNCIGh1YiBmb3VuZA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NDU6MjMuODQwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy0xIC0+IDB4N2EgLT4gSVJRIDI1IE1vZGU6MSBBY3RpdmU6MSkNClsgICAxOC40NjE0
OTRdIGh1YiA2LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQpbICAgMTguNDYxODE5XSB4ZW46
IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgIDE4LjQ2
MTgyMV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KWyAgIDE4LjQ2MTg0Nl0gb2hjaS1w
Y2kgMDAwMDowMDoxNi4wOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQpbICAgMTguNDYxODUz
XSBvaGNpLXBjaSAwMDAwOjAwOjE2LjA6IE9IQ0kgUENJIGhvc3QgY29udHJvbGxlcg0KWyAg
IDE4LjQ2MjEwN10gb2hjaS1wY2kgMDAwMDowMDoxNi4wOiBuZXcgVVNCIGJ1cyByZWdpc3Rl
cmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDcNClsgICAxOC40NjIxOTZdIG9oY2ktcGNpIDAw
MDA6MDA6MTYuMDogaXJxIDE4LCBpbyBtZW0gMHhmZGJmZTAwMA0KWyAgIDE4LjUxNzkzOF0g
dXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1
Y3Q9MDAwMQ0KWyAgIDE4LjUxNzk0MF0gdXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIHN0cmlu
Z3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgMTguNTE3OTQxXSB1
c2IgdXNiNzogUHJvZHVjdDogT0hDSSBQQ0kgaG9zdCBjb250cm9sbGVyDQpbICAgMTguNTE3
OTQyXSB1c2IgdXNiNzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjE4LjAtcmM1LTIwMTQxMTE2
LXZhbmlsbGEgb2hjaV9oY2QNClsgICAxOC41MTc5NDJdIHVzYiB1c2I3OiBTZXJpYWxOdW1i
ZXI6IDAwMDA6MDA6MTYuMA0KWyAgIDE4LjUxODIyOV0gaHViIDctMDoxLjA6IFVTQiBodWIg
Zm91bmQNClsgICAxOC41MTgyNDVdIGh1YiA3LTA6MS4wOiA0IHBvcnRzIGRldGVjdGVkDQpb
ICAgMTguNTE4NTAyXSB1aGNpX2hjZDogVVNCIFVuaXZlcnNhbCBIb3N0IENvbnRyb2xsZXIg
SW50ZXJmYWNlIGRyaXZlcg0KWyAgIDE4LjUxODU5N10gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JscA0KWyAgIDE4LjUxODY0OF0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Itc3RvcmFnZQ0KWyAgIDE4LjUxODcy
Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JzZXJpYWwN
ClsgICAxOC41MTg3NTBdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgY3AyMTB4DQpbICAgMTguNTE4ODU1XSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9y
dCByZWdpc3RlcmVkIGZvciBjcDIxMHgNClsgICAxOC41MTg4OTFdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3lwcmVzc19tOA0KWyAgIDE4LjUxODkxMV0g
dXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgRGVMb3JtZSBF
YXJ0aG1hdGUgVVNCDQpbICAgMTguNTE4OTMyXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3Vw
cG9ydCByZWdpc3RlcmVkIGZvciBISUQtPkNPTSBSUzIzMiBBZGFwdGVyDQpbICAgMTguNTE4
OTUyXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBOb2tp
YSBDQS00MiBWMiBBZGFwdGVyDQpbICAgMTguNTE4OTgxXSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc3MjANClsgICAxOC41MTkwMDNdIHVzYnNlcmlh
bDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIE1vc2NoaXAgMiBwb3J0IGFk
YXB0ZXINClsgICAxOC41MTkwMzRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFj
ZSBkcml2ZXIgbW9zNzg0MA0KWyAgIDE4LjUxOTA1NF0gdXNic2VyaWFsOiBVU0IgU2VyaWFs
IHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCA3ODQwLzc4MjAgVVNCIFNlcmlhbCBE
cml2ZXINClsgICAxOC41MTkxMzVdIGk4MDQyOiBQTlA6IE5vIFBTLzIgY29udHJvbGxlciBm
b3VuZC4gUHJvYmluZyBwb3J0cyBkaXJlY3RseS4NClsgICAxOC41MTk4MjJdIHNlcmlvOiBp
ODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDENClsgICAxOC41MTk4NThdIHNlcmlv
OiBpODA0MiBBVVggcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEyDQpbICAgMTguNTIwMDc3XSBt
b3VzZWRldjogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWljZQ0KWyAgIDE4
LjUyMDkyNl0gcnRjX2Ntb3MgMDA6MDI6IFJUQyBjYW4gd2FrZSBmcm9tIFM0DQpbICAgMTgu
NTIxMzk1XSBydGNfY21vcyAwMDowMjogcnRjIGNvcmU6IHJlZ2lzdGVyZWQgcnRjX2Ntb3Mg
YXMgcnRjMA0KWyAgIDE4LjUyMTQ1N10gcnRjX2Ntb3MgMDA6MDI6IGFsYXJtcyB1cCB0byBv
bmUgbW9udGgsIHkzaywgMTE0IGJ5dGVzIG52cmFtDQpbICAgMTguNTIxNzI2XSBBQ1BJIFdh
cm5pbmc6IFN5c3RlbUlPIHJhbmdlIDB4MDAwMDAwMDAwMDAwMGIwMC0weDAwMDAwMDAwMDAw
MDBiMDcgY29uZmxpY3RzIHdpdGggT3BSZWdpb24gMHgwMDAwMDAwMDAwMDAwYjAwLTB4MDAw
MDAwMDAwMDAwMGIwZiAoXFNPUjEpICgyMDE0MDkyNi91dGFkZHJlc3MtMjU4KQ0KWyAgIDE4
LjUyMTcyOF0gQUNQSTogVGhpcyBjb25mbGljdCBtYXkgY2F1c2UgcmFuZG9tIHByb2JsZW1z
IGFuZCBzeXN0ZW0gaW5zdGFiaWxpdHkNClsgICAxOC41MjE3MjhdIEFDUEk6IElmIGFuIEFD
UEkgZHJpdmVyIGlzIGF2YWlsYWJsZSBmb3IgdGhpcyBkZXZpY2UsIHlvdSBzaG91bGQgdXNl
IGl0IGluc3RlYWQgb2YgdGhlIG5hdGl2ZSBkcml2ZXINClsgICAxOC41MjE3MzRdIHBpaXg0
X3NtYnVzIDAwMDA6MDA6MTQuMDogU01CdXMgSG9zdCBDb250cm9sbGVyIGF0IDB4YjAwLCBy
ZXZpc2lvbiAwDQpbICAgMTguNTIxODM5XSBBQ1BJIFdhcm5pbmc6IFN5c3RlbUlPIHJhbmdl
IDB4MDAwMDAwMDAwMDAwMGIyMC0weDAwMDAwMDAwMDAwMDBiMjcgY29uZmxpY3RzIHdpdGgg
T3BSZWdpb24gMHgwMDAwMDAwMDAwMDAwYjIwLTB4MDAwMDAwMDAwMDAwMGIyZiAoXFNPUjIp
ICgyMDE0MDkyNi91dGFkZHJlc3MtMjU4KQ0KWyAgIDE4LjUyMTg0MF0gQUNQSTogVGhpcyBj
b25mbGljdCBtYXkgY2F1c2UgcmFuZG9tIHByb2JsZW1zIGFuZCBzeXN0ZW0gaW5zdGFiaWxp
dHkNClsgICAxOC41MjE4NDFdIEFDUEk6IElmIGFuIEFDUEkgZHJpdmVyIGlzIGF2YWlsYWJs
ZSBmb3IgdGhpcyBkZXZpY2UsIHlvdSBzaG91bGQgdXNlIGl0IGluc3RlYWQgb2YgdGhlIG5h
dGl2ZSBkcml2ZXINClsgICAxOC41MjE4NDJdIHBpaXg0X3NtYnVzIDAwMDA6MDA6MTQuMDog
QXV4aWxpYXJ5IFNNQnVzIEhvc3QgQ29udHJvbGxlciBhdCAweGIyMA0KWyAgIDE4LjUyMjE3
Nl0gbGlyY19kZXY6IElSIFJlbW90ZSBDb250cm9sIGRyaXZlciByZWdpc3RlcmVkLCBtYWpv
ciAyNDggDQpbICAgMTguNTIyMTk0XSBJUiBORUMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFs
aXplZA0KWyAgIDE4LjUyMjE5N10gSVIgUkM1KHgvc3opIHByb3RvY29sIGhhbmRsZXIgaW5p
dGlhbGl6ZWQNClsgICAxOC41MjIxOTldIElSIFJDNiBwcm90b2NvbCBoYW5kbGVyIGluaXRp
YWxpemVkDQpbICAgMTguNTIyMjAwXSBJUiBKVkMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFs
aXplZA0KWyAgIDE4LjUyMjIwM10gSVIgU29ueSBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxp
emVkDQpbICAgMTguNTIyMjA1XSBJUiBTQU5ZTyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxp
emVkDQpbICAgMTguNTIyMjA3XSBJUiBTaGFycCBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxp
emVkDQpbICAgMTguNTIyMjEwXSBJUiBNQ0UgS2V5Ym9hcmQvbW91c2UgcHJvdG9jb2wgaGFu
ZGxlciBpbml0aWFsaXplZA0KWyAgIDE4LjUyMjIxMl0gSVIgTElSQyBicmlkZ2UgaGFuZGxl
ciBpbml0aWFsaXplZA0KWyAgIDE4LjUyMjIxNF0gSVIgWE1QIHByb3RvY29sIGhhbmRsZXIg
aW5pdGlhbGl6ZWQNClsgICAxOC41MjIyMTZdIGN4MjU4MjE6IGRyaXZlciB2ZXJzaW9uIDAu
MC4xMDYgbG9hZGVkDQpbICAgMTguNTIyNDE2XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBp
bnRlcmZhY2UgZHJpdmVyIHB2cnVzYjINClsgICAxOC41MjI0MTddIHB2cnVzYjI6IFY0TCBp
bi10cmVlIHZlcnNpb246SGF1cHBhdWdlIFdpblRWLVBWUi1VU0IyIE1QRUcyIEVuY29kZXIv
VHVuZXINClsgICAxOC41MjI0MThdIHB2cnVzYjI6IERlYnVnIG1hc2sgaXMgMzEgKDB4MWYp
DQpbICAgMTguNTIyNTEzXSBmNzE4MDVmOiBVbnN1cHBvcnRlZCBGaW50ZWsgZGV2aWNlLCBz
a2lwcGluZw0KWyAgIDE4LjUyMjYwN10gZjcxODgyZmc6IEZvdW5kIGY3MTg4OWVkIGNoaXAg
YXQgMHg2MDAsIHJldmlzaW9uIDE2DQpbICAgMTguNTIyNjM4XSBBQ1BJIFdhcm5pbmc6IFN5
c3RlbUlPIHJhbmdlIDB4MDAwMDAwMDAwMDAwMDYwMC0weDAwMDAwMDAwMDAwMDA2MDcgY29u
ZmxpY3RzIHdpdGggT3BSZWdpb24gMHgwMDAwMDAwMDAwMDAwNjA1LTB4MDAwMDAwMDAwMDAw
MDYwNiAoXEhNT1IpICgyMDE0MDkyNi91dGFkZHJlc3MtMjU4KQ0KWyAgIDE4LjUyMjYzOV0g
QUNQSTogVGhpcyBjb25mbGljdCBtYXkgY2F1c2UgcmFuZG9tIHByb2JsZW1zIGFuZCBzeXN0
ZW0gaW5zdGFiaWxpdHkNClsgICAxOC41MjI2NDBdIEFDUEk6IElmIGFuIEFDUEkgZHJpdmVy
IGlzIGF2YWlsYWJsZSBmb3IgdGhpcyBkZXZpY2UsIHlvdSBzaG91bGQgdXNlIGl0IGluc3Rl
YWQgb2YgdGhlIG5hdGl2ZSBkcml2ZXINClsgICAxOC41MjI3OTNdIGY3MTg4MmZnIGY3MTg4
MmZnLjE1MzY6IEZhbjogMSBpcyBpbiBkdXR5LWN5Y2xlIG1vZGUNClsgICAxOC41MjI4Mzhd
IGY3MTg4MmZnIGY3MTg4MmZnLjE1MzY6IEZhbjogMiBpcyBpbiBkdXR5LWN5Y2xlIG1vZGUN
ClsgICAxOC41MjI4ODJdIGY3MTg4MmZnIGY3MTg4MmZnLjE1MzY6IEZhbjogMyBpcyBpbiBk
dXR5LWN5Y2xlIG1vZGUNClsgICAxOC42NTM5NzNdIHNwNTEwMF90Y286IFNQNTEwMC9TQjgw
MCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYwLjA1DQpbICAgMTguNjU0MDM4XSBzcDUx
MDBfdGNvOiBQQ0kgUmV2aXNpb24gSUQ6IDB4NDENClsgICAxOC42NTQxMDZdIHNwNTEwMF90
Y286IFVzaW5nIDB4ZmVkODBiMDAgZm9yIHdhdGNoZG9nIE1NSU8gYWRkcmVzcw0KWyAgIDE4
LjY1NDE0MF0gc3A1MTAwX3RjbzogTGFzdCByZWJvb3Qgd2FzIG5vdCB0cmlnZ2VyZWQgYnkg
d2F0Y2hkb2cuDQpbICAgMTguNjU0MzIyXSBzcDUxMDBfdGNvOiBpbml0aWFsaXplZCAoMHhm
ZmZmYzkwMDAwMzc2YjAwKS4gaGVhcnRiZWF0PTYwIHNlYyAobm93YXlvdXQ9MCkNClsgICAx
OC42NTQzMjhdIHhlbl93ZHQ6IFhlbiBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDENClsg
ICAxOC42NTQzODJdIHhlbl93ZHQ6IGNhbm5vdCByZWdpc3RlciBtaXNjZGV2IG9uIG1pbm9y
PTEzMCAoLTE2KQ0KWyAgIDE4LjY1NDM5Ml0gd2R0OiBwcm9iZSBvZiB3ZHQgZmFpbGVkIHdp
dGggZXJyb3IgLTE2DQpbICAgMTguNjU0OTY2XSBkZXZpY2UtbWFwcGVyOiBpb2N0bDogNC4y
OC4wLWlvY3RsICgyMDE0LTA5LTE3KSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAcmVkaGF0LmNv
bQ0KWyAgIDE4LjY1NTI3MF0gZGV2aWNlLW1hcHBlcjogY2FjaGUtcG9saWN5LW1xOiB2ZXJz
aW9uIDEuMi4wIGxvYWRlZA0KWyAgIDE4LjY1NTI3Ml0gZGV2aWNlLW1hcHBlcjogY2FjaGUg
Y2xlYW5lcjogdmVyc2lvbiAxLjAuMCBsb2FkZWQNClsgICAxOC42NTUyNzVdIEJsdWV0b290
aDogVmlydHVhbCBIQ0kgZHJpdmVyIHZlciAxLjUNClsgICAxOC42NTUzODhdIEJsdWV0b290
aDogSENJIFVBUlQgZHJpdmVyIHZlciAyLjINClsgICAxOC42NTUzOTBdIEJsdWV0b290aDog
SENJIEg0IHByb3RvY29sIGluaXRpYWxpemVkDQpbICAgMTguNjU1MzkwXSBCbHVldG9vdGg6
IEhDSSBCQ1NQIHByb3RvY29sIGluaXRpYWxpemVkDQpbICAgMTguNjU1MzkxXSBCbHVldG9v
dGg6IEhDSUxMIHByb3RvY29sIGluaXRpYWxpemVkDQpbICAgMTguNjU1MzkxXSBCbHVldG9v
dGg6IEhDSUFUSDNLIHByb3RvY29sIGluaXRpYWxpemVkDQpbICAgMTguNjU1MzkyXSBCbHVl
dG9vdGg6IEhDSSBUaHJlZS13aXJlIFVBUlQgKEg1KSBwcm90b2NvbCBpbml0aWFsaXplZA0K
WyAgIDE4LjY1NTQzMl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZl
ciBiY20yMDN4DQpbICAgMTguNjU1NDY0XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRl
cmZhY2UgZHJpdmVyIGJwYTEweA0KWyAgIDE4LjY1NTQ5Nl0gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBiZnVzYg0KWyAgIDE4LjY1NTUyOF0gdXNiY29yZTog
cmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBidHVzYg0KWyAgIDE4LjY1NTU1OV0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBhdGgzaw0KWyAgIDE4
LjY1NjI1NV0gaGlkcmF3OiByYXcgSElEIGV2ZW50cyBkcml2ZXIgKEMpIEppcmkgS29zaW5h
DQpbICAgMTguNjU2NTMwXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJp
dmVyIHVzYmhpZA0KWyAgIDE4LjY1NjUzMF0gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJpdmVy
DQpbICAgMTguNjU4MTE0XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNiB0cmlnZ2VyaW5nIDAg
cG9sYXJpdHkgMQ0KWyAgIDE4LjY1ODExOV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNg0K
WyAgIDE4LjY1ODIyM10geGVuOiByZWdpc3RlcmluZyBnc2kgMjUgdHJpZ2dlcmluZyAwIHBv
bGFyaXR5IDENClsgICAxOC42NTgyMzddIHhlbjogLS0+IHBpcnE9MjUgLT4gaXJxPTI1IChn
c2k9MjUpDQpbICAgMTguNjU4NDI3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIHNuZC11c2ItYXVkaW8NClsgICAxOC42NTg3NDJdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVhMTAxDQpbICAgMTguNjU4Nzg5XSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItdXN4MnkN
ClsgICAxOC42NTg4MjRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgc25kLXVzYi1jYWlhcQ0KWyAgIDE4LjY1ODg1Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLTZmaXJlDQpbICAgMTguNjU4OTEyXSBOZXRm
aWx0ZXIgbWVzc2FnZXMgdmlhIE5FVExJTksgdjAuMzAuDQpbICAgMTguNjU4OTE5XSBuZm5s
X2FjY3Q6IHJlZ2lzdGVyaW5nIHdpdGggbmZuZXRsaW5rLg0KWyAgIDE4LjY1ODk4MF0gbmZf
Y29ubnRyYWNrIHZlcnNpb24gMC41LjAgKDE2Mzg0IGJ1Y2tldHMsIDY1NTM2IG1heCkNClsg
ICAxOC42NTkyNTRdIGN0bmV0bGluayB2MC45MzogcmVnaXN0ZXJpbmcgd2l0aCBuZm5ldGxp
bmsuDQpbICAgMTguNjU5NjUzXSB4dF90aW1lOiBrZXJuZWwgdGltZXpvbmUgaXMgLTAwMDAN
ClsgICAxOC42NTk2ODBdIGlwX3NldDogcHJvdG9jb2wgNg0KWyAgIDE4LjY1OTc2N10gSVBW
UzogUmVnaXN0ZXJlZCBwcm90b2NvbHMgKCkNClsgICAxOC42NTk4ODRdIElQVlM6IENvbm5l
Y3Rpb24gaGFzaCB0YWJsZSBjb25maWd1cmVkIChzaXplPTQwOTYsIG1lbW9yeT02NEtieXRl
cykNClsgICAxOC42NTk5NDldIElQVlM6IENyZWF0aW5nIG5ldG5zIHNpemU9MTg0MCBpZD0w
DQpbICAgMTguNzEwNDM4XSBzb3VuZCBoZGF1ZGlvQzBEMjogYXV0b2NvbmZpZzogbGluZV9v
dXRzPTQgKDB4MTQvMHgxNS8weDE2LzB4MTcvMHgwKSB0eXBlOmxpbmUNClsgICAxOC43MTA0
NDBdIHNvdW5kIGhkYXVkaW9DMEQyOiAgICBzcGVha2VyX291dHM9MCAoMHgwLzB4MC8weDAv
MHgwLzB4MCkNClsgICAxOC43MTA0NDJdIHNvdW5kIGhkYXVkaW9DMEQyOiAgICBocF9vdXRz
PTEgKDB4MWIvMHgwLzB4MC8weDAvMHgwKQ0KWyAgIDE4LjcxMDQ0M10gc291bmQgaGRhdWRp
b0MwRDI6ICAgIG1vbm86IG1vbm9fb3V0PTB4MA0KWyAgIDE4LjcxMDQ0NF0gc291bmQgaGRh
dWRpb0MwRDI6ICAgIGRpZy1vdXQ9MHgxMS8weDFlDQpbICAgMTguNzEwNDQ1XSBzb3VuZCBo
ZGF1ZGlvQzBEMjogICAgaW5wdXRzOg0KWyAgIDE4LjcxMDQ0Nl0gc291bmQgaGRhdWRpb0Mw
RDI6ICAgICAgRnJvbnQgTWljPTB4MTkNClsgICAxOC43MTA0NDddIHNvdW5kIGhkYXVkaW9D
MEQyOiAgICAgIFJlYXIgTWljPTB4MTgNClsgICAxOC43MTA0NDldIHNvdW5kIGhkYXVkaW9D
MEQyOiAgICAgIExpbmU9MHgxYQ0KWyAgIDE4LjcyNDAwNF0gdXNiIDQtNTogbmV3IGZ1bGwt
c3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2luZyBvaGNpLXBjaQ0KWyAgIDE4LjczMDc2
Nl0gcmFuZG9tOiBub25ibG9ja2luZyBwb29sIGlzIGluaXRpYWxpemVkDQpbICAgMTguODQw
NjA5XSB1c2IgNy0zOiBuZXcgbG93LXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIgdXNpbmcg
b2hjaS1wY2kNClsgICAxOS4wMDA5ODZdIHVzYiA3LTM6IE5ldyBVU0IgZGV2aWNlIGZvdW5k
LCBpZFZlbmRvcj0wNDZkLCBpZFByb2R1Y3Q9YzUxNw0KWyAgIDE5LjAwMDk5Ml0gdXNiIDct
MzogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTEsIFByb2R1Y3Q9MiwgU2VyaWFsTnVt
YmVyPTANClsgICAxOS4wMDA5OTddIHVzYiA3LTM6IFByb2R1Y3Q6IFVTQiBSZWNlaXZlcg0K
WyAgIDE5LjAwMTAwMV0gdXNiIDctMzogTWFudWZhY3R1cmVyOiBMb2dpdGVjaA0KWyAgIDE5
LjAwODY1OV0gaW5wdXQ6IExvZ2l0ZWNoIFVTQiBSZWNlaXZlciBhcyAvZGV2aWNlcy9wY2kw
MDAwOjAwLzAwMDA6MDA6MTYuMC91c2I3LzctMy83LTM6MS4wLzAwMDM6MDQ2RDpDNTE3LjAw
MDEvaW5wdXQvaW5wdXQ1DQpbICAgMTkuMDA5NDE3XSBsb2dpdGVjaCAwMDAzOjA0NkQ6QzUx
Ny4wMDAxOiBpbnB1dCxoaWRyYXcwOiBVU0IgSElEIHYxLjEwIEtleWJvYXJkIFtMb2dpdGVj
aCBVU0IgUmVjZWl2ZXJdIG9uIHVzYi0wMDAwOjAwOjE2LjAtMy9pbnB1dDANClsgICAxOS4w
MTU2MjZdIElQVlM6IGlwdnMgbG9hZGVkLg0KWyAgIDE5LjAxNzAxM10gbG9naXRlY2ggMDAw
MzowNDZEOkM1MTcuMDAwMjogZml4aW5nIHVwIExvZ2l0ZWNoIGtleWJvYXJkIHJlcG9ydCBk
ZXNjcmlwdG9yDQpbICAgMTkuMDE3NTAzXSBpbnB1dDogTG9naXRlY2ggVVNCIFJlY2VpdmVy
IGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxNi4wL3VzYjcvNy0zLzctMzoxLjEv
MDAwMzowNDZEOkM1MTcuMDAwMi9pbnB1dC9pbnB1dDYNClsgICAxOS4wMTgyNTBdIGxvZ2l0
ZWNoIDAwMDM6MDQ2RDpDNTE3LjAwMDI6IGlucHV0LGhpZGRldjAsaGlkcmF3MTogVVNCIEhJ
RCB2MS4xMCBNb3VzZSBbTG9naXRlY2ggVVNCIFJlY2VpdmVyXSBvbiB1c2ItMDAwMDowMDox
Ni4wLTMvaW5wdXQxDQpbICAgMTkuMTU0MDM0XSB1c2IgNC01OiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MGExMiwgaWRQcm9kdWN0PTAwMDENClsgICAxOS4xNTQwMzZdIHVz
YiA0LTU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0wLCBQcm9kdWN0PTIsIFNlcmlh
bE51bWJlcj0wDQpbICAgMTkuMTU0MDM3XSB1c2IgNC01OiBQcm9kdWN0OiBFRFJDbGFzc29u
ZQ0KWyAgIDE5LjE1NDE1NF0gaXBfdGFibGVzOiAoQykgMjAwMC0yMDA2IE5ldGZpbHRlciBD
b3JlIFRlYW0NClsgICAxOS4xNTQyMzZdIFRDUDogY3ViaWMgcmVnaXN0ZXJlZA0KWyAgIDE5
LjE1NDg5Ml0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMA0KWyAgIDE5LjE1
NTczOV0gaXA2X3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtDQpb
ICAgMTkuMjQxNzUxXSBzaXQ6IElQdjYgb3ZlciBJUHY0IHR1bm5lbGluZyBkcml2ZXINClsg
ICAxOS4yNDIwNTRdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcNClsgICAx
OS4yNDIxMjRdIGJyaWRnZTogYXV0b21hdGljIGZpbHRlcmluZyB2aWEgYXJwL2lwL2lwNnRh
YmxlcyBoYXMgYmVlbiBkZXByZWNhdGVkLiBVcGRhdGUgeW91ciBzY3JpcHRzIHRvIGxvYWQg
YnJfbmV0ZmlsdGVyIGlmIHlvdSBuZWVkIHRoaXMuDQpbICAgMTkuMzk4ODg1XSBCcmlkZ2Ug
ZmlyZXdhbGxpbmcgcmVnaXN0ZXJlZA0KWyAgIDE5LjM5ODg4OV0gRWJ0YWJsZXMgdjIuMCBy
ZWdpc3RlcmVkDQpbICAgMTkuMzk5MTYwXSBCbHVldG9vdGg6IFJGQ09NTSBUVFkgbGF5ZXIg
aW5pdGlhbGl6ZWQNClsgICAxOS4zOTkxNzFdIEJsdWV0b290aDogUkZDT01NIHNvY2tldCBs
YXllciBpbml0aWFsaXplZA0KWyAgIDE5LjM5OTE4MV0gQmx1ZXRvb3RoOiBSRkNPTU0gdmVy
IDEuMTENClsgICAxOS4zOTkxODldIEJsdWV0b290aDogQk5FUCAoRXRoZXJuZXQgRW11bGF0
aW9uKSB2ZXIgMS4zDQpbICAgMTkuMzk5MTkwXSBCbHVldG9vdGg6IEJORVAgZmlsdGVyczog
cHJvdG9jb2wgbXVsdGljYXN0DQpbICAgMTkuMzk5MjExXSBCbHVldG9vdGg6IEJORVAgc29j
a2V0IGxheWVyIGluaXRpYWxpemVkDQpbICAgMTkuMzk5MjEzXSBCbHVldG9vdGg6IEhJRFAg
KEh1bWFuIEludGVyZmFjZSBFbXVsYXRpb24pIHZlciAxLjINClsgICAxOS4zOTkyMTZdIEJs
dWV0b290aDogSElEUCBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQNClsgICAxOS4zOTkyNjZd
IEtleSB0eXBlIGNlcGggcmVnaXN0ZXJlZA0KWyAgIDE5LjM5OTUyNF0gbGliY2VwaDogbG9h
ZGVkIChtb24vb3NkIHByb3RvIDE1LzI0KQ0KWyAgIDE5LjQwMDUwN10gcmVnaXN0ZXJlZCB0
YXNrc3RhdHMgdmVyc2lvbiAxDQpbICAgMTkuNDAyMTc0XSBCdHJmcyBsb2FkZWQNClsgICAx
OS42MjQ5MzBdIGF0YTQ6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAw
KQ0KWyAgIDE5LjYyNDk3MF0gY29uc29sZSBbbmV0Y29uMF0gZW5hYmxlZA0KWyAgIDE5LjYy
NDk3MV0gbmV0Y29uc29sZTogbmV0d29yayBsb2dnaW5nIHN0YXJ0ZWQNClsgICAxOS42MzEy
MzFdIHJ0Y19jbW9zIDAwOjAyOiBzZXR0aW5nIHN5c3RlbSBjbG9jayB0byAyMDE0LTExLTE4
IDIxOjQ1OjI0IFVUQyAoMTQxNjM0NzEyNCkNClsgICAxOS42NTA0ODVdIGF0YTI6IFNBVEEg
bGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQ0KWyAgIDE5LjY1MDU4N10gQUxT
QSBkZXZpY2UgbGlzdDoNClsgICAxOS42NTA1ODhdICAgIzA6IEhEQSBBVEkgU0IgYXQgMHhm
ZGJmODAwMCBpcnEgMTYNClsgICAxOS42NTA1ODldICAgIzE6IEhEQSBBVEkgSERNSSBhdCAw
eGZlOWZjMDAwIGlycSAxMjQNClsgICAxOS44MzM4NzZdIGF0YTE6IFNBVEEgbGluayB1cCA2
LjAgR2JwcyAoU1N0YXR1cyAxMzMgU0NvbnRyb2wgMzAwKQ0KWyAgIDE5Ljg0MjE2N10gYXRh
MzogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEyMyBTQ29udHJvbCAzMDApDQpb
ICAgMTkuODUxNDc1XSBhdGExLjAwOiBBVEEtODogSEdTVCBIRE43MjQwNDBBTEU2NDAsIE1K
QU9BNUUwLCBtYXggVURNQS8xMzMNClsgICAxOS44NTk2MTldIGF0YTEuMDA6IDc4MTQwMzcx
Njggc2VjdG9ycywgbXVsdGkgMDogTEJBNDggTkNRIChkZXB0aCAzMS8zMiksIEFBDQpbICAg
MTkuODY4NDM2XSBhdGEzLjAwOiBBVEEtODogSGl0YWNoaSBIRFM3MjIwMjBBTEEzMzAsIEpL
QU9BMjBOLCBtYXggVURNQS8xMzMNClsgICAxOS44NzY2MzVdIGF0YTMuMDA6IDM5MDcwMjkx
Njggc2VjdG9ycywgbXVsdGkgMDogTEJBNDggTkNRIChkZXB0aCAzMS8zMiksIEFBDQpbICAg
MTkuODg1NDg5XSBhdGExLjAwOiBjb25maWd1cmVkIGZvciBVRE1BLzEzMw0KWyAgIDE5Ljg5
NDU4NV0gYXRhMy4wMDogY29uZmlndXJlZCBmb3IgVURNQS8xMzMNClsgICAxOS44OTU4NDRd
IHNjc2kgMDowOjA6MDogRGlyZWN0LUFjY2VzcyAgICAgQVRBICAgICAgSEdTVCBIRE43MjQw
NDBBTCBBNUUwIFBROiAwIEFOU0k6IDUNClsgICAxOS44OTk1MTBdIHNkIDA6MDowOjA6IFtz
ZGFdIDc4MTQwMzcxNjggNTEyLWJ5dGUgbG9naWNhbCBibG9ja3M6ICg0LjAwIFRCLzMuNjMg
VGlCKQ0KWyAgIDE5Ljg5OTUxN10gc2QgMDowOjA6MDogW3NkYV0gNDA5Ni1ieXRlIHBoeXNp
Y2FsIGJsb2Nrcw0KWyAgIDE5LjkwMDE5MV0gc2QgMDowOjA6MDogQXR0YWNoZWQgc2NzaSBn
ZW5lcmljIHNnMCB0eXBlIDANClsgICAxOS45MDA1MDddIHNkIDA6MDowOjA6IFtzZGFdIFdy
aXRlIFByb3RlY3QgaXMgb2ZmDQpbICAgMTkuOTAwNTE2XSBzZCAwOjA6MDowOiBbc2RhXSBN
b2RlIFNlbnNlOiAwMCAzYSAwMCAwMA0KWyAgIDE5LjkwMDg0MF0gc2QgMDowOjA6MDogW3Nk
YV0gV3JpdGUgY2FjaGU6IGVuYWJsZWQsIHJlYWQgY2FjaGU6IGVuYWJsZWQsIGRvZXNuJ3Qg
c3VwcG9ydCBEUE8gb3IgRlVBDQpbICAgMTkuOTUzNTMxXSBzY3NpIDI6MDowOjA6IERpcmVj
dC1BY2Nlc3MgICAgIEFUQSAgICAgIEhpdGFjaGkgSERTNzIyMDIgQTIwTiBQUTogMCBBTlNJ
OiA1DQpbICAgMTkuOTYwNzI3XSBzZCAyOjA6MDowOiBbc2RiXSAzOTA3MDI5MTY4IDUxMi1i
eXRlIGxvZ2ljYWwgYmxvY2tzOiAoMi4wMCBUQi8xLjgxIFRpQikNClsgICAxOS45NjA3NzFd
IHNkIDI6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJpYyBzZzEgdHlwZSAwDQpbICAgMTku
OTcwMjUyXSAgc2RhOiBzZGExIHNkYTIgc2RhMyBzZGE0DQpbICAgMTkuOTcxNjI2XSBzZCAw
OjA6MDowOiBbc2RhXSBBdHRhY2hlZCBTQ1NJIGRpc2sNClsgICAxOS45ODc3MTZdIHNkIDI6
MDowOjA6IFtzZGJdIFdyaXRlIFByb3RlY3QgaXMgb2ZmDQpbICAgMTkuOTk0MjQ5XSBzZCAy
OjA6MDowOiBbc2RiXSBNb2RlIFNlbnNlOiAwMCAzYSAwMCAwMA0KWyAgIDIwLjAwMDY0NV0g
c2QgMjowOjA6MDogW3NkYl0gV3JpdGUgY2FjaGU6IGVuYWJsZWQsIHJlYWQgY2FjaGU6IGVu
YWJsZWQsIGRvZXNuJ3Qgc3VwcG9ydCBEUE8gb3IgRlVBDQpbICAgMjAuMDExMjE2XSAgc2Ri
OiBzZGIxDQpbICAgMjAuMDE3ODQ4XSBzZCAyOjA6MDowOiBbc2RiXSBBdHRhY2hlZCBTQ1NJ
IGRpc2sNClsgICAyMC4wMjUxMTJdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEx
MDRLIChmZmZmZmZmZjgyMzA2MDAwIC0gZmZmZmZmZmY4MjQxYTAwMCkNClsgICAyMC4wMzEy
MjNdIFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogMTg0MzJr
DQpbICAgMjAuMDQ2MTAxXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAzNTZLIChm
ZmZmODgwMDAxYmE3MDAwIC0gZmZmZjg4MDAwMWMwMDAwMCkNClsgICAyMC4wNTMzNzBdIEZy
ZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDE2NDhLIChmZmZmODgwMDAyMDY0MDAwIC0g
ZmZmZjg4MDAwMjIwMDAwMCkNClsgICAyMC4xMDE1OTBdIHVkZXZkWzE2MDZdOiBzdGFydGlu
ZyB2ZXJzaW9uIDE3NQ0KWyAgIDIxLjA5Njg1NF0gRVhUNC1mcyAoZG0tMCk6IG1vdW50ZWQg
ZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiAobnVsbCkNClsgICAy
My42ODY2MzNdIHVkZXZkWzE5ODhdOiBzdGFydGluZyB2ZXJzaW9uIDE3NQ0KWyAgIDI2Ljk2
ODU5MF0gRVhUNC1mcyAoZG0tMCk6IHJlLW1vdW50ZWQuIE9wdHM6IChudWxsKQ0KWyAgIDUz
LjUwOTAzNF0gRVhUNC1mcyAoZG0tMCk6IHJlLW1vdW50ZWQuIE9wdHM6IGJhcnJpZXI9MSxl
cnJvcnM9cmVtb3VudC1ybw0KWyAgIDU3LjczNDQ4M10gQWRkaW5nIDIwOTcxNDhrIHN3YXAg
b24gL2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtc3dhcC4gIFByaW9yaXR5Oi0xIGV4dGVu
dHM6MSBhY3Jvc3M6MjA5NzE0OGsgDQpbICAgNjMuOTA2NDM3XSBFWFQ0LWZzIChzZGExKTog
bW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJp
ZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAgIDY1Ljk0MTc4Nl0gcjgxNjkgMDAwMDowZDow
MC4wIGV0aDA6IGxpbmsgZG93bg0KWyAgIDY1Ljk0MTg3M10gcjgxNjkgMDAwMDowZDowMC4w
IGV0aDA6IGxpbmsgZG93bg0KWyAgIDY2LjAxNTIyOF0gcjgxNjkgMDAwMDowYzowMC4wIGV0
aDE6IGxpbmsgZG93bg0KWyAgIDY2LjAxNTI3M10gcjgxNjkgMDAwMDowYzowMC4wIGV0aDE6
IGxpbmsgZG93bg0KWyAgIDY3LjgzNDQ3OF0gcjgxNjkgMDAwMDowZDowMC4wIGV0aDA6IGxp
bmsgdXANClsgICA2OC42MzE1ODldIHI4MTY5IDAwMDA6MGM6MDAuMCBldGgxOiBsaW5rIHVw
DQpbICAgODEuMDI1NjgxXSBuZl9jb25udHJhY2s6IGF1dG9tYXRpYyBoZWxwZXIgYXNzaWdu
bWVudCBpcyBkZXByZWNhdGVkIGFuZCBpdCB3aWxsIGJlIHJlbW92ZWQgc29vbi4gVXNlIHRo
ZSBpcHRhYmxlcyBDVCB0YXJnZXQgdG8gYXR0YWNoIGhlbHBlcnMgaW5zdGVhZC4NClsgIDEw
Ni4zNTMzMzNdIEVYVDQtZnMgKGRtLTIpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRl
cmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJvDQpbICAx
MTYuMzA3MzcxXSBFWFQ0LWZzIChkbS01MCk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9y
ZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8NClsg
IDEyOS43NDYyMzJdIEVYVDQtZnMgKGRtLTQ5KTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGgg
b3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0K
WyAgMTM5LjY2NjE1OF0gRVhUNC1mcyAoZG0tNDgpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0
aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJv
DQpbICAxNjcuNzg2NzY1XSBFWFQ0LWZzIChkbS00NSk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3
aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQt
cm8NClsgIDE4NC41NDU0MjVdIEVYVDQtZnMgKGRtLTQ3KTogbW91bnRlZCBmaWxlc3lzdGVt
IHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3Vu
dC1ybw0KWyAgMjA0LjU0Njc0M10gRVhUNC1mcyAoZG0tNDYpOiBtb3VudGVkIGZpbGVzeXN0
ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1v
dW50LXJvDQpbICAyOTguNDcxMzY1XSBFWFQ0LWZzIChzZGIxKTogbW91bnRlZCBmaWxlc3lz
dGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVt
b3VudC1ybw0KWyAgMzE0LjExMzc2MF0gZGV2aWNlIHZpZjEuMCBlbnRlcmVkIHByb21pc2N1
b3VzIG1vZGUNCihkMSkgWzIwMTQtMTEtMTggMjE6NTA6MTkuMTU3XSBtYXBwaW5nIGtlcm5l
bCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQxKSBbMjAxNC0xMS0xOCAyMTo1MDoxOS4xNTdd
IGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MDoxOS40
MThdIHRyYXBzLmM6MjU3OTpkMXYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYu
DQpbICAzMTQuOTM5MzU4XSB4ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVs
IDE3LCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAgMzE0
Ljk1NTAwNl0geGVuLWJsa2JhY2s6cmluZy1yZWYgOSwgZXZlbnQtY2hhbm5lbCAxOCwgcHJv
dG9jb2wgMSAoeDg2XzY0LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDMxNi4xMTg1NDhd
IHZpZiB2aWYtMS0wIHZpZjEuMDogR3Vlc3QgUnggcmVhZHkNClsgIDMxNi4xMjk3MTFdIHhl
bl9icmlkZ2U6IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAg
MzE2LjE0MDcyNF0geGVuX2JyaWRnZTogcG9ydCAxKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJk
aW5nIHN0YXRlDQpbICAzMjAuMTE0NTI5XSBkZXZpY2UgdmlmMi4wIGVudGVyZWQgcHJvbWlz
Y3VvdXMgbW9kZQ0KKGQyKSBbMjAxNC0xMS0xOCAyMTo1MDoyNS4xNzddIG1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDIpIFsyMDE0LTExLTE4IDIxOjUwOjI1LjE3
N10gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjUwOjI1
LjI1M10gdHJhcHMuYzoyNTc5OmQydjAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZm
Zi4NClsgIDMyMC43NzU0MjFdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5u
ZWwgMTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAz
MjEuNzkxOTQyXSB2aWYgdmlmLTItMCB2aWYyLjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzMjEu
ODAyODc3XSB4ZW5fYnJpZGdlOiBwb3J0IDIodmlmMi4wKSBlbnRlcmVkIGZvcndhcmRpbmcg
c3RhdGUNClsgIDMyMS44MTM2NjBdIHhlbl9icmlkZ2U6IHBvcnQgMih2aWYyLjApIGVudGVy
ZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzI2LjAxNDQ4Ml0gZGV2aWNlIHZpZjMuMCBlbnRl
cmVkIHByb21pc2N1b3VzIG1vZGUNCihkMykgWzIwMTQtMTEtMTggMjE6NTA6MzAuOTY0XSBt
YXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQzKSBbMjAxNC0xMS0xOCAy
MTo1MDozMC45NjRdIGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1MDozMS4wNTZdIHRyYXBzLmM6MjU3OTpkM3YwIERvbWFpbiBhdHRlbXB0ZWQgV1JN
U1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAweDAwMDAw
MDAwMDAwMGZmZmYuDQpbICAzMjYuNjk3Mzg1XSB4ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBl
dmVudC1jaGFubmVsIDE3LCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdy
YW50cw0KWyAgMzI3LjcxNjcwM10gdmlmIHZpZi0zLTAgdmlmMy4wOiBHdWVzdCBSeCByZWFk
eQ0KWyAgMzI3LjcyNzEwOV0geGVuX2JyaWRnZTogcG9ydCAzKHZpZjMuMCkgZW50ZXJlZCBm
b3J3YXJkaW5nIHN0YXRlDQpbICAzMjcuNzM3NDY2XSB4ZW5fYnJpZGdlOiBwb3J0IDModmlm
My4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDMzMS4xNjE4NjNdIHhlbl9icmlk
Z2U6IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzMxLjg5
MjI0MF0gZGV2aWNlIHZpZjQuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNCihkNCkgWzIw
MTQtMTEtMTggMjE6NTA6MzYuODQ3XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1l
bW9yeQ0KKGQ0KSBbMjAxNC0xMS0xOCAyMTo1MDozNi44NDddIGFib3V0IHRvIGdldCBzdGFy
dGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MDozNi45MjRdIHRyYXBzLmM6MjU3OTpk
NHYwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAw
MDAwMDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuDQpbICAzMzIuNDQ5NjQ5XSB4
ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDEwLCBwcm90b2NvbCAxICh4
ODZfNjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAgMzMzLjQ2NjE4Ml0gdmlmIHZpZi00
LTAgdmlmNC4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzMzLjQ3NjEyNF0geGVuX2JyaWRnZTog
cG9ydCA0KHZpZjQuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzMzMuNDg2MTQy
XSB4ZW5fYnJpZGdlOiBwb3J0IDQodmlmNC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUN
CihYRU4pIFsyMDE0LTExLTE4IDIxOjUwOjM5LjEwOF0gZ3JhbnRfdGFibGUuYzozMDU6ZDB2
MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byAyIGZyYW1lcw0KWyAgMzM2Ljg3MTM2MV0g
eGVuX2JyaWRnZTogcG9ydCAyKHZpZjIuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpb
ICAzMzcuNjY0ODI4XSBkZXZpY2UgdmlmNS4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0K
KGQ1KSBbMjAxNC0xMS0xOCAyMTo1MDo0Mi42MTNdIG1hcHBpbmcga2VybmVsIGludG8gcGh5
c2ljYWwgbWVtb3J5DQooZDUpIFsyMDE0LTExLTE4IDIxOjUwOjQyLjYxNF0gYWJvdXQgdG8g
Z2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjUwOjQyLjY5NF0gdHJhcHMu
YzoyNTc5OmQ1djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDMzOC4y
MjAwNjJdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3Rv
Y29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzMzkuMjM2MTM3XSB2
aWYgdmlmLTUtMCB2aWY1LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzMzkuMjQ1NTc5XSB4ZW5f
YnJpZGdlOiBwb3J0IDUodmlmNS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDMz
OS4yNTUwMDBdIHhlbl9icmlkZ2U6IHBvcnQgNSh2aWY1LjApIGVudGVyZWQgZm9yd2FyZGlu
ZyBzdGF0ZQ0KWyAgMzQyLjc5NDMyOV0geGVuX2JyaWRnZTogcG9ydCAzKHZpZjMuMCkgZW50
ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNDMuNzExMDg3XSBkZXZpY2UgdmlmNi4wIGVu
dGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ2KSBbMjAxNC0xMS0xOCAyMTo1MDo0OC42NjZd
IG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDYpIFsyMDE0LTExLTE4
IDIxOjUwOjQ4LjY2Nl0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjUwOjQ4Ljc4OV0gdHJhcHMuYzoyNTc5OmQ2djAgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAw
MDAwMDAwMDAwZmZmZi4NClsgIDM0NC4zMTUyMjBdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgs
IGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQg
Z3JhbnRzDQpbICAzNDUuMzMxNzQ0XSB2aWYgdmlmLTYtMCB2aWY2LjA6IEd1ZXN0IFJ4IHJl
YWR5DQpbICAzNDUuMzQwNjQ3XSB4ZW5fYnJpZGdlOiBwb3J0IDYodmlmNi4wKSBlbnRlcmVk
IGZvcndhcmRpbmcgc3RhdGUNClsgIDM0NS4zNDk0NThdIHhlbl9icmlkZ2U6IHBvcnQgNih2
aWY2LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzQ4LjUwMzg1OF0geGVuX2Jy
aWRnZTogcG9ydCA0KHZpZjQuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNDku
NjkwNjA5XSBkZXZpY2UgdmlmNy4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ3KSBb
MjAxNC0xMS0xOCAyMTo1MDo1NC42MzddIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwg
bWVtb3J5DQooZDcpIFsyMDE0LTExLTE4IDIxOjUwOjU0LjYzN10gYWJvdXQgdG8gZ2V0IHN0
YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjUwOjU0LjcxMV0gdHJhcHMuYzoyNTc5
OmQ3djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgw
MDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM1MC4yMzc0ODhd
IHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEg
KHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzNTEuMjU2MDU0XSB2aWYgdmlm
LTctMCB2aWY3LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzNTEuMjY0NDE0XSB4ZW5fYnJpZGdl
OiBwb3J0IDcodmlmNy4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM1MS4yNzI2
MDddIHhlbl9icmlkZ2U6IHBvcnQgNyh2aWY3LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0
ZQ0KWyAgMzU0LjI2Njg3MV0geGVuX2JyaWRnZTogcG9ydCA1KHZpZjUuMCkgZW50ZXJlZCBm
b3J3YXJkaW5nIHN0YXRlDQpbICAzNTUuNzIxNjcwXSBkZXZpY2UgdmlmOC4wIGVudGVyZWQg
cHJvbWlzY3VvdXMgbW9kZQ0KKGQ4KSBbMjAxNC0xMS0xOCAyMTo1MTowMC43NjRdIG1hcHBp
bmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDgpIFsyMDE0LTExLTE4IDIxOjUx
OjAwLjc2NF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NCihYRU4pIFsyMDE0LTExLTE4IDIx
OjUxOjAwLjgzOF0gdHJhcHMuYzoyNTc5OmQ4djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAw
MDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAw
MDAwZmZmZi4NClsgIDM1Ni4zNjM0MzZdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50
LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRz
DQpbICAzNTcuMzgwODYxXSB2aWYgdmlmLTgtMCB2aWY4LjA6IEd1ZXN0IFJ4IHJlYWR5DQpb
ICAzNTcuMzg4NzE5XSB4ZW5fYnJpZGdlOiBwb3J0IDgodmlmOC4wKSBlbnRlcmVkIGZvcndh
cmRpbmcgc3RhdGUNClsgIDM1Ny4zOTYzODBdIHhlbl9icmlkZ2U6IHBvcnQgOCh2aWY4LjAp
IGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzYwLjQwMzE0M10geGVuX2JyaWRnZTog
cG9ydCA2KHZpZjYuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzNjEuODQwMzQ4
XSBkZXZpY2UgdmlmOS4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQ5KSBbMjAxNC0x
MS0xOCAyMTo1MTowNi43OTRdIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5
DQooZDkpIFsyMDE0LTExLTE4IDIxOjUxOjA2Ljc5NF0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQu
Li4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjUxOjA2Ljg4MV0gdHJhcHMuYzoyNTc5OmQ5djAg
RG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAw
MDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM2Mi40MTA5MjddIHhlbi1i
bGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTcsIHByb3RvY29sIDEgKHg4Nl82
NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzNjIuNDc3MTkwXSB2aWYgdmlmLTktMCB2
aWY5LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzNjIuNDg0MjQ3XSB4ZW5fYnJpZGdlOiBwb3J0
IDkodmlmOS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM2Mi40OTA5NTRdIHhl
bl9icmlkZ2U6IHBvcnQgOSh2aWY5LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NTE6MDcuNDI5XSBncmFudF90YWJsZS5jOjMwNTpkMHYwIElu
Y3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDMgZnJhbWVzDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1MTowNy40NDZdIGdyYW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNr
IHNpemUgdG8gNCBmcmFtZXMNClsgIDM2Ni4zMjYxMzRdIHhlbl9icmlkZ2U6IHBvcnQgNyh2
aWY3LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzY4LjIyNDE3Ml0gZGV2aWNl
IHZpZjEwLjAgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQooZDEwKSBbMjAxNC0xMS0xOCAy
MTo1MToxMy4xNzddIG1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQooZDEw
KSBbMjAxNC0xMS0xOCAyMTo1MToxMy4xNzddIGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQoo
WEVOKSBbMjAxNC0xMS0xOCAyMTo1MToxMy4yNTZdIHRyYXBzLmM6MjU3OTpkMTB2MCBEb21h
aW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAw
MDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLg0KWyAgMzY4LjcyMDAwNF0geGVuLWJsa2Jh
Y2s6cmluZy1yZWYgOCwgZXZlbnQtY2hhbm5lbCAxMCwgcHJvdG9jb2wgMSAoeDg2XzY0LWFi
aSkgcGVyc2lzdGVudCBncmFudHMNClsgIDM2OC44ODU4NDFdIHZpZiB2aWYtMTAtMCB2aWYx
MC4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzY4Ljg5MjcxMl0geGVuX2JyaWRnZTogcG9ydCAx
MCh2aWYxMC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM2OC44OTk2NjNdIHhl
bl9icmlkZ2U6IHBvcnQgMTAodmlmMTAuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpb
ICAzNzIuNDA5MTg1XSB4ZW5fYnJpZGdlOiBwb3J0IDgodmlmOC4wKSBlbnRlcmVkIGZvcndh
cmRpbmcgc3RhdGUNCihYRU4pIFsyMDE0LTExLTE4IDIxOjUxOjE4Ljg2MF0gZ3JhbnRfdGFi
bGUuYzozMDU6ZDB2MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA1IGZyYW1lcw0KWyAg
Mzc0LjM1NzQ3OV0gZGV2aWNlIHZpZjExLjAgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQoo
ZDExKSBbMjAxNC0xMS0xOCAyMTo1MToxOS4zMTBdIG1hcHBpbmcga2VybmVsIGludG8gcGh5
c2ljYWwgbWVtb3J5DQooZDExKSBbMjAxNC0xMS0xOCAyMTo1MToxOS4zMTBdIGFib3V0IHRv
IGdldCBzdGFydGVkLi4uDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MToxOS40MDddIHRyYXBz
LmM6MjU3OTpkMTF2MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQg
ZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLg0KWyAgMzc0
Ljk1MjMzNF0geGVuLWJsa2JhY2s6cmluZy1yZWYgOCwgZXZlbnQtY2hhbm5lbCAxNywgcHJv
dG9jb2wgMSAoeDg2XzY0LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDM3NS4wMTg3Njld
IHZpZiB2aWYtMTEtMCB2aWYxMS4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzc1LjAyNTYxN10g
eGVuX2JyaWRnZTogcG9ydCAxMSh2aWYxMS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUN
ClsgIDM3NS4wMzI0NDhdIHhlbl9icmlkZ2U6IHBvcnQgMTEodmlmMTEuMCkgZW50ZXJlZCBm
b3J3YXJkaW5nIHN0YXRlDQpbICAzNzcuNTMxNzcxXSB4ZW5fYnJpZGdlOiBwb3J0IDkodmlm
OS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM4MC43Mzc4MzJdIGRldmljZSB2
aWYxMi4wIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KKGQxMikgWzIwMTQtMTEtMTggMjE6
NTE6MjUuNjg5XSBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQxMikg
WzIwMTQtMTEtMTggMjE6NTE6MjUuNjg5XSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLg0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NTE6MjUuNzgwXSB0cmFwcy5jOjI1Nzk6ZDEydjAgRG9tYWlu
IGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAw
MDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4NClsgIDM4MS4yNDE2ODVdIHhlbi1ibGtiYWNr
OnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkp
IHBlcnNpc3RlbnQgZ3JhbnRzDQpbICAzODEuMzgxMTcyXSB2aWYgdmlmLTEyLTAgdmlmMTIu
MDogR3Vlc3QgUnggcmVhZHkNClsgIDM4MS4zODgwNDVdIHhlbl9icmlkZ2U6IHBvcnQgMTIo
dmlmMTIuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzODEuMzk1MDM0XSB4ZW5f
YnJpZGdlOiBwb3J0IDEyKHZpZjEyLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAg
MzgzLjkzNTAzNV0geGVuX2JyaWRnZTogcG9ydCAxMCh2aWYxMC4wKSBlbnRlcmVkIGZvcndh
cmRpbmcgc3RhdGUNClsgIDM4Ni44NzA0MThdIGRldmljZSB2aWYxMy4wIGVudGVyZWQgcHJv
bWlzY3VvdXMgbW9kZQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTE6MzEuODY2XSBBTUQtVmk6
IERpc2FibGU6IGRldmljZSBpZCA9IDB4YTQsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTE6MzEuODY2XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE0LCB0eXBlID0gMHg3LCByb290IHRhYmxlID0g
MHg1MTIzZjYwMDAsIGRvbWFpbiA9IDEzLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDE0
LTExLTE4IDIxOjUxOjMxLjg2Nl0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowMzowNi4wIGZy
b20gZG9tMCB0byBkb20xMw0KKGQxMykgWzIwMTQtMTEtMTggMjE6NTE6MzEuODcyXSBtYXBw
aW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQxMykgWzIwMTQtMTEtMTggMjE6
NTE6MzEuODcyXSBhYm91dCB0byBnZXQgc3RhcnRlZC4uLg0KWyAgMzg3LjAwNDI1MF0geGVu
X3BjaWJhY2s6IHZwY2k6IDAwMDA6MDM6MDYuMDogYXNzaWduIHRvIHZpcnR1YWwgc2xvdCAw
DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTozMi4xMDhdIHRyYXBzLmM6MjU3OTpkMTN2MCBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAw
MDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLg0KWyAgMzg3LjYyMTQ2NF0geGVuLWJs
a2JhY2s6cmluZy1yZWYgOSwgZXZlbnQtY2hhbm5lbCAxMSwgcHJvdG9jb2wgMSAoeDg2XzY0
LWFiaSkgcGVyc2lzdGVudCBncmFudHMNClsgIDM4OC42Mzk1NDhdIHZpZiB2aWYtMTMtMCB2
aWYxMy4wOiBHdWVzdCBSeCByZWFkeQ0KWyAgMzg4LjY0NjM2MF0geGVuX2JyaWRnZTogcG9y
dCAxMyh2aWYxMy4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDM4OC42NTMxNzZd
IHhlbl9icmlkZ2U6IHBvcnQgMTModmlmMTMuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRl
DQpbICAzODguNzE1NzIzXSBwY2liYWNrIDAwMDA6MDM6MDYuMDogZW5hYmxpbmcgZGV2aWNl
ICgwMDAwIC0+IDAwMDEpDQpbICAzODguNzIyNDI1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAy
MiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgMzg4LjcyOTA3MF0gQWxyZWFkeSBzZXR1
cCB0aGUgR1NJIDoyMg0KWyAgMzg4LjczNjcxNl0gcGNpYmFjayAwMDAwOjAzOjA2LjA6IGVu
YWJsaW5nIGJ1cyBtYXN0ZXJpbmcNClsgIDM5MC4wNzEzOTldIHhlbl9icmlkZ2U6IHBvcnQg
MTEodmlmMTEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICAzOTIuOTUzMzg3XSBk
ZXZpY2UgdmlmMTQuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNCihkMTQpIFsyMDE0LTEx
LTE4IDIxOjUxOjM3LjkyMl0gbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkN
CihkMTQpIFsyMDE0LTExLTE4IDIxOjUxOjM3LjkyMl0gYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQu
Li4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjUxOjM4LjAxMl0gdHJhcHMuYzoyNTc5OmQxNHYw
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAw
MDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuDQpbICAzOTMuNTQxOTQ4XSB4ZW4t
YmxrYmFjazpyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDEwLCBwcm90b2NvbCAxICh4ODZf
NjQtYWJpKSBwZXJzaXN0ZW50IGdyYW50cw0KWyAgMzk0LjU2MjA4NF0gdmlmIHZpZi0xNC0w
IHZpZjE0LjA6IEd1ZXN0IFJ4IHJlYWR5DQpbICAzOTQuNTY4ODI0XSB4ZW5fYnJpZGdlOiBw
b3J0IDE0KHZpZjE0LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgMzk0LjU3NTcy
Ml0geGVuX2JyaWRnZTogcG9ydCAxNCh2aWYxNC4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3Rh
dGUNClsgIDM5Ni40MjEzMzNdIHhlbl9icmlkZ2U6IHBvcnQgMTIodmlmMTIuMCkgZW50ZXJl
ZCBmb3J3YXJkaW5nIHN0YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTo0Mi4wODRdIGdy
YW50X3RhYmxlLmM6MzA1OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gNiBmcmFt
ZXMNClsgIDM5OC45Njk3MjRdIGRldmljZSB2aWYxNS4wIGVudGVyZWQgcHJvbWlzY3VvdXMg
bW9kZQ0KKGQxNSkgWzIwMTQtMTEtMTggMjE6NTE6NDMuOTI0XSBtYXBwaW5nIGtlcm5lbCBp
bnRvIHBoeXNpY2FsIG1lbW9yeQ0KKGQxNSkgWzIwMTQtMTEtMTggMjE6NTE6NDMuOTI0XSBh
Ym91dCB0byBnZXQgc3RhcnRlZC4uLg0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTE6NDQuMDE0
XSB0cmFwcy5jOjI1Nzk6ZDE1djAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4N
ClsgIDM5OS41Mzg5MzZdIHhlbi1ibGtiYWNrOnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwg
MTAsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpIHBlcnNpc3RlbnQgZ3JhbnRzDQpbICA0MDAu
NTU2NzcxXSB2aWYgdmlmLTE1LTAgdmlmMTUuMDogR3Vlc3QgUnggcmVhZHkNClsgIDQwMC41
NjM0MzBdIHZwbl9icmlkZ2U6IHBvcnQgMSh2aWYxNS4wKSBlbnRlcmVkIGZvcndhcmRpbmcg
c3RhdGUNClsgIDQwMC41NzAxODddIHZwbl9icmlkZ2U6IHBvcnQgMSh2aWYxNS4wKSBlbnRl
cmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDQwMy42NzgyNTVdIHhlbl9icmlkZ2U6IHBvcnQg
MTModmlmMTMuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICA0MDUuMTE5MTU1XSBk
ZXZpY2UgdmlmMTYuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNClsgIDQwNS4zMzkzNjdd
IGRldmljZSB2aWYxNi4wLWVtdSBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUNClsgIDQwNS4z
NTE5MDZdIHhlbl9icmlkZ2U6IHBvcnQgMTYodmlmMTYuMC1lbXUpIGVudGVyZWQgZm9yd2Fy
ZGluZyBzdGF0ZQ0KWyAgNDA1LjM1ODU4OV0geGVuX2JyaWRnZTogcG9ydCAxNih2aWYxNi4w
LWVtdSkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICA0MDYuNDM5OTM3XSBwY2liYWNr
IDAwMDA6MDg6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHgzYyAo
d2FzIDB4MTAwLCB3cml0aW5nIDB4MTA3KQ0KWyAgNDA2LjQ0ODczMl0gcGNpYmFjayAwMDAw
OjA4OjAwLjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4MTAgKHdhcyAw
eDQsIHdyaXRpbmcgMHhmZTBmZTAwNCkNClsgIDQwNi40NTczMzVdIHBjaWJhY2sgMDAwMDow
ODowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweGMgKHdhcyAweDAs
IHdyaXRpbmcgMHgxMCkNCihYRU4pIFsyMDE0LTExLTE4IDIxOjUxOjUxLjM1MV0gaW8uYzo1
ODQ6IGQxNjogYmluZDogbV9nc2k9MzcgZ19nc2k9MzYgZGV2PTAwLjAwLjUgaW50eD0wIGZm
ZmY4MzA1MTg2YzU4MjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjUxOjUxLjc1Ml0gQU1ELVZp
OiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDgwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTo1MS43NTJdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4ODAwLCB0eXBlID0gMHgxLCByb290IHRhYmxl
ID0gMHg1MDhhYTAwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDE0LTExLTE4IDIxOjUxOjUxLjc1Ml0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowODowMC4w
IGZyb20gZG9tMCB0byBkb20xNg0KWyAgNDA3Ljg5NDAwOV0gcGNpYmFjayAwMDAwOjBhOjAw
LjA6IHJlc3RvcmluZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4M2MgKHdhcyAweDEwMCwg
d3JpdGluZyAweDEwYSkNClsgIDQwNy45MDE5MDRdIHBjaWJhY2sgMDAwMDowYTowMC4wOiBy
ZXN0b3JpbmcgY29uZmlnIHNwYWNlIGF0IG9mZnNldCAweDEwICh3YXMgMHg0LCB3cml0aW5n
IDB4ZmUyMDAwMDQpDQpbICA0MDcuOTA4NDA5XSBwY2liYWNrIDAwMDA6MGE6MDAuMDogcmVz
dG9yaW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZzZXQgMHhjICh3YXMgMHgwLCB3cml0aW5nIDB4
MTApDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MDJdIGlvLmM6NTg0OiBkMTY6IGJp
bmQ6IG1fZ3NpPTQ3IGdfZ3NpPTQwIGRldj0wMC4wMC42IGludHg9MCBmZmZmODMwMzc3MzQ1
MGE4DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MDhdIEFNRC1WaTogRGlzYWJsZTog
ZGV2aWNlIGlkID0gMHhhMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NTE6NTIuODA4XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweGEwMCwgdHlwZSA9IDB4MSwgcm9vdCB0YWJsZSA9IDB4NTA4YWEw
MDAwLCBkb21haW4gPSAxNiwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1MTo1Mi44MDhdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMCBmcm9tIGRvbTAg
dG8gZG9tMTYNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUyLjgxOV0gSFZNIExvYWRlcg0K
KGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIuODE5XSBEZXRlY3RlZCBYZW4gdjQuNS4wLXJj
DQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MTldIFhlbmJ1cyByaW5ncyBAMHhmZWZm
YzAwMCwgZXZlbnQgY2hhbm5lbCAxDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MTld
IFN5c3RlbSByZXF1ZXN0ZWQgU2VhQklPUw0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIu
ODE5XSBDUFUgc3BlZWQgaXMgMzIwMCBNSHoNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUy
LjgxOV0gUmVsb2NhdGluZyBndWVzdCBtZW1vcnkgZm9yIGxvd21lbSBNTUlPIHNwYWNlIGRp
c2FibGVkDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MTldIGlycS5jOjI3MDogRG9t
MTYgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6
NTIuODE5XSBQQ0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJRNQ0KKFhFTikgWzIwMTQtMTEt
MTggMjE6NTE6NTIuODIwXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAw
IC0+IDEwDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MjBdIFBDSS1JU0EgbGluayAx
IHJvdXRlZCB0byBJUlExMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTE6NTIuODIwXSBpcnEu
YzoyNzA6IERvbTE2IFBDSSBsaW5rIDIgY2hhbmdlZCAwIC0+IDExDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1Mi44MjBdIFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NTE6NTIuODIwXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5r
IDMgY2hhbmdlZCAwIC0+IDUNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUyLjgyMF0gUENJ
LUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUNClsgIDQwNy45NDgyNThdIHhlbl9wY2liYWNr
OiB2cGNpOiAwMDAwOjA4OjAwLjA6IGFzc2lnbiB0byB2aXJ0dWFsIHNsb3QgMA0KWyAgNDA3
Ljk1NTcyMV0geGVuX3BjaWJhY2s6IHZwY2k6IDAwMDA6MGE6MDAuMDogYXNzaWduIHRvIHZp
cnR1YWwgc2xvdCAxDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44MzddIHBjaSBkZXYg
MDE6MiBJTlRELT5JUlE1DQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi44NDNdIHBjaSBk
ZXYgMDE6MyBJTlRBLT5JUlExMA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIuODQ4XSBw
Y2kgZGV2IDAyOjAgSU5UQS0+SVJRMTENCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUyLjg1
OF0gcGNpIGRldiAwNDowIElOVEEtPklSUTUNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUy
Ljg2NV0gcGNpIGRldiAwNTowIElOVEEtPklSUTEwDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1
MTo1Mi44NzFdIHBjaSBkZXYgMDY6MCBJTlRBLT5JUlExMQ0KKGQxNikgWzIwMTQtMTEtMTgg
MjE6NTE6NTIuOTE2XSBObyBSQU0gaW4gaGlnaCBtZW1vcnk7IHNldHRpbmcgaGlnaF9tZW0g
cmVzb3VyY2UgYmFzZSB0byAxMDAwMDAwMDANCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUy
LjkxNl0gcGNpIGRldiAwMzowIGJhciAxMCBzaXplIDAwMjAwMDAwMDogMGYwMDAwMDA4DQoo
ZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi45MThdIHBjaSBkZXYgMDI6MCBiYXIgMTQgc2l6
ZSAwMDEwMDAwMDA6IDBmMjAwMDAwOA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIuOTIx
XSBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMjAwMDAwOiAwZjMwMDAwMDQNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjUxOjUyLjkyMV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1m
MzAwMCBtZm49ZmUyMDAgbnI9MjAwDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi45MjZd
IHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAwNDAwMDA6IDBmMzIwMDAwMA0KKGQxNikg
WzIwMTQtMTEtMTggMjE6NTE6NTIuOTI5XSBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAw
MDIwMDAwOiAwZjMyNDAwMDANCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUyLjkyOV0gcGNp
IGRldiAwMzowIGJhciAzMCBzaXplIDAwMDAxMDAwMDogMGYzMjYwMDAwDQooZDE2KSBbMjAx
NC0xMS0xOCAyMTo1MTo1Mi45MzBdIHBjaSBkZXYgMDU6MCBiYXIgMTAgc2l6ZSAwMDAwMDIw
MDA6IDBmMzI3MDAwNA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTE6NTIuOTMwXSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1Mi45MzZdIHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDA6
IDBmMzI3MjAwMA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIuOTM3XSBwY2kgZGV2IDAy
OjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDENCihkMTYpIFsyMDE0LTExLTE4
IDIxOjUxOjUyLjkzOV0gcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDA0MDogMDAw
MDBjMTAxDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi45NDJdIHBjaSBkZXYgMDE6MiBi
YXIgMjAgc2l6ZSAwMDAwMDAwMjA6IDAwMDAwYzE0MQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6
NTE6NTIuOTQ0XSBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMDEwOiAwMDAwMGMx
NjENCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUyLjk0N10gTXVsdGlwcm9jZXNzb3IgaW5p
dGlhbGlzYXRpb246DQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Mi45NzJdICAtIENQVTAg
Li4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4u
LiBkb25lLg0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTIuOTk0XSAgLSBDUFUxIC4uLiA0
OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9u
ZS4NCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjAxM10gIC0gQ1BVMiAuLi4gNDgtYml0
IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuDQoo
ZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4wMzNdICAtIENQVTMgLi4uIDQ4LWJpdCBwaHlz
IC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLg0KKGQxNikg
WzIwMTQtMTEtMTggMjE6NTE6NTMuMDMzXSBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoNCihk
MTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjA0Ml0gIC0gUkVQIElOU0IgYWNyb3NzIHBhZ2Ug
Ym91bmRhcmllcyAuLi4gcGFzc2VkDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4wNDZd
ICAtIEdTIGJhc2UgTVNScyBhbmQgU1dBUEdTIC4uLiBwYXNzZWQNCihkMTYpIFsyMDE0LTEx
LTE4IDIxOjUxOjUzLjA0Nl0gUGFzc2VkIDIgb2YgMiB0ZXN0cw0KKGQxNikgWzIwMTQtMTEt
MTggMjE6NTE6NTMuMDQ2XSBXcml0aW5nIFNNQklPUyB0YWJsZXMgLi4uDQooZDE2KSBbMjAx
NC0xMS0xOCAyMTo1MTo1My4wNDddIExvYWRpbmcgU2VhQklPUyAuLi4NCihkMTYpIFsyMDE0
LTExLTE4IDIxOjUxOjUzLjA0N10gQ3JlYXRpbmcgTVAgdGFibGVzIC4uLg0KKGQxNikgWzIw
MTQtMTEtMTggMjE6NTE6NTMuMDQ4XSBMb2FkaW5nIEFDUEkgLi4uDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1My4wNDldIHZtODYgVFNTIGF0IGZjMDBhMjAwDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1My4wNTBdIEJJT1MgbWFwOg0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6
NTMuMDUwXSAgMTAwMDAtMTAwZDM6IFNjcmF0Y2ggc3BhY2UNCihkMTYpIFsyMDE0LTExLTE4
IDIxOjUxOjUzLjA1MF0gIGMwMDAwLWZmZmZmOiBNYWluIEJJT1MNCihkMTYpIFsyMDE0LTEx
LTE4IDIxOjUxOjUzLjA1MF0gRTgyMCB0YWJsZToNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUx
OjUzLjA1MF0gIFswMF06IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6
IFJBTQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMDUwXSAgSE9MRTogMDAwMDAwMDA6
MDAwYTAwMDAgLSAwMDAwMDAwMDowMDBjMDAwMA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6
NTMuMDUwXSAgWzAxXTogMDAwMDAwMDA6MDAwYzAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDog
UkVTRVJWRUQNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjA1MF0gIFswMl06IDAwMDAw
MDAwOjAwMTAwMDAwIC0gMDAwMDAwMDA6M2Y4MDAwMDA6IFJBTQ0KKGQxNikgWzIwMTQtMTEt
MTggMjE6NTE6NTMuMDUwXSAgSE9MRTogMDAwMDAwMDA6M2Y4MDAwMDAgLSAwMDAwMDAwMDpm
YzAwMDAwMA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMDUwXSAgWzAzXTogMDAwMDAw
MDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQNCihkMTYpIFsyMDE0
LTExLTE4IDIxOjUxOjUzLjA1MF0gSW52b2tpbmcgU2VhQklPUyAuLi4NCihkMTYpIFsyMDE0
LTExLTE4IDIxOjUxOjUzLjA1M10gU2VhQklPUyAodmVyc2lvbiByZWwtMS43LjUtMC1nZTUx
NDg4Yy0yMDE0MTExOF8yMjMwNDMtc2VydmVlcnN0ZXJ0amUpDQooZDE2KSBbMjAxNC0xMS0x
OCAyMTo1MTo1My4wNTNdIA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMDUzXSBGb3Vu
ZCBYZW4gaHlwZXJ2aXNvciBzaWduYXR1cmUgYXQgNDAwMDAwMDANCihkMTYpIFsyMDE0LTEx
LTE4IDIxOjUxOjUzLjA1M10gUnVubmluZyBvbiBRRU1VIChpNDQwZngpDQooZDE2KSBbMjAx
NC0xMS0xOCAyMTo1MTo1My4wNTNdIHhlbjogY29weSBlODIwLi4uDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1My4wNTNdIFJlbG9jYXRpbmcgaW5pdCBmcm9tIDB4MDAwZGY2MjkgdG8g
MHgzZjdhZTYwMCAoc2l6ZSA3MTk5NSkNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjA1
Nl0gQ1BVIE1oej0zMjAxDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4wNjFdIEZvdW5k
IDEwIFBDSSBkZXZpY2VzIChtYXggUENJIGJ1cyBpcyAwMCkNCihkMTYpIFsyMDE0LTExLTE4
IDIxOjUxOjUzLjA2MV0gQWxsb2NhdGVkIFhlbiBoeXBlcmNhbGwgcGFnZSBhdCAzZjdmZjAw
MA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMDYxXSBEZXRlY3RlZCBYZW4gdjQuNS4w
LXJjDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4wNjFdIHhlbjogY29weSBCSU9TIHRh
Ymxlcy4uLg0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMDYxXSBDb3B5aW5nIFNNQklP
UyBlbnRyeSBwb2ludCBmcm9tIDB4MDAwMTAwMTAgdG8gMHgwMDBmMGY1MA0KKGQxNikgWzIw
MTQtMTEtMTggMjE6NTE6NTMuMDYxXSBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMWEw
L2ZjMDAxMWIwIHRvIDB4MDAwZjBlMzANCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjA2
MV0gQ29weWluZyBQSVIgZnJvbSAweDAwMDEwMDMwIHRvIDB4MDAwZjBkYjANCihkMTYpIFsy
MDE0LTExLTE4IDIxOjUxOjUzLjA2MV0gQ29weWluZyBBQ1BJIFJTRFAgZnJvbSAweDAwMDEw
MGIwIHRvIDB4MDAwZjBkODANCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjA2Ml0gVXNp
bmcgcG10aW1lciwgaW9wb3J0IDB4YjAwOA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMu
MDYyXSBTY2FuIGZvciBWR0Egb3B0aW9uIHJvbQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6
NTMuMDc5XSBSdW5uaW5nIG9wdGlvbiByb20gYXQgYzAwMDowMDAzDQooWEVOKSBbMjAxNC0x
MS0xOCAyMTo1MTo1My4wODhdIHN0ZHZnYS5jOjE0NzpkMTZ2MCBlbnRlcmluZyBzdGR2Z2Eg
YW5kIGNhY2hpbmcgbW9kZXMNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjExNV0gcG1t
IGNhbGwgYXJnMT0wDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4xMTZdIFR1cm5pbmcg
b24gdmdhIHRleHQgbW9kZSBjb25zb2xlDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4y
MzRdIFNlYUJJT1MgKHZlcnNpb24gcmVsLTEuNy41LTAtZ2U1MTQ4OGMtMjAxNDExMThfMjIz
MDQzLXNlcnZlZXJzdGVydGplKQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMjQ4XSBN
YWNoaW5lIFVVSUQgYzM5YTYwNzktMDUzNi00NDJmLWE2YjUtZjhkMzAzNjk3YzFhDQooZDE2
KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNDhdIFhIQ0kgaW5pdCBvbiBkZXYgMDA6MDUuMDog
cmVncyBAIDB4ZjMyNzAwMDAsIDQgcG9ydHMsIDMyIHNsb3RzLCAzMiBieXRlIGNvbnRleHQN
CihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjI0OF0gcw0KKGQxNikgWzIwMTQtMTEtMTgg
MjE6NTE6NTMuMjQ4XSBYSENJICAgIGV4dGNhcCAweDEgQCBmMzI3MDUwMA0KKGQxNikgWzIw
MTQtMTEtMTggMjE6NTE6NTMuMjQ4XSBYSENJICAgIHByb3RvY29sIFVTQiAgMy4wMCwgMiBw
b3J0cyAob2Zmc2V0IDEpLCBkZWYgMA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMjQ4
XSBYSENJICAgIHByb3RvY29sIFVTQiAgMi4wMCwgMiBwb3J0cyAob2Zmc2V0IDMpLCBkZWYg
MA0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMjQ5XSBVSENJIGluaXQgb24gZGV2IDAw
OjAxLjIgKGlvPWMxNDApDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNTBdIEZvdW5k
IDAgbHB0IHBvcnRzDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNTFdIEZvdW5kIDEg
c2VyaWFsIHBvcnRzDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNTJdIEFUQSBjb250
cm9sbGVyIDEgYXQgMWYwLzNmNC8wIChpcnEgMTQgZGV2IDkpDQooZDE2KSBbMjAxNC0xMS0x
OCAyMTo1MTo1My4yNTNdIEFUQSBjb250cm9sbGVyIDIgYXQgMTcwLzM3NC8wIChpcnEgMTUg
ZGV2IDkpDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNTZdIGF0YTAtMDogUUVNVSBI
QVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDEwMjQwIE1pQnl0ZXMpDQooZDE2KSBbMjAxNC0x
MS0xOCAyMTo1MTo1My4yNTZdIFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4
LypAMSwxL2RyaXZlQDAvZGlza0AwDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My4yNThd
IGF0YTAtMTogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDMwMCBHaUJ5dGVzKQ0K
KGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTMuMjU4XSBTZWFyY2hpbmcgYm9vdG9yZGVyIGZv
cjogL3BjaUBpMGNmOC8qQDEsMS9kcml2ZUAwL2Rpc2tAMQ0KKGQxNikgWzIwMTQtMTEtMTgg
MjE6NTE6NTMuMzU2XSBQUzIga2V5Ym9hcmQgaW5pdGlhbGl6ZWQNCihkMTYpIFsyMDE0LTEx
LTE4IDIxOjUxOjUzLjQwMV0gWEhDSSBwb3J0ICM0OiAweDAwMjAwYTAzLCBwb3dlcmVkLCBl
bmFibGVkLCBwbHMgMCwgc3BlZWQgMiBbTG93XQ0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6
NTMuNDMxXSBYSENJIG5vIGRldmljZXMgZm91bmQNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUx
OjUzLjQ0Ml0gQWxsIHRocmVhZHMgY29tcGxldGUuDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1
MTo1My40NDJdIFNjYW4gZm9yIG9wdGlvbiByb21zDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1
MTo1My40NjhdIFJ1bm5pbmcgb3B0aW9uIHJvbSBhdCBjOTgwOjAwMDMNCihkMTYpIFsyMDE0
LTExLTE4IDIxOjUxOjUzLjQ3NV0gcG1tIGNhbGwgYXJnMT0xDQooZDE2KSBbMjAxNC0xMS0x
OCAyMTo1MTo1My40NzZdIHBtbSBjYWxsIGFyZzE9MA0KKGQxNikgWzIwMTQtMTEtMTggMjE6
NTE6NTMuNDc3XSBwbW0gY2FsbCBhcmcxPTENCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUz
LjQ3OF0gcG1tIGNhbGwgYXJnMT0wDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My40OTRd
IFNlYXJjaGluZyBib290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4LypANA0KKGQxNikgWzIwMTQt
MTEtMTggMjE6NTE6NTMuNDk0XSANCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjUzLjUwMV0g
UHJlc3MgRjEyIGZvciBib290IG1lbnUuDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1My41
MDJdIA0KWyAgNDA5LjYwMTI3N10geGVuX2JyaWRnZTogcG9ydCAxNCh2aWYxNC4wKSBlbnRl
cmVkIGZvcndhcmRpbmcgc3RhdGUNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjU2LjA0N10g
U2VhcmNoaW5nIGJvb3RvcmRlciBmb3I6IEhBTFQNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUx
OjU2LjA0N10gZHJpdmUgMHgwMDBmMGQzMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlv
bj1sYmEgTENIUz0xMDI0LzI1NS82MyBzPTIwOTcxNTIwDQooZDE2KSBbMjAxNC0xMS0xOCAy
MTo1MTo1Ni4wNDddIGRyaXZlIDB4MDAwZjBkMDA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNs
YXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMgcz02MjkxNDU2MDANCihkMTYpIFsyMDE0LTEx
LTE4IDIxOjUxOjU2LjA0N10gDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Ni4wNDddIFNw
YWNlIGF2YWlsYWJsZSBmb3IgVU1COiBjYTgwMC1lZjAwMCwgZjAwMDAtZjBkMDANCihkMTYp
IFsyMDE0LTExLTE4IDIxOjUxOjU2LjA0N10gUmV0dXJuZWQgMjUzOTUyIGJ5dGVzIG9mIFpv
bmVIaWdoDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Ni4wNDddIGU4MjAgbWFwIGhhcyA2
IGl0ZW1zOg0KKGQxNikgWzIwMTQtMTEtMTggMjE6NTE6NTYuMDQ3XSAgIDA6IDAwMDAwMDAw
MDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwID0gMSBSQU0NCihkMTYpIFsyMDE0LTExLTE4
IDIxOjUxOjU2LjA0N10gICAxOiAwMDAwMDAwMDAwMDlmYzAwIC0gMDAwMDAwMDAwMDBhMDAw
MCA9IDIgUkVTRVJWRUQNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjU2LjA0N10gICAyOiAw
MDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCA9IDIgUkVTRVJWRUQNCihkMTYp
IFsyMDE0LTExLTE4IDIxOjUxOjU2LjA0N10gICAzOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAw
MDAwMDAzZjdmZTAwMCA9IDEgUkFNDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Ni4wNDdd
ICAgNDogMDAwMDAwMDAzZjdmZTAwMCAtIDAwMDAwMDAwM2Y4MDAwMDAgPSAyIFJFU0VSVkVE
DQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Ni4wNDddICAgNTogMDAwMDAwMDBmYzAwMDAw
MCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJFU0VSVkVEDQooZDE2KSBbMjAxNC0xMS0xOCAy
MTo1MTo1Ni4wNDhdIGVudGVyIGhhbmRsZV8xOToNCihkMTYpIFsyMDE0LTExLTE4IDIxOjUx
OjU2LjA0OF0gICBOVUxMDQooZDE2KSBbMjAxNC0xMS0xOCAyMTo1MTo1Ni4wNTRdIEJvb3Rp
bmcgZnJvbSBIYXJkIERpc2suLi4NCihkMTYpIFsyMDE0LTExLTE4IDIxOjUxOjU2LjA1N10g
Qm9vdGluZyBmcm9tIDAwMDA6N2MwMA0KWyAgNDE0LjkyNTU3Nl0gZGV2aWNlIHZpZjE3LjAg
ZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQpbICA0MTUuMDkzMDYwXSBkZXZpY2UgdmlmMTcu
MC1lbXUgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlDQpbICA0MTUuMTAzMjYzXSB4ZW5fYnJp
ZGdlOiBwb3J0IDE4KHZpZjE3LjAtZW11KSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsg
IDQxNS4xMDk3OTJdIHhlbl9icmlkZ2U6IHBvcnQgMTgodmlmMTcuMC1lbXUpIGVudGVyZWQg
Zm9yd2FyZGluZyBzdGF0ZQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMDUxXSBIVk0g
TG9hZGVyDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4wNTFdIERldGVjdGVkIFhlbiB2
NC41LjAtcmMNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjA1MV0gWGVuYnVzIHJpbmdz
IEAweGZlZmZjMDAwLCBldmVudCBjaGFubmVsIDENCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjA1MV0gU3lzdGVtIHJlcXVlc3RlZCBTZWFCSU9TDQooZDE3KSBbMjAxNC0xMS0xOCAy
MTo1MjowMC4wNTFdIENQVSBzcGVlZCBpcyAzMjAwIE1Ieg0KKGQxNykgWzIwMTQtMTEtMTgg
MjE6NTI6MDAuMDUxXSBSZWxvY2F0aW5nIGd1ZXN0IG1lbW9yeSBmb3IgbG93bWVtIE1NSU8g
c3BhY2UgZGlzYWJsZWQNCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjAwLjA1Ml0gaXJxLmM6
MjcwOiBEb20xNyBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1DQooZDE3KSBbMjAxNC0xMS0x
OCAyMTo1MjowMC4wNTJdIFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1DQooWEVOKSBb
MjAxNC0xMS0xOCAyMTo1MjowMC4wNTJdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMSBj
aGFuZ2VkIDAgLT4gMTANCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjA1Ml0gUENJLUlT
QSBsaW5rIDEgcm91dGVkIHRvIElSUTEwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjowMC4w
NTJdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihkMTcp
IFsyMDE0LTExLTE4IDIxOjUyOjAwLjA1Ml0gUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElS
UTExDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjowMC4wNTJdIGlycS5jOjI3MDogRG9tMTcg
UENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAu
MDUyXSBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQ0KKGQxNykgWzIwMTQtMTEtMTgg
MjE6NTI6MDAuMDcxXSBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTANCihkMTcpIFsyMDE0LTEx
LTE4IDIxOjUyOjAwLjA3NV0gcGNpIGRldiAwMjowIElOVEEtPklSUTExDQooZDE3KSBbMjAx
NC0xMS0xOCAyMTo1MjowMC4wODZdIHBjaSBkZXYgMDQ6MCBJTlRBLT5JUlE1DQooZDE3KSBb
MjAxNC0xMS0xOCAyMTo1MjowMC4xNDVdIE5vIFJBTSBpbiBoaWdoIG1lbW9yeTsgc2V0dGlu
ZyBoaWdoX21lbSByZXNvdXJjZSBiYXNlIHRvIDEwMDAwMDAwMA0KKGQxNykgWzIwMTQtMTEt
MTggMjE6NTI6MDAuMTQ1XSBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAyMDAwMDAwOiAw
ZjAwMDAwMDgNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjE0N10gcGNpIGRldiAwMjow
IGJhciAxNCBzaXplIDAwMTAwMDAwMDogMGYyMDAwMDA4DQooZDE3KSBbMjAxNC0xMS0xOCAy
MTo1MjowMC4xNDldIHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSAwMDAwNDAwMDA6IDBmMzAw
MDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMTUxXSBwY2kgZGV2IDA0OjAgYmFy
IDEwIHNpemUgMDAwMDIwMDAwOiAwZjMwNDAwMDANCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjE1MV0gcGNpIGRldiAwMzowIGJhciAzMCBzaXplIDAwMDAxMDAwMDogMGYzMDYwMDAw
DQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4xNTRdIHBjaSBkZXYgMDM6MCBiYXIgMTQg
c2l6ZSAwMDAwMDEwMDA6IDBmMzA3MDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAu
MTU0XSBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDAwMDAwMTAwOiAwMDAwMGMwMDENCihk
MTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjE1Nl0gcGNpIGRldiAwNDowIGJhciAxNCBzaXpl
IDAwMDAwMDA0MDogMDAwMDBjMTAxDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4xNThd
IHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAwMTA6IDAwMDAwYzE0MQ0KKGQxNykg
WzIwMTQtMTEtMTggMjE6NTI6MDAuMTYwXSBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlv
bjoNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjE4Ml0gIC0gQ1BVMCAuLi4gNDgtYml0
IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuDQoo
ZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yMDJdICAtIENQVTEgLi4uIDQ4LWJpdCBwaHlz
IC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsxLzhdIC4uLiBkb25lLg0KKGQxNykg
WzIwMTQtMTEtMTggMjE6NTI6MDAuMjIwXSAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4g
Zml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMS84XSAuLi4gZG9uZS4NCihkMTcpIFsyMDE0
LTExLTE4IDIxOjUyOjAwLjI0MV0gIC0gQ1BVMyAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVk
IE1UUlJzIC4uLiB2YXIgTVRSUnMgWzEvOF0gLi4uIGRvbmUuDQooZDE3KSBbMjAxNC0xMS0x
OCAyMTo1MjowMC4yNDFdIFRlc3RpbmcgSFZNIGVudmlyb25tZW50Og0KKGQxNykgWzIwMTQt
MTEtMTggMjE6NTI6MDAuMjUwXSAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVz
IC4uLiBwYXNzZWQNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjI1NF0gIC0gR1MgYmFz
ZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBhc3NlZA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6
MDAuMjU0XSBQYXNzZWQgMiBvZiAyIHRlc3RzDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1Mjow
MC4yNTRdIFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDIx
OjUyOjAwLjI1Nl0gTG9hZGluZyBTZWFCSU9TIC4uLg0KKGQxNykgWzIwMTQtMTEtMTggMjE6
NTI6MDAuMjU2XSBDcmVhdGluZyBNUCB0YWJsZXMgLi4uDQooZDE3KSBbMjAxNC0xMS0xOCAy
MTo1MjowMC4yNTZdIExvYWRpbmcgQUNQSSAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjI1N10gdm04NiBUU1MgYXQgZmMwMGEyMDANCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjI1OF0gQklPUyBtYXA6DQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNThdICAx
MDAwMC0xMDBkMzogU2NyYXRjaCBzcGFjZQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAu
MjU4XSAgYzAwMDAtZmZmZmY6IE1haW4gQklPUw0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6
MDAuMjU4XSBFODIwIHRhYmxlOg0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMjU4XSAg
WzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkFNDQooZDE3
KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNThdICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAt
IDAwMDAwMDAwOjAwMGMwMDAwDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNThdICBb
MDFdOiAwMDAwMDAwMDowMDBjMDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBSRVNFUlZFRA0K
KGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMjU4XSAgWzAyXTogMDAwMDAwMDA6MDAxMDAw
MDAgLSAwMDAwMDAwMDozZjgwMDAwMDogUkFNDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1Mjow
MC4yNThdICBIT0xFOiAwMDAwMDAwMDozZjgwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwDQoo
ZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNThdICBbMDNdOiAwMDAwMDAwMDpmYzAwMDAw
MCAtIDAwMDAwMDAxOjAwMDAwMDAwOiBSRVNFUlZFRA0KKGQxNykgWzIwMTQtMTEtMTggMjE6
NTI6MDAuMjU4XSBJbnZva2luZyBTZWFCSU9TIC4uLg0KKGQxNykgWzIwMTQtMTEtMTggMjE6
NTI6MDAuMjYxXSBTZWFCSU9TICh2ZXJzaW9uIHJlbC0xLjcuNS0wLWdlNTE0ODhjLTIwMTQx
MTE4XzIyMzA0My1zZXJ2ZWVyc3RlcnRqZSkNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAw
LjI2MV0gDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNjFdIEZvdW5kIFhlbiBoeXBl
cnZpc29yIHNpZ25hdHVyZSBhdCA0MDAwMDAwMA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6
MDAuMjYxXSBSdW5uaW5nIG9uIFFFTVUgKGk0NDBmeCkNCihkMTcpIFsyMDE0LTExLTE4IDIx
OjUyOjAwLjI2MV0geGVuOiBjb3B5IGU4MjAuLi4NCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjI2MV0gUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBkZjYyOSB0byAweDNmN2FlNjAw
IChzaXplIDcxOTk1KQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMjY0XSBDUFUgTWh6
PTMyMDENCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjI2OF0gRm91bmQgNyBQQ0kgZGV2
aWNlcyAobWF4IFBDSSBidXMgaXMgMDApDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4y
NjhdIEFsbG9jYXRlZCBYZW4gaHlwZXJjYWxsIHBhZ2UgYXQgM2Y3ZmYwMDANCihkMTcpIFsy
MDE0LTExLTE4IDIxOjUyOjAwLjI2OF0gRGV0ZWN0ZWQgWGVuIHY0LjUuMC1yYw0KKGQxNykg
WzIwMTQtMTEtMTggMjE6NTI6MDAuMjY4XSB4ZW46IGNvcHkgQklPUyB0YWJsZXMuLi4NCihk
MTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjI2OF0gQ29weWluZyBTTUJJT1MgZW50cnkgcG9p
bnQgZnJvbSAweDAwMDEwMDEwIHRvIDB4MDAwZjBmNTANCihkMTcpIFsyMDE0LTExLTE4IDIx
OjUyOjAwLjI2OF0gQ29weWluZyBNUFRBQkxFIGZyb20gMHhmYzAwMTFhMC9mYzAwMTFiMCB0
byAweDAwMGYwZTMwDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNjhdIENvcHlpbmcg
UElSIGZyb20gMHgwMDAxMDAzMCB0byAweDAwMGYwZGIwDQooZDE3KSBbMjAxNC0xMS0xOCAy
MTo1MjowMC4yNjhdIENvcHlpbmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0byAweDAw
MGYwZDgwDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4yNjhdIFVzaW5nIHBtdGltZXIs
IGlvcG9ydCAweGIwMDgNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjI2OF0gU2NhbiBm
b3IgVkdBIG9wdGlvbiByb20NCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjI4NF0gUnVu
bmluZyBvcHRpb24gcm9tIGF0IGMwMDA6MDAwMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6
MDAuMjkyXSBzdGR2Z2EuYzoxNDc6ZDE3djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5n
IG1vZGVzDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC4zMTFdIHBtbSBjYWxsIGFyZzE9
MA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuMzEyXSBUdXJuaW5nIG9uIHZnYSB0ZXh0
IG1vZGUgY29uc29sZQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNDI4XSBTZWFCSU9T
ICh2ZXJzaW9uIHJlbC0xLjcuNS0wLWdlNTE0ODhjLTIwMTQxMTE4XzIyMzA0My1zZXJ2ZWVy
c3RlcnRqZSkNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjQ0MF0gTWFjaGluZSBVVUlE
IGJmYmFmM2NjLTVmNDgtNDBkNS1hNWY5LTNiOTg4ZGY2YzExNA0KKGQxNykgWzIwMTQtMTEt
MTggMjE6NTI6MDAuNDQxXSBBbGwgdGhyZWFkcyBjb21wbGV0ZS4NCihkMTcpIFsyMDE0LTEx
LTE4IDIxOjUyOjAwLjQ0Ml0gRm91bmQgMCBscHQgcG9ydHMNCihkMTcpIFsyMDE0LTExLTE4
IDIxOjUyOjAwLjQ0Ml0gRm91bmQgMCBzZXJpYWwgcG9ydHMNCihkMTcpIFsyMDE0LTExLTE4
IDIxOjUyOjAwLjQ0Ml0gQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAvM2Y0LzAgKGlycSAxNCBk
ZXYgOSkNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjQ0M10gQVRBIGNvbnRyb2xsZXIg
MiBhdCAxNzAvMzc0LzAgKGlycSAxNSBkZXYgOSkNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUy
OjAwLjQ0OF0gYXRhMC0wOiBRRU1VIEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAoMTAyNDAg
TWlCeXRlcykNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjQ0OF0gU2VhcmNoaW5nIGJv
b3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMC9kaXNrQDANClsgIDQxNS42
MzA5MTFdIHZwbl9icmlkZ2U6IHBvcnQgMSh2aWYxNS4wKSBlbnRlcmVkIGZvcndhcmRpbmcg
c3RhdGUNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjU0NV0gUFMyIGtleWJvYXJkIGlu
aXRpYWxpemVkDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC41NDVdIEFsbCB0aHJlYWRz
IGNvbXBsZXRlLg0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNTQ1XSBTY2FuIGZvciBv
cHRpb24gcm9tcw0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNTY1XSBSdW5uaW5nIG9w
dGlvbiByb20gYXQgYzk4MDowMDAzDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC41NzFd
IHBtbSBjYWxsIGFyZzE9MQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNTcxXSBwbW0g
Y2FsbCBhcmcxPTANCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjU3M10gcG1tIGNhbGwg
YXJnMT0xDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC41NzNdIHBtbSBjYWxsIGFyZzE9
MA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNTg5XSBTZWFyY2hpbmcgYm9vdG9yZGVy
IGZvcjogL3BjaUBpMGNmOC8qQDQNCihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAwLjU4OV0g
DQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMC41OTVdIFByZXNzIEYxMiBmb3IgYm9vdCBt
ZW51Lg0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDAuNTk2XSANCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjUyOjAxLjg2MV0gc3RkdmdhLmM6MTUxOmQxNnYwIGxlYXZpbmcgc3RkdmdhDQoo
ZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMy4xMzJdIFNlYXJjaGluZyBib290b3JkZXIgZm9y
OiBIQUxUDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMy4xMzJdIGRyaXZlIDB4MDAwZjBk
MzA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMg
cz0yMDk3MTUyMA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDMuMTMyXSBTcGFjZSBhdmFp
bGFibGUgZm9yIFVNQjogY2E4MDAtZWYwMDAsIGYwMDAwLWYwZDMwDQooZDE3KSBbMjAxNC0x
MS0xOCAyMTo1MjowMy4xMzJdIFJldHVybmVkIDI1ODA0OCBieXRlcyBvZiBab25lSGlnaA0K
KGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDMuMTMyXSBlODIwIG1hcCBoYXMgNiBpdGVtczoN
CihkMTcpIFsyMDE0LTExLTE4IDIxOjUyOjAzLjEzMl0gICAwOiAwMDAwMDAwMDAwMDAwMDAw
IC0gMDAwMDAwMDAwMDA5ZmMwMCA9IDEgUkFNDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1Mjow
My4xMzJdICAgMTogMDAwMDAwMDAwMDA5ZmMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgPSAyIFJF
U0VSVkVEDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMy4xMzJdICAgMjogMDAwMDAwMDAw
MDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgPSAyIFJFU0VSVkVEDQooZDE3KSBbMjAxNC0x
MS0xOCAyMTo1MjowMy4xMzJdICAgMzogMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwM2Y3
ZmYwMDAgPSAxIFJBTQ0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDMuMTMyXSAgIDQ6IDAw
MDAwMDAwM2Y3ZmYwMDAgLSAwMDAwMDAwMDNmODAwMDAwID0gMiBSRVNFUlZFRA0KKGQxNykg
WzIwMTQtMTEtMTggMjE6NTI6MDMuMTMyXSAgIDU6IDAwMDAwMDAwZmMwMDAwMDAgLSAwMDAw
MDAwMTAwMDAwMDAwID0gMiBSRVNFUlZFRA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDMu
MTMzXSBlbnRlciBoYW5kbGVfMTk6DQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMy4xMzNd
ICAgTlVMTA0KKGQxNykgWzIwMTQtMTEtMTggMjE6NTI6MDMuMTM5XSBCb290aW5nIGZyb20g
SGFyZCBEaXNrLi4uDQooZDE3KSBbMjAxNC0xMS0xOCAyMTo1MjowMy4xNDFdIEJvb3Rpbmcg
ZnJvbSAwMDAwOjdjMDANClsgIDQyMC4zNzk5NjldIHhlbl9icmlkZ2U6IHBvcnQgMTYodmlm
MTYuMC1lbXUpIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KKFhFTikgWzIwMTQtMTEtMTgg
MjE6NTI6MTMuMDU5XSBzdGR2Z2EuYzoxNTE6ZDE3djAgbGVhdmluZyBzdGR2Z2ENClsgIDQz
MC4xNDQ5NTZdIHhlbl9icmlkZ2U6IHBvcnQgMTgodmlmMTcuMC1lbXUpIGVudGVyZWQgZm9y
d2FyZGluZyBzdGF0ZQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MjcuNDM0XSBzdGR2Z2Eu
YzoxNDc6ZDE2djAgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzDQooWEVOKSBb
MjAxNC0xMS0xOCAyMTo1MjoyOS4wMjNdIGlycS5jOjM4MDogRG9tMTYgY2FsbGJhY2sgdmlh
IGNoYW5nZWQgdG8gRGlyZWN0IFZlY3RvciAweGYzDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1
MjozNS4zMjldIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZl
IG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM1LjMzNF0gbWVtb3J5X21hcDphZGQ6
IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NTI6MzUuMzM4XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBm
ZSBucj0xDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS4zNDJdIG1lbW9yeV9tYXA6YWRk
OiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDIx
OjUyOjM1LjM0N10gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUw
ZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzUuMzUyXSBtZW1vcnlfbWFwOmFk
ZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1MjozNS4zNTVdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZl
MGZlIG5yPTENCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM1LjM1OV0gbWVtb3J5X21hcDph
ZGQ6IGRvbTE2IGdmbj1mMzI3MCBtZm49ZmUwZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTgg
MjE6NTI6MzUuMzY0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1m
ZTBmZSBucj0xDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS4zNjldIG1lbW9yeV9tYXA6
YWRkOiBkb20xNiBnZm49ZjMyNzAgbWZuPWZlMGZlIG5yPTENCihYRU4pIFsyMDE0LTExLTE4
IDIxOjUyOjM1LjM3NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzI3MCBtZm49
ZmUwZmUgbnI9MQ0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzUuMzgwXSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMjcwIG1mbj1mZTBmZSBucj0xDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1MjozNS4zOTNdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMDAgbWZu
PWZlMjAwIG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzUuNDAxXSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDANCihYRU4pIFsyMDE0
LTExLTE4IDIxOjUyOjM1LjQwN10gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAw
MCBtZm49ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS40MTRdIG1l
bW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMA0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NTI6MzUuNDIwXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2Zu
PWYzMDAwIG1mbj1mZTIwMCBucj0yMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM1LjQy
Nl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwDQoo
WEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS40MzNdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20x
NiBnZm49ZjMwMDAgbWZuPWZlMjAwIG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6
MzUuNDM5XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0y
MDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM1LjQ0NV0gbWVtb3J5X21hcDpyZW1vdmU6
IGRvbTE2IGdmbj1mMzAwMCBtZm49ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1MjozNS40NTJdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMDAgbWZuPWZlMjAw
IG5yPTIwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzUuNDU4XSBtZW1vcnlfbWFwOnJl
bW92ZTogZG9tMTYgZ2ZuPWYzMDAwIG1mbj1mZTIwMCBucj0yMDANCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjUyOjM1LjQ2NV0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAwMCBtZm49
ZmUyMDAgbnI9MjAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS41MDFdIGlycS5jOjI3
MDogRG9tMTYgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMA0KKFhFTikgWzIwMTQtMTEtMTgg
MjE6NTI6MzUuNTI1XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAt
PiAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1MjozNS41NDVdIGlycS5jOjI3MDogRG9tMTYg
UENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM1
LjU2Nl0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwDQooWEVO
KSBbMjAxNC0xMS0xOCAyMTo1MjozNy4xMjddIHN0ZHZnYS5jOjE0NzpkMTd2MCBlbnRlcmlu
ZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMNClsgIDQ1Mi4zMTYwODJdIHhlbi1ibGtiYWNr
OnJpbmctcmVmIDgsIGV2ZW50LWNoYW5uZWwgMzIsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkp
IHBlcnNpc3RlbnQgZ3JhbnRzDQpbICA0NTIuMzMwMDc1XSB4ZW4tYmxrYmFjazpyaW5nLXJl
ZiA5LCBldmVudC1jaGFubmVsIDMzLCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0
ZW50IGdyYW50cw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzcuNDYyXSBncmFudF90YWJs
ZS5jOjEyOTk6ZDE2djEgRXhwYW5kaW5nIGRvbSAoMTYpIGdyYW50IHRhYmxlIGZyb20gKDQp
IHRvICg1KSBmcmFtZXMuDQpbICA0NTIuNjAyMzk2XSB2aWYgdmlmLTE2LTAgdmlmMTYuMDog
R3Vlc3QgUnggcmVhZHkNClsgIDQ1Mi42MDg3NTVdIHhlbl9icmlkZ2U6IHBvcnQgMTUodmlm
MTYuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQpbICA0NTIuNjE1MDQ1XSB4ZW5fYnJp
ZGdlOiBwb3J0IDE1KHZpZjE2LjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NTI6MzguODkyXSBpcnEuYzozODA6IERvbTE3IGNhbGxiYWNrIHZp
YSBjaGFuZ2VkIHRvIERpcmVjdCBWZWN0b3IgMHhmMw0KKFhFTikgWzIwMTQtMTEtMTggMjE6
NTI6MzkuOTY0XSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDAN
CihYRU4pIFsyMDE0LTExLTE4IDIxOjUyOjM5Ljk3MF0gaXJxLmM6MjcwOiBEb20xNyBQQ0kg
bGluayAxIGNoYW5nZWQgMTAgLT4gMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6MzkuOTc2
XSBpcnEuYzoyNzA6IERvbTE3IFBDSSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwDQooWEVOKSBb
MjAxNC0xMS0xOCAyMTo1MjozOS45ODJdIGlycS5jOjI3MDogRG9tMTcgUENJIGxpbmsgMyBj
aGFuZ2VkIDUgLT4gMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6NDAuNTAzXSBncmFudF90
YWJsZS5jOjEyOTk6ZDE3djEgRXhwYW5kaW5nIGRvbSAoMTcpIGdyYW50IHRhYmxlIGZyb20g
KDQpIHRvICg1KSBmcmFtZXMuDQpbICA0NTUuNjQxMDU2XSB4ZW4tYmxrYmFjazpyaW5nLXJl
ZiA5LCBldmVudC1jaGFubmVsIDMzLCBwcm90b2NvbCAxICh4ODZfNjQtYWJpKSBwZXJzaXN0
ZW50IGdyYW50cw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTI6NDAuNTM2XSBncmFudF90YWJs
ZS5jOjMwNTpkMHY0IEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDcgZnJhbWVzDQpbICA0
NTUuNjYzNTU3XSB2aWYgdmlmLTE3LTAgdmlmMTcuMDogR3Vlc3QgUnggcmVhZHkNClsgIDQ1
NS42NzAxNDVdIHhlbl9icmlkZ2U6IHBvcnQgMTcodmlmMTcuMCkgZW50ZXJlZCBmb3J3YXJk
aW5nIHN0YXRlDQpbICA0NTUuNjc2NjQ5XSB4ZW5fYnJpZGdlOiBwb3J0IDE3KHZpZjE3LjAp
IGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAgNDY3LjY1NzEyOF0geGVuX2JyaWRnZTog
cG9ydCAxNSh2aWYxNi4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDQ3MC42OTg3
NzddIHhlbl9icmlkZ2U6IHBvcnQgMTcodmlmMTcuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0
YXRlDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1Mjo1OC40MDldIGdyYW50X3RhYmxlLmM6MzA1
OmQwdjAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gOCBmcmFtZXMNCihYRU4pIFsyMDE0
LTExLTE4IDIxOjU1OjQxLjU5MV0gLS0tLVsgWGVuLTQuNS4wLXJjICB4ODZfNjQgIGRlYnVn
PXkgIE5vdCB0YWludGVkIF0tLS0tDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFd
IENQVTogICAgMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAtLS0tWyBYZW4t
NC41LjAtcmMgIHg4Nl82NCAgZGVidWc9eSAgTm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIFsy
MDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gUklQOiAgICBlMDA4Ols8ZmZmZjgyZDA4MDEyYzdl
Nz5dQ1BVOiAgICAyDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdIFJJUDogICAg
ZTAwODpbPGZmZmY4MmQwODAxNGE0NjE+XSBodm1fZG9fSVJRX2RwY2krMHhiZC8weDEzYw0K
KFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSBSRkxBR1M6IDAwMDAwMDAwMDAwMTAw
MDYgICAgX3NwaW5fdW5sb2NrKzB4MWYvMHgzMENPTlRFWFQ6IGh5cGVydmlzb3INCihYRU4p
IFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0
MS41OTFdIFJGTEFHUzogMDAwMDAwMDAwMDAxMDI0NiAgIHJheDogMDAwMDAwMDAwMDAwMDAw
MCAgIHJieDogZmZmZjgzMDM3NzM0NTBhOCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwMQ0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSBDT05URVhUOiBoeXBlcnZpc29yDQooWEVO
KSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdIHJkeDogMDAwMDAwMDAwMDAwMDAwMCAgIHJz
aTogZmZmZjgzMDU0ZWY0ZWY5OCAgIHJkaTogMDAwMDAwMDAxMmFhNTQwMA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NTU6NDEuNTkxXSByYXg6IGZmZmY4MmQwODAzMjhkYTAgICByYng6IGZm
ZmY4MzA1MTg2YzVkODAgICByY3g6IDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjU1OjQxLjU5MV0gcmJwOiBmZmZmODMwNTRlZjQ3Yzg4ICAgcnNwOiBmZmZmODMw
NTRlZjQ3Yzc4ICAgcjg6ICBmZmZmODMwNTE4NmM1OGQwDQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1NTo0MS41OTFdIHI5OiAgMDAwMDAwMDAwMDAwMDAyZiAgIHIxMDogMDAwMDAwMDAwMDAw
MDBkMCAgIHIxMTogZmZmZmZmZmY4MjkwODRiMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6
NDEuNTkxXSByZHg6IGZmZmY4MmQwODAyZTAwMDAgICByc2k6IGZmZmY4MzA1MGFlYWQyYTgg
ICByZGk6IDAwMDAwMDAwMDAwMDAwYjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5
MV0gcmJwOiBmZmZmODJkMDgwMmU3ZGY4ICAgcnNwOiBmZmZmODJkMDgwMmU3ZGY4ICAgcjg6
ICBmZmZmODJkMDgwMmU3ZDI4DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdIHI5
OiAgMDAwMDAwMDAwMDAwMDA0MCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogZmZm
ZmZmZmZmZmZmZmZjMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSByMTI6IGZm
ZmY4MzA1MTg2YzVkODAgICByMTM6IGZmZmY4MzAzNzczNDUwYTggICByMTQ6IGZmZmY4MzAz
NzczNDUwYjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gcjE1OiBmZmZmODMw
NTE4NmM1YjAwICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAw
NmYwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdIHIxMjogZmZmZjgzMDUxNWI1
YjAwMCAgIHIxMzogMDAwMDAwMDAwMDAwMDAwMCAgIHIxNDogZmZmZjgzMDM3NzM0NTA4MA0K
KFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSBjcjM6IDAwMDAwMDA1NGEyMTUwMDAg
ICBjcjI6IDAwMDAwMDAwMDAwMDAwYjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5
MV0gcjE1OiAwMDAwMDAwMDAwMDAwMDJmICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0
OiAwMDAwMDAwMDAwMDAwNmYwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdIGRz
OiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IDAwMDAgICBj
czogZTAwOA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSBjcjM6IDAwMDAwMDA1
NGEyMTUwMDAgICBjcjI6IDAwMDAwMDAwMDAwMDAxNjANCihYRU4pIFsyMDE0LTExLTE4IDIx
OjU1OjQxLjU5MV0gZHM6IDAwMDAgICBlczogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAwMDAg
ICBzczogMDAwMCAgIGNzOiBlMDA4DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFd
IFhlbiBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmODJkMDgwMmU3ZGY4Og0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODJkMDgwMmU3ZTQ4WGVuIHN0YWNrIHRy
YWNlIGZyb20gcnNwPWZmZmY4MzA1NGVmNDdjNzg6DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1
NTo0MS41OTFdICAgIGZmZmY4MmQwODAxNGEzOTUgZmZmZjgzMDA5ZmQyZDA2MCBmZmZmODMw
NTRlZjQ3Yzg4IGZmZmY4MzAzNzczNDUwYjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQx
LjU5MV0gICAgZmZmZmM5MDAxNDFmMmIyMCBmZmZmODJkMDgwMzI4ZjgwIGZmZmY4MzAzNzcz
NDUxNDAgZmZmZjgyZDA4MDE0YTI2ZSBmZmZmODMwMzc3MzQ1MGE4IGZmZmY4MzA1NGVmNDdk
MTgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgZmZmZjgyZDA4MDE3MjA2
MCAwMDAwMDA5NDNmNDNlNTE4IGZmZmY4ODAwMmIyMjdlMTggZmZmZjgyZDA4MDJlN2U3OA0K
KFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODJkMDgwMTJmMmMzIDAw
MDAwMDAwMDAwMDAyODYNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgMDAw
MDAwMDEwMDAwMDAzMSBmZmZmODJkMDgwMThiMjBmIGZmZmY4MmQwODAzMjhmODAgZmZmZjgz
MDUwYjBiYjVlMCBmZmZmODMwNTRlZjQ3Y2Y4IGZmZmY4MmQwODAxNzg4NDYgZmZmZjgzMDM3
NzM0NTBlMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgIA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODJkMDgwMmU3ZWM4IGZmZmY4MmQwODAx
MmYzYzMgZmZmZjgyZDA4MDJlN2VmOCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MmQwODAyMmQ1
YTENCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgMDAwMDAwOTQzZjY1ZDhi
NCBmZmZmODMwNTVkMDAyZjI0IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMmY5ZmY4ODAwMA0K
KFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODJkMDgwMmZmZjgwIGZm
ZmY4MzA1NGVmNDdkMjggMDAwMDAwMDAwMDU1ZDEyNiBmZmZmODMwNTRlZjEyMDAwIGZmZmY4
MmQwODAyZmZmODAgZmZmZmZmZmZmZmZmZmZmZg0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6
NDEuNTkxXSAgICBmZmZmODMwNTE1YjViMGI4IGZmZmY4MmQwODAyZTAwMDAgZmZmZjg4MDAy
YjIyN2UxOA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODJkMDgw
MmU3ZWY4IGZmZmY4MmQwODAyZmZmODAgZmZmZjgyZDA4MDEyYmUzMSBmZmZmODMwMzc3MzQ1
MGE4IGZmZmY4MzA1MTViNWIwMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0g
ICAgMDIwMDIwMDIwMDIwMDIwMCBmZmZmODMwMDlmZDJkMDAwDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0MS41OTFdICAgIDAwMDA3Y2ZhYjEwYjgyYjcgMDAwMDAwMDAwMDAwMDAwMSBm
ZmZmODJkMDgwMjMzMTIyIDAyMDAyMDAyMDAyMDAyMDAgZmZmZjgzMDUxNWI1YjAwMA0KKFhF
TikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICAwMDAwMDAwMDAwMDAwMDAxIGZmZmY4
ODAwNTkyNWExZTgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgZmZmZjgz
MDM3NzM0NTBhOCBmZmZmODJkMDgwMmZmZjgwIGZmZmY4MmQwODAyZTdmMDggZmZmZjgyZDA4
MDEyYmU4OSBmZmZmODMwNTRlZjQ3ZGQ4IDAwMDA3ZDJmN2ZkMTgwYzcgZmZmZjgzMDUxNWI1
YjBiOCBmZmZmODJkMDgwMjMyY2QxDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFd
ICAgIGZmZmY4ODAwMmIyMjdlMTggZmZmZjg4MDA1OTI1YTFlOA0KKFhFTikgWzIwMTQtMTEt
MTggMjE6NTU6NDEuNTkxXSAgICAwMDAwMDAwMDAwMDAwMDAxIDAwMDAwMDAwMDAwMDAwMDEN
CihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgZmZmZjg4MDAyYjIyN2JiOCBm
ZmZmZmZmZjgyOTA4NGIwIGZmZmY4ODAwNWY2ZDM1YTggMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIDAwMDAw
MDAwMDAwMDAwZDAgMDAwMDAwOTQzZjRlMTcyZCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAz
NzczNDUxNTAgMDAwMDAwMDAwMDAwNTc3NiBmZmZmZmZmZjgxYzEwY2MwDQooWEVOKSBbMjAx
NC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIDAwMDAwMDk0M2Y0M2UzMDAgMDAwMDAwMDAwMDAw
MDAwMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICAwMDAwMDAwMDAwMDAw
MDAxIDAwMDAwMDAwMDAwMDAwMDEgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODMwNTRlZjRlZjk4
DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIGZmZmY4MzA1MTViNWIwYmMg
MDAwMDAwYjkwMDAwMDAwMCBmZmZmODJkMDgwMTJjNjlmIGZmZmY4ODAwNTkyNWExODAgZmZm
Zjg4MDA1ZjZkMzUwMCAwMDAwMDAwMDAwMDBlMDA4IDAwMDAwMGZhMDAwMDAwMDANCihYRU4p
IFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgMDAwMDAwMDAwMDAwMDI0Ng0KKFhFTikg
WzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmZmZmZjgxMGVhYjYzIGZmZmY4MzA1
NGVmNDdkZDAgMDAwMDAwMDAwMDAwZTAzMyAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAyODYgZmZmZjgzMDM3NzM0NTExMCBmZmZmODgwMDJiMjI3YjY4DQooWEVOKSBbMjAxNC0x
MS0xOCAyMTo1NTo0MS41OTFdICAgDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFd
ICAgIDAwMDAwMDAwMDAwMGUwMmIgZmZmZjgzMDU0ZWY0N2VjOCBmZmZmODJkMDgwMTQ5NjJk
IDAwMDAwMDAwMDAwMGJlZWYgMDAwMDAwMDAwMDAwMDEwMCBmZmZmODJkMDgwMzI4ZGEwDQoo
WEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIDAwMDAwMDAwMDAwMGJlZWYgMDAw
MDAwMDAwMDAwYmVlZg0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICAwMDAw
MDAwMDAwMDBiZWVmIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDA5ZmQyZDAwMCBmZmZmODMw
NTEyYjZjMDY4IDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDU0ZWY0ZTU0MA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBmZmZmODMwNTRlZjRlNDAwIDAwMDAwMDAwMDAw
MDAwMDANCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gWGVuIGNhbGwgdHJhY2U6
DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIFs8ZmZmZjgyZDA4MDEyYzdl
Nz5dIF9zcGluX3VubG9jaysweDFmLzB4MzANCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQx
LjU5MV0gIGZmZmY4MzA1MTViNWIwYjgNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5
MV0gICAgMDAwMDAwMDEwMDAwMDAwMCBmZmZmODMwNTRlZjQ3ZTg4ICAgWzxmZmZmODJkMDgw
MTRhMzk1Pl0gcHRfaXJxX3RpbWVfb3V0KzB4MTI3LzB4MTM2DQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0MS41OTFdICAgIFs8ZmZmZjgyZDA4MDEyZjJjMz5dIGV4ZWN1dGVfdGltZXIr
MHg0ZS8weDZjDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAgIFs8ZmZmZjgy
ZDA4MDEyZjNjMz5dIHRpbWVyX3NvZnRpcnFfYWN0aW9uKzB4ZTIvMHgyMjANCihYRU4pIFsy
MDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gICAgWzxmZmZmODJkMDgwMTJiZTMxPl0gX19kb19z
b2Z0aXJxKzB4ODEvMHg4Yw0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSAgICBb
PGZmZmY4MmQwODAxMmJlODk+XSBkb19zb2Z0aXJxKzB4MTMvMHgxNQ0KKFhFTikgWzIwMTQt
MTEtMTggMjE6NTU6NDEuNTkxXSAgICBbPGZmZmY4MmQwODAyMzJjZDE+XSBwcm9jZXNzX3Nv
ZnRpcnFzKzB4MjEvMHgzMA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDEuNTkxXSANCihY
RU4pIFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gIGZmZmY4MzA1NGVmNDdlODggZmZmZjgz
MDU0ZWY0N2U4OFBhZ2V0YWJsZSB3YWxrIGZyb20gMDAwMDAwMDAwMDAwMDBiODoNCihYRU4p
IFsyMDE0LTExLTE4IDIxOjU1OjQxLjU5MV0gDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0
MS41OTFdICAgIGZmZmY4MzAzNzczNDUwYTggTDRbMHgwMDBdID0gMDAwMDAwMDAwMDAwMDAw
MCBmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0MS41OTFdICAw
MDAwMDAwMDAwMDAwMDgyIGZmZmY4MzAzNzczNDUwYTgNCihYRU4pIFsyMDE0LTExLTE4IDIx
OjU1OjQzLjI2MF0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K
KFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDMuMjgwXSAgZmZmZjgzMDM3NzM0NTE1MFBhbmlj
IG9uIENQVSAwOg0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDMuMjk3XSBGQVRBTCBQQUdF
IEZBVUxUDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My4zMTBdIFtlcnJvcl9jb2RlPTAw
MDBdDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My4zMjNdIEZhdWx0aW5nIGxpbmVhciBh
ZGRyZXNzOiAwMDAwMDAwMDAwMDAwMGI4DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My4z
NDNdICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCihYRU4pIFsy
MDE0LTExLTE4IDIxOjU1OjQzLjM2Ml0gDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My4z
NzFdIFJlYm9vdCBpbiBmaXZlIHNlY29uZHMuLi4NCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1
OjQzLjM4Nl0gDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My4zOTVdICAgIGZmZmY4MzA1
MTViNWIwMDAgMDAwMDAwMDAwMDAwMDAwMSBmZmZmODMwMzc3MzQ1MDgwIDAwMDAwMDAwMDAw
MDAwMmYNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjQyMl0gICAgZmZmZjgzMDU0ZWY0
N2YwOCBmZmZmODJkMDgwMTcyMWEzIGZmZmY4MzA1NGVmNDdlODggZmZmZjgzMDU0ZWY0N2U4
OA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDMuNDQ5XSAgICAwMDAwMGVjYzAwMDAwMDA0
IGZmZmY4MmQwODAzMDAwODAgZmZmZjgyZDA4MDJmZmY4MCBmZmZmZmZmZmZmZmZmZmZmDQoo
WEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My40NzZdICAgIGZmZmY4MzA1NGVmNDAwMDAgMDAw
MDAwMDAwMDAwMDAwMSBmZmZmODMwNTRlZjQ3ZWY4IGZmZmY4MmQwODAxMmJlMzENCihYRU4p
IFsyMDE0LTExLTE4IDIxOjU1OjQzLjUwM10gICAgZmZmZjgzMDA5ZmY4ODAwMCBmZmZmZmZm
ZjgzMDgxNTkwIGZmZmZmZmZmODIyMWM1MjAgZmZmZmZmZmY4MjIxY2MyMA0KKFhFTikgWzIw
MTQtMTEtMTggMjE6NTU6NDMuNTMwXSBYZW4gY2FsbCB0cmFjZToNCihYRU4pIFsyMDE0LTEx
LTE4IDIxOjU1OjQzLjU0M10gICAgWzxmZmZmODJkMDgwMTRhNDYxPl0gaHZtX2RvX0lSUV9k
cGNpKzB4YmQvMHgxM2MNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjU2NV0gICAgWzxm
ZmZmODJkMDgwMTcyMDYwPl0gZG9fSVJRKzB4NDljLzB4NjI0DQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0My41ODRdICAgIFs8ZmZmZjgyZDA4MDIzMzEyMj5dIGNvbW1vbl9pbnRlcnJ1
cHQrMHg2Mi8weDcwDQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My42MDZdICAgIFs8ZmZm
ZjgyZDA4MDEyYzY5Zj5dIF9zcGluX2xvY2srMHgxYS8weDU0DQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0My42MjZdICAgIFs8ZmZmZjgyZDA4MDE0OTYyZD5dIGRwY2lfc29mdGlycSsw
eDI0MS8weDNhZA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDMuNjQ4XSAgICBbPGZmZmY4
MmQwODAxMmJlMzE+XSBfX2RvX3NvZnRpcnErMHg4MS8weDhjDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0My42NjldICAgIFs8ZmZmZjgyZDA4MDEyYmU4OT5dIGRvX3NvZnRpcnErMHgx
My8weDE1DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My42ODldICAgIFs8ZmZmZjgyZDA4
MDIzMmNkMT5dIHByb2Nlc3Nfc29mdGlycXMrMHgyMS8weDMwDQooWEVOKSBbMjAxNC0xMS0x
OCAyMTo1NTo0My43MTFdIA0KKFhFTikgWzIwMTQtMTEtMTggMjE6NTU6NDMuNzIwXSBQYWdl
dGFibGUgd2FsayBmcm9tIDAwMDAwMDAwMDAwMDAxNjA6DQooWEVOKSBbMjAxNC0xMS0xOCAy
MTo1NTo0My43MzhdICBMNFsweDAwMF0gPSAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmZmZm
ZmZmZmYNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjc1OV0gDQooWEVOKSBbMjAxNC0x
MS0xOCAyMTo1NTo0My43NjhdICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioNCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjc4N10gUGFuaWMgb24gQ1BVIDI6
DQooWEVOKSBbMjAxNC0xMS0xOCAyMTo1NTo0My44MDBdIEZBVEFMIFBBR0UgRkFVTFQNCihY
RU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjgxM10gW2Vycm9yX2NvZGU9MDAwMl0NCihYRU4p
IFsyMDE0LTExLTE4IDIxOjU1OjQzLjgyNl0gRmF1bHRpbmcgbGluZWFyIGFkZHJlc3M6IDAw
MDAwMDAwMDAwMDAxNjANCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjg0NV0gKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKFhFTikgWzIwMTQtMTEtMTgg
MjE6NTU6NDMuODY1XSANCihYRU4pIFsyMDE0LTExLTE4IDIxOjU1OjQzLjg3M10gUmVib290
IGluIGZpdmUgc2Vjb25kcy4uLg0K
------------1231500C116741850
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------1231500C116741850--



From xen-devel-bounces@lists.xen.org Tue Nov 18 22:56:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 22:56:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqrgy-000830-Ll; Tue, 18 Nov 2014 22:56:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xqrgx-00082v-1a
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 22:56:11 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	31/0A-26858-A8ECB645; Tue, 18 Nov 2014 22:56:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416351368!7850020!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11912 invoked from network); 18 Nov 2014 22:56:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 22:56:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,412,1413244800"; d="scan'208";a="192697374"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 17:56:06 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqrgs-0006kI-Jx;
	Tue, 18 Nov 2014 22:56:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqrgs-00056P-DC;
	Tue, 18 Nov 2014 22:56:06 +0000
Date: Tue, 18 Nov 2014 22:56:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31643-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31643: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31643 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31643/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl-sedf      9 guest-start             fail baseline untested
 test-amd64-i386-xl-credit2   12 guest-localmigrate      fail baseline untested
 test-amd64-amd64-xl-sedf-pin 12 guest-localmigrate      fail baseline untested
 test-amd64-i386-xl           12 guest-localmigrate      fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu 12 guest-localmigrate      fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken baseline untested
 test-amd64-amd64-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                efefb5ca5da52f7537c7ced03d6e53408f13a26e
baseline version:
 linux                56c381f93d57b88a3e667a2f55137947315c17e2

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 22:56:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 22:56:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqrgy-000830-Ll; Tue, 18 Nov 2014 22:56:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xqrgx-00082v-1a
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 22:56:11 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	31/0A-26858-A8ECB645; Tue, 18 Nov 2014 22:56:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416351368!7850020!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11912 invoked from network); 18 Nov 2014 22:56:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 22:56:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,412,1413244800"; d="scan'208";a="192697374"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 17:56:06 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqrgs-0006kI-Jx;
	Tue, 18 Nov 2014 22:56:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqrgs-00056P-DC;
	Tue, 18 Nov 2014 22:56:06 +0000
Date: Tue, 18 Nov 2014 22:56:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31643-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31643: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31643 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31643/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl-sedf      9 guest-start             fail baseline untested
 test-amd64-i386-xl-credit2   12 guest-localmigrate      fail baseline untested
 test-amd64-amd64-xl-sedf-pin 12 guest-localmigrate      fail baseline untested
 test-amd64-i386-xl           12 guest-localmigrate      fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu 12 guest-localmigrate      fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken baseline untested
 test-amd64-amd64-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                efefb5ca5da52f7537c7ced03d6e53408f13a26e
baseline version:
 linux                56c381f93d57b88a3e667a2f55137947315c17e2

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 23:57:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 23:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqseH-0000oP-Aa; Tue, 18 Nov 2014 23:57:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqseF-0000oK-3s
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 23:57:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4A/5D-09842-6ECDB645; Tue, 18 Nov 2014 23:57:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416355044!13666601!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24046 invoked from network); 18 Nov 2014 23:57:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 23:57:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,413,1413244800"; d="scan'208";a="194222116"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 18:56:54 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqsdh-00072M-Kv;
	Tue, 18 Nov 2014 23:56:53 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqsdh-0008V7-DS;
	Tue, 18 Nov 2014 23:56:53 +0000
Date: Tue, 18 Nov 2014 23:56:53 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31661-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31661: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31661 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31661/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=9716ed62cb1d73254b552e2077497d684c81639d
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen 9716ed62cb1d73254b552e2077497d684c81639d
+ branch=rumpuserxen
+ revision=9716ed62cb1d73254b552e2077497d684c81639d
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git 9716ed62cb1d73254b552e2077497d684c81639d:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   1eb3666..9716ed6  9716ed62cb1d73254b552e2077497d684c81639d -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 18 23:57:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Nov 2014 23:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqseH-0000oP-Aa; Tue, 18 Nov 2014 23:57:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqseF-0000oK-3s
	for xen-devel@lists.xensource.com; Tue, 18 Nov 2014 23:57:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4A/5D-09842-6ECDB645; Tue, 18 Nov 2014 23:57:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416355044!13666601!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24046 invoked from network); 18 Nov 2014 23:57:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2014 23:57:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,413,1413244800"; d="scan'208";a="194222116"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 18:56:54 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqsdh-00072M-Kv;
	Tue, 18 Nov 2014 23:56:53 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqsdh-0008V7-DS;
	Tue, 18 Nov 2014 23:56:53 +0000
Date: Tue, 18 Nov 2014 23:56:53 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31661-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31661: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31661 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31661/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen          1eb3666b469e307b20262e856229d0bd5d06a59e

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=9716ed62cb1d73254b552e2077497d684c81639d
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen 9716ed62cb1d73254b552e2077497d684c81639d
+ branch=rumpuserxen
+ revision=9716ed62cb1d73254b552e2077497d684c81639d
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git 9716ed62cb1d73254b552e2077497d684c81639d:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   1eb3666..9716ed6  9716ed62cb1d73254b552e2077497d684c81639d -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 00:01:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 00:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqshy-0001DJ-Oi; Wed, 19 Nov 2014 00:01: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@citrix.com>) id 1Xqshx-0001DD-N5
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 00:01:17 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	BA/48-11581-CCDDB645; Wed, 19 Nov 2014 00:01:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416355274!12105059!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24958 invoked from network); 19 Nov 2014 00:01:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 00:01:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,413,1413244800"; d="scan'208";a="194223246"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 19:01:13 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqsht-00073z-2J;
	Wed, 19 Nov 2014 00:01:13 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqshs-0000rc-TQ;
	Wed, 19 Nov 2014 00:01:12 +0000
Date: Wed, 19 Nov 2014 00:01:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31660-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31660: 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 31660 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31660/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
baseline version:
 libvirt              72b4151f858df3564b82a8ebba60778b996b6dce

------------------------------------------------------------
People who touched revisions under test:
  John Ferlan <jferlan@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
+ branch=libvirt
+ revision=121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   72b4151..121fc4f  121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 00:01:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 00:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqshy-0001DJ-Oi; Wed, 19 Nov 2014 00:01: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@citrix.com>) id 1Xqshx-0001DD-N5
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 00:01:17 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	BA/48-11581-CCDDB645; Wed, 19 Nov 2014 00:01:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416355274!12105059!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24958 invoked from network); 19 Nov 2014 00:01:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 00:01:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,413,1413244800"; d="scan'208";a="194223246"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 19:01:13 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xqsht-00073z-2J;
	Wed, 19 Nov 2014 00:01:13 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xqshs-0000rc-TQ;
	Wed, 19 Nov 2014 00:01:12 +0000
Date: Wed, 19 Nov 2014 00:01:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31660-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31660: 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 31660 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31660/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
baseline version:
 libvirt              72b4151f858df3564b82a8ebba60778b996b6dce

------------------------------------------------------------
People who touched revisions under test:
  John Ferlan <jferlan@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
+ branch=libvirt
+ revision=121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   72b4151..121fc4f  121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 01:26:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 01:26:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqu2D-0006cp-TK; Wed, 19 Nov 2014 01:26:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xqu2B-0006ci-Sq
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 01:26:16 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	C2/BA-07724-7B1FB645; Wed, 19 Nov 2014 01:26:15 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416360371!12301513!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3403 invoked from network); 19 Nov 2014 01:26:11 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-31.messagelabs.com with SMTP;
	19 Nov 2014 01:26:11 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 18 Nov 2014 17:26:09 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,413,1413270000"; d="scan'208";a="624584902"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.96])
	([10.238.130.96])
	by fmsmga001.fm.intel.com with ESMTP; 18 Nov 2014 17:26:06 -0800
Message-ID: <546BF1AD.4010801@intel.com>
Date: Wed, 19 Nov 2014 09:26:05 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
	<546B20910200007800048AC0@mail.emea.novell.com>
In-Reply-To: <546B20910200007800048AC0@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> So without lookuping devices[i], how can we call func() for each sbdf as
>> you mentioned?
>
> You've got both rmrr and bdf in the body of for_each_rmrr_device().
> After all - as I said - you just open-coded it.
>

Yeah, so change this again,

int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
{
     struct acpi_rmrr_unit *rmrr;
     int rc = 0;
     unsigned int i;
     u16 bdf;

     for_each_rmrr_device ( rmrr, bdf, i )
     {
         rc = func(PFN_DOWN(rmrr->base_address),
                            PFN_UP(rmrr->end_address) -
                             PFN_DOWN(rmrr->base_address),
                            PCI_SBDF(rmrr->segment, bdf),
                           ctxt);
         /* Hit this entry so just go next. */
         if ( rc == 1 )
             i = rmrr->scope.devices_cnt;
         else if ( rc < 0 )
             return rc;
     }

     return rc;
}

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 01:26:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 01:26:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqu2D-0006cp-TK; Wed, 19 Nov 2014 01:26:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xqu2B-0006ci-Sq
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 01:26:16 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	C2/BA-07724-7B1FB645; Wed, 19 Nov 2014 01:26:15 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416360371!12301513!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3403 invoked from network); 19 Nov 2014 01:26:11 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-31.messagelabs.com with SMTP;
	19 Nov 2014 01:26:11 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 18 Nov 2014 17:26:09 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,413,1413270000"; d="scan'208";a="624584902"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.96])
	([10.238.130.96])
	by fmsmga001.fm.intel.com with ESMTP; 18 Nov 2014 17:26:06 -0800
Message-ID: <546BF1AD.4010801@intel.com>
Date: Wed, 19 Nov 2014 09:26:05 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
	<546B20910200007800048AC0@mail.emea.novell.com>
In-Reply-To: <546B20910200007800048AC0@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> So without lookuping devices[i], how can we call func() for each sbdf as
>> you mentioned?
>
> You've got both rmrr and bdf in the body of for_each_rmrr_device().
> After all - as I said - you just open-coded it.
>

Yeah, so change this again,

int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
{
     struct acpi_rmrr_unit *rmrr;
     int rc = 0;
     unsigned int i;
     u16 bdf;

     for_each_rmrr_device ( rmrr, bdf, i )
     {
         rc = func(PFN_DOWN(rmrr->base_address),
                            PFN_UP(rmrr->end_address) -
                             PFN_DOWN(rmrr->base_address),
                            PCI_SBDF(rmrr->segment, bdf),
                           ctxt);
         /* Hit this entry so just go next. */
         if ( rc == 1 )
             i = rmrr->scope.devices_cnt;
         else if ( rc < 0 )
             return rc;
     }

     return rc;
}

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 01:29:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 01:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqu58-0006nN-Tn; Wed, 19 Nov 2014 01:29:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Xqu57-0006nG-BH
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 01:29:17 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	9E/BD-23865-C62FB645; Wed, 19 Nov 2014 01:29:16 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416360555!7867783!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5137 invoked from network); 19 Nov 2014 01:29:16 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-31.messagelabs.com with SMTP;
	19 Nov 2014 01:29:16 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 18 Nov 2014 17:29:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,413,1413270000"; d="scan'208";a="634212266"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga002.fm.intel.com with ESMTP; 18 Nov 2014 17:29:05 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 19 Nov 2014 09:29:04 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.110]) with mapi id
	14.03.0195.001; Wed, 19 Nov 2014 09:29:02 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest
Thread-Index: AQHQAxh40OPG79GTNEGKmyo8ZLinmpxlrM6AgACVuECAADyIKIAAqAiw
Date: Wed, 19 Nov 2014 01:29:03 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
References: <21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
In-Reply-To: <20141118151542.GB13651@deinos.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li,
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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

Tim Deegan wrote on 2014-11-18:
> At 14:26 +0000 on 18 Nov (1416317209), Ian Campbell wrote:
>> On Tue, 2014-11-18 at 11:41 +0000, Zhang, Yang Z wrote:
>>>> Hmm - this is a pitfall waiting to happen.
>>>> 
>>>> In the case that there is a heterogeneous setup with one 1G
>>>> capable and one 1G incapable server, Xen cannot forcibly prevent
>>>> the use of 1G pages on the capable hardware.  Any VM which
>>>> guesses at hardware support by means other than cpuid features
>>>> is liable to
> explode on migrate.
>>> 
>>> But a normal guest shouldn't to guess it, right?
>> 
>> IMHO any guest which does not use the mechanism explicitly provided
>> for feature detection deserves to break randomly.
> 
> Yes, that's a reasonable position (notwithstanding that we know such
> software exists).
> 

Agree.

> In this case, the guest is entitled to _expect_ pagefaults on 1GB
> mappings if CPUID claims they are not supported.  That sounds like an
> unlikely thing for the guest to be relying on, but Xen itself does
> something similar for the SHOPT_FAST_FAULT_PATH (and now also for
> IOMMU entries for the deferred caching attribute updates).

Indeed. How about adding the software check (as Andrew mentioned) firstly and leave the hardware problem (Actually, I don't think we can solve it currently).

> 
> Cheers,
> 
> Tim.


Best regards,
Yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 01:29:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 01:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqu58-0006nN-Tn; Wed, 19 Nov 2014 01:29:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Xqu57-0006nG-BH
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 01:29:17 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	9E/BD-23865-C62FB645; Wed, 19 Nov 2014 01:29:16 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416360555!7867783!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5137 invoked from network); 19 Nov 2014 01:29:16 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-31.messagelabs.com with SMTP;
	19 Nov 2014 01:29:16 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 18 Nov 2014 17:29:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,413,1413270000"; d="scan'208";a="634212266"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga002.fm.intel.com with ESMTP; 18 Nov 2014 17:29:05 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 19 Nov 2014 09:29:04 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.110]) with mapi id
	14.03.0195.001; Wed, 19 Nov 2014 09:29:02 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest
Thread-Index: AQHQAxh40OPG79GTNEGKmyo8ZLinmpxlrM6AgACVuECAADyIKIAAqAiw
Date: Wed, 19 Nov 2014 01:29:03 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
References: <21610.5784.968036.992847@mariner.uk.xensource.com>
	<546A2F600200007800048848@mail.emea.novell.com>
	<20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
In-Reply-To: <20141118151542.GB13651@deinos.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li,
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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

Tim Deegan wrote on 2014-11-18:
> At 14:26 +0000 on 18 Nov (1416317209), Ian Campbell wrote:
>> On Tue, 2014-11-18 at 11:41 +0000, Zhang, Yang Z wrote:
>>>> Hmm - this is a pitfall waiting to happen.
>>>> 
>>>> In the case that there is a heterogeneous setup with one 1G
>>>> capable and one 1G incapable server, Xen cannot forcibly prevent
>>>> the use of 1G pages on the capable hardware.  Any VM which
>>>> guesses at hardware support by means other than cpuid features
>>>> is liable to
> explode on migrate.
>>> 
>>> But a normal guest shouldn't to guess it, right?
>> 
>> IMHO any guest which does not use the mechanism explicitly provided
>> for feature detection deserves to break randomly.
> 
> Yes, that's a reasonable position (notwithstanding that we know such
> software exists).
> 

Agree.

> In this case, the guest is entitled to _expect_ pagefaults on 1GB
> mappings if CPUID claims they are not supported.  That sounds like an
> unlikely thing for the guest to be relying on, but Xen itself does
> something similar for the SHOPT_FAST_FAULT_PATH (and now also for
> IOMMU entries for the deferred caching attribute updates).

Indeed. How about adding the software check (as Andrew mentioned) firstly and leave the hardware problem (Actually, I don't think we can solve it currently).

> 
> Cheers,
> 
> Tim.


Best regards,
Yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 01:44:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 01: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 1XquJL-00076Z-Lw; Wed, 19 Nov 2014 01:43:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XquJK-00076S-K0
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 01:43:58 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B4/17-22737-DD5FB645; Wed, 19 Nov 2014 01:43:57 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416361436!6837160!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14411 invoked from network); 19 Nov 2014 01:43:57 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-206.messagelabs.com with SMTP;
	19 Nov 2014 01:43:57 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 18 Nov 2014 17:43:55 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,413,1413270000"; d="scan'208";a="610143691"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 18 Nov 2014 17:43:54 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 19 Nov 2014 09:41:59 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id
	14.03.0195.001; Wed, 19 Nov 2014 09:41:53 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/l9ZNIwAqiexHE6x0A+uPl9BJ5xfW+EAgACOpLD//47SgIAHvScg
Date: Wed, 19 Nov 2014 01:41:53 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A63F4F@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
	<1415964503.7113.14.camel@citrix.com>
In-Reply-To: <1415964503.7113.14.camel@citrix.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: Fabio Fantoni <fabio.fantoni@m2r.biz>, Wei Liu <wei.liu2@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Friday, November 14, 2014 7:28 PM
> To: Hu, Robert
> Cc: Fabio Fantoni; Wei Liu; JBeulich@suse.com; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> On Fri, 2014-11-14 at 10:14 +0000, Hu, Robert wrote:
> > Will rerun this test case in RC2 testing, and if still there, append
> > the full logs then.
> 
> Thank you.
> 
> BTW, I've pointed this need for logs out to multiple of your
> predecessors over the years. If you could try and get this information
> (e.g. the link to the wiki, the need for logs in the general case) added
> to your internal documentation (test plan, onboard docs for new
> engineers, etc) that would be awesome.
Yes, I'm trying to perfect the procedure in this direction.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 01:44:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 01: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 1XquJL-00076Z-Lw; Wed, 19 Nov 2014 01:43:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XquJK-00076S-K0
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 01:43:58 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B4/17-22737-DD5FB645; Wed, 19 Nov 2014 01:43:57 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416361436!6837160!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14411 invoked from network); 19 Nov 2014 01:43:57 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-206.messagelabs.com with SMTP;
	19 Nov 2014 01:43:57 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 18 Nov 2014 17:43:55 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,413,1413270000"; d="scan'208";a="610143691"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 18 Nov 2014 17:43:54 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 19 Nov 2014 09:41:59 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id
	14.03.0195.001; Wed, 19 Nov 2014 09:41:53 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/l9ZNIwAqiexHE6x0A+uPl9BJ5xfW+EAgACOpLD//47SgIAHvScg
Date: Wed, 19 Nov 2014 01:41:53 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A63F4F@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A607A0@SHSMSX103.ccr.corp.intel.com>
	<1415964503.7113.14.camel@citrix.com>
In-Reply-To: <1415964503.7113.14.camel@citrix.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: Fabio Fantoni <fabio.fantoni@m2r.biz>, Wei Liu <wei.liu2@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Friday, November 14, 2014 7:28 PM
> To: Hu, Robert
> Cc: Fabio Fantoni; Wei Liu; JBeulich@suse.com; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> On Fri, 2014-11-14 at 10:14 +0000, Hu, Robert wrote:
> > Will rerun this test case in RC2 testing, and if still there, append
> > the full logs then.
> 
> Thank you.
> 
> BTW, I've pointed this need for logs out to multiple of your
> predecessors over the years. If you could try and get this information
> (e.g. the link to the wiki, the need for logs in the general case) added
> to your internal documentation (test plan, onboard docs for new
> engineers, etc) that would be awesome.
Yes, I'm trying to perfect the procedure in this direction.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 01:56:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 01:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XquV7-0007M4-9F; Wed, 19 Nov 2014 01:56:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XquV5-0007Lw-MA
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 01:56:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	93/02-09936-6B8FB645; Wed, 19 Nov 2014 01:56:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416362165!13708704!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12061 invoked from network); 19 Nov 2014 01:56:06 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 01:56:06 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJ1tpON012575
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 01:55:52 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJ1tmEV007059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 01:55:51 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJ1tm7d013871; Wed, 19 Nov 2014 01:55:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 17:55:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 127A5117D84; Tue, 18 Nov 2014 20:55:42 -0500 (EST)
Date: Tue, 18 Nov 2014 20:55:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141119015541.GA10307@laptop.dumpdata.com>
References: <1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<20141118205633.GB6540@laptop.dumpdata.com>
	<348130555.20141118231254@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <348130555.20141118231254@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
> 
> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
> 
> >> 
> >> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
> >> about them .. however looking at the earlier reports these lines were also in 
> >> those reports).
> >> 
> >> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
> >> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
> >> and had a new default seabios config. (just to rule out anything stale in my tree)
> >> 
> >> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
> >> seabios config) are not the most recent (they don't get updated automatically 
> >> when you just do a git pull on the main tree) ?
> >> 
> >> In /tools/firmware/seabios-dir/.config i have:
> >> CONFIG_USB=y
> >> CONFIG_USB_UHCI=y
> >> CONFIG_USB_OHCI=y
> >> CONFIG_USB_EHCI=y
> >> CONFIG_USB_XHCI=y
> >> CONFIG_USB_MSC=y
> >> CONFIG_USB_UAS=y
> >> CONFIG_USB_HUB=y
> >> CONFIG_USB_KEYBOARD=y
> >> CONFIG_USB_MOUSE=y
> >> 
> 
> > I seem to have the same thing. Perhaps it is my XHCI controller being wonky.
> 
> >> And this is all just from a:
> >> - git clone git://xenbits.xen.org/xen.git -b staging
> >> - make clean && ./configure && make -j6 && make -j6 install
> 
> > Aye. 
> > .. snip..
> >> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
> >> >     [But this might be invalid as the addition of the ffff8303faaf25a8
> >> >      might be correct - as the second dpci the softirq is processing
> >> >      could be the MSI one]
> >> 
> >> Would there be an easy way to stress test this function separately in some 
> >> debugging function to see if it indeed is returning unexpected values ?
> 
> > Sadly no. But you got me looking in the right direction when you mentioned
> > 'timeout'.
> >> 
> >> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
> >> 
> >> Just curious, have you also tested the patches on AMD hardware ?
> 
> > Yes. To reproduce this the first thing I did was to get an AMD box.
> 
> >> 
> >>  
> >> >> When i look at the combination of (2) and (3), It seems it could be an 
> >> >> interaction between the two passed through devices and/or different IRQ types.
> >> 
> >> > Could be - as in it is causing this issue to show up faster than
> >> > expected. Or it is the one that triggers more than one dpci happening
> >> > at the same time.
> >> 
> >> Well that didn't seem to be it (see separate amendment i mailed previously)
> 
> > Right, the current theory I've is that the interrupts are not being
> > Acked within 8 milisecond and we reset the 'state' - and at the same
> > time we get an interrupt and schedule it - while we are still processing
> > the same interrupt. This would explain why the 'test_and_clear_bit'
> > got the wrong value.
> 
> > In regards to the list poison - following this thread of logic - with
> > the 'state = 0' set we open the floodgates for any CPU to put the same
> > 'struct hvm_pirq_dpci' on its list.
> 
> > We do reset the 'state' on _every_ GSI that is mapped to a guest - so
> > we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:
> 
> > CPUX:                           CPUY:
> > pt_irq_time_out:
> > state = 0;                      
> > [out of timer coder, the                raise_softirq
> >  pirq_dpci is on the dpci_list]         [adds the pirq_dpci as state == 0]
> 
> > softirq_dpci                            softirq_dpci:
> >         list_del
> >         [entries poison]
> >                                                 list_del <= BOOM
> >                         
> > Is what I believe is happening.
> 
> > The INTX device - once I put a load on it - does not trigger
> > any pt_irq_time_out, so that would explain why I cannot hit this.
> 
> > But I believe your card hits these "hiccups".   
> 
> 
> Hi Konrad,
> 
> I just tested you 5 patches and as a result i still got an(other) host crash:
> (complete serial log attached)
> 
> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> (XEN) [2014-11-18 21:55:41.591] CPU:    0
> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08012c7e7>]CPU:    2
> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
> (XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010006    _spin_unlock+0x1f/0x30CONTEXT: hypervisor

Duh!

Here is another patch on top of the five you have (attached and inline).

>From 18008650f10199e2b83f74394f634a97086e34b8 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 18 Nov 2014 20:48:43 -0500
Subject: [PATCH] debug: Whether we want to clear the 'dom' field or not when
 changing the 'state' bit.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index aad5607..24e2bd6 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -243,13 +243,14 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 }
 
 /*
- * Reset the pirq_dpci->dom parameter to NULL.
+ * Reset the pirq_dpci->dom parameter to NULL if 'clear_dom' is set.
  *
  * This function checks the different states to make sure it can do it
  * at the right time. If it unschedules the 'hvm_dirq_assist' from running
  * it also refcounts (which is what the softirq would have done) properly.
  */
-static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci,
+                                  unsigned int clear_dom)
 {
     struct domain *d = pirq_dpci->dom;
     struct __debug *debug = &__get_cpu_var(_d);
@@ -276,7 +277,8 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
          * in local variable before it sets STATE_RUN - and therefore will not
          * dereference '->dom' which would crash.
          */
-        pirq_dpci->dom = NULL;
+        if (clear_dom)
+            pirq_dpci->dom = NULL;
         break;
     }
 }
@@ -295,7 +297,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
                               &pirq_dpci->flags) )
     {
         _record(&debug->clear, pirq_dpci);
-        pt_pirq_softirq_reset(pirq_dpci);
+        pt_pirq_softirq_reset(pirq_dpci, 0 /* leave ->dom /);
         /* pirq_dpci->state = 0; <= OUCH! */
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
@@ -333,9 +335,11 @@ static void pt_irq_time_out(void *data)
     pt_pirq_iterate(irq_map->dom, pt_irq_guest_eoi, NULL);
 
     spin_unlock(&irq_map->dom->event_lock);
+#if 0
     console_start_sync();
     dump_debug((char)0);
     console_end_sync();
+#endif
 }
 
 struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *d)
@@ -446,7 +450,7 @@ int pt_irq_create_bind(
                      * in the queue.
                      */
                     pirq_dpci->line = __LINE__;
-                    pt_pirq_softirq_reset(pirq_dpci);
+                    pt_pirq_softirq_reset(pirq_dpci, 1 /* clear dom */);
                 }
             }
             if ( unlikely(rc) )
@@ -701,7 +705,7 @@ int pt_irq_destroy_bind(
          * call to pt_pirq_softirq_reset.
          */
         pirq_dpci->line = __LINE__;
-        pt_pirq_softirq_reset(pirq_dpci);
+        pt_pirq_softirq_reset(pirq_dpci, 1 /* clear ->dom */);
 
         pirq_cleanup_check(pirq, d);
     }
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 01:56:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 01:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XquV7-0007M4-9F; Wed, 19 Nov 2014 01:56:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XquV5-0007Lw-MA
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 01:56:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	93/02-09936-6B8FB645; Wed, 19 Nov 2014 01:56:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416362165!13708704!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12061 invoked from network); 19 Nov 2014 01:56:06 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 01:56:06 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJ1tpON012575
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 01:55:52 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJ1tmEV007059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 01:55:51 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJ1tm7d013871; Wed, 19 Nov 2014 01:55:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Nov 2014 17:55:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 127A5117D84; Tue, 18 Nov 2014 20:55:42 -0500 (EST)
Date: Tue, 18 Nov 2014 20:55:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141119015541.GA10307@laptop.dumpdata.com>
References: <1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<20141118205633.GB6540@laptop.dumpdata.com>
	<348130555.20141118231254@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <348130555.20141118231254@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
> 
> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
> 
> >> 
> >> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
> >> about them .. however looking at the earlier reports these lines were also in 
> >> those reports).
> >> 
> >> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
> >> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
> >> and had a new default seabios config. (just to rule out anything stale in my tree)
> >> 
> >> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
> >> seabios config) are not the most recent (they don't get updated automatically 
> >> when you just do a git pull on the main tree) ?
> >> 
> >> In /tools/firmware/seabios-dir/.config i have:
> >> CONFIG_USB=y
> >> CONFIG_USB_UHCI=y
> >> CONFIG_USB_OHCI=y
> >> CONFIG_USB_EHCI=y
> >> CONFIG_USB_XHCI=y
> >> CONFIG_USB_MSC=y
> >> CONFIG_USB_UAS=y
> >> CONFIG_USB_HUB=y
> >> CONFIG_USB_KEYBOARD=y
> >> CONFIG_USB_MOUSE=y
> >> 
> 
> > I seem to have the same thing. Perhaps it is my XHCI controller being wonky.
> 
> >> And this is all just from a:
> >> - git clone git://xenbits.xen.org/xen.git -b staging
> >> - make clean && ./configure && make -j6 && make -j6 install
> 
> > Aye. 
> > .. snip..
> >> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
> >> >     [But this might be invalid as the addition of the ffff8303faaf25a8
> >> >      might be correct - as the second dpci the softirq is processing
> >> >      could be the MSI one]
> >> 
> >> Would there be an easy way to stress test this function separately in some 
> >> debugging function to see if it indeed is returning unexpected values ?
> 
> > Sadly no. But you got me looking in the right direction when you mentioned
> > 'timeout'.
> >> 
> >> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
> >> 
> >> Just curious, have you also tested the patches on AMD hardware ?
> 
> > Yes. To reproduce this the first thing I did was to get an AMD box.
> 
> >> 
> >>  
> >> >> When i look at the combination of (2) and (3), It seems it could be an 
> >> >> interaction between the two passed through devices and/or different IRQ types.
> >> 
> >> > Could be - as in it is causing this issue to show up faster than
> >> > expected. Or it is the one that triggers more than one dpci happening
> >> > at the same time.
> >> 
> >> Well that didn't seem to be it (see separate amendment i mailed previously)
> 
> > Right, the current theory I've is that the interrupts are not being
> > Acked within 8 milisecond and we reset the 'state' - and at the same
> > time we get an interrupt and schedule it - while we are still processing
> > the same interrupt. This would explain why the 'test_and_clear_bit'
> > got the wrong value.
> 
> > In regards to the list poison - following this thread of logic - with
> > the 'state = 0' set we open the floodgates for any CPU to put the same
> > 'struct hvm_pirq_dpci' on its list.
> 
> > We do reset the 'state' on _every_ GSI that is mapped to a guest - so
> > we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:
> 
> > CPUX:                           CPUY:
> > pt_irq_time_out:
> > state = 0;                      
> > [out of timer coder, the                raise_softirq
> >  pirq_dpci is on the dpci_list]         [adds the pirq_dpci as state == 0]
> 
> > softirq_dpci                            softirq_dpci:
> >         list_del
> >         [entries poison]
> >                                                 list_del <= BOOM
> >                         
> > Is what I believe is happening.
> 
> > The INTX device - once I put a load on it - does not trigger
> > any pt_irq_time_out, so that would explain why I cannot hit this.
> 
> > But I believe your card hits these "hiccups".   
> 
> 
> Hi Konrad,
> 
> I just tested you 5 patches and as a result i still got an(other) host crash:
> (complete serial log attached)
> 
> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> (XEN) [2014-11-18 21:55:41.591] CPU:    0
> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08012c7e7>]CPU:    2
> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
> (XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010006    _spin_unlock+0x1f/0x30CONTEXT: hypervisor

Duh!

Here is another patch on top of the five you have (attached and inline).

>From 18008650f10199e2b83f74394f634a97086e34b8 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 18 Nov 2014 20:48:43 -0500
Subject: [PATCH] debug: Whether we want to clear the 'dom' field or not when
 changing the 'state' bit.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index aad5607..24e2bd6 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -243,13 +243,14 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 }
 
 /*
- * Reset the pirq_dpci->dom parameter to NULL.
+ * Reset the pirq_dpci->dom parameter to NULL if 'clear_dom' is set.
  *
  * This function checks the different states to make sure it can do it
  * at the right time. If it unschedules the 'hvm_dirq_assist' from running
  * it also refcounts (which is what the softirq would have done) properly.
  */
-static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci,
+                                  unsigned int clear_dom)
 {
     struct domain *d = pirq_dpci->dom;
     struct __debug *debug = &__get_cpu_var(_d);
@@ -276,7 +277,8 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
          * in local variable before it sets STATE_RUN - and therefore will not
          * dereference '->dom' which would crash.
          */
-        pirq_dpci->dom = NULL;
+        if (clear_dom)
+            pirq_dpci->dom = NULL;
         break;
     }
 }
@@ -295,7 +297,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
                               &pirq_dpci->flags) )
     {
         _record(&debug->clear, pirq_dpci);
-        pt_pirq_softirq_reset(pirq_dpci);
+        pt_pirq_softirq_reset(pirq_dpci, 0 /* leave ->dom /);
         /* pirq_dpci->state = 0; <= OUCH! */
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
@@ -333,9 +335,11 @@ static void pt_irq_time_out(void *data)
     pt_pirq_iterate(irq_map->dom, pt_irq_guest_eoi, NULL);
 
     spin_unlock(&irq_map->dom->event_lock);
+#if 0
     console_start_sync();
     dump_debug((char)0);
     console_end_sync();
+#endif
 }
 
 struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *d)
@@ -446,7 +450,7 @@ int pt_irq_create_bind(
                      * in the queue.
                      */
                     pirq_dpci->line = __LINE__;
-                    pt_pirq_softirq_reset(pirq_dpci);
+                    pt_pirq_softirq_reset(pirq_dpci, 1 /* clear dom */);
                 }
             }
             if ( unlikely(rc) )
@@ -701,7 +705,7 @@ int pt_irq_destroy_bind(
          * call to pt_pirq_softirq_reset.
          */
         pirq_dpci->line = __LINE__;
-        pt_pirq_softirq_reset(pirq_dpci);
+        pt_pirq_softirq_reset(pirq_dpci, 1 /* clear ->dom */);
 
         pirq_cleanup_check(pirq, d);
     }
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 03:48:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 03:48:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqwFe-0000Ma-Rx; Wed, 19 Nov 2014 03:48:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqwFd-0000MU-3e
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 03:48:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C8/25-25276-0031C645; Wed, 19 Nov 2014 03:48:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416368894!13761870!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17361 invoked from network); 19 Nov 2014 03:48:15 -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;
	19 Nov 2014 03:48:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,414,1413244800"; d="scan'208";a="192751713"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 22:48:12 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqwFY-0008Ad-KD;
	Wed, 19 Nov 2014 03:48:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqwFY-0001i2-EL;
	Wed, 19 Nov 2014 03:48:12 +0000
Date: Wed, 19 Nov 2014 03:48:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31663-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 12387
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.4-testing test] 31663: 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: multipart/mixed; boundary="===============0627674269859683580=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0627674269859683580==
Content-Type: text/plain
Content-Length: 12165
Content-Transfer-Encoding: quoted-printable

flight 31663 qemu-upstream-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31663/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot               fail blocked in 25336

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                b04df88d41f64fc6b56d193b6e90fb840cedb1d3
baseline version:
 qemuu                65fc9b78ba3d868a26952db0d8e51cecf01d47b4

------------------------------------------------------------
People who touched revisions under test:
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dqemu-upstream-4.4-testing
+ revision=3Db04df88d41f64fc6b56d193b6e90fb840cedb1d3
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-4.4-testing b04df88d41f64fc6b56d193b6e90fb840cedb1d3
+ branch=3Dqemu-upstream-4.4-testing
+ revision=3Db04df88d41f64fc6b56d193b6e90fb840cedb1d3
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dqemuu
+ xenbranch=3Dxen-4.4-testing
+ '[' xqemuu =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-4.4-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.4-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-4.4-testing
++ : daily-cron.qemu-upstream-4.4-testing
++ : daily-cron.qemu-upstream-4.4-testing
++ : daily-cron.qemu-upstream-4.4-testing
++ : daily-cron.qemu-upstream-4.4-testing
++ : daily-cron.qemu-upstream-4.4-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.4-testing.git
++ : daily-cron.qemu-upstream-4.4-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-upstream-4.4-testing
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-upstream-4.4-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-4.4-testing
+ git push osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git b04df88d41f64fc6b56d193b6e90fb840cedb1d3:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git
   65fc9b7..b04df88  b04df88d41f64fc6b56d193b6e90fb840cedb1d3 -> master


--===============0627674269859683580==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0627674269859683580==--

From xen-devel-bounces@lists.xen.org Wed Nov 19 03:48:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 03:48:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqwFe-0000Ma-Rx; Wed, 19 Nov 2014 03:48:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqwFd-0000MU-3e
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 03:48:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C8/25-25276-0031C645; Wed, 19 Nov 2014 03:48:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416368894!13761870!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17361 invoked from network); 19 Nov 2014 03:48:15 -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;
	19 Nov 2014 03:48:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,414,1413244800"; d="scan'208";a="192751713"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 22:48:12 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqwFY-0008Ad-KD;
	Wed, 19 Nov 2014 03:48:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqwFY-0001i2-EL;
	Wed, 19 Nov 2014 03:48:12 +0000
Date: Wed, 19 Nov 2014 03:48:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31663-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 12387
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.4-testing test] 31663: 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: multipart/mixed; boundary="===============0627674269859683580=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0627674269859683580==
Content-Type: text/plain
Content-Length: 12165
Content-Transfer-Encoding: quoted-printable

flight 31663 qemu-upstream-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31663/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot               fail blocked in 25336

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                b04df88d41f64fc6b56d193b6e90fb840cedb1d3
baseline version:
 qemuu                65fc9b78ba3d868a26952db0d8e51cecf01d47b4

------------------------------------------------------------
People who touched revisions under test:
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dqemu-upstream-4.4-testing
+ revision=3Db04df88d41f64fc6b56d193b6e90fb840cedb1d3
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-4.4-testing b04df88d41f64fc6b56d193b6e90fb840cedb1d3
+ branch=3Dqemu-upstream-4.4-testing
+ revision=3Db04df88d41f64fc6b56d193b6e90fb840cedb1d3
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dqemuu
+ xenbranch=3Dxen-4.4-testing
+ '[' xqemuu =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-4.4-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.4-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-4.4-testing
++ : daily-cron.qemu-upstream-4.4-testing
++ : daily-cron.qemu-upstream-4.4-testing
++ : daily-cron.qemu-upstream-4.4-testing
++ : daily-cron.qemu-upstream-4.4-testing
++ : daily-cron.qemu-upstream-4.4-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.4-testing.git
++ : daily-cron.qemu-upstream-4.4-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-upstream-4.4-testing
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-upstream-4.4-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-4.4-testing
+ git push osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git b04df88d41f64fc6b56d193b6e90fb840cedb1d3:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git
   65fc9b7..b04df88  b04df88d41f64fc6b56d193b6e90fb840cedb1d3 -> master


--===============0627674269859683580==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0627674269859683580==--

From xen-devel-bounces@lists.xen.org Wed Nov 19 04:55:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 04:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqxI9-0001Ec-Fc; Wed, 19 Nov 2014 04:54:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqxI7-0001EX-Fq
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 04:54:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BE/40-09842-E922C645; Wed, 19 Nov 2014 04:54:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416372892!13776070!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18419 invoked from network); 19 Nov 2014 04:54:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 04:54:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="192760314"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 23:54:50 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqxI2-0008UJ-Oz;
	Wed, 19 Nov 2014 04:54:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqxI2-0003x5-CR;
	Wed, 19 Nov 2014 04:54:50 +0000
Date: Wed, 19 Nov 2014 04:54:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31659-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31659: 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 31659 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31659/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31489

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  0540b854f6733759593e829bc3f13c9b45974e32
baseline version:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Emil Condrea <emilcondrea@gmail.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  M A Young <m.a.young@durham.ac.uk>
  Meng Xu <mengxu@cis.upenn.edu>
  Michael Young <m.a.young@durham.ac.uk>
  Olaf Hering <olaf@aepfle.de>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=0540b854f6733759593e829bc3f13c9b45974e32
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 0540b854f6733759593e829bc3f13c9b45974e32
+ branch=xen-unstable
+ revision=0540b854f6733759593e829bc3f13c9b45974e32
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 0540b854f6733759593e829bc3f13c9b45974e32:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   e6fa63d..0540b85  0540b854f6733759593e829bc3f13c9b45974e32 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 04:55:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 04:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XqxI9-0001Ec-Fc; Wed, 19 Nov 2014 04:54:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XqxI7-0001EX-Fq
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 04:54:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BE/40-09842-E922C645; Wed, 19 Nov 2014 04:54:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416372892!13776070!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18419 invoked from network); 19 Nov 2014 04:54:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 04:54:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="192760314"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 18 Nov 2014 23:54:50 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XqxI2-0008UJ-Oz;
	Wed, 19 Nov 2014 04:54:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XqxI2-0003x5-CR;
	Wed, 19 Nov 2014 04:54:50 +0000
Date: Wed, 19 Nov 2014 04:54:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31659-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31659: 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 31659 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31659/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31489

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  0540b854f6733759593e829bc3f13c9b45974e32
baseline version:
 xen                  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Emil Condrea <emilcondrea@gmail.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  M A Young <m.a.young@durham.ac.uk>
  Meng Xu <mengxu@cis.upenn.edu>
  Michael Young <m.a.young@durham.ac.uk>
  Olaf Hering <olaf@aepfle.de>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=0540b854f6733759593e829bc3f13c9b45974e32
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 0540b854f6733759593e829bc3f13c9b45974e32
+ branch=xen-unstable
+ revision=0540b854f6733759593e829bc3f13c9b45974e32
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 0540b854f6733759593e829bc3f13c9b45974e32:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   e6fa63d..0540b85  0540b854f6733759593e829bc3f13c9b45974e32 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 06:35:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 06:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqyqi-0002qx-Sg; Wed, 19 Nov 2014 06:34:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xqyqh-0002qa-47
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 06:34:43 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	FF/26-25547-20A3C645; Wed, 19 Nov 2014 06:34:42 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416378878!12360308!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27527 invoked from network); 19 Nov 2014 06:34:40 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 06:34:40 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Tue, 18 Nov 2014 23:34:22 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Wed, 19 Nov 2014 14:34:09 +0800
Message-Id: <1416378851-32236-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently libxl__domain_rename only update /local/domain/<domid>/name,
still some places in xenstore are not updated, including:
/vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.

This patch series updates /vm/<uuid>/name in xenstore, and removes the unusual
'domain' field under backend directory.

---
Changes to v2:
  * split one patch into two:
    1/2 remove 'domain' field in backend dir;
    2/2 add code to update /vm/<uuid>/name
  * remove all redundant logging.

Chunyan Liu (2):
  remove domain field in xenstore backend dir
  fix rename: xenstore not fully updated

 tools/libxl/libxl.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 06:35:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 06:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqyqj-0002r4-70; Wed, 19 Nov 2014 06:34:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xqyqh-0002qf-AW
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 06:34:43 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	89/F8-22737-20A3C645; Wed, 19 Nov 2014 06:34:42 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416378878!12147809!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20210 invoked from network); 19 Nov 2014 06:34:40 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 06:34:40 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Tue, 18 Nov 2014 23:34:27 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Wed, 19 Nov 2014 14:34:11 +0800
Message-Id: <1416378851-32236-3-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1416378851-32236-1-git-send-email-cyliu@suse.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH 2/2 V3] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__domain_rename only updates /local/domain/<domid>/name,
/vm/<uuid>/name in xenstore are not updated. Add code in
libxl__domain_rename to update /vm/<uuid>/name too.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 tools/libxl/libxl.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index dbefaf3..b403edc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
     uint32_t stub_dm_domid;
     const char *stub_dm_old_name = NULL, *stub_dm_new_name = NULL;
     int rc;
+    libxl_dominfo info;
+    char *uuid;
+    const char *vm_name_path;
 
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) goto x_nomem;
@@ -429,6 +432,16 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
         goto x_fail;
     }
 
+    /* update /vm/<uuid>/name */
+    rc = libxl_domain_info(ctx, &info, domid);
+    if (rc)
+        goto x_fail;
+
+    uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
+    vm_name_path = GCSPRINTF("/vm/%s/name", uuid);
+    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name))
+        goto x_fail;
+
     if (stub_dm_domid) {
         rc = libxl__domain_rename(gc, stub_dm_domid,
                                   stub_dm_old_name,
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 06:35:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 06:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqyqh-0002qk-FM; Wed, 19 Nov 2014 06:34:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xqyqg-0002qZ-DP
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 06:34:42 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BE/6F-25276-10A3C645; Wed, 19 Nov 2014 06:34:41 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416378879!13778694!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30461 invoked from network); 19 Nov 2014 06:34:40 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 06:34:40 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Tue, 18 Nov 2014 23:34:25 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Wed, 19 Nov 2014 14:34:10 +0800
Message-Id: <1416378851-32236-2-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1416378851-32236-1-git-send-email-cyliu@suse.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH 1/2 V3] remove domain field in xenstore backend
	dir
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 unusual 'domain' field under backend directory. The
affected are backend/console, backend/vfb, backend/vkbd.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 tools/libxl/libxl.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..dbefaf3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3605,8 +3605,6 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
     flexarray_append(back, "1");
     flexarray_append(back, "state");
     flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(gc, domid));
     flexarray_append(back, "protocol");
     flexarray_append(back, LIBXL_XENCONSOLE_PROTOCOL);
 
@@ -3943,8 +3941,6 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
     flexarray_append(back, "1");
     flexarray_append(back, "state");
     flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(gc, domid));
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid));
@@ -4041,7 +4037,6 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb)
     flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
     flexarray_append_pair(back, "online", "1");
     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_defbool_val(vfb->vnc.enable) ? "1" : "0");
     flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 06:35:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 06:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqyqj-0002r4-70; Wed, 19 Nov 2014 06:34:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xqyqh-0002qf-AW
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 06:34:43 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	89/F8-22737-20A3C645; Wed, 19 Nov 2014 06:34:42 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416378878!12147809!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20210 invoked from network); 19 Nov 2014 06:34:40 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 06:34:40 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Tue, 18 Nov 2014 23:34:27 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Wed, 19 Nov 2014 14:34:11 +0800
Message-Id: <1416378851-32236-3-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1416378851-32236-1-git-send-email-cyliu@suse.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH 2/2 V3] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__domain_rename only updates /local/domain/<domid>/name,
/vm/<uuid>/name in xenstore are not updated. Add code in
libxl__domain_rename to update /vm/<uuid>/name too.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 tools/libxl/libxl.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index dbefaf3..b403edc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
     uint32_t stub_dm_domid;
     const char *stub_dm_old_name = NULL, *stub_dm_new_name = NULL;
     int rc;
+    libxl_dominfo info;
+    char *uuid;
+    const char *vm_name_path;
 
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) goto x_nomem;
@@ -429,6 +432,16 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
         goto x_fail;
     }
 
+    /* update /vm/<uuid>/name */
+    rc = libxl_domain_info(ctx, &info, domid);
+    if (rc)
+        goto x_fail;
+
+    uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
+    vm_name_path = GCSPRINTF("/vm/%s/name", uuid);
+    if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name))
+        goto x_fail;
+
     if (stub_dm_domid) {
         rc = libxl__domain_rename(gc, stub_dm_domid,
                                   stub_dm_old_name,
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 06:35:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 06:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqyqi-0002qx-Sg; Wed, 19 Nov 2014 06:34:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xqyqh-0002qa-47
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 06:34:43 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	FF/26-25547-20A3C645; Wed, 19 Nov 2014 06:34:42 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416378878!12360308!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27527 invoked from network); 19 Nov 2014 06:34:40 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 06:34:40 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Tue, 18 Nov 2014 23:34:22 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Wed, 19 Nov 2014 14:34:09 +0800
Message-Id: <1416378851-32236-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently libxl__domain_rename only update /local/domain/<domid>/name,
still some places in xenstore are not updated, including:
/vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.

This patch series updates /vm/<uuid>/name in xenstore, and removes the unusual
'domain' field under backend directory.

---
Changes to v2:
  * split one patch into two:
    1/2 remove 'domain' field in backend dir;
    2/2 add code to update /vm/<uuid>/name
  * remove all redundant logging.

Chunyan Liu (2):
  remove domain field in xenstore backend dir
  fix rename: xenstore not fully updated

 tools/libxl/libxl.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 06:35:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 06:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqyqh-0002qk-FM; Wed, 19 Nov 2014 06:34:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xqyqg-0002qZ-DP
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 06:34:42 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BE/6F-25276-10A3C645; Wed, 19 Nov 2014 06:34:41 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416378879!13778694!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30461 invoked from network); 19 Nov 2014 06:34:40 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 06:34:40 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Tue, 18 Nov 2014 23:34:25 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Wed, 19 Nov 2014 14:34:10 +0800
Message-Id: <1416378851-32236-2-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1416378851-32236-1-git-send-email-cyliu@suse.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH 1/2 V3] remove domain field in xenstore backend
	dir
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 unusual 'domain' field under backend directory. The
affected are backend/console, backend/vfb, backend/vkbd.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 tools/libxl/libxl.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..dbefaf3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3605,8 +3605,6 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
     flexarray_append(back, "1");
     flexarray_append(back, "state");
     flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(gc, domid));
     flexarray_append(back, "protocol");
     flexarray_append(back, LIBXL_XENCONSOLE_PROTOCOL);
 
@@ -3943,8 +3941,6 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
     flexarray_append(back, "1");
     flexarray_append(back, "state");
     flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(gc, domid));
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid));
@@ -4041,7 +4037,6 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb)
     flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
     flexarray_append_pair(back, "online", "1");
     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_defbool_val(vfb->vnc.enable) ? "1" : "0");
     flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 07:14:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 07: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 1XqzSS-0003kP-AB; Wed, 19 Nov 2014 07:13:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XqzSR-0003kI-7Z
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 07:13:43 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	5D/C7-14727-6234C645; Wed, 19 Nov 2014 07:13:42 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416381219!8039395!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22307 invoked from network); 19 Nov 2014 07:13:41 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 07:13:41 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 19 Nov 2014 00:13:17 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Wed, 19 Nov 2014 15:12:51 +0800
Message-Id: <1416381171-16772-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH] fix restore: xenstore entries left when restore
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While running libvirt-tck domain/102-broken-save-restore.t
test (save domain, corrupt saved file by truncate the last 512k,
then restore), found that restore domain failed, but domain
related xenstore entries still exist in xenstore.

Add a patch to clear xenstore entries in this case.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 tools/libxl/libxl.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..447840d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1525,6 +1525,54 @@ static void devices_destroy_cb(libxl__egc *egc,
                                libxl__devices_remove_state *drs,
                                int rc);
 
+static void libxl_clear_xs_entry(libxl__gc *gc, uint32_t domid)
+{
+    const char *dom_path, *vm_path;
+    char *path;
+    unsigned int num_kinds, num_dev_xsentries;
+    char **kinds = NULL, **devs = NULL;
+    int i, j;
+
+    /* remove libxl path */
+    libxl__xs_rm_checked(gc, XBT_NULL, libxl__xs_libxl_path(gc, domid));
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path)
+        return;
+
+    /* remove backend entries */
+    path = GCSPRINTF("%s/device", dom_path);
+    kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds);
+    if (kinds && num_kinds) {
+        for (i = 0; i < num_kinds; i++) {
+            path = GCSPRINTF("%s/device/%s", dom_path, kinds[i]);
+            devs = libxl__xs_directory(gc, XBT_NULL, path, &num_dev_xsentries);
+            if (!devs)
+                continue;
+            for (j = 0; j < num_dev_xsentries; j++) {
+                path = GCSPRINTF("%s/device/%s/%s/backend",
+                                 dom_path, kinds[i], devs[j]);
+                path = libxl__xs_read(gc, XBT_NULL, path);
+                if (path)
+                    libxl__xs_rm_checked(gc, XBT_NULL, path);
+            }
+        }
+    }
+
+    path = GCSPRINTF("%s/console/backend", dom_path);
+    path = libxl__xs_read(gc, XBT_NULL, path);
+    if (path)
+        libxl__xs_rm_checked(gc, XBT_NULL, path);
+
+    /* remove vm path */
+    vm_path = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/vm", dom_path));
+    if (vm_path)
+        libxl__xs_rm_checked(gc, XBT_NULL, vm_path);
+
+    /* remove dom path */
+    libxl__xs_rm_checked(gc, XBT_NULL, dom_path);
+}
+
 void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis)
 {
     STATE_AO_GC(dis->ao);
@@ -1540,6 +1588,10 @@ void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis)
         break;
     case ERROR_INVAL:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "non-existant domain %d", domid);
+        /* domain may not started successfully but some xenstore entries
+         * might be created already in earlier stage. We need to clear
+         * those entries. */
+        libxl_clear_xs_entry(gc, domid);
     default:
         goto out;
     }
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 07:14:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 07: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 1XqzSS-0003kP-AB; Wed, 19 Nov 2014 07:13:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XqzSR-0003kI-7Z
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 07:13:43 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	5D/C7-14727-6234C645; Wed, 19 Nov 2014 07:13:42 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416381219!8039395!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22307 invoked from network); 19 Nov 2014 07:13:41 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 07:13:41 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 19 Nov 2014 00:13:17 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Wed, 19 Nov 2014 15:12:51 +0800
Message-Id: <1416381171-16772-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [PATCH] fix restore: xenstore entries left when restore
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While running libvirt-tck domain/102-broken-save-restore.t
test (save domain, corrupt saved file by truncate the last 512k,
then restore), found that restore domain failed, but domain
related xenstore entries still exist in xenstore.

Add a patch to clear xenstore entries in this case.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 tools/libxl/libxl.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..447840d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1525,6 +1525,54 @@ static void devices_destroy_cb(libxl__egc *egc,
                                libxl__devices_remove_state *drs,
                                int rc);
 
+static void libxl_clear_xs_entry(libxl__gc *gc, uint32_t domid)
+{
+    const char *dom_path, *vm_path;
+    char *path;
+    unsigned int num_kinds, num_dev_xsentries;
+    char **kinds = NULL, **devs = NULL;
+    int i, j;
+
+    /* remove libxl path */
+    libxl__xs_rm_checked(gc, XBT_NULL, libxl__xs_libxl_path(gc, domid));
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path)
+        return;
+
+    /* remove backend entries */
+    path = GCSPRINTF("%s/device", dom_path);
+    kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds);
+    if (kinds && num_kinds) {
+        for (i = 0; i < num_kinds; i++) {
+            path = GCSPRINTF("%s/device/%s", dom_path, kinds[i]);
+            devs = libxl__xs_directory(gc, XBT_NULL, path, &num_dev_xsentries);
+            if (!devs)
+                continue;
+            for (j = 0; j < num_dev_xsentries; j++) {
+                path = GCSPRINTF("%s/device/%s/%s/backend",
+                                 dom_path, kinds[i], devs[j]);
+                path = libxl__xs_read(gc, XBT_NULL, path);
+                if (path)
+                    libxl__xs_rm_checked(gc, XBT_NULL, path);
+            }
+        }
+    }
+
+    path = GCSPRINTF("%s/console/backend", dom_path);
+    path = libxl__xs_read(gc, XBT_NULL, path);
+    if (path)
+        libxl__xs_rm_checked(gc, XBT_NULL, path);
+
+    /* remove vm path */
+    vm_path = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/vm", dom_path));
+    if (vm_path)
+        libxl__xs_rm_checked(gc, XBT_NULL, vm_path);
+
+    /* remove dom path */
+    libxl__xs_rm_checked(gc, XBT_NULL, dom_path);
+}
+
 void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis)
 {
     STATE_AO_GC(dis->ao);
@@ -1540,6 +1588,10 @@ void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis)
         break;
     case ERROR_INVAL:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "non-existant domain %d", domid);
+        /* domain may not started successfully but some xenstore entries
+         * might be created already in earlier stage. We need to clear
+         * those entries. */
+        libxl_clear_xs_entry(gc, domid);
     default:
         goto out;
     }
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 07:36:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 07:36:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqzng-00042v-57; Wed, 19 Nov 2014 07:35:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xqzne-00042q-Aa
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 07:35:38 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	67/45-25727-9484C645; Wed, 19 Nov 2014 07:35:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416382537!9897761!1
X-Originating-IP: [81.169.146.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9675 invoked from network); 19 Nov 2014 07:35:37 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 07:35:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416382537; l=519;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=ECWg0d39gbFZUYoI6yB4+7IdkDo=;
	b=dqm7GBfrhANNbvLfxuCdrOcx8dJkz7VLuRypYo9n+f6TwsKdeMCeLBEsngYzVWKkdeA
	OkUjFAEQ0BlupqaCncRZHkPJYH0qIJGRD3NTl+qR0uFC8gf/e2y1jicdSNYaxh2RQf2nR
	w0Ha4hT6XK57jJHFuLaSpKJdAj+8ETlXuT0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.12 AUTH) with ESMTPSA id Q0020aqAJ7ZOQDC
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 19 Nov 2014 08:35:24 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 8118450172; Wed, 19 Nov 2014 08:35:24 +0100 (CET)
Date: Wed, 19 Nov 2014 08:35:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141119073524.GA21195@aepfle.de>
References: <1416327994-29619-1-git-send-email-olaf@aepfle.de>
	<21611.30074.302907.667308@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21611.30074.302907.667308@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: use more fixed strings to build 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, Nov 18, Ian Jackson wrote:

> How about
> 
>    It should be possible to repeatedly build identical sources
>    and get identical binaries, even on different hosts at different
>    build times.  This fails [etc. etc. ...]
> 
>    Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and XEN_BUILD_HOST
>    which the build environment can set to fixed strings to get a
>    reproducible build.
> 
> or some such.

Thanks. Do you want me to resend with this updated changelog, or will it
be used while applying?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 07:36:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 07:36:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xqzng-00042v-57; Wed, 19 Nov 2014 07:35:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xqzne-00042q-Aa
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 07:35:38 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	67/45-25727-9484C645; Wed, 19 Nov 2014 07:35:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416382537!9897761!1
X-Originating-IP: [81.169.146.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9675 invoked from network); 19 Nov 2014 07:35:37 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 07:35:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416382537; l=519;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=ECWg0d39gbFZUYoI6yB4+7IdkDo=;
	b=dqm7GBfrhANNbvLfxuCdrOcx8dJkz7VLuRypYo9n+f6TwsKdeMCeLBEsngYzVWKkdeA
	OkUjFAEQ0BlupqaCncRZHkPJYH0qIJGRD3NTl+qR0uFC8gf/e2y1jicdSNYaxh2RQf2nR
	w0Ha4hT6XK57jJHFuLaSpKJdAj+8ETlXuT0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.12 AUTH) with ESMTPSA id Q0020aqAJ7ZOQDC
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 19 Nov 2014 08:35:24 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 8118450172; Wed, 19 Nov 2014 08:35:24 +0100 (CET)
Date: Wed, 19 Nov 2014 08:35:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141119073524.GA21195@aepfle.de>
References: <1416327994-29619-1-git-send-email-olaf@aepfle.de>
	<21611.30074.302907.667308@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21611.30074.302907.667308@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: use more fixed strings to build 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, Nov 18, Ian Jackson wrote:

> How about
> 
>    It should be possible to repeatedly build identical sources
>    and get identical binaries, even on different hosts at different
>    build times.  This fails [etc. etc. ...]
> 
>    Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and XEN_BUILD_HOST
>    which the build environment can set to fixed strings to get a
>    reproducible build.
> 
> or some such.

Thanks. Do you want me to resend with this updated changelog, or will it
be used while applying?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 07:49:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 07: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 1Xr00n-0004IJ-2s; Wed, 19 Nov 2014 07:49:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr00m-0004IB-6h
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 07:49:12 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	95/AB-17958-77B4C645; Wed, 19 Nov 2014 07:49:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416383346!8623674!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17194 invoked from network); 19 Nov 2014 07:49:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 07:49:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="194295995"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 19 Nov 2014 02:49:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr00f-0000vt-Jh;
	Wed, 19 Nov 2014 07:49:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr00f-0003z5-Bh;
	Wed, 19 Nov 2014 07:49:05 +0000
Date: Wed, 19 Nov 2014 07:49:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31665-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31665: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31665 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31665/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                fc14f9c1272f62c3e8d01300f52467c0d9af50f9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
561 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 22279 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 Nov 19 07:49:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 07: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 1Xr00n-0004IJ-2s; Wed, 19 Nov 2014 07:49:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr00m-0004IB-6h
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 07:49:12 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	95/AB-17958-77B4C645; Wed, 19 Nov 2014 07:49:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416383346!8623674!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17194 invoked from network); 19 Nov 2014 07:49:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 07:49:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="194295995"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 19 Nov 2014 02:49:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr00f-0000vt-Jh;
	Wed, 19 Nov 2014 07:49:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr00f-0003z5-Bh;
	Wed, 19 Nov 2014 07:49:05 +0000
Date: Wed, 19 Nov 2014 07:49:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31665-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31665: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31665 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31665/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                fc14f9c1272f62c3e8d01300f52467c0d9af50f9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
561 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 22279 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 Nov 19 08:36:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 08:36:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr0js-0005Ka-UU; Wed, 19 Nov 2014 08:35:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1Xr0js-0005KV-9g
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 08:35:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	57/9B-09936-3665C645; Wed, 19 Nov 2014 08:35:47 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416386146!13822607!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1625 invoked from network); 19 Nov 2014 08:35:46 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-7.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 19 Nov 2014 08:35:46 -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 S996868AbaKSIff (ORCPT <rfc822;xen-devel@lists.xenproject.org>);
	Wed, 19 Nov 2014 09:35:35 +0100
Date: Wed, 19 Nov 2014 09:35:35 +0100
From: Daniel Kiper <dkiper@net-space.pl>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141119083535.GA321@router-fw-old.local.net-space.pl>
References: <5464827B0200007800047188@mail.emea.novell.com>
	<20141118180343.GA12891@router-fw-old.local.net-space.pl>
	<21611.36575.47438.496721@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21611.36575.47438.496721@mariner.uk.xensource.com>
User-Agent: Mutt/1.3.28i
Cc: Charles Arnold <carnold@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>, jbeulich@suse.com,
	Daniel Kiper <dkiper@net-space.pl>, Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Backport request for "tools/hotplug: set mtu from
	bridge for tap 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, Nov 18, 2014 at 06:24:31PM +0000, Ian Jackson wrote:
> Daniel Kiper writes ("Re: [Xen-devel] delaying 4.4.2 and 4.3.4"):
> > By the way, what I should do to have commit f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
> > (tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4.3?
> > I am asking about that more than five months. This patch fixes real bug.
>
> I don't seem to be able to find these mails from you but my mailbox is
> very big.  The normal thing ought to be for you to post a backport
> request and CC the stable tools maintainer (ie me).  I'm sorry if I
> dropped your message.
>
> The patch looks reasonable to backport.  I have put it on my list for
> backporting later.  I'll wait a bit to see if anyone objects.
> (I have also CC'd the patch's original author and also Ian C because
> he acked it for unstable.)
>
> Does it apply cleanly to 4.3 and 4.4?  I haven't checked.  Daniel, if
> you could check that, that would be helpful.  If it doesn't then the
> normal process would be for the backport requestor (ie you) to post
> the revised patch against 4.3 and/or 4.4.

4.4 and later have this patch. 4.3 and earlier ones do not have this patch.
It could be cherry picked to 4.3 and 4.2 without any issues.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 08:36:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 08:36:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr0js-0005Ka-UU; Wed, 19 Nov 2014 08:35:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1Xr0js-0005KV-9g
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 08:35:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	57/9B-09936-3665C645; Wed, 19 Nov 2014 08:35:47 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416386146!13822607!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1625 invoked from network); 19 Nov 2014 08:35:46 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-7.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 19 Nov 2014 08:35:46 -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 S996868AbaKSIff (ORCPT <rfc822;xen-devel@lists.xenproject.org>);
	Wed, 19 Nov 2014 09:35:35 +0100
Date: Wed, 19 Nov 2014 09:35:35 +0100
From: Daniel Kiper <dkiper@net-space.pl>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141119083535.GA321@router-fw-old.local.net-space.pl>
References: <5464827B0200007800047188@mail.emea.novell.com>
	<20141118180343.GA12891@router-fw-old.local.net-space.pl>
	<21611.36575.47438.496721@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21611.36575.47438.496721@mariner.uk.xensource.com>
User-Agent: Mutt/1.3.28i
Cc: Charles Arnold <carnold@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>, jbeulich@suse.com,
	Daniel Kiper <dkiper@net-space.pl>, Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Backport request for "tools/hotplug: set mtu from
	bridge for tap 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, Nov 18, 2014 at 06:24:31PM +0000, Ian Jackson wrote:
> Daniel Kiper writes ("Re: [Xen-devel] delaying 4.4.2 and 4.3.4"):
> > By the way, what I should do to have commit f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
> > (tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4.3?
> > I am asking about that more than five months. This patch fixes real bug.
>
> I don't seem to be able to find these mails from you but my mailbox is
> very big.  The normal thing ought to be for you to post a backport
> request and CC the stable tools maintainer (ie me).  I'm sorry if I
> dropped your message.
>
> The patch looks reasonable to backport.  I have put it on my list for
> backporting later.  I'll wait a bit to see if anyone objects.
> (I have also CC'd the patch's original author and also Ian C because
> he acked it for unstable.)
>
> Does it apply cleanly to 4.3 and 4.4?  I haven't checked.  Daniel, if
> you could check that, that would be helpful.  If it doesn't then the
> normal process would be for the backport requestor (ie you) to post
> the revised patch against 4.3 and/or 4.4.

4.4 and later have this patch. 4.3 and earlier ones do not have this patch.
It could be cherry picked to 4.3 and 4.2 without any issues.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:36:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:36:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1fp-00064L-Se; Wed, 19 Nov 2014 09:35:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr1fo-00064G-9K
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:35:40 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A7/08-09842-B646C645; Wed, 19 Nov 2014 09:35:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416389737!13839864!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31495 invoked from network); 19 Nov 2014 09:35:38 -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;
	19 Nov 2014 09:35:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="194317719"
Message-ID: <1416389735.29243.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>, <ian.jackson@eu.citrix.com>
Date: Wed, 19 Nov 2014 09:35:35 +0000
In-Reply-To: <1416381171-16772-1-git-send-email-cyliu@suse.com>
References: <1416381171-16772-1-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix restore: xenstore entries left when
	restore 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 15:12 +0800, Chunyan Liu wrote:
> While running libvirt-tck domain/102-broken-save-restore.t
> test (save domain, corrupt saved file by truncate the last 512k,
> then restore), found that restore domain failed, but domain
> related xenstore entries still exist in xenstore.
> 
> Add a patch to clear xenstore entries in this case.
> 
> Signed-off-by: Chunyan Liu <cyliu@suse.com>
> ---
>  tools/libxl/libxl.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..447840d 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1525,6 +1525,54 @@ static void devices_destroy_cb(libxl__egc *egc,
>                                 libxl__devices_remove_state *drs,
>                                 int rc);
>  
> +static void libxl_clear_xs_entry(libxl__gc *gc, uint32_t domid)

This seems to duplicate a bunch of stuff already done by
libxl__destroy_domid and libxl__devices_destroy etc. I think rather than
duplicating this libxl__destroy_domid should be made to Do The Right
Thing by trying to clean up any remnants of the domid even if it doesn't
currently exist.

Alternatively perhaps the real bug is in the error path of the restore
functionality, which isn't calling the correct unwind path. Ian, any
thoughts?

Ian.

> +    const char *dom_path, *vm_path;
> +    char *path;
> +    unsigned int num_kinds, num_dev_xsentries;
> +    char **kinds = NULL, **devs = NULL;
> +    int i, j;
> +
> +    /* remove libxl path */
> +    libxl__xs_rm_checked(gc, XBT_NULL, libxl__xs_libxl_path(gc, domid));
> +
> +    dom_path = libxl__xs_get_dompath(gc, domid);
> +    if (!dom_path)
> +        return;
> +
> +    /* remove backend entries */
> +    path = GCSPRINTF("%s/device", dom_path);
> +    kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds);
> +    if (kinds && num_kinds) {
> +        for (i = 0; i < num_kinds; i++) {
> +            path = GCSPRINTF("%s/device/%s", dom_path, kinds[i]);
> +            devs = libxl__xs_directory(gc, XBT_NULL, path, &num_dev_xsentries);
> +            if (!devs)
> +                continue;
> +            for (j = 0; j < num_dev_xsentries; j++) {
> +                path = GCSPRINTF("%s/device/%s/%s/backend",
> +                                 dom_path, kinds[i], devs[j]);
> +                path = libxl__xs_read(gc, XBT_NULL, path);
> +                if (path)
> +                    libxl__xs_rm_checked(gc, XBT_NULL, path);
> +            }
> +        }
> +    }
> +
> +    path = GCSPRINTF("%s/console/backend", dom_path);
> +    path = libxl__xs_read(gc, XBT_NULL, path);
> +    if (path)
> +        libxl__xs_rm_checked(gc, XBT_NULL, path);
> +
> +    /* remove vm path */
> +    vm_path = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/vm", dom_path));
> +    if (vm_path)
> +        libxl__xs_rm_checked(gc, XBT_NULL, vm_path);
> +
> +    /* remove dom path */
> +    libxl__xs_rm_checked(gc, XBT_NULL, dom_path);
> +}
> +
>  void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis)
>  {
>      STATE_AO_GC(dis->ao);
> @@ -1540,6 +1588,10 @@ void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis)
>          break;
>      case ERROR_INVAL:
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "non-existant domain %d", domid);
> +        /* domain may not started successfully but some xenstore entries
> +         * might be created already in earlier stage. We need to clear
> +         * those entries. */
> +        libxl_clear_xs_entry(gc, domid);
>      default:
>          goto out;
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:36:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:36:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1fp-00064L-Se; Wed, 19 Nov 2014 09:35:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr1fo-00064G-9K
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:35:40 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A7/08-09842-B646C645; Wed, 19 Nov 2014 09:35:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416389737!13839864!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31495 invoked from network); 19 Nov 2014 09:35:38 -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;
	19 Nov 2014 09:35:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="194317719"
Message-ID: <1416389735.29243.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>, <ian.jackson@eu.citrix.com>
Date: Wed, 19 Nov 2014 09:35:35 +0000
In-Reply-To: <1416381171-16772-1-git-send-email-cyliu@suse.com>
References: <1416381171-16772-1-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix restore: xenstore entries left when
	restore 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 15:12 +0800, Chunyan Liu wrote:
> While running libvirt-tck domain/102-broken-save-restore.t
> test (save domain, corrupt saved file by truncate the last 512k,
> then restore), found that restore domain failed, but domain
> related xenstore entries still exist in xenstore.
> 
> Add a patch to clear xenstore entries in this case.
> 
> Signed-off-by: Chunyan Liu <cyliu@suse.com>
> ---
>  tools/libxl/libxl.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..447840d 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1525,6 +1525,54 @@ static void devices_destroy_cb(libxl__egc *egc,
>                                 libxl__devices_remove_state *drs,
>                                 int rc);
>  
> +static void libxl_clear_xs_entry(libxl__gc *gc, uint32_t domid)

This seems to duplicate a bunch of stuff already done by
libxl__destroy_domid and libxl__devices_destroy etc. I think rather than
duplicating this libxl__destroy_domid should be made to Do The Right
Thing by trying to clean up any remnants of the domid even if it doesn't
currently exist.

Alternatively perhaps the real bug is in the error path of the restore
functionality, which isn't calling the correct unwind path. Ian, any
thoughts?

Ian.

> +    const char *dom_path, *vm_path;
> +    char *path;
> +    unsigned int num_kinds, num_dev_xsentries;
> +    char **kinds = NULL, **devs = NULL;
> +    int i, j;
> +
> +    /* remove libxl path */
> +    libxl__xs_rm_checked(gc, XBT_NULL, libxl__xs_libxl_path(gc, domid));
> +
> +    dom_path = libxl__xs_get_dompath(gc, domid);
> +    if (!dom_path)
> +        return;
> +
> +    /* remove backend entries */
> +    path = GCSPRINTF("%s/device", dom_path);
> +    kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds);
> +    if (kinds && num_kinds) {
> +        for (i = 0; i < num_kinds; i++) {
> +            path = GCSPRINTF("%s/device/%s", dom_path, kinds[i]);
> +            devs = libxl__xs_directory(gc, XBT_NULL, path, &num_dev_xsentries);
> +            if (!devs)
> +                continue;
> +            for (j = 0; j < num_dev_xsentries; j++) {
> +                path = GCSPRINTF("%s/device/%s/%s/backend",
> +                                 dom_path, kinds[i], devs[j]);
> +                path = libxl__xs_read(gc, XBT_NULL, path);
> +                if (path)
> +                    libxl__xs_rm_checked(gc, XBT_NULL, path);
> +            }
> +        }
> +    }
> +
> +    path = GCSPRINTF("%s/console/backend", dom_path);
> +    path = libxl__xs_read(gc, XBT_NULL, path);
> +    if (path)
> +        libxl__xs_rm_checked(gc, XBT_NULL, path);
> +
> +    /* remove vm path */
> +    vm_path = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/vm", dom_path));
> +    if (vm_path)
> +        libxl__xs_rm_checked(gc, XBT_NULL, vm_path);
> +
> +    /* remove dom path */
> +    libxl__xs_rm_checked(gc, XBT_NULL, dom_path);
> +}
> +
>  void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis)
>  {
>      STATE_AO_GC(dis->ao);
> @@ -1540,6 +1588,10 @@ void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis)
>          break;
>      case ERROR_INVAL:
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "non-existant domain %d", domid);
> +        /* domain may not started successfully but some xenstore entries
> +         * might be created already in earlier stage. We need to clear
> +         * those entries. */
> +        libxl_clear_xs_entry(gc, domid);
>      default:
>          goto out;
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:38:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:38:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1iW-0006AV-Gh; Wed, 19 Nov 2014 09:38:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr1iT-0006AO-VP
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:38:26 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F7/2E-17958-1156C645; Wed, 19 Nov 2014 09:38:25 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416389901!12394730!1
X-Originating-IP: [64.18.0.178]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25300 invoked from network); 19 Nov 2014 09:38:23 -0000
Received: from exprod5og104.obsmtp.com (HELO exprod5og104.obsmtp.com)
	(64.18.0.178)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 09:38:23 -0000
Received: from mail-qa0-f54.google.com ([209.85.216.54]) (using TLSv1) by
	exprod5ob104.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGxlDHF3aZMzitNS+tlVgTE9MpKQljnb@postini.com;
	Wed, 19 Nov 2014 01:38:23 PST
Received: by mail-qa0-f54.google.com with SMTP id i13so102223qae.41
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 01:38:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=n/QOnLTMAg5sEJp5D8icU1cEC+NWdgxzQIOzELHDLoQ=;
	b=Y0y146j6mPuZPATjIO4uL2rMHUFlRoNBcjH6pwRXZ4hXj2gztP1y5EPxYgkFo3x0nR
	r6UeeOqRPG7jm26srUbr4gM5Qz3WK3OmU/Wt2kFgTs/SkLWRX0HsTDBn+kZ/QPsEf5vD
	SEW1Cm/QdIu7dosvmT/rhuPDgdt5GLoNa2k9k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=n/QOnLTMAg5sEJp5D8icU1cEC+NWdgxzQIOzELHDLoQ=;
	b=cveCMiToN1WFiraNGz5xmrs28OWCFTq6O0vgI0sY/RRw2LGZtFYF2wkFnAKsyDYB29
	HPcWy3mmGBngJpB24W9y9XU7PMqqHTS3wqMMtVnSMqc4zTF4dVYPw0697IvEgGDOBnvq
	DMjE+jPgIjlfvkN6x05dZuoC/NKy+kG4zhIjxV9u1Plh2nZ0kLlt1dAIVNGCk2YDxIPM
	MIdskYKeH4ZmxhQsjesB71mvy5vfXc74AOGRVAw/YtFmyVQ3e2ezvqSFSw7doVR4IJn6
	9EU/ijcw313ifFcwvRbt/UweCdPFYxIt6R07N/1YeCcaHeCKW+vQ38x4K+Ea6YlCnNTI
	v2oA==
X-Gm-Message-State: ALoCoQm5PFrVpssOvoivXcENwu9ioremZ91/GMjrelQqguKLT+qhkQuOYXvOUUk/fD4mpvRQrdQoVgvgmnkWnos2SnpmBCNYpvsAXHRsDzgWTOwkmiEUm8w701mdSjrX9hqtALPUlI4VKGuX5teX5e93kAjAFdo8Kw==
X-Received: by 10.224.92.81 with SMTP id q17mr49679433qam.66.1416389900354;
	Wed, 19 Nov 2014 01:38:20 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.92.81 with SMTP id q17mr49679421qam.66.1416389900230;
	Wed, 19 Nov 2014 01:38:20 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 01:38:20 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 11:38:20 +0200
Message-ID: <CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

Thank you for your support.

You are right - with latest change you've proposed I got a continuous
prints during platform hang:

(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0

Looks line issue needs further deeper debugging.

Regards,
Andrii

On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> Hello Andrii,
> we are getting closer :-)
>
> It would help if you post the output with GIC_DEBUG defined but without
> the other change that "fixes" the issue.
>
> I think the problem is probably due to software irqs.
> You are getting too many
>
> gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
>
> messages. That means you are loosing virtual SGIs (guest VCPU to guest
> VCPU). It would be best to investigate why, especially if you get many
> more of the same messages without the MAINTENANCE_IRQ change I
> suggested.
>
> This patch might also help understading the problem more:
>
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index b7516c0..5eaeca2 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
>      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
>      {
>          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> -        if ( i >= nr_lrs ) return;
> +        if ( i >= nr_lrs )
> +        {
> +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> +                    p->irq, v->domain->domain_id, v->vcpu_id);
> +            continue;
> +        }
>
>          spin_lock_irqsave(&gic.lock, flags);
>          gic_set_lr(i, p, GICH_LR_PENDING);
>
>
>
>
> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> No hangs with this change.
>> Complete log is the following:
>>
>> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
>> DRA752 ES1.0
>> <ethaddr> not set. Validating first E-fuse MAC
>> cpsw
>> - UART enabled -
>> - CPU 00000000 booting -
>> - Xen starting in Hyp mode -
>> - Zero BSS -
>> - Setting up control registers -
>> - Turning on paging -
>> - Ready -
>> (XEN) Checking for initrd in /chosen
>> (XEN) RAM: 0000000080000000 - 000000009fffffff
>> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
>> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
>> (XEN)
>> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
>> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
>> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
>> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
>> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
>> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
>> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
>> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
>> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
>> (XEN)
>> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
>> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
>> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
>> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
>> (XEN) Dom heap: 344064 pages
>> (XEN) Domain heap initialised
>> (XEN) Looking for UART console serial0
>>  Xen 4.5-unstable
>> (XEN) Xen version 4.5-unstable (atseglytskyi@)
>> (arm-linux-gnueabihf-gcc (crosstool-NG
>> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
>> 20130328 (prerelease)) debu4
>> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
>> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
>> (XEN) 32-bit Execution:
>> (XEN)   Processor Features: 00001131:00011011
>> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
>> (XEN)     Extensions: GenericTimer Security
>> (XEN)   Debug Features: 02010555
>> (XEN)   Auxiliary Features: 00000000
>> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
>> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
>> (XEN) Platform: TI DRA7
>> (XEN) /psci method must be smc, but is: "hvc"
>> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
>> (XEN) Set AuxCoreBoot0 to 0x20
>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
>> (XEN) Using generic timer at 6144 KHz
>> (XEN) GIC initialization:
>> (XEN)         gic_dist_addr=0000000048211000
>> (XEN)         gic_cpu_addr=0000000048212000
>> (XEN)         gic_hyp_addr=0000000048214000
>> (XEN)         gic_vcpu_addr=0000000048216000
>> (XEN)         gic_maintenance_irq=25
>> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
>> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> (XEN) I/O virtualisation disabled
>> (XEN) Allocated console ring of 16 KiB.
>> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
>> (XEN) Bringing up CPU1
>> - CPU 00000001 booting -
>> - Xen starting in Hyp mode -
>> - Setting up control registers -
>> - Turning on paging -
>> - Ready -
>> (XEN) CPU 1 booted.
>> (XEN) Brought up 2 CPUs
>> (XEN) *** LOADING DOMAIN 0 ***
>> (XEN) Loading kernel from boot module 2
>> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
>> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
>> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
>> (XEN) Std. Loglevel: All
>> (XEN) Guest Loglevel: All
>> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
>> input to Xen)
>> (XEN) Freed 272kB init memory.
>> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> already pending in LR0
>> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> already pending in LR0
>> [    0.000000] /cpus/cpu@0 missing clock-frequency property
>> [    0.000000] /cpus/cpu@1 missing clock-frequency property
>> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
>> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
>> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
>> /ocp/i2c@48072000/camera_ov10635
>> [    0.437500] ldo3: operation not allowed
>> [    0.437500] omapdss HDMI error: can't set the voltage regulator
>> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
>> [    0.468750] ov1063x 1-0030: No deserializer node found
>> [    0.468750] ov1063x 1-0030: No serializer node found
>> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
>> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
>> [    0.578125] ahci ahci.0.auto: can't get clock
>> [    0.898437] ldc_module_init
>> [    1.304687] Missing dual_emac_res_vlan in DT.
>> [    1.304687] Using 1 as Reserved VLAN for 0 slave
>> [    1.312500] Missing dual_emac_res_vlan in DT.
>> [    1.320312] Using 2 as Reserved VLAN for 1 slave
>> [    1.382812] Freeing init memory: 236K
>> sh: write error: No such device
>> Cannot identify '/dev/camera0': 2, No such file or directory
>> Parsing config from /xen/images/DomUAndroid.cfg
>> XSM Disabled: seclabel not supported
>> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> dom1 access to irq 53: Function not implemented
>> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> dom1 access to irq 71: Function not implemented
>> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> dom1 access to irq 173: Function not implemented
>> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> dom1 access to irq 174: Function not implemented
>> Turning on vfb in domain 1
>> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> still lr_pending
>> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> still lr_pending
>> Parsing config from /xen/images/DomUQNX.cfg
>> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
>> inject irq=2 into d0v0, when it is still lr_pending
>>
>> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> still lr_pending
>> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
>> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
>> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
>> found: Invalid kernel
>> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
>> failed: No such file or directory
>> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
>> (re-)build domain: -3
>> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> still lr_pending
>> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> still lr_pending
>> Turning on 'vsnd' in domain '1' (dev_id: '0')
>> Turning on vkbd in domain 1
>> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> still lr_pending
>> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> still lr_pending
>> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> still lr_pending
>>
>> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
>> trying to inject irq=2 into d0v0, when it is still lr_pending
>>
>> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
>> <andrii.tseglytskyi@globallogic.com> wrote:
>> > OK got it. Give me a few mins
>> >
>> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
>> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
>> >> for non-hardware irqs (desc == NULL) and keep avoiding
>> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
>> >>
>> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
>> >> other potential bugs introduced later.
>> >>
>> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >>> What if I try on top of current master branch the following code:
>> >>>
>> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >>> index 31fb81a..6764ab7 100644
>> >>> --- a/xen/arch/arm/gic-v2.c
>> >>> +++ b/xen/arch/arm/gic-v2.c
>> >>> @@ -36,6 +36,8 @@
>> >>>  #include <asm/io.h>
>> >>>  #include <asm/gic.h>
>> >>>
>> >>> +#define GIC_DEBUG 1
>> >>> +
>> >>>  /*
>> >>>   * LR register definitions are GIC v2 specific.
>> >>>   * Moved these definitions from header file to here
>> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >>> index bcaded9..c03d6a6 100644
>> >>> --- a/xen/arch/arm/gic.c
>> >>> +++ b/xen/arch/arm/gic.c
>> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
>> >>>
>> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
>> >>> gic_hw_ops->info->nr_lrs) - 1))
>> >>>
>> >>> -#undef GIC_DEBUG
>> >>> +#define GIC_DEBUG 1
>> >>>
>> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
>> >>>
>> >>> It is equivalent to what you proposing - my code contains
>> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
>> >>> be executed:
>> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
>> >>>
>> >>> regards,
>> >>> Andrii
>> >>>
>> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
>> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>> >>> >> everything works fine
>> >>> >> The following 2 patches fixes xen/master for my platform.
>> >>> >>
>> >>> >> Stefano, could you please take a look to these changes?
>> >>> >>
>> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
>> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
>> >>> >>
>> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>> >>> >>
>> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >>> >>
>> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >>> >> index 31fb81a..093ecdb 100644
>> >>> >> --- a/xen/arch/arm/gic-v2.c
>> >>> >> +++ b/xen/arch/arm/gic-v2.c
>> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>> >>> >> pending_irq *p,
>> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
>> >>> >>
>> >>> >> -    if ( p->desc != NULL )
>> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >>> >>      {
>> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >>> >> -        else
>> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>> >>> >> GICH_V2_LR_PHYSICAL_MASK )
>> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >>> >> +    }
>> >>> >> +    else if ( p->desc != NULL )
>> >>> >> +    {
>> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>> >>> >>      }
>> >>> >>
>> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
>> >>> >
>> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
>> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
>> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
>> >>> > working correctly on OMAP5. This changes might only be better at
>> >>> > "hiding" the real issue.
>> >>> >
>> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
>> >>> > maintenance interrupts doesn't work for software interrupts.
>> >>> > The commit that should make them work correctly after the
>> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
>> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
>> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
>> >>> > Maybe that doesn't work correctly on OMAP5.
>> >>> >
>> >>> > Could you try this patch on top of
>> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
>> >>> > if the problem is specifically with software irqs.
>> >>> >
>> >>> >
>> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >>> > index b7516c0..d8a17c9 100644
>> >>> > --- a/xen/arch/arm/gic.c
>> >>> > +++ b/xen/arch/arm/gic.c
>> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>> >>> >  /* Maximum cpu interface per GIC */
>> >>> >  #define NR_GIC_CPU_IF 8
>> >>> >
>> >>> > -#undef GIC_DEBUG
>> >>> > +#define GIC_DEBUG 1
>> >>> >
>> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
>> >>> >
>> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>> >>> >      if ( p->desc != NULL )
>> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>> >>> > +    else
>> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>> >>> >
>> >>> >      GICH[GICH_LR + lr] = lr_val;
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> Andrii Tseglytskyi | Embedded Dev
>> >>> GlobalLogic
>> >>> www.globallogic.com
>> >>>
>> >
>> >
>> >
>> > --
>> >
>> > Andrii Tseglytskyi | Embedded Dev
>> > GlobalLogic
>> > www.globallogic.com
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:38:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:38:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1iW-0006AV-Gh; Wed, 19 Nov 2014 09:38:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr1iT-0006AO-VP
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:38:26 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F7/2E-17958-1156C645; Wed, 19 Nov 2014 09:38:25 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416389901!12394730!1
X-Originating-IP: [64.18.0.178]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25300 invoked from network); 19 Nov 2014 09:38:23 -0000
Received: from exprod5og104.obsmtp.com (HELO exprod5og104.obsmtp.com)
	(64.18.0.178)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 09:38:23 -0000
Received: from mail-qa0-f54.google.com ([209.85.216.54]) (using TLSv1) by
	exprod5ob104.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGxlDHF3aZMzitNS+tlVgTE9MpKQljnb@postini.com;
	Wed, 19 Nov 2014 01:38:23 PST
Received: by mail-qa0-f54.google.com with SMTP id i13so102223qae.41
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 01:38:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=n/QOnLTMAg5sEJp5D8icU1cEC+NWdgxzQIOzELHDLoQ=;
	b=Y0y146j6mPuZPATjIO4uL2rMHUFlRoNBcjH6pwRXZ4hXj2gztP1y5EPxYgkFo3x0nR
	r6UeeOqRPG7jm26srUbr4gM5Qz3WK3OmU/Wt2kFgTs/SkLWRX0HsTDBn+kZ/QPsEf5vD
	SEW1Cm/QdIu7dosvmT/rhuPDgdt5GLoNa2k9k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=n/QOnLTMAg5sEJp5D8icU1cEC+NWdgxzQIOzELHDLoQ=;
	b=cveCMiToN1WFiraNGz5xmrs28OWCFTq6O0vgI0sY/RRw2LGZtFYF2wkFnAKsyDYB29
	HPcWy3mmGBngJpB24W9y9XU7PMqqHTS3wqMMtVnSMqc4zTF4dVYPw0697IvEgGDOBnvq
	DMjE+jPgIjlfvkN6x05dZuoC/NKy+kG4zhIjxV9u1Plh2nZ0kLlt1dAIVNGCk2YDxIPM
	MIdskYKeH4ZmxhQsjesB71mvy5vfXc74AOGRVAw/YtFmyVQ3e2ezvqSFSw7doVR4IJn6
	9EU/ijcw313ifFcwvRbt/UweCdPFYxIt6R07N/1YeCcaHeCKW+vQ38x4K+Ea6YlCnNTI
	v2oA==
X-Gm-Message-State: ALoCoQm5PFrVpssOvoivXcENwu9ioremZ91/GMjrelQqguKLT+qhkQuOYXvOUUk/fD4mpvRQrdQoVgvgmnkWnos2SnpmBCNYpvsAXHRsDzgWTOwkmiEUm8w701mdSjrX9hqtALPUlI4VKGuX5teX5e93kAjAFdo8Kw==
X-Received: by 10.224.92.81 with SMTP id q17mr49679433qam.66.1416389900354;
	Wed, 19 Nov 2014 01:38:20 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.92.81 with SMTP id q17mr49679421qam.66.1416389900230;
	Wed, 19 Nov 2014 01:38:20 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 01:38:20 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<54662F69.8060700@linaro.org>
	<CAH_mUMP9AreyD9xL4my685zeEa3XQXpJHotY7pY58s8rNtm_EA@mail.gmail.com>
	<CAH_mUMPvvR7TxkddCuOvQ7v7vWvcF5N_hQH5+MHU_G-O_aHzoA@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 11:38:20 +0200
Message-ID: <CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

Thank you for your support.

You are right - with latest change you've proposed I got a continuous
prints during platform hang:

(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0

Looks line issue needs further deeper debugging.

Regards,
Andrii

On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> Hello Andrii,
> we are getting closer :-)
>
> It would help if you post the output with GIC_DEBUG defined but without
> the other change that "fixes" the issue.
>
> I think the problem is probably due to software irqs.
> You are getting too many
>
> gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
>
> messages. That means you are loosing virtual SGIs (guest VCPU to guest
> VCPU). It would be best to investigate why, especially if you get many
> more of the same messages without the MAINTENANCE_IRQ change I
> suggested.
>
> This patch might also help understading the problem more:
>
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index b7516c0..5eaeca2 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
>      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
>      {
>          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> -        if ( i >= nr_lrs ) return;
> +        if ( i >= nr_lrs )
> +        {
> +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> +                    p->irq, v->domain->domain_id, v->vcpu_id);
> +            continue;
> +        }
>
>          spin_lock_irqsave(&gic.lock, flags);
>          gic_set_lr(i, p, GICH_LR_PENDING);
>
>
>
>
> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> No hangs with this change.
>> Complete log is the following:
>>
>> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
>> DRA752 ES1.0
>> <ethaddr> not set. Validating first E-fuse MAC
>> cpsw
>> - UART enabled -
>> - CPU 00000000 booting -
>> - Xen starting in Hyp mode -
>> - Zero BSS -
>> - Setting up control registers -
>> - Turning on paging -
>> - Ready -
>> (XEN) Checking for initrd in /chosen
>> (XEN) RAM: 0000000080000000 - 000000009fffffff
>> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
>> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
>> (XEN)
>> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
>> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
>> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
>> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
>> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
>> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
>> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
>> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
>> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
>> (XEN)
>> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
>> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
>> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
>> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
>> (XEN) Dom heap: 344064 pages
>> (XEN) Domain heap initialised
>> (XEN) Looking for UART console serial0
>>  Xen 4.5-unstable
>> (XEN) Xen version 4.5-unstable (atseglytskyi@)
>> (arm-linux-gnueabihf-gcc (crosstool-NG
>> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
>> 20130328 (prerelease)) debu4
>> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
>> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
>> (XEN) 32-bit Execution:
>> (XEN)   Processor Features: 00001131:00011011
>> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
>> (XEN)     Extensions: GenericTimer Security
>> (XEN)   Debug Features: 02010555
>> (XEN)   Auxiliary Features: 00000000
>> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
>> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
>> (XEN) Platform: TI DRA7
>> (XEN) /psci method must be smc, but is: "hvc"
>> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
>> (XEN) Set AuxCoreBoot0 to 0x20
>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
>> (XEN) Using generic timer at 6144 KHz
>> (XEN) GIC initialization:
>> (XEN)         gic_dist_addr=0000000048211000
>> (XEN)         gic_cpu_addr=0000000048212000
>> (XEN)         gic_hyp_addr=0000000048214000
>> (XEN)         gic_vcpu_addr=0000000048216000
>> (XEN)         gic_maintenance_irq=25
>> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
>> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> (XEN) I/O virtualisation disabled
>> (XEN) Allocated console ring of 16 KiB.
>> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
>> (XEN) Bringing up CPU1
>> - CPU 00000001 booting -
>> - Xen starting in Hyp mode -
>> - Setting up control registers -
>> - Turning on paging -
>> - Ready -
>> (XEN) CPU 1 booted.
>> (XEN) Brought up 2 CPUs
>> (XEN) *** LOADING DOMAIN 0 ***
>> (XEN) Loading kernel from boot module 2
>> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
>> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
>> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
>> (XEN) Std. Loglevel: All
>> (XEN) Guest Loglevel: All
>> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
>> input to Xen)
>> (XEN) Freed 272kB init memory.
>> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> already pending in LR0
>> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> already pending in LR0
>> [    0.000000] /cpus/cpu@0 missing clock-frequency property
>> [    0.000000] /cpus/cpu@1 missing clock-frequency property
>> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
>> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
>> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
>> /ocp/i2c@48072000/camera_ov10635
>> [    0.437500] ldo3: operation not allowed
>> [    0.437500] omapdss HDMI error: can't set the voltage regulator
>> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
>> [    0.468750] ov1063x 1-0030: No deserializer node found
>> [    0.468750] ov1063x 1-0030: No serializer node found
>> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
>> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
>> [    0.578125] ahci ahci.0.auto: can't get clock
>> [    0.898437] ldc_module_init
>> [    1.304687] Missing dual_emac_res_vlan in DT.
>> [    1.304687] Using 1 as Reserved VLAN for 0 slave
>> [    1.312500] Missing dual_emac_res_vlan in DT.
>> [    1.320312] Using 2 as Reserved VLAN for 1 slave
>> [    1.382812] Freeing init memory: 236K
>> sh: write error: No such device
>> Cannot identify '/dev/camera0': 2, No such file or directory
>> Parsing config from /xen/images/DomUAndroid.cfg
>> XSM Disabled: seclabel not supported
>> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> dom1 access to irq 53: Function not implemented
>> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> dom1 access to irq 71: Function not implemented
>> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> dom1 access to irq 173: Function not implemented
>> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> dom1 access to irq 174: Function not implemented
>> Turning on vfb in domain 1
>> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> still lr_pending
>> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> still lr_pending
>> Parsing config from /xen/images/DomUQNX.cfg
>> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
>> inject irq=2 into d0v0, when it is still lr_pending
>>
>> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> still lr_pending
>> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
>> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
>> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
>> found: Invalid kernel
>> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
>> failed: No such file or directory
>> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
>> (re-)build domain: -3
>> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> still lr_pending
>> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> still lr_pending
>> Turning on 'vsnd' in domain '1' (dev_id: '0')
>> Turning on vkbd in domain 1
>> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> still lr_pending
>> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> still lr_pending
>> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> still lr_pending
>>
>> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
>> trying to inject irq=2 into d0v0, when it is still lr_pending
>>
>> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
>> <andrii.tseglytskyi@globallogic.com> wrote:
>> > OK got it. Give me a few mins
>> >
>> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
>> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
>> >> for non-hardware irqs (desc == NULL) and keep avoiding
>> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
>> >>
>> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
>> >> other potential bugs introduced later.
>> >>
>> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >>> What if I try on top of current master branch the following code:
>> >>>
>> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >>> index 31fb81a..6764ab7 100644
>> >>> --- a/xen/arch/arm/gic-v2.c
>> >>> +++ b/xen/arch/arm/gic-v2.c
>> >>> @@ -36,6 +36,8 @@
>> >>>  #include <asm/io.h>
>> >>>  #include <asm/gic.h>
>> >>>
>> >>> +#define GIC_DEBUG 1
>> >>> +
>> >>>  /*
>> >>>   * LR register definitions are GIC v2 specific.
>> >>>   * Moved these definitions from header file to here
>> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >>> index bcaded9..c03d6a6 100644
>> >>> --- a/xen/arch/arm/gic.c
>> >>> +++ b/xen/arch/arm/gic.c
>> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
>> >>>
>> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
>> >>> gic_hw_ops->info->nr_lrs) - 1))
>> >>>
>> >>> -#undef GIC_DEBUG
>> >>> +#define GIC_DEBUG 1
>> >>>
>> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
>> >>>
>> >>> It is equivalent to what you proposing - my code contains
>> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
>> >>> be executed:
>> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
>> >>>
>> >>> regards,
>> >>> Andrii
>> >>>
>> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
>> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>> >>> >> everything works fine
>> >>> >> The following 2 patches fixes xen/master for my platform.
>> >>> >>
>> >>> >> Stefano, could you please take a look to these changes?
>> >>> >>
>> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
>> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
>> >>> >>
>> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>> >>> >>
>> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >>> >>
>> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >>> >> index 31fb81a..093ecdb 100644
>> >>> >> --- a/xen/arch/arm/gic-v2.c
>> >>> >> +++ b/xen/arch/arm/gic-v2.c
>> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>> >>> >> pending_irq *p,
>> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
>> >>> >>
>> >>> >> -    if ( p->desc != NULL )
>> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >>> >>      {
>> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >>> >> -        else
>> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>> >>> >> GICH_V2_LR_PHYSICAL_MASK )
>> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >>> >> +    }
>> >>> >> +    else if ( p->desc != NULL )
>> >>> >> +    {
>> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>> >>> >>      }
>> >>> >>
>> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
>> >>> >
>> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
>> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
>> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
>> >>> > working correctly on OMAP5. This changes might only be better at
>> >>> > "hiding" the real issue.
>> >>> >
>> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
>> >>> > maintenance interrupts doesn't work for software interrupts.
>> >>> > The commit that should make them work correctly after the
>> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
>> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
>> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
>> >>> > Maybe that doesn't work correctly on OMAP5.
>> >>> >
>> >>> > Could you try this patch on top of
>> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
>> >>> > if the problem is specifically with software irqs.
>> >>> >
>> >>> >
>> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >>> > index b7516c0..d8a17c9 100644
>> >>> > --- a/xen/arch/arm/gic.c
>> >>> > +++ b/xen/arch/arm/gic.c
>> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>> >>> >  /* Maximum cpu interface per GIC */
>> >>> >  #define NR_GIC_CPU_IF 8
>> >>> >
>> >>> > -#undef GIC_DEBUG
>> >>> > +#define GIC_DEBUG 1
>> >>> >
>> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
>> >>> >
>> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>> >>> >      if ( p->desc != NULL )
>> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>> >>> > +    else
>> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>> >>> >
>> >>> >      GICH[GICH_LR + lr] = lr_val;
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> Andrii Tseglytskyi | Embedded Dev
>> >>> GlobalLogic
>> >>> www.globallogic.com
>> >>>
>> >
>> >
>> >
>> > --
>> >
>> > Andrii Tseglytskyi | Embedded Dev
>> > GlobalLogic
>> > www.globallogic.com
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:54:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1xz-0006Wb-LV; Wed, 19 Nov 2014 09:54:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xr1xx-0006WW-SQ
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:54:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BA/D3-09936-1D86C645; Wed, 19 Nov 2014 09:54:25 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416390862!13766381!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29654 invoked from network); 19 Nov 2014 09:54:23 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-6.tower-21.messagelabs.com with SMTP;
	19 Nov 2014 09:54:23 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 19 Nov 2014 00:12:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,415,1413270000"; d="scan'208";a="624730612"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by fmsmga001.fm.intel.com with ESMTP; 19 Nov 2014 00:18:53 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 19 Nov 2014 16:17:46 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Wed, 19 Nov 2014 16:17:44 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
	guest memory is out of reserved device memory maps
Thread-Index: AQHP/l8LtnOoOMCxBUyde78SnbhphJxnpV8g
Date: Wed, 19 Nov 2014 08:17:44 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FA1CD@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
In-Reply-To: <54633CF90200007800046B44@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, November 12, 2014 5:57 PM
> 
> >>> On 12.11.14 at 10:13, <tiejun.chen@intel.com> wrote:
> > On 2014/11/12 17:02, Jan Beulich wrote:
> >>>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
> >>>>> #2 flags field in each specific device of new domctl would control
> >>>>> whether this device need to check/reserve its own RMRR range. But its
> >>>>> not dependent on current device assignment domctl, so the user can
> use
> >>>>> them to control which devices need to work as hotplug later, separately.
> >>>>
> >>>> And this could be left as a second step, in order for what needs to
> >>>> be done now to not get more complicated that necessary.
> >>>>
> >>>
> >>> Do you mean currently we still rely on the device assignment domctl to
> >>> provide SBDF? So looks nothing should be changed in our policy.
> >>
> >> I can't connect your question to what I said. What I tried to tell you
> >
> > Something is misunderstanding to me.
> >
> >> was that I don't currently see a need to make this overly complicated:
> >> Having the option to punch holes for all devices and (by default)
> >> dealing with just the devices assigned at boot may be sufficient as a
> >> first step. Yet (repeating just to avoid any misunderstanding) that
> >> makes things easier only if we decide to require device assignment to
> >> happen before memory getting populated (since in that case there's
> >
> > Here what do you mean, 'if we decide to require device assignment to
> > happen before memory getting populated'?
> >
> > Because -quote-
> > "
> > In the present the device assignment is always after memory population.
> > And I also mentioned previously I double checked this sequence with printk.
> > "
> >
> > Or you already plan or deciede to change this sequence?
> 
> So it is now the 3rd time that I'm telling you that part of your
> decision making as to which route to follow should be to
> re-consider whether the current sequence of operations shouldn't
> be changed. Please also consult with the VT-d maintainers (hint to
> them: participating in this discussion publicly would be really nice)
> on _all_ decisions to be made here.
> 

there's no decision made privately. we hope all the discussions publicly.
will get back w/ our thoughts soon.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:54:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1y3-0006Wq-2H; Wed, 19 Nov 2014 09:54:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr1y2-0006Wi-AE
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:54:30 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F5/B3-08051-5D86C645; Wed, 19 Nov 2014 09:54:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416390867!12866747!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32472 invoked from network); 19 Nov 2014 09:54:28 -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;
	19 Nov 2014 09:54:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="194320989"
Message-ID: <1416390860.29243.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 19 Nov 2014 09:54:20 +0000
In-Reply-To: <546B7B02.6050104@linaro.org>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-1-git-send-email-ian.campbell@citrix.com>
	<546B7B02.6050104@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 1/4] xen: arm: Add earlyprintk for
	McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 16:59 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 11/18/2014 04:44 PM, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/Rules.mk |    6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> > index 572d854..ef887a5 100644
> > --- a/xen/arch/arm/Rules.mk
> > +++ b/xen/arch/arm/Rules.mk
> > @@ -95,6 +95,12 @@ EARLY_PRINTK_BAUD := 115200
> >  EARLY_UART_BASE_ADDRESS := 0x1c020000
> >  EARLY_UART_REG_SHIFT := 2
> >  endif
> > +ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
> > +EARLY_PRINTK_INC := 8250
> > +EARLY_PRINTK_BAUD := 9600
> 
> EARLY_PRINTK_BAUD is not necessary as we don't use the initialization
> function (EARLY_PRINTK_INIT_UART is not set).

Oh yes, oops. Also the baud is not even what is actually used, so it's
not even serving a documentary purpose.

> With the EARLY_PRINTK_BAUD dropped, this could be merged with the
> xgene-storm  early printk

It's at a different base address. Long term I either want to make this
(somewhat) runtime configurable or at least to rationalise the options
into the form <soc/soc-family>-uart<N>, or perhaps even <8250|pl011|
etc>@<address>[,<rate><settings>], if it's not to skanky to arrange to
parse that somewhere in the build system. Not for 4.5 though.

> (I didn't really understand why the baud rate
> is different).

Different hardware might potentially have different baud rates
configured in firmware which we would want to seemlessly follow, but
it's moot since the right thing to do in most cases is leave the
bootloader provided cfg alone.

> But I don't think it's 4.5 material.

You mean the patch generally or the merging?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:54:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1xz-0006Wb-LV; Wed, 19 Nov 2014 09:54:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xr1xx-0006WW-SQ
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:54:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BA/D3-09936-1D86C645; Wed, 19 Nov 2014 09:54:25 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416390862!13766381!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29654 invoked from network); 19 Nov 2014 09:54:23 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-6.tower-21.messagelabs.com with SMTP;
	19 Nov 2014 09:54:23 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 19 Nov 2014 00:12:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,415,1413270000"; d="scan'208";a="624730612"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by fmsmga001.fm.intel.com with ESMTP; 19 Nov 2014 00:18:53 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 19 Nov 2014 16:17:46 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Wed, 19 Nov 2014 16:17:44 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
	guest memory is out of reserved device memory maps
Thread-Index: AQHP/l8LtnOoOMCxBUyde78SnbhphJxnpV8g
Date: Wed, 19 Nov 2014 08:17:44 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FA1CD@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
In-Reply-To: <54633CF90200007800046B44@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, November 12, 2014 5:57 PM
> 
> >>> On 12.11.14 at 10:13, <tiejun.chen@intel.com> wrote:
> > On 2014/11/12 17:02, Jan Beulich wrote:
> >>>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
> >>>>> #2 flags field in each specific device of new domctl would control
> >>>>> whether this device need to check/reserve its own RMRR range. But its
> >>>>> not dependent on current device assignment domctl, so the user can
> use
> >>>>> them to control which devices need to work as hotplug later, separately.
> >>>>
> >>>> And this could be left as a second step, in order for what needs to
> >>>> be done now to not get more complicated that necessary.
> >>>>
> >>>
> >>> Do you mean currently we still rely on the device assignment domctl to
> >>> provide SBDF? So looks nothing should be changed in our policy.
> >>
> >> I can't connect your question to what I said. What I tried to tell you
> >
> > Something is misunderstanding to me.
> >
> >> was that I don't currently see a need to make this overly complicated:
> >> Having the option to punch holes for all devices and (by default)
> >> dealing with just the devices assigned at boot may be sufficient as a
> >> first step. Yet (repeating just to avoid any misunderstanding) that
> >> makes things easier only if we decide to require device assignment to
> >> happen before memory getting populated (since in that case there's
> >
> > Here what do you mean, 'if we decide to require device assignment to
> > happen before memory getting populated'?
> >
> > Because -quote-
> > "
> > In the present the device assignment is always after memory population.
> > And I also mentioned previously I double checked this sequence with printk.
> > "
> >
> > Or you already plan or deciede to change this sequence?
> 
> So it is now the 3rd time that I'm telling you that part of your
> decision making as to which route to follow should be to
> re-consider whether the current sequence of operations shouldn't
> be changed. Please also consult with the VT-d maintainers (hint to
> them: participating in this discussion publicly would be really nice)
> on _all_ decisions to be made here.
> 

there's no decision made privately. we hope all the discussions publicly.
will get back w/ our thoughts soon.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:54:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1y3-0006Wq-2H; Wed, 19 Nov 2014 09:54:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr1y2-0006Wi-AE
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:54:30 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F5/B3-08051-5D86C645; Wed, 19 Nov 2014 09:54:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416390867!12866747!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32472 invoked from network); 19 Nov 2014 09:54:28 -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;
	19 Nov 2014 09:54:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="194320989"
Message-ID: <1416390860.29243.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 19 Nov 2014 09:54:20 +0000
In-Reply-To: <546B7B02.6050104@linaro.org>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-1-git-send-email-ian.campbell@citrix.com>
	<546B7B02.6050104@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 1/4] xen: arm: Add earlyprintk for
	McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 16:59 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 11/18/2014 04:44 PM, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/Rules.mk |    6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> > index 572d854..ef887a5 100644
> > --- a/xen/arch/arm/Rules.mk
> > +++ b/xen/arch/arm/Rules.mk
> > @@ -95,6 +95,12 @@ EARLY_PRINTK_BAUD := 115200
> >  EARLY_UART_BASE_ADDRESS := 0x1c020000
> >  EARLY_UART_REG_SHIFT := 2
> >  endif
> > +ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
> > +EARLY_PRINTK_INC := 8250
> > +EARLY_PRINTK_BAUD := 9600
> 
> EARLY_PRINTK_BAUD is not necessary as we don't use the initialization
> function (EARLY_PRINTK_INIT_UART is not set).

Oh yes, oops. Also the baud is not even what is actually used, so it's
not even serving a documentary purpose.

> With the EARLY_PRINTK_BAUD dropped, this could be merged with the
> xgene-storm  early printk

It's at a different base address. Long term I either want to make this
(somewhat) runtime configurable or at least to rationalise the options
into the form <soc/soc-family>-uart<N>, or perhaps even <8250|pl011|
etc>@<address>[,<rate><settings>], if it's not to skanky to arrange to
parse that somewhere in the build system. Not for 4.5 though.

> (I didn't really understand why the baud rate
> is different).

Different hardware might potentially have different baud rates
configured in firmware which we would want to seemlessly follow, but
it's moot since the right thing to do in most cases is leave the
bootloader provided cfg alone.

> But I don't think it's 4.5 material.

You mean the patch generally or the merging?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:54:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1yO-0006aD-FA; Wed, 19 Nov 2014 09:54:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr1yN-0006a2-2X
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:54:51 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	18/7E-17735-AE86C645; Wed, 19 Nov 2014 09:54:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416390888!12313707!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20290 invoked from network); 19 Nov 2014 09:54:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 09:54:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="192805948"
Message-ID: <1416390886.29243.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 19 Nov 2014 09:54:46 +0000
In-Reply-To: <546B7B74.2090909@linaro.org>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
	<546B7B74.2090909@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/4] xen: arm: correct off by one in
 xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 17:01 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 11/18/2014 04:44 PM, Ian Campbell wrote:
> > The callers pass the end as the pfn immediately *after* the last page to be
> > mapped, therefore adding one is incorrect and causes an additional page to be
> > mapped.
> > 
> > At the same time correct the printing of the mfn values, zero-padding them to
> > 16 digits as for a paddr when they are frame numbers is just confusing.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/platforms/xgene-storm.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> > index 29c4752..38674cd 100644
> > --- a/xen/arch/arm/platforms/xgene-storm.c
> > +++ b/xen/arch/arm/platforms/xgene-storm.c
> > @@ -45,9 +45,9 @@ static int map_one_mmio(struct domain *d, const char *what,
> >  {
> >      int ret;
> >  
> > -    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
> > +    printk("Additional MMIO %lx-%lx (%s)\n",
> >             start, end, what);
> > -    ret = map_mmio_regions(d, start, end - start + 1, start);
> > +    ret = map_mmio_regions(d, start, end - start, start);
> >      if ( ret )
> >          printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
> >                 what, start, d->domain_id);
> 
> As you fixed the previous printf format. I would fix this one too.

Yes, good idea.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:54:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1yO-0006aD-FA; Wed, 19 Nov 2014 09:54:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr1yN-0006a2-2X
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:54:51 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	18/7E-17735-AE86C645; Wed, 19 Nov 2014 09:54:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416390888!12313707!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20290 invoked from network); 19 Nov 2014 09:54:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 09:54:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="192805948"
Message-ID: <1416390886.29243.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 19 Nov 2014 09:54:46 +0000
In-Reply-To: <546B7B74.2090909@linaro.org>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
	<546B7B74.2090909@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/4] xen: arm: correct off by one in
 xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 17:01 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 11/18/2014 04:44 PM, Ian Campbell wrote:
> > The callers pass the end as the pfn immediately *after* the last page to be
> > mapped, therefore adding one is incorrect and causes an additional page to be
> > mapped.
> > 
> > At the same time correct the printing of the mfn values, zero-padding them to
> > 16 digits as for a paddr when they are frame numbers is just confusing.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/platforms/xgene-storm.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> > index 29c4752..38674cd 100644
> > --- a/xen/arch/arm/platforms/xgene-storm.c
> > +++ b/xen/arch/arm/platforms/xgene-storm.c
> > @@ -45,9 +45,9 @@ static int map_one_mmio(struct domain *d, const char *what,
> >  {
> >      int ret;
> >  
> > -    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
> > +    printk("Additional MMIO %lx-%lx (%s)\n",
> >             start, end, what);
> > -    ret = map_mmio_regions(d, start, end - start + 1, start);
> > +    ret = map_mmio_regions(d, start, end - start, start);
> >      if ( ret )
> >          printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
> >                 what, start, d->domain_id);
> 
> As you fixed the previous printf format. I would fix this one too.

Yes, good idea.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:55:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:55:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1yl-0006dT-T7; Wed, 19 Nov 2014 09:55:15 +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 1Xr1yX-0006cb-Ce
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:55:14 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	A8/33-05632-4F86C645; Wed, 19 Nov 2014 09:55:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416390899!12411941!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21513 invoked from network); 19 Nov 2014 09:55:00 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 09:55:00 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xr1yC-0000pv-RW; Wed, 19 Nov 2014 09:54:40 +0000
Date: Wed, 19 Nov 2014 10:54:40 +0100
From: Tim Deegan <tim@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20141119095440.GA1409@deinos.phlegethon.org>
References: <20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li,
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
> Tim Deegan wrote on 2014-11-18:
> > In this case, the guest is entitled to _expect_ pagefaults on 1GB
> > mappings if CPUID claims they are not supported.  That sounds like an
> > unlikely thing for the guest to be relying on, but Xen itself does
> > something similar for the SHOPT_FAST_FAULT_PATH (and now also for
> > IOMMU entries for the deferred caching attribute updates).
> 
> Indeed. How about adding the software check (as Andrew mentioned)
> firstly and leave the hardware problem (Actually, I don't think we
> can solve it currently).

I don't think we should change the software path unless we can change
the hardware behaviour too.  It's better to be consistent, and it
saves us some cycles in the pt walker.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:55:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09:55:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr1yl-0006dT-T7; Wed, 19 Nov 2014 09:55:15 +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 1Xr1yX-0006cb-Ce
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:55:14 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	A8/33-05632-4F86C645; Wed, 19 Nov 2014 09:55:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416390899!12411941!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21513 invoked from network); 19 Nov 2014 09:55:00 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 09:55:00 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xr1yC-0000pv-RW; Wed, 19 Nov 2014 09:54:40 +0000
Date: Wed, 19 Nov 2014 10:54:40 +0100
From: Tim Deegan <tim@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20141119095440.GA1409@deinos.phlegethon.org>
References: <20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li,
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
	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

At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
> Tim Deegan wrote on 2014-11-18:
> > In this case, the guest is entitled to _expect_ pagefaults on 1GB
> > mappings if CPUID claims they are not supported.  That sounds like an
> > unlikely thing for the guest to be relying on, but Xen itself does
> > something similar for the SHOPT_FAST_FAULT_PATH (and now also for
> > IOMMU entries for the deferred caching attribute updates).
> 
> Indeed. How about adding the software check (as Andrew mentioned)
> firstly and leave the hardware problem (Actually, I don't think we
> can solve it currently).

I don't think we should change the software path unless we can change
the hardware behaviour too.  It's better to be consistent, and it
saves us some cycles in the pt walker.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:56:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09: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 1Xr1zu-0006rm-Cy; Wed, 19 Nov 2014 09:56: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 1Xr1zt-0006rR-Db
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:56:25 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B2/8A-31453-8496C645; Wed, 19 Nov 2014 09:56:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416390982!12178278!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18130 invoked from network); 19 Nov 2014 09:56:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 09:56:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="192806233"
Message-ID: <1416390980.29243.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 19 Nov 2014 09:56:20 +0000
In-Reply-To: <546B7E9E.9040806@linaro.org>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-4-git-send-email-ian.campbell@citrix.com>
	<546B7E9E.9040806@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4
 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 17:15 +0000, Julien Grall wrote:
> > +        default:
> > +            /* Ignore unknown PCI busses */
> 
> I would add a
> printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));
> 
> > +            ret = 0;
> > +            break;
> 
> continue?

Yes, that makes sense (probably the ret = is then unnecessary).

>  You can't assume the order of the PCI busses in the device tree.

But, I don't understand what this has to do with using continue.

> 
> > +        }
> > +
> > +        if ( ret < 0 )
> > +            return ret;
> > +
> > +        printk("Mapped additional regions for PCIe device at 0x%"PRIx64"\n",
> > +               addr);
> 
> Printing the device tree path would be more helpful than the address.

OK.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 09:56:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 09: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 1Xr1zu-0006rm-Cy; Wed, 19 Nov 2014 09:56: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 1Xr1zt-0006rR-Db
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 09:56:25 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B2/8A-31453-8496C645; Wed, 19 Nov 2014 09:56:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416390982!12178278!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18130 invoked from network); 19 Nov 2014 09:56:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 09:56:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="192806233"
Message-ID: <1416390980.29243.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 19 Nov 2014 09:56:20 +0000
In-Reply-To: <546B7E9E.9040806@linaro.org>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-4-git-send-email-ian.campbell@citrix.com>
	<546B7E9E.9040806@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4
 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 17:15 +0000, Julien Grall wrote:
> > +        default:
> > +            /* Ignore unknown PCI busses */
> 
> I would add a
> printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));
> 
> > +            ret = 0;
> > +            break;
> 
> continue?

Yes, that makes sense (probably the ret = is then unnecessary).

>  You can't assume the order of the PCI busses in the device tree.

But, I don't understand what this has to do with using continue.

> 
> > +        }
> > +
> > +        if ( ret < 0 )
> > +            return ret;
> > +
> > +        printk("Mapped additional regions for PCIe device at 0x%"PRIx64"\n",
> > +               addr);
> 
> Printing the device tree path would be more helpful than the address.

OK.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:03:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr26A-0007IJ-Cy; Wed, 19 Nov 2014 10:02:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr269-0007IE-2a
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:02:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8E/58-25276-CCA6C645; Wed, 19 Nov 2014 10:02:52 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416391371!13844606!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15220 invoked from network); 19 Nov 2014 10:02:51 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:02:51 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so1238029wid.0
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 02:02:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=JW4/esUDVRn48UaLf38lmhynbQXzIoVV3D0qxMgelhw=;
	b=hzcfEa10kqTTCYjc4IP6fG56PA4dlZT0f+bXT/z6q060DFs1127W+a0soIlKZcocjo
	Ica8ynlkiuEf2qSUl65lLfiVdIua2J99HnoOyVpH6bFlhVcWcdK0/ycryC38eCh82ZJW
	JW1SMhDtvBDHzL1tVOYciaw5/VtXjRofGoYGUHzvrvFgWAX2QFJu0UgZIz3edECy4hSl
	0QnNoGR/2uiSoiVMhInyGWnrfE+yD/EGWa8FBmnJvr8ZUJ8DHnifECIxgMp68thWN9qh
	PG4quQflAjJQzPbsosKtz43aK3nayQAmyszA2Hxp86LxRQi7MNt94Fd2vuPxTAAC6YQF
	vM1g==
X-Gm-Message-State: ALoCoQm0S6jJ4iBbPXFBMKHAiuK7pzQRS+uWb5fBpW1rhx3hYIDAlfmjUeAytVJVeyFThnnKq2EV
X-Received: by 10.180.107.1 with SMTP id gy1mr4075167wib.8.1416391371558;
	Wed, 19 Nov 2014 02:02:51 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id n4sm1499034wiz.17.2014.11.19.02.02.50
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 02:02:50 -0800 (PST)
Message-ID: <546C6AC9.7080908@linaro.org>
Date: Wed, 19 Nov 2014 10:02:49 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>	
	<1416329088-23328-1-git-send-email-ian.campbell@citrix.com>	
	<546B7B02.6050104@linaro.org>
	<1416390860.29243.10.camel@citrix.com>
In-Reply-To: <1416390860.29243.10.camel@citrix.com>
Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 1/4] xen: arm: Add earlyprintk for
	McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 19/11/2014 09:54, Ian Campbell wrote:
> On Tue, 2014-11-18 at 16:59 +0000, Julien Grall wrote:
>> Hi Ian,
>>
>> On 11/18/2014 04:44 PM, Ian Campbell wrote:
>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>>> ---
>>>   xen/arch/arm/Rules.mk |    6 ++++++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
>>> index 572d854..ef887a5 100644
>>> --- a/xen/arch/arm/Rules.mk
>>> +++ b/xen/arch/arm/Rules.mk
>>> @@ -95,6 +95,12 @@ EARLY_PRINTK_BAUD := 115200
>>>   EARLY_UART_BASE_ADDRESS := 0x1c020000
>>>   EARLY_UART_REG_SHIFT := 2
>>>   endif
>>> +ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
>>> +EARLY_PRINTK_INC := 8250
>>> +EARLY_PRINTK_BAUD := 9600
>>
>> EARLY_PRINTK_BAUD is not necessary as we don't use the initialization
>> function (EARLY_PRINTK_INIT_UART is not set).
>
> Oh yes, oops. Also the baud is not even what is actually used, so it's
> not even serving a documentary purpose.
>
>> With the EARLY_PRINTK_BAUD dropped, this could be merged with the
>> xgene-storm  early printk
>
> It's at a different base address. Long term I either want to make this
> (somewhat) runtime configurable or at least to rationalise the options
> into the form <soc/soc-family>-uart<N>, or perhaps even <8250|pl011|
> etc>@<address>[,<rate><settings>], if it's not to skanky to arrange to
> parse that somewhere in the build system. Not for 4.5 though.

> You mean the patch generally or the merging?

I meant rationalise the number of early printk. This patch looks fine 
for me.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:03:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr26A-0007IJ-Cy; Wed, 19 Nov 2014 10:02:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr269-0007IE-2a
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:02:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8E/58-25276-CCA6C645; Wed, 19 Nov 2014 10:02:52 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416391371!13844606!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15220 invoked from network); 19 Nov 2014 10:02:51 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:02:51 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so1238029wid.0
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 02:02:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=JW4/esUDVRn48UaLf38lmhynbQXzIoVV3D0qxMgelhw=;
	b=hzcfEa10kqTTCYjc4IP6fG56PA4dlZT0f+bXT/z6q060DFs1127W+a0soIlKZcocjo
	Ica8ynlkiuEf2qSUl65lLfiVdIua2J99HnoOyVpH6bFlhVcWcdK0/ycryC38eCh82ZJW
	JW1SMhDtvBDHzL1tVOYciaw5/VtXjRofGoYGUHzvrvFgWAX2QFJu0UgZIz3edECy4hSl
	0QnNoGR/2uiSoiVMhInyGWnrfE+yD/EGWa8FBmnJvr8ZUJ8DHnifECIxgMp68thWN9qh
	PG4quQflAjJQzPbsosKtz43aK3nayQAmyszA2Hxp86LxRQi7MNt94Fd2vuPxTAAC6YQF
	vM1g==
X-Gm-Message-State: ALoCoQm0S6jJ4iBbPXFBMKHAiuK7pzQRS+uWb5fBpW1rhx3hYIDAlfmjUeAytVJVeyFThnnKq2EV
X-Received: by 10.180.107.1 with SMTP id gy1mr4075167wib.8.1416391371558;
	Wed, 19 Nov 2014 02:02:51 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id n4sm1499034wiz.17.2014.11.19.02.02.50
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 02:02:50 -0800 (PST)
Message-ID: <546C6AC9.7080908@linaro.org>
Date: Wed, 19 Nov 2014 10:02:49 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>	
	<1416329088-23328-1-git-send-email-ian.campbell@citrix.com>	
	<546B7B02.6050104@linaro.org>
	<1416390860.29243.10.camel@citrix.com>
In-Reply-To: <1416390860.29243.10.camel@citrix.com>
Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 1/4] xen: arm: Add earlyprintk for
	McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 19/11/2014 09:54, Ian Campbell wrote:
> On Tue, 2014-11-18 at 16:59 +0000, Julien Grall wrote:
>> Hi Ian,
>>
>> On 11/18/2014 04:44 PM, Ian Campbell wrote:
>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>>> ---
>>>   xen/arch/arm/Rules.mk |    6 ++++++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
>>> index 572d854..ef887a5 100644
>>> --- a/xen/arch/arm/Rules.mk
>>> +++ b/xen/arch/arm/Rules.mk
>>> @@ -95,6 +95,12 @@ EARLY_PRINTK_BAUD := 115200
>>>   EARLY_UART_BASE_ADDRESS := 0x1c020000
>>>   EARLY_UART_REG_SHIFT := 2
>>>   endif
>>> +ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
>>> +EARLY_PRINTK_INC := 8250
>>> +EARLY_PRINTK_BAUD := 9600
>>
>> EARLY_PRINTK_BAUD is not necessary as we don't use the initialization
>> function (EARLY_PRINTK_INIT_UART is not set).
>
> Oh yes, oops. Also the baud is not even what is actually used, so it's
> not even serving a documentary purpose.
>
>> With the EARLY_PRINTK_BAUD dropped, this could be merged with the
>> xgene-storm  early printk
>
> It's at a different base address. Long term I either want to make this
> (somewhat) runtime configurable or at least to rationalise the options
> into the form <soc/soc-family>-uart<N>, or perhaps even <8250|pl011|
> etc>@<address>[,<rate><settings>], if it's not to skanky to arrange to
> parse that somewhere in the build system. Not for 4.5 though.

> You mean the patch generally or the merging?

I meant rationalise the number of early printk. This patch looks fine 
for me.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:06:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10: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.xen.org>)
	id 1Xr29K-0007Pq-2i; Wed, 19 Nov 2014 10: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 1Xr29I-0007Pd-1G
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 10:06:08 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	C9/19-19763-F8B6C645; Wed, 19 Nov 2014 10:06:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416391565!4615222!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25783 invoked from network); 19 Nov 2014 10:06:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:06:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="192809195"
Message-ID: <1416391555.29243.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <timwood@gwu.edu>
Date: Wed, 19 Nov 2014 10:05:55 +0000
In-Reply-To: <CAC8jeWMffRsnj0u4Ro_gBOV5ZsY+tS7hp-bZneE9NfgCRDR9iQ@mail.gmail.com>
References: <CABm+uF9cqpdqrjbwj3WUaeZXPZsNkCVHdL_=m4xh9MMxKQduUg@mail.gmail.com>
	<1416220487.27385.22.camel@citrix.com>
	<CAC8jeWMffRsnj0u4Ro_gBOV5ZsY+tS7hp-bZneE9NfgCRDR9iQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Xen devel list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] support for sharing huge pages with grant table?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 14:50 -0500, Timothy Wood wrote:
> On Mon, Nov 17, 2014 at 5:34 AM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
> 
>         On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wrote:
>         > Hi,
>         >
>         > I am curious if Xen currently supports sharing hugepages
>         between
>         > domains (specifically ones originally allocated in Dom-0 and
>         shared
>         > with a guest r/w).  I've seen some references to huge pages
>         in the
>         > archives of this list, but not in relation to the grant
>         mechanism.
>         
>         I don't think the grant table has any specific superpage
>         support. It
>         might be an interesting extension to consider though (for the
>         sorts of
>         reasons you would like it).
>         
>         You could grant a superpage using multiple 4K grants to cover
>         whichever
>         subset of the superpage you need to expose to the other end.
>         Now granted
>         (no pun intended ;-)) that might suck up 512 grefs in the
>         worst case,
>         which is a bit mad...
> 
> 
> If the grants just need to be setup once at system startup and then
> are never changed, is this likely to pose any particular problem
> (i.e., does the size of the grant table only affect things when new
> grants are being setup, or is it checked regularly at runtime)?

I think the main concern would be the amount of space used by the grant
table, rather than the frequency of access to it.

At 512 refs per superpage, each ref being 64-bits (for a v1 grant table,
lets ignore v2 for now) then we are talking about a page worth of grant
table for each such superpage mapping. I think the maximum grant table
size is 32 pages by default, although this can be increased on the Xen
command line, I'm not sure how far though.

>  
>         
>         > Also, can someone confirm that "superpages" are another term
>         for "huge
>         > pages" in Xen?
>         
>         Yes. Or at least I think so.
>         
>         > This would be helpful for some work we are doing on high
>         speed
>         > networking to VMs---DPDK stores packets into huge pages and
>         we'd like
>         > to get those to VMs as quickly as possible.
>         
>         This seems like a reasonable usecase to me. Having added this
>         to the
>         grant table interface I suppose you would also need to
>         consider
>         extensions to the individual PV I/O protocols (netif.h) to
>         allow them to
>         signal when a grant was huge. You might have issues with e.g.
>         finding
>         enough bits to represent the larger sizes...
> 
> 
> I hope you guys will think it is useful enough to someday implement
> it.. I've got a handful of undergrad and grad students who work with
> me, but this might be beyond our capabilities at this point ;)
> 
> 
> In our prior system, we did this on KVM.  In that case we used QEMU to
> define a virtual PCI device that mapped memory from the host OS and
> let it be accessed by a VM.  Any thoughts on whether the same approach
> would work with Xen?  I'd originally thought just using the grant
> table to enable sharing would make this a lot easier in Xen, but maybe
> not since it doesn't support huge pages.

That approach might work for an HVM guest, I'm not sure. It probably
won't work for a PV guest since they don't have emulated PCI devices
(only actual ones passed through).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:06:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10: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.xen.org>)
	id 1Xr29K-0007Pq-2i; Wed, 19 Nov 2014 10: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 1Xr29I-0007Pd-1G
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 10:06:08 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	C9/19-19763-F8B6C645; Wed, 19 Nov 2014 10:06:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416391565!4615222!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25783 invoked from network); 19 Nov 2014 10:06:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:06:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,415,1413244800"; d="scan'208";a="192809195"
Message-ID: <1416391555.29243.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <timwood@gwu.edu>
Date: Wed, 19 Nov 2014 10:05:55 +0000
In-Reply-To: <CAC8jeWMffRsnj0u4Ro_gBOV5ZsY+tS7hp-bZneE9NfgCRDR9iQ@mail.gmail.com>
References: <CABm+uF9cqpdqrjbwj3WUaeZXPZsNkCVHdL_=m4xh9MMxKQduUg@mail.gmail.com>
	<1416220487.27385.22.camel@citrix.com>
	<CAC8jeWMffRsnj0u4Ro_gBOV5ZsY+tS7hp-bZneE9NfgCRDR9iQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Xen devel list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] support for sharing huge pages with grant table?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 14:50 -0500, Timothy Wood wrote:
> On Mon, Nov 17, 2014 at 5:34 AM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
> 
>         On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wrote:
>         > Hi,
>         >
>         > I am curious if Xen currently supports sharing hugepages
>         between
>         > domains (specifically ones originally allocated in Dom-0 and
>         shared
>         > with a guest r/w).  I've seen some references to huge pages
>         in the
>         > archives of this list, but not in relation to the grant
>         mechanism.
>         
>         I don't think the grant table has any specific superpage
>         support. It
>         might be an interesting extension to consider though (for the
>         sorts of
>         reasons you would like it).
>         
>         You could grant a superpage using multiple 4K grants to cover
>         whichever
>         subset of the superpage you need to expose to the other end.
>         Now granted
>         (no pun intended ;-)) that might suck up 512 grefs in the
>         worst case,
>         which is a bit mad...
> 
> 
> If the grants just need to be setup once at system startup and then
> are never changed, is this likely to pose any particular problem
> (i.e., does the size of the grant table only affect things when new
> grants are being setup, or is it checked regularly at runtime)?

I think the main concern would be the amount of space used by the grant
table, rather than the frequency of access to it.

At 512 refs per superpage, each ref being 64-bits (for a v1 grant table,
lets ignore v2 for now) then we are talking about a page worth of grant
table for each such superpage mapping. I think the maximum grant table
size is 32 pages by default, although this can be increased on the Xen
command line, I'm not sure how far though.

>  
>         
>         > Also, can someone confirm that "superpages" are another term
>         for "huge
>         > pages" in Xen?
>         
>         Yes. Or at least I think so.
>         
>         > This would be helpful for some work we are doing on high
>         speed
>         > networking to VMs---DPDK stores packets into huge pages and
>         we'd like
>         > to get those to VMs as quickly as possible.
>         
>         This seems like a reasonable usecase to me. Having added this
>         to the
>         grant table interface I suppose you would also need to
>         consider
>         extensions to the individual PV I/O protocols (netif.h) to
>         allow them to
>         signal when a grant was huge. You might have issues with e.g.
>         finding
>         enough bits to represent the larger sizes...
> 
> 
> I hope you guys will think it is useful enough to someday implement
> it.. I've got a handful of undergrad and grad students who work with
> me, but this might be beyond our capabilities at this point ;)
> 
> 
> In our prior system, we did this on KVM.  In that case we used QEMU to
> define a virtual PCI device that mapped memory from the host OS and
> let it be accessed by a VM.  Any thoughts on whether the same approach
> would work with Xen?  I'd originally thought just using the grant
> table to enable sharing would make this a lot easier in Xen, but maybe
> not since it doesn't support huge pages.

That approach might work for an HVM guest, I'm not sure. It probably
won't work for a PV guest since they don't have emulated PCI devices
(only actual ones passed through).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:06:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr29g-0007T6-L4; Wed, 19 Nov 2014 10:06:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr29f-0007Sr-BW
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:06:31 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D5/B1-25276-6AB6C645; Wed, 19 Nov 2014 10:06:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416391590!13833721!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8549 invoked from network); 19 Nov 2014 10:06:30 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:06:30 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so4743453wid.15
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 02:06:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=6d5ShgDOPaPHMJjZ0KgzEyYTBQ+8OP8b0mF/Q0IYAV8=;
	b=LZ5JUL1Om0jU6NlUT0aPIjjVLo2RCuPgiZxN03c8N/Xpcwqjb+xW16kMoPStjiaCTd
	KE1V0qSr87RUJ0AoreUJ0IJxTut5ce+B78iIFSBgsbeGVNvo4axxnFFT5tel3yaY1NlE
	ab128f3ljK9sHH9fyFiiCOXQNxym1Q18g6r58s6lZMcoy2KyeQAuNKO+UBv4feZJf2Ne
	TEeFcJzns70g2wBr8SiuE11bq9MIsfRvpAdVASV6XXvm/EvqcH9dlBnbMJ3vJVXuPyE6
	cJN/uclmhjponFLswhSq1usXFt6p7UycVpf0EM35H9EbNHKYxoxnkNx0Ep3qXNprVwfS
	Cunw==
X-Gm-Message-State: ALoCoQlhUTqVbVLe/IbUgMppD2q/9mlpgzNQOlzuhXM3fKWUguV87EQW7sC5C7KbkYnZ1Sz2dOPu
X-Received: by 10.180.9.244 with SMTP id d20mr12077678wib.40.1416391589854;
	Wed, 19 Nov 2014 02:06:29 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id dr5sm1536753wib.4.2014.11.19.02.06.28
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 02:06:29 -0800 (PST)
Message-ID: <546C6BA3.1050202@linaro.org>
Date: Wed, 19 Nov 2014 10:06:27 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>	
	<1416329088-23328-4-git-send-email-ian.campbell@citrix.com>	
	<546B7E9E.9040806@linaro.org>
	<1416390980.29243.12.camel@citrix.com>
In-Reply-To: <1416390980.29243.12.camel@citrix.com>
Cc: Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4
 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Ian,

On 19/11/2014 09:56, Ian Campbell wrote:
> On Tue, 2014-11-18 at 17:15 +0000, Julien Grall wrote:
>>> +        default:
>>> +            /* Ignore unknown PCI busses */
>>
>> I would add a
>> printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));
>>
>>> +            ret = 0;
>>> +            break;
>>
>> continue?
>
> Yes, that makes sense (probably the ret = is then unnecessary).
>
>>   You can't assume the order of the PCI busses in the device tree.
>
> But, I don't understand what this has to do with using continue.

The current xgene-storm DTS has the different PCI busses ordered. So as 
soon as you don't find the PCI range, it means there is no more PCI busses.

Without the continue, this patch gives the impression that you rely on 
the node order on the device tree.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:06:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr29g-0007T6-L4; Wed, 19 Nov 2014 10:06:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr29f-0007Sr-BW
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:06:31 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D5/B1-25276-6AB6C645; Wed, 19 Nov 2014 10:06:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416391590!13833721!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8549 invoked from network); 19 Nov 2014 10:06:30 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:06:30 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so4743453wid.15
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 02:06:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=6d5ShgDOPaPHMJjZ0KgzEyYTBQ+8OP8b0mF/Q0IYAV8=;
	b=LZ5JUL1Om0jU6NlUT0aPIjjVLo2RCuPgiZxN03c8N/Xpcwqjb+xW16kMoPStjiaCTd
	KE1V0qSr87RUJ0AoreUJ0IJxTut5ce+B78iIFSBgsbeGVNvo4axxnFFT5tel3yaY1NlE
	ab128f3ljK9sHH9fyFiiCOXQNxym1Q18g6r58s6lZMcoy2KyeQAuNKO+UBv4feZJf2Ne
	TEeFcJzns70g2wBr8SiuE11bq9MIsfRvpAdVASV6XXvm/EvqcH9dlBnbMJ3vJVXuPyE6
	cJN/uclmhjponFLswhSq1usXFt6p7UycVpf0EM35H9EbNHKYxoxnkNx0Ep3qXNprVwfS
	Cunw==
X-Gm-Message-State: ALoCoQlhUTqVbVLe/IbUgMppD2q/9mlpgzNQOlzuhXM3fKWUguV87EQW7sC5C7KbkYnZ1Sz2dOPu
X-Received: by 10.180.9.244 with SMTP id d20mr12077678wib.40.1416391589854;
	Wed, 19 Nov 2014 02:06:29 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id dr5sm1536753wib.4.2014.11.19.02.06.28
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 02:06:29 -0800 (PST)
Message-ID: <546C6BA3.1050202@linaro.org>
Date: Wed, 19 Nov 2014 10:06:27 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>	
	<1416329088-23328-4-git-send-email-ian.campbell@citrix.com>	
	<546B7E9E.9040806@linaro.org>
	<1416390980.29243.12.camel@citrix.com>
In-Reply-To: <1416390980.29243.12.camel@citrix.com>
Cc: Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4
 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Ian,

On 19/11/2014 09:56, Ian Campbell wrote:
> On Tue, 2014-11-18 at 17:15 +0000, Julien Grall wrote:
>>> +        default:
>>> +            /* Ignore unknown PCI busses */
>>
>> I would add a
>> printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));
>>
>>> +            ret = 0;
>>> +            break;
>>
>> continue?
>
> Yes, that makes sense (probably the ret = is then unnecessary).
>
>>   You can't assume the order of the PCI busses in the device tree.
>
> But, I don't understand what this has to do with using continue.

The current xgene-storm DTS has the different PCI busses ordered. So as 
soon as you don't find the PCI range, it means there is no more PCI busses.

Without the continue, this patch gives the impression that you rely on 
the node order on the device tree.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:13:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:13:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2Fz-0007n3-5V; Wed, 19 Nov 2014 10:13:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2Fw-0007my-A0
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:13:00 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	16/F1-25276-B2D6C645; Wed, 19 Nov 2014 10:12:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416391977!13836019!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20309 invoked from network); 19 Nov 2014 10:12:59 -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;
	19 Nov 2014 10:12:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194326217"
Message-ID: <1416391975.29243.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 10:12:55 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
bunch of random sha id's in it, where the 4.4-testing version does not.

They seem to have replaced the various
        `= <boolean>`
        
        Default: `true`
        
Bits.

Andy, Any thoughts or should I investigate?

I don't see anything since 4.4 touching the html generation itself (we
added pandoc for pdf but didn't touch HTML afaict).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:13:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:13:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2Fz-0007n3-5V; Wed, 19 Nov 2014 10:13:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2Fw-0007my-A0
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:13:00 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	16/F1-25276-B2D6C645; Wed, 19 Nov 2014 10:12:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416391977!13836019!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20309 invoked from network); 19 Nov 2014 10:12:59 -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;
	19 Nov 2014 10:12:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194326217"
Message-ID: <1416391975.29243.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 10:12:55 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
bunch of random sha id's in it, where the 4.4-testing version does not.

They seem to have replaced the various
        `= <boolean>`
        
        Default: `true`
        
Bits.

Andy, Any thoughts or should I investigate?

I don't see anything since 4.4 touching the html generation itself (we
added pandoc for pdf but didn't touch HTML afaict).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:18:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:18:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2LB-0007vX-1D; Wed, 19 Nov 2014 10:18:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2L9-0007vS-5G
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:18:23 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	A2/73-27785-E6E6C645; Wed, 19 Nov 2014 10:18:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416392300!13464001!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8128 invoked from network); 19 Nov 2014 10:18:21 -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;
	19 Nov 2014 10:18:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194327940"
Message-ID: <1416392298.29243.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 19 Nov 2014 10:18:18 +0000
In-Reply-To: <546C6BA3.1050202@linaro.org>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-4-git-send-email-ian.campbell@citrix.com>
	<546B7E9E.9040806@linaro.org> <1416390980.29243.12.camel@citrix.com>
	<546C6BA3.1050202@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4
 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:06 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 19/11/2014 09:56, Ian Campbell wrote:
> > On Tue, 2014-11-18 at 17:15 +0000, Julien Grall wrote:
> >>> +        default:
> >>> +            /* Ignore unknown PCI busses */
> >>
> >> I would add a
> >> printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));
> >>
> >>> +            ret = 0;
> >>> +            break;
> >>
> >> continue?
> >
> > Yes, that makes sense (probably the ret = is then unnecessary).
> >
> >>   You can't assume the order of the PCI busses in the device tree.
> >
> > But, I don't understand what this has to do with using continue.
> 
> The current xgene-storm DTS has the different PCI busses ordered. So as 
> soon as you don't find the PCI range, it means there is no more PCI busses.

I don't think it does, the patch iterates over all of the buses, even
ones we don't understand, we don't give up at the first one we don't
grok.

> Without the continue, this patch gives the impression that you rely on 
> the node order on the device tree.



> 
> Regards,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:18:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:18:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2LB-0007vX-1D; Wed, 19 Nov 2014 10:18:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2L9-0007vS-5G
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:18:23 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	A2/73-27785-E6E6C645; Wed, 19 Nov 2014 10:18:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416392300!13464001!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8128 invoked from network); 19 Nov 2014 10:18:21 -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;
	19 Nov 2014 10:18:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194327940"
Message-ID: <1416392298.29243.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Wed, 19 Nov 2014 10:18:18 +0000
In-Reply-To: <546C6BA3.1050202@linaro.org>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-4-git-send-email-ian.campbell@citrix.com>
	<546B7E9E.9040806@linaro.org> <1416390980.29243.12.camel@citrix.com>
	<546C6BA3.1050202@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4
 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:06 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 19/11/2014 09:56, Ian Campbell wrote:
> > On Tue, 2014-11-18 at 17:15 +0000, Julien Grall wrote:
> >>> +        default:
> >>> +            /* Ignore unknown PCI busses */
> >>
> >> I would add a
> >> printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));
> >>
> >>> +            ret = 0;
> >>> +            break;
> >>
> >> continue?
> >
> > Yes, that makes sense (probably the ret = is then unnecessary).
> >
> >>   You can't assume the order of the PCI busses in the device tree.
> >
> > But, I don't understand what this has to do with using continue.
> 
> The current xgene-storm DTS has the different PCI busses ordered. So as 
> soon as you don't find the PCI range, it means there is no more PCI busses.

I don't think it does, the patch iterates over all of the buses, even
ones we don't understand, we don't give up at the first one we don't
grok.

> Without the continue, this patch gives the impression that you rely on 
> the node order on the device tree.



> 
> Regards,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:21:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2O1-00081f-Me; Wed, 19 Nov 2014 10:21:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2Nz-00081Y-Dc
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:21:19 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	6A/3B-02698-E1F6C645; Wed, 19 Nov 2014 10:21:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416392476!8809830!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31716 invoked from network); 19 Nov 2014 10:21:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:21:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192813261"
Message-ID: <1416392474.29243.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 10:21:14 +0000
In-Reply-To: <1416391975.29243.16.camel@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:12 +0000, Ian Campbell wrote:
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> bunch of random sha id's in it, where the 4.4-testing version does not.
> 
> They seem to have replaced the various
>         `= <boolean>`
>         
>         Default: `true`
>         
> Bits.
> 
> Andy, Any thoughts or should I investigate?
> 
> I don't see anything since 4.4 touching the html generation itself (we
> added pandoc for pdf but didn't touch HTML afaict).

FWIW it seems to happen from the conring_size entry onwards, The
"com1,com2" and earlier are OK. I can't see anything about thecom1,com2
entry which would be causing this...

> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:21:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2O1-00081f-Me; Wed, 19 Nov 2014 10:21:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2Nz-00081Y-Dc
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:21:19 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	6A/3B-02698-E1F6C645; Wed, 19 Nov 2014 10:21:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416392476!8809830!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31716 invoked from network); 19 Nov 2014 10:21:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:21:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192813261"
Message-ID: <1416392474.29243.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 10:21:14 +0000
In-Reply-To: <1416391975.29243.16.camel@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:12 +0000, Ian Campbell wrote:
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> bunch of random sha id's in it, where the 4.4-testing version does not.
> 
> They seem to have replaced the various
>         `= <boolean>`
>         
>         Default: `true`
>         
> Bits.
> 
> Andy, Any thoughts or should I investigate?
> 
> I don't see anything since 4.4 touching the html generation itself (we
> added pandoc for pdf but didn't touch HTML afaict).

FWIW it seems to happen from the conring_size entry onwards, The
"com1,com2" and earlier are OK. I can't see anything about thecom1,com2
entry which would be causing this...

> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:24:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:24:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2RN-0008Ey-D9; Wed, 19 Nov 2014 10:24:49 +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 1Xr2RL-0008Et-QK
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:24:47 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	AE/D4-19763-EEF6C645; Wed, 19 Nov 2014 10:24:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416392684!12186904!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3397 invoked from network); 19 Nov 2014 10:24:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:24:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192813980"
Message-ID: <546C6FEB.8010308@citrix.com>
Date: Wed, 19 Nov 2014 10:24:43 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
References: <1416391975.29243.16.camel@citrix.com>
In-Reply-To: <1416391975.29243.16.camel@citrix.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/14 10:12, Ian Campbell wrote:
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> bunch of random sha id's in it, where the 4.4-testing version does not.
>
> They seem to have replaced the various
>         `= <boolean>`
>         
>         Default: `true`
>         
> Bits.
>
> Andy, Any thoughts or should I investigate?
>
> I don't see anything since 4.4 touching the html generation itself (we
> added pandoc for pdf but didn't touch HTML afaict).
>
> Ian.
>

I have looked into it before but didn't get very far.  I suspect it
might be a bug in wheezy's markdown.  It doesn't reproduce when building
using other versions of markdown.

I had planned (given some non-existent free time) to see about
converting it from markdown to pandoc which has leads to a far more
nicely formatted document.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:24:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:24:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2RN-0008Ey-D9; Wed, 19 Nov 2014 10:24:49 +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 1Xr2RL-0008Et-QK
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:24:47 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	AE/D4-19763-EEF6C645; Wed, 19 Nov 2014 10:24:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416392684!12186904!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3397 invoked from network); 19 Nov 2014 10:24:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:24:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192813980"
Message-ID: <546C6FEB.8010308@citrix.com>
Date: Wed, 19 Nov 2014 10:24:43 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
References: <1416391975.29243.16.camel@citrix.com>
In-Reply-To: <1416391975.29243.16.camel@citrix.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/14 10:12, Ian Campbell wrote:
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> bunch of random sha id's in it, where the 4.4-testing version does not.
>
> They seem to have replaced the various
>         `= <boolean>`
>         
>         Default: `true`
>         
> Bits.
>
> Andy, Any thoughts or should I investigate?
>
> I don't see anything since 4.4 touching the html generation itself (we
> added pandoc for pdf but didn't touch HTML afaict).
>
> Ian.
>

I have looked into it before but didn't get very far.  I suspect it
might be a bug in wheezy's markdown.  It doesn't reproduce when building
using other versions of markdown.

I had planned (given some non-existent free time) to see about
converting it from markdown to pandoc which has leads to a far more
nicely formatted document.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:30:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2Wo-0008Py-Dg; Wed, 19 Nov 2014 10:30:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr2Wn-0008Pt-1K
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:30:25 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D4/69-02696-F317C645; Wed, 19 Nov 2014 10:30:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416393023!13468288!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14834 invoked from network); 19 Nov 2014 10:30:23 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:30:23 -0000
Received: by mail-wg0-f46.google.com with SMTP id x12so416417wgg.33
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 02:30:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=EipfXop1RJAuvJGFZ5NmyicizMXVtEH1l93sIHMkEkc=;
	b=XLD5MpmG6gWm73Zk6JMKmpPR6ThXh0+eFlvl6X/5r6+fS1/MZkq45RlwLhvPhn3ZwJ
	5GOj/I+nqfjbpNDDLa5n2mKi1XpEtWDBykCjJN+PQYdcatzLknoNUr9wMmWsGpRw0THH
	IZCKTiqw69qtqnvsCBzYP3r+dzJodC5tWIJupRm2Kyp0f7QXL0bNUZela0UmfWQHXNoP
	Q/sZ0vSz63TIVz99ApcqWlawDI3xFloR0CEjGvtG1AnvJU4TpsjU0gH5g1wEVJM1ecvd
	WLFmg9+9ojCOqQmmdOs0JBhvJAuzeRh9Ma4wubxxgR9O79RgKfcSj4C+2ZYVUHvsjL4u
	ABHw==
X-Gm-Message-State: ALoCoQlsdYNL24BOj2o/Psx0BUHQM15cBMhsCR7+c4PsDdzHxEKh3mmdtadiauOvdqa01oY2o/dM
X-Received: by 10.180.9.196 with SMTP id c4mr4297028wib.66.1416393022942;
	Wed, 19 Nov 2014 02:30:22 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id bj7sm1662496wjc.33.2014.11.19.02.30.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 02:30:22 -0800 (PST)
Message-ID: <546C713C.9030506@linaro.org>
Date: Wed, 19 Nov 2014 10:30:20 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>		
	<1416329088-23328-4-git-send-email-ian.campbell@citrix.com>		
	<546B7E9E.9040806@linaro.org>
	<1416390980.29243.12.camel@citrix.com>	
	<546C6BA3.1050202@linaro.org>
	<1416392298.29243.18.camel@citrix.com>
In-Reply-To: <1416392298.29243.18.camel@citrix.com>
Cc: Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4
 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 19/11/2014 10:18, Ian Campbell wrote:
> On Wed, 2014-11-19 at 10:06 +0000, Julien Grall wrote:
>> Hi Ian,
>>
>> On 19/11/2014 09:56, Ian Campbell wrote:
>>> On Tue, 2014-11-18 at 17:15 +0000, Julien Grall wrote:
>>>>> +        default:
>>>>> +            /* Ignore unknown PCI busses */
>>>>
>>>> I would add a
>>>> printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));
>>>>
>>>>> +            ret = 0;
>>>>> +            break;
>>>>
>>>> continue?
>>>
>>> Yes, that makes sense (probably the ret = is then unnecessary).
>>>
>>>>    You can't assume the order of the PCI busses in the device tree.
>>>
>>> But, I don't understand what this has to do with using continue.
>>
>> The current xgene-storm DTS has the different PCI busses ordered. So as
>> soon as you don't find the PCI range, it means there is no more PCI busses.
>
> I don't think it does, the patch iterates over all of the buses, even
> ones we don't understand, we don't give up at the first one we don't
> grok.

Hrmm you are right. I don't know why I though the break were bound to 
the loop and not the switch.

Sorry for the noise.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:30:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2Ws-0008QJ-Pe; Wed, 19 Nov 2014 10:30:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2Wr-0008Q9-Dv
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:30:29 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	63/1C-02699-4417C645; Wed, 19 Nov 2014 10:30:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416393026!8028340!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4631 invoked from network); 19 Nov 2014 10:30:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:30:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194330103"
Message-ID: <1416393024.29243.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 19 Nov 2014 10:30:24 +0000
In-Reply-To: <546C6FEB.8010308@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:24 +0000, Andrew Cooper wrote:
> On 19/11/14 10:12, Ian Campbell wrote:
> > http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> > bunch of random sha id's in it, where the 4.4-testing version does not.
> >
> > They seem to have replaced the various
> >         `= <boolean>`
> >         
> >         Default: `true`
> >         
> > Bits.
> >
> > Andy, Any thoughts or should I investigate?
> >
> > I don't see anything since 4.4 touching the html generation itself (we
> > added pandoc for pdf but didn't touch HTML afaict).
> >
> > Ian.
> >
> 
> I have looked into it before but didn't get very far.  I suspect it
> might be a bug in wheezy's markdown.  It doesn't reproduce when building
> using other versions of markdown.

Right.

It seems to be triggered by the line:
  `S` is an integer 1 or 2 for the number of stop bits.
just removing that makes the issue go away. It's not the `s since
removing just those retains the issue. WTAF!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:30:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2Wo-0008Py-Dg; Wed, 19 Nov 2014 10:30:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr2Wn-0008Pt-1K
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:30:25 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D4/69-02696-F317C645; Wed, 19 Nov 2014 10:30:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416393023!13468288!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14834 invoked from network); 19 Nov 2014 10:30:23 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:30:23 -0000
Received: by mail-wg0-f46.google.com with SMTP id x12so416417wgg.33
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 02:30:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=EipfXop1RJAuvJGFZ5NmyicizMXVtEH1l93sIHMkEkc=;
	b=XLD5MpmG6gWm73Zk6JMKmpPR6ThXh0+eFlvl6X/5r6+fS1/MZkq45RlwLhvPhn3ZwJ
	5GOj/I+nqfjbpNDDLa5n2mKi1XpEtWDBykCjJN+PQYdcatzLknoNUr9wMmWsGpRw0THH
	IZCKTiqw69qtqnvsCBzYP3r+dzJodC5tWIJupRm2Kyp0f7QXL0bNUZela0UmfWQHXNoP
	Q/sZ0vSz63TIVz99ApcqWlawDI3xFloR0CEjGvtG1AnvJU4TpsjU0gH5g1wEVJM1ecvd
	WLFmg9+9ojCOqQmmdOs0JBhvJAuzeRh9Ma4wubxxgR9O79RgKfcSj4C+2ZYVUHvsjL4u
	ABHw==
X-Gm-Message-State: ALoCoQlsdYNL24BOj2o/Psx0BUHQM15cBMhsCR7+c4PsDdzHxEKh3mmdtadiauOvdqa01oY2o/dM
X-Received: by 10.180.9.196 with SMTP id c4mr4297028wib.66.1416393022942;
	Wed, 19 Nov 2014 02:30:22 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id bj7sm1662496wjc.33.2014.11.19.02.30.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 02:30:22 -0800 (PST)
Message-ID: <546C713C.9030506@linaro.org>
Date: Wed, 19 Nov 2014 10:30:20 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416329045.17982.27.camel@citrix.com>		
	<1416329088-23328-4-git-send-email-ian.campbell@citrix.com>		
	<546B7E9E.9040806@linaro.org>
	<1416390980.29243.12.camel@citrix.com>	
	<546C6BA3.1050202@linaro.org>
	<1416392298.29243.18.camel@citrix.com>
In-Reply-To: <1416392298.29243.18.camel@citrix.com>
Cc: Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4
 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 19/11/2014 10:18, Ian Campbell wrote:
> On Wed, 2014-11-19 at 10:06 +0000, Julien Grall wrote:
>> Hi Ian,
>>
>> On 19/11/2014 09:56, Ian Campbell wrote:
>>> On Tue, 2014-11-18 at 17:15 +0000, Julien Grall wrote:
>>>>> +        default:
>>>>> +            /* Ignore unknown PCI busses */
>>>>
>>>> I would add a
>>>> printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));
>>>>
>>>>> +            ret = 0;
>>>>> +            break;
>>>>
>>>> continue?
>>>
>>> Yes, that makes sense (probably the ret = is then unnecessary).
>>>
>>>>    You can't assume the order of the PCI busses in the device tree.
>>>
>>> But, I don't understand what this has to do with using continue.
>>
>> The current xgene-storm DTS has the different PCI busses ordered. So as
>> soon as you don't find the PCI range, it means there is no more PCI busses.
>
> I don't think it does, the patch iterates over all of the buses, even
> ones we don't understand, we don't give up at the first one we don't
> grok.

Hrmm you are right. I don't know why I though the break were bound to 
the loop and not the switch.

Sorry for the noise.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:30:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2Ws-0008QJ-Pe; Wed, 19 Nov 2014 10:30:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2Wr-0008Q9-Dv
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:30:29 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	63/1C-02699-4417C645; Wed, 19 Nov 2014 10:30:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416393026!8028340!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4631 invoked from network); 19 Nov 2014 10:30:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:30:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194330103"
Message-ID: <1416393024.29243.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 19 Nov 2014 10:30:24 +0000
In-Reply-To: <546C6FEB.8010308@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:24 +0000, Andrew Cooper wrote:
> On 19/11/14 10:12, Ian Campbell wrote:
> > http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> > bunch of random sha id's in it, where the 4.4-testing version does not.
> >
> > They seem to have replaced the various
> >         `= <boolean>`
> >         
> >         Default: `true`
> >         
> > Bits.
> >
> > Andy, Any thoughts or should I investigate?
> >
> > I don't see anything since 4.4 touching the html generation itself (we
> > added pandoc for pdf but didn't touch HTML afaict).
> >
> > Ian.
> >
> 
> I have looked into it before but didn't get very far.  I suspect it
> might be a bug in wheezy's markdown.  It doesn't reproduce when building
> using other versions of markdown.

Right.

It seems to be triggered by the line:
  `S` is an integer 1 or 2 for the number of stop bits.
just removing that makes the issue go away. It's not the `s since
removing just those retains the issue. WTAF!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:38:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2dy-0000Jf-T9; Wed, 19 Nov 2014 10:37:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xr2dx-0000Ja-Sk
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:37:49 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	D1/4F-03145-DF27C645; Wed, 19 Nov 2014 10:37:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416393467!13442014!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7216 invoked from network); 19 Nov 2014 10:37:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:37:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192816514"
Message-ID: <546C72F8.2020704@citrix.com>
Date: Wed, 19 Nov 2014 10:37:44 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>	
	<546C6FEB.8010308@citrix.com>
	<1416393024.29243.20.camel@citrix.com>
In-Reply-To: <1416393024.29243.20.camel@citrix.com>
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/14 10:30, Ian Campbell wrote:
> On Wed, 2014-11-19 at 10:24 +0000, Andrew Cooper wrote:
>> On 19/11/14 10:12, Ian Campbell wrote:
>>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
>>> bunch of random sha id's in it, where the 4.4-testing version does not.
>>>
>>> They seem to have replaced the various
>>>         `= <boolean>`
>>>         
>>>         Default: `true`
>>>         
>>> Bits.
>>>
>>> Andy, Any thoughts or should I investigate?
>>>
>>> I don't see anything since 4.4 touching the html generation itself (we
>>> added pandoc for pdf but didn't touch HTML afaict).
>>>
>>> Ian.
>>>
>> I have looked into it before but didn't get very far.  I suspect it
>> might be a bug in wheezy's markdown.  It doesn't reproduce when building
>> using other versions of markdown.
> Right.
>
> It seems to be triggered by the line:
>   `S` is an integer 1 or 2 for the number of stop bits.
> just removing that makes the issue go away. It's not the `s since
> removing just those retains the issue. WTAF!
>
> Ian.
>

So it does.  As best as I can tell, that is all legal mardown for a
nested block.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:38:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2dy-0000Jf-T9; Wed, 19 Nov 2014 10:37:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xr2dx-0000Ja-Sk
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:37:49 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	D1/4F-03145-DF27C645; Wed, 19 Nov 2014 10:37:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416393467!13442014!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7216 invoked from network); 19 Nov 2014 10:37:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:37:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192816514"
Message-ID: <546C72F8.2020704@citrix.com>
Date: Wed, 19 Nov 2014 10:37:44 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>	
	<546C6FEB.8010308@citrix.com>
	<1416393024.29243.20.camel@citrix.com>
In-Reply-To: <1416393024.29243.20.camel@citrix.com>
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/14 10:30, Ian Campbell wrote:
> On Wed, 2014-11-19 at 10:24 +0000, Andrew Cooper wrote:
>> On 19/11/14 10:12, Ian Campbell wrote:
>>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
>>> bunch of random sha id's in it, where the 4.4-testing version does not.
>>>
>>> They seem to have replaced the various
>>>         `= <boolean>`
>>>         
>>>         Default: `true`
>>>         
>>> Bits.
>>>
>>> Andy, Any thoughts or should I investigate?
>>>
>>> I don't see anything since 4.4 touching the html generation itself (we
>>> added pandoc for pdf but didn't touch HTML afaict).
>>>
>>> Ian.
>>>
>> I have looked into it before but didn't get very far.  I suspect it
>> might be a bug in wheezy's markdown.  It doesn't reproduce when building
>> using other versions of markdown.
> Right.
>
> It seems to be triggered by the line:
>   `S` is an integer 1 or 2 for the number of stop bits.
> just removing that makes the issue go away. It's not the `s since
> removing just those retains the issue. WTAF!
>
> Ian.
>

So it does.  As best as I can tell, that is all legal mardown for a
nested block.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:39:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2fQ-0000Op-DF; Wed, 19 Nov 2014 10:39:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2fO-0000Oh-KA
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:39:18 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	30/B4-19763-5537C645; Wed, 19 Nov 2014 10:39:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416393555!12200245!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32764 invoked from network); 19 Nov 2014 10:39:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:39:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194331812"
Message-ID: <1416393524.29243.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 19 Nov 2014 10:38:44 +0000
In-Reply-To: <546C72F8.2020704@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com> <1416393024.29243.20.camel@citrix.com>
	<546C72F8.2020704@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:37 +0000, Andrew Cooper wrote:
> On 19/11/14 10:30, Ian Campbell wrote:
> > On Wed, 2014-11-19 at 10:24 +0000, Andrew Cooper wrote:
> >> On 19/11/14 10:12, Ian Campbell wrote:
> >>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> >>> bunch of random sha id's in it, where the 4.4-testing version does not.
> >>>
> >>> They seem to have replaced the various
> >>>         `= <boolean>`
> >>>         
> >>>         Default: `true`
> >>>         
> >>> Bits.
> >>>
> >>> Andy, Any thoughts or should I investigate?
> >>>
> >>> I don't see anything since 4.4 touching the html generation itself (we
> >>> added pandoc for pdf but didn't touch HTML afaict).
> >>>
> >>> Ian.
> >>>
> >> I have looked into it before but didn't get very far.  I suspect it
> >> might be a bug in wheezy's markdown.  It doesn't reproduce when building
> >> using other versions of markdown.
> > Right.
> >
> > It seems to be triggered by the line:
> >   `S` is an integer 1 or 2 for the number of stop bits.
> > just removing that makes the issue go away. It's not the `s since
> > removing just those retains the issue. WTAF!
> >
> > Ian.
> >
> 
> So it does.  As best as I can tell, that is all legal mardown for a
> nested block.

Removing the preceeding nested list also "fixes" it, so I suspect some
sort of error in handling nested lists with surrounding text in the
parent entry, or something. I've not been able to find a workaround...

> 
> ~Andrew



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:39:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2fQ-0000Op-DF; Wed, 19 Nov 2014 10:39:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2fO-0000Oh-KA
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:39:18 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	30/B4-19763-5537C645; Wed, 19 Nov 2014 10:39:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416393555!12200245!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32764 invoked from network); 19 Nov 2014 10:39:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:39:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194331812"
Message-ID: <1416393524.29243.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 19 Nov 2014 10:38:44 +0000
In-Reply-To: <546C72F8.2020704@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com> <1416393024.29243.20.camel@citrix.com>
	<546C72F8.2020704@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:37 +0000, Andrew Cooper wrote:
> On 19/11/14 10:30, Ian Campbell wrote:
> > On Wed, 2014-11-19 at 10:24 +0000, Andrew Cooper wrote:
> >> On 19/11/14 10:12, Ian Campbell wrote:
> >>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> >>> bunch of random sha id's in it, where the 4.4-testing version does not.
> >>>
> >>> They seem to have replaced the various
> >>>         `= <boolean>`
> >>>         
> >>>         Default: `true`
> >>>         
> >>> Bits.
> >>>
> >>> Andy, Any thoughts or should I investigate?
> >>>
> >>> I don't see anything since 4.4 touching the html generation itself (we
> >>> added pandoc for pdf but didn't touch HTML afaict).
> >>>
> >>> Ian.
> >>>
> >> I have looked into it before but didn't get very far.  I suspect it
> >> might be a bug in wheezy's markdown.  It doesn't reproduce when building
> >> using other versions of markdown.
> > Right.
> >
> > It seems to be triggered by the line:
> >   `S` is an integer 1 or 2 for the number of stop bits.
> > just removing that makes the issue go away. It's not the `s since
> > removing just those retains the issue. WTAF!
> >
> > Ian.
> >
> 
> So it does.  As best as I can tell, that is all legal mardown for a
> nested block.

Removing the preceeding nested list also "fixes" it, so I suspect some
sort of error in handling nested lists with surrounding text in the
parent entry, or something. I've not been able to find a workaround...

> 
> ~Andrew



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:46:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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 1Xr2ma-0000jI-O9; Wed, 19 Nov 2014 10:46:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2mZ-0000jB-NV
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:46:43 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E5/E5-23865-2157C645; Wed, 19 Nov 2014 10:46:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416394000!7970810!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29888 invoked from network); 19 Nov 2014 10:46:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:46:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192818133"
Message-ID: <1416393997.29243.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Wed, 19 Nov 2014 10:46:37 +0000
In-Reply-To: <1416393524.29243.21.camel@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com> <1416393024.29243.20.camel@citrix.com>
	<546C72F8.2020704@citrix.com> <1416393524.29243.21.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:38 +0000, Ian Campbell wrote:
> I've not been able to find a workaround...

This works for me...

8<---------------

>From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 19 Nov 2014 10:42:18 +0000
Subject: [PATCH] docs: workaround markdown parser error in
 xen-command-line.markdown

Some versions of markdown (specifically the one in Debian Wheezy, currently
used to generate
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
confused by nested lists in the middle of multi-paragraph parent list entries
as seen in the com1,com2 entry.

The effect is that the "Default" section of all following entries are replace
by some sort of hash or checksum (at least, a string of 32 random seeming hex
digits).

Workaround this issue by making the decriptions of the DPS options a nested
list, moving the existing nested list describing the options for S into a third
level list. This seems to avoid the issue, and is arguably better formatting in
its own right (at least its not a regression IMHO)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 docs/misc/xen-command-line.markdown |   16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0830e5f..c40f89b 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -248,17 +248,17 @@ Both option `com1` and `com2` follow the same format.
 * `DPS` represents the number of data bits, the parity, and the number
   of stop bits.
 
-  `D` is an integer between 5 and 8 for the number of data bits.
+  * `D` is an integer between 5 and 8 for the number of data bits.
 
-  `P` is a single character representing the type of parity:
+  * `P` is a single character representing the type of parity:
 
-   * `n` No
-   * `o` Odd
-   * `e` Even
-   * `m` Mark
-   * `s` Space
+      * `n` No
+      * `o` Odd
+      * `e` Even
+      * `m` Mark
+      * `s` Space
 
-  `S` is an integer 1 or 2 for the number of stop bits.
+  * `S` is an integer 1 or 2 for the number of stop bits.
 
 * `<io-base>` is an integer which specifies the IO base port for UART
   registers.
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:46:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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 1Xr2ma-0000jI-O9; Wed, 19 Nov 2014 10:46:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr2mZ-0000jB-NV
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:46:43 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E5/E5-23865-2157C645; Wed, 19 Nov 2014 10:46:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416394000!7970810!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29888 invoked from network); 19 Nov 2014 10:46:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:46:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192818133"
Message-ID: <1416393997.29243.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Wed, 19 Nov 2014 10:46:37 +0000
In-Reply-To: <1416393524.29243.21.camel@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com> <1416393024.29243.20.camel@citrix.com>
	<546C72F8.2020704@citrix.com> <1416393524.29243.21.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:38 +0000, Ian Campbell wrote:
> I've not been able to find a workaround...

This works for me...

8<---------------

>From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 19 Nov 2014 10:42:18 +0000
Subject: [PATCH] docs: workaround markdown parser error in
 xen-command-line.markdown

Some versions of markdown (specifically the one in Debian Wheezy, currently
used to generate
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
confused by nested lists in the middle of multi-paragraph parent list entries
as seen in the com1,com2 entry.

The effect is that the "Default" section of all following entries are replace
by some sort of hash or checksum (at least, a string of 32 random seeming hex
digits).

Workaround this issue by making the decriptions of the DPS options a nested
list, moving the existing nested list describing the options for S into a third
level list. This seems to avoid the issue, and is arguably better formatting in
its own right (at least its not a regression IMHO)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 docs/misc/xen-command-line.markdown |   16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0830e5f..c40f89b 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -248,17 +248,17 @@ Both option `com1` and `com2` follow the same format.
 * `DPS` represents the number of data bits, the parity, and the number
   of stop bits.
 
-  `D` is an integer between 5 and 8 for the number of data bits.
+  * `D` is an integer between 5 and 8 for the number of data bits.
 
-  `P` is a single character representing the type of parity:
+  * `P` is a single character representing the type of parity:
 
-   * `n` No
-   * `o` Odd
-   * `e` Even
-   * `m` Mark
-   * `s` Space
+      * `n` No
+      * `o` Odd
+      * `e` Even
+      * `m` Mark
+      * `s` Space
 
-  `S` is an integer 1 or 2 for the number of stop bits.
+  * `S` is an integer 1 or 2 for the number of stop bits.
 
 * `<io-base>` is an integer which specifies the IO base port for UART
   registers.
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:53:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2sh-0000wI-O2; Wed, 19 Nov 2014 10:53:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xr2sg-0000wA-2p
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:53:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AE/0A-09842-D867C645; Wed, 19 Nov 2014 10:53:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416394379!13824238!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4171 invoked from network); 19 Nov 2014 10:53:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:53:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192819097"
Message-ID: <546C7689.10406@citrix.com>
Date: Wed, 19 Nov 2014 10:52:57 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
References: <1416391975.29243.16.camel@citrix.com>	
	<546C6FEB.8010308@citrix.com>
	<1416393024.29243.20.camel@citrix.com>	
	<546C72F8.2020704@citrix.com>
	<1416393524.29243.21.camel@citrix.com>
	<1416393997.29243.22.camel@citrix.com>
In-Reply-To: <1416393997.29243.22.camel@citrix.com>
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/14 10:46, Ian Campbell wrote:
> On Wed, 2014-11-19 at 10:38 +0000, Ian Campbell wrote:
>> I've not been able to find a workaround...
> This works for me...
>
> 8<---------------
>
> From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 19 Nov 2014 10:42:18 +0000
> Subject: [PATCH] docs: workaround markdown parser error in
>  xen-command-line.markdown
>
> Some versions of markdown (specifically the one in Debian Wheezy, currently
> used to generate
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
> confused by nested lists in the middle of multi-paragraph parent list entries
> as seen in the com1,com2 entry.
>
> The effect is that the "Default" section of all following entries are replace
> by some sort of hash or checksum (at least, a string of 32 random seeming hex
> digits).
>
> Workaround this issue by making the decriptions of the DPS options a nested
> list, moving the existing nested list describing the options for S into a third
> level list. This seems to avoid the issue, and is arguably better formatting in
> its own right (at least its not a regression IMHO)
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

I had just identified a different way, but this way is slightly better.

If you take out all the blank lines visible in the context below, the
resulting HTML will be correctly formatted and rather neater (i.e.
without sporadic blank lines).

~Andrew

> ---
>  docs/misc/xen-command-line.markdown |   16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> index 0830e5f..c40f89b 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -248,17 +248,17 @@ Both option `com1` and `com2` follow the same format.
>  * `DPS` represents the number of data bits, the parity, and the number
>    of stop bits.
>  
> -  `D` is an integer between 5 and 8 for the number of data bits.
> +  * `D` is an integer between 5 and 8 for the number of data bits.
>  
> -  `P` is a single character representing the type of parity:
> +  * `P` is a single character representing the type of parity:
>  
> -   * `n` No
> -   * `o` Odd
> -   * `e` Even
> -   * `m` Mark
> -   * `s` Space
> +      * `n` No
> +      * `o` Odd
> +      * `e` Even
> +      * `m` Mark
> +      * `s` Space
>  
> -  `S` is an integer 1 or 2 for the number of stop bits.
> +  * `S` is an integer 1 or 2 for the number of stop bits.
>  
>  * `<io-base>` is an integer which specifies the IO base port for UART
>    registers.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:53:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 10:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr2sh-0000wI-O2; Wed, 19 Nov 2014 10:53:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xr2sg-0000wA-2p
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 10:53:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AE/0A-09842-D867C645; Wed, 19 Nov 2014 10:53:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416394379!13824238!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4171 invoked from network); 19 Nov 2014 10:53:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 10:53:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192819097"
Message-ID: <546C7689.10406@citrix.com>
Date: Wed, 19 Nov 2014 10:52:57 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
References: <1416391975.29243.16.camel@citrix.com>	
	<546C6FEB.8010308@citrix.com>
	<1416393024.29243.20.camel@citrix.com>	
	<546C72F8.2020704@citrix.com>
	<1416393524.29243.21.camel@citrix.com>
	<1416393997.29243.22.camel@citrix.com>
In-Reply-To: <1416393997.29243.22.camel@citrix.com>
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/14 10:46, Ian Campbell wrote:
> On Wed, 2014-11-19 at 10:38 +0000, Ian Campbell wrote:
>> I've not been able to find a workaround...
> This works for me...
>
> 8<---------------
>
> From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 19 Nov 2014 10:42:18 +0000
> Subject: [PATCH] docs: workaround markdown parser error in
>  xen-command-line.markdown
>
> Some versions of markdown (specifically the one in Debian Wheezy, currently
> used to generate
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
> confused by nested lists in the middle of multi-paragraph parent list entries
> as seen in the com1,com2 entry.
>
> The effect is that the "Default" section of all following entries are replace
> by some sort of hash or checksum (at least, a string of 32 random seeming hex
> digits).
>
> Workaround this issue by making the decriptions of the DPS options a nested
> list, moving the existing nested list describing the options for S into a third
> level list. This seems to avoid the issue, and is arguably better formatting in
> its own right (at least its not a regression IMHO)
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

I had just identified a different way, but this way is slightly better.

If you take out all the blank lines visible in the context below, the
resulting HTML will be correctly formatted and rather neater (i.e.
without sporadic blank lines).

~Andrew

> ---
>  docs/misc/xen-command-line.markdown |   16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> index 0830e5f..c40f89b 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -248,17 +248,17 @@ Both option `com1` and `com2` follow the same format.
>  * `DPS` represents the number of data bits, the parity, and the number
>    of stop bits.
>  
> -  `D` is an integer between 5 and 8 for the number of data bits.
> +  * `D` is an integer between 5 and 8 for the number of data bits.
>  
> -  `P` is a single character representing the type of parity:
> +  * `P` is a single character representing the type of parity:
>  
> -   * `n` No
> -   * `o` Odd
> -   * `e` Even
> -   * `m` Mark
> -   * `s` Space
> +      * `n` No
> +      * `o` Odd
> +      * `e` Even
> +      * `m` Mark
> +      * `s` Space
>  
> -  `S` is an integer 1 or 2 for the number of stop bits.
> +  * `S` is an integer 1 or 2 for the number of stop bits.
>  
>  * `<io-base>` is an integer which specifies the IO base port for UART
>    registers.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:53:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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.xen.org>)
	id 1Xr2tA-0000yw-4I; Wed, 19 Nov 2014 10:53:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr2t8-0000yi-KR
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 10:53:30 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	E0/90-03148-9A67C645; Wed, 19 Nov 2014 10:53:29 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416394407!13428273!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28946 invoked from network); 19 Nov 2014 10:53:29 -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;
	19 Nov 2014 10:53:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194334320"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 05:53:19 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr2sx-0008Jj-Bx;
	Wed, 19 Nov 2014 10:53:19 +0000
Date: Wed, 19 Nov 2014 10:52:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <konrad.wilk@oracle.com>
In-Reply-To: <alpine.DEB.2.02.1411181410440.27247@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411191052330.27247@kaball.uk.xensource.com>
References: <1416259239-13281-1-git-send-email-dslutz@verizon.com>
	<alpine.DEB.2.02.1411181410440.27247@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com, Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [BUGFIX][PATCH for 2.2 1/1] hw/ide/core.c: Prevent
 SIGSEGV during migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ping?

On Tue, 18 Nov 2014, Stefano Stabellini wrote:
> Konrad,
> I think we should have this fix in Xen 4.5. Should I go ahead and
> backport it?
> 
> On Mon, 17 Nov 2014, Don Slutz wrote:
> > The other callers to blk_set_enable_write_cache() in this file
> > already check for s->blk == NULL.
> > 
> > Signed-off-by: Don Slutz <dslutz@verizon.com>
> > ---
> > 
> > I think this is a bugfix that should be back ported to stable
> > releases.
> > 
> > I also think this should be done in xen's copy of QEMU for 4.5 with
> > back port(s) to active stable releases.
> > 
> > Note: In 2.1 and earlier the routine is
> > bdrv_set_enable_write_cache(); variable is s->bs.
> > 
> >  hw/ide/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/hw/ide/core.c b/hw/ide/core.c
> > index 00e21cf..d4af5e2 100644
> > --- a/hw/ide/core.c
> > +++ b/hw/ide/core.c
> > @@ -2401,7 +2401,7 @@ static int ide_drive_post_load(void *opaque, int version_id)
> >  {
> >      IDEState *s = opaque;
> >  
> > -    if (s->identify_set) {
> > +    if (s->blk && s->identify_set) {
> >          blk_set_enable_write_cache(s->blk, !!(s->identify_data[85] & (1 << 5)));
> >      }
> >      return 0;
> > -- 
> > 1.8.4
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 10:53:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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.xen.org>)
	id 1Xr2tA-0000yw-4I; Wed, 19 Nov 2014 10:53:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr2t8-0000yi-KR
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 10:53:30 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	E0/90-03148-9A67C645; Wed, 19 Nov 2014 10:53:29 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416394407!13428273!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28946 invoked from network); 19 Nov 2014 10:53:29 -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;
	19 Nov 2014 10:53:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194334320"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 05:53:19 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr2sx-0008Jj-Bx;
	Wed, 19 Nov 2014 10:53:19 +0000
Date: Wed, 19 Nov 2014 10:52:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <konrad.wilk@oracle.com>
In-Reply-To: <alpine.DEB.2.02.1411181410440.27247@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411191052330.27247@kaball.uk.xensource.com>
References: <1416259239-13281-1-git-send-email-dslutz@verizon.com>
	<alpine.DEB.2.02.1411181410440.27247@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com, Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [BUGFIX][PATCH for 2.2 1/1] hw/ide/core.c: Prevent
 SIGSEGV during migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ping?

On Tue, 18 Nov 2014, Stefano Stabellini wrote:
> Konrad,
> I think we should have this fix in Xen 4.5. Should I go ahead and
> backport it?
> 
> On Mon, 17 Nov 2014, Don Slutz wrote:
> > The other callers to blk_set_enable_write_cache() in this file
> > already check for s->blk == NULL.
> > 
> > Signed-off-by: Don Slutz <dslutz@verizon.com>
> > ---
> > 
> > I think this is a bugfix that should be back ported to stable
> > releases.
> > 
> > I also think this should be done in xen's copy of QEMU for 4.5 with
> > back port(s) to active stable releases.
> > 
> > Note: In 2.1 and earlier the routine is
> > bdrv_set_enable_write_cache(); variable is s->bs.
> > 
> >  hw/ide/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/hw/ide/core.c b/hw/ide/core.c
> > index 00e21cf..d4af5e2 100644
> > --- a/hw/ide/core.c
> > +++ b/hw/ide/core.c
> > @@ -2401,7 +2401,7 @@ static int ide_drive_post_load(void *opaque, int version_id)
> >  {
> >      IDEState *s = opaque;
> >  
> > -    if (s->identify_set) {
> > +    if (s->blk && s->identify_set) {
> >          blk_set_enable_write_cache(s->blk, !!(s->identify_data[85] & (1 << 5)));
> >      }
> >      return 0;
> > -- 
> > 1.8.4
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:06:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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.xen.org>)
	id 1Xr35f-0001K5-R4; Wed, 19 Nov 2014 11:06:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr35e-0001K0-1Y
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:06:26 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	43/3C-03145-1B97C645; Wed, 19 Nov 2014 11:06:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416395183!13479949!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20696 invoked from network); 19 Nov 2014 11:06:24 -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;
	19 Nov 2014 11:06:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194337046"
Message-ID: <1416395092.29243.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 19 Nov 2014 11:04:52 +0000
In-Reply-To: <546C7689.10406@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com> <1416393024.29243.20.camel@citrix.com>
	<546C72F8.2020704@citrix.com> <1416393524.29243.21.camel@citrix.com>
	<1416393997.29243.22.camel@citrix.com> <546C7689.10406@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:52 +0000, Andrew Cooper wrote:
> On 19/11/14 10:46, Ian Campbell wrote:
> > On Wed, 2014-11-19 at 10:38 +0000, Ian Campbell wrote:
> >> I've not been able to find a workaround...
> > This works for me...
> >
> > 8<---------------
> >
> > From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Wed, 19 Nov 2014 10:42:18 +0000
> > Subject: [PATCH] docs: workaround markdown parser error in
> >  xen-command-line.markdown
> >
> > Some versions of markdown (specifically the one in Debian Wheezy, currently
> > used to generate
> > http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
> > confused by nested lists in the middle of multi-paragraph parent list entries
> > as seen in the com1,com2 entry.
> >
> > The effect is that the "Default" section of all following entries are replace
> > by some sort of hash or checksum (at least, a string of 32 random seeming hex
> > digits).
> >
> > Workaround this issue by making the decriptions of the DPS options a nested
> > list, moving the existing nested list describing the options for S into a third
> > level list. This seems to avoid the issue, and is arguably better formatting in
> > its own right (at least its not a regression IMHO)
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I had just identified a different way, but this way is slightly better.
> 
> If you take out all the blank lines visible in the context below, the
> resulting HTML will be correctly formatted and rather neater (i.e.
> without sporadic blank lines).

Agreed.

8<------

>From 53398a9729d391f1fb7b6f753a0032b1f3604d4d Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 19 Nov 2014 10:42:18 +0000
Subject: [PATCH] docs: workaround markdown parser error in
 xen-command-line.markdown

Some versions of markdown (specifically the one in Debian Wheezy, currently
used to generate
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
confused by nested lists in the middle of multi-paragraph parent list entries
as seen in the com1,com2 entry.

The effect is that the "Default" section of all following entries are replace
by some sort of hash or checksum (at least, a string of 32 random seeming hex
digits).

Workaround this issue by making the decriptions of the DPS options a nested
list, moving the existing nested list describing the options for S into a third
level list. This seems to avoid the issue, and is arguably better formatting in
its own right (at least its not a regression IMHO)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Less blank lines == nicer output.
---
 docs/misc/xen-command-line.markdown |   21 ++++++++-------------
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0830e5f..b7eaeea 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -247,19 +247,14 @@ Both option `com1` and `com2` follow the same format.
 * Optionally, a clock speed measured in hz can be specified.
 * `DPS` represents the number of data bits, the parity, and the number
   of stop bits.
-
-  `D` is an integer between 5 and 8 for the number of data bits.
-
-  `P` is a single character representing the type of parity:
-
-   * `n` No
-   * `o` Odd
-   * `e` Even
-   * `m` Mark
-   * `s` Space
-
-  `S` is an integer 1 or 2 for the number of stop bits.
-
+  * `D` is an integer between 5 and 8 for the number of data bits.
+  * `P` is a single character representing the type of parity:
+      * `n` No
+      * `o` Odd
+      * `e` Even
+      * `m` Mark
+      * `s` Space
+  * `S` is an integer 1 or 2 for the number of stop bits.
 * `<io-base>` is an integer which specifies the IO base port for UART
   registers.
 * `<irq>` is the IRQ number to use, or `0` to use the UART in poll
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:06:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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.xen.org>)
	id 1Xr35f-0001K5-R4; Wed, 19 Nov 2014 11:06:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr35e-0001K0-1Y
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:06:26 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	43/3C-03145-1B97C645; Wed, 19 Nov 2014 11:06:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416395183!13479949!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20696 invoked from network); 19 Nov 2014 11:06:24 -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;
	19 Nov 2014 11:06:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194337046"
Message-ID: <1416395092.29243.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 19 Nov 2014 11:04:52 +0000
In-Reply-To: <546C7689.10406@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com> <1416393024.29243.20.camel@citrix.com>
	<546C72F8.2020704@citrix.com> <1416393524.29243.21.camel@citrix.com>
	<1416393997.29243.22.camel@citrix.com> <546C7689.10406@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 10:52 +0000, Andrew Cooper wrote:
> On 19/11/14 10:46, Ian Campbell wrote:
> > On Wed, 2014-11-19 at 10:38 +0000, Ian Campbell wrote:
> >> I've not been able to find a workaround...
> > This works for me...
> >
> > 8<---------------
> >
> > From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Wed, 19 Nov 2014 10:42:18 +0000
> > Subject: [PATCH] docs: workaround markdown parser error in
> >  xen-command-line.markdown
> >
> > Some versions of markdown (specifically the one in Debian Wheezy, currently
> > used to generate
> > http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
> > confused by nested lists in the middle of multi-paragraph parent list entries
> > as seen in the com1,com2 entry.
> >
> > The effect is that the "Default" section of all following entries are replace
> > by some sort of hash or checksum (at least, a string of 32 random seeming hex
> > digits).
> >
> > Workaround this issue by making the decriptions of the DPS options a nested
> > list, moving the existing nested list describing the options for S into a third
> > level list. This seems to avoid the issue, and is arguably better formatting in
> > its own right (at least its not a regression IMHO)
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I had just identified a different way, but this way is slightly better.
> 
> If you take out all the blank lines visible in the context below, the
> resulting HTML will be correctly formatted and rather neater (i.e.
> without sporadic blank lines).

Agreed.

8<------

>From 53398a9729d391f1fb7b6f753a0032b1f3604d4d Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 19 Nov 2014 10:42:18 +0000
Subject: [PATCH] docs: workaround markdown parser error in
 xen-command-line.markdown

Some versions of markdown (specifically the one in Debian Wheezy, currently
used to generate
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
confused by nested lists in the middle of multi-paragraph parent list entries
as seen in the com1,com2 entry.

The effect is that the "Default" section of all following entries are replace
by some sort of hash or checksum (at least, a string of 32 random seeming hex
digits).

Workaround this issue by making the decriptions of the DPS options a nested
list, moving the existing nested list describing the options for S into a third
level list. This seems to avoid the issue, and is arguably better formatting in
its own right (at least its not a regression IMHO)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Less blank lines == nicer output.
---
 docs/misc/xen-command-line.markdown |   21 ++++++++-------------
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0830e5f..b7eaeea 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -247,19 +247,14 @@ Both option `com1` and `com2` follow the same format.
 * Optionally, a clock speed measured in hz can be specified.
 * `DPS` represents the number of data bits, the parity, and the number
   of stop bits.
-
-  `D` is an integer between 5 and 8 for the number of data bits.
-
-  `P` is a single character representing the type of parity:
-
-   * `n` No
-   * `o` Odd
-   * `e` Even
-   * `m` Mark
-   * `s` Space
-
-  `S` is an integer 1 or 2 for the number of stop bits.
-
+  * `D` is an integer between 5 and 8 for the number of data bits.
+  * `P` is a single character representing the type of parity:
+      * `n` No
+      * `o` Odd
+      * `e` Even
+      * `m` Mark
+      * `s` Space
+  * `S` is an integer 1 or 2 for the number of stop bits.
 * `<io-base>` is an integer which specifies the IO base port for UART
   registers.
 * `<irq>` is the IRQ number to use, or `0` to use the UART in poll
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:06:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr36A-0001M5-82; Wed, 19 Nov 2014 11:06:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xr368-0001Lp-Rb
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:06:57 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	9C/53-02696-0D97C645; Wed, 19 Nov 2014 11:06:56 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416395213!13464873!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28560 invoked from network); 19 Nov 2014 11:06:55 -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;
	19 Nov 2014 11:06:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192822045"
Message-ID: <546C797D.6040709@citrix.com>
Date: Wed, 19 Nov 2014 11:05:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>		
	<546C6FEB.8010308@citrix.com>
	<1416393024.29243.20.camel@citrix.com>		
	<546C72F8.2020704@citrix.com>
	<1416393524.29243.21.camel@citrix.com>	
	<1416393997.29243.22.camel@citrix.com> <546C7689.10406@citrix.com>
	<1416395092.29243.27.camel@citrix.com>
In-Reply-To: <1416395092.29243.27.camel@citrix.com>
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/14 11:04, Ian Campbell wrote:
> On Wed, 2014-11-19 at 10:52 +0000, Andrew Cooper wrote:
>> On 19/11/14 10:46, Ian Campbell wrote:
>>> On Wed, 2014-11-19 at 10:38 +0000, Ian Campbell wrote:
>>>> I've not been able to find a workaround...
>>> This works for me...
>>>
>>> 8<---------------
>>>
>>> From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00 2001
>>> From: Ian Campbell <ian.campbell@citrix.com>
>>> Date: Wed, 19 Nov 2014 10:42:18 +0000
>>> Subject: [PATCH] docs: workaround markdown parser error in
>>>  xen-command-line.markdown
>>>
>>> Some versions of markdown (specifically the one in Debian Wheezy, currently
>>> used to generate
>>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
>>> confused by nested lists in the middle of multi-paragraph parent list entries
>>> as seen in the com1,com2 entry.
>>>
>>> The effect is that the "Default" section of all following entries are replace
>>> by some sort of hash or checksum (at least, a string of 32 random seeming hex
>>> digits).
>>>
>>> Workaround this issue by making the decriptions of the DPS options a nested
>>> list, moving the existing nested list describing the options for S into a third
>>> level list. This seems to avoid the issue, and is arguably better formatting in
>>> its own right (at least its not a regression IMHO)
>>>
>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> I had just identified a different way, but this way is slightly better.
>>
>> If you take out all the blank lines visible in the context below, the
>> resulting HTML will be correctly formatted and rather neater (i.e.
>> without sporadic blank lines).
> Agreed.
>
> 8<------
>
> From 53398a9729d391f1fb7b6f753a0032b1f3604d4d Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 19 Nov 2014 10:42:18 +0000
> Subject: [PATCH] docs: workaround markdown parser error in
>  xen-command-line.markdown
>
> Some versions of markdown (specifically the one in Debian Wheezy, currently
> used to generate
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
> confused by nested lists in the middle of multi-paragraph parent list entries
> as seen in the com1,com2 entry.
>
> The effect is that the "Default" section of all following entries are replace
> by some sort of hash or checksum (at least, a string of 32 random seeming hex
> digits).
>
> Workaround this issue by making the decriptions of the DPS options a nested
> list, moving the existing nested list describing the options for S into a third
> level list. This seems to avoid the issue, and is arguably better formatting in
> its own right (at least its not a regression IMHO)
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
> v2: Less blank lines == nicer output.
> ---
>  docs/misc/xen-command-line.markdown |   21 ++++++++-------------
>  1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> index 0830e5f..b7eaeea 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -247,19 +247,14 @@ Both option `com1` and `com2` follow the same format.
>  * Optionally, a clock speed measured in hz can be specified.
>  * `DPS` represents the number of data bits, the parity, and the number
>    of stop bits.
> -
> -  `D` is an integer between 5 and 8 for the number of data bits.
> -
> -  `P` is a single character representing the type of parity:
> -
> -   * `n` No
> -   * `o` Odd
> -   * `e` Even
> -   * `m` Mark
> -   * `s` Space
> -
> -  `S` is an integer 1 or 2 for the number of stop bits.
> -
> +  * `D` is an integer between 5 and 8 for the number of data bits.
> +  * `P` is a single character representing the type of parity:
> +      * `n` No
> +      * `o` Odd
> +      * `e` Even
> +      * `m` Mark
> +      * `s` Space
> +  * `S` is an integer 1 or 2 for the number of stop bits.
>  * `<io-base>` is an integer which specifies the IO base port for UART
>    registers.
>  * `<irq>` is the IRQ number to use, or `0` to use the UART in poll


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:06:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr36A-0001M5-82; Wed, 19 Nov 2014 11:06:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xr368-0001Lp-Rb
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:06:57 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	9C/53-02696-0D97C645; Wed, 19 Nov 2014 11:06:56 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416395213!13464873!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28560 invoked from network); 19 Nov 2014 11:06:55 -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;
	19 Nov 2014 11:06:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192822045"
Message-ID: <546C797D.6040709@citrix.com>
Date: Wed, 19 Nov 2014 11:05:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>		
	<546C6FEB.8010308@citrix.com>
	<1416393024.29243.20.camel@citrix.com>		
	<546C72F8.2020704@citrix.com>
	<1416393524.29243.21.camel@citrix.com>	
	<1416393997.29243.22.camel@citrix.com> <546C7689.10406@citrix.com>
	<1416395092.29243.27.camel@citrix.com>
In-Reply-To: <1416395092.29243.27.camel@citrix.com>
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/14 11:04, Ian Campbell wrote:
> On Wed, 2014-11-19 at 10:52 +0000, Andrew Cooper wrote:
>> On 19/11/14 10:46, Ian Campbell wrote:
>>> On Wed, 2014-11-19 at 10:38 +0000, Ian Campbell wrote:
>>>> I've not been able to find a workaround...
>>> This works for me...
>>>
>>> 8<---------------
>>>
>>> From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00 2001
>>> From: Ian Campbell <ian.campbell@citrix.com>
>>> Date: Wed, 19 Nov 2014 10:42:18 +0000
>>> Subject: [PATCH] docs: workaround markdown parser error in
>>>  xen-command-line.markdown
>>>
>>> Some versions of markdown (specifically the one in Debian Wheezy, currently
>>> used to generate
>>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
>>> confused by nested lists in the middle of multi-paragraph parent list entries
>>> as seen in the com1,com2 entry.
>>>
>>> The effect is that the "Default" section of all following entries are replace
>>> by some sort of hash or checksum (at least, a string of 32 random seeming hex
>>> digits).
>>>
>>> Workaround this issue by making the decriptions of the DPS options a nested
>>> list, moving the existing nested list describing the options for S into a third
>>> level list. This seems to avoid the issue, and is arguably better formatting in
>>> its own right (at least its not a regression IMHO)
>>>
>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> I had just identified a different way, but this way is slightly better.
>>
>> If you take out all the blank lines visible in the context below, the
>> resulting HTML will be correctly formatted and rather neater (i.e.
>> without sporadic blank lines).
> Agreed.
>
> 8<------
>
> From 53398a9729d391f1fb7b6f753a0032b1f3604d4d Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 19 Nov 2014 10:42:18 +0000
> Subject: [PATCH] docs: workaround markdown parser error in
>  xen-command-line.markdown
>
> Some versions of markdown (specifically the one in Debian Wheezy, currently
> used to generate
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
> confused by nested lists in the middle of multi-paragraph parent list entries
> as seen in the com1,com2 entry.
>
> The effect is that the "Default" section of all following entries are replace
> by some sort of hash or checksum (at least, a string of 32 random seeming hex
> digits).
>
> Workaround this issue by making the decriptions of the DPS options a nested
> list, moving the existing nested list describing the options for S into a third
> level list. This seems to avoid the issue, and is arguably better formatting in
> its own right (at least its not a regression IMHO)
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
> v2: Less blank lines == nicer output.
> ---
>  docs/misc/xen-command-line.markdown |   21 ++++++++-------------
>  1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> index 0830e5f..b7eaeea 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -247,19 +247,14 @@ Both option `com1` and `com2` follow the same format.
>  * Optionally, a clock speed measured in hz can be specified.
>  * `DPS` represents the number of data bits, the parity, and the number
>    of stop bits.
> -
> -  `D` is an integer between 5 and 8 for the number of data bits.
> -
> -  `P` is a single character representing the type of parity:
> -
> -   * `n` No
> -   * `o` Odd
> -   * `e` Even
> -   * `m` Mark
> -   * `s` Space
> -
> -  `S` is an integer 1 or 2 for the number of stop bits.
> -
> +  * `D` is an integer between 5 and 8 for the number of data bits.
> +  * `P` is a single character representing the type of parity:
> +      * `n` No
> +      * `o` Odd
> +      * `e` Even
> +      * `m` Mark
> +      * `s` Space
> +  * `S` is an integer 1 or 2 for the number of stop bits.
>  * `<io-base>` is an integer which specifies the IO base port for UART
>    registers.
>  * `<irq>` is the IRQ number to use, or `0` to use the UART in poll


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:08:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr37S-0001UN-OF; Wed, 19 Nov 2014 11:08:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr37R-0001UC-Hw
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 11:08:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B5/C5-09936-02A7C645; Wed, 19 Nov 2014 11:08:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416395294!13860197!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5088 invoked from network); 19 Nov 2014 11:08:16 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 11:08:16 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJB8AZR009449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 11:08:11 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAJB89ep028814
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 11:08:10 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJB88N1028622; Wed, 19 Nov 2014 11:08:09 GMT
Received: from [IPv6:2607:fb90:2405:f91c:53f:5d67:f782:e915] (/172.56.34.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 03:08:08 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <alpine.DEB.2.02.1411191052330.27247@kaball.uk.xensource.com>
References: <1416259239-13281-1-git-send-email-dslutz@verizon.com>
	<alpine.DEB.2.02.1411181410440.27247@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411191052330.27247@kaball.uk.xensource.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 19 Nov 2014 06:08:04 -0500
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <4EC8C166-7BA3-4F63-A09A-097F4FD67652@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, Don Slutz <dslutz@verizon.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [BUGFIX][PATCH for 2.2 1/1] hw/ide/core.c: Prevent
	SIGSEGV during migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 19, 2014 5:52:58 AM EST, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>ping?
>
>On Tue, 18 Nov 2014, Stefano Stabellini wrote:
>> Konrad,
>> I think we should have this fix in Xen 4.5. Should I go ahead and
>> backport it?

Go for it. Release-Acked-by: Konrad Rzeszutek Wilk (konrad.wilk@oracle.com)

>> 
>> On Mon, 17 Nov 2014, Don Slutz wrote:
>> > The other callers to blk_set_enable_write_cache() in this file
>> > already check for s->blk == NULL.
>> > 
>> > Signed-off-by: Don Slutz <dslutz@verizon.com>
>> > ---
>> > 
>> > I think this is a bugfix that should be back ported to stable
>> > releases.
>> > 
>> > I also think this should be done in xen's copy of QEMU for 4.5 with
>> > back port(s) to active stable releases.
>> > 
>> > Note: In 2.1 and earlier the routine is
>> > bdrv_set_enable_write_cache(); variable is s->bs.
>> > 
>> >  hw/ide/core.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > 
>> > diff --git a/hw/ide/core.c b/hw/ide/core.c
>> > index 00e21cf..d4af5e2 100644
>> > --- a/hw/ide/core.c
>> > +++ b/hw/ide/core.c
>> > @@ -2401,7 +2401,7 @@ static int ide_drive_post_load(void *opaque,
>int version_id)
>> >  {
>> >      IDEState *s = opaque;
>> >  
>> > -    if (s->identify_set) {
>> > +    if (s->blk && s->identify_set) {
>> >          blk_set_enable_write_cache(s->blk, !!(s->identify_data[85]
>& (1 << 5)));
>> >      }
>> >      return 0;
>> > -- 
>> > 1.8.4
>> > 
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:08:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr37S-0001UN-OF; Wed, 19 Nov 2014 11:08:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr37R-0001UC-Hw
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 11:08:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B5/C5-09936-02A7C645; Wed, 19 Nov 2014 11:08:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416395294!13860197!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5088 invoked from network); 19 Nov 2014 11:08:16 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 11:08:16 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJB8AZR009449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 11:08:11 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAJB89ep028814
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 11:08:10 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJB88N1028622; Wed, 19 Nov 2014 11:08:09 GMT
Received: from [IPv6:2607:fb90:2405:f91c:53f:5d67:f782:e915] (/172.56.34.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 03:08:08 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <alpine.DEB.2.02.1411191052330.27247@kaball.uk.xensource.com>
References: <1416259239-13281-1-git-send-email-dslutz@verizon.com>
	<alpine.DEB.2.02.1411181410440.27247@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411191052330.27247@kaball.uk.xensource.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 19 Nov 2014 06:08:04 -0500
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <4EC8C166-7BA3-4F63-A09A-097F4FD67652@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, Don Slutz <dslutz@verizon.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [BUGFIX][PATCH for 2.2 1/1] hw/ide/core.c: Prevent
	SIGSEGV during migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 19, 2014 5:52:58 AM EST, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>ping?
>
>On Tue, 18 Nov 2014, Stefano Stabellini wrote:
>> Konrad,
>> I think we should have this fix in Xen 4.5. Should I go ahead and
>> backport it?

Go for it. Release-Acked-by: Konrad Rzeszutek Wilk (konrad.wilk@oracle.com)

>> 
>> On Mon, 17 Nov 2014, Don Slutz wrote:
>> > The other callers to blk_set_enable_write_cache() in this file
>> > already check for s->blk == NULL.
>> > 
>> > Signed-off-by: Don Slutz <dslutz@verizon.com>
>> > ---
>> > 
>> > I think this is a bugfix that should be back ported to stable
>> > releases.
>> > 
>> > I also think this should be done in xen's copy of QEMU for 4.5 with
>> > back port(s) to active stable releases.
>> > 
>> > Note: In 2.1 and earlier the routine is
>> > bdrv_set_enable_write_cache(); variable is s->bs.
>> > 
>> >  hw/ide/core.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > 
>> > diff --git a/hw/ide/core.c b/hw/ide/core.c
>> > index 00e21cf..d4af5e2 100644
>> > --- a/hw/ide/core.c
>> > +++ b/hw/ide/core.c
>> > @@ -2401,7 +2401,7 @@ static int ide_drive_post_load(void *opaque,
>int version_id)
>> >  {
>> >      IDEState *s = opaque;
>> >  
>> > -    if (s->identify_set) {
>> > +    if (s->blk && s->identify_set) {
>> >          blk_set_enable_write_cache(s->blk, !!(s->identify_data[85]
>& (1 << 5)));
>> >      }
>> >      return 0;
>> > -- 
>> > 1.8.4
>> > 
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:11:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:11:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Ab-0001iR-W8; Wed, 19 Nov 2014 11:11:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr3Aa-0001iE-SL
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 11:11:33 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	2C/6B-09284-4EA7C645; Wed, 19 Nov 2014 11:11:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416395490!7978390!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25999 invoked from network); 19 Nov 2014 11:11:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:11:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192823458"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 19 Nov 2014 06:11:18 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr3AM-0001u4-Ha;
	Wed, 19 Nov 2014 11:11:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr3AM-0000xh-AB;
	Wed, 19 Nov 2014 11:11:18 +0000
Date: Wed, 19 Nov 2014 11:11:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31668-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11464
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31668: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0046652713569381525=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0046652713569381525==
Content-Type: text/plain
Content-Length: 11229
Content-Transfer-Encoding: quoted-printable

flight 31668 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31668/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                f874bf905ff2f8dcc17acbfc61e49a92a6f4d04b
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liang <liang.z.li@intel.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12960 lines long.)


--===============0046652713569381525==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0046652713569381525==--

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:11:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:11:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Ab-0001iR-W8; Wed, 19 Nov 2014 11:11:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr3Aa-0001iE-SL
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 11:11:33 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	2C/6B-09284-4EA7C645; Wed, 19 Nov 2014 11:11:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416395490!7978390!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25999 invoked from network); 19 Nov 2014 11:11:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:11:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192823458"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 19 Nov 2014 06:11:18 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr3AM-0001u4-Ha;
	Wed, 19 Nov 2014 11:11:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr3AM-0000xh-AB;
	Wed, 19 Nov 2014 11:11:18 +0000
Date: Wed, 19 Nov 2014 11:11:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31668-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11464
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31668: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0046652713569381525=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0046652713569381525==
Content-Type: text/plain
Content-Length: 11229
Content-Transfer-Encoding: quoted-printable

flight 31668 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31668/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                f874bf905ff2f8dcc17acbfc61e49a92a6f4d04b
baseline version:
 qemuu                b00a0ddb31a393b8386d30a9bef4d9bbb249e7ec

------------------------------------------------------------
People who touched revisions under test:
  Adam Crume <adamcrume@gmail.com>
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Alex Williamson <alex.williamson@redhat.com>
  Alexander Graf <agraf@suse.de>
  Alexey Kardashevskiy <aik@ozlabs.ru>
  Amit Shah <amit.shah@redhat.com>
  Amos Kong <akong@redhat.com>
  Andreas F=C3=A4rber <afaerber@suse.de>
  Andrew Jones <drjones@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Aurelien Jarno <aurelien@aurel32.net>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Bharata B Rao <bharata@linux.vnet.ibm.com>
  Bin Wu <wu.wubin@huawei.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Gang <gang.chen.5i5j@gmail.com>
  Chenliang <chenliang88@huawei.com>
  Chris Johns <chrisj@rtems.org>
  Chris Spiegel <chris.spiegel@cypherpath.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Claudio Fontana <claudio.fontana@huawei.com>
  Cole Robinson <crobinso@redhat.com>
  Corey Minyard <cminyard@mvista.com>
  Cornelia Huck <cornelia.huck@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  David Hildenbrand <dahi@linux.vnet.ibm.com>
  Denis V. Lunev <den@openvz.org>
  Don Slutz <dslutz@verizon.com>
  Dongxue Zhang <elta.era@gmail.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eduardo Otubo <eduardo.otubo@profitbricks.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Gal Hammer <ghammer@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hannes Reinecke <hare@suse.de>
  Heinz Graalfs <graalfs@linux.vnet.ibm.com>
  Igor Mammedov <imammedo@redhat.com>
  James Harper <james.harper@ejbdigital.com.au>
  James Harper <james@ejbdigital.com.au>
  Jan Kiszka <jan.kiszka@siemens.com>
  Jan Vesely <jano.vesely@gmail.com>
  Jens Freimann <jfrei@linux.vnet.ibm.com>
  Joel Schopp <jschopp@linux.vnet.ibm.com>
  John Snow <jsnow@redhat.com>
  Jonas Gorski <jogo@openwrt.org>
  Jonas Maebe <jonas.maebe@elis.ugent.be>
  Juan Quintela <quintela@redhat.com>
  Juan Quintela <quintela@trasno.org>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  KONRAD Frederic <fred.konrad@greensocs.com>
  Laszlo Ersek <lersek@redhat.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Li Liang <liang.z.li@intel.com>
  Li Liu <john.liuli@huawei.com>
  Luiz Capitulino <lcapitulino@redhat.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Magnus Reftel <reftel@spotify.com>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Martin Decky <martin@decky.cz>
  Martin Simmons <martin@lispworks.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Max Reitz <mreitz@redhat.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Michael Roth <mdroth@linux.vnet.ibm.com>
  Michael S. Tsirkin <mst@redhat.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Michael Walle <michael@walle.cc> (for lm32)
  Michal Privoznik <mprivozn@redhat.com>
  Mikhail Ilyin <m.ilin@samsung.com>
  Ming Lei <ming.lei@canonical.com>
  Nikita Belov <zodiac@ispras.ru>
  Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Paul Moore <pmoore@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Crosthwaite <peter.crosthwaite@xilinx.com>
  Peter Lieven <pl@kamp.de>
  Peter Maydell <peter.maydell@linaro.org>
  Peter Wu <peter@lekensteyn.nl>
  Petr Matousek <pmatouse@redhat.com>
  Philipp Gesang <philipp.gesang@intra2net.com>
  Pierre Mallard <mallard.pierre@gmail.com>
  Ray Strode <rstrode@redhat.com>
  Richard Jones <rjones@redhat.com>
  Richard W.M. Jones <rjones@redhat.com>
  Riku Voipio <riku.voipio@linaro.org>
  Rob Herring <rob.herring@linaro.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
  Sebastian Krahmer <krahmer@suse.de>
  SeokYeon Hwang <syeon.hwang@samsung.com>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Berger <stefanb@linux.vnet.ibm.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  Ting Wang <kathy.wangting@huawei.com>
  Tom Musta <tommusta@gmail.com>
  Tony Breeds <tony@bakeyournoodle.com>
  Wei Huang <wei@redhat.com>
  Willem Pinckaers <willem_qemu@lekkertech.net>
  Yongbok Kim <yongbok.kim@imgtec.com>
  Zhang Haoyu <zhanghy@sangfor.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
  Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 12960 lines long.)


--===============0046652713569381525==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0046652713569381525==--

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:11:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:11:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Ar-0001nZ-F7; Wed, 19 Nov 2014 11:11:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr3Ap-0001kJ-Cl
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:11:47 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	11/28-14214-2FA7C645; Wed, 19 Nov 2014 11:11:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416395503!6928141!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10751 invoked from network); 19 Nov 2014 11:11:45 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 11:11:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJBBbLH007772
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 11:11:38 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJBBbR9011796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 11:11:37 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJBBakQ008228; Wed, 19 Nov 2014 11:11:36 GMT
Received: from [IPv6:2607:fb90:2405:f91c:53f:5d67:f782:e915] (/172.56.34.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 03:11:36 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <546C797D.6040709@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com>
	<1416393024.29243.20.camel@citrix.com>
	<546C72F8.2020704@citrix.com>
	<1416393524.29243.21.camel@citrix.com>
	<1416393997.29243.22.camel@citrix.com> <546C7689.10406@citrix.com>
	<1416395092.29243.27.camel@citrix.com>
	<546C797D.6040709@citrix.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 19 Nov 2014 06:11:31 -0500
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <AC983992-3F1C-462A-AEF5-F57E9273F6B1@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 19, 2014 6:05:33 AM EST, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>On 19/11/14 11:04, Ian Campbell wrote:
>> On Wed, 2014-11-19 at 10:52 +0000, Andrew Cooper wrote:
>>> On 19/11/14 10:46, Ian Campbell wrote:
>>>> On Wed, 2014-11-19 at 10:38 +0000, Ian Campbell wrote:
>>>>> I've not been able to find a workaround...
>>>> This works for me...
>>>>
>>>> 8<---------------
>>>>
>>>> From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00
>2001
>>>> From: Ian Campbell <ian.campbell@citrix.com>
>>>> Date: Wed, 19 Nov 2014 10:42:18 +0000
>>>> Subject: [PATCH] docs: workaround markdown parser error in
>>>>  xen-command-line.markdown
>>>>
>>>> Some versions of markdown (specifically the one in Debian Wheezy,
>currently
>>>> used to generate
>>>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html)
>seem to be
>>>> confused by nested lists in the middle of multi-paragraph parent
>list entries
>>>> as seen in the com1,com2 entry.
>>>>
>>>> The effect is that the "Default" section of all following entries
>are replace
>>>> by some sort of hash or checksum (at least, a string of 32 random
>seeming hex
>>>> digits).
>>>>
>>>> Workaround this issue by making the decriptions of the DPS options
>a nested
>>>> list, moving the existing nested list describing the options for S
>into a third
>>>> level list. This seems to avoid the issue, and is arguably better
>formatting in
>>>> its own right (at least its not a regression IMHO)
>>>>
>>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>>> I had just identified a different way, but this way is slightly
>better.
>>>
>>> If you take out all the blank lines visible in the context below,
>the
>>> resulting HTML will be correctly formatted and rather neater (i.e.
>>> without sporadic blank lines).
>> Agreed.
>>
>> 8<------
>>
>> From 53398a9729d391f1fb7b6f753a0032b1f3604d4d Mon Sep 17 00:00:00
>2001
>> From: Ian Campbell <ian.campbell@citrix.com>
>> Date: Wed, 19 Nov 2014 10:42:18 +0000
>> Subject: [PATCH] docs: workaround markdown parser error in
>>  xen-command-line.markdown
>>
>> Some versions of markdown (specifically the one in Debian Wheezy,
>currently
>> used to generate
>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem
>to be
>> confused by nested lists in the middle of multi-paragraph parent list
>entries
>> as seen in the com1,com2 entry.
>>
>> The effect is that the "Default" section of all following entries are
>replace
>> by some sort of hash or checksum (at least, a string of 32 random
>seeming hex
>> digits).
>>
>> Workaround this issue by making the decriptions of the DPS options a
>nested
>> list, moving the existing nested list describing the options for S
>into a third
>> level list. This seems to avoid the issue, and is arguably better
>formatting in
>> its own right (at least its not a regression IMHO)
>>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
>Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Release-Acked-by: Konrad Rzeszutek Wilk (Konrad.wilk@oracle.com)

In case you were thinking of putting in 4.5
>
>> ---
>> v2: Less blank lines == nicer output.
>> ---
>>  docs/misc/xen-command-line.markdown |   21 ++++++++-------------
>>  1 file changed, 8 insertions(+), 13 deletions(-)
>>
>> diff --git a/docs/misc/xen-command-line.markdown
>b/docs/misc/xen-command-line.markdown
>> index 0830e5f..b7eaeea 100644
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -247,19 +247,14 @@ Both option `com1` and `com2` follow the same
>format.
>>  * Optionally, a clock speed measured in hz can be specified.
>>  * `DPS` represents the number of data bits, the parity, and the
>number
>>    of stop bits.
>> -
>> -  `D` is an integer between 5 and 8 for the number of data bits.
>> -
>> -  `P` is a single character representing the type of parity:
>> -
>> -   * `n` No
>> -   * `o` Odd
>> -   * `e` Even
>> -   * `m` Mark
>> -   * `s` Space
>> -
>> -  `S` is an integer 1 or 2 for the number of stop bits.
>> -
>> +  * `D` is an integer between 5 and 8 for the number of data bits.
>> +  * `P` is a single character representing the type of parity:
>> +      * `n` No
>> +      * `o` Odd
>> +      * `e` Even
>> +      * `m` Mark
>> +      * `s` Space
>> +  * `S` is an integer 1 or 2 for the number of stop bits.
>>  * `<io-base>` is an integer which specifies the IO base port for
>UART
>>    registers.
>>  * `<irq>` is the IRQ number to use, or `0` to use the UART in poll
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/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 Nov 19 11:11:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:11:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Ar-0001nZ-F7; Wed, 19 Nov 2014 11:11:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr3Ap-0001kJ-Cl
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:11:47 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	11/28-14214-2FA7C645; Wed, 19 Nov 2014 11:11:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416395503!6928141!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10751 invoked from network); 19 Nov 2014 11:11:45 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 11:11:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJBBbLH007772
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 11:11:38 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJBBbR9011796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 11:11:37 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJBBakQ008228; Wed, 19 Nov 2014 11:11:36 GMT
Received: from [IPv6:2607:fb90:2405:f91c:53f:5d67:f782:e915] (/172.56.34.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 03:11:36 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <546C797D.6040709@citrix.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com>
	<1416393024.29243.20.camel@citrix.com>
	<546C72F8.2020704@citrix.com>
	<1416393524.29243.21.camel@citrix.com>
	<1416393997.29243.22.camel@citrix.com> <546C7689.10406@citrix.com>
	<1416395092.29243.27.camel@citrix.com>
	<546C797D.6040709@citrix.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 19 Nov 2014 06:11:31 -0500
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <AC983992-3F1C-462A-AEF5-F57E9273F6B1@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 19, 2014 6:05:33 AM EST, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>On 19/11/14 11:04, Ian Campbell wrote:
>> On Wed, 2014-11-19 at 10:52 +0000, Andrew Cooper wrote:
>>> On 19/11/14 10:46, Ian Campbell wrote:
>>>> On Wed, 2014-11-19 at 10:38 +0000, Ian Campbell wrote:
>>>>> I've not been able to find a workaround...
>>>> This works for me...
>>>>
>>>> 8<---------------
>>>>
>>>> From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00
>2001
>>>> From: Ian Campbell <ian.campbell@citrix.com>
>>>> Date: Wed, 19 Nov 2014 10:42:18 +0000
>>>> Subject: [PATCH] docs: workaround markdown parser error in
>>>>  xen-command-line.markdown
>>>>
>>>> Some versions of markdown (specifically the one in Debian Wheezy,
>currently
>>>> used to generate
>>>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html)
>seem to be
>>>> confused by nested lists in the middle of multi-paragraph parent
>list entries
>>>> as seen in the com1,com2 entry.
>>>>
>>>> The effect is that the "Default" section of all following entries
>are replace
>>>> by some sort of hash or checksum (at least, a string of 32 random
>seeming hex
>>>> digits).
>>>>
>>>> Workaround this issue by making the decriptions of the DPS options
>a nested
>>>> list, moving the existing nested list describing the options for S
>into a third
>>>> level list. This seems to avoid the issue, and is arguably better
>formatting in
>>>> its own right (at least its not a regression IMHO)
>>>>
>>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>>> I had just identified a different way, but this way is slightly
>better.
>>>
>>> If you take out all the blank lines visible in the context below,
>the
>>> resulting HTML will be correctly formatted and rather neater (i.e.
>>> without sporadic blank lines).
>> Agreed.
>>
>> 8<------
>>
>> From 53398a9729d391f1fb7b6f753a0032b1f3604d4d Mon Sep 17 00:00:00
>2001
>> From: Ian Campbell <ian.campbell@citrix.com>
>> Date: Wed, 19 Nov 2014 10:42:18 +0000
>> Subject: [PATCH] docs: workaround markdown parser error in
>>  xen-command-line.markdown
>>
>> Some versions of markdown (specifically the one in Debian Wheezy,
>currently
>> used to generate
>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem
>to be
>> confused by nested lists in the middle of multi-paragraph parent list
>entries
>> as seen in the com1,com2 entry.
>>
>> The effect is that the "Default" section of all following entries are
>replace
>> by some sort of hash or checksum (at least, a string of 32 random
>seeming hex
>> digits).
>>
>> Workaround this issue by making the decriptions of the DPS options a
>nested
>> list, moving the existing nested list describing the options for S
>into a third
>> level list. This seems to avoid the issue, and is arguably better
>formatting in
>> its own right (at least its not a regression IMHO)
>>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
>Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Release-Acked-by: Konrad Rzeszutek Wilk (Konrad.wilk@oracle.com)

In case you were thinking of putting in 4.5
>
>> ---
>> v2: Less blank lines == nicer output.
>> ---
>>  docs/misc/xen-command-line.markdown |   21 ++++++++-------------
>>  1 file changed, 8 insertions(+), 13 deletions(-)
>>
>> diff --git a/docs/misc/xen-command-line.markdown
>b/docs/misc/xen-command-line.markdown
>> index 0830e5f..b7eaeea 100644
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -247,19 +247,14 @@ Both option `com1` and `com2` follow the same
>format.
>>  * Optionally, a clock speed measured in hz can be specified.
>>  * `DPS` represents the number of data bits, the parity, and the
>number
>>    of stop bits.
>> -
>> -  `D` is an integer between 5 and 8 for the number of data bits.
>> -
>> -  `P` is a single character representing the type of parity:
>> -
>> -   * `n` No
>> -   * `o` Odd
>> -   * `e` Even
>> -   * `m` Mark
>> -   * `s` Space
>> -
>> -  `S` is an integer 1 or 2 for the number of stop bits.
>> -
>> +  * `D` is an integer between 5 and 8 for the number of data bits.
>> +  * `P` is a single character representing the type of parity:
>> +      * `n` No
>> +      * `o` Odd
>> +      * `e` Even
>> +      * `m` Mark
>> +      * `s` Space
>> +  * `S` is an integer 1 or 2 for the number of stop bits.
>>  * `<io-base>` is an integer which specifies the IO base port for
>UART
>>    registers.
>>  * `<irq>` is the IRQ number to use, or `0` to use the UART in poll
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/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 Nov 19 11:11:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Ay-0001qt-4C; Wed, 19 Nov 2014 11:11:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr3Ax-0001pS-4X
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:11:55 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	21/C6-02953-AFA7C645; Wed, 19 Nov 2014 11:11:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416395512!13452435!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5919 invoked from network); 19 Nov 2014 11:11:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:11:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192823572"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:11:51 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr3At-0000E4-85;
	Wed, 19 Nov 2014 11:11:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr3As-00079l-BQ;
	Wed, 19 Nov 2014 11:11:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21612.31477.599956.73036@mariner.uk.xensource.com>
Date: Wed, 19 Nov 2014 11:11:49 +0000
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1416378851-32236-2-git-send-email-cyliu@suse.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<1416378851-32236-2-git-send-email-cyliu@suse.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2 V3] remove domain field in xenstore
	backend dir
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Chunyan Liu writes ("[PATCH 1/2 V3] remove domain field in xenstore backend dir"):
> Remove the unusual 'domain' field under backend directory. The
> affected are backend/console, backend/vfb, backend/vkbd.

Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:11:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Ay-0001qt-4C; Wed, 19 Nov 2014 11:11:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr3Ax-0001pS-4X
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:11:55 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	21/C6-02953-AFA7C645; Wed, 19 Nov 2014 11:11:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416395512!13452435!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5919 invoked from network); 19 Nov 2014 11:11:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:11:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192823572"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:11:51 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr3At-0000E4-85;
	Wed, 19 Nov 2014 11:11:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr3As-00079l-BQ;
	Wed, 19 Nov 2014 11:11:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21612.31477.599956.73036@mariner.uk.xensource.com>
Date: Wed, 19 Nov 2014 11:11:49 +0000
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1416378851-32236-2-git-send-email-cyliu@suse.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<1416378851-32236-2-git-send-email-cyliu@suse.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2 V3] remove domain field in xenstore
	backend dir
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Chunyan Liu writes ("[PATCH 1/2 V3] remove domain field in xenstore backend dir"):
> Remove the unusual 'domain' field under backend directory. The
> affected are backend/console, backend/vfb, backend/vkbd.

Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:12:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3BS-0001y5-JX; Wed, 19 Nov 2014 11:12:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr3BR-0001xh-8z
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:12:25 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	BA/E5-02957-81B7C645; Wed, 19 Nov 2014 11:12:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416395541!13447188!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29791 invoked from network); 19 Nov 2014 11:12:23 -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;
	19 Nov 2014 11:12:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192823665"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:12:21 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr3BM-0000EJ-OZ;
	Wed, 19 Nov 2014 11:12:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr3BL-00079u-RX;
	Wed, 19 Nov 2014 11:12:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21612.31507.512531.111279@mariner.uk.xensource.com>
Date: Wed, 19 Nov 2014 11:12:19 +0000
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1416378851-32236-3-git-send-email-cyliu@suse.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<1416378851-32236-3-git-send-email-cyliu@suse.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Chunyan Liu writes ("[PATCH 2/2 V3] fix rename: xenstore not fully updated"):
> libxl__domain_rename only updates /local/domain/<domid>/name,
> /vm/<uuid>/name in xenstore are not updated. Add code in
> libxl__domain_rename to update /vm/<uuid>/name too.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:12:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3BS-0001y5-JX; Wed, 19 Nov 2014 11:12:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr3BR-0001xh-8z
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:12:25 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	BA/E5-02957-81B7C645; Wed, 19 Nov 2014 11:12:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416395541!13447188!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29791 invoked from network); 19 Nov 2014 11:12:23 -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;
	19 Nov 2014 11:12:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192823665"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:12:21 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr3BM-0000EJ-OZ;
	Wed, 19 Nov 2014 11:12:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr3BL-00079u-RX;
	Wed, 19 Nov 2014 11:12:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21612.31507.512531.111279@mariner.uk.xensource.com>
Date: Wed, 19 Nov 2014 11:12:19 +0000
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1416378851-32236-3-git-send-email-cyliu@suse.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<1416378851-32236-3-git-send-email-cyliu@suse.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Chunyan Liu writes ("[PATCH 2/2 V3] fix rename: xenstore not fully updated"):
> libxl__domain_rename only updates /local/domain/<domid>/name,
> /vm/<uuid>/name in xenstore are not updated. Add code in
> libxl__domain_rename to update /vm/<uuid>/name too.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:12:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:12:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Bf-000226-0t; Wed, 19 Nov 2014 11:12:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr3Bd-00021S-DP
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:12:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2B/AB-25276-42B7C645; Wed, 19 Nov 2014 11:12:36 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416395554!13830975!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4061 invoked from network); 19 Nov 2014 11:12: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;
	19 Nov 2014 11:12:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192823699"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:12:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr3BW-0000EM-8E;
	Wed, 19 Nov 2014 11:12:30 +0000
Date: Wed, 19 Nov 2014 11:12:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> Thank you for your support.
> 
> You are right - with latest change you've proposed I got a continuous
> prints during platform hang:
> 
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> 
> Looks line issue needs further deeper debugging.

Cool! You could simply print what irqs are in all LRs when they are
full, for example you could call gic_dump_info. That would tell us what
is taking all the LRs space we have.

How many LRs are available on omap5 anyway?

I doubt you have so much interrupt traffic to actually fill all the LRs,
so I am thinking that a few LRs might not be cleared properly (that
should happen on hypervisor entry, gic_update_one_lr should take care of
it).


> Regards,
> Andrii
> 
> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > Hello Andrii,
> > we are getting closer :-)
> >
> > It would help if you post the output with GIC_DEBUG defined but without
> > the other change that "fixes" the issue.
> >
> > I think the problem is probably due to software irqs.
> > You are getting too many
> >
> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
> >
> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
> > VCPU). It would be best to investigate why, especially if you get many
> > more of the same messages without the MAINTENANCE_IRQ change I
> > suggested.
> >
> > This patch might also help understading the problem more:
> >
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index b7516c0..5eaeca2 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
> >      {
> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> > -        if ( i >= nr_lrs ) return;
> > +        if ( i >= nr_lrs )
> > +        {
> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
> > +            continue;
> > +        }
> >
> >          spin_lock_irqsave(&gic.lock, flags);
> >          gic_set_lr(i, p, GICH_LR_PENDING);
> >
> >
> >
> >
> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi Stefano,
> >>
> >> No hangs with this change.
> >> Complete log is the following:
> >>
> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> >> DRA752 ES1.0
> >> <ethaddr> not set. Validating first E-fuse MAC
> >> cpsw
> >> - UART enabled -
> >> - CPU 00000000 booting -
> >> - Xen starting in Hyp mode -
> >> - Zero BSS -
> >> - Setting up control registers -
> >> - Turning on paging -
> >> - Ready -
> >> (XEN) Checking for initrd in /chosen
> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> >> (XEN)
> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> >> (XEN)
> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> >> (XEN) Dom heap: 344064 pages
> >> (XEN) Domain heap initialised
> >> (XEN) Looking for UART console serial0
> >>  Xen 4.5-unstable
> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> >> (arm-linux-gnueabihf-gcc (crosstool-NG
> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> >> 20130328 (prerelease)) debu4
> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> >> (XEN) 32-bit Execution:
> >> (XEN)   Processor Features: 00001131:00011011
> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> >> (XEN)     Extensions: GenericTimer Security
> >> (XEN)   Debug Features: 02010555
> >> (XEN)   Auxiliary Features: 00000000
> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> >> (XEN) Platform: TI DRA7
> >> (XEN) /psci method must be smc, but is: "hvc"
> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> >> (XEN) Set AuxCoreBoot0 to 0x20
> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> >> (XEN) Using generic timer at 6144 KHz
> >> (XEN) GIC initialization:
> >> (XEN)         gic_dist_addr=0000000048211000
> >> (XEN)         gic_cpu_addr=0000000048212000
> >> (XEN)         gic_hyp_addr=0000000048214000
> >> (XEN)         gic_vcpu_addr=0000000048216000
> >> (XEN)         gic_maintenance_irq=25
> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> >> (XEN) I/O virtualisation disabled
> >> (XEN) Allocated console ring of 16 KiB.
> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> >> (XEN) Bringing up CPU1
> >> - CPU 00000001 booting -
> >> - Xen starting in Hyp mode -
> >> - Setting up control registers -
> >> - Turning on paging -
> >> - Ready -
> >> (XEN) CPU 1 booted.
> >> (XEN) Brought up 2 CPUs
> >> (XEN) *** LOADING DOMAIN 0 ***
> >> (XEN) Loading kernel from boot module 2
> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> >> (XEN) Std. Loglevel: All
> >> (XEN) Guest Loglevel: All
> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> >> input to Xen)
> >> (XEN) Freed 272kB init memory.
> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> already pending in LR0
> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> already pending in LR0
> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> >> /ocp/i2c@48072000/camera_ov10635
> >> [    0.437500] ldo3: operation not allowed
> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> >> [    0.468750] ov1063x 1-0030: No deserializer node found
> >> [    0.468750] ov1063x 1-0030: No serializer node found
> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> >> [    0.578125] ahci ahci.0.auto: can't get clock
> >> [    0.898437] ldc_module_init
> >> [    1.304687] Missing dual_emac_res_vlan in DT.
> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> >> [    1.312500] Missing dual_emac_res_vlan in DT.
> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> >> [    1.382812] Freeing init memory: 236K
> >> sh: write error: No such device
> >> Cannot identify '/dev/camera0': 2, No such file or directory
> >> Parsing config from /xen/images/DomUAndroid.cfg
> >> XSM Disabled: seclabel not supported
> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> dom1 access to irq 53: Function not implemented
> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> dom1 access to irq 71: Function not implemented
> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> dom1 access to irq 173: Function not implemented
> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> dom1 access to irq 174: Function not implemented
> >> Turning on vfb in domain 1
> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> still lr_pending
> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> still lr_pending
> >> Parsing config from /xen/images/DomUQNX.cfg
> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> >> inject irq=2 into d0v0, when it is still lr_pending
> >>
> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> still lr_pending
> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> >> found: Invalid kernel
> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> >> failed: No such file or directory
> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> >> (re-)build domain: -3
> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> still lr_pending
> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> still lr_pending
> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
> >> Turning on vkbd in domain 1
> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> still lr_pending
> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> still lr_pending
> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> still lr_pending
> >>
> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> >> trying to inject irq=2 into d0v0, when it is still lr_pending
> >>
> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> > OK got it. Give me a few mins
> >> >
> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> >> >>
> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> >> >> other potential bugs introduced later.
> >> >>
> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >>> What if I try on top of current master branch the following code:
> >> >>>
> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >>> index 31fb81a..6764ab7 100644
> >> >>> --- a/xen/arch/arm/gic-v2.c
> >> >>> +++ b/xen/arch/arm/gic-v2.c
> >> >>> @@ -36,6 +36,8 @@
> >> >>>  #include <asm/io.h>
> >> >>>  #include <asm/gic.h>
> >> >>>
> >> >>> +#define GIC_DEBUG 1
> >> >>> +
> >> >>>  /*
> >> >>>   * LR register definitions are GIC v2 specific.
> >> >>>   * Moved these definitions from header file to here
> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >>> index bcaded9..c03d6a6 100644
> >> >>> --- a/xen/arch/arm/gic.c
> >> >>> +++ b/xen/arch/arm/gic.c
> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> >> >>>
> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> >> >>> gic_hw_ops->info->nr_lrs) - 1))
> >> >>>
> >> >>> -#undef GIC_DEBUG
> >> >>> +#define GIC_DEBUG 1
> >> >>>
> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >>>
> >> >>> It is equivalent to what you proposing - my code contains
> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> >> >>> be executed:
> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> >> >>>
> >> >>> regards,
> >> >>> Andrii
> >> >>>
> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> >> >>> >> everything works fine
> >> >>> >> The following 2 patches fixes xen/master for my platform.
> >> >>> >>
> >> >>> >> Stefano, could you please take a look to these changes?
> >> >>> >>
> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> >> >>> >>
> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> >> >>> >>
> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >>> >>
> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >>> >> index 31fb81a..093ecdb 100644
> >> >>> >> --- a/xen/arch/arm/gic-v2.c
> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> >> >>> >> pending_irq *p,
> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> >> >>> >>
> >> >>> >> -    if ( p->desc != NULL )
> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >>> >>      {
> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >>> >> -        else
> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >>> >> +    }
> >> >>> >> +    else if ( p->desc != NULL )
> >> >>> >> +    {
> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >>> >>      }
> >> >>> >>
> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> >> >>> >
> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> >> >>> > working correctly on OMAP5. This changes might only be better at
> >> >>> > "hiding" the real issue.
> >> >>> >
> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> >> >>> > maintenance interrupts doesn't work for software interrupts.
> >> >>> > The commit that should make them work correctly after the
> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> >> >>> > Maybe that doesn't work correctly on OMAP5.
> >> >>> >
> >> >>> > Could you try this patch on top of
> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> >> >>> > if the problem is specifically with software irqs.
> >> >>> >
> >> >>> >
> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >>> > index b7516c0..d8a17c9 100644
> >> >>> > --- a/xen/arch/arm/gic.c
> >> >>> > +++ b/xen/arch/arm/gic.c
> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> >> >>> >  /* Maximum cpu interface per GIC */
> >> >>> >  #define NR_GIC_CPU_IF 8
> >> >>> >
> >> >>> > -#undef GIC_DEBUG
> >> >>> > +#define GIC_DEBUG 1
> >> >>> >
> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >>> >
> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >> >>> >      if ( p->desc != NULL )
> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> >> >>> > +    else
> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> >> >>> >
> >> >>> >      GICH[GICH_LR + lr] = lr_val;
> >> >>> >
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>>
> >> >>> Andrii Tseglytskyi | Embedded Dev
> >> >>> GlobalLogic
> >> >>> www.globallogic.com
> >> >>>
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > Andrii Tseglytskyi | Embedded Dev
> >> > GlobalLogic
> >> > www.globallogic.com
> >>
> >>
> >>
> >> --
> >>
> >> Andrii Tseglytskyi | Embedded Dev
> >> GlobalLogic
> >> www.globallogic.com
> >>
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:12:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:12:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Bf-000226-0t; Wed, 19 Nov 2014 11:12:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr3Bd-00021S-DP
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:12:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2B/AB-25276-42B7C645; Wed, 19 Nov 2014 11:12:36 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416395554!13830975!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4061 invoked from network); 19 Nov 2014 11:12: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;
	19 Nov 2014 11:12:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192823699"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:12:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr3BW-0000EM-8E;
	Wed, 19 Nov 2014 11:12:30 +0000
Date: Wed, 19 Nov 2014 11:12:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> Thank you for your support.
> 
> You are right - with latest change you've proposed I got a continuous
> prints during platform hang:
> 
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> 
> Looks line issue needs further deeper debugging.

Cool! You could simply print what irqs are in all LRs when they are
full, for example you could call gic_dump_info. That would tell us what
is taking all the LRs space we have.

How many LRs are available on omap5 anyway?

I doubt you have so much interrupt traffic to actually fill all the LRs,
so I am thinking that a few LRs might not be cleared properly (that
should happen on hypervisor entry, gic_update_one_lr should take care of
it).


> Regards,
> Andrii
> 
> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > Hello Andrii,
> > we are getting closer :-)
> >
> > It would help if you post the output with GIC_DEBUG defined but without
> > the other change that "fixes" the issue.
> >
> > I think the problem is probably due to software irqs.
> > You are getting too many
> >
> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
> >
> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
> > VCPU). It would be best to investigate why, especially if you get many
> > more of the same messages without the MAINTENANCE_IRQ change I
> > suggested.
> >
> > This patch might also help understading the problem more:
> >
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index b7516c0..5eaeca2 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
> >      {
> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> > -        if ( i >= nr_lrs ) return;
> > +        if ( i >= nr_lrs )
> > +        {
> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
> > +            continue;
> > +        }
> >
> >          spin_lock_irqsave(&gic.lock, flags);
> >          gic_set_lr(i, p, GICH_LR_PENDING);
> >
> >
> >
> >
> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi Stefano,
> >>
> >> No hangs with this change.
> >> Complete log is the following:
> >>
> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> >> DRA752 ES1.0
> >> <ethaddr> not set. Validating first E-fuse MAC
> >> cpsw
> >> - UART enabled -
> >> - CPU 00000000 booting -
> >> - Xen starting in Hyp mode -
> >> - Zero BSS -
> >> - Setting up control registers -
> >> - Turning on paging -
> >> - Ready -
> >> (XEN) Checking for initrd in /chosen
> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> >> (XEN)
> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> >> (XEN)
> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> >> (XEN) Dom heap: 344064 pages
> >> (XEN) Domain heap initialised
> >> (XEN) Looking for UART console serial0
> >>  Xen 4.5-unstable
> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> >> (arm-linux-gnueabihf-gcc (crosstool-NG
> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> >> 20130328 (prerelease)) debu4
> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> >> (XEN) 32-bit Execution:
> >> (XEN)   Processor Features: 00001131:00011011
> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> >> (XEN)     Extensions: GenericTimer Security
> >> (XEN)   Debug Features: 02010555
> >> (XEN)   Auxiliary Features: 00000000
> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> >> (XEN) Platform: TI DRA7
> >> (XEN) /psci method must be smc, but is: "hvc"
> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> >> (XEN) Set AuxCoreBoot0 to 0x20
> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> >> (XEN) Using generic timer at 6144 KHz
> >> (XEN) GIC initialization:
> >> (XEN)         gic_dist_addr=0000000048211000
> >> (XEN)         gic_cpu_addr=0000000048212000
> >> (XEN)         gic_hyp_addr=0000000048214000
> >> (XEN)         gic_vcpu_addr=0000000048216000
> >> (XEN)         gic_maintenance_irq=25
> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> >> (XEN) I/O virtualisation disabled
> >> (XEN) Allocated console ring of 16 KiB.
> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> >> (XEN) Bringing up CPU1
> >> - CPU 00000001 booting -
> >> - Xen starting in Hyp mode -
> >> - Setting up control registers -
> >> - Turning on paging -
> >> - Ready -
> >> (XEN) CPU 1 booted.
> >> (XEN) Brought up 2 CPUs
> >> (XEN) *** LOADING DOMAIN 0 ***
> >> (XEN) Loading kernel from boot module 2
> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> >> (XEN) Std. Loglevel: All
> >> (XEN) Guest Loglevel: All
> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> >> input to Xen)
> >> (XEN) Freed 272kB init memory.
> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> already pending in LR0
> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> already pending in LR0
> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> >> /ocp/i2c@48072000/camera_ov10635
> >> [    0.437500] ldo3: operation not allowed
> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> >> [    0.468750] ov1063x 1-0030: No deserializer node found
> >> [    0.468750] ov1063x 1-0030: No serializer node found
> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> >> [    0.578125] ahci ahci.0.auto: can't get clock
> >> [    0.898437] ldc_module_init
> >> [    1.304687] Missing dual_emac_res_vlan in DT.
> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> >> [    1.312500] Missing dual_emac_res_vlan in DT.
> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> >> [    1.382812] Freeing init memory: 236K
> >> sh: write error: No such device
> >> Cannot identify '/dev/camera0': 2, No such file or directory
> >> Parsing config from /xen/images/DomUAndroid.cfg
> >> XSM Disabled: seclabel not supported
> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> dom1 access to irq 53: Function not implemented
> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> dom1 access to irq 71: Function not implemented
> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> dom1 access to irq 173: Function not implemented
> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> dom1 access to irq 174: Function not implemented
> >> Turning on vfb in domain 1
> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> still lr_pending
> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> still lr_pending
> >> Parsing config from /xen/images/DomUQNX.cfg
> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> >> inject irq=2 into d0v0, when it is still lr_pending
> >>
> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> still lr_pending
> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> >> found: Invalid kernel
> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> >> failed: No such file or directory
> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> >> (re-)build domain: -3
> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> still lr_pending
> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> still lr_pending
> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
> >> Turning on vkbd in domain 1
> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> still lr_pending
> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> still lr_pending
> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> still lr_pending
> >>
> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> >> trying to inject irq=2 into d0v0, when it is still lr_pending
> >>
> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> > OK got it. Give me a few mins
> >> >
> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> >> >>
> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> >> >> other potential bugs introduced later.
> >> >>
> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >>> What if I try on top of current master branch the following code:
> >> >>>
> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >>> index 31fb81a..6764ab7 100644
> >> >>> --- a/xen/arch/arm/gic-v2.c
> >> >>> +++ b/xen/arch/arm/gic-v2.c
> >> >>> @@ -36,6 +36,8 @@
> >> >>>  #include <asm/io.h>
> >> >>>  #include <asm/gic.h>
> >> >>>
> >> >>> +#define GIC_DEBUG 1
> >> >>> +
> >> >>>  /*
> >> >>>   * LR register definitions are GIC v2 specific.
> >> >>>   * Moved these definitions from header file to here
> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >>> index bcaded9..c03d6a6 100644
> >> >>> --- a/xen/arch/arm/gic.c
> >> >>> +++ b/xen/arch/arm/gic.c
> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> >> >>>
> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> >> >>> gic_hw_ops->info->nr_lrs) - 1))
> >> >>>
> >> >>> -#undef GIC_DEBUG
> >> >>> +#define GIC_DEBUG 1
> >> >>>
> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >>>
> >> >>> It is equivalent to what you proposing - my code contains
> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> >> >>> be executed:
> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> >> >>>
> >> >>> regards,
> >> >>> Andrii
> >> >>>
> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> >> >>> >> everything works fine
> >> >>> >> The following 2 patches fixes xen/master for my platform.
> >> >>> >>
> >> >>> >> Stefano, could you please take a look to these changes?
> >> >>> >>
> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> >> >>> >>
> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> >> >>> >>
> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >>> >>
> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >>> >> index 31fb81a..093ecdb 100644
> >> >>> >> --- a/xen/arch/arm/gic-v2.c
> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> >> >>> >> pending_irq *p,
> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> >> >>> >>
> >> >>> >> -    if ( p->desc != NULL )
> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >>> >>      {
> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >>> >> -        else
> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >>> >> +    }
> >> >>> >> +    else if ( p->desc != NULL )
> >> >>> >> +    {
> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >>> >>      }
> >> >>> >>
> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> >> >>> >
> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> >> >>> > working correctly on OMAP5. This changes might only be better at
> >> >>> > "hiding" the real issue.
> >> >>> >
> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> >> >>> > maintenance interrupts doesn't work for software interrupts.
> >> >>> > The commit that should make them work correctly after the
> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> >> >>> > Maybe that doesn't work correctly on OMAP5.
> >> >>> >
> >> >>> > Could you try this patch on top of
> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> >> >>> > if the problem is specifically with software irqs.
> >> >>> >
> >> >>> >
> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >>> > index b7516c0..d8a17c9 100644
> >> >>> > --- a/xen/arch/arm/gic.c
> >> >>> > +++ b/xen/arch/arm/gic.c
> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> >> >>> >  /* Maximum cpu interface per GIC */
> >> >>> >  #define NR_GIC_CPU_IF 8
> >> >>> >
> >> >>> > -#undef GIC_DEBUG
> >> >>> > +#define GIC_DEBUG 1
> >> >>> >
> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >>> >
> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >> >>> >      if ( p->desc != NULL )
> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> >> >>> > +    else
> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> >> >>> >
> >> >>> >      GICH[GICH_LR + lr] = lr_val;
> >> >>> >
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>>
> >> >>> Andrii Tseglytskyi | Embedded Dev
> >> >>> GlobalLogic
> >> >>> www.globallogic.com
> >> >>>
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > Andrii Tseglytskyi | Embedded Dev
> >> > GlobalLogic
> >> > www.globallogic.com
> >>
> >>
> >>
> >> --
> >>
> >> Andrii Tseglytskyi | Embedded Dev
> >> GlobalLogic
> >> www.globallogic.com
> >>
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Fk-0002Tr-SS; Wed, 19 Nov 2014 11:16:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1Xr3Fh-0002TZ-Pg
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 11:16:50 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	7B/22-31453-02C7C645; Wed, 19 Nov 2014 11:16:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416395807!12195392!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24559 invoked from network); 19 Nov 2014 11:16:47 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 19 Nov 2014 11:16:47 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54332 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xr3E7-0001jX-1L; Wed, 19 Nov 2014 12:15:11 +0100
Date: Wed, 19 Nov 2014 12:16:44 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <996703854.20141119121644@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141119015541.GA10307@laptop.dumpdata.com>
References: <1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<20141118205633.GB6540@laptop.dumpdata.com>
	<348130555.20141118231254@eikelenboom.it>
	<20141119015541.GA10307@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, November 19, 2014, 2:55:41 AM, you wrote:

> On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
>> 
>> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
>> 
>> >> 
>> >> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
>> >> about them .. however looking at the earlier reports these lines were also in 
>> >> those reports).
>> >> 
>> >> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
>> >> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
>> >> and had a new default seabios config. (just to rule out anything stale in my tree)
>> >> 
>> >> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
>> >> seabios config) are not the most recent (they don't get updated automatically 
>> >> when you just do a git pull on the main tree) ?
>> >> 
>> >> In /tools/firmware/seabios-dir/.config i have:
>> >> CONFIG_USB=y
>> >> CONFIG_USB_UHCI=y
>> >> CONFIG_USB_OHCI=y
>> >> CONFIG_USB_EHCI=y
>> >> CONFIG_USB_XHCI=y
>> >> CONFIG_USB_MSC=y
>> >> CONFIG_USB_UAS=y
>> >> CONFIG_USB_HUB=y
>> >> CONFIG_USB_KEYBOARD=y
>> >> CONFIG_USB_MOUSE=y
>> >> 
>> 
>> > I seem to have the same thing. Perhaps it is my XHCI controller being wonky.
>> 
>> >> And this is all just from a:
>> >> - git clone git://xenbits.xen.org/xen.git -b staging
>> >> - make clean && ./configure && make -j6 && make -j6 install
>> 
>> > Aye. 
>> > .. snip..
>> >> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
>> >> >     [But this might be invalid as the addition of the ffff8303faaf25a8
>> >> >      might be correct - as the second dpci the softirq is processing
>> >> >      could be the MSI one]
>> >> 
>> >> Would there be an easy way to stress test this function separately in some 
>> >> debugging function to see if it indeed is returning unexpected values ?
>> 
>> > Sadly no. But you got me looking in the right direction when you mentioned
>> > 'timeout'.
>> >> 
>> >> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
>> >> 
>> >> Just curious, have you also tested the patches on AMD hardware ?
>> 
>> > Yes. To reproduce this the first thing I did was to get an AMD box.
>> 
>> >> 
>> >>  
>> >> >> When i look at the combination of (2) and (3), It seems it could be an 
>> >> >> interaction between the two passed through devices and/or different IRQ types.
>> >> 
>> >> > Could be - as in it is causing this issue to show up faster than
>> >> > expected. Or it is the one that triggers more than one dpci happening
>> >> > at the same time.
>> >> 
>> >> Well that didn't seem to be it (see separate amendment i mailed previously)
>> 
>> > Right, the current theory I've is that the interrupts are not being
>> > Acked within 8 milisecond and we reset the 'state' - and at the same
>> > time we get an interrupt and schedule it - while we are still processing
>> > the same interrupt. This would explain why the 'test_and_clear_bit'
>> > got the wrong value.
>> 
>> > In regards to the list poison - following this thread of logic - with
>> > the 'state = 0' set we open the floodgates for any CPU to put the same
>> > 'struct hvm_pirq_dpci' on its list.
>> 
>> > We do reset the 'state' on _every_ GSI that is mapped to a guest - so
>> > we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:
>> 
>> > CPUX:                           CPUY:
>> > pt_irq_time_out:
>> > state = 0;                      
>> > [out of timer coder, the                raise_softirq
>> >  pirq_dpci is on the dpci_list]         [adds the pirq_dpci as state == 0]
>> 
>> > softirq_dpci                            softirq_dpci:
>> >         list_del
>> >         [entries poison]
>> >                                                 list_del <= BOOM
>> >                         
>> > Is what I believe is happening.
>> 
>> > The INTX device - once I put a load on it - does not trigger
>> > any pt_irq_time_out, so that would explain why I cannot hit this.
>> 
>> > But I believe your card hits these "hiccups".   
>> 
>> 
>> Hi Konrad,
>> 
>> I just tested you 5 patches and as a result i still got an(other) host crash:
>> (complete serial log attached)
>> 
>> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> (XEN) [2014-11-18 21:55:41.591] CPU:    0
>> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08012c7e7>]CPU:    2
>> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
>> (XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010006    _spin_unlock+0x1f/0x30CONTEXT: hypervisor

> Duh!

> Here is another patch on top of the five you have (attached and inline).

Hi Konrad,

Happy to report it has been running with this additional patch for 2 hours now 
without any problems. I think you nailed it :-)
More than happy to test the definitive patch as well.

--
Sander

> From 18008650f10199e2b83f74394f634a97086e34b8 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Tue, 18 Nov 2014 20:48:43 -0500
> Subject: [PATCH] debug: Whether we want to clear the 'dom' field or not when
>  changing the 'state' bit.

> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  xen/drivers/passthrough/io.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)

> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index aad5607..24e2bd6 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -243,13 +243,14 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
>  }
>  
>  /*
> - * Reset the pirq_dpci->dom parameter to NULL.
> + * Reset the pirq_dpci->dom parameter to NULL if 'clear_dom' is set.
>   *
>   * This function checks the different states to make sure it can do it
>   * at the right time. If it unschedules the 'hvm_dirq_assist' from running
>   * it also refcounts (which is what the softirq would have done) properly.
>   */
> -static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci,
> +                                  unsigned int clear_dom)
>  {
>      struct domain *d = pirq_dpci->dom;
>      struct __debug *debug = &__get_cpu_var(_d);
> @@ -276,7 +277,8 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
>           * in local variable before it sets STATE_RUN - and therefore will not
>           * dereference '->dom' which would crash.
>           */
-        pirq_dpci->>dom = NULL;
> +        if (clear_dom)
> +            pirq_dpci->dom = NULL;
>          break;
>      }
>  }
> @@ -295,7 +297,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
>                                &pirq_dpci->flags) )
>      {
>          _record(&debug->clear, pirq_dpci);
> -        pt_pirq_softirq_reset(pirq_dpci);
> +        pt_pirq_softirq_reset(pirq_dpci, 0 /* leave ->dom /);
>          /* pirq_dpci->state = 0; <= OUCH! */
>          pirq_dpci->pending = 0;
>          pirq_guest_eoi(dpci_pirq(pirq_dpci));
> @@ -333,9 +335,11 @@ static void pt_irq_time_out(void *data)
>      pt_pirq_iterate(irq_map->dom, pt_irq_guest_eoi, NULL);
>  
>      spin_unlock(&irq_map->dom->event_lock);
> +#if 0
>      console_start_sync();
>      dump_debug((char)0);
>      console_end_sync();
> +#endif
>  }
>  
>  struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *d)
> @@ -446,7 +450,7 @@ int pt_irq_create_bind(
>                       * in the queue.
>                       */
>                      pirq_dpci->line = __LINE__;
> -                    pt_pirq_softirq_reset(pirq_dpci);
> +                    pt_pirq_softirq_reset(pirq_dpci, 1 /* clear dom */);
>                  }
>              }
>              if ( unlikely(rc) )
> @@ -701,7 +705,7 @@ int pt_irq_destroy_bind(
>           * call to pt_pirq_softirq_reset.
>           */
>          pirq_dpci->line = __LINE__;
> -        pt_pirq_softirq_reset(pirq_dpci);
> +        pt_pirq_softirq_reset(pirq_dpci, 1 /* clear ->dom */);
>  
>          pirq_cleanup_check(pirq, d);
>      }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Fi-0002Te-35; Wed, 19 Nov 2014 11:16:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr3Fg-0002TX-Lr
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:16:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	67/93-02696-02C7C645; Wed, 19 Nov 2014 11:16:48 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416395804!13483258!1
X-Originating-IP: [64.18.0.188]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20204 invoked from network); 19 Nov 2014 11:16:45 -0000
Received: from exprod5og109.obsmtp.com (HELO exprod5og109.obsmtp.com)
	(64.18.0.188)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 11:16:45 -0000
Received: from mail-qg0-f41.google.com ([209.85.192.41]) (using TLSv1) by
	exprod5ob109.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGx8G3bsEj4GdyxkxjZQImksKFzXqBl7@postini.com;
	Wed, 19 Nov 2014 03:16:45 PST
Received: by mail-qg0-f41.google.com with SMTP id j5so218362qga.0
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 03:16:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=gI9Klx6bn8lItwnLBjBBUrP4PpLHKVAJl4Vn5AGwq3k=;
	b=YBEGb1ajsDycUBSEEQFUgG8eL+5wV8WbjZLz1Bnd1AyZ77MXc6JWvDdXAGds8dtEzS
	ARHe/MehSvtQuCwnY97qIY4J6PHE3BSuXQE6tZTvIBVMnNtHpVwbQUd24OtcQX/A0t2z
	dzLD5RksDkz2Rbm/it2KK58+0CcWPuiJCfM/o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=gI9Klx6bn8lItwnLBjBBUrP4PpLHKVAJl4Vn5AGwq3k=;
	b=TyAzUzi5APKwd0Z9lNZTThAXXI0pRfCI8mIKpMonk1LWh8jhw18rhACFkz60YNBDno
	3TvtaOLwj4wQWOU4Ib03OnVMZ05c/ySO8A0F50H+Bd5kVMEgxJNLk1Es6btGuFrK6yl4
	rZQFm4zBJMhaRH+7NjCRmAYp1GnPHeEtj4bbVb+MH8ywbDMjzziMjOmfulVKiC4PPKPs
	yNK6xKqbFp0u1SK+7onOlVPaz4525CgvWVnFnZGR57VqTqbNQuIH+BILO5+OympFZNoJ
	vKLSxWfR3ChItPZUqZ4vSQl3QByRk/NM9dM0ucrXcsf/xRdyBQXtJU5hyyaWAaFW2oxS
	DKfg==
X-Gm-Message-State: ALoCoQkUdntnN4xHHCUq8dy5Q4MuubKobS012ZntDJkMGtopKXUDa4dHJQn31Z5NXva1C7qzBA5PylKXOzjlxPneOXG6BtOuGoAnu4cBn8xBN/p/Pypn13GdEIAVFMUwsB3fd6e3NaloQk2GYDJTq3mK96jWq9v3nQ==
X-Received: by 10.140.105.37 with SMTP id b34mr50626117qgf.91.1416395803136;
	Wed, 19 Nov 2014 03:16:43 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.105.37 with SMTP id b34mr50626100qgf.91.1416395802999;
	Wed, 19 Nov 2014 03:16:42 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 03:16:42 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 13:16:42 +0200
Message-ID: <CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> Thank you for your support.
>>
>> You are right - with latest change you've proposed I got a continuous
>> prints during platform hang:
>>
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>>
>> Looks line issue needs further deeper debugging.
>
> Cool! You could simply print what irqs are in all LRs when they are
> full, for example you could call gic_dump_info. That would tell us what
> is taking all the LRs space we have.
>
> How many LRs are available on omap5 anyway?

:) Already done this:


(XEN) gic.c:725:d0v0 LRs full, not injecting irq=27 nr_lrs 4 i 4 into d0v0
(XEN) GICH_LRs (vcpu 0) mask=f
(XEN)    HW_LR[0]=1a00001f
(XEN)    HW_LR[1]=9a00e439
(XEN)    HW_LR[2]=1a000002
(XEN)    HW_LR[3]=9a015856
(XEN) Inflight irq=31 lr=0
(XEN) Inflight irq=57 lr=1
(XEN) Inflight irq=2 lr=2
(XEN) Inflight irq=86 lr=3
(XEN) Inflight irq=27 lr=255
(XEN) Pending irq=27


>
> I doubt you have so much interrupt traffic to actually fill all the LRs,
> so I am thinking that a few LRs might not be cleared properly (that
> should happen on hypervisor entry, gic_update_one_lr should take care of
> it).

This actually explains why this happens during domU start - SGI
traffic might be very heavy this time

>
>
>> Regards,
>> Andrii
>>
>> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > Hello Andrii,
>> > we are getting closer :-)
>> >
>> > It would help if you post the output with GIC_DEBUG defined but without
>> > the other change that "fixes" the issue.
>> >
>> > I think the problem is probably due to software irqs.
>> > You are getting too many
>> >
>> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
>> >
>> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
>> > VCPU). It would be best to investigate why, especially if you get many
>> > more of the same messages without the MAINTENANCE_IRQ change I
>> > suggested.
>> >
>> > This patch might also help understading the problem more:
>> >
>> >
>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> > index b7516c0..5eaeca2 100644
>> > --- a/xen/arch/arm/gic.c
>> > +++ b/xen/arch/arm/gic.c
>> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
>> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
>> >      {
>> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
>> > -        if ( i >= nr_lrs ) return;
>> > +        if ( i >= nr_lrs )
>> > +        {
>> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
>> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
>> > +            continue;
>> > +        }
>> >
>> >          spin_lock_irqsave(&gic.lock, flags);
>> >          gic_set_lr(i, p, GICH_LR_PENDING);
>> >
>> >
>> >
>> >
>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi Stefano,
>> >>
>> >> No hangs with this change.
>> >> Complete log is the following:
>> >>
>> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
>> >> DRA752 ES1.0
>> >> <ethaddr> not set. Validating first E-fuse MAC
>> >> cpsw
>> >> - UART enabled -
>> >> - CPU 00000000 booting -
>> >> - Xen starting in Hyp mode -
>> >> - Zero BSS -
>> >> - Setting up control registers -
>> >> - Turning on paging -
>> >> - Ready -
>> >> (XEN) Checking for initrd in /chosen
>> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
>> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
>> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
>> >> (XEN)
>> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
>> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
>> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
>> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
>> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
>> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
>> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
>> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
>> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
>> >> (XEN)
>> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
>> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
>> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
>> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
>> >> (XEN) Dom heap: 344064 pages
>> >> (XEN) Domain heap initialised
>> >> (XEN) Looking for UART console serial0
>> >>  Xen 4.5-unstable
>> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
>> >> (arm-linux-gnueabihf-gcc (crosstool-NG
>> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
>> >> 20130328 (prerelease)) debu4
>> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
>> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
>> >> (XEN) 32-bit Execution:
>> >> (XEN)   Processor Features: 00001131:00011011
>> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
>> >> (XEN)     Extensions: GenericTimer Security
>> >> (XEN)   Debug Features: 02010555
>> >> (XEN)   Auxiliary Features: 00000000
>> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
>> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
>> >> (XEN) Platform: TI DRA7
>> >> (XEN) /psci method must be smc, but is: "hvc"
>> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
>> >> (XEN) Set AuxCoreBoot0 to 0x20
>> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
>> >> (XEN) Using generic timer at 6144 KHz
>> >> (XEN) GIC initialization:
>> >> (XEN)         gic_dist_addr=0000000048211000
>> >> (XEN)         gic_cpu_addr=0000000048212000
>> >> (XEN)         gic_hyp_addr=0000000048214000
>> >> (XEN)         gic_vcpu_addr=0000000048216000
>> >> (XEN)         gic_maintenance_irq=25
>> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
>> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> >> (XEN) I/O virtualisation disabled
>> >> (XEN) Allocated console ring of 16 KiB.
>> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
>> >> (XEN) Bringing up CPU1
>> >> - CPU 00000001 booting -
>> >> - Xen starting in Hyp mode -
>> >> - Setting up control registers -
>> >> - Turning on paging -
>> >> - Ready -
>> >> (XEN) CPU 1 booted.
>> >> (XEN) Brought up 2 CPUs
>> >> (XEN) *** LOADING DOMAIN 0 ***
>> >> (XEN) Loading kernel from boot module 2
>> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
>> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
>> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
>> >> (XEN) Std. Loglevel: All
>> >> (XEN) Guest Loglevel: All
>> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
>> >> input to Xen)
>> >> (XEN) Freed 272kB init memory.
>> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> >> already pending in LR0
>> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> >> already pending in LR0
>> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
>> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
>> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
>> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
>> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
>> >> /ocp/i2c@48072000/camera_ov10635
>> >> [    0.437500] ldo3: operation not allowed
>> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
>> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
>> >> [    0.468750] ov1063x 1-0030: No deserializer node found
>> >> [    0.468750] ov1063x 1-0030: No serializer node found
>> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
>> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
>> >> [    0.578125] ahci ahci.0.auto: can't get clock
>> >> [    0.898437] ldc_module_init
>> >> [    1.304687] Missing dual_emac_res_vlan in DT.
>> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
>> >> [    1.312500] Missing dual_emac_res_vlan in DT.
>> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
>> >> [    1.382812] Freeing init memory: 236K
>> >> sh: write error: No such device
>> >> Cannot identify '/dev/camera0': 2, No such file or directory
>> >> Parsing config from /xen/images/DomUAndroid.cfg
>> >> XSM Disabled: seclabel not supported
>> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> dom1 access to irq 53: Function not implemented
>> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> dom1 access to irq 71: Function not implemented
>> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> dom1 access to irq 173: Function not implemented
>> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> dom1 access to irq 174: Function not implemented
>> >> Turning on vfb in domain 1
>> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> still lr_pending
>> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> still lr_pending
>> >> Parsing config from /xen/images/DomUQNX.cfg
>> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
>> >> inject irq=2 into d0v0, when it is still lr_pending
>> >>
>> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> still lr_pending
>> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
>> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
>> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
>> >> found: Invalid kernel
>> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
>> >> failed: No such file or directory
>> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
>> >> (re-)build domain: -3
>> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> still lr_pending
>> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> still lr_pending
>> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
>> >> Turning on vkbd in domain 1
>> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> still lr_pending
>> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> still lr_pending
>> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> still lr_pending
>> >>
>> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
>> >> trying to inject irq=2 into d0v0, when it is still lr_pending
>> >>
>> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
>> >> <andrii.tseglytskyi@globallogic.com> wrote:
>> >> > OK got it. Give me a few mins
>> >> >
>> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
>> >> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
>> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
>> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
>> >> >>
>> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
>> >> >> other potential bugs introduced later.
>> >> >>
>> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >>> What if I try on top of current master branch the following code:
>> >> >>>
>> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >> >>> index 31fb81a..6764ab7 100644
>> >> >>> --- a/xen/arch/arm/gic-v2.c
>> >> >>> +++ b/xen/arch/arm/gic-v2.c
>> >> >>> @@ -36,6 +36,8 @@
>> >> >>>  #include <asm/io.h>
>> >> >>>  #include <asm/gic.h>
>> >> >>>
>> >> >>> +#define GIC_DEBUG 1
>> >> >>> +
>> >> >>>  /*
>> >> >>>   * LR register definitions are GIC v2 specific.
>> >> >>>   * Moved these definitions from header file to here
>> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >>> index bcaded9..c03d6a6 100644
>> >> >>> --- a/xen/arch/arm/gic.c
>> >> >>> +++ b/xen/arch/arm/gic.c
>> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
>> >> >>>
>> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
>> >> >>> gic_hw_ops->info->nr_lrs) - 1))
>> >> >>>
>> >> >>> -#undef GIC_DEBUG
>> >> >>> +#define GIC_DEBUG 1
>> >> >>>
>> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
>> >> >>>
>> >> >>> It is equivalent to what you proposing - my code contains
>> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
>> >> >>> be executed:
>> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
>> >> >>>
>> >> >>> regards,
>> >> >>> Andrii
>> >> >>>
>> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
>> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>> >> >>> >> everything works fine
>> >> >>> >> The following 2 patches fixes xen/master for my platform.
>> >> >>> >>
>> >> >>> >> Stefano, could you please take a look to these changes?
>> >> >>> >>
>> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
>> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
>> >> >>> >>
>> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>> >> >>> >>
>> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >> >>> >>
>> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >> >>> >> index 31fb81a..093ecdb 100644
>> >> >>> >> --- a/xen/arch/arm/gic-v2.c
>> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
>> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>> >> >>> >> pending_irq *p,
>> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
>> >> >>> >>
>> >> >>> >> -    if ( p->desc != NULL )
>> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >> >>> >>      {
>> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> >>> >> -        else
>> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
>> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> >>> >> +    }
>> >> >>> >> +    else if ( p->desc != NULL )
>> >> >>> >> +    {
>> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>> >> >>> >>      }
>> >> >>> >>
>> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
>> >> >>> >
>> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
>> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
>> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
>> >> >>> > working correctly on OMAP5. This changes might only be better at
>> >> >>> > "hiding" the real issue.
>> >> >>> >
>> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
>> >> >>> > maintenance interrupts doesn't work for software interrupts.
>> >> >>> > The commit that should make them work correctly after the
>> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
>> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
>> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
>> >> >>> > Maybe that doesn't work correctly on OMAP5.
>> >> >>> >
>> >> >>> > Could you try this patch on top of
>> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
>> >> >>> > if the problem is specifically with software irqs.
>> >> >>> >
>> >> >>> >
>> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >>> > index b7516c0..d8a17c9 100644
>> >> >>> > --- a/xen/arch/arm/gic.c
>> >> >>> > +++ b/xen/arch/arm/gic.c
>> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>> >> >>> >  /* Maximum cpu interface per GIC */
>> >> >>> >  #define NR_GIC_CPU_IF 8
>> >> >>> >
>> >> >>> > -#undef GIC_DEBUG
>> >> >>> > +#define GIC_DEBUG 1
>> >> >>> >
>> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
>> >> >>> >
>> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>> >> >>> >      if ( p->desc != NULL )
>> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>> >> >>> > +    else
>> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>> >> >>> >
>> >> >>> >      GICH[GICH_LR + lr] = lr_val;
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>>
>> >> >>> Andrii Tseglytskyi | Embedded Dev
>> >> >>> GlobalLogic
>> >> >>> www.globallogic.com
>> >> >>>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> >
>> >> > Andrii Tseglytskyi | Embedded Dev
>> >> > GlobalLogic
>> >> > www.globallogic.com
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Andrii Tseglytskyi | Embedded Dev
>> >> GlobalLogic
>> >> www.globallogic.com
>> >>
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Fk-0002Tr-SS; Wed, 19 Nov 2014 11:16:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1Xr3Fh-0002TZ-Pg
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 11:16:50 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	7B/22-31453-02C7C645; Wed, 19 Nov 2014 11:16:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416395807!12195392!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24559 invoked from network); 19 Nov 2014 11:16:47 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 19 Nov 2014 11:16:47 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54332 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xr3E7-0001jX-1L; Wed, 19 Nov 2014 12:15:11 +0100
Date: Wed, 19 Nov 2014 12:16:44 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <996703854.20141119121644@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141119015541.GA10307@laptop.dumpdata.com>
References: <1403873666.20141117180419@eikelenboom.it>
	<20141117204347.GA27617@laptop.dumpdata.com>
	<1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<20141118205633.GB6540@laptop.dumpdata.com>
	<348130555.20141118231254@eikelenboom.it>
	<20141119015541.GA10307@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, November 19, 2014, 2:55:41 AM, you wrote:

> On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
>> 
>> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
>> 
>> >> 
>> >> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
>> >> about them .. however looking at the earlier reports these lines were also in 
>> >> those reports).
>> >> 
>> >> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
>> >> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
>> >> and had a new default seabios config. (just to rule out anything stale in my tree)
>> >> 
>> >> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
>> >> seabios config) are not the most recent (they don't get updated automatically 
>> >> when you just do a git pull on the main tree) ?
>> >> 
>> >> In /tools/firmware/seabios-dir/.config i have:
>> >> CONFIG_USB=y
>> >> CONFIG_USB_UHCI=y
>> >> CONFIG_USB_OHCI=y
>> >> CONFIG_USB_EHCI=y
>> >> CONFIG_USB_XHCI=y
>> >> CONFIG_USB_MSC=y
>> >> CONFIG_USB_UAS=y
>> >> CONFIG_USB_HUB=y
>> >> CONFIG_USB_KEYBOARD=y
>> >> CONFIG_USB_MOUSE=y
>> >> 
>> 
>> > I seem to have the same thing. Perhaps it is my XHCI controller being wonky.
>> 
>> >> And this is all just from a:
>> >> - git clone git://xenbits.xen.org/xen.git -b staging
>> >> - make clean && ./configure && make -j6 && make -j6 install
>> 
>> > Aye. 
>> > .. snip..
>> >> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
>> >> >     [But this might be invalid as the addition of the ffff8303faaf25a8
>> >> >      might be correct - as the second dpci the softirq is processing
>> >> >      could be the MSI one]
>> >> 
>> >> Would there be an easy way to stress test this function separately in some 
>> >> debugging function to see if it indeed is returning unexpected values ?
>> 
>> > Sadly no. But you got me looking in the right direction when you mentioned
>> > 'timeout'.
>> >> 
>> >> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
>> >> 
>> >> Just curious, have you also tested the patches on AMD hardware ?
>> 
>> > Yes. To reproduce this the first thing I did was to get an AMD box.
>> 
>> >> 
>> >>  
>> >> >> When i look at the combination of (2) and (3), It seems it could be an 
>> >> >> interaction between the two passed through devices and/or different IRQ types.
>> >> 
>> >> > Could be - as in it is causing this issue to show up faster than
>> >> > expected. Or it is the one that triggers more than one dpci happening
>> >> > at the same time.
>> >> 
>> >> Well that didn't seem to be it (see separate amendment i mailed previously)
>> 
>> > Right, the current theory I've is that the interrupts are not being
>> > Acked within 8 milisecond and we reset the 'state' - and at the same
>> > time we get an interrupt and schedule it - while we are still processing
>> > the same interrupt. This would explain why the 'test_and_clear_bit'
>> > got the wrong value.
>> 
>> > In regards to the list poison - following this thread of logic - with
>> > the 'state = 0' set we open the floodgates for any CPU to put the same
>> > 'struct hvm_pirq_dpci' on its list.
>> 
>> > We do reset the 'state' on _every_ GSI that is mapped to a guest - so
>> > we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:
>> 
>> > CPUX:                           CPUY:
>> > pt_irq_time_out:
>> > state = 0;                      
>> > [out of timer coder, the                raise_softirq
>> >  pirq_dpci is on the dpci_list]         [adds the pirq_dpci as state == 0]
>> 
>> > softirq_dpci                            softirq_dpci:
>> >         list_del
>> >         [entries poison]
>> >                                                 list_del <= BOOM
>> >                         
>> > Is what I believe is happening.
>> 
>> > The INTX device - once I put a load on it - does not trigger
>> > any pt_irq_time_out, so that would explain why I cannot hit this.
>> 
>> > But I believe your card hits these "hiccups".   
>> 
>> 
>> Hi Konrad,
>> 
>> I just tested you 5 patches and as a result i still got an(other) host crash:
>> (complete serial log attached)
>> 
>> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> (XEN) [2014-11-18 21:55:41.591] CPU:    0
>> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08012c7e7>]CPU:    2
>> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
>> (XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010006    _spin_unlock+0x1f/0x30CONTEXT: hypervisor

> Duh!

> Here is another patch on top of the five you have (attached and inline).

Hi Konrad,

Happy to report it has been running with this additional patch for 2 hours now 
without any problems. I think you nailed it :-)
More than happy to test the definitive patch as well.

--
Sander

> From 18008650f10199e2b83f74394f634a97086e34b8 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Tue, 18 Nov 2014 20:48:43 -0500
> Subject: [PATCH] debug: Whether we want to clear the 'dom' field or not when
>  changing the 'state' bit.

> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  xen/drivers/passthrough/io.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)

> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index aad5607..24e2bd6 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -243,13 +243,14 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
>  }
>  
>  /*
> - * Reset the pirq_dpci->dom parameter to NULL.
> + * Reset the pirq_dpci->dom parameter to NULL if 'clear_dom' is set.
>   *
>   * This function checks the different states to make sure it can do it
>   * at the right time. If it unschedules the 'hvm_dirq_assist' from running
>   * it also refcounts (which is what the softirq would have done) properly.
>   */
> -static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci,
> +                                  unsigned int clear_dom)
>  {
>      struct domain *d = pirq_dpci->dom;
>      struct __debug *debug = &__get_cpu_var(_d);
> @@ -276,7 +277,8 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
>           * in local variable before it sets STATE_RUN - and therefore will not
>           * dereference '->dom' which would crash.
>           */
-        pirq_dpci->>dom = NULL;
> +        if (clear_dom)
> +            pirq_dpci->dom = NULL;
>          break;
>      }
>  }
> @@ -295,7 +297,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
>                                &pirq_dpci->flags) )
>      {
>          _record(&debug->clear, pirq_dpci);
> -        pt_pirq_softirq_reset(pirq_dpci);
> +        pt_pirq_softirq_reset(pirq_dpci, 0 /* leave ->dom /);
>          /* pirq_dpci->state = 0; <= OUCH! */
>          pirq_dpci->pending = 0;
>          pirq_guest_eoi(dpci_pirq(pirq_dpci));
> @@ -333,9 +335,11 @@ static void pt_irq_time_out(void *data)
>      pt_pirq_iterate(irq_map->dom, pt_irq_guest_eoi, NULL);
>  
>      spin_unlock(&irq_map->dom->event_lock);
> +#if 0
>      console_start_sync();
>      dump_debug((char)0);
>      console_end_sync();
> +#endif
>  }
>  
>  struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *d)
> @@ -446,7 +450,7 @@ int pt_irq_create_bind(
>                       * in the queue.
>                       */
>                      pirq_dpci->line = __LINE__;
> -                    pt_pirq_softirq_reset(pirq_dpci);
> +                    pt_pirq_softirq_reset(pirq_dpci, 1 /* clear dom */);
>                  }
>              }
>              if ( unlikely(rc) )
> @@ -701,7 +705,7 @@ int pt_irq_destroy_bind(
>           * call to pt_pirq_softirq_reset.
>           */
>          pirq_dpci->line = __LINE__;
> -        pt_pirq_softirq_reset(pirq_dpci);
> +        pt_pirq_softirq_reset(pirq_dpci, 1 /* clear ->dom */);
>  
>          pirq_cleanup_check(pirq, d);
>      }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Fi-0002Te-35; Wed, 19 Nov 2014 11:16:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr3Fg-0002TX-Lr
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:16:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	67/93-02696-02C7C645; Wed, 19 Nov 2014 11:16:48 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416395804!13483258!1
X-Originating-IP: [64.18.0.188]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20204 invoked from network); 19 Nov 2014 11:16:45 -0000
Received: from exprod5og109.obsmtp.com (HELO exprod5og109.obsmtp.com)
	(64.18.0.188)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 11:16:45 -0000
Received: from mail-qg0-f41.google.com ([209.85.192.41]) (using TLSv1) by
	exprod5ob109.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGx8G3bsEj4GdyxkxjZQImksKFzXqBl7@postini.com;
	Wed, 19 Nov 2014 03:16:45 PST
Received: by mail-qg0-f41.google.com with SMTP id j5so218362qga.0
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 03:16:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=gI9Klx6bn8lItwnLBjBBUrP4PpLHKVAJl4Vn5AGwq3k=;
	b=YBEGb1ajsDycUBSEEQFUgG8eL+5wV8WbjZLz1Bnd1AyZ77MXc6JWvDdXAGds8dtEzS
	ARHe/MehSvtQuCwnY97qIY4J6PHE3BSuXQE6tZTvIBVMnNtHpVwbQUd24OtcQX/A0t2z
	dzLD5RksDkz2Rbm/it2KK58+0CcWPuiJCfM/o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=gI9Klx6bn8lItwnLBjBBUrP4PpLHKVAJl4Vn5AGwq3k=;
	b=TyAzUzi5APKwd0Z9lNZTThAXXI0pRfCI8mIKpMonk1LWh8jhw18rhACFkz60YNBDno
	3TvtaOLwj4wQWOU4Ib03OnVMZ05c/ySO8A0F50H+Bd5kVMEgxJNLk1Es6btGuFrK6yl4
	rZQFm4zBJMhaRH+7NjCRmAYp1GnPHeEtj4bbVb+MH8ywbDMjzziMjOmfulVKiC4PPKPs
	yNK6xKqbFp0u1SK+7onOlVPaz4525CgvWVnFnZGR57VqTqbNQuIH+BILO5+OympFZNoJ
	vKLSxWfR3ChItPZUqZ4vSQl3QByRk/NM9dM0ucrXcsf/xRdyBQXtJU5hyyaWAaFW2oxS
	DKfg==
X-Gm-Message-State: ALoCoQkUdntnN4xHHCUq8dy5Q4MuubKobS012ZntDJkMGtopKXUDa4dHJQn31Z5NXva1C7qzBA5PylKXOzjlxPneOXG6BtOuGoAnu4cBn8xBN/p/Pypn13GdEIAVFMUwsB3fd6e3NaloQk2GYDJTq3mK96jWq9v3nQ==
X-Received: by 10.140.105.37 with SMTP id b34mr50626117qgf.91.1416395803136;
	Wed, 19 Nov 2014 03:16:43 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.105.37 with SMTP id b34mr50626100qgf.91.1416395802999;
	Wed, 19 Nov 2014 03:16:42 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 03:16:42 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171631530.26318@kaball.uk.xensource.com>
	<CAH_mUMPcrm2b_=PN-v+5eo=9387JR9cCOoTt7628HgTTB4mHhA@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 13:16:42 +0200
Message-ID: <CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> Thank you for your support.
>>
>> You are right - with latest change you've proposed I got a continuous
>> prints during platform hang:
>>
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>>
>> Looks line issue needs further deeper debugging.
>
> Cool! You could simply print what irqs are in all LRs when they are
> full, for example you could call gic_dump_info. That would tell us what
> is taking all the LRs space we have.
>
> How many LRs are available on omap5 anyway?

:) Already done this:


(XEN) gic.c:725:d0v0 LRs full, not injecting irq=27 nr_lrs 4 i 4 into d0v0
(XEN) GICH_LRs (vcpu 0) mask=f
(XEN)    HW_LR[0]=1a00001f
(XEN)    HW_LR[1]=9a00e439
(XEN)    HW_LR[2]=1a000002
(XEN)    HW_LR[3]=9a015856
(XEN) Inflight irq=31 lr=0
(XEN) Inflight irq=57 lr=1
(XEN) Inflight irq=2 lr=2
(XEN) Inflight irq=86 lr=3
(XEN) Inflight irq=27 lr=255
(XEN) Pending irq=27


>
> I doubt you have so much interrupt traffic to actually fill all the LRs,
> so I am thinking that a few LRs might not be cleared properly (that
> should happen on hypervisor entry, gic_update_one_lr should take care of
> it).

This actually explains why this happens during domU start - SGI
traffic might be very heavy this time

>
>
>> Regards,
>> Andrii
>>
>> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > Hello Andrii,
>> > we are getting closer :-)
>> >
>> > It would help if you post the output with GIC_DEBUG defined but without
>> > the other change that "fixes" the issue.
>> >
>> > I think the problem is probably due to software irqs.
>> > You are getting too many
>> >
>> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
>> >
>> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
>> > VCPU). It would be best to investigate why, especially if you get many
>> > more of the same messages without the MAINTENANCE_IRQ change I
>> > suggested.
>> >
>> > This patch might also help understading the problem more:
>> >
>> >
>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> > index b7516c0..5eaeca2 100644
>> > --- a/xen/arch/arm/gic.c
>> > +++ b/xen/arch/arm/gic.c
>> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
>> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
>> >      {
>> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
>> > -        if ( i >= nr_lrs ) return;
>> > +        if ( i >= nr_lrs )
>> > +        {
>> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
>> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
>> > +            continue;
>> > +        }
>> >
>> >          spin_lock_irqsave(&gic.lock, flags);
>> >          gic_set_lr(i, p, GICH_LR_PENDING);
>> >
>> >
>> >
>> >
>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi Stefano,
>> >>
>> >> No hangs with this change.
>> >> Complete log is the following:
>> >>
>> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
>> >> DRA752 ES1.0
>> >> <ethaddr> not set. Validating first E-fuse MAC
>> >> cpsw
>> >> - UART enabled -
>> >> - CPU 00000000 booting -
>> >> - Xen starting in Hyp mode -
>> >> - Zero BSS -
>> >> - Setting up control registers -
>> >> - Turning on paging -
>> >> - Ready -
>> >> (XEN) Checking for initrd in /chosen
>> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
>> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
>> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
>> >> (XEN)
>> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
>> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
>> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
>> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
>> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
>> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
>> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
>> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
>> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
>> >> (XEN)
>> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
>> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
>> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
>> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
>> >> (XEN) Dom heap: 344064 pages
>> >> (XEN) Domain heap initialised
>> >> (XEN) Looking for UART console serial0
>> >>  Xen 4.5-unstable
>> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
>> >> (arm-linux-gnueabihf-gcc (crosstool-NG
>> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
>> >> 20130328 (prerelease)) debu4
>> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
>> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
>> >> (XEN) 32-bit Execution:
>> >> (XEN)   Processor Features: 00001131:00011011
>> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
>> >> (XEN)     Extensions: GenericTimer Security
>> >> (XEN)   Debug Features: 02010555
>> >> (XEN)   Auxiliary Features: 00000000
>> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
>> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
>> >> (XEN) Platform: TI DRA7
>> >> (XEN) /psci method must be smc, but is: "hvc"
>> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
>> >> (XEN) Set AuxCoreBoot0 to 0x20
>> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
>> >> (XEN) Using generic timer at 6144 KHz
>> >> (XEN) GIC initialization:
>> >> (XEN)         gic_dist_addr=0000000048211000
>> >> (XEN)         gic_cpu_addr=0000000048212000
>> >> (XEN)         gic_hyp_addr=0000000048214000
>> >> (XEN)         gic_vcpu_addr=0000000048216000
>> >> (XEN)         gic_maintenance_irq=25
>> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
>> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> >> (XEN) I/O virtualisation disabled
>> >> (XEN) Allocated console ring of 16 KiB.
>> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
>> >> (XEN) Bringing up CPU1
>> >> - CPU 00000001 booting -
>> >> - Xen starting in Hyp mode -
>> >> - Setting up control registers -
>> >> - Turning on paging -
>> >> - Ready -
>> >> (XEN) CPU 1 booted.
>> >> (XEN) Brought up 2 CPUs
>> >> (XEN) *** LOADING DOMAIN 0 ***
>> >> (XEN) Loading kernel from boot module 2
>> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
>> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
>> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
>> >> (XEN) Std. Loglevel: All
>> >> (XEN) Guest Loglevel: All
>> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
>> >> input to Xen)
>> >> (XEN) Freed 272kB init memory.
>> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> >> already pending in LR0
>> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> >> already pending in LR0
>> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
>> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
>> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
>> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
>> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
>> >> /ocp/i2c@48072000/camera_ov10635
>> >> [    0.437500] ldo3: operation not allowed
>> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
>> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
>> >> [    0.468750] ov1063x 1-0030: No deserializer node found
>> >> [    0.468750] ov1063x 1-0030: No serializer node found
>> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
>> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
>> >> [    0.578125] ahci ahci.0.auto: can't get clock
>> >> [    0.898437] ldc_module_init
>> >> [    1.304687] Missing dual_emac_res_vlan in DT.
>> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
>> >> [    1.312500] Missing dual_emac_res_vlan in DT.
>> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
>> >> [    1.382812] Freeing init memory: 236K
>> >> sh: write error: No such device
>> >> Cannot identify '/dev/camera0': 2, No such file or directory
>> >> Parsing config from /xen/images/DomUAndroid.cfg
>> >> XSM Disabled: seclabel not supported
>> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> dom1 access to irq 53: Function not implemented
>> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> dom1 access to irq 71: Function not implemented
>> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> dom1 access to irq 173: Function not implemented
>> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> dom1 access to irq 174: Function not implemented
>> >> Turning on vfb in domain 1
>> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> still lr_pending
>> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> still lr_pending
>> >> Parsing config from /xen/images/DomUQNX.cfg
>> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
>> >> inject irq=2 into d0v0, when it is still lr_pending
>> >>
>> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> still lr_pending
>> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
>> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
>> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
>> >> found: Invalid kernel
>> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
>> >> failed: No such file or directory
>> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
>> >> (re-)build domain: -3
>> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> still lr_pending
>> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> still lr_pending
>> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
>> >> Turning on vkbd in domain 1
>> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> still lr_pending
>> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> still lr_pending
>> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> still lr_pending
>> >>
>> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
>> >> trying to inject irq=2 into d0v0, when it is still lr_pending
>> >>
>> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
>> >> <andrii.tseglytskyi@globallogic.com> wrote:
>> >> > OK got it. Give me a few mins
>> >> >
>> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
>> >> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
>> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
>> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
>> >> >>
>> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
>> >> >> other potential bugs introduced later.
>> >> >>
>> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >>> What if I try on top of current master branch the following code:
>> >> >>>
>> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >> >>> index 31fb81a..6764ab7 100644
>> >> >>> --- a/xen/arch/arm/gic-v2.c
>> >> >>> +++ b/xen/arch/arm/gic-v2.c
>> >> >>> @@ -36,6 +36,8 @@
>> >> >>>  #include <asm/io.h>
>> >> >>>  #include <asm/gic.h>
>> >> >>>
>> >> >>> +#define GIC_DEBUG 1
>> >> >>> +
>> >> >>>  /*
>> >> >>>   * LR register definitions are GIC v2 specific.
>> >> >>>   * Moved these definitions from header file to here
>> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >>> index bcaded9..c03d6a6 100644
>> >> >>> --- a/xen/arch/arm/gic.c
>> >> >>> +++ b/xen/arch/arm/gic.c
>> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
>> >> >>>
>> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
>> >> >>> gic_hw_ops->info->nr_lrs) - 1))
>> >> >>>
>> >> >>> -#undef GIC_DEBUG
>> >> >>> +#define GIC_DEBUG 1
>> >> >>>
>> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
>> >> >>>
>> >> >>> It is equivalent to what you proposing - my code contains
>> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
>> >> >>> be executed:
>> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
>> >> >>>
>> >> >>> regards,
>> >> >>> Andrii
>> >> >>>
>> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
>> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>> >> >>> >> everything works fine
>> >> >>> >> The following 2 patches fixes xen/master for my platform.
>> >> >>> >>
>> >> >>> >> Stefano, could you please take a look to these changes?
>> >> >>> >>
>> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
>> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
>> >> >>> >>
>> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>> >> >>> >>
>> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >> >>> >>
>> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >> >>> >> index 31fb81a..093ecdb 100644
>> >> >>> >> --- a/xen/arch/arm/gic-v2.c
>> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
>> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>> >> >>> >> pending_irq *p,
>> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
>> >> >>> >>
>> >> >>> >> -    if ( p->desc != NULL )
>> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >> >>> >>      {
>> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> >>> >> -        else
>> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
>> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> >>> >> +    }
>> >> >>> >> +    else if ( p->desc != NULL )
>> >> >>> >> +    {
>> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>> >> >>> >>      }
>> >> >>> >>
>> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
>> >> >>> >
>> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
>> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
>> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
>> >> >>> > working correctly on OMAP5. This changes might only be better at
>> >> >>> > "hiding" the real issue.
>> >> >>> >
>> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
>> >> >>> > maintenance interrupts doesn't work for software interrupts.
>> >> >>> > The commit that should make them work correctly after the
>> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
>> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
>> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
>> >> >>> > Maybe that doesn't work correctly on OMAP5.
>> >> >>> >
>> >> >>> > Could you try this patch on top of
>> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
>> >> >>> > if the problem is specifically with software irqs.
>> >> >>> >
>> >> >>> >
>> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >>> > index b7516c0..d8a17c9 100644
>> >> >>> > --- a/xen/arch/arm/gic.c
>> >> >>> > +++ b/xen/arch/arm/gic.c
>> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>> >> >>> >  /* Maximum cpu interface per GIC */
>> >> >>> >  #define NR_GIC_CPU_IF 8
>> >> >>> >
>> >> >>> > -#undef GIC_DEBUG
>> >> >>> > +#define GIC_DEBUG 1
>> >> >>> >
>> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
>> >> >>> >
>> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>> >> >>> >      if ( p->desc != NULL )
>> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>> >> >>> > +    else
>> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>> >> >>> >
>> >> >>> >      GICH[GICH_LR + lr] = lr_val;
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>>
>> >> >>> Andrii Tseglytskyi | Embedded Dev
>> >> >>> GlobalLogic
>> >> >>> www.globallogic.com
>> >> >>>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> >
>> >> > Andrii Tseglytskyi | Embedded Dev
>> >> > GlobalLogic
>> >> > www.globallogic.com
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Andrii Tseglytskyi | Embedded Dev
>> >> GlobalLogic
>> >> www.globallogic.com
>> >>
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:17:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11: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 1Xr3Gb-0002cI-Je; Wed, 19 Nov 2014 11:17:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xr3GZ-0002bu-EZ
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:17:43 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	74/14-31453-65C7C645; Wed, 19 Nov 2014 11:17:42 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416395860!12215057!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17031 invoked from network); 19 Nov 2014 11:17:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:17:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192825004"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:17:38 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1Xr3GT-0000Iz-V4; Wed, 19 Nov 2014 11:17:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 11:17:36 +0000
Message-ID: <1416395856-20849-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] docs/commandline: Fix formatting issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In both of these cases, markdown was interpreting the text as regular text,
and reflowing it as a regular paragraph, leading to a single line as output.
Reformat them as code blocks inside blockquote blocks, which causes them to
take their precise whitespace layout.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

Konrad: this is a documentation fix, so requesting a 4.5 ack please.
---
 docs/misc/xen-command-line.markdown |   38 +++++++++++++++++------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index f054d4b..e3a5a15 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -475,13 +475,13 @@ defaults of 1 and unlimited respectively are used instead.
 
 For example, with `dom0_max_vcpus=4-8`:
 
-     Number of
-  PCPUs | Dom0 VCPUs
-   2    |  4
-   4    |  4
-   6    |  6
-   8    |  8
-  10    |  8
+>        Number of
+>     PCPUs | Dom0 VCPUs
+>      2    |  4
+>      4    |  4
+>      6    |  6
+>      8    |  8
+>     10    |  8
 
 ### dom0\_mem
 > `= List of ( min:<size> | max:<size> | <size> )`
@@ -684,18 +684,18 @@ supported only when compiled with XSM\_ENABLE=y on x86.
 The specified value is a bit mask with the individual bits having the
 following meaning:
 
-Bit  0 - debug level 0 (unused at present)
-Bit  1 - debug level 1 (Control Register logging)
-Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
-Bit  3 - debug level 3 (unused at present)
-Bit  4 - I/O operation logging
-Bit  5 - vMMU logging
-Bit  6 - vLAPIC general logging
-Bit  7 - vLAPIC timer logging
-Bit  8 - vLAPIC interrupt logging
-Bit  9 - vIOAPIC logging
-Bit 10 - hypercall logging
-Bit 11 - MSR operation logging
+>     Bit  0 - debug level 0 (unused at present)
+>     Bit  1 - debug level 1 (Control Register logging)
+>     Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
+>     Bit  3 - debug level 3 (unused at present)
+>     Bit  4 - I/O operation logging
+>     Bit  5 - vMMU logging
+>     Bit  6 - vLAPIC general logging
+>     Bit  7 - vLAPIC timer logging
+>     Bit  8 - vLAPIC interrupt logging
+>     Bit  9 - vIOAPIC logging
+>     Bit 10 - hypercall logging
+>     Bit 11 - MSR operation logging
 
 Recognized in debug builds of the hypervisor only.
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:17:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11: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 1Xr3Gb-0002cI-Je; Wed, 19 Nov 2014 11:17:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xr3GZ-0002bu-EZ
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:17:43 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	74/14-31453-65C7C645; Wed, 19 Nov 2014 11:17:42 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416395860!12215057!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17031 invoked from network); 19 Nov 2014 11:17:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:17:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192825004"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:17:38 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1Xr3GT-0000Iz-V4; Wed, 19 Nov 2014 11:17:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 11:17:36 +0000
Message-ID: <1416395856-20849-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] docs/commandline: Fix formatting issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In both of these cases, markdown was interpreting the text as regular text,
and reflowing it as a regular paragraph, leading to a single line as output.
Reformat them as code blocks inside blockquote blocks, which causes them to
take their precise whitespace layout.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

Konrad: this is a documentation fix, so requesting a 4.5 ack please.
---
 docs/misc/xen-command-line.markdown |   38 +++++++++++++++++------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index f054d4b..e3a5a15 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -475,13 +475,13 @@ defaults of 1 and unlimited respectively are used instead.
 
 For example, with `dom0_max_vcpus=4-8`:
 
-     Number of
-  PCPUs | Dom0 VCPUs
-   2    |  4
-   4    |  4
-   6    |  6
-   8    |  8
-  10    |  8
+>        Number of
+>     PCPUs | Dom0 VCPUs
+>      2    |  4
+>      4    |  4
+>      6    |  6
+>      8    |  8
+>     10    |  8
 
 ### dom0\_mem
 > `= List of ( min:<size> | max:<size> | <size> )`
@@ -684,18 +684,18 @@ supported only when compiled with XSM\_ENABLE=y on x86.
 The specified value is a bit mask with the individual bits having the
 following meaning:
 
-Bit  0 - debug level 0 (unused at present)
-Bit  1 - debug level 1 (Control Register logging)
-Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
-Bit  3 - debug level 3 (unused at present)
-Bit  4 - I/O operation logging
-Bit  5 - vMMU logging
-Bit  6 - vLAPIC general logging
-Bit  7 - vLAPIC timer logging
-Bit  8 - vLAPIC interrupt logging
-Bit  9 - vIOAPIC logging
-Bit 10 - hypercall logging
-Bit 11 - MSR operation logging
+>     Bit  0 - debug level 0 (unused at present)
+>     Bit  1 - debug level 1 (Control Register logging)
+>     Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
+>     Bit  3 - debug level 3 (unused at present)
+>     Bit  4 - I/O operation logging
+>     Bit  5 - vMMU logging
+>     Bit  6 - vLAPIC general logging
+>     Bit  7 - vLAPIC timer logging
+>     Bit  8 - vLAPIC interrupt logging
+>     Bit  9 - vIOAPIC logging
+>     Bit 10 - hypercall logging
+>     Bit 11 - MSR operation logging
 
 Recognized in debug builds of the hypervisor only.
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:19:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Hp-0002mD-3d; Wed, 19 Nov 2014 11:19:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xr3Ho-0002m4-E2
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:19:00 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	65/52-24859-3AC7C645; Wed, 19 Nov 2014 11:18:59 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416395939!12276515!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32411 invoked from network); 19 Nov 2014 11:18:59 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:18:59 -0000
Received: by mail-wi0-f178.google.com with SMTP id hi2so1434146wib.17
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 03:18:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=oUi0bpJj9spXMvb/LxqGiKUTFb3ULCme2k3bP1GHFnQ=;
	b=UEYUb9XA+d5u8VxA+lvxzINrCBr0l4xvhCm8jfvuJ15plfiNyDCO6Wey2gHSCRY5tY
	JlYTB/1w1wxraYnTTBd6jOtam+/Ig4jkDCa2LiiX3j3btfhqkA7Sf6svqgMYXSPwyDXO
	860fRyZfcu5IrL99vwBuylG8rk91I3dkwoasmlhPlhRsbBs1vwiyY2Dz4ygMexmKQGzR
	gSCeTIKZ8AU1jRoJJ6ShwO3EblficVvhcttwhSPD76fsaIdVy2z2/qLIdm0DC+jrnNCj
	b3CedsDKe0PibbM+l+vyxCUWsNj0miK/7aOE5/G9/1QGTTqvOw4Nrq+BApdRo+JJff69
	aRoA==
MIME-Version: 1.0
X-Received: by 10.180.82.4 with SMTP id e4mr4598461wiy.42.1416395932133; Wed,
	19 Nov 2014 03:18:52 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Wed, 19 Nov 2014 03:18:52 -0800 (PST)
In-Reply-To: <20141111173606.GC21312@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
Date: Wed, 19 Nov 2014 11:18:52 +0000
X-Google-Sender-Auth: lFQ7BKWQmPro88xLTuXO72xS-hA
Message-ID: <CAFLBxZaLOLNU8c5_ogT_JpFJZ=4KK3yn7mykz082Z0fKb7Vz0A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 5:36 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> Third stage:
>
>            Basic     PoD   Ballooning  Mem_relocation
> PV/PVH       Y       na       Y         na
> HVM          Y       Y        Y         X
>
> NUMA-aware PoD?

Hmm, that will certainly be interesting. :-)

The point of PoD is to allocate a chunk of memory at guest creation
time and have the VM balloon down to fit that amount of memory.

If we assume that vnodes correspond to some set of pnodes, then the
initial allocation will (ideally) have to come from *some* subset of
those pnodes; but depending on the situation, it may be any
combinaton.  So for example, a guest with 2 vnodes each with 2GiB each
might end up with 1G on each pnode, or 2 G on one pnode and none on
another.

In this case, the only way to get an ideal memory layout is to
communicate back to the balloon driver how much memory to free on each
virtual node.  If the split is 1G / 1G, then the balloon driver will
need to allocate 1G for each vnode.  If the split was 0.5G / 1.5G,
then it would have to allocate 1.5G / 0.5G, &c.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:19:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3Hp-0002mD-3d; Wed, 19 Nov 2014 11:19:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xr3Ho-0002m4-E2
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:19:00 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	65/52-24859-3AC7C645; Wed, 19 Nov 2014 11:18:59 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416395939!12276515!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32411 invoked from network); 19 Nov 2014 11:18:59 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:18:59 -0000
Received: by mail-wi0-f178.google.com with SMTP id hi2so1434146wib.17
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 03:18:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=oUi0bpJj9spXMvb/LxqGiKUTFb3ULCme2k3bP1GHFnQ=;
	b=UEYUb9XA+d5u8VxA+lvxzINrCBr0l4xvhCm8jfvuJ15plfiNyDCO6Wey2gHSCRY5tY
	JlYTB/1w1wxraYnTTBd6jOtam+/Ig4jkDCa2LiiX3j3btfhqkA7Sf6svqgMYXSPwyDXO
	860fRyZfcu5IrL99vwBuylG8rk91I3dkwoasmlhPlhRsbBs1vwiyY2Dz4ygMexmKQGzR
	gSCeTIKZ8AU1jRoJJ6ShwO3EblficVvhcttwhSPD76fsaIdVy2z2/qLIdm0DC+jrnNCj
	b3CedsDKe0PibbM+l+vyxCUWsNj0miK/7aOE5/G9/1QGTTqvOw4Nrq+BApdRo+JJff69
	aRoA==
MIME-Version: 1.0
X-Received: by 10.180.82.4 with SMTP id e4mr4598461wiy.42.1416395932133; Wed,
	19 Nov 2014 03:18:52 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Wed, 19 Nov 2014 03:18:52 -0800 (PST)
In-Reply-To: <20141111173606.GC21312@zion.uk.xensource.com>
References: <20141111173606.GC21312@zion.uk.xensource.com>
Date: Wed, 19 Nov 2014 11:18:52 +0000
X-Google-Sender-Auth: lFQ7BKWQmPro88xLTuXO72xS-hA
Message-ID: <CAFLBxZaLOLNU8c5_ogT_JpFJZ=4KK3yn7mykz082Z0fKb7Vz0A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] RFC: vNUMA project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 5:36 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> Third stage:
>
>            Basic     PoD   Ballooning  Mem_relocation
> PV/PVH       Y       na       Y         na
> HVM          Y       Y        Y         X
>
> NUMA-aware PoD?

Hmm, that will certainly be interesting. :-)

The point of PoD is to allocate a chunk of memory at guest creation
time and have the VM balloon down to fit that amount of memory.

If we assume that vnodes correspond to some set of pnodes, then the
initial allocation will (ideally) have to come from *some* subset of
those pnodes; but depending on the situation, it may be any
combinaton.  So for example, a guest with 2 vnodes each with 2GiB each
might end up with 1G on each pnode, or 2 G on one pnode and none on
another.

In this case, the only way to get an ideal memory layout is to
communicate back to the balloon driver how much memory to free on each
virtual node.  If the split is 1G / 1G, then the balloon driver will
need to allocate 1G for each vnode.  If the split was 0.5G / 1.5G,
then it would have to allocate 1.5G / 0.5G, &c.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:22:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3L6-00035y-SQ; Wed, 19 Nov 2014 11:22:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr3L5-00035r-E0
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:22:23 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	A9/E6-25547-E6D7C645; Wed, 19 Nov 2014 11:22:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416396140!12361200!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26466 invoked from network); 19 Nov 2014 11:22:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:22:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194341212"
Message-ID: <1416396138.29243.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 19 Nov 2014 11:22:18 +0000
In-Reply-To: <1416395856-20849-1-git-send-email-andrew.cooper3@citrix.com>
References: <1416395856-20849-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] docs/commandline: Fix formatting
	issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 11:17 +0000, Andrew Cooper wrote:
> In both of these cases, markdown was interpreting the text as regular text,
> and reflowing it as a regular paragraph, leading to a single line as output.
> Reformat them as code blocks inside blockquote blocks, which causes them to
> take their precise whitespace layout.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> ---
> 
> Konrad: this is a documentation fix, so requesting a 4.5 ack please.

FWIW IMHO documentation fixes in general should have a very low bar to
cross until very late in the release cycle...

> ---
>  docs/misc/xen-command-line.markdown |   38 +++++++++++++++++------------------
>  1 file changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> index f054d4b..e3a5a15 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -475,13 +475,13 @@ defaults of 1 and unlimited respectively are used instead.
>  
>  For example, with `dom0_max_vcpus=4-8`:
>  
> -     Number of
> -  PCPUs | Dom0 VCPUs
> -   2    |  4
> -   4    |  4
> -   6    |  6
> -   8    |  8
> -  10    |  8
> +>        Number of
> +>     PCPUs | Dom0 VCPUs
> +>      2    |  4
> +>      4    |  4
> +>      6    |  6
> +>      8    |  8
> +>     10    |  8
>  
>  ### dom0\_mem
>  > `= List of ( min:<size> | max:<size> | <size> )`
> @@ -684,18 +684,18 @@ supported only when compiled with XSM\_ENABLE=y on x86.
>  The specified value is a bit mask with the individual bits having the
>  following meaning:
>  
> -Bit  0 - debug level 0 (unused at present)
> -Bit  1 - debug level 1 (Control Register logging)
> -Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
> -Bit  3 - debug level 3 (unused at present)
> -Bit  4 - I/O operation logging
> -Bit  5 - vMMU logging
> -Bit  6 - vLAPIC general logging
> -Bit  7 - vLAPIC timer logging
> -Bit  8 - vLAPIC interrupt logging
> -Bit  9 - vIOAPIC logging
> -Bit 10 - hypercall logging
> -Bit 11 - MSR operation logging
> +>     Bit  0 - debug level 0 (unused at present)
> +>     Bit  1 - debug level 1 (Control Register logging)
> +>     Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
> +>     Bit  3 - debug level 3 (unused at present)
> +>     Bit  4 - I/O operation logging
> +>     Bit  5 - vMMU logging
> +>     Bit  6 - vLAPIC general logging
> +>     Bit  7 - vLAPIC timer logging
> +>     Bit  8 - vLAPIC interrupt logging
> +>     Bit  9 - vIOAPIC logging
> +>     Bit 10 - hypercall logging
> +>     Bit 11 - MSR operation logging
>  
>  Recognized in debug builds of the hypervisor only.
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:22:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3L6-00035y-SQ; Wed, 19 Nov 2014 11:22:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr3L5-00035r-E0
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:22:23 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	A9/E6-25547-E6D7C645; Wed, 19 Nov 2014 11:22:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416396140!12361200!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26466 invoked from network); 19 Nov 2014 11:22:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:22:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194341212"
Message-ID: <1416396138.29243.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 19 Nov 2014 11:22:18 +0000
In-Reply-To: <1416395856-20849-1-git-send-email-andrew.cooper3@citrix.com>
References: <1416395856-20849-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] docs/commandline: Fix formatting
	issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 11:17 +0000, Andrew Cooper wrote:
> In both of these cases, markdown was interpreting the text as regular text,
> and reflowing it as a regular paragraph, leading to a single line as output.
> Reformat them as code blocks inside blockquote blocks, which causes them to
> take their precise whitespace layout.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> ---
> 
> Konrad: this is a documentation fix, so requesting a 4.5 ack please.

FWIW IMHO documentation fixes in general should have a very low bar to
cross until very late in the release cycle...

> ---
>  docs/misc/xen-command-line.markdown |   38 +++++++++++++++++------------------
>  1 file changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> index f054d4b..e3a5a15 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -475,13 +475,13 @@ defaults of 1 and unlimited respectively are used instead.
>  
>  For example, with `dom0_max_vcpus=4-8`:
>  
> -     Number of
> -  PCPUs | Dom0 VCPUs
> -   2    |  4
> -   4    |  4
> -   6    |  6
> -   8    |  8
> -  10    |  8
> +>        Number of
> +>     PCPUs | Dom0 VCPUs
> +>      2    |  4
> +>      4    |  4
> +>      6    |  6
> +>      8    |  8
> +>     10    |  8
>  
>  ### dom0\_mem
>  > `= List of ( min:<size> | max:<size> | <size> )`
> @@ -684,18 +684,18 @@ supported only when compiled with XSM\_ENABLE=y on x86.
>  The specified value is a bit mask with the individual bits having the
>  following meaning:
>  
> -Bit  0 - debug level 0 (unused at present)
> -Bit  1 - debug level 1 (Control Register logging)
> -Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
> -Bit  3 - debug level 3 (unused at present)
> -Bit  4 - I/O operation logging
> -Bit  5 - vMMU logging
> -Bit  6 - vLAPIC general logging
> -Bit  7 - vLAPIC timer logging
> -Bit  8 - vLAPIC interrupt logging
> -Bit  9 - vIOAPIC logging
> -Bit 10 - hypercall logging
> -Bit 11 - MSR operation logging
> +>     Bit  0 - debug level 0 (unused at present)
> +>     Bit  1 - debug level 1 (Control Register logging)
> +>     Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
> +>     Bit  3 - debug level 3 (unused at present)
> +>     Bit  4 - I/O operation logging
> +>     Bit  5 - vMMU logging
> +>     Bit  6 - vLAPIC general logging
> +>     Bit  7 - vLAPIC timer logging
> +>     Bit  8 - vLAPIC interrupt logging
> +>     Bit  9 - vIOAPIC logging
> +>     Bit 10 - hypercall logging
> +>     Bit 11 - MSR operation logging
>  
>  Recognized in debug builds of the hypervisor only.
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:26:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:26:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3PE-0003EJ-L6; Wed, 19 Nov 2014 11:26:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr3PD-0003EC-BU
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:26:39 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	8E/9D-01660-E6E7C645; Wed, 19 Nov 2014 11:26:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416396395!12217290!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24499 invoked from network); 19 Nov 2014 11:26:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:26:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192827675"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:26:34 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr3P8-0000TD-0U;
	Wed, 19 Nov 2014 11:26:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr3P7-0007C8-3I;
	Wed, 19 Nov 2014 11:26:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21612.32360.328456.516321@mariner.uk.xensource.com>
Date: Wed, 19 Nov 2014 11:26:32 +0000
To: <konrad.wilk@oracle.com>
In-Reply-To: <1416378851-32236-1-git-send-email-cyliu@suse.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Chunyan Liu <cyliu@suse.com>, wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad, I have another release ack request:

Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> Currently libxl__domain_rename only update /local/domain/<domid>/name,
> still some places in xenstore are not updated, including:
> /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> This patch series updates /vm/<uuid>/name in xenstore,

This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
bugfix which I think should go into Xen 4.5.

The risk WITHOUT this patch is that there are out-of-tree tools which
look here for the domain name and will get confused after it is
renamed.

The risk WITH this patch is that the implementation could be wrong
somehow, in which case the code would need to be updated again.  But
it's a very small patch and has been fully reviewed.


> and removes the unusual 'domain' field under backend directory.

This is a reference to "[PATCH 1/2 V3] remove domain field in xenstore
backend dir".  The change to libxl is that it no longer writes
  /local/domain/0/backend/vfb/3/0/domain = "name of frontend domain"

It seems hardly conceivable that anyone could be using this field.
Existing users will not work after the domain is renamed, anyway.

The risk on both sides of the decision lies entirely with out-of-tree
software which looks here for the domain name for some reason.  We
don't think any such tools exist.

Note that the domain name cannot be used directly by a non-dom0
programs because the mapping between domids and domain names is in a
part of xenstore which is not accessible to guests.  (It is possible
that a guest would read this value merely to display it.)


If such out-of-tree software exists:

The risk WITHOUT this patch is that it might report, or (worse)
operate on, the wrong domain entirely.

The risk WITH this patch is that it (or some subset of its
functionality) would stop working right away.


An alternative would be to update all of these entries on rename.
That's a large and somewhat fiddly patch which we don't think is
appropriate given that the presence of this key is a mistake.


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 Nov 19 11:26:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:26:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3PE-0003EJ-L6; Wed, 19 Nov 2014 11:26:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr3PD-0003EC-BU
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:26:39 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	8E/9D-01660-E6E7C645; Wed, 19 Nov 2014 11:26:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416396395!12217290!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24499 invoked from network); 19 Nov 2014 11:26:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 11:26:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192827675"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:26:34 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr3P8-0000TD-0U;
	Wed, 19 Nov 2014 11:26:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr3P7-0007C8-3I;
	Wed, 19 Nov 2014 11:26:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21612.32360.328456.516321@mariner.uk.xensource.com>
Date: Wed, 19 Nov 2014 11:26:32 +0000
To: <konrad.wilk@oracle.com>
In-Reply-To: <1416378851-32236-1-git-send-email-cyliu@suse.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Chunyan Liu <cyliu@suse.com>, wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad, I have another release ack request:

Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> Currently libxl__domain_rename only update /local/domain/<domid>/name,
> still some places in xenstore are not updated, including:
> /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> This patch series updates /vm/<uuid>/name in xenstore,

This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
bugfix which I think should go into Xen 4.5.

The risk WITHOUT this patch is that there are out-of-tree tools which
look here for the domain name and will get confused after it is
renamed.

The risk WITH this patch is that the implementation could be wrong
somehow, in which case the code would need to be updated again.  But
it's a very small patch and has been fully reviewed.


> and removes the unusual 'domain' field under backend directory.

This is a reference to "[PATCH 1/2 V3] remove domain field in xenstore
backend dir".  The change to libxl is that it no longer writes
  /local/domain/0/backend/vfb/3/0/domain = "name of frontend domain"

It seems hardly conceivable that anyone could be using this field.
Existing users will not work after the domain is renamed, anyway.

The risk on both sides of the decision lies entirely with out-of-tree
software which looks here for the domain name for some reason.  We
don't think any such tools exist.

Note that the domain name cannot be used directly by a non-dom0
programs because the mapping between domids and domain names is in a
part of xenstore which is not accessible to guests.  (It is possible
that a guest would read this value merely to display it.)


If such out-of-tree software exists:

The risk WITHOUT this patch is that it might report, or (worse)
operate on, the wrong domain entirely.

The risk WITH this patch is that it (or some subset of its
functionality) would stop working right away.


An alternative would be to update all of these entries on rename.
That's a large and somewhat fiddly patch which we don't think is
appropriate given that the presence of this key is a mistake.


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 Nov 19 11:44:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3fu-0003Zj-2Q; Wed, 19 Nov 2014 11:43:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr3fs-0003Ze-Fz
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:43:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	39/7C-09936-7728C645; Wed, 19 Nov 2014 11:43:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416397429!13798910!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21929 invoked from network); 19 Nov 2014 11:43:50 -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;
	19 Nov 2014 11:43:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192831293"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:43:19 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr3fL-0000n2-4i;
	Wed, 19 Nov 2014 11:43:19 +0000
Date: Wed, 19 Nov 2014 11:42:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi Stefano,
> >>
> >> Thank you for your support.
> >>
> >> You are right - with latest change you've proposed I got a continuous
> >> prints during platform hang:
> >>
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >>
> >> Looks line issue needs further deeper debugging.
> >
> > Cool! You could simply print what irqs are in all LRs when they are
> > full, for example you could call gic_dump_info. That would tell us what
> > is taking all the LRs space we have.
> >
> > How many LRs are available on omap5 anyway?
> 
> :) Already done this:
> 
> 
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=27 nr_lrs 4 i 4 into d0v0
> (XEN) GICH_LRs (vcpu 0) mask=f
> (XEN)    HW_LR[0]=1a00001f
> (XEN)    HW_LR[1]=9a00e439
> (XEN)    HW_LR[2]=1a000002
> (XEN)    HW_LR[3]=9a015856
> (XEN) Inflight irq=31 lr=0
> (XEN) Inflight irq=57 lr=1
> (XEN) Inflight irq=2 lr=2
> (XEN) Inflight irq=86 lr=3
> (XEN) Inflight irq=27 lr=255
> (XEN) Pending irq=27

27 should be the virtual timer if I remember correctly.

So it looks like there is not actually anything wrong, is just that you
have too much inflight irqs? It should cause problems because in that
case GICH_HCR_UIE should be set and you should get a maintenance
interrupt when LRs become available (actually when "none, or only one,
of the List register entries is marked as a valid interrupt").

Maybe GICH_HCR_UIE is the one that doesn't work properly. It might be
worth checking that you are receiving maintenance interrupts:


diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b7516c0..b3eaa44 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
      * on return to guest that is going to clear the old LRs and inject
      * new interrupts.
      */
+    
+    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
 }
 
 void gic_dump_info(struct vcpu *v)

 
You could also try to replace GICH_HCR_UIE with GICH_HCR_NPIE, you
should still be receiving maintenance interrupts when one or more LRs
become available.


> >
> > I doubt you have so much interrupt traffic to actually fill all the LRs,
> > so I am thinking that a few LRs might not be cleared properly (that
> > should happen on hypervisor entry, gic_update_one_lr should take care of
> > it).
> 
> This actually explains why this happens during domU start - SGI
> traffic might be very heavy this time
> 
> >
> >
> >> Regards,
> >> Andrii
> >>
> >> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > Hello Andrii,
> >> > we are getting closer :-)
> >> >
> >> > It would help if you post the output with GIC_DEBUG defined but without
> >> > the other change that "fixes" the issue.
> >> >
> >> > I think the problem is probably due to software irqs.
> >> > You are getting too many
> >> >
> >> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
> >> >
> >> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
> >> > VCPU). It would be best to investigate why, especially if you get many
> >> > more of the same messages without the MAINTENANCE_IRQ change I
> >> > suggested.
> >> >
> >> > This patch might also help understading the problem more:
> >> >
> >> >
> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> > index b7516c0..5eaeca2 100644
> >> > --- a/xen/arch/arm/gic.c
> >> > +++ b/xen/arch/arm/gic.c
> >> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
> >> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
> >> >      {
> >> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> >> > -        if ( i >= nr_lrs ) return;
> >> > +        if ( i >= nr_lrs )
> >> > +        {
> >> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> >> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
> >> > +            continue;
> >> > +        }
> >> >
> >> >          spin_lock_irqsave(&gic.lock, flags);
> >> >          gic_set_lr(i, p, GICH_LR_PENDING);
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> Hi Stefano,
> >> >>
> >> >> No hangs with this change.
> >> >> Complete log is the following:
> >> >>
> >> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> >> >> DRA752 ES1.0
> >> >> <ethaddr> not set. Validating first E-fuse MAC
> >> >> cpsw
> >> >> - UART enabled -
> >> >> - CPU 00000000 booting -
> >> >> - Xen starting in Hyp mode -
> >> >> - Zero BSS -
> >> >> - Setting up control registers -
> >> >> - Turning on paging -
> >> >> - Ready -
> >> >> (XEN) Checking for initrd in /chosen
> >> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
> >> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> >> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> >> >> (XEN)
> >> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> >> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> >> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> >> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> >> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> >> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> >> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> >> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> >> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> >> >> (XEN)
> >> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> >> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> >> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> >> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> >> >> (XEN) Dom heap: 344064 pages
> >> >> (XEN) Domain heap initialised
> >> >> (XEN) Looking for UART console serial0
> >> >>  Xen 4.5-unstable
> >> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> >> >> (arm-linux-gnueabihf-gcc (crosstool-NG
> >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> >> >> 20130328 (prerelease)) debu4
> >> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> >> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> >> >> (XEN) 32-bit Execution:
> >> >> (XEN)   Processor Features: 00001131:00011011
> >> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> >> >> (XEN)     Extensions: GenericTimer Security
> >> >> (XEN)   Debug Features: 02010555
> >> >> (XEN)   Auxiliary Features: 00000000
> >> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> >> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> >> >> (XEN) Platform: TI DRA7
> >> >> (XEN) /psci method must be smc, but is: "hvc"
> >> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> >> >> (XEN) Set AuxCoreBoot0 to 0x20
> >> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> >> >> (XEN) Using generic timer at 6144 KHz
> >> >> (XEN) GIC initialization:
> >> >> (XEN)         gic_dist_addr=0000000048211000
> >> >> (XEN)         gic_cpu_addr=0000000048212000
> >> >> (XEN)         gic_hyp_addr=0000000048214000
> >> >> (XEN)         gic_vcpu_addr=0000000048216000
> >> >> (XEN)         gic_maintenance_irq=25
> >> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> >> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> >> >> (XEN) I/O virtualisation disabled
> >> >> (XEN) Allocated console ring of 16 KiB.
> >> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> >> >> (XEN) Bringing up CPU1
> >> >> - CPU 00000001 booting -
> >> >> - Xen starting in Hyp mode -
> >> >> - Setting up control registers -
> >> >> - Turning on paging -
> >> >> - Ready -
> >> >> (XEN) CPU 1 booted.
> >> >> (XEN) Brought up 2 CPUs
> >> >> (XEN) *** LOADING DOMAIN 0 ***
> >> >> (XEN) Loading kernel from boot module 2
> >> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> >> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> >> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> >> >> (XEN) Std. Loglevel: All
> >> >> (XEN) Guest Loglevel: All
> >> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> >> >> input to Xen)
> >> >> (XEN) Freed 272kB init memory.
> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> >> already pending in LR0
> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> >> already pending in LR0
> >> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> >> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> >> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> >> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> >> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> >> >> /ocp/i2c@48072000/camera_ov10635
> >> >> [    0.437500] ldo3: operation not allowed
> >> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> >> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> >> >> [    0.468750] ov1063x 1-0030: No deserializer node found
> >> >> [    0.468750] ov1063x 1-0030: No serializer node found
> >> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> >> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> >> >> [    0.578125] ahci ahci.0.auto: can't get clock
> >> >> [    0.898437] ldc_module_init
> >> >> [    1.304687] Missing dual_emac_res_vlan in DT.
> >> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> >> >> [    1.312500] Missing dual_emac_res_vlan in DT.
> >> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> >> >> [    1.382812] Freeing init memory: 236K
> >> >> sh: write error: No such device
> >> >> Cannot identify '/dev/camera0': 2, No such file or directory
> >> >> Parsing config from /xen/images/DomUAndroid.cfg
> >> >> XSM Disabled: seclabel not supported
> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> dom1 access to irq 53: Function not implemented
> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> dom1 access to irq 71: Function not implemented
> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> dom1 access to irq 173: Function not implemented
> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> dom1 access to irq 174: Function not implemented
> >> >> Turning on vfb in domain 1
> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> still lr_pending
> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> still lr_pending
> >> >> Parsing config from /xen/images/DomUQNX.cfg
> >> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> >> >> inject irq=2 into d0v0, when it is still lr_pending
> >> >>
> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> still lr_pending
> >> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> >> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> >> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> >> >> found: Invalid kernel
> >> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> >> >> failed: No such file or directory
> >> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> >> >> (re-)build domain: -3
> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> still lr_pending
> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> still lr_pending
> >> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
> >> >> Turning on vkbd in domain 1
> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> still lr_pending
> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> still lr_pending
> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> still lr_pending
> >> >>
> >> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> >> >> trying to inject irq=2 into d0v0, when it is still lr_pending
> >> >>
> >> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> >> > OK got it. Give me a few mins
> >> >> >
> >> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> >> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
> >> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> >> >> >>
> >> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> >> >> >> other potential bugs introduced later.
> >> >> >>
> >> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >>> What if I try on top of current master branch the following code:
> >> >> >>>
> >> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >> >>> index 31fb81a..6764ab7 100644
> >> >> >>> --- a/xen/arch/arm/gic-v2.c
> >> >> >>> +++ b/xen/arch/arm/gic-v2.c
> >> >> >>> @@ -36,6 +36,8 @@
> >> >> >>>  #include <asm/io.h>
> >> >> >>>  #include <asm/gic.h>
> >> >> >>>
> >> >> >>> +#define GIC_DEBUG 1
> >> >> >>> +
> >> >> >>>  /*
> >> >> >>>   * LR register definitions are GIC v2 specific.
> >> >> >>>   * Moved these definitions from header file to here
> >> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >>> index bcaded9..c03d6a6 100644
> >> >> >>> --- a/xen/arch/arm/gic.c
> >> >> >>> +++ b/xen/arch/arm/gic.c
> >> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> >> >> >>>
> >> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> >> >> >>> gic_hw_ops->info->nr_lrs) - 1))
> >> >> >>>
> >> >> >>> -#undef GIC_DEBUG
> >> >> >>> +#define GIC_DEBUG 1
> >> >> >>>
> >> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >> >>>
> >> >> >>> It is equivalent to what you proposing - my code contains
> >> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> >> >> >>> be executed:
> >> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> >> >> >>>
> >> >> >>> regards,
> >> >> >>> Andrii
> >> >> >>>
> >> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> >> >> >>> >> everything works fine
> >> >> >>> >> The following 2 patches fixes xen/master for my platform.
> >> >> >>> >>
> >> >> >>> >> Stefano, could you please take a look to these changes?
> >> >> >>> >>
> >> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> >> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> >> >> >>> >>
> >> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> >> >> >>> >>
> >> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> >> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >> >>> >>
> >> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >> >>> >> index 31fb81a..093ecdb 100644
> >> >> >>> >> --- a/xen/arch/arm/gic-v2.c
> >> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
> >> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> >> >> >>> >> pending_irq *p,
> >> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> >> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> >> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> >> >> >>> >>
> >> >> >>> >> -    if ( p->desc != NULL )
> >> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >> >>> >>      {
> >> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >> >>> >> -        else
> >> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> >> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> >> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >> >>> >> +    }
> >> >> >>> >> +    else if ( p->desc != NULL )
> >> >> >>> >> +    {
> >> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> >> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >> >>> >>      }
> >> >> >>> >>
> >> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> >> >> >>> >
> >> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> >> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> >> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> >> >> >>> > working correctly on OMAP5. This changes might only be better at
> >> >> >>> > "hiding" the real issue.
> >> >> >>> >
> >> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> >> >> >>> > maintenance interrupts doesn't work for software interrupts.
> >> >> >>> > The commit that should make them work correctly after the
> >> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> >> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> >> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> >> >> >>> > Maybe that doesn't work correctly on OMAP5.
> >> >> >>> >
> >> >> >>> > Could you try this patch on top of
> >> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> >> >> >>> > if the problem is specifically with software irqs.
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >>> > index b7516c0..d8a17c9 100644
> >> >> >>> > --- a/xen/arch/arm/gic.c
> >> >> >>> > +++ b/xen/arch/arm/gic.c
> >> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> >> >> >>> >  /* Maximum cpu interface per GIC */
> >> >> >>> >  #define NR_GIC_CPU_IF 8
> >> >> >>> >
> >> >> >>> > -#undef GIC_DEBUG
> >> >> >>> > +#define GIC_DEBUG 1
> >> >> >>> >
> >> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >> >>> >
> >> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> >> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >> >> >>> >      if ( p->desc != NULL )
> >> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> >> >> >>> > +    else
> >> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> >> >> >>> >
> >> >> >>> >      GICH[GICH_LR + lr] = lr_val;
> >> >> >>> >
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> --
> >> >> >>>
> >> >> >>> Andrii Tseglytskyi | Embedded Dev
> >> >> >>> GlobalLogic
> >> >> >>> www.globallogic.com
> >> >> >>>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> >
> >> >> > Andrii Tseglytskyi | Embedded Dev
> >> >> > GlobalLogic
> >> >> > www.globallogic.com
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> Andrii Tseglytskyi | Embedded Dev
> >> >> GlobalLogic
> >> >> www.globallogic.com
> >> >>
> >>
> >>
> >>
> >> --
> >>
> >> Andrii Tseglytskyi | Embedded Dev
> >> GlobalLogic
> >> www.globallogic.com
> >>
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:44:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr3fu-0003Zj-2Q; Wed, 19 Nov 2014 11:43:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr3fs-0003Ze-Fz
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:43:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	39/7C-09936-7728C645; Wed, 19 Nov 2014 11:43:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416397429!13798910!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21929 invoked from network); 19 Nov 2014 11:43:50 -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;
	19 Nov 2014 11:43:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192831293"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 06:43:19 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr3fL-0000n2-4i;
	Wed, 19 Nov 2014 11:43:19 +0000
Date: Wed, 19 Nov 2014 11:42:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi Stefano,
> >>
> >> Thank you for your support.
> >>
> >> You are right - with latest change you've proposed I got a continuous
> >> prints during platform hang:
> >>
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >>
> >> Looks line issue needs further deeper debugging.
> >
> > Cool! You could simply print what irqs are in all LRs when they are
> > full, for example you could call gic_dump_info. That would tell us what
> > is taking all the LRs space we have.
> >
> > How many LRs are available on omap5 anyway?
> 
> :) Already done this:
> 
> 
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=27 nr_lrs 4 i 4 into d0v0
> (XEN) GICH_LRs (vcpu 0) mask=f
> (XEN)    HW_LR[0]=1a00001f
> (XEN)    HW_LR[1]=9a00e439
> (XEN)    HW_LR[2]=1a000002
> (XEN)    HW_LR[3]=9a015856
> (XEN) Inflight irq=31 lr=0
> (XEN) Inflight irq=57 lr=1
> (XEN) Inflight irq=2 lr=2
> (XEN) Inflight irq=86 lr=3
> (XEN) Inflight irq=27 lr=255
> (XEN) Pending irq=27

27 should be the virtual timer if I remember correctly.

So it looks like there is not actually anything wrong, is just that you
have too much inflight irqs? It should cause problems because in that
case GICH_HCR_UIE should be set and you should get a maintenance
interrupt when LRs become available (actually when "none, or only one,
of the List register entries is marked as a valid interrupt").

Maybe GICH_HCR_UIE is the one that doesn't work properly. It might be
worth checking that you are receiving maintenance interrupts:


diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b7516c0..b3eaa44 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
      * on return to guest that is going to clear the old LRs and inject
      * new interrupts.
      */
+    
+    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
 }
 
 void gic_dump_info(struct vcpu *v)

 
You could also try to replace GICH_HCR_UIE with GICH_HCR_NPIE, you
should still be receiving maintenance interrupts when one or more LRs
become available.


> >
> > I doubt you have so much interrupt traffic to actually fill all the LRs,
> > so I am thinking that a few LRs might not be cleared properly (that
> > should happen on hypervisor entry, gic_update_one_lr should take care of
> > it).
> 
> This actually explains why this happens during domU start - SGI
> traffic might be very heavy this time
> 
> >
> >
> >> Regards,
> >> Andrii
> >>
> >> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > Hello Andrii,
> >> > we are getting closer :-)
> >> >
> >> > It would help if you post the output with GIC_DEBUG defined but without
> >> > the other change that "fixes" the issue.
> >> >
> >> > I think the problem is probably due to software irqs.
> >> > You are getting too many
> >> >
> >> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
> >> >
> >> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
> >> > VCPU). It would be best to investigate why, especially if you get many
> >> > more of the same messages without the MAINTENANCE_IRQ change I
> >> > suggested.
> >> >
> >> > This patch might also help understading the problem more:
> >> >
> >> >
> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> > index b7516c0..5eaeca2 100644
> >> > --- a/xen/arch/arm/gic.c
> >> > +++ b/xen/arch/arm/gic.c
> >> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
> >> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
> >> >      {
> >> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> >> > -        if ( i >= nr_lrs ) return;
> >> > +        if ( i >= nr_lrs )
> >> > +        {
> >> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> >> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
> >> > +            continue;
> >> > +        }
> >> >
> >> >          spin_lock_irqsave(&gic.lock, flags);
> >> >          gic_set_lr(i, p, GICH_LR_PENDING);
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> Hi Stefano,
> >> >>
> >> >> No hangs with this change.
> >> >> Complete log is the following:
> >> >>
> >> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> >> >> DRA752 ES1.0
> >> >> <ethaddr> not set. Validating first E-fuse MAC
> >> >> cpsw
> >> >> - UART enabled -
> >> >> - CPU 00000000 booting -
> >> >> - Xen starting in Hyp mode -
> >> >> - Zero BSS -
> >> >> - Setting up control registers -
> >> >> - Turning on paging -
> >> >> - Ready -
> >> >> (XEN) Checking for initrd in /chosen
> >> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
> >> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> >> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> >> >> (XEN)
> >> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> >> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> >> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> >> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> >> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> >> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> >> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> >> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> >> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> >> >> (XEN)
> >> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> >> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> >> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> >> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> >> >> (XEN) Dom heap: 344064 pages
> >> >> (XEN) Domain heap initialised
> >> >> (XEN) Looking for UART console serial0
> >> >>  Xen 4.5-unstable
> >> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> >> >> (arm-linux-gnueabihf-gcc (crosstool-NG
> >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> >> >> 20130328 (prerelease)) debu4
> >> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> >> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> >> >> (XEN) 32-bit Execution:
> >> >> (XEN)   Processor Features: 00001131:00011011
> >> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> >> >> (XEN)     Extensions: GenericTimer Security
> >> >> (XEN)   Debug Features: 02010555
> >> >> (XEN)   Auxiliary Features: 00000000
> >> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> >> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> >> >> (XEN) Platform: TI DRA7
> >> >> (XEN) /psci method must be smc, but is: "hvc"
> >> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> >> >> (XEN) Set AuxCoreBoot0 to 0x20
> >> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> >> >> (XEN) Using generic timer at 6144 KHz
> >> >> (XEN) GIC initialization:
> >> >> (XEN)         gic_dist_addr=0000000048211000
> >> >> (XEN)         gic_cpu_addr=0000000048212000
> >> >> (XEN)         gic_hyp_addr=0000000048214000
> >> >> (XEN)         gic_vcpu_addr=0000000048216000
> >> >> (XEN)         gic_maintenance_irq=25
> >> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> >> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> >> >> (XEN) I/O virtualisation disabled
> >> >> (XEN) Allocated console ring of 16 KiB.
> >> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> >> >> (XEN) Bringing up CPU1
> >> >> - CPU 00000001 booting -
> >> >> - Xen starting in Hyp mode -
> >> >> - Setting up control registers -
> >> >> - Turning on paging -
> >> >> - Ready -
> >> >> (XEN) CPU 1 booted.
> >> >> (XEN) Brought up 2 CPUs
> >> >> (XEN) *** LOADING DOMAIN 0 ***
> >> >> (XEN) Loading kernel from boot module 2
> >> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> >> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> >> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> >> >> (XEN) Std. Loglevel: All
> >> >> (XEN) Guest Loglevel: All
> >> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> >> >> input to Xen)
> >> >> (XEN) Freed 272kB init memory.
> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> >> already pending in LR0
> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> >> already pending in LR0
> >> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> >> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> >> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> >> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> >> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> >> >> /ocp/i2c@48072000/camera_ov10635
> >> >> [    0.437500] ldo3: operation not allowed
> >> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> >> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> >> >> [    0.468750] ov1063x 1-0030: No deserializer node found
> >> >> [    0.468750] ov1063x 1-0030: No serializer node found
> >> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> >> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> >> >> [    0.578125] ahci ahci.0.auto: can't get clock
> >> >> [    0.898437] ldc_module_init
> >> >> [    1.304687] Missing dual_emac_res_vlan in DT.
> >> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> >> >> [    1.312500] Missing dual_emac_res_vlan in DT.
> >> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> >> >> [    1.382812] Freeing init memory: 236K
> >> >> sh: write error: No such device
> >> >> Cannot identify '/dev/camera0': 2, No such file or directory
> >> >> Parsing config from /xen/images/DomUAndroid.cfg
> >> >> XSM Disabled: seclabel not supported
> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> dom1 access to irq 53: Function not implemented
> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> dom1 access to irq 71: Function not implemented
> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> dom1 access to irq 173: Function not implemented
> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> dom1 access to irq 174: Function not implemented
> >> >> Turning on vfb in domain 1
> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> still lr_pending
> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> still lr_pending
> >> >> Parsing config from /xen/images/DomUQNX.cfg
> >> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> >> >> inject irq=2 into d0v0, when it is still lr_pending
> >> >>
> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> still lr_pending
> >> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> >> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> >> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> >> >> found: Invalid kernel
> >> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> >> >> failed: No such file or directory
> >> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> >> >> (re-)build domain: -3
> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> still lr_pending
> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> still lr_pending
> >> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
> >> >> Turning on vkbd in domain 1
> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> still lr_pending
> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> still lr_pending
> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> still lr_pending
> >> >>
> >> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> >> >> trying to inject irq=2 into d0v0, when it is still lr_pending
> >> >>
> >> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> >> > OK got it. Give me a few mins
> >> >> >
> >> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> >> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
> >> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> >> >> >>
> >> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> >> >> >> other potential bugs introduced later.
> >> >> >>
> >> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >>> What if I try on top of current master branch the following code:
> >> >> >>>
> >> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >> >>> index 31fb81a..6764ab7 100644
> >> >> >>> --- a/xen/arch/arm/gic-v2.c
> >> >> >>> +++ b/xen/arch/arm/gic-v2.c
> >> >> >>> @@ -36,6 +36,8 @@
> >> >> >>>  #include <asm/io.h>
> >> >> >>>  #include <asm/gic.h>
> >> >> >>>
> >> >> >>> +#define GIC_DEBUG 1
> >> >> >>> +
> >> >> >>>  /*
> >> >> >>>   * LR register definitions are GIC v2 specific.
> >> >> >>>   * Moved these definitions from header file to here
> >> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >>> index bcaded9..c03d6a6 100644
> >> >> >>> --- a/xen/arch/arm/gic.c
> >> >> >>> +++ b/xen/arch/arm/gic.c
> >> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> >> >> >>>
> >> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> >> >> >>> gic_hw_ops->info->nr_lrs) - 1))
> >> >> >>>
> >> >> >>> -#undef GIC_DEBUG
> >> >> >>> +#define GIC_DEBUG 1
> >> >> >>>
> >> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >> >>>
> >> >> >>> It is equivalent to what you proposing - my code contains
> >> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> >> >> >>> be executed:
> >> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> >> >> >>>
> >> >> >>> regards,
> >> >> >>> Andrii
> >> >> >>>
> >> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> >> >> >>> >> everything works fine
> >> >> >>> >> The following 2 patches fixes xen/master for my platform.
> >> >> >>> >>
> >> >> >>> >> Stefano, could you please take a look to these changes?
> >> >> >>> >>
> >> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> >> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> >> >> >>> >>
> >> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> >> >> >>> >>
> >> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> >> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >> >>> >>
> >> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >> >>> >> index 31fb81a..093ecdb 100644
> >> >> >>> >> --- a/xen/arch/arm/gic-v2.c
> >> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
> >> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> >> >> >>> >> pending_irq *p,
> >> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> >> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> >> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> >> >> >>> >>
> >> >> >>> >> -    if ( p->desc != NULL )
> >> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >> >>> >>      {
> >> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >> >>> >> -        else
> >> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> >> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> >> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >> >>> >> +    }
> >> >> >>> >> +    else if ( p->desc != NULL )
> >> >> >>> >> +    {
> >> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> >> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >> >>> >>      }
> >> >> >>> >>
> >> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> >> >> >>> >
> >> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> >> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> >> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> >> >> >>> > working correctly on OMAP5. This changes might only be better at
> >> >> >>> > "hiding" the real issue.
> >> >> >>> >
> >> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> >> >> >>> > maintenance interrupts doesn't work for software interrupts.
> >> >> >>> > The commit that should make them work correctly after the
> >> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> >> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> >> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> >> >> >>> > Maybe that doesn't work correctly on OMAP5.
> >> >> >>> >
> >> >> >>> > Could you try this patch on top of
> >> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> >> >> >>> > if the problem is specifically with software irqs.
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >>> > index b7516c0..d8a17c9 100644
> >> >> >>> > --- a/xen/arch/arm/gic.c
> >> >> >>> > +++ b/xen/arch/arm/gic.c
> >> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> >> >> >>> >  /* Maximum cpu interface per GIC */
> >> >> >>> >  #define NR_GIC_CPU_IF 8
> >> >> >>> >
> >> >> >>> > -#undef GIC_DEBUG
> >> >> >>> > +#define GIC_DEBUG 1
> >> >> >>> >
> >> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >> >>> >
> >> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> >> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >> >> >>> >      if ( p->desc != NULL )
> >> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> >> >> >>> > +    else
> >> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> >> >> >>> >
> >> >> >>> >      GICH[GICH_LR + lr] = lr_val;
> >> >> >>> >
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> --
> >> >> >>>
> >> >> >>> Andrii Tseglytskyi | Embedded Dev
> >> >> >>> GlobalLogic
> >> >> >>> www.globallogic.com
> >> >> >>>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> >
> >> >> > Andrii Tseglytskyi | Embedded Dev
> >> >> > GlobalLogic
> >> >> > www.globallogic.com
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> Andrii Tseglytskyi | Embedded Dev
> >> >> GlobalLogic
> >> >> www.globallogic.com
> >> >>
> >>
> >>
> >>
> >> --
> >>
> >> Andrii Tseglytskyi | Embedded Dev
> >> GlobalLogic
> >> www.globallogic.com
> >>
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:57:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11: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 1Xr3sm-0003p6-W9; Wed, 19 Nov 2014 11:57:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr3sl-0003p1-5b
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:57:11 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	86/27-25727-6958C645; Wed, 19 Nov 2014 11:57:10 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416398226!7991575!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26656 invoked from network); 19 Nov 2014 11:57:08 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 11:57:08 -0000
Received: from mail-qg0-f52.google.com ([209.85.192.52]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGyFkmcG6YLO5Q/vK7h0tjbS8GMDN4Rf@postini.com;
	Wed, 19 Nov 2014 03:57:08 PST
Received: by mail-qg0-f52.google.com with SMTP id a108so242129qge.39
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 03:57:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ELnd1q4aqlBotM9PY6ROPaj/nx815wpkyO0i+Ov76DM=;
	b=TODM0m1jh3EUhzByCnKN9ebB5ATdLu9x18JXb18k93VjthlmgbeyJe+I4G50VsO66i
	emy6LGLB1/kE1bfJkuFYtBmmm37yOXcl8p6D3JKpIMCWfZVL+yDW92hu+C65rg8Dxv3r
	V0phbdHETf9YvcueFuKMLTVzwUHzJ0iQLJclw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=ELnd1q4aqlBotM9PY6ROPaj/nx815wpkyO0i+Ov76DM=;
	b=VpBeP2gEl/ZqDwg1Bo17tBZG4d0VXEXDgM4HbS91T0DXvHFKhQXaf6oR1Csh93djJ4
	WdobkXmehsQFbPuJT7DI59yY8xkxAb3bQiPWi9RsV+aV50Exb6oHs0gaKvxTKQGMHg35
	OFEoxiwtVV25O5Nk2LU8y202efpkPSTXwhX3ZSJIWQQ6eLXiZb6O2tMivyweUNsFmYY5
	r0Pe6k/NwPGFOVjwtETDk4u/QAOiaLaPEvdWbhzN7k0pOLj3gCpuQhCXreJMJFntT39m
	YQ79t32UfuTblEO7O3Xm+iAl+mkb+Pgj2/+KO5ALdVO7gFylSCTXjjT45NGPJ3Ga3LU2
	TZWg==
X-Gm-Message-State: ALoCoQnMRLUUZthi2z9s7CVGYf4kgskXw2Go5tqhgHWMI4gsMwVdey4lTVIc0hkCnepM136sduf7Nigw57dGjzl+K4TJi5FJoS2jnk0kNC0/UjKlspG1cTkzEwZREntM7BGo5des3d23PEafxYwcMJArbnb+jgdxKA==
X-Received: by 10.224.138.2 with SMTP id y2mr51895248qat.52.1416398225649;
	Wed, 19 Nov 2014 03:57:05 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.138.2 with SMTP id y2mr51895233qat.52.1416398225504;
	Wed, 19 Nov 2014 03:57:05 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 03:57:05 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 13:57:05 +0200
Message-ID: <CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 1:42 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi Stefano,
>> >>
>> >> Thank you for your support.
>> >>
>> >> You are right - with latest change you've proposed I got a continuous
>> >> prints during platform hang:
>> >>
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >>
>> >> Looks line issue needs further deeper debugging.
>> >
>> > Cool! You could simply print what irqs are in all LRs when they are
>> > full, for example you could call gic_dump_info. That would tell us what
>> > is taking all the LRs space we have.
>> >
>> > How many LRs are available on omap5 anyway?
>>
>> :) Already done this:
>>
>>
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=27 nr_lrs 4 i 4 into d0v0
>> (XEN) GICH_LRs (vcpu 0) mask=f
>> (XEN)    HW_LR[0]=1a00001f
>> (XEN)    HW_LR[1]=9a00e439
>> (XEN)    HW_LR[2]=1a000002
>> (XEN)    HW_LR[3]=9a015856
>> (XEN) Inflight irq=31 lr=0
>> (XEN) Inflight irq=57 lr=1
>> (XEN) Inflight irq=2 lr=2
>> (XEN) Inflight irq=86 lr=3
>> (XEN) Inflight irq=27 lr=255
>> (XEN) Pending irq=27
>
> 27 should be the virtual timer if I remember correctly.
>
> So it looks like there is not actually anything wrong, is just that you
> have too much inflight irqs? It should cause problems because in that
> case GICH_HCR_UIE should be set and you should get a maintenance
> interrupt when LRs become available (actually when "none, or only one,
> of the List register entries is marked as a valid interrupt").
>
> Maybe GICH_HCR_UIE is the one that doesn't work properly. It might be
> worth checking that you are receiving maintenance interrupts:
>
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index b7516c0..b3eaa44 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>       * on return to guest that is going to clear the old LRs and inject
>       * new interrupts.
>       */
> +
> +    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
>  }
>

I observe this print during hang, so maintenance interrupt occurs.
Can I perform some kind of LRs cleanup inside its handler?

>  void gic_dump_info(struct vcpu *v)
>
>
> You could also try to replace GICH_HCR_UIE with GICH_HCR_NPIE, you
> should still be receiving maintenance interrupts when one or more LRs
> become available.

Sorry didn't get, do you mean this change ?

@@ -759,9 +760,9 @@ void gic_inject(void)


     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
-        GICH[GICH_HCR] |= GICH_HCR_UIE;
+        GICH[GICH_HCR] |= GICH_HCR_NPIE;
     else
-        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
+        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;

 }



>
>
>> >
>> > I doubt you have so much interrupt traffic to actually fill all the LRs,
>> > so I am thinking that a few LRs might not be cleared properly (that
>> > should happen on hypervisor entry, gic_update_one_lr should take care of
>> > it).
>>
>> This actually explains why this happens during domU start - SGI
>> traffic might be very heavy this time
>>
>> >
>> >
>> >> Regards,
>> >> Andrii
>> >>
>> >> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > Hello Andrii,
>> >> > we are getting closer :-)
>> >> >
>> >> > It would help if you post the output with GIC_DEBUG defined but without
>> >> > the other change that "fixes" the issue.
>> >> >
>> >> > I think the problem is probably due to software irqs.
>> >> > You are getting too many
>> >> >
>> >> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
>> >> >
>> >> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
>> >> > VCPU). It would be best to investigate why, especially if you get many
>> >> > more of the same messages without the MAINTENANCE_IRQ change I
>> >> > suggested.
>> >> >
>> >> > This patch might also help understading the problem more:
>> >> >
>> >> >
>> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> > index b7516c0..5eaeca2 100644
>> >> > --- a/xen/arch/arm/gic.c
>> >> > +++ b/xen/arch/arm/gic.c
>> >> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
>> >> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
>> >> >      {
>> >> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
>> >> > -        if ( i >= nr_lrs ) return;
>> >> > +        if ( i >= nr_lrs )
>> >> > +        {
>> >> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
>> >> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
>> >> > +            continue;
>> >> > +        }
>> >> >
>> >> >          spin_lock_irqsave(&gic.lock, flags);
>> >> >          gic_set_lr(i, p, GICH_LR_PENDING);
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> Hi Stefano,
>> >> >>
>> >> >> No hangs with this change.
>> >> >> Complete log is the following:
>> >> >>
>> >> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
>> >> >> DRA752 ES1.0
>> >> >> <ethaddr> not set. Validating first E-fuse MAC
>> >> >> cpsw
>> >> >> - UART enabled -
>> >> >> - CPU 00000000 booting -
>> >> >> - Xen starting in Hyp mode -
>> >> >> - Zero BSS -
>> >> >> - Setting up control registers -
>> >> >> - Turning on paging -
>> >> >> - Ready -
>> >> >> (XEN) Checking for initrd in /chosen
>> >> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
>> >> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
>> >> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
>> >> >> (XEN)
>> >> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
>> >> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
>> >> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
>> >> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
>> >> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
>> >> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
>> >> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
>> >> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
>> >> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
>> >> >> (XEN)
>> >> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
>> >> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
>> >> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
>> >> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
>> >> >> (XEN) Dom heap: 344064 pages
>> >> >> (XEN) Domain heap initialised
>> >> >> (XEN) Looking for UART console serial0
>> >> >>  Xen 4.5-unstable
>> >> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
>> >> >> (arm-linux-gnueabihf-gcc (crosstool-NG
>> >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
>> >> >> 20130328 (prerelease)) debu4
>> >> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
>> >> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
>> >> >> (XEN) 32-bit Execution:
>> >> >> (XEN)   Processor Features: 00001131:00011011
>> >> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
>> >> >> (XEN)     Extensions: GenericTimer Security
>> >> >> (XEN)   Debug Features: 02010555
>> >> >> (XEN)   Auxiliary Features: 00000000
>> >> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
>> >> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
>> >> >> (XEN) Platform: TI DRA7
>> >> >> (XEN) /psci method must be smc, but is: "hvc"
>> >> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
>> >> >> (XEN) Set AuxCoreBoot0 to 0x20
>> >> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
>> >> >> (XEN) Using generic timer at 6144 KHz
>> >> >> (XEN) GIC initialization:
>> >> >> (XEN)         gic_dist_addr=0000000048211000
>> >> >> (XEN)         gic_cpu_addr=0000000048212000
>> >> >> (XEN)         gic_hyp_addr=0000000048214000
>> >> >> (XEN)         gic_vcpu_addr=0000000048216000
>> >> >> (XEN)         gic_maintenance_irq=25
>> >> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
>> >> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> >> >> (XEN) I/O virtualisation disabled
>> >> >> (XEN) Allocated console ring of 16 KiB.
>> >> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
>> >> >> (XEN) Bringing up CPU1
>> >> >> - CPU 00000001 booting -
>> >> >> - Xen starting in Hyp mode -
>> >> >> - Setting up control registers -
>> >> >> - Turning on paging -
>> >> >> - Ready -
>> >> >> (XEN) CPU 1 booted.
>> >> >> (XEN) Brought up 2 CPUs
>> >> >> (XEN) *** LOADING DOMAIN 0 ***
>> >> >> (XEN) Loading kernel from boot module 2
>> >> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
>> >> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
>> >> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
>> >> >> (XEN) Std. Loglevel: All
>> >> >> (XEN) Guest Loglevel: All
>> >> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
>> >> >> input to Xen)
>> >> >> (XEN) Freed 272kB init memory.
>> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> >> >> already pending in LR0
>> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> >> >> already pending in LR0
>> >> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
>> >> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
>> >> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
>> >> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
>> >> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
>> >> >> /ocp/i2c@48072000/camera_ov10635
>> >> >> [    0.437500] ldo3: operation not allowed
>> >> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
>> >> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
>> >> >> [    0.468750] ov1063x 1-0030: No deserializer node found
>> >> >> [    0.468750] ov1063x 1-0030: No serializer node found
>> >> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
>> >> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
>> >> >> [    0.578125] ahci ahci.0.auto: can't get clock
>> >> >> [    0.898437] ldc_module_init
>> >> >> [    1.304687] Missing dual_emac_res_vlan in DT.
>> >> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
>> >> >> [    1.312500] Missing dual_emac_res_vlan in DT.
>> >> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
>> >> >> [    1.382812] Freeing init memory: 236K
>> >> >> sh: write error: No such device
>> >> >> Cannot identify '/dev/camera0': 2, No such file or directory
>> >> >> Parsing config from /xen/images/DomUAndroid.cfg
>> >> >> XSM Disabled: seclabel not supported
>> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> >> dom1 access to irq 53: Function not implemented
>> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> >> dom1 access to irq 71: Function not implemented
>> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> >> dom1 access to irq 173: Function not implemented
>> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> >> dom1 access to irq 174: Function not implemented
>> >> >> Turning on vfb in domain 1
>> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> >> still lr_pending
>> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> >> still lr_pending
>> >> >> Parsing config from /xen/images/DomUQNX.cfg
>> >> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
>> >> >> inject irq=2 into d0v0, when it is still lr_pending
>> >> >>
>> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> >> still lr_pending
>> >> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
>> >> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
>> >> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
>> >> >> found: Invalid kernel
>> >> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
>> >> >> failed: No such file or directory
>> >> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
>> >> >> (re-)build domain: -3
>> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> >> still lr_pending
>> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> >> still lr_pending
>> >> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
>> >> >> Turning on vkbd in domain 1
>> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> >> still lr_pending
>> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> >> still lr_pending
>> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> >> still lr_pending
>> >> >>
>> >> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
>> >> >> trying to inject irq=2 into d0v0, when it is still lr_pending
>> >> >>
>> >> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
>> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
>> >> >> > OK got it. Give me a few mins
>> >> >> >
>> >> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
>> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
>> >> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
>> >> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
>> >> >> >>
>> >> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
>> >> >> >> other potential bugs introduced later.
>> >> >> >>
>> >> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >>> What if I try on top of current master branch the following code:
>> >> >> >>>
>> >> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >> >> >>> index 31fb81a..6764ab7 100644
>> >> >> >>> --- a/xen/arch/arm/gic-v2.c
>> >> >> >>> +++ b/xen/arch/arm/gic-v2.c
>> >> >> >>> @@ -36,6 +36,8 @@
>> >> >> >>>  #include <asm/io.h>
>> >> >> >>>  #include <asm/gic.h>
>> >> >> >>>
>> >> >> >>> +#define GIC_DEBUG 1
>> >> >> >>> +
>> >> >> >>>  /*
>> >> >> >>>   * LR register definitions are GIC v2 specific.
>> >> >> >>>   * Moved these definitions from header file to here
>> >> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >> >>> index bcaded9..c03d6a6 100644
>> >> >> >>> --- a/xen/arch/arm/gic.c
>> >> >> >>> +++ b/xen/arch/arm/gic.c
>> >> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
>> >> >> >>>
>> >> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
>> >> >> >>> gic_hw_ops->info->nr_lrs) - 1))
>> >> >> >>>
>> >> >> >>> -#undef GIC_DEBUG
>> >> >> >>> +#define GIC_DEBUG 1
>> >> >> >>>
>> >> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
>> >> >> >>>
>> >> >> >>> It is equivalent to what you proposing - my code contains
>> >> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
>> >> >> >>> be executed:
>> >> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
>> >> >> >>>
>> >> >> >>> regards,
>> >> >> >>> Andrii
>> >> >> >>>
>> >> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
>> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>> >> >> >>> >> everything works fine
>> >> >> >>> >> The following 2 patches fixes xen/master for my platform.
>> >> >> >>> >>
>> >> >> >>> >> Stefano, could you please take a look to these changes?
>> >> >> >>> >>
>> >> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
>> >> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
>> >> >> >>> >>
>> >> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>> >> >> >>> >>
>> >> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>> >> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >> >> >>> >>
>> >> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >> >> >>> >> index 31fb81a..093ecdb 100644
>> >> >> >>> >> --- a/xen/arch/arm/gic-v2.c
>> >> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
>> >> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>> >> >> >>> >> pending_irq *p,
>> >> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>> >> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>> >> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
>> >> >> >>> >>
>> >> >> >>> >> -    if ( p->desc != NULL )
>> >> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >> >> >>> >>      {
>> >> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> >> >>> >> -        else
>> >> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>> >> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
>> >> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>> >> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> >> >>> >> +    }
>> >> >> >>> >> +    else if ( p->desc != NULL )
>> >> >> >>> >> +    {
>> >> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>> >> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>> >> >> >>> >>      }
>> >> >> >>> >>
>> >> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
>> >> >> >>> >
>> >> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
>> >> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
>> >> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
>> >> >> >>> > working correctly on OMAP5. This changes might only be better at
>> >> >> >>> > "hiding" the real issue.
>> >> >> >>> >
>> >> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
>> >> >> >>> > maintenance interrupts doesn't work for software interrupts.
>> >> >> >>> > The commit that should make them work correctly after the
>> >> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
>> >> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
>> >> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
>> >> >> >>> > Maybe that doesn't work correctly on OMAP5.
>> >> >> >>> >
>> >> >> >>> > Could you try this patch on top of
>> >> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
>> >> >> >>> > if the problem is specifically with software irqs.
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >> >>> > index b7516c0..d8a17c9 100644
>> >> >> >>> > --- a/xen/arch/arm/gic.c
>> >> >> >>> > +++ b/xen/arch/arm/gic.c
>> >> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>> >> >> >>> >  /* Maximum cpu interface per GIC */
>> >> >> >>> >  #define NR_GIC_CPU_IF 8
>> >> >> >>> >
>> >> >> >>> > -#undef GIC_DEBUG
>> >> >> >>> > +#define GIC_DEBUG 1
>> >> >> >>> >
>> >> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
>> >> >> >>> >
>> >> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>> >> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>> >> >> >>> >      if ( p->desc != NULL )
>> >> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>> >> >> >>> > +    else
>> >> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>> >> >> >>> >
>> >> >> >>> >      GICH[GICH_LR + lr] = lr_val;
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>>
>> >> >> >>> Andrii Tseglytskyi | Embedded Dev
>> >> >> >>> GlobalLogic
>> >> >> >>> www.globallogic.com
>> >> >> >>>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> >
>> >> >> > Andrii Tseglytskyi | Embedded Dev
>> >> >> > GlobalLogic
>> >> >> > www.globallogic.com
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Andrii Tseglytskyi | Embedded Dev
>> >> >> GlobalLogic
>> >> >> www.globallogic.com
>> >> >>
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Andrii Tseglytskyi | Embedded Dev
>> >> GlobalLogic
>> >> www.globallogic.com
>> >>
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 11:57:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 11: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 1Xr3sm-0003p6-W9; Wed, 19 Nov 2014 11:57:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr3sl-0003p1-5b
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 11:57:11 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	86/27-25727-6958C645; Wed, 19 Nov 2014 11:57:10 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416398226!7991575!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26656 invoked from network); 19 Nov 2014 11:57:08 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 11:57:08 -0000
Received: from mail-qg0-f52.google.com ([209.85.192.52]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGyFkmcG6YLO5Q/vK7h0tjbS8GMDN4Rf@postini.com;
	Wed, 19 Nov 2014 03:57:08 PST
Received: by mail-qg0-f52.google.com with SMTP id a108so242129qge.39
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 03:57:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ELnd1q4aqlBotM9PY6ROPaj/nx815wpkyO0i+Ov76DM=;
	b=TODM0m1jh3EUhzByCnKN9ebB5ATdLu9x18JXb18k93VjthlmgbeyJe+I4G50VsO66i
	emy6LGLB1/kE1bfJkuFYtBmmm37yOXcl8p6D3JKpIMCWfZVL+yDW92hu+C65rg8Dxv3r
	V0phbdHETf9YvcueFuKMLTVzwUHzJ0iQLJclw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=ELnd1q4aqlBotM9PY6ROPaj/nx815wpkyO0i+Ov76DM=;
	b=VpBeP2gEl/ZqDwg1Bo17tBZG4d0VXEXDgM4HbS91T0DXvHFKhQXaf6oR1Csh93djJ4
	WdobkXmehsQFbPuJT7DI59yY8xkxAb3bQiPWi9RsV+aV50Exb6oHs0gaKvxTKQGMHg35
	OFEoxiwtVV25O5Nk2LU8y202efpkPSTXwhX3ZSJIWQQ6eLXiZb6O2tMivyweUNsFmYY5
	r0Pe6k/NwPGFOVjwtETDk4u/QAOiaLaPEvdWbhzN7k0pOLj3gCpuQhCXreJMJFntT39m
	YQ79t32UfuTblEO7O3Xm+iAl+mkb+Pgj2/+KO5ALdVO7gFylSCTXjjT45NGPJ3Ga3LU2
	TZWg==
X-Gm-Message-State: ALoCoQnMRLUUZthi2z9s7CVGYf4kgskXw2Go5tqhgHWMI4gsMwVdey4lTVIc0hkCnepM136sduf7Nigw57dGjzl+K4TJi5FJoS2jnk0kNC0/UjKlspG1cTkzEwZREntM7BGo5des3d23PEafxYwcMJArbnb+jgdxKA==
X-Received: by 10.224.138.2 with SMTP id y2mr51895248qat.52.1416398225649;
	Wed, 19 Nov 2014 03:57:05 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.138.2 with SMTP id y2mr51895233qat.52.1416398225504;
	Wed, 19 Nov 2014 03:57:05 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 03:57:05 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 13:57:05 +0200
Message-ID: <CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 1:42 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi Stefano,
>> >>
>> >> Thank you for your support.
>> >>
>> >> You are right - with latest change you've proposed I got a continuous
>> >> prints during platform hang:
>> >>
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
>> >>
>> >> Looks line issue needs further deeper debugging.
>> >
>> > Cool! You could simply print what irqs are in all LRs when they are
>> > full, for example you could call gic_dump_info. That would tell us what
>> > is taking all the LRs space we have.
>> >
>> > How many LRs are available on omap5 anyway?
>>
>> :) Already done this:
>>
>>
>> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=27 nr_lrs 4 i 4 into d0v0
>> (XEN) GICH_LRs (vcpu 0) mask=f
>> (XEN)    HW_LR[0]=1a00001f
>> (XEN)    HW_LR[1]=9a00e439
>> (XEN)    HW_LR[2]=1a000002
>> (XEN)    HW_LR[3]=9a015856
>> (XEN) Inflight irq=31 lr=0
>> (XEN) Inflight irq=57 lr=1
>> (XEN) Inflight irq=2 lr=2
>> (XEN) Inflight irq=86 lr=3
>> (XEN) Inflight irq=27 lr=255
>> (XEN) Pending irq=27
>
> 27 should be the virtual timer if I remember correctly.
>
> So it looks like there is not actually anything wrong, is just that you
> have too much inflight irqs? It should cause problems because in that
> case GICH_HCR_UIE should be set and you should get a maintenance
> interrupt when LRs become available (actually when "none, or only one,
> of the List register entries is marked as a valid interrupt").
>
> Maybe GICH_HCR_UIE is the one that doesn't work properly. It might be
> worth checking that you are receiving maintenance interrupts:
>
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index b7516c0..b3eaa44 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>       * on return to guest that is going to clear the old LRs and inject
>       * new interrupts.
>       */
> +
> +    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
>  }
>

I observe this print during hang, so maintenance interrupt occurs.
Can I perform some kind of LRs cleanup inside its handler?

>  void gic_dump_info(struct vcpu *v)
>
>
> You could also try to replace GICH_HCR_UIE with GICH_HCR_NPIE, you
> should still be receiving maintenance interrupts when one or more LRs
> become available.

Sorry didn't get, do you mean this change ?

@@ -759,9 +760,9 @@ void gic_inject(void)


     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
-        GICH[GICH_HCR] |= GICH_HCR_UIE;
+        GICH[GICH_HCR] |= GICH_HCR_NPIE;
     else
-        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
+        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;

 }



>
>
>> >
>> > I doubt you have so much interrupt traffic to actually fill all the LRs,
>> > so I am thinking that a few LRs might not be cleared properly (that
>> > should happen on hypervisor entry, gic_update_one_lr should take care of
>> > it).
>>
>> This actually explains why this happens during domU start - SGI
>> traffic might be very heavy this time
>>
>> >
>> >
>> >> Regards,
>> >> Andrii
>> >>
>> >> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > Hello Andrii,
>> >> > we are getting closer :-)
>> >> >
>> >> > It would help if you post the output with GIC_DEBUG defined but without
>> >> > the other change that "fixes" the issue.
>> >> >
>> >> > I think the problem is probably due to software irqs.
>> >> > You are getting too many
>> >> >
>> >> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
>> >> >
>> >> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
>> >> > VCPU). It would be best to investigate why, especially if you get many
>> >> > more of the same messages without the MAINTENANCE_IRQ change I
>> >> > suggested.
>> >> >
>> >> > This patch might also help understading the problem more:
>> >> >
>> >> >
>> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> > index b7516c0..5eaeca2 100644
>> >> > --- a/xen/arch/arm/gic.c
>> >> > +++ b/xen/arch/arm/gic.c
>> >> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
>> >> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
>> >> >      {
>> >> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
>> >> > -        if ( i >= nr_lrs ) return;
>> >> > +        if ( i >= nr_lrs )
>> >> > +        {
>> >> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
>> >> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
>> >> > +            continue;
>> >> > +        }
>> >> >
>> >> >          spin_lock_irqsave(&gic.lock, flags);
>> >> >          gic_set_lr(i, p, GICH_LR_PENDING);
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> Hi Stefano,
>> >> >>
>> >> >> No hangs with this change.
>> >> >> Complete log is the following:
>> >> >>
>> >> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
>> >> >> DRA752 ES1.0
>> >> >> <ethaddr> not set. Validating first E-fuse MAC
>> >> >> cpsw
>> >> >> - UART enabled -
>> >> >> - CPU 00000000 booting -
>> >> >> - Xen starting in Hyp mode -
>> >> >> - Zero BSS -
>> >> >> - Setting up control registers -
>> >> >> - Turning on paging -
>> >> >> - Ready -
>> >> >> (XEN) Checking for initrd in /chosen
>> >> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
>> >> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
>> >> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
>> >> >> (XEN)
>> >> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
>> >> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
>> >> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
>> >> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
>> >> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
>> >> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
>> >> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
>> >> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
>> >> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
>> >> >> (XEN)
>> >> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
>> >> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
>> >> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
>> >> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
>> >> >> (XEN) Dom heap: 344064 pages
>> >> >> (XEN) Domain heap initialised
>> >> >> (XEN) Looking for UART console serial0
>> >> >>  Xen 4.5-unstable
>> >> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
>> >> >> (arm-linux-gnueabihf-gcc (crosstool-NG
>> >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
>> >> >> 20130328 (prerelease)) debu4
>> >> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
>> >> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
>> >> >> (XEN) 32-bit Execution:
>> >> >> (XEN)   Processor Features: 00001131:00011011
>> >> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
>> >> >> (XEN)     Extensions: GenericTimer Security
>> >> >> (XEN)   Debug Features: 02010555
>> >> >> (XEN)   Auxiliary Features: 00000000
>> >> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
>> >> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
>> >> >> (XEN) Platform: TI DRA7
>> >> >> (XEN) /psci method must be smc, but is: "hvc"
>> >> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
>> >> >> (XEN) Set AuxCoreBoot0 to 0x20
>> >> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
>> >> >> (XEN) Using generic timer at 6144 KHz
>> >> >> (XEN) GIC initialization:
>> >> >> (XEN)         gic_dist_addr=0000000048211000
>> >> >> (XEN)         gic_cpu_addr=0000000048212000
>> >> >> (XEN)         gic_hyp_addr=0000000048214000
>> >> >> (XEN)         gic_vcpu_addr=0000000048216000
>> >> >> (XEN)         gic_maintenance_irq=25
>> >> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
>> >> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> >> >> (XEN) I/O virtualisation disabled
>> >> >> (XEN) Allocated console ring of 16 KiB.
>> >> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
>> >> >> (XEN) Bringing up CPU1
>> >> >> - CPU 00000001 booting -
>> >> >> - Xen starting in Hyp mode -
>> >> >> - Setting up control registers -
>> >> >> - Turning on paging -
>> >> >> - Ready -
>> >> >> (XEN) CPU 1 booted.
>> >> >> (XEN) Brought up 2 CPUs
>> >> >> (XEN) *** LOADING DOMAIN 0 ***
>> >> >> (XEN) Loading kernel from boot module 2
>> >> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
>> >> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
>> >> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
>> >> >> (XEN) Std. Loglevel: All
>> >> >> (XEN) Guest Loglevel: All
>> >> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
>> >> >> input to Xen)
>> >> >> (XEN) Freed 272kB init memory.
>> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> >> >> already pending in LR0
>> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
>> >> >> already pending in LR0
>> >> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
>> >> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
>> >> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
>> >> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
>> >> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
>> >> >> /ocp/i2c@48072000/camera_ov10635
>> >> >> [    0.437500] ldo3: operation not allowed
>> >> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
>> >> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
>> >> >> [    0.468750] ov1063x 1-0030: No deserializer node found
>> >> >> [    0.468750] ov1063x 1-0030: No serializer node found
>> >> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
>> >> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
>> >> >> [    0.578125] ahci ahci.0.auto: can't get clock
>> >> >> [    0.898437] ldc_module_init
>> >> >> [    1.304687] Missing dual_emac_res_vlan in DT.
>> >> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
>> >> >> [    1.312500] Missing dual_emac_res_vlan in DT.
>> >> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
>> >> >> [    1.382812] Freeing init memory: 236K
>> >> >> sh: write error: No such device
>> >> >> Cannot identify '/dev/camera0': 2, No such file or directory
>> >> >> Parsing config from /xen/images/DomUAndroid.cfg
>> >> >> XSM Disabled: seclabel not supported
>> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> >> dom1 access to irq 53: Function not implemented
>> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> >> dom1 access to irq 71: Function not implemented
>> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> >> dom1 access to irq 173: Function not implemented
>> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
>> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
>> >> >> dom1 access to irq 174: Function not implemented
>> >> >> Turning on vfb in domain 1
>> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> >> still lr_pending
>> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> >> still lr_pending
>> >> >> Parsing config from /xen/images/DomUQNX.cfg
>> >> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
>> >> >> inject irq=2 into d0v0, when it is still lr_pending
>> >> >>
>> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> >> still lr_pending
>> >> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
>> >> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
>> >> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
>> >> >> found: Invalid kernel
>> >> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
>> >> >> failed: No such file or directory
>> >> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
>> >> >> (re-)build domain: -3
>> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> >> still lr_pending
>> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> >> still lr_pending
>> >> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
>> >> >> Turning on vkbd in domain 1
>> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> >> still lr_pending
>> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
>> >> >> still lr_pending
>> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
>> >> >> still lr_pending
>> >> >>
>> >> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
>> >> >> trying to inject irq=2 into d0v0, when it is still lr_pending
>> >> >>
>> >> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
>> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
>> >> >> > OK got it. Give me a few mins
>> >> >> >
>> >> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
>> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
>> >> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
>> >> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
>> >> >> >>
>> >> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
>> >> >> >> other potential bugs introduced later.
>> >> >> >>
>> >> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >>> What if I try on top of current master branch the following code:
>> >> >> >>>
>> >> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >> >> >>> index 31fb81a..6764ab7 100644
>> >> >> >>> --- a/xen/arch/arm/gic-v2.c
>> >> >> >>> +++ b/xen/arch/arm/gic-v2.c
>> >> >> >>> @@ -36,6 +36,8 @@
>> >> >> >>>  #include <asm/io.h>
>> >> >> >>>  #include <asm/gic.h>
>> >> >> >>>
>> >> >> >>> +#define GIC_DEBUG 1
>> >> >> >>> +
>> >> >> >>>  /*
>> >> >> >>>   * LR register definitions are GIC v2 specific.
>> >> >> >>>   * Moved these definitions from header file to here
>> >> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >> >>> index bcaded9..c03d6a6 100644
>> >> >> >>> --- a/xen/arch/arm/gic.c
>> >> >> >>> +++ b/xen/arch/arm/gic.c
>> >> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
>> >> >> >>>
>> >> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
>> >> >> >>> gic_hw_ops->info->nr_lrs) - 1))
>> >> >> >>>
>> >> >> >>> -#undef GIC_DEBUG
>> >> >> >>> +#define GIC_DEBUG 1
>> >> >> >>>
>> >> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
>> >> >> >>>
>> >> >> >>> It is equivalent to what you proposing - my code contains
>> >> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
>> >> >> >>> be executed:
>> >> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
>> >> >> >>>
>> >> >> >>> regards,
>> >> >> >>> Andrii
>> >> >> >>>
>> >> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
>> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
>> >> >> >>> >> everything works fine
>> >> >> >>> >> The following 2 patches fixes xen/master for my platform.
>> >> >> >>> >>
>> >> >> >>> >> Stefano, could you please take a look to these changes?
>> >> >> >>> >>
>> >> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
>> >> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
>> >> >> >>> >>
>> >> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
>> >> >> >>> >>
>> >> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
>> >> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> >> >> >>> >>
>> >> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> >> >> >>> >> index 31fb81a..093ecdb 100644
>> >> >> >>> >> --- a/xen/arch/arm/gic-v2.c
>> >> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
>> >> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
>> >> >> >>> >> pending_irq *p,
>> >> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
>> >> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
>> >> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
>> >> >> >>> >>
>> >> >> >>> >> -    if ( p->desc != NULL )
>> >> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >> >> >>> >>      {
>> >> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
>> >> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> >> >>> >> -        else
>> >> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
>> >> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
>> >> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
>> >> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
>> >> >> >>> >> +    }
>> >> >> >>> >> +    else if ( p->desc != NULL )
>> >> >> >>> >> +    {
>> >> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
>> >> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
>> >> >> >>> >>      }
>> >> >> >>> >>
>> >> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
>> >> >> >>> >
>> >> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
>> >> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
>> >> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
>> >> >> >>> > working correctly on OMAP5. This changes might only be better at
>> >> >> >>> > "hiding" the real issue.
>> >> >> >>> >
>> >> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
>> >> >> >>> > maintenance interrupts doesn't work for software interrupts.
>> >> >> >>> > The commit that should make them work correctly after the
>> >> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
>> >> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
>> >> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
>> >> >> >>> > Maybe that doesn't work correctly on OMAP5.
>> >> >> >>> >
>> >> >> >>> > Could you try this patch on top of
>> >> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
>> >> >> >>> > if the problem is specifically with software irqs.
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >> >>> > index b7516c0..d8a17c9 100644
>> >> >> >>> > --- a/xen/arch/arm/gic.c
>> >> >> >>> > +++ b/xen/arch/arm/gic.c
>> >> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
>> >> >> >>> >  /* Maximum cpu interface per GIC */
>> >> >> >>> >  #define NR_GIC_CPU_IF 8
>> >> >> >>> >
>> >> >> >>> > -#undef GIC_DEBUG
>> >> >> >>> > +#define GIC_DEBUG 1
>> >> >> >>> >
>> >> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
>> >> >> >>> >
>> >> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>> >> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>> >> >> >>> >      if ( p->desc != NULL )
>> >> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
>> >> >> >>> > +    else
>> >> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
>> >> >> >>> >
>> >> >> >>> >      GICH[GICH_LR + lr] = lr_val;
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>>
>> >> >> >>> Andrii Tseglytskyi | Embedded Dev
>> >> >> >>> GlobalLogic
>> >> >> >>> www.globallogic.com
>> >> >> >>>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> >
>> >> >> > Andrii Tseglytskyi | Embedded Dev
>> >> >> > GlobalLogic
>> >> >> > www.globallogic.com
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Andrii Tseglytskyi | Embedded Dev
>> >> >> GlobalLogic
>> >> >> www.globallogic.com
>> >> >>
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Andrii Tseglytskyi | Embedded Dev
>> >> GlobalLogic
>> >> www.globallogic.com
>> >>
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:10:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12: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.xen.org>)
	id 1Xr44x-0004HR-TM; Wed, 19 Nov 2014 12:09:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr44w-0004HH-PD
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 12:09:46 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	BA/C1-17735-A888C645; Wed, 19 Nov 2014 12:09:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416398983!12421985!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28884 invoked from network); 19 Nov 2014 12:09:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 12:09:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194352544"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 07:09:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr3w8-00015B-GA;
	Wed, 19 Nov 2014 12:00:40 +0000
Date: Wed, 19 Nov 2014 12:00:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <4EC8C166-7BA3-4F63-A09A-097F4FD67652@oracle.com>
Message-ID: <alpine.DEB.2.02.1411191200100.27247@kaball.uk.xensource.com>
References: <1416259239-13281-1-git-send-email-dslutz@verizon.com>
	<alpine.DEB.2.02.1411181410440.27247@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411191052330.27247@kaball.uk.xensource.com>
	<4EC8C166-7BA3-4F63-A09A-097F4FD67652@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Don Slutz <dslutz@verizon.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [BUGFIX][PATCH for 2.2 1/1] hw/ide/core.c: Prevent
 SIGSEGV during migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On November 19, 2014 5:52:58 AM EST, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> >ping?
> >
> >On Tue, 18 Nov 2014, Stefano Stabellini wrote:
> >> Konrad,
> >> I think we should have this fix in Xen 4.5. Should I go ahead and
> >> backport it?
> 
> Go for it. Release-Acked-by: Konrad Rzeszutek Wilk (konrad.wilk@oracle.com)

Done, thanks!


> >> 
> >> On Mon, 17 Nov 2014, Don Slutz wrote:
> >> > The other callers to blk_set_enable_write_cache() in this file
> >> > already check for s->blk == NULL.
> >> > 
> >> > Signed-off-by: Don Slutz <dslutz@verizon.com>
> >> > ---
> >> > 
> >> > I think this is a bugfix that should be back ported to stable
> >> > releases.
> >> > 
> >> > I also think this should be done in xen's copy of QEMU for 4.5 with
> >> > back port(s) to active stable releases.
> >> > 
> >> > Note: In 2.1 and earlier the routine is
> >> > bdrv_set_enable_write_cache(); variable is s->bs.
> >> > 
> >> >  hw/ide/core.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> > 
> >> > diff --git a/hw/ide/core.c b/hw/ide/core.c
> >> > index 00e21cf..d4af5e2 100644
> >> > --- a/hw/ide/core.c
> >> > +++ b/hw/ide/core.c
> >> > @@ -2401,7 +2401,7 @@ static int ide_drive_post_load(void *opaque,
> >int version_id)
> >> >  {
> >> >      IDEState *s = opaque;
> >> >  
> >> > -    if (s->identify_set) {
> >> > +    if (s->blk && s->identify_set) {
> >> >          blk_set_enable_write_cache(s->blk, !!(s->identify_data[85]
> >& (1 << 5)));
> >> >      }
> >> >      return 0;
> >> > -- 
> >> > 1.8.4
> >> > 
> >> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:10:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12: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.xen.org>)
	id 1Xr44z-0004HY-94; Wed, 19 Nov 2014 12:09:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr44x-0004HM-HG
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:09:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	60/1F-09936-A888C645; Wed, 19 Nov 2014 12:09:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416398984!13852874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22226 invoked from network); 19 Nov 2014 12:09:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 12:09:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194352550"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 07:09:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr3vA-000145-Sv;
	Wed, 19 Nov 2014 11:59:40 +0000
Date: Wed, 19 Nov 2014 11:59:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 1:42 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> Hi Stefano,
> >> >>
> >> >> Thank you for your support.
> >> >>
> >> >> You are right - with latest change you've proposed I got a continuous
> >> >> prints during platform hang:
> >> >>
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >>
> >> >> Looks line issue needs further deeper debugging.
> >> >
> >> > Cool! You could simply print what irqs are in all LRs when they are
> >> > full, for example you could call gic_dump_info. That would tell us what
> >> > is taking all the LRs space we have.
> >> >
> >> > How many LRs are available on omap5 anyway?
> >>
> >> :) Already done this:
> >>
> >>
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=27 nr_lrs 4 i 4 into d0v0
> >> (XEN) GICH_LRs (vcpu 0) mask=f
> >> (XEN)    HW_LR[0]=1a00001f
> >> (XEN)    HW_LR[1]=9a00e439
> >> (XEN)    HW_LR[2]=1a000002
> >> (XEN)    HW_LR[3]=9a015856
> >> (XEN) Inflight irq=31 lr=0
> >> (XEN) Inflight irq=57 lr=1
> >> (XEN) Inflight irq=2 lr=2
> >> (XEN) Inflight irq=86 lr=3
> >> (XEN) Inflight irq=27 lr=255
> >> (XEN) Pending irq=27
> >
> > 27 should be the virtual timer if I remember correctly.
> >
> > So it looks like there is not actually anything wrong, is just that you
> > have too much inflight irqs? It should cause problems because in that
> > case GICH_HCR_UIE should be set and you should get a maintenance
> > interrupt when LRs become available (actually when "none, or only one,
> > of the List register entries is marked as a valid interrupt").
> >
> > Maybe GICH_HCR_UIE is the one that doesn't work properly. It might be
> > worth checking that you are receiving maintenance interrupts:
> >
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index b7516c0..b3eaa44 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >       * on return to guest that is going to clear the old LRs and inject
> >       * new interrupts.
> >       */
> > +
> > +    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
> >  }
> >
> 
> I observe this print during hang, so maintenance interrupt occurs.
> Can I perform some kind of LRs cleanup inside its handler?

It should happen automatically because on hypervisor entry gic_clear_lrs
gets called. In fact by the time you see this message the LRs should
have already been cleared.


> >  void gic_dump_info(struct vcpu *v)
> >
> >
> > You could also try to replace GICH_HCR_UIE with GICH_HCR_NPIE, you
> > should still be receiving maintenance interrupts when one or more LRs
> > become available.
> 
> Sorry didn't get, do you mean this change ?
> 
> @@ -759,9 +760,9 @@ void gic_inject(void)
> 
> 
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>      else
> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> 
>  }

Yes, exactly


> 
> >
> >
> >> >
> >> > I doubt you have so much interrupt traffic to actually fill all the LRs,
> >> > so I am thinking that a few LRs might not be cleared properly (that
> >> > should happen on hypervisor entry, gic_update_one_lr should take care of
> >> > it).
> >>
> >> This actually explains why this happens during domU start - SGI
> >> traffic might be very heavy this time
> >>
> >> >
> >> >
> >> >> Regards,
> >> >> Andrii
> >> >>
> >> >> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
> >> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> > Hello Andrii,
> >> >> > we are getting closer :-)
> >> >> >
> >> >> > It would help if you post the output with GIC_DEBUG defined but without
> >> >> > the other change that "fixes" the issue.
> >> >> >
> >> >> > I think the problem is probably due to software irqs.
> >> >> > You are getting too many
> >> >> >
> >> >> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
> >> >> >
> >> >> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
> >> >> > VCPU). It would be best to investigate why, especially if you get many
> >> >> > more of the same messages without the MAINTENANCE_IRQ change I
> >> >> > suggested.
> >> >> >
> >> >> > This patch might also help understading the problem more:
> >> >> >
> >> >> >
> >> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> > index b7516c0..5eaeca2 100644
> >> >> > --- a/xen/arch/arm/gic.c
> >> >> > +++ b/xen/arch/arm/gic.c
> >> >> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
> >> >> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
> >> >> >      {
> >> >> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> >> >> > -        if ( i >= nr_lrs ) return;
> >> >> > +        if ( i >= nr_lrs )
> >> >> > +        {
> >> >> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> >> >> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
> >> >> > +            continue;
> >> >> > +        }
> >> >> >
> >> >> >          spin_lock_irqsave(&gic.lock, flags);
> >> >> >          gic_set_lr(i, p, GICH_LR_PENDING);
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> Hi Stefano,
> >> >> >>
> >> >> >> No hangs with this change.
> >> >> >> Complete log is the following:
> >> >> >>
> >> >> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> >> >> >> DRA752 ES1.0
> >> >> >> <ethaddr> not set. Validating first E-fuse MAC
> >> >> >> cpsw
> >> >> >> - UART enabled -
> >> >> >> - CPU 00000000 booting -
> >> >> >> - Xen starting in Hyp mode -
> >> >> >> - Zero BSS -
> >> >> >> - Setting up control registers -
> >> >> >> - Turning on paging -
> >> >> >> - Ready -
> >> >> >> (XEN) Checking for initrd in /chosen
> >> >> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
> >> >> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> >> >> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> >> >> >> (XEN)
> >> >> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> >> >> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> >> >> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> >> >> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> >> >> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> >> >> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> >> >> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> >> >> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> >> >> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> >> >> >> (XEN)
> >> >> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> >> >> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> >> >> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> >> >> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> >> >> >> (XEN) Dom heap: 344064 pages
> >> >> >> (XEN) Domain heap initialised
> >> >> >> (XEN) Looking for UART console serial0
> >> >> >>  Xen 4.5-unstable
> >> >> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> >> >> >> (arm-linux-gnueabihf-gcc (crosstool-NG
> >> >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> >> >> >> 20130328 (prerelease)) debu4
> >> >> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> >> >> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> >> >> >> (XEN) 32-bit Execution:
> >> >> >> (XEN)   Processor Features: 00001131:00011011
> >> >> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> >> >> >> (XEN)     Extensions: GenericTimer Security
> >> >> >> (XEN)   Debug Features: 02010555
> >> >> >> (XEN)   Auxiliary Features: 00000000
> >> >> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> >> >> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> >> >> >> (XEN) Platform: TI DRA7
> >> >> >> (XEN) /psci method must be smc, but is: "hvc"
> >> >> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> >> >> >> (XEN) Set AuxCoreBoot0 to 0x20
> >> >> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> >> >> >> (XEN) Using generic timer at 6144 KHz
> >> >> >> (XEN) GIC initialization:
> >> >> >> (XEN)         gic_dist_addr=0000000048211000
> >> >> >> (XEN)         gic_cpu_addr=0000000048212000
> >> >> >> (XEN)         gic_hyp_addr=0000000048214000
> >> >> >> (XEN)         gic_vcpu_addr=0000000048216000
> >> >> >> (XEN)         gic_maintenance_irq=25
> >> >> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> >> >> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> >> >> >> (XEN) I/O virtualisation disabled
> >> >> >> (XEN) Allocated console ring of 16 KiB.
> >> >> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> >> >> >> (XEN) Bringing up CPU1
> >> >> >> - CPU 00000001 booting -
> >> >> >> - Xen starting in Hyp mode -
> >> >> >> - Setting up control registers -
> >> >> >> - Turning on paging -
> >> >> >> - Ready -
> >> >> >> (XEN) CPU 1 booted.
> >> >> >> (XEN) Brought up 2 CPUs
> >> >> >> (XEN) *** LOADING DOMAIN 0 ***
> >> >> >> (XEN) Loading kernel from boot module 2
> >> >> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> >> >> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> >> >> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> >> >> >> (XEN) Std. Loglevel: All
> >> >> >> (XEN) Guest Loglevel: All
> >> >> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> >> >> >> input to Xen)
> >> >> >> (XEN) Freed 272kB init memory.
> >> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> >> >> already pending in LR0
> >> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> >> >> already pending in LR0
> >> >> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> >> >> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> >> >> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> >> >> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> >> >> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> >> >> >> /ocp/i2c@48072000/camera_ov10635
> >> >> >> [    0.437500] ldo3: operation not allowed
> >> >> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> >> >> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> >> >> >> [    0.468750] ov1063x 1-0030: No deserializer node found
> >> >> >> [    0.468750] ov1063x 1-0030: No serializer node found
> >> >> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> >> >> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> >> >> >> [    0.578125] ahci ahci.0.auto: can't get clock
> >> >> >> [    0.898437] ldc_module_init
> >> >> >> [    1.304687] Missing dual_emac_res_vlan in DT.
> >> >> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> >> >> >> [    1.312500] Missing dual_emac_res_vlan in DT.
> >> >> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> >> >> >> [    1.382812] Freeing init memory: 236K
> >> >> >> sh: write error: No such device
> >> >> >> Cannot identify '/dev/camera0': 2, No such file or directory
> >> >> >> Parsing config from /xen/images/DomUAndroid.cfg
> >> >> >> XSM Disabled: seclabel not supported
> >> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> >> dom1 access to irq 53: Function not implemented
> >> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> >> dom1 access to irq 71: Function not implemented
> >> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> >> dom1 access to irq 173: Function not implemented
> >> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> >> dom1 access to irq 174: Function not implemented
> >> >> >> Turning on vfb in domain 1
> >> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> >> still lr_pending
> >> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> >> still lr_pending
> >> >> >> Parsing config from /xen/images/DomUQNX.cfg
> >> >> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> >> >> >> inject irq=2 into d0v0, when it is still lr_pending
> >> >> >>
> >> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> >> still lr_pending
> >> >> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> >> >> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> >> >> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> >> >> >> found: Invalid kernel
> >> >> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> >> >> >> failed: No such file or directory
> >> >> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> >> >> >> (re-)build domain: -3
> >> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> >> still lr_pending
> >> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> >> still lr_pending
> >> >> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
> >> >> >> Turning on vkbd in domain 1
> >> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> >> still lr_pending
> >> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> >> still lr_pending
> >> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> >> still lr_pending
> >> >> >>
> >> >> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> >> >> >> trying to inject irq=2 into d0v0, when it is still lr_pending
> >> >> >>
> >> >> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> >> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> >> >> > OK got it. Give me a few mins
> >> >> >> >
> >> >> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> >> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> >> >> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
> >> >> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> >> >> >> >>
> >> >> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> >> >> >> >> other potential bugs introduced later.
> >> >> >> >>
> >> >> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> >>> What if I try on top of current master branch the following code:
> >> >> >> >>>
> >> >> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >> >> >>> index 31fb81a..6764ab7 100644
> >> >> >> >>> --- a/xen/arch/arm/gic-v2.c
> >> >> >> >>> +++ b/xen/arch/arm/gic-v2.c
> >> >> >> >>> @@ -36,6 +36,8 @@
> >> >> >> >>>  #include <asm/io.h>
> >> >> >> >>>  #include <asm/gic.h>
> >> >> >> >>>
> >> >> >> >>> +#define GIC_DEBUG 1
> >> >> >> >>> +
> >> >> >> >>>  /*
> >> >> >> >>>   * LR register definitions are GIC v2 specific.
> >> >> >> >>>   * Moved these definitions from header file to here
> >> >> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >> >>> index bcaded9..c03d6a6 100644
> >> >> >> >>> --- a/xen/arch/arm/gic.c
> >> >> >> >>> +++ b/xen/arch/arm/gic.c
> >> >> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> >> >> >> >>>
> >> >> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> >> >> >> >>> gic_hw_ops->info->nr_lrs) - 1))
> >> >> >> >>>
> >> >> >> >>> -#undef GIC_DEBUG
> >> >> >> >>> +#define GIC_DEBUG 1
> >> >> >> >>>
> >> >> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >> >> >>>
> >> >> >> >>> It is equivalent to what you proposing - my code contains
> >> >> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> >> >> >> >>> be executed:
> >> >> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> >> >> >> >>>
> >> >> >> >>> regards,
> >> >> >> >>> Andrii
> >> >> >> >>>
> >> >> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> >> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> >> >> >> >>> >> everything works fine
> >> >> >> >>> >> The following 2 patches fixes xen/master for my platform.
> >> >> >> >>> >>
> >> >> >> >>> >> Stefano, could you please take a look to these changes?
> >> >> >> >>> >>
> >> >> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> >> >> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> >> >> >> >>> >>
> >> >> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> >> >> >> >>> >>
> >> >> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> >> >> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >> >> >>> >>
> >> >> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >> >> >>> >> index 31fb81a..093ecdb 100644
> >> >> >> >>> >> --- a/xen/arch/arm/gic-v2.c
> >> >> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
> >> >> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> >> >> >> >>> >> pending_irq *p,
> >> >> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> >> >> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> >> >> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> >> >> >> >>> >>
> >> >> >> >>> >> -    if ( p->desc != NULL )
> >> >> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >> >> >>> >>      {
> >> >> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >> >> >>> >> -        else
> >> >> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> >> >> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> >> >> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >> >> >>> >> +    }
> >> >> >> >>> >> +    else if ( p->desc != NULL )
> >> >> >> >>> >> +    {
> >> >> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> >> >> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >> >> >>> >>      }
> >> >> >> >>> >>
> >> >> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> >> >> >> >>> >
> >> >> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> >> >> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> >> >> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> >> >> >> >>> > working correctly on OMAP5. This changes might only be better at
> >> >> >> >>> > "hiding" the real issue.
> >> >> >> >>> >
> >> >> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> >> >> >> >>> > maintenance interrupts doesn't work for software interrupts.
> >> >> >> >>> > The commit that should make them work correctly after the
> >> >> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> >> >> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> >> >> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> >> >> >> >>> > Maybe that doesn't work correctly on OMAP5.
> >> >> >> >>> >
> >> >> >> >>> > Could you try this patch on top of
> >> >> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> >> >> >> >>> > if the problem is specifically with software irqs.
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >> >>> > index b7516c0..d8a17c9 100644
> >> >> >> >>> > --- a/xen/arch/arm/gic.c
> >> >> >> >>> > +++ b/xen/arch/arm/gic.c
> >> >> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> >> >> >> >>> >  /* Maximum cpu interface per GIC */
> >> >> >> >>> >  #define NR_GIC_CPU_IF 8
> >> >> >> >>> >
> >> >> >> >>> > -#undef GIC_DEBUG
> >> >> >> >>> > +#define GIC_DEBUG 1
> >> >> >> >>> >
> >> >> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >> >> >>> >
> >> >> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> >> >> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >> >> >> >>> >      if ( p->desc != NULL )
> >> >> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> >> >> >> >>> > +    else
> >> >> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> >> >> >> >>> >
> >> >> >> >>> >      GICH[GICH_LR + lr] = lr_val;
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> --
> >> >> >> >>>
> >> >> >> >>> Andrii Tseglytskyi | Embedded Dev
> >> >> >> >>> GlobalLogic
> >> >> >> >>> www.globallogic.com
> >> >> >> >>>
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> >
> >> >> >> > Andrii Tseglytskyi | Embedded Dev
> >> >> >> > GlobalLogic
> >> >> >> > www.globallogic.com
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >>
> >> >> >> Andrii Tseglytskyi | Embedded Dev
> >> >> >> GlobalLogic
> >> >> >> www.globallogic.com
> >> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> Andrii Tseglytskyi | Embedded Dev
> >> >> GlobalLogic
> >> >> www.globallogic.com
> >> >>
> >>
> >>
> >>
> >> --
> >>
> >> Andrii Tseglytskyi | Embedded Dev
> >> GlobalLogic
> >> www.globallogic.com
> >>
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:10:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12: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.xen.org>)
	id 1Xr44x-0004HR-TM; Wed, 19 Nov 2014 12:09:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr44w-0004HH-PD
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 12:09:46 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	BA/C1-17735-A888C645; Wed, 19 Nov 2014 12:09:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416398983!12421985!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28884 invoked from network); 19 Nov 2014 12:09:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 12:09:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194352544"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 07:09:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr3w8-00015B-GA;
	Wed, 19 Nov 2014 12:00:40 +0000
Date: Wed, 19 Nov 2014 12:00:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <4EC8C166-7BA3-4F63-A09A-097F4FD67652@oracle.com>
Message-ID: <alpine.DEB.2.02.1411191200100.27247@kaball.uk.xensource.com>
References: <1416259239-13281-1-git-send-email-dslutz@verizon.com>
	<alpine.DEB.2.02.1411181410440.27247@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411191052330.27247@kaball.uk.xensource.com>
	<4EC8C166-7BA3-4F63-A09A-097F4FD67652@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Don Slutz <dslutz@verizon.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [BUGFIX][PATCH for 2.2 1/1] hw/ide/core.c: Prevent
 SIGSEGV during migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On November 19, 2014 5:52:58 AM EST, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> >ping?
> >
> >On Tue, 18 Nov 2014, Stefano Stabellini wrote:
> >> Konrad,
> >> I think we should have this fix in Xen 4.5. Should I go ahead and
> >> backport it?
> 
> Go for it. Release-Acked-by: Konrad Rzeszutek Wilk (konrad.wilk@oracle.com)

Done, thanks!


> >> 
> >> On Mon, 17 Nov 2014, Don Slutz wrote:
> >> > The other callers to blk_set_enable_write_cache() in this file
> >> > already check for s->blk == NULL.
> >> > 
> >> > Signed-off-by: Don Slutz <dslutz@verizon.com>
> >> > ---
> >> > 
> >> > I think this is a bugfix that should be back ported to stable
> >> > releases.
> >> > 
> >> > I also think this should be done in xen's copy of QEMU for 4.5 with
> >> > back port(s) to active stable releases.
> >> > 
> >> > Note: In 2.1 and earlier the routine is
> >> > bdrv_set_enable_write_cache(); variable is s->bs.
> >> > 
> >> >  hw/ide/core.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> > 
> >> > diff --git a/hw/ide/core.c b/hw/ide/core.c
> >> > index 00e21cf..d4af5e2 100644
> >> > --- a/hw/ide/core.c
> >> > +++ b/hw/ide/core.c
> >> > @@ -2401,7 +2401,7 @@ static int ide_drive_post_load(void *opaque,
> >int version_id)
> >> >  {
> >> >      IDEState *s = opaque;
> >> >  
> >> > -    if (s->identify_set) {
> >> > +    if (s->blk && s->identify_set) {
> >> >          blk_set_enable_write_cache(s->blk, !!(s->identify_data[85]
> >& (1 << 5)));
> >> >      }
> >> >      return 0;
> >> > -- 
> >> > 1.8.4
> >> > 
> >> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:10:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12: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.xen.org>)
	id 1Xr44z-0004HY-94; Wed, 19 Nov 2014 12:09:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr44x-0004HM-HG
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:09:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	60/1F-09936-A888C645; Wed, 19 Nov 2014 12:09:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416398984!13852874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22226 invoked from network); 19 Nov 2014 12:09:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 12:09:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194352550"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 07:09:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr3vA-000145-Sv;
	Wed, 19 Nov 2014 11:59:40 +0000
Date: Wed, 19 Nov 2014 11:59:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 1:42 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> Hi Stefano,
> >> >>
> >> >> Thank you for your support.
> >> >>
> >> >> You are right - with latest change you've proposed I got a continuous
> >> >> prints during platform hang:
> >> >>
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> >> >>
> >> >> Looks line issue needs further deeper debugging.
> >> >
> >> > Cool! You could simply print what irqs are in all LRs when they are
> >> > full, for example you could call gic_dump_info. That would tell us what
> >> > is taking all the LRs space we have.
> >> >
> >> > How many LRs are available on omap5 anyway?
> >>
> >> :) Already done this:
> >>
> >>
> >> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=27 nr_lrs 4 i 4 into d0v0
> >> (XEN) GICH_LRs (vcpu 0) mask=f
> >> (XEN)    HW_LR[0]=1a00001f
> >> (XEN)    HW_LR[1]=9a00e439
> >> (XEN)    HW_LR[2]=1a000002
> >> (XEN)    HW_LR[3]=9a015856
> >> (XEN) Inflight irq=31 lr=0
> >> (XEN) Inflight irq=57 lr=1
> >> (XEN) Inflight irq=2 lr=2
> >> (XEN) Inflight irq=86 lr=3
> >> (XEN) Inflight irq=27 lr=255
> >> (XEN) Pending irq=27
> >
> > 27 should be the virtual timer if I remember correctly.
> >
> > So it looks like there is not actually anything wrong, is just that you
> > have too much inflight irqs? It should cause problems because in that
> > case GICH_HCR_UIE should be set and you should get a maintenance
> > interrupt when LRs become available (actually when "none, or only one,
> > of the List register entries is marked as a valid interrupt").
> >
> > Maybe GICH_HCR_UIE is the one that doesn't work properly. It might be
> > worth checking that you are receiving maintenance interrupts:
> >
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index b7516c0..b3eaa44 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >       * on return to guest that is going to clear the old LRs and inject
> >       * new interrupts.
> >       */
> > +
> > +    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
> >  }
> >
> 
> I observe this print during hang, so maintenance interrupt occurs.
> Can I perform some kind of LRs cleanup inside its handler?

It should happen automatically because on hypervisor entry gic_clear_lrs
gets called. In fact by the time you see this message the LRs should
have already been cleared.


> >  void gic_dump_info(struct vcpu *v)
> >
> >
> > You could also try to replace GICH_HCR_UIE with GICH_HCR_NPIE, you
> > should still be receiving maintenance interrupts when one or more LRs
> > become available.
> 
> Sorry didn't get, do you mean this change ?
> 
> @@ -759,9 +760,9 @@ void gic_inject(void)
> 
> 
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>      else
> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> 
>  }

Yes, exactly


> 
> >
> >
> >> >
> >> > I doubt you have so much interrupt traffic to actually fill all the LRs,
> >> > so I am thinking that a few LRs might not be cleared properly (that
> >> > should happen on hypervisor entry, gic_update_one_lr should take care of
> >> > it).
> >>
> >> This actually explains why this happens during domU start - SGI
> >> traffic might be very heavy this time
> >>
> >> >
> >> >
> >> >> Regards,
> >> >> Andrii
> >> >>
> >> >> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
> >> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> > Hello Andrii,
> >> >> > we are getting closer :-)
> >> >> >
> >> >> > It would help if you post the output with GIC_DEBUG defined but without
> >> >> > the other change that "fixes" the issue.
> >> >> >
> >> >> > I think the problem is probably due to software irqs.
> >> >> > You are getting too many
> >> >> >
> >> >> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
> >> >> >
> >> >> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
> >> >> > VCPU). It would be best to investigate why, especially if you get many
> >> >> > more of the same messages without the MAINTENANCE_IRQ change I
> >> >> > suggested.
> >> >> >
> >> >> > This patch might also help understading the problem more:
> >> >> >
> >> >> >
> >> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> > index b7516c0..5eaeca2 100644
> >> >> > --- a/xen/arch/arm/gic.c
> >> >> > +++ b/xen/arch/arm/gic.c
> >> >> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
> >> >> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
> >> >> >      {
> >> >> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> >> >> > -        if ( i >= nr_lrs ) return;
> >> >> > +        if ( i >= nr_lrs )
> >> >> > +        {
> >> >> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> >> >> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
> >> >> > +            continue;
> >> >> > +        }
> >> >> >
> >> >> >          spin_lock_irqsave(&gic.lock, flags);
> >> >> >          gic_set_lr(i, p, GICH_LR_PENDING);
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> Hi Stefano,
> >> >> >>
> >> >> >> No hangs with this change.
> >> >> >> Complete log is the following:
> >> >> >>
> >> >> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> >> >> >> DRA752 ES1.0
> >> >> >> <ethaddr> not set. Validating first E-fuse MAC
> >> >> >> cpsw
> >> >> >> - UART enabled -
> >> >> >> - CPU 00000000 booting -
> >> >> >> - Xen starting in Hyp mode -
> >> >> >> - Zero BSS -
> >> >> >> - Setting up control registers -
> >> >> >> - Turning on paging -
> >> >> >> - Ready -
> >> >> >> (XEN) Checking for initrd in /chosen
> >> >> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
> >> >> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> >> >> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> >> >> >> (XEN)
> >> >> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> >> >> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> >> >> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> >> >> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> >> >> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> >> >> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> >> >> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> >> >> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> >> >> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> >> >> >> (XEN)
> >> >> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> >> >> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> >> >> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> >> >> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> >> >> >> (XEN) Dom heap: 344064 pages
> >> >> >> (XEN) Domain heap initialised
> >> >> >> (XEN) Looking for UART console serial0
> >> >> >>  Xen 4.5-unstable
> >> >> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> >> >> >> (arm-linux-gnueabihf-gcc (crosstool-NG
> >> >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> >> >> >> 20130328 (prerelease)) debu4
> >> >> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> >> >> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> >> >> >> (XEN) 32-bit Execution:
> >> >> >> (XEN)   Processor Features: 00001131:00011011
> >> >> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> >> >> >> (XEN)     Extensions: GenericTimer Security
> >> >> >> (XEN)   Debug Features: 02010555
> >> >> >> (XEN)   Auxiliary Features: 00000000
> >> >> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> >> >> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> >> >> >> (XEN) Platform: TI DRA7
> >> >> >> (XEN) /psci method must be smc, but is: "hvc"
> >> >> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> >> >> >> (XEN) Set AuxCoreBoot0 to 0x20
> >> >> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> >> >> >> (XEN) Using generic timer at 6144 KHz
> >> >> >> (XEN) GIC initialization:
> >> >> >> (XEN)         gic_dist_addr=0000000048211000
> >> >> >> (XEN)         gic_cpu_addr=0000000048212000
> >> >> >> (XEN)         gic_hyp_addr=0000000048214000
> >> >> >> (XEN)         gic_vcpu_addr=0000000048216000
> >> >> >> (XEN)         gic_maintenance_irq=25
> >> >> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> >> >> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> >> >> >> (XEN) I/O virtualisation disabled
> >> >> >> (XEN) Allocated console ring of 16 KiB.
> >> >> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> >> >> >> (XEN) Bringing up CPU1
> >> >> >> - CPU 00000001 booting -
> >> >> >> - Xen starting in Hyp mode -
> >> >> >> - Setting up control registers -
> >> >> >> - Turning on paging -
> >> >> >> - Ready -
> >> >> >> (XEN) CPU 1 booted.
> >> >> >> (XEN) Brought up 2 CPUs
> >> >> >> (XEN) *** LOADING DOMAIN 0 ***
> >> >> >> (XEN) Loading kernel from boot module 2
> >> >> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> >> >> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> >> >> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> >> >> >> (XEN) Std. Loglevel: All
> >> >> >> (XEN) Guest Loglevel: All
> >> >> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> >> >> >> input to Xen)
> >> >> >> (XEN) Freed 272kB init memory.
> >> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> >> >> already pending in LR0
> >> >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> >> >> >> already pending in LR0
> >> >> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> >> >> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> >> >> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> >> >> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> >> >> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> >> >> >> /ocp/i2c@48072000/camera_ov10635
> >> >> >> [    0.437500] ldo3: operation not allowed
> >> >> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> >> >> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> >> >> >> [    0.468750] ov1063x 1-0030: No deserializer node found
> >> >> >> [    0.468750] ov1063x 1-0030: No serializer node found
> >> >> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> >> >> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> >> >> >> [    0.578125] ahci ahci.0.auto: can't get clock
> >> >> >> [    0.898437] ldc_module_init
> >> >> >> [    1.304687] Missing dual_emac_res_vlan in DT.
> >> >> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> >> >> >> [    1.312500] Missing dual_emac_res_vlan in DT.
> >> >> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> >> >> >> [    1.382812] Freeing init memory: 236K
> >> >> >> sh: write error: No such device
> >> >> >> Cannot identify '/dev/camera0': 2, No such file or directory
> >> >> >> Parsing config from /xen/images/DomUAndroid.cfg
> >> >> >> XSM Disabled: seclabel not supported
> >> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> >> dom1 access to irq 53: Function not implemented
> >> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> >> dom1 access to irq 71: Function not implemented
> >> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> >> dom1 access to irq 173: Function not implemented
> >> >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> >> >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> >> >> >> dom1 access to irq 174: Function not implemented
> >> >> >> Turning on vfb in domain 1
> >> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> >> still lr_pending
> >> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> >> still lr_pending
> >> >> >> Parsing config from /xen/images/DomUQNX.cfg
> >> >> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> >> >> >> inject irq=2 into d0v0, when it is still lr_pending
> >> >> >>
> >> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> >> still lr_pending
> >> >> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> >> >> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> >> >> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> >> >> >> found: Invalid kernel
> >> >> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> >> >> >> failed: No such file or directory
> >> >> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> >> >> >> (re-)build domain: -3
> >> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> >> still lr_pending
> >> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> >> still lr_pending
> >> >> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
> >> >> >> Turning on vkbd in domain 1
> >> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> >> still lr_pending
> >> >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> >> >> >> still lr_pending
> >> >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> >> >> >> still lr_pending
> >> >> >>
> >> >> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> >> >> >> trying to inject irq=2 into d0v0, when it is still lr_pending
> >> >> >>
> >> >> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> >> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> >> >> > OK got it. Give me a few mins
> >> >> >> >
> >> >> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> >> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> >> >> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
> >> >> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> >> >> >> >>
> >> >> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> >> >> >> >> other potential bugs introduced later.
> >> >> >> >>
> >> >> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> >>> What if I try on top of current master branch the following code:
> >> >> >> >>>
> >> >> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >> >> >>> index 31fb81a..6764ab7 100644
> >> >> >> >>> --- a/xen/arch/arm/gic-v2.c
> >> >> >> >>> +++ b/xen/arch/arm/gic-v2.c
> >> >> >> >>> @@ -36,6 +36,8 @@
> >> >> >> >>>  #include <asm/io.h>
> >> >> >> >>>  #include <asm/gic.h>
> >> >> >> >>>
> >> >> >> >>> +#define GIC_DEBUG 1
> >> >> >> >>> +
> >> >> >> >>>  /*
> >> >> >> >>>   * LR register definitions are GIC v2 specific.
> >> >> >> >>>   * Moved these definitions from header file to here
> >> >> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >> >>> index bcaded9..c03d6a6 100644
> >> >> >> >>> --- a/xen/arch/arm/gic.c
> >> >> >> >>> +++ b/xen/arch/arm/gic.c
> >> >> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> >> >> >> >>>
> >> >> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> >> >> >> >>> gic_hw_ops->info->nr_lrs) - 1))
> >> >> >> >>>
> >> >> >> >>> -#undef GIC_DEBUG
> >> >> >> >>> +#define GIC_DEBUG 1
> >> >> >> >>>
> >> >> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >> >> >>>
> >> >> >> >>> It is equivalent to what you proposing - my code contains
> >> >> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> >> >> >> >>> be executed:
> >> >> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> >> >> >> >>>
> >> >> >> >>> regards,
> >> >> >> >>> Andrii
> >> >> >> >>>
> >> >> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> >> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> >> >> >> >>> >> everything works fine
> >> >> >> >>> >> The following 2 patches fixes xen/master for my platform.
> >> >> >> >>> >>
> >> >> >> >>> >> Stefano, could you please take a look to these changes?
> >> >> >> >>> >>
> >> >> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> >> >> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> >> >> >> >>> >>
> >> >> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> >> >> >> >>> >>
> >> >> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> >> >> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> >> >> >>> >>
> >> >> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> >> >> >> >>> >> index 31fb81a..093ecdb 100644
> >> >> >> >>> >> --- a/xen/arch/arm/gic-v2.c
> >> >> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
> >> >> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> >> >> >> >>> >> pending_irq *p,
> >> >> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> >> >> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> >> >> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> >> >> >> >>> >>
> >> >> >> >>> >> -    if ( p->desc != NULL )
> >> >> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >> >> >>> >>      {
> >> >> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> >> >> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >> >> >>> >> -        else
> >> >> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> >> >> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> >> >> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> >> >> >> >>> >> +    }
> >> >> >> >>> >> +    else if ( p->desc != NULL )
> >> >> >> >>> >> +    {
> >> >> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> >> >> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> >> >> >> >>> >>      }
> >> >> >> >>> >>
> >> >> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> >> >> >> >>> >
> >> >> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> >> >> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> >> >> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> >> >> >> >>> > working correctly on OMAP5. This changes might only be better at
> >> >> >> >>> > "hiding" the real issue.
> >> >> >> >>> >
> >> >> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> >> >> >> >>> > maintenance interrupts doesn't work for software interrupts.
> >> >> >> >>> > The commit that should make them work correctly after the
> >> >> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> >> >> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> >> >> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> >> >> >> >>> > Maybe that doesn't work correctly on OMAP5.
> >> >> >> >>> >
> >> >> >> >>> > Could you try this patch on top of
> >> >> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> >> >> >> >>> > if the problem is specifically with software irqs.
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >> >>> > index b7516c0..d8a17c9 100644
> >> >> >> >>> > --- a/xen/arch/arm/gic.c
> >> >> >> >>> > +++ b/xen/arch/arm/gic.c
> >> >> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> >> >> >> >>> >  /* Maximum cpu interface per GIC */
> >> >> >> >>> >  #define NR_GIC_CPU_IF 8
> >> >> >> >>> >
> >> >> >> >>> > -#undef GIC_DEBUG
> >> >> >> >>> > +#define GIC_DEBUG 1
> >> >> >> >>> >
> >> >> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> >> >> >> >>> >
> >> >> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> >> >> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >> >> >> >>> >      if ( p->desc != NULL )
> >> >> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> >> >> >> >>> > +    else
> >> >> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> >> >> >> >>> >
> >> >> >> >>> >      GICH[GICH_LR + lr] = lr_val;
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> --
> >> >> >> >>>
> >> >> >> >>> Andrii Tseglytskyi | Embedded Dev
> >> >> >> >>> GlobalLogic
> >> >> >> >>> www.globallogic.com
> >> >> >> >>>
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> >
> >> >> >> > Andrii Tseglytskyi | Embedded Dev
> >> >> >> > GlobalLogic
> >> >> >> > www.globallogic.com
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >>
> >> >> >> Andrii Tseglytskyi | Embedded Dev
> >> >> >> GlobalLogic
> >> >> >> www.globallogic.com
> >> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> Andrii Tseglytskyi | Embedded Dev
> >> >> GlobalLogic
> >> >> www.globallogic.com
> >> >>
> >>
> >>
> >>
> >> --
> >>
> >> Andrii Tseglytskyi | Embedded Dev
> >> GlobalLogic
> >> www.globallogic.com
> >>
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:13:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr48v-0004dO-7c; Wed, 19 Nov 2014 12:13:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr48u-0004dJ-AO
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:13:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6A/81-25276-F798C645; Wed, 19 Nov 2014 12:13:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416399229!13891712!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25994 invoked from network); 19 Nov 2014 12:13:50 -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;
	19 Nov 2014 12:13:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194353208"
Message-ID: <1416399227.29243.33.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 19 Nov 2014 12:13:47 +0000
In-Reply-To: <alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
> So it looks like there is not actually anything wrong, is just that you
> have too much inflight irqs? It should cause problems because in that
> case GICH_HCR_UIE should be set and you should get a maintenance
> interrupt when LRs become available (actually when "none, or only one,
> of the List register entries is marked as a valid interrupt").
> 
> Maybe GICH_HCR_UIE is the one that doesn't work properly.

How much testing did this aspect get when the no-maint-irq series
originally went in? Did you manage to find a workload which filled all
the LRs or try artificially limiting the number of LRs somehow in order
to provoke it?

I ask because my intuition is that this won't happen very much, meaning
those code paths may not be as well tested...



>  It might be
> worth checking that you are receiving maintenance interrupts:
> 
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index b7516c0..b3eaa44 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>       * on return to guest that is going to clear the old LRs and inject
>       * new interrupts.
>       */
> +    
> +    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
>  }
>  
>  void gic_dump_info(struct vcpu *v)
> 
>  
> You could also try to replace GICH_HCR_UIE with GICH_HCR_NPIE, you
> should still be receiving maintenance interrupts when one or more LRs
> become available.
> 
> 
> > >
> > > I doubt you have so much interrupt traffic to actually fill all the LRs,
> > > so I am thinking that a few LRs might not be cleared properly (that
> > > should happen on hypervisor entry, gic_update_one_lr should take care of
> > > it).
> > 
> > This actually explains why this happens during domU start - SGI
> > traffic might be very heavy this time
> > 
> > >
> > >
> > >> Regards,
> > >> Andrii
> > >>
> > >> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
> > >> <stefano.stabellini@eu.citrix.com> wrote:
> > >> > Hello Andrii,
> > >> > we are getting closer :-)
> > >> >
> > >> > It would help if you post the output with GIC_DEBUG defined but without
> > >> > the other change that "fixes" the issue.
> > >> >
> > >> > I think the problem is probably due to software irqs.
> > >> > You are getting too many
> > >> >
> > >> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
> > >> >
> > >> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
> > >> > VCPU). It would be best to investigate why, especially if you get many
> > >> > more of the same messages without the MAINTENANCE_IRQ change I
> > >> > suggested.
> > >> >
> > >> > This patch might also help understading the problem more:
> > >> >
> > >> >
> > >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > >> > index b7516c0..5eaeca2 100644
> > >> > --- a/xen/arch/arm/gic.c
> > >> > +++ b/xen/arch/arm/gic.c
> > >> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
> > >> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
> > >> >      {
> > >> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> > >> > -        if ( i >= nr_lrs ) return;
> > >> > +        if ( i >= nr_lrs )
> > >> > +        {
> > >> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> > >> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
> > >> > +            continue;
> > >> > +        }
> > >> >
> > >> >          spin_lock_irqsave(&gic.lock, flags);
> > >> >          gic_set_lr(i, p, GICH_LR_PENDING);
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > >> >> Hi Stefano,
> > >> >>
> > >> >> No hangs with this change.
> > >> >> Complete log is the following:
> > >> >>
> > >> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> > >> >> DRA752 ES1.0
> > >> >> <ethaddr> not set. Validating first E-fuse MAC
> > >> >> cpsw
> > >> >> - UART enabled -
> > >> >> - CPU 00000000 booting -
> > >> >> - Xen starting in Hyp mode -
> > >> >> - Zero BSS -
> > >> >> - Setting up control registers -
> > >> >> - Turning on paging -
> > >> >> - Ready -
> > >> >> (XEN) Checking for initrd in /chosen
> > >> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
> > >> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> > >> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> > >> >> (XEN)
> > >> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> > >> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> > >> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> > >> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> > >> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> > >> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> > >> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> > >> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> > >> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> > >> >> (XEN)
> > >> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> > >> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> > >> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> > >> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> > >> >> (XEN) Dom heap: 344064 pages
> > >> >> (XEN) Domain heap initialised
> > >> >> (XEN) Looking for UART console serial0
> > >> >>  Xen 4.5-unstable
> > >> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> > >> >> (arm-linux-gnueabihf-gcc (crosstool-NG
> > >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> > >> >> 20130328 (prerelease)) debu4
> > >> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> > >> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> > >> >> (XEN) 32-bit Execution:
> > >> >> (XEN)   Processor Features: 00001131:00011011
> > >> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> > >> >> (XEN)     Extensions: GenericTimer Security
> > >> >> (XEN)   Debug Features: 02010555
> > >> >> (XEN)   Auxiliary Features: 00000000
> > >> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> > >> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> > >> >> (XEN) Platform: TI DRA7
> > >> >> (XEN) /psci method must be smc, but is: "hvc"
> > >> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> > >> >> (XEN) Set AuxCoreBoot0 to 0x20
> > >> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> > >> >> (XEN) Using generic timer at 6144 KHz
> > >> >> (XEN) GIC initialization:
> > >> >> (XEN)         gic_dist_addr=0000000048211000
> > >> >> (XEN)         gic_cpu_addr=0000000048212000
> > >> >> (XEN)         gic_hyp_addr=0000000048214000
> > >> >> (XEN)         gic_vcpu_addr=0000000048216000
> > >> >> (XEN)         gic_maintenance_irq=25
> > >> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> > >> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > >> >> (XEN) I/O virtualisation disabled
> > >> >> (XEN) Allocated console ring of 16 KiB.
> > >> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> > >> >> (XEN) Bringing up CPU1
> > >> >> - CPU 00000001 booting -
> > >> >> - Xen starting in Hyp mode -
> > >> >> - Setting up control registers -
> > >> >> - Turning on paging -
> > >> >> - Ready -
> > >> >> (XEN) CPU 1 booted.
> > >> >> (XEN) Brought up 2 CPUs
> > >> >> (XEN) *** LOADING DOMAIN 0 ***
> > >> >> (XEN) Loading kernel from boot module 2
> > >> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> > >> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> > >> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> > >> >> (XEN) Std. Loglevel: All
> > >> >> (XEN) Guest Loglevel: All
> > >> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> > >> >> input to Xen)
> > >> >> (XEN) Freed 272kB init memory.
> > >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> > >> >> already pending in LR0
> > >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> > >> >> already pending in LR0
> > >> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> > >> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> > >> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> > >> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> > >> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> > >> >> /ocp/i2c@48072000/camera_ov10635
> > >> >> [    0.437500] ldo3: operation not allowed
> > >> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> > >> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> > >> >> [    0.468750] ov1063x 1-0030: No deserializer node found
> > >> >> [    0.468750] ov1063x 1-0030: No serializer node found
> > >> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> > >> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> > >> >> [    0.578125] ahci ahci.0.auto: can't get clock
> > >> >> [    0.898437] ldc_module_init
> > >> >> [    1.304687] Missing dual_emac_res_vlan in DT.
> > >> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> > >> >> [    1.312500] Missing dual_emac_res_vlan in DT.
> > >> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> > >> >> [    1.382812] Freeing init memory: 236K
> > >> >> sh: write error: No such device
> > >> >> Cannot identify '/dev/camera0': 2, No such file or directory
> > >> >> Parsing config from /xen/images/DomUAndroid.cfg
> > >> >> XSM Disabled: seclabel not supported
> > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > >> >> dom1 access to irq 53: Function not implemented
> > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > >> >> dom1 access to irq 71: Function not implemented
> > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > >> >> dom1 access to irq 173: Function not implemented
> > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > >> >> dom1 access to irq 174: Function not implemented
> > >> >> Turning on vfb in domain 1
> > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > >> >> still lr_pending
> > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > >> >> still lr_pending
> > >> >> Parsing config from /xen/images/DomUQNX.cfg
> > >> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> > >> >> inject irq=2 into d0v0, when it is still lr_pending
> > >> >>
> > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > >> >> still lr_pending
> > >> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> > >> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> > >> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> > >> >> found: Invalid kernel
> > >> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> > >> >> failed: No such file or directory
> > >> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> > >> >> (re-)build domain: -3
> > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > >> >> still lr_pending
> > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > >> >> still lr_pending
> > >> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
> > >> >> Turning on vkbd in domain 1
> > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > >> >> still lr_pending
> > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > >> >> still lr_pending
> > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > >> >> still lr_pending
> > >> >>
> > >> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> > >> >> trying to inject irq=2 into d0v0, when it is still lr_pending
> > >> >>
> > >> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> > >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> > >> >> > OK got it. Give me a few mins
> > >> >> >
> > >> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> > >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> > >> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> > >> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
> > >> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> > >> >> >>
> > >> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> > >> >> >> other potential bugs introduced later.
> > >> >> >>
> > >> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > >> >> >>> What if I try on top of current master branch the following code:
> > >> >> >>>
> > >> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > >> >> >>> index 31fb81a..6764ab7 100644
> > >> >> >>> --- a/xen/arch/arm/gic-v2.c
> > >> >> >>> +++ b/xen/arch/arm/gic-v2.c
> > >> >> >>> @@ -36,6 +36,8 @@
> > >> >> >>>  #include <asm/io.h>
> > >> >> >>>  #include <asm/gic.h>
> > >> >> >>>
> > >> >> >>> +#define GIC_DEBUG 1
> > >> >> >>> +
> > >> >> >>>  /*
> > >> >> >>>   * LR register definitions are GIC v2 specific.
> > >> >> >>>   * Moved these definitions from header file to here
> > >> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > >> >> >>> index bcaded9..c03d6a6 100644
> > >> >> >>> --- a/xen/arch/arm/gic.c
> > >> >> >>> +++ b/xen/arch/arm/gic.c
> > >> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> > >> >> >>>
> > >> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> > >> >> >>> gic_hw_ops->info->nr_lrs) - 1))
> > >> >> >>>
> > >> >> >>> -#undef GIC_DEBUG
> > >> >> >>> +#define GIC_DEBUG 1
> > >> >> >>>
> > >> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> > >> >> >>>
> > >> >> >>> It is equivalent to what you proposing - my code contains
> > >> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> > >> >> >>> be executed:
> > >> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> > >> >> >>>
> > >> >> >>> regards,
> > >> >> >>> Andrii
> > >> >> >>>
> > >> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> > >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> > >> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > >> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> > >> >> >>> >> everything works fine
> > >> >> >>> >> The following 2 patches fixes xen/master for my platform.
> > >> >> >>> >>
> > >> >> >>> >> Stefano, could you please take a look to these changes?
> > >> >> >>> >>
> > >> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> > >> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > >> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> > >> >> >>> >>
> > >> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> > >> >> >>> >>
> > >> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> > >> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > >> >> >>> >>
> > >> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > >> >> >>> >> index 31fb81a..093ecdb 100644
> > >> >> >>> >> --- a/xen/arch/arm/gic-v2.c
> > >> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
> > >> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> > >> >> >>> >> pending_irq *p,
> > >> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> > >> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> > >> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> > >> >> >>> >>
> > >> >> >>> >> -    if ( p->desc != NULL )
> > >> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> > >> >> >>> >>      {
> > >> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> > >> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> > >> >> >>> >> -        else
> > >> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> > >> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> > >> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> > >> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> > >> >> >>> >> +    }
> > >> >> >>> >> +    else if ( p->desc != NULL )
> > >> >> >>> >> +    {
> > >> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> > >> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> > >> >> >>> >>      }
> > >> >> >>> >>
> > >> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> > >> >> >>> >
> > >> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> > >> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> > >> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> > >> >> >>> > working correctly on OMAP5. This changes might only be better at
> > >> >> >>> > "hiding" the real issue.
> > >> >> >>> >
> > >> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> > >> >> >>> > maintenance interrupts doesn't work for software interrupts.
> > >> >> >>> > The commit that should make them work correctly after the
> > >> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> > >> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> > >> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> > >> >> >>> > Maybe that doesn't work correctly on OMAP5.
> > >> >> >>> >
> > >> >> >>> > Could you try this patch on top of
> > >> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> > >> >> >>> > if the problem is specifically with software irqs.
> > >> >> >>> >
> > >> >> >>> >
> > >> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > >> >> >>> > index b7516c0..d8a17c9 100644
> > >> >> >>> > --- a/xen/arch/arm/gic.c
> > >> >> >>> > +++ b/xen/arch/arm/gic.c
> > >> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> > >> >> >>> >  /* Maximum cpu interface per GIC */
> > >> >> >>> >  #define NR_GIC_CPU_IF 8
> > >> >> >>> >
> > >> >> >>> > -#undef GIC_DEBUG
> > >> >> >>> > +#define GIC_DEBUG 1
> > >> >> >>> >
> > >> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> > >> >> >>> >
> > >> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> > >> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> > >> >> >>> >      if ( p->desc != NULL )
> > >> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> > >> >> >>> > +    else
> > >> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> > >> >> >>> >
> > >> >> >>> >      GICH[GICH_LR + lr] = lr_val;
> > >> >> >>> >
> > >> >> >>>
> > >> >> >>>
> > >> >> >>>
> > >> >> >>> --
> > >> >> >>>
> > >> >> >>> Andrii Tseglytskyi | Embedded Dev
> > >> >> >>> GlobalLogic
> > >> >> >>> www.globallogic.com
> > >> >> >>>
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > --
> > >> >> >
> > >> >> > Andrii Tseglytskyi | Embedded Dev
> > >> >> > GlobalLogic
> > >> >> > www.globallogic.com
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >>
> > >> >> Andrii Tseglytskyi | Embedded Dev
> > >> >> GlobalLogic
> > >> >> www.globallogic.com
> > >> >>
> > >>
> > >>
> > >>
> > >> --
> > >>
> > >> Andrii Tseglytskyi | Embedded Dev
> > >> GlobalLogic
> > >> www.globallogic.com
> > >>
> > 
> > 
> > 
> > -- 
> > 
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:13:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr48v-0004dO-7c; Wed, 19 Nov 2014 12:13:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr48u-0004dJ-AO
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:13:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6A/81-25276-F798C645; Wed, 19 Nov 2014 12:13:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416399229!13891712!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25994 invoked from network); 19 Nov 2014 12:13:50 -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;
	19 Nov 2014 12:13:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="194353208"
Message-ID: <1416399227.29243.33.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 19 Nov 2014 12:13:47 +0000
In-Reply-To: <alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
> So it looks like there is not actually anything wrong, is just that you
> have too much inflight irqs? It should cause problems because in that
> case GICH_HCR_UIE should be set and you should get a maintenance
> interrupt when LRs become available (actually when "none, or only one,
> of the List register entries is marked as a valid interrupt").
> 
> Maybe GICH_HCR_UIE is the one that doesn't work properly.

How much testing did this aspect get when the no-maint-irq series
originally went in? Did you manage to find a workload which filled all
the LRs or try artificially limiting the number of LRs somehow in order
to provoke it?

I ask because my intuition is that this won't happen very much, meaning
those code paths may not be as well tested...



>  It might be
> worth checking that you are receiving maintenance interrupts:
> 
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index b7516c0..b3eaa44 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>       * on return to guest that is going to clear the old LRs and inject
>       * new interrupts.
>       */
> +    
> +    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
>  }
>  
>  void gic_dump_info(struct vcpu *v)
> 
>  
> You could also try to replace GICH_HCR_UIE with GICH_HCR_NPIE, you
> should still be receiving maintenance interrupts when one or more LRs
> become available.
> 
> 
> > >
> > > I doubt you have so much interrupt traffic to actually fill all the LRs,
> > > so I am thinking that a few LRs might not be cleared properly (that
> > > should happen on hypervisor entry, gic_update_one_lr should take care of
> > > it).
> > 
> > This actually explains why this happens during domU start - SGI
> > traffic might be very heavy this time
> > 
> > >
> > >
> > >> Regards,
> > >> Andrii
> > >>
> > >> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
> > >> <stefano.stabellini@eu.citrix.com> wrote:
> > >> > Hello Andrii,
> > >> > we are getting closer :-)
> > >> >
> > >> > It would help if you post the output with GIC_DEBUG defined but without
> > >> > the other change that "fixes" the issue.
> > >> >
> > >> > I think the problem is probably due to software irqs.
> > >> > You are getting too many
> > >> >
> > >> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
> > >> >
> > >> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
> > >> > VCPU). It would be best to investigate why, especially if you get many
> > >> > more of the same messages without the MAINTENANCE_IRQ change I
> > >> > suggested.
> > >> >
> > >> > This patch might also help understading the problem more:
> > >> >
> > >> >
> > >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > >> > index b7516c0..5eaeca2 100644
> > >> > --- a/xen/arch/arm/gic.c
> > >> > +++ b/xen/arch/arm/gic.c
> > >> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
> > >> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
> > >> >      {
> > >> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> > >> > -        if ( i >= nr_lrs ) return;
> > >> > +        if ( i >= nr_lrs )
> > >> > +        {
> > >> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> > >> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
> > >> > +            continue;
> > >> > +        }
> > >> >
> > >> >          spin_lock_irqsave(&gic.lock, flags);
> > >> >          gic_set_lr(i, p, GICH_LR_PENDING);
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > >> >> Hi Stefano,
> > >> >>
> > >> >> No hangs with this change.
> > >> >> Complete log is the following:
> > >> >>
> > >> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> > >> >> DRA752 ES1.0
> > >> >> <ethaddr> not set. Validating first E-fuse MAC
> > >> >> cpsw
> > >> >> - UART enabled -
> > >> >> - CPU 00000000 booting -
> > >> >> - Xen starting in Hyp mode -
> > >> >> - Zero BSS -
> > >> >> - Setting up control registers -
> > >> >> - Turning on paging -
> > >> >> - Ready -
> > >> >> (XEN) Checking for initrd in /chosen
> > >> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
> > >> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> > >> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> > >> >> (XEN)
> > >> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> > >> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> > >> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> > >> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> > >> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> > >> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> > >> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> > >> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> > >> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> > >> >> (XEN)
> > >> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> > >> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> > >> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> > >> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> > >> >> (XEN) Dom heap: 344064 pages
> > >> >> (XEN) Domain heap initialised
> > >> >> (XEN) Looking for UART console serial0
> > >> >>  Xen 4.5-unstable
> > >> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> > >> >> (arm-linux-gnueabihf-gcc (crosstool-NG
> > >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> > >> >> 20130328 (prerelease)) debu4
> > >> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> > >> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> > >> >> (XEN) 32-bit Execution:
> > >> >> (XEN)   Processor Features: 00001131:00011011
> > >> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> > >> >> (XEN)     Extensions: GenericTimer Security
> > >> >> (XEN)   Debug Features: 02010555
> > >> >> (XEN)   Auxiliary Features: 00000000
> > >> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> > >> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> > >> >> (XEN) Platform: TI DRA7
> > >> >> (XEN) /psci method must be smc, but is: "hvc"
> > >> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> > >> >> (XEN) Set AuxCoreBoot0 to 0x20
> > >> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> > >> >> (XEN) Using generic timer at 6144 KHz
> > >> >> (XEN) GIC initialization:
> > >> >> (XEN)         gic_dist_addr=0000000048211000
> > >> >> (XEN)         gic_cpu_addr=0000000048212000
> > >> >> (XEN)         gic_hyp_addr=0000000048214000
> > >> >> (XEN)         gic_vcpu_addr=0000000048216000
> > >> >> (XEN)         gic_maintenance_irq=25
> > >> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> > >> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > >> >> (XEN) I/O virtualisation disabled
> > >> >> (XEN) Allocated console ring of 16 KiB.
> > >> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> > >> >> (XEN) Bringing up CPU1
> > >> >> - CPU 00000001 booting -
> > >> >> - Xen starting in Hyp mode -
> > >> >> - Setting up control registers -
> > >> >> - Turning on paging -
> > >> >> - Ready -
> > >> >> (XEN) CPU 1 booted.
> > >> >> (XEN) Brought up 2 CPUs
> > >> >> (XEN) *** LOADING DOMAIN 0 ***
> > >> >> (XEN) Loading kernel from boot module 2
> > >> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> > >> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> > >> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> > >> >> (XEN) Std. Loglevel: All
> > >> >> (XEN) Guest Loglevel: All
> > >> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> > >> >> input to Xen)
> > >> >> (XEN) Freed 272kB init memory.
> > >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> > >> >> already pending in LR0
> > >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> > >> >> already pending in LR0
> > >> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> > >> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> > >> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> > >> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> > >> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> > >> >> /ocp/i2c@48072000/camera_ov10635
> > >> >> [    0.437500] ldo3: operation not allowed
> > >> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> > >> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> > >> >> [    0.468750] ov1063x 1-0030: No deserializer node found
> > >> >> [    0.468750] ov1063x 1-0030: No serializer node found
> > >> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> > >> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> > >> >> [    0.578125] ahci ahci.0.auto: can't get clock
> > >> >> [    0.898437] ldc_module_init
> > >> >> [    1.304687] Missing dual_emac_res_vlan in DT.
> > >> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> > >> >> [    1.312500] Missing dual_emac_res_vlan in DT.
> > >> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> > >> >> [    1.382812] Freeing init memory: 236K
> > >> >> sh: write error: No such device
> > >> >> Cannot identify '/dev/camera0': 2, No such file or directory
> > >> >> Parsing config from /xen/images/DomUAndroid.cfg
> > >> >> XSM Disabled: seclabel not supported
> > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > >> >> dom1 access to irq 53: Function not implemented
> > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > >> >> dom1 access to irq 71: Function not implemented
> > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > >> >> dom1 access to irq 173: Function not implemented
> > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > >> >> dom1 access to irq 174: Function not implemented
> > >> >> Turning on vfb in domain 1
> > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > >> >> still lr_pending
> > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > >> >> still lr_pending
> > >> >> Parsing config from /xen/images/DomUQNX.cfg
> > >> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> > >> >> inject irq=2 into d0v0, when it is still lr_pending
> > >> >>
> > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > >> >> still lr_pending
> > >> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> > >> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> > >> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> > >> >> found: Invalid kernel
> > >> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> > >> >> failed: No such file or directory
> > >> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> > >> >> (re-)build domain: -3
> > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > >> >> still lr_pending
> > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > >> >> still lr_pending
> > >> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
> > >> >> Turning on vkbd in domain 1
> > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > >> >> still lr_pending
> > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > >> >> still lr_pending
> > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > >> >> still lr_pending
> > >> >>
> > >> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> > >> >> trying to inject irq=2 into d0v0, when it is still lr_pending
> > >> >>
> > >> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> > >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> > >> >> > OK got it. Give me a few mins
> > >> >> >
> > >> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> > >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> > >> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> > >> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
> > >> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> > >> >> >>
> > >> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> > >> >> >> other potential bugs introduced later.
> > >> >> >>
> > >> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > >> >> >>> What if I try on top of current master branch the following code:
> > >> >> >>>
> > >> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > >> >> >>> index 31fb81a..6764ab7 100644
> > >> >> >>> --- a/xen/arch/arm/gic-v2.c
> > >> >> >>> +++ b/xen/arch/arm/gic-v2.c
> > >> >> >>> @@ -36,6 +36,8 @@
> > >> >> >>>  #include <asm/io.h>
> > >> >> >>>  #include <asm/gic.h>
> > >> >> >>>
> > >> >> >>> +#define GIC_DEBUG 1
> > >> >> >>> +
> > >> >> >>>  /*
> > >> >> >>>   * LR register definitions are GIC v2 specific.
> > >> >> >>>   * Moved these definitions from header file to here
> > >> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > >> >> >>> index bcaded9..c03d6a6 100644
> > >> >> >>> --- a/xen/arch/arm/gic.c
> > >> >> >>> +++ b/xen/arch/arm/gic.c
> > >> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> > >> >> >>>
> > >> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> > >> >> >>> gic_hw_ops->info->nr_lrs) - 1))
> > >> >> >>>
> > >> >> >>> -#undef GIC_DEBUG
> > >> >> >>> +#define GIC_DEBUG 1
> > >> >> >>>
> > >> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> > >> >> >>>
> > >> >> >>> It is equivalent to what you proposing - my code contains
> > >> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> > >> >> >>> be executed:
> > >> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> > >> >> >>>
> > >> >> >>> regards,
> > >> >> >>> Andrii
> > >> >> >>>
> > >> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> > >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> > >> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > >> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> > >> >> >>> >> everything works fine
> > >> >> >>> >> The following 2 patches fixes xen/master for my platform.
> > >> >> >>> >>
> > >> >> >>> >> Stefano, could you please take a look to these changes?
> > >> >> >>> >>
> > >> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> > >> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > >> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> > >> >> >>> >>
> > >> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> > >> >> >>> >>
> > >> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> > >> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > >> >> >>> >>
> > >> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > >> >> >>> >> index 31fb81a..093ecdb 100644
> > >> >> >>> >> --- a/xen/arch/arm/gic-v2.c
> > >> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
> > >> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> > >> >> >>> >> pending_irq *p,
> > >> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> > >> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> > >> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> > >> >> >>> >>
> > >> >> >>> >> -    if ( p->desc != NULL )
> > >> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> > >> >> >>> >>      {
> > >> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> > >> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> > >> >> >>> >> -        else
> > >> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> > >> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> > >> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> > >> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> > >> >> >>> >> +    }
> > >> >> >>> >> +    else if ( p->desc != NULL )
> > >> >> >>> >> +    {
> > >> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> > >> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> > >> >> >>> >>      }
> > >> >> >>> >>
> > >> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> > >> >> >>> >
> > >> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> > >> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> > >> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> > >> >> >>> > working correctly on OMAP5. This changes might only be better at
> > >> >> >>> > "hiding" the real issue.
> > >> >> >>> >
> > >> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> > >> >> >>> > maintenance interrupts doesn't work for software interrupts.
> > >> >> >>> > The commit that should make them work correctly after the
> > >> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> > >> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> > >> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> > >> >> >>> > Maybe that doesn't work correctly on OMAP5.
> > >> >> >>> >
> > >> >> >>> > Could you try this patch on top of
> > >> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> > >> >> >>> > if the problem is specifically with software irqs.
> > >> >> >>> >
> > >> >> >>> >
> > >> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > >> >> >>> > index b7516c0..d8a17c9 100644
> > >> >> >>> > --- a/xen/arch/arm/gic.c
> > >> >> >>> > +++ b/xen/arch/arm/gic.c
> > >> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> > >> >> >>> >  /* Maximum cpu interface per GIC */
> > >> >> >>> >  #define NR_GIC_CPU_IF 8
> > >> >> >>> >
> > >> >> >>> > -#undef GIC_DEBUG
> > >> >> >>> > +#define GIC_DEBUG 1
> > >> >> >>> >
> > >> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> > >> >> >>> >
> > >> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> > >> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> > >> >> >>> >      if ( p->desc != NULL )
> > >> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> > >> >> >>> > +    else
> > >> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> > >> >> >>> >
> > >> >> >>> >      GICH[GICH_LR + lr] = lr_val;
> > >> >> >>> >
> > >> >> >>>
> > >> >> >>>
> > >> >> >>>
> > >> >> >>> --
> > >> >> >>>
> > >> >> >>> Andrii Tseglytskyi | Embedded Dev
> > >> >> >>> GlobalLogic
> > >> >> >>> www.globallogic.com
> > >> >> >>>
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > --
> > >> >> >
> > >> >> > Andrii Tseglytskyi | Embedded Dev
> > >> >> > GlobalLogic
> > >> >> > www.globallogic.com
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >>
> > >> >> Andrii Tseglytskyi | Embedded Dev
> > >> >> GlobalLogic
> > >> >> www.globallogic.com
> > >> >>
> > >>
> > >>
> > >>
> > >> --
> > >>
> > >> Andrii Tseglytskyi | Embedded Dev
> > >> GlobalLogic
> > >> www.globallogic.com
> > >>
> > 
> > 
> > 
> > -- 
> > 
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:17:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12: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 1Xr4Ce-0004m8-Ac; Wed, 19 Nov 2014 12:17:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr4Cc-0004m3-Si
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:17:43 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	F9/12-14214-66A8C645; Wed, 19 Nov 2014 12:17:42 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416399459!12216853!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16419 invoked from network); 19 Nov 2014 12:17:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 12:17:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192839180"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 07:17:38 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr4CX-0001W2-Vj;
	Wed, 19 Nov 2014 12:17:37 +0000
Date: Wed, 19 Nov 2014 12:17:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416399227.29243.33.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<1416399227.29243.33.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Ian Campbell wrote:
> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
> > So it looks like there is not actually anything wrong, is just that you
> > have too much inflight irqs? It should cause problems because in that
> > case GICH_HCR_UIE should be set and you should get a maintenance
> > interrupt when LRs become available (actually when "none, or only one,
> > of the List register entries is marked as a valid interrupt").
> > 
> > Maybe GICH_HCR_UIE is the one that doesn't work properly.
> 
> How much testing did this aspect get when the no-maint-irq series
> originally went in? Did you manage to find a workload which filled all
> the LRs or try artificially limiting the number of LRs somehow in order
> to provoke it?
> 
> I ask because my intuition is that this won't happen very much, meaning
> those code paths may not be as well tested...

I did test it by artificially limiting the number of LRs to 1.
However there have been many iterations of that series and I didn't run
this test at every iteration.

 
> 
> >  It might be
> > worth checking that you are receiving maintenance interrupts:
> > 
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index b7516c0..b3eaa44 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >       * on return to guest that is going to clear the old LRs and inject
> >       * new interrupts.
> >       */
> > +    
> > +    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
> >  }
> >  
> >  void gic_dump_info(struct vcpu *v)
> > 
> >  
> > You could also try to replace GICH_HCR_UIE with GICH_HCR_NPIE, you
> > should still be receiving maintenance interrupts when one or more LRs
> > become available.
> > 
> > 
> > > >
> > > > I doubt you have so much interrupt traffic to actually fill all the LRs,
> > > > so I am thinking that a few LRs might not be cleared properly (that
> > > > should happen on hypervisor entry, gic_update_one_lr should take care of
> > > > it).
> > > 
> > > This actually explains why this happens during domU start - SGI
> > > traffic might be very heavy this time
> > > 
> > > >
> > > >
> > > >> Regards,
> > > >> Andrii
> > > >>
> > > >> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
> > > >> <stefano.stabellini@eu.citrix.com> wrote:
> > > >> > Hello Andrii,
> > > >> > we are getting closer :-)
> > > >> >
> > > >> > It would help if you post the output with GIC_DEBUG defined but without
> > > >> > the other change that "fixes" the issue.
> > > >> >
> > > >> > I think the problem is probably due to software irqs.
> > > >> > You are getting too many
> > > >> >
> > > >> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
> > > >> >
> > > >> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
> > > >> > VCPU). It would be best to investigate why, especially if you get many
> > > >> > more of the same messages without the MAINTENANCE_IRQ change I
> > > >> > suggested.
> > > >> >
> > > >> > This patch might also help understading the problem more:
> > > >> >
> > > >> >
> > > >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > > >> > index b7516c0..5eaeca2 100644
> > > >> > --- a/xen/arch/arm/gic.c
> > > >> > +++ b/xen/arch/arm/gic.c
> > > >> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
> > > >> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
> > > >> >      {
> > > >> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> > > >> > -        if ( i >= nr_lrs ) return;
> > > >> > +        if ( i >= nr_lrs )
> > > >> > +        {
> > > >> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> > > >> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
> > > >> > +            continue;
> > > >> > +        }
> > > >> >
> > > >> >          spin_lock_irqsave(&gic.lock, flags);
> > > >> >          gic_set_lr(i, p, GICH_LR_PENDING);
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > > >> >> Hi Stefano,
> > > >> >>
> > > >> >> No hangs with this change.
> > > >> >> Complete log is the following:
> > > >> >>
> > > >> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> > > >> >> DRA752 ES1.0
> > > >> >> <ethaddr> not set. Validating first E-fuse MAC
> > > >> >> cpsw
> > > >> >> - UART enabled -
> > > >> >> - CPU 00000000 booting -
> > > >> >> - Xen starting in Hyp mode -
> > > >> >> - Zero BSS -
> > > >> >> - Setting up control registers -
> > > >> >> - Turning on paging -
> > > >> >> - Ready -
> > > >> >> (XEN) Checking for initrd in /chosen
> > > >> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
> > > >> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> > > >> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> > > >> >> (XEN)
> > > >> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> > > >> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> > > >> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> > > >> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> > > >> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> > > >> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> > > >> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> > > >> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> > > >> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> > > >> >> (XEN)
> > > >> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> > > >> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> > > >> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> > > >> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> > > >> >> (XEN) Dom heap: 344064 pages
> > > >> >> (XEN) Domain heap initialised
> > > >> >> (XEN) Looking for UART console serial0
> > > >> >>  Xen 4.5-unstable
> > > >> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> > > >> >> (arm-linux-gnueabihf-gcc (crosstool-NG
> > > >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> > > >> >> 20130328 (prerelease)) debu4
> > > >> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> > > >> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> > > >> >> (XEN) 32-bit Execution:
> > > >> >> (XEN)   Processor Features: 00001131:00011011
> > > >> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> > > >> >> (XEN)     Extensions: GenericTimer Security
> > > >> >> (XEN)   Debug Features: 02010555
> > > >> >> (XEN)   Auxiliary Features: 00000000
> > > >> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> > > >> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> > > >> >> (XEN) Platform: TI DRA7
> > > >> >> (XEN) /psci method must be smc, but is: "hvc"
> > > >> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> > > >> >> (XEN) Set AuxCoreBoot0 to 0x20
> > > >> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> > > >> >> (XEN) Using generic timer at 6144 KHz
> > > >> >> (XEN) GIC initialization:
> > > >> >> (XEN)         gic_dist_addr=0000000048211000
> > > >> >> (XEN)         gic_cpu_addr=0000000048212000
> > > >> >> (XEN)         gic_hyp_addr=0000000048214000
> > > >> >> (XEN)         gic_vcpu_addr=0000000048216000
> > > >> >> (XEN)         gic_maintenance_irq=25
> > > >> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> > > >> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > > >> >> (XEN) I/O virtualisation disabled
> > > >> >> (XEN) Allocated console ring of 16 KiB.
> > > >> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> > > >> >> (XEN) Bringing up CPU1
> > > >> >> - CPU 00000001 booting -
> > > >> >> - Xen starting in Hyp mode -
> > > >> >> - Setting up control registers -
> > > >> >> - Turning on paging -
> > > >> >> - Ready -
> > > >> >> (XEN) CPU 1 booted.
> > > >> >> (XEN) Brought up 2 CPUs
> > > >> >> (XEN) *** LOADING DOMAIN 0 ***
> > > >> >> (XEN) Loading kernel from boot module 2
> > > >> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> > > >> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> > > >> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> > > >> >> (XEN) Std. Loglevel: All
> > > >> >> (XEN) Guest Loglevel: All
> > > >> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> > > >> >> input to Xen)
> > > >> >> (XEN) Freed 272kB init memory.
> > > >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> > > >> >> already pending in LR0
> > > >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> > > >> >> already pending in LR0
> > > >> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> > > >> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> > > >> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> > > >> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> > > >> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> > > >> >> /ocp/i2c@48072000/camera_ov10635
> > > >> >> [    0.437500] ldo3: operation not allowed
> > > >> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> > > >> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> > > >> >> [    0.468750] ov1063x 1-0030: No deserializer node found
> > > >> >> [    0.468750] ov1063x 1-0030: No serializer node found
> > > >> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> > > >> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> > > >> >> [    0.578125] ahci ahci.0.auto: can't get clock
> > > >> >> [    0.898437] ldc_module_init
> > > >> >> [    1.304687] Missing dual_emac_res_vlan in DT.
> > > >> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> > > >> >> [    1.312500] Missing dual_emac_res_vlan in DT.
> > > >> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> > > >> >> [    1.382812] Freeing init memory: 236K
> > > >> >> sh: write error: No such device
> > > >> >> Cannot identify '/dev/camera0': 2, No such file or directory
> > > >> >> Parsing config from /xen/images/DomUAndroid.cfg
> > > >> >> XSM Disabled: seclabel not supported
> > > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > > >> >> dom1 access to irq 53: Function not implemented
> > > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > > >> >> dom1 access to irq 71: Function not implemented
> > > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > > >> >> dom1 access to irq 173: Function not implemented
> > > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > > >> >> dom1 access to irq 174: Function not implemented
> > > >> >> Turning on vfb in domain 1
> > > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > > >> >> still lr_pending
> > > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > > >> >> still lr_pending
> > > >> >> Parsing config from /xen/images/DomUQNX.cfg
> > > >> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> > > >> >> inject irq=2 into d0v0, when it is still lr_pending
> > > >> >>
> > > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > > >> >> still lr_pending
> > > >> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> > > >> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> > > >> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> > > >> >> found: Invalid kernel
> > > >> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> > > >> >> failed: No such file or directory
> > > >> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> > > >> >> (re-)build domain: -3
> > > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > > >> >> still lr_pending
> > > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > > >> >> still lr_pending
> > > >> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
> > > >> >> Turning on vkbd in domain 1
> > > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > > >> >> still lr_pending
> > > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > > >> >> still lr_pending
> > > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > > >> >> still lr_pending
> > > >> >>
> > > >> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> > > >> >> trying to inject irq=2 into d0v0, when it is still lr_pending
> > > >> >>
> > > >> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> > > >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> > > >> >> > OK got it. Give me a few mins
> > > >> >> >
> > > >> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> > > >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> > > >> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> > > >> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
> > > >> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> > > >> >> >>
> > > >> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> > > >> >> >> other potential bugs introduced later.
> > > >> >> >>
> > > >> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > > >> >> >>> What if I try on top of current master branch the following code:
> > > >> >> >>>
> > > >> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > > >> >> >>> index 31fb81a..6764ab7 100644
> > > >> >> >>> --- a/xen/arch/arm/gic-v2.c
> > > >> >> >>> +++ b/xen/arch/arm/gic-v2.c
> > > >> >> >>> @@ -36,6 +36,8 @@
> > > >> >> >>>  #include <asm/io.h>
> > > >> >> >>>  #include <asm/gic.h>
> > > >> >> >>>
> > > >> >> >>> +#define GIC_DEBUG 1
> > > >> >> >>> +
> > > >> >> >>>  /*
> > > >> >> >>>   * LR register definitions are GIC v2 specific.
> > > >> >> >>>   * Moved these definitions from header file to here
> > > >> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > > >> >> >>> index bcaded9..c03d6a6 100644
> > > >> >> >>> --- a/xen/arch/arm/gic.c
> > > >> >> >>> +++ b/xen/arch/arm/gic.c
> > > >> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> > > >> >> >>>
> > > >> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> > > >> >> >>> gic_hw_ops->info->nr_lrs) - 1))
> > > >> >> >>>
> > > >> >> >>> -#undef GIC_DEBUG
> > > >> >> >>> +#define GIC_DEBUG 1
> > > >> >> >>>
> > > >> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> > > >> >> >>>
> > > >> >> >>> It is equivalent to what you proposing - my code contains
> > > >> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> > > >> >> >>> be executed:
> > > >> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> > > >> >> >>>
> > > >> >> >>> regards,
> > > >> >> >>> Andrii
> > > >> >> >>>
> > > >> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> > > >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> > > >> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > > >> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> > > >> >> >>> >> everything works fine
> > > >> >> >>> >> The following 2 patches fixes xen/master for my platform.
> > > >> >> >>> >>
> > > >> >> >>> >> Stefano, could you please take a look to these changes?
> > > >> >> >>> >>
> > > >> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> > > >> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > > >> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> > > >> >> >>> >>
> > > >> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> > > >> >> >>> >>
> > > >> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> > > >> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > > >> >> >>> >>
> > > >> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > > >> >> >>> >> index 31fb81a..093ecdb 100644
> > > >> >> >>> >> --- a/xen/arch/arm/gic-v2.c
> > > >> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
> > > >> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> > > >> >> >>> >> pending_irq *p,
> > > >> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> > > >> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> > > >> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> > > >> >> >>> >>
> > > >> >> >>> >> -    if ( p->desc != NULL )
> > > >> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> > > >> >> >>> >>      {
> > > >> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> > > >> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> > > >> >> >>> >> -        else
> > > >> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> > > >> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> > > >> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> > > >> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> > > >> >> >>> >> +    }
> > > >> >> >>> >> +    else if ( p->desc != NULL )
> > > >> >> >>> >> +    {
> > > >> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> > > >> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> > > >> >> >>> >>      }
> > > >> >> >>> >>
> > > >> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> > > >> >> >>> >
> > > >> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> > > >> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> > > >> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> > > >> >> >>> > working correctly on OMAP5. This changes might only be better at
> > > >> >> >>> > "hiding" the real issue.
> > > >> >> >>> >
> > > >> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> > > >> >> >>> > maintenance interrupts doesn't work for software interrupts.
> > > >> >> >>> > The commit that should make them work correctly after the
> > > >> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> > > >> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> > > >> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> > > >> >> >>> > Maybe that doesn't work correctly on OMAP5.
> > > >> >> >>> >
> > > >> >> >>> > Could you try this patch on top of
> > > >> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> > > >> >> >>> > if the problem is specifically with software irqs.
> > > >> >> >>> >
> > > >> >> >>> >
> > > >> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > > >> >> >>> > index b7516c0..d8a17c9 100644
> > > >> >> >>> > --- a/xen/arch/arm/gic.c
> > > >> >> >>> > +++ b/xen/arch/arm/gic.c
> > > >> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> > > >> >> >>> >  /* Maximum cpu interface per GIC */
> > > >> >> >>> >  #define NR_GIC_CPU_IF 8
> > > >> >> >>> >
> > > >> >> >>> > -#undef GIC_DEBUG
> > > >> >> >>> > +#define GIC_DEBUG 1
> > > >> >> >>> >
> > > >> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> > > >> >> >>> >
> > > >> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> > > >> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> > > >> >> >>> >      if ( p->desc != NULL )
> > > >> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> > > >> >> >>> > +    else
> > > >> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> > > >> >> >>> >
> > > >> >> >>> >      GICH[GICH_LR + lr] = lr_val;
> > > >> >> >>> >
> > > >> >> >>>
> > > >> >> >>>
> > > >> >> >>>
> > > >> >> >>> --
> > > >> >> >>>
> > > >> >> >>> Andrii Tseglytskyi | Embedded Dev
> > > >> >> >>> GlobalLogic
> > > >> >> >>> www.globallogic.com
> > > >> >> >>>
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> > --
> > > >> >> >
> > > >> >> > Andrii Tseglytskyi | Embedded Dev
> > > >> >> > GlobalLogic
> > > >> >> > www.globallogic.com
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >>
> > > >> >> Andrii Tseglytskyi | Embedded Dev
> > > >> >> GlobalLogic
> > > >> >> www.globallogic.com
> > > >> >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> Andrii Tseglytskyi | Embedded Dev
> > > >> GlobalLogic
> > > >> www.globallogic.com
> > > >>
> > > 
> > > 
> > > 
> > > -- 
> > > 
> > > Andrii Tseglytskyi | Embedded Dev
> > > GlobalLogic
> > > www.globallogic.com
> > > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:17:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12: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 1Xr4Ce-0004m8-Ac; Wed, 19 Nov 2014 12:17:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr4Cc-0004m3-Si
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:17:43 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	F9/12-14214-66A8C645; Wed, 19 Nov 2014 12:17:42 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416399459!12216853!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16419 invoked from network); 19 Nov 2014 12:17:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 12:17:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,416,1413244800"; d="scan'208";a="192839180"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 07:17:38 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr4CX-0001W2-Vj;
	Wed, 19 Nov 2014 12:17:37 +0000
Date: Wed, 19 Nov 2014 12:17:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416399227.29243.33.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411171742360.26318@kaball.uk.xensource.com>
	<CAH_mUMOV4iHmyYOt4YLgsLZ5yxo4FL_+sfq1ACyJfg4p_7kqJA@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<1416399227.29243.33.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Ian Campbell wrote:
> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
> > So it looks like there is not actually anything wrong, is just that you
> > have too much inflight irqs? It should cause problems because in that
> > case GICH_HCR_UIE should be set and you should get a maintenance
> > interrupt when LRs become available (actually when "none, or only one,
> > of the List register entries is marked as a valid interrupt").
> > 
> > Maybe GICH_HCR_UIE is the one that doesn't work properly.
> 
> How much testing did this aspect get when the no-maint-irq series
> originally went in? Did you manage to find a workload which filled all
> the LRs or try artificially limiting the number of LRs somehow in order
> to provoke it?
> 
> I ask because my intuition is that this won't happen very much, meaning
> those code paths may not be as well tested...

I did test it by artificially limiting the number of LRs to 1.
However there have been many iterations of that series and I didn't run
this test at every iteration.

 
> 
> >  It might be
> > worth checking that you are receiving maintenance interrupts:
> > 
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index b7516c0..b3eaa44 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >       * on return to guest that is going to clear the old LRs and inject
> >       * new interrupts.
> >       */
> > +    
> > +    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
> >  }
> >  
> >  void gic_dump_info(struct vcpu *v)
> > 
> >  
> > You could also try to replace GICH_HCR_UIE with GICH_HCR_NPIE, you
> > should still be receiving maintenance interrupts when one or more LRs
> > become available.
> > 
> > 
> > > >
> > > > I doubt you have so much interrupt traffic to actually fill all the LRs,
> > > > so I am thinking that a few LRs might not be cleared properly (that
> > > > should happen on hypervisor entry, gic_update_one_lr should take care of
> > > > it).
> > > 
> > > This actually explains why this happens during domU start - SGI
> > > traffic might be very heavy this time
> > > 
> > > >
> > > >
> > > >> Regards,
> > > >> Andrii
> > > >>
> > > >> On Tue, Nov 18, 2014 at 7:51 PM, Stefano Stabellini
> > > >> <stefano.stabellini@eu.citrix.com> wrote:
> > > >> > Hello Andrii,
> > > >> > we are getting closer :-)
> > > >> >
> > > >> > It would help if you post the output with GIC_DEBUG defined but without
> > > >> > the other change that "fixes" the issue.
> > > >> >
> > > >> > I think the problem is probably due to software irqs.
> > > >> > You are getting too many
> > > >> >
> > > >> > gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending
> > > >> >
> > > >> > messages. That means you are loosing virtual SGIs (guest VCPU to guest
> > > >> > VCPU). It would be best to investigate why, especially if you get many
> > > >> > more of the same messages without the MAINTENANCE_IRQ change I
> > > >> > suggested.
> > > >> >
> > > >> > This patch might also help understading the problem more:
> > > >> >
> > > >> >
> > > >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > > >> > index b7516c0..5eaeca2 100644
> > > >> > --- a/xen/arch/arm/gic.c
> > > >> > +++ b/xen/arch/arm/gic.c
> > > >> > @@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
> > > >> >      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
> > > >> >      {
> > > >> >          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
> > > >> > -        if ( i >= nr_lrs ) return;
> > > >> > +        if ( i >= nr_lrs )
> > > >> > +        {
> > > >> > +            gdprintk(XENLOG_DEBUG, "LRs full, not injecting irq=%u into d%dv%d\n",
> > > >> > +                    p->irq, v->domain->domain_id, v->vcpu_id);
> > > >> > +            continue;
> > > >> > +        }
> > > >> >
> > > >> >          spin_lock_irqsave(&gic.lock, flags);
> > > >> >          gic_set_lr(i, p, GICH_LR_PENDING);
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > > >> >> Hi Stefano,
> > > >> >>
> > > >> >> No hangs with this change.
> > > >> >> Complete log is the following:
> > > >> >>
> > > >> >> U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
> > > >> >> DRA752 ES1.0
> > > >> >> <ethaddr> not set. Validating first E-fuse MAC
> > > >> >> cpsw
> > > >> >> - UART enabled -
> > > >> >> - CPU 00000000 booting -
> > > >> >> - Xen starting in Hyp mode -
> > > >> >> - Zero BSS -
> > > >> >> - Setting up control registers -
> > > >> >> - Turning on paging -
> > > >> >> - Ready -
> > > >> >> (XEN) Checking for initrd in /chosen
> > > >> >> (XEN) RAM: 0000000080000000 - 000000009fffffff
> > > >> >> (XEN) RAM: 00000000a0000000 - 00000000bfffffff
> > > >> >> (XEN) RAM: 00000000c0000000 - 00000000dfffffff
> > > >> >> (XEN)
> > > >> >> (XEN) MODULE[1]: 00000000c2000000 - 00000000c20069aa
> > > >> >> (XEN) MODULE[2]: 00000000c0000000 - 00000000c2000000
> > > >> >> (XEN) MODULE[3]: 0000000000000000 - 0000000000000000
> > > >> >> (XEN) MODULE[4]: 00000000c3000000 - 00000000c3010000
> > > >> >> (XEN)  RESVD[0]: 00000000ba300000 - 00000000bfd00000
> > > >> >> (XEN)  RESVD[1]: 0000000095800000 - 0000000095900000
> > > >> >> (XEN)  RESVD[2]: 0000000098a00000 - 0000000098b00000
> > > >> >> (XEN)  RESVD[3]: 0000000095f00000 - 0000000098a00000
> > > >> >> (XEN)  RESVD[4]: 0000000095900000 - 0000000095f00000
> > > >> >> (XEN)
> > > >> >> (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
> > > >> >> dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
> > > >> >> (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
> > > >> >> (XEN) Xen heap: 00000000d2000000-00000000de000000 (49152 pages)
> > > >> >> (XEN) Dom heap: 344064 pages
> > > >> >> (XEN) Domain heap initialised
> > > >> >> (XEN) Looking for UART console serial0
> > > >> >>  Xen 4.5-unstable
> > > >> >> (XEN) Xen version 4.5-unstable (atseglytskyi@)
> > > >> >> (arm-linux-gnueabihf-gcc (crosstool-NG
> > > >> >> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
> > > >> >> 20130328 (prerelease)) debu4
> > > >> >> (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
> > > >> >> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> > > >> >> (XEN) 32-bit Execution:
> > > >> >> (XEN)   Processor Features: 00001131:00011011
> > > >> >> (XEN)     Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> > > >> >> (XEN)     Extensions: GenericTimer Security
> > > >> >> (XEN)   Debug Features: 02010555
> > > >> >> (XEN)   Auxiliary Features: 00000000
> > > >> >> (XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
> > > >> >> (XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> > > >> >> (XEN) Platform: TI DRA7
> > > >> >> (XEN) /psci method must be smc, but is: "hvc"
> > > >> >> (XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
> > > >> >> (XEN) Set AuxCoreBoot0 to 0x20
> > > >> >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> > > >> >> (XEN) Using generic timer at 6144 KHz
> > > >> >> (XEN) GIC initialization:
> > > >> >> (XEN)         gic_dist_addr=0000000048211000
> > > >> >> (XEN)         gic_cpu_addr=0000000048212000
> > > >> >> (XEN)         gic_hyp_addr=0000000048214000
> > > >> >> (XEN)         gic_vcpu_addr=0000000048216000
> > > >> >> (XEN)         gic_maintenance_irq=25
> > > >> >> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> > > >> >> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > > >> >> (XEN) I/O virtualisation disabled
> > > >> >> (XEN) Allocated console ring of 16 KiB.
> > > >> >> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> > > >> >> (XEN) Bringing up CPU1
> > > >> >> - CPU 00000001 booting -
> > > >> >> - Xen starting in Hyp mode -
> > > >> >> - Setting up control registers -
> > > >> >> - Turning on paging -
> > > >> >> - Ready -
> > > >> >> (XEN) CPU 1 booted.
> > > >> >> (XEN) Brought up 2 CPUs
> > > >> >> (XEN) *** LOADING DOMAIN 0 ***
> > > >> >> (XEN) Loading kernel from boot module 2
> > > >> >> (XEN) Populate P2M 0xc8000000->0xd0000000 (1:1 mapping for dom0)
> > > >> >> (XEN) Loading zImage from 00000000c0000040 to 00000000cfc00000-00000000cff50c48
> > > >> >> (XEN) Loading dom0 DTB to 0x00000000cfa00000-0x00000000cfa05ba8
> > > >> >> (XEN) Std. Loglevel: All
> > > >> >> (XEN) Guest Loglevel: All
> > > >> >> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> > > >> >> input to Xen)
> > > >> >> (XEN) Freed 272kB init memory.
> > > >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> > > >> >> already pending in LR0
> > > >> >> (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
> > > >> >> already pending in LR0
> > > >> >> [    0.000000] /cpus/cpu@0 missing clock-frequency property
> > > >> >> [    0.000000] /cpus/cpu@1 missing clock-frequency property
> > > >> >> [    0.140625] omap-gpmc omap-gpmc: failed to reserve memory
> > > >> >> [    0.187500] omap_l3_noc ocp.3: couldn't find resource 2
> > > >> >> [    0.273437] i2c i2c-1: of_i2c: invalid reg on
> > > >> >> /ocp/i2c@48072000/camera_ov10635
> > > >> >> [    0.437500] ldo3: operation not allowed
> > > >> >> [    0.437500] omapdss HDMI error: can't set the voltage regulator
> > > >> >> [    0.468750] tfc_s9700 display0: tfc_s9700_probe probe
> > > >> >> [    0.468750] ov1063x 1-0030: No deserializer node found
> > > >> >> [    0.468750] ov1063x 1-0030: No serializer node found
> > > >> >> [    0.468750] ov1063x 1-0030: Failed writing register 0x0103!
> > > >> >> [    0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
> > > >> >> [    0.578125] ahci ahci.0.auto: can't get clock
> > > >> >> [    0.898437] ldc_module_init
> > > >> >> [    1.304687] Missing dual_emac_res_vlan in DT.
> > > >> >> [    1.304687] Using 1 as Reserved VLAN for 0 slave
> > > >> >> [    1.312500] Missing dual_emac_res_vlan in DT.
> > > >> >> [    1.320312] Using 2 as Reserved VLAN for 1 slave
> > > >> >> [    1.382812] Freeing init memory: 236K
> > > >> >> sh: write error: No such device
> > > >> >> Cannot identify '/dev/camera0': 2, No such file or directory
> > > >> >> Parsing config from /xen/images/DomUAndroid.cfg
> > > >> >> XSM Disabled: seclabel not supported
> > > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > > >> >> dom1 access to irq 53: Function not implemented
> > > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > > >> >> dom1 access to irq 71: Function not implemented
> > > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > > >> >> dom1 access to irq 173: Function not implemented
> > > >> >> (XEN) do_physdev_op 16 cmd=13: not implemented yet
> > > >> >> libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
> > > >> >> dom1 access to irq 174: Function not implemented
> > > >> >> Turning on vfb in domain 1
> > > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > > >> >> still lr_pending
> > > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > > >> >> still lr_pending
> > > >> >> Parsing config from /xen/images/DomUQNX.cfg
> > > >> >> XSM Disabled: seclabel not supported(XEN) gic.c:617:d0v1 trying to
> > > >> >> inject irq=2 into d0v0, when it is still lr_pending
> > > >> >>
> > > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > > >> >> still lr_pending
> > > >> >> [    4.304687] dra7-evm-sound sound.17: cpu dai node is invalid
> > > >> >> [    4.312500] dra7-evm-sound sound.17: failed to add bluetooth dai link -22
> > > >> >> xc: error: panic: xc_dom_core.c:644: xc_dom_find_loader: no loader
> > > >> >> found: Invalid kernel
> > > >> >> libxl: error: libxl_dom.c:436:libxl__build_pv: xc_dom_parse_image
> > > >> >> failed: No such file or directory
> > > >> >> libxl: error: libxl_create.c:1030:domcreate_rebuild_done: cannot
> > > >> >> (re-)build domain: -3
> > > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > > >> >> still lr_pending
> > > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > > >> >> still lr_pending
> > > >> >> Turning on 'vsnd' in domain '1' (dev_id: '0')
> > > >> >> Turning on vkbd in domain 1
> > > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > > >> >> still lr_pending
> > > >> >> (XEN) gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is
> > > >> >> still lr_pending
> > > >> >> (XEN) gic.c:617:d0v0 trying to inject irq=2 into d0v1, when it is
> > > >> >> still lr_pending
> > > >> >>
> > > >> >> Please press Enter to activate this console. (XEN) gic.c:617:d0v1
> > > >> >> trying to inject irq=2 into d0v0, when it is still lr_pending
> > > >> >>
> > > >> >> On Tue, Nov 18, 2014 at 6:18 PM, Andrii Tseglytskyi
> > > >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> > > >> >> > OK got it. Give me a few mins
> > > >> >> >
> > > >> >> > On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
> > > >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> > > >> >> >> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> > > >> >> >> for non-hardware irqs (desc == NULL) and keep avoiding
> > > >> >> >> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
> > > >> >> >>
> > > >> >> >> Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
> > > >> >> >> other potential bugs introduced later.
> > > >> >> >>
> > > >> >> >> On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > > >> >> >>> What if I try on top of current master branch the following code:
> > > >> >> >>>
> > > >> >> >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > > >> >> >>> index 31fb81a..6764ab7 100644
> > > >> >> >>> --- a/xen/arch/arm/gic-v2.c
> > > >> >> >>> +++ b/xen/arch/arm/gic-v2.c
> > > >> >> >>> @@ -36,6 +36,8 @@
> > > >> >> >>>  #include <asm/io.h>
> > > >> >> >>>  #include <asm/gic.h>
> > > >> >> >>>
> > > >> >> >>> +#define GIC_DEBUG 1
> > > >> >> >>> +
> > > >> >> >>>  /*
> > > >> >> >>>   * LR register definitions are GIC v2 specific.
> > > >> >> >>>   * Moved these definitions from header file to here
> > > >> >> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > > >> >> >>> index bcaded9..c03d6a6 100644
> > > >> >> >>> --- a/xen/arch/arm/gic.c
> > > >> >> >>> +++ b/xen/arch/arm/gic.c
> > > >> >> >>> @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> > > >> >> >>>
> > > >> >> >>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 <<
> > > >> >> >>> gic_hw_ops->info->nr_lrs) - 1))
> > > >> >> >>>
> > > >> >> >>> -#undef GIC_DEBUG
> > > >> >> >>> +#define GIC_DEBUG 1
> > > >> >> >>>
> > > >> >> >>>  static void gic_update_one_lr(struct vcpu *v, int i);
> > > >> >> >>>
> > > >> >> >>> It is equivalent to what you proposing - my code contains
> > > >> >> >>> PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
> > > >> >> >>> be executed:
> > > >> >> >>>  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function
> > > >> >> >>>
> > > >> >> >>> regards,
> > > >> >> >>> Andrii
> > > >> >> >>>
> > > >> >> >>> On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
> > > >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> > > >> >> >>> > On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> > > >> >> >>> >> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> > > >> >> >>> >> everything works fine
> > > >> >> >>> >> The following 2 patches fixes xen/master for my platform.
> > > >> >> >>> >>
> > > >> >> >>> >> Stefano, could you please take a look to these changes?
> > > >> >> >>> >>
> > > >> >> >>> >> commit 3628a0aa35706a8f532af865ed784536ce514eca
> > > >> >> >>> >> Author: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > > >> >> >>> >> Date:   Tue Nov 18 14:20:42 2014 +0200
> > > >> >> >>> >>
> > > >> >> >>> >>     xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
> > > >> >> >>> >>
> > > >> >> >>> >>     Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
> > > >> >> >>> >>     Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > > >> >> >>> >>
> > > >> >> >>> >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > > >> >> >>> >> index 31fb81a..093ecdb 100644
> > > >> >> >>> >> --- a/xen/arch/arm/gic-v2.c
> > > >> >> >>> >> +++ b/xen/arch/arm/gic-v2.c
> > > >> >> >>> >> @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
> > > >> >> >>> >> pending_irq *p,
> > > >> >> >>> >>                                               << GICH_V2_LR_PRIORITY_SHIFT) |
> > > >> >> >>> >>                ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> > > >> >> >>> >> GICH_V2_LR_VIRTUAL_SHIFT));
> > > >> >> >>> >>
> > > >> >> >>> >> -    if ( p->desc != NULL )
> > > >> >> >>> >> +    if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> > > >> >> >>> >>      {
> > > >> >> >>> >> -        if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
> > > >> >> >>> >> -            lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> > > >> >> >>> >> -        else
> > > >> >> >>> >> -            lr_reg |= GICH_V2_LR_HW | ((p->desc->irq &
> > > >> >> >>> >> GICH_V2_LR_PHYSICAL_MASK )
> > > >> >> >>> >> -                            << GICH_V2_LR_PHYSICAL_SHIFT);
> > > >> >> >>> >> +        lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
> > > >> >> >>> >> +    }
> > > >> >> >>> >> +    else if ( p->desc != NULL )
> > > >> >> >>> >> +    {
> > > >> >> >>> >> +        lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> > > >> >> >>> >> +                       << GICH_V2_LR_PHYSICAL_SHIFT);
> > > >> >> >>> >>      }
> > > >> >> >>> >>
> > > >> >> >>> >>      writel_gich(lr_reg, GICH_LR + lr * 4);
> > > >> >> >>> >
> > > >> >> >>> > Actually in case p->desc == NULL (the irq is not an hardware irq, it
> > > >> >> >>> > could be the virtual timer irq or the evtchn irq), you shouldn't need
> > > >> >> >>> > the maintenance interrupt, if the bug was really due to GICH_LR_HW not
> > > >> >> >>> > working correctly on OMAP5. This changes might only be better at
> > > >> >> >>> > "hiding" the real issue.
> > > >> >> >>> >
> > > >> >> >>> > Maybe the problem is exactly the opposite: the new scheme for avoiding
> > > >> >> >>> > maintenance interrupts doesn't work for software interrupts.
> > > >> >> >>> > The commit that should make them work correctly after the
> > > >> >> >>> > no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
> > > >> >> >>> > If you look at the changes to gic_update_one_lr in that commit, you'll
> > > >> >> >>> > see that is going to set a software irq as PENDING if it is already ACTIVE.
> > > >> >> >>> > Maybe that doesn't work correctly on OMAP5.
> > > >> >> >>> >
> > > >> >> >>> > Could you try this patch on top of
> > > >> >> >>> > 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
> > > >> >> >>> > if the problem is specifically with software irqs.
> > > >> >> >>> >
> > > >> >> >>> >
> > > >> >> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > > >> >> >>> > index b7516c0..d8a17c9 100644
> > > >> >> >>> > --- a/xen/arch/arm/gic.c
> > > >> >> >>> > +++ b/xen/arch/arm/gic.c
> > > >> >> >>> > @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> > > >> >> >>> >  /* Maximum cpu interface per GIC */
> > > >> >> >>> >  #define NR_GIC_CPU_IF 8
> > > >> >> >>> >
> > > >> >> >>> > -#undef GIC_DEBUG
> > > >> >> >>> > +#define GIC_DEBUG 1
> > > >> >> >>> >
> > > >> >> >>> >  static void gic_update_one_lr(struct vcpu *v, int i);
> > > >> >> >>> >
> > > >> >> >>> > @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
> > > >> >> >>> >          ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> > > >> >> >>> >      if ( p->desc != NULL )
> > > >> >> >>> >          lr_val |= GICH_LR_HW | (p->desc->irq << GICH_LR_PHYSICAL_SHIFT);
> > > >> >> >>> > +    else
> > > >> >> >>> > +        lr_val |= GICH_LR_MAINTENANCE_IRQ;
> > > >> >> >>> >
> > > >> >> >>> >      GICH[GICH_LR + lr] = lr_val;
> > > >> >> >>> >
> > > >> >> >>>
> > > >> >> >>>
> > > >> >> >>>
> > > >> >> >>> --
> > > >> >> >>>
> > > >> >> >>> Andrii Tseglytskyi | Embedded Dev
> > > >> >> >>> GlobalLogic
> > > >> >> >>> www.globallogic.com
> > > >> >> >>>
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> > --
> > > >> >> >
> > > >> >> > Andrii Tseglytskyi | Embedded Dev
> > > >> >> > GlobalLogic
> > > >> >> > www.globallogic.com
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >>
> > > >> >> Andrii Tseglytskyi | Embedded Dev
> > > >> >> GlobalLogic
> > > >> >> www.globallogic.com
> > > >> >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> Andrii Tseglytskyi | Embedded Dev
> > > >> GlobalLogic
> > > >> www.globallogic.com
> > > >>
> > > 
> > > 
> > > 
> > > -- 
> > > 
> > > Andrii Tseglytskyi | Embedded Dev
> > > GlobalLogic
> > > www.globallogic.com
> > > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:24:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12:24:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr4Ig-00052A-Gz; Wed, 19 Nov 2014 12:23:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr4If-000525-2P
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:23:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	38/E2-25276-CDB8C645; Wed, 19 Nov 2014 12:23:56 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416399835!13883764!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32040 invoked from network); 19 Nov 2014 12:23:55 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 12:23:55 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so1632536wid.12
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 04:23:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=iomZPxz1jMyxqyf2XROwA1xLmO86i1QWWBf4+3qYdeg=;
	b=GzVotHClJK5SsbGeBoDL2FO8gJEeBLJm5f4wDKV6nkEGmiQzoyIFBTAwfCqIcNrkV0
	Twenl6qAtOJNshODnAkAQby0sqNNcOxOc3SaOAuUsy8ZJB3T0uaeQch3iJV0b5gNOynr
	4WHOgegPs9j08Wk4FGJND2YpqVC0ua8PXzCmlrJ/4sRG0LE5DLu1+qPbBumKDf7jSMZz
	gPteQAcz+xWm20fOELnzAcTLO1/I2bqY+nYl/BoFWI/4bL3sWA0y4qaHwK5h3siCxjEb
	Wy37c1YUO7dxQRH9aydAdgfWUqSH6w30zh6Lix+Wk0m8UQtfLGispYySwDH02aCW+NuX
	wLUQ==
X-Gm-Message-State: ALoCoQlMKfqHZl6pJN0VJIZndhC/Q2DZewRGz46FChlWRst5C0afF6KfHwITjN5pjdBVwkDogWoK
X-Received: by 10.180.211.2 with SMTP id my2mr5138410wic.13.1416399835649;
	Wed, 19 Nov 2014 04:23:55 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ny6sm1988090wic.22.2014.11.19.04.23.54
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 04:23:54 -0800 (PST)
Message-ID: <546C8BD9.8090406@linaro.org>
Date: Wed, 19 Nov 2014 12:23:53 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<1416399227.29243.33.camel@citrix.com>
	<alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Ian Campbell wrote:
>> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
>>> So it looks like there is not actually anything wrong, is just that you
>>> have too much inflight irqs? It should cause problems because in that
>>> case GICH_HCR_UIE should be set and you should get a maintenance
>>> interrupt when LRs become available (actually when "none, or only one,
>>> of the List register entries is marked as a valid interrupt").
>>>
>>> Maybe GICH_HCR_UIE is the one that doesn't work properly.
>>
>> How much testing did this aspect get when the no-maint-irq series
>> originally went in? Did you manage to find a workload which filled all
>> the LRs or try artificially limiting the number of LRs somehow in order
>> to provoke it?
>>
>> I ask because my intuition is that this won't happen very much, meaning
>> those code paths may not be as well tested...
> 
> I did test it by artificially limiting the number of LRs to 1.
> However there have been many iterations of that series and I didn't run
> this test at every iteration.

am I the only to think this may not be related to this bug? All the LRs
are full with IRQ of the same priority. So it's valid.

As gic_restore_pending_irqs is called every time that we return to the
guest. It could be anything else.

It would be interesting to see why we are trapping all the time in Xen.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:24:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12:24:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr4Ig-00052A-Gz; Wed, 19 Nov 2014 12:23:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr4If-000525-2P
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:23:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	38/E2-25276-CDB8C645; Wed, 19 Nov 2014 12:23:56 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416399835!13883764!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32040 invoked from network); 19 Nov 2014 12:23:55 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 12:23:55 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so1632536wid.12
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 04:23:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=iomZPxz1jMyxqyf2XROwA1xLmO86i1QWWBf4+3qYdeg=;
	b=GzVotHClJK5SsbGeBoDL2FO8gJEeBLJm5f4wDKV6nkEGmiQzoyIFBTAwfCqIcNrkV0
	Twenl6qAtOJNshODnAkAQby0sqNNcOxOc3SaOAuUsy8ZJB3T0uaeQch3iJV0b5gNOynr
	4WHOgegPs9j08Wk4FGJND2YpqVC0ua8PXzCmlrJ/4sRG0LE5DLu1+qPbBumKDf7jSMZz
	gPteQAcz+xWm20fOELnzAcTLO1/I2bqY+nYl/BoFWI/4bL3sWA0y4qaHwK5h3siCxjEb
	Wy37c1YUO7dxQRH9aydAdgfWUqSH6w30zh6Lix+Wk0m8UQtfLGispYySwDH02aCW+NuX
	wLUQ==
X-Gm-Message-State: ALoCoQlMKfqHZl6pJN0VJIZndhC/Q2DZewRGz46FChlWRst5C0afF6KfHwITjN5pjdBVwkDogWoK
X-Received: by 10.180.211.2 with SMTP id my2mr5138410wic.13.1416399835649;
	Wed, 19 Nov 2014 04:23:55 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ny6sm1988090wic.22.2014.11.19.04.23.54
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 04:23:54 -0800 (PST)
Message-ID: <546C8BD9.8090406@linaro.org>
Date: Wed, 19 Nov 2014 12:23:53 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<1416399227.29243.33.camel@citrix.com>
	<alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Ian Campbell wrote:
>> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
>>> So it looks like there is not actually anything wrong, is just that you
>>> have too much inflight irqs? It should cause problems because in that
>>> case GICH_HCR_UIE should be set and you should get a maintenance
>>> interrupt when LRs become available (actually when "none, or only one,
>>> of the List register entries is marked as a valid interrupt").
>>>
>>> Maybe GICH_HCR_UIE is the one that doesn't work properly.
>>
>> How much testing did this aspect get when the no-maint-irq series
>> originally went in? Did you manage to find a workload which filled all
>> the LRs or try artificially limiting the number of LRs somehow in order
>> to provoke it?
>>
>> I ask because my intuition is that this won't happen very much, meaning
>> those code paths may not be as well tested...
> 
> I did test it by artificially limiting the number of LRs to 1.
> However there have been many iterations of that series and I didn't run
> this test at every iteration.

am I the only to think this may not be related to this bug? All the LRs
are full with IRQ of the same priority. So it's valid.

As gic_restore_pending_irqs is called every time that we return to the
guest. It could be anything else.

It would be interesting to see why we are trapping all the time in Xen.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:37:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12:37:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr4Va-0005H2-Ay; Wed, 19 Nov 2014 12:37:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr4VY-0005Gx-Mp
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:37:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8B/89-25276-CFE8C645; Wed, 19 Nov 2014 12:37:16 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416400633!13856548!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 657 invoked from network); 19 Nov 2014 12:37:15 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 12:37:15 -0000
Received: from mail-qa0-f51.google.com ([209.85.216.51]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGyO+U/Bb2amZ6CeEQCJKyLZ0iS1cLD9@postini.com;
	Wed, 19 Nov 2014 04:37:15 PST
Received: by mail-qa0-f51.google.com with SMTP id k15so276232qaq.38
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 04:37:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=tOHMhUhTubFiVLqxkZ3ZCG3Ge3rHWb+GsPkXmtxG2AI=;
	b=iZr904iWO4wX80HLeN6sATSINkfKmqB+X2Z0yAU/UkJo7uon1wWDiOXTlMVKVRe9qE
	eWidN0m4NMwTKegZCVuF4PADBXVp1Qa/DwIFZFNcBUdktuZKsgmSAz9QTnVBBx5P0Lrj
	tE+fj/8PqIcCgSy3cAEDdAChKv4MQe+APGmoI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=tOHMhUhTubFiVLqxkZ3ZCG3Ge3rHWb+GsPkXmtxG2AI=;
	b=eF2bHSycPPftq/CAEeCHK/C4NLSR9BP9ocn4phf5i1750KE96cSAWyDUa182PImNM5
	z1FFSsUBBFCtNMdJ35NVzoVoQ5s3jBAtsvZCzjrd77SgMGAgZoW972aJtWFvp75dgbv5
	bCH74e07qEZoMPhH6J/vd9akk4agGjgk0dOZyB9Ct0RYgxbm0AE3Du9AAEyQO2dktrWX
	Ty5HI9QTJXlVfXITphuYuu1egTY4f4R0DubiXCkEaScrm7lPBCjo+VdWIeII6sLIqdlb
	8PeyRLO97xmaZpT9nqcWgnBOAeVo21x/+eexr/2PpivMVOPPb1l5x4l8ua4FNTdsqrED
	FP9w==
X-Gm-Message-State: ALoCoQnEFEfMG7+u8KFG4MmU0XDCian4xVYN9B4lJ1wsmhD5g7xkx3WiomGjFKH+HPo4QHI5Ijxn5fLAVuyzfH6dWmAAVklfiHMsJU15J8X9HTivLNpSPNWRpVMlByA/ezaRfA+gGpW464B6ejRwfzVOTPhajYAJNg==
X-Received: by 10.224.23.71 with SMTP id q7mr49273896qab.22.1416400632803;
	Wed, 19 Nov 2014 04:37:12 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.23.71 with SMTP id q7mr49273881qab.22.1416400632674;
	Wed, 19 Nov 2014 04:37:12 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 04:37:12 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 14:37:12 +0200
Message-ID: <CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >      else
> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >
> >  }
>
> Yes, exactly

I tried, hang still occurs with this change

Regards,
Andrii




-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:37:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12:37:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr4Va-0005H2-Ay; Wed, 19 Nov 2014 12:37:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr4VY-0005Gx-Mp
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:37:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8B/89-25276-CFE8C645; Wed, 19 Nov 2014 12:37:16 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416400633!13856548!1
X-Originating-IP: [64.18.0.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 657 invoked from network); 19 Nov 2014 12:37:15 -0000
Received: from exprod5og106.obsmtp.com (HELO exprod5og106.obsmtp.com)
	(64.18.0.182)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 12:37:15 -0000
Received: from mail-qa0-f51.google.com ([209.85.216.51]) (using TLSv1) by
	exprod5ob106.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGyO+U/Bb2amZ6CeEQCJKyLZ0iS1cLD9@postini.com;
	Wed, 19 Nov 2014 04:37:15 PST
Received: by mail-qa0-f51.google.com with SMTP id k15so276232qaq.38
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 04:37:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=tOHMhUhTubFiVLqxkZ3ZCG3Ge3rHWb+GsPkXmtxG2AI=;
	b=iZr904iWO4wX80HLeN6sATSINkfKmqB+X2Z0yAU/UkJo7uon1wWDiOXTlMVKVRe9qE
	eWidN0m4NMwTKegZCVuF4PADBXVp1Qa/DwIFZFNcBUdktuZKsgmSAz9QTnVBBx5P0Lrj
	tE+fj/8PqIcCgSy3cAEDdAChKv4MQe+APGmoI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=tOHMhUhTubFiVLqxkZ3ZCG3Ge3rHWb+GsPkXmtxG2AI=;
	b=eF2bHSycPPftq/CAEeCHK/C4NLSR9BP9ocn4phf5i1750KE96cSAWyDUa182PImNM5
	z1FFSsUBBFCtNMdJ35NVzoVoQ5s3jBAtsvZCzjrd77SgMGAgZoW972aJtWFvp75dgbv5
	bCH74e07qEZoMPhH6J/vd9akk4agGjgk0dOZyB9Ct0RYgxbm0AE3Du9AAEyQO2dktrWX
	Ty5HI9QTJXlVfXITphuYuu1egTY4f4R0DubiXCkEaScrm7lPBCjo+VdWIeII6sLIqdlb
	8PeyRLO97xmaZpT9nqcWgnBOAeVo21x/+eexr/2PpivMVOPPb1l5x4l8ua4FNTdsqrED
	FP9w==
X-Gm-Message-State: ALoCoQnEFEfMG7+u8KFG4MmU0XDCian4xVYN9B4lJ1wsmhD5g7xkx3WiomGjFKH+HPo4QHI5Ijxn5fLAVuyzfH6dWmAAVklfiHMsJU15J8X9HTivLNpSPNWRpVMlByA/ezaRfA+gGpW464B6ejRwfzVOTPhajYAJNg==
X-Received: by 10.224.23.71 with SMTP id q7mr49273896qab.22.1416400632803;
	Wed, 19 Nov 2014 04:37:12 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.23.71 with SMTP id q7mr49273881qab.22.1416400632674;
	Wed, 19 Nov 2014 04:37:12 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 04:37:12 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 14:37:12 +0200
Message-ID: <CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >      else
> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >
> >  }
>
> Yes, exactly

I tried, hang still occurs with this change

Regards,
Andrii




-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:40:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12: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 1Xr4YX-0005NQ-0N; Wed, 19 Nov 2014 12:40:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr4YV-0005NK-Cr
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:40:19 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	0E/A4-27785-2BF8C645; Wed, 19 Nov 2014 12:40:18 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416400816!13480342!1
X-Originating-IP: [64.18.0.137]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8294 invoked from network); 19 Nov 2014 12:40:17 -0000
Received: from exprod5og120.obsmtp.com (HELO exprod5og120.obsmtp.com)
	(64.18.0.137)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 12:40:17 -0000
Received: from mail-qg0-f47.google.com ([209.85.192.47]) (using TLSv1) by
	exprod5ob120.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGyPr1BPVU4TuyLMoZrmqREsZbAQB4KY@postini.com;
	Wed, 19 Nov 2014 04:40:17 PST
Received: by mail-qg0-f47.google.com with SMTP id z60so304258qgd.34
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 04:40:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=+ueWco3CzfE4fzhqxyN3zO1V/Tw3Hj9P5wED+fT7CuA=;
	b=JP6ob+3yY+Lo0SFMq94dZK55K+3D67aNjgnuJ3YuKL64IAILIaoQFjFxHrETduRgst
	BeVUznZovr3zl3gyOZy3gBQ2XLGxHwhg2SN5/cz0T3+pa2sYqS3H7AZYSZigLRn5qlTR
	YhhmAmkb6UABAniDEAMmy9lgXfLbf10IXHztQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=+ueWco3CzfE4fzhqxyN3zO1V/Tw3Hj9P5wED+fT7CuA=;
	b=XAMb/MxQEKgh7QolARQSbmWBAqjXWmnxlIYBWZK2l4lwF2a9lTQldrA/GcuI3OZFfe
	ozThkKUokjaQ5K3A4bSly3IpVYp6UyRQX/H2srK6L6jcXj5BBqQEEv3AMJEpQtEQJ7db
	oxZfLA4WpSPs8Mx0rgve6QX9ut4DIDh2j3KkjHW6ShXflcQBo7omyHg2dr2xNpbQGF9u
	TFFglBeo1p/YSJS+ZaWu+/ejjH3FzGxvzXpm7FZTEGLEWVxCOrJadeJtBhapsFqfoy17
	jbDzuzxzQTmi3HgZZUU2y5J94nvwMEEsVaT9P4naDQBU3aYOrqEsRcQPwetR3U3WZezq
	QIOA==
X-Gm-Message-State: ALoCoQlMF3qumUV+KBQUugzFrypnk4ZL3zKg4VIzx0fUqmlBDIMXghTI3l2lcfgHj3f5X0D2AnvuRf0T6qFrYNN+5WaJAytVCwNPo/RxGMuG2PJXK0NAkN1a0l/y/bVgx+ec5eEQpeY6tY3QwB9uD51XjQ8kIGvMWA==
X-Received: by 10.224.28.193 with SMTP id n1mr51807842qac.93.1416400815490;
	Wed, 19 Nov 2014 04:40:15 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.28.193 with SMTP id n1mr51807829qac.93.1416400815338;
	Wed, 19 Nov 2014 04:40:15 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 04:40:15 -0800 (PST)
In-Reply-To: <546C8BD9.8090406@linaro.org>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<1416399227.29243.33.camel@citrix.com>
	<alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>
	<546C8BD9.8090406@linaro.org>
Date: Wed, 19 Nov 2014 14:40:15 +0200
Message-ID: <CAH_mUMNsE7vyHWKGTaFvPoq4kBbJi6Pn8O9-fREC+hA+cQ+tSQ@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Julien,

On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall <julien.grall@linaro.org> wrote:
> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>> On Wed, 19 Nov 2014, Ian Campbell wrote:
>>> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
>>>> So it looks like there is not actually anything wrong, is just that you
>>>> have too much inflight irqs? It should cause problems because in that
>>>> case GICH_HCR_UIE should be set and you should get a maintenance
>>>> interrupt when LRs become available (actually when "none, or only one,
>>>> of the List register entries is marked as a valid interrupt").
>>>>
>>>> Maybe GICH_HCR_UIE is the one that doesn't work properly.
>>>
>>> How much testing did this aspect get when the no-maint-irq series
>>> originally went in? Did you manage to find a workload which filled all
>>> the LRs or try artificially limiting the number of LRs somehow in order
>>> to provoke it?
>>>
>>> I ask because my intuition is that this won't happen very much, meaning
>>> those code paths may not be as well tested...
>>
>> I did test it by artificially limiting the number of LRs to 1.
>> However there have been many iterations of that series and I didn't run
>> this test at every iteration.
>
> am I the only to think this may not be related to this bug? All the LRs
> are full with IRQ of the same priority. So it's valid.
>
> As gic_restore_pending_irqs is called every time that we return to the
> guest. It could be anything else.
>
> It would be interesting to see why we are trapping all the time in Xen.
>

I may perform any test if you have some specific scenario.


> Regards,
>
> --
> Julien Grall



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 12:40:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 12: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 1Xr4YX-0005NQ-0N; Wed, 19 Nov 2014 12:40:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr4YV-0005NK-Cr
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 12:40:19 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	0E/A4-27785-2BF8C645; Wed, 19 Nov 2014 12:40:18 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416400816!13480342!1
X-Originating-IP: [64.18.0.137]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8294 invoked from network); 19 Nov 2014 12:40:17 -0000
Received: from exprod5og120.obsmtp.com (HELO exprod5og120.obsmtp.com)
	(64.18.0.137)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 12:40:17 -0000
Received: from mail-qg0-f47.google.com ([209.85.192.47]) (using TLSv1) by
	exprod5ob120.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGyPr1BPVU4TuyLMoZrmqREsZbAQB4KY@postini.com;
	Wed, 19 Nov 2014 04:40:17 PST
Received: by mail-qg0-f47.google.com with SMTP id z60so304258qgd.34
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 04:40:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=+ueWco3CzfE4fzhqxyN3zO1V/Tw3Hj9P5wED+fT7CuA=;
	b=JP6ob+3yY+Lo0SFMq94dZK55K+3D67aNjgnuJ3YuKL64IAILIaoQFjFxHrETduRgst
	BeVUznZovr3zl3gyOZy3gBQ2XLGxHwhg2SN5/cz0T3+pa2sYqS3H7AZYSZigLRn5qlTR
	YhhmAmkb6UABAniDEAMmy9lgXfLbf10IXHztQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=+ueWco3CzfE4fzhqxyN3zO1V/Tw3Hj9P5wED+fT7CuA=;
	b=XAMb/MxQEKgh7QolARQSbmWBAqjXWmnxlIYBWZK2l4lwF2a9lTQldrA/GcuI3OZFfe
	ozThkKUokjaQ5K3A4bSly3IpVYp6UyRQX/H2srK6L6jcXj5BBqQEEv3AMJEpQtEQJ7db
	oxZfLA4WpSPs8Mx0rgve6QX9ut4DIDh2j3KkjHW6ShXflcQBo7omyHg2dr2xNpbQGF9u
	TFFglBeo1p/YSJS+ZaWu+/ejjH3FzGxvzXpm7FZTEGLEWVxCOrJadeJtBhapsFqfoy17
	jbDzuzxzQTmi3HgZZUU2y5J94nvwMEEsVaT9P4naDQBU3aYOrqEsRcQPwetR3U3WZezq
	QIOA==
X-Gm-Message-State: ALoCoQlMF3qumUV+KBQUugzFrypnk4ZL3zKg4VIzx0fUqmlBDIMXghTI3l2lcfgHj3f5X0D2AnvuRf0T6qFrYNN+5WaJAytVCwNPo/RxGMuG2PJXK0NAkN1a0l/y/bVgx+ec5eEQpeY6tY3QwB9uD51XjQ8kIGvMWA==
X-Received: by 10.224.28.193 with SMTP id n1mr51807842qac.93.1416400815490;
	Wed, 19 Nov 2014 04:40:15 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.28.193 with SMTP id n1mr51807829qac.93.1416400815338;
	Wed, 19 Nov 2014 04:40:15 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 04:40:15 -0800 (PST)
In-Reply-To: <546C8BD9.8090406@linaro.org>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNmqZi2Sav0mxfxLB9vg+Qfhp2xjGsSCjH_+kGk4okKyw@mail.gmail.com>
	<CAH_mUMNMUddQGdLmb2cV3TLJYz406qggrBkJuwf70qejCyA0Ug@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<1416399227.29243.33.camel@citrix.com>
	<alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>
	<546C8BD9.8090406@linaro.org>
Date: Wed, 19 Nov 2014 14:40:15 +0200
Message-ID: <CAH_mUMNsE7vyHWKGTaFvPoq4kBbJi6Pn8O9-fREC+hA+cQ+tSQ@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Julien,

On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall <julien.grall@linaro.org> wrote:
> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>> On Wed, 19 Nov 2014, Ian Campbell wrote:
>>> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
>>>> So it looks like there is not actually anything wrong, is just that you
>>>> have too much inflight irqs? It should cause problems because in that
>>>> case GICH_HCR_UIE should be set and you should get a maintenance
>>>> interrupt when LRs become available (actually when "none, or only one,
>>>> of the List register entries is marked as a valid interrupt").
>>>>
>>>> Maybe GICH_HCR_UIE is the one that doesn't work properly.
>>>
>>> How much testing did this aspect get when the no-maint-irq series
>>> originally went in? Did you manage to find a workload which filled all
>>> the LRs or try artificially limiting the number of LRs somehow in order
>>> to provoke it?
>>>
>>> I ask because my intuition is that this won't happen very much, meaning
>>> those code paths may not be as well tested...
>>
>> I did test it by artificially limiting the number of LRs to 1.
>> However there have been many iterations of that series and I didn't run
>> this test at every iteration.
>
> am I the only to think this may not be related to this bug? All the LRs
> are full with IRQ of the same priority. So it's valid.
>
> As gic_restore_pending_irqs is called every time that we return to the
> guest. It could be anything else.
>
> It would be interesting to see why we are trapping all the time in Xen.
>

I may perform any test if you have some specific scenario.


> Regards,
>
> --
> Julien Grall



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 13:27:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 13: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 1Xr5HJ-00067y-HQ; Wed, 19 Nov 2014 13:26:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr5HI-00067t-Bg
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 13:26:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8D/C9-09842-B8A9C645; Wed, 19 Nov 2014 13:26:35 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416403595!6598750!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16473 invoked from network); 19 Nov 2014 13:26:35 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 13:26:35 -0000
Received: by mail-wg0-f46.google.com with SMTP id x12so835204wgg.19
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 05:26:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=yzak1QK4KcpRj/bNS13oVAEdtM4gTNGi70lLUVf/Nq8=;
	b=Coy94OpxVsMU7AdKC1m1a/VwmUVwxAl/bcuipkGyctwb/I5fuLAZN4R80ILtbdHAVp
	d9NBQz1+q4WvGPT27rTMbonzkAvW19WFkKVE4VoYaG8qK4m/nQuushz7cQwQ+GdpnWrl
	hXTWCROVUPQna2FFjdhSM/6cwGUuwC+hO8o7UJCuw5f7+rRYeR3DdIQuBv8rnQjHw7Rx
	vVImglLGtlo5ZmGeJemy6uRlIaC2E2iGua6w4afa/YlqEv2KDCfByHzUSsvSHay/XrL1
	vQcbvXfIYNth+Kxvz14y02gzqMyueLZPLu8u1J0cykHyzj6kLaR6b2boJstWkAFz3TP7
	UMBw==
X-Gm-Message-State: ALoCoQk1SG9n/vCuBA8d2tqj63a15Njk3anFeMPfDU7qTChUSVohoCqBLGYo+pjvoprPgHn1HQF+
X-Received: by 10.194.82.104 with SMTP id h8mr57928048wjy.44.1416403594831;
	Wed, 19 Nov 2014 05:26:34 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ga1sm2243222wib.1.2014.11.19.05.26.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 05:26:34 -0800 (PST)
Message-ID: <546C9A88.6000100@linaro.org>
Date: Wed, 19 Nov 2014 13:26:32 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>	<1416399227.29243.33.camel@citrix.com>	<alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>	<546C8BD9.8090406@linaro.org>
	<CAH_mUMNsE7vyHWKGTaFvPoq4kBbJi6Pn8O9-fREC+hA+cQ+tSQ@mail.gmail.com>
In-Reply-To: <CAH_mUMNsE7vyHWKGTaFvPoq4kBbJi6Pn8O9-fREC+hA+cQ+tSQ@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
> Hi Julien,
> 
> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall <julien.grall@linaro.org> wrote:
>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>> On Wed, 19 Nov 2014, Ian Campbell wrote:
>>>> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
>>>>> So it looks like there is not actually anything wrong, is just that you
>>>>> have too much inflight irqs? It should cause problems because in that
>>>>> case GICH_HCR_UIE should be set and you should get a maintenance
>>>>> interrupt when LRs become available (actually when "none, or only one,
>>>>> of the List register entries is marked as a valid interrupt").
>>>>>
>>>>> Maybe GICH_HCR_UIE is the one that doesn't work properly.
>>>>
>>>> How much testing did this aspect get when the no-maint-irq series
>>>> originally went in? Did you manage to find a workload which filled all
>>>> the LRs or try artificially limiting the number of LRs somehow in order
>>>> to provoke it?
>>>>
>>>> I ask because my intuition is that this won't happen very much, meaning
>>>> those code paths may not be as well tested...
>>>
>>> I did test it by artificially limiting the number of LRs to 1.
>>> However there have been many iterations of that series and I didn't run
>>> this test at every iteration.
>>
>> am I the only to think this may not be related to this bug? All the LRs
>> are full with IRQ of the same priority. So it's valid.
>>
>> As gic_restore_pending_irqs is called every time that we return to the
>> guest. It could be anything else.
>>
>> It would be interesting to see why we are trapping all the time in Xen.
>>
> 
> I may perform any test if you have some specific scenario.

I have no specific scenario in my mind :/.

It looks like I'm able to reproduce it on my ARM board by the restricted
the number of LRs to 1.

I will investigate.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 13:27:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 13: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 1Xr5HJ-00067y-HQ; Wed, 19 Nov 2014 13:26:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr5HI-00067t-Bg
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 13:26:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8D/C9-09842-B8A9C645; Wed, 19 Nov 2014 13:26:35 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416403595!6598750!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16473 invoked from network); 19 Nov 2014 13:26:35 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 13:26:35 -0000
Received: by mail-wg0-f46.google.com with SMTP id x12so835204wgg.19
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 05:26:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=yzak1QK4KcpRj/bNS13oVAEdtM4gTNGi70lLUVf/Nq8=;
	b=Coy94OpxVsMU7AdKC1m1a/VwmUVwxAl/bcuipkGyctwb/I5fuLAZN4R80ILtbdHAVp
	d9NBQz1+q4WvGPT27rTMbonzkAvW19WFkKVE4VoYaG8qK4m/nQuushz7cQwQ+GdpnWrl
	hXTWCROVUPQna2FFjdhSM/6cwGUuwC+hO8o7UJCuw5f7+rRYeR3DdIQuBv8rnQjHw7Rx
	vVImglLGtlo5ZmGeJemy6uRlIaC2E2iGua6w4afa/YlqEv2KDCfByHzUSsvSHay/XrL1
	vQcbvXfIYNth+Kxvz14y02gzqMyueLZPLu8u1J0cykHyzj6kLaR6b2boJstWkAFz3TP7
	UMBw==
X-Gm-Message-State: ALoCoQk1SG9n/vCuBA8d2tqj63a15Njk3anFeMPfDU7qTChUSVohoCqBLGYo+pjvoprPgHn1HQF+
X-Received: by 10.194.82.104 with SMTP id h8mr57928048wjy.44.1416403594831;
	Wed, 19 Nov 2014 05:26:34 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ga1sm2243222wib.1.2014.11.19.05.26.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 05:26:34 -0800 (PST)
Message-ID: <546C9A88.6000100@linaro.org>
Date: Wed, 19 Nov 2014 13:26:32 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>	<1416399227.29243.33.camel@citrix.com>	<alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>	<546C8BD9.8090406@linaro.org>
	<CAH_mUMNsE7vyHWKGTaFvPoq4kBbJi6Pn8O9-fREC+hA+cQ+tSQ@mail.gmail.com>
In-Reply-To: <CAH_mUMNsE7vyHWKGTaFvPoq4kBbJi6Pn8O9-fREC+hA+cQ+tSQ@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
> Hi Julien,
> 
> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall <julien.grall@linaro.org> wrote:
>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>> On Wed, 19 Nov 2014, Ian Campbell wrote:
>>>> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
>>>>> So it looks like there is not actually anything wrong, is just that you
>>>>> have too much inflight irqs? It should cause problems because in that
>>>>> case GICH_HCR_UIE should be set and you should get a maintenance
>>>>> interrupt when LRs become available (actually when "none, or only one,
>>>>> of the List register entries is marked as a valid interrupt").
>>>>>
>>>>> Maybe GICH_HCR_UIE is the one that doesn't work properly.
>>>>
>>>> How much testing did this aspect get when the no-maint-irq series
>>>> originally went in? Did you manage to find a workload which filled all
>>>> the LRs or try artificially limiting the number of LRs somehow in order
>>>> to provoke it?
>>>>
>>>> I ask because my intuition is that this won't happen very much, meaning
>>>> those code paths may not be as well tested...
>>>
>>> I did test it by artificially limiting the number of LRs to 1.
>>> However there have been many iterations of that series and I didn't run
>>> this test at every iteration.
>>
>> am I the only to think this may not be related to this bug? All the LRs
>> are full with IRQ of the same priority. So it's valid.
>>
>> As gic_restore_pending_irqs is called every time that we return to the
>> guest. It could be anything else.
>>
>> It would be interesting to see why we are trapping all the time in Xen.
>>
> 
> I may perform any test if you have some specific scenario.

I have no specific scenario in my mind :/.

It looks like I'm able to reproduce it on my ARM board by the restricted
the number of LRs to 1.

I will investigate.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 13:30:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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.xen.org>)
	id 1Xr5L0-0006Eo-8n; Wed, 19 Nov 2014 13:30:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr5Ky-0006Eh-Qu
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 13:30:25 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	09/9F-31453-07B9C645; Wed, 19 Nov 2014 13:30:24 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416403821!6845876!1
X-Originating-IP: [64.18.0.26]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26098 invoked from network); 19 Nov 2014 13:30:23 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 13:30:23 -0000
Received: from mail-qc0-f169.google.com ([209.85.216.169]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGybbMINsucYgs9PF9hKUCaRJzs2t1Mb@postini.com;
	Wed, 19 Nov 2014 05:30:23 PST
Received: by mail-qc0-f169.google.com with SMTP id w7so378389qcr.28
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 05:30:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=6PwX7zqrhVc2XLjl9+uQsRu6bXLDjOXhTQYe3JSCvnE=;
	b=Oy724OMWCAXdJndxSHl6uvVsxy7a0/8sERynGmOvDJlyk0WKVN8OoWYwCVRXXKICnI
	HMMhllOiA81ET9afWNDgjsoH45lXNyWnxEDWwVGFZr2HqclS7L7qRL1RWVCtZYIjND5x
	FQRz2ZsP54BHHdJkOvJTSUmYKSZ+J4kIgWeDw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=6PwX7zqrhVc2XLjl9+uQsRu6bXLDjOXhTQYe3JSCvnE=;
	b=T5a0b2lMHNpCsPs7YjkzVd7VGhQe6CQsKBUAmFCgIfi3eTkixhKEQk/O6HWc43ycca
	DKQwBtdNzxYwKHjI/VF0GsWlSQ8ARf4mW4URWd0juKQIPC2IZmx89MKshmPrFWNfOxWi
	k1r9gu1G7MdcMuDIBksHG1Qf5zRXCGml1eiN8Jn7kPpP4pMgiltHDCWqU2nZXwsLVzQd
	7TXYSytO66G7ZuL/txwvWiAo4KcWT4KWfdAolmY48fUOL5Z90VFK1GYI8tqcPT+QJuUr
	5aCS5aZhswCt6FQuhYggRveDdiRt2WvphYPJWhe06n3hYQp8keYlyEpr395STOPR7HU5
	IDug==
X-Gm-Message-State: ALoCoQln5UNfdJ0EDDVRny3qkOVH9PlVOjGl49bbqdSV+Bt0JnsgsseurCrpg/wzPlxRRgNVT5qPPapvefRFGUnolwCksb8Sk+1Llgt2NcOYYf7q7pZsQwcuO4fdJqhjXoV9xcpPzh6MzSmd4dKC343lrbQfhTbCkQ==
X-Received: by 10.140.109.102 with SMTP id k93mr51710391qgf.83.1416403818612; 
	Wed, 19 Nov 2014 05:30:18 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.109.102 with SMTP id k93mr51710378qgf.83.1416403818476; 
	Wed, 19 Nov 2014 05:30:18 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 05:30:18 -0800 (PST)
In-Reply-To: <546C9A88.6000100@linaro.org>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<1416399227.29243.33.camel@citrix.com>
	<alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>
	<546C8BD9.8090406@linaro.org>
	<CAH_mUMNsE7vyHWKGTaFvPoq4kBbJi6Pn8O9-fREC+hA+cQ+tSQ@mail.gmail.com>
	<546C9A88.6000100@linaro.org>
Date: Wed, 19 Nov 2014 15:30:18 +0200
Message-ID: <CAH_mUMOTpKiyn91N5f2hUsZ1TFTMKRLJj795FLK6LdYRNS=h+w@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 3:26 PM, Julien Grall <julien.grall@linaro.org> wrote:
> On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
>> Hi Julien,
>>
>> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>>> On Wed, 19 Nov 2014, Ian Campbell wrote:
>>>>> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
>>>>>> So it looks like there is not actually anything wrong, is just that you
>>>>>> have too much inflight irqs? It should cause problems because in that
>>>>>> case GICH_HCR_UIE should be set and you should get a maintenance
>>>>>> interrupt when LRs become available (actually when "none, or only one,
>>>>>> of the List register entries is marked as a valid interrupt").
>>>>>>
>>>>>> Maybe GICH_HCR_UIE is the one that doesn't work properly.
>>>>>
>>>>> How much testing did this aspect get when the no-maint-irq series
>>>>> originally went in? Did you manage to find a workload which filled all
>>>>> the LRs or try artificially limiting the number of LRs somehow in order
>>>>> to provoke it?
>>>>>
>>>>> I ask because my intuition is that this won't happen very much, meaning
>>>>> those code paths may not be as well tested...
>>>>
>>>> I did test it by artificially limiting the number of LRs to 1.
>>>> However there have been many iterations of that series and I didn't run
>>>> this test at every iteration.
>>>
>>> am I the only to think this may not be related to this bug? All the LRs
>>> are full with IRQ of the same priority. So it's valid.
>>>
>>> As gic_restore_pending_irqs is called every time that we return to the
>>> guest. It could be anything else.
>>>
>>> It would be interesting to see why we are trapping all the time in Xen.
>>>
>>
>> I may perform any test if you have some specific scenario.
>
> I have no specific scenario in my mind :/.
>
> It looks like I'm able to reproduce it on my ARM board by the restricted
> the number of LRs to 1.
>

Do you mean that you got a hang with current xen/master branch ?

Regards,
Andrii

> I will investigate.
>
> Regards,
>
> --
> Julien Grall



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 13:30:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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.xen.org>)
	id 1Xr5L0-0006Eo-8n; Wed, 19 Nov 2014 13:30:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr5Ky-0006Eh-Qu
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 13:30:25 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	09/9F-31453-07B9C645; Wed, 19 Nov 2014 13:30:24 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416403821!6845876!1
X-Originating-IP: [64.18.0.26]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26098 invoked from network); 19 Nov 2014 13:30:23 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 13:30:23 -0000
Received: from mail-qc0-f169.google.com ([209.85.216.169]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGybbMINsucYgs9PF9hKUCaRJzs2t1Mb@postini.com;
	Wed, 19 Nov 2014 05:30:23 PST
Received: by mail-qc0-f169.google.com with SMTP id w7so378389qcr.28
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 05:30:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=6PwX7zqrhVc2XLjl9+uQsRu6bXLDjOXhTQYe3JSCvnE=;
	b=Oy724OMWCAXdJndxSHl6uvVsxy7a0/8sERynGmOvDJlyk0WKVN8OoWYwCVRXXKICnI
	HMMhllOiA81ET9afWNDgjsoH45lXNyWnxEDWwVGFZr2HqclS7L7qRL1RWVCtZYIjND5x
	FQRz2ZsP54BHHdJkOvJTSUmYKSZ+J4kIgWeDw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=6PwX7zqrhVc2XLjl9+uQsRu6bXLDjOXhTQYe3JSCvnE=;
	b=T5a0b2lMHNpCsPs7YjkzVd7VGhQe6CQsKBUAmFCgIfi3eTkixhKEQk/O6HWc43ycca
	DKQwBtdNzxYwKHjI/VF0GsWlSQ8ARf4mW4URWd0juKQIPC2IZmx89MKshmPrFWNfOxWi
	k1r9gu1G7MdcMuDIBksHG1Qf5zRXCGml1eiN8Jn7kPpP4pMgiltHDCWqU2nZXwsLVzQd
	7TXYSytO66G7ZuL/txwvWiAo4KcWT4KWfdAolmY48fUOL5Z90VFK1GYI8tqcPT+QJuUr
	5aCS5aZhswCt6FQuhYggRveDdiRt2WvphYPJWhe06n3hYQp8keYlyEpr395STOPR7HU5
	IDug==
X-Gm-Message-State: ALoCoQln5UNfdJ0EDDVRny3qkOVH9PlVOjGl49bbqdSV+Bt0JnsgsseurCrpg/wzPlxRRgNVT5qPPapvefRFGUnolwCksb8Sk+1Llgt2NcOYYf7q7pZsQwcuO4fdJqhjXoV9xcpPzh6MzSmd4dKC343lrbQfhTbCkQ==
X-Received: by 10.140.109.102 with SMTP id k93mr51710391qgf.83.1416403818612; 
	Wed, 19 Nov 2014 05:30:18 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.109.102 with SMTP id k93mr51710378qgf.83.1416403818476; 
	Wed, 19 Nov 2014 05:30:18 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 05:30:18 -0800 (PST)
In-Reply-To: <546C9A88.6000100@linaro.org>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<1416399227.29243.33.camel@citrix.com>
	<alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>
	<546C8BD9.8090406@linaro.org>
	<CAH_mUMNsE7vyHWKGTaFvPoq4kBbJi6Pn8O9-fREC+hA+cQ+tSQ@mail.gmail.com>
	<546C9A88.6000100@linaro.org>
Date: Wed, 19 Nov 2014 15:30:18 +0200
Message-ID: <CAH_mUMOTpKiyn91N5f2hUsZ1TFTMKRLJj795FLK6LdYRNS=h+w@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 3:26 PM, Julien Grall <julien.grall@linaro.org> wrote:
> On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
>> Hi Julien,
>>
>> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>>> On Wed, 19 Nov 2014, Ian Campbell wrote:
>>>>> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
>>>>>> So it looks like there is not actually anything wrong, is just that you
>>>>>> have too much inflight irqs? It should cause problems because in that
>>>>>> case GICH_HCR_UIE should be set and you should get a maintenance
>>>>>> interrupt when LRs become available (actually when "none, or only one,
>>>>>> of the List register entries is marked as a valid interrupt").
>>>>>>
>>>>>> Maybe GICH_HCR_UIE is the one that doesn't work properly.
>>>>>
>>>>> How much testing did this aspect get when the no-maint-irq series
>>>>> originally went in? Did you manage to find a workload which filled all
>>>>> the LRs or try artificially limiting the number of LRs somehow in order
>>>>> to provoke it?
>>>>>
>>>>> I ask because my intuition is that this won't happen very much, meaning
>>>>> those code paths may not be as well tested...
>>>>
>>>> I did test it by artificially limiting the number of LRs to 1.
>>>> However there have been many iterations of that series and I didn't run
>>>> this test at every iteration.
>>>
>>> am I the only to think this may not be related to this bug? All the LRs
>>> are full with IRQ of the same priority. So it's valid.
>>>
>>> As gic_restore_pending_irqs is called every time that we return to the
>>> guest. It could be anything else.
>>>
>>> It would be interesting to see why we are trapping all the time in Xen.
>>>
>>
>> I may perform any test if you have some specific scenario.
>
> I have no specific scenario in my mind :/.
>
> It looks like I'm able to reproduce it on my ARM board by the restricted
> the number of LRs to 1.
>

Do you mean that you got a hang with current xen/master branch ?

Regards,
Andrii

> I will investigate.
>
> Regards,
>
> --
> Julien Grall



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 14:05:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 14:05:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr5sS-0006sW-RN; Wed, 19 Nov 2014 14:05:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1Xr5sQ-0006sR-4N
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 14:04:58 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	AE/44-26858-983AC645; Wed, 19 Nov 2014 14:04:57 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416405895!8735936!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21052 invoked from network); 19 Nov 2014 14:04:55 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 14:04:55 -0000
Received: by mail-wg0-f54.google.com with SMTP id y10so941967wgg.13
	for <xen-devel@lists.xensource.com>;
	Wed, 19 Nov 2014 06:04:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=9hr62sMoYwGxjbSO/nLxMvtA9GPKIvxE174QwOlyj/s=;
	b=A8hqSoakwzagDP0MkcoPqUesRKiAdtCUaSQZMXkBjK5vYlzRW9B+nd0pr3TsSaMQKk
	FJJtAvATz2xwcmH1dQvYtIVGlIWBvqTTXe6CPWGwiI8hpQkTBCViBdR2SOsRJRBnKd8B
	oHD5cUmEsLZqoM7/kij1JbpatgOIW1eDJZ2lVe6kXYjKvRY7+DW8j+qvMJHJdpcOa7YJ
	3dphdzS+pXvZ580mkp/E18UucPc9mGHwntZsFeGevvBnfaecC4KyZDrNvCQHrvKAodZl
	FI3wKJG8iWTSZB0I7hi11YPjwuL4Gxx/T0keZGORLdP0QZSDUcjVL5uZtikmj1DP4aZc
	d4tA==
X-Gm-Message-State: ALoCoQkQ/VxTvOAphUPfCCuOcZ9vb+eUpphrz62RFADzjbbHcyDyNLvFENdQF9BB2VcH9qS8s344
X-Received: by 10.180.73.175 with SMTP id m15mr6162496wiv.0.1416405894743;
	Wed, 19 Nov 2014 06:04:54 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id cj3sm2405877wjb.45.2014.11.19.06.04.52
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 06:04:54 -0800 (PST)
Message-ID: <546CA38A.7040509@m2r.biz>
Date: Wed, 19 Nov 2014 15:04:58 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <5465E68E.1000304@m2r.biz>
In-Reply-To: <5465E68E.1000304@m2r.biz>
Cc: anthony PERARD <anthony.perard@citrix.com>, dslutz@verizon.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu 2.2 crash on linux hvm domU (full backtrace
	included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
> dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid 
> leaf with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, 
> and qemu 2.2 from spice git (spice/next commit 
> e779fa0a715530311e6f59fc8adb0f6eca914a89):
> https://github.com/Fantu/Xen/commits/rebase/m2r-staging

I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the full 
backtrace of latest test:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, addr=0,
>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> 73          eax = env->regs[R_EAX];
> (gdb) bt full
> #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, 
> addr=0,
>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>         s = 0x5555564443a0
>         cs = 0x0
>         cpu = 0x0
>         __func__ = "vmport_ioport_read"
>         env = 0x8250
>         command = 0 '\000'
>         eax = 0
> #1  0x0000555555655fc4 in memory_region_read_accessor (mr=0x555556444428,
>     addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>         tmp = 0
> #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
>     value=0x7fffffffd8d0, size=4, access_size_min=4, access_size_max=4,
>     access=0x555555655f62 <memory_region_read_accessor>, 
> mr=0x555556444428)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>         access_mask = 4294967295
>         access_size = 4
>         i = 0
> #3  0x00005555556590e9 in memory_region_dispatch_read1 
> (mr=0x555556444428,
>     addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>         data = 0
> #4  0x00005555556591b1 in memory_region_dispatch_read (mr=0x555556444428,
>     addr=0, pval=0x7fffffffd9a8, size=4)
> ---Type <return> to continue, or q <return> to quit---
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> No locals.
> #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
>     pval=0x7fffffffd9a8, size=4)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> No locals.
> #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920, 
> addr=22104,
>     buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
>         l = 4
>         ptr = 0x555555a92d87 "%s/%d:\n"
>         val = 7852232130387826944
>         addr1 = 0
>         mr = 0x555556444428
>         error = false
> #7  0x000055555560a38f in address_space_read (as=0x555555eaf920, 
> addr=22104,
>     buf=0x7fffffffda50 "\377\377\377\377", len=4)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
> No locals.
> #8  0x000055555564fd4b in cpu_inl (addr=22104)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>         buf = "\377\377\377\377"
>         val = 21845
> #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> ---Type <return> to continue, or q <return> to quit---
> No locals.
> #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>         i = 1
> #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
>     req=0x7ffff7ff3020) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> No locals.
> #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>         state = 0x5555563c2510
>         req = 0x7ffff7ff3020
> #13 0x000055555596e240 in qemu_iohandler_poll (pollfds=0x555556389a30, 
> ret=1)
>     at iohandler.c:143
>         revents = 1
>         pioh = 0x5555563f7610
>         ioh = 0x555556450a40
> #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at 
> main-loop.c:495
>         ret = 1
>         timeout = 4294967295
>         timeout_ns = 3965432
> #15 0x0000555555756d3f in main_loop () at vl.c:1882
>         nonblocking = false
>         last_io = 0
> #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
>     envp=0x7fffffffe240) at vl.c:4400
> ---Type <return> to continue, or q <return> to quit---
>         i = 128
>         snapshot = 0
>         linux_boot = 0
>         initrd_filename = 0x0
>         kernel_filename = 0x0
>         kernel_cmdline = 0x555555a48f86 ""
>         boot_order = 0x555556387460 "dc"
>         ds = 0x5555564b2040
>         cyls = 0
>         heads = 0
>         secs = 0
>         translation = 0
>         hda_opts = 0x0
>         opts = 0x5555563873b0
>         machine_opts = 0x555556389010
>         icount_opts = 0x0
>         olist = 0x555555e57e80
>         optind = 62
>         optarg = 0x7fffffffe914 
> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>         loadvm = 0x0
>         machine_class = 0x55555637d5c0
>         cpu_model = 0x0
>         vga_model = 0x0
>         qtest_chrdev = 0x0
> ---Type <return> to continue, or q <return> to quit---
>         qtest_log = 0x0
>         pid_file = 0x0
>         incoming = 0x0
>         show_vnc_port = 0
>         defconfig = true
>         userconfig = true
>         log_mask = 0x0
>         log_file = 0x0
>         mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
>           realloc = 0x55555575a45a <realloc_and_trace>,
>           free = 0x55555575a4c1 <free_and_trace>, calloc = 0, 
> try_malloc = 0,
>           try_realloc = 0}
>         trace_events = 0x0
>         trace_file = 0x0
>         default_ram_size = 134217728
>         maxram_size = 2130706432
>         ram_slots = 0
>         vmstate_dump_file = 0x0
>         main_loop_err = 0x0
>         __func__ = "main"

I take a fast look in source based on calltrace and I saw this commit:
http://git.qemu.org/?p=qemu.git;a=commit;h=37f9e258b64b3cf97c7c78df60660100c9eb5a21
xen-hvm.c: Add support for Xen access to vmport
Can be the cause of regression and I must try another test reverting 
this commit or is not related?

Thanks for any reply anddo sorry for my bad english.

>
> Qemu crash on fedora 20 lxde (with software updates of some days ago) 
> boot with this backtrace:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
>> addr=0, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>> 73          eax = env->regs[R_EAX];
>> (gdb) bt full
>> #0  0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
>> addr=0, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>         s = 0x555556440a20
>>         cs = 0x0
>>         cpu = 0x0
>>         __func__ = "vmport_ioport_read"
>>         env = 0x8250
>>         command = 0 '\000'
>>         eax = 0
>> #1  0x0000555555655b9c in memory_region_read_accessor 
>> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0, 
>> mask=4294967295)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>         tmp = 0
>> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0, 
>> value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
>>     access=0x555555655b3a <memory_region_read_accessor>, 
>> mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>         access_mask = 4294967295
>>         access_size = 4
>>         i = 0
>> #3  0x0000555555658cc1 in memory_region_dispatch_read1 
>> (mr=0x555556440aa8, addr=0, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>         data = 0
>> #4  0x0000555555658d89 in memory_region_dispatch_read 
>> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>> No locals.
>> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0, 
>> pval=0x7fffffffd998, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>> No locals.
>> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840, 
>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4, 
>> is_write=false)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>>         l = 4
>>         ptr = 0x0
>>         val = 7964229952888770560
>>         addr1 = 0
>>         mr = 0x555556440aa8
>>         error = false
>> #7  0x000055555560a173 in address_space_read (as=0x555555eae840, 
>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
>> No locals.
>> #8  0x000055555564fac7 in cpu_inl (addr=22104) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>         buf = "\377\377\377\377"
>>         val = 21845
>> #9  0x000055555567084b in do_inp (addr=22104, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>> No locals.
>> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>         i = 0
>> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590, 
>> req=0x7ffff7ff3000) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>> ---Type <return> to continue, or q <return> to quit---
>> No locals.
>> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>         state = 0x5555563c1590
>>         req = 0x7ffff7ff3000
>> #13 0x000055555596d874 in qemu_iohandler_poll 
>> (pollfds=0x555556388a30, ret=1) at iohandler.c:143
>>         revents = 1
>>         pioh = 0x5555563f3c90
>>         ioh = 0x555556515f80
>> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at 
>> main-loop.c:495
>>         ret = 1
>>         timeout = 4294967295
>>         timeout_ns = 3418165
>> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>>         nonblocking = false
>>         last_io = 1
>> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038, 
>> envp=0x7fffffffe230) at vl.c:4400
>>         i = 128
>>         snapshot = 0
>>         linux_boot = 0
>>         initrd_filename = 0x0
>>         kernel_filename = 0x0
>>         kernel_cmdline = 0x555555a485c6 ""
>>         boot_order = 0x5555563864e0 "dc"
>>         ds = 0x5555564c71b0
>>         cyls = 0
>>         heads = 0
>>         secs = 0
>>         translation = 0
>>         hda_opts = 0x0
>>         opts = 0x555556386430
>>         machine_opts = 0x555556388090
>>         icount_opts = 0x0
>>         olist = 0x555555e56da0
>>         optind = 62
>>         optarg = 0x7fffffffe914 
>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>         loadvm = 0x0
>>         machine_class = 0x55555637c5c0
>>         cpu_model = 0x0
>>         vga_model = 0x0
>>         qtest_chrdev = 0x0
>> ---Type <return> to continue, or q <return> to quit---
>>         qtest_log = 0x0
>>         pid_file = 0x0
>>         incoming = 0x0
>>         show_vnc_port = 0
>>         defconfig = true
>>         userconfig = true
>>         log_mask = 0x0
>>         log_file = 0x0
>>         mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>, 
>> realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39 
>> <free_and_trace>, calloc = 0,
>>           try_malloc = 0, try_realloc = 0}
>>         trace_events = 0x0
>>         trace_file = 0x0
>>         default_ram_size = 134217728
>>         maxram_size = 2013265920
>>         ram_slots = 0
>>         vmstate_dump_file = 0x0
>>         main_loop_err = 0x0
>>         __func__ = "main"
>
>
>> xl -vvv create /etc/xen/FEDORA19.cfg
>> Parsing config from /etc/xen/FEDORA19.cfg
>> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660: 
>> create: how=(nil) callback=(nil) poller=0xac2af0
>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk 
>> vdev=hda spec.backend=unknown
>> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda, 
>> backend phy unsuitable as phys path not a block device
>> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk 
>> vdev=hda, using backend qdisk
>> libxl: debug: libxl_create.c:935:initiate_domain_create: running 
>> bootloader
>> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV 
>> domain, skipping bootloader
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac32f8: deregister unregistered
>> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
>> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
>> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
>> xc: detail:   Loader:   0000000000100000->000000000036b324
>> xc: detail:   Modules:  0000000000000000->0000000000000000
>> xc: detail:   TOTAL:    0000000000000000->0000000078000000
>> xc: detail:   ENTRY:    0000000000100000
>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>> xc: detail:   4KB PAGES: 0x0000000000000200
>> xc: detail:   2MB PAGES: 0x00000000000003bf
>> xc: detail:   1GB PAGES: 0x0000000000000000
>> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 -> 0x7f1f975012b0
>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk 
>> vdev=hda spec.backend=qdisk
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac4ad0: deregister unregistered
>> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning 
>> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> /usr/lib/xen/bin/qemu-gdb
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> chardev=libxl-cmd,mode=control
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   FEDORA
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -spice
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> spicevmc,id=vdagent,name=vdagent
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> virtserialport,chardev=vdagent,name=com.redhat.spice.0
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> qxl-vga,vram_size_mb=64,ram_size_mb=64
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   order=dc
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> spicevmc,name=usbredir,id=usbrc1
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> usb-redir,chardev=usbrc1,id=usbrc1
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> spicevmc,name=usbredir,id=usbrc2
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> usb-redir,chardev=usbrc2,id=usbrc2
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> spicevmc,name=usbredir,id=usbrc3
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> usb-redir,chardev=usbrc3,id=usbrc3
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> spicevmc,name=usbredir,id=usbrc4
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> usb-redir,chardev=usbrc4,id=usbrc4
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -soundhw
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -netdev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -machine
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -drive
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>> register slotnum=3
>> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660: 
>> inprogress: poller=0xac2af0, flags=i
>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>> epath=/local/domain/0/device-model/9/state
>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>> epath=/local/domain/0/device-model/9/state
>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>> deregister slotnum=3
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac3558: deregister unregistered
>> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to 
>> /var/run/xen/qmp-libxl-9
>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>     "execute": "qmp_capabilities",
>>     "id": 1
>> }
>> '
>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>     "execute": "query-chardev",
>>     "id": 2
>> }
>> '
>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>     "execute": "query-vnc",
>>     "id": 3
>> }
>> '
>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>> register slotnum=3
>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>> epath=/local/domain/0/backend/vif/9/0/state
>> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend 
>> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting 
>> state 1
>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>> epath=/local/domain/0/backend/vif/9/0/state
>> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend 
>> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>> deregister slotnum=3
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac8368: deregister unregistered
>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>> script: /etc/xen/scripts/vif-bridge online
>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to 
>> execute: /etc/xen/scripts/vif-bridge online
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac83f0: deregister unregistered
>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>> script: /etc/xen/scripts/vif-bridge add
>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to 
>> execute: /etc/xen/scripts/vif-bridge add
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac83f0: deregister unregistered
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac83f0: deregister unregistered
>> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao 
>> 0xac2660: progress report: ignored
>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660: 
>> complete, rc=0
>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660: 
>> destroy
>> xc: debug: hypercall buffer: total allocations:704 total releases:704
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
>> xc: debug: hypercall buffer: cache current size:4
>> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
>> xc: debug: hypercall buffer: total allocations:0 total releases:0
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:0
>> xc: debug: hypercall buffer: cache current size:0
>> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
>
> xl dmesg
>> (d9) HVM Loader
>> (d9) Detected Xen v4.5.0-rc
>> (d9) Xenbus rings @0xfeffc000, event channel 1
>> (d9) System requested SeaBIOS
>> (d9) CPU speed is 2660 MHz
>> (d9) Relocating guest memory for lowmem MMIO space disabled
>> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
>> (d9) PCI-ISA link 0 routed to IRQ5
>> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
>> (d9) PCI-ISA link 1 routed to IRQ10
>> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
>> (d9) PCI-ISA link 2 routed to IRQ11
>> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
>> (d9) PCI-ISA link 3 routed to IRQ5
>> (d9) pci dev 01:3 INTA->IRQ10
>> (d9) pci dev 02:0 INTA->IRQ11
>> (d9) pci dev 03:0 INTA->IRQ5
>> (d9) pci dev 04:0 INTA->IRQ5
>> (d9) pci dev 05:0 INTA->IRQ10
>> (d9) pci dev 06:0 INTA->IRQ11
>> (d9) pci dev 1d:0 INTA->IRQ10
>> (d9) pci dev 1d:1 INTB->IRQ11
>> (d9) pci dev 1d:2 INTC->IRQ5
>> (d9) pci dev 1d:7 INTD->IRQ5
>> (d9) No RAM in high memory; setting high_mem resource base to 100000000
>> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
>> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
>> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
>> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
>> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
>> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
>> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
>> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
>> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
>> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
>> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
>> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
>> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
>> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
>> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
>> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
>> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>> (d9) Multiprocessor initialisation:
>> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>> done.
>> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>> done.
>> (d9) Testing HVM environment:
>> (d9)  - REP INSB across page boundaries ... passed
>> (d9)  - GS base MSRs and SWAPGS ... passed
>> (d9) Passed 2 of 2 tests
>> (d9) Writing SMBIOS tables ...
>> (d9) Loading SeaBIOS ...
>> (d9) Creating MP tables ...
>> (d9) Loading ACPI ...
>> (d9) S3 disabled
>> (d9) S4 disabled
>> (d9) vm86 TSS at fc00a100
>> (d9) BIOS map:
>> (d9)  10000-100d3: Scratch space
>> (d9)  c0000-fffff: Main BIOS
>> (d9) E820 table:
>> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
>> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
>> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>> (d9) Invoking SeaBIOS ...
>> (d9) SeaBIOS (version 
>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>> (d9)
>> (d9) Found Xen hypervisor signature at 40000000
>> (d9) Running on QEMU (i440fx)
>> (d9) xen: copy e820...
>> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>> (d9) CPU Mhz=2660
>> (d9) Found 13 PCI devices (max PCI bus is 00)
>> (d9) Allocated Xen hypercall page at 77fff000
>> (d9) Detected Xen v4.5.0-rc
>> (d9) xen: copy BIOS tables...
>> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
>> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>> (d9) Using pmtimer, ioport 0xb008
>> (d9) Scan for VGA option rom
>> (d9) Running option rom at c000:0003
>> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
>> (d9) pmm call arg1=0
>> (d9) Turning on vga text mode console
>> (d9) SeaBIOS (version 
>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
>> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
>> (d9) Found 0 lpt ports
>> (d9) Found 0 serial ports
>> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
>> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>> (d9) UHCI init on dev 00:1d.0 (io=c240)
>> (d9) UHCI init on dev 00:1d.1 (io=c260)
>> (d9) UHCI init on dev 00:1d.2 (io=c280)
>> (d9) PS2 keyboard initialized
>> (d9) All threads complete.
>> (d9) Scan for option roms
>> (d9) Running option rom at c980:0003
>> (d9) pmm call arg1=1
>> (d9) pmm call arg1=0
>> (d9) pmm call arg1=1
>> (d9) pmm call arg1=0
>> (d9) Searching bootorder for: /pci@i0cf8/*@6
>> (d9)
>> (d9) Press F12 for boot menu.
>> (d9)
>> (d9) Searching bootorder for: HALT
>> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba 
>> LCHS=1024/255/63 s=20480000
>> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
>> (d9) Returned 258048 bytes of ZoneHigh
>> (d9) e820 map has 6 items:
>> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
>> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
>> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
>> (d9) enter handle_19:
>> (d9)   NULL
>> (d9) Booting from Hard Disk...
>> (d9) Booting from 0000:7c00
>> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
>> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
>> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
>> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
>> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
>
> domU's xl cfg:
>> name='FEDORA'
>> builder="hvm"
>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>> memory=2048
>> vcpus=2
>> acpi_s3=0
>> acpi_s4=0
>> vif=['bridge=xenbr0']
>> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
>> boot='dc'
>> device_model_version='qemu-xen'
>> vnc=0
>> keymap="it"
>> vga="qxl"
>> spice=1
>> spicehost='0.0.0.0'
>> spiceport=6005
>> spicedisable_ticketing=1
>> spicevdagent=1
>> spice_clipboard_sharing=0
>> spiceusbredirection=4
>> soundhw="hda"
>
> I tested also with stdvga instead of qxl vga but qemu crash always on 
> fedora boot with same error.
>
> If you need more informations/tests tell me and I'll post them.
>
> Thanks for any reply and sorry for my bad english.
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 14:05:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 14:05:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr5sS-0006sW-RN; Wed, 19 Nov 2014 14:05:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1Xr5sQ-0006sR-4N
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 14:04:58 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	AE/44-26858-983AC645; Wed, 19 Nov 2014 14:04:57 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416405895!8735936!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21052 invoked from network); 19 Nov 2014 14:04:55 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 14:04:55 -0000
Received: by mail-wg0-f54.google.com with SMTP id y10so941967wgg.13
	for <xen-devel@lists.xensource.com>;
	Wed, 19 Nov 2014 06:04:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=9hr62sMoYwGxjbSO/nLxMvtA9GPKIvxE174QwOlyj/s=;
	b=A8hqSoakwzagDP0MkcoPqUesRKiAdtCUaSQZMXkBjK5vYlzRW9B+nd0pr3TsSaMQKk
	FJJtAvATz2xwcmH1dQvYtIVGlIWBvqTTXe6CPWGwiI8hpQkTBCViBdR2SOsRJRBnKd8B
	oHD5cUmEsLZqoM7/kij1JbpatgOIW1eDJZ2lVe6kXYjKvRY7+DW8j+qvMJHJdpcOa7YJ
	3dphdzS+pXvZ580mkp/E18UucPc9mGHwntZsFeGevvBnfaecC4KyZDrNvCQHrvKAodZl
	FI3wKJG8iWTSZB0I7hi11YPjwuL4Gxx/T0keZGORLdP0QZSDUcjVL5uZtikmj1DP4aZc
	d4tA==
X-Gm-Message-State: ALoCoQkQ/VxTvOAphUPfCCuOcZ9vb+eUpphrz62RFADzjbbHcyDyNLvFENdQF9BB2VcH9qS8s344
X-Received: by 10.180.73.175 with SMTP id m15mr6162496wiv.0.1416405894743;
	Wed, 19 Nov 2014 06:04:54 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id cj3sm2405877wjb.45.2014.11.19.06.04.52
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 06:04:54 -0800 (PST)
Message-ID: <546CA38A.7040509@m2r.biz>
Date: Wed, 19 Nov 2014 15:04:58 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <5465E68E.1000304@m2r.biz>
In-Reply-To: <5465E68E.1000304@m2r.biz>
Cc: anthony PERARD <anthony.perard@citrix.com>, dslutz@verizon.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu 2.2 crash on linux hvm domU (full backtrace
	included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
> dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid 
> leaf with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, 
> and qemu 2.2 from spice git (spice/next commit 
> e779fa0a715530311e6f59fc8adb0f6eca914a89):
> https://github.com/Fantu/Xen/commits/rebase/m2r-staging

I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the full 
backtrace of latest test:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, addr=0,
>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> 73          eax = env->regs[R_EAX];
> (gdb) bt full
> #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, 
> addr=0,
>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>         s = 0x5555564443a0
>         cs = 0x0
>         cpu = 0x0
>         __func__ = "vmport_ioport_read"
>         env = 0x8250
>         command = 0 '\000'
>         eax = 0
> #1  0x0000555555655fc4 in memory_region_read_accessor (mr=0x555556444428,
>     addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>         tmp = 0
> #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
>     value=0x7fffffffd8d0, size=4, access_size_min=4, access_size_max=4,
>     access=0x555555655f62 <memory_region_read_accessor>, 
> mr=0x555556444428)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>         access_mask = 4294967295
>         access_size = 4
>         i = 0
> #3  0x00005555556590e9 in memory_region_dispatch_read1 
> (mr=0x555556444428,
>     addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>         data = 0
> #4  0x00005555556591b1 in memory_region_dispatch_read (mr=0x555556444428,
>     addr=0, pval=0x7fffffffd9a8, size=4)
> ---Type <return> to continue, or q <return> to quit---
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> No locals.
> #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
>     pval=0x7fffffffd9a8, size=4)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> No locals.
> #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920, 
> addr=22104,
>     buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
>         l = 4
>         ptr = 0x555555a92d87 "%s/%d:\n"
>         val = 7852232130387826944
>         addr1 = 0
>         mr = 0x555556444428
>         error = false
> #7  0x000055555560a38f in address_space_read (as=0x555555eaf920, 
> addr=22104,
>     buf=0x7fffffffda50 "\377\377\377\377", len=4)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
> No locals.
> #8  0x000055555564fd4b in cpu_inl (addr=22104)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>         buf = "\377\377\377\377"
>         val = 21845
> #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> ---Type <return> to continue, or q <return> to quit---
> No locals.
> #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>         i = 1
> #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
>     req=0x7ffff7ff3020) at 
> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> No locals.
> #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>         state = 0x5555563c2510
>         req = 0x7ffff7ff3020
> #13 0x000055555596e240 in qemu_iohandler_poll (pollfds=0x555556389a30, 
> ret=1)
>     at iohandler.c:143
>         revents = 1
>         pioh = 0x5555563f7610
>         ioh = 0x555556450a40
> #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at 
> main-loop.c:495
>         ret = 1
>         timeout = 4294967295
>         timeout_ns = 3965432
> #15 0x0000555555756d3f in main_loop () at vl.c:1882
>         nonblocking = false
>         last_io = 0
> #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
>     envp=0x7fffffffe240) at vl.c:4400
> ---Type <return> to continue, or q <return> to quit---
>         i = 128
>         snapshot = 0
>         linux_boot = 0
>         initrd_filename = 0x0
>         kernel_filename = 0x0
>         kernel_cmdline = 0x555555a48f86 ""
>         boot_order = 0x555556387460 "dc"
>         ds = 0x5555564b2040
>         cyls = 0
>         heads = 0
>         secs = 0
>         translation = 0
>         hda_opts = 0x0
>         opts = 0x5555563873b0
>         machine_opts = 0x555556389010
>         icount_opts = 0x0
>         olist = 0x555555e57e80
>         optind = 62
>         optarg = 0x7fffffffe914 
> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>         loadvm = 0x0
>         machine_class = 0x55555637d5c0
>         cpu_model = 0x0
>         vga_model = 0x0
>         qtest_chrdev = 0x0
> ---Type <return> to continue, or q <return> to quit---
>         qtest_log = 0x0
>         pid_file = 0x0
>         incoming = 0x0
>         show_vnc_port = 0
>         defconfig = true
>         userconfig = true
>         log_mask = 0x0
>         log_file = 0x0
>         mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
>           realloc = 0x55555575a45a <realloc_and_trace>,
>           free = 0x55555575a4c1 <free_and_trace>, calloc = 0, 
> try_malloc = 0,
>           try_realloc = 0}
>         trace_events = 0x0
>         trace_file = 0x0
>         default_ram_size = 134217728
>         maxram_size = 2130706432
>         ram_slots = 0
>         vmstate_dump_file = 0x0
>         main_loop_err = 0x0
>         __func__ = "main"

I take a fast look in source based on calltrace and I saw this commit:
http://git.qemu.org/?p=qemu.git;a=commit;h=37f9e258b64b3cf97c7c78df60660100c9eb5a21
xen-hvm.c: Add support for Xen access to vmport
Can be the cause of regression and I must try another test reverting 
this commit or is not related?

Thanks for any reply anddo sorry for my bad english.

>
> Qemu crash on fedora 20 lxde (with software updates of some days ago) 
> boot with this backtrace:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
>> addr=0, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>> 73          eax = env->regs[R_EAX];
>> (gdb) bt full
>> #0  0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
>> addr=0, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>         s = 0x555556440a20
>>         cs = 0x0
>>         cpu = 0x0
>>         __func__ = "vmport_ioport_read"
>>         env = 0x8250
>>         command = 0 '\000'
>>         eax = 0
>> #1  0x0000555555655b9c in memory_region_read_accessor 
>> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0, 
>> mask=4294967295)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>         tmp = 0
>> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0, 
>> value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
>>     access=0x555555655b3a <memory_region_read_accessor>, 
>> mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>         access_mask = 4294967295
>>         access_size = 4
>>         i = 0
>> #3  0x0000555555658cc1 in memory_region_dispatch_read1 
>> (mr=0x555556440aa8, addr=0, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>         data = 0
>> #4  0x0000555555658d89 in memory_region_dispatch_read 
>> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>> No locals.
>> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0, 
>> pval=0x7fffffffd998, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>> No locals.
>> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840, 
>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4, 
>> is_write=false)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>>         l = 4
>>         ptr = 0x0
>>         val = 7964229952888770560
>>         addr1 = 0
>>         mr = 0x555556440aa8
>>         error = false
>> #7  0x000055555560a173 in address_space_read (as=0x555555eae840, 
>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
>> No locals.
>> #8  0x000055555564fac7 in cpu_inl (addr=22104) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>         buf = "\377\377\377\377"
>>         val = 21845
>> #9  0x000055555567084b in do_inp (addr=22104, size=4) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>> No locals.
>> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>         i = 0
>> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590, 
>> req=0x7ffff7ff3000) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>> ---Type <return> to continue, or q <return> to quit---
>> No locals.
>> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>         state = 0x5555563c1590
>>         req = 0x7ffff7ff3000
>> #13 0x000055555596d874 in qemu_iohandler_poll 
>> (pollfds=0x555556388a30, ret=1) at iohandler.c:143
>>         revents = 1
>>         pioh = 0x5555563f3c90
>>         ioh = 0x555556515f80
>> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at 
>> main-loop.c:495
>>         ret = 1
>>         timeout = 4294967295
>>         timeout_ns = 3418165
>> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>>         nonblocking = false
>>         last_io = 1
>> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038, 
>> envp=0x7fffffffe230) at vl.c:4400
>>         i = 128
>>         snapshot = 0
>>         linux_boot = 0
>>         initrd_filename = 0x0
>>         kernel_filename = 0x0
>>         kernel_cmdline = 0x555555a485c6 ""
>>         boot_order = 0x5555563864e0 "dc"
>>         ds = 0x5555564c71b0
>>         cyls = 0
>>         heads = 0
>>         secs = 0
>>         translation = 0
>>         hda_opts = 0x0
>>         opts = 0x555556386430
>>         machine_opts = 0x555556388090
>>         icount_opts = 0x0
>>         olist = 0x555555e56da0
>>         optind = 62
>>         optarg = 0x7fffffffe914 
>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>         loadvm = 0x0
>>         machine_class = 0x55555637c5c0
>>         cpu_model = 0x0
>>         vga_model = 0x0
>>         qtest_chrdev = 0x0
>> ---Type <return> to continue, or q <return> to quit---
>>         qtest_log = 0x0
>>         pid_file = 0x0
>>         incoming = 0x0
>>         show_vnc_port = 0
>>         defconfig = true
>>         userconfig = true
>>         log_mask = 0x0
>>         log_file = 0x0
>>         mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>, 
>> realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39 
>> <free_and_trace>, calloc = 0,
>>           try_malloc = 0, try_realloc = 0}
>>         trace_events = 0x0
>>         trace_file = 0x0
>>         default_ram_size = 134217728
>>         maxram_size = 2013265920
>>         ram_slots = 0
>>         vmstate_dump_file = 0x0
>>         main_loop_err = 0x0
>>         __func__ = "main"
>
>
>> xl -vvv create /etc/xen/FEDORA19.cfg
>> Parsing config from /etc/xen/FEDORA19.cfg
>> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660: 
>> create: how=(nil) callback=(nil) poller=0xac2af0
>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk 
>> vdev=hda spec.backend=unknown
>> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda, 
>> backend phy unsuitable as phys path not a block device
>> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk 
>> vdev=hda, using backend qdisk
>> libxl: debug: libxl_create.c:935:initiate_domain_create: running 
>> bootloader
>> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV 
>> domain, skipping bootloader
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac32f8: deregister unregistered
>> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
>> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
>> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
>> xc: detail:   Loader:   0000000000100000->000000000036b324
>> xc: detail:   Modules:  0000000000000000->0000000000000000
>> xc: detail:   TOTAL:    0000000000000000->0000000078000000
>> xc: detail:   ENTRY:    0000000000100000
>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>> xc: detail:   4KB PAGES: 0x0000000000000200
>> xc: detail:   2MB PAGES: 0x00000000000003bf
>> xc: detail:   1GB PAGES: 0x0000000000000000
>> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 -> 0x7f1f975012b0
>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk 
>> vdev=hda spec.backend=qdisk
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac4ad0: deregister unregistered
>> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning 
>> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> /usr/lib/xen/bin/qemu-gdb
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> chardev=libxl-cmd,mode=control
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   FEDORA
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -spice
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> spicevmc,id=vdagent,name=vdagent
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> virtserialport,chardev=vdagent,name=com.redhat.spice.0
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> qxl-vga,vram_size_mb=64,ram_size_mb=64
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   order=dc
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> spicevmc,name=usbredir,id=usbrc1
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> usb-redir,chardev=usbrc1,id=usbrc1
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> spicevmc,name=usbredir,id=usbrc2
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> usb-redir,chardev=usbrc2,id=usbrc2
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> spicevmc,name=usbredir,id=usbrc3
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> usb-redir,chardev=usbrc3,id=usbrc3
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -chardev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> spicevmc,name=usbredir,id=usbrc4
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> usb-redir,chardev=usbrc4,id=usbrc4
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -soundhw
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -netdev
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -machine
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -drive
>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>> register slotnum=3
>> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660: 
>> inprogress: poller=0xac2af0, flags=i
>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>> epath=/local/domain/0/device-model/9/state
>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>> epath=/local/domain/0/device-model/9/state
>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>> deregister slotnum=3
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac3558: deregister unregistered
>> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to 
>> /var/run/xen/qmp-libxl-9
>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>     "execute": "qmp_capabilities",
>>     "id": 1
>> }
>> '
>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>     "execute": "query-chardev",
>>     "id": 2
>> }
>> '
>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>     "execute": "query-vnc",
>>     "id": 3
>> }
>> '
>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>> register slotnum=3
>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>> epath=/local/domain/0/backend/vif/9/0/state
>> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend 
>> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting 
>> state 1
>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>> epath=/local/domain/0/backend/vif/9/0/state
>> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend 
>> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>> deregister slotnum=3
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac8368: deregister unregistered
>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>> script: /etc/xen/scripts/vif-bridge online
>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to 
>> execute: /etc/xen/scripts/vif-bridge online
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac83f0: deregister unregistered
>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>> script: /etc/xen/scripts/vif-bridge add
>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to 
>> execute: /etc/xen/scripts/vif-bridge add
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac83f0: deregister unregistered
>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>> w=0xac83f0: deregister unregistered
>> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao 
>> 0xac2660: progress report: ignored
>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660: 
>> complete, rc=0
>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660: 
>> destroy
>> xc: debug: hypercall buffer: total allocations:704 total releases:704
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
>> xc: debug: hypercall buffer: cache current size:4
>> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
>> xc: debug: hypercall buffer: total allocations:0 total releases:0
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:0
>> xc: debug: hypercall buffer: cache current size:0
>> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
>
> xl dmesg
>> (d9) HVM Loader
>> (d9) Detected Xen v4.5.0-rc
>> (d9) Xenbus rings @0xfeffc000, event channel 1
>> (d9) System requested SeaBIOS
>> (d9) CPU speed is 2660 MHz
>> (d9) Relocating guest memory for lowmem MMIO space disabled
>> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
>> (d9) PCI-ISA link 0 routed to IRQ5
>> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
>> (d9) PCI-ISA link 1 routed to IRQ10
>> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
>> (d9) PCI-ISA link 2 routed to IRQ11
>> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
>> (d9) PCI-ISA link 3 routed to IRQ5
>> (d9) pci dev 01:3 INTA->IRQ10
>> (d9) pci dev 02:0 INTA->IRQ11
>> (d9) pci dev 03:0 INTA->IRQ5
>> (d9) pci dev 04:0 INTA->IRQ5
>> (d9) pci dev 05:0 INTA->IRQ10
>> (d9) pci dev 06:0 INTA->IRQ11
>> (d9) pci dev 1d:0 INTA->IRQ10
>> (d9) pci dev 1d:1 INTB->IRQ11
>> (d9) pci dev 1d:2 INTC->IRQ5
>> (d9) pci dev 1d:7 INTD->IRQ5
>> (d9) No RAM in high memory; setting high_mem resource base to 100000000
>> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
>> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
>> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
>> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
>> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
>> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
>> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
>> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
>> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
>> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
>> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
>> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
>> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
>> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
>> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
>> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
>> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>> (d9) Multiprocessor initialisation:
>> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>> done.
>> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>> done.
>> (d9) Testing HVM environment:
>> (d9)  - REP INSB across page boundaries ... passed
>> (d9)  - GS base MSRs and SWAPGS ... passed
>> (d9) Passed 2 of 2 tests
>> (d9) Writing SMBIOS tables ...
>> (d9) Loading SeaBIOS ...
>> (d9) Creating MP tables ...
>> (d9) Loading ACPI ...
>> (d9) S3 disabled
>> (d9) S4 disabled
>> (d9) vm86 TSS at fc00a100
>> (d9) BIOS map:
>> (d9)  10000-100d3: Scratch space
>> (d9)  c0000-fffff: Main BIOS
>> (d9) E820 table:
>> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
>> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
>> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>> (d9) Invoking SeaBIOS ...
>> (d9) SeaBIOS (version 
>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>> (d9)
>> (d9) Found Xen hypervisor signature at 40000000
>> (d9) Running on QEMU (i440fx)
>> (d9) xen: copy e820...
>> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>> (d9) CPU Mhz=2660
>> (d9) Found 13 PCI devices (max PCI bus is 00)
>> (d9) Allocated Xen hypercall page at 77fff000
>> (d9) Detected Xen v4.5.0-rc
>> (d9) xen: copy BIOS tables...
>> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
>> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>> (d9) Using pmtimer, ioport 0xb008
>> (d9) Scan for VGA option rom
>> (d9) Running option rom at c000:0003
>> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
>> (d9) pmm call arg1=0
>> (d9) Turning on vga text mode console
>> (d9) SeaBIOS (version 
>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
>> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
>> (d9) Found 0 lpt ports
>> (d9) Found 0 serial ports
>> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
>> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>> (d9) UHCI init on dev 00:1d.0 (io=c240)
>> (d9) UHCI init on dev 00:1d.1 (io=c260)
>> (d9) UHCI init on dev 00:1d.2 (io=c280)
>> (d9) PS2 keyboard initialized
>> (d9) All threads complete.
>> (d9) Scan for option roms
>> (d9) Running option rom at c980:0003
>> (d9) pmm call arg1=1
>> (d9) pmm call arg1=0
>> (d9) pmm call arg1=1
>> (d9) pmm call arg1=0
>> (d9) Searching bootorder for: /pci@i0cf8/*@6
>> (d9)
>> (d9) Press F12 for boot menu.
>> (d9)
>> (d9) Searching bootorder for: HALT
>> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba 
>> LCHS=1024/255/63 s=20480000
>> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
>> (d9) Returned 258048 bytes of ZoneHigh
>> (d9) e820 map has 6 items:
>> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
>> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
>> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
>> (d9) enter handle_19:
>> (d9)   NULL
>> (d9) Booting from Hard Disk...
>> (d9) Booting from 0000:7c00
>> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
>> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
>> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
>> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
>> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
>
> domU's xl cfg:
>> name='FEDORA'
>> builder="hvm"
>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>> memory=2048
>> vcpus=2
>> acpi_s3=0
>> acpi_s4=0
>> vif=['bridge=xenbr0']
>> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
>> boot='dc'
>> device_model_version='qemu-xen'
>> vnc=0
>> keymap="it"
>> vga="qxl"
>> spice=1
>> spicehost='0.0.0.0'
>> spiceport=6005
>> spicedisable_ticketing=1
>> spicevdagent=1
>> spice_clipboard_sharing=0
>> spiceusbredirection=4
>> soundhw="hda"
>
> I tested also with stdvga instead of qxl vga but qemu crash always on 
> fedora boot with same error.
>
> If you need more informations/tests tell me and I'll post them.
>
> Thanks for any reply and sorry for my bad english.
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 14:06:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 14:06:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr5tV-0006x6-Hi; Wed, 19 Nov 2014 14:06:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr5tR-0006wr-Mt
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 14:06:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1D/EA-09936-8C3AC645; Wed, 19 Nov 2014 14:06:00 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416405960!13937696!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23370 invoked from network); 19 Nov 2014 14:06:00 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 14:06:00 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so945389wgh.20
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 06:06:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=A0KE6jZhHdQPoQl3Fh0Z1xCVJqzpEADl3IjTUJSyzSU=;
	b=iriH0MXBsb0vRwpXkHMXZFX1HvJu3CbwZYj1SbOTRBqpvRPz+3jP+BcwpdgIe16OXh
	SPxyn5XHH0O/af6quA/NgxIGdvhP9bpy4UNGYBM+pt5OvTHPEzS6qtU3+czKibfCUlNS
	/x34E/GnVTFgRDD1loxjKJnw+N7q4rs4CygxX4gVxVfktj+SsFNIboVGUlEXw0+0LD7l
	MoVCTWygztoOqQhy0pjtgmm+P4gMrgeNbjhzA+bGeyk6Pw/qa6nDh4XeVebSmzAUnNQb
	KccsyN6KZ+IrVfBRiEwx3G+jxSgZqvieZITT15no/5b01FaQnF0ijih3thrqW8HuRqc0
	iMSA==
X-Gm-Message-State: ALoCoQk/ZECtA+WUXZcY+b+IYyMCwTbs9jUMMliaF9zQwEQHrogsTUQsghjPuK27J6VX6Zp+oz7g
X-Received: by 10.180.75.116 with SMTP id b20mr13531115wiw.49.1416405960098;
	Wed, 19 Nov 2014 06:06:00 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id he3sm2442351wjc.15.2014.11.19.06.05.58
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 06:05:59 -0800 (PST)
Message-ID: <546CA3C6.6010406@linaro.org>
Date: Wed, 19 Nov 2014 14:05:58 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>	<1416399227.29243.33.camel@citrix.com>	<alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>	<546C8BD9.8090406@linaro.org>	<CAH_mUMNsE7vyHWKGTaFvPoq4kBbJi6Pn8O9-fREC+hA+cQ+tSQ@mail.gmail.com>	<546C9A88.6000100@linaro.org>
	<CAH_mUMOTpKiyn91N5f2hUsZ1TFTMKRLJj795FLK6LdYRNS=h+w@mail.gmail.com>
In-Reply-To: <CAH_mUMOTpKiyn91N5f2hUsZ1TFTMKRLJj795FLK6LdYRNS=h+w@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/2014 01:30 PM, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 3:26 PM, Julien Grall <julien.grall@linaro.org> wrote:
>> On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
>>> Hi Julien,
>>>
>>> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>>>> On Wed, 19 Nov 2014, Ian Campbell wrote:
>>>>>> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
>>>>>>> So it looks like there is not actually anything wrong, is just that you
>>>>>>> have too much inflight irqs? It should cause problems because in that
>>>>>>> case GICH_HCR_UIE should be set and you should get a maintenance
>>>>>>> interrupt when LRs become available (actually when "none, or only one,
>>>>>>> of the List register entries is marked as a valid interrupt").
>>>>>>>
>>>>>>> Maybe GICH_HCR_UIE is the one that doesn't work properly.
>>>>>>
>>>>>> How much testing did this aspect get when the no-maint-irq series
>>>>>> originally went in? Did you manage to find a workload which filled all
>>>>>> the LRs or try artificially limiting the number of LRs somehow in order
>>>>>> to provoke it?
>>>>>>
>>>>>> I ask because my intuition is that this won't happen very much, meaning
>>>>>> those code paths may not be as well tested...
>>>>>
>>>>> I did test it by artificially limiting the number of LRs to 1.
>>>>> However there have been many iterations of that series and I didn't run
>>>>> this test at every iteration.
>>>>
>>>> am I the only to think this may not be related to this bug? All the LRs
>>>> are full with IRQ of the same priority. So it's valid.
>>>>
>>>> As gic_restore_pending_irqs is called every time that we return to the
>>>> guest. It could be anything else.
>>>>
>>>> It would be interesting to see why we are trapping all the time in Xen.
>>>>
>>>
>>> I may perform any test if you have some specific scenario.
>>
>> I have no specific scenario in my mind :/.
>>
>> It looks like I'm able to reproduce it on my ARM board by the restricted
>> the number of LRs to 1.
>>
> 
> Do you mean that you got a hang with current xen/master branch ?

Yes but I forgot to update another part of the code.

With the patch below to restrict the number of LRs I'm still able to boot.
And don't see any maintenance interrupt.

Stefano, is it valid?

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..c1c0f7ff 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -327,6 +327,7 @@ static void __cpuinit gicv2_hyp_init(void)
     vtr = readl_gich(GICH_VTR);
     nr_lrs  = (vtr & GICH_V2_VTR_NRLRGS) + 1;
     gicv2_info.nr_lrs = nr_lrs;
+    gicv2_info.nr_lrs = 1;
 
     writel_gich(GICH_MISR_EOI, GICH_MISR);
 }
@@ -488,6 +489,16 @@ static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
 
 static void gicv2_hcr_status(uint32_t flag, bool_t status)
 {
+    uint32_t lr = readl_gich(GICH_LR + 0);
+
+    if ( status )
+        lr |= GICH_V2_LR_MAINTENANCE_IRQ;
+    else
+        lr &= ~GICH_V2_LR_MAINTENANCE_IRQ;
+
+    writel_gich(lr, GICH_LR + 0);
+
+#if 0
     uint32_t hcr = readl_gich(GICH_HCR);
 
     if ( status )
@@ -496,6 +507,7 @@ static void gicv2_hcr_status(uint32_t flag, bool_t status)
         hcr &= (~flag);
 
     writel_gich(hcr, GICH_HCR);
+#endif
 }
 
 static unsigned int gicv2_read_vmcr_priority(void)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..c726d7a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -599,6 +599,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
      * on return to guest that is going to clear the old LRs and inject
      * new interrupts.
      */
+    gdprintk(XENLOG_DEBUG, "\n");
 }
 
 void gic_dump_info(struct vcpu *v)


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 14:06:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 14:06:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr5tV-0006x6-Hi; Wed, 19 Nov 2014 14:06:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr5tR-0006wr-Mt
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 14:06:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1D/EA-09936-8C3AC645; Wed, 19 Nov 2014 14:06:00 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416405960!13937696!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23370 invoked from network); 19 Nov 2014 14:06:00 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 14:06:00 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so945389wgh.20
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 06:06:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=A0KE6jZhHdQPoQl3Fh0Z1xCVJqzpEADl3IjTUJSyzSU=;
	b=iriH0MXBsb0vRwpXkHMXZFX1HvJu3CbwZYj1SbOTRBqpvRPz+3jP+BcwpdgIe16OXh
	SPxyn5XHH0O/af6quA/NgxIGdvhP9bpy4UNGYBM+pt5OvTHPEzS6qtU3+czKibfCUlNS
	/x34E/GnVTFgRDD1loxjKJnw+N7q4rs4CygxX4gVxVfktj+SsFNIboVGUlEXw0+0LD7l
	MoVCTWygztoOqQhy0pjtgmm+P4gMrgeNbjhzA+bGeyk6Pw/qa6nDh4XeVebSmzAUnNQb
	KccsyN6KZ+IrVfBRiEwx3G+jxSgZqvieZITT15no/5b01FaQnF0ijih3thrqW8HuRqc0
	iMSA==
X-Gm-Message-State: ALoCoQk/ZECtA+WUXZcY+b+IYyMCwTbs9jUMMliaF9zQwEQHrogsTUQsghjPuK27J6VX6Zp+oz7g
X-Received: by 10.180.75.116 with SMTP id b20mr13531115wiw.49.1416405960098;
	Wed, 19 Nov 2014 06:06:00 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id he3sm2442351wjc.15.2014.11.19.06.05.58
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 06:05:59 -0800 (PST)
Message-ID: <546CA3C6.6010406@linaro.org>
Date: Wed, 19 Nov 2014 14:05:58 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>	<1416399227.29243.33.camel@citrix.com>	<alpine.DEB.2.02.1411191216160.27247@kaball.uk.xensource.com>	<546C8BD9.8090406@linaro.org>	<CAH_mUMNsE7vyHWKGTaFvPoq4kBbJi6Pn8O9-fREC+hA+cQ+tSQ@mail.gmail.com>	<546C9A88.6000100@linaro.org>
	<CAH_mUMOTpKiyn91N5f2hUsZ1TFTMKRLJj795FLK6LdYRNS=h+w@mail.gmail.com>
In-Reply-To: <CAH_mUMOTpKiyn91N5f2hUsZ1TFTMKRLJj795FLK6LdYRNS=h+w@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/2014 01:30 PM, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 3:26 PM, Julien Grall <julien.grall@linaro.org> wrote:
>> On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
>>> Hi Julien,
>>>
>>> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>>>> On Wed, 19 Nov 2014, Ian Campbell wrote:
>>>>>> On Wed, 2014-11-19 at 11:42 +0000, Stefano Stabellini wrote:
>>>>>>> So it looks like there is not actually anything wrong, is just that you
>>>>>>> have too much inflight irqs? It should cause problems because in that
>>>>>>> case GICH_HCR_UIE should be set and you should get a maintenance
>>>>>>> interrupt when LRs become available (actually when "none, or only one,
>>>>>>> of the List register entries is marked as a valid interrupt").
>>>>>>>
>>>>>>> Maybe GICH_HCR_UIE is the one that doesn't work properly.
>>>>>>
>>>>>> How much testing did this aspect get when the no-maint-irq series
>>>>>> originally went in? Did you manage to find a workload which filled all
>>>>>> the LRs or try artificially limiting the number of LRs somehow in order
>>>>>> to provoke it?
>>>>>>
>>>>>> I ask because my intuition is that this won't happen very much, meaning
>>>>>> those code paths may not be as well tested...
>>>>>
>>>>> I did test it by artificially limiting the number of LRs to 1.
>>>>> However there have been many iterations of that series and I didn't run
>>>>> this test at every iteration.
>>>>
>>>> am I the only to think this may not be related to this bug? All the LRs
>>>> are full with IRQ of the same priority. So it's valid.
>>>>
>>>> As gic_restore_pending_irqs is called every time that we return to the
>>>> guest. It could be anything else.
>>>>
>>>> It would be interesting to see why we are trapping all the time in Xen.
>>>>
>>>
>>> I may perform any test if you have some specific scenario.
>>
>> I have no specific scenario in my mind :/.
>>
>> It looks like I'm able to reproduce it on my ARM board by the restricted
>> the number of LRs to 1.
>>
> 
> Do you mean that you got a hang with current xen/master branch ?

Yes but I forgot to update another part of the code.

With the patch below to restrict the number of LRs I'm still able to boot.
And don't see any maintenance interrupt.

Stefano, is it valid?

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..c1c0f7ff 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -327,6 +327,7 @@ static void __cpuinit gicv2_hyp_init(void)
     vtr = readl_gich(GICH_VTR);
     nr_lrs  = (vtr & GICH_V2_VTR_NRLRGS) + 1;
     gicv2_info.nr_lrs = nr_lrs;
+    gicv2_info.nr_lrs = 1;
 
     writel_gich(GICH_MISR_EOI, GICH_MISR);
 }
@@ -488,6 +489,16 @@ static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
 
 static void gicv2_hcr_status(uint32_t flag, bool_t status)
 {
+    uint32_t lr = readl_gich(GICH_LR + 0);
+
+    if ( status )
+        lr |= GICH_V2_LR_MAINTENANCE_IRQ;
+    else
+        lr &= ~GICH_V2_LR_MAINTENANCE_IRQ;
+
+    writel_gich(lr, GICH_LR + 0);
+
+#if 0
     uint32_t hcr = readl_gich(GICH_HCR);
 
     if ( status )
@@ -496,6 +507,7 @@ static void gicv2_hcr_status(uint32_t flag, bool_t status)
         hcr &= (~flag);
 
     writel_gich(hcr, GICH_HCR);
+#endif
 }
 
 static unsigned int gicv2_read_vmcr_priority(void)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..c726d7a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -599,6 +599,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
      * on return to guest that is going to clear the old LRs and inject
      * new interrupts.
      */
+    gdprintk(XENLOG_DEBUG, "\n");
 }
 
 void gic_dump_info(struct vcpu *v)


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 14:56:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 14:56:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr6gA-0007eC-HX; Wed, 19 Nov 2014 14:56:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr6g9-0007e7-1p
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 14:56:21 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	08/4E-02696-49FAC645; Wed, 19 Nov 2014 14:56:20 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416408976!8891783!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19484 invoked from network); 19 Nov 2014 14:56:19 -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;
	19 Nov 2014 14:56:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194408127"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 09:53:03 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr6cw-0004Gl-Ht;
	Wed, 19 Nov 2014 14:53:02 +0000
Date: Wed, 19 Nov 2014 14:52:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> > >      else
> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> > >
> > >  }
> >
> > Yes, exactly
> 
> I tried, hang still occurs with this change

We need to figure out why during the hang you still have all the LRs
busy even if you are getting maintenance interrupts that should cause
them to be cleared.

Could you please call gic_dump_info(current) from maintenance_interrupt,
and post the output during the hang? Remove the other gic_dump_info to
avoid confusion, we want to understand what is the status of the LRs
after clearing them upon receiving a maintenance interrupt at busy times.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 14:56:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 14:56:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr6gA-0007eC-HX; Wed, 19 Nov 2014 14:56:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr6g9-0007e7-1p
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 14:56:21 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	08/4E-02696-49FAC645; Wed, 19 Nov 2014 14:56:20 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416408976!8891783!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19484 invoked from network); 19 Nov 2014 14:56:19 -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;
	19 Nov 2014 14:56:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194408127"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 09:53:03 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr6cw-0004Gl-Ht;
	Wed, 19 Nov 2014 14:53:02 +0000
Date: Wed, 19 Nov 2014 14:52:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> > >      else
> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> > >
> > >  }
> >
> > Yes, exactly
> 
> I tried, hang still occurs with this change

We need to figure out why during the hang you still have all the LRs
busy even if you are getting maintenance interrupts that should cause
them to be cleared.

Could you please call gic_dump_info(current) from maintenance_interrupt,
and post the output during the hang? Remove the other gic_dump_info to
avoid confusion, we want to understand what is the status of the LRs
after clearing them upon receiving a maintenance interrupt at busy times.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 14:57:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 14: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 1Xr6gu-0007gQ-Uo; Wed, 19 Nov 2014 14:57:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xr6gt-0007g9-8B
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 14:57:07 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	E6/F1-11581-2CFAC645; Wed, 19 Nov 2014 14:57:06 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416409022!12298181!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3151 invoked from network); 19 Nov 2014 14:57:04 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 14:57:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416409024; x=1447945024;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=+7PzlAEjarilyoq28o/Mydo7nUlEEAkJ4sELN3o2DGM=;
	b=BP1gEHuvWDQW5ivQ2lBXLFplmTey51px7/sJhK02mmOpaNnIoYa8ko24
	IEc7qo7m+xgLIw8+LDf6cmkYSx1xOal+lnuACLDJ+GFrab+9CF0zGJNpX
	Eo2R7/OqJSm1XXy1pTZXorO+cCSnm8Vlf/Y6CNQ1m5xmXHnu23W4oiczH Y=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 19 Nov 2014 14:56:52 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="908800320"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.96.159])
	by fldsmtpi01.verizon.com with ESMTP; 19 Nov 2014 14:56:50 +0000
Message-ID: <546CAFB1.8070904@terremark.com>
Date: Wed, 19 Nov 2014 09:56:49 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
In-Reply-To: <546CA38A.7040509@m2r.biz>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	dslutz@verizon.com, anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org
Subject: Re: [Xen-devel] [Qemu-devel] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I think I know what is happening here.  But you are pointing at the 
wrong change.

commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4

Is what I am guessing at this time is the issue.  I think that 
xen_enabled() is
returning false in pc_machine_initfn.  Where as in pc_init1 is is 
returning true.

I am thinking that:


diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7bb97a4..3268c29 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
      .desc = "Xen Fully-virtualized PC",
      .init = pc_xen_hvm_init,
      .max_cpus = HVM_MAX_VCPUS,
-    .default_machine_opts = "accel=xen",
+    .default_machine_opts = "accel=xen,vmport=off",
      .hot_add_cpu = pc_hot_add_cpu,
  };
  #endif

Will fix your issue. I have not tested this yet.

     -Don Slutz


On 11/19/14 09:04, Fabio Fantoni wrote:
> Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
>> dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid 
>> leaf with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" 
>> patches, and qemu 2.2 from spice git (spice/next commit 
>> e779fa0a715530311e6f59fc8adb0f6eca914a89):
>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>
> I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the 
> full backtrace of latest test:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, addr=0,
>>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>> 73          eax = env->regs[R_EAX];
>> (gdb) bt full
>> #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, 
>> addr=0,
>>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>         s = 0x5555564443a0
>>         cs = 0x0
>>         cpu = 0x0
>>         __func__ = "vmport_ioport_read"
>>         env = 0x8250
>>         command = 0 '\000'
>>         eax = 0
>> #1  0x0000555555655fc4 in memory_region_read_accessor 
>> (mr=0x555556444428,
>>     addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>         tmp = 0
>> #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
>>     value=0x7fffffffd8d0, size=4, access_size_min=4, access_size_max=4,
>>     access=0x555555655f62 <memory_region_read_accessor>, 
>> mr=0x555556444428)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>         access_mask = 4294967295
>>         access_size = 4
>>         i = 0
>> #3  0x00005555556590e9 in memory_region_dispatch_read1 
>> (mr=0x555556444428,
>>     addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>         data = 0
>> #4  0x00005555556591b1 in memory_region_dispatch_read 
>> (mr=0x555556444428,
>>     addr=0, pval=0x7fffffffd9a8, size=4)
>> ---Type <return> to continue, or q <return> to quit---
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>> No locals.
>> #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
>>     pval=0x7fffffffd9a8, size=4)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>> No locals.
>> #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920, 
>> addr=22104,
>>     buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
>>         l = 4
>>         ptr = 0x555555a92d87 "%s/%d:\n"
>>         val = 7852232130387826944
>>         addr1 = 0
>>         mr = 0x555556444428
>>         error = false
>> #7  0x000055555560a38f in address_space_read (as=0x555555eaf920, 
>> addr=22104,
>>     buf=0x7fffffffda50 "\377\377\377\377", len=4)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
>> No locals.
>> #8  0x000055555564fd4b in cpu_inl (addr=22104)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>         buf = "\377\377\377\377"
>>         val = 21845
>> #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>> ---Type <return> to continue, or q <return> to quit---
>> No locals.
>> #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>         i = 1
>> #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
>>     req=0x7ffff7ff3020) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>> No locals.
>> #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>         state = 0x5555563c2510
>>         req = 0x7ffff7ff3020
>> #13 0x000055555596e240 in qemu_iohandler_poll 
>> (pollfds=0x555556389a30, ret=1)
>>     at iohandler.c:143
>>         revents = 1
>>         pioh = 0x5555563f7610
>>         ioh = 0x555556450a40
>> #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at 
>> main-loop.c:495
>>         ret = 1
>>         timeout = 4294967295
>>         timeout_ns = 3965432
>> #15 0x0000555555756d3f in main_loop () at vl.c:1882
>>         nonblocking = false
>>         last_io = 0
>> #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
>>     envp=0x7fffffffe240) at vl.c:4400
>> ---Type <return> to continue, or q <return> to quit---
>>         i = 128
>>         snapshot = 0
>>         linux_boot = 0
>>         initrd_filename = 0x0
>>         kernel_filename = 0x0
>>         kernel_cmdline = 0x555555a48f86 ""
>>         boot_order = 0x555556387460 "dc"
>>         ds = 0x5555564b2040
>>         cyls = 0
>>         heads = 0
>>         secs = 0
>>         translation = 0
>>         hda_opts = 0x0
>>         opts = 0x5555563873b0
>>         machine_opts = 0x555556389010
>>         icount_opts = 0x0
>>         olist = 0x555555e57e80
>>         optind = 62
>>         optarg = 0x7fffffffe914 
>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>         loadvm = 0x0
>>         machine_class = 0x55555637d5c0
>>         cpu_model = 0x0
>>         vga_model = 0x0
>>         qtest_chrdev = 0x0
>> ---Type <return> to continue, or q <return> to quit---
>>         qtest_log = 0x0
>>         pid_file = 0x0
>>         incoming = 0x0
>>         show_vnc_port = 0
>>         defconfig = true
>>         userconfig = true
>>         log_mask = 0x0
>>         log_file = 0x0
>>         mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
>>           realloc = 0x55555575a45a <realloc_and_trace>,
>>           free = 0x55555575a4c1 <free_and_trace>, calloc = 0, 
>> try_malloc = 0,
>>           try_realloc = 0}
>>         trace_events = 0x0
>>         trace_file = 0x0
>>         default_ram_size = 134217728
>>         maxram_size = 2130706432
>>         ram_slots = 0
>>         vmstate_dump_file = 0x0
>>         main_loop_err = 0x0
>>         __func__ = "main"
>
> I take a fast look in source based on calltrace and I saw this commit:
> http://git.qemu.org/?p=qemu.git;a=commit;h=37f9e258b64b3cf97c7c78df60660100c9eb5a21 
>
> xen-hvm.c: Add support for Xen access to vmport
> Can be the cause of regression and I must try another test reverting 
> this commit or is not related?
>
> Thanks for any reply anddo sorry for my bad english.
>
>>
>> Qemu crash on fedora 20 lxde (with software updates of some days ago) 
>> boot with this backtrace:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
>>> addr=0, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>> 73          eax = env->regs[R_EAX];
>>> (gdb) bt full
>>> #0  0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
>>> addr=0, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>         s = 0x555556440a20
>>>         cs = 0x0
>>>         cpu = 0x0
>>>         __func__ = "vmport_ioport_read"
>>>         env = 0x8250
>>>         command = 0 '\000'
>>>         eax = 0
>>> #1  0x0000555555655b9c in memory_region_read_accessor 
>>> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0, 
>>> mask=4294967295)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>         tmp = 0
>>> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0, 
>>> value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
>>>     access=0x555555655b3a <memory_region_read_accessor>, 
>>> mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>         access_mask = 4294967295
>>>         access_size = 4
>>>         i = 0
>>> #3  0x0000555555658cc1 in memory_region_dispatch_read1 
>>> (mr=0x555556440aa8, addr=0, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>         data = 0
>>> #4  0x0000555555658d89 in memory_region_dispatch_read 
>>> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>> No locals.
>>> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0, 
>>> pval=0x7fffffffd998, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>> No locals.
>>> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840, 
>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4, 
>>> is_write=false)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>>>         l = 4
>>>         ptr = 0x0
>>>         val = 7964229952888770560
>>>         addr1 = 0
>>>         mr = 0x555556440aa8
>>>         error = false
>>> #7  0x000055555560a173 in address_space_read (as=0x555555eae840, 
>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
>>> No locals.
>>> #8  0x000055555564fac7 in cpu_inl (addr=22104) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>         buf = "\377\377\377\377"
>>>         val = 21845
>>> #9  0x000055555567084b in do_inp (addr=22104, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>> No locals.
>>> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>         i = 0
>>> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590, 
>>> req=0x7ffff7ff3000) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>> ---Type <return> to continue, or q <return> to quit---
>>> No locals.
>>> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) 
>>> at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>         state = 0x5555563c1590
>>>         req = 0x7ffff7ff3000
>>> #13 0x000055555596d874 in qemu_iohandler_poll 
>>> (pollfds=0x555556388a30, ret=1) at iohandler.c:143
>>>         revents = 1
>>>         pioh = 0x5555563f3c90
>>>         ioh = 0x555556515f80
>>> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at 
>>> main-loop.c:495
>>>         ret = 1
>>>         timeout = 4294967295
>>>         timeout_ns = 3418165
>>> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>>>         nonblocking = false
>>>         last_io = 1
>>> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038, 
>>> envp=0x7fffffffe230) at vl.c:4400
>>>         i = 128
>>>         snapshot = 0
>>>         linux_boot = 0
>>>         initrd_filename = 0x0
>>>         kernel_filename = 0x0
>>>         kernel_cmdline = 0x555555a485c6 ""
>>>         boot_order = 0x5555563864e0 "dc"
>>>         ds = 0x5555564c71b0
>>>         cyls = 0
>>>         heads = 0
>>>         secs = 0
>>>         translation = 0
>>>         hda_opts = 0x0
>>>         opts = 0x555556386430
>>>         machine_opts = 0x555556388090
>>>         icount_opts = 0x0
>>>         olist = 0x555555e56da0
>>>         optind = 62
>>>         optarg = 0x7fffffffe914 
>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>         loadvm = 0x0
>>>         machine_class = 0x55555637c5c0
>>>         cpu_model = 0x0
>>>         vga_model = 0x0
>>>         qtest_chrdev = 0x0
>>> ---Type <return> to continue, or q <return> to quit---
>>>         qtest_log = 0x0
>>>         pid_file = 0x0
>>>         incoming = 0x0
>>>         show_vnc_port = 0
>>>         defconfig = true
>>>         userconfig = true
>>>         log_mask = 0x0
>>>         log_file = 0x0
>>>         mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>, 
>>> realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39 
>>> <free_and_trace>, calloc = 0,
>>>           try_malloc = 0, try_realloc = 0}
>>>         trace_events = 0x0
>>>         trace_file = 0x0
>>>         default_ram_size = 134217728
>>>         maxram_size = 2013265920
>>>         ram_slots = 0
>>>         vmstate_dump_file = 0x0
>>>         main_loop_err = 0x0
>>>         __func__ = "main"
>>
>>
>>> xl -vvv create /etc/xen/FEDORA19.cfg
>>> Parsing config from /etc/xen/FEDORA19.cfg
>>> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660: 
>>> create: how=(nil) callback=(nil) poller=0xac2af0
>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: 
>>> Disk vdev=hda spec.backend=unknown
>>> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda, 
>>> backend phy unsuitable as phys path not a block device
>>> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: 
>>> Disk vdev=hda, using backend qdisk
>>> libxl: debug: libxl_create.c:935:initiate_domain_create: running 
>>> bootloader
>>> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV 
>>> domain, skipping bootloader
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac32f8: deregister unregistered
>>> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
>>> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
>>> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
>>> xc: detail:   Loader:   0000000000100000->000000000036b324
>>> xc: detail:   Modules:  0000000000000000->0000000000000000
>>> xc: detail:   TOTAL:    0000000000000000->0000000078000000
>>> xc: detail:   ENTRY:    0000000000100000
>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>> xc: detail:   4KB PAGES: 0x0000000000000200
>>> xc: detail:   2MB PAGES: 0x00000000000003bf
>>> xc: detail:   1GB PAGES: 0x0000000000000000
>>> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 -> 0x7f1f975012b0
>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: 
>>> Disk vdev=hda spec.backend=qdisk
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac4ad0: deregister unregistered
>>> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning 
>>> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> /usr/lib/xen/bin/qemu-gdb
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> chardev=libxl-cmd,mode=control
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   FEDORA
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -spice
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> spicevmc,id=vdagent,name=vdagent
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> virtserialport,chardev=vdagent,name=com.redhat.spice.0
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> qxl-vga,vram_size_mb=64,ram_size_mb=64
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> spicevmc,name=usbredir,id=usbrc1
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> usb-redir,chardev=usbrc1,id=usbrc1
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> spicevmc,name=usbredir,id=usbrc2
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> usb-redir,chardev=usbrc2,id=usbrc2
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> spicevmc,name=usbredir,id=usbrc3
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> usb-redir,chardev=usbrc3,id=usbrc3
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> spicevmc,name=usbredir,id=usbrc4
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> usb-redir,chardev=usbrc4,id=usbrc4
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -netdev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -drive
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>>> register slotnum=3
>>> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660: 
>>> inprogress: poller=0xac2af0, flags=i
>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>>> epath=/local/domain/0/device-model/9/state
>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>>> epath=/local/domain/0/device-model/9/state
>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>>> deregister slotnum=3
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac3558: deregister unregistered
>>> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to 
>>> /var/run/xen/qmp-libxl-9
>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>     "execute": "qmp_capabilities",
>>>     "id": 1
>>> }
>>> '
>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>     "execute": "query-chardev",
>>>     "id": 2
>>> }
>>> '
>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>     "execute": "query-vnc",
>>>     "id": 3
>>> }
>>> '
>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>>> register slotnum=3
>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>>> epath=/local/domain/0/backend/vif/9/0/state
>>> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend 
>>> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting 
>>> state 1
>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>>> epath=/local/domain/0/backend/vif/9/0/state
>>> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend 
>>> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>>> deregister slotnum=3
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac8368: deregister unregistered
>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>>> script: /etc/xen/scripts/vif-bridge online
>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking 
>>> to execute: /etc/xen/scripts/vif-bridge online
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac83f0: deregister unregistered
>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>>> script: /etc/xen/scripts/vif-bridge add
>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking 
>>> to execute: /etc/xen/scripts/vif-bridge add
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac83f0: deregister unregistered
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac83f0: deregister unregistered
>>> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao 
>>> 0xac2660: progress report: ignored
>>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660: 
>>> complete, rc=0
>>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660: 
>>> destroy
>>> xc: debug: hypercall buffer: total allocations:704 total releases:704
>>> xc: debug: hypercall buffer: current allocations:0 maximum 
>>> allocations:4
>>> xc: debug: hypercall buffer: cache current size:4
>>> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
>>> xc: debug: hypercall buffer: total allocations:0 total releases:0
>>> xc: debug: hypercall buffer: current allocations:0 maximum 
>>> allocations:0
>>> xc: debug: hypercall buffer: cache current size:0
>>> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
>>
>> xl dmesg
>>> (d9) HVM Loader
>>> (d9) Detected Xen v4.5.0-rc
>>> (d9) Xenbus rings @0xfeffc000, event channel 1
>>> (d9) System requested SeaBIOS
>>> (d9) CPU speed is 2660 MHz
>>> (d9) Relocating guest memory for lowmem MMIO space disabled
>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
>>> (d9) PCI-ISA link 0 routed to IRQ5
>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
>>> (d9) PCI-ISA link 1 routed to IRQ10
>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
>>> (d9) PCI-ISA link 2 routed to IRQ11
>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
>>> (d9) PCI-ISA link 3 routed to IRQ5
>>> (d9) pci dev 01:3 INTA->IRQ10
>>> (d9) pci dev 02:0 INTA->IRQ11
>>> (d9) pci dev 03:0 INTA->IRQ5
>>> (d9) pci dev 04:0 INTA->IRQ5
>>> (d9) pci dev 05:0 INTA->IRQ10
>>> (d9) pci dev 06:0 INTA->IRQ11
>>> (d9) pci dev 1d:0 INTA->IRQ10
>>> (d9) pci dev 1d:1 INTB->IRQ11
>>> (d9) pci dev 1d:2 INTC->IRQ5
>>> (d9) pci dev 1d:7 INTD->IRQ5
>>> (d9) No RAM in high memory; setting high_mem resource base to 100000000
>>> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
>>> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
>>> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
>>> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
>>> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>> (d9) Multiprocessor initialisation:
>>> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>>> done.
>>> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>>> done.
>>> (d9) Testing HVM environment:
>>> (d9)  - REP INSB across page boundaries ... passed
>>> (d9)  - GS base MSRs and SWAPGS ... passed
>>> (d9) Passed 2 of 2 tests
>>> (d9) Writing SMBIOS tables ...
>>> (d9) Loading SeaBIOS ...
>>> (d9) Creating MP tables ...
>>> (d9) Loading ACPI ...
>>> (d9) S3 disabled
>>> (d9) S4 disabled
>>> (d9) vm86 TSS at fc00a100
>>> (d9) BIOS map:
>>> (d9)  10000-100d3: Scratch space
>>> (d9)  c0000-fffff: Main BIOS
>>> (d9) E820 table:
>>> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
>>> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>> (d9) Invoking SeaBIOS ...
>>> (d9) SeaBIOS (version 
>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>> (d9)
>>> (d9) Found Xen hypervisor signature at 40000000
>>> (d9) Running on QEMU (i440fx)
>>> (d9) xen: copy e820...
>>> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>> (d9) CPU Mhz=2660
>>> (d9) Found 13 PCI devices (max PCI bus is 00)
>>> (d9) Allocated Xen hypercall page at 77fff000
>>> (d9) Detected Xen v4.5.0-rc
>>> (d9) xen: copy BIOS tables...
>>> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
>>> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>> (d9) Using pmtimer, ioport 0xb008
>>> (d9) Scan for VGA option rom
>>> (d9) Running option rom at c000:0003
>>> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
>>> (d9) pmm call arg1=0
>>> (d9) Turning on vga text mode console
>>> (d9) SeaBIOS (version 
>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
>>> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
>>> (d9) Found 0 lpt ports
>>> (d9) Found 0 serial ports
>>> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
>>> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>> (d9) UHCI init on dev 00:1d.0 (io=c240)
>>> (d9) UHCI init on dev 00:1d.1 (io=c260)
>>> (d9) UHCI init on dev 00:1d.2 (io=c280)
>>> (d9) PS2 keyboard initialized
>>> (d9) All threads complete.
>>> (d9) Scan for option roms
>>> (d9) Running option rom at c980:0003
>>> (d9) pmm call arg1=1
>>> (d9) pmm call arg1=0
>>> (d9) pmm call arg1=1
>>> (d9) pmm call arg1=0
>>> (d9) Searching bootorder for: /pci@i0cf8/*@6
>>> (d9)
>>> (d9) Press F12 for boot menu.
>>> (d9)
>>> (d9) Searching bootorder for: HALT
>>> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba 
>>> LCHS=1024/255/63 s=20480000
>>> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
>>> (d9) Returned 258048 bytes of ZoneHigh
>>> (d9) e820 map has 6 items:
>>> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>>> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>>> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>>> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
>>> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
>>> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
>>> (d9) enter handle_19:
>>> (d9)   NULL
>>> (d9) Booting from Hard Disk...
>>> (d9) Booting from 0000:7c00
>>> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
>>
>> domU's xl cfg:
>>> name='FEDORA'
>>> builder="hvm"
>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>> memory=2048
>>> vcpus=2
>>> acpi_s3=0
>>> acpi_s4=0
>>> vif=['bridge=xenbr0']
>>> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
>>> boot='dc'
>>> device_model_version='qemu-xen'
>>> vnc=0
>>> keymap="it"
>>> vga="qxl"
>>> spice=1
>>> spicehost='0.0.0.0'
>>> spiceport=6005
>>> spicedisable_ticketing=1
>>> spicevdagent=1
>>> spice_clipboard_sharing=0
>>> spiceusbredirection=4
>>> soundhw="hda"
>>
>> I tested also with stdvga instead of qxl vga but qemu crash always on 
>> fedora boot with same error.
>>
>> If you need more informations/tests tell me and I'll post them.
>>
>> Thanks for any reply and sorry for my bad english.
>>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 14:57:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 14: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 1Xr6gu-0007gQ-Uo; Wed, 19 Nov 2014 14:57:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xr6gt-0007g9-8B
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 14:57:07 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	E6/F1-11581-2CFAC645; Wed, 19 Nov 2014 14:57:06 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416409022!12298181!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3151 invoked from network); 19 Nov 2014 14:57:04 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 14:57:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416409024; x=1447945024;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=+7PzlAEjarilyoq28o/Mydo7nUlEEAkJ4sELN3o2DGM=;
	b=BP1gEHuvWDQW5ivQ2lBXLFplmTey51px7/sJhK02mmOpaNnIoYa8ko24
	IEc7qo7m+xgLIw8+LDf6cmkYSx1xOal+lnuACLDJ+GFrab+9CF0zGJNpX
	Eo2R7/OqJSm1XXy1pTZXorO+cCSnm8Vlf/Y6CNQ1m5xmXHnu23W4oiczH Y=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 19 Nov 2014 14:56:52 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="908800320"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.96.159])
	by fldsmtpi01.verizon.com with ESMTP; 19 Nov 2014 14:56:50 +0000
Message-ID: <546CAFB1.8070904@terremark.com>
Date: Wed, 19 Nov 2014 09:56:49 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
In-Reply-To: <546CA38A.7040509@m2r.biz>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	dslutz@verizon.com, anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org
Subject: Re: [Xen-devel] [Qemu-devel] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I think I know what is happening here.  But you are pointing at the 
wrong change.

commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4

Is what I am guessing at this time is the issue.  I think that 
xen_enabled() is
returning false in pc_machine_initfn.  Where as in pc_init1 is is 
returning true.

I am thinking that:


diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7bb97a4..3268c29 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
      .desc = "Xen Fully-virtualized PC",
      .init = pc_xen_hvm_init,
      .max_cpus = HVM_MAX_VCPUS,
-    .default_machine_opts = "accel=xen",
+    .default_machine_opts = "accel=xen,vmport=off",
      .hot_add_cpu = pc_hot_add_cpu,
  };
  #endif

Will fix your issue. I have not tested this yet.

     -Don Slutz


On 11/19/14 09:04, Fabio Fantoni wrote:
> Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
>> dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid 
>> leaf with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" 
>> patches, and qemu 2.2 from spice git (spice/next commit 
>> e779fa0a715530311e6f59fc8adb0f6eca914a89):
>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>
> I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the 
> full backtrace of latest test:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, addr=0,
>>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>> 73          eax = env->regs[R_EAX];
>> (gdb) bt full
>> #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, 
>> addr=0,
>>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>         s = 0x5555564443a0
>>         cs = 0x0
>>         cpu = 0x0
>>         __func__ = "vmport_ioport_read"
>>         env = 0x8250
>>         command = 0 '\000'
>>         eax = 0
>> #1  0x0000555555655fc4 in memory_region_read_accessor 
>> (mr=0x555556444428,
>>     addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>         tmp = 0
>> #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
>>     value=0x7fffffffd8d0, size=4, access_size_min=4, access_size_max=4,
>>     access=0x555555655f62 <memory_region_read_accessor>, 
>> mr=0x555556444428)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>         access_mask = 4294967295
>>         access_size = 4
>>         i = 0
>> #3  0x00005555556590e9 in memory_region_dispatch_read1 
>> (mr=0x555556444428,
>>     addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>         data = 0
>> #4  0x00005555556591b1 in memory_region_dispatch_read 
>> (mr=0x555556444428,
>>     addr=0, pval=0x7fffffffd9a8, size=4)
>> ---Type <return> to continue, or q <return> to quit---
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>> No locals.
>> #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
>>     pval=0x7fffffffd9a8, size=4)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>> No locals.
>> #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920, 
>> addr=22104,
>>     buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
>>         l = 4
>>         ptr = 0x555555a92d87 "%s/%d:\n"
>>         val = 7852232130387826944
>>         addr1 = 0
>>         mr = 0x555556444428
>>         error = false
>> #7  0x000055555560a38f in address_space_read (as=0x555555eaf920, 
>> addr=22104,
>>     buf=0x7fffffffda50 "\377\377\377\377", len=4)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
>> No locals.
>> #8  0x000055555564fd4b in cpu_inl (addr=22104)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>         buf = "\377\377\377\377"
>>         val = 21845
>> #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>> ---Type <return> to continue, or q <return> to quit---
>> No locals.
>> #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>         i = 1
>> #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
>>     req=0x7ffff7ff3020) at 
>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>> No locals.
>> #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>         state = 0x5555563c2510
>>         req = 0x7ffff7ff3020
>> #13 0x000055555596e240 in qemu_iohandler_poll 
>> (pollfds=0x555556389a30, ret=1)
>>     at iohandler.c:143
>>         revents = 1
>>         pioh = 0x5555563f7610
>>         ioh = 0x555556450a40
>> #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at 
>> main-loop.c:495
>>         ret = 1
>>         timeout = 4294967295
>>         timeout_ns = 3965432
>> #15 0x0000555555756d3f in main_loop () at vl.c:1882
>>         nonblocking = false
>>         last_io = 0
>> #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
>>     envp=0x7fffffffe240) at vl.c:4400
>> ---Type <return> to continue, or q <return> to quit---
>>         i = 128
>>         snapshot = 0
>>         linux_boot = 0
>>         initrd_filename = 0x0
>>         kernel_filename = 0x0
>>         kernel_cmdline = 0x555555a48f86 ""
>>         boot_order = 0x555556387460 "dc"
>>         ds = 0x5555564b2040
>>         cyls = 0
>>         heads = 0
>>         secs = 0
>>         translation = 0
>>         hda_opts = 0x0
>>         opts = 0x5555563873b0
>>         machine_opts = 0x555556389010
>>         icount_opts = 0x0
>>         olist = 0x555555e57e80
>>         optind = 62
>>         optarg = 0x7fffffffe914 
>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>         loadvm = 0x0
>>         machine_class = 0x55555637d5c0
>>         cpu_model = 0x0
>>         vga_model = 0x0
>>         qtest_chrdev = 0x0
>> ---Type <return> to continue, or q <return> to quit---
>>         qtest_log = 0x0
>>         pid_file = 0x0
>>         incoming = 0x0
>>         show_vnc_port = 0
>>         defconfig = true
>>         userconfig = true
>>         log_mask = 0x0
>>         log_file = 0x0
>>         mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
>>           realloc = 0x55555575a45a <realloc_and_trace>,
>>           free = 0x55555575a4c1 <free_and_trace>, calloc = 0, 
>> try_malloc = 0,
>>           try_realloc = 0}
>>         trace_events = 0x0
>>         trace_file = 0x0
>>         default_ram_size = 134217728
>>         maxram_size = 2130706432
>>         ram_slots = 0
>>         vmstate_dump_file = 0x0
>>         main_loop_err = 0x0
>>         __func__ = "main"
>
> I take a fast look in source based on calltrace and I saw this commit:
> http://git.qemu.org/?p=qemu.git;a=commit;h=37f9e258b64b3cf97c7c78df60660100c9eb5a21 
>
> xen-hvm.c: Add support for Xen access to vmport
> Can be the cause of regression and I must try another test reverting 
> this commit or is not related?
>
> Thanks for any reply anddo sorry for my bad english.
>
>>
>> Qemu crash on fedora 20 lxde (with software updates of some days ago) 
>> boot with this backtrace:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
>>> addr=0, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>> 73          eax = env->regs[R_EAX];
>>> (gdb) bt full
>>> #0  0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
>>> addr=0, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>         s = 0x555556440a20
>>>         cs = 0x0
>>>         cpu = 0x0
>>>         __func__ = "vmport_ioport_read"
>>>         env = 0x8250
>>>         command = 0 '\000'
>>>         eax = 0
>>> #1  0x0000555555655b9c in memory_region_read_accessor 
>>> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0, 
>>> mask=4294967295)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>         tmp = 0
>>> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0, 
>>> value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
>>>     access=0x555555655b3a <memory_region_read_accessor>, 
>>> mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>         access_mask = 4294967295
>>>         access_size = 4
>>>         i = 0
>>> #3  0x0000555555658cc1 in memory_region_dispatch_read1 
>>> (mr=0x555556440aa8, addr=0, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>         data = 0
>>> #4  0x0000555555658d89 in memory_region_dispatch_read 
>>> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>> No locals.
>>> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0, 
>>> pval=0x7fffffffd998, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>> No locals.
>>> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840, 
>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4, 
>>> is_write=false)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>>>         l = 4
>>>         ptr = 0x0
>>>         val = 7964229952888770560
>>>         addr1 = 0
>>>         mr = 0x555556440aa8
>>>         error = false
>>> #7  0x000055555560a173 in address_space_read (as=0x555555eae840, 
>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
>>> No locals.
>>> #8  0x000055555564fac7 in cpu_inl (addr=22104) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>         buf = "\377\377\377\377"
>>>         val = 21845
>>> #9  0x000055555567084b in do_inp (addr=22104, size=4) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>> No locals.
>>> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>         i = 0
>>> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590, 
>>> req=0x7ffff7ff3000) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>> ---Type <return> to continue, or q <return> to quit---
>>> No locals.
>>> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) 
>>> at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>         state = 0x5555563c1590
>>>         req = 0x7ffff7ff3000
>>> #13 0x000055555596d874 in qemu_iohandler_poll 
>>> (pollfds=0x555556388a30, ret=1) at iohandler.c:143
>>>         revents = 1
>>>         pioh = 0x5555563f3c90
>>>         ioh = 0x555556515f80
>>> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at 
>>> main-loop.c:495
>>>         ret = 1
>>>         timeout = 4294967295
>>>         timeout_ns = 3418165
>>> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>>>         nonblocking = false
>>>         last_io = 1
>>> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038, 
>>> envp=0x7fffffffe230) at vl.c:4400
>>>         i = 128
>>>         snapshot = 0
>>>         linux_boot = 0
>>>         initrd_filename = 0x0
>>>         kernel_filename = 0x0
>>>         kernel_cmdline = 0x555555a485c6 ""
>>>         boot_order = 0x5555563864e0 "dc"
>>>         ds = 0x5555564c71b0
>>>         cyls = 0
>>>         heads = 0
>>>         secs = 0
>>>         translation = 0
>>>         hda_opts = 0x0
>>>         opts = 0x555556386430
>>>         machine_opts = 0x555556388090
>>>         icount_opts = 0x0
>>>         olist = 0x555555e56da0
>>>         optind = 62
>>>         optarg = 0x7fffffffe914 
>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>         loadvm = 0x0
>>>         machine_class = 0x55555637c5c0
>>>         cpu_model = 0x0
>>>         vga_model = 0x0
>>>         qtest_chrdev = 0x0
>>> ---Type <return> to continue, or q <return> to quit---
>>>         qtest_log = 0x0
>>>         pid_file = 0x0
>>>         incoming = 0x0
>>>         show_vnc_port = 0
>>>         defconfig = true
>>>         userconfig = true
>>>         log_mask = 0x0
>>>         log_file = 0x0
>>>         mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>, 
>>> realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39 
>>> <free_and_trace>, calloc = 0,
>>>           try_malloc = 0, try_realloc = 0}
>>>         trace_events = 0x0
>>>         trace_file = 0x0
>>>         default_ram_size = 134217728
>>>         maxram_size = 2013265920
>>>         ram_slots = 0
>>>         vmstate_dump_file = 0x0
>>>         main_loop_err = 0x0
>>>         __func__ = "main"
>>
>>
>>> xl -vvv create /etc/xen/FEDORA19.cfg
>>> Parsing config from /etc/xen/FEDORA19.cfg
>>> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660: 
>>> create: how=(nil) callback=(nil) poller=0xac2af0
>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: 
>>> Disk vdev=hda spec.backend=unknown
>>> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda, 
>>> backend phy unsuitable as phys path not a block device
>>> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: 
>>> Disk vdev=hda, using backend qdisk
>>> libxl: debug: libxl_create.c:935:initiate_domain_create: running 
>>> bootloader
>>> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV 
>>> domain, skipping bootloader
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac32f8: deregister unregistered
>>> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
>>> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
>>> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
>>> xc: detail:   Loader:   0000000000100000->000000000036b324
>>> xc: detail:   Modules:  0000000000000000->0000000000000000
>>> xc: detail:   TOTAL:    0000000000000000->0000000078000000
>>> xc: detail:   ENTRY:    0000000000100000
>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>> xc: detail:   4KB PAGES: 0x0000000000000200
>>> xc: detail:   2MB PAGES: 0x00000000000003bf
>>> xc: detail:   1GB PAGES: 0x0000000000000000
>>> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 -> 0x7f1f975012b0
>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: 
>>> Disk vdev=hda spec.backend=qdisk
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac4ad0: deregister unregistered
>>> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning 
>>> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> /usr/lib/xen/bin/qemu-gdb
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> chardev=libxl-cmd,mode=control
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   FEDORA
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -spice
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> spicevmc,id=vdagent,name=vdagent
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> virtserialport,chardev=vdagent,name=com.redhat.spice.0
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> qxl-vga,vram_size_mb=64,ram_size_mb=64
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> spicevmc,name=usbredir,id=usbrc1
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> usb-redir,chardev=usbrc1,id=usbrc1
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> spicevmc,name=usbredir,id=usbrc2
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> usb-redir,chardev=usbrc2,id=usbrc2
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> spicevmc,name=usbredir,id=usbrc3
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> usb-redir,chardev=usbrc3,id=usbrc3
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> spicevmc,name=usbredir,id=usbrc4
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> usb-redir,chardev=usbrc4,id=usbrc4
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -device
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -netdev
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -drive
>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>>> register slotnum=3
>>> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660: 
>>> inprogress: poller=0xac2af0, flags=i
>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>>> epath=/local/domain/0/device-model/9/state
>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>>> epath=/local/domain/0/device-model/9/state
>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>>> deregister slotnum=3
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac3558: deregister unregistered
>>> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to 
>>> /var/run/xen/qmp-libxl-9
>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>     "execute": "qmp_capabilities",
>>>     "id": 1
>>> }
>>> '
>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>     "execute": "query-chardev",
>>>     "id": 2
>>> }
>>> '
>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>     "execute": "query-vnc",
>>>     "id": 3
>>> }
>>> '
>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>>> register slotnum=3
>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>>> epath=/local/domain/0/backend/vif/9/0/state
>>> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend 
>>> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting 
>>> state 1
>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>>> epath=/local/domain/0/backend/vif/9/0/state
>>> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend 
>>> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>>> deregister slotnum=3
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac8368: deregister unregistered
>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>>> script: /etc/xen/scripts/vif-bridge online
>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking 
>>> to execute: /etc/xen/scripts/vif-bridge online
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac83f0: deregister unregistered
>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>>> script: /etc/xen/scripts/vif-bridge add
>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking 
>>> to execute: /etc/xen/scripts/vif-bridge add
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac83f0: deregister unregistered
>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>> w=0xac83f0: deregister unregistered
>>> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao 
>>> 0xac2660: progress report: ignored
>>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660: 
>>> complete, rc=0
>>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660: 
>>> destroy
>>> xc: debug: hypercall buffer: total allocations:704 total releases:704
>>> xc: debug: hypercall buffer: current allocations:0 maximum 
>>> allocations:4
>>> xc: debug: hypercall buffer: cache current size:4
>>> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
>>> xc: debug: hypercall buffer: total allocations:0 total releases:0
>>> xc: debug: hypercall buffer: current allocations:0 maximum 
>>> allocations:0
>>> xc: debug: hypercall buffer: cache current size:0
>>> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
>>
>> xl dmesg
>>> (d9) HVM Loader
>>> (d9) Detected Xen v4.5.0-rc
>>> (d9) Xenbus rings @0xfeffc000, event channel 1
>>> (d9) System requested SeaBIOS
>>> (d9) CPU speed is 2660 MHz
>>> (d9) Relocating guest memory for lowmem MMIO space disabled
>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
>>> (d9) PCI-ISA link 0 routed to IRQ5
>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
>>> (d9) PCI-ISA link 1 routed to IRQ10
>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
>>> (d9) PCI-ISA link 2 routed to IRQ11
>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
>>> (d9) PCI-ISA link 3 routed to IRQ5
>>> (d9) pci dev 01:3 INTA->IRQ10
>>> (d9) pci dev 02:0 INTA->IRQ11
>>> (d9) pci dev 03:0 INTA->IRQ5
>>> (d9) pci dev 04:0 INTA->IRQ5
>>> (d9) pci dev 05:0 INTA->IRQ10
>>> (d9) pci dev 06:0 INTA->IRQ11
>>> (d9) pci dev 1d:0 INTA->IRQ10
>>> (d9) pci dev 1d:1 INTB->IRQ11
>>> (d9) pci dev 1d:2 INTC->IRQ5
>>> (d9) pci dev 1d:7 INTD->IRQ5
>>> (d9) No RAM in high memory; setting high_mem resource base to 100000000
>>> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
>>> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
>>> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
>>> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
>>> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>> (d9) Multiprocessor initialisation:
>>> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>>> done.
>>> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>>> done.
>>> (d9) Testing HVM environment:
>>> (d9)  - REP INSB across page boundaries ... passed
>>> (d9)  - GS base MSRs and SWAPGS ... passed
>>> (d9) Passed 2 of 2 tests
>>> (d9) Writing SMBIOS tables ...
>>> (d9) Loading SeaBIOS ...
>>> (d9) Creating MP tables ...
>>> (d9) Loading ACPI ...
>>> (d9) S3 disabled
>>> (d9) S4 disabled
>>> (d9) vm86 TSS at fc00a100
>>> (d9) BIOS map:
>>> (d9)  10000-100d3: Scratch space
>>> (d9)  c0000-fffff: Main BIOS
>>> (d9) E820 table:
>>> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
>>> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>> (d9) Invoking SeaBIOS ...
>>> (d9) SeaBIOS (version 
>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>> (d9)
>>> (d9) Found Xen hypervisor signature at 40000000
>>> (d9) Running on QEMU (i440fx)
>>> (d9) xen: copy e820...
>>> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>> (d9) CPU Mhz=2660
>>> (d9) Found 13 PCI devices (max PCI bus is 00)
>>> (d9) Allocated Xen hypercall page at 77fff000
>>> (d9) Detected Xen v4.5.0-rc
>>> (d9) xen: copy BIOS tables...
>>> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
>>> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>> (d9) Using pmtimer, ioport 0xb008
>>> (d9) Scan for VGA option rom
>>> (d9) Running option rom at c000:0003
>>> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
>>> (d9) pmm call arg1=0
>>> (d9) Turning on vga text mode console
>>> (d9) SeaBIOS (version 
>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
>>> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
>>> (d9) Found 0 lpt ports
>>> (d9) Found 0 serial ports
>>> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
>>> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>> (d9) UHCI init on dev 00:1d.0 (io=c240)
>>> (d9) UHCI init on dev 00:1d.1 (io=c260)
>>> (d9) UHCI init on dev 00:1d.2 (io=c280)
>>> (d9) PS2 keyboard initialized
>>> (d9) All threads complete.
>>> (d9) Scan for option roms
>>> (d9) Running option rom at c980:0003
>>> (d9) pmm call arg1=1
>>> (d9) pmm call arg1=0
>>> (d9) pmm call arg1=1
>>> (d9) pmm call arg1=0
>>> (d9) Searching bootorder for: /pci@i0cf8/*@6
>>> (d9)
>>> (d9) Press F12 for boot menu.
>>> (d9)
>>> (d9) Searching bootorder for: HALT
>>> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba 
>>> LCHS=1024/255/63 s=20480000
>>> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
>>> (d9) Returned 258048 bytes of ZoneHigh
>>> (d9) e820 map has 6 items:
>>> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>>> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>>> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>>> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
>>> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
>>> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
>>> (d9) enter handle_19:
>>> (d9)   NULL
>>> (d9) Booting from Hard Disk...
>>> (d9) Booting from 0000:7c00
>>> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
>>
>> domU's xl cfg:
>>> name='FEDORA'
>>> builder="hvm"
>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>> memory=2048
>>> vcpus=2
>>> acpi_s3=0
>>> acpi_s4=0
>>> vif=['bridge=xenbr0']
>>> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
>>> boot='dc'
>>> device_model_version='qemu-xen'
>>> vnc=0
>>> keymap="it"
>>> vga="qxl"
>>> spice=1
>>> spicehost='0.0.0.0'
>>> spiceport=6005
>>> spicedisable_ticketing=1
>>> spicevdagent=1
>>> spice_clipboard_sharing=0
>>> spiceusbredirection=4
>>> soundhw="hda"
>>
>> I tested also with stdvga instead of qxl vga but qemu crash always on 
>> fedora boot with same error.
>>
>> If you need more informations/tests tell me and I'll post them.
>>
>> Thanks for any reply and sorry for my bad english.
>>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:05:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:05:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr6oq-00082r-3I; Wed, 19 Nov 2014 15:05:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr6on-00082m-Nr
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 15:05:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	20/8F-09936-DA1BC645; Wed, 19 Nov 2014 15:05:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416409515!6627835!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17946 invoked from network); 19 Nov 2014 15:05:16 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 15:05:16 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJF52oZ027528
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 15:05:03 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJF517g011978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 15:05:02 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJF50of004457; Wed, 19 Nov 2014 15:05:01 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 07:05:00 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3D8DE11800A; Wed, 19 Nov 2014 10:04:59 -0500 (EST)
Date: Wed, 19 Nov 2014 10:04:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141119150459.GA15417@laptop.dumpdata.com>
References: <1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<20141118205633.GB6540@laptop.dumpdata.com>
	<348130555.20141118231254@eikelenboom.it>
	<20141119015541.GA10307@laptop.dumpdata.com>
	<996703854.20141119121644@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <996703854.20141119121644@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 12:16:44PM +0100, Sander Eikelenboom wrote:
> 
> Wednesday, November 19, 2014, 2:55:41 AM, you wrote:
> 
> > On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
> >> 
> >> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
> >> 
> >> >> 
> >> >> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
> >> >> about them .. however looking at the earlier reports these lines were also in 
> >> >> those reports).
> >> >> 
> >> >> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
> >> >> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
> >> >> and had a new default seabios config. (just to rule out anything stale in my tree)
> >> >> 
> >> >> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
> >> >> seabios config) are not the most recent (they don't get updated automatically 
> >> >> when you just do a git pull on the main tree) ?
> >> >> 
> >> >> In /tools/firmware/seabios-dir/.config i have:
> >> >> CONFIG_USB=y
> >> >> CONFIG_USB_UHCI=y
> >> >> CONFIG_USB_OHCI=y
> >> >> CONFIG_USB_EHCI=y
> >> >> CONFIG_USB_XHCI=y
> >> >> CONFIG_USB_MSC=y
> >> >> CONFIG_USB_UAS=y
> >> >> CONFIG_USB_HUB=y
> >> >> CONFIG_USB_KEYBOARD=y
> >> >> CONFIG_USB_MOUSE=y
> >> >> 
> >> 
> >> > I seem to have the same thing. Perhaps it is my XHCI controller being wonky.
> >> 
> >> >> And this is all just from a:
> >> >> - git clone git://xenbits.xen.org/xen.git -b staging
> >> >> - make clean && ./configure && make -j6 && make -j6 install
> >> 
> >> > Aye. 
> >> > .. snip..
> >> >> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
> >> >> >     [But this might be invalid as the addition of the ffff8303faaf25a8
> >> >> >      might be correct - as the second dpci the softirq is processing
> >> >> >      could be the MSI one]
> >> >> 
> >> >> Would there be an easy way to stress test this function separately in some 
> >> >> debugging function to see if it indeed is returning unexpected values ?
> >> 
> >> > Sadly no. But you got me looking in the right direction when you mentioned
> >> > 'timeout'.
> >> >> 
> >> >> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
> >> >> 
> >> >> Just curious, have you also tested the patches on AMD hardware ?
> >> 
> >> > Yes. To reproduce this the first thing I did was to get an AMD box.
> >> 
> >> >> 
> >> >>  
> >> >> >> When i look at the combination of (2) and (3), It seems it could be an 
> >> >> >> interaction between the two passed through devices and/or different IRQ types.
> >> >> 
> >> >> > Could be - as in it is causing this issue to show up faster than
> >> >> > expected. Or it is the one that triggers more than one dpci happening
> >> >> > at the same time.
> >> >> 
> >> >> Well that didn't seem to be it (see separate amendment i mailed previously)
> >> 
> >> > Right, the current theory I've is that the interrupts are not being
> >> > Acked within 8 milisecond and we reset the 'state' - and at the same
> >> > time we get an interrupt and schedule it - while we are still processing
> >> > the same interrupt. This would explain why the 'test_and_clear_bit'
> >> > got the wrong value.
> >> 
> >> > In regards to the list poison - following this thread of logic - with
> >> > the 'state = 0' set we open the floodgates for any CPU to put the same
> >> > 'struct hvm_pirq_dpci' on its list.
> >> 
> >> > We do reset the 'state' on _every_ GSI that is mapped to a guest - so
> >> > we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:
> >> 
> >> > CPUX:                           CPUY:
> >> > pt_irq_time_out:
> >> > state = 0;                      
> >> > [out of timer coder, the                raise_softirq
> >> >  pirq_dpci is on the dpci_list]         [adds the pirq_dpci as state == 0]
> >> 
> >> > softirq_dpci                            softirq_dpci:
> >> >         list_del
> >> >         [entries poison]
> >> >                                                 list_del <= BOOM
> >> >                         
> >> > Is what I believe is happening.
> >> 
> >> > The INTX device - once I put a load on it - does not trigger
> >> > any pt_irq_time_out, so that would explain why I cannot hit this.
> >> 
> >> > But I believe your card hits these "hiccups".   
> >> 
> >> 
> >> Hi Konrad,
> >> 
> >> I just tested you 5 patches and as a result i still got an(other) host crash:
> >> (complete serial log attached)
> >> 
> >> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> >> (XEN) [2014-11-18 21:55:41.591] CPU:    0
> >> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> >> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08012c7e7>]CPU:    2
> >> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
> >> (XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010006    _spin_unlock+0x1f/0x30CONTEXT: hypervisor
> 
> > Duh!
> 
> > Here is another patch on top of the five you have (attached and inline).
> 
> Hi Konrad,
> 
> Happy to report it has been running with this additional patch for 2 hours now 
> without any problems. I think you nailed it :-)

Could you also do an 'xl debug-keys k' and send that please?

> More than happy to test the definitive patch as well.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:05:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:05:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr6oq-00082r-3I; Wed, 19 Nov 2014 15:05:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr6on-00082m-Nr
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 15:05:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	20/8F-09936-DA1BC645; Wed, 19 Nov 2014 15:05:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416409515!6627835!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17946 invoked from network); 19 Nov 2014 15:05:16 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 15:05:16 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJF52oZ027528
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 15:05:03 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJF517g011978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 15:05:02 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJF50of004457; Wed, 19 Nov 2014 15:05:01 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 07:05:00 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3D8DE11800A; Wed, 19 Nov 2014 10:04:59 -0500 (EST)
Date: Wed, 19 Nov 2014 10:04:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141119150459.GA15417@laptop.dumpdata.com>
References: <1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<20141118205633.GB6540@laptop.dumpdata.com>
	<348130555.20141118231254@eikelenboom.it>
	<20141119015541.GA10307@laptop.dumpdata.com>
	<996703854.20141119121644@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <996703854.20141119121644@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 12:16:44PM +0100, Sander Eikelenboom wrote:
> 
> Wednesday, November 19, 2014, 2:55:41 AM, you wrote:
> 
> > On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
> >> 
> >> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
> >> 
> >> >> 
> >> >> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
> >> >> about them .. however looking at the earlier reports these lines were also in 
> >> >> those reports).
> >> >> 
> >> >> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
> >> >> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
> >> >> and had a new default seabios config. (just to rule out anything stale in my tree)
> >> >> 
> >> >> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
> >> >> seabios config) are not the most recent (they don't get updated automatically 
> >> >> when you just do a git pull on the main tree) ?
> >> >> 
> >> >> In /tools/firmware/seabios-dir/.config i have:
> >> >> CONFIG_USB=y
> >> >> CONFIG_USB_UHCI=y
> >> >> CONFIG_USB_OHCI=y
> >> >> CONFIG_USB_EHCI=y
> >> >> CONFIG_USB_XHCI=y
> >> >> CONFIG_USB_MSC=y
> >> >> CONFIG_USB_UAS=y
> >> >> CONFIG_USB_HUB=y
> >> >> CONFIG_USB_KEYBOARD=y
> >> >> CONFIG_USB_MOUSE=y
> >> >> 
> >> 
> >> > I seem to have the same thing. Perhaps it is my XHCI controller being wonky.
> >> 
> >> >> And this is all just from a:
> >> >> - git clone git://xenbits.xen.org/xen.git -b staging
> >> >> - make clean && ./configure && make -j6 && make -j6 install
> >> 
> >> > Aye. 
> >> > .. snip..
> >> >> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
> >> >> >     [But this might be invalid as the addition of the ffff8303faaf25a8
> >> >> >      might be correct - as the second dpci the softirq is processing
> >> >> >      could be the MSI one]
> >> >> 
> >> >> Would there be an easy way to stress test this function separately in some 
> >> >> debugging function to see if it indeed is returning unexpected values ?
> >> 
> >> > Sadly no. But you got me looking in the right direction when you mentioned
> >> > 'timeout'.
> >> >> 
> >> >> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
> >> >> 
> >> >> Just curious, have you also tested the patches on AMD hardware ?
> >> 
> >> > Yes. To reproduce this the first thing I did was to get an AMD box.
> >> 
> >> >> 
> >> >>  
> >> >> >> When i look at the combination of (2) and (3), It seems it could be an 
> >> >> >> interaction between the two passed through devices and/or different IRQ types.
> >> >> 
> >> >> > Could be - as in it is causing this issue to show up faster than
> >> >> > expected. Or it is the one that triggers more than one dpci happening
> >> >> > at the same time.
> >> >> 
> >> >> Well that didn't seem to be it (see separate amendment i mailed previously)
> >> 
> >> > Right, the current theory I've is that the interrupts are not being
> >> > Acked within 8 milisecond and we reset the 'state' - and at the same
> >> > time we get an interrupt and schedule it - while we are still processing
> >> > the same interrupt. This would explain why the 'test_and_clear_bit'
> >> > got the wrong value.
> >> 
> >> > In regards to the list poison - following this thread of logic - with
> >> > the 'state = 0' set we open the floodgates for any CPU to put the same
> >> > 'struct hvm_pirq_dpci' on its list.
> >> 
> >> > We do reset the 'state' on _every_ GSI that is mapped to a guest - so
> >> > we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:
> >> 
> >> > CPUX:                           CPUY:
> >> > pt_irq_time_out:
> >> > state = 0;                      
> >> > [out of timer coder, the                raise_softirq
> >> >  pirq_dpci is on the dpci_list]         [adds the pirq_dpci as state == 0]
> >> 
> >> > softirq_dpci                            softirq_dpci:
> >> >         list_del
> >> >         [entries poison]
> >> >                                                 list_del <= BOOM
> >> >                         
> >> > Is what I believe is happening.
> >> 
> >> > The INTX device - once I put a load on it - does not trigger
> >> > any pt_irq_time_out, so that would explain why I cannot hit this.
> >> 
> >> > But I believe your card hits these "hiccups".   
> >> 
> >> 
> >> Hi Konrad,
> >> 
> >> I just tested you 5 patches and as a result i still got an(other) host crash:
> >> (complete serial log attached)
> >> 
> >> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> >> (XEN) [2014-11-18 21:55:41.591] CPU:    0
> >> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> >> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08012c7e7>]CPU:    2
> >> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
> >> (XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010006    _spin_unlock+0x1f/0x30CONTEXT: hypervisor
> 
> > Duh!
> 
> > Here is another patch on top of the five you have (attached and inline).
> 
> Hi Konrad,
> 
> Happy to report it has been running with this additional patch for 2 hours now 
> without any problems. I think you nailed it :-)

Could you also do an 'xl debug-keys k' and send that please?

> More than happy to test the definitive patch as well.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:12:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:12:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr6vY-0008Fw-UJ; Wed, 19 Nov 2014 15:12:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1Xr6vX-0008Fr-7C
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:12:15 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	52/4D-19763-E43BC645; Wed, 19 Nov 2014 15:12:14 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416409932!12274487!1
X-Originating-IP: [209.85.216.42]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11764 invoked from network); 19 Nov 2014 15:12:13 -0000
Received: from mail-qa0-f42.google.com (HELO mail-qa0-f42.google.com)
	(209.85.216.42)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:12:13 -0000
Received: by mail-qa0-f42.google.com with SMTP id j7so518012qaq.1
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 07:12:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=TjMIqcBE0wtv9EiNaMzdPZKVdzwQZF3YZZoBU/S9n8s=;
	b=HTkoTK+Z9MgUGc2HTQzBpkfVlutspD0dbO7mKF69wspqPM9htDeGtmWc3CMv10g4Cb
	5NILS/3j6FlD4nxczKMv4apprXI0RT06GbVzLCyz3S67JYQiv+WYbI5W02Hjj8a0sITR
	+WgMFdKnCKc/g5AkVAE/QOHH2BsC/J4sbYLBtndv6HDxyf5EmoPWBlBD9RI2ZXbcG0Z1
	l0C6cTGU0OZ94QuMMfBr9R/rfPWP4NN/vHDh2TzHfoZumeL/tLIxkQCoGvVn48SdSpG6
	DLDTlbAtT/x0D+5+4WQ0RGxfBiqJx1/CzynfLh9DdvIySzVcqaFKY031APwSV8iP20dz
	W+NQ==
X-Received: by 10.229.248.132 with SMTP id mg4mr14015505qcb.29.1416409932493; 
	Wed, 19 Nov 2014 07:12:12 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.99])
	by mx.google.com with ESMTPSA id x17sm1591530qae.11.2014.11.19.07.12.10
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Wed, 19 Nov 2014 07:12:11 -0800 (PST)
Date: Wed, 19 Nov 2014 12:12:09 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <6916092.20141119121209@gmail.com>
To: "Jan Beulich" <JBeulich@suse.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <546B86990200007800048DBF@mail.emea.novell.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
	<546B86990200007800048DBF@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Hello Jan and Konrad,

Tuesday, November 18, 2014, 1:49:13 PM, you wrote:

>>
>> I've just checked this with lspci. I see that the IO is being enabled.

> Memory you mean.

Yes. Sorry.

>> Any   other   idea   on   why I might be reading back 0xff for all PCI
>> memory area reads? The lspci output follows.

> Since this isn't behind a bridge - no, not really. Did you try this with
> any other device for comparison purposes?

This   is  getting  more  interesting.  It  seems  that  something  is
overwriting the pci-back configuration data.

Starting  from a fresh reboot I checked the Dom0 pci configuration and
got this:

root@smartin-xen:~# lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00

I then start/stop my DomU and checked the Dom0 pci configuration again
and got this:

root@smartin-xen:~# lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
10: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00

Inside  my  DomU I added code to print the PCI configuration registers
and what I get after restarting the DomU is:

(d18) 14:57:04.042 src/e1000e.c@00150: 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
(d18) 14:57:04.042 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
(d18) 14:57:04.042 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
(d18) 14:57:04.043 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
(d18) 14:57:04.043 src/e1000e.c@00324: Enable PCI Memory Access
(d18) 14:57:05.043 src/e1000e.c@00150: 00: 86 80 59 15 03 00 10 00 04 00 00 02 00 00 00 00
(d18) 14:57:05.044 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
(d18) 14:57:05.044 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
(d18) 14:57:05.045 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00

As  you can see the pci configuration read from the pci-back driver by
my DomU is different to the data in the Dom0 pci configuration!

Just  before  leaving my DomU I disable the pci memory access and this
is what I see

(d18) 15:01:02.051 src/e1000e.c@00150: 00: 86 80 59 15 03 00 10 00 04 00 00 02 00 00 00 00
(d18) 15:01:02.051 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
(d18) 15:01:02.051 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
(d18) 15:01:02.052 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
(d18) 15:01:02.052 src/e1000e.c@00541: Disable PCI Memory Access
(d18) 15:01:02.052 src/e1000e.c@00150: 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
(d18) 15:01:02.052 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
(d18) 15:01:02.052 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
(d18) 15:01:02.053 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00

As  you  can  see the data is consistent with just writing 0000 to the
pci control register.

This is the output from the debug version of the xen-pciback module.

[ 5429.351231] pciback 0000:00:19.0: enabling device (0000 -> 0003)
[ 5429.351367] xen: registering gsi 20 triggering 0 polarity 1
[ 5429.351373] Already setup the GSI :20
[ 5429.351387] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 on  disable-> enable
[ 5429.351436] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 on  enabled
[ 5434.360078] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 off  enable-> disable
[ 5434.360116] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #0 off  disabled
[ 5434.361491] xen-pciback pci-20-0: fe state changed 5
[ 5434.362473] xen-pciback pci-20-0: fe state changed 6
[ 5434.363540] xen-pciback pci-20-0: fe state changed 0
[ 5434.363544] xen-pciback pci-20-0: frontend is gone! unregister device
[ 5434.467359] pciback 0000:00:19.0: resetting virtual configuration space
[ 5434.467376] pciback 0000:00:19.0: free-ing dynamically allocated virtual configuration space fields

Does this make any sense to you?

-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:12:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:12:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr6vY-0008Fw-UJ; Wed, 19 Nov 2014 15:12:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1Xr6vX-0008Fr-7C
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:12:15 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	52/4D-19763-E43BC645; Wed, 19 Nov 2014 15:12:14 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416409932!12274487!1
X-Originating-IP: [209.85.216.42]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11764 invoked from network); 19 Nov 2014 15:12:13 -0000
Received: from mail-qa0-f42.google.com (HELO mail-qa0-f42.google.com)
	(209.85.216.42)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:12:13 -0000
Received: by mail-qa0-f42.google.com with SMTP id j7so518012qaq.1
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 07:12:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=TjMIqcBE0wtv9EiNaMzdPZKVdzwQZF3YZZoBU/S9n8s=;
	b=HTkoTK+Z9MgUGc2HTQzBpkfVlutspD0dbO7mKF69wspqPM9htDeGtmWc3CMv10g4Cb
	5NILS/3j6FlD4nxczKMv4apprXI0RT06GbVzLCyz3S67JYQiv+WYbI5W02Hjj8a0sITR
	+WgMFdKnCKc/g5AkVAE/QOHH2BsC/J4sbYLBtndv6HDxyf5EmoPWBlBD9RI2ZXbcG0Z1
	l0C6cTGU0OZ94QuMMfBr9R/rfPWP4NN/vHDh2TzHfoZumeL/tLIxkQCoGvVn48SdSpG6
	DLDTlbAtT/x0D+5+4WQ0RGxfBiqJx1/CzynfLh9DdvIySzVcqaFKY031APwSV8iP20dz
	W+NQ==
X-Received: by 10.229.248.132 with SMTP id mg4mr14015505qcb.29.1416409932493; 
	Wed, 19 Nov 2014 07:12:12 -0800 (PST)
Received: from smartin-envy.nemo.cl ([181.202.132.99])
	by mx.google.com with ESMTPSA id x17sm1591530qae.11.2014.11.19.07.12.10
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Wed, 19 Nov 2014 07:12:11 -0800 (PST)
Date: Wed, 19 Nov 2014 12:12:09 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <6916092.20141119121209@gmail.com>
To: "Jan Beulich" <JBeulich@suse.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <546B86990200007800048DBF@mail.emea.novell.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
	<546B86990200007800048DBF@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Hello Jan and Konrad,

Tuesday, November 18, 2014, 1:49:13 PM, you wrote:

>>
>> I've just checked this with lspci. I see that the IO is being enabled.

> Memory you mean.

Yes. Sorry.

>> Any   other   idea   on   why I might be reading back 0xff for all PCI
>> memory area reads? The lspci output follows.

> Since this isn't behind a bridge - no, not really. Did you try this with
> any other device for comparison purposes?

This   is  getting  more  interesting.  It  seems  that  something  is
overwriting the pci-back configuration data.

Starting  from a fresh reboot I checked the Dom0 pci configuration and
got this:

root@smartin-xen:~# lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00

I then start/stop my DomU and checked the Dom0 pci configuration again
and got this:

root@smartin-xen:~# lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
10: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00

Inside  my  DomU I added code to print the PCI configuration registers
and what I get after restarting the DomU is:

(d18) 14:57:04.042 src/e1000e.c@00150: 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
(d18) 14:57:04.042 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
(d18) 14:57:04.042 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
(d18) 14:57:04.043 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
(d18) 14:57:04.043 src/e1000e.c@00324: Enable PCI Memory Access
(d18) 14:57:05.043 src/e1000e.c@00150: 00: 86 80 59 15 03 00 10 00 04 00 00 02 00 00 00 00
(d18) 14:57:05.044 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
(d18) 14:57:05.044 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
(d18) 14:57:05.045 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00

As  you can see the pci configuration read from the pci-back driver by
my DomU is different to the data in the Dom0 pci configuration!

Just  before  leaving my DomU I disable the pci memory access and this
is what I see

(d18) 15:01:02.051 src/e1000e.c@00150: 00: 86 80 59 15 03 00 10 00 04 00 00 02 00 00 00 00
(d18) 15:01:02.051 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
(d18) 15:01:02.051 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
(d18) 15:01:02.052 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
(d18) 15:01:02.052 src/e1000e.c@00541: Disable PCI Memory Access
(d18) 15:01:02.052 src/e1000e.c@00150: 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
(d18) 15:01:02.052 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
(d18) 15:01:02.052 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
(d18) 15:01:02.053 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00

As  you  can  see the data is consistent with just writing 0000 to the
pci control register.

This is the output from the debug version of the xen-pciback module.

[ 5429.351231] pciback 0000:00:19.0: enabling device (0000 -> 0003)
[ 5429.351367] xen: registering gsi 20 triggering 0 polarity 1
[ 5429.351373] Already setup the GSI :20
[ 5429.351387] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 on  disable-> enable
[ 5429.351436] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 on  enabled
[ 5434.360078] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 off  enable-> disable
[ 5434.360116] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #0 off  disabled
[ 5434.361491] xen-pciback pci-20-0: fe state changed 5
[ 5434.362473] xen-pciback pci-20-0: fe state changed 6
[ 5434.363540] xen-pciback pci-20-0: fe state changed 0
[ 5434.363544] xen-pciback pci-20-0: frontend is gone! unregister device
[ 5434.467359] pciback 0000:00:19.0: resetting virtual configuration space
[ 5434.467376] pciback 0000:00:19.0: free-ing dynamically allocated virtual configuration space fields

Does this make any sense to you?

-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:28:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:28:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Ak-0008UE-QB; Wed, 19 Nov 2014 15:27:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7Ai-0008U9-SB
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:27:56 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	D1/8B-22737-BF6BC645; Wed, 19 Nov 2014 15:27:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416410871!9402269!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14553 invoked from network); 19 Nov 2014 15:27:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:27:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194425414"
Message-ID: <1416410868.29243.39.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:27:48 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH 0/5 v2 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These patches:

      * fix up an off by one bug in the xgene mapping of additional PCI
        bus resources, which would cause an additional extra page to be
        mapped
      * correct the size of the mapped regions to match the docs
      * adds support for the other 4 PCI buses on the chip, which
        enables mcdivitt and presumably most other Xgene based platforms
        which uses PCI buses other than pcie0.
      * adds earlyprintk for the mcdivitt platform

They can also be found at:
        git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v2

McDivitt is the X-Gene based HP Moonshot cartridge (McDivitt is the code
name, I think the product is called m400, not quite sure).

Other than the bug fixes I'd like to see the mcdivitt support
(specifically the "other 4 PCI buses" one) in 4.5 because Moonshot is an
interesting and exciting platform for arm64. It is also being used for
ongoing work on Xen on ARM on Openstack in Linaro. The earlyprintk patch
is totally harmless unless it's explicitly enabled at compile time, IMHO
if we are taking the rest we may as well throw it in...

The risk here is that we break the existing support for the Mustang
platform, which would be the most likely failure case for the second
patch. I've tested these on a Mustang, including firing up a PCI NIC
device. The new mappings are a superset of the existing ones so the
potential for breakage should be quite small.

I've also successfully tested on a McDivitt.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:28:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:28:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Ag-0008U2-ET; Wed, 19 Nov 2014 15:27:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr7Ae-0008Tx-HV
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:27:52 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	21/31-26740-7F6BC645; Wed, 19 Nov 2014 15:27:51 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416410868!10038839!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3410 invoked from network); 19 Nov 2014 15:27:50 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 15:27:50 -0000
Received: from mail-qg0-f46.google.com ([209.85.192.46]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGy29NpOuYDGifBnu2ltzb7RPZQDbFbA@postini.com;
	Wed, 19 Nov 2014 07:27:50 PST
Received: by mail-qg0-f46.google.com with SMTP id i50so559665qgf.19
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 07:27:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Gh2Vic6S/qZo0q4aG+iICXNiDPOaVhfoD9yhfAyaMD0=;
	b=f3wzwGRf9lEbl2+aB1EWXZYGN+UKUmTefkJ0wc+pGVpskZ4idMIvHaMoO35SDeBAgn
	dGiv4ZTc31oZ/xG4o4N5wvHkBmixkQLZVU6Vp5/Zzv4dzJX+EIjxpWHi2/Wdor3uD6VT
	x3oPzvBTMuMyb/k9AypddsIBciDLZws8JLGCQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Gh2Vic6S/qZo0q4aG+iICXNiDPOaVhfoD9yhfAyaMD0=;
	b=I9kJxYdhUgROAXKOO3Lf0/tQ3Ws/wPAQe6c31EBlL71Sug6+ULf8MTYeZP/pZYNqL/
	+29v5pt5yIjHC8dDEkg0SVb2I0BBFa2QVXUTkqPsNepFY619LsHDAKw8YaJSFeS9my4p
	QGuKv9aD9Q7OlUpiJ9SmYn1exNLHB8htWHtdECH12szMsJZgIpnTZ0le9IANKlKnlGrv
	FfkW5GVHocGO3rte/btbzyvGxl32Y3ohWuU66OVqNj8WXnT7y32oiy4vwaV5Fomi7pb7
	/h49xPxNTyzGJWohaYRNXM7+QPmj6ujeGZXYwF7ln4v/IgrudI7cKi6xpGmKXLJ1/Mh5
	TMsQ==
X-Gm-Message-State: ALoCoQmdQJL5tVtkGX6vuvdkoDNTEzxez+yqXtTKD1COnTSBp7BRBfUuL7vfmd6MoPdS/iiDiWe84WhOoawBaOSKzLPxLKba+Cd2h1YTTQDQe3upvrQmYCLd5gSWobmP9b3JZ/AvS3lwj3ExUbPDZBgNxeusGAMZ/Q==
X-Received: by 10.229.196.70 with SMTP id ef6mr22449357qcb.31.1416410867854;
	Wed, 19 Nov 2014 07:27:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.229.196.70 with SMTP id ef6mr22449344qcb.31.1416410867734;
	Wed, 19 Nov 2014 07:27:47 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 07:27:47 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 17:27:47 +0200
Message-ID: <CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,



On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> > >      else
>> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> > >
>> > >  }
>> >
>> > Yes, exactly
>>
>> I tried, hang still occurs with this change
>
> We need to figure out why during the hang you still have all the LRs
> busy even if you are getting maintenance interrupts that should cause
> them to be cleared.
>

I see that I have free LRs during maintenance interrupt

(XEN) gic.c:871:d0v0 maintenance interrupt
(XEN) GICH_LRs (vcpu 0) mask=0
(XEN)    HW_LR[0]=9a015856
(XEN)    HW_LR[1]=0
(XEN)    HW_LR[2]=0
(XEN)    HW_LR[3]=0
(XEN) Inflight irq=86 lr=0
(XEN) Inflight irq=2 lr=255
(XEN) Pending irq=2

But I see that after I got hang - maintenance interrupts are generated
continuously. Platform continues printing the same log till reboot.


My diff is on top of 394b7e587b05d0f4a5fd6f067b38339ab5a77121

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b7516c0..1e0316a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
 /* Maximum cpu interface per GIC */
 #define NR_GIC_CPU_IF 8

-#undef GIC_DEBUG
+#define GIC_DEBUG 1

 static void gic_update_one_lr(struct vcpu *v, int i);

@@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void
*dev_id, struct cpu_user_regs *r
      * on return to guest that is going to clear the old LRs and inject
      * new interrupts.
      */
+    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
+    gic_dump_info(current);
 }

 void gic_dump_info(struct vcpu *v)


> Could you please call gic_dump_info(current) from maintenance_interrupt,
> and post the output during the hang? Remove the other gic_dump_info to
> avoid confusion, we want to understand what is the status of the LRs
> after clearing them upon receiving a maintenance interrupt at busy times.



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:28:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:28:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Ak-0008UE-QB; Wed, 19 Nov 2014 15:27:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7Ai-0008U9-SB
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:27:56 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	D1/8B-22737-BF6BC645; Wed, 19 Nov 2014 15:27:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416410871!9402269!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14553 invoked from network); 19 Nov 2014 15:27:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:27:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194425414"
Message-ID: <1416410868.29243.39.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:27:48 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH 0/5 v2 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These patches:

      * fix up an off by one bug in the xgene mapping of additional PCI
        bus resources, which would cause an additional extra page to be
        mapped
      * correct the size of the mapped regions to match the docs
      * adds support for the other 4 PCI buses on the chip, which
        enables mcdivitt and presumably most other Xgene based platforms
        which uses PCI buses other than pcie0.
      * adds earlyprintk for the mcdivitt platform

They can also be found at:
        git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v2

McDivitt is the X-Gene based HP Moonshot cartridge (McDivitt is the code
name, I think the product is called m400, not quite sure).

Other than the bug fixes I'd like to see the mcdivitt support
(specifically the "other 4 PCI buses" one) in 4.5 because Moonshot is an
interesting and exciting platform for arm64. It is also being used for
ongoing work on Xen on ARM on Openstack in Linaro. The earlyprintk patch
is totally harmless unless it's explicitly enabled at compile time, IMHO
if we are taking the rest we may as well throw it in...

The risk here is that we break the existing support for the Mustang
platform, which would be the most likely failure case for the second
patch. I've tested these on a Mustang, including firing up a PCI NIC
device. The new mappings are a superset of the existing ones so the
potential for breakage should be quite small.

I've also successfully tested on a McDivitt.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:28:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:28:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Ag-0008U2-ET; Wed, 19 Nov 2014 15:27:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr7Ae-0008Tx-HV
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:27:52 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	21/31-26740-7F6BC645; Wed, 19 Nov 2014 15:27:51 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416410868!10038839!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3410 invoked from network); 19 Nov 2014 15:27:50 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 15:27:50 -0000
Received: from mail-qg0-f46.google.com ([209.85.192.46]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGy29NpOuYDGifBnu2ltzb7RPZQDbFbA@postini.com;
	Wed, 19 Nov 2014 07:27:50 PST
Received: by mail-qg0-f46.google.com with SMTP id i50so559665qgf.19
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 07:27:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Gh2Vic6S/qZo0q4aG+iICXNiDPOaVhfoD9yhfAyaMD0=;
	b=f3wzwGRf9lEbl2+aB1EWXZYGN+UKUmTefkJ0wc+pGVpskZ4idMIvHaMoO35SDeBAgn
	dGiv4ZTc31oZ/xG4o4N5wvHkBmixkQLZVU6Vp5/Zzv4dzJX+EIjxpWHi2/Wdor3uD6VT
	x3oPzvBTMuMyb/k9AypddsIBciDLZws8JLGCQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Gh2Vic6S/qZo0q4aG+iICXNiDPOaVhfoD9yhfAyaMD0=;
	b=I9kJxYdhUgROAXKOO3Lf0/tQ3Ws/wPAQe6c31EBlL71Sug6+ULf8MTYeZP/pZYNqL/
	+29v5pt5yIjHC8dDEkg0SVb2I0BBFa2QVXUTkqPsNepFY619LsHDAKw8YaJSFeS9my4p
	QGuKv9aD9Q7OlUpiJ9SmYn1exNLHB8htWHtdECH12szMsJZgIpnTZ0le9IANKlKnlGrv
	FfkW5GVHocGO3rte/btbzyvGxl32Y3ohWuU66OVqNj8WXnT7y32oiy4vwaV5Fomi7pb7
	/h49xPxNTyzGJWohaYRNXM7+QPmj6ujeGZXYwF7ln4v/IgrudI7cKi6xpGmKXLJ1/Mh5
	TMsQ==
X-Gm-Message-State: ALoCoQmdQJL5tVtkGX6vuvdkoDNTEzxez+yqXtTKD1COnTSBp7BRBfUuL7vfmd6MoPdS/iiDiWe84WhOoawBaOSKzLPxLKba+Cd2h1YTTQDQe3upvrQmYCLd5gSWobmP9b3JZ/AvS3lwj3ExUbPDZBgNxeusGAMZ/Q==
X-Received: by 10.229.196.70 with SMTP id ef6mr22449357qcb.31.1416410867854;
	Wed, 19 Nov 2014 07:27:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.229.196.70 with SMTP id ef6mr22449344qcb.31.1416410867734;
	Wed, 19 Nov 2014 07:27:47 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 07:27:47 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181435300.27247@kaball.uk.xensource.com>
	<CAH_mUMPHTans97o2u5FbzZn14+5mdf2kHktcg_M=-2RDJeuL-g@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 17:27:47 +0200
Message-ID: <CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,



On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> > >      else
>> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> > >
>> > >  }
>> >
>> > Yes, exactly
>>
>> I tried, hang still occurs with this change
>
> We need to figure out why during the hang you still have all the LRs
> busy even if you are getting maintenance interrupts that should cause
> them to be cleared.
>

I see that I have free LRs during maintenance interrupt

(XEN) gic.c:871:d0v0 maintenance interrupt
(XEN) GICH_LRs (vcpu 0) mask=0
(XEN)    HW_LR[0]=9a015856
(XEN)    HW_LR[1]=0
(XEN)    HW_LR[2]=0
(XEN)    HW_LR[3]=0
(XEN) Inflight irq=86 lr=0
(XEN) Inflight irq=2 lr=255
(XEN) Pending irq=2

But I see that after I got hang - maintenance interrupts are generated
continuously. Platform continues printing the same log till reboot.


My diff is on top of 394b7e587b05d0f4a5fd6f067b38339ab5a77121

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b7516c0..1e0316a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
 /* Maximum cpu interface per GIC */
 #define NR_GIC_CPU_IF 8

-#undef GIC_DEBUG
+#define GIC_DEBUG 1

 static void gic_update_one_lr(struct vcpu *v, int i);

@@ -868,6 +868,8 @@ static void maintenance_interrupt(int irq, void
*dev_id, struct cpu_user_regs *r
      * on return to guest that is going to clear the old LRs and inject
      * new interrupts.
      */
+    gdprintk(XENLOG_DEBUG, "maintenance interrupt\n");
+    gic_dump_info(current);
 }

 void gic_dump_info(struct vcpu *v)


> Could you please call gic_dump_info(current) from maintenance_interrupt,
> and post the output during the hang? Remove the other gic_dump_info to
> avoid confusion, we want to understand what is the status of the LRs
> after clearing them upon receiving a maintenance interrupt at busy times.



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:28:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7BH-00006q-6o; Wed, 19 Nov 2014 15:28:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7BF-00006Z-PB
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:28:29 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	2B/62-02559-D17BC645; Wed, 19 Nov 2014 15:28:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416410905!13542396!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7483 invoked from network); 19 Nov 2014 15:28:28 -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;
	19 Nov 2014 15:28:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194425628"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:28:22 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xr7B7-00059a-1o;
	Wed, 19 Nov 2014 15:28:22 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Wed, 19 Nov
	2014 15:28:20 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:28:15 +0000
Message-ID: <1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH v2 for-4.5 5/5] xen: arm: Support the other 4
	PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only establish specific mappings for pcie0, which is
used on the Mustang platform. However at least McDivitt uses pcie3.
So wire up all the others, based on whether the corresponding DT node
is marked as available.

This results in no change for Mustang.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: - Didn't constify dt node pointer -- dt_find_compatible_node needs a
      non-const
    - Print a message when ignoring an unknown bus
    - Log with dt node full anme instead of CFG space address.
    - Log at start of xgene_storm_pcie_specific_mapping instead of in the
      caller after the fact.
---
 xen/arch/arm/platforms/xgene-storm.c |   89 +++++++++++++++++++++++++++++-----
 1 file changed, 76 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 8c27f24..0b3492d 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -78,35 +78,35 @@ static int map_one_spi(struct domain *d, const char *what,
     return ret;
 }
 
-/*
- * Xen does not currently support mapping MMIO regions and interrupt
- * for bus child devices (referenced via the "ranges" and
- * "interrupt-map" properties to domain 0). Instead for now map the
- * necessary resources manually.
- */
-static int xgene_storm_specific_mapping(struct domain *d)
+/* Creates MMIO mappings base..end as well as 4 SPIs from the given base. */
+static int xgene_storm_pcie_specific_mapping(struct domain *d,
+                                             const struct dt_device_node *node,
+                                             paddr_t base, paddr_t end,
+                                             int base_spi)
 {
     int ret;
 
+    printk("Mapping additional regions for PCIe device %s\n",
+           dt_node_full_name(node));
+
     /* Map the PCIe bus resources */
-    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
-                                        paddr_to_pfn(0x01000000000UL));
+    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(base), paddr_to_pfn(end));
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTA", 0xc2, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTA", base_spi+0, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTB", 0xc3, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTB", base_spi+1, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTC", 0xc4, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTC", base_spi+2, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTD", 0xc5, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTD", base_spi+3, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
@@ -115,6 +115,69 @@ err:
     return ret;
 }
 
+/*
+ * Xen does not currently support mapping MMIO regions and interrupt
+ * for bus child devices (referenced via the "ranges" and
+ * "interrupt-map" properties to domain 0). Instead for now map the
+ * necessary resources manually.
+ */
+static int xgene_storm_specific_mapping(struct domain *d)
+{
+    struct dt_device_node *node = NULL;
+    int ret;
+
+    while ( (node = dt_find_compatible_node(node, "pci", "apm,xgene-pcie")) )
+    {
+        u64 addr;
+
+        /* Identify the bus via it's control register address */
+        ret = dt_device_get_address(node, 0, &addr, NULL);
+        if ( ret < 0 )
+            return ret;
+
+        if ( !dt_device_is_available(node) )
+            continue;
+
+       switch ( addr )
+        {
+        case 0x1f2b0000: /* PCIe0 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                node,
+                0x0e000000000UL, 0x10000000000UL, 0xc2);
+            break;
+        case 0x1f2c0000: /* PCIe1 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                node,
+                0x0d000000000UL, 0x0e000000000UL, 0xc8);
+            break;
+        case 0x1f2d0000: /* PCIe2 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                node,
+                0x09000000000UL, 0x0a000000000UL, 0xce);
+            break;
+        case 0x1f500000: /* PCIe3 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                node,
+                0x0a000000000UL, 0x0c000000000UL, 0xd4);
+            break;
+        case 0x1f510000: /* PCIe4 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                node,
+                0x0c000000000UL, 0x0d000000000UL, 0xda);
+            break;
+
+        default:
+            printk("Ignoring unknown PCI bus %s\n", dt_node_full_name(node));
+            continue;
+        }
+
+        if ( ret < 0 )
+            return ret;
+    }
+
+    return 0;
+}
+
 static void xgene_storm_reset(void)
 {
     void __iomem *addr;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:28:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7BH-00006q-6o; Wed, 19 Nov 2014 15:28:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7BF-00006Z-PB
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:28:29 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	2B/62-02559-D17BC645; Wed, 19 Nov 2014 15:28:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416410905!13542396!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7483 invoked from network); 19 Nov 2014 15:28:28 -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;
	19 Nov 2014 15:28:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194425628"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:28:22 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xr7B7-00059a-1o;
	Wed, 19 Nov 2014 15:28:22 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Wed, 19 Nov
	2014 15:28:20 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:28:15 +0000
Message-ID: <1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH v2 for-4.5 5/5] xen: arm: Support the other 4
	PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only establish specific mappings for pcie0, which is
used on the Mustang platform. However at least McDivitt uses pcie3.
So wire up all the others, based on whether the corresponding DT node
is marked as available.

This results in no change for Mustang.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: - Didn't constify dt node pointer -- dt_find_compatible_node needs a
      non-const
    - Print a message when ignoring an unknown bus
    - Log with dt node full anme instead of CFG space address.
    - Log at start of xgene_storm_pcie_specific_mapping instead of in the
      caller after the fact.
---
 xen/arch/arm/platforms/xgene-storm.c |   89 +++++++++++++++++++++++++++++-----
 1 file changed, 76 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 8c27f24..0b3492d 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -78,35 +78,35 @@ static int map_one_spi(struct domain *d, const char *what,
     return ret;
 }
 
-/*
- * Xen does not currently support mapping MMIO regions and interrupt
- * for bus child devices (referenced via the "ranges" and
- * "interrupt-map" properties to domain 0). Instead for now map the
- * necessary resources manually.
- */
-static int xgene_storm_specific_mapping(struct domain *d)
+/* Creates MMIO mappings base..end as well as 4 SPIs from the given base. */
+static int xgene_storm_pcie_specific_mapping(struct domain *d,
+                                             const struct dt_device_node *node,
+                                             paddr_t base, paddr_t end,
+                                             int base_spi)
 {
     int ret;
 
+    printk("Mapping additional regions for PCIe device %s\n",
+           dt_node_full_name(node));
+
     /* Map the PCIe bus resources */
-    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
-                                        paddr_to_pfn(0x01000000000UL));
+    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(base), paddr_to_pfn(end));
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTA", 0xc2, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTA", base_spi+0, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTB", 0xc3, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTB", base_spi+1, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTC", 0xc4, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTC", base_spi+2, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
-    ret = map_one_spi(d, "PCI#INTD", 0xc5, DT_IRQ_TYPE_LEVEL_HIGH);
+    ret = map_one_spi(d, "PCI#INTD", base_spi+3, DT_IRQ_TYPE_LEVEL_HIGH);
     if ( ret )
         goto err;
 
@@ -115,6 +115,69 @@ err:
     return ret;
 }
 
+/*
+ * Xen does not currently support mapping MMIO regions and interrupt
+ * for bus child devices (referenced via the "ranges" and
+ * "interrupt-map" properties to domain 0). Instead for now map the
+ * necessary resources manually.
+ */
+static int xgene_storm_specific_mapping(struct domain *d)
+{
+    struct dt_device_node *node = NULL;
+    int ret;
+
+    while ( (node = dt_find_compatible_node(node, "pci", "apm,xgene-pcie")) )
+    {
+        u64 addr;
+
+        /* Identify the bus via it's control register address */
+        ret = dt_device_get_address(node, 0, &addr, NULL);
+        if ( ret < 0 )
+            return ret;
+
+        if ( !dt_device_is_available(node) )
+            continue;
+
+       switch ( addr )
+        {
+        case 0x1f2b0000: /* PCIe0 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                node,
+                0x0e000000000UL, 0x10000000000UL, 0xc2);
+            break;
+        case 0x1f2c0000: /* PCIe1 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                node,
+                0x0d000000000UL, 0x0e000000000UL, 0xc8);
+            break;
+        case 0x1f2d0000: /* PCIe2 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                node,
+                0x09000000000UL, 0x0a000000000UL, 0xce);
+            break;
+        case 0x1f500000: /* PCIe3 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                node,
+                0x0a000000000UL, 0x0c000000000UL, 0xd4);
+            break;
+        case 0x1f510000: /* PCIe4 */
+            ret = xgene_storm_pcie_specific_mapping(d,
+                node,
+                0x0c000000000UL, 0x0d000000000UL, 0xda);
+            break;
+
+        default:
+            printk("Ignoring unknown PCI bus %s\n", dt_node_full_name(node));
+            continue;
+        }
+
+        if ( ret < 0 )
+            return ret;
+    }
+
+    return 0;
+}
+
 static void xgene_storm_reset(void)
 {
     void __iomem *addr;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:30:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Cs-0000M2-AB; Wed, 19 Nov 2014 15:30:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7Cq-0000LS-EE
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:30:08 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	8B/F2-17694-F77BC645; Wed, 19 Nov 2014 15:30:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416411003!8762172!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31999 invoked from network); 19 Nov 2014 15:30:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:30:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="192908029"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:28:18 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xr7B3-00059R-CI;
	Wed, 19 Nov 2014 15:28:18 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Wed, 19 Nov
	2014 15:28:17 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:28:12 +0000
Message-ID: <1416410895-20461-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH v2 for-4.5 2/5] xen: arm: Drop EARLY_PRINTK_BAUD
	from entries which don't set ..._INIT_UART
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

EARLY_PRINTK_BAUD doesn't do anything unless EARLY_PRINTK_INIT_UART is set.

Furthermore only the pl011 driver implements the init routine at all, so the
entries which use 8250 and specified a BAUD were doubly wrong.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: New patch.
---
 xen/arch/arm/Rules.mk |    7 -------
 1 file changed, 7 deletions(-)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 30c7823..4ee51a9 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -45,7 +45,6 @@ ifeq ($(debug),y)
 # Early printk for versatile express
 ifeq ($(CONFIG_EARLY_PRINTK), vexpress)
 EARLY_PRINTK_INC := pl011
-EARLY_PRINTK_BAUD := 38400
 EARLY_UART_BASE_ADDRESS := 0x1c090000
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), fastmodel)
@@ -56,12 +55,10 @@ EARLY_UART_BASE_ADDRESS := 0x1c090000
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), exynos5250)
 EARLY_PRINTK_INC := exynos4210
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0x12c20000
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), midway)
 EARLY_PRINTK_INC := pl011
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0xfff36000
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), omap5432)
@@ -91,7 +88,6 @@ EARLY_UART_REG_SHIFT := 2
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), xgene-storm)
 EARLY_PRINTK_INC := 8250
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0x1c020000
 EARLY_UART_REG_SHIFT := 2
 endif
@@ -102,18 +98,15 @@ EARLY_UART_REG_SHIFT := 2
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), juno)
 EARLY_PRINTK_INC := pl011
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0x7ff80000
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), hip04-d01)
 EARLY_PRINTK_INC := 8250
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0xE4007000
 EARLY_UART_REG_SHIFT := 2
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), seattle)
 EARLY_PRINTK_INC := pl011
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0xe1010000
 endif
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:30:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Cq-0000Lc-UP; Wed, 19 Nov 2014 15:30:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7Cp-0000LF-GO
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:30:07 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	16/EA-09284-E77BC645; Wed, 19 Nov 2014 15:30:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416411003!8762172!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31809 invoked from network); 19 Nov 2014 15:30:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:30:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="192908022"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:28:17 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xr7B2-00059P-4j;
	Wed, 19 Nov 2014 15:28:17 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Wed, 19 Nov
	2014 15:28:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:28:11 +0000
Message-ID: <1416410895-20461-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH v2 for-4.5 1/5] xen: arm: Add earlyprintk for
	McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Remove pointless/unused baud rate setting.

A bunch of other entries have these, but cleaning them up is out of scope here I think.
---
 xen/arch/arm/Rules.mk |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 572d854..30c7823 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -95,6 +95,11 @@ EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0x1c020000
 EARLY_UART_REG_SHIFT := 2
 endif
+ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
+EARLY_PRINTK_INC := 8250
+EARLY_UART_BASE_ADDRESS := 0x1c021000
+EARLY_UART_REG_SHIFT := 2
+endif
 ifeq ($(CONFIG_EARLY_PRINTK), juno)
 EARLY_PRINTK_INC := pl011
 EARLY_PRINTK_BAUD := 115200
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:30:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Cs-0000M2-AB; Wed, 19 Nov 2014 15:30:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7Cq-0000LS-EE
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:30:08 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	8B/F2-17694-F77BC645; Wed, 19 Nov 2014 15:30:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416411003!8762172!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31999 invoked from network); 19 Nov 2014 15:30:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:30:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="192908029"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:28:18 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xr7B3-00059R-CI;
	Wed, 19 Nov 2014 15:28:18 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Wed, 19 Nov
	2014 15:28:17 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:28:12 +0000
Message-ID: <1416410895-20461-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH v2 for-4.5 2/5] xen: arm: Drop EARLY_PRINTK_BAUD
	from entries which don't set ..._INIT_UART
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

EARLY_PRINTK_BAUD doesn't do anything unless EARLY_PRINTK_INIT_UART is set.

Furthermore only the pl011 driver implements the init routine at all, so the
entries which use 8250 and specified a BAUD were doubly wrong.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: New patch.
---
 xen/arch/arm/Rules.mk |    7 -------
 1 file changed, 7 deletions(-)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 30c7823..4ee51a9 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -45,7 +45,6 @@ ifeq ($(debug),y)
 # Early printk for versatile express
 ifeq ($(CONFIG_EARLY_PRINTK), vexpress)
 EARLY_PRINTK_INC := pl011
-EARLY_PRINTK_BAUD := 38400
 EARLY_UART_BASE_ADDRESS := 0x1c090000
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), fastmodel)
@@ -56,12 +55,10 @@ EARLY_UART_BASE_ADDRESS := 0x1c090000
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), exynos5250)
 EARLY_PRINTK_INC := exynos4210
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0x12c20000
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), midway)
 EARLY_PRINTK_INC := pl011
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0xfff36000
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), omap5432)
@@ -91,7 +88,6 @@ EARLY_UART_REG_SHIFT := 2
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), xgene-storm)
 EARLY_PRINTK_INC := 8250
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0x1c020000
 EARLY_UART_REG_SHIFT := 2
 endif
@@ -102,18 +98,15 @@ EARLY_UART_REG_SHIFT := 2
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), juno)
 EARLY_PRINTK_INC := pl011
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0x7ff80000
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), hip04-d01)
 EARLY_PRINTK_INC := 8250
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0xE4007000
 EARLY_UART_REG_SHIFT := 2
 endif
 ifeq ($(CONFIG_EARLY_PRINTK), seattle)
 EARLY_PRINTK_INC := pl011
-EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0xe1010000
 endif
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:30:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Cq-0000Lc-UP; Wed, 19 Nov 2014 15:30:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7Cp-0000LF-GO
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:30:07 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	16/EA-09284-E77BC645; Wed, 19 Nov 2014 15:30:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416411003!8762172!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31809 invoked from network); 19 Nov 2014 15:30:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:30:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="192908022"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:28:17 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xr7B2-00059P-4j;
	Wed, 19 Nov 2014 15:28:17 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Wed, 19 Nov
	2014 15:28:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:28:11 +0000
Message-ID: <1416410895-20461-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH v2 for-4.5 1/5] xen: arm: Add earlyprintk for
	McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Remove pointless/unused baud rate setting.

A bunch of other entries have these, but cleaning them up is out of scope here I think.
---
 xen/arch/arm/Rules.mk |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 572d854..30c7823 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -95,6 +95,11 @@ EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0x1c020000
 EARLY_UART_REG_SHIFT := 2
 endif
+ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
+EARLY_PRINTK_INC := 8250
+EARLY_UART_BASE_ADDRESS := 0x1c021000
+EARLY_UART_REG_SHIFT := 2
+endif
 ifeq ($(CONFIG_EARLY_PRINTK), juno)
 EARLY_PRINTK_INC := pl011
 EARLY_PRINTK_BAUD := 115200
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:30:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Cs-0000Mh-PR; Wed, 19 Nov 2014 15:30:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7Cr-0000Lb-5A
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:30:09 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	A7/CF-25727-087BC645; Wed, 19 Nov 2014 15:30:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416411003!8762172!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32180 invoked from network); 19 Nov 2014 15:30:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:30:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="192908037"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:28:19 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xr7B4-00059U-J8;
	Wed, 19 Nov 2014 15:28:19 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Wed, 19 Nov
	2014 15:28:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:28:13 +0000
Message-ID: <1416410895-20461-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH v2 for-4.5 3/5] xen: arm: correct off by one in
	xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 callers pass the end as the pfn immediately *after* the last page to be
mapped, therefore adding one is incorrect and causes an additional page to be
mapped.

At the same time correct the printing of the mfn values, zero-padding them to
16 digits as for a paddr when they are frame numbers is just confusing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Fix the other printk format string too.
---
 xen/arch/arm/platforms/xgene-storm.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 29c4752..8685c93 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -45,11 +45,11 @@ static int map_one_mmio(struct domain *d, const char *what,
 {
     int ret;
 
-    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
+    printk("Additional MMIO %lx-%lx (%s)\n",
            start, end, what);
-    ret = map_mmio_regions(d, start, end - start + 1, start);
+    ret = map_mmio_regions(d, start, end - start, start);
     if ( ret )
-        printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
+        printk("Failed to map %s @ %lx to dom%d\n",
                what, start, d->domain_id);
     return ret;
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:30:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Cs-0000Mh-PR; Wed, 19 Nov 2014 15:30:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7Cr-0000Lb-5A
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:30:09 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	A7/CF-25727-087BC645; Wed, 19 Nov 2014 15:30:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416411003!8762172!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32180 invoked from network); 19 Nov 2014 15:30:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:30:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="192908037"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:28:19 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xr7B4-00059U-J8;
	Wed, 19 Nov 2014 15:28:19 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Wed, 19 Nov
	2014 15:28:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:28:13 +0000
Message-ID: <1416410895-20461-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH v2 for-4.5 3/5] xen: arm: correct off by one in
	xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 callers pass the end as the pfn immediately *after* the last page to be
mapped, therefore adding one is incorrect and causes an additional page to be
mapped.

At the same time correct the printing of the mfn values, zero-padding them to
16 digits as for a paddr when they are frame numbers is just confusing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Fix the other printk format string too.
---
 xen/arch/arm/platforms/xgene-storm.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 29c4752..8685c93 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -45,11 +45,11 @@ static int map_one_mmio(struct domain *d, const char *what,
 {
     int ret;
 
-    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
+    printk("Additional MMIO %lx-%lx (%s)\n",
            start, end, what);
-    ret = map_mmio_regions(d, start, end - start + 1, start);
+    ret = map_mmio_regions(d, start, end - start, start);
     if ( ret )
-        printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
+        printk("Failed to map %s @ %lx to dom%d\n",
                what, start, d->domain_id);
     return ret;
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:30:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Ct-0000Nc-DF; Wed, 19 Nov 2014 15:30:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7Cs-0000Lq-0u
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:30:10 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	5F/01-18267-187BC645; Wed, 19 Nov 2014 15:30:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416411003!8762172!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32331 invoked from network); 19 Nov 2014 15:30:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:30:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="192908048"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:28:21 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xr7B5-00059X-QV;
	Wed, 19 Nov 2014 15:28:20 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Wed, 19 Nov
	2014 15:28:19 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:28:14 +0000
Message-ID: <1416410895-20461-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH v2 for-4.5 4/5] xen: arm: correct specific
	mappings for PCIE0 on X-Gene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 region assigned to PCIE0, according to the docs, is 0x0e000000000 to
0x10000000000. They make no distinction between PCI CFG and PCI IO mem within
this range (in fact, I'm not sure that isn't up to the driver).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/platforms/xgene-storm.c |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 8685c93..8c27f24 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -89,22 +89,8 @@ static int xgene_storm_specific_mapping(struct domain *d)
     int ret;
 
     /* Map the PCIe bus resources */
-    ret = map_one_mmio(d, "PCI MEM REGION", paddr_to_pfn(0xe000000000UL),
-                                            paddr_to_pfn(0xe010000000UL));
-    if ( ret )
-        goto err;
-
-    ret = map_one_mmio(d, "PCI IO REGION", paddr_to_pfn(0xe080000000UL),
-                                           paddr_to_pfn(0xe080010000UL));
-    if ( ret )
-        goto err;
-
-    ret = map_one_mmio(d, "PCI CFG REGION", paddr_to_pfn(0xe0d0000000UL),
-                                            paddr_to_pfn(0xe0d0200000UL));
-    if ( ret )
-        goto err;
-    ret = map_one_mmio(d, "PCI MSI REGION", paddr_to_pfn(0xe010000000UL),
-                                            paddr_to_pfn(0xe010800000UL));
+    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
+                                        paddr_to_pfn(0x01000000000UL));
     if ( ret )
         goto err;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:30:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Ct-0000Nc-DF; Wed, 19 Nov 2014 15:30:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xr7Cs-0000Lq-0u
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:30:10 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	5F/01-18267-187BC645; Wed, 19 Nov 2014 15:30:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416411003!8762172!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32331 invoked from network); 19 Nov 2014 15:30:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:30:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="192908048"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:28:21 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with smtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Xr7B5-00059X-QV;
	Wed, 19 Nov 2014 15:28:20 +0000
Received: by drall.uk.xensource.com (sSMTP sendmail emulation); Wed, 19 Nov
	2014 15:28:19 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 19 Nov 2014 15:28:14 +0000
Message-ID: <1416410895-20461-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, julien.grall@linaro.org,
	tim@xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	stefano.stabellini@eu.citrix.com,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: [Xen-devel] [PATCH v2 for-4.5 4/5] xen: arm: correct specific
	mappings for PCIE0 on X-Gene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 region assigned to PCIE0, according to the docs, is 0x0e000000000 to
0x10000000000. They make no distinction between PCI CFG and PCI IO mem within
this range (in fact, I'm not sure that isn't up to the driver).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/platforms/xgene-storm.c |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 8685c93..8c27f24 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -89,22 +89,8 @@ static int xgene_storm_specific_mapping(struct domain *d)
     int ret;
 
     /* Map the PCIe bus resources */
-    ret = map_one_mmio(d, "PCI MEM REGION", paddr_to_pfn(0xe000000000UL),
-                                            paddr_to_pfn(0xe010000000UL));
-    if ( ret )
-        goto err;
-
-    ret = map_one_mmio(d, "PCI IO REGION", paddr_to_pfn(0xe080000000UL),
-                                           paddr_to_pfn(0xe080010000UL));
-    if ( ret )
-        goto err;
-
-    ret = map_one_mmio(d, "PCI CFG REGION", paddr_to_pfn(0xe0d0000000UL),
-                                            paddr_to_pfn(0xe0d0200000UL));
-    if ( ret )
-        goto err;
-    ret = map_one_mmio(d, "PCI MSI REGION", paddr_to_pfn(0xe010000000UL),
-                                            paddr_to_pfn(0xe010800000UL));
+    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
+                                        paddr_to_pfn(0x01000000000UL));
     if ( ret )
         goto err;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:41:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Nz-00014F-UM; Wed, 19 Nov 2014 15:41:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr7Ny-000143-2e
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 15:41:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E8/92-09842-13ABC645; Wed, 19 Nov 2014 15:41:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416411693!13594384!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22275 invoked from network); 19 Nov 2014 15:41:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:41:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194431286"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 19 Nov 2014 10:41:22 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr7Ni-0003Cw-39;
	Wed, 19 Nov 2014 15:41:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr7Nf-0004Jf-N4;
	Wed, 19 Nov 2014 15:41:19 +0000
Date: Wed, 19 Nov 2014 15:41:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31669-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31669: 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 31669 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31669/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  d279f6e1344871d71e379cc06c7baa6d4f9f0b29
baseline version:
 xen                  184e82513e3a4eb16b92e891d1d0ab719320c0ea

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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.4-testing
+ revision=d279f6e1344871d71e379cc06c7baa6d4f9f0b29
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.4-testing d279f6e1344871d71e379cc06c7baa6d4f9f0b29
+ branch=xen-4.4-testing
+ revision=d279f6e1344871d71e379cc06c7baa6d4f9f0b29
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.4-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.4-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.4-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.4-testing.git
++ : daily-cron.xen-4.4-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.4-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.4-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.4-testing
+ xenversion=xen-4.4
+ xenversion=4.4
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git d279f6e1344871d71e379cc06c7baa6d4f9f0b29:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   184e825..d279f6e  d279f6e1344871d71e379cc06c7baa6d4f9f0b29 -> stable-4.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:41:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Ny-000144-IY; Wed, 19 Nov 2014 15:41:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr7Nw-00013y-G4
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:41:36 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	6B/E4-27785-F2ABC645; Wed, 19 Nov 2014 15:41:35 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416411692!13512768!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13677 invoked from network); 19 Nov 2014 15:41:35 -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;
	19 Nov 2014 15:41:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="192914472"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:41:29 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr7No-0005Nv-NV;
	Wed, 19 Nov 2014 15:41:28 +0000
Date: Wed, 19 Nov 2014 15:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi Stefano,
> >>
> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >> > >      else
> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >> > >
> >> > >  }
> >> >
> >> > Yes, exactly
> >>
> >> I tried, hang still occurs with this change
> >
> > We need to figure out why during the hang you still have all the LRs
> > busy even if you are getting maintenance interrupts that should cause
> > them to be cleared.
> >
> 
> I see that I have free LRs during maintenance interrupt
> 
> (XEN) gic.c:871:d0v0 maintenance interrupt
> (XEN) GICH_LRs (vcpu 0) mask=0
> (XEN)    HW_LR[0]=9a015856
> (XEN)    HW_LR[1]=0
> (XEN)    HW_LR[2]=0
> (XEN)    HW_LR[3]=0
> (XEN) Inflight irq=86 lr=0
> (XEN) Inflight irq=2 lr=255
> (XEN) Pending irq=2
> 
> But I see that after I got hang - maintenance interrupts are generated
> continuously. Platform continues printing the same log till reboot.

Exactly the same log? As in the one above you just pasted?
That is very very suspicious.

I am thinking that we are not handling GICH_HCR_UIE correctly and
something we do in Xen, maybe writing to an LR register, might trigger a
new maintenance interrupt immediately causing an infinite loop.

Could you please try this patch? It disable GICH_HCR_UIE immediately on
hypervisor entry.


diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 4d2a92d..6ae8dc4 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -821,12 +823,8 @@ void gic_inject(void)
 
     gic_restore_pending_irqs(current);
 
-
     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
         GICH[GICH_HCR] |= GICH_HCR_UIE;
-    else
-        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
-
 }
 
 static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:41:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Nz-00014F-UM; Wed, 19 Nov 2014 15:41:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xr7Ny-000143-2e
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 15:41:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E8/92-09842-13ABC645; Wed, 19 Nov 2014 15:41:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416411693!13594384!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22275 invoked from network); 19 Nov 2014 15:41:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:41:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194431286"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 19 Nov 2014 10:41:22 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xr7Ni-0003Cw-39;
	Wed, 19 Nov 2014 15:41:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xr7Nf-0004Jf-N4;
	Wed, 19 Nov 2014 15:41:19 +0000
Date: Wed, 19 Nov 2014 15:41:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31669-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31669: 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 31669 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31669/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  d279f6e1344871d71e379cc06c7baa6d4f9f0b29
baseline version:
 xen                  184e82513e3a4eb16b92e891d1d0ab719320c0ea

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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.4-testing
+ revision=d279f6e1344871d71e379cc06c7baa6d4f9f0b29
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.4-testing d279f6e1344871d71e379cc06c7baa6d4f9f0b29
+ branch=xen-4.4-testing
+ revision=d279f6e1344871d71e379cc06c7baa6d4f9f0b29
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.4-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.4-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.4-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.4-testing.git
++ : daily-cron.xen-4.4-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.4-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.4-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.4-testing
+ xenversion=xen-4.4
+ xenversion=4.4
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git d279f6e1344871d71e379cc06c7baa6d4f9f0b29:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   184e825..d279f6e  d279f6e1344871d71e379cc06c7baa6d4f9f0b29 -> stable-4.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:41:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7Ny-000144-IY; Wed, 19 Nov 2014 15:41:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr7Nw-00013y-G4
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 15:41:36 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	6B/E4-27785-F2ABC645; Wed, 19 Nov 2014 15:41:35 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416411692!13512768!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13677 invoked from network); 19 Nov 2014 15:41:35 -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;
	19 Nov 2014 15:41:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="192914472"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:41:29 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr7No-0005Nv-NV;
	Wed, 19 Nov 2014 15:41:28 +0000
Date: Wed, 19 Nov 2014 15:41:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi Stefano,
> >>
> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >> > >      else
> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >> > >
> >> > >  }
> >> >
> >> > Yes, exactly
> >>
> >> I tried, hang still occurs with this change
> >
> > We need to figure out why during the hang you still have all the LRs
> > busy even if you are getting maintenance interrupts that should cause
> > them to be cleared.
> >
> 
> I see that I have free LRs during maintenance interrupt
> 
> (XEN) gic.c:871:d0v0 maintenance interrupt
> (XEN) GICH_LRs (vcpu 0) mask=0
> (XEN)    HW_LR[0]=9a015856
> (XEN)    HW_LR[1]=0
> (XEN)    HW_LR[2]=0
> (XEN)    HW_LR[3]=0
> (XEN) Inflight irq=86 lr=0
> (XEN) Inflight irq=2 lr=255
> (XEN) Pending irq=2
> 
> But I see that after I got hang - maintenance interrupts are generated
> continuously. Platform continues printing the same log till reboot.

Exactly the same log? As in the one above you just pasted?
That is very very suspicious.

I am thinking that we are not handling GICH_HCR_UIE correctly and
something we do in Xen, maybe writing to an LR register, might trigger a
new maintenance interrupt immediately causing an infinite loop.

Could you please try this patch? It disable GICH_HCR_UIE immediately on
hypervisor entry.


diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 4d2a92d..6ae8dc4 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -821,12 +823,8 @@ void gic_inject(void)
 
     gic_restore_pending_irqs(current);
 
-
     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
         GICH[GICH_HCR] |= GICH_HCR_UIE;
-    else
-        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
-
 }
 
 static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:43:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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 1Xr7PR-0001KY-IX; Wed, 19 Nov 2014 15:43:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1Xr7PP-0001KB-3P
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 15:43:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	88/01-09936-A8ABC645; Wed, 19 Nov 2014 15:43:06 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416411784!13952895!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10462 invoked from network); 19 Nov 2014 15:43:04 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:43:04 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so2331099wiv.8
	for <xen-devel@lists.xensource.com>;
	Wed, 19 Nov 2014 07:43:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=X0j4g+3lAwySRdFRJzS7wUPZ8AXfyCdQ8Ttk3HWvkiI=;
	b=Dfy+SsCQ3hQcFZcIX73hENQbH4P7bZCDVtNV+TOGrKGOEHabmRXb5AfX1GsVTlYD2p
	Rb4GASGPLyP5g23pzLkYiUoCOlVew9Q0PYtR0xE93BhioQWEfM+elvL/Yxo0B8VS7VvY
	NK/am9tFv55ekrowow4X9YlnYFYsoS4OWwnJ7fgG8YpkEo/wtdOX6Rc6RvwGe9DV9cp9
	C1kNQWg7zse7+xHcQ0g0cjI8m/+eJQA9lEL0eKHxzN6l/8TW4iezi2ZRWEUch4Hq5E0H
	xqXg6q7/o3LLoH/MMB8ybqjcDffma+X65+Xszm2Se5Qzjo83hw+eGVFZQUZI6C6ZxZDx
	K57w==
X-Gm-Message-State: ALoCoQnYW+W/m9is1g9QEB2P4DsB06hRnNa5wxIl/gep83uSfSMfoHI8qJNoS//TFh1uJArc3kbR
X-Received: by 10.194.200.101 with SMTP id jr5mr57624585wjc.6.1416411784546;
	Wed, 19 Nov 2014 07:43:04 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id td9sm148444wic.15.2014.11.19.07.43.02
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 07:43:03 -0800 (PST)
Message-ID: <546CBA8B.2090903@m2r.biz>
Date: Wed, 19 Nov 2014 16:43:07 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Don Slutz <dslutz@verizon.com>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
	<546CAFB1.8070904@terremark.com>
In-Reply-To: <546CAFB1.8070904@terremark.com>
Cc: anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org,
	xen-devel <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] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 19/11/2014 15:56, Don Slutz ha scritto:
> I think I know what is happening here.  But you are pointing at the 
> wrong change.
>
> commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
>
> Is what I am guessing at this time is the issue.  I think that 
> xen_enabled() is
> returning false in pc_machine_initfn.  Where as in pc_init1 is is 
> returning true.
>
> I am thinking that:
>
>
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 7bb97a4..3268c29 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
>      .desc = "Xen Fully-virtualized PC",
>      .init = pc_xen_hvm_init,
>      .max_cpus = HVM_MAX_VCPUS,
> -    .default_machine_opts = "accel=xen",
> +    .default_machine_opts = "accel=xen,vmport=off",
>      .hot_add_cpu = pc_hot_add_cpu,
>  };
>  #endif
>
> Will fix your issue. I have not tested this yet.

Tested now and it solves regression of linux hvm domUs with qemu 2.2, 
thanks.
I think that I'm not the only with this regression and that this patch 
(or a fix to the cause in vmport) should be applied before qemu 2.2 final.

>
>     -Don Slutz
>
>
> On 11/19/14 09:04, Fabio Fantoni wrote:
>> Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
>>> dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid 
>>> leaf with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" 
>>> patches, and qemu 2.2 from spice git (spice/next commit 
>>> e779fa0a715530311e6f59fc8adb0f6eca914a89):
>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>
>> I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the 
>> full backtrace of latest test:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, 
>>> addr=0,
>>>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>> 73          eax = env->regs[R_EAX];
>>> (gdb) bt full
>>> #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, 
>>> addr=0,
>>>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>         s = 0x5555564443a0
>>>         cs = 0x0
>>>         cpu = 0x0
>>>         __func__ = "vmport_ioport_read"
>>>         env = 0x8250
>>>         command = 0 '\000'
>>>         eax = 0
>>> #1  0x0000555555655fc4 in memory_region_read_accessor 
>>> (mr=0x555556444428,
>>>     addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>         tmp = 0
>>> #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
>>>     value=0x7fffffffd8d0, size=4, access_size_min=4, access_size_max=4,
>>>     access=0x555555655f62 <memory_region_read_accessor>, 
>>> mr=0x555556444428)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>         access_mask = 4294967295
>>>         access_size = 4
>>>         i = 0
>>> #3  0x00005555556590e9 in memory_region_dispatch_read1 
>>> (mr=0x555556444428,
>>>     addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>         data = 0
>>> #4  0x00005555556591b1 in memory_region_dispatch_read 
>>> (mr=0x555556444428,
>>>     addr=0, pval=0x7fffffffd9a8, size=4)
>>> ---Type <return> to continue, or q <return> to quit---
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>> No locals.
>>> #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
>>>     pval=0x7fffffffd9a8, size=4)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>> No locals.
>>> #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920, 
>>> addr=22104,
>>>     buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
>>>         l = 4
>>>         ptr = 0x555555a92d87 "%s/%d:\n"
>>>         val = 7852232130387826944
>>>         addr1 = 0
>>>         mr = 0x555556444428
>>>         error = false
>>> #7  0x000055555560a38f in address_space_read (as=0x555555eaf920, 
>>> addr=22104,
>>>     buf=0x7fffffffda50 "\377\377\377\377", len=4)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
>>> No locals.
>>> #8  0x000055555564fd4b in cpu_inl (addr=22104)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>         buf = "\377\377\377\377"
>>>         val = 21845
>>> #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>> ---Type <return> to continue, or q <return> to quit---
>>> No locals.
>>> #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>         i = 1
>>> #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
>>>     req=0x7ffff7ff3020) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>> No locals.
>>> #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>         state = 0x5555563c2510
>>>         req = 0x7ffff7ff3020
>>> #13 0x000055555596e240 in qemu_iohandler_poll 
>>> (pollfds=0x555556389a30, ret=1)
>>>     at iohandler.c:143
>>>         revents = 1
>>>         pioh = 0x5555563f7610
>>>         ioh = 0x555556450a40
>>> #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at 
>>> main-loop.c:495
>>>         ret = 1
>>>         timeout = 4294967295
>>>         timeout_ns = 3965432
>>> #15 0x0000555555756d3f in main_loop () at vl.c:1882
>>>         nonblocking = false
>>>         last_io = 0
>>> #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
>>>     envp=0x7fffffffe240) at vl.c:4400
>>> ---Type <return> to continue, or q <return> to quit---
>>>         i = 128
>>>         snapshot = 0
>>>         linux_boot = 0
>>>         initrd_filename = 0x0
>>>         kernel_filename = 0x0
>>>         kernel_cmdline = 0x555555a48f86 ""
>>>         boot_order = 0x555556387460 "dc"
>>>         ds = 0x5555564b2040
>>>         cyls = 0
>>>         heads = 0
>>>         secs = 0
>>>         translation = 0
>>>         hda_opts = 0x0
>>>         opts = 0x5555563873b0
>>>         machine_opts = 0x555556389010
>>>         icount_opts = 0x0
>>>         olist = 0x555555e57e80
>>>         optind = 62
>>>         optarg = 0x7fffffffe914 
>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>         loadvm = 0x0
>>>         machine_class = 0x55555637d5c0
>>>         cpu_model = 0x0
>>>         vga_model = 0x0
>>>         qtest_chrdev = 0x0
>>> ---Type <return> to continue, or q <return> to quit---
>>>         qtest_log = 0x0
>>>         pid_file = 0x0
>>>         incoming = 0x0
>>>         show_vnc_port = 0
>>>         defconfig = true
>>>         userconfig = true
>>>         log_mask = 0x0
>>>         log_file = 0x0
>>>         mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
>>>           realloc = 0x55555575a45a <realloc_and_trace>,
>>>           free = 0x55555575a4c1 <free_and_trace>, calloc = 0, 
>>> try_malloc = 0,
>>>           try_realloc = 0}
>>>         trace_events = 0x0
>>>         trace_file = 0x0
>>>         default_ram_size = 134217728
>>>         maxram_size = 2130706432
>>>         ram_slots = 0
>>>         vmstate_dump_file = 0x0
>>>         main_loop_err = 0x0
>>>         __func__ = "main"
>>
>> I take a fast look in source based on calltrace and I saw this commit:
>> http://git.qemu.org/?p=qemu.git;a=commit;h=37f9e258b64b3cf97c7c78df60660100c9eb5a21 
>>
>> xen-hvm.c: Add support for Xen access to vmport
>> Can be the cause of regression and I must try another test reverting 
>> this commit or is not related?
>>
>> Thanks for any reply anddo sorry for my bad english.
>>
>>>
>>> Qemu crash on fedora 20 lxde (with software updates of some days 
>>> ago) boot with this backtrace:
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
>>>> addr=0, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>> 73          eax = env->regs[R_EAX];
>>>> (gdb) bt full
>>>> #0  0x0000555555689607 in vmport_ioport_read 
>>>> (opaque=0x555556440a20, addr=0, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>         s = 0x555556440a20
>>>>         cs = 0x0
>>>>         cpu = 0x0
>>>>         __func__ = "vmport_ioport_read"
>>>>         env = 0x8250
>>>>         command = 0 '\000'
>>>>         eax = 0
>>>> #1  0x0000555555655b9c in memory_region_read_accessor 
>>>> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0, 
>>>> mask=4294967295)
>>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>>         tmp = 0
>>>> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0, 
>>>> value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
>>>>     access=0x555555655b3a <memory_region_read_accessor>, 
>>>> mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>>         access_mask = 4294967295
>>>>         access_size = 4
>>>>         i = 0
>>>> #3  0x0000555555658cc1 in memory_region_dispatch_read1 
>>>> (mr=0x555556440aa8, addr=0, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>>         data = 0
>>>> #4  0x0000555555658d89 in memory_region_dispatch_read 
>>>> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>>> No locals.
>>>> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0, 
>>>> pval=0x7fffffffd998, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>>> No locals.
>>>> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840, 
>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4, 
>>>> is_write=false)
>>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>>>>         l = 4
>>>>         ptr = 0x0
>>>>         val = 7964229952888770560
>>>>         addr1 = 0
>>>>         mr = 0x555556440aa8
>>>>         error = false
>>>> #7  0x000055555560a173 in address_space_read (as=0x555555eae840, 
>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
>>>> No locals.
>>>> #8  0x000055555564fac7 in cpu_inl (addr=22104) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>>         buf = "\377\377\377\377"
>>>>         val = 21845
>>>> #9  0x000055555567084b in do_inp (addr=22104, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>>> No locals.
>>>> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>>         i = 0
>>>> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590, 
>>>> req=0x7ffff7ff3000) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>>> ---Type <return> to continue, or q <return> to quit---
>>>> No locals.
>>>> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) 
>>>> at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>>         state = 0x5555563c1590
>>>>         req = 0x7ffff7ff3000
>>>> #13 0x000055555596d874 in qemu_iohandler_poll 
>>>> (pollfds=0x555556388a30, ret=1) at iohandler.c:143
>>>>         revents = 1
>>>>         pioh = 0x5555563f3c90
>>>>         ioh = 0x555556515f80
>>>> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at 
>>>> main-loop.c:495
>>>>         ret = 1
>>>>         timeout = 4294967295
>>>>         timeout_ns = 3418165
>>>> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>>>>         nonblocking = false
>>>>         last_io = 1
>>>> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038, 
>>>> envp=0x7fffffffe230) at vl.c:4400
>>>>         i = 128
>>>>         snapshot = 0
>>>>         linux_boot = 0
>>>>         initrd_filename = 0x0
>>>>         kernel_filename = 0x0
>>>>         kernel_cmdline = 0x555555a485c6 ""
>>>>         boot_order = 0x5555563864e0 "dc"
>>>>         ds = 0x5555564c71b0
>>>>         cyls = 0
>>>>         heads = 0
>>>>         secs = 0
>>>>         translation = 0
>>>>         hda_opts = 0x0
>>>>         opts = 0x555556386430
>>>>         machine_opts = 0x555556388090
>>>>         icount_opts = 0x0
>>>>         olist = 0x555555e56da0
>>>>         optind = 62
>>>>         optarg = 0x7fffffffe914 
>>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>>         loadvm = 0x0
>>>>         machine_class = 0x55555637c5c0
>>>>         cpu_model = 0x0
>>>>         vga_model = 0x0
>>>>         qtest_chrdev = 0x0
>>>> ---Type <return> to continue, or q <return> to quit---
>>>>         qtest_log = 0x0
>>>>         pid_file = 0x0
>>>>         incoming = 0x0
>>>>         show_vnc_port = 0
>>>>         defconfig = true
>>>>         userconfig = true
>>>>         log_mask = 0x0
>>>>         log_file = 0x0
>>>>         mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>, 
>>>> realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39 
>>>> <free_and_trace>, calloc = 0,
>>>>           try_malloc = 0, try_realloc = 0}
>>>>         trace_events = 0x0
>>>>         trace_file = 0x0
>>>>         default_ram_size = 134217728
>>>>         maxram_size = 2013265920
>>>>         ram_slots = 0
>>>>         vmstate_dump_file = 0x0
>>>>         main_loop_err = 0x0
>>>>         __func__ = "main"
>>>
>>>
>>>> xl -vvv create /etc/xen/FEDORA19.cfg
>>>> Parsing config from /etc/xen/FEDORA19.cfg
>>>> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660: 
>>>> create: how=(nil) callback=(nil) poller=0xac2af0
>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: 
>>>> Disk vdev=hda spec.backend=unknown
>>>> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda, 
>>>> backend phy unsuitable as phys path not a block device
>>>> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: 
>>>> Disk vdev=hda, using backend qdisk
>>>> libxl: debug: libxl_create.c:935:initiate_domain_create: running 
>>>> bootloader
>>>> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a 
>>>> PV domain, skipping bootloader
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac32f8: deregister unregistered
>>>> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
>>>> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
>>>> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
>>>> xc: detail:   Loader: 0000000000100000->000000000036b324
>>>> xc: detail:   Modules: 0000000000000000->0000000000000000
>>>> xc: detail:   TOTAL: 0000000000000000->0000000078000000
>>>> xc: detail:   ENTRY:    0000000000100000
>>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>>> xc: detail:   4KB PAGES: 0x0000000000000200
>>>> xc: detail:   2MB PAGES: 0x00000000000003bf
>>>> xc: detail:   1GB PAGES: 0x0000000000000000
>>>> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 -> 
>>>> 0x7f1f975012b0
>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: 
>>>> Disk vdev=hda spec.backend=qdisk
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac4ad0: deregister unregistered
>>>> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning 
>>>> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> /usr/lib/xen/bin/qemu-gdb
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> chardev=libxl-cmd,mode=control
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: FEDORA
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -spice
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> spicevmc,id=vdagent,name=vdagent
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> virtserialport,chardev=vdagent,name=com.redhat.spice.0
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> qxl-vga,vram_size_mb=64,ram_size_mb=64
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on 
>>>>
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> spicevmc,name=usbredir,id=usbrc1
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> usb-redir,chardev=usbrc1,id=usbrc1
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> spicevmc,name=usbredir,id=usbrc2
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> usb-redir,chardev=usbrc2,id=usbrc2
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> spicevmc,name=usbredir,id=usbrc3
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> usb-redir,chardev=usbrc3,id=usbrc3
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> spicevmc,name=usbredir,id=usbrc4
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> usb-redir,chardev=usbrc4,id=usbrc4
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -netdev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -drive
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>>>> register slotnum=3
>>>> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660: 
>>>> inprogress: poller=0xac2af0, flags=i
>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>>>> epath=/local/domain/0/device-model/9/state
>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>>>> epath=/local/domain/0/device-model/9/state
>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>>>> deregister slotnum=3
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac3558: deregister unregistered
>>>> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to 
>>>> /var/run/xen/qmp-libxl-9
>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>     "execute": "qmp_capabilities",
>>>>     "id": 1
>>>> }
>>>> '
>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: 
>>>> return
>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>     "execute": "query-chardev",
>>>>     "id": 2
>>>> }
>>>> '
>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: 
>>>> return
>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>     "execute": "query-vnc",
>>>>     "id": 3
>>>> }
>>>> '
>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: 
>>>> return
>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>>>> register slotnum=3
>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend 
>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting 
>>>> state 1
>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend 
>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>>>> deregister slotnum=3
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac8368: deregister unregistered
>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>>>> script: /etc/xen/scripts/vif-bridge online
>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking 
>>>> to execute: /etc/xen/scripts/vif-bridge online
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac83f0: deregister unregistered
>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>>>> script: /etc/xen/scripts/vif-bridge add
>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking 
>>>> to execute: /etc/xen/scripts/vif-bridge add
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac83f0: deregister unregistered
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac83f0: deregister unregistered
>>>> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao 
>>>> 0xac2660: progress report: ignored
>>>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660: 
>>>> complete, rc=0
>>>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660: 
>>>> destroy
>>>> xc: debug: hypercall buffer: total allocations:704 total releases:704
>>>> xc: debug: hypercall buffer: current allocations:0 maximum 
>>>> allocations:4
>>>> xc: debug: hypercall buffer: cache current size:4
>>>> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
>>>> xc: debug: hypercall buffer: total allocations:0 total releases:0
>>>> xc: debug: hypercall buffer: current allocations:0 maximum 
>>>> allocations:0
>>>> xc: debug: hypercall buffer: cache current size:0
>>>> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
>>>
>>> xl dmesg
>>>> (d9) HVM Loader
>>>> (d9) Detected Xen v4.5.0-rc
>>>> (d9) Xenbus rings @0xfeffc000, event channel 1
>>>> (d9) System requested SeaBIOS
>>>> (d9) CPU speed is 2660 MHz
>>>> (d9) Relocating guest memory for lowmem MMIO space disabled
>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
>>>> (d9) PCI-ISA link 0 routed to IRQ5
>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
>>>> (d9) PCI-ISA link 1 routed to IRQ10
>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
>>>> (d9) PCI-ISA link 2 routed to IRQ11
>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
>>>> (d9) PCI-ISA link 3 routed to IRQ5
>>>> (d9) pci dev 01:3 INTA->IRQ10
>>>> (d9) pci dev 02:0 INTA->IRQ11
>>>> (d9) pci dev 03:0 INTA->IRQ5
>>>> (d9) pci dev 04:0 INTA->IRQ5
>>>> (d9) pci dev 05:0 INTA->IRQ10
>>>> (d9) pci dev 06:0 INTA->IRQ11
>>>> (d9) pci dev 1d:0 INTA->IRQ10
>>>> (d9) pci dev 1d:1 INTB->IRQ11
>>>> (d9) pci dev 1d:2 INTC->IRQ5
>>>> (d9) pci dev 1d:7 INTD->IRQ5
>>>> (d9) No RAM in high memory; setting high_mem resource base to 
>>>> 100000000
>>>> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>>> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>>> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>>> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>>> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>>> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>>> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>>> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>>> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>>> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
>>>> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
>>>> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>>> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
>>>> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
>>>> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>>> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>>> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>>> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>>> (d9) Multiprocessor initialisation:
>>>> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>> ... done.
>>>> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>> ... done.
>>>> (d9) Testing HVM environment:
>>>> (d9)  - REP INSB across page boundaries ... passed
>>>> (d9)  - GS base MSRs and SWAPGS ... passed
>>>> (d9) Passed 2 of 2 tests
>>>> (d9) Writing SMBIOS tables ...
>>>> (d9) Loading SeaBIOS ...
>>>> (d9) Creating MP tables ...
>>>> (d9) Loading ACPI ...
>>>> (d9) S3 disabled
>>>> (d9) S4 disabled
>>>> (d9) vm86 TSS at fc00a100
>>>> (d9) BIOS map:
>>>> (d9)  10000-100d3: Scratch space
>>>> (d9)  c0000-fffff: Main BIOS
>>>> (d9) E820 table:
>>>> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>>> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>>> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>>> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>>> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
>>>> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>>> (d9) Invoking SeaBIOS ...
>>>> (d9) SeaBIOS (version 
>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>> (d9)
>>>> (d9) Found Xen hypervisor signature at 40000000
>>>> (d9) Running on QEMU (i440fx)
>>>> (d9) xen: copy e820...
>>>> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>>> (d9) CPU Mhz=2660
>>>> (d9) Found 13 PCI devices (max PCI bus is 00)
>>>> (d9) Allocated Xen hypercall page at 77fff000
>>>> (d9) Detected Xen v4.5.0-rc
>>>> (d9) xen: copy BIOS tables...
>>>> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>>> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>>> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
>>>> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>>> (d9) Using pmtimer, ioport 0xb008
>>>> (d9) Scan for VGA option rom
>>>> (d9) Running option rom at c000:0003
>>>> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
>>>> (d9) pmm call arg1=0
>>>> (d9) Turning on vga text mode console
>>>> (d9) SeaBIOS (version 
>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
>>>> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
>>>> (d9) Found 0 lpt ports
>>>> (d9) Found 0 serial ports
>>>> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>>> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>>> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
>>>> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>>> (d9) UHCI init on dev 00:1d.0 (io=c240)
>>>> (d9) UHCI init on dev 00:1d.1 (io=c260)
>>>> (d9) UHCI init on dev 00:1d.2 (io=c280)
>>>> (d9) PS2 keyboard initialized
>>>> (d9) All threads complete.
>>>> (d9) Scan for option roms
>>>> (d9) Running option rom at c980:0003
>>>> (d9) pmm call arg1=1
>>>> (d9) pmm call arg1=0
>>>> (d9) pmm call arg1=1
>>>> (d9) pmm call arg1=0
>>>> (d9) Searching bootorder for: /pci@i0cf8/*@6
>>>> (d9)
>>>> (d9) Press F12 for boot menu.
>>>> (d9)
>>>> (d9) Searching bootorder for: HALT
>>>> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba 
>>>> LCHS=1024/255/63 s=20480000
>>>> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
>>>> (d9) Returned 258048 bytes of ZoneHigh
>>>> (d9) e820 map has 6 items:
>>>> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>>>> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>>>> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>>>> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
>>>> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
>>>> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
>>>> (d9) enter handle_19:
>>>> (d9)   NULL
>>>> (d9) Booting from Hard Disk...
>>>> (d9) Booting from 0000:7c00
>>>> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
>>>
>>> domU's xl cfg:
>>>> name='FEDORA'
>>>> builder="hvm"
>>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>> memory=2048
>>>> vcpus=2
>>>> acpi_s3=0
>>>> acpi_s4=0
>>>> vif=['bridge=xenbr0']
>>>> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
>>>> boot='dc'
>>>> device_model_version='qemu-xen'
>>>> vnc=0
>>>> keymap="it"
>>>> vga="qxl"
>>>> spice=1
>>>> spicehost='0.0.0.0'
>>>> spiceport=6005
>>>> spicedisable_ticketing=1
>>>> spicevdagent=1
>>>> spice_clipboard_sharing=0
>>>> spiceusbredirection=4
>>>> soundhw="hda"
>>>
>>> I tested also with stdvga instead of qxl vga but qemu crash always 
>>> on fedora boot with same error.
>>>
>>> If you need more informations/tests tell me and I'll post them.
>>>
>>> Thanks for any reply and sorry for my bad english.
>>>
>>
>>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:43:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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 1Xr7PR-0001KY-IX; Wed, 19 Nov 2014 15:43:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1Xr7PP-0001KB-3P
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 15:43:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	88/01-09936-A8ABC645; Wed, 19 Nov 2014 15:43:06 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416411784!13952895!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10462 invoked from network); 19 Nov 2014 15:43:04 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:43:04 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so2331099wiv.8
	for <xen-devel@lists.xensource.com>;
	Wed, 19 Nov 2014 07:43:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=X0j4g+3lAwySRdFRJzS7wUPZ8AXfyCdQ8Ttk3HWvkiI=;
	b=Dfy+SsCQ3hQcFZcIX73hENQbH4P7bZCDVtNV+TOGrKGOEHabmRXb5AfX1GsVTlYD2p
	Rb4GASGPLyP5g23pzLkYiUoCOlVew9Q0PYtR0xE93BhioQWEfM+elvL/Yxo0B8VS7VvY
	NK/am9tFv55ekrowow4X9YlnYFYsoS4OWwnJ7fgG8YpkEo/wtdOX6Rc6RvwGe9DV9cp9
	C1kNQWg7zse7+xHcQ0g0cjI8m/+eJQA9lEL0eKHxzN6l/8TW4iezi2ZRWEUch4Hq5E0H
	xqXg6q7/o3LLoH/MMB8ybqjcDffma+X65+Xszm2Se5Qzjo83hw+eGVFZQUZI6C6ZxZDx
	K57w==
X-Gm-Message-State: ALoCoQnYW+W/m9is1g9QEB2P4DsB06hRnNa5wxIl/gep83uSfSMfoHI8qJNoS//TFh1uJArc3kbR
X-Received: by 10.194.200.101 with SMTP id jr5mr57624585wjc.6.1416411784546;
	Wed, 19 Nov 2014 07:43:04 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id td9sm148444wic.15.2014.11.19.07.43.02
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 07:43:03 -0800 (PST)
Message-ID: <546CBA8B.2090903@m2r.biz>
Date: Wed, 19 Nov 2014 16:43:07 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Don Slutz <dslutz@verizon.com>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
	<546CAFB1.8070904@terremark.com>
In-Reply-To: <546CAFB1.8070904@terremark.com>
Cc: anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org,
	xen-devel <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] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 19/11/2014 15:56, Don Slutz ha scritto:
> I think I know what is happening here.  But you are pointing at the 
> wrong change.
>
> commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
>
> Is what I am guessing at this time is the issue.  I think that 
> xen_enabled() is
> returning false in pc_machine_initfn.  Where as in pc_init1 is is 
> returning true.
>
> I am thinking that:
>
>
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 7bb97a4..3268c29 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
>      .desc = "Xen Fully-virtualized PC",
>      .init = pc_xen_hvm_init,
>      .max_cpus = HVM_MAX_VCPUS,
> -    .default_machine_opts = "accel=xen",
> +    .default_machine_opts = "accel=xen,vmport=off",
>      .hot_add_cpu = pc_hot_add_cpu,
>  };
>  #endif
>
> Will fix your issue. I have not tested this yet.

Tested now and it solves regression of linux hvm domUs with qemu 2.2, 
thanks.
I think that I'm not the only with this regression and that this patch 
(or a fix to the cause in vmport) should be applied before qemu 2.2 final.

>
>     -Don Slutz
>
>
> On 11/19/14 09:04, Fabio Fantoni wrote:
>> Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
>>> dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid 
>>> leaf with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" 
>>> patches, and qemu 2.2 from spice git (spice/next commit 
>>> e779fa0a715530311e6f59fc8adb0f6eca914a89):
>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>
>> I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the 
>> full backtrace of latest test:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, 
>>> addr=0,
>>>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>> 73          eax = env->regs[R_EAX];
>>> (gdb) bt full
>>> #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, 
>>> addr=0,
>>>     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>         s = 0x5555564443a0
>>>         cs = 0x0
>>>         cpu = 0x0
>>>         __func__ = "vmport_ioport_read"
>>>         env = 0x8250
>>>         command = 0 '\000'
>>>         eax = 0
>>> #1  0x0000555555655fc4 in memory_region_read_accessor 
>>> (mr=0x555556444428,
>>>     addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>         tmp = 0
>>> #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
>>>     value=0x7fffffffd8d0, size=4, access_size_min=4, access_size_max=4,
>>>     access=0x555555655f62 <memory_region_read_accessor>, 
>>> mr=0x555556444428)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>         access_mask = 4294967295
>>>         access_size = 4
>>>         i = 0
>>> #3  0x00005555556590e9 in memory_region_dispatch_read1 
>>> (mr=0x555556444428,
>>>     addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>         data = 0
>>> #4  0x00005555556591b1 in memory_region_dispatch_read 
>>> (mr=0x555556444428,
>>>     addr=0, pval=0x7fffffffd9a8, size=4)
>>> ---Type <return> to continue, or q <return> to quit---
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>> No locals.
>>> #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
>>>     pval=0x7fffffffd9a8, size=4)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>> No locals.
>>> #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920, 
>>> addr=22104,
>>>     buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
>>>         l = 4
>>>         ptr = 0x555555a92d87 "%s/%d:\n"
>>>         val = 7852232130387826944
>>>         addr1 = 0
>>>         mr = 0x555556444428
>>>         error = false
>>> #7  0x000055555560a38f in address_space_read (as=0x555555eaf920, 
>>> addr=22104,
>>>     buf=0x7fffffffda50 "\377\377\377\377", len=4)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
>>> No locals.
>>> #8  0x000055555564fd4b in cpu_inl (addr=22104)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>         buf = "\377\377\377\377"
>>>         val = 21845
>>> #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>> ---Type <return> to continue, or q <return> to quit---
>>> No locals.
>>> #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>         i = 1
>>> #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
>>>     req=0x7ffff7ff3020) at 
>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>> No locals.
>>> #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>         state = 0x5555563c2510
>>>         req = 0x7ffff7ff3020
>>> #13 0x000055555596e240 in qemu_iohandler_poll 
>>> (pollfds=0x555556389a30, ret=1)
>>>     at iohandler.c:143
>>>         revents = 1
>>>         pioh = 0x5555563f7610
>>>         ioh = 0x555556450a40
>>> #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at 
>>> main-loop.c:495
>>>         ret = 1
>>>         timeout = 4294967295
>>>         timeout_ns = 3965432
>>> #15 0x0000555555756d3f in main_loop () at vl.c:1882
>>>         nonblocking = false
>>>         last_io = 0
>>> #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
>>>     envp=0x7fffffffe240) at vl.c:4400
>>> ---Type <return> to continue, or q <return> to quit---
>>>         i = 128
>>>         snapshot = 0
>>>         linux_boot = 0
>>>         initrd_filename = 0x0
>>>         kernel_filename = 0x0
>>>         kernel_cmdline = 0x555555a48f86 ""
>>>         boot_order = 0x555556387460 "dc"
>>>         ds = 0x5555564b2040
>>>         cyls = 0
>>>         heads = 0
>>>         secs = 0
>>>         translation = 0
>>>         hda_opts = 0x0
>>>         opts = 0x5555563873b0
>>>         machine_opts = 0x555556389010
>>>         icount_opts = 0x0
>>>         olist = 0x555555e57e80
>>>         optind = 62
>>>         optarg = 0x7fffffffe914 
>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>         loadvm = 0x0
>>>         machine_class = 0x55555637d5c0
>>>         cpu_model = 0x0
>>>         vga_model = 0x0
>>>         qtest_chrdev = 0x0
>>> ---Type <return> to continue, or q <return> to quit---
>>>         qtest_log = 0x0
>>>         pid_file = 0x0
>>>         incoming = 0x0
>>>         show_vnc_port = 0
>>>         defconfig = true
>>>         userconfig = true
>>>         log_mask = 0x0
>>>         log_file = 0x0
>>>         mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
>>>           realloc = 0x55555575a45a <realloc_and_trace>,
>>>           free = 0x55555575a4c1 <free_and_trace>, calloc = 0, 
>>> try_malloc = 0,
>>>           try_realloc = 0}
>>>         trace_events = 0x0
>>>         trace_file = 0x0
>>>         default_ram_size = 134217728
>>>         maxram_size = 2130706432
>>>         ram_slots = 0
>>>         vmstate_dump_file = 0x0
>>>         main_loop_err = 0x0
>>>         __func__ = "main"
>>
>> I take a fast look in source based on calltrace and I saw this commit:
>> http://git.qemu.org/?p=qemu.git;a=commit;h=37f9e258b64b3cf97c7c78df60660100c9eb5a21 
>>
>> xen-hvm.c: Add support for Xen access to vmport
>> Can be the cause of regression and I must try another test reverting 
>> this commit or is not related?
>>
>> Thanks for any reply anddo sorry for my bad english.
>>
>>>
>>> Qemu crash on fedora 20 lxde (with software updates of some days 
>>> ago) boot with this backtrace:
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20, 
>>>> addr=0, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>> 73          eax = env->regs[R_EAX];
>>>> (gdb) bt full
>>>> #0  0x0000555555689607 in vmport_ioport_read 
>>>> (opaque=0x555556440a20, addr=0, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>         s = 0x555556440a20
>>>>         cs = 0x0
>>>>         cpu = 0x0
>>>>         __func__ = "vmport_ioport_read"
>>>>         env = 0x8250
>>>>         command = 0 '\000'
>>>>         eax = 0
>>>> #1  0x0000555555655b9c in memory_region_read_accessor 
>>>> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0, 
>>>> mask=4294967295)
>>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>>         tmp = 0
>>>> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0, 
>>>> value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
>>>>     access=0x555555655b3a <memory_region_read_accessor>, 
>>>> mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>>         access_mask = 4294967295
>>>>         access_size = 4
>>>>         i = 0
>>>> #3  0x0000555555658cc1 in memory_region_dispatch_read1 
>>>> (mr=0x555556440aa8, addr=0, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>>         data = 0
>>>> #4  0x0000555555658d89 in memory_region_dispatch_read 
>>>> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>>> No locals.
>>>> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0, 
>>>> pval=0x7fffffffd998, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>>> No locals.
>>>> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840, 
>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4, 
>>>> is_write=false)
>>>>     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>>>>         l = 4
>>>>         ptr = 0x0
>>>>         val = 7964229952888770560
>>>>         addr1 = 0
>>>>         mr = 0x555556440aa8
>>>>         error = false
>>>> #7  0x000055555560a173 in address_space_read (as=0x555555eae840, 
>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
>>>> No locals.
>>>> #8  0x000055555564fac7 in cpu_inl (addr=22104) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>>         buf = "\377\377\377\377"
>>>>         val = 21845
>>>> #9  0x000055555567084b in do_inp (addr=22104, size=4) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>>> No locals.
>>>> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>>         i = 0
>>>> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590, 
>>>> req=0x7ffff7ff3000) at 
>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>>> ---Type <return> to continue, or q <return> to quit---
>>>> No locals.
>>>> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) 
>>>> at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>>         state = 0x5555563c1590
>>>>         req = 0x7ffff7ff3000
>>>> #13 0x000055555596d874 in qemu_iohandler_poll 
>>>> (pollfds=0x555556388a30, ret=1) at iohandler.c:143
>>>>         revents = 1
>>>>         pioh = 0x5555563f3c90
>>>>         ioh = 0x555556515f80
>>>> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at 
>>>> main-loop.c:495
>>>>         ret = 1
>>>>         timeout = 4294967295
>>>>         timeout_ns = 3418165
>>>> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>>>>         nonblocking = false
>>>>         last_io = 1
>>>> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038, 
>>>> envp=0x7fffffffe230) at vl.c:4400
>>>>         i = 128
>>>>         snapshot = 0
>>>>         linux_boot = 0
>>>>         initrd_filename = 0x0
>>>>         kernel_filename = 0x0
>>>>         kernel_cmdline = 0x555555a485c6 ""
>>>>         boot_order = 0x5555563864e0 "dc"
>>>>         ds = 0x5555564c71b0
>>>>         cyls = 0
>>>>         heads = 0
>>>>         secs = 0
>>>>         translation = 0
>>>>         hda_opts = 0x0
>>>>         opts = 0x555556386430
>>>>         machine_opts = 0x555556388090
>>>>         icount_opts = 0x0
>>>>         olist = 0x555555e56da0
>>>>         optind = 62
>>>>         optarg = 0x7fffffffe914 
>>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>>         loadvm = 0x0
>>>>         machine_class = 0x55555637c5c0
>>>>         cpu_model = 0x0
>>>>         vga_model = 0x0
>>>>         qtest_chrdev = 0x0
>>>> ---Type <return> to continue, or q <return> to quit---
>>>>         qtest_log = 0x0
>>>>         pid_file = 0x0
>>>>         incoming = 0x0
>>>>         show_vnc_port = 0
>>>>         defconfig = true
>>>>         userconfig = true
>>>>         log_mask = 0x0
>>>>         log_file = 0x0
>>>>         mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>, 
>>>> realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39 
>>>> <free_and_trace>, calloc = 0,
>>>>           try_malloc = 0, try_realloc = 0}
>>>>         trace_events = 0x0
>>>>         trace_file = 0x0
>>>>         default_ram_size = 134217728
>>>>         maxram_size = 2013265920
>>>>         ram_slots = 0
>>>>         vmstate_dump_file = 0x0
>>>>         main_loop_err = 0x0
>>>>         __func__ = "main"
>>>
>>>
>>>> xl -vvv create /etc/xen/FEDORA19.cfg
>>>> Parsing config from /etc/xen/FEDORA19.cfg
>>>> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660: 
>>>> create: how=(nil) callback=(nil) poller=0xac2af0
>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: 
>>>> Disk vdev=hda spec.backend=unknown
>>>> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda, 
>>>> backend phy unsuitable as phys path not a block device
>>>> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: 
>>>> Disk vdev=hda, using backend qdisk
>>>> libxl: debug: libxl_create.c:935:initiate_domain_create: running 
>>>> bootloader
>>>> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a 
>>>> PV domain, skipping bootloader
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac32f8: deregister unregistered
>>>> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
>>>> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
>>>> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
>>>> xc: detail:   Loader: 0000000000100000->000000000036b324
>>>> xc: detail:   Modules: 0000000000000000->0000000000000000
>>>> xc: detail:   TOTAL: 0000000000000000->0000000078000000
>>>> xc: detail:   ENTRY:    0000000000100000
>>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>>> xc: detail:   4KB PAGES: 0x0000000000000200
>>>> xc: detail:   2MB PAGES: 0x00000000000003bf
>>>> xc: detail:   1GB PAGES: 0x0000000000000000
>>>> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 -> 
>>>> 0x7f1f975012b0
>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: 
>>>> Disk vdev=hda spec.backend=qdisk
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac4ad0: deregister unregistered
>>>> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning 
>>>> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> /usr/lib/xen/bin/qemu-gdb
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> chardev=libxl-cmd,mode=control
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: FEDORA
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -spice
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> spicevmc,id=vdagent,name=vdagent
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> virtserialport,chardev=vdagent,name=com.redhat.spice.0
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> qxl-vga,vram_size_mb=64,ram_size_mb=64
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on 
>>>>
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> spicevmc,name=usbredir,id=usbrc1
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> usb-redir,chardev=usbrc1,id=usbrc1
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> spicevmc,name=usbredir,id=usbrc2
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> usb-redir,chardev=usbrc2,id=usbrc2
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> spicevmc,name=usbredir,id=usbrc3
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> usb-redir,chardev=usbrc3,id=usbrc3
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> spicevmc,name=usbredir,id=usbrc4
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> usb-redir,chardev=usbrc4,id=usbrc4
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -netdev
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -drive
>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 
>>>> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>>>> register slotnum=3
>>>> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660: 
>>>> inprogress: poller=0xac2af0, flags=i
>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>>>> epath=/local/domain/0/device-model/9/state
>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558 
>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event 
>>>> epath=/local/domain/0/device-model/9/state
>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0: 
>>>> deregister slotnum=3
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac3558: deregister unregistered
>>>> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to 
>>>> /var/run/xen/qmp-libxl-9
>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>     "execute": "qmp_capabilities",
>>>>     "id": 1
>>>> }
>>>> '
>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: 
>>>> return
>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>     "execute": "query-chardev",
>>>>     "id": 2
>>>> }
>>>> '
>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: 
>>>> return
>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>     "execute": "query-vnc",
>>>>     "id": 3
>>>> }
>>>> '
>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: 
>>>> return
>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch 
>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>>>> register slotnum=3
>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend 
>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting 
>>>> state 1
>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368 
>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event 
>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend 
>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1: 
>>>> deregister slotnum=3
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac8368: deregister unregistered
>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>>>> script: /etc/xen/scripts/vif-bridge online
>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking 
>>>> to execute: /etc/xen/scripts/vif-bridge online
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac83f0: deregister unregistered
>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug 
>>>> script: /etc/xen/scripts/vif-bridge add
>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking 
>>>> to execute: /etc/xen/scripts/vif-bridge add
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac83f0: deregister unregistered
>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch 
>>>> w=0xac83f0: deregister unregistered
>>>> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao 
>>>> 0xac2660: progress report: ignored
>>>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660: 
>>>> complete, rc=0
>>>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660: 
>>>> destroy
>>>> xc: debug: hypercall buffer: total allocations:704 total releases:704
>>>> xc: debug: hypercall buffer: current allocations:0 maximum 
>>>> allocations:4
>>>> xc: debug: hypercall buffer: cache current size:4
>>>> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
>>>> xc: debug: hypercall buffer: total allocations:0 total releases:0
>>>> xc: debug: hypercall buffer: current allocations:0 maximum 
>>>> allocations:0
>>>> xc: debug: hypercall buffer: cache current size:0
>>>> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
>>>
>>> xl dmesg
>>>> (d9) HVM Loader
>>>> (d9) Detected Xen v4.5.0-rc
>>>> (d9) Xenbus rings @0xfeffc000, event channel 1
>>>> (d9) System requested SeaBIOS
>>>> (d9) CPU speed is 2660 MHz
>>>> (d9) Relocating guest memory for lowmem MMIO space disabled
>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
>>>> (d9) PCI-ISA link 0 routed to IRQ5
>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
>>>> (d9) PCI-ISA link 1 routed to IRQ10
>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
>>>> (d9) PCI-ISA link 2 routed to IRQ11
>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
>>>> (d9) PCI-ISA link 3 routed to IRQ5
>>>> (d9) pci dev 01:3 INTA->IRQ10
>>>> (d9) pci dev 02:0 INTA->IRQ11
>>>> (d9) pci dev 03:0 INTA->IRQ5
>>>> (d9) pci dev 04:0 INTA->IRQ5
>>>> (d9) pci dev 05:0 INTA->IRQ10
>>>> (d9) pci dev 06:0 INTA->IRQ11
>>>> (d9) pci dev 1d:0 INTA->IRQ10
>>>> (d9) pci dev 1d:1 INTB->IRQ11
>>>> (d9) pci dev 1d:2 INTC->IRQ5
>>>> (d9) pci dev 1d:7 INTD->IRQ5
>>>> (d9) No RAM in high memory; setting high_mem resource base to 
>>>> 100000000
>>>> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>>> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>>> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>>> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>>> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>>> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>>> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>>> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>>> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>>> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
>>>> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
>>>> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>>> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
>>>> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
>>>> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>>> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>>> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>>> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>>> (d9) Multiprocessor initialisation:
>>>> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>> ... done.
>>>> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>> ... done.
>>>> (d9) Testing HVM environment:
>>>> (d9)  - REP INSB across page boundaries ... passed
>>>> (d9)  - GS base MSRs and SWAPGS ... passed
>>>> (d9) Passed 2 of 2 tests
>>>> (d9) Writing SMBIOS tables ...
>>>> (d9) Loading SeaBIOS ...
>>>> (d9) Creating MP tables ...
>>>> (d9) Loading ACPI ...
>>>> (d9) S3 disabled
>>>> (d9) S4 disabled
>>>> (d9) vm86 TSS at fc00a100
>>>> (d9) BIOS map:
>>>> (d9)  10000-100d3: Scratch space
>>>> (d9)  c0000-fffff: Main BIOS
>>>> (d9) E820 table:
>>>> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>>> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>>> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>>> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>>> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
>>>> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>>> (d9) Invoking SeaBIOS ...
>>>> (d9) SeaBIOS (version 
>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>> (d9)
>>>> (d9) Found Xen hypervisor signature at 40000000
>>>> (d9) Running on QEMU (i440fx)
>>>> (d9) xen: copy e820...
>>>> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>>> (d9) CPU Mhz=2660
>>>> (d9) Found 13 PCI devices (max PCI bus is 00)
>>>> (d9) Allocated Xen hypercall page at 77fff000
>>>> (d9) Detected Xen v4.5.0-rc
>>>> (d9) xen: copy BIOS tables...
>>>> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>>> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>>> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
>>>> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>>> (d9) Using pmtimer, ioport 0xb008
>>>> (d9) Scan for VGA option rom
>>>> (d9) Running option rom at c000:0003
>>>> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
>>>> (d9) pmm call arg1=0
>>>> (d9) Turning on vga text mode console
>>>> (d9) SeaBIOS (version 
>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
>>>> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
>>>> (d9) Found 0 lpt ports
>>>> (d9) Found 0 serial ports
>>>> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>>> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>>> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
>>>> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>>> (d9) UHCI init on dev 00:1d.0 (io=c240)
>>>> (d9) UHCI init on dev 00:1d.1 (io=c260)
>>>> (d9) UHCI init on dev 00:1d.2 (io=c280)
>>>> (d9) PS2 keyboard initialized
>>>> (d9) All threads complete.
>>>> (d9) Scan for option roms
>>>> (d9) Running option rom at c980:0003
>>>> (d9) pmm call arg1=1
>>>> (d9) pmm call arg1=0
>>>> (d9) pmm call arg1=1
>>>> (d9) pmm call arg1=0
>>>> (d9) Searching bootorder for: /pci@i0cf8/*@6
>>>> (d9)
>>>> (d9) Press F12 for boot menu.
>>>> (d9)
>>>> (d9) Searching bootorder for: HALT
>>>> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba 
>>>> LCHS=1024/255/63 s=20480000
>>>> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
>>>> (d9) Returned 258048 bytes of ZoneHigh
>>>> (d9) e820 map has 6 items:
>>>> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>>>> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>>>> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>>>> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
>>>> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
>>>> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
>>>> (d9) enter handle_19:
>>>> (d9)   NULL
>>>> (d9) Booting from Hard Disk...
>>>> (d9) Booting from 0000:7c00
>>>> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
>>>
>>> domU's xl cfg:
>>>> name='FEDORA'
>>>> builder="hvm"
>>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>> memory=2048
>>>> vcpus=2
>>>> acpi_s3=0
>>>> acpi_s4=0
>>>> vif=['bridge=xenbr0']
>>>> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
>>>> boot='dc'
>>>> device_model_version='qemu-xen'
>>>> vnc=0
>>>> keymap="it"
>>>> vga="qxl"
>>>> spice=1
>>>> spicehost='0.0.0.0'
>>>> spiceport=6005
>>>> spicedisable_ticketing=1
>>>> spicevdagent=1
>>>> spice_clipboard_sharing=0
>>>> spiceusbredirection=4
>>>> soundhw="hda"
>>>
>>> I tested also with stdvga instead of qxl vga but qemu crash always 
>>> on fedora boot with same error.
>>>
>>> If you need more informations/tests tell me and I'll post them.
>>>
>>> Thanks for any reply and sorry for my bad english.
>>>
>>
>>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:53:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7ZG-0001ju-Vp; Wed, 19 Nov 2014 15:53: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@citrix.com>) id 1Xr7ZF-0001jp-51
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 15:53:17 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	69/BF-29352-CECBC645; Wed, 19 Nov 2014 15:53:16 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416412390!12270510!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13642 invoked from network); 19 Nov 2014 15:53:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:53:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194436994"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:53:02 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr7Yz-0005e9-N0;
	Wed, 19 Nov 2014 15:53:01 +0000
Date: Wed, 19 Nov 2014 15:52:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
In-Reply-To: <546CBA8B.2090903@m2r.biz>
Message-ID: <alpine.DEB.2.02.1411191551120.12596@kaball.uk.xensource.com>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
	<546CAFB1.8070904@terremark.com> <546CBA8B.2090903@m2r.biz>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Don Slutz <dslutz@verizon.com>, anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org
Subject: Re: [Xen-devel] [Qemu-devel] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Fabio Fantoni wrote:
> Il 19/11/2014 15:56, Don Slutz ha scritto:
> > I think I know what is happening here.  But you are pointing at the wrong
> > change.
> > 
> > commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
> > 
> > Is what I am guessing at this time is the issue.  I think that xen_enabled()
> > is
> > returning false in pc_machine_initfn.  Where as in pc_init1 is is returning
> > true.
> > 
> > I am thinking that:
> > 
> > 
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > index 7bb97a4..3268c29 100644
> > --- a/hw/i386/pc_piix.c
> > +++ b/hw/i386/pc_piix.c
> > @@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
> >      .desc = "Xen Fully-virtualized PC",
> >      .init = pc_xen_hvm_init,
> >      .max_cpus = HVM_MAX_VCPUS,
> > -    .default_machine_opts = "accel=xen",
> > +    .default_machine_opts = "accel=xen,vmport=off",
> >      .hot_add_cpu = pc_hot_add_cpu,
> >  };
> >  #endif
> > 
> > Will fix your issue. I have not tested this yet.
> 
> Tested now and it solves regression of linux hvm domUs with qemu 2.2, thanks.
> I think that I'm not the only with this regression and that this patch (or a
> fix to the cause in vmport) should be applied before qemu 2.2 final.

Don,
please submit a proper patch with a Signed-off-by.

Thanks!

- Stefano

> > 
> >     -Don Slutz
> > 
> > 
> > On 11/19/14 09:04, Fabio Fantoni wrote:
> > > Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
> > > > dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid leaf
> > > > with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, and
> > > > qemu 2.2 from spice git (spice/next commit
> > > > e779fa0a715530311e6f59fc8adb0f6eca914a89):
> > > > https://github.com/Fantu/Xen/commits/rebase/m2r-staging
> > > 
> > > I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the full
> > > backtrace of latest test:
> > > > Program received signal SIGSEGV, Segmentation fault.
> > > > 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, addr=0,
> > > >     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > 73          eax = env->regs[R_EAX];
> > > > (gdb) bt full
> > > > #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
> > > > addr=0,
> > > >     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > >         s = 0x5555564443a0
> > > >         cs = 0x0
> > > >         cpu = 0x0
> > > >         __func__ = "vmport_ioport_read"
> > > >         env = 0x8250
> > > >         command = 0 '\000'
> > > >         eax = 0
> > > > #1  0x0000555555655fc4 in memory_region_read_accessor
> > > > (mr=0x555556444428,
> > > >     addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
> > > >         tmp = 0
> > > > #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
> > > >     value=0x7fffffffd8d0, size=4, access_size_min=4, access_size_max=4,
> > > >     access=0x555555655f62 <memory_region_read_accessor>,
> > > > mr=0x555556444428)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
> > > >         access_mask = 4294967295
> > > >         access_size = 4
> > > >         i = 0
> > > > #3  0x00005555556590e9 in memory_region_dispatch_read1
> > > > (mr=0x555556444428,
> > > >     addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
> > > >         data = 0
> > > > #4  0x00005555556591b1 in memory_region_dispatch_read
> > > > (mr=0x555556444428,
> > > >     addr=0, pval=0x7fffffffd9a8, size=4)
> > > > ---Type <return> to continue, or q <return> to quit---
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> > > > No locals.
> > > > #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
> > > >     pval=0x7fffffffd9a8, size=4)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> > > > No locals.
> > > > #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920,
> > > > addr=22104,
> > > >     buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
> > > >         l = 4
> > > >         ptr = 0x555555a92d87 "%s/%d:\n"
> > > >         val = 7852232130387826944
> > > >         addr1 = 0
> > > >         mr = 0x555556444428
> > > >         error = false
> > > > #7  0x000055555560a38f in address_space_read (as=0x555555eaf920,
> > > > addr=22104,
> > > >     buf=0x7fffffffda50 "\377\377\377\377", len=4)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
> > > > No locals.
> > > > #8  0x000055555564fd4b in cpu_inl (addr=22104)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
> > > >         buf = "\377\377\377\377"
> > > >         val = 21845
> > > > #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> > > > ---Type <return> to continue, or q <return> to quit---
> > > > No locals.
> > > > #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
> > > >         i = 1
> > > > #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
> > > >     req=0x7ffff7ff3020) at
> > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> > > > No locals.
> > > > #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
> > > >         state = 0x5555563c2510
> > > >         req = 0x7ffff7ff3020
> > > > #13 0x000055555596e240 in qemu_iohandler_poll (pollfds=0x555556389a30,
> > > > ret=1)
> > > >     at iohandler.c:143
> > > >         revents = 1
> > > >         pioh = 0x5555563f7610
> > > >         ioh = 0x555556450a40
> > > > #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at
> > > > main-loop.c:495
> > > >         ret = 1
> > > >         timeout = 4294967295
> > > >         timeout_ns = 3965432
> > > > #15 0x0000555555756d3f in main_loop () at vl.c:1882
> > > >         nonblocking = false
> > > >         last_io = 0
> > > > #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
> > > >     envp=0x7fffffffe240) at vl.c:4400
> > > > ---Type <return> to continue, or q <return> to quit---
> > > >         i = 128
> > > >         snapshot = 0
> > > >         linux_boot = 0
> > > >         initrd_filename = 0x0
> > > >         kernel_filename = 0x0
> > > >         kernel_cmdline = 0x555555a48f86 ""
> > > >         boot_order = 0x555556387460 "dc"
> > > >         ds = 0x5555564b2040
> > > >         cyls = 0
> > > >         heads = 0
> > > >         secs = 0
> > > >         translation = 0
> > > >         hda_opts = 0x0
> > > >         opts = 0x5555563873b0
> > > >         machine_opts = 0x555556389010
> > > >         icount_opts = 0x0
> > > >         olist = 0x555555e57e80
> > > >         optind = 62
> > > >         optarg = 0x7fffffffe914
> > > > "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
> > > >         loadvm = 0x0
> > > >         machine_class = 0x55555637d5c0
> > > >         cpu_model = 0x0
> > > >         vga_model = 0x0
> > > >         qtest_chrdev = 0x0
> > > > ---Type <return> to continue, or q <return> to quit---
> > > >         qtest_log = 0x0
> > > >         pid_file = 0x0
> > > >         incoming = 0x0
> > > >         show_vnc_port = 0
> > > >         defconfig = true
> > > >         userconfig = true
> > > >         log_mask = 0x0
> > > >         log_file = 0x0
> > > >         mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
> > > >           realloc = 0x55555575a45a <realloc_and_trace>,
> > > >           free = 0x55555575a4c1 <free_and_trace>, calloc = 0, try_malloc
> > > > = 0,
> > > >           try_realloc = 0}
> > > >         trace_events = 0x0
> > > >         trace_file = 0x0
> > > >         default_ram_size = 134217728
> > > >         maxram_size = 2130706432
> > > >         ram_slots = 0
> > > >         vmstate_dump_file = 0x0
> > > >         main_loop_err = 0x0
> > > >         __func__ = "main"
> > > 
> > > I take a fast look in source based on calltrace and I saw this commit:
> > > http://secure-web.cisco.com/1EXVvN4KugVmCtI8RnLSX68LVqyly3ymtr7bhU7HDX8viw0fYlCBA54KE1K_VbwvaJhMDSmpeNsTiBHicuNWfTtG_XH9DP4c-7oqEb6kCcWzXKnCcQNOb9ikh4FRIBDr9R069aR0R5fdiB9q4iQSFDc4X0ttOQHu8h69rpG-X2bI/http%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dcommit%3Bh%3D37f9e258b64b3cf97c7c78df60660100c9eb5a21 
> > > xen-hvm.c: Add support for Xen access to vmport
> > > Can be the cause of regression and I must try another test reverting this
> > > commit or is not related?
> > > 
> > > Thanks for any reply anddo sorry for my bad english.
> > > 
> > > > 
> > > > Qemu crash on fedora 20 lxde (with software updates of some days ago)
> > > > boot with this backtrace:
> > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
> > > > > addr=0, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > > 73          eax = env->regs[R_EAX];
> > > > > (gdb) bt full
> > > > > #0  0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
> > > > > addr=0, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > >         s = 0x555556440a20
> > > > >         cs = 0x0
> > > > >         cpu = 0x0
> > > > >         __func__ = "vmport_ioport_read"
> > > > >         env = 0x8250
> > > > >         command = 0 '\000'
> > > > >         eax = 0
> > > > > #1  0x0000555555655b9c in memory_region_read_accessor
> > > > > (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0,
> > > > > mask=4294967295)
> > > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
> > > > >         tmp = 0
> > > > > #2  0x0000555555655e8f in access_with_adjusted_size (addr=0,
> > > > > value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
> > > > >     access=0x555555655b3a <memory_region_read_accessor>,
> > > > > mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
> > > > >         access_mask = 4294967295
> > > > >         access_size = 4
> > > > >         i = 0
> > > > > #3  0x0000555555658cc1 in memory_region_dispatch_read1
> > > > > (mr=0x555556440aa8, addr=0, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
> > > > >         data = 0
> > > > > #4  0x0000555555658d89 in memory_region_dispatch_read
> > > > > (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> > > > > No locals.
> > > > > #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0,
> > > > > pval=0x7fffffffd998, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> > > > > No locals.
> > > > > #6  0x0000555555609fae in address_space_rw (as=0x555555eae840,
> > > > > addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4,
> > > > > is_write=false)
> > > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
> > > > >         l = 4
> > > > >         ptr = 0x0
> > > > >         val = 7964229952888770560
> > > > >         addr1 = 0
> > > > >         mr = 0x555556440aa8
> > > > >         error = false
> > > > > #7  0x000055555560a173 in address_space_read (as=0x555555eae840,
> > > > > addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
> > > > > No locals.
> > > > > #8  0x000055555564fac7 in cpu_inl (addr=22104) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
> > > > >         buf = "\377\377\377\377"
> > > > >         val = 21845
> > > > > #9  0x000055555567084b in do_inp (addr=22104, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> > > > > No locals.
> > > > > #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
> > > > >         i = 0
> > > > > #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590,
> > > > > req=0x7ffff7ff3000) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > No locals.
> > > > > #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
> > > > >         state = 0x5555563c1590
> > > > >         req = 0x7ffff7ff3000
> > > > > #13 0x000055555596d874 in qemu_iohandler_poll (pollfds=0x555556388a30,
> > > > > ret=1) at iohandler.c:143
> > > > >         revents = 1
> > > > >         pioh = 0x5555563f3c90
> > > > >         ioh = 0x555556515f80
> > > > > #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at
> > > > > main-loop.c:495
> > > > >         ret = 1
> > > > >         timeout = 4294967295
> > > > >         timeout_ns = 3418165
> > > > > #15 0x00005555557567b7 in main_loop () at vl.c:1882
> > > > >         nonblocking = false
> > > > >         last_io = 1
> > > > > #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038,
> > > > > envp=0x7fffffffe230) at vl.c:4400
> > > > >         i = 128
> > > > >         snapshot = 0
> > > > >         linux_boot = 0
> > > > >         initrd_filename = 0x0
> > > > >         kernel_filename = 0x0
> > > > >         kernel_cmdline = 0x555555a485c6 ""
> > > > >         boot_order = 0x5555563864e0 "dc"
> > > > >         ds = 0x5555564c71b0
> > > > >         cyls = 0
> > > > >         heads = 0
> > > > >         secs = 0
> > > > >         translation = 0
> > > > >         hda_opts = 0x0
> > > > >         opts = 0x555556386430
> > > > >         machine_opts = 0x555556388090
> > > > >         icount_opts = 0x0
> > > > >         olist = 0x555555e56da0
> > > > >         optind = 62
> > > > >         optarg = 0x7fffffffe914
> > > > > "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
> > > > >         loadvm = 0x0
> > > > >         machine_class = 0x55555637c5c0
> > > > >         cpu_model = 0x0
> > > > >         vga_model = 0x0
> > > > >         qtest_chrdev = 0x0
> > > > > ---Type <return> to continue, or q <return> to quit---
> > > > >         qtest_log = 0x0
> > > > >         pid_file = 0x0
> > > > >         incoming = 0x0
> > > > >         show_vnc_port = 0
> > > > >         defconfig = true
> > > > >         userconfig = true
> > > > >         log_mask = 0x0
> > > > >         log_file = 0x0
> > > > >         mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>,
> > > > > realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39
> > > > > <free_and_trace>, calloc = 0,
> > > > >           try_malloc = 0, try_realloc = 0}
> > > > >         trace_events = 0x0
> > > > >         trace_file = 0x0
> > > > >         default_ram_size = 134217728
> > > > >         maxram_size = 2013265920
> > > > >         ram_slots = 0
> > > > >         vmstate_dump_file = 0x0
> > > > >         main_loop_err = 0x0
> > > > >         __func__ = "main"
> > > > 
> > > > 
> > > > > xl -vvv create /etc/xen/FEDORA19.cfg
> > > > > Parsing config from /etc/xen/FEDORA19.cfg
> > > > > libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660:
> > > > > create: how=(nil) callback=(nil) poller=0xac2af0
> > > > > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
> > > > > vdev=hda spec.backend=unknown
> > > > > libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda,
> > > > > backend phy unsuitable as phys path not a block device
> > > > > libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
> > > > > vdev=hda, using backend qdisk
> > > > > libxl: debug: libxl_create.c:935:initiate_domain_create: running
> > > > > bootloader
> > > > > libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV
> > > > > domain, skipping bootloader
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac32f8: deregister unregistered
> > > > > xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
> > > > > xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
> > > > > xc: detail: VIRTUAL MEMORY ARRANGEMENT:
> > > > > xc: detail:   Loader: 0000000000100000->000000000036b324
> > > > > xc: detail:   Modules: 0000000000000000->0000000000000000
> > > > > xc: detail:   TOTAL: 0000000000000000->0000000078000000
> > > > > xc: detail:   ENTRY:    0000000000100000
> > > > > xc: detail: PHYSICAL MEMORY ALLOCATION:
> > > > > xc: detail:   4KB PAGES: 0x0000000000000200
> > > > > xc: detail:   2MB PAGES: 0x00000000000003bf
> > > > > xc: detail:   1GB PAGES: 0x0000000000000000
> > > > > xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 ->
> > > > > 0x7f1f975012b0
> > > > > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
> > > > > vdev=hda spec.backend=qdisk
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac4ad0: deregister unregistered
> > > > > libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning
> > > > > device-model /usr/lib/xen/bin/qemu-gdb with arguments:
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > /usr/lib/xen/bin/qemu-gdb
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > chardev=libxl-cmd,mode=control
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: FEDORA
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -spice
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > spicevmc,id=vdagent,name=vdagent
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > virtserialport,chardev=vdagent,name=com.redhat.spice.0
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > qxl-vga,vram_size_mb=64,ram_size_mb=64
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on 
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > spicevmc,name=usbredir,id=usbrc1
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > usb-redir,chardev=usbrc1,id=usbrc1
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > spicevmc,name=usbredir,id=usbrc2
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > usb-redir,chardev=usbrc2,id=usbrc2
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > spicevmc,name=usbredir,id=usbrc3
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > usb-redir,chardev=usbrc3,id=usbrc3
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > spicevmc,name=usbredir,id=usbrc4
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > usb-redir,chardev=usbrc4,id=usbrc4
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -netdev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -drive
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
> > > > > libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
> > > > > w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
> > > > > register slotnum=3
> > > > > libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660:
> > > > > inprogress: poller=0xac2af0, flags=i
> > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
> > > > > wpath=/local/domain/0/device-model/9/state token=3/0: event
> > > > > epath=/local/domain/0/device-model/9/state
> > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
> > > > > wpath=/local/domain/0/device-model/9/state token=3/0: event
> > > > > epath=/local/domain/0/device-model/9/state
> > > > > libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
> > > > > deregister slotnum=3
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac3558: deregister unregistered
> > > > > libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to
> > > > > /var/run/xen/qmp-libxl-9
> > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
> > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
> > > > >     "execute": "qmp_capabilities",
> > > > >     "id": 1
> > > > > }
> > > > > '
> > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > return
> > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
> > > > >     "execute": "query-chardev",
> > > > >     "id": 2
> > > > > }
> > > > > '
> > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > return
> > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
> > > > >     "execute": "query-vnc",
> > > > >     "id": 3
> > > > > }
> > > > > '
> > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > return
> > > > > libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
> > > > > w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
> > > > > register slotnum=3
> > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
> > > > > wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
> > > > > epath=/local/domain/0/backend/vif/9/0/state
> > > > > libxl: debug: libxl_event.c:810:devstate_watch_callback: backend
> > > > > /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting
> > > > > state 1
> > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
> > > > > wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
> > > > > epath=/local/domain/0/backend/vif/9/0/state
> > > > > libxl: debug: libxl_event.c:806:devstate_watch_callback: backend
> > > > > /local/domain/0/backend/vif/9/0/state wanted state 2 ok
> > > > > libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
> > > > > deregister slotnum=3
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac8368: deregister unregistered
> > > > > libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
> > > > > script: /etc/xen/scripts/vif-bridge online
> > > > > libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to
> > > > > execute: /etc/xen/scripts/vif-bridge online
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac83f0: deregister unregistered
> > > > > libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
> > > > > script: /etc/xen/scripts/vif-bridge add
> > > > > libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to
> > > > > execute: /etc/xen/scripts/vif-bridge add
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac83f0: deregister unregistered
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac83f0: deregister unregistered
> > > > > libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao
> > > > > 0xac2660: progress report: ignored
> > > > > libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660:
> > > > > complete, rc=0
> > > > > libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660:
> > > > > destroy
> > > > > xc: debug: hypercall buffer: total allocations:704 total releases:704
> > > > > xc: debug: hypercall buffer: current allocations:0 maximum
> > > > > allocations:4
> > > > > xc: debug: hypercall buffer: cache current size:4
> > > > > xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
> > > > > xc: debug: hypercall buffer: total allocations:0 total releases:0
> > > > > xc: debug: hypercall buffer: current allocations:0 maximum
> > > > > allocations:0
> > > > > xc: debug: hypercall buffer: cache current size:0
> > > > > xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
> > > > 
> > > > xl dmesg
> > > > > (d9) HVM Loader
> > > > > (d9) Detected Xen v4.5.0-rc
> > > > > (d9) Xenbus rings @0xfeffc000, event channel 1
> > > > > (d9) System requested SeaBIOS
> > > > > (d9) CPU speed is 2660 MHz
> > > > > (d9) Relocating guest memory for lowmem MMIO space disabled
> > > > > (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
> > > > > (d9) PCI-ISA link 0 routed to IRQ5
> > > > > (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
> > > > > (d9) PCI-ISA link 1 routed to IRQ10
> > > > > (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
> > > > > (d9) PCI-ISA link 2 routed to IRQ11
> > > > > (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
> > > > > (d9) PCI-ISA link 3 routed to IRQ5
> > > > > (d9) pci dev 01:3 INTA->IRQ10
> > > > > (d9) pci dev 02:0 INTA->IRQ11
> > > > > (d9) pci dev 03:0 INTA->IRQ5
> > > > > (d9) pci dev 04:0 INTA->IRQ5
> > > > > (d9) pci dev 05:0 INTA->IRQ10
> > > > > (d9) pci dev 06:0 INTA->IRQ11
> > > > > (d9) pci dev 1d:0 INTA->IRQ10
> > > > > (d9) pci dev 1d:1 INTB->IRQ11
> > > > > (d9) pci dev 1d:2 INTC->IRQ5
> > > > > (d9) pci dev 1d:7 INTD->IRQ5
> > > > > (d9) No RAM in high memory; setting high_mem resource base to
> > > > > 100000000
> > > > > (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
> > > > > (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
> > > > > (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
> > > > > (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
> > > > > (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
> > > > > (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
> > > > > (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
> > > > > (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
> > > > > (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
> > > > > (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
> > > > > (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
> > > > > (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
> > > > > (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
> > > > > (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
> > > > > (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
> > > > > (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
> > > > > (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
> > > > > (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
> > > > > (d9) Multiprocessor initialisation:
> > > > > (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ...
> > > > > done.
> > > > > (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ...
> > > > > done.
> > > > > (d9) Testing HVM environment:
> > > > > (d9)  - REP INSB across page boundaries ... passed
> > > > > (d9)  - GS base MSRs and SWAPGS ... passed
> > > > > (d9) Passed 2 of 2 tests
> > > > > (d9) Writing SMBIOS tables ...
> > > > > (d9) Loading SeaBIOS ...
> > > > > (d9) Creating MP tables ...
> > > > > (d9) Loading ACPI ...
> > > > > (d9) S3 disabled
> > > > > (d9) S4 disabled
> > > > > (d9) vm86 TSS at fc00a100
> > > > > (d9) BIOS map:
> > > > > (d9)  10000-100d3: Scratch space
> > > > > (d9)  c0000-fffff: Main BIOS
> > > > > (d9) E820 table:
> > > > > (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> > > > > (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
> > > > > (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
> > > > > (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
> > > > > (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
> > > > > (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> > > > > (d9) Invoking SeaBIOS ...
> > > > > (d9) SeaBIOS (version
> > > > > debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> > > > > (d9)
> > > > > (d9) Found Xen hypervisor signature at 40000000
> > > > > (d9) Running on QEMU (i440fx)
> > > > > (d9) xen: copy e820...
> > > > > (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
> > > > > (d9) CPU Mhz=2660
> > > > > (d9) Found 13 PCI devices (max PCI bus is 00)
> > > > > (d9) Allocated Xen hypercall page at 77fff000
> > > > > (d9) Detected Xen v4.5.0-rc
> > > > > (d9) xen: copy BIOS tables...
> > > > > (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
> > > > > (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
> > > > > (d9) Copying PIR from 0x00010030 to 0x000f0dc0
> > > > > (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
> > > > > (d9) Using pmtimer, ioport 0xb008
> > > > > (d9) Scan for VGA option rom
> > > > > (d9) Running option rom at c000:0003
> > > > > (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
> > > > > (d9) pmm call arg1=0
> > > > > (d9) Turning on vga text mode console
> > > > > (d9) SeaBIOS (version
> > > > > debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> > > > > (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
> > > > > (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
> > > > > (d9) Found 0 lpt ports
> > > > > (d9) Found 0 serial ports
> > > > > (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> > > > > (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> > > > > (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
> > > > > (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> > > > > (d9) UHCI init on dev 00:1d.0 (io=c240)
> > > > > (d9) UHCI init on dev 00:1d.1 (io=c260)
> > > > > (d9) UHCI init on dev 00:1d.2 (io=c280)
> > > > > (d9) PS2 keyboard initialized
> > > > > (d9) All threads complete.
> > > > > (d9) Scan for option roms
> > > > > (d9) Running option rom at c980:0003
> > > > > (d9) pmm call arg1=1
> > > > > (d9) pmm call arg1=0
> > > > > (d9) pmm call arg1=1
> > > > > (d9) pmm call arg1=0
> > > > > (d9) Searching bootorder for: /pci@i0cf8/*@6
> > > > > (d9)
> > > > > (d9) Press F12 for boot menu.
> > > > > (d9)
> > > > > (d9) Searching bootorder for: HALT
> > > > > (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba
> > > > > LCHS=1024/255/63 s=20480000
> > > > > (d9) Space available for UMB: ca800-ef000, f0000-f0d40
> > > > > (d9) Returned 258048 bytes of ZoneHigh
> > > > > (d9) e820 map has 6 items:
> > > > > (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
> > > > > (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
> > > > > (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
> > > > > (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
> > > > > (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
> > > > > (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
> > > > > (d9) enter handle_19:
> > > > > (d9)   NULL
> > > > > (d9) Booting from Hard Disk...
> > > > > (d9) Booting from 0000:7c00
> > > > > (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
> > > > > (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
> > > > > (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
> > > > > (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
> > > > > (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
> > > > 
> > > > domU's xl cfg:
> > > > > name='FEDORA'
> > > > > builder="hvm"
> > > > > device_model_override="/usr/lib/xen/bin/qemu-gdb"
> > > > > memory=2048
> > > > > vcpus=2
> > > > > acpi_s3=0
> > > > > acpi_s4=0
> > > > > vif=['bridge=xenbr0']
> > > > > disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
> > > > > boot='dc'
> > > > > device_model_version='qemu-xen'
> > > > > vnc=0
> > > > > keymap="it"
> > > > > vga="qxl"
> > > > > spice=1
> > > > > spicehost='0.0.0.0'
> > > > > spiceport=6005
> > > > > spicedisable_ticketing=1
> > > > > spicevdagent=1
> > > > > spice_clipboard_sharing=0
> > > > > spiceusbredirection=4
> > > > > soundhw="hda"
> > > > 
> > > > I tested also with stdvga instead of qxl vga but qemu crash always on
> > > > fedora boot with same error.
> > > > 
> > > > If you need more informations/tests tell me and I'll post them.
> > > > 
> > > > Thanks for any reply and sorry for my bad english.
> > > > 
> > > 
> > > 
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 15:53:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 15:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7ZG-0001ju-Vp; Wed, 19 Nov 2014 15:53: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@citrix.com>) id 1Xr7ZF-0001jp-51
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 15:53:17 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	69/BF-29352-CECBC645; Wed, 19 Nov 2014 15:53:16 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416412390!12270510!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13642 invoked from network); 19 Nov 2014 15:53:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 15:53:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194436994"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 10:53:02 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr7Yz-0005e9-N0;
	Wed, 19 Nov 2014 15:53:01 +0000
Date: Wed, 19 Nov 2014 15:52:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
In-Reply-To: <546CBA8B.2090903@m2r.biz>
Message-ID: <alpine.DEB.2.02.1411191551120.12596@kaball.uk.xensource.com>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
	<546CAFB1.8070904@terremark.com> <546CBA8B.2090903@m2r.biz>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Don Slutz <dslutz@verizon.com>, anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org
Subject: Re: [Xen-devel] [Qemu-devel] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Fabio Fantoni wrote:
> Il 19/11/2014 15:56, Don Slutz ha scritto:
> > I think I know what is happening here.  But you are pointing at the wrong
> > change.
> > 
> > commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
> > 
> > Is what I am guessing at this time is the issue.  I think that xen_enabled()
> > is
> > returning false in pc_machine_initfn.  Where as in pc_init1 is is returning
> > true.
> > 
> > I am thinking that:
> > 
> > 
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > index 7bb97a4..3268c29 100644
> > --- a/hw/i386/pc_piix.c
> > +++ b/hw/i386/pc_piix.c
> > @@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
> >      .desc = "Xen Fully-virtualized PC",
> >      .init = pc_xen_hvm_init,
> >      .max_cpus = HVM_MAX_VCPUS,
> > -    .default_machine_opts = "accel=xen",
> > +    .default_machine_opts = "accel=xen,vmport=off",
> >      .hot_add_cpu = pc_hot_add_cpu,
> >  };
> >  #endif
> > 
> > Will fix your issue. I have not tested this yet.
> 
> Tested now and it solves regression of linux hvm domUs with qemu 2.2, thanks.
> I think that I'm not the only with this regression and that this patch (or a
> fix to the cause in vmport) should be applied before qemu 2.2 final.

Don,
please submit a proper patch with a Signed-off-by.

Thanks!

- Stefano

> > 
> >     -Don Slutz
> > 
> > 
> > On 11/19/14 09:04, Fabio Fantoni wrote:
> > > Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
> > > > dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid leaf
> > > > with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, and
> > > > qemu 2.2 from spice git (spice/next commit
> > > > e779fa0a715530311e6f59fc8adb0f6eca914a89):
> > > > https://github.com/Fantu/Xen/commits/rebase/m2r-staging
> > > 
> > > I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the full
> > > backtrace of latest test:
> > > > Program received signal SIGSEGV, Segmentation fault.
> > > > 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, addr=0,
> > > >     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > 73          eax = env->regs[R_EAX];
> > > > (gdb) bt full
> > > > #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
> > > > addr=0,
> > > >     size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > >         s = 0x5555564443a0
> > > >         cs = 0x0
> > > >         cpu = 0x0
> > > >         __func__ = "vmport_ioport_read"
> > > >         env = 0x8250
> > > >         command = 0 '\000'
> > > >         eax = 0
> > > > #1  0x0000555555655fc4 in memory_region_read_accessor
> > > > (mr=0x555556444428,
> > > >     addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
> > > >         tmp = 0
> > > > #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
> > > >     value=0x7fffffffd8d0, size=4, access_size_min=4, access_size_max=4,
> > > >     access=0x555555655f62 <memory_region_read_accessor>,
> > > > mr=0x555556444428)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
> > > >         access_mask = 4294967295
> > > >         access_size = 4
> > > >         i = 0
> > > > #3  0x00005555556590e9 in memory_region_dispatch_read1
> > > > (mr=0x555556444428,
> > > >     addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
> > > >         data = 0
> > > > #4  0x00005555556591b1 in memory_region_dispatch_read
> > > > (mr=0x555556444428,
> > > >     addr=0, pval=0x7fffffffd9a8, size=4)
> > > > ---Type <return> to continue, or q <return> to quit---
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> > > > No locals.
> > > > #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
> > > >     pval=0x7fffffffd9a8, size=4)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> > > > No locals.
> > > > #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920,
> > > > addr=22104,
> > > >     buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
> > > >         l = 4
> > > >         ptr = 0x555555a92d87 "%s/%d:\n"
> > > >         val = 7852232130387826944
> > > >         addr1 = 0
> > > >         mr = 0x555556444428
> > > >         error = false
> > > > #7  0x000055555560a38f in address_space_read (as=0x555555eaf920,
> > > > addr=22104,
> > > >     buf=0x7fffffffda50 "\377\377\377\377", len=4)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
> > > > No locals.
> > > > #8  0x000055555564fd4b in cpu_inl (addr=22104)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
> > > >         buf = "\377\377\377\377"
> > > >         val = 21845
> > > > #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> > > > ---Type <return> to continue, or q <return> to quit---
> > > > No locals.
> > > > #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
> > > >         i = 1
> > > > #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
> > > >     req=0x7ffff7ff3020) at
> > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> > > > No locals.
> > > > #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
> > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
> > > >         state = 0x5555563c2510
> > > >         req = 0x7ffff7ff3020
> > > > #13 0x000055555596e240 in qemu_iohandler_poll (pollfds=0x555556389a30,
> > > > ret=1)
> > > >     at iohandler.c:143
> > > >         revents = 1
> > > >         pioh = 0x5555563f7610
> > > >         ioh = 0x555556450a40
> > > > #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at
> > > > main-loop.c:495
> > > >         ret = 1
> > > >         timeout = 4294967295
> > > >         timeout_ns = 3965432
> > > > #15 0x0000555555756d3f in main_loop () at vl.c:1882
> > > >         nonblocking = false
> > > >         last_io = 0
> > > > #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
> > > >     envp=0x7fffffffe240) at vl.c:4400
> > > > ---Type <return> to continue, or q <return> to quit---
> > > >         i = 128
> > > >         snapshot = 0
> > > >         linux_boot = 0
> > > >         initrd_filename = 0x0
> > > >         kernel_filename = 0x0
> > > >         kernel_cmdline = 0x555555a48f86 ""
> > > >         boot_order = 0x555556387460 "dc"
> > > >         ds = 0x5555564b2040
> > > >         cyls = 0
> > > >         heads = 0
> > > >         secs = 0
> > > >         translation = 0
> > > >         hda_opts = 0x0
> > > >         opts = 0x5555563873b0
> > > >         machine_opts = 0x555556389010
> > > >         icount_opts = 0x0
> > > >         olist = 0x555555e57e80
> > > >         optind = 62
> > > >         optarg = 0x7fffffffe914
> > > > "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
> > > >         loadvm = 0x0
> > > >         machine_class = 0x55555637d5c0
> > > >         cpu_model = 0x0
> > > >         vga_model = 0x0
> > > >         qtest_chrdev = 0x0
> > > > ---Type <return> to continue, or q <return> to quit---
> > > >         qtest_log = 0x0
> > > >         pid_file = 0x0
> > > >         incoming = 0x0
> > > >         show_vnc_port = 0
> > > >         defconfig = true
> > > >         userconfig = true
> > > >         log_mask = 0x0
> > > >         log_file = 0x0
> > > >         mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
> > > >           realloc = 0x55555575a45a <realloc_and_trace>,
> > > >           free = 0x55555575a4c1 <free_and_trace>, calloc = 0, try_malloc
> > > > = 0,
> > > >           try_realloc = 0}
> > > >         trace_events = 0x0
> > > >         trace_file = 0x0
> > > >         default_ram_size = 134217728
> > > >         maxram_size = 2130706432
> > > >         ram_slots = 0
> > > >         vmstate_dump_file = 0x0
> > > >         main_loop_err = 0x0
> > > >         __func__ = "main"
> > > 
> > > I take a fast look in source based on calltrace and I saw this commit:
> > > http://secure-web.cisco.com/1EXVvN4KugVmCtI8RnLSX68LVqyly3ymtr7bhU7HDX8viw0fYlCBA54KE1K_VbwvaJhMDSmpeNsTiBHicuNWfTtG_XH9DP4c-7oqEb6kCcWzXKnCcQNOb9ikh4FRIBDr9R069aR0R5fdiB9q4iQSFDc4X0ttOQHu8h69rpG-X2bI/http%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dcommit%3Bh%3D37f9e258b64b3cf97c7c78df60660100c9eb5a21 
> > > xen-hvm.c: Add support for Xen access to vmport
> > > Can be the cause of regression and I must try another test reverting this
> > > commit or is not related?
> > > 
> > > Thanks for any reply anddo sorry for my bad english.
> > > 
> > > > 
> > > > Qemu crash on fedora 20 lxde (with software updates of some days ago)
> > > > boot with this backtrace:
> > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
> > > > > addr=0, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > > 73          eax = env->regs[R_EAX];
> > > > > (gdb) bt full
> > > > > #0  0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
> > > > > addr=0, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > >         s = 0x555556440a20
> > > > >         cs = 0x0
> > > > >         cpu = 0x0
> > > > >         __func__ = "vmport_ioport_read"
> > > > >         env = 0x8250
> > > > >         command = 0 '\000'
> > > > >         eax = 0
> > > > > #1  0x0000555555655b9c in memory_region_read_accessor
> > > > > (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0,
> > > > > mask=4294967295)
> > > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
> > > > >         tmp = 0
> > > > > #2  0x0000555555655e8f in access_with_adjusted_size (addr=0,
> > > > > value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
> > > > >     access=0x555555655b3a <memory_region_read_accessor>,
> > > > > mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
> > > > >         access_mask = 4294967295
> > > > >         access_size = 4
> > > > >         i = 0
> > > > > #3  0x0000555555658cc1 in memory_region_dispatch_read1
> > > > > (mr=0x555556440aa8, addr=0, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
> > > > >         data = 0
> > > > > #4  0x0000555555658d89 in memory_region_dispatch_read
> > > > > (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> > > > > No locals.
> > > > > #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0,
> > > > > pval=0x7fffffffd998, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> > > > > No locals.
> > > > > #6  0x0000555555609fae in address_space_rw (as=0x555555eae840,
> > > > > addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4,
> > > > > is_write=false)
> > > > >     at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
> > > > >         l = 4
> > > > >         ptr = 0x0
> > > > >         val = 7964229952888770560
> > > > >         addr1 = 0
> > > > >         mr = 0x555556440aa8
> > > > >         error = false
> > > > > #7  0x000055555560a173 in address_space_read (as=0x555555eae840,
> > > > > addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
> > > > > No locals.
> > > > > #8  0x000055555564fac7 in cpu_inl (addr=22104) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
> > > > >         buf = "\377\377\377\377"
> > > > >         val = 21845
> > > > > #9  0x000055555567084b in do_inp (addr=22104, size=4) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> > > > > No locals.
> > > > > #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
> > > > >         i = 0
> > > > > #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590,
> > > > > req=0x7ffff7ff3000) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > No locals.
> > > > > #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) at
> > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
> > > > >         state = 0x5555563c1590
> > > > >         req = 0x7ffff7ff3000
> > > > > #13 0x000055555596d874 in qemu_iohandler_poll (pollfds=0x555556388a30,
> > > > > ret=1) at iohandler.c:143
> > > > >         revents = 1
> > > > >         pioh = 0x5555563f3c90
> > > > >         ioh = 0x555556515f80
> > > > > #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at
> > > > > main-loop.c:495
> > > > >         ret = 1
> > > > >         timeout = 4294967295
> > > > >         timeout_ns = 3418165
> > > > > #15 0x00005555557567b7 in main_loop () at vl.c:1882
> > > > >         nonblocking = false
> > > > >         last_io = 1
> > > > > #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038,
> > > > > envp=0x7fffffffe230) at vl.c:4400
> > > > >         i = 128
> > > > >         snapshot = 0
> > > > >         linux_boot = 0
> > > > >         initrd_filename = 0x0
> > > > >         kernel_filename = 0x0
> > > > >         kernel_cmdline = 0x555555a485c6 ""
> > > > >         boot_order = 0x5555563864e0 "dc"
> > > > >         ds = 0x5555564c71b0
> > > > >         cyls = 0
> > > > >         heads = 0
> > > > >         secs = 0
> > > > >         translation = 0
> > > > >         hda_opts = 0x0
> > > > >         opts = 0x555556386430
> > > > >         machine_opts = 0x555556388090
> > > > >         icount_opts = 0x0
> > > > >         olist = 0x555555e56da0
> > > > >         optind = 62
> > > > >         optarg = 0x7fffffffe914
> > > > > "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
> > > > >         loadvm = 0x0
> > > > >         machine_class = 0x55555637c5c0
> > > > >         cpu_model = 0x0
> > > > >         vga_model = 0x0
> > > > >         qtest_chrdev = 0x0
> > > > > ---Type <return> to continue, or q <return> to quit---
> > > > >         qtest_log = 0x0
> > > > >         pid_file = 0x0
> > > > >         incoming = 0x0
> > > > >         show_vnc_port = 0
> > > > >         defconfig = true
> > > > >         userconfig = true
> > > > >         log_mask = 0x0
> > > > >         log_file = 0x0
> > > > >         mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>,
> > > > > realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39
> > > > > <free_and_trace>, calloc = 0,
> > > > >           try_malloc = 0, try_realloc = 0}
> > > > >         trace_events = 0x0
> > > > >         trace_file = 0x0
> > > > >         default_ram_size = 134217728
> > > > >         maxram_size = 2013265920
> > > > >         ram_slots = 0
> > > > >         vmstate_dump_file = 0x0
> > > > >         main_loop_err = 0x0
> > > > >         __func__ = "main"
> > > > 
> > > > 
> > > > > xl -vvv create /etc/xen/FEDORA19.cfg
> > > > > Parsing config from /etc/xen/FEDORA19.cfg
> > > > > libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660:
> > > > > create: how=(nil) callback=(nil) poller=0xac2af0
> > > > > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
> > > > > vdev=hda spec.backend=unknown
> > > > > libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda,
> > > > > backend phy unsuitable as phys path not a block device
> > > > > libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
> > > > > vdev=hda, using backend qdisk
> > > > > libxl: debug: libxl_create.c:935:initiate_domain_create: running
> > > > > bootloader
> > > > > libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV
> > > > > domain, skipping bootloader
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac32f8: deregister unregistered
> > > > > xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
> > > > > xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
> > > > > xc: detail: VIRTUAL MEMORY ARRANGEMENT:
> > > > > xc: detail:   Loader: 0000000000100000->000000000036b324
> > > > > xc: detail:   Modules: 0000000000000000->0000000000000000
> > > > > xc: detail:   TOTAL: 0000000000000000->0000000078000000
> > > > > xc: detail:   ENTRY:    0000000000100000
> > > > > xc: detail: PHYSICAL MEMORY ALLOCATION:
> > > > > xc: detail:   4KB PAGES: 0x0000000000000200
> > > > > xc: detail:   2MB PAGES: 0x00000000000003bf
> > > > > xc: detail:   1GB PAGES: 0x0000000000000000
> > > > > xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 ->
> > > > > 0x7f1f975012b0
> > > > > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
> > > > > vdev=hda spec.backend=qdisk
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac4ad0: deregister unregistered
> > > > > libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning
> > > > > device-model /usr/lib/xen/bin/qemu-gdb with arguments:
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > /usr/lib/xen/bin/qemu-gdb
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > chardev=libxl-cmd,mode=control
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: FEDORA
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -spice
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > spicevmc,id=vdagent,name=vdagent
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > virtserialport,chardev=vdagent,name=com.redhat.spice.0
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > qxl-vga,vram_size_mb=64,ram_size_mb=64
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on 
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > spicevmc,name=usbredir,id=usbrc1
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > usb-redir,chardev=usbrc1,id=usbrc1
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > spicevmc,name=usbredir,id=usbrc2
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > usb-redir,chardev=usbrc2,id=usbrc2
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > spicevmc,name=usbredir,id=usbrc3
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > usb-redir,chardev=usbrc3,id=usbrc3
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > spicevmc,name=usbredir,id=usbrc4
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > usb-redir,chardev=usbrc4,id=usbrc4
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -netdev
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -drive
> > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
> > > > > libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
> > > > > w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
> > > > > register slotnum=3
> > > > > libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660:
> > > > > inprogress: poller=0xac2af0, flags=i
> > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
> > > > > wpath=/local/domain/0/device-model/9/state token=3/0: event
> > > > > epath=/local/domain/0/device-model/9/state
> > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
> > > > > wpath=/local/domain/0/device-model/9/state token=3/0: event
> > > > > epath=/local/domain/0/device-model/9/state
> > > > > libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
> > > > > deregister slotnum=3
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac3558: deregister unregistered
> > > > > libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to
> > > > > /var/run/xen/qmp-libxl-9
> > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
> > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
> > > > >     "execute": "qmp_capabilities",
> > > > >     "id": 1
> > > > > }
> > > > > '
> > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > return
> > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
> > > > >     "execute": "query-chardev",
> > > > >     "id": 2
> > > > > }
> > > > > '
> > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > return
> > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
> > > > >     "execute": "query-vnc",
> > > > >     "id": 3
> > > > > }
> > > > > '
> > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > return
> > > > > libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
> > > > > w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
> > > > > register slotnum=3
> > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
> > > > > wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
> > > > > epath=/local/domain/0/backend/vif/9/0/state
> > > > > libxl: debug: libxl_event.c:810:devstate_watch_callback: backend
> > > > > /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting
> > > > > state 1
> > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
> > > > > wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
> > > > > epath=/local/domain/0/backend/vif/9/0/state
> > > > > libxl: debug: libxl_event.c:806:devstate_watch_callback: backend
> > > > > /local/domain/0/backend/vif/9/0/state wanted state 2 ok
> > > > > libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
> > > > > deregister slotnum=3
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac8368: deregister unregistered
> > > > > libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
> > > > > script: /etc/xen/scripts/vif-bridge online
> > > > > libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to
> > > > > execute: /etc/xen/scripts/vif-bridge online
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac83f0: deregister unregistered
> > > > > libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
> > > > > script: /etc/xen/scripts/vif-bridge add
> > > > > libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to
> > > > > execute: /etc/xen/scripts/vif-bridge add
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac83f0: deregister unregistered
> > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
> > > > > w=0xac83f0: deregister unregistered
> > > > > libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao
> > > > > 0xac2660: progress report: ignored
> > > > > libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660:
> > > > > complete, rc=0
> > > > > libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660:
> > > > > destroy
> > > > > xc: debug: hypercall buffer: total allocations:704 total releases:704
> > > > > xc: debug: hypercall buffer: current allocations:0 maximum
> > > > > allocations:4
> > > > > xc: debug: hypercall buffer: cache current size:4
> > > > > xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
> > > > > xc: debug: hypercall buffer: total allocations:0 total releases:0
> > > > > xc: debug: hypercall buffer: current allocations:0 maximum
> > > > > allocations:0
> > > > > xc: debug: hypercall buffer: cache current size:0
> > > > > xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
> > > > 
> > > > xl dmesg
> > > > > (d9) HVM Loader
> > > > > (d9) Detected Xen v4.5.0-rc
> > > > > (d9) Xenbus rings @0xfeffc000, event channel 1
> > > > > (d9) System requested SeaBIOS
> > > > > (d9) CPU speed is 2660 MHz
> > > > > (d9) Relocating guest memory for lowmem MMIO space disabled
> > > > > (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
> > > > > (d9) PCI-ISA link 0 routed to IRQ5
> > > > > (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
> > > > > (d9) PCI-ISA link 1 routed to IRQ10
> > > > > (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
> > > > > (d9) PCI-ISA link 2 routed to IRQ11
> > > > > (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
> > > > > (d9) PCI-ISA link 3 routed to IRQ5
> > > > > (d9) pci dev 01:3 INTA->IRQ10
> > > > > (d9) pci dev 02:0 INTA->IRQ11
> > > > > (d9) pci dev 03:0 INTA->IRQ5
> > > > > (d9) pci dev 04:0 INTA->IRQ5
> > > > > (d9) pci dev 05:0 INTA->IRQ10
> > > > > (d9) pci dev 06:0 INTA->IRQ11
> > > > > (d9) pci dev 1d:0 INTA->IRQ10
> > > > > (d9) pci dev 1d:1 INTB->IRQ11
> > > > > (d9) pci dev 1d:2 INTC->IRQ5
> > > > > (d9) pci dev 1d:7 INTD->IRQ5
> > > > > (d9) No RAM in high memory; setting high_mem resource base to
> > > > > 100000000
> > > > > (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
> > > > > (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
> > > > > (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
> > > > > (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
> > > > > (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
> > > > > (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
> > > > > (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
> > > > > (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
> > > > > (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
> > > > > (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
> > > > > (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
> > > > > (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
> > > > > (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
> > > > > (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
> > > > > (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
> > > > > (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
> > > > > (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
> > > > > (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
> > > > > (d9) Multiprocessor initialisation:
> > > > > (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ...
> > > > > done.
> > > > > (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ...
> > > > > done.
> > > > > (d9) Testing HVM environment:
> > > > > (d9)  - REP INSB across page boundaries ... passed
> > > > > (d9)  - GS base MSRs and SWAPGS ... passed
> > > > > (d9) Passed 2 of 2 tests
> > > > > (d9) Writing SMBIOS tables ...
> > > > > (d9) Loading SeaBIOS ...
> > > > > (d9) Creating MP tables ...
> > > > > (d9) Loading ACPI ...
> > > > > (d9) S3 disabled
> > > > > (d9) S4 disabled
> > > > > (d9) vm86 TSS at fc00a100
> > > > > (d9) BIOS map:
> > > > > (d9)  10000-100d3: Scratch space
> > > > > (d9)  c0000-fffff: Main BIOS
> > > > > (d9) E820 table:
> > > > > (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> > > > > (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
> > > > > (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
> > > > > (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
> > > > > (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
> > > > > (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> > > > > (d9) Invoking SeaBIOS ...
> > > > > (d9) SeaBIOS (version
> > > > > debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> > > > > (d9)
> > > > > (d9) Found Xen hypervisor signature at 40000000
> > > > > (d9) Running on QEMU (i440fx)
> > > > > (d9) xen: copy e820...
> > > > > (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
> > > > > (d9) CPU Mhz=2660
> > > > > (d9) Found 13 PCI devices (max PCI bus is 00)
> > > > > (d9) Allocated Xen hypercall page at 77fff000
> > > > > (d9) Detected Xen v4.5.0-rc
> > > > > (d9) xen: copy BIOS tables...
> > > > > (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
> > > > > (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
> > > > > (d9) Copying PIR from 0x00010030 to 0x000f0dc0
> > > > > (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
> > > > > (d9) Using pmtimer, ioport 0xb008
> > > > > (d9) Scan for VGA option rom
> > > > > (d9) Running option rom at c000:0003
> > > > > (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
> > > > > (d9) pmm call arg1=0
> > > > > (d9) Turning on vga text mode console
> > > > > (d9) SeaBIOS (version
> > > > > debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> > > > > (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
> > > > > (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
> > > > > (d9) Found 0 lpt ports
> > > > > (d9) Found 0 serial ports
> > > > > (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> > > > > (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> > > > > (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
> > > > > (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> > > > > (d9) UHCI init on dev 00:1d.0 (io=c240)
> > > > > (d9) UHCI init on dev 00:1d.1 (io=c260)
> > > > > (d9) UHCI init on dev 00:1d.2 (io=c280)
> > > > > (d9) PS2 keyboard initialized
> > > > > (d9) All threads complete.
> > > > > (d9) Scan for option roms
> > > > > (d9) Running option rom at c980:0003
> > > > > (d9) pmm call arg1=1
> > > > > (d9) pmm call arg1=0
> > > > > (d9) pmm call arg1=1
> > > > > (d9) pmm call arg1=0
> > > > > (d9) Searching bootorder for: /pci@i0cf8/*@6
> > > > > (d9)
> > > > > (d9) Press F12 for boot menu.
> > > > > (d9)
> > > > > (d9) Searching bootorder for: HALT
> > > > > (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba
> > > > > LCHS=1024/255/63 s=20480000
> > > > > (d9) Space available for UMB: ca800-ef000, f0000-f0d40
> > > > > (d9) Returned 258048 bytes of ZoneHigh
> > > > > (d9) e820 map has 6 items:
> > > > > (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
> > > > > (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
> > > > > (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
> > > > > (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
> > > > > (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
> > > > > (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
> > > > > (d9) enter handle_19:
> > > > > (d9)   NULL
> > > > > (d9) Booting from Hard Disk...
> > > > > (d9) Booting from 0000:7c00
> > > > > (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
> > > > > (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
> > > > > (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
> > > > > (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
> > > > > (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
> > > > 
> > > > domU's xl cfg:
> > > > > name='FEDORA'
> > > > > builder="hvm"
> > > > > device_model_override="/usr/lib/xen/bin/qemu-gdb"
> > > > > memory=2048
> > > > > vcpus=2
> > > > > acpi_s3=0
> > > > > acpi_s4=0
> > > > > vif=['bridge=xenbr0']
> > > > > disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
> > > > > boot='dc'
> > > > > device_model_version='qemu-xen'
> > > > > vnc=0
> > > > > keymap="it"
> > > > > vga="qxl"
> > > > > spice=1
> > > > > spicehost='0.0.0.0'
> > > > > spiceport=6005
> > > > > spicedisable_ticketing=1
> > > > > spicevdagent=1
> > > > > spice_clipboard_sharing=0
> > > > > spiceusbredirection=4
> > > > > soundhw="hda"
> > > > 
> > > > I tested also with stdvga instead of qxl vga but qemu crash always on
> > > > fedora boot with same error.
> > > > 
> > > > If you need more informations/tests tell me and I'll post them.
> > > > 
> > > > Thanks for any reply and sorry for my bad english.
> > > > 
> > > 
> > > 
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:02:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7hl-0002L3-8C; Wed, 19 Nov 2014 16:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr7hj-0002Ky-AW
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:02:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	23/32-09936-AFEBC645; Wed, 19 Nov 2014 16:02:02 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416412920!13941863!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21370 invoked from network); 19 Nov 2014 16:02:01 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:02:01 -0000
Received: from mail-qc0-f181.google.com ([209.85.216.181]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGy+9wc8CMg91dFtw0g3r6J0lpYbw34f@postini.com;
	Wed, 19 Nov 2014 08:02:01 PST
Received: by mail-qc0-f181.google.com with SMTP id m20so622894qcx.40
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 08:01:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=LV7gY9JmJ1iR+LhEi8Q9xJGZFivwds9mPHGW0xASIgQ=;
	b=SDkJV3lhCAfbo2Ria59reljZQAjabNBHBLgLenOh6AG65jDIkoiHYUszwYeoXc5opA
	X+545hwkn9BdrOClgQMVCMvQI3JBdSNsyVwjPOlBbp8QE7zWj1AEge5n0HpHNCVwTMQA
	OGdhaL4UZGaNl6sLqxp8reYppSHTCj/TBCNmw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=LV7gY9JmJ1iR+LhEi8Q9xJGZFivwds9mPHGW0xASIgQ=;
	b=YDVn6savgEGyrTqHm77u+7xPMC4BBf3XrNZrJOYrn7CkABjmayhOnPv9XbjkVIT4TH
	R3jwP9j4cKsLnmFJRyUtattswX57EZRokIUiLtmHBJwm3WV/NACLXAACLul6op8o18NE
	uwjztGcE+cBEY1sKXEPyrkyEmCpKhSiPK1hSdKaiDwcA876gYRQBClGg3IH7N36S+uo6
	sPCoIffmROmcJAy7IyUSFzsBQgqlYj6BazVpnRp15PaQgZuuDIP2ifp2W91kIrrKgWWi
	kWcvL4jgM2DjNtu1SaCXPW6gaVoyuUw1TYyFRG7cRp9yIGXM3u2yOaYvCgpdM292AxTl
	/LKA==
X-Gm-Message-State: ALoCoQnCvohRc4G0a4MTX9aj6W+jq0x2QAHJbG2LEA97tn3Htu81SP+JwTyX3QL++1HOFdlScFf4CuF/M9FcFfuJ+xP1tA8K7IkjH857fscRBKzQD2lpEynMD7F4Xz6JcgZIsQJI9EcQoxZ4je1xahEstiBEhqZCFg==
X-Received: by 10.229.240.138 with SMTP id la10mr52395281qcb.13.1416412919215; 
	Wed, 19 Nov 2014 08:01:59 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.229.240.138 with SMTP id la10mr52395239qcb.13.1416412918793; 
	Wed, 19 Nov 2014 08:01:58 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 08:01:58 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 18:01:58 +0200
Message-ID: <CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi Stefano,
>> >>
>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> >> > >      else
>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> >> > >
>> >> > >  }
>> >> >
>> >> > Yes, exactly
>> >>
>> >> I tried, hang still occurs with this change
>> >
>> > We need to figure out why during the hang you still have all the LRs
>> > busy even if you are getting maintenance interrupts that should cause
>> > them to be cleared.
>> >
>>
>> I see that I have free LRs during maintenance interrupt
>>
>> (XEN) gic.c:871:d0v0 maintenance interrupt
>> (XEN) GICH_LRs (vcpu 0) mask=0
>> (XEN)    HW_LR[0]=9a015856
>> (XEN)    HW_LR[1]=0
>> (XEN)    HW_LR[2]=0
>> (XEN)    HW_LR[3]=0
>> (XEN) Inflight irq=86 lr=0
>> (XEN) Inflight irq=2 lr=255
>> (XEN) Pending irq=2
>>
>> But I see that after I got hang - maintenance interrupts are generated
>> continuously. Platform continues printing the same log till reboot.
>
> Exactly the same log? As in the one above you just pasted?
> That is very very suspicious.

Yes exactly the same log. And looks like it means that LRs are flushed
correctly.

>
> I am thinking that we are not handling GICH_HCR_UIE correctly and
> something we do in Xen, maybe writing to an LR register, might trigger a
> new maintenance interrupt immediately causing an infinite loop.
>

Yes, this is what I'm thinking about. Taking in account all collected
debug info it looks like once LRs are overloaded with SGIs -
maintenance interrupt occurs.
And then it is not handled properly, and occurs again and again - so
platform hangs inside its handler.

> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> hypervisor entry.
>

Now trying.

>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 4d2a92d..6ae8dc4 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>
> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -821,12 +823,8 @@ void gic_inject(void)
>
>      gic_restore_pending_irqs(current);
>
> -
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> -    else
> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> -
>  }
>
>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:02:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7hl-0002L3-8C; Wed, 19 Nov 2014 16:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr7hj-0002Ky-AW
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:02:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	23/32-09936-AFEBC645; Wed, 19 Nov 2014 16:02:02 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416412920!13941863!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21370 invoked from network); 19 Nov 2014 16:02:01 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:02:01 -0000
Received: from mail-qc0-f181.google.com ([209.85.216.181]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGy+9wc8CMg91dFtw0g3r6J0lpYbw34f@postini.com;
	Wed, 19 Nov 2014 08:02:01 PST
Received: by mail-qc0-f181.google.com with SMTP id m20so622894qcx.40
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 08:01:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=LV7gY9JmJ1iR+LhEi8Q9xJGZFivwds9mPHGW0xASIgQ=;
	b=SDkJV3lhCAfbo2Ria59reljZQAjabNBHBLgLenOh6AG65jDIkoiHYUszwYeoXc5opA
	X+545hwkn9BdrOClgQMVCMvQI3JBdSNsyVwjPOlBbp8QE7zWj1AEge5n0HpHNCVwTMQA
	OGdhaL4UZGaNl6sLqxp8reYppSHTCj/TBCNmw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=LV7gY9JmJ1iR+LhEi8Q9xJGZFivwds9mPHGW0xASIgQ=;
	b=YDVn6savgEGyrTqHm77u+7xPMC4BBf3XrNZrJOYrn7CkABjmayhOnPv9XbjkVIT4TH
	R3jwP9j4cKsLnmFJRyUtattswX57EZRokIUiLtmHBJwm3WV/NACLXAACLul6op8o18NE
	uwjztGcE+cBEY1sKXEPyrkyEmCpKhSiPK1hSdKaiDwcA876gYRQBClGg3IH7N36S+uo6
	sPCoIffmROmcJAy7IyUSFzsBQgqlYj6BazVpnRp15PaQgZuuDIP2ifp2W91kIrrKgWWi
	kWcvL4jgM2DjNtu1SaCXPW6gaVoyuUw1TYyFRG7cRp9yIGXM3u2yOaYvCgpdM292AxTl
	/LKA==
X-Gm-Message-State: ALoCoQnCvohRc4G0a4MTX9aj6W+jq0x2QAHJbG2LEA97tn3Htu81SP+JwTyX3QL++1HOFdlScFf4CuF/M9FcFfuJ+xP1tA8K7IkjH857fscRBKzQD2lpEynMD7F4Xz6JcgZIsQJI9EcQoxZ4je1xahEstiBEhqZCFg==
X-Received: by 10.229.240.138 with SMTP id la10mr52395281qcb.13.1416412919215; 
	Wed, 19 Nov 2014 08:01:59 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.229.240.138 with SMTP id la10mr52395239qcb.13.1416412918793; 
	Wed, 19 Nov 2014 08:01:58 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 08:01:58 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 18:01:58 +0200
Message-ID: <CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi Stefano,
>> >>
>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> >> > >      else
>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> >> > >
>> >> > >  }
>> >> >
>> >> > Yes, exactly
>> >>
>> >> I tried, hang still occurs with this change
>> >
>> > We need to figure out why during the hang you still have all the LRs
>> > busy even if you are getting maintenance interrupts that should cause
>> > them to be cleared.
>> >
>>
>> I see that I have free LRs during maintenance interrupt
>>
>> (XEN) gic.c:871:d0v0 maintenance interrupt
>> (XEN) GICH_LRs (vcpu 0) mask=0
>> (XEN)    HW_LR[0]=9a015856
>> (XEN)    HW_LR[1]=0
>> (XEN)    HW_LR[2]=0
>> (XEN)    HW_LR[3]=0
>> (XEN) Inflight irq=86 lr=0
>> (XEN) Inflight irq=2 lr=255
>> (XEN) Pending irq=2
>>
>> But I see that after I got hang - maintenance interrupts are generated
>> continuously. Platform continues printing the same log till reboot.
>
> Exactly the same log? As in the one above you just pasted?
> That is very very suspicious.

Yes exactly the same log. And looks like it means that LRs are flushed
correctly.

>
> I am thinking that we are not handling GICH_HCR_UIE correctly and
> something we do in Xen, maybe writing to an LR register, might trigger a
> new maintenance interrupt immediately causing an infinite loop.
>

Yes, this is what I'm thinking about. Taking in account all collected
debug info it looks like once LRs are overloaded with SGIs -
maintenance interrupt occurs.
And then it is not handled properly, and occurs again and again - so
platform hangs inside its handler.

> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> hypervisor entry.
>

Now trying.

>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 4d2a92d..6ae8dc4 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>
> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -821,12 +823,8 @@ void gic_inject(void)
>
>      gic_restore_pending_irqs(current);
>
> -
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> -    else
> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> -
>  }
>
>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7iG-0002RN-LD; Wed, 19 Nov 2014 16:02:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xr7iF-0002RF-PD
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:02:35 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	BD/69-22737-A1FBC645; Wed, 19 Nov 2014 16:02:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416412950!9410534!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20361 invoked from network); 19 Nov 2014 16:02:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:02:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194441027"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:02:12 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Xr7hr-0005s8-Oe;
	Wed, 19 Nov 2014 16:02:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 19 Nov 2014 16:01:58 +0000
Message-ID: <1416412921-23671-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 1/4] dma: add
	dma_get_required_mask_from_max_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 generic dma_get_required_mask() is useful even for architectures (such
as ia64) that define ARCH_HAS_GET_REQUIRED_MASK.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/base/platform.c     |   10 ++++++++--
 include/linux/dma-mapping.h |    1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b2afc29..f9f3930 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1009,8 +1009,7 @@ int __init platform_bus_init(void)
 	return error;
 }
 
-#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
-u64 dma_get_required_mask(struct device *dev)
+u64 dma_get_required_mask_from_max_pfn(struct device *dev)
 {
 	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
 	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
@@ -1028,6 +1027,13 @@ u64 dma_get_required_mask(struct device *dev)
 	}
 	return mask;
 }
+EXPORT_SYMBOL_GPL(dma_get_required_mask_from_max_pfn);
+
+#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
+u64 dma_get_required_mask(struct device *dev)
+{
+	return dma_get_required_mask_from_max_pfn(dev);
+}
 EXPORT_SYMBOL_GPL(dma_get_required_mask);
 #endif
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d3881..6e2fdfc 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -127,6 +127,7 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
 	return dma_set_mask_and_coherent(dev, mask);
 }
 
+extern u64 dma_get_required_mask_from_max_pfn(struct device *dev);
 extern u64 dma_get_required_mask(struct device *dev);
 
 #ifndef set_arch_dma_coherent_ops
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7iG-0002RN-LD; Wed, 19 Nov 2014 16:02:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xr7iF-0002RF-PD
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:02:35 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	BD/69-22737-A1FBC645; Wed, 19 Nov 2014 16:02:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416412950!9410534!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20361 invoked from network); 19 Nov 2014 16:02:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:02:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194441027"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:02:12 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Xr7hr-0005s8-Oe;
	Wed, 19 Nov 2014 16:02:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 19 Nov 2014 16:01:58 +0000
Message-ID: <1416412921-23671-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 1/4] dma: add
	dma_get_required_mask_from_max_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 generic dma_get_required_mask() is useful even for architectures (such
as ia64) that define ARCH_HAS_GET_REQUIRED_MASK.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/base/platform.c     |   10 ++++++++--
 include/linux/dma-mapping.h |    1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b2afc29..f9f3930 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1009,8 +1009,7 @@ int __init platform_bus_init(void)
 	return error;
 }
 
-#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
-u64 dma_get_required_mask(struct device *dev)
+u64 dma_get_required_mask_from_max_pfn(struct device *dev)
 {
 	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
 	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
@@ -1028,6 +1027,13 @@ u64 dma_get_required_mask(struct device *dev)
 	}
 	return mask;
 }
+EXPORT_SYMBOL_GPL(dma_get_required_mask_from_max_pfn);
+
+#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
+u64 dma_get_required_mask(struct device *dev)
+{
+	return dma_get_required_mask_from_max_pfn(dev);
+}
 EXPORT_SYMBOL_GPL(dma_get_required_mask);
 #endif
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d3881..6e2fdfc 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -127,6 +127,7 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
 	return dma_set_mask_and_coherent(dev, mask);
 }
 
+extern u64 dma_get_required_mask_from_max_pfn(struct device *dev);
 extern u64 dma_get_required_mask(struct device *dev);
 
 #ifndef set_arch_dma_coherent_ops
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16: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 1Xr7iI-0002S7-1E; Wed, 19 Nov 2014 16:02:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xr7iG-0002RL-Gi
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:02:36 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	0D/F2-29352-B1FBC645; Wed, 19 Nov 2014 16:02:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416412950!9410534!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20448 invoked from network); 19 Nov 2014 16:02:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:02:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194441039"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:02:12 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Xr7hr-0005s8-RH;
	Wed, 19 Nov 2014 16:02:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 19 Nov 2014 16:02:00 +0000
Message-ID: <1416412921-23671-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 3/4] x86: allow dma_get_required_mask() to be
	overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 dma_ops->get_required_mask() if provided, defaulting to
dma_get_requried_mask_from_max_pfn().

This is needed on systems (such as Xen PV guests) where the DMA
address and the physical address are not equal.

ARCH_HAS_DMA_GET_REQUIRED_MASK is defined in asm/device.h instead of
asm/dma-mapping.h because linux/dma-mapping.h uses the define before
including asm/dma-mapping.h

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/x86/include/asm/device.h |    2 ++
 arch/x86/kernel/pci-dma.c     |    8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
index 03dd729..10bc628 100644
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
 struct pdev_archdata {
 };
 
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
+
 #endif /* _ASM_X86_DEVICE_H */
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index a25e202..5154400 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -140,6 +140,14 @@ void dma_generic_free_coherent(struct device *dev, size_t size, void *vaddr,
 		free_pages((unsigned long)vaddr, get_order(size));
 }
 
+u64 dma_get_required_mask(struct device *dev)
+{
+	if (dma_ops->get_required_mask)
+		return dma_ops->get_required_mask(dev);
+	return dma_get_required_mask_from_max_pfn(dev);
+}
+EXPORT_SYMBOL_GPL(dma_get_required_mask);
+
 /*
  * See <Documentation/x86/x86_64/boot-options.txt> for the iommu kernel
  * parameter documentation.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16: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 1Xr7iI-0002S7-1E; Wed, 19 Nov 2014 16:02:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xr7iG-0002RL-Gi
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:02:36 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	0D/F2-29352-B1FBC645; Wed, 19 Nov 2014 16:02:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416412950!9410534!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20448 invoked from network); 19 Nov 2014 16:02:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:02:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194441039"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:02:12 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Xr7hr-0005s8-RH;
	Wed, 19 Nov 2014 16:02:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 19 Nov 2014 16:02:00 +0000
Message-ID: <1416412921-23671-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 3/4] x86: allow dma_get_required_mask() to be
	overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 dma_ops->get_required_mask() if provided, defaulting to
dma_get_requried_mask_from_max_pfn().

This is needed on systems (such as Xen PV guests) where the DMA
address and the physical address are not equal.

ARCH_HAS_DMA_GET_REQUIRED_MASK is defined in asm/device.h instead of
asm/dma-mapping.h because linux/dma-mapping.h uses the define before
including asm/dma-mapping.h

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/x86/include/asm/device.h |    2 ++
 arch/x86/kernel/pci-dma.c     |    8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
index 03dd729..10bc628 100644
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
 struct pdev_archdata {
 };
 
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
+
 #endif /* _ASM_X86_DEVICE_H */
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index a25e202..5154400 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -140,6 +140,14 @@ void dma_generic_free_coherent(struct device *dev, size_t size, void *vaddr,
 		free_pages((unsigned long)vaddr, get_order(size));
 }
 
+u64 dma_get_required_mask(struct device *dev)
+{
+	if (dma_ops->get_required_mask)
+		return dma_ops->get_required_mask(dev);
+	return dma_get_required_mask_from_max_pfn(dev);
+}
+EXPORT_SYMBOL_GPL(dma_get_required_mask);
+
 /*
  * See <Documentation/x86/x86_64/boot-options.txt> for the iommu kernel
  * parameter documentation.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7iJ-0002Sx-EW; Wed, 19 Nov 2014 16:02:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xr7iH-0002Rt-Mf
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:02:37 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	FC/F8-14727-D1FBC645; Wed, 19 Nov 2014 16:02:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416412950!9410534!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20627 invoked from network); 19 Nov 2014 16:02:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:02:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194441044"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:02:13 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Xr7hr-0005s8-Nv;
	Wed, 19 Nov 2014 16:02:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 19 Nov 2014 16:01:57 +0000
Message-ID: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCHv3 0/4]: dma, x86,
	xen: reduce SWIOTLB usage in Xen guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On systems where DMA addresses and physical addresses are not 1:1
(such as Xen PV guests), the generic dma_get_required_mask() will not
return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to use
only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

This series allows Xen PV guests to override the default
dma_get_required_mask() with one that calculates the DMA mask from the
maximum MFN (and not the PFN).

Changes in v3:
- fix off-by-one in xen_dma_get_required_mask()
- split ia64 changes into separate patch.

Changes in v2:
- split x86 and xen changes into separate patches

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7iJ-0002Sx-EW; Wed, 19 Nov 2014 16:02:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xr7iH-0002Rt-Mf
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:02:37 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	FC/F8-14727-D1FBC645; Wed, 19 Nov 2014 16:02:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416412950!9410534!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20627 invoked from network); 19 Nov 2014 16:02:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:02:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194441044"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:02:13 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Xr7hr-0005s8-Nv;
	Wed, 19 Nov 2014 16:02:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 19 Nov 2014 16:01:57 +0000
Message-ID: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCHv3 0/4]: dma, x86,
	xen: reduce SWIOTLB usage in Xen guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On systems where DMA addresses and physical addresses are not 1:1
(such as Xen PV guests), the generic dma_get_required_mask() will not
return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to use
only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

This series allows Xen PV guests to override the default
dma_get_required_mask() with one that calculates the DMA mask from the
maximum MFN (and not the PFN).

Changes in v3:
- fix off-by-one in xen_dma_get_required_mask()
- split ia64 changes into separate patch.

Changes in v2:
- split x86 and xen changes into separate patches

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7iJ-0002TT-Ti; Wed, 19 Nov 2014 16:02:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xr7iI-0002SU-Qy
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:02:38 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	30/19-14727-E1FBC645; Wed, 19 Nov 2014 16:02:38 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416412950!9410534!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20734 invoked from network); 19 Nov 2014 16:02:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:02:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194441055"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:02:13 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Xr7hr-0005s8-PQ;
	Wed, 19 Nov 2014 16:02:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 19 Nov 2014 16:01:59 +0000
Message-ID: <1416412921-23671-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Fenghua Yu <fenghua.yu@intel.com>, Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 2/4] ia64: use common
	dma_get_required_mask_from_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
---
 arch/ia64/include/asm/machvec.h      |    2 +-
 arch/ia64/include/asm/machvec_init.h |    1 -
 arch/ia64/pci/pci.c                  |   20 --------------------
 3 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
index 9c39bdf..beaa47d 100644
--- a/arch/ia64/include/asm/machvec.h
+++ b/arch/ia64/include/asm/machvec.h
@@ -287,7 +287,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
 # define platform_dma_get_ops		dma_get_ops
 #endif
 #ifndef platform_dma_get_required_mask
-# define  platform_dma_get_required_mask	ia64_dma_get_required_mask
+# define  platform_dma_get_required_mask	dma_get_required_mask_from_max_pfn
 #endif
 #ifndef platform_irq_to_vector
 # define platform_irq_to_vector		__ia64_irq_to_vector
diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
index 37a4698..ef964b2 100644
--- a/arch/ia64/include/asm/machvec_init.h
+++ b/arch/ia64/include/asm/machvec_init.h
@@ -3,7 +3,6 @@
 
 extern ia64_mv_send_ipi_t ia64_send_ipi;
 extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
-extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
 extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
 extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
 extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 291a582..79da21b 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -791,26 +791,6 @@ static void __init set_pci_dfl_cacheline_size(void)
 	pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
 }
 
-u64 ia64_dma_get_required_mask(struct device *dev)
-{
-	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
-	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
-	u64 mask;
-
-	if (!high_totalram) {
-		/* convert to mask just covering totalram */
-		low_totalram = (1 << (fls(low_totalram) - 1));
-		low_totalram += low_totalram - 1;
-		mask = low_totalram;
-	} else {
-		high_totalram = (1 << (fls(high_totalram) - 1));
-		high_totalram += high_totalram - 1;
-		mask = (((u64)high_totalram) << 32) + 0xffffffff;
-	}
-	return mask;
-}
-EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
-
 u64 dma_get_required_mask(struct device *dev)
 {
 	return platform_dma_get_required_mask(dev);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7iJ-0002TT-Ti; Wed, 19 Nov 2014 16:02:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xr7iI-0002SU-Qy
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:02:38 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	30/19-14727-E1FBC645; Wed, 19 Nov 2014 16:02:38 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416412950!9410534!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20734 invoked from network); 19 Nov 2014 16:02:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:02:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194441055"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:02:13 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Xr7hr-0005s8-PQ;
	Wed, 19 Nov 2014 16:02:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 19 Nov 2014 16:01:59 +0000
Message-ID: <1416412921-23671-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Fenghua Yu <fenghua.yu@intel.com>, Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 2/4] ia64: use common
	dma_get_required_mask_from_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
---
 arch/ia64/include/asm/machvec.h      |    2 +-
 arch/ia64/include/asm/machvec_init.h |    1 -
 arch/ia64/pci/pci.c                  |   20 --------------------
 3 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
index 9c39bdf..beaa47d 100644
--- a/arch/ia64/include/asm/machvec.h
+++ b/arch/ia64/include/asm/machvec.h
@@ -287,7 +287,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
 # define platform_dma_get_ops		dma_get_ops
 #endif
 #ifndef platform_dma_get_required_mask
-# define  platform_dma_get_required_mask	ia64_dma_get_required_mask
+# define  platform_dma_get_required_mask	dma_get_required_mask_from_max_pfn
 #endif
 #ifndef platform_irq_to_vector
 # define platform_irq_to_vector		__ia64_irq_to_vector
diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
index 37a4698..ef964b2 100644
--- a/arch/ia64/include/asm/machvec_init.h
+++ b/arch/ia64/include/asm/machvec_init.h
@@ -3,7 +3,6 @@
 
 extern ia64_mv_send_ipi_t ia64_send_ipi;
 extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
-extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
 extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
 extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
 extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 291a582..79da21b 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -791,26 +791,6 @@ static void __init set_pci_dfl_cacheline_size(void)
 	pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
 }
 
-u64 ia64_dma_get_required_mask(struct device *dev)
-{
-	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
-	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
-	u64 mask;
-
-	if (!high_totalram) {
-		/* convert to mask just covering totalram */
-		low_totalram = (1 << (fls(low_totalram) - 1));
-		low_totalram += low_totalram - 1;
-		mask = low_totalram;
-	} else {
-		high_totalram = (1 << (fls(high_totalram) - 1));
-		high_totalram += high_totalram - 1;
-		mask = (((u64)high_totalram) << 32) + 0xffffffff;
-	}
-	return mask;
-}
-EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
-
 u64 dma_get_required_mask(struct device *dev)
 {
 	return platform_dma_get_required_mask(dev);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7iL-0002Ug-BZ; Wed, 19 Nov 2014 16:02:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xr7iK-0002T3-0t
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:02:40 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	2E/19-14727-F1FBC645; Wed, 19 Nov 2014 16:02:39 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416412950!9410534!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20935 invoked from network); 19 Nov 2014 16:02:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:02:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194441068"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:02:13 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Xr7hr-0005s8-Rw;
	Wed, 19 Nov 2014 16:02:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 19 Nov 2014 16:02:01 +0000
Message-ID: <1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 4/4] x86/xen: use the maximum MFN to calculate
	the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to
use only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

Provide a get_required_mask op that uses the maximum MFN to calculate
the DMA mask.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    1 +
 drivers/xen/swiotlb-xen.c      |   13 +++++++++++++
 include/xen/swiotlb-xen.h      |    4 ++++
 3 files changed, 18 insertions(+)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 0e98e5d..a5d180a 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -31,6 +31,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.map_page = xen_swiotlb_map_page,
 	.unmap_page = xen_swiotlb_unmap_page,
 	.dma_supported = xen_swiotlb_dma_supported,
+	.get_required_mask = xen_swiotlb_get_required_mask,
 };
 
 /*
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..654587d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -42,9 +42,11 @@
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 #include <xen/hvc-console.h>
+#include <xen/interface/memory.h>
 
 #include <asm/dma-mapping.h>
 #include <asm/xen/page-coherent.h>
+#include <asm/xen/hypercall.h>
 
 #include <trace/events/swiotlb.h>
 /*
@@ -683,3 +685,14 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
+
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+	unsigned long max_mfn;
+
+	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
+
+	return DMA_BIT_MASK(fls_long(max_mfn - 1) + PAGE_SHIFT);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 8b2eb93..6408888 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -58,4 +58,8 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
 
 extern int
 xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
+
+extern u64
+xen_swiotlb_get_required_mask(struct device *dev);
+
 #endif /* __LINUX_SWIOTLB_XEN_H */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7iL-0002Ug-BZ; Wed, 19 Nov 2014 16:02:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xr7iK-0002T3-0t
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:02:40 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	2E/19-14727-F1FBC645; Wed, 19 Nov 2014 16:02:39 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416412950!9410534!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20935 invoked from network); 19 Nov 2014 16:02:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:02:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="194441068"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:02:13 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Xr7hr-0005s8-Rw;
	Wed, 19 Nov 2014 16:02:11 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Wed, 19 Nov 2014 16:02:01 +0000
Message-ID: <1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 4/4] x86/xen: use the maximum MFN to calculate
	the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to
use only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

Provide a get_required_mask op that uses the maximum MFN to calculate
the DMA mask.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    1 +
 drivers/xen/swiotlb-xen.c      |   13 +++++++++++++
 include/xen/swiotlb-xen.h      |    4 ++++
 3 files changed, 18 insertions(+)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 0e98e5d..a5d180a 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -31,6 +31,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.map_page = xen_swiotlb_map_page,
 	.unmap_page = xen_swiotlb_unmap_page,
 	.dma_supported = xen_swiotlb_dma_supported,
+	.get_required_mask = xen_swiotlb_get_required_mask,
 };
 
 /*
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..654587d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -42,9 +42,11 @@
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 #include <xen/hvc-console.h>
+#include <xen/interface/memory.h>
 
 #include <asm/dma-mapping.h>
 #include <asm/xen/page-coherent.h>
+#include <asm/xen/hypercall.h>
 
 #include <trace/events/swiotlb.h>
 /*
@@ -683,3 +685,14 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
+
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+	unsigned long max_mfn;
+
+	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
+
+	return DMA_BIT_MASK(fls_long(max_mfn - 1) + PAGE_SHIFT);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 8b2eb93..6408888 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -58,4 +58,8 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
 
 extern int
 xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
+
+extern u64
+xen_swiotlb_get_required_mask(struct device *dev);
+
 #endif /* __LINUX_SWIOTLB_XEN_H */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:09:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:09:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7p6-0003Cj-I9; Wed, 19 Nov 2014 16:09:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr7p5-0003Ca-5I
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:09:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B8/1F-09936-2C0CC645; Wed, 19 Nov 2014 16:09:38 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416413375!13909146!1
X-Originating-IP: [64.18.0.184]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12590 invoked from network); 19 Nov 2014 16:09:37 -0000
Received: from exprod5og107.obsmtp.com (HELO exprod5og107.obsmtp.com)
	(64.18.0.184)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:09:37 -0000
Received: from mail-qc0-f179.google.com ([209.85.216.179]) (using TLSv1) by
	exprod5ob107.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzAv5vj3E4zKXXtCRK99yQPmXedjaxY@postini.com;
	Wed, 19 Nov 2014 08:09:37 PST
Received: by mail-qc0-f179.google.com with SMTP id c9so665882qcz.10
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 08:09:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=+UkM+POw4n4L112NrfepwSfcpWBWv+n3GYsQ+mO3riI=;
	b=ibgrJvNuuvzUkIGfx3JGyHRW1KiAldNJQmwXQ7XzCWNw/ND7FSFU4vr5nPRstmLmC1
	Hj5MGI4OaUMah54IBrXvHUrjnAK9sM+6nrBiFJzTQuVVAQceiInTFuhlZT9WuXOKRIQI
	Lb1QqgwhmXKxODflLd/LDDu8GINXZF8wDKzhE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=+UkM+POw4n4L112NrfepwSfcpWBWv+n3GYsQ+mO3riI=;
	b=hSWvk4dmryCRJBpdr37Iuo+InSSciUiEZNv2HMYzAmheJFWldb6xwxbuGBp8+UVcRa
	cZgfgYW0VKj5j0lRvjSoZuVrPgICNKxl//50zLQGYaqk2tnHtdu3iZzsm+Aco+0IbhAO
	XEnjK43MTgWmhMBCinPne+IBs74y88BlcB5vX+DIguXAzKq8x/CjNz+t5KijROzW36Jh
	Vo/CIvjvNyw6/gez9/jGNQPTIeYx1G6fnwgiK9C0DW8lrArRpnbTa2V/T7XPZdKudpBD
	KISpUV/PMb0BzqJCrLlY0OCDnE+uM4Av9nxBlvbDTSdpSD48kmSOMTa8JeTgkr4DeSsn
	j4dg==
X-Gm-Message-State: ALoCoQlXQQYP2BENvwRyMdvoWf48utjPrw8OgfSJtpapsYAfgDc8rHHvhRk+ZUa0R5kg1UKEWHVoKIz1ILKCBinmaJBiV8lT+JSf80L2JJ8rTpREDwKi/ZJAcJsdD3uf+/r9Cvb9gZwjiLz1icWlNXSQTuezzwzg+A==
X-Received: by 10.140.80.136 with SMTP id c8mr51505122qgd.86.1416413374966;
	Wed, 19 Nov 2014 08:09:34 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.80.136 with SMTP id c8mr51505102qgd.86.1416413374776;
	Wed, 19 Nov 2014 08:09:34 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 08:09:34 -0800 (PST)
In-Reply-To: <CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
Date: Wed, 19 Nov 2014 18:09:34 +0200
Message-ID: <CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> Hi Stefano,
>>>
>>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> Hi Stefano,
>>> >>
>>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>>> >> > >      else
>>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>>> >> > >
>>> >> > >  }
>>> >> >
>>> >> > Yes, exactly
>>> >>
>>> >> I tried, hang still occurs with this change
>>> >
>>> > We need to figure out why during the hang you still have all the LRs
>>> > busy even if you are getting maintenance interrupts that should cause
>>> > them to be cleared.
>>> >
>>>
>>> I see that I have free LRs during maintenance interrupt
>>>
>>> (XEN) gic.c:871:d0v0 maintenance interrupt
>>> (XEN) GICH_LRs (vcpu 0) mask=0
>>> (XEN)    HW_LR[0]=9a015856
>>> (XEN)    HW_LR[1]=0
>>> (XEN)    HW_LR[2]=0
>>> (XEN)    HW_LR[3]=0
>>> (XEN) Inflight irq=86 lr=0
>>> (XEN) Inflight irq=2 lr=255
>>> (XEN) Pending irq=2
>>>
>>> But I see that after I got hang - maintenance interrupts are generated
>>> continuously. Platform continues printing the same log till reboot.
>>
>> Exactly the same log? As in the one above you just pasted?
>> That is very very suspicious.
>
> Yes exactly the same log. And looks like it means that LRs are flushed
> correctly.
>
>>
>> I am thinking that we are not handling GICH_HCR_UIE correctly and
>> something we do in Xen, maybe writing to an LR register, might trigger a
>> new maintenance interrupt immediately causing an infinite loop.
>>
>
> Yes, this is what I'm thinking about. Taking in account all collected
> debug info it looks like once LRs are overloaded with SGIs -
> maintenance interrupt occurs.
> And then it is not handled properly, and occurs again and again - so
> platform hangs inside its handler.
>
>> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>> hypervisor entry.
>>
>
> Now trying.
>
>>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 4d2a92d..6ae8dc4 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>>      if ( is_idle_vcpu(v) )
>>          return;
>>
>> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> +
>>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>
>>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> @@ -821,12 +823,8 @@ void gic_inject(void)
>>
>>      gic_restore_pending_irqs(current);
>>
>> -
>>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> -    else
>> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> -
>>  }
>>
>>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>

Heh - I don't see hangs with this patch :) But also I see that
maintenance interrupt doesn't occur (and no hang as result)
Stefano - is this expected?

>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:09:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:09:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7p6-0003Cj-I9; Wed, 19 Nov 2014 16:09:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr7p5-0003Ca-5I
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:09:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B8/1F-09936-2C0CC645; Wed, 19 Nov 2014 16:09:38 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416413375!13909146!1
X-Originating-IP: [64.18.0.184]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12590 invoked from network); 19 Nov 2014 16:09:37 -0000
Received: from exprod5og107.obsmtp.com (HELO exprod5og107.obsmtp.com)
	(64.18.0.184)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:09:37 -0000
Received: from mail-qc0-f179.google.com ([209.85.216.179]) (using TLSv1) by
	exprod5ob107.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzAv5vj3E4zKXXtCRK99yQPmXedjaxY@postini.com;
	Wed, 19 Nov 2014 08:09:37 PST
Received: by mail-qc0-f179.google.com with SMTP id c9so665882qcz.10
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 08:09:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=+UkM+POw4n4L112NrfepwSfcpWBWv+n3GYsQ+mO3riI=;
	b=ibgrJvNuuvzUkIGfx3JGyHRW1KiAldNJQmwXQ7XzCWNw/ND7FSFU4vr5nPRstmLmC1
	Hj5MGI4OaUMah54IBrXvHUrjnAK9sM+6nrBiFJzTQuVVAQceiInTFuhlZT9WuXOKRIQI
	Lb1QqgwhmXKxODflLd/LDDu8GINXZF8wDKzhE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=+UkM+POw4n4L112NrfepwSfcpWBWv+n3GYsQ+mO3riI=;
	b=hSWvk4dmryCRJBpdr37Iuo+InSSciUiEZNv2HMYzAmheJFWldb6xwxbuGBp8+UVcRa
	cZgfgYW0VKj5j0lRvjSoZuVrPgICNKxl//50zLQGYaqk2tnHtdu3iZzsm+Aco+0IbhAO
	XEnjK43MTgWmhMBCinPne+IBs74y88BlcB5vX+DIguXAzKq8x/CjNz+t5KijROzW36Jh
	Vo/CIvjvNyw6/gez9/jGNQPTIeYx1G6fnwgiK9C0DW8lrArRpnbTa2V/T7XPZdKudpBD
	KISpUV/PMb0BzqJCrLlY0OCDnE+uM4Av9nxBlvbDTSdpSD48kmSOMTa8JeTgkr4DeSsn
	j4dg==
X-Gm-Message-State: ALoCoQlXQQYP2BENvwRyMdvoWf48utjPrw8OgfSJtpapsYAfgDc8rHHvhRk+ZUa0R5kg1UKEWHVoKIz1ILKCBinmaJBiV8lT+JSf80L2JJ8rTpREDwKi/ZJAcJsdD3uf+/r9Cvb9gZwjiLz1icWlNXSQTuezzwzg+A==
X-Received: by 10.140.80.136 with SMTP id c8mr51505122qgd.86.1416413374966;
	Wed, 19 Nov 2014 08:09:34 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.80.136 with SMTP id c8mr51505102qgd.86.1416413374776;
	Wed, 19 Nov 2014 08:09:34 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 08:09:34 -0800 (PST)
In-Reply-To: <CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181612300.27247@kaball.uk.xensource.com>
	<CAH_mUMOEQa2cOVEUBFso2pxTfjyA-ECJH0oOeH6qkGDO_OGQQA@mail.gmail.com>
	<CAH_mUMOOqLtthY0TptpqZ6o9SrjtwhZAb5vkQ-s2a9nhswJddA@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
Date: Wed, 19 Nov 2014 18:09:34 +0200
Message-ID: <CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> Hi Stefano,
>>>
>>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> Hi Stefano,
>>> >>
>>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>>> >> > >      else
>>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>>> >> > >
>>> >> > >  }
>>> >> >
>>> >> > Yes, exactly
>>> >>
>>> >> I tried, hang still occurs with this change
>>> >
>>> > We need to figure out why during the hang you still have all the LRs
>>> > busy even if you are getting maintenance interrupts that should cause
>>> > them to be cleared.
>>> >
>>>
>>> I see that I have free LRs during maintenance interrupt
>>>
>>> (XEN) gic.c:871:d0v0 maintenance interrupt
>>> (XEN) GICH_LRs (vcpu 0) mask=0
>>> (XEN)    HW_LR[0]=9a015856
>>> (XEN)    HW_LR[1]=0
>>> (XEN)    HW_LR[2]=0
>>> (XEN)    HW_LR[3]=0
>>> (XEN) Inflight irq=86 lr=0
>>> (XEN) Inflight irq=2 lr=255
>>> (XEN) Pending irq=2
>>>
>>> But I see that after I got hang - maintenance interrupts are generated
>>> continuously. Platform continues printing the same log till reboot.
>>
>> Exactly the same log? As in the one above you just pasted?
>> That is very very suspicious.
>
> Yes exactly the same log. And looks like it means that LRs are flushed
> correctly.
>
>>
>> I am thinking that we are not handling GICH_HCR_UIE correctly and
>> something we do in Xen, maybe writing to an LR register, might trigger a
>> new maintenance interrupt immediately causing an infinite loop.
>>
>
> Yes, this is what I'm thinking about. Taking in account all collected
> debug info it looks like once LRs are overloaded with SGIs -
> maintenance interrupt occurs.
> And then it is not handled properly, and occurs again and again - so
> platform hangs inside its handler.
>
>> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>> hypervisor entry.
>>
>
> Now trying.
>
>>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 4d2a92d..6ae8dc4 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>>      if ( is_idle_vcpu(v) )
>>          return;
>>
>> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> +
>>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>
>>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> @@ -821,12 +823,8 @@ void gic_inject(void)
>>
>>      gic_restore_pending_irqs(current);
>>
>> -
>>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> -    else
>> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> -
>>  }
>>
>>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>

Heh - I don't see hangs with this patch :) But also I see that
maintenance interrupt doesn't occur (and no hang as result)
Stefano - is this expected?

>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:17:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7wf-0003RQ-Ll; Wed, 19 Nov 2014 16:17:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr7we-0003RL-IM
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:17:28 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	C8/61-11608-792CC645; Wed, 19 Nov 2014 16:17:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416413827!8773774!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15622 invoked from network); 19 Nov 2014 16:17:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:17:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192930223"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:13:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr7tF-00064M-Ln;
	Wed, 19 Nov 2014 16:13:57 +0000
Date: Wed, 19 Nov 2014 16:13:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> Hi Stefano,
> >>>
> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> Hi Stefano,
> >>> >>
> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >>> >> > >      else
> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >>> >> > >
> >>> >> > >  }
> >>> >> >
> >>> >> > Yes, exactly
> >>> >>
> >>> >> I tried, hang still occurs with this change
> >>> >
> >>> > We need to figure out why during the hang you still have all the LRs
> >>> > busy even if you are getting maintenance interrupts that should cause
> >>> > them to be cleared.
> >>> >
> >>>
> >>> I see that I have free LRs during maintenance interrupt
> >>>
> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >>> (XEN)    HW_LR[0]=9a015856
> >>> (XEN)    HW_LR[1]=0
> >>> (XEN)    HW_LR[2]=0
> >>> (XEN)    HW_LR[3]=0
> >>> (XEN) Inflight irq=86 lr=0
> >>> (XEN) Inflight irq=2 lr=255
> >>> (XEN) Pending irq=2
> >>>
> >>> But I see that after I got hang - maintenance interrupts are generated
> >>> continuously. Platform continues printing the same log till reboot.
> >>
> >> Exactly the same log? As in the one above you just pasted?
> >> That is very very suspicious.
> >
> > Yes exactly the same log. And looks like it means that LRs are flushed
> > correctly.
> >
> >>
> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >> new maintenance interrupt immediately causing an infinite loop.
> >>
> >
> > Yes, this is what I'm thinking about. Taking in account all collected
> > debug info it looks like once LRs are overloaded with SGIs -
> > maintenance interrupt occurs.
> > And then it is not handled properly, and occurs again and again - so
> > platform hangs inside its handler.
> >
> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >> hypervisor entry.
> >>
> >
> > Now trying.
> >
> >>
> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> index 4d2a92d..6ae8dc4 100644
> >> --- a/xen/arch/arm/gic.c
> >> +++ b/xen/arch/arm/gic.c
> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >>      if ( is_idle_vcpu(v) )
> >>          return;
> >>
> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> +
> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>
> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >>
> >>      gic_restore_pending_irqs(current);
> >>
> >> -
> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> -    else
> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> -
> >>  }
> >>
> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >
> 
> Heh - I don't see hangs with this patch :) But also I see that
> maintenance interrupt doesn't occur (and no hang as result)
> Stefano - is this expected?

No maintenance interrupts at all? That's strange. You should be
receiving them when LRs are full and you still have interrupts pending
to be added to them.

You could add another printk here to see if you should be receiving
them:

     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
+    {
+        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
         GICH[GICH_HCR] |= GICH_HCR_UIE;
-    else
-        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
-
+    }
 }


> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:17:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr7wf-0003RQ-Ll; Wed, 19 Nov 2014 16:17:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr7we-0003RL-IM
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:17:28 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	C8/61-11608-792CC645; Wed, 19 Nov 2014 16:17:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416413827!8773774!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15622 invoked from network); 19 Nov 2014 16:17:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:17:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192930223"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:13:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr7tF-00064M-Ln;
	Wed, 19 Nov 2014 16:13:57 +0000
Date: Wed, 19 Nov 2014 16:13:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> Hi Stefano,
> >>>
> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> Hi Stefano,
> >>> >>
> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >>> >> > >      else
> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >>> >> > >
> >>> >> > >  }
> >>> >> >
> >>> >> > Yes, exactly
> >>> >>
> >>> >> I tried, hang still occurs with this change
> >>> >
> >>> > We need to figure out why during the hang you still have all the LRs
> >>> > busy even if you are getting maintenance interrupts that should cause
> >>> > them to be cleared.
> >>> >
> >>>
> >>> I see that I have free LRs during maintenance interrupt
> >>>
> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >>> (XEN)    HW_LR[0]=9a015856
> >>> (XEN)    HW_LR[1]=0
> >>> (XEN)    HW_LR[2]=0
> >>> (XEN)    HW_LR[3]=0
> >>> (XEN) Inflight irq=86 lr=0
> >>> (XEN) Inflight irq=2 lr=255
> >>> (XEN) Pending irq=2
> >>>
> >>> But I see that after I got hang - maintenance interrupts are generated
> >>> continuously. Platform continues printing the same log till reboot.
> >>
> >> Exactly the same log? As in the one above you just pasted?
> >> That is very very suspicious.
> >
> > Yes exactly the same log. And looks like it means that LRs are flushed
> > correctly.
> >
> >>
> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >> new maintenance interrupt immediately causing an infinite loop.
> >>
> >
> > Yes, this is what I'm thinking about. Taking in account all collected
> > debug info it looks like once LRs are overloaded with SGIs -
> > maintenance interrupt occurs.
> > And then it is not handled properly, and occurs again and again - so
> > platform hangs inside its handler.
> >
> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >> hypervisor entry.
> >>
> >
> > Now trying.
> >
> >>
> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> index 4d2a92d..6ae8dc4 100644
> >> --- a/xen/arch/arm/gic.c
> >> +++ b/xen/arch/arm/gic.c
> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >>      if ( is_idle_vcpu(v) )
> >>          return;
> >>
> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> +
> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>
> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >>
> >>      gic_restore_pending_irqs(current);
> >>
> >> -
> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> -    else
> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> -
> >>  }
> >>
> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >
> 
> Heh - I don't see hangs with this patch :) But also I see that
> maintenance interrupt doesn't occur (and no hang as result)
> Stefano - is this expected?

No maintenance interrupts at all? That's strange. You should be
receiving them when LRs are full and you still have interrupts pending
to be added to them.

You could add another printk here to see if you should be receiving
them:

     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
+    {
+        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
         GICH[GICH_HCR] |= GICH_HCR_UIE;
-    else
-        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
-
+    }
 }


> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:30:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr88Z-0003gZ-Vn; Wed, 19 Nov 2014 16:29:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr88X-0003gU-SN
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:29:46 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3C/5C-25276-975CC645; Wed, 19 Nov 2014 16:29:45 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416414582!13980385!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9826 invoked from network); 19 Nov 2014 16:29:44 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:29:44 -0000
Received: from mail-qc0-f169.google.com ([209.85.216.169]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzFdnHfkKuP46BztfUJOmcgD01RiNV2@postini.com;
	Wed, 19 Nov 2014 08:29:43 PST
Received: by mail-qc0-f169.google.com with SMTP id w7so685165qcr.28
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 08:29:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=B/x26zCyEEyVOI4AP1A3vDibh2Y/HSsWKT22ZL8V6i8=;
	b=W1+hwMykgtFICAxumdDLIKmFREzDX6N0MiUlHR7xZagJc0q2oKI4x7kyXJbrk/z93T
	xneQL8MiFQI1t04WqrD00snbsbWK2bfeQrzkJQOnovZcvXOw6D6qu3cOVH97HQYVNJ11
	yu3y2mZb5liXjw7qOzsU2Y6OxNraoHY5O6edo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=B/x26zCyEEyVOI4AP1A3vDibh2Y/HSsWKT22ZL8V6i8=;
	b=eBb7AjxJLGAAHBgFo8Ij3wYOnr5/a8hVto9EkUVtP36BCv5AKr75a59cz4lRXfzwEj
	06LxsVYPVTB6M3DBoCkobs6oNSR9FUd+vvDroquolqHkAKQ/1/f8aavEnVWecRmZAVuJ
	X4MHC4DpDHueBXtmL+1BnzVxXnd8LhilzZrURNDhA2qGMMEixbR6KiqAbE6ogV+AA/++
	Cx0ksYKmgITGspv3GcWiF5cuL9FbPYKX1imH8zfMvcBkiTjH/jMRUtlXOEVVjj3LIE+M
	SlTA0e77w+kGG/fLKV37tQB44q6OYkzWh1dRQ5v5gz3npxF8wRyGNUJHfqUlu9MCtzKf
	RayA==
X-Gm-Message-State: ALoCoQnxJfi81FC8jZG+qHMkbFqcspWsb2OiJyIEgrx+z/W4EU56/qL6kBujCiCLTi7+lbF1JU73dxHtJN2YIMpHeWdn6NfYrwLWqTKRyUAOGVmX5xjsyca7nqXAnWxAmVUIxtqvWzJmMJRn9mHWt/a+JIk7Cg139w==
X-Received: by 10.224.138.2 with SMTP id y2mr53617398qat.52.1416414581637;
	Wed, 19 Nov 2014 08:29:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.138.2 with SMTP id y2mr53617382qat.52.1416414581507;
	Wed, 19 Nov 2014 08:29:41 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 08:29:41 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 18:29:41 +0200
Message-ID: <CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>> <andrii.tseglytskyi@globallogic.com> wrote:
>> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >>> Hi Stefano,
>> >>>
>> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >>> >> Hi Stefano,
>> >>> >>
>> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> >>> >> > >      else
>> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> >>> >> > >
>> >>> >> > >  }
>> >>> >> >
>> >>> >> > Yes, exactly
>> >>> >>
>> >>> >> I tried, hang still occurs with this change
>> >>> >
>> >>> > We need to figure out why during the hang you still have all the LRs
>> >>> > busy even if you are getting maintenance interrupts that should cause
>> >>> > them to be cleared.
>> >>> >
>> >>>
>> >>> I see that I have free LRs during maintenance interrupt
>> >>>
>> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>> >>> (XEN)    HW_LR[0]=9a015856
>> >>> (XEN)    HW_LR[1]=0
>> >>> (XEN)    HW_LR[2]=0
>> >>> (XEN)    HW_LR[3]=0
>> >>> (XEN) Inflight irq=86 lr=0
>> >>> (XEN) Inflight irq=2 lr=255
>> >>> (XEN) Pending irq=2
>> >>>
>> >>> But I see that after I got hang - maintenance interrupts are generated
>> >>> continuously. Platform continues printing the same log till reboot.
>> >>
>> >> Exactly the same log? As in the one above you just pasted?
>> >> That is very very suspicious.
>> >
>> > Yes exactly the same log. And looks like it means that LRs are flushed
>> > correctly.
>> >
>> >>
>> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>> >> something we do in Xen, maybe writing to an LR register, might trigger a
>> >> new maintenance interrupt immediately causing an infinite loop.
>> >>
>> >
>> > Yes, this is what I'm thinking about. Taking in account all collected
>> > debug info it looks like once LRs are overloaded with SGIs -
>> > maintenance interrupt occurs.
>> > And then it is not handled properly, and occurs again and again - so
>> > platform hangs inside its handler.
>> >
>> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>> >> hypervisor entry.
>> >>
>> >
>> > Now trying.
>> >
>> >>
>> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> index 4d2a92d..6ae8dc4 100644
>> >> --- a/xen/arch/arm/gic.c
>> >> +++ b/xen/arch/arm/gic.c
>> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>> >>      if ( is_idle_vcpu(v) )
>> >>          return;
>> >>
>> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> +
>> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >>
>> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>> >>
>> >>      gic_restore_pending_irqs(current);
>> >>
>> >> -
>> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> -    else
>> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> -
>> >>  }
>> >>
>> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>> >
>>
>> Heh - I don't see hangs with this patch :) But also I see that
>> maintenance interrupt doesn't occur (and no hang as result)
>> Stefano - is this expected?
>
> No maintenance interrupts at all? That's strange. You should be
> receiving them when LRs are full and you still have interrupts pending
> to be added to them.
>
> You could add another printk here to see if you should be receiving
> them:
>
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> +    {
> +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> -    else
> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> -
> +    }
>  }
>

Requested properly:

(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt

But does not occur


>
>> >
>> >
>> > --
>> >
>> > Andrii Tseglytskyi | Embedded Dev
>> > GlobalLogic
>> > www.globallogic.com
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:30:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr88Z-0003gZ-Vn; Wed, 19 Nov 2014 16:29:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr88X-0003gU-SN
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:29:46 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3C/5C-25276-975CC645; Wed, 19 Nov 2014 16:29:45 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416414582!13980385!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9826 invoked from network); 19 Nov 2014 16:29:44 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:29:44 -0000
Received: from mail-qc0-f169.google.com ([209.85.216.169]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzFdnHfkKuP46BztfUJOmcgD01RiNV2@postini.com;
	Wed, 19 Nov 2014 08:29:43 PST
Received: by mail-qc0-f169.google.com with SMTP id w7so685165qcr.28
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 08:29:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=B/x26zCyEEyVOI4AP1A3vDibh2Y/HSsWKT22ZL8V6i8=;
	b=W1+hwMykgtFICAxumdDLIKmFREzDX6N0MiUlHR7xZagJc0q2oKI4x7kyXJbrk/z93T
	xneQL8MiFQI1t04WqrD00snbsbWK2bfeQrzkJQOnovZcvXOw6D6qu3cOVH97HQYVNJ11
	yu3y2mZb5liXjw7qOzsU2Y6OxNraoHY5O6edo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=B/x26zCyEEyVOI4AP1A3vDibh2Y/HSsWKT22ZL8V6i8=;
	b=eBb7AjxJLGAAHBgFo8Ij3wYOnr5/a8hVto9EkUVtP36BCv5AKr75a59cz4lRXfzwEj
	06LxsVYPVTB6M3DBoCkobs6oNSR9FUd+vvDroquolqHkAKQ/1/f8aavEnVWecRmZAVuJ
	X4MHC4DpDHueBXtmL+1BnzVxXnd8LhilzZrURNDhA2qGMMEixbR6KiqAbE6ogV+AA/++
	Cx0ksYKmgITGspv3GcWiF5cuL9FbPYKX1imH8zfMvcBkiTjH/jMRUtlXOEVVjj3LIE+M
	SlTA0e77w+kGG/fLKV37tQB44q6OYkzWh1dRQ5v5gz3npxF8wRyGNUJHfqUlu9MCtzKf
	RayA==
X-Gm-Message-State: ALoCoQnxJfi81FC8jZG+qHMkbFqcspWsb2OiJyIEgrx+z/W4EU56/qL6kBujCiCLTi7+lbF1JU73dxHtJN2YIMpHeWdn6NfYrwLWqTKRyUAOGVmX5xjsyca7nqXAnWxAmVUIxtqvWzJmMJRn9mHWt/a+JIk7Cg139w==
X-Received: by 10.224.138.2 with SMTP id y2mr53617398qat.52.1416414581637;
	Wed, 19 Nov 2014 08:29:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.138.2 with SMTP id y2mr53617382qat.52.1416414581507;
	Wed, 19 Nov 2014 08:29:41 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 08:29:41 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 18:29:41 +0200
Message-ID: <CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>> <andrii.tseglytskyi@globallogic.com> wrote:
>> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >>> Hi Stefano,
>> >>>
>> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >>> >> Hi Stefano,
>> >>> >>
>> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> >>> >> > >      else
>> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> >>> >> > >
>> >>> >> > >  }
>> >>> >> >
>> >>> >> > Yes, exactly
>> >>> >>
>> >>> >> I tried, hang still occurs with this change
>> >>> >
>> >>> > We need to figure out why during the hang you still have all the LRs
>> >>> > busy even if you are getting maintenance interrupts that should cause
>> >>> > them to be cleared.
>> >>> >
>> >>>
>> >>> I see that I have free LRs during maintenance interrupt
>> >>>
>> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>> >>> (XEN)    HW_LR[0]=9a015856
>> >>> (XEN)    HW_LR[1]=0
>> >>> (XEN)    HW_LR[2]=0
>> >>> (XEN)    HW_LR[3]=0
>> >>> (XEN) Inflight irq=86 lr=0
>> >>> (XEN) Inflight irq=2 lr=255
>> >>> (XEN) Pending irq=2
>> >>>
>> >>> But I see that after I got hang - maintenance interrupts are generated
>> >>> continuously. Platform continues printing the same log till reboot.
>> >>
>> >> Exactly the same log? As in the one above you just pasted?
>> >> That is very very suspicious.
>> >
>> > Yes exactly the same log. And looks like it means that LRs are flushed
>> > correctly.
>> >
>> >>
>> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>> >> something we do in Xen, maybe writing to an LR register, might trigger a
>> >> new maintenance interrupt immediately causing an infinite loop.
>> >>
>> >
>> > Yes, this is what I'm thinking about. Taking in account all collected
>> > debug info it looks like once LRs are overloaded with SGIs -
>> > maintenance interrupt occurs.
>> > And then it is not handled properly, and occurs again and again - so
>> > platform hangs inside its handler.
>> >
>> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>> >> hypervisor entry.
>> >>
>> >
>> > Now trying.
>> >
>> >>
>> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> index 4d2a92d..6ae8dc4 100644
>> >> --- a/xen/arch/arm/gic.c
>> >> +++ b/xen/arch/arm/gic.c
>> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>> >>      if ( is_idle_vcpu(v) )
>> >>          return;
>> >>
>> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> +
>> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >>
>> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>> >>
>> >>      gic_restore_pending_irqs(current);
>> >>
>> >> -
>> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> -    else
>> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> -
>> >>  }
>> >>
>> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>> >
>>
>> Heh - I don't see hangs with this patch :) But also I see that
>> maintenance interrupt doesn't occur (and no hang as result)
>> Stefano - is this expected?
>
> No maintenance interrupts at all? That's strange. You should be
> receiving them when LRs are full and you still have interrupts pending
> to be added to them.
>
> You could add another printk here to see if you should be receiving
> them:
>
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> +    {
> +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> -    else
> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> -
> +    }
>  }
>

Requested properly:

(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt
(XEN) gic.c:756:d0v0 requesting maintenance interrupt

But does not occur


>
>> >
>> >
>> > --
>> >
>> > Andrii Tseglytskyi | Embedded Dev
>> > GlobalLogic
>> > www.globallogic.com
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:33:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8Bj-0003ti-Il; Wed, 19 Nov 2014 16:33:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr8Bh-0003tZ-R2
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:33:02 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	40/42-02953-D36CC645; Wed, 19 Nov 2014 16:33:01 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416414778!13560871!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28831 invoked from network); 19 Nov 2014 16:32:59 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:32:59 -0000
Received: from mail-qc0-f178.google.com ([209.85.216.178]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzGOez0//Icna/1Lv7m5kppTeLNui1o@postini.com;
	Wed, 19 Nov 2014 08:32:59 PST
Received: by mail-qc0-f178.google.com with SMTP id b13so748820qcw.37
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 08:32:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=XL1QVvuDv5wWurWLyRYoTKgXDZ4I64eowaZhesO+V+k=;
	b=LfxmlsfQgThza3RSeF1N5+YUAEaOljlsph/KOwIYzDHzL3Xe5R/INL6AwoIkvRwSSH
	1T0RY2YvxGNFbquJLTljbbxqv2DNLZdagPrp5SJ9CoTj2Oy7I7R/yxU4BKKcEjEt+tlT
	rib1sJPQY0ktI/W+ay11Lz+Z+0zH4aMpau7SQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=XL1QVvuDv5wWurWLyRYoTKgXDZ4I64eowaZhesO+V+k=;
	b=h5EoM2qUihU8Dcd9t5Er0ClSYcUDm9vzX6kHAGNo9LVYsU9Ca4iVadq69+igwvdxTp
	AqVL0cpGvvOCZwoBf9m1ac/aSOlMUDRVr5q5xIT1YOT4N+NSxudx/I2oZtO3ELdzfujw
	b6yvgAV+nBhBNaEZpGPvTl8eXDWQLEOUCf9a3WPBHWgcxZIVEcrF3k+zp4Hdy1aIy0ob
	lE5s0soxgEwWRskMDxmIkiLIlsmPr3FKRztxutEoYzbD/0Klh4cwV6jt05M+/A+Y/Gn2
	9pjJFh64dQb0NNPJjHq0kwYmfGaF9jG5BYCZWmeS37pwtyeLN5y30iSNmQ6ip77Hg6d1
	vp8A==
X-Gm-Message-State: ALoCoQnrgoCBa4EmZkQNRrhVQET0wAM4l3e6FB/mFwwa+2fQptSJNOntlCcwxMZfEAmWEiiZkA6aO7f78Iio+9A9UcqcZHMr2Z3SgdhgwQflCKVgXVuuz5ma9C4rPJCCBCJnSodgfF7pDMB2N5SsDk0T9h5Ne1kWpQ==
X-Received: by 10.140.85.83 with SMTP id m77mr51934042qgd.93.1416414777387;
	Wed, 19 Nov 2014 08:32:57 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.85.83 with SMTP id m77mr51933976qgd.93.1416414776816;
	Wed, 19 Nov 2014 08:32:56 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 08:32:56 -0800 (PST)
In-Reply-To: <CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
Date: Wed, 19 Nov 2014 18:32:56 +0200
Message-ID: <CAH_mUMPRUqFWbwwn0QqMuFpD-6YfNC2wJF0xKeg4yUVMj6rLDg@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Gic dump during interrupt requesting:

(XEN) GICH_LRs (vcpu 0) mask=f
(XEN)    HW_LR[0]=3a00001f
(XEN)    HW_LR[1]=9a015856
(XEN)    HW_LR[2]=1a00001b
(XEN)    HW_LR[3]=9a00e439
(XEN) Inflight irq=31 lr=0
(XEN) Inflight irq=86 lr=1
(XEN) Inflight irq=27 lr=2
(XEN) Inflight irq=57 lr=3
(XEN) Inflight irq=2 lr=255
(XEN) Pending irq=2

On Wed, Nov 19, 2014 at 6:29 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>>> <andrii.tseglytskyi@globallogic.com> wrote:
>>> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>>> > <stefano.stabellini@eu.citrix.com> wrote:
>>> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >>> Hi Stefano,
>>> >>>
>>> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>> >>> <stefano.stabellini@eu.citrix.com> wrote:
>>> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >>> >> Hi Stefano,
>>> >>> >>
>>> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>>> >>> >> > >      else
>>> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>>> >>> >> > >
>>> >>> >> > >  }
>>> >>> >> >
>>> >>> >> > Yes, exactly
>>> >>> >>
>>> >>> >> I tried, hang still occurs with this change
>>> >>> >
>>> >>> > We need to figure out why during the hang you still have all the LRs
>>> >>> > busy even if you are getting maintenance interrupts that should cause
>>> >>> > them to be cleared.
>>> >>> >
>>> >>>
>>> >>> I see that I have free LRs during maintenance interrupt
>>> >>>
>>> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>>> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>>> >>> (XEN)    HW_LR[0]=9a015856
>>> >>> (XEN)    HW_LR[1]=0
>>> >>> (XEN)    HW_LR[2]=0
>>> >>> (XEN)    HW_LR[3]=0
>>> >>> (XEN) Inflight irq=86 lr=0
>>> >>> (XEN) Inflight irq=2 lr=255
>>> >>> (XEN) Pending irq=2
>>> >>>
>>> >>> But I see that after I got hang - maintenance interrupts are generated
>>> >>> continuously. Platform continues printing the same log till reboot.
>>> >>
>>> >> Exactly the same log? As in the one above you just pasted?
>>> >> That is very very suspicious.
>>> >
>>> > Yes exactly the same log. And looks like it means that LRs are flushed
>>> > correctly.
>>> >
>>> >>
>>> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>>> >> something we do in Xen, maybe writing to an LR register, might trigger a
>>> >> new maintenance interrupt immediately causing an infinite loop.
>>> >>
>>> >
>>> > Yes, this is what I'm thinking about. Taking in account all collected
>>> > debug info it looks like once LRs are overloaded with SGIs -
>>> > maintenance interrupt occurs.
>>> > And then it is not handled properly, and occurs again and again - so
>>> > platform hangs inside its handler.
>>> >
>>> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>>> >> hypervisor entry.
>>> >>
>>> >
>>> > Now trying.
>>> >
>>> >>
>>> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> >> index 4d2a92d..6ae8dc4 100644
>>> >> --- a/xen/arch/arm/gic.c
>>> >> +++ b/xen/arch/arm/gic.c
>>> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>>> >>      if ( is_idle_vcpu(v) )
>>> >>          return;
>>> >>
>>> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> +
>>> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>> >>
>>> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>>> >>
>>> >>      gic_restore_pending_irqs(current);
>>> >>
>>> >> -
>>> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> -    else
>>> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> -
>>> >>  }
>>> >>
>>> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>>> >
>>>
>>> Heh - I don't see hangs with this patch :) But also I see that
>>> maintenance interrupt doesn't occur (and no hang as result)
>>> Stefano - is this expected?
>>
>> No maintenance interrupts at all? That's strange. You should be
>> receiving them when LRs are full and you still have interrupts pending
>> to be added to them.
>>
>> You could add another printk here to see if you should be receiving
>> them:
>>
>>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> +    {
>> +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> -    else
>> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> -
>> +    }
>>  }
>>
>
> Requested properly:
>
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>
> But does not occur
>
>
>>
>>> >
>>> >
>>> > --
>>> >
>>> > Andrii Tseglytskyi | Embedded Dev
>>> > GlobalLogic
>>> > www.globallogic.com
>>>
>>>
>>>
>>> --
>>>
>>> Andrii Tseglytskyi | Embedded Dev
>>> GlobalLogic
>>> www.globallogic.com
>>>
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:33:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8Bj-0003ti-Il; Wed, 19 Nov 2014 16:33:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr8Bh-0003tZ-R2
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:33:02 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	40/42-02953-D36CC645; Wed, 19 Nov 2014 16:33:01 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416414778!13560871!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28831 invoked from network); 19 Nov 2014 16:32:59 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:32:59 -0000
Received: from mail-qc0-f178.google.com ([209.85.216.178]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzGOez0//Icna/1Lv7m5kppTeLNui1o@postini.com;
	Wed, 19 Nov 2014 08:32:59 PST
Received: by mail-qc0-f178.google.com with SMTP id b13so748820qcw.37
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 08:32:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=XL1QVvuDv5wWurWLyRYoTKgXDZ4I64eowaZhesO+V+k=;
	b=LfxmlsfQgThza3RSeF1N5+YUAEaOljlsph/KOwIYzDHzL3Xe5R/INL6AwoIkvRwSSH
	1T0RY2YvxGNFbquJLTljbbxqv2DNLZdagPrp5SJ9CoTj2Oy7I7R/yxU4BKKcEjEt+tlT
	rib1sJPQY0ktI/W+ay11Lz+Z+0zH4aMpau7SQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=XL1QVvuDv5wWurWLyRYoTKgXDZ4I64eowaZhesO+V+k=;
	b=h5EoM2qUihU8Dcd9t5Er0ClSYcUDm9vzX6kHAGNo9LVYsU9Ca4iVadq69+igwvdxTp
	AqVL0cpGvvOCZwoBf9m1ac/aSOlMUDRVr5q5xIT1YOT4N+NSxudx/I2oZtO3ELdzfujw
	b6yvgAV+nBhBNaEZpGPvTl8eXDWQLEOUCf9a3WPBHWgcxZIVEcrF3k+zp4Hdy1aIy0ob
	lE5s0soxgEwWRskMDxmIkiLIlsmPr3FKRztxutEoYzbD/0Klh4cwV6jt05M+/A+Y/Gn2
	9pjJFh64dQb0NNPJjHq0kwYmfGaF9jG5BYCZWmeS37pwtyeLN5y30iSNmQ6ip77Hg6d1
	vp8A==
X-Gm-Message-State: ALoCoQnrgoCBa4EmZkQNRrhVQET0wAM4l3e6FB/mFwwa+2fQptSJNOntlCcwxMZfEAmWEiiZkA6aO7f78Iio+9A9UcqcZHMr2Z3SgdhgwQflCKVgXVuuz5ma9C4rPJCCBCJnSodgfF7pDMB2N5SsDk0T9h5Ne1kWpQ==
X-Received: by 10.140.85.83 with SMTP id m77mr51934042qgd.93.1416414777387;
	Wed, 19 Nov 2014 08:32:57 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.85.83 with SMTP id m77mr51933976qgd.93.1416414776816;
	Wed, 19 Nov 2014 08:32:56 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 08:32:56 -0800 (PST)
In-Reply-To: <CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
Date: Wed, 19 Nov 2014 18:32:56 +0200
Message-ID: <CAH_mUMPRUqFWbwwn0QqMuFpD-6YfNC2wJF0xKeg4yUVMj6rLDg@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Gic dump during interrupt requesting:

(XEN) GICH_LRs (vcpu 0) mask=f
(XEN)    HW_LR[0]=3a00001f
(XEN)    HW_LR[1]=9a015856
(XEN)    HW_LR[2]=1a00001b
(XEN)    HW_LR[3]=9a00e439
(XEN) Inflight irq=31 lr=0
(XEN) Inflight irq=86 lr=1
(XEN) Inflight irq=27 lr=2
(XEN) Inflight irq=57 lr=3
(XEN) Inflight irq=2 lr=255
(XEN) Pending irq=2

On Wed, Nov 19, 2014 at 6:29 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>>> <andrii.tseglytskyi@globallogic.com> wrote:
>>> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>>> > <stefano.stabellini@eu.citrix.com> wrote:
>>> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >>> Hi Stefano,
>>> >>>
>>> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>> >>> <stefano.stabellini@eu.citrix.com> wrote:
>>> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >>> >> Hi Stefano,
>>> >>> >>
>>> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>>> >>> >> > >      else
>>> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>>> >>> >> > >
>>> >>> >> > >  }
>>> >>> >> >
>>> >>> >> > Yes, exactly
>>> >>> >>
>>> >>> >> I tried, hang still occurs with this change
>>> >>> >
>>> >>> > We need to figure out why during the hang you still have all the LRs
>>> >>> > busy even if you are getting maintenance interrupts that should cause
>>> >>> > them to be cleared.
>>> >>> >
>>> >>>
>>> >>> I see that I have free LRs during maintenance interrupt
>>> >>>
>>> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>>> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>>> >>> (XEN)    HW_LR[0]=9a015856
>>> >>> (XEN)    HW_LR[1]=0
>>> >>> (XEN)    HW_LR[2]=0
>>> >>> (XEN)    HW_LR[3]=0
>>> >>> (XEN) Inflight irq=86 lr=0
>>> >>> (XEN) Inflight irq=2 lr=255
>>> >>> (XEN) Pending irq=2
>>> >>>
>>> >>> But I see that after I got hang - maintenance interrupts are generated
>>> >>> continuously. Platform continues printing the same log till reboot.
>>> >>
>>> >> Exactly the same log? As in the one above you just pasted?
>>> >> That is very very suspicious.
>>> >
>>> > Yes exactly the same log. And looks like it means that LRs are flushed
>>> > correctly.
>>> >
>>> >>
>>> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>>> >> something we do in Xen, maybe writing to an LR register, might trigger a
>>> >> new maintenance interrupt immediately causing an infinite loop.
>>> >>
>>> >
>>> > Yes, this is what I'm thinking about. Taking in account all collected
>>> > debug info it looks like once LRs are overloaded with SGIs -
>>> > maintenance interrupt occurs.
>>> > And then it is not handled properly, and occurs again and again - so
>>> > platform hangs inside its handler.
>>> >
>>> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>>> >> hypervisor entry.
>>> >>
>>> >
>>> > Now trying.
>>> >
>>> >>
>>> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> >> index 4d2a92d..6ae8dc4 100644
>>> >> --- a/xen/arch/arm/gic.c
>>> >> +++ b/xen/arch/arm/gic.c
>>> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>>> >>      if ( is_idle_vcpu(v) )
>>> >>          return;
>>> >>
>>> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> +
>>> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>> >>
>>> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>>> >>
>>> >>      gic_restore_pending_irqs(current);
>>> >>
>>> >> -
>>> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> -    else
>>> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> -
>>> >>  }
>>> >>
>>> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>>> >
>>>
>>> Heh - I don't see hangs with this patch :) But also I see that
>>> maintenance interrupt doesn't occur (and no hang as result)
>>> Stefano - is this expected?
>>
>> No maintenance interrupts at all? That's strange. You should be
>> receiving them when LRs are full and you still have interrupts pending
>> to be added to them.
>>
>> You could add another printk here to see if you should be receiving
>> them:
>>
>>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> +    {
>> +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> -    else
>> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> -
>> +    }
>>  }
>>
>
> Requested properly:
>
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>
> But does not occur
>
>
>>
>>> >
>>> >
>>> > --
>>> >
>>> > Andrii Tseglytskyi | Embedded Dev
>>> > GlobalLogic
>>> > www.globallogic.com
>>>
>>>
>>>
>>> --
>>>
>>> Andrii Tseglytskyi | Embedded Dev
>>> GlobalLogic
>>> www.globallogic.com
>>>
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:43:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:43:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8Li-00045q-2S; Wed, 19 Nov 2014 16:43:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr8Lh-00045l-3i
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:43:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CF/B2-09936-8A8CC645; Wed, 19 Nov 2014 16:43:20 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416415395!13926988!1
X-Originating-IP: [64.18.0.188]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14249 invoked from network); 19 Nov 2014 16:43:19 -0000
Received: from exprod5og109.obsmtp.com (HELO exprod5og109.obsmtp.com)
	(64.18.0.188)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:43:19 -0000
Received: from mail-qa0-f43.google.com ([209.85.216.43]) (using TLSv1) by
	exprod5ob109.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzIo6BmIQa85pkTjFEFY1h3fJQr10+p@postini.com;
	Wed, 19 Nov 2014 08:43:19 PST
Received: by mail-qa0-f43.google.com with SMTP id bm13so643467qab.2
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 08:43:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=E3KljuRcLiLrjcn+86Z7SfOZTOdoSoU9GoIeh3gAcyk=;
	b=cfikgeavDsG2KPSyDFyH9W09zykvOj9I9I70UbTnFp4SpF4WTBv0ZK4lSbhcZ45t66
	GmtJnPjJ3zijDlPC0F+4Ep1EOmMKk6LX393miOh+53lIO7qgElXI64StpsB2OoUfkwv/
	0gFYpanuJkdDXCoBvKTj9DVf5hrG2krX1fxC4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=E3KljuRcLiLrjcn+86Z7SfOZTOdoSoU9GoIeh3gAcyk=;
	b=FvmNdqZXy2ZaUSTaN8Me2h/YcZz+CUuIv36hss7QgrYkeN/kipN3hxajrVgQTXZRJD
	8wq3fWso8mHf2ZHqTXLsJrFT4AsjozQjzj+Cnvq+RM2f4G7M7bf2w8RXv2HRS3S0tBM1
	W3tdkm1orMkP2PPWto+5vcfLAPR6jhDE2QyrkTAC0/yShxgaAyo7zzJDIgzWd6jkvXSC
	AREep198GniNO/Vpobq8Nqxk32UOFaYxhePr1+fGbu5dTQ0AlQMrdxMmBZ885pskbbXd
	Z8R9iL6XdmCT2o8rfjHLc7wP8VnO0GU4i0KggEMxkh1coTSwQgl/0wB/5o6VGX8jBk5q
	kdOA==
X-Gm-Message-State: ALoCoQkdsVipKtJyGIirp91j3dv4Up8Lswz+uZTJRMLLEWX/r3G6BiWQr66XDBJ30SqQmkmHaru/ktqsNp+gZVN/JUPI53j8flPMzaC8A8yAwO0pl8PqgvqlkdFaQfjvtsj+Yd60tjOcKnhksSsxWkgrZo9wQ9vPpQ==
X-Received: by 10.224.28.193 with SMTP id n1mr53329332qac.93.1416415382923;
	Wed, 19 Nov 2014 08:43:02 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.28.193 with SMTP id n1mr53329308qac.93.1416415382682;
	Wed, 19 Nov 2014 08:43:02 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 08:43:02 -0800 (PST)
In-Reply-To: <CAH_mUMPRUqFWbwwn0QqMuFpD-6YfNC2wJF0xKeg4yUVMj6rLDg@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<CAH_mUMPRUqFWbwwn0QqMuFpD-6YfNC2wJF0xKeg4yUVMj6rLDg@mail.gmail.com>
Date: Wed, 19 Nov 2014 18:43:02 +0200
Message-ID: <CAH_mUMOBuWU+3HBy=MMhRZxpjBHOiHCBgWedXZ6f0EgzVCWkFQ@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

BTW - shouldn't this flag GICH_LR_MAINTENANCE_IRQ be set after
maintenance interrupt requesting ?

On Wed, Nov 19, 2014 at 6:32 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> Gic dump during interrupt requesting:
>
> (XEN) GICH_LRs (vcpu 0) mask=f
> (XEN)    HW_LR[0]=3a00001f
> (XEN)    HW_LR[1]=9a015856
> (XEN)    HW_LR[2]=1a00001b
> (XEN)    HW_LR[3]=9a00e439
> (XEN) Inflight irq=31 lr=0
> (XEN) Inflight irq=86 lr=1
> (XEN) Inflight irq=27 lr=2
> (XEN) Inflight irq=57 lr=3
> (XEN) Inflight irq=2 lr=255
> (XEN) Pending irq=2
>
> On Wed, Nov 19, 2014 at 6:29 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
>> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>>> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>>>> <andrii.tseglytskyi@globallogic.com> wrote:
>>>> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>>>> > <stefano.stabellini@eu.citrix.com> wrote:
>>>> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>>> >>> Hi Stefano,
>>>> >>>
>>>> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>>> >>> <stefano.stabellini@eu.citrix.com> wrote:
>>>> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>>> >>> >> Hi Stefano,
>>>> >>> >>
>>>> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>>> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>>>> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>>>> >>> >> > >      else
>>>> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>>> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>>>> >>> >> > >
>>>> >>> >> > >  }
>>>> >>> >> >
>>>> >>> >> > Yes, exactly
>>>> >>> >>
>>>> >>> >> I tried, hang still occurs with this change
>>>> >>> >
>>>> >>> > We need to figure out why during the hang you still have all the LRs
>>>> >>> > busy even if you are getting maintenance interrupts that should cause
>>>> >>> > them to be cleared.
>>>> >>> >
>>>> >>>
>>>> >>> I see that I have free LRs during maintenance interrupt
>>>> >>>
>>>> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>>>> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>>>> >>> (XEN)    HW_LR[0]=9a015856
>>>> >>> (XEN)    HW_LR[1]=0
>>>> >>> (XEN)    HW_LR[2]=0
>>>> >>> (XEN)    HW_LR[3]=0
>>>> >>> (XEN) Inflight irq=86 lr=0
>>>> >>> (XEN) Inflight irq=2 lr=255
>>>> >>> (XEN) Pending irq=2
>>>> >>>
>>>> >>> But I see that after I got hang - maintenance interrupts are generated
>>>> >>> continuously. Platform continues printing the same log till reboot.
>>>> >>
>>>> >> Exactly the same log? As in the one above you just pasted?
>>>> >> That is very very suspicious.
>>>> >
>>>> > Yes exactly the same log. And looks like it means that LRs are flushed
>>>> > correctly.
>>>> >
>>>> >>
>>>> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>>>> >> something we do in Xen, maybe writing to an LR register, might trigger a
>>>> >> new maintenance interrupt immediately causing an infinite loop.
>>>> >>
>>>> >
>>>> > Yes, this is what I'm thinking about. Taking in account all collected
>>>> > debug info it looks like once LRs are overloaded with SGIs -
>>>> > maintenance interrupt occurs.
>>>> > And then it is not handled properly, and occurs again and again - so
>>>> > platform hangs inside its handler.
>>>> >
>>>> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>>>> >> hypervisor entry.
>>>> >>
>>>> >
>>>> > Now trying.
>>>> >
>>>> >>
>>>> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>>> >> index 4d2a92d..6ae8dc4 100644
>>>> >> --- a/xen/arch/arm/gic.c
>>>> >> +++ b/xen/arch/arm/gic.c
>>>> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>>>> >>      if ( is_idle_vcpu(v) )
>>>> >>          return;
>>>> >>
>>>> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>>> >> +
>>>> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>>> >>
>>>> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>>> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>>>> >>
>>>> >>      gic_restore_pending_irqs(current);
>>>> >>
>>>> >> -
>>>> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>>> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>>> >> -    else
>>>> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>>> >> -
>>>> >>  }
>>>> >>
>>>> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>>>> >
>>>>
>>>> Heh - I don't see hangs with this patch :) But also I see that
>>>> maintenance interrupt doesn't occur (and no hang as result)
>>>> Stefano - is this expected?
>>>
>>> No maintenance interrupts at all? That's strange. You should be
>>> receiving them when LRs are full and you still have interrupts pending
>>> to be added to them.
>>>
>>> You could add another printk here to see if you should be receiving
>>> them:
>>>
>>>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> +    {
>>> +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>>>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> -    else
>>> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> -
>>> +    }
>>>  }
>>>
>>
>> Requested properly:
>>
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>
>> But does not occur
>>
>>
>>>
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > Andrii Tseglytskyi | Embedded Dev
>>>> > GlobalLogic
>>>> > www.globallogic.com
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Andrii Tseglytskyi | Embedded Dev
>>>> GlobalLogic
>>>> www.globallogic.com
>>>>
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:43:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:43:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8Li-00045q-2S; Wed, 19 Nov 2014 16:43:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr8Lh-00045l-3i
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:43:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CF/B2-09936-8A8CC645; Wed, 19 Nov 2014 16:43:20 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416415395!13926988!1
X-Originating-IP: [64.18.0.188]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14249 invoked from network); 19 Nov 2014 16:43:19 -0000
Received: from exprod5og109.obsmtp.com (HELO exprod5og109.obsmtp.com)
	(64.18.0.188)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:43:19 -0000
Received: from mail-qa0-f43.google.com ([209.85.216.43]) (using TLSv1) by
	exprod5ob109.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzIo6BmIQa85pkTjFEFY1h3fJQr10+p@postini.com;
	Wed, 19 Nov 2014 08:43:19 PST
Received: by mail-qa0-f43.google.com with SMTP id bm13so643467qab.2
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 08:43:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=E3KljuRcLiLrjcn+86Z7SfOZTOdoSoU9GoIeh3gAcyk=;
	b=cfikgeavDsG2KPSyDFyH9W09zykvOj9I9I70UbTnFp4SpF4WTBv0ZK4lSbhcZ45t66
	GmtJnPjJ3zijDlPC0F+4Ep1EOmMKk6LX393miOh+53lIO7qgElXI64StpsB2OoUfkwv/
	0gFYpanuJkdDXCoBvKTj9DVf5hrG2krX1fxC4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=E3KljuRcLiLrjcn+86Z7SfOZTOdoSoU9GoIeh3gAcyk=;
	b=FvmNdqZXy2ZaUSTaN8Me2h/YcZz+CUuIv36hss7QgrYkeN/kipN3hxajrVgQTXZRJD
	8wq3fWso8mHf2ZHqTXLsJrFT4AsjozQjzj+Cnvq+RM2f4G7M7bf2w8RXv2HRS3S0tBM1
	W3tdkm1orMkP2PPWto+5vcfLAPR6jhDE2QyrkTAC0/yShxgaAyo7zzJDIgzWd6jkvXSC
	AREep198GniNO/Vpobq8Nqxk32UOFaYxhePr1+fGbu5dTQ0AlQMrdxMmBZ885pskbbXd
	Z8R9iL6XdmCT2o8rfjHLc7wP8VnO0GU4i0KggEMxkh1coTSwQgl/0wB/5o6VGX8jBk5q
	kdOA==
X-Gm-Message-State: ALoCoQkdsVipKtJyGIirp91j3dv4Up8Lswz+uZTJRMLLEWX/r3G6BiWQr66XDBJ30SqQmkmHaru/ktqsNp+gZVN/JUPI53j8flPMzaC8A8yAwO0pl8PqgvqlkdFaQfjvtsj+Yd60tjOcKnhksSsxWkgrZo9wQ9vPpQ==
X-Received: by 10.224.28.193 with SMTP id n1mr53329332qac.93.1416415382923;
	Wed, 19 Nov 2014 08:43:02 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.28.193 with SMTP id n1mr53329308qac.93.1416415382682;
	Wed, 19 Nov 2014 08:43:02 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 08:43:02 -0800 (PST)
In-Reply-To: <CAH_mUMPRUqFWbwwn0QqMuFpD-6YfNC2wJF0xKeg4yUVMj6rLDg@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411181703140.27247@kaball.uk.xensource.com>
	<CAH_mUMOMrJhABFKfeOZUSx-6MOELjwkNa7raxtJjcHq7=doG4A@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<CAH_mUMPRUqFWbwwn0QqMuFpD-6YfNC2wJF0xKeg4yUVMj6rLDg@mail.gmail.com>
Date: Wed, 19 Nov 2014 18:43:02 +0200
Message-ID: <CAH_mUMOBuWU+3HBy=MMhRZxpjBHOiHCBgWedXZ6f0EgzVCWkFQ@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

BTW - shouldn't this flag GICH_LR_MAINTENANCE_IRQ be set after
maintenance interrupt requesting ?

On Wed, Nov 19, 2014 at 6:32 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> Gic dump during interrupt requesting:
>
> (XEN) GICH_LRs (vcpu 0) mask=f
> (XEN)    HW_LR[0]=3a00001f
> (XEN)    HW_LR[1]=9a015856
> (XEN)    HW_LR[2]=1a00001b
> (XEN)    HW_LR[3]=9a00e439
> (XEN) Inflight irq=31 lr=0
> (XEN) Inflight irq=86 lr=1
> (XEN) Inflight irq=27 lr=2
> (XEN) Inflight irq=57 lr=3
> (XEN) Inflight irq=2 lr=255
> (XEN) Pending irq=2
>
> On Wed, Nov 19, 2014 at 6:29 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
>> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>>> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>>>> <andrii.tseglytskyi@globallogic.com> wrote:
>>>> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>>>> > <stefano.stabellini@eu.citrix.com> wrote:
>>>> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>>> >>> Hi Stefano,
>>>> >>>
>>>> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>>> >>> <stefano.stabellini@eu.citrix.com> wrote:
>>>> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>>> >>> >> Hi Stefano,
>>>> >>> >>
>>>> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>>> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>>>> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>>>> >>> >> > >      else
>>>> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>>> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>>>> >>> >> > >
>>>> >>> >> > >  }
>>>> >>> >> >
>>>> >>> >> > Yes, exactly
>>>> >>> >>
>>>> >>> >> I tried, hang still occurs with this change
>>>> >>> >
>>>> >>> > We need to figure out why during the hang you still have all the LRs
>>>> >>> > busy even if you are getting maintenance interrupts that should cause
>>>> >>> > them to be cleared.
>>>> >>> >
>>>> >>>
>>>> >>> I see that I have free LRs during maintenance interrupt
>>>> >>>
>>>> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>>>> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>>>> >>> (XEN)    HW_LR[0]=9a015856
>>>> >>> (XEN)    HW_LR[1]=0
>>>> >>> (XEN)    HW_LR[2]=0
>>>> >>> (XEN)    HW_LR[3]=0
>>>> >>> (XEN) Inflight irq=86 lr=0
>>>> >>> (XEN) Inflight irq=2 lr=255
>>>> >>> (XEN) Pending irq=2
>>>> >>>
>>>> >>> But I see that after I got hang - maintenance interrupts are generated
>>>> >>> continuously. Platform continues printing the same log till reboot.
>>>> >>
>>>> >> Exactly the same log? As in the one above you just pasted?
>>>> >> That is very very suspicious.
>>>> >
>>>> > Yes exactly the same log. And looks like it means that LRs are flushed
>>>> > correctly.
>>>> >
>>>> >>
>>>> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>>>> >> something we do in Xen, maybe writing to an LR register, might trigger a
>>>> >> new maintenance interrupt immediately causing an infinite loop.
>>>> >>
>>>> >
>>>> > Yes, this is what I'm thinking about. Taking in account all collected
>>>> > debug info it looks like once LRs are overloaded with SGIs -
>>>> > maintenance interrupt occurs.
>>>> > And then it is not handled properly, and occurs again and again - so
>>>> > platform hangs inside its handler.
>>>> >
>>>> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>>>> >> hypervisor entry.
>>>> >>
>>>> >
>>>> > Now trying.
>>>> >
>>>> >>
>>>> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>>> >> index 4d2a92d..6ae8dc4 100644
>>>> >> --- a/xen/arch/arm/gic.c
>>>> >> +++ b/xen/arch/arm/gic.c
>>>> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>>>> >>      if ( is_idle_vcpu(v) )
>>>> >>          return;
>>>> >>
>>>> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>>> >> +
>>>> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>>> >>
>>>> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>>> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>>>> >>
>>>> >>      gic_restore_pending_irqs(current);
>>>> >>
>>>> >> -
>>>> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>>> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>>> >> -    else
>>>> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>>> >> -
>>>> >>  }
>>>> >>
>>>> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>>>> >
>>>>
>>>> Heh - I don't see hangs with this patch :) But also I see that
>>>> maintenance interrupt doesn't occur (and no hang as result)
>>>> Stefano - is this expected?
>>>
>>> No maintenance interrupts at all? That's strange. You should be
>>> receiving them when LRs are full and you still have interrupts pending
>>> to be added to them.
>>>
>>> You could add another printk here to see if you should be receiving
>>> them:
>>>
>>>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> +    {
>>> +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>>>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> -    else
>>> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> -
>>> +    }
>>>  }
>>>
>>
>> Requested properly:
>>
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>
>> But does not occur
>>
>>
>>>
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > Andrii Tseglytskyi | Embedded Dev
>>>> > GlobalLogic
>>>> > www.globallogic.com
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Andrii Tseglytskyi | Embedded Dev
>>>> GlobalLogic
>>>> www.globallogic.com
>>>>
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:45:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8NH-0004GL-Hl; Wed, 19 Nov 2014 16:44:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr8NG-0004GF-9s
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:44:58 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2C/E4-09936-909CC645; Wed, 19 Nov 2014 16:44:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416415494!13610628!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7990 invoked from network); 19 Nov 2014 16:44:55 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:44:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJGiiEr012496
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 16:44:45 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAJGigEF017243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 16:44:43 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJGifKi015391; Wed, 19 Nov 2014 16:44:41 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 08:44:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 596521180D7; Wed, 19 Nov 2014 11:44:40 -0500 (EST)
Date: Wed, 19 Nov 2014 11:44:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, linux@eikelenboom.it
Message-ID: <20141119164440.GA18595@laptop.dumpdata.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
	<1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
	<54662A360200007800047BDB@mail.emea.novell.com>
	<20141114161146.GG5364@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141114161146.GG5364@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet
	with an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 11:11:46AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 03:13:42PM +0000, Jan Beulich wrote:
> > >>> On 12.11.14 at 03:23, <konrad.wilk@oracle.com> wrote:
> > > +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> > > +{
> > > +    struct domain *d = pirq_dpci->dom;
> > > +
> > > +    ASSERT(spin_is_locked(&d->event_lock));
> > > +
> > > +    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
> > > +    {
> > > +    case (1 << STATE_SCHED):
> > > +        /*
> > > +         * We are going to try to de-schedule the softirq before it goes in
> > > +         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
> > > +         */
> > > +        put_domain(d);
> > > +        /* fallthrough. */
> > 
> > Considering Sander's report, the only suspicious place I find is this
> > one: When the STATE_SCHED flag is set, pirq_dpci is on some
> > CPU's list. What guarantees it to get removed from that list before
> > getting inserted on another one?
> 
> None. The moment that STATE_SCHED is cleared, 'raise_softirq_for'
> is free to manipulate the list.

I was too quick to say this. A bit more inspection shows that while
'raise_softirq_for' is free to manipulate the list - it won't be called.

The reason is that the pt_pirq_softirq_reset is called _after_ the IRQ
action handler are removed for this IRQ. That means we will not receive
any interrupts for it and call 'raise_softirq_for'. At least until
'pt_irq_create_bind' is called. And said function has a check for
this too:

42      * A crude 'while' loop with us dropping the spinlock and giving            
243      * the softirq_dpci a chance to run.                                        
244      * We MUST check for this condition as the softirq could be scheduled       
245      * and hasn't run yet. Note that this code replaced tasklet_kill which      
246      * would have spun forever and would do the same thing (wait to flush out   
247      * outstanding hvm_dirq_assist calls.                                       
248      */                                                                         
249     if ( pt_pirq_softirq_active(pirq_dpci) )          

Hence the patch below is not needed.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:45:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8NH-0004GL-Hl; Wed, 19 Nov 2014 16:44:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr8NG-0004GF-9s
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 16:44:58 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2C/E4-09936-909CC645; Wed, 19 Nov 2014 16:44:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416415494!13610628!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7990 invoked from network); 19 Nov 2014 16:44:55 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 16:44:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJGiiEr012496
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 16:44:45 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAJGigEF017243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 16:44:43 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJGifKi015391; Wed, 19 Nov 2014 16:44:41 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 08:44:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 596521180D7; Wed, 19 Nov 2014 11:44:40 -0500 (EST)
Date: Wed, 19 Nov 2014 11:44:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, linux@eikelenboom.it
Message-ID: <20141119164440.GA18595@laptop.dumpdata.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
	<1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
	<54662A360200007800047BDB@mail.emea.novell.com>
	<20141114161146.GG5364@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141114161146.GG5364@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	tim@xen.org, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet
	with an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 11:11:46AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 03:13:42PM +0000, Jan Beulich wrote:
> > >>> On 12.11.14 at 03:23, <konrad.wilk@oracle.com> wrote:
> > > +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> > > +{
> > > +    struct domain *d = pirq_dpci->dom;
> > > +
> > > +    ASSERT(spin_is_locked(&d->event_lock));
> > > +
> > > +    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
> > > +    {
> > > +    case (1 << STATE_SCHED):
> > > +        /*
> > > +         * We are going to try to de-schedule the softirq before it goes in
> > > +         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
> > > +         */
> > > +        put_domain(d);
> > > +        /* fallthrough. */
> > 
> > Considering Sander's report, the only suspicious place I find is this
> > one: When the STATE_SCHED flag is set, pirq_dpci is on some
> > CPU's list. What guarantees it to get removed from that list before
> > getting inserted on another one?
> 
> None. The moment that STATE_SCHED is cleared, 'raise_softirq_for'
> is free to manipulate the list.

I was too quick to say this. A bit more inspection shows that while
'raise_softirq_for' is free to manipulate the list - it won't be called.

The reason is that the pt_pirq_softirq_reset is called _after_ the IRQ
action handler are removed for this IRQ. That means we will not receive
any interrupts for it and call 'raise_softirq_for'. At least until
'pt_irq_create_bind' is called. And said function has a check for
this too:

42      * A crude 'while' loop with us dropping the spinlock and giving            
243      * the softirq_dpci a chance to run.                                        
244      * We MUST check for this condition as the softirq could be scheduled       
245      * and hasn't run yet. Note that this code replaced tasklet_kill which      
246      * would have spun forever and would do the same thing (wait to flush out   
247      * outstanding hvm_dirq_assist calls.                                       
248      */                                                                         
249     if ( pt_pirq_softirq_active(pirq_dpci) )          

Hence the patch below is not needed.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:52:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16: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 1Xr8U3-0004SQ-F0; Wed, 19 Nov 2014 16:51:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr8U2-0004SL-8P
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:51:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	28/AD-25276-DAACC645; Wed, 19 Nov 2014 16:51:57 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416415913!13954555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8883 invoked from network); 19 Nov 2014 16:51:56 -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;
	19 Nov 2014 16:51:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194463619"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:50:59 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr8T4-0006qh-51;
	Wed, 19 Nov 2014 16:50:58 +0000
Date: Wed, 19 Nov 2014 16:50:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >>> Hi Stefano,
> >> >>>
> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >>> >> Hi Stefano,
> >> >>> >>
> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >> >>> >> > >      else
> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >> >>> >> > >
> >> >>> >> > >  }
> >> >>> >> >
> >> >>> >> > Yes, exactly
> >> >>> >>
> >> >>> >> I tried, hang still occurs with this change
> >> >>> >
> >> >>> > We need to figure out why during the hang you still have all the LRs
> >> >>> > busy even if you are getting maintenance interrupts that should cause
> >> >>> > them to be cleared.
> >> >>> >
> >> >>>
> >> >>> I see that I have free LRs during maintenance interrupt
> >> >>>
> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >> >>> (XEN)    HW_LR[0]=9a015856
> >> >>> (XEN)    HW_LR[1]=0
> >> >>> (XEN)    HW_LR[2]=0
> >> >>> (XEN)    HW_LR[3]=0
> >> >>> (XEN) Inflight irq=86 lr=0
> >> >>> (XEN) Inflight irq=2 lr=255
> >> >>> (XEN) Pending irq=2
> >> >>>
> >> >>> But I see that after I got hang - maintenance interrupts are generated
> >> >>> continuously. Platform continues printing the same log till reboot.
> >> >>
> >> >> Exactly the same log? As in the one above you just pasted?
> >> >> That is very very suspicious.
> >> >
> >> > Yes exactly the same log. And looks like it means that LRs are flushed
> >> > correctly.
> >> >
> >> >>
> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >> >> new maintenance interrupt immediately causing an infinite loop.
> >> >>
> >> >
> >> > Yes, this is what I'm thinking about. Taking in account all collected
> >> > debug info it looks like once LRs are overloaded with SGIs -
> >> > maintenance interrupt occurs.
> >> > And then it is not handled properly, and occurs again and again - so
> >> > platform hangs inside its handler.
> >> >
> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >> >> hypervisor entry.
> >> >>
> >> >
> >> > Now trying.
> >> >
> >> >>
> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> index 4d2a92d..6ae8dc4 100644
> >> >> --- a/xen/arch/arm/gic.c
> >> >> +++ b/xen/arch/arm/gic.c
> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >> >>      if ( is_idle_vcpu(v) )
> >> >>          return;
> >> >>
> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> +
> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >> >>
> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >> >>
> >> >>      gic_restore_pending_irqs(current);
> >> >>
> >> >> -
> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> -    else
> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> -
> >> >>  }
> >> >>
> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >> >
> >>
> >> Heh - I don't see hangs with this patch :) But also I see that
> >> maintenance interrupt doesn't occur (and no hang as result)
> >> Stefano - is this expected?
> >
> > No maintenance interrupts at all? That's strange. You should be
> > receiving them when LRs are full and you still have interrupts pending
> > to be added to them.
> >
> > You could add another printk here to see if you should be receiving
> > them:
> >
> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> > +    {
> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
> > -    else
> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > -
> > +    }
> >  }
> >
> 
> Requested properly:
> 
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> 
> But does not occur

OK, let's see what's going on then by printing the irq number of the
maintenance interrupt:

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 4d2a92d..fed3167 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -55,6 +55,7 @@ static struct {
 static DEFINE_PER_CPU(uint64_t, lr_mask);
 
 static uint8_t nr_lrs;
+static bool uie_on;
 #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
 
 /* The GIC mapping of CPU interfaces does not necessarily match the
@@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
 {
     int i = 0;
     unsigned long flags;
+    unsigned long hcr;
 
     /* The idle domain has no LRs to be cleared. Since gic_restore_state
      * doesn't write any LR registers for the idle domain they could be
@@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    hcr = GICH[GICH_HCR];
+    if ( hcr & GICH_HCR_UIE )
+    {
+        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
+        uie_on = 1;
+    }
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
         intack = GICC[GICC_IAR];
         irq = intack & GICC_IA_IRQ;
 
+        if ( uie_on )
+        {
+            uie_on = 0;
+            printk("received maintenance interrupt irq=%d\n", irq);
+        }
         if ( likely(irq >= 16 && irq < 1021) )
         {
             local_irq_enable();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:52:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16: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 1Xr8U3-0004SQ-F0; Wed, 19 Nov 2014 16:51:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr8U2-0004SL-8P
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:51:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	28/AD-25276-DAACC645; Wed, 19 Nov 2014 16:51:57 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416415913!13954555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8883 invoked from network); 19 Nov 2014 16:51:56 -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;
	19 Nov 2014 16:51:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194463619"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:50:59 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr8T4-0006qh-51;
	Wed, 19 Nov 2014 16:50:58 +0000
Date: Wed, 19 Nov 2014 16:50:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >>> Hi Stefano,
> >> >>>
> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >>> >> Hi Stefano,
> >> >>> >>
> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >> >>> >> > >      else
> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >> >>> >> > >
> >> >>> >> > >  }
> >> >>> >> >
> >> >>> >> > Yes, exactly
> >> >>> >>
> >> >>> >> I tried, hang still occurs with this change
> >> >>> >
> >> >>> > We need to figure out why during the hang you still have all the LRs
> >> >>> > busy even if you are getting maintenance interrupts that should cause
> >> >>> > them to be cleared.
> >> >>> >
> >> >>>
> >> >>> I see that I have free LRs during maintenance interrupt
> >> >>>
> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >> >>> (XEN)    HW_LR[0]=9a015856
> >> >>> (XEN)    HW_LR[1]=0
> >> >>> (XEN)    HW_LR[2]=0
> >> >>> (XEN)    HW_LR[3]=0
> >> >>> (XEN) Inflight irq=86 lr=0
> >> >>> (XEN) Inflight irq=2 lr=255
> >> >>> (XEN) Pending irq=2
> >> >>>
> >> >>> But I see that after I got hang - maintenance interrupts are generated
> >> >>> continuously. Platform continues printing the same log till reboot.
> >> >>
> >> >> Exactly the same log? As in the one above you just pasted?
> >> >> That is very very suspicious.
> >> >
> >> > Yes exactly the same log. And looks like it means that LRs are flushed
> >> > correctly.
> >> >
> >> >>
> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >> >> new maintenance interrupt immediately causing an infinite loop.
> >> >>
> >> >
> >> > Yes, this is what I'm thinking about. Taking in account all collected
> >> > debug info it looks like once LRs are overloaded with SGIs -
> >> > maintenance interrupt occurs.
> >> > And then it is not handled properly, and occurs again and again - so
> >> > platform hangs inside its handler.
> >> >
> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >> >> hypervisor entry.
> >> >>
> >> >
> >> > Now trying.
> >> >
> >> >>
> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> index 4d2a92d..6ae8dc4 100644
> >> >> --- a/xen/arch/arm/gic.c
> >> >> +++ b/xen/arch/arm/gic.c
> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >> >>      if ( is_idle_vcpu(v) )
> >> >>          return;
> >> >>
> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> +
> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >> >>
> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >> >>
> >> >>      gic_restore_pending_irqs(current);
> >> >>
> >> >> -
> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> -    else
> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> -
> >> >>  }
> >> >>
> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >> >
> >>
> >> Heh - I don't see hangs with this patch :) But also I see that
> >> maintenance interrupt doesn't occur (and no hang as result)
> >> Stefano - is this expected?
> >
> > No maintenance interrupts at all? That's strange. You should be
> > receiving them when LRs are full and you still have interrupts pending
> > to be added to them.
> >
> > You could add another printk here to see if you should be receiving
> > them:
> >
> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> > +    {
> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
> > -    else
> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > -
> > +    }
> >  }
> >
> 
> Requested properly:
> 
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> 
> But does not occur

OK, let's see what's going on then by printing the irq number of the
maintenance interrupt:

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 4d2a92d..fed3167 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -55,6 +55,7 @@ static struct {
 static DEFINE_PER_CPU(uint64_t, lr_mask);
 
 static uint8_t nr_lrs;
+static bool uie_on;
 #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
 
 /* The GIC mapping of CPU interfaces does not necessarily match the
@@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
 {
     int i = 0;
     unsigned long flags;
+    unsigned long hcr;
 
     /* The idle domain has no LRs to be cleared. Since gic_restore_state
      * doesn't write any LR registers for the idle domain they could be
@@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    hcr = GICH[GICH_HCR];
+    if ( hcr & GICH_HCR_UIE )
+    {
+        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
+        uie_on = 1;
+    }
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
         intack = GICC[GICC_IAR];
         irq = intack & GICC_IA_IRQ;
 
+        if ( uie_on )
+        {
+            uie_on = 0;
+            printk("received maintenance interrupt irq=%d\n", irq);
+        }
         if ( likely(irq >= 16 && irq < 1021) )
         {
             local_irq_enable();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:52:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:52:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8Ua-0004VL-SK; Wed, 19 Nov 2014 16:52:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr8UZ-0004VA-E1
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:52:31 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	80/F5-07724-ECACC645; Wed, 19 Nov 2014 16:52:30 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416415946!12487144!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3266 invoked from network); 19 Nov 2014 16:52:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:52:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194464140"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:52:24 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr8UR-0006ra-Lr;
	Wed, 19 Nov 2014 16:52:23 +0000
Date: Wed, 19 Nov 2014 16:52:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMOBuWU+3HBy=MMhRZxpjBHOiHCBgWedXZ6f0EgzVCWkFQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191650390.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<CAH_mUMPRUqFWbwwn0QqMuFpD-6YfNC2wJF0xKeg4yUVMj6rLDg@mail.gmail.com>
	<CAH_mUMOBuWU+3HBy=MMhRZxpjBHOiHCBgWedXZ6f0EgzVCWkFQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

No, that's for requesting a maintenance interrupt for a specific irq
when it is EOI'ed by the guest.

In our case we are requesting maintenance interrupts via UIE: a single
global maintenance interrupt when most LRs become free.

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> BTW - shouldn't this flag GICH_LR_MAINTENANCE_IRQ be set after
> maintenance interrupt requesting ?
> 
> On Wed, Nov 19, 2014 at 6:32 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > Gic dump during interrupt requesting:
> >
> > (XEN) GICH_LRs (vcpu 0) mask=f
> > (XEN)    HW_LR[0]=3a00001f
> > (XEN)    HW_LR[1]=9a015856
> > (XEN)    HW_LR[2]=1a00001b
> > (XEN)    HW_LR[3]=9a00e439
> > (XEN) Inflight irq=31 lr=0
> > (XEN) Inflight irq=86 lr=1
> > (XEN) Inflight irq=27 lr=2
> > (XEN) Inflight irq=57 lr=3
> > (XEN) Inflight irq=2 lr=255
> > (XEN) Pending irq=2
> >
> > On Wed, Nov 19, 2014 at 6:29 PM, Andrii Tseglytskyi
> > <andrii.tseglytskyi@globallogic.com> wrote:
> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>>> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >>>> <andrii.tseglytskyi@globallogic.com> wrote:
> >>>> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >>>> > <stefano.stabellini@eu.citrix.com> wrote:
> >>>> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>>> >>> Hi Stefano,
> >>>> >>>
> >>>> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >>>> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>>> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>>> >>> >> Hi Stefano,
> >>>> >>> >>
> >>>> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>>> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>>> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >>>> >>> >> > >      else
> >>>> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>>> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >>>> >>> >> > >
> >>>> >>> >> > >  }
> >>>> >>> >> >
> >>>> >>> >> > Yes, exactly
> >>>> >>> >>
> >>>> >>> >> I tried, hang still occurs with this change
> >>>> >>> >
> >>>> >>> > We need to figure out why during the hang you still have all the LRs
> >>>> >>> > busy even if you are getting maintenance interrupts that should cause
> >>>> >>> > them to be cleared.
> >>>> >>> >
> >>>> >>>
> >>>> >>> I see that I have free LRs during maintenance interrupt
> >>>> >>>
> >>>> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >>>> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >>>> >>> (XEN)    HW_LR[0]=9a015856
> >>>> >>> (XEN)    HW_LR[1]=0
> >>>> >>> (XEN)    HW_LR[2]=0
> >>>> >>> (XEN)    HW_LR[3]=0
> >>>> >>> (XEN) Inflight irq=86 lr=0
> >>>> >>> (XEN) Inflight irq=2 lr=255
> >>>> >>> (XEN) Pending irq=2
> >>>> >>>
> >>>> >>> But I see that after I got hang - maintenance interrupts are generated
> >>>> >>> continuously. Platform continues printing the same log till reboot.
> >>>> >>
> >>>> >> Exactly the same log? As in the one above you just pasted?
> >>>> >> That is very very suspicious.
> >>>> >
> >>>> > Yes exactly the same log. And looks like it means that LRs are flushed
> >>>> > correctly.
> >>>> >
> >>>> >>
> >>>> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >>>> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >>>> >> new maintenance interrupt immediately causing an infinite loop.
> >>>> >>
> >>>> >
> >>>> > Yes, this is what I'm thinking about. Taking in account all collected
> >>>> > debug info it looks like once LRs are overloaded with SGIs -
> >>>> > maintenance interrupt occurs.
> >>>> > And then it is not handled properly, and occurs again and again - so
> >>>> > platform hangs inside its handler.
> >>>> >
> >>>> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >>>> >> hypervisor entry.
> >>>> >>
> >>>> >
> >>>> > Now trying.
> >>>> >
> >>>> >>
> >>>> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>>> >> index 4d2a92d..6ae8dc4 100644
> >>>> >> --- a/xen/arch/arm/gic.c
> >>>> >> +++ b/xen/arch/arm/gic.c
> >>>> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >>>> >>      if ( is_idle_vcpu(v) )
> >>>> >>          return;
> >>>> >>
> >>>> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>>> >> +
> >>>> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>>> >>
> >>>> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >>>> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >>>> >>
> >>>> >>      gic_restore_pending_irqs(current);
> >>>> >>
> >>>> >> -
> >>>> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>>> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>>> >> -    else
> >>>> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>>> >> -
> >>>> >>  }
> >>>> >>
> >>>> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >>>> >
> >>>>
> >>>> Heh - I don't see hangs with this patch :) But also I see that
> >>>> maintenance interrupt doesn't occur (and no hang as result)
> >>>> Stefano - is this expected?
> >>>
> >>> No maintenance interrupts at all? That's strange. You should be
> >>> receiving them when LRs are full and you still have interrupts pending
> >>> to be added to them.
> >>>
> >>> You could add another printk here to see if you should be receiving
> >>> them:
> >>>
> >>>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> +    {
> >>> +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >>>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> -    else
> >>> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> -
> >>> +    }
> >>>  }
> >>>
> >>
> >> Requested properly:
> >>
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>
> >> But does not occur
> >>
> >>
> >>>
> >>>> >
> >>>> >
> >>>> > --
> >>>> >
> >>>> > Andrii Tseglytskyi | Embedded Dev
> >>>> > GlobalLogic
> >>>> > www.globallogic.com
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Andrii Tseglytskyi | Embedded Dev
> >>>> GlobalLogic
> >>>> www.globallogic.com
> >>>>
> >>
> >>
> >>
> >> --
> >>
> >> Andrii Tseglytskyi | Embedded Dev
> >> GlobalLogic
> >> www.globallogic.com
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 16:52:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 16:52:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8Ua-0004VL-SK; Wed, 19 Nov 2014 16:52:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr8UZ-0004VA-E1
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 16:52:31 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	80/F5-07724-ECACC645; Wed, 19 Nov 2014 16:52:30 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416415946!12487144!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3266 invoked from network); 19 Nov 2014 16:52:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 16:52:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194464140"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 11:52:24 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr8UR-0006ra-Lr;
	Wed, 19 Nov 2014 16:52:23 +0000
Date: Wed, 19 Nov 2014 16:52:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMOBuWU+3HBy=MMhRZxpjBHOiHCBgWedXZ6f0EgzVCWkFQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191650390.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<CAH_mUMPRUqFWbwwn0QqMuFpD-6YfNC2wJF0xKeg4yUVMj6rLDg@mail.gmail.com>
	<CAH_mUMOBuWU+3HBy=MMhRZxpjBHOiHCBgWedXZ6f0EgzVCWkFQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

No, that's for requesting a maintenance interrupt for a specific irq
when it is EOI'ed by the guest.

In our case we are requesting maintenance interrupts via UIE: a single
global maintenance interrupt when most LRs become free.

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> BTW - shouldn't this flag GICH_LR_MAINTENANCE_IRQ be set after
> maintenance interrupt requesting ?
> 
> On Wed, Nov 19, 2014 at 6:32 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > Gic dump during interrupt requesting:
> >
> > (XEN) GICH_LRs (vcpu 0) mask=f
> > (XEN)    HW_LR[0]=3a00001f
> > (XEN)    HW_LR[1]=9a015856
> > (XEN)    HW_LR[2]=1a00001b
> > (XEN)    HW_LR[3]=9a00e439
> > (XEN) Inflight irq=31 lr=0
> > (XEN) Inflight irq=86 lr=1
> > (XEN) Inflight irq=27 lr=2
> > (XEN) Inflight irq=57 lr=3
> > (XEN) Inflight irq=2 lr=255
> > (XEN) Pending irq=2
> >
> > On Wed, Nov 19, 2014 at 6:29 PM, Andrii Tseglytskyi
> > <andrii.tseglytskyi@globallogic.com> wrote:
> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>>> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >>>> <andrii.tseglytskyi@globallogic.com> wrote:
> >>>> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >>>> > <stefano.stabellini@eu.citrix.com> wrote:
> >>>> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>>> >>> Hi Stefano,
> >>>> >>>
> >>>> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >>>> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>>> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>>> >>> >> Hi Stefano,
> >>>> >>> >>
> >>>> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>>> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>>> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >>>> >>> >> > >      else
> >>>> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>>> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >>>> >>> >> > >
> >>>> >>> >> > >  }
> >>>> >>> >> >
> >>>> >>> >> > Yes, exactly
> >>>> >>> >>
> >>>> >>> >> I tried, hang still occurs with this change
> >>>> >>> >
> >>>> >>> > We need to figure out why during the hang you still have all the LRs
> >>>> >>> > busy even if you are getting maintenance interrupts that should cause
> >>>> >>> > them to be cleared.
> >>>> >>> >
> >>>> >>>
> >>>> >>> I see that I have free LRs during maintenance interrupt
> >>>> >>>
> >>>> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >>>> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >>>> >>> (XEN)    HW_LR[0]=9a015856
> >>>> >>> (XEN)    HW_LR[1]=0
> >>>> >>> (XEN)    HW_LR[2]=0
> >>>> >>> (XEN)    HW_LR[3]=0
> >>>> >>> (XEN) Inflight irq=86 lr=0
> >>>> >>> (XEN) Inflight irq=2 lr=255
> >>>> >>> (XEN) Pending irq=2
> >>>> >>>
> >>>> >>> But I see that after I got hang - maintenance interrupts are generated
> >>>> >>> continuously. Platform continues printing the same log till reboot.
> >>>> >>
> >>>> >> Exactly the same log? As in the one above you just pasted?
> >>>> >> That is very very suspicious.
> >>>> >
> >>>> > Yes exactly the same log. And looks like it means that LRs are flushed
> >>>> > correctly.
> >>>> >
> >>>> >>
> >>>> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >>>> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >>>> >> new maintenance interrupt immediately causing an infinite loop.
> >>>> >>
> >>>> >
> >>>> > Yes, this is what I'm thinking about. Taking in account all collected
> >>>> > debug info it looks like once LRs are overloaded with SGIs -
> >>>> > maintenance interrupt occurs.
> >>>> > And then it is not handled properly, and occurs again and again - so
> >>>> > platform hangs inside its handler.
> >>>> >
> >>>> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >>>> >> hypervisor entry.
> >>>> >>
> >>>> >
> >>>> > Now trying.
> >>>> >
> >>>> >>
> >>>> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>>> >> index 4d2a92d..6ae8dc4 100644
> >>>> >> --- a/xen/arch/arm/gic.c
> >>>> >> +++ b/xen/arch/arm/gic.c
> >>>> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >>>> >>      if ( is_idle_vcpu(v) )
> >>>> >>          return;
> >>>> >>
> >>>> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>>> >> +
> >>>> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>>> >>
> >>>> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >>>> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >>>> >>
> >>>> >>      gic_restore_pending_irqs(current);
> >>>> >>
> >>>> >> -
> >>>> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>>> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>>> >> -    else
> >>>> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>>> >> -
> >>>> >>  }
> >>>> >>
> >>>> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >>>> >
> >>>>
> >>>> Heh - I don't see hangs with this patch :) But also I see that
> >>>> maintenance interrupt doesn't occur (and no hang as result)
> >>>> Stefano - is this expected?
> >>>
> >>> No maintenance interrupts at all? That's strange. You should be
> >>> receiving them when LRs are full and you still have interrupts pending
> >>> to be added to them.
> >>>
> >>> You could add another printk here to see if you should be receiving
> >>> them:
> >>>
> >>>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> +    {
> >>> +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >>>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> -    else
> >>> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> -
> >>> +    }
> >>>  }
> >>>
> >>
> >> Requested properly:
> >>
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>
> >> But does not occur
> >>
> >>
> >>>
> >>>> >
> >>>> >
> >>>> > --
> >>>> >
> >>>> > Andrii Tseglytskyi | Embedded Dev
> >>>> > GlobalLogic
> >>>> > www.globallogic.com
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Andrii Tseglytskyi | Embedded Dev
> >>>> GlobalLogic
> >>>> www.globallogic.com
> >>>>
> >>
> >>
> >>
> >> --
> >>
> >> Andrii Tseglytskyi | Embedded Dev
> >> GlobalLogic
> >> www.globallogic.com
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:03:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8fH-0004x9-BZ; Wed, 19 Nov 2014 17:03:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr8fF-0004wt-UU
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:03:34 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	23/1D-26858-56DCC645; Wed, 19 Nov 2014 17:03:33 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416416609!12506775!1
X-Originating-IP: [64.18.0.24]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2204 invoked from network); 19 Nov 2014 17:03:31 -0000
Received: from exprod5og112.obsmtp.com (HELO exprod5og112.obsmtp.com)
	(64.18.0.24)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 17:03:31 -0000
Received: from mail-qg0-f47.google.com ([209.85.192.47]) (using TLSv1) by
	exprod5ob112.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzNYamkzclYVxtRBJ+AEg2vLv35jLqu@postini.com;
	Wed, 19 Nov 2014 09:03:31 PST
Received: by mail-qg0-f47.google.com with SMTP id z60so734264qgd.6
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 09:03:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=28mrOg2y6/s/2gHo5vTLWQ9s16XD1R+T57NGFgN9+sU=;
	b=Odlbg36YshjiXce2+mLNcQVqP8OQ4j8cYbKu3g2zC4LOwTErbpVnpjzfljYDDNQ8tk
	vSn9jX4fnvDXNpc/YvdMbmmWLvf4mgI3FBtVQHHw6EJcvJGhuW6Osyy8TkM9FBtuVe31
	Ngk6MKlM0Dql0fKGtiCX6bp/IAu9kJJ039fzE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=28mrOg2y6/s/2gHo5vTLWQ9s16XD1R+T57NGFgN9+sU=;
	b=l70NYA7qma1DtLrFSXQGR7ng5tZbOL2EtjegQ2sI/TRx8QdSr+fmh4PXEHlVvhRUBJ
	/INmy7n0eJRPwWlCGRFdcfW1tbyWwf1QQ942QVwAs6usJjSBA0/FglVcs/oN+ZGTT842
	JjVivv/JlsPuatmAfsAUMcNNWUF66bJvMFOT5YM4N1A0RoPomeu8LzsHo28JEjqN9j/Z
	qCS9mmkhakwhoeu/GbgSqsI5CzWoO8y2SuDy8Bjg04DhJYdWgpGOtgdnhv7DcFze01O/
	jvF6LCwLx5VjmIlu8jHgOf/Xbq1OhcNTZngbE2rK4Zo4ioVFqEubbRTX7QLkN8FwlOqB
	Qj0Q==
X-Gm-Message-State: ALoCoQn6E0v7T9EXlk7TUSDSmCauaJNHsMCfp3OizIzZgxFiClYdxAWQqHQEpCY2G3nesbb6PaO11Tvc82Cv3g7WurDV70BQhjtl938imgOUdBYsnyCG6oXNrYNqslXiQhlUu3e8HPwC9/cxUUUYOXIJnqLgzjXBlw==
X-Received: by 10.140.80.136 with SMTP id c8mr51832842qgd.86.1416416609102;
	Wed, 19 Nov 2014 09:03:29 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.80.136 with SMTP id c8mr51832818qgd.86.1416416608907;
	Wed, 19 Nov 2014 09:03:28 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 09:03:28 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 19:03:28 +0200
Message-ID: <CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I got this strange log:

(XEN) received maintenance interrupt irq=1023

And platform does not hang due to this:
+    hcr = GICH[GICH_HCR];
+    if ( hcr & GICH_HCR_UIE )
+    {
+        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
+        uie_on = 1;
+    }

On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>> >> <andrii.tseglytskyi@globallogic.com> wrote:
>> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>> >> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >>> Hi Stefano,
>> >> >>>
>> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >>> >> Hi Stefano,
>> >> >>> >>
>> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> >> >>> >> > >      else
>> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> >> >>> >> > >
>> >> >>> >> > >  }
>> >> >>> >> >
>> >> >>> >> > Yes, exactly
>> >> >>> >>
>> >> >>> >> I tried, hang still occurs with this change
>> >> >>> >
>> >> >>> > We need to figure out why during the hang you still have all the LRs
>> >> >>> > busy even if you are getting maintenance interrupts that should cause
>> >> >>> > them to be cleared.
>> >> >>> >
>> >> >>>
>> >> >>> I see that I have free LRs during maintenance interrupt
>> >> >>>
>> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>> >> >>> (XEN)    HW_LR[0]=9a015856
>> >> >>> (XEN)    HW_LR[1]=0
>> >> >>> (XEN)    HW_LR[2]=0
>> >> >>> (XEN)    HW_LR[3]=0
>> >> >>> (XEN) Inflight irq=86 lr=0
>> >> >>> (XEN) Inflight irq=2 lr=255
>> >> >>> (XEN) Pending irq=2
>> >> >>>
>> >> >>> But I see that after I got hang - maintenance interrupts are generated
>> >> >>> continuously. Platform continues printing the same log till reboot.
>> >> >>
>> >> >> Exactly the same log? As in the one above you just pasted?
>> >> >> That is very very suspicious.
>> >> >
>> >> > Yes exactly the same log. And looks like it means that LRs are flushed
>> >> > correctly.
>> >> >
>> >> >>
>> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
>> >> >> new maintenance interrupt immediately causing an infinite loop.
>> >> >>
>> >> >
>> >> > Yes, this is what I'm thinking about. Taking in account all collected
>> >> > debug info it looks like once LRs are overloaded with SGIs -
>> >> > maintenance interrupt occurs.
>> >> > And then it is not handled properly, and occurs again and again - so
>> >> > platform hangs inside its handler.
>> >> >
>> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>> >> >> hypervisor entry.
>> >> >>
>> >> >
>> >> > Now trying.
>> >> >
>> >> >>
>> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >> index 4d2a92d..6ae8dc4 100644
>> >> >> --- a/xen/arch/arm/gic.c
>> >> >> +++ b/xen/arch/arm/gic.c
>> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>> >> >>      if ( is_idle_vcpu(v) )
>> >> >>          return;
>> >> >>
>> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> +
>> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >> >>
>> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>> >> >>
>> >> >>      gic_restore_pending_irqs(current);
>> >> >>
>> >> >> -
>> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> -    else
>> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> -
>> >> >>  }
>> >> >>
>> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>> >> >
>> >>
>> >> Heh - I don't see hangs with this patch :) But also I see that
>> >> maintenance interrupt doesn't occur (and no hang as result)
>> >> Stefano - is this expected?
>> >
>> > No maintenance interrupts at all? That's strange. You should be
>> > receiving them when LRs are full and you still have interrupts pending
>> > to be added to them.
>> >
>> > You could add another printk here to see if you should be receiving
>> > them:
>> >
>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> > +    {
>> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> > -    else
>> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> > -
>> > +    }
>> >  }
>> >
>>
>> Requested properly:
>>
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>
>> But does not occur
>
> OK, let's see what's going on then by printing the irq number of the
> maintenance interrupt:
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 4d2a92d..fed3167 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -55,6 +55,7 @@ static struct {
>  static DEFINE_PER_CPU(uint64_t, lr_mask);
>
>  static uint8_t nr_lrs;
> +static bool uie_on;
>  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
>
>  /* The GIC mapping of CPU interfaces does not necessarily match the
> @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
>  {
>      int i = 0;
>      unsigned long flags;
> +    unsigned long hcr;
>
>      /* The idle domain has no LRs to be cleared. Since gic_restore_state
>       * doesn't write any LR registers for the idle domain they could be
> @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>
> +    hcr = GICH[GICH_HCR];
> +    if ( hcr & GICH_HCR_UIE )
> +    {
> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> +        uie_on = 1;
> +    }
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>          intack = GICC[GICC_IAR];
>          irq = intack & GICC_IA_IRQ;
>
> +        if ( uie_on )
> +        {
> +            uie_on = 0;
> +            printk("received maintenance interrupt irq=%d\n", irq);
> +        }
>          if ( likely(irq >= 16 && irq < 1021) )
>          {
>              local_irq_enable();



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:03:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8fH-0004x9-BZ; Wed, 19 Nov 2014 17:03:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr8fF-0004wt-UU
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:03:34 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	23/1D-26858-56DCC645; Wed, 19 Nov 2014 17:03:33 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416416609!12506775!1
X-Originating-IP: [64.18.0.24]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2204 invoked from network); 19 Nov 2014 17:03:31 -0000
Received: from exprod5og112.obsmtp.com (HELO exprod5og112.obsmtp.com)
	(64.18.0.24)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 17:03:31 -0000
Received: from mail-qg0-f47.google.com ([209.85.192.47]) (using TLSv1) by
	exprod5ob112.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzNYamkzclYVxtRBJ+AEg2vLv35jLqu@postini.com;
	Wed, 19 Nov 2014 09:03:31 PST
Received: by mail-qg0-f47.google.com with SMTP id z60so734264qgd.6
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 09:03:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=28mrOg2y6/s/2gHo5vTLWQ9s16XD1R+T57NGFgN9+sU=;
	b=Odlbg36YshjiXce2+mLNcQVqP8OQ4j8cYbKu3g2zC4LOwTErbpVnpjzfljYDDNQ8tk
	vSn9jX4fnvDXNpc/YvdMbmmWLvf4mgI3FBtVQHHw6EJcvJGhuW6Osyy8TkM9FBtuVe31
	Ngk6MKlM0Dql0fKGtiCX6bp/IAu9kJJ039fzE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=28mrOg2y6/s/2gHo5vTLWQ9s16XD1R+T57NGFgN9+sU=;
	b=l70NYA7qma1DtLrFSXQGR7ng5tZbOL2EtjegQ2sI/TRx8QdSr+fmh4PXEHlVvhRUBJ
	/INmy7n0eJRPwWlCGRFdcfW1tbyWwf1QQ942QVwAs6usJjSBA0/FglVcs/oN+ZGTT842
	JjVivv/JlsPuatmAfsAUMcNNWUF66bJvMFOT5YM4N1A0RoPomeu8LzsHo28JEjqN9j/Z
	qCS9mmkhakwhoeu/GbgSqsI5CzWoO8y2SuDy8Bjg04DhJYdWgpGOtgdnhv7DcFze01O/
	jvF6LCwLx5VjmIlu8jHgOf/Xbq1OhcNTZngbE2rK4Zo4ioVFqEubbRTX7QLkN8FwlOqB
	Qj0Q==
X-Gm-Message-State: ALoCoQn6E0v7T9EXlk7TUSDSmCauaJNHsMCfp3OizIzZgxFiClYdxAWQqHQEpCY2G3nesbb6PaO11Tvc82Cv3g7WurDV70BQhjtl938imgOUdBYsnyCG6oXNrYNqslXiQhlUu3e8HPwC9/cxUUUYOXIJnqLgzjXBlw==
X-Received: by 10.140.80.136 with SMTP id c8mr51832842qgd.86.1416416609102;
	Wed, 19 Nov 2014 09:03:29 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.80.136 with SMTP id c8mr51832818qgd.86.1416416608907;
	Wed, 19 Nov 2014 09:03:28 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 09:03:28 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 19:03:28 +0200
Message-ID: <CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I got this strange log:

(XEN) received maintenance interrupt irq=1023

And platform does not hang due to this:
+    hcr = GICH[GICH_HCR];
+    if ( hcr & GICH_HCR_UIE )
+    {
+        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
+        uie_on = 1;
+    }

On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>> >> <andrii.tseglytskyi@globallogic.com> wrote:
>> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>> >> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >>> Hi Stefano,
>> >> >>>
>> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >>> >> Hi Stefano,
>> >> >>> >>
>> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> >> >>> >> > >      else
>> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> >> >>> >> > >
>> >> >>> >> > >  }
>> >> >>> >> >
>> >> >>> >> > Yes, exactly
>> >> >>> >>
>> >> >>> >> I tried, hang still occurs with this change
>> >> >>> >
>> >> >>> > We need to figure out why during the hang you still have all the LRs
>> >> >>> > busy even if you are getting maintenance interrupts that should cause
>> >> >>> > them to be cleared.
>> >> >>> >
>> >> >>>
>> >> >>> I see that I have free LRs during maintenance interrupt
>> >> >>>
>> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>> >> >>> (XEN)    HW_LR[0]=9a015856
>> >> >>> (XEN)    HW_LR[1]=0
>> >> >>> (XEN)    HW_LR[2]=0
>> >> >>> (XEN)    HW_LR[3]=0
>> >> >>> (XEN) Inflight irq=86 lr=0
>> >> >>> (XEN) Inflight irq=2 lr=255
>> >> >>> (XEN) Pending irq=2
>> >> >>>
>> >> >>> But I see that after I got hang - maintenance interrupts are generated
>> >> >>> continuously. Platform continues printing the same log till reboot.
>> >> >>
>> >> >> Exactly the same log? As in the one above you just pasted?
>> >> >> That is very very suspicious.
>> >> >
>> >> > Yes exactly the same log. And looks like it means that LRs are flushed
>> >> > correctly.
>> >> >
>> >> >>
>> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
>> >> >> new maintenance interrupt immediately causing an infinite loop.
>> >> >>
>> >> >
>> >> > Yes, this is what I'm thinking about. Taking in account all collected
>> >> > debug info it looks like once LRs are overloaded with SGIs -
>> >> > maintenance interrupt occurs.
>> >> > And then it is not handled properly, and occurs again and again - so
>> >> > platform hangs inside its handler.
>> >> >
>> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>> >> >> hypervisor entry.
>> >> >>
>> >> >
>> >> > Now trying.
>> >> >
>> >> >>
>> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >> index 4d2a92d..6ae8dc4 100644
>> >> >> --- a/xen/arch/arm/gic.c
>> >> >> +++ b/xen/arch/arm/gic.c
>> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>> >> >>      if ( is_idle_vcpu(v) )
>> >> >>          return;
>> >> >>
>> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> +
>> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >> >>
>> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>> >> >>
>> >> >>      gic_restore_pending_irqs(current);
>> >> >>
>> >> >> -
>> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> -    else
>> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> -
>> >> >>  }
>> >> >>
>> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>> >> >
>> >>
>> >> Heh - I don't see hangs with this patch :) But also I see that
>> >> maintenance interrupt doesn't occur (and no hang as result)
>> >> Stefano - is this expected?
>> >
>> > No maintenance interrupts at all? That's strange. You should be
>> > receiving them when LRs are full and you still have interrupts pending
>> > to be added to them.
>> >
>> > You could add another printk here to see if you should be receiving
>> > them:
>> >
>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> > +    {
>> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> > -    else
>> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> > -
>> > +    }
>> >  }
>> >
>>
>> Requested properly:
>>
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>
>> But does not occur
>
> OK, let's see what's going on then by printing the irq number of the
> maintenance interrupt:
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 4d2a92d..fed3167 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -55,6 +55,7 @@ static struct {
>  static DEFINE_PER_CPU(uint64_t, lr_mask);
>
>  static uint8_t nr_lrs;
> +static bool uie_on;
>  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
>
>  /* The GIC mapping of CPU interfaces does not necessarily match the
> @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
>  {
>      int i = 0;
>      unsigned long flags;
> +    unsigned long hcr;
>
>      /* The idle domain has no LRs to be cleared. Since gic_restore_state
>       * doesn't write any LR registers for the idle domain they could be
> @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>
> +    hcr = GICH[GICH_HCR];
> +    if ( hcr & GICH_HCR_UIE )
> +    {
> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> +        uie_on = 1;
> +    }
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>          intack = GICC[GICC_IAR];
>          irq = intack & GICC_IA_IRQ;
>
> +        if ( uie_on )
> +        {
> +            uie_on = 0;
> +            printk("received maintenance interrupt irq=%d\n", irq);
> +        }
>          if ( likely(irq >= 16 && irq < 1021) )
>          {
>              local_irq_enable();



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:12:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:12:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8nZ-0005B3-CW; Wed, 19 Nov 2014 17:12:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr8nX-0005Av-Cv
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:12:07 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	77/20-28296-26FCC645; Wed, 19 Nov 2014 17:12:02 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416417118!12538227!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13756 invoked from network); 19 Nov 2014 17:12:00 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 17:12:00 -0000
Received: from mail-qc0-f169.google.com ([209.85.216.169]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzPXj/NnKiPV9mTfWKptZoHjnenNbCJ@postini.com;
	Wed, 19 Nov 2014 09:12:00 PST
Received: by mail-qc0-f169.google.com with SMTP id w7so760017qcr.28
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 09:11:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=NGl0cKXgddXYlHtif1LRX5m47/+DREAOovbzZSeYz3o=;
	b=cu6n1Qokk0+wwoGcSE5+cTeguRzTJ1A7CItkR39Zl3An2DhaxPqtgUH1/KiFtsMbxe
	LCVWv69TMUZvIPwCoORTC3k2SLDoQ3HL9IuR7vwkHKJwLMeAH9GCgAaoaXK3pXNkIpEU
	KGo940AmtXhuKDVioP2ZY/GPG+zmSZ3LAjwV8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=NGl0cKXgddXYlHtif1LRX5m47/+DREAOovbzZSeYz3o=;
	b=T/fLFKyDCmwtM1W5xSD2CCE+U3ZiIa7d1/xjaTN8x0Ku00TvBUGGpOKlhQUcaR7myR
	ARsi+gbfZGUgeEQwBh/4qgAjfMoYQXIX6/K1M1NadzGMkLCHthQpXAUxtoH+2TMsgY2y
	APjMc8/xQcUBhrQiKa3hCHTYBa55Scl0xnVkyNbi3JJK0W+CCGxeZx8+T9RTNF7yuotL
	kQFQDtiXGqqqLKt9OgpusOzFRROlOOIjfLAzXh2MzfAk1OPfuPO69vWgTQaZVunkpmrT
	Im7uslr5u0ZSe2uSQsGZ7KdMutocBVTOKAOUPi77bs4DYJVZJLA4c3+/2MCLeLb15puw
	tBtQ==
X-Gm-Message-State: ALoCoQmJmnedvxM75btNwCdiXxAEUuQIetUxpGKcKduLmsK6rV8KieJGRurFAzwzMX8FxEOAkQ7YtbAQAM3RAfOjW4kUtrwdb+QWKZJF2Hl8XNHy54P3Qcl9N5dPtu1Ub2SR4JMHVUvHBft6iBO1Z3bt5zBShxsueg==
X-Received: by 10.224.92.81 with SMTP id q17mr52420709qam.66.1416417118050;
	Wed, 19 Nov 2014 09:11:58 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.92.81 with SMTP id q17mr52420676qam.66.1416417117815;
	Wed, 19 Nov 2014 09:11:57 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 09:11:57 -0800 (PST)
In-Reply-To: <CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
Date: Wed, 19 Nov 2014 19:11:57 +0200
Message-ID: <CAH_mUMMgL2jrD-M69P1t7qTHrNO6ar6hv984nRzu5b5OhUuMPw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Does number 1023 mean that maintenance interrupt is global?

On Wed, Nov 19, 2014 at 7:03 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> I got this strange log:
>
> (XEN) received maintenance interrupt irq=1023
>
> And platform does not hang due to this:
> +    hcr = GICH[GICH_HCR];
> +    if ( hcr & GICH_HCR_UIE )
> +    {
> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> +        uie_on = 1;
> +    }
>
> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>>> >> <andrii.tseglytskyi@globallogic.com> wrote:
>>> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>>> >> > <stefano.stabellini@eu.citrix.com> wrote:
>>> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >>> Hi Stefano,
>>> >> >>>
>>> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>>> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >>> >> Hi Stefano,
>>> >> >>> >>
>>> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>>> >> >>> >> > >      else
>>> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>>> >> >>> >> > >
>>> >> >>> >> > >  }
>>> >> >>> >> >
>>> >> >>> >> > Yes, exactly
>>> >> >>> >>
>>> >> >>> >> I tried, hang still occurs with this change
>>> >> >>> >
>>> >> >>> > We need to figure out why during the hang you still have all the LRs
>>> >> >>> > busy even if you are getting maintenance interrupts that should cause
>>> >> >>> > them to be cleared.
>>> >> >>> >
>>> >> >>>
>>> >> >>> I see that I have free LRs during maintenance interrupt
>>> >> >>>
>>> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>>> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>>> >> >>> (XEN)    HW_LR[0]=9a015856
>>> >> >>> (XEN)    HW_LR[1]=0
>>> >> >>> (XEN)    HW_LR[2]=0
>>> >> >>> (XEN)    HW_LR[3]=0
>>> >> >>> (XEN) Inflight irq=86 lr=0
>>> >> >>> (XEN) Inflight irq=2 lr=255
>>> >> >>> (XEN) Pending irq=2
>>> >> >>>
>>> >> >>> But I see that after I got hang - maintenance interrupts are generated
>>> >> >>> continuously. Platform continues printing the same log till reboot.
>>> >> >>
>>> >> >> Exactly the same log? As in the one above you just pasted?
>>> >> >> That is very very suspicious.
>>> >> >
>>> >> > Yes exactly the same log. And looks like it means that LRs are flushed
>>> >> > correctly.
>>> >> >
>>> >> >>
>>> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>>> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
>>> >> >> new maintenance interrupt immediately causing an infinite loop.
>>> >> >>
>>> >> >
>>> >> > Yes, this is what I'm thinking about. Taking in account all collected
>>> >> > debug info it looks like once LRs are overloaded with SGIs -
>>> >> > maintenance interrupt occurs.
>>> >> > And then it is not handled properly, and occurs again and again - so
>>> >> > platform hangs inside its handler.
>>> >> >
>>> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>>> >> >> hypervisor entry.
>>> >> >>
>>> >> >
>>> >> > Now trying.
>>> >> >
>>> >> >>
>>> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> >> >> index 4d2a92d..6ae8dc4 100644
>>> >> >> --- a/xen/arch/arm/gic.c
>>> >> >> +++ b/xen/arch/arm/gic.c
>>> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>>> >> >>      if ( is_idle_vcpu(v) )
>>> >> >>          return;
>>> >> >>
>>> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> +
>>> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>> >> >>
>>> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>>> >> >>
>>> >> >>      gic_restore_pending_irqs(current);
>>> >> >>
>>> >> >> -
>>> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> >> -    else
>>> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> -
>>> >> >>  }
>>> >> >>
>>> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>>> >> >
>>> >>
>>> >> Heh - I don't see hangs with this patch :) But also I see that
>>> >> maintenance interrupt doesn't occur (and no hang as result)
>>> >> Stefano - is this expected?
>>> >
>>> > No maintenance interrupts at all? That's strange. You should be
>>> > receiving them when LRs are full and you still have interrupts pending
>>> > to be added to them.
>>> >
>>> > You could add another printk here to see if you should be receiving
>>> > them:
>>> >
>>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> > +    {
>>> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>>> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> > -    else
>>> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> > -
>>> > +    }
>>> >  }
>>> >
>>>
>>> Requested properly:
>>>
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>>
>>> But does not occur
>>
>> OK, let's see what's going on then by printing the irq number of the
>> maintenance interrupt:
>>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 4d2a92d..fed3167 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -55,6 +55,7 @@ static struct {
>>  static DEFINE_PER_CPU(uint64_t, lr_mask);
>>
>>  static uint8_t nr_lrs;
>> +static bool uie_on;
>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
>>
>>  /* The GIC mapping of CPU interfaces does not necessarily match the
>> @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
>>  {
>>      int i = 0;
>>      unsigned long flags;
>> +    unsigned long hcr;
>>
>>      /* The idle domain has no LRs to be cleared. Since gic_restore_state
>>       * doesn't write any LR registers for the idle domain they could be
>> @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
>>      if ( is_idle_vcpu(v) )
>>          return;
>>
>> +    hcr = GICH[GICH_HCR];
>> +    if ( hcr & GICH_HCR_UIE )
>> +    {
>> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> +        uie_on = 1;
>> +    }
>> +
>>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>
>>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>>          intack = GICC[GICC_IAR];
>>          irq = intack & GICC_IA_IRQ;
>>
>> +        if ( uie_on )
>> +        {
>> +            uie_on = 0;
>> +            printk("received maintenance interrupt irq=%d\n", irq);
>> +        }
>>          if ( likely(irq >= 16 && irq < 1021) )
>>          {
>>              local_irq_enable();
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:12:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:12:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr8nZ-0005B3-CW; Wed, 19 Nov 2014 17:12:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr8nX-0005Av-Cv
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:12:07 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	77/20-28296-26FCC645; Wed, 19 Nov 2014 17:12:02 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416417118!12538227!1
X-Originating-IP: [64.18.0.186]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13756 invoked from network); 19 Nov 2014 17:12:00 -0000
Received: from exprod5og108.obsmtp.com (HELO exprod5og108.obsmtp.com)
	(64.18.0.186)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 17:12:00 -0000
Received: from mail-qc0-f169.google.com ([209.85.216.169]) (using TLSv1) by
	exprod5ob108.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzPXj/NnKiPV9mTfWKptZoHjnenNbCJ@postini.com;
	Wed, 19 Nov 2014 09:12:00 PST
Received: by mail-qc0-f169.google.com with SMTP id w7so760017qcr.28
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 09:11:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=NGl0cKXgddXYlHtif1LRX5m47/+DREAOovbzZSeYz3o=;
	b=cu6n1Qokk0+wwoGcSE5+cTeguRzTJ1A7CItkR39Zl3An2DhaxPqtgUH1/KiFtsMbxe
	LCVWv69TMUZvIPwCoORTC3k2SLDoQ3HL9IuR7vwkHKJwLMeAH9GCgAaoaXK3pXNkIpEU
	KGo940AmtXhuKDVioP2ZY/GPG+zmSZ3LAjwV8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=NGl0cKXgddXYlHtif1LRX5m47/+DREAOovbzZSeYz3o=;
	b=T/fLFKyDCmwtM1W5xSD2CCE+U3ZiIa7d1/xjaTN8x0Ku00TvBUGGpOKlhQUcaR7myR
	ARsi+gbfZGUgeEQwBh/4qgAjfMoYQXIX6/K1M1NadzGMkLCHthQpXAUxtoH+2TMsgY2y
	APjMc8/xQcUBhrQiKa3hCHTYBa55Scl0xnVkyNbi3JJK0W+CCGxeZx8+T9RTNF7yuotL
	kQFQDtiXGqqqLKt9OgpusOzFRROlOOIjfLAzXh2MzfAk1OPfuPO69vWgTQaZVunkpmrT
	Im7uslr5u0ZSe2uSQsGZ7KdMutocBVTOKAOUPi77bs4DYJVZJLA4c3+/2MCLeLb15puw
	tBtQ==
X-Gm-Message-State: ALoCoQmJmnedvxM75btNwCdiXxAEUuQIetUxpGKcKduLmsK6rV8KieJGRurFAzwzMX8FxEOAkQ7YtbAQAM3RAfOjW4kUtrwdb+QWKZJF2Hl8XNHy54P3Qcl9N5dPtu1Ub2SR4JMHVUvHBft6iBO1Z3bt5zBShxsueg==
X-Received: by 10.224.92.81 with SMTP id q17mr52420709qam.66.1416417118050;
	Wed, 19 Nov 2014 09:11:58 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.92.81 with SMTP id q17mr52420676qam.66.1416417117815;
	Wed, 19 Nov 2014 09:11:57 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 09:11:57 -0800 (PST)
In-Reply-To: <CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191055280.27247@kaball.uk.xensource.com>
	<CAH_mUMO-cU96VtsD_JrS6yBDgvfWsZC58HmMUW4Tvtx1H1DfKg@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
Date: Wed, 19 Nov 2014 19:11:57 +0200
Message-ID: <CAH_mUMMgL2jrD-M69P1t7qTHrNO6ar6hv984nRzu5b5OhUuMPw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Does number 1023 mean that maintenance interrupt is global?

On Wed, Nov 19, 2014 at 7:03 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> I got this strange log:
>
> (XEN) received maintenance interrupt irq=1023
>
> And platform does not hang due to this:
> +    hcr = GICH[GICH_HCR];
> +    if ( hcr & GICH_HCR_UIE )
> +    {
> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> +        uie_on = 1;
> +    }
>
> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>>> >> <andrii.tseglytskyi@globallogic.com> wrote:
>>> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>>> >> > <stefano.stabellini@eu.citrix.com> wrote:
>>> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >>> Hi Stefano,
>>> >> >>>
>>> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>>> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >>> >> Hi Stefano,
>>> >> >>> >>
>>> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>>> >> >>> >> > >      else
>>> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>>> >> >>> >> > >
>>> >> >>> >> > >  }
>>> >> >>> >> >
>>> >> >>> >> > Yes, exactly
>>> >> >>> >>
>>> >> >>> >> I tried, hang still occurs with this change
>>> >> >>> >
>>> >> >>> > We need to figure out why during the hang you still have all the LRs
>>> >> >>> > busy even if you are getting maintenance interrupts that should cause
>>> >> >>> > them to be cleared.
>>> >> >>> >
>>> >> >>>
>>> >> >>> I see that I have free LRs during maintenance interrupt
>>> >> >>>
>>> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>>> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>>> >> >>> (XEN)    HW_LR[0]=9a015856
>>> >> >>> (XEN)    HW_LR[1]=0
>>> >> >>> (XEN)    HW_LR[2]=0
>>> >> >>> (XEN)    HW_LR[3]=0
>>> >> >>> (XEN) Inflight irq=86 lr=0
>>> >> >>> (XEN) Inflight irq=2 lr=255
>>> >> >>> (XEN) Pending irq=2
>>> >> >>>
>>> >> >>> But I see that after I got hang - maintenance interrupts are generated
>>> >> >>> continuously. Platform continues printing the same log till reboot.
>>> >> >>
>>> >> >> Exactly the same log? As in the one above you just pasted?
>>> >> >> That is very very suspicious.
>>> >> >
>>> >> > Yes exactly the same log. And looks like it means that LRs are flushed
>>> >> > correctly.
>>> >> >
>>> >> >>
>>> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>>> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
>>> >> >> new maintenance interrupt immediately causing an infinite loop.
>>> >> >>
>>> >> >
>>> >> > Yes, this is what I'm thinking about. Taking in account all collected
>>> >> > debug info it looks like once LRs are overloaded with SGIs -
>>> >> > maintenance interrupt occurs.
>>> >> > And then it is not handled properly, and occurs again and again - so
>>> >> > platform hangs inside its handler.
>>> >> >
>>> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>>> >> >> hypervisor entry.
>>> >> >>
>>> >> >
>>> >> > Now trying.
>>> >> >
>>> >> >>
>>> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> >> >> index 4d2a92d..6ae8dc4 100644
>>> >> >> --- a/xen/arch/arm/gic.c
>>> >> >> +++ b/xen/arch/arm/gic.c
>>> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>>> >> >>      if ( is_idle_vcpu(v) )
>>> >> >>          return;
>>> >> >>
>>> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> +
>>> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>> >> >>
>>> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>>> >> >>
>>> >> >>      gic_restore_pending_irqs(current);
>>> >> >>
>>> >> >> -
>>> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> >> -    else
>>> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> -
>>> >> >>  }
>>> >> >>
>>> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>>> >> >
>>> >>
>>> >> Heh - I don't see hangs with this patch :) But also I see that
>>> >> maintenance interrupt doesn't occur (and no hang as result)
>>> >> Stefano - is this expected?
>>> >
>>> > No maintenance interrupts at all? That's strange. You should be
>>> > receiving them when LRs are full and you still have interrupts pending
>>> > to be added to them.
>>> >
>>> > You could add another printk here to see if you should be receiving
>>> > them:
>>> >
>>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> > +    {
>>> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>>> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> > -    else
>>> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> > -
>>> > +    }
>>> >  }
>>> >
>>>
>>> Requested properly:
>>>
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>>
>>> But does not occur
>>
>> OK, let's see what's going on then by printing the irq number of the
>> maintenance interrupt:
>>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 4d2a92d..fed3167 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -55,6 +55,7 @@ static struct {
>>  static DEFINE_PER_CPU(uint64_t, lr_mask);
>>
>>  static uint8_t nr_lrs;
>> +static bool uie_on;
>>  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
>>
>>  /* The GIC mapping of CPU interfaces does not necessarily match the
>> @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
>>  {
>>      int i = 0;
>>      unsigned long flags;
>> +    unsigned long hcr;
>>
>>      /* The idle domain has no LRs to be cleared. Since gic_restore_state
>>       * doesn't write any LR registers for the idle domain they could be
>> @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
>>      if ( is_idle_vcpu(v) )
>>          return;
>>
>> +    hcr = GICH[GICH_HCR];
>> +    if ( hcr & GICH_HCR_UIE )
>> +    {
>> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> +        uie_on = 1;
>> +    }
>> +
>>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>
>>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>>          intack = GICC[GICC_IAR];
>>          irq = intack & GICC_IA_IRQ;
>>
>> +        if ( uie_on )
>> +        {
>> +            uie_on = 0;
>> +            printk("received maintenance interrupt irq=%d\n", irq);
>> +        }
>>          if ( likely(irq >= 16 && irq < 1021) )
>>          {
>>              local_irq_enable();
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:20:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17: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.xen.org>)
	id 1Xr8vN-0005RE-Ds; Wed, 19 Nov 2014 17:20:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr8vL-0005R4-At
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:20:11 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	FF/68-02712-A41DC645; Wed, 19 Nov 2014 17:20:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416417608!13550031!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26604 invoked from network); 19 Nov 2014 17:20:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 17:20:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194470421"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:07:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr8jN-00077U-1B;
	Wed, 19 Nov 2014 17:07:49 +0000
Date: Wed, 19 Nov 2014 17:07:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I think that's OK: it looks like that on your board for some reasons
when UIE is set you get irq 1023 (spurious interrupt) instead of your
normal maintenance interrupt.

But everything should work anyway without issues.

This is the same patch as before but on top of the lastest xen-unstable
tree. Please confirm if it works.

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..df140b9 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -527,8 +529,6 @@ void gic_inject(void)
 
     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
         gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
-    else
-        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
 }
 
 static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> I got this strange log:
> 
> (XEN) received maintenance interrupt irq=1023
> 
> And platform does not hang due to this:
> +    hcr = GICH[GICH_HCR];
> +    if ( hcr & GICH_HCR_UIE )
> +    {
> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> +        uie_on = 1;
> +    }
> 
> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >>> Hi Stefano,
> >> >> >>>
> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >>> >> Hi Stefano,
> >> >> >>> >>
> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >> >> >>> >> > >      else
> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >> >> >>> >> > >
> >> >> >>> >> > >  }
> >> >> >>> >> >
> >> >> >>> >> > Yes, exactly
> >> >> >>> >>
> >> >> >>> >> I tried, hang still occurs with this change
> >> >> >>> >
> >> >> >>> > We need to figure out why during the hang you still have all the LRs
> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
> >> >> >>> > them to be cleared.
> >> >> >>> >
> >> >> >>>
> >> >> >>> I see that I have free LRs during maintenance interrupt
> >> >> >>>
> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >> >> >>> (XEN)    HW_LR[0]=9a015856
> >> >> >>> (XEN)    HW_LR[1]=0
> >> >> >>> (XEN)    HW_LR[2]=0
> >> >> >>> (XEN)    HW_LR[3]=0
> >> >> >>> (XEN) Inflight irq=86 lr=0
> >> >> >>> (XEN) Inflight irq=2 lr=255
> >> >> >>> (XEN) Pending irq=2
> >> >> >>>
> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
> >> >> >>> continuously. Platform continues printing the same log till reboot.
> >> >> >>
> >> >> >> Exactly the same log? As in the one above you just pasted?
> >> >> >> That is very very suspicious.
> >> >> >
> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
> >> >> > correctly.
> >> >> >
> >> >> >>
> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >> >> >> new maintenance interrupt immediately causing an infinite loop.
> >> >> >>
> >> >> >
> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
> >> >> > debug info it looks like once LRs are overloaded with SGIs -
> >> >> > maintenance interrupt occurs.
> >> >> > And then it is not handled properly, and occurs again and again - so
> >> >> > platform hangs inside its handler.
> >> >> >
> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >> >> >> hypervisor entry.
> >> >> >>
> >> >> >
> >> >> > Now trying.
> >> >> >
> >> >> >>
> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >> index 4d2a92d..6ae8dc4 100644
> >> >> >> --- a/xen/arch/arm/gic.c
> >> >> >> +++ b/xen/arch/arm/gic.c
> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >> >> >>      if ( is_idle_vcpu(v) )
> >> >> >>          return;
> >> >> >>
> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >> +
> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >> >> >>
> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >> >> >>
> >> >> >>      gic_restore_pending_irqs(current);
> >> >> >>
> >> >> >> -
> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> >> -    else
> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >> -
> >> >> >>  }
> >> >> >>
> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >> >> >
> >> >>
> >> >> Heh - I don't see hangs with this patch :) But also I see that
> >> >> maintenance interrupt doesn't occur (and no hang as result)
> >> >> Stefano - is this expected?
> >> >
> >> > No maintenance interrupts at all? That's strange. You should be
> >> > receiving them when LRs are full and you still have interrupts pending
> >> > to be added to them.
> >> >
> >> > You could add another printk here to see if you should be receiving
> >> > them:
> >> >
> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> > +    {
> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> > -    else
> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> > -
> >> > +    }
> >> >  }
> >> >
> >>
> >> Requested properly:
> >>
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>
> >> But does not occur
> >
> > OK, let's see what's going on then by printing the irq number of the
> > maintenance interrupt:
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 4d2a92d..fed3167 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -55,6 +55,7 @@ static struct {
> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
> >
> >  static uint8_t nr_lrs;
> > +static bool uie_on;
> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
> >
> >  /* The GIC mapping of CPU interfaces does not necessarily match the
> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
> >  {
> >      int i = 0;
> >      unsigned long flags;
> > +    unsigned long hcr;
> >
> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
> >       * doesn't write any LR registers for the idle domain they could be
> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
> >      if ( is_idle_vcpu(v) )
> >          return;
> >
> > +    hcr = GICH[GICH_HCR];
> > +    if ( hcr & GICH_HCR_UIE )
> > +    {
> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > +        uie_on = 1;
> > +    }
> > +
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >
> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
> >          intack = GICC[GICC_IAR];
> >          irq = intack & GICC_IA_IRQ;
> >
> > +        if ( uie_on )
> > +        {
> > +            uie_on = 0;
> > +            printk("received maintenance interrupt irq=%d\n", irq);
> > +        }
> >          if ( likely(irq >= 16 && irq < 1021) )
> >          {
> >              local_irq_enable();
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:20:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17: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.xen.org>)
	id 1Xr8vN-0005RE-Ds; Wed, 19 Nov 2014 17:20:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr8vL-0005R4-At
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:20:11 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	FF/68-02712-A41DC645; Wed, 19 Nov 2014 17:20:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416417608!13550031!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26604 invoked from network); 19 Nov 2014 17:20:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 17:20:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194470421"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:07:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr8jN-00077U-1B;
	Wed, 19 Nov 2014 17:07:49 +0000
Date: Wed, 19 Nov 2014 17:07:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I think that's OK: it looks like that on your board for some reasons
when UIE is set you get irq 1023 (spurious interrupt) instead of your
normal maintenance interrupt.

But everything should work anyway without issues.

This is the same patch as before but on top of the lastest xen-unstable
tree. Please confirm if it works.

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..df140b9 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -527,8 +529,6 @@ void gic_inject(void)
 
     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
         gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
-    else
-        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
 }
 
 static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> I got this strange log:
> 
> (XEN) received maintenance interrupt irq=1023
> 
> And platform does not hang due to this:
> +    hcr = GICH[GICH_HCR];
> +    if ( hcr & GICH_HCR_UIE )
> +    {
> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> +        uie_on = 1;
> +    }
> 
> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >>> Hi Stefano,
> >> >> >>>
> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >>> >> Hi Stefano,
> >> >> >>> >>
> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >> >> >>> >> > >      else
> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >> >> >>> >> > >
> >> >> >>> >> > >  }
> >> >> >>> >> >
> >> >> >>> >> > Yes, exactly
> >> >> >>> >>
> >> >> >>> >> I tried, hang still occurs with this change
> >> >> >>> >
> >> >> >>> > We need to figure out why during the hang you still have all the LRs
> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
> >> >> >>> > them to be cleared.
> >> >> >>> >
> >> >> >>>
> >> >> >>> I see that I have free LRs during maintenance interrupt
> >> >> >>>
> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >> >> >>> (XEN)    HW_LR[0]=9a015856
> >> >> >>> (XEN)    HW_LR[1]=0
> >> >> >>> (XEN)    HW_LR[2]=0
> >> >> >>> (XEN)    HW_LR[3]=0
> >> >> >>> (XEN) Inflight irq=86 lr=0
> >> >> >>> (XEN) Inflight irq=2 lr=255
> >> >> >>> (XEN) Pending irq=2
> >> >> >>>
> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
> >> >> >>> continuously. Platform continues printing the same log till reboot.
> >> >> >>
> >> >> >> Exactly the same log? As in the one above you just pasted?
> >> >> >> That is very very suspicious.
> >> >> >
> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
> >> >> > correctly.
> >> >> >
> >> >> >>
> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >> >> >> new maintenance interrupt immediately causing an infinite loop.
> >> >> >>
> >> >> >
> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
> >> >> > debug info it looks like once LRs are overloaded with SGIs -
> >> >> > maintenance interrupt occurs.
> >> >> > And then it is not handled properly, and occurs again and again - so
> >> >> > platform hangs inside its handler.
> >> >> >
> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >> >> >> hypervisor entry.
> >> >> >>
> >> >> >
> >> >> > Now trying.
> >> >> >
> >> >> >>
> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >> index 4d2a92d..6ae8dc4 100644
> >> >> >> --- a/xen/arch/arm/gic.c
> >> >> >> +++ b/xen/arch/arm/gic.c
> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >> >> >>      if ( is_idle_vcpu(v) )
> >> >> >>          return;
> >> >> >>
> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >> +
> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >> >> >>
> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >> >> >>
> >> >> >>      gic_restore_pending_irqs(current);
> >> >> >>
> >> >> >> -
> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> >> -    else
> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >> -
> >> >> >>  }
> >> >> >>
> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >> >> >
> >> >>
> >> >> Heh - I don't see hangs with this patch :) But also I see that
> >> >> maintenance interrupt doesn't occur (and no hang as result)
> >> >> Stefano - is this expected?
> >> >
> >> > No maintenance interrupts at all? That's strange. You should be
> >> > receiving them when LRs are full and you still have interrupts pending
> >> > to be added to them.
> >> >
> >> > You could add another printk here to see if you should be receiving
> >> > them:
> >> >
> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> > +    {
> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> > -    else
> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> > -
> >> > +    }
> >> >  }
> >> >
> >>
> >> Requested properly:
> >>
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>
> >> But does not occur
> >
> > OK, let's see what's going on then by printing the irq number of the
> > maintenance interrupt:
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 4d2a92d..fed3167 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -55,6 +55,7 @@ static struct {
> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
> >
> >  static uint8_t nr_lrs;
> > +static bool uie_on;
> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
> >
> >  /* The GIC mapping of CPU interfaces does not necessarily match the
> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
> >  {
> >      int i = 0;
> >      unsigned long flags;
> > +    unsigned long hcr;
> >
> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
> >       * doesn't write any LR registers for the idle domain they could be
> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
> >      if ( is_idle_vcpu(v) )
> >          return;
> >
> > +    hcr = GICH[GICH_HCR];
> > +    if ( hcr & GICH_HCR_UIE )
> > +    {
> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > +        uie_on = 1;
> > +    }
> > +
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >
> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
> >          intack = GICC[GICC_IAR];
> >          irq = intack & GICC_IA_IRQ;
> >
> > +        if ( uie_on )
> > +        {
> > +            uie_on = 0;
> > +            printk("received maintenance interrupt irq=%d\n", irq);
> > +        }
> >          if ( likely(irq >= 16 && irq < 1021) )
> >          {
> >              local_irq_enable();
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:28:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr92p-0005hm-TP; Wed, 19 Nov 2014 17:27:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1Xr92o-0005hh-MA
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 17:27:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	59/9E-09936-A13DC645; Wed, 19 Nov 2014 17:27:54 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416418073!6664432!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30668 invoked from network); 19 Nov 2014 17:27:53 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 19 Nov 2014 17:27:53 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:49400 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xr91D-0005fn-2a; Wed, 19 Nov 2014 18:26:15 +0100
Date: Wed, 19 Nov 2014 18:27:49 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1387312151.20141119182749@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141119150459.GA15417@laptop.dumpdata.com>
References: <1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<20141118205633.GB6540@laptop.dumpdata.com>
	<348130555.20141118231254@eikelenboom.it>
	<20141119015541.GA10307@laptop.dumpdata.com>
	<996703854.20141119121644@eikelenboom.it>
	<20141119150459.GA15417@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, November 19, 2014, 4:04:59 PM, you wrote:

> On Wed, Nov 19, 2014 at 12:16:44PM +0100, Sander Eikelenboom wrote:
>> 
>> Wednesday, November 19, 2014, 2:55:41 AM, you wrote:
>> 
>> > On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
>> >> 
>> >> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
>> >> 
>> >> >> 
>> >> >> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
>> >> >> about them .. however looking at the earlier reports these lines were also in 
>> >> >> those reports).
>> >> >> 
>> >> >> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
>> >> >> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
>> >> >> and had a new default seabios config. (just to rule out anything stale in my tree)
>> >> >> 
>> >> >> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
>> >> >> seabios config) are not the most recent (they don't get updated automatically 
>> >> >> when you just do a git pull on the main tree) ?
>> >> >> 
>> >> >> In /tools/firmware/seabios-dir/.config i have:
>> >> >> CONFIG_USB=y
>> >> >> CONFIG_USB_UHCI=y
>> >> >> CONFIG_USB_OHCI=y
>> >> >> CONFIG_USB_EHCI=y
>> >> >> CONFIG_USB_XHCI=y
>> >> >> CONFIG_USB_MSC=y
>> >> >> CONFIG_USB_UAS=y
>> >> >> CONFIG_USB_HUB=y
>> >> >> CONFIG_USB_KEYBOARD=y
>> >> >> CONFIG_USB_MOUSE=y
>> >> >> 
>> >> 
>> >> > I seem to have the same thing. Perhaps it is my XHCI controller being wonky.
>> >> 
>> >> >> And this is all just from a:
>> >> >> - git clone git://xenbits.xen.org/xen.git -b staging
>> >> >> - make clean && ./configure && make -j6 && make -j6 install
>> >> 
>> >> > Aye. 
>> >> > .. snip..
>> >> >> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
>> >> >> >     [But this might be invalid as the addition of the ffff8303faaf25a8
>> >> >> >      might be correct - as the second dpci the softirq is processing
>> >> >> >      could be the MSI one]
>> >> >> 
>> >> >> Would there be an easy way to stress test this function separately in some 
>> >> >> debugging function to see if it indeed is returning unexpected values ?
>> >> 
>> >> > Sadly no. But you got me looking in the right direction when you mentioned
>> >> > 'timeout'.
>> >> >> 
>> >> >> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
>> >> >> 
>> >> >> Just curious, have you also tested the patches on AMD hardware ?
>> >> 
>> >> > Yes. To reproduce this the first thing I did was to get an AMD box.
>> >> 
>> >> >> 
>> >> >>  
>> >> >> >> When i look at the combination of (2) and (3), It seems it could be an 
>> >> >> >> interaction between the two passed through devices and/or different IRQ types.
>> >> >> 
>> >> >> > Could be - as in it is causing this issue to show up faster than
>> >> >> > expected. Or it is the one that triggers more than one dpci happening
>> >> >> > at the same time.
>> >> >> 
>> >> >> Well that didn't seem to be it (see separate amendment i mailed previously)
>> >> 
>> >> > Right, the current theory I've is that the interrupts are not being
>> >> > Acked within 8 milisecond and we reset the 'state' - and at the same
>> >> > time we get an interrupt and schedule it - while we are still processing
>> >> > the same interrupt. This would explain why the 'test_and_clear_bit'
>> >> > got the wrong value.
>> >> 
>> >> > In regards to the list poison - following this thread of logic - with
>> >> > the 'state = 0' set we open the floodgates for any CPU to put the same
>> >> > 'struct hvm_pirq_dpci' on its list.
>> >> 
>> >> > We do reset the 'state' on _every_ GSI that is mapped to a guest - so
>> >> > we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:
>> >> 
>> >> > CPUX:                           CPUY:
>> >> > pt_irq_time_out:
>> >> > state = 0;                      
>> >> > [out of timer coder, the                raise_softirq
>> >> >  pirq_dpci is on the dpci_list]         [adds the pirq_dpci as state == 0]
>> >> 
>> >> > softirq_dpci                            softirq_dpci:
>> >> >         list_del
>> >> >         [entries poison]
>> >> >                                                 list_del <= BOOM
>> >> >                         
>> >> > Is what I believe is happening.
>> >> 
>> >> > The INTX device - once I put a load on it - does not trigger
>> >> > any pt_irq_time_out, so that would explain why I cannot hit this.
>> >> 
>> >> > But I believe your card hits these "hiccups".   
>> >> 
>> >> 
>> >> Hi Konrad,
>> >> 
>> >> I just tested you 5 patches and as a result i still got an(other) host crash:
>> >> (complete serial log attached)
>> >> 
>> >> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> >> (XEN) [2014-11-18 21:55:41.591] CPU:    0
>> >> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> >> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08012c7e7>]CPU:    2
>> >> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
>> >> (XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010006    _spin_unlock+0x1f/0x30CONTEXT: hypervisor
>> 
>> > Duh!
>> 
>> > Here is another patch on top of the five you have (attached and inline).
>> 
>> Hi Konrad,
>> 
>> Happy to report it has been running with this additional patch for 2 hours now 
>> without any problems. I think you nailed it :-)

> Could you also do an 'xl debug-keys k' and send that please?

Sure:

(XEN) [2014-11-19 17:26:05.839] CPU00:
(XEN) [2014-11-19 17:26:05.839] d16 OK-softirq 1msec ago, state:1, 751216 count, [prev:ffff82d0802e7e70, next:ffff82d0802e7e70] ffff8303fab608a8 22c258
(XEN) [2014-11-19 17:26:05.839] d16 OK-raise   1msec ago, state:1, 751216 count, [prev:0200200200200200, next:0100100100100100] ffff8303fab608a8 22c257
(XEN) [2014-11-19 17:26:05.839] d16 OK-raise   347977msec ago, state:1, 61 count, [prev:ffff82d080329160, next:ffff82d080329160] ffff8303fab608a8 203775
(XEN) [2014-11-19 17:26:05.839] d16 OK-reset   1msec ago, state:0, 258049 count, [prev:0200200200200200, next:0100100100100100] ffff8303fab608a8 22c256
(XEN) [2014-11-19 17:26:05.839] d16 OK-timeout 1msec ago, state:0, 258049 count, [prev:0200200200200200, next:0100100100100100] ffff8303fab608a8 22c254
(XEN) [2014-11-19 17:26:05.839] d16 OK-timeout 1msec ago, state:0, 258049 count, [prev:0200200200200200, next:0100100100100100] ffff8303fab608a8 22c255
(XEN) [2014-11-19 17:26:05.839] d16 Z-softirq  5746msec ago, state:6, 669 count, [prev:0200200200200200, next:0100100100100100] ffff8303fab608a8 22b871
(XEN) [2014-11-19 17:26:05.839] d16 Z-raise    5746msec ago, state:4, 669 count, [prev:ffff82d080329160, next:ffff82d080329160] ffff8303fab608a8 22b86f
(XEN) [2014-11-19 17:26:05.839] CPU01:
(XEN) [2014-11-19 17:26:05.839] CPU02:
(XEN) [2014-11-19 17:26:05.839] CPU03:
(XEN) [2014-11-19 17:26:05.839] CPU04:
(XEN) [2014-11-19 17:26:05.840] CPU05:


>> More than happy to test the definitive patch as well.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:28:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr92p-0005hm-TP; Wed, 19 Nov 2014 17:27:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1Xr92o-0005hh-MA
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 17:27:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	59/9E-09936-A13DC645; Wed, 19 Nov 2014 17:27:54 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416418073!6664432!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30668 invoked from network); 19 Nov 2014 17:27:53 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 19 Nov 2014 17:27:53 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:49400 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xr91D-0005fn-2a; Wed, 19 Nov 2014 18:26:15 +0100
Date: Wed, 19 Nov 2014 18:27:49 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1387312151.20141119182749@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141119150459.GA15417@laptop.dumpdata.com>
References: <1271355060.20141117234011@eikelenboom.it>
	<20141118024927.GA32256@andromeda.dapyr.net>
	<1408328417.20141118120741@eikelenboom.it>
	<68258140.20141118160925@eikelenboom.it>
	<20141118161650.GC17095@laptop.dumpdata.com>
	<1222042576.20141118180323@eikelenboom.it>
	<20141118205633.GB6540@laptop.dumpdata.com>
	<348130555.20141118231254@eikelenboom.it>
	<20141119015541.GA10307@laptop.dumpdata.com>
	<996703854.20141119121644@eikelenboom.it>
	<20141119150459.GA15417@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: xen panic RIP:   dpci_softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, November 19, 2014, 4:04:59 PM, you wrote:

> On Wed, Nov 19, 2014 at 12:16:44PM +0100, Sander Eikelenboom wrote:
>> 
>> Wednesday, November 19, 2014, 2:55:41 AM, you wrote:
>> 
>> > On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
>> >> 
>> >> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
>> >> 
>> >> >> 
>> >> >> Uhmm i thought i had these switched off (due to problems earlier and then forgot 
>> >> >> about them .. however looking at the earlier reports these lines were also in 
>> >> >> those reports).
>> >> >> 
>> >> >> The xen-syms and these last runs are all with a prestine xen tree cloned today (staging 
>> >> >> branch), so the qemu-xen and seabios defined with that were also freshly cloned 
>> >> >> and had a new default seabios config. (just to rule out anything stale in my tree)
>> >> >> 
>> >> >> If you don't see those messages .. perhaps your seabios and qemu trees (and at least the 
>> >> >> seabios config) are not the most recent (they don't get updated automatically 
>> >> >> when you just do a git pull on the main tree) ?
>> >> >> 
>> >> >> In /tools/firmware/seabios-dir/.config i have:
>> >> >> CONFIG_USB=y
>> >> >> CONFIG_USB_UHCI=y
>> >> >> CONFIG_USB_OHCI=y
>> >> >> CONFIG_USB_EHCI=y
>> >> >> CONFIG_USB_XHCI=y
>> >> >> CONFIG_USB_MSC=y
>> >> >> CONFIG_USB_UAS=y
>> >> >> CONFIG_USB_HUB=y
>> >> >> CONFIG_USB_KEYBOARD=y
>> >> >> CONFIG_USB_MOUSE=y
>> >> >> 
>> >> 
>> >> > I seem to have the same thing. Perhaps it is my XHCI controller being wonky.
>> >> 
>> >> >> And this is all just from a:
>> >> >> - git clone git://xenbits.xen.org/xen.git -b staging
>> >> >> - make clean && ./configure && make -j6 && make -j6 install
>> >> 
>> >> > Aye. 
>> >> > .. snip..
>> >> >> >  1) test_and_[set|clear]_bit sometimes return unexpected values.
>> >> >> >     [But this might be invalid as the addition of the ffff8303faaf25a8
>> >> >> >      might be correct - as the second dpci the softirq is processing
>> >> >> >      could be the MSI one]
>> >> >> 
>> >> >> Would there be an easy way to stress test this function separately in some 
>> >> >> debugging function to see if it indeed is returning unexpected values ?
>> >> 
>> >> > Sadly no. But you got me looking in the right direction when you mentioned
>> >> > 'timeout'.
>> >> >> 
>> >> >> >  2) INIT_LIST_HEAD operations on the same CPU are not honored.
>> >> >> 
>> >> >> Just curious, have you also tested the patches on AMD hardware ?
>> >> 
>> >> > Yes. To reproduce this the first thing I did was to get an AMD box.
>> >> 
>> >> >> 
>> >> >>  
>> >> >> >> When i look at the combination of (2) and (3), It seems it could be an 
>> >> >> >> interaction between the two passed through devices and/or different IRQ types.
>> >> >> 
>> >> >> > Could be - as in it is causing this issue to show up faster than
>> >> >> > expected. Or it is the one that triggers more than one dpci happening
>> >> >> > at the same time.
>> >> >> 
>> >> >> Well that didn't seem to be it (see separate amendment i mailed previously)
>> >> 
>> >> > Right, the current theory I've is that the interrupts are not being
>> >> > Acked within 8 milisecond and we reset the 'state' - and at the same
>> >> > time we get an interrupt and schedule it - while we are still processing
>> >> > the same interrupt. This would explain why the 'test_and_clear_bit'
>> >> > got the wrong value.
>> >> 
>> >> > In regards to the list poison - following this thread of logic - with
>> >> > the 'state = 0' set we open the floodgates for any CPU to put the same
>> >> > 'struct hvm_pirq_dpci' on its list.
>> >> 
>> >> > We do reset the 'state' on _every_ GSI that is mapped to a guest - so
>> >> > we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:
>> >> 
>> >> > CPUX:                           CPUY:
>> >> > pt_irq_time_out:
>> >> > state = 0;                      
>> >> > [out of timer coder, the                raise_softirq
>> >> >  pirq_dpci is on the dpci_list]         [adds the pirq_dpci as state == 0]
>> >> 
>> >> > softirq_dpci                            softirq_dpci:
>> >> >         list_del
>> >> >         [entries poison]
>> >> >                                                 list_del <= BOOM
>> >> >                         
>> >> > Is what I believe is happening.
>> >> 
>> >> > The INTX device - once I put a load on it - does not trigger
>> >> > any pt_irq_time_out, so that would explain why I cannot hit this.
>> >> 
>> >> > But I believe your card hits these "hiccups".   
>> >> 
>> >> 
>> >> Hi Konrad,
>> >> 
>> >> I just tested you 5 patches and as a result i still got an(other) host crash:
>> >> (complete serial log attached)
>> >> 
>> >> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> >> (XEN) [2014-11-18 21:55:41.591] CPU:    0
>> >> (XEN) [2014-11-18 21:55:41.591] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
>> >> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08012c7e7>]CPU:    2
>> >> (XEN) [2014-11-18 21:55:41.591] RIP:    e008:[<ffff82d08014a461>] hvm_do_IRQ_dpci+0xbd/0x13c
>> >> (XEN) [2014-11-18 21:55:41.591] RFLAGS: 0000000000010006    _spin_unlock+0x1f/0x30CONTEXT: hypervisor
>> 
>> > Duh!
>> 
>> > Here is another patch on top of the five you have (attached and inline).
>> 
>> Hi Konrad,
>> 
>> Happy to report it has been running with this additional patch for 2 hours now 
>> without any problems. I think you nailed it :-)

> Could you also do an 'xl debug-keys k' and send that please?

Sure:

(XEN) [2014-11-19 17:26:05.839] CPU00:
(XEN) [2014-11-19 17:26:05.839] d16 OK-softirq 1msec ago, state:1, 751216 count, [prev:ffff82d0802e7e70, next:ffff82d0802e7e70] ffff8303fab608a8 22c258
(XEN) [2014-11-19 17:26:05.839] d16 OK-raise   1msec ago, state:1, 751216 count, [prev:0200200200200200, next:0100100100100100] ffff8303fab608a8 22c257
(XEN) [2014-11-19 17:26:05.839] d16 OK-raise   347977msec ago, state:1, 61 count, [prev:ffff82d080329160, next:ffff82d080329160] ffff8303fab608a8 203775
(XEN) [2014-11-19 17:26:05.839] d16 OK-reset   1msec ago, state:0, 258049 count, [prev:0200200200200200, next:0100100100100100] ffff8303fab608a8 22c256
(XEN) [2014-11-19 17:26:05.839] d16 OK-timeout 1msec ago, state:0, 258049 count, [prev:0200200200200200, next:0100100100100100] ffff8303fab608a8 22c254
(XEN) [2014-11-19 17:26:05.839] d16 OK-timeout 1msec ago, state:0, 258049 count, [prev:0200200200200200, next:0100100100100100] ffff8303fab608a8 22c255
(XEN) [2014-11-19 17:26:05.839] d16 Z-softirq  5746msec ago, state:6, 669 count, [prev:0200200200200200, next:0100100100100100] ffff8303fab608a8 22b871
(XEN) [2014-11-19 17:26:05.839] d16 Z-raise    5746msec ago, state:4, 669 count, [prev:ffff82d080329160, next:ffff82d080329160] ffff8303fab608a8 22b86f
(XEN) [2014-11-19 17:26:05.839] CPU01:
(XEN) [2014-11-19 17:26:05.839] CPU02:
(XEN) [2014-11-19 17:26:05.839] CPU03:
(XEN) [2014-11-19 17:26:05.839] CPU04:
(XEN) [2014-11-19 17:26:05.840] CPU05:


>> More than happy to test the definitive patch as well.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:31:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr96c-0005qx-Ru; Wed, 19 Nov 2014 17:31:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr96c-0005ql-2M
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 17:31:50 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	DD/FC-11581-504DC645; Wed, 19 Nov 2014 17:31:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416418307!12326573!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17034 invoked from network); 19 Nov 2014 17:31:48 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 17:31:48 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJHVirU012882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 17:31:45 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAJHVhWE019447
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 17:31:43 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJHVhoi019200; Wed, 19 Nov 2014 17:31:43 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 09:31:42 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0080E11812A; Wed, 19 Nov 2014 12:31:41 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, JBeulich@suse.com, linux@eikelenboom.it
Date: Wed, 19 Nov 2014 12:31:39 -0500
Message-Id: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH v1 for-xen-4.5] Fix list corruption in
	dpci_softirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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,

This patch should fix the issue that Sander had seen. The full details
are in the patch itself. Sander, if you could - please test origin/staging
with this patch to make sure it does fix the issue.


 xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------

Konrad Rzeszutek Wilk (1):
      dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked.

 1 file changed, 17 insertions(+), 10 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:31:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr96d-0005r7-7N; Wed, 19 Nov 2014 17:31:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr96c-0005qm-7K
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 17:31:50 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	EA/B8-02957-504DC645; Wed, 19 Nov 2014 17:31:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416418307!13587102!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11433 invoked from network); 19 Nov 2014 17:31:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 17:31:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJHVifs009440
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 17:31:45 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJHVh1D028605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 17:31:44 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJHVhgx019216; Wed, 19 Nov 2014 17:31:43 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 09:31:43 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4267211812C; Wed, 19 Nov 2014 12:31:42 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, JBeulich@suse.com, linux@eikelenboom.it
Date: Wed, 19 Nov 2014 12:31:40 -0500
Message-Id: <1416418300-15778-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
References: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [for-xen-4.5 PATCH] dpci: Fix list corruption if INTx
	device is used and an IRQ timeout is invoked.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 we pass in INTx type devices to a guest on an over-subscribed
machine - and in an over-worked guest - we can cause the
pirq_dpci->softirq_list to become corrupted.

The reason for this is that the 'pt_irq_guest_eoi' ends up
setting the 'state' to zero value. However the 'state' value
(STATE_SCHED, STATE_RUN) is used to communicate between
 'raise_softirq_for' and 'dpci_softirq' to determine whether the
'struct hvm_pirq_dpci' can be re-scheduled. We are ignoring the
teardown path for simplicity for right now. The 'pt_irq_guest_eoi' was
not adhering to the proper dialogue and was not using locked cmpxchg or
test_bit operations and ended setting 'state' set to zero. That
meant 'raise_softirq_for' was free to schedule it while the
'struct hvm_pirq_dpci'' was still on an per-cpu list.
The end result was list_del being called twice and the second call
corrupting the per-cpu list.

For this to occur one of the CPUs must be in the idle loop executing
softirqs and the interrupt handler in the guest must not
respond to the pending interrupt within 8ms, and we must receive
another interrupt for this device on another CPU.

CPU0:                                  CPU1:

timer_softirq_action
 \- pt_irq_time_out
     state = 0;                        do_IRQ
 [out of timer code, the                raise_softirq
 pirq_dpci is on the CPU0 dpci_list]      [adds the pirq_dpci to CPU1
                                           dpci_list as state == 0]

softirq_dpci:                            softirq_dpci:
        list_del
        [list entries are poisoned]
                                                list_del <= BOOM

The fix is simple - enroll 'pt_irq_guest_eoi' to use the locked
semantics for 'state'. We piggyback on pt_pirq_softirq_cancel (was
pt_pirq_softirq_reset) to use cmpxchg. We also expand said function
to reset the '->dom' only on the teardown paths - but not on the
timeouts.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..2039d31 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -57,7 +57,7 @@ enum {
  * This can be called multiple times, but the softirq is only raised once.
  * That is until the STATE_SCHED state has been cleared. The state can be
  * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
- * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
+ * or by 'pt_pirq_softirq_cancel' (which will try to clear the state before
  * the softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
@@ -97,13 +97,15 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 }
 
 /*
- * Reset the pirq_dpci->dom parameter to NULL.
+ * Cancels an outstanding pirq_dpci (if scheduled). Also if clear is set,
+ * reset pirq_dpci->dom parameter to NULL (used for teardown).
  *
  * This function checks the different states to make sure it can do it
  * at the right time. If it unschedules the 'hvm_dirq_assist' from running
  * it also refcounts (which is what the softirq would have done) properly.
  */
-static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
+                                   unsigned int clear)
 {
     struct domain *d = pirq_dpci->dom;
 
@@ -125,8 +127,13 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
          * in local variable before it sets STATE_RUN - and therefore will not
          * dereference '->dom' which would crash.
+         *
+         * However, if this is called from 'pt_irq_time_out' we do not want to
+         * clear the '->dom' as we can re-use the 'pirq_dpci' after that and
+         * need '->dom'.
          */
-        pirq_dpci->dom = NULL;
+        if ( clear )
+            pirq_dpci->dom = NULL;
         break;
     }
 }
@@ -142,7 +149,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pt_pirq_softirq_cancel(pirq_dpci, 0 /* keep dom */);
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -285,7 +292,7 @@ int pt_irq_create_bind(
                      * to be scheduled but we must deal with the one that may be
                      * in the queue.
                      */
-                    pt_pirq_softirq_reset(pirq_dpci);
+                    pt_pirq_softirq_cancel(pirq_dpci, 1 /* reset dom */);
                 }
             }
             if ( unlikely(rc) )
@@ -536,9 +543,9 @@ int pt_irq_destroy_bind(
         pirq_dpci->flags = 0;
         /*
          * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
-         * call to pt_pirq_softirq_reset.
+         * call to pt_pirq_softirq_cancel.
          */
-        pt_pirq_softirq_reset(pirq_dpci);
+        pt_pirq_softirq_cancel(pirq_dpci, 1 /* reset dom */);
 
         pirq_cleanup_check(pirq, d);
     }
@@ -773,8 +780,8 @@ unlock:
 }
 
 /*
- * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
- * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
+ * Note: 'pt_pirq_softirq_cancel' can clear the STATE_SCHED before we get to
+ * doing it. If that is the case we let 'pt_pirq_softirq_cancel' do ref-counting.
  */
 static void dpci_softirq(void)
 {
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:31:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr96c-0005qx-Ru; Wed, 19 Nov 2014 17:31:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr96c-0005ql-2M
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 17:31:50 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	DD/FC-11581-504DC645; Wed, 19 Nov 2014 17:31:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416418307!12326573!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17034 invoked from network); 19 Nov 2014 17:31:48 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 17:31:48 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJHVirU012882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 17:31:45 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAJHVhWE019447
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 17:31:43 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJHVhoi019200; Wed, 19 Nov 2014 17:31:43 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 09:31:42 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0080E11812A; Wed, 19 Nov 2014 12:31:41 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, JBeulich@suse.com, linux@eikelenboom.it
Date: Wed, 19 Nov 2014 12:31:39 -0500
Message-Id: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH v1 for-xen-4.5] Fix list corruption in
	dpci_softirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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,

This patch should fix the issue that Sander had seen. The full details
are in the patch itself. Sander, if you could - please test origin/staging
with this patch to make sure it does fix the issue.


 xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------

Konrad Rzeszutek Wilk (1):
      dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked.

 1 file changed, 17 insertions(+), 10 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:31:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr96d-0005r7-7N; Wed, 19 Nov 2014 17:31:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xr96c-0005qm-7K
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 17:31:50 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	EA/B8-02957-504DC645; Wed, 19 Nov 2014 17:31:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416418307!13587102!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11433 invoked from network); 19 Nov 2014 17:31:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 17:31:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJHVifs009440
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 17:31:45 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJHVh1D028605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 17:31:44 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJHVhgx019216; Wed, 19 Nov 2014 17:31:43 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 09:31:43 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4267211812C; Wed, 19 Nov 2014 12:31:42 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, JBeulich@suse.com, linux@eikelenboom.it
Date: Wed, 19 Nov 2014 12:31:40 -0500
Message-Id: <1416418300-15778-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
References: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [for-xen-4.5 PATCH] dpci: Fix list corruption if INTx
	device is used and an IRQ timeout is invoked.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 we pass in INTx type devices to a guest on an over-subscribed
machine - and in an over-worked guest - we can cause the
pirq_dpci->softirq_list to become corrupted.

The reason for this is that the 'pt_irq_guest_eoi' ends up
setting the 'state' to zero value. However the 'state' value
(STATE_SCHED, STATE_RUN) is used to communicate between
 'raise_softirq_for' and 'dpci_softirq' to determine whether the
'struct hvm_pirq_dpci' can be re-scheduled. We are ignoring the
teardown path for simplicity for right now. The 'pt_irq_guest_eoi' was
not adhering to the proper dialogue and was not using locked cmpxchg or
test_bit operations and ended setting 'state' set to zero. That
meant 'raise_softirq_for' was free to schedule it while the
'struct hvm_pirq_dpci'' was still on an per-cpu list.
The end result was list_del being called twice and the second call
corrupting the per-cpu list.

For this to occur one of the CPUs must be in the idle loop executing
softirqs and the interrupt handler in the guest must not
respond to the pending interrupt within 8ms, and we must receive
another interrupt for this device on another CPU.

CPU0:                                  CPU1:

timer_softirq_action
 \- pt_irq_time_out
     state = 0;                        do_IRQ
 [out of timer code, the                raise_softirq
 pirq_dpci is on the CPU0 dpci_list]      [adds the pirq_dpci to CPU1
                                           dpci_list as state == 0]

softirq_dpci:                            softirq_dpci:
        list_del
        [list entries are poisoned]
                                                list_del <= BOOM

The fix is simple - enroll 'pt_irq_guest_eoi' to use the locked
semantics for 'state'. We piggyback on pt_pirq_softirq_cancel (was
pt_pirq_softirq_reset) to use cmpxchg. We also expand said function
to reset the '->dom' only on the teardown paths - but not on the
timeouts.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..2039d31 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -57,7 +57,7 @@ enum {
  * This can be called multiple times, but the softirq is only raised once.
  * That is until the STATE_SCHED state has been cleared. The state can be
  * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
- * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
+ * or by 'pt_pirq_softirq_cancel' (which will try to clear the state before
  * the softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
@@ -97,13 +97,15 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 }
 
 /*
- * Reset the pirq_dpci->dom parameter to NULL.
+ * Cancels an outstanding pirq_dpci (if scheduled). Also if clear is set,
+ * reset pirq_dpci->dom parameter to NULL (used for teardown).
  *
  * This function checks the different states to make sure it can do it
  * at the right time. If it unschedules the 'hvm_dirq_assist' from running
  * it also refcounts (which is what the softirq would have done) properly.
  */
-static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
+                                   unsigned int clear)
 {
     struct domain *d = pirq_dpci->dom;
 
@@ -125,8 +127,13 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
          * in local variable before it sets STATE_RUN - and therefore will not
          * dereference '->dom' which would crash.
+         *
+         * However, if this is called from 'pt_irq_time_out' we do not want to
+         * clear the '->dom' as we can re-use the 'pirq_dpci' after that and
+         * need '->dom'.
          */
-        pirq_dpci->dom = NULL;
+        if ( clear )
+            pirq_dpci->dom = NULL;
         break;
     }
 }
@@ -142,7 +149,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pt_pirq_softirq_cancel(pirq_dpci, 0 /* keep dom */);
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -285,7 +292,7 @@ int pt_irq_create_bind(
                      * to be scheduled but we must deal with the one that may be
                      * in the queue.
                      */
-                    pt_pirq_softirq_reset(pirq_dpci);
+                    pt_pirq_softirq_cancel(pirq_dpci, 1 /* reset dom */);
                 }
             }
             if ( unlikely(rc) )
@@ -536,9 +543,9 @@ int pt_irq_destroy_bind(
         pirq_dpci->flags = 0;
         /*
          * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
-         * call to pt_pirq_softirq_reset.
+         * call to pt_pirq_softirq_cancel.
          */
-        pt_pirq_softirq_reset(pirq_dpci);
+        pt_pirq_softirq_cancel(pirq_dpci, 1 /* reset dom */);
 
         pirq_cleanup_check(pirq, d);
     }
@@ -773,8 +780,8 @@ unlock:
 }
 
 /*
- * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
- * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
+ * Note: 'pt_pirq_softirq_cancel' can clear the STATE_SCHED before we get to
+ * doing it. If that is the case we let 'pt_pirq_softirq_cancel' do ref-counting.
  */
 static void dpci_softirq(void)
 {
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:33:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:33:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr98U-00062S-OI; Wed, 19 Nov 2014 17:33:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr98T-00062L-Ka
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 17:33:45 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	37/0B-02697-874DC645; Wed, 19 Nov 2014 17:33:44 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416418422!4724460!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14230 invoked from network); 19 Nov 2014 17:33:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 17:33:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192964554"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:33:41 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr98N-0007XO-P4;
	Wed, 19 Nov 2014 17:33:39 +0000
Date: Wed, 19 Nov 2014 17:33:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <1416412921-23671-3-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411191733090.12596@kaball.uk.xensource.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
	<1416412921-23671-3-git-send-email-david.vrabel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Fenghua Yu <fenghua.yu@intel.com>, Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/4] ia64: use common
	dma_get_required_mask_from_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, David Vrabel wrote:
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: linux-ia64@vger.kernel.org

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/ia64/include/asm/machvec.h      |    2 +-
>  arch/ia64/include/asm/machvec_init.h |    1 -
>  arch/ia64/pci/pci.c                  |   20 --------------------
>  3 files changed, 1 insertion(+), 22 deletions(-)
> 
> diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
> index 9c39bdf..beaa47d 100644
> --- a/arch/ia64/include/asm/machvec.h
> +++ b/arch/ia64/include/asm/machvec.h
> @@ -287,7 +287,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
>  # define platform_dma_get_ops		dma_get_ops
>  #endif
>  #ifndef platform_dma_get_required_mask
> -# define  platform_dma_get_required_mask	ia64_dma_get_required_mask
> +# define  platform_dma_get_required_mask	dma_get_required_mask_from_max_pfn
>  #endif
>  #ifndef platform_irq_to_vector
>  # define platform_irq_to_vector		__ia64_irq_to_vector
> diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
> index 37a4698..ef964b2 100644
> --- a/arch/ia64/include/asm/machvec_init.h
> +++ b/arch/ia64/include/asm/machvec_init.h
> @@ -3,7 +3,6 @@
>  
>  extern ia64_mv_send_ipi_t ia64_send_ipi;
>  extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
> -extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
>  extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
>  extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
>  extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index 291a582..79da21b 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -791,26 +791,6 @@ static void __init set_pci_dfl_cacheline_size(void)
>  	pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
>  }
>  
> -u64 ia64_dma_get_required_mask(struct device *dev)
> -{
> -	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
> -	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
> -	u64 mask;
> -
> -	if (!high_totalram) {
> -		/* convert to mask just covering totalram */
> -		low_totalram = (1 << (fls(low_totalram) - 1));
> -		low_totalram += low_totalram - 1;
> -		mask = low_totalram;
> -	} else {
> -		high_totalram = (1 << (fls(high_totalram) - 1));
> -		high_totalram += high_totalram - 1;
> -		mask = (((u64)high_totalram) << 32) + 0xffffffff;
> -	}
> -	return mask;
> -}
> -EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
> -
>  u64 dma_get_required_mask(struct device *dev)
>  {
>  	return platform_dma_get_required_mask(dev);
> -- 
> 1.7.10.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  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://secure-web.cisco.com/1uzdEOuzPh9ddYCppJ7edARD7taQXur82_EMioIJqXcGS1lEgfETQB2j546iHGLqo8mraFv4u9YxUpICa6DurqoTbYGXFrH14KuGQfFFzn4DHYx5HIksjcOqO2hiw74xfemY9frjnyDwhuBoBc3quJ5I8zLhf8kRz1AJGBKOKY_o/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:33:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:33:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr98U-00062S-OI; Wed, 19 Nov 2014 17:33:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr98T-00062L-Ka
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 17:33:45 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	37/0B-02697-874DC645; Wed, 19 Nov 2014 17:33:44 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416418422!4724460!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14230 invoked from network); 19 Nov 2014 17:33:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 17:33:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192964554"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:33:41 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr98N-0007XO-P4;
	Wed, 19 Nov 2014 17:33:39 +0000
Date: Wed, 19 Nov 2014 17:33:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <1416412921-23671-3-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411191733090.12596@kaball.uk.xensource.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
	<1416412921-23671-3-git-send-email-david.vrabel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Fenghua Yu <fenghua.yu@intel.com>, Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/4] ia64: use common
	dma_get_required_mask_from_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, David Vrabel wrote:
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: linux-ia64@vger.kernel.org

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/ia64/include/asm/machvec.h      |    2 +-
>  arch/ia64/include/asm/machvec_init.h |    1 -
>  arch/ia64/pci/pci.c                  |   20 --------------------
>  3 files changed, 1 insertion(+), 22 deletions(-)
> 
> diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
> index 9c39bdf..beaa47d 100644
> --- a/arch/ia64/include/asm/machvec.h
> +++ b/arch/ia64/include/asm/machvec.h
> @@ -287,7 +287,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
>  # define platform_dma_get_ops		dma_get_ops
>  #endif
>  #ifndef platform_dma_get_required_mask
> -# define  platform_dma_get_required_mask	ia64_dma_get_required_mask
> +# define  platform_dma_get_required_mask	dma_get_required_mask_from_max_pfn
>  #endif
>  #ifndef platform_irq_to_vector
>  # define platform_irq_to_vector		__ia64_irq_to_vector
> diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
> index 37a4698..ef964b2 100644
> --- a/arch/ia64/include/asm/machvec_init.h
> +++ b/arch/ia64/include/asm/machvec_init.h
> @@ -3,7 +3,6 @@
>  
>  extern ia64_mv_send_ipi_t ia64_send_ipi;
>  extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
> -extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
>  extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
>  extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
>  extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index 291a582..79da21b 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -791,26 +791,6 @@ static void __init set_pci_dfl_cacheline_size(void)
>  	pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
>  }
>  
> -u64 ia64_dma_get_required_mask(struct device *dev)
> -{
> -	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
> -	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
> -	u64 mask;
> -
> -	if (!high_totalram) {
> -		/* convert to mask just covering totalram */
> -		low_totalram = (1 << (fls(low_totalram) - 1));
> -		low_totalram += low_totalram - 1;
> -		mask = low_totalram;
> -	} else {
> -		high_totalram = (1 << (fls(high_totalram) - 1));
> -		high_totalram += high_totalram - 1;
> -		mask = (((u64)high_totalram) << 32) + 0xffffffff;
> -	}
> -	return mask;
> -}
> -EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
> -
>  u64 dma_get_required_mask(struct device *dev)
>  {
>  	return platform_dma_get_required_mask(dev);
> -- 
> 1.7.10.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  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://secure-web.cisco.com/1uzdEOuzPh9ddYCppJ7edARD7taQXur82_EMioIJqXcGS1lEgfETQB2j546iHGLqo8mraFv4u9YxUpICa6DurqoTbYGXFrH14KuGQfFFzn4DHYx5HIksjcOqO2hiw74xfemY9frjnyDwhuBoBc3quJ5I8zLhf8kRz1AJGBKOKY_o/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:38:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9Cg-0006PG-EN; Wed, 19 Nov 2014 17:38:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr9Cd-0006P8-LU
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:38:04 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	25/8B-19763-A75DC645; Wed, 19 Nov 2014 17:38:02 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416418679!12285391!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25601 invoked from network); 19 Nov 2014 17:38:01 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 17:38:01 -0000
Received: from mail-qa0-f41.google.com ([209.85.216.41]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzVdzh7eQA3V/fRZY9FfPTi1kFhDqGa@postini.com;
	Wed, 19 Nov 2014 09:38:01 PST
Received: by mail-qa0-f41.google.com with SMTP id f12so743952qad.14
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 09:37:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=jV2fke/QaapzBRYRI9D4QCTiSbgK5H+p1yt1bQF34Kw=;
	b=DFWBrPkcCKqcq/4A9tohr1XtY2ScrLdbtpdY1jdvrlsjQngpmoqtG0Tpgkhra1VXc9
	V0wJRbC/57qLmT1KTS10YItLxZOSn1WbFPs1xgdQlrIo8Y60PUFWZjvXJQUyHk67TsUz
	uyUHxCKcvhBR6k6+vQ3H6LeA4q/zETW/ftFbo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=jV2fke/QaapzBRYRI9D4QCTiSbgK5H+p1yt1bQF34Kw=;
	b=YmvGoomuUTGaq0OmtBMbTLpeQHkImCBsewaujl0wT67NNp1tZw5R5LXYSWiD5Txsjp
	o33luZSg9IA+w26cDy8XCXFtCtRUodMlp+E9jSgr6RxcYMPuldf8ddhjVRprsXJRc5ij
	xGf7cF/Ydb7pzvyQT8c+lpC0gdL/x2i5RgN5eJXX9mzuEXDgAnQNUUJglgaGI+A4ejbY
	7mqpPBWAucYVPjzOaeAsLTFKA2d+g3yaybSi2uyxerHbPQbqslicDs53v8c+2qdcdNFM
	S50crC/OZ6xet8UXm0U3mm7kuLKgjZGBl2eVJIqYyrqu8N9c3BlWMb3vFGAImmNoTREk
	qjBg==
X-Gm-Message-State: ALoCoQmxrHvq0JracD99neGsCg8rNv6ZnazEm8UwZUWnru7i+2byflr1kguNu2AMBa3oSNaQsSOmVfOkTrStdjZllm7jFEbbwjVLKNkI24o6cGNFmg9OsSM3hfamQDLqkOpTSZPvJ0mqEj12pZ1iBamG9A2fzNlrVA==
X-Received: by 10.224.138.2 with SMTP id y2mr54045129qat.52.1416418678866;
	Wed, 19 Nov 2014 09:37:58 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.138.2 with SMTP id y2mr54045090qat.52.1416418678455;
	Wed, 19 Nov 2014 09:37:58 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 09:37:58 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 19:37:58 +0200
Message-ID: <CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> I think that's OK: it looks like that on your board for some reasons
> when UIE is set you get irq 1023 (spurious interrupt) instead of your
> normal maintenance interrupt.

OK, but I think this should be investigated too. What do you think ?

>
> But everything should work anyway without issues.
>
> This is the same patch as before but on top of the lastest xen-unstable
> tree. Please confirm if it works.
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..df140b9 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>
> +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -527,8 +529,6 @@ void gic_inject(void)
>
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> -    else
> -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>  }
>

I confirm - it works fine. Will this be a final fix ?

Regards,
Andrii

>  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> I got this strange log:
>>
>> (XEN) received maintenance interrupt irq=1023
>>
>> And platform does not hang due to this:
>> +    hcr = GICH[GICH_HCR];
>> +    if ( hcr & GICH_HCR_UIE )
>> +    {
>> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> +        uie_on = 1;
>> +    }
>>
>> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
>> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >>> Hi Stefano,
>> >> >> >>>
>> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >>> >> Hi Stefano,
>> >> >> >>> >>
>> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> >> >> >>> >> > >      else
>> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> >> >> >>> >> > >
>> >> >> >>> >> > >  }
>> >> >> >>> >> >
>> >> >> >>> >> > Yes, exactly
>> >> >> >>> >>
>> >> >> >>> >> I tried, hang still occurs with this change
>> >> >> >>> >
>> >> >> >>> > We need to figure out why during the hang you still have all the LRs
>> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
>> >> >> >>> > them to be cleared.
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>> I see that I have free LRs during maintenance interrupt
>> >> >> >>>
>> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>> >> >> >>> (XEN)    HW_LR[0]=9a015856
>> >> >> >>> (XEN)    HW_LR[1]=0
>> >> >> >>> (XEN)    HW_LR[2]=0
>> >> >> >>> (XEN)    HW_LR[3]=0
>> >> >> >>> (XEN) Inflight irq=86 lr=0
>> >> >> >>> (XEN) Inflight irq=2 lr=255
>> >> >> >>> (XEN) Pending irq=2
>> >> >> >>>
>> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
>> >> >> >>> continuously. Platform continues printing the same log till reboot.
>> >> >> >>
>> >> >> >> Exactly the same log? As in the one above you just pasted?
>> >> >> >> That is very very suspicious.
>> >> >> >
>> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
>> >> >> > correctly.
>> >> >> >
>> >> >> >>
>> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
>> >> >> >> new maintenance interrupt immediately causing an infinite loop.
>> >> >> >>
>> >> >> >
>> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
>> >> >> > debug info it looks like once LRs are overloaded with SGIs -
>> >> >> > maintenance interrupt occurs.
>> >> >> > And then it is not handled properly, and occurs again and again - so
>> >> >> > platform hangs inside its handler.
>> >> >> >
>> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>> >> >> >> hypervisor entry.
>> >> >> >>
>> >> >> >
>> >> >> > Now trying.
>> >> >> >
>> >> >> >>
>> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >> >> index 4d2a92d..6ae8dc4 100644
>> >> >> >> --- a/xen/arch/arm/gic.c
>> >> >> >> +++ b/xen/arch/arm/gic.c
>> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>> >> >> >>      if ( is_idle_vcpu(v) )
>> >> >> >>          return;
>> >> >> >>
>> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >> +
>> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >> >> >>
>> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>> >> >> >>
>> >> >> >>      gic_restore_pending_irqs(current);
>> >> >> >>
>> >> >> >> -
>> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> >> -    else
>> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >> -
>> >> >> >>  }
>> >> >> >>
>> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>> >> >> >
>> >> >>
>> >> >> Heh - I don't see hangs with this patch :) But also I see that
>> >> >> maintenance interrupt doesn't occur (and no hang as result)
>> >> >> Stefano - is this expected?
>> >> >
>> >> > No maintenance interrupts at all? That's strange. You should be
>> >> > receiving them when LRs are full and you still have interrupts pending
>> >> > to be added to them.
>> >> >
>> >> > You could add another printk here to see if you should be receiving
>> >> > them:
>> >> >
>> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> > +    {
>> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> > -    else
>> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> > -
>> >> > +    }
>> >> >  }
>> >> >
>> >>
>> >> Requested properly:
>> >>
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >>
>> >> But does not occur
>> >
>> > OK, let's see what's going on then by printing the irq number of the
>> > maintenance interrupt:
>> >
>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> > index 4d2a92d..fed3167 100644
>> > --- a/xen/arch/arm/gic.c
>> > +++ b/xen/arch/arm/gic.c
>> > @@ -55,6 +55,7 @@ static struct {
>> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
>> >
>> >  static uint8_t nr_lrs;
>> > +static bool uie_on;
>> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
>> >
>> >  /* The GIC mapping of CPU interfaces does not necessarily match the
>> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
>> >  {
>> >      int i = 0;
>> >      unsigned long flags;
>> > +    unsigned long hcr;
>> >
>> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
>> >       * doesn't write any LR registers for the idle domain they could be
>> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
>> >      if ( is_idle_vcpu(v) )
>> >          return;
>> >
>> > +    hcr = GICH[GICH_HCR];
>> > +    if ( hcr & GICH_HCR_UIE )
>> > +    {
>> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> > +        uie_on = 1;
>> > +    }
>> > +
>> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >
>> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>> >          intack = GICC[GICC_IAR];
>> >          irq = intack & GICC_IA_IRQ;
>> >
>> > +        if ( uie_on )
>> > +        {
>> > +            uie_on = 0;
>> > +            printk("received maintenance interrupt irq=%d\n", irq);
>> > +        }
>> >          if ( likely(irq >= 16 && irq < 1021) )
>> >          {
>> >              local_irq_enable();
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:38:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9Cg-0006PG-EN; Wed, 19 Nov 2014 17:38:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr9Cd-0006P8-LU
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:38:04 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	25/8B-19763-A75DC645; Wed, 19 Nov 2014 17:38:02 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416418679!12285391!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25601 invoked from network); 19 Nov 2014 17:38:01 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 17:38:01 -0000
Received: from mail-qa0-f41.google.com ([209.85.216.41]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzVdzh7eQA3V/fRZY9FfPTi1kFhDqGa@postini.com;
	Wed, 19 Nov 2014 09:38:01 PST
Received: by mail-qa0-f41.google.com with SMTP id f12so743952qad.14
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 09:37:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=jV2fke/QaapzBRYRI9D4QCTiSbgK5H+p1yt1bQF34Kw=;
	b=DFWBrPkcCKqcq/4A9tohr1XtY2ScrLdbtpdY1jdvrlsjQngpmoqtG0Tpgkhra1VXc9
	V0wJRbC/57qLmT1KTS10YItLxZOSn1WbFPs1xgdQlrIo8Y60PUFWZjvXJQUyHk67TsUz
	uyUHxCKcvhBR6k6+vQ3H6LeA4q/zETW/ftFbo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=jV2fke/QaapzBRYRI9D4QCTiSbgK5H+p1yt1bQF34Kw=;
	b=YmvGoomuUTGaq0OmtBMbTLpeQHkImCBsewaujl0wT67NNp1tZw5R5LXYSWiD5Txsjp
	o33luZSg9IA+w26cDy8XCXFtCtRUodMlp+E9jSgr6RxcYMPuldf8ddhjVRprsXJRc5ij
	xGf7cF/Ydb7pzvyQT8c+lpC0gdL/x2i5RgN5eJXX9mzuEXDgAnQNUUJglgaGI+A4ejbY
	7mqpPBWAucYVPjzOaeAsLTFKA2d+g3yaybSi2uyxerHbPQbqslicDs53v8c+2qdcdNFM
	S50crC/OZ6xet8UXm0U3mm7kuLKgjZGBl2eVJIqYyrqu8N9c3BlWMb3vFGAImmNoTREk
	qjBg==
X-Gm-Message-State: ALoCoQmxrHvq0JracD99neGsCg8rNv6ZnazEm8UwZUWnru7i+2byflr1kguNu2AMBa3oSNaQsSOmVfOkTrStdjZllm7jFEbbwjVLKNkI24o6cGNFmg9OsSM3hfamQDLqkOpTSZPvJ0mqEj12pZ1iBamG9A2fzNlrVA==
X-Received: by 10.224.138.2 with SMTP id y2mr54045129qat.52.1416418678866;
	Wed, 19 Nov 2014 09:37:58 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.138.2 with SMTP id y2mr54045090qat.52.1416418678455;
	Wed, 19 Nov 2014 09:37:58 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 09:37:58 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191134080.27247@kaball.uk.xensource.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 19:37:58 +0200
Message-ID: <CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> I think that's OK: it looks like that on your board for some reasons
> when UIE is set you get irq 1023 (spurious interrupt) instead of your
> normal maintenance interrupt.

OK, but I think this should be investigated too. What do you think ?

>
> But everything should work anyway without issues.
>
> This is the same patch as before but on top of the lastest xen-unstable
> tree. Please confirm if it works.
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..df140b9 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>
> +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -527,8 +529,6 @@ void gic_inject(void)
>
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> -    else
> -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>  }
>

I confirm - it works fine. Will this be a final fix ?

Regards,
Andrii

>  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> I got this strange log:
>>
>> (XEN) received maintenance interrupt irq=1023
>>
>> And platform does not hang due to this:
>> +    hcr = GICH[GICH_HCR];
>> +    if ( hcr & GICH_HCR_UIE )
>> +    {
>> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> +        uie_on = 1;
>> +    }
>>
>> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
>> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >>> Hi Stefano,
>> >> >> >>>
>> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >>> >> Hi Stefano,
>> >> >> >>> >>
>> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> >> >> >>> >> > >      else
>> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> >> >> >>> >> > >
>> >> >> >>> >> > >  }
>> >> >> >>> >> >
>> >> >> >>> >> > Yes, exactly
>> >> >> >>> >>
>> >> >> >>> >> I tried, hang still occurs with this change
>> >> >> >>> >
>> >> >> >>> > We need to figure out why during the hang you still have all the LRs
>> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
>> >> >> >>> > them to be cleared.
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>> I see that I have free LRs during maintenance interrupt
>> >> >> >>>
>> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>> >> >> >>> (XEN)    HW_LR[0]=9a015856
>> >> >> >>> (XEN)    HW_LR[1]=0
>> >> >> >>> (XEN)    HW_LR[2]=0
>> >> >> >>> (XEN)    HW_LR[3]=0
>> >> >> >>> (XEN) Inflight irq=86 lr=0
>> >> >> >>> (XEN) Inflight irq=2 lr=255
>> >> >> >>> (XEN) Pending irq=2
>> >> >> >>>
>> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
>> >> >> >>> continuously. Platform continues printing the same log till reboot.
>> >> >> >>
>> >> >> >> Exactly the same log? As in the one above you just pasted?
>> >> >> >> That is very very suspicious.
>> >> >> >
>> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
>> >> >> > correctly.
>> >> >> >
>> >> >> >>
>> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
>> >> >> >> new maintenance interrupt immediately causing an infinite loop.
>> >> >> >>
>> >> >> >
>> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
>> >> >> > debug info it looks like once LRs are overloaded with SGIs -
>> >> >> > maintenance interrupt occurs.
>> >> >> > And then it is not handled properly, and occurs again and again - so
>> >> >> > platform hangs inside its handler.
>> >> >> >
>> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>> >> >> >> hypervisor entry.
>> >> >> >>
>> >> >> >
>> >> >> > Now trying.
>> >> >> >
>> >> >> >>
>> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >> >> index 4d2a92d..6ae8dc4 100644
>> >> >> >> --- a/xen/arch/arm/gic.c
>> >> >> >> +++ b/xen/arch/arm/gic.c
>> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>> >> >> >>      if ( is_idle_vcpu(v) )
>> >> >> >>          return;
>> >> >> >>
>> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >> +
>> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >> >> >>
>> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>> >> >> >>
>> >> >> >>      gic_restore_pending_irqs(current);
>> >> >> >>
>> >> >> >> -
>> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> >> -    else
>> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >> -
>> >> >> >>  }
>> >> >> >>
>> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>> >> >> >
>> >> >>
>> >> >> Heh - I don't see hangs with this patch :) But also I see that
>> >> >> maintenance interrupt doesn't occur (and no hang as result)
>> >> >> Stefano - is this expected?
>> >> >
>> >> > No maintenance interrupts at all? That's strange. You should be
>> >> > receiving them when LRs are full and you still have interrupts pending
>> >> > to be added to them.
>> >> >
>> >> > You could add another printk here to see if you should be receiving
>> >> > them:
>> >> >
>> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> > +    {
>> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> > -    else
>> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> > -
>> >> > +    }
>> >> >  }
>> >> >
>> >>
>> >> Requested properly:
>> >>
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >>
>> >> But does not occur
>> >
>> > OK, let's see what's going on then by printing the irq number of the
>> > maintenance interrupt:
>> >
>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> > index 4d2a92d..fed3167 100644
>> > --- a/xen/arch/arm/gic.c
>> > +++ b/xen/arch/arm/gic.c
>> > @@ -55,6 +55,7 @@ static struct {
>> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
>> >
>> >  static uint8_t nr_lrs;
>> > +static bool uie_on;
>> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
>> >
>> >  /* The GIC mapping of CPU interfaces does not necessarily match the
>> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
>> >  {
>> >      int i = 0;
>> >      unsigned long flags;
>> > +    unsigned long hcr;
>> >
>> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
>> >       * doesn't write any LR registers for the idle domain they could be
>> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
>> >      if ( is_idle_vcpu(v) )
>> >          return;
>> >
>> > +    hcr = GICH[GICH_HCR];
>> > +    if ( hcr & GICH_HCR_UIE )
>> > +    {
>> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> > +        uie_on = 1;
>> > +    }
>> > +
>> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >
>> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>> >          intack = GICC[GICC_IAR];
>> >          irq = intack & GICC_IA_IRQ;
>> >
>> > +        if ( uie_on )
>> > +        {
>> > +            uie_on = 0;
>> > +            printk("received maintenance interrupt irq=%d\n", irq);
>> > +        }
>> >          if ( likely(irq >= 16 && irq < 1021) )
>> >          {
>> >              local_irq_enable();
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:38:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9D4-0006SM-0k; Wed, 19 Nov 2014 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 <Stefano.Stabellini@citrix.com>) id 1Xr9D2-0006S6-Vf
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:38:29 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	19/C5-31453-495DC645; Wed, 19 Nov 2014 17:38:28 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416418705!12353330!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23119 invoked from network); 19 Nov 2014 17:38:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 17:38:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194473273"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:14:38 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr8px-0007E3-NS;
	Wed, 19 Nov 2014 17:14:37 +0000
Date: Wed, 19 Nov 2014 17:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMMgL2jrD-M69P1t7qTHrNO6ar6hv984nRzu5b5OhUuMPw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191714050.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<CAH_mUMMgL2jrD-M69P1t7qTHrNO6ar6hv984nRzu5b5OhUuMPw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

No, it just means "spurious interrupt".

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Does number 1023 mean that maintenance interrupt is global?
> 
> On Wed, Nov 19, 2014 at 7:03 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > I got this strange log:
> >
> > (XEN) received maintenance interrupt irq=1023
> >
> > And platform does not hang due to this:
> > +    hcr = GICH[GICH_HCR];
> > +    if ( hcr & GICH_HCR_UIE )
> > +    {
> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > +        uie_on = 1;
> > +    }
> >
> > On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >>> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >>> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >>> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >>> Hi Stefano,
> >>> >> >>>
> >>> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >>> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >>> >> Hi Stefano,
> >>> >> >>> >>
> >>> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >>> >> >>> >> > >      else
> >>> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >>> >> >>> >> > >
> >>> >> >>> >> > >  }
> >>> >> >>> >> >
> >>> >> >>> >> > Yes, exactly
> >>> >> >>> >>
> >>> >> >>> >> I tried, hang still occurs with this change
> >>> >> >>> >
> >>> >> >>> > We need to figure out why during the hang you still have all the LRs
> >>> >> >>> > busy even if you are getting maintenance interrupts that should cause
> >>> >> >>> > them to be cleared.
> >>> >> >>> >
> >>> >> >>>
> >>> >> >>> I see that I have free LRs during maintenance interrupt
> >>> >> >>>
> >>> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >>> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >>> >> >>> (XEN)    HW_LR[0]=9a015856
> >>> >> >>> (XEN)    HW_LR[1]=0
> >>> >> >>> (XEN)    HW_LR[2]=0
> >>> >> >>> (XEN)    HW_LR[3]=0
> >>> >> >>> (XEN) Inflight irq=86 lr=0
> >>> >> >>> (XEN) Inflight irq=2 lr=255
> >>> >> >>> (XEN) Pending irq=2
> >>> >> >>>
> >>> >> >>> But I see that after I got hang - maintenance interrupts are generated
> >>> >> >>> continuously. Platform continues printing the same log till reboot.
> >>> >> >>
> >>> >> >> Exactly the same log? As in the one above you just pasted?
> >>> >> >> That is very very suspicious.
> >>> >> >
> >>> >> > Yes exactly the same log. And looks like it means that LRs are flushed
> >>> >> > correctly.
> >>> >> >
> >>> >> >>
> >>> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >>> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >>> >> >> new maintenance interrupt immediately causing an infinite loop.
> >>> >> >>
> >>> >> >
> >>> >> > Yes, this is what I'm thinking about. Taking in account all collected
> >>> >> > debug info it looks like once LRs are overloaded with SGIs -
> >>> >> > maintenance interrupt occurs.
> >>> >> > And then it is not handled properly, and occurs again and again - so
> >>> >> > platform hangs inside its handler.
> >>> >> >
> >>> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >>> >> >> hypervisor entry.
> >>> >> >>
> >>> >> >
> >>> >> > Now trying.
> >>> >> >
> >>> >> >>
> >>> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> >> >> index 4d2a92d..6ae8dc4 100644
> >>> >> >> --- a/xen/arch/arm/gic.c
> >>> >> >> +++ b/xen/arch/arm/gic.c
> >>> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >>> >> >>      if ( is_idle_vcpu(v) )
> >>> >> >>          return;
> >>> >> >>
> >>> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> +
> >>> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>> >> >>
> >>> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >>> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >>> >> >>
> >>> >> >>      gic_restore_pending_irqs(current);
> >>> >> >>
> >>> >> >> -
> >>> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> >> -    else
> >>> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> -
> >>> >> >>  }
> >>> >> >>
> >>> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >>> >> >
> >>> >>
> >>> >> Heh - I don't see hangs with this patch :) But also I see that
> >>> >> maintenance interrupt doesn't occur (and no hang as result)
> >>> >> Stefano - is this expected?
> >>> >
> >>> > No maintenance interrupts at all? That's strange. You should be
> >>> > receiving them when LRs are full and you still have interrupts pending
> >>> > to be added to them.
> >>> >
> >>> > You could add another printk here to see if you should be receiving
> >>> > them:
> >>> >
> >>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> > +    {
> >>> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >>> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> > -    else
> >>> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> > -
> >>> > +    }
> >>> >  }
> >>> >
> >>>
> >>> Requested properly:
> >>>
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>>
> >>> But does not occur
> >>
> >> OK, let's see what's going on then by printing the irq number of the
> >> maintenance interrupt:
> >>
> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> index 4d2a92d..fed3167 100644
> >> --- a/xen/arch/arm/gic.c
> >> +++ b/xen/arch/arm/gic.c
> >> @@ -55,6 +55,7 @@ static struct {
> >>  static DEFINE_PER_CPU(uint64_t, lr_mask);
> >>
> >>  static uint8_t nr_lrs;
> >> +static bool uie_on;
> >>  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
> >>
> >>  /* The GIC mapping of CPU interfaces does not necessarily match the
> >> @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
> >>  {
> >>      int i = 0;
> >>      unsigned long flags;
> >> +    unsigned long hcr;
> >>
> >>      /* The idle domain has no LRs to be cleared. Since gic_restore_state
> >>       * doesn't write any LR registers for the idle domain they could be
> >> @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
> >>      if ( is_idle_vcpu(v) )
> >>          return;
> >>
> >> +    hcr = GICH[GICH_HCR];
> >> +    if ( hcr & GICH_HCR_UIE )
> >> +    {
> >> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> +        uie_on = 1;
> >> +    }
> >> +
> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>
> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
> >>          intack = GICC[GICC_IAR];
> >>          irq = intack & GICC_IA_IRQ;
> >>
> >> +        if ( uie_on )
> >> +        {
> >> +            uie_on = 0;
> >> +            printk("received maintenance interrupt irq=%d\n", irq);
> >> +        }
> >>          if ( likely(irq >= 16 && irq < 1021) )
> >>          {
> >>              local_irq_enable();
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:38:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9D4-0006SM-0k; Wed, 19 Nov 2014 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 <Stefano.Stabellini@citrix.com>) id 1Xr9D2-0006S6-Vf
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:38:29 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	19/C5-31453-495DC645; Wed, 19 Nov 2014 17:38:28 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416418705!12353330!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23119 invoked from network); 19 Nov 2014 17:38:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 17:38:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194473273"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:14:38 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr8px-0007E3-NS;
	Wed, 19 Nov 2014 17:14:37 +0000
Date: Wed, 19 Nov 2014 17:14:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMMgL2jrD-M69P1t7qTHrNO6ar6hv984nRzu5b5OhUuMPw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191714050.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMM6xncP=nfyGyTjmD_kq7uTBuGAjxNE_0FQohoOdN=SeA@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<CAH_mUMMgL2jrD-M69P1t7qTHrNO6ar6hv984nRzu5b5OhUuMPw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

No, it just means "spurious interrupt".

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Does number 1023 mean that maintenance interrupt is global?
> 
> On Wed, Nov 19, 2014 at 7:03 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > I got this strange log:
> >
> > (XEN) received maintenance interrupt irq=1023
> >
> > And platform does not hang due to this:
> > +    hcr = GICH[GICH_HCR];
> > +    if ( hcr & GICH_HCR_UIE )
> > +    {
> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > +        uie_on = 1;
> > +    }
> >
> > On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >>> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >>> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >>> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >>> Hi Stefano,
> >>> >> >>>
> >>> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >>> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >>> >> Hi Stefano,
> >>> >> >>> >>
> >>> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >>> >> >>> >> > >      else
> >>> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >>> >> >>> >> > >
> >>> >> >>> >> > >  }
> >>> >> >>> >> >
> >>> >> >>> >> > Yes, exactly
> >>> >> >>> >>
> >>> >> >>> >> I tried, hang still occurs with this change
> >>> >> >>> >
> >>> >> >>> > We need to figure out why during the hang you still have all the LRs
> >>> >> >>> > busy even if you are getting maintenance interrupts that should cause
> >>> >> >>> > them to be cleared.
> >>> >> >>> >
> >>> >> >>>
> >>> >> >>> I see that I have free LRs during maintenance interrupt
> >>> >> >>>
> >>> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >>> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >>> >> >>> (XEN)    HW_LR[0]=9a015856
> >>> >> >>> (XEN)    HW_LR[1]=0
> >>> >> >>> (XEN)    HW_LR[2]=0
> >>> >> >>> (XEN)    HW_LR[3]=0
> >>> >> >>> (XEN) Inflight irq=86 lr=0
> >>> >> >>> (XEN) Inflight irq=2 lr=255
> >>> >> >>> (XEN) Pending irq=2
> >>> >> >>>
> >>> >> >>> But I see that after I got hang - maintenance interrupts are generated
> >>> >> >>> continuously. Platform continues printing the same log till reboot.
> >>> >> >>
> >>> >> >> Exactly the same log? As in the one above you just pasted?
> >>> >> >> That is very very suspicious.
> >>> >> >
> >>> >> > Yes exactly the same log. And looks like it means that LRs are flushed
> >>> >> > correctly.
> >>> >> >
> >>> >> >>
> >>> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >>> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >>> >> >> new maintenance interrupt immediately causing an infinite loop.
> >>> >> >>
> >>> >> >
> >>> >> > Yes, this is what I'm thinking about. Taking in account all collected
> >>> >> > debug info it looks like once LRs are overloaded with SGIs -
> >>> >> > maintenance interrupt occurs.
> >>> >> > And then it is not handled properly, and occurs again and again - so
> >>> >> > platform hangs inside its handler.
> >>> >> >
> >>> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >>> >> >> hypervisor entry.
> >>> >> >>
> >>> >> >
> >>> >> > Now trying.
> >>> >> >
> >>> >> >>
> >>> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> >> >> index 4d2a92d..6ae8dc4 100644
> >>> >> >> --- a/xen/arch/arm/gic.c
> >>> >> >> +++ b/xen/arch/arm/gic.c
> >>> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >>> >> >>      if ( is_idle_vcpu(v) )
> >>> >> >>          return;
> >>> >> >>
> >>> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> +
> >>> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>> >> >>
> >>> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >>> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >>> >> >>
> >>> >> >>      gic_restore_pending_irqs(current);
> >>> >> >>
> >>> >> >> -
> >>> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> >> -    else
> >>> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> -
> >>> >> >>  }
> >>> >> >>
> >>> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >>> >> >
> >>> >>
> >>> >> Heh - I don't see hangs with this patch :) But also I see that
> >>> >> maintenance interrupt doesn't occur (and no hang as result)
> >>> >> Stefano - is this expected?
> >>> >
> >>> > No maintenance interrupts at all? That's strange. You should be
> >>> > receiving them when LRs are full and you still have interrupts pending
> >>> > to be added to them.
> >>> >
> >>> > You could add another printk here to see if you should be receiving
> >>> > them:
> >>> >
> >>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> > +    {
> >>> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >>> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> > -    else
> >>> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> > -
> >>> > +    }
> >>> >  }
> >>> >
> >>>
> >>> Requested properly:
> >>>
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>>
> >>> But does not occur
> >>
> >> OK, let's see what's going on then by printing the irq number of the
> >> maintenance interrupt:
> >>
> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> index 4d2a92d..fed3167 100644
> >> --- a/xen/arch/arm/gic.c
> >> +++ b/xen/arch/arm/gic.c
> >> @@ -55,6 +55,7 @@ static struct {
> >>  static DEFINE_PER_CPU(uint64_t, lr_mask);
> >>
> >>  static uint8_t nr_lrs;
> >> +static bool uie_on;
> >>  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
> >>
> >>  /* The GIC mapping of CPU interfaces does not necessarily match the
> >> @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
> >>  {
> >>      int i = 0;
> >>      unsigned long flags;
> >> +    unsigned long hcr;
> >>
> >>      /* The idle domain has no LRs to be cleared. Since gic_restore_state
> >>       * doesn't write any LR registers for the idle domain they could be
> >> @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
> >>      if ( is_idle_vcpu(v) )
> >>          return;
> >>
> >> +    hcr = GICH[GICH_HCR];
> >> +    if ( hcr & GICH_HCR_UIE )
> >> +    {
> >> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> +        uie_on = 1;
> >> +    }
> >> +
> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>
> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
> >>          intack = GICC[GICC_IAR];
> >>          irq = intack & GICC_IA_IRQ;
> >>
> >> +        if ( uie_on )
> >> +        {
> >> +            uie_on = 0;
> >> +            printk("received maintenance interrupt irq=%d\n", irq);
> >> +        }
> >>          if ( likely(irq >= 16 && irq < 1021) )
> >>          {
> >>              local_irq_enable();
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:43:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9HI-0006os-NW; Wed, 19 Nov 2014 17:42:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr9HG-0006oL-Eb
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:42:51 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	1A/F4-25714-996DC645; Wed, 19 Nov 2014 17:42:49 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416418965!12353949!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5174 invoked from network); 19 Nov 2014 17:42:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 17:42:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192968290"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:42:41 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr9H6-0007fP-LH;
	Wed, 19 Nov 2014 17:42:40 +0000
Date: Wed, 19 Nov 2014 17:42:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > I think that's OK: it looks like that on your board for some reasons
> > when UIE is set you get irq 1023 (spurious interrupt) instead of your
> > normal maintenance interrupt.
> 
> OK, but I think this should be investigated too. What do you think ?

I think it is harmless: my guess is that if we clear UIE before reading
GICC_IAR, GICC_IAR returns spurious interrupt instead of maintenance
interrupt. But it doesn't really matter to us.

> >
> > But everything should work anyway without issues.
> >
> > This is the same patch as before but on top of the lastest xen-unstable
> > tree. Please confirm if it works.
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 70d10d6..df140b9 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
> >      if ( is_idle_vcpu(v) )
> >          return;
> >
> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> > +
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >
> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> > @@ -527,8 +529,6 @@ void gic_inject(void)
> >
> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> > -    else
> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >  }
> >
> 
> I confirm - it works fine. Will this be a final fix ?

Yep :-)
Many thanks for your help on this!


> Regards,
> Andrii
> 
> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> >
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> I got this strange log:
> >>
> >> (XEN) received maintenance interrupt irq=1023
> >>
> >> And platform does not hang due to this:
> >> +    hcr = GICH[GICH_HCR];
> >> +    if ( hcr & GICH_HCR_UIE )
> >> +    {
> >> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> +        uie_on = 1;
> >> +    }
> >>
> >> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> >> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> >>> Hi Stefano,
> >> >> >> >>>
> >> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> >>> >> Hi Stefano,
> >> >> >> >>> >>
> >> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >> >> >> >>> >> > >      else
> >> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >> >> >> >>> >> > >
> >> >> >> >>> >> > >  }
> >> >> >> >>> >> >
> >> >> >> >>> >> > Yes, exactly
> >> >> >> >>> >>
> >> >> >> >>> >> I tried, hang still occurs with this change
> >> >> >> >>> >
> >> >> >> >>> > We need to figure out why during the hang you still have all the LRs
> >> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
> >> >> >> >>> > them to be cleared.
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >> >>> I see that I have free LRs during maintenance interrupt
> >> >> >> >>>
> >> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >> >> >> >>> (XEN)    HW_LR[0]=9a015856
> >> >> >> >>> (XEN)    HW_LR[1]=0
> >> >> >> >>> (XEN)    HW_LR[2]=0
> >> >> >> >>> (XEN)    HW_LR[3]=0
> >> >> >> >>> (XEN) Inflight irq=86 lr=0
> >> >> >> >>> (XEN) Inflight irq=2 lr=255
> >> >> >> >>> (XEN) Pending irq=2
> >> >> >> >>>
> >> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
> >> >> >> >>> continuously. Platform continues printing the same log till reboot.
> >> >> >> >>
> >> >> >> >> Exactly the same log? As in the one above you just pasted?
> >> >> >> >> That is very very suspicious.
> >> >> >> >
> >> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
> >> >> >> > correctly.
> >> >> >> >
> >> >> >> >>
> >> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >> >> >> >> new maintenance interrupt immediately causing an infinite loop.
> >> >> >> >>
> >> >> >> >
> >> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
> >> >> >> > debug info it looks like once LRs are overloaded with SGIs -
> >> >> >> > maintenance interrupt occurs.
> >> >> >> > And then it is not handled properly, and occurs again and again - so
> >> >> >> > platform hangs inside its handler.
> >> >> >> >
> >> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >> >> >> >> hypervisor entry.
> >> >> >> >>
> >> >> >> >
> >> >> >> > Now trying.
> >> >> >> >
> >> >> >> >>
> >> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >> >> index 4d2a92d..6ae8dc4 100644
> >> >> >> >> --- a/xen/arch/arm/gic.c
> >> >> >> >> +++ b/xen/arch/arm/gic.c
> >> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >> >> >> >>      if ( is_idle_vcpu(v) )
> >> >> >> >>          return;
> >> >> >> >>
> >> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >> >> +
> >> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >> >> >> >>
> >> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >> >> >> >>
> >> >> >> >>      gic_restore_pending_irqs(current);
> >> >> >> >>
> >> >> >> >> -
> >> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> >> >> -    else
> >> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >> >> -
> >> >> >> >>  }
> >> >> >> >>
> >> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >> >> >> >
> >> >> >>
> >> >> >> Heh - I don't see hangs with this patch :) But also I see that
> >> >> >> maintenance interrupt doesn't occur (and no hang as result)
> >> >> >> Stefano - is this expected?
> >> >> >
> >> >> > No maintenance interrupts at all? That's strange. You should be
> >> >> > receiving them when LRs are full and you still have interrupts pending
> >> >> > to be added to them.
> >> >> >
> >> >> > You could add another printk here to see if you should be receiving
> >> >> > them:
> >> >> >
> >> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >> > +    {
> >> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> > -    else
> >> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> > -
> >> >> > +    }
> >> >> >  }
> >> >> >
> >> >>
> >> >> Requested properly:
> >> >>
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >>
> >> >> But does not occur
> >> >
> >> > OK, let's see what's going on then by printing the irq number of the
> >> > maintenance interrupt:
> >> >
> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> > index 4d2a92d..fed3167 100644
> >> > --- a/xen/arch/arm/gic.c
> >> > +++ b/xen/arch/arm/gic.c
> >> > @@ -55,6 +55,7 @@ static struct {
> >> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
> >> >
> >> >  static uint8_t nr_lrs;
> >> > +static bool uie_on;
> >> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
> >> >
> >> >  /* The GIC mapping of CPU interfaces does not necessarily match the
> >> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
> >> >  {
> >> >      int i = 0;
> >> >      unsigned long flags;
> >> > +    unsigned long hcr;
> >> >
> >> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
> >> >       * doesn't write any LR registers for the idle domain they could be
> >> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
> >> >      if ( is_idle_vcpu(v) )
> >> >          return;
> >> >
> >> > +    hcr = GICH[GICH_HCR];
> >> > +    if ( hcr & GICH_HCR_UIE )
> >> > +    {
> >> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> > +        uie_on = 1;
> >> > +    }
> >> > +
> >> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >> >
> >> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
> >> >          intack = GICC[GICC_IAR];
> >> >          irq = intack & GICC_IA_IRQ;
> >> >
> >> > +        if ( uie_on )
> >> > +        {
> >> > +            uie_on = 0;
> >> > +            printk("received maintenance interrupt irq=%d\n", irq);
> >> > +        }
> >> >          if ( likely(irq >= 16 && irq < 1021) )
> >> >          {
> >> >              local_irq_enable();
> >>
> >>
> >>
> >> --
> >>
> >> Andrii Tseglytskyi | Embedded Dev
> >> GlobalLogic
> >> www.globallogic.com
> >>
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:43:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9HI-0006os-NW; Wed, 19 Nov 2014 17:42:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr9HG-0006oL-Eb
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:42:51 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	1A/F4-25714-996DC645; Wed, 19 Nov 2014 17:42:49 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416418965!12353949!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5174 invoked from network); 19 Nov 2014 17:42:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 17:42:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192968290"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:42:41 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr9H6-0007fP-LH;
	Wed, 19 Nov 2014 17:42:40 +0000
Date: Wed, 19 Nov 2014 17:42:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > I think that's OK: it looks like that on your board for some reasons
> > when UIE is set you get irq 1023 (spurious interrupt) instead of your
> > normal maintenance interrupt.
> 
> OK, but I think this should be investigated too. What do you think ?

I think it is harmless: my guess is that if we clear UIE before reading
GICC_IAR, GICC_IAR returns spurious interrupt instead of maintenance
interrupt. But it doesn't really matter to us.

> >
> > But everything should work anyway without issues.
> >
> > This is the same patch as before but on top of the lastest xen-unstable
> > tree. Please confirm if it works.
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 70d10d6..df140b9 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
> >      if ( is_idle_vcpu(v) )
> >          return;
> >
> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> > +
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >
> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> > @@ -527,8 +529,6 @@ void gic_inject(void)
> >
> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> > -    else
> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >  }
> >
> 
> I confirm - it works fine. Will this be a final fix ?

Yep :-)
Many thanks for your help on this!


> Regards,
> Andrii
> 
> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> >
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> I got this strange log:
> >>
> >> (XEN) received maintenance interrupt irq=1023
> >>
> >> And platform does not hang due to this:
> >> +    hcr = GICH[GICH_HCR];
> >> +    if ( hcr & GICH_HCR_UIE )
> >> +    {
> >> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> +        uie_on = 1;
> >> +    }
> >>
> >> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> >> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> >>> Hi Stefano,
> >> >> >> >>>
> >> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> >> >>> >> Hi Stefano,
> >> >> >> >>> >>
> >> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >> >> >> >>> >> > >      else
> >> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >> >> >> >>> >> > >
> >> >> >> >>> >> > >  }
> >> >> >> >>> >> >
> >> >> >> >>> >> > Yes, exactly
> >> >> >> >>> >>
> >> >> >> >>> >> I tried, hang still occurs with this change
> >> >> >> >>> >
> >> >> >> >>> > We need to figure out why during the hang you still have all the LRs
> >> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
> >> >> >> >>> > them to be cleared.
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >> >>> I see that I have free LRs during maintenance interrupt
> >> >> >> >>>
> >> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >> >> >> >>> (XEN)    HW_LR[0]=9a015856
> >> >> >> >>> (XEN)    HW_LR[1]=0
> >> >> >> >>> (XEN)    HW_LR[2]=0
> >> >> >> >>> (XEN)    HW_LR[3]=0
> >> >> >> >>> (XEN) Inflight irq=86 lr=0
> >> >> >> >>> (XEN) Inflight irq=2 lr=255
> >> >> >> >>> (XEN) Pending irq=2
> >> >> >> >>>
> >> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
> >> >> >> >>> continuously. Platform continues printing the same log till reboot.
> >> >> >> >>
> >> >> >> >> Exactly the same log? As in the one above you just pasted?
> >> >> >> >> That is very very suspicious.
> >> >> >> >
> >> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
> >> >> >> > correctly.
> >> >> >> >
> >> >> >> >>
> >> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >> >> >> >> new maintenance interrupt immediately causing an infinite loop.
> >> >> >> >>
> >> >> >> >
> >> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
> >> >> >> > debug info it looks like once LRs are overloaded with SGIs -
> >> >> >> > maintenance interrupt occurs.
> >> >> >> > And then it is not handled properly, and occurs again and again - so
> >> >> >> > platform hangs inside its handler.
> >> >> >> >
> >> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >> >> >> >> hypervisor entry.
> >> >> >> >>
> >> >> >> >
> >> >> >> > Now trying.
> >> >> >> >
> >> >> >> >>
> >> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> >> >> >> index 4d2a92d..6ae8dc4 100644
> >> >> >> >> --- a/xen/arch/arm/gic.c
> >> >> >> >> +++ b/xen/arch/arm/gic.c
> >> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >> >> >> >>      if ( is_idle_vcpu(v) )
> >> >> >> >>          return;
> >> >> >> >>
> >> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >> >> +
> >> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >> >> >> >>
> >> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >> >> >> >>
> >> >> >> >>      gic_restore_pending_irqs(current);
> >> >> >> >>
> >> >> >> >> -
> >> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> >> >> -    else
> >> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> >> >> -
> >> >> >> >>  }
> >> >> >> >>
> >> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >> >> >> >
> >> >> >>
> >> >> >> Heh - I don't see hangs with this patch :) But also I see that
> >> >> >> maintenance interrupt doesn't occur (and no hang as result)
> >> >> >> Stefano - is this expected?
> >> >> >
> >> >> > No maintenance interrupts at all? That's strange. You should be
> >> >> > receiving them when LRs are full and you still have interrupts pending
> >> >> > to be added to them.
> >> >> >
> >> >> > You could add another printk here to see if you should be receiving
> >> >> > them:
> >> >> >
> >> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >> >> > +    {
> >> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >> >> > -    else
> >> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> >> > -
> >> >> > +    }
> >> >> >  }
> >> >> >
> >> >>
> >> >> Requested properly:
> >> >>
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >> >>
> >> >> But does not occur
> >> >
> >> > OK, let's see what's going on then by printing the irq number of the
> >> > maintenance interrupt:
> >> >
> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> > index 4d2a92d..fed3167 100644
> >> > --- a/xen/arch/arm/gic.c
> >> > +++ b/xen/arch/arm/gic.c
> >> > @@ -55,6 +55,7 @@ static struct {
> >> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
> >> >
> >> >  static uint8_t nr_lrs;
> >> > +static bool uie_on;
> >> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
> >> >
> >> >  /* The GIC mapping of CPU interfaces does not necessarily match the
> >> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
> >> >  {
> >> >      int i = 0;
> >> >      unsigned long flags;
> >> > +    unsigned long hcr;
> >> >
> >> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
> >> >       * doesn't write any LR registers for the idle domain they could be
> >> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
> >> >      if ( is_idle_vcpu(v) )
> >> >          return;
> >> >
> >> > +    hcr = GICH[GICH_HCR];
> >> > +    if ( hcr & GICH_HCR_UIE )
> >> > +    {
> >> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >> > +        uie_on = 1;
> >> > +    }
> >> > +
> >> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >> >
> >> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
> >> >          intack = GICC[GICC_IAR];
> >> >          irq = intack & GICC_IA_IRQ;
> >> >
> >> > +        if ( uie_on )
> >> > +        {
> >> > +            uie_on = 0;
> >> > +            printk("received maintenance interrupt irq=%d\n", irq);
> >> > +        }
> >> >          if ( likely(irq >= 16 && irq < 1021) )
> >> >          {
> >> >              local_irq_enable();
> >>
> >>
> >>
> >> --
> >>
> >> Andrii Tseglytskyi | Embedded Dev
> >> GlobalLogic
> >> www.globallogic.com
> >>
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9Ld-00077J-Ep; Wed, 19 Nov 2014 17:47:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr9Lb-00077B-Mk
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:47:20 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	07/84-07724-6A7DC645; Wed, 19 Nov 2014 17:47:18 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416419235!8792329!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25865 invoked from network); 19 Nov 2014 17:47:17 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 17:47:17 -0000
Received: from mail-qc0-f171.google.com ([209.85.216.171]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzXoobMrNNcKuqhrGh6gCO/cp9fqT7g@postini.com;
	Wed, 19 Nov 2014 09:47:17 PST
Received: by mail-qc0-f171.google.com with SMTP id r5so814289qcx.2
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 09:47:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Zi2TgFaUIQ69EQm72AMglo3to4/6SMWSFaz83XZRG3c=;
	b=MXqYfsObeqDuajnhIphv4/bvvBJ3nejaJbow+1bINzOULu5TiFr6MD4yxeOAwZ9Mlt
	i87QufpRUjoa6p4BGqXcsymcmh/d5eWZ4/MgdLY27rY7k0klJb5cmFzHw7hA3U8ZiFca
	jlChZ2CKy/dkryBnJRVrdl9IBuvkficSGvMgo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Zi2TgFaUIQ69EQm72AMglo3to4/6SMWSFaz83XZRG3c=;
	b=M2j7Rxt0WAbSVupK+3N639rUhr2WynWzuGaYuCnx7B4qQg5IVLeOP0PKtsAEqHwt8R
	VjnhH5XWpF13p0+TMAr8u0pwaOW2l2b+foSf3qpZH45uuhh46oCI/R+D00iS89HCE4rr
	mlRU/1U/HpVYmUpvwAGfX6M2x7G55PPjJCVKcFWviCX/3URpZ7wYZExUDwaCYufK5ETn
	uFKMzg7UeuKG4m4y9eYFcGXdUm+Jp0Hu4+8I7/IB7q5BI/e6kKN5dJ8yC8Iaf3hbYQET
	1hGOx0sOTJR2YqEsQ7nqM3QLfT7pMP23PDZBA+CDmDpwZGJbvc2knmRcFrWVnLARLZ1h
	whbQ==
X-Gm-Message-State: ALoCoQmOy38kr3FtAPd0xHTuOhOlNIxb10+2GuNEeTwo/iK92+YkKudm6EWyIdhvuj3NlzqRHxs/3AAoU7mVVmMCLsOOVtbMdEN/n1R/VcVhs23vGEOhyVxm4sqSDBH49Oa5+bfuybAEnzgqe81bTn2LGkB72PmovA==
X-Received: by 10.140.105.37 with SMTP id b34mr53048707qgf.91.1416419234351;
	Wed, 19 Nov 2014 09:47:14 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.105.37 with SMTP id b34mr53048686qgf.91.1416419234220;
	Wed, 19 Nov 2014 09:47:14 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 09:47:13 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 19:47:13 +0200
Message-ID: <CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 7:42 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > I think that's OK: it looks like that on your board for some reasons
>> > when UIE is set you get irq 1023 (spurious interrupt) instead of your
>> > normal maintenance interrupt.
>>
>> OK, but I think this should be investigated too. What do you think ?
>
> I think it is harmless: my guess is that if we clear UIE before reading
> GICC_IAR, GICC_IAR returns spurious interrupt instead of maintenance
> interrupt. But it doesn't really matter to us.

OK. I think catching this will be a good exercise for someone )) But
out of scope for this issue.

>
>> >
>> > But everything should work anyway without issues.
>> >
>> > This is the same patch as before but on top of the lastest xen-unstable
>> > tree. Please confirm if it works.
>> >
>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> > index 70d10d6..df140b9 100644
>> > --- a/xen/arch/arm/gic.c
>> > +++ b/xen/arch/arm/gic.c
>> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>> >      if ( is_idle_vcpu(v) )
>> >          return;
>> >
>> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>> > +
>> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >
>> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> > @@ -527,8 +529,6 @@ void gic_inject(void)
>> >
>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
>> > -    else
>> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>> >  }
>> >
>>
>> I confirm - it works fine. Will this be a final fix ?
>
> Yep :-)
> Many thanks for your help on this!

Thank you Stefano. This issue was really critical for us :)

Regards,
Andrii

>
>
>> Regards,
>> Andrii
>>
>> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>> >
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> I got this strange log:
>> >>
>> >> (XEN) received maintenance interrupt irq=1023
>> >>
>> >> And platform does not hang due to this:
>> >> +    hcr = GICH[GICH_HCR];
>> >> +    if ( hcr & GICH_HCR_UIE )
>> >> +    {
>> >> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> +        uie_on = 1;
>> >> +    }
>> >>
>> >> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>> >> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>> >> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
>> >> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>> >> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >> >>> Hi Stefano,
>> >> >> >> >>>
>> >> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> >> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >> >>> >> Hi Stefano,
>> >> >> >> >>> >>
>> >> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> >> >> >> >>> >> > >      else
>> >> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> >> >> >> >>> >> > >
>> >> >> >> >>> >> > >  }
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > Yes, exactly
>> >> >> >> >>> >>
>> >> >> >> >>> >> I tried, hang still occurs with this change
>> >> >> >> >>> >
>> >> >> >> >>> > We need to figure out why during the hang you still have all the LRs
>> >> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
>> >> >> >> >>> > them to be cleared.
>> >> >> >> >>> >
>> >> >> >> >>>
>> >> >> >> >>> I see that I have free LRs during maintenance interrupt
>> >> >> >> >>>
>> >> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>> >> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>> >> >> >> >>> (XEN)    HW_LR[0]=9a015856
>> >> >> >> >>> (XEN)    HW_LR[1]=0
>> >> >> >> >>> (XEN)    HW_LR[2]=0
>> >> >> >> >>> (XEN)    HW_LR[3]=0
>> >> >> >> >>> (XEN) Inflight irq=86 lr=0
>> >> >> >> >>> (XEN) Inflight irq=2 lr=255
>> >> >> >> >>> (XEN) Pending irq=2
>> >> >> >> >>>
>> >> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
>> >> >> >> >>> continuously. Platform continues printing the same log till reboot.
>> >> >> >> >>
>> >> >> >> >> Exactly the same log? As in the one above you just pasted?
>> >> >> >> >> That is very very suspicious.
>> >> >> >> >
>> >> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
>> >> >> >> > correctly.
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>> >> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
>> >> >> >> >> new maintenance interrupt immediately causing an infinite loop.
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
>> >> >> >> > debug info it looks like once LRs are overloaded with SGIs -
>> >> >> >> > maintenance interrupt occurs.
>> >> >> >> > And then it is not handled properly, and occurs again and again - so
>> >> >> >> > platform hangs inside its handler.
>> >> >> >> >
>> >> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>> >> >> >> >> hypervisor entry.
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > Now trying.
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >> >> >> index 4d2a92d..6ae8dc4 100644
>> >> >> >> >> --- a/xen/arch/arm/gic.c
>> >> >> >> >> +++ b/xen/arch/arm/gic.c
>> >> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>> >> >> >> >>      if ( is_idle_vcpu(v) )
>> >> >> >> >>          return;
>> >> >> >> >>
>> >> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >> >> +
>> >> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >> >> >> >>
>> >> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> >> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>> >> >> >> >>
>> >> >> >> >>      gic_restore_pending_irqs(current);
>> >> >> >> >>
>> >> >> >> >> -
>> >> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> >> >> -    else
>> >> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >> >> -
>> >> >> >> >>  }
>> >> >> >> >>
>> >> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>> >> >> >> >
>> >> >> >>
>> >> >> >> Heh - I don't see hangs with this patch :) But also I see that
>> >> >> >> maintenance interrupt doesn't occur (and no hang as result)
>> >> >> >> Stefano - is this expected?
>> >> >> >
>> >> >> > No maintenance interrupts at all? That's strange. You should be
>> >> >> > receiving them when LRs are full and you still have interrupts pending
>> >> >> > to be added to them.
>> >> >> >
>> >> >> > You could add another printk here to see if you should be receiving
>> >> >> > them:
>> >> >> >
>> >> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >> > +    {
>> >> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>> >> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> > -    else
>> >> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> > -
>> >> >> > +    }
>> >> >> >  }
>> >> >> >
>> >> >>
>> >> >> Requested properly:
>> >> >>
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >>
>> >> >> But does not occur
>> >> >
>> >> > OK, let's see what's going on then by printing the irq number of the
>> >> > maintenance interrupt:
>> >> >
>> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> > index 4d2a92d..fed3167 100644
>> >> > --- a/xen/arch/arm/gic.c
>> >> > +++ b/xen/arch/arm/gic.c
>> >> > @@ -55,6 +55,7 @@ static struct {
>> >> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
>> >> >
>> >> >  static uint8_t nr_lrs;
>> >> > +static bool uie_on;
>> >> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
>> >> >
>> >> >  /* The GIC mapping of CPU interfaces does not necessarily match the
>> >> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
>> >> >  {
>> >> >      int i = 0;
>> >> >      unsigned long flags;
>> >> > +    unsigned long hcr;
>> >> >
>> >> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
>> >> >       * doesn't write any LR registers for the idle domain they could be
>> >> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
>> >> >      if ( is_idle_vcpu(v) )
>> >> >          return;
>> >> >
>> >> > +    hcr = GICH[GICH_HCR];
>> >> > +    if ( hcr & GICH_HCR_UIE )
>> >> > +    {
>> >> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> > +        uie_on = 1;
>> >> > +    }
>> >> > +
>> >> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >> >
>> >> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> >> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>> >> >          intack = GICC[GICC_IAR];
>> >> >          irq = intack & GICC_IA_IRQ;
>> >> >
>> >> > +        if ( uie_on )
>> >> > +        {
>> >> > +            uie_on = 0;
>> >> > +            printk("received maintenance interrupt irq=%d\n", irq);
>> >> > +        }
>> >> >          if ( likely(irq >= 16 && irq < 1021) )
>> >> >          {
>> >> >              local_irq_enable();
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Andrii Tseglytskyi | Embedded Dev
>> >> GlobalLogic
>> >> www.globallogic.com
>> >>
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:47:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9Ld-00077J-Ep; Wed, 19 Nov 2014 17:47:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr9Lb-00077B-Mk
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 17:47:20 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	07/84-07724-6A7DC645; Wed, 19 Nov 2014 17:47:18 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416419235!8792329!1
X-Originating-IP: [64.18.0.180]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25865 invoked from network); 19 Nov 2014 17:47:17 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 17:47:17 -0000
Received: from mail-qc0-f171.google.com ([209.85.216.171]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzXoobMrNNcKuqhrGh6gCO/cp9fqT7g@postini.com;
	Wed, 19 Nov 2014 09:47:17 PST
Received: by mail-qc0-f171.google.com with SMTP id r5so814289qcx.2
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 09:47:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Zi2TgFaUIQ69EQm72AMglo3to4/6SMWSFaz83XZRG3c=;
	b=MXqYfsObeqDuajnhIphv4/bvvBJ3nejaJbow+1bINzOULu5TiFr6MD4yxeOAwZ9Mlt
	i87QufpRUjoa6p4BGqXcsymcmh/d5eWZ4/MgdLY27rY7k0klJb5cmFzHw7hA3U8ZiFca
	jlChZ2CKy/dkryBnJRVrdl9IBuvkficSGvMgo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Zi2TgFaUIQ69EQm72AMglo3to4/6SMWSFaz83XZRG3c=;
	b=M2j7Rxt0WAbSVupK+3N639rUhr2WynWzuGaYuCnx7B4qQg5IVLeOP0PKtsAEqHwt8R
	VjnhH5XWpF13p0+TMAr8u0pwaOW2l2b+foSf3qpZH45uuhh46oCI/R+D00iS89HCE4rr
	mlRU/1U/HpVYmUpvwAGfX6M2x7G55PPjJCVKcFWviCX/3URpZ7wYZExUDwaCYufK5ETn
	uFKMzg7UeuKG4m4y9eYFcGXdUm+Jp0Hu4+8I7/IB7q5BI/e6kKN5dJ8yC8Iaf3hbYQET
	1hGOx0sOTJR2YqEsQ7nqM3QLfT7pMP23PDZBA+CDmDpwZGJbvc2knmRcFrWVnLARLZ1h
	whbQ==
X-Gm-Message-State: ALoCoQmOy38kr3FtAPd0xHTuOhOlNIxb10+2GuNEeTwo/iK92+YkKudm6EWyIdhvuj3NlzqRHxs/3AAoU7mVVmMCLsOOVtbMdEN/n1R/VcVhs23vGEOhyVxm4sqSDBH49Oa5+bfuybAEnzgqe81bTn2LGkB72PmovA==
X-Received: by 10.140.105.37 with SMTP id b34mr53048707qgf.91.1416419234351;
	Wed, 19 Nov 2014 09:47:14 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.105.37 with SMTP id b34mr53048686qgf.91.1416419234220;
	Wed, 19 Nov 2014 09:47:14 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 09:47:13 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 19:47:13 +0200
Message-ID: <CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 7:42 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > I think that's OK: it looks like that on your board for some reasons
>> > when UIE is set you get irq 1023 (spurious interrupt) instead of your
>> > normal maintenance interrupt.
>>
>> OK, but I think this should be investigated too. What do you think ?
>
> I think it is harmless: my guess is that if we clear UIE before reading
> GICC_IAR, GICC_IAR returns spurious interrupt instead of maintenance
> interrupt. But it doesn't really matter to us.

OK. I think catching this will be a good exercise for someone )) But
out of scope for this issue.

>
>> >
>> > But everything should work anyway without issues.
>> >
>> > This is the same patch as before but on top of the lastest xen-unstable
>> > tree. Please confirm if it works.
>> >
>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> > index 70d10d6..df140b9 100644
>> > --- a/xen/arch/arm/gic.c
>> > +++ b/xen/arch/arm/gic.c
>> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>> >      if ( is_idle_vcpu(v) )
>> >          return;
>> >
>> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>> > +
>> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >
>> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> > @@ -527,8 +529,6 @@ void gic_inject(void)
>> >
>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
>> > -    else
>> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>> >  }
>> >
>>
>> I confirm - it works fine. Will this be a final fix ?
>
> Yep :-)
> Many thanks for your help on this!

Thank you Stefano. This issue was really critical for us :)

Regards,
Andrii

>
>
>> Regards,
>> Andrii
>>
>> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>> >
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> I got this strange log:
>> >>
>> >> (XEN) received maintenance interrupt irq=1023
>> >>
>> >> And platform does not hang due to this:
>> >> +    hcr = GICH[GICH_HCR];
>> >> +    if ( hcr & GICH_HCR_UIE )
>> >> +    {
>> >> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> +        uie_on = 1;
>> >> +    }
>> >>
>> >> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>> >> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>> >> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
>> >> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>> >> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >> >>> Hi Stefano,
>> >> >> >> >>>
>> >> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> >> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> >> >> >>> >> Hi Stefano,
>> >> >> >> >>> >>
>> >> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>> >> >> >> >>> >> > >      else
>> >> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>> >> >> >> >>> >> > >
>> >> >> >> >>> >> > >  }
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > Yes, exactly
>> >> >> >> >>> >>
>> >> >> >> >>> >> I tried, hang still occurs with this change
>> >> >> >> >>> >
>> >> >> >> >>> > We need to figure out why during the hang you still have all the LRs
>> >> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
>> >> >> >> >>> > them to be cleared.
>> >> >> >> >>> >
>> >> >> >> >>>
>> >> >> >> >>> I see that I have free LRs during maintenance interrupt
>> >> >> >> >>>
>> >> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>> >> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>> >> >> >> >>> (XEN)    HW_LR[0]=9a015856
>> >> >> >> >>> (XEN)    HW_LR[1]=0
>> >> >> >> >>> (XEN)    HW_LR[2]=0
>> >> >> >> >>> (XEN)    HW_LR[3]=0
>> >> >> >> >>> (XEN) Inflight irq=86 lr=0
>> >> >> >> >>> (XEN) Inflight irq=2 lr=255
>> >> >> >> >>> (XEN) Pending irq=2
>> >> >> >> >>>
>> >> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
>> >> >> >> >>> continuously. Platform continues printing the same log till reboot.
>> >> >> >> >>
>> >> >> >> >> Exactly the same log? As in the one above you just pasted?
>> >> >> >> >> That is very very suspicious.
>> >> >> >> >
>> >> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
>> >> >> >> > correctly.
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>> >> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
>> >> >> >> >> new maintenance interrupt immediately causing an infinite loop.
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
>> >> >> >> > debug info it looks like once LRs are overloaded with SGIs -
>> >> >> >> > maintenance interrupt occurs.
>> >> >> >> > And then it is not handled properly, and occurs again and again - so
>> >> >> >> > platform hangs inside its handler.
>> >> >> >> >
>> >> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>> >> >> >> >> hypervisor entry.
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > Now trying.
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> >> >> >> index 4d2a92d..6ae8dc4 100644
>> >> >> >> >> --- a/xen/arch/arm/gic.c
>> >> >> >> >> +++ b/xen/arch/arm/gic.c
>> >> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>> >> >> >> >>      if ( is_idle_vcpu(v) )
>> >> >> >> >>          return;
>> >> >> >> >>
>> >> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >> >> +
>> >> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >> >> >> >>
>> >> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> >> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>> >> >> >> >>
>> >> >> >> >>      gic_restore_pending_irqs(current);
>> >> >> >> >>
>> >> >> >> >> -
>> >> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> >> >> -    else
>> >> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> >> >> -
>> >> >> >> >>  }
>> >> >> >> >>
>> >> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>> >> >> >> >
>> >> >> >>
>> >> >> >> Heh - I don't see hangs with this patch :) But also I see that
>> >> >> >> maintenance interrupt doesn't occur (and no hang as result)
>> >> >> >> Stefano - is this expected?
>> >> >> >
>> >> >> > No maintenance interrupts at all? That's strange. You should be
>> >> >> > receiving them when LRs are full and you still have interrupts pending
>> >> >> > to be added to them.
>> >> >> >
>> >> >> > You could add another printk here to see if you should be receiving
>> >> >> > them:
>> >> >> >
>> >> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>> >> >> > +    {
>> >> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>> >> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
>> >> >> > -    else
>> >> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> >> > -
>> >> >> > +    }
>> >> >> >  }
>> >> >> >
>> >> >>
>> >> >> Requested properly:
>> >> >>
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>> >> >>
>> >> >> But does not occur
>> >> >
>> >> > OK, let's see what's going on then by printing the irq number of the
>> >> > maintenance interrupt:
>> >> >
>> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> >> > index 4d2a92d..fed3167 100644
>> >> > --- a/xen/arch/arm/gic.c
>> >> > +++ b/xen/arch/arm/gic.c
>> >> > @@ -55,6 +55,7 @@ static struct {
>> >> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
>> >> >
>> >> >  static uint8_t nr_lrs;
>> >> > +static bool uie_on;
>> >> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
>> >> >
>> >> >  /* The GIC mapping of CPU interfaces does not necessarily match the
>> >> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
>> >> >  {
>> >> >      int i = 0;
>> >> >      unsigned long flags;
>> >> > +    unsigned long hcr;
>> >> >
>> >> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
>> >> >       * doesn't write any LR registers for the idle domain they could be
>> >> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
>> >> >      if ( is_idle_vcpu(v) )
>> >> >          return;
>> >> >
>> >> > +    hcr = GICH[GICH_HCR];
>> >> > +    if ( hcr & GICH_HCR_UIE )
>> >> > +    {
>> >> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>> >> > +        uie_on = 1;
>> >> > +    }
>> >> > +
>> >> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> >> >
>> >> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>> >> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>> >> >          intack = GICC[GICC_IAR];
>> >> >          irq = intack & GICC_IA_IRQ;
>> >> >
>> >> > +        if ( uie_on )
>> >> > +        {
>> >> > +            uie_on = 0;
>> >> > +            printk("received maintenance interrupt irq=%d\n", irq);
>> >> > +        }
>> >> >          if ( likely(irq >= 16 && irq < 1021) )
>> >> >          {
>> >> >              local_irq_enable();
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Andrii Tseglytskyi | Embedded Dev
>> >> GlobalLogic
>> >> www.globallogic.com
>> >>
>>
>>
>>
>> --
>>
>> Andrii Tseglytskyi | Embedded Dev
>> GlobalLogic
>> www.globallogic.com
>>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:53:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17: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.xen.org>)
	id 1Xr9RP-0007Lk-Fg; Wed, 19 Nov 2014 17:53:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xr9RN-0007Ld-T7
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 17:53:18 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	AF/1B-31453-D09DC645; Wed, 19 Nov 2014 17:53:17 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416419595!7021360!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3962 invoked from network); 19 Nov 2014 17:53:15 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 17:53:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416419595; x=1447955595;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=+2dKELeXMQ2sRD/1d1lMK4TskkzNOU+gWfBMnJbo628=;
	b=hTVckAE5La0I7loR9Ely7uxaH1RsnfI5b0elQ5DR6+SN8kT2bBZqCqlB
	vDF/CY5ye4LT7ph7G6HSjOKDKn6SGe3PMJAgZqj9qEIfVmsQ1s7gaq+vG
	N+BpsRSWrrkVOxHQk6dYiMzgkSTj7p90mODuxVYwtTlJAxfY52GmVocoh c=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by fldsmtpe04.verizon.com with ESMTP; 19 Nov 2014 17:53:14 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="873174034"
Received: from unknown (HELO don-760.CloudSwitch.com) ([162.47.5.188])
	by fldsmtpi02.verizon.com with ESMTP; 19 Nov 2014 17:53:12 +0000
Message-ID: <546CD906.40903@terremark.com>
Date: Wed, 19 Nov 2014 12:53:10 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Fabio Fantoni <fabio.fantoni@m2r.biz>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
	<546CAFB1.8070904@terremark.com> <546CBA8B.2090903@m2r.biz>
	<alpine.DEB.2.02.1411191551120.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411191551120.12596@kaball.uk.xensource.com>
Cc: anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org,
	xen-devel <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [Qemu-devel] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have posted the patch:

Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off for xenfv machine
Date: Wed, 19 Nov 2014 12:30:57 -0500
Message-ID: <1416418257-10166-1-git-send-email-dslutz@verizon.com>


Which fixes QEMU 2.2 for xenfv.  However if you configure xen_platform_pci=0 you will still
have this issue.  The good news is that xen-4.5 currently does not have QEMU 2.2 and so does
not have this issue.

Only people (groups like spice?) that want QEMU 2.2.0 with xen 4.5.0 (or older xen versions)
will hit this.

I have changes to xen 4.6 which will fix the xen_platform_pci=0 case also.

In order to get xen 4.5 to fully work with QEMU 2.2.0 (both in hard freeze)

the 1st patch from "Dr. David Alan Gilbert <dgilbert@redhat.com>"
would need to be applied to xen's qemu 2.0.2 (+ changes) so that
vmport=off can be added to --machine.

And a patch (yet to be written, subset of changes I have pending for 4.6)
that adds vmport=off to QEMU args for --machine (it can be done in all cases).

     -Don Slutz



On 11/19/14 10:52, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Fabio Fantoni wrote:
>> Il 19/11/2014 15:56, Don Slutz ha scritto:
>>> I think I know what is happening here.  But you are pointing at the wrong
>>> change.
>>>
>>> commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
>>>
>>> Is what I am guessing at this time is the issue.  I think that xen_enabled()
>>> is
>>> returning false in pc_machine_initfn.  Where as in pc_init1 is is returning
>>> true.
>>>
>>> I am thinking that:
>>>
>>>
>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>>> index 7bb97a4..3268c29 100644
>>> --- a/hw/i386/pc_piix.c
>>> +++ b/hw/i386/pc_piix.c
>>> @@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
>>>       .desc = "Xen Fully-virtualized PC",
>>>       .init = pc_xen_hvm_init,
>>>       .max_cpus = HVM_MAX_VCPUS,
>>> -    .default_machine_opts = "accel=xen",
>>> +    .default_machine_opts = "accel=xen,vmport=off",
>>>       .hot_add_cpu = pc_hot_add_cpu,
>>>   };
>>>   #endif
>>>
>>> Will fix your issue. I have not tested this yet.
>> Tested now and it solves regression of linux hvm domUs with qemu 2.2, thanks.
>> I think that I'm not the only with this regression and that this patch (or a
>> fix to the cause in vmport) should be applied before qemu 2.2 final.
> Don,
> please submit a proper patch with a Signed-off-by.
>
> Thanks!
>
> - Stefano
>
>>>      -Don Slutz
>>>
>>>
>>> On 11/19/14 09:04, Fabio Fantoni wrote:
>>>> Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
>>>>> dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid leaf
>>>>> with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, and
>>>>> qemu 2.2 from spice git (spice/next commit
>>>>> e779fa0a715530311e6f59fc8adb0f6eca914a89):
>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>> I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the full
>>>> backtrace of latest test:
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, addr=0,
>>>>>      size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>> 73          eax = env->regs[R_EAX];
>>>>> (gdb) bt full
>>>>> #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
>>>>> addr=0,
>>>>>      size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>          s = 0x5555564443a0
>>>>>          cs = 0x0
>>>>>          cpu = 0x0
>>>>>          __func__ = "vmport_ioport_read"
>>>>>          env = 0x8250
>>>>>          command = 0 '\000'
>>>>>          eax = 0
>>>>> #1  0x0000555555655fc4 in memory_region_read_accessor
>>>>> (mr=0x555556444428,
>>>>>      addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>>>          tmp = 0
>>>>> #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
>>>>>      value=0x7fffffffd8d0, size=4, access_size_min=4, access_size_max=4,
>>>>>      access=0x555555655f62 <memory_region_read_accessor>,
>>>>> mr=0x555556444428)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>>>          access_mask = 4294967295
>>>>>          access_size = 4
>>>>>          i = 0
>>>>> #3  0x00005555556590e9 in memory_region_dispatch_read1
>>>>> (mr=0x555556444428,
>>>>>      addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>>>          data = 0
>>>>> #4  0x00005555556591b1 in memory_region_dispatch_read
>>>>> (mr=0x555556444428,
>>>>>      addr=0, pval=0x7fffffffd9a8, size=4)
>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>>>> No locals.
>>>>> #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
>>>>>      pval=0x7fffffffd9a8, size=4)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>>>> No locals.
>>>>> #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920,
>>>>> addr=22104,
>>>>>      buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
>>>>>          l = 4
>>>>>          ptr = 0x555555a92d87 "%s/%d:\n"
>>>>>          val = 7852232130387826944
>>>>>          addr1 = 0
>>>>>          mr = 0x555556444428
>>>>>          error = false
>>>>> #7  0x000055555560a38f in address_space_read (as=0x555555eaf920,
>>>>> addr=22104,
>>>>>      buf=0x7fffffffda50 "\377\377\377\377", len=4)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
>>>>> No locals.
>>>>> #8  0x000055555564fd4b in cpu_inl (addr=22104)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>>>          buf = "\377\377\377\377"
>>>>>          val = 21845
>>>>> #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>> No locals.
>>>>> #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>>>          i = 1
>>>>> #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
>>>>>      req=0x7ffff7ff3020) at
>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>>>> No locals.
>>>>> #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>>>          state = 0x5555563c2510
>>>>>          req = 0x7ffff7ff3020
>>>>> #13 0x000055555596e240 in qemu_iohandler_poll (pollfds=0x555556389a30,
>>>>> ret=1)
>>>>>      at iohandler.c:143
>>>>>          revents = 1
>>>>>          pioh = 0x5555563f7610
>>>>>          ioh = 0x555556450a40
>>>>> #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at
>>>>> main-loop.c:495
>>>>>          ret = 1
>>>>>          timeout = 4294967295
>>>>>          timeout_ns = 3965432
>>>>> #15 0x0000555555756d3f in main_loop () at vl.c:1882
>>>>>          nonblocking = false
>>>>>          last_io = 0
>>>>> #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
>>>>>      envp=0x7fffffffe240) at vl.c:4400
>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>          i = 128
>>>>>          snapshot = 0
>>>>>          linux_boot = 0
>>>>>          initrd_filename = 0x0
>>>>>          kernel_filename = 0x0
>>>>>          kernel_cmdline = 0x555555a48f86 ""
>>>>>          boot_order = 0x555556387460 "dc"
>>>>>          ds = 0x5555564b2040
>>>>>          cyls = 0
>>>>>          heads = 0
>>>>>          secs = 0
>>>>>          translation = 0
>>>>>          hda_opts = 0x0
>>>>>          opts = 0x5555563873b0
>>>>>          machine_opts = 0x555556389010
>>>>>          icount_opts = 0x0
>>>>>          olist = 0x555555e57e80
>>>>>          optind = 62
>>>>>          optarg = 0x7fffffffe914
>>>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>>>          loadvm = 0x0
>>>>>          machine_class = 0x55555637d5c0
>>>>>          cpu_model = 0x0
>>>>>          vga_model = 0x0
>>>>>          qtest_chrdev = 0x0
>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>          qtest_log = 0x0
>>>>>          pid_file = 0x0
>>>>>          incoming = 0x0
>>>>>          show_vnc_port = 0
>>>>>          defconfig = true
>>>>>          userconfig = true
>>>>>          log_mask = 0x0
>>>>>          log_file = 0x0
>>>>>          mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
>>>>>            realloc = 0x55555575a45a <realloc_and_trace>,
>>>>>            free = 0x55555575a4c1 <free_and_trace>, calloc = 0, try_malloc
>>>>> = 0,
>>>>>            try_realloc = 0}
>>>>>          trace_events = 0x0
>>>>>          trace_file = 0x0
>>>>>          default_ram_size = 134217728
>>>>>          maxram_size = 2130706432
>>>>>          ram_slots = 0
>>>>>          vmstate_dump_file = 0x0
>>>>>          main_loop_err = 0x0
>>>>>          __func__ = "main"
>>>> I take a fast look in source based on calltrace and I saw this commit:
>>>> http://secure-web.cisco.com/1EXVvN4KugVmCtI8RnLSX68LVqyly3ymtr7bhU7HDX8viw0fYlCBA54KE1K_VbwvaJhMDSmpeNsTiBHicuNWfTtG_XH9DP4c-7oqEb6kCcWzXKnCcQNOb9ikh4FRIBDr9R069aR0R5fdiB9q4iQSFDc4X0ttOQHu8h69rpG-X2bI/http%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dcommit%3Bh%3D37f9e258b64b3cf97c7c78df60660100c9eb5a21
>>>> xen-hvm.c: Add support for Xen access to vmport
>>>> Can be the cause of regression and I must try another test reverting this
>>>> commit or is not related?
>>>>
>>>> Thanks for any reply anddo sorry for my bad english.
>>>>
>>>>> Qemu crash on fedora 20 lxde (with software updates of some days ago)
>>>>> boot with this backtrace:
>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
>>>>>> addr=0, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>> 73          eax = env->regs[R_EAX];
>>>>>> (gdb) bt full
>>>>>> #0  0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
>>>>>> addr=0, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>>          s = 0x555556440a20
>>>>>>          cs = 0x0
>>>>>>          cpu = 0x0
>>>>>>          __func__ = "vmport_ioport_read"
>>>>>>          env = 0x8250
>>>>>>          command = 0 '\000'
>>>>>>          eax = 0
>>>>>> #1  0x0000555555655b9c in memory_region_read_accessor
>>>>>> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0,
>>>>>> mask=4294967295)
>>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>>>>          tmp = 0
>>>>>> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0,
>>>>>> value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
>>>>>>      access=0x555555655b3a <memory_region_read_accessor>,
>>>>>> mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>>>>          access_mask = 4294967295
>>>>>>          access_size = 4
>>>>>>          i = 0
>>>>>> #3  0x0000555555658cc1 in memory_region_dispatch_read1
>>>>>> (mr=0x555556440aa8, addr=0, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>>>>          data = 0
>>>>>> #4  0x0000555555658d89 in memory_region_dispatch_read
>>>>>> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>>>>> No locals.
>>>>>> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0,
>>>>>> pval=0x7fffffffd998, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>>>>> No locals.
>>>>>> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840,
>>>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4,
>>>>>> is_write=false)
>>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>>>>>>          l = 4
>>>>>>          ptr = 0x0
>>>>>>          val = 7964229952888770560
>>>>>>          addr1 = 0
>>>>>>          mr = 0x555556440aa8
>>>>>>          error = false
>>>>>> #7  0x000055555560a173 in address_space_read (as=0x555555eae840,
>>>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
>>>>>> No locals.
>>>>>> #8  0x000055555564fac7 in cpu_inl (addr=22104) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>>>>          buf = "\377\377\377\377"
>>>>>>          val = 21845
>>>>>> #9  0x000055555567084b in do_inp (addr=22104, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>>>>> No locals.
>>>>>> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>>>>          i = 0
>>>>>> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590,
>>>>>> req=0x7ffff7ff3000) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>> No locals.
>>>>>> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>>>>          state = 0x5555563c1590
>>>>>>          req = 0x7ffff7ff3000
>>>>>> #13 0x000055555596d874 in qemu_iohandler_poll (pollfds=0x555556388a30,
>>>>>> ret=1) at iohandler.c:143
>>>>>>          revents = 1
>>>>>>          pioh = 0x5555563f3c90
>>>>>>          ioh = 0x555556515f80
>>>>>> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at
>>>>>> main-loop.c:495
>>>>>>          ret = 1
>>>>>>          timeout = 4294967295
>>>>>>          timeout_ns = 3418165
>>>>>> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>>>>>>          nonblocking = false
>>>>>>          last_io = 1
>>>>>> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038,
>>>>>> envp=0x7fffffffe230) at vl.c:4400
>>>>>>          i = 128
>>>>>>          snapshot = 0
>>>>>>          linux_boot = 0
>>>>>>          initrd_filename = 0x0
>>>>>>          kernel_filename = 0x0
>>>>>>          kernel_cmdline = 0x555555a485c6 ""
>>>>>>          boot_order = 0x5555563864e0 "dc"
>>>>>>          ds = 0x5555564c71b0
>>>>>>          cyls = 0
>>>>>>          heads = 0
>>>>>>          secs = 0
>>>>>>          translation = 0
>>>>>>          hda_opts = 0x0
>>>>>>          opts = 0x555556386430
>>>>>>          machine_opts = 0x555556388090
>>>>>>          icount_opts = 0x0
>>>>>>          olist = 0x555555e56da0
>>>>>>          optind = 62
>>>>>>          optarg = 0x7fffffffe914
>>>>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>>>>          loadvm = 0x0
>>>>>>          machine_class = 0x55555637c5c0
>>>>>>          cpu_model = 0x0
>>>>>>          vga_model = 0x0
>>>>>>          qtest_chrdev = 0x0
>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>          qtest_log = 0x0
>>>>>>          pid_file = 0x0
>>>>>>          incoming = 0x0
>>>>>>          show_vnc_port = 0
>>>>>>          defconfig = true
>>>>>>          userconfig = true
>>>>>>          log_mask = 0x0
>>>>>>          log_file = 0x0
>>>>>>          mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>,
>>>>>> realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39
>>>>>> <free_and_trace>, calloc = 0,
>>>>>>            try_malloc = 0, try_realloc = 0}
>>>>>>          trace_events = 0x0
>>>>>>          trace_file = 0x0
>>>>>>          default_ram_size = 134217728
>>>>>>          maxram_size = 2013265920
>>>>>>          ram_slots = 0
>>>>>>          vmstate_dump_file = 0x0
>>>>>>          main_loop_err = 0x0
>>>>>>          __func__ = "main"
>>>>>
>>>>>> xl -vvv create /etc/xen/FEDORA19.cfg
>>>>>> Parsing config from /etc/xen/FEDORA19.cfg
>>>>>> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660:
>>>>>> create: how=(nil) callback=(nil) poller=0xac2af0
>>>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
>>>>>> vdev=hda spec.backend=unknown
>>>>>> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda,
>>>>>> backend phy unsuitable as phys path not a block device
>>>>>> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
>>>>>> vdev=hda, using backend qdisk
>>>>>> libxl: debug: libxl_create.c:935:initiate_domain_create: running
>>>>>> bootloader
>>>>>> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV
>>>>>> domain, skipping bootloader
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac32f8: deregister unregistered
>>>>>> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
>>>>>> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
>>>>>> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
>>>>>> xc: detail:   Loader: 0000000000100000->000000000036b324
>>>>>> xc: detail:   Modules: 0000000000000000->0000000000000000
>>>>>> xc: detail:   TOTAL: 0000000000000000->0000000078000000
>>>>>> xc: detail:   ENTRY:    0000000000100000
>>>>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>>>>> xc: detail:   4KB PAGES: 0x0000000000000200
>>>>>> xc: detail:   2MB PAGES: 0x00000000000003bf
>>>>>> xc: detail:   1GB PAGES: 0x0000000000000000
>>>>>> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 ->
>>>>>> 0x7f1f975012b0
>>>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
>>>>>> vdev=hda spec.backend=qdisk
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac4ad0: deregister unregistered
>>>>>> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning
>>>>>> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> /usr/lib/xen/bin/qemu-gdb
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> chardev=libxl-cmd,mode=control
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: FEDORA
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -spice
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> spicevmc,id=vdagent,name=vdagent
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> virtserialport,chardev=vdagent,name=com.redhat.spice.0
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> qxl-vga,vram_size_mb=64,ram_size_mb=64
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> spicevmc,name=usbredir,id=usbrc1
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> usb-redir,chardev=usbrc1,id=usbrc1
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> spicevmc,name=usbredir,id=usbrc2
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> usb-redir,chardev=usbrc2,id=usbrc2
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> spicevmc,name=usbredir,id=usbrc3
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> usb-redir,chardev=usbrc3,id=usbrc3
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> spicevmc,name=usbredir,id=usbrc4
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> usb-redir,chardev=usbrc4,id=usbrc4
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -netdev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -drive
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
>>>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
>>>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
>>>>>> register slotnum=3
>>>>>> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660:
>>>>>> inprogress: poller=0xac2af0, flags=i
>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
>>>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event
>>>>>> epath=/local/domain/0/device-model/9/state
>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
>>>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event
>>>>>> epath=/local/domain/0/device-model/9/state
>>>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
>>>>>> deregister slotnum=3
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac3558: deregister unregistered
>>>>>> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to
>>>>>> /var/run/xen/qmp-libxl-9
>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>>>      "execute": "qmp_capabilities",
>>>>>>      "id": 1
>>>>>> }
>>>>>> '
>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>> return
>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>>>      "execute": "query-chardev",
>>>>>>      "id": 2
>>>>>> }
>>>>>> '
>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>> return
>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>>>      "execute": "query-vnc",
>>>>>>      "id": 3
>>>>>> }
>>>>>> '
>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>> return
>>>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
>>>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
>>>>>> register slotnum=3
>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
>>>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
>>>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>>>> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend
>>>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting
>>>>>> state 1
>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
>>>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
>>>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>>>> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend
>>>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
>>>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
>>>>>> deregister slotnum=3
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac8368: deregister unregistered
>>>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
>>>>>> script: /etc/xen/scripts/vif-bridge online
>>>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to
>>>>>> execute: /etc/xen/scripts/vif-bridge online
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac83f0: deregister unregistered
>>>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
>>>>>> script: /etc/xen/scripts/vif-bridge add
>>>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to
>>>>>> execute: /etc/xen/scripts/vif-bridge add
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac83f0: deregister unregistered
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac83f0: deregister unregistered
>>>>>> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao
>>>>>> 0xac2660: progress report: ignored
>>>>>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660:
>>>>>> complete, rc=0
>>>>>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660:
>>>>>> destroy
>>>>>> xc: debug: hypercall buffer: total allocations:704 total releases:704
>>>>>> xc: debug: hypercall buffer: current allocations:0 maximum
>>>>>> allocations:4
>>>>>> xc: debug: hypercall buffer: cache current size:4
>>>>>> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
>>>>>> xc: debug: hypercall buffer: total allocations:0 total releases:0
>>>>>> xc: debug: hypercall buffer: current allocations:0 maximum
>>>>>> allocations:0
>>>>>> xc: debug: hypercall buffer: cache current size:0
>>>>>> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
>>>>> xl dmesg
>>>>>> (d9) HVM Loader
>>>>>> (d9) Detected Xen v4.5.0-rc
>>>>>> (d9) Xenbus rings @0xfeffc000, event channel 1
>>>>>> (d9) System requested SeaBIOS
>>>>>> (d9) CPU speed is 2660 MHz
>>>>>> (d9) Relocating guest memory for lowmem MMIO space disabled
>>>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
>>>>>> (d9) PCI-ISA link 0 routed to IRQ5
>>>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
>>>>>> (d9) PCI-ISA link 1 routed to IRQ10
>>>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
>>>>>> (d9) PCI-ISA link 2 routed to IRQ11
>>>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
>>>>>> (d9) PCI-ISA link 3 routed to IRQ5
>>>>>> (d9) pci dev 01:3 INTA->IRQ10
>>>>>> (d9) pci dev 02:0 INTA->IRQ11
>>>>>> (d9) pci dev 03:0 INTA->IRQ5
>>>>>> (d9) pci dev 04:0 INTA->IRQ5
>>>>>> (d9) pci dev 05:0 INTA->IRQ10
>>>>>> (d9) pci dev 06:0 INTA->IRQ11
>>>>>> (d9) pci dev 1d:0 INTA->IRQ10
>>>>>> (d9) pci dev 1d:1 INTB->IRQ11
>>>>>> (d9) pci dev 1d:2 INTC->IRQ5
>>>>>> (d9) pci dev 1d:7 INTD->IRQ5
>>>>>> (d9) No RAM in high memory; setting high_mem resource base to
>>>>>> 100000000
>>>>>> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>>>>> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>>>>> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>>>>> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>>>>> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>>>>> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>>>>> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>>>>> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>>>>> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>>>>> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
>>>>>> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
>>>>>> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>>>>> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
>>>>>> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
>>>>>> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>>>>> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>>>>> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>>>>> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>>>>> (d9) Multiprocessor initialisation:
>>>>>> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ...
>>>>>> done.
>>>>>> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ...
>>>>>> done.
>>>>>> (d9) Testing HVM environment:
>>>>>> (d9)  - REP INSB across page boundaries ... passed
>>>>>> (d9)  - GS base MSRs and SWAPGS ... passed
>>>>>> (d9) Passed 2 of 2 tests
>>>>>> (d9) Writing SMBIOS tables ...
>>>>>> (d9) Loading SeaBIOS ...
>>>>>> (d9) Creating MP tables ...
>>>>>> (d9) Loading ACPI ...
>>>>>> (d9) S3 disabled
>>>>>> (d9) S4 disabled
>>>>>> (d9) vm86 TSS at fc00a100
>>>>>> (d9) BIOS map:
>>>>>> (d9)  10000-100d3: Scratch space
>>>>>> (d9)  c0000-fffff: Main BIOS
>>>>>> (d9) E820 table:
>>>>>> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>>>>> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>>>>> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>>>>> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>>>>> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
>>>>>> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>>>>> (d9) Invoking SeaBIOS ...
>>>>>> (d9) SeaBIOS (version
>>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>>> (d9)
>>>>>> (d9) Found Xen hypervisor signature at 40000000
>>>>>> (d9) Running on QEMU (i440fx)
>>>>>> (d9) xen: copy e820...
>>>>>> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>>>>> (d9) CPU Mhz=2660
>>>>>> (d9) Found 13 PCI devices (max PCI bus is 00)
>>>>>> (d9) Allocated Xen hypercall page at 77fff000
>>>>>> (d9) Detected Xen v4.5.0-rc
>>>>>> (d9) xen: copy BIOS tables...
>>>>>> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>>>>> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>>>>> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
>>>>>> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>>>>> (d9) Using pmtimer, ioport 0xb008
>>>>>> (d9) Scan for VGA option rom
>>>>>> (d9) Running option rom at c000:0003
>>>>>> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
>>>>>> (d9) pmm call arg1=0
>>>>>> (d9) Turning on vga text mode console
>>>>>> (d9) SeaBIOS (version
>>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>>> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
>>>>>> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
>>>>>> (d9) Found 0 lpt ports
>>>>>> (d9) Found 0 serial ports
>>>>>> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>>>>> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>>>>> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
>>>>>> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>>>>> (d9) UHCI init on dev 00:1d.0 (io=c240)
>>>>>> (d9) UHCI init on dev 00:1d.1 (io=c260)
>>>>>> (d9) UHCI init on dev 00:1d.2 (io=c280)
>>>>>> (d9) PS2 keyboard initialized
>>>>>> (d9) All threads complete.
>>>>>> (d9) Scan for option roms
>>>>>> (d9) Running option rom at c980:0003
>>>>>> (d9) pmm call arg1=1
>>>>>> (d9) pmm call arg1=0
>>>>>> (d9) pmm call arg1=1
>>>>>> (d9) pmm call arg1=0
>>>>>> (d9) Searching bootorder for: /pci@i0cf8/*@6
>>>>>> (d9)
>>>>>> (d9) Press F12 for boot menu.
>>>>>> (d9)
>>>>>> (d9) Searching bootorder for: HALT
>>>>>> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba
>>>>>> LCHS=1024/255/63 s=20480000
>>>>>> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
>>>>>> (d9) Returned 258048 bytes of ZoneHigh
>>>>>> (d9) e820 map has 6 items:
>>>>>> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>>>>>> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>>>>>> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>>>>>> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
>>>>>> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
>>>>>> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
>>>>>> (d9) enter handle_19:
>>>>>> (d9)   NULL
>>>>>> (d9) Booting from Hard Disk...
>>>>>> (d9) Booting from 0000:7c00
>>>>>> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
>>>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
>>>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
>>>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
>>>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
>>>>> domU's xl cfg:
>>>>>> name='FEDORA'
>>>>>> builder="hvm"
>>>>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>>> memory=2048
>>>>>> vcpus=2
>>>>>> acpi_s3=0
>>>>>> acpi_s4=0
>>>>>> vif=['bridge=xenbr0']
>>>>>> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
>>>>>> boot='dc'
>>>>>> device_model_version='qemu-xen'
>>>>>> vnc=0
>>>>>> keymap="it"
>>>>>> vga="qxl"
>>>>>> spice=1
>>>>>> spicehost='0.0.0.0'
>>>>>> spiceport=6005
>>>>>> spicedisable_ticketing=1
>>>>>> spicevdagent=1
>>>>>> spice_clipboard_sharing=0
>>>>>> spiceusbredirection=4
>>>>>> soundhw="hda"
>>>>> I tested also with stdvga instead of qxl vga but qemu crash always on
>>>>> fedora boot with same error.
>>>>>
>>>>> If you need more informations/tests tell me and I'll post them.
>>>>>
>>>>> Thanks for any reply and sorry for my bad english.
>>>>>
>>>>
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:53:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 17: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.xen.org>)
	id 1Xr9RP-0007Lk-Fg; Wed, 19 Nov 2014 17:53:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xr9RN-0007Ld-T7
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 17:53:18 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	AF/1B-31453-D09DC645; Wed, 19 Nov 2014 17:53:17 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416419595!7021360!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3962 invoked from network); 19 Nov 2014 17:53:15 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 17:53:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416419595; x=1447955595;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=+2dKELeXMQ2sRD/1d1lMK4TskkzNOU+gWfBMnJbo628=;
	b=hTVckAE5La0I7loR9Ely7uxaH1RsnfI5b0elQ5DR6+SN8kT2bBZqCqlB
	vDF/CY5ye4LT7ph7G6HSjOKDKn6SGe3PMJAgZqj9qEIfVmsQ1s7gaq+vG
	N+BpsRSWrrkVOxHQk6dYiMzgkSTj7p90mODuxVYwtTlJAxfY52GmVocoh c=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by fldsmtpe04.verizon.com with ESMTP; 19 Nov 2014 17:53:14 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="873174034"
Received: from unknown (HELO don-760.CloudSwitch.com) ([162.47.5.188])
	by fldsmtpi02.verizon.com with ESMTP; 19 Nov 2014 17:53:12 +0000
Message-ID: <546CD906.40903@terremark.com>
Date: Wed, 19 Nov 2014 12:53:10 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Fabio Fantoni <fabio.fantoni@m2r.biz>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
	<546CAFB1.8070904@terremark.com> <546CBA8B.2090903@m2r.biz>
	<alpine.DEB.2.02.1411191551120.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411191551120.12596@kaball.uk.xensource.com>
Cc: anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org,
	xen-devel <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [Qemu-devel] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have posted the patch:

Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off for xenfv machine
Date: Wed, 19 Nov 2014 12:30:57 -0500
Message-ID: <1416418257-10166-1-git-send-email-dslutz@verizon.com>


Which fixes QEMU 2.2 for xenfv.  However if you configure xen_platform_pci=0 you will still
have this issue.  The good news is that xen-4.5 currently does not have QEMU 2.2 and so does
not have this issue.

Only people (groups like spice?) that want QEMU 2.2.0 with xen 4.5.0 (or older xen versions)
will hit this.

I have changes to xen 4.6 which will fix the xen_platform_pci=0 case also.

In order to get xen 4.5 to fully work with QEMU 2.2.0 (both in hard freeze)

the 1st patch from "Dr. David Alan Gilbert <dgilbert@redhat.com>"
would need to be applied to xen's qemu 2.0.2 (+ changes) so that
vmport=off can be added to --machine.

And a patch (yet to be written, subset of changes I have pending for 4.6)
that adds vmport=off to QEMU args for --machine (it can be done in all cases).

     -Don Slutz



On 11/19/14 10:52, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Fabio Fantoni wrote:
>> Il 19/11/2014 15:56, Don Slutz ha scritto:
>>> I think I know what is happening here.  But you are pointing at the wrong
>>> change.
>>>
>>> commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
>>>
>>> Is what I am guessing at this time is the issue.  I think that xen_enabled()
>>> is
>>> returning false in pc_machine_initfn.  Where as in pc_init1 is is returning
>>> true.
>>>
>>> I am thinking that:
>>>
>>>
>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>>> index 7bb97a4..3268c29 100644
>>> --- a/hw/i386/pc_piix.c
>>> +++ b/hw/i386/pc_piix.c
>>> @@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
>>>       .desc = "Xen Fully-virtualized PC",
>>>       .init = pc_xen_hvm_init,
>>>       .max_cpus = HVM_MAX_VCPUS,
>>> -    .default_machine_opts = "accel=xen",
>>> +    .default_machine_opts = "accel=xen,vmport=off",
>>>       .hot_add_cpu = pc_hot_add_cpu,
>>>   };
>>>   #endif
>>>
>>> Will fix your issue. I have not tested this yet.
>> Tested now and it solves regression of linux hvm domUs with qemu 2.2, thanks.
>> I think that I'm not the only with this regression and that this patch (or a
>> fix to the cause in vmport) should be applied before qemu 2.2 final.
> Don,
> please submit a proper patch with a Signed-off-by.
>
> Thanks!
>
> - Stefano
>
>>>      -Don Slutz
>>>
>>>
>>> On 11/19/14 09:04, Fabio Fantoni wrote:
>>>> Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
>>>>> dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid leaf
>>>>> with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, and
>>>>> qemu 2.2 from spice git (spice/next commit
>>>>> e779fa0a715530311e6f59fc8adb0f6eca914a89):
>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>> I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the full
>>>> backtrace of latest test:
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0, addr=0,
>>>>>      size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>> 73          eax = env->regs[R_EAX];
>>>>> (gdb) bt full
>>>>> #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
>>>>> addr=0,
>>>>>      size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>          s = 0x5555564443a0
>>>>>          cs = 0x0
>>>>>          cpu = 0x0
>>>>>          __func__ = "vmport_ioport_read"
>>>>>          env = 0x8250
>>>>>          command = 0 '\000'
>>>>>          eax = 0
>>>>> #1  0x0000555555655fc4 in memory_region_read_accessor
>>>>> (mr=0x555556444428,
>>>>>      addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>>>          tmp = 0
>>>>> #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
>>>>>      value=0x7fffffffd8d0, size=4, access_size_min=4, access_size_max=4,
>>>>>      access=0x555555655f62 <memory_region_read_accessor>,
>>>>> mr=0x555556444428)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>>>          access_mask = 4294967295
>>>>>          access_size = 4
>>>>>          i = 0
>>>>> #3  0x00005555556590e9 in memory_region_dispatch_read1
>>>>> (mr=0x555556444428,
>>>>>      addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>>>          data = 0
>>>>> #4  0x00005555556591b1 in memory_region_dispatch_read
>>>>> (mr=0x555556444428,
>>>>>      addr=0, pval=0x7fffffffd9a8, size=4)
>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>>>> No locals.
>>>>> #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
>>>>>      pval=0x7fffffffd9a8, size=4)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>>>> No locals.
>>>>> #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920,
>>>>> addr=22104,
>>>>>      buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
>>>>>          l = 4
>>>>>          ptr = 0x555555a92d87 "%s/%d:\n"
>>>>>          val = 7852232130387826944
>>>>>          addr1 = 0
>>>>>          mr = 0x555556444428
>>>>>          error = false
>>>>> #7  0x000055555560a38f in address_space_read (as=0x555555eaf920,
>>>>> addr=22104,
>>>>>      buf=0x7fffffffda50 "\377\377\377\377", len=4)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
>>>>> No locals.
>>>>> #8  0x000055555564fd4b in cpu_inl (addr=22104)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>>>          buf = "\377\377\377\377"
>>>>>          val = 21845
>>>>> #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>> No locals.
>>>>> #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>>>          i = 1
>>>>> #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
>>>>>      req=0x7ffff7ff3020) at
>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>>>> No locals.
>>>>> #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>>>          state = 0x5555563c2510
>>>>>          req = 0x7ffff7ff3020
>>>>> #13 0x000055555596e240 in qemu_iohandler_poll (pollfds=0x555556389a30,
>>>>> ret=1)
>>>>>      at iohandler.c:143
>>>>>          revents = 1
>>>>>          pioh = 0x5555563f7610
>>>>>          ioh = 0x555556450a40
>>>>> #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at
>>>>> main-loop.c:495
>>>>>          ret = 1
>>>>>          timeout = 4294967295
>>>>>          timeout_ns = 3965432
>>>>> #15 0x0000555555756d3f in main_loop () at vl.c:1882
>>>>>          nonblocking = false
>>>>>          last_io = 0
>>>>> #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
>>>>>      envp=0x7fffffffe240) at vl.c:4400
>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>          i = 128
>>>>>          snapshot = 0
>>>>>          linux_boot = 0
>>>>>          initrd_filename = 0x0
>>>>>          kernel_filename = 0x0
>>>>>          kernel_cmdline = 0x555555a48f86 ""
>>>>>          boot_order = 0x555556387460 "dc"
>>>>>          ds = 0x5555564b2040
>>>>>          cyls = 0
>>>>>          heads = 0
>>>>>          secs = 0
>>>>>          translation = 0
>>>>>          hda_opts = 0x0
>>>>>          opts = 0x5555563873b0
>>>>>          machine_opts = 0x555556389010
>>>>>          icount_opts = 0x0
>>>>>          olist = 0x555555e57e80
>>>>>          optind = 62
>>>>>          optarg = 0x7fffffffe914
>>>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>>>          loadvm = 0x0
>>>>>          machine_class = 0x55555637d5c0
>>>>>          cpu_model = 0x0
>>>>>          vga_model = 0x0
>>>>>          qtest_chrdev = 0x0
>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>          qtest_log = 0x0
>>>>>          pid_file = 0x0
>>>>>          incoming = 0x0
>>>>>          show_vnc_port = 0
>>>>>          defconfig = true
>>>>>          userconfig = true
>>>>>          log_mask = 0x0
>>>>>          log_file = 0x0
>>>>>          mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
>>>>>            realloc = 0x55555575a45a <realloc_and_trace>,
>>>>>            free = 0x55555575a4c1 <free_and_trace>, calloc = 0, try_malloc
>>>>> = 0,
>>>>>            try_realloc = 0}
>>>>>          trace_events = 0x0
>>>>>          trace_file = 0x0
>>>>>          default_ram_size = 134217728
>>>>>          maxram_size = 2130706432
>>>>>          ram_slots = 0
>>>>>          vmstate_dump_file = 0x0
>>>>>          main_loop_err = 0x0
>>>>>          __func__ = "main"
>>>> I take a fast look in source based on calltrace and I saw this commit:
>>>> http://secure-web.cisco.com/1EXVvN4KugVmCtI8RnLSX68LVqyly3ymtr7bhU7HDX8viw0fYlCBA54KE1K_VbwvaJhMDSmpeNsTiBHicuNWfTtG_XH9DP4c-7oqEb6kCcWzXKnCcQNOb9ikh4FRIBDr9R069aR0R5fdiB9q4iQSFDc4X0ttOQHu8h69rpG-X2bI/http%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dcommit%3Bh%3D37f9e258b64b3cf97c7c78df60660100c9eb5a21
>>>> xen-hvm.c: Add support for Xen access to vmport
>>>> Can be the cause of regression and I must try another test reverting this
>>>> commit or is not related?
>>>>
>>>> Thanks for any reply anddo sorry for my bad english.
>>>>
>>>>> Qemu crash on fedora 20 lxde (with software updates of some days ago)
>>>>> boot with this backtrace:
>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
>>>>>> addr=0, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>> 73          eax = env->regs[R_EAX];
>>>>>> (gdb) bt full
>>>>>> #0  0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
>>>>>> addr=0, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>>          s = 0x555556440a20
>>>>>>          cs = 0x0
>>>>>>          cpu = 0x0
>>>>>>          __func__ = "vmport_ioport_read"
>>>>>>          env = 0x8250
>>>>>>          command = 0 '\000'
>>>>>>          eax = 0
>>>>>> #1  0x0000555555655b9c in memory_region_read_accessor
>>>>>> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0,
>>>>>> mask=4294967295)
>>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>>>>          tmp = 0
>>>>>> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0,
>>>>>> value=0x7fffffffd8c0, size=4, access_size_min=4, access_size_max=4,
>>>>>>      access=0x555555655b3a <memory_region_read_accessor>,
>>>>>> mr=0x555556440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>>>>          access_mask = 4294967295
>>>>>>          access_size = 4
>>>>>>          i = 0
>>>>>> #3  0x0000555555658cc1 in memory_region_dispatch_read1
>>>>>> (mr=0x555556440aa8, addr=0, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>>>>          data = 0
>>>>>> #4  0x0000555555658d89 in memory_region_dispatch_read
>>>>>> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>>>>> No locals.
>>>>>> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0,
>>>>>> pval=0x7fffffffd998, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>>>>> No locals.
>>>>>> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840,
>>>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4,
>>>>>> is_write=false)
>>>>>>      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>>>>>>          l = 4
>>>>>>          ptr = 0x0
>>>>>>          val = 7964229952888770560
>>>>>>          addr1 = 0
>>>>>>          mr = 0x555556440aa8
>>>>>>          error = false
>>>>>> #7  0x000055555560a173 in address_space_read (as=0x555555eae840,
>>>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
>>>>>> No locals.
>>>>>> #8  0x000055555564fac7 in cpu_inl (addr=22104) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>>>>          buf = "\377\377\377\377"
>>>>>>          val = 21845
>>>>>> #9  0x000055555567084b in do_inp (addr=22104, size=4) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>>>>> No locals.
>>>>>> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>>>>          i = 0
>>>>>> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590,
>>>>>> req=0x7ffff7ff3000) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>> No locals.
>>>>>> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590) at
>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>>>>          state = 0x5555563c1590
>>>>>>          req = 0x7ffff7ff3000
>>>>>> #13 0x000055555596d874 in qemu_iohandler_poll (pollfds=0x555556388a30,
>>>>>> ret=1) at iohandler.c:143
>>>>>>          revents = 1
>>>>>>          pioh = 0x5555563f3c90
>>>>>>          ioh = 0x555556515f80
>>>>>> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at
>>>>>> main-loop.c:495
>>>>>>          ret = 1
>>>>>>          timeout = 4294967295
>>>>>>          timeout_ns = 3418165
>>>>>> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>>>>>>          nonblocking = false
>>>>>>          last_io = 1
>>>>>> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038,
>>>>>> envp=0x7fffffffe230) at vl.c:4400
>>>>>>          i = 128
>>>>>>          snapshot = 0
>>>>>>          linux_boot = 0
>>>>>>          initrd_filename = 0x0
>>>>>>          kernel_filename = 0x0
>>>>>>          kernel_cmdline = 0x555555a485c6 ""
>>>>>>          boot_order = 0x5555563864e0 "dc"
>>>>>>          ds = 0x5555564c71b0
>>>>>>          cyls = 0
>>>>>>          heads = 0
>>>>>>          secs = 0
>>>>>>          translation = 0
>>>>>>          hda_opts = 0x0
>>>>>>          opts = 0x555556386430
>>>>>>          machine_opts = 0x555556388090
>>>>>>          icount_opts = 0x0
>>>>>>          olist = 0x555555e56da0
>>>>>>          optind = 62
>>>>>>          optarg = 0x7fffffffe914
>>>>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>>>>          loadvm = 0x0
>>>>>>          machine_class = 0x55555637c5c0
>>>>>>          cpu_model = 0x0
>>>>>>          vga_model = 0x0
>>>>>>          qtest_chrdev = 0x0
>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>          qtest_log = 0x0
>>>>>>          pid_file = 0x0
>>>>>>          incoming = 0x0
>>>>>>          show_vnc_port = 0
>>>>>>          defconfig = true
>>>>>>          userconfig = true
>>>>>>          log_mask = 0x0
>>>>>>          log_file = 0x0
>>>>>>          mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>,
>>>>>> realloc = 0x555555759ed2 <realloc_and_trace>, free = 0x555555759f39
>>>>>> <free_and_trace>, calloc = 0,
>>>>>>            try_malloc = 0, try_realloc = 0}
>>>>>>          trace_events = 0x0
>>>>>>          trace_file = 0x0
>>>>>>          default_ram_size = 134217728
>>>>>>          maxram_size = 2013265920
>>>>>>          ram_slots = 0
>>>>>>          vmstate_dump_file = 0x0
>>>>>>          main_loop_err = 0x0
>>>>>>          __func__ = "main"
>>>>>
>>>>>> xl -vvv create /etc/xen/FEDORA19.cfg
>>>>>> Parsing config from /etc/xen/FEDORA19.cfg
>>>>>> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660:
>>>>>> create: how=(nil) callback=(nil) poller=0xac2af0
>>>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
>>>>>> vdev=hda spec.backend=unknown
>>>>>> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda,
>>>>>> backend phy unsuitable as phys path not a block device
>>>>>> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
>>>>>> vdev=hda, using backend qdisk
>>>>>> libxl: debug: libxl_create.c:935:initiate_domain_create: running
>>>>>> bootloader
>>>>>> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV
>>>>>> domain, skipping bootloader
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac32f8: deregister unregistered
>>>>>> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
>>>>>> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
>>>>>> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
>>>>>> xc: detail:   Loader: 0000000000100000->000000000036b324
>>>>>> xc: detail:   Modules: 0000000000000000->0000000000000000
>>>>>> xc: detail:   TOTAL: 0000000000000000->0000000078000000
>>>>>> xc: detail:   ENTRY:    0000000000100000
>>>>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>>>>> xc: detail:   4KB PAGES: 0x0000000000000200
>>>>>> xc: detail:   2MB PAGES: 0x00000000000003bf
>>>>>> xc: detail:   1GB PAGES: 0x0000000000000000
>>>>>> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 ->
>>>>>> 0x7f1f975012b0
>>>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
>>>>>> vdev=hda spec.backend=qdisk
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac4ad0: deregister unregistered
>>>>>> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning
>>>>>> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> /usr/lib/xen/bin/qemu-gdb
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> chardev=libxl-cmd,mode=control
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: FEDORA
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -spice
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> spicevmc,id=vdagent,name=vdagent
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> virtserialport,chardev=vdagent,name=com.redhat.spice.0
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> qxl-vga,vram_size_mb=64,ram_size_mb=64
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> spicevmc,name=usbredir,id=usbrc1
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> usb-redir,chardev=usbrc1,id=usbrc1
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> spicevmc,name=usbredir,id=usbrc2
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> usb-redir,chardev=usbrc2,id=usbrc2
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> spicevmc,name=usbredir,id=usbrc3
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> usb-redir,chardev=usbrc3,id=usbrc3
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> spicevmc,name=usbredir,id=usbrc4
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> usb-redir,chardev=usbrc4,id=usbrc4
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -netdev
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -drive
>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
>>>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
>>>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
>>>>>> register slotnum=3
>>>>>> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660:
>>>>>> inprogress: poller=0xac2af0, flags=i
>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
>>>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event
>>>>>> epath=/local/domain/0/device-model/9/state
>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
>>>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event
>>>>>> epath=/local/domain/0/device-model/9/state
>>>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
>>>>>> deregister slotnum=3
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac3558: deregister unregistered
>>>>>> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to
>>>>>> /var/run/xen/qmp-libxl-9
>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>>>      "execute": "qmp_capabilities",
>>>>>>      "id": 1
>>>>>> }
>>>>>> '
>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>> return
>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>>>      "execute": "query-chardev",
>>>>>>      "id": 2
>>>>>> }
>>>>>> '
>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>> return
>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
>>>>>>      "execute": "query-vnc",
>>>>>>      "id": 3
>>>>>> }
>>>>>> '
>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>> return
>>>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
>>>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
>>>>>> register slotnum=3
>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
>>>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
>>>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>>>> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend
>>>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting
>>>>>> state 1
>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
>>>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
>>>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>>>> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend
>>>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
>>>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
>>>>>> deregister slotnum=3
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac8368: deregister unregistered
>>>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
>>>>>> script: /etc/xen/scripts/vif-bridge online
>>>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to
>>>>>> execute: /etc/xen/scripts/vif-bridge online
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac83f0: deregister unregistered
>>>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
>>>>>> script: /etc/xen/scripts/vif-bridge add
>>>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to
>>>>>> execute: /etc/xen/scripts/vif-bridge add
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac83f0: deregister unregistered
>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch
>>>>>> w=0xac83f0: deregister unregistered
>>>>>> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao
>>>>>> 0xac2660: progress report: ignored
>>>>>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660:
>>>>>> complete, rc=0
>>>>>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660:
>>>>>> destroy
>>>>>> xc: debug: hypercall buffer: total allocations:704 total releases:704
>>>>>> xc: debug: hypercall buffer: current allocations:0 maximum
>>>>>> allocations:4
>>>>>> xc: debug: hypercall buffer: cache current size:4
>>>>>> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
>>>>>> xc: debug: hypercall buffer: total allocations:0 total releases:0
>>>>>> xc: debug: hypercall buffer: current allocations:0 maximum
>>>>>> allocations:0
>>>>>> xc: debug: hypercall buffer: cache current size:0
>>>>>> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
>>>>> xl dmesg
>>>>>> (d9) HVM Loader
>>>>>> (d9) Detected Xen v4.5.0-rc
>>>>>> (d9) Xenbus rings @0xfeffc000, event channel 1
>>>>>> (d9) System requested SeaBIOS
>>>>>> (d9) CPU speed is 2660 MHz
>>>>>> (d9) Relocating guest memory for lowmem MMIO space disabled
>>>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
>>>>>> (d9) PCI-ISA link 0 routed to IRQ5
>>>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
>>>>>> (d9) PCI-ISA link 1 routed to IRQ10
>>>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
>>>>>> (d9) PCI-ISA link 2 routed to IRQ11
>>>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
>>>>>> (d9) PCI-ISA link 3 routed to IRQ5
>>>>>> (d9) pci dev 01:3 INTA->IRQ10
>>>>>> (d9) pci dev 02:0 INTA->IRQ11
>>>>>> (d9) pci dev 03:0 INTA->IRQ5
>>>>>> (d9) pci dev 04:0 INTA->IRQ5
>>>>>> (d9) pci dev 05:0 INTA->IRQ10
>>>>>> (d9) pci dev 06:0 INTA->IRQ11
>>>>>> (d9) pci dev 1d:0 INTA->IRQ10
>>>>>> (d9) pci dev 1d:1 INTB->IRQ11
>>>>>> (d9) pci dev 1d:2 INTC->IRQ5
>>>>>> (d9) pci dev 1d:7 INTD->IRQ5
>>>>>> (d9) No RAM in high memory; setting high_mem resource base to
>>>>>> 100000000
>>>>>> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>>>>> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>>>>> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>>>>> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>>>>> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>>>>> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>>>>> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>>>>> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>>>>> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>>>>> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
>>>>>> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
>>>>>> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>>>>> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
>>>>>> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
>>>>>> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>>>>> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>>>>> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>>>>> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>>>>> (d9) Multiprocessor initialisation:
>>>>>> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ...
>>>>>> done.
>>>>>> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ...
>>>>>> done.
>>>>>> (d9) Testing HVM environment:
>>>>>> (d9)  - REP INSB across page boundaries ... passed
>>>>>> (d9)  - GS base MSRs and SWAPGS ... passed
>>>>>> (d9) Passed 2 of 2 tests
>>>>>> (d9) Writing SMBIOS tables ...
>>>>>> (d9) Loading SeaBIOS ...
>>>>>> (d9) Creating MP tables ...
>>>>>> (d9) Loading ACPI ...
>>>>>> (d9) S3 disabled
>>>>>> (d9) S4 disabled
>>>>>> (d9) vm86 TSS at fc00a100
>>>>>> (d9) BIOS map:
>>>>>> (d9)  10000-100d3: Scratch space
>>>>>> (d9)  c0000-fffff: Main BIOS
>>>>>> (d9) E820 table:
>>>>>> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>>>>> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>>>>> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>>>>> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>>>>> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
>>>>>> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>>>>> (d9) Invoking SeaBIOS ...
>>>>>> (d9) SeaBIOS (version
>>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>>> (d9)
>>>>>> (d9) Found Xen hypervisor signature at 40000000
>>>>>> (d9) Running on QEMU (i440fx)
>>>>>> (d9) xen: copy e820...
>>>>>> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>>>>> (d9) CPU Mhz=2660
>>>>>> (d9) Found 13 PCI devices (max PCI bus is 00)
>>>>>> (d9) Allocated Xen hypercall page at 77fff000
>>>>>> (d9) Detected Xen v4.5.0-rc
>>>>>> (d9) xen: copy BIOS tables...
>>>>>> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>>>>> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>>>>> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
>>>>>> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>>>>> (d9) Using pmtimer, ioport 0xb008
>>>>>> (d9) Scan for VGA option rom
>>>>>> (d9) Running option rom at c000:0003
>>>>>> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
>>>>>> (d9) pmm call arg1=0
>>>>>> (d9) Turning on vga text mode console
>>>>>> (d9) SeaBIOS (version
>>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>>> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
>>>>>> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
>>>>>> (d9) Found 0 lpt ports
>>>>>> (d9) Found 0 serial ports
>>>>>> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>>>>> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>>>>> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
>>>>>> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>>>>> (d9) UHCI init on dev 00:1d.0 (io=c240)
>>>>>> (d9) UHCI init on dev 00:1d.1 (io=c260)
>>>>>> (d9) UHCI init on dev 00:1d.2 (io=c280)
>>>>>> (d9) PS2 keyboard initialized
>>>>>> (d9) All threads complete.
>>>>>> (d9) Scan for option roms
>>>>>> (d9) Running option rom at c980:0003
>>>>>> (d9) pmm call arg1=1
>>>>>> (d9) pmm call arg1=0
>>>>>> (d9) pmm call arg1=1
>>>>>> (d9) pmm call arg1=0
>>>>>> (d9) Searching bootorder for: /pci@i0cf8/*@6
>>>>>> (d9)
>>>>>> (d9) Press F12 for boot menu.
>>>>>> (d9)
>>>>>> (d9) Searching bootorder for: HALT
>>>>>> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba
>>>>>> LCHS=1024/255/63 s=20480000
>>>>>> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
>>>>>> (d9) Returned 258048 bytes of ZoneHigh
>>>>>> (d9) e820 map has 6 items:
>>>>>> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>>>>>> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>>>>>> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>>>>>> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
>>>>>> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
>>>>>> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
>>>>>> (d9) enter handle_19:
>>>>>> (d9)   NULL
>>>>>> (d9) Booting from Hard Disk...
>>>>>> (d9) Booting from 0000:7c00
>>>>>> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
>>>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
>>>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
>>>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
>>>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
>>>>> domU's xl cfg:
>>>>>> name='FEDORA'
>>>>>> builder="hvm"
>>>>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>>> memory=2048
>>>>>> vcpus=2
>>>>>> acpi_s3=0
>>>>>> acpi_s4=0
>>>>>> vif=['bridge=xenbr0']
>>>>>> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
>>>>>> boot='dc'
>>>>>> device_model_version='qemu-xen'
>>>>>> vnc=0
>>>>>> keymap="it"
>>>>>> vga="qxl"
>>>>>> spice=1
>>>>>> spicehost='0.0.0.0'
>>>>>> spiceport=6005
>>>>>> spicedisable_ticketing=1
>>>>>> spicevdagent=1
>>>>>> spice_clipboard_sharing=0
>>>>>> spiceusbredirection=4
>>>>>> soundhw="hda"
>>>>> I tested also with stdvga instead of qxl vga but qemu crash always on
>>>>> fedora boot with same error.
>>>>>
>>>>> If you need more informations/tests tell me and I'll post them.
>>>>>
>>>>> Thanks for any reply and sorry for my bad english.
>>>>>
>>>>
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:58:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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 1Xr9Vv-0007e7-BR; Wed, 19 Nov 2014 17:57:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr9Vu-0007dy-Br
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 17:57:58 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	7E/DB-05632-52ADC645; Wed, 19 Nov 2014 17:57:57 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416419872!12499174!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 19 Nov 2014 17:57:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 17:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194484459"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:45:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr9JW-0007hb-TC;
	Wed, 19 Nov 2014 17:45:10 +0000
Date: Wed, 19 Nov 2014 17:44:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1411191701190.12596@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xensource.com,
	andrii.tseglytskyi@globallogic.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] xen/arm: clear UIE on hypervisor entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UIE being set can cause maintenance interrupts to occur when Xen writes
to one or more LR registers. The effect is a busy loop around the
interrupt handler in Xen
(http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.

Konrad, this fixes an actual bug, at least on OMAP5. It should have no
bad side effects on any other platforms as far as I can tell. It should
go in 4.5.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..df140b9 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -527,8 +529,6 @@ void gic_inject(void)
 
     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
         gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
-    else
-        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
 }
 
 static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 17:58:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 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 1Xr9Vv-0007e7-BR; Wed, 19 Nov 2014 17:57:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr9Vu-0007dy-Br
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 17:57:58 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	7E/DB-05632-52ADC645; Wed, 19 Nov 2014 17:57:57 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416419872!12499174!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 19 Nov 2014 17:57:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 17:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194484459"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:45:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr9JW-0007hb-TC;
	Wed, 19 Nov 2014 17:45:10 +0000
Date: Wed, 19 Nov 2014 17:44:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1411191701190.12596@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xensource.com,
	andrii.tseglytskyi@globallogic.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] xen/arm: clear UIE on hypervisor entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UIE being set can cause maintenance interrupts to occur when Xen writes
to one or more LR registers. The effect is a busy loop around the
interrupt handler in Xen
(http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.

Konrad, this fixes an actual bug, at least on OMAP5. It should have no
bad side effects on any other platforms as far as I can tell. It should
go in 4.5.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..df140b9 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -527,8 +529,6 @@ void gic_inject(void)
 
     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
         gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
-    else
-        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
 }
 
 static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9aJ-0007rz-17; Wed, 19 Nov 2014 18:02:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr9aH-0007rr-Mk
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 18:02:29 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	F0/B2-28296-43BDC645; Wed, 19 Nov 2014 18:02:28 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416420145!12548237!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22795 invoked from network); 19 Nov 2014 18:02:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 18:02:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194487346"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:51:24 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr9PX-0007nW-7W;
	Wed, 19 Nov 2014 17:51:23 +0000
Date: Wed, 19 Nov 2014 17:51:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411191749110.12596@kaball.uk.xensource.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
	<1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4/4] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, David Vrabel wrote:
> On a Xen PV guest the DMA addresses and physical addresses are not 1:1
> (such as Xen PV guests) and the generic dma_get_required_mask() does
> not return the correct mask (since it uses max_pfn).
> 
> Some device drivers (such as mptsas, mpt2sas) use
> dma_get_required_mask() to set the device's DMA mask to allow them to
> use only 32-bit DMA addresses in hardware structures.  This results in
> unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
> impacting performance significantly.
> 
> Provide a get_required_mask op that uses the maximum MFN to calculate
> the DMA mask.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/pci-swiotlb-xen.c |    1 +
>  drivers/xen/swiotlb-xen.c      |   13 +++++++++++++
>  include/xen/swiotlb-xen.h      |    4 ++++
>  3 files changed, 18 insertions(+)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index 0e98e5d..a5d180a 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -31,6 +31,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
>  	.map_page = xen_swiotlb_map_page,
>  	.unmap_page = xen_swiotlb_unmap_page,
>  	.dma_supported = xen_swiotlb_dma_supported,
> +	.get_required_mask = xen_swiotlb_get_required_mask,
>  };
>  
>  /*
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ebd8f21..654587d 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -42,9 +42,11 @@
>  #include <xen/page.h>
>  #include <xen/xen-ops.h>
>  #include <xen/hvc-console.h>
> +#include <xen/interface/memory.h>
>  
>  #include <asm/dma-mapping.h>
>  #include <asm/xen/page-coherent.h>
> +#include <asm/xen/hypercall.h>
>  
>  #include <trace/events/swiotlb.h>
>  /*
> @@ -683,3 +685,14 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
> +
> +u64
> +xen_swiotlb_get_required_mask(struct device *dev)
> +{
> +	unsigned long max_mfn;
> +
> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);

As Jan pointed out, I think you need to change the prototype of
HYPERVISOR_memory_op to return long. Please do consistently across all
relevant archs.


> +	return DMA_BIT_MASK(fls_long(max_mfn - 1) + PAGE_SHIFT);
> +}
> +EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index 8b2eb93..6408888 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -58,4 +58,8 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
>  
>  extern int
>  xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
> +
> +extern u64
> +xen_swiotlb_get_required_mask(struct device *dev);
> +
>  #endif /* __LINUX_SWIOTLB_XEN_H */
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9aJ-0007rz-17; Wed, 19 Nov 2014 18:02:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr9aH-0007rr-Mk
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 18:02:29 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	F0/B2-28296-43BDC645; Wed, 19 Nov 2014 18:02:28 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416420145!12548237!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22795 invoked from network); 19 Nov 2014 18:02:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 18:02:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194487346"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 12:51:24 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr9PX-0007nW-7W;
	Wed, 19 Nov 2014 17:51:23 +0000
Date: Wed, 19 Nov 2014 17:51:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411191749110.12596@kaball.uk.xensource.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
	<1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4/4] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, David Vrabel wrote:
> On a Xen PV guest the DMA addresses and physical addresses are not 1:1
> (such as Xen PV guests) and the generic dma_get_required_mask() does
> not return the correct mask (since it uses max_pfn).
> 
> Some device drivers (such as mptsas, mpt2sas) use
> dma_get_required_mask() to set the device's DMA mask to allow them to
> use only 32-bit DMA addresses in hardware structures.  This results in
> unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
> impacting performance significantly.
> 
> Provide a get_required_mask op that uses the maximum MFN to calculate
> the DMA mask.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/pci-swiotlb-xen.c |    1 +
>  drivers/xen/swiotlb-xen.c      |   13 +++++++++++++
>  include/xen/swiotlb-xen.h      |    4 ++++
>  3 files changed, 18 insertions(+)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index 0e98e5d..a5d180a 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -31,6 +31,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
>  	.map_page = xen_swiotlb_map_page,
>  	.unmap_page = xen_swiotlb_unmap_page,
>  	.dma_supported = xen_swiotlb_dma_supported,
> +	.get_required_mask = xen_swiotlb_get_required_mask,
>  };
>  
>  /*
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ebd8f21..654587d 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -42,9 +42,11 @@
>  #include <xen/page.h>
>  #include <xen/xen-ops.h>
>  #include <xen/hvc-console.h>
> +#include <xen/interface/memory.h>
>  
>  #include <asm/dma-mapping.h>
>  #include <asm/xen/page-coherent.h>
> +#include <asm/xen/hypercall.h>
>  
>  #include <trace/events/swiotlb.h>
>  /*
> @@ -683,3 +685,14 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
> +
> +u64
> +xen_swiotlb_get_required_mask(struct device *dev)
> +{
> +	unsigned long max_mfn;
> +
> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);

As Jan pointed out, I think you need to change the prototype of
HYPERVISOR_memory_op to return long. Please do consistently across all
relevant archs.


> +	return DMA_BIT_MASK(fls_long(max_mfn - 1) + PAGE_SHIFT);
> +}
> +EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index 8b2eb93..6408888 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -58,4 +58,8 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
>  
>  extern int
>  xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
> +
> +extern u64
> +xen_swiotlb_get_required_mask(struct device *dev);
> +
>  #endif /* __LINUX_SWIOTLB_XEN_H */
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:06:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18:06:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9eG-000843-Lr; Wed, 19 Nov 2014 18:06:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr9eE-00083r-H8
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 18:06:35 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	90/79-02698-82CDC645; Wed, 19 Nov 2014 18:06:32 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416420389!8154484!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22733 invoked from network); 19 Nov 2014 18:06:31 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 18:06:31 -0000
Received: from mail-qg0-f42.google.com ([209.85.192.42]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzcJUn2deBZqDh4+DVbhO0i9cXt8Uxx@postini.com;
	Wed, 19 Nov 2014 10:06:31 PST
Received: by mail-qg0-f42.google.com with SMTP id i50so851877qgf.1
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 10:06:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Rkfx6Ju/cyvkmJYlpT2YGxQ7vseRR0l9nTi/pnhXuMo=;
	b=NGuvIklx62tUaL2DQtdVNbsxWF9ghOoOEJn/Cv0iF9GmS06bcSALyFltRoUlOfgKN4
	oA7IoMSmVTIJnqP5ql98++w0Lb4sQVVRr6xQb2klUaXDcLaRQhHd2btfSE+L1DPvIE+8
	gLGtBhYFHAZ7V7Yi05PWbTHFPgTl/ohqrtNC0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Rkfx6Ju/cyvkmJYlpT2YGxQ7vseRR0l9nTi/pnhXuMo=;
	b=GBHZfgddqlEupQDet6gvTffIdhZAUp8eAdpXBduhBDwVkutVpn5p0OL5PKU0osjYOW
	vjDFInSsDDWzMNJ++c3f5T/9ETQAA+Q0dD87zTA8VgJqqS7rb29SnOwz3vaQEZyoODBA
	4JvY/k4HVlzOnPZjtIeCbJKF0rl6oOFJymtVEeMZ6mLEnHDIa9O17C9z9f1e2+FacmHc
	/tI5QZfVS9Bd8hBbf822sAf7OwBVwkxJT6uyGzNuOH2jcxGBOVbtYIl+4TxmHpH3RgCe
	KsSJ30VuNWpIcrW645M/dG8hqPXpipG7YKvr4gJOpVfBNO44di4T5srzobzvOu3/iP+o
	6Rxw==
X-Gm-Message-State: ALoCoQlpDpxb+3aP0viDhWnJ+OOY3nv0RNHn63Utl9Qj2bYlTNJkL6jpQ0+ctgHM3UUQ8rAjMyFBg3vEtk3wdNVvmgvzByZNgsuZVB1Q5WQVQZAjXXOsyhIIZsf1j48dDgQicE2cipMlAG8/2vzSKHFGB4g1V9jEeA==
X-Received: by 10.140.107.163 with SMTP id h32mr48079840qgf.34.1416420388804; 
	Wed, 19 Nov 2014 10:06:28 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.107.163 with SMTP id h32mr48079828qgf.34.1416420388694; 
	Wed, 19 Nov 2014 10:06:28 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 10:06:28 -0800 (PST)
In-Reply-To: <CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
Date: Wed, 19 Nov 2014 20:06:28 +0200
Message-ID: <CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The only ambiguity left - maintenance interrupt handler is not called.
It was requested for specific IRQ number, retrieved from device tree.
But when we trigger GICH_HCR_UIE - we got maintenance interrupt for
spurious number 1023.

Regards,
Andrii

On Wed, Nov 19, 2014 at 7:47 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> On Wed, Nov 19, 2014 at 7:42 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> Hi Stefano,
>>>
>>> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>> > I think that's OK: it looks like that on your board for some reasons
>>> > when UIE is set you get irq 1023 (spurious interrupt) instead of your
>>> > normal maintenance interrupt.
>>>
>>> OK, but I think this should be investigated too. What do you think ?
>>
>> I think it is harmless: my guess is that if we clear UIE before reading
>> GICC_IAR, GICC_IAR returns spurious interrupt instead of maintenance
>> interrupt. But it doesn't really matter to us.
>
> OK. I think catching this will be a good exercise for someone )) But
> out of scope for this issue.
>
>>
>>> >
>>> > But everything should work anyway without issues.
>>> >
>>> > This is the same patch as before but on top of the lastest xen-unstable
>>> > tree. Please confirm if it works.
>>> >
>>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> > index 70d10d6..df140b9 100644
>>> > --- a/xen/arch/arm/gic.c
>>> > +++ b/xen/arch/arm/gic.c
>>> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>>> >      if ( is_idle_vcpu(v) )
>>> >          return;
>>> >
>>> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>>> > +
>>> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>> >
>>> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>> > @@ -527,8 +529,6 @@ void gic_inject(void)
>>> >
>>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
>>> > -    else
>>> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>>> >  }
>>> >
>>>
>>> I confirm - it works fine. Will this be a final fix ?
>>
>> Yep :-)
>> Many thanks for your help on this!
>
> Thank you Stefano. This issue was really critical for us :)
>
> Regards,
> Andrii
>
>>
>>
>>> Regards,
>>> Andrii
>>>
>>> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>>> >
>>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> I got this strange log:
>>> >>
>>> >> (XEN) received maintenance interrupt irq=1023
>>> >>
>>> >> And platform does not hang due to this:
>>> >> +    hcr = GICH[GICH_HCR];
>>> >> +    if ( hcr & GICH_HCR_UIE )
>>> >> +    {
>>> >> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> +        uie_on = 1;
>>> >> +    }
>>> >>
>>> >> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
>>> >> <stefano.stabellini@eu.citrix.com> wrote:
>>> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>>> >> >> <stefano.stabellini@eu.citrix.com> wrote:
>>> >> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>>> >> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
>>> >> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>>> >> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
>>> >> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >> >> >>> Hi Stefano,
>>> >> >> >> >>>
>>> >> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>> >> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>>> >> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >> >> >>> >> Hi Stefano,
>>> >> >> >> >>> >>
>>> >> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>>> >> >> >> >>> >> > >      else
>>> >> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>>> >> >> >> >>> >> > >
>>> >> >> >> >>> >> > >  }
>>> >> >> >> >>> >> >
>>> >> >> >> >>> >> > Yes, exactly
>>> >> >> >> >>> >>
>>> >> >> >> >>> >> I tried, hang still occurs with this change
>>> >> >> >> >>> >
>>> >> >> >> >>> > We need to figure out why during the hang you still have all the LRs
>>> >> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
>>> >> >> >> >>> > them to be cleared.
>>> >> >> >> >>> >
>>> >> >> >> >>>
>>> >> >> >> >>> I see that I have free LRs during maintenance interrupt
>>> >> >> >> >>>
>>> >> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>>> >> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>>> >> >> >> >>> (XEN)    HW_LR[0]=9a015856
>>> >> >> >> >>> (XEN)    HW_LR[1]=0
>>> >> >> >> >>> (XEN)    HW_LR[2]=0
>>> >> >> >> >>> (XEN)    HW_LR[3]=0
>>> >> >> >> >>> (XEN) Inflight irq=86 lr=0
>>> >> >> >> >>> (XEN) Inflight irq=2 lr=255
>>> >> >> >> >>> (XEN) Pending irq=2
>>> >> >> >> >>>
>>> >> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
>>> >> >> >> >>> continuously. Platform continues printing the same log till reboot.
>>> >> >> >> >>
>>> >> >> >> >> Exactly the same log? As in the one above you just pasted?
>>> >> >> >> >> That is very very suspicious.
>>> >> >> >> >
>>> >> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
>>> >> >> >> > correctly.
>>> >> >> >> >
>>> >> >> >> >>
>>> >> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>>> >> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
>>> >> >> >> >> new maintenance interrupt immediately causing an infinite loop.
>>> >> >> >> >>
>>> >> >> >> >
>>> >> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
>>> >> >> >> > debug info it looks like once LRs are overloaded with SGIs -
>>> >> >> >> > maintenance interrupt occurs.
>>> >> >> >> > And then it is not handled properly, and occurs again and again - so
>>> >> >> >> > platform hangs inside its handler.
>>> >> >> >> >
>>> >> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>>> >> >> >> >> hypervisor entry.
>>> >> >> >> >>
>>> >> >> >> >
>>> >> >> >> > Now trying.
>>> >> >> >> >
>>> >> >> >> >>
>>> >> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> >> >> >> >> index 4d2a92d..6ae8dc4 100644
>>> >> >> >> >> --- a/xen/arch/arm/gic.c
>>> >> >> >> >> +++ b/xen/arch/arm/gic.c
>>> >> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>>> >> >> >> >>      if ( is_idle_vcpu(v) )
>>> >> >> >> >>          return;
>>> >> >> >> >>
>>> >> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> >> >> +
>>> >> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>> >> >> >> >>
>>> >> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>> >> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>>> >> >> >> >>
>>> >> >> >> >>      gic_restore_pending_irqs(current);
>>> >> >> >> >>
>>> >> >> >> >> -
>>> >> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> >> >> >> -    else
>>> >> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> >> >> -
>>> >> >> >> >>  }
>>> >> >> >> >>
>>> >> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >> Heh - I don't see hangs with this patch :) But also I see that
>>> >> >> >> maintenance interrupt doesn't occur (and no hang as result)
>>> >> >> >> Stefano - is this expected?
>>> >> >> >
>>> >> >> > No maintenance interrupts at all? That's strange. You should be
>>> >> >> > receiving them when LRs are full and you still have interrupts pending
>>> >> >> > to be added to them.
>>> >> >> >
>>> >> >> > You could add another printk here to see if you should be receiving
>>> >> >> > them:
>>> >> >> >
>>> >> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> >> > +    {
>>> >> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>>> >> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> >> > -    else
>>> >> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> > -
>>> >> >> > +    }
>>> >> >> >  }
>>> >> >> >
>>> >> >>
>>> >> >> Requested properly:
>>> >> >>
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >>
>>> >> >> But does not occur
>>> >> >
>>> >> > OK, let's see what's going on then by printing the irq number of the
>>> >> > maintenance interrupt:
>>> >> >
>>> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> >> > index 4d2a92d..fed3167 100644
>>> >> > --- a/xen/arch/arm/gic.c
>>> >> > +++ b/xen/arch/arm/gic.c
>>> >> > @@ -55,6 +55,7 @@ static struct {
>>> >> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
>>> >> >
>>> >> >  static uint8_t nr_lrs;
>>> >> > +static bool uie_on;
>>> >> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
>>> >> >
>>> >> >  /* The GIC mapping of CPU interfaces does not necessarily match the
>>> >> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
>>> >> >  {
>>> >> >      int i = 0;
>>> >> >      unsigned long flags;
>>> >> > +    unsigned long hcr;
>>> >> >
>>> >> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
>>> >> >       * doesn't write any LR registers for the idle domain they could be
>>> >> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
>>> >> >      if ( is_idle_vcpu(v) )
>>> >> >          return;
>>> >> >
>>> >> > +    hcr = GICH[GICH_HCR];
>>> >> > +    if ( hcr & GICH_HCR_UIE )
>>> >> > +    {
>>> >> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> > +        uie_on = 1;
>>> >> > +    }
>>> >> > +
>>> >> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>> >> >
>>> >> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>> >> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>>> >> >          intack = GICC[GICC_IAR];
>>> >> >          irq = intack & GICC_IA_IRQ;
>>> >> >
>>> >> > +        if ( uie_on )
>>> >> > +        {
>>> >> > +            uie_on = 0;
>>> >> > +            printk("received maintenance interrupt irq=%d\n", irq);
>>> >> > +        }
>>> >> >          if ( likely(irq >= 16 && irq < 1021) )
>>> >> >          {
>>> >> >              local_irq_enable();
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> Andrii Tseglytskyi | Embedded Dev
>>> >> GlobalLogic
>>> >> www.globallogic.com
>>> >>
>>>
>>>
>>>
>>> --
>>>
>>> Andrii Tseglytskyi | Embedded Dev
>>> GlobalLogic
>>> www.globallogic.com
>>>
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:06:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18:06:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9eG-000843-Lr; Wed, 19 Nov 2014 18:06:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1Xr9eE-00083r-H8
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 18:06:35 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	90/79-02698-82CDC645; Wed, 19 Nov 2014 18:06:32 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416420389!8154484!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22733 invoked from network); 19 Nov 2014 18:06:31 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 18:06:31 -0000
Received: from mail-qg0-f42.google.com ([209.85.192.42]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzcJUn2deBZqDh4+DVbhO0i9cXt8Uxx@postini.com;
	Wed, 19 Nov 2014 10:06:31 PST
Received: by mail-qg0-f42.google.com with SMTP id i50so851877qgf.1
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 10:06:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Rkfx6Ju/cyvkmJYlpT2YGxQ7vseRR0l9nTi/pnhXuMo=;
	b=NGuvIklx62tUaL2DQtdVNbsxWF9ghOoOEJn/Cv0iF9GmS06bcSALyFltRoUlOfgKN4
	oA7IoMSmVTIJnqP5ql98++w0Lb4sQVVRr6xQb2klUaXDcLaRQhHd2btfSE+L1DPvIE+8
	gLGtBhYFHAZ7V7Yi05PWbTHFPgTl/ohqrtNC0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Rkfx6Ju/cyvkmJYlpT2YGxQ7vseRR0l9nTi/pnhXuMo=;
	b=GBHZfgddqlEupQDet6gvTffIdhZAUp8eAdpXBduhBDwVkutVpn5p0OL5PKU0osjYOW
	vjDFInSsDDWzMNJ++c3f5T/9ETQAA+Q0dD87zTA8VgJqqS7rb29SnOwz3vaQEZyoODBA
	4JvY/k4HVlzOnPZjtIeCbJKF0rl6oOFJymtVEeMZ6mLEnHDIa9O17C9z9f1e2+FacmHc
	/tI5QZfVS9Bd8hBbf822sAf7OwBVwkxJT6uyGzNuOH2jcxGBOVbtYIl+4TxmHpH3RgCe
	KsSJ30VuNWpIcrW645M/dG8hqPXpipG7YKvr4gJOpVfBNO44di4T5srzobzvOu3/iP+o
	6Rxw==
X-Gm-Message-State: ALoCoQlpDpxb+3aP0viDhWnJ+OOY3nv0RNHn63Utl9Qj2bYlTNJkL6jpQ0+ctgHM3UUQ8rAjMyFBg3vEtk3wdNVvmgvzByZNgsuZVB1Q5WQVQZAjXXOsyhIIZsf1j48dDgQicE2cipMlAG8/2vzSKHFGB4g1V9jEeA==
X-Received: by 10.140.107.163 with SMTP id h32mr48079840qgf.34.1416420388804; 
	Wed, 19 Nov 2014 10:06:28 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.107.163 with SMTP id h32mr48079828qgf.34.1416420388694; 
	Wed, 19 Nov 2014 10:06:28 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 10:06:28 -0800 (PST)
In-Reply-To: <CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191157300.27247@kaball.uk.xensource.com>
	<CAH_mUMM0ia4XkcvJmbstG9qO5pyCw=P2+852H8wzX6ovKiLJ0g@mail.gmail.com>
	<alpine.DEB.2.02.1411191448300.27247@kaball.uk.xensource.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
Date: Wed, 19 Nov 2014 20:06:28 +0200
Message-ID: <CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The only ambiguity left - maintenance interrupt handler is not called.
It was requested for specific IRQ number, retrieved from device tree.
But when we trigger GICH_HCR_UIE - we got maintenance interrupt for
spurious number 1023.

Regards,
Andrii

On Wed, Nov 19, 2014 at 7:47 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@globallogic.com> wrote:
> On Wed, Nov 19, 2014 at 7:42 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> Hi Stefano,
>>>
>>> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>> > I think that's OK: it looks like that on your board for some reasons
>>> > when UIE is set you get irq 1023 (spurious interrupt) instead of your
>>> > normal maintenance interrupt.
>>>
>>> OK, but I think this should be investigated too. What do you think ?
>>
>> I think it is harmless: my guess is that if we clear UIE before reading
>> GICC_IAR, GICC_IAR returns spurious interrupt instead of maintenance
>> interrupt. But it doesn't really matter to us.
>
> OK. I think catching this will be a good exercise for someone )) But
> out of scope for this issue.
>
>>
>>> >
>>> > But everything should work anyway without issues.
>>> >
>>> > This is the same patch as before but on top of the lastest xen-unstable
>>> > tree. Please confirm if it works.
>>> >
>>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> > index 70d10d6..df140b9 100644
>>> > --- a/xen/arch/arm/gic.c
>>> > +++ b/xen/arch/arm/gic.c
>>> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>>> >      if ( is_idle_vcpu(v) )
>>> >          return;
>>> >
>>> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>>> > +
>>> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>> >
>>> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>> > @@ -527,8 +529,6 @@ void gic_inject(void)
>>> >
>>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
>>> > -    else
>>> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>>> >  }
>>> >
>>>
>>> I confirm - it works fine. Will this be a final fix ?
>>
>> Yep :-)
>> Many thanks for your help on this!
>
> Thank you Stefano. This issue was really critical for us :)
>
> Regards,
> Andrii
>
>>
>>
>>> Regards,
>>> Andrii
>>>
>>> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>>> >
>>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> I got this strange log:
>>> >>
>>> >> (XEN) received maintenance interrupt irq=1023
>>> >>
>>> >> And platform does not hang due to this:
>>> >> +    hcr = GICH[GICH_HCR];
>>> >> +    if ( hcr & GICH_HCR_UIE )
>>> >> +    {
>>> >> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> +        uie_on = 1;
>>> >> +    }
>>> >>
>>> >> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
>>> >> <stefano.stabellini@eu.citrix.com> wrote:
>>> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
>>> >> >> <stefano.stabellini@eu.citrix.com> wrote:
>>> >> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>>> >> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
>>> >> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>>> >> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
>>> >> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >> >> >>> Hi Stefano,
>>> >> >> >> >>>
>>> >> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>> >> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
>>> >> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> >> >> >> >>> >> Hi Stefano,
>>> >> >> >> >>> >>
>>> >> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
>>> >> >> >> >>> >> > >      else
>>> >> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
>>> >> >> >> >>> >> > >
>>> >> >> >> >>> >> > >  }
>>> >> >> >> >>> >> >
>>> >> >> >> >>> >> > Yes, exactly
>>> >> >> >> >>> >>
>>> >> >> >> >>> >> I tried, hang still occurs with this change
>>> >> >> >> >>> >
>>> >> >> >> >>> > We need to figure out why during the hang you still have all the LRs
>>> >> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
>>> >> >> >> >>> > them to be cleared.
>>> >> >> >> >>> >
>>> >> >> >> >>>
>>> >> >> >> >>> I see that I have free LRs during maintenance interrupt
>>> >> >> >> >>>
>>> >> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
>>> >> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
>>> >> >> >> >>> (XEN)    HW_LR[0]=9a015856
>>> >> >> >> >>> (XEN)    HW_LR[1]=0
>>> >> >> >> >>> (XEN)    HW_LR[2]=0
>>> >> >> >> >>> (XEN)    HW_LR[3]=0
>>> >> >> >> >>> (XEN) Inflight irq=86 lr=0
>>> >> >> >> >>> (XEN) Inflight irq=2 lr=255
>>> >> >> >> >>> (XEN) Pending irq=2
>>> >> >> >> >>>
>>> >> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
>>> >> >> >> >>> continuously. Platform continues printing the same log till reboot.
>>> >> >> >> >>
>>> >> >> >> >> Exactly the same log? As in the one above you just pasted?
>>> >> >> >> >> That is very very suspicious.
>>> >> >> >> >
>>> >> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
>>> >> >> >> > correctly.
>>> >> >> >> >
>>> >> >> >> >>
>>> >> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
>>> >> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
>>> >> >> >> >> new maintenance interrupt immediately causing an infinite loop.
>>> >> >> >> >>
>>> >> >> >> >
>>> >> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
>>> >> >> >> > debug info it looks like once LRs are overloaded with SGIs -
>>> >> >> >> > maintenance interrupt occurs.
>>> >> >> >> > And then it is not handled properly, and occurs again and again - so
>>> >> >> >> > platform hangs inside its handler.
>>> >> >> >> >
>>> >> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
>>> >> >> >> >> hypervisor entry.
>>> >> >> >> >>
>>> >> >> >> >
>>> >> >> >> > Now trying.
>>> >> >> >> >
>>> >> >> >> >>
>>> >> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> >> >> >> >> index 4d2a92d..6ae8dc4 100644
>>> >> >> >> >> --- a/xen/arch/arm/gic.c
>>> >> >> >> >> +++ b/xen/arch/arm/gic.c
>>> >> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
>>> >> >> >> >>      if ( is_idle_vcpu(v) )
>>> >> >> >> >>          return;
>>> >> >> >> >>
>>> >> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> >> >> +
>>> >> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>> >> >> >> >>
>>> >> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>> >> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
>>> >> >> >> >>
>>> >> >> >> >>      gic_restore_pending_irqs(current);
>>> >> >> >> >>
>>> >> >> >> >> -
>>> >> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> >> >> >> -    else
>>> >> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> >> >> -
>>> >> >> >> >>  }
>>> >> >> >> >>
>>> >> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >> Heh - I don't see hangs with this patch :) But also I see that
>>> >> >> >> maintenance interrupt doesn't occur (and no hang as result)
>>> >> >> >> Stefano - is this expected?
>>> >> >> >
>>> >> >> > No maintenance interrupts at all? That's strange. You should be
>>> >> >> > receiving them when LRs are full and you still have interrupts pending
>>> >> >> > to be added to them.
>>> >> >> >
>>> >> >> > You could add another printk here to see if you should be receiving
>>> >> >> > them:
>>> >> >> >
>>> >> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>>> >> >> > +    {
>>> >> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
>>> >> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
>>> >> >> > -    else
>>> >> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> >> > -
>>> >> >> > +    }
>>> >> >> >  }
>>> >> >> >
>>> >> >>
>>> >> >> Requested properly:
>>> >> >>
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
>>> >> >>
>>> >> >> But does not occur
>>> >> >
>>> >> > OK, let's see what's going on then by printing the irq number of the
>>> >> > maintenance interrupt:
>>> >> >
>>> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> >> > index 4d2a92d..fed3167 100644
>>> >> > --- a/xen/arch/arm/gic.c
>>> >> > +++ b/xen/arch/arm/gic.c
>>> >> > @@ -55,6 +55,7 @@ static struct {
>>> >> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
>>> >> >
>>> >> >  static uint8_t nr_lrs;
>>> >> > +static bool uie_on;
>>> >> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
>>> >> >
>>> >> >  /* The GIC mapping of CPU interfaces does not necessarily match the
>>> >> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
>>> >> >  {
>>> >> >      int i = 0;
>>> >> >      unsigned long flags;
>>> >> > +    unsigned long hcr;
>>> >> >
>>> >> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
>>> >> >       * doesn't write any LR registers for the idle domain they could be
>>> >> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
>>> >> >      if ( is_idle_vcpu(v) )
>>> >> >          return;
>>> >> >
>>> >> > +    hcr = GICH[GICH_HCR];
>>> >> > +    if ( hcr & GICH_HCR_UIE )
>>> >> > +    {
>>> >> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
>>> >> > +        uie_on = 1;
>>> >> > +    }
>>> >> > +
>>> >> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>> >> >
>>> >> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
>>> >> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>>> >> >          intack = GICC[GICC_IAR];
>>> >> >          irq = intack & GICC_IA_IRQ;
>>> >> >
>>> >> > +        if ( uie_on )
>>> >> > +        {
>>> >> > +            uie_on = 0;
>>> >> > +            printk("received maintenance interrupt irq=%d\n", irq);
>>> >> > +        }
>>> >> >          if ( likely(irq >= 16 && irq < 1021) )
>>> >> >          {
>>> >> >              local_irq_enable();
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> Andrii Tseglytskyi | Embedded Dev
>>> >> GlobalLogic
>>> >> www.globallogic.com
>>> >>
>>>
>>>
>>>
>>> --
>>>
>>> Andrii Tseglytskyi | Embedded Dev
>>> GlobalLogic
>>> www.globallogic.com
>>>
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:19:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18: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 1Xr9qr-0008LZ-21; Wed, 19 Nov 2014 18:19:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr9qq-0008LU-EJ
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 18:19:36 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0A/4E-25276-73FDC645; Wed, 19 Nov 2014 18:19:35 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416421173!13987281!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27486 invoked from network); 19 Nov 2014 18:19:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 18:19:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192983721"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 13:18:50 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr9lo-00089P-Tz;
	Wed, 19 Nov 2014 18:14:24 +0000
Date: Wed, 19 Nov 2014 18:14:04 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

That's right, the maintenance interrupt handler is not called, but it
doesn't do anything so we are fine. The important thing is that an
interrupt is sent and git_clear_lrs gets called on hypervisor entry.

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> The only ambiguity left - maintenance interrupt handler is not called.
> It was requested for specific IRQ number, retrieved from device tree.
> But when we trigger GICH_HCR_UIE - we got maintenance interrupt for
> spurious number 1023.
> 
> Regards,
> Andrii
> 
> On Wed, Nov 19, 2014 at 7:47 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > On Wed, Nov 19, 2014 at 7:42 PM, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> Hi Stefano,
> >>>
> >>> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> > I think that's OK: it looks like that on your board for some reasons
> >>> > when UIE is set you get irq 1023 (spurious interrupt) instead of your
> >>> > normal maintenance interrupt.
> >>>
> >>> OK, but I think this should be investigated too. What do you think ?
> >>
> >> I think it is harmless: my guess is that if we clear UIE before reading
> >> GICC_IAR, GICC_IAR returns spurious interrupt instead of maintenance
> >> interrupt. But it doesn't really matter to us.
> >
> > OK. I think catching this will be a good exercise for someone )) But
> > out of scope for this issue.
> >
> >>
> >>> >
> >>> > But everything should work anyway without issues.
> >>> >
> >>> > This is the same patch as before but on top of the lastest xen-unstable
> >>> > tree. Please confirm if it works.
> >>> >
> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> > index 70d10d6..df140b9 100644
> >>> > --- a/xen/arch/arm/gic.c
> >>> > +++ b/xen/arch/arm/gic.c
> >>> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
> >>> >      if ( is_idle_vcpu(v) )
> >>> >          return;
> >>> >
> >>> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >>> > +
> >>> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>> >
> >>> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >>> > @@ -527,8 +529,6 @@ void gic_inject(void)
> >>> >
> >>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> >>> > -    else
> >>> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >>> >  }
> >>> >
> >>>
> >>> I confirm - it works fine. Will this be a final fix ?
> >>
> >> Yep :-)
> >> Many thanks for your help on this!
> >
> > Thank you Stefano. This issue was really critical for us :)
> >
> > Regards,
> > Andrii
> >
> >>
> >>
> >>> Regards,
> >>> Andrii
> >>>
> >>> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> >>> >
> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> I got this strange log:
> >>> >>
> >>> >> (XEN) received maintenance interrupt irq=1023
> >>> >>
> >>> >> And platform does not hang due to this:
> >>> >> +    hcr = GICH[GICH_HCR];
> >>> >> +    if ( hcr & GICH_HCR_UIE )
> >>> >> +    {
> >>> >> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> +        uie_on = 1;
> >>> >> +    }
> >>> >>
> >>> >> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
> >>> >> <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> >>> >> >> <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >>> >> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >>> >> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >>> >> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >> >> >>> Hi Stefano,
> >>> >> >> >> >>>
> >>> >> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >>> >> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >> >> >>> >> Hi Stefano,
> >>> >> >> >> >>> >>
> >>> >> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >>> >> >> >> >>> >> > >      else
> >>> >> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >>> >> >> >> >>> >> > >
> >>> >> >> >> >>> >> > >  }
> >>> >> >> >> >>> >> >
> >>> >> >> >> >>> >> > Yes, exactly
> >>> >> >> >> >>> >>
> >>> >> >> >> >>> >> I tried, hang still occurs with this change
> >>> >> >> >> >>> >
> >>> >> >> >> >>> > We need to figure out why during the hang you still have all the LRs
> >>> >> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
> >>> >> >> >> >>> > them to be cleared.
> >>> >> >> >> >>> >
> >>> >> >> >> >>>
> >>> >> >> >> >>> I see that I have free LRs during maintenance interrupt
> >>> >> >> >> >>>
> >>> >> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >>> >> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >>> >> >> >> >>> (XEN)    HW_LR[0]=9a015856
> >>> >> >> >> >>> (XEN)    HW_LR[1]=0
> >>> >> >> >> >>> (XEN)    HW_LR[2]=0
> >>> >> >> >> >>> (XEN)    HW_LR[3]=0
> >>> >> >> >> >>> (XEN) Inflight irq=86 lr=0
> >>> >> >> >> >>> (XEN) Inflight irq=2 lr=255
> >>> >> >> >> >>> (XEN) Pending irq=2
> >>> >> >> >> >>>
> >>> >> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
> >>> >> >> >> >>> continuously. Platform continues printing the same log till reboot.
> >>> >> >> >> >>
> >>> >> >> >> >> Exactly the same log? As in the one above you just pasted?
> >>> >> >> >> >> That is very very suspicious.
> >>> >> >> >> >
> >>> >> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
> >>> >> >> >> > correctly.
> >>> >> >> >> >
> >>> >> >> >> >>
> >>> >> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >>> >> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >>> >> >> >> >> new maintenance interrupt immediately causing an infinite loop.
> >>> >> >> >> >>
> >>> >> >> >> >
> >>> >> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
> >>> >> >> >> > debug info it looks like once LRs are overloaded with SGIs -
> >>> >> >> >> > maintenance interrupt occurs.
> >>> >> >> >> > And then it is not handled properly, and occurs again and again - so
> >>> >> >> >> > platform hangs inside its handler.
> >>> >> >> >> >
> >>> >> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >>> >> >> >> >> hypervisor entry.
> >>> >> >> >> >>
> >>> >> >> >> >
> >>> >> >> >> > Now trying.
> >>> >> >> >> >
> >>> >> >> >> >>
> >>> >> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> >> >> >> >> index 4d2a92d..6ae8dc4 100644
> >>> >> >> >> >> --- a/xen/arch/arm/gic.c
> >>> >> >> >> >> +++ b/xen/arch/arm/gic.c
> >>> >> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >>> >> >> >> >>      if ( is_idle_vcpu(v) )
> >>> >> >> >> >>          return;
> >>> >> >> >> >>
> >>> >> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> >> >> +
> >>> >> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>> >> >> >> >>
> >>> >> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >>> >> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >>> >> >> >> >>
> >>> >> >> >> >>      gic_restore_pending_irqs(current);
> >>> >> >> >> >>
> >>> >> >> >> >> -
> >>> >> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> >> >> >> -    else
> >>> >> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> >> >> -
> >>> >> >> >> >>  }
> >>> >> >> >> >>
> >>> >> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >>> >> >> >> >
> >>> >> >> >>
> >>> >> >> >> Heh - I don't see hangs with this patch :) But also I see that
> >>> >> >> >> maintenance interrupt doesn't occur (and no hang as result)
> >>> >> >> >> Stefano - is this expected?
> >>> >> >> >
> >>> >> >> > No maintenance interrupts at all? That's strange. You should be
> >>> >> >> > receiving them when LRs are full and you still have interrupts pending
> >>> >> >> > to be added to them.
> >>> >> >> >
> >>> >> >> > You could add another printk here to see if you should be receiving
> >>> >> >> > them:
> >>> >> >> >
> >>> >> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> >> > +    {
> >>> >> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >>> >> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> >> > -    else
> >>> >> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> > -
> >>> >> >> > +    }
> >>> >> >> >  }
> >>> >> >> >
> >>> >> >>
> >>> >> >> Requested properly:
> >>> >> >>
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >>
> >>> >> >> But does not occur
> >>> >> >
> >>> >> > OK, let's see what's going on then by printing the irq number of the
> >>> >> > maintenance interrupt:
> >>> >> >
> >>> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> >> > index 4d2a92d..fed3167 100644
> >>> >> > --- a/xen/arch/arm/gic.c
> >>> >> > +++ b/xen/arch/arm/gic.c
> >>> >> > @@ -55,6 +55,7 @@ static struct {
> >>> >> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
> >>> >> >
> >>> >> >  static uint8_t nr_lrs;
> >>> >> > +static bool uie_on;
> >>> >> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
> >>> >> >
> >>> >> >  /* The GIC mapping of CPU interfaces does not necessarily match the
> >>> >> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
> >>> >> >  {
> >>> >> >      int i = 0;
> >>> >> >      unsigned long flags;
> >>> >> > +    unsigned long hcr;
> >>> >> >
> >>> >> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
> >>> >> >       * doesn't write any LR registers for the idle domain they could be
> >>> >> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
> >>> >> >      if ( is_idle_vcpu(v) )
> >>> >> >          return;
> >>> >> >
> >>> >> > +    hcr = GICH[GICH_HCR];
> >>> >> > +    if ( hcr & GICH_HCR_UIE )
> >>> >> > +    {
> >>> >> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> > +        uie_on = 1;
> >>> >> > +    }
> >>> >> > +
> >>> >> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>> >> >
> >>> >> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >>> >> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
> >>> >> >          intack = GICC[GICC_IAR];
> >>> >> >          irq = intack & GICC_IA_IRQ;
> >>> >> >
> >>> >> > +        if ( uie_on )
> >>> >> > +        {
> >>> >> > +            uie_on = 0;
> >>> >> > +            printk("received maintenance interrupt irq=%d\n", irq);
> >>> >> > +        }
> >>> >> >          if ( likely(irq >= 16 && irq < 1021) )
> >>> >> >          {
> >>> >> >              local_irq_enable();
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >>
> >>> >> Andrii Tseglytskyi | Embedded Dev
> >>> >> GlobalLogic
> >>> >> www.globallogic.com
> >>> >>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Andrii Tseglytskyi | Embedded Dev
> >>> GlobalLogic
> >>> www.globallogic.com
> >>>
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:19:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18: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 1Xr9qr-0008LZ-21; Wed, 19 Nov 2014 18:19:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr9qq-0008LU-EJ
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 18:19:36 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0A/4E-25276-73FDC645; Wed, 19 Nov 2014 18:19:35 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416421173!13987281!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27486 invoked from network); 19 Nov 2014 18:19:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 18:19:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192983721"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 13:18:50 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr9lo-00089P-Tz;
	Wed, 19 Nov 2014 18:14:24 +0000
Date: Wed, 19 Nov 2014 18:14:04 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMNP1UwcDvK8teQ=VLsA2hfBa+xsFP6dqau5HHViDOJQag@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

That's right, the maintenance interrupt handler is not called, but it
doesn't do anything so we are fine. The important thing is that an
interrupt is sent and git_clear_lrs gets called on hypervisor entry.

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> The only ambiguity left - maintenance interrupt handler is not called.
> It was requested for specific IRQ number, retrieved from device tree.
> But when we trigger GICH_HCR_UIE - we got maintenance interrupt for
> spurious number 1023.
> 
> Regards,
> Andrii
> 
> On Wed, Nov 19, 2014 at 7:47 PM, Andrii Tseglytskyi
> <andrii.tseglytskyi@globallogic.com> wrote:
> > On Wed, Nov 19, 2014 at 7:42 PM, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> Hi Stefano,
> >>>
> >>> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> > I think that's OK: it looks like that on your board for some reasons
> >>> > when UIE is set you get irq 1023 (spurious interrupt) instead of your
> >>> > normal maintenance interrupt.
> >>>
> >>> OK, but I think this should be investigated too. What do you think ?
> >>
> >> I think it is harmless: my guess is that if we clear UIE before reading
> >> GICC_IAR, GICC_IAR returns spurious interrupt instead of maintenance
> >> interrupt. But it doesn't really matter to us.
> >
> > OK. I think catching this will be a good exercise for someone )) But
> > out of scope for this issue.
> >
> >>
> >>> >
> >>> > But everything should work anyway without issues.
> >>> >
> >>> > This is the same patch as before but on top of the lastest xen-unstable
> >>> > tree. Please confirm if it works.
> >>> >
> >>> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> > index 70d10d6..df140b9 100644
> >>> > --- a/xen/arch/arm/gic.c
> >>> > +++ b/xen/arch/arm/gic.c
> >>> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
> >>> >      if ( is_idle_vcpu(v) )
> >>> >          return;
> >>> >
> >>> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >>> > +
> >>> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>> >
> >>> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >>> > @@ -527,8 +529,6 @@ void gic_inject(void)
> >>> >
> >>> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> >>> > -    else
> >>> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >>> >  }
> >>> >
> >>>
> >>> I confirm - it works fine. Will this be a final fix ?
> >>
> >> Yep :-)
> >> Many thanks for your help on this!
> >
> > Thank you Stefano. This issue was really critical for us :)
> >
> > Regards,
> > Andrii
> >
> >>
> >>
> >>> Regards,
> >>> Andrii
> >>>
> >>> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> >>> >
> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> I got this strange log:
> >>> >>
> >>> >> (XEN) received maintenance interrupt irq=1023
> >>> >>
> >>> >> And platform does not hang due to this:
> >>> >> +    hcr = GICH[GICH_HCR];
> >>> >> +    if ( hcr & GICH_HCR_UIE )
> >>> >> +    {
> >>> >> +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> +        uie_on = 1;
> >>> >> +    }
> >>> >>
> >>> >> On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
> >>> >> <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> >>> >> >> <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >>> >> >> >> <andrii.tseglytskyi@globallogic.com> wrote:
> >>> >> >> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >>> >> >> >> > <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> >> >> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >> >> >>> Hi Stefano,
> >>> >> >> >> >>>
> >>> >> >> >> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> >>> >> >> >> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>> >> >> >> >>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> >> >> >> >>> >> Hi Stefano,
> >>> >> >> >> >>> >>
> >>> >> >> >> >>> >> > >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> >> >> >>> >> > > -        GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> >> >> >>> >> > > +        GICH[GICH_HCR] |= GICH_HCR_NPIE;
> >>> >> >> >> >>> >> > >      else
> >>> >> >> >> >>> >> > > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> >> >>> >> > > +        GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >>> >> >> >> >>> >> > >
> >>> >> >> >> >>> >> > >  }
> >>> >> >> >> >>> >> >
> >>> >> >> >> >>> >> > Yes, exactly
> >>> >> >> >> >>> >>
> >>> >> >> >> >>> >> I tried, hang still occurs with this change
> >>> >> >> >> >>> >
> >>> >> >> >> >>> > We need to figure out why during the hang you still have all the LRs
> >>> >> >> >> >>> > busy even if you are getting maintenance interrupts that should cause
> >>> >> >> >> >>> > them to be cleared.
> >>> >> >> >> >>> >
> >>> >> >> >> >>>
> >>> >> >> >> >>> I see that I have free LRs during maintenance interrupt
> >>> >> >> >> >>>
> >>> >> >> >> >>> (XEN) gic.c:871:d0v0 maintenance interrupt
> >>> >> >> >> >>> (XEN) GICH_LRs (vcpu 0) mask=0
> >>> >> >> >> >>> (XEN)    HW_LR[0]=9a015856
> >>> >> >> >> >>> (XEN)    HW_LR[1]=0
> >>> >> >> >> >>> (XEN)    HW_LR[2]=0
> >>> >> >> >> >>> (XEN)    HW_LR[3]=0
> >>> >> >> >> >>> (XEN) Inflight irq=86 lr=0
> >>> >> >> >> >>> (XEN) Inflight irq=2 lr=255
> >>> >> >> >> >>> (XEN) Pending irq=2
> >>> >> >> >> >>>
> >>> >> >> >> >>> But I see that after I got hang - maintenance interrupts are generated
> >>> >> >> >> >>> continuously. Platform continues printing the same log till reboot.
> >>> >> >> >> >>
> >>> >> >> >> >> Exactly the same log? As in the one above you just pasted?
> >>> >> >> >> >> That is very very suspicious.
> >>> >> >> >> >
> >>> >> >> >> > Yes exactly the same log. And looks like it means that LRs are flushed
> >>> >> >> >> > correctly.
> >>> >> >> >> >
> >>> >> >> >> >>
> >>> >> >> >> >> I am thinking that we are not handling GICH_HCR_UIE correctly and
> >>> >> >> >> >> something we do in Xen, maybe writing to an LR register, might trigger a
> >>> >> >> >> >> new maintenance interrupt immediately causing an infinite loop.
> >>> >> >> >> >>
> >>> >> >> >> >
> >>> >> >> >> > Yes, this is what I'm thinking about. Taking in account all collected
> >>> >> >> >> > debug info it looks like once LRs are overloaded with SGIs -
> >>> >> >> >> > maintenance interrupt occurs.
> >>> >> >> >> > And then it is not handled properly, and occurs again and again - so
> >>> >> >> >> > platform hangs inside its handler.
> >>> >> >> >> >
> >>> >> >> >> >> Could you please try this patch? It disable GICH_HCR_UIE immediately on
> >>> >> >> >> >> hypervisor entry.
> >>> >> >> >> >>
> >>> >> >> >> >
> >>> >> >> >> > Now trying.
> >>> >> >> >> >
> >>> >> >> >> >>
> >>> >> >> >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> >> >> >> >> index 4d2a92d..6ae8dc4 100644
> >>> >> >> >> >> --- a/xen/arch/arm/gic.c
> >>> >> >> >> >> +++ b/xen/arch/arm/gic.c
> >>> >> >> >> >> @@ -701,6 +701,8 @@ void gic_clear_lrs(struct vcpu *v)
> >>> >> >> >> >>      if ( is_idle_vcpu(v) )
> >>> >> >> >> >>          return;
> >>> >> >> >> >>
> >>> >> >> >> >> +    GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> >> >> +
> >>> >> >> >> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>> >> >> >> >>
> >>> >> >> >> >>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >>> >> >> >> >> @@ -821,12 +823,8 @@ void gic_inject(void)
> >>> >> >> >> >>
> >>> >> >> >> >>      gic_restore_pending_irqs(current);
> >>> >> >> >> >>
> >>> >> >> >> >> -
> >>> >> >> >> >>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> >> >> >>          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> >> >> >> -    else
> >>> >> >> >> >> -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> >> >> -
> >>> >> >> >> >>  }
> >>> >> >> >> >>
> >>> >> >> >> >>  static void do_sgi(struct cpu_user_regs *regs, int othercpu, enum gic_sgi sgi)
> >>> >> >> >> >
> >>> >> >> >>
> >>> >> >> >> Heh - I don't see hangs with this patch :) But also I see that
> >>> >> >> >> maintenance interrupt doesn't occur (and no hang as result)
> >>> >> >> >> Stefano - is this expected?
> >>> >> >> >
> >>> >> >> > No maintenance interrupts at all? That's strange. You should be
> >>> >> >> > receiving them when LRs are full and you still have interrupts pending
> >>> >> >> > to be added to them.
> >>> >> >> >
> >>> >> >> > You could add another printk here to see if you should be receiving
> >>> >> >> > them:
> >>> >> >> >
> >>> >> >> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >>> >> >> > +    {
> >>> >> >> > +        gdprintk(XENLOG_DEBUG, "requesting maintenance interrupt\n");
> >>> >> >> >          GICH[GICH_HCR] |= GICH_HCR_UIE;
> >>> >> >> > -    else
> >>> >> >> > -        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> >> > -
> >>> >> >> > +    }
> >>> >> >> >  }
> >>> >> >> >
> >>> >> >>
> >>> >> >> Requested properly:
> >>> >> >>
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >> (XEN) gic.c:756:d0v0 requesting maintenance interrupt
> >>> >> >>
> >>> >> >> But does not occur
> >>> >> >
> >>> >> > OK, let's see what's going on then by printing the irq number of the
> >>> >> > maintenance interrupt:
> >>> >> >
> >>> >> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>> >> > index 4d2a92d..fed3167 100644
> >>> >> > --- a/xen/arch/arm/gic.c
> >>> >> > +++ b/xen/arch/arm/gic.c
> >>> >> > @@ -55,6 +55,7 @@ static struct {
> >>> >> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
> >>> >> >
> >>> >> >  static uint8_t nr_lrs;
> >>> >> > +static bool uie_on;
> >>> >> >  #define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
> >>> >> >
> >>> >> >  /* The GIC mapping of CPU interfaces does not necessarily match the
> >>> >> > @@ -694,6 +695,7 @@ void gic_clear_lrs(struct vcpu *v)
> >>> >> >  {
> >>> >> >      int i = 0;
> >>> >> >      unsigned long flags;
> >>> >> > +    unsigned long hcr;
> >>> >> >
> >>> >> >      /* The idle domain has no LRs to be cleared. Since gic_restore_state
> >>> >> >       * doesn't write any LR registers for the idle domain they could be
> >>> >> > @@ -701,6 +703,13 @@ void gic_clear_lrs(struct vcpu *v)
> >>> >> >      if ( is_idle_vcpu(v) )
> >>> >> >          return;
> >>> >> >
> >>> >> > +    hcr = GICH[GICH_HCR];
> >>> >> > +    if ( hcr & GICH_HCR_UIE )
> >>> >> > +    {
> >>> >> > +        GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >>> >> > +        uie_on = 1;
> >>> >> > +    }
> >>> >> > +
> >>> >> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>> >> >
> >>> >> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> >>> >> > @@ -865,6 +873,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
> >>> >> >          intack = GICC[GICC_IAR];
> >>> >> >          irq = intack & GICC_IA_IRQ;
> >>> >> >
> >>> >> > +        if ( uie_on )
> >>> >> > +        {
> >>> >> > +            uie_on = 0;
> >>> >> > +            printk("received maintenance interrupt irq=%d\n", irq);
> >>> >> > +        }
> >>> >> >          if ( likely(irq >= 16 && irq < 1021) )
> >>> >> >          {
> >>> >> >              local_irq_enable();
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >>
> >>> >> Andrii Tseglytskyi | Embedded Dev
> >>> >> GlobalLogic
> >>> >> www.globallogic.com
> >>> >>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Andrii Tseglytskyi | Embedded Dev
> >>> GlobalLogic
> >>> www.globallogic.com
> >>>
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> 
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:23:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18:23:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9ug-00006p-Ss; Wed, 19 Nov 2014 18:23:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr9ue-00006i-Su
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 18:23:33 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	20/4D-02957-420EC645; Wed, 19 Nov 2014 18:23:32 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416421409!13580786!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32007 invoked from network); 19 Nov 2014 18:23:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 18:23:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194500512"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 13:18:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr9po-0008D6-Au;
	Wed, 19 Nov 2014 18:18:32 +0000
Date: Wed, 19 Nov 2014 18:18:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Don Slutz <dslutz@verizon.com>
In-Reply-To: <546CD906.40903@terremark.com>
Message-ID: <alpine.DEB.2.02.1411191817240.12596@kaball.uk.xensource.com>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
	<546CAFB1.8070904@terremark.com> <546CBA8B.2090903@m2r.biz>
	<alpine.DEB.2.02.1411191551120.12596@kaball.uk.xensource.com>
	<546CD906.40903@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>,
	anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org
Subject: Re: [Xen-devel] [Qemu-devel] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Don Slutz wrote:
> I have posted the patch:
> 
> Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
> for xenfv machine
> Date: Wed, 19 Nov 2014 12:30:57 -0500
> Message-ID: <1416418257-10166-1-git-send-email-dslutz@verizon.com>
> 
> 
> Which fixes QEMU 2.2 for xenfv.  However if you configure xen_platform_pci=0
> you will still
> have this issue.  The good news is that xen-4.5 currently does not have QEMU
> 2.2 and so does
> not have this issue.
> 
> Only people (groups like spice?) that want QEMU 2.2.0 with xen 4.5.0 (or older
> xen versions)
> will hit this.
> 
> I have changes to xen 4.6 which will fix the xen_platform_pci=0 case also.
> 
> In order to get xen 4.5 to fully work with QEMU 2.2.0 (both in hard freeze)
> 
> the 1st patch from "Dr. David Alan Gilbert <dgilbert@redhat.com>"
> would need to be applied to xen's qemu 2.0.2 (+ changes) so that
> vmport=off can be added to --machine.
> 
> And a patch (yet to be written, subset of changes I have pending for 4.6)
> that adds vmport=off to QEMU args for --machine (it can be done in all cases).

What happens if you pass vmport=off via --machine, without David Alan
Gilbert's patch in QEMU?


>     -Don Slutz
> 
> 
> 
> On 11/19/14 10:52, Stefano Stabellini wrote:
> > On Wed, 19 Nov 2014, Fabio Fantoni wrote:
> > > Il 19/11/2014 15:56, Don Slutz ha scritto:
> > > > I think I know what is happening here.  But you are pointing at the
> > > > wrong
> > > > change.
> > > > 
> > > > commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
> > > > 
> > > > Is what I am guessing at this time is the issue.  I think that
> > > > xen_enabled()
> > > > is
> > > > returning false in pc_machine_initfn.  Where as in pc_init1 is is
> > > > returning
> > > > true.
> > > > 
> > > > I am thinking that:
> > > > 
> > > > 
> > > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > > > index 7bb97a4..3268c29 100644
> > > > --- a/hw/i386/pc_piix.c
> > > > +++ b/hw/i386/pc_piix.c
> > > > @@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
> > > >       .desc = "Xen Fully-virtualized PC",
> > > >       .init = pc_xen_hvm_init,
> > > >       .max_cpus = HVM_MAX_VCPUS,
> > > > -    .default_machine_opts = "accel=xen",
> > > > +    .default_machine_opts = "accel=xen,vmport=off",
> > > >       .hot_add_cpu = pc_hot_add_cpu,
> > > >   };
> > > >   #endif
> > > > 
> > > > Will fix your issue. I have not tested this yet.
> > > Tested now and it solves regression of linux hvm domUs with qemu 2.2,
> > > thanks.
> > > I think that I'm not the only with this regression and that this patch (or
> > > a
> > > fix to the cause in vmport) should be applied before qemu 2.2 final.
> > Don,
> > please submit a proper patch with a Signed-off-by.
> > 
> > Thanks!
> > 
> > - Stefano
> > 
> > > >      -Don Slutz
> > > > 
> > > > 
> > > > On 11/19/14 09:04, Fabio Fantoni wrote:
> > > > > Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
> > > > > > dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid
> > > > > > leaf
> > > > > > with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches,
> > > > > > and
> > > > > > qemu 2.2 from spice git (spice/next commit
> > > > > > e779fa0a715530311e6f59fc8adb0f6eca914a89):
> > > > > > https://github.com/Fantu/Xen/commits/rebase/m2r-staging
> > > > > I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the
> > > > > full
> > > > > backtrace of latest test:
> > > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > > 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
> > > > > > addr=0,
> > > > > >      size=4) at
> > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > > > 73          eax = env->regs[R_EAX];
> > > > > > (gdb) bt full
> > > > > > #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
> > > > > > addr=0,
> > > > > >      size=4) at
> > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > > >          s = 0x5555564443a0
> > > > > >          cs = 0x0
> > > > > >          cpu = 0x0
> > > > > >          __func__ = "vmport_ioport_read"
> > > > > >          env = 0x8250
> > > > > >          command = 0 '\000'
> > > > > >          eax = 0
> > > > > > #1  0x0000555555655fc4 in memory_region_read_accessor
> > > > > > (mr=0x555556444428,
> > > > > >      addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
> > > > > >          tmp = 0
> > > > > > #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
> > > > > >      value=0x7fffffffd8d0, size=4, access_size_min=4,
> > > > > > access_size_max=4,
> > > > > >      access=0x555555655f62 <memory_region_read_accessor>,
> > > > > > mr=0x555556444428)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
> > > > > >          access_mask = 4294967295
> > > > > >          access_size = 4
> > > > > >          i = 0
> > > > > > #3  0x00005555556590e9 in memory_region_dispatch_read1
> > > > > > (mr=0x555556444428,
> > > > > >      addr=0, size=4) at
> > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
> > > > > >          data = 0
> > > > > > #4  0x00005555556591b1 in memory_region_dispatch_read
> > > > > > (mr=0x555556444428,
> > > > > >      addr=0, pval=0x7fffffffd9a8, size=4)
> > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> > > > > > No locals.
> > > > > > #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
> > > > > >      pval=0x7fffffffd9a8, size=4)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> > > > > > No locals.
> > > > > > #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920,
> > > > > > addr=22104,
> > > > > >      buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
> > > > > >          l = 4
> > > > > >          ptr = 0x555555a92d87 "%s/%d:\n"
> > > > > >          val = 7852232130387826944
> > > > > >          addr1 = 0
> > > > > >          mr = 0x555556444428
> > > > > >          error = false
> > > > > > #7  0x000055555560a38f in address_space_read (as=0x555555eaf920,
> > > > > > addr=22104,
> > > > > >      buf=0x7fffffffda50 "\377\377\377\377", len=4)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
> > > > > > No locals.
> > > > > > #8  0x000055555564fd4b in cpu_inl (addr=22104)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
> > > > > >          buf = "\377\377\377\377"
> > > > > >          val = 21845
> > > > > > #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > > No locals.
> > > > > > #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
> > > > > >          i = 1
> > > > > > #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
> > > > > >      req=0x7ffff7ff3020) at
> > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> > > > > > No locals.
> > > > > > #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
> > > > > >          state = 0x5555563c2510
> > > > > >          req = 0x7ffff7ff3020
> > > > > > #13 0x000055555596e240 in qemu_iohandler_poll
> > > > > > (pollfds=0x555556389a30,
> > > > > > ret=1)
> > > > > >      at iohandler.c:143
> > > > > >          revents = 1
> > > > > >          pioh = 0x5555563f7610
> > > > > >          ioh = 0x555556450a40
> > > > > > #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at
> > > > > > main-loop.c:495
> > > > > >          ret = 1
> > > > > >          timeout = 4294967295
> > > > > >          timeout_ns = 3965432
> > > > > > #15 0x0000555555756d3f in main_loop () at vl.c:1882
> > > > > >          nonblocking = false
> > > > > >          last_io = 0
> > > > > > #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
> > > > > >      envp=0x7fffffffe240) at vl.c:4400
> > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > >          i = 128
> > > > > >          snapshot = 0
> > > > > >          linux_boot = 0
> > > > > >          initrd_filename = 0x0
> > > > > >          kernel_filename = 0x0
> > > > > >          kernel_cmdline = 0x555555a48f86 ""
> > > > > >          boot_order = 0x555556387460 "dc"
> > > > > >          ds = 0x5555564b2040
> > > > > >          cyls = 0
> > > > > >          heads = 0
> > > > > >          secs = 0
> > > > > >          translation = 0
> > > > > >          hda_opts = 0x0
> > > > > >          opts = 0x5555563873b0
> > > > > >          machine_opts = 0x555556389010
> > > > > >          icount_opts = 0x0
> > > > > >          olist = 0x555555e57e80
> > > > > >          optind = 62
> > > > > >          optarg = 0x7fffffffe914
> > > > > > "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
> > > > > >          loadvm = 0x0
> > > > > >          machine_class = 0x55555637d5c0
> > > > > >          cpu_model = 0x0
> > > > > >          vga_model = 0x0
> > > > > >          qtest_chrdev = 0x0
> > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > >          qtest_log = 0x0
> > > > > >          pid_file = 0x0
> > > > > >          incoming = 0x0
> > > > > >          show_vnc_port = 0
> > > > > >          defconfig = true
> > > > > >          userconfig = true
> > > > > >          log_mask = 0x0
> > > > > >          log_file = 0x0
> > > > > >          mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
> > > > > >            realloc = 0x55555575a45a <realloc_and_trace>,
> > > > > >            free = 0x55555575a4c1 <free_and_trace>, calloc = 0,
> > > > > > try_malloc
> > > > > > = 0,
> > > > > >            try_realloc = 0}
> > > > > >          trace_events = 0x0
> > > > > >          trace_file = 0x0
> > > > > >          default_ram_size = 134217728
> > > > > >          maxram_size = 2130706432
> > > > > >          ram_slots = 0
> > > > > >          vmstate_dump_file = 0x0
> > > > > >          main_loop_err = 0x0
> > > > > >          __func__ = "main"
> > > > > I take a fast look in source based on calltrace and I saw this commit:
> > > > > http://secure-web.cisco.com/1EXVvN4KugVmCtI8RnLSX68LVqyly3ymtr7bhU7HDX8viw0fYlCBA54KE1K_VbwvaJhMDSmpeNsTiBHicuNWfTtG_XH9DP4c-7oqEb6kCcWzXKnCcQNOb9ikh4FRIBDr9R069aR0R5fdiB9q4iQSFDc4X0ttOQHu8h69rpG-X2bI/http%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dcommit%3Bh%3D37f9e258b64b3cf97c7c78df60660100c9eb5a21
> > > > > xen-hvm.c: Add support for Xen access to vmport
> > > > > Can be the cause of regression and I must try another test reverting
> > > > > this
> > > > > commit or is not related?
> > > > > 
> > > > > Thanks for any reply anddo sorry for my bad english.
> > > > > 
> > > > > > Qemu crash on fedora 20 lxde (with software updates of some days
> > > > > > ago)
> > > > > > boot with this backtrace:
> > > > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > > > 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
> > > > > > > addr=0, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > > > > 73          eax = env->regs[R_EAX];
> > > > > > > (gdb) bt full
> > > > > > > #0  0x0000555555689607 in vmport_ioport_read
> > > > > > > (opaque=0x555556440a20,
> > > > > > > addr=0, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > > > >          s = 0x555556440a20
> > > > > > >          cs = 0x0
> > > > > > >          cpu = 0x0
> > > > > > >          __func__ = "vmport_ioport_read"
> > > > > > >          env = 0x8250
> > > > > > >          command = 0 '\000'
> > > > > > >          eax = 0
> > > > > > > #1  0x0000555555655b9c in memory_region_read_accessor
> > > > > > > (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0,
> > > > > > > mask=4294967295)
> > > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
> > > > > > >          tmp = 0
> > > > > > > #2  0x0000555555655e8f in access_with_adjusted_size (addr=0,
> > > > > > > value=0x7fffffffd8c0, size=4, access_size_min=4,
> > > > > > > access_size_max=4,
> > > > > > >      access=0x555555655b3a <memory_region_read_accessor>,
> > > > > > > mr=0x555556440aa8) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
> > > > > > >          access_mask = 4294967295
> > > > > > >          access_size = 4
> > > > > > >          i = 0
> > > > > > > #3  0x0000555555658cc1 in memory_region_dispatch_read1
> > > > > > > (mr=0x555556440aa8, addr=0, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
> > > > > > >          data = 0
> > > > > > > #4  0x0000555555658d89 in memory_region_dispatch_read
> > > > > > > (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> > > > > > > No locals.
> > > > > > > #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0,
> > > > > > > pval=0x7fffffffd998, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> > > > > > > No locals.
> > > > > > > #6  0x0000555555609fae in address_space_rw (as=0x555555eae840,
> > > > > > > addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4,
> > > > > > > is_write=false)
> > > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
> > > > > > >          l = 4
> > > > > > >          ptr = 0x0
> > > > > > >          val = 7964229952888770560
> > > > > > >          addr1 = 0
> > > > > > >          mr = 0x555556440aa8
> > > > > > >          error = false
> > > > > > > #7  0x000055555560a173 in address_space_read (as=0x555555eae840,
> > > > > > > addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
> > > > > > > No locals.
> > > > > > > #8  0x000055555564fac7 in cpu_inl (addr=22104) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
> > > > > > >          buf = "\377\377\377\377"
> > > > > > >          val = 21845
> > > > > > > #9  0x000055555567084b in do_inp (addr=22104, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> > > > > > > No locals.
> > > > > > > #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
> > > > > > >          i = 0
> > > > > > > #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590,
> > > > > > > req=0x7ffff7ff3000) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> > > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > > > No locals.
> > > > > > > #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590)
> > > > > > > at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
> > > > > > >          state = 0x5555563c1590
> > > > > > >          req = 0x7ffff7ff3000
> > > > > > > #13 0x000055555596d874 in qemu_iohandler_poll
> > > > > > > (pollfds=0x555556388a30,
> > > > > > > ret=1) at iohandler.c:143
> > > > > > >          revents = 1
> > > > > > >          pioh = 0x5555563f3c90
> > > > > > >          ioh = 0x555556515f80
> > > > > > > #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at
> > > > > > > main-loop.c:495
> > > > > > >          ret = 1
> > > > > > >          timeout = 4294967295
> > > > > > >          timeout_ns = 3418165
> > > > > > > #15 0x00005555557567b7 in main_loop () at vl.c:1882
> > > > > > >          nonblocking = false
> > > > > > >          last_io = 1
> > > > > > > #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038,
> > > > > > > envp=0x7fffffffe230) at vl.c:4400
> > > > > > >          i = 128
> > > > > > >          snapshot = 0
> > > > > > >          linux_boot = 0
> > > > > > >          initrd_filename = 0x0
> > > > > > >          kernel_filename = 0x0
> > > > > > >          kernel_cmdline = 0x555555a485c6 ""
> > > > > > >          boot_order = 0x5555563864e0 "dc"
> > > > > > >          ds = 0x5555564c71b0
> > > > > > >          cyls = 0
> > > > > > >          heads = 0
> > > > > > >          secs = 0
> > > > > > >          translation = 0
> > > > > > >          hda_opts = 0x0
> > > > > > >          opts = 0x555556386430
> > > > > > >          machine_opts = 0x555556388090
> > > > > > >          icount_opts = 0x0
> > > > > > >          olist = 0x555555e56da0
> > > > > > >          optind = 62
> > > > > > >          optarg = 0x7fffffffe914
> > > > > > > "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
> > > > > > >          loadvm = 0x0
> > > > > > >          machine_class = 0x55555637c5c0
> > > > > > >          cpu_model = 0x0
> > > > > > >          vga_model = 0x0
> > > > > > >          qtest_chrdev = 0x0
> > > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > > >          qtest_log = 0x0
> > > > > > >          pid_file = 0x0
> > > > > > >          incoming = 0x0
> > > > > > >          show_vnc_port = 0
> > > > > > >          defconfig = true
> > > > > > >          userconfig = true
> > > > > > >          log_mask = 0x0
> > > > > > >          log_file = 0x0
> > > > > > >          mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>,
> > > > > > > realloc = 0x555555759ed2 <realloc_and_trace>, free =
> > > > > > > 0x555555759f39
> > > > > > > <free_and_trace>, calloc = 0,
> > > > > > >            try_malloc = 0, try_realloc = 0}
> > > > > > >          trace_events = 0x0
> > > > > > >          trace_file = 0x0
> > > > > > >          default_ram_size = 134217728
> > > > > > >          maxram_size = 2013265920
> > > > > > >          ram_slots = 0
> > > > > > >          vmstate_dump_file = 0x0
> > > > > > >          main_loop_err = 0x0
> > > > > > >          __func__ = "main"
> > > > > > 
> > > > > > > xl -vvv create /etc/xen/FEDORA19.cfg
> > > > > > > Parsing config from /etc/xen/FEDORA19.cfg
> > > > > > > libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660:
> > > > > > > create: how=(nil) callback=(nil) poller=0xac2af0
> > > > > > > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend:
> > > > > > > Disk
> > > > > > > vdev=hda spec.backend=unknown
> > > > > > > libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda,
> > > > > > > backend phy unsuitable as phys path not a block device
> > > > > > > libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend:
> > > > > > > Disk
> > > > > > > vdev=hda, using backend qdisk
> > > > > > > libxl: debug: libxl_create.c:935:initiate_domain_create: running
> > > > > > > bootloader
> > > > > > > libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a
> > > > > > > PV
> > > > > > > domain, skipping bootloader
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac32f8: deregister unregistered
> > > > > > > xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
> > > > > > > xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
> > > > > > > xc: detail: VIRTUAL MEMORY ARRANGEMENT:
> > > > > > > xc: detail:   Loader: 0000000000100000->000000000036b324
> > > > > > > xc: detail:   Modules: 0000000000000000->0000000000000000
> > > > > > > xc: detail:   TOTAL: 0000000000000000->0000000078000000
> > > > > > > xc: detail:   ENTRY:    0000000000100000
> > > > > > > xc: detail: PHYSICAL MEMORY ALLOCATION:
> > > > > > > xc: detail:   4KB PAGES: 0x0000000000000200
> > > > > > > xc: detail:   2MB PAGES: 0x00000000000003bf
> > > > > > > xc: detail:   1GB PAGES: 0x0000000000000000
> > > > > > > xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 ->
> > > > > > > 0x7f1f975012b0
> > > > > > > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend:
> > > > > > > Disk
> > > > > > > vdev=hda spec.backend=qdisk
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac4ad0: deregister unregistered
> > > > > > > libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning
> > > > > > > device-model /usr/lib/xen/bin/qemu-gdb with arguments:
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > /usr/lib/xen/bin/qemu-gdb
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > chardev=libxl-cmd,mode=control
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: FEDORA
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -spice
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > spicevmc,id=vdagent,name=vdagent
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > virtserialport,chardev=vdagent,name=com.redhat.spice.0
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > qxl-vga,vram_size_mb=64,ram_size_mb=64
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > spicevmc,name=usbredir,id=usbrc1
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > usb-redir,chardev=usbrc1,id=usbrc1
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > spicevmc,name=usbredir,id=usbrc2
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > usb-redir,chardev=usbrc2,id=usbrc2
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > spicevmc,name=usbredir,id=usbrc3
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > usb-redir,chardev=usbrc3,id=usbrc3
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > spicevmc,name=usbredir,id=usbrc4
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > usb-redir,chardev=usbrc4,id=usbrc4
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -netdev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -drive
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
> > > > > > > libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
> > > > > > > w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
> > > > > > > register slotnum=3
> > > > > > > libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660:
> > > > > > > inprogress: poller=0xac2af0, flags=i
> > > > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
> > > > > > > wpath=/local/domain/0/device-model/9/state token=3/0: event
> > > > > > > epath=/local/domain/0/device-model/9/state
> > > > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
> > > > > > > wpath=/local/domain/0/device-model/9/state token=3/0: event
> > > > > > > epath=/local/domain/0/device-model/9/state
> > > > > > > libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
> > > > > > > deregister slotnum=3
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac3558: deregister unregistered
> > > > > > > libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to
> > > > > > > /var/run/xen/qmp-libxl-9
> > > > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > > > qmp
> > > > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
> > > > > > > '{
> > > > > > >      "execute": "qmp_capabilities",
> > > > > > >      "id": 1
> > > > > > > }
> > > > > > > '
> > > > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > > > return
> > > > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
> > > > > > > '{
> > > > > > >      "execute": "query-chardev",
> > > > > > >      "id": 2
> > > > > > > }
> > > > > > > '
> > > > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > > > return
> > > > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
> > > > > > > '{
> > > > > > >      "execute": "query-vnc",
> > > > > > >      "id": 3
> > > > > > > }
> > > > > > > '
> > > > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > > > return
> > > > > > > libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
> > > > > > > w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
> > > > > > > register slotnum=3
> > > > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
> > > > > > > wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
> > > > > > > epath=/local/domain/0/backend/vif/9/0/state
> > > > > > > libxl: debug: libxl_event.c:810:devstate_watch_callback: backend
> > > > > > > /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting
> > > > > > > state 1
> > > > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
> > > > > > > wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
> > > > > > > epath=/local/domain/0/backend/vif/9/0/state
> > > > > > > libxl: debug: libxl_event.c:806:devstate_watch_callback: backend
> > > > > > > /local/domain/0/backend/vif/9/0/state wanted state 2 ok
> > > > > > > libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
> > > > > > > deregister slotnum=3
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac8368: deregister unregistered
> > > > > > > libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
> > > > > > > script: /etc/xen/scripts/vif-bridge online
> > > > > > > libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking
> > > > > > > to
> > > > > > > execute: /etc/xen/scripts/vif-bridge online
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac83f0: deregister unregistered
> > > > > > > libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
> > > > > > > script: /etc/xen/scripts/vif-bridge add
> > > > > > > libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking
> > > > > > > to
> > > > > > > execute: /etc/xen/scripts/vif-bridge add
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac83f0: deregister unregistered
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac83f0: deregister unregistered
> > > > > > > libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao
> > > > > > > 0xac2660: progress report: ignored
> > > > > > > libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660:
> > > > > > > complete, rc=0
> > > > > > > libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660:
> > > > > > > destroy
> > > > > > > xc: debug: hypercall buffer: total allocations:704 total
> > > > > > > releases:704
> > > > > > > xc: debug: hypercall buffer: current allocations:0 maximum
> > > > > > > allocations:4
> > > > > > > xc: debug: hypercall buffer: cache current size:4
> > > > > > > xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
> > > > > > > xc: debug: hypercall buffer: total allocations:0 total releases:0
> > > > > > > xc: debug: hypercall buffer: current allocations:0 maximum
> > > > > > > allocations:0
> > > > > > > xc: debug: hypercall buffer: cache current size:0
> > > > > > > xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
> > > > > > xl dmesg
> > > > > > > (d9) HVM Loader
> > > > > > > (d9) Detected Xen v4.5.0-rc
> > > > > > > (d9) Xenbus rings @0xfeffc000, event channel 1
> > > > > > > (d9) System requested SeaBIOS
> > > > > > > (d9) CPU speed is 2660 MHz
> > > > > > > (d9) Relocating guest memory for lowmem MMIO space disabled
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
> > > > > > > (d9) PCI-ISA link 0 routed to IRQ5
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
> > > > > > > (d9) PCI-ISA link 1 routed to IRQ10
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
> > > > > > > (d9) PCI-ISA link 2 routed to IRQ11
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
> > > > > > > (d9) PCI-ISA link 3 routed to IRQ5
> > > > > > > (d9) pci dev 01:3 INTA->IRQ10
> > > > > > > (d9) pci dev 02:0 INTA->IRQ11
> > > > > > > (d9) pci dev 03:0 INTA->IRQ5
> > > > > > > (d9) pci dev 04:0 INTA->IRQ5
> > > > > > > (d9) pci dev 05:0 INTA->IRQ10
> > > > > > > (d9) pci dev 06:0 INTA->IRQ11
> > > > > > > (d9) pci dev 1d:0 INTA->IRQ10
> > > > > > > (d9) pci dev 1d:1 INTB->IRQ11
> > > > > > > (d9) pci dev 1d:2 INTC->IRQ5
> > > > > > > (d9) pci dev 1d:7 INTD->IRQ5
> > > > > > > (d9) No RAM in high memory; setting high_mem resource base to
> > > > > > > 100000000
> > > > > > > (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
> > > > > > > (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
> > > > > > > (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
> > > > > > > (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
> > > > > > > (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
> > > > > > > (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
> > > > > > > (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
> > > > > > > (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
> > > > > > > (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
> > > > > > > (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
> > > > > > > (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
> > > > > > > (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
> > > > > > > (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
> > > > > > > (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
> > > > > > > (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
> > > > > > > (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
> > > > > > > (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
> > > > > > > (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
> > > > > > > (d9) Multiprocessor initialisation:
> > > > > > > (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
> > > > > > > ...
> > > > > > > done.
> > > > > > > (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
> > > > > > > ...
> > > > > > > done.
> > > > > > > (d9) Testing HVM environment:
> > > > > > > (d9)  - REP INSB across page boundaries ... passed
> > > > > > > (d9)  - GS base MSRs and SWAPGS ... passed
> > > > > > > (d9) Passed 2 of 2 tests
> > > > > > > (d9) Writing SMBIOS tables ...
> > > > > > > (d9) Loading SeaBIOS ...
> > > > > > > (d9) Creating MP tables ...
> > > > > > > (d9) Loading ACPI ...
> > > > > > > (d9) S3 disabled
> > > > > > > (d9) S4 disabled
> > > > > > > (d9) vm86 TSS at fc00a100
> > > > > > > (d9) BIOS map:
> > > > > > > (d9)  10000-100d3: Scratch space
> > > > > > > (d9)  c0000-fffff: Main BIOS
> > > > > > > (d9) E820 table:
> > > > > > > (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> > > > > > > (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
> > > > > > > (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
> > > > > > > (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
> > > > > > > (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
> > > > > > > (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> > > > > > > (d9) Invoking SeaBIOS ...
> > > > > > > (d9) SeaBIOS (version
> > > > > > > debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> > > > > > > (d9)
> > > > > > > (d9) Found Xen hypervisor signature at 40000000
> > > > > > > (d9) Running on QEMU (i440fx)
> > > > > > > (d9) xen: copy e820...
> > > > > > > (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
> > > > > > > (d9) CPU Mhz=2660
> > > > > > > (d9) Found 13 PCI devices (max PCI bus is 00)
> > > > > > > (d9) Allocated Xen hypercall page at 77fff000
> > > > > > > (d9) Detected Xen v4.5.0-rc
> > > > > > > (d9) xen: copy BIOS tables...
> > > > > > > (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
> > > > > > > (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
> > > > > > > (d9) Copying PIR from 0x00010030 to 0x000f0dc0
> > > > > > > (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
> > > > > > > (d9) Using pmtimer, ioport 0xb008
> > > > > > > (d9) Scan for VGA option rom
> > > > > > > (d9) Running option rom at c000:0003
> > > > > > > (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
> > > > > > > (d9) pmm call arg1=0
> > > > > > > (d9) Turning on vga text mode console
> > > > > > > (d9) SeaBIOS (version
> > > > > > > debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> > > > > > > (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
> > > > > > > (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
> > > > > > > (d9) Found 0 lpt ports
> > > > > > > (d9) Found 0 serial ports
> > > > > > > (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> > > > > > > (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> > > > > > > (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
> > > > > > > (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> > > > > > > (d9) UHCI init on dev 00:1d.0 (io=c240)
> > > > > > > (d9) UHCI init on dev 00:1d.1 (io=c260)
> > > > > > > (d9) UHCI init on dev 00:1d.2 (io=c280)
> > > > > > > (d9) PS2 keyboard initialized
> > > > > > > (d9) All threads complete.
> > > > > > > (d9) Scan for option roms
> > > > > > > (d9) Running option rom at c980:0003
> > > > > > > (d9) pmm call arg1=1
> > > > > > > (d9) pmm call arg1=0
> > > > > > > (d9) pmm call arg1=1
> > > > > > > (d9) pmm call arg1=0
> > > > > > > (d9) Searching bootorder for: /pci@i0cf8/*@6
> > > > > > > (d9)
> > > > > > > (d9) Press F12 for boot menu.
> > > > > > > (d9)
> > > > > > > (d9) Searching bootorder for: HALT
> > > > > > > (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba
> > > > > > > LCHS=1024/255/63 s=20480000
> > > > > > > (d9) Space available for UMB: ca800-ef000, f0000-f0d40
> > > > > > > (d9) Returned 258048 bytes of ZoneHigh
> > > > > > > (d9) e820 map has 6 items:
> > > > > > > (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
> > > > > > > (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
> > > > > > > (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
> > > > > > > (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
> > > > > > > (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
> > > > > > > (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
> > > > > > > (d9) enter handle_19:
> > > > > > > (d9)   NULL
> > > > > > > (d9) Booting from Hard Disk...
> > > > > > > (d9) Booting from 0000:7c00
> > > > > > > (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
> > > > > > domU's xl cfg:
> > > > > > > name='FEDORA'
> > > > > > > builder="hvm"
> > > > > > > device_model_override="/usr/lib/xen/bin/qemu-gdb"
> > > > > > > memory=2048
> > > > > > > vcpus=2
> > > > > > > acpi_s3=0
> > > > > > > acpi_s4=0
> > > > > > > vif=['bridge=xenbr0']
> > > > > > > disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
> > > > > > > boot='dc'
> > > > > > > device_model_version='qemu-xen'
> > > > > > > vnc=0
> > > > > > > keymap="it"
> > > > > > > vga="qxl"
> > > > > > > spice=1
> > > > > > > spicehost='0.0.0.0'
> > > > > > > spiceport=6005
> > > > > > > spicedisable_ticketing=1
> > > > > > > spicevdagent=1
> > > > > > > spice_clipboard_sharing=0
> > > > > > > spiceusbredirection=4
> > > > > > > soundhw="hda"
> > > > > > I tested also with stdvga instead of qxl vga but qemu crash always
> > > > > > on
> > > > > > fedora boot with same error.
> > > > > > 
> > > > > > If you need more informations/tests tell me and I'll post them.
> > > > > > 
> > > > > > Thanks for any reply and sorry for my bad english.
> > > > > > 
> > > > > 
> > > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:23:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18:23:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xr9ug-00006p-Ss; Wed, 19 Nov 2014 18:23:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xr9ue-00006i-Su
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 18:23:33 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	20/4D-02957-420EC645; Wed, 19 Nov 2014 18:23:32 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416421409!13580786!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32007 invoked from network); 19 Nov 2014 18:23:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 18:23:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="194500512"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 13:18:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xr9po-0008D6-Au;
	Wed, 19 Nov 2014 18:18:32 +0000
Date: Wed, 19 Nov 2014 18:18:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Don Slutz <dslutz@verizon.com>
In-Reply-To: <546CD906.40903@terremark.com>
Message-ID: <alpine.DEB.2.02.1411191817240.12596@kaball.uk.xensource.com>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
	<546CAFB1.8070904@terremark.com> <546CBA8B.2090903@m2r.biz>
	<alpine.DEB.2.02.1411191551120.12596@kaball.uk.xensource.com>
	<546CD906.40903@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>,
	anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org
Subject: Re: [Xen-devel] [Qemu-devel] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Don Slutz wrote:
> I have posted the patch:
> 
> Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
> for xenfv machine
> Date: Wed, 19 Nov 2014 12:30:57 -0500
> Message-ID: <1416418257-10166-1-git-send-email-dslutz@verizon.com>
> 
> 
> Which fixes QEMU 2.2 for xenfv.  However if you configure xen_platform_pci=0
> you will still
> have this issue.  The good news is that xen-4.5 currently does not have QEMU
> 2.2 and so does
> not have this issue.
> 
> Only people (groups like spice?) that want QEMU 2.2.0 with xen 4.5.0 (or older
> xen versions)
> will hit this.
> 
> I have changes to xen 4.6 which will fix the xen_platform_pci=0 case also.
> 
> In order to get xen 4.5 to fully work with QEMU 2.2.0 (both in hard freeze)
> 
> the 1st patch from "Dr. David Alan Gilbert <dgilbert@redhat.com>"
> would need to be applied to xen's qemu 2.0.2 (+ changes) so that
> vmport=off can be added to --machine.
> 
> And a patch (yet to be written, subset of changes I have pending for 4.6)
> that adds vmport=off to QEMU args for --machine (it can be done in all cases).

What happens if you pass vmport=off via --machine, without David Alan
Gilbert's patch in QEMU?


>     -Don Slutz
> 
> 
> 
> On 11/19/14 10:52, Stefano Stabellini wrote:
> > On Wed, 19 Nov 2014, Fabio Fantoni wrote:
> > > Il 19/11/2014 15:56, Don Slutz ha scritto:
> > > > I think I know what is happening here.  But you are pointing at the
> > > > wrong
> > > > change.
> > > > 
> > > > commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
> > > > 
> > > > Is what I am guessing at this time is the issue.  I think that
> > > > xen_enabled()
> > > > is
> > > > returning false in pc_machine_initfn.  Where as in pc_init1 is is
> > > > returning
> > > > true.
> > > > 
> > > > I am thinking that:
> > > > 
> > > > 
> > > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > > > index 7bb97a4..3268c29 100644
> > > > --- a/hw/i386/pc_piix.c
> > > > +++ b/hw/i386/pc_piix.c
> > > > @@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
> > > >       .desc = "Xen Fully-virtualized PC",
> > > >       .init = pc_xen_hvm_init,
> > > >       .max_cpus = HVM_MAX_VCPUS,
> > > > -    .default_machine_opts = "accel=xen",
> > > > +    .default_machine_opts = "accel=xen,vmport=off",
> > > >       .hot_add_cpu = pc_hot_add_cpu,
> > > >   };
> > > >   #endif
> > > > 
> > > > Will fix your issue. I have not tested this yet.
> > > Tested now and it solves regression of linux hvm domUs with qemu 2.2,
> > > thanks.
> > > I think that I'm not the only with this regression and that this patch (or
> > > a
> > > fix to the cause in vmport) should be applied before qemu 2.2 final.
> > Don,
> > please submit a proper patch with a Signed-off-by.
> > 
> > Thanks!
> > 
> > - Stefano
> > 
> > > >      -Don Slutz
> > > > 
> > > > 
> > > > On 11/19/14 09:04, Fabio Fantoni wrote:
> > > > > Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
> > > > > > dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid
> > > > > > leaf
> > > > > > with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches,
> > > > > > and
> > > > > > qemu 2.2 from spice git (spice/next commit
> > > > > > e779fa0a715530311e6f59fc8adb0f6eca914a89):
> > > > > > https://github.com/Fantu/Xen/commits/rebase/m2r-staging
> > > > > I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the
> > > > > full
> > > > > backtrace of latest test:
> > > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > > 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
> > > > > > addr=0,
> > > > > >      size=4) at
> > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > > > 73          eax = env->regs[R_EAX];
> > > > > > (gdb) bt full
> > > > > > #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
> > > > > > addr=0,
> > > > > >      size=4) at
> > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > > >          s = 0x5555564443a0
> > > > > >          cs = 0x0
> > > > > >          cpu = 0x0
> > > > > >          __func__ = "vmport_ioport_read"
> > > > > >          env = 0x8250
> > > > > >          command = 0 '\000'
> > > > > >          eax = 0
> > > > > > #1  0x0000555555655fc4 in memory_region_read_accessor
> > > > > > (mr=0x555556444428,
> > > > > >      addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
> > > > > >          tmp = 0
> > > > > > #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
> > > > > >      value=0x7fffffffd8d0, size=4, access_size_min=4,
> > > > > > access_size_max=4,
> > > > > >      access=0x555555655f62 <memory_region_read_accessor>,
> > > > > > mr=0x555556444428)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
> > > > > >          access_mask = 4294967295
> > > > > >          access_size = 4
> > > > > >          i = 0
> > > > > > #3  0x00005555556590e9 in memory_region_dispatch_read1
> > > > > > (mr=0x555556444428,
> > > > > >      addr=0, size=4) at
> > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
> > > > > >          data = 0
> > > > > > #4  0x00005555556591b1 in memory_region_dispatch_read
> > > > > > (mr=0x555556444428,
> > > > > >      addr=0, pval=0x7fffffffd9a8, size=4)
> > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> > > > > > No locals.
> > > > > > #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
> > > > > >      pval=0x7fffffffd9a8, size=4)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> > > > > > No locals.
> > > > > > #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920,
> > > > > > addr=22104,
> > > > > >      buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
> > > > > >          l = 4
> > > > > >          ptr = 0x555555a92d87 "%s/%d:\n"
> > > > > >          val = 7852232130387826944
> > > > > >          addr1 = 0
> > > > > >          mr = 0x555556444428
> > > > > >          error = false
> > > > > > #7  0x000055555560a38f in address_space_read (as=0x555555eaf920,
> > > > > > addr=22104,
> > > > > >      buf=0x7fffffffda50 "\377\377\377\377", len=4)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
> > > > > > No locals.
> > > > > > #8  0x000055555564fd4b in cpu_inl (addr=22104)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
> > > > > >          buf = "\377\377\377\377"
> > > > > >          val = 21845
> > > > > > #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > > No locals.
> > > > > > #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
> > > > > >          i = 1
> > > > > > #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
> > > > > >      req=0x7ffff7ff3020) at
> > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> > > > > > No locals.
> > > > > > #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
> > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
> > > > > >          state = 0x5555563c2510
> > > > > >          req = 0x7ffff7ff3020
> > > > > > #13 0x000055555596e240 in qemu_iohandler_poll
> > > > > > (pollfds=0x555556389a30,
> > > > > > ret=1)
> > > > > >      at iohandler.c:143
> > > > > >          revents = 1
> > > > > >          pioh = 0x5555563f7610
> > > > > >          ioh = 0x555556450a40
> > > > > > #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at
> > > > > > main-loop.c:495
> > > > > >          ret = 1
> > > > > >          timeout = 4294967295
> > > > > >          timeout_ns = 3965432
> > > > > > #15 0x0000555555756d3f in main_loop () at vl.c:1882
> > > > > >          nonblocking = false
> > > > > >          last_io = 0
> > > > > > #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
> > > > > >      envp=0x7fffffffe240) at vl.c:4400
> > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > >          i = 128
> > > > > >          snapshot = 0
> > > > > >          linux_boot = 0
> > > > > >          initrd_filename = 0x0
> > > > > >          kernel_filename = 0x0
> > > > > >          kernel_cmdline = 0x555555a48f86 ""
> > > > > >          boot_order = 0x555556387460 "dc"
> > > > > >          ds = 0x5555564b2040
> > > > > >          cyls = 0
> > > > > >          heads = 0
> > > > > >          secs = 0
> > > > > >          translation = 0
> > > > > >          hda_opts = 0x0
> > > > > >          opts = 0x5555563873b0
> > > > > >          machine_opts = 0x555556389010
> > > > > >          icount_opts = 0x0
> > > > > >          olist = 0x555555e57e80
> > > > > >          optind = 62
> > > > > >          optarg = 0x7fffffffe914
> > > > > > "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
> > > > > >          loadvm = 0x0
> > > > > >          machine_class = 0x55555637d5c0
> > > > > >          cpu_model = 0x0
> > > > > >          vga_model = 0x0
> > > > > >          qtest_chrdev = 0x0
> > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > >          qtest_log = 0x0
> > > > > >          pid_file = 0x0
> > > > > >          incoming = 0x0
> > > > > >          show_vnc_port = 0
> > > > > >          defconfig = true
> > > > > >          userconfig = true
> > > > > >          log_mask = 0x0
> > > > > >          log_file = 0x0
> > > > > >          mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
> > > > > >            realloc = 0x55555575a45a <realloc_and_trace>,
> > > > > >            free = 0x55555575a4c1 <free_and_trace>, calloc = 0,
> > > > > > try_malloc
> > > > > > = 0,
> > > > > >            try_realloc = 0}
> > > > > >          trace_events = 0x0
> > > > > >          trace_file = 0x0
> > > > > >          default_ram_size = 134217728
> > > > > >          maxram_size = 2130706432
> > > > > >          ram_slots = 0
> > > > > >          vmstate_dump_file = 0x0
> > > > > >          main_loop_err = 0x0
> > > > > >          __func__ = "main"
> > > > > I take a fast look in source based on calltrace and I saw this commit:
> > > > > http://secure-web.cisco.com/1EXVvN4KugVmCtI8RnLSX68LVqyly3ymtr7bhU7HDX8viw0fYlCBA54KE1K_VbwvaJhMDSmpeNsTiBHicuNWfTtG_XH9DP4c-7oqEb6kCcWzXKnCcQNOb9ikh4FRIBDr9R069aR0R5fdiB9q4iQSFDc4X0ttOQHu8h69rpG-X2bI/http%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dcommit%3Bh%3D37f9e258b64b3cf97c7c78df60660100c9eb5a21
> > > > > xen-hvm.c: Add support for Xen access to vmport
> > > > > Can be the cause of regression and I must try another test reverting
> > > > > this
> > > > > commit or is not related?
> > > > > 
> > > > > Thanks for any reply anddo sorry for my bad english.
> > > > > 
> > > > > > Qemu crash on fedora 20 lxde (with software updates of some days
> > > > > > ago)
> > > > > > boot with this backtrace:
> > > > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > > > 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
> > > > > > > addr=0, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > > > > 73          eax = env->regs[R_EAX];
> > > > > > > (gdb) bt full
> > > > > > > #0  0x0000555555689607 in vmport_ioport_read
> > > > > > > (opaque=0x555556440a20,
> > > > > > > addr=0, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
> > > > > > >          s = 0x555556440a20
> > > > > > >          cs = 0x0
> > > > > > >          cpu = 0x0
> > > > > > >          __func__ = "vmport_ioport_read"
> > > > > > >          env = 0x8250
> > > > > > >          command = 0 '\000'
> > > > > > >          eax = 0
> > > > > > > #1  0x0000555555655b9c in memory_region_read_accessor
> > > > > > > (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0,
> > > > > > > mask=4294967295)
> > > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
> > > > > > >          tmp = 0
> > > > > > > #2  0x0000555555655e8f in access_with_adjusted_size (addr=0,
> > > > > > > value=0x7fffffffd8c0, size=4, access_size_min=4,
> > > > > > > access_size_max=4,
> > > > > > >      access=0x555555655b3a <memory_region_read_accessor>,
> > > > > > > mr=0x555556440aa8) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
> > > > > > >          access_mask = 4294967295
> > > > > > >          access_size = 4
> > > > > > >          i = 0
> > > > > > > #3  0x0000555555658cc1 in memory_region_dispatch_read1
> > > > > > > (mr=0x555556440aa8, addr=0, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
> > > > > > >          data = 0
> > > > > > > #4  0x0000555555658d89 in memory_region_dispatch_read
> > > > > > > (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
> > > > > > > No locals.
> > > > > > > #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0,
> > > > > > > pval=0x7fffffffd998, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
> > > > > > > No locals.
> > > > > > > #6  0x0000555555609fae in address_space_rw (as=0x555555eae840,
> > > > > > > addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4,
> > > > > > > is_write=false)
> > > > > > >      at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
> > > > > > >          l = 4
> > > > > > >          ptr = 0x0
> > > > > > >          val = 7964229952888770560
> > > > > > >          addr1 = 0
> > > > > > >          mr = 0x555556440aa8
> > > > > > >          error = false
> > > > > > > #7  0x000055555560a173 in address_space_read (as=0x555555eae840,
> > > > > > > addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
> > > > > > > No locals.
> > > > > > > #8  0x000055555564fac7 in cpu_inl (addr=22104) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
> > > > > > >          buf = "\377\377\377\377"
> > > > > > >          val = 21845
> > > > > > > #9  0x000055555567084b in do_inp (addr=22104, size=4) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
> > > > > > > No locals.
> > > > > > > #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
> > > > > > >          i = 0
> > > > > > > #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590,
> > > > > > > req=0x7ffff7ff3000) at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
> > > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > > > No locals.
> > > > > > > #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590)
> > > > > > > at
> > > > > > > /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
> > > > > > >          state = 0x5555563c1590
> > > > > > >          req = 0x7ffff7ff3000
> > > > > > > #13 0x000055555596d874 in qemu_iohandler_poll
> > > > > > > (pollfds=0x555556388a30,
> > > > > > > ret=1) at iohandler.c:143
> > > > > > >          revents = 1
> > > > > > >          pioh = 0x5555563f3c90
> > > > > > >          ioh = 0x555556515f80
> > > > > > > #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at
> > > > > > > main-loop.c:495
> > > > > > >          ret = 1
> > > > > > >          timeout = 4294967295
> > > > > > >          timeout_ns = 3418165
> > > > > > > #15 0x00005555557567b7 in main_loop () at vl.c:1882
> > > > > > >          nonblocking = false
> > > > > > >          last_io = 1
> > > > > > > #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038,
> > > > > > > envp=0x7fffffffe230) at vl.c:4400
> > > > > > >          i = 128
> > > > > > >          snapshot = 0
> > > > > > >          linux_boot = 0
> > > > > > >          initrd_filename = 0x0
> > > > > > >          kernel_filename = 0x0
> > > > > > >          kernel_cmdline = 0x555555a485c6 ""
> > > > > > >          boot_order = 0x5555563864e0 "dc"
> > > > > > >          ds = 0x5555564c71b0
> > > > > > >          cyls = 0
> > > > > > >          heads = 0
> > > > > > >          secs = 0
> > > > > > >          translation = 0
> > > > > > >          hda_opts = 0x0
> > > > > > >          opts = 0x555556386430
> > > > > > >          machine_opts = 0x555556388090
> > > > > > >          icount_opts = 0x0
> > > > > > >          olist = 0x555555e56da0
> > > > > > >          optind = 62
> > > > > > >          optarg = 0x7fffffffe914
> > > > > > > "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
> > > > > > >          loadvm = 0x0
> > > > > > >          machine_class = 0x55555637c5c0
> > > > > > >          cpu_model = 0x0
> > > > > > >          vga_model = 0x0
> > > > > > >          qtest_chrdev = 0x0
> > > > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > > >          qtest_log = 0x0
> > > > > > >          pid_file = 0x0
> > > > > > >          incoming = 0x0
> > > > > > >          show_vnc_port = 0
> > > > > > >          defconfig = true
> > > > > > >          userconfig = true
> > > > > > >          log_mask = 0x0
> > > > > > >          log_file = 0x0
> > > > > > >          mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>,
> > > > > > > realloc = 0x555555759ed2 <realloc_and_trace>, free =
> > > > > > > 0x555555759f39
> > > > > > > <free_and_trace>, calloc = 0,
> > > > > > >            try_malloc = 0, try_realloc = 0}
> > > > > > >          trace_events = 0x0
> > > > > > >          trace_file = 0x0
> > > > > > >          default_ram_size = 134217728
> > > > > > >          maxram_size = 2013265920
> > > > > > >          ram_slots = 0
> > > > > > >          vmstate_dump_file = 0x0
> > > > > > >          main_loop_err = 0x0
> > > > > > >          __func__ = "main"
> > > > > > 
> > > > > > > xl -vvv create /etc/xen/FEDORA19.cfg
> > > > > > > Parsing config from /etc/xen/FEDORA19.cfg
> > > > > > > libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660:
> > > > > > > create: how=(nil) callback=(nil) poller=0xac2af0
> > > > > > > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend:
> > > > > > > Disk
> > > > > > > vdev=hda spec.backend=unknown
> > > > > > > libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda,
> > > > > > > backend phy unsuitable as phys path not a block device
> > > > > > > libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend:
> > > > > > > Disk
> > > > > > > vdev=hda, using backend qdisk
> > > > > > > libxl: debug: libxl_create.c:935:initiate_domain_create: running
> > > > > > > bootloader
> > > > > > > libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a
> > > > > > > PV
> > > > > > > domain, skipping bootloader
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac32f8: deregister unregistered
> > > > > > > xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
> > > > > > > xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
> > > > > > > xc: detail: VIRTUAL MEMORY ARRANGEMENT:
> > > > > > > xc: detail:   Loader: 0000000000100000->000000000036b324
> > > > > > > xc: detail:   Modules: 0000000000000000->0000000000000000
> > > > > > > xc: detail:   TOTAL: 0000000000000000->0000000078000000
> > > > > > > xc: detail:   ENTRY:    0000000000100000
> > > > > > > xc: detail: PHYSICAL MEMORY ALLOCATION:
> > > > > > > xc: detail:   4KB PAGES: 0x0000000000000200
> > > > > > > xc: detail:   2MB PAGES: 0x00000000000003bf
> > > > > > > xc: detail:   1GB PAGES: 0x0000000000000000
> > > > > > > xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 ->
> > > > > > > 0x7f1f975012b0
> > > > > > > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend:
> > > > > > > Disk
> > > > > > > vdev=hda spec.backend=qdisk
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac4ad0: deregister unregistered
> > > > > > > libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning
> > > > > > > device-model /usr/lib/xen/bin/qemu-gdb with arguments:
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > /usr/lib/xen/bin/qemu-gdb
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > chardev=libxl-cmd,mode=control
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: FEDORA
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -spice
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > spicevmc,id=vdagent,name=vdagent
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > virtserialport,chardev=vdagent,name=com.redhat.spice.0
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > qxl-vga,vram_size_mb=64,ram_size_mb=64
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > spicevmc,name=usbredir,id=usbrc1
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > usb-redir,chardev=usbrc1,id=usbrc1
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > spicevmc,name=usbredir,id=usbrc2
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > usb-redir,chardev=usbrc2,id=usbrc2
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > spicevmc,name=usbredir,id=usbrc3
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > usb-redir,chardev=usbrc3,id=usbrc3
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > spicevmc,name=usbredir,id=usbrc4
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > usb-redir,chardev=usbrc4,id=usbrc4
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -netdev
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -drive
> > > > > > > libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
> > > > > > > file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
> > > > > > > libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
> > > > > > > w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
> > > > > > > register slotnum=3
> > > > > > > libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660:
> > > > > > > inprogress: poller=0xac2af0, flags=i
> > > > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
> > > > > > > wpath=/local/domain/0/device-model/9/state token=3/0: event
> > > > > > > epath=/local/domain/0/device-model/9/state
> > > > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
> > > > > > > wpath=/local/domain/0/device-model/9/state token=3/0: event
> > > > > > > epath=/local/domain/0/device-model/9/state
> > > > > > > libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
> > > > > > > deregister slotnum=3
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac3558: deregister unregistered
> > > > > > > libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to
> > > > > > > /var/run/xen/qmp-libxl-9
> > > > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > > > qmp
> > > > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
> > > > > > > '{
> > > > > > >      "execute": "qmp_capabilities",
> > > > > > >      "id": 1
> > > > > > > }
> > > > > > > '
> > > > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > > > return
> > > > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
> > > > > > > '{
> > > > > > >      "execute": "query-chardev",
> > > > > > >      "id": 2
> > > > > > > }
> > > > > > > '
> > > > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > > > return
> > > > > > > libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
> > > > > > > '{
> > > > > > >      "execute": "query-vnc",
> > > > > > >      "id": 3
> > > > > > > }
> > > > > > > '
> > > > > > > libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
> > > > > > > return
> > > > > > > libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
> > > > > > > w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
> > > > > > > register slotnum=3
> > > > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
> > > > > > > wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
> > > > > > > epath=/local/domain/0/backend/vif/9/0/state
> > > > > > > libxl: debug: libxl_event.c:810:devstate_watch_callback: backend
> > > > > > > /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting
> > > > > > > state 1
> > > > > > > libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
> > > > > > > wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
> > > > > > > epath=/local/domain/0/backend/vif/9/0/state
> > > > > > > libxl: debug: libxl_event.c:806:devstate_watch_callback: backend
> > > > > > > /local/domain/0/backend/vif/9/0/state wanted state 2 ok
> > > > > > > libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
> > > > > > > deregister slotnum=3
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac8368: deregister unregistered
> > > > > > > libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
> > > > > > > script: /etc/xen/scripts/vif-bridge online
> > > > > > > libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking
> > > > > > > to
> > > > > > > execute: /etc/xen/scripts/vif-bridge online
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac83f0: deregister unregistered
> > > > > > > libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
> > > > > > > script: /etc/xen/scripts/vif-bridge add
> > > > > > > libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking
> > > > > > > to
> > > > > > > execute: /etc/xen/scripts/vif-bridge add
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac83f0: deregister unregistered
> > > > > > > libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
> > > > > > > watch
> > > > > > > w=0xac83f0: deregister unregistered
> > > > > > > libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao
> > > > > > > 0xac2660: progress report: ignored
> > > > > > > libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660:
> > > > > > > complete, rc=0
> > > > > > > libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660:
> > > > > > > destroy
> > > > > > > xc: debug: hypercall buffer: total allocations:704 total
> > > > > > > releases:704
> > > > > > > xc: debug: hypercall buffer: current allocations:0 maximum
> > > > > > > allocations:4
> > > > > > > xc: debug: hypercall buffer: cache current size:4
> > > > > > > xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
> > > > > > > xc: debug: hypercall buffer: total allocations:0 total releases:0
> > > > > > > xc: debug: hypercall buffer: current allocations:0 maximum
> > > > > > > allocations:0
> > > > > > > xc: debug: hypercall buffer: cache current size:0
> > > > > > > xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
> > > > > > xl dmesg
> > > > > > > (d9) HVM Loader
> > > > > > > (d9) Detected Xen v4.5.0-rc
> > > > > > > (d9) Xenbus rings @0xfeffc000, event channel 1
> > > > > > > (d9) System requested SeaBIOS
> > > > > > > (d9) CPU speed is 2660 MHz
> > > > > > > (d9) Relocating guest memory for lowmem MMIO space disabled
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
> > > > > > > (d9) PCI-ISA link 0 routed to IRQ5
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
> > > > > > > (d9) PCI-ISA link 1 routed to IRQ10
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
> > > > > > > (d9) PCI-ISA link 2 routed to IRQ11
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
> > > > > > > (d9) PCI-ISA link 3 routed to IRQ5
> > > > > > > (d9) pci dev 01:3 INTA->IRQ10
> > > > > > > (d9) pci dev 02:0 INTA->IRQ11
> > > > > > > (d9) pci dev 03:0 INTA->IRQ5
> > > > > > > (d9) pci dev 04:0 INTA->IRQ5
> > > > > > > (d9) pci dev 05:0 INTA->IRQ10
> > > > > > > (d9) pci dev 06:0 INTA->IRQ11
> > > > > > > (d9) pci dev 1d:0 INTA->IRQ10
> > > > > > > (d9) pci dev 1d:1 INTB->IRQ11
> > > > > > > (d9) pci dev 1d:2 INTC->IRQ5
> > > > > > > (d9) pci dev 1d:7 INTD->IRQ5
> > > > > > > (d9) No RAM in high memory; setting high_mem resource base to
> > > > > > > 100000000
> > > > > > > (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
> > > > > > > (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
> > > > > > > (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
> > > > > > > (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
> > > > > > > (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
> > > > > > > (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
> > > > > > > (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
> > > > > > > (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
> > > > > > > (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
> > > > > > > (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
> > > > > > > (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
> > > > > > > (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
> > > > > > > (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
> > > > > > > (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
> > > > > > > (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
> > > > > > > (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
> > > > > > > (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
> > > > > > > (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
> > > > > > > (d9) Multiprocessor initialisation:
> > > > > > > (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
> > > > > > > ...
> > > > > > > done.
> > > > > > > (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
> > > > > > > ...
> > > > > > > done.
> > > > > > > (d9) Testing HVM environment:
> > > > > > > (d9)  - REP INSB across page boundaries ... passed
> > > > > > > (d9)  - GS base MSRs and SWAPGS ... passed
> > > > > > > (d9) Passed 2 of 2 tests
> > > > > > > (d9) Writing SMBIOS tables ...
> > > > > > > (d9) Loading SeaBIOS ...
> > > > > > > (d9) Creating MP tables ...
> > > > > > > (d9) Loading ACPI ...
> > > > > > > (d9) S3 disabled
> > > > > > > (d9) S4 disabled
> > > > > > > (d9) vm86 TSS at fc00a100
> > > > > > > (d9) BIOS map:
> > > > > > > (d9)  10000-100d3: Scratch space
> > > > > > > (d9)  c0000-fffff: Main BIOS
> > > > > > > (d9) E820 table:
> > > > > > > (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> > > > > > > (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
> > > > > > > (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
> > > > > > > (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
> > > > > > > (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
> > > > > > > (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> > > > > > > (d9) Invoking SeaBIOS ...
> > > > > > > (d9) SeaBIOS (version
> > > > > > > debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> > > > > > > (d9)
> > > > > > > (d9) Found Xen hypervisor signature at 40000000
> > > > > > > (d9) Running on QEMU (i440fx)
> > > > > > > (d9) xen: copy e820...
> > > > > > > (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
> > > > > > > (d9) CPU Mhz=2660
> > > > > > > (d9) Found 13 PCI devices (max PCI bus is 00)
> > > > > > > (d9) Allocated Xen hypercall page at 77fff000
> > > > > > > (d9) Detected Xen v4.5.0-rc
> > > > > > > (d9) xen: copy BIOS tables...
> > > > > > > (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
> > > > > > > (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
> > > > > > > (d9) Copying PIR from 0x00010030 to 0x000f0dc0
> > > > > > > (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
> > > > > > > (d9) Using pmtimer, ioport 0xb008
> > > > > > > (d9) Scan for VGA option rom
> > > > > > > (d9) Running option rom at c000:0003
> > > > > > > (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
> > > > > > > (d9) pmm call arg1=0
> > > > > > > (d9) Turning on vga text mode console
> > > > > > > (d9) SeaBIOS (version
> > > > > > > debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
> > > > > > > (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
> > > > > > > (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
> > > > > > > (d9) Found 0 lpt ports
> > > > > > > (d9) Found 0 serial ports
> > > > > > > (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> > > > > > > (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> > > > > > > (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
> > > > > > > (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> > > > > > > (d9) UHCI init on dev 00:1d.0 (io=c240)
> > > > > > > (d9) UHCI init on dev 00:1d.1 (io=c260)
> > > > > > > (d9) UHCI init on dev 00:1d.2 (io=c280)
> > > > > > > (d9) PS2 keyboard initialized
> > > > > > > (d9) All threads complete.
> > > > > > > (d9) Scan for option roms
> > > > > > > (d9) Running option rom at c980:0003
> > > > > > > (d9) pmm call arg1=1
> > > > > > > (d9) pmm call arg1=0
> > > > > > > (d9) pmm call arg1=1
> > > > > > > (d9) pmm call arg1=0
> > > > > > > (d9) Searching bootorder for: /pci@i0cf8/*@6
> > > > > > > (d9)
> > > > > > > (d9) Press F12 for boot menu.
> > > > > > > (d9)
> > > > > > > (d9) Searching bootorder for: HALT
> > > > > > > (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba
> > > > > > > LCHS=1024/255/63 s=20480000
> > > > > > > (d9) Space available for UMB: ca800-ef000, f0000-f0d40
> > > > > > > (d9) Returned 258048 bytes of ZoneHigh
> > > > > > > (d9) e820 map has 6 items:
> > > > > > > (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
> > > > > > > (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
> > > > > > > (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
> > > > > > > (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
> > > > > > > (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
> > > > > > > (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
> > > > > > > (d9) enter handle_19:
> > > > > > > (d9)   NULL
> > > > > > > (d9) Booting from Hard Disk...
> > > > > > > (d9) Booting from 0000:7c00
> > > > > > > (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
> > > > > > > (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
> > > > > > domU's xl cfg:
> > > > > > > name='FEDORA'
> > > > > > > builder="hvm"
> > > > > > > device_model_override="/usr/lib/xen/bin/qemu-gdb"
> > > > > > > memory=2048
> > > > > > > vcpus=2
> > > > > > > acpi_s3=0
> > > > > > > acpi_s4=0
> > > > > > > vif=['bridge=xenbr0']
> > > > > > > disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
> > > > > > > boot='dc'
> > > > > > > device_model_version='qemu-xen'
> > > > > > > vnc=0
> > > > > > > keymap="it"
> > > > > > > vga="qxl"
> > > > > > > spice=1
> > > > > > > spicehost='0.0.0.0'
> > > > > > > spiceport=6005
> > > > > > > spicedisable_ticketing=1
> > > > > > > spicevdagent=1
> > > > > > > spice_clipboard_sharing=0
> > > > > > > spiceusbredirection=4
> > > > > > > soundhw="hda"
> > > > > > I tested also with stdvga instead of qxl vga but qemu crash always
> > > > > > on
> > > > > > fedora boot with same error.
> > > > > > 
> > > > > > If you need more informations/tests tell me and I'll post them.
> > > > > > 
> > > > > > Thanks for any reply and sorry for my bad english.
> > > > > > 
> > > > > 
> > > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:26:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18: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 1Xr9xC-0000G2-MR; Wed, 19 Nov 2014 18:26:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr9xB-0000Fv-0B
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 18:26:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	95/94-09842-0C0EC645; Wed, 19 Nov 2014 18:26:08 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416421567!5941122!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 469 invoked from network); 19 Nov 2014 18:26:08 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 18:26:08 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so2866350wiw.16
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 10:26:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=tzEdCGARE1ETVURiht450r4dMrJJF2/N9ud6iOyltD0=;
	b=OZ1IxbJ7sSsfHUwG2HwO+WIWedwyG/U7w0Y5IwH/k/57eXv9MKXXravZhxJTGNjyxa
	kKpzVM6di2FM/jY1uQosPqElnNj1oQHa4+6uBAKEoSNvQ0m9So543o4tipOf6Sx33QAo
	FynLEVDDhq2aVgrpZAmx1OPDh2VWgWwk3cr5uBx0LH11hnd/VXm0zInBgUQR+HoYd97J
	Vx35YYeOiV9r3zcD+nLR3tqF9WyVLg9tVkoXtwNXo06higF7j2kH/FYKBukt2e5qZk7i
	9WTowKUakicz20D4+TDUrqhT8Da8pFdsGp0fRW/ZkbJu/BxsxPHA3wjQLzJZP04rKozR
	UxLQ==
X-Gm-Message-State: ALoCoQkaIqQPyK6j0rkz52AoVInf+zyiXjQOEuYeblBABU1kydWXqGY4TczW90oHb5TGeureBOew
X-Received: by 10.194.77.4 with SMTP id o4mr55517010wjw.41.1416421567809;
	Wed, 19 Nov 2014 10:26:07 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id wr9sm3309270wjb.42.2014.11.19.10.26.06
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 10:26:06 -0800 (PST)
Message-ID: <546CE0BD.6010102@linaro.org>
Date: Wed, 19 Nov 2014 18:26:05 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> That's right, the maintenance interrupt handler is not called, but it
> doesn't do anything so we are fine. The important thing is that an
> interrupt is sent and git_clear_lrs gets called on hypervisor entry.

It would be worth to write down this somewhere. Just in case someone
decide to add code in maintenance interrupt later.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:26:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18: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 1Xr9xF-0000GT-1p; Wed, 19 Nov 2014 18:26:13 +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 1Xr9xE-0000GB-3I
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 18:26:12 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	8C/FF-02702-3C0EC645; Wed, 19 Nov 2014 18:26:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416421569!8938746!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20129 invoked from network); 19 Nov 2014 18:26:10 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 18:26:10 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJIPvdK014022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 18:25:57 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJIPtZR024939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 18:25:56 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJIPsZg024847; Wed, 19 Nov 2014 18:25:54 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 10:25:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id DBCFD1181EE; Wed, 19 Nov 2014 13:25:52 -0500 (EST)
Date: Wed, 19 Nov 2014 13:25:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141119182552.GA14861@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411191701190.12596@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411191701190.12596@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>, andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 05:44:49PM +0000, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> 
> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> bad side effects on any other platforms as far as I can tell. It should
> go in 4.5.

Have you checked (aka ran the tests) on the other platforms?
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
  ^^^^^^^
 'Reported-and-Tested-by'
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..df140b9 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>  
> +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>  
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -527,8 +529,6 @@ void gic_inject(void)
>  
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> -    else
> -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>  }
>  
>  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:26:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18: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 1Xr9xC-0000G2-MR; Wed, 19 Nov 2014 18:26:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xr9xB-0000Fv-0B
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 18:26:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	95/94-09842-0C0EC645; Wed, 19 Nov 2014 18:26:08 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416421567!5941122!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 469 invoked from network); 19 Nov 2014 18:26:08 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 18:26:08 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so2866350wiw.16
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 10:26:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=tzEdCGARE1ETVURiht450r4dMrJJF2/N9ud6iOyltD0=;
	b=OZ1IxbJ7sSsfHUwG2HwO+WIWedwyG/U7w0Y5IwH/k/57eXv9MKXXravZhxJTGNjyxa
	kKpzVM6di2FM/jY1uQosPqElnNj1oQHa4+6uBAKEoSNvQ0m9So543o4tipOf6Sx33QAo
	FynLEVDDhq2aVgrpZAmx1OPDh2VWgWwk3cr5uBx0LH11hnd/VXm0zInBgUQR+HoYd97J
	Vx35YYeOiV9r3zcD+nLR3tqF9WyVLg9tVkoXtwNXo06higF7j2kH/FYKBukt2e5qZk7i
	9WTowKUakicz20D4+TDUrqhT8Da8pFdsGp0fRW/ZkbJu/BxsxPHA3wjQLzJZP04rKozR
	UxLQ==
X-Gm-Message-State: ALoCoQkaIqQPyK6j0rkz52AoVInf+zyiXjQOEuYeblBABU1kydWXqGY4TczW90oHb5TGeureBOew
X-Received: by 10.194.77.4 with SMTP id o4mr55517010wjw.41.1416421567809;
	Wed, 19 Nov 2014 10:26:07 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id wr9sm3309270wjb.42.2014.11.19.10.26.06
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 19 Nov 2014 10:26:06 -0800 (PST)
Message-ID: <546CE0BD.6010102@linaro.org>
Date: Wed, 19 Nov 2014 18:26:05 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> That's right, the maintenance interrupt handler is not called, but it
> doesn't do anything so we are fine. The important thing is that an
> interrupt is sent and git_clear_lrs gets called on hypervisor entry.

It would be worth to write down this somewhere. Just in case someone
decide to add code in maintenance interrupt later.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:26:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18: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 1Xr9xF-0000GT-1p; Wed, 19 Nov 2014 18:26:13 +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 1Xr9xE-0000GB-3I
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 18:26:12 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	8C/FF-02702-3C0EC645; Wed, 19 Nov 2014 18:26:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416421569!8938746!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20129 invoked from network); 19 Nov 2014 18:26:10 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 18:26:10 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJIPvdK014022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 18:25:57 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJIPtZR024939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 18:25:56 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJIPsZg024847; Wed, 19 Nov 2014 18:25:54 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 10:25:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id DBCFD1181EE; Wed, 19 Nov 2014 13:25:52 -0500 (EST)
Date: Wed, 19 Nov 2014 13:25:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141119182552.GA14861@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411191701190.12596@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411191701190.12596@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>, andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 05:44:49PM +0000, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> 
> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> bad side effects on any other platforms as far as I can tell. It should
> go in 4.5.

Have you checked (aka ran the tests) on the other platforms?
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
  ^^^^^^^
 'Reported-and-Tested-by'
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..df140b9 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>  
> +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>  
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -527,8 +529,6 @@ void gic_inject(void)
>  
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> -    else
> -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>  }
>  
>  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:32:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18: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 1XrA2u-0000ZF-RT; Wed, 19 Nov 2014 18:32:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrA2t-0000Z8-BI
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 18:32:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8A/09-09936-222EC645; Wed, 19 Nov 2014 18:32:02 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416421920!10529324!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30564 invoked from network); 19 Nov 2014 18:32:02 -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;
	19 Nov 2014 18:32:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192989003"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 13:31:07 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrA1y-0008U2-U8;
	Wed, 19 Nov 2014 18:31:06 +0000
Date: Wed, 19 Nov 2014 18:30:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141119182552.GA14861@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411191830000.12596@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411191701190.12596@kaball.uk.xensource.com>
	<20141119182552.GA14861@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xensource.com,
	andrii.tseglytskyi@globallogic.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 05:44:49PM +0000, Stefano Stabellini wrote:
> > UIE being set can cause maintenance interrupts to occur when Xen writes
> > to one or more LR registers. The effect is a busy loop around the
> > interrupt handler in Xen
> > (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> > 
> > Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> > bad side effects on any other platforms as far as I can tell. It should
> > go in 4.5.
> 
> Have you checked (aka ran the tests) on the other platforms?

Yes, I tested on Midway and it runs fine.


> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>   ^^^^^^^
>  'Reported-and-Tested-by'

Good point


> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 70d10d6..df140b9 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
> >      if ( is_idle_vcpu(v) )
> >          return;
> >  
> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> > +
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >  
> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> > @@ -527,8 +529,6 @@ void gic_inject(void)
> >  
> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> > -    else
> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >  }
> >  
> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:32:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18: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 1XrA2u-0000ZF-RT; Wed, 19 Nov 2014 18:32:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrA2t-0000Z8-BI
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 18:32:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8A/09-09936-222EC645; Wed, 19 Nov 2014 18:32:02 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416421920!10529324!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30564 invoked from network); 19 Nov 2014 18:32:02 -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;
	19 Nov 2014 18:32:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192989003"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 13:31:07 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrA1y-0008U2-U8;
	Wed, 19 Nov 2014 18:31:06 +0000
Date: Wed, 19 Nov 2014 18:30:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141119182552.GA14861@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411191830000.12596@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411191701190.12596@kaball.uk.xensource.com>
	<20141119182552.GA14861@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xensource.com,
	andrii.tseglytskyi@globallogic.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 05:44:49PM +0000, Stefano Stabellini wrote:
> > UIE being set can cause maintenance interrupts to occur when Xen writes
> > to one or more LR registers. The effect is a busy loop around the
> > interrupt handler in Xen
> > (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> > 
> > Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> > bad side effects on any other platforms as far as I can tell. It should
> > go in 4.5.
> 
> Have you checked (aka ran the tests) on the other platforms?

Yes, I tested on Midway and it runs fine.


> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>   ^^^^^^^
>  'Reported-and-Tested-by'

Good point


> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 70d10d6..df140b9 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
> >      if ( is_idle_vcpu(v) )
> >          return;
> >  
> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> > +
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >  
> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> > @@ -527,8 +529,6 @@ void gic_inject(void)
> >  
> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> > -    else
> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >  }
> >  
> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:32:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18: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 1XrA37-0000ad-7r; Wed, 19 Nov 2014 18:32:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrA35-0000a9-Qk
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 18:32:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	35/39-09936-E22EC645; Wed, 19 Nov 2014 18:32:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416421932!5942081!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29221 invoked from network); 19 Nov 2014 18:32:14 -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;
	19 Nov 2014 18:32:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192989131"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 13:31:27 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrA2I-0008UB-W5;
	Wed, 19 Nov 2014 18:31:26 +0000
Date: Wed, 19 Nov 2014 18:31:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <546CE0BD.6010102@linaro.org>
Message-ID: <alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Julien Grall wrote:
> On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > That's right, the maintenance interrupt handler is not called, but it
> > doesn't do anything so we are fine. The important thing is that an
> > interrupt is sent and git_clear_lrs gets called on hypervisor entry.
> 
> It would be worth to write down this somewhere. Just in case someone
> decide to add code in maintenance interrupt later.

Yes, I could add a comment in the handler

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:32:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18: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 1XrA37-0000ad-7r; Wed, 19 Nov 2014 18:32:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrA35-0000a9-Qk
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 18:32:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	35/39-09936-E22EC645; Wed, 19 Nov 2014 18:32:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416421932!5942081!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29221 invoked from network); 19 Nov 2014 18:32:14 -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;
	19 Nov 2014 18:32:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="192989131"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 13:31:27 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrA2I-0008UB-W5;
	Wed, 19 Nov 2014 18:31:26 +0000
Date: Wed, 19 Nov 2014 18:31:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <546CE0BD.6010102@linaro.org>
Message-ID: <alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Julien Grall wrote:
> On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > That's right, the maintenance interrupt handler is not called, but it
> > doesn't do anything so we are fine. The important thing is that an
> > interrupt is sent and git_clear_lrs gets called on hypervisor entry.
> 
> It would be worth to write down this somewhere. Just in case someone
> decide to add code in maintenance interrupt later.

Yes, I could add a comment in the handler

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:55:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18:55:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrAOq-00015l-80; Wed, 19 Nov 2014 18:54:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XrAOo-00015c-RQ
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 18:54:43 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	3D/03-02957-277EC645; Wed, 19 Nov 2014 18:54:42 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416423281!13586088!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31197 invoked from network); 19 Nov 2014 18:54:41 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 19 Nov 2014 18:54:41 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50113 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XrANE-0004AH-F3; Wed, 19 Nov 2014 19:53:04 +0100
Date: Wed, 19 Nov 2014 19:54:39 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <118231163.20141119195439@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
References: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xenproject.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v1 for-xen-4.5] Fix list corruption in
	dpci_softirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, November 19, 2014, 6:31:39 PM, you wrote:

> Hey,

> This patch should fix the issue that Sander had seen. The full details
> are in the patch itself. Sander, if you could - please test origin/staging
> with this patch to make sure it does fix the issue.


>  xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------

> Konrad Rzeszutek Wilk (1):
>       dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked.

>  1 file changed, 17 insertions(+), 10 deletions(-)


Hi Konrad,

Hmm just tested with a freshly cloned tree .. unfortunately it blew up again.
(i must admit i also re-enabled stuff i had disabled in debugging like, cpuidle, cpufreq). 

(XEN) [2014-11-19 18:41:25.999] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) [2014-11-19 18:41:25.999] CPU:    5
(XEN) [2014-11-19 18:41:25.999] RIP:    e008:[<ffff82d0801490ac>] dpci_softirq+0x9c/0x23d
(XEN) [2014-11-19 18:41:25.999] RFLAGS: 0000000000010283   CONTEXT: hypervisor
(XEN) [2014-11-19 18:41:25.999] rax: 0100100100100100   rbx: ffff8303bb688d90   rcx: 0000000000000001
(XEN) [2014-11-19 18:41:25.999] rdx: ffff83054ef18000   rsi: 0000000000000002   rdi: ffff83050b29e0b8
(XEN) [2014-11-19 18:41:25.999] rbp: ffff83054ef1feb0   rsp: ffff83054ef1fe50   r8:  ffff8303bb688d60
(XEN) [2014-11-19 18:41:25.999] r9:  000001d5f62fff63   r10: 00000000deadbeef   r11: 0000000000000246
(XEN) [2014-11-19 18:41:25.999] r12: ffff8303bb688d38   r13: ffff83050b29e000   r14: ffff8303bb688d28
(XEN) [2014-11-19 18:41:25.999] r15: ffff8303bb688d28   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2014-11-19 18:41:25.999] cr3: 000000050b2c7000   cr2: ffffffffff600400
(XEN) [2014-11-19 18:41:25.999] ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) [2014-11-19 18:41:25.999] Xen stack trace from rsp=ffff83054ef1fe50:
(XEN) [2014-11-19 18:41:25.999]    0000000000000c23 ffff83050b29e0b8 ffff8303bb688d38 ffff83054ef1fe70
(XEN) [2014-11-19 18:41:25.999]    ffff8303bb688d90 ffff8303bb688d90 000000fb00000000 ffff82d080300200
(XEN) [2014-11-19 18:41:25.999]    ffff82d0802fff80 ffffffffffffffff ffff83054ef18000 0000000000000002
(XEN) [2014-11-19 18:41:25.999]    ffff83054ef1fee0 ffff82d08012be31 ffff83054ef18000 ffff83009fd2d000
(XEN) [2014-11-19 18:41:25.999]    00000000ffffffff ffff83054ef28068 ffff83054ef1fef0 ffff82d08012be89
(XEN) [2014-11-19 18:41:25.999]    ffff83054ef1ff10 ffff82d0801633e5 ffff82d08012be89 ffff83009ff8b000
(XEN) [2014-11-19 18:41:25.999]    ffff83054ef1fde8 ffff880059bf8000 ffff880059bf8000 0000000000000000
(XEN) [2014-11-19 18:41:25.999]    0000000000000000 ffff880059bfbeb0 ffffffff822f3ec0 0000000000000246
(XEN) [2014-11-19 18:41:25.999]    0000000000000001 0000000000000000 0000000000000000 0000000000000000
(XEN) [2014-11-19 18:41:25.999]    ffffffff810013aa ffff880059bde480 00000000deadbeef 00000000deadbeef
(XEN) [2014-11-19 18:41:25.999]    0000010000000000 ffffffff810013aa 000000000000e033 0000000000000246
(XEN) [2014-11-19 18:41:25.999]    ffff880059bfbe98 000000000000e02b 1862060042c8beef 224d41480704beef
(XEN) [2014-11-19 18:41:25.999]    99171042639bbeef 74c88180108cbeef c0dc604c00000005 ffff83009ff8b000
(XEN) [2014-11-19 18:41:26.000]    00000034cebff280 ca836183a4020303
(XEN) [2014-11-19 18:41:26.000] Xen call trace:
(XEN) [2014-11-19 18:41:26.000]    [<ffff82d0801490ac>] dpci_softirq+0x9c/0x23d
(XEN) [2014-11-19 18:41:26.000]    [<ffff82d08012be31>] __do_softirq+0x81/0x8c
(XEN) [2014-11-19 18:41:26.000]    [<ffff82d08012be89>] do_softirq+0x13/0x15
(XEN) [2014-11-19 18:41:26.000]    [<ffff82d0801633e5>] idle_loop+0x5e/0x6e
(XEN) [2014-11-19 18:41:26.000] 
(XEN) [2014-11-19 18:41:26.778] 
(XEN) [2014-11-19 18:41:26.787] ****************************************
(XEN) [2014-11-19 18:41:26.806] Panic on CPU 5:
(XEN) [2014-11-19 18:41:26.819] GENERAL PROTECTION FAULT
(XEN) [2014-11-19 18:41:26.834] [error_code=0000]
(XEN) [2014-11-19 18:41:26.847] ****************************************
(XEN) [2014-11-19 18:41:26.867] 
(XEN) [2014-11-19 18:41:26.876] Reboot in five seconds...
(XEN) [2014-11-19 18:41:26.891] APIC error on CPU0: 00(08)
(XEN) [2014-11-19 18:41:26.906] APIC error on CPU0: 08(08)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 18:55:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 18:55:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrAOq-00015l-80; Wed, 19 Nov 2014 18:54:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XrAOo-00015c-RQ
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 18:54:43 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	3D/03-02957-277EC645; Wed, 19 Nov 2014 18:54:42 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416423281!13586088!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31197 invoked from network); 19 Nov 2014 18:54:41 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 19 Nov 2014 18:54:41 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50113 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XrANE-0004AH-F3; Wed, 19 Nov 2014 19:53:04 +0100
Date: Wed, 19 Nov 2014 19:54:39 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <118231163.20141119195439@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
References: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xenproject.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v1 for-xen-4.5] Fix list corruption in
	dpci_softirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, November 19, 2014, 6:31:39 PM, you wrote:

> Hey,

> This patch should fix the issue that Sander had seen. The full details
> are in the patch itself. Sander, if you could - please test origin/staging
> with this patch to make sure it does fix the issue.


>  xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------

> Konrad Rzeszutek Wilk (1):
>       dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked.

>  1 file changed, 17 insertions(+), 10 deletions(-)


Hi Konrad,

Hmm just tested with a freshly cloned tree .. unfortunately it blew up again.
(i must admit i also re-enabled stuff i had disabled in debugging like, cpuidle, cpufreq). 

(XEN) [2014-11-19 18:41:25.999] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) [2014-11-19 18:41:25.999] CPU:    5
(XEN) [2014-11-19 18:41:25.999] RIP:    e008:[<ffff82d0801490ac>] dpci_softirq+0x9c/0x23d
(XEN) [2014-11-19 18:41:25.999] RFLAGS: 0000000000010283   CONTEXT: hypervisor
(XEN) [2014-11-19 18:41:25.999] rax: 0100100100100100   rbx: ffff8303bb688d90   rcx: 0000000000000001
(XEN) [2014-11-19 18:41:25.999] rdx: ffff83054ef18000   rsi: 0000000000000002   rdi: ffff83050b29e0b8
(XEN) [2014-11-19 18:41:25.999] rbp: ffff83054ef1feb0   rsp: ffff83054ef1fe50   r8:  ffff8303bb688d60
(XEN) [2014-11-19 18:41:25.999] r9:  000001d5f62fff63   r10: 00000000deadbeef   r11: 0000000000000246
(XEN) [2014-11-19 18:41:25.999] r12: ffff8303bb688d38   r13: ffff83050b29e000   r14: ffff8303bb688d28
(XEN) [2014-11-19 18:41:25.999] r15: ffff8303bb688d28   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2014-11-19 18:41:25.999] cr3: 000000050b2c7000   cr2: ffffffffff600400
(XEN) [2014-11-19 18:41:25.999] ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) [2014-11-19 18:41:25.999] Xen stack trace from rsp=ffff83054ef1fe50:
(XEN) [2014-11-19 18:41:25.999]    0000000000000c23 ffff83050b29e0b8 ffff8303bb688d38 ffff83054ef1fe70
(XEN) [2014-11-19 18:41:25.999]    ffff8303bb688d90 ffff8303bb688d90 000000fb00000000 ffff82d080300200
(XEN) [2014-11-19 18:41:25.999]    ffff82d0802fff80 ffffffffffffffff ffff83054ef18000 0000000000000002
(XEN) [2014-11-19 18:41:25.999]    ffff83054ef1fee0 ffff82d08012be31 ffff83054ef18000 ffff83009fd2d000
(XEN) [2014-11-19 18:41:25.999]    00000000ffffffff ffff83054ef28068 ffff83054ef1fef0 ffff82d08012be89
(XEN) [2014-11-19 18:41:25.999]    ffff83054ef1ff10 ffff82d0801633e5 ffff82d08012be89 ffff83009ff8b000
(XEN) [2014-11-19 18:41:25.999]    ffff83054ef1fde8 ffff880059bf8000 ffff880059bf8000 0000000000000000
(XEN) [2014-11-19 18:41:25.999]    0000000000000000 ffff880059bfbeb0 ffffffff822f3ec0 0000000000000246
(XEN) [2014-11-19 18:41:25.999]    0000000000000001 0000000000000000 0000000000000000 0000000000000000
(XEN) [2014-11-19 18:41:25.999]    ffffffff810013aa ffff880059bde480 00000000deadbeef 00000000deadbeef
(XEN) [2014-11-19 18:41:25.999]    0000010000000000 ffffffff810013aa 000000000000e033 0000000000000246
(XEN) [2014-11-19 18:41:25.999]    ffff880059bfbe98 000000000000e02b 1862060042c8beef 224d41480704beef
(XEN) [2014-11-19 18:41:25.999]    99171042639bbeef 74c88180108cbeef c0dc604c00000005 ffff83009ff8b000
(XEN) [2014-11-19 18:41:26.000]    00000034cebff280 ca836183a4020303
(XEN) [2014-11-19 18:41:26.000] Xen call trace:
(XEN) [2014-11-19 18:41:26.000]    [<ffff82d0801490ac>] dpci_softirq+0x9c/0x23d
(XEN) [2014-11-19 18:41:26.000]    [<ffff82d08012be31>] __do_softirq+0x81/0x8c
(XEN) [2014-11-19 18:41:26.000]    [<ffff82d08012be89>] do_softirq+0x13/0x15
(XEN) [2014-11-19 18:41:26.000]    [<ffff82d0801633e5>] idle_loop+0x5e/0x6e
(XEN) [2014-11-19 18:41:26.000] 
(XEN) [2014-11-19 18:41:26.778] 
(XEN) [2014-11-19 18:41:26.787] ****************************************
(XEN) [2014-11-19 18:41:26.806] Panic on CPU 5:
(XEN) [2014-11-19 18:41:26.819] GENERAL PROTECTION FAULT
(XEN) [2014-11-19 18:41:26.834] [error_code=0000]
(XEN) [2014-11-19 18:41:26.847] ****************************************
(XEN) [2014-11-19 18:41:26.867] 
(XEN) [2014-11-19 18:41:26.876] Reboot in five seconds...
(XEN) [2014-11-19 18:41:26.891] APIC error on CPU0: 00(08)
(XEN) [2014-11-19 18:41:26.906] APIC error on CPU0: 08(08)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:23:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:23:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrApy-0001wg-7G; Wed, 19 Nov 2014 19:22:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XrApw-0001wZ-C6
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 19:22:44 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	0F/AF-02702-30EEC645; Wed, 19 Nov 2014 19:22:43 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416424962!13589851!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4371 invoked from network); 19 Nov 2014 19:22:43 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 19:22:43 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-31-199-23.oxfd.adsl.virginm.net ([86.31.199.23]:51432
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XrApr-00029L-FQ (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Wed, 19 Nov 2014 19:22:41 +0000
Message-ID: <546CEE00.4010303@citrix.com>
Date: Wed, 19 Nov 2014 19:22:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
	<118231163.20141119195439@eikelenboom.it>
In-Reply-To: <118231163.20141119195439@eikelenboom.it>
Cc: xen-devel@lists.xenproject.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v1 for-xen-4.5] Fix list corruption in
	dpci_softirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/2014 18:54, Sander Eikelenboom wrote:
> Wednesday, November 19, 2014, 6:31:39 PM, you wrote:
>
>> Hey,
>> This patch should fix the issue that Sander had seen. The full details
>> are in the patch itself. Sander, if you could - please test origin/staging
>> with this patch to make sure it does fix the issue.
>
>>  xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------
>> Konrad Rzeszutek Wilk (1):
>>       dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked.
>>  1 file changed, 17 insertions(+), 10 deletions(-)
>
> Hi Konrad,
>
> Hmm just tested with a freshly cloned tree .. unfortunately it blew up again.
> (i must admit i also re-enabled stuff i had disabled in debugging like, cpuidle, cpufreq). 
>
> (XEN) [2014-11-19 18:41:25.999] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> (XEN) [2014-11-19 18:41:25.999] CPU:    5
> (XEN) [2014-11-19 18:41:25.999] RIP:    e008:[<ffff82d0801490ac>] dpci_softirq+0x9c/0x23d
> (XEN) [2014-11-19 18:41:25.999] RFLAGS: 0000000000010283   CONTEXT: hypervisor
> (XEN) [2014-11-19 18:41:25.999] rax: 0100100100100100   rbx: ffff8303bb688d90   rcx: 0000000000000001
> (XEN) [2014-11-19 18:41:25.999] rdx: ffff83054ef18000   rsi: 0000000000000002   rdi: ffff83050b29e0b8
> (XEN) [2014-11-19 18:41:25.999] rbp: ffff83054ef1feb0   rsp: ffff83054ef1fe50   r8:  ffff8303bb688d60
> (XEN) [2014-11-19 18:41:25.999] r9:  000001d5f62fff63   r10: 00000000deadbeef   r11: 0000000000000246
> (XEN) [2014-11-19 18:41:25.999] r12: ffff8303bb688d38   r13: ffff83050b29e000   r14: ffff8303bb688d28
> (XEN) [2014-11-19 18:41:25.999] r15: ffff8303bb688d28   cr0: 000000008005003b   cr4: 00000000000006f0
> (XEN) [2014-11-19 18:41:25.999] cr3: 000000050b2c7000   cr2: ffffffffff600400
> (XEN) [2014-11-19 18:41:25.999] ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) [2014-11-19 18:41:25.999] Xen stack trace from rsp=ffff83054ef1fe50:
> (XEN) [2014-11-19 18:41:25.999]    0000000000000c23 ffff83050b29e0b8 ffff8303bb688d38 ffff83054ef1fe70
> (XEN) [2014-11-19 18:41:25.999]    ffff8303bb688d90 ffff8303bb688d90 000000fb00000000 ffff82d080300200
> (XEN) [2014-11-19 18:41:25.999]    ffff82d0802fff80 ffffffffffffffff ffff83054ef18000 0000000000000002
> (XEN) [2014-11-19 18:41:25.999]    ffff83054ef1fee0 ffff82d08012be31 ffff83054ef18000 ffff83009fd2d000
> (XEN) [2014-11-19 18:41:25.999]    00000000ffffffff ffff83054ef28068 ffff83054ef1fef0 ffff82d08012be89
> (XEN) [2014-11-19 18:41:25.999]    ffff83054ef1ff10 ffff82d0801633e5 ffff82d08012be89 ffff83009ff8b000
> (XEN) [2014-11-19 18:41:25.999]    ffff83054ef1fde8 ffff880059bf8000 ffff880059bf8000 0000000000000000
> (XEN) [2014-11-19 18:41:25.999]    0000000000000000 ffff880059bfbeb0 ffffffff822f3ec0 0000000000000246
> (XEN) [2014-11-19 18:41:25.999]    0000000000000001 0000000000000000 0000000000000000 0000000000000000
> (XEN) [2014-11-19 18:41:25.999]    ffffffff810013aa ffff880059bde480 00000000deadbeef 00000000deadbeef
> (XEN) [2014-11-19 18:41:25.999]    0000010000000000 ffffffff810013aa 000000000000e033 0000000000000246
> (XEN) [2014-11-19 18:41:25.999]    ffff880059bfbe98 000000000000e02b 1862060042c8beef 224d41480704beef
> (XEN) [2014-11-19 18:41:25.999]    99171042639bbeef 74c88180108cbeef c0dc604c00000005 ffff83009ff8b000
> (XEN) [2014-11-19 18:41:26.000]    00000034cebff280 ca836183a4020303
> (XEN) [2014-11-19 18:41:26.000] Xen call trace:
> (XEN) [2014-11-19 18:41:26.000]    [<ffff82d0801490ac>] dpci_softirq+0x9c/0x23d
> (XEN) [2014-11-19 18:41:26.000]    [<ffff82d08012be31>] __do_softirq+0x81/0x8c
> (XEN) [2014-11-19 18:41:26.000]    [<ffff82d08012be89>] do_softirq+0x13/0x15
> (XEN) [2014-11-19 18:41:26.000]    [<ffff82d0801633e5>] idle_loop+0x5e/0x6e
> (XEN) [2014-11-19 18:41:26.000] 
> (XEN) [2014-11-19 18:41:26.778] 
> (XEN) [2014-11-19 18:41:26.787] ****************************************
> (XEN) [2014-11-19 18:41:26.806] Panic on CPU 5:
> (XEN) [2014-11-19 18:41:26.819] GENERAL PROTECTION FAULT
> (XEN) [2014-11-19 18:41:26.834] [error_code=0000]
> (XEN) [2014-11-19 18:41:26.847] ****************************************
> (XEN) [2014-11-19 18:41:26.867] 
> (XEN) [2014-11-19 18:41:26.876] Reboot in five seconds...
> (XEN) [2014-11-19 18:41:26.891] APIC error on CPU0: 00(08)
> (XEN) [2014-11-19 18:41:26.906] APIC error on CPU0: 08(08)

For the avoidance of any confusion, this is still LIST_POISON1 (see
%rax), but now a #GP fault following c/s 404227138 (now with 100% less
chance of dereferencing into guest-controlled virtual address space)

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:23:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:23:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrApy-0001wg-7G; Wed, 19 Nov 2014 19:22:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XrApw-0001wZ-C6
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 19:22:44 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	0F/AF-02702-30EEC645; Wed, 19 Nov 2014 19:22:43 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416424962!13589851!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4371 invoked from network); 19 Nov 2014 19:22:43 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 19:22:43 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-31-199-23.oxfd.adsl.virginm.net ([86.31.199.23]:51432
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XrApr-00029L-FQ (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Wed, 19 Nov 2014 19:22:41 +0000
Message-ID: <546CEE00.4010303@citrix.com>
Date: Wed, 19 Nov 2014 19:22:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
	<118231163.20141119195439@eikelenboom.it>
In-Reply-To: <118231163.20141119195439@eikelenboom.it>
Cc: xen-devel@lists.xenproject.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v1 for-xen-4.5] Fix list corruption in
	dpci_softirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/2014 18:54, Sander Eikelenboom wrote:
> Wednesday, November 19, 2014, 6:31:39 PM, you wrote:
>
>> Hey,
>> This patch should fix the issue that Sander had seen. The full details
>> are in the patch itself. Sander, if you could - please test origin/staging
>> with this patch to make sure it does fix the issue.
>
>>  xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------
>> Konrad Rzeszutek Wilk (1):
>>       dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked.
>>  1 file changed, 17 insertions(+), 10 deletions(-)
>
> Hi Konrad,
>
> Hmm just tested with a freshly cloned tree .. unfortunately it blew up again.
> (i must admit i also re-enabled stuff i had disabled in debugging like, cpuidle, cpufreq). 
>
> (XEN) [2014-11-19 18:41:25.999] ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
> (XEN) [2014-11-19 18:41:25.999] CPU:    5
> (XEN) [2014-11-19 18:41:25.999] RIP:    e008:[<ffff82d0801490ac>] dpci_softirq+0x9c/0x23d
> (XEN) [2014-11-19 18:41:25.999] RFLAGS: 0000000000010283   CONTEXT: hypervisor
> (XEN) [2014-11-19 18:41:25.999] rax: 0100100100100100   rbx: ffff8303bb688d90   rcx: 0000000000000001
> (XEN) [2014-11-19 18:41:25.999] rdx: ffff83054ef18000   rsi: 0000000000000002   rdi: ffff83050b29e0b8
> (XEN) [2014-11-19 18:41:25.999] rbp: ffff83054ef1feb0   rsp: ffff83054ef1fe50   r8:  ffff8303bb688d60
> (XEN) [2014-11-19 18:41:25.999] r9:  000001d5f62fff63   r10: 00000000deadbeef   r11: 0000000000000246
> (XEN) [2014-11-19 18:41:25.999] r12: ffff8303bb688d38   r13: ffff83050b29e000   r14: ffff8303bb688d28
> (XEN) [2014-11-19 18:41:25.999] r15: ffff8303bb688d28   cr0: 000000008005003b   cr4: 00000000000006f0
> (XEN) [2014-11-19 18:41:25.999] cr3: 000000050b2c7000   cr2: ffffffffff600400
> (XEN) [2014-11-19 18:41:25.999] ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) [2014-11-19 18:41:25.999] Xen stack trace from rsp=ffff83054ef1fe50:
> (XEN) [2014-11-19 18:41:25.999]    0000000000000c23 ffff83050b29e0b8 ffff8303bb688d38 ffff83054ef1fe70
> (XEN) [2014-11-19 18:41:25.999]    ffff8303bb688d90 ffff8303bb688d90 000000fb00000000 ffff82d080300200
> (XEN) [2014-11-19 18:41:25.999]    ffff82d0802fff80 ffffffffffffffff ffff83054ef18000 0000000000000002
> (XEN) [2014-11-19 18:41:25.999]    ffff83054ef1fee0 ffff82d08012be31 ffff83054ef18000 ffff83009fd2d000
> (XEN) [2014-11-19 18:41:25.999]    00000000ffffffff ffff83054ef28068 ffff83054ef1fef0 ffff82d08012be89
> (XEN) [2014-11-19 18:41:25.999]    ffff83054ef1ff10 ffff82d0801633e5 ffff82d08012be89 ffff83009ff8b000
> (XEN) [2014-11-19 18:41:25.999]    ffff83054ef1fde8 ffff880059bf8000 ffff880059bf8000 0000000000000000
> (XEN) [2014-11-19 18:41:25.999]    0000000000000000 ffff880059bfbeb0 ffffffff822f3ec0 0000000000000246
> (XEN) [2014-11-19 18:41:25.999]    0000000000000001 0000000000000000 0000000000000000 0000000000000000
> (XEN) [2014-11-19 18:41:25.999]    ffffffff810013aa ffff880059bde480 00000000deadbeef 00000000deadbeef
> (XEN) [2014-11-19 18:41:25.999]    0000010000000000 ffffffff810013aa 000000000000e033 0000000000000246
> (XEN) [2014-11-19 18:41:25.999]    ffff880059bfbe98 000000000000e02b 1862060042c8beef 224d41480704beef
> (XEN) [2014-11-19 18:41:25.999]    99171042639bbeef 74c88180108cbeef c0dc604c00000005 ffff83009ff8b000
> (XEN) [2014-11-19 18:41:26.000]    00000034cebff280 ca836183a4020303
> (XEN) [2014-11-19 18:41:26.000] Xen call trace:
> (XEN) [2014-11-19 18:41:26.000]    [<ffff82d0801490ac>] dpci_softirq+0x9c/0x23d
> (XEN) [2014-11-19 18:41:26.000]    [<ffff82d08012be31>] __do_softirq+0x81/0x8c
> (XEN) [2014-11-19 18:41:26.000]    [<ffff82d08012be89>] do_softirq+0x13/0x15
> (XEN) [2014-11-19 18:41:26.000]    [<ffff82d0801633e5>] idle_loop+0x5e/0x6e
> (XEN) [2014-11-19 18:41:26.000] 
> (XEN) [2014-11-19 18:41:26.778] 
> (XEN) [2014-11-19 18:41:26.787] ****************************************
> (XEN) [2014-11-19 18:41:26.806] Panic on CPU 5:
> (XEN) [2014-11-19 18:41:26.819] GENERAL PROTECTION FAULT
> (XEN) [2014-11-19 18:41:26.834] [error_code=0000]
> (XEN) [2014-11-19 18:41:26.847] ****************************************
> (XEN) [2014-11-19 18:41:26.867] 
> (XEN) [2014-11-19 18:41:26.876] Reboot in five seconds...
> (XEN) [2014-11-19 18:41:26.891] APIC error on CPU0: 00(08)
> (XEN) [2014-11-19 18:41:26.906] APIC error on CPU0: 08(08)

For the avoidance of any confusion, this is still LIST_POISON1 (see
%rax), but now a #GP fault following c/s 404227138 (now with 100% less
chance of dereferencing into guest-controlled virtual address space)

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:24:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrAra-00022u-0j; Wed, 19 Nov 2014 19:24:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XrArY-00022g-Ea
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 19:24:24 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EB/CD-25276-76EEC645; Wed, 19 Nov 2014 19:24:23 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416425061!13638522!1
X-Originating-IP: [64.18.0.245]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12926 invoked from network); 19 Nov 2014 19:24:22 -0000
Received: from exprod5og125.obsmtp.com (HELO exprod5og125.obsmtp.com)
	(64.18.0.245)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 19:24:22 -0000
Received: from mail-qg0-f51.google.com ([209.85.192.51]) (using TLSv1) by
	exprod5ob125.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzuZN3IlG9opc4WAV0pmTGuYdIyAMyb@postini.com;
	Wed, 19 Nov 2014 11:24:22 PST
Received: by mail-qg0-f51.google.com with SMTP id l89so975267qgf.10
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 11:24:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ZOre8sqPlS6tZu0tkZm8PGatuz08IQeiczirBjqrDos=;
	b=OGSFwlmNxyXzz/PYEmLONKLeLYbZNikUbyjXcDLm4s4GiuosScg++74lssiZnY25Q9
	uzH82ChTCP6HfXB2F5r/E+YPwR5LcOk++8TSLPR9ZA1ICbl0zS8ifW5sed2Gvfy06ba7
	jVlgY0TWb/ec37DqKYXOCfVclw4cRuhUhhxw0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=ZOre8sqPlS6tZu0tkZm8PGatuz08IQeiczirBjqrDos=;
	b=R9uG67bmIOwHGmqAFAR0i4n+p5xh3iEBJYOG8cGnN6hNpLUPXV8fTnoPcnCEz9CVY3
	cyervFBSFhvZOCA6GsJvSIH3j3skRrisCGUtiQWcarTowukMnSe7fPPjdddFYvMNtdbx
	SkZUCcDat43bVT4vOzZ4y+m3LZ4mRnJjpwsHE0LnZaQFxnmoXJE23pb8unnJ9S9T83lV
	3iQUAdGsjVHFCC+MV/NoowOvHkEaYG+uYos1/W4oIfAM04yMaZ4oM0A973ycAkigJAnw
	w1cWmfhbH+MPbp9Xkc8KFVoUdLWEC/RhgfTkUYM+duadaOTWWWtjk6IKerNxkrdJkik5
	JbpA==
X-Received: by 10.224.28.193 with SMTP id n1mr54337300qac.93.1416425060469;
	Wed, 19 Nov 2014 11:24:20 -0800 (PST)
X-Gm-Message-State: ALoCoQmXJNpyHvbE2DR5l9h4XGgytdb790vH9+CA/EzQnd+PcGJKenMqLgxi0hQ/lHMNjVuDJT4WqAMtIjirPjeLrUTZN7HcGE4NKM/zr+GFBrjWznTFRrGNG4NZkXgyguQMWl2BcxcaiK51rrB6MbW2A2yrLqokdQ==
MIME-Version: 1.0
X-Received: by 10.224.28.193 with SMTP id n1mr54337290qac.93.1416425060374;
	Wed, 19 Nov 2014 11:24:20 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 11:24:20 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 11:24:20 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 21:24:20 +0200
Message-ID: <CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6582875891437687041=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6582875891437687041==
Content-Type: multipart/alternative; boundary=001a11c2ca309336e805083b28a8

--001a11c2ca309336e805083b28a8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=80=D0=B8=D1=81=D1=
=82=D1=83=D0=B2=D0=B0=D1=87 "Stefano Stabellini" <
stefano.stabellini@eu.citrix.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=
=B2:
>
> On Wed, 19 Nov 2014, Julien Grall wrote:
> > On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > > That's right, the maintenance interrupt handler is not called, but it
> > > doesn't do anything so we are fine. The important thing is that an
> > > interrupt is sent and git_clear_lrs gets called on hypervisor entry.
> >
> > It would be worth to write down this somewhere. Just in case someone
> > decide to add code in maintenance interrupt later.
>
> Yes, I could add a comment in the handler

Maybe it wouldn't take a lot of effort to fix it? I am just worrying that
we may hide some issue - typically spurious interrupt this not what is
expected.

--001a11c2ca309336e805083b28a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=80=D0=B8=D1=81=D1=
=82=D1=83=D0=B2=D0=B0=D1=87 &quot;Stefano Stabellini&quot; &lt;<a href=3D"m=
ailto:stefano.stabellini@eu.citrix.com">stefano.stabellini@eu.citrix.com</a=
>&gt; =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:<br>
&gt;<br>
&gt; On Wed, 19 Nov 2014, Julien Grall wrote:<br>
&gt; &gt; On 11/19/2014 06:14 PM, Stefano Stabellini wrote:<br>
&gt; &gt; &gt; That&#39;s right, the maintenance interrupt handler is not c=
alled, but it<br>
&gt; &gt; &gt; doesn&#39;t do anything so we are fine. The important thing =
is that an<br>
&gt; &gt; &gt; interrupt is sent and git_clear_lrs gets called on hyperviso=
r entry.<br>
&gt; &gt;<br>
&gt; &gt; It would be worth to write down this somewhere. Just in case some=
one<br>
&gt; &gt; decide to add code in maintenance interrupt later.<br>
&gt;<br>
&gt; Yes, I could add a comment in the handler</p>
<p dir=3D"ltr">Maybe it wouldn&#39;t take a lot of effort to fix it? I am j=
ust worrying that we may hide some issue - typically spurious interrupt thi=
s not what is expected.<br>
</p>

--001a11c2ca309336e805083b28a8--


--===============6582875891437687041==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6582875891437687041==--


From xen-devel-bounces@lists.xen.org Wed Nov 19 19:24:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrAra-00022u-0j; Wed, 19 Nov 2014 19:24:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XrArY-00022g-Ea
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 19:24:24 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EB/CD-25276-76EEC645; Wed, 19 Nov 2014 19:24:23 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416425061!13638522!1
X-Originating-IP: [64.18.0.245]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12926 invoked from network); 19 Nov 2014 19:24:22 -0000
Received: from exprod5og125.obsmtp.com (HELO exprod5og125.obsmtp.com)
	(64.18.0.245)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 19:24:22 -0000
Received: from mail-qg0-f51.google.com ([209.85.192.51]) (using TLSv1) by
	exprod5ob125.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVGzuZN3IlG9opc4WAV0pmTGuYdIyAMyb@postini.com;
	Wed, 19 Nov 2014 11:24:22 PST
Received: by mail-qg0-f51.google.com with SMTP id l89so975267qgf.10
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 11:24:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ZOre8sqPlS6tZu0tkZm8PGatuz08IQeiczirBjqrDos=;
	b=OGSFwlmNxyXzz/PYEmLONKLeLYbZNikUbyjXcDLm4s4GiuosScg++74lssiZnY25Q9
	uzH82ChTCP6HfXB2F5r/E+YPwR5LcOk++8TSLPR9ZA1ICbl0zS8ifW5sed2Gvfy06ba7
	jVlgY0TWb/ec37DqKYXOCfVclw4cRuhUhhxw0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=ZOre8sqPlS6tZu0tkZm8PGatuz08IQeiczirBjqrDos=;
	b=R9uG67bmIOwHGmqAFAR0i4n+p5xh3iEBJYOG8cGnN6hNpLUPXV8fTnoPcnCEz9CVY3
	cyervFBSFhvZOCA6GsJvSIH3j3skRrisCGUtiQWcarTowukMnSe7fPPjdddFYvMNtdbx
	SkZUCcDat43bVT4vOzZ4y+m3LZ4mRnJjpwsHE0LnZaQFxnmoXJE23pb8unnJ9S9T83lV
	3iQUAdGsjVHFCC+MV/NoowOvHkEaYG+uYos1/W4oIfAM04yMaZ4oM0A973ycAkigJAnw
	w1cWmfhbH+MPbp9Xkc8KFVoUdLWEC/RhgfTkUYM+duadaOTWWWtjk6IKerNxkrdJkik5
	JbpA==
X-Received: by 10.224.28.193 with SMTP id n1mr54337300qac.93.1416425060469;
	Wed, 19 Nov 2014 11:24:20 -0800 (PST)
X-Gm-Message-State: ALoCoQmXJNpyHvbE2DR5l9h4XGgytdb790vH9+CA/EzQnd+PcGJKenMqLgxi0hQ/lHMNjVuDJT4WqAMtIjirPjeLrUTZN7HcGE4NKM/zr+GFBrjWznTFRrGNG4NZkXgyguQMWl2BcxcaiK51rrB6MbW2A2yrLqokdQ==
MIME-Version: 1.0
X-Received: by 10.224.28.193 with SMTP id n1mr54337290qac.93.1416425060374;
	Wed, 19 Nov 2014 11:24:20 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 11:24:20 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Wed, 19 Nov 2014 11:24:20 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191537340.12596@kaball.uk.xensource.com>
	<CAH_mUMM2s=5k930J=2_kZoBvr4u89abmk2jiqVUfKK2t66wdeA@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
Date: Wed, 19 Nov 2014 21:24:20 +0200
Message-ID: <CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6582875891437687041=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6582875891437687041==
Content-Type: multipart/alternative; boundary=001a11c2ca309336e805083b28a8

--001a11c2ca309336e805083b28a8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=80=D0=B8=D1=81=D1=
=82=D1=83=D0=B2=D0=B0=D1=87 "Stefano Stabellini" <
stefano.stabellini@eu.citrix.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=
=B2:
>
> On Wed, 19 Nov 2014, Julien Grall wrote:
> > On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > > That's right, the maintenance interrupt handler is not called, but it
> > > doesn't do anything so we are fine. The important thing is that an
> > > interrupt is sent and git_clear_lrs gets called on hypervisor entry.
> >
> > It would be worth to write down this somewhere. Just in case someone
> > decide to add code in maintenance interrupt later.
>
> Yes, I could add a comment in the handler

Maybe it wouldn't take a lot of effort to fix it? I am just worrying that
we may hide some issue - typically spurious interrupt this not what is
expected.

--001a11c2ca309336e805083b28a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=80=D0=B8=D1=81=D1=
=82=D1=83=D0=B2=D0=B0=D1=87 &quot;Stefano Stabellini&quot; &lt;<a href=3D"m=
ailto:stefano.stabellini@eu.citrix.com">stefano.stabellini@eu.citrix.com</a=
>&gt; =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:<br>
&gt;<br>
&gt; On Wed, 19 Nov 2014, Julien Grall wrote:<br>
&gt; &gt; On 11/19/2014 06:14 PM, Stefano Stabellini wrote:<br>
&gt; &gt; &gt; That&#39;s right, the maintenance interrupt handler is not c=
alled, but it<br>
&gt; &gt; &gt; doesn&#39;t do anything so we are fine. The important thing =
is that an<br>
&gt; &gt; &gt; interrupt is sent and git_clear_lrs gets called on hyperviso=
r entry.<br>
&gt; &gt;<br>
&gt; &gt; It would be worth to write down this somewhere. Just in case some=
one<br>
&gt; &gt; decide to add code in maintenance interrupt later.<br>
&gt;<br>
&gt; Yes, I could add a comment in the handler</p>
<p dir=3D"ltr">Maybe it wouldn&#39;t take a lot of effort to fix it? I am j=
ust worrying that we may hide some issue - typically spurious interrupt thi=
s not what is expected.<br>
</p>

--001a11c2ca309336e805083b28a8--


--===============6582875891437687041==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6582875891437687041==--


From xen-devel-bounces@lists.xen.org Wed Nov 19 19:25:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19: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 1XrAsb-000289-FL; Wed, 19 Nov 2014 19:25:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrAsZ-00027x-R4
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 19:25:28 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	73/A5-28296-7AEEC645; Wed, 19 Nov 2014 19:25:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416425123!12398113!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2869 invoked from network); 19 Nov 2014 19:25:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 19:25:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="193011922"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 19 Nov 2014 14:25:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrAsS-0004HZ-O8;
	Wed, 19 Nov 2014 19:25:20 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrAsS-0007wZ-Es;
	Wed, 19 Nov 2014 19:25:20 +0000
Date: Wed, 19 Nov 2014 19:25:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31670-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31670: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31670 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31670/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 31536

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  82fa0623454a52c7d1812a9419c4cc09567d243d
baseline version:
 xen                  d6281e354393f1c8a02fac55f4f611b4d4856303

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 82fa0623454a52c7d1812a9419c4cc09567d243d
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:31:21 2014 +0100

    x86emul: enforce privilege level restrictions when loading CS
    
    Privilege level checks were basically missing for the CS case, the
    only check that was done (RPL == DPL for nonconforming segments)
    was solely covering a single special case (return to non-conforming
    segment).
    
    Additionally in long mode the L bit set requires the D bit to be clear,
    as was recently pointed out for KVM by Nadav Amit
    <namit@cs.technion.ac.il>.
    
    Finally we also need to force the loaded selector's RPL to CPL (at
    least as long as lret/retf emulation doesn't support privilege level
    changes).
    
    This is CVE-2014-8595 / XSA-110.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: 1d68c1a70e00ed95ef0889cfa005379dab27b37d
    master date: 2014-11-18 14:16:23 +0100

commit c6e304d8335c9d8c447d743fd1163fbe8bccf245
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:30:37 2014 +0100

    x86: don't allow page table updates on non-PV page tables in do_mmu_update()
    
    paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
    consistently supported for non-PV guests (they'd deref NULL for PVH or
    non-HAP HVM ones). Don't allow respective MMU_* operations on the
    page tables of such domains.
    
    This is CVE-2014-8594 / XSA-109.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    master commit: e4292c5aac41b80f33d4877104348d5ee7c95aa4
    master date: 2014-11-18 14:15:21 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:25:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19: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 1XrAsb-000289-FL; Wed, 19 Nov 2014 19:25:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrAsZ-00027x-R4
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 19:25:28 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	73/A5-28296-7AEEC645; Wed, 19 Nov 2014 19:25:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416425123!12398113!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2869 invoked from network); 19 Nov 2014 19:25:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 19:25:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="193011922"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 19 Nov 2014 14:25:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrAsS-0004HZ-O8;
	Wed, 19 Nov 2014 19:25:20 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrAsS-0007wZ-Es;
	Wed, 19 Nov 2014 19:25:20 +0000
Date: Wed, 19 Nov 2014 19:25:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31670-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31670: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31670 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31670/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 31536

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  82fa0623454a52c7d1812a9419c4cc09567d243d
baseline version:
 xen                  d6281e354393f1c8a02fac55f4f611b4d4856303

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 82fa0623454a52c7d1812a9419c4cc09567d243d
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:31:21 2014 +0100

    x86emul: enforce privilege level restrictions when loading CS
    
    Privilege level checks were basically missing for the CS case, the
    only check that was done (RPL == DPL for nonconforming segments)
    was solely covering a single special case (return to non-conforming
    segment).
    
    Additionally in long mode the L bit set requires the D bit to be clear,
    as was recently pointed out for KVM by Nadav Amit
    <namit@cs.technion.ac.il>.
    
    Finally we also need to force the loaded selector's RPL to CPL (at
    least as long as lret/retf emulation doesn't support privilege level
    changes).
    
    This is CVE-2014-8595 / XSA-110.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: 1d68c1a70e00ed95ef0889cfa005379dab27b37d
    master date: 2014-11-18 14:16:23 +0100

commit c6e304d8335c9d8c447d743fd1163fbe8bccf245
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:30:37 2014 +0100

    x86: don't allow page table updates on non-PV page tables in do_mmu_update()
    
    paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
    consistently supported for non-PV guests (they'd deref NULL for PVH or
    non-HAP HVM ones). Don't allow respective MMU_* operations on the
    page tables of such domains.
    
    This is CVE-2014-8594 / XSA-109.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    master commit: e4292c5aac41b80f33d4877104348d5ee7c95aa4
    master date: 2014-11-18 14:15:21 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:25:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrAsg-00029O-Ry; Wed, 19 Nov 2014 19:25:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XrAsf-00028X-4M
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 19:25:33 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	6C/A3-26858-BAEEC645; Wed, 19 Nov 2014 19:25:31 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416425128!12398123!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3291 invoked from network); 19 Nov 2014 19:25:29 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 19:25:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416425129; x=1447961129;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=d83090tKbw88YXkUAgF2ecyzgRSd7hEKrm0kxLKz8XE=;
	b=OiOON8SYxLwaCv4Uj9C7h0QNH2eOn6NfHxxvYUv1fCYuvjI6DBB2o2JG
	d9l7UlDpK2aEaFYyOXKZt4A/V9CCE9c8makpcwXoXqwvnDmie0Fr9x5Sn
	ijyNhJ0D9PjKSXtWpd9+SoFPf7l4Ms/P1RnTGru4wXPq2V//z+yxerM3x E=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 19 Nov 2014 19:25:27 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="874694105"
Received: from unknown (HELO don-760.CloudSwitch.com) ([162.47.4.155])
	by fldsmtpi03.verizon.com with ESMTP; 19 Nov 2014 19:25:25 +0000
Message-ID: <546CEEA4.8060903@terremark.com>
Date: Wed, 19 Nov 2014 14:25:24 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Don Slutz <dslutz@verizon.com>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
	<546CAFB1.8070904@terremark.com> <546CBA8B.2090903@m2r.biz>
	<alpine.DEB.2.02.1411191551120.12596@kaball.uk.xensource.com>
	<546CD906.40903@terremark.com>
	<alpine.DEB.2.02.1411191817240.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411191817240.12596@kaball.uk.xensource.com>
Cc: anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org, Fabio Fantoni <fabio.fantoni@m2r.biz>,
	xen-devel <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/14 13:18, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Don Slutz wrote:
>> I have posted the patch:
>>
>> Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
>> for xenfv machine
>> Date: Wed, 19 Nov 2014 12:30:57 -0500
>> Message-ID: <1416418257-10166-1-git-send-email-dslutz@verizon.com>
>>
>>
>> Which fixes QEMU 2.2 for xenfv.  However if you configure xen_platform_pci=0
>> you will still
>> have this issue.  The good news is that xen-4.5 currently does not have QEMU
>> 2.2 and so does
>> not have this issue.
>>
>> Only people (groups like spice?) that want QEMU 2.2.0 with xen 4.5.0 (or older
>> xen versions)
>> will hit this.
>>
>> I have changes to xen 4.6 which will fix the xen_platform_pci=0 case also.
>>
>> In order to get xen 4.5 to fully work with QEMU 2.2.0 (both in hard freeze)
>>
>> the 1st patch from "Dr. David Alan Gilbert <dgilbert@redhat.com>"
>> would need to be applied to xen's qemu 2.0.2 (+ changes) so that
>> vmport=off can be added to --machine.
>>
>> And a patch (yet to be written, subset of changes I have pending for 4.6)
>> that adds vmport=off to QEMU args for --machine (it can be done in all cases).
> What happens if you pass vmport=off via --machine, without David Alan
> Gilbert's patch in QEMU?

I am almost (99%) sure that QEMU will complain about a bad arg.

gdb says:

(gdb) r
Starting program: 
/home/don/qemu/out/master/x86_64-softmmu/qemu-system-x86_64 -M pc 
-machine accel=xen,vmportport=1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
qemu-system-x86_64: -machine accel=xen,vmportport=1: Invalid parameter 
'vmportport'


In which case domU will fail to start.
    -Don Slutz

>
>>      -Don Slutz
>>
>>
>>
>> On 11/19/14 10:52, Stefano Stabellini wrote:
>>> On Wed, 19 Nov 2014, Fabio Fantoni wrote:
>>>> Il 19/11/2014 15:56, Don Slutz ha scritto:
>>>>> I think I know what is happening here.  But you are pointing at the
>>>>> wrong
>>>>> change.
>>>>>
>>>>> commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
>>>>>
>>>>> Is what I am guessing at this time is the issue.  I think that
>>>>> xen_enabled()
>>>>> is
>>>>> returning false in pc_machine_initfn.  Where as in pc_init1 is is
>>>>> returning
>>>>> true.
>>>>>
>>>>> I am thinking that:
>>>>>
>>>>>
>>>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>>>>> index 7bb97a4..3268c29 100644
>>>>> --- a/hw/i386/pc_piix.c
>>>>> +++ b/hw/i386/pc_piix.c
>>>>> @@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
>>>>>        .desc = "Xen Fully-virtualized PC",
>>>>>        .init = pc_xen_hvm_init,
>>>>>        .max_cpus = HVM_MAX_VCPUS,
>>>>> -    .default_machine_opts = "accel=xen",
>>>>> +    .default_machine_opts = "accel=xen,vmport=off",
>>>>>        .hot_add_cpu = pc_hot_add_cpu,
>>>>>    };
>>>>>    #endif
>>>>>
>>>>> Will fix your issue. I have not tested this yet.
>>>> Tested now and it solves regression of linux hvm domUs with qemu 2.2,
>>>> thanks.
>>>> I think that I'm not the only with this regression and that this patch (or
>>>> a
>>>> fix to the cause in vmport) should be applied before qemu 2.2 final.
>>> Don,
>>> please submit a proper patch with a Signed-off-by.
>>>
>>> Thanks!
>>>
>>> - Stefano
>>>
>>>>>       -Don Slutz
>>>>>
>>>>>
>>>>> On 11/19/14 09:04, Fabio Fantoni wrote:
>>>>>> Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
>>>>>>> dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid
>>>>>>> leaf
>>>>>>> with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches,
>>>>>>> and
>>>>>>> qemu 2.2 from spice git (spice/next commit
>>>>>>> e779fa0a715530311e6f59fc8adb0f6eca914a89):
>>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>>>> I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the
>>>>>> full
>>>>>> backtrace of latest test:
>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>> 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
>>>>>>> addr=0,
>>>>>>>       size=4) at
>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>>> 73          eax = env->regs[R_EAX];
>>>>>>> (gdb) bt full
>>>>>>> #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
>>>>>>> addr=0,
>>>>>>>       size=4) at
>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>>>           s = 0x5555564443a0
>>>>>>>           cs = 0x0
>>>>>>>           cpu = 0x0
>>>>>>>           __func__ = "vmport_ioport_read"
>>>>>>>           env = 0x8250
>>>>>>>           command = 0 '\000'
>>>>>>>           eax = 0
>>>>>>> #1  0x0000555555655fc4 in memory_region_read_accessor
>>>>>>> (mr=0x555556444428,
>>>>>>>       addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>>>>>           tmp = 0
>>>>>>> #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
>>>>>>>       value=0x7fffffffd8d0, size=4, access_size_min=4,
>>>>>>> access_size_max=4,
>>>>>>>       access=0x555555655f62 <memory_region_read_accessor>,
>>>>>>> mr=0x555556444428)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>>>>>           access_mask = 4294967295
>>>>>>>           access_size = 4
>>>>>>>           i = 0
>>>>>>> #3  0x00005555556590e9 in memory_region_dispatch_read1
>>>>>>> (mr=0x555556444428,
>>>>>>>       addr=0, size=4) at
>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>>>>>           data = 0
>>>>>>> #4  0x00005555556591b1 in memory_region_dispatch_read
>>>>>>> (mr=0x555556444428,
>>>>>>>       addr=0, pval=0x7fffffffd9a8, size=4)
>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>>>>>> No locals.
>>>>>>> #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
>>>>>>>       pval=0x7fffffffd9a8, size=4)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>>>>>> No locals.
>>>>>>> #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920,
>>>>>>> addr=22104,
>>>>>>>       buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
>>>>>>>           l = 4
>>>>>>>           ptr = 0x555555a92d87 "%s/%d:\n"
>>>>>>>           val = 7852232130387826944
>>>>>>>           addr1 = 0
>>>>>>>           mr = 0x555556444428
>>>>>>>           error = false
>>>>>>> #7  0x000055555560a38f in address_space_read (as=0x555555eaf920,
>>>>>>> addr=22104,
>>>>>>>       buf=0x7fffffffda50 "\377\377\377\377", len=4)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
>>>>>>> No locals.
>>>>>>> #8  0x000055555564fd4b in cpu_inl (addr=22104)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>>>>>           buf = "\377\377\377\377"
>>>>>>>           val = 21845
>>>>>>> #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>> No locals.
>>>>>>> #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>>>>>           i = 1
>>>>>>> #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
>>>>>>>       req=0x7ffff7ff3020) at
>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>>>>>> No locals.
>>>>>>> #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>>>>>           state = 0x5555563c2510
>>>>>>>           req = 0x7ffff7ff3020
>>>>>>> #13 0x000055555596e240 in qemu_iohandler_poll
>>>>>>> (pollfds=0x555556389a30,
>>>>>>> ret=1)
>>>>>>>       at iohandler.c:143
>>>>>>>           revents = 1
>>>>>>>           pioh = 0x5555563f7610
>>>>>>>           ioh = 0x555556450a40
>>>>>>> #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at
>>>>>>> main-loop.c:495
>>>>>>>           ret = 1
>>>>>>>           timeout = 4294967295
>>>>>>>           timeout_ns = 3965432
>>>>>>> #15 0x0000555555756d3f in main_loop () at vl.c:1882
>>>>>>>           nonblocking = false
>>>>>>>           last_io = 0
>>>>>>> #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
>>>>>>>       envp=0x7fffffffe240) at vl.c:4400
>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>>           i = 128
>>>>>>>           snapshot = 0
>>>>>>>           linux_boot = 0
>>>>>>>           initrd_filename = 0x0
>>>>>>>           kernel_filename = 0x0
>>>>>>>           kernel_cmdline = 0x555555a48f86 ""
>>>>>>>           boot_order = 0x555556387460 "dc"
>>>>>>>           ds = 0x5555564b2040
>>>>>>>           cyls = 0
>>>>>>>           heads = 0
>>>>>>>           secs = 0
>>>>>>>           translation = 0
>>>>>>>           hda_opts = 0x0
>>>>>>>           opts = 0x5555563873b0
>>>>>>>           machine_opts = 0x555556389010
>>>>>>>           icount_opts = 0x0
>>>>>>>           olist = 0x555555e57e80
>>>>>>>           optind = 62
>>>>>>>           optarg = 0x7fffffffe914
>>>>>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>>>>>           loadvm = 0x0
>>>>>>>           machine_class = 0x55555637d5c0
>>>>>>>           cpu_model = 0x0
>>>>>>>           vga_model = 0x0
>>>>>>>           qtest_chrdev = 0x0
>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>>           qtest_log = 0x0
>>>>>>>           pid_file = 0x0
>>>>>>>           incoming = 0x0
>>>>>>>           show_vnc_port = 0
>>>>>>>           defconfig = true
>>>>>>>           userconfig = true
>>>>>>>           log_mask = 0x0
>>>>>>>           log_file = 0x0
>>>>>>>           mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
>>>>>>>             realloc = 0x55555575a45a <realloc_and_trace>,
>>>>>>>             free = 0x55555575a4c1 <free_and_trace>, calloc = 0,
>>>>>>> try_malloc
>>>>>>> = 0,
>>>>>>>             try_realloc = 0}
>>>>>>>           trace_events = 0x0
>>>>>>>           trace_file = 0x0
>>>>>>>           default_ram_size = 134217728
>>>>>>>           maxram_size = 2130706432
>>>>>>>           ram_slots = 0
>>>>>>>           vmstate_dump_file = 0x0
>>>>>>>           main_loop_err = 0x0
>>>>>>>           __func__ = "main"
>>>>>> I take a fast look in source based on calltrace and I saw this commit:
>>>>>> http://secure-web.cisco.com/1EXVvN4KugVmCtI8RnLSX68LVqyly3ymtr7bhU7HDX8viw0fYlCBA54KE1K_VbwvaJhMDSmpeNsTiBHicuNWfTtG_XH9DP4c-7oqEb6kCcWzXKnCcQNOb9ikh4FRIBDr9R069aR0R5fdiB9q4iQSFDc4X0ttOQHu8h69rpG-X2bI/http%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dcommit%3Bh%3D37f9e258b64b3cf97c7c78df60660100c9eb5a21
>>>>>> xen-hvm.c: Add support for Xen access to vmport
>>>>>> Can be the cause of regression and I must try another test reverting
>>>>>> this
>>>>>> commit or is not related?
>>>>>>
>>>>>> Thanks for any reply anddo sorry for my bad english.
>>>>>>
>>>>>>> Qemu crash on fedora 20 lxde (with software updates of some days
>>>>>>> ago)
>>>>>>> boot with this backtrace:
>>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>>> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
>>>>>>>> addr=0, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>>>> 73          eax = env->regs[R_EAX];
>>>>>>>> (gdb) bt full
>>>>>>>> #0  0x0000555555689607 in vmport_ioport_read
>>>>>>>> (opaque=0x555556440a20,
>>>>>>>> addr=0, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>>>>           s = 0x555556440a20
>>>>>>>>           cs = 0x0
>>>>>>>>           cpu = 0x0
>>>>>>>>           __func__ = "vmport_ioport_read"
>>>>>>>>           env = 0x8250
>>>>>>>>           command = 0 '\000'
>>>>>>>>           eax = 0
>>>>>>>> #1  0x0000555555655b9c in memory_region_read_accessor
>>>>>>>> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0,
>>>>>>>> mask=4294967295)
>>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>>>>>>           tmp = 0
>>>>>>>> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0,
>>>>>>>> value=0x7fffffffd8c0, size=4, access_size_min=4,
>>>>>>>> access_size_max=4,
>>>>>>>>       access=0x555555655b3a <memory_region_read_accessor>,
>>>>>>>> mr=0x555556440aa8) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>>>>>>           access_mask = 4294967295
>>>>>>>>           access_size = 4
>>>>>>>>           i = 0
>>>>>>>> #3  0x0000555555658cc1 in memory_region_dispatch_read1
>>>>>>>> (mr=0x555556440aa8, addr=0, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>>>>>>           data = 0
>>>>>>>> #4  0x0000555555658d89 in memory_region_dispatch_read
>>>>>>>> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>>>>>>> No locals.
>>>>>>>> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0,
>>>>>>>> pval=0x7fffffffd998, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>>>>>>> No locals.
>>>>>>>> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840,
>>>>>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4,
>>>>>>>> is_write=false)
>>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>>>>>>>>           l = 4
>>>>>>>>           ptr = 0x0
>>>>>>>>           val = 7964229952888770560
>>>>>>>>           addr1 = 0
>>>>>>>>           mr = 0x555556440aa8
>>>>>>>>           error = false
>>>>>>>> #7  0x000055555560a173 in address_space_read (as=0x555555eae840,
>>>>>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
>>>>>>>> No locals.
>>>>>>>> #8  0x000055555564fac7 in cpu_inl (addr=22104) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>>>>>>           buf = "\377\377\377\377"
>>>>>>>>           val = 21845
>>>>>>>> #9  0x000055555567084b in do_inp (addr=22104, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>>>>>>> No locals.
>>>>>>>> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>>>>>>           i = 0
>>>>>>>> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590,
>>>>>>>> req=0x7ffff7ff3000) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>>> No locals.
>>>>>>>> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590)
>>>>>>>> at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>>>>>>           state = 0x5555563c1590
>>>>>>>>           req = 0x7ffff7ff3000
>>>>>>>> #13 0x000055555596d874 in qemu_iohandler_poll
>>>>>>>> (pollfds=0x555556388a30,
>>>>>>>> ret=1) at iohandler.c:143
>>>>>>>>           revents = 1
>>>>>>>>           pioh = 0x5555563f3c90
>>>>>>>>           ioh = 0x555556515f80
>>>>>>>> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at
>>>>>>>> main-loop.c:495
>>>>>>>>           ret = 1
>>>>>>>>           timeout = 4294967295
>>>>>>>>           timeout_ns = 3418165
>>>>>>>> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>>>>>>>>           nonblocking = false
>>>>>>>>           last_io = 1
>>>>>>>> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038,
>>>>>>>> envp=0x7fffffffe230) at vl.c:4400
>>>>>>>>           i = 128
>>>>>>>>           snapshot = 0
>>>>>>>>           linux_boot = 0
>>>>>>>>           initrd_filename = 0x0
>>>>>>>>           kernel_filename = 0x0
>>>>>>>>           kernel_cmdline = 0x555555a485c6 ""
>>>>>>>>           boot_order = 0x5555563864e0 "dc"
>>>>>>>>           ds = 0x5555564c71b0
>>>>>>>>           cyls = 0
>>>>>>>>           heads = 0
>>>>>>>>           secs = 0
>>>>>>>>           translation = 0
>>>>>>>>           hda_opts = 0x0
>>>>>>>>           opts = 0x555556386430
>>>>>>>>           machine_opts = 0x555556388090
>>>>>>>>           icount_opts = 0x0
>>>>>>>>           olist = 0x555555e56da0
>>>>>>>>           optind = 62
>>>>>>>>           optarg = 0x7fffffffe914
>>>>>>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>>>>>>           loadvm = 0x0
>>>>>>>>           machine_class = 0x55555637c5c0
>>>>>>>>           cpu_model = 0x0
>>>>>>>>           vga_model = 0x0
>>>>>>>>           qtest_chrdev = 0x0
>>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>>>           qtest_log = 0x0
>>>>>>>>           pid_file = 0x0
>>>>>>>>           incoming = 0x0
>>>>>>>>           show_vnc_port = 0
>>>>>>>>           defconfig = true
>>>>>>>>           userconfig = true
>>>>>>>>           log_mask = 0x0
>>>>>>>>           log_file = 0x0
>>>>>>>>           mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>,
>>>>>>>> realloc = 0x555555759ed2 <realloc_and_trace>, free =
>>>>>>>> 0x555555759f39
>>>>>>>> <free_and_trace>, calloc = 0,
>>>>>>>>             try_malloc = 0, try_realloc = 0}
>>>>>>>>           trace_events = 0x0
>>>>>>>>           trace_file = 0x0
>>>>>>>>           default_ram_size = 134217728
>>>>>>>>           maxram_size = 2013265920
>>>>>>>>           ram_slots = 0
>>>>>>>>           vmstate_dump_file = 0x0
>>>>>>>>           main_loop_err = 0x0
>>>>>>>>           __func__ = "main"
>>>>>>>> xl -vvv create /etc/xen/FEDORA19.cfg
>>>>>>>> Parsing config from /etc/xen/FEDORA19.cfg
>>>>>>>> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660:
>>>>>>>> create: how=(nil) callback=(nil) poller=0xac2af0
>>>>>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend:
>>>>>>>> Disk
>>>>>>>> vdev=hda spec.backend=unknown
>>>>>>>> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda,
>>>>>>>> backend phy unsuitable as phys path not a block device
>>>>>>>> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend:
>>>>>>>> Disk
>>>>>>>> vdev=hda, using backend qdisk
>>>>>>>> libxl: debug: libxl_create.c:935:initiate_domain_create: running
>>>>>>>> bootloader
>>>>>>>> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a
>>>>>>>> PV
>>>>>>>> domain, skipping bootloader
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac32f8: deregister unregistered
>>>>>>>> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
>>>>>>>> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
>>>>>>>> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
>>>>>>>> xc: detail:   Loader: 0000000000100000->000000000036b324
>>>>>>>> xc: detail:   Modules: 0000000000000000->0000000000000000
>>>>>>>> xc: detail:   TOTAL: 0000000000000000->0000000078000000
>>>>>>>> xc: detail:   ENTRY:    0000000000100000
>>>>>>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>>>>>>> xc: detail:   4KB PAGES: 0x0000000000000200
>>>>>>>> xc: detail:   2MB PAGES: 0x00000000000003bf
>>>>>>>> xc: detail:   1GB PAGES: 0x0000000000000000
>>>>>>>> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 ->
>>>>>>>> 0x7f1f975012b0
>>>>>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend:
>>>>>>>> Disk
>>>>>>>> vdev=hda spec.backend=qdisk
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac4ad0: deregister unregistered
>>>>>>>> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning
>>>>>>>> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> /usr/lib/xen/bin/qemu-gdb
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> chardev=libxl-cmd,mode=control
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: FEDORA
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -spice
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> spicevmc,id=vdagent,name=vdagent
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> virtserialport,chardev=vdagent,name=com.redhat.spice.0
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> qxl-vga,vram_size_mb=64,ram_size_mb=64
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> spicevmc,name=usbredir,id=usbrc1
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> usb-redir,chardev=usbrc1,id=usbrc1
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> spicevmc,name=usbredir,id=usbrc2
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> usb-redir,chardev=usbrc2,id=usbrc2
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> spicevmc,name=usbredir,id=usbrc3
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> usb-redir,chardev=usbrc3,id=usbrc3
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> spicevmc,name=usbredir,id=usbrc4
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> usb-redir,chardev=usbrc4,id=usbrc4
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -netdev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -drive
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
>>>>>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
>>>>>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
>>>>>>>> register slotnum=3
>>>>>>>> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660:
>>>>>>>> inprogress: poller=0xac2af0, flags=i
>>>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
>>>>>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event
>>>>>>>> epath=/local/domain/0/device-model/9/state
>>>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
>>>>>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event
>>>>>>>> epath=/local/domain/0/device-model/9/state
>>>>>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
>>>>>>>> deregister slotnum=3
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac3558: deregister unregistered
>>>>>>>> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to
>>>>>>>> /var/run/xen/qmp-libxl-9
>>>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>>>> qmp
>>>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
>>>>>>>> '{
>>>>>>>>       "execute": "qmp_capabilities",
>>>>>>>>       "id": 1
>>>>>>>> }
>>>>>>>> '
>>>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>>>> return
>>>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
>>>>>>>> '{
>>>>>>>>       "execute": "query-chardev",
>>>>>>>>       "id": 2
>>>>>>>> }
>>>>>>>> '
>>>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>>>> return
>>>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
>>>>>>>> '{
>>>>>>>>       "execute": "query-vnc",
>>>>>>>>       "id": 3
>>>>>>>> }
>>>>>>>> '
>>>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>>>> return
>>>>>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
>>>>>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
>>>>>>>> register slotnum=3
>>>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
>>>>>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
>>>>>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>>>>>> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend
>>>>>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting
>>>>>>>> state 1
>>>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
>>>>>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
>>>>>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>>>>>> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend
>>>>>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
>>>>>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
>>>>>>>> deregister slotnum=3
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac8368: deregister unregistered
>>>>>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
>>>>>>>> script: /etc/xen/scripts/vif-bridge online
>>>>>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking
>>>>>>>> to
>>>>>>>> execute: /etc/xen/scripts/vif-bridge online
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac83f0: deregister unregistered
>>>>>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
>>>>>>>> script: /etc/xen/scripts/vif-bridge add
>>>>>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking
>>>>>>>> to
>>>>>>>> execute: /etc/xen/scripts/vif-bridge add
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac83f0: deregister unregistered
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac83f0: deregister unregistered
>>>>>>>> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao
>>>>>>>> 0xac2660: progress report: ignored
>>>>>>>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660:
>>>>>>>> complete, rc=0
>>>>>>>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660:
>>>>>>>> destroy
>>>>>>>> xc: debug: hypercall buffer: total allocations:704 total
>>>>>>>> releases:704
>>>>>>>> xc: debug: hypercall buffer: current allocations:0 maximum
>>>>>>>> allocations:4
>>>>>>>> xc: debug: hypercall buffer: cache current size:4
>>>>>>>> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
>>>>>>>> xc: debug: hypercall buffer: total allocations:0 total releases:0
>>>>>>>> xc: debug: hypercall buffer: current allocations:0 maximum
>>>>>>>> allocations:0
>>>>>>>> xc: debug: hypercall buffer: cache current size:0
>>>>>>>> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
>>>>>>> xl dmesg
>>>>>>>> (d9) HVM Loader
>>>>>>>> (d9) Detected Xen v4.5.0-rc
>>>>>>>> (d9) Xenbus rings @0xfeffc000, event channel 1
>>>>>>>> (d9) System requested SeaBIOS
>>>>>>>> (d9) CPU speed is 2660 MHz
>>>>>>>> (d9) Relocating guest memory for lowmem MMIO space disabled
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
>>>>>>>> (d9) PCI-ISA link 0 routed to IRQ5
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
>>>>>>>> (d9) PCI-ISA link 1 routed to IRQ10
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
>>>>>>>> (d9) PCI-ISA link 2 routed to IRQ11
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
>>>>>>>> (d9) PCI-ISA link 3 routed to IRQ5
>>>>>>>> (d9) pci dev 01:3 INTA->IRQ10
>>>>>>>> (d9) pci dev 02:0 INTA->IRQ11
>>>>>>>> (d9) pci dev 03:0 INTA->IRQ5
>>>>>>>> (d9) pci dev 04:0 INTA->IRQ5
>>>>>>>> (d9) pci dev 05:0 INTA->IRQ10
>>>>>>>> (d9) pci dev 06:0 INTA->IRQ11
>>>>>>>> (d9) pci dev 1d:0 INTA->IRQ10
>>>>>>>> (d9) pci dev 1d:1 INTB->IRQ11
>>>>>>>> (d9) pci dev 1d:2 INTC->IRQ5
>>>>>>>> (d9) pci dev 1d:7 INTD->IRQ5
>>>>>>>> (d9) No RAM in high memory; setting high_mem resource base to
>>>>>>>> 100000000
>>>>>>>> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>>>>>>> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>>>>>>> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>>>>>>> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>>>>>>> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>>>>>>> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>>>>>>> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>>>>>>> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>>>>>>> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>>>>>>> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
>>>>>>>> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
>>>>>>>> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>>>>>>> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
>>>>>>>> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
>>>>>>>> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>>>>>>> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>>>>>>> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>>>>>>> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>>>>>>> (d9) Multiprocessor initialisation:
>>>>>>>> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
>>>>>>>> ...
>>>>>>>> done.
>>>>>>>> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
>>>>>>>> ...
>>>>>>>> done.
>>>>>>>> (d9) Testing HVM environment:
>>>>>>>> (d9)  - REP INSB across page boundaries ... passed
>>>>>>>> (d9)  - GS base MSRs and SWAPGS ... passed
>>>>>>>> (d9) Passed 2 of 2 tests
>>>>>>>> (d9) Writing SMBIOS tables ...
>>>>>>>> (d9) Loading SeaBIOS ...
>>>>>>>> (d9) Creating MP tables ...
>>>>>>>> (d9) Loading ACPI ...
>>>>>>>> (d9) S3 disabled
>>>>>>>> (d9) S4 disabled
>>>>>>>> (d9) vm86 TSS at fc00a100
>>>>>>>> (d9) BIOS map:
>>>>>>>> (d9)  10000-100d3: Scratch space
>>>>>>>> (d9)  c0000-fffff: Main BIOS
>>>>>>>> (d9) E820 table:
>>>>>>>> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>>>>>>> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>>>>>>> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>>>>>>> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>>>>>>> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
>>>>>>>> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>>>>>>> (d9) Invoking SeaBIOS ...
>>>>>>>> (d9) SeaBIOS (version
>>>>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>>>>> (d9)
>>>>>>>> (d9) Found Xen hypervisor signature at 40000000
>>>>>>>> (d9) Running on QEMU (i440fx)
>>>>>>>> (d9) xen: copy e820...
>>>>>>>> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>>>>>>> (d9) CPU Mhz=2660
>>>>>>>> (d9) Found 13 PCI devices (max PCI bus is 00)
>>>>>>>> (d9) Allocated Xen hypercall page at 77fff000
>>>>>>>> (d9) Detected Xen v4.5.0-rc
>>>>>>>> (d9) xen: copy BIOS tables...
>>>>>>>> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>>>>>>> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>>>>>>> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
>>>>>>>> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>>>>>>> (d9) Using pmtimer, ioport 0xb008
>>>>>>>> (d9) Scan for VGA option rom
>>>>>>>> (d9) Running option rom at c000:0003
>>>>>>>> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
>>>>>>>> (d9) pmm call arg1=0
>>>>>>>> (d9) Turning on vga text mode console
>>>>>>>> (d9) SeaBIOS (version
>>>>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>>>>> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
>>>>>>>> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
>>>>>>>> (d9) Found 0 lpt ports
>>>>>>>> (d9) Found 0 serial ports
>>>>>>>> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>>>>>>> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>>>>>>> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
>>>>>>>> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>>>>>>> (d9) UHCI init on dev 00:1d.0 (io=c240)
>>>>>>>> (d9) UHCI init on dev 00:1d.1 (io=c260)
>>>>>>>> (d9) UHCI init on dev 00:1d.2 (io=c280)
>>>>>>>> (d9) PS2 keyboard initialized
>>>>>>>> (d9) All threads complete.
>>>>>>>> (d9) Scan for option roms
>>>>>>>> (d9) Running option rom at c980:0003
>>>>>>>> (d9) pmm call arg1=1
>>>>>>>> (d9) pmm call arg1=0
>>>>>>>> (d9) pmm call arg1=1
>>>>>>>> (d9) pmm call arg1=0
>>>>>>>> (d9) Searching bootorder for: /pci@i0cf8/*@6
>>>>>>>> (d9)
>>>>>>>> (d9) Press F12 for boot menu.
>>>>>>>> (d9)
>>>>>>>> (d9) Searching bootorder for: HALT
>>>>>>>> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba
>>>>>>>> LCHS=1024/255/63 s=20480000
>>>>>>>> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
>>>>>>>> (d9) Returned 258048 bytes of ZoneHigh
>>>>>>>> (d9) e820 map has 6 items:
>>>>>>>> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>>>>>>>> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>>>>>>>> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>>>>>>>> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
>>>>>>>> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
>>>>>>>> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
>>>>>>>> (d9) enter handle_19:
>>>>>>>> (d9)   NULL
>>>>>>>> (d9) Booting from Hard Disk...
>>>>>>>> (d9) Booting from 0000:7c00
>>>>>>>> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
>>>>>>> domU's xl cfg:
>>>>>>>> name='FEDORA'
>>>>>>>> builder="hvm"
>>>>>>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>>>>> memory=2048
>>>>>>>> vcpus=2
>>>>>>>> acpi_s3=0
>>>>>>>> acpi_s4=0
>>>>>>>> vif=['bridge=xenbr0']
>>>>>>>> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
>>>>>>>> boot='dc'
>>>>>>>> device_model_version='qemu-xen'
>>>>>>>> vnc=0
>>>>>>>> keymap="it"
>>>>>>>> vga="qxl"
>>>>>>>> spice=1
>>>>>>>> spicehost='0.0.0.0'
>>>>>>>> spiceport=6005
>>>>>>>> spicedisable_ticketing=1
>>>>>>>> spicevdagent=1
>>>>>>>> spice_clipboard_sharing=0
>>>>>>>> spiceusbredirection=4
>>>>>>>> soundhw="hda"
>>>>>>> I tested also with stdvga instead of qxl vga but qemu crash always
>>>>>>> on
>>>>>>> fedora boot with same error.
>>>>>>>
>>>>>>> If you need more informations/tests tell me and I'll post them.
>>>>>>>
>>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:25:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrAsg-00029O-Ry; Wed, 19 Nov 2014 19:25:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XrAsf-00028X-4M
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 19:25:33 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	6C/A3-26858-BAEEC645; Wed, 19 Nov 2014 19:25:31 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416425128!12398123!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3291 invoked from network); 19 Nov 2014 19:25:29 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 19:25:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416425129; x=1447961129;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=d83090tKbw88YXkUAgF2ecyzgRSd7hEKrm0kxLKz8XE=;
	b=OiOON8SYxLwaCv4Uj9C7h0QNH2eOn6NfHxxvYUv1fCYuvjI6DBB2o2JG
	d9l7UlDpK2aEaFYyOXKZt4A/V9CCE9c8makpcwXoXqwvnDmie0Fr9x5Sn
	ijyNhJ0D9PjKSXtWpd9+SoFPf7l4Ms/P1RnTGru4wXPq2V//z+yxerM3x E=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 19 Nov 2014 19:25:27 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="scan'208";a="874694105"
Received: from unknown (HELO don-760.CloudSwitch.com) ([162.47.4.155])
	by fldsmtpi03.verizon.com with ESMTP; 19 Nov 2014 19:25:25 +0000
Message-ID: <546CEEA4.8060903@terremark.com>
Date: Wed, 19 Nov 2014 14:25:24 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Don Slutz <dslutz@verizon.com>
References: <5465E68E.1000304@m2r.biz> <546CA38A.7040509@m2r.biz>
	<546CAFB1.8070904@terremark.com> <546CBA8B.2090903@m2r.biz>
	<alpine.DEB.2.02.1411191551120.12596@kaball.uk.xensource.com>
	<546CD906.40903@terremark.com>
	<alpine.DEB.2.02.1411191817240.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411191817240.12596@kaball.uk.xensource.com>
Cc: anthony PERARD <anthony.perard@citrix.com>,
	spice-devel@lists.freedesktop.org, Fabio Fantoni <fabio.fantoni@m2r.biz>,
	xen-devel <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] qemu 2.2 crash on linux hvm domU (full
 backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/14 13:18, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Don Slutz wrote:
>> I have posted the patch:
>>
>> Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
>> for xenfv machine
>> Date: Wed, 19 Nov 2014 12:30:57 -0500
>> Message-ID: <1416418257-10166-1-git-send-email-dslutz@verizon.com>
>>
>>
>> Which fixes QEMU 2.2 for xenfv.  However if you configure xen_platform_pci=0
>> you will still
>> have this issue.  The good news is that xen-4.5 currently does not have QEMU
>> 2.2 and so does
>> not have this issue.
>>
>> Only people (groups like spice?) that want QEMU 2.2.0 with xen 4.5.0 (or older
>> xen versions)
>> will hit this.
>>
>> I have changes to xen 4.6 which will fix the xen_platform_pci=0 case also.
>>
>> In order to get xen 4.5 to fully work with QEMU 2.2.0 (both in hard freeze)
>>
>> the 1st patch from "Dr. David Alan Gilbert <dgilbert@redhat.com>"
>> would need to be applied to xen's qemu 2.0.2 (+ changes) so that
>> vmport=off can be added to --machine.
>>
>> And a patch (yet to be written, subset of changes I have pending for 4.6)
>> that adds vmport=off to QEMU args for --machine (it can be done in all cases).
> What happens if you pass vmport=off via --machine, without David Alan
> Gilbert's patch in QEMU?

I am almost (99%) sure that QEMU will complain about a bad arg.

gdb says:

(gdb) r
Starting program: 
/home/don/qemu/out/master/x86_64-softmmu/qemu-system-x86_64 -M pc 
-machine accel=xen,vmportport=1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
qemu-system-x86_64: -machine accel=xen,vmportport=1: Invalid parameter 
'vmportport'


In which case domU will fail to start.
    -Don Slutz

>
>>      -Don Slutz
>>
>>
>>
>> On 11/19/14 10:52, Stefano Stabellini wrote:
>>> On Wed, 19 Nov 2014, Fabio Fantoni wrote:
>>>> Il 19/11/2014 15:56, Don Slutz ha scritto:
>>>>> I think I know what is happening here.  But you are pointing at the
>>>>> wrong
>>>>> change.
>>>>>
>>>>> commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
>>>>>
>>>>> Is what I am guessing at this time is the issue.  I think that
>>>>> xen_enabled()
>>>>> is
>>>>> returning false in pc_machine_initfn.  Where as in pc_init1 is is
>>>>> returning
>>>>> true.
>>>>>
>>>>> I am thinking that:
>>>>>
>>>>>
>>>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>>>>> index 7bb97a4..3268c29 100644
>>>>> --- a/hw/i386/pc_piix.c
>>>>> +++ b/hw/i386/pc_piix.c
>>>>> @@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
>>>>>        .desc = "Xen Fully-virtualized PC",
>>>>>        .init = pc_xen_hvm_init,
>>>>>        .max_cpus = HVM_MAX_VCPUS,
>>>>> -    .default_machine_opts = "accel=xen",
>>>>> +    .default_machine_opts = "accel=xen,vmport=off",
>>>>>        .hot_add_cpu = pc_hot_add_cpu,
>>>>>    };
>>>>>    #endif
>>>>>
>>>>> Will fix your issue. I have not tested this yet.
>>>> Tested now and it solves regression of linux hvm domUs with qemu 2.2,
>>>> thanks.
>>>> I think that I'm not the only with this regression and that this patch (or
>>>> a
>>>> fix to the cause in vmport) should be applied before qemu 2.2 final.
>>> Don,
>>> please submit a proper patch with a Signed-off-by.
>>>
>>> Thanks!
>>>
>>> - Stefano
>>>
>>>>>       -Don Slutz
>>>>>
>>>>>
>>>>> On 11/19/14 09:04, Fabio Fantoni wrote:
>>>>>> Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
>>>>>>> dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid
>>>>>>> leaf
>>>>>>> with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches,
>>>>>>> and
>>>>>>> qemu 2.2 from spice git (spice/next commit
>>>>>>> e779fa0a715530311e6f59fc8adb0f6eca914a89):
>>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>>>> I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the
>>>>>> full
>>>>>> backtrace of latest test:
>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>> 0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
>>>>>>> addr=0,
>>>>>>>       size=4) at
>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>>> 73          eax = env->regs[R_EAX];
>>>>>>> (gdb) bt full
>>>>>>> #0  0x0000555555689b07 in vmport_ioport_read (opaque=0x5555564443a0,
>>>>>>> addr=0,
>>>>>>>       size=4) at
>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>>>           s = 0x5555564443a0
>>>>>>>           cs = 0x0
>>>>>>>           cpu = 0x0
>>>>>>>           __func__ = "vmport_ioport_read"
>>>>>>>           env = 0x8250
>>>>>>>           command = 0 '\000'
>>>>>>>           eax = 0
>>>>>>> #1  0x0000555555655fc4 in memory_region_read_accessor
>>>>>>> (mr=0x555556444428,
>>>>>>>       addr=0, value=0x7fffffffd8d0, size=4, shift=0, mask=4294967295)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>>>>>           tmp = 0
>>>>>>> #2  0x00005555556562b7 in access_with_adjusted_size (addr=0,
>>>>>>>       value=0x7fffffffd8d0, size=4, access_size_min=4,
>>>>>>> access_size_max=4,
>>>>>>>       access=0x555555655f62 <memory_region_read_accessor>,
>>>>>>> mr=0x555556444428)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>>>>>           access_mask = 4294967295
>>>>>>>           access_size = 4
>>>>>>>           i = 0
>>>>>>> #3  0x00005555556590e9 in memory_region_dispatch_read1
>>>>>>> (mr=0x555556444428,
>>>>>>>       addr=0, size=4) at
>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>>>>>           data = 0
>>>>>>> #4  0x00005555556591b1 in memory_region_dispatch_read
>>>>>>> (mr=0x555556444428,
>>>>>>>       addr=0, pval=0x7fffffffd9a8, size=4)
>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>>>>>> No locals.
>>>>>>> #5  0x000055555565cbbc in io_mem_read (mr=0x555556444428, addr=0,
>>>>>>>       pval=0x7fffffffd9a8, size=4)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>>>>>> No locals.
>>>>>>> #6  0x000055555560a1ca in address_space_rw (as=0x555555eaf920,
>>>>>>> addr=22104,
>>>>>>>       buf=0x7fffffffda50 "\377\377\377\377", len=4, is_write=false)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
>>>>>>>           l = 4
>>>>>>>           ptr = 0x555555a92d87 "%s/%d:\n"
>>>>>>>           val = 7852232130387826944
>>>>>>>           addr1 = 0
>>>>>>>           mr = 0x555556444428
>>>>>>>           error = false
>>>>>>> #7  0x000055555560a38f in address_space_read (as=0x555555eaf920,
>>>>>>> addr=22104,
>>>>>>>       buf=0x7fffffffda50 "\377\377\377\377", len=4)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
>>>>>>> No locals.
>>>>>>> #8  0x000055555564fd4b in cpu_inl (addr=22104)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>>>>>           buf = "\377\377\377\377"
>>>>>>>           val = 21845
>>>>>>> #9  0x0000555555670c73 in do_inp (addr=22104, size=4)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>> No locals.
>>>>>>> #10 0x0000555555670ee0 in cpu_ioreq_pio (req=0x7ffff7ff3020)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>>>>>           i = 1
>>>>>>> #11 0x00005555556714b3 in handle_ioreq (state=0x5555563c2510,
>>>>>>>       req=0x7ffff7ff3020) at
>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>>>>>> No locals.
>>>>>>> #12 0x0000555555671826 in cpu_handle_ioreq (opaque=0x5555563c2510)
>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>>>>>           state = 0x5555563c2510
>>>>>>>           req = 0x7ffff7ff3020
>>>>>>> #13 0x000055555596e240 in qemu_iohandler_poll
>>>>>>> (pollfds=0x555556389a30,
>>>>>>> ret=1)
>>>>>>>       at iohandler.c:143
>>>>>>>           revents = 1
>>>>>>>           pioh = 0x5555563f7610
>>>>>>>           ioh = 0x555556450a40
>>>>>>> #14 0x000055555596de1c in main_loop_wait (nonblocking=0) at
>>>>>>> main-loop.c:495
>>>>>>>           ret = 1
>>>>>>>           timeout = 4294967295
>>>>>>>           timeout_ns = 3965432
>>>>>>> #15 0x0000555555756d3f in main_loop () at vl.c:1882
>>>>>>>           nonblocking = false
>>>>>>>           last_io = 0
>>>>>>> #16 0x000055555575ea49 in main (argc=62, argv=0x7fffffffe048,
>>>>>>>       envp=0x7fffffffe240) at vl.c:4400
>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>>           i = 128
>>>>>>>           snapshot = 0
>>>>>>>           linux_boot = 0
>>>>>>>           initrd_filename = 0x0
>>>>>>>           kernel_filename = 0x0
>>>>>>>           kernel_cmdline = 0x555555a48f86 ""
>>>>>>>           boot_order = 0x555556387460 "dc"
>>>>>>>           ds = 0x5555564b2040
>>>>>>>           cyls = 0
>>>>>>>           heads = 0
>>>>>>>           secs = 0
>>>>>>>           translation = 0
>>>>>>>           hda_opts = 0x0
>>>>>>>           opts = 0x5555563873b0
>>>>>>>           machine_opts = 0x555556389010
>>>>>>>           icount_opts = 0x0
>>>>>>>           olist = 0x555555e57e80
>>>>>>>           optind = 62
>>>>>>>           optarg = 0x7fffffffe914
>>>>>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>>>>>           loadvm = 0x0
>>>>>>>           machine_class = 0x55555637d5c0
>>>>>>>           cpu_model = 0x0
>>>>>>>           vga_model = 0x0
>>>>>>>           qtest_chrdev = 0x0
>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>>           qtest_log = 0x0
>>>>>>>           pid_file = 0x0
>>>>>>>           incoming = 0x0
>>>>>>>           show_vnc_port = 0
>>>>>>>           defconfig = true
>>>>>>>           userconfig = true
>>>>>>>           log_mask = 0x0
>>>>>>>           log_file = 0x0
>>>>>>>           mem_trace = {malloc = 0x55555575a402 <malloc_and_trace>,
>>>>>>>             realloc = 0x55555575a45a <realloc_and_trace>,
>>>>>>>             free = 0x55555575a4c1 <free_and_trace>, calloc = 0,
>>>>>>> try_malloc
>>>>>>> = 0,
>>>>>>>             try_realloc = 0}
>>>>>>>           trace_events = 0x0
>>>>>>>           trace_file = 0x0
>>>>>>>           default_ram_size = 134217728
>>>>>>>           maxram_size = 2130706432
>>>>>>>           ram_slots = 0
>>>>>>>           vmstate_dump_file = 0x0
>>>>>>>           main_loop_err = 0x0
>>>>>>>           __func__ = "main"
>>>>>> I take a fast look in source based on calltrace and I saw this commit:
>>>>>> http://secure-web.cisco.com/1EXVvN4KugVmCtI8RnLSX68LVqyly3ymtr7bhU7HDX8viw0fYlCBA54KE1K_VbwvaJhMDSmpeNsTiBHicuNWfTtG_XH9DP4c-7oqEb6kCcWzXKnCcQNOb9ikh4FRIBDr9R069aR0R5fdiB9q4iQSFDc4X0ttOQHu8h69rpG-X2bI/http%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dcommit%3Bh%3D37f9e258b64b3cf97c7c78df60660100c9eb5a21
>>>>>> xen-hvm.c: Add support for Xen access to vmport
>>>>>> Can be the cause of regression and I must try another test reverting
>>>>>> this
>>>>>> commit or is not related?
>>>>>>
>>>>>> Thanks for any reply anddo sorry for my bad english.
>>>>>>
>>>>>>> Qemu crash on fedora 20 lxde (with software updates of some days
>>>>>>> ago)
>>>>>>> boot with this backtrace:
>>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>>> 0x0000555555689607 in vmport_ioport_read (opaque=0x555556440a20,
>>>>>>>> addr=0, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>>>> 73          eax = env->regs[R_EAX];
>>>>>>>> (gdb) bt full
>>>>>>>> #0  0x0000555555689607 in vmport_ioport_read
>>>>>>>> (opaque=0x555556440a20,
>>>>>>>> addr=0, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
>>>>>>>>           s = 0x555556440a20
>>>>>>>>           cs = 0x0
>>>>>>>>           cpu = 0x0
>>>>>>>>           __func__ = "vmport_ioport_read"
>>>>>>>>           env = 0x8250
>>>>>>>>           command = 0 '\000'
>>>>>>>>           eax = 0
>>>>>>>> #1  0x0000555555655b9c in memory_region_read_accessor
>>>>>>>> (mr=0x555556440aa8, addr=0, value=0x7fffffffd8c0, size=4, shift=0,
>>>>>>>> mask=4294967295)
>>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
>>>>>>>>           tmp = 0
>>>>>>>> #2  0x0000555555655e8f in access_with_adjusted_size (addr=0,
>>>>>>>> value=0x7fffffffd8c0, size=4, access_size_min=4,
>>>>>>>> access_size_max=4,
>>>>>>>>       access=0x555555655b3a <memory_region_read_accessor>,
>>>>>>>> mr=0x555556440aa8) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
>>>>>>>>           access_mask = 4294967295
>>>>>>>>           access_size = 4
>>>>>>>>           i = 0
>>>>>>>> #3  0x0000555555658cc1 in memory_region_dispatch_read1
>>>>>>>> (mr=0x555556440aa8, addr=0, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
>>>>>>>>           data = 0
>>>>>>>> #4  0x0000555555658d89 in memory_region_dispatch_read
>>>>>>>> (mr=0x555556440aa8, addr=0, pval=0x7fffffffd998, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
>>>>>>>> No locals.
>>>>>>>> #5  0x000055555565c794 in io_mem_read (mr=0x555556440aa8, addr=0,
>>>>>>>> pval=0x7fffffffd998, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
>>>>>>>> No locals.
>>>>>>>> #6  0x0000555555609fae in address_space_rw (as=0x555555eae840,
>>>>>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4,
>>>>>>>> is_write=false)
>>>>>>>>       at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
>>>>>>>>           l = 4
>>>>>>>>           ptr = 0x0
>>>>>>>>           val = 7964229952888770560
>>>>>>>>           addr1 = 0
>>>>>>>>           mr = 0x555556440aa8
>>>>>>>>           error = false
>>>>>>>> #7  0x000055555560a173 in address_space_read (as=0x555555eae840,
>>>>>>>> addr=22104, buf=0x7fffffffda40 "\377\377\377\377", len=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
>>>>>>>> No locals.
>>>>>>>> #8  0x000055555564fac7 in cpu_inl (addr=22104) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
>>>>>>>>           buf = "\377\377\377\377"
>>>>>>>>           val = 21845
>>>>>>>> #9  0x000055555567084b in do_inp (addr=22104, size=4) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
>>>>>>>> No locals.
>>>>>>>> #10 0x0000555555670ab8 in cpu_ioreq_pio (req=0x7ffff7ff3000) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
>>>>>>>>           i = 0
>>>>>>>> #11 0x000055555567108b in handle_ioreq (state=0x5555563c1590,
>>>>>>>> req=0x7ffff7ff3000) at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
>>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>>> No locals.
>>>>>>>> #12 0x00005555556713fe in cpu_handle_ioreq (opaque=0x5555563c1590)
>>>>>>>> at
>>>>>>>> /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
>>>>>>>>           state = 0x5555563c1590
>>>>>>>>           req = 0x7ffff7ff3000
>>>>>>>> #13 0x000055555596d874 in qemu_iohandler_poll
>>>>>>>> (pollfds=0x555556388a30,
>>>>>>>> ret=1) at iohandler.c:143
>>>>>>>>           revents = 1
>>>>>>>>           pioh = 0x5555563f3c90
>>>>>>>>           ioh = 0x555556515f80
>>>>>>>> #14 0x000055555596d450 in main_loop_wait (nonblocking=0) at
>>>>>>>> main-loop.c:495
>>>>>>>>           ret = 1
>>>>>>>>           timeout = 4294967295
>>>>>>>>           timeout_ns = 3418165
>>>>>>>> #15 0x00005555557567b7 in main_loop () at vl.c:1882
>>>>>>>>           nonblocking = false
>>>>>>>>           last_io = 1
>>>>>>>> #16 0x000055555575e4c1 in main (argc=62, argv=0x7fffffffe038,
>>>>>>>> envp=0x7fffffffe230) at vl.c:4400
>>>>>>>>           i = 128
>>>>>>>>           snapshot = 0
>>>>>>>>           linux_boot = 0
>>>>>>>>           initrd_filename = 0x0
>>>>>>>>           kernel_filename = 0x0
>>>>>>>>           kernel_cmdline = 0x555555a485c6 ""
>>>>>>>>           boot_order = 0x5555563864e0 "dc"
>>>>>>>>           ds = 0x5555564c71b0
>>>>>>>>           cyls = 0
>>>>>>>>           heads = 0
>>>>>>>>           secs = 0
>>>>>>>>           translation = 0
>>>>>>>>           hda_opts = 0x0
>>>>>>>>           opts = 0x555556386430
>>>>>>>>           machine_opts = 0x555556388090
>>>>>>>>           icount_opts = 0x0
>>>>>>>>           olist = 0x555555e56da0
>>>>>>>>           optind = 62
>>>>>>>>           optarg = 0x7fffffffe914
>>>>>>>> "file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"
>>>>>>>>           loadvm = 0x0
>>>>>>>>           machine_class = 0x55555637c5c0
>>>>>>>>           cpu_model = 0x0
>>>>>>>>           vga_model = 0x0
>>>>>>>>           qtest_chrdev = 0x0
>>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>>>           qtest_log = 0x0
>>>>>>>>           pid_file = 0x0
>>>>>>>>           incoming = 0x0
>>>>>>>>           show_vnc_port = 0
>>>>>>>>           defconfig = true
>>>>>>>>           userconfig = true
>>>>>>>>           log_mask = 0x0
>>>>>>>>           log_file = 0x0
>>>>>>>>           mem_trace = {malloc = 0x555555759e7a <malloc_and_trace>,
>>>>>>>> realloc = 0x555555759ed2 <realloc_and_trace>, free =
>>>>>>>> 0x555555759f39
>>>>>>>> <free_and_trace>, calloc = 0,
>>>>>>>>             try_malloc = 0, try_realloc = 0}
>>>>>>>>           trace_events = 0x0
>>>>>>>>           trace_file = 0x0
>>>>>>>>           default_ram_size = 134217728
>>>>>>>>           maxram_size = 2013265920
>>>>>>>>           ram_slots = 0
>>>>>>>>           vmstate_dump_file = 0x0
>>>>>>>>           main_loop_err = 0x0
>>>>>>>>           __func__ = "main"
>>>>>>>> xl -vvv create /etc/xen/FEDORA19.cfg
>>>>>>>> Parsing config from /etc/xen/FEDORA19.cfg
>>>>>>>> libxl: debug: libxl_create.c:1529:do_domain_create: ao 0xac2660:
>>>>>>>> create: how=(nil) callback=(nil) poller=0xac2af0
>>>>>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend:
>>>>>>>> Disk
>>>>>>>> vdev=hda spec.backend=unknown
>>>>>>>> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda,
>>>>>>>> backend phy unsuitable as phys path not a block device
>>>>>>>> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend:
>>>>>>>> Disk
>>>>>>>> vdev=hda, using backend qdisk
>>>>>>>> libxl: debug: libxl_create.c:935:initiate_domain_create: running
>>>>>>>> bootloader
>>>>>>>> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a
>>>>>>>> PV
>>>>>>>> domain, skipping bootloader
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac32f8: deregister unregistered
>>>>>>>> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x26b324
>>>>>>>> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x36b324
>>>>>>>> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
>>>>>>>> xc: detail:   Loader: 0000000000100000->000000000036b324
>>>>>>>> xc: detail:   Modules: 0000000000000000->0000000000000000
>>>>>>>> xc: detail:   TOTAL: 0000000000000000->0000000078000000
>>>>>>>> xc: detail:   ENTRY:    0000000000100000
>>>>>>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>>>>>>> xc: detail:   4KB PAGES: 0x0000000000000200
>>>>>>>> xc: detail:   2MB PAGES: 0x00000000000003bf
>>>>>>>> xc: detail:   1GB PAGES: 0x0000000000000000
>>>>>>>> xc: detail: elf_load_binary: phdr 0 at 0x7f1f9729f000 ->
>>>>>>>> 0x7f1f975012b0
>>>>>>>> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend:
>>>>>>>> Disk
>>>>>>>> vdev=hda spec.backend=qdisk
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac4ad0: deregister unregistered
>>>>>>>> libxl: debug: libxl_dm.c:1415:libxl__spawn_local_dm: Spawning
>>>>>>>> device-model /usr/lib/xen/bin/qemu-gdb with arguments:
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> /usr/lib/xen/bin/qemu-gdb
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -xen-domid
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   9
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -mon
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> chardev=libxl-cmd,mode=control
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -nodefaults
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -name
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: FEDORA
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -k
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   it
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -spice
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> port=6005,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: virtio-serial
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> spicevmc,id=vdagent,name=vdagent
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> virtserialport,chardev=vdagent,name=com.redhat.spice.0
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> qxl-vga,vram_size_mb=64,ram_size_mb=64
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -boot
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: order=dc
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> spicevmc,name=usbredir,id=usbrc1
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> usb-redir,chardev=usbrc1,id=usbrc1
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> spicevmc,name=usbredir,id=usbrc2
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> usb-redir,chardev=usbrc2,id=usbrc2
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> spicevmc,name=usbredir,id=usbrc3
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> usb-redir,chardev=usbrc3,id=usbrc3
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -chardev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> spicevmc,name=usbredir,id=usbrc4
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> usb-redir,chardev=usbrc4,id=usbrc4
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -soundhw
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   hda
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -smp
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: 2,maxcpus=2
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -device
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> rtl8139,id=nic0,netdev=net0,mac=00:16:3e:18:e1:35
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -netdev
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -machine
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   xenfv
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   -m
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:   1920
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm: -drive
>>>>>>>> libxl: debug: libxl_dm.c:1417:libxl__spawn_local_dm:
>>>>>>>> file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
>>>>>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
>>>>>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
>>>>>>>> register slotnum=3
>>>>>>>> libxl: debug: libxl_create.c:1545:do_domain_create: ao 0xac2660:
>>>>>>>> inprogress: poller=0xac2af0, flags=i
>>>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
>>>>>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event
>>>>>>>> epath=/local/domain/0/device-model/9/state
>>>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac3558
>>>>>>>> wpath=/local/domain/0/device-model/9/state token=3/0: event
>>>>>>>> epath=/local/domain/0/device-model/9/state
>>>>>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac3558 wpath=/local/domain/0/device-model/9/state token=3/0:
>>>>>>>> deregister slotnum=3
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac3558: deregister unregistered
>>>>>>>> libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to
>>>>>>>> /var/run/xen/qmp-libxl-9
>>>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>>>> qmp
>>>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
>>>>>>>> '{
>>>>>>>>       "execute": "qmp_capabilities",
>>>>>>>>       "id": 1
>>>>>>>> }
>>>>>>>> '
>>>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>>>> return
>>>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
>>>>>>>> '{
>>>>>>>>       "execute": "query-chardev",
>>>>>>>>       "id": 2
>>>>>>>> }
>>>>>>>> '
>>>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>>>> return
>>>>>>>> libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command:
>>>>>>>> '{
>>>>>>>>       "execute": "query-vnc",
>>>>>>>>       "id": 3
>>>>>>>> }
>>>>>>>> '
>>>>>>>> libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type:
>>>>>>>> return
>>>>>>>> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch
>>>>>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
>>>>>>>> register slotnum=3
>>>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
>>>>>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
>>>>>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>>>>>> libxl: debug: libxl_event.c:810:devstate_watch_callback: backend
>>>>>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 still waiting
>>>>>>>> state 1
>>>>>>>> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xac8368
>>>>>>>> wpath=/local/domain/0/backend/vif/9/0/state token=3/1: event
>>>>>>>> epath=/local/domain/0/backend/vif/9/0/state
>>>>>>>> libxl: debug: libxl_event.c:806:devstate_watch_callback: backend
>>>>>>>> /local/domain/0/backend/vif/9/0/state wanted state 2 ok
>>>>>>>> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac8368 wpath=/local/domain/0/backend/vif/9/0/state token=3/1:
>>>>>>>> deregister slotnum=3
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac8368: deregister unregistered
>>>>>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
>>>>>>>> script: /etc/xen/scripts/vif-bridge online
>>>>>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking
>>>>>>>> to
>>>>>>>> execute: /etc/xen/scripts/vif-bridge online
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac83f0: deregister unregistered
>>>>>>>> libxl: debug: libxl_device.c:1028:device_hotplug: calling hotplug
>>>>>>>> script: /etc/xen/scripts/vif-bridge add
>>>>>>>> libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking
>>>>>>>> to
>>>>>>>> execute: /etc/xen/scripts/vif-bridge add
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac83f0: deregister unregistered
>>>>>>>> libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister:
>>>>>>>> watch
>>>>>>>> w=0xac83f0: deregister unregistered
>>>>>>>> libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao
>>>>>>>> 0xac2660: progress report: ignored
>>>>>>>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xac2660:
>>>>>>>> complete, rc=0
>>>>>>>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xac2660:
>>>>>>>> destroy
>>>>>>>> xc: debug: hypercall buffer: total allocations:704 total
>>>>>>>> releases:704
>>>>>>>> xc: debug: hypercall buffer: current allocations:0 maximum
>>>>>>>> allocations:4
>>>>>>>> xc: debug: hypercall buffer: cache current size:4
>>>>>>>> xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:8
>>>>>>>> xc: debug: hypercall buffer: total allocations:0 total releases:0
>>>>>>>> xc: debug: hypercall buffer: current allocations:0 maximum
>>>>>>>> allocations:0
>>>>>>>> xc: debug: hypercall buffer: cache current size:0
>>>>>>>> xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
>>>>>>> xl dmesg
>>>>>>>> (d9) HVM Loader
>>>>>>>> (d9) Detected Xen v4.5.0-rc
>>>>>>>> (d9) Xenbus rings @0xfeffc000, event channel 1
>>>>>>>> (d9) System requested SeaBIOS
>>>>>>>> (d9) CPU speed is 2660 MHz
>>>>>>>> (d9) Relocating guest memory for lowmem MMIO space disabled
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 0 -> 5
>>>>>>>> (d9) PCI-ISA link 0 routed to IRQ5
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 0 -> 10
>>>>>>>> (d9) PCI-ISA link 1 routed to IRQ10
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 0 -> 11
>>>>>>>> (d9) PCI-ISA link 2 routed to IRQ11
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 0 -> 5
>>>>>>>> (d9) PCI-ISA link 3 routed to IRQ5
>>>>>>>> (d9) pci dev 01:3 INTA->IRQ10
>>>>>>>> (d9) pci dev 02:0 INTA->IRQ11
>>>>>>>> (d9) pci dev 03:0 INTA->IRQ5
>>>>>>>> (d9) pci dev 04:0 INTA->IRQ5
>>>>>>>> (d9) pci dev 05:0 INTA->IRQ10
>>>>>>>> (d9) pci dev 06:0 INTA->IRQ11
>>>>>>>> (d9) pci dev 1d:0 INTA->IRQ10
>>>>>>>> (d9) pci dev 1d:1 INTB->IRQ11
>>>>>>>> (d9) pci dev 1d:2 INTC->IRQ5
>>>>>>>> (d9) pci dev 1d:7 INTD->IRQ5
>>>>>>>> (d9) No RAM in high memory; setting high_mem resource base to
>>>>>>>> 100000000
>>>>>>>> (d9) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>>>>>>> (d9) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>>>>>>> (d9) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>>>>>>> (d9) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>>>>>>> (d9) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>>>>>>> (d9) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>>>>>>> (d9) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>>>>>>> (d9) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>>>>>>> (d9) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>>>>>>> (d9) pci dev 02:0 bar 10 size 000000100: 00000c001
>>>>>>>> (d9) pci dev 06:0 bar 10 size 000000100: 00000c101
>>>>>>>> (d9) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>>>>>>> (d9) pci dev 04:0 bar 10 size 000000020: 00000c201
>>>>>>>> (d9) pci dev 05:0 bar 1c size 000000020: 00000c221
>>>>>>>> (d9) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>>>>>>> (d9) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>>>>>>> (d9) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>>>>>>> (d9) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>>>>>>> (d9) Multiprocessor initialisation:
>>>>>>>> (d9)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
>>>>>>>> ...
>>>>>>>> done.
>>>>>>>> (d9)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8]
>>>>>>>> ...
>>>>>>>> done.
>>>>>>>> (d9) Testing HVM environment:
>>>>>>>> (d9)  - REP INSB across page boundaries ... passed
>>>>>>>> (d9)  - GS base MSRs and SWAPGS ... passed
>>>>>>>> (d9) Passed 2 of 2 tests
>>>>>>>> (d9) Writing SMBIOS tables ...
>>>>>>>> (d9) Loading SeaBIOS ...
>>>>>>>> (d9) Creating MP tables ...
>>>>>>>> (d9) Loading ACPI ...
>>>>>>>> (d9) S3 disabled
>>>>>>>> (d9) S4 disabled
>>>>>>>> (d9) vm86 TSS at fc00a100
>>>>>>>> (d9) BIOS map:
>>>>>>>> (d9)  10000-100d3: Scratch space
>>>>>>>> (d9)  c0000-fffff: Main BIOS
>>>>>>>> (d9) E820 table:
>>>>>>>> (d9)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>>>>>>> (d9)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>>>>>>> (d9)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>>>>>>> (d9)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>>>>>>> (d9)  HOLE: 00000000:78000000 - 00000000:fc000000
>>>>>>>> (d9)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>>>>>>> (d9) Invoking SeaBIOS ...
>>>>>>>> (d9) SeaBIOS (version
>>>>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>>>>> (d9)
>>>>>>>> (d9) Found Xen hypervisor signature at 40000000
>>>>>>>> (d9) Running on QEMU (i440fx)
>>>>>>>> (d9) xen: copy e820...
>>>>>>>> (d9) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>>>>>>> (d9) CPU Mhz=2660
>>>>>>>> (d9) Found 13 PCI devices (max PCI bus is 00)
>>>>>>>> (d9) Allocated Xen hypercall page at 77fff000
>>>>>>>> (d9) Detected Xen v4.5.0-rc
>>>>>>>> (d9) xen: copy BIOS tables...
>>>>>>>> (d9) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>>>>>>> (d9) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>>>>>>> (d9) Copying PIR from 0x00010030 to 0x000f0dc0
>>>>>>>> (d9) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>>>>>>> (d9) Using pmtimer, ioport 0xb008
>>>>>>>> (d9) Scan for VGA option rom
>>>>>>>> (d9) Running option rom at c000:0003
>>>>>>>> (XEN) stdvga.c:147:d9v0 entering stdvga and caching modes
>>>>>>>> (d9) pmm call arg1=0
>>>>>>>> (d9) Turning on vga text mode console
>>>>>>>> (d9) SeaBIOS (version
>>>>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>>>>> (d9) Machine UUID 2eca57e6-bff7-404e-bbda-1926d614cd28
>>>>>>>> (d9) EHCI init on dev 00:1d.7 (regs=0xf9057020)
>>>>>>>> (d9) Found 0 lpt ports
>>>>>>>> (d9) Found 0 serial ports
>>>>>>>> (d9) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>>>>>>> (d9) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>>>>>>> (d9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
>>>>>>>> (d9) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>>>>>>> (d9) UHCI init on dev 00:1d.0 (io=c240)
>>>>>>>> (d9) UHCI init on dev 00:1d.1 (io=c260)
>>>>>>>> (d9) UHCI init on dev 00:1d.2 (io=c280)
>>>>>>>> (d9) PS2 keyboard initialized
>>>>>>>> (d9) All threads complete.
>>>>>>>> (d9) Scan for option roms
>>>>>>>> (d9) Running option rom at c980:0003
>>>>>>>> (d9) pmm call arg1=1
>>>>>>>> (d9) pmm call arg1=0
>>>>>>>> (d9) pmm call arg1=1
>>>>>>>> (d9) pmm call arg1=0
>>>>>>>> (d9) Searching bootorder for: /pci@i0cf8/*@6
>>>>>>>> (d9)
>>>>>>>> (d9) Press F12 for boot menu.
>>>>>>>> (d9)
>>>>>>>> (d9) Searching bootorder for: HALT
>>>>>>>> (d9) drive 0x000f0d40: PCHS=16383/16/63 translation=lba
>>>>>>>> LCHS=1024/255/63 s=20480000
>>>>>>>> (d9) Space available for UMB: ca800-ef000, f0000-f0d40
>>>>>>>> (d9) Returned 258048 bytes of ZoneHigh
>>>>>>>> (d9) e820 map has 6 items:
>>>>>>>> (d9)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>>>>>>>> (d9)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>>>>>>>> (d9)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>>>>>>>> (d9)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
>>>>>>>> (d9)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
>>>>>>>> (d9)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
>>>>>>>> (d9) enter handle_19:
>>>>>>>> (d9)   NULL
>>>>>>>> (d9) Booting from Hard Disk...
>>>>>>>> (d9) Booting from 0000:7c00
>>>>>>>> (XEN) irq.c:389: Dom9 callback via changed to Direct Vector 0xf3
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 0 changed 5 -> 0
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 1 changed 10 -> 0
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 2 changed 11 -> 0
>>>>>>>> (XEN) irq.c:279: Dom9 PCI link 3 changed 5 -> 0
>>>>>>> domU's xl cfg:
>>>>>>>> name='FEDORA'
>>>>>>>> builder="hvm"
>>>>>>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>>>>> memory=2048
>>>>>>>> vcpus=2
>>>>>>>> acpi_s3=0
>>>>>>>> acpi_s4=0
>>>>>>>> vif=['bridge=xenbr0']
>>>>>>>> disk=['/mnt/vm/disks/FEDORA19.disk1.xm,raw,hda,rw']
>>>>>>>> boot='dc'
>>>>>>>> device_model_version='qemu-xen'
>>>>>>>> vnc=0
>>>>>>>> keymap="it"
>>>>>>>> vga="qxl"
>>>>>>>> spice=1
>>>>>>>> spicehost='0.0.0.0'
>>>>>>>> spiceport=6005
>>>>>>>> spicedisable_ticketing=1
>>>>>>>> spicevdagent=1
>>>>>>>> spice_clipboard_sharing=0
>>>>>>>> spiceusbredirection=4
>>>>>>>> soundhw="hda"
>>>>>>> I tested also with stdvga instead of qxl vga but qemu crash always
>>>>>>> on
>>>>>>> fedora boot with same error.
>>>>>>>
>>>>>>> If you need more informations/tests tell me and I'll post them.
>>>>>>>
>>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:44:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:44:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrBAs-0002nC-SI; Wed, 19 Nov 2014 19:44:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrBAr-0002n4-8W
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 19:44:21 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	3A/C9-29352-413FC645; Wed, 19 Nov 2014 19:44:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416426258!8205705!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3974 invoked from network); 19 Nov 2014 19:44:19 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 19:44:19 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJJhsw3017781
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 19:43:55 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJJhsHu021776
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 19:43:54 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJJhraX021767; Wed, 19 Nov 2014 19:43:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 11:43:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E87CC1182D3; Wed, 19 Nov 2014 14:43:50 -0500 (EST)
Date: Wed, 19 Nov 2014 14:43:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119194350.GA18117@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
	<20141113195605.GA13039@laptop.dumpdata.com>
	<54658ABF.5050708@suse.com>
	<20141114164741.GA8198@laptop.dumpdata.com>
	<5466385E.6040009@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5466385E.6040009@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 06:14:06PM +0100, Juergen Gross wrote:
> On 11/14/2014 05:47 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Nov 14, 2014 at 05:53:19AM +0100, Juergen Gross wrote:
> >>On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>>+	mfn_save = virt_to_mfn(buf);
> >>>>>>+
> >>>>>>+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
> >>>>>
> >>>>>So the 'list' is constructed by going forward - that is from low-numbered
> >>>>>PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
> >>>>>other way - from the highest PFN to the lowest PFN.
> >>>>>
> >>>>>Won't that mean we will restore the chunks of memory in the wrong
> >>>>>order? That is we will still restore them in chunks size, but the
> >>>>>chunks will be in descending order instead of ascending?
> >>>>
> >>>>No, the information where to put each chunk is contained in the chunk
> >>>>data. I can add a comment explaining this.
> >>>
> >>>Right, the MFNs in a "chunks" are going to be restored in the right order.
> >>>
> >>>I was thinking that the "chunks" (so a set of MFNs) will be restored in
> >>>the opposite order that they are written to.
> >>>
> >>>And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?
> >>
> >>More don't fit on a single page due to the other info needed. So: yes.
> >
> >But you could use two pages - one for the structure and the other
> >for the list of MFNs. That would fix the problem of having only
> >509 MFNs being contingous per chunk when restoring.
> 
> That's no problem (see below).
> 
> >Anyhow the point I had that I am worried is that we do not restore the
> >MFNs in the same order. We do it in "chunk" size which is OK (so the 509 MFNs
> >at once)- but the order we traverse the restoration process is the opposite of
> >the save process. Say we have 4MB of contingous MFNs, so two (err, three)
> >chunks. The first one we iterate is from 0->509, the second is 510->1018, the
> >last is 1019->1023. When we restore (remap) we start with the last 'chunk'
> >so we end up restoring them: 1019->1023, 510->1018, 0->509 order.
> 
> No. When building up the chunks we save in each chunk where to put it
> on remap. So in your example 0-509 should be mapped at <dest>+0,
> 510-1018 at <dest>+510, and 1019-1023 at <dest>+1019.
> 
> When remapping we map 1019-1023 to <dest>+1019, 510-1018 at <dest>+510
> and last 0-509 at <dest>+0. So we do the mapping in reverse order, but
> to the correct pfns.

Excellent! Could a condensed version of that explanation be put in the code ?

> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:44:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:44:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrBAs-0002nC-SI; Wed, 19 Nov 2014 19:44:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrBAr-0002n4-8W
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 19:44:21 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	3A/C9-29352-413FC645; Wed, 19 Nov 2014 19:44:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416426258!8205705!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3974 invoked from network); 19 Nov 2014 19:44:19 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 19:44:19 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJJhsw3017781
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 19:43:55 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJJhsHu021776
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 19:43:54 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJJhraX021767; Wed, 19 Nov 2014 19:43:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 11:43:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E87CC1182D3; Wed, 19 Nov 2014 14:43:50 -0500 (EST)
Date: Wed, 19 Nov 2014 14:43:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119194350.GA18117@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
	<20141113195605.GA13039@laptop.dumpdata.com>
	<54658ABF.5050708@suse.com>
	<20141114164741.GA8198@laptop.dumpdata.com>
	<5466385E.6040009@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5466385E.6040009@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 06:14:06PM +0100, Juergen Gross wrote:
> On 11/14/2014 05:47 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Nov 14, 2014 at 05:53:19AM +0100, Juergen Gross wrote:
> >>On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>>+	mfn_save = virt_to_mfn(buf);
> >>>>>>+
> >>>>>>+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
> >>>>>
> >>>>>So the 'list' is constructed by going forward - that is from low-numbered
> >>>>>PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
> >>>>>other way - from the highest PFN to the lowest PFN.
> >>>>>
> >>>>>Won't that mean we will restore the chunks of memory in the wrong
> >>>>>order? That is we will still restore them in chunks size, but the
> >>>>>chunks will be in descending order instead of ascending?
> >>>>
> >>>>No, the information where to put each chunk is contained in the chunk
> >>>>data. I can add a comment explaining this.
> >>>
> >>>Right, the MFNs in a "chunks" are going to be restored in the right order.
> >>>
> >>>I was thinking that the "chunks" (so a set of MFNs) will be restored in
> >>>the opposite order that they are written to.
> >>>
> >>>And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?
> >>
> >>More don't fit on a single page due to the other info needed. So: yes.
> >
> >But you could use two pages - one for the structure and the other
> >for the list of MFNs. That would fix the problem of having only
> >509 MFNs being contingous per chunk when restoring.
> 
> That's no problem (see below).
> 
> >Anyhow the point I had that I am worried is that we do not restore the
> >MFNs in the same order. We do it in "chunk" size which is OK (so the 509 MFNs
> >at once)- but the order we traverse the restoration process is the opposite of
> >the save process. Say we have 4MB of contingous MFNs, so two (err, three)
> >chunks. The first one we iterate is from 0->509, the second is 510->1018, the
> >last is 1019->1023. When we restore (remap) we start with the last 'chunk'
> >so we end up restoring them: 1019->1023, 510->1018, 0->509 order.
> 
> No. When building up the chunks we save in each chunk where to put it
> on remap. So in your example 0-509 should be mapped at <dest>+0,
> 510-1018 at <dest>+510, and 1019-1023 at <dest>+1019.
> 
> When remapping we map 1019-1023 to <dest>+1019, 510-1018 at <dest>+510
> and last 0-509 at <dest>+0. So we do the mapping in reverse order, but
> to the correct pfns.

Excellent! Could a condensed version of that explanation be put in the code ?

> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:45:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:45:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrBBz-0002rH-Ac; Wed, 19 Nov 2014 19:45:31 +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 1XrBBx-0002r6-HC
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 19:45:29 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	53/55-14214-853FC645; Wed, 19 Nov 2014 19:45:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416426327!12300695!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15673 invoked from network); 19 Nov 2014 19:45:28 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 19:45:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJJjKw5026298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 19:45:21 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJJjIv5011396
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 19:45:18 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJJjHQ2002882; Wed, 19 Nov 2014 19:45:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 11:45:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0B7AF1182DC; Wed, 19 Nov 2014 14:45:16 -0500 (EST)
Date: Wed, 19 Nov 2014 14:45:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141119194515.GB18117@laptop.dumpdata.com>
References: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
	<1415807026.1155.21.camel@citrix.com>
	<1415959858.21321.23.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415959858.21321.23.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Wei Liu <wei.liu2@citrix.com>, Clark Laughlin <clark.laughlin@linaro.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] mkdeb: correctly map package
 architectures for x86 and 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, Nov 14, 2014 at 10:10:58AM +0000, Ian Campbell wrote:
> (CCing some more maintainers and the release manager)
> 
> On Wed, 2014-11-12 at 15:43 +0000, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:38 -0600, Clark Laughlin wrote:
> > > mkdeb previously set the package architecture to be 'amd64' for anything other than
> > > XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture from
> > > GNU names to debian names for x86 and ARM architectures, or otherwise, defaults it
> > > to the value in XEN_TARGET_ARCH.
> > > 
> > > Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Actually thinking about it some more I'd be happier arguing for a freeze
> exception for something like the below which only handles the actual
> valid values of XEN_TARGET_ARCH and not the GNU names (which cannot
> happen) and prints an error for unknown architectures (so new ports
> aren't bitten in the future, etc).
> 
> Konrad, wrt the freeze I think this is low risk for breaking x86
> platforms and makes things work for arm, so is worth it.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> ------
> 
> >From d861e1bcf5c3530ef322515ec2c55031dd538277 Mon Sep 17 00:00:00 2001
> From: Clark Laughlin <clark.laughlin@linaro.org>
> Date: Wed, 12 Nov 2014 09:38:48 -0600
> Subject: [PATCH] mkdeb: correctly map package architectures for x86 and ARM
> 
> mkdeb previously set the package architecture to be 'amd64' for anything other than
> XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture
> from XEN_TARGET_ARCH to the Debian architecture names for x86 and ARM
> architectures.
> 
> Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v3 (ijc): Handle only valid values for $XEN_TARGET_ARCH, print an error if the
> arch is unknown.
> ---
>  tools/misc/mkdeb |   16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
> index 3bbf881..67b91cc 100644
> --- a/tools/misc/mkdeb
> +++ b/tools/misc/mkdeb
> @@ -13,11 +13,17 @@ fi
>  
>  cd $1
>  version=$2
> -if test "$XEN_TARGET_ARCH" = "x86_32"; then
> -  arch=i386
> -else
> -  arch=amd64
> -fi
> +
> +# map the architecture, if necessary
> +case "$XEN_TARGET_ARCH" in
> +  x86_32|x86_32p)  arch=i386 ;;
> +  x86_64)  arch=amd64 ;;
> +  arm32)   arch=armhf ;;
> +  arm64)   arch=$XEN_TARGET_ARCH;;
> +  *) echo "Unknown XEN_TARGET_ARCH $XEN_TARGET_ARCH" >&2
> +     exit 1
> +     ;;
> +esac
>  
>  # Prepare the directory to package
>  cd dist
> -- 
> 1.7.10.4
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:45:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:45:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrBBz-0002rH-Ac; Wed, 19 Nov 2014 19:45:31 +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 1XrBBx-0002r6-HC
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 19:45:29 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	53/55-14214-853FC645; Wed, 19 Nov 2014 19:45:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416426327!12300695!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15673 invoked from network); 19 Nov 2014 19:45:28 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 19:45:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJJjKw5026298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 19:45:21 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJJjIv5011396
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 19:45:18 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJJjHQ2002882; Wed, 19 Nov 2014 19:45:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 11:45:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0B7AF1182DC; Wed, 19 Nov 2014 14:45:16 -0500 (EST)
Date: Wed, 19 Nov 2014 14:45:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141119194515.GB18117@laptop.dumpdata.com>
References: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
	<1415807026.1155.21.camel@citrix.com>
	<1415959858.21321.23.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415959858.21321.23.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Wei Liu <wei.liu2@citrix.com>, Clark Laughlin <clark.laughlin@linaro.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] mkdeb: correctly map package
 architectures for x86 and 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, Nov 14, 2014 at 10:10:58AM +0000, Ian Campbell wrote:
> (CCing some more maintainers and the release manager)
> 
> On Wed, 2014-11-12 at 15:43 +0000, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:38 -0600, Clark Laughlin wrote:
> > > mkdeb previously set the package architecture to be 'amd64' for anything other than
> > > XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture from
> > > GNU names to debian names for x86 and ARM architectures, or otherwise, defaults it
> > > to the value in XEN_TARGET_ARCH.
> > > 
> > > Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Actually thinking about it some more I'd be happier arguing for a freeze
> exception for something like the below which only handles the actual
> valid values of XEN_TARGET_ARCH and not the GNU names (which cannot
> happen) and prints an error for unknown architectures (so new ports
> aren't bitten in the future, etc).
> 
> Konrad, wrt the freeze I think this is low risk for breaking x86
> platforms and makes things work for arm, so is worth it.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> ------
> 
> >From d861e1bcf5c3530ef322515ec2c55031dd538277 Mon Sep 17 00:00:00 2001
> From: Clark Laughlin <clark.laughlin@linaro.org>
> Date: Wed, 12 Nov 2014 09:38:48 -0600
> Subject: [PATCH] mkdeb: correctly map package architectures for x86 and ARM
> 
> mkdeb previously set the package architecture to be 'amd64' for anything other than
> XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture
> from XEN_TARGET_ARCH to the Debian architecture names for x86 and ARM
> architectures.
> 
> Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v3 (ijc): Handle only valid values for $XEN_TARGET_ARCH, print an error if the
> arch is unknown.
> ---
>  tools/misc/mkdeb |   16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
> index 3bbf881..67b91cc 100644
> --- a/tools/misc/mkdeb
> +++ b/tools/misc/mkdeb
> @@ -13,11 +13,17 @@ fi
>  
>  cd $1
>  version=$2
> -if test "$XEN_TARGET_ARCH" = "x86_32"; then
> -  arch=i386
> -else
> -  arch=amd64
> -fi
> +
> +# map the architecture, if necessary
> +case "$XEN_TARGET_ARCH" in
> +  x86_32|x86_32p)  arch=i386 ;;
> +  x86_64)  arch=amd64 ;;
> +  arm32)   arch=armhf ;;
> +  arm64)   arch=$XEN_TARGET_ARCH;;
> +  *) echo "Unknown XEN_TARGET_ARCH $XEN_TARGET_ARCH" >&2
> +     exit 1
> +     ;;
> +esac
>  
>  # Prepare the directory to package
>  cd dist
> -- 
> 1.7.10.4
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:46:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:46:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrBD6-0002xR-P8; Wed, 19 Nov 2014 19:46:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <n0ano@tlaloc.n0ano.com>) id 1XrBD5-0002xH-C5
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 19:46:39 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	FE/6B-02954-E93FC645; Wed, 19 Nov 2014 19:46:38 +0000
X-Env-Sender: n0ano@tlaloc.n0ano.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416426396!13559111!1
X-Originating-IP: [67.41.209.129]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9708 invoked from network); 19 Nov 2014 19:46:37 -0000
Received: from willie.n0ano.com (HELO willie.n0ano.com) (67.41.209.129)
	by server-7.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Nov 2014 19:46:37 -0000
Received: from tlaloc.n0ano.com ([192.168.1.12])
	by willie.n0ano.com with esmtp (Exim 4.72)
	(envelope-from <n0ano@tlaloc.n0ano.com>)
	id 1XrBD1-0004SW-Ss; Wed, 19 Nov 2014 12:46:35 -0700
Received: by tlaloc.n0ano.com (Postfix, from userid 524)
	id 9101FBAF9F6; Wed, 19 Nov 2014 12:46:11 -0700 (MST)
Date: Wed, 19 Nov 2014 12:46:11 -0700
From: "Donald D. Dugger" <donald.d.dugger@intel.com>
To: xen-devel@lists.xen.org
Message-ID: <20141119194611.GA2600@tlaloc.n0ano.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: allen.m.kay@intel.com, will.auld@intel.com, eddie.dong@intel.com,
	n0ano@n0ano.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH V3] Decouple SnadyBridge quirk form VTd timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently the quirk code for SandyBridge uses the VTd timeout value when
writing to an IGD register.  This is the wrong timeout to use and, at
1000 msec., is also much too large.  This patch changes the quirk code to
use a timeout that is specific to the IGD device and allows the user
control of the timeout.

Boolean settings for the boot parameter `snb_igd_quirk' keep their current
meaning, enabling or disabling the quirk code with a timeout of 1000 msec.

In addition specifying `snb_igd_quirk=default' will enable the code and
set the timeout to the theoretical maximum of 670 msec.  For finer control,
specifying `snb_igd_quirk=n', where `n' is a decimal number, will enable
the code and set the timeout to `n' msec.

Signed-off-by: Don Dugger <donald.d.dugger@intel.com>
-- 
diff -r 9d485e2c8339 xen/drivers/passthrough/vtd/quirks.c
--- a/xen/drivers/passthrough/vtd/quirks.c	Mon Nov 10 12:03:36 2014 +0000
+++ b/xen/drivers/passthrough/vtd/quirks.c	Wed Nov 19 09:49:31 2014 -0700
@@ -50,6 +50,10 @@
 #define IS_ILK(id)    (id == 0x00408086 || id == 0x00448086 || id== 0x00628086 || id == 0x006A8086)
 #define IS_CPT(id)    (id == 0x01008086 || id == 0x01048086)
 
+#define SNB_IGD_TIMEOUT_LEGACY	MILLISECS(1000)
+#define SNB_IGD_TIMEOUT		MILLISECS( 670)
+static u32 snb_igd_timeout = 0;
+
 static u32 __read_mostly ioh_id;
 static u32 __initdata igd_id;
 bool_t __read_mostly rwbf_quirk;
@@ -158,6 +162,16 @@
  * Workaround is to prevent graphics get into RC6
  * state when doing VT-d IOTLB operations, do the VT-d
  * IOTLB operation, and then re-enable RC6 state.
+ *
+ * This quirk is enabled with the snb_igd_quirk command
+ * line parameter.  Specifying snb_igd_quirk with no value
+ * (or any of the standard boolean values) enables this
+ * quirk and sets the timeout to the legacy timeout of
+ * 1000 msec.  Setting this parameter to the string
+ * "default" enables this quirk and sets the timeout to
+ * the theoretical maximum of 670 msec.  Setting this
+ * parameter to a numerical value enables the quirk and
+ * sets the timeout to that numerical number of msecs.
  */
 static void snb_vtd_ops_preamble(struct iommu* iommu)
 {
@@ -177,7 +191,7 @@
     start_time = NOW();
     while ( (*(volatile u32 *)(igd_reg_va + 0x22AC) & 0xF) != 0 )
     {
-        if ( NOW() > start_time + DMAR_OPERATION_TIMEOUT )
+        if ( NOW() > start_time + snb_igd_timeout )
         {
             dprintk(XENLOG_INFO VTDPREFIX,
                     "snb_vtd_ops_preamble: failed to disable idle handshake\n");
@@ -208,13 +222,10 @@
  * call before VT-d translation enable and IOTLB flush operations.
  */
 
-static int snb_igd_quirk;
-boolean_param("snb_igd_quirk", snb_igd_quirk);
-
 void vtd_ops_preamble_quirk(struct iommu* iommu)
 {
     cantiga_vtd_ops_preamble(iommu);
-    if ( snb_igd_quirk )
+    if ( snb_igd_timeout != 0 )
     {
         spin_lock(&igd_lock);
 
@@ -228,7 +239,7 @@
  */
 void vtd_ops_postamble_quirk(struct iommu* iommu)
 {
-    if ( snb_igd_quirk )
+    if ( snb_igd_timeout != 0 )
     {
         snb_vtd_ops_postamble(iommu);
 
@@ -237,6 +248,42 @@
     }
 }
 
+static void __init parse_snb_timeout(const char *s)
+{
+	int not;
+
+	switch (*s) {
+
+	case '\0':
+		snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
+		break;
+
+	case '0':	case '1':	case '2':
+	case '3':	case '4':	case '5':
+	case '6':	case '7':	case '8':
+	case '9':
+		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
+		if ( snb_igd_timeout == MILLISECS(1) )
+			snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
+		break;
+
+	default:
+		if ( strncmp("default", s, 7) == 0 ) {
+			snb_igd_timeout = SNB_IGD_TIMEOUT;
+			break;
+		}
+		not = !strncmp("no-", s, 3);
+		if ( not )
+			s += 3;
+		if ( not ^ parse_bool(s) )
+			snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
+		break;
+
+	}
+	return;
+}
+custom_param("snb_igd_quirk", parse_snb_timeout);
+
 /* 5500/5520/X58 Chipset Interrupt remapping errata, for stepping B-3.
  * Fixed in stepping C-2. */
 static void __init tylersburg_intremap_quirk(void)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 19:46:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 19:46:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrBD6-0002xR-P8; Wed, 19 Nov 2014 19:46:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <n0ano@tlaloc.n0ano.com>) id 1XrBD5-0002xH-C5
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 19:46:39 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	FE/6B-02954-E93FC645; Wed, 19 Nov 2014 19:46:38 +0000
X-Env-Sender: n0ano@tlaloc.n0ano.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416426396!13559111!1
X-Originating-IP: [67.41.209.129]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9708 invoked from network); 19 Nov 2014 19:46:37 -0000
Received: from willie.n0ano.com (HELO willie.n0ano.com) (67.41.209.129)
	by server-7.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Nov 2014 19:46:37 -0000
Received: from tlaloc.n0ano.com ([192.168.1.12])
	by willie.n0ano.com with esmtp (Exim 4.72)
	(envelope-from <n0ano@tlaloc.n0ano.com>)
	id 1XrBD1-0004SW-Ss; Wed, 19 Nov 2014 12:46:35 -0700
Received: by tlaloc.n0ano.com (Postfix, from userid 524)
	id 9101FBAF9F6; Wed, 19 Nov 2014 12:46:11 -0700 (MST)
Date: Wed, 19 Nov 2014 12:46:11 -0700
From: "Donald D. Dugger" <donald.d.dugger@intel.com>
To: xen-devel@lists.xen.org
Message-ID: <20141119194611.GA2600@tlaloc.n0ano.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: allen.m.kay@intel.com, will.auld@intel.com, eddie.dong@intel.com,
	n0ano@n0ano.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH V3] Decouple SnadyBridge quirk form VTd timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently the quirk code for SandyBridge uses the VTd timeout value when
writing to an IGD register.  This is the wrong timeout to use and, at
1000 msec., is also much too large.  This patch changes the quirk code to
use a timeout that is specific to the IGD device and allows the user
control of the timeout.

Boolean settings for the boot parameter `snb_igd_quirk' keep their current
meaning, enabling or disabling the quirk code with a timeout of 1000 msec.

In addition specifying `snb_igd_quirk=default' will enable the code and
set the timeout to the theoretical maximum of 670 msec.  For finer control,
specifying `snb_igd_quirk=n', where `n' is a decimal number, will enable
the code and set the timeout to `n' msec.

Signed-off-by: Don Dugger <donald.d.dugger@intel.com>
-- 
diff -r 9d485e2c8339 xen/drivers/passthrough/vtd/quirks.c
--- a/xen/drivers/passthrough/vtd/quirks.c	Mon Nov 10 12:03:36 2014 +0000
+++ b/xen/drivers/passthrough/vtd/quirks.c	Wed Nov 19 09:49:31 2014 -0700
@@ -50,6 +50,10 @@
 #define IS_ILK(id)    (id == 0x00408086 || id == 0x00448086 || id== 0x00628086 || id == 0x006A8086)
 #define IS_CPT(id)    (id == 0x01008086 || id == 0x01048086)
 
+#define SNB_IGD_TIMEOUT_LEGACY	MILLISECS(1000)
+#define SNB_IGD_TIMEOUT		MILLISECS( 670)
+static u32 snb_igd_timeout = 0;
+
 static u32 __read_mostly ioh_id;
 static u32 __initdata igd_id;
 bool_t __read_mostly rwbf_quirk;
@@ -158,6 +162,16 @@
  * Workaround is to prevent graphics get into RC6
  * state when doing VT-d IOTLB operations, do the VT-d
  * IOTLB operation, and then re-enable RC6 state.
+ *
+ * This quirk is enabled with the snb_igd_quirk command
+ * line parameter.  Specifying snb_igd_quirk with no value
+ * (or any of the standard boolean values) enables this
+ * quirk and sets the timeout to the legacy timeout of
+ * 1000 msec.  Setting this parameter to the string
+ * "default" enables this quirk and sets the timeout to
+ * the theoretical maximum of 670 msec.  Setting this
+ * parameter to a numerical value enables the quirk and
+ * sets the timeout to that numerical number of msecs.
  */
 static void snb_vtd_ops_preamble(struct iommu* iommu)
 {
@@ -177,7 +191,7 @@
     start_time = NOW();
     while ( (*(volatile u32 *)(igd_reg_va + 0x22AC) & 0xF) != 0 )
     {
-        if ( NOW() > start_time + DMAR_OPERATION_TIMEOUT )
+        if ( NOW() > start_time + snb_igd_timeout )
         {
             dprintk(XENLOG_INFO VTDPREFIX,
                     "snb_vtd_ops_preamble: failed to disable idle handshake\n");
@@ -208,13 +222,10 @@
  * call before VT-d translation enable and IOTLB flush operations.
  */
 
-static int snb_igd_quirk;
-boolean_param("snb_igd_quirk", snb_igd_quirk);
-
 void vtd_ops_preamble_quirk(struct iommu* iommu)
 {
     cantiga_vtd_ops_preamble(iommu);
-    if ( snb_igd_quirk )
+    if ( snb_igd_timeout != 0 )
     {
         spin_lock(&igd_lock);
 
@@ -228,7 +239,7 @@
  */
 void vtd_ops_postamble_quirk(struct iommu* iommu)
 {
-    if ( snb_igd_quirk )
+    if ( snb_igd_timeout != 0 )
     {
         snb_vtd_ops_postamble(iommu);
 
@@ -237,6 +248,42 @@
     }
 }
 
+static void __init parse_snb_timeout(const char *s)
+{
+	int not;
+
+	switch (*s) {
+
+	case '\0':
+		snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
+		break;
+
+	case '0':	case '1':	case '2':
+	case '3':	case '4':	case '5':
+	case '6':	case '7':	case '8':
+	case '9':
+		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
+		if ( snb_igd_timeout == MILLISECS(1) )
+			snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
+		break;
+
+	default:
+		if ( strncmp("default", s, 7) == 0 ) {
+			snb_igd_timeout = SNB_IGD_TIMEOUT;
+			break;
+		}
+		not = !strncmp("no-", s, 3);
+		if ( not )
+			s += 3;
+		if ( not ^ parse_bool(s) )
+			snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
+		break;
+
+	}
+	return;
+}
+custom_param("snb_igd_quirk", parse_snb_timeout);
+
 /* 5500/5520/X58 Chipset Interrupt remapping errata, for stepping B-3.
  * Fixed in stepping C-2. */
 static void __init tylersburg_intremap_quirk(void)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 20:38:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20:38:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrC0n-0003p6-7N; Wed, 19 Nov 2014 20:38:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrC0m-0003p1-4W
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 20:38:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FA/41-09936-7AFFC645; Wed, 19 Nov 2014 20:37:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416429476!13965650!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12839 invoked from network); 19 Nov 2014 20:37:58 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:37:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKbf8W018285
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:37:42 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKbdJh028718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 20:37:40 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJKbcRp017527; Wed, 19 Nov 2014 20:37:38 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:37:37 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 90DDD118331; Wed, 19 Nov 2014 15:37:35 -0500 (EST)
Date: Wed, 19 Nov 2014 15:37:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119203735.GA18495@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-8-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-8-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:43:45AM +0100, Juergen Gross wrote:
> At start of the day the Xen hypervisor presents a contiguous mfn list
> to a pv-domain. In order to support sparse memory this mfn list is
> accessed via a three level p2m tree built early in the boot process.
> Whenever the system needs the mfn associated with a pfn this tree is
> used to find the mfn.
> 
> Instead of using a software walked tree for accessing a specific mfn
> list entry this patch is creating a virtual address area for the
> entire possible mfn list including memory holes. The holes are
> covered by mapping a pre-defined  page consisting only of "invalid
> mfn" entries. Access to a mfn entry is possible by just using the
> virtual base address of the mfn list and the pfn as index into that
> list. This speeds up the (hot) path of determining the mfn of a
> pfn.
> 
> Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
> showed following improvements:
> 
> Elapsed time: 32:50 ->  32:35
> System:       18:07 ->  17:47
> User:        104:00 -> 103:30
> 
> Tested on 64 bit dom0 and 32 bit domU.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/include/asm/xen/page.h |  14 +-
>  arch/x86/xen/mmu.c              |  32 +-
>  arch/x86/xen/p2m.c              | 732 +++++++++++++++++-----------------------
>  arch/x86/xen/xen-ops.h          |   2 +-
>  4 files changed, 342 insertions(+), 438 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 07d8a7b..4a227ec 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -72,7 +72,19 @@ extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
>   */
>  static inline unsigned long __pfn_to_mfn(unsigned long pfn)
>  {
> -	return get_phys_to_machine(pfn);
> +	unsigned long mfn;
> +
> +	if (pfn < xen_p2m_size)
> +		mfn = xen_p2m_addr[pfn];
> +	else if (unlikely(pfn < xen_max_p2m_pfn))
> +		return get_phys_to_machine(pfn);
> +	else
> +		return IDENTITY_FRAME(pfn);
> +
> +	if (unlikely(mfn == INVALID_P2M_ENTRY))
> +		return get_phys_to_machine(pfn);
> +
> +	return mfn;
>  }
>  
>  static inline unsigned long pfn_to_mfn(unsigned long pfn)
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 31ca515..0b43c45 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1158,20 +1158,16 @@ static void __init xen_cleanhighmap(unsigned long vaddr,
>  	 * instead of somewhere later and be confusing. */
>  	xen_mc_flush();
>  }
> -static void __init xen_pagetable_p2m_copy(void)
> +
> +static void __init xen_pagetable_p2m_free(void)
>  {
>  	unsigned long size;
>  	unsigned long addr;
> -	unsigned long new_mfn_list;
> -
> -	if (xen_feature(XENFEAT_auto_translated_physmap))
> -		return;
>  
>  	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
>  
> -	new_mfn_list = xen_revector_p2m_tree();
>  	/* No memory or already called. */
> -	if (!new_mfn_list || new_mfn_list == xen_start_info->mfn_list)
> +	if ((unsigned long)xen_p2m_addr == xen_start_info->mfn_list)
>  		return;
>  
>  	/* using __ka address and sticking INVALID_P2M_ENTRY! */
> @@ -1189,8 +1185,6 @@ static void __init xen_pagetable_p2m_copy(void)
>  
>  	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
>  	memblock_free(__pa(xen_start_info->mfn_list), size);
> -	/* And revector! Bye bye old array */
> -	xen_start_info->mfn_list = new_mfn_list;
>  
>  	/* At this stage, cleanup_highmap has already cleaned __ka space
>  	 * from _brk_limit way up to the max_pfn_mapped (which is the end of
> @@ -1214,12 +1208,26 @@ static void __init xen_pagetable_p2m_copy(void)
>  }
>  #endif
>  
> -static void __init xen_pagetable_init(void)
> +static void __init xen_pagetable_p2m_setup(void)
>  {
> -	paging_init();
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
> +	xen_vmalloc_p2m_tree();
> +
>  #ifdef CONFIG_X86_64
> -	xen_pagetable_p2m_copy();
> +	xen_pagetable_p2m_free();
>  #endif
> +	/* And revector! Bye bye old array */
> +	xen_start_info->mfn_list = (unsigned long)xen_p2m_addr;
> +}
> +
> +static void __init xen_pagetable_init(void)
> +{
> +	paging_init();
> +
> +	xen_pagetable_p2m_setup();
> +
>  	/* Allocate and initialize top and mid mfn levels for p2m structure */
>  	xen_build_mfn_list_list();
>  
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 328875a..7df446d 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -3,21 +3,22 @@
>   * guests themselves, but it must also access and update the p2m array
>   * during suspend/resume when all the pages are reallocated.
>   *
> - * The p2m table is logically a flat array, but we implement it as a
> - * three-level tree to allow the address space to be sparse.
> + * The logical flat p2m table is mapped to a linear kernel memory area.
> + * For accesses by Xen a three-level tree linked via mfns only is set up to
> + * allow the address space to be sparse.
>   *
> - *                               Xen
> - *                                |
> - *     p2m_top              p2m_top_mfn
> - *       /  \                   /   \
> - * p2m_mid p2m_mid	p2m_mid_mfn p2m_mid_mfn
> - *    / \      / \         /           /
> - *  p2m p2m p2m p2m p2m p2m p2m ...
> + *               Xen
> + *                |
> + *          p2m_top_mfn
> + *              /   \
> + * p2m_mid_mfn p2m_mid_mfn
> + *         /           /
> + *  p2m p2m p2m ...
>   *
>   * The p2m_mid_mfn pages are mapped by p2m_top_mfn_p.
>   *
> - * The p2m_top and p2m_top_mfn levels are limited to 1 page, so the
> - * maximum representable pseudo-physical address space is:
> + * The p2m_top_mfn level is limited to 1 page, so the maximum representable
> + * pseudo-physical address space is:
>   *  P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * P2M_PER_PAGE pages
>   *
>   * P2M_PER_PAGE depends on the architecture, as a mfn is always
> @@ -30,6 +31,9 @@
>   * leaf entries, or for the top  root, or middle one, for which there is a void
>   * entry, we assume it is  "missing". So (for example)
>   *  pfn_to_mfn(0x90909090)=INVALID_P2M_ENTRY.
> + * We have a dedicated page p2m_missing with all entries being
> + * INVALID_P2M_ENTRY. This page may be referenced multiple times in the p2m
> + * list/tree in case there are multiple areas with P2M_PER_PAGE invalid pfns.
>   *
>   * We also have the possibility of setting 1-1 mappings on certain regions, so
>   * that:
> @@ -39,122 +43,20 @@
>   * PCI BARs, or ACPI spaces), we can create mappings easily because we
>   * get the PFN value to match the MFN.
>   *
> - * For this to work efficiently we have one new page p2m_identity and
> - * allocate (via reserved_brk) any other pages we need to cover the sides
> - * (1GB or 4MB boundary violations). All entries in p2m_identity are set to
> - * INVALID_P2M_ENTRY type (Xen toolstack only recognizes that and MFNs,
> - * no other fancy value).
> + * For this to work efficiently we have one new page p2m_identity. All entries
> + * in p2m_identity are set to INVALID_P2M_ENTRY type (Xen toolstack only
> + * recognizes that and MFNs, no other fancy value).
>   *
>   * On lookup we spot that the entry points to p2m_identity and return the
>   * identity value instead of dereferencing and returning INVALID_P2M_ENTRY.
>   * If the entry points to an allocated page, we just proceed as before and
> - * return the PFN.  If the PFN has IDENTITY_FRAME_BIT set we unmask that in
> + * return the PFN. If the PFN has IDENTITY_FRAME_BIT set we unmask that in
>   * appropriate functions (pfn_to_mfn).
>   *
>   * The reason for having the IDENTITY_FRAME_BIT instead of just returning the
>   * PFN is that we could find ourselves where pfn_to_mfn(pfn)==pfn for a
>   * non-identity pfn. To protect ourselves against we elect to set (and get) the
>   * IDENTITY_FRAME_BIT on all identity mapped PFNs.
> - *
> - * This simplistic diagram is used to explain the more subtle piece of code.
> - * There is also a digram of the P2M at the end that can help.
> - * Imagine your E820 looking as so:
> - *
> - *                    1GB                                           2GB    4GB
> - * /-------------------+---------\/----\         /----------\    /---+-----\
> - * | System RAM        | Sys RAM ||ACPI|         | reserved |    | Sys RAM |
> - * \-------------------+---------/\----/         \----------/    \---+-----/
> - *                               ^- 1029MB                       ^- 2001MB
> - *
> - * [1029MB = 263424 (0x40500), 2001MB = 512256 (0x7D100),
> - *  2048MB = 524288 (0x80000)]
> - *
> - * And dom0_mem=max:3GB,1GB is passed in to the guest, meaning memory past 1GB
> - * is actually not present (would have to kick the balloon driver to put it in).
> - *
> - * When we are told to set the PFNs for identity mapping (see patch: "xen/setup:
> - * Set identity mapping for non-RAM E820 and E820 gaps.") we pass in the start
> - * of the PFN and the end PFN (263424 and 512256 respectively). The first step
> - * is to reserve_brk a top leaf page if the p2m[1] is missing. The top leaf page
> - * covers 512^2 of page estate (1GB) and in case the start or end PFN is not
> - * aligned on 512^2*PAGE_SIZE (1GB) we reserve_brk new middle and leaf pages as
> - * required to split any existing p2m_mid_missing middle pages.
> - *
> - * With the E820 example above, 263424 is not 1GB aligned so we allocate a
> - * reserve_brk page which will cover the PFNs estate from 0x40000 to 0x80000.
> - * Each entry in the allocate page is "missing" (points to p2m_missing).
> - *
> - * Next stage is to determine if we need to do a more granular boundary check
> - * on the 4MB (or 2MB depending on architecture) off the start and end pfn's.
> - * We check if the start pfn and end pfn violate that boundary check, and if
> - * so reserve_brk a (p2m[x][y]) leaf page. This way we have a much finer
> - * granularity of setting which PFNs are missing and which ones are identity.
> - * In our example 263424 and 512256 both fail the check so we reserve_brk two
> - * pages. Populate them with INVALID_P2M_ENTRY (so they both have "missing"
> - * values) and assign them to p2m[1][2] and p2m[1][488] respectively.
> - *
> - * At this point we would at minimum reserve_brk one page, but could be up to
> - * three. Each call to set_phys_range_identity has at maximum a three page
> - * cost. If we were to query the P2M at this stage, all those entries from
> - * start PFN through end PFN (so 1029MB -> 2001MB) would return
> - * INVALID_P2M_ENTRY ("missing").
> - *
> - * The next step is to walk from the start pfn to the end pfn setting
> - * the IDENTITY_FRAME_BIT on each PFN. This is done in set_phys_range_identity.
> - * If we find that the middle entry is pointing to p2m_missing we can swap it
> - * over to p2m_identity - this way covering 4MB (or 2MB) PFN space (and
> - * similarly swapping p2m_mid_missing for p2m_mid_identity for larger regions).
> - * At this point we do not need to worry about boundary aligment (so no need to
> - * reserve_brk a middle page, figure out which PFNs are "missing" and which
> - * ones are identity), as that has been done earlier.  If we find that the
> - * middle leaf is not occupied by p2m_identity or p2m_missing, we dereference
> - * that page (which covers 512 PFNs) and set the appropriate PFN with
> - * IDENTITY_FRAME_BIT. In our example 263424 and 512256 end up there, and we
> - * set from p2m[1][2][256->511] and p2m[1][488][0->256] with
> - * IDENTITY_FRAME_BIT set.
> - *
> - * All other regions that are void (or not filled) either point to p2m_missing
> - * (considered missing) or have the default value of INVALID_P2M_ENTRY (also
> - * considered missing). In our case, p2m[1][2][0->255] and p2m[1][488][257->511]
> - * contain the INVALID_P2M_ENTRY value and are considered "missing."
> - *
> - * Finally, the region beyond the end of of the E820 (4 GB in this example)
> - * is set to be identity (in case there are MMIO regions placed here).
> - *
> - * This is what the p2m ends up looking (for the E820 above) with this
> - * fabulous drawing:
> - *
> - *    p2m         /--------------\
> - *  /-----\       | &mfn_list[0],|                           /-----------------\
> - *  |  0  |------>| &mfn_list[1],|    /---------------\      | ~0, ~0, ..      |
> - *  |-----|       |  ..., ~0, ~0 |    | ~0, ~0, [x]---+----->| IDENTITY [@256] |
> - *  |  1  |---\   \--------------/    | [p2m_identity]+\     | IDENTITY [@257] |
> - *  |-----|    \                      | [p2m_identity]+\\    | ....            |
> - *  |  2  |--\  \-------------------->|  ...          | \\   \----------------/
> - *  |-----|   \                       \---------------/  \\
> - *  |  3  |-\  \                                          \\  p2m_identity [1]
> - *  |-----|  \  \-------------------->/---------------\   /-----------------\
> - *  | ..  |\  |                       | [p2m_identity]+-->| ~0, ~0, ~0, ... |
> - *  \-----/ | |                       | [p2m_identity]+-->| ..., ~0         |
> - *          | |                       | ....          |   \-----------------/
> - *          | |                       +-[x], ~0, ~0.. +\
> - *          | |                       \---------------/ \
> - *          | |                                          \-> /---------------\
> - *          | V  p2m_mid_missing       p2m_missing           | IDENTITY[@0]  |
> - *          | /-----------------\     /------------\         | IDENTITY[@256]|
> - *          | | [p2m_missing]   +---->| ~0, ~0, ...|         | ~0, ~0, ....  |
> - *          | | [p2m_missing]   +---->| ..., ~0    |         \---------------/
> - *          | | ...             |     \------------/
> - *          | \-----------------/
> - *          |
> - *          |     p2m_mid_identity
> - *          |   /-----------------\
> - *          \-->| [p2m_identity]  +---->[1]
> - *              | [p2m_identity]  +---->[1]
> - *              | ...             |
> - *              \-----------------/
> - *
> - * where ~0 is INVALID_P2M_ENTRY. IDENTITY is (PFN | IDENTITY_BIT)
>   */
>  
>  #include <linux/init.h>
> @@ -179,6 +81,8 @@
>  #include "multicalls.h"
>  #include "xen-ops.h"
>  
> +#define PMDS_PER_MID_PAGE	(P2M_MID_PER_PAGE / PTRS_PER_PTE)
> +
>  static void __init m2p_override_init(void);
>  
>  unsigned long *xen_p2m_addr __read_mostly;
> @@ -188,22 +92,15 @@ EXPORT_SYMBOL_GPL(xen_p2m_size);
>  unsigned long xen_max_p2m_pfn __read_mostly;
>  EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
>  
> +static DEFINE_SPINLOCK(p2m_update_lock);
> +
>  static unsigned long *p2m_mid_missing_mfn;
>  static unsigned long *p2m_top_mfn;
>  static unsigned long **p2m_top_mfn_p;
> -
> -/* Placeholders for holes in the address space */
> -static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
> -static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
> -
> -static RESERVE_BRK_ARRAY(unsigned long **, p2m_top, P2M_TOP_PER_PAGE);
> -
> -static RESERVE_BRK_ARRAY(unsigned long, p2m_identity, P2M_PER_PAGE);
> -static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
> -
> -RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
> -
> -static int use_brk = 1;
> +static unsigned long *p2m_missing;
> +static unsigned long *p2m_identity;
> +static pte_t *p2m_missing_pte;
> +static pte_t *p2m_identity_pte;
>  
>  static inline unsigned p2m_top_index(unsigned long pfn)
>  {
> @@ -221,14 +118,6 @@ static inline unsigned p2m_index(unsigned long pfn)
>  	return pfn % P2M_PER_PAGE;
>  }
>  
> -static void p2m_top_init(unsigned long ***top)
> -{
> -	unsigned i;
> -
> -	for (i = 0; i < P2M_TOP_PER_PAGE; i++)
> -		top[i] = p2m_mid_missing;
> -}
> -
>  static void p2m_top_mfn_init(unsigned long *top)
>  {
>  	unsigned i;
> @@ -245,35 +134,32 @@ static void p2m_top_mfn_p_init(unsigned long **top)
>  		top[i] = p2m_mid_missing_mfn;
>  }
>  
> -static void p2m_mid_init(unsigned long **mid, unsigned long *leaf)
> +static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
>  {
>  	unsigned i;
>  
>  	for (i = 0; i < P2M_MID_PER_PAGE; i++)
> -		mid[i] = leaf;
> +		mid[i] = virt_to_mfn(leaf);
>  }
>  
> -static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
> +static void p2m_init(unsigned long *p2m)
>  {
>  	unsigned i;
>  
> -	for (i = 0; i < P2M_MID_PER_PAGE; i++)
> -		mid[i] = virt_to_mfn(leaf);
> +	for (i = 0; i < P2M_PER_PAGE; i++)
> +		p2m[i] = INVALID_P2M_ENTRY;
>  }
>  
> -static void p2m_init(unsigned long *p2m)
> +static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
>  {
>  	unsigned i;
>  
> -	for (i = 0; i < P2M_MID_PER_PAGE; i++)
> -		p2m[i] = INVALID_P2M_ENTRY;
> +	for (i = 0; i < P2M_PER_PAGE; i++)
> +		p2m[i] = IDENTITY_FRAME(pfn + i);
>  }
>  
>  static void * __ref alloc_p2m_page(void)
>  {
> -	if (unlikely(use_brk))
> -		return extend_brk(PAGE_SIZE, PAGE_SIZE);
> -
>  	if (unlikely(!slab_is_available()))
>  		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
>  
> @@ -298,6 +184,9 @@ static void free_p2m_page(void *p)
>  void __ref xen_build_mfn_list_list(void)
>  {
>  	unsigned long pfn;
> +	pte_t *ptep;
> +	unsigned int level, topidx, mididx;
> +	unsigned long *mid_mfn_p;
>  
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return;
> @@ -317,20 +206,22 @@ void __ref xen_build_mfn_list_list(void)
>  		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
>  	}
>  
> -	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += P2M_PER_PAGE) {
> -		unsigned topidx = p2m_top_index(pfn);
> -		unsigned mididx = p2m_mid_index(pfn);
> -		unsigned long **mid;
> -		unsigned long *mid_mfn_p;
> +	for (pfn = 0; pfn < xen_max_p2m_pfn && pfn < MAX_P2M_PFN;
> +	     pfn += P2M_PER_PAGE) {
> +		topidx = p2m_top_index(pfn);
> +		mididx = p2m_mid_index(pfn);
>  
> -		mid = p2m_top[topidx];
>  		mid_mfn_p = p2m_top_mfn_p[topidx];
> +		ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn),
> +				      &level);
> +		BUG_ON(!ptep || level != PG_LEVEL_4K);
> +		ptep = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
>  
>  		/* Don't bother allocating any mfn mid levels if
>  		 * they're just missing, just update the stored mfn,
>  		 * since all could have changed over a migrate.
>  		 */
> -		if (mid == p2m_mid_missing) {
> +		if (ptep == p2m_missing_pte || ptep == p2m_identity_pte) {
>  			BUG_ON(mididx);
>  			BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
>  			p2m_top_mfn[topidx] = virt_to_mfn(p2m_mid_missing_mfn);
> @@ -339,11 +230,6 @@ void __ref xen_build_mfn_list_list(void)
>  		}
>  
>  		if (mid_mfn_p == p2m_mid_missing_mfn) {
> -			/*
> -			 * XXX boot-time only!  We should never find
> -			 * missing parts of the mfn tree after
> -			 * runtime.
> -			 */
>  			mid_mfn_p = alloc_p2m_page();
>  			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
>  
> @@ -351,7 +237,7 @@ void __ref xen_build_mfn_list_list(void)
>  		}
>  
>  		p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
> -		mid_mfn_p[mididx] = virt_to_mfn(mid[mididx]);
> +		mid_mfn_p[mididx] = virt_to_mfn(xen_p2m_addr + pfn);
>  	}
>  }
>  
> @@ -370,154 +256,153 @@ void xen_setup_mfn_list_list(void)
>  /* Set up p2m_top to point to the domain-builder provided p2m pages */
>  void __init xen_build_dynamic_phys_to_machine(void)
>  {
> -	unsigned long *mfn_list;
> -	unsigned long max_pfn;
>  	unsigned long pfn;
>  
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return;
>  
>  	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
> -	mfn_list = (unsigned long *)xen_start_info->mfn_list;
> -	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
> -	xen_max_p2m_pfn = max_pfn;
> -	xen_p2m_size = max_pfn;
> +	xen_p2m_size = ALIGN(xen_start_info->nr_pages, P2M_PER_PAGE);
>  
> -	p2m_missing = alloc_p2m_page();
> -	p2m_init(p2m_missing);
> -	p2m_identity = alloc_p2m_page();
> -	p2m_init(p2m_identity);
> +	for (pfn = xen_start_info->nr_pages; pfn < xen_p2m_size; pfn++)
> +		xen_p2m_addr[pfn] = INVALID_P2M_ENTRY;
>  
> -	p2m_mid_missing = alloc_p2m_page();
> -	p2m_mid_init(p2m_mid_missing, p2m_missing);
> -	p2m_mid_identity = alloc_p2m_page();
> -	p2m_mid_init(p2m_mid_identity, p2m_identity);
> +	xen_max_p2m_pfn = xen_p2m_size;

I recall that in the past we had issues the nr_pages had an odd value
(say 1025MB or such), we had to be careful about filling the
xen_p2m_addr with INVALID_P2M_ENTRY - otherwise they would have the
default of zero. You are doing that - good (note: You need to
test odd size guests too).

But then you are also increasing the xen_max_p2m_pfn to that
value. Shouldn't it be min(xen_start_info->nr_pages, MAX_DOMAIN_PAGES)?

That way it will have the exact value of PFNs we should be using?

Hm, I am actually not sure what the right value we should provide
when we access an PFN > MAX_DOMAIN_PAGES and pfn > nr_pages.

I believe in the past we would just return INVALID_P2M_ENTRY.
But with your 'xen_rebuild_p2m_list' it would create it with
the MFN values.

Or should we just remove the MAX_DOMANI_PAGES config option here?
	
> +}
>  
> -	p2m_top = alloc_p2m_page();
> -	p2m_top_init(p2m_top);
> +#define P2M_TYPE_IDENTITY	0
> +#define P2M_TYPE_MISSING	1
> +#define P2M_TYPE_PFN		2
> +#define P2M_TYPE_UNKNOWN	3
>  
> -	/*
> -	 * The domain builder gives us a pre-constructed p2m array in
> -	 * mfn_list for all the pages initially given to us, so we just
> -	 * need to graft that into our tree structure.
> -	 */
> -	for (pfn = 0; pfn < max_pfn; pfn += P2M_PER_PAGE) {
> -		unsigned topidx = p2m_top_index(pfn);
> -		unsigned mididx = p2m_mid_index(pfn);
> +static int xen_p2m_elem_type(unsigned long pfn)
> +{
> +	unsigned long mfn;
>  
> -		if (p2m_top[topidx] == p2m_mid_missing) {
> -			unsigned long **mid = alloc_p2m_page();
> -			p2m_mid_init(mid, p2m_missing);
> +	if (pfn >= xen_p2m_size)
> +		return P2M_TYPE_IDENTITY;
>  
> -			p2m_top[topidx] = mid;
> -		}
> +	mfn = xen_p2m_addr[pfn];
>  
> -		/*
> -		 * As long as the mfn_list has enough entries to completely
> -		 * fill a p2m page, pointing into the array is ok. But if
> -		 * not the entries beyond the last pfn will be undefined.
> -		 */
> -		if (unlikely(pfn + P2M_PER_PAGE > max_pfn)) {
> -			unsigned long p2midx;
> +	if (mfn == INVALID_P2M_ENTRY)
> +		return P2M_TYPE_MISSING;
>  
> -			p2midx = max_pfn % P2M_PER_PAGE;
> -			for ( ; p2midx < P2M_PER_PAGE; p2midx++)
> -				mfn_list[pfn + p2midx] = INVALID_P2M_ENTRY;
> -		}
> -		p2m_top[topidx][mididx] = &mfn_list[pfn];
> -	}
> +	if (mfn & IDENTITY_FRAME_BIT)
> +		return P2M_TYPE_IDENTITY;
> +
> +	return P2M_TYPE_PFN;
>  }
> -#ifdef CONFIG_X86_64
> -unsigned long __init xen_revector_p2m_tree(void)
> +
> +static void __init xen_rebuild_p2m_list(unsigned long *p2m)
>  {
> -	unsigned long va_start;
> -	unsigned long va_end;
> +	unsigned int i, chunk;
>  	unsigned long pfn;
> -	unsigned long pfn_free = 0;
> -	unsigned long *mfn_list = NULL;
> -	unsigned long size;
> -
> -	use_brk = 0;
> -	va_start = xen_start_info->mfn_list;
> -	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
> -	 * so make sure it is rounded up to that */
> -	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
> -	va_end = va_start + size;
> -
> -	/* If we were revectored already, don't do it again. */
> -	if (va_start <= __START_KERNEL_map && va_start >= __PAGE_OFFSET)
> -		return 0;
> -
> -	mfn_list = alloc_bootmem_align(size, PAGE_SIZE);
> -	if (!mfn_list) {
> -		pr_warn("Could not allocate space for a new P2M tree!\n");
> -		return xen_start_info->mfn_list;
> -	}
> -	/* Fill it out with INVALID_P2M_ENTRY value */
> -	memset(mfn_list, 0xFF, size);
> -
> -	for (pfn = 0; pfn < ALIGN(MAX_DOMAIN_PAGES, P2M_PER_PAGE); pfn += P2M_PER_PAGE) {
> -		unsigned topidx = p2m_top_index(pfn);
> -		unsigned mididx;
> -		unsigned long *mid_p;
> +	unsigned long *mfns;
> +	pte_t *ptep;
> +	pmd_t *pmdp;
> +	int type;
>  
> -		if (!p2m_top[topidx])
> -			continue;
> +	p2m_missing = alloc_p2m_page();
> +	p2m_init(p2m_missing);
> +	p2m_identity = alloc_p2m_page();
> +	p2m_init(p2m_identity);
>  
> -		if (p2m_top[topidx] == p2m_mid_missing)
> -			continue;
> +	p2m_missing_pte = alloc_p2m_page();
> +	paravirt_alloc_pte(&init_mm, __pa(p2m_missing_pte) >> PAGE_SHIFT);
> +	p2m_identity_pte = alloc_p2m_page();
> +	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
> +	for (i = 0; i < PTRS_PER_PTE; i++) {
> +		set_pte(p2m_missing_pte + i,
> +			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));

PAGE_KERNEL_RO?
> +		set_pte(p2m_identity_pte + i,
> +			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));

PAGE_KERNEL_RO ?

(or wait, this is done in the next patch!)
> +	}
>  
> -		mididx = p2m_mid_index(pfn);
> -		mid_p = p2m_top[topidx][mididx];
> -		if (!mid_p)
> -			continue;
> -		if ((mid_p == p2m_missing) || (mid_p == p2m_identity))
> +	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
> +		/*
> +		 * Try to map missing/identity PMDs or p2m-pages if possible.
> +		 * We have to respect the structure of the mfn_list_list
> +		 * which will be built a little bit later.

Could you say exactly when 'little bit later' is?

> +		 * Chunk size to test is one p2m page if we are in the middle
> +		 * of a mfn_list_list mid page and the complete mid page area
> +		 * if we are at index 0 of the mid page. Please note that a
> +		 * mid page might cover more than one PMD, e.g. on 32 bit PAE
> +		 * kernels.
> +		 */
> +		chunk = (pfn & (P2M_PER_PAGE * P2M_MID_PER_PAGE - 1)) ?
> +			P2M_PER_PAGE : P2M_PER_PAGE * P2M_MID_PER_PAGE;
> +
> +		type = xen_p2m_elem_type(pfn);
> +		i = 0;
> +		if (type != P2M_TYPE_PFN)
> +			for (i = 1; i < chunk; i++)
> +				if (xen_p2m_elem_type(pfn + i) != type)
> +					break;
> +		if (i < chunk)
> +			/* Reset to minimal chunk size. */
> +			chunk = P2M_PER_PAGE;

Say this is hit, and the values are: i == 3, chunk = 511.
The next region is an identify (or should be).

The initial xen_p2m_addr + i + pfn has INVALID_P2M_ENTRY (since 
that is what the xen_build_dynamic_phys_to_machine would
setup).
> +
> +		if (type == P2M_TYPE_PFN || i < chunk) {
> +			/* Use initial p2m page contents. */
> +#ifdef CONFIG_X86_64
> +			mfns = alloc_p2m_page();

And we get here. We allocate the page - which has random values.

> +			copy_page(mfns, xen_p2m_addr + pfn);

And then we copy the whole page over. So the values past the
pfn+i+xen_p2m_addr will be INVALID_P2M_ENTRY. But should it
be IDENTIFY?

[edit: I forgot about xen/setup.c calling set_phys_range_identity
for the last E820 entry, so that will take care of marking
xen_p2m_addr+pfn+i and past to IDENTIFY]. Wheew !

> +#else
> +			mfns = xen_p2m_addr + pfn;
> +#endif
> +			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
> +			set_pte(ptep,
> +				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
>  			continue;
> +		}
>  
> -		if ((unsigned long)mid_p == INVALID_P2M_ENTRY)
> +		if (chunk == P2M_PER_PAGE) {
> +			/* Map complete missing or identity p2m-page. */
> +			mfns = (type == P2M_TYPE_MISSING) ?
> +				p2m_missing : p2m_identity;
> +			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
> +			set_pte(ptep,
> +				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
>  			continue;
> +		}
>  
> -		/* The old va. Rebase it on mfn_list */
> -		if (mid_p >= (unsigned long *)va_start && mid_p <= (unsigned long *)va_end) {
> -			unsigned long *new;
> +		/* Complete missing or identity PMD(s) can be mapped. */
> +		ptep = (type == P2M_TYPE_MISSING) ?
> +			p2m_missing_pte : p2m_identity_pte;
> +		for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
> +			pmdp = populate_extra_pmd(
> +				(unsigned long)(p2m + pfn + i * PTRS_PER_PTE));
> +			set_pmd(pmdp, __pmd(__pa(ptep) | _KERNPG_TABLE));
> +		}
> +	}
> +}
>  
> -			if (pfn_free  > (size / sizeof(unsigned long))) {
> -				WARN(1, "Only allocated for %ld pages, but we want %ld!\n",
> -				     size / sizeof(unsigned long), pfn_free);
> -				return 0;
> -			}
> -			new = &mfn_list[pfn_free];
> +void __init xen_vmalloc_p2m_tree(void)
> +{
> +	static struct vm_struct vm;
>  
> -			copy_page(new, mid_p);
> -			p2m_top[topidx][mididx] = &mfn_list[pfn_free];
> +	vm.flags = VM_ALLOC;
> +	vm.size = ALIGN(sizeof(unsigned long) * xen_max_p2m_pfn,
> +			PMD_SIZE * PMDS_PER_MID_PAGE);
> +	vm_area_register_early(&vm, PMD_SIZE * PMDS_PER_MID_PAGE);
> +	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);

What happens if somebody boots with 'vmalloc=1MB' and we boot
an 400GB guest?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 20:38:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20:38:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrC0n-0003p6-7N; Wed, 19 Nov 2014 20:38:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrC0m-0003p1-4W
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 20:38:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FA/41-09936-7AFFC645; Wed, 19 Nov 2014 20:37:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416429476!13965650!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12839 invoked from network); 19 Nov 2014 20:37:58 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:37:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKbf8W018285
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:37:42 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKbdJh028718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 20:37:40 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJKbcRp017527; Wed, 19 Nov 2014 20:37:38 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:37:37 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 90DDD118331; Wed, 19 Nov 2014 15:37:35 -0500 (EST)
Date: Wed, 19 Nov 2014 15:37:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119203735.GA18495@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-8-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-8-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:43:45AM +0100, Juergen Gross wrote:
> At start of the day the Xen hypervisor presents a contiguous mfn list
> to a pv-domain. In order to support sparse memory this mfn list is
> accessed via a three level p2m tree built early in the boot process.
> Whenever the system needs the mfn associated with a pfn this tree is
> used to find the mfn.
> 
> Instead of using a software walked tree for accessing a specific mfn
> list entry this patch is creating a virtual address area for the
> entire possible mfn list including memory holes. The holes are
> covered by mapping a pre-defined  page consisting only of "invalid
> mfn" entries. Access to a mfn entry is possible by just using the
> virtual base address of the mfn list and the pfn as index into that
> list. This speeds up the (hot) path of determining the mfn of a
> pfn.
> 
> Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
> showed following improvements:
> 
> Elapsed time: 32:50 ->  32:35
> System:       18:07 ->  17:47
> User:        104:00 -> 103:30
> 
> Tested on 64 bit dom0 and 32 bit domU.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/include/asm/xen/page.h |  14 +-
>  arch/x86/xen/mmu.c              |  32 +-
>  arch/x86/xen/p2m.c              | 732 +++++++++++++++++-----------------------
>  arch/x86/xen/xen-ops.h          |   2 +-
>  4 files changed, 342 insertions(+), 438 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 07d8a7b..4a227ec 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -72,7 +72,19 @@ extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
>   */
>  static inline unsigned long __pfn_to_mfn(unsigned long pfn)
>  {
> -	return get_phys_to_machine(pfn);
> +	unsigned long mfn;
> +
> +	if (pfn < xen_p2m_size)
> +		mfn = xen_p2m_addr[pfn];
> +	else if (unlikely(pfn < xen_max_p2m_pfn))
> +		return get_phys_to_machine(pfn);
> +	else
> +		return IDENTITY_FRAME(pfn);
> +
> +	if (unlikely(mfn == INVALID_P2M_ENTRY))
> +		return get_phys_to_machine(pfn);
> +
> +	return mfn;
>  }
>  
>  static inline unsigned long pfn_to_mfn(unsigned long pfn)
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 31ca515..0b43c45 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1158,20 +1158,16 @@ static void __init xen_cleanhighmap(unsigned long vaddr,
>  	 * instead of somewhere later and be confusing. */
>  	xen_mc_flush();
>  }
> -static void __init xen_pagetable_p2m_copy(void)
> +
> +static void __init xen_pagetable_p2m_free(void)
>  {
>  	unsigned long size;
>  	unsigned long addr;
> -	unsigned long new_mfn_list;
> -
> -	if (xen_feature(XENFEAT_auto_translated_physmap))
> -		return;
>  
>  	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
>  
> -	new_mfn_list = xen_revector_p2m_tree();
>  	/* No memory or already called. */
> -	if (!new_mfn_list || new_mfn_list == xen_start_info->mfn_list)
> +	if ((unsigned long)xen_p2m_addr == xen_start_info->mfn_list)
>  		return;
>  
>  	/* using __ka address and sticking INVALID_P2M_ENTRY! */
> @@ -1189,8 +1185,6 @@ static void __init xen_pagetable_p2m_copy(void)
>  
>  	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
>  	memblock_free(__pa(xen_start_info->mfn_list), size);
> -	/* And revector! Bye bye old array */
> -	xen_start_info->mfn_list = new_mfn_list;
>  
>  	/* At this stage, cleanup_highmap has already cleaned __ka space
>  	 * from _brk_limit way up to the max_pfn_mapped (which is the end of
> @@ -1214,12 +1208,26 @@ static void __init xen_pagetable_p2m_copy(void)
>  }
>  #endif
>  
> -static void __init xen_pagetable_init(void)
> +static void __init xen_pagetable_p2m_setup(void)
>  {
> -	paging_init();
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
> +	xen_vmalloc_p2m_tree();
> +
>  #ifdef CONFIG_X86_64
> -	xen_pagetable_p2m_copy();
> +	xen_pagetable_p2m_free();
>  #endif
> +	/* And revector! Bye bye old array */
> +	xen_start_info->mfn_list = (unsigned long)xen_p2m_addr;
> +}
> +
> +static void __init xen_pagetable_init(void)
> +{
> +	paging_init();
> +
> +	xen_pagetable_p2m_setup();
> +
>  	/* Allocate and initialize top and mid mfn levels for p2m structure */
>  	xen_build_mfn_list_list();
>  
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 328875a..7df446d 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -3,21 +3,22 @@
>   * guests themselves, but it must also access and update the p2m array
>   * during suspend/resume when all the pages are reallocated.
>   *
> - * The p2m table is logically a flat array, but we implement it as a
> - * three-level tree to allow the address space to be sparse.
> + * The logical flat p2m table is mapped to a linear kernel memory area.
> + * For accesses by Xen a three-level tree linked via mfns only is set up to
> + * allow the address space to be sparse.
>   *
> - *                               Xen
> - *                                |
> - *     p2m_top              p2m_top_mfn
> - *       /  \                   /   \
> - * p2m_mid p2m_mid	p2m_mid_mfn p2m_mid_mfn
> - *    / \      / \         /           /
> - *  p2m p2m p2m p2m p2m p2m p2m ...
> + *               Xen
> + *                |
> + *          p2m_top_mfn
> + *              /   \
> + * p2m_mid_mfn p2m_mid_mfn
> + *         /           /
> + *  p2m p2m p2m ...
>   *
>   * The p2m_mid_mfn pages are mapped by p2m_top_mfn_p.
>   *
> - * The p2m_top and p2m_top_mfn levels are limited to 1 page, so the
> - * maximum representable pseudo-physical address space is:
> + * The p2m_top_mfn level is limited to 1 page, so the maximum representable
> + * pseudo-physical address space is:
>   *  P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * P2M_PER_PAGE pages
>   *
>   * P2M_PER_PAGE depends on the architecture, as a mfn is always
> @@ -30,6 +31,9 @@
>   * leaf entries, or for the top  root, or middle one, for which there is a void
>   * entry, we assume it is  "missing". So (for example)
>   *  pfn_to_mfn(0x90909090)=INVALID_P2M_ENTRY.
> + * We have a dedicated page p2m_missing with all entries being
> + * INVALID_P2M_ENTRY. This page may be referenced multiple times in the p2m
> + * list/tree in case there are multiple areas with P2M_PER_PAGE invalid pfns.
>   *
>   * We also have the possibility of setting 1-1 mappings on certain regions, so
>   * that:
> @@ -39,122 +43,20 @@
>   * PCI BARs, or ACPI spaces), we can create mappings easily because we
>   * get the PFN value to match the MFN.
>   *
> - * For this to work efficiently we have one new page p2m_identity and
> - * allocate (via reserved_brk) any other pages we need to cover the sides
> - * (1GB or 4MB boundary violations). All entries in p2m_identity are set to
> - * INVALID_P2M_ENTRY type (Xen toolstack only recognizes that and MFNs,
> - * no other fancy value).
> + * For this to work efficiently we have one new page p2m_identity. All entries
> + * in p2m_identity are set to INVALID_P2M_ENTRY type (Xen toolstack only
> + * recognizes that and MFNs, no other fancy value).
>   *
>   * On lookup we spot that the entry points to p2m_identity and return the
>   * identity value instead of dereferencing and returning INVALID_P2M_ENTRY.
>   * If the entry points to an allocated page, we just proceed as before and
> - * return the PFN.  If the PFN has IDENTITY_FRAME_BIT set we unmask that in
> + * return the PFN. If the PFN has IDENTITY_FRAME_BIT set we unmask that in
>   * appropriate functions (pfn_to_mfn).
>   *
>   * The reason for having the IDENTITY_FRAME_BIT instead of just returning the
>   * PFN is that we could find ourselves where pfn_to_mfn(pfn)==pfn for a
>   * non-identity pfn. To protect ourselves against we elect to set (and get) the
>   * IDENTITY_FRAME_BIT on all identity mapped PFNs.
> - *
> - * This simplistic diagram is used to explain the more subtle piece of code.
> - * There is also a digram of the P2M at the end that can help.
> - * Imagine your E820 looking as so:
> - *
> - *                    1GB                                           2GB    4GB
> - * /-------------------+---------\/----\         /----------\    /---+-----\
> - * | System RAM        | Sys RAM ||ACPI|         | reserved |    | Sys RAM |
> - * \-------------------+---------/\----/         \----------/    \---+-----/
> - *                               ^- 1029MB                       ^- 2001MB
> - *
> - * [1029MB = 263424 (0x40500), 2001MB = 512256 (0x7D100),
> - *  2048MB = 524288 (0x80000)]
> - *
> - * And dom0_mem=max:3GB,1GB is passed in to the guest, meaning memory past 1GB
> - * is actually not present (would have to kick the balloon driver to put it in).
> - *
> - * When we are told to set the PFNs for identity mapping (see patch: "xen/setup:
> - * Set identity mapping for non-RAM E820 and E820 gaps.") we pass in the start
> - * of the PFN and the end PFN (263424 and 512256 respectively). The first step
> - * is to reserve_brk a top leaf page if the p2m[1] is missing. The top leaf page
> - * covers 512^2 of page estate (1GB) and in case the start or end PFN is not
> - * aligned on 512^2*PAGE_SIZE (1GB) we reserve_brk new middle and leaf pages as
> - * required to split any existing p2m_mid_missing middle pages.
> - *
> - * With the E820 example above, 263424 is not 1GB aligned so we allocate a
> - * reserve_brk page which will cover the PFNs estate from 0x40000 to 0x80000.
> - * Each entry in the allocate page is "missing" (points to p2m_missing).
> - *
> - * Next stage is to determine if we need to do a more granular boundary check
> - * on the 4MB (or 2MB depending on architecture) off the start and end pfn's.
> - * We check if the start pfn and end pfn violate that boundary check, and if
> - * so reserve_brk a (p2m[x][y]) leaf page. This way we have a much finer
> - * granularity of setting which PFNs are missing and which ones are identity.
> - * In our example 263424 and 512256 both fail the check so we reserve_brk two
> - * pages. Populate them with INVALID_P2M_ENTRY (so they both have "missing"
> - * values) and assign them to p2m[1][2] and p2m[1][488] respectively.
> - *
> - * At this point we would at minimum reserve_brk one page, but could be up to
> - * three. Each call to set_phys_range_identity has at maximum a three page
> - * cost. If we were to query the P2M at this stage, all those entries from
> - * start PFN through end PFN (so 1029MB -> 2001MB) would return
> - * INVALID_P2M_ENTRY ("missing").
> - *
> - * The next step is to walk from the start pfn to the end pfn setting
> - * the IDENTITY_FRAME_BIT on each PFN. This is done in set_phys_range_identity.
> - * If we find that the middle entry is pointing to p2m_missing we can swap it
> - * over to p2m_identity - this way covering 4MB (or 2MB) PFN space (and
> - * similarly swapping p2m_mid_missing for p2m_mid_identity for larger regions).
> - * At this point we do not need to worry about boundary aligment (so no need to
> - * reserve_brk a middle page, figure out which PFNs are "missing" and which
> - * ones are identity), as that has been done earlier.  If we find that the
> - * middle leaf is not occupied by p2m_identity or p2m_missing, we dereference
> - * that page (which covers 512 PFNs) and set the appropriate PFN with
> - * IDENTITY_FRAME_BIT. In our example 263424 and 512256 end up there, and we
> - * set from p2m[1][2][256->511] and p2m[1][488][0->256] with
> - * IDENTITY_FRAME_BIT set.
> - *
> - * All other regions that are void (or not filled) either point to p2m_missing
> - * (considered missing) or have the default value of INVALID_P2M_ENTRY (also
> - * considered missing). In our case, p2m[1][2][0->255] and p2m[1][488][257->511]
> - * contain the INVALID_P2M_ENTRY value and are considered "missing."
> - *
> - * Finally, the region beyond the end of of the E820 (4 GB in this example)
> - * is set to be identity (in case there are MMIO regions placed here).
> - *
> - * This is what the p2m ends up looking (for the E820 above) with this
> - * fabulous drawing:
> - *
> - *    p2m         /--------------\
> - *  /-----\       | &mfn_list[0],|                           /-----------------\
> - *  |  0  |------>| &mfn_list[1],|    /---------------\      | ~0, ~0, ..      |
> - *  |-----|       |  ..., ~0, ~0 |    | ~0, ~0, [x]---+----->| IDENTITY [@256] |
> - *  |  1  |---\   \--------------/    | [p2m_identity]+\     | IDENTITY [@257] |
> - *  |-----|    \                      | [p2m_identity]+\\    | ....            |
> - *  |  2  |--\  \-------------------->|  ...          | \\   \----------------/
> - *  |-----|   \                       \---------------/  \\
> - *  |  3  |-\  \                                          \\  p2m_identity [1]
> - *  |-----|  \  \-------------------->/---------------\   /-----------------\
> - *  | ..  |\  |                       | [p2m_identity]+-->| ~0, ~0, ~0, ... |
> - *  \-----/ | |                       | [p2m_identity]+-->| ..., ~0         |
> - *          | |                       | ....          |   \-----------------/
> - *          | |                       +-[x], ~0, ~0.. +\
> - *          | |                       \---------------/ \
> - *          | |                                          \-> /---------------\
> - *          | V  p2m_mid_missing       p2m_missing           | IDENTITY[@0]  |
> - *          | /-----------------\     /------------\         | IDENTITY[@256]|
> - *          | | [p2m_missing]   +---->| ~0, ~0, ...|         | ~0, ~0, ....  |
> - *          | | [p2m_missing]   +---->| ..., ~0    |         \---------------/
> - *          | | ...             |     \------------/
> - *          | \-----------------/
> - *          |
> - *          |     p2m_mid_identity
> - *          |   /-----------------\
> - *          \-->| [p2m_identity]  +---->[1]
> - *              | [p2m_identity]  +---->[1]
> - *              | ...             |
> - *              \-----------------/
> - *
> - * where ~0 is INVALID_P2M_ENTRY. IDENTITY is (PFN | IDENTITY_BIT)
>   */
>  
>  #include <linux/init.h>
> @@ -179,6 +81,8 @@
>  #include "multicalls.h"
>  #include "xen-ops.h"
>  
> +#define PMDS_PER_MID_PAGE	(P2M_MID_PER_PAGE / PTRS_PER_PTE)
> +
>  static void __init m2p_override_init(void);
>  
>  unsigned long *xen_p2m_addr __read_mostly;
> @@ -188,22 +92,15 @@ EXPORT_SYMBOL_GPL(xen_p2m_size);
>  unsigned long xen_max_p2m_pfn __read_mostly;
>  EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
>  
> +static DEFINE_SPINLOCK(p2m_update_lock);
> +
>  static unsigned long *p2m_mid_missing_mfn;
>  static unsigned long *p2m_top_mfn;
>  static unsigned long **p2m_top_mfn_p;
> -
> -/* Placeholders for holes in the address space */
> -static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
> -static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
> -
> -static RESERVE_BRK_ARRAY(unsigned long **, p2m_top, P2M_TOP_PER_PAGE);
> -
> -static RESERVE_BRK_ARRAY(unsigned long, p2m_identity, P2M_PER_PAGE);
> -static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
> -
> -RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
> -
> -static int use_brk = 1;
> +static unsigned long *p2m_missing;
> +static unsigned long *p2m_identity;
> +static pte_t *p2m_missing_pte;
> +static pte_t *p2m_identity_pte;
>  
>  static inline unsigned p2m_top_index(unsigned long pfn)
>  {
> @@ -221,14 +118,6 @@ static inline unsigned p2m_index(unsigned long pfn)
>  	return pfn % P2M_PER_PAGE;
>  }
>  
> -static void p2m_top_init(unsigned long ***top)
> -{
> -	unsigned i;
> -
> -	for (i = 0; i < P2M_TOP_PER_PAGE; i++)
> -		top[i] = p2m_mid_missing;
> -}
> -
>  static void p2m_top_mfn_init(unsigned long *top)
>  {
>  	unsigned i;
> @@ -245,35 +134,32 @@ static void p2m_top_mfn_p_init(unsigned long **top)
>  		top[i] = p2m_mid_missing_mfn;
>  }
>  
> -static void p2m_mid_init(unsigned long **mid, unsigned long *leaf)
> +static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
>  {
>  	unsigned i;
>  
>  	for (i = 0; i < P2M_MID_PER_PAGE; i++)
> -		mid[i] = leaf;
> +		mid[i] = virt_to_mfn(leaf);
>  }
>  
> -static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
> +static void p2m_init(unsigned long *p2m)
>  {
>  	unsigned i;
>  
> -	for (i = 0; i < P2M_MID_PER_PAGE; i++)
> -		mid[i] = virt_to_mfn(leaf);
> +	for (i = 0; i < P2M_PER_PAGE; i++)
> +		p2m[i] = INVALID_P2M_ENTRY;
>  }
>  
> -static void p2m_init(unsigned long *p2m)
> +static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
>  {
>  	unsigned i;
>  
> -	for (i = 0; i < P2M_MID_PER_PAGE; i++)
> -		p2m[i] = INVALID_P2M_ENTRY;
> +	for (i = 0; i < P2M_PER_PAGE; i++)
> +		p2m[i] = IDENTITY_FRAME(pfn + i);
>  }
>  
>  static void * __ref alloc_p2m_page(void)
>  {
> -	if (unlikely(use_brk))
> -		return extend_brk(PAGE_SIZE, PAGE_SIZE);
> -
>  	if (unlikely(!slab_is_available()))
>  		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
>  
> @@ -298,6 +184,9 @@ static void free_p2m_page(void *p)
>  void __ref xen_build_mfn_list_list(void)
>  {
>  	unsigned long pfn;
> +	pte_t *ptep;
> +	unsigned int level, topidx, mididx;
> +	unsigned long *mid_mfn_p;
>  
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return;
> @@ -317,20 +206,22 @@ void __ref xen_build_mfn_list_list(void)
>  		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
>  	}
>  
> -	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += P2M_PER_PAGE) {
> -		unsigned topidx = p2m_top_index(pfn);
> -		unsigned mididx = p2m_mid_index(pfn);
> -		unsigned long **mid;
> -		unsigned long *mid_mfn_p;
> +	for (pfn = 0; pfn < xen_max_p2m_pfn && pfn < MAX_P2M_PFN;
> +	     pfn += P2M_PER_PAGE) {
> +		topidx = p2m_top_index(pfn);
> +		mididx = p2m_mid_index(pfn);
>  
> -		mid = p2m_top[topidx];
>  		mid_mfn_p = p2m_top_mfn_p[topidx];
> +		ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn),
> +				      &level);
> +		BUG_ON(!ptep || level != PG_LEVEL_4K);
> +		ptep = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
>  
>  		/* Don't bother allocating any mfn mid levels if
>  		 * they're just missing, just update the stored mfn,
>  		 * since all could have changed over a migrate.
>  		 */
> -		if (mid == p2m_mid_missing) {
> +		if (ptep == p2m_missing_pte || ptep == p2m_identity_pte) {
>  			BUG_ON(mididx);
>  			BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
>  			p2m_top_mfn[topidx] = virt_to_mfn(p2m_mid_missing_mfn);
> @@ -339,11 +230,6 @@ void __ref xen_build_mfn_list_list(void)
>  		}
>  
>  		if (mid_mfn_p == p2m_mid_missing_mfn) {
> -			/*
> -			 * XXX boot-time only!  We should never find
> -			 * missing parts of the mfn tree after
> -			 * runtime.
> -			 */
>  			mid_mfn_p = alloc_p2m_page();
>  			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
>  
> @@ -351,7 +237,7 @@ void __ref xen_build_mfn_list_list(void)
>  		}
>  
>  		p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
> -		mid_mfn_p[mididx] = virt_to_mfn(mid[mididx]);
> +		mid_mfn_p[mididx] = virt_to_mfn(xen_p2m_addr + pfn);
>  	}
>  }
>  
> @@ -370,154 +256,153 @@ void xen_setup_mfn_list_list(void)
>  /* Set up p2m_top to point to the domain-builder provided p2m pages */
>  void __init xen_build_dynamic_phys_to_machine(void)
>  {
> -	unsigned long *mfn_list;
> -	unsigned long max_pfn;
>  	unsigned long pfn;
>  
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return;
>  
>  	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
> -	mfn_list = (unsigned long *)xen_start_info->mfn_list;
> -	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
> -	xen_max_p2m_pfn = max_pfn;
> -	xen_p2m_size = max_pfn;
> +	xen_p2m_size = ALIGN(xen_start_info->nr_pages, P2M_PER_PAGE);
>  
> -	p2m_missing = alloc_p2m_page();
> -	p2m_init(p2m_missing);
> -	p2m_identity = alloc_p2m_page();
> -	p2m_init(p2m_identity);
> +	for (pfn = xen_start_info->nr_pages; pfn < xen_p2m_size; pfn++)
> +		xen_p2m_addr[pfn] = INVALID_P2M_ENTRY;
>  
> -	p2m_mid_missing = alloc_p2m_page();
> -	p2m_mid_init(p2m_mid_missing, p2m_missing);
> -	p2m_mid_identity = alloc_p2m_page();
> -	p2m_mid_init(p2m_mid_identity, p2m_identity);
> +	xen_max_p2m_pfn = xen_p2m_size;

I recall that in the past we had issues the nr_pages had an odd value
(say 1025MB or such), we had to be careful about filling the
xen_p2m_addr with INVALID_P2M_ENTRY - otherwise they would have the
default of zero. You are doing that - good (note: You need to
test odd size guests too).

But then you are also increasing the xen_max_p2m_pfn to that
value. Shouldn't it be min(xen_start_info->nr_pages, MAX_DOMAIN_PAGES)?

That way it will have the exact value of PFNs we should be using?

Hm, I am actually not sure what the right value we should provide
when we access an PFN > MAX_DOMAIN_PAGES and pfn > nr_pages.

I believe in the past we would just return INVALID_P2M_ENTRY.
But with your 'xen_rebuild_p2m_list' it would create it with
the MFN values.

Or should we just remove the MAX_DOMANI_PAGES config option here?
	
> +}
>  
> -	p2m_top = alloc_p2m_page();
> -	p2m_top_init(p2m_top);
> +#define P2M_TYPE_IDENTITY	0
> +#define P2M_TYPE_MISSING	1
> +#define P2M_TYPE_PFN		2
> +#define P2M_TYPE_UNKNOWN	3
>  
> -	/*
> -	 * The domain builder gives us a pre-constructed p2m array in
> -	 * mfn_list for all the pages initially given to us, so we just
> -	 * need to graft that into our tree structure.
> -	 */
> -	for (pfn = 0; pfn < max_pfn; pfn += P2M_PER_PAGE) {
> -		unsigned topidx = p2m_top_index(pfn);
> -		unsigned mididx = p2m_mid_index(pfn);
> +static int xen_p2m_elem_type(unsigned long pfn)
> +{
> +	unsigned long mfn;
>  
> -		if (p2m_top[topidx] == p2m_mid_missing) {
> -			unsigned long **mid = alloc_p2m_page();
> -			p2m_mid_init(mid, p2m_missing);
> +	if (pfn >= xen_p2m_size)
> +		return P2M_TYPE_IDENTITY;
>  
> -			p2m_top[topidx] = mid;
> -		}
> +	mfn = xen_p2m_addr[pfn];
>  
> -		/*
> -		 * As long as the mfn_list has enough entries to completely
> -		 * fill a p2m page, pointing into the array is ok. But if
> -		 * not the entries beyond the last pfn will be undefined.
> -		 */
> -		if (unlikely(pfn + P2M_PER_PAGE > max_pfn)) {
> -			unsigned long p2midx;
> +	if (mfn == INVALID_P2M_ENTRY)
> +		return P2M_TYPE_MISSING;
>  
> -			p2midx = max_pfn % P2M_PER_PAGE;
> -			for ( ; p2midx < P2M_PER_PAGE; p2midx++)
> -				mfn_list[pfn + p2midx] = INVALID_P2M_ENTRY;
> -		}
> -		p2m_top[topidx][mididx] = &mfn_list[pfn];
> -	}
> +	if (mfn & IDENTITY_FRAME_BIT)
> +		return P2M_TYPE_IDENTITY;
> +
> +	return P2M_TYPE_PFN;
>  }
> -#ifdef CONFIG_X86_64
> -unsigned long __init xen_revector_p2m_tree(void)
> +
> +static void __init xen_rebuild_p2m_list(unsigned long *p2m)
>  {
> -	unsigned long va_start;
> -	unsigned long va_end;
> +	unsigned int i, chunk;
>  	unsigned long pfn;
> -	unsigned long pfn_free = 0;
> -	unsigned long *mfn_list = NULL;
> -	unsigned long size;
> -
> -	use_brk = 0;
> -	va_start = xen_start_info->mfn_list;
> -	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
> -	 * so make sure it is rounded up to that */
> -	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
> -	va_end = va_start + size;
> -
> -	/* If we were revectored already, don't do it again. */
> -	if (va_start <= __START_KERNEL_map && va_start >= __PAGE_OFFSET)
> -		return 0;
> -
> -	mfn_list = alloc_bootmem_align(size, PAGE_SIZE);
> -	if (!mfn_list) {
> -		pr_warn("Could not allocate space for a new P2M tree!\n");
> -		return xen_start_info->mfn_list;
> -	}
> -	/* Fill it out with INVALID_P2M_ENTRY value */
> -	memset(mfn_list, 0xFF, size);
> -
> -	for (pfn = 0; pfn < ALIGN(MAX_DOMAIN_PAGES, P2M_PER_PAGE); pfn += P2M_PER_PAGE) {
> -		unsigned topidx = p2m_top_index(pfn);
> -		unsigned mididx;
> -		unsigned long *mid_p;
> +	unsigned long *mfns;
> +	pte_t *ptep;
> +	pmd_t *pmdp;
> +	int type;
>  
> -		if (!p2m_top[topidx])
> -			continue;
> +	p2m_missing = alloc_p2m_page();
> +	p2m_init(p2m_missing);
> +	p2m_identity = alloc_p2m_page();
> +	p2m_init(p2m_identity);
>  
> -		if (p2m_top[topidx] == p2m_mid_missing)
> -			continue;
> +	p2m_missing_pte = alloc_p2m_page();
> +	paravirt_alloc_pte(&init_mm, __pa(p2m_missing_pte) >> PAGE_SHIFT);
> +	p2m_identity_pte = alloc_p2m_page();
> +	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
> +	for (i = 0; i < PTRS_PER_PTE; i++) {
> +		set_pte(p2m_missing_pte + i,
> +			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));

PAGE_KERNEL_RO?
> +		set_pte(p2m_identity_pte + i,
> +			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));

PAGE_KERNEL_RO ?

(or wait, this is done in the next patch!)
> +	}
>  
> -		mididx = p2m_mid_index(pfn);
> -		mid_p = p2m_top[topidx][mididx];
> -		if (!mid_p)
> -			continue;
> -		if ((mid_p == p2m_missing) || (mid_p == p2m_identity))
> +	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
> +		/*
> +		 * Try to map missing/identity PMDs or p2m-pages if possible.
> +		 * We have to respect the structure of the mfn_list_list
> +		 * which will be built a little bit later.

Could you say exactly when 'little bit later' is?

> +		 * Chunk size to test is one p2m page if we are in the middle
> +		 * of a mfn_list_list mid page and the complete mid page area
> +		 * if we are at index 0 of the mid page. Please note that a
> +		 * mid page might cover more than one PMD, e.g. on 32 bit PAE
> +		 * kernels.
> +		 */
> +		chunk = (pfn & (P2M_PER_PAGE * P2M_MID_PER_PAGE - 1)) ?
> +			P2M_PER_PAGE : P2M_PER_PAGE * P2M_MID_PER_PAGE;
> +
> +		type = xen_p2m_elem_type(pfn);
> +		i = 0;
> +		if (type != P2M_TYPE_PFN)
> +			for (i = 1; i < chunk; i++)
> +				if (xen_p2m_elem_type(pfn + i) != type)
> +					break;
> +		if (i < chunk)
> +			/* Reset to minimal chunk size. */
> +			chunk = P2M_PER_PAGE;

Say this is hit, and the values are: i == 3, chunk = 511.
The next region is an identify (or should be).

The initial xen_p2m_addr + i + pfn has INVALID_P2M_ENTRY (since 
that is what the xen_build_dynamic_phys_to_machine would
setup).
> +
> +		if (type == P2M_TYPE_PFN || i < chunk) {
> +			/* Use initial p2m page contents. */
> +#ifdef CONFIG_X86_64
> +			mfns = alloc_p2m_page();

And we get here. We allocate the page - which has random values.

> +			copy_page(mfns, xen_p2m_addr + pfn);

And then we copy the whole page over. So the values past the
pfn+i+xen_p2m_addr will be INVALID_P2M_ENTRY. But should it
be IDENTIFY?

[edit: I forgot about xen/setup.c calling set_phys_range_identity
for the last E820 entry, so that will take care of marking
xen_p2m_addr+pfn+i and past to IDENTIFY]. Wheew !

> +#else
> +			mfns = xen_p2m_addr + pfn;
> +#endif
> +			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
> +			set_pte(ptep,
> +				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
>  			continue;
> +		}
>  
> -		if ((unsigned long)mid_p == INVALID_P2M_ENTRY)
> +		if (chunk == P2M_PER_PAGE) {
> +			/* Map complete missing or identity p2m-page. */
> +			mfns = (type == P2M_TYPE_MISSING) ?
> +				p2m_missing : p2m_identity;
> +			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
> +			set_pte(ptep,
> +				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
>  			continue;
> +		}
>  
> -		/* The old va. Rebase it on mfn_list */
> -		if (mid_p >= (unsigned long *)va_start && mid_p <= (unsigned long *)va_end) {
> -			unsigned long *new;
> +		/* Complete missing or identity PMD(s) can be mapped. */
> +		ptep = (type == P2M_TYPE_MISSING) ?
> +			p2m_missing_pte : p2m_identity_pte;
> +		for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
> +			pmdp = populate_extra_pmd(
> +				(unsigned long)(p2m + pfn + i * PTRS_PER_PTE));
> +			set_pmd(pmdp, __pmd(__pa(ptep) | _KERNPG_TABLE));
> +		}
> +	}
> +}
>  
> -			if (pfn_free  > (size / sizeof(unsigned long))) {
> -				WARN(1, "Only allocated for %ld pages, but we want %ld!\n",
> -				     size / sizeof(unsigned long), pfn_free);
> -				return 0;
> -			}
> -			new = &mfn_list[pfn_free];
> +void __init xen_vmalloc_p2m_tree(void)
> +{
> +	static struct vm_struct vm;
>  
> -			copy_page(new, mid_p);
> -			p2m_top[topidx][mididx] = &mfn_list[pfn_free];
> +	vm.flags = VM_ALLOC;
> +	vm.size = ALIGN(sizeof(unsigned long) * xen_max_p2m_pfn,
> +			PMD_SIZE * PMDS_PER_MID_PAGE);
> +	vm_area_register_early(&vm, PMD_SIZE * PMDS_PER_MID_PAGE);
> +	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);

What happens if somebody boots with 'vmalloc=1MB' and we boot
an 400GB guest?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 20:39:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20:39:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrC1t-0003sw-Rg; Wed, 19 Nov 2014 20:39:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrC1r-0003sV-Mh
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 20:39:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	27/E1-09936-BEFFC645; Wed, 19 Nov 2014 20:39:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416429545!14003258!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3630 invoked from network); 19 Nov 2014 20:39:06 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:39:06 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKcpca019729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:38:53 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKcowf001936
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 20:38:51 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKcn0n015137; Wed, 19 Nov 2014 20:38:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:38:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6F492118334; Wed, 19 Nov 2014 15:38:48 -0500 (EST)
Date: Wed, 19 Nov 2014 15:38:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119203848.GB18495@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-8-git-send-email-jgross@suse.com>
	<54624BCB.9040300@citrix.com> <546477FD.9050800@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546477FD.9050800@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, David Vrabel <david.vrabel@citrix.com>,
	hpa@zytor.com, boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 10:21:01AM +0100, Juergen Gross wrote:
> On 11/11/2014 06:47 PM, David Vrabel wrote:
> >On 11/11/14 05:43, Juergen Gross wrote:
> >>At start of the day the Xen hypervisor presents a contiguous mfn list
> >>to a pv-domain. In order to support sparse memory this mfn list is
> >>accessed via a three level p2m tree built early in the boot process.
> >>Whenever the system needs the mfn associated with a pfn this tree is
> >>used to find the mfn.
> >>
> >>Instead of using a software walked tree for accessing a specific mfn
> >>list entry this patch is creating a virtual address area for the
> >>entire possible mfn list including memory holes. The holes are
> >>covered by mapping a pre-defined  page consisting only of "invalid
> >>mfn" entries. Access to a mfn entry is possible by just using the
> >>virtual base address of the mfn list and the pfn as index into that
> >>list. This speeds up the (hot) path of determining the mfn of a
> >>pfn.
> >>
> >>Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
> >>showed following improvements:
> >>
> >>Elapsed time: 32:50 ->  32:35
> >>System:       18:07 ->  17:47
> >>User:        104:00 -> 103:30
> >>
> >>Tested on 64 bit dom0 and 32 bit domU.
> >
> >Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> >
> >Can you please test this with the following guests/scenarios.
> >
> >* 64 bit dom0 with PCI devices with high MMIO BARs.
> 
> I'm not sure I have a machine available with this configuration.
> 
> >* 32 bit domU with PCI devices assigned.
> >* 32 bit domU with 64 GiB of memory.
> >* domU that starts pre-ballooned and is subsequently ballooned up.
> >* 64 bit domU that is saved and restored (or local host migration)
> >* 32 bit domU that is saved and restored (or local host migration)

I would also add: try 64-bit domU with really bizzare memory sizes that
are not odd. Like 9765431 or such. And naturally do the migration to
make sure that the re-hook doesn't miss a page or such.

> 
> I'll try.
> 
> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 20:39:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20:39:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrC1t-0003sw-Rg; Wed, 19 Nov 2014 20:39:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrC1r-0003sV-Mh
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 20:39:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	27/E1-09936-BEFFC645; Wed, 19 Nov 2014 20:39:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416429545!14003258!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3630 invoked from network); 19 Nov 2014 20:39:06 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:39:06 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKcpca019729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:38:53 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKcowf001936
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 20:38:51 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKcn0n015137; Wed, 19 Nov 2014 20:38:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:38:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6F492118334; Wed, 19 Nov 2014 15:38:48 -0500 (EST)
Date: Wed, 19 Nov 2014 15:38:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119203848.GB18495@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-8-git-send-email-jgross@suse.com>
	<54624BCB.9040300@citrix.com> <546477FD.9050800@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546477FD.9050800@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, David Vrabel <david.vrabel@citrix.com>,
	hpa@zytor.com, boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 7/8] xen: switch to linear virtual mapped
 sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 13, 2014 at 10:21:01AM +0100, Juergen Gross wrote:
> On 11/11/2014 06:47 PM, David Vrabel wrote:
> >On 11/11/14 05:43, Juergen Gross wrote:
> >>At start of the day the Xen hypervisor presents a contiguous mfn list
> >>to a pv-domain. In order to support sparse memory this mfn list is
> >>accessed via a three level p2m tree built early in the boot process.
> >>Whenever the system needs the mfn associated with a pfn this tree is
> >>used to find the mfn.
> >>
> >>Instead of using a software walked tree for accessing a specific mfn
> >>list entry this patch is creating a virtual address area for the
> >>entire possible mfn list including memory holes. The holes are
> >>covered by mapping a pre-defined  page consisting only of "invalid
> >>mfn" entries. Access to a mfn entry is possible by just using the
> >>virtual base address of the mfn list and the pfn as index into that
> >>list. This speeds up the (hot) path of determining the mfn of a
> >>pfn.
> >>
> >>Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
> >>showed following improvements:
> >>
> >>Elapsed time: 32:50 ->  32:35
> >>System:       18:07 ->  17:47
> >>User:        104:00 -> 103:30
> >>
> >>Tested on 64 bit dom0 and 32 bit domU.
> >
> >Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> >
> >Can you please test this with the following guests/scenarios.
> >
> >* 64 bit dom0 with PCI devices with high MMIO BARs.
> 
> I'm not sure I have a machine available with this configuration.
> 
> >* 32 bit domU with PCI devices assigned.
> >* 32 bit domU with 64 GiB of memory.
> >* domU that starts pre-ballooned and is subsequently ballooned up.
> >* 64 bit domU that is saved and restored (or local host migration)
> >* 32 bit domU that is saved and restored (or local host migration)

I would also add: try 64-bit domU with really bizzare memory sizes that
are not odd. Like 9765431 or such. And naturally do the migration to
make sure that the re-hook doesn't miss a page or such.

> 
> I'll try.
> 
> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 20:39:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20: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 1XrC2M-0003wz-8F; Wed, 19 Nov 2014 20:39:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrC2K-0003wf-MJ
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 20:39:36 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	E7/D6-18267-7000D645; Wed, 19 Nov 2014 20:39:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416429573!12570188!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3557 invoked from network); 19 Nov 2014 20:39:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:39:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKdJuS020558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:39:20 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKdIXm018561
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 20:39:19 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKdHf5016363; Wed, 19 Nov 2014 20:39:18 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:39:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 27A7E118336; Wed, 19 Nov 2014 15:39:15 -0500 (EST)
Date: Wed, 19 Nov 2014 15:39:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119203914.GC18495@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-9-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-9-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 8/8] xen: Speed up set_phys_to_machine()
 by using read-only mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:43:46AM +0100, Juergen Gross wrote:
> Instead of checking at each call of set_phys_to_machine() whether a
> new p2m page has to be allocated due to writing an entry in a large
> invalid or identity area, just map those areas read only and react
> to a page fault on write by allocating the new page.
> 
> This change will make the common path with no allocation much
> faster as it only requires a single write of the new mfn instead
> of walking the address translation tables and checking for the
> special cases.
> 
> Suggested-by: David Vrabel <david.vrabel@citrix.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Clever!

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/p2m.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 7df446d..58cf04c 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -70,6 +70,7 @@
>  
>  #include <asm/cache.h>
>  #include <asm/setup.h>
> +#include <asm/uaccess.h>
>  
>  #include <asm/xen/page.h>
>  #include <asm/xen/hypercall.h>
> @@ -313,9 +314,9 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
>  	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
>  	for (i = 0; i < PTRS_PER_PTE; i++) {
>  		set_pte(p2m_missing_pte + i,
> -			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
> +			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL_RO));
>  		set_pte(p2m_identity_pte + i,
> -			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
> +			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL_RO));
>  	}
>  
>  	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
> @@ -362,7 +363,7 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
>  				p2m_missing : p2m_identity;
>  			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
>  			set_pte(ptep,
> -				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
> +				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL_RO));
>  			continue;
>  		}
>  
> @@ -621,6 +622,9 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  		return true;
>  	}
>  
> +	if (likely(!__put_user(mfn, xen_p2m_addr + pfn)))
> +		return true;
> +
>  	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
>  	BUG_ON(!ptep || level != PG_LEVEL_4K);
>  
> @@ -630,9 +634,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
>  		return mfn == IDENTITY_FRAME(pfn);
>  
> -	xen_p2m_addr[pfn] = mfn;
> -
> -	return true;
> +	return false;
>  }
>  
>  bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> -- 
> 2.1.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 20:39:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20: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 1XrC2M-0003wz-8F; Wed, 19 Nov 2014 20:39:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrC2K-0003wf-MJ
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 20:39:36 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	E7/D6-18267-7000D645; Wed, 19 Nov 2014 20:39:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416429573!12570188!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3557 invoked from network); 19 Nov 2014 20:39:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:39:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKdJuS020558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:39:20 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKdIXm018561
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 20:39:19 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKdHf5016363; Wed, 19 Nov 2014 20:39:18 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:39:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 27A7E118336; Wed, 19 Nov 2014 15:39:15 -0500 (EST)
Date: Wed, 19 Nov 2014 15:39:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119203914.GC18495@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-9-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-9-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 8/8] xen: Speed up set_phys_to_machine()
 by using read-only mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:43:46AM +0100, Juergen Gross wrote:
> Instead of checking at each call of set_phys_to_machine() whether a
> new p2m page has to be allocated due to writing an entry in a large
> invalid or identity area, just map those areas read only and react
> to a page fault on write by allocating the new page.
> 
> This change will make the common path with no allocation much
> faster as it only requires a single write of the new mfn instead
> of walking the address translation tables and checking for the
> special cases.
> 
> Suggested-by: David Vrabel <david.vrabel@citrix.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Clever!

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/p2m.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 7df446d..58cf04c 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -70,6 +70,7 @@
>  
>  #include <asm/cache.h>
>  #include <asm/setup.h>
> +#include <asm/uaccess.h>
>  
>  #include <asm/xen/page.h>
>  #include <asm/xen/hypercall.h>
> @@ -313,9 +314,9 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
>  	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
>  	for (i = 0; i < PTRS_PER_PTE; i++) {
>  		set_pte(p2m_missing_pte + i,
> -			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
> +			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL_RO));
>  		set_pte(p2m_identity_pte + i,
> -			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
> +			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL_RO));
>  	}
>  
>  	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
> @@ -362,7 +363,7 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
>  				p2m_missing : p2m_identity;
>  			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
>  			set_pte(ptep,
> -				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
> +				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL_RO));
>  			continue;
>  		}
>  
> @@ -621,6 +622,9 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  		return true;
>  	}
>  
> +	if (likely(!__put_user(mfn, xen_p2m_addr + pfn)))
> +		return true;
> +
>  	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
>  	BUG_ON(!ptep || level != PG_LEVEL_4K);
>  
> @@ -630,9 +634,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
>  		return mfn == IDENTITY_FRAME(pfn);
>  
> -	xen_p2m_addr[pfn] = mfn;
> -
> -	return true;
> +	return false;
>  }
>  
>  bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> -- 
> 2.1.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 20:42:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrC4U-00048j-PL; Wed, 19 Nov 2014 20:41:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrC4T-00048b-MN
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 20:41:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F7/65-09842-D800D645; Wed, 19 Nov 2014 20:41:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416429707!13969939!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2626 invoked from network); 19 Nov 2014 20:41:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:41:48 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKfY6L023113
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:41:35 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKfXod009490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 20:41:34 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKfXc2022300; Wed, 19 Nov 2014 20:41:33 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:41:32 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A7B3911833D; Wed, 19 Nov 2014 15:41:31 -0500 (EST)
Date: Wed, 19 Nov 2014 15:41:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119204131.GD18495@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 0/8] xen: Switch to virtual mapped linear
	p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:43:38AM +0100, Juergen Gross wrote:
> Paravirtualized kernels running on Xen use a three level tree for
> translation of guest specific physical addresses to machine global
> addresses. This p2m tree is used for construction of page table
> entries, so the p2m tree walk is performance critical.
> 
> By using a linear virtual mapped p2m list accesses to p2m elements
> can be sped up while even simplifying code. To achieve this goal
> some p2m related initializations have to be performed later in the
> boot process, as the final p2m list can be set up only after basic
> memory management functions are available.
> 

Hey Juergen,

I finially finished looking at the patchset. Had some comments,
some questions that I hope can make it in the patch so that in
six months or so when somebody looks at the code they can
understand the subtle pieces.

Looking forward to the v4! (Thought keep in mind that next week
is Thanksgiving week so won't be able to look much after Wednesday)

>  arch/x86/include/asm/pgtable_types.h |    1 +
>  arch/x86/include/asm/xen/page.h      |   49 +-
>  arch/x86/mm/pageattr.c               |   20 +
>  arch/x86/xen/mmu.c                   |   38 +-
>  arch/x86/xen/p2m.c                   | 1315 ++++++++++++++--------------------
>  arch/x86/xen/setup.c                 |  460 ++++++------
>  arch/x86/xen/xen-ops.h               |    6 +-
>  7 files changed, 854 insertions(+), 1035 deletions(-)

And best of - we are deleting more code!

> 
> -- 
> 2.1.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 20:42:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrC4U-00048j-PL; Wed, 19 Nov 2014 20:41:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrC4T-00048b-MN
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 20:41:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F7/65-09842-D800D645; Wed, 19 Nov 2014 20:41:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416429707!13969939!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2626 invoked from network); 19 Nov 2014 20:41:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:41:48 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKfY6L023113
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:41:35 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKfXod009490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 20:41:34 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKfXc2022300; Wed, 19 Nov 2014 20:41:33 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:41:32 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A7B3911833D; Wed, 19 Nov 2014 15:41:31 -0500 (EST)
Date: Wed, 19 Nov 2014 15:41:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119204131.GD18495@laptop.dumpdata.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415684626-18590-1-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 0/8] xen: Switch to virtual mapped linear
	p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 11, 2014 at 06:43:38AM +0100, Juergen Gross wrote:
> Paravirtualized kernels running on Xen use a three level tree for
> translation of guest specific physical addresses to machine global
> addresses. This p2m tree is used for construction of page table
> entries, so the p2m tree walk is performance critical.
> 
> By using a linear virtual mapped p2m list accesses to p2m elements
> can be sped up while even simplifying code. To achieve this goal
> some p2m related initializations have to be performed later in the
> boot process, as the final p2m list can be set up only after basic
> memory management functions are available.
> 

Hey Juergen,

I finially finished looking at the patchset. Had some comments,
some questions that I hope can make it in the patch so that in
six months or so when somebody looks at the code they can
understand the subtle pieces.

Looking forward to the v4! (Thought keep in mind that next week
is Thanksgiving week so won't be able to look much after Wednesday)

>  arch/x86/include/asm/pgtable_types.h |    1 +
>  arch/x86/include/asm/xen/page.h      |   49 +-
>  arch/x86/mm/pageattr.c               |   20 +
>  arch/x86/xen/mmu.c                   |   38 +-
>  arch/x86/xen/p2m.c                   | 1315 ++++++++++++++--------------------
>  arch/x86/xen/setup.c                 |  460 ++++++------
>  arch/x86/xen/xen-ops.h               |    6 +-
>  7 files changed, 854 insertions(+), 1035 deletions(-)

And best of - we are deleting more code!

> 
> -- 
> 2.1.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 20:54:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20:54:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCG1-0004Qd-2O; Wed, 19 Nov 2014 20:53:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCFz-0004QW-Ja
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 20:53:43 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	DE/0B-02559-6530D645; Wed, 19 Nov 2014 20:53:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416430420!13567778!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17598 invoked from network); 19 Nov 2014 20:53:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:53:41 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKrcgk004333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:53:39 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKrb3r024598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 20:53:38 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKrbT5029126; Wed, 19 Nov 2014 20:53:37 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:53:37 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EF0A111834C; Wed, 19 Nov 2014 15:53:35 -0500 (EST)
Date: Wed, 19 Nov 2014 15:53:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Simon Martin <furryfuttock@gmail.com>
Message-ID: <20141119205335.GB19961@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
	<546B86990200007800048DBF@mail.emea.novell.com>
	<6916092.20141119121209@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM"
Content-Disposition: inline
In-Reply-To: <6916092.20141119121209@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Nov 19, 2014 at 12:12:09PM -0300, Simon Martin wrote:
> Hello Jan and Konrad,
> 
> Tuesday, November 18, 2014, 1:49:13 PM, you wrote:
> 
> >>
> >> I've just checked this with lspci. I see that the IO is being enabled.
> 
> > Memory you mean.
> 
> Yes. Sorry.
> 
> >> Any   other   idea   on   why I might be reading back 0xff for all PCI
> >> memory area reads? The lspci output follows.
> 
> > Since this isn't behind a bridge - no, not really. Did you try this with
> > any other device for comparison purposes?
> 
> This   is  getting  more  interesting.  It  seems  that  something  is
> overwriting the pci-back configuration data.
> 
> Starting  from a fresh reboot I checked the Dom0 pci configuration and
> got this:
> 
> root@smartin-xen:~# lspci -s 00:19.0 -x
> 00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
> 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> 30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00
> 
> I then start/stop my DomU and checked the Dom0 pci configuration again
> and got this:
> 
> root@smartin-xen:~# lspci -s 00:19.0 -x
> 00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
> 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> 30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00
> 
> Inside  my  DomU I added code to print the PCI configuration registers
> and what I get after restarting the DomU is:
> 
> (d18) 14:57:04.042 src/e1000e.c@00150: 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> (d18) 14:57:04.042 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> (d18) 14:57:04.042 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 14:57:04.043 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> (d18) 14:57:04.043 src/e1000e.c@00324: Enable PCI Memory Access
> (d18) 14:57:05.043 src/e1000e.c@00150: 00: 86 80 59 15 03 00 10 00 04 00 00 02 00 00 00 00
> (d18) 14:57:05.044 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> (d18) 14:57:05.044 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 14:57:05.045 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> 
> As  you can see the pci configuration read from the pci-back driver by
> my DomU is different to the data in the Dom0 pci configuration!
> 
> Just  before  leaving my DomU I disable the pci memory access and this
> is what I see
> 
> (d18) 15:01:02.051 src/e1000e.c@00150: 00: 86 80 59 15 03 00 10 00 04 00 00 02 00 00 00 00
> (d18) 15:01:02.051 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> (d18) 15:01:02.051 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 15:01:02.052 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> (d18) 15:01:02.052 src/e1000e.c@00541: Disable PCI Memory Access
> (d18) 15:01:02.052 src/e1000e.c@00150: 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> (d18) 15:01:02.052 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> (d18) 15:01:02.052 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 15:01:02.053 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> 
> As  you  can  see the data is consistent with just writing 0000 to the
> pci control register.
> 
> This is the output from the debug version of the xen-pciback module.
> 
> [ 5429.351231] pciback 0000:00:19.0: enabling device (0000 -> 0003)
> [ 5429.351367] xen: registering gsi 20 triggering 0 polarity 1
> [ 5429.351373] Already setup the GSI :20
> [ 5429.351387] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 on  disable-> enable
> [ 5429.351436] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 on  enabled
> [ 5434.360078] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 off  enable-> disable
> [ 5434.360116] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #0 off  disabled
> [ 5434.361491] xen-pciback pci-20-0: fe state changed 5
> [ 5434.362473] xen-pciback pci-20-0: fe state changed 6
> [ 5434.363540] xen-pciback pci-20-0: fe state changed 0
> [ 5434.363544] xen-pciback pci-20-0: frontend is gone! unregister device
> [ 5434.467359] pciback 0000:00:19.0: resetting virtual configuration space
> [ 5434.467376] pciback 0000:00:19.0: free-ing dynamically allocated virtual configuration space fields
> 
> Does this make any sense to you?

There was a bug in Xen pcibackend that I thought I upstreamed which could
be releated. It was not restoring the right registers to the PCI-device.

They are attached.

> 
> -- 
> Best regards,
>  Simon                            mailto:furryfuttock@gmail.com
> 

--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-xen-pciback-Don-t-deadlock-when-unbinding.patch"

>From b5935d70083123aae48e115c7ed027a0ca79657f Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 14 Jul 2014 12:18:52 -0400
Subject: [PATCH 01/10] xen/pciback: Don't deadlock when unbinding.

As commit 0a9fd0152929db372ff61b0d6c280fdd34ae8bdb
'xen/pciback: Document the entry points for 'pcistub_put_pci_dev''
explained there are four entry points in this function.
Two of them are when the user fiddles in the SysFS to
unbind a device which might be in use by a guest or not.

Both 'unbind' states will cause a deadlock as the the PCI lock has
already been taken, which then pci_device_reset tries to take.

We can simplify this by requiring that all callers of
pcistub_put_pci_dev MUST hold the device lock. And then
we can just call the lockless version of pci_device_reset.

To make it even simpler we will modify xen_pcibk_release_pci_dev
to quality whether it should take a lock or not - as it ends
up calling xen_pcibk_release_pci_dev and needs to hold the lock.

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/xen/xen-pciback/passthrough.c | 14 +++++++++++---
 drivers/xen/xen-pciback/pci_stub.c    | 12 ++++++------
 drivers/xen/xen-pciback/pciback.h     |  7 ++++---
 drivers/xen/xen-pciback/vpci.c        | 14 +++++++++++---
 drivers/xen/xen-pciback/xenbus.c      |  2 +-
 5 files changed, 33 insertions(+), 16 deletions(-)

diff --git a/drivers/xen/xen-pciback/passthrough.c b/drivers/xen/xen-pciback/passthrough.c
index 828dddc..f16a30e 100644
--- a/drivers/xen/xen-pciback/passthrough.c
+++ b/drivers/xen/xen-pciback/passthrough.c
@@ -69,7 +69,7 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 }
 
 static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					struct pci_dev *dev)
+					struct pci_dev *dev, bool lock)
 {
 	struct passthrough_dev_data *dev_data = pdev->pci_dev_data;
 	struct pci_dev_entry *dev_entry, *t;
@@ -87,8 +87,13 @@ static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
 
 	mutex_unlock(&dev_data->lock);
 
-	if (found_dev)
+	if (found_dev) {
+		if (lock)
+			device_lock(&found_dev->dev);
 		pcistub_put_pci_dev(found_dev);
+		if (lock)
+			device_unlock(&found_dev->dev);
+	}
 }
 
 static int __xen_pcibk_init_devices(struct xen_pcibk_device *pdev)
@@ -156,8 +161,11 @@ static void __xen_pcibk_release_devices(struct xen_pcibk_device *pdev)
 	struct pci_dev_entry *dev_entry, *t;
 
 	list_for_each_entry_safe(dev_entry, t, &dev_data->dev_list, list) {
+		struct pci_dev *dev = dev_entry->dev;
 		list_del(&dev_entry->list);
-		pcistub_put_pci_dev(dev_entry->dev);
+		device_lock(&dev->dev);
+		pcistub_put_pci_dev(dev);
+		device_unlock(&dev->dev);
 		kfree(dev_entry);
 	}
 
diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 017069a..9cbe1a3 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -250,6 +250,8 @@ struct pci_dev *pcistub_get_pci_dev(struct xen_pcibk_device *pdev,
  *  - 'echo BDF > unbind' with a guest still using it. See pcistub_remove
  *
  *  As such we have to be careful.
+ *
+ *  To make this easier, the caller has to hold the device lock.
  */
 void pcistub_put_pci_dev(struct pci_dev *dev)
 {
@@ -276,11 +278,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* Cleanup our device
 	 * (so it's ready for the next domain)
 	 */
-
-	/* This is OK - we are running from workqueue context
-	 * and want to inhibit the user from fiddling with 'reset'
-	 */
-	pci_reset_function(dev);
+	lockdep_assert_held(&dev->dev.mutex);
+	__pci_reset_function_locked(dev);
 	pci_restore_state(dev);
 
 	/* This disables the device. */
@@ -567,7 +566,8 @@ static void pcistub_remove(struct pci_dev *dev)
 			/* N.B. This ends up calling pcistub_put_pci_dev which ends up
 			 * doing the FLR. */
 			xen_pcibk_release_pci_dev(found_psdev->pdev,
-						found_psdev->dev);
+						found_psdev->dev,
+						false /* caller holds the lock. */);
 		}
 
 		spin_lock_irqsave(&pcistub_devices_lock, flags);
diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
index f72af87..58e38d5 100644
--- a/drivers/xen/xen-pciback/pciback.h
+++ b/drivers/xen/xen-pciback/pciback.h
@@ -99,7 +99,8 @@ struct xen_pcibk_backend {
 		    unsigned int *domain, unsigned int *bus,
 		    unsigned int *devfn);
 	int (*publish)(struct xen_pcibk_device *pdev, publish_pci_root_cb cb);
-	void (*release)(struct xen_pcibk_device *pdev, struct pci_dev *dev);
+	void (*release)(struct xen_pcibk_device *pdev, struct pci_dev *dev,
+                        bool lock);
 	int (*add)(struct xen_pcibk_device *pdev, struct pci_dev *dev,
 		   int devid, publish_pci_dev_cb publish_cb);
 	struct pci_dev *(*get)(struct xen_pcibk_device *pdev,
@@ -122,10 +123,10 @@ static inline int xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 }
 
 static inline void xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					     struct pci_dev *dev)
+					     struct pci_dev *dev, bool lock)
 {
 	if (xen_pcibk_backend && xen_pcibk_backend->release)
-		return xen_pcibk_backend->release(pdev, dev);
+		return xen_pcibk_backend->release(pdev, dev, lock);
 }
 
 static inline struct pci_dev *
diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
index 51afff9..c99f8bb 100644
--- a/drivers/xen/xen-pciback/vpci.c
+++ b/drivers/xen/xen-pciback/vpci.c
@@ -145,7 +145,7 @@ out:
 }
 
 static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					struct pci_dev *dev)
+					struct pci_dev *dev, bool lock)
 {
 	int slot;
 	struct vpci_dev_data *vpci_dev = pdev->pci_dev_data;
@@ -169,8 +169,13 @@ static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
 out:
 	mutex_unlock(&vpci_dev->lock);
 
-	if (found_dev)
+	if (found_dev) {
+		if (lock)
+			device_lock(&found_dev->dev);
 		pcistub_put_pci_dev(found_dev);
+		if (lock)
+			device_unlock(&found_dev->dev);
+	}
 }
 
 static int __xen_pcibk_init_devices(struct xen_pcibk_device *pdev)
@@ -208,8 +213,11 @@ static void __xen_pcibk_release_devices(struct xen_pcibk_device *pdev)
 		struct pci_dev_entry *e, *tmp;
 		list_for_each_entry_safe(e, tmp, &vpci_dev->dev_list[slot],
 					 list) {
+			struct pci_dev *dev = e->dev;
 			list_del(&e->list);
-			pcistub_put_pci_dev(e->dev);
+			device_lock(&dev->dev);
+			pcistub_put_pci_dev(dev);
+			device_unlock(&dev->dev);
 			kfree(e);
 		}
 	}
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index ad8d30c..eeee499 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -291,7 +291,7 @@ static int xen_pcibk_remove_device(struct xen_pcibk_device *pdev,
 
 	/* N.B. This ends up calling pcistub_put_pci_dev which ends up
 	 * doing the FLR. */
-	xen_pcibk_release_pci_dev(pdev, dev);
+	xen_pcibk_release_pci_dev(pdev, dev, true /* use the lock. */);
 
 out:
 	return err;
-- 
1.8.4.2


--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0006-xen-pciback-Restore-configuration-space-when-detachi.patch"

>From 01e3c0895b0c9ee957b09f946429226c241bb5d2 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 6 Aug 2014 16:21:32 -0400
Subject: [PATCH 06/10] xen/pciback: Restore configuration space when detaching
 from a guest.

The commit 9eea3f7695226f9af9992cebf8e98ac0ad78b277
"xen/pciback: Don't deadlock when unbinding." was using
the version of pci_reset_function which would lock the device lock.
That is no good as we can dead-lock. As such we swapped to using
the lock-less version and requiring that the callers
of 'pcistub_put_pci_dev' take the device lock. And as such
this bug got exposed.

Using the lock-less version is  OK, except that we tried to
use 'pci_restore_state' after the lock-less version of
__pci_reset_function_locked - which won't work as 'state_saved'
is set to false. Said 'state_saved' is a toggle boolean that
is to be used by the sequence of a) pci_save_state/pci_restore_state
or b) pci_load_and_free_saved_state/pci_restore_state. We don't
want to use a) as the guest might have messed up the PCI
configuration space and we want it to revert to the state
when the PCI device was binded to us. Therefore we pick
b) to restore the configuration space.

To still retain the PCI configuration space, we save it once
more and store it on our private copy to be restored when:
 - Device is unbinded from pciback
 - Device is detached from a guest.

Reported-by:  Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 843a2ba..1126c5a 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -105,7 +105,7 @@ static void pcistub_device_release(struct kref *kref)
 	 */
 	__pci_reset_function_locked(dev);
 	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
-		dev_dbg(&dev->dev, "Could not reload PCI state\n");
+		dev_info(&dev->dev, "Could not reload PCI state\n");
 	else
 		pci_restore_state(dev);
 
@@ -257,6 +257,7 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 {
 	struct pcistub_device *psdev, *found_psdev = NULL;
 	unsigned long flags;
+	struct xen_pcibk_dev_data *dev_data;
 
 	spin_lock_irqsave(&pcistub_devices_lock, flags);
 
@@ -279,9 +280,25 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	 * (so it's ready for the next domain)
 	 */
 	device_lock_assert(&dev->dev);
-	__pci_reset_function_locked(dev);
-	pci_restore_state(dev);
-
+	dev_data = pci_get_drvdata(dev);
+	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
+		dev_info(&dev->dev, "Could not reload PCI state\n");
+	else {
+		__pci_reset_function_locked(dev);
+		/*
+		 * The usual sequence is pci_save_state & pci_restore_state
+		 * but the guest might have messed the configuration space up.
+		 * Use the initial version (when device was binded to us).
+		 */
+		pci_restore_state(dev);
+		/*
+		 * The next steps are to reload the configuration for the
+		 * next time we bind & unbind to a guest - or unload from
+		 * pciback.
+		 */
+		pci_save_state(dev);
+		dev_data->pci_saved_state = pci_store_saved_state(dev);
+	}
 	/* This disables the device. */
 	xen_pcibk_reset_device(dev);
 
-- 
1.8.4.2


--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--yrj/dFKFPuw6o+aM--


From xen-devel-bounces@lists.xen.org Wed Nov 19 20:54:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20:54:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCG1-0004Qd-2O; Wed, 19 Nov 2014 20:53:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCFz-0004QW-Ja
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 20:53:43 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	DE/0B-02559-6530D645; Wed, 19 Nov 2014 20:53:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416430420!13567778!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17598 invoked from network); 19 Nov 2014 20:53:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:53:41 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKrcgk004333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:53:39 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKrb3r024598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 20:53:38 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKrbT5029126; Wed, 19 Nov 2014 20:53:37 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:53:37 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EF0A111834C; Wed, 19 Nov 2014 15:53:35 -0500 (EST)
Date: Wed, 19 Nov 2014 15:53:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Simon Martin <furryfuttock@gmail.com>
Message-ID: <20141119205335.GB19961@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
	<546B86990200007800048DBF@mail.emea.novell.com>
	<6916092.20141119121209@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM"
Content-Disposition: inline
In-Reply-To: <6916092.20141119121209@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Nov 19, 2014 at 12:12:09PM -0300, Simon Martin wrote:
> Hello Jan and Konrad,
> 
> Tuesday, November 18, 2014, 1:49:13 PM, you wrote:
> 
> >>
> >> I've just checked this with lspci. I see that the IO is being enabled.
> 
> > Memory you mean.
> 
> Yes. Sorry.
> 
> >> Any   other   idea   on   why I might be reading back 0xff for all PCI
> >> memory area reads? The lspci output follows.
> 
> > Since this isn't behind a bridge - no, not really. Did you try this with
> > any other device for comparison purposes?
> 
> This   is  getting  more  interesting.  It  seems  that  something  is
> overwriting the pci-back configuration data.
> 
> Starting  from a fresh reboot I checked the Dom0 pci configuration and
> got this:
> 
> root@smartin-xen:~# lspci -s 00:19.0 -x
> 00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
> 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> 30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00
> 
> I then start/stop my DomU and checked the Dom0 pci configuration again
> and got this:
> 
> root@smartin-xen:~# lspci -s 00:19.0 -x
> 00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
> 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> 30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00
> 
> Inside  my  DomU I added code to print the PCI configuration registers
> and what I get after restarting the DomU is:
> 
> (d18) 14:57:04.042 src/e1000e.c@00150: 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> (d18) 14:57:04.042 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> (d18) 14:57:04.042 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 14:57:04.043 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> (d18) 14:57:04.043 src/e1000e.c@00324: Enable PCI Memory Access
> (d18) 14:57:05.043 src/e1000e.c@00150: 00: 86 80 59 15 03 00 10 00 04 00 00 02 00 00 00 00
> (d18) 14:57:05.044 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> (d18) 14:57:05.044 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 14:57:05.045 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> 
> As  you can see the pci configuration read from the pci-back driver by
> my DomU is different to the data in the Dom0 pci configuration!
> 
> Just  before  leaving my DomU I disable the pci memory access and this
> is what I see
> 
> (d18) 15:01:02.051 src/e1000e.c@00150: 00: 86 80 59 15 03 00 10 00 04 00 00 02 00 00 00 00
> (d18) 15:01:02.051 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> (d18) 15:01:02.051 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 15:01:02.052 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> (d18) 15:01:02.052 src/e1000e.c@00541: Disable PCI Memory Access
> (d18) 15:01:02.052 src/e1000e.c@00150: 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> (d18) 15:01:02.052 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> (d18) 15:01:02.052 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 15:01:02.053 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> 
> As  you  can  see the data is consistent with just writing 0000 to the
> pci control register.
> 
> This is the output from the debug version of the xen-pciback module.
> 
> [ 5429.351231] pciback 0000:00:19.0: enabling device (0000 -> 0003)
> [ 5429.351367] xen: registering gsi 20 triggering 0 polarity 1
> [ 5429.351373] Already setup the GSI :20
> [ 5429.351387] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 on  disable-> enable
> [ 5429.351436] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 on  enabled
> [ 5434.360078] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #20 off  enable-> disable
> [ 5434.360116] pciback 0000:00:19.0: xen-pciback[0000:00:19.0]: #0 off  disabled
> [ 5434.361491] xen-pciback pci-20-0: fe state changed 5
> [ 5434.362473] xen-pciback pci-20-0: fe state changed 6
> [ 5434.363540] xen-pciback pci-20-0: fe state changed 0
> [ 5434.363544] xen-pciback pci-20-0: frontend is gone! unregister device
> [ 5434.467359] pciback 0000:00:19.0: resetting virtual configuration space
> [ 5434.467376] pciback 0000:00:19.0: free-ing dynamically allocated virtual configuration space fields
> 
> Does this make any sense to you?

There was a bug in Xen pcibackend that I thought I upstreamed which could
be releated. It was not restoring the right registers to the PCI-device.

They are attached.

> 
> -- 
> Best regards,
>  Simon                            mailto:furryfuttock@gmail.com
> 

--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-xen-pciback-Don-t-deadlock-when-unbinding.patch"

>From b5935d70083123aae48e115c7ed027a0ca79657f Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 14 Jul 2014 12:18:52 -0400
Subject: [PATCH 01/10] xen/pciback: Don't deadlock when unbinding.

As commit 0a9fd0152929db372ff61b0d6c280fdd34ae8bdb
'xen/pciback: Document the entry points for 'pcistub_put_pci_dev''
explained there are four entry points in this function.
Two of them are when the user fiddles in the SysFS to
unbind a device which might be in use by a guest or not.

Both 'unbind' states will cause a deadlock as the the PCI lock has
already been taken, which then pci_device_reset tries to take.

We can simplify this by requiring that all callers of
pcistub_put_pci_dev MUST hold the device lock. And then
we can just call the lockless version of pci_device_reset.

To make it even simpler we will modify xen_pcibk_release_pci_dev
to quality whether it should take a lock or not - as it ends
up calling xen_pcibk_release_pci_dev and needs to hold the lock.

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/xen/xen-pciback/passthrough.c | 14 +++++++++++---
 drivers/xen/xen-pciback/pci_stub.c    | 12 ++++++------
 drivers/xen/xen-pciback/pciback.h     |  7 ++++---
 drivers/xen/xen-pciback/vpci.c        | 14 +++++++++++---
 drivers/xen/xen-pciback/xenbus.c      |  2 +-
 5 files changed, 33 insertions(+), 16 deletions(-)

diff --git a/drivers/xen/xen-pciback/passthrough.c b/drivers/xen/xen-pciback/passthrough.c
index 828dddc..f16a30e 100644
--- a/drivers/xen/xen-pciback/passthrough.c
+++ b/drivers/xen/xen-pciback/passthrough.c
@@ -69,7 +69,7 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 }
 
 static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					struct pci_dev *dev)
+					struct pci_dev *dev, bool lock)
 {
 	struct passthrough_dev_data *dev_data = pdev->pci_dev_data;
 	struct pci_dev_entry *dev_entry, *t;
@@ -87,8 +87,13 @@ static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
 
 	mutex_unlock(&dev_data->lock);
 
-	if (found_dev)
+	if (found_dev) {
+		if (lock)
+			device_lock(&found_dev->dev);
 		pcistub_put_pci_dev(found_dev);
+		if (lock)
+			device_unlock(&found_dev->dev);
+	}
 }
 
 static int __xen_pcibk_init_devices(struct xen_pcibk_device *pdev)
@@ -156,8 +161,11 @@ static void __xen_pcibk_release_devices(struct xen_pcibk_device *pdev)
 	struct pci_dev_entry *dev_entry, *t;
 
 	list_for_each_entry_safe(dev_entry, t, &dev_data->dev_list, list) {
+		struct pci_dev *dev = dev_entry->dev;
 		list_del(&dev_entry->list);
-		pcistub_put_pci_dev(dev_entry->dev);
+		device_lock(&dev->dev);
+		pcistub_put_pci_dev(dev);
+		device_unlock(&dev->dev);
 		kfree(dev_entry);
 	}
 
diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 017069a..9cbe1a3 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -250,6 +250,8 @@ struct pci_dev *pcistub_get_pci_dev(struct xen_pcibk_device *pdev,
  *  - 'echo BDF > unbind' with a guest still using it. See pcistub_remove
  *
  *  As such we have to be careful.
+ *
+ *  To make this easier, the caller has to hold the device lock.
  */
 void pcistub_put_pci_dev(struct pci_dev *dev)
 {
@@ -276,11 +278,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* Cleanup our device
 	 * (so it's ready for the next domain)
 	 */
-
-	/* This is OK - we are running from workqueue context
-	 * and want to inhibit the user from fiddling with 'reset'
-	 */
-	pci_reset_function(dev);
+	lockdep_assert_held(&dev->dev.mutex);
+	__pci_reset_function_locked(dev);
 	pci_restore_state(dev);
 
 	/* This disables the device. */
@@ -567,7 +566,8 @@ static void pcistub_remove(struct pci_dev *dev)
 			/* N.B. This ends up calling pcistub_put_pci_dev which ends up
 			 * doing the FLR. */
 			xen_pcibk_release_pci_dev(found_psdev->pdev,
-						found_psdev->dev);
+						found_psdev->dev,
+						false /* caller holds the lock. */);
 		}
 
 		spin_lock_irqsave(&pcistub_devices_lock, flags);
diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
index f72af87..58e38d5 100644
--- a/drivers/xen/xen-pciback/pciback.h
+++ b/drivers/xen/xen-pciback/pciback.h
@@ -99,7 +99,8 @@ struct xen_pcibk_backend {
 		    unsigned int *domain, unsigned int *bus,
 		    unsigned int *devfn);
 	int (*publish)(struct xen_pcibk_device *pdev, publish_pci_root_cb cb);
-	void (*release)(struct xen_pcibk_device *pdev, struct pci_dev *dev);
+	void (*release)(struct xen_pcibk_device *pdev, struct pci_dev *dev,
+                        bool lock);
 	int (*add)(struct xen_pcibk_device *pdev, struct pci_dev *dev,
 		   int devid, publish_pci_dev_cb publish_cb);
 	struct pci_dev *(*get)(struct xen_pcibk_device *pdev,
@@ -122,10 +123,10 @@ static inline int xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 }
 
 static inline void xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					     struct pci_dev *dev)
+					     struct pci_dev *dev, bool lock)
 {
 	if (xen_pcibk_backend && xen_pcibk_backend->release)
-		return xen_pcibk_backend->release(pdev, dev);
+		return xen_pcibk_backend->release(pdev, dev, lock);
 }
 
 static inline struct pci_dev *
diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
index 51afff9..c99f8bb 100644
--- a/drivers/xen/xen-pciback/vpci.c
+++ b/drivers/xen/xen-pciback/vpci.c
@@ -145,7 +145,7 @@ out:
 }
 
 static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					struct pci_dev *dev)
+					struct pci_dev *dev, bool lock)
 {
 	int slot;
 	struct vpci_dev_data *vpci_dev = pdev->pci_dev_data;
@@ -169,8 +169,13 @@ static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
 out:
 	mutex_unlock(&vpci_dev->lock);
 
-	if (found_dev)
+	if (found_dev) {
+		if (lock)
+			device_lock(&found_dev->dev);
 		pcistub_put_pci_dev(found_dev);
+		if (lock)
+			device_unlock(&found_dev->dev);
+	}
 }
 
 static int __xen_pcibk_init_devices(struct xen_pcibk_device *pdev)
@@ -208,8 +213,11 @@ static void __xen_pcibk_release_devices(struct xen_pcibk_device *pdev)
 		struct pci_dev_entry *e, *tmp;
 		list_for_each_entry_safe(e, tmp, &vpci_dev->dev_list[slot],
 					 list) {
+			struct pci_dev *dev = e->dev;
 			list_del(&e->list);
-			pcistub_put_pci_dev(e->dev);
+			device_lock(&dev->dev);
+			pcistub_put_pci_dev(dev);
+			device_unlock(&dev->dev);
 			kfree(e);
 		}
 	}
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index ad8d30c..eeee499 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -291,7 +291,7 @@ static int xen_pcibk_remove_device(struct xen_pcibk_device *pdev,
 
 	/* N.B. This ends up calling pcistub_put_pci_dev which ends up
 	 * doing the FLR. */
-	xen_pcibk_release_pci_dev(pdev, dev);
+	xen_pcibk_release_pci_dev(pdev, dev, true /* use the lock. */);
 
 out:
 	return err;
-- 
1.8.4.2


--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0006-xen-pciback-Restore-configuration-space-when-detachi.patch"

>From 01e3c0895b0c9ee957b09f946429226c241bb5d2 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 6 Aug 2014 16:21:32 -0400
Subject: [PATCH 06/10] xen/pciback: Restore configuration space when detaching
 from a guest.

The commit 9eea3f7695226f9af9992cebf8e98ac0ad78b277
"xen/pciback: Don't deadlock when unbinding." was using
the version of pci_reset_function which would lock the device lock.
That is no good as we can dead-lock. As such we swapped to using
the lock-less version and requiring that the callers
of 'pcistub_put_pci_dev' take the device lock. And as such
this bug got exposed.

Using the lock-less version is  OK, except that we tried to
use 'pci_restore_state' after the lock-less version of
__pci_reset_function_locked - which won't work as 'state_saved'
is set to false. Said 'state_saved' is a toggle boolean that
is to be used by the sequence of a) pci_save_state/pci_restore_state
or b) pci_load_and_free_saved_state/pci_restore_state. We don't
want to use a) as the guest might have messed up the PCI
configuration space and we want it to revert to the state
when the PCI device was binded to us. Therefore we pick
b) to restore the configuration space.

To still retain the PCI configuration space, we save it once
more and store it on our private copy to be restored when:
 - Device is unbinded from pciback
 - Device is detached from a guest.

Reported-by:  Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 843a2ba..1126c5a 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -105,7 +105,7 @@ static void pcistub_device_release(struct kref *kref)
 	 */
 	__pci_reset_function_locked(dev);
 	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
-		dev_dbg(&dev->dev, "Could not reload PCI state\n");
+		dev_info(&dev->dev, "Could not reload PCI state\n");
 	else
 		pci_restore_state(dev);
 
@@ -257,6 +257,7 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 {
 	struct pcistub_device *psdev, *found_psdev = NULL;
 	unsigned long flags;
+	struct xen_pcibk_dev_data *dev_data;
 
 	spin_lock_irqsave(&pcistub_devices_lock, flags);
 
@@ -279,9 +280,25 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	 * (so it's ready for the next domain)
 	 */
 	device_lock_assert(&dev->dev);
-	__pci_reset_function_locked(dev);
-	pci_restore_state(dev);
-
+	dev_data = pci_get_drvdata(dev);
+	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
+		dev_info(&dev->dev, "Could not reload PCI state\n");
+	else {
+		__pci_reset_function_locked(dev);
+		/*
+		 * The usual sequence is pci_save_state & pci_restore_state
+		 * but the guest might have messed the configuration space up.
+		 * Use the initial version (when device was binded to us).
+		 */
+		pci_restore_state(dev);
+		/*
+		 * The next steps are to reload the configuration for the
+		 * next time we bind & unbind to a guest - or unload from
+		 * pciback.
+		 */
+		pci_save_state(dev);
+		dev_data->pci_saved_state = pci_store_saved_state(dev);
+	}
 	/* This disables the device. */
 	xen_pcibk_reset_device(dev);
 
-- 
1.8.4.2


--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--yrj/dFKFPuw6o+aM--


From xen-devel-bounces@lists.xen.org Wed Nov 19 20:58:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20:58:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCJy-0004aD-Sg; Wed, 19 Nov 2014 20:57:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCJx-0004a7-RV
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 20:57:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	99/BE-09842-D440D645; Wed, 19 Nov 2014 20:57:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416430667!14009069!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24283 invoked from network); 19 Nov 2014 20:57:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:57:48 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKvSsB008671
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:57:29 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAJKvRm0011381
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 20:57:27 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKvQN4004666; Wed, 19 Nov 2014 20:57:26 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:57:26 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 30CC0118354; Wed, 19 Nov 2014 15:57:25 -0500 (EST)
Date: Wed, 19 Nov 2014 15:57:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141119205724.GC19961@laptop.dumpdata.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-2-git-send-email-talex5@gmail.com>
	<1413888616.23337.22.camel@citrix.com>
	<CAG4opy_ntDYAnN2m-YBvzfPX3CWiHFYZ-tx+u-e=vygntayy9Q@mail.gmail.com>
	<1414406079.31057.6.camel@citrix.com>
	<CAG4opy-bY4HCmGik1y2DRLamXk=Tgj2J0cfqHjFRcs9goM1wqw@mail.gmail.com>
	<1415960966.21321.30.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415960966.21321.30.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Thomas Leonard <talex5@gmail.com>, David Scott <Dave.Scott@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 1/4] mini-os: arm: time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 10:29:26AM +0000, Ian Campbell wrote:
> On Thu, 2014-11-13 at 16:29 +0000, Thomas Leonard wrote:
> > On 27 October 2014 10:34, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Sun, 2014-10-26 at 09:51 +0000, Thomas Leonard wrote:
> > >> On 21 October 2014 11:50, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >> > On Fri, 2014-10-03 at 10:20 +0100, Thomas Leonard wrote:
> > >> >> Based on an initial patch by Karim Raslan.
> > >> >>
> > >> >> Signed-off-by: Karim Allah Ahmed <karim.allah.ahmed@gmail.com>
> > >> >> Signed-off-by: Thomas Leonard <talex5@gmail.com>
> > >> >
> > >> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > >> >
> > >> >> +/* Wall-clock time is not currently available on ARM, so this is always zero for now:
> > >> >> + * http://wiki.xenproject.org/wiki/Xen_ARM_TODO#Expose_Wallclock_time_to_guests
> > >> >
> > >> > I have some slightly hacky patches for this, I really should dust them
> > >> > off and submit them...
> > >> >
> > >> >> +void block_domain(s_time_t until)
> > >> >> +{
> > >> >> +    uint64_t until_count = ns_to_ticks(until) + cntvct_at_init;
> > >> >> +    ASSERT(irqs_disabled());
> > >> >> +    if (read_virtual_count() < until_count)
> > >> >> +    {
> > >> >> +        set_vtimer_compare(until_count);
> > >> >> +        __asm__ __volatile__("wfi");
> > >> >> +        unset_vtimer_compare();
> > >> >> +
> > >> >> +        /* Give the IRQ handler a chance to handle whatever woke us up. */
> > >> >> +        local_irq_enable();
> > >> >> +        local_irq_disable();
> > >> >> +    }
> > >> >
> > >> > Just wondering, is this not roughly equivalent to a wfi loop with
> > >> > interrupts enabled?
> > >>
> > >> I'm not quite sure what you mean.
> > >>
> > >> If we enable interrupts before the wfi then I think the following could occur:
> > >>
> > >> 1. Application checks for work, finds none and calls block_domain.
> > >> 2. block_domain enables interrupts.
> > >> 3. An interrupt occurs.
> > >> 4. The interrupt handler sets a flag indicating work to do.
> > >> 5. wfi is called, putting the domain to sleep, even though there is work to do.
> > >>
> > >> Enabling IRQs after block_domain ensures we can't sleep while we have
> > >> work to do.
> > >
> > > Ah, yes.
> > 
> > So, can this patch be applied as-is now?
> 
> We are now post-rc2 in the 4.5.0 release process, so the answer would be
> "needs a release exception, but it's a feature so probably not" (and it
> would have been a bit dubious towards the end of October too, which was
> post rc1, and feature freeze was the end of September in any case).
> 
> However this is part of a new mini-os port which isn't even hooked into
> the main build system yet (AFAICT), so in that sense it is utterly
> harmless to apply. On the other hand there is a bunch more patches to
> come which are needed to make the mini-os port actually useful, and I'm
> not sure those are all utterly harmless e.g. to common or x86 code (as
> in I've not gone looked at the diffstat for the remaining patches), so
> in that sense there's no harm waiting for 4.6 development to open.
> 
> I defer to the release manager (Konrad, CCd) on this...

I would prefer to defer this to Xen 4.6 to keep the amount of patches
going in staging to be bug-fixes.

Thank you.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 20:58:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 20:58:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCJy-0004aD-Sg; Wed, 19 Nov 2014 20:57:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCJx-0004a7-RV
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 20:57:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	99/BE-09842-D440D645; Wed, 19 Nov 2014 20:57:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416430667!14009069!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24283 invoked from network); 19 Nov 2014 20:57:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 20:57:48 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJKvSsB008671
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 20:57:29 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAJKvRm0011381
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 20:57:27 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJKvQN4004666; Wed, 19 Nov 2014 20:57:26 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 12:57:26 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 30CC0118354; Wed, 19 Nov 2014 15:57:25 -0500 (EST)
Date: Wed, 19 Nov 2014 15:57:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141119205724.GC19961@laptop.dumpdata.com>
References: <1412328051-20015-1-git-send-email-talex5@gmail.com>
	<1412328051-20015-2-git-send-email-talex5@gmail.com>
	<1413888616.23337.22.camel@citrix.com>
	<CAG4opy_ntDYAnN2m-YBvzfPX3CWiHFYZ-tx+u-e=vygntayy9Q@mail.gmail.com>
	<1414406079.31057.6.camel@citrix.com>
	<CAG4opy-bY4HCmGik1y2DRLamXk=Tgj2J0cfqHjFRcs9goM1wqw@mail.gmail.com>
	<1415960966.21321.30.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415960966.21321.30.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Thomas Leonard <talex5@gmail.com>, David Scott <Dave.Scott@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] [PATCH ARM v8 1/4] mini-os: arm: time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 10:29:26AM +0000, Ian Campbell wrote:
> On Thu, 2014-11-13 at 16:29 +0000, Thomas Leonard wrote:
> > On 27 October 2014 10:34, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Sun, 2014-10-26 at 09:51 +0000, Thomas Leonard wrote:
> > >> On 21 October 2014 11:50, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >> > On Fri, 2014-10-03 at 10:20 +0100, Thomas Leonard wrote:
> > >> >> Based on an initial patch by Karim Raslan.
> > >> >>
> > >> >> Signed-off-by: Karim Allah Ahmed <karim.allah.ahmed@gmail.com>
> > >> >> Signed-off-by: Thomas Leonard <talex5@gmail.com>
> > >> >
> > >> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > >> >
> > >> >> +/* Wall-clock time is not currently available on ARM, so this is always zero for now:
> > >> >> + * http://wiki.xenproject.org/wiki/Xen_ARM_TODO#Expose_Wallclock_time_to_guests
> > >> >
> > >> > I have some slightly hacky patches for this, I really should dust them
> > >> > off and submit them...
> > >> >
> > >> >> +void block_domain(s_time_t until)
> > >> >> +{
> > >> >> +    uint64_t until_count = ns_to_ticks(until) + cntvct_at_init;
> > >> >> +    ASSERT(irqs_disabled());
> > >> >> +    if (read_virtual_count() < until_count)
> > >> >> +    {
> > >> >> +        set_vtimer_compare(until_count);
> > >> >> +        __asm__ __volatile__("wfi");
> > >> >> +        unset_vtimer_compare();
> > >> >> +
> > >> >> +        /* Give the IRQ handler a chance to handle whatever woke us up. */
> > >> >> +        local_irq_enable();
> > >> >> +        local_irq_disable();
> > >> >> +    }
> > >> >
> > >> > Just wondering, is this not roughly equivalent to a wfi loop with
> > >> > interrupts enabled?
> > >>
> > >> I'm not quite sure what you mean.
> > >>
> > >> If we enable interrupts before the wfi then I think the following could occur:
> > >>
> > >> 1. Application checks for work, finds none and calls block_domain.
> > >> 2. block_domain enables interrupts.
> > >> 3. An interrupt occurs.
> > >> 4. The interrupt handler sets a flag indicating work to do.
> > >> 5. wfi is called, putting the domain to sleep, even though there is work to do.
> > >>
> > >> Enabling IRQs after block_domain ensures we can't sleep while we have
> > >> work to do.
> > >
> > > Ah, yes.
> > 
> > So, can this patch be applied as-is now?
> 
> We are now post-rc2 in the 4.5.0 release process, so the answer would be
> "needs a release exception, but it's a feature so probably not" (and it
> would have been a bit dubious towards the end of October too, which was
> post rc1, and feature freeze was the end of September in any case).
> 
> However this is part of a new mini-os port which isn't even hooked into
> the main build system yet (AFAICT), so in that sense it is utterly
> harmless to apply. On the other hand there is a bunch more patches to
> come which are needed to make the mini-os port actually useful, and I'm
> not sure those are all utterly harmless e.g. to common or x86 code (as
> in I've not gone looked at the diffstat for the remaining patches), so
> in that sense there's no harm waiting for 4.6 development to open.
> 
> I defer to the release manager (Konrad, CCd) on this...

I would prefer to defer this to Xen 4.6 to keep the amount of patches
going in staging to be bug-fixes.

Thank you.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:02:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21: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 1XrCO6-0004mn-Ha; Wed, 19 Nov 2014 21:02:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCO4-0004mh-VO
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:02:05 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	07/53-02696-C450D645; Wed, 19 Nov 2014 21:02:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416430922!13581560!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1119 invoked from network); 19 Nov 2014 21:02:03 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:02:03 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJL1uqu022331
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:01:57 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL1uhO023761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:01:56 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL1uUS023755; Wed, 19 Nov 2014 21:01:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:01:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id DC97711835A; Wed, 19 Nov 2014 16:01:54 -0500 (EST)
Date: Wed, 19 Nov 2014 16:01:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141119210154.GB20440@laptop.dumpdata.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: liang.z.li@intel.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 12:10:34PM +0000, Wei Liu wrote:
> The existence check is to make sure a device is not added to a guest
> multiple times.
> 
> PCI device backend path has different rules from vif, disk etc. For
> example:
> /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> 
> The devid for PCI devices is hardcoded 0. libxl__device_exists only
> checks up to /local/.../9/0 so it always returns true even the device is
> assignable.
> 
> Remove invocation of libxl__device_exists. We're sure at this point that
> the PCI device is assignable (hence no xenstore entry or JSON entry).
> The check is done before hand. For HVM guest it's done by calling
> xc_test_assign_device and for PV guest it's done by calling
> pciback_dev_is_assigned.
> 
> Reported-by: Li, Liang Z <liang.z.li@intel.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Konrad Wilk <konrad.wilk@oracle.com>
> ---
> This patch fixes a regression in 4.5.

Ouch! That needs then to be fixed.

Is the version you would want to commit? I did test it - and it
looked to do the right thing - thought the xen-pciback is stuck in the
7 state. However that is a seperate issue that I believe is due to
Xen pciback not your patches.

> 
> The risk is that I misunderstood semantics of xc_test_assign_device and
> pciback_dev_is_assigned and end up adding several entries to JSON config
> template. But if the assignable tests are incorrect I think we have a
> bigger problem to worry about than duplicated entries in JSON template.
> 
> It would be good for someone to have PCI hotplug setup to run a quick test.  I
> think Liang confirmed (indrectly) that xc_test_assign_device worked well for
> him so I think there's won't be multiple JSON template entries for HVM guests.
> However PV side still remains to be tested.
> ---
>  tools/libxl/libxl_pci.c |    8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 9f40100..316643c 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -175,14 +175,6 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
>          rc = libxl__xs_transaction_start(gc, &t);
>          if (rc) goto out;
>  
> -        rc = libxl__device_exists(gc, t, device);
> -        if (rc < 0) goto out;
> -        if (rc == 1) {
> -            LOG(ERROR, "device already exists in xenstore");
> -            rc = ERROR_DEVICE_EXISTS;
> -            goto out;
> -        }
> -
>          rc = libxl__set_domain_configuration(gc, domid, &d_config);
>          if (rc) goto out;
>  
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:02:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21: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 1XrCO6-0004mn-Ha; Wed, 19 Nov 2014 21:02:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCO4-0004mh-VO
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:02:05 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	07/53-02696-C450D645; Wed, 19 Nov 2014 21:02:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416430922!13581560!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1119 invoked from network); 19 Nov 2014 21:02:03 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:02:03 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJL1uqu022331
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:01:57 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL1uhO023761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:01:56 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL1uUS023755; Wed, 19 Nov 2014 21:01:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:01:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id DC97711835A; Wed, 19 Nov 2014 16:01:54 -0500 (EST)
Date: Wed, 19 Nov 2014 16:01:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141119210154.GB20440@laptop.dumpdata.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: liang.z.li@intel.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 12:10:34PM +0000, Wei Liu wrote:
> The existence check is to make sure a device is not added to a guest
> multiple times.
> 
> PCI device backend path has different rules from vif, disk etc. For
> example:
> /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> 
> The devid for PCI devices is hardcoded 0. libxl__device_exists only
> checks up to /local/.../9/0 so it always returns true even the device is
> assignable.
> 
> Remove invocation of libxl__device_exists. We're sure at this point that
> the PCI device is assignable (hence no xenstore entry or JSON entry).
> The check is done before hand. For HVM guest it's done by calling
> xc_test_assign_device and for PV guest it's done by calling
> pciback_dev_is_assigned.
> 
> Reported-by: Li, Liang Z <liang.z.li@intel.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Konrad Wilk <konrad.wilk@oracle.com>
> ---
> This patch fixes a regression in 4.5.

Ouch! That needs then to be fixed.

Is the version you would want to commit? I did test it - and it
looked to do the right thing - thought the xen-pciback is stuck in the
7 state. However that is a seperate issue that I believe is due to
Xen pciback not your patches.

> 
> The risk is that I misunderstood semantics of xc_test_assign_device and
> pciback_dev_is_assigned and end up adding several entries to JSON config
> template. But if the assignable tests are incorrect I think we have a
> bigger problem to worry about than duplicated entries in JSON template.
> 
> It would be good for someone to have PCI hotplug setup to run a quick test.  I
> think Liang confirmed (indrectly) that xc_test_assign_device worked well for
> him so I think there's won't be multiple JSON template entries for HVM guests.
> However PV side still remains to be tested.
> ---
>  tools/libxl/libxl_pci.c |    8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 9f40100..316643c 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -175,14 +175,6 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
>          rc = libxl__xs_transaction_start(gc, &t);
>          if (rc) goto out;
>  
> -        rc = libxl__device_exists(gc, t, device);
> -        if (rc < 0) goto out;
> -        if (rc == 1) {
> -            LOG(ERROR, "device already exists in xenstore");
> -            rc = ERROR_DEVICE_EXISTS;
> -            goto out;
> -        }
> -
>          rc = libxl__set_domain_configuration(gc, domid, &d_config);
>          if (rc) goto out;
>  
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:05:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCQv-00055H-3h; Wed, 19 Nov 2014 21:05: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 1XrCQt-00055B-Jv
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 21:04:59 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	10/B9-02697-AF50D645; Wed, 19 Nov 2014 21:04:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416431096!6925181!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5520 invoked from network); 19 Nov 2014 21:04:58 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 21:04:58 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJL4tjS025953
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:04:55 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL4sH2002914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:04:55 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL4saT019992; Wed, 19 Nov 2014 21:04:54 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:04:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4347D118360; Wed, 19 Nov 2014 16:04:53 -0500 (EST)
Date: Wed, 19 Nov 2014 16:04:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119210453.GC20440@laptop.dumpdata.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-4-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415957846-22703-4-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/4] introduce boot parameter for setting
 XENFEAT_virtual_p2m
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 10:37:25AM +0100, Juergen Gross wrote:
> Introduce a new boot parameter "virt_p2m" to be able to set
> XENFEAT_virtual_p2m for a pv domain.
> 
> As long as Xen tools and kdump don't support this new feature it is
> turned off by default.

Couldn't the dom0_large and dom0 be detected automatically? That is
the dom0 could advertise it can do large-dom0 support and Xen would
automatically switch to the right mode?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:05:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCQv-00055H-3h; Wed, 19 Nov 2014 21:05: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 1XrCQt-00055B-Jv
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 21:04:59 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	10/B9-02697-AF50D645; Wed, 19 Nov 2014 21:04:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416431096!6925181!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5520 invoked from network); 19 Nov 2014 21:04:58 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 21:04:58 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJL4tjS025953
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:04:55 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL4sH2002914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:04:55 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL4saT019992; Wed, 19 Nov 2014 21:04:54 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:04:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4347D118360; Wed, 19 Nov 2014 16:04:53 -0500 (EST)
Date: Wed, 19 Nov 2014 16:04:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141119210453.GC20440@laptop.dumpdata.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-4-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415957846-22703-4-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/4] introduce boot parameter for setting
 XENFEAT_virtual_p2m
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 14, 2014 at 10:37:25AM +0100, Juergen Gross wrote:
> Introduce a new boot parameter "virt_p2m" to be able to set
> XENFEAT_virtual_p2m for a pv domain.
> 
> As long as Xen tools and kdump don't support this new feature it is
> turned off by default.

Couldn't the dom0_large and dom0 be detected automatically? That is
the dom0 could advertise it can do large-dom0 support and Xen would
automatically switch to the right mode?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:07:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:07:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCSv-0005CZ-Ss; Wed, 19 Nov 2014 21:07:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCSu-0005CT-Q2
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 21:07:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	49/B0-25276-8760D645; Wed, 19 Nov 2014 21:07:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416431221!14006700!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19179 invoked from network); 19 Nov 2014 21:07:02 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:07:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJL6SAI027940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:06:29 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL6Sm7024760
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:06:28 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL6RbC007031; Wed, 19 Nov 2014 21:06:28 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:06:27 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B2A3F118365; Wed, 19 Nov 2014 16:06:26 -0500 (EST)
Date: Wed, 19 Nov 2014 16:06:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141119210626.GD20440@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-13-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415792454-23161-13-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 13/13] swiotlb-xen: remove BUG_ON in
	xen_bus_to_phys
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 11:40:54AM +0000, Stefano Stabellini wrote:
> On x86 truncation cannot occur because config XEN depends on X86_64 ||
> (X86_32 && X86_PAE).
> 
> On ARM truncation can occur without CONFIG_ARM_LPAE, when the dma
> operation involves foreign grants. However in that case the physical
> address returned by xen_bus_to_phys is actually invalid (there is no mfn
> to pfn tracking for foreign grants on ARM) and it is not used.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/swiotlb-xen.c |    2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 498b654..153cf14 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
>  	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
>  	phys_addr_t paddr = dma;
>  
> -	BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
> -
>  	paddr |= baddr & ~PAGE_MASK;
>  
>  	return paddr;
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:07:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:07:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCSv-0005CZ-Ss; Wed, 19 Nov 2014 21:07:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCSu-0005CT-Q2
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 21:07:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	49/B0-25276-8760D645; Wed, 19 Nov 2014 21:07:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416431221!14006700!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19179 invoked from network); 19 Nov 2014 21:07:02 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:07:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJL6SAI027940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:06:29 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL6Sm7024760
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:06:28 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL6RbC007031; Wed, 19 Nov 2014 21:06:28 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:06:27 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B2A3F118365; Wed, 19 Nov 2014 16:06:26 -0500 (EST)
Date: Wed, 19 Nov 2014 16:06:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141119210626.GD20440@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-13-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415792454-23161-13-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 13/13] swiotlb-xen: remove BUG_ON in
	xen_bus_to_phys
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 11:40:54AM +0000, Stefano Stabellini wrote:
> On x86 truncation cannot occur because config XEN depends on X86_64 ||
> (X86_32 && X86_PAE).
> 
> On ARM truncation can occur without CONFIG_ARM_LPAE, when the dma
> operation involves foreign grants. However in that case the physical
> address returned by xen_bus_to_phys is actually invalid (there is no mfn
> to pfn tracking for foreign grants on ARM) and it is not used.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/swiotlb-xen.c |    2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 498b654..153cf14 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
>  	dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
>  	phys_addr_t paddr = dma;
>  
> -	BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
> -
>  	paddr |= baddr & ~PAGE_MASK;
>  
>  	return paddr;
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:08:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCTn-0005Gv-Ao; Wed, 19 Nov 2014 21:07:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCTl-0005Gl-Uv
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 21:07:58 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	65/3F-02957-DA60D645; Wed, 19 Nov 2014 21:07:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416431257!13592822!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15151 invoked from network); 19 Nov 2014 21:07:39 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:07:39 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJL76ag020505
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:07:07 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL750O008704
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:07:05 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL75gV008687; Wed, 19 Nov 2014 21:07:05 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:07:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 12884118368; Wed, 19 Nov 2014 16:07:04 -0500 (EST)
Date: Wed, 19 Nov 2014 16:07:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141119210703.GE20440@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 12/13] swiotlb-xen: pass dev_addr to
 xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 11:40:53AM +0000, Stefano Stabellini wrote:
> xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
> handle as argument, not a physical address.

Ouch. Should this also go on stable tree?

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>  drivers/xen/swiotlb-xen.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 3725ee4..498b654 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
>  
>  	BUG_ON(dir == DMA_NONE);
>  
> -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
>  
>  	/* NOTE: We use dev_addr here, not paddr! */
>  	if (is_xen_swiotlb_buffer(dev_addr)) {
> @@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
>  	BUG_ON(dir == DMA_NONE);
>  
>  	if (target == SYNC_FOR_CPU)
> -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
>  
>  	/* NOTE: We use dev_addr here, not paddr! */
>  	if (is_xen_swiotlb_buffer(dev_addr))
>  		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
>  
>  	if (target == SYNC_FOR_DEVICE)
> -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
>  
>  	if (dir != DMA_FROM_DEVICE)
>  		return;
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:08:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCTn-0005Gv-Ao; Wed, 19 Nov 2014 21:07:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCTl-0005Gl-Uv
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 21:07:58 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	65/3F-02957-DA60D645; Wed, 19 Nov 2014 21:07:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416431257!13592822!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15151 invoked from network); 19 Nov 2014 21:07:39 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:07:39 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJL76ag020505
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:07:07 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL750O008704
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:07:05 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL75gV008687; Wed, 19 Nov 2014 21:07:05 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:07:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 12884118368; Wed, 19 Nov 2014 16:07:04 -0500 (EST)
Date: Wed, 19 Nov 2014 16:07:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141119210703.GE20440@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 12/13] swiotlb-xen: pass dev_addr to
 xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 11:40:53AM +0000, Stefano Stabellini wrote:
> xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
> handle as argument, not a physical address.

Ouch. Should this also go on stable tree?

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>  drivers/xen/swiotlb-xen.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 3725ee4..498b654 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
>  
>  	BUG_ON(dir == DMA_NONE);
>  
> -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
>  
>  	/* NOTE: We use dev_addr here, not paddr! */
>  	if (is_xen_swiotlb_buffer(dev_addr)) {
> @@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
>  	BUG_ON(dir == DMA_NONE);
>  
>  	if (target == SYNC_FOR_CPU)
> -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
>  
>  	/* NOTE: We use dev_addr here, not paddr! */
>  	if (is_xen_swiotlb_buffer(dev_addr))
>  		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
>  
>  	if (target == SYNC_FOR_DEVICE)
> -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
>  
>  	if (dir != DMA_FROM_DEVICE)
>  		return;
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:09:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCUj-0005Nh-Oc; Wed, 19 Nov 2014 21:08:57 +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 1XrCUh-0005NU-V5
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 21:08:56 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A5/52-03148-7E60D645; Wed, 19 Nov 2014 21:08:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416431333!8178392!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 875 invoked from network); 19 Nov 2014 21:08:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:08:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJL8nYM030457
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:08:50 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL8mQ9009858
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 21:08:49 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJL8lnN015586; Wed, 19 Nov 2014 21:08:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:08:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2776C11836B; Wed, 19 Nov 2014 16:08:46 -0500 (EST)
Date: Wed, 19 Nov 2014 16:08:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>, wei.liu2@citrix.com,
	ian.campbell@citrix.com, ian.jackson@eu.citrix.com
Message-ID: <20141119210845.GF20440@laptop.dumpdata.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> Before this patch, pv guest video_memkb is -1, which is an invalid value.
> And it will cause the xenstore 'memory/targe' calculation wrong:
> 
>     memory/target = info->target_memkb - info->video_memkb

CC-ing the maintainers.

Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?

Thanks.

> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> ---
>  tools/libxl/libxl_create.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index b1ff5ae..1198225 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -357,6 +357,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
> +        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
> +            b_info->video_memkb = 0;
>          if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
>              b_info->shadow_memkb = 0;
>          if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
> -- 
> 1.8.3.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:09:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCUj-0005Nh-Oc; Wed, 19 Nov 2014 21:08:57 +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 1XrCUh-0005NU-V5
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 21:08:56 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A5/52-03148-7E60D645; Wed, 19 Nov 2014 21:08:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416431333!8178392!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 875 invoked from network); 19 Nov 2014 21:08:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:08:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJL8nYM030457
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:08:50 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJL8mQ9009858
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 21:08:49 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJL8lnN015586; Wed, 19 Nov 2014 21:08:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:08:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2776C11836B; Wed, 19 Nov 2014 16:08:46 -0500 (EST)
Date: Wed, 19 Nov 2014 16:08:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>, wei.liu2@citrix.com,
	ian.campbell@citrix.com, ian.jackson@eu.citrix.com
Message-ID: <20141119210845.GF20440@laptop.dumpdata.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> Before this patch, pv guest video_memkb is -1, which is an invalid value.
> And it will cause the xenstore 'memory/targe' calculation wrong:
> 
>     memory/target = info->target_memkb - info->video_memkb

CC-ing the maintainers.

Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?

Thanks.

> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> ---
>  tools/libxl/libxl_create.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index b1ff5ae..1198225 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -357,6 +357,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
> +        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
> +            b_info->video_memkb = 0;
>          if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
>              b_info->shadow_memkb = 0;
>          if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
> -- 
> 1.8.3.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:11:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCXS-0005cT-Ka; Wed, 19 Nov 2014 21:11:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCXR-0005cK-T4
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:11:45 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	71/6E-02953-1970D645; Wed, 19 Nov 2014 21:11:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416431503!8178749!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11327 invoked from network); 19 Nov 2014 21:11:44 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:11:44 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLBbeJ001391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:11:38 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLBZgX009668
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 21:11:36 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJLBYL0022971; Wed, 19 Nov 2014 21:11:34 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:11:34 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EEE1F118370; Wed, 19 Nov 2014 16:11:32 -0500 (EST)
Date: Wed, 19 Nov 2014 16:11:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141119211132.GG20440@laptop.dumpdata.com>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: stefano.stabellini@eu.citrix.com, julien.grall@linaro.org, tim@xen.org,
	xen-devel@lists.xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 2/4] xen: arm: correct off by one in
 xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 04:44:46PM +0000, Ian Campbell wrote:
> The callers pass the end as the pfn immediately *after* the last page to be
> mapped, therefore adding one is incorrect and causes an additional page to be
> mapped.
> 
> At the same time correct the printing of the mfn values, zero-padding them to
> 16 digits as for a paddr when they are frame numbers is just confusing.

HA! I was just looking at that today and thought it was odd.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/platforms/xgene-storm.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 29c4752..38674cd 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -45,9 +45,9 @@ static int map_one_mmio(struct domain *d, const char *what,
>  {
>      int ret;
>  
> -    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
> +    printk("Additional MMIO %lx-%lx (%s)\n",
>             start, end, what);
> -    ret = map_mmio_regions(d, start, end - start + 1, start);
> +    ret = map_mmio_regions(d, start, end - start, start);
>      if ( ret )
>          printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
>                 what, start, d->domain_id);
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:11:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCXS-0005cT-Ka; Wed, 19 Nov 2014 21:11:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCXR-0005cK-T4
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:11:45 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	71/6E-02953-1970D645; Wed, 19 Nov 2014 21:11:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416431503!8178749!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11327 invoked from network); 19 Nov 2014 21:11:44 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:11:44 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLBbeJ001391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:11:38 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLBZgX009668
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 21:11:36 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJLBYL0022971; Wed, 19 Nov 2014 21:11:34 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:11:34 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EEE1F118370; Wed, 19 Nov 2014 16:11:32 -0500 (EST)
Date: Wed, 19 Nov 2014 16:11:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141119211132.GG20440@laptop.dumpdata.com>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416329088-23328-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: stefano.stabellini@eu.citrix.com, julien.grall@linaro.org, tim@xen.org,
	xen-devel@lists.xen.org, Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 2/4] xen: arm: correct off by one in
 xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 04:44:46PM +0000, Ian Campbell wrote:
> The callers pass the end as the pfn immediately *after* the last page to be
> mapped, therefore adding one is incorrect and causes an additional page to be
> mapped.
> 
> At the same time correct the printing of the mfn values, zero-padding them to
> 16 digits as for a paddr when they are frame numbers is just confusing.

HA! I was just looking at that today and thought it was odd.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/platforms/xgene-storm.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 29c4752..38674cd 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -45,9 +45,9 @@ static int map_one_mmio(struct domain *d, const char *what,
>  {
>      int ret;
>  
> -    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
> +    printk("Additional MMIO %lx-%lx (%s)\n",
>             start, end, what);
> -    ret = map_mmio_regions(d, start, end - start + 1, start);
> +    ret = map_mmio_regions(d, start, end - start, start);
>      if ( ret )
>          printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
>                 what, start, d->domain_id);
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:19:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:19:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCee-0005t3-I9; Wed, 19 Nov 2014 21:19:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCed-0005sy-Ay
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:19:11 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	C0/65-05632-E490D645; Wed, 19 Nov 2014 21:19:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416431948!12412487!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17342 invoked from network); 19 Nov 2014 21:19:10 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:19:10 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLJ39J010233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:19:03 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLJ1CV016052
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 21:19:02 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJLJ0Hb015744; Wed, 19 Nov 2014 21:19:00 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:18:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AB10811837E; Wed, 19 Nov 2014 16:18:58 -0500 (EST)
Date: Wed, 19 Nov 2014 16:18:58 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141119211858.GH20440@laptop.dumpdata.com>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329502.17982.28.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416329502.17982.28.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/4 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 04:51:42PM +0000, Ian Campbell wrote:
> On Tue, 2014-11-18 at 16:44 +0000, Ian Campbell wrote:
> > These patches:
> 
> ... which are also at
>         git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v1

I presume you are going to post v2 with Julian's feedback rolled in?

I took a look at the code and it looks Xen 4.5 material so I am
OK with it rolling in, but would appreciate another posting just
to make sure that nothing is amiss.

Thank you!
> 
> 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 Nov 19 21:19:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:19:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCee-0005t3-I9; Wed, 19 Nov 2014 21:19:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCed-0005sy-Ay
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:19:11 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	C0/65-05632-E490D645; Wed, 19 Nov 2014 21:19:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416431948!12412487!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17342 invoked from network); 19 Nov 2014 21:19:10 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:19:10 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLJ39J010233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:19:03 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLJ1CV016052
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 21:19:02 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJLJ0Hb015744; Wed, 19 Nov 2014 21:19:00 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:18:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AB10811837E; Wed, 19 Nov 2014 16:18:58 -0500 (EST)
Date: Wed, 19 Nov 2014 16:18:58 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141119211858.GH20440@laptop.dumpdata.com>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329502.17982.28.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416329502.17982.28.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/4 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 04:51:42PM +0000, Ian Campbell wrote:
> On Tue, 2014-11-18 at 16:44 +0000, Ian Campbell wrote:
> > These patches:
> 
> ... which are also at
>         git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v1

I presume you are going to post v2 with Julian's feedback rolled in?

I took a look at the code and it looks Xen 4.5 material so I am
OK with it rolling in, but would appreciate another posting just
to make sure that nothing is amiss.

Thank you!
> 
> 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 Nov 19 21:21:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:21:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCgh-0005yY-2S; Wed, 19 Nov 2014 21:21:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCge-0005yN-Uo
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:21:17 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	13/5D-27584-CC90D645; Wed, 19 Nov 2014 21:21:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416432072!12329024!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28287 invoked from network); 19 Nov 2014 21:21:13 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:21:13 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLL7H6012635
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:21:07 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLL6Lq021849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:21:07 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLL6bm021846; Wed, 19 Nov 2014 21:21:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:21:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 54186118387; Wed, 19 Nov 2014 16:21:05 -0500 (EST)
Date: Wed, 19 Nov 2014 16:21:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141119212104.GI20440@laptop.dumpdata.com>
References: <1416395856-20849-1-git-send-email-andrew.cooper3@citrix.com>
	<1416396138.29243.28.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416396138.29243.28.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] docs/commandline: Fix formatting
	issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 11:22:18AM +0000, Ian Campbell wrote:
> On Wed, 2014-11-19 at 11:17 +0000, Andrew Cooper wrote:
> > In both of these cases, markdown was interpreting the text as regular text,
> > and reflowing it as a regular paragraph, leading to a single line as output.
> > Reformat them as code blocks inside blockquote blocks, which causes them to
> > take their precise whitespace layout.
> > 
> > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
> 
> > CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> > CC: Wei Liu <wei.liu2@citrix.com>
> > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > ---
> > 
> > Konrad: this is a documentation fix, so requesting a 4.5 ack please.
> 
> FWIW IMHO documentation fixes in general should have a very low bar to
> cross until very late in the release cycle...

I concur, I updated the release criteria doc so that it will be expediated
in the future.

> 
> > ---
> >  docs/misc/xen-command-line.markdown |   38 +++++++++++++++++------------------
> >  1 file changed, 19 insertions(+), 19 deletions(-)
> > 
> > diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> > index f054d4b..e3a5a15 100644
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -475,13 +475,13 @@ defaults of 1 and unlimited respectively are used instead.
> >  
> >  For example, with `dom0_max_vcpus=4-8`:
> >  
> > -     Number of
> > -  PCPUs | Dom0 VCPUs
> > -   2    |  4
> > -   4    |  4
> > -   6    |  6
> > -   8    |  8
> > -  10    |  8
> > +>        Number of
> > +>     PCPUs | Dom0 VCPUs
> > +>      2    |  4
> > +>      4    |  4
> > +>      6    |  6
> > +>      8    |  8
> > +>     10    |  8
> >  
> >  ### dom0\_mem
> >  > `= List of ( min:<size> | max:<size> | <size> )`
> > @@ -684,18 +684,18 @@ supported only when compiled with XSM\_ENABLE=y on x86.
> >  The specified value is a bit mask with the individual bits having the
> >  following meaning:
> >  
> > -Bit  0 - debug level 0 (unused at present)
> > -Bit  1 - debug level 1 (Control Register logging)
> > -Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
> > -Bit  3 - debug level 3 (unused at present)
> > -Bit  4 - I/O operation logging
> > -Bit  5 - vMMU logging
> > -Bit  6 - vLAPIC general logging
> > -Bit  7 - vLAPIC timer logging
> > -Bit  8 - vLAPIC interrupt logging
> > -Bit  9 - vIOAPIC logging
> > -Bit 10 - hypercall logging
> > -Bit 11 - MSR operation logging
> > +>     Bit  0 - debug level 0 (unused at present)
> > +>     Bit  1 - debug level 1 (Control Register logging)
> > +>     Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
> > +>     Bit  3 - debug level 3 (unused at present)
> > +>     Bit  4 - I/O operation logging
> > +>     Bit  5 - vMMU logging
> > +>     Bit  6 - vLAPIC general logging
> > +>     Bit  7 - vLAPIC timer logging
> > +>     Bit  8 - vLAPIC interrupt logging
> > +>     Bit  9 - vIOAPIC logging
> > +>     Bit 10 - hypercall logging
> > +>     Bit 11 - MSR operation logging
> >  
> >  Recognized in debug builds of the hypervisor only.
> >  
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:21:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:21:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCgh-0005yY-2S; Wed, 19 Nov 2014 21:21:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCge-0005yN-Uo
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:21:17 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	13/5D-27584-CC90D645; Wed, 19 Nov 2014 21:21:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416432072!12329024!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28287 invoked from network); 19 Nov 2014 21:21:13 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:21:13 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLL7H6012635
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:21:07 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLL6Lq021849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:21:07 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLL6bm021846; Wed, 19 Nov 2014 21:21:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:21:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 54186118387; Wed, 19 Nov 2014 16:21:05 -0500 (EST)
Date: Wed, 19 Nov 2014 16:21:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141119212104.GI20440@laptop.dumpdata.com>
References: <1416395856-20849-1-git-send-email-andrew.cooper3@citrix.com>
	<1416396138.29243.28.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416396138.29243.28.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] docs/commandline: Fix formatting
	issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 11:22:18AM +0000, Ian Campbell wrote:
> On Wed, 2014-11-19 at 11:17 +0000, Andrew Cooper wrote:
> > In both of these cases, markdown was interpreting the text as regular text,
> > and reflowing it as a regular paragraph, leading to a single line as output.
> > Reformat them as code blocks inside blockquote blocks, which causes them to
> > take their precise whitespace layout.
> > 
> > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
> 
> > CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> > CC: Wei Liu <wei.liu2@citrix.com>
> > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > ---
> > 
> > Konrad: this is a documentation fix, so requesting a 4.5 ack please.
> 
> FWIW IMHO documentation fixes in general should have a very low bar to
> cross until very late in the release cycle...

I concur, I updated the release criteria doc so that it will be expediated
in the future.

> 
> > ---
> >  docs/misc/xen-command-line.markdown |   38 +++++++++++++++++------------------
> >  1 file changed, 19 insertions(+), 19 deletions(-)
> > 
> > diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> > index f054d4b..e3a5a15 100644
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -475,13 +475,13 @@ defaults of 1 and unlimited respectively are used instead.
> >  
> >  For example, with `dom0_max_vcpus=4-8`:
> >  
> > -     Number of
> > -  PCPUs | Dom0 VCPUs
> > -   2    |  4
> > -   4    |  4
> > -   6    |  6
> > -   8    |  8
> > -  10    |  8
> > +>        Number of
> > +>     PCPUs | Dom0 VCPUs
> > +>      2    |  4
> > +>      4    |  4
> > +>      6    |  6
> > +>      8    |  8
> > +>     10    |  8
> >  
> >  ### dom0\_mem
> >  > `= List of ( min:<size> | max:<size> | <size> )`
> > @@ -684,18 +684,18 @@ supported only when compiled with XSM\_ENABLE=y on x86.
> >  The specified value is a bit mask with the individual bits having the
> >  following meaning:
> >  
> > -Bit  0 - debug level 0 (unused at present)
> > -Bit  1 - debug level 1 (Control Register logging)
> > -Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
> > -Bit  3 - debug level 3 (unused at present)
> > -Bit  4 - I/O operation logging
> > -Bit  5 - vMMU logging
> > -Bit  6 - vLAPIC general logging
> > -Bit  7 - vLAPIC timer logging
> > -Bit  8 - vLAPIC interrupt logging
> > -Bit  9 - vIOAPIC logging
> > -Bit 10 - hypercall logging
> > -Bit 11 - MSR operation logging
> > +>     Bit  0 - debug level 0 (unused at present)
> > +>     Bit  1 - debug level 1 (Control Register logging)
> > +>     Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
> > +>     Bit  3 - debug level 3 (unused at present)
> > +>     Bit  4 - I/O operation logging
> > +>     Bit  5 - vMMU logging
> > +>     Bit  6 - vLAPIC general logging
> > +>     Bit  7 - vLAPIC timer logging
> > +>     Bit  8 - vLAPIC interrupt logging
> > +>     Bit  9 - vIOAPIC logging
> > +>     Bit 10 - hypercall logging
> > +>     Bit 11 - MSR operation logging
> >  
> >  Recognized in debug builds of the hypervisor only.
> >  
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:21:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCgr-00060Q-FH; Wed, 19 Nov 2014 21:21:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XrCgq-00060D-KE
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:21:28 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	05/69-02699-7D90D645; Wed, 19 Nov 2014 21:21:27 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416432085!10268974!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5675 invoked from network); 19 Nov 2014 21:21:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 21:21:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,419,1413244800"; d="scan'208";a="193058437"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 16:21:24 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrCgl-0002fK-Mb;
	Wed, 19 Nov 2014 21:21:23 +0000
Date: Wed, 19 Nov 2014 21:21:23 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141119212123.GA27349@zion.uk.xensource.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
	<20141119210154.GB20440@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141119210154.GB20440@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, liang.z.li@intel.com,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 17, 2014 at 12:10:34PM +0000, Wei Liu wrote:
> > The existence check is to make sure a device is not added to a guest
> > multiple times.
> > 
> > PCI device backend path has different rules from vif, disk etc. For
> > example:
> > /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> > /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> > /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> > /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> > 
> > The devid for PCI devices is hardcoded 0. libxl__device_exists only
> > checks up to /local/.../9/0 so it always returns true even the device is
> > assignable.
> > 
> > Remove invocation of libxl__device_exists. We're sure at this point that
> > the PCI device is assignable (hence no xenstore entry or JSON entry).
> > The check is done before hand. For HVM guest it's done by calling
> > xc_test_assign_device and for PV guest it's done by calling
> > pciback_dev_is_assigned.
> > 
> > Reported-by: Li, Liang Z <liang.z.li@intel.com>
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > ---
> > This patch fixes a regression in 4.5.
> 
> Ouch! That needs then to be fixed.
> 
> Is the version you would want to commit? I did test it - and it

Yes.

> looked to do the right thing - thought the xen-pciback is stuck in the
> 7 state. However that is a seperate issue that I believe is due to
> Xen pciback not your patches.
> 

Thanks for testing.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:21:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCgr-00060Q-FH; Wed, 19 Nov 2014 21:21:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XrCgq-00060D-KE
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:21:28 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	05/69-02699-7D90D645; Wed, 19 Nov 2014 21:21:27 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416432085!10268974!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5675 invoked from network); 19 Nov 2014 21:21:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 21:21:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,419,1413244800"; d="scan'208";a="193058437"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 16:21:24 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrCgl-0002fK-Mb;
	Wed, 19 Nov 2014 21:21:23 +0000
Date: Wed, 19 Nov 2014 21:21:23 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141119212123.GA27349@zion.uk.xensource.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
	<20141119210154.GB20440@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141119210154.GB20440@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, liang.z.li@intel.com,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 17, 2014 at 12:10:34PM +0000, Wei Liu wrote:
> > The existence check is to make sure a device is not added to a guest
> > multiple times.
> > 
> > PCI device backend path has different rules from vif, disk etc. For
> > example:
> > /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> > /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> > /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> > /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> > 
> > The devid for PCI devices is hardcoded 0. libxl__device_exists only
> > checks up to /local/.../9/0 so it always returns true even the device is
> > assignable.
> > 
> > Remove invocation of libxl__device_exists. We're sure at this point that
> > the PCI device is assignable (hence no xenstore entry or JSON entry).
> > The check is done before hand. For HVM guest it's done by calling
> > xc_test_assign_device and for PV guest it's done by calling
> > pciback_dev_is_assigned.
> > 
> > Reported-by: Li, Liang Z <liang.z.li@intel.com>
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > ---
> > This patch fixes a regression in 4.5.
> 
> Ouch! That needs then to be fixed.
> 
> Is the version you would want to commit? I did test it - and it

Yes.

> looked to do the right thing - thought the xen-pciback is stuck in the
> 7 state. However that is a seperate issue that I believe is due to
> Xen pciback not your patches.
> 

Thanks for testing.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:25:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:25:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCkA-0006HQ-2i; Wed, 19 Nov 2014 21:24:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XrCk8-0006HI-I3
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 21:24:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AB/8A-25276-3AA0D645; Wed, 19 Nov 2014 21:24:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416432289!13975129!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26531 invoked from network); 19 Nov 2014 21:24:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 21:24:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,419,1413244800"; d="scan'208";a="193059782"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 16:24:35 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrCjr-0002hh-8j;
	Wed, 19 Nov 2014 21:24:35 +0000
Date: Wed, 19 Nov 2014 21:24:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141119212434.GB27349@zion.uk.xensource.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
	<20141119210845.GF20440@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141119210845.GF20440@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Zhigang Wang <zhigang.x.wang@oracle.com>,
	wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > And it will cause the xenstore 'memory/targe' calculation wrong:
> > 
> >     memory/target = info->target_memkb - info->video_memkb
> 
> CC-ing the maintainers.
> 
> Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?
> 

I don't think this is a regression, it has been broken for quite a
while.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:25:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:25:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCkA-0006HQ-2i; Wed, 19 Nov 2014 21:24:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XrCk8-0006HI-I3
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 21:24:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AB/8A-25276-3AA0D645; Wed, 19 Nov 2014 21:24:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416432289!13975129!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26531 invoked from network); 19 Nov 2014 21:24:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 21:24:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,419,1413244800"; d="scan'208";a="193059782"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 19 Nov 2014 16:24:35 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrCjr-0002hh-8j;
	Wed, 19 Nov 2014 21:24:35 +0000
Date: Wed, 19 Nov 2014 21:24:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141119212434.GB27349@zion.uk.xensource.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
	<20141119210845.GF20440@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141119210845.GF20440@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Zhigang Wang <zhigang.x.wang@oracle.com>,
	wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > And it will cause the xenstore 'memory/targe' calculation wrong:
> > 
> >     memory/target = info->target_memkb - info->video_memkb
> 
> CC-ing the maintainers.
> 
> Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?
> 

I don't think this is a regression, it has been broken for quite a
while.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:25:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:25:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCke-0006KT-HK; Wed, 19 Nov 2014 21:25:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCkd-0006KK-BS
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:25:23 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	33/0A-27623-2CA0D645; Wed, 19 Nov 2014 21:25:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416432318!12508120!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10454 invoked from network); 19 Nov 2014 21:25:20 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:25:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLPAoB017091
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:25:11 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLP7Z2003126
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:25:08 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLP78m020248; Wed, 19 Nov 2014 21:25:07 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:25:07 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 34B80118395; Wed, 19 Nov 2014 16:25:06 -0500 (EST)
Date: Wed, 19 Nov 2014 16:25:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141119212505.GJ20440@laptop.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21612.32360.328456.516321@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Chunyan Liu <cyliu@suse.com>, wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote:
> Hi Konrad, I have another release ack request:
> 
> Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > still some places in xenstore are not updated, including:
> > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> > This patch series updates /vm/<uuid>/name in xenstore,
> 
> This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
> bugfix which I think should go into Xen 4.5.
> 
> The risk WITHOUT this patch is that there are out-of-tree tools which
> look here for the domain name and will get confused after it is
> renamed.

When was this introduced? Did it exist with Xend?

> 
> The risk WITH this patch is that the implementation could be wrong
> somehow, in which case the code would need to be updated again.  But
> it's a very small patch and has been fully reviewed.

I checked QEMU and didn't find anything in there.

> 
> 
> > and removes the unusual 'domain' field under backend directory.
> 
> This is a reference to "[PATCH 1/2 V3] remove domain field in xenstore
> backend dir".  The change to libxl is that it no longer writes
>   /local/domain/0/backend/vfb/3/0/domain = "name of frontend domain"
> 
> It seems hardly conceivable that anyone could be using this field.
> Existing users will not work after the domain is renamed, anyway.
> 
> The risk on both sides of the decision lies entirely with out-of-tree
> software which looks here for the domain name for some reason.  We
> don't think any such tools exist.
> 
> Note that the domain name cannot be used directly by a non-dom0
> programs because the mapping between domids and domain names is in a
> part of xenstore which is not accessible to guests.  (It is possible
> that a guest would read this value merely to display it.)
> 
> 
> If such out-of-tree software exists:
> 
> The risk WITHOUT this patch is that it might report, or (worse)
> operate on, the wrong domain entirely.
> 
> The risk WITH this patch is that it (or some subset of its
> functionality) would stop working right away.
> 
> 
> An alternative would be to update all of these entries on rename.
> That's a large and somewhat fiddly patch which we don't think is
> appropriate given that the presence of this key is a mistake.
> 
> 
> 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 Nov 19 21:25:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:25:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCke-0006KT-HK; Wed, 19 Nov 2014 21:25:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCkd-0006KK-BS
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:25:23 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	33/0A-27623-2CA0D645; Wed, 19 Nov 2014 21:25:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416432318!12508120!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10454 invoked from network); 19 Nov 2014 21:25:20 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:25:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLPAoB017091
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:25:11 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLP7Z2003126
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:25:08 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLP78m020248; Wed, 19 Nov 2014 21:25:07 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:25:07 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 34B80118395; Wed, 19 Nov 2014 16:25:06 -0500 (EST)
Date: Wed, 19 Nov 2014 16:25:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141119212505.GJ20440@laptop.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21612.32360.328456.516321@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Chunyan Liu <cyliu@suse.com>, wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote:
> Hi Konrad, I have another release ack request:
> 
> Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > still some places in xenstore are not updated, including:
> > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> > This patch series updates /vm/<uuid>/name in xenstore,
> 
> This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
> bugfix which I think should go into Xen 4.5.
> 
> The risk WITHOUT this patch is that there are out-of-tree tools which
> look here for the domain name and will get confused after it is
> renamed.

When was this introduced? Did it exist with Xend?

> 
> The risk WITH this patch is that the implementation could be wrong
> somehow, in which case the code would need to be updated again.  But
> it's a very small patch and has been fully reviewed.

I checked QEMU and didn't find anything in there.

> 
> 
> > and removes the unusual 'domain' field under backend directory.
> 
> This is a reference to "[PATCH 1/2 V3] remove domain field in xenstore
> backend dir".  The change to libxl is that it no longer writes
>   /local/domain/0/backend/vfb/3/0/domain = "name of frontend domain"
> 
> It seems hardly conceivable that anyone could be using this field.
> Existing users will not work after the domain is renamed, anyway.
> 
> The risk on both sides of the decision lies entirely with out-of-tree
> software which looks here for the domain name for some reason.  We
> don't think any such tools exist.
> 
> Note that the domain name cannot be used directly by a non-dom0
> programs because the mapping between domids and domain names is in a
> part of xenstore which is not accessible to guests.  (It is possible
> that a guest would read this value merely to display it.)
> 
> 
> If such out-of-tree software exists:
> 
> The risk WITHOUT this patch is that it might report, or (worse)
> operate on, the wrong domain entirely.
> 
> The risk WITH this patch is that it (or some subset of its
> functionality) would stop working right away.
> 
> 
> An alternative would be to update all of these entries on rename.
> That's a large and somewhat fiddly patch which we don't think is
> appropriate given that the presence of this key is a mistake.
> 
> 
> 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 Nov 19 21:27:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:27:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCml-0006WF-31; Wed, 19 Nov 2014 21:27:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCmj-0006W5-KH
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:27:33 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	AA/5F-17694-44B0D645; Wed, 19 Nov 2014 21:27:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416432450!12562746!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12784 invoked from network); 19 Nov 2014 21:27:32 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:27:32 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLRPE8010989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:27:26 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLRNM9026208
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:27:23 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLRNFQ008763; Wed, 19 Nov 2014 21:27:23 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:27:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 945E611839B; Wed, 19 Nov 2014 16:27:21 -0500 (EST)
Date: Wed, 19 Nov 2014 16:27:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141119212721.GK20440@laptop.dumpdata.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/5 v2 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 03:27:48PM +0000, Ian Campbell wrote:
> These patches:
> 
>       * fix up an off by one bug in the xgene mapping of additional PCI
>         bus resources, which would cause an additional extra page to be
>         mapped
>       * correct the size of the mapped regions to match the docs
>       * adds support for the other 4 PCI buses on the chip, which
>         enables mcdivitt and presumably most other Xgene based platforms
>         which uses PCI buses other than pcie0.
>       * adds earlyprintk for the mcdivitt platform
> 
> They can also be found at:
>         git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v2

#1-#4 can go in - aka Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
For #5 I would appreciate an ARM knowledgeble person to review it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:27:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:27:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCml-0006WF-31; Wed, 19 Nov 2014 21:27:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCmj-0006W5-KH
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:27:33 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	AA/5F-17694-44B0D645; Wed, 19 Nov 2014 21:27:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416432450!12562746!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12784 invoked from network); 19 Nov 2014 21:27:32 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:27:32 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLRPE8010989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:27:26 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLRNM9026208
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:27:23 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLRNFQ008763; Wed, 19 Nov 2014 21:27:23 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:27:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 945E611839B; Wed, 19 Nov 2014 16:27:21 -0500 (EST)
Date: Wed, 19 Nov 2014 16:27:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141119212721.GK20440@laptop.dumpdata.com>
References: <1416410868.29243.39.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416410868.29243.39.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/5 v2 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 03:27:48PM +0000, Ian Campbell wrote:
> These patches:
> 
>       * fix up an off by one bug in the xgene mapping of additional PCI
>         bus resources, which would cause an additional extra page to be
>         mapped
>       * correct the size of the mapped regions to match the docs
>       * adds support for the other 4 PCI buses on the chip, which
>         enables mcdivitt and presumably most other Xgene based platforms
>         which uses PCI buses other than pcie0.
>       * adds earlyprintk for the mcdivitt platform
> 
> They can also be found at:
>         git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v2

#1-#4 can go in - aka Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
For #5 I would appreciate an ARM knowledgeble person to review it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:29:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:29:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCoE-0006hH-N7; Wed, 19 Nov 2014 21:29:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCoD-0006h1-4P
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:29:05 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	E6/2A-25714-0AB0D645; Wed, 19 Nov 2014 21:29:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416432541!12352508!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16917 invoked from network); 19 Nov 2014 21:29:02 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 21:29:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLStVm021701
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:28:56 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLStTH000874
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:28:55 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLSs6h000869; Wed, 19 Nov 2014 21:28:54 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:28:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B93C71183A0; Wed, 19 Nov 2014 16:28:53 -0500 (EST)
Date: Wed, 19 Nov 2014 16:28:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141119212853.GM20440@laptop.dumpdata.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
	<20141119210154.GB20440@laptop.dumpdata.com>
	<20141119212123.GA27349@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141119212123.GA27349@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: liang.z.li@intel.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 09:21:23PM +0000, Wei Liu wrote:
> On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 17, 2014 at 12:10:34PM +0000, Wei Liu wrote:
> > > The existence check is to make sure a device is not added to a guest
> > > multiple times.
> > > 
> > > PCI device backend path has different rules from vif, disk etc. For
> > > example:
> > > /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> > > /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> > > /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> > > /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> > > 
> > > The devid for PCI devices is hardcoded 0. libxl__device_exists only
> > > checks up to /local/.../9/0 so it always returns true even the device is
> > > assignable.
> > > 
> > > Remove invocation of libxl__device_exists. We're sure at this point that
> > > the PCI device is assignable (hence no xenstore entry or JSON entry).
> > > The check is done before hand. For HVM guest it's done by calling
> > > xc_test_assign_device and for PV guest it's done by calling
> > > pciback_dev_is_assigned.
> > > 
> > > Reported-by: Li, Liang Z <liang.z.li@intel.com>
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > > ---
> > > This patch fixes a regression in 4.5.
> > 
> > Ouch! That needs then to be fixed.
> > 
> > Is the version you would want to commit? I did test it - and it
> 
> Yes.

Then Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > looked to do the right thing - thought the xen-pciback is stuck in the
> > 7 state. However that is a seperate issue that I believe is due to
> > Xen pciback not your patches.
> > 
> 
> Thanks for testing.
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:29:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21:29:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrCoE-0006hH-N7; Wed, 19 Nov 2014 21:29:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCoD-0006h1-4P
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 21:29:05 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	E6/2A-25714-0AB0D645; Wed, 19 Nov 2014 21:29:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416432541!12352508!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16917 invoked from network); 19 Nov 2014 21:29:02 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Nov 2014 21:29:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLStVm021701
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:28:56 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLStTH000874
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 21:28:55 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLSs6h000869; Wed, 19 Nov 2014 21:28:54 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:28:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B93C71183A0; Wed, 19 Nov 2014 16:28:53 -0500 (EST)
Date: Wed, 19 Nov 2014 16:28:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141119212853.GM20440@laptop.dumpdata.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
	<20141119210154.GB20440@laptop.dumpdata.com>
	<20141119212123.GA27349@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141119212123.GA27349@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: liang.z.li@intel.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 09:21:23PM +0000, Wei Liu wrote:
> On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 17, 2014 at 12:10:34PM +0000, Wei Liu wrote:
> > > The existence check is to make sure a device is not added to a guest
> > > multiple times.
> > > 
> > > PCI device backend path has different rules from vif, disk etc. For
> > > example:
> > > /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> > > /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> > > /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> > > /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> > > 
> > > The devid for PCI devices is hardcoded 0. libxl__device_exists only
> > > checks up to /local/.../9/0 so it always returns true even the device is
> > > assignable.
> > > 
> > > Remove invocation of libxl__device_exists. We're sure at this point that
> > > the PCI device is assignable (hence no xenstore entry or JSON entry).
> > > The check is done before hand. For HVM guest it's done by calling
> > > xc_test_assign_device and for PV guest it's done by calling
> > > pciback_dev_is_assigned.
> > > 
> > > Reported-by: Li, Liang Z <liang.z.li@intel.com>
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > > ---
> > > This patch fixes a regression in 4.5.
> > 
> > Ouch! That needs then to be fixed.
> > 
> > Is the version you would want to commit? I did test it - and it
> 
> Yes.

Then Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > looked to do the right thing - thought the xen-pciback is stuck in the
> > 7 state. However that is a seperate issue that I believe is due to
> > Xen pciback not your patches.
> > 
> 
> Thanks for testing.
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:32:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21: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 1XrCrh-0006sl-Aw; Wed, 19 Nov 2014 21:32:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCrf-0006sf-AZ
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 21:32:39 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	F0/19-29352-67C0D645; Wed, 19 Nov 2014 21:32:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416432756!12310934!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13969 invoked from network); 19 Nov 2014 21:32:37 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:32:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLWVTG026163
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:32:31 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLWUde013245
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 21:32:30 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJLWS0h022583; Wed, 19 Nov 2014 21:32:29 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:32:28 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2C88A1183A6; Wed, 19 Nov 2014 16:32:27 -0500 (EST)
Date: Wed, 19 Nov 2014 16:32:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Simon Cao <caobosimon@gmail.com>
Message-ID: <20141119213226.GA21408@laptop.dumpdata.com>
References: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
	<5460E9D80200006600078038@soto.provo.novell.com>
	<CAMJpVt8yO8SDpmgFE1XJDNCF1v87Czt+9Li117xZnhsxpCRj_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMJpVt8yO8SDpmgFE1XJDNCF1v87Czt+9Li117xZnhsxpCRj_Q@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Lars Kurth <lars.kurth@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>, Chun Yan Liu <cyliu@suse.com>,
	Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Nov 16, 2014 at 10:36:28AM +0800, Simon Cao wrote:
> Hi,
> =

> I was working on the work. But I was busing preparing some job interviews
> in the last three months, sorry for this long delay. I will update my
> progress in a few days.

OK, I put your name for this to be in Xen 4.6.

Thanks!
> =

> Thanks!
> =

> Bo Cao
> =

> On Mon, Nov 10, 2014 at 4:37 PM, Chun Yan Liu <cyliu@suse.com> wrote:
> =

> > Is there any progress on this work? I didn't see new version after this.
> > Anyone knows the status?
> >
> > Thanks,
> > Chunyan
> >
> > >>> On 8/11/2014 at 04:23 AM, in message
> > <1407702234-22309-1-git-send-email-caobosimon@gmail.com>, Bo Cao
> > <caobosimon@gmail.com> wrote:
> > > Finally I have a workable version xl/libxl support for PVUSB. Most of
> > > its commands work property now, but there are still some probelm to be
> > > solved.
> > > Please take a loot and give me some advices.
> > >
> > > =3D=3D What have been implemented ? =3D=3D
> > > I have implemented libxl functions for PVUSB in libxl_usb.c. It mainly
> > > consists of two part:
> > > usbctrl_add/remove/list and usb_add/remove/list in which usbctrl deno=
te
> > usb
> > > controller in which
> > > usd device can be plugged in. I don't use "ao_dev" in
> > > libxl_deivce_usbctrl_add since we don't need to
> > > execute hotplug script for usbctrl and without "ao_dev", adding defau=
lt
> > > usbctrl for usb device
> > > would be easier.
> > >
> > > For the cammands to manipulate usb device such as "xl usb-attach" and=
 "xl
> > > usb-detach", this patch now only
> > > support to specify usb devices by their interface in sysfs. Using this
> > > interface, we can read usb device
> > > information through sysfs and bind/unbind usb device. (The support for
> > > mapping the "lsusb" bus:addr to the
> > > sysfs usb interface will come later).
> > >
> > > =3D=3D What needs to do next ? =3D=3D
> > > There are two main problems to be solved.
> > >
> > > 1.  PVUSB Options in VM Guest's Configuration File
> > >     The interface in VM Guest's configuration file to add usb device =
is:
> > > "usb=3D[interface=3D"1-1"]".
> > > But the problem is now is that after the default usbctrl is added, the
> > state
> > > of usbctrl is "2", e,g, "XenbusStateInitWait",
> > > waiting for xen-usbfront to connect. The xen-usbfront in VM Guest isn=
't
> > > loaded. Therefore, "sysfs_intf_write"
> > > will report error. Does anyone have any clue how to solve this?
> > >
> > > 2. sysfs_intf_write
> > >     In the process of "xl usb-attach domid intf=3D1-1", after writing
> > "1-1" to
> > > Xenstore entry, we need to
> > > bind the controller of this usb device to usbback driver so that it c=
an
> > be
> > > used by VM Guest. For exampele,
> > > for usb device "1-1", it's controller interface maybe "1-1:1.0", and =
we
> > > write this value to "/sys/bus/usb/driver/usbback/bind".
> > > But for some devices, they have two controllers, for example "1-1:1.0"
> > and
> > > "1-1:1.1". I think this means it has two functions,
> > > such as usbhid and usb-storage. So in this case, we bind the two
> > controller
> > > to usbback?
> > >
> > > =3D=3D=3D=3D=3D=3D=3D=3D
> > > There maybe some errors or bugs in the codes. Feel free to tell me.
> > >
> > > Cheers,
> > >
> > > - Simon
> > >
> > > ---
> > > CC: George Dunlap <george.dunlap@eu.citrix.com>
> > > CC: Ian Jackson <ian.jackson@citrix.com>
> > > CC: Ian Campbell <ian.campbell@citrix.com>
> > > CC: Pasi K=E4rkk=E4inen <pasik@iki.fi>
> > > CC: Lars Kurth <lars.kurth@citrix.com>
> > >
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > >
> >
> >

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 21:32:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 21: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 1XrCrh-0006sl-Aw; Wed, 19 Nov 2014 21:32:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrCrf-0006sf-AZ
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 21:32:39 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	F0/19-29352-67C0D645; Wed, 19 Nov 2014 21:32:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416432756!12310934!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13969 invoked from network); 19 Nov 2014 21:32:37 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 21:32:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJLWVTG026163
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 21:32:31 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJLWUde013245
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 21:32:30 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJLWS0h022583; Wed, 19 Nov 2014 21:32:29 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 13:32:28 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2C88A1183A6; Wed, 19 Nov 2014 16:32:27 -0500 (EST)
Date: Wed, 19 Nov 2014 16:32:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Simon Cao <caobosimon@gmail.com>
Message-ID: <20141119213226.GA21408@laptop.dumpdata.com>
References: <1407702234-22309-1-git-send-email-caobosimon@gmail.com>
	<5460E9D80200006600078038@soto.provo.novell.com>
	<CAMJpVt8yO8SDpmgFE1XJDNCF1v87Czt+9Li117xZnhsxpCRj_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMJpVt8yO8SDpmgFE1XJDNCF1v87Czt+9Li117xZnhsxpCRj_Q@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Lars Kurth <lars.kurth@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>, Chun Yan Liu <cyliu@suse.com>,
	Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH v0 RFC 0/2] xl/libxl support for PVUSB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Nov 16, 2014 at 10:36:28AM +0800, Simon Cao wrote:
> Hi,
> =

> I was working on the work. But I was busing preparing some job interviews
> in the last three months, sorry for this long delay. I will update my
> progress in a few days.

OK, I put your name for this to be in Xen 4.6.

Thanks!
> =

> Thanks!
> =

> Bo Cao
> =

> On Mon, Nov 10, 2014 at 4:37 PM, Chun Yan Liu <cyliu@suse.com> wrote:
> =

> > Is there any progress on this work? I didn't see new version after this.
> > Anyone knows the status?
> >
> > Thanks,
> > Chunyan
> >
> > >>> On 8/11/2014 at 04:23 AM, in message
> > <1407702234-22309-1-git-send-email-caobosimon@gmail.com>, Bo Cao
> > <caobosimon@gmail.com> wrote:
> > > Finally I have a workable version xl/libxl support for PVUSB. Most of
> > > its commands work property now, but there are still some probelm to be
> > > solved.
> > > Please take a loot and give me some advices.
> > >
> > > =3D=3D What have been implemented ? =3D=3D
> > > I have implemented libxl functions for PVUSB in libxl_usb.c. It mainly
> > > consists of two part:
> > > usbctrl_add/remove/list and usb_add/remove/list in which usbctrl deno=
te
> > usb
> > > controller in which
> > > usd device can be plugged in. I don't use "ao_dev" in
> > > libxl_deivce_usbctrl_add since we don't need to
> > > execute hotplug script for usbctrl and without "ao_dev", adding defau=
lt
> > > usbctrl for usb device
> > > would be easier.
> > >
> > > For the cammands to manipulate usb device such as "xl usb-attach" and=
 "xl
> > > usb-detach", this patch now only
> > > support to specify usb devices by their interface in sysfs. Using this
> > > interface, we can read usb device
> > > information through sysfs and bind/unbind usb device. (The support for
> > > mapping the "lsusb" bus:addr to the
> > > sysfs usb interface will come later).
> > >
> > > =3D=3D What needs to do next ? =3D=3D
> > > There are two main problems to be solved.
> > >
> > > 1.  PVUSB Options in VM Guest's Configuration File
> > >     The interface in VM Guest's configuration file to add usb device =
is:
> > > "usb=3D[interface=3D"1-1"]".
> > > But the problem is now is that after the default usbctrl is added, the
> > state
> > > of usbctrl is "2", e,g, "XenbusStateInitWait",
> > > waiting for xen-usbfront to connect. The xen-usbfront in VM Guest isn=
't
> > > loaded. Therefore, "sysfs_intf_write"
> > > will report error. Does anyone have any clue how to solve this?
> > >
> > > 2. sysfs_intf_write
> > >     In the process of "xl usb-attach domid intf=3D1-1", after writing
> > "1-1" to
> > > Xenstore entry, we need to
> > > bind the controller of this usb device to usbback driver so that it c=
an
> > be
> > > used by VM Guest. For exampele,
> > > for usb device "1-1", it's controller interface maybe "1-1:1.0", and =
we
> > > write this value to "/sys/bus/usb/driver/usbback/bind".
> > > But for some devices, they have two controllers, for example "1-1:1.0"
> > and
> > > "1-1:1.1". I think this means it has two functions,
> > > such as usbhid and usb-storage. So in this case, we bind the two
> > controller
> > > to usbback?
> > >
> > > =3D=3D=3D=3D=3D=3D=3D=3D
> > > There maybe some errors or bugs in the codes. Feel free to tell me.
> > >
> > > Cheers,
> > >
> > > - Simon
> > >
> > > ---
> > > CC: George Dunlap <george.dunlap@eu.citrix.com>
> > > CC: Ian Jackson <ian.jackson@citrix.com>
> > > CC: Ian Campbell <ian.campbell@citrix.com>
> > > CC: Pasi K=E4rkk=E4inen <pasik@iki.fi>
> > > CC: Lars Kurth <lars.kurth@citrix.com>
> > >
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > >
> >
> >

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 22:16:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 22:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrDY1-0007fg-6I; Wed, 19 Nov 2014 22:16:25 +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 1XrDY0-0007fb-5o
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 22:16:24 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	70/9D-29352-7B61D645; Wed, 19 Nov 2014 22:16:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416435381!12314734!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29188 invoked from network); 19 Nov 2014 22:16:22 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 22:16:22 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJMGEW0013466
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 22:16:16 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMGCWn017595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 22:16:13 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMGCjY017554; Wed, 19 Nov 2014 22:16:12 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 14:16:11 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C750E1183EE; Wed, 19 Nov 2014 17:16:10 -0500 (EST)
Date: Wed, 19 Nov 2014 17:16:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xensource.com, 
	jbeulich@suse.com, andrew.cooper3@citrix.com
Message-ID: <20141119221610.GA22156@laptop.dumpdata.com>
References: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
	<118231163.20141119195439@eikelenboom.it>
	<20141119190131.GA15580@laptop.dumpdata.com>
	<1173563549.20141119201735@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1173563549.20141119201735@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: Re: [Xen-devel] [PATCH v1 for-xen-4.5] Fix list corruption in
	dpci_softirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 08:17:35PM +0100, Sander Eikelenboom wrote:
> 
> Wednesday, November 19, 2014, 8:01:31 PM, you wrote:
> 
> > On Wed, Nov 19, 2014 at 07:54:39PM +0100, Sander Eikelenboom wrote:
> >> 
> >> Wednesday, November 19, 2014, 6:31:39 PM, you wrote:
> >> 
> >> > Hey,
> >> 
> >> > This patch should fix the issue that Sander had seen. The full details
> >> > are in the patch itself. Sander, if you could - please test origin/staging
> >> > with this patch to make sure it does fix the issue.
> >> 
> >> 
> >> >  xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------
> >> 
> >> > Konrad Rzeszutek Wilk (1):
> >> >       dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked.
> >> 
> >> >  1 file changed, 17 insertions(+), 10 deletions(-)
> >> 
> >> 
> >> Hi Konrad,
> >> 
> >> Hmm just tested with a freshly cloned tree .. unfortunately it blew up again.
> >> (i must admit i also re-enabled stuff i had disabled in debugging like, cpuidle, cpufreq). 
> 
> > Argh.
> 
> > Could you also try the first patch the STATE_ZOMBIE one?
> 
> Building now ..

(Attached and inline)

Sander mentioned to me over IRC that with the STATE_ZOMBIE patch things work peachy for him.

The patch in combination with the previous adds two extra paths:

1) in raise_softirq, we do delay scheduling of dcpi_pirq until STATE_ZOMBIE is cleared.
2) dpci_softirq will pick up the cancelled dpci_pirq and then clear the STATE_ZOMBIE.

Lets follow the case without the zombie patch and with the zombie patch:

w/o zombie:

timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to 0.
        pirq_dpci is still on dpci_list.
dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.
dpci_softirq
	while (!list_emtpry)
		list_del, but ->next already has LIST_POISON1 and we blow up.


w/ zombie:
timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to STATE_ZOMBIE.
        pirq_dpci is still on dpci_list.
dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state, it is STATE_ZOMBIE so returns.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.

So it seems that the STATE_ZOMBIE is needed, but for a different reason that
Jan initially thought of:


>From c89a97f695fda245f5fcb16ddb36d3df7f6f28b9 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 12:15:26 -0500
Subject: [PATCH] dpci: Add ZOMBIE state to allow the softirq to finish with
 the dpci_pirq.

When we want to cancel an outstanding 'struct hvm_pirq_dpci' we perform
and cmpxch on the state to set it to zero. That is OK on the teardown
paths as it is guarnateed that the do_IRQ action handler has been removed.
Hence no more interrupts can be scheduled. But with the introduction
of "dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked."
we now utilize the pt_pirq_softirq_cancel when we want to cancel
outstanding operations. However once we cancel them the do_IRQ is
free to schedule them back in - even if said 'struct hvm_pirq_dpci'
is still on the dpci_list.

The code base before this patch could follow this race:

\-timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to 0.
        pirq_dpci is still on dpci_list.
\- dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.

\- dpci_softirq
	while (!list_emtpry)
		list_del, but ->next already has LIST_POISON1 and we blow up.

This patch in combination adds two extra paths:

1) in raise_softirq, we do delay scheduling of dcpi_pirq until STATE_ZOMBIE is cleared.
2) dpci_softirq will pick up the cancelled dpci_pirq and then clear the STATE_ZOMBIE.

Using the example above the code-paths would be now:
\- timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to STATE_ZOMBIE.
        pirq_dpci is still on dpci_list.
\- dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state, it is STATE_ZOMBIE so returns.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Conflicts:
	xen/drivers/passthrough/io.c
---
 xen/drivers/passthrough/io.c | 28 ++++++++++++++++++++++------
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 2039d31..1a26973 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -50,20 +50,26 @@ static DEFINE_PER_CPU(struct list_head, dpci_list);
 
 enum {
     STATE_SCHED,
-    STATE_RUN
+    STATE_RUN,
+    STATE_ZOMBIE
 };
 
 /*
  * This can be called multiple times, but the softirq is only raised once.
- * That is until the STATE_SCHED state has been cleared. The state can be
- * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
+ * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
+ * STATE_SCHED and STATE_ZOMBIE state can be cleared by the 'dpci_softirq'
  * or by 'pt_pirq_softirq_cancel' (which will try to clear the state before
- * the softirq had a chance to run).
+ * (when it has executed 'hvm_dirq_assist'). The STATE_SCHED can be cleared
+ * by 'pt_pirq_softirq_cancel' (which will try to clear the state before the
+ * softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
 
+    if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+        return;
+
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
@@ -85,7 +91,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
  */
 bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 {
-    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
         return 1;
 
     /*
@@ -111,7 +117,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
 
     ASSERT(spin_is_locked(&d->event_lock));
 
-    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
         /*
@@ -122,6 +128,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
         /* fallthrough. */
     case (1 << STATE_RUN):
     case (1 << STATE_RUN) | (1 << STATE_SCHED):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
         /*
          * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
@@ -786,6 +793,7 @@ unlock:
 static void dpci_softirq(void)
 {
     unsigned int cpu = smp_processor_id();
+    unsigned int reset = 0;
     LIST_HEAD(our_list);
 
     local_irq_disable();
@@ -812,7 +820,15 @@ static void dpci_softirq(void)
             hvm_dirq_assist(d, pirq_dpci);
             put_domain(d);
         }
+        else
+            reset = 1;
+
         clear_bit(STATE_RUN, &pirq_dpci->state);
+        if ( reset )
+        {
+            clear_bit(STATE_ZOMBIE, &pirq_dpci->state);
+            reset = 0;
+        }
     }
 }
 
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 22:16:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 22:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrDY1-0007fg-6I; Wed, 19 Nov 2014 22:16:25 +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 1XrDY0-0007fb-5o
	for xen-devel@lists.xensource.com; Wed, 19 Nov 2014 22:16:24 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	70/9D-29352-7B61D645; Wed, 19 Nov 2014 22:16:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416435381!12314734!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29188 invoked from network); 19 Nov 2014 22:16:22 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 22:16:22 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJMGEW0013466
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 22:16:16 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMGCWn017595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 22:16:13 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMGCjY017554; Wed, 19 Nov 2014 22:16:12 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 14:16:11 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C750E1183EE; Wed, 19 Nov 2014 17:16:10 -0500 (EST)
Date: Wed, 19 Nov 2014 17:16:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xensource.com, 
	jbeulich@suse.com, andrew.cooper3@citrix.com
Message-ID: <20141119221610.GA22156@laptop.dumpdata.com>
References: <1416418300-15778-1-git-send-email-konrad.wilk@oracle.com>
	<118231163.20141119195439@eikelenboom.it>
	<20141119190131.GA15580@laptop.dumpdata.com>
	<1173563549.20141119201735@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1173563549.20141119201735@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: Re: [Xen-devel] [PATCH v1 for-xen-4.5] Fix list corruption in
	dpci_softirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 19, 2014 at 08:17:35PM +0100, Sander Eikelenboom wrote:
> 
> Wednesday, November 19, 2014, 8:01:31 PM, you wrote:
> 
> > On Wed, Nov 19, 2014 at 07:54:39PM +0100, Sander Eikelenboom wrote:
> >> 
> >> Wednesday, November 19, 2014, 6:31:39 PM, you wrote:
> >> 
> >> > Hey,
> >> 
> >> > This patch should fix the issue that Sander had seen. The full details
> >> > are in the patch itself. Sander, if you could - please test origin/staging
> >> > with this patch to make sure it does fix the issue.
> >> 
> >> 
> >> >  xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------
> >> 
> >> > Konrad Rzeszutek Wilk (1):
> >> >       dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked.
> >> 
> >> >  1 file changed, 17 insertions(+), 10 deletions(-)
> >> 
> >> 
> >> Hi Konrad,
> >> 
> >> Hmm just tested with a freshly cloned tree .. unfortunately it blew up again.
> >> (i must admit i also re-enabled stuff i had disabled in debugging like, cpuidle, cpufreq). 
> 
> > Argh.
> 
> > Could you also try the first patch the STATE_ZOMBIE one?
> 
> Building now ..

(Attached and inline)

Sander mentioned to me over IRC that with the STATE_ZOMBIE patch things work peachy for him.

The patch in combination with the previous adds two extra paths:

1) in raise_softirq, we do delay scheduling of dcpi_pirq until STATE_ZOMBIE is cleared.
2) dpci_softirq will pick up the cancelled dpci_pirq and then clear the STATE_ZOMBIE.

Lets follow the case without the zombie patch and with the zombie patch:

w/o zombie:

timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to 0.
        pirq_dpci is still on dpci_list.
dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.
dpci_softirq
	while (!list_emtpry)
		list_del, but ->next already has LIST_POISON1 and we blow up.


w/ zombie:
timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to STATE_ZOMBIE.
        pirq_dpci is still on dpci_list.
dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state, it is STATE_ZOMBIE so returns.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.

So it seems that the STATE_ZOMBIE is needed, but for a different reason that
Jan initially thought of:


>From c89a97f695fda245f5fcb16ddb36d3df7f6f28b9 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 14 Nov 2014 12:15:26 -0500
Subject: [PATCH] dpci: Add ZOMBIE state to allow the softirq to finish with
 the dpci_pirq.

When we want to cancel an outstanding 'struct hvm_pirq_dpci' we perform
and cmpxch on the state to set it to zero. That is OK on the teardown
paths as it is guarnateed that the do_IRQ action handler has been removed.
Hence no more interrupts can be scheduled. But with the introduction
of "dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked."
we now utilize the pt_pirq_softirq_cancel when we want to cancel
outstanding operations. However once we cancel them the do_IRQ is
free to schedule them back in - even if said 'struct hvm_pirq_dpci'
is still on the dpci_list.

The code base before this patch could follow this race:

\-timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to 0.
        pirq_dpci is still on dpci_list.
\- dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.

\- dpci_softirq
	while (!list_emtpry)
		list_del, but ->next already has LIST_POISON1 and we blow up.

This patch in combination adds two extra paths:

1) in raise_softirq, we do delay scheduling of dcpi_pirq until STATE_ZOMBIE is cleared.
2) dpci_softirq will pick up the cancelled dpci_pirq and then clear the STATE_ZOMBIE.

Using the example above the code-paths would be now:
\- timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to STATE_ZOMBIE.
        pirq_dpci is still on dpci_list.
\- dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state, it is STATE_ZOMBIE so returns.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Conflicts:
	xen/drivers/passthrough/io.c
---
 xen/drivers/passthrough/io.c | 28 ++++++++++++++++++++++------
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 2039d31..1a26973 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -50,20 +50,26 @@ static DEFINE_PER_CPU(struct list_head, dpci_list);
 
 enum {
     STATE_SCHED,
-    STATE_RUN
+    STATE_RUN,
+    STATE_ZOMBIE
 };
 
 /*
  * This can be called multiple times, but the softirq is only raised once.
- * That is until the STATE_SCHED state has been cleared. The state can be
- * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
+ * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
+ * STATE_SCHED and STATE_ZOMBIE state can be cleared by the 'dpci_softirq'
  * or by 'pt_pirq_softirq_cancel' (which will try to clear the state before
- * the softirq had a chance to run).
+ * (when it has executed 'hvm_dirq_assist'). The STATE_SCHED can be cleared
+ * by 'pt_pirq_softirq_cancel' (which will try to clear the state before the
+ * softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
 
+    if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+        return;
+
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
@@ -85,7 +91,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
  */
 bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 {
-    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
         return 1;
 
     /*
@@ -111,7 +117,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
 
     ASSERT(spin_is_locked(&d->event_lock));
 
-    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
         /*
@@ -122,6 +128,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
         /* fallthrough. */
     case (1 << STATE_RUN):
     case (1 << STATE_RUN) | (1 << STATE_SCHED):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
         /*
          * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
@@ -786,6 +793,7 @@ unlock:
 static void dpci_softirq(void)
 {
     unsigned int cpu = smp_processor_id();
+    unsigned int reset = 0;
     LIST_HEAD(our_list);
 
     local_irq_disable();
@@ -812,7 +820,15 @@ static void dpci_softirq(void)
             hvm_dirq_assist(d, pirq_dpci);
             put_domain(d);
         }
+        else
+            reset = 1;
+
         clear_bit(STATE_RUN, &pirq_dpci->state);
+        if ( reset )
+        {
+            clear_bit(STATE_ZOMBIE, &pirq_dpci->state);
+            reset = 0;
+        }
     }
 }
 
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 22:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 22:21:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrDdF-0007ok-QG; Wed, 19 Nov 2014 22:21:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrDdD-0007np-KN
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 22:21:47 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	38/7C-28865-AF71D645; Wed, 19 Nov 2014 22:21:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416435705!12326713!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9562 invoked from network); 19 Nov 2014 22:21:46 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 22:21:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJMLdKg009628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 22:21:40 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMLdvH019603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 22:21:39 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMLdmu006238; Wed, 19 Nov 2014 22:21:39 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 14:21:38 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C20271183F8; Wed, 19 Nov 2014 17:21:37 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux@eikelenboom.it, jbeulich@suse.com,
	andrew.cooper3@citrix.com
Date: Wed, 19 Nov 2014 17:21:35 -0500
Message-Id: <1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state to
	allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When we want to cancel an outstanding 'struct hvm_pirq_dpci' we perform
and cmpxch on the state to set it to zero. That is OK on the teardown
paths as it is guarnateed that the do_IRQ action handler has been removed.
Hence no more interrupts can be scheduled. But with the introduction
of "dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked."
we now utilize the pt_pirq_softirq_cancel when we want to cancel
outstanding operations. However once we cancel them the do_IRQ is
free to schedule them back in - even if said 'struct hvm_pirq_dpci'
is still on the dpci_list.

The code base before this patch could follow this race:

\-timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to 0.
        pirq_dpci is still on dpci_list.
\- dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.

\- dpci_softirq
	while (!list_emtpry)
		list_del, but ->next already has LIST_POISON1 and we blow up.

This patch in combination adds two extra paths:

1) in raise_softirq, we do delay scheduling of dcpi_pirq until STATE_ZOMBIE is cleared.
2) dpci_softirq will pick up the cancelled dpci_pirq and then clear the STATE_ZOMBIE.

Using the example above the code-paths would be now:
\- timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to STATE_ZOMBIE.
        pirq_dpci is still on dpci_list.
\- dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state, it is STATE_ZOMBIE so returns.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.

Reported-and-Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 28 ++++++++++++++++++++++------
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 2039d31..1a26973 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -50,20 +50,26 @@ static DEFINE_PER_CPU(struct list_head, dpci_list);
 
 enum {
     STATE_SCHED,
-    STATE_RUN
+    STATE_RUN,
+    STATE_ZOMBIE
 };
 
 /*
  * This can be called multiple times, but the softirq is only raised once.
- * That is until the STATE_SCHED state has been cleared. The state can be
- * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
+ * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
+ * STATE_SCHED and STATE_ZOMBIE state can be cleared by the 'dpci_softirq'
  * or by 'pt_pirq_softirq_cancel' (which will try to clear the state before
- * the softirq had a chance to run).
+ * (when it has executed 'hvm_dirq_assist'). The STATE_SCHED can be cleared
+ * by 'pt_pirq_softirq_cancel' (which will try to clear the state before the
+ * softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
 
+    if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+        return;
+
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
@@ -85,7 +91,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
  */
 bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 {
-    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
         return 1;
 
     /*
@@ -111,7 +117,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
 
     ASSERT(spin_is_locked(&d->event_lock));
 
-    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
         /*
@@ -122,6 +128,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
         /* fallthrough. */
     case (1 << STATE_RUN):
     case (1 << STATE_RUN) | (1 << STATE_SCHED):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
         /*
          * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
@@ -786,6 +793,7 @@ unlock:
 static void dpci_softirq(void)
 {
     unsigned int cpu = smp_processor_id();
+    unsigned int reset = 0;
     LIST_HEAD(our_list);
 
     local_irq_disable();
@@ -812,7 +820,15 @@ static void dpci_softirq(void)
             hvm_dirq_assist(d, pirq_dpci);
             put_domain(d);
         }
+        else
+            reset = 1;
+
         clear_bit(STATE_RUN, &pirq_dpci->state);
+        if ( reset )
+        {
+            clear_bit(STATE_ZOMBIE, &pirq_dpci->state);
+            reset = 0;
+        }
     }
 }
 
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 22:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 22:21:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrDdE-0007o9-AE; Wed, 19 Nov 2014 22:21: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 1XrDdD-0007no-9i
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 22:21:47 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	43/33-31453-AF71D645; Wed, 19 Nov 2014 22:21:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416435704!12330013!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15598 invoked from network); 19 Nov 2014 22:21:46 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 22:21:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJMLfTl019571
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 22:21:42 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMLe6a006343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 22:21:41 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJMLdfn007676; Wed, 19 Nov 2014 22:21:40 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 14:21:39 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 938E41183F5; Wed, 19 Nov 2014 17:21:37 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux@eikelenboom.it, jbeulich@suse.com,
	andrew.cooper3@citrix.com
Date: Wed, 19 Nov 2014 17:21:33 -0500
Message-Id: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [for xen-4.5 PATCH v2] Fix list corruption in
	dpci_softirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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,

Attached are two patches that fix the dpci_softirq list corruption
that Sander was observing.


 xen/drivers/passthrough/io.c | 55 +++++++++++++++++++++++++++++++-------------
 1 file changed, 39 insertions(+), 16 deletions(-)

Konrad Rzeszutek Wilk (2):
      dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked.
      dpci: Add ZOMBIE state to allow the softirq to finish with the dpci_pirq.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 22:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 22:21:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrDdD-0007o2-Ui; Wed, 19 Nov 2014 22:21:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrDdD-0007nn-5M
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 22:21:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7E/B0-09842-AF71D645; Wed, 19 Nov 2014 22:21:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416435704!13660769!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23816 invoked from network); 19 Nov 2014 22:21:45 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 22:21:45 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJMLeXW019546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 22:21:41 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMLd1g006284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 22:21:40 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMLdhw006270; Wed, 19 Nov 2014 22:21:39 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 14:21:39 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AE55C1183F7; Wed, 19 Nov 2014 17:21:37 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux@eikelenboom.it, jbeulich@suse.com,
	andrew.cooper3@citrix.com
Date: Wed, 19 Nov 2014 17:21:34 -0500
Message-Id: <1416435695-23784-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [for-xen-4.5 PATCH v2 1/2] dpci: Fix list corruption if
	INTx device is used and an IRQ timeout is invoked.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 we pass in INTx type devices to a guest on an over-subscribed
machine - and in an over-worked guest - we can cause the
pirq_dpci->softirq_list to become corrupted.

The reason for this is that the 'pt_irq_guest_eoi' ends up
setting the 'state' to zero value. However the 'state' value
(STATE_SCHED, STATE_RUN) is used to communicate between
 'raise_softirq_for' and 'dpci_softirq' to determine whether the
'struct hvm_pirq_dpci' can be re-scheduled. We are ignoring the
teardown path for simplicity for right now. The 'pt_irq_guest_eoi' was
not adhering to the proper dialogue and was not using locked cmpxchg or
test_bit operations and ended setting 'state' set to zero. That
meant 'raise_softirq_for' was free to schedule it while the
'struct hvm_pirq_dpci'' was still on an per-cpu list.
The end result was list_del being called twice and the second call
corrupting the per-cpu list.

For this to occur one of the CPUs must be in the idle loop executing
softirqs and the interrupt handler in the guest must not
respond to the pending interrupt within 8ms, and we must receive
another interrupt for this device on another CPU.

CPU0:                                  CPU1:

timer_softirq_action
 \- pt_irq_time_out
     state = 0;                        do_IRQ
 [out of timer code, the                raise_softirq
 pirq_dpci is on the CPU0 dpci_list]      [adds the pirq_dpci to CPU1
                                           dpci_list as state == 0]

softirq_dpci:                            softirq_dpci:
        list_del
        [list entries are poisoned]
                                                list_del <= BOOM

The fix is simple - enroll 'pt_irq_guest_eoi' to use the locked
semantics for 'state'. We piggyback on pt_pirq_softirq_cancel (was
pt_pirq_softirq_reset) to use cmpxchg. We also expand said function
to reset the '->dom' only on the teardown paths - but not on the
timeouts.

Reported-and-Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..2039d31 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -57,7 +57,7 @@ enum {
  * This can be called multiple times, but the softirq is only raised once.
  * That is until the STATE_SCHED state has been cleared. The state can be
  * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
- * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
+ * or by 'pt_pirq_softirq_cancel' (which will try to clear the state before
  * the softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
@@ -97,13 +97,15 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 }
 
 /*
- * Reset the pirq_dpci->dom parameter to NULL.
+ * Cancels an outstanding pirq_dpci (if scheduled). Also if clear is set,
+ * reset pirq_dpci->dom parameter to NULL (used for teardown).
  *
  * This function checks the different states to make sure it can do it
  * at the right time. If it unschedules the 'hvm_dirq_assist' from running
  * it also refcounts (which is what the softirq would have done) properly.
  */
-static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
+                                   unsigned int clear)
 {
     struct domain *d = pirq_dpci->dom;
 
@@ -125,8 +127,13 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
          * in local variable before it sets STATE_RUN - and therefore will not
          * dereference '->dom' which would crash.
+         *
+         * However, if this is called from 'pt_irq_time_out' we do not want to
+         * clear the '->dom' as we can re-use the 'pirq_dpci' after that and
+         * need '->dom'.
          */
-        pirq_dpci->dom = NULL;
+        if ( clear )
+            pirq_dpci->dom = NULL;
         break;
     }
 }
@@ -142,7 +149,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pt_pirq_softirq_cancel(pirq_dpci, 0 /* keep dom */);
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -285,7 +292,7 @@ int pt_irq_create_bind(
                      * to be scheduled but we must deal with the one that may be
                      * in the queue.
                      */
-                    pt_pirq_softirq_reset(pirq_dpci);
+                    pt_pirq_softirq_cancel(pirq_dpci, 1 /* reset dom */);
                 }
             }
             if ( unlikely(rc) )
@@ -536,9 +543,9 @@ int pt_irq_destroy_bind(
         pirq_dpci->flags = 0;
         /*
          * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
-         * call to pt_pirq_softirq_reset.
+         * call to pt_pirq_softirq_cancel.
          */
-        pt_pirq_softirq_reset(pirq_dpci);
+        pt_pirq_softirq_cancel(pirq_dpci, 1 /* reset dom */);
 
         pirq_cleanup_check(pirq, d);
     }
@@ -773,8 +780,8 @@ unlock:
 }
 
 /*
- * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
- * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
+ * Note: 'pt_pirq_softirq_cancel' can clear the STATE_SCHED before we get to
+ * doing it. If that is the case we let 'pt_pirq_softirq_cancel' do ref-counting.
  */
 static void dpci_softirq(void)
 {
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 22:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 22:21:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrDdE-0007o9-AE; Wed, 19 Nov 2014 22:21: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 1XrDdD-0007no-9i
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 22:21:47 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	43/33-31453-AF71D645; Wed, 19 Nov 2014 22:21:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416435704!12330013!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15598 invoked from network); 19 Nov 2014 22:21:46 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 22:21:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJMLfTl019571
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 22:21:42 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMLe6a006343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Nov 2014 22:21:41 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAJMLdfn007676; Wed, 19 Nov 2014 22:21:40 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 14:21:39 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 938E41183F5; Wed, 19 Nov 2014 17:21:37 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux@eikelenboom.it, jbeulich@suse.com,
	andrew.cooper3@citrix.com
Date: Wed, 19 Nov 2014 17:21:33 -0500
Message-Id: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [for xen-4.5 PATCH v2] Fix list corruption in
	dpci_softirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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,

Attached are two patches that fix the dpci_softirq list corruption
that Sander was observing.


 xen/drivers/passthrough/io.c | 55 +++++++++++++++++++++++++++++++-------------
 1 file changed, 39 insertions(+), 16 deletions(-)

Konrad Rzeszutek Wilk (2):
      dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked.
      dpci: Add ZOMBIE state to allow the softirq to finish with the dpci_pirq.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 22:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 22:21:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrDdF-0007ok-QG; Wed, 19 Nov 2014 22:21:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrDdD-0007np-KN
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 22:21:47 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	38/7C-28865-AF71D645; Wed, 19 Nov 2014 22:21:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416435705!12326713!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9562 invoked from network); 19 Nov 2014 22:21:46 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 22:21:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJMLdKg009628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 22:21:40 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMLdvH019603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 22:21:39 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMLdmu006238; Wed, 19 Nov 2014 22:21:39 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 14:21:38 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C20271183F8; Wed, 19 Nov 2014 17:21:37 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux@eikelenboom.it, jbeulich@suse.com,
	andrew.cooper3@citrix.com
Date: Wed, 19 Nov 2014 17:21:35 -0500
Message-Id: <1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state to
	allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When we want to cancel an outstanding 'struct hvm_pirq_dpci' we perform
and cmpxch on the state to set it to zero. That is OK on the teardown
paths as it is guarnateed that the do_IRQ action handler has been removed.
Hence no more interrupts can be scheduled. But with the introduction
of "dpci: Fix list corruption if INTx device is used and an IRQ timeout is invoked."
we now utilize the pt_pirq_softirq_cancel when we want to cancel
outstanding operations. However once we cancel them the do_IRQ is
free to schedule them back in - even if said 'struct hvm_pirq_dpci'
is still on the dpci_list.

The code base before this patch could follow this race:

\-timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to 0.
        pirq_dpci is still on dpci_list.
\- dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.

\- dpci_softirq
	while (!list_emtpry)
		list_del, but ->next already has LIST_POISON1 and we blow up.

This patch in combination adds two extra paths:

1) in raise_softirq, we do delay scheduling of dcpi_pirq until STATE_ZOMBIE is cleared.
2) dpci_softirq will pick up the cancelled dpci_pirq and then clear the STATE_ZOMBIE.

Using the example above the code-paths would be now:
\- timer_softirq_action
	pt_irq_time_out calls pt_pirq_softirq_cancel which cmpxchg the state to STATE_ZOMBIE.
        pirq_dpci is still on dpci_list.
\- dpci_sofitrq
	while (!list_emptry(&our_list))
		list_del, but has not yet done 'entry->next = LIST_POISON1;'
[interrupt happens]
	raise_softirq checks state, it is STATE_ZOMBIE so returns.
[interrupt is done, back to dpci_softirq]
	finishes the entry->next = LIST_POISON1;
		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
	ends the loop, exits.

Reported-and-Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 28 ++++++++++++++++++++++------
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 2039d31..1a26973 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -50,20 +50,26 @@ static DEFINE_PER_CPU(struct list_head, dpci_list);
 
 enum {
     STATE_SCHED,
-    STATE_RUN
+    STATE_RUN,
+    STATE_ZOMBIE
 };
 
 /*
  * This can be called multiple times, but the softirq is only raised once.
- * That is until the STATE_SCHED state has been cleared. The state can be
- * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
+ * That is until the STATE_SCHED and STATE_ZOMBIE state has been cleared. The
+ * STATE_SCHED and STATE_ZOMBIE state can be cleared by the 'dpci_softirq'
  * or by 'pt_pirq_softirq_cancel' (which will try to clear the state before
- * the softirq had a chance to run).
+ * (when it has executed 'hvm_dirq_assist'). The STATE_SCHED can be cleared
+ * by 'pt_pirq_softirq_cancel' (which will try to clear the state before the
+ * softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
 {
     unsigned long flags;
 
+    if ( test_bit(STATE_ZOMBIE, &pirq_dpci->state) )
+        return;
+
     if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
         return;
 
@@ -85,7 +91,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
  */
 bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 {
-    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
+    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
         return 1;
 
     /*
@@ -111,7 +117,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
 
     ASSERT(spin_is_locked(&d->event_lock));
 
-    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
+    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 1 << STATE_ZOMBIE ) )
     {
     case (1 << STATE_SCHED):
         /*
@@ -122,6 +128,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
         /* fallthrough. */
     case (1 << STATE_RUN):
     case (1 << STATE_RUN) | (1 << STATE_SCHED):
+    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
         /*
          * The reason it is OK to reset 'dom' when STATE_RUN bit is set is due
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
@@ -786,6 +793,7 @@ unlock:
 static void dpci_softirq(void)
 {
     unsigned int cpu = smp_processor_id();
+    unsigned int reset = 0;
     LIST_HEAD(our_list);
 
     local_irq_disable();
@@ -812,7 +820,15 @@ static void dpci_softirq(void)
             hvm_dirq_assist(d, pirq_dpci);
             put_domain(d);
         }
+        else
+            reset = 1;
+
         clear_bit(STATE_RUN, &pirq_dpci->state);
+        if ( reset )
+        {
+            clear_bit(STATE_ZOMBIE, &pirq_dpci->state);
+            reset = 0;
+        }
     }
 }
 
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 19 22:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Nov 2014 22:21:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrDdD-0007o2-Ui; Wed, 19 Nov 2014 22:21:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrDdD-0007nn-5M
	for xen-devel@lists.xenproject.org; Wed, 19 Nov 2014 22:21:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7E/B0-09842-AF71D645; Wed, 19 Nov 2014 22:21:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416435704!13660769!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23816 invoked from network); 19 Nov 2014 22:21:45 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2014 22:21:45 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAJMLeXW019546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Nov 2014 22:21:41 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMLd1g006284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 19 Nov 2014 22:21:40 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAJMLdhw006270; Wed, 19 Nov 2014 22:21:39 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Nov 2014 14:21:39 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AE55C1183F7; Wed, 19 Nov 2014 17:21:37 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux@eikelenboom.it, jbeulich@suse.com,
	andrew.cooper3@citrix.com
Date: Wed, 19 Nov 2014 17:21:34 -0500
Message-Id: <1416435695-23784-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [for-xen-4.5 PATCH v2 1/2] dpci: Fix list corruption if
	INTx device is used and an IRQ timeout is invoked.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 we pass in INTx type devices to a guest on an over-subscribed
machine - and in an over-worked guest - we can cause the
pirq_dpci->softirq_list to become corrupted.

The reason for this is that the 'pt_irq_guest_eoi' ends up
setting the 'state' to zero value. However the 'state' value
(STATE_SCHED, STATE_RUN) is used to communicate between
 'raise_softirq_for' and 'dpci_softirq' to determine whether the
'struct hvm_pirq_dpci' can be re-scheduled. We are ignoring the
teardown path for simplicity for right now. The 'pt_irq_guest_eoi' was
not adhering to the proper dialogue and was not using locked cmpxchg or
test_bit operations and ended setting 'state' set to zero. That
meant 'raise_softirq_for' was free to schedule it while the
'struct hvm_pirq_dpci'' was still on an per-cpu list.
The end result was list_del being called twice and the second call
corrupting the per-cpu list.

For this to occur one of the CPUs must be in the idle loop executing
softirqs and the interrupt handler in the guest must not
respond to the pending interrupt within 8ms, and we must receive
another interrupt for this device on another CPU.

CPU0:                                  CPU1:

timer_softirq_action
 \- pt_irq_time_out
     state = 0;                        do_IRQ
 [out of timer code, the                raise_softirq
 pirq_dpci is on the CPU0 dpci_list]      [adds the pirq_dpci to CPU1
                                           dpci_list as state == 0]

softirq_dpci:                            softirq_dpci:
        list_del
        [list entries are poisoned]
                                                list_del <= BOOM

The fix is simple - enroll 'pt_irq_guest_eoi' to use the locked
semantics for 'state'. We piggyback on pt_pirq_softirq_cancel (was
pt_pirq_softirq_reset) to use cmpxchg. We also expand said function
to reset the '->dom' only on the teardown paths - but not on the
timeouts.

Reported-and-Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..2039d31 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -57,7 +57,7 @@ enum {
  * This can be called multiple times, but the softirq is only raised once.
  * That is until the STATE_SCHED state has been cleared. The state can be
  * cleared by: the 'dpci_softirq' (when it has executed 'hvm_dirq_assist'),
- * or by 'pt_pirq_softirq_reset' (which will try to clear the state before
+ * or by 'pt_pirq_softirq_cancel' (which will try to clear the state before
  * the softirq had a chance to run).
  */
 static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
@@ -97,13 +97,15 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
 }
 
 /*
- * Reset the pirq_dpci->dom parameter to NULL.
+ * Cancels an outstanding pirq_dpci (if scheduled). Also if clear is set,
+ * reset pirq_dpci->dom parameter to NULL (used for teardown).
  *
  * This function checks the different states to make sure it can do it
  * at the right time. If it unschedules the 'hvm_dirq_assist' from running
  * it also refcounts (which is what the softirq would have done) properly.
  */
-static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
+                                   unsigned int clear)
 {
     struct domain *d = pirq_dpci->dom;
 
@@ -125,8 +127,13 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
          * to a shortcut the 'dpci_softirq' implements. It stashes the 'dom'
          * in local variable before it sets STATE_RUN - and therefore will not
          * dereference '->dom' which would crash.
+         *
+         * However, if this is called from 'pt_irq_time_out' we do not want to
+         * clear the '->dom' as we can re-use the 'pirq_dpci' after that and
+         * need '->dom'.
          */
-        pirq_dpci->dom = NULL;
+        if ( clear )
+            pirq_dpci->dom = NULL;
         break;
     }
 }
@@ -142,7 +149,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pt_pirq_softirq_cancel(pirq_dpci, 0 /* keep dom */);
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -285,7 +292,7 @@ int pt_irq_create_bind(
                      * to be scheduled but we must deal with the one that may be
                      * in the queue.
                      */
-                    pt_pirq_softirq_reset(pirq_dpci);
+                    pt_pirq_softirq_cancel(pirq_dpci, 1 /* reset dom */);
                 }
             }
             if ( unlikely(rc) )
@@ -536,9 +543,9 @@ int pt_irq_destroy_bind(
         pirq_dpci->flags = 0;
         /*
          * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the
-         * call to pt_pirq_softirq_reset.
+         * call to pt_pirq_softirq_cancel.
          */
-        pt_pirq_softirq_reset(pirq_dpci);
+        pt_pirq_softirq_cancel(pirq_dpci, 1 /* reset dom */);
 
         pirq_cleanup_check(pirq, d);
     }
@@ -773,8 +780,8 @@ unlock:
 }
 
 /*
- * Note: 'pt_pirq_softirq_reset' can clear the STATE_SCHED before we get to
- * doing it. If that is the case we let 'pt_pirq_softirq_reset' do ref-counting.
+ * Note: 'pt_pirq_softirq_cancel' can clear the STATE_SCHED before we get to
+ * doing it. If that is the case we let 'pt_pirq_softirq_cancel' do ref-counting.
  */
 static void dpci_softirq(void)
 {
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 00:08:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 00:08:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrFHs-0001NG-9N; Thu, 20 Nov 2014 00:07:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux+xen-devel=lists.xensource.com@arm.linux.org.uk>)
	id 1XrFHr-0001NB-13
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 00:07:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	38/4F-09842-6D03D645; Thu, 20 Nov 2014 00:07:50 +0000
X-Env-Sender: linux+xen-devel=lists.xensource.com@arm.linux.org.uk
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416442068!14029488!1
X-Originating-IP: [78.32.30.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5124 invoked from network); 20 Nov 2014 00:07:49 -0000
Received: from pandora.arm.linux.org.uk (HELO pandora.arm.linux.org.uk)
	(78.32.30.218)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 00:07:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=arm.linux.org.uk; s=pandora-2014; 
	h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=BIc1gYMct4rUdQqed5MfCoZyqd6Rdyx1rmSDvuGD+0g=; 
	b=itLSHwm/Kt0ApMDDELNN4JPX9Mt16dnvic+wNO4U/hYq3+yAAreou5Bu8D+RVDQIvPo4MaphBKZmYPnEVdm32y6vAC61BNBPIeCZJXrlnVkz41q9uAc4PEsM3Y08xN5HESWwvBby80fq0iMgcsBtw/alelfAKMJbELacPILNL24=;
Received: from n2100.arm.linux.org.uk
	([2002:4e20:1eda:1:214:fdff:fe10:4f86]:33508)
	by pandora.arm.linux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
	(Exim 4.82_1-5b7a7c0-XX) (envelope-from <linux@arm.linux.org.uk>)
	id 1XrFHg-000498-Mg; Thu, 20 Nov 2014 00:07:40 +0000
Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76)
	(envelope-from <linux@n2100.arm.linux.org.uk>)
	id 1XrFHd-0007mE-9o; Thu, 20 Nov 2014 00:07:37 +0000
Date: Thu, 20 Nov 2014 00:07:36 +0000
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141120000736.GN4042@n2100.arm.linux.org.uk>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411181649000.27247@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411181649000.27247@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 05/13] arm: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 04:49:21PM +0000, Stefano Stabellini wrote:
> ping?

Sending something which wants my attention _To:_ me is always a good idea :)

The patch is fine in itself, but I have a niggle about the
is_device_dma_coherent() - provided this is only used in architecture
specific code, that should be fine.  It could probably do with a comment
to that effect in an attempt to discourage drivers using it (thereby
becoming less portable to other architectures.)

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 00:08:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 00:08:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrFHs-0001NG-9N; Thu, 20 Nov 2014 00:07:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux+xen-devel=lists.xensource.com@arm.linux.org.uk>)
	id 1XrFHr-0001NB-13
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 00:07:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	38/4F-09842-6D03D645; Thu, 20 Nov 2014 00:07:50 +0000
X-Env-Sender: linux+xen-devel=lists.xensource.com@arm.linux.org.uk
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416442068!14029488!1
X-Originating-IP: [78.32.30.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5124 invoked from network); 20 Nov 2014 00:07:49 -0000
Received: from pandora.arm.linux.org.uk (HELO pandora.arm.linux.org.uk)
	(78.32.30.218)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 00:07:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=arm.linux.org.uk; s=pandora-2014; 
	h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=BIc1gYMct4rUdQqed5MfCoZyqd6Rdyx1rmSDvuGD+0g=; 
	b=itLSHwm/Kt0ApMDDELNN4JPX9Mt16dnvic+wNO4U/hYq3+yAAreou5Bu8D+RVDQIvPo4MaphBKZmYPnEVdm32y6vAC61BNBPIeCZJXrlnVkz41q9uAc4PEsM3Y08xN5HESWwvBby80fq0iMgcsBtw/alelfAKMJbELacPILNL24=;
Received: from n2100.arm.linux.org.uk
	([2002:4e20:1eda:1:214:fdff:fe10:4f86]:33508)
	by pandora.arm.linux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
	(Exim 4.82_1-5b7a7c0-XX) (envelope-from <linux@arm.linux.org.uk>)
	id 1XrFHg-000498-Mg; Thu, 20 Nov 2014 00:07:40 +0000
Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76)
	(envelope-from <linux@n2100.arm.linux.org.uk>)
	id 1XrFHd-0007mE-9o; Thu, 20 Nov 2014 00:07:37 +0000
Date: Thu, 20 Nov 2014 00:07:36 +0000
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141120000736.GN4042@n2100.arm.linux.org.uk>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411181649000.27247@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411181649000.27247@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 05/13] arm: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 18, 2014 at 04:49:21PM +0000, Stefano Stabellini wrote:
> ping?

Sending something which wants my attention _To:_ me is always a good idea :)

The patch is fine in itself, but I have a niggle about the
is_device_dma_coherent() - provided this is only used in architecture
specific code, that should be fine.  It could probably do with a comment
to that effect in an attempt to discourage drivers using it (thereby
becoming less portable to other architectures.)

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 00:45:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 00:45:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrFrj-0001nO-Ej; Thu, 20 Nov 2014 00:44: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@citrix.com>) id 1XrFri-0001nJ-3e
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 00:44:54 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	D2/6F-24859-5893D645; Thu, 20 Nov 2014 00:44:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416444291!12595777!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25525 invoked from network); 20 Nov 2014 00:44:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 00:44:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,420,1413244800"; d="scan'208";a="193112211"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 19 Nov 2014 19:44:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrFrd-0005ox-8Q;
	Thu, 20 Nov 2014 00:44:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrFrd-0004O1-1P;
	Thu, 20 Nov 2014 00:44:49 +0000
Date: Thu, 20 Nov 2014 00:44:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31675-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31675: 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 31675 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31675/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl            3 host-install(3)           broken pass in 31657
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 31657
 test-amd64-i386-freebsd10-amd64  3 host-install(3)        broken pass in 31657

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-freebsd10-amd64 host-install(3)

Not pushing.

(No revision log; it would be 30846 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 00:45:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 00:45:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrFrj-0001nO-Ej; Thu, 20 Nov 2014 00:44: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@citrix.com>) id 1XrFri-0001nJ-3e
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 00:44:54 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	D2/6F-24859-5893D645; Thu, 20 Nov 2014 00:44:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416444291!12595777!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25525 invoked from network); 20 Nov 2014 00:44:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 00:44:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,420,1413244800"; d="scan'208";a="193112211"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 19 Nov 2014 19:44:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrFrd-0005ox-8Q;
	Thu, 20 Nov 2014 00:44:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrFrd-0004O1-1P;
	Thu, 20 Nov 2014 00:44:49 +0000
Date: Thu, 20 Nov 2014 00:44:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31675-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31675: 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 31675 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31675/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl            3 host-install(3)           broken pass in 31657
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 31657
 test-amd64-i386-freebsd10-amd64  3 host-install(3)        broken pass in 31657

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-freebsd10-amd64 host-install(3)

Not pushing.

(No revision log; it would be 30846 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 01:24:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 01:24:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrGTN-0006OV-Hu; Thu, 20 Nov 2014 01:23:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XrGTL-0006ON-H5
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 01:23:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F0/B1-09842-2A24D645; Thu, 20 Nov 2014 01:23:46 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416446624!13996915!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21478 invoked from network); 20 Nov 2014 01:23:45 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 01:23:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416446622; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=S44O9K2Cc3N2unaVBtHuwvYcYECXczFdI1Tb91h2zc8=;
	b=OfubclSygEBSMQ9V4RR5EJUdcXvQjxRE3ALy3E/a7nxNl/9A/dXbR2/JjidAjYfZ2FDINzSWMffcj+8Gk4ei+tVG4CTWd51R6kPQfe6PUinlpHwitfc3peHCMoA2ubn33FVoHJOx0tetpNLpCTCJf932+mkfWXis33OxUg0uaiA=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Wed, 19 Nov 2014 17:23:41 -0800
	id 000000000003048A.546D429E.000036BC
Message-ID: <546D429A.5020906@ihonk.com>
Date: Wed, 19 Nov 2014 17:23:38 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, pasik@iki.fi
References: <5457F79B.2020300@ihonk.com>
	<20141104082012.GY12451@reaktio.net>	<5458B55C0200007800044B33@mail.emea.novell.com>	<5460716A.7090905@ihonk.com>	<54608A8B0200007800045E58@mail.emea.novell.com>	<54611A86.4000200@ihonk.com>	<5461D15C02000078000464D7@mail.emea.novell.com>	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
In-Reply-To: <546B094C0200007800048A5C@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/17/2014 23:54, Jan Beulich wrote:
>>>> On 17.11.14 at 20:21, <sflist@ihonk.com> wrote:
>> Okay, I did a bisection and was not able to correlate the above error
>> message with the problem I'm seeing. Not saying it's not related, but I
>> had plenty of successful test runs in the presence of that error.
>>
>> Took me about a week (sometimes it takes as much as 6 hours to produce
>> the error), but bisect narrowed it down to this commit:
>>
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9a727a813e9b25003e433b3d
>> c3fa47e621f9e238
>>
>> What do you think?
> Thanks for narrowing this, even if this change didn't show any other
> bad effects so far (and it's been widely tested by now), and even if
> problems here would generally be expected to surface independent
> of the use of PCI pass-through. But a hang (rather than a crash)
> would indeed be the most natural result of something being wrong
> here. To double check the result, could you, in an up-to-date tree,
> simply make x86's arch_skip_send_event_check() return 0
> unconditionally?

Made this change and the host was happy.

>   Plus, without said adjustment, first just disable the
> MWAIT CPU idle driver ("mwait-idle=0") and then, if that didn't make
> a difference, use of C states altogether ("cpuidle=0"). If any of this
> does make a difference, limiting use of C states without fully
> excluding their use may need to be the next step.

Will do this next.

> Another thing - now that serial logging appears to be working for
> you, did you try whether the host, once hung, still reacts to serial
> input (perhaps force input to go to Xen right at boot via the
> "conswitch=" option)? If so, 'd' debug-key output would likely be
> the piece of most interest.

Here you go. Performed with a checkout of 9a727a81 (because it was 
handy), let me know if you'd rather see the results from 4.5-rc2 or any 
other Xen debugging info:

(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000281e2c1>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 00003acd4939f3e7   rbx: 00003acd493a0cce   rcx: 000000000000ffff
(XEN) rdx: 00003acd00000000   rsi: 0000000000000000   rdi: 0000000000000057
(XEN) rbp: 000000000000645c   rsp: fffff880033edf90   r8: fffff880033edff0
(XEN) r9:  0000000000000000   r10: fffff880033ee040   r11: 0000000342934690
(XEN) r12: fffff880033ee3c8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000066aca000   cr2: fffff98002680000
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a943e000   rcx: 0000000000000001
(XEN) rdx: ffff830c3dc70000   rsi: 0000000000000004   rdi: ffff830c3dc7a088
(XEN) rbp: ffff830c3dc77ec8   rsp: ffff830c3dc77e40   r8: ffff830c3dc7a0a0
(XEN) r9:  0000000000000000   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: 0000151cc8b48756   r13: ffff8300a943e000   r14: ffff830c3dc7a088
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c18962000   cr2: 00000000ff331aa0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc77e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dc7a0a0 0000000100c77e78
(XEN)    ffff830c3dc7a080 ffff82d0801b5277 ffff8300a943e000 fffff88002fe2d70
(XEN)    ffff8300a943e000 0000000001c9c380 ffff82d0801e0f00 ffff830c3dc77f08
(XEN)    ffff82d0802f8080 ffff82d0802f8000 ffffffffffffffff ffff830c3dc70000
(XEN)    0000000000000001 ffff830c3dc77ef8 ffff82d08012a1b3 ffff8300a943e000
(XEN)    fffff88002fe2d70 000036d08fbeebe8 000000000000000f ffff830c3dc77f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 000036d08fbeebe8 fffff88002fe2d70 000000000000000f
(XEN)    fffff88002fd8180 fffff88002fe2d70 fffff88002fd82a0 000034711df61755
(XEN)    fffff88002fd82a0 0000000000000002 fffff88002fd81c0 0000000000000400
(XEN)    0000000000000000 fffff88002fe2eb0 0000beef0000beef fffff8000298520c
(XEN)    000000bf0000beef 0000000000000046 fffff88002fe2c20 000000000000beef
(XEN)    c2c2c2c2c2c2beef c2c2c2c2c2c2beef c2c2c2c2c2c2beef c2c2c2c2c2c2beef
(XEN)    c2c2c2c200000001 ffff8300a943e000 0000003bbd958e00 c2c2c2c2c2c2c2c2
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000298520c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000034711df61755   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 000036d08fbeebe8   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000ff331aa0
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000298520e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  000034edd4ec417c   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 000036d08fe55d56   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000776ebfb8
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d0801d4bb4>] enable_intr_window+0xe4/0xed
(XEN) RFLAGS: 0000000000000202   CONTEXT: hypervisor
(XEN) rax: 00000000b6a065fe   rbx: 000000000000d202   rcx: 0000000000000000
(XEN) rdx: 0000000000000004   rsi: 000000000000d202   rdi: ffff8300a942f000
(XEN) rbp: ffff830c3dca7e98   rsp: ffff830c3dca7e68   r8: ffff8300a942f000
(XEN) r9:  00000000ffffffff   r10: ffff830c3f68d650   r11: fffff80000ba6d30
(XEN) r12: ffff8300a942f000   r13: 000000000000d202   r14: 00000000000000d2
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1b519000   cr2: 0000000004af6354
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7e68:
(XEN)    ffff830c3dca7e98 ffff82d0801bdff8 ffff830c3dca7e98 ffff8300a942f000
(XEN)    ffff8300a942f000 000000000000d202 ffff830c3dca7f08 ffff82d0801d4ea4
(XEN)    ffff82d0802f8000 000000d2ffffffff ffff830c3dca0000 0000000000000001
(XEN)    ffff830c3dca7ef8 ffff82d08012a1b3 ffff8300a942f000 ffff8300a942f000
(XEN)    0000151cdcad2c52 ffff8300a942f000 ffff830c3dcaa088 0000000001c9c380
(XEN)    ffff830c3dca7e28 ffff82d0801e3c86 0000000000000001 000000000000000f
(XEN)    000036d08fbabfb5 fffff80000ba6d30 000000000000000f fffff80002a47e80
(XEN)    fffff80000ba6d30 fffff80002a47fa0 0000362abb330cfb fffff80002a47fa0
(XEN)    0000000000000002 fffff80002a47ec0 0000000000000400 0000000000000000
(XEN)    fffff80000ba6e70 0000beef0000beef fffff8000298520c 000000bf0000beef
(XEN)    0000000000000046 fffff80000ba6be0 000000000000beef 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 0000000000000003
(XEN)    ffff8300a942f000 0000003bbd988e00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801d4bb4>] enable_intr_window+0xe4/0xed
(XEN)    [<ffff82d0801d4ea4>] vmx_intr_assist+0x28c/0x51c
(XEN)    [<ffff82d0801e3c86>] vmx_asm_vmexit_handler+0x46/0xc0
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298520c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a47e80   rcx: fffff80002a47ec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80000ba6e70
(XEN) rbp: 000000000000000f   rsp: fffff80000ba6be0   r8: fffff80002a47fa0
(XEN) r9:  0000362abb330cfb   r10: fffff80002a47fa0   r11: fffff80000ba6d30
(XEN) r12: fffff80000ba6d30   r13: 000036d08fbabfb5   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000004af6354
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff82d080321280   rcx: 0000000000000004
(XEN) rdx: ffff830c3dc90000   rsi: ffff8300a942e000   rdi: ffff830c3dc9c088
(XEN) rbp: ffff830c3dc97d58   rsp: ffff830c3dc97d10   r8: fffff88002e402a0
(XEN) r9:  000032242fda2dba   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: ffff8300a942e000   r13: ffff830c3dc9c088   r14: ffff82d080321280
(XEN) r15: ffff830c3dc9c088   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1b505000   cr2: fffff8a00033e03e
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc97d10:
(XEN)    ffff82d080128f45 0000000000000006 ffff830c3dc97d38 ffff82d08012aa17
(XEN)    0000000000000000 ffff8300a942e000 0000000000000028 0000000000000000
(XEN)    0000000000000000 ffff830c3dc97d88 ffff82d080129079 0000000000000246
(XEN)    ffff830c3dc97d88 ffff82d08012a80f ffff830c3dc97f18 ffff830c3dc97f08
(XEN)    ffff82d0801dda32 ffff8300a942e000 ffff8300a942e000 ffff8300a942e000
(XEN)    ffff830c3dc9c088 ffff830c3dc97e08 0000000000000000 ffff830c3dc97de8
(XEN)    ffff830c3dc90000 ffff830c3dc9c0a0 ffff8300a942e000 0000151cebb9d23b
(XEN)    ffff8300a942e000 ffff830c3dc9c088 0000000001c9c380 0000000000000292
(XEN)    ffff830c3dc97e28 ffff82d08012a80f ffff8300a942e000 ffff830c3dc97e98
(XEN)    ffff82d0801caea5 ffff830c3dc97ec8 ffff8300a942e508 ffff830c3dc97e58
(XEN)    ffff82d0801c89a3 ffff830c3dc97e78 ffff830c3dc97e88 ffff82d0801b5277
(XEN)    ffff8300a942e000 0000151cebb9d23b ffff8300a942e000 ffff830c3dc97f08
(XEN)    ffff82d0801e0f69 ffff830c3dc97f18 ffff8300a942e000 ffff830c3dc97f08
(XEN)    ffff82d0801ddba6 ffff830c3dc90000 0000000000000001 ffff830c3dc97ef8
(XEN)    ffff82d08012a1b3 ffff8300a942e000 ffff8300a942e000 fffff88002e4ad70
(XEN)    000036d08fbab094 000000000000000f 0000000000000001 000000000000000f
(XEN)    ffff82d0801e3c81 0000000000000001 000000000000000f 000036d08fbab094
(XEN)    fffff88002e4ad70 000000000000000f fffff88002e40180 fffff88002e4ad70
(XEN)    fffff88002e402a0 000032242fda2dba fffff88002e402a0 0000000000000002
(XEN)    fffff88002e401c0 0000000000000400 0000000000000000 fffff88002e4aeb0
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d080129079>] do_sched_op_compat+0x26/0xa1
(XEN)    [<ffff82d0801dda32>] vmx_vmexit_handler+0x1845/0x195e
(XEN)    [<ffff82d0801e3c81>] vmx_asm_vmexit_handler+0x41/0xc0
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000298520c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  000032242fda2dba   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 000036d08fbab094   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: fffff8a00033e03e
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a942c000   rcx: 0000000000000005
(XEN) rdx: ffff830c3dc80000   rsi: 0000000000000005   rdi: ffff830c3dc8e088
(XEN) rbp: ffff830c3dc87ec8   rsp: ffff830c3dc87e40   r8: ffff830c3dc8e0a0
(XEN) r9:  0000000000000000   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: 0000151cfdff3536   r13: ffff8300a942c000   r14: ffff830c3dc8e088
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c19cb4000   cr2: 0000000001550320
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc87e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dc8e0a0 0000000500c87e78
(XEN)    ffff830c3dc8e080 ffff82d0801b5277 ffff8300a942c000 fffff88002f36d70
(XEN)    ffff8300a942c000 0000000001c9c380 ffff82d0801e0f00 ffff830c3dc87f08
(XEN)    ffff82d0802f8280 ffff82d0802f8000 ffffffffffffffff ffff830c3dc80000
(XEN)    0000000000000001 ffff830c3dc87ef8 ffff82d08012a1b3 ffff8300a942c000
(XEN)    fffff88002f36d70 000036d08fbb1ba4 000000000000000f ffff830c3dc87f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 000036d08fbb1ba4 fffff88002f36d70 000000000000000f
(XEN)    fffff88002f2c180 fffff88002f36d70 fffff88002f2c2a0 000035b9461016e5
(XEN)    fffff88002f2c2a0 0000000000000002 fffff88002f2c1c0 0000000000000400
(XEN)    0000000000000000 fffff88002f36eb0 0000beef0000beef fffff8000298520c
(XEN)    000000bf0000beef 0000000000000046 fffff88002f36c20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000005 ffff8300a942c000 0000003bbd96ce00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000298520c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  000035b9461016e5   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000036d08fbb1ba4   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000001550320
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010

Thanks!

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 01:24:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 01:24:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrGTN-0006OV-Hu; Thu, 20 Nov 2014 01:23:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XrGTL-0006ON-H5
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 01:23:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F0/B1-09842-2A24D645; Thu, 20 Nov 2014 01:23:46 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416446624!13996915!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21478 invoked from network); 20 Nov 2014 01:23:45 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 01:23:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416446622; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=S44O9K2Cc3N2unaVBtHuwvYcYECXczFdI1Tb91h2zc8=;
	b=OfubclSygEBSMQ9V4RR5EJUdcXvQjxRE3ALy3E/a7nxNl/9A/dXbR2/JjidAjYfZ2FDINzSWMffcj+8Gk4ei+tVG4CTWd51R6kPQfe6PUinlpHwitfc3peHCMoA2ubn33FVoHJOx0tetpNLpCTCJf932+mkfWXis33OxUg0uaiA=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Wed, 19 Nov 2014 17:23:41 -0800
	id 000000000003048A.546D429E.000036BC
Message-ID: <546D429A.5020906@ihonk.com>
Date: Wed, 19 Nov 2014 17:23:38 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, pasik@iki.fi
References: <5457F79B.2020300@ihonk.com>
	<20141104082012.GY12451@reaktio.net>	<5458B55C0200007800044B33@mail.emea.novell.com>	<5460716A.7090905@ihonk.com>	<54608A8B0200007800045E58@mail.emea.novell.com>	<54611A86.4000200@ihonk.com>	<5461D15C02000078000464D7@mail.emea.novell.com>	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
In-Reply-To: <546B094C0200007800048A5C@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/17/2014 23:54, Jan Beulich wrote:
>>>> On 17.11.14 at 20:21, <sflist@ihonk.com> wrote:
>> Okay, I did a bisection and was not able to correlate the above error
>> message with the problem I'm seeing. Not saying it's not related, but I
>> had plenty of successful test runs in the presence of that error.
>>
>> Took me about a week (sometimes it takes as much as 6 hours to produce
>> the error), but bisect narrowed it down to this commit:
>>
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9a727a813e9b25003e433b3d
>> c3fa47e621f9e238
>>
>> What do you think?
> Thanks for narrowing this, even if this change didn't show any other
> bad effects so far (and it's been widely tested by now), and even if
> problems here would generally be expected to surface independent
> of the use of PCI pass-through. But a hang (rather than a crash)
> would indeed be the most natural result of something being wrong
> here. To double check the result, could you, in an up-to-date tree,
> simply make x86's arch_skip_send_event_check() return 0
> unconditionally?

Made this change and the host was happy.

>   Plus, without said adjustment, first just disable the
> MWAIT CPU idle driver ("mwait-idle=0") and then, if that didn't make
> a difference, use of C states altogether ("cpuidle=0"). If any of this
> does make a difference, limiting use of C states without fully
> excluding their use may need to be the next step.

Will do this next.

> Another thing - now that serial logging appears to be working for
> you, did you try whether the host, once hung, still reacts to serial
> input (perhaps force input to go to Xen right at boot via the
> "conswitch=" option)? If so, 'd' debug-key output would likely be
> the piece of most interest.

Here you go. Performed with a checkout of 9a727a81 (because it was 
handy), let me know if you'd rather see the results from 4.5-rc2 or any 
other Xen debugging info:

(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000281e2c1>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 00003acd4939f3e7   rbx: 00003acd493a0cce   rcx: 000000000000ffff
(XEN) rdx: 00003acd00000000   rsi: 0000000000000000   rdi: 0000000000000057
(XEN) rbp: 000000000000645c   rsp: fffff880033edf90   r8: fffff880033edff0
(XEN) r9:  0000000000000000   r10: fffff880033ee040   r11: 0000000342934690
(XEN) r12: fffff880033ee3c8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000066aca000   cr2: fffff98002680000
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a943e000   rcx: 0000000000000001
(XEN) rdx: ffff830c3dc70000   rsi: 0000000000000004   rdi: ffff830c3dc7a088
(XEN) rbp: ffff830c3dc77ec8   rsp: ffff830c3dc77e40   r8: ffff830c3dc7a0a0
(XEN) r9:  0000000000000000   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: 0000151cc8b48756   r13: ffff8300a943e000   r14: ffff830c3dc7a088
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c18962000   cr2: 00000000ff331aa0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc77e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dc7a0a0 0000000100c77e78
(XEN)    ffff830c3dc7a080 ffff82d0801b5277 ffff8300a943e000 fffff88002fe2d70
(XEN)    ffff8300a943e000 0000000001c9c380 ffff82d0801e0f00 ffff830c3dc77f08
(XEN)    ffff82d0802f8080 ffff82d0802f8000 ffffffffffffffff ffff830c3dc70000
(XEN)    0000000000000001 ffff830c3dc77ef8 ffff82d08012a1b3 ffff8300a943e000
(XEN)    fffff88002fe2d70 000036d08fbeebe8 000000000000000f ffff830c3dc77f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 000036d08fbeebe8 fffff88002fe2d70 000000000000000f
(XEN)    fffff88002fd8180 fffff88002fe2d70 fffff88002fd82a0 000034711df61755
(XEN)    fffff88002fd82a0 0000000000000002 fffff88002fd81c0 0000000000000400
(XEN)    0000000000000000 fffff88002fe2eb0 0000beef0000beef fffff8000298520c
(XEN)    000000bf0000beef 0000000000000046 fffff88002fe2c20 000000000000beef
(XEN)    c2c2c2c2c2c2beef c2c2c2c2c2c2beef c2c2c2c2c2c2beef c2c2c2c2c2c2beef
(XEN)    c2c2c2c200000001 ffff8300a943e000 0000003bbd958e00 c2c2c2c2c2c2c2c2
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000298520c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000034711df61755   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 000036d08fbeebe8   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000ff331aa0
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000298520e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  000034edd4ec417c   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 000036d08fe55d56   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000776ebfb8
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d0801d4bb4>] enable_intr_window+0xe4/0xed
(XEN) RFLAGS: 0000000000000202   CONTEXT: hypervisor
(XEN) rax: 00000000b6a065fe   rbx: 000000000000d202   rcx: 0000000000000000
(XEN) rdx: 0000000000000004   rsi: 000000000000d202   rdi: ffff8300a942f000
(XEN) rbp: ffff830c3dca7e98   rsp: ffff830c3dca7e68   r8: ffff8300a942f000
(XEN) r9:  00000000ffffffff   r10: ffff830c3f68d650   r11: fffff80000ba6d30
(XEN) r12: ffff8300a942f000   r13: 000000000000d202   r14: 00000000000000d2
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1b519000   cr2: 0000000004af6354
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7e68:
(XEN)    ffff830c3dca7e98 ffff82d0801bdff8 ffff830c3dca7e98 ffff8300a942f000
(XEN)    ffff8300a942f000 000000000000d202 ffff830c3dca7f08 ffff82d0801d4ea4
(XEN)    ffff82d0802f8000 000000d2ffffffff ffff830c3dca0000 0000000000000001
(XEN)    ffff830c3dca7ef8 ffff82d08012a1b3 ffff8300a942f000 ffff8300a942f000
(XEN)    0000151cdcad2c52 ffff8300a942f000 ffff830c3dcaa088 0000000001c9c380
(XEN)    ffff830c3dca7e28 ffff82d0801e3c86 0000000000000001 000000000000000f
(XEN)    000036d08fbabfb5 fffff80000ba6d30 000000000000000f fffff80002a47e80
(XEN)    fffff80000ba6d30 fffff80002a47fa0 0000362abb330cfb fffff80002a47fa0
(XEN)    0000000000000002 fffff80002a47ec0 0000000000000400 0000000000000000
(XEN)    fffff80000ba6e70 0000beef0000beef fffff8000298520c 000000bf0000beef
(XEN)    0000000000000046 fffff80000ba6be0 000000000000beef 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 0000000000000003
(XEN)    ffff8300a942f000 0000003bbd988e00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801d4bb4>] enable_intr_window+0xe4/0xed
(XEN)    [<ffff82d0801d4ea4>] vmx_intr_assist+0x28c/0x51c
(XEN)    [<ffff82d0801e3c86>] vmx_asm_vmexit_handler+0x46/0xc0
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298520c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a47e80   rcx: fffff80002a47ec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80000ba6e70
(XEN) rbp: 000000000000000f   rsp: fffff80000ba6be0   r8: fffff80002a47fa0
(XEN) r9:  0000362abb330cfb   r10: fffff80002a47fa0   r11: fffff80000ba6d30
(XEN) r12: fffff80000ba6d30   r13: 000036d08fbabfb5   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000004af6354
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff82d080321280   rcx: 0000000000000004
(XEN) rdx: ffff830c3dc90000   rsi: ffff8300a942e000   rdi: ffff830c3dc9c088
(XEN) rbp: ffff830c3dc97d58   rsp: ffff830c3dc97d10   r8: fffff88002e402a0
(XEN) r9:  000032242fda2dba   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: ffff8300a942e000   r13: ffff830c3dc9c088   r14: ffff82d080321280
(XEN) r15: ffff830c3dc9c088   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1b505000   cr2: fffff8a00033e03e
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc97d10:
(XEN)    ffff82d080128f45 0000000000000006 ffff830c3dc97d38 ffff82d08012aa17
(XEN)    0000000000000000 ffff8300a942e000 0000000000000028 0000000000000000
(XEN)    0000000000000000 ffff830c3dc97d88 ffff82d080129079 0000000000000246
(XEN)    ffff830c3dc97d88 ffff82d08012a80f ffff830c3dc97f18 ffff830c3dc97f08
(XEN)    ffff82d0801dda32 ffff8300a942e000 ffff8300a942e000 ffff8300a942e000
(XEN)    ffff830c3dc9c088 ffff830c3dc97e08 0000000000000000 ffff830c3dc97de8
(XEN)    ffff830c3dc90000 ffff830c3dc9c0a0 ffff8300a942e000 0000151cebb9d23b
(XEN)    ffff8300a942e000 ffff830c3dc9c088 0000000001c9c380 0000000000000292
(XEN)    ffff830c3dc97e28 ffff82d08012a80f ffff8300a942e000 ffff830c3dc97e98
(XEN)    ffff82d0801caea5 ffff830c3dc97ec8 ffff8300a942e508 ffff830c3dc97e58
(XEN)    ffff82d0801c89a3 ffff830c3dc97e78 ffff830c3dc97e88 ffff82d0801b5277
(XEN)    ffff8300a942e000 0000151cebb9d23b ffff8300a942e000 ffff830c3dc97f08
(XEN)    ffff82d0801e0f69 ffff830c3dc97f18 ffff8300a942e000 ffff830c3dc97f08
(XEN)    ffff82d0801ddba6 ffff830c3dc90000 0000000000000001 ffff830c3dc97ef8
(XEN)    ffff82d08012a1b3 ffff8300a942e000 ffff8300a942e000 fffff88002e4ad70
(XEN)    000036d08fbab094 000000000000000f 0000000000000001 000000000000000f
(XEN)    ffff82d0801e3c81 0000000000000001 000000000000000f 000036d08fbab094
(XEN)    fffff88002e4ad70 000000000000000f fffff88002e40180 fffff88002e4ad70
(XEN)    fffff88002e402a0 000032242fda2dba fffff88002e402a0 0000000000000002
(XEN)    fffff88002e401c0 0000000000000400 0000000000000000 fffff88002e4aeb0
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d080129079>] do_sched_op_compat+0x26/0xa1
(XEN)    [<ffff82d0801dda32>] vmx_vmexit_handler+0x1845/0x195e
(XEN)    [<ffff82d0801e3c81>] vmx_asm_vmexit_handler+0x41/0xc0
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000298520c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  000032242fda2dba   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 000036d08fbab094   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: fffff8a00033e03e
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a942c000   rcx: 0000000000000005
(XEN) rdx: ffff830c3dc80000   rsi: 0000000000000005   rdi: ffff830c3dc8e088
(XEN) rbp: ffff830c3dc87ec8   rsp: ffff830c3dc87e40   r8: ffff830c3dc8e0a0
(XEN) r9:  0000000000000000   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: 0000151cfdff3536   r13: ffff8300a942c000   r14: ffff830c3dc8e088
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c19cb4000   cr2: 0000000001550320
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc87e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dc8e0a0 0000000500c87e78
(XEN)    ffff830c3dc8e080 ffff82d0801b5277 ffff8300a942c000 fffff88002f36d70
(XEN)    ffff8300a942c000 0000000001c9c380 ffff82d0801e0f00 ffff830c3dc87f08
(XEN)    ffff82d0802f8280 ffff82d0802f8000 ffffffffffffffff ffff830c3dc80000
(XEN)    0000000000000001 ffff830c3dc87ef8 ffff82d08012a1b3 ffff8300a942c000
(XEN)    fffff88002f36d70 000036d08fbb1ba4 000000000000000f ffff830c3dc87f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 000036d08fbb1ba4 fffff88002f36d70 000000000000000f
(XEN)    fffff88002f2c180 fffff88002f36d70 fffff88002f2c2a0 000035b9461016e5
(XEN)    fffff88002f2c2a0 0000000000000002 fffff88002f2c1c0 0000000000000400
(XEN)    0000000000000000 fffff88002f36eb0 0000beef0000beef fffff8000298520c
(XEN)    000000bf0000beef 0000000000000046 fffff88002f36c20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000005 ffff8300a942c000 0000003bbd96ce00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000298520c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  000035b9461016e5   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000036d08fbb1ba4   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000001550320
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010

Thanks!

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 04:47:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 04:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrJdh-0000D7-GS; Thu, 20 Nov 2014 04:46:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrJdf-0000D2-9c
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 04:46:39 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	4F/01-07724-E227D645; Thu, 20 Nov 2014 04:46:38 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416458797!10142799!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28674 invoked from network); 20 Nov 2014 04:46:37 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 04:46:37 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 160D3AD2E;
	Thu, 20 Nov 2014 04:46:36 +0000 (UTC)
Message-ID: <546D722B.5040606@suse.com>
Date: Thu, 20 Nov 2014 05:46:35 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-4-git-send-email-jgross@suse.com>
	<20141119210453.GC20440@laptop.dumpdata.com>
In-Reply-To: <20141119210453.GC20440@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/4] introduce boot parameter for setting
	XENFEAT_virtual_p2m
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/2014 10:04 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 10:37:25AM +0100, Juergen Gross wrote:
>> Introduce a new boot parameter "virt_p2m" to be able to set
>> XENFEAT_virtual_p2m for a pv domain.
>>
>> As long as Xen tools and kdump don't support this new feature it is
>> turned off by default.
>
> Couldn't the dom0_large and dom0 be detected automatically? That is
> the dom0 could advertise it can do large-dom0 support and Xen would
> automatically switch to the right mode?

No, that's not the problem. Xen has to indicate it is capable to handle
the new mode. At dom0 construction time the dom0 kernel can't know about
the capability of kdump to handle the new mode.

In case the new interface is accepted I'll set up some kdump patches to
handle it. We can switch to dom0/dom0_large set on default if they are
accepted on time (e.g. at the time the kernel support for the new
interface is put in place).


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 04:47:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 04:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrJdh-0000D7-GS; Thu, 20 Nov 2014 04:46:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrJdf-0000D2-9c
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 04:46:39 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	4F/01-07724-E227D645; Thu, 20 Nov 2014 04:46:38 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416458797!10142799!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28674 invoked from network); 20 Nov 2014 04:46:37 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 04:46:37 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 160D3AD2E;
	Thu, 20 Nov 2014 04:46:36 +0000 (UTC)
Message-ID: <546D722B.5040606@suse.com>
Date: Thu, 20 Nov 2014 05:46:35 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-4-git-send-email-jgross@suse.com>
	<20141119210453.GC20440@laptop.dumpdata.com>
In-Reply-To: <20141119210453.GC20440@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/4] introduce boot parameter for setting
	XENFEAT_virtual_p2m
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/19/2014 10:04 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 10:37:25AM +0100, Juergen Gross wrote:
>> Introduce a new boot parameter "virt_p2m" to be able to set
>> XENFEAT_virtual_p2m for a pv domain.
>>
>> As long as Xen tools and kdump don't support this new feature it is
>> turned off by default.
>
> Couldn't the dom0_large and dom0 be detected automatically? That is
> the dom0 could advertise it can do large-dom0 support and Xen would
> automatically switch to the right mode?

No, that's not the problem. Xen has to indicate it is capable to handle
the new mode. At dom0 construction time the dom0 kernel can't know about
the capability of kdump to handle the new mode.

In case the new interface is accepted I'll set up some kdump patches to
handle it. We can switch to dom0/dom0_large set on default if they are
accepted on time (e.g. at the time the kernel support for the new
interface is put in place).


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 05:00:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 05:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrJqd-0000VO-34; Thu, 20 Nov 2014 05:00:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrJqb-0000Pl-Q8
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 05:00:01 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	1E/E4-22819-0557D645; Thu, 20 Nov 2014 05:00:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416459600!6957987!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11058 invoked from network); 20 Nov 2014 05:00:00 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 05:00:00 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id BF7D5AD53;
	Thu, 20 Nov 2014 04:59:59 +0000 (UTC)
Message-ID: <546D754E.4090305@suse.com>
Date: Thu, 20 Nov 2014 05:59:58 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
	<20141113195605.GA13039@laptop.dumpdata.com>
	<54658ABF.5050708@suse.com>
	<20141114164741.GA8198@laptop.dumpdata.com>
	<5466385E.6040009@suse.com>
	<20141119194350.GA18117@laptop.dumpdata.com>
In-Reply-To: <20141119194350.GA18117@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

On 11/19/2014 08:43 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 06:14:06PM +0100, Juergen Gross wrote:
>> On 11/14/2014 05:47 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Nov 14, 2014 at 05:53:19AM +0100, Juergen Gross wrote:
>>>> On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>> +	mfn_save = virt_to_mfn(buf);
>>>>>>>> +
>>>>>>>> +	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
>>>>>>>
>>>>>>> So the 'list' is constructed by going forward - that is from low-numbered
>>>>>>> PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
>>>>>>> other way - from the highest PFN to the lowest PFN.
>>>>>>>
>>>>>>> Won't that mean we will restore the chunks of memory in the wrong
>>>>>>> order? That is we will still restore them in chunks size, but the
>>>>>>> chunks will be in descending order instead of ascending?
>>>>>>
>>>>>> No, the information where to put each chunk is contained in the chunk
>>>>>> data. I can add a comment explaining this.
>>>>>
>>>>> Right, the MFNs in a "chunks" are going to be restored in the right order.
>>>>>
>>>>> I was thinking that the "chunks" (so a set of MFNs) will be restored in
>>>>> the opposite order that they are written to.
>>>>>
>>>>> And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?
>>>>
>>>> More don't fit on a single page due to the other info needed. So: yes.
>>>
>>> But you could use two pages - one for the structure and the other
>>> for the list of MFNs. That would fix the problem of having only
>>> 509 MFNs being contingous per chunk when restoring.
>>
>> That's no problem (see below).
>>
>>> Anyhow the point I had that I am worried is that we do not restore the
>>> MFNs in the same order. We do it in "chunk" size which is OK (so the 509 MFNs
>>> at once)- but the order we traverse the restoration process is the opposite of
>>> the save process. Say we have 4MB of contingous MFNs, so two (err, three)
>>> chunks. The first one we iterate is from 0->509, the second is 510->1018, the
>>> last is 1019->1023. When we restore (remap) we start with the last 'chunk'
>>> so we end up restoring them: 1019->1023, 510->1018, 0->509 order.
>>
>> No. When building up the chunks we save in each chunk where to put it
>> on remap. So in your example 0-509 should be mapped at <dest>+0,
>> 510-1018 at <dest>+510, and 1019-1023 at <dest>+1019.
>>
>> When remapping we map 1019-1023 to <dest>+1019, 510-1018 at <dest>+510
>> and last 0-509 at <dest>+0. So we do the mapping in reverse order, but
>> to the correct pfns.
>
> Excellent! Could a condensed version of that explanation be put in the code ?

Sure.

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 05:00:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 05:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrJqd-0000VO-34; Thu, 20 Nov 2014 05:00:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrJqb-0000Pl-Q8
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 05:00:01 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	1E/E4-22819-0557D645; Thu, 20 Nov 2014 05:00:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416459600!6957987!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11058 invoked from network); 20 Nov 2014 05:00:00 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 05:00:00 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id BF7D5AD53;
	Thu, 20 Nov 2014 04:59:59 +0000 (UTC)
Message-ID: <546D754E.4090305@suse.com>
Date: Thu, 20 Nov 2014 05:59:58 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<1415684626-18590-3-git-send-email-jgross@suse.com>
	<20141112214506.GA5922@laptop.dumpdata.com>
	<54644E48.3040506@suse.com>
	<20141113195605.GA13039@laptop.dumpdata.com>
	<54658ABF.5050708@suse.com>
	<20141114164741.GA8198@laptop.dumpdata.com>
	<5466385E.6040009@suse.com>
	<20141119194350.GA18117@laptop.dumpdata.com>
In-Reply-To: <20141119194350.GA18117@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 2/8] xen: Delay remapping memory of
	pv-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

On 11/19/2014 08:43 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 06:14:06PM +0100, Juergen Gross wrote:
>> On 11/14/2014 05:47 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Nov 14, 2014 at 05:53:19AM +0100, Juergen Gross wrote:
>>>> On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>> +	mfn_save = virt_to_mfn(buf);
>>>>>>>> +
>>>>>>>> +	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
>>>>>>>
>>>>>>> So the 'list' is constructed by going forward - that is from low-numbered
>>>>>>> PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
>>>>>>> other way - from the highest PFN to the lowest PFN.
>>>>>>>
>>>>>>> Won't that mean we will restore the chunks of memory in the wrong
>>>>>>> order? That is we will still restore them in chunks size, but the
>>>>>>> chunks will be in descending order instead of ascending?
>>>>>>
>>>>>> No, the information where to put each chunk is contained in the chunk
>>>>>> data. I can add a comment explaining this.
>>>>>
>>>>> Right, the MFNs in a "chunks" are going to be restored in the right order.
>>>>>
>>>>> I was thinking that the "chunks" (so a set of MFNs) will be restored in
>>>>> the opposite order that they are written to.
>>>>>
>>>>> And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?
>>>>
>>>> More don't fit on a single page due to the other info needed. So: yes.
>>>
>>> But you could use two pages - one for the structure and the other
>>> for the list of MFNs. That would fix the problem of having only
>>> 509 MFNs being contingous per chunk when restoring.
>>
>> That's no problem (see below).
>>
>>> Anyhow the point I had that I am worried is that we do not restore the
>>> MFNs in the same order. We do it in "chunk" size which is OK (so the 509 MFNs
>>> at once)- but the order we traverse the restoration process is the opposite of
>>> the save process. Say we have 4MB of contingous MFNs, so two (err, three)
>>> chunks. The first one we iterate is from 0->509, the second is 510->1018, the
>>> last is 1019->1023. When we restore (remap) we start with the last 'chunk'
>>> so we end up restoring them: 1019->1023, 510->1018, 0->509 order.
>>
>> No. When building up the chunks we save in each chunk where to put it
>> on remap. So in your example 0-509 should be mapped at <dest>+0,
>> 510-1018 at <dest>+510, and 1019-1023 at <dest>+1019.
>>
>> When remapping we map 1019-1023 to <dest>+1019, 510-1018 at <dest>+510
>> and last 0-509 at <dest>+0. So we do the mapping in reverse order, but
>> to the correct pfns.
>
> Excellent! Could a condensed version of that explanation be put in the code ?

Sure.

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 05:08:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 05:08:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrJyw-0000qS-CI; Thu, 20 Nov 2014 05:08:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrJyu-0000qN-6t
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 05:08:36 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	1B/A8-02696-3577D645; Thu, 20 Nov 2014 05:08:35 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416460114!13625995!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24300 invoked from network); 20 Nov 2014 05:08:34 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 05:08:34 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 69402AC54;
	Thu, 20 Nov 2014 05:08:34 +0000 (UTC)
Message-ID: <546D7751.6060707@suse.com>
Date: Thu, 20 Nov 2014 06:08:33 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<20141119204131.GD18495@laptop.dumpdata.com>
In-Reply-To: <20141119204131.GD18495@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 0/8] xen: Switch to virtual mapped linear
	p2m 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

On 11/19/2014 09:41 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 06:43:38AM +0100, Juergen Gross wrote:
>> Paravirtualized kernels running on Xen use a three level tree for
>> translation of guest specific physical addresses to machine global
>> addresses. This p2m tree is used for construction of page table
>> entries, so the p2m tree walk is performance critical.
>>
>> By using a linear virtual mapped p2m list accesses to p2m elements
>> can be sped up while even simplifying code. To achieve this goal
>> some p2m related initializations have to be performed later in the
>> boot process, as the final p2m list can be set up only after basic
>> memory management functions are available.
>>
>
> Hey Juergen,
>
> I finially finished looking at the patchset. Had some comments,
> some questions that I hope can make it in the patch so that in
> six months or so when somebody looks at the code they can
> understand the subtle pieces.

Yep.

OTOH: What was hard to write should be hard to read ;-)

> Looking forward to the v4! (Thought keep in mind that next week
> is Thanksgiving week so won't be able to look much after Wednesday)

Let's see how testing is going. Setting up the test system wasn't
very smooth due to some unrelated issues.

>
>>   arch/x86/include/asm/pgtable_types.h |    1 +
>>   arch/x86/include/asm/xen/page.h      |   49 +-
>>   arch/x86/mm/pageattr.c               |   20 +
>>   arch/x86/xen/mmu.c                   |   38 +-
>>   arch/x86/xen/p2m.c                   | 1315 ++++++++++++++--------------------
>>   arch/x86/xen/setup.c                 |  460 ++++++------
>>   arch/x86/xen/xen-ops.h               |    6 +-
>>   7 files changed, 854 insertions(+), 1035 deletions(-)
>
> And best of - we are deleting more code!

Indeed. But it's a shame the beautiful ASCII-art in p2m.c is part of the
deletions.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 05:08:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 05:08:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrJyw-0000qS-CI; Thu, 20 Nov 2014 05:08:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrJyu-0000qN-6t
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 05:08:36 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	1B/A8-02696-3577D645; Thu, 20 Nov 2014 05:08:35 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416460114!13625995!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24300 invoked from network); 20 Nov 2014 05:08:34 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 05:08:34 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 69402AC54;
	Thu, 20 Nov 2014 05:08:34 +0000 (UTC)
Message-ID: <546D7751.6060707@suse.com>
Date: Thu, 20 Nov 2014 06:08:33 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1415684626-18590-1-git-send-email-jgross@suse.com>
	<20141119204131.GD18495@laptop.dumpdata.com>
In-Reply-To: <20141119204131.GD18495@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, david.vrabel@citrix.com, hpa@zytor.com,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH V3 0/8] xen: Switch to virtual mapped linear
	p2m 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

On 11/19/2014 09:41 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 11, 2014 at 06:43:38AM +0100, Juergen Gross wrote:
>> Paravirtualized kernels running on Xen use a three level tree for
>> translation of guest specific physical addresses to machine global
>> addresses. This p2m tree is used for construction of page table
>> entries, so the p2m tree walk is performance critical.
>>
>> By using a linear virtual mapped p2m list accesses to p2m elements
>> can be sped up while even simplifying code. To achieve this goal
>> some p2m related initializations have to be performed later in the
>> boot process, as the final p2m list can be set up only after basic
>> memory management functions are available.
>>
>
> Hey Juergen,
>
> I finially finished looking at the patchset. Had some comments,
> some questions that I hope can make it in the patch so that in
> six months or so when somebody looks at the code they can
> understand the subtle pieces.

Yep.

OTOH: What was hard to write should be hard to read ;-)

> Looking forward to the v4! (Thought keep in mind that next week
> is Thanksgiving week so won't be able to look much after Wednesday)

Let's see how testing is going. Setting up the test system wasn't
very smooth due to some unrelated issues.

>
>>   arch/x86/include/asm/pgtable_types.h |    1 +
>>   arch/x86/include/asm/xen/page.h      |   49 +-
>>   arch/x86/mm/pageattr.c               |   20 +
>>   arch/x86/xen/mmu.c                   |   38 +-
>>   arch/x86/xen/p2m.c                   | 1315 ++++++++++++++--------------------
>>   arch/x86/xen/setup.c                 |  460 ++++++------
>>   arch/x86/xen/xen-ops.h               |    6 +-
>>   7 files changed, 854 insertions(+), 1035 deletions(-)
>
> And best of - we are deleting more code!

Indeed. But it's a shame the beautiful ASCII-art in p2m.c is part of the
deletions.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 07:32:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 07: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.xen.org>)
	id 1XrMCv-0002H3-1u; Thu, 20 Nov 2014 07:31: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 1XrMCt-0002Gy-Jm
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 07:31:11 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	D4/D4-11581-EB89D645; Thu, 20 Nov 2014 07:31:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416468669!7090772!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30769 invoked from network); 20 Nov 2014 07:31:09 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 07:31:09 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 07:31:09 +0000
Message-Id: <546DA6CB02000078000492C5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 07:31:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
	<546B20910200007800048AC0@mail.emea.novell.com>
	<546BF1AD.4010801@intel.com>
In-Reply-To: <546BF1AD.4010801@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 02:26, <tiejun.chen@intel.com> wrote:
>> > So without lookuping devices[i], how can we call func() for each sbdf as
>>> you mentioned?
>>
>> You've got both rmrr and bdf in the body of for_each_rmrr_device().
>> After all - as I said - you just open-coded it.
>>
> 
> Yeah, so change this again,
> 
> int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
> {
>      struct acpi_rmrr_unit *rmrr;
>      int rc = 0;
>      unsigned int i;
>      u16 bdf;
> 
>      for_each_rmrr_device ( rmrr, bdf, i )
>      {
>          rc = func(PFN_DOWN(rmrr->base_address),
>                             PFN_UP(rmrr->end_address) -
>                              PFN_DOWN(rmrr->base_address),
>                             PCI_SBDF(rmrr->segment, bdf),
>                            ctxt);
>          /* Hit this entry so just go next. */
>          if ( rc == 1 )
>              i = rmrr->scope.devices_cnt;
>          else if ( rc < 0 )
>              return rc;
>      }
> 
>      return rc;
> }

Better. Another improvement would be make it not depend on the
internal workings of for_each_rmrr_device()... And in any case you
should not special case 1 - just return when rc is negative and skip
the rest of the current RMRR when it's positive. And of course make
the function's final return value predictable.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 07:32:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 07: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.xen.org>)
	id 1XrMCv-0002H3-1u; Thu, 20 Nov 2014 07:31: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 1XrMCt-0002Gy-Jm
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 07:31:11 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	D4/D4-11581-EB89D645; Thu, 20 Nov 2014 07:31:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416468669!7090772!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30769 invoked from network); 20 Nov 2014 07:31:09 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 07:31:09 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 07:31:09 +0000
Message-Id: <546DA6CB02000078000492C5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 07:31:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
	<546B20910200007800048AC0@mail.emea.novell.com>
	<546BF1AD.4010801@intel.com>
In-Reply-To: <546BF1AD.4010801@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 02:26, <tiejun.chen@intel.com> wrote:
>> > So without lookuping devices[i], how can we call func() for each sbdf as
>>> you mentioned?
>>
>> You've got both rmrr and bdf in the body of for_each_rmrr_device().
>> After all - as I said - you just open-coded it.
>>
> 
> Yeah, so change this again,
> 
> int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
> {
>      struct acpi_rmrr_unit *rmrr;
>      int rc = 0;
>      unsigned int i;
>      u16 bdf;
> 
>      for_each_rmrr_device ( rmrr, bdf, i )
>      {
>          rc = func(PFN_DOWN(rmrr->base_address),
>                             PFN_UP(rmrr->end_address) -
>                              PFN_DOWN(rmrr->base_address),
>                             PCI_SBDF(rmrr->segment, bdf),
>                            ctxt);
>          /* Hit this entry so just go next. */
>          if ( rc == 1 )
>              i = rmrr->scope.devices_cnt;
>          else if ( rc < 0 )
>              return rc;
>      }
> 
>      return rc;
> }

Better. Another improvement would be make it not depend on the
internal workings of for_each_rmrr_device()... And in any case you
should not special case 1 - just return when rc is negative and skip
the rest of the current RMRR when it's positive. And of course make
the function's final return value predictable.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 07:46:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 07:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrMQp-0002XU-FB; Thu, 20 Nov 2014 07:45:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XrMQo-0002XP-Fw
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 07:45:34 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	28/40-27623-D1C9D645; Thu, 20 Nov 2014 07:45:33 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416469532!12479386!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1103 invoked from network); 20 Nov 2014 07:45:32 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-31.messagelabs.com with SMTP;
	20 Nov 2014 07:45:32 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 19 Nov 2014 23:45:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="419118006"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by FMSMGA003.fm.intel.com with ESMTP; 19 Nov 2014 23:35:59 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 20 Nov 2014 15:45:24 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Thu, 20 Nov 2014 15:45:17 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
	guest memory is out of reserved device memory maps
Thread-Index: AQHP/l8LtnOoOMCxBUyde78SnbhphJxnpV8ggAF+RLA=
Date: Thu, 20 Nov 2014 07:45:16 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tian, Kevin
> Sent: Wednesday, November 19, 2014 4:18 PM
> 
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Wednesday, November 12, 2014 5:57 PM
> >
> > >>> On 12.11.14 at 10:13, <tiejun.chen@intel.com> wrote:
> > > On 2014/11/12 17:02, Jan Beulich wrote:
> > >>>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
> > >>>>> #2 flags field in each specific device of new domctl would control
> > >>>>> whether this device need to check/reserve its own RMRR range. But
> its
> > >>>>> not dependent on current device assignment domctl, so the user can
> > use
> > >>>>> them to control which devices need to work as hotplug later,
> separately.
> > >>>>
> > >>>> And this could be left as a second step, in order for what needs to
> > >>>> be done now to not get more complicated that necessary.
> > >>>>
> > >>>
> > >>> Do you mean currently we still rely on the device assignment domctl to
> > >>> provide SBDF? So looks nothing should be changed in our policy.
> > >>
> > >> I can't connect your question to what I said. What I tried to tell you
> > >
> > > Something is misunderstanding to me.
> > >
> > >> was that I don't currently see a need to make this overly complicated:
> > >> Having the option to punch holes for all devices and (by default)
> > >> dealing with just the devices assigned at boot may be sufficient as a
> > >> first step. Yet (repeating just to avoid any misunderstanding) that
> > >> makes things easier only if we decide to require device assignment to
> > >> happen before memory getting populated (since in that case there's
> > >
> > > Here what do you mean, 'if we decide to require device assignment to
> > > happen before memory getting populated'?
> > >
> > > Because -quote-
> > > "
> > > In the present the device assignment is always after memory population.
> > > And I also mentioned previously I double checked this sequence with printk.
> > > "
> > >
> > > Or you already plan or deciede to change this sequence?
> >
> > So it is now the 3rd time that I'm telling you that part of your
> > decision making as to which route to follow should be to
> > re-consider whether the current sequence of operations shouldn't
> > be changed. Please also consult with the VT-d maintainers (hint to
> > them: participating in this discussion publicly would be really nice)
> > on _all_ decisions to be made here.
> >
> 

Yang and I did some discussion here. We understand your point to
avoid introducing new interface if we can leverage existing code.
However it's not a trivial effort to move device assignment before 
populating p2m, and there is no other benefit of doing so except
for this purpose. So we'd not suggest this way.

Current option sounds a reasonable one, i.e. passing a list of BDFs
assigned to this VM before populating p2m, and then having 
hypervisor to filter out reserved regions associated with those 
BDFs. This way libxc teaches Xen to create reserved regions once,
and then later the filtered info is returned upon query.

The limitation of wasted memory due to confliction can be
mitigated, and we considered further enhancement can be made
later in libxc that when populating p2m, the reserved regions
can be skipped explicitly at initial p2m creation phase and then 
there would be no waste at all. But this optimization takes some
time and can be built incrementally on current patch and interface, 
post 4.5 release. For now let's focus on the very correctness first.

If you agree, Tiejun will move forward to send another series for 4.5. So
far lots of opens have been closed with your help, but it also means
original v7 needs a serious update then (latest code is in deep discussion
list)

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 07:46:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 07:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrMQp-0002XU-FB; Thu, 20 Nov 2014 07:45:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XrMQo-0002XP-Fw
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 07:45:34 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	28/40-27623-D1C9D645; Thu, 20 Nov 2014 07:45:33 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416469532!12479386!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1103 invoked from network); 20 Nov 2014 07:45:32 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-31.messagelabs.com with SMTP;
	20 Nov 2014 07:45:32 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 19 Nov 2014 23:45:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="419118006"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by FMSMGA003.fm.intel.com with ESMTP; 19 Nov 2014 23:35:59 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 20 Nov 2014 15:45:24 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Thu, 20 Nov 2014 15:45:17 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
	guest memory is out of reserved device memory maps
Thread-Index: AQHP/l8LtnOoOMCxBUyde78SnbhphJxnpV8ggAF+RLA=
Date: Thu, 20 Nov 2014 07:45:16 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tian, Kevin
> Sent: Wednesday, November 19, 2014 4:18 PM
> 
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Wednesday, November 12, 2014 5:57 PM
> >
> > >>> On 12.11.14 at 10:13, <tiejun.chen@intel.com> wrote:
> > > On 2014/11/12 17:02, Jan Beulich wrote:
> > >>>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
> > >>>>> #2 flags field in each specific device of new domctl would control
> > >>>>> whether this device need to check/reserve its own RMRR range. But
> its
> > >>>>> not dependent on current device assignment domctl, so the user can
> > use
> > >>>>> them to control which devices need to work as hotplug later,
> separately.
> > >>>>
> > >>>> And this could be left as a second step, in order for what needs to
> > >>>> be done now to not get more complicated that necessary.
> > >>>>
> > >>>
> > >>> Do you mean currently we still rely on the device assignment domctl to
> > >>> provide SBDF? So looks nothing should be changed in our policy.
> > >>
> > >> I can't connect your question to what I said. What I tried to tell you
> > >
> > > Something is misunderstanding to me.
> > >
> > >> was that I don't currently see a need to make this overly complicated:
> > >> Having the option to punch holes for all devices and (by default)
> > >> dealing with just the devices assigned at boot may be sufficient as a
> > >> first step. Yet (repeating just to avoid any misunderstanding) that
> > >> makes things easier only if we decide to require device assignment to
> > >> happen before memory getting populated (since in that case there's
> > >
> > > Here what do you mean, 'if we decide to require device assignment to
> > > happen before memory getting populated'?
> > >
> > > Because -quote-
> > > "
> > > In the present the device assignment is always after memory population.
> > > And I also mentioned previously I double checked this sequence with printk.
> > > "
> > >
> > > Or you already plan or deciede to change this sequence?
> >
> > So it is now the 3rd time that I'm telling you that part of your
> > decision making as to which route to follow should be to
> > re-consider whether the current sequence of operations shouldn't
> > be changed. Please also consult with the VT-d maintainers (hint to
> > them: participating in this discussion publicly would be really nice)
> > on _all_ decisions to be made here.
> >
> 

Yang and I did some discussion here. We understand your point to
avoid introducing new interface if we can leverage existing code.
However it's not a trivial effort to move device assignment before 
populating p2m, and there is no other benefit of doing so except
for this purpose. So we'd not suggest this way.

Current option sounds a reasonable one, i.e. passing a list of BDFs
assigned to this VM before populating p2m, and then having 
hypervisor to filter out reserved regions associated with those 
BDFs. This way libxc teaches Xen to create reserved regions once,
and then later the filtered info is returned upon query.

The limitation of wasted memory due to confliction can be
mitigated, and we considered further enhancement can be made
later in libxc that when populating p2m, the reserved regions
can be skipped explicitly at initial p2m creation phase and then 
there would be no waste at all. But this optimization takes some
time and can be built incrementally on current patch and interface, 
post 4.5 release. For now let's focus on the very correctness first.

If you agree, Tiejun will move forward to send another series for 4.5. So
far lots of opens have been closed with your help, but it also means
original v7 needs a serious update then (latest code is in deep discussion
list)

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 07:59:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 07:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrMe5-0002k0-QT; Thu, 20 Nov 2014 07:59: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 1XrMe4-0002jv-JM
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 07:59:16 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	A3/21-14214-35F9D645; Thu, 20 Nov 2014 07:59:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416470355!6978668!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28052 invoked from network); 20 Nov 2014 07:59:15 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 07:59:15 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 07:59:14 +0000
Message-Id: <546DAD6502000078000492FD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 07:59:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
In-Reply-To: <546D429A.5020906@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 02:23, <sflist@ihonk.com> wrote:
> On 11/17/2014 23:54, Jan Beulich wrote:
>> Another thing - now that serial logging appears to be working for
>> you, did you try whether the host, once hung, still reacts to serial
>> input (perhaps force input to go to Xen right at boot via the
>> "conswitch=" option)? If so, 'd' debug-key output would likely be
>> the piece of most interest.
> 
> Here you go. Performed with a checkout of 9a727a81 (because it was 
> handy), let me know if you'd rather see the results from 4.5-rc2 or any 
> other Xen debugging info:

Interesting - all CPUs are executing stuff from Dom1, which be itself
is not indicating a problem, but may (considering the host hang) hint
at guest vCPU-s not getting de-scheduled anymore on one or more of
the CPUs. The 'a' debug key output would hopefully give us enough
information to know whether that's the case. Ideally do 'd' and 'a'
a couple of times each (alternating, and with a few seconds in
between).

Also, for double checking purposes, could you make the xen-syms
of a build you observed the problem with available somewhere?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 07:59:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 07:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrMe5-0002k0-QT; Thu, 20 Nov 2014 07:59: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 1XrMe4-0002jv-JM
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 07:59:16 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	A3/21-14214-35F9D645; Thu, 20 Nov 2014 07:59:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416470355!6978668!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28052 invoked from network); 20 Nov 2014 07:59:15 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 07:59:15 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 07:59:14 +0000
Message-Id: <546DAD6502000078000492FD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 07:59:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
In-Reply-To: <546D429A.5020906@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 02:23, <sflist@ihonk.com> wrote:
> On 11/17/2014 23:54, Jan Beulich wrote:
>> Another thing - now that serial logging appears to be working for
>> you, did you try whether the host, once hung, still reacts to serial
>> input (perhaps force input to go to Xen right at boot via the
>> "conswitch=" option)? If so, 'd' debug-key output would likely be
>> the piece of most interest.
> 
> Here you go. Performed with a checkout of 9a727a81 (because it was 
> handy), let me know if you'd rather see the results from 4.5-rc2 or any 
> other Xen debugging info:

Interesting - all CPUs are executing stuff from Dom1, which be itself
is not indicating a problem, but may (considering the host hang) hint
at guest vCPU-s not getting de-scheduled anymore on one or more of
the CPUs. The 'a' debug key output would hopefully give us enough
information to know whether that's the case. Ideally do 'd' and 'a'
a couple of times each (alternating, and with a few seconds in
between).

Also, for double checking purposes, could you make the xen-syms
of a build you observed the problem with available somewhere?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:04:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrMiv-0003OE-9i; Thu, 20 Nov 2014 08:04:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrMit-0003O8-Nk
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 08:04:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	62/93-09936-F70AD645; Thu, 20 Nov 2014 08:04:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416470654!14033974!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7586 invoked from network); 20 Nov 2014 08:04:14 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 08:04:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 08:04:14 +0000
Message-Id: <546DAE8F020000780004930A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 08:04:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Tiejun Chen <tiejun.chen@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 08:45, <kevin.tian@intel.com> wrote:
> Yang and I did some discussion here. We understand your point to
> avoid introducing new interface if we can leverage existing code.
> However it's not a trivial effort to move device assignment before 
> populating p2m, and there is no other benefit of doing so except
> for this purpose. So we'd not suggest this way.

"It's not a trivial effort" is pretty vague: What specifically is it that
makes this difficult? I wouldn't expect there to be any strong
dependencies on the ordering of these two operations...

> Current option sounds a reasonable one, i.e. passing a list of BDFs
> assigned to this VM before populating p2m, and then having 
> hypervisor to filter out reserved regions associated with those 
> BDFs. This way libxc teaches Xen to create reserved regions once,
> and then later the filtered info is returned upon query.

Reasonable, but partly redundant. The positive aspect being that
it permits this list and the list of actually being assigned devices to
be different, i.e. allowing holes to be set up for devices that only
_may_ get assigned at some point.

> The limitation of wasted memory due to confliction can be
> mitigated, and we considered further enhancement can be made
> later in libxc that when populating p2m, the reserved regions
> can be skipped explicitly at initial p2m creation phase and then 
> there would be no waste at all. But this optimization takes some
> time and can be built incrementally on current patch and interface, 
> post 4.5 release. For now let's focus on the very correctness first.

I agree, as long as the optimization part doesn't get dropped after
the correctness part went in.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:04:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrMiv-0003OE-9i; Thu, 20 Nov 2014 08:04:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrMit-0003O8-Nk
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 08:04:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	62/93-09936-F70AD645; Thu, 20 Nov 2014 08:04:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416470654!14033974!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7586 invoked from network); 20 Nov 2014 08:04:14 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 08:04:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 08:04:14 +0000
Message-Id: <546DAE8F020000780004930A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 08:04:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Tiejun Chen <tiejun.chen@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 08:45, <kevin.tian@intel.com> wrote:
> Yang and I did some discussion here. We understand your point to
> avoid introducing new interface if we can leverage existing code.
> However it's not a trivial effort to move device assignment before 
> populating p2m, and there is no other benefit of doing so except
> for this purpose. So we'd not suggest this way.

"It's not a trivial effort" is pretty vague: What specifically is it that
makes this difficult? I wouldn't expect there to be any strong
dependencies on the ordering of these two operations...

> Current option sounds a reasonable one, i.e. passing a list of BDFs
> assigned to this VM before populating p2m, and then having 
> hypervisor to filter out reserved regions associated with those 
> BDFs. This way libxc teaches Xen to create reserved regions once,
> and then later the filtered info is returned upon query.

Reasonable, but partly redundant. The positive aspect being that
it permits this list and the list of actually being assigned devices to
be different, i.e. allowing holes to be set up for devices that only
_may_ get assigned at some point.

> The limitation of wasted memory due to confliction can be
> mitigated, and we considered further enhancement can be made
> later in libxc that when populating p2m, the reserved regions
> can be skipped explicitly at initial p2m creation phase and then 
> there would be no waste at all. But this optimization takes some
> time and can be built incrementally on current patch and interface, 
> post 4.5 release. For now let's focus on the very correctness first.

I agree, as long as the optimization part doesn't get dropped after
the correctness part went in.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:12:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrMq4-0003bW-K4; Thu, 20 Nov 2014 08:11:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrMq3-0003bP-Kx
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 08:11:39 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	A2/2B-27623-A32AD645; Thu, 20 Nov 2014 08:11:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416471098!12633006!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32184 invoked from network); 20 Nov 2014 08:11:38 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 08:11:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 08:11:37 +0000
Message-Id: <546DB0490200007800049315@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 08:11:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
	<1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
	<54662A360200007800047BDB@mail.emea.novell.com>
	<20141114161146.GG5364@laptop.dumpdata.com>
	<20141119164440.GA18595@laptop.dumpdata.com>
In-Reply-To: <20141119164440.GA18595@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, linux@eikelenboom.it,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet
 with an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 17:44, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 14, 2014 at 11:11:46AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Nov 14, 2014 at 03:13:42PM +0000, Jan Beulich wrote:
>> > >>> On 12.11.14 at 03:23, <konrad.wilk@oracle.com> wrote:
>> > > +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
>> > > +{
>> > > +    struct domain *d = pirq_dpci->dom;
>> > > +
>> > > +    ASSERT(spin_is_locked(&d->event_lock));
>> > > +
>> > > +    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
>> > > +    {
>> > > +    case (1 << STATE_SCHED):
>> > > +        /*
>> > > +         * We are going to try to de-schedule the softirq before it goes 
> in
>> > > +         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
>> > > +         */
>> > > +        put_domain(d);
>> > > +        /* fallthrough. */
>> > 
>> > Considering Sander's report, the only suspicious place I find is this
>> > one: When the STATE_SCHED flag is set, pirq_dpci is on some
>> > CPU's list. What guarantees it to get removed from that list before
>> > getting inserted on another one?
>> 
>> None. The moment that STATE_SCHED is cleared, 'raise_softirq_for'
>> is free to manipulate the list.
> 
> I was too quick to say this. A bit more inspection shows that while
> 'raise_softirq_for' is free to manipulate the list - it won't be called.
> 
> The reason is that the pt_pirq_softirq_reset is called _after_ the IRQ
> action handler are removed for this IRQ. That means we will not receive
> any interrupts for it and call 'raise_softirq_for'. At least until
> 'pt_irq_create_bind' is called. And said function has a check for
> this too:
> 
> 42      * A crude 'while' loop with us dropping the spinlock and giving
> 243      * the softirq_dpci a chance to run.
> 244      * We MUST check for this condition as the softirq could be scheduled
> 245      * and hasn't run yet. Note that this code replaced tasklet_kill which
> 246      * would have spun forever and would do the same thing (wait to flush out
> 247      * outstanding hvm_dirq_assist calls.
> 248      */
> 249     if ( pt_pirq_softirq_active(pirq_dpci) )

With that you correct your earlier reply, but I don't see how this
answers my original question.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:12:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrMq4-0003bW-K4; Thu, 20 Nov 2014 08:11:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrMq3-0003bP-Kx
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 08:11:39 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	A2/2B-27623-A32AD645; Thu, 20 Nov 2014 08:11:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416471098!12633006!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32184 invoked from network); 20 Nov 2014 08:11:38 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 08:11:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 08:11:37 +0000
Message-Id: <546DB0490200007800049315@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 08:11:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1415759004-11903-1-git-send-email-konrad.wilk@oracle.com>
	<1415759004-11903-3-git-send-email-konrad.wilk@oracle.com>
	<54662A360200007800047BDB@mail.emea.novell.com>
	<20141114161146.GG5364@laptop.dumpdata.com>
	<20141119164440.GA18595@laptop.dumpdata.com>
In-Reply-To: <20141119164440.GA18595@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, linux@eikelenboom.it,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v10 for-xen-4.5 2/2] dpci: Replace tasklet
 with an softirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 17:44, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 14, 2014 at 11:11:46AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Nov 14, 2014 at 03:13:42PM +0000, Jan Beulich wrote:
>> > >>> On 12.11.14 at 03:23, <konrad.wilk@oracle.com> wrote:
>> > > +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
>> > > +{
>> > > +    struct domain *d = pirq_dpci->dom;
>> > > +
>> > > +    ASSERT(spin_is_locked(&d->event_lock));
>> > > +
>> > > +    switch ( cmpxchg(&pirq_dpci->state, 1 << STATE_SCHED, 0) )
>> > > +    {
>> > > +    case (1 << STATE_SCHED):
>> > > +        /*
>> > > +         * We are going to try to de-schedule the softirq before it goes 
> in
>> > > +         * STATE_RUN. Whoever clears STATE_SCHED MUST refcount the 'dom'.
>> > > +         */
>> > > +        put_domain(d);
>> > > +        /* fallthrough. */
>> > 
>> > Considering Sander's report, the only suspicious place I find is this
>> > one: When the STATE_SCHED flag is set, pirq_dpci is on some
>> > CPU's list. What guarantees it to get removed from that list before
>> > getting inserted on another one?
>> 
>> None. The moment that STATE_SCHED is cleared, 'raise_softirq_for'
>> is free to manipulate the list.
> 
> I was too quick to say this. A bit more inspection shows that while
> 'raise_softirq_for' is free to manipulate the list - it won't be called.
> 
> The reason is that the pt_pirq_softirq_reset is called _after_ the IRQ
> action handler are removed for this IRQ. That means we will not receive
> any interrupts for it and call 'raise_softirq_for'. At least until
> 'pt_irq_create_bind' is called. And said function has a check for
> this too:
> 
> 42      * A crude 'while' loop with us dropping the spinlock and giving
> 243      * the softirq_dpci a chance to run.
> 244      * We MUST check for this condition as the softirq could be scheduled
> 245      * and hasn't run yet. Note that this code replaced tasklet_kill which
> 246      * would have spun forever and would do the same thing (wait to flush out
> 247      * outstanding hvm_dirq_assist calls.
> 248      */
> 249     if ( pt_pirq_softirq_active(pirq_dpci) )

With that you correct your earlier reply, but I don't see how this
answers my original question.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:12:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08:12:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrMr0-0003iq-1d; Thu, 20 Nov 2014 08:12:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XrMqy-0003ib-4Z
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 08:12:36 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	F3/A9-02712-372AD645; Thu, 20 Nov 2014 08:12:35 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416471153!13662351!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3974 invoked from network); 20 Nov 2014 08:12:34 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-27.messagelabs.com with SMTP;
	20 Nov 2014 08:12:34 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 20 Nov 2014 00:12:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,422,1413270000"; d="scan'208";a="635045112"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.128])
	([10.238.130.128])
	by fmsmga002.fm.intel.com with ESMTP; 20 Nov 2014 00:12:10 -0800
Message-ID: <546DA259.10609@intel.com>
Date: Thu, 20 Nov 2014 16:12:09 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
	<546B20910200007800048AC0@mail.emea.novell.com>
	<546BF1AD.4010801@intel.com>
	<546DA6CB02000078000492C5@mail.emea.novell.com>
In-Reply-To: <546DA6CB02000078000492C5@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/20 15:31, Jan Beulich wrote:
>>>> On 19.11.14 at 02:26, <tiejun.chen@intel.com> wrote:
>>>> So without lookuping devices[i], how can we call func() for each sbdf as
>>>> you mentioned?
>>>
>>> You've got both rmrr and bdf in the body of for_each_rmrr_device().
>>> After all - as I said - you just open-coded it.
>>>
>>
>> Yeah, so change this again,
>>
>> int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>> {
>>       struct acpi_rmrr_unit *rmrr;
>>       int rc = 0;
>>       unsigned int i;
>>       u16 bdf;
>>
>>       for_each_rmrr_device ( rmrr, bdf, i )
>>       {
>>           rc = func(PFN_DOWN(rmrr->base_address),
>>                              PFN_UP(rmrr->end_address) -
>>                               PFN_DOWN(rmrr->base_address),
>>                              PCI_SBDF(rmrr->segment, bdf),
>>                             ctxt);
>>           /* Hit this entry so just go next. */
>>           if ( rc == 1 )
>>               i = rmrr->scope.devices_cnt;
>>           else if ( rc < 0 )
>>               return rc;
>>       }
>>
>>       return rc;
>> }
>
> Better. Another improvement would be make it not depend on the
> internal workings of for_each_rmrr_device()... And in any case you

Yes but as you see,

#define for_each_rmrr_device(rmrr, bdf, idx)            \
     list_for_each_entry(rmrr, &acpi_rmrr_units, list)   \
         /* assume there never is a bdf == 0 */          \
         for (idx = 0; (bdf = rmrr->scope.devices[idx]) && \
                  idx < rmrr->scope.devices_cnt; idx++)

So,
     for_each_rmrr_device ( rmrr, bdf, i )
     {
         rc = func(...);
         /* Hit this entry so just go next. */
         if ( rc > 0 )
             i = rmrr->scope.devices_cnt;

If you don't intend to reset something of this internal working, its 
hard to go next rmrr entry. Maybe you already have idea, so could you 
give me some hints?

> should not special case 1 - just return when rc is negative and skip
> the rest of the current RMRR when it's positive. And of course make
> the function's final return value predictable.
>

Like this,

         /* Hit this entry so just go next. */
         if ( rc > 0 )
             xxxx;
         else if ( rc < 0 )
             return rc;
     }

     return 0;

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:12:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08:12:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrMr0-0003iq-1d; Thu, 20 Nov 2014 08:12:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XrMqy-0003ib-4Z
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 08:12:36 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	F3/A9-02712-372AD645; Thu, 20 Nov 2014 08:12:35 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416471153!13662351!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3974 invoked from network); 20 Nov 2014 08:12:34 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-27.messagelabs.com with SMTP;
	20 Nov 2014 08:12:34 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 20 Nov 2014 00:12:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,422,1413270000"; d="scan'208";a="635045112"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.128])
	([10.238.130.128])
	by fmsmga002.fm.intel.com with ESMTP; 20 Nov 2014 00:12:10 -0800
Message-ID: <546DA259.10609@intel.com>
Date: Thu, 20 Nov 2014 16:12:09 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
	<546B20910200007800048AC0@mail.emea.novell.com>
	<546BF1AD.4010801@intel.com>
	<546DA6CB02000078000492C5@mail.emea.novell.com>
In-Reply-To: <546DA6CB02000078000492C5@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/20 15:31, Jan Beulich wrote:
>>>> On 19.11.14 at 02:26, <tiejun.chen@intel.com> wrote:
>>>> So without lookuping devices[i], how can we call func() for each sbdf as
>>>> you mentioned?
>>>
>>> You've got both rmrr and bdf in the body of for_each_rmrr_device().
>>> After all - as I said - you just open-coded it.
>>>
>>
>> Yeah, so change this again,
>>
>> int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>> {
>>       struct acpi_rmrr_unit *rmrr;
>>       int rc = 0;
>>       unsigned int i;
>>       u16 bdf;
>>
>>       for_each_rmrr_device ( rmrr, bdf, i )
>>       {
>>           rc = func(PFN_DOWN(rmrr->base_address),
>>                              PFN_UP(rmrr->end_address) -
>>                               PFN_DOWN(rmrr->base_address),
>>                              PCI_SBDF(rmrr->segment, bdf),
>>                             ctxt);
>>           /* Hit this entry so just go next. */
>>           if ( rc == 1 )
>>               i = rmrr->scope.devices_cnt;
>>           else if ( rc < 0 )
>>               return rc;
>>       }
>>
>>       return rc;
>> }
>
> Better. Another improvement would be make it not depend on the
> internal workings of for_each_rmrr_device()... And in any case you

Yes but as you see,

#define for_each_rmrr_device(rmrr, bdf, idx)            \
     list_for_each_entry(rmrr, &acpi_rmrr_units, list)   \
         /* assume there never is a bdf == 0 */          \
         for (idx = 0; (bdf = rmrr->scope.devices[idx]) && \
                  idx < rmrr->scope.devices_cnt; idx++)

So,
     for_each_rmrr_device ( rmrr, bdf, i )
     {
         rc = func(...);
         /* Hit this entry so just go next. */
         if ( rc > 0 )
             i = rmrr->scope.devices_cnt;

If you don't intend to reset something of this internal working, its 
hard to go next rmrr entry. Maybe you already have idea, so could you 
give me some hints?

> should not special case 1 - just return when rc is negative and skip
> the rest of the current RMRR when it's positive. And of course make
> the function's final return value predictable.
>

Like this,

         /* Hit this entry so just go next. */
         if ( rc > 0 )
             xxxx;
         else if ( rc < 0 )
             return rc;
     }

     return 0;

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:15:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08: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 1XrMtI-0003sI-K1; Thu, 20 Nov 2014 08:15:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linxingnku@gmail.com>) id 1XrARE-0001Hc-8J
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 18:57:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	95/BA-09936-708EC645; Wed, 19 Nov 2014 18:57:11 +0000
X-Env-Sender: linxingnku@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416423430!13976746!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30888 invoked from network); 19 Nov 2014 18:57:10 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 18:57:10 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so1627908wgg.15
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 10:57:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=OG3VBxTvUqkYXN5f1KnUhaj+zGefLLuApca8f+wzHRg=;
	b=Cck1WdvQkvB/ZYlKL/O8aRFIRq1OdHfvF9m6EHv8xx+GUZEWxXsOH7WFuMHrbvbbU/
	SyggAKeAWt2KC/bUUnrbtAXQndR8BHzVPBerenUD4y4FVbuDfLYrhhWNA2NAhVznDkjG
	83EORumZC+8wYc5CMw4/rHL4m0CjewD6qWCi7HJWL/7KJ2UZ2ispBTjhJS0xxqkYOM52
	uFyA1Ihqa2ZclUSvlZZ8QAAlAQWEnA8vW1JkNBv+mdeVIvuouoIeIpAFwFuQfpyUyPk7
	pAqyX/F78tVrp2t4NxFhEAoao3RpX6eMES4Z9zPm6ID39w7te1yFHl4zbpq7zdM9Jh34
	c6gQ==
MIME-Version: 1.0
X-Received: by 10.180.96.106 with SMTP id dr10mr8295865wib.70.1416423430115;
	Wed, 19 Nov 2014 10:57:10 -0800 (PST)
Received: by 10.27.132.86 with HTTP; Wed, 19 Nov 2014 10:57:10 -0800 (PST)
In-Reply-To: <1416227964.5466.12.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
Date: Wed, 19 Nov 2014 11:57:10 -0700
Message-ID: <CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
From: Xing Lin <linxingnku@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Thu, 20 Nov 2014 08:14:59 +0000
Cc: xen-devel@lists.xen.org,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0569428062494274379=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0569428062494274379==
Content-Type: multipart/alternative; boundary=f46d04182702675a3405083ac713

--f46d04182702675a3405083ac713
Content-Type: text/plain; charset=UTF-8

Hi Ian,

Both of your two points are valid. There is no need to install
virt-manager. And the patch to start a qemu process in /etc/init.d/xen
seems to be enough for launching instances from horizon. I have updated the
wiki page.  Please review it at

http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno

Thanks, Ian!

-Xing

On Mon, Nov 17, 2014 at 5:39 AM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:
> > Hi,
> >
> >
> > The wiki page is ready. I am not sure whether I am using the correct
> > format or not. Please let me know if any changes are need. Thanks,
> >
> >
> > http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
>
> Thanks for this. WRT the need to install virt manager to avoid the
> "cannot open shared object file" issue I expect just running "ldconfig"
> would have worked instead.
>
> It would also be good to understand why it is necessary to install from
> source. Was it just the lack of the xencommons initscript? Debian and
> Ubuntu have their own initscripts and don't reuse the xencommons script.
> However it should be fairly easy to add the necessary commands to start
> qemu to /etc/init.d/xen instead of rebuilding from source.
>
> I'd expect just adding to the end of the "start)" section of the script
> to work. e.g.
>
>                 *) log_end_msg 1; exit ;;
>         esac
>         log_end_msg 0
> +       /usr/local/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name
> dom0 -nographic -M xenpv -daemonize \
> +          -monitor /dev/null -serial /dev/null -parallel /dev/null \
> +          -pidfile /var/run/qemu-xen-dom0.pid
>         ;;
>   stop)
>         capability_check
>         case "$?" in
>                 0) ;;
>
> (nb, that's not a real patch, I just typed it into my mail client as is)
>
> If you can confirm that this works then I can try and get this fixed in
> Debian at least.
>
> Ian.
>
>

--f46d04182702675a3405083ac713
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Ian,<div><br></div><div>Both of your two points are val=
id. There is no need to install virt-manager. And the patch to start a qemu=
 process in /etc/init.d/xen seems to be enough for launching instances from=
 horizon. I have updated the wiki page.=C2=A0 Please review it at=C2=A0</di=
v><div><br><div class=3D"gmail_extra"><a href=3D"http://wiki.xenproject.org=
/wiki/Xen_via_libvirt_for_OpenStack_juno">http://wiki.xenproject.org/wiki/X=
en_via_libvirt_for_OpenStack_juno</a></div><div class=3D"gmail_extra"><br><=
/div><div class=3D"gmail_extra">Thanks, Ian!</div><div class=3D"gmail_extra=
"><br></div><div class=3D"gmail_extra">-Xing</div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Mon, Nov 17, 2014 at 5:39 AM, Ian Campb=
ell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=
=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><span class=3D"">On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt;<br>
&gt; The wiki page is ready. I am not sure whether I am using the correct<b=
r>
&gt; format or not. Please let me know if any changes are need. Thanks,<br>
&gt;<br>
&gt;<br>
&gt; <a href=3D"http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenSta=
ck_juno" target=3D"_blank">http://wiki.xenproject.org/wiki/Xen_via_libvirt_=
for_OpenStack_juno</a><br>
<br>
</span>Thanks for this. WRT the need to install virt manager to avoid the<b=
r>
&quot;cannot open shared object file&quot; issue I expect just running &quo=
t;ldconfig&quot;<br>
would have worked instead.<br>
<br>
It would also be good to understand why it is necessary to install from<br>
source. Was it just the lack of the xencommons initscript? Debian and<br>
Ubuntu have their own initscripts and don&#39;t reuse the xencommons script=
.<br>
However it should be fairly easy to add the necessary commands to start<br>
qemu to /etc/init.d/xen instead of rebuilding from source.<br>
<br>
I&#39;d expect just adding to the end of the &quot;start)&quot; section of =
the script<br>
to work. e.g.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *) log_end_msg 1; e=
xit ;;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 esac<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 log_end_msg 0<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/local/bin/qemu-system-i386 -xen-domid 0 -x=
en-attach -name dom0 -nographic -M xenpv -daemonize \<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -monitor /dev/null -serial /dev/null -p=
arallel /dev/null \<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -pidfile /var/run/qemu-xen-dom0.pid<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;;<br>
=C2=A0 stop)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 capability_check<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case &quot;$?&quot; in<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0) ;;<br>
<br>
(nb, that&#39;s not a real patch, I just typed it into my mail client as is=
)<br>
<br>
If you can confirm that this works then I can try and get this fixed in<br>
Debian at least.<br>
<span class=3D""><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><br></div></div></div>

--f46d04182702675a3405083ac713--


--===============0569428062494274379==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0569428062494274379==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 08:15:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08: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 1XrMtI-0003sI-K1; Thu, 20 Nov 2014 08:15:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linxingnku@gmail.com>) id 1XrARE-0001Hc-8J
	for xen-devel@lists.xen.org; Wed, 19 Nov 2014 18:57:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	95/BA-09936-708EC645; Wed, 19 Nov 2014 18:57:11 +0000
X-Env-Sender: linxingnku@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416423430!13976746!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30888 invoked from network); 19 Nov 2014 18:57:10 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2014 18:57:10 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so1627908wgg.15
	for <xen-devel@lists.xen.org>; Wed, 19 Nov 2014 10:57:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=OG3VBxTvUqkYXN5f1KnUhaj+zGefLLuApca8f+wzHRg=;
	b=Cck1WdvQkvB/ZYlKL/O8aRFIRq1OdHfvF9m6EHv8xx+GUZEWxXsOH7WFuMHrbvbbU/
	SyggAKeAWt2KC/bUUnrbtAXQndR8BHzVPBerenUD4y4FVbuDfLYrhhWNA2NAhVznDkjG
	83EORumZC+8wYc5CMw4/rHL4m0CjewD6qWCi7HJWL/7KJ2UZ2ispBTjhJS0xxqkYOM52
	uFyA1Ihqa2ZclUSvlZZ8QAAlAQWEnA8vW1JkNBv+mdeVIvuouoIeIpAFwFuQfpyUyPk7
	pAqyX/F78tVrp2t4NxFhEAoao3RpX6eMES4Z9zPm6ID39w7te1yFHl4zbpq7zdM9Jh34
	c6gQ==
MIME-Version: 1.0
X-Received: by 10.180.96.106 with SMTP id dr10mr8295865wib.70.1416423430115;
	Wed, 19 Nov 2014 10:57:10 -0800 (PST)
Received: by 10.27.132.86 with HTTP; Wed, 19 Nov 2014 10:57:10 -0800 (PST)
In-Reply-To: <1416227964.5466.12.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
Date: Wed, 19 Nov 2014 11:57:10 -0700
Message-ID: <CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
From: Xing Lin <linxingnku@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Thu, 20 Nov 2014 08:14:59 +0000
Cc: xen-devel@lists.xen.org,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0569428062494274379=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0569428062494274379==
Content-Type: multipart/alternative; boundary=f46d04182702675a3405083ac713

--f46d04182702675a3405083ac713
Content-Type: text/plain; charset=UTF-8

Hi Ian,

Both of your two points are valid. There is no need to install
virt-manager. And the patch to start a qemu process in /etc/init.d/xen
seems to be enough for launching instances from horizon. I have updated the
wiki page.  Please review it at

http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno

Thanks, Ian!

-Xing

On Mon, Nov 17, 2014 at 5:39 AM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:
> > Hi,
> >
> >
> > The wiki page is ready. I am not sure whether I am using the correct
> > format or not. Please let me know if any changes are need. Thanks,
> >
> >
> > http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
>
> Thanks for this. WRT the need to install virt manager to avoid the
> "cannot open shared object file" issue I expect just running "ldconfig"
> would have worked instead.
>
> It would also be good to understand why it is necessary to install from
> source. Was it just the lack of the xencommons initscript? Debian and
> Ubuntu have their own initscripts and don't reuse the xencommons script.
> However it should be fairly easy to add the necessary commands to start
> qemu to /etc/init.d/xen instead of rebuilding from source.
>
> I'd expect just adding to the end of the "start)" section of the script
> to work. e.g.
>
>                 *) log_end_msg 1; exit ;;
>         esac
>         log_end_msg 0
> +       /usr/local/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name
> dom0 -nographic -M xenpv -daemonize \
> +          -monitor /dev/null -serial /dev/null -parallel /dev/null \
> +          -pidfile /var/run/qemu-xen-dom0.pid
>         ;;
>   stop)
>         capability_check
>         case "$?" in
>                 0) ;;
>
> (nb, that's not a real patch, I just typed it into my mail client as is)
>
> If you can confirm that this works then I can try and get this fixed in
> Debian at least.
>
> Ian.
>
>

--f46d04182702675a3405083ac713
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Ian,<div><br></div><div>Both of your two points are val=
id. There is no need to install virt-manager. And the patch to start a qemu=
 process in /etc/init.d/xen seems to be enough for launching instances from=
 horizon. I have updated the wiki page.=C2=A0 Please review it at=C2=A0</di=
v><div><br><div class=3D"gmail_extra"><a href=3D"http://wiki.xenproject.org=
/wiki/Xen_via_libvirt_for_OpenStack_juno">http://wiki.xenproject.org/wiki/X=
en_via_libvirt_for_OpenStack_juno</a></div><div class=3D"gmail_extra"><br><=
/div><div class=3D"gmail_extra">Thanks, Ian!</div><div class=3D"gmail_extra=
"><br></div><div class=3D"gmail_extra">-Xing</div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Mon, Nov 17, 2014 at 5:39 AM, Ian Campb=
ell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=
=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><span class=3D"">On Fri, 2014-11-14 at 21:10 -0700, Xing Lin wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt;<br>
&gt; The wiki page is ready. I am not sure whether I am using the correct<b=
r>
&gt; format or not. Please let me know if any changes are need. Thanks,<br>
&gt;<br>
&gt;<br>
&gt; <a href=3D"http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenSta=
ck_juno" target=3D"_blank">http://wiki.xenproject.org/wiki/Xen_via_libvirt_=
for_OpenStack_juno</a><br>
<br>
</span>Thanks for this. WRT the need to install virt manager to avoid the<b=
r>
&quot;cannot open shared object file&quot; issue I expect just running &quo=
t;ldconfig&quot;<br>
would have worked instead.<br>
<br>
It would also be good to understand why it is necessary to install from<br>
source. Was it just the lack of the xencommons initscript? Debian and<br>
Ubuntu have their own initscripts and don&#39;t reuse the xencommons script=
.<br>
However it should be fairly easy to add the necessary commands to start<br>
qemu to /etc/init.d/xen instead of rebuilding from source.<br>
<br>
I&#39;d expect just adding to the end of the &quot;start)&quot; section of =
the script<br>
to work. e.g.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *) log_end_msg 1; e=
xit ;;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 esac<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 log_end_msg 0<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/local/bin/qemu-system-i386 -xen-domid 0 -x=
en-attach -name dom0 -nographic -M xenpv -daemonize \<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -monitor /dev/null -serial /dev/null -p=
arallel /dev/null \<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -pidfile /var/run/qemu-xen-dom0.pid<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;;<br>
=C2=A0 stop)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 capability_check<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case &quot;$?&quot; in<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0) ;;<br>
<br>
(nb, that&#39;s not a real patch, I just typed it into my mail client as is=
)<br>
<br>
If you can confirm that this works then I can try and get this fixed in<br>
Debian at least.<br>
<span class=3D""><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><br></div></div></div>

--f46d04182702675a3405083ac713--


--===============0569428062494274379==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0569428062494274379==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 08:52:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrNT5-0004Kl-6F; Thu, 20 Nov 2014 08:51:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrNT3-0004Ke-Lv
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 08:51:57 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	8D/65-25714-CABAD645; Thu, 20 Nov 2014 08:51:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416473516!9516949!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32608 invoked from network); 20 Nov 2014 08:51:56 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 08:51:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 08:51:55 +0000
Message-Id: <546DB9BC020000780004934F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 08:51:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Simon Martin" <furryfuttock@gmail.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
	<546B86990200007800048DBF@mail.emea.novell.com>
	<6916092.20141119121209@gmail.com>
In-Reply-To: <6916092.20141119121209@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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 19.11.14 at 16:12, <furryfuttock@gmail.com> wrote:
> This   is  getting  more  interesting.  It  seems  that  something  is
> overwriting the pci-back configuration data.
> 
> Starting  from a fresh reboot I checked the Dom0 pci configuration and
> got this:
> 
> root@smartin-xen:~# lspci -s 00:19.0 -x
> 00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
> 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> 30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00
> 
> I then start/stop my DomU and checked the Dom0 pci configuration again
> and got this:
> 
> root@smartin-xen:~# lspci -s 00:19.0 -x
> 00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
> 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> 30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00

I.e. the BARs got zapped. Not something that should happen. And
certainly explaining why you would not be able to use the device a
second time.

> Inside  my  DomU I added code to print the PCI configuration registers
> and what I get after restarting the DomU is:
> 
> (d18) 14:57:04.042 src/e1000e.c@00150: 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> (d18) 14:57:04.042 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> (d18) 14:57:04.042 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 14:57:04.043 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> (d18) 14:57:04.043 src/e1000e.c@00324: Enable PCI Memory Access
> (d18) 14:57:05.043 src/e1000e.c@00150: 00: 86 80 59 15 03 00 10 00 04 00 00 02 00 00 00 00
> (d18) 14:57:05.044 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00  00 00 00 00 00
> (d18) 14:57:05.044 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 14:57:05.045 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> 
> As  you can see the pci configuration read from the pci-back driver by
> my DomU is different to the data in the Dom0 pci configuration!

The only byte that is different afaics is the one at 0x3c, and that's
fine. Plus comparing with what Dom0 sees before the guest was
started or after the guest was stopped isn't really meaningful -
instead you'd want to compare against what Dom0 sees while the
guest is running.

But in the end your problem may have to do with the various
warnings issued regarding unrecognized DMAR table data, all
relating to the use of namespaces that our code doesn't have
support for.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:52:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrNST-0004JV-Nw; Thu, 20 Nov 2014 08:51:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XrNSS-0004JQ-G7
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 08:51:20 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	99/D1-19763-78BAD645; Thu, 20 Nov 2014 08:51:19 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416473477!9516777!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27845 invoked from network); 20 Nov 2014 08:51:18 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-206.messagelabs.com with SMTP;
	20 Nov 2014 08:51:18 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 20 Nov 2014 00:51:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,422,1413270000"; d="scan'208";a="610981964"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by orsmga001.jf.intel.com with ESMTP; 20 Nov 2014 00:51:15 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 20 Nov 2014 16:51:11 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id
	14.03.0195.001; Thu, 20 Nov 2014 16:51:09 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
	guest memory is out of reserved device memory maps
Thread-Index: AQHP/l8LtnOoOMCxBUyde78SnbhphJxnpV8ggAF+RLD//4qpgIAAjifg
Date: Thu, 20 Nov 2014 08:51:08 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FB636@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
	<546DAE8F020000780004930A@mail.emea.novell.com>
In-Reply-To: <546DAE8F020000780004930A@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Chen,
	Tiejun" <tiejun.chen@intel.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Thursday, November 20, 2014 4:04 PM
> 
> >>> On 20.11.14 at 08:45, <kevin.tian@intel.com> wrote:
> > Yang and I did some discussion here. We understand your point to
> > avoid introducing new interface if we can leverage existing code.
> > However it's not a trivial effort to move device assignment before
> > populating p2m, and there is no other benefit of doing so except
> > for this purpose. So we'd not suggest this way.
> 
> "It's not a trivial effort" is pretty vague: What specifically is it that
> makes this difficult? I wouldn't expect there to be any strong
> dependencies on the ordering of these two operations...

I'll leave to Yang to answer this part, who did a detail investigation
on that, e.g. on IOMMU page table setup, etc. But what really matters
here is not only about complexity, but also flexibility. Doing so will 
tie the policy to assigned device only, which removes the option to
support hotpluggable device.

> 
> > Current option sounds a reasonable one, i.e. passing a list of BDFs
> > assigned to this VM before populating p2m, and then having
> > hypervisor to filter out reserved regions associated with those
> > BDFs. This way libxc teaches Xen to create reserved regions once,
> > and then later the filtered info is returned upon query.
> 
> Reasonable, but partly redundant. The positive aspect being that
> it permits this list and the list of actually being assigned devices to
> be different, i.e. allowing holes to be set up for devices that only
> _may_ get assigned at some point.

redundant if we think the list only exactly matching the statically 
assigned devices. but that's just current point.

reasonable if we think there may be other policies impacting the list
(e.g. if hotplugable device may have a config option and then we have
a potential list larger than static assigned devices). From this angle
I think the new interface actually makes sense for this very purpose.

> 
> > The limitation of wasted memory due to confliction can be
> > mitigated, and we considered further enhancement can be made
> > later in libxc that when populating p2m, the reserved regions
> > can be skipped explicitly at initial p2m creation phase and then
> > there would be no waste at all. But this optimization takes some
> > time and can be built incrementally on current patch and interface,
> > post 4.5 release. For now let's focus on the very correctness first.
> 
> I agree, as long as the optimization part doesn't get dropped after
> the correctness part went in.

definitely. after putting so much effort in last months from Tiejun, 
you can see our willingness to make it correct and continuously 
improved.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:52:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrNST-0004JV-Nw; Thu, 20 Nov 2014 08:51:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XrNSS-0004JQ-G7
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 08:51:20 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	99/D1-19763-78BAD645; Thu, 20 Nov 2014 08:51:19 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416473477!9516777!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27845 invoked from network); 20 Nov 2014 08:51:18 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-206.messagelabs.com with SMTP;
	20 Nov 2014 08:51:18 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 20 Nov 2014 00:51:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,422,1413270000"; d="scan'208";a="610981964"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by orsmga001.jf.intel.com with ESMTP; 20 Nov 2014 00:51:15 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 20 Nov 2014 16:51:11 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id
	14.03.0195.001; Thu, 20 Nov 2014 16:51:09 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
	guest memory is out of reserved device memory maps
Thread-Index: AQHP/l8LtnOoOMCxBUyde78SnbhphJxnpV8ggAF+RLD//4qpgIAAjifg
Date: Thu, 20 Nov 2014 08:51:08 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FB636@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
	<546DAE8F020000780004930A@mail.emea.novell.com>
In-Reply-To: <546DAE8F020000780004930A@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Chen,
	Tiejun" <tiejun.chen@intel.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Thursday, November 20, 2014 4:04 PM
> 
> >>> On 20.11.14 at 08:45, <kevin.tian@intel.com> wrote:
> > Yang and I did some discussion here. We understand your point to
> > avoid introducing new interface if we can leverage existing code.
> > However it's not a trivial effort to move device assignment before
> > populating p2m, and there is no other benefit of doing so except
> > for this purpose. So we'd not suggest this way.
> 
> "It's not a trivial effort" is pretty vague: What specifically is it that
> makes this difficult? I wouldn't expect there to be any strong
> dependencies on the ordering of these two operations...

I'll leave to Yang to answer this part, who did a detail investigation
on that, e.g. on IOMMU page table setup, etc. But what really matters
here is not only about complexity, but also flexibility. Doing so will 
tie the policy to assigned device only, which removes the option to
support hotpluggable device.

> 
> > Current option sounds a reasonable one, i.e. passing a list of BDFs
> > assigned to this VM before populating p2m, and then having
> > hypervisor to filter out reserved regions associated with those
> > BDFs. This way libxc teaches Xen to create reserved regions once,
> > and then later the filtered info is returned upon query.
> 
> Reasonable, but partly redundant. The positive aspect being that
> it permits this list and the list of actually being assigned devices to
> be different, i.e. allowing holes to be set up for devices that only
> _may_ get assigned at some point.

redundant if we think the list only exactly matching the statically 
assigned devices. but that's just current point.

reasonable if we think there may be other policies impacting the list
(e.g. if hotplugable device may have a config option and then we have
a potential list larger than static assigned devices). From this angle
I think the new interface actually makes sense for this very purpose.

> 
> > The limitation of wasted memory due to confliction can be
> > mitigated, and we considered further enhancement can be made
> > later in libxc that when populating p2m, the reserved regions
> > can be skipped explicitly at initial p2m creation phase and then
> > there would be no waste at all. But this optimization takes some
> > time and can be built incrementally on current patch and interface,
> > post 4.5 release. For now let's focus on the very correctness first.
> 
> I agree, as long as the optimization part doesn't get dropped after
> the correctness part went in.

definitely. after putting so much effort in last months from Tiejun, 
you can see our willingness to make it correct and continuously 
improved.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:52:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrNT5-0004Kl-6F; Thu, 20 Nov 2014 08:51:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrNT3-0004Ke-Lv
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 08:51:57 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	8D/65-25714-CABAD645; Thu, 20 Nov 2014 08:51:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416473516!9516949!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32608 invoked from network); 20 Nov 2014 08:51:56 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 08:51:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 08:51:55 +0000
Message-Id: <546DB9BC020000780004934F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 08:51:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Simon Martin" <furryfuttock@gmail.com>
References: <198478230.20141113102921@gmail.com>
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
	<546B86990200007800048DBF@mail.emea.novell.com>
	<6916092.20141119121209@gmail.com>
In-Reply-To: <6916092.20141119121209@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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 19.11.14 at 16:12, <furryfuttock@gmail.com> wrote:
> This   is  getting  more  interesting.  It  seems  that  something  is
> overwriting the pci-back configuration data.
> 
> Starting  from a fresh reboot I checked the Dom0 pci configuration and
> got this:
> 
> root@smartin-xen:~# lspci -s 00:19.0 -x
> 00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
> 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> 30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00
> 
> I then start/stop my DomU and checked the Dom0 pci configuration again
> and got this:
> 
> root@smartin-xen:~# lspci -s 00:19.0 -x
> 00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
> 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> 30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00

I.e. the BARs got zapped. Not something that should happen. And
certainly explaining why you would not be able to use the device a
second time.

> Inside  my  DomU I added code to print the PCI configuration registers
> and what I get after restarting the DomU is:
> 
> (d18) 14:57:04.042 src/e1000e.c@00150: 00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00
> (d18) 14:57:04.042 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00 00 00 00 00 00
> (d18) 14:57:04.042 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 14:57:04.043 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> (d18) 14:57:04.043 src/e1000e.c@00324: Enable PCI Memory Access
> (d18) 14:57:05.043 src/e1000e.c@00150: 00: 86 80 59 15 03 00 10 00 04 00 00 02 00 00 00 00
> (d18) 14:57:05.044 src/e1000e.c@00150: 10: 00 00 d0 f7 00 c0 d3 f7 81 f0 00  00 00 00 00 00
> (d18) 14:57:05.044 src/e1000e.c@00150: 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 54 20
> (d18) 14:57:05.045 src/e1000e.c@00150: 30: 00 00 00 00 c8 00 00 00 00 00 00 00 14 01 00 00
> 
> As  you can see the pci configuration read from the pci-back driver by
> my DomU is different to the data in the Dom0 pci configuration!

The only byte that is different afaics is the one at 0x3c, and that's
fine. Plus comparing with what Dom0 sees before the guest was
started or after the guest was stopped isn't really meaningful -
instead you'd want to compare against what Dom0 sees while the
guest is running.

But in the end your problem may have to do with the various
warnings issued regarding unrecognized DMAR table data, all
relating to the use of namespaces that our code doesn't have
support for.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:59:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08: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 1XrNaC-0004gD-DU; Thu, 20 Nov 2014 08:59:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrNaB-0004g8-Aa
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 08:59:19 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	33/68-25276-66DAD645; Thu, 20 Nov 2014 08:59:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416473957!14048192!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16781 invoked from network); 20 Nov 2014 08:59:18 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 08:59:18 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 08:59:17 +0000
Message-Id: <546DBB760200007800049372@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 08:59:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
	<546B20910200007800048AC0@mail.emea.novell.com>
	<546BF1AD.4010801@intel.com>
	<546DA6CB02000078000492C5@mail.emea.novell.com>
	<546DA259.10609@intel.com>
In-Reply-To: <546DA259.10609@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 09:12, <tiejun.chen@intel.com> wrote:
> On 2014/11/20 15:31, Jan Beulich wrote:
>>>>> On 19.11.14 at 02:26, <tiejun.chen@intel.com> wrote:
>>> int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>> {
>>>       struct acpi_rmrr_unit *rmrr;
>>>       int rc = 0;
>>>       unsigned int i;
>>>       u16 bdf;
>>>
>>>       for_each_rmrr_device ( rmrr, bdf, i )
>>>       {
>>>           rc = func(PFN_DOWN(rmrr->base_address),
>>>                              PFN_UP(rmrr->end_address) -
>>>                               PFN_DOWN(rmrr->base_address),
>>>                              PCI_SBDF(rmrr->segment, bdf),
>>>                             ctxt);
>>>           /* Hit this entry so just go next. */
>>>           if ( rc == 1 )
>>>               i = rmrr->scope.devices_cnt;
>>>           else if ( rc < 0 )
>>>               return rc;
>>>       }
>>>
>>>       return rc;
>>> }
>>
>> Better. Another improvement would be make it not depend on the
>> internal workings of for_each_rmrr_device()... And in any case you
> 
> Yes but as you see,
> 
> #define for_each_rmrr_device(rmrr, bdf, idx)            \
>      list_for_each_entry(rmrr, &acpi_rmrr_units, list)   \
>          /* assume there never is a bdf == 0 */          \
>          for (idx = 0; (bdf = rmrr->scope.devices[idx]) && \
>                   idx < rmrr->scope.devices_cnt; idx++)
> 
> So,
>      for_each_rmrr_device ( rmrr, bdf, i )
>      {
>          rc = func(...);
>          /* Hit this entry so just go next. */
>          if ( rc > 0 )
>              i = rmrr->scope.devices_cnt;
> 
> If you don't intend to reset something of this internal working, its 
> hard to go next rmrr entry. Maybe you already have idea, so could you 
> give me some hints?

Have a second struct acpi_rmrr_unit pointer, starting out as NULL
and getting set to the current one when the callback returns a
positive value. Skip further iterations as long as both pointers
match.

>> should not special case 1 - just return when rc is negative and skip
>> the rest of the current RMRR when it's positive. And of course make
>> the function's final return value predictable.
>>
> 
> Like this,
> 
>          /* Hit this entry so just go next. */
>          if ( rc > 0 )
>              xxxx;
>          else if ( rc < 0 )
>              return rc;
>      }

Yes, albeit swapping the order (and dropping the "else" along with
adding unlikely() to the error case) would be preferred.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 08:59:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 08: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 1XrNaC-0004gD-DU; Thu, 20 Nov 2014 08:59:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrNaB-0004g8-Aa
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 08:59:19 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	33/68-25276-66DAD645; Thu, 20 Nov 2014 08:59:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416473957!14048192!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16781 invoked from network); 20 Nov 2014 08:59:18 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 08:59:18 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 08:59:17 +0000
Message-Id: <546DBB760200007800049372@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 08:59:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
	<546B20910200007800048AC0@mail.emea.novell.com>
	<546BF1AD.4010801@intel.com>
	<546DA6CB02000078000492C5@mail.emea.novell.com>
	<546DA259.10609@intel.com>
In-Reply-To: <546DA259.10609@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 09:12, <tiejun.chen@intel.com> wrote:
> On 2014/11/20 15:31, Jan Beulich wrote:
>>>>> On 19.11.14 at 02:26, <tiejun.chen@intel.com> wrote:
>>> int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>> {
>>>       struct acpi_rmrr_unit *rmrr;
>>>       int rc = 0;
>>>       unsigned int i;
>>>       u16 bdf;
>>>
>>>       for_each_rmrr_device ( rmrr, bdf, i )
>>>       {
>>>           rc = func(PFN_DOWN(rmrr->base_address),
>>>                              PFN_UP(rmrr->end_address) -
>>>                               PFN_DOWN(rmrr->base_address),
>>>                              PCI_SBDF(rmrr->segment, bdf),
>>>                             ctxt);
>>>           /* Hit this entry so just go next. */
>>>           if ( rc == 1 )
>>>               i = rmrr->scope.devices_cnt;
>>>           else if ( rc < 0 )
>>>               return rc;
>>>       }
>>>
>>>       return rc;
>>> }
>>
>> Better. Another improvement would be make it not depend on the
>> internal workings of for_each_rmrr_device()... And in any case you
> 
> Yes but as you see,
> 
> #define for_each_rmrr_device(rmrr, bdf, idx)            \
>      list_for_each_entry(rmrr, &acpi_rmrr_units, list)   \
>          /* assume there never is a bdf == 0 */          \
>          for (idx = 0; (bdf = rmrr->scope.devices[idx]) && \
>                   idx < rmrr->scope.devices_cnt; idx++)
> 
> So,
>      for_each_rmrr_device ( rmrr, bdf, i )
>      {
>          rc = func(...);
>          /* Hit this entry so just go next. */
>          if ( rc > 0 )
>              i = rmrr->scope.devices_cnt;
> 
> If you don't intend to reset something of this internal working, its 
> hard to go next rmrr entry. Maybe you already have idea, so could you 
> give me some hints?

Have a second struct acpi_rmrr_unit pointer, starting out as NULL
and getting set to the current one when the callback returns a
positive value. Skip further iterations as long as both pointers
match.

>> should not special case 1 - just return when rc is negative and skip
>> the rest of the current RMRR when it's positive. And of course make
>> the function's final return value predictable.
>>
> 
> Like this,
> 
>          /* Hit this entry so just go next. */
>          if ( rc > 0 )
>              xxxx;
>          else if ( rc < 0 )
>              return rc;
>      }

Yes, albeit swapping the order (and dropping the "else" along with
adding unlikely() to the error case) would be preferred.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:01:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 09:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrNbt-0004mq-0A; Thu, 20 Nov 2014 09:01:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrNbr-0004mk-8N
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 09:01:03 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	5A/65-07724-ECDAD645; Thu, 20 Nov 2014 09:01:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416474060!12613077!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12132 invoked from network); 20 Nov 2014 09:01:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 09:01:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="193197914"
Message-ID: <1416474053.29243.55.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Donald D. Dugger" <donald.d.dugger@intel.com>
Date: Thu, 20 Nov 2014 09:00:53 +0000
In-Reply-To: <20141119194611.GA2600@tlaloc.n0ano.com>
References: <20141119194611.GA2600@tlaloc.n0ano.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: allen.m.kay@intel.com, eddie.dong@intel.com, n0ano@n0ano.com,
	xen-devel@lists.xen.org, will.auld@intel.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH V3] Decouple SnadyBridge quirk form VTd
 timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 12:46 -0700, Donald D. Dugger wrote:
> Currently the quirk code for SandyBridge uses the VTd timeout value when

You've got a typo in the subject ("SnadyBridge").



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:01:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 09:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrNbt-0004mq-0A; Thu, 20 Nov 2014 09:01:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrNbr-0004mk-8N
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 09:01:03 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	5A/65-07724-ECDAD645; Thu, 20 Nov 2014 09:01:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416474060!12613077!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12132 invoked from network); 20 Nov 2014 09:01:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 09:01:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="193197914"
Message-ID: <1416474053.29243.55.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Donald D. Dugger" <donald.d.dugger@intel.com>
Date: Thu, 20 Nov 2014 09:00:53 +0000
In-Reply-To: <20141119194611.GA2600@tlaloc.n0ano.com>
References: <20141119194611.GA2600@tlaloc.n0ano.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: allen.m.kay@intel.com, eddie.dong@intel.com, n0ano@n0ano.com,
	xen-devel@lists.xen.org, will.auld@intel.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH V3] Decouple SnadyBridge quirk form VTd
 timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 12:46 -0700, Donald D. Dugger wrote:
> Currently the quirk code for SandyBridge uses the VTd timeout value when

You've got a typo in the subject ("SnadyBridge").



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:02:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 09:02:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrNcy-0004vW-Es; Thu, 20 Nov 2014 09:02:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrNcx-0004ug-3K
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 09:02:11 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	5B/BC-01660-21EAD645; Thu, 20 Nov 2014 09:02:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416474128!7110050!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 892 invoked from network); 20 Nov 2014 09:02:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 09:02:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="193198241"
Message-ID: <1416474124.29243.56.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 09:02:04 +0000
In-Reply-To: <20141119211858.GH20440@laptop.dumpdata.com>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329502.17982.28.camel@citrix.com>
	<20141119211858.GH20440@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/4 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 16:18 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 18, 2014 at 04:51:42PM +0000, Ian Campbell wrote:
> > On Tue, 2014-11-18 at 16:44 +0000, Ian Campbell wrote:
> > > These patches:
> > 
> > ... which are also at
> >         git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v1
> 
> I presume you are going to post v2 with Julian's feedback rolled in?

Yes, see <1416410868.29243.39.camel@citrix.com>.

> I took a look at the code and it looks Xen 4.5 material so I am
> OK with it rolling in, but would appreciate another posting just
> to make sure that nothing is amiss.
> 
> Thank you!
> > 
> > Ian.
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:02:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 09:02:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrNcy-0004vW-Es; Thu, 20 Nov 2014 09:02:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrNcx-0004ug-3K
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 09:02:11 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	5B/BC-01660-21EAD645; Thu, 20 Nov 2014 09:02:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416474128!7110050!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 892 invoked from network); 20 Nov 2014 09:02:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 09:02:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="193198241"
Message-ID: <1416474124.29243.56.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 09:02:04 +0000
In-Reply-To: <20141119211858.GH20440@laptop.dumpdata.com>
References: <1416329045.17982.27.camel@citrix.com>
	<1416329502.17982.28.camel@citrix.com>
	<20141119211858.GH20440@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/4 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 16:18 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 18, 2014 at 04:51:42PM +0000, Ian Campbell wrote:
> > On Tue, 2014-11-18 at 16:44 +0000, Ian Campbell wrote:
> > > These patches:
> > 
> > ... which are also at
> >         git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v1
> 
> I presume you are going to post v2 with Julian's feedback rolled in?

Yes, see <1416410868.29243.39.camel@citrix.com>.

> I took a look at the code and it looks Xen 4.5 material so I am
> OK with it rolling in, but would appreciate another posting just
> to make sure that nothing is amiss.
> 
> Thank you!
> > 
> > Ian.
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:03:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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 1XrNeM-00055B-TT; Thu, 20 Nov 2014 09:03:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XrNeM-000551-7v
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 09:03:38 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	3D/4C-24859-96EAD645; Thu, 20 Nov 2014 09:03:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416474216!12672385!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,BODY_RANDOM_LONG,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5286 invoked from network); 20 Nov 2014 09:03:36 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 09:03:36 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416474216; l=2092;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=TmjUVWUNVf/DUQfRGcujgEy5t90=;
	b=YKY010YGKpipJK7i3Ny1HfUEWNFjeMZOdqVI0XCdPkQkD76ATXDTBFd3vpstp86JO3U
	FCEADjoncH7iJ7peoqbnaBljQaCf8Utfo3nfWNp54Wllc2tiwwsvW1gec6XnxR9E+IlJw
	jlywbFzqjqSb917QHHs0Wkay8yM1cDE7wOg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.12 AUTH) with ESMTPSA id C06763qAK93aonu
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 20 Nov 2014 10:03:36 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 50A6950172; Thu, 20 Nov 2014 10:03:36 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Thu, 20 Nov 2014 10:03:31 +0100
Message-Id: <1416474211-8411-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH] INSTALL: correct EXTRA_CFLAGS 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>
MIME-Version: 1.0
Content-Type: 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 already documented configure patch was not applied.
Adjust documentation to describe existing behaviour.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
 INSTALL | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/INSTALL b/INSTALL
index 6bb9d23..656c90a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -128,13 +128,6 @@ original xenstored will be used. Valid names are xenstored and
 oxenstored.
   --with-xenstored=name
 
-Using additional CFLAGS to build tools running in dom0 is required when
-building distro packages. This is the option to pass things like
-RPM_OPT_FLAGS.
-  --with-extra-cflags-tools=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-traditional=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-upstream=EXTRA_CFLAGS
-
 Instead of starting the tools in dom0 with sysv runlevel scripts they
 can also be started by systemd. If this option is enabled xenstored will
 receive the communication socked directly from systemd. So starting it
@@ -241,6 +234,12 @@ QEMU_UPSTREAM_URL=
 QEMU_TRADITIONAL_URL=
 SEABIOS_UPSTREAM_URL=
 
+Using additional CFLAGS to build tools running in dom0 is required when
+building distro packages. This can be used to pass RPM_OPT_FLAGS.
+EXTRA_CFLAGS_XEN_TOOLS=
+EXTRA_CFLAGS_QEMU_TRADITIONAL=
+EXTRA_CFLAGS_QEMU_XEN=
+
 This variable can be used to use DIR/include and DIR/lib during build.
 This is the same as PREPEND_LIB and PREPEND_INCLUDES. APPEND_LIB and
 APPEND_INCLUDES= will be appended to the CFLAGS/LDFLAGS variable.
@@ -310,10 +309,10 @@ sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi
 %build
 export WGET=$(type -P false)
 export GIT=$(type -P false)
+export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
 %configure \
-        --with-extra-cflags-tools="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-traditional="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-upstream="$RPM_OPT_FLAGS" \
         --with-initddir=%{_initddir}
 unset CFLAGS CXXFLAGS FFLAGS LDFLAGS
 make

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:03:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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 1XrNeM-00055B-TT; Thu, 20 Nov 2014 09:03:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XrNeM-000551-7v
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 09:03:38 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	3D/4C-24859-96EAD645; Thu, 20 Nov 2014 09:03:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416474216!12672385!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,BODY_RANDOM_LONG,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5286 invoked from network); 20 Nov 2014 09:03:36 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 09:03:36 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416474216; l=2092;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=TmjUVWUNVf/DUQfRGcujgEy5t90=;
	b=YKY010YGKpipJK7i3Ny1HfUEWNFjeMZOdqVI0XCdPkQkD76ATXDTBFd3vpstp86JO3U
	FCEADjoncH7iJ7peoqbnaBljQaCf8Utfo3nfWNp54Wllc2tiwwsvW1gec6XnxR9E+IlJw
	jlywbFzqjqSb917QHHs0Wkay8yM1cDE7wOg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.12 AUTH) with ESMTPSA id C06763qAK93aonu
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 20 Nov 2014 10:03:36 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 50A6950172; Thu, 20 Nov 2014 10:03:36 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Thu, 20 Nov 2014 10:03:31 +0100
Message-Id: <1416474211-8411-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH] INSTALL: correct EXTRA_CFLAGS 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>
MIME-Version: 1.0
Content-Type: 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 already documented configure patch was not applied.
Adjust documentation to describe existing behaviour.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
 INSTALL | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/INSTALL b/INSTALL
index 6bb9d23..656c90a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -128,13 +128,6 @@ original xenstored will be used. Valid names are xenstored and
 oxenstored.
   --with-xenstored=name
 
-Using additional CFLAGS to build tools running in dom0 is required when
-building distro packages. This is the option to pass things like
-RPM_OPT_FLAGS.
-  --with-extra-cflags-tools=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-traditional=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-upstream=EXTRA_CFLAGS
-
 Instead of starting the tools in dom0 with sysv runlevel scripts they
 can also be started by systemd. If this option is enabled xenstored will
 receive the communication socked directly from systemd. So starting it
@@ -241,6 +234,12 @@ QEMU_UPSTREAM_URL=
 QEMU_TRADITIONAL_URL=
 SEABIOS_UPSTREAM_URL=
 
+Using additional CFLAGS to build tools running in dom0 is required when
+building distro packages. This can be used to pass RPM_OPT_FLAGS.
+EXTRA_CFLAGS_XEN_TOOLS=
+EXTRA_CFLAGS_QEMU_TRADITIONAL=
+EXTRA_CFLAGS_QEMU_XEN=
+
 This variable can be used to use DIR/include and DIR/lib during build.
 This is the same as PREPEND_LIB and PREPEND_INCLUDES. APPEND_LIB and
 APPEND_INCLUDES= will be appended to the CFLAGS/LDFLAGS variable.
@@ -310,10 +309,10 @@ sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi
 %build
 export WGET=$(type -P false)
 export GIT=$(type -P false)
+export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
 %configure \
-        --with-extra-cflags-tools="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-traditional="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-upstream="$RPM_OPT_FLAGS" \
         --with-initddir=%{_initddir}
 unset CFLAGS CXXFLAGS FFLAGS LDFLAGS
 make

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:14:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 09: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.xen.org>)
	id 1XrNo5-0005MP-14; Thu, 20 Nov 2014 09:13:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1XrNo4-0005MH-3W; Thu, 20 Nov 2014 09:13:40 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	88/F4-02698-3C0BD645; Thu, 20 Nov 2014 09:13:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416474817!13681883!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4120 invoked from network); 20 Nov 2014 09:13:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 09:13:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="194723682"
Message-ID: <1416474814.29243.59.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, xen-devel
	<xen-devel@lists.xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 20 Nov 2014 09:13:34 +0000
In-Reply-To: <alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-users@lists.xen.org,
	Jim Fehlig <jfehlig@suse.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 13:00 +0000, Stefano Stabellini wrote:
> On Mon, 17 Nov 2014, Ian Campbell wrote:
> > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > By the way, how many NICs can I apply to a VM?
> > > 
> > > On xen-4.4.0, Using qemu-dm, I can apply 8 NIC to a VM, but using
> > > qemu-system-i386, I can only apply 4 NICs to an VM?
> > > is it normal?
> > 
> > I've no idea, CCing the qemu maintainers.
> > 
> > I'd have expected the number of PV nics to be completely independent of
> > the device mode, so I suppose you mean emulated NICs?
> 
> I can pass 4 emulated NICs maximum, but you can easily reach 8 if you
> use PV NICs instead. Just pass 'type=pv' like this:
> 
> vif=['', '', '', '', 'type=pv', 'type=pv', 'type=pv', 'type=pv']
> 
> it is going to create 4 emulated nics and 4 pv nics. The 4 emulated nics
> also have 4 corresponding pv nics. The emulated nics get disconnected
> soon after boot by the guest operating system (if it has pv drivers
> installed, such as Linux). So overall once the boot sequence is fully
> completed you'll end up with the 8 pv nics that you want.

I wonder if we should do something in (lib)xl such that by default the
first 4 NICs have type LIBXL_NIC_TYPE_VIF_IOEMU (i.e. emulated+PV path)
and the rest have LIBXL_NIC_TYPE_VIF (i.e. PV only).

> BTW the reason for the failure seems to be that QEMU runs out of ram
> (xen: failed to populate ram at 80110000, so
> xc_domain_populate_physmap_exact failed) allocating roms for the rtl8139
> (40000 bytes each). Maybe qemu-trad wasn't loading any roms for rtl8139.
> Interestingly e1000 doesn't need any roms either, so another way around
> this would be to set 'type=e1000' for all the vifs.

Or to use the new option in 4.5 to increase the MMIO space (or is that
not where ROMs end up?)

Do we need to plumb through qemu's optionrom parameter to allow a)
limiting the number of NICs which will try to do PXE and b) allow custom
roms etc?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:14:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 09: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.xen.org>)
	id 1XrNo5-0005MP-14; Thu, 20 Nov 2014 09:13:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1XrNo4-0005MH-3W; Thu, 20 Nov 2014 09:13:40 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	88/F4-02698-3C0BD645; Thu, 20 Nov 2014 09:13:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416474817!13681883!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4120 invoked from network); 20 Nov 2014 09:13:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 09:13:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="194723682"
Message-ID: <1416474814.29243.59.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, xen-devel
	<xen-devel@lists.xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 20 Nov 2014 09:13:34 +0000
In-Reply-To: <alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-users@lists.xen.org,
	Jim Fehlig <jfehlig@suse.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 13:00 +0000, Stefano Stabellini wrote:
> On Mon, 17 Nov 2014, Ian Campbell wrote:
> > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > By the way, how many NICs can I apply to a VM?
> > > 
> > > On xen-4.4.0, Using qemu-dm, I can apply 8 NIC to a VM, but using
> > > qemu-system-i386, I can only apply 4 NICs to an VM?
> > > is it normal?
> > 
> > I've no idea, CCing the qemu maintainers.
> > 
> > I'd have expected the number of PV nics to be completely independent of
> > the device mode, so I suppose you mean emulated NICs?
> 
> I can pass 4 emulated NICs maximum, but you can easily reach 8 if you
> use PV NICs instead. Just pass 'type=pv' like this:
> 
> vif=['', '', '', '', 'type=pv', 'type=pv', 'type=pv', 'type=pv']
> 
> it is going to create 4 emulated nics and 4 pv nics. The 4 emulated nics
> also have 4 corresponding pv nics. The emulated nics get disconnected
> soon after boot by the guest operating system (if it has pv drivers
> installed, such as Linux). So overall once the boot sequence is fully
> completed you'll end up with the 8 pv nics that you want.

I wonder if we should do something in (lib)xl such that by default the
first 4 NICs have type LIBXL_NIC_TYPE_VIF_IOEMU (i.e. emulated+PV path)
and the rest have LIBXL_NIC_TYPE_VIF (i.e. PV only).

> BTW the reason for the failure seems to be that QEMU runs out of ram
> (xen: failed to populate ram at 80110000, so
> xc_domain_populate_physmap_exact failed) allocating roms for the rtl8139
> (40000 bytes each). Maybe qemu-trad wasn't loading any roms for rtl8139.
> Interestingly e1000 doesn't need any roms either, so another way around
> this would be to set 'type=e1000' for all the vifs.

Or to use the new option in 4.5 to increase the MMIO space (or is that
not where ROMs end up?)

Do we need to plumb through qemu's optionrom parameter to allow a)
limiting the number of NICs which will try to do PXE and b) allow custom
roms etc?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 09:31:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrO4M-00065i-Vw; Thu, 20 Nov 2014 09:30:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrO4L-00065d-FN
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 09:30:29 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	F9/A7-26740-4B4BD645; Thu, 20 Nov 2014 09:30:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416475826!12655541!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30009 invoked from network); 20 Nov 2014 09:30:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 09:30:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="194727571"
Message-ID: <1416475824.14429.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Thu, 20 Nov 2014 09:30:24 +0000
In-Reply-To: <CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 11:57 -0700, Xing Lin wrote:
> Hi Ian,
> 
> 
> Both of your two points are valid. There is no need to install
> virt-manager. And the patch to start a qemu process in /etc/init.d/xen
> seems to be enough for launching instances from horizon. I have
> updated the wiki page.  Please review it at 
> 
> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno

Looks much better, thanks!

I think the need to symlink pygrub to /usr/bin should be considered an
openstack bug. I presume nova specifies the absolute path, when it
should just say "pygrub" by default and let the toolstack find the
default one.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 09:31:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrO4M-00065i-Vw; Thu, 20 Nov 2014 09:30:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrO4L-00065d-FN
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 09:30:29 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	F9/A7-26740-4B4BD645; Thu, 20 Nov 2014 09:30:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416475826!12655541!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30009 invoked from network); 20 Nov 2014 09:30:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 09:30:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="194727571"
Message-ID: <1416475824.14429.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Thu, 20 Nov 2014 09:30:24 +0000
In-Reply-To: <CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 11:57 -0700, Xing Lin wrote:
> Hi Ian,
> 
> 
> Both of your two points are valid. There is no need to install
> virt-manager. And the patch to start a qemu process in /etc/init.d/xen
> seems to be enough for launching instances from horizon. I have
> updated the wiki page.  Please review it at 
> 
> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno

Looks much better, thanks!

I think the need to symlink pygrub to /usr/bin should be considered an
openstack bug. I presume nova specifies the absolute path, when it
should just say "pygrub" by default and let the toolstack find the
default one.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:59:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 09:59:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrOVe-0006bL-OO; Thu, 20 Nov 2014 09:58:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrOVd-0006bG-Pf
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 09:58:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E2/2B-09936-15BBD645; Thu, 20 Nov 2014 09:58:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416477519!14129965!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20794 invoked from network); 20 Nov 2014 09:58:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 09:58:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="194733542"
Message-ID: <546DBB4D.9030100@citrix.com>
Date: Thu, 20 Nov 2014 09:58:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>, Chao Peng
	<chao.p.peng@linux.intel.com>
X-DLP: MIA2
Subject: [Xen-devel] Xen-4.5 Testing - Cache Monitoring Technology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 found myself a PSR-capable server and have been having a play
with Xen-4.5

At a first pass, I can get some numbers out:

[root@blob ~]# xl psr-cmt-attach 0
[root@blob ~]# xl psr-cmt-show cache_occupancy
Total RMID: 71
Name                                        ID        Socket 0       
Socket 1
Total L3 Cache Size                                   46080 KB       
46080 KB
Domain-0                                     0        45072
KB            0 KB
[root@blob ~]#

However, I am unable to get any occupancy information for HVM guests. 
Given nothing obvious in the code which would make CMT PV-guest
specific, I presume this is unexpected?

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 09:59:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 09:59:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrOVe-0006bL-OO; Thu, 20 Nov 2014 09:58:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrOVd-0006bG-Pf
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 09:58:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E2/2B-09936-15BBD645; Thu, 20 Nov 2014 09:58:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416477519!14129965!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20794 invoked from network); 20 Nov 2014 09:58:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 09:58:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="194733542"
Message-ID: <546DBB4D.9030100@citrix.com>
Date: Thu, 20 Nov 2014 09:58:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>, Chao Peng
	<chao.p.peng@linux.intel.com>
X-DLP: MIA2
Subject: [Xen-devel] Xen-4.5 Testing - Cache Monitoring Technology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 found myself a PSR-capable server and have been having a play
with Xen-4.5

At a first pass, I can get some numbers out:

[root@blob ~]# xl psr-cmt-attach 0
[root@blob ~]# xl psr-cmt-show cache_occupancy
Total RMID: 71
Name                                        ID        Socket 0       
Socket 1
Total L3 Cache Size                                   46080 KB       
46080 KB
Domain-0                                     0        45072
KB            0 KB
[root@blob ~]#

However, I am unable to get any occupancy information for HVM guests. 
Given nothing obvious in the code which would make CMT PV-guest
specific, I presume this is unexpected?

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:04:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10: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 1XrOb6-0006sv-Hk; Thu, 20 Nov 2014 10:04:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrOb4-0006sp-S2
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:04:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9B/EA-09936-2ACBD645; Thu, 20 Nov 2014 10:04:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416477857!14078872!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26510 invoked from network); 20 Nov 2014 10:04:17 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:04:17 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:04:17 +0100
Message-Id: <546DCAB102000078000493E0@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:04:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 0/3] x86: XSA-109/110 follow-up (to be
 considered for 4.5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

1: tighten page table owner checking in do_mmu_update()
2: don't ignore foreigndom input on various MMUEXT ops
3: HVM: don't crash guest upon problems occurring in user mode

Reason to request considering this for 4.5: Tightened argument
checking (as done in the first two patches) reduces the chances
of them getting abused. Not unduly crashing the guest (as done
in the third one) may avoid future security issues of guest user
mode affecting the guest kernel.

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:04:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10: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 1XrOb6-0006sv-Hk; Thu, 20 Nov 2014 10:04:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrOb4-0006sp-S2
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:04:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9B/EA-09936-2ACBD645; Thu, 20 Nov 2014 10:04:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416477857!14078872!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26510 invoked from network); 20 Nov 2014 10:04:17 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:04:17 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:04:17 +0100
Message-Id: <546DCAB102000078000493E0@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:04:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 0/3] x86: XSA-109/110 follow-up (to be
 considered for 4.5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

1: tighten page table owner checking in do_mmu_update()
2: don't ignore foreigndom input on various MMUEXT ops
3: HVM: don't crash guest upon problems occurring in user mode

Reason to request considering this for 4.5: Tightened argument
checking (as done in the first two patches) reduces the chances
of them getting abused. Not unduly crashing the guest (as done
in the third one) may avoid future security issues of guest user
mode affecting the guest kernel.

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:12:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10: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 1XrOiL-00073O-Gn; Thu, 20 Nov 2014 10:11:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrOiK-00073J-BG
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:11:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	53/3C-09936-36EBD645; Thu, 20 Nov 2014 10:11:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416478306!14070773!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4102 invoked from network); 20 Nov 2014 10:11:47 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:11:47 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:11:46 +0100
Message-Id: <546DCC7202000078000493F0@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:11:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
In-Reply-To: <546DCAB102000078000493E0@smtp.nue.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9DA8A972.0__="
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1/3] x86: tighten page table owner checking in
 do_mmu_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part9DA8A972.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
a bad page table domain being specified.

Also pt_owner can't be NULL when reaching the "out" label, so the
respective check can be dropped.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3618,6 +3618,11 @@ long do_mmu_update(
         break;
=20
         case MMU_MACHPHYS_UPDATE:
+            if ( unlikely(d !=3D pt_owner) )
+            {
+                rc =3D -EPERM;
+                break;
+            }
=20
             mfn =3D req.ptr >> PAGE_SHIFT;
             gpfn =3D req.val;
@@ -3694,7 +3699,7 @@ long do_mmu_update(
     perfc_add(num_page_updates, i);
=20
  out:
-    if ( pt_owner && (pt_owner !=3D d) )
+    if ( pt_owner !=3D d )
         rcu_unlock_domain(pt_owner);
=20
     /* Add incremental work we have done to the @done output parameter. =
*/




--=__Part9DA8A972.0__=
Content-Type: text/plain; name="x86-mmuupd-check-foreign.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mmuupd-check-foreign.patch"

x86: tighten page table owner checking in do_mmu_update()=0A=0AMMU_MACHPHYS=
_UPDATE, not manipulating page tables, shouldn't ignore=0Aa bad page table =
domain being specified.=0A=0AAlso pt_owner can't be NULL when reaching the =
"out" label, so the=0Arespective check can be dropped.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0AAcked-by: Tim Deegan <tim@xen.org>=0A=0A-=
-- a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -3618,6 +3618,11 @@ =
long do_mmu_update(=0A         break;=0A =0A         case MMU_MACHPHYS_UPDA=
TE:=0A+            if ( unlikely(d !=3D pt_owner) )=0A+            {=0A+   =
             rc =3D -EPERM;=0A+                break;=0A+            }=0A =
=0A             mfn =3D req.ptr >> PAGE_SHIFT;=0A             gpfn =3D =
req.val;=0A@@ -3694,7 +3699,7 @@ long do_mmu_update(=0A     perfc_add(num_p=
age_updates, i);=0A =0A  out:=0A-    if ( pt_owner && (pt_owner !=3D d) =
)=0A+    if ( pt_owner !=3D d )=0A         rcu_unlock_domain(pt_owner);=0A =
=0A     /* Add incremental work we have done to the @done output parameter.=
 */=0A
--=__Part9DA8A972.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

--=__Part9DA8A972.0__=--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:12:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10: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 1XrOiL-00073O-Gn; Thu, 20 Nov 2014 10:11:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrOiK-00073J-BG
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:11:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	53/3C-09936-36EBD645; Thu, 20 Nov 2014 10:11:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416478306!14070773!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4102 invoked from network); 20 Nov 2014 10:11:47 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:11:47 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:11:46 +0100
Message-Id: <546DCC7202000078000493F0@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:11:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
In-Reply-To: <546DCAB102000078000493E0@smtp.nue.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9DA8A972.0__="
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1/3] x86: tighten page table owner checking in
 do_mmu_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part9DA8A972.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
a bad page table domain being specified.

Also pt_owner can't be NULL when reaching the "out" label, so the
respective check can be dropped.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3618,6 +3618,11 @@ long do_mmu_update(
         break;
=20
         case MMU_MACHPHYS_UPDATE:
+            if ( unlikely(d !=3D pt_owner) )
+            {
+                rc =3D -EPERM;
+                break;
+            }
=20
             mfn =3D req.ptr >> PAGE_SHIFT;
             gpfn =3D req.val;
@@ -3694,7 +3699,7 @@ long do_mmu_update(
     perfc_add(num_page_updates, i);
=20
  out:
-    if ( pt_owner && (pt_owner !=3D d) )
+    if ( pt_owner !=3D d )
         rcu_unlock_domain(pt_owner);
=20
     /* Add incremental work we have done to the @done output parameter. =
*/




--=__Part9DA8A972.0__=
Content-Type: text/plain; name="x86-mmuupd-check-foreign.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mmuupd-check-foreign.patch"

x86: tighten page table owner checking in do_mmu_update()=0A=0AMMU_MACHPHYS=
_UPDATE, not manipulating page tables, shouldn't ignore=0Aa bad page table =
domain being specified.=0A=0AAlso pt_owner can't be NULL when reaching the =
"out" label, so the=0Arespective check can be dropped.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0AAcked-by: Tim Deegan <tim@xen.org>=0A=0A-=
-- a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -3618,6 +3618,11 @@ =
long do_mmu_update(=0A         break;=0A =0A         case MMU_MACHPHYS_UPDA=
TE:=0A+            if ( unlikely(d !=3D pt_owner) )=0A+            {=0A+   =
             rc =3D -EPERM;=0A+                break;=0A+            }=0A =
=0A             mfn =3D req.ptr >> PAGE_SHIFT;=0A             gpfn =3D =
req.val;=0A@@ -3694,7 +3699,7 @@ long do_mmu_update(=0A     perfc_add(num_p=
age_updates, i);=0A =0A  out:=0A-    if ( pt_owner && (pt_owner !=3D d) =
)=0A+    if ( pt_owner !=3D d )=0A         rcu_unlock_domain(pt_owner);=0A =
=0A     /* Add incremental work we have done to the @done output parameter.=
 */=0A
--=__Part9DA8A972.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

--=__Part9DA8A972.0__=--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:12:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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.xen.org>)
	id 1XrOj5-00077j-3h; Thu, 20 Nov 2014 10:12:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrOj3-00077T-74
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:12:33 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	2C/87-22819-09EBD645; Thu, 20 Nov 2014 10:12:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416478350!7012652!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12943 invoked from network); 20 Nov 2014 10:12:31 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:12:31 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:12:30 +0100
Message-Id: <546DCC9F02000078000493F4@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:12:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
In-Reply-To: <546DCAB102000078000493E0@smtp.nue.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part7045449F.0__="
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 2/3] x86: don't ignore foreigndom input on
 various MMUEXT ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part7045449F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Instead properly fail requests that shouldn't be issued on foreign
domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
operation to work that way.

In the course of doing this the need to always clear "okay" even when
wanting an error code other than -EINVAL became unwieldy, so the
respective logic is being adjusted at once, together with a little
other related cleanup.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3062,23 +3062,23 @@ long do_mmuext_op(
         }
=20
         case MMUEXT_NEW_BASEPTR:
-            if ( paging_mode_translate(d) )
-                okay =3D 0;
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( unlikely(paging_mode_translate(d)) )
+                rc =3D -EINVAL;
             else
-            {
                 rc =3D new_guest_cr3(op.arg1.mfn);
-                okay =3D !rc;
-            }
             break;
=20
         case MMUEXT_NEW_USER_BASEPTR: {
             unsigned long old_mfn;
=20
-            if ( paging_mode_translate(current->domain) )
-            {
-                okay =3D 0;
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( unlikely(paging_mode_translate(d)) )
+                rc =3D -EINVAL;
+            if ( unlikely(rc) )
                 break;
-            }
=20
             old_mfn =3D pagetable_get_pfn(curr->arch.guest_table_user);
             /*
@@ -3136,12 +3136,17 @@ long do_mmuext_op(
         }
        =20
         case MMUEXT_TLB_FLUSH_LOCAL:
-            flush_tlb_local();
+            if ( likely(d =3D=3D pg_owner) )
+                flush_tlb_local();
+            else
+                rc =3D -EPERM;
             break;
    =20
         case MMUEXT_INVLPG_LOCAL:
-            if ( !paging_mode_enabled(d)=20
-                 || paging_invlpg(curr, op.arg1.linear_addr) !=3D 0 )
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( !paging_mode_enabled(d) ||
+                      paging_invlpg(curr, op.arg1.linear_addr) !=3D 0 )
                 flush_tlb_one_local(op.arg1.linear_addr);
             break;
=20
@@ -3150,13 +3155,16 @@ long do_mmuext_op(
         {
             cpumask_t pmask;
=20
-            if ( unlikely(vcpumask_to_pcpumask(d,
-                            guest_handle_to_param(op.arg2.vcpumask, =
const_void),
-                            &pmask)) )
-            {
-                okay =3D 0;
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( unlikely(vcpumask_to_pcpumask(d,
+                                   guest_handle_to_param(op.arg2.vcpumask,=

+                                                         const_void),
+                                   &pmask)) )
+                rc =3D -EINVAL;
+            if ( unlikely(rc) )
                 break;
-            }
+
             if ( op.cmd =3D=3D MMUEXT_TLB_FLUSH_MULTI )
                 flush_tlb_mask(&pmask);
             else
@@ -3165,18 +3173,26 @@ long do_mmuext_op(
         }
=20
         case MMUEXT_TLB_FLUSH_ALL:
-            flush_tlb_mask(d->domain_dirty_cpumask);
+            if ( likely(d =3D=3D pg_owner) )
+                flush_tlb_mask(d->domain_dirty_cpumask);
+            else
+                rc =3D -EPERM;
             break;
    =20
         case MMUEXT_INVLPG_ALL:
-            flush_tlb_one_mask(d->domain_dirty_cpumask, op.arg1.linear_add=
r);
+            if ( likely(d =3D=3D pg_owner) )
+                flush_tlb_one_mask(d->domain_dirty_cpumask, op.arg1.linear=
_addr);
+            else
+                rc =3D -EPERM;
             break;
=20
         case MMUEXT_FLUSH_CACHE:
-            if ( unlikely(!cache_flush_permitted(d)) )
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( unlikely(!cache_flush_permitted(d)) )
             {
                 MEM_LOG("Non-physdev domain tried to FLUSH_CACHE.");
-                okay =3D 0;
+                rc =3D -EACCES;
             }
             else
             {
@@ -3185,8 +3201,8 @@ long do_mmuext_op(
             break;
=20
         case MMUEXT_FLUSH_CACHE_GLOBAL:
-            if ( unlikely(foreigndom !=3D DOMID_SELF) )
-                okay =3D 0;
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
             else if ( likely(cache_flush_permitted(d)) )
             {
                 unsigned int cpu;
@@ -3211,7 +3227,9 @@ long do_mmuext_op(
             unsigned long ptr  =3D op.arg1.linear_addr;
             unsigned long ents =3D op.arg2.nr_ents;
=20
-            if ( paging_mode_external(d) )
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( paging_mode_external(d) )
             {
                 MEM_LOG("ignoring SET_LDT hypercall from external =
domain");
                 okay =3D 0;
@@ -3237,7 +3255,7 @@ long do_mmuext_op(
         case MMUEXT_CLEAR_PAGE: {
             struct page_info *page;
=20
-            page =3D get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);
+            page =3D get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, =
P2M_ALLOC);
             if ( !page || !get_page_type(page, PGT_writable_page) )
             {
                 if ( page )
@@ -3248,7 +3266,7 @@ long do_mmuext_op(
             }
=20
             /* A page is dirtied when it's being cleared. */
-            paging_mark_dirty(d, page_to_mfn(page));
+            paging_mark_dirty(pg_owner, page_to_mfn(page));
=20
             clear_domain_page(page_to_mfn(page));
=20
@@ -3260,7 +3278,8 @@ long do_mmuext_op(
         {
             struct page_info *src_page, *dst_page;
=20
-            src_page =3D get_page_from_gfn(d, op.arg2.src_mfn, NULL, =
P2M_ALLOC);
+            src_page =3D get_page_from_gfn(pg_owner, op.arg2.src_mfn, =
NULL,
+                                         P2M_ALLOC);
             if ( unlikely(!src_page) )
             {
                 okay =3D 0;
@@ -3268,7 +3287,8 @@ long do_mmuext_op(
                 break;
             }
=20
-            dst_page =3D get_page_from_gfn(d, op.arg1.mfn, NULL, =
P2M_ALLOC);
+            dst_page =3D get_page_from_gfn(pg_owner, op.arg1.mfn, NULL,
+                                         P2M_ALLOC);
             okay =3D (dst_page && get_page_type(dst_page, PGT_writable_pag=
e));
             if ( unlikely(!okay) )
             {
@@ -3280,7 +3300,7 @@ long do_mmuext_op(
             }
=20
             /* A page is dirtied when it's being copied to. */
-            paging_mark_dirty(d, page_to_mfn(dst_page));
+            paging_mark_dirty(pg_owner, page_to_mfn(dst_page));
=20
             copy_domain_page(page_to_mfn(dst_page), page_to_mfn(src_page))=
;
=20
@@ -3291,68 +3311,56 @@ long do_mmuext_op(
=20
         case MMUEXT_MARK_SUPER:
         {
-            unsigned long mfn;
-            struct spage_info *spage;
+            unsigned long mfn =3D op.arg1.mfn;
=20
-            mfn =3D op.arg1.mfn;
-            if ( mfn & (L1_PAGETABLE_ENTRIES-1) )
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( mfn & (L1_PAGETABLE_ENTRIES-1) )
             {
                 MEM_LOG("Unaligned superpage reference mfn %lx", mfn);
                 okay =3D 0;
-                break;
             }
-
-            if ( !opt_allow_superpage )
+            else if ( !opt_allow_superpage )
             {
                 MEM_LOG("Superpages disallowed");
-                okay =3D 0;
                 rc =3D -ENOSYS;
-                break;
             }
-
-            spage =3D mfn_to_spage(mfn);
-            okay =3D (mark_superpage(spage, d) >=3D 0);
+            else
+                rc =3D mark_superpage(mfn_to_spage(mfn), d);
             break;
         }
=20
         case MMUEXT_UNMARK_SUPER:
         {
-            unsigned long mfn;
-            struct spage_info *spage;
+            unsigned long mfn =3D op.arg1.mfn;
=20
-            mfn =3D op.arg1.mfn;
-            if ( mfn & (L1_PAGETABLE_ENTRIES-1) )
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( mfn & (L1_PAGETABLE_ENTRIES-1) )
             {
                 MEM_LOG("Unaligned superpage reference mfn %lx", mfn);
                 okay =3D 0;
-                break;
             }
-
-            if ( !opt_allow_superpage )
+            else if ( !opt_allow_superpage )
             {
                 MEM_LOG("Superpages disallowed");
-                okay =3D 0;
                 rc =3D -ENOSYS;
-                break;
             }
-
-            spage =3D mfn_to_spage(mfn);
-            okay =3D (unmark_superpage(spage) >=3D 0);
+            else
+                rc =3D unmark_superpage(mfn_to_spage(mfn));
             break;
         }
=20
         default:
             MEM_LOG("Invalid extended pt command %#x", op.cmd);
             rc =3D -ENOSYS;
-            okay =3D 0;
             break;
         }
=20
-        if ( unlikely(!okay) )
-        {
-            rc =3D rc ? rc : -EINVAL;
+        if ( unlikely(!okay) && !rc )
+            rc =3D -EINVAL;
+        if ( unlikely(rc) )
             break;
-        }
=20
         guest_handle_add_offset(uops, 1);
     }



--=__Part7045449F.0__=
Content-Type: text/plain; name="x86-mmuext-check-foreign.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mmuext-check-foreign.patch"

x86: don't ignore foreigndom input on various MMUEXT ops=0A=0AInstead =
properly fail requests that shouldn't be issued on foreign=0Adomains or - =
for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing=0Aoperation to work =
that way.=0A=0AIn the course of doing this the need to always clear "okay" =
even when=0Awanting an error code other than -EINVAL became unwieldy, so =
the=0Arespective logic is being adjusted at once, together with a =
little=0Aother related cleanup.=0A=0ASigned-off-by: Jan Beulich <jbeulich@s=
use.com>=0A=0A--- a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ =
-3062,23 +3062,23 @@ long do_mmuext_op(=0A         }=0A =0A         case =
MMUEXT_NEW_BASEPTR:=0A-            if ( paging_mode_translate(d) )=0A-     =
           okay =3D 0;=0A+            if ( unlikely(d !=3D pg_owner) )=0A+ =
               rc =3D -EPERM;=0A+            else if ( unlikely(paging_mode=
_translate(d)) )=0A+                rc =3D -EINVAL;=0A             =
else=0A-            {=0A                 rc =3D new_guest_cr3(op.arg1.mfn);=
=0A-                okay =3D !rc;=0A-            }=0A             =
break;=0A =0A         case MMUEXT_NEW_USER_BASEPTR: {=0A             =
unsigned long old_mfn;=0A =0A-            if ( paging_mode_translate(curren=
t->domain) )=0A-            {=0A-                okay =3D 0;=0A+           =
 if ( unlikely(d !=3D pg_owner) )=0A+                rc =3D -EPERM;=0A+    =
        else if ( unlikely(paging_mode_translate(d)) )=0A+                =
rc =3D -EINVAL;=0A+            if ( unlikely(rc) )=0A                 =
break;=0A-            }=0A =0A             old_mfn =3D pagetable_get_pfn(cu=
rr->arch.guest_table_user);=0A             /*=0A@@ -3136,12 +3136,17 @@ =
long do_mmuext_op(=0A         }=0A         =0A         case MMUEXT_TLB_FLUS=
H_LOCAL:=0A-            flush_tlb_local();=0A+            if ( likely(d =
=3D=3D pg_owner) )=0A+                flush_tlb_local();=0A+            =
else=0A+                rc =3D -EPERM;=0A             break;=0A     =0A    =
     case MMUEXT_INVLPG_LOCAL:=0A-            if ( !paging_mode_enabled(d) =
=0A-                 || paging_invlpg(curr, op.arg1.linear_addr) !=3D 0 =
)=0A+            if ( unlikely(d !=3D pg_owner) )=0A+                rc =
=3D -EPERM;=0A+            else if ( !paging_mode_enabled(d) ||=0A+        =
              paging_invlpg(curr, op.arg1.linear_addr) !=3D 0 )=0A         =
        flush_tlb_one_local(op.arg1.linear_addr);=0A             break;=0A =
=0A@@ -3150,13 +3155,16 @@ long do_mmuext_op(=0A         {=0A             =
cpumask_t pmask;=0A =0A-            if ( unlikely(vcpumask_to_pcpumask(d,=
=0A-                            guest_handle_to_param(op.arg2.vcpumask, =
const_void),=0A-                            &pmask)) )=0A-            =
{=0A-                okay =3D 0;=0A+            if ( unlikely(d !=3D =
pg_owner) )=0A+                rc =3D -EPERM;=0A+            else if ( =
unlikely(vcpumask_to_pcpumask(d,=0A+                                   =
guest_handle_to_param(op.arg2.vcpumask,=0A+                                =
                         const_void),=0A+                                  =
 &pmask)) )=0A+                rc =3D -EINVAL;=0A+            if ( =
unlikely(rc) )=0A                 break;=0A-            }=0A+=0A           =
  if ( op.cmd =3D=3D MMUEXT_TLB_FLUSH_MULTI )=0A                 flush_tlb_=
mask(&pmask);=0A             else=0A@@ -3165,18 +3173,26 @@ long do_mmuext_=
op(=0A         }=0A =0A         case MMUEXT_TLB_FLUSH_ALL:=0A-            =
flush_tlb_mask(d->domain_dirty_cpumask);=0A+            if ( likely(d =
=3D=3D pg_owner) )=0A+                flush_tlb_mask(d->domain_dirty_cpumas=
k);=0A+            else=0A+                rc =3D -EPERM;=0A             =
break;=0A     =0A         case MMUEXT_INVLPG_ALL:=0A-            flush_tlb_=
one_mask(d->domain_dirty_cpumask, op.arg1.linear_addr);=0A+            if =
( likely(d =3D=3D pg_owner) )=0A+                flush_tlb_one_mask(d->doma=
in_dirty_cpumask, op.arg1.linear_addr);=0A+            else=0A+            =
    rc =3D -EPERM;=0A             break;=0A =0A         case MMUEXT_FLUSH_C=
ACHE:=0A-            if ( unlikely(!cache_flush_permitted(d)) )=0A+        =
    if ( unlikely(d !=3D pg_owner) )=0A+                rc =3D -EPERM;=0A+ =
           else if ( unlikely(!cache_flush_permitted(d)) )=0A             =
{=0A                 MEM_LOG("Non-physdev domain tried to FLUSH_CACHE.");=
=0A-                okay =3D 0;=0A+                rc =3D -EACCES;=0A      =
       }=0A             else=0A             {=0A@@ -3185,8 +3201,8 @@ long =
do_mmuext_op(=0A             break;=0A =0A         case MMUEXT_FLUSH_CACHE_=
GLOBAL:=0A-            if ( unlikely(foreigndom !=3D DOMID_SELF) )=0A-     =
           okay =3D 0;=0A+            if ( unlikely(d !=3D pg_owner) )=0A+ =
               rc =3D -EPERM;=0A             else if ( likely(cache_flush_p=
ermitted(d)) )=0A             {=0A                 unsigned int cpu;=0A@@ =
-3211,7 +3227,9 @@ long do_mmuext_op(=0A             unsigned long ptr  =
=3D op.arg1.linear_addr;=0A             unsigned long ents =3D op.arg2.nr_e=
nts;=0A =0A-            if ( paging_mode_external(d) )=0A+            if ( =
unlikely(d !=3D pg_owner) )=0A+                rc =3D -EPERM;=0A+          =
  else if ( paging_mode_external(d) )=0A             {=0A                 =
MEM_LOG("ignoring SET_LDT hypercall from external domain");=0A             =
    okay =3D 0;=0A@@ -3237,7 +3255,7 @@ long do_mmuext_op(=0A         case =
MMUEXT_CLEAR_PAGE: {=0A             struct page_info *page;=0A =0A-        =
    page =3D get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);=0A+       =
     page =3D get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC);=0A=
             if ( !page || !get_page_type(page, PGT_writable_page) )=0A    =
         {=0A                 if ( page )=0A@@ -3248,7 +3266,7 @@ long =
do_mmuext_op(=0A             }=0A =0A             /* A page is dirtied =
when it's being cleared. */=0A-            paging_mark_dirty(d, page_to_mfn=
(page));=0A+            paging_mark_dirty(pg_owner, page_to_mfn(page));=0A =
=0A             clear_domain_page(page_to_mfn(page));=0A =0A@@ -3260,7 =
+3278,8 @@ long do_mmuext_op(=0A         {=0A             struct page_info =
*src_page, *dst_page;=0A =0A-            src_page =3D get_page_from_gfn(d, =
op.arg2.src_mfn, NULL, P2M_ALLOC);=0A+            src_page =3D get_page_fro=
m_gfn(pg_owner, op.arg2.src_mfn, NULL,=0A+                                 =
        P2M_ALLOC);=0A             if ( unlikely(!src_page) )=0A           =
  {=0A                 okay =3D 0;=0A@@ -3268,7 +3287,8 @@ long do_mmuext_o=
p(=0A                 break;=0A             }=0A =0A-            dst_page =
=3D get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);=0A+            =
dst_page =3D get_page_from_gfn(pg_owner, op.arg1.mfn, NULL,=0A+            =
                             P2M_ALLOC);=0A             okay =3D (dst_page =
&& get_page_type(dst_page, PGT_writable_page));=0A             if ( =
unlikely(!okay) )=0A             {=0A@@ -3280,7 +3300,7 @@ long do_mmuext_o=
p(=0A             }=0A =0A             /* A page is dirtied when it's =
being copied to. */=0A-            paging_mark_dirty(d, page_to_mfn(dst_pag=
e));=0A+            paging_mark_dirty(pg_owner, page_to_mfn(dst_page));=0A =
=0A             copy_domain_page(page_to_mfn(dst_page), page_to_mfn(src_pag=
e));=0A =0A@@ -3291,68 +3311,56 @@ long do_mmuext_op(=0A =0A         case =
MMUEXT_MARK_SUPER:=0A         {=0A-            unsigned long mfn;=0A-      =
      struct spage_info *spage;=0A+            unsigned long mfn =3D =
op.arg1.mfn;=0A =0A-            mfn =3D op.arg1.mfn;=0A-            if ( =
mfn & (L1_PAGETABLE_ENTRIES-1) )=0A+            if ( unlikely(d !=3D =
pg_owner) )=0A+                rc =3D -EPERM;=0A+            else if ( mfn =
& (L1_PAGETABLE_ENTRIES-1) )=0A             {=0A                 MEM_LOG("U=
naligned superpage reference mfn %lx", mfn);=0A                 okay =3D =
0;=0A-                break;=0A             }=0A-=0A-            if ( =
!opt_allow_superpage )=0A+            else if ( !opt_allow_superpage )=0A  =
           {=0A                 MEM_LOG("Superpages disallowed");=0A-      =
          okay =3D 0;=0A                 rc =3D -ENOSYS;=0A-               =
 break;=0A             }=0A-=0A-            spage =3D mfn_to_spage(mfn);=0A=
-            okay =3D (mark_superpage(spage, d) >=3D 0);=0A+            =
else=0A+                rc =3D mark_superpage(mfn_to_spage(mfn), d);=0A    =
         break;=0A         }=0A =0A         case MMUEXT_UNMARK_SUPER:=0A   =
      {=0A-            unsigned long mfn;=0A-            struct spage_info =
*spage;=0A+            unsigned long mfn =3D op.arg1.mfn;=0A =0A-          =
  mfn =3D op.arg1.mfn;=0A-            if ( mfn & (L1_PAGETABLE_ENTRIES-1) =
)=0A+            if ( unlikely(d !=3D pg_owner) )=0A+                rc =
=3D -EPERM;=0A+            else if ( mfn & (L1_PAGETABLE_ENTRIES-1) )=0A   =
          {=0A                 MEM_LOG("Unaligned superpage reference mfn =
%lx", mfn);=0A                 okay =3D 0;=0A-                break;=0A    =
         }=0A-=0A-            if ( !opt_allow_superpage )=0A+            =
else if ( !opt_allow_superpage )=0A             {=0A                 =
MEM_LOG("Superpages disallowed");=0A-                okay =3D 0;=0A        =
         rc =3D -ENOSYS;=0A-                break;=0A             =
}=0A-=0A-            spage =3D mfn_to_spage(mfn);=0A-            okay =3D =
(unmark_superpage(spage) >=3D 0);=0A+            else=0A+                =
rc =3D unmark_superpage(mfn_to_spage(mfn));=0A             break;=0A       =
  }=0A =0A         default:=0A             MEM_LOG("Invalid extended pt =
command %#x", op.cmd);=0A             rc =3D -ENOSYS;=0A-            okay =
=3D 0;=0A             break;=0A         }=0A =0A-        if ( unlikely(!oka=
y) )=0A-        {=0A-            rc =3D rc ? rc : -EINVAL;=0A+        if ( =
unlikely(!okay) && !rc )=0A+            rc =3D -EINVAL;=0A+        if ( =
unlikely(rc) )=0A             break;=0A-        }=0A =0A         guest_hand=
le_add_offset(uops, 1);=0A     }=0A
--=__Part7045449F.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

--=__Part7045449F.0__=--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:12:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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.xen.org>)
	id 1XrOj5-00077j-3h; Thu, 20 Nov 2014 10:12:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrOj3-00077T-74
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:12:33 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	2C/87-22819-09EBD645; Thu, 20 Nov 2014 10:12:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416478350!7012652!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12943 invoked from network); 20 Nov 2014 10:12:31 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:12:31 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:12:30 +0100
Message-Id: <546DCC9F02000078000493F4@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:12:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
In-Reply-To: <546DCAB102000078000493E0@smtp.nue.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part7045449F.0__="
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 2/3] x86: don't ignore foreigndom input on
 various MMUEXT ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part7045449F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Instead properly fail requests that shouldn't be issued on foreign
domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
operation to work that way.

In the course of doing this the need to always clear "okay" even when
wanting an error code other than -EINVAL became unwieldy, so the
respective logic is being adjusted at once, together with a little
other related cleanup.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3062,23 +3062,23 @@ long do_mmuext_op(
         }
=20
         case MMUEXT_NEW_BASEPTR:
-            if ( paging_mode_translate(d) )
-                okay =3D 0;
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( unlikely(paging_mode_translate(d)) )
+                rc =3D -EINVAL;
             else
-            {
                 rc =3D new_guest_cr3(op.arg1.mfn);
-                okay =3D !rc;
-            }
             break;
=20
         case MMUEXT_NEW_USER_BASEPTR: {
             unsigned long old_mfn;
=20
-            if ( paging_mode_translate(current->domain) )
-            {
-                okay =3D 0;
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( unlikely(paging_mode_translate(d)) )
+                rc =3D -EINVAL;
+            if ( unlikely(rc) )
                 break;
-            }
=20
             old_mfn =3D pagetable_get_pfn(curr->arch.guest_table_user);
             /*
@@ -3136,12 +3136,17 @@ long do_mmuext_op(
         }
        =20
         case MMUEXT_TLB_FLUSH_LOCAL:
-            flush_tlb_local();
+            if ( likely(d =3D=3D pg_owner) )
+                flush_tlb_local();
+            else
+                rc =3D -EPERM;
             break;
    =20
         case MMUEXT_INVLPG_LOCAL:
-            if ( !paging_mode_enabled(d)=20
-                 || paging_invlpg(curr, op.arg1.linear_addr) !=3D 0 )
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( !paging_mode_enabled(d) ||
+                      paging_invlpg(curr, op.arg1.linear_addr) !=3D 0 )
                 flush_tlb_one_local(op.arg1.linear_addr);
             break;
=20
@@ -3150,13 +3155,16 @@ long do_mmuext_op(
         {
             cpumask_t pmask;
=20
-            if ( unlikely(vcpumask_to_pcpumask(d,
-                            guest_handle_to_param(op.arg2.vcpumask, =
const_void),
-                            &pmask)) )
-            {
-                okay =3D 0;
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( unlikely(vcpumask_to_pcpumask(d,
+                                   guest_handle_to_param(op.arg2.vcpumask,=

+                                                         const_void),
+                                   &pmask)) )
+                rc =3D -EINVAL;
+            if ( unlikely(rc) )
                 break;
-            }
+
             if ( op.cmd =3D=3D MMUEXT_TLB_FLUSH_MULTI )
                 flush_tlb_mask(&pmask);
             else
@@ -3165,18 +3173,26 @@ long do_mmuext_op(
         }
=20
         case MMUEXT_TLB_FLUSH_ALL:
-            flush_tlb_mask(d->domain_dirty_cpumask);
+            if ( likely(d =3D=3D pg_owner) )
+                flush_tlb_mask(d->domain_dirty_cpumask);
+            else
+                rc =3D -EPERM;
             break;
    =20
         case MMUEXT_INVLPG_ALL:
-            flush_tlb_one_mask(d->domain_dirty_cpumask, op.arg1.linear_add=
r);
+            if ( likely(d =3D=3D pg_owner) )
+                flush_tlb_one_mask(d->domain_dirty_cpumask, op.arg1.linear=
_addr);
+            else
+                rc =3D -EPERM;
             break;
=20
         case MMUEXT_FLUSH_CACHE:
-            if ( unlikely(!cache_flush_permitted(d)) )
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( unlikely(!cache_flush_permitted(d)) )
             {
                 MEM_LOG("Non-physdev domain tried to FLUSH_CACHE.");
-                okay =3D 0;
+                rc =3D -EACCES;
             }
             else
             {
@@ -3185,8 +3201,8 @@ long do_mmuext_op(
             break;
=20
         case MMUEXT_FLUSH_CACHE_GLOBAL:
-            if ( unlikely(foreigndom !=3D DOMID_SELF) )
-                okay =3D 0;
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
             else if ( likely(cache_flush_permitted(d)) )
             {
                 unsigned int cpu;
@@ -3211,7 +3227,9 @@ long do_mmuext_op(
             unsigned long ptr  =3D op.arg1.linear_addr;
             unsigned long ents =3D op.arg2.nr_ents;
=20
-            if ( paging_mode_external(d) )
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( paging_mode_external(d) )
             {
                 MEM_LOG("ignoring SET_LDT hypercall from external =
domain");
                 okay =3D 0;
@@ -3237,7 +3255,7 @@ long do_mmuext_op(
         case MMUEXT_CLEAR_PAGE: {
             struct page_info *page;
=20
-            page =3D get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);
+            page =3D get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, =
P2M_ALLOC);
             if ( !page || !get_page_type(page, PGT_writable_page) )
             {
                 if ( page )
@@ -3248,7 +3266,7 @@ long do_mmuext_op(
             }
=20
             /* A page is dirtied when it's being cleared. */
-            paging_mark_dirty(d, page_to_mfn(page));
+            paging_mark_dirty(pg_owner, page_to_mfn(page));
=20
             clear_domain_page(page_to_mfn(page));
=20
@@ -3260,7 +3278,8 @@ long do_mmuext_op(
         {
             struct page_info *src_page, *dst_page;
=20
-            src_page =3D get_page_from_gfn(d, op.arg2.src_mfn, NULL, =
P2M_ALLOC);
+            src_page =3D get_page_from_gfn(pg_owner, op.arg2.src_mfn, =
NULL,
+                                         P2M_ALLOC);
             if ( unlikely(!src_page) )
             {
                 okay =3D 0;
@@ -3268,7 +3287,8 @@ long do_mmuext_op(
                 break;
             }
=20
-            dst_page =3D get_page_from_gfn(d, op.arg1.mfn, NULL, =
P2M_ALLOC);
+            dst_page =3D get_page_from_gfn(pg_owner, op.arg1.mfn, NULL,
+                                         P2M_ALLOC);
             okay =3D (dst_page && get_page_type(dst_page, PGT_writable_pag=
e));
             if ( unlikely(!okay) )
             {
@@ -3280,7 +3300,7 @@ long do_mmuext_op(
             }
=20
             /* A page is dirtied when it's being copied to. */
-            paging_mark_dirty(d, page_to_mfn(dst_page));
+            paging_mark_dirty(pg_owner, page_to_mfn(dst_page));
=20
             copy_domain_page(page_to_mfn(dst_page), page_to_mfn(src_page))=
;
=20
@@ -3291,68 +3311,56 @@ long do_mmuext_op(
=20
         case MMUEXT_MARK_SUPER:
         {
-            unsigned long mfn;
-            struct spage_info *spage;
+            unsigned long mfn =3D op.arg1.mfn;
=20
-            mfn =3D op.arg1.mfn;
-            if ( mfn & (L1_PAGETABLE_ENTRIES-1) )
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( mfn & (L1_PAGETABLE_ENTRIES-1) )
             {
                 MEM_LOG("Unaligned superpage reference mfn %lx", mfn);
                 okay =3D 0;
-                break;
             }
-
-            if ( !opt_allow_superpage )
+            else if ( !opt_allow_superpage )
             {
                 MEM_LOG("Superpages disallowed");
-                okay =3D 0;
                 rc =3D -ENOSYS;
-                break;
             }
-
-            spage =3D mfn_to_spage(mfn);
-            okay =3D (mark_superpage(spage, d) >=3D 0);
+            else
+                rc =3D mark_superpage(mfn_to_spage(mfn), d);
             break;
         }
=20
         case MMUEXT_UNMARK_SUPER:
         {
-            unsigned long mfn;
-            struct spage_info *spage;
+            unsigned long mfn =3D op.arg1.mfn;
=20
-            mfn =3D op.arg1.mfn;
-            if ( mfn & (L1_PAGETABLE_ENTRIES-1) )
+            if ( unlikely(d !=3D pg_owner) )
+                rc =3D -EPERM;
+            else if ( mfn & (L1_PAGETABLE_ENTRIES-1) )
             {
                 MEM_LOG("Unaligned superpage reference mfn %lx", mfn);
                 okay =3D 0;
-                break;
             }
-
-            if ( !opt_allow_superpage )
+            else if ( !opt_allow_superpage )
             {
                 MEM_LOG("Superpages disallowed");
-                okay =3D 0;
                 rc =3D -ENOSYS;
-                break;
             }
-
-            spage =3D mfn_to_spage(mfn);
-            okay =3D (unmark_superpage(spage) >=3D 0);
+            else
+                rc =3D unmark_superpage(mfn_to_spage(mfn));
             break;
         }
=20
         default:
             MEM_LOG("Invalid extended pt command %#x", op.cmd);
             rc =3D -ENOSYS;
-            okay =3D 0;
             break;
         }
=20
-        if ( unlikely(!okay) )
-        {
-            rc =3D rc ? rc : -EINVAL;
+        if ( unlikely(!okay) && !rc )
+            rc =3D -EINVAL;
+        if ( unlikely(rc) )
             break;
-        }
=20
         guest_handle_add_offset(uops, 1);
     }



--=__Part7045449F.0__=
Content-Type: text/plain; name="x86-mmuext-check-foreign.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mmuext-check-foreign.patch"

x86: don't ignore foreigndom input on various MMUEXT ops=0A=0AInstead =
properly fail requests that shouldn't be issued on foreign=0Adomains or - =
for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing=0Aoperation to work =
that way.=0A=0AIn the course of doing this the need to always clear "okay" =
even when=0Awanting an error code other than -EINVAL became unwieldy, so =
the=0Arespective logic is being adjusted at once, together with a =
little=0Aother related cleanup.=0A=0ASigned-off-by: Jan Beulich <jbeulich@s=
use.com>=0A=0A--- a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ =
-3062,23 +3062,23 @@ long do_mmuext_op(=0A         }=0A =0A         case =
MMUEXT_NEW_BASEPTR:=0A-            if ( paging_mode_translate(d) )=0A-     =
           okay =3D 0;=0A+            if ( unlikely(d !=3D pg_owner) )=0A+ =
               rc =3D -EPERM;=0A+            else if ( unlikely(paging_mode=
_translate(d)) )=0A+                rc =3D -EINVAL;=0A             =
else=0A-            {=0A                 rc =3D new_guest_cr3(op.arg1.mfn);=
=0A-                okay =3D !rc;=0A-            }=0A             =
break;=0A =0A         case MMUEXT_NEW_USER_BASEPTR: {=0A             =
unsigned long old_mfn;=0A =0A-            if ( paging_mode_translate(curren=
t->domain) )=0A-            {=0A-                okay =3D 0;=0A+           =
 if ( unlikely(d !=3D pg_owner) )=0A+                rc =3D -EPERM;=0A+    =
        else if ( unlikely(paging_mode_translate(d)) )=0A+                =
rc =3D -EINVAL;=0A+            if ( unlikely(rc) )=0A                 =
break;=0A-            }=0A =0A             old_mfn =3D pagetable_get_pfn(cu=
rr->arch.guest_table_user);=0A             /*=0A@@ -3136,12 +3136,17 @@ =
long do_mmuext_op(=0A         }=0A         =0A         case MMUEXT_TLB_FLUS=
H_LOCAL:=0A-            flush_tlb_local();=0A+            if ( likely(d =
=3D=3D pg_owner) )=0A+                flush_tlb_local();=0A+            =
else=0A+                rc =3D -EPERM;=0A             break;=0A     =0A    =
     case MMUEXT_INVLPG_LOCAL:=0A-            if ( !paging_mode_enabled(d) =
=0A-                 || paging_invlpg(curr, op.arg1.linear_addr) !=3D 0 =
)=0A+            if ( unlikely(d !=3D pg_owner) )=0A+                rc =
=3D -EPERM;=0A+            else if ( !paging_mode_enabled(d) ||=0A+        =
              paging_invlpg(curr, op.arg1.linear_addr) !=3D 0 )=0A         =
        flush_tlb_one_local(op.arg1.linear_addr);=0A             break;=0A =
=0A@@ -3150,13 +3155,16 @@ long do_mmuext_op(=0A         {=0A             =
cpumask_t pmask;=0A =0A-            if ( unlikely(vcpumask_to_pcpumask(d,=
=0A-                            guest_handle_to_param(op.arg2.vcpumask, =
const_void),=0A-                            &pmask)) )=0A-            =
{=0A-                okay =3D 0;=0A+            if ( unlikely(d !=3D =
pg_owner) )=0A+                rc =3D -EPERM;=0A+            else if ( =
unlikely(vcpumask_to_pcpumask(d,=0A+                                   =
guest_handle_to_param(op.arg2.vcpumask,=0A+                                =
                         const_void),=0A+                                  =
 &pmask)) )=0A+                rc =3D -EINVAL;=0A+            if ( =
unlikely(rc) )=0A                 break;=0A-            }=0A+=0A           =
  if ( op.cmd =3D=3D MMUEXT_TLB_FLUSH_MULTI )=0A                 flush_tlb_=
mask(&pmask);=0A             else=0A@@ -3165,18 +3173,26 @@ long do_mmuext_=
op(=0A         }=0A =0A         case MMUEXT_TLB_FLUSH_ALL:=0A-            =
flush_tlb_mask(d->domain_dirty_cpumask);=0A+            if ( likely(d =
=3D=3D pg_owner) )=0A+                flush_tlb_mask(d->domain_dirty_cpumas=
k);=0A+            else=0A+                rc =3D -EPERM;=0A             =
break;=0A     =0A         case MMUEXT_INVLPG_ALL:=0A-            flush_tlb_=
one_mask(d->domain_dirty_cpumask, op.arg1.linear_addr);=0A+            if =
( likely(d =3D=3D pg_owner) )=0A+                flush_tlb_one_mask(d->doma=
in_dirty_cpumask, op.arg1.linear_addr);=0A+            else=0A+            =
    rc =3D -EPERM;=0A             break;=0A =0A         case MMUEXT_FLUSH_C=
ACHE:=0A-            if ( unlikely(!cache_flush_permitted(d)) )=0A+        =
    if ( unlikely(d !=3D pg_owner) )=0A+                rc =3D -EPERM;=0A+ =
           else if ( unlikely(!cache_flush_permitted(d)) )=0A             =
{=0A                 MEM_LOG("Non-physdev domain tried to FLUSH_CACHE.");=
=0A-                okay =3D 0;=0A+                rc =3D -EACCES;=0A      =
       }=0A             else=0A             {=0A@@ -3185,8 +3201,8 @@ long =
do_mmuext_op(=0A             break;=0A =0A         case MMUEXT_FLUSH_CACHE_=
GLOBAL:=0A-            if ( unlikely(foreigndom !=3D DOMID_SELF) )=0A-     =
           okay =3D 0;=0A+            if ( unlikely(d !=3D pg_owner) )=0A+ =
               rc =3D -EPERM;=0A             else if ( likely(cache_flush_p=
ermitted(d)) )=0A             {=0A                 unsigned int cpu;=0A@@ =
-3211,7 +3227,9 @@ long do_mmuext_op(=0A             unsigned long ptr  =
=3D op.arg1.linear_addr;=0A             unsigned long ents =3D op.arg2.nr_e=
nts;=0A =0A-            if ( paging_mode_external(d) )=0A+            if ( =
unlikely(d !=3D pg_owner) )=0A+                rc =3D -EPERM;=0A+          =
  else if ( paging_mode_external(d) )=0A             {=0A                 =
MEM_LOG("ignoring SET_LDT hypercall from external domain");=0A             =
    okay =3D 0;=0A@@ -3237,7 +3255,7 @@ long do_mmuext_op(=0A         case =
MMUEXT_CLEAR_PAGE: {=0A             struct page_info *page;=0A =0A-        =
    page =3D get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);=0A+       =
     page =3D get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC);=0A=
             if ( !page || !get_page_type(page, PGT_writable_page) )=0A    =
         {=0A                 if ( page )=0A@@ -3248,7 +3266,7 @@ long =
do_mmuext_op(=0A             }=0A =0A             /* A page is dirtied =
when it's being cleared. */=0A-            paging_mark_dirty(d, page_to_mfn=
(page));=0A+            paging_mark_dirty(pg_owner, page_to_mfn(page));=0A =
=0A             clear_domain_page(page_to_mfn(page));=0A =0A@@ -3260,7 =
+3278,8 @@ long do_mmuext_op(=0A         {=0A             struct page_info =
*src_page, *dst_page;=0A =0A-            src_page =3D get_page_from_gfn(d, =
op.arg2.src_mfn, NULL, P2M_ALLOC);=0A+            src_page =3D get_page_fro=
m_gfn(pg_owner, op.arg2.src_mfn, NULL,=0A+                                 =
        P2M_ALLOC);=0A             if ( unlikely(!src_page) )=0A           =
  {=0A                 okay =3D 0;=0A@@ -3268,7 +3287,8 @@ long do_mmuext_o=
p(=0A                 break;=0A             }=0A =0A-            dst_page =
=3D get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);=0A+            =
dst_page =3D get_page_from_gfn(pg_owner, op.arg1.mfn, NULL,=0A+            =
                             P2M_ALLOC);=0A             okay =3D (dst_page =
&& get_page_type(dst_page, PGT_writable_page));=0A             if ( =
unlikely(!okay) )=0A             {=0A@@ -3280,7 +3300,7 @@ long do_mmuext_o=
p(=0A             }=0A =0A             /* A page is dirtied when it's =
being copied to. */=0A-            paging_mark_dirty(d, page_to_mfn(dst_pag=
e));=0A+            paging_mark_dirty(pg_owner, page_to_mfn(dst_page));=0A =
=0A             copy_domain_page(page_to_mfn(dst_page), page_to_mfn(src_pag=
e));=0A =0A@@ -3291,68 +3311,56 @@ long do_mmuext_op(=0A =0A         case =
MMUEXT_MARK_SUPER:=0A         {=0A-            unsigned long mfn;=0A-      =
      struct spage_info *spage;=0A+            unsigned long mfn =3D =
op.arg1.mfn;=0A =0A-            mfn =3D op.arg1.mfn;=0A-            if ( =
mfn & (L1_PAGETABLE_ENTRIES-1) )=0A+            if ( unlikely(d !=3D =
pg_owner) )=0A+                rc =3D -EPERM;=0A+            else if ( mfn =
& (L1_PAGETABLE_ENTRIES-1) )=0A             {=0A                 MEM_LOG("U=
naligned superpage reference mfn %lx", mfn);=0A                 okay =3D =
0;=0A-                break;=0A             }=0A-=0A-            if ( =
!opt_allow_superpage )=0A+            else if ( !opt_allow_superpage )=0A  =
           {=0A                 MEM_LOG("Superpages disallowed");=0A-      =
          okay =3D 0;=0A                 rc =3D -ENOSYS;=0A-               =
 break;=0A             }=0A-=0A-            spage =3D mfn_to_spage(mfn);=0A=
-            okay =3D (mark_superpage(spage, d) >=3D 0);=0A+            =
else=0A+                rc =3D mark_superpage(mfn_to_spage(mfn), d);=0A    =
         break;=0A         }=0A =0A         case MMUEXT_UNMARK_SUPER:=0A   =
      {=0A-            unsigned long mfn;=0A-            struct spage_info =
*spage;=0A+            unsigned long mfn =3D op.arg1.mfn;=0A =0A-          =
  mfn =3D op.arg1.mfn;=0A-            if ( mfn & (L1_PAGETABLE_ENTRIES-1) =
)=0A+            if ( unlikely(d !=3D pg_owner) )=0A+                rc =
=3D -EPERM;=0A+            else if ( mfn & (L1_PAGETABLE_ENTRIES-1) )=0A   =
          {=0A                 MEM_LOG("Unaligned superpage reference mfn =
%lx", mfn);=0A                 okay =3D 0;=0A-                break;=0A    =
         }=0A-=0A-            if ( !opt_allow_superpage )=0A+            =
else if ( !opt_allow_superpage )=0A             {=0A                 =
MEM_LOG("Superpages disallowed");=0A-                okay =3D 0;=0A        =
         rc =3D -ENOSYS;=0A-                break;=0A             =
}=0A-=0A-            spage =3D mfn_to_spage(mfn);=0A-            okay =3D =
(unmark_superpage(spage) >=3D 0);=0A+            else=0A+                =
rc =3D unmark_superpage(mfn_to_spage(mfn));=0A             break;=0A       =
  }=0A =0A         default:=0A             MEM_LOG("Invalid extended pt =
command %#x", op.cmd);=0A             rc =3D -ENOSYS;=0A-            okay =
=3D 0;=0A             break;=0A         }=0A =0A-        if ( unlikely(!oka=
y) )=0A-        {=0A-            rc =3D rc ? rc : -EINVAL;=0A+        if ( =
unlikely(!okay) && !rc )=0A+            rc =3D -EINVAL;=0A+        if ( =
unlikely(rc) )=0A             break;=0A-        }=0A =0A         guest_hand=
le_add_offset(uops, 1);=0A     }=0A
--=__Part7045449F.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

--=__Part7045449F.0__=--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:13:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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.xen.org>)
	id 1XrOjf-0007CN-HN; Thu, 20 Nov 2014 10:13:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrOjd-0007C5-FV
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:13:09 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	94/2B-02698-4BEBD645; Thu, 20 Nov 2014 10:13:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416478386!13694991!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29459 invoked from network); 20 Nov 2014 10:13:07 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:13:07 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:13:06 +0100
Message-Id: <546DCCC202000078000493F8@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:13:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
In-Reply-To: <546DCAB102000078000493E0@smtp.nue.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4D7879A2.0__="
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 3/3] x86/HVM: don't crash guest upon problems
 occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part4D7879A2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
exit occurred in guest kernel mode") to further cases, including the
failed VM entry one that XSA-110 was needed to be issued for.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
 static uint64_t osvw_length, osvw_status;
 static DEFINE_SPINLOCK(osvw_lock);
=20
+/* Only crash the guest if the problem originates in kernel mode. */
+static void svm_crash_or_gp(struct vcpu *v)
+{
+    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
+    else
+        domain_crash(v->domain);
+}
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int =
inst_len)
 {
     struct vcpu *curr =3D current;
@@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
     if ( unlikely(inst_len > 15) )
     {
         gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);
-        domain_crash(curr->domain);
+        svm_crash_or_gp(curr);
         return;
     }
=20
@@ -1505,7 +1514,7 @@ static void svm_do_nested_pgfault(struct
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
          gpa, mfn_x(mfn), p2mt);
-    domain_crash(v->domain);
+    svm_crash_or_gp(v);
 }
=20
 static void svm_fpu_dirty_intercept(void)
@@ -2647,7 +2656,7 @@ void svm_vmexit_handler(struct cpu_user_
             printk(XENLOG_G_ERR
                    "%pv: Error %d handling NPF (gpa=3D%08lx ec=3D%04lx)\n"=
,
                    v, rc, vmcb->exitinfo2, vmcb->exitinfo1);
-            domain_crash(v->domain);
+            svm_crash_or_gp(v);
         }
         v->arch.hvm_svm.cached_insn_len =3D 0;
         break;
@@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
                  "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",
                  exit_reason,=20
                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
-        if ( vmcb_get_cpl(vmcb) )
-            hvm_inject_hw_exception(TRAP_invalid_op,
-                                    HVM_DELIVER_NO_ERROR_CODE);
-        else
-            domain_crash(v->domain);
+        svm_crash_or_gp(v);
         break;
     }
=20
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
=20
+/* Only crash the guest if the problem originates in kernel mode. */
+static void vmx_crash_or_gp(struct vcpu *v)
+{
+    struct segment_register ss;
+
+    vmx_get_segment_register(v, x86_seg_ss, &ss);
+    if ( ss.attr.fields.dpl )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
+    else
+        domain_crash(v->domain);
+}
+
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
=20
 static const u32 msr_index[] =3D
@@ -2474,7 +2486,7 @@ static void ept_handle_violation(unsigne
     if ( qualification & EPT_GLA_VALID )
         gdprintk(XENLOG_ERR, " --- GLA %#lx\n", gla);
=20
-    domain_crash(d);
+    vmx_crash_or_gp(current);
 }
=20
 static void vmx_failed_vmentry(unsigned int exit_reason,
@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned=20
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
=20
-    domain_crash(curr->domain);
+    vmx_crash_or_gp(curr);
 }
=20
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        {
-            struct segment_register ss;
-
-            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
-                     exit_reason);
-
-            vmx_get_segment_register(v, x86_seg_ss, &ss);
-            if ( ss.attr.fields.dpl )
-                hvm_inject_hw_exception(TRAP_invalid_op,
-                                        HVM_DELIVER_NO_ERROR_CODE);
-            else
-                domain_crash(v->domain);
-        }
+        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason=
);
+        vmx_crash_or_gp(v);
         break;
     }
=20



--=__Part4D7879A2.0__=
Content-Type: text/plain; name="x86-HVM-dont-crash-guest-in-user-mode.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-dont-crash-guest-in-user-mode.patch"

x86/HVM: don't crash guest upon problems occurring in user mode=0A=0AThis =
extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM=0Aexit =
occurred in guest kernel mode") to further cases, including the=0Afailed =
VM entry one that XSA-110 was needed to be issued for.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/svm/svm.c=0A+++=
 b/xen/arch/x86/hvm/svm/svm.c=0A@@ -90,6 +90,15 @@ static bool_t amd_erratu=
m383_found __rea=0A static uint64_t osvw_length, osvw_status;=0A static =
DEFINE_SPINLOCK(osvw_lock);=0A =0A+/* Only crash the guest if the problem =
originates in kernel mode. */=0A+static void svm_crash_or_gp(struct vcpu =
*v)=0A+{=0A+    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )=0A+        =
hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);=0A+   =
 else=0A+        domain_crash(v->domain);=0A+}=0A+=0A void __update_guest_e=
ip(struct cpu_user_regs *regs, unsigned int inst_len)=0A {=0A     struct =
vcpu *curr =3D current;=0A@@ -100,7 +109,7 @@ void __update_guest_eip(struc=
t cpu_user_=0A     if ( unlikely(inst_len > 15) )=0A     {=0A         =
gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);=0A-        =
domain_crash(curr->domain);=0A+        svm_crash_or_gp(curr);=0A         =
return;=0A     }=0A =0A@@ -1505,7 +1514,7 @@ static void svm_do_nested_pgfa=
ult(struct=0A     gdprintk(XENLOG_ERR,=0A          "SVM violation gpa =
%#"PRIpaddr", mfn %#lx, type %i\n",=0A          gpa, mfn_x(mfn), p2mt);=0A-=
    domain_crash(v->domain);=0A+    svm_crash_or_gp(v);=0A }=0A =0A static =
void svm_fpu_dirty_intercept(void)=0A@@ -2647,7 +2656,7 @@ void svm_vmexit_=
handler(struct cpu_user_=0A             printk(XENLOG_G_ERR=0A             =
       "%pv: Error %d handling NPF (gpa=3D%08lx ec=3D%04lx)\n",=0A         =
           v, rc, vmcb->exitinfo2, vmcb->exitinfo1);=0A-            =
domain_crash(v->domain);=0A+            svm_crash_or_gp(v);=0A         =
}=0A         v->arch.hvm_svm.cached_insn_len =3D 0;=0A         break;=0A@@ =
-2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_=0A            =
      "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",=0A           =
       exit_reason, =0A                  (u64)vmcb->exitinfo1, (u64)vmcb->e=
xitinfo2);=0A-        if ( vmcb_get_cpl(vmcb) )=0A-            hvm_inject_h=
w_exception(TRAP_invalid_op,=0A-                                    =
HVM_DELIVER_NO_ERROR_CODE);=0A-        else=0A-            domain_crash(v->=
domain);=0A+        svm_crash_or_gp(v);=0A         break;=0A     }=0A =
=0A--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@=
 -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu=0A     =
passive_domain_destroy(v);=0A }=0A =0A+/* Only crash the guest if the =
problem originates in kernel mode. */=0A+static void vmx_crash_or_gp(struct=
 vcpu *v)=0A+{=0A+    struct segment_register ss;=0A+=0A+    vmx_get_segmen=
t_register(v, x86_seg_ss, &ss);=0A+    if ( ss.attr.fields.dpl )=0A+       =
 hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);=0A+  =
  else=0A+        domain_crash(v->domain);=0A+}=0A+=0A static DEFINE_PER_CP=
U(struct vmx_msr_state, host_msr_state);=0A =0A static const u32 msr_index[=
] =3D=0A@@ -2474,7 +2486,7 @@ static void ept_handle_violation(unsigne=0A  =
   if ( qualification & EPT_GLA_VALID )=0A         gdprintk(XENLOG_ERR, " =
--- GLA %#lx\n", gla);=0A =0A-    domain_crash(d);=0A+    vmx_crash_or_gp(c=
urrent);=0A }=0A =0A static void vmx_failed_vmentry(unsigned int exit_reaso=
n,=0A@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned =0A     =
vmcs_dump_vcpu(curr);=0A     printk("**************************************=
\n");=0A =0A-    domain_crash(curr->domain);=0A+    vmx_crash_or_gp(curr);=
=0A }=0A =0A void vmx_enter_realmode(struct cpu_user_regs *regs)=0A@@ =
-3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_=0A     /* =
fall through */=0A     default:=0A     exit_and_crash:=0A-        {=0A-    =
        struct segment_register ss;=0A-=0A-            gdprintk(XENLOG_WARN=
ING, "Bad vmexit (reason %#lx)\n",=0A-                     exit_reason);=0A=
-=0A-            vmx_get_segment_register(v, x86_seg_ss, &ss);=0A-         =
   if ( ss.attr.fields.dpl )=0A-                hvm_inject_hw_exception(TRA=
P_invalid_op,=0A-                                        HVM_DELIVER_NO_ERR=
OR_CODE);=0A-            else=0A-                domain_crash(v->domain);=
=0A-        }=0A+        gdprintk(XENLOG_WARNING, "Bad vmexit (reason =
%#lx)\n", exit_reason);=0A+        vmx_crash_or_gp(v);=0A         =
break;=0A     }=0A =0A
--=__Part4D7879A2.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

--=__Part4D7879A2.0__=--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:13:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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.xen.org>)
	id 1XrOjf-0007CN-HN; Thu, 20 Nov 2014 10:13:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrOjd-0007C5-FV
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:13:09 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	94/2B-02698-4BEBD645; Thu, 20 Nov 2014 10:13:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416478386!13694991!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29459 invoked from network); 20 Nov 2014 10:13:07 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:13:07 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:13:06 +0100
Message-Id: <546DCCC202000078000493F8@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:13:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
In-Reply-To: <546DCAB102000078000493E0@smtp.nue.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4D7879A2.0__="
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 3/3] x86/HVM: don't crash guest upon problems
 occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part4D7879A2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
exit occurred in guest kernel mode") to further cases, including the
failed VM entry one that XSA-110 was needed to be issued for.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
 static uint64_t osvw_length, osvw_status;
 static DEFINE_SPINLOCK(osvw_lock);
=20
+/* Only crash the guest if the problem originates in kernel mode. */
+static void svm_crash_or_gp(struct vcpu *v)
+{
+    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
+    else
+        domain_crash(v->domain);
+}
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int =
inst_len)
 {
     struct vcpu *curr =3D current;
@@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
     if ( unlikely(inst_len > 15) )
     {
         gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);
-        domain_crash(curr->domain);
+        svm_crash_or_gp(curr);
         return;
     }
=20
@@ -1505,7 +1514,7 @@ static void svm_do_nested_pgfault(struct
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
          gpa, mfn_x(mfn), p2mt);
-    domain_crash(v->domain);
+    svm_crash_or_gp(v);
 }
=20
 static void svm_fpu_dirty_intercept(void)
@@ -2647,7 +2656,7 @@ void svm_vmexit_handler(struct cpu_user_
             printk(XENLOG_G_ERR
                    "%pv: Error %d handling NPF (gpa=3D%08lx ec=3D%04lx)\n"=
,
                    v, rc, vmcb->exitinfo2, vmcb->exitinfo1);
-            domain_crash(v->domain);
+            svm_crash_or_gp(v);
         }
         v->arch.hvm_svm.cached_insn_len =3D 0;
         break;
@@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
                  "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",
                  exit_reason,=20
                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
-        if ( vmcb_get_cpl(vmcb) )
-            hvm_inject_hw_exception(TRAP_invalid_op,
-                                    HVM_DELIVER_NO_ERROR_CODE);
-        else
-            domain_crash(v->domain);
+        svm_crash_or_gp(v);
         break;
     }
=20
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
=20
+/* Only crash the guest if the problem originates in kernel mode. */
+static void vmx_crash_or_gp(struct vcpu *v)
+{
+    struct segment_register ss;
+
+    vmx_get_segment_register(v, x86_seg_ss, &ss);
+    if ( ss.attr.fields.dpl )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
+    else
+        domain_crash(v->domain);
+}
+
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
=20
 static const u32 msr_index[] =3D
@@ -2474,7 +2486,7 @@ static void ept_handle_violation(unsigne
     if ( qualification & EPT_GLA_VALID )
         gdprintk(XENLOG_ERR, " --- GLA %#lx\n", gla);
=20
-    domain_crash(d);
+    vmx_crash_or_gp(current);
 }
=20
 static void vmx_failed_vmentry(unsigned int exit_reason,
@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned=20
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
=20
-    domain_crash(curr->domain);
+    vmx_crash_or_gp(curr);
 }
=20
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        {
-            struct segment_register ss;
-
-            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
-                     exit_reason);
-
-            vmx_get_segment_register(v, x86_seg_ss, &ss);
-            if ( ss.attr.fields.dpl )
-                hvm_inject_hw_exception(TRAP_invalid_op,
-                                        HVM_DELIVER_NO_ERROR_CODE);
-            else
-                domain_crash(v->domain);
-        }
+        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason=
);
+        vmx_crash_or_gp(v);
         break;
     }
=20



--=__Part4D7879A2.0__=
Content-Type: text/plain; name="x86-HVM-dont-crash-guest-in-user-mode.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-dont-crash-guest-in-user-mode.patch"

x86/HVM: don't crash guest upon problems occurring in user mode=0A=0AThis =
extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM=0Aexit =
occurred in guest kernel mode") to further cases, including the=0Afailed =
VM entry one that XSA-110 was needed to be issued for.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/svm/svm.c=0A+++=
 b/xen/arch/x86/hvm/svm/svm.c=0A@@ -90,6 +90,15 @@ static bool_t amd_erratu=
m383_found __rea=0A static uint64_t osvw_length, osvw_status;=0A static =
DEFINE_SPINLOCK(osvw_lock);=0A =0A+/* Only crash the guest if the problem =
originates in kernel mode. */=0A+static void svm_crash_or_gp(struct vcpu =
*v)=0A+{=0A+    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )=0A+        =
hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);=0A+   =
 else=0A+        domain_crash(v->domain);=0A+}=0A+=0A void __update_guest_e=
ip(struct cpu_user_regs *regs, unsigned int inst_len)=0A {=0A     struct =
vcpu *curr =3D current;=0A@@ -100,7 +109,7 @@ void __update_guest_eip(struc=
t cpu_user_=0A     if ( unlikely(inst_len > 15) )=0A     {=0A         =
gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);=0A-        =
domain_crash(curr->domain);=0A+        svm_crash_or_gp(curr);=0A         =
return;=0A     }=0A =0A@@ -1505,7 +1514,7 @@ static void svm_do_nested_pgfa=
ult(struct=0A     gdprintk(XENLOG_ERR,=0A          "SVM violation gpa =
%#"PRIpaddr", mfn %#lx, type %i\n",=0A          gpa, mfn_x(mfn), p2mt);=0A-=
    domain_crash(v->domain);=0A+    svm_crash_or_gp(v);=0A }=0A =0A static =
void svm_fpu_dirty_intercept(void)=0A@@ -2647,7 +2656,7 @@ void svm_vmexit_=
handler(struct cpu_user_=0A             printk(XENLOG_G_ERR=0A             =
       "%pv: Error %d handling NPF (gpa=3D%08lx ec=3D%04lx)\n",=0A         =
           v, rc, vmcb->exitinfo2, vmcb->exitinfo1);=0A-            =
domain_crash(v->domain);=0A+            svm_crash_or_gp(v);=0A         =
}=0A         v->arch.hvm_svm.cached_insn_len =3D 0;=0A         break;=0A@@ =
-2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_=0A            =
      "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",=0A           =
       exit_reason, =0A                  (u64)vmcb->exitinfo1, (u64)vmcb->e=
xitinfo2);=0A-        if ( vmcb_get_cpl(vmcb) )=0A-            hvm_inject_h=
w_exception(TRAP_invalid_op,=0A-                                    =
HVM_DELIVER_NO_ERROR_CODE);=0A-        else=0A-            domain_crash(v->=
domain);=0A+        svm_crash_or_gp(v);=0A         break;=0A     }=0A =
=0A--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@=
 -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu=0A     =
passive_domain_destroy(v);=0A }=0A =0A+/* Only crash the guest if the =
problem originates in kernel mode. */=0A+static void vmx_crash_or_gp(struct=
 vcpu *v)=0A+{=0A+    struct segment_register ss;=0A+=0A+    vmx_get_segmen=
t_register(v, x86_seg_ss, &ss);=0A+    if ( ss.attr.fields.dpl )=0A+       =
 hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);=0A+  =
  else=0A+        domain_crash(v->domain);=0A+}=0A+=0A static DEFINE_PER_CP=
U(struct vmx_msr_state, host_msr_state);=0A =0A static const u32 msr_index[=
] =3D=0A@@ -2474,7 +2486,7 @@ static void ept_handle_violation(unsigne=0A  =
   if ( qualification & EPT_GLA_VALID )=0A         gdprintk(XENLOG_ERR, " =
--- GLA %#lx\n", gla);=0A =0A-    domain_crash(d);=0A+    vmx_crash_or_gp(c=
urrent);=0A }=0A =0A static void vmx_failed_vmentry(unsigned int exit_reaso=
n,=0A@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned =0A     =
vmcs_dump_vcpu(curr);=0A     printk("**************************************=
\n");=0A =0A-    domain_crash(curr->domain);=0A+    vmx_crash_or_gp(curr);=
=0A }=0A =0A void vmx_enter_realmode(struct cpu_user_regs *regs)=0A@@ =
-3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_=0A     /* =
fall through */=0A     default:=0A     exit_and_crash:=0A-        {=0A-    =
        struct segment_register ss;=0A-=0A-            gdprintk(XENLOG_WARN=
ING, "Bad vmexit (reason %#lx)\n",=0A-                     exit_reason);=0A=
-=0A-            vmx_get_segment_register(v, x86_seg_ss, &ss);=0A-         =
   if ( ss.attr.fields.dpl )=0A-                hvm_inject_hw_exception(TRA=
P_invalid_op,=0A-                                        HVM_DELIVER_NO_ERR=
OR_CODE);=0A-            else=0A-                domain_crash(v->domain);=
=0A-        }=0A+        gdprintk(XENLOG_WARNING, "Bad vmexit (reason =
%#lx)\n", exit_reason);=0A+        vmx_crash_or_gp(v);=0A         =
break;=0A     }=0A =0A
--=__Part4D7879A2.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

--=__Part4D7879A2.0__=--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:15:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10: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 1XrOlb-0007TN-8Z; Thu, 20 Nov 2014 10:15:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1XrOla-0007TF-OW
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 10:15:10 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	14/0B-02699-E2FBD645; Thu, 20 Nov 2014 10:15:10 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416478508!13688363!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23133 invoked from network); 20 Nov 2014 10:15:09 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-27.messagelabs.com with SMTP;
	20 Nov 2014 10:15:09 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 20 Nov 2014 02:15:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="419181492"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by FMSMGA003.fm.intel.com with ESMTP; 20 Nov 2014 02:05:41 -0800
Date: Thu, 20 Nov 2014 18:15:05 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141120101505.GB20252@pengc-linux.bj.intel.com>
References: <546DBB4D.9030100@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546DBB4D.9030100@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 Testing - Cache Monitoring Technology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Chao Peng <chao.p.peng@linux.intel.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 09:58:37AM +0000, Andrew Cooper wrote:
> Hi,
> 
> I have found myself a PSR-capable server and have been having a play
> with Xen-4.5
> 
> At a first pass, I can get some numbers out:
> 
> [root@blob ~]# xl psr-cmt-attach 0
> [root@blob ~]# xl psr-cmt-show cache_occupancy
> Total RMID: 71
> Name                                        ID        Socket 0       
> Socket 1
> Total L3 Cache Size                                   46080 KB       
> 46080 KB
> Domain-0                                     0        45072
> KB            0 KB
> [root@blob ~]#
> 
> However, I am unable to get any occupancy information for HVM guests. 
> Given nothing obvious in the code which would make CMT PV-guest
> specific, I presume this is unexpected?
> 
> 
Thank your for trying...
But I just tested the HVM on my box and it runs correct.

Have you missed to run psr-cmt-attach for your HVM domain? Otherwise I
think there may be something wrong.

The cmt itself should not be PV-specific.

Chao
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 20 10:15:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10: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 1XrOlb-0007TN-8Z; Thu, 20 Nov 2014 10:15:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1XrOla-0007TF-OW
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 10:15:10 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	14/0B-02699-E2FBD645; Thu, 20 Nov 2014 10:15:10 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416478508!13688363!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23133 invoked from network); 20 Nov 2014 10:15:09 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-27.messagelabs.com with SMTP;
	20 Nov 2014 10:15:09 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 20 Nov 2014 02:15:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="419181492"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by FMSMGA003.fm.intel.com with ESMTP; 20 Nov 2014 02:05:41 -0800
Date: Thu, 20 Nov 2014 18:15:05 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141120101505.GB20252@pengc-linux.bj.intel.com>
References: <546DBB4D.9030100@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546DBB4D.9030100@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 Testing - Cache Monitoring Technology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Chao Peng <chao.p.peng@linux.intel.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 09:58:37AM +0000, Andrew Cooper wrote:
> Hi,
> 
> I have found myself a PSR-capable server and have been having a play
> with Xen-4.5
> 
> At a first pass, I can get some numbers out:
> 
> [root@blob ~]# xl psr-cmt-attach 0
> [root@blob ~]# xl psr-cmt-show cache_occupancy
> Total RMID: 71
> Name                                        ID        Socket 0       
> Socket 1
> Total L3 Cache Size                                   46080 KB       
> 46080 KB
> Domain-0                                     0        45072
> KB            0 KB
> [root@blob ~]#
> 
> However, I am unable to get any occupancy information for HVM guests. 
> Given nothing obvious in the code which would make CMT PV-guest
> specific, I presume this is unexpected?
> 
> 
Thank your for trying...
But I just tested the HVM on my box and it runs correct.

Have you missed to run psr-cmt-attach for your HVM domain? Otherwise I
think there may be something wrong.

The cmt itself should not be PV-specific.

Chao
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 20 10:23:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrOtH-0007iK-77; Thu, 20 Nov 2014 10:23:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrOtG-0007iF-Dx
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 10:23:06 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	20/10-25547-901CD645; Thu, 20 Nov 2014 10:23:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416478983!12697091!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13039 invoked from network); 20 Nov 2014 10:23:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 10:23:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194739200"
Message-ID: <546DC105.20803@citrix.com>
Date: Thu, 20 Nov 2014 10:23:01 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Chao Peng <chao.p.peng@linux.intel.com>
References: <546DBB4D.9030100@citrix.com>
	<20141120101505.GB20252@pengc-linux.bj.intel.com>
In-Reply-To: <20141120101505.GB20252@pengc-linux.bj.intel.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 Testing - Cache Monitoring Technology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 10:15, Chao Peng wrote:
> On Thu, Nov 20, 2014 at 09:58:37AM +0000, Andrew Cooper wrote:
>> Hi,
>>
>> I have found myself a PSR-capable server and have been having a play
>> with Xen-4.5
>>
>> At a first pass, I can get some numbers out:
>>
>> [root@blob ~]# xl psr-cmt-attach 0
>> [root@blob ~]# xl psr-cmt-show cache_occupancy
>> Total RMID: 71
>> Name                                        ID        Socket 0       
>> Socket 1
>> Total L3 Cache Size                                   46080 KB       
>> 46080 KB
>> Domain-0                                     0        45072
>> KB            0 KB
>> [root@blob ~]#
>>
>> However, I am unable to get any occupancy information for HVM guests. 
>> Given nothing obvious in the code which would make CMT PV-guest
>> specific, I presume this is unexpected?
>>
>>
> Thank your for trying...
> But I just tested the HVM on my box and it runs correct.
>
> Have you missed to run psr-cmt-attach for your HVM domain? Otherwise I
> think there may be something wrong.

No - I get the HVM domain (a memtest domain) listed in the output.  It
is clear from Dom0's occupancy dropping off significantly that
competition is underway on Socket 0 (as expected), but the domain always
has 0 occupancy reported.

I shall investigate.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:23:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrOtH-0007iK-77; Thu, 20 Nov 2014 10:23:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrOtG-0007iF-Dx
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 10:23:06 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	20/10-25547-901CD645; Thu, 20 Nov 2014 10:23:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416478983!12697091!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13039 invoked from network); 20 Nov 2014 10:23:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 10:23:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194739200"
Message-ID: <546DC105.20803@citrix.com>
Date: Thu, 20 Nov 2014 10:23:01 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Chao Peng <chao.p.peng@linux.intel.com>
References: <546DBB4D.9030100@citrix.com>
	<20141120101505.GB20252@pengc-linux.bj.intel.com>
In-Reply-To: <20141120101505.GB20252@pengc-linux.bj.intel.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 Testing - Cache Monitoring Technology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 10:15, Chao Peng wrote:
> On Thu, Nov 20, 2014 at 09:58:37AM +0000, Andrew Cooper wrote:
>> Hi,
>>
>> I have found myself a PSR-capable server and have been having a play
>> with Xen-4.5
>>
>> At a first pass, I can get some numbers out:
>>
>> [root@blob ~]# xl psr-cmt-attach 0
>> [root@blob ~]# xl psr-cmt-show cache_occupancy
>> Total RMID: 71
>> Name                                        ID        Socket 0       
>> Socket 1
>> Total L3 Cache Size                                   46080 KB       
>> 46080 KB
>> Domain-0                                     0        45072
>> KB            0 KB
>> [root@blob ~]#
>>
>> However, I am unable to get any occupancy information for HVM guests. 
>> Given nothing obvious in the code which would make CMT PV-guest
>> specific, I presume this is unexpected?
>>
>>
> Thank your for trying...
> But I just tested the HVM on my box and it runs correct.
>
> Have you missed to run psr-cmt-attach for your HVM domain? Otherwise I
> think there may be something wrong.

No - I get the HVM domain (a memtest domain) listed in the output.  It
is clear from Dom0's occupancy dropping off significantly that
competition is underway on Socket 0 (as expected), but the domain always
has 0 occupancy reported.

I shall investigate.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:28:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:28:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrOyY-0007v4-6J; Thu, 20 Nov 2014 10:28:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XrOyW-0007ux-5m
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 10:28:32 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	06/13-02702-F42CD645; Thu, 20 Nov 2014 10:28:31 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416479310!9069129!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18288 invoked from network); 20 Nov 2014 10:28:30 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Nov 2014 10:28:30 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 20 Nov 2014 02:21:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,423,1413270000"; d="scan'208";a="625441987"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.128])
	([10.238.130.128])
	by fmsmga001.fm.intel.com with ESMTP; 20 Nov 2014 02:28:05 -0800
Message-ID: <546DC235.4020908@intel.com>
Date: Thu, 20 Nov 2014 18:28:05 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
	<546B20910200007800048AC0@mail.emea.novell.com>
	<546BF1AD.4010801@intel.com>
	<546DA6CB02000078000492C5@mail.emea.novell.com>
	<546DA259.10609@intel.com>
	<546DBB760200007800049372@mail.emea.novell.com>
In-Reply-To: <546DBB760200007800049372@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Have a second struct acpi_rmrr_unit pointer, starting out as NULL
> and getting set to the current one when the callback returns a
> positive value. Skip further iterations as long as both pointers
> match.

Great!

int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
{
     struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
     int rc = 0;
     unsigned int i;
     u16 bdf;

     for_each_rmrr_device ( rmrr, bdf, i )
     {
         if ( rmrr != rmrr_cur )
         {
             rc = func(PFN_DOWN(rmrr->base_address),
                       PFN_UP(rmrr->end_address) -
                         PFN_DOWN(rmrr->base_address),
                       PCI_SBDF(rmrr->segment, bdf),
                       ctxt);

             if ( unlikely(rc < 0) )
                 return rc;
             /* Hit this entry so just go next. */
             if ( rc > 0 )
                 rmrr_cur = rmrr;
         }
     }

     return 0;
}


Thanks
Tiejun


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:28:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:28:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrOyY-0007v4-6J; Thu, 20 Nov 2014 10:28:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XrOyW-0007ux-5m
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 10:28:32 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	06/13-02702-F42CD645; Thu, 20 Nov 2014 10:28:31 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416479310!9069129!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18288 invoked from network); 20 Nov 2014 10:28:30 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Nov 2014 10:28:30 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 20 Nov 2014 02:21:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,423,1413270000"; d="scan'208";a="625441987"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.128])
	([10.238.130.128])
	by fmsmga001.fm.intel.com with ESMTP; 20 Nov 2014 02:28:05 -0800
Message-ID: <546DC235.4020908@intel.com>
Date: Thu, 20 Nov 2014 18:28:05 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com> <5462CE68.6010709@intel.com>
	<54632EA80200007800046AE5@mail.emea.novell.com>
	<5469AA77.2070602@intel.com>
	<5469D68D0200007800048515@mail.emea.novell.com>
	<5469D749.2040807@intel.com>
	<5469E74302000078000485B0@mail.emea.novell.com>
	<5469DCD7.4030701@intel.com>
	<5469EF5D0200007800048609@mail.emea.novell.com>
	<546AB82D.5080305@intel.com>
	<546B0AF00200007800048A69@mail.emea.novell.com>
	<546B004B.6050603@intel.com>
	<546B20910200007800048AC0@mail.emea.novell.com>
	<546BF1AD.4010801@intel.com>
	<546DA6CB02000078000492C5@mail.emea.novell.com>
	<546DA259.10609@intel.com>
	<546DBB760200007800049372@mail.emea.novell.com>
In-Reply-To: <546DBB760200007800049372@mail.emea.novell.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Have a second struct acpi_rmrr_unit pointer, starting out as NULL
> and getting set to the current one when the callback returns a
> positive value. Skip further iterations as long as both pointers
> match.

Great!

int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
{
     struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
     int rc = 0;
     unsigned int i;
     u16 bdf;

     for_each_rmrr_device ( rmrr, bdf, i )
     {
         if ( rmrr != rmrr_cur )
         {
             rc = func(PFN_DOWN(rmrr->base_address),
                       PFN_UP(rmrr->end_address) -
                         PFN_DOWN(rmrr->base_address),
                       PCI_SBDF(rmrr->segment, bdf),
                       ctxt);

             if ( unlikely(rc < 0) )
                 return rc;
             /* Hit this entry so just go next. */
             if ( rc > 0 )
                 rmrr_cur = rmrr;
         }
     }

     return 0;
}


Thanks
Tiejun


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:30:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrOzh-00080h-Kn; Thu, 20 Nov 2014 10:29:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrOzg-00080P-65
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 10:29:44 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F8/90-25276-792CD645; Thu, 20 Nov 2014 10:29:43 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416479381!14090457!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13175 invoked from network); 20 Nov 2014 10:29:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 10:29:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194740541"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 05:29:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrOz8-00005r-VN;
	Thu, 20 Nov 2014 10:29:10 +0000
Date: Thu, 20 Nov 2014 10:28:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
	<CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1424345877-1416479329=:12596"
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>, xen-devel@lists.xen.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1424345877-1416479329=:12596
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> 19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=80=D0=B8=D1=81=
=D1=82=D1=83=D0=B2=D0=B0=D1=87 "Stefano Stabellini" <stefano.stabellini@eu.=
citrix.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:
> >
> > On Wed, 19 Nov 2014, Julien Grall wrote:
> > > On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > > > That's right, the maintenance interrupt handler is not called, but =
it
> > > > doesn't do anything so we are fine. The important thing is that an
> > > > interrupt is sent and git_clear_lrs gets called on hypervisor entry=
=2E
> > >
> > > It would be worth to write down this somewhere. Just in case someone
> > > decide to add code in maintenance interrupt later.
> >
> > Yes, I could add a comment in the handler
>=20
> Maybe it wouldn't take a lot of effort to fix it? I am just worrying that=
 we may hide some issue -
> typically spurious interrupt this not what is expected.

My guess is that by clearing UIE before reading GICC_IAR, we "clear" the
maintenance interrupt too, as a consequence the following read to
GICC_IAR would return 1023 (nothing to be read). As bit as if the
maintenance interrupt was a level interrupt and we just disabled it.

So I think that if we cleared UIE after reading GICC_IAR, GICC_IAR would
return the correct value.

However with the current structure of the code, the first thing that we
do upon entering the hypervisor is clearing LRs and given what happened
on your platform I think is a good idea to do it with UIE disabled.

This is way I would rather read spurious interrupts but read/write LRs
with UIE disabled than reading maintenance interrupts but risking
strange behaviours on some platforms.
--1342847746-1424345877-1416479329=:12596
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1424345877-1416479329=:12596--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:30:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrOzr-00082L-0s; Thu, 20 Nov 2014 10:29:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrOzp-00081y-A2
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:29:53 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	D6/17-02957-0A2CD645; Thu, 20 Nov 2014 10:29:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416479388!13693719!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20426 invoked from network); 20 Nov 2014 10:29: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;
	20 Nov 2014 10:29:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; 
	d="scan'208,217";a="194740637"
Message-ID: <546DC29A.4070301@citrix.com>
Date: Thu, 20 Nov 2014 10:29:46 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCC7202000078000493F0@smtp.nue.novell.com>
In-Reply-To: <546DCC7202000078000493F0@smtp.nue.novell.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] x86: tighten page table owner checking
 in do_mmu_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="===============4615693742964800841=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4615693742964800841==
Content-Type: multipart/alternative;
	boundary="------------090405090003080301010406"

--------------090405090003080301010406
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit

On 20/11/14 10:11, Jan Beulich wrote:
> MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
> a bad page table domain being specified.
>
> Also pt_owner can't be NULL when reaching the "out" label, so the
> respective check can be dropped.

Yes it can.

Failing

    if ( (pg_owner = get_pg_owner((uint16_t)foreigndom)) == NULL )
    {
        rc = -ESRCH;
        goto out;
    }

around line 3462 will cause pt_owner to be NULL at the out label.

~Andrew

>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Acked-by: Tim Deegan <tim@xen.org>
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3618,6 +3618,11 @@ long do_mmu_update(
>          break;
>  
>          case MMU_MACHPHYS_UPDATE:
> +            if ( unlikely(d != pt_owner) )
> +            {
> +                rc = -EPERM;
> +                break;
> +            }
>  
>              mfn = req.ptr >> PAGE_SHIFT;
>              gpfn = req.val;
> @@ -3694,7 +3699,7 @@ long do_mmu_update(
>      perfc_add(num_page_updates, i);
>  
>   out:
> -    if ( pt_owner && (pt_owner != d) )
> +    if ( pt_owner != d )
>          rcu_unlock_domain(pt_owner);
>  
>      /* Add incremental work we have done to the @done output parameter. */
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------090405090003080301010406
Content-Type: text/html; charset="windows-1252"
Content-Length: 2517
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 20/11/14 10:11, Jan Beulich wrote:<br>
    </div>
    <blockquote cite=3D"mid:546DCC7202000078000493F0@smtp.nue.novell.com"
      type=3D"cite">
      <pre wrap=3D"">MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
a bad page table domain being specified.

Also pt_owner can't be NULL when reaching the "out" label, so the
respective check can be dropped.</pre>
    </blockquote>
    <br>
    Yes it can.<br>
    <br>
    Failing <br>
    <br>
    =A0=A0=A0 if ( (pg_owner =3D get_pg_owner((uint16_t)foreigndom)) =3D=3D NULL )<br>
    =A0=A0=A0 {<br>
    =A0=A0=A0=A0=A0=A0=A0 rc =3D -ESRCH;<br>
    =A0=A0=A0=A0=A0=A0=A0 goto out;<br>
    =A0=A0=A0 }<br>
    <br>
    around line 3462 will cause pt_owner to be NULL at the out label.<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote cite=3D"mid:546DCC7202000078000493F0@smtp.nue.novell.com"
      type=3D"cite">
      <pre wrap=3D"">

Signed-off-by: Jan Beulich <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a>
Acked-by: Tim Deegan <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:tim@xen.org">&lt;tim@xen.org&gt;</a>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3618,6 +3618,11 @@ long do_mmu_update(
         break;
 
         case MMU_MACHPHYS_UPDATE:
+            if ( unlikely(d !=3D pt_owner) )
+            {
+                rc =3D -EPERM;
+                break;
+            }
 
             mfn =3D req.ptr &gt;&gt; PAGE_SHIFT;
             gpfn =3D req.val;
@@ -3694,7 +3699,7 @@ long do_mmu_update(
     perfc_add(num_page_updates, i);
 
  out:
-    if ( pt_owner &amp;&amp; (pt_owner !=3D d) )
+    if ( pt_owner !=3D d )
         rcu_unlock_domain(pt_owner);
 
     /* Add incremental work we have done to the @done output parameter. */



</pre>
      <br>
      <fieldset class=3D"mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap=3D"">_______________________________________________
Xen-devel mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class=3D"moz-txt-link-freetext" href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------090405090003080301010406--


--===============4615693742964800841==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4615693742964800841==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:30:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrOzh-00080h-Kn; Thu, 20 Nov 2014 10:29:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrOzg-00080P-65
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 10:29:44 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F8/90-25276-792CD645; Thu, 20 Nov 2014 10:29:43 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416479381!14090457!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13175 invoked from network); 20 Nov 2014 10:29:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 10:29:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194740541"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 05:29:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrOz8-00005r-VN;
	Thu, 20 Nov 2014 10:29:10 +0000
Date: Thu, 20 Nov 2014 10:28:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<CAH_mUMMNtetw_yODZLXbWD78HC6r3SJUwknSc0sQjrYtLUWEhA@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
	<CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1424345877-1416479329=:12596"
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>, xen-devel@lists.xen.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1424345877-1416479329=:12596
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> 19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=80=D0=B8=D1=81=
=D1=82=D1=83=D0=B2=D0=B0=D1=87 "Stefano Stabellini" <stefano.stabellini@eu.=
citrix.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:
> >
> > On Wed, 19 Nov 2014, Julien Grall wrote:
> > > On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > > > That's right, the maintenance interrupt handler is not called, but =
it
> > > > doesn't do anything so we are fine. The important thing is that an
> > > > interrupt is sent and git_clear_lrs gets called on hypervisor entry=
=2E
> > >
> > > It would be worth to write down this somewhere. Just in case someone
> > > decide to add code in maintenance interrupt later.
> >
> > Yes, I could add a comment in the handler
>=20
> Maybe it wouldn't take a lot of effort to fix it? I am just worrying that=
 we may hide some issue -
> typically spurious interrupt this not what is expected.

My guess is that by clearing UIE before reading GICC_IAR, we "clear" the
maintenance interrupt too, as a consequence the following read to
GICC_IAR would return 1023 (nothing to be read). As bit as if the
maintenance interrupt was a level interrupt and we just disabled it.

So I think that if we cleared UIE after reading GICC_IAR, GICC_IAR would
return the correct value.

However with the current structure of the code, the first thing that we
do upon entering the hypervisor is clearing LRs and given what happened
on your platform I think is a good idea to do it with UIE disabled.

This is way I would rather read spurious interrupts but read/write LRs
with UIE disabled than reading maintenance interrupts but risking
strange behaviours on some platforms.
--1342847746-1424345877-1416479329=:12596
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1424345877-1416479329=:12596--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:30:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrOzr-00082L-0s; Thu, 20 Nov 2014 10:29:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrOzp-00081y-A2
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:29:53 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	D6/17-02957-0A2CD645; Thu, 20 Nov 2014 10:29:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416479388!13693719!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20426 invoked from network); 20 Nov 2014 10:29: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;
	20 Nov 2014 10:29:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; 
	d="scan'208,217";a="194740637"
Message-ID: <546DC29A.4070301@citrix.com>
Date: Thu, 20 Nov 2014 10:29:46 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCC7202000078000493F0@smtp.nue.novell.com>
In-Reply-To: <546DCC7202000078000493F0@smtp.nue.novell.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] x86: tighten page table owner checking
 in do_mmu_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="===============4615693742964800841=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4615693742964800841==
Content-Type: multipart/alternative;
	boundary="------------090405090003080301010406"

--------------090405090003080301010406
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit

On 20/11/14 10:11, Jan Beulich wrote:
> MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
> a bad page table domain being specified.
>
> Also pt_owner can't be NULL when reaching the "out" label, so the
> respective check can be dropped.

Yes it can.

Failing

    if ( (pg_owner = get_pg_owner((uint16_t)foreigndom)) == NULL )
    {
        rc = -ESRCH;
        goto out;
    }

around line 3462 will cause pt_owner to be NULL at the out label.

~Andrew

>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Acked-by: Tim Deegan <tim@xen.org>
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3618,6 +3618,11 @@ long do_mmu_update(
>          break;
>  
>          case MMU_MACHPHYS_UPDATE:
> +            if ( unlikely(d != pt_owner) )
> +            {
> +                rc = -EPERM;
> +                break;
> +            }
>  
>              mfn = req.ptr >> PAGE_SHIFT;
>              gpfn = req.val;
> @@ -3694,7 +3699,7 @@ long do_mmu_update(
>      perfc_add(num_page_updates, i);
>  
>   out:
> -    if ( pt_owner && (pt_owner != d) )
> +    if ( pt_owner != d )
>          rcu_unlock_domain(pt_owner);
>  
>      /* Add incremental work we have done to the @done output parameter. */
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------090405090003080301010406
Content-Type: text/html; charset="windows-1252"
Content-Length: 2517
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 20/11/14 10:11, Jan Beulich wrote:<br>
    </div>
    <blockquote cite=3D"mid:546DCC7202000078000493F0@smtp.nue.novell.com"
      type=3D"cite">
      <pre wrap=3D"">MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
a bad page table domain being specified.

Also pt_owner can't be NULL when reaching the "out" label, so the
respective check can be dropped.</pre>
    </blockquote>
    <br>
    Yes it can.<br>
    <br>
    Failing <br>
    <br>
    =A0=A0=A0 if ( (pg_owner =3D get_pg_owner((uint16_t)foreigndom)) =3D=3D NULL )<br>
    =A0=A0=A0 {<br>
    =A0=A0=A0=A0=A0=A0=A0 rc =3D -ESRCH;<br>
    =A0=A0=A0=A0=A0=A0=A0 goto out;<br>
    =A0=A0=A0 }<br>
    <br>
    around line 3462 will cause pt_owner to be NULL at the out label.<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote cite=3D"mid:546DCC7202000078000493F0@smtp.nue.novell.com"
      type=3D"cite">
      <pre wrap=3D"">

Signed-off-by: Jan Beulich <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a>
Acked-by: Tim Deegan <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:tim@xen.org">&lt;tim@xen.org&gt;</a>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3618,6 +3618,11 @@ long do_mmu_update(
         break;
 
         case MMU_MACHPHYS_UPDATE:
+            if ( unlikely(d !=3D pt_owner) )
+            {
+                rc =3D -EPERM;
+                break;
+            }
 
             mfn =3D req.ptr &gt;&gt; PAGE_SHIFT;
             gpfn =3D req.val;
@@ -3694,7 +3699,7 @@ long do_mmu_update(
     perfc_add(num_page_updates, i);
 
  out:
-    if ( pt_owner &amp;&amp; (pt_owner !=3D d) )
+    if ( pt_owner !=3D d )
         rcu_unlock_domain(pt_owner);
 
     /* Add incremental work we have done to the @done output parameter. */



</pre>
      <br>
      <fieldset class=3D"mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap=3D"">_______________________________________________
Xen-devel mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class=3D"moz-txt-link-freetext" href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------090405090003080301010406--


--===============4615693742964800841==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4615693742964800841==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:34:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:34:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrP3h-0008Nk-My; Thu, 20 Nov 2014 10:33:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrP3f-0008Nd-Rl
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:33:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F4/49-09936-F83CD645; Thu, 20 Nov 2014 10:33:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416479628!6081821!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17958 invoked from network); 20 Nov 2014 10:33: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;
	20 Nov 2014 10:33:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; 
	d="scan'208,217";a="193217266"
Message-ID: <546DC38A.8010000@citrix.com>
Date: Thu, 20 Nov 2014 10:33:46 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>	<546DCC7202000078000493F0@smtp.nue.novell.com>
	<546DC29A.4070301@citrix.com>
In-Reply-To: <546DC29A.4070301@citrix.com>
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] x86: tighten page table owner checking
 in do_mmu_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="===============3565478027246392164=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3565478027246392164==
Content-Type: multipart/alternative;
	boundary="------------040608020501000903030304"

--------------040608020501000903030304
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit

On 20/11/14 10:29, Andrew Cooper wrote:
> On 20/11/14 10:11, Jan Beulich wrote:
>> MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
>> a bad page table domain being specified.
>>
>> Also pt_owner can't be NULL when reaching the "out" label, so the
>> respective check can be dropped.
>
> Yes it can.
>
> Failing
>
>     if ( (pg_owner = get_pg_owner((uint16_t)foreigndom)) == NULL )
>     {
>         rc = -ESRCH;
>         goto out;
>     }
>
> around line 3462 will cause pt_owner to be NULL at the out label.
>
> ~Andrew

...And I should really double check my reply before I send.  Apologies
for the noise.

~Andrew

--------------040608020501000903030304
Content-Type: text/html; charset="windows-1252"
Content-Length: 1505
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 20/11/14 10:29, Andrew Cooper wrote:<br>
    </div>
    <blockquote cite=3D"mid:546DC29A.4070301@citrix.com" type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html;
        charset=3Dwindows-1252">
      <div class=3D"moz-cite-prefix">On 20/11/14 10:11, Jan Beulich wrote:<br>
      </div>
      <blockquote
        cite=3D"mid:546DCC7202000078000493F0@smtp.nue.novell.com"
        type=3D"cite">
        <pre wrap=3D"">MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
a bad page table domain being specified.

Also pt_owner can't be NULL when reaching the "out" label, so the
respective check can be dropped.</pre>
      </blockquote>
      <br>
      Yes it can.<br>
      <br>
      Failing <br>
      <br>
      =A0=A0=A0 if ( (pg_owner =3D get_pg_owner((uint16_t)foreigndom)) =3D=3D NULL )<br>
      =A0=A0=A0 {<br>
      =A0=A0=A0=A0=A0=A0=A0 rc =3D -ESRCH;<br>
      =A0=A0=A0=A0=A0=A0=A0 goto out;<br>
      =A0=A0=A0 }<br>
      <br>
      around line 3462 will cause pt_owner to be NULL at the out label.<br>
      <br>
      ~Andrew<br>
    </blockquote>
    <br>
    ...And I should really double check my reply before I send.=A0
    Apologies for the noise.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------040608020501000903030304--


--===============3565478027246392164==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3565478027246392164==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:34:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:34:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrP3h-0008Nk-My; Thu, 20 Nov 2014 10:33:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrP3f-0008Nd-Rl
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:33:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F4/49-09936-F83CD645; Thu, 20 Nov 2014 10:33:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416479628!6081821!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17958 invoked from network); 20 Nov 2014 10:33: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;
	20 Nov 2014 10:33:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; 
	d="scan'208,217";a="193217266"
Message-ID: <546DC38A.8010000@citrix.com>
Date: Thu, 20 Nov 2014 10:33:46 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>	<546DCC7202000078000493F0@smtp.nue.novell.com>
	<546DC29A.4070301@citrix.com>
In-Reply-To: <546DC29A.4070301@citrix.com>
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] x86: tighten page table owner checking
 in do_mmu_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="===============3565478027246392164=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3565478027246392164==
Content-Type: multipart/alternative;
	boundary="------------040608020501000903030304"

--------------040608020501000903030304
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit

On 20/11/14 10:29, Andrew Cooper wrote:
> On 20/11/14 10:11, Jan Beulich wrote:
>> MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
>> a bad page table domain being specified.
>>
>> Also pt_owner can't be NULL when reaching the "out" label, so the
>> respective check can be dropped.
>
> Yes it can.
>
> Failing
>
>     if ( (pg_owner = get_pg_owner((uint16_t)foreigndom)) == NULL )
>     {
>         rc = -ESRCH;
>         goto out;
>     }
>
> around line 3462 will cause pt_owner to be NULL at the out label.
>
> ~Andrew

...And I should really double check my reply before I send.  Apologies
for the noise.

~Andrew

--------------040608020501000903030304
Content-Type: text/html; charset="windows-1252"
Content-Length: 1505
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 20/11/14 10:29, Andrew Cooper wrote:<br>
    </div>
    <blockquote cite=3D"mid:546DC29A.4070301@citrix.com" type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html;
        charset=3Dwindows-1252">
      <div class=3D"moz-cite-prefix">On 20/11/14 10:11, Jan Beulich wrote:<br>
      </div>
      <blockquote
        cite=3D"mid:546DCC7202000078000493F0@smtp.nue.novell.com"
        type=3D"cite">
        <pre wrap=3D"">MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
a bad page table domain being specified.

Also pt_owner can't be NULL when reaching the "out" label, so the
respective check can be dropped.</pre>
      </blockquote>
      <br>
      Yes it can.<br>
      <br>
      Failing <br>
      <br>
      =A0=A0=A0 if ( (pg_owner =3D get_pg_owner((uint16_t)foreigndom)) =3D=3D NULL )<br>
      =A0=A0=A0 {<br>
      =A0=A0=A0=A0=A0=A0=A0 rc =3D -ESRCH;<br>
      =A0=A0=A0=A0=A0=A0=A0 goto out;<br>
      =A0=A0=A0 }<br>
      <br>
      around line 3462 will cause pt_owner to be NULL at the out label.<br>
      <br>
      ~Andrew<br>
    </blockquote>
    <br>
    ...And I should really double check my reply before I send.=A0
    Apologies for the noise.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------040608020501000903030304--


--===============3565478027246392164==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3565478027246392164==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 10:44:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPDE-0000GH-V5; Thu, 20 Nov 2014 10:43:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPDE-0000GA-71
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:43:44 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	96/F9-31453-FD5CD645; Thu, 20 Nov 2014 10:43:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416480222!7137398!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4801 invoked from network); 20 Nov 2014 10:43:42 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:43:42 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:43:42 +0100
Message-Id: <546DD3EC0200007800049451@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:43:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-2-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1416435695-23784-2-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 1/2] dpci: Fix list
 corruption if INTx device is used and an IRQ timeout is invoked.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 23:21, <konrad.wilk@oracle.com> wrote:
> @@ -97,13 +97,15 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
>  }
>  
>  /*
> - * Reset the pirq_dpci->dom parameter to NULL.
> + * Cancels an outstanding pirq_dpci (if scheduled). Also if clear is set,
> + * reset pirq_dpci->dom parameter to NULL (used for teardown).
>   *
>   * This function checks the different states to make sure it can do it
>   * at the right time. If it unschedules the 'hvm_dirq_assist' from running
>   * it also refcounts (which is what the softirq would have done) properly.
>   */
> -static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> +static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
> +                                   unsigned int clear)

Looks reasonable apart from this wanting to be bool_t, and apart
from the fact that iiuc it still doesn't eliminate the observed crashes
(in which case the fix for that may better be folded into here). I'm
not really convinced that this fix is what you currently have as
patch 2 (as the previously mentioned problem of _reset() [now
_cancel()] clearing STATE_SCHED without removing the list entry
from the list is now becoming even more obvious), but I'll also
comment there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:44:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPDE-0000GH-V5; Thu, 20 Nov 2014 10:43:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPDE-0000GA-71
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:43:44 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	96/F9-31453-FD5CD645; Thu, 20 Nov 2014 10:43:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416480222!7137398!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4801 invoked from network); 20 Nov 2014 10:43:42 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:43:42 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:43:42 +0100
Message-Id: <546DD3EC0200007800049451@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:43:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-2-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1416435695-23784-2-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 1/2] dpci: Fix list
 corruption if INTx device is used and an IRQ timeout is invoked.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 23:21, <konrad.wilk@oracle.com> wrote:
> @@ -97,13 +97,15 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
>  }
>  
>  /*
> - * Reset the pirq_dpci->dom parameter to NULL.
> + * Cancels an outstanding pirq_dpci (if scheduled). Also if clear is set,
> + * reset pirq_dpci->dom parameter to NULL (used for teardown).
>   *
>   * This function checks the different states to make sure it can do it
>   * at the right time. If it unschedules the 'hvm_dirq_assist' from running
>   * it also refcounts (which is what the softirq would have done) properly.
>   */
> -static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> +static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
> +                                   unsigned int clear)

Looks reasonable apart from this wanting to be bool_t, and apart
from the fact that iiuc it still doesn't eliminate the observed crashes
(in which case the fix for that may better be folded into here). I'm
not really convinced that this fix is what you currently have as
patch 2 (as the previously mentioned problem of _reset() [now
_cancel()] clearing STATE_SCHED without removing the list entry
from the list is now becoming even more obvious), but I'll also
comment there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:49:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPIP-0000S8-Ar; Thu, 20 Nov 2014 10:49:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrPIN-0000Ru-Lc
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 10:49:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0D/96-09936-F17CD645; Thu, 20 Nov 2014 10:49:03 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416480541!14133427!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15013 invoked from network); 20 Nov 2014 10:49:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 10:49:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193219942"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 05:49:00 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrP9W-0000Nk-1P;
	Thu, 20 Nov 2014 10:39:54 +0000
Date: Thu, 20 Nov 2014 10:39:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
In-Reply-To: <20141120000736.GN4042@n2100.arm.linux.org.uk>
Message-ID: <alpine.DEB.2.02.1411201036400.12596@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411181649000.27247@kaball.uk.xensource.com>
	<20141120000736.GN4042@n2100.arm.linux.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 05/13] arm: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Russell King - ARM Linux wrote:
> On Tue, Nov 18, 2014 at 04:49:21PM +0000, Stefano Stabellini wrote:
> > ping?
> 
> Sending something which wants my attention _To:_ me is always a good idea :)

I'll keep that in mind :-)


> The patch is fine in itself, but I have a niggle about the
> is_device_dma_coherent() - provided this is only used in architecture
> specific code, that should be fine.  It could probably do with a comment
> to that effect in an attempt to discourage drivers using it (thereby
> becoming less portable to other architectures.)

Can I take this as an Acked-by?
Good point regarding the comment. Maybe I can add:

/* do not use this function in a driver */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:49:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPIA-0000R9-V3; Thu, 20 Nov 2014 10:48:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrPI9-0000R4-CC
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 10:48:49 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	06/D5-02559-017CD645; Thu, 20 Nov 2014 10:48:48 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416480526!10383397!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27240 invoked from network); 20 Nov 2014 10:48:47 -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;
	20 Nov 2014 10:48:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193219877"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 05:48:44 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrPHZ-0000Wz-7G;
	Thu, 20 Nov 2014 10:48:13 +0000
Date: Thu, 20 Nov 2014 10:47:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411201033460.12596@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411201046110.12596@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141119210703.GE20440@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411201033460.12596@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 12/13] swiotlb-xen: pass dev_addr to
 xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 12, 2014 at 11:40:53AM +0000, Stefano Stabellini wrote:
> > > xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
> > > handle as argument, not a physical address.
> > 
> > Ouch. Should this also go on stable tree?
> 
> Good idea

Also can I take that as an Acked-by for this patch?


There is one last bit of common and x86 changes in this series:
patch #7 adds a paramter to xen_dma_map_page, even though the x86
implementation is empty:

http://marc.info/?l=xen-devel&m=141579253829808&w=2

is that OK for you?
 
 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > > ---
> > >  drivers/xen/swiotlb-xen.c |    6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > > index 3725ee4..498b654 100644
> > > --- a/drivers/xen/swiotlb-xen.c
> > > +++ b/drivers/xen/swiotlb-xen.c
> > > @@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
> > >  
> > >  	BUG_ON(dir == DMA_NONE);
> > >  
> > > -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> > > +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
> > >  
> > >  	/* NOTE: We use dev_addr here, not paddr! */
> > >  	if (is_xen_swiotlb_buffer(dev_addr)) {
> > > @@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
> > >  	BUG_ON(dir == DMA_NONE);
> > >  
> > >  	if (target == SYNC_FOR_CPU)
> > > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> > >  
> > >  	/* NOTE: We use dev_addr here, not paddr! */
> > >  	if (is_xen_swiotlb_buffer(dev_addr))
> > >  		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
> > >  
> > >  	if (target == SYNC_FOR_DEVICE)
> > > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> > >  
> > >  	if (dir != DMA_FROM_DEVICE)
> > >  		return;
> > > -- 
> > > 1.7.10.4
> > > 
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:49:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPIP-0000S8-Ar; Thu, 20 Nov 2014 10:49:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrPIN-0000Ru-Lc
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 10:49:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0D/96-09936-F17CD645; Thu, 20 Nov 2014 10:49:03 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416480541!14133427!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15013 invoked from network); 20 Nov 2014 10:49:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 10:49:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193219942"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 05:49:00 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrP9W-0000Nk-1P;
	Thu, 20 Nov 2014 10:39:54 +0000
Date: Thu, 20 Nov 2014 10:39:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
In-Reply-To: <20141120000736.GN4042@n2100.arm.linux.org.uk>
Message-ID: <alpine.DEB.2.02.1411201036400.12596@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411181649000.27247@kaball.uk.xensource.com>
	<20141120000736.GN4042@n2100.arm.linux.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 05/13] arm: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Russell King - ARM Linux wrote:
> On Tue, Nov 18, 2014 at 04:49:21PM +0000, Stefano Stabellini wrote:
> > ping?
> 
> Sending something which wants my attention _To:_ me is always a good idea :)

I'll keep that in mind :-)


> The patch is fine in itself, but I have a niggle about the
> is_device_dma_coherent() - provided this is only used in architecture
> specific code, that should be fine.  It could probably do with a comment
> to that effect in an attempt to discourage drivers using it (thereby
> becoming less portable to other architectures.)

Can I take this as an Acked-by?
Good point regarding the comment. Maybe I can add:

/* do not use this function in a driver */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:49:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPIA-0000R9-V3; Thu, 20 Nov 2014 10:48:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrPI9-0000R4-CC
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 10:48:49 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	06/D5-02559-017CD645; Thu, 20 Nov 2014 10:48:48 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416480526!10383397!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27240 invoked from network); 20 Nov 2014 10:48:47 -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;
	20 Nov 2014 10:48:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193219877"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 05:48:44 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrPHZ-0000Wz-7G;
	Thu, 20 Nov 2014 10:48:13 +0000
Date: Thu, 20 Nov 2014 10:47:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411201033460.12596@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411201046110.12596@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141119210703.GE20440@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411201033460.12596@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 12/13] swiotlb-xen: pass dev_addr to
 xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 12, 2014 at 11:40:53AM +0000, Stefano Stabellini wrote:
> > > xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
> > > handle as argument, not a physical address.
> > 
> > Ouch. Should this also go on stable tree?
> 
> Good idea

Also can I take that as an Acked-by for this patch?


There is one last bit of common and x86 changes in this series:
patch #7 adds a paramter to xen_dma_map_page, even though the x86
implementation is empty:

http://marc.info/?l=xen-devel&m=141579253829808&w=2

is that OK for you?
 
 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > > ---
> > >  drivers/xen/swiotlb-xen.c |    6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > > index 3725ee4..498b654 100644
> > > --- a/drivers/xen/swiotlb-xen.c
> > > +++ b/drivers/xen/swiotlb-xen.c
> > > @@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
> > >  
> > >  	BUG_ON(dir == DMA_NONE);
> > >  
> > > -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> > > +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
> > >  
> > >  	/* NOTE: We use dev_addr here, not paddr! */
> > >  	if (is_xen_swiotlb_buffer(dev_addr)) {
> > > @@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
> > >  	BUG_ON(dir == DMA_NONE);
> > >  
> > >  	if (target == SYNC_FOR_CPU)
> > > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> > >  
> > >  	/* NOTE: We use dev_addr here, not paddr! */
> > >  	if (is_xen_swiotlb_buffer(dev_addr))
> > >  		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
> > >  
> > >  	if (target == SYNC_FOR_DEVICE)
> > > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> > >  
> > >  	if (dir != DMA_FROM_DEVICE)
> > >  		return;
> > > -- 
> > > 1.7.10.4
> > > 
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:50:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:50:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPJJ-0000ZU-O6; Thu, 20 Nov 2014 10:50:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrPJI-0000ZH-JN
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 10:50:00 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	6C/97-02559-757CD645; Thu, 20 Nov 2014 10:49:59 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416480597!13717407!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1274 invoked from network); 20 Nov 2014 10:49:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 10:49:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193220032"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 05:49:51 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrP45-0000Ci-4A;
	Thu, 20 Nov 2014 10:34:17 +0000
Date: Thu, 20 Nov 2014 10:33:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141119210703.GE20440@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411201033460.12596@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141119210703.GE20440@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 12/13] swiotlb-xen: pass dev_addr to
 xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 11:40:53AM +0000, Stefano Stabellini wrote:
> > xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
> > handle as argument, not a physical address.
> 
> Ouch. Should this also go on stable tree?

Good idea


> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> >  drivers/xen/swiotlb-xen.c |    6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index 3725ee4..498b654 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
> >  
> >  	BUG_ON(dir == DMA_NONE);
> >  
> > -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> > +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
> >  
> >  	/* NOTE: We use dev_addr here, not paddr! */
> >  	if (is_xen_swiotlb_buffer(dev_addr)) {
> > @@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
> >  	BUG_ON(dir == DMA_NONE);
> >  
> >  	if (target == SYNC_FOR_CPU)
> > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> >  
> >  	/* NOTE: We use dev_addr here, not paddr! */
> >  	if (is_xen_swiotlb_buffer(dev_addr))
> >  		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
> >  
> >  	if (target == SYNC_FOR_DEVICE)
> > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> >  
> >  	if (dir != DMA_FROM_DEVICE)
> >  		return;
> > -- 
> > 1.7.10.4
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:50:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:50:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPJJ-0000ZU-O6; Thu, 20 Nov 2014 10:50:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrPJI-0000ZH-JN
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 10:50:00 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	6C/97-02559-757CD645; Thu, 20 Nov 2014 10:49:59 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416480597!13717407!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1274 invoked from network); 20 Nov 2014 10:49:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 10:49:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193220032"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 05:49:51 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrP45-0000Ci-4A;
	Thu, 20 Nov 2014 10:34:17 +0000
Date: Thu, 20 Nov 2014 10:33:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141119210703.GE20440@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411201033460.12596@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141119210703.GE20440@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 12/13] swiotlb-xen: pass dev_addr to
 xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 11:40:53AM +0000, Stefano Stabellini wrote:
> > xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
> > handle as argument, not a physical address.
> 
> Ouch. Should this also go on stable tree?

Good idea


> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> >  drivers/xen/swiotlb-xen.c |    6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index 3725ee4..498b654 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
> >  
> >  	BUG_ON(dir == DMA_NONE);
> >  
> > -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> > +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
> >  
> >  	/* NOTE: We use dev_addr here, not paddr! */
> >  	if (is_xen_swiotlb_buffer(dev_addr)) {
> > @@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
> >  	BUG_ON(dir == DMA_NONE);
> >  
> >  	if (target == SYNC_FOR_CPU)
> > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> >  
> >  	/* NOTE: We use dev_addr here, not paddr! */
> >  	if (is_xen_swiotlb_buffer(dev_addr))
> >  		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
> >  
> >  	if (target == SYNC_FOR_DEVICE)
> > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> >  
> >  	if (dir != DMA_FROM_DEVICE)
> >  		return;
> > -- 
> > 1.7.10.4
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:51:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:51:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPKY-0000jE-1s; Thu, 20 Nov 2014 10:51:18 +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 1XrPKX-0000j8-FJ
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:51:17 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	30/3A-02698-4A7CD645; Thu, 20 Nov 2014 10:51:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416480676!13733355!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27670 invoked from network); 20 Nov 2014 10:51:16 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 10:51:16 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XrPKH-000OjU-K2; Thu, 20 Nov 2014 10:51:02 +0000
Date: Thu, 20 Nov 2014 11:51:01 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141120105101.GB91061@deinos.phlegethon.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCC9F02000078000493F4@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546DCC9F02000078000493F4@smtp.nue.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: don't ignore foreigndom input on
 various MMUEXT ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:12 +0100 on 20 Nov (1416478351), Jan Beulich wrote:
> Instead properly fail requests that shouldn't be issued on foreign
> domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
> operation to work that way.
> 
> In the course of doing this the need to always clear "okay" even when
> wanting an error code other than -EINVAL became unwieldy, so the
> respective logic is being adjusted at once, together with a little
> other related cleanup.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Tim Deegan <tim@xen.org>

though I would prefer this as two patches, one to remove 'okay'
altogether in favour of appropriate rc settings, and then a simpler
version of this.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:51:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:51:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPKY-0000jE-1s; Thu, 20 Nov 2014 10:51:18 +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 1XrPKX-0000j8-FJ
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:51:17 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	30/3A-02698-4A7CD645; Thu, 20 Nov 2014 10:51:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416480676!13733355!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27670 invoked from network); 20 Nov 2014 10:51:16 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 10:51:16 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XrPKH-000OjU-K2; Thu, 20 Nov 2014 10:51:02 +0000
Date: Thu, 20 Nov 2014 11:51:01 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141120105101.GB91061@deinos.phlegethon.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCC9F02000078000493F4@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546DCC9F02000078000493F4@smtp.nue.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: don't ignore foreigndom input on
 various MMUEXT ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:12 +0100 on 20 Nov (1416478351), Jan Beulich wrote:
> Instead properly fail requests that shouldn't be issued on foreign
> domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
> operation to work that way.
> 
> In the course of doing this the need to always clear "okay" even when
> wanting an error code other than -EINVAL became unwieldy, so the
> respective logic is being adjusted at once, together with a little
> other related cleanup.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Tim Deegan <tim@xen.org>

though I would prefer this as two patches, one to remove 'okay'
altogether in favour of appropriate rc settings, and then a simpler
version of this.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:54:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10: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 1XrPN0-00018r-JW; Thu, 20 Nov 2014 10:53:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrPMz-00018i-MQ
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 10:53:49 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	1F/6C-03148-D38CD645; Thu, 20 Nov 2014 10:53:49 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416480827!13706283!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15964 invoked from network); 20 Nov 2014 10:53:48 -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;
	20 Nov 2014 10:53:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194744685"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 05:53:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrPMw-0000pd-8e;
	Thu, 20 Nov 2014 10:53:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 20 Nov 2014 10:53:24 +0000
Message-ID: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-DLP: MIA1
Cc: julien.grall@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, andrii.tseglytskyi@globallogic.com
Subject: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UIE being set can cause maintenance interrupts to occur when Xen writes
to one or more LR registers. The effect is a busy loop around the
interrupt handler in Xen
(http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
CC: konrad.wilk@oracle.com

---

Konrad, this fixes an actual bug, at least on OMAP5. It should have no
bad side effects on any other platforms as far as I can tell. It should
go in 4.5.

Changes in v2:

- add an in-code comment about maintenance_interrupt not being called.

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..c6c11d3 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -527,8 +529,6 @@ void gic_inject(void)
 
     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
         gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
-    else
-        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
 }
 
 static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
@@ -598,6 +598,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
      * Receiving the interrupt is going to cause gic_inject to be called
      * on return to guest that is going to clear the old LRs and inject
      * new interrupts.
+     *
+     * Do not add code here: maintenance interrupts caused by setting
+     * GICH_HCR_UIE, might read as spurious interrupts (1023). As a
+     * consequence sometimes this handler might not be called.
      */
 }
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:54:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10: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 1XrPN0-00018r-JW; Thu, 20 Nov 2014 10:53:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrPMz-00018i-MQ
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 10:53:49 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	1F/6C-03148-D38CD645; Thu, 20 Nov 2014 10:53:49 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416480827!13706283!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15964 invoked from network); 20 Nov 2014 10:53:48 -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;
	20 Nov 2014 10:53:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194744685"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 05:53:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrPMw-0000pd-8e;
	Thu, 20 Nov 2014 10:53:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 20 Nov 2014 10:53:24 +0000
Message-ID: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-DLP: MIA1
Cc: julien.grall@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, andrii.tseglytskyi@globallogic.com
Subject: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UIE being set can cause maintenance interrupts to occur when Xen writes
to one or more LR registers. The effect is a busy loop around the
interrupt handler in Xen
(http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
CC: konrad.wilk@oracle.com

---

Konrad, this fixes an actual bug, at least on OMAP5. It should have no
bad side effects on any other platforms as far as I can tell. It should
go in 4.5.

Changes in v2:

- add an in-code comment about maintenance_interrupt not being called.

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..c6c11d3 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -527,8 +529,6 @@ void gic_inject(void)
 
     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
         gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
-    else
-        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
 }
 
 static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
@@ -598,6 +598,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
      * Receiving the interrupt is going to cause gic_inject to be called
      * on return to guest that is going to clear the old LRs and inject
      * new interrupts.
+     *
+     * Do not add code here: maintenance interrupts caused by setting
+     * GICH_HCR_UIE, might read as spurious interrupts (1023). As a
+     * consequence sometimes this handler might not be called.
      */
 }
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:56:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:56:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPOs-0001Fu-60; Thu, 20 Nov 2014 10:55:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPOq-0001Fn-BZ
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:55:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BC/32-09842-FA8CD645; Thu, 20 Nov 2014 10:55:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416480943!14132007!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13762 invoked from network); 20 Nov 2014 10:55:43 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:55:43 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:55:42 +0100
Message-Id: <546DD6BF0200007800049471@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:55:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 23:21, <konrad.wilk@oracle.com> wrote:

Leaving aside the question of whether this is the right approach, in
case it is a couple of comments:

> @@ -85,7 +91,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
>   */
>  bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
>  {
> -    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
> +    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )

This is becoming unwieldy - perhaps better just "if ( pirq_dpci->state )"?

> @@ -122,6 +128,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
>          /* fallthrough. */
>      case (1 << STATE_RUN):
>      case (1 << STATE_RUN) | (1 << STATE_SCHED):
> +    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):

How would we get into this state? Afaict STATE_ZOMBIE can't be set
at the same time as STATE_SCHED.

> @@ -786,6 +793,7 @@ unlock:
>  static void dpci_softirq(void)
>  {
>      unsigned int cpu = smp_processor_id();
> +    unsigned int reset = 0;

bool_t (and would better be inside the loop, avoiding the pointless
re-init on the last iteration).

But taking it as a whole - aren't we now at risk of losing an interrupt
instance the guest expects, due to raise_softirq_for() bailing on
zombie entries, and dpci_softirq() being the only place where the
zombie state gets cleared?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 10:56:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 10:56:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPOs-0001Fu-60; Thu, 20 Nov 2014 10:55:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPOq-0001Fn-BZ
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 10:55:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BC/32-09842-FA8CD645; Thu, 20 Nov 2014 10:55:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416480943!14132007!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13762 invoked from network); 20 Nov 2014 10:55:43 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 10:55:43 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 11:55:42 +0100
Message-Id: <546DD6BF0200007800049471@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 11:55:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 23:21, <konrad.wilk@oracle.com> wrote:

Leaving aside the question of whether this is the right approach, in
case it is a couple of comments:

> @@ -85,7 +91,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
>   */
>  bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
>  {
> -    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
> +    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )

This is becoming unwieldy - perhaps better just "if ( pirq_dpci->state )"?

> @@ -122,6 +128,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
>          /* fallthrough. */
>      case (1 << STATE_RUN):
>      case (1 << STATE_RUN) | (1 << STATE_SCHED):
> +    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):

How would we get into this state? Afaict STATE_ZOMBIE can't be set
at the same time as STATE_SCHED.

> @@ -786,6 +793,7 @@ unlock:
>  static void dpci_softirq(void)
>  {
>      unsigned int cpu = smp_processor_id();
> +    unsigned int reset = 0;

bool_t (and would better be inside the loop, avoiding the pointless
re-init on the last iteration).

But taking it as a whole - aren't we now at risk of losing an interrupt
instance the guest expects, due to raise_softirq_for() bailing on
zombie entries, and dpci_softirq() being the only place where the
zombie state gets cleared?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:02:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPVM-0001Te-1P; Thu, 20 Nov 2014 11:02:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPVL-0001TV-8l
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 11:02:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E9/A1-09842-24ACD645; Thu, 20 Nov 2014 11:02:26 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416481346!14054503!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31293 invoked from network); 20 Nov 2014 11:02:26 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:02:26 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so8275490wiv.5
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Nov 2014 03:02:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=8RrIqP80I07sX1wCg7BmT+nd80/7LxFWwZsIVqvx/0I=;
	b=aKK9DmGUzhmoOAvo3WKYJK0n0FBsd2j/gEbGANVY/QUwAS6xghxoepysKuNACC+jWm
	X69+qcrvyOviGKvxgqrugbLZBn5jxAxPGWm+yelPPf7r61mo/PWXWyiTAZMhaI5elFR0
	d8ROmxUtwCMT0lLlxPnRGpazMrOT/3IiPaQLpDefzOOoSKysMG1giyj7XOOORFjmP8FP
	IFlxTvc4kbcVinbBlqOwzPRGv34pd9pakRUbs2o0ES3yo4MFKWyHdF/7qanT5JjF/BKb
	U9tSgY9D19jibMEKcaWziUhw6G6ArtpHzeCEu2kWU44dv2v+neRa1zsKwfpeHURNjoAR
	/k1g==
X-Gm-Message-State: ALoCoQk8K95Q4VD6z/IvmLDsNFI1nDxs2B0GWLjbICw/6MKDyOOZDqJb5bThpN8BFgwq84tAAfTV
X-Received: by 10.194.93.168 with SMTP id cv8mr40083959wjb.114.1416481345689; 
	Thu, 20 Nov 2014 03:02:25 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	dm10sm6101163wib.18.2014.11.20.03.02.24 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:02:24 -0800 (PST)
Message-ID: <546DCA3F.2030508@linaro.org>
Date: Thu, 20 Nov 2014 11:02:23 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	xen-devel@lists.xensource.com
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: julien.grall@citrix.com, Ian.Campbell@citrix.com,
	andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> CC: konrad.wilk@oracle.com
> ---
> 
> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> bad side effects on any other platforms as far as I can tell. It should
> go in 4.5.

>From Andrii's mail, there is a bad side effect. We can receive spurious
interrupt.

On V1, you said that you tried this patch on midway. I would prefer if
you give a try on  platform that would really be used (such as xgene or
seattle). As we know Midway won't be used in prod.

Regards,

> Changes in v2:
> 
> - add an in-code comment about maintenance_interrupt not being called.
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..c6c11d3 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>  
> +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>  
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -527,8 +529,6 @@ void gic_inject(void)
>  
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> -    else
> -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>  }
>  
>  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> @@ -598,6 +598,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>       * Receiving the interrupt is going to cause gic_inject to be called
>       * on return to guest that is going to clear the old LRs and inject
>       * new interrupts.
> +     *
> +     * Do not add code here: maintenance interrupts caused by setting
> +     * GICH_HCR_UIE, might read as spurious interrupts (1023). As a
> +     * consequence sometimes this handler might not be called.
>       */
>  }
>  
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:02:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPVM-0001Te-1P; Thu, 20 Nov 2014 11:02:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPVL-0001TV-8l
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 11:02:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E9/A1-09842-24ACD645; Thu, 20 Nov 2014 11:02:26 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416481346!14054503!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31293 invoked from network); 20 Nov 2014 11:02:26 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:02:26 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so8275490wiv.5
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Nov 2014 03:02:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=8RrIqP80I07sX1wCg7BmT+nd80/7LxFWwZsIVqvx/0I=;
	b=aKK9DmGUzhmoOAvo3WKYJK0n0FBsd2j/gEbGANVY/QUwAS6xghxoepysKuNACC+jWm
	X69+qcrvyOviGKvxgqrugbLZBn5jxAxPGWm+yelPPf7r61mo/PWXWyiTAZMhaI5elFR0
	d8ROmxUtwCMT0lLlxPnRGpazMrOT/3IiPaQLpDefzOOoSKysMG1giyj7XOOORFjmP8FP
	IFlxTvc4kbcVinbBlqOwzPRGv34pd9pakRUbs2o0ES3yo4MFKWyHdF/7qanT5JjF/BKb
	U9tSgY9D19jibMEKcaWziUhw6G6ArtpHzeCEu2kWU44dv2v+neRa1zsKwfpeHURNjoAR
	/k1g==
X-Gm-Message-State: ALoCoQk8K95Q4VD6z/IvmLDsNFI1nDxs2B0GWLjbICw/6MKDyOOZDqJb5bThpN8BFgwq84tAAfTV
X-Received: by 10.194.93.168 with SMTP id cv8mr40083959wjb.114.1416481345689; 
	Thu, 20 Nov 2014 03:02:25 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	dm10sm6101163wib.18.2014.11.20.03.02.24 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:02:24 -0800 (PST)
Message-ID: <546DCA3F.2030508@linaro.org>
Date: Thu, 20 Nov 2014 11:02:23 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	xen-devel@lists.xensource.com
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: julien.grall@citrix.com, Ian.Campbell@citrix.com,
	andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> CC: konrad.wilk@oracle.com
> ---
> 
> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> bad side effects on any other platforms as far as I can tell. It should
> go in 4.5.

>From Andrii's mail, there is a bad side effect. We can receive spurious
interrupt.

On V1, you said that you tried this patch on midway. I would prefer if
you give a try on  platform that would really be used (such as xgene or
seattle). As we know Midway won't be used in prod.

Regards,

> Changes in v2:
> 
> - add an in-code comment about maintenance_interrupt not being called.
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..c6c11d3 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>  
> +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>  
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -527,8 +529,6 @@ void gic_inject(void)
>  
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> -    else
> -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>  }
>  
>  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> @@ -598,6 +598,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>       * Receiving the interrupt is going to cause gic_inject to be called
>       * on return to guest that is going to clear the old LRs and inject
>       * new interrupts.
> +     *
> +     * Do not add code here: maintenance interrupts caused by setting
> +     * GICH_HCR_UIE, might read as spurious interrupts (1023). As a
> +     * consequence sometimes this handler might not be called.
>       */
>  }
>  
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:06:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:06:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPZF-0001i0-SQ; Thu, 20 Nov 2014 11:06:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPZE-0001hu-5L
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 11:06:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D6/CB-25276-33BCD645; Thu, 20 Nov 2014 11:06:27 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416481586!14139070!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5711 invoked from network); 20 Nov 2014 11:06:26 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:06:26 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so8286761wiv.5
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Nov 2014 03:06:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=fro60GMUpI9LzqBPmK1OWTCbUv6OxJb8QM480YiEG+k=;
	b=AINJkM3uWPm7SfulbHrnJXVXiw64G1rr0vBtlK1r3iHs6ZhENysXESApxs/aX/sUA9
	3b1dZYF8yBmgw57t3Gk+I5zPoOuW9wYeeP4mYrGtnRqu6TcFMqdEDYHv+aEC9sXISJIv
	Ez0LpNdkk74qcljQFQV/ZQHPBYN0FAb+KtjpTQueKhyVjDR04oRh1WKodZKyFBorR43U
	LMfwJ/Yui7pAvJPeUSzSPX4pMzTlxy6QlbRfEybTA5oV0ZDiDCFYZaySkUGECkFmdcgU
	t7DsdjCRb8TDRGfPhBRbFsv0uXYvQYrbmQLinNvoxtcWWThpF9zNsjHuQwyw0Ct5X/vy
	VN7g==
X-Gm-Message-State: ALoCoQkdePlc8bpDjN0FH7QgnJLq4umfbcYOPPdG8DHOAwJFY9pskngPY2u/FdUPKpHyJkWkelk0
X-Received: by 10.194.172.131 with SMTP id bc3mr69204450wjc.64.1416481586643; 
	Thu, 20 Nov 2014 03:06:26 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id mw7sm3574604wib.14.2014.11.20.03.06.25
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:06:25 -0800 (PST)
Message-ID: <546DCB30.6040400@linaro.org>
Date: Thu, 20 Nov 2014 11:06:24 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	xen-devel@lists.xensource.com
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<546DCA3F.2030508@linaro.org>
In-Reply-To: <546DCA3F.2030508@linaro.org>
Cc: julien.grall@citrix.com, Ian.Campbell@citrix.com,
	andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 11:02 AM, Julien Grall wrote:
> Hi Stefano,
> 
> On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
>> UIE being set can cause maintenance interrupts to occur when Xen writes
>> to one or more LR registers. The effect is a busy loop around the
>> interrupt handler in Xen
>> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
>>
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> CC: konrad.wilk@oracle.com
>> ---
>>
>> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
>> bad side effects on any other platforms as far as I can tell. It should
>> go in 4.5.
> 
> From Andrii's mail, there is a bad side effect. We can receive spurious
> interrupt.
> 
> On V1, you said that you tried this patch on midway. I would prefer if
> you give a try on  platform that would really be used (such as xgene or
> seattle). As we know Midway won't be used in prod.

And maybe give a try to gicv3 too as it's common code.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:06:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:06:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPZF-0001i0-SQ; Thu, 20 Nov 2014 11:06:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPZE-0001hu-5L
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 11:06:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D6/CB-25276-33BCD645; Thu, 20 Nov 2014 11:06:27 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416481586!14139070!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5711 invoked from network); 20 Nov 2014 11:06:26 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:06:26 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so8286761wiv.5
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Nov 2014 03:06:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=fro60GMUpI9LzqBPmK1OWTCbUv6OxJb8QM480YiEG+k=;
	b=AINJkM3uWPm7SfulbHrnJXVXiw64G1rr0vBtlK1r3iHs6ZhENysXESApxs/aX/sUA9
	3b1dZYF8yBmgw57t3Gk+I5zPoOuW9wYeeP4mYrGtnRqu6TcFMqdEDYHv+aEC9sXISJIv
	Ez0LpNdkk74qcljQFQV/ZQHPBYN0FAb+KtjpTQueKhyVjDR04oRh1WKodZKyFBorR43U
	LMfwJ/Yui7pAvJPeUSzSPX4pMzTlxy6QlbRfEybTA5oV0ZDiDCFYZaySkUGECkFmdcgU
	t7DsdjCRb8TDRGfPhBRbFsv0uXYvQYrbmQLinNvoxtcWWThpF9zNsjHuQwyw0Ct5X/vy
	VN7g==
X-Gm-Message-State: ALoCoQkdePlc8bpDjN0FH7QgnJLq4umfbcYOPPdG8DHOAwJFY9pskngPY2u/FdUPKpHyJkWkelk0
X-Received: by 10.194.172.131 with SMTP id bc3mr69204450wjc.64.1416481586643; 
	Thu, 20 Nov 2014 03:06:26 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id mw7sm3574604wib.14.2014.11.20.03.06.25
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:06:25 -0800 (PST)
Message-ID: <546DCB30.6040400@linaro.org>
Date: Thu, 20 Nov 2014 11:06:24 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	xen-devel@lists.xensource.com
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<546DCA3F.2030508@linaro.org>
In-Reply-To: <546DCA3F.2030508@linaro.org>
Cc: julien.grall@citrix.com, Ian.Campbell@citrix.com,
	andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 11:02 AM, Julien Grall wrote:
> Hi Stefano,
> 
> On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
>> UIE being set can cause maintenance interrupts to occur when Xen writes
>> to one or more LR registers. The effect is a busy loop around the
>> interrupt handler in Xen
>> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
>>
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>> CC: konrad.wilk@oracle.com
>> ---
>>
>> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
>> bad side effects on any other platforms as far as I can tell. It should
>> go in 4.5.
> 
> From Andrii's mail, there is a bad side effect. We can receive spurious
> interrupt.
> 
> On V1, you said that you tried this patch on midway. I would prefer if
> you give a try on  platform that would really be used (such as xgene or
> seattle). As we know Midway won't be used in prod.

And maybe give a try to gicv3 too as it's common code.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:06:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:06:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPZL-0001ij-8T; Thu, 20 Nov 2014 11:06:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrPZJ-0001iJ-Sy
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:06:34 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	51/06-28296-93BCD645; Thu, 20 Nov 2014 11:06:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416481590!8946408!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25154 invoked from network); 20 Nov 2014 11:06:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:06:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; 
	d="scan'208,217";a="194747211"
Message-ID: <546DCB34.8030302@citrix.com>
Date: Thu, 20 Nov 2014 11:06:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
In-Reply-To: <546DCCC202000078000493F8@smtp.nue.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7262172203652596061=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7262172203652596061==
Content-Type: multipart/alternative;
	boundary="------------010300060402080808010406"

--------------010300060402080808010406
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

On 20/11/14 10:13, Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM=

> exit occurred in guest kernel mode") to further cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
>  static uint64_t osvw_length, osvw_status;
>  static DEFINE_SPINLOCK(osvw_lock);
> =20
> +/* Only crash the guest if the problem originates in kernel mode. */
> +static void svm_crash_or_gp(struct vcpu *v)
> +{
> +    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_=
CODE);

This (and its VMX counterpart) should either deliver a #GP fault, or
have its name changed to not imply a #GP fault.

How about "crash_or_fault()" as an alternative which is slightly less
specific?

~Andrew

> +    else
> +        domain_crash(v->domain);
> +}
> +
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_=
len)
>  {
>      struct vcpu *curr =3D current;
> @@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
>      if ( unlikely(inst_len > 15) )
>      {
>          gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);=

> -        domain_crash(curr->domain);
> +        svm_crash_or_gp(curr);
>          return;
>      }
> =20
> @@ -1505,7 +1514,7 @@ static void svm_do_nested_pgfault(struct
>      gdprintk(XENLOG_ERR,
>           "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
>           gpa, mfn_x(mfn), p2mt);
> -    domain_crash(v->domain);
> +    svm_crash_or_gp(v);
>  }
> =20
>  static void svm_fpu_dirty_intercept(void)
> @@ -2647,7 +2656,7 @@ void svm_vmexit_handler(struct cpu_user_
>              printk(XENLOG_G_ERR
>                     "%pv: Error %d handling NPF (gpa=3D%08lx ec=3D%04lx=
)\n",
>                     v, rc, vmcb->exitinfo2, vmcb->exitinfo1);
> -            domain_crash(v->domain);
> +            svm_crash_or_gp(v);
>          }
>          v->arch.hvm_svm.cached_insn_len =3D 0;
>          break;
> @@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
>                   "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n=
",
>                   exit_reason,=20
>                   (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
> -        if ( vmcb_get_cpl(vmcb) )
> -            hvm_inject_hw_exception(TRAP_invalid_op,
> -                                    HVM_DELIVER_NO_ERROR_CODE);
> -        else
> -            domain_crash(v->domain);
> +        svm_crash_or_gp(v);
>          break;
>      }
> =20
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
>      passive_domain_destroy(v);
>  }
> =20
> +/* Only crash the guest if the problem originates in kernel mode. */
> +static void vmx_crash_or_gp(struct vcpu *v)
> +{
> +    struct segment_register ss;
> +
> +    vmx_get_segment_register(v, x86_seg_ss, &ss);
> +    if ( ss.attr.fields.dpl )
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_=
CODE);
> +    else
> +        domain_crash(v->domain);
> +}
> +
>  static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
> =20
>  static const u32 msr_index[] =3D
> @@ -2474,7 +2486,7 @@ static void ept_handle_violation(unsigne
>      if ( qualification & EPT_GLA_VALID )
>          gdprintk(XENLOG_ERR, " --- GLA %#lx\n", gla);
> =20
> -    domain_crash(d);
> +    vmx_crash_or_gp(current);
>  }
> =20
>  static void vmx_failed_vmentry(unsigned int exit_reason,
> @@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned=20
>      vmcs_dump_vcpu(curr);
>      printk("**************************************\n");
> =20
> -    domain_crash(curr->domain);
> +    vmx_crash_or_gp(curr);
>  }
> =20
>  void vmx_enter_realmode(struct cpu_user_regs *regs)
> @@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
>      /* fall through */
>      default:
>      exit_and_crash:
> -        {
> -            struct segment_register ss;
> -
> -            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
> -                     exit_reason);
> -
> -            vmx_get_segment_register(v, x86_seg_ss, &ss);
> -            if ( ss.attr.fields.dpl )
> -                hvm_inject_hw_exception(TRAP_invalid_op,
> -                                        HVM_DELIVER_NO_ERROR_CODE);
> -            else
> -                domain_crash(v->domain);
> -        }
> +        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_re=
ason);
> +        vmx_crash_or_gp(v);
>          break;
>      }
> =20
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------010300060402080808010406
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 20/11/14 10:13, Jan Beulich wrote:<br>
    </div>
    <blockquote cite="mid:546DCCC202000078000493F8@smtp.nue.novell.com"
      type="cite">
      <pre wrap="">This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
exit occurred in guest kernel mode") to further cases, including the
failed VM entry one that XSA-110 was needed to be issued for.

Signed-off-by: Jan Beulich <a class="moz-txt-link-rfc2396E" href="mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a>

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
 static uint64_t osvw_length, osvw_status;
 static DEFINE_SPINLOCK(osvw_lock);
 
+/* Only crash the guest if the problem originates in kernel mode. */
+static void svm_crash_or_gp(struct vcpu *v)
+{
+    if ( vmcb_get_cpl(v-&gt;arch.hvm_svm.vmcb) )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);</pre>
    </blockquote>
    <br>
    This (and its VMX counterpart) should either deliver a #GP fault, or
    have its name changed to not imply a #GP fault.<br>
    <br>
    How about "crash_or_fault()" as an alternative which is slightly
    less specific?<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote cite="mid:546DCCC202000078000493F8@smtp.nue.novell.com"
      type="cite">
      <pre wrap="">
+    else
+        domain_crash(v-&gt;domain);
+}
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
     if ( unlikely(inst_len &gt; 15) )
     {
         gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);
-        domain_crash(curr-&gt;domain);
+        svm_crash_or_gp(curr);
         return;
     }
 
@@ -1505,7 +1514,7 @@ static void svm_do_nested_pgfault(struct
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
          gpa, mfn_x(mfn), p2mt);
-    domain_crash(v-&gt;domain);
+    svm_crash_or_gp(v);
 }
 
 static void svm_fpu_dirty_intercept(void)
@@ -2647,7 +2656,7 @@ void svm_vmexit_handler(struct cpu_user_
             printk(XENLOG_G_ERR
                    "%pv: Error %d handling NPF (gpa=%08lx ec=%04lx)\n",
                    v, rc, vmcb-&gt;exitinfo2, vmcb-&gt;exitinfo1);
-            domain_crash(v-&gt;domain);
+            svm_crash_or_gp(v);
         }
         v-&gt;arch.hvm_svm.cached_insn_len = 0;
         break;
@@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
                  "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
                  exit_reason, 
                  (u64)vmcb-&gt;exitinfo1, (u64)vmcb-&gt;exitinfo2);
-        if ( vmcb_get_cpl(vmcb) )
-            hvm_inject_hw_exception(TRAP_invalid_op,
-                                    HVM_DELIVER_NO_ERROR_CODE);
-        else
-            domain_crash(v-&gt;domain);
+        svm_crash_or_gp(v);
         break;
     }
 
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
 
+/* Only crash the guest if the problem originates in kernel mode. */
+static void vmx_crash_or_gp(struct vcpu *v)
+{
+    struct segment_register ss;
+
+    vmx_get_segment_register(v, x86_seg_ss, &amp;ss);
+    if ( ss.attr.fields.dpl )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+    else
+        domain_crash(v-&gt;domain);
+}
+
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
 
 static const u32 msr_index[] =
@@ -2474,7 +2486,7 @@ static void ept_handle_violation(unsigne
     if ( qualification &amp; EPT_GLA_VALID )
         gdprintk(XENLOG_ERR, " --- GLA %#lx\n", gla);
 
-    domain_crash(d);
+    vmx_crash_or_gp(current);
 }
 
 static void vmx_failed_vmentry(unsigned int exit_reason,
@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned 
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
 
-    domain_crash(curr-&gt;domain);
+    vmx_crash_or_gp(curr);
 }
 
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        {
-            struct segment_register ss;
-
-            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
-                     exit_reason);
-
-            vmx_get_segment_register(v, x86_seg_ss, &amp;ss);
-            if ( ss.attr.fields.dpl )
-                hvm_inject_hw_exception(TRAP_invalid_op,
-                                        HVM_DELIVER_NO_ERROR_CODE);
-            else
-                domain_crash(v-&gt;domain);
-        }
+        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);
+        vmx_crash_or_gp(v);
         break;
     }
 


</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------010300060402080808010406--


--===============7262172203652596061==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7262172203652596061==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 11:06:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:06:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPZL-0001ij-8T; Thu, 20 Nov 2014 11:06:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrPZJ-0001iJ-Sy
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:06:34 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	51/06-28296-93BCD645; Thu, 20 Nov 2014 11:06:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416481590!8946408!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25154 invoked from network); 20 Nov 2014 11:06:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:06:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; 
	d="scan'208,217";a="194747211"
Message-ID: <546DCB34.8030302@citrix.com>
Date: Thu, 20 Nov 2014 11:06:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
In-Reply-To: <546DCCC202000078000493F8@smtp.nue.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7262172203652596061=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7262172203652596061==
Content-Type: multipart/alternative;
	boundary="------------010300060402080808010406"

--------------010300060402080808010406
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

On 20/11/14 10:13, Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM=

> exit occurred in guest kernel mode") to further cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
>  static uint64_t osvw_length, osvw_status;
>  static DEFINE_SPINLOCK(osvw_lock);
> =20
> +/* Only crash the guest if the problem originates in kernel mode. */
> +static void svm_crash_or_gp(struct vcpu *v)
> +{
> +    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_=
CODE);

This (and its VMX counterpart) should either deliver a #GP fault, or
have its name changed to not imply a #GP fault.

How about "crash_or_fault()" as an alternative which is slightly less
specific?

~Andrew

> +    else
> +        domain_crash(v->domain);
> +}
> +
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_=
len)
>  {
>      struct vcpu *curr =3D current;
> @@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
>      if ( unlikely(inst_len > 15) )
>      {
>          gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);=

> -        domain_crash(curr->domain);
> +        svm_crash_or_gp(curr);
>          return;
>      }
> =20
> @@ -1505,7 +1514,7 @@ static void svm_do_nested_pgfault(struct
>      gdprintk(XENLOG_ERR,
>           "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
>           gpa, mfn_x(mfn), p2mt);
> -    domain_crash(v->domain);
> +    svm_crash_or_gp(v);
>  }
> =20
>  static void svm_fpu_dirty_intercept(void)
> @@ -2647,7 +2656,7 @@ void svm_vmexit_handler(struct cpu_user_
>              printk(XENLOG_G_ERR
>                     "%pv: Error %d handling NPF (gpa=3D%08lx ec=3D%04lx=
)\n",
>                     v, rc, vmcb->exitinfo2, vmcb->exitinfo1);
> -            domain_crash(v->domain);
> +            svm_crash_or_gp(v);
>          }
>          v->arch.hvm_svm.cached_insn_len =3D 0;
>          break;
> @@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
>                   "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n=
",
>                   exit_reason,=20
>                   (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
> -        if ( vmcb_get_cpl(vmcb) )
> -            hvm_inject_hw_exception(TRAP_invalid_op,
> -                                    HVM_DELIVER_NO_ERROR_CODE);
> -        else
> -            domain_crash(v->domain);
> +        svm_crash_or_gp(v);
>          break;
>      }
> =20
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
>      passive_domain_destroy(v);
>  }
> =20
> +/* Only crash the guest if the problem originates in kernel mode. */
> +static void vmx_crash_or_gp(struct vcpu *v)
> +{
> +    struct segment_register ss;
> +
> +    vmx_get_segment_register(v, x86_seg_ss, &ss);
> +    if ( ss.attr.fields.dpl )
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_=
CODE);
> +    else
> +        domain_crash(v->domain);
> +}
> +
>  static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
> =20
>  static const u32 msr_index[] =3D
> @@ -2474,7 +2486,7 @@ static void ept_handle_violation(unsigne
>      if ( qualification & EPT_GLA_VALID )
>          gdprintk(XENLOG_ERR, " --- GLA %#lx\n", gla);
> =20
> -    domain_crash(d);
> +    vmx_crash_or_gp(current);
>  }
> =20
>  static void vmx_failed_vmentry(unsigned int exit_reason,
> @@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned=20
>      vmcs_dump_vcpu(curr);
>      printk("**************************************\n");
> =20
> -    domain_crash(curr->domain);
> +    vmx_crash_or_gp(curr);
>  }
> =20
>  void vmx_enter_realmode(struct cpu_user_regs *regs)
> @@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
>      /* fall through */
>      default:
>      exit_and_crash:
> -        {
> -            struct segment_register ss;
> -
> -            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
> -                     exit_reason);
> -
> -            vmx_get_segment_register(v, x86_seg_ss, &ss);
> -            if ( ss.attr.fields.dpl )
> -                hvm_inject_hw_exception(TRAP_invalid_op,
> -                                        HVM_DELIVER_NO_ERROR_CODE);
> -            else
> -                domain_crash(v->domain);
> -        }
> +        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_re=
ason);
> +        vmx_crash_or_gp(v);
>          break;
>      }
> =20
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------010300060402080808010406
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 20/11/14 10:13, Jan Beulich wrote:<br>
    </div>
    <blockquote cite="mid:546DCCC202000078000493F8@smtp.nue.novell.com"
      type="cite">
      <pre wrap="">This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
exit occurred in guest kernel mode") to further cases, including the
failed VM entry one that XSA-110 was needed to be issued for.

Signed-off-by: Jan Beulich <a class="moz-txt-link-rfc2396E" href="mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a>

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
 static uint64_t osvw_length, osvw_status;
 static DEFINE_SPINLOCK(osvw_lock);
 
+/* Only crash the guest if the problem originates in kernel mode. */
+static void svm_crash_or_gp(struct vcpu *v)
+{
+    if ( vmcb_get_cpl(v-&gt;arch.hvm_svm.vmcb) )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);</pre>
    </blockquote>
    <br>
    This (and its VMX counterpart) should either deliver a #GP fault, or
    have its name changed to not imply a #GP fault.<br>
    <br>
    How about "crash_or_fault()" as an alternative which is slightly
    less specific?<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote cite="mid:546DCCC202000078000493F8@smtp.nue.novell.com"
      type="cite">
      <pre wrap="">
+    else
+        domain_crash(v-&gt;domain);
+}
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
     if ( unlikely(inst_len &gt; 15) )
     {
         gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);
-        domain_crash(curr-&gt;domain);
+        svm_crash_or_gp(curr);
         return;
     }
 
@@ -1505,7 +1514,7 @@ static void svm_do_nested_pgfault(struct
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
          gpa, mfn_x(mfn), p2mt);
-    domain_crash(v-&gt;domain);
+    svm_crash_or_gp(v);
 }
 
 static void svm_fpu_dirty_intercept(void)
@@ -2647,7 +2656,7 @@ void svm_vmexit_handler(struct cpu_user_
             printk(XENLOG_G_ERR
                    "%pv: Error %d handling NPF (gpa=%08lx ec=%04lx)\n",
                    v, rc, vmcb-&gt;exitinfo2, vmcb-&gt;exitinfo1);
-            domain_crash(v-&gt;domain);
+            svm_crash_or_gp(v);
         }
         v-&gt;arch.hvm_svm.cached_insn_len = 0;
         break;
@@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
                  "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
                  exit_reason, 
                  (u64)vmcb-&gt;exitinfo1, (u64)vmcb-&gt;exitinfo2);
-        if ( vmcb_get_cpl(vmcb) )
-            hvm_inject_hw_exception(TRAP_invalid_op,
-                                    HVM_DELIVER_NO_ERROR_CODE);
-        else
-            domain_crash(v-&gt;domain);
+        svm_crash_or_gp(v);
         break;
     }
 
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
 
+/* Only crash the guest if the problem originates in kernel mode. */
+static void vmx_crash_or_gp(struct vcpu *v)
+{
+    struct segment_register ss;
+
+    vmx_get_segment_register(v, x86_seg_ss, &amp;ss);
+    if ( ss.attr.fields.dpl )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+    else
+        domain_crash(v-&gt;domain);
+}
+
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
 
 static const u32 msr_index[] =
@@ -2474,7 +2486,7 @@ static void ept_handle_violation(unsigne
     if ( qualification &amp; EPT_GLA_VALID )
         gdprintk(XENLOG_ERR, " --- GLA %#lx\n", gla);
 
-    domain_crash(d);
+    vmx_crash_or_gp(current);
 }
 
 static void vmx_failed_vmentry(unsigned int exit_reason,
@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned 
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
 
-    domain_crash(curr-&gt;domain);
+    vmx_crash_or_gp(curr);
 }
 
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        {
-            struct segment_register ss;
-
-            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
-                     exit_reason);
-
-            vmx_get_segment_register(v, x86_seg_ss, &amp;ss);
-            if ( ss.attr.fields.dpl )
-                hvm_inject_hw_exception(TRAP_invalid_op,
-                                        HVM_DELIVER_NO_ERROR_CODE);
-            else
-                domain_crash(v-&gt;domain);
-        }
+        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);
+        vmx_crash_or_gp(v);
         break;
     }
 


</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------010300060402080808010406--


--===============7262172203652596061==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7262172203652596061==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 11:09:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPbg-0001vY-RZ; Thu, 20 Nov 2014 11:09:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrPbg-0001vQ-A2
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 11:09:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0D/BF-09842-BCBCD645; Thu, 20 Nov 2014 11:08:59 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416481737!14099108!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7970 invoked from network); 20 Nov 2014 11:08:58 -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;
	20 Nov 2014 11:08:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194747639"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:08:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrPbc-00019d-P7;
	Thu, 20 Nov 2014 11:08:56 +0000
Date: Thu, 20 Nov 2014 11:08:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <546DCA3F.2030508@linaro.org>
Message-ID: <alpine.DEB.2.02.1411201107010.12596@kaball.uk.xensource.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<546DCA3F.2030508@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: julien.grall@citrix.com, andrii.tseglytskyi@globallogic.com,
	xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Julien Grall wrote:
> Hi Stefano,
> 
> On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
> > UIE being set can cause maintenance interrupts to occur when Xen writes
> > to one or more LR registers. The effect is a busy loop around the
> > interrupt handler in Xen
> > (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > CC: konrad.wilk@oracle.com
> > ---
> > 
> > Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> > bad side effects on any other platforms as far as I can tell. It should
> > go in 4.5.
> 
> >From Andrii's mail, there is a bad side effect. We can receive spurious
> interrupt.

The spurious interrupt is the maintenance interrupt.
There is not one more spurious interrupt notification in addition to the
maintenance interrupt.


> On V1, you said that you tried this patch on midway. I would prefer if
> you give a try on  platform that would really be used (such as xgene or
> seattle). As we know Midway won't be used in prod.

OK


> Regards,
> 
> > Changes in v2:
> > 
> > - add an in-code comment about maintenance_interrupt not being called.
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 70d10d6..c6c11d3 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
> >      if ( is_idle_vcpu(v) )
> >          return;
> >  
> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> > +
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >  
> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> > @@ -527,8 +529,6 @@ void gic_inject(void)
> >  
> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> > -    else
> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >  }
> >  
> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> > @@ -598,6 +598,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >       * Receiving the interrupt is going to cause gic_inject to be called
> >       * on return to guest that is going to clear the old LRs and inject
> >       * new interrupts.
> > +     *
> > +     * Do not add code here: maintenance interrupts caused by setting
> > +     * GICH_HCR_UIE, might read as spurious interrupts (1023). As a
> > +     * consequence sometimes this handler might not be called.
> >       */
> >  }
> >  
> > 
> 
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:09:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPbg-0001vY-RZ; Thu, 20 Nov 2014 11:09:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrPbg-0001vQ-A2
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 11:09:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0D/BF-09842-BCBCD645; Thu, 20 Nov 2014 11:08:59 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416481737!14099108!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7970 invoked from network); 20 Nov 2014 11:08:58 -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;
	20 Nov 2014 11:08:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194747639"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:08:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrPbc-00019d-P7;
	Thu, 20 Nov 2014 11:08:56 +0000
Date: Thu, 20 Nov 2014 11:08:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <546DCA3F.2030508@linaro.org>
Message-ID: <alpine.DEB.2.02.1411201107010.12596@kaball.uk.xensource.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<546DCA3F.2030508@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: julien.grall@citrix.com, andrii.tseglytskyi@globallogic.com,
	xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Julien Grall wrote:
> Hi Stefano,
> 
> On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
> > UIE being set can cause maintenance interrupts to occur when Xen writes
> > to one or more LR registers. The effect is a busy loop around the
> > interrupt handler in Xen
> > (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > CC: konrad.wilk@oracle.com
> > ---
> > 
> > Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> > bad side effects on any other platforms as far as I can tell. It should
> > go in 4.5.
> 
> >From Andrii's mail, there is a bad side effect. We can receive spurious
> interrupt.

The spurious interrupt is the maintenance interrupt.
There is not one more spurious interrupt notification in addition to the
maintenance interrupt.


> On V1, you said that you tried this patch on midway. I would prefer if
> you give a try on  platform that would really be used (such as xgene or
> seattle). As we know Midway won't be used in prod.

OK


> Regards,
> 
> > Changes in v2:
> > 
> > - add an in-code comment about maintenance_interrupt not being called.
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 70d10d6..c6c11d3 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
> >      if ( is_idle_vcpu(v) )
> >          return;
> >  
> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> > +
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >  
> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> > @@ -527,8 +529,6 @@ void gic_inject(void)
> >  
> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> > -    else
> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >  }
> >  
> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> > @@ -598,6 +598,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >       * Receiving the interrupt is going to cause gic_inject to be called
> >       * on return to guest that is going to clear the old LRs and inject
> >       * new interrupts.
> > +     *
> > +     * Do not add code here: maintenance interrupts caused by setting
> > +     * GICH_HCR_UIE, might read as spurious interrupts (1023). As a
> > +     * consequence sometimes this handler might not be called.
> >       */
> >  }
> >  
> > 
> 
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:14:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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 1XrPhF-00028N-L1; Thu, 20 Nov 2014 11:14:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPhE-00028I-DA
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:14:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	27/4B-09842-32DCD645; Thu, 20 Nov 2014 11:14:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416482083!14156680!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25201 invoked from network); 20 Nov 2014 11:14:43 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 11:14:43 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 12:14:42 +0100
Message-Id: <546DDB3202000078000494A0@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 12:14:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
	<546DCB34.8030302@citrix.com>
In-Reply-To: <546DCB34.8030302@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.11.14 at 12:06, <andrew.cooper3@citrix.com> wrote:
> On 20/11/14 10:13, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
>>  static uint64_t osvw_length, osvw_status;
>>  static DEFINE_SPINLOCK(osvw_lock);
>>  
>> +/* Only crash the guest if the problem originates in kernel mode. */
>> +static void svm_crash_or_gp(struct vcpu *v)
>> +{
>> +    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
>> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> 
> This (and its VMX counterpart) should either deliver a #GP fault, or
> have its name changed to not imply a #GP fault.

Indeed - not sure how I managed to get this mixed up.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:14:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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 1XrPhF-00028N-L1; Thu, 20 Nov 2014 11:14:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPhE-00028I-DA
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:14:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	27/4B-09842-32DCD645; Thu, 20 Nov 2014 11:14:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416482083!14156680!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25201 invoked from network); 20 Nov 2014 11:14:43 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 11:14:43 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 12:14:42 +0100
Message-Id: <546DDB3202000078000494A0@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 12:14:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
	<546DCB34.8030302@citrix.com>
In-Reply-To: <546DCB34.8030302@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.11.14 at 12:06, <andrew.cooper3@citrix.com> wrote:
> On 20/11/14 10:13, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
>>  static uint64_t osvw_length, osvw_status;
>>  static DEFINE_SPINLOCK(osvw_lock);
>>  
>> +/* Only crash the guest if the problem originates in kernel mode. */
>> +static void svm_crash_or_gp(struct vcpu *v)
>> +{
>> +    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
>> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> 
> This (and its VMX counterpart) should either deliver a #GP fault, or
> have its name changed to not imply a #GP fault.

Indeed - not sure how I managed to get this mixed up.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:15:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:15:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPhs-0002At-3C; Thu, 20 Nov 2014 11:15:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPhq-0002Ah-KJ
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:15:22 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BA/7C-25276-A4DCD645; Thu, 20 Nov 2014 11:15:22 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416482121!11983862!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12757 invoked from network); 20 Nov 2014 11:15:21 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:15:21 -0000
Received: by mail-wg0-f49.google.com with SMTP id x12so3367570wgg.8
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 03:15:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=ujSwEByVr0a8zsYQVDi69KFtw6bJw6mGTEfpCwyWHBc=;
	b=i/j0rTsJTGlFMtpiwAeTU6XEVpDkjk6W3xrSC0kS7B5mzipzE7Twcdy1aiY7ihAthy
	yNe3zo3bPMByBvm55I52BtWfU57O+md6ztn+YDp5EjQJndX6CIpE4b6/R7Aw2cn0k5LH
	30Lhm7VOdQnMNQDugn1/xLSNuw6d6wKRxg/gerxaI6I8b1n87CZPTHZbTbjpA3wGXmJi
	QV9dxKDXI7dZ3dH8JIuEED5ctMpFkc6JDCNCpMtUDR1/dxEsH02V2OS9DQ2LVwm677jj
	cKp4LBO2IvIRh76SE00trCiTTjmSviwg0+0LBzKMhx/Rg9iAeMz//8DK4xMKvnHW1AlC
	zyHg==
X-Gm-Message-State: ALoCoQl/QNihCXW8lWjtvvoIabFCEg/C7qX2VTdaS+b4UbjHD5an6MzjCJyOkyi7dw+FsBIMCpkX
X-Received: by 10.180.182.233 with SMTP id eh9mr3278027wic.31.1416482121131;
	Thu, 20 Nov 2014 03:15:21 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id a8sm6143670wiz.21.2014.11.20.03.15.19
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:15:20 -0800 (PST)
Message-ID: <546DCD46.8000105@linaro.org>
Date: Thu, 20 Nov 2014 11:15:18 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
	<CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
	<alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
Content-Length: 3113
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTEvMjAvMjAxNCAxMDoyOCBBTSwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOgo+IE9uIFdl
ZCwgMTkgTm92IDIwMTQsIEFuZHJpaSBUc2VnbHl0c2t5aSB3cm90ZToKPj4gMTkg0LvQuNGB0YIu
IDIwMTQgMjA6MzIsINC60L7RgNC40YHRgtGD0LLQsNGHICJTdGVmYW5vIFN0YWJlbGxpbmkiIDxz
dGVmYW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT4g0L3QsNC/0LjRgdCw0LI6Cj4+Pgo+Pj4g
T24gV2VkLCAxOSBOb3YgMjAxNCwgSnVsaWVuIEdyYWxsIHdyb3RlOgo+Pj4+IE9uIDExLzE5LzIw
MTQgMDY6MTQgUE0sIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToKPj4+Pj4gVGhhdCdzIHJpZ2h0
LCB0aGUgbWFpbnRlbmFuY2UgaW50ZXJydXB0IGhhbmRsZXIgaXMgbm90IGNhbGxlZCwgYnV0IGl0
Cj4+Pj4+IGRvZXNuJ3QgZG8gYW55dGhpbmcgc28gd2UgYXJlIGZpbmUuIFRoZSBpbXBvcnRhbnQg
dGhpbmcgaXMgdGhhdCBhbgo+Pj4+PiBpbnRlcnJ1cHQgaXMgc2VudCBhbmQgZ2l0X2NsZWFyX2xy
cyBnZXRzIGNhbGxlZCBvbiBoeXBlcnZpc29yIGVudHJ5Lgo+Pj4+Cj4+Pj4gSXQgd291bGQgYmUg
d29ydGggdG8gd3JpdGUgZG93biB0aGlzIHNvbWV3aGVyZS4gSnVzdCBpbiBjYXNlIHNvbWVvbmUK
Pj4+PiBkZWNpZGUgdG8gYWRkIGNvZGUgaW4gbWFpbnRlbmFuY2UgaW50ZXJydXB0IGxhdGVyLgo+
Pj4KPj4+IFllcywgSSBjb3VsZCBhZGQgYSBjb21tZW50IGluIHRoZSBoYW5kbGVyCj4+Cj4+IE1h
eWJlIGl0IHdvdWxkbid0IHRha2UgYSBsb3Qgb2YgZWZmb3J0IHRvIGZpeCBpdD8gSSBhbSBqdXN0
IHdvcnJ5aW5nIHRoYXQgd2UgbWF5IGhpZGUgc29tZSBpc3N1ZSAtCj4+IHR5cGljYWxseSBzcHVy
aW91cyBpbnRlcnJ1cHQgdGhpcyBub3Qgd2hhdCBpcyBleHBlY3RlZC4KPiAKPiBNeSBndWVzcyBp
cyB0aGF0IGJ5IGNsZWFyaW5nIFVJRSBiZWZvcmUgcmVhZGluZyBHSUNDX0lBUiwgd2UgImNsZWFy
IiB0aGUKPiBtYWludGVuYW5jZSBpbnRlcnJ1cHQgdG9vLCBhcyBhIGNvbnNlcXVlbmNlIHRoZSBm
b2xsb3dpbmcgcmVhZCB0bwo+IEdJQ0NfSUFSIHdvdWxkIHJldHVybiAxMDIzIChub3RoaW5nIHRv
IGJlIHJlYWQpLiBBcyBiaXQgYXMgaWYgdGhlCj4gbWFpbnRlbmFuY2UgaW50ZXJydXB0IHdhcyBh
IGxldmVsIGludGVycnVwdCBhbmQgd2UganVzdCBkaXNhYmxlZCBpdC4KPiAKPiBTbyBJIHRoaW5r
IHRoYXQgaWYgd2UgY2xlYXJlZCBVSUUgYWZ0ZXIgcmVhZGluZyBHSUNDX0lBUiwgR0lDQ19JQVIg
d291bGQKPiByZXR1cm4gdGhlIGNvcnJlY3QgdmFsdWUuCj4gCj4gSG93ZXZlciB3aXRoIHRoZSBj
dXJyZW50IHN0cnVjdHVyZSBvZiB0aGUgY29kZSwgdGhlIGZpcnN0IHRoaW5nIHRoYXQgd2UKPiBk
byB1cG9uIGVudGVyaW5nIHRoZSBoeXBlcnZpc29yIGlzIGNsZWFyaW5nIExScyBhbmQgZ2l2ZW4g
d2hhdCBoYXBwZW5lZAo+IG9uIHlvdXIgcGxhdGZvcm0gSSB0aGluayBpcyBhIGdvb2QgaWRlYSB0
byBkbyBpdCB3aXRoIFVJRSBkaXNhYmxlZC4KCkFncmVlZC4gVUlFIHNob3VsZCBiZSBkaXNhYmxl
ZCB0byBhdm9pZCBhbm90aGVyIG1haW50ZW5hbmNlIGludGVycnVwdCBhcwpzb29uIGFzIHdlIEVP
SSB0aGUgSVJRLgoKPiBUaGlzIGlzIHdheSBJIHdvdWxkIHJhdGhlciByZWFkIHNwdXJpb3VzIGlu
dGVycnVwdHMgYnV0IHJlYWQvd3JpdGUgTFJzCj4gd2l0aCBVSUUgZGlzYWJsZWQgdGhhbiByZWFk
aW5nIG1haW50ZW5hbmNlIGludGVycnVwdHMgYnV0IHJpc2tpbmcKPiBzdHJhbmdlIGJlaGF2aW91
cnMgb24gc29tZSBwbGF0Zm9ybXMuCgpSZWFkaW5nIHRoZSBHSUMtdjIgZG9jdW1lbnRhdGlvbiwg
dGhlIHNwdXJpb3VzIGludGVycnVwdCB0aGluZ3Mgc2hvdWxkCmhhcHBlbiBvbiBhbnkgcGxhdGZv
cm0gZXZlcnkgdGltZSB0aGUgVUlFIGlzIGRpc2FibGVkIHdoaWxlIHdlIHJlY2VpdmUgYQptYWlu
dGVuYW5jZSBpbnRlcnJ1cHQuCgoiVGhlIHJlYWQgcmV0dXJucyBhIHNwdXJpb3VzIGludGVycnVw
dCBJRCBvZiAxMDIzIGlmIGFueSBvZiB0aGUKZm9sbG93aW5nIGFwcGx5OgoKLSBubyBwZW5kaW5n
IGludGVycnVwdCBvbiB0aGUgQ1BVIGludGVyZmFjZSBoYXMgc3VmZmljaWVudCBwcmlvcml0eSBm
b3IKdGhlIGludGVyZmFjZSB0byBzaWduYWwgaXQgdG8gdGhlIHByb2Nlc3NvciIKCi0tIApKdWxp
ZW4gR3JhbGwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:15:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:15:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPhs-0002At-3C; Thu, 20 Nov 2014 11:15:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPhq-0002Ah-KJ
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:15:22 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BA/7C-25276-A4DCD645; Thu, 20 Nov 2014 11:15:22 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416482121!11983862!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12757 invoked from network); 20 Nov 2014 11:15:21 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:15:21 -0000
Received: by mail-wg0-f49.google.com with SMTP id x12so3367570wgg.8
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 03:15:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=ujSwEByVr0a8zsYQVDi69KFtw6bJw6mGTEfpCwyWHBc=;
	b=i/j0rTsJTGlFMtpiwAeTU6XEVpDkjk6W3xrSC0kS7B5mzipzE7Twcdy1aiY7ihAthy
	yNe3zo3bPMByBvm55I52BtWfU57O+md6ztn+YDp5EjQJndX6CIpE4b6/R7Aw2cn0k5LH
	30Lhm7VOdQnMNQDugn1/xLSNuw6d6wKRxg/gerxaI6I8b1n87CZPTHZbTbjpA3wGXmJi
	QV9dxKDXI7dZ3dH8JIuEED5ctMpFkc6JDCNCpMtUDR1/dxEsH02V2OS9DQ2LVwm677jj
	cKp4LBO2IvIRh76SE00trCiTTjmSviwg0+0LBzKMhx/Rg9iAeMz//8DK4xMKvnHW1AlC
	zyHg==
X-Gm-Message-State: ALoCoQl/QNihCXW8lWjtvvoIabFCEg/C7qX2VTdaS+b4UbjHD5an6MzjCJyOkyi7dw+FsBIMCpkX
X-Received: by 10.180.182.233 with SMTP id eh9mr3278027wic.31.1416482121131;
	Thu, 20 Nov 2014 03:15:21 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id a8sm6143670wiz.21.2014.11.20.03.15.19
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:15:20 -0800 (PST)
Message-ID: <546DCD46.8000105@linaro.org>
Date: Thu, 20 Nov 2014 11:15:18 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
	<CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
	<alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
Content-Length: 3113
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTEvMjAvMjAxNCAxMDoyOCBBTSwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOgo+IE9uIFdl
ZCwgMTkgTm92IDIwMTQsIEFuZHJpaSBUc2VnbHl0c2t5aSB3cm90ZToKPj4gMTkg0LvQuNGB0YIu
IDIwMTQgMjA6MzIsINC60L7RgNC40YHRgtGD0LLQsNGHICJTdGVmYW5vIFN0YWJlbGxpbmkiIDxz
dGVmYW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT4g0L3QsNC/0LjRgdCw0LI6Cj4+Pgo+Pj4g
T24gV2VkLCAxOSBOb3YgMjAxNCwgSnVsaWVuIEdyYWxsIHdyb3RlOgo+Pj4+IE9uIDExLzE5LzIw
MTQgMDY6MTQgUE0sIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToKPj4+Pj4gVGhhdCdzIHJpZ2h0
LCB0aGUgbWFpbnRlbmFuY2UgaW50ZXJydXB0IGhhbmRsZXIgaXMgbm90IGNhbGxlZCwgYnV0IGl0
Cj4+Pj4+IGRvZXNuJ3QgZG8gYW55dGhpbmcgc28gd2UgYXJlIGZpbmUuIFRoZSBpbXBvcnRhbnQg
dGhpbmcgaXMgdGhhdCBhbgo+Pj4+PiBpbnRlcnJ1cHQgaXMgc2VudCBhbmQgZ2l0X2NsZWFyX2xy
cyBnZXRzIGNhbGxlZCBvbiBoeXBlcnZpc29yIGVudHJ5Lgo+Pj4+Cj4+Pj4gSXQgd291bGQgYmUg
d29ydGggdG8gd3JpdGUgZG93biB0aGlzIHNvbWV3aGVyZS4gSnVzdCBpbiBjYXNlIHNvbWVvbmUK
Pj4+PiBkZWNpZGUgdG8gYWRkIGNvZGUgaW4gbWFpbnRlbmFuY2UgaW50ZXJydXB0IGxhdGVyLgo+
Pj4KPj4+IFllcywgSSBjb3VsZCBhZGQgYSBjb21tZW50IGluIHRoZSBoYW5kbGVyCj4+Cj4+IE1h
eWJlIGl0IHdvdWxkbid0IHRha2UgYSBsb3Qgb2YgZWZmb3J0IHRvIGZpeCBpdD8gSSBhbSBqdXN0
IHdvcnJ5aW5nIHRoYXQgd2UgbWF5IGhpZGUgc29tZSBpc3N1ZSAtCj4+IHR5cGljYWxseSBzcHVy
aW91cyBpbnRlcnJ1cHQgdGhpcyBub3Qgd2hhdCBpcyBleHBlY3RlZC4KPiAKPiBNeSBndWVzcyBp
cyB0aGF0IGJ5IGNsZWFyaW5nIFVJRSBiZWZvcmUgcmVhZGluZyBHSUNDX0lBUiwgd2UgImNsZWFy
IiB0aGUKPiBtYWludGVuYW5jZSBpbnRlcnJ1cHQgdG9vLCBhcyBhIGNvbnNlcXVlbmNlIHRoZSBm
b2xsb3dpbmcgcmVhZCB0bwo+IEdJQ0NfSUFSIHdvdWxkIHJldHVybiAxMDIzIChub3RoaW5nIHRv
IGJlIHJlYWQpLiBBcyBiaXQgYXMgaWYgdGhlCj4gbWFpbnRlbmFuY2UgaW50ZXJydXB0IHdhcyBh
IGxldmVsIGludGVycnVwdCBhbmQgd2UganVzdCBkaXNhYmxlZCBpdC4KPiAKPiBTbyBJIHRoaW5r
IHRoYXQgaWYgd2UgY2xlYXJlZCBVSUUgYWZ0ZXIgcmVhZGluZyBHSUNDX0lBUiwgR0lDQ19JQVIg
d291bGQKPiByZXR1cm4gdGhlIGNvcnJlY3QgdmFsdWUuCj4gCj4gSG93ZXZlciB3aXRoIHRoZSBj
dXJyZW50IHN0cnVjdHVyZSBvZiB0aGUgY29kZSwgdGhlIGZpcnN0IHRoaW5nIHRoYXQgd2UKPiBk
byB1cG9uIGVudGVyaW5nIHRoZSBoeXBlcnZpc29yIGlzIGNsZWFyaW5nIExScyBhbmQgZ2l2ZW4g
d2hhdCBoYXBwZW5lZAo+IG9uIHlvdXIgcGxhdGZvcm0gSSB0aGluayBpcyBhIGdvb2QgaWRlYSB0
byBkbyBpdCB3aXRoIFVJRSBkaXNhYmxlZC4KCkFncmVlZC4gVUlFIHNob3VsZCBiZSBkaXNhYmxl
ZCB0byBhdm9pZCBhbm90aGVyIG1haW50ZW5hbmNlIGludGVycnVwdCBhcwpzb29uIGFzIHdlIEVP
SSB0aGUgSVJRLgoKPiBUaGlzIGlzIHdheSBJIHdvdWxkIHJhdGhlciByZWFkIHNwdXJpb3VzIGlu
dGVycnVwdHMgYnV0IHJlYWQvd3JpdGUgTFJzCj4gd2l0aCBVSUUgZGlzYWJsZWQgdGhhbiByZWFk
aW5nIG1haW50ZW5hbmNlIGludGVycnVwdHMgYnV0IHJpc2tpbmcKPiBzdHJhbmdlIGJlaGF2aW91
cnMgb24gc29tZSBwbGF0Zm9ybXMuCgpSZWFkaW5nIHRoZSBHSUMtdjIgZG9jdW1lbnRhdGlvbiwg
dGhlIHNwdXJpb3VzIGludGVycnVwdCB0aGluZ3Mgc2hvdWxkCmhhcHBlbiBvbiBhbnkgcGxhdGZv
cm0gZXZlcnkgdGltZSB0aGUgVUlFIGlzIGRpc2FibGVkIHdoaWxlIHdlIHJlY2VpdmUgYQptYWlu
dGVuYW5jZSBpbnRlcnJ1cHQuCgoiVGhlIHJlYWQgcmV0dXJucyBhIHNwdXJpb3VzIGludGVycnVw
dCBJRCBvZiAxMDIzIGlmIGFueSBvZiB0aGUKZm9sbG93aW5nIGFwcGx5OgoKLSBubyBwZW5kaW5n
IGludGVycnVwdCBvbiB0aGUgQ1BVIGludGVyZmFjZSBoYXMgc3VmZmljaWVudCBwcmlvcml0eSBm
b3IKdGhlIGludGVyZmFjZSB0byBzaWduYWwgaXQgdG8gdGhlIHByb2Nlc3NvciIKCi0tIApKdWxp
ZW4gR3JhbGwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:17:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:17:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPjy-0002O2-48; Thu, 20 Nov 2014 11:17:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPjw-0002Nv-Tc
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:17:33 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	F2/8E-24859-CCDCD645; Thu, 20 Nov 2014 11:17:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416482251!8245518!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15850 invoked from network); 20 Nov 2014 11:17:31 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 11:17:31 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 12:17:31 +0100
Message-Id: <546DDBDA02000078000494AF@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 12:17:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <1416327994-29619-1-git-send-email-olaf@aepfle.de>
	<21611.30074.302907.667308@mariner.uk.xensource.com>
	<20141119073524.GA21195@aepfle.de>
In-Reply-To: <20141119073524.GA21195@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: use more fixed strings to build 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 19.11.14 at 08:35, <olaf@aepfle.de> wrote:
> On Tue, Nov 18, Ian Jackson wrote:
> 
>> How about
>> 
>>    It should be possible to repeatedly build identical sources
>>    and get identical binaries, even on different hosts at different
>>    build times.  This fails [etc. etc. ...]
>> 
>>    Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and XEN_BUILD_HOST
>>    which the build environment can set to fixed strings to get a
>>    reproducible build.
>> 
>> or some such.
> 
> Thanks. Do you want me to resend with this updated changelog, or will it
> be used while applying?

Please resend.

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 Nov 20 11:17:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:17:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPjy-0002O2-48; Thu, 20 Nov 2014 11:17:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPjw-0002Nv-Tc
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:17:33 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	F2/8E-24859-CCDCD645; Thu, 20 Nov 2014 11:17:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416482251!8245518!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15850 invoked from network); 20 Nov 2014 11:17:31 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 11:17:31 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 12:17:31 +0100
Message-Id: <546DDBDA02000078000494AF@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 12:17:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <1416327994-29619-1-git-send-email-olaf@aepfle.de>
	<21611.30074.302907.667308@mariner.uk.xensource.com>
	<20141119073524.GA21195@aepfle.de>
In-Reply-To: <20141119073524.GA21195@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: use more fixed strings to build 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 19.11.14 at 08:35, <olaf@aepfle.de> wrote:
> On Tue, Nov 18, Ian Jackson wrote:
> 
>> How about
>> 
>>    It should be possible to repeatedly build identical sources
>>    and get identical binaries, even on different hosts at different
>>    build times.  This fails [etc. etc. ...]
>> 
>>    Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and XEN_BUILD_HOST
>>    which the build environment can set to fixed strings to get a
>>    reproducible build.
>> 
>> or some such.
> 
> Thanks. Do you want me to resend with this updated changelog, or will it
> be used while applying?

Please resend.

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 Nov 20 11:18:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPkd-0002UL-Hg; Thu, 20 Nov 2014 11:18:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPkb-0002U1-Qo
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:18:13 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	1C/F2-02559-5FDCD645; Thu, 20 Nov 2014 11:18:13 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416482292!13704876!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9361 invoked from network); 20 Nov 2014 11:18:12 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:18:12 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so3441612wgh.2
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 03:18:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=6oyHByHVyCWBI87uTWo/8Q6K/S91Z1CwX4/dAZklMiI=;
	b=CSnES1611C0TGDYvji73I6XUqzZuXIy26NxQvdyq/1VdozOcTcerq89/3A9mjYomuX
	ldhJDbrxB1LCM/viSp7VUbyZe+LQADl26GyBwqKhvhB5MF7qPd4ZgMbfS1subbMgj6cn
	Ron8RLd6K2X1s11if7V7xs7KOurspcZnrww1sPM4mglgRO+5k1ED7bZ57J9wro+7lkFt
	rrv3id0R7Z+rcFCt7U44NL4VL2Mip90Z51Lmm0ci1q3ewiiZmzEzr2pB9XyjAvL1OnJP
	VZu+r0NcDAVpCNedMwxNjNxuOX3Zr28HhxnyoQnTIKhnccFMAIKEv0HmTXpAiDLqGqwJ
	QYvg==
X-Gm-Message-State: ALoCoQkmuRbfqYZJkmAsIn0cNd5VF5QE/IYc1fLLBbgMLN2XYD4LYrrcClxa1c5Od8JR5pCn6q2F
X-Received: by 10.194.193.38 with SMTP id hl6mr22485270wjc.38.1416482292275;
	Thu, 20 Nov 2014 03:18:12 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id hz9sm588228wjb.17.2014.11.20.03.18.10
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:18:11 -0800 (PST)
Message-ID: <546DCDF2.3050704@linaro.org>
Date: Thu, 20 Nov 2014 11:18:10 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416410895-20461-1-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 1/5] xen: arm: Add earlyprintk
	for McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/19/2014 03:28 PM, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


> ---
> v2: Remove pointless/unused baud rate setting.
> 
> A bunch of other entries have these, but cleaning them up is out of scope here I think.

Agreed.

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

> ---
>  xen/arch/arm/Rules.mk |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index 572d854..30c7823 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -95,6 +95,11 @@ EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0x1c020000
>  EARLY_UART_REG_SHIFT := 2
>  endif
> +ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
> +EARLY_PRINTK_INC := 8250
> +EARLY_UART_BASE_ADDRESS := 0x1c021000
> +EARLY_UART_REG_SHIFT := 2
> +endif
>  ifeq ($(CONFIG_EARLY_PRINTK), juno)
>  EARLY_PRINTK_INC := pl011
>  EARLY_PRINTK_BAUD := 115200
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:18:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPkd-0002UL-Hg; Thu, 20 Nov 2014 11:18:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPkb-0002U1-Qo
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:18:13 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	1C/F2-02559-5FDCD645; Thu, 20 Nov 2014 11:18:13 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416482292!13704876!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9361 invoked from network); 20 Nov 2014 11:18:12 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:18:12 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so3441612wgh.2
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 03:18:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=6oyHByHVyCWBI87uTWo/8Q6K/S91Z1CwX4/dAZklMiI=;
	b=CSnES1611C0TGDYvji73I6XUqzZuXIy26NxQvdyq/1VdozOcTcerq89/3A9mjYomuX
	ldhJDbrxB1LCM/viSp7VUbyZe+LQADl26GyBwqKhvhB5MF7qPd4ZgMbfS1subbMgj6cn
	Ron8RLd6K2X1s11if7V7xs7KOurspcZnrww1sPM4mglgRO+5k1ED7bZ57J9wro+7lkFt
	rrv3id0R7Z+rcFCt7U44NL4VL2Mip90Z51Lmm0ci1q3ewiiZmzEzr2pB9XyjAvL1OnJP
	VZu+r0NcDAVpCNedMwxNjNxuOX3Zr28HhxnyoQnTIKhnccFMAIKEv0HmTXpAiDLqGqwJ
	QYvg==
X-Gm-Message-State: ALoCoQkmuRbfqYZJkmAsIn0cNd5VF5QE/IYc1fLLBbgMLN2XYD4LYrrcClxa1c5Od8JR5pCn6q2F
X-Received: by 10.194.193.38 with SMTP id hl6mr22485270wjc.38.1416482292275;
	Thu, 20 Nov 2014 03:18:12 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id hz9sm588228wjb.17.2014.11.20.03.18.10
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:18:11 -0800 (PST)
Message-ID: <546DCDF2.3050704@linaro.org>
Date: Thu, 20 Nov 2014 11:18:10 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416410895-20461-1-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 1/5] xen: arm: Add earlyprintk
	for McDivitt.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/19/2014 03:28 PM, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


> ---
> v2: Remove pointless/unused baud rate setting.
> 
> A bunch of other entries have these, but cleaning them up is out of scope here I think.

Agreed.

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

> ---
>  xen/arch/arm/Rules.mk |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index 572d854..30c7823 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -95,6 +95,11 @@ EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0x1c020000
>  EARLY_UART_REG_SHIFT := 2
>  endif
> +ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
> +EARLY_PRINTK_INC := 8250
> +EARLY_UART_BASE_ADDRESS := 0x1c021000
> +EARLY_UART_REG_SHIFT := 2
> +endif
>  ifeq ($(CONFIG_EARLY_PRINTK), juno)
>  EARLY_PRINTK_INC := pl011
>  EARLY_PRINTK_BAUD := 115200
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:20:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPn5-0002iL-3W; Thu, 20 Nov 2014 11:20:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPn3-0002i5-0w
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:20:45 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	2B/80-02698-C8ECD645; Thu, 20 Nov 2014 11:20:44 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416482443!13709488!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21963 invoked from network); 20 Nov 2014 11:20:43 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:20:43 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so3420796wgh.31
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 03:20:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=DWPifSk4iKrXtLR7qmaYrJZhArgyCkJsYrzEK69lmx0=;
	b=cliPA8SSU5j/cLwD6rDCdDauLXLap+kRWlAdeKQ2p75A1xbIf1qjvMIkCXv6BzBbaN
	xTaa9gYJTyft65RT9pyxtCsnAciUoP3Y0r3ud1XCgj0IsnJABrLWlvz7fpsKQr/VF/Ps
	d7Wd7jmqS5Ao98uwVB8DYsWauVhjfTweu4a03xRX3C8bqb7E/lTLb3sORxYWIkLksAr5
	/Xi46ZtmgCzfvwj7vVInNLCn0aO5tMPozra5sIf82cLynqsALpI3I+yE6ndJAvysyCsa
	yfiY55qzVyW24WmA2quSGTh2bbTzp9GwTfmhCTTS8TPNv6U4Iqe0Owy1fZetR11W5+Dc
	/pdg==
X-Gm-Message-State: ALoCoQl8mNHQwgf3HeegKGZ8iJRKLAPgLz953vqNtZym04zLE5/bNkvhUKYkDSMzfQCH3QiotwLI
X-Received: by 10.194.5.227 with SMTP id v3mr68868184wjv.63.1416482443393;
	Thu, 20 Nov 2014 03:20:43 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id h8sm3618969wiy.17.2014.11.20.03.20.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:20:42 -0800 (PST)
Message-ID: <546DCE89.5010505@linaro.org>
Date: Thu, 20 Nov 2014 11:20:41 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-2-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416410895-20461-2-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 2/5] xen: arm: Drop
 EARLY_PRINTK_BAUD from entries which don't set ..._INIT_UART
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/19/2014 03:28 PM, Ian Campbell wrote:
> EARLY_PRINTK_BAUD doesn't do anything unless EARLY_PRINTK_INIT_UART is set.
> 
> Furthermore only the pl011 driver implements the init routine at all, so the
> entries which use 8250 and specified a BAUD were doubly wrong.

NIT: and exynos4210

Maybe "use 8250" should be replaced by "other UARTs drivers"?

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,


> ---
> v2: New patch.
> ---
>  xen/arch/arm/Rules.mk |    7 -------
>  1 file changed, 7 deletions(-)
> 
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index 30c7823..4ee51a9 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -45,7 +45,6 @@ ifeq ($(debug),y)
>  # Early printk for versatile express
>  ifeq ($(CONFIG_EARLY_PRINTK), vexpress)
>  EARLY_PRINTK_INC := pl011
> -EARLY_PRINTK_BAUD := 38400
>  EARLY_UART_BASE_ADDRESS := 0x1c090000
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), fastmodel)
> @@ -56,12 +55,10 @@ EARLY_UART_BASE_ADDRESS := 0x1c090000
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), exynos5250)
>  EARLY_PRINTK_INC := exynos4210
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0x12c20000
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), midway)
>  EARLY_PRINTK_INC := pl011
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0xfff36000
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), omap5432)
> @@ -91,7 +88,6 @@ EARLY_UART_REG_SHIFT := 2
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), xgene-storm)
>  EARLY_PRINTK_INC := 8250
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0x1c020000
>  EARLY_UART_REG_SHIFT := 2
>  endif
> @@ -102,18 +98,15 @@ EARLY_UART_REG_SHIFT := 2
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), juno)
>  EARLY_PRINTK_INC := pl011
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0x7ff80000
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), hip04-d01)
>  EARLY_PRINTK_INC := 8250
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0xE4007000
>  EARLY_UART_REG_SHIFT := 2
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), seattle)
>  EARLY_PRINTK_INC := pl011
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0xe1010000
>  endif
>  
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:20:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPn5-0002iL-3W; Thu, 20 Nov 2014 11:20:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPn3-0002i5-0w
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:20:45 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	2B/80-02698-C8ECD645; Thu, 20 Nov 2014 11:20:44 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416482443!13709488!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21963 invoked from network); 20 Nov 2014 11:20:43 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:20:43 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so3420796wgh.31
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 03:20:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=DWPifSk4iKrXtLR7qmaYrJZhArgyCkJsYrzEK69lmx0=;
	b=cliPA8SSU5j/cLwD6rDCdDauLXLap+kRWlAdeKQ2p75A1xbIf1qjvMIkCXv6BzBbaN
	xTaa9gYJTyft65RT9pyxtCsnAciUoP3Y0r3ud1XCgj0IsnJABrLWlvz7fpsKQr/VF/Ps
	d7Wd7jmqS5Ao98uwVB8DYsWauVhjfTweu4a03xRX3C8bqb7E/lTLb3sORxYWIkLksAr5
	/Xi46ZtmgCzfvwj7vVInNLCn0aO5tMPozra5sIf82cLynqsALpI3I+yE6ndJAvysyCsa
	yfiY55qzVyW24WmA2quSGTh2bbTzp9GwTfmhCTTS8TPNv6U4Iqe0Owy1fZetR11W5+Dc
	/pdg==
X-Gm-Message-State: ALoCoQl8mNHQwgf3HeegKGZ8iJRKLAPgLz953vqNtZym04zLE5/bNkvhUKYkDSMzfQCH3QiotwLI
X-Received: by 10.194.5.227 with SMTP id v3mr68868184wjv.63.1416482443393;
	Thu, 20 Nov 2014 03:20:43 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id h8sm3618969wiy.17.2014.11.20.03.20.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:20:42 -0800 (PST)
Message-ID: <546DCE89.5010505@linaro.org>
Date: Thu, 20 Nov 2014 11:20:41 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-2-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416410895-20461-2-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 2/5] xen: arm: Drop
 EARLY_PRINTK_BAUD from entries which don't set ..._INIT_UART
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/19/2014 03:28 PM, Ian Campbell wrote:
> EARLY_PRINTK_BAUD doesn't do anything unless EARLY_PRINTK_INIT_UART is set.
> 
> Furthermore only the pl011 driver implements the init routine at all, so the
> entries which use 8250 and specified a BAUD were doubly wrong.

NIT: and exynos4210

Maybe "use 8250" should be replaced by "other UARTs drivers"?

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,


> ---
> v2: New patch.
> ---
>  xen/arch/arm/Rules.mk |    7 -------
>  1 file changed, 7 deletions(-)
> 
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index 30c7823..4ee51a9 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -45,7 +45,6 @@ ifeq ($(debug),y)
>  # Early printk for versatile express
>  ifeq ($(CONFIG_EARLY_PRINTK), vexpress)
>  EARLY_PRINTK_INC := pl011
> -EARLY_PRINTK_BAUD := 38400
>  EARLY_UART_BASE_ADDRESS := 0x1c090000
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), fastmodel)
> @@ -56,12 +55,10 @@ EARLY_UART_BASE_ADDRESS := 0x1c090000
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), exynos5250)
>  EARLY_PRINTK_INC := exynos4210
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0x12c20000
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), midway)
>  EARLY_PRINTK_INC := pl011
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0xfff36000
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), omap5432)
> @@ -91,7 +88,6 @@ EARLY_UART_REG_SHIFT := 2
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), xgene-storm)
>  EARLY_PRINTK_INC := 8250
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0x1c020000
>  EARLY_UART_REG_SHIFT := 2
>  endif
> @@ -102,18 +98,15 @@ EARLY_UART_REG_SHIFT := 2
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), juno)
>  EARLY_PRINTK_INC := pl011
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0x7ff80000
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), hip04-d01)
>  EARLY_PRINTK_INC := 8250
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0xE4007000
>  EARLY_UART_REG_SHIFT := 2
>  endif
>  ifeq ($(CONFIG_EARLY_PRINTK), seattle)
>  EARLY_PRINTK_INC := pl011
> -EARLY_PRINTK_BAUD := 115200
>  EARLY_UART_BASE_ADDRESS := 0xe1010000
>  endif
>  
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:21:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:21:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPni-0002oO-HP; Thu, 20 Nov 2014 11:21:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPnh-0002o9-QK
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:21:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D2/B5-09936-5BECD645; Thu, 20 Nov 2014 11:21:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416482484!14156654!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21190 invoked from network); 20 Nov 2014 11:21:24 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 11:21:24 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 12:21:23 +0100
Message-Id: <546DDCC302000078000494C9@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 12:21:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
	<1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4/4] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 17:02, <david.vrabel@citrix.com> wrote:
> On a Xen PV guest the DMA addresses and physical addresses are not 1:1
> (such as Xen PV guests) and the generic dma_get_required_mask() does
> not return the correct mask (since it uses max_pfn).
> 
> Some device drivers (such as mptsas, mpt2sas) use
> dma_get_required_mask() to set the device's DMA mask to allow them to
> use only 32-bit DMA addresses in hardware structures.  This results in
> unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
> impacting performance significantly.
> 
> Provide a get_required_mask op that uses the maximum MFN to calculate
> the DMA mask.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:21:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:21:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPni-0002oO-HP; Thu, 20 Nov 2014 11:21:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPnh-0002o9-QK
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:21:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D2/B5-09936-5BECD645; Thu, 20 Nov 2014 11:21:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416482484!14156654!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21190 invoked from network); 20 Nov 2014 11:21:24 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 11:21:24 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 12:21:23 +0100
Message-Id: <546DDCC302000078000494C9@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 12:21:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
	<1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4/4] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 17:02, <david.vrabel@citrix.com> wrote:
> On a Xen PV guest the DMA addresses and physical addresses are not 1:1
> (such as Xen PV guests) and the generic dma_get_required_mask() does
> not return the correct mask (since it uses max_pfn).
> 
> Some device drivers (such as mptsas, mpt2sas) use
> dma_get_required_mask() to set the device's DMA mask to allow them to
> use only 32-bit DMA addresses in hardware structures.  This results in
> unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
> impacting performance significantly.
> 
> Provide a get_required_mask op that uses the maximum MFN to calculate
> the DMA mask.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:21:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:21:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPnj-0002p3-Uk; Thu, 20 Nov 2014 11:21:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XrPni-0002oD-Ba
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 11:21:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	03/39-09842-5BECD645; Thu, 20 Nov 2014 11:21:25 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416482481!14060274!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32408 invoked from network); 20 Nov 2014 11:21:21 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:21:21 -0000
Received: by mail-wg0-f54.google.com with SMTP id y10so3428473wgg.27
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Nov 2014 03:21:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=h/k0la4djW7oU+p5CaEWdHbJhW7RuUJvv5Ot5nBY3ho=;
	b=EKQzFt9Rpvk3jLbaTtSZycSkcxgdVeWzsWtu6YCOjFBTQ/Dx4ZM3F1Sk/08FUk7DYD
	H1og+GKHwdbyIdCk+EiR6SaFIXM2YY2BtdlQbd2vTyIqi3dDK4P2bdtcQ6AtGGYcZouN
	xZhj0ej5Uk90un+mIdkfDxWN+Av40ALYxmuC8B4JhbXx+P9dIW3r7ZdtK4gc9u/QtEy0
	r7jBLdnPWrRlxCeQ4AxX/nDJl/O12Jgcy+aHdGbwFEsVv1qvf0RUyCYjvbaijVQjy5ET
	tyEYoBDOhXelmgXNXRNxn5zC85HvpwCQfNSNTVweJy/2OuPYVmhsQBI7JyTzgeuvGsQQ
	guXw==
X-Gm-Message-State: ALoCoQkpjlW7j2kcYCTlL6yW4eZ1JE0PH4P8Zw+sOq5OusNlG2Mo82pBpjmPXcakryqyehPhpLax
X-Received: by 10.194.239.164 with SMTP id vt4mr23146318wjc.131.1416482479759; 
	Thu, 20 Nov 2014 03:21:19 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id fv5sm2899137wjc.37.2014.11.20.03.21.16
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:21:18 -0800 (PST)
Message-ID: <546DCEB4.5000205@m2r.biz>
Date: Thu, 20 Nov 2014 12:21:24 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <53BBA83C.3010307@m2r.biz>
	<1404809604.30343.5.camel@cihla.spice.brq.redhat.com>
	<53BBC2AA.4030503@m2r.biz> <53BBC952.1040902@m2r.biz>
	<54130761.6080501@m2r.biz> <541C2D39.1060607@m2r.biz>
	<54648477.5040505@m2r.biz> <5464A27D.4020107@m2r.biz>
In-Reply-To: <5464A27D.4020107@m2r.biz>
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [Spice-devel] screen freezed for 2-3 minutes on
 spice connect on xen windows 7 domU's with qxl after save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4622071111556217136=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4622071111556217136==
Content-Type: multipart/alternative;
 boundary="------------060009010202020400050503"

This is a multi-part message in MIME format.
--------------060009010202020400050503
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Length: 43803
Content-Transfer-Encoding: quoted-printable

Il 13/11/2014 13:22, Fabio Fantoni ha scritto:
> Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
>> Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
>>> Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
>>>> Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
>>>>> Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
>>>>>> Il 08/07/2014 10:53, David Ja=9Aa ha scritto:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
>>>>>>>> On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
>>>>>>>> client with
>>>>>>>> spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as 
>>>>>>>> kvm
>>>>>>>> except for one problem after xl save/restore, when after 
>>>>>>>> restore on
>>>>>>>> spice client connect  the domU's screen freezed for 2-3 minutes 
>>>>>>>> (and
>>>>>>>> seems also windows), after this time seems that all return to 
>>>>>>>> works
>>>>>>>> correctly.
>>>>>>>> This problem happen also if spice client connect long time 
>>>>>>>> after restore.
>>>>>>>> With stdvga not have this problem but stdvga has many missed 
>>>>>>>> resolutions
>>>>>>>> and bad refresh performance.
>>>>>>>>
>>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>> Client and server logs would certainly help. Please run:
>>>>>>>    * virt-viewer with --spice-debug option
>>>>>>>    * spice-server with SPICE_DEBUG_LEVEL environment variable set
>>>>>>>      to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
>>>>>>> http://libvirt.org/drvqemu.html#qemucommand )
>>>>>>> and note the location in the logs where the freeze takes place.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> David
>>>>>>
>>>>>> Thanks for your reply, in attachments:
>>>>>> - domU's xl cfg: W7.cfg
>>>>>> - xl -vvv create/save/restore: xen logs.txt
>>>>>> - remote-viewer with --spice-debug after domU's start until xl 
>>>>>> save: spicelog-1.txt (zipped)
>>>>>> - remote-viewer with --spice-debug after domU's xl restore: 
>>>>>> spicelog-2.txt
>>>>>
>>>>> Sorry for my forgetfulness, here also qemu's log:
>>>>> - after domU's start until xl save: qemu-dm-W7.log.1
>>>>> - after domU's xl restore: qemu-dm-W7.log
>>>>>
>>>>>>
>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>
>>>>>>
>>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Spice-devel mailing list
>>>>>>> Spice-devel@lists.freedesktop.org
>>>>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>>
>>>>
>>>> The problem persist, this time I saw these in xl dmesg after restore:
>>>>
>>>> (XEN) HVM2 restore: CPU 0
>>>> (XEN) HVM2 restore: CPU 1
>>>> (XEN) HVM2 restore: PIC 0
>>>> (XEN) HVM2 restore: PIC 1
>>>> (XEN) HVM2 restore: IOAPIC 0
>>>> (XEN) HVM2 restore: LAPIC 0
>>>> (XEN) HVM2 restore: LAPIC 1
>>>> (XEN) HVM2 restore: LAPIC_REGS 0
>>>> (XEN) HVM2 restore: LAPIC_REGS 1
>>>> (XEN) HVM2 restore: PCI_IRQ 0
>>>> (XEN) HVM2 restore: ISA_IRQ 0
>>>> (XEN) HVM2 restore: PCI_LINK 0
>>>> (XEN) HVM2 restore: PIT 0
>>>> (XEN) HVM2 restore: RTC 0
>>>> (XEN) HVM2 restore: HPET 0
>>>> (XEN) HVM2 restore: PMTIMER 0
>>>> (XEN) HVM2 restore: MTRR 0
>>>> (XEN) HVM2 restore: MTRR 1
>>>> (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 0
>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 1
>>>> (XEN) HVM2 restore: VMCE_VCPU 0
>>>> (XEN) HVM2 restore: VMCE_VCPU 1
>>>> (XEN) HVM2 restore: TSC_ADJUST 0
>>>> (XEN) HVM2 restore: TSC_ADJUST 1
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
>>>> (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from 
>>>> (4) to (32) frames.
>>>> (XEN) irq.c:380: Dom2 callback via changed to GSI 24
>>>>
>>>> Tested on latest staging (commit 
>>>> 7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:
>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>>
>>>> If you need more informations or tests tell me and I'll post them.
>>>> Thanks for any reply and sorry for my bad english.
>>>
>>> I did another tests updating to latest git staging (commit 
>>> 3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of 
>>> "only" 2-3 minutes but now when it appears to restart (after 2-3 
>>> minutes) windows domUs undefinitely hangs instead.
>>> No further details in xen and domU's logs.
>>>
>>> If you need more tests/details tell me and I'll do them.
>>>
>>> Thanks for any reply.
>>
>> I did a new test with xen build based on tag 4.5.0-rc2 and on xl 
>> dmesg show these errors:
>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>> Before and after save/restore, with stdvga instead not show them.
>
> Sorry, I found that was introduced by new winpv drivers update instead 
> and I solved applying this patch:
> x86/hvm: Add per-vcpu evtchn upcalls v3 
> http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html
> About save/restore problem with qxl I still not found a solution or at 
> least the exact cause :(

I tried a strace on qemu process when windows (in domU) is in temp. 
freeze and still does many operations (seems similar), I post below a 
small part if can be useful.
I noted for example some of these lines:
read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
temporarily unavailable)
Is it normal=3F

...
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 4197512}, NULL, 8) =3D 2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, 
revents=3DPOLLIN}], left {0, 4193071})
read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
read(30, "W\0\0\0", 4)                  =3D 4
write(30, "W\0\0\0", 4)                 =3D 4
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0
gettimeofday({1416480295, 28658}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0
gettimeofday({1416480295, 28811}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})
*read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
temporarily unavailable)*
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D 0x7f4a3b2cc000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D 0x7f4a3b2cb000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D 0x7f4a3b2ca000
clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D 0x7f4a3b2c9000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D 0x7f4a3b2c8000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D 0x7f4a3b2c7000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D 0x7f4a3b2c6000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D 0x7f4a3b2c5000
clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D 0x7f4a3b2c4000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D 0x7f4a3b2c3000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D 0x7f4a3b2c2000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D 0x7f4a3b2c1000
clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
read(6, "\1\0\0\0\0\0\0\0", 512)        =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0
gettimeofday({1416480295, 35292}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0
gettimeofday({1416480295, 35746}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0
gettimeofday({1416480295, 35898}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 13233688}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
revents=3DPOLLIN}], left {0, 13227138})
read(20, 
"\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"..., 
69632) =3D 101
clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0
gettimeofday({1416480295, 36400}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0
gettimeofday({1416480295, 36550}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 12581076}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
revents=3DPOLLIN}], left {0, 12576281})
read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
read(20, 
"\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"..., 
69632) =3D 101
clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0
gettimeofday({1416480295, 37123}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0
gettimeofday({1416480295, 37273}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 11857546}, NULL, 8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 
9477611})
*read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
temporarily unavailable)*
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
read(6, "\5\0\0\0\0\0\0\0", 512)        =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0
gettimeofday({1416480295, 40643}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0
gettimeofday({1416480295, 40946}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0
gettimeofday({1416480295, 41097}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d4000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d3000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d2000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d1000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d0000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2cf000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2ce000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2cd000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2cc000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2cb000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2ca000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c9000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c8000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c7000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c6000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c5000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b435000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b434000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b433000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b432000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2db000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2da000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d9000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d8000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d7000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d6000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d5000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0
gettimeofday({1416480295, 48329}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0
gettimeofday({1416480295, 48632}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0
gettimeofday({1416480295, 48783}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, 
revents=3DPOLLIN}], left {0, 0})
read(8, "\4\0\0\0\0\0\0\0", 16)         =3D 8
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c4000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c3000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c2000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c1000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0
gettimeofday({1416480295, 52051}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0
gettimeofday({1416480295, 52426}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0
gettimeofday({1416480295, 52576}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0
gettimeofday({1416480295, 55341}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0
gettimeofday({1416480295, 55725}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0
gettimeofday({1416480295, 55876}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, 
revents=3DPOLLIN}], left {0, 0})
read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b435000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b434000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b433000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b432000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2db000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2da000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d9000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d8000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0
gettimeofday({1416480295, 58810}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0
gettimeofday({1416480295, 59114}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0
gettimeofday({1416480295, 59265}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
revents=3DPOLLIN}], left {0, 0})
...

Strace of domU's qemu process during freeze can be useful=3F I must do a 
more specific tests=3F
If you need more informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.


>
>>
>> Below I posted full xl dmesg of domU, if you need more 
>> informations/tests tell me and I'll post them.
>>
>>
>>> (d4) HVM Loader
>>> (d4) Detected Xen v4.5.0-rc
>>> (d4) Xenbus rings @0xfeffc000, event channel 1
>>> (d4) System requested SeaBIOS
>>> (d4) CPU speed is 2660 MHz
>>> (d4) Relocating guest memory for lowmem MMIO space disabled
>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -> 5
>>> (d4) PCI-ISA link 0 routed to IRQ5
>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -> 10
>>> (d4) PCI-ISA link 1 routed to IRQ10
>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -> 11
>>> (d4) PCI-ISA link 2 routed to IRQ11
>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -> 5
>>> (d4) PCI-ISA link 3 routed to IRQ5
>>> (d4) pci dev 01:3 INTA->IRQ10
>>> (d4) pci dev 02:0 INTA->IRQ11
>>> (d4) pci dev 03:0 INTA->IRQ5
>>> (d4) pci dev 04:0 INTA->IRQ5
>>> (d4) pci dev 05:0 INTA->IRQ10
>>> (d4) pci dev 06:0 INTA->IRQ11
>>> (d4) pci dev 1d:0 INTA->IRQ10
>>> (d4) pci dev 1d:1 INTB->IRQ11
>>> (d4) pci dev 1d:2 INTC->IRQ5
>>> (d4) pci dev 1d:7 INTD->IRQ5
>>> (d4) No RAM in high memory; setting high_mem resource base to 100000000
>>> (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>> (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>> (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>> (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>> (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>> (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>> (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>> (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>> (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>> (d4) pci dev 02:0 bar 10 size 000000100: 00000c001
>>> (d4) pci dev 06:0 bar 10 size 000000100: 00000c101
>>> (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>> (d4) pci dev 04:0 bar 10 size 000000020: 00000c201
>>> (d4) pci dev 05:0 bar 1c size 000000020: 00000c221
>>> (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>> (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>> (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>> (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>> (d4) Multiprocessor initialisation:
>>> (d4)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>>> done.
>>> (d4)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>>> done.
>>> (d4) Testing HVM environment:
>>> (d4)  - REP INSB across page boundaries ... passed
>>> (d4)  - GS base MSRs and SWAPGS ... passed
>>> (d4) Passed 2 of 2 tests
>>> (d4) Writing SMBIOS tables ...
>>> (d4) Loading SeaBIOS ...
>>> (d4) Creating MP tables ...
>>> (d4) Loading ACPI ...
>>> (d4) S3 disabled
>>> (d4) S4 disabled
>>> (d4) vm86 TSS at fc00a100
>>> (d4) BIOS map:
>>> (d4)  10000-100d3: Scratch space
>>> (d4)  c0000-fffff: Main BIOS
>>> (d4) E820 table:
>>> (d4)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>> (d4)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>> (d4)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>> (d4)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>> (d4)  HOLE: 00000000:78000000 - 00000000:fc000000
>>> (d4)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>> (d4) Invoking SeaBIOS ...
>>> (d4) SeaBIOS (version 
>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>> (d4)
>>> (d4) Found Xen hypervisor signature at 40000100
>>> (d4) Running on QEMU (i440fx)
>>> (d4) xen: copy e820...
>>> (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>> (d4) CPU Mhz=3D2661
>>> (d4) Found 13 PCI devices (max PCI bus is 00)
>>> (d4) Allocated Xen hypercall page at 77fff000
>>> (d4) Detected Xen v4.5.0-rc
>>> (d4) xen: copy BIOS tables...
>>> (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>> (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>> (d4) Copying PIR from 0x00010030 to 0x000f0dc0
>>> (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>> (d4) Using pmtimer, ioport 0xb008
>>> (d4) Scan for VGA option rom
>>> (d4) Running option rom at c000:0003
>>> (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes
>>> (d4) pmm call arg1=3D0
>>> (d4) Turning on vga text mode console
>>> (d4) SeaBIOS (version 
>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>> (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838
>>> (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)
>>> (d4) Found 0 lpt ports
>>> (d4) Found 0 serial ports
>>> (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>> (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>> (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)
>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>> (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
>>> (d4) UHCI init on dev 00:1d.0 (io=3Dc240)
>>> (d4) UHCI init on dev 00:1d.1 (io=3Dc260)
>>> (d4) UHCI init on dev 00:1d.2 (io=3Dc280)
>>> (d4) PS2 keyboard initialized
>>> (d4) All threads complete.
>>> (d4) Scan for option roms
>>> (d4) Running option rom at c980:0003
>>> (d4) pmm call arg1=3D1
>>> (d4) pmm call arg1=3D0
>>> (d4) pmm call arg1=3D1
>>> (d4) pmm call arg1=3D0
>>> (d4) Searching bootorder for: /pci@i0cf8/*@6
>>> (d4)
>>> (d4) Press F12 for boot menu.
>>> (d4)
>>> (d4) Searching bootorder for: HALT
>>> (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba 
>>> LCHS=3D1024/255/63 s=3D102400000
>>> (d4)
>>> (d4) Space available for UMB: ca800-ee800, f0000-f0ce0
>>> (d4) Returned 258048 bytes of ZoneHigh
>>> (d4) e820 map has 6 items:
>>> (d4)   0: 0000000000000000 - 000000000009fc00 =3D 1 RAM
>>> (d4)   1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED
>>> (d4)   2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED
>>> (d4)   3: 0000000000100000 - 0000000077fff000 =3D 1 RAM
>>> (d4)   4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED
>>> (d4)   5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED
>>> (d4) enter handle_19:
>>> (d4)   NULL
>>> (d4) Booting from DVD/CD...
>>> (d4) Device reports MEDIUM NOT PRESENT
>>> (d4) scsi_is_ready returned -1
>>> (d4) Boot failed: Could not read from CDROM (code 0003)
>>> (d4) enter handle_18:
>>> (d4)   NULL
>>> (d4) Booting from Hard Disk...
>>> (d4) Booting from 0000:7c00
>>> (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 
>>> sp: 1 build: 1db1
>>> (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
>>> (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
>>> (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -> 0
>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -> 0
>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -> 0
>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -> 0
>>> *(XEN) hvm.c:6119:d4v1 Bad HVM op 23.**
>>> **(XEN) hvm.c:6119:d4v1 Bad HVM op 23.*
>>> (XEN) irq.c:380: Dom4 callback via changed to GSI 24
>>> (XEN) HVM4 save: CPU
>>> (XEN) HVM4 save: PIC
>>> (XEN) HVM4 save: IOAPIC
>>> (XEN) HVM4 save: LAPIC
>>> (XEN) HVM4 save: LAPIC_REGS
>>> (XEN) HVM4 save: PCI_IRQ
>>> (XEN) HVM4 save: ISA_IRQ
>>> (XEN) HVM4 save: PCI_LINK
>>> (XEN) HVM4 save: PIT
>>> (XEN) HVM4 save: RTC
>>> (XEN) HVM4 save: HPET
>>> (XEN) HVM4 save: PMTIMER
>>> (XEN) HVM4 save: MTRR
>>> (XEN) HVM4 save: VIRIDIAN_DOMAIN
>>> (XEN) HVM4 save: CPU_XSAVE
>>> (XEN) HVM4 save: VIRIDIAN_VCPU
>>> (XEN) HVM4 save: VMCE_VCPU
>>> (XEN) HVM4 save: TSC_ADJUST
>>> (XEN) HVM5 restore: CPU 0
>>> (XEN) HVM5 restore: CPU 1
>>> (XEN) HVM5 restore: PIC 0
>>> (XEN) HVM5 restore: PIC 1
>>> (XEN) HVM5 restore: IOAPIC 0
>>> (XEN) HVM5 restore: LAPIC 0
>>> (XEN) HVM5 restore: LAPIC 1
>>> (XEN) HVM5 restore: LAPIC_REGS 0
>>> (XEN) HVM5 restore: LAPIC_REGS 1
>>> (XEN) HVM5 restore: PCI_IRQ 0
>>> (XEN) HVM5 restore: ISA_IRQ 0
>>> (XEN) HVM5 restore: PCI_LINK 0
>>> (XEN) HVM5 restore: PIT 0
>>> (XEN) HVM5 restore: RTC 0
>>> (XEN) HVM5 restore: HPET 0
>>> (XEN) HVM5 restore: PMTIMER 0
>>> (XEN) HVM5 restore: MTRR 0
>>> (XEN) HVM5 restore: MTRR 1
>>> (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0
>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 0
>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 1
>>> (XEN) HVM5 restore: VMCE_VCPU 0
>>> (XEN) HVM5 restore: VMCE_VCPU 1
>>> (XEN) HVM5 restore: TSC_ADJUST 0
>>> (XEN) HVM5 restore: TSC_ADJUST 1
>>> (XEN) irq.c:380: Dom5 callback via changed to None
>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>>> (XEN) irq.c:380: Dom5 callback via changed to GSI 24
>>
>>
>


--------------060009010202020400050503
Content-Type: text/html; charset=windows-1252
Content-Length: 55940
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Il 13/11/2014 13:22, Fabio Fantoni ha
      scritto:<br>
    </div>
    <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite">
      <meta content=3D"text/html; charset=3Dwindows-1252"
        http-equiv=3D"Content-Type">
      <div class=3D"moz-cite-prefix">Il 13/11/2014 11:14, Fabio Fantoni ha
        scritto:<br>
      </div>
      <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite">
        <meta content=3D"text/html; charset=3Dwindows-1252"
          http-equiv=3D"Content-Type">
        <div class=3D"moz-cite-prefix">Il 19/09/2014 15:18, Fabio Fantoni
          ha scritto:<br>
        </div>
        <blockquote cite=3D"mid:541C2D39.1060607@m2r.biz" type=3D"cite">Il
          12/09/2014 16:46, Fabio Fantoni ha scritto: <br>
          <blockquote type=3D"cite">Il 08/07/2014 12:34, Fabio Fantoni ha
            scritto: <br>
            <blockquote type=3D"cite">Il 08/07/2014 12:06, Fabio Fantoni
              ha scritto: <br>
              <blockquote type=3D"cite">Il 08/07/2014 10:53, David Ja=9Aa ha
                scritto: <br>
                <blockquote type=3D"cite">Hi, <br>
                  <br>
                  On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
                  <br>
                  <blockquote type=3D"cite">On xen 4.5 (tried with qemu
                    2.0.0/2.1-rc0, spice 0.12.5 and client with <br>
                    spice-gtk 0.23/0.25) windows 7 domUs with qxl vga
                    works good as kvm <br>
                    except for one problem after xl save/restore, when
                    after restore on <br>
                    spice client connect=A0 the domU's screen freezed for
                    2-3 minutes (and <br>
                    seems also windows), after this time seems that all
                    return to works <br>
                    correctly. <br>
                    This problem happen also if spice client connect
                    long time after restore. <br>
                    With stdvga not have this problem but stdvga has
                    many missed resolutions <br>
                    and bad refresh performance. <br>
                    <br>
                    If you need more tests/informations tell me and I'll
                    post them. <br>
                  </blockquote>
                  Client and server logs would certainly help. Please
                  run: <br>
                  =A0=A0 * virt-viewer with --spice-debug option <br>
                  =A0=A0 * spice-server with SPICE_DEBUG_LEVEL environment
                  variable set <br>
                  =A0=A0=A0=A0 to 4 or 5 (if you use qemu+libvirt, use qemu:env
                  element: <br>
                  =A0=A0=A0=A0 <a moz-do-not-send=3D"true"
                    class=3D"moz-txt-link-freetext"
                    href=3D"http://libvirt.org/drvqemu.html#qemucommand">http://libvirt.org/drvqemu.html#qemucommand</a>
                  ) <br>
                  and note the location in the logs where the freeze
                  takes place. <br>
                  <br>
                  Regards, <br>
                  <br>
                  David <br>
                </blockquote>
                <br>
                Thanks for your reply, in attachments: <br>
                - domU's xl cfg: W7.cfg <br>
                - xl -vvv create/save/restore: xen logs.txt <br>
                - remote-viewer with --spice-debug after domU's start
                until xl save: spicelog-1.txt (zipped) <br>
                - remote-viewer with --spice-debug after domU's xl
                restore: spicelog-2.txt <br>
              </blockquote>
              <br>
              Sorry for my forgetfulness, here also qemu's log: <br>
              - after domU's start until xl save: qemu-dm-W7.log.1 <br>
              - after domU's xl restore: qemu-dm-W7.log <br>
              <br>
              <blockquote type=3D"cite"> <br>
                If you need more tests/informations tell me and I'll
                post them. <br>
                <br>
                <br>
                <blockquote type=3D"cite">Thanks for any reply and sorry
                  for my bad english. <br>
                  <br>
                  _______________________________________________ <br>
                  Spice-devel mailing list <br>
                  <a moz-do-not-send=3D"true"
                    class=3D"moz-txt-link-abbreviated"
                    href=3D"mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a>
                  <br>
                  <a moz-do-not-send=3D"true"
                    class=3D"moz-txt-link-freetext"
                    href=3D"http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a>
                  <br>
                </blockquote>
              </blockquote>
              <br>
            </blockquote>
            <br>
            The problem persist, this time I saw these in xl dmesg after
            restore: <br>
            <br>
            (XEN) HVM2 restore: CPU 0 <br>
            (XEN) HVM2 restore: CPU 1 <br>
            (XEN) HVM2 restore: PIC 0 <br>
            (XEN) HVM2 restore: PIC 1 <br>
            (XEN) HVM2 restore: IOAPIC 0 <br>
            (XEN) HVM2 restore: LAPIC 0 <br>
            (XEN) HVM2 restore: LAPIC 1 <br>
            (XEN) HVM2 restore: LAPIC_REGS 0 <br>
            (XEN) HVM2 restore: LAPIC_REGS 1 <br>
            (XEN) HVM2 restore: PCI_IRQ 0 <br>
            (XEN) HVM2 restore: ISA_IRQ 0 <br>
            (XEN) HVM2 restore: PCI_LINK 0 <br>
            (XEN) HVM2 restore: PIT 0 <br>
            (XEN) HVM2 restore: RTC 0 <br>
            (XEN) HVM2 restore: HPET 0 <br>
            (XEN) HVM2 restore: PMTIMER 0 <br>
            (XEN) HVM2 restore: MTRR 0 <br>
            (XEN) HVM2 restore: MTRR 1 <br>
            (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0 <br>
            (XEN) HVM2 restore: VIRIDIAN_VCPU 0 <br>
            (XEN) HVM2 restore: VIRIDIAN_VCPU 1 <br>
            (XEN) HVM2 restore: VMCE_VCPU 0 <br>
            (XEN) HVM2 restore: VMCE_VCPU 1 <br>
            (XEN) HVM2 restore: TSC_ADJUST 0 <br>
            (XEN) HVM2 restore: TSC_ADJUST 1 <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid <br>
            (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table
            from (4) to (32) frames. <br>
            (XEN) irq.c:380: Dom2 callback via changed to GSI 24 <br>
            <br>
            Tested on latest staging (commit
            7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice
            patches: <br>
            <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
              href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a>
            <br>
            <br>
            If you need more informations or tests tell me and I'll post
            them. <br>
            Thanks for any reply and sorry for my bad english. <br>
          </blockquote>
          <br>
          I did another tests updating to latest git staging (commit
          3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore
          problem of "only" 2-3 minutes but now when it appears to
          restart (after 2-3 minutes) windows domUs undefinitely hangs
          instead. <br>
          No further details in xen and domU's logs. <br>
          <br>
          If you need more tests/details tell me and I'll do them. <br>
          <br>
          Thanks for any reply. <br>
        </blockquote>
        <br>
        I did a new test with xen build based on tag 4.5.0-rc2 and on xl
        dmesg show these errors:<br>
        <blockquote type=3D"cite"><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b></blockquote>
        Before and after save/restore, with stdvga instead not show
        them.<br>
      </blockquote>
      <br>
      Sorry, I found that was introduced by new winpv drivers update
      instead and I solved applying this patch:<br>
      x86/hvm: Add per-vcpu evtchn upcalls v3 <a moz-do-not-send=3D"true"
        class=3D"moz-txt-link-freetext"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html">http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html</a><br>
      About save/restore problem with qxl I still not found a solution
      or at least the exact cause :(<br>
    </blockquote>
    <br>
    I tried a strace on qemu process when windows (in domU) is in temp.
    freeze and still does many operations (seems similar), I post below
    a small part if can be useful.<br>
    I noted for example some of these lines:<br>
    read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
    temporarily unavailable)<br>
    Is it normal=3F<br>
    <br>
    ...<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 4197512}, NULL, 8) =3D
    2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0,
    4193071})<br>
    read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    read(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
    write(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0<br>
    gettimeofday({1416480295, 28658}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0<br>
    gettimeofday({1416480295, 28811}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
    ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
    <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
      temporarily unavailable)</b><br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
    0x7f4a3b435000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
    0x7f4a3b434000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
    0x7f4a3b433000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
    0x7f4a3b432000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
    0x7f4a3b2db000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
    0x7f4a3b2da000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
    0x7f4a3b2d9000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
    0x7f4a3b2d8000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
    0x7f4a3b2d7000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
    0x7f4a3b2d6000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
    0x7f4a3b2d5000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
    0x7f4a3b2d4000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
    0x7f4a3b2d3000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
    0x7f4a3b2d2000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
    0x7f4a3b2d1000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
    0x7f4a3b2d0000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
    0x7f4a3b2cf000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
    0x7f4a3b2ce000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
    0x7f4a3b2cd000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D
    0x7f4a3b2cc000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D
    0x7f4a3b2cb000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D
    0x7f4a3b2ca000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D
    0x7f4a3b2c9000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D
    0x7f4a3b2c8000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D
    0x7f4a3b2c7000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D
    0x7f4a3b2c6000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D
    0x7f4a3b2c5000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D
    0x7f4a3b2c4000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D
    0x7f4a3b2c3000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D
    0x7f4a3b2c2000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D
    0x7f4a3b2c1000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    read(6, "\1\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0<br>
    gettimeofday({1416480295, 35292}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0<br>
    gettimeofday({1416480295, 35746}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0<br>
    gettimeofday({1416480295, 35898}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 13233688}, NULL, 8)
    =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0,
    13227138})<br>
    read(20,
    "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"...,
    69632) =3D 101<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0<br>
    gettimeofday({1416480295, 36400}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0<br>
    gettimeofday({1416480295, 36550}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 12581076}, NULL, 8)
    =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0,
    12576281})<br>
    read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    read(20,
    "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"...,
    69632) =3D 101<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0<br>
    gettimeofday({1416480295, 37123}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0<br>
    gettimeofday({1416480295, 37273}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 11857546}, NULL, 8)
    =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 9477611})<br>
    <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
      temporarily unavailable)</b><br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    read(6, "\5\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0<br>
    gettimeofday({1416480295, 40643}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0<br>
    gettimeofday({1416480295, 40946}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0<br>
    gettimeofday({1416480295, 41097}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
    ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d0000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2cf000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2ce000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2cd000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2cc000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2cb000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2ca000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0<br>
    gettimeofday({1416480295, 48329}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0<br>
    gettimeofday({1416480295, 48632}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0<br>
    gettimeofday({1416480295, 48783}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
    ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
    read(8, "\4\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
    0x7f4a3b435000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
    0x7f4a3b434000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
    0x7f4a3b433000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
    0x7f4a3b432000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
    0x7f4a3b2db000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
    0x7f4a3b2da000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
    0x7f4a3b2d9000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
    0x7f4a3b2d8000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0<br>
    gettimeofday({1416480295, 52051}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0<br>
    gettimeofday({1416480295, 52426}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0<br>
    gettimeofday({1416480295, 52576}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
    ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
    read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
    0x7f4a3b2d7000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
    0x7f4a3b2d6000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
    0x7f4a3b2d5000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
    0x7f4a3b2d4000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
    0x7f4a3b2d3000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
    0x7f4a3b2d2000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
    0x7f4a3b2d1000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
    0x7f4a3b2d0000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
    0x7f4a3b2cf000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
    0x7f4a3b2ce000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
    0x7f4a3b2cd000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0<br>
    gettimeofday({1416480295, 55341}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0<br>
    gettimeofday({1416480295, 55725}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0<br>
    gettimeofday({1416480295, 55876}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
    ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
    read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
    read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0<br>
    gettimeofday({1416480295, 58810}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0<br>
    gettimeofday({1416480295, 59114}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0<br>
    gettimeofday({1416480295, 59265}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
    ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
    ...<br>
    <br>
    Strace of domU's qemu process during freeze can be useful=3F I must do
    a more specific tests=3F<br>
    If you need more informations/tests tell me and I'll post them.<br>
    <br>
    Thanks for any reply and sorry for my bad english.<br>
    <br>
    <br>
    <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite"> <br>
      <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite"> <br>
        Below I posted full xl dmesg of domU, if you need more
        informations/tests tell me and I'll post them.<br>
        <br>
        <br>
        <blockquote type=3D"cite">(d4) HVM Loader<br>
          (d4) Detected Xen v4.5.0-rc<br>
          (d4) Xenbus rings @0xfeffc000, event channel 1<br>
          (d4) System requested SeaBIOS<br>
          (d4) CPU speed is 2660 MHz<br>
          (d4) Relocating guest memory for lowmem MMIO space disabled<br>
          (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -&gt; 5<br>
          (d4) PCI-ISA link 0 routed to IRQ5<br>
          (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -&gt; 10<br>
          (d4) PCI-ISA link 1 routed to IRQ10<br>
          (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -&gt; 11<br>
          (d4) PCI-ISA link 2 routed to IRQ11<br>
          (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -&gt; 5<br>
          (d4) PCI-ISA link 3 routed to IRQ5<br>
          (d4) pci dev 01:3 INTA-&gt;IRQ10<br>
          (d4) pci dev 02:0 INTA-&gt;IRQ11<br>
          (d4) pci dev 03:0 INTA-&gt;IRQ5<br>
          (d4) pci dev 04:0 INTA-&gt;IRQ5<br>
          (d4) pci dev 05:0 INTA-&gt;IRQ10<br>
          (d4) pci dev 06:0 INTA-&gt;IRQ11<br>
          (d4) pci dev 1d:0 INTA-&gt;IRQ10<br>
          (d4) pci dev 1d:1 INTB-&gt;IRQ11<br>
          (d4) pci dev 1d:2 INTC-&gt;IRQ5<br>
          (d4) pci dev 1d:7 INTD-&gt;IRQ5<br>
          (d4) No RAM in high memory; setting high_mem resource base to
          100000000<br>
          (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000<br>
          (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000<br>
          (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008<br>
          (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000<br>
          (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000<br>
          (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000<br>
          (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000<br>
          (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000<br>
          (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000<br>
          (d4) pci dev 02:0 bar 10 size 000000100: 00000c001<br>
          (d4) pci dev 06:0 bar 10 size 000000100: 00000c101<br>
          (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000<br>
          (d4) pci dev 04:0 bar 10 size 000000020: 00000c201<br>
          (d4) pci dev 05:0 bar 1c size 000000020: 00000c221<br>
          (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241<br>
          (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261<br>
          (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281<br>
          (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1<br>
          (d4) Multiprocessor initialisation:<br>
          (d4)=A0 - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs
          [1/8] ... done.<br>
          (d4)=A0 - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs
          [1/8] ... done.<br>
          (d4) Testing HVM environment:<br>
          (d4)=A0 - REP INSB across page boundaries ... passed<br>
          (d4)=A0 - GS base MSRs and SWAPGS ... passed<br>
          (d4) Passed 2 of 2 tests<br>
          (d4) Writing SMBIOS tables ...<br>
          (d4) Loading SeaBIOS ...<br>
          (d4) Creating MP tables ...<br>
          (d4) Loading ACPI ...<br>
          (d4) S3 disabled<br>
          (d4) S4 disabled<br>
          (d4) vm86 TSS at fc00a100<br>
          (d4) BIOS map:<br>
          (d4)=A0 10000-100d3: Scratch space<br>
          (d4)=A0 c0000-fffff: Main BIOS<br>
          (d4) E820 table:<br>
          (d4)=A0 [00]: 00000000:00000000 - 00000000:000a0000: RAM<br>
          (d4)=A0 HOLE: 00000000:000a0000 - 00000000:000c0000<br>
          (d4)=A0 [01]: 00000000:000c0000 - 00000000:00100000: RESERVED<br>
          (d4)=A0 [02]: 00000000:00100000 - 00000000:78000000: RAM<br>
          (d4)=A0 HOLE: 00000000:78000000 - 00000000:fc000000<br>
          (d4)=A0 [03]: 00000000:fc000000 - 00000001:00000000: RESERVED<br>
          (d4) Invoking SeaBIOS ...<br>
          (d4) SeaBIOS (version
          debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
          (d4) <br>
          (d4) Found Xen hypervisor signature at 40000100<br>
          (d4) Running on QEMU (i440fx)<br>
          (d4) xen: copy e820...<br>
          (d4) Relocating init from 0x000df619 to 0x77fae600 (size
          71995)<br>
          (d4) CPU Mhz=3D2661<br>
          (d4) Found 13 PCI devices (max PCI bus is 00)<br>
          (d4) Allocated Xen hypercall page at 77fff000<br>
          (d4) Detected Xen v4.5.0-rc<br>
          (d4) xen: copy BIOS tables...<br>
          (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40<br>
          (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40<br>
          (d4) Copying PIR from 0x00010030 to 0x000f0dc0<br>
          (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90<br>
          (d4) Using pmtimer, ioport 0xb008<br>
          (d4) Scan for VGA option rom<br>
          (d4) Running option rom at c000:0003<br>
          (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes<br>
          (d4) pmm call arg1=3D0<br>
          (d4) Turning on vga text mode console<br>
          (d4) SeaBIOS (version
          debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
          (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838<br>
          (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)<br>
          (d4) Found 0 lpt ports<br>
          (d4) Found 0 serial ports<br>
          (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)<br>
          (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)<br>
          (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)<br>
          (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0<br>
          (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]<br>
          (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1<br>
          (d4) UHCI init on dev 00:1d.0 (io=3Dc240)<br>
          (d4) UHCI init on dev 00:1d.1 (io=3Dc260)<br>
          (d4) UHCI init on dev 00:1d.2 (io=3Dc280)<br>
          (d4) PS2 keyboard initialized<br>
          (d4) All threads complete.<br>
          (d4) Scan for option roms<br>
          (d4) Running option rom at c980:0003<br>
          (d4) pmm call arg1=3D1<br>
          (d4) pmm call arg1=3D0<br>
          (d4) pmm call arg1=3D1<br>
          (d4) pmm call arg1=3D0<br>
          (d4) Searching bootorder for: /pci@i0cf8/*@6<br>
          (d4) <br>
          (d4) Press F12 for boot menu.<br>
          (d4) <br>
          (d4) Searching bootorder for: HALT<br>
          (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba
          LCHS=3D1024/255/63 s=3D102400000<br>
          (d4) <br>
          (d4) Space available for UMB: ca800-ee800, f0000-f0ce0<br>
          (d4) Returned 258048 bytes of ZoneHigh<br>
          (d4) e820 map has 6 items:<br>
          (d4)=A0=A0 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM<br>
          (d4)=A0=A0 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED<br>
          (d4)=A0=A0 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED<br>
          (d4)=A0=A0 3: 0000000000100000 - 0000000077fff000 =3D 1 RAM<br>
          (d4)=A0=A0 4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED<br>
          (d4)=A0=A0 5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED<br>
          (d4) enter handle_19:<br>
          (d4)=A0=A0 NULL<br>
          (d4) Booting from DVD/CD...<br>
          (d4) Device reports MEDIUM NOT PRESENT<br>
          (d4) scsi_is_ready returned -1<br>
          (d4) Boot failed: Could not read from CDROM (code 0003)<br>
          (d4) enter handle_18:<br>
          (d4)=A0=A0 NULL<br>
          (d4) Booting from Hard Disk...<br>
          (d4) Booting from 0000:7c00<br>
          (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6
          minor: 1 sp: 1 build: 1db1<br>
          (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff<br>
          (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe<br>
          (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd<br>
          (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -&gt; 0<br>
          (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -&gt; 0<br>
          (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -&gt; 0<br>
          (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -&gt; 0<br>
          <b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><b><br>
          </b><b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><br>
          (XEN) irq.c:380: Dom4 callback via changed to GSI 24<br>
          (XEN) HVM4 save: CPU<br>
          (XEN) HVM4 save: PIC<br>
          (XEN) HVM4 save: IOAPIC<br>
          (XEN) HVM4 save: LAPIC<br>
          (XEN) HVM4 save: LAPIC_REGS<br>
          (XEN) HVM4 save: PCI_IRQ<br>
          (XEN) HVM4 save: ISA_IRQ<br>
          (XEN) HVM4 save: PCI_LINK<br>
          (XEN) HVM4 save: PIT<br>
          (XEN) HVM4 save: RTC<br>
          (XEN) HVM4 save: HPET<br>
          (XEN) HVM4 save: PMTIMER<br>
          (XEN) HVM4 save: MTRR<br>
          (XEN) HVM4 save: VIRIDIAN_DOMAIN<br>
          (XEN) HVM4 save: CPU_XSAVE<br>
          (XEN) HVM4 save: VIRIDIAN_VCPU<br>
          (XEN) HVM4 save: VMCE_VCPU<br>
          (XEN) HVM4 save: TSC_ADJUST<br>
          (XEN) HVM5 restore: CPU 0<br>
          (XEN) HVM5 restore: CPU 1<br>
          (XEN) HVM5 restore: PIC 0<br>
          (XEN) HVM5 restore: PIC 1<br>
          (XEN) HVM5 restore: IOAPIC 0<br>
          (XEN) HVM5 restore: LAPIC 0<br>
          (XEN) HVM5 restore: LAPIC 1<br>
          (XEN) HVM5 restore: LAPIC_REGS 0<br>
          (XEN) HVM5 restore: LAPIC_REGS 1<br>
          (XEN) HVM5 restore: PCI_IRQ 0<br>
          (XEN) HVM5 restore: ISA_IRQ 0<br>
          (XEN) HVM5 restore: PCI_LINK 0<br>
          (XEN) HVM5 restore: PIT 0<br>
          (XEN) HVM5 restore: RTC 0<br>
          (XEN) HVM5 restore: HPET 0<br>
          (XEN) HVM5 restore: PMTIMER 0<br>
          (XEN) HVM5 restore: MTRR 0<br>
          (XEN) HVM5 restore: MTRR 1<br>
          (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0<br>
          (XEN) HVM5 restore: VIRIDIAN_VCPU 0<br>
          (XEN) HVM5 restore: VIRIDIAN_VCPU 1<br>
          (XEN) HVM5 restore: VMCE_VCPU 0<br>
          (XEN) HVM5 restore: VMCE_VCPU 1<br>
          (XEN) HVM5 restore: TSC_ADJUST 0<br>
          (XEN) HVM5 restore: TSC_ADJUST 1<br>
          (XEN) irq.c:380: Dom5 callback via changed to None<br>
          <b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
          </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
          </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
          </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><br>
          (XEN) irq.c:380: Dom5 callback via changed to GSI 24</blockquote>
        <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------060009010202020400050503--


--===============4622071111556217136==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4622071111556217136==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 11:21:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:21:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPnj-0002p3-Uk; Thu, 20 Nov 2014 11:21:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XrPni-0002oD-Ba
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 11:21:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	03/39-09842-5BECD645; Thu, 20 Nov 2014 11:21:25 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416482481!14060274!1
X-Originating-IP: [74.125.82.54]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32408 invoked from network); 20 Nov 2014 11:21:21 -0000
Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com)
	(74.125.82.54)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:21:21 -0000
Received: by mail-wg0-f54.google.com with SMTP id y10so3428473wgg.27
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Nov 2014 03:21:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=h/k0la4djW7oU+p5CaEWdHbJhW7RuUJvv5Ot5nBY3ho=;
	b=EKQzFt9Rpvk3jLbaTtSZycSkcxgdVeWzsWtu6YCOjFBTQ/Dx4ZM3F1Sk/08FUk7DYD
	H1og+GKHwdbyIdCk+EiR6SaFIXM2YY2BtdlQbd2vTyIqi3dDK4P2bdtcQ6AtGGYcZouN
	xZhj0ej5Uk90un+mIdkfDxWN+Av40ALYxmuC8B4JhbXx+P9dIW3r7ZdtK4gc9u/QtEy0
	r7jBLdnPWrRlxCeQ4AxX/nDJl/O12Jgcy+aHdGbwFEsVv1qvf0RUyCYjvbaijVQjy5ET
	tyEYoBDOhXelmgXNXRNxn5zC85HvpwCQfNSNTVweJy/2OuPYVmhsQBI7JyTzgeuvGsQQ
	guXw==
X-Gm-Message-State: ALoCoQkpjlW7j2kcYCTlL6yW4eZ1JE0PH4P8Zw+sOq5OusNlG2Mo82pBpjmPXcakryqyehPhpLax
X-Received: by 10.194.239.164 with SMTP id vt4mr23146318wjc.131.1416482479759; 
	Thu, 20 Nov 2014 03:21:19 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id fv5sm2899137wjc.37.2014.11.20.03.21.16
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:21:18 -0800 (PST)
Message-ID: <546DCEB4.5000205@m2r.biz>
Date: Thu, 20 Nov 2014 12:21:24 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <53BBA83C.3010307@m2r.biz>
	<1404809604.30343.5.camel@cihla.spice.brq.redhat.com>
	<53BBC2AA.4030503@m2r.biz> <53BBC952.1040902@m2r.biz>
	<54130761.6080501@m2r.biz> <541C2D39.1060607@m2r.biz>
	<54648477.5040505@m2r.biz> <5464A27D.4020107@m2r.biz>
In-Reply-To: <5464A27D.4020107@m2r.biz>
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [Spice-devel] screen freezed for 2-3 minutes on
 spice connect on xen windows 7 domU's with qxl after save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4622071111556217136=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4622071111556217136==
Content-Type: multipart/alternative;
 boundary="------------060009010202020400050503"

This is a multi-part message in MIME format.
--------------060009010202020400050503
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Length: 43803
Content-Transfer-Encoding: quoted-printable

Il 13/11/2014 13:22, Fabio Fantoni ha scritto:
> Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
>> Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
>>> Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
>>>> Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
>>>>> Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
>>>>>> Il 08/07/2014 10:53, David Ja=9Aa ha scritto:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
>>>>>>>> On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
>>>>>>>> client with
>>>>>>>> spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as 
>>>>>>>> kvm
>>>>>>>> except for one problem after xl save/restore, when after 
>>>>>>>> restore on
>>>>>>>> spice client connect  the domU's screen freezed for 2-3 minutes 
>>>>>>>> (and
>>>>>>>> seems also windows), after this time seems that all return to 
>>>>>>>> works
>>>>>>>> correctly.
>>>>>>>> This problem happen also if spice client connect long time 
>>>>>>>> after restore.
>>>>>>>> With stdvga not have this problem but stdvga has many missed 
>>>>>>>> resolutions
>>>>>>>> and bad refresh performance.
>>>>>>>>
>>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>> Client and server logs would certainly help. Please run:
>>>>>>>    * virt-viewer with --spice-debug option
>>>>>>>    * spice-server with SPICE_DEBUG_LEVEL environment variable set
>>>>>>>      to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
>>>>>>> http://libvirt.org/drvqemu.html#qemucommand )
>>>>>>> and note the location in the logs where the freeze takes place.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> David
>>>>>>
>>>>>> Thanks for your reply, in attachments:
>>>>>> - domU's xl cfg: W7.cfg
>>>>>> - xl -vvv create/save/restore: xen logs.txt
>>>>>> - remote-viewer with --spice-debug after domU's start until xl 
>>>>>> save: spicelog-1.txt (zipped)
>>>>>> - remote-viewer with --spice-debug after domU's xl restore: 
>>>>>> spicelog-2.txt
>>>>>
>>>>> Sorry for my forgetfulness, here also qemu's log:
>>>>> - after domU's start until xl save: qemu-dm-W7.log.1
>>>>> - after domU's xl restore: qemu-dm-W7.log
>>>>>
>>>>>>
>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>
>>>>>>
>>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Spice-devel mailing list
>>>>>>> Spice-devel@lists.freedesktop.org
>>>>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>>
>>>>
>>>> The problem persist, this time I saw these in xl dmesg after restore:
>>>>
>>>> (XEN) HVM2 restore: CPU 0
>>>> (XEN) HVM2 restore: CPU 1
>>>> (XEN) HVM2 restore: PIC 0
>>>> (XEN) HVM2 restore: PIC 1
>>>> (XEN) HVM2 restore: IOAPIC 0
>>>> (XEN) HVM2 restore: LAPIC 0
>>>> (XEN) HVM2 restore: LAPIC 1
>>>> (XEN) HVM2 restore: LAPIC_REGS 0
>>>> (XEN) HVM2 restore: LAPIC_REGS 1
>>>> (XEN) HVM2 restore: PCI_IRQ 0
>>>> (XEN) HVM2 restore: ISA_IRQ 0
>>>> (XEN) HVM2 restore: PCI_LINK 0
>>>> (XEN) HVM2 restore: PIT 0
>>>> (XEN) HVM2 restore: RTC 0
>>>> (XEN) HVM2 restore: HPET 0
>>>> (XEN) HVM2 restore: PMTIMER 0
>>>> (XEN) HVM2 restore: MTRR 0
>>>> (XEN) HVM2 restore: MTRR 1
>>>> (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 0
>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 1
>>>> (XEN) HVM2 restore: VMCE_VCPU 0
>>>> (XEN) HVM2 restore: VMCE_VCPU 1
>>>> (XEN) HVM2 restore: TSC_ADJUST 0
>>>> (XEN) HVM2 restore: TSC_ADJUST 1
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
>>>> (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from 
>>>> (4) to (32) frames.
>>>> (XEN) irq.c:380: Dom2 callback via changed to GSI 24
>>>>
>>>> Tested on latest staging (commit 
>>>> 7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:
>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>>
>>>> If you need more informations or tests tell me and I'll post them.
>>>> Thanks for any reply and sorry for my bad english.
>>>
>>> I did another tests updating to latest git staging (commit 
>>> 3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of 
>>> "only" 2-3 minutes but now when it appears to restart (after 2-3 
>>> minutes) windows domUs undefinitely hangs instead.
>>> No further details in xen and domU's logs.
>>>
>>> If you need more tests/details tell me and I'll do them.
>>>
>>> Thanks for any reply.
>>
>> I did a new test with xen build based on tag 4.5.0-rc2 and on xl 
>> dmesg show these errors:
>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>> Before and after save/restore, with stdvga instead not show them.
>
> Sorry, I found that was introduced by new winpv drivers update instead 
> and I solved applying this patch:
> x86/hvm: Add per-vcpu evtchn upcalls v3 
> http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html
> About save/restore problem with qxl I still not found a solution or at 
> least the exact cause :(

I tried a strace on qemu process when windows (in domU) is in temp. 
freeze and still does many operations (seems similar), I post below a 
small part if can be useful.
I noted for example some of these lines:
read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
temporarily unavailable)
Is it normal=3F

...
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 4197512}, NULL, 8) =3D 2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, 
revents=3DPOLLIN}], left {0, 4193071})
read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
read(30, "W\0\0\0", 4)                  =3D 4
write(30, "W\0\0\0", 4)                 =3D 4
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0
gettimeofday({1416480295, 28658}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0
gettimeofday({1416480295, 28811}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})
*read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
temporarily unavailable)*
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D 0x7f4a3b2cc000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D 0x7f4a3b2cb000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D 0x7f4a3b2ca000
clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D 0x7f4a3b2c9000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D 0x7f4a3b2c8000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D 0x7f4a3b2c7000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D 0x7f4a3b2c6000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D 0x7f4a3b2c5000
clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D 0x7f4a3b2c4000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D 0x7f4a3b2c3000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D 0x7f4a3b2c2000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D 0x7f4a3b2c1000
clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
read(6, "\1\0\0\0\0\0\0\0", 512)        =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0
gettimeofday({1416480295, 35292}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0
gettimeofday({1416480295, 35746}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0
gettimeofday({1416480295, 35898}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 13233688}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
revents=3DPOLLIN}], left {0, 13227138})
read(20, 
"\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"..., 
69632) =3D 101
clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0
gettimeofday({1416480295, 36400}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0
gettimeofday({1416480295, 36550}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 12581076}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
revents=3DPOLLIN}], left {0, 12576281})
read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
read(20, 
"\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"..., 
69632) =3D 101
clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0
gettimeofday({1416480295, 37123}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0
gettimeofday({1416480295, 37273}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 11857546}, NULL, 8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 
9477611})
*read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
temporarily unavailable)*
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
read(6, "\5\0\0\0\0\0\0\0", 512)        =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0
gettimeofday({1416480295, 40643}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0
gettimeofday({1416480295, 40946}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0
gettimeofday({1416480295, 41097}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d4000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d3000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d2000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d1000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d0000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2cf000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2ce000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2cd000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2cc000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2cb000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2ca000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c9000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c8000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c7000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c6000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c5000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b435000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b434000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b433000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b432000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2db000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2da000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d9000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d8000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d7000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d6000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d5000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0
gettimeofday({1416480295, 48329}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0
gettimeofday({1416480295, 48632}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0
gettimeofday({1416480295, 48783}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, 
revents=3DPOLLIN}], left {0, 0})
read(8, "\4\0\0\0\0\0\0\0", 16)         =3D 8
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c4000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c3000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c2000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2c1000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0
gettimeofday({1416480295, 52051}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0
gettimeofday({1416480295, 52426}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0
gettimeofday({1416480295, 52576}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0
futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0
gettimeofday({1416480295, 55341}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0
gettimeofday({1416480295, 55725}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0
gettimeofday({1416480295, 55876}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, 
revents=3DPOLLIN}], left {0, 0})
read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b435000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b434000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b433000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b432000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2db000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2da000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d9000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
munmap(0x7f4a3b2d8000, 4096)            =3D 0
ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0
gettimeofday({1416480295, 58810}, NULL) =3D 0
write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0
gettimeofday({1416480295, 59114}, NULL) =3D 0
clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0
gettimeofday({1416480295, 59265}, NULL) =3D 0
ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D40, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D37, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D22, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D19, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
{fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
revents=3DPOLLIN}], left {0, 0})
...

Strace of domU's qemu process during freeze can be useful=3F I must do a 
more specific tests=3F
If you need more informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.


>
>>
>> Below I posted full xl dmesg of domU, if you need more 
>> informations/tests tell me and I'll post them.
>>
>>
>>> (d4) HVM Loader
>>> (d4) Detected Xen v4.5.0-rc
>>> (d4) Xenbus rings @0xfeffc000, event channel 1
>>> (d4) System requested SeaBIOS
>>> (d4) CPU speed is 2660 MHz
>>> (d4) Relocating guest memory for lowmem MMIO space disabled
>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -> 5
>>> (d4) PCI-ISA link 0 routed to IRQ5
>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -> 10
>>> (d4) PCI-ISA link 1 routed to IRQ10
>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -> 11
>>> (d4) PCI-ISA link 2 routed to IRQ11
>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -> 5
>>> (d4) PCI-ISA link 3 routed to IRQ5
>>> (d4) pci dev 01:3 INTA->IRQ10
>>> (d4) pci dev 02:0 INTA->IRQ11
>>> (d4) pci dev 03:0 INTA->IRQ5
>>> (d4) pci dev 04:0 INTA->IRQ5
>>> (d4) pci dev 05:0 INTA->IRQ10
>>> (d4) pci dev 06:0 INTA->IRQ11
>>> (d4) pci dev 1d:0 INTA->IRQ10
>>> (d4) pci dev 1d:1 INTB->IRQ11
>>> (d4) pci dev 1d:2 INTC->IRQ5
>>> (d4) pci dev 1d:7 INTD->IRQ5
>>> (d4) No RAM in high memory; setting high_mem resource base to 100000000
>>> (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>> (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>> (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>> (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>> (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>> (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>> (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>> (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>> (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>> (d4) pci dev 02:0 bar 10 size 000000100: 00000c001
>>> (d4) pci dev 06:0 bar 10 size 000000100: 00000c101
>>> (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>> (d4) pci dev 04:0 bar 10 size 000000020: 00000c201
>>> (d4) pci dev 05:0 bar 1c size 000000020: 00000c221
>>> (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>> (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>> (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>> (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>> (d4) Multiprocessor initialisation:
>>> (d4)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>>> done.
>>> (d4)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
>>> done.
>>> (d4) Testing HVM environment:
>>> (d4)  - REP INSB across page boundaries ... passed
>>> (d4)  - GS base MSRs and SWAPGS ... passed
>>> (d4) Passed 2 of 2 tests
>>> (d4) Writing SMBIOS tables ...
>>> (d4) Loading SeaBIOS ...
>>> (d4) Creating MP tables ...
>>> (d4) Loading ACPI ...
>>> (d4) S3 disabled
>>> (d4) S4 disabled
>>> (d4) vm86 TSS at fc00a100
>>> (d4) BIOS map:
>>> (d4)  10000-100d3: Scratch space
>>> (d4)  c0000-fffff: Main BIOS
>>> (d4) E820 table:
>>> (d4)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>> (d4)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>> (d4)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>> (d4)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>> (d4)  HOLE: 00000000:78000000 - 00000000:fc000000
>>> (d4)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>> (d4) Invoking SeaBIOS ...
>>> (d4) SeaBIOS (version 
>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>> (d4)
>>> (d4) Found Xen hypervisor signature at 40000100
>>> (d4) Running on QEMU (i440fx)
>>> (d4) xen: copy e820...
>>> (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>> (d4) CPU Mhz=3D2661
>>> (d4) Found 13 PCI devices (max PCI bus is 00)
>>> (d4) Allocated Xen hypercall page at 77fff000
>>> (d4) Detected Xen v4.5.0-rc
>>> (d4) xen: copy BIOS tables...
>>> (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>> (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>> (d4) Copying PIR from 0x00010030 to 0x000f0dc0
>>> (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>> (d4) Using pmtimer, ioport 0xb008
>>> (d4) Scan for VGA option rom
>>> (d4) Running option rom at c000:0003
>>> (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes
>>> (d4) pmm call arg1=3D0
>>> (d4) Turning on vga text mode console
>>> (d4) SeaBIOS (version 
>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>> (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838
>>> (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)
>>> (d4) Found 0 lpt ports
>>> (d4) Found 0 serial ports
>>> (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>> (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>> (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)
>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>> (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
>>> (d4) UHCI init on dev 00:1d.0 (io=3Dc240)
>>> (d4) UHCI init on dev 00:1d.1 (io=3Dc260)
>>> (d4) UHCI init on dev 00:1d.2 (io=3Dc280)
>>> (d4) PS2 keyboard initialized
>>> (d4) All threads complete.
>>> (d4) Scan for option roms
>>> (d4) Running option rom at c980:0003
>>> (d4) pmm call arg1=3D1
>>> (d4) pmm call arg1=3D0
>>> (d4) pmm call arg1=3D1
>>> (d4) pmm call arg1=3D0
>>> (d4) Searching bootorder for: /pci@i0cf8/*@6
>>> (d4)
>>> (d4) Press F12 for boot menu.
>>> (d4)
>>> (d4) Searching bootorder for: HALT
>>> (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba 
>>> LCHS=3D1024/255/63 s=3D102400000
>>> (d4)
>>> (d4) Space available for UMB: ca800-ee800, f0000-f0ce0
>>> (d4) Returned 258048 bytes of ZoneHigh
>>> (d4) e820 map has 6 items:
>>> (d4)   0: 0000000000000000 - 000000000009fc00 =3D 1 RAM
>>> (d4)   1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED
>>> (d4)   2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED
>>> (d4)   3: 0000000000100000 - 0000000077fff000 =3D 1 RAM
>>> (d4)   4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED
>>> (d4)   5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED
>>> (d4) enter handle_19:
>>> (d4)   NULL
>>> (d4) Booting from DVD/CD...
>>> (d4) Device reports MEDIUM NOT PRESENT
>>> (d4) scsi_is_ready returned -1
>>> (d4) Boot failed: Could not read from CDROM (code 0003)
>>> (d4) enter handle_18:
>>> (d4)   NULL
>>> (d4) Booting from Hard Disk...
>>> (d4) Booting from 0000:7c00
>>> (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 
>>> sp: 1 build: 1db1
>>> (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
>>> (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
>>> (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -> 0
>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -> 0
>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -> 0
>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -> 0
>>> *(XEN) hvm.c:6119:d4v1 Bad HVM op 23.**
>>> **(XEN) hvm.c:6119:d4v1 Bad HVM op 23.*
>>> (XEN) irq.c:380: Dom4 callback via changed to GSI 24
>>> (XEN) HVM4 save: CPU
>>> (XEN) HVM4 save: PIC
>>> (XEN) HVM4 save: IOAPIC
>>> (XEN) HVM4 save: LAPIC
>>> (XEN) HVM4 save: LAPIC_REGS
>>> (XEN) HVM4 save: PCI_IRQ
>>> (XEN) HVM4 save: ISA_IRQ
>>> (XEN) HVM4 save: PCI_LINK
>>> (XEN) HVM4 save: PIT
>>> (XEN) HVM4 save: RTC
>>> (XEN) HVM4 save: HPET
>>> (XEN) HVM4 save: PMTIMER
>>> (XEN) HVM4 save: MTRR
>>> (XEN) HVM4 save: VIRIDIAN_DOMAIN
>>> (XEN) HVM4 save: CPU_XSAVE
>>> (XEN) HVM4 save: VIRIDIAN_VCPU
>>> (XEN) HVM4 save: VMCE_VCPU
>>> (XEN) HVM4 save: TSC_ADJUST
>>> (XEN) HVM5 restore: CPU 0
>>> (XEN) HVM5 restore: CPU 1
>>> (XEN) HVM5 restore: PIC 0
>>> (XEN) HVM5 restore: PIC 1
>>> (XEN) HVM5 restore: IOAPIC 0
>>> (XEN) HVM5 restore: LAPIC 0
>>> (XEN) HVM5 restore: LAPIC 1
>>> (XEN) HVM5 restore: LAPIC_REGS 0
>>> (XEN) HVM5 restore: LAPIC_REGS 1
>>> (XEN) HVM5 restore: PCI_IRQ 0
>>> (XEN) HVM5 restore: ISA_IRQ 0
>>> (XEN) HVM5 restore: PCI_LINK 0
>>> (XEN) HVM5 restore: PIT 0
>>> (XEN) HVM5 restore: RTC 0
>>> (XEN) HVM5 restore: HPET 0
>>> (XEN) HVM5 restore: PMTIMER 0
>>> (XEN) HVM5 restore: MTRR 0
>>> (XEN) HVM5 restore: MTRR 1
>>> (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0
>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 0
>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 1
>>> (XEN) HVM5 restore: VMCE_VCPU 0
>>> (XEN) HVM5 restore: VMCE_VCPU 1
>>> (XEN) HVM5 restore: TSC_ADJUST 0
>>> (XEN) HVM5 restore: TSC_ADJUST 1
>>> (XEN) irq.c:380: Dom5 callback via changed to None
>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>>> (XEN) irq.c:380: Dom5 callback via changed to GSI 24
>>
>>
>


--------------060009010202020400050503
Content-Type: text/html; charset=windows-1252
Content-Length: 55940
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Il 13/11/2014 13:22, Fabio Fantoni ha
      scritto:<br>
    </div>
    <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite">
      <meta content=3D"text/html; charset=3Dwindows-1252"
        http-equiv=3D"Content-Type">
      <div class=3D"moz-cite-prefix">Il 13/11/2014 11:14, Fabio Fantoni ha
        scritto:<br>
      </div>
      <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite">
        <meta content=3D"text/html; charset=3Dwindows-1252"
          http-equiv=3D"Content-Type">
        <div class=3D"moz-cite-prefix">Il 19/09/2014 15:18, Fabio Fantoni
          ha scritto:<br>
        </div>
        <blockquote cite=3D"mid:541C2D39.1060607@m2r.biz" type=3D"cite">Il
          12/09/2014 16:46, Fabio Fantoni ha scritto: <br>
          <blockquote type=3D"cite">Il 08/07/2014 12:34, Fabio Fantoni ha
            scritto: <br>
            <blockquote type=3D"cite">Il 08/07/2014 12:06, Fabio Fantoni
              ha scritto: <br>
              <blockquote type=3D"cite">Il 08/07/2014 10:53, David Ja=9Aa ha
                scritto: <br>
                <blockquote type=3D"cite">Hi, <br>
                  <br>
                  On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
                  <br>
                  <blockquote type=3D"cite">On xen 4.5 (tried with qemu
                    2.0.0/2.1-rc0, spice 0.12.5 and client with <br>
                    spice-gtk 0.23/0.25) windows 7 domUs with qxl vga
                    works good as kvm <br>
                    except for one problem after xl save/restore, when
                    after restore on <br>
                    spice client connect=A0 the domU's screen freezed for
                    2-3 minutes (and <br>
                    seems also windows), after this time seems that all
                    return to works <br>
                    correctly. <br>
                    This problem happen also if spice client connect
                    long time after restore. <br>
                    With stdvga not have this problem but stdvga has
                    many missed resolutions <br>
                    and bad refresh performance. <br>
                    <br>
                    If you need more tests/informations tell me and I'll
                    post them. <br>
                  </blockquote>
                  Client and server logs would certainly help. Please
                  run: <br>
                  =A0=A0 * virt-viewer with --spice-debug option <br>
                  =A0=A0 * spice-server with SPICE_DEBUG_LEVEL environment
                  variable set <br>
                  =A0=A0=A0=A0 to 4 or 5 (if you use qemu+libvirt, use qemu:env
                  element: <br>
                  =A0=A0=A0=A0 <a moz-do-not-send=3D"true"
                    class=3D"moz-txt-link-freetext"
                    href=3D"http://libvirt.org/drvqemu.html#qemucommand">http://libvirt.org/drvqemu.html#qemucommand</a>
                  ) <br>
                  and note the location in the logs where the freeze
                  takes place. <br>
                  <br>
                  Regards, <br>
                  <br>
                  David <br>
                </blockquote>
                <br>
                Thanks for your reply, in attachments: <br>
                - domU's xl cfg: W7.cfg <br>
                - xl -vvv create/save/restore: xen logs.txt <br>
                - remote-viewer with --spice-debug after domU's start
                until xl save: spicelog-1.txt (zipped) <br>
                - remote-viewer with --spice-debug after domU's xl
                restore: spicelog-2.txt <br>
              </blockquote>
              <br>
              Sorry for my forgetfulness, here also qemu's log: <br>
              - after domU's start until xl save: qemu-dm-W7.log.1 <br>
              - after domU's xl restore: qemu-dm-W7.log <br>
              <br>
              <blockquote type=3D"cite"> <br>
                If you need more tests/informations tell me and I'll
                post them. <br>
                <br>
                <br>
                <blockquote type=3D"cite">Thanks for any reply and sorry
                  for my bad english. <br>
                  <br>
                  _______________________________________________ <br>
                  Spice-devel mailing list <br>
                  <a moz-do-not-send=3D"true"
                    class=3D"moz-txt-link-abbreviated"
                    href=3D"mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a>
                  <br>
                  <a moz-do-not-send=3D"true"
                    class=3D"moz-txt-link-freetext"
                    href=3D"http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a>
                  <br>
                </blockquote>
              </blockquote>
              <br>
            </blockquote>
            <br>
            The problem persist, this time I saw these in xl dmesg after
            restore: <br>
            <br>
            (XEN) HVM2 restore: CPU 0 <br>
            (XEN) HVM2 restore: CPU 1 <br>
            (XEN) HVM2 restore: PIC 0 <br>
            (XEN) HVM2 restore: PIC 1 <br>
            (XEN) HVM2 restore: IOAPIC 0 <br>
            (XEN) HVM2 restore: LAPIC 0 <br>
            (XEN) HVM2 restore: LAPIC 1 <br>
            (XEN) HVM2 restore: LAPIC_REGS 0 <br>
            (XEN) HVM2 restore: LAPIC_REGS 1 <br>
            (XEN) HVM2 restore: PCI_IRQ 0 <br>
            (XEN) HVM2 restore: ISA_IRQ 0 <br>
            (XEN) HVM2 restore: PCI_LINK 0 <br>
            (XEN) HVM2 restore: PIT 0 <br>
            (XEN) HVM2 restore: RTC 0 <br>
            (XEN) HVM2 restore: HPET 0 <br>
            (XEN) HVM2 restore: PMTIMER 0 <br>
            (XEN) HVM2 restore: MTRR 0 <br>
            (XEN) HVM2 restore: MTRR 1 <br>
            (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0 <br>
            (XEN) HVM2 restore: VIRIDIAN_VCPU 0 <br>
            (XEN) HVM2 restore: VIRIDIAN_VCPU 1 <br>
            (XEN) HVM2 restore: VMCE_VCPU 0 <br>
            (XEN) HVM2 restore: VMCE_VCPU 1 <br>
            (XEN) HVM2 restore: TSC_ADJUST 0 <br>
            (XEN) HVM2 restore: TSC_ADJUST 1 <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid <br>
            (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid <br>
            (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table
            from (4) to (32) frames. <br>
            (XEN) irq.c:380: Dom2 callback via changed to GSI 24 <br>
            <br>
            Tested on latest staging (commit
            7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice
            patches: <br>
            <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
              href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a>
            <br>
            <br>
            If you need more informations or tests tell me and I'll post
            them. <br>
            Thanks for any reply and sorry for my bad english. <br>
          </blockquote>
          <br>
          I did another tests updating to latest git staging (commit
          3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore
          problem of "only" 2-3 minutes but now when it appears to
          restart (after 2-3 minutes) windows domUs undefinitely hangs
          instead. <br>
          No further details in xen and domU's logs. <br>
          <br>
          If you need more tests/details tell me and I'll do them. <br>
          <br>
          Thanks for any reply. <br>
        </blockquote>
        <br>
        I did a new test with xen build based on tag 4.5.0-rc2 and on xl
        dmesg show these errors:<br>
        <blockquote type=3D"cite"><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b></blockquote>
        Before and after save/restore, with stdvga instead not show
        them.<br>
      </blockquote>
      <br>
      Sorry, I found that was introduced by new winpv drivers update
      instead and I solved applying this patch:<br>
      x86/hvm: Add per-vcpu evtchn upcalls v3 <a moz-do-not-send=3D"true"
        class=3D"moz-txt-link-freetext"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html">http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html</a><br>
      About save/restore problem with qxl I still not found a solution
      or at least the exact cause :(<br>
    </blockquote>
    <br>
    I tried a strace on qemu process when windows (in domU) is in temp.
    freeze and still does many operations (seems similar), I post below
    a small part if can be useful.<br>
    I noted for example some of these lines:<br>
    read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
    temporarily unavailable)<br>
    Is it normal=3F<br>
    <br>
    ...<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 4197512}, NULL, 8) =3D
    2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0,
    4193071})<br>
    read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    read(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
    write(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0<br>
    gettimeofday({1416480295, 28658}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0<br>
    gettimeofday({1416480295, 28811}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
    ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
    <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
      temporarily unavailable)</b><br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
    0x7f4a3b435000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
    0x7f4a3b434000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
    0x7f4a3b433000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
    0x7f4a3b432000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
    0x7f4a3b2db000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
    0x7f4a3b2da000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
    0x7f4a3b2d9000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
    0x7f4a3b2d8000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
    0x7f4a3b2d7000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
    0x7f4a3b2d6000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
    0x7f4a3b2d5000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
    0x7f4a3b2d4000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
    0x7f4a3b2d3000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
    0x7f4a3b2d2000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
    0x7f4a3b2d1000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
    0x7f4a3b2d0000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
    0x7f4a3b2cf000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
    0x7f4a3b2ce000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
    0x7f4a3b2cd000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D
    0x7f4a3b2cc000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D
    0x7f4a3b2cb000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D
    0x7f4a3b2ca000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D
    0x7f4a3b2c9000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D
    0x7f4a3b2c8000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D
    0x7f4a3b2c7000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D
    0x7f4a3b2c6000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D
    0x7f4a3b2c5000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D
    0x7f4a3b2c4000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D
    0x7f4a3b2c3000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D
    0x7f4a3b2c2000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D
    0x7f4a3b2c1000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    read(6, "\1\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0<br>
    gettimeofday({1416480295, 35292}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0<br>
    gettimeofday({1416480295, 35746}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0<br>
    gettimeofday({1416480295, 35898}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 13233688}, NULL, 8)
    =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0,
    13227138})<br>
    read(20,
    "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"...,
    69632) =3D 101<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0<br>
    gettimeofday({1416480295, 36400}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0<br>
    gettimeofday({1416480295, 36550}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 12581076}, NULL, 8)
    =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0,
    12576281})<br>
    read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    read(20,
    "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"...,
    69632) =3D 101<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0<br>
    gettimeofday({1416480295, 37123}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0<br>
    gettimeofday({1416480295, 37273}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 11857546}, NULL, 8)
    =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 9477611})<br>
    <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
      temporarily unavailable)</b><br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    read(6, "\5\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0<br>
    gettimeofday({1416480295, 40643}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0<br>
    gettimeofday({1416480295, 40946}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0<br>
    gettimeofday({1416480295, 41097}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
    ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d0000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2cf000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2ce000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2cd000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2cc000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2cb000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2ca000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0<br>
    gettimeofday({1416480295, 48329}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0<br>
    gettimeofday({1416480295, 48632}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0<br>
    gettimeofday({1416480295, 48783}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
    ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
    read(8, "\4\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2c1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
    0x7f4a3b435000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
    0x7f4a3b434000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
    0x7f4a3b433000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
    0x7f4a3b432000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
    0x7f4a3b2db000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
    0x7f4a3b2da000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
    0x7f4a3b2d9000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
    0x7f4a3b2d8000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0<br>
    gettimeofday({1416480295, 52051}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0<br>
    gettimeofday({1416480295, 52426}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0<br>
    gettimeofday({1416480295, 52576}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
    ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
    read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
    0x7f4a3b2d7000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
    0x7f4a3b2d6000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
    0x7f4a3b2d5000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
    0x7f4a3b2d4000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
    0x7f4a3b2d3000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
    0x7f4a3b2d2000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
    0x7f4a3b2d1000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
    0x7f4a3b2d0000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
    0x7f4a3b2cf000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
    0x7f4a3b2ce000<br>
    ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
    mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
    0x7f4a3b2cd000<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0<br>
    futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0<br>
    gettimeofday({1416480295, 55341}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0<br>
    gettimeofday({1416480295, 55725}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0<br>
    gettimeofday({1416480295, 55876}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
    ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
    read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
    munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
    ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
    read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0<br>
    gettimeofday({1416480295, 58810}, NULL) =3D 0<br>
    write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0<br>
    gettimeofday({1416480295, 59114}, NULL) =3D 0<br>
    clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0<br>
    gettimeofday({1416480295, 59265}, NULL) =3D 0<br>
    ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
    events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
    events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
    ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
    ...<br>
    <br>
    Strace of domU's qemu process during freeze can be useful=3F I must do
    a more specific tests=3F<br>
    If you need more informations/tests tell me and I'll post them.<br>
    <br>
    Thanks for any reply and sorry for my bad english.<br>
    <br>
    <br>
    <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite"> <br>
      <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite"> <br>
        Below I posted full xl dmesg of domU, if you need more
        informations/tests tell me and I'll post them.<br>
        <br>
        <br>
        <blockquote type=3D"cite">(d4) HVM Loader<br>
          (d4) Detected Xen v4.5.0-rc<br>
          (d4) Xenbus rings @0xfeffc000, event channel 1<br>
          (d4) System requested SeaBIOS<br>
          (d4) CPU speed is 2660 MHz<br>
          (d4) Relocating guest memory for lowmem MMIO space disabled<br>
          (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -&gt; 5<br>
          (d4) PCI-ISA link 0 routed to IRQ5<br>
          (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -&gt; 10<br>
          (d4) PCI-ISA link 1 routed to IRQ10<br>
          (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -&gt; 11<br>
          (d4) PCI-ISA link 2 routed to IRQ11<br>
          (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -&gt; 5<br>
          (d4) PCI-ISA link 3 routed to IRQ5<br>
          (d4) pci dev 01:3 INTA-&gt;IRQ10<br>
          (d4) pci dev 02:0 INTA-&gt;IRQ11<br>
          (d4) pci dev 03:0 INTA-&gt;IRQ5<br>
          (d4) pci dev 04:0 INTA-&gt;IRQ5<br>
          (d4) pci dev 05:0 INTA-&gt;IRQ10<br>
          (d4) pci dev 06:0 INTA-&gt;IRQ11<br>
          (d4) pci dev 1d:0 INTA-&gt;IRQ10<br>
          (d4) pci dev 1d:1 INTB-&gt;IRQ11<br>
          (d4) pci dev 1d:2 INTC-&gt;IRQ5<br>
          (d4) pci dev 1d:7 INTD-&gt;IRQ5<br>
          (d4) No RAM in high memory; setting high_mem resource base to
          100000000<br>
          (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000<br>
          (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000<br>
          (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008<br>
          (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000<br>
          (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000<br>
          (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000<br>
          (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000<br>
          (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000<br>
          (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000<br>
          (d4) pci dev 02:0 bar 10 size 000000100: 00000c001<br>
          (d4) pci dev 06:0 bar 10 size 000000100: 00000c101<br>
          (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000<br>
          (d4) pci dev 04:0 bar 10 size 000000020: 00000c201<br>
          (d4) pci dev 05:0 bar 1c size 000000020: 00000c221<br>
          (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241<br>
          (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261<br>
          (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281<br>
          (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1<br>
          (d4) Multiprocessor initialisation:<br>
          (d4)=A0 - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs
          [1/8] ... done.<br>
          (d4)=A0 - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs
          [1/8] ... done.<br>
          (d4) Testing HVM environment:<br>
          (d4)=A0 - REP INSB across page boundaries ... passed<br>
          (d4)=A0 - GS base MSRs and SWAPGS ... passed<br>
          (d4) Passed 2 of 2 tests<br>
          (d4) Writing SMBIOS tables ...<br>
          (d4) Loading SeaBIOS ...<br>
          (d4) Creating MP tables ...<br>
          (d4) Loading ACPI ...<br>
          (d4) S3 disabled<br>
          (d4) S4 disabled<br>
          (d4) vm86 TSS at fc00a100<br>
          (d4) BIOS map:<br>
          (d4)=A0 10000-100d3: Scratch space<br>
          (d4)=A0 c0000-fffff: Main BIOS<br>
          (d4) E820 table:<br>
          (d4)=A0 [00]: 00000000:00000000 - 00000000:000a0000: RAM<br>
          (d4)=A0 HOLE: 00000000:000a0000 - 00000000:000c0000<br>
          (d4)=A0 [01]: 00000000:000c0000 - 00000000:00100000: RESERVED<br>
          (d4)=A0 [02]: 00000000:00100000 - 00000000:78000000: RAM<br>
          (d4)=A0 HOLE: 00000000:78000000 - 00000000:fc000000<br>
          (d4)=A0 [03]: 00000000:fc000000 - 00000001:00000000: RESERVED<br>
          (d4) Invoking SeaBIOS ...<br>
          (d4) SeaBIOS (version
          debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
          (d4) <br>
          (d4) Found Xen hypervisor signature at 40000100<br>
          (d4) Running on QEMU (i440fx)<br>
          (d4) xen: copy e820...<br>
          (d4) Relocating init from 0x000df619 to 0x77fae600 (size
          71995)<br>
          (d4) CPU Mhz=3D2661<br>
          (d4) Found 13 PCI devices (max PCI bus is 00)<br>
          (d4) Allocated Xen hypercall page at 77fff000<br>
          (d4) Detected Xen v4.5.0-rc<br>
          (d4) xen: copy BIOS tables...<br>
          (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40<br>
          (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40<br>
          (d4) Copying PIR from 0x00010030 to 0x000f0dc0<br>
          (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90<br>
          (d4) Using pmtimer, ioport 0xb008<br>
          (d4) Scan for VGA option rom<br>
          (d4) Running option rom at c000:0003<br>
          (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes<br>
          (d4) pmm call arg1=3D0<br>
          (d4) Turning on vga text mode console<br>
          (d4) SeaBIOS (version
          debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
          (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838<br>
          (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)<br>
          (d4) Found 0 lpt ports<br>
          (d4) Found 0 serial ports<br>
          (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)<br>
          (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)<br>
          (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)<br>
          (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0<br>
          (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]<br>
          (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1<br>
          (d4) UHCI init on dev 00:1d.0 (io=3Dc240)<br>
          (d4) UHCI init on dev 00:1d.1 (io=3Dc260)<br>
          (d4) UHCI init on dev 00:1d.2 (io=3Dc280)<br>
          (d4) PS2 keyboard initialized<br>
          (d4) All threads complete.<br>
          (d4) Scan for option roms<br>
          (d4) Running option rom at c980:0003<br>
          (d4) pmm call arg1=3D1<br>
          (d4) pmm call arg1=3D0<br>
          (d4) pmm call arg1=3D1<br>
          (d4) pmm call arg1=3D0<br>
          (d4) Searching bootorder for: /pci@i0cf8/*@6<br>
          (d4) <br>
          (d4) Press F12 for boot menu.<br>
          (d4) <br>
          (d4) Searching bootorder for: HALT<br>
          (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba
          LCHS=3D1024/255/63 s=3D102400000<br>
          (d4) <br>
          (d4) Space available for UMB: ca800-ee800, f0000-f0ce0<br>
          (d4) Returned 258048 bytes of ZoneHigh<br>
          (d4) e820 map has 6 items:<br>
          (d4)=A0=A0 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM<br>
          (d4)=A0=A0 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED<br>
          (d4)=A0=A0 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED<br>
          (d4)=A0=A0 3: 0000000000100000 - 0000000077fff000 =3D 1 RAM<br>
          (d4)=A0=A0 4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED<br>
          (d4)=A0=A0 5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED<br>
          (d4) enter handle_19:<br>
          (d4)=A0=A0 NULL<br>
          (d4) Booting from DVD/CD...<br>
          (d4) Device reports MEDIUM NOT PRESENT<br>
          (d4) scsi_is_ready returned -1<br>
          (d4) Boot failed: Could not read from CDROM (code 0003)<br>
          (d4) enter handle_18:<br>
          (d4)=A0=A0 NULL<br>
          (d4) Booting from Hard Disk...<br>
          (d4) Booting from 0000:7c00<br>
          (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6
          minor: 1 sp: 1 build: 1db1<br>
          (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff<br>
          (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe<br>
          (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd<br>
          (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -&gt; 0<br>
          (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -&gt; 0<br>
          (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -&gt; 0<br>
          (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -&gt; 0<br>
          <b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><b><br>
          </b><b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><br>
          (XEN) irq.c:380: Dom4 callback via changed to GSI 24<br>
          (XEN) HVM4 save: CPU<br>
          (XEN) HVM4 save: PIC<br>
          (XEN) HVM4 save: IOAPIC<br>
          (XEN) HVM4 save: LAPIC<br>
          (XEN) HVM4 save: LAPIC_REGS<br>
          (XEN) HVM4 save: PCI_IRQ<br>
          (XEN) HVM4 save: ISA_IRQ<br>
          (XEN) HVM4 save: PCI_LINK<br>
          (XEN) HVM4 save: PIT<br>
          (XEN) HVM4 save: RTC<br>
          (XEN) HVM4 save: HPET<br>
          (XEN) HVM4 save: PMTIMER<br>
          (XEN) HVM4 save: MTRR<br>
          (XEN) HVM4 save: VIRIDIAN_DOMAIN<br>
          (XEN) HVM4 save: CPU_XSAVE<br>
          (XEN) HVM4 save: VIRIDIAN_VCPU<br>
          (XEN) HVM4 save: VMCE_VCPU<br>
          (XEN) HVM4 save: TSC_ADJUST<br>
          (XEN) HVM5 restore: CPU 0<br>
          (XEN) HVM5 restore: CPU 1<br>
          (XEN) HVM5 restore: PIC 0<br>
          (XEN) HVM5 restore: PIC 1<br>
          (XEN) HVM5 restore: IOAPIC 0<br>
          (XEN) HVM5 restore: LAPIC 0<br>
          (XEN) HVM5 restore: LAPIC 1<br>
          (XEN) HVM5 restore: LAPIC_REGS 0<br>
          (XEN) HVM5 restore: LAPIC_REGS 1<br>
          (XEN) HVM5 restore: PCI_IRQ 0<br>
          (XEN) HVM5 restore: ISA_IRQ 0<br>
          (XEN) HVM5 restore: PCI_LINK 0<br>
          (XEN) HVM5 restore: PIT 0<br>
          (XEN) HVM5 restore: RTC 0<br>
          (XEN) HVM5 restore: HPET 0<br>
          (XEN) HVM5 restore: PMTIMER 0<br>
          (XEN) HVM5 restore: MTRR 0<br>
          (XEN) HVM5 restore: MTRR 1<br>
          (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0<br>
          (XEN) HVM5 restore: VIRIDIAN_VCPU 0<br>
          (XEN) HVM5 restore: VIRIDIAN_VCPU 1<br>
          (XEN) HVM5 restore: VMCE_VCPU 0<br>
          (XEN) HVM5 restore: VMCE_VCPU 1<br>
          (XEN) HVM5 restore: TSC_ADJUST 0<br>
          (XEN) HVM5 restore: TSC_ADJUST 1<br>
          (XEN) irq.c:380: Dom5 callback via changed to None<br>
          <b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
          </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
          </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
          </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><br>
          (XEN) irq.c:380: Dom5 callback via changed to GSI 24</blockquote>
        <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------060009010202020400050503--


--===============4622071111556217136==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4622071111556217136==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 11:23:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:23:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPps-0003Cu-Vd; Thu, 20 Nov 2014 11:23:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPpr-0003Cg-6q
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:23:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	27/4C-25276-93FCD645; Thu, 20 Nov 2014 11:23:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416482617!14060965!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22020 invoked from network); 20 Nov 2014 11:23:37 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:23:37 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so3439226wgg.0
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 03:23:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=J6v8j3DBrMP+Zct5U5JliK2tfqx8Ig3o/ATBje4vS0o=;
	b=JHI43xLuqStELEMjsrotx7PaxT3wIXkeR5QnU1nY8wuiiYjhogB7Hv21BcuZ9iGDs6
	+yL43tnrS8rZ0716G/S/2jIEXb+JSh3iSpxZ5K+KwYkTrz9mOY717Spi1z2gSUGIjWqj
	SkxXsuYvL53egnd8N6XXsb9WpYhdWIion3VUZD+SN8rAZlettB++SKGWkADUaRjLDk5n
	LSReaoNFk9wrlxYXwXJIR93uUbnuj8k/Hmlg4FTfeX8cmT3nSXW0Vdh5n4wlnRYqwgc3
	A21C6CcWZXQFCPe+Pojle4g3mMp3z8t/rzDowawqCXZzJr6C181VXFvh+uKkuS3qwhsD
	YHHQ==
X-Gm-Message-State: ALoCoQld9SLENxq2fZt2JL/yBsahcXBBa2tx8c6WK9FB6qu5ELp8R5UJSeueTGw1R5L+Gb8jaBIC
X-Received: by 10.181.8.72 with SMTP id di8mr3284456wid.1.1416482617189;
	Thu, 20 Nov 2014 03:23:37 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id j17sm2913590wjn.32.2014.11.20.03.23.35
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:23:36 -0800 (PST)
Message-ID: <546DCF36.7080400@linaro.org>
Date: Thu, 20 Nov 2014 11:23:34 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-3-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416410895-20461-3-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 3/5] xen: arm: correct off by one
 in xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/19/2014 03:28 PM, Ian Campbell wrote:
> The callers pass the end as the pfn immediately *after* the last page to be
> mapped, therefore adding one is incorrect and causes an additional page to be
> mapped.
> 
> At the same time correct the printing of the mfn values, zero-padding them to
> 16 digits as for a paddr when they are frame numbers is just confusing.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

> ---
> v2: Fix the other printk format string too.
> ---
>  xen/arch/arm/platforms/xgene-storm.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 29c4752..8685c93 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -45,11 +45,11 @@ static int map_one_mmio(struct domain *d, const char *what,
>  {
>      int ret;
>  
> -    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
> +    printk("Additional MMIO %lx-%lx (%s)\n",
>             start, end, what);
> -    ret = map_mmio_regions(d, start, end - start + 1, start);
> +    ret = map_mmio_regions(d, start, end - start, start);
>      if ( ret )
> -        printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
> +        printk("Failed to map %s @ %lx to dom%d\n",
>                 what, start, d->domain_id);
>      return ret;
>  }
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:23:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:23:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPps-0003Cu-Vd; Thu, 20 Nov 2014 11:23:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPpr-0003Cg-6q
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:23:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	27/4C-25276-93FCD645; Thu, 20 Nov 2014 11:23:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416482617!14060965!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22020 invoked from network); 20 Nov 2014 11:23:37 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:23:37 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so3439226wgg.0
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 03:23:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=J6v8j3DBrMP+Zct5U5JliK2tfqx8Ig3o/ATBje4vS0o=;
	b=JHI43xLuqStELEMjsrotx7PaxT3wIXkeR5QnU1nY8wuiiYjhogB7Hv21BcuZ9iGDs6
	+yL43tnrS8rZ0716G/S/2jIEXb+JSh3iSpxZ5K+KwYkTrz9mOY717Spi1z2gSUGIjWqj
	SkxXsuYvL53egnd8N6XXsb9WpYhdWIion3VUZD+SN8rAZlettB++SKGWkADUaRjLDk5n
	LSReaoNFk9wrlxYXwXJIR93uUbnuj8k/Hmlg4FTfeX8cmT3nSXW0Vdh5n4wlnRYqwgc3
	A21C6CcWZXQFCPe+Pojle4g3mMp3z8t/rzDowawqCXZzJr6C181VXFvh+uKkuS3qwhsD
	YHHQ==
X-Gm-Message-State: ALoCoQld9SLENxq2fZt2JL/yBsahcXBBa2tx8c6WK9FB6qu5ELp8R5UJSeueTGw1R5L+Gb8jaBIC
X-Received: by 10.181.8.72 with SMTP id di8mr3284456wid.1.1416482617189;
	Thu, 20 Nov 2014 03:23:37 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id j17sm2913590wjn.32.2014.11.20.03.23.35
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:23:36 -0800 (PST)
Message-ID: <546DCF36.7080400@linaro.org>
Date: Thu, 20 Nov 2014 11:23:34 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-3-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416410895-20461-3-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 3/5] xen: arm: correct off by one
 in xgene-storm's map_one_mmio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/19/2014 03:28 PM, Ian Campbell wrote:
> The callers pass the end as the pfn immediately *after* the last page to be
> mapped, therefore adding one is incorrect and causes an additional page to be
> mapped.
> 
> At the same time correct the printing of the mfn values, zero-padding them to
> 16 digits as for a paddr when they are frame numbers is just confusing.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

> ---
> v2: Fix the other printk format string too.
> ---
>  xen/arch/arm/platforms/xgene-storm.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 29c4752..8685c93 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -45,11 +45,11 @@ static int map_one_mmio(struct domain *d, const char *what,
>  {
>      int ret;
>  
> -    printk("Additional MMIO %"PRIpaddr"-%"PRIpaddr" (%s)\n",
> +    printk("Additional MMIO %lx-%lx (%s)\n",
>             start, end, what);
> -    ret = map_mmio_regions(d, start, end - start + 1, start);
> +    ret = map_mmio_regions(d, start, end - start, start);
>      if ( ret )
> -        printk("Failed to map %s @ %"PRIpaddr" to dom%d\n",
> +        printk("Failed to map %s @ %lx to dom%d\n",
>                 what, start, d->domain_id);
>      return ret;
>  }
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:26:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:26:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPso-0003PB-KQ; Thu, 20 Nov 2014 11:26:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPsm-0003P4-UL
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:26:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	77/20-09936-0FFCD645; Thu, 20 Nov 2014 11:26:40 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416482799!14129649!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20110 invoked from network); 20 Nov 2014 11:26:39 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:26:39 -0000
Received: by mail-wg0-f46.google.com with SMTP id x12so3428364wgg.5
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 03:26:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=QpUfON5X3c8cDgSVMEecTl5rSciuBp3b38K7QUL6UY0=;
	b=eGbvD10FRxfKd4JKVDMUG1E0PrhslrKZbNnYadOAZRbNvhquWuNZ63roH4xvLjzIvf
	l13wqW2cwjkA7voMCn4jpzmsPIN8QAIK79rIC6taeQTwn9f11tmnp+/cT8+g2KJ9eTy8
	rb64TsCQaoznPIPC/2sOv5sGUwUcTXQuT4wbJbbYBxi1sfo8OfBNKg7aBGTxFZTi7NWx
	JwuLltY802aWpjj/gOZljx/kW4wb/gx8HIU6t9IJXSmOzhGLTWg/Z6pIWkDyFkYVA2SD
	WEXNlRP9H+BMktbcJCJYHET1CdQ/rrlYYtUJix/VJ7AeSxOHqoftwiPJA1/zYrQ2Cx9X
	ZCHA==
X-Gm-Message-State: ALoCoQkpmWFAmSorwyfDOyuh4kEftNBIdqeD3ksVOe7y+3QGlWPVIA+bNbKvW+4MO6dXrgHoc/u4
X-Received: by 10.180.85.6 with SMTP id d6mr3328438wiz.82.1416482799471;
	Thu, 20 Nov 2014 03:26:39 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fv5sm2918503wjc.37.2014.11.20.03.26.37
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:26:38 -0800 (PST)
Message-ID: <546DCFEC.9030200@linaro.org>
Date: Thu, 20 Nov 2014 11:26:36 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 5/5] xen: arm: Support the other
 4 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/19/2014 03:28 PM, Ian Campbell wrote:
> Currently we only establish specific mappings for pcie0, which is
> used on the Mustang platform. However at least McDivitt uses pcie3.
> So wire up all the others, based on whether the corresponding DT node
> is marked as available.
> 
> This results in no change for Mustang.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: - Didn't constify dt node pointer -- dt_find_compatible_node needs a
>       non-const

Oh right. A bit annoying, I will look at it to see if we can constify
the parameter in Xen 4.6.

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

>     - Print a message when ignoring an unknown bus
>     - Log with dt node full anme instead of CFG space address.
>     - Log at start of xgene_storm_pcie_specific_mapping instead of in the
>       caller after the fact.
> ---
>  xen/arch/arm/platforms/xgene-storm.c |   89 +++++++++++++++++++++++++++++-----
>  1 file changed, 76 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 8c27f24..0b3492d 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -78,35 +78,35 @@ static int map_one_spi(struct domain *d, const char *what,
>      return ret;
>  }
>  
> -/*
> - * Xen does not currently support mapping MMIO regions and interrupt
> - * for bus child devices (referenced via the "ranges" and
> - * "interrupt-map" properties to domain 0). Instead for now map the
> - * necessary resources manually.
> - */
> -static int xgene_storm_specific_mapping(struct domain *d)
> +/* Creates MMIO mappings base..end as well as 4 SPIs from the given base. */
> +static int xgene_storm_pcie_specific_mapping(struct domain *d,
> +                                             const struct dt_device_node *node,
> +                                             paddr_t base, paddr_t end,
> +                                             int base_spi)
>  {
>      int ret;
>  
> +    printk("Mapping additional regions for PCIe device %s\n",
> +           dt_node_full_name(node));
> +
>      /* Map the PCIe bus resources */
> -    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
> -                                        paddr_to_pfn(0x01000000000UL));
> +    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(base), paddr_to_pfn(end));
>      if ( ret )
>          goto err;
>  
> -    ret = map_one_spi(d, "PCI#INTA", 0xc2, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTA", base_spi+0, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>  
> -    ret = map_one_spi(d, "PCI#INTB", 0xc3, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTB", base_spi+1, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>  
> -    ret = map_one_spi(d, "PCI#INTC", 0xc4, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTC", base_spi+2, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>  
> -    ret = map_one_spi(d, "PCI#INTD", 0xc5, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTD", base_spi+3, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>  
> @@ -115,6 +115,69 @@ err:
>      return ret;
>  }
>  
> +/*
> + * Xen does not currently support mapping MMIO regions and interrupt
> + * for bus child devices (referenced via the "ranges" and
> + * "interrupt-map" properties to domain 0). Instead for now map the
> + * necessary resources manually.
> + */
> +static int xgene_storm_specific_mapping(struct domain *d)
> +{
> +    struct dt_device_node *node = NULL;
> +    int ret;
> +
> +    while ( (node = dt_find_compatible_node(node, "pci", "apm,xgene-pcie")) )
> +    {
> +        u64 addr;
> +
> +        /* Identify the bus via it's control register address */
> +        ret = dt_device_get_address(node, 0, &addr, NULL);
> +        if ( ret < 0 )
> +            return ret;
> +
> +        if ( !dt_device_is_available(node) )
> +            continue;
> +
> +       switch ( addr )
> +        {
> +        case 0x1f2b0000: /* PCIe0 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0e000000000UL, 0x10000000000UL, 0xc2);
> +            break;
> +        case 0x1f2c0000: /* PCIe1 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0d000000000UL, 0x0e000000000UL, 0xc8);
> +            break;
> +        case 0x1f2d0000: /* PCIe2 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x09000000000UL, 0x0a000000000UL, 0xce);
> +            break;
> +        case 0x1f500000: /* PCIe3 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0a000000000UL, 0x0c000000000UL, 0xd4);
> +            break;
> +        case 0x1f510000: /* PCIe4 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0c000000000UL, 0x0d000000000UL, 0xda);
> +            break;
> +
> +        default:
> +            printk("Ignoring unknown PCI bus %s\n", dt_node_full_name(node));
> +            continue;
> +        }
> +
> +        if ( ret < 0 )
> +            return ret;
> +    }
> +
> +    return 0;
> +}
> +
>  static void xgene_storm_reset(void)
>  {
>      void __iomem *addr;
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:26:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:26:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPso-0003PB-KQ; Thu, 20 Nov 2014 11:26:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrPsm-0003P4-UL
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:26:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	77/20-09936-0FFCD645; Thu, 20 Nov 2014 11:26:40 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416482799!14129649!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20110 invoked from network); 20 Nov 2014 11:26:39 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:26:39 -0000
Received: by mail-wg0-f46.google.com with SMTP id x12so3428364wgg.5
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 03:26:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=QpUfON5X3c8cDgSVMEecTl5rSciuBp3b38K7QUL6UY0=;
	b=eGbvD10FRxfKd4JKVDMUG1E0PrhslrKZbNnYadOAZRbNvhquWuNZ63roH4xvLjzIvf
	l13wqW2cwjkA7voMCn4jpzmsPIN8QAIK79rIC6taeQTwn9f11tmnp+/cT8+g2KJ9eTy8
	rb64TsCQaoznPIPC/2sOv5sGUwUcTXQuT4wbJbbYBxi1sfo8OfBNKg7aBGTxFZTi7NWx
	JwuLltY802aWpjj/gOZljx/kW4wb/gx8HIU6t9IJXSmOzhGLTWg/Z6pIWkDyFkYVA2SD
	WEXNlRP9H+BMktbcJCJYHET1CdQ/rrlYYtUJix/VJ7AeSxOHqoftwiPJA1/zYrQ2Cx9X
	ZCHA==
X-Gm-Message-State: ALoCoQkpmWFAmSorwyfDOyuh4kEftNBIdqeD3ksVOe7y+3QGlWPVIA+bNbKvW+4MO6dXrgHoc/u4
X-Received: by 10.180.85.6 with SMTP id d6mr3328438wiz.82.1416482799471;
	Thu, 20 Nov 2014 03:26:39 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fv5sm2918503wjc.37.2014.11.20.03.26.37
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 03:26:38 -0800 (PST)
Message-ID: <546DCFEC.9030200@linaro.org>
Date: Thu, 20 Nov 2014 11:26:36 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Clark Laughlin <clark.laughlin@linaro.org>, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 5/5] xen: arm: Support the other
 4 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/19/2014 03:28 PM, Ian Campbell wrote:
> Currently we only establish specific mappings for pcie0, which is
> used on the Mustang platform. However at least McDivitt uses pcie3.
> So wire up all the others, based on whether the corresponding DT node
> is marked as available.
> 
> This results in no change for Mustang.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: - Didn't constify dt node pointer -- dt_find_compatible_node needs a
>       non-const

Oh right. A bit annoying, I will look at it to see if we can constify
the parameter in Xen 4.6.

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

>     - Print a message when ignoring an unknown bus
>     - Log with dt node full anme instead of CFG space address.
>     - Log at start of xgene_storm_pcie_specific_mapping instead of in the
>       caller after the fact.
> ---
>  xen/arch/arm/platforms/xgene-storm.c |   89 +++++++++++++++++++++++++++++-----
>  1 file changed, 76 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 8c27f24..0b3492d 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -78,35 +78,35 @@ static int map_one_spi(struct domain *d, const char *what,
>      return ret;
>  }
>  
> -/*
> - * Xen does not currently support mapping MMIO regions and interrupt
> - * for bus child devices (referenced via the "ranges" and
> - * "interrupt-map" properties to domain 0). Instead for now map the
> - * necessary resources manually.
> - */
> -static int xgene_storm_specific_mapping(struct domain *d)
> +/* Creates MMIO mappings base..end as well as 4 SPIs from the given base. */
> +static int xgene_storm_pcie_specific_mapping(struct domain *d,
> +                                             const struct dt_device_node *node,
> +                                             paddr_t base, paddr_t end,
> +                                             int base_spi)
>  {
>      int ret;
>  
> +    printk("Mapping additional regions for PCIe device %s\n",
> +           dt_node_full_name(node));
> +
>      /* Map the PCIe bus resources */
> -    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
> -                                        paddr_to_pfn(0x01000000000UL));
> +    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(base), paddr_to_pfn(end));
>      if ( ret )
>          goto err;
>  
> -    ret = map_one_spi(d, "PCI#INTA", 0xc2, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTA", base_spi+0, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>  
> -    ret = map_one_spi(d, "PCI#INTB", 0xc3, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTB", base_spi+1, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>  
> -    ret = map_one_spi(d, "PCI#INTC", 0xc4, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTC", base_spi+2, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>  
> -    ret = map_one_spi(d, "PCI#INTD", 0xc5, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTD", base_spi+3, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>  
> @@ -115,6 +115,69 @@ err:
>      return ret;
>  }
>  
> +/*
> + * Xen does not currently support mapping MMIO regions and interrupt
> + * for bus child devices (referenced via the "ranges" and
> + * "interrupt-map" properties to domain 0). Instead for now map the
> + * necessary resources manually.
> + */
> +static int xgene_storm_specific_mapping(struct domain *d)
> +{
> +    struct dt_device_node *node = NULL;
> +    int ret;
> +
> +    while ( (node = dt_find_compatible_node(node, "pci", "apm,xgene-pcie")) )
> +    {
> +        u64 addr;
> +
> +        /* Identify the bus via it's control register address */
> +        ret = dt_device_get_address(node, 0, &addr, NULL);
> +        if ( ret < 0 )
> +            return ret;
> +
> +        if ( !dt_device_is_available(node) )
> +            continue;
> +
> +       switch ( addr )
> +        {
> +        case 0x1f2b0000: /* PCIe0 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0e000000000UL, 0x10000000000UL, 0xc2);
> +            break;
> +        case 0x1f2c0000: /* PCIe1 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0d000000000UL, 0x0e000000000UL, 0xc8);
> +            break;
> +        case 0x1f2d0000: /* PCIe2 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x09000000000UL, 0x0a000000000UL, 0xce);
> +            break;
> +        case 0x1f500000: /* PCIe3 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0a000000000UL, 0x0c000000000UL, 0xd4);
> +            break;
> +        case 0x1f510000: /* PCIe4 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0c000000000UL, 0x0d000000000UL, 0xda);
> +            break;
> +
> +        default:
> +            printk("Ignoring unknown PCI bus %s\n", dt_node_full_name(node));
> +            continue;
> +        }
> +
> +        if ( ret < 0 )
> +            return ret;
> +    }
> +
> +    return 0;
> +}
> +
>  static void xgene_storm_reset(void)
>  {
>      void __iomem *addr;
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:28:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPu7-0003V7-3G; Thu, 20 Nov 2014 11:28:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XrPu5-0003V2-6A
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:28:01 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	0C/5B-25727-040DD645; Thu, 20 Nov 2014 11:28:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416482879!12723999!1
X-Originating-IP: [81.169.146.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6623 invoked from network); 20 Nov 2014 11:28:00 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 11:28:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416482879; l=2054;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=H4/TslZg0uoRXYjDsyHBFrBaiww=;
	b=jyGzTTc+d9cdqBd1BQYWpmzGp+mtZeZg2Xmg8LvFPdKN9qfPxLtGCTifSgoATopg92b
	g+69qtQcO35Pz6JFj39GtB8sS4N5T6D9/IHME1jfwnaDEM6wbaz2W04x+94thlBwSzEAI
	y7uod1oNwZQJTNupTK0jDsIxYeTZHVQYViY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.12 AUTH) with ESMTPSA id e06a58qAKBRqg0H
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 20 Nov 2014 12:27:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 20A1550172; Thu, 20 Nov 2014 12:27:51 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Thu, 20 Nov 2014 12:27:44 +0100
Message-Id: <1416482864-7824-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH v2] xen: use more fixed strings to build 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>
MIME-Version: 1.0
Content-Type: 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 should be possible to repeatedly build identical sources and get
identical binaries, even on different hosts at different build times.
This fails for xen.gz and xen.efi because current time and buildhost
get included in the binaries.

Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and XEN_BUILD_HOST
which the build environment can set to fixed strings to get a
reproducible build.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---

v2: 
 reword commit message.

 xen/Makefile | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index 72c1313..47f003c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -8,6 +8,9 @@ export XEN_FULLVERSION   = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
 
 export XEN_WHOAMI	?= $(USER)
 export XEN_DOMAIN	?= $(shell ([ -x /bin/dnsdomainname ] && /bin/dnsdomainname) || ([ -x /bin/domainname ] && /bin/domainname || echo [unknown]))
+export XEN_BUILD_DATE	?= $(shell LC_ALL=C date)
+export XEN_BUILD_TIME	?= $(shell LC_ALL=C date +%T)
+export XEN_BUILD_HOST	?= $(shell hostname)
 
 export BASEDIR := $(CURDIR)
 export XEN_ROOT := $(BASEDIR)/..
@@ -126,11 +129,11 @@ delete-unfresh-files:
 
 # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
 include/xen/compile.h: include/xen/compile.h.in .banner
-	@sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
-	    -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
+	@sed -e 's/@@date@@/$(XEN_BUILD_DATE)/g' \
+	    -e 's/@@time@@/$(XEN_BUILD_TIME)/g' \
 	    -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
 	    -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
-	    -e 's/@@hostname@@/$(shell hostname)/g' \
+	    -e 's/@@hostname@@/$(XEN_BUILD_HOST)/g' \
 	    -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
 	    -e 's/@@version@@/$(XEN_VERSION)/g' \
 	    -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:28:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPu7-0003V7-3G; Thu, 20 Nov 2014 11:28:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XrPu5-0003V2-6A
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:28:01 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	0C/5B-25727-040DD645; Thu, 20 Nov 2014 11:28:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416482879!12723999!1
X-Originating-IP: [81.169.146.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6623 invoked from network); 20 Nov 2014 11:28:00 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 11:28:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416482879; l=2054;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=H4/TslZg0uoRXYjDsyHBFrBaiww=;
	b=jyGzTTc+d9cdqBd1BQYWpmzGp+mtZeZg2Xmg8LvFPdKN9qfPxLtGCTifSgoATopg92b
	g+69qtQcO35Pz6JFj39GtB8sS4N5T6D9/IHME1jfwnaDEM6wbaz2W04x+94thlBwSzEAI
	y7uod1oNwZQJTNupTK0jDsIxYeTZHVQYViY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.12 AUTH) with ESMTPSA id e06a58qAKBRqg0H
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 20 Nov 2014 12:27:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 20A1550172; Thu, 20 Nov 2014 12:27:51 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Thu, 20 Nov 2014 12:27:44 +0100
Message-Id: <1416482864-7824-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH v2] xen: use more fixed strings to build 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>
MIME-Version: 1.0
Content-Type: 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 should be possible to repeatedly build identical sources and get
identical binaries, even on different hosts at different build times.
This fails for xen.gz and xen.efi because current time and buildhost
get included in the binaries.

Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and XEN_BUILD_HOST
which the build environment can set to fixed strings to get a
reproducible build.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---

v2: 
 reword commit message.

 xen/Makefile | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index 72c1313..47f003c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -8,6 +8,9 @@ export XEN_FULLVERSION   = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
 
 export XEN_WHOAMI	?= $(USER)
 export XEN_DOMAIN	?= $(shell ([ -x /bin/dnsdomainname ] && /bin/dnsdomainname) || ([ -x /bin/domainname ] && /bin/domainname || echo [unknown]))
+export XEN_BUILD_DATE	?= $(shell LC_ALL=C date)
+export XEN_BUILD_TIME	?= $(shell LC_ALL=C date +%T)
+export XEN_BUILD_HOST	?= $(shell hostname)
 
 export BASEDIR := $(CURDIR)
 export XEN_ROOT := $(BASEDIR)/..
@@ -126,11 +129,11 @@ delete-unfresh-files:
 
 # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
 include/xen/compile.h: include/xen/compile.h.in .banner
-	@sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
-	    -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
+	@sed -e 's/@@date@@/$(XEN_BUILD_DATE)/g' \
+	    -e 's/@@time@@/$(XEN_BUILD_TIME)/g' \
 	    -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
 	    -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
-	    -e 's/@@hostname@@/$(shell hostname)/g' \
+	    -e 's/@@hostname@@/$(XEN_BUILD_HOST)/g' \
 	    -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
 	    -e 's/@@version@@/$(XEN_VERSION)/g' \
 	    -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:31:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:31:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPxn-0003hE-NQ; Thu, 20 Nov 2014 11:31:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPxm-0003gO-0I
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:31:50 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	43/0B-18267-521DD645; Thu, 20 Nov 2014 11:31:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416483108!12683651!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3634 invoked from network); 20 Nov 2014 11:31:48 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 11:31:48 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 12:31:48 +0100
Message-Id: <546DDF34020000780004950D@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 12:31:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Donald D. Dugger" <donald.d.dugger@intel.com>
References: <20141119194611.GA2600@tlaloc.n0ano.com>
In-Reply-To: <20141119194611.GA2600@tlaloc.n0ano.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: eddie.dong@intel.com, will.auld@intel.com, allen.m.kay@intel.com,
	n0ano@n0ano.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V3] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 20:46, <donald.d.dugger@intel.com> wrote:
> @@ -237,6 +248,42 @@
>      }
>  }
>  
> +static void __init parse_snb_timeout(const char *s)
> +{
> +	int not;
> +
> +	switch (*s) {
> +
> +	case '\0':
> +		snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
> +		break;
> +
> +	case '0':	case '1':	case '2':
> +	case '3':	case '4':	case '5':
> +	case '6':	case '7':	case '8':
> +	case '9':
> +		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
> +		if ( snb_igd_timeout == MILLISECS(1) )
> +			snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
> +		break;

Overly complicated. Just parse_bool() first, if that returns negative
check for "default" or "", and (if not matched) invoke strtoul(). No
need for this switch statement.

> +
> +	default:
> +		if ( strncmp("default", s, 7) == 0 ) {
> +			snb_igd_timeout = SNB_IGD_TIMEOUT;
> +			break;
> +		}
> +		not = !strncmp("no-", s, 3);

This makes no sense - you're looking for e.g. "snb_igd_quirk=no-no"
here. If the use specified "no-snb_igd_quirk", you'll end up seeing
"=no" when this function gets entered.

Also the whole function is white space damaged (using hard tabs)
and has misplaced opening braces.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:31:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:31:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrPxn-0003hE-NQ; Thu, 20 Nov 2014 11:31:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrPxm-0003gO-0I
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 11:31:50 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	43/0B-18267-521DD645; Thu, 20 Nov 2014 11:31:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416483108!12683651!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3634 invoked from network); 20 Nov 2014 11:31:48 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 11:31:48 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 12:31:48 +0100
Message-Id: <546DDF34020000780004950D@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 12:31:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Donald D. Dugger" <donald.d.dugger@intel.com>
References: <20141119194611.GA2600@tlaloc.n0ano.com>
In-Reply-To: <20141119194611.GA2600@tlaloc.n0ano.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: eddie.dong@intel.com, will.auld@intel.com, allen.m.kay@intel.com,
	n0ano@n0ano.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V3] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.11.14 at 20:46, <donald.d.dugger@intel.com> wrote:
> @@ -237,6 +248,42 @@
>      }
>  }
>  
> +static void __init parse_snb_timeout(const char *s)
> +{
> +	int not;
> +
> +	switch (*s) {
> +
> +	case '\0':
> +		snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
> +		break;
> +
> +	case '0':	case '1':	case '2':
> +	case '3':	case '4':	case '5':
> +	case '6':	case '7':	case '8':
> +	case '9':
> +		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
> +		if ( snb_igd_timeout == MILLISECS(1) )
> +			snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
> +		break;

Overly complicated. Just parse_bool() first, if that returns negative
check for "default" or "", and (if not matched) invoke strtoul(). No
need for this switch statement.

> +
> +	default:
> +		if ( strncmp("default", s, 7) == 0 ) {
> +			snb_igd_timeout = SNB_IGD_TIMEOUT;
> +			break;
> +		}
> +		not = !strncmp("no-", s, 3);

This makes no sense - you're looking for e.g. "snb_igd_quirk=no-no"
here. If the use specified "no-snb_igd_quirk", you'll end up seeing
"=no" when this function gets entered.

Also the whole function is white space damaged (using hard tabs)
and has misplaced opening braces.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:40:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrQ5d-0003wR-UI; Thu, 20 Nov 2014 11:39:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>)
	id 1XrQ5c-0003wJ-FS; Thu, 20 Nov 2014 11:39:56 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	DC/FE-28296-B03DD645; Thu, 20 Nov 2014 11:39:55 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416483593!12718936!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26820 invoked from network); 20 Nov 2014 11:39:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:39:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193229336"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:39:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrQ5T-0001eO-KS;
	Thu, 20 Nov 2014 11:39:47 +0000
Date: Thu, 20 Nov 2014 11:39:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416474814.29243.59.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Jim Fehlig <jfehlig@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-users@lists.xen.org, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Ian Campbell wrote:
> On Mon, 2014-11-17 at 13:00 +0000, Stefano Stabellini wrote:
> > On Mon, 17 Nov 2014, Ian Campbell wrote:
> > > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > > By the way, how many NICs can I apply to a VM?
> > > > 
> > > > On xen-4.4.0, Using qemu-dm, I can apply 8 NIC to a VM, but using
> > > > qemu-system-i386, I can only apply 4 NICs to an VM?
> > > > is it normal?
> > > 
> > > I've no idea, CCing the qemu maintainers.
> > > 
> > > I'd have expected the number of PV nics to be completely independent of
> > > the device mode, so I suppose you mean emulated NICs?
> > 
> > I can pass 4 emulated NICs maximum, but you can easily reach 8 if you
> > use PV NICs instead. Just pass 'type=pv' like this:
> > 
> > vif=['', '', '', '', 'type=pv', 'type=pv', 'type=pv', 'type=pv']
> > 
> > it is going to create 4 emulated nics and 4 pv nics. The 4 emulated nics
> > also have 4 corresponding pv nics. The emulated nics get disconnected
> > soon after boot by the guest operating system (if it has pv drivers
> > installed, such as Linux). So overall once the boot sequence is fully
> > completed you'll end up with the 8 pv nics that you want.
> 
> I wonder if we should do something in (lib)xl such that by default the
> first 4 NICs have type LIBXL_NIC_TYPE_VIF_IOEMU (i.e. emulated+PV path)
> and the rest have LIBXL_NIC_TYPE_VIF (i.e. PV only).

That looks like a simple and reasonable idea.


> > BTW the reason for the failure seems to be that QEMU runs out of ram
> > (xen: failed to populate ram at 80110000, so
> > xc_domain_populate_physmap_exact failed) allocating roms for the rtl8139
> > (40000 bytes each). Maybe qemu-trad wasn't loading any roms for rtl8139.
> > Interestingly e1000 doesn't need any roms either, so another way around
> > this would be to set 'type=e1000' for all the vifs.
> 
> Or to use the new option in 4.5 to increase the MMIO space (or is that
> not where ROMs end up?)
> 
> Do we need to plumb through qemu's optionrom parameter to allow a)
> limiting the number of NICs which will try to do PXE and b) allow custom
> roms etc?

The libxl solution is the best one for simplicity, besides I don't think
there is such an option for QEMU.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:40:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrQ5d-0003wR-UI; Thu, 20 Nov 2014 11:39:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>)
	id 1XrQ5c-0003wJ-FS; Thu, 20 Nov 2014 11:39:56 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	DC/FE-28296-B03DD645; Thu, 20 Nov 2014 11:39:55 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416483593!12718936!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26820 invoked from network); 20 Nov 2014 11:39:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:39:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193229336"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:39:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrQ5T-0001eO-KS;
	Thu, 20 Nov 2014 11:39:47 +0000
Date: Thu, 20 Nov 2014 11:39:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416474814.29243.59.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Jim Fehlig <jfehlig@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-users@lists.xen.org, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Ian Campbell wrote:
> On Mon, 2014-11-17 at 13:00 +0000, Stefano Stabellini wrote:
> > On Mon, 17 Nov 2014, Ian Campbell wrote:
> > > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > > By the way, how many NICs can I apply to a VM?
> > > > 
> > > > On xen-4.4.0, Using qemu-dm, I can apply 8 NIC to a VM, but using
> > > > qemu-system-i386, I can only apply 4 NICs to an VM?
> > > > is it normal?
> > > 
> > > I've no idea, CCing the qemu maintainers.
> > > 
> > > I'd have expected the number of PV nics to be completely independent of
> > > the device mode, so I suppose you mean emulated NICs?
> > 
> > I can pass 4 emulated NICs maximum, but you can easily reach 8 if you
> > use PV NICs instead. Just pass 'type=pv' like this:
> > 
> > vif=['', '', '', '', 'type=pv', 'type=pv', 'type=pv', 'type=pv']
> > 
> > it is going to create 4 emulated nics and 4 pv nics. The 4 emulated nics
> > also have 4 corresponding pv nics. The emulated nics get disconnected
> > soon after boot by the guest operating system (if it has pv drivers
> > installed, such as Linux). So overall once the boot sequence is fully
> > completed you'll end up with the 8 pv nics that you want.
> 
> I wonder if we should do something in (lib)xl such that by default the
> first 4 NICs have type LIBXL_NIC_TYPE_VIF_IOEMU (i.e. emulated+PV path)
> and the rest have LIBXL_NIC_TYPE_VIF (i.e. PV only).

That looks like a simple and reasonable idea.


> > BTW the reason for the failure seems to be that QEMU runs out of ram
> > (xen: failed to populate ram at 80110000, so
> > xc_domain_populate_physmap_exact failed) allocating roms for the rtl8139
> > (40000 bytes each). Maybe qemu-trad wasn't loading any roms for rtl8139.
> > Interestingly e1000 doesn't need any roms either, so another way around
> > this would be to set 'type=e1000' for all the vifs.
> 
> Or to use the new option in 4.5 to increase the MMIO space (or is that
> not where ROMs end up?)
> 
> Do we need to plumb through qemu's optionrom parameter to allow a)
> limiting the number of NICs which will try to do PXE and b) allow custom
> roms etc?

The libxl solution is the best one for simplicity, besides I don't think
there is such an option for QEMU.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:42:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:42:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrQ7u-00048q-2c; Thu, 20 Nov 2014 11:42:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1XrQ7s-00048V-Ce; Thu, 20 Nov 2014 11:42:16 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	7B/8D-02696-793DD645; Thu, 20 Nov 2014 11:42:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416483733!13721304!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12975 invoked from network); 20 Nov 2014 11:42: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;
	20 Nov 2014 11:42:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194753873"
Message-ID: <1416483731.14429.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Nov 2014 11:42:11 +0000
In-Reply-To: <alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Jim Fehlig <jfehlig@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-users@lists.xen.org, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 11:39 +0000, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 13:00 +0000, Stefano Stabellini wrote:
> > > On Mon, 17 Nov 2014, Ian Campbell wrote:
> > > > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > > > By the way, how many NICs can I apply to a VM?
> > > > > 
> > > > > On xen-4.4.0, Using qemu-dm, I can apply 8 NIC to a VM, but using
> > > > > qemu-system-i386, I can only apply 4 NICs to an VM?
> > > > > is it normal?
> > > > 
> > > > I've no idea, CCing the qemu maintainers.
> > > > 
> > > > I'd have expected the number of PV nics to be completely independent of
> > > > the device mode, so I suppose you mean emulated NICs?
> > > 
> > > I can pass 4 emulated NICs maximum, but you can easily reach 8 if you
> > > use PV NICs instead. Just pass 'type=pv' like this:
> > > 
> > > vif=['', '', '', '', 'type=pv', 'type=pv', 'type=pv', 'type=pv']
> > > 
> > > it is going to create 4 emulated nics and 4 pv nics. The 4 emulated nics
> > > also have 4 corresponding pv nics. The emulated nics get disconnected
> > > soon after boot by the guest operating system (if it has pv drivers
> > > installed, such as Linux). So overall once the boot sequence is fully
> > > completed you'll end up with the 8 pv nics that you want.
> > 
> > I wonder if we should do something in (lib)xl such that by default the
> > first 4 NICs have type LIBXL_NIC_TYPE_VIF_IOEMU (i.e. emulated+PV path)
> > and the rest have LIBXL_NIC_TYPE_VIF (i.e. PV only).
> 
> That looks like a simple and reasonable idea.
> 
> 
> > > BTW the reason for the failure seems to be that QEMU runs out of ram
> > > (xen: failed to populate ram at 80110000, so
> > > xc_domain_populate_physmap_exact failed) allocating roms for the rtl8139
> > > (40000 bytes each). Maybe qemu-trad wasn't loading any roms for rtl8139.
> > > Interestingly e1000 doesn't need any roms either, so another way around
> > > this would be to set 'type=e1000' for all the vifs.
> > 
> > Or to use the new option in 4.5 to increase the MMIO space (or is that
> > not where ROMs end up?)
> > 
> > Do we need to plumb through qemu's optionrom parameter to allow a)
> > limiting the number of NICs which will try to do PXE and b) allow custom
> > roms etc?
> 
> The libxl solution is the best one for simplicity, besides I don't think
> there is such an option for QEMU.

There is, it's the romfile option to -device e.g.
         -device $NICMODEL,vlan=0,romfile=$ROMFILE
        
where NICMODEL is e100, rtl8139, virtio-blah
and ROMFILE is e.g. an ipxe binary.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:42:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:42:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrQ7u-00048q-2c; Thu, 20 Nov 2014 11:42:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1XrQ7s-00048V-Ce; Thu, 20 Nov 2014 11:42:16 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	7B/8D-02696-793DD645; Thu, 20 Nov 2014 11:42:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416483733!13721304!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12975 invoked from network); 20 Nov 2014 11:42: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;
	20 Nov 2014 11:42:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194753873"
Message-ID: <1416483731.14429.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Nov 2014 11:42:11 +0000
In-Reply-To: <alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Jim Fehlig <jfehlig@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-users@lists.xen.org, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 11:39 +0000, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 13:00 +0000, Stefano Stabellini wrote:
> > > On Mon, 17 Nov 2014, Ian Campbell wrote:
> > > > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > > > By the way, how many NICs can I apply to a VM?
> > > > > 
> > > > > On xen-4.4.0, Using qemu-dm, I can apply 8 NIC to a VM, but using
> > > > > qemu-system-i386, I can only apply 4 NICs to an VM?
> > > > > is it normal?
> > > > 
> > > > I've no idea, CCing the qemu maintainers.
> > > > 
> > > > I'd have expected the number of PV nics to be completely independent of
> > > > the device mode, so I suppose you mean emulated NICs?
> > > 
> > > I can pass 4 emulated NICs maximum, but you can easily reach 8 if you
> > > use PV NICs instead. Just pass 'type=pv' like this:
> > > 
> > > vif=['', '', '', '', 'type=pv', 'type=pv', 'type=pv', 'type=pv']
> > > 
> > > it is going to create 4 emulated nics and 4 pv nics. The 4 emulated nics
> > > also have 4 corresponding pv nics. The emulated nics get disconnected
> > > soon after boot by the guest operating system (if it has pv drivers
> > > installed, such as Linux). So overall once the boot sequence is fully
> > > completed you'll end up with the 8 pv nics that you want.
> > 
> > I wonder if we should do something in (lib)xl such that by default the
> > first 4 NICs have type LIBXL_NIC_TYPE_VIF_IOEMU (i.e. emulated+PV path)
> > and the rest have LIBXL_NIC_TYPE_VIF (i.e. PV only).
> 
> That looks like a simple and reasonable idea.
> 
> 
> > > BTW the reason for the failure seems to be that QEMU runs out of ram
> > > (xen: failed to populate ram at 80110000, so
> > > xc_domain_populate_physmap_exact failed) allocating roms for the rtl8139
> > > (40000 bytes each). Maybe qemu-trad wasn't loading any roms for rtl8139.
> > > Interestingly e1000 doesn't need any roms either, so another way around
> > > this would be to set 'type=e1000' for all the vifs.
> > 
> > Or to use the new option in 4.5 to increase the MMIO space (or is that
> > not where ROMs end up?)
> > 
> > Do we need to plumb through qemu's optionrom parameter to allow a)
> > limiting the number of NICs which will try to do PXE and b) allow custom
> > roms etc?
> 
> The libxl solution is the best one for simplicity, besides I don't think
> there is such an option for QEMU.

There is, it's the romfile option to -device e.g.
         -device $NICMODEL,vlan=0,romfile=$ROMFILE
        
where NICMODEL is e100, rtl8139, virtio-blah
and ROMFILE is e.g. an ipxe binary.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:42:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:42:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrQ8F-0004JE-9o; Thu, 20 Nov 2014 11:42:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQ8D-0004IE-Ja
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:42:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4F/24-09842-DA3DD645; Thu, 20 Nov 2014 11:42:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416483755!14066482!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24975 invoked from network); 20 Nov 2014 11:42:36 -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;
	20 Nov 2014 11:42:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193229891"
Message-ID: <546DD3A8.2060404@citrix.com>
Date: Thu, 20 Nov 2014 11:42:32 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
	<1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
	<alpine.DEB.2.02.1411191749110.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411191749110.12596@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4/4] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/14 17:51, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, David Vrabel wrote:
>> 
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +	unsigned long max_mfn;
>> +
>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
> 
> As Jan pointed out, I think you need to change the prototype of
> HYPERVISOR_memory_op to return long. Please do consistently across all
> relevant archs.

This doesn't help since 32-bit guests will still truncate.  A new
hypercall op that returns the result in a uint64_t parameter is required.

There is another reason why max_mfn isn't suitable -- IOMMU usage so I
think we should assume a 64-bit DMA mask is required (this is actually
the change I put into XenServer's kernel).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:42:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:42:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrQ8F-0004JE-9o; Thu, 20 Nov 2014 11:42:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQ8D-0004IE-Ja
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:42:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4F/24-09842-DA3DD645; Thu, 20 Nov 2014 11:42:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416483755!14066482!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24975 invoked from network); 20 Nov 2014 11:42:36 -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;
	20 Nov 2014 11:42:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193229891"
Message-ID: <546DD3A8.2060404@citrix.com>
Date: Thu, 20 Nov 2014 11:42:32 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1416412921-23671-1-git-send-email-david.vrabel@citrix.com>
	<1416412921-23671-5-git-send-email-david.vrabel@citrix.com>
	<alpine.DEB.2.02.1411191749110.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411191749110.12596@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4/4] x86/xen: use the maximum MFN to
 calculate the required DMA mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/11/14 17:51, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, David Vrabel wrote:
>> 
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +	unsigned long max_mfn;
>> +
>> +	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
> 
> As Jan pointed out, I think you need to change the prototype of
> HYPERVISOR_memory_op to return long. Please do consistently across all
> relevant archs.

This doesn't help since 32-bit guests will still truncate.  A new
hypercall op that returns the result in a uint64_t parameter is required.

There is another reason why max_mfn isn't suitable -- IOMMU usage so I
think we should assume a 64-bit DMA mask is required (this is actually
the change I put into XenServer's kernel).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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.xen.org>)
	id 1XrQFx-0004sD-AR; Thu, 20 Nov 2014 11:50:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQFw-0004s5-N0
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:50:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F3/5F-09936-C85DD645; Thu, 20 Nov 2014 11:50:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416484234!14110524!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5407 invoked from network); 20 Nov 2014 11:50:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:50:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193231390"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:50:34 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XrQFt-0001p1-OD;
	Thu, 20 Nov 2014 11:50:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 20 Nov 2014 11:50:22 +0000
Message-ID: <1416484225-28054-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
References: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 1/4] dma: add
	dma_get_required_mask_from_max_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 generic dma_get_required_mask() is useful even for architectures (such
as ia64) that define ARCH_HAS_GET_REQUIRED_MASK.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/base/platform.c     |   10 ++++++++--
 include/linux/dma-mapping.h |    1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b2afc29..f9f3930 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1009,8 +1009,7 @@ int __init platform_bus_init(void)
 	return error;
 }
 
-#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
-u64 dma_get_required_mask(struct device *dev)
+u64 dma_get_required_mask_from_max_pfn(struct device *dev)
 {
 	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
 	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
@@ -1028,6 +1027,13 @@ u64 dma_get_required_mask(struct device *dev)
 	}
 	return mask;
 }
+EXPORT_SYMBOL_GPL(dma_get_required_mask_from_max_pfn);
+
+#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
+u64 dma_get_required_mask(struct device *dev)
+{
+	return dma_get_required_mask_from_max_pfn(dev);
+}
 EXPORT_SYMBOL_GPL(dma_get_required_mask);
 #endif
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d3881..6e2fdfc 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -127,6 +127,7 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
 	return dma_set_mask_and_coherent(dev, mask);
 }
 
+extern u64 dma_get_required_mask_from_max_pfn(struct device *dev);
 extern u64 dma_get_required_mask(struct device *dev);
 
 #ifndef set_arch_dma_coherent_ops
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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.xen.org>)
	id 1XrQFz-0004sl-1U; Thu, 20 Nov 2014 11:50:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQFx-0004sC-QE
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:50:37 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	F3/70-02697-D85DD645; Thu, 20 Nov 2014 11:50:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416484235!12435170!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18679 invoked from network); 20 Nov 2014 11:50:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:50:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194755369"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:50:34 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XrQFt-0001p1-Qy;
	Thu, 20 Nov 2014 11:50:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 20 Nov 2014 11:50:24 +0000
Message-ID: <1416484225-28054-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
References: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 3/4] x86: allow dma_get_required_mask() to be
	overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 dma_ops->get_required_mask() if provided, defaulting to
dma_get_requried_mask_from_max_pfn().

This is needed on systems (such as Xen PV guests) where the DMA
address and the physical address are not equal.

ARCH_HAS_DMA_GET_REQUIRED_MASK is defined in asm/device.h instead of
asm/dma-mapping.h because linux/dma-mapping.h uses the define before
including asm/dma-mapping.h

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/x86/include/asm/device.h |    2 ++
 arch/x86/kernel/pci-dma.c     |    8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
index 03dd729..10bc628 100644
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
 struct pdev_archdata {
 };
 
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
+
 #endif /* _ASM_X86_DEVICE_H */
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index a25e202..5154400 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -140,6 +140,14 @@ void dma_generic_free_coherent(struct device *dev, size_t size, void *vaddr,
 		free_pages((unsigned long)vaddr, get_order(size));
 }
 
+u64 dma_get_required_mask(struct device *dev)
+{
+	if (dma_ops->get_required_mask)
+		return dma_ops->get_required_mask(dev);
+	return dma_get_required_mask_from_max_pfn(dev);
+}
+EXPORT_SYMBOL_GPL(dma_get_required_mask);
+
 /*
  * See <Documentation/x86/x86_64/boot-options.txt> for the iommu kernel
  * parameter documentation.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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.xen.org>)
	id 1XrQFz-0004t9-Oo; Thu, 20 Nov 2014 11:50:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQFy-0004sV-Ud
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:50:39 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	03/7A-31453-D85DD645; Thu, 20 Nov 2014 11:50:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416484235!12435170!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18743 invoked from network); 20 Nov 2014 11:50:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:50:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194755370"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:50:34 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XrQFt-0001p1-Rt;
	Thu, 20 Nov 2014 11:50:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 20 Nov 2014 11:50:25 +0000
Message-ID: <1416484225-28054-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
References: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 4/4] x86/xen: assume a 64-bit DMA mask is
	required
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to
use only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

We could base the DMA mask on the maximum MFN but:

a) The hypercall op to get the maximum MFN (XENMEM_maximum_ram_page)
will truncate the result to an int in 32-bit guests.

b) Future uses of the IOMMU in Xen may map frames at bus addresses
above the end of RAM.

So, just assume a 64-bit DMA mask is always required.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    1 +
 drivers/xen/swiotlb-xen.c      |    9 +++++++++
 include/xen/swiotlb-xen.h      |    4 ++++
 3 files changed, 14 insertions(+)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 0e98e5d..a5d180a 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -31,6 +31,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.map_page = xen_swiotlb_map_page,
 	.unmap_page = xen_swiotlb_unmap_page,
 	.dma_supported = xen_swiotlb_dma_supported,
+	.get_required_mask = xen_swiotlb_get_required_mask,
 };
 
 /*
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..767d048 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -42,9 +42,11 @@
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 #include <xen/hvc-console.h>
+#include <xen/interface/memory.h>
 
 #include <asm/dma-mapping.h>
 #include <asm/xen/page-coherent.h>
+#include <asm/xen/hypercall.h>
 
 #include <trace/events/swiotlb.h>
 /*
@@ -683,3 +685,10 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
+
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+	return DMA_BIT_MASK(64);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 8b2eb93..6408888 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -58,4 +58,8 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
 
 extern int
 xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
+
+extern u64
+xen_swiotlb_get_required_mask(struct device *dev);
+
 #endif /* __LINUX_SWIOTLB_XEN_H */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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.xen.org>)
	id 1XrQFx-0004sD-AR; Thu, 20 Nov 2014 11:50:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQFw-0004s5-N0
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:50:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F3/5F-09936-C85DD645; Thu, 20 Nov 2014 11:50:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416484234!14110524!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5407 invoked from network); 20 Nov 2014 11:50:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:50:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193231390"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:50:34 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XrQFt-0001p1-OD;
	Thu, 20 Nov 2014 11:50:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 20 Nov 2014 11:50:22 +0000
Message-ID: <1416484225-28054-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
References: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 1/4] dma: add
	dma_get_required_mask_from_max_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 generic dma_get_required_mask() is useful even for architectures (such
as ia64) that define ARCH_HAS_GET_REQUIRED_MASK.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/base/platform.c     |   10 ++++++++--
 include/linux/dma-mapping.h |    1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b2afc29..f9f3930 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1009,8 +1009,7 @@ int __init platform_bus_init(void)
 	return error;
 }
 
-#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
-u64 dma_get_required_mask(struct device *dev)
+u64 dma_get_required_mask_from_max_pfn(struct device *dev)
 {
 	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
 	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
@@ -1028,6 +1027,13 @@ u64 dma_get_required_mask(struct device *dev)
 	}
 	return mask;
 }
+EXPORT_SYMBOL_GPL(dma_get_required_mask_from_max_pfn);
+
+#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
+u64 dma_get_required_mask(struct device *dev)
+{
+	return dma_get_required_mask_from_max_pfn(dev);
+}
 EXPORT_SYMBOL_GPL(dma_get_required_mask);
 #endif
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d3881..6e2fdfc 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -127,6 +127,7 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
 	return dma_set_mask_and_coherent(dev, mask);
 }
 
+extern u64 dma_get_required_mask_from_max_pfn(struct device *dev);
 extern u64 dma_get_required_mask(struct device *dev);
 
 #ifndef set_arch_dma_coherent_ops
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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.xen.org>)
	id 1XrQFy-0004sc-Mg; Thu, 20 Nov 2014 11:50:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQFx-0004sA-AU
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:50:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FD/94-09842-C85DD645; Thu, 20 Nov 2014 11:50:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416484234!14110524!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5507 invoked from network); 20 Nov 2014 11:50:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:50:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193231391"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:50:34 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XrQFt-0001p1-P2;
	Thu, 20 Nov 2014 11:50:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 20 Nov 2014 11:50:23 +0000
Message-ID: <1416484225-28054-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
References: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Fenghua Yu <fenghua.yu@intel.com>, Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 2/4] ia64: use common
	dma_get_required_mask_from_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
---
 arch/ia64/include/asm/machvec.h      |    2 +-
 arch/ia64/include/asm/machvec_init.h |    1 -
 arch/ia64/pci/pci.c                  |   20 --------------------
 3 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
index 9c39bdf..beaa47d 100644
--- a/arch/ia64/include/asm/machvec.h
+++ b/arch/ia64/include/asm/machvec.h
@@ -287,7 +287,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
 # define platform_dma_get_ops		dma_get_ops
 #endif
 #ifndef platform_dma_get_required_mask
-# define  platform_dma_get_required_mask	ia64_dma_get_required_mask
+# define  platform_dma_get_required_mask	dma_get_required_mask_from_max_pfn
 #endif
 #ifndef platform_irq_to_vector
 # define platform_irq_to_vector		__ia64_irq_to_vector
diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
index 37a4698..ef964b2 100644
--- a/arch/ia64/include/asm/machvec_init.h
+++ b/arch/ia64/include/asm/machvec_init.h
@@ -3,7 +3,6 @@
 
 extern ia64_mv_send_ipi_t ia64_send_ipi;
 extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
-extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
 extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
 extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
 extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 291a582..79da21b 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -791,26 +791,6 @@ static void __init set_pci_dfl_cacheline_size(void)
 	pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
 }
 
-u64 ia64_dma_get_required_mask(struct device *dev)
-{
-	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
-	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
-	u64 mask;
-
-	if (!high_totalram) {
-		/* convert to mask just covering totalram */
-		low_totalram = (1 << (fls(low_totalram) - 1));
-		low_totalram += low_totalram - 1;
-		mask = low_totalram;
-	} else {
-		high_totalram = (1 << (fls(high_totalram) - 1));
-		high_totalram += high_totalram - 1;
-		mask = (((u64)high_totalram) << 32) + 0xffffffff;
-	}
-	return mask;
-}
-EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
-
 u64 dma_get_required_mask(struct device *dev)
 {
 	return platform_dma_get_required_mask(dev);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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.xen.org>)
	id 1XrQFz-0004sz-Cs; Thu, 20 Nov 2014 11:50:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQFy-0004sM-08
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:50:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	44/7F-25276-D85DD645; Thu, 20 Nov 2014 11:50:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416484234!14110524!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5609 invoked from network); 20 Nov 2014 11:50:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:50:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193231392"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:50:34 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XrQFt-0001p1-NY;
	Thu, 20 Nov 2014 11:50:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 20 Nov 2014 11:50:21 +0000
Message-ID: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCHv4 0/4]: dma, x86,
	xen: reduce SWIOTLB usage in Xen guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On systems where DMA addresses and physical addresses are not 1:1
(such as Xen PV guests), the generic dma_get_required_mask() will not
return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to use
only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

This series allows Xen PV guests to override the default
dma_get_required_mask() with one that calculates the DMA mask from the
maximum MFN (and not the PFN).

Changes in v4:
- Assume 64-bit mask is required.

Changes in v3:
- fix off-by-one in xen_dma_get_required_mask()
- split ia64 changes into separate patch.

Changes in v2:
- split x86 and xen changes into separate patches

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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.xen.org>)
	id 1XrQFz-0004t9-Oo; Thu, 20 Nov 2014 11:50:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQFy-0004sV-Ud
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:50:39 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	03/7A-31453-D85DD645; Thu, 20 Nov 2014 11:50:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416484235!12435170!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18743 invoked from network); 20 Nov 2014 11:50:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:50:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194755370"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:50:34 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XrQFt-0001p1-Rt;
	Thu, 20 Nov 2014 11:50:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 20 Nov 2014 11:50:25 +0000
Message-ID: <1416484225-28054-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
References: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 4/4] x86/xen: assume a 64-bit DMA mask is
	required
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to
use only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

We could base the DMA mask on the maximum MFN but:

a) The hypercall op to get the maximum MFN (XENMEM_maximum_ram_page)
will truncate the result to an int in 32-bit guests.

b) Future uses of the IOMMU in Xen may map frames at bus addresses
above the end of RAM.

So, just assume a 64-bit DMA mask is always required.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    1 +
 drivers/xen/swiotlb-xen.c      |    9 +++++++++
 include/xen/swiotlb-xen.h      |    4 ++++
 3 files changed, 14 insertions(+)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 0e98e5d..a5d180a 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -31,6 +31,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.map_page = xen_swiotlb_map_page,
 	.unmap_page = xen_swiotlb_unmap_page,
 	.dma_supported = xen_swiotlb_dma_supported,
+	.get_required_mask = xen_swiotlb_get_required_mask,
 };
 
 /*
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..767d048 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -42,9 +42,11 @@
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 #include <xen/hvc-console.h>
+#include <xen/interface/memory.h>
 
 #include <asm/dma-mapping.h>
 #include <asm/xen/page-coherent.h>
+#include <asm/xen/hypercall.h>
 
 #include <trace/events/swiotlb.h>
 /*
@@ -683,3 +685,10 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
+
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+	return DMA_BIT_MASK(64);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 8b2eb93..6408888 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -58,4 +58,8 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
 
 extern int
 xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
+
+extern u64
+xen_swiotlb_get_required_mask(struct device *dev);
+
 #endif /* __LINUX_SWIOTLB_XEN_H */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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.xen.org>)
	id 1XrQFz-0004sl-1U; Thu, 20 Nov 2014 11:50:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQFx-0004sC-QE
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:50:37 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	F3/70-02697-D85DD645; Thu, 20 Nov 2014 11:50:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416484235!12435170!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18679 invoked from network); 20 Nov 2014 11:50:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:50:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="194755369"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:50:34 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XrQFt-0001p1-Qy;
	Thu, 20 Nov 2014 11:50:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 20 Nov 2014 11:50:24 +0000
Message-ID: <1416484225-28054-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
References: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 3/4] x86: allow dma_get_required_mask() to be
	overridden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 dma_ops->get_required_mask() if provided, defaulting to
dma_get_requried_mask_from_max_pfn().

This is needed on systems (such as Xen PV guests) where the DMA
address and the physical address are not equal.

ARCH_HAS_DMA_GET_REQUIRED_MASK is defined in asm/device.h instead of
asm/dma-mapping.h because linux/dma-mapping.h uses the define before
including asm/dma-mapping.h

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/x86/include/asm/device.h |    2 ++
 arch/x86/kernel/pci-dma.c     |    8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
index 03dd729..10bc628 100644
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
 struct pdev_archdata {
 };
 
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
+
 #endif /* _ASM_X86_DEVICE_H */
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index a25e202..5154400 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -140,6 +140,14 @@ void dma_generic_free_coherent(struct device *dev, size_t size, void *vaddr,
 		free_pages((unsigned long)vaddr, get_order(size));
 }
 
+u64 dma_get_required_mask(struct device *dev)
+{
+	if (dma_ops->get_required_mask)
+		return dma_ops->get_required_mask(dev);
+	return dma_get_required_mask_from_max_pfn(dev);
+}
+EXPORT_SYMBOL_GPL(dma_get_required_mask);
+
 /*
  * See <Documentation/x86/x86_64/boot-options.txt> for the iommu kernel
  * parameter documentation.
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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.xen.org>)
	id 1XrQFy-0004sc-Mg; Thu, 20 Nov 2014 11:50:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQFx-0004sA-AU
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:50:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FD/94-09842-C85DD645; Thu, 20 Nov 2014 11:50:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416484234!14110524!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5507 invoked from network); 20 Nov 2014 11:50:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:50:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193231391"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:50:34 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XrQFt-0001p1-P2;
	Thu, 20 Nov 2014 11:50:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 20 Nov 2014 11:50:23 +0000
Message-ID: <1416484225-28054-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
References: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Fenghua Yu <fenghua.yu@intel.com>, Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCH 2/4] ia64: use common
	dma_get_required_mask_from_pfn()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
---
 arch/ia64/include/asm/machvec.h      |    2 +-
 arch/ia64/include/asm/machvec_init.h |    1 -
 arch/ia64/pci/pci.c                  |   20 --------------------
 3 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
index 9c39bdf..beaa47d 100644
--- a/arch/ia64/include/asm/machvec.h
+++ b/arch/ia64/include/asm/machvec.h
@@ -287,7 +287,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
 # define platform_dma_get_ops		dma_get_ops
 #endif
 #ifndef platform_dma_get_required_mask
-# define  platform_dma_get_required_mask	ia64_dma_get_required_mask
+# define  platform_dma_get_required_mask	dma_get_required_mask_from_max_pfn
 #endif
 #ifndef platform_irq_to_vector
 # define platform_irq_to_vector		__ia64_irq_to_vector
diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
index 37a4698..ef964b2 100644
--- a/arch/ia64/include/asm/machvec_init.h
+++ b/arch/ia64/include/asm/machvec_init.h
@@ -3,7 +3,6 @@
 
 extern ia64_mv_send_ipi_t ia64_send_ipi;
 extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
-extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
 extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
 extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
 extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 291a582..79da21b 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -791,26 +791,6 @@ static void __init set_pci_dfl_cacheline_size(void)
 	pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
 }
 
-u64 ia64_dma_get_required_mask(struct device *dev)
-{
-	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
-	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
-	u64 mask;
-
-	if (!high_totalram) {
-		/* convert to mask just covering totalram */
-		low_totalram = (1 << (fls(low_totalram) - 1));
-		low_totalram += low_totalram - 1;
-		mask = low_totalram;
-	} else {
-		high_totalram = (1 << (fls(high_totalram) - 1));
-		high_totalram += high_totalram - 1;
-		mask = (((u64)high_totalram) << 32) + 0xffffffff;
-	}
-	return mask;
-}
-EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
-
 u64 dma_get_required_mask(struct device *dev)
 {
 	return platform_dma_get_required_mask(dev);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11: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.xen.org>)
	id 1XrQFz-0004sz-Cs; Thu, 20 Nov 2014 11:50:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrQFy-0004sM-08
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:50:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	44/7F-25276-D85DD645; Thu, 20 Nov 2014 11:50:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416484234!14110524!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5609 invoked from network); 20 Nov 2014 11:50:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:50:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193231392"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:50:34 -0500
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1XrQFt-0001p1-NY;
	Thu, 20 Nov 2014 11:50:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 20 Nov 2014 11:50:21 +0000
Message-ID: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] [PATCHv4 0/4]: dma, x86,
	xen: reduce SWIOTLB usage in Xen guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On systems where DMA addresses and physical addresses are not 1:1
(such as Xen PV guests), the generic dma_get_required_mask() will not
return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to use
only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

This series allows Xen PV guests to override the default
dma_get_required_mask() with one that calculates the DMA mask from the
maximum MFN (and not the PFN).

Changes in v4:
- Assume 64-bit mask is required.

Changes in v3:
- fix off-by-one in xen_dma_get_required_mask()
- split ia64 changes into separate patch.

Changes in v2:
- split x86 and xen changes into separate patches

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:51:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:51:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrQGl-0005A2-6h; Thu, 20 Nov 2014 11:51:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrQGk-00059n-CY
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:51:26 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	92/BC-02696-DB5DD645; Thu, 20 Nov 2014 11:51:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416484283!13729006!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31678 invoked from network); 20 Nov 2014 11:51:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:51:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193231502"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:51:23 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrQGg-0001px-Oq;
	Thu, 20 Nov 2014 11:51:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrQGg-0001Y8-Dx;
	Thu, 20 Nov 2014 11:51:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21613.54714.243767.604758@mariner.uk.xensource.com>
Date: Thu, 20 Nov 2014 11:51:22 +0000
To: Lars Kurth <lars.kurth.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <8CD9998A-A30A-4B60-986E-BEDDCD223517@gmail.com>
References: <8CD9998A-A30A-4B60-986E-BEDDCD223517@gmail.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [Vote] Confirm Konrad Rzeszutek Wilk as Xen
	project	Hypervisor Committer (please vote by Nov 30th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lars Kurth writes ("[Xen-devel] [Vote] Confirm Konrad Rzeszutek Wilk as Xen project Hypervisor Committer (please vote by Nov 30th)"):
> The voting form is at https://docs.google.com/forms/d/
> 1Hpoda2VjdMMGDsz1zh01tkHPR1vUsVeUVAR0DWhlgik/viewform but if you want to vote
> in public feel free to just reply to this thread. 

I have (obviously) voted yes, with your form.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:51:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:51:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrQGl-0005A2-6h; Thu, 20 Nov 2014 11:51:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrQGk-00059n-CY
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:51:26 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	92/BC-02696-DB5DD645; Thu, 20 Nov 2014 11:51:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416484283!13729006!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31678 invoked from network); 20 Nov 2014 11:51:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 11:51:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,423,1413244800"; d="scan'208";a="193231502"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 06:51:23 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrQGg-0001px-Oq;
	Thu, 20 Nov 2014 11:51:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrQGg-0001Y8-Dx;
	Thu, 20 Nov 2014 11:51:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21613.54714.243767.604758@mariner.uk.xensource.com>
Date: Thu, 20 Nov 2014 11:51:22 +0000
To: Lars Kurth <lars.kurth.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <8CD9998A-A30A-4B60-986E-BEDDCD223517@gmail.com>
References: <8CD9998A-A30A-4B60-986E-BEDDCD223517@gmail.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [Vote] Confirm Konrad Rzeszutek Wilk as Xen
	project	Hypervisor Committer (please vote by Nov 30th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lars Kurth writes ("[Xen-devel] [Vote] Confirm Konrad Rzeszutek Wilk as Xen project Hypervisor Committer (please vote by Nov 30th)"):
> The voting form is at https://docs.google.com/forms/d/
> 1Hpoda2VjdMMGDsz1zh01tkHPR1vUsVeUVAR0DWhlgik/viewform but if you want to vote
> in public feel free to just reply to this thread. 

I have (obviously) voted yes, with your form.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:52:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:52:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrQHQ-0005RJ-MG; Thu, 20 Nov 2014 11:52:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XrQHP-0005Qj-Du
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:52:07 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	1E/2D-02953-6E5DD645; Thu, 20 Nov 2014 11:52:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416484317!13162712!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	RCVD_ILLEGAL_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDQwMTQgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3971 invoked from network); 20 Nov 2014 11:51:57 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 11:51:57 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XrQH1-000PlC-UR; Thu, 20 Nov 2014 11:51:43 +0000
Date: Thu, 20 Nov 2014 12:51:43 +0100
From: Tim Deegan <tim@xen.org>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Message-ID: <20141120115143.GA91131@deinos.phlegethon.org>
References: <8CD9998A-A30A-4B60-986E-BEDDCD223517@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8CD9998A-A30A-4B60-986E-BEDDCD223517@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [Vote] Confirm Konrad Rzeszutek Wilk as Xen project
 Hypervisor Committer (please vote by Nov 30th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:26 +0000 on 17 Nov (1416237976), Lars Kurth wrote:
> last week Ian Jackson nominated Konrad as Xen Project Hypervisor committer.
> 
> Our governance process requires a formal vote by existing committers
> to confirm Konrad and for me to set up a voting form. Existing
> committers are: Keir Fraser, Ian Campbell, Ian Jackson, Jan Beulich
> and Tim Deegan. Others are welcome to voice support.

+1.  An excellent idea.

Tim.

> 
> The voting form is at https://docs.google.com/forms/d/1Hpoda2VjdMMGDsz1zh01tkHPR1vUsVeUVAR0DWhlgik/viewform but if you want to vote in public feel free to just reply to this thread. 
> 
> Best Regards
> Lars

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 11:52:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 11:52:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrQHQ-0005RJ-MG; Thu, 20 Nov 2014 11:52:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XrQHP-0005Qj-Du
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 11:52:07 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	1E/2D-02953-6E5DD645; Thu, 20 Nov 2014 11:52:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416484317!13162712!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	RCVD_ILLEGAL_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDQwMTQgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3971 invoked from network); 20 Nov 2014 11:51:57 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 11:51:57 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XrQH1-000PlC-UR; Thu, 20 Nov 2014 11:51:43 +0000
Date: Thu, 20 Nov 2014 12:51:43 +0100
From: Tim Deegan <tim@xen.org>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Message-ID: <20141120115143.GA91131@deinos.phlegethon.org>
References: <8CD9998A-A30A-4B60-986E-BEDDCD223517@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8CD9998A-A30A-4B60-986E-BEDDCD223517@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [Vote] Confirm Konrad Rzeszutek Wilk as Xen project
 Hypervisor Committer (please vote by Nov 30th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:26 +0000 on 17 Nov (1416237976), Lars Kurth wrote:
> last week Ian Jackson nominated Konrad as Xen Project Hypervisor committer.
> 
> Our governance process requires a formal vote by existing committers
> to confirm Konrad and for me to set up a voting form. Existing
> committers are: Keir Fraser, Ian Campbell, Ian Jackson, Jan Beulich
> and Tim Deegan. Others are welcome to voice support.

+1.  An excellent idea.

Tim.

> 
> The voting form is at https://docs.google.com/forms/d/1Hpoda2VjdMMGDsz1zh01tkHPR1vUsVeUVAR0DWhlgik/viewform but if you want to vote in public feel free to just reply to this thread. 
> 
> Best Regards
> Lars

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 13:02:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 13:02:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrRNT-0006rz-JB; Thu, 20 Nov 2014 13:02:27 +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 1XrRNS-0006ru-VP
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 13:02:27 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	62/7A-02559-1F1DD645; Thu, 20 Nov 2014 11:35:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416483312!13730627!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31605 invoked from network); 20 Nov 2014 11:35:12 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 11:35:12 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XrQ0o-000PUu-7S; Thu, 20 Nov 2014 11:34:58 +0000
Date: Thu, 20 Nov 2014 12:34:58 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141120113458.GC91061@deinos.phlegethon.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546DCCC202000078000493F8@smtp.nue.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:13 +0100 on 20 Nov (1416478386), Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
> exit occurred in guest kernel mode") to further cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

This seems like a good idea in general, but I'm not sure it's
appropriate for _all_ of these.  Unhandled exit types and 
overlong instruction decode seem obviously good. 

hvm_hap_nested_page_fault() returns 0: seems only to happen for pvh
guests that write to read-only memory (?).  That seems like a
different class of failure.  I don't think our response should be
different based on the privilege level here, although domain_crash()
does seem harsh.  (I presume this is to avoid emulating an instruction
in PVH mode?)  If we're changing this, I think it should be to #GP
rather than #UD.

p2m_pt_handle_deferred_changes() returns < 0: AFAICS this is basically
ENOMEM when trying to update p2m tables.  It's so unlikely to be
caused by userspace activity that disguising it with #UD is probably
just unhelpful.  It turns a clean failure into an undebuggable
intermittent glitch.

bad vm entry: Here we're basically looking at a Xen bug that we're
just trying to contain the damage on.  I guess maybe if the guest user
can trigger it it's nice to give the kernel a chance.  And at least it
comes with a loud console message, so I'm OK with it. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 13:02:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 13:02:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrRNT-0006rz-JB; Thu, 20 Nov 2014 13:02:27 +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 1XrRNS-0006ru-VP
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 13:02:27 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	62/7A-02559-1F1DD645; Thu, 20 Nov 2014 11:35:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416483312!13730627!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31605 invoked from network); 20 Nov 2014 11:35:12 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 11:35:12 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XrQ0o-000PUu-7S; Thu, 20 Nov 2014 11:34:58 +0000
Date: Thu, 20 Nov 2014 12:34:58 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141120113458.GC91061@deinos.phlegethon.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546DCCC202000078000493F8@smtp.nue.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:13 +0100 on 20 Nov (1416478386), Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
> exit occurred in guest kernel mode") to further cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

This seems like a good idea in general, but I'm not sure it's
appropriate for _all_ of these.  Unhandled exit types and 
overlong instruction decode seem obviously good. 

hvm_hap_nested_page_fault() returns 0: seems only to happen for pvh
guests that write to read-only memory (?).  That seems like a
different class of failure.  I don't think our response should be
different based on the privilege level here, although domain_crash()
does seem harsh.  (I presume this is to avoid emulating an instruction
in PVH mode?)  If we're changing this, I think it should be to #GP
rather than #UD.

p2m_pt_handle_deferred_changes() returns < 0: AFAICS this is basically
ENOMEM when trying to update p2m tables.  It's so unlikely to be
caused by userspace activity that disguising it with #UD is probably
just unhelpful.  It turns a clean failure into an undebuggable
intermittent glitch.

bad vm entry: Here we're basically looking at a Xen bug that we're
just trying to contain the damage on.  I guess maybe if the guest user
can trigger it it's nice to give the kernel a chance.  And at least it
comes with a loud console message, so I'm OK with it. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 13:11:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 13:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrRWU-00070i-Ih; Thu, 20 Nov 2014 13:11:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrRWT-00070X-MQ
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 13:11:45 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	24/BE-07724-098ED645; Thu, 20 Nov 2014 13:11:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416489104!8981891!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24863 invoked from network); 20 Nov 2014 13:11:44 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 13:11:44 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 14:11:43 +0100
Message-Id: <546DF69E0200007800049579@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 14:11:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
	<20141120113458.GC91061@deinos.phlegethon.org>
In-Reply-To: <20141120113458.GC91061@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.11.14 at 12:34, <tim@xen.org> wrote:
> At 11:13 +0100 on 20 Nov (1416478386), Jan Beulich wrote:
>> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
>> exit occurred in guest kernel mode") to further cases, including the
>> failed VM entry one that XSA-110 was needed to be issued for.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> This seems like a good idea in general, but I'm not sure it's
> appropriate for _all_ of these.  Unhandled exit types and 
> overlong instruction decode seem obviously good. 
> 
> hvm_hap_nested_page_fault() returns 0: seems only to happen for pvh
> guests that write to read-only memory (?).  That seems like a
> different class of failure.  I don't think our response should be
> different based on the privilege level here, although domain_crash()
> does seem harsh.  (I presume this is to avoid emulating an instruction
> in PVH mode?)  If we're changing this, I think it should be to #GP
> rather than #UD.

I dropped those for now. We should re-evaluate this once we
have #VE support on VMX (i.e. we may want to inject that one
there instead).

> p2m_pt_handle_deferred_changes() returns < 0: AFAICS this is basically
> ENOMEM when trying to update p2m tables.  It's so unlikely to be
> caused by userspace activity that disguising it with #UD is probably
> just unhelpful.  It turns a clean failure into an undebuggable
> intermittent glitch.

Dropped too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 13:11:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 13:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrRWU-00070i-Ih; Thu, 20 Nov 2014 13:11:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrRWT-00070X-MQ
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 13:11:45 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	24/BE-07724-098ED645; Thu, 20 Nov 2014 13:11:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416489104!8981891!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24863 invoked from network); 20 Nov 2014 13:11:44 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 13:11:44 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 14:11:43 +0100
Message-Id: <546DF69E0200007800049579@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 14:11:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
	<20141120113458.GC91061@deinos.phlegethon.org>
In-Reply-To: <20141120113458.GC91061@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.11.14 at 12:34, <tim@xen.org> wrote:
> At 11:13 +0100 on 20 Nov (1416478386), Jan Beulich wrote:
>> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
>> exit occurred in guest kernel mode") to further cases, including the
>> failed VM entry one that XSA-110 was needed to be issued for.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> This seems like a good idea in general, but I'm not sure it's
> appropriate for _all_ of these.  Unhandled exit types and 
> overlong instruction decode seem obviously good. 
> 
> hvm_hap_nested_page_fault() returns 0: seems only to happen for pvh
> guests that write to read-only memory (?).  That seems like a
> different class of failure.  I don't think our response should be
> different based on the privilege level here, although domain_crash()
> does seem harsh.  (I presume this is to avoid emulating an instruction
> in PVH mode?)  If we're changing this, I think it should be to #GP
> rather than #UD.

I dropped those for now. We should re-evaluate this once we
have #VE support on VMX (i.e. we may want to inject that one
there instead).

> p2m_pt_handle_deferred_changes() returns < 0: AFAICS this is basically
> ENOMEM when trying to update p2m tables.  It's so unlikely to be
> caused by userspace activity that disguising it with #UD is probably
> just unhelpful.  It turns a clean failure into an undebuggable
> intermittent glitch.

Dropped too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 13:51:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 13:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrS8s-0007eL-6L; Thu, 20 Nov 2014 13:51:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrS8r-0007eG-L8
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 13:51:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D7/F1-25276-DD1FD645; Thu, 20 Nov 2014 13:51:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416491483!13829599!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8949 invoked from network); 20 Nov 2014 13:51:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 13:51:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194789458"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 08:51:22 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrS8i-0003e6-Qe;
	Thu, 20 Nov 2014 13:51:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrS8i-0001qk-Cg;
	Thu, 20 Nov 2014 13:51:16 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 20 Nov 2014 13:51:15 +0000
Message-ID: <1416491475-7078-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH] linux-next tests: Use correct branch
	for baseline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 cr-daily-branch honour an environment or setting variable
EXTRA_SGR_ARGS.  In branch-settings.linux-next set it appropriately to
arrange that the linux-next test reports consider linux-linus tests as
interesting as well as just linux-next ones.

(We already use a flight from linux-linus for selecting the baseline
linux version.)

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 branch-settings.linux-next |    1 +
 cr-daily-branch            |    2 ++
 2 files changed, 3 insertions(+)

diff --git a/branch-settings.linux-next b/branch-settings.linux-next
index e9bf926..1c5660b 100644
--- a/branch-settings.linux-next
+++ b/branch-settings.linux-next
@@ -2,3 +2,4 @@ OSSTEST_NO_BASELINE=y
 OSSTEST_PUSH=false
 OLD_REVISION=determine-late
 GITFORCEFLAG=--fail
+EXTRA_SGR_ARGS=--branches-also=linux-linus
diff --git a/cr-daily-branch b/cr-daily-branch
index d00ecbb..17bb2c9 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -301,6 +301,8 @@ END
         ;;
 esac
 
+sgr_args+=" $EXTRA_SGR_ARGS"
+
 : $flight $branch $OSSTEST_BLESSING $sgr_args
 $DAILY_BRANCH_PREEXEC_HOOK
 execute_flight $flight $OSSTEST_BLESSING
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 13:51:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 13:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrS8s-0007eL-6L; Thu, 20 Nov 2014 13:51:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrS8r-0007eG-L8
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 13:51:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D7/F1-25276-DD1FD645; Thu, 20 Nov 2014 13:51:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416491483!13829599!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8949 invoked from network); 20 Nov 2014 13:51:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 13:51:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194789458"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 08:51:22 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrS8i-0003e6-Qe;
	Thu, 20 Nov 2014 13:51:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrS8i-0001qk-Cg;
	Thu, 20 Nov 2014 13:51:16 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 20 Nov 2014 13:51:15 +0000
Message-ID: <1416491475-7078-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH] linux-next tests: Use correct branch
	for baseline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 cr-daily-branch honour an environment or setting variable
EXTRA_SGR_ARGS.  In branch-settings.linux-next set it appropriately to
arrange that the linux-next test reports consider linux-linus tests as
interesting as well as just linux-next ones.

(We already use a flight from linux-linus for selecting the baseline
linux version.)

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 branch-settings.linux-next |    1 +
 cr-daily-branch            |    2 ++
 2 files changed, 3 insertions(+)

diff --git a/branch-settings.linux-next b/branch-settings.linux-next
index e9bf926..1c5660b 100644
--- a/branch-settings.linux-next
+++ b/branch-settings.linux-next
@@ -2,3 +2,4 @@ OSSTEST_NO_BASELINE=y
 OSSTEST_PUSH=false
 OLD_REVISION=determine-late
 GITFORCEFLAG=--fail
+EXTRA_SGR_ARGS=--branches-also=linux-linus
diff --git a/cr-daily-branch b/cr-daily-branch
index d00ecbb..17bb2c9 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -301,6 +301,8 @@ END
         ;;
 esac
 
+sgr_args+=" $EXTRA_SGR_ARGS"
+
 : $flight $branch $OSSTEST_BLESSING $sgr_args
 $DAILY_BRANCH_PREEXEC_HOOK
 execute_flight $flight $OSSTEST_BLESSING
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 13:52:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 13: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 1XrSA2-0007p9-Mr; Thu, 20 Nov 2014 13:52:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrSA1-0007ou-JO
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 13:52:37 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	C4/07-18267-422FD645; Thu, 20 Nov 2014 13:52:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416491554!12766874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18508 invoked from network); 20 Nov 2014 13:52:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 13:52:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194789859"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 20 Nov 2014 08:52:33 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrS9x-0001I1-Bs;
	Thu, 20 Nov 2014 13:52:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrS9x-0008GO-5m;
	Thu, 20 Nov 2014 13:52:33 +0000
Date: Thu, 20 Nov 2014 13:52:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31688-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31688: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31688 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31688/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   5 xen-build                 fail REGR. vs. 31647

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-amd64-pair         1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a

version targeted for testing:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a
baseline version:
 qemuu                0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51

------------------------------------------------------------
People who touched revisions under test:
  Don Slutz <dslutz@verizon.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          blocked 
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         blocked 
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-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-i386-freebsd10-i386                               blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           blocked 
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 a230ec3101ddda868252c036ea960af2b2d6cd5a
Author: Don Slutz <dslutz@verizon.com>
Date:   Mon Nov 17 16:20:39 2014 -0500

    hw/ide/core.c: Prevent SIGSEGV during migration
    
    The other callers to blk_set_enable_write_cache() in this file
    already check for s->blk == NULL.
    
    upstream-commit-id: 6b896ab261942f441a16836e3fa3c83f3f4488b9
    
    Signed-off-by: Don Slutz <dslutz@verizon.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Message-id: 1416259239-13281-1-git-send-email-dslutz@verizon.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    
    Conflicts:
    	hw/ide/core.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 13:52:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 13: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 1XrSA2-0007p9-Mr; Thu, 20 Nov 2014 13:52:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrSA1-0007ou-JO
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 13:52:37 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	C4/07-18267-422FD645; Thu, 20 Nov 2014 13:52:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416491554!12766874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18508 invoked from network); 20 Nov 2014 13:52:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 13:52:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194789859"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 20 Nov 2014 08:52:33 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrS9x-0001I1-Bs;
	Thu, 20 Nov 2014 13:52:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrS9x-0008GO-5m;
	Thu, 20 Nov 2014 13:52:33 +0000
Date: Thu, 20 Nov 2014 13:52:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31688-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31688: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31688 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31688/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   5 xen-build                 fail REGR. vs. 31647

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-amd64-pair         1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a

version targeted for testing:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a
baseline version:
 qemuu                0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51

------------------------------------------------------------
People who touched revisions under test:
  Don Slutz <dslutz@verizon.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          blocked 
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         blocked 
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-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-i386-freebsd10-i386                               blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           blocked 
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 a230ec3101ddda868252c036ea960af2b2d6cd5a
Author: Don Slutz <dslutz@verizon.com>
Date:   Mon Nov 17 16:20:39 2014 -0500

    hw/ide/core.c: Prevent SIGSEGV during migration
    
    The other callers to blk_set_enable_write_cache() in this file
    already check for s->blk == NULL.
    
    upstream-commit-id: 6b896ab261942f441a16836e3fa3c83f3f4488b9
    
    Signed-off-by: Don Slutz <dslutz@verizon.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Message-id: 1416259239-13281-1-git-send-email-dslutz@verizon.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    
    Conflicts:
    	hw/ide/core.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:08:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:08:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrSOd-0008ET-DC; Thu, 20 Nov 2014 14:07:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrSOc-0008EO-1n
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 14:07:42 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	2A/B2-26858-DA5FD645; Thu, 20 Nov 2014 14:07:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416492460!12733740!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5059 invoked from network); 20 Nov 2014 14:07:40 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 14:07:40 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 15:07:40 +0100
Message-Id: <546E03BC02000078000495B0@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 15:07:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part182D2CBC.0__="
Subject: [Xen-devel] DRAFT: XSA-113: Guest effectable page reference leak in
 MMU_MACHPHYS_UPDATE handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part182D2CBC.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

                    Xen Security Advisory XSA-113

  Guest effectable page reference leak in MMU_MACHPHYS_UPDATE handling

              *** EMBARGOED UNTIL 2014-11-27 12:00 UTC ***

ISSUE DESCRIPTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

An error handling path in the processing of MMU_MACHPHYS_UPDATE failed
to drop a page reference which was acquired in an earlier processing
step.

IMPACT
=3D=3D=3D=3D=3D=3D

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.

Only domains controlling HVM guests can exploit this vulnerability.
(This includes domains providing hardware emulation services to HVM
guests.)

VULNERABLE SYSTEMS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
Older versions have not been inspected.  ARM systems are not vulnerable.

This vulnerability is only applicable to Xen systems using stub domains
or other forms of disaggregation of control domains for HVM guests.

MITIGATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Running only PV guests will avoid this issue.

(The security of a Xen system using stub domains is still better than
with a qemu-dm running as an unrestricted dom0 process.  Therefore
users with these configurations should not switch to an unrestricted
dom0 qemu-dm.)

RESOLUTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Applying the attached patch resolves this issue.

xsa113.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x

$ sha256sum xsa113*.patch
a0f2b792a6b4648151f85fe13961b0bf309a568ed03e1b1d4ea01e4eabf1b18e  =
xsa113.patch
$



--=__Part182D2CBC.0__=
Content-Type: text/plain; name="xsa113.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xsa113.patch"

x86/mm: fix a reference counting error in MMU_MACHPHYS_UPDATE=0A=0AAny =
domain which can pass the XSM check against a translated guest can cause =
a=0Apage reference to be leaked.=0A=0AWhile shuffling the order of checks, =
drop the quite-pointless MEM_LOG().  This=0Abrings the check in line with =
similar checks in the vicinity.=0A=0ADiscovered while reviewing the =
XSA-109/110 followup series.=0A=0AThis is XSA-113.=0A=0ASigned-off-by: =
Andrew Cooper <andrew.cooper3@citrix.com>=0AReviewed-by: Jan Beulich =
<jbeulich@suse.com>=0AReviewed-by: Tim Deegan <tim@xen.org>=0A=0A--- =
a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -3619,6 +3619,12 @@ =
long do_mmu_update(=0A =0A         case MMU_MACHPHYS_UPDATE:=0A =0A+       =
     if ( unlikely(paging_mode_translate(pg_owner)) )=0A+            {=0A+ =
               rc =3D -EINVAL;=0A+                break;=0A+            =
}=0A+=0A             mfn =3D req.ptr >> PAGE_SHIFT;=0A             gpfn =
=3D req.val;=0A =0A@@ -3638,13 +3644,6 @@ long do_mmu_update(=0A           =
      break;=0A             }=0A =0A-            if ( unlikely(paging_mode_=
translate(pg_owner)) )=0A-            {=0A-                MEM_LOG("Mach-ph=
ys update on auto-translate guest");=0A-                rc =3D -EINVAL;=0A-=
                break;=0A-            }=0A-=0A             set_gpfn_from_mf=
n(mfn, gpfn);=0A =0A             paging_mark_dirty(pg_owner, mfn);=0A
--=__Part182D2CBC.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

--=__Part182D2CBC.0__=--


From xen-devel-bounces@lists.xen.org Thu Nov 20 14:08:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:08:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrSOd-0008ET-DC; Thu, 20 Nov 2014 14:07:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrSOc-0008EO-1n
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 14:07:42 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	2A/B2-26858-DA5FD645; Thu, 20 Nov 2014 14:07:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416492460!12733740!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5059 invoked from network); 20 Nov 2014 14:07:40 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 14:07:40 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 15:07:40 +0100
Message-Id: <546E03BC02000078000495B0@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 15:07:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part182D2CBC.0__="
Subject: [Xen-devel] DRAFT: XSA-113: Guest effectable page reference leak in
 MMU_MACHPHYS_UPDATE handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part182D2CBC.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

                    Xen Security Advisory XSA-113

  Guest effectable page reference leak in MMU_MACHPHYS_UPDATE handling

              *** EMBARGOED UNTIL 2014-11-27 12:00 UTC ***

ISSUE DESCRIPTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

An error handling path in the processing of MMU_MACHPHYS_UPDATE failed
to drop a page reference which was acquired in an earlier processing
step.

IMPACT
=3D=3D=3D=3D=3D=3D

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.

Only domains controlling HVM guests can exploit this vulnerability.
(This includes domains providing hardware emulation services to HVM
guests.)

VULNERABLE SYSTEMS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
Older versions have not been inspected.  ARM systems are not vulnerable.

This vulnerability is only applicable to Xen systems using stub domains
or other forms of disaggregation of control domains for HVM guests.

MITIGATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Running only PV guests will avoid this issue.

(The security of a Xen system using stub domains is still better than
with a qemu-dm running as an unrestricted dom0 process.  Therefore
users with these configurations should not switch to an unrestricted
dom0 qemu-dm.)

RESOLUTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Applying the attached patch resolves this issue.

xsa113.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x

$ sha256sum xsa113*.patch
a0f2b792a6b4648151f85fe13961b0bf309a568ed03e1b1d4ea01e4eabf1b18e  =
xsa113.patch
$



--=__Part182D2CBC.0__=
Content-Type: text/plain; name="xsa113.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xsa113.patch"

x86/mm: fix a reference counting error in MMU_MACHPHYS_UPDATE=0A=0AAny =
domain which can pass the XSM check against a translated guest can cause =
a=0Apage reference to be leaked.=0A=0AWhile shuffling the order of checks, =
drop the quite-pointless MEM_LOG().  This=0Abrings the check in line with =
similar checks in the vicinity.=0A=0ADiscovered while reviewing the =
XSA-109/110 followup series.=0A=0AThis is XSA-113.=0A=0ASigned-off-by: =
Andrew Cooper <andrew.cooper3@citrix.com>=0AReviewed-by: Jan Beulich =
<jbeulich@suse.com>=0AReviewed-by: Tim Deegan <tim@xen.org>=0A=0A--- =
a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -3619,6 +3619,12 @@ =
long do_mmu_update(=0A =0A         case MMU_MACHPHYS_UPDATE:=0A =0A+       =
     if ( unlikely(paging_mode_translate(pg_owner)) )=0A+            {=0A+ =
               rc =3D -EINVAL;=0A+                break;=0A+            =
}=0A+=0A             mfn =3D req.ptr >> PAGE_SHIFT;=0A             gpfn =
=3D req.val;=0A =0A@@ -3638,13 +3644,6 @@ long do_mmu_update(=0A           =
      break;=0A             }=0A =0A-            if ( unlikely(paging_mode_=
translate(pg_owner)) )=0A-            {=0A-                MEM_LOG("Mach-ph=
ys update on auto-translate guest");=0A-                rc =3D -EINVAL;=0A-=
                break;=0A-            }=0A-=0A             set_gpfn_from_mf=
n(mfn, gpfn);=0A =0A             paging_mark_dirty(pg_owner, mfn);=0A
--=__Part182D2CBC.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

--=__Part182D2CBC.0__=--


From xen-devel-bounces@lists.xen.org Thu Nov 20 14:22:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:22:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrScZ-000081-U9; Thu, 20 Nov 2014 14:22:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrScY-00007t-Hm
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:22:06 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	05/B7-27785-D09FD645; Thu, 20 Nov 2014 14:22:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416493323!8355127!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21335 invoked from network); 20 Nov 2014 14:22:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 14:22:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194803044"
Message-ID: <546DF8FC.6060404@citrix.com>
Date: Thu, 20 Nov 2014 14:21:48 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Chao Peng <chao.p.peng@linux.intel.com>
References: <546DBB4D.9030100@citrix.com>	<20141120101505.GB20252@pengc-linux.bj.intel.com>
	<546DC105.20803@citrix.com>
In-Reply-To: <546DC105.20803@citrix.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 Testing - Cache Monitoring Technology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 10:23, Andrew Cooper wrote:
> On 20/11/14 10:15, Chao Peng wrote:
>> On Thu, Nov 20, 2014 at 09:58:37AM +0000, Andrew Cooper wrote:
>>> Hi,
>>>
>>> I have found myself a PSR-capable server and have been having a play
>>> with Xen-4.5
>>>
>>> At a first pass, I can get some numbers out:
>>>
>>> [root@blob ~]# xl psr-cmt-attach 0
>>> [root@blob ~]# xl psr-cmt-show cache_occupancy
>>> Total RMID: 71
>>> Name                                        ID        Socket 0       
>>> Socket 1
>>> Total L3 Cache Size                                   46080 KB       
>>> 46080 KB
>>> Domain-0                                     0        45072
>>> KB            0 KB
>>> [root@blob ~]#
>>>
>>> However, I am unable to get any occupancy information for HVM guests. 
>>> Given nothing obvious in the code which would make CMT PV-guest
>>> specific, I presume this is unexpected?
>>>
>>>
>> Thank your for trying...
>> But I just tested the HVM on my box and it runs correct.
>>
>> Have you missed to run psr-cmt-attach for your HVM domain? Otherwise I
>> think there may be something wrong.
> No - I get the HVM domain (a memtest domain) listed in the output.  It
> is clear from Dom0's occupancy dropping off significantly that
> competition is underway on Socket 0 (as expected), but the domain always
> has 0 occupancy reported.
>
> I shall investigate.

On further investigation, it would appear to be a behavioural property
of memtest (5.01, 8vcpu guest, 1GB RAM).

In SMP mode with all cpus streaming data, the occupancy skyrockets. 
However, when only cpu0 is running (with all other cpus waiting until
the end of the round), the occupancy drops to 0.

On this system, it would appear that the minimum granularity is 72KB,
and 72KB is occasionally reported rather than 0.  I am guessing that
when only a single cpu is running, the occupancy is less than the
granularity, and the 0 being reported is as a result of rounding.

It is interesting to note that with dom0 only, dom0's occupancy is
almost all of the LLC, but with this single memtest domU, the
occupancies of dom0 + domU is never more than 1/4 of the LLC.  I presume
that this means that copious cache flushing is going on.


Whatever the reason, it has been interesting having a bit of a play. It
does appear that PSR and CMT JustWorked(tm) for me on Xen-4.5 which is
very nice.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:22:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:22:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrScZ-000081-U9; Thu, 20 Nov 2014 14:22:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrScY-00007t-Hm
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:22:06 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	05/B7-27785-D09FD645; Thu, 20 Nov 2014 14:22:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416493323!8355127!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21335 invoked from network); 20 Nov 2014 14:22:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 14:22:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194803044"
Message-ID: <546DF8FC.6060404@citrix.com>
Date: Thu, 20 Nov 2014 14:21:48 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Chao Peng <chao.p.peng@linux.intel.com>
References: <546DBB4D.9030100@citrix.com>	<20141120101505.GB20252@pengc-linux.bj.intel.com>
	<546DC105.20803@citrix.com>
In-Reply-To: <546DC105.20803@citrix.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 Testing - Cache Monitoring Technology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 10:23, Andrew Cooper wrote:
> On 20/11/14 10:15, Chao Peng wrote:
>> On Thu, Nov 20, 2014 at 09:58:37AM +0000, Andrew Cooper wrote:
>>> Hi,
>>>
>>> I have found myself a PSR-capable server and have been having a play
>>> with Xen-4.5
>>>
>>> At a first pass, I can get some numbers out:
>>>
>>> [root@blob ~]# xl psr-cmt-attach 0
>>> [root@blob ~]# xl psr-cmt-show cache_occupancy
>>> Total RMID: 71
>>> Name                                        ID        Socket 0       
>>> Socket 1
>>> Total L3 Cache Size                                   46080 KB       
>>> 46080 KB
>>> Domain-0                                     0        45072
>>> KB            0 KB
>>> [root@blob ~]#
>>>
>>> However, I am unable to get any occupancy information for HVM guests. 
>>> Given nothing obvious in the code which would make CMT PV-guest
>>> specific, I presume this is unexpected?
>>>
>>>
>> Thank your for trying...
>> But I just tested the HVM on my box and it runs correct.
>>
>> Have you missed to run psr-cmt-attach for your HVM domain? Otherwise I
>> think there may be something wrong.
> No - I get the HVM domain (a memtest domain) listed in the output.  It
> is clear from Dom0's occupancy dropping off significantly that
> competition is underway on Socket 0 (as expected), but the domain always
> has 0 occupancy reported.
>
> I shall investigate.

On further investigation, it would appear to be a behavioural property
of memtest (5.01, 8vcpu guest, 1GB RAM).

In SMP mode with all cpus streaming data, the occupancy skyrockets. 
However, when only cpu0 is running (with all other cpus waiting until
the end of the round), the occupancy drops to 0.

On this system, it would appear that the minimum granularity is 72KB,
and 72KB is occasionally reported rather than 0.  I am guessing that
when only a single cpu is running, the occupancy is less than the
granularity, and the 0 being reported is as a result of rounding.

It is interesting to note that with dom0 only, dom0's occupancy is
almost all of the LLC, but with this single memtest domU, the
occupancies of dom0 + domU is never more than 1/4 of the LLC.  I presume
that this means that copious cache flushing is going on.


Whatever the reason, it has been interesting having a bit of a play. It
does appear that PSR and CMT JustWorked(tm) for me on Xen-4.5 which is
very nice.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:35:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14: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 1XrSpH-0000Ou-Nm; Thu, 20 Nov 2014 14:35:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkoch@verizon.com>) id 1XrSpG-0000Op-7X
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:35:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4F/8D-09936-12CFD645; Thu, 20 Nov 2014 14:35:13 +0000
X-Env-Sender: dkoch@verizon.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416494112!12043854!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6737 invoked from network); 20 Nov 2014 14:35:13 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 14:35:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dkoch@verizon.com; q=dns/txt; s=corp;
	t=1416494113; x=1448030113;
	h=date:from:to:cc:subject:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=1dXpW9tYK2MkgS4G7oXxUbyAtsi8YcDza/VzT7d/7X8=;
	b=EAZrAPd2iJLY/o6yJZIraycdHkGswiO3UH6KW4HpclBZljzPGsWgIDOD
	r29P85wC1g5sE9ZNYsBGxPOQhN6RCbHitBwvqyTBbbiKx3LNMPaobCTsp
	y3Pzm9lZo5HGvwv5yNRyH8+Q63jyTJeEudErAoV0wVw/ny3b3SSCJ3WGR k=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 20 Nov 2014 14:35:11 +0000
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="875328233"
Received: from unknown (HELO yoyo) ([162.47.5.245])
	by fldsmtpi03.verizon.com with SMTP; 20 Nov 2014 14:35:10 +0000
Date: Thu, 20 Nov 2014 09:35:10 -0500
From: Don Koch <dkoch@verizon.com>
To: Don Koch <dkoch@verizon.com>
Message-Id: <20141120093510.2c775b06cd6725c87721e614@verizon.com>
In-Reply-To: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
X-Mailer: Sylpheed 3.4.0beta6 (GTK+ 2.24.22; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This change can be ignored. Details below.

On Tue, 18 Nov 2014 10:26:31 -0500
Don Koch <dkoch@verizon.com> wrote:

> If we restore an xsave area from an older xen that has a larger
> size than the xcr0 bit call for, it is possible to have non-zero
> data in the unused area if an xsave has ever been done that used
> that area (e.g. during a context switch). Since the vcpu's xsave
> area is never zeroed after the initial allocation, that data is
> still there. Since we are told that said area was not written to
> during the save or migration, there is no need to restore it.

Found the issue. Don Slutz had reported this occurring a couple of times
and I witnessed the bad data in the unused area. Turns out he had
done a migration from 4.3 to 4.4, then another migration from 4.4 to
4.3 and when he tried another 4.3 to 4.4 migration, it failed.

Since 4.4 to 4.3 migration isn't supported, we can punt this fix.
Well, unless we want to support this (I assume not) in which case
it still needs a minor tweak.

Sorry for the noise.

-d

> Signed-off-by: Don Koch <dkoch@verizon.com>
> ---
> Turns out the assertion that the unused xsave area is zero
> is wrong. Unfortunately, that leaves the following as the
> only way I can think of to work around it (and is no worse
> than xsave/xrestore during context switches). Alternate
> suggestions welcome.
> 
>  xen/arch/x86/hvm/hvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 8f49b44..b2c0bc4 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
>                  printk(XENLOG_G_WARNING
>                         "HVM%d.%u restore mismatch: xsave length %#x > %#x (non-zero data at %#x)\n",
>                         d->domain_id, vcpuid, desc->length, size, i);
> -                return -EOPNOTSUPP;
> +                break;
>              }
>          }
>          printk(XENLOG_G_WARNING
> -- 
> 1.8.3.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:35:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14: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 1XrSpH-0000Ou-Nm; Thu, 20 Nov 2014 14:35:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkoch@verizon.com>) id 1XrSpG-0000Op-7X
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:35:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4F/8D-09936-12CFD645; Thu, 20 Nov 2014 14:35:13 +0000
X-Env-Sender: dkoch@verizon.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416494112!12043854!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6737 invoked from network); 20 Nov 2014 14:35:13 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 14:35:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dkoch@verizon.com; q=dns/txt; s=corp;
	t=1416494113; x=1448030113;
	h=date:from:to:cc:subject:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=1dXpW9tYK2MkgS4G7oXxUbyAtsi8YcDza/VzT7d/7X8=;
	b=EAZrAPd2iJLY/o6yJZIraycdHkGswiO3UH6KW4HpclBZljzPGsWgIDOD
	r29P85wC1g5sE9ZNYsBGxPOQhN6RCbHitBwvqyTBbbiKx3LNMPaobCTsp
	y3Pzm9lZo5HGvwv5yNRyH8+Q63jyTJeEudErAoV0wVw/ny3b3SSCJ3WGR k=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 20 Nov 2014 14:35:11 +0000
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="875328233"
Received: from unknown (HELO yoyo) ([162.47.5.245])
	by fldsmtpi03.verizon.com with SMTP; 20 Nov 2014 14:35:10 +0000
Date: Thu, 20 Nov 2014 09:35:10 -0500
From: Don Koch <dkoch@verizon.com>
To: Don Koch <dkoch@verizon.com>
Message-Id: <20141120093510.2c775b06cd6725c87721e614@verizon.com>
In-Reply-To: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
X-Mailer: Sylpheed 3.4.0beta6 (GTK+ 2.24.22; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This change can be ignored. Details below.

On Tue, 18 Nov 2014 10:26:31 -0500
Don Koch <dkoch@verizon.com> wrote:

> If we restore an xsave area from an older xen that has a larger
> size than the xcr0 bit call for, it is possible to have non-zero
> data in the unused area if an xsave has ever been done that used
> that area (e.g. during a context switch). Since the vcpu's xsave
> area is never zeroed after the initial allocation, that data is
> still there. Since we are told that said area was not written to
> during the save or migration, there is no need to restore it.

Found the issue. Don Slutz had reported this occurring a couple of times
and I witnessed the bad data in the unused area. Turns out he had
done a migration from 4.3 to 4.4, then another migration from 4.4 to
4.3 and when he tried another 4.3 to 4.4 migration, it failed.

Since 4.4 to 4.3 migration isn't supported, we can punt this fix.
Well, unless we want to support this (I assume not) in which case
it still needs a minor tweak.

Sorry for the noise.

-d

> Signed-off-by: Don Koch <dkoch@verizon.com>
> ---
> Turns out the assertion that the unused xsave area is zero
> is wrong. Unfortunately, that leaves the following as the
> only way I can think of to work around it (and is no worse
> than xsave/xrestore during context switches). Alternate
> suggestions welcome.
> 
>  xen/arch/x86/hvm/hvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 8f49b44..b2c0bc4 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
>                  printk(XENLOG_G_WARNING
>                         "HVM%d.%u restore mismatch: xsave length %#x > %#x (non-zero data at %#x)\n",
>                         d->domain_id, vcpuid, desc->length, size, i);
> -                return -EOPNOTSUPP;
> +                break;
>              }
>          }
>          printk(XENLOG_G_WARNING
> -- 
> 1.8.3.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:37:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:37:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrSrK-0000UH-8A; Thu, 20 Nov 2014 14:37:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrSrI-0000UA-E7
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 14:37:20 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	68/D4-17958-F9CFD645; Thu, 20 Nov 2014 14:37:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416494239!12736829!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22434 invoked from network); 20 Nov 2014 14:37:19 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 14:37:19 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 15:37:18 +0100
Message-Id: <546E0AAF02000078000495E0@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 15:37:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1416338436-3293-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1416338436-3293-1-git-send-email-julien.grall@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	George Dunlap <george.dunlap@eu.citrix.com>, tim@xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC for 4.6] xen: Extend DOMCTL createdomain to
 support arch configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 20:20, <julien.grall@linaro.org> wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -540,6 +540,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      int i, j, e820_warn = 0, bytes = 0;
>      bool_t acpi_boot_table_init_done = 0;
>      struct domain *dom0;
> +    struct arch_domainconfig config;
>      struct ns16550_defaults ns16550 = {
>          .data_bits = 8,
>          .parity    = 'n',
> @@ -1347,7 +1348,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>          domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
>  
>      /* Create initial domain 0. */
> -    dom0 = domain_create(0, domcr_flags, 0);
> +    memset(&config, 0, sizeof(config));
> +    dom0 = domain_create(0, domcr_flags, 0, &config);

Why not NULL like almost everywhere else?

> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -228,6 +228,11 @@ struct arch_shared_info {
>  };
>  typedef struct arch_shared_info arch_shared_info_t;
>  
> +struct arch_domainconfig {
> +    char dummy;
> +};
> +typedef struct arch_domainconfig arch_domainconfig_t;

I think we decided that, regardless of all bad precedents, we'd stop
adding things without xen_ prefix to the public interface. I'm also
rather uncertain about all these typedef-s - I think we could very
well get away without adding any new ones (if internally to the
hypervisor or tools they turn out to make the code much better
readable, each such component could still introduce one on its own).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:37:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:37:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrSrK-0000UH-8A; Thu, 20 Nov 2014 14:37:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrSrI-0000UA-E7
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 14:37:20 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	68/D4-17958-F9CFD645; Thu, 20 Nov 2014 14:37:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416494239!12736829!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22434 invoked from network); 20 Nov 2014 14:37:19 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 14:37:19 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 15:37:18 +0100
Message-Id: <546E0AAF02000078000495E0@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 15:37:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1416338436-3293-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1416338436-3293-1-git-send-email-julien.grall@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	George Dunlap <george.dunlap@eu.citrix.com>, tim@xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC for 4.6] xen: Extend DOMCTL createdomain to
 support arch configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.11.14 at 20:20, <julien.grall@linaro.org> wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -540,6 +540,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      int i, j, e820_warn = 0, bytes = 0;
>      bool_t acpi_boot_table_init_done = 0;
>      struct domain *dom0;
> +    struct arch_domainconfig config;
>      struct ns16550_defaults ns16550 = {
>          .data_bits = 8,
>          .parity    = 'n',
> @@ -1347,7 +1348,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>          domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
>  
>      /* Create initial domain 0. */
> -    dom0 = domain_create(0, domcr_flags, 0);
> +    memset(&config, 0, sizeof(config));
> +    dom0 = domain_create(0, domcr_flags, 0, &config);

Why not NULL like almost everywhere else?

> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -228,6 +228,11 @@ struct arch_shared_info {
>  };
>  typedef struct arch_shared_info arch_shared_info_t;
>  
> +struct arch_domainconfig {
> +    char dummy;
> +};
> +typedef struct arch_domainconfig arch_domainconfig_t;

I think we decided that, regardless of all bad precedents, we'd stop
adding things without xen_ prefix to the public interface. I'm also
rather uncertain about all these typedef-s - I think we could very
well get away without adding any new ones (if internally to the
hypervisor or tools they turn out to make the code much better
readable, each such component could still introduce one on its own).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:40:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrSuM-0000dc-ST; Thu, 20 Nov 2014 14:40:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XrSuL-0000dW-Hc
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:40:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E7/12-25276-C5DFD645; Thu, 20 Nov 2014 14:40:28 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416494425!14216402!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6610 invoked from network); 20 Nov 2014 14:40:26 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-21.messagelabs.com with SMTP;
	20 Nov 2014 14:40:26 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 20 Nov 2014 06:40:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,424,1413270000"; d="scan'208";a="611133082"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga001.jf.intel.com with ESMTP; 20 Nov 2014 06:40:15 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 20 Nov 2014 22:40:13 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Thu, 20 Nov 2014 22:40:12 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
	guest memory is out of reserved device memory maps
Thread-Index: AQHP/l8LtnOoOMCxBUyde78SnbhphJxnpV8ggAF+RLD//4qpgIAAjifggABlnHA=
Date: Thu, 20 Nov 2014 14:40:11 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
	<546DAE8F020000780004930A@mail.emea.novell.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Chen,
	Tiejun" <tiejun.chen@intel.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tian, Kevin
> Sent: Thursday, November 20, 2014 4:51 PM
> 
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Thursday, November 20, 2014 4:04 PM
> >
> > >>> On 20.11.14 at 08:45, <kevin.tian@intel.com> wrote:
> > > Yang and I did some discussion here. We understand your point to
> > > avoid introducing new interface if we can leverage existing code.
> > > However it's not a trivial effort to move device assignment before
> > > populating p2m, and there is no other benefit of doing so except
> > > for this purpose. So we'd not suggest this way.
> >
> > "It's not a trivial effort" is pretty vague: What specifically is it that
> > makes this difficult? I wouldn't expect there to be any strong
> > dependencies on the ordering of these two operations...
> 
> I'll leave to Yang to answer this part, who did a detail investigation
> on that, e.g. on IOMMU page table setup, etc. But what really matters
> here is not only about complexity, but also flexibility. Doing so will
> tie the policy to assigned device only, which removes the option to
> support hotpluggable device.
> 
> >
> > > Current option sounds a reasonable one, i.e. passing a list of BDFs
> > > assigned to this VM before populating p2m, and then having
> > > hypervisor to filter out reserved regions associated with those
> > > BDFs. This way libxc teaches Xen to create reserved regions once,
> > > and then later the filtered info is returned upon query.
> >
> > Reasonable, but partly redundant. The positive aspect being that
> > it permits this list and the list of actually being assigned devices to
> > be different, i.e. allowing holes to be set up for devices that only
> > _may_ get assigned at some point.
> 
> redundant if we think the list only exactly matching the statically
> assigned devices. but that's just current point.
> 
> reasonable if we think there may be other policies impacting the list
> (e.g. if hotplugable device may have a config option and then we have
> a potential list larger than static assigned devices). From this angle
> I think the new interface actually makes sense for this very purpose.
> 

Jan are you OK with this? In previous approach we reserved all the
RMRR regions so hotplug scenario is covered automatically. Now since
we want to do BDF specific filtering, this new interface is actually
necessary for hotplug support. If OK, Tiejun will send out a new 
series to see whether it's ready for 4.5 check-in.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:40:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrSuM-0000dc-ST; Thu, 20 Nov 2014 14:40:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XrSuL-0000dW-Hc
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:40:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E7/12-25276-C5DFD645; Thu, 20 Nov 2014 14:40:28 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416494425!14216402!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6610 invoked from network); 20 Nov 2014 14:40:26 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-21.messagelabs.com with SMTP;
	20 Nov 2014 14:40:26 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 20 Nov 2014 06:40:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,424,1413270000"; d="scan'208";a="611133082"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga001.jf.intel.com with ESMTP; 20 Nov 2014 06:40:15 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 20 Nov 2014 22:40:13 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Thu, 20 Nov 2014 22:40:12 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
	guest memory is out of reserved device memory maps
Thread-Index: AQHP/l8LtnOoOMCxBUyde78SnbhphJxnpV8ggAF+RLD//4qpgIAAjifggABlnHA=
Date: Thu, 20 Nov 2014 14:40:11 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
	<546DAE8F020000780004930A@mail.emea.novell.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Chen,
	Tiejun" <tiejun.chen@intel.com>, "tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tian, Kevin
> Sent: Thursday, November 20, 2014 4:51 PM
> 
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Thursday, November 20, 2014 4:04 PM
> >
> > >>> On 20.11.14 at 08:45, <kevin.tian@intel.com> wrote:
> > > Yang and I did some discussion here. We understand your point to
> > > avoid introducing new interface if we can leverage existing code.
> > > However it's not a trivial effort to move device assignment before
> > > populating p2m, and there is no other benefit of doing so except
> > > for this purpose. So we'd not suggest this way.
> >
> > "It's not a trivial effort" is pretty vague: What specifically is it that
> > makes this difficult? I wouldn't expect there to be any strong
> > dependencies on the ordering of these two operations...
> 
> I'll leave to Yang to answer this part, who did a detail investigation
> on that, e.g. on IOMMU page table setup, etc. But what really matters
> here is not only about complexity, but also flexibility. Doing so will
> tie the policy to assigned device only, which removes the option to
> support hotpluggable device.
> 
> >
> > > Current option sounds a reasonable one, i.e. passing a list of BDFs
> > > assigned to this VM before populating p2m, and then having
> > > hypervisor to filter out reserved regions associated with those
> > > BDFs. This way libxc teaches Xen to create reserved regions once,
> > > and then later the filtered info is returned upon query.
> >
> > Reasonable, but partly redundant. The positive aspect being that
> > it permits this list and the list of actually being assigned devices to
> > be different, i.e. allowing holes to be set up for devices that only
> > _may_ get assigned at some point.
> 
> redundant if we think the list only exactly matching the statically
> assigned devices. but that's just current point.
> 
> reasonable if we think there may be other policies impacting the list
> (e.g. if hotplugable device may have a config option and then we have
> a potential list larger than static assigned devices). From this angle
> I think the new interface actually makes sense for this very purpose.
> 

Jan are you OK with this? In previous approach we reserved all the
RMRR regions so hotplug scenario is covered automatically. Now since
we want to do BDF specific filtering, this new interface is actually
necessary for hotplug support. If OK, Tiejun will send out a new 
series to see whether it's ready for 4.5 check-in.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:45:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:45:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrSzE-0000te-Jv; Thu, 20 Nov 2014 14:45:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrSzC-0000tZ-Re
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:45:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B3/BA-25276-A8EFD645; Thu, 20 Nov 2014 14:45:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416494729!14163683!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1426 invoked from network); 20 Nov 2014 14:45:29 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 14:45:29 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 15:45:29 +0100
Message-Id: <546E0C9902000078000495FF@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 15:45:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Don Koch" <dkoch@verizon.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
	<20141120093510.2c775b06cd6725c87721e614@verizon.com>
In-Reply-To: <20141120093510.2c775b06cd6725c87721e614@verizon.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: AndrewCooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.11.14 at 15:35, <dkoch@verizon.com> wrote:
> On Tue, 18 Nov 2014 10:26:31 -0500
> Don Koch <dkoch@verizon.com> wrote:
> 
>> If we restore an xsave area from an older xen that has a larger
>> size than the xcr0 bit call for, it is possible to have non-zero
>> data in the unused area if an xsave has ever been done that used
>> that area (e.g. during a context switch). Since the vcpu's xsave
>> area is never zeroed after the initial allocation, that data is
>> still there. Since we are told that said area was not written to
>> during the save or migration, there is no need to restore it.
> 
> Found the issue. Don Slutz had reported this occurring a couple of times
> and I witnessed the bad data in the unused area. Turns out he had
> done a migration from 4.3 to 4.4, then another migration from 4.4 to
> 4.3 and when he tried another 4.3 to 4.4 migration, it failed.

With the important part being that 4.3.0 (other than 4.3.3)
copied as much data as the receiving system's XSAVE
capabilities would require, i.e. potentially stuff that wasn't part
of the CPU_XSAVE save record at all (if the sending side either
had less capabilities or used an already fixed hypervisor).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:45:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:45:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrSzE-0000te-Jv; Thu, 20 Nov 2014 14:45:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrSzC-0000tZ-Re
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:45:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B3/BA-25276-A8EFD645; Thu, 20 Nov 2014 14:45:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416494729!14163683!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1426 invoked from network); 20 Nov 2014 14:45:29 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 14:45:29 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 15:45:29 +0100
Message-Id: <546E0C9902000078000495FF@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 15:45:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Don Koch" <dkoch@verizon.com>
References: <1416324391-21118-1-git-send-email-dkoch@verizon.com>
	<20141120093510.2c775b06cd6725c87721e614@verizon.com>
In-Reply-To: <20141120093510.2c775b06cd6725c87721e614@verizon.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: AndrewCooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.11.14 at 15:35, <dkoch@verizon.com> wrote:
> On Tue, 18 Nov 2014 10:26:31 -0500
> Don Koch <dkoch@verizon.com> wrote:
> 
>> If we restore an xsave area from an older xen that has a larger
>> size than the xcr0 bit call for, it is possible to have non-zero
>> data in the unused area if an xsave has ever been done that used
>> that area (e.g. during a context switch). Since the vcpu's xsave
>> area is never zeroed after the initial allocation, that data is
>> still there. Since we are told that said area was not written to
>> during the save or migration, there is no need to restore it.
> 
> Found the issue. Don Slutz had reported this occurring a couple of times
> and I witnessed the bad data in the unused area. Turns out he had
> done a migration from 4.3 to 4.4, then another migration from 4.4 to
> 4.3 and when he tried another 4.3 to 4.4 migration, it failed.

With the important part being that 4.3.0 (other than 4.3.3)
copied as much data as the receiving system's XSAVE
capabilities would require, i.e. potentially stuff that wasn't part
of the CPU_XSAVE save record at all (if the sending side either
had less capabilities or used an already fixed hypervisor).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:46:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14: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 1XrT0J-0000yX-3q; Thu, 20 Nov 2014 14:46:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrT0H-0000yG-0S
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:46:37 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	A6/79-27623-CCEFD645; Thu, 20 Nov 2014 14:46:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416494795!9010941!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21094 invoked from network); 20 Nov 2014 14:46:35 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 14:46:35 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 15:46:35 +0100
Message-Id: <546E0CDB0200007800049602@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 15:46:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
	<546DAE8F020000780004930A@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Tiejun Chen <tiejun.chen@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 15:40, <kevin.tian@intel.com> wrote:
>>  From: Tian, Kevin
>> Sent: Thursday, November 20, 2014 4:51 PM
>> > From: Jan Beulich [mailto:JBeulich@suse.com]
>> > Sent: Thursday, November 20, 2014 4:04 PM
>> > >>> On 20.11.14 at 08:45, <kevin.tian@intel.com> wrote:
>> > > Current option sounds a reasonable one, i.e. passing a list of BDFs
>> > > assigned to this VM before populating p2m, and then having
>> > > hypervisor to filter out reserved regions associated with those
>> > > BDFs. This way libxc teaches Xen to create reserved regions once,
>> > > and then later the filtered info is returned upon query.
>> >
>> > Reasonable, but partly redundant. The positive aspect being that
>> > it permits this list and the list of actually being assigned devices to
>> > be different, i.e. allowing holes to be set up for devices that only
>> > _may_ get assigned at some point.
>> 
>> redundant if we think the list only exactly matching the statically
>> assigned devices. but that's just current point.
>> 
>> reasonable if we think there may be other policies impacting the list
>> (e.g. if hotplugable device may have a config option and then we have
>> a potential list larger than static assigned devices). From this angle
>> I think the new interface actually makes sense for this very purpose.
> 
> Jan are you OK with this?

I can live with it, yes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:46:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14: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 1XrT0J-0000yX-3q; Thu, 20 Nov 2014 14:46:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrT0H-0000yG-0S
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:46:37 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	A6/79-27623-CCEFD645; Thu, 20 Nov 2014 14:46:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416494795!9010941!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21094 invoked from network); 20 Nov 2014 14:46:35 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 14:46:35 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 15:46:35 +0100
Message-Id: <546E0CDB0200007800049602@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 15:46:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
	<546DAE8F020000780004930A@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Tiejun Chen <tiejun.chen@intel.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 15:40, <kevin.tian@intel.com> wrote:
>>  From: Tian, Kevin
>> Sent: Thursday, November 20, 2014 4:51 PM
>> > From: Jan Beulich [mailto:JBeulich@suse.com]
>> > Sent: Thursday, November 20, 2014 4:04 PM
>> > >>> On 20.11.14 at 08:45, <kevin.tian@intel.com> wrote:
>> > > Current option sounds a reasonable one, i.e. passing a list of BDFs
>> > > assigned to this VM before populating p2m, and then having
>> > > hypervisor to filter out reserved regions associated with those
>> > > BDFs. This way libxc teaches Xen to create reserved regions once,
>> > > and then later the filtered info is returned upon query.
>> >
>> > Reasonable, but partly redundant. The positive aspect being that
>> > it permits this list and the list of actually being assigned devices to
>> > be different, i.e. allowing holes to be set up for devices that only
>> > _may_ get assigned at some point.
>> 
>> redundant if we think the list only exactly matching the statically
>> assigned devices. but that's just current point.
>> 
>> reasonable if we think there may be other policies impacting the list
>> (e.g. if hotplugable device may have a config option and then we have
>> a potential list larger than static assigned devices). From this angle
>> I think the new interface actually makes sense for this very purpose.
> 
> Jan are you OK with this?

I can live with it, yes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:47:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrT1D-00015L-IC; Thu, 20 Nov 2014 14:47:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>)
	id 1XrT1C-000158-OH; Thu, 20 Nov 2014 14:47:34 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	A4/39-22819-50FFD645; Thu, 20 Nov 2014 14:47:33 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416494850!12468443!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2925 invoked from network); 20 Nov 2014 14:47:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 14:47:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193286387"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 09:47:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrT0p-0004kh-An;
	Thu, 20 Nov 2014 14:47:11 +0000
Date: Thu, 20 Nov 2014 14:46:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416483731.14429.8.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Jim Fehlig <jfehlig@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-users@lists.xen.org, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Ian Campbell wrote:
> On Thu, 2014-11-20 at 11:39 +0000, Stefano Stabellini wrote:
> > On Thu, 20 Nov 2014, Ian Campbell wrote:
> > > On Mon, 2014-11-17 at 13:00 +0000, Stefano Stabellini wrote:
> > > > On Mon, 17 Nov 2014, Ian Campbell wrote:
> > > > > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > > > > By the way, how many NICs can I apply to a VM?
> > > > > > 
> > > > > > On xen-4.4.0, Using qemu-dm, I can apply 8 NIC to a VM, but using
> > > > > > qemu-system-i386, I can only apply 4 NICs to an VM?
> > > > > > is it normal?
> > > > > 
> > > > > I've no idea, CCing the qemu maintainers.
> > > > > 
> > > > > I'd have expected the number of PV nics to be completely independent of
> > > > > the device mode, so I suppose you mean emulated NICs?
> > > > 
> > > > I can pass 4 emulated NICs maximum, but you can easily reach 8 if you
> > > > use PV NICs instead. Just pass 'type=pv' like this:
> > > > 
> > > > vif=['', '', '', '', 'type=pv', 'type=pv', 'type=pv', 'type=pv']
> > > > 
> > > > it is going to create 4 emulated nics and 4 pv nics. The 4 emulated nics
> > > > also have 4 corresponding pv nics. The emulated nics get disconnected
> > > > soon after boot by the guest operating system (if it has pv drivers
> > > > installed, such as Linux). So overall once the boot sequence is fully
> > > > completed you'll end up with the 8 pv nics that you want.
> > > 
> > > I wonder if we should do something in (lib)xl such that by default the
> > > first 4 NICs have type LIBXL_NIC_TYPE_VIF_IOEMU (i.e. emulated+PV path)
> > > and the rest have LIBXL_NIC_TYPE_VIF (i.e. PV only).
> > 
> > That looks like a simple and reasonable idea.
> > 
> > 
> > > > BTW the reason for the failure seems to be that QEMU runs out of ram
> > > > (xen: failed to populate ram at 80110000, so
> > > > xc_domain_populate_physmap_exact failed) allocating roms for the rtl8139
> > > > (40000 bytes each). Maybe qemu-trad wasn't loading any roms for rtl8139.
> > > > Interestingly e1000 doesn't need any roms either, so another way around
> > > > this would be to set 'type=e1000' for all the vifs.
> > > 
> > > Or to use the new option in 4.5 to increase the MMIO space (or is that
> > > not where ROMs end up?)
> > > 
> > > Do we need to plumb through qemu's optionrom parameter to allow a)
> > > limiting the number of NICs which will try to do PXE and b) allow custom
> > > roms etc?
> > 
> > The libxl solution is the best one for simplicity, besides I don't think
> > there is such an option for QEMU.
> 
> There is, it's the romfile option to -device e.g.
>          -device $NICMODEL,vlan=0,romfile=$ROMFILE
>         
> where NICMODEL is e100, rtl8139, virtio-blah
> and ROMFILE is e.g. an ipxe binary.

I think that option was intended to point QEMU to a different file, not
to disable the romfile.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:47:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrT1D-00015L-IC; Thu, 20 Nov 2014 14:47:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>)
	id 1XrT1C-000158-OH; Thu, 20 Nov 2014 14:47:34 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	A4/39-22819-50FFD645; Thu, 20 Nov 2014 14:47:33 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416494850!12468443!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2925 invoked from network); 20 Nov 2014 14:47:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 14:47:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193286387"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 09:47:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrT0p-0004kh-An;
	Thu, 20 Nov 2014 14:47:11 +0000
Date: Thu, 20 Nov 2014 14:46:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416483731.14429.8.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Jim Fehlig <jfehlig@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-users@lists.xen.org, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Ian Campbell wrote:
> On Thu, 2014-11-20 at 11:39 +0000, Stefano Stabellini wrote:
> > On Thu, 20 Nov 2014, Ian Campbell wrote:
> > > On Mon, 2014-11-17 at 13:00 +0000, Stefano Stabellini wrote:
> > > > On Mon, 17 Nov 2014, Ian Campbell wrote:
> > > > > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > > > > By the way, how many NICs can I apply to a VM?
> > > > > > 
> > > > > > On xen-4.4.0, Using qemu-dm, I can apply 8 NIC to a VM, but using
> > > > > > qemu-system-i386, I can only apply 4 NICs to an VM?
> > > > > > is it normal?
> > > > > 
> > > > > I've no idea, CCing the qemu maintainers.
> > > > > 
> > > > > I'd have expected the number of PV nics to be completely independent of
> > > > > the device mode, so I suppose you mean emulated NICs?
> > > > 
> > > > I can pass 4 emulated NICs maximum, but you can easily reach 8 if you
> > > > use PV NICs instead. Just pass 'type=pv' like this:
> > > > 
> > > > vif=['', '', '', '', 'type=pv', 'type=pv', 'type=pv', 'type=pv']
> > > > 
> > > > it is going to create 4 emulated nics and 4 pv nics. The 4 emulated nics
> > > > also have 4 corresponding pv nics. The emulated nics get disconnected
> > > > soon after boot by the guest operating system (if it has pv drivers
> > > > installed, such as Linux). So overall once the boot sequence is fully
> > > > completed you'll end up with the 8 pv nics that you want.
> > > 
> > > I wonder if we should do something in (lib)xl such that by default the
> > > first 4 NICs have type LIBXL_NIC_TYPE_VIF_IOEMU (i.e. emulated+PV path)
> > > and the rest have LIBXL_NIC_TYPE_VIF (i.e. PV only).
> > 
> > That looks like a simple and reasonable idea.
> > 
> > 
> > > > BTW the reason for the failure seems to be that QEMU runs out of ram
> > > > (xen: failed to populate ram at 80110000, so
> > > > xc_domain_populate_physmap_exact failed) allocating roms for the rtl8139
> > > > (40000 bytes each). Maybe qemu-trad wasn't loading any roms for rtl8139.
> > > > Interestingly e1000 doesn't need any roms either, so another way around
> > > > this would be to set 'type=e1000' for all the vifs.
> > > 
> > > Or to use the new option in 4.5 to increase the MMIO space (or is that
> > > not where ROMs end up?)
> > > 
> > > Do we need to plumb through qemu's optionrom parameter to allow a)
> > > limiting the number of NICs which will try to do PXE and b) allow custom
> > > roms etc?
> > 
> > The libxl solution is the best one for simplicity, besides I don't think
> > there is such an option for QEMU.
> 
> There is, it's the romfile option to -device e.g.
>          -device $NICMODEL,vlan=0,romfile=$ROMFILE
>         
> where NICMODEL is e100, rtl8139, virtio-blah
> and ROMFILE is e.g. an ipxe binary.

I think that option was intended to point QEMU to a different file, not
to disable the romfile.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:49:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:49:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrT2m-0001I6-QQ; Thu, 20 Nov 2014 14:49:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1XrT2l-0001Hu-7U; Thu, 20 Nov 2014 14:49:11 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	39/C1-02953-66FFD645; Thu, 20 Nov 2014 14:49:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416494948!13765718!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30175 invoked from network); 20 Nov 2014 14:49:09 -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;
	20 Nov 2014 14:49:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193287119"
Message-ID: <1416494946.14429.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Nov 2014 14:49:06 +0000
In-Reply-To: <alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Jim Fehlig <jfehlig@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-users@lists.xen.org, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 14:46 +0000, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Ian Campbell wrote:
> > There is, it's the romfile option to -device e.g.
> >          -device $NICMODEL,vlan=0,romfile=$ROMFILE
> >         
> > where NICMODEL is e100, rtl8139, virtio-blah
> > and ROMFILE is e.g. an ipxe binary.
> 
> I think that option was intended to point QEMU to a different file, not
> to disable the romfile.

romfile="" does that, I think. Or use /dev/null etc etc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:49:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:49:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrT2m-0001I6-QQ; Thu, 20 Nov 2014 14:49:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1XrT2l-0001Hu-7U; Thu, 20 Nov 2014 14:49:11 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	39/C1-02953-66FFD645; Thu, 20 Nov 2014 14:49:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416494948!13765718!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30175 invoked from network); 20 Nov 2014 14:49:09 -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;
	20 Nov 2014 14:49:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193287119"
Message-ID: <1416494946.14429.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Nov 2014 14:49:06 +0000
In-Reply-To: <alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Jim Fehlig <jfehlig@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-users@lists.xen.org, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 14:46 +0000, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Ian Campbell wrote:
> > There is, it's the romfile option to -device e.g.
> >          -device $NICMODEL,vlan=0,romfile=$ROMFILE
> >         
> > where NICMODEL is e100, rtl8139, virtio-blah
> > and ROMFILE is e.g. an ipxe binary.
> 
> I think that option was intended to point QEMU to a different file, not
> to disable the romfile.

romfile="" does that, I think. Or use /dev/null etc etc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:52:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrT68-0001oT-6b; Thu, 20 Nov 2014 14:52:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrT66-0001oK-TE
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:52:39 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	D9/42-02698-6300E645; Thu, 20 Nov 2014 14:52:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416495156!13790830!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20826 invoked from network); 20 Nov 2014 14:52:37 -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;
	20 Nov 2014 14:52:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194822076"
Message-ID: <1416495154.14429.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Nov 2014 14:52:34 +0000
In-Reply-To: <1416474814.29243.59.camel@citrix.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

create ^
title it qemu-upstream: limitation on 4 emulated NICs prevents guest from starting unless PV override is used.
thanks



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:52:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 14:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrT68-0001oT-6b; Thu, 20 Nov 2014 14:52:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrT66-0001oK-TE
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 14:52:39 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	D9/42-02698-6300E645; Thu, 20 Nov 2014 14:52:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416495156!13790830!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20826 invoked from network); 20 Nov 2014 14:52:37 -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;
	20 Nov 2014 14:52:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194822076"
Message-ID: <1416495154.14429.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Nov 2014 14:52:34 +0000
In-Reply-To: <1416474814.29243.59.camel@citrix.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

create ^
title it qemu-upstream: limitation on 4 emulated NICs prevents guest from starting unless PV override is used.
thanks



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:55:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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 1XrT8M-0001zu-QM; Thu, 20 Nov 2014 14:54:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrT8M-0001zo-Ce
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 14:54:58 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	B9/1D-27785-1C00E645; Thu, 20 Nov 2014 14:54:57 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416495296!13805818!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16657 invoked from network); 20 Nov 2014 14:54:57 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 14:54:57 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so3965785wgh.16
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 06:54:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=1bF67xszgA5dVlmKf7dah0prz7Don7dL6/S5pO1XhVw=;
	b=HwoJ41nc5+holb2L1DcLR4bC5KriPoFZgWUQ/5mM2fzkZGh/ZKVSzuUP86thsGr7F7
	XaYGfVjrjvfLzKE1TOHMPwMjLLzzZJqkdNpaftfPQ+LLpWZaHVYwtgDy1TsW3d1SMjU+
	mOQwskb7DmT9GCkEW9cVYfiOQJi9Gkrp3bywrpZ3Zfgtbse0wQpQatobkXgoxgIQfm3L
	biRB6TIdkJw818G17sVHkkWY5/Jf2TLGAa+G/nGyNrP7azx6wxkUFiVb2GUPERk32wME
	fZeGk4DdeLpbfH7PZyi3ORrgZ0AuXxg4eXS9aK6ZiPHTH9ITerYPenZQe0pEHnNpILbT
	3JIw==
X-Gm-Message-State: ALoCoQlyOlNFrwrPL4KQjoE5DXSqheWY5+okdlwSwweV2GibrjuES/5TzPwCbCJb0Vsrkzzvf3xi
X-Received: by 10.194.240.232 with SMTP id wd8mr23279198wjc.135.1416495296097; 
	Thu, 20 Nov 2014 06:54:56 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id pu3sm3699853wjc.14.2014.11.20.06.54.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 06:54:54 -0800 (PST)
Message-ID: <546E00BD.9080007@linaro.org>
Date: Thu, 20 Nov 2014 14:54:53 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416338436-3293-1-git-send-email-julien.grall@linaro.org>
	<546E0AAF02000078000495E0@smtp.nue.novell.com>
In-Reply-To: <546E0AAF02000078000495E0@smtp.nue.novell.com>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	George Dunlap <george.dunlap@eu.citrix.com>, tim@xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC for 4.6] xen: Extend DOMCTL createdomain to
 support arch 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

Hi Jan,

On 11/20/2014 02:37 PM, Jan Beulich wrote:
>>>> On 18.11.14 at 20:20, <julien.grall@linaro.org> wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -540,6 +540,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>      int i, j, e820_warn = 0, bytes = 0;
>>      bool_t acpi_boot_table_init_done = 0;
>>      struct domain *dom0;
>> +    struct arch_domainconfig config;
>>      struct ns16550_defaults ns16550 = {
>>          .data_bits = 8,
>>          .parity    = 'n',
>> @@ -1347,7 +1348,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>          domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
>>  
>>      /* Create initial domain 0. */
>> -    dom0 = domain_create(0, domcr_flags, 0);
>> +    memset(&config, 0, sizeof(config));
>> +    dom0 = domain_create(0, domcr_flags, 0, &config);
> 
> Why not NULL like almost everywhere else?

It was because DOM0 is not a dummy domain.

As it's not use on x86, I could replace by NULL.

>> --- a/xen/include/public/arch-x86/xen.h
>> +++ b/xen/include/public/arch-x86/xen.h
>> @@ -228,6 +228,11 @@ struct arch_shared_info {
>>  };
>>  typedef struct arch_shared_info arch_shared_info_t;
>>  
>> +struct arch_domainconfig {
>> +    char dummy;
>> +};
>> +typedef struct arch_domainconfig arch_domainconfig_t;
> 
> I think we decided that, regardless of all bad precedents, we'd stop
> adding things without xen_ prefix to the public interface. I'm also
> rather uncertain about all these typedef-s - I think we could very
> well get away without adding any new ones (if internally to the
> hypervisor or tools they turn out to make the code much better
> readable, each such component could still introduce one on its own).

Ok. I will drop them and rename the structure to xen_arch_domainconfig;

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 14:55:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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 1XrT8M-0001zu-QM; Thu, 20 Nov 2014 14:54:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrT8M-0001zo-Ce
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 14:54:58 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	B9/1D-27785-1C00E645; Thu, 20 Nov 2014 14:54:57 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416495296!13805818!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16657 invoked from network); 20 Nov 2014 14:54:57 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 14:54:57 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so3965785wgh.16
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 06:54:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=1bF67xszgA5dVlmKf7dah0prz7Don7dL6/S5pO1XhVw=;
	b=HwoJ41nc5+holb2L1DcLR4bC5KriPoFZgWUQ/5mM2fzkZGh/ZKVSzuUP86thsGr7F7
	XaYGfVjrjvfLzKE1TOHMPwMjLLzzZJqkdNpaftfPQ+LLpWZaHVYwtgDy1TsW3d1SMjU+
	mOQwskb7DmT9GCkEW9cVYfiOQJi9Gkrp3bywrpZ3Zfgtbse0wQpQatobkXgoxgIQfm3L
	biRB6TIdkJw818G17sVHkkWY5/Jf2TLGAa+G/nGyNrP7azx6wxkUFiVb2GUPERk32wME
	fZeGk4DdeLpbfH7PZyi3ORrgZ0AuXxg4eXS9aK6ZiPHTH9ITerYPenZQe0pEHnNpILbT
	3JIw==
X-Gm-Message-State: ALoCoQlyOlNFrwrPL4KQjoE5DXSqheWY5+okdlwSwweV2GibrjuES/5TzPwCbCJb0Vsrkzzvf3xi
X-Received: by 10.194.240.232 with SMTP id wd8mr23279198wjc.135.1416495296097; 
	Thu, 20 Nov 2014 06:54:56 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id pu3sm3699853wjc.14.2014.11.20.06.54.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 06:54:54 -0800 (PST)
Message-ID: <546E00BD.9080007@linaro.org>
Date: Thu, 20 Nov 2014 14:54:53 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416338436-3293-1-git-send-email-julien.grall@linaro.org>
	<546E0AAF02000078000495E0@smtp.nue.novell.com>
In-Reply-To: <546E0AAF02000078000495E0@smtp.nue.novell.com>
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	George Dunlap <george.dunlap@eu.citrix.com>, tim@xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC for 4.6] xen: Extend DOMCTL createdomain to
 support arch 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

Hi Jan,

On 11/20/2014 02:37 PM, Jan Beulich wrote:
>>>> On 18.11.14 at 20:20, <julien.grall@linaro.org> wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -540,6 +540,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>      int i, j, e820_warn = 0, bytes = 0;
>>      bool_t acpi_boot_table_init_done = 0;
>>      struct domain *dom0;
>> +    struct arch_domainconfig config;
>>      struct ns16550_defaults ns16550 = {
>>          .data_bits = 8,
>>          .parity    = 'n',
>> @@ -1347,7 +1348,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>          domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
>>  
>>      /* Create initial domain 0. */
>> -    dom0 = domain_create(0, domcr_flags, 0);
>> +    memset(&config, 0, sizeof(config));
>> +    dom0 = domain_create(0, domcr_flags, 0, &config);
> 
> Why not NULL like almost everywhere else?

It was because DOM0 is not a dummy domain.

As it's not use on x86, I could replace by NULL.

>> --- a/xen/include/public/arch-x86/xen.h
>> +++ b/xen/include/public/arch-x86/xen.h
>> @@ -228,6 +228,11 @@ struct arch_shared_info {
>>  };
>>  typedef struct arch_shared_info arch_shared_info_t;
>>  
>> +struct arch_domainconfig {
>> +    char dummy;
>> +};
>> +typedef struct arch_domainconfig arch_domainconfig_t;
> 
> I think we decided that, regardless of all bad precedents, we'd stop
> adding things without xen_ prefix to the public interface. I'm also
> rather uncertain about all these typedef-s - I think we could very
> well get away without adding any new ones (if internally to the
> hypervisor or tools they turn out to make the code much better
> readable, each such component could still introduce one on its own).

Ok. I will drop them and rename the structure to xen_arch_domainconfig;

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:05:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTIp-0002hw-Ky; Thu, 20 Nov 2014 15:05:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bugs@bugs.xenproject.org>)
	id 1XrTIn-0002ho-Sj
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:05:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DB/AF-09842-9430E645; Thu, 20 Nov 2014 15:05:45 +0000
X-Env-Sender: xen-devel-bugs@bugs.xenproject.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416495943!10749882!1
X-Originating-IP: [50.56.82.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9624 invoked from network); 20 Nov 2014 15:05:44 -0000
Received: from bugs.xenproject.org (HELO bugs.xenproject.org) (50.56.82.209)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 20 Nov 2014 15:05:44 -0000
Received: from xen-devel-bugs by bugs.xenproject.org with local (Exim 4.80)
	(envelope-from <xen-devel-bugs@bugs.xenproject.org>)
	id 1XrTRm-0001I5-Rz; Thu, 20 Nov 2014 15:15:02 +0000
Content-Disposition: inline
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
From: xen@bugs.xenproject.org
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Message-ID: <control-reply-1416496502.4963@bugs.xenproject.org>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<1416495154.14429.15.camel@citrix.com>
In-Reply-To: <1416495154.14429.15.camel@citrix.com>
X-Emesinae-Message: control
X-Emesinae-Control-From: Ian Campbell <Ian.Campbell@citrix.com>
X-Emesinae-Control-Number-Commands: 3
Date: Thu, 20 Nov 2014 15:15:02 +0000
Subject: [Xen-devel] Processed: Re: Number of NICs per VM with qemu-upstream
 (Was: Re: Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Processing commands for xen@bugs.xenproject.org:

> create ^
Created new bug #46 rooted at `<1416474814.29243.59.camel@citrix.com>'
Title: `Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re: Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm <emulator> did not work on xen-4.4)'
> title it qemu-upstream: limitation on 4 emulated NICs prevents guest from starting unless PV override is used.
Set title for #46 to `qemu-upstream: limitation on 4 emulated NICs prevents guest from starting unless PV override is used.'
> thanks
Finished processing.

Modified/created Bugs:
 - 46: http://bugs.xenproject.org/xen/bug/46 (new)

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs
Contact xen-bugs-owner@bugs.xenproject.org with any infrastructure issues

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:05:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTIp-0002hw-Ky; Thu, 20 Nov 2014 15:05:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bugs@bugs.xenproject.org>)
	id 1XrTIn-0002ho-Sj
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:05:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DB/AF-09842-9430E645; Thu, 20 Nov 2014 15:05:45 +0000
X-Env-Sender: xen-devel-bugs@bugs.xenproject.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416495943!10749882!1
X-Originating-IP: [50.56.82.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9624 invoked from network); 20 Nov 2014 15:05:44 -0000
Received: from bugs.xenproject.org (HELO bugs.xenproject.org) (50.56.82.209)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 20 Nov 2014 15:05:44 -0000
Received: from xen-devel-bugs by bugs.xenproject.org with local (Exim 4.80)
	(envelope-from <xen-devel-bugs@bugs.xenproject.org>)
	id 1XrTRm-0001I5-Rz; Thu, 20 Nov 2014 15:15:02 +0000
Content-Disposition: inline
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
From: xen@bugs.xenproject.org
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Message-ID: <control-reply-1416496502.4963@bugs.xenproject.org>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<1416495154.14429.15.camel@citrix.com>
In-Reply-To: <1416495154.14429.15.camel@citrix.com>
X-Emesinae-Message: control
X-Emesinae-Control-From: Ian Campbell <Ian.Campbell@citrix.com>
X-Emesinae-Control-Number-Commands: 3
Date: Thu, 20 Nov 2014 15:15:02 +0000
Subject: [Xen-devel] Processed: Re: Number of NICs per VM with qemu-upstream
 (Was: Re: Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Processing commands for xen@bugs.xenproject.org:

> create ^
Created new bug #46 rooted at `<1416474814.29243.59.camel@citrix.com>'
Title: `Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re: Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm <emulator> did not work on xen-4.4)'
> title it qemu-upstream: limitation on 4 emulated NICs prevents guest from starting unless PV override is used.
Set title for #46 to `qemu-upstream: limitation on 4 emulated NICs prevents guest from starting unless PV override is used.'
> thanks
Finished processing.

Modified/created Bugs:
 - 46: http://bugs.xenproject.org/xen/bug/46 (new)

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs
Contact xen-bugs-owner@bugs.xenproject.org with any infrastructure issues

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:23:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTZH-000393-P3; Thu, 20 Nov 2014 15:22:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrTZG-00038y-FJ
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:22:46 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	2A/45-26858-5470E645; Thu, 20 Nov 2014 15:22:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416496959!12698180!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 433 invoked from network); 20 Nov 2014 15:22:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:22:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194836322"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:22:05 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XrTYb-0005Jo-2V; Thu, 20 Nov 2014 15:22:05 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 20 Nov 2014 15:22:00 +0000
Message-ID: <1416496920-31183-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 v2] docs/commandline: Fix formatting
	issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For 'dom0_max_vcpus' and 'hvm_debug', markdown was interpreting the text as
regular text, and reflowing it as a regular paragraph, leading to a single
line as output.  Reformat them as code blocks inside blockquote blocks, which
causes them to take their precise whitespace layout.

For 'psr', the bullet point was incorrectly delineated from paragraph text,
causing it to be reflowed.  Alter the formatting to include the CMT-specific
options as sub-bullets of the overall CMT resource.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>

---
v2: Fix 'psr' formatting errors as well
---
 docs/misc/xen-command-line.markdown |   47 +++++++++++++++++------------------
 1 file changed, 23 insertions(+), 24 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index f054d4b..66d021b 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -475,13 +475,13 @@ defaults of 1 and unlimited respectively are used instead.
 
 For example, with `dom0_max_vcpus=4-8`:
 
-     Number of
-  PCPUs | Dom0 VCPUs
-   2    |  4
-   4    |  4
-   6    |  6
-   8    |  8
-  10    |  8
+>        Number of
+>     PCPUs | Dom0 VCPUs
+>      2    |  4
+>      4    |  4
+>      6    |  6
+>      8    |  8
+>     10    |  8
 
 ### dom0\_mem
 > `= List of ( min:<size> | max:<size> | <size> )`
@@ -684,18 +684,18 @@ supported only when compiled with XSM\_ENABLE=y on x86.
 The specified value is a bit mask with the individual bits having the
 following meaning:
 
-Bit  0 - debug level 0 (unused at present)
-Bit  1 - debug level 1 (Control Register logging)
-Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
-Bit  3 - debug level 3 (unused at present)
-Bit  4 - I/O operation logging
-Bit  5 - vMMU logging
-Bit  6 - vLAPIC general logging
-Bit  7 - vLAPIC timer logging
-Bit  8 - vLAPIC interrupt logging
-Bit  9 - vIOAPIC logging
-Bit 10 - hypercall logging
-Bit 11 - MSR operation logging
+>     Bit  0 - debug level 0 (unused at present)
+>     Bit  1 - debug level 1 (Control Register logging)
+>     Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
+>     Bit  3 - debug level 3 (unused at present)
+>     Bit  4 - I/O operation logging
+>     Bit  5 - vMMU logging
+>     Bit  6 - vLAPIC general logging
+>     Bit  7 - vLAPIC timer logging
+>     Bit  8 - vLAPIC interrupt logging
+>     Bit  9 - vIOAPIC logging
+>     Bit 10 - hypercall logging
+>     Bit 11 - MSR operation logging
 
 Recognized in debug builds of the hypervisor only.
 
@@ -1047,12 +1047,11 @@ resource.  RMID is a hardware-provided layer of abstraction between software
 and logical processors.
 
 The following resources are available:
-* Cache Monitoring Technology (Haswell and later).  Information
-regarding the L3 cache occupancy.
 
-`cmt` instructs Xen to enable/disable Cache Monitoring Technology.
-
-`rmid_max` indicates the max value for rmid.
+* Cache Monitoring Technology (Haswell and later).  Information regarding the
+  L3 cache occupancy.
+  * `cmt` instructs Xen to enable/disable Cache Monitoring Technology.
+  * `rmid_max` indicates the max value for rmid.
 
 ### reboot
 > `= t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]`
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:23:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTZH-000393-P3; Thu, 20 Nov 2014 15:22:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrTZG-00038y-FJ
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:22:46 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	2A/45-26858-5470E645; Thu, 20 Nov 2014 15:22:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416496959!12698180!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 433 invoked from network); 20 Nov 2014 15:22:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:22:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194836322"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:22:05 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XrTYb-0005Jo-2V; Thu, 20 Nov 2014 15:22:05 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 20 Nov 2014 15:22:00 +0000
Message-ID: <1416496920-31183-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 v2] docs/commandline: Fix formatting
	issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For 'dom0_max_vcpus' and 'hvm_debug', markdown was interpreting the text as
regular text, and reflowing it as a regular paragraph, leading to a single
line as output.  Reformat them as code blocks inside blockquote blocks, which
causes them to take their precise whitespace layout.

For 'psr', the bullet point was incorrectly delineated from paragraph text,
causing it to be reflowed.  Alter the formatting to include the CMT-specific
options as sub-bullets of the overall CMT resource.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>

---
v2: Fix 'psr' formatting errors as well
---
 docs/misc/xen-command-line.markdown |   47 +++++++++++++++++------------------
 1 file changed, 23 insertions(+), 24 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index f054d4b..66d021b 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -475,13 +475,13 @@ defaults of 1 and unlimited respectively are used instead.
 
 For example, with `dom0_max_vcpus=4-8`:
 
-     Number of
-  PCPUs | Dom0 VCPUs
-   2    |  4
-   4    |  4
-   6    |  6
-   8    |  8
-  10    |  8
+>        Number of
+>     PCPUs | Dom0 VCPUs
+>      2    |  4
+>      4    |  4
+>      6    |  6
+>      8    |  8
+>     10    |  8
 
 ### dom0\_mem
 > `= List of ( min:<size> | max:<size> | <size> )`
@@ -684,18 +684,18 @@ supported only when compiled with XSM\_ENABLE=y on x86.
 The specified value is a bit mask with the individual bits having the
 following meaning:
 
-Bit  0 - debug level 0 (unused at present)
-Bit  1 - debug level 1 (Control Register logging)
-Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
-Bit  3 - debug level 3 (unused at present)
-Bit  4 - I/O operation logging
-Bit  5 - vMMU logging
-Bit  6 - vLAPIC general logging
-Bit  7 - vLAPIC timer logging
-Bit  8 - vLAPIC interrupt logging
-Bit  9 - vIOAPIC logging
-Bit 10 - hypercall logging
-Bit 11 - MSR operation logging
+>     Bit  0 - debug level 0 (unused at present)
+>     Bit  1 - debug level 1 (Control Register logging)
+>     Bit  2 - debug level 2 (VMX logging of MSR restores when context switching)
+>     Bit  3 - debug level 3 (unused at present)
+>     Bit  4 - I/O operation logging
+>     Bit  5 - vMMU logging
+>     Bit  6 - vLAPIC general logging
+>     Bit  7 - vLAPIC timer logging
+>     Bit  8 - vLAPIC interrupt logging
+>     Bit  9 - vIOAPIC logging
+>     Bit 10 - hypercall logging
+>     Bit 11 - MSR operation logging
 
 Recognized in debug builds of the hypervisor only.
 
@@ -1047,12 +1047,11 @@ resource.  RMID is a hardware-provided layer of abstraction between software
 and logical processors.
 
 The following resources are available:
-* Cache Monitoring Technology (Haswell and later).  Information
-regarding the L3 cache occupancy.
 
-`cmt` instructs Xen to enable/disable Cache Monitoring Technology.
-
-`rmid_max` indicates the max value for rmid.
+* Cache Monitoring Technology (Haswell and later).  Information regarding the
+  L3 cache occupancy.
+  * `cmt` instructs Xen to enable/disable Cache Monitoring Technology.
+  * `rmid_max` indicates the max value for rmid.
 
 ### reboot
 > `= t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]`
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:28:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:28:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTf8-0003Ov-Rf; Thu, 20 Nov 2014 15:28:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrTf7-0003Oq-BJ
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:28:49 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E6/03-09936-0B80E645; Thu, 20 Nov 2014 15:28:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416497324!10756507!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23439 invoked from network); 20 Nov 2014 15:28:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:28:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194838998"
Message-ID: <1416497310.14429.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:28:30 +0000
In-Reply-To: <20141119212505.GJ20440@laptop.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
 updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 16:25 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote:
> > Hi Konrad, I have another release ack request:
> > 
> > Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > > still some places in xenstore are not updated, including:
> > > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> > > This patch series updates /vm/<uuid>/name in xenstore,
> > 
> > This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
> > bugfix which I think should go into Xen 4.5.
> > 
> > The risk WITHOUT this patch is that there are out-of-tree tools which
> > look here for the domain name and will get confused after it is
> > renamed.
> 
> When was this introduced? Did it exist with Xend?

Based on:
 git grep domain\" RELEASE-4.4.0  tools/python/
 git grep domain\' RELEASE-4.4.0 tools/python/
it doesn't appear so, but someone with a xend install would be needed to
confirm for sure.

Given that this has always been wrong for a libxl domain after migration
it seems likely to me that noone is looking at this field.
> 
> > 
> > The risk WITH this patch is that the implementation could be wrong
> > somehow, in which case the code would need to be updated again.  But
> > it's a very small patch and has been fully reviewed.
> 
> I checked QEMU and didn't find anything in there.

Great.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:28:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:28:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTf8-0003Ov-Rf; Thu, 20 Nov 2014 15:28:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrTf7-0003Oq-BJ
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:28:49 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E6/03-09936-0B80E645; Thu, 20 Nov 2014 15:28:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416497324!10756507!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23439 invoked from network); 20 Nov 2014 15:28:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:28:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194838998"
Message-ID: <1416497310.14429.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:28:30 +0000
In-Reply-To: <20141119212505.GJ20440@laptop.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
 updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 16:25 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote:
> > Hi Konrad, I have another release ack request:
> > 
> > Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > > still some places in xenstore are not updated, including:
> > > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> > > This patch series updates /vm/<uuid>/name in xenstore,
> > 
> > This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
> > bugfix which I think should go into Xen 4.5.
> > 
> > The risk WITHOUT this patch is that there are out-of-tree tools which
> > look here for the domain name and will get confused after it is
> > renamed.
> 
> When was this introduced? Did it exist with Xend?

Based on:
 git grep domain\" RELEASE-4.4.0  tools/python/
 git grep domain\' RELEASE-4.4.0 tools/python/
it doesn't appear so, but someone with a xend install would be needed to
confirm for sure.

Given that this has always been wrong for a libxl domain after migration
it seems likely to me that noone is looking at this field.
> 
> > 
> > The risk WITH this patch is that the implementation could be wrong
> > somehow, in which case the code would need to be updated again.  But
> > it's a very small patch and has been fully reviewed.
> 
> I checked QEMU and didn't find anything in there.

Great.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:29:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTfa-0003Rt-7z; Thu, 20 Nov 2014 15:29:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrTfY-0003Rc-3j
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:29:16 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	B4/EA-03148-BC80E645; Thu, 20 Nov 2014 15:29:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416497352!13797538!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 781 invoked from network); 20 Nov 2014 15:29:14 -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;
	20 Nov 2014 15:29:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193305774"
Message-ID: <1416497348.14429.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Thu, 20 Nov 2014 15:29:08 +0000
In-Reply-To: <1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 15:57 -0500, Zhigang Wang wrote:
> Before this patch, pv guest video_memkb is -1, which is an invalid value.
> And it will cause the xenstore 'memory/targe' calculation wrong:
> 
>     memory/target = info->target_memkb - info->video_memkb
> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:29:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTfa-0003Rt-7z; Thu, 20 Nov 2014 15:29:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrTfY-0003Rc-3j
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:29:16 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	B4/EA-03148-BC80E645; Thu, 20 Nov 2014 15:29:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416497352!13797538!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 781 invoked from network); 20 Nov 2014 15:29:14 -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;
	20 Nov 2014 15:29:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193305774"
Message-ID: <1416497348.14429.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Thu, 20 Nov 2014 15:29:08 +0000
In-Reply-To: <1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 15:57 -0500, Zhigang Wang wrote:
> Before this patch, pv guest video_memkb is -1, which is an invalid value.
> And it will cause the xenstore 'memory/targe' calculation wrong:
> 
>     memory/target = info->target_memkb - info->video_memkb
> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:29:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15: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 1XrTgE-0003YA-LM; Thu, 20 Nov 2014 15:29:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrTgE-0003Xy-4Q
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:29:58 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	E2/7B-02696-5F80E645; Thu, 20 Nov 2014 15:29:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416497394!13777663!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15824 invoked from network); 20 Nov 2014 15:29:56 -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;
	20 Nov 2014 15:29:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193306013"
Message-ID: <1416497391.14429.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 20 Nov 2014 15:29:51 +0000
In-Reply-To: <20141119212434.GB27349@zion.uk.xensource.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
	<20141119210845.GF20440@laptop.dumpdata.com>
	<20141119212434.GB27349@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Zhigang Wang <zhigang.x.wang@oracle.com>,
	ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 21:24 +0000, Wei Liu wrote:
> On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > > And it will cause the xenstore 'memory/targe' calculation wrong:
> > > 
> > >     memory/target = info->target_memkb - info->video_memkb
> > 
> > CC-ing the maintainers.
> > 
> > Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?
> > 
> 
> I don't think this is a regression, it has been broken for quite a
> while.

I think so to.

On the other hand its a pretty clear bug to use video_memkb == -1 and
we've seen that it causes real issues. The fix is also fairly obvious.
I'm inclined towards suggesting we fix this in 4.5.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:29:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15: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 1XrTgE-0003YA-LM; Thu, 20 Nov 2014 15:29:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrTgE-0003Xy-4Q
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:29:58 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	E2/7B-02696-5F80E645; Thu, 20 Nov 2014 15:29:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416497394!13777663!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15824 invoked from network); 20 Nov 2014 15:29:56 -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;
	20 Nov 2014 15:29:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193306013"
Message-ID: <1416497391.14429.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 20 Nov 2014 15:29:51 +0000
In-Reply-To: <20141119212434.GB27349@zion.uk.xensource.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
	<20141119210845.GF20440@laptop.dumpdata.com>
	<20141119212434.GB27349@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Zhigang Wang <zhigang.x.wang@oracle.com>,
	ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 21:24 +0000, Wei Liu wrote:
> On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > > And it will cause the xenstore 'memory/targe' calculation wrong:
> > > 
> > >     memory/target = info->target_memkb - info->video_memkb
> > 
> > CC-ing the maintainers.
> > 
> > Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?
> > 
> 
> I don't think this is a regression, it has been broken for quite a
> while.

I think so to.

On the other hand its a pretty clear bug to use video_memkb == -1 and
we've seen that it causes real issues. The fix is also fairly obvious.
I'm inclined towards suggesting we fix this in 4.5.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:37:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTnO-0003t9-MD; Thu, 20 Nov 2014 15:37:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrTnN-0003t4-CT
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:37:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E6/3D-25276-0BA0E645; Thu, 20 Nov 2014 15:37:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416497838!14219519!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12496 invoked from network); 20 Nov 2014 15:37:18 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 15:37:18 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 16:37:18 +0100
Message-Id: <546E18BD020000780004966B@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 16:37:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
	<20141120113458.GC91061@deinos.phlegethon.org>
	<546DF69E0200007800049579@smtp.nue.novell.com>
In-Reply-To: <546DF69E0200007800049579@smtp.nue.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE5D0D2BD.0__="
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH v2 3/3] x86/HVM: don't crash guest upon problems
 occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE5D0D2BD.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
exit occurred in guest kernel mode") to a few more cases, including the
failed VM entry one that XSA-110 was needed to be issued for.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: - s/crash_or_gp/crash_or_fault/
    - drop changes to svm_do_nested_pgfault(), svm_vmexit_handler()'s
      VMEXIT_NPF handling, and ept_handle_violation()

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
 static uint64_t osvw_length, osvw_status;
 static DEFINE_SPINLOCK(osvw_lock);
=20
+/* Only crash the guest if the problem originates in kernel mode. */
+static void svm_crash_or_fault(struct vcpu *v)
+{
+    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
+    else
+        domain_crash(v->domain);
+}
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int =
inst_len)
 {
     struct vcpu *curr =3D current;
@@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
     if ( unlikely(inst_len > 15) )
     {
         gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);
-        domain_crash(curr->domain);
+        svm_crash_or_fault(curr);
         return;
     }
=20
@@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
                  "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",
                  exit_reason,=20
                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
-        if ( vmcb_get_cpl(vmcb) )
-            hvm_inject_hw_exception(TRAP_invalid_op,
-                                    HVM_DELIVER_NO_ERROR_CODE);
-        else
-            domain_crash(v->domain);
+        svm_crash_or_fault(v);
         break;
     }
=20
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
=20
+/* Only crash the guest if the problem originates in kernel mode. */
+static void vmx_crash_or_fault(struct vcpu *v)
+{
+    struct segment_register ss;
+
+    vmx_get_segment_register(v, x86_seg_ss, &ss);
+    if ( ss.attr.fields.dpl )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
+    else
+        domain_crash(v->domain);
+}
+
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
=20
 static const u32 msr_index[] =3D
@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned=20
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
=20
-    domain_crash(curr->domain);
+    vmx_crash_or_fault(curr);
 }
=20
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        {
-            struct segment_register ss;
-
-            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
-                     exit_reason);
-
-            vmx_get_segment_register(v, x86_seg_ss, &ss);
-            if ( ss.attr.fields.dpl )
-                hvm_inject_hw_exception(TRAP_invalid_op,
-                                        HVM_DELIVER_NO_ERROR_CODE);
-            else
-                domain_crash(v->domain);
-        }
+        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason=
);
+        vmx_crash_or_fault(v);
         break;
     }
=20




--=__PartE5D0D2BD.0__=
Content-Type: text/plain; name="x86-HVM-dont-crash-guest-in-user-mode.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-dont-crash-guest-in-user-mode.patch"

x86/HVM: don't crash guest upon problems occurring in user mode=0A=0AThis =
extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM=0Aexit =
occurred in guest kernel mode") to a few more cases, including the=0Afailed=
 VM entry one that XSA-110 was needed to be issued for.=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A---=0Av2: - s/crash_or_gp/crash_or_fault=
/=0A    - drop changes to svm_do_nested_pgfault(), svm_vmexit_handler()'s=
=0A      VMEXIT_NPF handling, and ept_handle_violation()=0A=0A--- =
a/xen/arch/x86/hvm/svm/svm.c=0A+++ b/xen/arch/x86/hvm/svm/svm.c=0A@@ -90,6 =
+90,15 @@ static bool_t amd_erratum383_found __rea=0A static uint64_t =
osvw_length, osvw_status;=0A static DEFINE_SPINLOCK(osvw_lock);=0A =0A+/* =
Only crash the guest if the problem originates in kernel mode. */=0A+static=
 void svm_crash_or_fault(struct vcpu *v)=0A+{=0A+    if ( vmcb_get_cpl(v->a=
rch.hvm_svm.vmcb) )=0A+        hvm_inject_hw_exception(TRAP_invalid_op, =
HVM_DELIVER_NO_ERROR_CODE);=0A+    else=0A+        domain_crash(v->domain);=
=0A+}=0A+=0A void __update_guest_eip(struct cpu_user_regs *regs, unsigned =
int inst_len)=0A {=0A     struct vcpu *curr =3D current;=0A@@ -100,7 =
+109,7 @@ void __update_guest_eip(struct cpu_user_=0A     if ( unlikely(ins=
t_len > 15) )=0A     {=0A         gdprintk(XENLOG_ERR, "Bad instruction =
length %u\n", inst_len);=0A-        domain_crash(curr->domain);=0A+        =
svm_crash_or_fault(curr);=0A         return;=0A     }=0A =0A@@ -2680,11 =
+2689,7 @@ void svm_vmexit_handler(struct cpu_user_=0A                  =
"exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",=0A                 =
 exit_reason, =0A                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinf=
o2);=0A-        if ( vmcb_get_cpl(vmcb) )=0A-            hvm_inject_hw_exce=
ption(TRAP_invalid_op,=0A-                                    HVM_DELIVER_N=
O_ERROR_CODE);=0A-        else=0A-            domain_crash(v->domain);=0A+ =
       svm_crash_or_fault(v);=0A         break;=0A     }=0A =0A--- =
a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ =
-134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu=0A     =
passive_domain_destroy(v);=0A }=0A =0A+/* Only crash the guest if the =
problem originates in kernel mode. */=0A+static void vmx_crash_or_fault(str=
uct vcpu *v)=0A+{=0A+    struct segment_register ss;=0A+=0A+    vmx_get_seg=
ment_register(v, x86_seg_ss, &ss);=0A+    if ( ss.attr.fields.dpl )=0A+    =
    hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);=0A=
+    else=0A+        domain_crash(v->domain);=0A+}=0A+=0A static DEFINE_PER=
_CPU(struct vmx_msr_state, host_msr_state);=0A =0A static const u32 =
msr_index[] =3D=0A@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsi=
gned =0A     vmcs_dump_vcpu(curr);=0A     printk("*************************=
*************\n");=0A =0A-    domain_crash(curr->domain);=0A+    vmx_crash_=
or_fault(curr);=0A }=0A =0A void vmx_enter_realmode(struct cpu_user_regs =
*regs)=0A@@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_=0A=
     /* fall through */=0A     default:=0A     exit_and_crash:=0A-        =
{=0A-            struct segment_register ss;=0A-=0A-            gdprintk(XE=
NLOG_WARNING, "Bad vmexit (reason %#lx)\n",=0A-                     =
exit_reason);=0A-=0A-            vmx_get_segment_register(v, x86_seg_ss, =
&ss);=0A-            if ( ss.attr.fields.dpl )=0A-                =
hvm_inject_hw_exception(TRAP_invalid_op,=0A-                               =
         HVM_DELIVER_NO_ERROR_CODE);=0A-            else=0A-               =
 domain_crash(v->domain);=0A-        }=0A+        gdprintk(XENLOG_WARNING, =
"Bad vmexit (reason %#lx)\n", exit_reason);=0A+        vmx_crash_or_fault(v=
);=0A         break;=0A     }=0A =0A
--=__PartE5D0D2BD.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

--=__PartE5D0D2BD.0__=--


From xen-devel-bounces@lists.xen.org Thu Nov 20 15:37:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTnO-0003t9-MD; Thu, 20 Nov 2014 15:37:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrTnN-0003t4-CT
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:37:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E6/3D-25276-0BA0E645; Thu, 20 Nov 2014 15:37:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416497838!14219519!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12496 invoked from network); 20 Nov 2014 15:37:18 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 15:37:18 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Thu, 20 Nov 2014 16:37:18 +0100
Message-Id: <546E18BD020000780004966B@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 20 Nov 2014 16:37:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
	<20141120113458.GC91061@deinos.phlegethon.org>
	<546DF69E0200007800049579@smtp.nue.novell.com>
In-Reply-To: <546DF69E0200007800049579@smtp.nue.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE5D0D2BD.0__="
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH v2 3/3] x86/HVM: don't crash guest upon problems
 occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE5D0D2BD.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
exit occurred in guest kernel mode") to a few more cases, including the
failed VM entry one that XSA-110 was needed to be issued for.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: - s/crash_or_gp/crash_or_fault/
    - drop changes to svm_do_nested_pgfault(), svm_vmexit_handler()'s
      VMEXIT_NPF handling, and ept_handle_violation()

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
 static uint64_t osvw_length, osvw_status;
 static DEFINE_SPINLOCK(osvw_lock);
=20
+/* Only crash the guest if the problem originates in kernel mode. */
+static void svm_crash_or_fault(struct vcpu *v)
+{
+    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
+    else
+        domain_crash(v->domain);
+}
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int =
inst_len)
 {
     struct vcpu *curr =3D current;
@@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
     if ( unlikely(inst_len > 15) )
     {
         gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);
-        domain_crash(curr->domain);
+        svm_crash_or_fault(curr);
         return;
     }
=20
@@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
                  "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",
                  exit_reason,=20
                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
-        if ( vmcb_get_cpl(vmcb) )
-            hvm_inject_hw_exception(TRAP_invalid_op,
-                                    HVM_DELIVER_NO_ERROR_CODE);
-        else
-            domain_crash(v->domain);
+        svm_crash_or_fault(v);
         break;
     }
=20
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
=20
+/* Only crash the guest if the problem originates in kernel mode. */
+static void vmx_crash_or_fault(struct vcpu *v)
+{
+    struct segment_register ss;
+
+    vmx_get_segment_register(v, x86_seg_ss, &ss);
+    if ( ss.attr.fields.dpl )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
+    else
+        domain_crash(v->domain);
+}
+
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
=20
 static const u32 msr_index[] =3D
@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned=20
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
=20
-    domain_crash(curr->domain);
+    vmx_crash_or_fault(curr);
 }
=20
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        {
-            struct segment_register ss;
-
-            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
-                     exit_reason);
-
-            vmx_get_segment_register(v, x86_seg_ss, &ss);
-            if ( ss.attr.fields.dpl )
-                hvm_inject_hw_exception(TRAP_invalid_op,
-                                        HVM_DELIVER_NO_ERROR_CODE);
-            else
-                domain_crash(v->domain);
-        }
+        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason=
);
+        vmx_crash_or_fault(v);
         break;
     }
=20




--=__PartE5D0D2BD.0__=
Content-Type: text/plain; name="x86-HVM-dont-crash-guest-in-user-mode.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-dont-crash-guest-in-user-mode.patch"

x86/HVM: don't crash guest upon problems occurring in user mode=0A=0AThis =
extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM=0Aexit =
occurred in guest kernel mode") to a few more cases, including the=0Afailed=
 VM entry one that XSA-110 was needed to be issued for.=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A---=0Av2: - s/crash_or_gp/crash_or_fault=
/=0A    - drop changes to svm_do_nested_pgfault(), svm_vmexit_handler()'s=
=0A      VMEXIT_NPF handling, and ept_handle_violation()=0A=0A--- =
a/xen/arch/x86/hvm/svm/svm.c=0A+++ b/xen/arch/x86/hvm/svm/svm.c=0A@@ -90,6 =
+90,15 @@ static bool_t amd_erratum383_found __rea=0A static uint64_t =
osvw_length, osvw_status;=0A static DEFINE_SPINLOCK(osvw_lock);=0A =0A+/* =
Only crash the guest if the problem originates in kernel mode. */=0A+static=
 void svm_crash_or_fault(struct vcpu *v)=0A+{=0A+    if ( vmcb_get_cpl(v->a=
rch.hvm_svm.vmcb) )=0A+        hvm_inject_hw_exception(TRAP_invalid_op, =
HVM_DELIVER_NO_ERROR_CODE);=0A+    else=0A+        domain_crash(v->domain);=
=0A+}=0A+=0A void __update_guest_eip(struct cpu_user_regs *regs, unsigned =
int inst_len)=0A {=0A     struct vcpu *curr =3D current;=0A@@ -100,7 =
+109,7 @@ void __update_guest_eip(struct cpu_user_=0A     if ( unlikely(ins=
t_len > 15) )=0A     {=0A         gdprintk(XENLOG_ERR, "Bad instruction =
length %u\n", inst_len);=0A-        domain_crash(curr->domain);=0A+        =
svm_crash_or_fault(curr);=0A         return;=0A     }=0A =0A@@ -2680,11 =
+2689,7 @@ void svm_vmexit_handler(struct cpu_user_=0A                  =
"exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",=0A                 =
 exit_reason, =0A                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinf=
o2);=0A-        if ( vmcb_get_cpl(vmcb) )=0A-            hvm_inject_hw_exce=
ption(TRAP_invalid_op,=0A-                                    HVM_DELIVER_N=
O_ERROR_CODE);=0A-        else=0A-            domain_crash(v->domain);=0A+ =
       svm_crash_or_fault(v);=0A         break;=0A     }=0A =0A--- =
a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ =
-134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu=0A     =
passive_domain_destroy(v);=0A }=0A =0A+/* Only crash the guest if the =
problem originates in kernel mode. */=0A+static void vmx_crash_or_fault(str=
uct vcpu *v)=0A+{=0A+    struct segment_register ss;=0A+=0A+    vmx_get_seg=
ment_register(v, x86_seg_ss, &ss);=0A+    if ( ss.attr.fields.dpl )=0A+    =
    hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);=0A=
+    else=0A+        domain_crash(v->domain);=0A+}=0A+=0A static DEFINE_PER=
_CPU(struct vmx_msr_state, host_msr_state);=0A =0A static const u32 =
msr_index[] =3D=0A@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsi=
gned =0A     vmcs_dump_vcpu(curr);=0A     printk("*************************=
*************\n");=0A =0A-    domain_crash(curr->domain);=0A+    vmx_crash_=
or_fault(curr);=0A }=0A =0A void vmx_enter_realmode(struct cpu_user_regs =
*regs)=0A@@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_=0A=
     /* fall through */=0A     default:=0A     exit_and_crash:=0A-        =
{=0A-            struct segment_register ss;=0A-=0A-            gdprintk(XE=
NLOG_WARNING, "Bad vmexit (reason %#lx)\n",=0A-                     =
exit_reason);=0A-=0A-            vmx_get_segment_register(v, x86_seg_ss, =
&ss);=0A-            if ( ss.attr.fields.dpl )=0A-                =
hvm_inject_hw_exception(TRAP_invalid_op,=0A-                               =
         HVM_DELIVER_NO_ERROR_CODE);=0A-            else=0A-               =
 domain_crash(v->domain);=0A-        }=0A+        gdprintk(XENLOG_WARNING, =
"Bad vmexit (reason %#lx)\n", exit_reason);=0A+        vmx_crash_or_fault(v=
);=0A         break;=0A     }=0A =0A
--=__PartE5D0D2BD.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

--=__PartE5D0D2BD.0__=--


From xen-devel-bounces@lists.xen.org Thu Nov 20 15:41:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTrC-00045G-GT; Thu, 20 Nov 2014 15:41:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XrTrB-00045A-5l
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:41:17 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9E/1F-24859-C9B0E645; Thu, 20 Nov 2014 15:41:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416498075!12702462!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8929 invoked from network); 20 Nov 2014 15:41:16 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 15:41:16 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XrTqw-0003W4-Ki; Thu, 20 Nov 2014 15:41:02 +0000
Date: Thu, 20 Nov 2014 16:41:02 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141120154102.GE91061@deinos.phlegethon.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
	<20141120113458.GC91061@deinos.phlegethon.org>
	<546DF69E0200007800049579@smtp.nue.novell.com>
	<546E18BD020000780004966B@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546E18BD020000780004966B@smtp.nue.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:37 +0100 on 20 Nov (1416497837), Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
> exit occurred in guest kernel mode") to a few more cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:41:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTrC-00045G-GT; Thu, 20 Nov 2014 15:41:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XrTrB-00045A-5l
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:41:17 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9E/1F-24859-C9B0E645; Thu, 20 Nov 2014 15:41:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416498075!12702462!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8929 invoked from network); 20 Nov 2014 15:41:16 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 15:41:16 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XrTqw-0003W4-Ki; Thu, 20 Nov 2014 15:41:02 +0000
Date: Thu, 20 Nov 2014 16:41:02 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141120154102.GE91061@deinos.phlegethon.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCCC202000078000493F8@smtp.nue.novell.com>
	<20141120113458.GC91061@deinos.phlegethon.org>
	<546DF69E0200007800049579@smtp.nue.novell.com>
	<546E18BD020000780004966B@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546E18BD020000780004966B@smtp.nue.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:37 +0100 on 20 Nov (1416497837), Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
> exit occurred in guest kernel mode") to a few more cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:42:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15: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 1XrTs1-00049n-US; Thu, 20 Nov 2014 15:42:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrTs0-00049c-Nb
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:42:08 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	CF/27-27785-FCB0E645; Thu, 20 Nov 2014 15:42:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416498124!13797189!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24125 invoked from network); 20 Nov 2014 15:42:06 -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;
	20 Nov 2014 15:42:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; 
	d="scan'208,217";a="194845271"
Message-ID: <546E0BCA.5080902@citrix.com>
Date: Thu, 20 Nov 2014 15:42:02 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>	<546DCCC202000078000493F8@smtp.nue.novell.com>	<20141120113458.GC91061@deinos.phlegethon.org>	<546DF69E0200007800049579@smtp.nue.novell.com>
	<546E18BD020000780004966B@smtp.nue.novell.com>
In-Reply-To: <546E18BD020000780004966B@smtp.nue.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9160022290349708393=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9160022290349708393==
Content-Type: multipart/alternative;
	boundary="------------020900000200060000010206"

--------------020900000200060000010206
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit

On 20/11/14 15:37, Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
> exit occurred in guest kernel mode") to a few more cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
> v2: - s/crash_or_gp/crash_or_fault/
>     - drop changes to svm_do_nested_pgfault(), svm_vmexit_handler()'s
>       VMEXIT_NPF handling, and ept_handle_violation()
>
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
>  static uint64_t osvw_length, osvw_status;
>  static DEFINE_SPINLOCK(osvw_lock);
>  
> +/* Only crash the guest if the problem originates in kernel mode. */
> +static void svm_crash_or_fault(struct vcpu *v)
> +{
> +    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> +    else
> +        domain_crash(v->domain);
> +}
> +
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
>  {
>      struct vcpu *curr = current;
> @@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
>      if ( unlikely(inst_len > 15) )
>      {
>          gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);
> -        domain_crash(curr->domain);
> +        svm_crash_or_fault(curr);
>          return;
>      }
>  
> @@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
>                   "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
>                   exit_reason, 
>                   (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
> -        if ( vmcb_get_cpl(vmcb) )
> -            hvm_inject_hw_exception(TRAP_invalid_op,
> -                                    HVM_DELIVER_NO_ERROR_CODE);
> -        else
> -            domain_crash(v->domain);
> +        svm_crash_or_fault(v);
>          break;
>      }
>  
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
>      passive_domain_destroy(v);
>  }
>  
> +/* Only crash the guest if the problem originates in kernel mode. */
> +static void vmx_crash_or_fault(struct vcpu *v)
> +{
> +    struct segment_register ss;
> +
> +    vmx_get_segment_register(v, x86_seg_ss, &ss);
> +    if ( ss.attr.fields.dpl )
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> +    else
> +        domain_crash(v->domain);
> +}
> +
>  static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
>  
>  static const u32 msr_index[] =
> @@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned 
>      vmcs_dump_vcpu(curr);
>      printk("**************************************\n");
>  
> -    domain_crash(curr->domain);
> +    vmx_crash_or_fault(curr);
>  }
>  
>  void vmx_enter_realmode(struct cpu_user_regs *regs)
> @@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
>      /* fall through */
>      default:
>      exit_and_crash:
> -        {
> -            struct segment_register ss;
> -
> -            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
> -                     exit_reason);
> -
> -            vmx_get_segment_register(v, x86_seg_ss, &ss);
> -            if ( ss.attr.fields.dpl )
> -                hvm_inject_hw_exception(TRAP_invalid_op,
> -                                        HVM_DELIVER_NO_ERROR_CODE);
> -            else
> -                domain_crash(v->domain);
> -        }
> +        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);
> +        vmx_crash_or_fault(v);
>          break;
>      }
>  
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------020900000200060000010206
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 20/11/14 15:37, Jan Beulich wrote:<br>
    </div>
    <blockquote cite="mid:546E18BD020000780004966B@smtp.nue.novell.com"
      type="cite">
      <pre wrap="">This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
exit occurred in guest kernel mode") to a few more cases, including the
failed VM entry one that XSA-110 was needed to be issued for.

Signed-off-by: Jan Beulich <a class="moz-txt-link-rfc2396E" href="mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a></pre>
    </blockquote>
    <br>
    Reviewed-by: Andrew Cooper <a class="moz-txt-link-rfc2396E" href="mailto:andrew.cooper3@citrix.com">&lt;andrew.cooper3@citrix.com&gt;</a><br>
    <br>
    <blockquote cite="mid:546E18BD020000780004966B@smtp.nue.novell.com"
      type="cite">
      <pre wrap="">
---
v2: - s/crash_or_gp/crash_or_fault/
    - drop changes to svm_do_nested_pgfault(), svm_vmexit_handler()'s
      VMEXIT_NPF handling, and ept_handle_violation()

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
 static uint64_t osvw_length, osvw_status;
 static DEFINE_SPINLOCK(osvw_lock);
 
+/* Only crash the guest if the problem originates in kernel mode. */
+static void svm_crash_or_fault(struct vcpu *v)
+{
+    if ( vmcb_get_cpl(v-&gt;arch.hvm_svm.vmcb) )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+    else
+        domain_crash(v-&gt;domain);
+}
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
     if ( unlikely(inst_len &gt; 15) )
     {
         gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);
-        domain_crash(curr-&gt;domain);
+        svm_crash_or_fault(curr);
         return;
     }
 
@@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
                  "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
                  exit_reason, 
                  (u64)vmcb-&gt;exitinfo1, (u64)vmcb-&gt;exitinfo2);
-        if ( vmcb_get_cpl(vmcb) )
-            hvm_inject_hw_exception(TRAP_invalid_op,
-                                    HVM_DELIVER_NO_ERROR_CODE);
-        else
-            domain_crash(v-&gt;domain);
+        svm_crash_or_fault(v);
         break;
     }
 
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
 
+/* Only crash the guest if the problem originates in kernel mode. */
+static void vmx_crash_or_fault(struct vcpu *v)
+{
+    struct segment_register ss;
+
+    vmx_get_segment_register(v, x86_seg_ss, &amp;ss);
+    if ( ss.attr.fields.dpl )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+    else
+        domain_crash(v-&gt;domain);
+}
+
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
 
 static const u32 msr_index[] =
@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned 
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
 
-    domain_crash(curr-&gt;domain);
+    vmx_crash_or_fault(curr);
 }
 
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        {
-            struct segment_register ss;
-
-            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
-                     exit_reason);
-
-            vmx_get_segment_register(v, x86_seg_ss, &amp;ss);
-            if ( ss.attr.fields.dpl )
-                hvm_inject_hw_exception(TRAP_invalid_op,
-                                        HVM_DELIVER_NO_ERROR_CODE);
-            else
-                domain_crash(v-&gt;domain);
-        }
+        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);
+        vmx_crash_or_fault(v);
         break;
     }
 



</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------020900000200060000010206--


--===============9160022290349708393==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9160022290349708393==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 15:42:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15: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 1XrTs1-00049n-US; Thu, 20 Nov 2014 15:42:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrTs0-00049c-Nb
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:42:08 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	CF/27-27785-FCB0E645; Thu, 20 Nov 2014 15:42:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416498124!13797189!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24125 invoked from network); 20 Nov 2014 15:42:06 -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;
	20 Nov 2014 15:42:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; 
	d="scan'208,217";a="194845271"
Message-ID: <546E0BCA.5080902@citrix.com>
Date: Thu, 20 Nov 2014 15:42:02 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>	<546DCCC202000078000493F8@smtp.nue.novell.com>	<20141120113458.GC91061@deinos.phlegethon.org>	<546DF69E0200007800049579@smtp.nue.novell.com>
	<546E18BD020000780004966B@smtp.nue.novell.com>
In-Reply-To: <546E18BD020000780004966B@smtp.nue.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/HVM: don't crash guest upon
 problems occurring in user mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9160022290349708393=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9160022290349708393==
Content-Type: multipart/alternative;
	boundary="------------020900000200060000010206"

--------------020900000200060000010206
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit

On 20/11/14 15:37, Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
> exit occurred in guest kernel mode") to a few more cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
> v2: - s/crash_or_gp/crash_or_fault/
>     - drop changes to svm_do_nested_pgfault(), svm_vmexit_handler()'s
>       VMEXIT_NPF handling, and ept_handle_violation()
>
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
>  static uint64_t osvw_length, osvw_status;
>  static DEFINE_SPINLOCK(osvw_lock);
>  
> +/* Only crash the guest if the problem originates in kernel mode. */
> +static void svm_crash_or_fault(struct vcpu *v)
> +{
> +    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> +    else
> +        domain_crash(v->domain);
> +}
> +
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
>  {
>      struct vcpu *curr = current;
> @@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
>      if ( unlikely(inst_len > 15) )
>      {
>          gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);
> -        domain_crash(curr->domain);
> +        svm_crash_or_fault(curr);
>          return;
>      }
>  
> @@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
>                   "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
>                   exit_reason, 
>                   (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
> -        if ( vmcb_get_cpl(vmcb) )
> -            hvm_inject_hw_exception(TRAP_invalid_op,
> -                                    HVM_DELIVER_NO_ERROR_CODE);
> -        else
> -            domain_crash(v->domain);
> +        svm_crash_or_fault(v);
>          break;
>      }
>  
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
>      passive_domain_destroy(v);
>  }
>  
> +/* Only crash the guest if the problem originates in kernel mode. */
> +static void vmx_crash_or_fault(struct vcpu *v)
> +{
> +    struct segment_register ss;
> +
> +    vmx_get_segment_register(v, x86_seg_ss, &ss);
> +    if ( ss.attr.fields.dpl )
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> +    else
> +        domain_crash(v->domain);
> +}
> +
>  static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
>  
>  static const u32 msr_index[] =
> @@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned 
>      vmcs_dump_vcpu(curr);
>      printk("**************************************\n");
>  
> -    domain_crash(curr->domain);
> +    vmx_crash_or_fault(curr);
>  }
>  
>  void vmx_enter_realmode(struct cpu_user_regs *regs)
> @@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
>      /* fall through */
>      default:
>      exit_and_crash:
> -        {
> -            struct segment_register ss;
> -
> -            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
> -                     exit_reason);
> -
> -            vmx_get_segment_register(v, x86_seg_ss, &ss);
> -            if ( ss.attr.fields.dpl )
> -                hvm_inject_hw_exception(TRAP_invalid_op,
> -                                        HVM_DELIVER_NO_ERROR_CODE);
> -            else
> -                domain_crash(v->domain);
> -        }
> +        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);
> +        vmx_crash_or_fault(v);
>          break;
>      }
>  
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------020900000200060000010206
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 20/11/14 15:37, Jan Beulich wrote:<br>
    </div>
    <blockquote cite="mid:546E18BD020000780004966B@smtp.nue.novell.com"
      type="cite">
      <pre wrap="">This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
exit occurred in guest kernel mode") to a few more cases, including the
failed VM entry one that XSA-110 was needed to be issued for.

Signed-off-by: Jan Beulich <a class="moz-txt-link-rfc2396E" href="mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a></pre>
    </blockquote>
    <br>
    Reviewed-by: Andrew Cooper <a class="moz-txt-link-rfc2396E" href="mailto:andrew.cooper3@citrix.com">&lt;andrew.cooper3@citrix.com&gt;</a><br>
    <br>
    <blockquote cite="mid:546E18BD020000780004966B@smtp.nue.novell.com"
      type="cite">
      <pre wrap="">
---
v2: - s/crash_or_gp/crash_or_fault/
    - drop changes to svm_do_nested_pgfault(), svm_vmexit_handler()'s
      VMEXIT_NPF handling, and ept_handle_violation()

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
 static uint64_t osvw_length, osvw_status;
 static DEFINE_SPINLOCK(osvw_lock);
 
+/* Only crash the guest if the problem originates in kernel mode. */
+static void svm_crash_or_fault(struct vcpu *v)
+{
+    if ( vmcb_get_cpl(v-&gt;arch.hvm_svm.vmcb) )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+    else
+        domain_crash(v-&gt;domain);
+}
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
     if ( unlikely(inst_len &gt; 15) )
     {
         gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);
-        domain_crash(curr-&gt;domain);
+        svm_crash_or_fault(curr);
         return;
     }
 
@@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
                  "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
                  exit_reason, 
                  (u64)vmcb-&gt;exitinfo1, (u64)vmcb-&gt;exitinfo2);
-        if ( vmcb_get_cpl(vmcb) )
-            hvm_inject_hw_exception(TRAP_invalid_op,
-                                    HVM_DELIVER_NO_ERROR_CODE);
-        else
-            domain_crash(v-&gt;domain);
+        svm_crash_or_fault(v);
         break;
     }
 
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
 
+/* Only crash the guest if the problem originates in kernel mode. */
+static void vmx_crash_or_fault(struct vcpu *v)
+{
+    struct segment_register ss;
+
+    vmx_get_segment_register(v, x86_seg_ss, &amp;ss);
+    if ( ss.attr.fields.dpl )
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
+    else
+        domain_crash(v-&gt;domain);
+}
+
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
 
 static const u32 msr_index[] =
@@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned 
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
 
-    domain_crash(curr-&gt;domain);
+    vmx_crash_or_fault(curr);
 }
 
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        {
-            struct segment_register ss;
-
-            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
-                     exit_reason);
-
-            vmx_get_segment_register(v, x86_seg_ss, &amp;ss);
-            if ( ss.attr.fields.dpl )
-                hvm_inject_hw_exception(TRAP_invalid_op,
-                                        HVM_DELIVER_NO_ERROR_CODE);
-            else
-                domain_crash(v-&gt;domain);
-        }
+        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);
+        vmx_crash_or_fault(v);
         break;
     }
 



</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------020900000200060000010206--


--===============9160022290349708393==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9160022290349708393==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 15:47:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15: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 1XrTx2-0004Tz-P6; Thu, 20 Nov 2014 15:47:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrTx1-0004Tu-5h
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:47:19 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	8D/CA-18267-60D0E645; Thu, 20 Nov 2014 15:47:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416498435!12704002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21770 invoked from network); 20 Nov 2014 15:47:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:47:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194847241"
Message-ID: <1416498424.14429.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 20 Nov 2014 15:47:04 +0000
In-Reply-To: <5469EBE5.4070209@eu.citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
	<1415963574.7113.7.camel@citrix.com> <5469EBE5.4070209@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 12:36 +0000, George Dunlap wrote:
> On 11/14/2014 11:12 AM, Ian Campbell wrote:
> > On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
> >> Return proper error codes on failure so that scripts can tell whether
> >> the command completed properly or not.
> >>
> >> Also while we're at it, normalize init and dispose of
> >> libxl_device_disk structures.  This means calling init and dispose in
> >> the actual functions where they are declared.
> >>
> >> This in turn means changing parse_disk_config_multistring() to not
> >> call libxl_device_disk_init.  And that in turn means changes to
> >> callers of parse_disk_config().
> >>
> >> It also means removing libxl_device_disk_init() from
> >> libxl.c:libxl_vdev_to_device_disk().  This is only called from
> >> xl_cmdimpl.c.
> >>
> >> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> >> ---
> >> CC: Ian Campbell <ian.campbell@citrix.com>
> >> CC: Ian Jackson <ian.jackson@citrix.com>
> >> CC: Wei Liu <wei.liu2@citrix.com>
> >> CC: Konrad Wilk <konrad.wilk@oracle.com>
> >>
> >> Release justification: This is a bug fix.  It's a fairly minor one,
> >> but it's also a very simple one.
> >>
> >> v2:
> >>   - Restructure functions to make sure init and dispose are properly
> >>   called.
> > Sadly this bit has somewhat reduced the truth of the second half of your
> > release justification, since the patch is a fair bit more subtle though.
> > Although IMHO it hasn't invalidated the case for taking the patch for
> > 4.5 (modulo comments below).
> 
> Well, I think we can take the hacky short-term fix I posted before, 
> which is simple, and do a proper fix after the 4.6 dev window opens up; 
> or we can do a more complete fix now.

Specifically the "hacky short-term fix" is
<1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com> ?

I could live with that, perhaps with the commit log explaining that a
little.

Konrad?

> 
> Or, if the valgrind thing is really important, I could use the change 
> you suggested, and do "return rc ? 1 : 0;" but I really think that's 
> going in the wrong direction...
> 
>   -George
> 
> >
> >> ---
> >>   tools/libxl/libxl.c      |  2 --
> >>   tools/libxl/xl_cmdimpl.c | 28 +++++++++++++++++++++-------
> >>   2 files changed, 21 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> >> index f7961f6..d9c4ce7 100644
> >> --- a/tools/libxl/libxl.c
> >> +++ b/tools/libxl/libxl.c
> >> @@ -2611,8 +2611,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid,
> >>       if (devid < 0)
> >>           return ERROR_INVAL;
> >>   
> >> -    libxl_device_disk_init(disk);
> > _init functions are idempotent, so this is harmless, I think. Existing
> > callers (including things which aren't xl) might be relying on it.
> > Outside of a freeze period that might be acceptable (those callers are
> > buggy) but since you are asking for a freeze exception I think this may
> > be going a step too far in cleaning things up.
> >
> > In terms of other callers you've missed
> > tools/ocaml/libs/xl/xenlight_stubs.c (which appears buggy to me) in
> > tree, plus whatever use e.g. libvirt makes of it.
> >
> >> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> >> index 3c9f146..25af715 100644
> >> --- a/tools/libxl/xl_cmdimpl.c
> >> +++ b/tools/libxl/xl_cmdimpl.c
> >> @@ -485,8 +485,6 @@ static void parse_disk_config_multistring(XLU_Config **config,
> >>   {
> >>       int e;
> >>   
> >> -    libxl_device_disk_init(disk);
> > Likewise here, although to a lesser extent since this is xl not libxl.
> >>   
> >> @@ -6378,13 +6382,17 @@ int main_blockattach(int argc, char **argv)
> >>           printf("disk: %s\n", json);
> >>           free(json);
> >>           if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
> >> -        return 0;
> > You should set rc = 0 here rather than initing it at declaration to
> > catch error paths which don't set the result. (we aren't very consistent
> > about this in the code today so I'm only mentioning it because other
> > changes seem to be needed, if that turns out not to be the case and
> > there's no need for v3 then this shouldn't block acceptance)
> >
> >> +        goto out;
> > I'm not 100% convinced by the use of the goto out error handling style
> > for a success path, but it's probably better than duplicating the exit
> > path or adding !dryrun checks to all the following operations. Ian,
> > since you recently posted updated coding style for things around this,
> > what do you think?
> >
> > Ian.
> >
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:47:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15: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 1XrTx2-0004Tz-P6; Thu, 20 Nov 2014 15:47:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrTx1-0004Tu-5h
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:47:19 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	8D/CA-18267-60D0E645; Thu, 20 Nov 2014 15:47:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416498435!12704002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21770 invoked from network); 20 Nov 2014 15:47:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:47:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194847241"
Message-ID: <1416498424.14429.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 20 Nov 2014 15:47:04 +0000
In-Reply-To: <5469EBE5.4070209@eu.citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
	<1415963574.7113.7.camel@citrix.com> <5469EBE5.4070209@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 12:36 +0000, George Dunlap wrote:
> On 11/14/2014 11:12 AM, Ian Campbell wrote:
> > On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
> >> Return proper error codes on failure so that scripts can tell whether
> >> the command completed properly or not.
> >>
> >> Also while we're at it, normalize init and dispose of
> >> libxl_device_disk structures.  This means calling init and dispose in
> >> the actual functions where they are declared.
> >>
> >> This in turn means changing parse_disk_config_multistring() to not
> >> call libxl_device_disk_init.  And that in turn means changes to
> >> callers of parse_disk_config().
> >>
> >> It also means removing libxl_device_disk_init() from
> >> libxl.c:libxl_vdev_to_device_disk().  This is only called from
> >> xl_cmdimpl.c.
> >>
> >> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> >> ---
> >> CC: Ian Campbell <ian.campbell@citrix.com>
> >> CC: Ian Jackson <ian.jackson@citrix.com>
> >> CC: Wei Liu <wei.liu2@citrix.com>
> >> CC: Konrad Wilk <konrad.wilk@oracle.com>
> >>
> >> Release justification: This is a bug fix.  It's a fairly minor one,
> >> but it's also a very simple one.
> >>
> >> v2:
> >>   - Restructure functions to make sure init and dispose are properly
> >>   called.
> > Sadly this bit has somewhat reduced the truth of the second half of your
> > release justification, since the patch is a fair bit more subtle though.
> > Although IMHO it hasn't invalidated the case for taking the patch for
> > 4.5 (modulo comments below).
> 
> Well, I think we can take the hacky short-term fix I posted before, 
> which is simple, and do a proper fix after the 4.6 dev window opens up; 
> or we can do a more complete fix now.

Specifically the "hacky short-term fix" is
<1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com> ?

I could live with that, perhaps with the commit log explaining that a
little.

Konrad?

> 
> Or, if the valgrind thing is really important, I could use the change 
> you suggested, and do "return rc ? 1 : 0;" but I really think that's 
> going in the wrong direction...
> 
>   -George
> 
> >
> >> ---
> >>   tools/libxl/libxl.c      |  2 --
> >>   tools/libxl/xl_cmdimpl.c | 28 +++++++++++++++++++++-------
> >>   2 files changed, 21 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> >> index f7961f6..d9c4ce7 100644
> >> --- a/tools/libxl/libxl.c
> >> +++ b/tools/libxl/libxl.c
> >> @@ -2611,8 +2611,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid,
> >>       if (devid < 0)
> >>           return ERROR_INVAL;
> >>   
> >> -    libxl_device_disk_init(disk);
> > _init functions are idempotent, so this is harmless, I think. Existing
> > callers (including things which aren't xl) might be relying on it.
> > Outside of a freeze period that might be acceptable (those callers are
> > buggy) but since you are asking for a freeze exception I think this may
> > be going a step too far in cleaning things up.
> >
> > In terms of other callers you've missed
> > tools/ocaml/libs/xl/xenlight_stubs.c (which appears buggy to me) in
> > tree, plus whatever use e.g. libvirt makes of it.
> >
> >> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> >> index 3c9f146..25af715 100644
> >> --- a/tools/libxl/xl_cmdimpl.c
> >> +++ b/tools/libxl/xl_cmdimpl.c
> >> @@ -485,8 +485,6 @@ static void parse_disk_config_multistring(XLU_Config **config,
> >>   {
> >>       int e;
> >>   
> >> -    libxl_device_disk_init(disk);
> > Likewise here, although to a lesser extent since this is xl not libxl.
> >>   
> >> @@ -6378,13 +6382,17 @@ int main_blockattach(int argc, char **argv)
> >>           printf("disk: %s\n", json);
> >>           free(json);
> >>           if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
> >> -        return 0;
> > You should set rc = 0 here rather than initing it at declaration to
> > catch error paths which don't set the result. (we aren't very consistent
> > about this in the code today so I'm only mentioning it because other
> > changes seem to be needed, if that turns out not to be the case and
> > there's no need for v3 then this shouldn't block acceptance)
> >
> >> +        goto out;
> > I'm not 100% convinced by the use of the goto out error handling style
> > for a success path, but it's probably better than duplicating the exit
> > path or adding !dryrun checks to all the following operations. Ian,
> > since you recently posted updated coding style for things around this,
> > what do you think?
> >
> > Ian.
> >
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:48:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTy7-0004YS-73; Thu, 20 Nov 2014 15:48: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 1XrTy5-0004YF-5Q
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:48:25 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	70/D1-31453-74D0E645; Thu, 20 Nov 2014 15:48:23 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416498500!8383040!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15836 invoked from network); 20 Nov 2014 15:48:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:48:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193314505"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:48:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrTxx-0005kF-Pg;
	Thu, 20 Nov 2014 15:48:17 +0000
Date: Thu, 20 Nov 2014 15:48:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141120154817.GA31452@zion.uk.xensource.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
	<20141119210845.GF20440@laptop.dumpdata.com>
	<20141119212434.GB27349@zion.uk.xensource.com>
	<1416497391.14429.23.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416497391.14429.23.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Zhigang Wang <zhigang.x.wang@oracle.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:29:51PM +0000, Ian Campbell wrote:
> On Wed, 2014-11-19 at 21:24 +0000, Wei Liu wrote:
> > On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > > > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > > > And it will cause the xenstore 'memory/targe' calculation wrong:
> > > > 
> > > >     memory/target = info->target_memkb - info->video_memkb
> > > 
> > > CC-ing the maintainers.
> > > 
> > > Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?
> > > 
> > 
> > I don't think this is a regression, it has been broken for quite a
> > while.
> 
> I think so to.
> 
> On the other hand its a pretty clear bug to use video_memkb == -1 and
> we've seen that it causes real issues. The fix is also fairly obvious.
> I'm inclined towards suggesting we fix this in 4.5.
> 

I concur.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:48:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrTy7-0004YS-73; Thu, 20 Nov 2014 15:48: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 1XrTy5-0004YF-5Q
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:48:25 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	70/D1-31453-74D0E645; Thu, 20 Nov 2014 15:48:23 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416498500!8383040!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15836 invoked from network); 20 Nov 2014 15:48:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:48:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193314505"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:48:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrTxx-0005kF-Pg;
	Thu, 20 Nov 2014 15:48:17 +0000
Date: Thu, 20 Nov 2014 15:48:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141120154817.GA31452@zion.uk.xensource.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
	<20141119210845.GF20440@laptop.dumpdata.com>
	<20141119212434.GB27349@zion.uk.xensource.com>
	<1416497391.14429.23.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416497391.14429.23.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Zhigang Wang <zhigang.x.wang@oracle.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:29:51PM +0000, Ian Campbell wrote:
> On Wed, 2014-11-19 at 21:24 +0000, Wei Liu wrote:
> > On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > > > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > > > And it will cause the xenstore 'memory/targe' calculation wrong:
> > > > 
> > > >     memory/target = info->target_memkb - info->video_memkb
> > > 
> > > CC-ing the maintainers.
> > > 
> > > Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?
> > > 
> > 
> > I don't think this is a regression, it has been broken for quite a
> > while.
> 
> I think so to.
> 
> On the other hand its a pretty clear bug to use video_memkb == -1 and
> we've seen that it causes real issues. The fix is also fairly obvious.
> I'm inclined towards suggesting we fix this in 4.5.
> 

I concur.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:48:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15: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 1XrTyb-0004c1-KH; Thu, 20 Nov 2014 15:48:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrTyZ-0004bl-9p
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:48:55 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	57/6B-11608-66D0E645; Thu, 20 Nov 2014 15:48:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416498530!12712812!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9761 invoked from network); 20 Nov 2014 15:48:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:48:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194847941"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:48:48 -0500
Received: from cosworth.uk.xensource.com	([10.80.16.52]
	helo=localhost.localdomain ident=ianc)	by ukmail1.uk.xensource.com with
	smtp (Exim 4.69)	(envelope-from <ian.campbell@citrix.com>)	id
	1XrTyS-0005kU-0G; Thu, 20 Nov 2014 15:48:49 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Thu, 20 Nov
	2014 15:48:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Nov 2014 15:48:47 +0000
Message-ID: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer containing
	the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
is freed by xc_dom_release. However the various xc_try_*_decode routines (other
than the gzip one) just use plain malloc/realloc and therefore the buffer ends
up leaked.

The memory pool currently supports mmap'd buffers as well as a directly
allocated buffers, however the try decode routines make use of realloc and do
not fit well into this model. Introduce a concept of an external memory block
to the memory pool and provide an interface to register such memory.

The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
mmap_ prefix since they are now also used for external memory blocks.

We are only seeing this now because the gzip decoder doesn't leak and it's only
relatively recently that kernels in the wild have switched to better
compression.

This is https://bugs.debian.org/767295

Reported by: Gedalya <gedalya@gedalya.net>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Correct handling in xc_try_lzo1x_decode.

This is a bug fix and should go into 4.5.

I have a sneaking suspicion this is going to need to backport a very long way...
---
 tools/libxc/include/xc_dom.h        |   10 ++++--
 tools/libxc/xc_dom_bzimageloader.c  |   20 ++++++++++++
 tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
 tools/libxc/xc_dom_decompress_lz4.c |    5 +++
 4 files changed, 80 insertions(+), 16 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6ae6a9f..07d7224 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -33,8 +33,13 @@ struct xc_dom_seg {
 
 struct xc_dom_mem {
     struct xc_dom_mem *next;
-    void *mmap_ptr;
-    size_t mmap_len;
+    void *ptr;
+    enum {
+        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
+        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
+        XC_DOM_MEM_TYPE_MMAP,
+    } type;
+    size_t len;
     unsigned char memory[0];
 };
 
@@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
 /* --- simple memory pool ------------------------------------------ */
 
 void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
 void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
                             const char *filename, size_t * size,
diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
index 2225699..964ebdc 100644
--- a/tools/libxc/xc_dom_bzimageloader.c
+++ b/tools/libxc/xc_dom_bzimageloader.c
@@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
 
     total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
 
+    if ( xc_dom_register_external(dom, out_buf, total) )
+    {
+        DOMPRINTF("BZIP2: Error registering stream output");
+        free(out_buf);
+        goto bzip2_cleanup;
+    }
+
     DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
               __FUNCTION__, *size, (long unsigned int) total);
 
@@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
         }
     }
 
+    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
+    {
+        DOMPRINTF("%s: Error registering stream output", what);
+        free(out_buf);
+        goto lzma_cleanup;
+    }
+
     DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
               __FUNCTION__, what, *size, (size_t)stream->total_out);
 
@@ -464,7 +478,13 @@ static int xc_try_lzo1x_decode(
 
         dst_len = lzo_read_32(cur);
         if ( !dst_len )
+        {
+            msg = "Error registering stream output";
+            if ( xc_dom_register_external(dom, out_buf, out_len) )
+                break;
+
             return 0;
+        }
 
         if ( dst_len > LZOP_MAX_BLOCK_SIZE )
         {
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index baa62a1..ecbf981 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
         return NULL;
     }
     memset(block, 0, sizeof(*block) + size);
+    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block) + size;
@@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
         return NULL;
     }
     memset(block, 0, sizeof(*block));
-    block->mmap_len = size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len,
-                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
-                           -1, 0);
-    if ( block->mmap_ptr == MAP_FAILED )
+    block->len = size;
+    block->ptr = mmap(NULL, block->len,
+                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
+                      -1, 0);
+    if ( block->ptr == MAP_FAILED )
     {
         DOMPRINTF("%s: mmap failed", __FUNCTION__);
         free(block);
         return NULL;
     }
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_mem_map += block->mmap_len;
+    dom->alloc_mem_map += block->len;
     if ( size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, size);
-    return block->mmap_ptr;
+    return block->ptr;
+}
+
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
+{
+    struct xc_dom_mem *block;
+
+    block = malloc(sizeof(*block));
+    if ( block == NULL )
+    {
+        DOMPRINTF("%s: allocation failed", __FUNCTION__);
+        return -1;
+    }
+    memset(block, 0, sizeof(*block));
+    block->ptr = ptr;
+    block->len = size;
+    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
+    block->next = dom->memblocks;
+    dom->memblocks = block;
+    dom->alloc_malloc += sizeof(*block);
+    dom->alloc_mem_map += block->len;
+    return 0;
 }
 
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
@@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
     }
 
     memset(block, 0, sizeof(*block));
-    block->mmap_len = *size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
+    block->len = *size;
+    block->ptr = mmap(NULL, block->len, PROT_READ,
                            MAP_SHARED, fd, 0);
-    if ( block->mmap_ptr == MAP_FAILED ) {
+    if ( block->ptr == MAP_FAILED ) {
         xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
                      "failed to mmap file: %s",
                      strerror(errno));
         goto err;
     }
 
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_file_map += block->mmap_len;
+    dom->alloc_file_map += block->len;
     close(fd);
     if ( *size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, *size);
-    return block->mmap_ptr;
+    return block->ptr;
 
  err:
     if ( fd != -1 )
@@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
     while ( (block = dom->memblocks) != NULL )
     {
         dom->memblocks = block->next;
-        if ( block->mmap_ptr )
-            munmap(block->mmap_ptr, block->mmap_len);
+        switch ( block->type )
+        {
+        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
+            break;
+        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
+            free(block->ptr);
+            break;
+        case XC_DOM_MEM_TYPE_MMAP:
+            munmap(block->ptr, block->len);
+            break;
+        }
         free(block);
     }
 }
diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
index 490ec56..b6a33f2 100644
--- a/tools/libxc/xc_dom_decompress_lz4.c
+++ b/tools/libxc/xc_dom_decompress_lz4.c
@@ -103,6 +103,11 @@ int xc_try_lz4_decode(
 
 		if (size == 0)
 		{
+			if ( xc_dom_register_external(dom, output, out_len) )
+			{
+				msg = "Error registering stream output";
+				goto exit_2;
+			}
 			*blob = output;
 			*psize = out_len;
 			return 0;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:48:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15: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 1XrTyb-0004c1-KH; Thu, 20 Nov 2014 15:48:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrTyZ-0004bl-9p
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:48:55 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	57/6B-11608-66D0E645; Thu, 20 Nov 2014 15:48:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416498530!12712812!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9761 invoked from network); 20 Nov 2014 15:48:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:48:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194847941"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:48:48 -0500
Received: from cosworth.uk.xensource.com	([10.80.16.52]
	helo=localhost.localdomain ident=ianc)	by ukmail1.uk.xensource.com with
	smtp (Exim 4.69)	(envelope-from <ian.campbell@citrix.com>)	id
	1XrTyS-0005kU-0G; Thu, 20 Nov 2014 15:48:49 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Thu, 20 Nov
	2014 15:48:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Nov 2014 15:48:47 +0000
Message-ID: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer containing
	the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
is freed by xc_dom_release. However the various xc_try_*_decode routines (other
than the gzip one) just use plain malloc/realloc and therefore the buffer ends
up leaked.

The memory pool currently supports mmap'd buffers as well as a directly
allocated buffers, however the try decode routines make use of realloc and do
not fit well into this model. Introduce a concept of an external memory block
to the memory pool and provide an interface to register such memory.

The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
mmap_ prefix since they are now also used for external memory blocks.

We are only seeing this now because the gzip decoder doesn't leak and it's only
relatively recently that kernels in the wild have switched to better
compression.

This is https://bugs.debian.org/767295

Reported by: Gedalya <gedalya@gedalya.net>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Correct handling in xc_try_lzo1x_decode.

This is a bug fix and should go into 4.5.

I have a sneaking suspicion this is going to need to backport a very long way...
---
 tools/libxc/include/xc_dom.h        |   10 ++++--
 tools/libxc/xc_dom_bzimageloader.c  |   20 ++++++++++++
 tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
 tools/libxc/xc_dom_decompress_lz4.c |    5 +++
 4 files changed, 80 insertions(+), 16 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6ae6a9f..07d7224 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -33,8 +33,13 @@ struct xc_dom_seg {
 
 struct xc_dom_mem {
     struct xc_dom_mem *next;
-    void *mmap_ptr;
-    size_t mmap_len;
+    void *ptr;
+    enum {
+        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
+        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
+        XC_DOM_MEM_TYPE_MMAP,
+    } type;
+    size_t len;
     unsigned char memory[0];
 };
 
@@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
 /* --- simple memory pool ------------------------------------------ */
 
 void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
 void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
                             const char *filename, size_t * size,
diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
index 2225699..964ebdc 100644
--- a/tools/libxc/xc_dom_bzimageloader.c
+++ b/tools/libxc/xc_dom_bzimageloader.c
@@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
 
     total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
 
+    if ( xc_dom_register_external(dom, out_buf, total) )
+    {
+        DOMPRINTF("BZIP2: Error registering stream output");
+        free(out_buf);
+        goto bzip2_cleanup;
+    }
+
     DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
               __FUNCTION__, *size, (long unsigned int) total);
 
@@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
         }
     }
 
+    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
+    {
+        DOMPRINTF("%s: Error registering stream output", what);
+        free(out_buf);
+        goto lzma_cleanup;
+    }
+
     DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
               __FUNCTION__, what, *size, (size_t)stream->total_out);
 
@@ -464,7 +478,13 @@ static int xc_try_lzo1x_decode(
 
         dst_len = lzo_read_32(cur);
         if ( !dst_len )
+        {
+            msg = "Error registering stream output";
+            if ( xc_dom_register_external(dom, out_buf, out_len) )
+                break;
+
             return 0;
+        }
 
         if ( dst_len > LZOP_MAX_BLOCK_SIZE )
         {
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index baa62a1..ecbf981 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
         return NULL;
     }
     memset(block, 0, sizeof(*block) + size);
+    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block) + size;
@@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
         return NULL;
     }
     memset(block, 0, sizeof(*block));
-    block->mmap_len = size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len,
-                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
-                           -1, 0);
-    if ( block->mmap_ptr == MAP_FAILED )
+    block->len = size;
+    block->ptr = mmap(NULL, block->len,
+                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
+                      -1, 0);
+    if ( block->ptr == MAP_FAILED )
     {
         DOMPRINTF("%s: mmap failed", __FUNCTION__);
         free(block);
         return NULL;
     }
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_mem_map += block->mmap_len;
+    dom->alloc_mem_map += block->len;
     if ( size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, size);
-    return block->mmap_ptr;
+    return block->ptr;
+}
+
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
+{
+    struct xc_dom_mem *block;
+
+    block = malloc(sizeof(*block));
+    if ( block == NULL )
+    {
+        DOMPRINTF("%s: allocation failed", __FUNCTION__);
+        return -1;
+    }
+    memset(block, 0, sizeof(*block));
+    block->ptr = ptr;
+    block->len = size;
+    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
+    block->next = dom->memblocks;
+    dom->memblocks = block;
+    dom->alloc_malloc += sizeof(*block);
+    dom->alloc_mem_map += block->len;
+    return 0;
 }
 
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
@@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
     }
 
     memset(block, 0, sizeof(*block));
-    block->mmap_len = *size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
+    block->len = *size;
+    block->ptr = mmap(NULL, block->len, PROT_READ,
                            MAP_SHARED, fd, 0);
-    if ( block->mmap_ptr == MAP_FAILED ) {
+    if ( block->ptr == MAP_FAILED ) {
         xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
                      "failed to mmap file: %s",
                      strerror(errno));
         goto err;
     }
 
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_file_map += block->mmap_len;
+    dom->alloc_file_map += block->len;
     close(fd);
     if ( *size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, *size);
-    return block->mmap_ptr;
+    return block->ptr;
 
  err:
     if ( fd != -1 )
@@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
     while ( (block = dom->memblocks) != NULL )
     {
         dom->memblocks = block->next;
-        if ( block->mmap_ptr )
-            munmap(block->mmap_ptr, block->mmap_len);
+        switch ( block->type )
+        {
+        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
+            break;
+        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
+            free(block->ptr);
+            break;
+        case XC_DOM_MEM_TYPE_MMAP:
+            munmap(block->ptr, block->len);
+            break;
+        }
         free(block);
     }
 }
diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
index 490ec56..b6a33f2 100644
--- a/tools/libxc/xc_dom_decompress_lz4.c
+++ b/tools/libxc/xc_dom_decompress_lz4.c
@@ -103,6 +103,11 @@ int xc_try_lz4_decode(
 
 		if (size == 0)
 		{
+			if ( xc_dom_register_external(dom, output, out_len) )
+			{
+				msg = "Error registering stream output";
+				goto exit_2;
+			}
 			*blob = output;
 			*psize = out_len;
 			return 0;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:52:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:52:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU1j-0004sV-DF; Thu, 20 Nov 2014 15:52:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XrU1h-0004sO-Pg
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:52:09 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	95/1B-26740-92E0E645; Thu, 20 Nov 2014 15:52:09 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416498723!8324156!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22530 invoked from network); 20 Nov 2014 15:52:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:52:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194849344"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:51:58 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XrU1W-0005ns-KI;
	Thu, 20 Nov 2014 15:51:58 +0000
Message-ID: <546E0E0E.4050102@eu.citrix.com>
Date: Thu, 20 Nov 2014 15:51:42 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>	
	<1415963574.7113.7.camel@citrix.com>
	<5469EBE5.4070209@eu.citrix.com>
	<1416498424.14429.30.camel@citrix.com>
In-Reply-To: <1416498424.14429.30.camel@citrix.com>
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/20/2014 03:47 PM, Ian Campbell wrote:
> On Mon, 2014-11-17 at 12:36 +0000, George Dunlap wrote:
>> On 11/14/2014 11:12 AM, Ian Campbell wrote:
>>> On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
>>>> Return proper error codes on failure so that scripts can tell
>>>> whether the command completed properly or not.
>>>> 
>>>> Also while we're at it, normalize init and dispose of 
>>>> libxl_device_disk structures.  This means calling init and
>>>> dispose in the actual functions where they are declared.
>>>> 
>>>> This in turn means changing parse_disk_config_multistring()
>>>> to not call libxl_device_disk_init.  And that in turn means
>>>> changes to callers of parse_disk_config().
>>>> 
>>>> It also means removing libxl_device_disk_init() from 
>>>> libxl.c:libxl_vdev_to_device_disk().  This is only called
>>>> from xl_cmdimpl.c.
>>>> 
>>>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> 
>>>> --- CC: Ian Campbell <ian.campbell@citrix.com> CC: Ian
>>>> Jackson <ian.jackson@citrix.com> CC: Wei Liu
>>>> <wei.liu2@citrix.com> CC: Konrad Wilk
>>>> <konrad.wilk@oracle.com>
>>>> 
>>>> Release justification: This is a bug fix.  It's a fairly
>>>> minor one, but it's also a very simple one.
>>>> 
>>>> v2: - Restructure functions to make sure init and dispose are
>>>> properly called.
>>> Sadly this bit has somewhat reduced the truth of the second
>>> half of your release justification, since the patch is a fair
>>> bit more subtle though. Although IMHO it hasn't invalidated the
>>> case for taking the patch for 4.5 (modulo comments below).
>> 
>> Well, I think we can take the hacky short-term fix I posted
>> before, which is simple, and do a proper fix after the 4.6 dev
>> window opens up; or we can do a more complete fix now.
> 
> Specifically the "hacky short-term fix" is 
> <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com> ?

Yes -- the one you found somewhat wanting. :-)

> I could live with that, perhaps with the commit log explaining that
> a little.

Do you want to add that, or shall I add it and re-submit?

 -George

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUbg4KAAoJELIVx6fHhBvtXvQH/1Lg2NPR1bPElcjninQ8Qv51
deoj9lZKeMvRECSM58CTrQHo83+9jqhb9URXDRMxJ2DQqK0UTTqzNkpiolwojLq4
PkGNy5Pwlfp35meYaVdADjnwatb05+ZM/kCGVlfF70aok3Das6BdXL82MT0Btfvj
Z+0GBxNgmmkV+WdOvuKzQx0Zyq6vWpRXPz4EjyU5ypm4DSkPw+xbH65Ja/d+uxhD
il06GKvxxnbAFa7zvdGavwkxpPJmp8s4XAheqwRTRtTZMubiHUm/Ycul/774P81i
4/A94owTU1BN10FWa1aSqszHY+M2rKZXAgxUrqNPzyPSRbYn4+mASORB1+WEpDo=
=1dUr
-----END PGP SIGNATURE-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:52:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:52:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU1j-0004sV-DF; Thu, 20 Nov 2014 15:52:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XrU1h-0004sO-Pg
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:52:09 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	95/1B-26740-92E0E645; Thu, 20 Nov 2014 15:52:09 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416498723!8324156!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22530 invoked from network); 20 Nov 2014 15:52:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:52:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194849344"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:51:58 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XrU1W-0005ns-KI;
	Thu, 20 Nov 2014 15:51:58 +0000
Message-ID: <546E0E0E.4050102@eu.citrix.com>
Date: Thu, 20 Nov 2014 15:51:42 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>	
	<1415963574.7113.7.camel@citrix.com>
	<5469EBE5.4070209@eu.citrix.com>
	<1416498424.14429.30.camel@citrix.com>
In-Reply-To: <1416498424.14429.30.camel@citrix.com>
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/20/2014 03:47 PM, Ian Campbell wrote:
> On Mon, 2014-11-17 at 12:36 +0000, George Dunlap wrote:
>> On 11/14/2014 11:12 AM, Ian Campbell wrote:
>>> On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
>>>> Return proper error codes on failure so that scripts can tell
>>>> whether the command completed properly or not.
>>>> 
>>>> Also while we're at it, normalize init and dispose of 
>>>> libxl_device_disk structures.  This means calling init and
>>>> dispose in the actual functions where they are declared.
>>>> 
>>>> This in turn means changing parse_disk_config_multistring()
>>>> to not call libxl_device_disk_init.  And that in turn means
>>>> changes to callers of parse_disk_config().
>>>> 
>>>> It also means removing libxl_device_disk_init() from 
>>>> libxl.c:libxl_vdev_to_device_disk().  This is only called
>>>> from xl_cmdimpl.c.
>>>> 
>>>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> 
>>>> --- CC: Ian Campbell <ian.campbell@citrix.com> CC: Ian
>>>> Jackson <ian.jackson@citrix.com> CC: Wei Liu
>>>> <wei.liu2@citrix.com> CC: Konrad Wilk
>>>> <konrad.wilk@oracle.com>
>>>> 
>>>> Release justification: This is a bug fix.  It's a fairly
>>>> minor one, but it's also a very simple one.
>>>> 
>>>> v2: - Restructure functions to make sure init and dispose are
>>>> properly called.
>>> Sadly this bit has somewhat reduced the truth of the second
>>> half of your release justification, since the patch is a fair
>>> bit more subtle though. Although IMHO it hasn't invalidated the
>>> case for taking the patch for 4.5 (modulo comments below).
>> 
>> Well, I think we can take the hacky short-term fix I posted
>> before, which is simple, and do a proper fix after the 4.6 dev
>> window opens up; or we can do a more complete fix now.
> 
> Specifically the "hacky short-term fix" is 
> <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com> ?

Yes -- the one you found somewhat wanting. :-)

> I could live with that, perhaps with the commit log explaining that
> a little.

Do you want to add that, or shall I add it and re-submit?

 -George

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUbg4KAAoJELIVx6fHhBvtXvQH/1Lg2NPR1bPElcjninQ8Qv51
deoj9lZKeMvRECSM58CTrQHo83+9jqhb9URXDRMxJ2DQqK0UTTqzNkpiolwojLq4
PkGNy5Pwlfp35meYaVdADjnwatb05+ZM/kCGVlfF70aok3Das6BdXL82MT0Btfvj
Z+0GBxNgmmkV+WdOvuKzQx0Zyq6vWpRXPz4EjyU5ypm4DSkPw+xbH65Ja/d+uxhD
il06GKvxxnbAFa7zvdGavwkxpPJmp8s4XAheqwRTRtTZMubiHUm/Ycul/774P81i
4/A94owTU1BN10FWa1aSqszHY+M2rKZXAgxUrqNPzyPSRbYn4+mASORB1+WEpDo=
=1dUr
-----END PGP SIGNATURE-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:54:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU3y-0005AQ-M8; Thu, 20 Nov 2014 15:54:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrU3x-0005A7-5r
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 15:54:29 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B6/9D-22737-3BE0E645; Thu, 20 Nov 2014 15:54:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416498864!12522089!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28279 invoked from network); 20 Nov 2014 15:54:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:54:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194850437"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:54:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrU3q-0005pS-1D;
	Thu, 20 Nov 2014 15:54:22 +0000
Date: Thu, 20 Nov 2014 15:54:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <546DCB30.6040400@linaro.org>
Message-ID: <alpine.DEB.2.02.1411201521320.12596@kaball.uk.xensource.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<546DCA3F.2030508@linaro.org> <546DCB30.6040400@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: julien.grall@citrix.com, andrii.tseglytskyi@globallogic.com,
	xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Julien Grall wrote:
> On 11/20/2014 11:02 AM, Julien Grall wrote:
> > Hi Stefano,
> > 
> > On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
> >> UIE being set can cause maintenance interrupts to occur when Xen writes
> >> to one or more LR registers. The effect is a busy loop around the
> >> interrupt handler in Xen
> >> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> >>
> >> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> CC: konrad.wilk@oracle.com
> >> ---
> >>
> >> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> >> bad side effects on any other platforms as far as I can tell. It should
> >> go in 4.5.
> > 
> > From Andrii's mail, there is a bad side effect. We can receive spurious
> > interrupt.
> > 
> > On V1, you said that you tried this patch on midway. I would prefer if
> > you give a try on  platform that would really be used (such as xgene or
> > seattle). As we know Midway won't be used in prod.
> 
> And maybe give a try to gicv3 too as it's common code.

I don't have a gicv3 test environment ready but it works on xgene too

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:54:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU3y-0005AQ-M8; Thu, 20 Nov 2014 15:54:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrU3x-0005A7-5r
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 15:54:29 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B6/9D-22737-3BE0E645; Thu, 20 Nov 2014 15:54:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416498864!12522089!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28279 invoked from network); 20 Nov 2014 15:54:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:54:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194850437"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:54:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrU3q-0005pS-1D;
	Thu, 20 Nov 2014 15:54:22 +0000
Date: Thu, 20 Nov 2014 15:54:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Julien Grall <julien.grall@linaro.org>
In-Reply-To: <546DCB30.6040400@linaro.org>
Message-ID: <alpine.DEB.2.02.1411201521320.12596@kaball.uk.xensource.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<546DCA3F.2030508@linaro.org> <546DCB30.6040400@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: julien.grall@citrix.com, andrii.tseglytskyi@globallogic.com,
	xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Julien Grall wrote:
> On 11/20/2014 11:02 AM, Julien Grall wrote:
> > Hi Stefano,
> > 
> > On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
> >> UIE being set can cause maintenance interrupts to occur when Xen writes
> >> to one or more LR registers. The effect is a busy loop around the
> >> interrupt handler in Xen
> >> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> >>
> >> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> >> CC: konrad.wilk@oracle.com
> >> ---
> >>
> >> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> >> bad side effects on any other platforms as far as I can tell. It should
> >> go in 4.5.
> > 
> > From Andrii's mail, there is a bad side effect. We can receive spurious
> > interrupt.
> > 
> > On V1, you said that you tried this patch on midway. I would prefer if
> > you give a try on  platform that would really be used (such as xgene or
> > seattle). As we know Midway won't be used in prod.
> 
> And maybe give a try to gicv3 too as it's common code.

I don't have a gicv3 test environment ready but it works on xgene too

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:56:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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.xen.org>)
	id 1XrU5v-0005MZ-6V; Thu, 20 Nov 2014 15:56: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 1XrU5u-0005MO-7l
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:56:30 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	E2/03-22737-D2F0E645; Thu, 20 Nov 2014 15:56:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416498986!12492144!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28776 invoked from network); 20 Nov 2014 15:56:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:56:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193317765"
Message-ID: <1416498978.14429.32.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 20 Nov 2014 15:56:18 +0000
In-Reply-To: <546E0E0E.4050102@eu.citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
	<1415963574.7113.7.camel@citrix.com> <5469EBE5.4070209@eu.citrix.com>
	<1416498424.14429.30.camel@citrix.com> <546E0E0E.4050102@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 15:51 +0000, George Dunlap wrote:
> On 11/20/2014 03:47 PM, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 12:36 +0000, George Dunlap wrote:
> >> On 11/14/2014 11:12 AM, Ian Campbell wrote:
> >>> On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
> >>>> Return proper error codes on failure so that scripts can tell
> >>>> whether the command completed properly or not.
> >>>> 
> >>>> Also while we're at it, normalize init and dispose of 
> >>>> libxl_device_disk structures.  This means calling init and
> >>>> dispose in the actual functions where they are declared.
> >>>> 
> >>>> This in turn means changing parse_disk_config_multistring()
> >>>> to not call libxl_device_disk_init.  And that in turn means
> >>>> changes to callers of parse_disk_config().
> >>>> 
> >>>> It also means removing libxl_device_disk_init() from 
> >>>> libxl.c:libxl_vdev_to_device_disk().  This is only called
> >>>> from xl_cmdimpl.c.
> >>>> 
> >>>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> 
> >>>> --- CC: Ian Campbell <ian.campbell@citrix.com> CC: Ian
> >>>> Jackson <ian.jackson@citrix.com> CC: Wei Liu
> >>>> <wei.liu2@citrix.com> CC: Konrad Wilk
> >>>> <konrad.wilk@oracle.com>
> >>>> 
> >>>> Release justification: This is a bug fix.  It's a fairly
> >>>> minor one, but it's also a very simple one.
> >>>> 
> >>>> v2: - Restructure functions to make sure init and dispose are
> >>>> properly called.
> >>> Sadly this bit has somewhat reduced the truth of the second
> >>> half of your release justification, since the patch is a fair
> >>> bit more subtle though. Although IMHO it hasn't invalidated the
> >>> case for taking the patch for 4.5 (modulo comments below).
> >> 
> >> Well, I think we can take the hacky short-term fix I posted
> >> before, which is simple, and do a proper fix after the 4.6 dev
> >> window opens up; or we can do a more complete fix now.
> > 
> > Specifically the "hacky short-term fix" is 
> > <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com> ?
> 
> Yes -- the one you found somewhat wanting. :-)
> 
> > I could live with that, perhaps with the commit log explaining that
> > a little.
> 
> Do you want to add that, or shall I add it and re-submit?

If you provide the text I'll just fold it in, unless having written it
you find invoking send-email to be so trivial it's actually easier.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:56:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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.xen.org>)
	id 1XrU5v-0005MZ-6V; Thu, 20 Nov 2014 15:56: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 1XrU5u-0005MO-7l
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:56:30 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	E2/03-22737-D2F0E645; Thu, 20 Nov 2014 15:56:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416498986!12492144!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28776 invoked from network); 20 Nov 2014 15:56:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:56:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193317765"
Message-ID: <1416498978.14429.32.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 20 Nov 2014 15:56:18 +0000
In-Reply-To: <546E0E0E.4050102@eu.citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
	<1415963574.7113.7.camel@citrix.com> <5469EBE5.4070209@eu.citrix.com>
	<1416498424.14429.30.camel@citrix.com> <546E0E0E.4050102@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 15:51 +0000, George Dunlap wrote:
> On 11/20/2014 03:47 PM, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 12:36 +0000, George Dunlap wrote:
> >> On 11/14/2014 11:12 AM, Ian Campbell wrote:
> >>> On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
> >>>> Return proper error codes on failure so that scripts can tell
> >>>> whether the command completed properly or not.
> >>>> 
> >>>> Also while we're at it, normalize init and dispose of 
> >>>> libxl_device_disk structures.  This means calling init and
> >>>> dispose in the actual functions where they are declared.
> >>>> 
> >>>> This in turn means changing parse_disk_config_multistring()
> >>>> to not call libxl_device_disk_init.  And that in turn means
> >>>> changes to callers of parse_disk_config().
> >>>> 
> >>>> It also means removing libxl_device_disk_init() from 
> >>>> libxl.c:libxl_vdev_to_device_disk().  This is only called
> >>>> from xl_cmdimpl.c.
> >>>> 
> >>>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> 
> >>>> --- CC: Ian Campbell <ian.campbell@citrix.com> CC: Ian
> >>>> Jackson <ian.jackson@citrix.com> CC: Wei Liu
> >>>> <wei.liu2@citrix.com> CC: Konrad Wilk
> >>>> <konrad.wilk@oracle.com>
> >>>> 
> >>>> Release justification: This is a bug fix.  It's a fairly
> >>>> minor one, but it's also a very simple one.
> >>>> 
> >>>> v2: - Restructure functions to make sure init and dispose are
> >>>> properly called.
> >>> Sadly this bit has somewhat reduced the truth of the second
> >>> half of your release justification, since the patch is a fair
> >>> bit more subtle though. Although IMHO it hasn't invalidated the
> >>> case for taking the patch for 4.5 (modulo comments below).
> >> 
> >> Well, I think we can take the hacky short-term fix I posted
> >> before, which is simple, and do a proper fix after the 4.6 dev
> >> window opens up; or we can do a more complete fix now.
> > 
> > Specifically the "hacky short-term fix" is 
> > <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com> ?
> 
> Yes -- the one you found somewhat wanting. :-)
> 
> > I could live with that, perhaps with the commit log explaining that
> > a little.
> 
> Do you want to add that, or shall I add it and re-submit?

If you provide the text I'll just fold it in, unless having written it
you find invoking send-email to be so trivial it's actually easier.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU79-0005TA-LI; Thu, 20 Nov 2014 15:57:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrU78-0005Sw-0r
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:57:46 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	19/D4-02698-97F0E645; Thu, 20 Nov 2014 15:57:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416499062!13800870!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27038 invoked from network); 20 Nov 2014 15:57:44 -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;
	20 Nov 2014 15:57:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194851690"
Message-ID: <1416499060.14429.33.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:57:40 +0000
In-Reply-To: <20141119212853.GM20440@laptop.dumpdata.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
	<20141119210154.GB20440@laptop.dumpdata.com>
	<20141119212123.GA27349@zion.uk.xensource.com>
	<20141119212853.GM20440@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, liang.z.li@intel.com,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 16:28 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 09:21:23PM +0000, Wei Liu wrote:
> > On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Nov 17, 2014 at 12:10:34PM +0000, Wei Liu wrote:
> > > > The existence check is to make sure a device is not added to a guest
> > > > multiple times.
> > > > 
> > > > PCI device backend path has different rules from vif, disk etc. For
> > > > example:
> > > > /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> > > > /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> > > > /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> > > > /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> > > > 
> > > > The devid for PCI devices is hardcoded 0. libxl__device_exists only
> > > > checks up to /local/.../9/0 so it always returns true even the device is
> > > > assignable.
> > > > 
> > > > Remove invocation of libxl__device_exists. We're sure at this point that
> > > > the PCI device is assignable (hence no xenstore entry or JSON entry).
> > > > The check is done before hand. For HVM guest it's done by calling
> > > > xc_test_assign_device and for PV guest it's done by calling
> > > > pciback_dev_is_assigned.
> > > > 
> > > > Reported-by: Li, Liang Z <liang.z.li@intel.com>
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > > > ---
> > > > This patch fixes a regression in 4.5.
> > > 
> > > Ouch! That needs then to be fixed.
> > > 
> > > Is the version you would want to commit? I did test it - and it
> > 
> > Yes.
> 
> Then Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU79-0005TA-LI; Thu, 20 Nov 2014 15:57:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrU78-0005Sw-0r
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:57:46 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	19/D4-02698-97F0E645; Thu, 20 Nov 2014 15:57:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416499062!13800870!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27038 invoked from network); 20 Nov 2014 15:57:44 -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;
	20 Nov 2014 15:57:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194851690"
Message-ID: <1416499060.14429.33.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:57:40 +0000
In-Reply-To: <20141119212853.GM20440@laptop.dumpdata.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
	<20141119210154.GB20440@laptop.dumpdata.com>
	<20141119212123.GA27349@zion.uk.xensource.com>
	<20141119212853.GM20440@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, liang.z.li@intel.com,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 16:28 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 09:21:23PM +0000, Wei Liu wrote:
> > On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Nov 17, 2014 at 12:10:34PM +0000, Wei Liu wrote:
> > > > The existence check is to make sure a device is not added to a guest
> > > > multiple times.
> > > > 
> > > > PCI device backend path has different rules from vif, disk etc. For
> > > > example:
> > > > /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> > > > /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> > > > /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> > > > /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> > > > 
> > > > The devid for PCI devices is hardcoded 0. libxl__device_exists only
> > > > checks up to /local/.../9/0 so it always returns true even the device is
> > > > assignable.
> > > > 
> > > > Remove invocation of libxl__device_exists. We're sure at this point that
> > > > the PCI device is assignable (hence no xenstore entry or JSON entry).
> > > > The check is done before hand. For HVM guest it's done by calling
> > > > xc_test_assign_device and for PV guest it's done by calling
> > > > pciback_dev_is_assigned.
> > > > 
> > > > Reported-by: Li, Liang Z <liang.z.li@intel.com>
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > > > ---
> > > > This patch fixes a regression in 4.5.
> > > 
> > > Ouch! That needs then to be fixed.
> > > 
> > > Is the version you would want to commit? I did test it - and it
> > 
> > Yes.
> 
> Then Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:58:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15: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 1XrU7U-0005WG-0i; Thu, 20 Nov 2014 15:58:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrU7Q-0005Vi-LR
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:58:06 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	ED/BF-24859-B8F0E645; Thu, 20 Nov 2014 15:58:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416499081!9029421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7289 invoked from network); 20 Nov 2014 15:58:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:58:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193318460"
Message-ID: <1416499078.14429.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:57:58 +0000
In-Reply-To: <20141118181927.GA24283@laptop.dumpdata.com>
References: <1416330461-11985-1-git-send-email-euan.harris@citrix.com>
	<21611.34164.318838.773459@mariner.uk.xensource.com>
	<20141118181927.GA24283@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Euan Harris <euan.harris@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Document device parameter of
 libxl_device_<type>_add 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, 2014-11-18 at 13:19 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 18, 2014 at 05:44:20PM +0000, Ian Jackson wrote:
> > Euan Harris writes ("[PATCH] libxl: Document device parameter of libxl_device_<type>_add functions"):
> > > The device parameter of libxl_device_<type>_add is an in/out parameter.
> > > Unspecified fields are filled in with appropriate values for the created
> > > device when the function returns.  Document this behaviour.
> > 
> > Thanks.
> > 
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > 
> > Konrad, this should go into 4.5 IMO because it's a doc comment
> > describing existing behaviour which we want everyone to rely on.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

and applied, thanks all.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:58:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15: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 1XrU7U-0005WG-0i; Thu, 20 Nov 2014 15:58:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrU7Q-0005Vi-LR
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:58:06 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	ED/BF-24859-B8F0E645; Thu, 20 Nov 2014 15:58:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416499081!9029421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7289 invoked from network); 20 Nov 2014 15:58:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:58:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193318460"
Message-ID: <1416499078.14429.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:57:58 +0000
In-Reply-To: <20141118181927.GA24283@laptop.dumpdata.com>
References: <1416330461-11985-1-git-send-email-euan.harris@citrix.com>
	<21611.34164.318838.773459@mariner.uk.xensource.com>
	<20141118181927.GA24283@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Euan Harris <euan.harris@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Document device parameter of
 libxl_device_<type>_add 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, 2014-11-18 at 13:19 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 18, 2014 at 05:44:20PM +0000, Ian Jackson wrote:
> > Euan Harris writes ("[PATCH] libxl: Document device parameter of libxl_device_<type>_add functions"):
> > > The device parameter of libxl_device_<type>_add is an in/out parameter.
> > > Unspecified fields are filled in with appropriate values for the created
> > > device when the function returns.  Document this behaviour.
> > 
> > Thanks.
> > 
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > 
> > Konrad, this should go into 4.5 IMO because it's a doc comment
> > describing existing behaviour which we want everyone to rely on.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

and applied, thanks all.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:58:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:58:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU7c-0005Yo-DN; Thu, 20 Nov 2014 15:58: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 1XrU7b-0005YO-7e
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:58:15 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	3A/12-18267-69F0E645; Thu, 20 Nov 2014 15:58:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416499091!12715592!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30040 invoked from network); 20 Nov 2014 15:58:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:58:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193318529"
Message-ID: <1416499087.14429.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:58:07 +0000
In-Reply-To: <20141119194515.GB18117@laptop.dumpdata.com>
References: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
	<1415807026.1155.21.camel@citrix.com>
	<1415959858.21321.23.camel@citrix.com>
	<20141119194515.GB18117@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] mkdeb: correctly map package
 architectures for x86 and ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 14:45 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 10:10:58AM +0000, Ian Campbell wrote:
> > (CCing some more maintainers and the release manager)
> > 
> > On Wed, 2014-11-12 at 15:43 +0000, Ian Campbell wrote:
> > > On Wed, 2014-11-12 at 09:38 -0600, Clark Laughlin wrote:
> > > > mkdeb previously set the package architecture to be 'amd64' for anything other than
> > > > XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture from
> > > > GNU names to debian names for x86 and ARM architectures, or otherwise, defaults it
> > > > to the value in XEN_TARGET_ARCH.
> > > > 
> > > > Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
> > > 
> > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Actually thinking about it some more I'd be happier arguing for a freeze
> > exception for something like the below which only handles the actual
> > valid values of XEN_TARGET_ARCH and not the GNU names (which cannot
> > happen) and prints an error for unknown architectures (so new ports
> > aren't bitten in the future, etc).
> > 
> > Konrad, wrt the freeze I think this is low risk for breaking x86
> > platforms and makes things work for arm, so is worth it.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Ian J acked on IRC, so I've applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:58:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:58:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU7c-0005Yo-DN; Thu, 20 Nov 2014 15:58: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 1XrU7b-0005YO-7e
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 15:58:15 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	3A/12-18267-69F0E645; Thu, 20 Nov 2014 15:58:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416499091!12715592!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30040 invoked from network); 20 Nov 2014 15:58:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:58:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193318529"
Message-ID: <1416499087.14429.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:58:07 +0000
In-Reply-To: <20141119194515.GB18117@laptop.dumpdata.com>
References: <1415806728-28484-1-git-send-email-clark.laughlin@linaro.org>
	<1415807026.1155.21.camel@citrix.com>
	<1415959858.21321.23.camel@citrix.com>
	<20141119194515.GB18117@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] mkdeb: correctly map package
 architectures for x86 and ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 14:45 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 10:10:58AM +0000, Ian Campbell wrote:
> > (CCing some more maintainers and the release manager)
> > 
> > On Wed, 2014-11-12 at 15:43 +0000, Ian Campbell wrote:
> > > On Wed, 2014-11-12 at 09:38 -0600, Clark Laughlin wrote:
> > > > mkdeb previously set the package architecture to be 'amd64' for anything other than
> > > > XEN_TARGET_ARCH=x86_32.  This patch attempts to correctly map the architecture from
> > > > GNU names to debian names for x86 and ARM architectures, or otherwise, defaults it
> > > > to the value in XEN_TARGET_ARCH.
> > > > 
> > > > Signed-off-by: Clark Laughlin <clark.laughlin@linaro.org>
> > > 
> > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Actually thinking about it some more I'd be happier arguing for a freeze
> > exception for something like the below which only handles the actual
> > valid values of XEN_TARGET_ARCH and not the GNU names (which cannot
> > happen) and prints an error for unknown architectures (so new ports
> > aren't bitten in the future, etc).
> > 
> > Konrad, wrt the freeze I think this is low risk for breaking x86
> > platforms and makes things work for arm, so is worth it.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Ian J acked on IRC, so I've applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:58:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:58:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU86-0005fr-Qj; Thu, 20 Nov 2014 15:58: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 1XrU85-0005fU-PX
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:58:45 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	50/F6-26652-3BF0E645; Thu, 20 Nov 2014 15:58:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416499118!12484941!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4563 invoked from network); 20 Nov 2014 15:58:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:58:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193318594"
Message-ID: <1416499099.14429.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:58:19 +0000
In-Reply-To: <AC983992-3F1C-462A-AEF5-F57E9273F6B1@oracle.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com> <1416393024.29243.20.camel@citrix.com>
	<546C72F8.2020704@citrix.com> <1416393524.29243.21.camel@citrix.com>
	<1416393997.29243.22.camel@citrix.com> <546C7689.10406@citrix.com>
	<1416395092.29243.27.camel@citrix.com> <546C797D.6040709@citrix.com>
	<AC983992-3F1C-462A-AEF5-F57E9273F6B1@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 06:11 -0500, Konrad Rzeszutek Wilk wrote:
> On November 19, 2014 6:05:33 AM EST, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >On 19/11/14 11:04, Ian Campbell wrote:
> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >
> >Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> Release-Acked-by: Konrad Rzeszutek Wilk (Konrad.wilk@oracle.com)
> 
> In case you were thinking of putting in 4.5

I was, and now I have, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:58:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:58:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU89-0005gW-6V; Thu, 20 Nov 2014 15:58:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrU87-0005g3-Qh
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:58:47 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	78/B8-02954-7BF0E645; Thu, 20 Nov 2014 15:58:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416499120!13823912!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11058 invoked from network); 20 Nov 2014 15:58:45 -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 Nov 2014 15:58:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194851992"
Message-ID: <1416499117.14429.37.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:58:37 +0000
In-Reply-To: <20141119212721.GK20440@laptop.dumpdata.com>
References: <1416410868.29243.39.camel@citrix.com>
	<20141119212721.GK20440@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/5 v2 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 16:27 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 03:27:48PM +0000, Ian Campbell wrote:
> > These patches:
> > 
> >       * fix up an off by one bug in the xgene mapping of additional PCI
> >         bus resources, which would cause an additional extra page to be
> >         mapped
> >       * correct the size of the mapped regions to match the docs
> >       * adds support for the other 4 PCI buses on the chip, which
> >         enables mcdivitt and presumably most other Xgene based platforms
> >         which uses PCI buses other than pcie0.
> >       * adds earlyprintk for the mcdivitt platform
> > 
> > They can also be found at:
> >         git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v2
> 
> #1-#4 can go in - aka Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, with a tweak to one of the ocmmit message suggested by Julien.

> For #5 I would appreciate an ARM knowledgeble person to review it.

Acked by Julien now, are you ok for it to go in?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:58:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:58:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU89-0005gW-6V; Thu, 20 Nov 2014 15:58:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrU87-0005g3-Qh
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:58:47 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	78/B8-02954-7BF0E645; Thu, 20 Nov 2014 15:58:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416499120!13823912!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11058 invoked from network); 20 Nov 2014 15:58:45 -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 Nov 2014 15:58:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194851992"
Message-ID: <1416499117.14429.37.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:58:37 +0000
In-Reply-To: <20141119212721.GK20440@laptop.dumpdata.com>
References: <1416410868.29243.39.camel@citrix.com>
	<20141119212721.GK20440@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/5 v2 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 16:27 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 03:27:48PM +0000, Ian Campbell wrote:
> > These patches:
> > 
> >       * fix up an off by one bug in the xgene mapping of additional PCI
> >         bus resources, which would cause an additional extra page to be
> >         mapped
> >       * correct the size of the mapped regions to match the docs
> >       * adds support for the other 4 PCI buses on the chip, which
> >         enables mcdivitt and presumably most other Xgene based platforms
> >         which uses PCI buses other than pcie0.
> >       * adds earlyprintk for the mcdivitt platform
> > 
> > They can also be found at:
> >         git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v2
> 
> #1-#4 can go in - aka Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, with a tweak to one of the ocmmit message suggested by Julien.

> For #5 I would appreciate an ARM knowledgeble person to review it.

Acked by Julien now, are you ok for it to go in?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:58:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:58:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU86-0005fr-Qj; Thu, 20 Nov 2014 15:58: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 1XrU85-0005fU-PX
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:58:45 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	50/F6-26652-3BF0E645; Thu, 20 Nov 2014 15:58:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416499118!12484941!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4563 invoked from network); 20 Nov 2014 15:58:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:58:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193318594"
Message-ID: <1416499099.14429.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 15:58:19 +0000
In-Reply-To: <AC983992-3F1C-462A-AEF5-F57E9273F6B1@oracle.com>
References: <1416391975.29243.16.camel@citrix.com>
	<546C6FEB.8010308@citrix.com> <1416393024.29243.20.camel@citrix.com>
	<546C72F8.2020704@citrix.com> <1416393524.29243.21.camel@citrix.com>
	<1416393997.29243.22.camel@citrix.com> <546C7689.10406@citrix.com>
	<1416395092.29243.27.camel@citrix.com> <546C797D.6040709@citrix.com>
	<AC983992-3F1C-462A-AEF5-F57E9273F6B1@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strangeness in generated xen-command-line.html
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 06:11 -0500, Konrad Rzeszutek Wilk wrote:
> On November 19, 2014 6:05:33 AM EST, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >On 19/11/14 11:04, Ian Campbell wrote:
> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >
> >Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> Release-Acked-by: Konrad Rzeszutek Wilk (Konrad.wilk@oracle.com)
> 
> In case you were thinking of putting in 4.5

I was, and now I have, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:59:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:59:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU8s-0005tl-R6; Thu, 20 Nov 2014 15:59:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrU8r-0005tM-Q6
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:59:33 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	0D/B6-17735-5EF0E645; Thu, 20 Nov 2014 15:59:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416499167!12805065!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32334 invoked from network); 20 Nov 2014 15:59:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:59:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194852289"
Message-ID: <1416499164.14429.38.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 20 Nov 2014 15:59:24 +0000
In-Reply-To: <1416496920-31183-1-git-send-email-andrew.cooper3@citrix.com>
References: <1416496920-31183-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] docs/commandline: Fix formatting
	issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 15:22 +0000, Andrew Cooper wrote:
> For 'dom0_max_vcpus' and 'hvm_debug', markdown was interpreting the text as
> regular text, and reflowing it as a regular paragraph, leading to a single
> line as output.  Reformat them as code blocks inside blockquote blocks, which
> causes them to take their precise whitespace layout.
> 
> For 'psr', the bullet point was incorrectly delineated from paragraph text,
> causing it to be reflowed.  Alter the formatting to include the CMT-specific
> options as sub-bullets of the overall CMT resource.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
> Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:59:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:59:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU8s-0005tl-R6; Thu, 20 Nov 2014 15:59:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrU8r-0005tM-Q6
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:59:33 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	0D/B6-17735-5EF0E645; Thu, 20 Nov 2014 15:59:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416499167!12805065!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32334 invoked from network); 20 Nov 2014 15:59:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:59:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194852289"
Message-ID: <1416499164.14429.38.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 20 Nov 2014 15:59:24 +0000
In-Reply-To: <1416496920-31183-1-git-send-email-andrew.cooper3@citrix.com>
References: <1416496920-31183-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] docs/commandline: Fix formatting
	issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 15:22 +0000, Andrew Cooper wrote:
> For 'dom0_max_vcpus' and 'hvm_debug', markdown was interpreting the text as
> regular text, and reflowing it as a regular paragraph, leading to a single
> line as output.  Reformat them as code blocks inside blockquote blocks, which
> causes them to take their precise whitespace layout.
> 
> For 'psr', the bullet point was incorrectly delineated from paragraph text,
> causing it to be reflowed.  Alter the formatting to include the CMT-specific
> options as sub-bullets of the overall CMT resource.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
> Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:59:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU98-0005yq-8Y; Thu, 20 Nov 2014 15:59:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XrU97-0005yM-5d
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:59:49 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B0/3B-22737-4FF0E645; Thu, 20 Nov 2014 15:59:48 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416499182!12480319!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17864 invoked from network); 20 Nov 2014 15:59:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:59:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193319069"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:59:35 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XrU8t-0005tm-Cd;
	Thu, 20 Nov 2014 15:59:35 +0000
Message-ID: <546E0FD7.9090402@eu.citrix.com>
Date: Thu, 20 Nov 2014 15:59:19 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>		
	<1415963574.7113.7.camel@citrix.com>
	<5469EBE5.4070209@eu.citrix.com>	
	<1416498424.14429.30.camel@citrix.com>
	<546E0E0E.4050102@eu.citrix.com>
	<1416498978.14429.32.camel@citrix.com>
In-Reply-To: <1416498978.14429.32.camel@citrix.com>
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/20/2014 03:56 PM, Ian Campbell wrote:
> On Thu, 2014-11-20 at 15:51 +0000, George Dunlap wrote:
>> On 11/20/2014 03:47 PM, Ian Campbell wrote:
>>> On Mon, 2014-11-17 at 12:36 +0000, George Dunlap wrote:
>>>> On 11/14/2014 11:12 AM, Ian Campbell wrote:
>>>>> On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
>>>>>> Return proper error codes on failure so that scripts can
>>>>>> tell whether the command completed properly or not.
>>>>>> 
>>>>>> Also while we're at it, normalize init and dispose of 
>>>>>> libxl_device_disk structures.  This means calling init
>>>>>> and dispose in the actual functions where they are
>>>>>> declared.
>>>>>> 
>>>>>> This in turn means changing
>>>>>> parse_disk_config_multistring() to not call
>>>>>> libxl_device_disk_init.  And that in turn means changes
>>>>>> to callers of parse_disk_config().
>>>>>> 
>>>>>> It also means removing libxl_device_disk_init() from 
>>>>>> libxl.c:libxl_vdev_to_device_disk().  This is only
>>>>>> called from xl_cmdimpl.c.
>>>>>> 
>>>>>> Signed-off-by: George Dunlap
>>>>>> <george.dunlap@eu.citrix.com> --- CC: Ian Campbell
>>>>>> <ian.campbell@citrix.com> CC: Ian Jackson
>>>>>> <ian.jackson@citrix.com> CC: Wei Liu 
>>>>>> <wei.liu2@citrix.com> CC: Konrad Wilk 
>>>>>> <konrad.wilk@oracle.com>
>>>>>> 
>>>>>> Release justification: This is a bug fix.  It's a fairly 
>>>>>> minor one, but it's also a very simple one.
>>>>>> 
>>>>>> v2: - Restructure functions to make sure init and dispose
>>>>>> are properly called.
>>>>> Sadly this bit has somewhat reduced the truth of the
>>>>> second half of your release justification, since the patch
>>>>> is a fair bit more subtle though. Although IMHO it hasn't
>>>>> invalidated the case for taking the patch for 4.5 (modulo
>>>>> comments below).
>>>> 
>>>> Well, I think we can take the hacky short-term fix I posted 
>>>> before, which is simple, and do a proper fix after the 4.6
>>>> dev window opens up; or we can do a more complete fix now.
>>> 
>>> Specifically the "hacky short-term fix" is 
>>> <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
>>> ?
>> 
>> Yes -- the one you found somewhat wanting. :-)
>> 
>>> I could live with that, perhaps with the commit log explaining
>>> that a little.
>> 
>> Do you want to add that, or shall I add it and re-submit?
> 
> If you provide the text I'll just fold it in, unless having written
> it you find invoking send-email to be so trivial it's actually
> easier.

Unfortunately I think I clobbered v1 in my git tree while developing
v2.  It probably hasn't been garbage collected yet, but I'll just
reply to v1 with an updated changelog.

 -George

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUbg/SAAoJELIVx6fHhBvt7CUIAI75XUObbYy0/Zkinx2eVcLE
d+fXSkVFWtwPPI2bfw3DyLtbMzAGxeNLhwwuLZ47b1ROam7fDcMzRp9t36NpetkY
E+NoBk7chO8sD8lveGukipNiX0qTSKVQAc721CHwgO3L3yIw7t4iSsylR0Ntzew1
twiL68v1vwC/N70PJYSzW0v1dFQODX7YV5RreFZ+Hon6og8dNvKmlRojPC77Qid0
kAEiL2JouKrQ48ONr1cKKPWHJqNFL3+pZHbZCi9d+OF0pmOhlaVXZFccLlr26xq+
SMQx0rLyTQF6rJRUaQ0zVgMK82BxjVWXO5rIPQggnwwY0ILaYY9YmmPWw86kD0M=
=04qs
-----END PGP SIGNATURE-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 15:59:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 15:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrU98-0005yq-8Y; Thu, 20 Nov 2014 15:59:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XrU97-0005yM-5d
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 15:59:49 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B0/3B-22737-4FF0E645; Thu, 20 Nov 2014 15:59:48 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416499182!12480319!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17864 invoked from network); 20 Nov 2014 15:59:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 15:59:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193319069"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 10:59:35 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XrU8t-0005tm-Cd;
	Thu, 20 Nov 2014 15:59:35 +0000
Message-ID: <546E0FD7.9090402@eu.citrix.com>
Date: Thu, 20 Nov 2014 15:59:19 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>		
	<1415963574.7113.7.camel@citrix.com>
	<5469EBE5.4070209@eu.citrix.com>	
	<1416498424.14429.30.camel@citrix.com>
	<546E0E0E.4050102@eu.citrix.com>
	<1416498978.14429.32.camel@citrix.com>
In-Reply-To: <1416498978.14429.32.camel@citrix.com>
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/20/2014 03:56 PM, Ian Campbell wrote:
> On Thu, 2014-11-20 at 15:51 +0000, George Dunlap wrote:
>> On 11/20/2014 03:47 PM, Ian Campbell wrote:
>>> On Mon, 2014-11-17 at 12:36 +0000, George Dunlap wrote:
>>>> On 11/14/2014 11:12 AM, Ian Campbell wrote:
>>>>> On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
>>>>>> Return proper error codes on failure so that scripts can
>>>>>> tell whether the command completed properly or not.
>>>>>> 
>>>>>> Also while we're at it, normalize init and dispose of 
>>>>>> libxl_device_disk structures.  This means calling init
>>>>>> and dispose in the actual functions where they are
>>>>>> declared.
>>>>>> 
>>>>>> This in turn means changing
>>>>>> parse_disk_config_multistring() to not call
>>>>>> libxl_device_disk_init.  And that in turn means changes
>>>>>> to callers of parse_disk_config().
>>>>>> 
>>>>>> It also means removing libxl_device_disk_init() from 
>>>>>> libxl.c:libxl_vdev_to_device_disk().  This is only
>>>>>> called from xl_cmdimpl.c.
>>>>>> 
>>>>>> Signed-off-by: George Dunlap
>>>>>> <george.dunlap@eu.citrix.com> --- CC: Ian Campbell
>>>>>> <ian.campbell@citrix.com> CC: Ian Jackson
>>>>>> <ian.jackson@citrix.com> CC: Wei Liu 
>>>>>> <wei.liu2@citrix.com> CC: Konrad Wilk 
>>>>>> <konrad.wilk@oracle.com>
>>>>>> 
>>>>>> Release justification: This is a bug fix.  It's a fairly 
>>>>>> minor one, but it's also a very simple one.
>>>>>> 
>>>>>> v2: - Restructure functions to make sure init and dispose
>>>>>> are properly called.
>>>>> Sadly this bit has somewhat reduced the truth of the
>>>>> second half of your release justification, since the patch
>>>>> is a fair bit more subtle though. Although IMHO it hasn't
>>>>> invalidated the case for taking the patch for 4.5 (modulo
>>>>> comments below).
>>>> 
>>>> Well, I think we can take the hacky short-term fix I posted 
>>>> before, which is simple, and do a proper fix after the 4.6
>>>> dev window opens up; or we can do a more complete fix now.
>>> 
>>> Specifically the "hacky short-term fix" is 
>>> <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
>>> ?
>> 
>> Yes -- the one you found somewhat wanting. :-)
>> 
>>> I could live with that, perhaps with the commit log explaining
>>> that a little.
>> 
>> Do you want to add that, or shall I add it and re-submit?
> 
> If you provide the text I'll just fold it in, unless having written
> it you find invoking send-email to be so trivial it's actually
> easier.

Unfortunately I think I clobbered v1 in my git tree while developing
v2.  It probably hasn't been garbage collected yet, but I'll just
reply to v1 with an updated changelog.

 -George

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUbg/SAAoJELIVx6fHhBvt7CUIAI75XUObbYy0/Zkinx2eVcLE
d+fXSkVFWtwPPI2bfw3DyLtbMzAGxeNLhwwuLZ47b1ROam7fDcMzRp9t36NpetkY
E+NoBk7chO8sD8lveGukipNiX0qTSKVQAc721CHwgO3L3yIw7t4iSsylR0Ntzew1
twiL68v1vwC/N70PJYSzW0v1dFQODX7YV5RreFZ+Hon6og8dNvKmlRojPC77Qid0
kAEiL2JouKrQ48ONr1cKKPWHJqNFL3+pZHbZCi9d+OF0pmOhlaVXZFccLlr26xq+
SMQx0rLyTQF6rJRUaQ0zVgMK82BxjVWXO5rIPQggnwwY0ILaYY9YmmPWw86kD0M=
=04qs
-----END PGP SIGNATURE-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:01:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:01:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUAn-0006cS-3p; Thu, 20 Nov 2014 16:01:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrUAl-0006c3-DE
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:01:31 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	81/D9-05632-A501E645; Thu, 20 Nov 2014 16:01:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416499287!12765005!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22642 invoked from network); 20 Nov 2014 16:01:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:01:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194852862"
Message-ID: <1416499238.14429.39.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 20 Nov 2014 16:00:38 +0000
In-Reply-To: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> parse bootloader configuration files.
> 
> c/s d1b93ea itself changed an an interface which previously used exclusively
> integers, to using strings in the case of a grub configuration with explicit
> default set, along with changing the code calling the interface to require a
> string.  The default value for "default" remained as an integer.
> 
> As a result, any Extlinux or Lilo configuration (which drives this interface
> exclusively with integers), or Grub configuration which doesn't explicitly
> declare a default will die with an AttributeError when attempting to call
> "self.cf.default.isdigit()" where "default" is an integer.
> 
> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
> which searches partitions for valid bootloader configurations, causing the
> issue to be reported as "Unable to find partition containing kernel"
> 
> This patch attempts to fix the issue by altering all parts of this interface
> to use strings, as opposed to integers.

Would it be less invasive at this point in the release to have the place
where this stuff is used do isinstance(s, str) and isinstance(s, int)?

Also, in run_grub sel can be set to g.cf.default and then:
    if sel == -1:
        print "No kernel image selected!"
        sys.exit(1)

I can't see where the -1 comes from though, and you aren't changing any
-1 into "-1", so maybe something more subtle is going on there.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:01:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:01:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUAn-0006cS-3p; Thu, 20 Nov 2014 16:01:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrUAl-0006c3-DE
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:01:31 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	81/D9-05632-A501E645; Thu, 20 Nov 2014 16:01:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416499287!12765005!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22642 invoked from network); 20 Nov 2014 16:01:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:01:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194852862"
Message-ID: <1416499238.14429.39.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 20 Nov 2014 16:00:38 +0000
In-Reply-To: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> parse bootloader configuration files.
> 
> c/s d1b93ea itself changed an an interface which previously used exclusively
> integers, to using strings in the case of a grub configuration with explicit
> default set, along with changing the code calling the interface to require a
> string.  The default value for "default" remained as an integer.
> 
> As a result, any Extlinux or Lilo configuration (which drives this interface
> exclusively with integers), or Grub configuration which doesn't explicitly
> declare a default will die with an AttributeError when attempting to call
> "self.cf.default.isdigit()" where "default" is an integer.
> 
> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
> which searches partitions for valid bootloader configurations, causing the
> issue to be reported as "Unable to find partition containing kernel"
> 
> This patch attempts to fix the issue by altering all parts of this interface
> to use strings, as opposed to integers.

Would it be less invasive at this point in the release to have the place
where this stuff is used do isinstance(s, str) and isinstance(s, int)?

Also, in run_grub sel can be set to g.cf.default and then:
    if sel == -1:
        print "No kernel image selected!"
        sys.exit(1)

I can't see where the -1 comes from though, and you aren't changing any
-1 into "-1", so maybe something more subtle is going on there.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:04:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUDh-00074U-06; Thu, 20 Nov 2014 16:04:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XrUDg-00074O-Gb
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:04:32 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	B1/D1-02712-F011E645; Thu, 20 Nov 2014 16:04:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416499467!13777570!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6341 invoked from network); 20 Nov 2014 16:04:31 -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;
	20 Nov 2014 16:04:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193321079"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 11:03:07 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrUCJ-0005yT-6p;
	Thu, 20 Nov 2014 16:03:07 +0000
Date: Thu, 20 Nov 2014 16:03:07 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141120160307.GB31452@zion.uk.xensource.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> up leaked.
> 
> The memory pool currently supports mmap'd buffers as well as a directly
> allocated buffers, however the try decode routines make use of realloc and do
> not fit well into this model. Introduce a concept of an external memory block
> to the memory pool and provide an interface to register such memory.
> 
> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> mmap_ prefix since they are now also used for external memory blocks.
> 
> We are only seeing this now because the gzip decoder doesn't leak and it's only
> relatively recently that kernels in the wild have switched to better
> compression.
> 
> This is https://bugs.debian.org/767295
> 
> Reported by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Reviewed-by: Wei Liu <wei.liu2@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:04:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUDh-00074U-06; Thu, 20 Nov 2014 16:04:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XrUDg-00074O-Gb
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:04:32 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	B1/D1-02712-F011E645; Thu, 20 Nov 2014 16:04:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416499467!13777570!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6341 invoked from network); 20 Nov 2014 16:04:31 -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;
	20 Nov 2014 16:04:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193321079"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 11:03:07 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrUCJ-0005yT-6p;
	Thu, 20 Nov 2014 16:03:07 +0000
Date: Thu, 20 Nov 2014 16:03:07 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141120160307.GB31452@zion.uk.xensource.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> up leaked.
> 
> The memory pool currently supports mmap'd buffers as well as a directly
> allocated buffers, however the try decode routines make use of realloc and do
> not fit well into this model. Introduce a concept of an external memory block
> to the memory pool and provide an interface to register such memory.
> 
> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> mmap_ prefix since they are now also used for external memory blocks.
> 
> We are only seeing this now because the gzip decoder doesn't leak and it's only
> relatively recently that kernels in the wild have switched to better
> compression.
> 
> This is https://bugs.debian.org/767295
> 
> Reported by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Reviewed-by: Wei Liu <wei.liu2@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:06:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:06:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUFe-0007DP-Gg; Thu, 20 Nov 2014 16:06:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XrUFd-0007DE-Bm
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:06:33 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	59/B0-02698-8811E645; Thu, 20 Nov 2014 16:06:32 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416499589!13778068!1
X-Originating-IP: [64.18.0.20]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21132 invoked from network); 20 Nov 2014 16:06:31 -0000
Received: from exprod5og110.obsmtp.com (HELO exprod5og110.obsmtp.com)
	(64.18.0.20)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 16:06:31 -0000
Received: from mail-qa0-f50.google.com ([209.85.216.50]) (using TLSv1) by
	exprod5ob110.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVG4RhZw5acIz4F2EIc7gc3dN3KlH9sx2@postini.com;
	Thu, 20 Nov 2014 08:06:31 PST
Received: by mail-qa0-f50.google.com with SMTP id w8so2093769qac.37
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 08:06:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=VlvBKG1ehBki9RHGzwTsL7BVQJWYStj03hrKFQgU/gk=;
	b=iRJbRRKdp73zcLQ53V0OFSbZIy5Um1l0bep8FepO873UbKF7De1MzMXlVZQZOOVgES
	y1KhiudfdyugLuGR+AWTUBt2ScQ3d+UpWS1g9Cd/ahG2N4D2Idq4qvGcXO2TnEVJ7j9N
	zs8Vd2aQrgWv9aWt2FlR3DASb9UwWRySi5iks=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=VlvBKG1ehBki9RHGzwTsL7BVQJWYStj03hrKFQgU/gk=;
	b=Pdrlhow9PGhR/iuirU/G55oOqZx9oFDwd+CSUBfKuU1wW7nFVgZtONiiJbIjiWXaJO
	7p/6WE2zXCJ79JzdtA4N5Yfql6etzo5efu86UkOms3WwSotXD7UZOT/n9p3Je43W8k8/
	4kOL1HrKLiTEvJhvMK+gLhobTX3il4lwGlFEg1c+n4Y8rrn6jpbav99yvUiyMPKGGlmW
	UocqFNebUnD0uzyf16t6MS8Zo9E01Zr5/7Em1b5ndZCTCZtLWJn+9dbu32gNZtmyhgSF
	oNY5WMdcdjyEbwUAcUSdIrwM9I6MiVBEFCLX1L5FYwzrQs1v6v9NfDQqdwB0ZeDWuK2P
	GXfA==
X-Gm-Message-State: ALoCoQnQc63KWqJKGgyn4t8mwNc9XWc4F9vp6zDYFUdWOjD/C6924jppT3wIuCXUplU+PcK3aNKhHx9UcLzF5O7WvojZ8GiQB0tWeFOOlCgTR6cmM7rnrECGDfDIQwxsf+D+OXM01p2mNvPPqDh2USuqhskwD+dJeg==
X-Received: by 10.140.85.83 with SMTP id m77mr59707769qgd.93.1416499588854;
	Thu, 20 Nov 2014 08:06:28 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.85.83 with SMTP id m77mr59706451qgd.93.1416499576945;
	Thu, 20 Nov 2014 08:06:16 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Thu, 20 Nov 2014 08:06:16 -0800 (PST)
In-Reply-To: <546DCD46.8000105@linaro.org>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
	<CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
	<alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
	<546DCD46.8000105@linaro.org>
Date: Thu, 20 Nov 2014 18:06:16 +0200
Message-ID: <CAH_mUMOSJXr-LU3++8pAeoojDQO4q36ZdNHMiZJEo9ivUf6h6w@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SSB0aGluayBJJ2xsIGRlYnVnIHRoaXMgYSBiaXQgbGF0ZXIgLSB1bmZvcnR1bmF0ZWx5LCBub3cg
ZG9uJ3QgaGF2ZQp0aW1lIGZvciB0aGlzLiBCdXQgSSB3YW50IHRvIGdldCByaWQgb2Ygc3B1cmlv
dXMgaW50ZXJydXB0IGhlcmUuCgpCVFcgLSBTdGVmYW5vIGFyZSB5b3UgZ29pbmcgdG8gcG9zdCB0
aGUgcGF0Y2ggdGhhdCB3ZSBjcmVhdGVkCnllc3RlcmRheSA/IFdpbGwgSWFuIGFjY2VwdCBpdD8K
ClJlZ2FyZHMsCkFuZHJpaQoKT24gVGh1LCBOb3YgMjAsIDIwMTQgYXQgMToxNSBQTSwgSnVsaWVu
IEdyYWxsIDxqdWxpZW4uZ3JhbGxAbGluYXJvLm9yZz4gd3JvdGU6Cj4gT24gMTEvMjAvMjAxNCAx
MDoyOCBBTSwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOgo+PiBPbiBXZWQsIDE5IE5vdiAyMDE0
LCBBbmRyaWkgVHNlZ2x5dHNreWkgd3JvdGU6Cj4+PiAxOSDQu9C40YHRgi4gMjAxNCAyMDozMiwg
0LrQvtGA0LjRgdGC0YPQstCw0YcgIlN0ZWZhbm8gU3RhYmVsbGluaSIgPHN0ZWZhbm8uc3RhYmVs
bGluaUBldS5jaXRyaXguY29tPiDQvdCw0L/QuNGB0LDQsjoKPj4+Pgo+Pj4+IE9uIFdlZCwgMTkg
Tm92IDIwMTQsIEp1bGllbiBHcmFsbCB3cm90ZToKPj4+Pj4gT24gMTEvMTkvMjAxNCAwNjoxNCBQ
TSwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOgo+Pj4+Pj4gVGhhdCdzIHJpZ2h0LCB0aGUgbWFp
bnRlbmFuY2UgaW50ZXJydXB0IGhhbmRsZXIgaXMgbm90IGNhbGxlZCwgYnV0IGl0Cj4+Pj4+PiBk
b2Vzbid0IGRvIGFueXRoaW5nIHNvIHdlIGFyZSBmaW5lLiBUaGUgaW1wb3J0YW50IHRoaW5nIGlz
IHRoYXQgYW4KPj4+Pj4+IGludGVycnVwdCBpcyBzZW50IGFuZCBnaXRfY2xlYXJfbHJzIGdldHMg
Y2FsbGVkIG9uIGh5cGVydmlzb3IgZW50cnkuCj4+Pj4+Cj4+Pj4+IEl0IHdvdWxkIGJlIHdvcnRo
IHRvIHdyaXRlIGRvd24gdGhpcyBzb21ld2hlcmUuIEp1c3QgaW4gY2FzZSBzb21lb25lCj4+Pj4+
IGRlY2lkZSB0byBhZGQgY29kZSBpbiBtYWludGVuYW5jZSBpbnRlcnJ1cHQgbGF0ZXIuCj4+Pj4K
Pj4+PiBZZXMsIEkgY291bGQgYWRkIGEgY29tbWVudCBpbiB0aGUgaGFuZGxlcgo+Pj4KPj4+IE1h
eWJlIGl0IHdvdWxkbid0IHRha2UgYSBsb3Qgb2YgZWZmb3J0IHRvIGZpeCBpdD8gSSBhbSBqdXN0
IHdvcnJ5aW5nIHRoYXQgd2UgbWF5IGhpZGUgc29tZSBpc3N1ZSAtCj4+PiB0eXBpY2FsbHkgc3B1
cmlvdXMgaW50ZXJydXB0IHRoaXMgbm90IHdoYXQgaXMgZXhwZWN0ZWQuCj4+Cj4+IE15IGd1ZXNz
IGlzIHRoYXQgYnkgY2xlYXJpbmcgVUlFIGJlZm9yZSByZWFkaW5nIEdJQ0NfSUFSLCB3ZSAiY2xl
YXIiIHRoZQo+PiBtYWludGVuYW5jZSBpbnRlcnJ1cHQgdG9vLCBhcyBhIGNvbnNlcXVlbmNlIHRo
ZSBmb2xsb3dpbmcgcmVhZCB0bwo+PiBHSUNDX0lBUiB3b3VsZCByZXR1cm4gMTAyMyAobm90aGlu
ZyB0byBiZSByZWFkKS4gQXMgYml0IGFzIGlmIHRoZQo+PiBtYWludGVuYW5jZSBpbnRlcnJ1cHQg
d2FzIGEgbGV2ZWwgaW50ZXJydXB0IGFuZCB3ZSBqdXN0IGRpc2FibGVkIGl0Lgo+Pgo+PiBTbyBJ
IHRoaW5rIHRoYXQgaWYgd2UgY2xlYXJlZCBVSUUgYWZ0ZXIgcmVhZGluZyBHSUNDX0lBUiwgR0lD
Q19JQVIgd291bGQKPj4gcmV0dXJuIHRoZSBjb3JyZWN0IHZhbHVlLgo+Pgo+PiBIb3dldmVyIHdp
dGggdGhlIGN1cnJlbnQgc3RydWN0dXJlIG9mIHRoZSBjb2RlLCB0aGUgZmlyc3QgdGhpbmcgdGhh
dCB3ZQo+PiBkbyB1cG9uIGVudGVyaW5nIHRoZSBoeXBlcnZpc29yIGlzIGNsZWFyaW5nIExScyBh
bmQgZ2l2ZW4gd2hhdCBoYXBwZW5lZAo+PiBvbiB5b3VyIHBsYXRmb3JtIEkgdGhpbmsgaXMgYSBn
b29kIGlkZWEgdG8gZG8gaXQgd2l0aCBVSUUgZGlzYWJsZWQuCj4KPiBBZ3JlZWQuIFVJRSBzaG91
bGQgYmUgZGlzYWJsZWQgdG8gYXZvaWQgYW5vdGhlciBtYWludGVuYW5jZSBpbnRlcnJ1cHQgYXMK
PiBzb29uIGFzIHdlIEVPSSB0aGUgSVJRLgo+Cj4+IFRoaXMgaXMgd2F5IEkgd291bGQgcmF0aGVy
IHJlYWQgc3B1cmlvdXMgaW50ZXJydXB0cyBidXQgcmVhZC93cml0ZSBMUnMKPj4gd2l0aCBVSUUg
ZGlzYWJsZWQgdGhhbiByZWFkaW5nIG1haW50ZW5hbmNlIGludGVycnVwdHMgYnV0IHJpc2tpbmcK
Pj4gc3RyYW5nZSBiZWhhdmlvdXJzIG9uIHNvbWUgcGxhdGZvcm1zLgo+Cj4gUmVhZGluZyB0aGUg
R0lDLXYyIGRvY3VtZW50YXRpb24sIHRoZSBzcHVyaW91cyBpbnRlcnJ1cHQgdGhpbmdzIHNob3Vs
ZAo+IGhhcHBlbiBvbiBhbnkgcGxhdGZvcm0gZXZlcnkgdGltZSB0aGUgVUlFIGlzIGRpc2FibGVk
IHdoaWxlIHdlIHJlY2VpdmUgYQo+IG1haW50ZW5hbmNlIGludGVycnVwdC4KPgo+ICJUaGUgcmVh
ZCByZXR1cm5zIGEgc3B1cmlvdXMgaW50ZXJydXB0IElEIG9mIDEwMjMgaWYgYW55IG9mIHRoZQo+
IGZvbGxvd2luZyBhcHBseToKPgo+IC0gbm8gcGVuZGluZyBpbnRlcnJ1cHQgb24gdGhlIENQVSBp
bnRlcmZhY2UgaGFzIHN1ZmZpY2llbnQgcHJpb3JpdHkgZm9yCj4gdGhlIGludGVyZmFjZSB0byBz
aWduYWwgaXQgdG8gdGhlIHByb2Nlc3NvciIKPgo+IC0tCj4gSnVsaWVuIEdyYWxsCgoKCi0tIAoK
QW5kcmlpIFRzZWdseXRza3lpIHwgRW1iZWRkZWQgRGV2Ckdsb2JhbExvZ2ljCnd3dy5nbG9iYWxs
b2dpYy5jb20KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:06:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:06:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUFf-0007Dg-Sv; Thu, 20 Nov 2014 16:06:35 +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 1XrUFe-0007DO-LN
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:06:34 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	00/B4-02712-A811E645; Thu, 20 Nov 2014 16:06:34 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416499593!13778087!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21321 invoked from network); 20 Nov 2014 16:06:33 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:06:33 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so5900243wiw.4
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 08:06:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=Tdz050Vnsmvd3wIgb3k4OLJbHtOdZhASkY4wyV5W4rU=;
	b=UJCKxj5RZ754oeLrRE8aW+d2oiWQjJAfCfQ+V0ZW5gBrMZOqMNRR+P0ad6b3udt+Ey
	RL/268GDAM5H/IxrC8dvoMxYFVHKdycEtp9zWvVg82R4mKPBSajmBtSbL4ygnUyGrsMl
	to1Cb0cPJ+X4irfAGBGvX6eeWgUHn0VQfwmCch0mXZPd3WabRAC8nPZ/EXIpdkoRppxm
	s7UyKsfLM4Le4V6x87piDNi2n87ptGL10ePOzL9rOVYNssjd+WWfldviMI+UCzfx5561
	6LU801JE6jpAAmTK8W7gwmCC0DfjVZoAlFOrrNv589qNgSOjKwlKYAd+E9X+jw7M+EnQ
	CCAg==
MIME-Version: 1.0
X-Received: by 10.180.11.8 with SMTP id m8mr24001471wib.11.1416499584981; Thu,
	20 Nov 2014 08:06:24 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Thu, 20 Nov 2014 08:06:24 -0800 (PST)
In-Reply-To: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
Date: Thu, 20 Nov 2014 16:06:24 +0000
X-Google-Sender-Auth: ZAXIPhMANWZuNdnet8WTSe5c68k
Message-ID: <CAFLBxZaLG8RGQ5Pce9TvczvJtg8t983X+stRNMD0VeYJgJ9VEw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for 4.5] xl: Return proper error codes for
 block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 5:31 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.

How about changing this to something like:

---
Return proper error codes on failure so that scripts can tell whether
the command completed properly or not.

This is not a proper fix, since it fails to call
libxl_device_disk_dispose() on the error path.  But a proper fix
requires some refactoring, so given where we are in the release
process, it's better to have a fix that is simple and obvious, and do
the refactoring once the next development window opens up.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:06:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:06:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUFe-0007DP-Gg; Thu, 20 Nov 2014 16:06:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XrUFd-0007DE-Bm
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:06:33 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	59/B0-02698-8811E645; Thu, 20 Nov 2014 16:06:32 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416499589!13778068!1
X-Originating-IP: [64.18.0.20]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21132 invoked from network); 20 Nov 2014 16:06:31 -0000
Received: from exprod5og110.obsmtp.com (HELO exprod5og110.obsmtp.com)
	(64.18.0.20)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 16:06:31 -0000
Received: from mail-qa0-f50.google.com ([209.85.216.50]) (using TLSv1) by
	exprod5ob110.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVG4RhZw5acIz4F2EIc7gc3dN3KlH9sx2@postini.com;
	Thu, 20 Nov 2014 08:06:31 PST
Received: by mail-qa0-f50.google.com with SMTP id w8so2093769qac.37
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 08:06:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=VlvBKG1ehBki9RHGzwTsL7BVQJWYStj03hrKFQgU/gk=;
	b=iRJbRRKdp73zcLQ53V0OFSbZIy5Um1l0bep8FepO873UbKF7De1MzMXlVZQZOOVgES
	y1KhiudfdyugLuGR+AWTUBt2ScQ3d+UpWS1g9Cd/ahG2N4D2Idq4qvGcXO2TnEVJ7j9N
	zs8Vd2aQrgWv9aWt2FlR3DASb9UwWRySi5iks=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=VlvBKG1ehBki9RHGzwTsL7BVQJWYStj03hrKFQgU/gk=;
	b=Pdrlhow9PGhR/iuirU/G55oOqZx9oFDwd+CSUBfKuU1wW7nFVgZtONiiJbIjiWXaJO
	7p/6WE2zXCJ79JzdtA4N5Yfql6etzo5efu86UkOms3WwSotXD7UZOT/n9p3Je43W8k8/
	4kOL1HrKLiTEvJhvMK+gLhobTX3il4lwGlFEg1c+n4Y8rrn6jpbav99yvUiyMPKGGlmW
	UocqFNebUnD0uzyf16t6MS8Zo9E01Zr5/7Em1b5ndZCTCZtLWJn+9dbu32gNZtmyhgSF
	oNY5WMdcdjyEbwUAcUSdIrwM9I6MiVBEFCLX1L5FYwzrQs1v6v9NfDQqdwB0ZeDWuK2P
	GXfA==
X-Gm-Message-State: ALoCoQnQc63KWqJKGgyn4t8mwNc9XWc4F9vp6zDYFUdWOjD/C6924jppT3wIuCXUplU+PcK3aNKhHx9UcLzF5O7WvojZ8GiQB0tWeFOOlCgTR6cmM7rnrECGDfDIQwxsf+D+OXM01p2mNvPPqDh2USuqhskwD+dJeg==
X-Received: by 10.140.85.83 with SMTP id m77mr59707769qgd.93.1416499588854;
	Thu, 20 Nov 2014 08:06:28 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.85.83 with SMTP id m77mr59706451qgd.93.1416499576945;
	Thu, 20 Nov 2014 08:06:16 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Thu, 20 Nov 2014 08:06:16 -0800 (PST)
In-Reply-To: <546DCD46.8000105@linaro.org>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191610220.12596@kaball.uk.xensource.com>
	<CAH_mUMNVRTZyE3h+s4NU31_pKiK1WgguO8erooOF+Q91eVRVzw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
	<CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
	<alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
	<546DCD46.8000105@linaro.org>
Date: Thu, 20 Nov 2014 18:06:16 +0200
Message-ID: <CAH_mUMOSJXr-LU3++8pAeoojDQO4q36ZdNHMiZJEo9ivUf6h6w@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SSB0aGluayBJJ2xsIGRlYnVnIHRoaXMgYSBiaXQgbGF0ZXIgLSB1bmZvcnR1bmF0ZWx5LCBub3cg
ZG9uJ3QgaGF2ZQp0aW1lIGZvciB0aGlzLiBCdXQgSSB3YW50IHRvIGdldCByaWQgb2Ygc3B1cmlv
dXMgaW50ZXJydXB0IGhlcmUuCgpCVFcgLSBTdGVmYW5vIGFyZSB5b3UgZ29pbmcgdG8gcG9zdCB0
aGUgcGF0Y2ggdGhhdCB3ZSBjcmVhdGVkCnllc3RlcmRheSA/IFdpbGwgSWFuIGFjY2VwdCBpdD8K
ClJlZ2FyZHMsCkFuZHJpaQoKT24gVGh1LCBOb3YgMjAsIDIwMTQgYXQgMToxNSBQTSwgSnVsaWVu
IEdyYWxsIDxqdWxpZW4uZ3JhbGxAbGluYXJvLm9yZz4gd3JvdGU6Cj4gT24gMTEvMjAvMjAxNCAx
MDoyOCBBTSwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOgo+PiBPbiBXZWQsIDE5IE5vdiAyMDE0
LCBBbmRyaWkgVHNlZ2x5dHNreWkgd3JvdGU6Cj4+PiAxOSDQu9C40YHRgi4gMjAxNCAyMDozMiwg
0LrQvtGA0LjRgdGC0YPQstCw0YcgIlN0ZWZhbm8gU3RhYmVsbGluaSIgPHN0ZWZhbm8uc3RhYmVs
bGluaUBldS5jaXRyaXguY29tPiDQvdCw0L/QuNGB0LDQsjoKPj4+Pgo+Pj4+IE9uIFdlZCwgMTkg
Tm92IDIwMTQsIEp1bGllbiBHcmFsbCB3cm90ZToKPj4+Pj4gT24gMTEvMTkvMjAxNCAwNjoxNCBQ
TSwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOgo+Pj4+Pj4gVGhhdCdzIHJpZ2h0LCB0aGUgbWFp
bnRlbmFuY2UgaW50ZXJydXB0IGhhbmRsZXIgaXMgbm90IGNhbGxlZCwgYnV0IGl0Cj4+Pj4+PiBk
b2Vzbid0IGRvIGFueXRoaW5nIHNvIHdlIGFyZSBmaW5lLiBUaGUgaW1wb3J0YW50IHRoaW5nIGlz
IHRoYXQgYW4KPj4+Pj4+IGludGVycnVwdCBpcyBzZW50IGFuZCBnaXRfY2xlYXJfbHJzIGdldHMg
Y2FsbGVkIG9uIGh5cGVydmlzb3IgZW50cnkuCj4+Pj4+Cj4+Pj4+IEl0IHdvdWxkIGJlIHdvcnRo
IHRvIHdyaXRlIGRvd24gdGhpcyBzb21ld2hlcmUuIEp1c3QgaW4gY2FzZSBzb21lb25lCj4+Pj4+
IGRlY2lkZSB0byBhZGQgY29kZSBpbiBtYWludGVuYW5jZSBpbnRlcnJ1cHQgbGF0ZXIuCj4+Pj4K
Pj4+PiBZZXMsIEkgY291bGQgYWRkIGEgY29tbWVudCBpbiB0aGUgaGFuZGxlcgo+Pj4KPj4+IE1h
eWJlIGl0IHdvdWxkbid0IHRha2UgYSBsb3Qgb2YgZWZmb3J0IHRvIGZpeCBpdD8gSSBhbSBqdXN0
IHdvcnJ5aW5nIHRoYXQgd2UgbWF5IGhpZGUgc29tZSBpc3N1ZSAtCj4+PiB0eXBpY2FsbHkgc3B1
cmlvdXMgaW50ZXJydXB0IHRoaXMgbm90IHdoYXQgaXMgZXhwZWN0ZWQuCj4+Cj4+IE15IGd1ZXNz
IGlzIHRoYXQgYnkgY2xlYXJpbmcgVUlFIGJlZm9yZSByZWFkaW5nIEdJQ0NfSUFSLCB3ZSAiY2xl
YXIiIHRoZQo+PiBtYWludGVuYW5jZSBpbnRlcnJ1cHQgdG9vLCBhcyBhIGNvbnNlcXVlbmNlIHRo
ZSBmb2xsb3dpbmcgcmVhZCB0bwo+PiBHSUNDX0lBUiB3b3VsZCByZXR1cm4gMTAyMyAobm90aGlu
ZyB0byBiZSByZWFkKS4gQXMgYml0IGFzIGlmIHRoZQo+PiBtYWludGVuYW5jZSBpbnRlcnJ1cHQg
d2FzIGEgbGV2ZWwgaW50ZXJydXB0IGFuZCB3ZSBqdXN0IGRpc2FibGVkIGl0Lgo+Pgo+PiBTbyBJ
IHRoaW5rIHRoYXQgaWYgd2UgY2xlYXJlZCBVSUUgYWZ0ZXIgcmVhZGluZyBHSUNDX0lBUiwgR0lD
Q19JQVIgd291bGQKPj4gcmV0dXJuIHRoZSBjb3JyZWN0IHZhbHVlLgo+Pgo+PiBIb3dldmVyIHdp
dGggdGhlIGN1cnJlbnQgc3RydWN0dXJlIG9mIHRoZSBjb2RlLCB0aGUgZmlyc3QgdGhpbmcgdGhh
dCB3ZQo+PiBkbyB1cG9uIGVudGVyaW5nIHRoZSBoeXBlcnZpc29yIGlzIGNsZWFyaW5nIExScyBh
bmQgZ2l2ZW4gd2hhdCBoYXBwZW5lZAo+PiBvbiB5b3VyIHBsYXRmb3JtIEkgdGhpbmsgaXMgYSBn
b29kIGlkZWEgdG8gZG8gaXQgd2l0aCBVSUUgZGlzYWJsZWQuCj4KPiBBZ3JlZWQuIFVJRSBzaG91
bGQgYmUgZGlzYWJsZWQgdG8gYXZvaWQgYW5vdGhlciBtYWludGVuYW5jZSBpbnRlcnJ1cHQgYXMK
PiBzb29uIGFzIHdlIEVPSSB0aGUgSVJRLgo+Cj4+IFRoaXMgaXMgd2F5IEkgd291bGQgcmF0aGVy
IHJlYWQgc3B1cmlvdXMgaW50ZXJydXB0cyBidXQgcmVhZC93cml0ZSBMUnMKPj4gd2l0aCBVSUUg
ZGlzYWJsZWQgdGhhbiByZWFkaW5nIG1haW50ZW5hbmNlIGludGVycnVwdHMgYnV0IHJpc2tpbmcK
Pj4gc3RyYW5nZSBiZWhhdmlvdXJzIG9uIHNvbWUgcGxhdGZvcm1zLgo+Cj4gUmVhZGluZyB0aGUg
R0lDLXYyIGRvY3VtZW50YXRpb24sIHRoZSBzcHVyaW91cyBpbnRlcnJ1cHQgdGhpbmdzIHNob3Vs
ZAo+IGhhcHBlbiBvbiBhbnkgcGxhdGZvcm0gZXZlcnkgdGltZSB0aGUgVUlFIGlzIGRpc2FibGVk
IHdoaWxlIHdlIHJlY2VpdmUgYQo+IG1haW50ZW5hbmNlIGludGVycnVwdC4KPgo+ICJUaGUgcmVh
ZCByZXR1cm5zIGEgc3B1cmlvdXMgaW50ZXJydXB0IElEIG9mIDEwMjMgaWYgYW55IG9mIHRoZQo+
IGZvbGxvd2luZyBhcHBseToKPgo+IC0gbm8gcGVuZGluZyBpbnRlcnJ1cHQgb24gdGhlIENQVSBp
bnRlcmZhY2UgaGFzIHN1ZmZpY2llbnQgcHJpb3JpdHkgZm9yCj4gdGhlIGludGVyZmFjZSB0byBz
aWduYWwgaXQgdG8gdGhlIHByb2Nlc3NvciIKPgo+IC0tCj4gSnVsaWVuIEdyYWxsCgoKCi0tIAoK
QW5kcmlpIFRzZWdseXRza3lpIHwgRW1iZWRkZWQgRGV2Ckdsb2JhbExvZ2ljCnd3dy5nbG9iYWxs
b2dpYy5jb20KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:06:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:06:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUFf-0007Dg-Sv; Thu, 20 Nov 2014 16:06:35 +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 1XrUFe-0007DO-LN
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:06:34 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	00/B4-02712-A811E645; Thu, 20 Nov 2014 16:06:34 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416499593!13778087!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21321 invoked from network); 20 Nov 2014 16:06:33 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:06:33 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so5900243wiw.4
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 08:06:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=Tdz050Vnsmvd3wIgb3k4OLJbHtOdZhASkY4wyV5W4rU=;
	b=UJCKxj5RZ754oeLrRE8aW+d2oiWQjJAfCfQ+V0ZW5gBrMZOqMNRR+P0ad6b3udt+Ey
	RL/268GDAM5H/IxrC8dvoMxYFVHKdycEtp9zWvVg82R4mKPBSajmBtSbL4ygnUyGrsMl
	to1Cb0cPJ+X4irfAGBGvX6eeWgUHn0VQfwmCch0mXZPd3WabRAC8nPZ/EXIpdkoRppxm
	s7UyKsfLM4Le4V6x87piDNi2n87ptGL10ePOzL9rOVYNssjd+WWfldviMI+UCzfx5561
	6LU801JE6jpAAmTK8W7gwmCC0DfjVZoAlFOrrNv589qNgSOjKwlKYAd+E9X+jw7M+EnQ
	CCAg==
MIME-Version: 1.0
X-Received: by 10.180.11.8 with SMTP id m8mr24001471wib.11.1416499584981; Thu,
	20 Nov 2014 08:06:24 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Thu, 20 Nov 2014 08:06:24 -0800 (PST)
In-Reply-To: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
Date: Thu, 20 Nov 2014 16:06:24 +0000
X-Google-Sender-Auth: ZAXIPhMANWZuNdnet8WTSe5c68k
Message-ID: <CAFLBxZaLG8RGQ5Pce9TvczvJtg8t983X+stRNMD0VeYJgJ9VEw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for 4.5] xl: Return proper error codes for
 block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 12, 2014 at 5:31 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.

How about changing this to something like:

---
Return proper error codes on failure so that scripts can tell whether
the command completed properly or not.

This is not a proper fix, since it fails to call
libxl_device_disk_dispose() on the error path.  But a proper fix
requires some refactoring, so given where we are in the release
process, it's better to have a fix that is simple and obvious, and do
the refactoring once the next development window opens up.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:09:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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.xen.org>)
	id 1XrUI5-0007VV-FM; Thu, 20 Nov 2014 16:09:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrUI3-0007VI-CP
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:09:03 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	EB/29-23865-E121E645; Thu, 20 Nov 2014 16:09:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416499739!12624450!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4127 invoked from network); 20 Nov 2014 16:09:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:09:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194857274"
Message-ID: <1416499682.14429.41.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 20 Nov 2014 16:08:02 +0000
In-Reply-To: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
> By default, the script get_maintainer.pl will remove duplicates email as soon
> as it appends the list of maintainers of a new file, and therefore override
> the role of the developper.
> 
> On complex patch (see [1]), this will result to ommitting randomly some
> maintainers.
> 
> This could be fixed

Are you proposing an alternative/better fix here? or describing what
this patch does?

>  by not removing the duplicate email in the list. Once the
> list is created, when it's necessary, the script will drop the "REST" people
> and remove duplicata.
> 
> Example:
> 
> Patch: https://patches.linaro.org/41083/
> 
> Before:
> 
> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Ian Campbell <ian.campbell@citrix.com>
> Wei Liu <wei.liu2@citrix.com>
> George Dunlap <george.dunlap@eu.citrix.com>
> xen-devel@lists.xen.org
> 
> After:
> 
> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Ian Campbell <ian.campbell@citrix.com>
> Wei Liu <wei.liu2@citrix.com>
> Stefano Stabellini <stefano.stabellini@citrix.com>
> Tim Deegan <tim@xen.org>
> Keir Fraser <keir@xen.org>
> Jan Beulich <jbeulich@suse.com>
> George Dunlap <george.dunlap@eu.citrix.com>
> xen-devel@lists.xen.org
> 
> [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> CC: Don Slutz <dslutz@verizon.com>
> 
> ---
>     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
>     time the script has been introduced).
> 
>     Developpers using this script won't ommitted to cc some maintainers, and it
>     will avoid maintainers complaining about miss CC.
> 
>     The only drawbacks I can see is there is too much people CCed (the
>     patch d67738db was intended to avoid CCing Keir too often).

My tree doesn't have in it d67738db but from the example you give above
it seems like this patch will regress that? As someone who already gets
too much mail and is listed in THE REST these days I am very much in
favour of not mailing THE REST when other maintainers have been found.

>     Also, if the maintainers is referenced twice in the file MAINTAINERS with
>     different email, the script won't notice it's duplicated and list 2 times.
>     Though, for this one it could be fixed by modifying  the MAINTAINERS file.
>     Is it worth for Xen 4.5? For know, it seems to only happen with Stefano.

That's fine IMHO. The script shouldn't be expected to be smart enough to
reconcile two distinct strings which happen to refer to the same person
into a single string. If someone cares they should patch MAINTAINERS to
refer to themselves in a consistent way.

> ---
>  scripts/get_maintainer.pl |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index df920e2..cc445cd 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -35,7 +35,7 @@ my $email_git_min_percent = 5;
>  my $email_git_since = "1-year-ago";
>  my $email_hg_since = "-365";
>  my $interactive = 0;
> -my $email_remove_duplicates = 1;
> +my $email_remove_duplicates = 0;
>  my $email_use_mailmap = 1;
>  my $email_drop_the_rest_supporter_if_supporter_found = 1;
>  my $output_multiline = 1;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:09:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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.xen.org>)
	id 1XrUI5-0007VV-FM; Thu, 20 Nov 2014 16:09:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrUI3-0007VI-CP
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:09:03 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	EB/29-23865-E121E645; Thu, 20 Nov 2014 16:09:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416499739!12624450!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4127 invoked from network); 20 Nov 2014 16:09:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:09:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194857274"
Message-ID: <1416499682.14429.41.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 20 Nov 2014 16:08:02 +0000
In-Reply-To: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
> By default, the script get_maintainer.pl will remove duplicates email as soon
> as it appends the list of maintainers of a new file, and therefore override
> the role of the developper.
> 
> On complex patch (see [1]), this will result to ommitting randomly some
> maintainers.
> 
> This could be fixed

Are you proposing an alternative/better fix here? or describing what
this patch does?

>  by not removing the duplicate email in the list. Once the
> list is created, when it's necessary, the script will drop the "REST" people
> and remove duplicata.
> 
> Example:
> 
> Patch: https://patches.linaro.org/41083/
> 
> Before:
> 
> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Ian Campbell <ian.campbell@citrix.com>
> Wei Liu <wei.liu2@citrix.com>
> George Dunlap <george.dunlap@eu.citrix.com>
> xen-devel@lists.xen.org
> 
> After:
> 
> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Ian Campbell <ian.campbell@citrix.com>
> Wei Liu <wei.liu2@citrix.com>
> Stefano Stabellini <stefano.stabellini@citrix.com>
> Tim Deegan <tim@xen.org>
> Keir Fraser <keir@xen.org>
> Jan Beulich <jbeulich@suse.com>
> George Dunlap <george.dunlap@eu.citrix.com>
> xen-devel@lists.xen.org
> 
> [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> CC: Don Slutz <dslutz@verizon.com>
> 
> ---
>     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
>     time the script has been introduced).
> 
>     Developpers using this script won't ommitted to cc some maintainers, and it
>     will avoid maintainers complaining about miss CC.
> 
>     The only drawbacks I can see is there is too much people CCed (the
>     patch d67738db was intended to avoid CCing Keir too often).

My tree doesn't have in it d67738db but from the example you give above
it seems like this patch will regress that? As someone who already gets
too much mail and is listed in THE REST these days I am very much in
favour of not mailing THE REST when other maintainers have been found.

>     Also, if the maintainers is referenced twice in the file MAINTAINERS with
>     different email, the script won't notice it's duplicated and list 2 times.
>     Though, for this one it could be fixed by modifying  the MAINTAINERS file.
>     Is it worth for Xen 4.5? For know, it seems to only happen with Stefano.

That's fine IMHO. The script shouldn't be expected to be smart enough to
reconcile two distinct strings which happen to refer to the same person
into a single string. If someone cares they should patch MAINTAINERS to
refer to themselves in a consistent way.

> ---
>  scripts/get_maintainer.pl |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index df920e2..cc445cd 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -35,7 +35,7 @@ my $email_git_min_percent = 5;
>  my $email_git_since = "1-year-ago";
>  my $email_hg_since = "-365";
>  my $interactive = 0;
> -my $email_remove_duplicates = 1;
> +my $email_remove_duplicates = 0;
>  my $email_use_mailmap = 1;
>  my $email_drop_the_rest_supporter_if_supporter_found = 1;
>  my $output_multiline = 1;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:09:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:09:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUIW-0007aJ-12; Thu, 20 Nov 2014 16:09:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrUIU-0007Zx-NE
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:09:30 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	57/16-03148-A321E645; Thu, 20 Nov 2014 16:09:30 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416499766!13804288!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29470 invoked from network); 20 Nov 2014 16:09:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:09:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194857591"
Message-ID: <546E1206.5080403@citrix.com>
Date: Thu, 20 Nov 2014 16:08:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416499238.14429.39.camel@citrix.com>
In-Reply-To: <1416499238.14429.39.camel@citrix.com>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/11/14 16:00, Ian Campbell wrote:
> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
>> parse bootloader configuration files.
>>
>> c/s d1b93ea itself changed an an interface which previously used exclusively
>> integers, to using strings in the case of a grub configuration with explicit
>> default set, along with changing the code calling the interface to require a
>> string.  The default value for "default" remained as an integer.
>>
>> As a result, any Extlinux or Lilo configuration (which drives this interface
>> exclusively with integers), or Grub configuration which doesn't explicitly
>> declare a default will die with an AttributeError when attempting to call
>> "self.cf.default.isdigit()" where "default" is an integer.
>>
>> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
>> which searches partitions for valid bootloader configurations, causing the
>> issue to be reported as "Unable to find partition containing kernel"
>>
>> This patch attempts to fix the issue by altering all parts of this interface
>> to use strings, as opposed to integers.
> Would it be less invasive at this point in the release to have the place
> where this stuff is used do isinstance(s, str) and isinstance(s, int)?

It would be BaseString not str, but I am fairly sure the classes have
altered through Py2's history.  I would not be any more confident with
that as a solution as trying to correctly to start with.

By far the least risky option at this point would be to revert the two
identified commits in the comments of the original patch.

>
> Also, in run_grub sel can be set to g.cf.default and then:
>     if sel == -1:
>         print "No kernel image selected!"
>         sys.exit(1)
>
> I can't see where the -1 comes from though, and you aren't changing any
> -1 into "-1", so maybe something more subtle is going on there.
>
> Ian.
>
>

sel comes either from g.image_index() which strictly is an integer, or
pulled out of the loop immediately preceding and strictly an integer.

I can't however find anything which could cause it to have the value
-1.  All error paths I can spot use 0 instead and load the first entry.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:09:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:09:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUIW-0007aJ-12; Thu, 20 Nov 2014 16:09:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrUIU-0007Zx-NE
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:09:30 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	57/16-03148-A321E645; Thu, 20 Nov 2014 16:09:30 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416499766!13804288!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29470 invoked from network); 20 Nov 2014 16:09:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:09:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194857591"
Message-ID: <546E1206.5080403@citrix.com>
Date: Thu, 20 Nov 2014 16:08:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416499238.14429.39.camel@citrix.com>
In-Reply-To: <1416499238.14429.39.camel@citrix.com>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/11/14 16:00, Ian Campbell wrote:
> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
>> parse bootloader configuration files.
>>
>> c/s d1b93ea itself changed an an interface which previously used exclusively
>> integers, to using strings in the case of a grub configuration with explicit
>> default set, along with changing the code calling the interface to require a
>> string.  The default value for "default" remained as an integer.
>>
>> As a result, any Extlinux or Lilo configuration (which drives this interface
>> exclusively with integers), or Grub configuration which doesn't explicitly
>> declare a default will die with an AttributeError when attempting to call
>> "self.cf.default.isdigit()" where "default" is an integer.
>>
>> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
>> which searches partitions for valid bootloader configurations, causing the
>> issue to be reported as "Unable to find partition containing kernel"
>>
>> This patch attempts to fix the issue by altering all parts of this interface
>> to use strings, as opposed to integers.
> Would it be less invasive at this point in the release to have the place
> where this stuff is used do isinstance(s, str) and isinstance(s, int)?

It would be BaseString not str, but I am fairly sure the classes have
altered through Py2's history.  I would not be any more confident with
that as a solution as trying to correctly to start with.

By far the least risky option at this point would be to revert the two
identified commits in the comments of the original patch.

>
> Also, in run_grub sel can be set to g.cf.default and then:
>     if sel == -1:
>         print "No kernel image selected!"
>         sys.exit(1)
>
> I can't see where the -1 comes from though, and you aren't changing any
> -1 into "-1", so maybe something more subtle is going on there.
>
> Ian.
>
>

sel comes either from g.image_index() which strictly is an integer, or
pulled out of the loop immediately preceding and strictly an integer.

I can't however find anything which could cause it to have the value
-1.  All error paths I can spot use 0 instead and load the first entry.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:15:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUNz-00085D-KX; Thu, 20 Nov 2014 16:15:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrUNy-00084y-Uv
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:15:11 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9D/B5-09936-D831E645; Thu, 20 Nov 2014 16:15:09 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416500107!14189205!1
X-Originating-IP: [74.125.83.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13970 invoked from network); 20 Nov 2014 16:15:08 -0000
Received: from mail-ee0-f47.google.com (HELO mail-ee0-f47.google.com)
	(74.125.83.47)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:15:08 -0000
Received: by mail-ee0-f47.google.com with SMTP id e49so105621eek.6
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 08:15:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=OkRFFn+1V6PjWz2oJOR6VZiP1ga3CbQaOxSpwIDq434=;
	b=Xs7R+cvUXr24X0hWQKv9aG1rAxflbX2PqQMJ3owqec33h1YlFfbmK5ubN/y8f98f3+
	2T1Izzxzpgq0o2/J8eiDnqSXu3sIiD/UtnpjvHE/ikLThyC3l1HqxEoqP85v2bhUlQYI
	yP9xW+iJMX6mPxrwzUdjhdM3Xh3rsetRvXKhWRN0dSnvUOFkQ9GYP3xGI3Bp9xBU6618
	kb4ziMB0743bqI7mGiEeDu5W2gFHaiUtEE4+8A2y1Es7hegnRpsPQCNksrmFenEfugWp
	BxVmLcZeXoF4XNzBFDbozPGacPBbYYp55kmpYr6g1QbGC40h4BQG4puzBiFNOolHgFSg
	t2Rw==
X-Gm-Message-State: ALoCoQl3S+IupsSiGruIXlgK0Sg43g0F05hiZgclU95CJye7mq65CLrqAFW6cAegAf7OiyMQY5Ey
X-Received: by 10.194.193.2 with SMTP id hk2mr54392308wjc.40.1416500107578;
	Thu, 20 Nov 2014 08:15:07 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id p7sm3968521wjo.38.2014.11.20.08.15.06
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 08:15:06 -0800 (PST)
Message-ID: <546E1389.1070304@linaro.org>
Date: Thu, 20 Nov 2014 16:15:05 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com>
In-Reply-To: <1416499682.14429.41.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/20/2014 04:08 PM, Ian Campbell wrote:
> On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
>> By default, the script get_maintainer.pl will remove duplicates email as soon
>> as it appends the list of maintainers of a new file, and therefore override
>> the role of the developper.
>>
>> On complex patch (see [1]), this will result to ommitting randomly some
>> maintainers.
>>
>> This could be fixed
> 
> Are you proposing an alternative/better fix here? or describing what
> this patch does?

Describing what the patch does.

>>  by not removing the duplicate email in the list. Once the
>> list is created, when it's necessary, the script will drop the "REST" people
>> and remove duplicata.
>>
>> Example:
>>
>> Patch: https://patches.linaro.org/41083/
>>
>> Before:
>>
>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Ian Jackson <ian.jackson@eu.citrix.com>
>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Ian Campbell <ian.campbell@citrix.com>
>> Wei Liu <wei.liu2@citrix.com>
>> George Dunlap <george.dunlap@eu.citrix.com>
>> xen-devel@lists.xen.org
>>
>> After:
>>
>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Ian Jackson <ian.jackson@eu.citrix.com>
>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Ian Campbell <ian.campbell@citrix.com>
>> Wei Liu <wei.liu2@citrix.com>
>> Stefano Stabellini <stefano.stabellini@citrix.com>
>> Tim Deegan <tim@xen.org>
>> Keir Fraser <keir@xen.org>
>> Jan Beulich <jbeulich@suse.com>
>> George Dunlap <george.dunlap@eu.citrix.com>
>> xen-devel@lists.xen.org
>>
>> [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
>>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>> CC: Don Slutz <dslutz@verizon.com>
>>
>> ---
>>     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
>>     time the script has been introduced).
>>
>>     Developpers using this script won't ommitted to cc some maintainers, and it
>>     will avoid maintainers complaining about miss CC.
>>
>>     The only drawbacks I can see is there is too much people CCed (the
>>     patch d67738db was intended to avoid CCing Keir too often).
> 
> My tree doesn't have in it d67738db but from the example you give above
> it seems like this patch will regress that? As someone who already gets
> too much mail and is listed in THE REST these days I am very much in
> favour of not mailing THE REST when other maintainers have been found.

It's still the case with this patch. Before if a maintainer was both in
x86 section and "THE REST". It may end up to completely drop the
maintainer in the CC list.

By drawbacks I meant, if there is another bug in the script then we may
end up to cc too many people. Honestly I don't believe it's the case.

>>     Also, if the maintainers is referenced twice in the file MAINTAINERS with
>>     different email, the script won't notice it's duplicated and list 2 times.
>>     Though, for this one it could be fixed by modifying  the MAINTAINERS file.
>>     Is it worth for Xen 4.5? For know, it seems to only happen with Stefano.
> 

Regards.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:15:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUNz-00085D-KX; Thu, 20 Nov 2014 16:15:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrUNy-00084y-Uv
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:15:11 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9D/B5-09936-D831E645; Thu, 20 Nov 2014 16:15:09 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416500107!14189205!1
X-Originating-IP: [74.125.83.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13970 invoked from network); 20 Nov 2014 16:15:08 -0000
Received: from mail-ee0-f47.google.com (HELO mail-ee0-f47.google.com)
	(74.125.83.47)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:15:08 -0000
Received: by mail-ee0-f47.google.com with SMTP id e49so105621eek.6
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 08:15:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=OkRFFn+1V6PjWz2oJOR6VZiP1ga3CbQaOxSpwIDq434=;
	b=Xs7R+cvUXr24X0hWQKv9aG1rAxflbX2PqQMJ3owqec33h1YlFfbmK5ubN/y8f98f3+
	2T1Izzxzpgq0o2/J8eiDnqSXu3sIiD/UtnpjvHE/ikLThyC3l1HqxEoqP85v2bhUlQYI
	yP9xW+iJMX6mPxrwzUdjhdM3Xh3rsetRvXKhWRN0dSnvUOFkQ9GYP3xGI3Bp9xBU6618
	kb4ziMB0743bqI7mGiEeDu5W2gFHaiUtEE4+8A2y1Es7hegnRpsPQCNksrmFenEfugWp
	BxVmLcZeXoF4XNzBFDbozPGacPBbYYp55kmpYr6g1QbGC40h4BQG4puzBiFNOolHgFSg
	t2Rw==
X-Gm-Message-State: ALoCoQl3S+IupsSiGruIXlgK0Sg43g0F05hiZgclU95CJye7mq65CLrqAFW6cAegAf7OiyMQY5Ey
X-Received: by 10.194.193.2 with SMTP id hk2mr54392308wjc.40.1416500107578;
	Thu, 20 Nov 2014 08:15:07 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id p7sm3968521wjo.38.2014.11.20.08.15.06
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 08:15:06 -0800 (PST)
Message-ID: <546E1389.1070304@linaro.org>
Date: Thu, 20 Nov 2014 16:15:05 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com>
In-Reply-To: <1416499682.14429.41.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 11/20/2014 04:08 PM, Ian Campbell wrote:
> On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
>> By default, the script get_maintainer.pl will remove duplicates email as soon
>> as it appends the list of maintainers of a new file, and therefore override
>> the role of the developper.
>>
>> On complex patch (see [1]), this will result to ommitting randomly some
>> maintainers.
>>
>> This could be fixed
> 
> Are you proposing an alternative/better fix here? or describing what
> this patch does?

Describing what the patch does.

>>  by not removing the duplicate email in the list. Once the
>> list is created, when it's necessary, the script will drop the "REST" people
>> and remove duplicata.
>>
>> Example:
>>
>> Patch: https://patches.linaro.org/41083/
>>
>> Before:
>>
>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Ian Jackson <ian.jackson@eu.citrix.com>
>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Ian Campbell <ian.campbell@citrix.com>
>> Wei Liu <wei.liu2@citrix.com>
>> George Dunlap <george.dunlap@eu.citrix.com>
>> xen-devel@lists.xen.org
>>
>> After:
>>
>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Ian Jackson <ian.jackson@eu.citrix.com>
>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Ian Campbell <ian.campbell@citrix.com>
>> Wei Liu <wei.liu2@citrix.com>
>> Stefano Stabellini <stefano.stabellini@citrix.com>
>> Tim Deegan <tim@xen.org>
>> Keir Fraser <keir@xen.org>
>> Jan Beulich <jbeulich@suse.com>
>> George Dunlap <george.dunlap@eu.citrix.com>
>> xen-devel@lists.xen.org
>>
>> [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
>>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>> CC: Don Slutz <dslutz@verizon.com>
>>
>> ---
>>     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
>>     time the script has been introduced).
>>
>>     Developpers using this script won't ommitted to cc some maintainers, and it
>>     will avoid maintainers complaining about miss CC.
>>
>>     The only drawbacks I can see is there is too much people CCed (the
>>     patch d67738db was intended to avoid CCing Keir too often).
> 
> My tree doesn't have in it d67738db but from the example you give above
> it seems like this patch will regress that? As someone who already gets
> too much mail and is listed in THE REST these days I am very much in
> favour of not mailing THE REST when other maintainers have been found.

It's still the case with this patch. Before if a maintainer was both in
x86 section and "THE REST". It may end up to completely drop the
maintainer in the CC list.

By drawbacks I meant, if there is another bug in the script then we may
end up to cc too many people. Honestly I don't believe it's the case.

>>     Also, if the maintainers is referenced twice in the file MAINTAINERS with
>>     different email, the script won't notice it's duplicated and list 2 times.
>>     Though, for this one it could be fixed by modifying  the MAINTAINERS file.
>>     Is it worth for Xen 4.5? For know, it seems to only happen with Stefano.
> 

Regards.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:15:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUO9-00086m-0Y; Thu, 20 Nov 2014 16:15:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>)
	id 1XrUO8-00086X-1a; Thu, 20 Nov 2014 16:15:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A5/62-25276-7931E645; Thu, 20 Nov 2014 16:15:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416500114!14147022!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4579 invoked from network); 20 Nov 2014 16:15: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;
	20 Nov 2014 16:15:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194861237"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 11:15:13 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrUO1-00068m-8H;
	Thu, 20 Nov 2014 16:15:13 +0000
Date: Thu, 20 Nov 2014 16:14:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416494946.14429.13.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411201613300.12596@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Jim Fehlig <jfehlig@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-users@lists.xen.org, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Ian Campbell wrote:
> On Thu, 2014-11-20 at 14:46 +0000, Stefano Stabellini wrote:
> > On Thu, 20 Nov 2014, Ian Campbell wrote:
> > > There is, it's the romfile option to -device e.g.
> > >          -device $NICMODEL,vlan=0,romfile=$ROMFILE
> > >         
> > > where NICMODEL is e100, rtl8139, virtio-blah
> > > and ROMFILE is e.g. an ipxe binary.
> > 
> > I think that option was intended to point QEMU to a different file, not
> > to disable the romfile.
> 
> romfile="" does that, I think. Or use /dev/null etc etc.

Confirmed working.

---

libxl: do not load roms for any NICs except the first to avoid wasting memory

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..f907ca9 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 LIBXL_NIC_TYPE_VIF_IOEMU);
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
-                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
+                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
                                                 nics[i].model, nics[i].devid,
-                                                nics[i].devid, smac));
+                                                nics[i].devid, smac,
+                                                i ? ",romfile=\"\"" : ""));
                 flexarray_append(dm_args, "-netdev");
                 flexarray_append(dm_args, GCSPRINTF(
                                           "type=tap,id=net%d,ifname=%s,"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:15:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUO9-00086m-0Y; Thu, 20 Nov 2014 16:15:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>)
	id 1XrUO8-00086X-1a; Thu, 20 Nov 2014 16:15:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A5/62-25276-7931E645; Thu, 20 Nov 2014 16:15:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416500114!14147022!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4579 invoked from network); 20 Nov 2014 16:15: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;
	20 Nov 2014 16:15:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="194861237"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 11:15:13 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrUO1-00068m-8H;
	Thu, 20 Nov 2014 16:15:13 +0000
Date: Thu, 20 Nov 2014 16:14:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416494946.14429.13.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411201613300.12596@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Jim Fehlig <jfehlig@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-users@lists.xen.org, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re:
 Re: [Xen-users] libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm
 <emulator> did not work on xen-4.4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, Ian Campbell wrote:
> On Thu, 2014-11-20 at 14:46 +0000, Stefano Stabellini wrote:
> > On Thu, 20 Nov 2014, Ian Campbell wrote:
> > > There is, it's the romfile option to -device e.g.
> > >          -device $NICMODEL,vlan=0,romfile=$ROMFILE
> > >         
> > > where NICMODEL is e100, rtl8139, virtio-blah
> > > and ROMFILE is e.g. an ipxe binary.
> > 
> > I think that option was intended to point QEMU to a different file, not
> > to disable the romfile.
> 
> romfile="" does that, I think. Or use /dev/null etc etc.

Confirmed working.

---

libxl: do not load roms for any NICs except the first to avoid wasting memory

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..f907ca9 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 LIBXL_NIC_TYPE_VIF_IOEMU);
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
-                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
+                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
                                                 nics[i].model, nics[i].devid,
-                                                nics[i].devid, smac));
+                                                nics[i].devid, smac,
+                                                i ? ",romfile=\"\"" : ""));
                 flexarray_append(dm_args, "-netdev");
                 flexarray_append(dm_args, GCSPRINTF(
                                           "type=tap,id=net%d,ifname=%s,"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:17:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16: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 1XrUPy-0008Se-7J; Thu, 20 Nov 2014 16:17:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrUPx-0008SL-Ai
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:17:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	54/A5-25276-8041E645; Thu, 20 Nov 2014 16:17:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416500228!14230275!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10444 invoked from network); 20 Nov 2014 16:17:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:17:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193328408"
Message-ID: <1416500123.20161.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 20 Nov 2014 16:15:23 +0000
In-Reply-To: <546E1206.5080403@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416499238.14429.39.camel@citrix.com> <546E1206.5080403@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
> On 20/11/14 16:00, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
> >> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> >> parse bootloader configuration files.
> >>
> >> c/s d1b93ea itself changed an an interface which previously used exclusively
> >> integers, to using strings in the case of a grub configuration with explicit
> >> default set, along with changing the code calling the interface to require a
> >> string.  The default value for "default" remained as an integer.
> >>
> >> As a result, any Extlinux or Lilo configuration (which drives this interface
> >> exclusively with integers), or Grub configuration which doesn't explicitly
> >> declare a default will die with an AttributeError when attempting to call
> >> "self.cf.default.isdigit()" where "default" is an integer.
> >>
> >> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
> >> which searches partitions for valid bootloader configurations, causing the
> >> issue to be reported as "Unable to find partition containing kernel"
> >>
> >> This patch attempts to fix the issue by altering all parts of this interface
> >> to use strings, as opposed to integers.
> > Would it be less invasive at this point in the release to have the place
> > where this stuff is used do isinstance(s, str) and isinstance(s, int)?
> 
> It would be BaseString not str, but I am fairly sure the classes have
> altered through Py2's history.  I would not be any more confident with
> that as a solution as trying to correctly to start with.

Actually isinstance(s, basestring) is what the webpage I was looking at
said, but I cut-n-pasted the wrong thing.

But regardless could it not do something like:
   if !isinstance(foo.cf.default, int):
       blah = int(foo.cf.default)
   elif foo.cf.default.isdigit():
       blah = whatever
       
and avoid the confusion about what is/isn't a string class while still
fixing the issue?

> sel comes either from g.image_index() which strictly is an integer, or
> pulled out of the loop immediately preceding and strictly an integer.

Ah, good.

> I can't however find anything which could cause it to have the value
> -1.  All error paths I can spot use 0 instead and load the first entry.
> 
> ~Andrew
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:17:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16: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 1XrUPy-0008Se-7J; Thu, 20 Nov 2014 16:17:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrUPx-0008SL-Ai
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:17:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	54/A5-25276-8041E645; Thu, 20 Nov 2014 16:17:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416500228!14230275!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10444 invoked from network); 20 Nov 2014 16:17:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:17:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193328408"
Message-ID: <1416500123.20161.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 20 Nov 2014 16:15:23 +0000
In-Reply-To: <546E1206.5080403@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416499238.14429.39.camel@citrix.com> <546E1206.5080403@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
> On 20/11/14 16:00, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
> >> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> >> parse bootloader configuration files.
> >>
> >> c/s d1b93ea itself changed an an interface which previously used exclusively
> >> integers, to using strings in the case of a grub configuration with explicit
> >> default set, along with changing the code calling the interface to require a
> >> string.  The default value for "default" remained as an integer.
> >>
> >> As a result, any Extlinux or Lilo configuration (which drives this interface
> >> exclusively with integers), or Grub configuration which doesn't explicitly
> >> declare a default will die with an AttributeError when attempting to call
> >> "self.cf.default.isdigit()" where "default" is an integer.
> >>
> >> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
> >> which searches partitions for valid bootloader configurations, causing the
> >> issue to be reported as "Unable to find partition containing kernel"
> >>
> >> This patch attempts to fix the issue by altering all parts of this interface
> >> to use strings, as opposed to integers.
> > Would it be less invasive at this point in the release to have the place
> > where this stuff is used do isinstance(s, str) and isinstance(s, int)?
> 
> It would be BaseString not str, but I am fairly sure the classes have
> altered through Py2's history.  I would not be any more confident with
> that as a solution as trying to correctly to start with.

Actually isinstance(s, basestring) is what the webpage I was looking at
said, but I cut-n-pasted the wrong thing.

But regardless could it not do something like:
   if !isinstance(foo.cf.default, int):
       blah = int(foo.cf.default)
   elif foo.cf.default.isdigit():
       blah = whatever
       
and avoid the confusion about what is/isn't a string class while still
fixing the issue?

> sel comes either from g.image_index() which strictly is an integer, or
> pulled out of the loop immediately preceding and strictly an integer.

Ah, good.

> I can't however find anything which could cause it to have the value
> -1.  All error paths I can spot use 0 instead and load the first entry.
> 
> ~Andrew
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:18:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16: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 1XrUQq-0000BK-Ln; Thu, 20 Nov 2014 16:18:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrUQo-0000Ac-Nj
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:18:07 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	FB/76-02697-D341E645; Thu, 20 Nov 2014 16:18:05 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416500280!4925291!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24228 invoked from network); 20 Nov 2014 16:18:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:18:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193328715"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 11:16:06 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrUOs-0006AE-T6;
	Thu, 20 Nov 2014 16:16:06 +0000
Date: Thu, 20 Nov 2014 16:15:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMOSJXr-LU3++8pAeoojDQO4q36ZdNHMiZJEo9ivUf6h6w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411201615040.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
	<CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
	<alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
	<546DCD46.8000105@linaro.org>
	<CAH_mUMOSJXr-LU3++8pAeoojDQO4q36ZdNHMiZJEo9ivUf6h6w@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-677714462-1416500111=:12596"
Content-ID: <alpine.DEB.2.02.1411201615260.12596@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-677714462-1416500111=:12596
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1411201615261.12596@kaball.uk.xensource.com>

Already posted:

http://marc.info/?l=3Dxen-devel&m=3D141648092100568

Ian hasn't provided any feedback yet.

On Thu, 20 Nov 2014, Andrii Tseglytskyi wrote:
> I think I'll debug this a bit later - unfortunately, now don't have
> time for this. But I want to get rid of spurious interrupt here.
>=20
> BTW - Stefano are you going to post the patch that we created
> yesterday ? Will Ian accept it?
>=20
> Regards,
> Andrii
>=20
> On Thu, Nov 20, 2014 at 1:15 PM, Julien Grall <julien.grall@linaro.org> w=
rote:
> > On 11/20/2014 10:28 AM, Stefano Stabellini wrote:
> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> 19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=80=D0=B8=D1=
=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 "Stefano Stabellini" <stefano.stabellini@=
eu.citrix.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:
> >>>>
> >>>> On Wed, 19 Nov 2014, Julien Grall wrote:
> >>>>> On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> >>>>>> That's right, the maintenance interrupt handler is not called, but=
 it
> >>>>>> doesn't do anything so we are fine. The important thing is that an
> >>>>>> interrupt is sent and git_clear_lrs gets called on hypervisor entr=
y.
> >>>>>
> >>>>> It would be worth to write down this somewhere. Just in case someon=
e
> >>>>> decide to add code in maintenance interrupt later.
> >>>>
> >>>> Yes, I could add a comment in the handler
> >>>
> >>> Maybe it wouldn't take a lot of effort to fix it? I am just worrying =
that we may hide some issue -
> >>> typically spurious interrupt this not what is expected.
> >>
> >> My guess is that by clearing UIE before reading GICC_IAR, we "clear" t=
he
> >> maintenance interrupt too, as a consequence the following read to
> >> GICC_IAR would return 1023 (nothing to be read). As bit as if the
> >> maintenance interrupt was a level interrupt and we just disabled it.
> >>
> >> So I think that if we cleared UIE after reading GICC_IAR, GICC_IAR wou=
ld
> >> return the correct value.
> >>
> >> However with the current structure of the code, the first thing that w=
e
> >> do upon entering the hypervisor is clearing LRs and given what happene=
d
> >> on your platform I think is a good idea to do it with UIE disabled.
> >
> > Agreed. UIE should be disabled to avoid another maintenance interrupt a=
s
> > soon as we EOI the IRQ.
> >
> >> This is way I would rather read spurious interrupts but read/write LRs
> >> with UIE disabled than reading maintenance interrupts but risking
> >> strange behaviours on some platforms.
> >
> > Reading the GIC-v2 documentation, the spurious interrupt things should
> > happen on any platform every time the UIE is disabled while we receive =
a
> > maintenance interrupt.
> >
> > "The read returns a spurious interrupt ID of 1023 if any of the
> > following apply:
> >
> > - no pending interrupt on the CPU interface has sufficient priority for
> > the interface to signal it to the processor"
> >
> > --
> > Julien Grall
>=20
>=20
>=20
> --=20
>=20
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
>=20
--1342847746-677714462-1416500111=:12596
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-677714462-1416500111=:12596--


From xen-devel-bounces@lists.xen.org Thu Nov 20 16:18:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16: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 1XrUQq-0000BK-Ln; Thu, 20 Nov 2014 16:18:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrUQo-0000Ac-Nj
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:18:07 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	FB/76-02697-D341E645; Thu, 20 Nov 2014 16:18:05 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416500280!4925291!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24228 invoked from network); 20 Nov 2014 16:18:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:18:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193328715"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 11:16:06 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrUOs-0006AE-T6;
	Thu, 20 Nov 2014 16:16:06 +0000
Date: Thu, 20 Nov 2014 16:15:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
In-Reply-To: <CAH_mUMOSJXr-LU3++8pAeoojDQO4q36ZdNHMiZJEo9ivUf6h6w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411201615040.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
	<CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
	<alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
	<546DCD46.8000105@linaro.org>
	<CAH_mUMOSJXr-LU3++8pAeoojDQO4q36ZdNHMiZJEo9ivUf6h6w@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-677714462-1416500111=:12596"
Content-ID: <alpine.DEB.2.02.1411201615260.12596@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: Julien Grall <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-677714462-1416500111=:12596
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1411201615261.12596@kaball.uk.xensource.com>

Already posted:

http://marc.info/?l=3Dxen-devel&m=3D141648092100568

Ian hasn't provided any feedback yet.

On Thu, 20 Nov 2014, Andrii Tseglytskyi wrote:
> I think I'll debug this a bit later - unfortunately, now don't have
> time for this. But I want to get rid of spurious interrupt here.
>=20
> BTW - Stefano are you going to post the patch that we created
> yesterday ? Will Ian accept it?
>=20
> Regards,
> Andrii
>=20
> On Thu, Nov 20, 2014 at 1:15 PM, Julien Grall <julien.grall@linaro.org> w=
rote:
> > On 11/20/2014 10:28 AM, Stefano Stabellini wrote:
> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> 19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=80=D0=B8=D1=
=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 "Stefano Stabellini" <stefano.stabellini@=
eu.citrix.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:
> >>>>
> >>>> On Wed, 19 Nov 2014, Julien Grall wrote:
> >>>>> On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> >>>>>> That's right, the maintenance interrupt handler is not called, but=
 it
> >>>>>> doesn't do anything so we are fine. The important thing is that an
> >>>>>> interrupt is sent and git_clear_lrs gets called on hypervisor entr=
y.
> >>>>>
> >>>>> It would be worth to write down this somewhere. Just in case someon=
e
> >>>>> decide to add code in maintenance interrupt later.
> >>>>
> >>>> Yes, I could add a comment in the handler
> >>>
> >>> Maybe it wouldn't take a lot of effort to fix it? I am just worrying =
that we may hide some issue -
> >>> typically spurious interrupt this not what is expected.
> >>
> >> My guess is that by clearing UIE before reading GICC_IAR, we "clear" t=
he
> >> maintenance interrupt too, as a consequence the following read to
> >> GICC_IAR would return 1023 (nothing to be read). As bit as if the
> >> maintenance interrupt was a level interrupt and we just disabled it.
> >>
> >> So I think that if we cleared UIE after reading GICC_IAR, GICC_IAR wou=
ld
> >> return the correct value.
> >>
> >> However with the current structure of the code, the first thing that w=
e
> >> do upon entering the hypervisor is clearing LRs and given what happene=
d
> >> on your platform I think is a good idea to do it with UIE disabled.
> >
> > Agreed. UIE should be disabled to avoid another maintenance interrupt a=
s
> > soon as we EOI the IRQ.
> >
> >> This is way I would rather read spurious interrupts but read/write LRs
> >> with UIE disabled than reading maintenance interrupts but risking
> >> strange behaviours on some platforms.
> >
> > Reading the GIC-v2 documentation, the spurious interrupt things should
> > happen on any platform every time the UIE is disabled while we receive =
a
> > maintenance interrupt.
> >
> > "The read returns a spurious interrupt ID of 1023 if any of the
> > following apply:
> >
> > - no pending interrupt on the CPU interface has sufficient priority for
> > the interface to signal it to the processor"
> >
> > --
> > Julien Grall
>=20
>=20
>=20
> --=20
>=20
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
>=20
--1342847746-677714462-1416500111=:12596
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-677714462-1416500111=:12596--


From xen-devel-bounces@lists.xen.org Thu Nov 20 16:22:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUUe-0000YP-CV; Thu, 20 Nov 2014 16:22:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrUUd-0000YJ-4i
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:22:03 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	62/F6-27785-A251E645; Thu, 20 Nov 2014 16:22:02 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416500521!13811673!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22430 invoked from network); 20 Nov 2014 16:22:01 -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;
	20 Nov 2014 16:22:01 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so9233310wiv.12
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 08:22:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=Bs3yFdwHxHLyxWIdNpOZc4vzAXDAbZCkamO7uVfuuII=;
	b=MDcb98yRgRIfXqOlOBqX6nyel9TWMXjYfOkEMcjOV/+2QqBdMMJptk3o/0inqiscak
	+2bEy7k9laTWXUDLGjYHmnDaZ5g5S8REJW7xHfP4czlsdyDjlXolAB1YH/lRwTbS7rV3
	BOkUyKOZ70kX6L2yX1FCfiRF1taiB4qovJlm4tjvRrJmEv35qn7vkPuttiU5mWYVFv21
	JnjU+SpGa8JfimGDSXvTXg9KTLimLuhTjYoQv+VdNj7gSGMlVrQdiChm/6eJ05W5p/KR
	CC5fQQFHAwvGakMkjx3it1IbzAkupZI3+6VvEXVJYxAgodszUCYtDPVJ6NT3xMrYRovW
	EyXw==
X-Gm-Message-State: ALoCoQnT+M9WbazA4GFbRujGzol261MgAKq9yPCxxL/RP/B6JNAVBcojN1+9GoMaIKZkJ+5GoifL
X-Received: by 10.180.88.165 with SMTP id bh5mr16855944wib.77.1416500520853;
	Thu, 20 Nov 2014 08:22:00 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fl1sm7269470wib.15.2014.11.20.08.21.59
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 08:22:00 -0800 (PST)
Message-ID: <546E1526.6090406@linaro.org>
Date: Thu, 20 Nov 2014 16:21:58 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com>
	<546E1389.1070304@linaro.org>
In-Reply-To: <546E1389.1070304@linaro.org>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 04:15 PM, Julien Grall wrote:
> Hi Ian,
> 
> On 11/20/2014 04:08 PM, Ian Campbell wrote:
>> On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
>>> By default, the script get_maintainer.pl will remove duplicates email as soon
>>> as it appends the list of maintainers of a new file, and therefore override
>>> the role of the developper.
>>>
>>> On complex patch (see [1]), this will result to ommitting randomly some
>>> maintainers.
>>>
>>> This could be fixed
>>
>> Are you proposing an alternative/better fix here? or describing what
>> this patch does?
> 
> Describing what the patch does.
> 
>>>  by not removing the duplicate email in the list. Once the
>>> list is created, when it's necessary, the script will drop the "REST" people
>>> and remove duplicata.
>>>
>>> Example:
>>>
>>> Patch: https://patches.linaro.org/41083/
>>>
>>> Before:
>>>
>>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>> Ian Jackson <ian.jackson@eu.citrix.com>
>>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Ian Campbell <ian.campbell@citrix.com>
>>> Wei Liu <wei.liu2@citrix.com>
>>> George Dunlap <george.dunlap@eu.citrix.com>
>>> xen-devel@lists.xen.org
>>>
>>> After:
>>>
>>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>> Ian Jackson <ian.jackson@eu.citrix.com>
>>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Ian Campbell <ian.campbell@citrix.com>
>>> Wei Liu <wei.liu2@citrix.com>
>>> Stefano Stabellini <stefano.stabellini@citrix.com>
>>> Tim Deegan <tim@xen.org>
>>> Keir Fraser <keir@xen.org>
>>> Jan Beulich <jbeulich@suse.com>
>>> George Dunlap <george.dunlap@eu.citrix.com>
>>> xen-devel@lists.xen.org
>>>
>>> [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
>>>
>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>> CC: Don Slutz <dslutz@verizon.com>
>>>
>>> ---
>>>     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
>>>     time the script has been introduced).
>>>
>>>     Developpers using this script won't ommitted to cc some maintainers, and it
>>>     will avoid maintainers complaining about miss CC.
>>>
>>>     The only drawbacks I can see is there is too much people CCed (the
>>>     patch d67738db was intended to avoid CCing Keir too often).
>>
>> My tree doesn't have in it d67738db but from the example you give above
>> it seems like this patch will regress that? As someone who already gets
>> too much mail and is listed in THE REST these days I am very much in
>> favour of not mailing THE REST when other maintainers have been found.

Forgot to add, the example above show the difference without and with
the patch. The list is correct because both ARM and x86 maintainers
should be CC. Because of this all "THE REST" maintainers are added.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:22:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUUe-0000YP-CV; Thu, 20 Nov 2014 16:22:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrUUd-0000YJ-4i
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:22:03 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	62/F6-27785-A251E645; Thu, 20 Nov 2014 16:22:02 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416500521!13811673!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22430 invoked from network); 20 Nov 2014 16:22:01 -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;
	20 Nov 2014 16:22:01 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so9233310wiv.12
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 08:22:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=Bs3yFdwHxHLyxWIdNpOZc4vzAXDAbZCkamO7uVfuuII=;
	b=MDcb98yRgRIfXqOlOBqX6nyel9TWMXjYfOkEMcjOV/+2QqBdMMJptk3o/0inqiscak
	+2bEy7k9laTWXUDLGjYHmnDaZ5g5S8REJW7xHfP4czlsdyDjlXolAB1YH/lRwTbS7rV3
	BOkUyKOZ70kX6L2yX1FCfiRF1taiB4qovJlm4tjvRrJmEv35qn7vkPuttiU5mWYVFv21
	JnjU+SpGa8JfimGDSXvTXg9KTLimLuhTjYoQv+VdNj7gSGMlVrQdiChm/6eJ05W5p/KR
	CC5fQQFHAwvGakMkjx3it1IbzAkupZI3+6VvEXVJYxAgodszUCYtDPVJ6NT3xMrYRovW
	EyXw==
X-Gm-Message-State: ALoCoQnT+M9WbazA4GFbRujGzol261MgAKq9yPCxxL/RP/B6JNAVBcojN1+9GoMaIKZkJ+5GoifL
X-Received: by 10.180.88.165 with SMTP id bh5mr16855944wib.77.1416500520853;
	Thu, 20 Nov 2014 08:22:00 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fl1sm7269470wib.15.2014.11.20.08.21.59
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 08:22:00 -0800 (PST)
Message-ID: <546E1526.6090406@linaro.org>
Date: Thu, 20 Nov 2014 16:21:58 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com>
	<546E1389.1070304@linaro.org>
In-Reply-To: <546E1389.1070304@linaro.org>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 04:15 PM, Julien Grall wrote:
> Hi Ian,
> 
> On 11/20/2014 04:08 PM, Ian Campbell wrote:
>> On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
>>> By default, the script get_maintainer.pl will remove duplicates email as soon
>>> as it appends the list of maintainers of a new file, and therefore override
>>> the role of the developper.
>>>
>>> On complex patch (see [1]), this will result to ommitting randomly some
>>> maintainers.
>>>
>>> This could be fixed
>>
>> Are you proposing an alternative/better fix here? or describing what
>> this patch does?
> 
> Describing what the patch does.
> 
>>>  by not removing the duplicate email in the list. Once the
>>> list is created, when it's necessary, the script will drop the "REST" people
>>> and remove duplicata.
>>>
>>> Example:
>>>
>>> Patch: https://patches.linaro.org/41083/
>>>
>>> Before:
>>>
>>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>> Ian Jackson <ian.jackson@eu.citrix.com>
>>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Ian Campbell <ian.campbell@citrix.com>
>>> Wei Liu <wei.liu2@citrix.com>
>>> George Dunlap <george.dunlap@eu.citrix.com>
>>> xen-devel@lists.xen.org
>>>
>>> After:
>>>
>>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>> Ian Jackson <ian.jackson@eu.citrix.com>
>>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Ian Campbell <ian.campbell@citrix.com>
>>> Wei Liu <wei.liu2@citrix.com>
>>> Stefano Stabellini <stefano.stabellini@citrix.com>
>>> Tim Deegan <tim@xen.org>
>>> Keir Fraser <keir@xen.org>
>>> Jan Beulich <jbeulich@suse.com>
>>> George Dunlap <george.dunlap@eu.citrix.com>
>>> xen-devel@lists.xen.org
>>>
>>> [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
>>>
>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>> CC: Don Slutz <dslutz@verizon.com>
>>>
>>> ---
>>>     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
>>>     time the script has been introduced).
>>>
>>>     Developpers using this script won't ommitted to cc some maintainers, and it
>>>     will avoid maintainers complaining about miss CC.
>>>
>>>     The only drawbacks I can see is there is too much people CCed (the
>>>     patch d67738db was intended to avoid CCing Keir too often).
>>
>> My tree doesn't have in it d67738db but from the example you give above
>> it seems like this patch will regress that? As someone who already gets
>> too much mail and is listed in THE REST these days I am very much in
>> favour of not mailing THE REST when other maintainers have been found.

Forgot to add, the example above show the difference without and with
the patch. The list is correct because both ARM and x86 maintainers
should be CC. Because of this all "THE REST" maintainers are added.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:27:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:27:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUZS-0000tv-82; Thu, 20 Nov 2014 16:27:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrUZQ-0000tL-2w; Thu, 20 Nov 2014 16:27:00 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7E/35-25276-3561E645; Thu, 20 Nov 2014 16:26:59 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416500817!14192340!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17932 invoked from network); 20 Nov 2014 16:26:58 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Nov 2014 16:26:58 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrUZD-0000KI-84; Thu, 20 Nov 2014 16:26:47 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrUZC-0008CI-Rd; Thu, 20 Nov 2014 16:26:46 +0000
Date: Thu, 20 Nov 2014 16:26:46 +0000
Message-Id: <E1XrUZC-0008CI-Rd@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 113 - Guest effectable page
 reference leak in MMU_MACHPHYS_UPDATE handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                    Xen Security Advisory XSA-113

  Guest effectable page reference leak in MMU_MACHPHYS_UPDATE handling

ISSUE DESCRIPTION
=================

An error handling path in the processing of MMU_MACHPHYS_UPDATE failed
to drop a page reference which was acquired in an earlier processing
step.

IMPACT
======

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.

Only domains controlling HVM guests can exploit this vulnerability.
(This includes domains providing hardware emulation services to HVM
guests.)

VULNERABLE SYSTEMS
==================

Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
Older versions have not been inspected.  ARM systems are not vulnerable.

This vulnerability is only applicable to Xen systems using stub domains
or other forms of disaggregation of control domains for HVM guests.

MITIGATION
==========

Running only PV guests will avoid this issue.

(The security of a Xen system using stub domains is still better than
with a qemu-dm running as an unrestricted dom0 process.  Therefore
users with these configurations should not switch to an unrestricted
dom0 qemu-dm.)

NOTE REGARDING LACK OF EMBARGO
==============================

A draft of this advisory was mistakenly sent to xen-devel.  The Xen
Project Security Team apologises for this error.  We are working to
share best working practices amongst the team to reduce the risks of
recurrance.

CREDITS
=======

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa113.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x

$ sha256sum xsa113*.patch
a0f2b792a6b4648151f85fe13961b0bf309a568ed03e1b1d4ea01e4eabf1b18e  xsa113.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUbhNoAAoJEIP+FMlX6CvZ5v8H/0cwnDOmSUZQ5Wm6ULUQH0w+
Jbsf6JPBRyDch1nCv/d8X27vSfmB8JH0m+LclEH0F1XSUiu5p4y46ZKk7Zfm4+gD
xq6/eKyXKwCXinAwEcLtvfONrajQQvzk2y4XZpE+g9U00AwvsBXM3AdqPup8cyQl
OLQO9Oq+xiqusCXIQeCb/KnoVUGS9PqlG/RT3rKKorYzuQjG7VURU3uKA1Vju7oD
ITzbNCjTjnA7cFVSk6g9ZG6k40nGkVKIv+pPFfZAE6/UqiCF91oNzVAYVnA0X0oL
YoAFxvVFOHp78192jW/7S8uacG+bskJNAr+NYIuaBlykka6Vbef6esWOW3UZEhA=
=LDjw
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa113.patch"
Content-Disposition: attachment; filename="xsa113.patch"
Content-Transfer-Encoding: base64

eDg2L21tOiBmaXggYSByZWZlcmVuY2UgY291bnRpbmcgZXJyb3IgaW4gTU1V
X01BQ0hQSFlTX1VQREFURQoKQW55IGRvbWFpbiB3aGljaCBjYW4gcGFzcyB0
aGUgWFNNIGNoZWNrIGFnYWluc3QgYSB0cmFuc2xhdGVkIGd1ZXN0IGNhbiBj
YXVzZSBhCnBhZ2UgcmVmZXJlbmNlIHRvIGJlIGxlYWtlZC4KCldoaWxlIHNo
dWZmbGluZyB0aGUgb3JkZXIgb2YgY2hlY2tzLCBkcm9wIHRoZSBxdWl0ZS1w
b2ludGxlc3MgTUVNX0xPRygpLiAgVGhpcwpicmluZ3MgdGhlIGNoZWNrIGlu
IGxpbmUgd2l0aCBzaW1pbGFyIGNoZWNrcyBpbiB0aGUgdmljaW5pdHkuCgpE
aXNjb3ZlcmVkIHdoaWxlIHJldmlld2luZyB0aGUgWFNBLTEwOS8xMTAgZm9s
bG93dXAgc2VyaWVzLgoKVGhpcyBpcyBYU0EtMTEzLgoKU2lnbmVkLW9mZi1i
eTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4K
UmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
UmV2aWV3ZWQtYnk6IFRpbSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoKLS0tIGEv
eGVuL2FyY2gveDg2L21tLmMKKysrIGIveGVuL2FyY2gveDg2L21tLmMKQEAg
LTM2MTksNiArMzYxOSwxMiBAQCBsb25nIGRvX21tdV91cGRhdGUoCiAKICAg
ICAgICAgY2FzZSBNTVVfTUFDSFBIWVNfVVBEQVRFOgogCisgICAgICAgICAg
ICBpZiAoIHVubGlrZWx5KHBhZ2luZ19tb2RlX3RyYW5zbGF0ZShwZ19vd25l
cikpICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICByYyA9IC1F
SU5WQUw7CisgICAgICAgICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICB9
CisKICAgICAgICAgICAgIG1mbiA9IHJlcS5wdHIgPj4gUEFHRV9TSElGVDsK
ICAgICAgICAgICAgIGdwZm4gPSByZXEudmFsOwogCkBAIC0zNjM4LDEzICsz
NjQ0LDYgQEAgbG9uZyBkb19tbXVfdXBkYXRlKAogICAgICAgICAgICAgICAg
IGJyZWFrOwogICAgICAgICAgICAgfQogCi0gICAgICAgICAgICBpZiAoIHVu
bGlrZWx5KHBhZ2luZ19tb2RlX3RyYW5zbGF0ZShwZ19vd25lcikpICkKLSAg
ICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBNRU1fTE9HKCJNYWNoLXBo
eXMgdXBkYXRlIG9uIGF1dG8tdHJhbnNsYXRlIGd1ZXN0Iik7Ci0gICAgICAg
ICAgICAgICAgcmMgPSAtRUlOVkFMOwotICAgICAgICAgICAgICAgIGJyZWFr
OwotICAgICAgICAgICAgfQotCiAgICAgICAgICAgICBzZXRfZ3Bmbl9mcm9t
X21mbihtZm4sIGdwZm4pOwogCiAgICAgICAgICAgICBwYWdpbmdfbWFya19k
aXJ0eShwZ19vd25lciwgbWZuKTsK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Thu Nov 20 16:27:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:27:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUZS-0000tv-82; Thu, 20 Nov 2014 16:27:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrUZQ-0000tL-2w; Thu, 20 Nov 2014 16:27:00 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7E/35-25276-3561E645; Thu, 20 Nov 2014 16:26:59 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416500817!14192340!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17932 invoked from network); 20 Nov 2014 16:26:58 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Nov 2014 16:26:58 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrUZD-0000KI-84; Thu, 20 Nov 2014 16:26:47 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrUZC-0008CI-Rd; Thu, 20 Nov 2014 16:26:46 +0000
Date: Thu, 20 Nov 2014 16:26:46 +0000
Message-Id: <E1XrUZC-0008CI-Rd@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 113 - Guest effectable page
 reference leak in MMU_MACHPHYS_UPDATE handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                    Xen Security Advisory XSA-113

  Guest effectable page reference leak in MMU_MACHPHYS_UPDATE handling

ISSUE DESCRIPTION
=================

An error handling path in the processing of MMU_MACHPHYS_UPDATE failed
to drop a page reference which was acquired in an earlier processing
step.

IMPACT
======

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.

Only domains controlling HVM guests can exploit this vulnerability.
(This includes domains providing hardware emulation services to HVM
guests.)

VULNERABLE SYSTEMS
==================

Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
Older versions have not been inspected.  ARM systems are not vulnerable.

This vulnerability is only applicable to Xen systems using stub domains
or other forms of disaggregation of control domains for HVM guests.

MITIGATION
==========

Running only PV guests will avoid this issue.

(The security of a Xen system using stub domains is still better than
with a qemu-dm running as an unrestricted dom0 process.  Therefore
users with these configurations should not switch to an unrestricted
dom0 qemu-dm.)

NOTE REGARDING LACK OF EMBARGO
==============================

A draft of this advisory was mistakenly sent to xen-devel.  The Xen
Project Security Team apologises for this error.  We are working to
share best working practices amongst the team to reduce the risks of
recurrance.

CREDITS
=======

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa113.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x

$ sha256sum xsa113*.patch
a0f2b792a6b4648151f85fe13961b0bf309a568ed03e1b1d4ea01e4eabf1b18e  xsa113.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUbhNoAAoJEIP+FMlX6CvZ5v8H/0cwnDOmSUZQ5Wm6ULUQH0w+
Jbsf6JPBRyDch1nCv/d8X27vSfmB8JH0m+LclEH0F1XSUiu5p4y46ZKk7Zfm4+gD
xq6/eKyXKwCXinAwEcLtvfONrajQQvzk2y4XZpE+g9U00AwvsBXM3AdqPup8cyQl
OLQO9Oq+xiqusCXIQeCb/KnoVUGS9PqlG/RT3rKKorYzuQjG7VURU3uKA1Vju7oD
ITzbNCjTjnA7cFVSk6g9ZG6k40nGkVKIv+pPFfZAE6/UqiCF91oNzVAYVnA0X0oL
YoAFxvVFOHp78192jW/7S8uacG+bskJNAr+NYIuaBlykka6Vbef6esWOW3UZEhA=
=LDjw
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa113.patch"
Content-Disposition: attachment; filename="xsa113.patch"
Content-Transfer-Encoding: base64

eDg2L21tOiBmaXggYSByZWZlcmVuY2UgY291bnRpbmcgZXJyb3IgaW4gTU1V
X01BQ0hQSFlTX1VQREFURQoKQW55IGRvbWFpbiB3aGljaCBjYW4gcGFzcyB0
aGUgWFNNIGNoZWNrIGFnYWluc3QgYSB0cmFuc2xhdGVkIGd1ZXN0IGNhbiBj
YXVzZSBhCnBhZ2UgcmVmZXJlbmNlIHRvIGJlIGxlYWtlZC4KCldoaWxlIHNo
dWZmbGluZyB0aGUgb3JkZXIgb2YgY2hlY2tzLCBkcm9wIHRoZSBxdWl0ZS1w
b2ludGxlc3MgTUVNX0xPRygpLiAgVGhpcwpicmluZ3MgdGhlIGNoZWNrIGlu
IGxpbmUgd2l0aCBzaW1pbGFyIGNoZWNrcyBpbiB0aGUgdmljaW5pdHkuCgpE
aXNjb3ZlcmVkIHdoaWxlIHJldmlld2luZyB0aGUgWFNBLTEwOS8xMTAgZm9s
bG93dXAgc2VyaWVzLgoKVGhpcyBpcyBYU0EtMTEzLgoKU2lnbmVkLW9mZi1i
eTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4K
UmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
UmV2aWV3ZWQtYnk6IFRpbSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoKLS0tIGEv
eGVuL2FyY2gveDg2L21tLmMKKysrIGIveGVuL2FyY2gveDg2L21tLmMKQEAg
LTM2MTksNiArMzYxOSwxMiBAQCBsb25nIGRvX21tdV91cGRhdGUoCiAKICAg
ICAgICAgY2FzZSBNTVVfTUFDSFBIWVNfVVBEQVRFOgogCisgICAgICAgICAg
ICBpZiAoIHVubGlrZWx5KHBhZ2luZ19tb2RlX3RyYW5zbGF0ZShwZ19vd25l
cikpICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICByYyA9IC1F
SU5WQUw7CisgICAgICAgICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICB9
CisKICAgICAgICAgICAgIG1mbiA9IHJlcS5wdHIgPj4gUEFHRV9TSElGVDsK
ICAgICAgICAgICAgIGdwZm4gPSByZXEudmFsOwogCkBAIC0zNjM4LDEzICsz
NjQ0LDYgQEAgbG9uZyBkb19tbXVfdXBkYXRlKAogICAgICAgICAgICAgICAg
IGJyZWFrOwogICAgICAgICAgICAgfQogCi0gICAgICAgICAgICBpZiAoIHVu
bGlrZWx5KHBhZ2luZ19tb2RlX3RyYW5zbGF0ZShwZ19vd25lcikpICkKLSAg
ICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBNRU1fTE9HKCJNYWNoLXBo
eXMgdXBkYXRlIG9uIGF1dG8tdHJhbnNsYXRlIGd1ZXN0Iik7Ci0gICAgICAg
ICAgICAgICAgcmMgPSAtRUlOVkFMOwotICAgICAgICAgICAgICAgIGJyZWFr
OwotICAgICAgICAgICAgfQotCiAgICAgICAgICAgICBzZXRfZ3Bmbl9mcm9t
X21mbihtZm4sIGdwZm4pOwogCiAgICAgICAgICAgICBwYWdpbmdfbWFya19k
aXJ0eShwZ19vd25lciwgbWZuKTsK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Thu Nov 20 16:34:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:34:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUfe-0001WY-0s; Thu, 20 Nov 2014 16:33: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 1XrUfc-0001WO-8q
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:33:24 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	C9/57-02697-3D71E645; Thu, 20 Nov 2014 16:33:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416501200!12535646!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27720 invoked from network); 20 Nov 2014 16:33:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:33:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193336158"
Message-ID: <1416500962.20161.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 20 Nov 2014 16:29:22 +0000
In-Reply-To: <546E1526.6090406@linaro.org>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com> <546E1389.1070304@linaro.org>
	<546E1526.6090406@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:21 +0000, Julien Grall wrote:
> On 11/20/2014 04:15 PM, Julien Grall wrote:
> > Hi Ian,
> > 
> > On 11/20/2014 04:08 PM, Ian Campbell wrote:
> >> On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
> >>> By default, the script get_maintainer.pl will remove duplicates email as soon
> >>> as it appends the list of maintainers of a new file, and therefore override
> >>> the role of the developper.
> >>>
> >>> On complex patch (see [1]), this will result to ommitting randomly some
> >>> maintainers.
> >>>
> >>> This could be fixed
> >>
> >> Are you proposing an alternative/better fix here? or describing what
> >> this patch does?
> > 
> > Describing what the patch does.
> > 
> >>>  by not removing the duplicate email in the list. Once the
> >>> list is created, when it's necessary, the script will drop the "REST" people
> >>> and remove duplicata.
> >>>
> >>> Example:
> >>>
> >>> Patch: https://patches.linaro.org/41083/
> >>>
> >>> Before:
> >>>
> >>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >>> Ian Jackson <ian.jackson@eu.citrix.com>
> >>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> Ian Campbell <ian.campbell@citrix.com>
> >>> Wei Liu <wei.liu2@citrix.com>
> >>> George Dunlap <george.dunlap@eu.citrix.com>
> >>> xen-devel@lists.xen.org
> >>>
> >>> After:
> >>>
> >>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >>> Ian Jackson <ian.jackson@eu.citrix.com>
> >>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> Ian Campbell <ian.campbell@citrix.com>
> >>> Wei Liu <wei.liu2@citrix.com>
> >>> Stefano Stabellini <stefano.stabellini@citrix.com>
> >>> Tim Deegan <tim@xen.org>
> >>> Keir Fraser <keir@xen.org>
> >>> Jan Beulich <jbeulich@suse.com>
> >>> George Dunlap <george.dunlap@eu.citrix.com>
> >>> xen-devel@lists.xen.org
> >>>
> >>> [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
> >>>
> >>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >>> CC: Don Slutz <dslutz@verizon.com>
> >>>
> >>> ---
> >>>     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
> >>>     time the script has been introduced).
> >>>
> >>>     Developpers using this script won't ommitted to cc some maintainers, and it
> >>>     will avoid maintainers complaining about miss CC.
> >>>
> >>>     The only drawbacks I can see is there is too much people CCed (the
> >>>     patch d67738db was intended to avoid CCing Keir too often).
> >>
> >> My tree doesn't have in it d67738db but from the example you give above
> >> it seems like this patch will regress that? As someone who already gets
> >> too much mail and is listed in THE REST these days I am very much in
> >> favour of not mailing THE REST when other maintainers have been found.
> 
> Forgot to add, the example above show the difference without and with
> the patch. The list is correct because both ARM and x86 maintainers
> should be CC. Because of this all "THE REST" maintainers are added.

Just to be clear, you mean that everyone under THE REST is added solely
because they also happen to be maintainers of some other relevant bit of
code, not that THE REST is explicitly added in this case, right?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:34:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:34:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUfe-0001WY-0s; Thu, 20 Nov 2014 16:33: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 1XrUfc-0001WO-8q
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:33:24 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	C9/57-02697-3D71E645; Thu, 20 Nov 2014 16:33:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416501200!12535646!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27720 invoked from network); 20 Nov 2014 16:33:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:33:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193336158"
Message-ID: <1416500962.20161.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 20 Nov 2014 16:29:22 +0000
In-Reply-To: <546E1526.6090406@linaro.org>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com> <546E1389.1070304@linaro.org>
	<546E1526.6090406@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:21 +0000, Julien Grall wrote:
> On 11/20/2014 04:15 PM, Julien Grall wrote:
> > Hi Ian,
> > 
> > On 11/20/2014 04:08 PM, Ian Campbell wrote:
> >> On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
> >>> By default, the script get_maintainer.pl will remove duplicates email as soon
> >>> as it appends the list of maintainers of a new file, and therefore override
> >>> the role of the developper.
> >>>
> >>> On complex patch (see [1]), this will result to ommitting randomly some
> >>> maintainers.
> >>>
> >>> This could be fixed
> >>
> >> Are you proposing an alternative/better fix here? or describing what
> >> this patch does?
> > 
> > Describing what the patch does.
> > 
> >>>  by not removing the duplicate email in the list. Once the
> >>> list is created, when it's necessary, the script will drop the "REST" people
> >>> and remove duplicata.
> >>>
> >>> Example:
> >>>
> >>> Patch: https://patches.linaro.org/41083/
> >>>
> >>> Before:
> >>>
> >>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >>> Ian Jackson <ian.jackson@eu.citrix.com>
> >>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> Ian Campbell <ian.campbell@citrix.com>
> >>> Wei Liu <wei.liu2@citrix.com>
> >>> George Dunlap <george.dunlap@eu.citrix.com>
> >>> xen-devel@lists.xen.org
> >>>
> >>> After:
> >>>
> >>> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >>> Ian Jackson <ian.jackson@eu.citrix.com>
> >>> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> Ian Campbell <ian.campbell@citrix.com>
> >>> Wei Liu <wei.liu2@citrix.com>
> >>> Stefano Stabellini <stefano.stabellini@citrix.com>
> >>> Tim Deegan <tim@xen.org>
> >>> Keir Fraser <keir@xen.org>
> >>> Jan Beulich <jbeulich@suse.com>
> >>> George Dunlap <george.dunlap@eu.citrix.com>
> >>> xen-devel@lists.xen.org
> >>>
> >>> [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
> >>>
> >>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >>> CC: Don Slutz <dslutz@verizon.com>
> >>>
> >>> ---
> >>>     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
> >>>     time the script has been introduced).
> >>>
> >>>     Developpers using this script won't ommitted to cc some maintainers, and it
> >>>     will avoid maintainers complaining about miss CC.
> >>>
> >>>     The only drawbacks I can see is there is too much people CCed (the
> >>>     patch d67738db was intended to avoid CCing Keir too often).
> >>
> >> My tree doesn't have in it d67738db but from the example you give above
> >> it seems like this patch will regress that? As someone who already gets
> >> too much mail and is listed in THE REST these days I am very much in
> >> favour of not mailing THE REST when other maintainers have been found.
> 
> Forgot to add, the example above show the difference without and with
> the patch. The list is correct because both ARM and x86 maintainers
> should be CC. Because of this all "THE REST" maintainers are added.

Just to be clear, you mean that everyone under THE REST is added solely
because they also happen to be maintainers of some other relevant bit of
code, not that THE REST is explicitly added in this case, right?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:34:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUgY-0001bn-Eq; Thu, 20 Nov 2014 16:34:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrUgW-0001bV-EO
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:34:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F4/41-25276-B081E645; Thu, 20 Nov 2014 16:34:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416501256!14194189!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6440 invoked from network); 20 Nov 2014 16:34:19 -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;
	20 Nov 2014 16:34:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193336730"
Message-ID: <1416501018.20161.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 20 Nov 2014 16:30:18 +0000
In-Reply-To: <546E1389.1070304@linaro.org>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com> <546E1389.1070304@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:15 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 11/20/2014 04:08 PM, Ian Campbell wrote:
> > On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
> >> By default, the script get_maintainer.pl will remove duplicates email as soon
> >> as it appends the list of maintainers of a new file, and therefore override
> >> the role of the developper.
> >>
> >> On complex patch (see [1]), this will result to ommitting randomly some
> >> maintainers.
> >>
> >> This could be fixed
> > 
> > Are you proposing an alternative/better fix here? or describing what
> > this patch does?
> 
> Describing what the patch does.

Then I think you meant "This is fixed" or "This patches fixes this
by ...".

> By drawbacks I meant, if there is another bug in the script then we may
> end up to cc too many people. Honestly I don't believe it's the case.

Sure, lets assume not.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:34:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUgY-0001bn-Eq; Thu, 20 Nov 2014 16:34:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrUgW-0001bV-EO
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:34:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F4/41-25276-B081E645; Thu, 20 Nov 2014 16:34:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416501256!14194189!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6440 invoked from network); 20 Nov 2014 16:34:19 -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;
	20 Nov 2014 16:34:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="193336730"
Message-ID: <1416501018.20161.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 20 Nov 2014 16:30:18 +0000
In-Reply-To: <546E1389.1070304@linaro.org>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com> <546E1389.1070304@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:15 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 11/20/2014 04:08 PM, Ian Campbell wrote:
> > On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
> >> By default, the script get_maintainer.pl will remove duplicates email as soon
> >> as it appends the list of maintainers of a new file, and therefore override
> >> the role of the developper.
> >>
> >> On complex patch (see [1]), this will result to ommitting randomly some
> >> maintainers.
> >>
> >> This could be fixed
> > 
> > Are you proposing an alternative/better fix here? or describing what
> > this patch does?
> 
> Describing what the patch does.

Then I think you meant "This is fixed" or "This patches fixes this
by ...".

> By drawbacks I meant, if there is another bug in the script then we may
> end up to cc too many people. Honestly I don't believe it's the case.

Sure, lets assume not.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:43:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:43:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUp4-0002E4-42; Thu, 20 Nov 2014 16:43:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrUp2-0002Dl-AG
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:43:08 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	1E/86-02699-B1A1E645; Thu, 20 Nov 2014 16:43:07 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416501786!13786544!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29087 invoked from network); 20 Nov 2014 16:43:06 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:43:06 -0000
Received: by mail-wg0-f50.google.com with SMTP id k14so4184820wgh.23
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 08:43:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=TcYDH8mIRsT3XcmoBzsbywK4x1zG/HB8aI+cLGgxEio=;
	b=Wbb7HbYCXNIgf087lbyDTztYGzOaT7hGfiRGZ15No7vmorj+PODtPH6w0my1f0PZJT
	hz4rprqyc+x6LyrEFsiqbh3f+Pt1Gcn5nI+8QTPVJ+Y6qx9EEF+ruJKwmVJ/IpK/74nA
	HK8OrFUeCsmiY+3v3i2CurS71FhyBCgbHSCIHiEzDOl2TuGSaXPPoEq2RaElajs+G9zG
	/39WIF2hbPAPnLiBYdNlCT/FECPaCq1wHZexV+DpkWYloxjGC5v+c1k7SBDCuEMenEz+
	df6Nji6/0ZrIpPB/1nTZd4ZGtZogwhG4gdZEue+BqGtu3LNc4Vf9/p37hZ66gGDBPtDE
	fRqQ==
X-Gm-Message-State: ALoCoQnxKGI1zfzfQtyXc9LNiBjssGQVZuoZHlQufKJ4Z1sxOgpRIaWeSa58DXAop9Yz8vv9zMEN
X-Received: by 10.180.20.163 with SMTP id o3mr25451584wie.12.1416501786023;
	Thu, 20 Nov 2014 08:43:06 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id bc1sm7351779wib.16.2014.11.20.08.43.04
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 08:43:05 -0800 (PST)
Message-ID: <546E1A18.1040606@linaro.org>
Date: Thu, 20 Nov 2014 16:43:04 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>	
	<1416499682.14429.41.camel@citrix.com>
	<546E1389.1070304@linaro.org>	 <546E1526.6090406@linaro.org>
	<1416500962.20161.4.camel@citrix.com>
In-Reply-To: <1416500962.20161.4.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 04:29 PM, Ian Campbell wrote:
>> Forgot to add, the example above show the difference without and with
>> the patch. The list is correct because both ARM and x86 maintainers
>> should be CC. Because of this all "THE REST" maintainers are added.
> 
> Just to be clear, you mean that everyone under THE REST is added solely
> because they also happen to be maintainers of some other relevant bit of
> code, not that THE REST is explicitly added in this case, right?

Yes, my description was confusing. With setting $email_remove_duplicates
to 0, the script will:
   1) Append the list of maintainers for every file
   2) Filter the list to remove the entry with "THE REST" role
   3) Remove duplicated address

The previous behavior was:
   1) Get the list of maintainers of the file (incidentally all the
maintainers in "THE REST" role are added). If the email address already
exists in the global list, skip it.
   2) Filter the list to remove the entry with "THE REST" role

So if a maintainers is marked on the "THE REST" on the first file and
actually be an x86 maintainers on the second file, the scripts will only
retain the "THE REST" role.

If it's more clear, I can add the explanation above in the commit message.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:43:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:43:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUp4-0002E4-42; Thu, 20 Nov 2014 16:43:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrUp2-0002Dl-AG
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:43:08 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	1E/86-02699-B1A1E645; Thu, 20 Nov 2014 16:43:07 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416501786!13786544!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29087 invoked from network); 20 Nov 2014 16:43:06 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:43:06 -0000
Received: by mail-wg0-f50.google.com with SMTP id k14so4184820wgh.23
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 08:43:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=TcYDH8mIRsT3XcmoBzsbywK4x1zG/HB8aI+cLGgxEio=;
	b=Wbb7HbYCXNIgf087lbyDTztYGzOaT7hGfiRGZ15No7vmorj+PODtPH6w0my1f0PZJT
	hz4rprqyc+x6LyrEFsiqbh3f+Pt1Gcn5nI+8QTPVJ+Y6qx9EEF+ruJKwmVJ/IpK/74nA
	HK8OrFUeCsmiY+3v3i2CurS71FhyBCgbHSCIHiEzDOl2TuGSaXPPoEq2RaElajs+G9zG
	/39WIF2hbPAPnLiBYdNlCT/FECPaCq1wHZexV+DpkWYloxjGC5v+c1k7SBDCuEMenEz+
	df6Nji6/0ZrIpPB/1nTZd4ZGtZogwhG4gdZEue+BqGtu3LNc4Vf9/p37hZ66gGDBPtDE
	fRqQ==
X-Gm-Message-State: ALoCoQnxKGI1zfzfQtyXc9LNiBjssGQVZuoZHlQufKJ4Z1sxOgpRIaWeSa58DXAop9Yz8vv9zMEN
X-Received: by 10.180.20.163 with SMTP id o3mr25451584wie.12.1416501786023;
	Thu, 20 Nov 2014 08:43:06 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id bc1sm7351779wib.16.2014.11.20.08.43.04
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 08:43:05 -0800 (PST)
Message-ID: <546E1A18.1040606@linaro.org>
Date: Thu, 20 Nov 2014 16:43:04 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>	
	<1416499682.14429.41.camel@citrix.com>
	<546E1389.1070304@linaro.org>	 <546E1526.6090406@linaro.org>
	<1416500962.20161.4.camel@citrix.com>
In-Reply-To: <1416500962.20161.4.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 04:29 PM, Ian Campbell wrote:
>> Forgot to add, the example above show the difference without and with
>> the patch. The list is correct because both ARM and x86 maintainers
>> should be CC. Because of this all "THE REST" maintainers are added.
> 
> Just to be clear, you mean that everyone under THE REST is added solely
> because they also happen to be maintainers of some other relevant bit of
> code, not that THE REST is explicitly added in this case, right?

Yes, my description was confusing. With setting $email_remove_duplicates
to 0, the script will:
   1) Append the list of maintainers for every file
   2) Filter the list to remove the entry with "THE REST" role
   3) Remove duplicated address

The previous behavior was:
   1) Get the list of maintainers of the file (incidentally all the
maintainers in "THE REST" role are added). If the email address already
exists in the global list, skip it.
   2) Filter the list to remove the entry with "THE REST" role

So if a maintainers is marked on the "THE REST" on the first file and
actually be an x86 maintainers on the second file, the scripts will only
retain the "THE REST" role.

If it's more clear, I can add the explanation above in the commit message.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:43:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:43:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUpD-0002Fa-Gd; Thu, 20 Nov 2014 16:43:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrUpB-0002FC-9z
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:43:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	56/46-09842-42A1E645; Thu, 20 Nov 2014 16:43:16 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416501794!14222248!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15814 invoked from network); 20 Nov 2014 16:43:15 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 16:43:15 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKGh2S1018350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 16:43:03 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKGh2pC022583
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 16:43:02 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKGh1M6016512; Thu, 20 Nov 2014 16:43:01 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 08:43:01 -0800
Message-ID: <546E1ABB.6090308@oracle.com>
Date: Thu, 20 Nov 2014 11:45:47 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>	
	<1416499238.14429.39.camel@citrix.com>
	<546E1206.5080403@citrix.com> <1416500123.20161.3.camel@citrix.com>
In-Reply-To: <1416500123.20161.3.camel@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 11:15 AM, Ian Campbell wrote:
> On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
>> On 20/11/14 16:00, Ian Campbell wrote:
>>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>>>> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
>>>> parse bootloader configuration files.
>>>>
>>>> c/s d1b93ea itself changed an an interface which previously used exclusively
>>>> integers, to using strings in the case of a grub configuration with explicit
>>>> default set, along with changing the code calling the interface to require a
>>>> string.  The default value for "default" remained as an integer.
>>>>
>>>> As a result, any Extlinux or Lilo configuration (which drives this interface
>>>> exclusively with integers), or Grub configuration which doesn't explicitly
>>>> declare a default will die with an AttributeError when attempting to call
>>>> "self.cf.default.isdigit()" where "default" is an integer.
>>>>
>>>> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
>>>> which searches partitions for valid bootloader configurations, causing the
>>>> issue to be reported as "Unable to find partition containing kernel"
>>>>
>>>> This patch attempts to fix the issue by altering all parts of this interface
>>>> to use strings, as opposed to integers.
>>> Would it be less invasive at this point in the release to have the place
>>> where this stuff is used do isinstance(s, str) and isinstance(s, int)?
>> It would be BaseString not str, but I am fairly sure the classes have
>> altered through Py2's history.  I would not be any more confident with
>> that as a solution as trying to correctly to start with.
> Actually isinstance(s, basestring) is what the webpage I was looking at
> said, but I cut-n-pasted the wrong thing.
>
> But regardless could it not do something like:
>     if !isinstance(foo.cf.default, int):

I think it would be the other way around, e.g. (not tested):

diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index aa7e562..7250f45 100644
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -457,7 +457,9 @@ class Grub:
          self.cf.parse(buf)

      def image_index(self):
-        if self.cf.default.isdigit():
+        if isinstance(self.cf.default, int)
+            sel = self.cf.default
+        elif if self.cf.default.isdigit():
              sel = int(self.cf.default)
          else:
              # We don't fully support submenus. Look for the leaf value in

but yes, this looks less intrusive (assuming this the only place where 
we'd hit this error).


-boris


>         blah = int(foo.cf.default)
>     elif foo.cf.default.isdigit():
>         blah = whatever
>         
> and avoid the confusion about what is/isn't a string class while still
> fixing the issue?
>
>> sel comes either from g.image_index() which strictly is an integer, or
>> pulled out of the loop immediately preceding and strictly an integer.
> Ah, good.
>
>> I can't however find anything which could cause it to have the value
>> -1.  All error paths I can spot use 0 instead and load the first entry.
>>
>> ~Andrew
>>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:43:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:43:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUpD-0002Fa-Gd; Thu, 20 Nov 2014 16:43:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrUpB-0002FC-9z
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:43:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	56/46-09842-42A1E645; Thu, 20 Nov 2014 16:43:16 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416501794!14222248!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15814 invoked from network); 20 Nov 2014 16:43:15 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 16:43:15 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKGh2S1018350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 16:43:03 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKGh2pC022583
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 16:43:02 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKGh1M6016512; Thu, 20 Nov 2014 16:43:01 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 08:43:01 -0800
Message-ID: <546E1ABB.6090308@oracle.com>
Date: Thu, 20 Nov 2014 11:45:47 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>	
	<1416499238.14429.39.camel@citrix.com>
	<546E1206.5080403@citrix.com> <1416500123.20161.3.camel@citrix.com>
In-Reply-To: <1416500123.20161.3.camel@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 11:15 AM, Ian Campbell wrote:
> On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
>> On 20/11/14 16:00, Ian Campbell wrote:
>>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>>>> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
>>>> parse bootloader configuration files.
>>>>
>>>> c/s d1b93ea itself changed an an interface which previously used exclusively
>>>> integers, to using strings in the case of a grub configuration with explicit
>>>> default set, along with changing the code calling the interface to require a
>>>> string.  The default value for "default" remained as an integer.
>>>>
>>>> As a result, any Extlinux or Lilo configuration (which drives this interface
>>>> exclusively with integers), or Grub configuration which doesn't explicitly
>>>> declare a default will die with an AttributeError when attempting to call
>>>> "self.cf.default.isdigit()" where "default" is an integer.
>>>>
>>>> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
>>>> which searches partitions for valid bootloader configurations, causing the
>>>> issue to be reported as "Unable to find partition containing kernel"
>>>>
>>>> This patch attempts to fix the issue by altering all parts of this interface
>>>> to use strings, as opposed to integers.
>>> Would it be less invasive at this point in the release to have the place
>>> where this stuff is used do isinstance(s, str) and isinstance(s, int)?
>> It would be BaseString not str, but I am fairly sure the classes have
>> altered through Py2's history.  I would not be any more confident with
>> that as a solution as trying to correctly to start with.
> Actually isinstance(s, basestring) is what the webpage I was looking at
> said, but I cut-n-pasted the wrong thing.
>
> But regardless could it not do something like:
>     if !isinstance(foo.cf.default, int):

I think it would be the other way around, e.g. (not tested):

diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index aa7e562..7250f45 100644
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -457,7 +457,9 @@ class Grub:
          self.cf.parse(buf)

      def image_index(self):
-        if self.cf.default.isdigit():
+        if isinstance(self.cf.default, int)
+            sel = self.cf.default
+        elif if self.cf.default.isdigit():
              sel = int(self.cf.default)
          else:
              # We don't fully support submenus. Look for the leaf value in

but yes, this looks less intrusive (assuming this the only place where 
we'd hit this error).


-boris


>         blah = int(foo.cf.default)
>     elif foo.cf.default.isdigit():
>         blah = whatever
>         
> and avoid the confusion about what is/isn't a string class while still
> fixing the issue?
>
>> sel comes either from g.image_index() which strictly is an integer, or
>> pulled out of the loop immediately preceding and strictly an integer.
> Ah, good.
>
>> I can't however find anything which could cause it to have the value
>> -1.  All error paths I can spot use 0 instead and load the first entry.
>>
>> ~Andrew
>>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:43:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:43:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUpT-0002It-Tr; Thu, 20 Nov 2014 16:43:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XrUpR-0002IO-CE
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:43:33 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	B2/25-22777-43A1E645; Thu, 20 Nov 2014 16:43:32 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416501808!4930657!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17705 invoked from network); 20 Nov 2014 16:43:30 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 16:43:30 -0000
Received: from mail-qa0-f47.google.com ([209.85.216.47]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVG4aMFhVMgy9CR7+pRBhM00MSxoIjLeS@postini.com;
	Thu, 20 Nov 2014 08:43:30 PST
Received: by mail-qa0-f47.google.com with SMTP id s7so2130111qap.20
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 08:43:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Xe0tSpDkVKgSsLZoQ2c6PXc1jCC7K/cbjAZ+hPnxhOA=;
	b=QFc8gEimMkBufL1yEp2XP2TybWpIgAXCOr8rnHob5ekbMoaI8s3Uih/dWACHvLE+07
	tCF0CyIk00sz2gMEFA6drRuPDGnWWHBge+JBysLAA4RQfdkz2hdjJZSLI0ZtjZKL5L2k
	gnUKdr+6x0pmc34pJlKNCY93uB0BWN3MstCdw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Xe0tSpDkVKgSsLZoQ2c6PXc1jCC7K/cbjAZ+hPnxhOA=;
	b=KllL07N9kP75oF49/TwsUEuAiSGJSFxUz/E1rnttvNxkUPrT5l+ek2SI1cnYSyWEys
	8qDs9io9weBOaKoNKzFSAEMtctA0YAbymH+jDxQBid9f73lrAKgZ/NxDslaq6+Bd2+Zb
	x4WzFkMitMdVgubrFkEYV7GT2KsWE0uxYbIKHQASe7jIaVxGwezm/sOejRWbsEe0Gpt8
	jmb22Vez5/pnE1YOxTy0uYwWLYlScOg6xtC80if18eS82Nw+B2ThDl2/f6Hk59rL3TSB
	P0nU+LWGrKjcOXxgHkllb/mrmFCT5BKITWxu/oSm4ZeJW3dl+/5/TJURolMwZT/XeoTt
	kTpw==
X-Gm-Message-State: ALoCoQkRoz21kcQWeeaBWk0HA/0X8FSh65058IuXNMU9tHr6DvKKAqQubxghB3J0FQSJCRtPJaigm7SW1LFjZpBA0tn8X5/BFg4U9MmufisMfhcOF4ifhsJsT6tZ5c3qsYEZJL0UI4ijMF5DE95WUNrTr5w9d8FS5Q==
X-Received: by 10.224.23.71 with SMTP id q7mr58589210qab.22.1416501807594;
	Thu, 20 Nov 2014 08:43:27 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.23.71 with SMTP id q7mr58589194qab.22.1416501807444;
	Thu, 20 Nov 2014 08:43:27 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Thu, 20 Nov 2014 08:43:27 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411201615040.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
	<CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
	<alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
	<546DCD46.8000105@linaro.org>
	<CAH_mUMOSJXr-LU3++8pAeoojDQO4q36ZdNHMiZJEo9ivUf6h6w@mail.gmail.com>
	<alpine.DEB.2.02.1411201615040.12596@kaball.uk.xensource.com>
Date: Thu, 20 Nov 2014 18:43:27 +0200
Message-ID: <CAH_mUMPeo0p20M-BanctJChpfmfgLNzTQsKKVf6cMAh25WD=2A@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3888965506007124922=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3888965506007124922==
Content-Type: multipart/alternative; boundary=001a11c231560eac9905084d0721

--001a11c231560eac9905084d0721
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

OK - I see. thanks a lot.

On Thu, Nov 20, 2014 at 6:15 PM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> Already posted:
>
> http://marc.info/?l=3Dxen-devel&m=3D141648092100568
>
> Ian hasn't provided any feedback yet.
>
> On Thu, 20 Nov 2014, Andrii Tseglytskyi wrote:
> > I think I'll debug this a bit later - unfortunately, now don't have
> > time for this. But I want to get rid of spurious interrupt here.
> >
> > BTW - Stefano are you going to post the patch that we created
> > yesterday ? Will Ian accept it?
> >
> > Regards,
> > Andrii
> >
> > On Thu, Nov 20, 2014 at 1:15 PM, Julien Grall <julien.grall@linaro.org>
> wrote:
> > > On 11/20/2014 10:28 AM, Stefano Stabellini wrote:
> > >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> > >>> 19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=80=D0=B8=
=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 "Stefano Stabellini" <
> stefano.stabellini@eu.citrix.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=
=B2:
> > >>>>
> > >>>> On Wed, 19 Nov 2014, Julien Grall wrote:
> > >>>>> On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > >>>>>> That's right, the maintenance interrupt handler is not called,
> but it
> > >>>>>> doesn't do anything so we are fine. The important thing is that =
an
> > >>>>>> interrupt is sent and git_clear_lrs gets called on hypervisor
> entry.
> > >>>>>
> > >>>>> It would be worth to write down this somewhere. Just in case
> someone
> > >>>>> decide to add code in maintenance interrupt later.
> > >>>>
> > >>>> Yes, I could add a comment in the handler
> > >>>
> > >>> Maybe it wouldn't take a lot of effort to fix it? I am just worryin=
g
> that we may hide some issue -
> > >>> typically spurious interrupt this not what is expected.
> > >>
> > >> My guess is that by clearing UIE before reading GICC_IAR, we "clear"
> the
> > >> maintenance interrupt too, as a consequence the following read to
> > >> GICC_IAR would return 1023 (nothing to be read). As bit as if the
> > >> maintenance interrupt was a level interrupt and we just disabled it.
> > >>
> > >> So I think that if we cleared UIE after reading GICC_IAR, GICC_IAR
> would
> > >> return the correct value.
> > >>
> > >> However with the current structure of the code, the first thing that
> we
> > >> do upon entering the hypervisor is clearing LRs and given what
> happened
> > >> on your platform I think is a good idea to do it with UIE disabled.
> > >
> > > Agreed. UIE should be disabled to avoid another maintenance interrupt
> as
> > > soon as we EOI the IRQ.
> > >
> > >> This is way I would rather read spurious interrupts but read/write L=
Rs
> > >> with UIE disabled than reading maintenance interrupts but risking
> > >> strange behaviours on some platforms.
> > >
> > > Reading the GIC-v2 documentation, the spurious interrupt things shoul=
d
> > > happen on any platform every time the UIE is disabled while we receiv=
e
> a
> > > maintenance interrupt.
> > >
> > > "The read returns a spurious interrupt ID of 1023 if any of the
> > > following apply:
> > >
> > > - no pending interrupt on the CPU interface has sufficient priority f=
or
> > > the interface to signal it to the processor"
> > >
> > > --
> > > Julien Grall
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> >
>



--=20

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

--001a11c231560eac9905084d0721
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">OK - I see. thanks a lot.</div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Thu, Nov 20, 2014 at 6:15 PM, Stefano Sta=
bellini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citri=
x.com" target=3D"_blank">stefano.stabellini@eu.citrix.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">Already posted:<br>
<br>
<a href=3D"http://marc.info/?l=3Dxen-devel&amp;m=3D141648092100568" target=
=3D"_blank">http://marc.info/?l=3Dxen-devel&amp;m=3D141648092100568</a><br>
<br>
Ian hasn&#39;t provided any feedback yet.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Thu, 20 Nov 2014, Andrii Tseglytskyi wrote:<br>
&gt; I think I&#39;ll debug this a bit later - unfortunately, now don&#39;t=
 have<br>
&gt; time for this. But I want to get rid of spurious interrupt here.<br>
&gt;<br>
&gt; BTW - Stefano are you going to post the patch that we created<br>
&gt; yesterday ? Will Ian accept it?<br>
&gt;<br>
&gt; Regards,<br>
&gt; Andrii<br>
&gt;<br>
&gt; On Thu, Nov 20, 2014 at 1:15 PM, Julien Grall &lt;<a href=3D"mailto:ju=
lien.grall@linaro.org">julien.grall@linaro.org</a>&gt; wrote:<br>
&gt; &gt; On 11/20/2014 10:28 AM, Stefano Stabellini wrote:<br>
&gt; &gt;&gt; On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:<br>
&gt; &gt;&gt;&gt; 19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=
=80=D0=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 &quot;Stefano Stabellini&quot=
; &lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.com">stefano.stabellin=
i@eu.citrix.com</a>&gt; =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; On Wed, 19 Nov 2014, Julien Grall wrote:<br>
&gt; &gt;&gt;&gt;&gt;&gt; On 11/19/2014 06:14 PM, Stefano Stabellini wrote:=
<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; That&#39;s right, the maintenance interrupt h=
andler is not called, but it<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; doesn&#39;t do anything so we are fine. The i=
mportant thing is that an<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; interrupt is sent and git_clear_lrs gets call=
ed on hypervisor entry.<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; It would be worth to write down this somewhere. J=
ust in case someone<br>
&gt; &gt;&gt;&gt;&gt;&gt; decide to add code in maintenance interrupt later=
.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; Yes, I could add a comment in the handler<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Maybe it wouldn&#39;t take a lot of effort to fix it? I a=
m just worrying that we may hide some issue -<br>
&gt; &gt;&gt;&gt; typically spurious interrupt this not what is expected.<b=
r>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; My guess is that by clearing UIE before reading GICC_IAR, we =
&quot;clear&quot; the<br>
&gt; &gt;&gt; maintenance interrupt too, as a consequence the following rea=
d to<br>
&gt; &gt;&gt; GICC_IAR would return 1023 (nothing to be read). As bit as if=
 the<br>
&gt; &gt;&gt; maintenance interrupt was a level interrupt and we just disab=
led it.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; So I think that if we cleared UIE after reading GICC_IAR, GIC=
C_IAR would<br>
&gt; &gt;&gt; return the correct value.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; However with the current structure of the code, the first thi=
ng that we<br>
&gt; &gt;&gt; do upon entering the hypervisor is clearing LRs and given wha=
t happened<br>
&gt; &gt;&gt; on your platform I think is a good idea to do it with UIE dis=
abled.<br>
&gt; &gt;<br>
&gt; &gt; Agreed. UIE should be disabled to avoid another maintenance inter=
rupt as<br>
&gt; &gt; soon as we EOI the IRQ.<br>
&gt; &gt;<br>
&gt; &gt;&gt; This is way I would rather read spurious interrupts but read/=
write LRs<br>
&gt; &gt;&gt; with UIE disabled than reading maintenance interrupts but ris=
king<br>
&gt; &gt;&gt; strange behaviours on some platforms.<br>
&gt; &gt;<br>
&gt; &gt; Reading the GIC-v2 documentation, the spurious interrupt things s=
hould<br>
&gt; &gt; happen on any platform every time the UIE is disabled while we re=
ceive a<br>
&gt; &gt; maintenance interrupt.<br>
&gt; &gt;<br>
&gt; &gt; &quot;The read returns a spurious interrupt ID of 1023 if any of =
the<br>
&gt; &gt; following apply:<br>
&gt; &gt;<br>
&gt; &gt; - no pending interrupt on the CPU interface has sufficient priori=
ty for<br>
&gt; &gt; the interface to signal it to the processor&quot;<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Julien Grall<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; Andrii Tseglytskyi | Embedded Dev<br>
&gt; GlobalLogic<br>
&gt; <a href=3D"http://www.globallogic.com" target=3D"_blank">www.globallog=
ic.com</a><br>
&gt; </div></div></blockquote></div><br><br clear=3D"all"><div><br></div>--=
 <br><div class=3D"gmail_signature"><font size=3D"-1"><br><span style=3D"ve=
rtical-align:baseline;font-variant:normal;font-style:normal;font-size:12px;=
background-color:transparent;text-decoration:none;font-family:Arial;font-we=
ight:bold">Andrii Tseglytskyi | Embedded Dev</span><br><span style=3D"verti=
cal-align:baseline;font-variant:normal;font-style:normal;font-size:12px;bac=
kground-color:transparent;text-decoration:none;font-family:Arial;font-weigh=
t:normal">GlobalLogic</span><br></font><a href=3D"http://www.globallogic.co=
m/" target=3D"_blank"><span style=3D"font-size:12px;font-family:Arial;color=
:rgb(17,85,204);vertical-align:baseline">www.globallogic.com</span></a><fon=
t size=3D"-1"><br><span style=3D"vertical-align:baseline;font-variant:norma=
l;font-style:normal;font-size:11px;background-color:transparent;text-decora=
tion:none;font-family:Arial;font-weight:normal"></span></font></div>
</div>

--001a11c231560eac9905084d0721--


--===============3888965506007124922==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3888965506007124922==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 16:43:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:43:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUpT-0002It-Tr; Thu, 20 Nov 2014 16:43:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrii.tseglytskyi@globallogic.com>)
	id 1XrUpR-0002IO-CE
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:43:33 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	B2/25-22777-43A1E645; Thu, 20 Nov 2014 16:43:32 +0000
X-Env-Sender: andrii.tseglytskyi@globallogic.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416501808!4930657!1
X-Originating-IP: [64.18.0.192]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17705 invoked from network); 20 Nov 2014 16:43:30 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 16:43:30 -0000
Received: from mail-qa0-f47.google.com ([209.85.216.47]) (using TLSv1) by
	exprod5ob122.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVG4aMFhVMgy9CR7+pRBhM00MSxoIjLeS@postini.com;
	Thu, 20 Nov 2014 08:43:30 PST
Received: by mail-qa0-f47.google.com with SMTP id s7so2130111qap.20
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 08:43:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=globallogic.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Xe0tSpDkVKgSsLZoQ2c6PXc1jCC7K/cbjAZ+hPnxhOA=;
	b=QFc8gEimMkBufL1yEp2XP2TybWpIgAXCOr8rnHob5ekbMoaI8s3Uih/dWACHvLE+07
	tCF0CyIk00sz2gMEFA6drRuPDGnWWHBge+JBysLAA4RQfdkz2hdjJZSLI0ZtjZKL5L2k
	gnUKdr+6x0pmc34pJlKNCY93uB0BWN3MstCdw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Xe0tSpDkVKgSsLZoQ2c6PXc1jCC7K/cbjAZ+hPnxhOA=;
	b=KllL07N9kP75oF49/TwsUEuAiSGJSFxUz/E1rnttvNxkUPrT5l+ek2SI1cnYSyWEys
	8qDs9io9weBOaKoNKzFSAEMtctA0YAbymH+jDxQBid9f73lrAKgZ/NxDslaq6+Bd2+Zb
	x4WzFkMitMdVgubrFkEYV7GT2KsWE0uxYbIKHQASe7jIaVxGwezm/sOejRWbsEe0Gpt8
	jmb22Vez5/pnE1YOxTy0uYwWLYlScOg6xtC80if18eS82Nw+B2ThDl2/f6Hk59rL3TSB
	P0nU+LWGrKjcOXxgHkllb/mrmFCT5BKITWxu/oSm4ZeJW3dl+/5/TJURolMwZT/XeoTt
	kTpw==
X-Gm-Message-State: ALoCoQkRoz21kcQWeeaBWk0HA/0X8FSh65058IuXNMU9tHr6DvKKAqQubxghB3J0FQSJCRtPJaigm7SW1LFjZpBA0tn8X5/BFg4U9MmufisMfhcOF4ifhsJsT6tZ5c3qsYEZJL0UI4ijMF5DE95WUNrTr5w9d8FS5Q==
X-Received: by 10.224.23.71 with SMTP id q7mr58589210qab.22.1416501807594;
	Thu, 20 Nov 2014 08:43:27 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.23.71 with SMTP id q7mr58589194qab.22.1416501807444;
	Thu, 20 Nov 2014 08:43:27 -0800 (PST)
Received: by 10.140.139.18 with HTTP; Thu, 20 Nov 2014 08:43:27 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1411201615040.12596@kaball.uk.xensource.com>
References: <CAH_mUMONEHLK_Ge_cLFV+WGXKFZUAUqQ9Gd6-8vwHcpqurZsnw@mail.gmail.com>
	<alpine.DEB.2.02.1411191644060.12596@kaball.uk.xensource.com>
	<CAH_mUMMOaKqMDw_Jb=oCKXb2TTU=SskH-fMVXSY4AVNBwU9QJQ@mail.gmail.com>
	<alpine.DEB.2.02.1411191704191.12596@kaball.uk.xensource.com>
	<CAH_mUMMwK2qtYXTfndJXhd5Mo8YZPf_=Z4LO_TrFMUsAJKV1bw@mail.gmail.com>
	<alpine.DEB.2.02.1411191740220.12596@kaball.uk.xensource.com>
	<CAH_mUMPHb-mCqp9QMUqa2vBTA5r=QJfVUkJSAfX0A2VGY6PQFw@mail.gmail.com>
	<CAH_mUMMai5kxW-Py8DT6kw=dgpw-7izYJicKLB4Y+Pc+hrY52Q@mail.gmail.com>
	<alpine.DEB.2.02.1411191813090.12596@kaball.uk.xensource.com>
	<546CE0BD.6010102@linaro.org>
	<alpine.DEB.2.02.1411191830500.12596@kaball.uk.xensource.com>
	<CAH_mUMOvSpq9zc=-hQnzsajpjc4NgoT=3fOt+UVSi2NDsm1ZhA@mail.gmail.com>
	<alpine.DEB.2.02.1411201023240.12596@kaball.uk.xensource.com>
	<546DCD46.8000105@linaro.org>
	<CAH_mUMOSJXr-LU3++8pAeoojDQO4q36ZdNHMiZJEo9ivUf6h6w@mail.gmail.com>
	<alpine.DEB.2.02.1411201615040.12596@kaball.uk.xensource.com>
Date: Thu, 20 Nov 2014 18:43:27 +0200
Message-ID: <CAH_mUMPeo0p20M-BanctJChpfmfgLNzTQsKKVf6cMAh25WD=2A@mail.gmail.com>
From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 random freeze question
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3888965506007124922=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3888965506007124922==
Content-Type: multipart/alternative; boundary=001a11c231560eac9905084d0721

--001a11c231560eac9905084d0721
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

OK - I see. thanks a lot.

On Thu, Nov 20, 2014 at 6:15 PM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> Already posted:
>
> http://marc.info/?l=3Dxen-devel&m=3D141648092100568
>
> Ian hasn't provided any feedback yet.
>
> On Thu, 20 Nov 2014, Andrii Tseglytskyi wrote:
> > I think I'll debug this a bit later - unfortunately, now don't have
> > time for this. But I want to get rid of spurious interrupt here.
> >
> > BTW - Stefano are you going to post the patch that we created
> > yesterday ? Will Ian accept it?
> >
> > Regards,
> > Andrii
> >
> > On Thu, Nov 20, 2014 at 1:15 PM, Julien Grall <julien.grall@linaro.org>
> wrote:
> > > On 11/20/2014 10:28 AM, Stefano Stabellini wrote:
> > >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> > >>> 19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=80=D0=B8=
=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 "Stefano Stabellini" <
> stefano.stabellini@eu.citrix.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=
=B2:
> > >>>>
> > >>>> On Wed, 19 Nov 2014, Julien Grall wrote:
> > >>>>> On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > >>>>>> That's right, the maintenance interrupt handler is not called,
> but it
> > >>>>>> doesn't do anything so we are fine. The important thing is that =
an
> > >>>>>> interrupt is sent and git_clear_lrs gets called on hypervisor
> entry.
> > >>>>>
> > >>>>> It would be worth to write down this somewhere. Just in case
> someone
> > >>>>> decide to add code in maintenance interrupt later.
> > >>>>
> > >>>> Yes, I could add a comment in the handler
> > >>>
> > >>> Maybe it wouldn't take a lot of effort to fix it? I am just worryin=
g
> that we may hide some issue -
> > >>> typically spurious interrupt this not what is expected.
> > >>
> > >> My guess is that by clearing UIE before reading GICC_IAR, we "clear"
> the
> > >> maintenance interrupt too, as a consequence the following read to
> > >> GICC_IAR would return 1023 (nothing to be read). As bit as if the
> > >> maintenance interrupt was a level interrupt and we just disabled it.
> > >>
> > >> So I think that if we cleared UIE after reading GICC_IAR, GICC_IAR
> would
> > >> return the correct value.
> > >>
> > >> However with the current structure of the code, the first thing that
> we
> > >> do upon entering the hypervisor is clearing LRs and given what
> happened
> > >> on your platform I think is a good idea to do it with UIE disabled.
> > >
> > > Agreed. UIE should be disabled to avoid another maintenance interrupt
> as
> > > soon as we EOI the IRQ.
> > >
> > >> This is way I would rather read spurious interrupts but read/write L=
Rs
> > >> with UIE disabled than reading maintenance interrupts but risking
> > >> strange behaviours on some platforms.
> > >
> > > Reading the GIC-v2 documentation, the spurious interrupt things shoul=
d
> > > happen on any platform every time the UIE is disabled while we receiv=
e
> a
> > > maintenance interrupt.
> > >
> > > "The read returns a spurious interrupt ID of 1023 if any of the
> > > following apply:
> > >
> > > - no pending interrupt on the CPU interface has sufficient priority f=
or
> > > the interface to signal it to the processor"
> > >
> > > --
> > > Julien Grall
> >
> >
> >
> > --
> >
> > Andrii Tseglytskyi | Embedded Dev
> > GlobalLogic
> > www.globallogic.com
> >
>



--=20

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

--001a11c231560eac9905084d0721
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">OK - I see. thanks a lot.</div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Thu, Nov 20, 2014 at 6:15 PM, Stefano Sta=
bellini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citri=
x.com" target=3D"_blank">stefano.stabellini@eu.citrix.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">Already posted:<br>
<br>
<a href=3D"http://marc.info/?l=3Dxen-devel&amp;m=3D141648092100568" target=
=3D"_blank">http://marc.info/?l=3Dxen-devel&amp;m=3D141648092100568</a><br>
<br>
Ian hasn&#39;t provided any feedback yet.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Thu, 20 Nov 2014, Andrii Tseglytskyi wrote:<br>
&gt; I think I&#39;ll debug this a bit later - unfortunately, now don&#39;t=
 have<br>
&gt; time for this. But I want to get rid of spurious interrupt here.<br>
&gt;<br>
&gt; BTW - Stefano are you going to post the patch that we created<br>
&gt; yesterday ? Will Ian accept it?<br>
&gt;<br>
&gt; Regards,<br>
&gt; Andrii<br>
&gt;<br>
&gt; On Thu, Nov 20, 2014 at 1:15 PM, Julien Grall &lt;<a href=3D"mailto:ju=
lien.grall@linaro.org">julien.grall@linaro.org</a>&gt; wrote:<br>
&gt; &gt; On 11/20/2014 10:28 AM, Stefano Stabellini wrote:<br>
&gt; &gt;&gt; On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:<br>
&gt; &gt;&gt;&gt; 19 =D0=BB=D0=B8=D1=81=D1=82. 2014 20:32, =D0=BA=D0=BE=D1=
=80=D0=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 &quot;Stefano Stabellini&quot=
; &lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.com">stefano.stabellin=
i@eu.citrix.com</a>&gt; =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; On Wed, 19 Nov 2014, Julien Grall wrote:<br>
&gt; &gt;&gt;&gt;&gt;&gt; On 11/19/2014 06:14 PM, Stefano Stabellini wrote:=
<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; That&#39;s right, the maintenance interrupt h=
andler is not called, but it<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; doesn&#39;t do anything so we are fine. The i=
mportant thing is that an<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; interrupt is sent and git_clear_lrs gets call=
ed on hypervisor entry.<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; It would be worth to write down this somewhere. J=
ust in case someone<br>
&gt; &gt;&gt;&gt;&gt;&gt; decide to add code in maintenance interrupt later=
.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; Yes, I could add a comment in the handler<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Maybe it wouldn&#39;t take a lot of effort to fix it? I a=
m just worrying that we may hide some issue -<br>
&gt; &gt;&gt;&gt; typically spurious interrupt this not what is expected.<b=
r>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; My guess is that by clearing UIE before reading GICC_IAR, we =
&quot;clear&quot; the<br>
&gt; &gt;&gt; maintenance interrupt too, as a consequence the following rea=
d to<br>
&gt; &gt;&gt; GICC_IAR would return 1023 (nothing to be read). As bit as if=
 the<br>
&gt; &gt;&gt; maintenance interrupt was a level interrupt and we just disab=
led it.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; So I think that if we cleared UIE after reading GICC_IAR, GIC=
C_IAR would<br>
&gt; &gt;&gt; return the correct value.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; However with the current structure of the code, the first thi=
ng that we<br>
&gt; &gt;&gt; do upon entering the hypervisor is clearing LRs and given wha=
t happened<br>
&gt; &gt;&gt; on your platform I think is a good idea to do it with UIE dis=
abled.<br>
&gt; &gt;<br>
&gt; &gt; Agreed. UIE should be disabled to avoid another maintenance inter=
rupt as<br>
&gt; &gt; soon as we EOI the IRQ.<br>
&gt; &gt;<br>
&gt; &gt;&gt; This is way I would rather read spurious interrupts but read/=
write LRs<br>
&gt; &gt;&gt; with UIE disabled than reading maintenance interrupts but ris=
king<br>
&gt; &gt;&gt; strange behaviours on some platforms.<br>
&gt; &gt;<br>
&gt; &gt; Reading the GIC-v2 documentation, the spurious interrupt things s=
hould<br>
&gt; &gt; happen on any platform every time the UIE is disabled while we re=
ceive a<br>
&gt; &gt; maintenance interrupt.<br>
&gt; &gt;<br>
&gt; &gt; &quot;The read returns a spurious interrupt ID of 1023 if any of =
the<br>
&gt; &gt; following apply:<br>
&gt; &gt;<br>
&gt; &gt; - no pending interrupt on the CPU interface has sufficient priori=
ty for<br>
&gt; &gt; the interface to signal it to the processor&quot;<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Julien Grall<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; Andrii Tseglytskyi | Embedded Dev<br>
&gt; GlobalLogic<br>
&gt; <a href=3D"http://www.globallogic.com" target=3D"_blank">www.globallog=
ic.com</a><br>
&gt; </div></div></blockquote></div><br><br clear=3D"all"><div><br></div>--=
 <br><div class=3D"gmail_signature"><font size=3D"-1"><br><span style=3D"ve=
rtical-align:baseline;font-variant:normal;font-style:normal;font-size:12px;=
background-color:transparent;text-decoration:none;font-family:Arial;font-we=
ight:bold">Andrii Tseglytskyi | Embedded Dev</span><br><span style=3D"verti=
cal-align:baseline;font-variant:normal;font-style:normal;font-size:12px;bac=
kground-color:transparent;text-decoration:none;font-family:Arial;font-weigh=
t:normal">GlobalLogic</span><br></font><a href=3D"http://www.globallogic.co=
m/" target=3D"_blank"><span style=3D"font-size:12px;font-family:Arial;color=
:rgb(17,85,204);vertical-align:baseline">www.globallogic.com</span></a><fon=
t size=3D"-1"><br><span style=3D"vertical-align:baseline;font-variant:norma=
l;font-style:normal;font-size:11px;background-color:transparent;text-decora=
tion:none;font-family:Arial;font-weight:normal"></span></font></div>
</div>

--001a11c231560eac9905084d0721--


--===============3888965506007124922==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3888965506007124922==--


From xen-devel-bounces@lists.xen.org Thu Nov 20 16:46:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:46:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUsK-0002gW-NB; Thu, 20 Nov 2014 16:46:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrUsJ-0002gH-BK
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 16:46:31 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	A5/B4-01660-6EA1E645; Thu, 20 Nov 2014 16:46:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416501990!12510182!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19283 invoked from network); 20 Nov 2014 16:46:30 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:46:30 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so9359683wiw.13
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Nov 2014 08:46:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=u2rMv/rtSlOhkvpJi2xpbWkL1mvRltd/GC3veTLzpfc=;
	b=hK+JSEI476BGeRVXfzTRWUIOrZnJGU7vK1X/JDSvNWc9057elQbRO7LpyCmeK8JI8o
	Kqlc5GdCPQ6Ke/sflVQg6FR5376RtXIpbEv1DEQfbM08Pv5wu195UeOmz5g4rY9cZbq0
	BfCkM5V4I8bgk7c7hwaAQUCiv/Hm7Vu3MEsgFj2B+ZMPsWb2KtmOdFWkBFNqFuRfK7of
	wlospNLVaOLAZYOM/eAoSc/mJxuj/Mk7bheRWWGpnCJaNVlXF1G+LCi9QSBFboTGXfeA
	PVpmOAESIluqHuFuZRjmx7GV/AvIFEXHOOVwPVt/o/3Rt26gEGHQ/Gi5AxU2yWpWigmx
	fuHw==
X-Gm-Message-State: ALoCoQllU6VyNe0aTx9h2Iqguuy0sh2G32Ar7ebMQe24HNXqEu04ruokSXT+uAqE1jolAg9YchuQ
X-Received: by 10.194.89.129 with SMTP id bo1mr70750578wjb.29.1416501989817;
	Thu, 20 Nov 2014 08:46:29 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id gy4sm4828752wib.11.2014.11.20.08.46.28
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 08:46:29 -0800 (PST)
Message-ID: <546E1AE3.4050409@linaro.org>
Date: Thu, 20 Nov 2014 16:46:27 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<546DCA3F.2030508@linaro.org> <546DCB30.6040400@linaro.org>
	<alpine.DEB.2.02.1411201521320.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411201521320.12596@kaball.uk.xensource.com>
Cc: julien.grall@citrix.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On 11/20/2014 03:54 PM, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Julien Grall wrote:
>> On 11/20/2014 11:02 AM, Julien Grall wrote:
>>> Hi Stefano,
>>>
>>> On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
>>>> UIE being set can cause maintenance interrupts to occur when Xen writes
>>>> to one or more LR registers. The effect is a busy loop around the
>>>> interrupt handler in Xen
>>>> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
>>>>
>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>>>> CC: konrad.wilk@oracle.com
>>>> ---
>>>>
>>>> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
>>>> bad side effects on any other platforms as far as I can tell. It should
>>>> go in 4.5.
>>>
>>> From Andrii's mail, there is a bad side effect. We can receive spurious
>>> interrupt.
>>>
>>> On V1, you said that you tried this patch on midway. I would prefer if
>>> you give a try on  platform that would really be used (such as xgene or
>>> seattle). As we know Midway won't be used in prod.
>>
>> And maybe give a try to gicv3 too as it's common code.
> 
> I don't have a gicv3 test environment ready but it works on xgene too

Ok. I will give a quick try on the model today or tomorrow.

Aside from that, and after reading the spec. This patch looks good to me:

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:46:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:46:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUsK-0002gW-NB; Thu, 20 Nov 2014 16:46:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrUsJ-0002gH-BK
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 16:46:31 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	A5/B4-01660-6EA1E645; Thu, 20 Nov 2014 16:46:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416501990!12510182!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19283 invoked from network); 20 Nov 2014 16:46:30 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:46:30 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so9359683wiw.13
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Nov 2014 08:46:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=u2rMv/rtSlOhkvpJi2xpbWkL1mvRltd/GC3veTLzpfc=;
	b=hK+JSEI476BGeRVXfzTRWUIOrZnJGU7vK1X/JDSvNWc9057elQbRO7LpyCmeK8JI8o
	Kqlc5GdCPQ6Ke/sflVQg6FR5376RtXIpbEv1DEQfbM08Pv5wu195UeOmz5g4rY9cZbq0
	BfCkM5V4I8bgk7c7hwaAQUCiv/Hm7Vu3MEsgFj2B+ZMPsWb2KtmOdFWkBFNqFuRfK7of
	wlospNLVaOLAZYOM/eAoSc/mJxuj/Mk7bheRWWGpnCJaNVlXF1G+LCi9QSBFboTGXfeA
	PVpmOAESIluqHuFuZRjmx7GV/AvIFEXHOOVwPVt/o/3Rt26gEGHQ/Gi5AxU2yWpWigmx
	fuHw==
X-Gm-Message-State: ALoCoQllU6VyNe0aTx9h2Iqguuy0sh2G32Ar7ebMQe24HNXqEu04ruokSXT+uAqE1jolAg9YchuQ
X-Received: by 10.194.89.129 with SMTP id bo1mr70750578wjb.29.1416501989817;
	Thu, 20 Nov 2014 08:46:29 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id gy4sm4828752wib.11.2014.11.20.08.46.28
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 08:46:29 -0800 (PST)
Message-ID: <546E1AE3.4050409@linaro.org>
Date: Thu, 20 Nov 2014 16:46:27 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<546DCA3F.2030508@linaro.org> <546DCB30.6040400@linaro.org>
	<alpine.DEB.2.02.1411201521320.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411201521320.12596@kaball.uk.xensource.com>
Cc: julien.grall@citrix.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On 11/20/2014 03:54 PM, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Julien Grall wrote:
>> On 11/20/2014 11:02 AM, Julien Grall wrote:
>>> Hi Stefano,
>>>
>>> On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
>>>> UIE being set can cause maintenance interrupts to occur when Xen writes
>>>> to one or more LR registers. The effect is a busy loop around the
>>>> interrupt handler in Xen
>>>> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
>>>>
>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>>>> CC: konrad.wilk@oracle.com
>>>> ---
>>>>
>>>> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
>>>> bad side effects on any other platforms as far as I can tell. It should
>>>> go in 4.5.
>>>
>>> From Andrii's mail, there is a bad side effect. We can receive spurious
>>> interrupt.
>>>
>>> On V1, you said that you tried this patch on midway. I would prefer if
>>> you give a try on  platform that would really be used (such as xgene or
>>> seattle). As we know Midway won't be used in prod.
>>
>> And maybe give a try to gicv3 too as it's common code.
> 
> I don't have a gicv3 test environment ready but it works on xgene too

Ok. I will give a quick try on the model today or tomorrow.

Aside from that, and after reading the spec. This patch looks good to me:

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:47:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16: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.xen.org>)
	id 1XrUta-0002qJ-EL; Thu, 20 Nov 2014 16:47:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrUta-0002qE-2E
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 16:47:50 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	41/55-14214-53B1E645; Thu, 20 Nov 2014 16:47:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416502064!12559088!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28738 invoked from network); 20 Nov 2014 16:47:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:47:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="194877414"
Message-ID: <1416502062.20161.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Nov 2014 16:47:42 +0000
In-Reply-To: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: julien.grall@citrix.com, xen-devel@lists.xensource.com,
	andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 10:53 +0000, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.

I think it would be useful to explain somewhere why/how a spurious
interrupt can occur, if not here then in the comment you've already
added or in another one in gic_clear_lrs where you clear UIE.

The bit about clearing the LRs on entry causing UIE to become deasserted
before we get as far as reading the IAR is a bit subtle.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> CC: konrad.wilk@oracle.com

With the expanded commentary:
        Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
> 
> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> bad side effects on any other platforms as far as I can tell. It should
> go in 4.5.
> 
> Changes in v2:
> 
> - add an in-code comment about maintenance_interrupt not being called.
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..c6c11d3 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>  
> +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>  
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -527,8 +529,6 @@ void gic_inject(void)
>  
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> -    else
> -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>  }
>  
>  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> @@ -598,6 +598,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>       * Receiving the interrupt is going to cause gic_inject to be called
>       * on return to guest that is going to clear the old LRs and inject
>       * new interrupts.
> +     *
> +     * Do not add code here: maintenance interrupts caused by setting
> +     * GICH_HCR_UIE, might read as spurious interrupts (1023). As a
> +     * consequence sometimes this handler might not be called.
>       */
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:47:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16: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.xen.org>)
	id 1XrUta-0002qJ-EL; Thu, 20 Nov 2014 16:47:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrUta-0002qE-2E
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 16:47:50 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	41/55-14214-53B1E645; Thu, 20 Nov 2014 16:47:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416502064!12559088!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28738 invoked from network); 20 Nov 2014 16:47:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:47:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="194877414"
Message-ID: <1416502062.20161.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Nov 2014 16:47:42 +0000
In-Reply-To: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: julien.grall@citrix.com, xen-devel@lists.xensource.com,
	andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 10:53 +0000, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.

I think it would be useful to explain somewhere why/how a spurious
interrupt can occur, if not here then in the comment you've already
added or in another one in gic_clear_lrs where you clear UIE.

The bit about clearing the LRs on entry causing UIE to become deasserted
before we get as far as reading the IAR is a bit subtle.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> CC: konrad.wilk@oracle.com

With the expanded commentary:
        Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
> 
> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> bad side effects on any other platforms as far as I can tell. It should
> go in 4.5.
> 
> Changes in v2:
> 
> - add an in-code comment about maintenance_interrupt not being called.
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 70d10d6..c6c11d3 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>  
> +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> +
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>  
>      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> @@ -527,8 +529,6 @@ void gic_inject(void)
>  
>      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
>          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> -    else
> -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
>  }
>  
>  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> @@ -598,6 +598,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>       * Receiving the interrupt is going to cause gic_inject to be called
>       * on return to guest that is going to clear the old LRs and inject
>       * new interrupts.
> +     *
> +     * Do not add code here: maintenance interrupts caused by setting
> +     * GICH_HCR_UIE, might read as spurious interrupts (1023). As a
> +     * consequence sometimes this handler might not be called.
>       */
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:52:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:52:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUxo-0003AJ-6b; Thu, 20 Nov 2014 16:52: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 1XrUxn-0003AC-3j
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:52:11 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	33/4E-28865-A3C1E645; Thu, 20 Nov 2014 16:52:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416502326!12496429!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29504 invoked from network); 20 Nov 2014 16:52:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:52:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="194879093"
Message-ID: <1416502322.20161.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 20 Nov 2014 16:52:02 +0000
In-Reply-To: <546E1A18.1040606@linaro.org>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com> <546E1389.1070304@linaro.org>
	<546E1526.6090406@linaro.org> <1416500962.20161.4.camel@citrix.com>
	<546E1A18.1040606@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:43 +0000, Julien Grall wrote:
> On 11/20/2014 04:29 PM, Ian Campbell wrote:
> >> Forgot to add, the example above show the difference without and with
> >> the patch. The list is correct because both ARM and x86 maintainers
> >> should be CC. Because of this all "THE REST" maintainers are added.
> > 
> > Just to be clear, you mean that everyone under THE REST is added solely
> > because they also happen to be maintainers of some other relevant bit of
> > code, not that THE REST is explicitly added in this case, right?
> 
> Yes, my description was confusing. With setting $email_remove_duplicates
> to 0, the script will:
>    1) Append the list of maintainers for every file
>    2) Filter the list to remove the entry with "THE REST" role
>    3) Remove duplicated address
> 
> The previous behavior was:
>    1) Get the list of maintainers of the file (incidentally all the
> maintainers in "THE REST" role are added). If the email address already
> exists in the global list, skip it.
>    2) Filter the list to remove the entry with "THE REST" role
> 
> So if a maintainers is marked on the "THE REST" on the first file and
> actually be an x86 maintainers on the second file, the scripts will only
> retain the "THE REST" role.
> 
> If it's more clear, I can add the explanation above in the commit message.

It is, please do.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:52:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:52:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrUxo-0003AJ-6b; Thu, 20 Nov 2014 16:52: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 1XrUxn-0003AC-3j
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:52:11 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	33/4E-28865-A3C1E645; Thu, 20 Nov 2014 16:52:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416502326!12496429!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29504 invoked from network); 20 Nov 2014 16:52:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:52:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="194879093"
Message-ID: <1416502322.20161.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 20 Nov 2014 16:52:02 +0000
In-Reply-To: <546E1A18.1040606@linaro.org>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com> <546E1389.1070304@linaro.org>
	<546E1526.6090406@linaro.org> <1416500962.20161.4.camel@citrix.com>
	<546E1A18.1040606@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:43 +0000, Julien Grall wrote:
> On 11/20/2014 04:29 PM, Ian Campbell wrote:
> >> Forgot to add, the example above show the difference without and with
> >> the patch. The list is correct because both ARM and x86 maintainers
> >> should be CC. Because of this all "THE REST" maintainers are added.
> > 
> > Just to be clear, you mean that everyone under THE REST is added solely
> > because they also happen to be maintainers of some other relevant bit of
> > code, not that THE REST is explicitly added in this case, right?
> 
> Yes, my description was confusing. With setting $email_remove_duplicates
> to 0, the script will:
>    1) Append the list of maintainers for every file
>    2) Filter the list to remove the entry with "THE REST" role
>    3) Remove duplicated address
> 
> The previous behavior was:
>    1) Get the list of maintainers of the file (incidentally all the
> maintainers in "THE REST" role are added). If the email address already
> exists in the global list, skip it.
>    2) Filter the list to remove the entry with "THE REST" role
> 
> So if a maintainers is marked on the "THE REST" on the first file and
> actually be an x86 maintainers on the second file, the scripts will only
> retain the "THE REST" role.
> 
> If it's more clear, I can add the explanation above in the commit message.

It is, please do.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:58:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:58:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrV3Y-0003YQ-3e; Thu, 20 Nov 2014 16:58: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 1XrV3W-0003YC-VL
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:58:07 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	DC/19-28865-E9D1E645; Thu, 20 Nov 2014 16:58:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416502671!12512327!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30446 invoked from network); 20 Nov 2014 16:57:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="194881760"
Message-ID: <1416502667.21748.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 20 Nov 2014 16:57:47 +0000
In-Reply-To: <1416502322.20161.9.camel@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com> <546E1389.1070304@linaro.org>
	<546E1526.6090406@linaro.org> <1416500962.20161.4.camel@citrix.com>
	<546E1A18.1040606@linaro.org> <1416502322.20161.9.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:52 +0000, Ian Campbell wrote:
> On Thu, 2014-11-20 at 16:43 +0000, Julien Grall wrote:
> > On 11/20/2014 04:29 PM, Ian Campbell wrote:
> > >> Forgot to add, the example above show the difference without and with
> > >> the patch. The list is correct because both ARM and x86 maintainers
> > >> should be CC. Because of this all "THE REST" maintainers are added.
> > > 
> > > Just to be clear, you mean that everyone under THE REST is added solely
> > > because they also happen to be maintainers of some other relevant bit of
> > > code, not that THE REST is explicitly added in this case, right?
> > 

Just a small clarification...

> > Yes, my description was confusing. With setting $email_remove_duplicates
> > to 0, the script will:
> >    1) Append the list of maintainers for every file

At this point each maintainer remains associated with the role/reason
they are added, right?

> >    2) Filter the list to remove the entry with "THE REST" role

And this only happens if there are roles other than "THE REST" in the
list?

> >    3) Remove duplicated address
> > 
> > The previous behavior was:
> >    1) Get the list of maintainers of the file (incidentally all the
> > maintainers in "THE REST" role are added). If the email address already
> > exists in the global list, skip it.
> >    2) Filter the list to remove the entry with "THE REST" role

Whereas here the link from maintainer to the role is lost, hence
everyone in THE REST is blindly removed?

> > So if a maintainers is marked on the "THE REST" on the first file and
> > actually be an x86 maintainers on the second file, the scripts will only
> > retain the "THE REST" role.
> > 
> > If it's more clear, I can add the explanation above in the commit message.
> 
> It is, please do.
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:58:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16:58:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrV3Y-0003YQ-3e; Thu, 20 Nov 2014 16:58: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 1XrV3W-0003YC-VL
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 16:58:07 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	DC/19-28865-E9D1E645; Thu, 20 Nov 2014 16:58:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416502671!12512327!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30446 invoked from network); 20 Nov 2014 16:57:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="194881760"
Message-ID: <1416502667.21748.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 20 Nov 2014 16:57:47 +0000
In-Reply-To: <1416502322.20161.9.camel@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>
	<1416499682.14429.41.camel@citrix.com> <546E1389.1070304@linaro.org>
	<546E1526.6090406@linaro.org> <1416500962.20161.4.camel@citrix.com>
	<546E1A18.1040606@linaro.org> <1416502322.20161.9.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:52 +0000, Ian Campbell wrote:
> On Thu, 2014-11-20 at 16:43 +0000, Julien Grall wrote:
> > On 11/20/2014 04:29 PM, Ian Campbell wrote:
> > >> Forgot to add, the example above show the difference without and with
> > >> the patch. The list is correct because both ARM and x86 maintainers
> > >> should be CC. Because of this all "THE REST" maintainers are added.
> > > 
> > > Just to be clear, you mean that everyone under THE REST is added solely
> > > because they also happen to be maintainers of some other relevant bit of
> > > code, not that THE REST is explicitly added in this case, right?
> > 

Just a small clarification...

> > Yes, my description was confusing. With setting $email_remove_duplicates
> > to 0, the script will:
> >    1) Append the list of maintainers for every file

At this point each maintainer remains associated with the role/reason
they are added, right?

> >    2) Filter the list to remove the entry with "THE REST" role

And this only happens if there are roles other than "THE REST" in the
list?

> >    3) Remove duplicated address
> > 
> > The previous behavior was:
> >    1) Get the list of maintainers of the file (incidentally all the
> > maintainers in "THE REST" role are added). If the email address already
> > exists in the global list, skip it.
> >    2) Filter the list to remove the entry with "THE REST" role

Whereas here the link from maintainer to the role is lost, hence
everyone in THE REST is blindly removed?

> > So if a maintainers is marked on the "THE REST" on the first file and
> > actually be an x86 maintainers on the second file, the scripts will only
> > retain the "THE REST" role.
> > 
> > If it's more clear, I can add the explanation above in the commit message.
> 
> It is, please do.
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16: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 1XrV3q-0003Zz-G5; Thu, 20 Nov 2014 16:58:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1XrV3o-0003Zn-Tl
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:58:25 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	8A/CB-14214-0BD1E645; Thu, 20 Nov 2014 16:58:24 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416502702!12535985!1
X-Originating-IP: [209.85.220.181]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8663 invoked from network); 20 Nov 2014 16:58:23 -0000
Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com)
	(209.85.220.181)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:58:23 -0000
Received: by mail-vc0-f181.google.com with SMTP id le20so1526920vcb.40
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 08:58:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=WCP9f/SRcc1X3VRUUZFIgPCsZJMbjdjNV9IvLCEak0c=;
	b=SXKWIZixRT9W0z8cBukAVuN6WqbmdN0jXjMmFimKb10wAedYMsAoKpZtHmfIiZxibh
	I7/RA4m8Q07ojYU1nvTbjsAxx9QvZyT3PDtmJbTIA1OlA1UEZscjx0K+f2lJtfBzOAw5
	n03gdXa5s4vtcox8MGi4vx82iVI7GLNnRv+k7V9qk+qului2XUVC6BtDkvDQYI3MArEp
	Ft6t2+gfOp9ZXnRNg6T+O/Qo2Xm7e4D54PXDFDv9NPLDa/sSTH2+ybaOzECs+35kX4iH
	7Y/rYUO0fwdlP0kQrTrAas2O6Ds86NrsmRmdmg0O4ip1L4steg4Uyvc6gKcyK2DFb+RR
	STXQ==
MIME-Version: 1.0
X-Received: by 10.221.4.2 with SMTP id oa2mr16104412vcb.17.1416502702192; Thu,
	20 Nov 2014 08:58:22 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Thu, 20 Nov 2014 08:58:22 -0800 (PST)
In-Reply-To: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
Date: Thu, 20 Nov 2014 16:58:22 +0000
Message-ID: <CAHt6W4cn3hiK0VwS+MF=CZu2QGLe9yuW-NSgfyVWoZgPZoz3GQ@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2014-11-20 15:48 GMT+00:00 Ian Campbell <ian.campbell@citrix.com>:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> up leaked.
>
> The memory pool currently supports mmap'd buffers as well as a directly
> allocated buffers, however the try decode routines make use of realloc and do
> not fit well into this model. Introduce a concept of an external memory block
> to the memory pool and provide an interface to register such memory.
>
> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> mmap_ prefix since they are now also used for external memory blocks.
>
> We are only seeing this now because the gzip decoder doesn't leak and it's only
> relatively recently that kernels in the wild have switched to better
> compression.
>
> This is https://bugs.debian.org/767295
>
> Reported by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: Correct handling in xc_try_lzo1x_decode.
>
> This is a bug fix and should go into 4.5.
>
> I have a sneaking suspicion this is going to need to backport a very long way...
> ---
>  tools/libxc/include/xc_dom.h        |   10 ++++--
>  tools/libxc/xc_dom_bzimageloader.c  |   20 ++++++++++++
>  tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
>  tools/libxc/xc_dom_decompress_lz4.c |    5 +++
>  4 files changed, 80 insertions(+), 16 deletions(-)
>
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6ae6a9f..07d7224 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -33,8 +33,13 @@ struct xc_dom_seg {
>
>  struct xc_dom_mem {
>      struct xc_dom_mem *next;
> -    void *mmap_ptr;
> -    size_t mmap_len;
> +    void *ptr;
> +    enum {
> +        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
> +        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
> +        XC_DOM_MEM_TYPE_MMAP,
> +    } type;
> +    size_t len;
>      unsigned char memory[0];
>  };
>

Just a small optimization, if you move type after len you can reduce
structure size.
Unless you want memory field aligned to 8 bytes on 64 bit but in this
case I would force member alignment.

Frediano

> @@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
>  /* --- simple memory pool ------------------------------------------ */
>
>  void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
>  void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>                              const char *filename, size_t * size,
> diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
> index 2225699..964ebdc 100644
> --- a/tools/libxc/xc_dom_bzimageloader.c
> +++ b/tools/libxc/xc_dom_bzimageloader.c
> @@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
>
>      total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
>
> +    if ( xc_dom_register_external(dom, out_buf, total) )
> +    {
> +        DOMPRINTF("BZIP2: Error registering stream output");
> +        free(out_buf);
> +        goto bzip2_cleanup;
> +    }
> +
>      DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
>                __FUNCTION__, *size, (long unsigned int) total);
>
> @@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
>          }
>      }
>
> +    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
> +    {
> +        DOMPRINTF("%s: Error registering stream output", what);
> +        free(out_buf);
> +        goto lzma_cleanup;
> +    }
> +
>      DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
>                __FUNCTION__, what, *size, (size_t)stream->total_out);
>
> @@ -464,7 +478,13 @@ static int xc_try_lzo1x_decode(
>
>          dst_len = lzo_read_32(cur);
>          if ( !dst_len )
> +        {
> +            msg = "Error registering stream output";
> +            if ( xc_dom_register_external(dom, out_buf, out_len) )
> +                break;
> +
>              return 0;
> +        }
>
>          if ( dst_len > LZOP_MAX_BLOCK_SIZE )
>          {
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index baa62a1..ecbf981 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block) + size);
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block) + size;
> @@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len,
> -                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> -                           -1, 0);
> -    if ( block->mmap_ptr == MAP_FAILED )
> +    block->len = size;
> +    block->ptr = mmap(NULL, block->len,
> +                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> +                      -1, 0);
> +    if ( block->ptr == MAP_FAILED )
>      {
>          DOMPRINTF("%s: mmap failed", __FUNCTION__);
>          free(block);
>          return NULL;
>      }
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_mem_map += block->mmap_len;
> +    dom->alloc_mem_map += block->len;
>      if ( size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, size);
> -    return block->mmap_ptr;
> +    return block->ptr;
> +}
> +
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
> +{
> +    struct xc_dom_mem *block;
> +
> +    block = malloc(sizeof(*block));
> +    if ( block == NULL )
> +    {
> +        DOMPRINTF("%s: allocation failed", __FUNCTION__);
> +        return -1;
> +    }
> +    memset(block, 0, sizeof(*block));
> +    block->ptr = ptr;
> +    block->len = size;
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
> +    block->next = dom->memblocks;
> +    dom->memblocks = block;
> +    dom->alloc_malloc += sizeof(*block);
> +    dom->alloc_mem_map += block->len;
> +    return 0;
>  }
>
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
> @@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>      }
>
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = *size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
> +    block->len = *size;
> +    block->ptr = mmap(NULL, block->len, PROT_READ,
>                             MAP_SHARED, fd, 0);
> -    if ( block->mmap_ptr == MAP_FAILED ) {
> +    if ( block->ptr == MAP_FAILED ) {
>          xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
>                       "failed to mmap file: %s",
>                       strerror(errno));
>          goto err;
>      }
>
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_file_map += block->mmap_len;
> +    dom->alloc_file_map += block->len;
>      close(fd);
>      if ( *size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, *size);
> -    return block->mmap_ptr;
> +    return block->ptr;
>
>   err:
>      if ( fd != -1 )
> @@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
>      while ( (block = dom->memblocks) != NULL )
>      {
>          dom->memblocks = block->next;
> -        if ( block->mmap_ptr )
> -            munmap(block->mmap_ptr, block->mmap_len);
> +        switch ( block->type )
> +        {
> +        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
> +            break;
> +        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
> +            free(block->ptr);
> +            break;
> +        case XC_DOM_MEM_TYPE_MMAP:
> +            munmap(block->ptr, block->len);
> +            break;
> +        }
>          free(block);
>      }
>  }
> diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
> index 490ec56..b6a33f2 100644
> --- a/tools/libxc/xc_dom_decompress_lz4.c
> +++ b/tools/libxc/xc_dom_decompress_lz4.c
> @@ -103,6 +103,11 @@ int xc_try_lz4_decode(
>
>                 if (size == 0)
>                 {
> +                       if ( xc_dom_register_external(dom, output, out_len) )
> +                       {
> +                               msg = "Error registering stream output";
> +                               goto exit_2;
> +                       }
>                         *blob = output;
>                         *psize = out_len;
>                         return 0;
> --
> 1.7.10.4
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 16:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 16: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 1XrV3q-0003Zz-G5; Thu, 20 Nov 2014 16:58:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1XrV3o-0003Zn-Tl
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 16:58:25 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	8A/CB-14214-0BD1E645; Thu, 20 Nov 2014 16:58:24 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416502702!12535985!1
X-Originating-IP: [209.85.220.181]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8663 invoked from network); 20 Nov 2014 16:58:23 -0000
Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com)
	(209.85.220.181)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 16:58:23 -0000
Received: by mail-vc0-f181.google.com with SMTP id le20so1526920vcb.40
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 08:58:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=WCP9f/SRcc1X3VRUUZFIgPCsZJMbjdjNV9IvLCEak0c=;
	b=SXKWIZixRT9W0z8cBukAVuN6WqbmdN0jXjMmFimKb10wAedYMsAoKpZtHmfIiZxibh
	I7/RA4m8Q07ojYU1nvTbjsAxx9QvZyT3PDtmJbTIA1OlA1UEZscjx0K+f2lJtfBzOAw5
	n03gdXa5s4vtcox8MGi4vx82iVI7GLNnRv+k7V9qk+qului2XUVC6BtDkvDQYI3MArEp
	Ft6t2+gfOp9ZXnRNg6T+O/Qo2Xm7e4D54PXDFDv9NPLDa/sSTH2+ybaOzECs+35kX4iH
	7Y/rYUO0fwdlP0kQrTrAas2O6Ds86NrsmRmdmg0O4ip1L4steg4Uyvc6gKcyK2DFb+RR
	STXQ==
MIME-Version: 1.0
X-Received: by 10.221.4.2 with SMTP id oa2mr16104412vcb.17.1416502702192; Thu,
	20 Nov 2014 08:58:22 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Thu, 20 Nov 2014 08:58:22 -0800 (PST)
In-Reply-To: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
Date: Thu, 20 Nov 2014 16:58:22 +0000
Message-ID: <CAHt6W4cn3hiK0VwS+MF=CZu2QGLe9yuW-NSgfyVWoZgPZoz3GQ@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2014-11-20 15:48 GMT+00:00 Ian Campbell <ian.campbell@citrix.com>:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> up leaked.
>
> The memory pool currently supports mmap'd buffers as well as a directly
> allocated buffers, however the try decode routines make use of realloc and do
> not fit well into this model. Introduce a concept of an external memory block
> to the memory pool and provide an interface to register such memory.
>
> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> mmap_ prefix since they are now also used for external memory blocks.
>
> We are only seeing this now because the gzip decoder doesn't leak and it's only
> relatively recently that kernels in the wild have switched to better
> compression.
>
> This is https://bugs.debian.org/767295
>
> Reported by: Gedalya <gedalya@gedalya.net>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: Correct handling in xc_try_lzo1x_decode.
>
> This is a bug fix and should go into 4.5.
>
> I have a sneaking suspicion this is going to need to backport a very long way...
> ---
>  tools/libxc/include/xc_dom.h        |   10 ++++--
>  tools/libxc/xc_dom_bzimageloader.c  |   20 ++++++++++++
>  tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
>  tools/libxc/xc_dom_decompress_lz4.c |    5 +++
>  4 files changed, 80 insertions(+), 16 deletions(-)
>
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6ae6a9f..07d7224 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -33,8 +33,13 @@ struct xc_dom_seg {
>
>  struct xc_dom_mem {
>      struct xc_dom_mem *next;
> -    void *mmap_ptr;
> -    size_t mmap_len;
> +    void *ptr;
> +    enum {
> +        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
> +        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
> +        XC_DOM_MEM_TYPE_MMAP,
> +    } type;
> +    size_t len;
>      unsigned char memory[0];
>  };
>

Just a small optimization, if you move type after len you can reduce
structure size.
Unless you want memory field aligned to 8 bytes on 64 bit but in this
case I would force member alignment.

Frediano

> @@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
>  /* --- simple memory pool ------------------------------------------ */
>
>  void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
>  void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>                              const char *filename, size_t * size,
> diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
> index 2225699..964ebdc 100644
> --- a/tools/libxc/xc_dom_bzimageloader.c
> +++ b/tools/libxc/xc_dom_bzimageloader.c
> @@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
>
>      total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
>
> +    if ( xc_dom_register_external(dom, out_buf, total) )
> +    {
> +        DOMPRINTF("BZIP2: Error registering stream output");
> +        free(out_buf);
> +        goto bzip2_cleanup;
> +    }
> +
>      DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
>                __FUNCTION__, *size, (long unsigned int) total);
>
> @@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
>          }
>      }
>
> +    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
> +    {
> +        DOMPRINTF("%s: Error registering stream output", what);
> +        free(out_buf);
> +        goto lzma_cleanup;
> +    }
> +
>      DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
>                __FUNCTION__, what, *size, (size_t)stream->total_out);
>
> @@ -464,7 +478,13 @@ static int xc_try_lzo1x_decode(
>
>          dst_len = lzo_read_32(cur);
>          if ( !dst_len )
> +        {
> +            msg = "Error registering stream output";
> +            if ( xc_dom_register_external(dom, out_buf, out_len) )
> +                break;
> +
>              return 0;
> +        }
>
>          if ( dst_len > LZOP_MAX_BLOCK_SIZE )
>          {
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index baa62a1..ecbf981 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block) + size);
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block) + size;
> @@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len,
> -                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> -                           -1, 0);
> -    if ( block->mmap_ptr == MAP_FAILED )
> +    block->len = size;
> +    block->ptr = mmap(NULL, block->len,
> +                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> +                      -1, 0);
> +    if ( block->ptr == MAP_FAILED )
>      {
>          DOMPRINTF("%s: mmap failed", __FUNCTION__);
>          free(block);
>          return NULL;
>      }
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_mem_map += block->mmap_len;
> +    dom->alloc_mem_map += block->len;
>      if ( size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, size);
> -    return block->mmap_ptr;
> +    return block->ptr;
> +}
> +
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
> +{
> +    struct xc_dom_mem *block;
> +
> +    block = malloc(sizeof(*block));
> +    if ( block == NULL )
> +    {
> +        DOMPRINTF("%s: allocation failed", __FUNCTION__);
> +        return -1;
> +    }
> +    memset(block, 0, sizeof(*block));
> +    block->ptr = ptr;
> +    block->len = size;
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
> +    block->next = dom->memblocks;
> +    dom->memblocks = block;
> +    dom->alloc_malloc += sizeof(*block);
> +    dom->alloc_mem_map += block->len;
> +    return 0;
>  }
>
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
> @@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>      }
>
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = *size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
> +    block->len = *size;
> +    block->ptr = mmap(NULL, block->len, PROT_READ,
>                             MAP_SHARED, fd, 0);
> -    if ( block->mmap_ptr == MAP_FAILED ) {
> +    if ( block->ptr == MAP_FAILED ) {
>          xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
>                       "failed to mmap file: %s",
>                       strerror(errno));
>          goto err;
>      }
>
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_file_map += block->mmap_len;
> +    dom->alloc_file_map += block->len;
>      close(fd);
>      if ( *size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, *size);
> -    return block->mmap_ptr;
> +    return block->ptr;
>
>   err:
>      if ( fd != -1 )
> @@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
>      while ( (block = dom->memblocks) != NULL )
>      {
>          dom->memblocks = block->next;
> -        if ( block->mmap_ptr )
> -            munmap(block->mmap_ptr, block->mmap_len);
> +        switch ( block->type )
> +        {
> +        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
> +            break;
> +        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
> +            free(block->ptr);
> +            break;
> +        case XC_DOM_MEM_TYPE_MMAP:
> +            munmap(block->ptr, block->len);
> +            break;
> +        }
>          free(block);
>      }
>  }
> diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
> index 490ec56..b6a33f2 100644
> --- a/tools/libxc/xc_dom_decompress_lz4.c
> +++ b/tools/libxc/xc_dom_decompress_lz4.c
> @@ -103,6 +103,11 @@ int xc_try_lz4_decode(
>
>                 if (size == 0)
>                 {
> +                       if ( xc_dom_register_external(dom, output, out_len) )
> +                       {
> +                               msg = "Error registering stream output";
> +                               goto exit_2;
> +                       }
>                         *blob = output;
>                         *psize = out_len;
>                         return 0;
> --
> 1.7.10.4
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 17:20:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 17:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrVOo-0004FB-Jj; Thu, 20 Nov 2014 17:20:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrVOn-0004F6-Kw
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 17:20:05 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	41/26-09936-4C22E645; Thu, 20 Nov 2014 17:20:04 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416504004!14258209!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22143 invoked from network); 20 Nov 2014 17:20:04 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 17:20:04 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so4303887wgh.30
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 09:20:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=BSFyTz9I0THgQV4JmWPo21/Tks1OC1odLCgCnCwEKJ4=;
	b=Knlp1e2q6oMLdUClZiX6cCfqgHXoY0ae94oHrva6DPBPkpa/C/RKhZ9iMXMV6A7NMy
	w3xcZmG88/V1ed1YSfrtpS18Hae6Ry53xYYzks9rniVdXlkVNOWROF+ftsPcfJpcSvUA
	NVRAPwBqiJnK05GEkYEV2oSnkgQ6bW4wL2b0vwmKcRtkO1MvxP65pnKVI5Po59n773UJ
	eexbP0H7wqrsuG9fv9SuN0B4egTzuM8SQBKM+VU83Llw1HbyUOzlT2QuQrOpTfL+Bd7n
	6Ww7NoyzxCC4kB3WWWFnXDlcgli/MHC9974HVchySHg1Doqwb/gU1bWtz1lVrz7kLTEo
	nb3w==
X-Gm-Message-State: ALoCoQk/+NRkpyT0YNZU0jKN1DKg7s7r51Th28pVPwk5nX4DWrwnScqY5ViHd6Q9qORLn33Um/qz
X-Received: by 10.194.92.148 with SMTP id cm20mr71566561wjb.88.1416504003426; 
	Thu, 20 Nov 2014 09:20:03 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id iz19sm7499886wic.8.2014.11.20.09.20.02
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 09:20:02 -0800 (PST)
Message-ID: <546E22C1.6050206@linaro.org>
Date: Thu, 20 Nov 2014 17:20:01 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>	
	<1416499682.14429.41.camel@citrix.com>
	<546E1389.1070304@linaro.org>	 <546E1526.6090406@linaro.org>
	<1416500962.20161.4.camel@citrix.com>	
	<546E1A18.1040606@linaro.org> <1416502322.20161.9.camel@citrix.com>
	<1416502667.21748.1.camel@citrix.com>
In-Reply-To: <1416502667.21748.1.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 04:57 PM, Ian Campbell wrote:
> On Thu, 2014-11-20 at 16:52 +0000, Ian Campbell wrote:
>> On Thu, 2014-11-20 at 16:43 +0000, Julien Grall wrote:
>>> On 11/20/2014 04:29 PM, Ian Campbell wrote:
>>>>> Forgot to add, the example above show the difference without and with
>>>>> the patch. The list is correct because both ARM and x86 maintainers
>>>>> should be CC. Because of this all "THE REST" maintainers are added.
>>>>
>>>> Just to be clear, you mean that everyone under THE REST is added solely
>>>> because they also happen to be maintainers of some other relevant bit of
>>>> code, not that THE REST is explicitly added in this case, right?
>>>
> 
> Just a small clarification...
> 
>>> Yes, my description was confusing. With setting $email_remove_duplicates
>>> to 0, the script will:
>>>    1) Append the list of maintainers for every file
> 
> At this point each maintainer remains associated with the role/reason
> they are added, right?

Yes. Every time the maintainers is listed we add in the list no matters
if the mail already exists. So the maintainers may be listed twice with
different roles (for instance: x86 and "THE REST").

>>>    2) Filter the list to remove the entry with "THE REST" role
> 
> And this only happens if there are roles other than "THE REST" in the
> list?

Yes.

> 
>>>    3) Remove duplicated address
>>>
>>> The previous behavior was:
>>>    1) Get the list of maintainers of the file (incidentally all the
>>> maintainers in "THE REST" role are added). If the email address already
>>> exists in the global list, skip it.
>>>    2) Filter the list to remove the entry with "THE REST" role
> 
> Whereas here the link from maintainer to the role is lost, hence
> everyone in THE REST is blindly removed?

Yes.

>>> So if a maintainers is marked on the "THE REST" on the first file and
>>> actually be an x86 maintainers on the second file, the scripts will only
>>> retain the "THE REST" role.
>>>
>>> If it's more clear, I can add the explanation above in the commit message.
>>
>> It is, please do.

I will send a new version.

Regards,


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 17:20:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 17:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrVOo-0004FB-Jj; Thu, 20 Nov 2014 17:20:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrVOn-0004F6-Kw
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 17:20:05 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	41/26-09936-4C22E645; Thu, 20 Nov 2014 17:20:04 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416504004!14258209!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22143 invoked from network); 20 Nov 2014 17:20:04 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 17:20:04 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so4303887wgh.30
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 09:20:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=BSFyTz9I0THgQV4JmWPo21/Tks1OC1odLCgCnCwEKJ4=;
	b=Knlp1e2q6oMLdUClZiX6cCfqgHXoY0ae94oHrva6DPBPkpa/C/RKhZ9iMXMV6A7NMy
	w3xcZmG88/V1ed1YSfrtpS18Hae6Ry53xYYzks9rniVdXlkVNOWROF+ftsPcfJpcSvUA
	NVRAPwBqiJnK05GEkYEV2oSnkgQ6bW4wL2b0vwmKcRtkO1MvxP65pnKVI5Po59n773UJ
	eexbP0H7wqrsuG9fv9SuN0B4egTzuM8SQBKM+VU83Llw1HbyUOzlT2QuQrOpTfL+Bd7n
	6Ww7NoyzxCC4kB3WWWFnXDlcgli/MHC9974HVchySHg1Doqwb/gU1bWtz1lVrz7kLTEo
	nb3w==
X-Gm-Message-State: ALoCoQk/+NRkpyT0YNZU0jKN1DKg7s7r51Th28pVPwk5nX4DWrwnScqY5ViHd6Q9qORLn33Um/qz
X-Received: by 10.194.92.148 with SMTP id cm20mr71566561wjb.88.1416504003426; 
	Thu, 20 Nov 2014 09:20:03 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id iz19sm7499886wic.8.2014.11.20.09.20.02
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 09:20:02 -0800 (PST)
Message-ID: <546E22C1.6050206@linaro.org>
Date: Thu, 20 Nov 2014 17:20:01 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>	
	<1416499682.14429.41.camel@citrix.com>
	<546E1389.1070304@linaro.org>	 <546E1526.6090406@linaro.org>
	<1416500962.20161.4.camel@citrix.com>	
	<546E1A18.1040606@linaro.org> <1416502322.20161.9.camel@citrix.com>
	<1416502667.21748.1.camel@citrix.com>
In-Reply-To: <1416502667.21748.1.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 04:57 PM, Ian Campbell wrote:
> On Thu, 2014-11-20 at 16:52 +0000, Ian Campbell wrote:
>> On Thu, 2014-11-20 at 16:43 +0000, Julien Grall wrote:
>>> On 11/20/2014 04:29 PM, Ian Campbell wrote:
>>>>> Forgot to add, the example above show the difference without and with
>>>>> the patch. The list is correct because both ARM and x86 maintainers
>>>>> should be CC. Because of this all "THE REST" maintainers are added.
>>>>
>>>> Just to be clear, you mean that everyone under THE REST is added solely
>>>> because they also happen to be maintainers of some other relevant bit of
>>>> code, not that THE REST is explicitly added in this case, right?
>>>
> 
> Just a small clarification...
> 
>>> Yes, my description was confusing. With setting $email_remove_duplicates
>>> to 0, the script will:
>>>    1) Append the list of maintainers for every file
> 
> At this point each maintainer remains associated with the role/reason
> they are added, right?

Yes. Every time the maintainers is listed we add in the list no matters
if the mail already exists. So the maintainers may be listed twice with
different roles (for instance: x86 and "THE REST").

>>>    2) Filter the list to remove the entry with "THE REST" role
> 
> And this only happens if there are roles other than "THE REST" in the
> list?

Yes.

> 
>>>    3) Remove duplicated address
>>>
>>> The previous behavior was:
>>>    1) Get the list of maintainers of the file (incidentally all the
>>> maintainers in "THE REST" role are added). If the email address already
>>> exists in the global list, skip it.
>>>    2) Filter the list to remove the entry with "THE REST" role
> 
> Whereas here the link from maintainer to the role is lost, hence
> everyone in THE REST is blindly removed?

Yes.

>>> So if a maintainers is marked on the "THE REST" on the first file and
>>> actually be an x86 maintainers on the second file, the scripts will only
>>> retain the "THE REST" role.
>>>
>>> If it's more clear, I can add the explanation above in the commit message.
>>
>> It is, please do.

I will send a new version.

Regards,


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 17:20:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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.xen.org>)
	id 1XrVPc-0004J9-6r; Thu, 20 Nov 2014 17:20:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrVPa-0004Ix-VK
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 17:20:55 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	5E/03-07724-6F22E645; Thu, 20 Nov 2014 17:20:54 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416504053!12727469!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19612 invoked from network); 20 Nov 2014 17:20:53 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 17:20:53 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so4328686wgg.14
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 09:20:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=u+johSpG4u8dBQgi5YEV4qGywcEqXyxGmaJNCt76H2g=;
	b=fAlNqohGrM7eFGUec7JFrV5TIWVOsrS9iUxQ1b7CQfVnzRopewNzSAlDR0e/yAzbqy
	fYA66SFq4hs75jJJTk2yOLv+p+w5+skPOmmY7xBWl3d8I8PyLNewvF6eunF2/EfvOu7s
	pbB9qRZyrCp6+MJFQP3DkJ6Yqdprd5aGpzotyFpAElWFW8TdF0PPRcIiyn2PTW+xLHeB
	VXzxrsU0qvV6iUbG0AeghDMJzd1Q30RLOHeTIt5fRB9k0TJYuNEADqnJRGewH5+iZj1S
	jvHqGVW4TI3kYCk4jZlzhm61JO30+D/zvreQqFyfshFDVKMa1UYQTcSM5jVVxG/96m7C
	v0oA==
X-Gm-Message-State: ALoCoQlyvpKbENzY+GUYNvOwMeWBIhhezKeisT4g8PqWMQsQbZjztRHK7L4fceRXW9UgfUWPYC7c
X-Received: by 10.194.200.101 with SMTP id jr5mr68467466wjc.6.1416504053346;
	Thu, 20 Nov 2014 09:20:53 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fl1sm7495600wib.15.2014.11.20.09.20.52
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 09:20:52 -0800 (PST)
Message-ID: <546E22F3.40106@linaro.org>
Date: Thu, 20 Nov 2014 17:20:51 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>	
	<1416499682.14429.41.camel@citrix.com>
	<546E1389.1070304@linaro.org> <1416501018.20161.5.camel@citrix.com>
In-Reply-To: <1416501018.20161.5.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 04:30 PM, Ian Campbell wrote:
> On Thu, 2014-11-20 at 16:15 +0000, Julien Grall wrote:
>> Hi Ian,
>>
>> On 11/20/2014 04:08 PM, Ian Campbell wrote:
>>> On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
>>>> By default, the script get_maintainer.pl will remove duplicates email as soon
>>>> as it appends the list of maintainers of a new file, and therefore override
>>>> the role of the developper.
>>>>
>>>> On complex patch (see [1]), this will result to ommitting randomly some
>>>> maintainers.
>>>>
>>>> This could be fixed
>>>
>>> Are you proposing an alternative/better fix here? or describing what
>>> this patch does?
>>
>> Describing what the patch does.
> 
> Then I think you meant "This is fixed" or "This patches fixes this
> by ...".

Ok. I will fix it.

> 
>> By drawbacks I meant, if there is another bug in the script then we may
>> end up to cc too many people. Honestly I don't believe it's the case.
> 
> Sure, lets assume not.

I will drop this drawbacks.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 17:20:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 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.xen.org>)
	id 1XrVPc-0004J9-6r; Thu, 20 Nov 2014 17:20:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrVPa-0004Ix-VK
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 17:20:55 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	5E/03-07724-6F22E645; Thu, 20 Nov 2014 17:20:54 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416504053!12727469!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19612 invoked from network); 20 Nov 2014 17:20:53 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 17:20:53 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so4328686wgg.14
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 09:20:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=u+johSpG4u8dBQgi5YEV4qGywcEqXyxGmaJNCt76H2g=;
	b=fAlNqohGrM7eFGUec7JFrV5TIWVOsrS9iUxQ1b7CQfVnzRopewNzSAlDR0e/yAzbqy
	fYA66SFq4hs75jJJTk2yOLv+p+w5+skPOmmY7xBWl3d8I8PyLNewvF6eunF2/EfvOu7s
	pbB9qRZyrCp6+MJFQP3DkJ6Yqdprd5aGpzotyFpAElWFW8TdF0PPRcIiyn2PTW+xLHeB
	VXzxrsU0qvV6iUbG0AeghDMJzd1Q30RLOHeTIt5fRB9k0TJYuNEADqnJRGewH5+iZj1S
	jvHqGVW4TI3kYCk4jZlzhm61JO30+D/zvreQqFyfshFDVKMa1UYQTcSM5jVVxG/96m7C
	v0oA==
X-Gm-Message-State: ALoCoQlyvpKbENzY+GUYNvOwMeWBIhhezKeisT4g8PqWMQsQbZjztRHK7L4fceRXW9UgfUWPYC7c
X-Received: by 10.194.200.101 with SMTP id jr5mr68467466wjc.6.1416504053346;
	Thu, 20 Nov 2014 09:20:53 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id fl1sm7495600wib.15.2014.11.20.09.20.52
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 09:20:52 -0800 (PST)
Message-ID: <546E22F3.40106@linaro.org>
Date: Thu, 20 Nov 2014 17:20:51 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416341031-6204-1-git-send-email-julien.grall@linaro.org>	
	<1416499682.14429.41.camel@citrix.com>
	<546E1389.1070304@linaro.org> <1416501018.20161.5.camel@citrix.com>
In-Reply-To: <1416501018.20161.5.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 04:30 PM, Ian Campbell wrote:
> On Thu, 2014-11-20 at 16:15 +0000, Julien Grall wrote:
>> Hi Ian,
>>
>> On 11/20/2014 04:08 PM, Ian Campbell wrote:
>>> On Tue, 2014-11-18 at 20:03 +0000, Julien Grall wrote:
>>>> By default, the script get_maintainer.pl will remove duplicates email as soon
>>>> as it appends the list of maintainers of a new file, and therefore override
>>>> the role of the developper.
>>>>
>>>> On complex patch (see [1]), this will result to ommitting randomly some
>>>> maintainers.
>>>>
>>>> This could be fixed
>>>
>>> Are you proposing an alternative/better fix here? or describing what
>>> this patch does?
>>
>> Describing what the patch does.
> 
> Then I think you meant "This is fixed" or "This patches fixes this
> by ...".

Ok. I will fix it.

> 
>> By drawbacks I meant, if there is another bug in the script then we may
>> end up to cc too many people. Honestly I don't believe it's the case.
> 
> Sure, lets assume not.

I will drop this drawbacks.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 17:36:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 17:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrVeM-0004nc-KS; Thu, 20 Nov 2014 17:36:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrVeL-0004nX-DT
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 17:36:09 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	E7/5D-02696-8862E645; Thu, 20 Nov 2014 17:36:08 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416504967!9187177!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9303 invoked from network); 20 Nov 2014 17:36:08 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 17:36:08 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so4390060wgh.20
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 09:36:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=+VGPqf0rriSd/9YOVhYVB3skcLo2a/YaP679VKjkZ0Q=;
	b=Fo37j26OkXiq9tr600mipcs8AywOU+nrXbqx5odwRTISkFmToEhkYnx1FXyRR4+AFk
	wooXc4IbnZ6+0AQOJUbt1A0mP8KA+lDKMTtkqX3gpl+nsR+2M9JqS6whXh4M94pj0IDd
	dKgspudI+RLwLOxq0aMZgy/voUWWCwEbbJDoqhqX9cjQU35jB45tYqkFBQ1Qi+/LPaKZ
	4rLdFaALgfGgI5vSPWk78aXifQwfdh7kSpIX/rXApB5rbP/f3kyawBWsT4xEu7nPO6jz
	DmVxmRva6tAeW6znbnX2YgMD3a2V0dIO0Z2SDYrHU9VantSeQTfukjGugZeBMqkrxm+x
	R/bQ==
X-Gm-Message-State: ALoCoQldnXAwCQd+42+fOUUNKO3J+Rx3NoWWpAac2ycPlARHj4bAQTHDTp8AWKgzQGlEfEvk7JN3
X-Received: by 10.180.77.79 with SMTP id q15mr72183wiw.8.1416504967653;
	Thu, 20 Nov 2014 09:36:07 -0800 (PST)
Received: from belegaer.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id ry19sm4332037wjb.3.2014.11.20.09.36.05
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 09:36:06 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Thu, 20 Nov 2014 17:36:03 +0000
Message-Id: <1416504963-4830-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 1.7.10.4
Cc: Julien Grall <julien.grall@linaro.org>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, Don Slutz <dslutz@verizon.com>
Subject: [Xen-devel] [PATCH v2 for 4.5] scripts/get_maintainer.pl: Correctly
	CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 script is setting $email_remove_duplicates to 1 by default, on
complex patch (see [1]), this will result to ommitting randomly some
maintainers.

This is because, the script will:
    1) Get the list of maintainers of the file (incidentally all the
       maintainers in "THE REST" role are added). If the email address already
       exists in the global list, skip it. => The role will be lost
    2) Filter the list to remove the entry with "THE REST" role

So if a maintainers is marked with "THE REST" role on the first file and
actually be an x86 maintainers on the script, the script will only retain
the "THE REST" role. During the filtering step, this maintainers will
therefore be dropped.

This patch fixes this by setting $email_remove_duplicates to 0 by default.
The new behavior of the script will be:
    1) Append the list of maintainers for every file
    2) Filter the list to remove the entry with "THE REST" role
    3) Remove duplicated email address

Example:

Patch: https://patches.linaro.org/41083/

Before the patch:

Daniel De Graaf <dgdegra@tycho.nsa.gov>
Ian Jackson <ian.jackson@eu.citrix.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Wei Liu <wei.liu2@citrix.com>
George Dunlap <george.dunlap@eu.citrix.com>
xen-devel@lists.xen.org

After the patch:

Daniel De Graaf <dgdegra@tycho.nsa.gov>
Ian Jackson <ian.jackson@eu.citrix.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Wei Liu <wei.liu2@citrix.com>
Stefano Stabellini <stefano.stabellini@citrix.com>
Tim Deegan <tim@xen.org>
Keir Fraser <keir@xen.org>
Jan Beulich <jbeulich@suse.com>
George Dunlap <george.dunlap@eu.citrix.com>
xen-devel@lists.xen.org

[1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html

Signed-off-by: Julien Grall <julien.grall@linaro.org>
CC: Don Slutz <dslutz@verizon.com>

---
    Changes in v2:
        - Rework the commit message to explain the problem and the
        solution more clearly

    I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
    time the script has been introduced).

    Developpers using this script won't ommitted to cc some maintainers, and it
    will avoid maintainers complaining about miss CC.

    The only drawbacks I can see is if the maintainers is referenced twice in
    the file MAINTAINERS with different email, the script won't notice it's
    duplicated and list 2 times. Though, for this one it could be fixed by
    modifying  the MAINTAINERS file. Is it worth for Xen 4.5? For know,
    it seems to only happen with Stefano.
---
 scripts/get_maintainer.pl |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index df920e2..cc445cd 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -35,7 +35,7 @@ my $email_git_min_percent = 5;
 my $email_git_since = "1-year-ago";
 my $email_hg_since = "-365";
 my $interactive = 0;
-my $email_remove_duplicates = 1;
+my $email_remove_duplicates = 0;
 my $email_use_mailmap = 1;
 my $email_drop_the_rest_supporter_if_supporter_found = 1;
 my $output_multiline = 1;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 17:36:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 17:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrVeM-0004nc-KS; Thu, 20 Nov 2014 17:36:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XrVeL-0004nX-DT
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 17:36:09 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	E7/5D-02696-8862E645; Thu, 20 Nov 2014 17:36:08 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416504967!9187177!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9303 invoked from network); 20 Nov 2014 17:36:08 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 17:36:08 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so4390060wgh.20
	for <xen-devel@lists.xenproject.org>;
	Thu, 20 Nov 2014 09:36:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=+VGPqf0rriSd/9YOVhYVB3skcLo2a/YaP679VKjkZ0Q=;
	b=Fo37j26OkXiq9tr600mipcs8AywOU+nrXbqx5odwRTISkFmToEhkYnx1FXyRR4+AFk
	wooXc4IbnZ6+0AQOJUbt1A0mP8KA+lDKMTtkqX3gpl+nsR+2M9JqS6whXh4M94pj0IDd
	dKgspudI+RLwLOxq0aMZgy/voUWWCwEbbJDoqhqX9cjQU35jB45tYqkFBQ1Qi+/LPaKZ
	4rLdFaALgfGgI5vSPWk78aXifQwfdh7kSpIX/rXApB5rbP/f3kyawBWsT4xEu7nPO6jz
	DmVxmRva6tAeW6znbnX2YgMD3a2V0dIO0Z2SDYrHU9VantSeQTfukjGugZeBMqkrxm+x
	R/bQ==
X-Gm-Message-State: ALoCoQldnXAwCQd+42+fOUUNKO3J+Rx3NoWWpAac2ycPlARHj4bAQTHDTp8AWKgzQGlEfEvk7JN3
X-Received: by 10.180.77.79 with SMTP id q15mr72183wiw.8.1416504967653;
	Thu, 20 Nov 2014 09:36:07 -0800 (PST)
Received: from belegaer.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id ry19sm4332037wjb.3.2014.11.20.09.36.05
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Nov 2014 09:36:06 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Thu, 20 Nov 2014 17:36:03 +0000
Message-Id: <1416504963-4830-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 1.7.10.4
Cc: Julien Grall <julien.grall@linaro.org>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, Don Slutz <dslutz@verizon.com>
Subject: [Xen-devel] [PATCH v2 for 4.5] scripts/get_maintainer.pl: Correctly
	CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 script is setting $email_remove_duplicates to 1 by default, on
complex patch (see [1]), this will result to ommitting randomly some
maintainers.

This is because, the script will:
    1) Get the list of maintainers of the file (incidentally all the
       maintainers in "THE REST" role are added). If the email address already
       exists in the global list, skip it. => The role will be lost
    2) Filter the list to remove the entry with "THE REST" role

So if a maintainers is marked with "THE REST" role on the first file and
actually be an x86 maintainers on the script, the script will only retain
the "THE REST" role. During the filtering step, this maintainers will
therefore be dropped.

This patch fixes this by setting $email_remove_duplicates to 0 by default.
The new behavior of the script will be:
    1) Append the list of maintainers for every file
    2) Filter the list to remove the entry with "THE REST" role
    3) Remove duplicated email address

Example:

Patch: https://patches.linaro.org/41083/

Before the patch:

Daniel De Graaf <dgdegra@tycho.nsa.gov>
Ian Jackson <ian.jackson@eu.citrix.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Wei Liu <wei.liu2@citrix.com>
George Dunlap <george.dunlap@eu.citrix.com>
xen-devel@lists.xen.org

After the patch:

Daniel De Graaf <dgdegra@tycho.nsa.gov>
Ian Jackson <ian.jackson@eu.citrix.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Wei Liu <wei.liu2@citrix.com>
Stefano Stabellini <stefano.stabellini@citrix.com>
Tim Deegan <tim@xen.org>
Keir Fraser <keir@xen.org>
Jan Beulich <jbeulich@suse.com>
George Dunlap <george.dunlap@eu.citrix.com>
xen-devel@lists.xen.org

[1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html

Signed-off-by: Julien Grall <julien.grall@linaro.org>
CC: Don Slutz <dslutz@verizon.com>

---
    Changes in v2:
        - Rework the commit message to explain the problem and the
        solution more clearly

    I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
    time the script has been introduced).

    Developpers using this script won't ommitted to cc some maintainers, and it
    will avoid maintainers complaining about miss CC.

    The only drawbacks I can see is if the maintainers is referenced twice in
    the file MAINTAINERS with different email, the script won't notice it's
    duplicated and list 2 times. Though, for this one it could be fixed by
    modifying  the MAINTAINERS file. Is it worth for Xen 4.5? For know,
    it seems to only happen with Stefano.
---
 scripts/get_maintainer.pl |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index df920e2..cc445cd 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -35,7 +35,7 @@ my $email_git_min_percent = 5;
 my $email_git_since = "1-year-ago";
 my $email_hg_since = "-365";
 my $interactive = 0;
-my $email_remove_duplicates = 1;
+my $email_remove_duplicates = 0;
 my $email_use_mailmap = 1;
 my $email_drop_the_rest_supporter_if_supporter_found = 1;
 my $output_multiline = 1;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 17:40:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 17:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrViu-0004yD-Ak; Thu, 20 Nov 2014 17:40:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrVit-0004y8-NO
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 17:40:51 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F5/EA-03145-2A72E645; Thu, 20 Nov 2014 17:40:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416505247!13829814!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14266 invoked from network); 20 Nov 2014 17:40:50 -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;
	20 Nov 2014 17:40:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="194898653"
Message-ID: <1416505070.26869.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 20 Nov 2014 17:37:50 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH OSSTEST v3 00/15] support for ARM32 arndale and
 cubietruck 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

I'm preparing a bunch of each of these boards to be racked for inclusion
in osstest. This series adds the necessary osstest support:

      * Support for platforms which require us to supply a Device Tree
      * Removing various hardcoded midway assumptions
      * Some new features needed to workaround h/w quirks (of arndale in
        particular)
      * Support for the power relay switch board which these are
        attached to
      * Some new convenience features

I have run a full (including host reinstall) build-* job on each
platform.

I have successfully run test-armhf-armhf-xl on cubietruck and this time
around on arndale too.

For reference the relevant bits of my ~/.xen-osstest/config are below.

Since v2 I've addressed review and figured out a working arndale kernel
config.

Quite a bit of this is now acked and I think the rest is in pretty good
shape. The major blocker right now is that rerunning
mg-debian-installer-update pulls in a newer kernel from backports.org
which doesn't boot on the existing midway platform. I'm investigating
that at the moment.

Despite that in theory most of this could go in now, since the midway
kernel issue is already there if we rerun mg-debian-installer-update and
most of the rest is benign until osstest's db learns about the new
systems. "make-flight: Run a basic test on each arm platform" could be
omitted for now. Or we could just wait with the whole lot.

Ian.

#HostProp_metrocentre_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 1
HostProp_westfield_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 2
HostProp_lakeside_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 3
HostProp_bluewater_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 4

HostProp_braque_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 5
HostProp_picaso_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 6
HostProp_metzinger_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 7
HostProp_gleizes_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 8

HostGroupProp_arndale_LinuxSerialConsole ttySAC2
HostGroupProp_arndale_Build_Make_Flags -j4
HostGroupProp_arndale_XenSerialConsole dtuart
HostGroupProp_arndale_XenDTUARTPath /serial@12C20000
HostGroupProp_arndale_Interface_Force eth0
HostGroupProp_arndale_ExtraInitramfsModules clk-s2mps11 s5m8767 i2c-s3c2410 phy-exynos5250-sata
HostGroupProp_arndale_Rootdelay 3
HostGroupProp_arndale_UBootScriptEarlyCommands setenv xen_addr_r 0x41000000

HostGroupFlags_arndale suite-wheezy,equiv-arndale,need-kernel-deb-armmp,no-di-kernel,force-mac-address,need-uboot-bootscr

HostGroup_metrocentre arndale
HostProp_metrocentre_Fqdn metrocentre.uk.xensource.com
HostProp_metrocentre_Ether 9e:04:00:59:64:5a

HostGroup_westfield arndale
HostProp_westfield_Fqdn westfield.uk.xensource.com
HostProp_westfield_Ether a6:46:13:77:e8:2f

HostGroup_lakeside arndale
HostProp_lakeside_Fqdn lakeside.uk.xensource.com
HostProp_lakeside_Ether e2:e7:75:3f:df:4c

HostGroup_bluewater arndale
HostProp_bluewater_Fqdn bluewater.uk.xensource.com
HostProp_bluewater_Ether f2:dc:22:d7:e9:e9

HostGroupProp_cubietruck_LinuxSerialConsole ttyS0
HostGroupProp_cubietruck_Build_Make_Flags -j4
HostGroupProp_cubietruck_XenSerialConsole dtuart
HostGroupProp_cubietruck_XenDTUARTPath /soc@01c00000/serial@01c28000 
HostGroupProp_cubietruck_UBootScriptEarlyCommands setenv xen_addr_r 0x41000000
HostGroupFlags_cubietruck suite-wheezy,equiv-cubietruck,need-kernel-deb-armmp,no-di-kernel,need-uboot-bootscr

HostGroup_braque cubietruck
HostProp_braque_Fqdn braque.uk.xensource.com

HostGroup_picaso cubietruck
HostProp_picaso_Fqdn picaso.uk.xensource.com

HostGroup_metzinger cubietruck
HostProp_metzinger metzinger.uk.xensource.com

HostGroup_gleizes cubietruck
HostProp_gleizes_Fqdn gleizes.uk.xensource.com



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 17:40:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 17:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrViu-0004yD-Ak; Thu, 20 Nov 2014 17:40:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrVit-0004y8-NO
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 17:40:51 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F5/EA-03145-2A72E645; Thu, 20 Nov 2014 17:40:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416505247!13829814!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14266 invoked from network); 20 Nov 2014 17:40:50 -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;
	20 Nov 2014 17:40:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="194898653"
Message-ID: <1416505070.26869.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 20 Nov 2014 17:37:50 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH OSSTEST v3 00/15] support for ARM32 arndale and
 cubietruck 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

I'm preparing a bunch of each of these boards to be racked for inclusion
in osstest. This series adds the necessary osstest support:

      * Support for platforms which require us to supply a Device Tree
      * Removing various hardcoded midway assumptions
      * Some new features needed to workaround h/w quirks (of arndale in
        particular)
      * Support for the power relay switch board which these are
        attached to
      * Some new convenience features

I have run a full (including host reinstall) build-* job on each
platform.

I have successfully run test-armhf-armhf-xl on cubietruck and this time
around on arndale too.

For reference the relevant bits of my ~/.xen-osstest/config are below.

Since v2 I've addressed review and figured out a working arndale kernel
config.

Quite a bit of this is now acked and I think the rest is in pretty good
shape. The major blocker right now is that rerunning
mg-debian-installer-update pulls in a newer kernel from backports.org
which doesn't boot on the existing midway platform. I'm investigating
that at the moment.

Despite that in theory most of this could go in now, since the midway
kernel issue is already there if we rerun mg-debian-installer-update and
most of the rest is benign until osstest's db learns about the new
systems. "make-flight: Run a basic test on each arm platform" could be
omitted for now. Or we could just wait with the whole lot.

Ian.

#HostProp_metrocentre_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 1
HostProp_westfield_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 2
HostProp_lakeside_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 3
HostProp_bluewater_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 4

HostProp_braque_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 5
HostProp_picaso_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 6
HostProp_metzinger_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 7
HostProp_gleizes_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 8

HostGroupProp_arndale_LinuxSerialConsole ttySAC2
HostGroupProp_arndale_Build_Make_Flags -j4
HostGroupProp_arndale_XenSerialConsole dtuart
HostGroupProp_arndale_XenDTUARTPath /serial@12C20000
HostGroupProp_arndale_Interface_Force eth0
HostGroupProp_arndale_ExtraInitramfsModules clk-s2mps11 s5m8767 i2c-s3c2410 phy-exynos5250-sata
HostGroupProp_arndale_Rootdelay 3
HostGroupProp_arndale_UBootScriptEarlyCommands setenv xen_addr_r 0x41000000

HostGroupFlags_arndale suite-wheezy,equiv-arndale,need-kernel-deb-armmp,no-di-kernel,force-mac-address,need-uboot-bootscr

HostGroup_metrocentre arndale
HostProp_metrocentre_Fqdn metrocentre.uk.xensource.com
HostProp_metrocentre_Ether 9e:04:00:59:64:5a

HostGroup_westfield arndale
HostProp_westfield_Fqdn westfield.uk.xensource.com
HostProp_westfield_Ether a6:46:13:77:e8:2f

HostGroup_lakeside arndale
HostProp_lakeside_Fqdn lakeside.uk.xensource.com
HostProp_lakeside_Ether e2:e7:75:3f:df:4c

HostGroup_bluewater arndale
HostProp_bluewater_Fqdn bluewater.uk.xensource.com
HostProp_bluewater_Ether f2:dc:22:d7:e9:e9

HostGroupProp_cubietruck_LinuxSerialConsole ttyS0
HostGroupProp_cubietruck_Build_Make_Flags -j4
HostGroupProp_cubietruck_XenSerialConsole dtuart
HostGroupProp_cubietruck_XenDTUARTPath /soc@01c00000/serial@01c28000 
HostGroupProp_cubietruck_UBootScriptEarlyCommands setenv xen_addr_r 0x41000000
HostGroupFlags_cubietruck suite-wheezy,equiv-cubietruck,need-kernel-deb-armmp,no-di-kernel,need-uboot-bootscr

HostGroup_braque cubietruck
HostProp_braque_Fqdn braque.uk.xensource.com

HostGroup_picaso cubietruck
HostProp_picaso_Fqdn picaso.uk.xensource.com

HostGroup_metzinger cubietruck
HostProp_metzinger metzinger.uk.xensource.com

HostGroup_gleizes cubietruck
HostProp_gleizes_Fqdn gleizes.uk.xensource.com



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 17:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 17:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrVjB-00050L-Nh; Thu, 20 Nov 2014 17:41:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrVjA-00050B-Lm
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 17:41:08 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	36/2B-03145-3B72E645; Thu, 20 Nov 2014 17:41:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416505264!13846457!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8450 invoked from network); 20 Nov 2014 17:41:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 17:41:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="193366914"
Message-ID: <1416505012.26869.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 20 Nov 2014 17:36:52 +0000
In-Reply-To: <1416491475-7078-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1416491475-7078-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH] linux-next tests: Use correct
 branch for baseline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 13:51 +0000, Ian Jackson wrote:
> Make cr-daily-branch honour an environment or setting variable
> EXTRA_SGR_ARGS.  In branch-settings.linux-next set it appropriately to
> arrange that the linux-next test reports consider linux-linus tests as
> interesting as well as just linux-next ones.
> 
> (We already use a flight from linux-linus for selecting the baseline
> linux version.)
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  branch-settings.linux-next |    1 +
>  cr-daily-branch            |    2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/branch-settings.linux-next b/branch-settings.linux-next
> index e9bf926..1c5660b 100644
> --- a/branch-settings.linux-next
> +++ b/branch-settings.linux-next
> @@ -2,3 +2,4 @@ OSSTEST_NO_BASELINE=y
>  OSSTEST_PUSH=false
>  OLD_REVISION=determine-late
>  GITFORCEFLAG=--fail
> +EXTRA_SGR_ARGS=--branches-also=linux-linus
> diff --git a/cr-daily-branch b/cr-daily-branch
> index d00ecbb..17bb2c9 100755
> --- a/cr-daily-branch
> +++ b/cr-daily-branch
> @@ -301,6 +301,8 @@ END
>          ;;
>  esac
>  
> +sgr_args+=" $EXTRA_SGR_ARGS"
> +
>  : $flight $branch $OSSTEST_BLESSING $sgr_args
>  $DAILY_BRANCH_PREEXEC_HOOK
>  execute_flight $flight $OSSTEST_BLESSING



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 17:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 17:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrVjB-00050L-Nh; Thu, 20 Nov 2014 17:41:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrVjA-00050B-Lm
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 17:41:08 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	36/2B-03145-3B72E645; Thu, 20 Nov 2014 17:41:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416505264!13846457!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8450 invoked from network); 20 Nov 2014 17:41:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 17:41:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="193366914"
Message-ID: <1416505012.26869.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 20 Nov 2014 17:36:52 +0000
In-Reply-To: <1416491475-7078-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1416491475-7078-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH] linux-next tests: Use correct
 branch for baseline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 13:51 +0000, Ian Jackson wrote:
> Make cr-daily-branch honour an environment or setting variable
> EXTRA_SGR_ARGS.  In branch-settings.linux-next set it appropriately to
> arrange that the linux-next test reports consider linux-linus tests as
> interesting as well as just linux-next ones.
> 
> (We already use a flight from linux-linus for selecting the baseline
> linux version.)
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  branch-settings.linux-next |    1 +
>  cr-daily-branch            |    2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/branch-settings.linux-next b/branch-settings.linux-next
> index e9bf926..1c5660b 100644
> --- a/branch-settings.linux-next
> +++ b/branch-settings.linux-next
> @@ -2,3 +2,4 @@ OSSTEST_NO_BASELINE=y
>  OSSTEST_PUSH=false
>  OLD_REVISION=determine-late
>  GITFORCEFLAG=--fail
> +EXTRA_SGR_ARGS=--branches-also=linux-linus
> diff --git a/cr-daily-branch b/cr-daily-branch
> index d00ecbb..17bb2c9 100755
> --- a/cr-daily-branch
> +++ b/cr-daily-branch
> @@ -301,6 +301,8 @@ END
>          ;;
>  esac
>  
> +sgr_args+=" $EXTRA_SGR_ARGS"
> +
>  : $flight $branch $OSSTEST_BLESSING $sgr_args
>  $DAILY_BRANCH_PREEXEC_HOOK
>  execute_flight $flight $OSSTEST_BLESSING



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 18:08:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 18: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 1XrW9n-0005m8-85; Thu, 20 Nov 2014 18:08:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrW9l-0005m3-4j
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 18:08:37 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	43/B6-02696-42E2E645; Thu, 20 Nov 2014 18:08:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416506912!9192791!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10246 invoked from network); 20 Nov 2014 18:08:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 18:08:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="193380833"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 13:07:35 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrW8g-0007rm-EF;
	Thu, 20 Nov 2014 18:07:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrW8g-0002ju-5F;
	Thu, 20 Nov 2014 18:07:30 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 20 Nov 2014 18:07:29 +0000
Message-ID: <1416506849-10498-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH] README.planner: Document the resource
	planning system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
 README.planner |  181 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 180 insertions(+), 1 deletion(-)

diff --git a/README.planner b/README.planner
index de8b962..ec4dce8 100644
--- a/README.planner
+++ b/README.planner
@@ -1,4 +1,183 @@
-Resource planner / scheduler
+RESOURCE PLANNER (IE SCHEDULER)
+===============================
+
+Overall architecture
+--------------------
+
+Resources (eg hosts) are owned by `tasks'.  As resources are allocated
+and deallocated, their `owntaskid' in the database is updated.
+
+When a process wishes to allocate resources, it does as follows:
+
+ - Select an appropriate task.  For command-line use, the user@host
+   static task usually used (as specified by the OSSTEST_TASK env var)
+   and things fail if it doesn't actually exist.
+
+   Automatic runs create a new ownd task for each job (in become-task
+   in JobDB-Executive.tcl, in sg-run-job.
+
+ - Connect to the queue daemon and participate in the planning
+   process.
+
+
+Planning
+--------
+
+The queue daemon sequences the planning of resource use and the
+allocation of resources.  This is done in a periodic planning cycle.
+Planning cycles are prompted by newly available resources, new
+requests for participation, and periodically.
+
+During each planning cycle we construct, from scratch, a complete plan
+for which resources are to be used, when, by which tasks.  Resources
+which are free and suitable for allocation right away are planned and
+allocated for immediate use.
+
+But, the plan extends far enough into the future to cover all
+currently-foreseeable requirements for resources.  This provides the
+planning algorithms the most complete information about available
+tradeoffs, and also provides useful output (the resource plan) for
+administrators and users.
+
+Each planning cycle starts with the existing allocated resources.  The
+planning daemon records (on disk, not in the database) what expected
+duration was declared with each of those allocations.  (A task that
+has allocated the resources it needs does not any longer participate
+in the planning process, although it will retain a liveness connection
+to the ms-ownerdaemon.)
+
+Then each interested client of ms-queuedaemon is asked - one by one,
+in turn - to fill into the plan-under-construction, what resources it
+intends to uses when.  Clients specify the expected duration of their
+use (but there is no mechanism for enforcing accuracy of these
+estimates).  ms-queuedaemon collates and records the provided
+information and passes it on to the next client.
+
+If there are resources which are available right now which a client
+wants to use, the client will allocate it there and then during its
+planning slot.
+
+The queueing order is determined by the job priority value.  Each
+client declares its own priority.  The usual basis for the priority is
+is client's starting time_t.  So by and large jobs execute in order.
+
+The main client in the planning process is
+ts-hosts-allocate-Executive.  That program contains the heuristics for
+choosing good tests hosts under various conditions.
+
+Command-line users can use mg-allocate -U to obtain resources through
+the planning process.  mg-allocate participates with a high queue
+priority so that command-line allocations will take precedence over
+automatic test runs.  (mg-allocate without -U bypasses the planner and
+can be used to `grab' resources which happen currently to be free.)
+
+The distinction between `idle' and `allocatable' resources exists so
+that newly-freed resources are properly offered first to the tasks at
+the front of the queue.  ms-ownerdaemon sets all idle resources to
+allocatable at the start of each planning cycle.
+
+
+ms-ownerdaemon and `ownd' tasks
+-------------------------------
+
+ms-ownerdaemon helps with cleanup and does nothing else.  Test runs
+connect to it and obtain ephemeral `task' ids.  All of the processes
+which are part of the the test run retain a descriptor onto the
+socket connection to ms-ownerdaemon.  When the last holder of a copy
+of the socket connection fd dies, ms-ownerdaemon sees the connection
+close.  It then sets the task to `not live' in the database.
+
+This means that there is no need for any explicit cleanup: tasks
+which just crash have their resources freed automatically.
+
+If the ms-ownerdaemon fails and is restarted, the tasks which were
+clients of the previous ms-owerdaemon cannot be automatically cleaned
+up.  The new ms-ownerdaemon will annotate them with `previous'.  The
+administrator can then clean them up manually, if she knows that all
+the corresponding actual processes are no longer running.
+
+
+Types of task
+-------------
+
+ * static tasks.  Usual for command-line use.  They are manually
+   created (with ./mg-hosts manual-task-create) and not normally ever
+   destroyed.
+
+ * `ownd' tasks.  These are used for production runs from cron and
+   some other mostly-automatic invocations of osstest (eg
+   mg-execute-flight).  They are automatically created and destroyed -
+   see above.
+
+ * magic task numbers with special meanings:
+
+     magic/allocatable
+
+        The resource is free and a process which is participating in
+        the planning process may allocate it to themselves by updating
+        the `owntaskid' in the resources table to refer to their own
+        task.
+
+     magic/idle
+
+        The resource is free but has perhaps only recently become so.
+        It can be allocated outside the planning process, but proceses
+        participating in planning should regard the resource as
+        unavailable.
+
+     magic/shared
+
+        The resource has been divided into shares.  It is unavailable
+        in its own right without being unshared first.  The individual
+        shares have their own owners.
+
+     magic/preparing
+
+        Applies only to shares of a divided resource.  The share is
+        unavailable because the process handling the division is still
+        putting the resource into the proper state implied by the
+        sharing information (see below).
+
+
+Sharing
+-------
+
+Hosts can be shared between multiple clients.  The first client to
+decide to set up a host for sharing:
+
+ - `Divides' the resource in the database
+    * allocates the host to the taskid `shared' and creates a set
+      of new rows in the resources table to represent the shares
+      (the number of shares is fixed at this point)
+    * initially, sets all but one of those shares to be owned by
+      magic/preparing
+    * sets the remaining share to be owned by itself
+ - Performs whatever actions are necessary to get the host into
+   a suitable state for it and others to use it (eg, installing
+   the OS)
+ - Sets the remaining shares to `idle' so that others can allocate
+   them
+
+(During planning - ie, for resources not yet available immediately -
+the intent to do this can be part of the plan so that other tasks can
+see and take account of it.  The time necessary for preparing the host
+is not currently modelled during planning.)
+
+Likewise a process which finds a shared resource completely idle can
+unshare it.  That is:
+    * Check that all the shares are allocatable
+    * Delete all the rows representing the shares
+    * Claim ownership of the main resource by changing the owntaskid
+      from `shared' to the process's own task.
+
+Shared resources also have a `wear' counter, which is there to arrange
+that shared systems get regrooved occasionally even if nothing decides
+to unshare them.
+
+
+
+DETAILED PROTOCOL NOTES
+=======================
 
 ms-queuedaemon commands
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 18:08:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 18: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 1XrW9n-0005m8-85; Thu, 20 Nov 2014 18:08:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrW9l-0005m3-4j
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 18:08:37 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	43/B6-02696-42E2E645; Thu, 20 Nov 2014 18:08:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416506912!9192791!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10246 invoked from network); 20 Nov 2014 18:08:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 18:08:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="193380833"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 20 Nov 2014 13:07:35 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrW8g-0007rm-EF;
	Thu, 20 Nov 2014 18:07:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrW8g-0002ju-5F;
	Thu, 20 Nov 2014 18:07:30 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 20 Nov 2014 18:07:29 +0000
Message-ID: <1416506849-10498-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH] README.planner: Document the resource
	planning system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
 README.planner |  181 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 180 insertions(+), 1 deletion(-)

diff --git a/README.planner b/README.planner
index de8b962..ec4dce8 100644
--- a/README.planner
+++ b/README.planner
@@ -1,4 +1,183 @@
-Resource planner / scheduler
+RESOURCE PLANNER (IE SCHEDULER)
+===============================
+
+Overall architecture
+--------------------
+
+Resources (eg hosts) are owned by `tasks'.  As resources are allocated
+and deallocated, their `owntaskid' in the database is updated.
+
+When a process wishes to allocate resources, it does as follows:
+
+ - Select an appropriate task.  For command-line use, the user@host
+   static task usually used (as specified by the OSSTEST_TASK env var)
+   and things fail if it doesn't actually exist.
+
+   Automatic runs create a new ownd task for each job (in become-task
+   in JobDB-Executive.tcl, in sg-run-job.
+
+ - Connect to the queue daemon and participate in the planning
+   process.
+
+
+Planning
+--------
+
+The queue daemon sequences the planning of resource use and the
+allocation of resources.  This is done in a periodic planning cycle.
+Planning cycles are prompted by newly available resources, new
+requests for participation, and periodically.
+
+During each planning cycle we construct, from scratch, a complete plan
+for which resources are to be used, when, by which tasks.  Resources
+which are free and suitable for allocation right away are planned and
+allocated for immediate use.
+
+But, the plan extends far enough into the future to cover all
+currently-foreseeable requirements for resources.  This provides the
+planning algorithms the most complete information about available
+tradeoffs, and also provides useful output (the resource plan) for
+administrators and users.
+
+Each planning cycle starts with the existing allocated resources.  The
+planning daemon records (on disk, not in the database) what expected
+duration was declared with each of those allocations.  (A task that
+has allocated the resources it needs does not any longer participate
+in the planning process, although it will retain a liveness connection
+to the ms-ownerdaemon.)
+
+Then each interested client of ms-queuedaemon is asked - one by one,
+in turn - to fill into the plan-under-construction, what resources it
+intends to uses when.  Clients specify the expected duration of their
+use (but there is no mechanism for enforcing accuracy of these
+estimates).  ms-queuedaemon collates and records the provided
+information and passes it on to the next client.
+
+If there are resources which are available right now which a client
+wants to use, the client will allocate it there and then during its
+planning slot.
+
+The queueing order is determined by the job priority value.  Each
+client declares its own priority.  The usual basis for the priority is
+is client's starting time_t.  So by and large jobs execute in order.
+
+The main client in the planning process is
+ts-hosts-allocate-Executive.  That program contains the heuristics for
+choosing good tests hosts under various conditions.
+
+Command-line users can use mg-allocate -U to obtain resources through
+the planning process.  mg-allocate participates with a high queue
+priority so that command-line allocations will take precedence over
+automatic test runs.  (mg-allocate without -U bypasses the planner and
+can be used to `grab' resources which happen currently to be free.)
+
+The distinction between `idle' and `allocatable' resources exists so
+that newly-freed resources are properly offered first to the tasks at
+the front of the queue.  ms-ownerdaemon sets all idle resources to
+allocatable at the start of each planning cycle.
+
+
+ms-ownerdaemon and `ownd' tasks
+-------------------------------
+
+ms-ownerdaemon helps with cleanup and does nothing else.  Test runs
+connect to it and obtain ephemeral `task' ids.  All of the processes
+which are part of the the test run retain a descriptor onto the
+socket connection to ms-ownerdaemon.  When the last holder of a copy
+of the socket connection fd dies, ms-ownerdaemon sees the connection
+close.  It then sets the task to `not live' in the database.
+
+This means that there is no need for any explicit cleanup: tasks
+which just crash have their resources freed automatically.
+
+If the ms-ownerdaemon fails and is restarted, the tasks which were
+clients of the previous ms-owerdaemon cannot be automatically cleaned
+up.  The new ms-ownerdaemon will annotate them with `previous'.  The
+administrator can then clean them up manually, if she knows that all
+the corresponding actual processes are no longer running.
+
+
+Types of task
+-------------
+
+ * static tasks.  Usual for command-line use.  They are manually
+   created (with ./mg-hosts manual-task-create) and not normally ever
+   destroyed.
+
+ * `ownd' tasks.  These are used for production runs from cron and
+   some other mostly-automatic invocations of osstest (eg
+   mg-execute-flight).  They are automatically created and destroyed -
+   see above.
+
+ * magic task numbers with special meanings:
+
+     magic/allocatable
+
+        The resource is free and a process which is participating in
+        the planning process may allocate it to themselves by updating
+        the `owntaskid' in the resources table to refer to their own
+        task.
+
+     magic/idle
+
+        The resource is free but has perhaps only recently become so.
+        It can be allocated outside the planning process, but proceses
+        participating in planning should regard the resource as
+        unavailable.
+
+     magic/shared
+
+        The resource has been divided into shares.  It is unavailable
+        in its own right without being unshared first.  The individual
+        shares have their own owners.
+
+     magic/preparing
+
+        Applies only to shares of a divided resource.  The share is
+        unavailable because the process handling the division is still
+        putting the resource into the proper state implied by the
+        sharing information (see below).
+
+
+Sharing
+-------
+
+Hosts can be shared between multiple clients.  The first client to
+decide to set up a host for sharing:
+
+ - `Divides' the resource in the database
+    * allocates the host to the taskid `shared' and creates a set
+      of new rows in the resources table to represent the shares
+      (the number of shares is fixed at this point)
+    * initially, sets all but one of those shares to be owned by
+      magic/preparing
+    * sets the remaining share to be owned by itself
+ - Performs whatever actions are necessary to get the host into
+   a suitable state for it and others to use it (eg, installing
+   the OS)
+ - Sets the remaining shares to `idle' so that others can allocate
+   them
+
+(During planning - ie, for resources not yet available immediately -
+the intent to do this can be part of the plan so that other tasks can
+see and take account of it.  The time necessary for preparing the host
+is not currently modelled during planning.)
+
+Likewise a process which finds a shared resource completely idle can
+unshare it.  That is:
+    * Check that all the shares are allocatable
+    * Delete all the rows representing the shares
+    * Claim ownership of the main resource by changing the owntaskid
+      from `shared' to the process's own task.
+
+Shared resources also have a `wear' counter, which is there to arrange
+that shared systems get regrooved occasionally even if nothing decides
+to unshare them.
+
+
+
+DETAILED PROTOCOL NOTES
+=======================
 
 ms-queuedaemon commands
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 18:28:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 18:28:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrWSs-0006DB-6f; Thu, 20 Nov 2014 18:28:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrWSq-0006D6-SL
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 18:28:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3B/27-09936-4C23E645; Thu, 20 Nov 2014 18:28:20 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416508096!14269493!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28970 invoked from network); 20 Nov 2014 18:28:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 18:28:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="194920267"
Message-ID: <546E32BB.8090909@citrix.com>
Date: Thu, 20 Nov 2014 18:28:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: [Xen-devel] Buggy interaction of live migration and p2m 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

Hello,

Tim, David and I were discussing this over lunch.  This email is a
(hopefully accurate) account of our findings, and potential solutions. 
(If I have messed up, please shout.)

Currently, correct live migration of PV domains relies on the toolstack
(which has a live mapping of the guests p2m) not observing stale values
when the guest updates its p2m, and the race condition between a p2m
update and an m2p update.  Realistically, this means no updates to the
p2m at all, due to several potential race conditions.  Should any race
conditions happen (e.g. ballooning while live migrating), the effects
could be anything from an aborted migration to VM memory corruption.

It should be noted that migrationv2 does not fix any of this.  It alters
the way in which some race conditions might be observed.  During
development of migrationv2, there was an explicit non-requirement of
fixing the existing Ballooning+LiveMigration issues we were aware,
although at the time, we were not aware of this specific set of issues. 
Our goal was to simply make migrationv2 work in the same circumstances
as previously, but with a bitness-agnostic wire format and
forward-extensible protocol.


As far as these issues are concerned, there are two distinct p2m
modifications which we care about:
1) p2m structure changes (rearranging the layout of the p2m)
2) p2m content changes (altering entries in the p2m)

There is no possible way for the toolstack to prevent a domain from
altering its p2m.  At the moment, ballooning typically only occurs when
requested by the toolstack, but the underlying operations
(increase/decrease_reservation, mem_exchange, etc) can be used by the
guest at any point.  This includes Wei's guest memory fragmentation
changes.  Changes to the content of the p2m also occur for grant map and
unmap operations.


Currently in PV guests, the p2m is implemented using a 3-level tree,
with its root in the guests shared_info page.  It provides a hard VM
memory limit of 4TB for 32bit PV guests (which is far higher than the
128GB limit from the compat p2m mappings), or 512GB for 64bit PV guests.

Juergen has a proposed new p2m interface using a virtual linear
mapping.  This is conceptually similar to the previous implementation
(which is fine from the toolstacks point of view), but far less
complicated from the guests point of view, and removes the memory limits
imposed by the p2m structure.

The new virtual linear mapping suffers from the same interaction issues
as the old 3-level tree did, but the introduction of the new interface
affords us an opportunity to make all API modifications at once to
reduce churn.


During live migration, the toolstack maps the guests p2m into a linear
mapping in the toolstacks virtual address space.  This is done once at
the start of migration, and never subsequently altered.  During live
migration, the p2m is cross-verified with the m2p, and frames are sent
using pfns as a reference, as they will be located in different frames
on the receiving side.

Should the guest change the p2m structure during live migration, the
toolstack ends up with a stale p2m with a non-p2m frame in the middle,
resulting in bogus cross-referencing.  Should the guest change an entry
in the p2m, the p2m frame itself will be resent as it would be marked as
dirty in the logdirty bitmap, but the target pfn will remain unsent and
probably stale on the receiving side.


Another factor which needs to be taken into account is Remus/COLO, which
run the domains under live migration conditions for the duration of
their lifetime.

During the live part of migration, the toolstack already has to be able
to tolerate failures to normalise the pagetables, which result as a
consequent of the pagetables being in active.  These failures are fatal
on the final iteration after the guest has been paused, but the same
logic could be extended to p2m/m2p issues, if needed.


There are several potential solutions to these problems.

1) Freeze the guests p2m during live migrate

This is the simplest sounding option, but is quite problematic from the
point of view of the guest.  It is essentially a shared spinlock between
the toolstack and the guest kernel.  It would prevent any grant
map/unmap operations from occurring, and might interact badly with
certain p2m updated in the guest which would previously be expected to
unconditionally succeed.

Pros) (Can't think of any)
Cons) Not easy to implement (even conceptually), requires invasive guest
changes, will cripple Remus/COLO


2) Deep p2m dirty tracking

In the case that a p2m frame is discovered dirty in the logdirty bitmap,
we can be certain that a write has occurred to it, and in the common
case, means that the mapping has changed.  The toolstack could maintain
a non-live copy of the p2m which is updated as new frames are sent. 
When a dirty p2m frame is found, the live and non-live copies can be
consulted to find which pfn mappings have changed, and locally mark all
the altered pfns for retransmit.

Pros) No guest changes required
Cons) Toolstack needs to keep an additional copy of the guests p2m on
the sending side

3) Eagerly check for p2m structure changes.

p2m structure changes are rare after boot, but not impossible.  Each
iteration of live migration, the toolstack can check for dirty
higher-level p2m frames in the dirty bitmap.  In the case that a
structure update occurs, the toolstack can use information it already
has to calculate a subset of pfns affected by the update, and mark them
for resending.  (This can currently be done to the frame granularity
given the p2m frame lit, but in combination with 2), could result in
fewer pfns needing resending.)

Pros) No guest changes required.
Cons) Moderately high toolstack overhead,  Possibility to resend far
more pfns than strictly required.

4) Request p2m structure change updates from the guest

The guest could provide a "p2m generation count" to allow the toolstack
to evaluate whether the structure had changed.  This would allow the
live part of migration to periodically re-evaluate whether it should
remap the p2m to avoid stale mappings.

Pros) Easy to implement alongside the virtual linear mapping support. 
Easy for toolstack and guest
Cons) Only works with new virtual linear guests.


Proposed solution:  A combination of 2, 3 and 4.

For legacy 3-level p2m guests, the toolstack can detect p2m structure
updates by tracking the p2m top and mid levels in the logdirty bitmap,
and invalidating the modified subset of pfns.  It has to eagerly check
the p2m frame list list mfn entry in the shared info to see whether the
guest has swapped onto a completely new p2m.

For a virtual linear map, the intermediate levels are not available to
track, but we can require that the guest increment p2m generation clock
in the shared info.  When the structure changes, the toolstack can remap
the p2m and calculate the altered subset of pfns, and mark for resend.

The toolstack must also track changes in the p2m itself, and compare to
a local copy showing the mapping at the time at which the pfn was last
sent.  This can be used to work out which p2m mappings have changed, and
also be used to confirm whether the pfns on the receiving side are stale
or not.

I believe this covered all cases and race conditions.  In the case that
the p2m is updated before the m2p, the p2m frame will be marked dirty in
the bitmap, and discoverable on the next iteration.  At that point, if
the p2m and m2p are inconsistent, the pfn will be deferred until the
final iteration.  If not, the frame is sent and everything is all ok. 
In the case that the p2m is updated after the m2p, the p2m/m2p will be
consistent when the dirty bitmap is acted on.


Thoughts? (for anyone who has made it this far :)  I think I have
covered everything.)

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 18:28:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 18:28:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrWSs-0006DB-6f; Thu, 20 Nov 2014 18:28:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrWSq-0006D6-SL
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 18:28:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3B/27-09936-4C23E645; Thu, 20 Nov 2014 18:28:20 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416508096!14269493!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28970 invoked from network); 20 Nov 2014 18:28:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 18:28:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="scan'208";a="194920267"
Message-ID: <546E32BB.8090909@citrix.com>
Date: Thu, 20 Nov 2014 18:28:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: [Xen-devel] Buggy interaction of live migration and p2m 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

Hello,

Tim, David and I were discussing this over lunch.  This email is a
(hopefully accurate) account of our findings, and potential solutions. 
(If I have messed up, please shout.)

Currently, correct live migration of PV domains relies on the toolstack
(which has a live mapping of the guests p2m) not observing stale values
when the guest updates its p2m, and the race condition between a p2m
update and an m2p update.  Realistically, this means no updates to the
p2m at all, due to several potential race conditions.  Should any race
conditions happen (e.g. ballooning while live migrating), the effects
could be anything from an aborted migration to VM memory corruption.

It should be noted that migrationv2 does not fix any of this.  It alters
the way in which some race conditions might be observed.  During
development of migrationv2, there was an explicit non-requirement of
fixing the existing Ballooning+LiveMigration issues we were aware,
although at the time, we were not aware of this specific set of issues. 
Our goal was to simply make migrationv2 work in the same circumstances
as previously, but with a bitness-agnostic wire format and
forward-extensible protocol.


As far as these issues are concerned, there are two distinct p2m
modifications which we care about:
1) p2m structure changes (rearranging the layout of the p2m)
2) p2m content changes (altering entries in the p2m)

There is no possible way for the toolstack to prevent a domain from
altering its p2m.  At the moment, ballooning typically only occurs when
requested by the toolstack, but the underlying operations
(increase/decrease_reservation, mem_exchange, etc) can be used by the
guest at any point.  This includes Wei's guest memory fragmentation
changes.  Changes to the content of the p2m also occur for grant map and
unmap operations.


Currently in PV guests, the p2m is implemented using a 3-level tree,
with its root in the guests shared_info page.  It provides a hard VM
memory limit of 4TB for 32bit PV guests (which is far higher than the
128GB limit from the compat p2m mappings), or 512GB for 64bit PV guests.

Juergen has a proposed new p2m interface using a virtual linear
mapping.  This is conceptually similar to the previous implementation
(which is fine from the toolstacks point of view), but far less
complicated from the guests point of view, and removes the memory limits
imposed by the p2m structure.

The new virtual linear mapping suffers from the same interaction issues
as the old 3-level tree did, but the introduction of the new interface
affords us an opportunity to make all API modifications at once to
reduce churn.


During live migration, the toolstack maps the guests p2m into a linear
mapping in the toolstacks virtual address space.  This is done once at
the start of migration, and never subsequently altered.  During live
migration, the p2m is cross-verified with the m2p, and frames are sent
using pfns as a reference, as they will be located in different frames
on the receiving side.

Should the guest change the p2m structure during live migration, the
toolstack ends up with a stale p2m with a non-p2m frame in the middle,
resulting in bogus cross-referencing.  Should the guest change an entry
in the p2m, the p2m frame itself will be resent as it would be marked as
dirty in the logdirty bitmap, but the target pfn will remain unsent and
probably stale on the receiving side.


Another factor which needs to be taken into account is Remus/COLO, which
run the domains under live migration conditions for the duration of
their lifetime.

During the live part of migration, the toolstack already has to be able
to tolerate failures to normalise the pagetables, which result as a
consequent of the pagetables being in active.  These failures are fatal
on the final iteration after the guest has been paused, but the same
logic could be extended to p2m/m2p issues, if needed.


There are several potential solutions to these problems.

1) Freeze the guests p2m during live migrate

This is the simplest sounding option, but is quite problematic from the
point of view of the guest.  It is essentially a shared spinlock between
the toolstack and the guest kernel.  It would prevent any grant
map/unmap operations from occurring, and might interact badly with
certain p2m updated in the guest which would previously be expected to
unconditionally succeed.

Pros) (Can't think of any)
Cons) Not easy to implement (even conceptually), requires invasive guest
changes, will cripple Remus/COLO


2) Deep p2m dirty tracking

In the case that a p2m frame is discovered dirty in the logdirty bitmap,
we can be certain that a write has occurred to it, and in the common
case, means that the mapping has changed.  The toolstack could maintain
a non-live copy of the p2m which is updated as new frames are sent. 
When a dirty p2m frame is found, the live and non-live copies can be
consulted to find which pfn mappings have changed, and locally mark all
the altered pfns for retransmit.

Pros) No guest changes required
Cons) Toolstack needs to keep an additional copy of the guests p2m on
the sending side

3) Eagerly check for p2m structure changes.

p2m structure changes are rare after boot, but not impossible.  Each
iteration of live migration, the toolstack can check for dirty
higher-level p2m frames in the dirty bitmap.  In the case that a
structure update occurs, the toolstack can use information it already
has to calculate a subset of pfns affected by the update, and mark them
for resending.  (This can currently be done to the frame granularity
given the p2m frame lit, but in combination with 2), could result in
fewer pfns needing resending.)

Pros) No guest changes required.
Cons) Moderately high toolstack overhead,  Possibility to resend far
more pfns than strictly required.

4) Request p2m structure change updates from the guest

The guest could provide a "p2m generation count" to allow the toolstack
to evaluate whether the structure had changed.  This would allow the
live part of migration to periodically re-evaluate whether it should
remap the p2m to avoid stale mappings.

Pros) Easy to implement alongside the virtual linear mapping support. 
Easy for toolstack and guest
Cons) Only works with new virtual linear guests.


Proposed solution:  A combination of 2, 3 and 4.

For legacy 3-level p2m guests, the toolstack can detect p2m structure
updates by tracking the p2m top and mid levels in the logdirty bitmap,
and invalidating the modified subset of pfns.  It has to eagerly check
the p2m frame list list mfn entry in the shared info to see whether the
guest has swapped onto a completely new p2m.

For a virtual linear map, the intermediate levels are not available to
track, but we can require that the guest increment p2m generation clock
in the shared info.  When the structure changes, the toolstack can remap
the p2m and calculate the altered subset of pfns, and mark for resend.

The toolstack must also track changes in the p2m itself, and compare to
a local copy showing the mapping at the time at which the pfn was last
sent.  This can be used to work out which p2m mappings have changed, and
also be used to confirm whether the pfns on the receiving side are stale
or not.

I believe this covered all cases and race conditions.  In the case that
the p2m is updated before the m2p, the p2m frame will be marked dirty in
the bitmap, and discoverable on the next iteration.  At that point, if
the p2m and m2p are inconsistent, the pfn will be deferred until the
final iteration.  If not, the frame is sent and everything is all ok. 
In the case that the p2m is updated after the m2p, the p2m/m2p will be
consistent when the dirty bitmap is acted on.


Thoughts? (for anyone who has made it this far :)  I think I have
covered everything.)

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 19:45:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 19:45:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrXet-0007c8-NM; Thu, 20 Nov 2014 19:44:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrXes-0007c3-Ec
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 19:44:50 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	EB/00-22777-1B44E645; Thu, 20 Nov 2014 19:44:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416512687!7131167!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14174 invoked from network); 20 Nov 2014 19:44:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 19:44:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKJiZUw024420
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 19:44:37 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKJiXAi023230
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 19:44:34 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKJiXBF023218; Thu, 20 Nov 2014 19:44:33 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 11:44:33 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1BDBE118615; Thu, 20 Nov 2014 14:44:32 -0500 (EST)
Date: Thu, 20 Nov 2014 14:44:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141120194431.GB25423@laptop.dumpdata.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
	<20141119210845.GF20440@laptop.dumpdata.com>
	<20141119212434.GB27349@zion.uk.xensource.com>
	<1416497391.14429.23.camel@citrix.com>
	<20141120154817.GA31452@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141120154817.GA31452@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org, Zhigang Wang <zhigang.x.wang@oracle.com>,
	ian.jackson@eu.citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:48:17PM +0000, Wei Liu wrote:
> On Thu, Nov 20, 2014 at 03:29:51PM +0000, Ian Campbell wrote:
> > On Wed, 2014-11-19 at 21:24 +0000, Wei Liu wrote:
> > > On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > > > > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > > > > And it will cause the xenstore 'memory/targe' calculation wrong:
> > > > > 
> > > > >     memory/target = info->target_memkb - info->video_memkb
> > > > 
> > > > CC-ing the maintainers.
> > > > 
> > > > Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?
> > > > 
> > > 
> > > I don't think this is a regression, it has been broken for quite a
> > > while.
> > 
> > I think so to.
> > 
> > On the other hand its a pretty clear bug to use video_memkb == -1 and
> > we've seen that it causes real issues. The fix is also fairly obvious.
> > I'm inclined towards suggesting we fix this in 4.5.
> > 
> 
> I concur.

Lets do it then. RElease-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Wei.
> 
> > Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 19:45:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 19:45:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrXet-0007c8-NM; Thu, 20 Nov 2014 19:44:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrXes-0007c3-Ec
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 19:44:50 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	EB/00-22777-1B44E645; Thu, 20 Nov 2014 19:44:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416512687!7131167!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14174 invoked from network); 20 Nov 2014 19:44:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2014 19:44:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKJiZUw024420
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 19:44:37 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKJiXAi023230
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 19:44:34 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKJiXBF023218; Thu, 20 Nov 2014 19:44:33 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 11:44:33 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1BDBE118615; Thu, 20 Nov 2014 14:44:32 -0500 (EST)
Date: Thu, 20 Nov 2014 14:44:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141120194431.GB25423@laptop.dumpdata.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
	<20141119210845.GF20440@laptop.dumpdata.com>
	<20141119212434.GB27349@zion.uk.xensource.com>
	<1416497391.14429.23.camel@citrix.com>
	<20141120154817.GA31452@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141120154817.GA31452@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org, Zhigang Wang <zhigang.x.wang@oracle.com>,
	ian.jackson@eu.citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:48:17PM +0000, Wei Liu wrote:
> On Thu, Nov 20, 2014 at 03:29:51PM +0000, Ian Campbell wrote:
> > On Wed, 2014-11-19 at 21:24 +0000, Wei Liu wrote:
> > > On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > > > > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > > > > And it will cause the xenstore 'memory/targe' calculation wrong:
> > > > > 
> > > > >     memory/target = info->target_memkb - info->video_memkb
> > > > 
> > > > CC-ing the maintainers.
> > > > 
> > > > Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?
> > > > 
> > > 
> > > I don't think this is a regression, it has been broken for quite a
> > > while.
> > 
> > I think so to.
> > 
> > On the other hand its a pretty clear bug to use video_memkb == -1 and
> > we've seen that it causes real issues. The fix is also fairly obvious.
> > I'm inclined towards suggesting we fix this in 4.5.
> > 
> 
> I concur.

Lets do it then. RElease-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Wei.
> 
> > Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 19:45:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 19: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.xen.org>)
	id 1XrXfV-0007ds-4s; Thu, 20 Nov 2014 19:45:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrXfU-0007dk-4J
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 19:45:28 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	55/9D-09936-7D44E645; Thu, 20 Nov 2014 19:45:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416512725!14216287!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25140 invoked from network); 20 Nov 2014 19:45:26 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 19:45:26 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKJjHuE001777
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 19:45:18 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAKJjG5i015195
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Nov 2014 19:45:16 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAKJjFsA015156; Thu, 20 Nov 2014 19:45:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 11:45:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0DCA411861C; Thu, 20 Nov 2014 14:45:14 -0500 (EST)
Date: Thu, 20 Nov 2014 14:45:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141120194513.GC25423@laptop.dumpdata.com>
References: <1416410868.29243.39.camel@citrix.com>
	<20141119212721.GK20440@laptop.dumpdata.com>
	<1416499117.14429.37.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416499117.14429.37.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/5 v2 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:58:37PM +0000, Ian Campbell wrote:
> On Wed, 2014-11-19 at 16:27 -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 19, 2014 at 03:27:48PM +0000, Ian Campbell wrote:
> > > These patches:
> > > 
> > >       * fix up an off by one bug in the xgene mapping of additional PCI
> > >         bus resources, which would cause an additional extra page to be
> > >         mapped
> > >       * correct the size of the mapped regions to match the docs
> > >       * adds support for the other 4 PCI buses on the chip, which
> > >         enables mcdivitt and presumably most other Xgene based platforms
> > >         which uses PCI buses other than pcie0.
> > >       * adds earlyprintk for the mcdivitt platform
> > > 
> > > They can also be found at:
> > >         git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v2
> > 
> > #1-#4 can go in - aka Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Applied, with a tweak to one of the ocmmit message suggested by Julien.
> 
> > For #5 I would appreciate an ARM knowledgeble person to review it.
> 
> Acked by Julien now, are you ok for it to go in?
> 

Yes. Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 19:45:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 19: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.xen.org>)
	id 1XrXfV-0007ds-4s; Thu, 20 Nov 2014 19:45:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrXfU-0007dk-4J
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 19:45:28 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	55/9D-09936-7D44E645; Thu, 20 Nov 2014 19:45:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416512725!14216287!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25140 invoked from network); 20 Nov 2014 19:45:26 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 19:45:26 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKJjHuE001777
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 19:45:18 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAKJjG5i015195
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Nov 2014 19:45:16 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAKJjFsA015156; Thu, 20 Nov 2014 19:45:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 11:45:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0DCA411861C; Thu, 20 Nov 2014 14:45:14 -0500 (EST)
Date: Thu, 20 Nov 2014 14:45:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141120194513.GC25423@laptop.dumpdata.com>
References: <1416410868.29243.39.camel@citrix.com>
	<20141119212721.GK20440@laptop.dumpdata.com>
	<1416499117.14429.37.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416499117.14429.37.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Clark Laughlin <clark.laughlin@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Subject: Re: [Xen-devel] [PATCH 0/5 v2 for-4.5] xen: arm: xgene bug fixes +
 support for McDivitt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:58:37PM +0000, Ian Campbell wrote:
> On Wed, 2014-11-19 at 16:27 -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 19, 2014 at 03:27:48PM +0000, Ian Campbell wrote:
> > > These patches:
> > > 
> > >       * fix up an off by one bug in the xgene mapping of additional PCI
> > >         bus resources, which would cause an additional extra page to be
> > >         mapped
> > >       * correct the size of the mapped regions to match the docs
> > >       * adds support for the other 4 PCI buses on the chip, which
> > >         enables mcdivitt and presumably most other Xgene based platforms
> > >         which uses PCI buses other than pcie0.
> > >       * adds earlyprintk for the mcdivitt platform
> > > 
> > > They can also be found at:
> > >         git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v2
> > 
> > #1-#4 can go in - aka Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Applied, with a tweak to one of the ocmmit message suggested by Julien.
> 
> > For #5 I would appreciate an ARM knowledgeble person to review it.
> 
> Acked by Julien now, are you ok for it to go in?
> 

Yes. Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 19:47:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 19:47:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrXh1-0007ln-Kg; Thu, 20 Nov 2014 19:47:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrXgy-0007le-Sm
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 19:47:01 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E7/3E-09842-4354E645; Thu, 20 Nov 2014 19:47:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416512818!14282669!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17510 invoked from network); 20 Nov 2014 19:46:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 19:46:59 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKJkp4O003419
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 19:46:52 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAKJkoEt020186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Nov 2014 19:46:51 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAKJkn3B020153; Thu, 20 Nov 2014 19:46:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 11:46:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A372C118620; Thu, 20 Nov 2014 14:46:47 -0500 (EST)
Date: Thu, 20 Nov 2014 14:46:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141120194647.GD25423@laptop.dumpdata.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
	<1415963574.7113.7.camel@citrix.com>
	<5469EBE5.4070209@eu.citrix.com>
	<1416498424.14429.30.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416498424.14429.30.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:47:04PM +0000, Ian Campbell wrote:
> On Mon, 2014-11-17 at 12:36 +0000, George Dunlap wrote:
> > On 11/14/2014 11:12 AM, Ian Campbell wrote:
> > > On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
> > >> Return proper error codes on failure so that scripts can tell whether
> > >> the command completed properly or not.
> > >>
> > >> Also while we're at it, normalize init and dispose of
> > >> libxl_device_disk structures.  This means calling init and dispose in
> > >> the actual functions where they are declared.
> > >>
> > >> This in turn means changing parse_disk_config_multistring() to not
> > >> call libxl_device_disk_init.  And that in turn means changes to
> > >> callers of parse_disk_config().
> > >>
> > >> It also means removing libxl_device_disk_init() from
> > >> libxl.c:libxl_vdev_to_device_disk().  This is only called from
> > >> xl_cmdimpl.c.
> > >>
> > >> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> > >> ---
> > >> CC: Ian Campbell <ian.campbell@citrix.com>
> > >> CC: Ian Jackson <ian.jackson@citrix.com>
> > >> CC: Wei Liu <wei.liu2@citrix.com>
> > >> CC: Konrad Wilk <konrad.wilk@oracle.com>
> > >>
> > >> Release justification: This is a bug fix.  It's a fairly minor one,
> > >> but it's also a very simple one.
> > >>
> > >> v2:
> > >>   - Restructure functions to make sure init and dispose are properly
> > >>   called.
> > > Sadly this bit has somewhat reduced the truth of the second half of your
> > > release justification, since the patch is a fair bit more subtle though.
> > > Although IMHO it hasn't invalidated the case for taking the patch for
> > > 4.5 (modulo comments below).
> > 
> > Well, I think we can take the hacky short-term fix I posted before, 
> > which is simple, and do a proper fix after the 4.6 dev window opens up; 
> > or we can do a more complete fix now.
> 
> Specifically the "hacky short-term fix" is
> <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com> ?
> 
> I could live with that, perhaps with the commit log explaining that a
> little.
> 
> Konrad?

<hands George the band-aid tape>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > 
> > Or, if the valgrind thing is really important, I could use the change 
> > you suggested, and do "return rc ? 1 : 0;" but I really think that's 
> > going in the wrong direction...
> > 
> >   -George
> > 
> > >
> > >> ---
> > >>   tools/libxl/libxl.c      |  2 --
> > >>   tools/libxl/xl_cmdimpl.c | 28 +++++++++++++++++++++-------
> > >>   2 files changed, 21 insertions(+), 9 deletions(-)
> > >>
> > >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > >> index f7961f6..d9c4ce7 100644
> > >> --- a/tools/libxl/libxl.c
> > >> +++ b/tools/libxl/libxl.c
> > >> @@ -2611,8 +2611,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid,
> > >>       if (devid < 0)
> > >>           return ERROR_INVAL;
> > >>   
> > >> -    libxl_device_disk_init(disk);
> > > _init functions are idempotent, so this is harmless, I think. Existing
> > > callers (including things which aren't xl) might be relying on it.
> > > Outside of a freeze period that might be acceptable (those callers are
> > > buggy) but since you are asking for a freeze exception I think this may
> > > be going a step too far in cleaning things up.
> > >
> > > In terms of other callers you've missed
> > > tools/ocaml/libs/xl/xenlight_stubs.c (which appears buggy to me) in
> > > tree, plus whatever use e.g. libvirt makes of it.
> > >
> > >> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > >> index 3c9f146..25af715 100644
> > >> --- a/tools/libxl/xl_cmdimpl.c
> > >> +++ b/tools/libxl/xl_cmdimpl.c
> > >> @@ -485,8 +485,6 @@ static void parse_disk_config_multistring(XLU_Config **config,
> > >>   {
> > >>       int e;
> > >>   
> > >> -    libxl_device_disk_init(disk);
> > > Likewise here, although to a lesser extent since this is xl not libxl.
> > >>   
> > >> @@ -6378,13 +6382,17 @@ int main_blockattach(int argc, char **argv)
> > >>           printf("disk: %s\n", json);
> > >>           free(json);
> > >>           if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
> > >> -        return 0;
> > > You should set rc = 0 here rather than initing it at declaration to
> > > catch error paths which don't set the result. (we aren't very consistent
> > > about this in the code today so I'm only mentioning it because other
> > > changes seem to be needed, if that turns out not to be the case and
> > > there's no need for v3 then this shouldn't block acceptance)
> > >
> > >> +        goto out;
> > > I'm not 100% convinced by the use of the goto out error handling style
> > > for a success path, but it's probably better than duplicating the exit
> > > path or adding !dryrun checks to all the following operations. Ian,
> > > since you recently posted updated coding style for things around this,
> > > what do you think?
> > >
> > > Ian.
> > >
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 19:47:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 19:47:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrXh1-0007ln-Kg; Thu, 20 Nov 2014 19:47:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrXgy-0007le-Sm
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 19:47:01 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E7/3E-09842-4354E645; Thu, 20 Nov 2014 19:47:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416512818!14282669!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17510 invoked from network); 20 Nov 2014 19:46:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 19:46:59 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKJkp4O003419
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 19:46:52 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAKJkoEt020186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Nov 2014 19:46:51 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAKJkn3B020153; Thu, 20 Nov 2014 19:46:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 11:46:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A372C118620; Thu, 20 Nov 2014 14:46:47 -0500 (EST)
Date: Thu, 20 Nov 2014 14:46:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141120194647.GD25423@laptop.dumpdata.com>
References: <1415905446-32168-1-git-send-email-george.dunlap@eu.citrix.com>
	<1415963574.7113.7.camel@citrix.com>
	<5469EBE5.4070209@eu.citrix.com>
	<1416498424.14429.30.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416498424.14429.30.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] xl: Return proper error codes
 for block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:47:04PM +0000, Ian Campbell wrote:
> On Mon, 2014-11-17 at 12:36 +0000, George Dunlap wrote:
> > On 11/14/2014 11:12 AM, Ian Campbell wrote:
> > > On Thu, 2014-11-13 at 19:04 +0000, George Dunlap wrote:
> > >> Return proper error codes on failure so that scripts can tell whether
> > >> the command completed properly or not.
> > >>
> > >> Also while we're at it, normalize init and dispose of
> > >> libxl_device_disk structures.  This means calling init and dispose in
> > >> the actual functions where they are declared.
> > >>
> > >> This in turn means changing parse_disk_config_multistring() to not
> > >> call libxl_device_disk_init.  And that in turn means changes to
> > >> callers of parse_disk_config().
> > >>
> > >> It also means removing libxl_device_disk_init() from
> > >> libxl.c:libxl_vdev_to_device_disk().  This is only called from
> > >> xl_cmdimpl.c.
> > >>
> > >> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> > >> ---
> > >> CC: Ian Campbell <ian.campbell@citrix.com>
> > >> CC: Ian Jackson <ian.jackson@citrix.com>
> > >> CC: Wei Liu <wei.liu2@citrix.com>
> > >> CC: Konrad Wilk <konrad.wilk@oracle.com>
> > >>
> > >> Release justification: This is a bug fix.  It's a fairly minor one,
> > >> but it's also a very simple one.
> > >>
> > >> v2:
> > >>   - Restructure functions to make sure init and dispose are properly
> > >>   called.
> > > Sadly this bit has somewhat reduced the truth of the second half of your
> > > release justification, since the patch is a fair bit more subtle though.
> > > Although IMHO it hasn't invalidated the case for taking the patch for
> > > 4.5 (modulo comments below).
> > 
> > Well, I think we can take the hacky short-term fix I posted before, 
> > which is simple, and do a proper fix after the 4.6 dev window opens up; 
> > or we can do a more complete fix now.
> 
> Specifically the "hacky short-term fix" is
> <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com> ?
> 
> I could live with that, perhaps with the commit log explaining that a
> little.
> 
> Konrad?

<hands George the band-aid tape>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > 
> > Or, if the valgrind thing is really important, I could use the change 
> > you suggested, and do "return rc ? 1 : 0;" but I really think that's 
> > going in the wrong direction...
> > 
> >   -George
> > 
> > >
> > >> ---
> > >>   tools/libxl/libxl.c      |  2 --
> > >>   tools/libxl/xl_cmdimpl.c | 28 +++++++++++++++++++++-------
> > >>   2 files changed, 21 insertions(+), 9 deletions(-)
> > >>
> > >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > >> index f7961f6..d9c4ce7 100644
> > >> --- a/tools/libxl/libxl.c
> > >> +++ b/tools/libxl/libxl.c
> > >> @@ -2611,8 +2611,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid,
> > >>       if (devid < 0)
> > >>           return ERROR_INVAL;
> > >>   
> > >> -    libxl_device_disk_init(disk);
> > > _init functions are idempotent, so this is harmless, I think. Existing
> > > callers (including things which aren't xl) might be relying on it.
> > > Outside of a freeze period that might be acceptable (those callers are
> > > buggy) but since you are asking for a freeze exception I think this may
> > > be going a step too far in cleaning things up.
> > >
> > > In terms of other callers you've missed
> > > tools/ocaml/libs/xl/xenlight_stubs.c (which appears buggy to me) in
> > > tree, plus whatever use e.g. libvirt makes of it.
> > >
> > >> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > >> index 3c9f146..25af715 100644
> > >> --- a/tools/libxl/xl_cmdimpl.c
> > >> +++ b/tools/libxl/xl_cmdimpl.c
> > >> @@ -485,8 +485,6 @@ static void parse_disk_config_multistring(XLU_Config **config,
> > >>   {
> > >>       int e;
> > >>   
> > >> -    libxl_device_disk_init(disk);
> > > Likewise here, although to a lesser extent since this is xl not libxl.
> > >>   
> > >> @@ -6378,13 +6382,17 @@ int main_blockattach(int argc, char **argv)
> > >>           printf("disk: %s\n", json);
> > >>           free(json);
> > >>           if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
> > >> -        return 0;
> > > You should set rc = 0 here rather than initing it at declaration to
> > > catch error paths which don't set the result. (we aren't very consistent
> > > about this in the code today so I'm only mentioning it because other
> > > changes seem to be needed, if that turns out not to be the case and
> > > there's no need for v3 then this shouldn't block acceptance)
> > >
> > >> +        goto out;
> > > I'm not 100% convinced by the use of the goto out error handling style
> > > for a success path, but it's probably better than duplicating the exit
> > > path or adding !dryrun checks to all the following operations. Ian,
> > > since you recently posted updated coding style for things around this,
> > > what do you think?
> > >
> > > Ian.
> > >
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 19:51:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 19:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrXlc-0007zh-BW; Thu, 20 Nov 2014 19:51:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrXla-0007zC-Eh
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 19:51:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DA/F0-09842-1564E645; Thu, 20 Nov 2014 19:51:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416513103!14185069!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22445 invoked from network); 20 Nov 2014 19:51:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 19:51:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKJpawX032399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 19:51:37 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKJpZp3029644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 19:51:36 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKJpZAh029643; Thu, 20 Nov 2014 19:51:35 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 11:51:34 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E50F6118627; Thu, 20 Nov 2014 14:51:33 -0500 (EST)
Date: Thu, 20 Nov 2014 14:51:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141120195133.GE25423@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546DD6BF0200007800049471@smtp.nue.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 11:55:43AM +0100, Jan Beulich wrote:
> >>> On 19.11.14 at 23:21, <konrad.wilk@oracle.com> wrote:
> 
> Leaving aside the question of whether this is the right approach, in
> case it is a couple of comments:
> 
> > @@ -85,7 +91,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
> >   */
> >  bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
> >  {
> > -    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
> > +    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
> 
> This is becoming unwieldy - perhaps better just "if ( pirq_dpci->state )"?
> 
> > @@ -122,6 +128,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
> >          /* fallthrough. */
> >      case (1 << STATE_RUN):
> >      case (1 << STATE_RUN) | (1 << STATE_SCHED):
> > +    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
> 
> How would we get into this state? Afaict STATE_ZOMBIE can't be set
> at the same time as STATE_SCHED.
> 
> > @@ -786,6 +793,7 @@ unlock:
> >  static void dpci_softirq(void)
> >  {
> >      unsigned int cpu = smp_processor_id();
> > +    unsigned int reset = 0;
> 
> bool_t (and would better be inside the loop, avoiding the pointless
> re-init on the last iteration).
> 
> But taking it as a whole - aren't we now at risk of losing an interrupt
> instance the guest expects, due to raise_softirq_for() bailing on
> zombie entries, and dpci_softirq() being the only place where the
> zombie state gets cleared?

Ah crud.

So a simple fix could be to seperate the 'state' to only deal with the
raise_softirq and softirq_dpci. And then add a new (old) 'masked' to
deal between hvm_dirq_assist, pt_irq_guest_eoi and hvm_do_IRQ_dpci.


>From 94a98e20a8ab721a58788919f92e3524a6c6e25c Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 14:28:11 -0500
Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

commit f6dd295381f4b6a66acddacf46bca8940586c8d8
"dpci: replace tasklet with softirq" used the 'masked' as an
two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
between 'raise_softirq_for' and 'dpci_softirq' to determine whether
the 'struct hvm_pirq_dpci' can be re-scheduled.

However it ignored the 'pt_irq_guest_eoi' was not adhering to the proper
dialogue and was not using locked cmpxchg or test_bit operations and
ended setting 'state' set to zero. That meant 'raise_softirq_for' was
free to schedule it while the 'struct hvm_pirq_dpci'' was still on an
per-cpu list causing an list corruption.

The code would trigger the following path causing list corruption:

    \-timer_softirq_action
    	pt_irq_time_out calls pt_pirq_softirq_cancel sets state to 0.
            pirq_dpci is still on dpci_list.
    \- dpci_sofitrq
    	while (!list_emptry(&our_list))
    		list_del, but has not yet done 'entry->next = LIST_POISON1;'
    [interrupt happens]
    	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
    [interrupt is done, back to dpci_softirq]
    	finishes the entry->next = LIST_POISON1;
    		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
    	ends the loop, exits.

    \- dpci_softirq
    	while (!list_emtpry)
    		list_del, but ->next already has LIST_POISON1 and we blow up.

An alternative solution was proposed (adding STATE_ZOMBIE and making
pt_irq_time_out use the cmpxchg protocol on 'state'), which fixed the above
issue but had an fatal bug. It would miss interrupts that are to be scheduled!

This patch brings back the 'masked' boolean which is used as an
communication channel between 'hvm_do_IRQ_dpci', 'hvm_dirq_assist' and
'pt_irq_guest_eoi'. When we have an interrupt we set 'masked'. Anytime
'hvm_dirq_assist' or 'pt_irq_guest_eoi' executes - it clears it.

The 'state' is left as a seperate mechanism to provide an mechanism between
'raise_sofitrq' and 'softirq_dpci' to communicate the state of the
'struct hvm_dirq_pirq'.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 5 +++--
 xen/include/xen/hvm/irq.h    | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..4d8c02f 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -142,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pirq_dpci->masked = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -610,6 +610,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
+    pirq_dpci->masked = 1;
     raise_softirq_for(pirq_dpci);
     return 1;
 }
@@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( pirq_dpci->state )
+    if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..3996f1f 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -94,6 +94,7 @@ struct hvm_irq_dpci {
 struct hvm_pirq_dpci {
     uint32_t flags;
     unsigned int state;
+    bool_t masked;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
-- 
1.9.3

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 19:51:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 19:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrXlc-0007zh-BW; Thu, 20 Nov 2014 19:51:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrXla-0007zC-Eh
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 19:51:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DA/F0-09842-1564E645; Thu, 20 Nov 2014 19:51:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416513103!14185069!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22445 invoked from network); 20 Nov 2014 19:51:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 19:51:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKJpawX032399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 19:51:37 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKJpZp3029644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 19:51:36 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKJpZAh029643; Thu, 20 Nov 2014 19:51:35 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 11:51:34 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E50F6118627; Thu, 20 Nov 2014 14:51:33 -0500 (EST)
Date: Thu, 20 Nov 2014 14:51:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141120195133.GE25423@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546DD6BF0200007800049471@smtp.nue.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 11:55:43AM +0100, Jan Beulich wrote:
> >>> On 19.11.14 at 23:21, <konrad.wilk@oracle.com> wrote:
> 
> Leaving aside the question of whether this is the right approach, in
> case it is a couple of comments:
> 
> > @@ -85,7 +91,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci *pirq_dpci)
> >   */
> >  bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
> >  {
> > -    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED)) )
> > +    if ( pirq_dpci->state & ((1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE) ) )
> 
> This is becoming unwieldy - perhaps better just "if ( pirq_dpci->state )"?
> 
> > @@ -122,6 +128,7 @@ static void pt_pirq_softirq_cancel(struct hvm_pirq_dpci *pirq_dpci,
> >          /* fallthrough. */
> >      case (1 << STATE_RUN):
> >      case (1 << STATE_RUN) | (1 << STATE_SCHED):
> > +    case (1 << STATE_RUN) | (1 << STATE_SCHED) | (1 << STATE_ZOMBIE):
> 
> How would we get into this state? Afaict STATE_ZOMBIE can't be set
> at the same time as STATE_SCHED.
> 
> > @@ -786,6 +793,7 @@ unlock:
> >  static void dpci_softirq(void)
> >  {
> >      unsigned int cpu = smp_processor_id();
> > +    unsigned int reset = 0;
> 
> bool_t (and would better be inside the loop, avoiding the pointless
> re-init on the last iteration).
> 
> But taking it as a whole - aren't we now at risk of losing an interrupt
> instance the guest expects, due to raise_softirq_for() bailing on
> zombie entries, and dpci_softirq() being the only place where the
> zombie state gets cleared?

Ah crud.

So a simple fix could be to seperate the 'state' to only deal with the
raise_softirq and softirq_dpci. And then add a new (old) 'masked' to
deal between hvm_dirq_assist, pt_irq_guest_eoi and hvm_do_IRQ_dpci.


>From 94a98e20a8ab721a58788919f92e3524a6c6e25c Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 14:28:11 -0500
Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

commit f6dd295381f4b6a66acddacf46bca8940586c8d8
"dpci: replace tasklet with softirq" used the 'masked' as an
two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
between 'raise_softirq_for' and 'dpci_softirq' to determine whether
the 'struct hvm_pirq_dpci' can be re-scheduled.

However it ignored the 'pt_irq_guest_eoi' was not adhering to the proper
dialogue and was not using locked cmpxchg or test_bit operations and
ended setting 'state' set to zero. That meant 'raise_softirq_for' was
free to schedule it while the 'struct hvm_pirq_dpci'' was still on an
per-cpu list causing an list corruption.

The code would trigger the following path causing list corruption:

    \-timer_softirq_action
    	pt_irq_time_out calls pt_pirq_softirq_cancel sets state to 0.
            pirq_dpci is still on dpci_list.
    \- dpci_sofitrq
    	while (!list_emptry(&our_list))
    		list_del, but has not yet done 'entry->next = LIST_POISON1;'
    [interrupt happens]
    	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
    [interrupt is done, back to dpci_softirq]
    	finishes the entry->next = LIST_POISON1;
    		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
    	ends the loop, exits.

    \- dpci_softirq
    	while (!list_emtpry)
    		list_del, but ->next already has LIST_POISON1 and we blow up.

An alternative solution was proposed (adding STATE_ZOMBIE and making
pt_irq_time_out use the cmpxchg protocol on 'state'), which fixed the above
issue but had an fatal bug. It would miss interrupts that are to be scheduled!

This patch brings back the 'masked' boolean which is used as an
communication channel between 'hvm_do_IRQ_dpci', 'hvm_dirq_assist' and
'pt_irq_guest_eoi'. When we have an interrupt we set 'masked'. Anytime
'hvm_dirq_assist' or 'pt_irq_guest_eoi' executes - it clears it.

The 'state' is left as a seperate mechanism to provide an mechanism between
'raise_sofitrq' and 'softirq_dpci' to communicate the state of the
'struct hvm_dirq_pirq'.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/drivers/passthrough/io.c | 5 +++--
 xen/include/xen/hvm/irq.h    | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..4d8c02f 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -142,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pirq_dpci->masked = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -610,6 +610,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
+    pirq_dpci->masked = 1;
     raise_softirq_for(pirq_dpci);
     return 1;
 }
@@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( pirq_dpci->state )
+    if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..3996f1f 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -94,6 +94,7 @@ struct hvm_irq_dpci {
 struct hvm_pirq_dpci {
     uint32_t flags;
     unsigned int state;
+    bool_t masked;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
-- 
1.9.3

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:08:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrY1G-0008Rh-Jz; Thu, 20 Nov 2014 20:07:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XrY1E-0008Rc-Ec
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 20:07:57 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	38/4C-31453-81A4E645; Thu, 20 Nov 2014 20:07:52 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416514068!12528882!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17904 invoked from network); 20 Nov 2014 20:07:49 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:07:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416514067; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=cIv53z6h68aQMwAEU5QhhVUWU3xGyxCMOg/YMQpcZN4=;
	b=wpyYqgN1uE+IkYKZLxSYSOMGvcTDISZV05g8OSgdQak8/EIekliCs07h4vdCxFnAPva5lNUGxMjpht2sbKWqo533GiiLlsQQP1mfp1YyzanHEHzBlROHdpTdNaMoIDtDwHcKXwMyaG9AWGi1TUuVSiRNDD8wz2WvDmEHx+yFB0A=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Thu, 20 Nov 2014 12:07:46 -0800
	id 0000000000030498.546E4A13.00002972
Message-ID: <546E4A17.5040902@ihonk.com>
Date: Thu, 20 Nov 2014 12:07:51 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
In-Reply-To: <546DAD6502000078000492FD@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

Thanks for all your help so far! Here's my latest update.

On 11/17/2014 23:54, Jan Beulich wrote:
> Plus, without said adjustment, first just disable the
> MWAIT CPU idle driver ("mwait-idle=0") and then, if that didn't make
> a difference, use of C states altogether ("cpuidle=0"). If any of this
> does make a difference, limiting use of C states without fully
> excluding their use may need to be the next step.

Running with mwait-idle=0 solves (hides?) the problem. Next step is to 
fiddle with the C states?

On 11/19/2014 23:59, Jan Beulich wrote:
> Also, for double checking purposes, could you make the xen-syms of a 
> build you observed the problem with available somewhere? 

The xen-syms (from my build of 9a727a81) can be found here: 
http://steve.freitas.org/xen-syms-4.5-unstable.gz

> Interesting - all CPUs are executing stuff from Dom1, which be itself 
> is not indicating a problem, but may (considering the host hang) hint 
> at guest vCPU-s not getting de-scheduled anymore on one or more of the 
> CPUs. The 'a' debug key output would hopefully give us enough 
> information to know whether that's the case. Ideally do 'd' and 'a' a 
> couple of times each (alternating, and with a few seconds in between). 

Here ya go (as before, from 9a727a81). I had to pick and choose what 
parts to pull from the log because it was getting spammed with kernel 
complaints about the disk subsystem being locked up, so the hypervisor 
debugging info was hard to read amidst the kernel errors. As ever, let 
me know if you need more.

Thanks again!

Steve

(XEN) CPU00:
(XEN)   ex=        1445us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=        9918us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=        8390us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=    70409499us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=    12265483us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=       94364us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=       18390us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN) CPU01:
(XEN)   ex=         390us timer=ffff830c17ceb460 
cb=pt_timer_fn(ffff830c17ceb420)
(XEN)   ex=    14101194us timer=ffff830c17ceb4e0 
cb=pt_timer_fn(ffff830c17ceb4a0)
(XEN)   ex=      153445us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex= 44171681527us timer=ffff830c17ceb290 
cb=rtc_alarm_cb(ffff830c17ceb1f0)
(XEN) CPU02:
(XEN)   ex=        1445us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=        8390us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       18390us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=       29570us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=       25445us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN) CPU04:
(XEN)   ex=         634us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN) CPU05:
(XEN)   ex=        1445us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=   388096702us timer=ffff830c17ceb5d0 
cb=pmt_timer_callback(ffff830c17ceb5a8)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  000003295cdc3c57   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 000003940027203c   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000001cb8300
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000002f7d38
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff800028232c1>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 0000039c01e4b276   rbx: 0000039c01e4ddc3   rcx: 000000000000ffff
(XEN) rdx: 0000039c00000000   rsi: 0000000000000000   rdi: 0000000000000038
(XEN) rbp: 00000000000024b3   rsp: fffff880048d04c0   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 00000003428f7600
(XEN) r12: fffff880048d08f8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000148f940
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  00000353a8bde5bd   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000039400271946   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef88138c8
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000003071d1e7b55   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 00000394002e01ea   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000043fd28
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a9784000   rcx: 0000000000000005
(XEN) rdx: ffff830c3dc80000   rsi: 0000000000000003   rdi: ffff830c3dc8e088
(XEN) rbp: ffff830c3dc87ec8   rsp: ffff830c3dc87e40   r8: ffff830c3dc8e0a0
(XEN) r9:  000001de682f4faa   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: 000001de682108bd   r13: ffff8300a9784000   r14: ffff830c3dc8e088
(XEN) r15: 00000000000f4240   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c185e7000   cr2: 000000000031f268
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc87e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dc8e0a0 0000000500c87e78
(XEN)    ffff830c3dc8e080 ffff82d0801b5277 ffff8300a9784000 fffff88002f36d70
(XEN)    ffff8300a9784000 00000000000f4240 ffff82d0801e0f00 ffff830c3dc87f08
(XEN)    ffff82d0802f8280 ffff82d0802f8000 ffffffffffffffff ffff830c3dc80000
(XEN)    0000000000000001 ffff830c3dc87ef8 ffff82d08012a1b3 ffff8300a9784000
(XEN)    fffff88002f36d70 000003940051e450 000000000000000f ffff830c3dc87f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 000003940051e450 fffff88002f36d70 000000000000000f
(XEN)    fffff88002f2c180 fffff88002f36d70 fffff88002f2c2a0 0000034bbd959ead
(XEN)    fffff88002f2c2a0 0000000000000002 fffff88002f2c1c0 0000000000000400
(XEN)    0000000000000000 fffff88002f36eb0 0000beef0000beef fffff8000298a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002f36c20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000005 ffff8300a9784000 0000003bbd96ce00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000003940051e450   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000031f268
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=         282us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=       17360us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=        1690us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=     2536293us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=    44362799us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=      957308us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=       11690us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN) CPU01:
(XEN)   ex=         659us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=       54745us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=        1025us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=      150745us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=      128408us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex=       26745us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=       11690us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN) CPU02:
(XEN)   ex=        1943us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       11690us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=       30041us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=        1937us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=       11690us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex= 44145634827us timer=ffff830c17ceb290 
cb=rtc_alarm_cb(ffff830c17ceb1f0)
(XEN)   ex=       30048us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=        1827us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=       11690us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=      806745us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=       30058us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=        1928us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=       11690us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=   362050002us timer=ffff830c17ceb5d0 
cb=pmt_timer_callback(ffff830c17ceb5a8)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000003940051e450   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000031f268
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  00000353a8bde5bd   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000039400271946   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef88138c8
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  000003295cdc3c57   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 000003940027203c   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000001cb8300
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d08012a132>] __do_softirq+0/0x8c
(XEN) RFLAGS: 0000000000000202   CONTEXT: hypervisor
(XEN) rax: 0000000000000246   rbx: ffff8300a9786000   rcx: 0000000000000000
(XEN) rdx: ffff82d0802f8000   rsi: ffff8300a9786000   rdi: 0000000000000000
(XEN) rbp: ffff830c3dca7f08   rsp: ffff830c3dca7f00   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c17ec0000   cr2: 00000000002f7d38
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7f00:
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 00000394002722bb fffff88002e4ad70 000000000000000f
(XEN)    fffff88002e40180 fffff88002e4ad70 fffff88002e402a0 00000256dc1c8f33
(XEN)    fffff88002e402a0 0000000000000002 fffff88002e401c0 0000000000000400
(XEN)    0000000000000000 fffff88002e4aeb0 0000beef0000beef fffff8000298a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002e4ac20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000003 ffff8300a9786000 0000003bbd988e00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a132>] __do_softirq+0/0x8c
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000002f7d38
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff800028232c3>]
(XEN) RFLAGS: 0000000000000006   CONTEXT: hvm guest
(XEN) rax: 00000000336e527f   rbx: 000003a26d8bfe95   rcx: 000000000000ffff
(XEN) rdx: 00000000000003a1   rsi: 0000000000000000   rdi: 0000000002c0c9a9
(XEN) rbp: 0000000000000000   rsp: fffff880048d0490   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 0027cb813b6e0000
(XEN) r12: fffff880048d08f8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000148f940
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000003071d1e7b55   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 00000394002e01ea   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000043fd28
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=         119us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex=       11733us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN)   ex=        1733us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=       28524us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=       77612us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=    35482842us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=     9656339us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex= 44136754870us timer=ffff830c17ceb290 
cb=rtc_alarm_cb(ffff830c17ceb1f0)
(XEN) CPU01:
(XEN)   ex=        2406us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=       11733us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=       74788us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=      270788us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=       30027us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=        1952us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       78788us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=       11733us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=     1066788us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=      118766us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=       30038us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=        1926us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=       11733us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN) CPU04:
(XEN)   ex=        1963us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=       11733us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=       30059us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=        1978us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=       11733us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=   353170045us timer=ffff830c17ceb5d0 
cb=pmt_timer_callback(ffff830c17ceb5a8)
(XEN)   ex=       30065us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000298a217>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000003071d1e7b55   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 00000394002e01ea   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000043fd28
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000002f7d38
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff800028232c3>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 0000000010984f60   rbx: 000003a710988443   rcx: 000000000000ffff
(XEN) rdx: 00000000000003a7   rsi: 0000000000000000   rdi: 0000000000000007
(XEN) rbp: 000000000000af00   rsp: fffff880048d04c0   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 00000003428f7600
(XEN) r12: fffff880048d08f8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000148f940
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d08011cc9d>] ASSERT_NOT_IN_ATOMIC+0x37/0x52
(XEN) RFLAGS: 0000000000000202   CONTEXT: hypervisor
(XEN) rax: 0000000000000180   rbx: ffff8300a9784000   rcx: 0000000000000001
(XEN) rdx: 0000003bbd988e00   rsi: ffff830c3dcaad20   rdi: 000000005c723445
(XEN) rbp: ffff830c3dca7e38   rsp: ffff830c3dca7e38   r8: 000001e23194cc09
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: 000001e25298787d   r13: ffff830c3dcaa130   r14: ffff830c3dca0000
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c185e7000   cr2: 000000000031f268
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7e38:
(XEN)    ffff830c3dca7ec8 ffff82d080126d91 ffff830c3dca7e58 ffff82d0801c89a3
(XEN)    000000033dca7e78 ffff830c3dca7e88 ffff82d0801b5277 ffff8300a9784000
(XEN)    fffff88002f36d70 000003940051e450 ffff830c3dca7f08 ffff82d0801e0f69
(XEN)    ffff830c3dca7f08 ffff82d0802f8180 ffff82d0802f8000 ffffffffffffffff
(XEN)    ffff830c3dca0000 0000000000000001 ffff830c3dca7ef8 ffff82d08012a1b3
(XEN)    ffff8300a9784000 fffff88002f36d70 000003940051e450 000000000000000f
(XEN)    ffff830c3dca7f08 ffff82d08012a20b 000000000000000f ffff82d0801e3d2a
(XEN)    0000000000000001 000000000000000f 000003940051e450 fffff88002f36d70
(XEN)    000000000000000f fffff88002f2c180 fffff88002f36d70 fffff88002f2c2a0
(XEN)    0000034bbd959ead fffff88002f2c2a0 0000000000000002 fffff88002f2c1c0
(XEN)    0000000000000400 0000000000000000 fffff88002f36eb0 0000beef0000beef
(XEN)    fffff8000298a20c 000000bf0000beef 0000000000000046 fffff88002f36c20
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    000000000000beef 0000000000000003 ffff8300a9784000 0000003bbd988e00
(XEN)    0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08011cc9d>] ASSERT_NOT_IN_ATOMIC+0x37/0x52
(XEN)    [<ffff82d080126d91>] schedule+0x47/0x612
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000003940051e450   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000031f268
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82d0801a8461>] mwait_idle+0x2ab/0x2ff
(XEN) RFLAGS: 0000000000000202   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: 000001e262c8819c   rcx: 20c49ba5e353f7cf
(XEN) rdx: ffff830c3dc90000   rsi: 000001e262c8819c   rdi: ffff830c3dcacba8
(XEN) rbp: ffff830c3dc97ef0   rsp: ffff830c3dc97e80   r8: 000001e23194cc09
(XEN) r9:  0000000000000000   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: ffff830c3dcacb80   r13: 0000000000000003   r14: 0000000000000004
(XEN) r15: ffff830c3dcacc10   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c18947000   cr2: 0000000001cb8300
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc97e80:
(XEN)    00000010bf79b000 000001e25ccbd093 ffff82d0801e0f00 ffff830c3dc97f08
(XEN)    ffff82d0802f8200 0000000000000000 0000000000000000 000002e800000115
(XEN)    0000000000000001 ffff830c3dc90000 ffff8300a978f000 00000000ffffff01
(XEN)    ffff830c3dc9c088 0000000000000003 ffff830c3dc97f10 ffff82d08015ee06
(XEN)    ffff82d08012a20b ffff8300bf79b000 ffff830c3dc97de8 0000000000000001
(XEN)    000000000000000f 000003940027203c fffff88002facd70 000000000000000f
(XEN)    fffff88002fa2180 fffff88002facd70 fffff88002fa22a0 000003295cdc3c57
(XEN)    fffff88002fa22a0 0000000000000002 fffff88002fa21c0 0000000000000400
(XEN)    0000000000000000 fffff88002faceb0 0000beef0000beef fffff8000298a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002facc20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000004 ffff8300bf79b000 0000003bbd97ae00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801a8461>] mwait_idle+0x2ab/0x2ff
(XEN)    [<ffff82d08015ee06>] idle_loop+0x51/0x6b
(XEN)
(XEN) *** Dumping CPU5 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82d0801a8461>] mwait_idle+0x2ab/0x2ff
(XEN) RFLAGS: 0000000000000202   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: 000001e26cdd6ba0   rcx: 20c49ba5e353f7cf
(XEN) rdx: ffff830c3dc80000   rsi: 000001e26cdd6ba0   rdi: ffff830c3dc8d448
(XEN) rbp: ffff830c3dc87ef0   rsp: ffff830c3dc87e80   r8: 000001e23194cc09
(XEN) r9:  ffff830c17ceb5d0   r10: 0000000000000000   r11: 000000000000000a
(XEN) r12: ffff830c3dc8d420   r13: 0000000000000004   r14: 0000000000000008
(XEN) r15: ffff830c3dc8d4d0   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 00000000bf48b000   cr2: 000007fef88138c8
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc87e80:
(XEN)    00000020bf79a000 000001e263681669 ffff82d0802f8000 ffffffffffffffff
(XEN)    ffff830c3dc80000 0000000000000000 0000000000000000 00001f3e0000130a
(XEN)    ffff830c3dc80000 ffff830c3dc80000 000001e263680d45 ffff8300bf79a000
(XEN)    ffff830c3dc8e088 ffffffffffffffff ffff830c3dc87f10 ffff82d08015ee06
(XEN)    ffff82d08012a20b ffff8300bf79a000 ffff830c3dc87e10 0000000000000001
(XEN)    000000000000000f 00000394002722bb fffff88002e4ad70 000000000000000f
(XEN)    fffff88002e40180 fffff88002e4ad70 fffff88002e402a0 00000256dc1c8f33
(XEN)    fffff88002e402a0 0000000000000002 fffff88002e401c0 0000000000000400
(XEN)    0000000000000000 fffff88002e4aeb0 0000beef0000beef fffff8000298a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002e4ac20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000005 ffff8300bf79a000 0000003bbd96ce00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801a8461>] mwait_idle+0x2ab/0x2ff
(XEN)    [<ffff82d08015ee06>] idle_loop+0x51/0x6b
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=         597us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=         597us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN)   ex=    15145207us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=       10541us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=      155653us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=    24971706us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex= 44126243734us timer=ffff830c17ceb290 
cb=rtc_alarm_cb(ffff830c17ceb1f0)
(XEN)   ex=      730445us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=      107653us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN) CPU01:
(XEN)   ex=         597us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=        1023us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=      259653us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=       30029us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=         597us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=        1074us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       30039us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=         597us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex=         947us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=      563653us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=       30047us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=         597us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=         996us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=       30055us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=         155us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=         981us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=         597us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=   342658909us timer=ffff830c17ceb5d0 
cb=pmt_timer_callback(ffff830c17ceb5a8)
(XEN)   ex=       91653us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=        1062us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000003940051e450   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000031f268
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  000003295cdc3c57   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 000003940027203c   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000001cb8300
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  00000353a8bde5bd   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000039400271946   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef88138c8
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000003071d1e7b55   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 00000394002e01ea   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000043fd28
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82d0801dc4fe>] vmx_vmexit_handler+0x311/0x195e
(XEN) RFLAGS: 0000000000000297   CONTEXT: hypervisor
(XEN) rax: 0000000000187000   rbx: ffff830c3dc97f18   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: ffff830c3dc97f18
(XEN) rbp: ffff830c3dc97f08   rsp: ffff830c3dc97d98   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: ffff8300a9786000   r13: 0000000000000028   r14: 0000000000000000
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c17ec0000   cr2: 00000000002f7d38
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc97d98:
(XEN)    ffff8300a9786000 ffff8300a9786000 ffff8300a9786000 ffff830c3dc9c088
(XEN)    ffff830c3dc97e08 0000000000000000 ffff830c3dc97de8 ffff830c3dc90000
(XEN)    ffff830c3dc9c0a0 ffff8300a9786000 000001e512e27b8b ffff8300a9786000
(XEN)    ffff830c3dc9c088 0000000001c9c380 0000000000000292 ffff830c3dc97e28
(XEN)    ffff82d08012a80f ffff8300a9786000 ffff830c3dc97e98 ffff82d0801caea5
(XEN)    ffff830c3dc97ec8 ffff8300a9786508 ffff82d080321280 ffff830c3dc9c0a0
(XEN)    ffff830c3dc97e78 ffff830c3dc97e88 ffff82d0801b5277 ffff8300a9786000
(XEN)    000001e512e27b8b ffff8300a9786000 ffff830c3dc97f08 ffff82d0801e0f69
(XEN)    ffff830c3dc97f18 ffff8300a9786000 ffff830c3dc97f08 ffff82d0801ddba6
(XEN)    ffff830c3dc90000 0000000000000001 ffff830c3dc97ef8 ffff82d08012a1b3
(XEN)    ffff8300a9786000 ffff8300a9786000 fffff88002e4ad70 00000394002722bb
(XEN)    000000000000000f 0000000000000001 000000000000000f ffff82d0801e3c81
(XEN)    0000000000000001 000000000000000f 00000394002722bb fffff88002e4ad70
(XEN)    000000000000000f fffff88002e40180 fffff88002e4ad70 fffff88002e402a0
(XEN)    00000256dc1c8f33 fffff88002e402a0 0000000000000002 fffff88002e401c0
(XEN)    0000000000000400 0000000000000000 fffff88002e4aeb0 0000beef0000beef
(XEN)    fffff8000298a20c 000000bf0000beef 0000000000000046 fffff88002e4ac20
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    000000000000beef 0000000000000004 ffff8300a9786000 0000003bbd97ae00
(XEN)    0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801dc4fe>] vmx_vmexit_handler+0x311/0x195e
(XEN)    [<ffff82d0801e3c81>] vmx_asm_vmexit_handler+0x41/0xc0
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000002f7d38
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82d08012a825>] _spin_lock+0x27/0x54
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: ffff830c17ceb628   rcx: 0000000000000000
(XEN) rdx: 0000000000000000   rsi: 0000000000000008   rdi: ffff830c17ceb62c
(XEN) rbp: ffff830c3dc87df8   rsp: ffff830c3dc87df0   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 00000003428f7600
(XEN) r12: 0000000000000008   r13: 0000000000000008   r14: ffff830c17ceb628
(XEN) r15: ffff8300a9787000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c180ec000   cr2: 000000000148f940
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc87df0:
(XEN)    ffff830c17ceb000 ffff830c3dc87e28 ffff82d0801c08e6 0000000000000008
(XEN)    0000000000000008 0000000000000001 ffff8300a9787000 ffff830c3dc87e98
(XEN)    ffff82d0801caef7 ffff830c3dc87ec8 ffff8300a9787508 000000023dc87e58
(XEN)    ffff830c17ceb4a0 00000143f866c070 ffff8300a9787510 ffff82d0801b5277
(XEN)    ffff8300a9787000 fffff880048d08f8 0000000000001000 0000000000000000
(XEN)    0000000000000058 ffff830c3dc87f08 ffff82d0801d4c75 ffff830c3dc87f08
(XEN)    ffffffff801ddba6 ffff830c3dc80000 0000000000000058 ffff830c3dc87ef8
(XEN)    ffff82d08012a1b3 ffff8300a9787000 ffff8300a9787000 fffff880048d08f8
(XEN)    0000000000001000 0000000000000000 0000000000000058 000000000000897d
(XEN)    ffff82d0801e3c86 0000000000000058 0000000000000000 0000000000001000
(XEN)    fffff880048d08f8 000000000000897d 000003af014f24a8 00000003428f7600
(XEN)    fffff880048d0570 0000000000000000 fffff880048d0520 000003af014efe7d
(XEN)    000000000000ffff 000003af00000000 0000000000000000 0000000000000052
(XEN)    0000beef0000beef fffff800028232bf 000000bf0000beef 0000000000000002
(XEN)    fffff880048d04c0 000000000000beef 000000000000beef 000000000000beef
(XEN)    000000000000beef 000000000000beef 0000000000000005 ffff8300a9787000
(XEN)    0000003bbd96ce00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a825>] _spin_lock+0x27/0x54
(XEN)    [<ffff82d0801c08e6>] hvm_isa_irq_deassert+0x34/0x77
(XEN)    [<ffff82d0801caef7>] pt_update_irq+0x1b8/0x230
(XEN)    [<ffff82d0801d4c75>] vmx_intr_assist+0x5d/0x51c
(XEN)    [<ffff82d0801e3c86>] vmx_asm_vmexit_handler+0x46/0xc0
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff800028232bf>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 000003af014efe7d   rbx: 000003af014f24a8   rcx: 000000000000ffff
(XEN) rdx: 000003af00000000   rsi: 0000000000000000   rdi: 0000000000000052
(XEN) rbp: 000000000000897d   rsp: fffff880048d04c0   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 00000003428f7600
(XEN) r12: fffff880048d08f8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000148f940
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        1796us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=        6341us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=       16341us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN)   ex=     4520950us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=      891686us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=    14347450us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN) CPU01:
(XEN)   ex=        6500us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=       16341us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=      939396us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=       67396us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=       30022us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=        6493us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       16341us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=      135396us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=       30035us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=         753us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex=        1042us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex= 44115619478us timer=ffff830c17ceb290 
cb=rtc_alarm_cb(ffff830c17ceb1f0)
(XEN)   ex=       16341us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex=        6535us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN) CPU04:
(XEN)   ex=        4039us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=        6506us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=       16341us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=       30055us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=        6536us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=       16341us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=      755722us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=   332034653us timer=ffff830c17ceb5d0 
cb=pmt_timer_callback(ffff830c17ceb5a8)
(XEN)   ex=       30066us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  00000353a8bde5bd   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000039400271946   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef88138c8
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff800028232c1>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 000003b6a07ae098   rbx: 000003b6a07b06ed   rcx: 000000000000ffff
(XEN) rdx: 000003b600000000   rsi: 0000000000000000   rdi: 0000000000000051
(XEN) rbp: 0000000000006ed0   rsp: fffff880048d04c0   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 00000003428f7600
(XEN) r12: fffff880048d08f8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000148f940
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000003940051e450   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000031f268
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  000003295cdc3c57   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 000003940027203c   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000001cb8300
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000002f7d38
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000003071d1e7b55   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 00000394002e01ea   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000043fd28
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) 'R' pressed -> rebooting machine
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:08:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrY1G-0008Rh-Jz; Thu, 20 Nov 2014 20:07:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XrY1E-0008Rc-Ec
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 20:07:57 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	38/4C-31453-81A4E645; Thu, 20 Nov 2014 20:07:52 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416514068!12528882!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17904 invoked from network); 20 Nov 2014 20:07:49 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:07:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416514067; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=cIv53z6h68aQMwAEU5QhhVUWU3xGyxCMOg/YMQpcZN4=;
	b=wpyYqgN1uE+IkYKZLxSYSOMGvcTDISZV05g8OSgdQak8/EIekliCs07h4vdCxFnAPva5lNUGxMjpht2sbKWqo533GiiLlsQQP1mfp1YyzanHEHzBlROHdpTdNaMoIDtDwHcKXwMyaG9AWGi1TUuVSiRNDD8wz2WvDmEHx+yFB0A=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Thu, 20 Nov 2014 12:07:46 -0800
	id 0000000000030498.546E4A13.00002972
Message-ID: <546E4A17.5040902@ihonk.com>
Date: Thu, 20 Nov 2014 12:07:51 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
In-Reply-To: <546DAD6502000078000492FD@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

Thanks for all your help so far! Here's my latest update.

On 11/17/2014 23:54, Jan Beulich wrote:
> Plus, without said adjustment, first just disable the
> MWAIT CPU idle driver ("mwait-idle=0") and then, if that didn't make
> a difference, use of C states altogether ("cpuidle=0"). If any of this
> does make a difference, limiting use of C states without fully
> excluding their use may need to be the next step.

Running with mwait-idle=0 solves (hides?) the problem. Next step is to 
fiddle with the C states?

On 11/19/2014 23:59, Jan Beulich wrote:
> Also, for double checking purposes, could you make the xen-syms of a 
> build you observed the problem with available somewhere? 

The xen-syms (from my build of 9a727a81) can be found here: 
http://steve.freitas.org/xen-syms-4.5-unstable.gz

> Interesting - all CPUs are executing stuff from Dom1, which be itself 
> is not indicating a problem, but may (considering the host hang) hint 
> at guest vCPU-s not getting de-scheduled anymore on one or more of the 
> CPUs. The 'a' debug key output would hopefully give us enough 
> information to know whether that's the case. Ideally do 'd' and 'a' a 
> couple of times each (alternating, and with a few seconds in between). 

Here ya go (as before, from 9a727a81). I had to pick and choose what 
parts to pull from the log because it was getting spammed with kernel 
complaints about the disk subsystem being locked up, so the hypervisor 
debugging info was hard to read amidst the kernel errors. As ever, let 
me know if you need more.

Thanks again!

Steve

(XEN) CPU00:
(XEN)   ex=        1445us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=        9918us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=        8390us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=    70409499us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=    12265483us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=       94364us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=       18390us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN) CPU01:
(XEN)   ex=         390us timer=ffff830c17ceb460 
cb=pt_timer_fn(ffff830c17ceb420)
(XEN)   ex=    14101194us timer=ffff830c17ceb4e0 
cb=pt_timer_fn(ffff830c17ceb4a0)
(XEN)   ex=      153445us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex= 44171681527us timer=ffff830c17ceb290 
cb=rtc_alarm_cb(ffff830c17ceb1f0)
(XEN) CPU02:
(XEN)   ex=        1445us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=        8390us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       18390us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=       29570us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=       25445us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN) CPU04:
(XEN)   ex=         634us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN) CPU05:
(XEN)   ex=        1445us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=   388096702us timer=ffff830c17ceb5d0 
cb=pmt_timer_callback(ffff830c17ceb5a8)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  000003295cdc3c57   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 000003940027203c   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000001cb8300
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000002f7d38
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff800028232c1>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 0000039c01e4b276   rbx: 0000039c01e4ddc3   rcx: 000000000000ffff
(XEN) rdx: 0000039c00000000   rsi: 0000000000000000   rdi: 0000000000000038
(XEN) rbp: 00000000000024b3   rsp: fffff880048d04c0   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 00000003428f7600
(XEN) r12: fffff880048d08f8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000148f940
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  00000353a8bde5bd   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000039400271946   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef88138c8
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000003071d1e7b55   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 00000394002e01ea   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000043fd28
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a9784000   rcx: 0000000000000005
(XEN) rdx: ffff830c3dc80000   rsi: 0000000000000003   rdi: ffff830c3dc8e088
(XEN) rbp: ffff830c3dc87ec8   rsp: ffff830c3dc87e40   r8: ffff830c3dc8e0a0
(XEN) r9:  000001de682f4faa   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: 000001de682108bd   r13: ffff8300a9784000   r14: ffff830c3dc8e088
(XEN) r15: 00000000000f4240   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c185e7000   cr2: 000000000031f268
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc87e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dc8e0a0 0000000500c87e78
(XEN)    ffff830c3dc8e080 ffff82d0801b5277 ffff8300a9784000 fffff88002f36d70
(XEN)    ffff8300a9784000 00000000000f4240 ffff82d0801e0f00 ffff830c3dc87f08
(XEN)    ffff82d0802f8280 ffff82d0802f8000 ffffffffffffffff ffff830c3dc80000
(XEN)    0000000000000001 ffff830c3dc87ef8 ffff82d08012a1b3 ffff8300a9784000
(XEN)    fffff88002f36d70 000003940051e450 000000000000000f ffff830c3dc87f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 000003940051e450 fffff88002f36d70 000000000000000f
(XEN)    fffff88002f2c180 fffff88002f36d70 fffff88002f2c2a0 0000034bbd959ead
(XEN)    fffff88002f2c2a0 0000000000000002 fffff88002f2c1c0 0000000000000400
(XEN)    0000000000000000 fffff88002f36eb0 0000beef0000beef fffff8000298a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002f36c20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000005 ffff8300a9784000 0000003bbd96ce00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000003940051e450   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000031f268
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=         282us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=       17360us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=        1690us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=     2536293us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=    44362799us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=      957308us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=       11690us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN) CPU01:
(XEN)   ex=         659us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=       54745us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=        1025us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=      150745us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=      128408us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex=       26745us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=       11690us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN) CPU02:
(XEN)   ex=        1943us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       11690us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=       30041us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=        1937us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=       11690us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex= 44145634827us timer=ffff830c17ceb290 
cb=rtc_alarm_cb(ffff830c17ceb1f0)
(XEN)   ex=       30048us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=        1827us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=       11690us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=      806745us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=       30058us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=        1928us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=       11690us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=   362050002us timer=ffff830c17ceb5d0 
cb=pmt_timer_callback(ffff830c17ceb5a8)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000003940051e450   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000031f268
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  00000353a8bde5bd   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000039400271946   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef88138c8
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  000003295cdc3c57   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 000003940027203c   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000001cb8300
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d08012a132>] __do_softirq+0/0x8c
(XEN) RFLAGS: 0000000000000202   CONTEXT: hypervisor
(XEN) rax: 0000000000000246   rbx: ffff8300a9786000   rcx: 0000000000000000
(XEN) rdx: ffff82d0802f8000   rsi: ffff8300a9786000   rdi: 0000000000000000
(XEN) rbp: ffff830c3dca7f08   rsp: ffff830c3dca7f00   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c17ec0000   cr2: 00000000002f7d38
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7f00:
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 00000394002722bb fffff88002e4ad70 000000000000000f
(XEN)    fffff88002e40180 fffff88002e4ad70 fffff88002e402a0 00000256dc1c8f33
(XEN)    fffff88002e402a0 0000000000000002 fffff88002e401c0 0000000000000400
(XEN)    0000000000000000 fffff88002e4aeb0 0000beef0000beef fffff8000298a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002e4ac20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000003 ffff8300a9786000 0000003bbd988e00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a132>] __do_softirq+0/0x8c
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000002f7d38
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff800028232c3>]
(XEN) RFLAGS: 0000000000000006   CONTEXT: hvm guest
(XEN) rax: 00000000336e527f   rbx: 000003a26d8bfe95   rcx: 000000000000ffff
(XEN) rdx: 00000000000003a1   rsi: 0000000000000000   rdi: 0000000002c0c9a9
(XEN) rbp: 0000000000000000   rsp: fffff880048d0490   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 0027cb813b6e0000
(XEN) r12: fffff880048d08f8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000148f940
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000003071d1e7b55   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 00000394002e01ea   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000043fd28
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=         119us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex=       11733us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN)   ex=        1733us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=       28524us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=       77612us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=    35482842us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=     9656339us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex= 44136754870us timer=ffff830c17ceb290 
cb=rtc_alarm_cb(ffff830c17ceb1f0)
(XEN) CPU01:
(XEN)   ex=        2406us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=       11733us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=       74788us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=      270788us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=       30027us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=        1952us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       78788us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=       11733us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=     1066788us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=      118766us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=       30038us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=        1926us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=       11733us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN) CPU04:
(XEN)   ex=        1963us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=       11733us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=       30059us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=        1978us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=       11733us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=   353170045us timer=ffff830c17ceb5d0 
cb=pmt_timer_callback(ffff830c17ceb5a8)
(XEN)   ex=       30065us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000298a217>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000003071d1e7b55   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 00000394002e01ea   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000043fd28
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000002f7d38
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff800028232c3>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 0000000010984f60   rbx: 000003a710988443   rcx: 000000000000ffff
(XEN) rdx: 00000000000003a7   rsi: 0000000000000000   rdi: 0000000000000007
(XEN) rbp: 000000000000af00   rsp: fffff880048d04c0   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 00000003428f7600
(XEN) r12: fffff880048d08f8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000148f940
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d08011cc9d>] ASSERT_NOT_IN_ATOMIC+0x37/0x52
(XEN) RFLAGS: 0000000000000202   CONTEXT: hypervisor
(XEN) rax: 0000000000000180   rbx: ffff8300a9784000   rcx: 0000000000000001
(XEN) rdx: 0000003bbd988e00   rsi: ffff830c3dcaad20   rdi: 000000005c723445
(XEN) rbp: ffff830c3dca7e38   rsp: ffff830c3dca7e38   r8: 000001e23194cc09
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: 000001e25298787d   r13: ffff830c3dcaa130   r14: ffff830c3dca0000
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c185e7000   cr2: 000000000031f268
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7e38:
(XEN)    ffff830c3dca7ec8 ffff82d080126d91 ffff830c3dca7e58 ffff82d0801c89a3
(XEN)    000000033dca7e78 ffff830c3dca7e88 ffff82d0801b5277 ffff8300a9784000
(XEN)    fffff88002f36d70 000003940051e450 ffff830c3dca7f08 ffff82d0801e0f69
(XEN)    ffff830c3dca7f08 ffff82d0802f8180 ffff82d0802f8000 ffffffffffffffff
(XEN)    ffff830c3dca0000 0000000000000001 ffff830c3dca7ef8 ffff82d08012a1b3
(XEN)    ffff8300a9784000 fffff88002f36d70 000003940051e450 000000000000000f
(XEN)    ffff830c3dca7f08 ffff82d08012a20b 000000000000000f ffff82d0801e3d2a
(XEN)    0000000000000001 000000000000000f 000003940051e450 fffff88002f36d70
(XEN)    000000000000000f fffff88002f2c180 fffff88002f36d70 fffff88002f2c2a0
(XEN)    0000034bbd959ead fffff88002f2c2a0 0000000000000002 fffff88002f2c1c0
(XEN)    0000000000000400 0000000000000000 fffff88002f36eb0 0000beef0000beef
(XEN)    fffff8000298a20c 000000bf0000beef 0000000000000046 fffff88002f36c20
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    000000000000beef 0000000000000003 ffff8300a9784000 0000003bbd988e00
(XEN)    0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08011cc9d>] ASSERT_NOT_IN_ATOMIC+0x37/0x52
(XEN)    [<ffff82d080126d91>] schedule+0x47/0x612
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000003940051e450   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000031f268
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82d0801a8461>] mwait_idle+0x2ab/0x2ff
(XEN) RFLAGS: 0000000000000202   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: 000001e262c8819c   rcx: 20c49ba5e353f7cf
(XEN) rdx: ffff830c3dc90000   rsi: 000001e262c8819c   rdi: ffff830c3dcacba8
(XEN) rbp: ffff830c3dc97ef0   rsp: ffff830c3dc97e80   r8: 000001e23194cc09
(XEN) r9:  0000000000000000   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: ffff830c3dcacb80   r13: 0000000000000003   r14: 0000000000000004
(XEN) r15: ffff830c3dcacc10   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c18947000   cr2: 0000000001cb8300
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc97e80:
(XEN)    00000010bf79b000 000001e25ccbd093 ffff82d0801e0f00 ffff830c3dc97f08
(XEN)    ffff82d0802f8200 0000000000000000 0000000000000000 000002e800000115
(XEN)    0000000000000001 ffff830c3dc90000 ffff8300a978f000 00000000ffffff01
(XEN)    ffff830c3dc9c088 0000000000000003 ffff830c3dc97f10 ffff82d08015ee06
(XEN)    ffff82d08012a20b ffff8300bf79b000 ffff830c3dc97de8 0000000000000001
(XEN)    000000000000000f 000003940027203c fffff88002facd70 000000000000000f
(XEN)    fffff88002fa2180 fffff88002facd70 fffff88002fa22a0 000003295cdc3c57
(XEN)    fffff88002fa22a0 0000000000000002 fffff88002fa21c0 0000000000000400
(XEN)    0000000000000000 fffff88002faceb0 0000beef0000beef fffff8000298a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002facc20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000004 ffff8300bf79b000 0000003bbd97ae00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801a8461>] mwait_idle+0x2ab/0x2ff
(XEN)    [<ffff82d08015ee06>] idle_loop+0x51/0x6b
(XEN)
(XEN) *** Dumping CPU5 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82d0801a8461>] mwait_idle+0x2ab/0x2ff
(XEN) RFLAGS: 0000000000000202   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: 000001e26cdd6ba0   rcx: 20c49ba5e353f7cf
(XEN) rdx: ffff830c3dc80000   rsi: 000001e26cdd6ba0   rdi: ffff830c3dc8d448
(XEN) rbp: ffff830c3dc87ef0   rsp: ffff830c3dc87e80   r8: 000001e23194cc09
(XEN) r9:  ffff830c17ceb5d0   r10: 0000000000000000   r11: 000000000000000a
(XEN) r12: ffff830c3dc8d420   r13: 0000000000000004   r14: 0000000000000008
(XEN) r15: ffff830c3dc8d4d0   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 00000000bf48b000   cr2: 000007fef88138c8
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc87e80:
(XEN)    00000020bf79a000 000001e263681669 ffff82d0802f8000 ffffffffffffffff
(XEN)    ffff830c3dc80000 0000000000000000 0000000000000000 00001f3e0000130a
(XEN)    ffff830c3dc80000 ffff830c3dc80000 000001e263680d45 ffff8300bf79a000
(XEN)    ffff830c3dc8e088 ffffffffffffffff ffff830c3dc87f10 ffff82d08015ee06
(XEN)    ffff82d08012a20b ffff8300bf79a000 ffff830c3dc87e10 0000000000000001
(XEN)    000000000000000f 00000394002722bb fffff88002e4ad70 000000000000000f
(XEN)    fffff88002e40180 fffff88002e4ad70 fffff88002e402a0 00000256dc1c8f33
(XEN)    fffff88002e402a0 0000000000000002 fffff88002e401c0 0000000000000400
(XEN)    0000000000000000 fffff88002e4aeb0 0000beef0000beef fffff8000298a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002e4ac20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000005 ffff8300bf79a000 0000003bbd96ce00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801a8461>] mwait_idle+0x2ab/0x2ff
(XEN)    [<ffff82d08015ee06>] idle_loop+0x51/0x6b
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=         597us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=         597us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN)   ex=    15145207us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=       10541us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=      155653us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=    24971706us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex= 44126243734us timer=ffff830c17ceb290 
cb=rtc_alarm_cb(ffff830c17ceb1f0)
(XEN)   ex=      730445us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=      107653us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN) CPU01:
(XEN)   ex=         597us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=        1023us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=      259653us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=       30029us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=         597us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=        1074us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       30039us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=         597us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex=         947us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=      563653us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=       30047us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=         597us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=         996us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=       30055us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=         155us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=         981us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=         597us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=   342658909us timer=ffff830c17ceb5d0 
cb=pmt_timer_callback(ffff830c17ceb5a8)
(XEN)   ex=       91653us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=        1062us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000003940051e450   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000031f268
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  000003295cdc3c57   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 000003940027203c   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000001cb8300
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  00000353a8bde5bd   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000039400271946   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef88138c8
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000003071d1e7b55   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 00000394002e01ea   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000043fd28
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82d0801dc4fe>] vmx_vmexit_handler+0x311/0x195e
(XEN) RFLAGS: 0000000000000297   CONTEXT: hypervisor
(XEN) rax: 0000000000187000   rbx: ffff830c3dc97f18   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: ffff830c3dc97f18
(XEN) rbp: ffff830c3dc97f08   rsp: ffff830c3dc97d98   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: ffff8300a9786000   r13: 0000000000000028   r14: 0000000000000000
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c17ec0000   cr2: 00000000002f7d38
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc97d98:
(XEN)    ffff8300a9786000 ffff8300a9786000 ffff8300a9786000 ffff830c3dc9c088
(XEN)    ffff830c3dc97e08 0000000000000000 ffff830c3dc97de8 ffff830c3dc90000
(XEN)    ffff830c3dc9c0a0 ffff8300a9786000 000001e512e27b8b ffff8300a9786000
(XEN)    ffff830c3dc9c088 0000000001c9c380 0000000000000292 ffff830c3dc97e28
(XEN)    ffff82d08012a80f ffff8300a9786000 ffff830c3dc97e98 ffff82d0801caea5
(XEN)    ffff830c3dc97ec8 ffff8300a9786508 ffff82d080321280 ffff830c3dc9c0a0
(XEN)    ffff830c3dc97e78 ffff830c3dc97e88 ffff82d0801b5277 ffff8300a9786000
(XEN)    000001e512e27b8b ffff8300a9786000 ffff830c3dc97f08 ffff82d0801e0f69
(XEN)    ffff830c3dc97f18 ffff8300a9786000 ffff830c3dc97f08 ffff82d0801ddba6
(XEN)    ffff830c3dc90000 0000000000000001 ffff830c3dc97ef8 ffff82d08012a1b3
(XEN)    ffff8300a9786000 ffff8300a9786000 fffff88002e4ad70 00000394002722bb
(XEN)    000000000000000f 0000000000000001 000000000000000f ffff82d0801e3c81
(XEN)    0000000000000001 000000000000000f 00000394002722bb fffff88002e4ad70
(XEN)    000000000000000f fffff88002e40180 fffff88002e4ad70 fffff88002e402a0
(XEN)    00000256dc1c8f33 fffff88002e402a0 0000000000000002 fffff88002e401c0
(XEN)    0000000000000400 0000000000000000 fffff88002e4aeb0 0000beef0000beef
(XEN)    fffff8000298a20c 000000bf0000beef 0000000000000046 fffff88002e4ac20
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    000000000000beef 0000000000000004 ffff8300a9786000 0000003bbd97ae00
(XEN)    0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801dc4fe>] vmx_vmexit_handler+0x311/0x195e
(XEN)    [<ffff82d0801e3c81>] vmx_asm_vmexit_handler+0x41/0xc0
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000002f7d38
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82d08012a825>] _spin_lock+0x27/0x54
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: ffff830c17ceb628   rcx: 0000000000000000
(XEN) rdx: 0000000000000000   rsi: 0000000000000008   rdi: ffff830c17ceb62c
(XEN) rbp: ffff830c3dc87df8   rsp: ffff830c3dc87df0   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 00000003428f7600
(XEN) r12: 0000000000000008   r13: 0000000000000008   r14: ffff830c17ceb628
(XEN) r15: ffff8300a9787000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c180ec000   cr2: 000000000148f940
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc87df0:
(XEN)    ffff830c17ceb000 ffff830c3dc87e28 ffff82d0801c08e6 0000000000000008
(XEN)    0000000000000008 0000000000000001 ffff8300a9787000 ffff830c3dc87e98
(XEN)    ffff82d0801caef7 ffff830c3dc87ec8 ffff8300a9787508 000000023dc87e58
(XEN)    ffff830c17ceb4a0 00000143f866c070 ffff8300a9787510 ffff82d0801b5277
(XEN)    ffff8300a9787000 fffff880048d08f8 0000000000001000 0000000000000000
(XEN)    0000000000000058 ffff830c3dc87f08 ffff82d0801d4c75 ffff830c3dc87f08
(XEN)    ffffffff801ddba6 ffff830c3dc80000 0000000000000058 ffff830c3dc87ef8
(XEN)    ffff82d08012a1b3 ffff8300a9787000 ffff8300a9787000 fffff880048d08f8
(XEN)    0000000000001000 0000000000000000 0000000000000058 000000000000897d
(XEN)    ffff82d0801e3c86 0000000000000058 0000000000000000 0000000000001000
(XEN)    fffff880048d08f8 000000000000897d 000003af014f24a8 00000003428f7600
(XEN)    fffff880048d0570 0000000000000000 fffff880048d0520 000003af014efe7d
(XEN)    000000000000ffff 000003af00000000 0000000000000000 0000000000000052
(XEN)    0000beef0000beef fffff800028232bf 000000bf0000beef 0000000000000002
(XEN)    fffff880048d04c0 000000000000beef 000000000000beef 000000000000beef
(XEN)    000000000000beef 000000000000beef 0000000000000005 ffff8300a9787000
(XEN)    0000003bbd96ce00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a825>] _spin_lock+0x27/0x54
(XEN)    [<ffff82d0801c08e6>] hvm_isa_irq_deassert+0x34/0x77
(XEN)    [<ffff82d0801caef7>] pt_update_irq+0x1b8/0x230
(XEN)    [<ffff82d0801d4c75>] vmx_intr_assist+0x5d/0x51c
(XEN)    [<ffff82d0801e3c86>] vmx_asm_vmexit_handler+0x46/0xc0
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff800028232bf>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 000003af014efe7d   rbx: 000003af014f24a8   rcx: 000000000000ffff
(XEN) rdx: 000003af00000000   rsi: 0000000000000000   rdi: 0000000000000052
(XEN) rbp: 000000000000897d   rsp: fffff880048d04c0   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 00000003428f7600
(XEN) r12: fffff880048d08f8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000148f940
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        1796us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=        6341us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=       16341us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN)   ex=     4520950us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=      891686us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=    14347450us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN) CPU01:
(XEN)   ex=        6500us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=       16341us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=      939396us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=       67396us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=       30022us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=        6493us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       16341us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=      135396us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=       30035us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=         753us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex=        1042us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex= 44115619478us timer=ffff830c17ceb290 
cb=rtc_alarm_cb(ffff830c17ceb1f0)
(XEN)   ex=       16341us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex=        6535us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN) CPU04:
(XEN)   ex=        4039us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=        6506us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=       16341us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=       30055us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=        6536us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=       16341us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=      755722us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=   332034653us timer=ffff830c17ceb5d0 
cb=pmt_timer_callback(ffff830c17ceb5a8)
(XEN)   ex=       30066us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  00000353a8bde5bd   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000039400271946   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef88138c8
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff800028232c1>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 000003b6a07ae098   rbx: 000003b6a07b06ed   rcx: 000000000000ffff
(XEN) rdx: 000003b600000000   rsi: 0000000000000000   rdi: 0000000000000051
(XEN) rbp: 0000000000006ed0   rsp: fffff880048d04c0   r8: fffff880048d0520
(XEN) r9:  0000000000000000   r10: fffff880048d0570   r11: 00000003428f7600
(XEN) r12: fffff880048d08f8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000148f940
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000034bbd959ead   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000003940051e450   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000031f268
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000298a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  000003295cdc3c57   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 000003940027203c   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 0000000001cb8300
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  00000256dc1c8f33   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 00000394002722bb   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 00000000002f7d38
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000298a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000003071d1e7b55   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 00000394002e01ea   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000000043fd28
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) 'R' pressed -> rebooting machine
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:11:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:11:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrY4S-00007m-DS; Thu, 20 Nov 2014 20:11:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrY4Q-00007g-Fq
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 20:11:14 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	22/FC-09842-1EA4E645; Thu, 20 Nov 2014 20:11:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416514271!14229885!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31000 invoked from network); 20 Nov 2014 20:11:12 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:11:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKB8EO032029
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:11:08 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKB6p2027591
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 20:11:07 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKB6Ve025106; Thu, 20 Nov 2014 20:11:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:11:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 055D1118658; Thu, 20 Nov 2014 15:11:04 -0500 (EST)
Date: Thu, 20 Nov 2014 15:11:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141120201104.GC31889@laptop.dumpdata.com>
References: <5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
	<546DAE8F020000780004930A@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Chen,
	Tiejun" <tiejun.chen@intel.com>, "tim@xen.org" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 are you OK with this? In previous approach we reserved all the
> RMRR regions so hotplug scenario is covered automatically. Now since
> we want to do BDF specific filtering, this new interface is actually
> necessary for hotplug support. If OK, Tiejun will send out a new 
> series to see whether it's ready for 4.5 check-in.

Could you also drop the 'RFC' part please? And please do mention in your
cover letter how to reproduce the initial bug (perhaps a pointer to
the hardware and software that this affects?)

Thank you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:11:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:11:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrY4S-00007m-DS; Thu, 20 Nov 2014 20:11:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrY4Q-00007g-Fq
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 20:11:14 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	22/FC-09842-1EA4E645; Thu, 20 Nov 2014 20:11:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416514271!14229885!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31000 invoked from network); 20 Nov 2014 20:11:12 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:11:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKB8EO032029
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:11:08 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKB6p2027591
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 20:11:07 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKB6Ve025106; Thu, 20 Nov 2014 20:11:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:11:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 055D1118658; Thu, 20 Nov 2014 15:11:04 -0500 (EST)
Date: Thu, 20 Nov 2014 15:11:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141120201104.GC31889@laptop.dumpdata.com>
References: <5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
	<546DAE8F020000780004930A@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Chen,
	Tiejun" <tiejun.chen@intel.com>, "tim@xen.org" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 are you OK with this? In previous approach we reserved all the
> RMRR regions so hotplug scenario is covered automatically. Now since
> we want to do BDF specific filtering, this new interface is actually
> necessary for hotplug support. If OK, Tiejun will send out a new 
> series to see whether it's ready for 4.5 check-in.

Could you also drop the 'RFC' part please? And please do mention in your
cover letter how to reproduce the initial bug (perhaps a pointer to
the hardware and software that this affects?)

Thank you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:17:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20: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 1XrYAT-0000PL-73; Thu, 20 Nov 2014 20:17:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrYAR-0000PG-Ji
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 20:17:27 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	F3/77-02698-65C4E645; Thu, 20 Nov 2014 20:17:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416514644!8426753!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3163 invoked from network); 20 Nov 2014 20:17:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:17:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKHEt9029548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:17:14 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKHCUu012277
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 20:17:13 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKHCRM021367; Thu, 20 Nov 2014 20:17:12 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:17:12 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 508D7118667; Thu, 20 Nov 2014 15:17:11 -0500 (EST)
Date: Thu, 20 Nov 2014 15:17:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141120201710.GD31889@laptop.dumpdata.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416502062.20161.8.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416502062.20161.8.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: julien.grall@citrix.com, andrii.tseglytskyi@globallogic.com,
	xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 04:47:42PM +0000, Ian Campbell wrote:
> On Thu, 2014-11-20 at 10:53 +0000, Stefano Stabellini wrote:
> > UIE being set can cause maintenance interrupts to occur when Xen writes
> > to one or more LR registers. The effect is a busy loop around the
> > interrupt handler in Xen
> > (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> 
> I think it would be useful to explain somewhere why/how a spurious
> interrupt can occur, if not here then in the comment you've already
> added or in another one in gic_clear_lrs where you clear UIE.
> 
> The bit about clearing the LRs on entry causing UIE to become deasserted
> before we get as far as reading the IAR is a bit subtle.
> 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > CC: konrad.wilk@oracle.com
> 
> With the expanded commentary:
>         Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > ---
> > 
> > Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> > bad side effects on any other platforms as far as I can tell. It should
> > go in 4.5.

As long as the testing that Julian has asked for does not demonstrate
any issues with this patch I am OK with it going in Xen 4.5.


> > 
> > Changes in v2:
> > 
> > - add an in-code comment about maintenance_interrupt not being called.
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 70d10d6..c6c11d3 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
> >      if ( is_idle_vcpu(v) )
> >          return;
> >  
> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> > +
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >  
> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> > @@ -527,8 +529,6 @@ void gic_inject(void)
> >  
> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> > -    else
> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >  }
> >  
> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> > @@ -598,6 +598,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >       * Receiving the interrupt is going to cause gic_inject to be called
> >       * on return to guest that is going to clear the old LRs and inject
> >       * new interrupts.
> > +     *
> > +     * Do not add code here: maintenance interrupts caused by setting
> > +     * GICH_HCR_UIE, might read as spurious interrupts (1023). As a
> > +     * consequence sometimes this handler might not be called.
> >       */
> >  }
> >  
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:17:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20: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 1XrYAT-0000PL-73; Thu, 20 Nov 2014 20:17:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrYAR-0000PG-Ji
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 20:17:27 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	F3/77-02698-65C4E645; Thu, 20 Nov 2014 20:17:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416514644!8426753!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3163 invoked from network); 20 Nov 2014 20:17:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:17:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKHEt9029548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:17:14 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKHCUu012277
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 20:17:13 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKHCRM021367; Thu, 20 Nov 2014 20:17:12 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:17:12 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 508D7118667; Thu, 20 Nov 2014 15:17:11 -0500 (EST)
Date: Thu, 20 Nov 2014 15:17:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141120201710.GD31889@laptop.dumpdata.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416502062.20161.8.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416502062.20161.8.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: julien.grall@citrix.com, andrii.tseglytskyi@globallogic.com,
	xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 04:47:42PM +0000, Ian Campbell wrote:
> On Thu, 2014-11-20 at 10:53 +0000, Stefano Stabellini wrote:
> > UIE being set can cause maintenance interrupts to occur when Xen writes
> > to one or more LR registers. The effect is a busy loop around the
> > interrupt handler in Xen
> > (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> 
> I think it would be useful to explain somewhere why/how a spurious
> interrupt can occur, if not here then in the comment you've already
> added or in another one in gic_clear_lrs where you clear UIE.
> 
> The bit about clearing the LRs on entry causing UIE to become deasserted
> before we get as far as reading the IAR is a bit subtle.
> 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> > CC: konrad.wilk@oracle.com
> 
> With the expanded commentary:
>         Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > ---
> > 
> > Konrad, this fixes an actual bug, at least on OMAP5. It should have no
> > bad side effects on any other platforms as far as I can tell. It should
> > go in 4.5.

As long as the testing that Julian has asked for does not demonstrate
any issues with this patch I am OK with it going in Xen 4.5.


> > 
> > Changes in v2:
> > 
> > - add an in-code comment about maintenance_interrupt not being called.
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 70d10d6..c6c11d3 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
> >      if ( is_idle_vcpu(v) )
> >          return;
> >  
> > +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> > +
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >  
> >      while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
> > @@ -527,8 +529,6 @@ void gic_inject(void)
> >  
> >      if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
> >          gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> > -    else
> > -        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
> >  }
> >  
> >  static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> > @@ -598,6 +598,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >       * Receiving the interrupt is going to cause gic_inject to be called
> >       * on return to guest that is going to clear the old LRs and inject
> >       * new interrupts.
> > +     *
> > +     * Do not add code here: maintenance interrupts caused by setting
> > +     * GICH_HCR_UIE, might read as spurious interrupts (1023). As a
> > +     * consequence sometimes this handler might not be called.
> >       */
> >  }
> >  
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:18:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:18:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrYBY-0000T9-LE; Thu, 20 Nov 2014 20:18:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XrYBX-0000Sy-FJ
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 20:18:35 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A9/86-03148-A9C4E645; Thu, 20 Nov 2014 20:18:34 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416514713!9209510!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28215 invoked from network); 20 Nov 2014 20:18:34 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 20 Nov 2014 20:18:34 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:49851 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XrY9q-0001t2-MI; Thu, 20 Nov 2014 21:16:50 +0100
Date: Thu, 20 Nov 2014 21:18:30 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1131707258.20141120211830@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141120195133.GE25423@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: andrew.cooper3@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
	to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, November 20, 2014, 8:51:33 PM, you wrote:

> Ah crud.

> So a simple fix could be to seperate the 'state' to only deal with the
> raise_softirq and softirq_dpci. And then add a new (old) 'masked' to
> deal between hvm_dirq_assist, pt_irq_guest_eoi and hvm_do_IRQ_dpci.


> From 94a98e20a8ab721a58788919f92e3524a6c6e25c Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Thu, 20 Nov 2014 14:28:11 -0500
> Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

> commit f6dd295381f4b6a66acddacf46bca8940586c8d8
> "dpci: replace tasklet with softirq" used the 'masked' as an
> two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
> between 'raise_softirq_for' and 'dpci_softirq' to determine whether
> the 'struct hvm_pirq_dpci' can be re-scheduled.

<SNIP>

Hi Konrad,

Is this patch supposed to replace both the previous ones ?

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:18:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:18:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrYBY-0000T9-LE; Thu, 20 Nov 2014 20:18:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XrYBX-0000Sy-FJ
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 20:18:35 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A9/86-03148-A9C4E645; Thu, 20 Nov 2014 20:18:34 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416514713!9209510!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28215 invoked from network); 20 Nov 2014 20:18:34 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 20 Nov 2014 20:18:34 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:49851 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XrY9q-0001t2-MI; Thu, 20 Nov 2014 21:16:50 +0100
Date: Thu, 20 Nov 2014 21:18:30 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1131707258.20141120211830@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141120195133.GE25423@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: andrew.cooper3@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
	to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, November 20, 2014, 8:51:33 PM, you wrote:

> Ah crud.

> So a simple fix could be to seperate the 'state' to only deal with the
> raise_softirq and softirq_dpci. And then add a new (old) 'masked' to
> deal between hvm_dirq_assist, pt_irq_guest_eoi and hvm_do_IRQ_dpci.


> From 94a98e20a8ab721a58788919f92e3524a6c6e25c Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Thu, 20 Nov 2014 14:28:11 -0500
> Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

> commit f6dd295381f4b6a66acddacf46bca8940586c8d8
> "dpci: replace tasklet with softirq" used the 'masked' as an
> two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
> between 'raise_softirq_for' and 'dpci_softirq' to determine whether
> the 'struct hvm_pirq_dpci' can be re-scheduled.

<SNIP>

Hi Konrad,

Is this patch supposed to replace both the previous ones ?

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:21:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrYEY-0000dL-8n; Thu, 20 Nov 2014 20:21:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrYEW-0000dA-O3
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 20:21:40 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EF/62-09842-45D4E645; Thu, 20 Nov 2014 20:21:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416514898!12114023!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27284 invoked from network); 20 Nov 2014 20:21:39 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:21:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKLIBL011322
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:21:19 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKLG5J026537
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Nov 2014 20:21:17 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAKKLFiL001085; Thu, 20 Nov 2014 20:21:16 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:21:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9D4D9118671; Thu, 20 Nov 2014 15:21:14 -0500 (EST)
Date: Thu, 20 Nov 2014 15:21:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>, gedalya@gedalya.net
Message-ID: <20141120202114.GE31889@laptop.dumpdata.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> up leaked.
> 
> The memory pool currently supports mmap'd buffers as well as a directly
> allocated buffers, however the try decode routines make use of realloc and do
> not fit well into this model. Introduce a concept of an external memory block
> to the memory pool and provide an interface to register such memory.
> 
> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> mmap_ prefix since they are now also used for external memory blocks.
> 
> We are only seeing this now because the gzip decoder doesn't leak and it's only
> relatively recently that kernels in the wild have switched to better
> compression.
> 
> This is https://bugs.debian.org/767295
> 
> Reported by: Gedalya <gedalya@gedalya.net>

Gedelya,

Could you also test this patch to make sure it does fix the
reported issue please?

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: Correct handling in xc_try_lzo1x_decode.
> 
> This is a bug fix and should go into 4.5.
> 
> I have a sneaking suspicion this is going to need to backport a very long way...
> ---
>  tools/libxc/include/xc_dom.h        |   10 ++++--
>  tools/libxc/xc_dom_bzimageloader.c  |   20 ++++++++++++
>  tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
>  tools/libxc/xc_dom_decompress_lz4.c |    5 +++
>  4 files changed, 80 insertions(+), 16 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6ae6a9f..07d7224 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -33,8 +33,13 @@ struct xc_dom_seg {
>  
>  struct xc_dom_mem {
>      struct xc_dom_mem *next;
> -    void *mmap_ptr;
> -    size_t mmap_len;
> +    void *ptr;
> +    enum {
> +        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
> +        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
> +        XC_DOM_MEM_TYPE_MMAP,
> +    } type;
> +    size_t len;
>      unsigned char memory[0];
>  };
>  
> @@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
>  /* --- simple memory pool ------------------------------------------ */
>  
>  void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
>  void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>                              const char *filename, size_t * size,
> diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
> index 2225699..964ebdc 100644
> --- a/tools/libxc/xc_dom_bzimageloader.c
> +++ b/tools/libxc/xc_dom_bzimageloader.c
> @@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
>  
>      total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
>  
> +    if ( xc_dom_register_external(dom, out_buf, total) )
> +    {
> +        DOMPRINTF("BZIP2: Error registering stream output");
> +        free(out_buf);
> +        goto bzip2_cleanup;
> +    }
> +
>      DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
>                __FUNCTION__, *size, (long unsigned int) total);
>  
> @@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
>          }
>      }
>  
> +    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
> +    {
> +        DOMPRINTF("%s: Error registering stream output", what);
> +        free(out_buf);
> +        goto lzma_cleanup;
> +    }
> +
>      DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
>                __FUNCTION__, what, *size, (size_t)stream->total_out);
>  
> @@ -464,7 +478,13 @@ static int xc_try_lzo1x_decode(
>  
>          dst_len = lzo_read_32(cur);
>          if ( !dst_len )
> +        {
> +            msg = "Error registering stream output";
> +            if ( xc_dom_register_external(dom, out_buf, out_len) )
> +                break;
> +
>              return 0;
> +        }
>  
>          if ( dst_len > LZOP_MAX_BLOCK_SIZE )
>          {
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index baa62a1..ecbf981 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block) + size);
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block) + size;
> @@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len,
> -                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> -                           -1, 0);
> -    if ( block->mmap_ptr == MAP_FAILED )
> +    block->len = size;
> +    block->ptr = mmap(NULL, block->len,
> +                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> +                      -1, 0);
> +    if ( block->ptr == MAP_FAILED )
>      {
>          DOMPRINTF("%s: mmap failed", __FUNCTION__);
>          free(block);
>          return NULL;
>      }
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_mem_map += block->mmap_len;
> +    dom->alloc_mem_map += block->len;
>      if ( size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, size);
> -    return block->mmap_ptr;
> +    return block->ptr;
> +}
> +
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
> +{
> +    struct xc_dom_mem *block;
> +
> +    block = malloc(sizeof(*block));
> +    if ( block == NULL )
> +    {
> +        DOMPRINTF("%s: allocation failed", __FUNCTION__);
> +        return -1;
> +    }
> +    memset(block, 0, sizeof(*block));
> +    block->ptr = ptr;
> +    block->len = size;
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
> +    block->next = dom->memblocks;
> +    dom->memblocks = block;
> +    dom->alloc_malloc += sizeof(*block);
> +    dom->alloc_mem_map += block->len;
> +    return 0;
>  }
>  
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
> @@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>      }
>  
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = *size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
> +    block->len = *size;
> +    block->ptr = mmap(NULL, block->len, PROT_READ,
>                             MAP_SHARED, fd, 0);
> -    if ( block->mmap_ptr == MAP_FAILED ) {
> +    if ( block->ptr == MAP_FAILED ) {
>          xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
>                       "failed to mmap file: %s",
>                       strerror(errno));
>          goto err;
>      }
>  
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_file_map += block->mmap_len;
> +    dom->alloc_file_map += block->len;
>      close(fd);
>      if ( *size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, *size);
> -    return block->mmap_ptr;
> +    return block->ptr;
>  
>   err:
>      if ( fd != -1 )
> @@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
>      while ( (block = dom->memblocks) != NULL )
>      {
>          dom->memblocks = block->next;
> -        if ( block->mmap_ptr )
> -            munmap(block->mmap_ptr, block->mmap_len);
> +        switch ( block->type )
> +        {
> +        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
> +            break;
> +        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
> +            free(block->ptr);
> +            break;
> +        case XC_DOM_MEM_TYPE_MMAP:
> +            munmap(block->ptr, block->len);
> +            break;
> +        }
>          free(block);
>      }
>  }
> diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
> index 490ec56..b6a33f2 100644
> --- a/tools/libxc/xc_dom_decompress_lz4.c
> +++ b/tools/libxc/xc_dom_decompress_lz4.c
> @@ -103,6 +103,11 @@ int xc_try_lz4_decode(
>  
>  		if (size == 0)
>  		{
> +			if ( xc_dom_register_external(dom, output, out_len) )
> +			{
> +				msg = "Error registering stream output";
> +				goto exit_2;
> +			}
>  			*blob = output;
>  			*psize = out_len;
>  			return 0;
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:21:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrYEY-0000dL-8n; Thu, 20 Nov 2014 20:21:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrYEW-0000dA-O3
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 20:21:40 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EF/62-09842-45D4E645; Thu, 20 Nov 2014 20:21:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416514898!12114023!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27284 invoked from network); 20 Nov 2014 20:21:39 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:21:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKLIBL011322
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:21:19 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKLG5J026537
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Nov 2014 20:21:17 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAKKLFiL001085; Thu, 20 Nov 2014 20:21:16 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:21:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9D4D9118671; Thu, 20 Nov 2014 15:21:14 -0500 (EST)
Date: Thu, 20 Nov 2014 15:21:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>, gedalya@gedalya.net
Message-ID: <20141120202114.GE31889@laptop.dumpdata.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> up leaked.
> 
> The memory pool currently supports mmap'd buffers as well as a directly
> allocated buffers, however the try decode routines make use of realloc and do
> not fit well into this model. Introduce a concept of an external memory block
> to the memory pool and provide an interface to register such memory.
> 
> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> mmap_ prefix since they are now also used for external memory blocks.
> 
> We are only seeing this now because the gzip decoder doesn't leak and it's only
> relatively recently that kernels in the wild have switched to better
> compression.
> 
> This is https://bugs.debian.org/767295
> 
> Reported by: Gedalya <gedalya@gedalya.net>

Gedelya,

Could you also test this patch to make sure it does fix the
reported issue please?

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: Correct handling in xc_try_lzo1x_decode.
> 
> This is a bug fix and should go into 4.5.
> 
> I have a sneaking suspicion this is going to need to backport a very long way...
> ---
>  tools/libxc/include/xc_dom.h        |   10 ++++--
>  tools/libxc/xc_dom_bzimageloader.c  |   20 ++++++++++++
>  tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
>  tools/libxc/xc_dom_decompress_lz4.c |    5 +++
>  4 files changed, 80 insertions(+), 16 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6ae6a9f..07d7224 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -33,8 +33,13 @@ struct xc_dom_seg {
>  
>  struct xc_dom_mem {
>      struct xc_dom_mem *next;
> -    void *mmap_ptr;
> -    size_t mmap_len;
> +    void *ptr;
> +    enum {
> +        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
> +        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
> +        XC_DOM_MEM_TYPE_MMAP,
> +    } type;
> +    size_t len;
>      unsigned char memory[0];
>  };
>  
> @@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
>  /* --- simple memory pool ------------------------------------------ */
>  
>  void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
>  void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>                              const char *filename, size_t * size,
> diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
> index 2225699..964ebdc 100644
> --- a/tools/libxc/xc_dom_bzimageloader.c
> +++ b/tools/libxc/xc_dom_bzimageloader.c
> @@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
>  
>      total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
>  
> +    if ( xc_dom_register_external(dom, out_buf, total) )
> +    {
> +        DOMPRINTF("BZIP2: Error registering stream output");
> +        free(out_buf);
> +        goto bzip2_cleanup;
> +    }
> +
>      DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
>                __FUNCTION__, *size, (long unsigned int) total);
>  
> @@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
>          }
>      }
>  
> +    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
> +    {
> +        DOMPRINTF("%s: Error registering stream output", what);
> +        free(out_buf);
> +        goto lzma_cleanup;
> +    }
> +
>      DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
>                __FUNCTION__, what, *size, (size_t)stream->total_out);
>  
> @@ -464,7 +478,13 @@ static int xc_try_lzo1x_decode(
>  
>          dst_len = lzo_read_32(cur);
>          if ( !dst_len )
> +        {
> +            msg = "Error registering stream output";
> +            if ( xc_dom_register_external(dom, out_buf, out_len) )
> +                break;
> +
>              return 0;
> +        }
>  
>          if ( dst_len > LZOP_MAX_BLOCK_SIZE )
>          {
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index baa62a1..ecbf981 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block) + size);
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block) + size;
> @@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
>          return NULL;
>      }
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len,
> -                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> -                           -1, 0);
> -    if ( block->mmap_ptr == MAP_FAILED )
> +    block->len = size;
> +    block->ptr = mmap(NULL, block->len,
> +                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
> +                      -1, 0);
> +    if ( block->ptr == MAP_FAILED )
>      {
>          DOMPRINTF("%s: mmap failed", __FUNCTION__);
>          free(block);
>          return NULL;
>      }
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_mem_map += block->mmap_len;
> +    dom->alloc_mem_map += block->len;
>      if ( size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, size);
> -    return block->mmap_ptr;
> +    return block->ptr;
> +}
> +
> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
> +{
> +    struct xc_dom_mem *block;
> +
> +    block = malloc(sizeof(*block));
> +    if ( block == NULL )
> +    {
> +        DOMPRINTF("%s: allocation failed", __FUNCTION__);
> +        return -1;
> +    }
> +    memset(block, 0, sizeof(*block));
> +    block->ptr = ptr;
> +    block->len = size;
> +    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
> +    block->next = dom->memblocks;
> +    dom->memblocks = block;
> +    dom->alloc_malloc += sizeof(*block);
> +    dom->alloc_mem_map += block->len;
> +    return 0;
>  }
>  
>  void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
> @@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>      }
>  
>      memset(block, 0, sizeof(*block));
> -    block->mmap_len = *size;
> -    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
> +    block->len = *size;
> +    block->ptr = mmap(NULL, block->len, PROT_READ,
>                             MAP_SHARED, fd, 0);
> -    if ( block->mmap_ptr == MAP_FAILED ) {
> +    if ( block->ptr == MAP_FAILED ) {
>          xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
>                       "failed to mmap file: %s",
>                       strerror(errno));
>          goto err;
>      }
>  
> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>      block->next = dom->memblocks;
>      dom->memblocks = block;
>      dom->alloc_malloc += sizeof(*block);
> -    dom->alloc_file_map += block->mmap_len;
> +    dom->alloc_file_map += block->len;
>      close(fd);
>      if ( *size > (100 * 1024) )
>          print_mem(dom, __FUNCTION__, *size);
> -    return block->mmap_ptr;
> +    return block->ptr;
>  
>   err:
>      if ( fd != -1 )
> @@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
>      while ( (block = dom->memblocks) != NULL )
>      {
>          dom->memblocks = block->next;
> -        if ( block->mmap_ptr )
> -            munmap(block->mmap_ptr, block->mmap_len);
> +        switch ( block->type )
> +        {
> +        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
> +            break;
> +        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
> +            free(block->ptr);
> +            break;
> +        case XC_DOM_MEM_TYPE_MMAP:
> +            munmap(block->ptr, block->len);
> +            break;
> +        }
>          free(block);
>      }
>  }
> diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
> index 490ec56..b6a33f2 100644
> --- a/tools/libxc/xc_dom_decompress_lz4.c
> +++ b/tools/libxc/xc_dom_decompress_lz4.c
> @@ -103,6 +103,11 @@ int xc_try_lz4_decode(
>  
>  		if (size == 0)
>  		{
> +			if ( xc_dom_register_external(dom, output, out_len) )
> +			{
> +				msg = "Error registering stream output";
> +				goto exit_2;
> +			}
>  			*blob = output;
>  			*psize = out_len;
>  			return 0;
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:24:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:24:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrYGu-0000sa-SR; Thu, 20 Nov 2014 20:24:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrYGo-0000sQ-Bm
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 20:24:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E7/31-25276-1ED4E645; Thu, 20 Nov 2014 20:24:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416515039!6225294!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13965 invoked from network); 20 Nov 2014 20:24:00 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:24:00 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKNoGt004399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:23:51 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKNni5006795
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Nov 2014 20:23:49 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAKKNm2n008672; Thu, 20 Nov 2014 20:23:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:23:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id F2FA21186A9; Thu, 20 Nov 2014 15:23:46 -0500 (EST)
Date: Thu, 20 Nov 2014 15:23:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141120202346.GF31889@laptop.dumpdata.com>
References: <1416504963-4830-1-git-send-email-julien.grall@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416504963-4830-1-git-send-email-julien.grall@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 05:36:03PM +0000, Julien Grall wrote:
> The current script is setting $email_remove_duplicates to 1 by default, on
> complex patch (see [1]), this will result to ommitting randomly some
> maintainers.

One could see that as feature - the emails about bugs or patches
to review don't land in your inbox! 

> 
> This is because, the script will:
>     1) Get the list of maintainers of the file (incidentally all the
>        maintainers in "THE REST" role are added). If the email address already
>        exists in the global list, skip it. => The role will be lost
>     2) Filter the list to remove the entry with "THE REST" role
> 
> So if a maintainers is marked with "THE REST" role on the first file and
> actually be an x86 maintainers on the script, the script will only retain
> the "THE REST" role. During the filtering step, this maintainers will
> therefore be dropped.
> 
> This patch fixes this by setting $email_remove_duplicates to 0 by default.
> The new behavior of the script will be:
>     1) Append the list of maintainers for every file
>     2) Filter the list to remove the entry with "THE REST" role
>     3) Remove duplicated email address
> 
> Example:
> 
> Patch: https://patches.linaro.org/41083/
> 
> Before the patch:
> 
> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Ian Campbell <ian.campbell@citrix.com>
> Wei Liu <wei.liu2@citrix.com>
> George Dunlap <george.dunlap@eu.citrix.com>
> xen-devel@lists.xen.org
> 
> After the patch:
> 
> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Ian Campbell <ian.campbell@citrix.com>
> Wei Liu <wei.liu2@citrix.com>
> Stefano Stabellini <stefano.stabellini@citrix.com>
> Tim Deegan <tim@xen.org>
> Keir Fraser <keir@xen.org>
> Jan Beulich <jbeulich@suse.com>
> George Dunlap <george.dunlap@eu.citrix.com>
> xen-devel@lists.xen.org
> 
> [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> CC: Don Slutz <dslutz@verizon.com>
> 
> ---
>     Changes in v2:
>         - Rework the commit message to explain the problem and the
>         solution more clearly
> 
>     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
>     time the script has been introduced).
> 
>     Developpers using this script won't ommitted to cc some maintainers, and it
>     will avoid maintainers complaining about miss CC.
> 
>     The only drawbacks I can see is if the maintainers is referenced twice in
>     the file MAINTAINERS with different email, the script won't notice it's
>     duplicated and list 2 times. Though, for this one it could be fixed by
>     modifying  the MAINTAINERS file. Is it worth for Xen 4.5? For know,
>     it seems to only happen with Stefano.

I am OK with this going in Xen 4.5.

Thank you.
> ---
>  scripts/get_maintainer.pl |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index df920e2..cc445cd 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -35,7 +35,7 @@ my $email_git_min_percent = 5;
>  my $email_git_since = "1-year-ago";
>  my $email_hg_since = "-365";
>  my $interactive = 0;
> -my $email_remove_duplicates = 1;
> +my $email_remove_duplicates = 0;
>  my $email_use_mailmap = 1;
>  my $email_drop_the_rest_supporter_if_supporter_found = 1;
>  my $output_multiline = 1;
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:24:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:24:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrYGu-0000sa-SR; Thu, 20 Nov 2014 20:24:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrYGo-0000sQ-Bm
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 20:24:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E7/31-25276-1ED4E645; Thu, 20 Nov 2014 20:24:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416515039!6225294!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13965 invoked from network); 20 Nov 2014 20:24:00 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:24:00 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKNoGt004399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:23:51 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKNni5006795
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Nov 2014 20:23:49 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAKKNm2n008672; Thu, 20 Nov 2014 20:23:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:23:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id F2FA21186A9; Thu, 20 Nov 2014 15:23:46 -0500 (EST)
Date: Thu, 20 Nov 2014 15:23:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141120202346.GF31889@laptop.dumpdata.com>
References: <1416504963-4830-1-git-send-email-julien.grall@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416504963-4830-1-git-send-email-julien.grall@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 05:36:03PM +0000, Julien Grall wrote:
> The current script is setting $email_remove_duplicates to 1 by default, on
> complex patch (see [1]), this will result to ommitting randomly some
> maintainers.

One could see that as feature - the emails about bugs or patches
to review don't land in your inbox! 

> 
> This is because, the script will:
>     1) Get the list of maintainers of the file (incidentally all the
>        maintainers in "THE REST" role are added). If the email address already
>        exists in the global list, skip it. => The role will be lost
>     2) Filter the list to remove the entry with "THE REST" role
> 
> So if a maintainers is marked with "THE REST" role on the first file and
> actually be an x86 maintainers on the script, the script will only retain
> the "THE REST" role. During the filtering step, this maintainers will
> therefore be dropped.
> 
> This patch fixes this by setting $email_remove_duplicates to 0 by default.
> The new behavior of the script will be:
>     1) Append the list of maintainers for every file
>     2) Filter the list to remove the entry with "THE REST" role
>     3) Remove duplicated email address
> 
> Example:
> 
> Patch: https://patches.linaro.org/41083/
> 
> Before the patch:
> 
> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Ian Campbell <ian.campbell@citrix.com>
> Wei Liu <wei.liu2@citrix.com>
> George Dunlap <george.dunlap@eu.citrix.com>
> xen-devel@lists.xen.org
> 
> After the patch:
> 
> Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Ian Campbell <ian.campbell@citrix.com>
> Wei Liu <wei.liu2@citrix.com>
> Stefano Stabellini <stefano.stabellini@citrix.com>
> Tim Deegan <tim@xen.org>
> Keir Fraser <keir@xen.org>
> Jan Beulich <jbeulich@suse.com>
> George Dunlap <george.dunlap@eu.citrix.com>
> xen-devel@lists.xen.org
> 
> [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> CC: Don Slutz <dslutz@verizon.com>
> 
> ---
>     Changes in v2:
>         - Rework the commit message to explain the problem and the
>         solution more clearly
> 
>     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
>     time the script has been introduced).
> 
>     Developpers using this script won't ommitted to cc some maintainers, and it
>     will avoid maintainers complaining about miss CC.
> 
>     The only drawbacks I can see is if the maintainers is referenced twice in
>     the file MAINTAINERS with different email, the script won't notice it's
>     duplicated and list 2 times. Though, for this one it could be fixed by
>     modifying  the MAINTAINERS file. Is it worth for Xen 4.5? For know,
>     it seems to only happen with Stefano.

I am OK with this going in Xen 4.5.

Thank you.
> ---
>  scripts/get_maintainer.pl |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index df920e2..cc445cd 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -35,7 +35,7 @@ my $email_git_min_percent = 5;
>  my $email_git_since = "1-year-ago";
>  my $email_hg_since = "-365";
>  my $interactive = 0;
> -my $email_remove_duplicates = 1;
> +my $email_remove_duplicates = 0;
>  my $email_use_mailmap = 1;
>  my $email_drop_the_rest_supporter_if_supporter_found = 1;
>  my $output_multiline = 1;
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:31:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:31:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrYNZ-00015z-7T; Thu, 20 Nov 2014 20:31:01 +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 1XrYNY-00015u-8i
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 20:31:00 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	FA/88-02696-38F4E645; Thu, 20 Nov 2014 20:30:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416515457!13842597!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13113 invoked from network); 20 Nov 2014 20:30:58 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:30:58 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKUOm6011924
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:30:24 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKUM9Q024202
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 20:30:23 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKUM83026139; Thu, 20 Nov 2014 20:30:22 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:30:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 611D81186BC; Thu, 20 Nov 2014 15:30:21 -0500 (EST)
Date: Thu, 20 Nov 2014 15:30:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141120203020.GJ31889@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141119210703.GE20440@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411201033460.12596@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411201046110.12596@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411201046110.12596@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 12/13] swiotlb-xen: pass dev_addr to
 xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 10:47:51AM +0000, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Stefano Stabellini wrote:
> > On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 12, 2014 at 11:40:53AM +0000, Stefano Stabellini wrote:
> > > > xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
> > > > handle as argument, not a physical address.
> > > 
> > > Ouch. Should this also go on stable tree?
> > 
> > Good idea
> 
> Also can I take that as an Acked-by for this patch?

Yes.
> 
> 
> There is one last bit of common and x86 changes in this series:
> patch #7 adds a paramter to xen_dma_map_page, even though the x86
> implementation is empty:
> 
> http://marc.info/?l=xen-devel&m=141579253829808&w=2
> 
> is that OK for you?

Yes.
>  
>  
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > ---
> > > >  drivers/xen/swiotlb-xen.c |    6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > > > index 3725ee4..498b654 100644
> > > > --- a/drivers/xen/swiotlb-xen.c
> > > > +++ b/drivers/xen/swiotlb-xen.c
> > > > @@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
> > > >  
> > > >  	BUG_ON(dir == DMA_NONE);
> > > >  
> > > > -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> > > > +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
> > > >  
> > > >  	/* NOTE: We use dev_addr here, not paddr! */
> > > >  	if (is_xen_swiotlb_buffer(dev_addr)) {
> > > > @@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
> > > >  	BUG_ON(dir == DMA_NONE);
> > > >  
> > > >  	if (target == SYNC_FOR_CPU)
> > > > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > > > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> > > >  
> > > >  	/* NOTE: We use dev_addr here, not paddr! */
> > > >  	if (is_xen_swiotlb_buffer(dev_addr))
> > > >  		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
> > > >  
> > > >  	if (target == SYNC_FOR_DEVICE)
> > > > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > > > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> > > >  
> > > >  	if (dir != DMA_FROM_DEVICE)
> > > >  		return;
> > > > -- 
> > > > 1.7.10.4
> > > > 
> > > 
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:31:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:31:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrYNZ-00015z-7T; Thu, 20 Nov 2014 20:31:01 +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 1XrYNY-00015u-8i
	for xen-devel@lists.xensource.com; Thu, 20 Nov 2014 20:31:00 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	FA/88-02696-38F4E645; Thu, 20 Nov 2014 20:30:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416515457!13842597!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13113 invoked from network); 20 Nov 2014 20:30:58 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:30:58 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKUOm6011924
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:30:24 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKUM9Q024202
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 20:30:23 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKUM83026139; Thu, 20 Nov 2014 20:30:22 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:30:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 611D81186BC; Thu, 20 Nov 2014 15:30:21 -0500 (EST)
Date: Thu, 20 Nov 2014 15:30:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141120203020.GJ31889@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<20141119210703.GE20440@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411201033460.12596@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411201046110.12596@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411201046110.12596@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 12/13] swiotlb-xen: pass dev_addr to
 xen_dma_unmap_page and xen_dma_sync_single_for_cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 10:47:51AM +0000, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Stefano Stabellini wrote:
> > On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 12, 2014 at 11:40:53AM +0000, Stefano Stabellini wrote:
> > > > xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
> > > > handle as argument, not a physical address.
> > > 
> > > Ouch. Should this also go on stable tree?
> > 
> > Good idea
> 
> Also can I take that as an Acked-by for this patch?

Yes.
> 
> 
> There is one last bit of common and x86 changes in this series:
> patch #7 adds a paramter to xen_dma_map_page, even though the x86
> implementation is empty:
> 
> http://marc.info/?l=xen-devel&m=141579253829808&w=2
> 
> is that OK for you?

Yes.
>  
>  
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > ---
> > > >  drivers/xen/swiotlb-xen.c |    6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > > > index 3725ee4..498b654 100644
> > > > --- a/drivers/xen/swiotlb-xen.c
> > > > +++ b/drivers/xen/swiotlb-xen.c
> > > > @@ -449,7 +449,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
> > > >  
> > > >  	BUG_ON(dir == DMA_NONE);
> > > >  
> > > > -	xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> > > > +	xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
> > > >  
> > > >  	/* NOTE: We use dev_addr here, not paddr! */
> > > >  	if (is_xen_swiotlb_buffer(dev_addr)) {
> > > > @@ -497,14 +497,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
> > > >  	BUG_ON(dir == DMA_NONE);
> > > >  
> > > >  	if (target == SYNC_FOR_CPU)
> > > > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > > > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> > > >  
> > > >  	/* NOTE: We use dev_addr here, not paddr! */
> > > >  	if (is_xen_swiotlb_buffer(dev_addr))
> > > >  		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
> > > >  
> > > >  	if (target == SYNC_FOR_DEVICE)
> > > > -		xen_dma_sync_single_for_cpu(hwdev, paddr, size, dir);
> > > > +		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
> > > >  
> > > >  	if (dir != DMA_FROM_DEVICE)
> > > >  		return;
> > > > -- 
> > > > 1.7.10.4
> > > > 
> > > 
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:31:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrYOP-00019L-LA; Thu, 20 Nov 2014 20:31:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrYOO-00019C-DJ
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 20:31:52 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	C0/0F-09284-7BF4E645; Thu, 20 Nov 2014 20:31:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416515509!12853007!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7952 invoked from network); 20 Nov 2014 20:31:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:31:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKVhJe023322
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:31:43 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKVTHj004811
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 20:31:38 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKVT1g029256; Thu, 20 Nov 2014 20:31:29 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:31:29 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 67B651186BF; Thu, 20 Nov 2014 15:31:27 -0500 (EST)
Date: Thu, 20 Nov 2014 15:31:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141120203127.GK31889@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<1131707258.20141120211830@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1131707258.20141120211830@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 09:18:30PM +0100, Sander Eikelenboom wrote:
> 
> Thursday, November 20, 2014, 8:51:33 PM, you wrote:
> 
> > Ah crud.
> 
> > So a simple fix could be to seperate the 'state' to only deal with the
> > raise_softirq and softirq_dpci. And then add a new (old) 'masked' to
> > deal between hvm_dirq_assist, pt_irq_guest_eoi and hvm_do_IRQ_dpci.
> 
> 
> > From 94a98e20a8ab721a58788919f92e3524a6c6e25c Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Thu, 20 Nov 2014 14:28:11 -0500
> > Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.
> 
> > commit f6dd295381f4b6a66acddacf46bca8940586c8d8
> > "dpci: replace tasklet with softirq" used the 'masked' as an
> > two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
> > between 'raise_softirq_for' and 'dpci_softirq' to determine whether
> > the 'struct hvm_pirq_dpci' can be re-scheduled.
> 
> <SNIP>
> 
> Hi Konrad,
> 
> Is this patch supposed to replace both the previous ones ?

Yes.
> 
> --
> Sander
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 20:31:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 20:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrYOP-00019L-LA; Thu, 20 Nov 2014 20:31:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrYOO-00019C-DJ
	for xen-devel@lists.xenproject.org; Thu, 20 Nov 2014 20:31:52 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	C0/0F-09284-7BF4E645; Thu, 20 Nov 2014 20:31:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416515509!12853007!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7952 invoked from network); 20 Nov 2014 20:31:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 20:31:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKKVhJe023322
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 20:31:43 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKVTHj004811
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 20:31:38 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKKVT1g029256; Thu, 20 Nov 2014 20:31:29 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 12:31:29 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 67B651186BF; Thu, 20 Nov 2014 15:31:27 -0500 (EST)
Date: Thu, 20 Nov 2014 15:31:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141120203127.GK31889@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<1131707258.20141120211830@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1131707258.20141120211830@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 09:18:30PM +0100, Sander Eikelenboom wrote:
> 
> Thursday, November 20, 2014, 8:51:33 PM, you wrote:
> 
> > Ah crud.
> 
> > So a simple fix could be to seperate the 'state' to only deal with the
> > raise_softirq and softirq_dpci. And then add a new (old) 'masked' to
> > deal between hvm_dirq_assist, pt_irq_guest_eoi and hvm_do_IRQ_dpci.
> 
> 
> > From 94a98e20a8ab721a58788919f92e3524a6c6e25c Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Thu, 20 Nov 2014 14:28:11 -0500
> > Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.
> 
> > commit f6dd295381f4b6a66acddacf46bca8940586c8d8
> > "dpci: replace tasklet with softirq" used the 'masked' as an
> > two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
> > between 'raise_softirq_for' and 'dpci_softirq' to determine whether
> > the 'struct hvm_pirq_dpci' can be re-scheduled.
> 
> <SNIP>
> 
> Hi Konrad,
> 
> Is this patch supposed to replace both the previous ones ?

Yes.
> 
> --
> Sander
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 21:30:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 21:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrZIP-00029S-EU; Thu, 20 Nov 2014 21:29:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrZIN-000294-LH
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 21:29:43 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	7F/DE-27623-64D5E645; Thu, 20 Nov 2014 21:29:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416518980!12806053!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20816 invoked from network); 20 Nov 2014 21:29:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 21:29:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKLTXR1031918
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 21:29:33 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKLTWvC006223
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 21:29:32 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKLTVJ2025041; Thu, 20 Nov 2014 21:29:31 GMT
Received: from ovs105.us.oracle.com (/10.149.76.205)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 13:29:31 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
Date: Thu, 20 Nov 2014 16:27:34 -0500
Message-Id: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller bitmap
	into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 parsing bitmap objects JSON parser will create libxl_bitmap
map of the smallest size needed.

This can cause problems when saved image file specifies CPU affinity.
For example, if 'vcpu_hard_affinity' in the saved image has only the
first CPU specified, just a single byte will be allocated and
libxl_bitmap->size will be set to 1.

This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
since the destination bitmap is created for maximum number of CPUs.

We could allocate that bitmap of the same size as the source, however,
it is later passed to xc_vcpu_setaffinity() which expects it to be
sized to the max number of CPUs

Instead, we should allow copying the (smaller) bitmap read by the parser
and keep the rest of bytes in the destination map unmodified (zero in
this case)

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/libxl/libxl.c       |    4 ++--
 tools/libxl/libxl_utils.c |    7 +++++++
 tools/libxl/libxl_utils.h |    2 ++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..84fd2ca 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5319,7 +5319,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
+        libxl_bitmap_copy_partial(ctx, &hard, cpumap_hard);
         flags = XEN_VCPUAFFINITY_HARD;
     }
     if (cpumap_soft) {
@@ -5327,7 +5327,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
+        libxl_bitmap_copy_partial(ctx, &soft, cpumap_soft);
         flags |= XEN_VCPUAFFINITY_SOFT;
     }
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 58df4f3..2a08bef 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
     memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
 }
 
+void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
+                               const libxl_bitmap *sptr)
+{
+    assert(dptr->size >= sptr->size);
+    memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
+}
+
 void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
                              libxl_bitmap *dptr,
                              const libxl_bitmap *sptr)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 117b229..d4d0a51 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -80,6 +80,8 @@ void libxl_bitmap_copy_alloc(libxl_ctx *ctx, libxl_bitmap *dptr,
                              const libxl_bitmap *sptr);
 void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
                        const libxl_bitmap *sptr);
+void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
+                               const libxl_bitmap *sptr);
 int libxl_bitmap_is_full(const libxl_bitmap *bitmap);
 int libxl_bitmap_is_empty(const libxl_bitmap *bitmap);
 int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 20 21:30:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Nov 2014 21:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrZIP-00029S-EU; Thu, 20 Nov 2014 21:29:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrZIN-000294-LH
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 21:29:43 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	7F/DE-27623-64D5E645; Thu, 20 Nov 2014 21:29:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416518980!12806053!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20816 invoked from network); 20 Nov 2014 21:29:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2014 21:29:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAKLTXR1031918
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Nov 2014 21:29:33 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKLTWvC006223
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 20 Nov 2014 21:29:32 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAKLTVJ2025041; Thu, 20 Nov 2014 21:29:31 GMT
Received: from ovs105.us.oracle.com (/10.149.76.205)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Nov 2014 13:29:31 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
Date: Thu, 20 Nov 2014 16:27:34 -0500
Message-Id: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller bitmap
	into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 parsing bitmap objects JSON parser will create libxl_bitmap
map of the smallest size needed.

This can cause problems when saved image file specifies CPU affinity.
For example, if 'vcpu_hard_affinity' in the saved image has only the
first CPU specified, just a single byte will be allocated and
libxl_bitmap->size will be set to 1.

This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
since the destination bitmap is created for maximum number of CPUs.

We could allocate that bitmap of the same size as the source, however,
it is later passed to xc_vcpu_setaffinity() which expects it to be
sized to the max number of CPUs

Instead, we should allow copying the (smaller) bitmap read by the parser
and keep the rest of bytes in the destination map unmodified (zero in
this case)

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/libxl/libxl.c       |    4 ++--
 tools/libxl/libxl_utils.c |    7 +++++++
 tools/libxl/libxl_utils.h |    2 ++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..84fd2ca 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5319,7 +5319,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
+        libxl_bitmap_copy_partial(ctx, &hard, cpumap_hard);
         flags = XEN_VCPUAFFINITY_HARD;
     }
     if (cpumap_soft) {
@@ -5327,7 +5327,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
+        libxl_bitmap_copy_partial(ctx, &soft, cpumap_soft);
         flags |= XEN_VCPUAFFINITY_SOFT;
     }
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 58df4f3..2a08bef 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
     memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
 }
 
+void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
+                               const libxl_bitmap *sptr)
+{
+    assert(dptr->size >= sptr->size);
+    memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
+}
+
 void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
                              libxl_bitmap *dptr,
                              const libxl_bitmap *sptr)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 117b229..d4d0a51 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -80,6 +80,8 @@ void libxl_bitmap_copy_alloc(libxl_ctx *ctx, libxl_bitmap *dptr,
                              const libxl_bitmap *sptr);
 void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
                        const libxl_bitmap *sptr);
+void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
+                               const libxl_bitmap *sptr);
 int libxl_bitmap_is_full(const libxl_bitmap *bitmap);
 int libxl_bitmap_is_empty(const libxl_bitmap *bitmap);
 int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 00:33:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 00:33:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrc9w-0004q9-T4; Fri, 21 Nov 2014 00:33:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xrc9v-0004q4-8O
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 00:33:11 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	EE/97-18267-6488E645; Fri, 21 Nov 2014 00:33:10 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416529989!12824963!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27950 invoked from network); 21 Nov 2014 00:33:09 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-31.messagelabs.com with SMTP;
	21 Nov 2014 00:33:09 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 20 Nov 2014 16:30:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,426,1413270000"; d="scan'208";a="640835941"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by orsmga002.jf.intel.com with ESMTP; 20 Nov 2014 16:32:54 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 21 Nov 2014 08:32:53 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Fri, 21 Nov 2014 08:32:53 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
	guest memory is out of reserved device memory maps
Thread-Index: AQHP/l8LtnOoOMCxBUyde78SnbhphJxnpV8ggAF+RLD//4qpgIAAjifggABlnHD//9dPAIAAzyog
Date: Fri, 21 Nov 2014 00:32:52 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FC607@SHSMSX101.ccr.corp.intel.com>
References: <5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
	<546DAE8F020000780004930A@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
	<20141120201104.GC31889@laptop.dumpdata.com>
In-Reply-To: <20141120201104.GC31889@laptop.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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Chen,
	Tiejun" <tiejun.chen@intel.com>, "tim@xen.org" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, November 21, 2014 4:11 AM
> 
> > Jan are you OK with this? In previous approach we reserved all the
> > RMRR regions so hotplug scenario is covered automatically. Now since
> > we want to do BDF specific filtering, this new interface is actually
> > necessary for hotplug support. If OK, Tiejun will send out a new
> > series to see whether it's ready for 4.5 check-in.
> 
> Could you also drop the 'RFC' part please? And please do mention in your
> cover letter how to reproduce the initial bug (perhaps a pointer to
> the hardware and software that this affects?)
> 

good suggestion. will do.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 00:33:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 00:33:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrc9w-0004q9-T4; Fri, 21 Nov 2014 00:33:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xrc9v-0004q4-8O
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 00:33:11 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	EE/97-18267-6488E645; Fri, 21 Nov 2014 00:33:10 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416529989!12824963!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27950 invoked from network); 21 Nov 2014 00:33:09 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-31.messagelabs.com with SMTP;
	21 Nov 2014 00:33:09 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 20 Nov 2014 16:30:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,426,1413270000"; d="scan'208";a="640835941"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by orsmga002.jf.intel.com with ESMTP; 20 Nov 2014 16:32:54 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 21 Nov 2014 08:32:53 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Fri, 21 Nov 2014 08:32:53 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
	guest memory is out of reserved device memory maps
Thread-Index: AQHP/l8LtnOoOMCxBUyde78SnbhphJxnpV8ggAF+RLD//4qpgIAAjifggABlnHD//9dPAIAAzyog
Date: Fri, 21 Nov 2014 00:32:52 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FC607@SHSMSX101.ccr.corp.intel.com>
References: <5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
	<5463302F0200007800046AF8@mail.emea.novell.com>
	<546324AC.1010306@intel.com>
	<54633CF90200007800046B44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FB4CF@SHSMSX101.ccr.corp.intel.com>
	<546DAE8F020000780004930A@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FBDA9@SHSMSX101.ccr.corp.intel.com>
	<20141120201104.GC31889@laptop.dumpdata.com>
In-Reply-To: <20141120201104.GC31889@laptop.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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Chen,
	Tiejun" <tiejun.chen@intel.com>, "tim@xen.org" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, November 21, 2014 4:11 AM
> 
> > Jan are you OK with this? In previous approach we reserved all the
> > RMRR regions so hotplug scenario is covered automatically. Now since
> > we want to do BDF specific filtering, this new interface is actually
> > necessary for hotplug support. If OK, Tiejun will send out a new
> > series to see whether it's ready for 4.5 check-in.
> 
> Could you also drop the 'RFC' part please? And please do mention in your
> cover letter how to reproduce the initial bug (perhaps a pointer to
> the hardware and software that this affects?)
> 

good suggestion. will do.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 01:00:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 01:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrcZg-00059O-Fr; Fri, 21 Nov 2014 00:59:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1XrcZf-00059J-Cg
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 00:59:47 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	07/65-02697-28E8E645; Fri, 21 Nov 2014 00:59:46 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416531584!12544392!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9132 invoked from network); 21 Nov 2014 00:59:45 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-206.messagelabs.com with SMTP;
	21 Nov 2014 00:59:45 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 20 Nov 2014 16:59:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="419589713"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by FMSMGA003.fm.intel.com with ESMTP; 20 Nov 2014 16:49:59 -0800
Date: Fri, 21 Nov 2014 08:59:27 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141121005927.GC20252@pengc-linux.bj.intel.com>
References: <546DBB4D.9030100@citrix.com>
	<20141120101505.GB20252@pengc-linux.bj.intel.com>
	<546DC105.20803@citrix.com> <546DF8FC.6060404@citrix.com>
MIME-Version: 1.0
Content-Length: 4272
Content-Disposition: inline
In-Reply-To: <546DF8FC.6060404@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 Testing - Cache Monitoring Technology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Chao Peng <chao.p.peng@linux.intel.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCBOb3YgMjAsIDIwMTQgYXQgMDI6MjE6NDhQTSArMDAwMCwgQW5kcmV3IENvb3BlciB3
cm90ZToKPiBPbiAyMC8xMS8xNCAxMDoyMywgQW5kcmV3IENvb3BlciB3cm90ZToKPiA+IE9uIDIw
LzExLzE0IDEwOjE1LCBDaGFvIFBlbmcgd3JvdGU6Cj4gPj4gT24gVGh1LCBOb3YgMjAsIDIwMTQg
YXQgMDk6NTg6MzdBTSArMDAwMCwgQW5kcmV3IENvb3BlciB3cm90ZToKPiA+Pj4gSGksCj4gPj4+
Cj4gPj4+IEkgaGF2ZSBmb3VuZCBteXNlbGYgYSBQU1ItY2FwYWJsZSBzZXJ2ZXIgYW5kIGhhdmUg
YmVlbiBoYXZpbmcgYSBwbGF5Cj4gPj4+IHdpdGggWGVuLTQuNQo+ID4+Pgo+ID4+PiBBdCBhIGZp
cnN0IHBhc3MsIEkgY2FuIGdldCBzb21lIG51bWJlcnMgb3V0Ogo+ID4+Pgo+ID4+PiBbcm9vdEBi
bG9iIH5dIyB4bCBwc3ItY210LWF0dGFjaCAwCj4gPj4+IFtyb290QGJsb2Igfl0jIHhsIHBzci1j
bXQtc2hvdyBjYWNoZV9vY2N1cGFuY3kKPiA+Pj4gVG90YWwgUk1JRDogNzEKPiA+Pj4gTmFtZSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCAgICAgICAgU29ja2V0IDAg
ICAgICAgCj4gPj4+IFNvY2tldCAxCj4gPj4+IFRvdGFsIEwzIENhY2hlIFNpemUgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDQ2MDgwIEtCICAgICAgIAo+ID4+PiA0NjA4MCBLQgo+
ID4+PiBEb21haW4tMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAg
ICA0NTA3Mgo+ID4+PiBLQiAgICAgICAgICAgIDAgS0IKPiA+Pj4gW3Jvb3RAYmxvYiB+XSMKPiA+
Pj4KPiA+Pj4gSG93ZXZlciwgSSBhbSB1bmFibGUgdG8gZ2V0IGFueSBvY2N1cGFuY3kgaW5mb3Jt
YXRpb24gZm9yIEhWTSBndWVzdHMuIAo+ID4+PiBHaXZlbiBub3RoaW5nIG9idmlvdXMgaW4gdGhl
IGNvZGUgd2hpY2ggd291bGQgbWFrZSBDTVQgUFYtZ3Vlc3QKPiA+Pj4gc3BlY2lmaWMsIEkgcHJl
c3VtZSB0aGlzIGlzIHVuZXhwZWN0ZWQ/Cj4gPj4+Cj4gPj4+Cj4gPj4gVGhhbmsgeW91ciBmb3Ig
dHJ5aW5nLi4uCj4gPj4gQnV0IEkganVzdCB0ZXN0ZWQgdGhlIEhWTSBvbiBteSBib3ggYW5kIGl0
IHJ1bnMgY29ycmVjdC4KPiA+Pgo+ID4+IEhhdmUgeW91IG1pc3NlZCB0byBydW4gcHNyLWNtdC1h
dHRhY2ggZm9yIHlvdXIgSFZNIGRvbWFpbj8gT3RoZXJ3aXNlIEkKPiA+PiB0aGluayB0aGVyZSBt
YXkgYmUgc29tZXRoaW5nIHdyb25nLgo+ID4gTm8gLSBJIGdldCB0aGUgSFZNIGRvbWFpbiAoYSBt
ZW10ZXN0IGRvbWFpbikgbGlzdGVkIGluIHRoZSBvdXRwdXQuICBJdAo+ID4gaXMgY2xlYXIgZnJv
bSBEb20wJ3Mgb2NjdXBhbmN5IGRyb3BwaW5nIG9mZiBzaWduaWZpY2FudGx5IHRoYXQKPiA+IGNv
bXBldGl0aW9uIGlzIHVuZGVyd2F5IG9uIFNvY2tldCAwIChhcyBleHBlY3RlZCksIGJ1dCB0aGUg
ZG9tYWluIGFsd2F5cwo+ID4gaGFzIDAgb2NjdXBhbmN5IHJlcG9ydGVkLgo+ID4KPiA+IEkgc2hh
bGwgaW52ZXN0aWdhdGUuCj4gCj4gT24gZnVydGhlciBpbnZlc3RpZ2F0aW9uLCBpdCB3b3VsZCBh
cHBlYXIgdG8gYmUgYSBiZWhhdmlvdXJhbCBwcm9wZXJ0eQo+IG9mIG1lbXRlc3QgKDUuMDEsIDh2
Y3B1IGd1ZXN0LCAxR0IgUkFNKS4KPiAKPiBJbiBTTVAgbW9kZSB3aXRoIGFsbCBjcHVzIHN0cmVh
bWluZyBkYXRhLCB0aGUgb2NjdXBhbmN5IHNreXJvY2tldHMuIAo+IEhvd2V2ZXIsIHdoZW4gb25s
eSBjcHUwIGlzIHJ1bm5pbmcgKHdpdGggYWxsIG90aGVyIGNwdXMgd2FpdGluZyB1bnRpbAo+IHRo
ZSBlbmQgb2YgdGhlIHJvdW5kKSwgdGhlIG9jY3VwYW5jeSBkcm9wcyB0byAwLgo+IAo+IE9uIHRo
aXMgc3lzdGVtLCBpdCB3b3VsZCBhcHBlYXIgdGhhdCB0aGUgbWluaW11bSBncmFudWxhcml0eSBp
cyA3MktCLAo+IGFuZCA3MktCIGlzIG9jY2FzaW9uYWxseSByZXBvcnRlZCByYXRoZXIgdGhhbiAw
LiAgSSBhbSBndWVzc2luZyB0aGF0Cj4gd2hlbiBvbmx5IGEgc2luZ2xlIGNwdSBpcyBydW5uaW5n
LCB0aGUgb2NjdXBhbmN5IGlzIGxlc3MgdGhhbiB0aGUKPiBncmFudWxhcml0eSwgYW5kIHRoZSAw
IGJlaW5nIHJlcG9ydGVkIGlzIGFzIGEgcmVzdWx0IG9mIHJvdW5kaW5nLgoKVGhpcyBpcyBwcm9i
YWJseSB0aGUgcmVhc29uIGFuZCB0aGUgbWluaW11bSBncmFudWxhcml0eSBkb2VzIGV4aXN0LiAK
QXMgdGhlIGhhcmR3YXJlIHVuZGVyZ3JvdW5kIGp1c3QgdGFncyB0aGUgY2FjaGUgd2F5cyB3aXRo
IFJNSUQuIFNvIHRoZQpncmFudWxhcml0eSBzaG91bGQgYmUgYXQgbGVhc2UgdGhlIGNhY2hlIHdh
eSBzaXplLgo+IAo+IEl0IGlzIGludGVyZXN0aW5nIHRvIG5vdGUgdGhhdCB3aXRoIGRvbTAgb25s
eSwgZG9tMCdzIG9jY3VwYW5jeSBpcwo+IGFsbW9zdCBhbGwgb2YgdGhlIExMQywgYnV0IHdpdGgg
dGhpcyBzaW5nbGUgbWVtdGVzdCBkb21VLCB0aGUKPiBvY2N1cGFuY2llcyBvZiBkb20wICsgZG9t
VSBpcyBuZXZlciBtb3JlIHRoYW4gMS80IG9mIHRoZSBMTEMuICBJIHByZXN1bWUKPiB0aGF0IHRo
aXMgbWVhbnMgdGhhdCBjb3Bpb3VzIGNhY2hlIGZsdXNoaW5nIGlzIGdvaW5nIG9uLgo+IApJIHNh
dyB0aGUgc2FtZSByZXN1bHQgc29tZXRpbWVzLiBBY3R1YWxseSB0aGUgZGF0YSB2YXJpZXMgZm9y
IGRpZmZlcmVudAp0eXBlcyBvZiB3b3JrbG9hZHMuIFNvbWV0aW1lcyB0aGUgZGF0YSBzdXJwcmlz
ZXMgbWUgYnV0IHVzdWFsbHkgaXQgbG9va3MKcmVhc29uYWJsZS4gQW5kIHRoaXMgaXMgdGhlIGlu
dGVyZXN0aW5nIHRoaW5nIHRoZSBDTVQgYnJpbmcgdG8gbWUuIEluCnRoZSBwYXN0LCB3ZSBqdXN0
IKGuZ3Vlc3OhryB0aGUgY2FjaGUgdXRpbGl6YXRpb24gYnV0IG5vdyB3ZSBjYW4goa5zZWWhryBp
dC4KCkNoYW8KPiAKPiBXaGF0ZXZlciB0aGUgcmVhc29uLCBpdCBoYXMgYmVlbiBpbnRlcmVzdGlu
ZyBoYXZpbmcgYSBiaXQgb2YgYSBwbGF5LiBJdAo+IGRvZXMgYXBwZWFyIHRoYXQgUFNSIGFuZCBD
TVQgSnVzdFdvcmtlZCh0bSkgZm9yIG1lIG9uIFhlbi00LjUgd2hpY2ggaXMKPiB2ZXJ5IG5pY2Uu
Cj4gCj4gfkFuZHJldwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Nov 21 01:00:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 01:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrcZg-00059O-Fr; Fri, 21 Nov 2014 00:59:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1XrcZf-00059J-Cg
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 00:59:47 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	07/65-02697-28E8E645; Fri, 21 Nov 2014 00:59:46 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416531584!12544392!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9132 invoked from network); 21 Nov 2014 00:59:45 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-206.messagelabs.com with SMTP;
	21 Nov 2014 00:59:45 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 20 Nov 2014 16:59:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="419589713"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by FMSMGA003.fm.intel.com with ESMTP; 20 Nov 2014 16:49:59 -0800
Date: Fri, 21 Nov 2014 08:59:27 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141121005927.GC20252@pengc-linux.bj.intel.com>
References: <546DBB4D.9030100@citrix.com>
	<20141120101505.GB20252@pengc-linux.bj.intel.com>
	<546DC105.20803@citrix.com> <546DF8FC.6060404@citrix.com>
MIME-Version: 1.0
Content-Length: 4272
Content-Disposition: inline
In-Reply-To: <546DF8FC.6060404@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 Testing - Cache Monitoring Technology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Chao Peng <chao.p.peng@linux.intel.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCBOb3YgMjAsIDIwMTQgYXQgMDI6MjE6NDhQTSArMDAwMCwgQW5kcmV3IENvb3BlciB3
cm90ZToKPiBPbiAyMC8xMS8xNCAxMDoyMywgQW5kcmV3IENvb3BlciB3cm90ZToKPiA+IE9uIDIw
LzExLzE0IDEwOjE1LCBDaGFvIFBlbmcgd3JvdGU6Cj4gPj4gT24gVGh1LCBOb3YgMjAsIDIwMTQg
YXQgMDk6NTg6MzdBTSArMDAwMCwgQW5kcmV3IENvb3BlciB3cm90ZToKPiA+Pj4gSGksCj4gPj4+
Cj4gPj4+IEkgaGF2ZSBmb3VuZCBteXNlbGYgYSBQU1ItY2FwYWJsZSBzZXJ2ZXIgYW5kIGhhdmUg
YmVlbiBoYXZpbmcgYSBwbGF5Cj4gPj4+IHdpdGggWGVuLTQuNQo+ID4+Pgo+ID4+PiBBdCBhIGZp
cnN0IHBhc3MsIEkgY2FuIGdldCBzb21lIG51bWJlcnMgb3V0Ogo+ID4+Pgo+ID4+PiBbcm9vdEBi
bG9iIH5dIyB4bCBwc3ItY210LWF0dGFjaCAwCj4gPj4+IFtyb290QGJsb2Igfl0jIHhsIHBzci1j
bXQtc2hvdyBjYWNoZV9vY2N1cGFuY3kKPiA+Pj4gVG90YWwgUk1JRDogNzEKPiA+Pj4gTmFtZSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCAgICAgICAgU29ja2V0IDAg
ICAgICAgCj4gPj4+IFNvY2tldCAxCj4gPj4+IFRvdGFsIEwzIENhY2hlIFNpemUgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDQ2MDgwIEtCICAgICAgIAo+ID4+PiA0NjA4MCBLQgo+
ID4+PiBEb21haW4tMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAg
ICA0NTA3Mgo+ID4+PiBLQiAgICAgICAgICAgIDAgS0IKPiA+Pj4gW3Jvb3RAYmxvYiB+XSMKPiA+
Pj4KPiA+Pj4gSG93ZXZlciwgSSBhbSB1bmFibGUgdG8gZ2V0IGFueSBvY2N1cGFuY3kgaW5mb3Jt
YXRpb24gZm9yIEhWTSBndWVzdHMuIAo+ID4+PiBHaXZlbiBub3RoaW5nIG9idmlvdXMgaW4gdGhl
IGNvZGUgd2hpY2ggd291bGQgbWFrZSBDTVQgUFYtZ3Vlc3QKPiA+Pj4gc3BlY2lmaWMsIEkgcHJl
c3VtZSB0aGlzIGlzIHVuZXhwZWN0ZWQ/Cj4gPj4+Cj4gPj4+Cj4gPj4gVGhhbmsgeW91ciBmb3Ig
dHJ5aW5nLi4uCj4gPj4gQnV0IEkganVzdCB0ZXN0ZWQgdGhlIEhWTSBvbiBteSBib3ggYW5kIGl0
IHJ1bnMgY29ycmVjdC4KPiA+Pgo+ID4+IEhhdmUgeW91IG1pc3NlZCB0byBydW4gcHNyLWNtdC1h
dHRhY2ggZm9yIHlvdXIgSFZNIGRvbWFpbj8gT3RoZXJ3aXNlIEkKPiA+PiB0aGluayB0aGVyZSBt
YXkgYmUgc29tZXRoaW5nIHdyb25nLgo+ID4gTm8gLSBJIGdldCB0aGUgSFZNIGRvbWFpbiAoYSBt
ZW10ZXN0IGRvbWFpbikgbGlzdGVkIGluIHRoZSBvdXRwdXQuICBJdAo+ID4gaXMgY2xlYXIgZnJv
bSBEb20wJ3Mgb2NjdXBhbmN5IGRyb3BwaW5nIG9mZiBzaWduaWZpY2FudGx5IHRoYXQKPiA+IGNv
bXBldGl0aW9uIGlzIHVuZGVyd2F5IG9uIFNvY2tldCAwIChhcyBleHBlY3RlZCksIGJ1dCB0aGUg
ZG9tYWluIGFsd2F5cwo+ID4gaGFzIDAgb2NjdXBhbmN5IHJlcG9ydGVkLgo+ID4KPiA+IEkgc2hh
bGwgaW52ZXN0aWdhdGUuCj4gCj4gT24gZnVydGhlciBpbnZlc3RpZ2F0aW9uLCBpdCB3b3VsZCBh
cHBlYXIgdG8gYmUgYSBiZWhhdmlvdXJhbCBwcm9wZXJ0eQo+IG9mIG1lbXRlc3QgKDUuMDEsIDh2
Y3B1IGd1ZXN0LCAxR0IgUkFNKS4KPiAKPiBJbiBTTVAgbW9kZSB3aXRoIGFsbCBjcHVzIHN0cmVh
bWluZyBkYXRhLCB0aGUgb2NjdXBhbmN5IHNreXJvY2tldHMuIAo+IEhvd2V2ZXIsIHdoZW4gb25s
eSBjcHUwIGlzIHJ1bm5pbmcgKHdpdGggYWxsIG90aGVyIGNwdXMgd2FpdGluZyB1bnRpbAo+IHRo
ZSBlbmQgb2YgdGhlIHJvdW5kKSwgdGhlIG9jY3VwYW5jeSBkcm9wcyB0byAwLgo+IAo+IE9uIHRo
aXMgc3lzdGVtLCBpdCB3b3VsZCBhcHBlYXIgdGhhdCB0aGUgbWluaW11bSBncmFudWxhcml0eSBp
cyA3MktCLAo+IGFuZCA3MktCIGlzIG9jY2FzaW9uYWxseSByZXBvcnRlZCByYXRoZXIgdGhhbiAw
LiAgSSBhbSBndWVzc2luZyB0aGF0Cj4gd2hlbiBvbmx5IGEgc2luZ2xlIGNwdSBpcyBydW5uaW5n
LCB0aGUgb2NjdXBhbmN5IGlzIGxlc3MgdGhhbiB0aGUKPiBncmFudWxhcml0eSwgYW5kIHRoZSAw
IGJlaW5nIHJlcG9ydGVkIGlzIGFzIGEgcmVzdWx0IG9mIHJvdW5kaW5nLgoKVGhpcyBpcyBwcm9i
YWJseSB0aGUgcmVhc29uIGFuZCB0aGUgbWluaW11bSBncmFudWxhcml0eSBkb2VzIGV4aXN0LiAK
QXMgdGhlIGhhcmR3YXJlIHVuZGVyZ3JvdW5kIGp1c3QgdGFncyB0aGUgY2FjaGUgd2F5cyB3aXRo
IFJNSUQuIFNvIHRoZQpncmFudWxhcml0eSBzaG91bGQgYmUgYXQgbGVhc2UgdGhlIGNhY2hlIHdh
eSBzaXplLgo+IAo+IEl0IGlzIGludGVyZXN0aW5nIHRvIG5vdGUgdGhhdCB3aXRoIGRvbTAgb25s
eSwgZG9tMCdzIG9jY3VwYW5jeSBpcwo+IGFsbW9zdCBhbGwgb2YgdGhlIExMQywgYnV0IHdpdGgg
dGhpcyBzaW5nbGUgbWVtdGVzdCBkb21VLCB0aGUKPiBvY2N1cGFuY2llcyBvZiBkb20wICsgZG9t
VSBpcyBuZXZlciBtb3JlIHRoYW4gMS80IG9mIHRoZSBMTEMuICBJIHByZXN1bWUKPiB0aGF0IHRo
aXMgbWVhbnMgdGhhdCBjb3Bpb3VzIGNhY2hlIGZsdXNoaW5nIGlzIGdvaW5nIG9uLgo+IApJIHNh
dyB0aGUgc2FtZSByZXN1bHQgc29tZXRpbWVzLiBBY3R1YWxseSB0aGUgZGF0YSB2YXJpZXMgZm9y
IGRpZmZlcmVudAp0eXBlcyBvZiB3b3JrbG9hZHMuIFNvbWV0aW1lcyB0aGUgZGF0YSBzdXJwcmlz
ZXMgbWUgYnV0IHVzdWFsbHkgaXQgbG9va3MKcmVhc29uYWJsZS4gQW5kIHRoaXMgaXMgdGhlIGlu
dGVyZXN0aW5nIHRoaW5nIHRoZSBDTVQgYnJpbmcgdG8gbWUuIEluCnRoZSBwYXN0LCB3ZSBqdXN0
IKGuZ3Vlc3OhryB0aGUgY2FjaGUgdXRpbGl6YXRpb24gYnV0IG5vdyB3ZSBjYW4goa5zZWWhryBp
dC4KCkNoYW8KPiAKPiBXaGF0ZXZlciB0aGUgcmVhc29uLCBpdCBoYXMgYmVlbiBpbnRlcmVzdGlu
ZyBoYXZpbmcgYSBiaXQgb2YgYSBwbGF5LiBJdAo+IGRvZXMgYXBwZWFyIHRoYXQgUFNSIGFuZCBD
TVQgSnVzdFdvcmtlZCh0bSkgZm9yIG1lIG9uIFhlbi00LjUgd2hpY2ggaXMKPiB2ZXJ5IG5pY2Uu
Cj4gCj4gfkFuZHJldwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Nov 21 03:14:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 03:14:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xref7-0002Qt-Nk; Fri, 21 Nov 2014 03:13:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gedalya@gedalya.net>) id 1Xref6-0002Qo-7u
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 03:13:32 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	8B/B6-23865-BDDAE645; Fri, 21 Nov 2014 03:13:31 +0000
X-Env-Sender: gedalya@gedalya.net
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416539609!8413200!1
X-Originating-IP: [47.21.139.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1430 invoked from network); 21 Nov 2014 03:13:29 -0000
Received: from mail.gedalya.net (HELO mail.gedalya.net) (47.21.139.35)
	by server-6.tower-31.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Nov 2014 03:13:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gedalya.net;
	s=rsa1; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=Ict3Xlc8gINRVQkC4BTvlDM3Qy9e8eY1vaBCNkggUgY=; 
	b=bud2oX4uuxa4OPULTyxHoACo/4MC/hkBYw/OW/uyoBS4IArzM91PVbhhlWULrdiwYtJZYZYNJR02b2MQ3sf9Grxe1DzXS4vGbWifvvajP6YRnhazPGopY+hu3cWYFCn/3u5B3YMXB7PP47y2srJ2FJUb5WWN8eUWFxy+mUesAfKI3O5iZ+Qb9pATAZclD9kLwkvJyrMhnVIrmod02jyE/iXOZE/ANO3OV3jkrL2h/gCEbUEsEfxxvyV9Ws5jPfjx5FLbma88EJ5k38GjT5TNy2xCCSfBMfBCdYC4twnUIlkPtwIQEC7HB9XwcmhOmvbMywz2Jtg3DdLLyX509chzGg==;
Received: from [192.168.9.10] by mail.gedalya.net with esmtpsa
	(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84)
	(envelope-from <gedalya@gedalya.net>)
	id 1Xreeu-0000gm-Un; Thu, 20 Nov 2014 22:13:20 -0500
Message-ID: <546EADD0.8010002@gedalya.net>
Date: Thu, 20 Nov 2014 22:13:20 -0500
From: Gedalya <gedalya@gedalya.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Ian Campbell <ian.campbell@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120202114.GE31889@laptop.dumpdata.com>
In-Reply-To: <20141120202114.GE31889@laptop.dumpdata.com>
Cc: wei.liu2@citrix.com, 767295@bugs.debian.org, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 03:21 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
>> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
>> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
>> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
>> up leaked.
>>
>> The memory pool currently supports mmap'd buffers as well as a directly
>> allocated buffers, however the try decode routines make use of realloc and do
>> not fit well into this model. Introduce a concept of an external memory block
>> to the memory pool and provide an interface to register such memory.
>>
>> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
>> mmap_ prefix since they are now also used for external memory blocks.
>>
>> We are only seeing this now because the gzip decoder doesn't leak and it's only
>> relatively recently that kernels in the wild have switched to better
>> compression.
>>
>> This is https://bugs.debian.org/767295
>>
>> Reported by: Gedalya <gedalya@gedalya.net>
> Gedelya,
>
> Could you also test this patch to make sure it does fix the
> reported issue please?

So here's what happens now.
1. Starts up tiny
2. reboot: leak
3. reboot: freed (process larger, but the delta is all/mostly shared pages)
4. reboot: leak
5. reboot: freed
etc..

root@xen:~/xen-pkgs# xl cr /etc/xen/auto/asterisk_deb80.cfg
Parsing config from /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
root     22981  0.0  0.0  95968   588 ?        SLsl 21:55   0:00 
/usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# pmap -x 22981
22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     144     128       0 r-x-- xl
0000000000623000       4       4       4 r---- xl
0000000000624000       8       8       8 rw--- xl
0000000000626000       4       4       4 rw---   [ anon ]
00000000009a6000     288     240     240 rw---   [ anon ]
00007f14d4000000     132       8       8 rw---   [ anon ]
00007f14d4021000   65404       0       0 -----   [ anon ]
<< snip >>
---------------- ------- ------- -------
total kB           95968    2728     596

--- reboot domu ---

root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
root     22981  0.6  3.3 131652 20008 ?        SLsl 21:55   0:00 
/usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# pmap -x 22981
22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     144     144       0 r-x-- xl
0000000000623000       4       4       4 r---- xl
0000000000624000       8       8       8 rw--- xl
0000000000626000       4       4       4 rw---   [ anon ]
00000000009a6000     288     288     288 rw---   [ anon ]
00000000009ee000   35676   16772   16772 rw---   [ anon ]
00007f14d4000000     132       8       8 rw---   [ anon ]
00007f14d4021000   65404       0       0 -----   [ anon ]
00007f14d9ae0000     104     100       0 r-x-- libz.so.1.2.8
<< snip >>
---------------- ------- ------- -------
total kB          131652   20072   17424

--- reboot domu ---

root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
root     22981  0.5  0.5  95876  3136 ?        SLsl 21:55   0:01 
/usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# pmap -x 22981
22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     144     144       0 r-x-- xl
0000000000623000       4       4       4 r---- xl
0000000000624000       8       8       8 rw--- xl
0000000000626000       4       4       4 rw---   [ anon ]
00000000009a6000     188     188     188 rw---   [ anon ]
00007f14d4000000     132       8       8 rw---   [ anon ]
00007f14d4021000   65404       0       0 -----   [ anon ]
00007f14d9ae0000     104     100       0 r-x-- libz.so.1.2.8
<< snip >>
---------------- ------- ------- -------
total kB           95876    3200     552

--- reboot domu ---

root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
root     22981  0.6  3.4 134660 20548 ?        SLsl 21:55   0:02 
/usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# pmap -x 22981
22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     144     144       0 r-x-- xl
0000000000623000       4       4       4 r---- xl
0000000000624000       8       8       8 rw--- xl
0000000000626000       4       4       4 rw---   [ anon ]
00000000009a6000     188     188     188 rw---   [ anon ]
00000000009d5000   38784   17348   17348 rw---   [ anon ]
00007f14d4000000     132       8       8 rw---   [ anon ]
00007f14d4021000   65404       0       0 -----   [ anon ]
00007f14d9ae0000     104     100       0 r-x-- libz.so.1.2.8
<< snip >>
---------------- ------- ------- -------
total kB          134660   20548   17900

--- reboot domu ---

root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
root     22981  0.6  0.5  95876  3200 ?        SLsl 21:55   0:03 
/usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# pmap -x 22981
22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     144     144       0 r-x-- xl
0000000000623000       4       4       4 r---- xl
0000000000624000       8       8       8 rw--- xl
0000000000626000       4       4       4 rw---   [ anon ]
00000000009a6000     188     188     188 rw---   [ anon ]
00007f14d4000000     132       8       8 rw---   [ anon ]
00007f14d4021000   65404       0       0 -----   [ anon ]
00007f14d9ae0000     104     100       0 r-x-- libz.so.1.2.8
<< snip >>
---------------- ------- ------- -------
total kB           95876    3200     552




Tried valgrind, it doesn't look like it was able to see what was going on

root@xen:~# valgrind --leak-check=full xl cr -F 
/etc/xen/auto/asterisk_deb80.cfg
==24967== Memcheck, a memory error detector
==24967== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==24967== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==24967== Command: /usr/sbin/xl cr -F /etc/xen/auto/asterisk_deb80.cfg
==24967==
==24971==
==24971== HEAP SUMMARY:
==24971==     in use at exit: 11,695 bytes in 41 blocks
==24971==   total heap usage: 75 allocs, 34 frees, 44,602 bytes allocated
==24971==
==24971== LEAK SUMMARY:
==24971==    definitely lost: 0 bytes in 0 blocks
==24971==    indirectly lost: 0 bytes in 0 blocks
==24971==      possibly lost: 0 bytes in 0 blocks
==24971==    still reachable: 11,695 bytes in 41 blocks
==24971==         suppressed: 0 bytes in 0 blocks
==24971== Reachable blocks (those to which a pointer was found) are not 
shown.
==24971== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24971==
==24971== For counts of detected and suppressed errors, rerun with: -v
==24971== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==24970==
==24970== HEAP SUMMARY:
==24970==     in use at exit: 10,743 bytes in 36 blocks
==24970==   total heap usage: 64 allocs, 28 frees, 35,289 bytes allocated
==24970==
==24970== LEAK SUMMARY:
==24970==    definitely lost: 0 bytes in 0 blocks
==24970==    indirectly lost: 0 bytes in 0 blocks
==24970==      possibly lost: 0 bytes in 0 blocks
==24970==    still reachable: 10,743 bytes in 36 blocks
==24970==         suppressed: 0 bytes in 0 blocks
==24970== Reachable blocks (those to which a pointer was found) are not 
shown.
==24970== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24970==
==24970== For counts of detected and suppressed errors, rerun with: -v
==24970== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==24975==
==24975== HEAP SUMMARY:
==24975==     in use at exit: 4,859 bytes in 43 blocks
==24975==   total heap usage: 92 allocs, 49 frees, 38,375 bytes allocated
==24975==
==24975== LEAK SUMMARY:
==24975==    definitely lost: 0 bytes in 0 blocks
==24975==    indirectly lost: 0 bytes in 0 blocks
==24975==      possibly lost: 0 bytes in 0 blocks
==24975==    still reachable: 4,859 bytes in 43 blocks
==24975==         suppressed: 0 bytes in 0 blocks
==24975== Reachable blocks (those to which a pointer was found) are not 
shown.
==24975== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24975==
==24975== For counts of detected and suppressed errors, rerun with: -v
==24975== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==24976==
==24976== HEAP SUMMARY:
==24976==     in use at exit: 13,066 bytes in 45 blocks
==24976==   total heap usage: 98 allocs, 53 frees, 48,704 bytes allocated
==24976==
==24976== LEAK SUMMARY:
==24976==    definitely lost: 0 bytes in 0 blocks
==24976==    indirectly lost: 0 bytes in 0 blocks
==24976==      possibly lost: 0 bytes in 0 blocks
==24976==    still reachable: 13,066 bytes in 45 blocks
==24976==         suppressed: 0 bytes in 0 blocks
==24976== Reachable blocks (those to which a pointer was found) are not 
shown.
==24976== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24976==
==24976== For counts of detected and suppressed errors, rerun with: -v
==24976== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==24969==
==24969== HEAP SUMMARY:
==24969==     in use at exit: 11,049 bytes in 42 blocks
==24969==   total heap usage: 92 allocs, 50 frees, 48,587 bytes allocated
==24969==
==24969== LEAK SUMMARY:
==24969==    definitely lost: 0 bytes in 0 blocks
==24969==    indirectly lost: 0 bytes in 0 blocks
==24969==      possibly lost: 0 bytes in 0 blocks
==24969==    still reachable: 11,049 bytes in 42 blocks
==24969==         suppressed: 0 bytes in 0 blocks
==24969== Reachable blocks (those to which a pointer was found) are not 
shown.
==24969== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24969==
==24969== For counts of detected and suppressed errors, rerun with: -v
==24969== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Parsing config from /etc/xen/auto/asterisk_deb80.cfg
Waiting for domain asterisk_deb80 (domid 31) to die [pid 24967]
Domain 31 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 31 needs to be cleaned up: destroying the domain
Done. Rebooting now
Waiting for domain asterisk_deb80 (domid 32) to die [pid 24967]
Domain 32 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 32 needs to be cleaned up: destroying the domain
Done. Rebooting now
Waiting for domain asterisk_deb80 (domid 33) to die [pid 24967]
Domain 33 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 33 needs to be cleaned up: destroying the domain
Done. Rebooting now
Waiting for domain asterisk_deb80 (domid 34) to die [pid 24967]
Domain 34 has shut down, reason code 0 0x0
Action for shutdown reason code 0 is destroy
Domain 34 needs to be cleaned up: destroying the domain
Done. Exiting now


>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> ---
>> v2: Correct handling in xc_try_lzo1x_decode.
>>
>> This is a bug fix and should go into 4.5.
>>
>> I have a sneaking suspicion this is going to need to backport a very long way...
>> ---
>>   tools/libxc/include/xc_dom.h        |   10 ++++--
>>   tools/libxc/xc_dom_bzimageloader.c  |   20 ++++++++++++
>>   tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
>>   tools/libxc/xc_dom_decompress_lz4.c |    5 +++
>>   4 files changed, 80 insertions(+), 16 deletions(-)
>>
>> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
>> index 6ae6a9f..07d7224 100644
>> --- a/tools/libxc/include/xc_dom.h
>> +++ b/tools/libxc/include/xc_dom.h
>> @@ -33,8 +33,13 @@ struct xc_dom_seg {
>>   
>>   struct xc_dom_mem {
>>       struct xc_dom_mem *next;
>> -    void *mmap_ptr;
>> -    size_t mmap_len;
>> +    void *ptr;
>> +    enum {
>> +        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
>> +        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
>> +        XC_DOM_MEM_TYPE_MMAP,
>> +    } type;
>> +    size_t len;
>>       unsigned char memory[0];
>>   };
>>   
>> @@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
>>   /* --- simple memory pool ------------------------------------------ */
>>   
>>   void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
>> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
>>   void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
>>   void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>>                               const char *filename, size_t * size,
>> diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
>> index 2225699..964ebdc 100644
>> --- a/tools/libxc/xc_dom_bzimageloader.c
>> +++ b/tools/libxc/xc_dom_bzimageloader.c
>> @@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
>>   
>>       total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
>>   
>> +    if ( xc_dom_register_external(dom, out_buf, total) )
>> +    {
>> +        DOMPRINTF("BZIP2: Error registering stream output");
>> +        free(out_buf);
>> +        goto bzip2_cleanup;
>> +    }
>> +
>>       DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
>>                 __FUNCTION__, *size, (long unsigned int) total);
>>   
>> @@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
>>           }
>>       }
>>   
>> +    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
>> +    {
>> +        DOMPRINTF("%s: Error registering stream output", what);
>> +        free(out_buf);
>> +        goto lzma_cleanup;
>> +    }
>> +
>>       DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
>>                 __FUNCTION__, what, *size, (size_t)stream->total_out);
>>   
>> @@ -464,7 +478,13 @@ static int xc_try_lzo1x_decode(
>>   
>>           dst_len = lzo_read_32(cur);
>>           if ( !dst_len )
>> +        {
>> +            msg = "Error registering stream output";
>> +            if ( xc_dom_register_external(dom, out_buf, out_len) )
>> +                break;
>> +
>>               return 0;
>> +        }
>>   
>>           if ( dst_len > LZOP_MAX_BLOCK_SIZE )
>>           {
>> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
>> index baa62a1..ecbf981 100644
>> --- a/tools/libxc/xc_dom_core.c
>> +++ b/tools/libxc/xc_dom_core.c
>> @@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
>>           return NULL;
>>       }
>>       memset(block, 0, sizeof(*block) + size);
>> +    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
>>       block->next = dom->memblocks;
>>       dom->memblocks = block;
>>       dom->alloc_malloc += sizeof(*block) + size;
>> @@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
>>           return NULL;
>>       }
>>       memset(block, 0, sizeof(*block));
>> -    block->mmap_len = size;
>> -    block->mmap_ptr = mmap(NULL, block->mmap_len,
>> -                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
>> -                           -1, 0);
>> -    if ( block->mmap_ptr == MAP_FAILED )
>> +    block->len = size;
>> +    block->ptr = mmap(NULL, block->len,
>> +                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
>> +                      -1, 0);
>> +    if ( block->ptr == MAP_FAILED )
>>       {
>>           DOMPRINTF("%s: mmap failed", __FUNCTION__);
>>           free(block);
>>           return NULL;
>>       }
>> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>>       block->next = dom->memblocks;
>>       dom->memblocks = block;
>>       dom->alloc_malloc += sizeof(*block);
>> -    dom->alloc_mem_map += block->mmap_len;
>> +    dom->alloc_mem_map += block->len;
>>       if ( size > (100 * 1024) )
>>           print_mem(dom, __FUNCTION__, size);
>> -    return block->mmap_ptr;
>> +    return block->ptr;
>> +}
>> +
>> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
>> +{
>> +    struct xc_dom_mem *block;
>> +
>> +    block = malloc(sizeof(*block));
>> +    if ( block == NULL )
>> +    {
>> +        DOMPRINTF("%s: allocation failed", __FUNCTION__);
>> +        return -1;
>> +    }
>> +    memset(block, 0, sizeof(*block));
>> +    block->ptr = ptr;
>> +    block->len = size;
>> +    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
>> +    block->next = dom->memblocks;
>> +    dom->memblocks = block;
>> +    dom->alloc_malloc += sizeof(*block);
>> +    dom->alloc_mem_map += block->len;
>> +    return 0;
>>   }
>>   
>>   void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>> @@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>>       }
>>   
>>       memset(block, 0, sizeof(*block));
>> -    block->mmap_len = *size;
>> -    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
>> +    block->len = *size;
>> +    block->ptr = mmap(NULL, block->len, PROT_READ,
>>                              MAP_SHARED, fd, 0);
>> -    if ( block->mmap_ptr == MAP_FAILED ) {
>> +    if ( block->ptr == MAP_FAILED ) {
>>           xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
>>                        "failed to mmap file: %s",
>>                        strerror(errno));
>>           goto err;
>>       }
>>   
>> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>>       block->next = dom->memblocks;
>>       dom->memblocks = block;
>>       dom->alloc_malloc += sizeof(*block);
>> -    dom->alloc_file_map += block->mmap_len;
>> +    dom->alloc_file_map += block->len;
>>       close(fd);
>>       if ( *size > (100 * 1024) )
>>           print_mem(dom, __FUNCTION__, *size);
>> -    return block->mmap_ptr;
>> +    return block->ptr;
>>   
>>    err:
>>       if ( fd != -1 )
>> @@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
>>       while ( (block = dom->memblocks) != NULL )
>>       {
>>           dom->memblocks = block->next;
>> -        if ( block->mmap_ptr )
>> -            munmap(block->mmap_ptr, block->mmap_len);
>> +        switch ( block->type )
>> +        {
>> +        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
>> +            break;
>> +        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
>> +            free(block->ptr);
>> +            break;
>> +        case XC_DOM_MEM_TYPE_MMAP:
>> +            munmap(block->ptr, block->len);
>> +            break;
>> +        }
>>           free(block);
>>       }
>>   }
>> diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
>> index 490ec56..b6a33f2 100644
>> --- a/tools/libxc/xc_dom_decompress_lz4.c
>> +++ b/tools/libxc/xc_dom_decompress_lz4.c
>> @@ -103,6 +103,11 @@ int xc_try_lz4_decode(
>>   
>>   		if (size == 0)
>>   		{
>> +			if ( xc_dom_register_external(dom, output, out_len) )
>> +			{
>> +				msg = "Error registering stream output";
>> +				goto exit_2;
>> +			}
>>   			*blob = output;
>>   			*psize = out_len;
>>   			return 0;
>> -- 
>> 1.7.10.4
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 03:14:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 03:14:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xref7-0002Qt-Nk; Fri, 21 Nov 2014 03:13:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gedalya@gedalya.net>) id 1Xref6-0002Qo-7u
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 03:13:32 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	8B/B6-23865-BDDAE645; Fri, 21 Nov 2014 03:13:31 +0000
X-Env-Sender: gedalya@gedalya.net
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416539609!8413200!1
X-Originating-IP: [47.21.139.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1430 invoked from network); 21 Nov 2014 03:13:29 -0000
Received: from mail.gedalya.net (HELO mail.gedalya.net) (47.21.139.35)
	by server-6.tower-31.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Nov 2014 03:13:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gedalya.net;
	s=rsa1; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=Ict3Xlc8gINRVQkC4BTvlDM3Qy9e8eY1vaBCNkggUgY=; 
	b=bud2oX4uuxa4OPULTyxHoACo/4MC/hkBYw/OW/uyoBS4IArzM91PVbhhlWULrdiwYtJZYZYNJR02b2MQ3sf9Grxe1DzXS4vGbWifvvajP6YRnhazPGopY+hu3cWYFCn/3u5B3YMXB7PP47y2srJ2FJUb5WWN8eUWFxy+mUesAfKI3O5iZ+Qb9pATAZclD9kLwkvJyrMhnVIrmod02jyE/iXOZE/ANO3OV3jkrL2h/gCEbUEsEfxxvyV9Ws5jPfjx5FLbma88EJ5k38GjT5TNy2xCCSfBMfBCdYC4twnUIlkPtwIQEC7HB9XwcmhOmvbMywz2Jtg3DdLLyX509chzGg==;
Received: from [192.168.9.10] by mail.gedalya.net with esmtpsa
	(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84)
	(envelope-from <gedalya@gedalya.net>)
	id 1Xreeu-0000gm-Un; Thu, 20 Nov 2014 22:13:20 -0500
Message-ID: <546EADD0.8010002@gedalya.net>
Date: Thu, 20 Nov 2014 22:13:20 -0500
From: Gedalya <gedalya@gedalya.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Ian Campbell <ian.campbell@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120202114.GE31889@laptop.dumpdata.com>
In-Reply-To: <20141120202114.GE31889@laptop.dumpdata.com>
Cc: wei.liu2@citrix.com, 767295@bugs.debian.org, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 03:21 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
>> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
>> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
>> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
>> up leaked.
>>
>> The memory pool currently supports mmap'd buffers as well as a directly
>> allocated buffers, however the try decode routines make use of realloc and do
>> not fit well into this model. Introduce a concept of an external memory block
>> to the memory pool and provide an interface to register such memory.
>>
>> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
>> mmap_ prefix since they are now also used for external memory blocks.
>>
>> We are only seeing this now because the gzip decoder doesn't leak and it's only
>> relatively recently that kernels in the wild have switched to better
>> compression.
>>
>> This is https://bugs.debian.org/767295
>>
>> Reported by: Gedalya <gedalya@gedalya.net>
> Gedelya,
>
> Could you also test this patch to make sure it does fix the
> reported issue please?

So here's what happens now.
1. Starts up tiny
2. reboot: leak
3. reboot: freed (process larger, but the delta is all/mostly shared pages)
4. reboot: leak
5. reboot: freed
etc..

root@xen:~/xen-pkgs# xl cr /etc/xen/auto/asterisk_deb80.cfg
Parsing config from /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
root     22981  0.0  0.0  95968   588 ?        SLsl 21:55   0:00 
/usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# pmap -x 22981
22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     144     128       0 r-x-- xl
0000000000623000       4       4       4 r---- xl
0000000000624000       8       8       8 rw--- xl
0000000000626000       4       4       4 rw---   [ anon ]
00000000009a6000     288     240     240 rw---   [ anon ]
00007f14d4000000     132       8       8 rw---   [ anon ]
00007f14d4021000   65404       0       0 -----   [ anon ]
<< snip >>
---------------- ------- ------- -------
total kB           95968    2728     596

--- reboot domu ---

root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
root     22981  0.6  3.3 131652 20008 ?        SLsl 21:55   0:00 
/usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# pmap -x 22981
22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     144     144       0 r-x-- xl
0000000000623000       4       4       4 r---- xl
0000000000624000       8       8       8 rw--- xl
0000000000626000       4       4       4 rw---   [ anon ]
00000000009a6000     288     288     288 rw---   [ anon ]
00000000009ee000   35676   16772   16772 rw---   [ anon ]
00007f14d4000000     132       8       8 rw---   [ anon ]
00007f14d4021000   65404       0       0 -----   [ anon ]
00007f14d9ae0000     104     100       0 r-x-- libz.so.1.2.8
<< snip >>
---------------- ------- ------- -------
total kB          131652   20072   17424

--- reboot domu ---

root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
root     22981  0.5  0.5  95876  3136 ?        SLsl 21:55   0:01 
/usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# pmap -x 22981
22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     144     144       0 r-x-- xl
0000000000623000       4       4       4 r---- xl
0000000000624000       8       8       8 rw--- xl
0000000000626000       4       4       4 rw---   [ anon ]
00000000009a6000     188     188     188 rw---   [ anon ]
00007f14d4000000     132       8       8 rw---   [ anon ]
00007f14d4021000   65404       0       0 -----   [ anon ]
00007f14d9ae0000     104     100       0 r-x-- libz.so.1.2.8
<< snip >>
---------------- ------- ------- -------
total kB           95876    3200     552

--- reboot domu ---

root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
root     22981  0.6  3.4 134660 20548 ?        SLsl 21:55   0:02 
/usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# pmap -x 22981
22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     144     144       0 r-x-- xl
0000000000623000       4       4       4 r---- xl
0000000000624000       8       8       8 rw--- xl
0000000000626000       4       4       4 rw---   [ anon ]
00000000009a6000     188     188     188 rw---   [ anon ]
00000000009d5000   38784   17348   17348 rw---   [ anon ]
00007f14d4000000     132       8       8 rw---   [ anon ]
00007f14d4021000   65404       0       0 -----   [ anon ]
00007f14d9ae0000     104     100       0 r-x-- libz.so.1.2.8
<< snip >>
---------------- ------- ------- -------
total kB          134660   20548   17900

--- reboot domu ---

root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
root     22981  0.6  0.5  95876  3200 ?        SLsl 21:55   0:03 
/usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
root@xen:~/xen-pkgs# pmap -x 22981
22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     144     144       0 r-x-- xl
0000000000623000       4       4       4 r---- xl
0000000000624000       8       8       8 rw--- xl
0000000000626000       4       4       4 rw---   [ anon ]
00000000009a6000     188     188     188 rw---   [ anon ]
00007f14d4000000     132       8       8 rw---   [ anon ]
00007f14d4021000   65404       0       0 -----   [ anon ]
00007f14d9ae0000     104     100       0 r-x-- libz.so.1.2.8
<< snip >>
---------------- ------- ------- -------
total kB           95876    3200     552




Tried valgrind, it doesn't look like it was able to see what was going on

root@xen:~# valgrind --leak-check=full xl cr -F 
/etc/xen/auto/asterisk_deb80.cfg
==24967== Memcheck, a memory error detector
==24967== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==24967== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==24967== Command: /usr/sbin/xl cr -F /etc/xen/auto/asterisk_deb80.cfg
==24967==
==24971==
==24971== HEAP SUMMARY:
==24971==     in use at exit: 11,695 bytes in 41 blocks
==24971==   total heap usage: 75 allocs, 34 frees, 44,602 bytes allocated
==24971==
==24971== LEAK SUMMARY:
==24971==    definitely lost: 0 bytes in 0 blocks
==24971==    indirectly lost: 0 bytes in 0 blocks
==24971==      possibly lost: 0 bytes in 0 blocks
==24971==    still reachable: 11,695 bytes in 41 blocks
==24971==         suppressed: 0 bytes in 0 blocks
==24971== Reachable blocks (those to which a pointer was found) are not 
shown.
==24971== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24971==
==24971== For counts of detected and suppressed errors, rerun with: -v
==24971== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==24970==
==24970== HEAP SUMMARY:
==24970==     in use at exit: 10,743 bytes in 36 blocks
==24970==   total heap usage: 64 allocs, 28 frees, 35,289 bytes allocated
==24970==
==24970== LEAK SUMMARY:
==24970==    definitely lost: 0 bytes in 0 blocks
==24970==    indirectly lost: 0 bytes in 0 blocks
==24970==      possibly lost: 0 bytes in 0 blocks
==24970==    still reachable: 10,743 bytes in 36 blocks
==24970==         suppressed: 0 bytes in 0 blocks
==24970== Reachable blocks (those to which a pointer was found) are not 
shown.
==24970== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24970==
==24970== For counts of detected and suppressed errors, rerun with: -v
==24970== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==24975==
==24975== HEAP SUMMARY:
==24975==     in use at exit: 4,859 bytes in 43 blocks
==24975==   total heap usage: 92 allocs, 49 frees, 38,375 bytes allocated
==24975==
==24975== LEAK SUMMARY:
==24975==    definitely lost: 0 bytes in 0 blocks
==24975==    indirectly lost: 0 bytes in 0 blocks
==24975==      possibly lost: 0 bytes in 0 blocks
==24975==    still reachable: 4,859 bytes in 43 blocks
==24975==         suppressed: 0 bytes in 0 blocks
==24975== Reachable blocks (those to which a pointer was found) are not 
shown.
==24975== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24975==
==24975== For counts of detected and suppressed errors, rerun with: -v
==24975== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==24976==
==24976== HEAP SUMMARY:
==24976==     in use at exit: 13,066 bytes in 45 blocks
==24976==   total heap usage: 98 allocs, 53 frees, 48,704 bytes allocated
==24976==
==24976== LEAK SUMMARY:
==24976==    definitely lost: 0 bytes in 0 blocks
==24976==    indirectly lost: 0 bytes in 0 blocks
==24976==      possibly lost: 0 bytes in 0 blocks
==24976==    still reachable: 13,066 bytes in 45 blocks
==24976==         suppressed: 0 bytes in 0 blocks
==24976== Reachable blocks (those to which a pointer was found) are not 
shown.
==24976== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24976==
==24976== For counts of detected and suppressed errors, rerun with: -v
==24976== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==24969==
==24969== HEAP SUMMARY:
==24969==     in use at exit: 11,049 bytes in 42 blocks
==24969==   total heap usage: 92 allocs, 50 frees, 48,587 bytes allocated
==24969==
==24969== LEAK SUMMARY:
==24969==    definitely lost: 0 bytes in 0 blocks
==24969==    indirectly lost: 0 bytes in 0 blocks
==24969==      possibly lost: 0 bytes in 0 blocks
==24969==    still reachable: 11,049 bytes in 42 blocks
==24969==         suppressed: 0 bytes in 0 blocks
==24969== Reachable blocks (those to which a pointer was found) are not 
shown.
==24969== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24969==
==24969== For counts of detected and suppressed errors, rerun with: -v
==24969== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Parsing config from /etc/xen/auto/asterisk_deb80.cfg
Waiting for domain asterisk_deb80 (domid 31) to die [pid 24967]
Domain 31 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 31 needs to be cleaned up: destroying the domain
Done. Rebooting now
Waiting for domain asterisk_deb80 (domid 32) to die [pid 24967]
Domain 32 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 32 needs to be cleaned up: destroying the domain
Done. Rebooting now
Waiting for domain asterisk_deb80 (domid 33) to die [pid 24967]
Domain 33 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 33 needs to be cleaned up: destroying the domain
Done. Rebooting now
Waiting for domain asterisk_deb80 (domid 34) to die [pid 24967]
Domain 34 has shut down, reason code 0 0x0
Action for shutdown reason code 0 is destroy
Domain 34 needs to be cleaned up: destroying the domain
Done. Exiting now


>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> ---
>> v2: Correct handling in xc_try_lzo1x_decode.
>>
>> This is a bug fix and should go into 4.5.
>>
>> I have a sneaking suspicion this is going to need to backport a very long way...
>> ---
>>   tools/libxc/include/xc_dom.h        |   10 ++++--
>>   tools/libxc/xc_dom_bzimageloader.c  |   20 ++++++++++++
>>   tools/libxc/xc_dom_core.c           |   61 +++++++++++++++++++++++++++--------
>>   tools/libxc/xc_dom_decompress_lz4.c |    5 +++
>>   4 files changed, 80 insertions(+), 16 deletions(-)
>>
>> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
>> index 6ae6a9f..07d7224 100644
>> --- a/tools/libxc/include/xc_dom.h
>> +++ b/tools/libxc/include/xc_dom.h
>> @@ -33,8 +33,13 @@ struct xc_dom_seg {
>>   
>>   struct xc_dom_mem {
>>       struct xc_dom_mem *next;
>> -    void *mmap_ptr;
>> -    size_t mmap_len;
>> +    void *ptr;
>> +    enum {
>> +        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
>> +        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
>> +        XC_DOM_MEM_TYPE_MMAP,
>> +    } type;
>> +    size_t len;
>>       unsigned char memory[0];
>>   };
>>   
>> @@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
>>   /* --- simple memory pool ------------------------------------------ */
>>   
>>   void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
>> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
>>   void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
>>   void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>>                               const char *filename, size_t * size,
>> diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
>> index 2225699..964ebdc 100644
>> --- a/tools/libxc/xc_dom_bzimageloader.c
>> +++ b/tools/libxc/xc_dom_bzimageloader.c
>> @@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
>>   
>>       total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
>>   
>> +    if ( xc_dom_register_external(dom, out_buf, total) )
>> +    {
>> +        DOMPRINTF("BZIP2: Error registering stream output");
>> +        free(out_buf);
>> +        goto bzip2_cleanup;
>> +    }
>> +
>>       DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
>>                 __FUNCTION__, *size, (long unsigned int) total);
>>   
>> @@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
>>           }
>>       }
>>   
>> +    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
>> +    {
>> +        DOMPRINTF("%s: Error registering stream output", what);
>> +        free(out_buf);
>> +        goto lzma_cleanup;
>> +    }
>> +
>>       DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
>>                 __FUNCTION__, what, *size, (size_t)stream->total_out);
>>   
>> @@ -464,7 +478,13 @@ static int xc_try_lzo1x_decode(
>>   
>>           dst_len = lzo_read_32(cur);
>>           if ( !dst_len )
>> +        {
>> +            msg = "Error registering stream output";
>> +            if ( xc_dom_register_external(dom, out_buf, out_len) )
>> +                break;
>> +
>>               return 0;
>> +        }
>>   
>>           if ( dst_len > LZOP_MAX_BLOCK_SIZE )
>>           {
>> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
>> index baa62a1..ecbf981 100644
>> --- a/tools/libxc/xc_dom_core.c
>> +++ b/tools/libxc/xc_dom_core.c
>> @@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image *dom, size_t size)
>>           return NULL;
>>       }
>>       memset(block, 0, sizeof(*block) + size);
>> +    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
>>       block->next = dom->memblocks;
>>       dom->memblocks = block;
>>       dom->alloc_malloc += sizeof(*block) + size;
>> @@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
>>           return NULL;
>>       }
>>       memset(block, 0, sizeof(*block));
>> -    block->mmap_len = size;
>> -    block->mmap_ptr = mmap(NULL, block->mmap_len,
>> -                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
>> -                           -1, 0);
>> -    if ( block->mmap_ptr == MAP_FAILED )
>> +    block->len = size;
>> +    block->ptr = mmap(NULL, block->len,
>> +                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
>> +                      -1, 0);
>> +    if ( block->ptr == MAP_FAILED )
>>       {
>>           DOMPRINTF("%s: mmap failed", __FUNCTION__);
>>           free(block);
>>           return NULL;
>>       }
>> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>>       block->next = dom->memblocks;
>>       dom->memblocks = block;
>>       dom->alloc_malloc += sizeof(*block);
>> -    dom->alloc_mem_map += block->mmap_len;
>> +    dom->alloc_mem_map += block->len;
>>       if ( size > (100 * 1024) )
>>           print_mem(dom, __FUNCTION__, size);
>> -    return block->mmap_ptr;
>> +    return block->ptr;
>> +}
>> +
>> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
>> +{
>> +    struct xc_dom_mem *block;
>> +
>> +    block = malloc(sizeof(*block));
>> +    if ( block == NULL )
>> +    {
>> +        DOMPRINTF("%s: allocation failed", __FUNCTION__);
>> +        return -1;
>> +    }
>> +    memset(block, 0, sizeof(*block));
>> +    block->ptr = ptr;
>> +    block->len = size;
>> +    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
>> +    block->next = dom->memblocks;
>> +    dom->memblocks = block;
>> +    dom->alloc_malloc += sizeof(*block);
>> +    dom->alloc_mem_map += block->len;
>> +    return 0;
>>   }
>>   
>>   void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>> @@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>>       }
>>   
>>       memset(block, 0, sizeof(*block));
>> -    block->mmap_len = *size;
>> -    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
>> +    block->len = *size;
>> +    block->ptr = mmap(NULL, block->len, PROT_READ,
>>                              MAP_SHARED, fd, 0);
>> -    if ( block->mmap_ptr == MAP_FAILED ) {
>> +    if ( block->ptr == MAP_FAILED ) {
>>           xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
>>                        "failed to mmap file: %s",
>>                        strerror(errno));
>>           goto err;
>>       }
>>   
>> +    block->type = XC_DOM_MEM_TYPE_MMAP;
>>       block->next = dom->memblocks;
>>       dom->memblocks = block;
>>       dom->alloc_malloc += sizeof(*block);
>> -    dom->alloc_file_map += block->mmap_len;
>> +    dom->alloc_file_map += block->len;
>>       close(fd);
>>       if ( *size > (100 * 1024) )
>>           print_mem(dom, __FUNCTION__, *size);
>> -    return block->mmap_ptr;
>> +    return block->ptr;
>>   
>>    err:
>>       if ( fd != -1 )
>> @@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_dom_image *dom)
>>       while ( (block = dom->memblocks) != NULL )
>>       {
>>           dom->memblocks = block->next;
>> -        if ( block->mmap_ptr )
>> -            munmap(block->mmap_ptr, block->mmap_len);
>> +        switch ( block->type )
>> +        {
>> +        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
>> +            break;
>> +        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
>> +            free(block->ptr);
>> +            break;
>> +        case XC_DOM_MEM_TYPE_MMAP:
>> +            munmap(block->ptr, block->len);
>> +            break;
>> +        }
>>           free(block);
>>       }
>>   }
>> diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
>> index 490ec56..b6a33f2 100644
>> --- a/tools/libxc/xc_dom_decompress_lz4.c
>> +++ b/tools/libxc/xc_dom_decompress_lz4.c
>> @@ -103,6 +103,11 @@ int xc_try_lz4_decode(
>>   
>>   		if (size == 0)
>>   		{
>> +			if ( xc_dom_register_external(dom, output, out_len) )
>> +			{
>> +				msg = "Error registering stream output";
>> +				goto exit_2;
>> +			}
>>   			*blob = output;
>>   			*psize = out_len;
>>   			return 0;
>> -- 
>> 1.7.10.4
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 03:19:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 03:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrekn-0002aN-Sn; Fri, 21 Nov 2014 03:19:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gedalya@gedalya.net>) id 1Xrekl-0002aG-MV
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 03:19:23 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	81/B0-09936-A3FAE645; Fri, 21 Nov 2014 03:19:22 +0000
X-Env-Sender: gedalya@gedalya.net
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416539960!14272680!1
X-Originating-IP: [47.21.139.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4252 invoked from network); 21 Nov 2014 03:19:21 -0000
Received: from mail.gedalya.net (HELO mail.gedalya.net) (47.21.139.35)
	by server-11.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Nov 2014 03:19:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gedalya.net;
	s=rsa1; 
	h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=8fqnwnb0ekQ42eePmMrkIqlD8fcuO/OsPhEdSkmdIr0=; 
	b=o4owapKwPcymQNU9Ziq4VFdPRRbBqlLi3kEjrpUPzCllPTkh8eclI4Co/w7z09Ya/JlBAYVcDccB1W74VvhdGOOZooSfTluPH/aRLDtGBHckS/dqpImiUwtUmrllRAYtcC+cBmkwa8zUJ+b9aXcWsUCYGuoRWbhXYvid/q9kkUhOlLkjE9rXnYX2VFAeGnOBWPFJWvSOd2x2/D0mjPmw/imiwxNzeIQ3QzNDsuwQtBbe35onUd0mjouJ+pcKe8/4OXpy+qDyH2UOfRq2q8E7ltVHGMIkKHHq6OTJJSAqD5Wj5l+AbUZNgBWAqJTYbDsIV5MV2LL5R7KAenbHjGezDg==;
Received: from [192.168.9.10] by mail.gedalya.net with esmtpsa
	(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84)
	(envelope-from <gedalya@gedalya.net>)
	id 1Xrekf-0000hh-7T; Thu, 20 Nov 2014 22:19:17 -0500
Message-ID: <546EAF34.2090705@gedalya.net>
Date: Thu, 20 Nov 2014 22:19:16 -0500
From: Gedalya <gedalya@gedalya.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Ian Campbell <ian.campbell@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>
In-Reply-To: <546EADD0.8010002@gedalya.net>
Content-Type: multipart/mixed; boundary="------------080605010805060603010702"
Cc: wei.liu2@citrix.com, 767295@bugs.debian.org, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------080605010805060603010702
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 11/20/2014 10:13 PM, Gedalya wrote:
> On 11/20/2014 03:21 PM, Konrad Rzeszutek Wilk wrote:
>> On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
>>> The libxc xc_dom_* infrastructure uses a very simple malloc memory 
>>> pool which
>>> is freed by xc_dom_release. However the various xc_try_*_decode 
>>> routines (other
>>> than the gzip one) just use plain malloc/realloc and therefore the 
>>> buffer ends
>>> up leaked.
>>>
>>> The memory pool currently supports mmap'd buffers as well as a directly
>>> allocated buffers, however the try decode routines make use of 
>>> realloc and do
>>> not fit well into this model. Introduce a concept of an external 
>>> memory block
>>> to the memory pool and provide an interface to register such memory.
>>>
>>> The mmap_ptr and mmap_len fields of the memblock tracking struct 
>>> lose their
>>> mmap_ prefix since they are now also used for external memory blocks.
>>>
>>> We are only seeing this now because the gzip decoder doesn't leak 
>>> and it's only
>>> relatively recently that kernels in the wild have switched to better
>>> compression.
>>>
>>> This is https://bugs.debian.org/767295
>>>
>>> Reported by: Gedalya <gedalya@gedalya.net>
>> Gedelya,
>>
>> Could you also test this patch to make sure it does fix the
>> reported issue please?
>
> So here's what happens now.
> 1. Starts up tiny
> 2. reboot: leak
> 3. reboot: freed (process larger, but the delta is all/mostly shared 
> pages)
> 4. reboot: leak
> 5. reboot: freed
> etc..
>
For the record, I applied it again the xen package currently in debian, 
4.4.1-3, see attached patch.
The only problem was that tools/libxc/include/xc_dom.h is in 
tools/libxc/xc_dom.h, otherwise it applied fine.


--------------080605010805060603010702
Content-Type: text/plain; charset=UTF-8;
 name="0039-libxc-dont-leak-buffer-containing-the-uncompressed-pv-kernel"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0039-libxc-dont-leak-buffer-containing-the-uncompressed-pv-k";
 filename*1="ernel"

Index: xen-4.4.1/tools/libxc/xc_dom.h
===================================================================
--- xen-4.4.1.orig/tools/libxc/xc_dom.h
+++ xen-4.4.1/tools/libxc/xc_dom.h
@@ -33,8 +33,13 @@ struct xc_dom_seg {
 
 struct xc_dom_mem {
     struct xc_dom_mem *next;
-    void *mmap_ptr;
-    size_t mmap_len;
+    void *ptr;
+    enum {
+        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
+        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
+        XC_DOM_MEM_TYPE_MMAP,
+    } type;
+    size_t len;
     unsigned char memory[0];
 };
 
@@ -290,6 +295,7 @@ void xc_dom_log_memory_footprint(struct
 /* --- simple memory pool ------------------------------------------ */
 
 void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
 void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
                             const char *filename, size_t * size,
Index: xen-4.4.1/tools/libxc/xc_dom_bzimageloader.c
===================================================================
--- xen-4.4.1.orig/tools/libxc/xc_dom_bzimageloader.c
+++ xen-4.4.1/tools/libxc/xc_dom_bzimageloader.c
@@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
 
     total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
 
+    if ( xc_dom_register_external(dom, out_buf, total) )
+    {
+        DOMPRINTF("BZIP2: Error registering stream output");
+        free(out_buf);
+        goto bzip2_cleanup;
+    }
+
     DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
               __FUNCTION__, *size, (long unsigned int) total);
 
@@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
         }
     }
 
+    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
+    {
+        DOMPRINTF("%s: Error registering stream output", what);
+        free(out_buf);
+        goto lzma_cleanup;
+    }
+
     DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
               __FUNCTION__, what, *size, (size_t)stream->total_out);
 
@@ -464,7 +478,13 @@ static int xc_try_lzo1x_decode(
 
         dst_len = lzo_read_32(cur);
         if ( !dst_len )
+        {
+            msg = "Error registering stream output";
+            if ( xc_dom_register_external(dom, out_buf, out_len) )
+                break;
+
             return 0;
+        }
 
         if ( dst_len > LZOP_MAX_BLOCK_SIZE )
         {
Index: xen-4.4.1/tools/libxc/xc_dom_core.c
===================================================================
--- xen-4.4.1.orig/tools/libxc/xc_dom_core.c
+++ xen-4.4.1/tools/libxc/xc_dom_core.c
@@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image
         return NULL;
     }
     memset(block, 0, sizeof(*block) + size);
+    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block) + size;
@@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct
         return NULL;
     }
     memset(block, 0, sizeof(*block));
-    block->mmap_len = size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len,
-                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
-                           -1, 0);
-    if ( block->mmap_ptr == MAP_FAILED )
+    block->len = size;
+    block->ptr = mmap(NULL, block->len,
+                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
+                      -1, 0);
+    if ( block->ptr == MAP_FAILED )
     {
         DOMPRINTF("%s: mmap failed", __FUNCTION__);
         free(block);
         return NULL;
     }
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_mem_map += block->mmap_len;
+    dom->alloc_mem_map += block->len;
     if ( size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, size);
-    return block->mmap_ptr;
+    return block->ptr;
+}
+
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
+{
+    struct xc_dom_mem *block;
+
+    block = malloc(sizeof(*block));
+    if ( block == NULL )
+    {
+        DOMPRINTF("%s: allocation failed", __FUNCTION__);
+        return -1;
+    }
+    memset(block, 0, sizeof(*block));
+    block->ptr = ptr;
+    block->len = size;
+    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
+    block->next = dom->memblocks;
+    dom->memblocks = block;
+    dom->alloc_malloc += sizeof(*block);
+    dom->alloc_mem_map += block->len;
+    return 0;
 }
 
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
@@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_do
     }
 
     memset(block, 0, sizeof(*block));
-    block->mmap_len = *size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
+    block->len = *size;
+    block->ptr = mmap(NULL, block->len, PROT_READ,
                            MAP_SHARED, fd, 0);
-    if ( block->mmap_ptr == MAP_FAILED ) {
+    if ( block->ptr == MAP_FAILED ) {
         xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
                      "failed to mmap file: %s",
                      strerror(errno));
         goto err;
     }
 
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_file_map += block->mmap_len;
+    dom->alloc_file_map += block->len;
     close(fd);
     if ( *size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, *size);
-    return block->mmap_ptr;
+    return block->ptr;
 
  err:
     if ( fd != -1 )
@@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_do
     while ( (block = dom->memblocks) != NULL )
     {
         dom->memblocks = block->next;
-        if ( block->mmap_ptr )
-            munmap(block->mmap_ptr, block->mmap_len);
+        switch ( block->type )
+        {
+        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
+            break;
+        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
+            free(block->ptr);
+            break;
+        case XC_DOM_MEM_TYPE_MMAP:
+            munmap(block->ptr, block->len);
+            break;
+        }
         free(block);
     }
 }
Index: xen-4.4.1/tools/libxc/xc_dom_decompress_lz4.c
===================================================================
--- xen-4.4.1.orig/tools/libxc/xc_dom_decompress_lz4.c
+++ xen-4.4.1/tools/libxc/xc_dom_decompress_lz4.c
@@ -104,6 +104,11 @@ int xc_try_lz4_decode(
 
 		if (size == 0)
 		{
+			if ( xc_dom_register_external(dom, output, out_len) )
+			{
+				msg = "Error registering stream output";
+				goto exit_2;
+			}
 			*blob = output;
 			*psize = out_len;
 			return 0;

--------------080605010805060603010702
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080605010805060603010702--


From xen-devel-bounces@lists.xen.org Fri Nov 21 03:19:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 03:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrekn-0002aN-Sn; Fri, 21 Nov 2014 03:19:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gedalya@gedalya.net>) id 1Xrekl-0002aG-MV
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 03:19:23 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	81/B0-09936-A3FAE645; Fri, 21 Nov 2014 03:19:22 +0000
X-Env-Sender: gedalya@gedalya.net
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416539960!14272680!1
X-Originating-IP: [47.21.139.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4252 invoked from network); 21 Nov 2014 03:19:21 -0000
Received: from mail.gedalya.net (HELO mail.gedalya.net) (47.21.139.35)
	by server-11.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Nov 2014 03:19:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gedalya.net;
	s=rsa1; 
	h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=8fqnwnb0ekQ42eePmMrkIqlD8fcuO/OsPhEdSkmdIr0=; 
	b=o4owapKwPcymQNU9Ziq4VFdPRRbBqlLi3kEjrpUPzCllPTkh8eclI4Co/w7z09Ya/JlBAYVcDccB1W74VvhdGOOZooSfTluPH/aRLDtGBHckS/dqpImiUwtUmrllRAYtcC+cBmkwa8zUJ+b9aXcWsUCYGuoRWbhXYvid/q9kkUhOlLkjE9rXnYX2VFAeGnOBWPFJWvSOd2x2/D0mjPmw/imiwxNzeIQ3QzNDsuwQtBbe35onUd0mjouJ+pcKe8/4OXpy+qDyH2UOfRq2q8E7ltVHGMIkKHHq6OTJJSAqD5Wj5l+AbUZNgBWAqJTYbDsIV5MV2LL5R7KAenbHjGezDg==;
Received: from [192.168.9.10] by mail.gedalya.net with esmtpsa
	(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84)
	(envelope-from <gedalya@gedalya.net>)
	id 1Xrekf-0000hh-7T; Thu, 20 Nov 2014 22:19:17 -0500
Message-ID: <546EAF34.2090705@gedalya.net>
Date: Thu, 20 Nov 2014 22:19:16 -0500
From: Gedalya <gedalya@gedalya.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Ian Campbell <ian.campbell@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>
In-Reply-To: <546EADD0.8010002@gedalya.net>
Content-Type: multipart/mixed; boundary="------------080605010805060603010702"
Cc: wei.liu2@citrix.com, 767295@bugs.debian.org, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------080605010805060603010702
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 11/20/2014 10:13 PM, Gedalya wrote:
> On 11/20/2014 03:21 PM, Konrad Rzeszutek Wilk wrote:
>> On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
>>> The libxc xc_dom_* infrastructure uses a very simple malloc memory 
>>> pool which
>>> is freed by xc_dom_release. However the various xc_try_*_decode 
>>> routines (other
>>> than the gzip one) just use plain malloc/realloc and therefore the 
>>> buffer ends
>>> up leaked.
>>>
>>> The memory pool currently supports mmap'd buffers as well as a directly
>>> allocated buffers, however the try decode routines make use of 
>>> realloc and do
>>> not fit well into this model. Introduce a concept of an external 
>>> memory block
>>> to the memory pool and provide an interface to register such memory.
>>>
>>> The mmap_ptr and mmap_len fields of the memblock tracking struct 
>>> lose their
>>> mmap_ prefix since they are now also used for external memory blocks.
>>>
>>> We are only seeing this now because the gzip decoder doesn't leak 
>>> and it's only
>>> relatively recently that kernels in the wild have switched to better
>>> compression.
>>>
>>> This is https://bugs.debian.org/767295
>>>
>>> Reported by: Gedalya <gedalya@gedalya.net>
>> Gedelya,
>>
>> Could you also test this patch to make sure it does fix the
>> reported issue please?
>
> So here's what happens now.
> 1. Starts up tiny
> 2. reboot: leak
> 3. reboot: freed (process larger, but the delta is all/mostly shared 
> pages)
> 4. reboot: leak
> 5. reboot: freed
> etc..
>
For the record, I applied it again the xen package currently in debian, 
4.4.1-3, see attached patch.
The only problem was that tools/libxc/include/xc_dom.h is in 
tools/libxc/xc_dom.h, otherwise it applied fine.


--------------080605010805060603010702
Content-Type: text/plain; charset=UTF-8;
 name="0039-libxc-dont-leak-buffer-containing-the-uncompressed-pv-kernel"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0039-libxc-dont-leak-buffer-containing-the-uncompressed-pv-k";
 filename*1="ernel"

Index: xen-4.4.1/tools/libxc/xc_dom.h
===================================================================
--- xen-4.4.1.orig/tools/libxc/xc_dom.h
+++ xen-4.4.1/tools/libxc/xc_dom.h
@@ -33,8 +33,13 @@ struct xc_dom_seg {
 
 struct xc_dom_mem {
     struct xc_dom_mem *next;
-    void *mmap_ptr;
-    size_t mmap_len;
+    void *ptr;
+    enum {
+        XC_DOM_MEM_TYPE_MALLOC_INTERNAL,
+        XC_DOM_MEM_TYPE_MALLOC_EXTERNAL,
+        XC_DOM_MEM_TYPE_MMAP,
+    } type;
+    size_t len;
     unsigned char memory[0];
 };
 
@@ -290,6 +295,7 @@ void xc_dom_log_memory_footprint(struct
 /* --- simple memory pool ------------------------------------------ */
 
 void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size);
 void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
                             const char *filename, size_t * size,
Index: xen-4.4.1/tools/libxc/xc_dom_bzimageloader.c
===================================================================
--- xen-4.4.1.orig/tools/libxc/xc_dom_bzimageloader.c
+++ xen-4.4.1/tools/libxc/xc_dom_bzimageloader.c
@@ -161,6 +161,13 @@ static int xc_try_bzip2_decode(
 
     total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
 
+    if ( xc_dom_register_external(dom, out_buf, total) )
+    {
+        DOMPRINTF("BZIP2: Error registering stream output");
+        free(out_buf);
+        goto bzip2_cleanup;
+    }
+
     DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
               __FUNCTION__, *size, (long unsigned int) total);
 
@@ -305,6 +312,13 @@ static int _xc_try_lzma_decode(
         }
     }
 
+    if ( xc_dom_register_external(dom, out_buf, stream->total_out) )
+    {
+        DOMPRINTF("%s: Error registering stream output", what);
+        free(out_buf);
+        goto lzma_cleanup;
+    }
+
     DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
               __FUNCTION__, what, *size, (size_t)stream->total_out);
 
@@ -464,7 +478,13 @@ static int xc_try_lzo1x_decode(
 
         dst_len = lzo_read_32(cur);
         if ( !dst_len )
+        {
+            msg = "Error registering stream output";
+            if ( xc_dom_register_external(dom, out_buf, out_len) )
+                break;
+
             return 0;
+        }
 
         if ( dst_len > LZOP_MAX_BLOCK_SIZE )
         {
Index: xen-4.4.1/tools/libxc/xc_dom_core.c
===================================================================
--- xen-4.4.1.orig/tools/libxc/xc_dom_core.c
+++ xen-4.4.1/tools/libxc/xc_dom_core.c
@@ -132,6 +132,7 @@ void *xc_dom_malloc(struct xc_dom_image
         return NULL;
     }
     memset(block, 0, sizeof(*block) + size);
+    block->type = XC_DOM_MEM_TYPE_MALLOC_INTERNAL;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block) + size;
@@ -151,23 +152,45 @@ void *xc_dom_malloc_page_aligned(struct
         return NULL;
     }
     memset(block, 0, sizeof(*block));
-    block->mmap_len = size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len,
-                           PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
-                           -1, 0);
-    if ( block->mmap_ptr == MAP_FAILED )
+    block->len = size;
+    block->ptr = mmap(NULL, block->len,
+                      PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
+                      -1, 0);
+    if ( block->ptr == MAP_FAILED )
     {
         DOMPRINTF("%s: mmap failed", __FUNCTION__);
         free(block);
         return NULL;
     }
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_mem_map += block->mmap_len;
+    dom->alloc_mem_map += block->len;
     if ( size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, size);
-    return block->mmap_ptr;
+    return block->ptr;
+}
+
+int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size)
+{
+    struct xc_dom_mem *block;
+
+    block = malloc(sizeof(*block));
+    if ( block == NULL )
+    {
+        DOMPRINTF("%s: allocation failed", __FUNCTION__);
+        return -1;
+    }
+    memset(block, 0, sizeof(*block));
+    block->ptr = ptr;
+    block->len = size;
+    block->type = XC_DOM_MEM_TYPE_MALLOC_EXTERNAL;
+    block->next = dom->memblocks;
+    dom->memblocks = block;
+    dom->alloc_malloc += sizeof(*block);
+    dom->alloc_mem_map += block->len;
+    return 0;
 }
 
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
@@ -212,24 +235,25 @@ void *xc_dom_malloc_filemap(struct xc_do
     }
 
     memset(block, 0, sizeof(*block));
-    block->mmap_len = *size;
-    block->mmap_ptr = mmap(NULL, block->mmap_len, PROT_READ,
+    block->len = *size;
+    block->ptr = mmap(NULL, block->len, PROT_READ,
                            MAP_SHARED, fd, 0);
-    if ( block->mmap_ptr == MAP_FAILED ) {
+    if ( block->ptr == MAP_FAILED ) {
         xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
                      "failed to mmap file: %s",
                      strerror(errno));
         goto err;
     }
 
+    block->type = XC_DOM_MEM_TYPE_MMAP;
     block->next = dom->memblocks;
     dom->memblocks = block;
     dom->alloc_malloc += sizeof(*block);
-    dom->alloc_file_map += block->mmap_len;
+    dom->alloc_file_map += block->len;
     close(fd);
     if ( *size > (100 * 1024) )
         print_mem(dom, __FUNCTION__, *size);
-    return block->mmap_ptr;
+    return block->ptr;
 
  err:
     if ( fd != -1 )
@@ -246,8 +270,17 @@ static void xc_dom_free_all(struct xc_do
     while ( (block = dom->memblocks) != NULL )
     {
         dom->memblocks = block->next;
-        if ( block->mmap_ptr )
-            munmap(block->mmap_ptr, block->mmap_len);
+        switch ( block->type )
+        {
+        case XC_DOM_MEM_TYPE_MALLOC_INTERNAL:
+            break;
+        case XC_DOM_MEM_TYPE_MALLOC_EXTERNAL:
+            free(block->ptr);
+            break;
+        case XC_DOM_MEM_TYPE_MMAP:
+            munmap(block->ptr, block->len);
+            break;
+        }
         free(block);
     }
 }
Index: xen-4.4.1/tools/libxc/xc_dom_decompress_lz4.c
===================================================================
--- xen-4.4.1.orig/tools/libxc/xc_dom_decompress_lz4.c
+++ xen-4.4.1/tools/libxc/xc_dom_decompress_lz4.c
@@ -104,6 +104,11 @@ int xc_try_lz4_decode(
 
 		if (size == 0)
 		{
+			if ( xc_dom_register_external(dom, output, out_len) )
+			{
+				msg = "Error registering stream output";
+				goto exit_2;
+			}
 			*blob = output;
 			*psize = out_len;
 			return 0;

--------------080605010805060603010702
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080605010805060603010702--


From xen-devel-bounces@lists.xen.org Fri Nov 21 05:04:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 05:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrgO4-0003vF-1l; Fri, 21 Nov 2014 05:04:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <n0ano@n0ano.com>) id 1XrgO3-0003vA-5c
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 05:04:03 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	32/17-20609-2C7CE645; Fri, 21 Nov 2014 05:04:02 +0000
X-Env-Sender: n0ano@n0ano.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416546239!13866918!1
X-Originating-IP: [67.41.209.129]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6988 invoked from network); 21 Nov 2014 05:04:01 -0000
Received: from willie.n0ano.com (HELO willie.n0ano.com) (67.41.209.129)
	by server-7.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Nov 2014 05:04:01 -0000
Received: from maat.n0ano.com ([192.168.1.25])
	by willie.n0ano.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <n0ano@n0ano.com>)
	id 1XrgNx-0006DV-Ew; Thu, 20 Nov 2014 22:03:57 -0700
Received: from n0ano by maat.n0ano.com with local (Exim 4.77)
	(envelope-from <n0ano@n0ano.com>)
	id 1XrgNi-0005sL-4T; Thu, 20 Nov 2014 22:03:42 -0700
Date: Thu, 20 Nov 2014 22:03:42 -0700
From: "Donald D. Dugger" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121050342.GA22258@n0ano.com>
References: <20141119194611.GA2600@tlaloc.n0ano.com>
	<546DDF34020000780004950D@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546DDF34020000780004950D@smtp.nue.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: eddie.dong@intel.com, will.auld@intel.com, allen.m.kay@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V3] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 12:31:48PM +0100, Jan Beulich wrote:
> >>> On 19.11.14 at 20:46, <donald.d.dugger@intel.com> wrote:
> > @@ -237,6 +248,42 @@
> >      }
> >  }
> >  
> > +static void __init parse_snb_timeout(const char *s)
> > +{
> > +	int not;
> > +
> > +	switch (*s) {
> > +
> > +	case '\0':
> > +		snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
> > +		break;
> > +
> > +	case '0':	case '1':	case '2':
> > +	case '3':	case '4':	case '5':
> > +	case '6':	case '7':	case '8':
> > +	case '9':
> > +		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
> > +		if ( snb_igd_timeout == MILLISECS(1) )
> > +			snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
> > +		break;
> 
> Overly complicated. Just parse_bool() first, if that returns negative
> check for "default" or "", and (if not matched) invoke strtoul(). No
> need for this switch statement.

Personally, I prefer switch statements whenever possible, they're linear
(if statements are evil) and the compiler optimizes them well.  Anyway,
NP, I'll follow your suggestion.

> 
> > +
> > +	default:
> > +		if ( strncmp("default", s, 7) == 0 ) {
> > +			snb_igd_timeout = SNB_IGD_TIMEOUT;
> > +			break;
> > +		}
> > +		not = !strncmp("no-", s, 3);
> 
> This makes no sense - you're looking for e.g. "snb_igd_quirk=no-no"
> here. If the use specified "no-snb_igd_quirk", you'll end up seeing
> "=no" when this function gets entered.

I was confused about the `no-' prefix, I thought it applied to the
value when it is really applied to the key (which makes a lot more
sense).  Fixed in next version.

> 
> Also the whole function is white space damaged (using hard tabs)
> and has misplaced opening braces.

Forgot Xen doesn't like tabs, my bad.

> 
> Jan
> 
> 

And, as Ian pointed out, dyslexia in the subject line, also fixed in the
next version.

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@n0ano.com
Ph: 303/443-3786

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 05:04:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 05:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrgO4-0003vF-1l; Fri, 21 Nov 2014 05:04:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <n0ano@n0ano.com>) id 1XrgO3-0003vA-5c
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 05:04:03 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	32/17-20609-2C7CE645; Fri, 21 Nov 2014 05:04:02 +0000
X-Env-Sender: n0ano@n0ano.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416546239!13866918!1
X-Originating-IP: [67.41.209.129]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6988 invoked from network); 21 Nov 2014 05:04:01 -0000
Received: from willie.n0ano.com (HELO willie.n0ano.com) (67.41.209.129)
	by server-7.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Nov 2014 05:04:01 -0000
Received: from maat.n0ano.com ([192.168.1.25])
	by willie.n0ano.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <n0ano@n0ano.com>)
	id 1XrgNx-0006DV-Ew; Thu, 20 Nov 2014 22:03:57 -0700
Received: from n0ano by maat.n0ano.com with local (Exim 4.77)
	(envelope-from <n0ano@n0ano.com>)
	id 1XrgNi-0005sL-4T; Thu, 20 Nov 2014 22:03:42 -0700
Date: Thu, 20 Nov 2014 22:03:42 -0700
From: "Donald D. Dugger" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121050342.GA22258@n0ano.com>
References: <20141119194611.GA2600@tlaloc.n0ano.com>
	<546DDF34020000780004950D@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546DDF34020000780004950D@smtp.nue.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: eddie.dong@intel.com, will.auld@intel.com, allen.m.kay@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V3] Decouple SnadyBridge quirk form VTd
	timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 12:31:48PM +0100, Jan Beulich wrote:
> >>> On 19.11.14 at 20:46, <donald.d.dugger@intel.com> wrote:
> > @@ -237,6 +248,42 @@
> >      }
> >  }
> >  
> > +static void __init parse_snb_timeout(const char *s)
> > +{
> > +	int not;
> > +
> > +	switch (*s) {
> > +
> > +	case '\0':
> > +		snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
> > +		break;
> > +
> > +	case '0':	case '1':	case '2':
> > +	case '3':	case '4':	case '5':
> > +	case '6':	case '7':	case '8':
> > +	case '9':
> > +		snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
> > +		if ( snb_igd_timeout == MILLISECS(1) )
> > +			snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
> > +		break;
> 
> Overly complicated. Just parse_bool() first, if that returns negative
> check for "default" or "", and (if not matched) invoke strtoul(). No
> need for this switch statement.

Personally, I prefer switch statements whenever possible, they're linear
(if statements are evil) and the compiler optimizes them well.  Anyway,
NP, I'll follow your suggestion.

> 
> > +
> > +	default:
> > +		if ( strncmp("default", s, 7) == 0 ) {
> > +			snb_igd_timeout = SNB_IGD_TIMEOUT;
> > +			break;
> > +		}
> > +		not = !strncmp("no-", s, 3);
> 
> This makes no sense - you're looking for e.g. "snb_igd_quirk=no-no"
> here. If the use specified "no-snb_igd_quirk", you'll end up seeing
> "=no" when this function gets entered.

I was confused about the `no-' prefix, I thought it applied to the
value when it is really applied to the key (which makes a lot more
sense).  Fixed in next version.

> 
> Also the whole function is white space damaged (using hard tabs)
> and has misplaced opening braces.

Forgot Xen doesn't like tabs, my bad.

> 
> Jan
> 
> 

And, as Ian pointed out, dyslexia in the subject line, also fixed in the
next version.

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@n0ano.com
Ph: 303/443-3786

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 05:12:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 05:12:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrgWA-00047x-5f; Fri, 21 Nov 2014 05:12:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <n0ano@n0ano.com>) id 1XrgW8-00047s-BI
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 05:12:24 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	A1/E7-02696-7B9CE645; Fri, 21 Nov 2014 05:12:23 +0000
X-Env-Sender: n0ano@n0ano.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416546740!13902648!1
X-Originating-IP: [67.41.209.129]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8702 invoked from network); 21 Nov 2014 05:12:22 -0000
Received: from willie.n0ano.com (HELO willie.n0ano.com) (67.41.209.129)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Nov 2014 05:12:22 -0000
Received: from maat.n0ano.com ([192.168.1.25])
	by willie.n0ano.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <n0ano@n0ano.com>)
	id 1XrgW3-0006Gq-Uf; Thu, 20 Nov 2014 22:12:19 -0700
Received: from n0ano by maat.n0ano.com with local (Exim 4.77)
	(envelope-from <n0ano@n0ano.com>)
	id 1XrgW3-0005xv-5h; Thu, 20 Nov 2014 22:12:19 -0700
Date: Thu, 20 Nov 2014 22:12:19 -0700
From: "Donald D. Dugger" <donald.d.dugger@intel.com>
To: xen-devel@lists.xen.org
Message-ID: <20141121051219.GB22258@n0ano.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: eddie.dong@intel.com, will.auld@intel.com, allen.m.kay@intel.com,
	JBeulich@suse.com, n0ano@n0ano.com
Subject: [Xen-devel] [PATCH V4] Decouple SandyBridge quirk from VTd timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently the quirk code for SandyBridge uses the VTd timeout value when
writing to an IGD register.  This is the wrong timeout to use and, at
1000 msec., is also much too large.  This patch changes the quirk code
to use a timeout that is specific to the IGD device and allows the user
control of the timeout.

Boolean settings for the boot parameter `snb_igd_quirk' keep their current
meaning, enabling or disabling the quirk code with a timeout of 1000 msec.

In addition specifying `snb_igd_quirk=default' will enable the code and
set the timeout to the theoretical maximum of 670 msec.  For finer control,
specifying `snb_igd_quirk=n', where `n' is a decimal number, will enable
the code and set the timeout to `n' msec.

Signed-off-by: Don Dugger <donald.d.dugger@intel.com>
-- 
diff -r 9d485e2c8339 xen/drivers/passthrough/vtd/quirks.c
--- a/xen/drivers/passthrough/vtd/quirks.c	Mon Nov 10 12:03:36 2014 +0000
+++ b/xen/drivers/passthrough/vtd/quirks.c	Thu Nov 20 22:00:51 2014 -0700
@@ -50,6 +50,11 @@
 #define IS_ILK(id)    (id == 0x00408086 || id == 0x00448086 || id== 0x00628086 || id == 0x006A8086)
 #define IS_CPT(id)    (id == 0x01008086 || id == 0x01048086)
 
+/* SandyBridge IGD timeouts in milliseconds */
+#define SNB_IGD_TIMEOUT_LEGACY    1000
+#define SNB_IGD_TIMEOUT            670
+static u32 snb_igd_timeout = 0;
+
 static u32 __read_mostly ioh_id;
 static u32 __initdata igd_id;
 bool_t __read_mostly rwbf_quirk;
@@ -158,6 +163,16 @@
  * Workaround is to prevent graphics get into RC6
  * state when doing VT-d IOTLB operations, do the VT-d
  * IOTLB operation, and then re-enable RC6 state.
+ *
+ * This quirk is enabled with the snb_igd_quirk command
+ * line parameter.  Specifying snb_igd_quirk with no value
+ * (or any of the standard boolean values) enables this
+ * quirk and sets the timeout to the legacy timeout of
+ * 1000 msec.  Setting this parameter to the string
+ * "default" enables this quirk and sets the timeout to
+ * the theoretical maximum of 670 msec.  Setting this
+ * parameter to a numerical value enables the quirk and
+ * sets the timeout to that numerical number of msecs.
  */
 static void snb_vtd_ops_preamble(struct iommu* iommu)
 {
@@ -177,7 +192,7 @@
     start_time = NOW();
     while ( (*(volatile u32 *)(igd_reg_va + 0x22AC) & 0xF) != 0 )
     {
-        if ( NOW() > start_time + DMAR_OPERATION_TIMEOUT )
+        if ( NOW() > start_time + snb_igd_timeout )
         {
             dprintk(XENLOG_INFO VTDPREFIX,
                     "snb_vtd_ops_preamble: failed to disable idle handshake\n");
@@ -208,13 +223,10 @@
  * call before VT-d translation enable and IOTLB flush operations.
  */
 
-static int snb_igd_quirk;
-boolean_param("snb_igd_quirk", snb_igd_quirk);
-
 void vtd_ops_preamble_quirk(struct iommu* iommu)
 {
     cantiga_vtd_ops_preamble(iommu);
-    if ( snb_igd_quirk )
+    if ( snb_igd_timeout != 0 )
     {
         spin_lock(&igd_lock);
 
@@ -228,7 +240,7 @@
  */
 void vtd_ops_postamble_quirk(struct iommu* iommu)
 {
-    if ( snb_igd_quirk )
+    if ( snb_igd_timeout != 0 )
     {
         snb_vtd_ops_postamble(iommu);
 
@@ -237,6 +249,36 @@
     }
 }
 
+static void __init parse_snb_timeout(const char *s)
+{
+    int t;
+
+    t = parse_bool(s);
+    if ( t < 0 )
+    {
+        if ( *s == '\0' )
+        {
+            t = SNB_IGD_TIMEOUT_LEGACY;
+        }
+        else if ( strcmp(s, "default") == 0 )
+        {
+            t = SNB_IGD_TIMEOUT;
+        }
+        else
+        {
+            t = strtoul(s, NULL, 0);
+        }
+    }
+    else
+    {
+        t = t ? SNB_IGD_TIMEOUT_LEGACY : 0;
+    }
+    snb_igd_timeout = MILLISECS(t);
+
+    return;
+}
+custom_param("snb_igd_quirk", parse_snb_timeout);
+
 /* 5500/5520/X58 Chipset Interrupt remapping errata, for stepping B-3.
  * Fixed in stepping C-2. */
 static void __init tylersburg_intremap_quirk(void)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 05:12:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 05:12:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrgWA-00047x-5f; Fri, 21 Nov 2014 05:12:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <n0ano@n0ano.com>) id 1XrgW8-00047s-BI
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 05:12:24 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	A1/E7-02696-7B9CE645; Fri, 21 Nov 2014 05:12:23 +0000
X-Env-Sender: n0ano@n0ano.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416546740!13902648!1
X-Originating-IP: [67.41.209.129]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8702 invoked from network); 21 Nov 2014 05:12:22 -0000
Received: from willie.n0ano.com (HELO willie.n0ano.com) (67.41.209.129)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Nov 2014 05:12:22 -0000
Received: from maat.n0ano.com ([192.168.1.25])
	by willie.n0ano.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <n0ano@n0ano.com>)
	id 1XrgW3-0006Gq-Uf; Thu, 20 Nov 2014 22:12:19 -0700
Received: from n0ano by maat.n0ano.com with local (Exim 4.77)
	(envelope-from <n0ano@n0ano.com>)
	id 1XrgW3-0005xv-5h; Thu, 20 Nov 2014 22:12:19 -0700
Date: Thu, 20 Nov 2014 22:12:19 -0700
From: "Donald D. Dugger" <donald.d.dugger@intel.com>
To: xen-devel@lists.xen.org
Message-ID: <20141121051219.GB22258@n0ano.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: eddie.dong@intel.com, will.auld@intel.com, allen.m.kay@intel.com,
	JBeulich@suse.com, n0ano@n0ano.com
Subject: [Xen-devel] [PATCH V4] Decouple SandyBridge quirk from VTd timeout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently the quirk code for SandyBridge uses the VTd timeout value when
writing to an IGD register.  This is the wrong timeout to use and, at
1000 msec., is also much too large.  This patch changes the quirk code
to use a timeout that is specific to the IGD device and allows the user
control of the timeout.

Boolean settings for the boot parameter `snb_igd_quirk' keep their current
meaning, enabling or disabling the quirk code with a timeout of 1000 msec.

In addition specifying `snb_igd_quirk=default' will enable the code and
set the timeout to the theoretical maximum of 670 msec.  For finer control,
specifying `snb_igd_quirk=n', where `n' is a decimal number, will enable
the code and set the timeout to `n' msec.

Signed-off-by: Don Dugger <donald.d.dugger@intel.com>
-- 
diff -r 9d485e2c8339 xen/drivers/passthrough/vtd/quirks.c
--- a/xen/drivers/passthrough/vtd/quirks.c	Mon Nov 10 12:03:36 2014 +0000
+++ b/xen/drivers/passthrough/vtd/quirks.c	Thu Nov 20 22:00:51 2014 -0700
@@ -50,6 +50,11 @@
 #define IS_ILK(id)    (id == 0x00408086 || id == 0x00448086 || id== 0x00628086 || id == 0x006A8086)
 #define IS_CPT(id)    (id == 0x01008086 || id == 0x01048086)
 
+/* SandyBridge IGD timeouts in milliseconds */
+#define SNB_IGD_TIMEOUT_LEGACY    1000
+#define SNB_IGD_TIMEOUT            670
+static u32 snb_igd_timeout = 0;
+
 static u32 __read_mostly ioh_id;
 static u32 __initdata igd_id;
 bool_t __read_mostly rwbf_quirk;
@@ -158,6 +163,16 @@
  * Workaround is to prevent graphics get into RC6
  * state when doing VT-d IOTLB operations, do the VT-d
  * IOTLB operation, and then re-enable RC6 state.
+ *
+ * This quirk is enabled with the snb_igd_quirk command
+ * line parameter.  Specifying snb_igd_quirk with no value
+ * (or any of the standard boolean values) enables this
+ * quirk and sets the timeout to the legacy timeout of
+ * 1000 msec.  Setting this parameter to the string
+ * "default" enables this quirk and sets the timeout to
+ * the theoretical maximum of 670 msec.  Setting this
+ * parameter to a numerical value enables the quirk and
+ * sets the timeout to that numerical number of msecs.
  */
 static void snb_vtd_ops_preamble(struct iommu* iommu)
 {
@@ -177,7 +192,7 @@
     start_time = NOW();
     while ( (*(volatile u32 *)(igd_reg_va + 0x22AC) & 0xF) != 0 )
     {
-        if ( NOW() > start_time + DMAR_OPERATION_TIMEOUT )
+        if ( NOW() > start_time + snb_igd_timeout )
         {
             dprintk(XENLOG_INFO VTDPREFIX,
                     "snb_vtd_ops_preamble: failed to disable idle handshake\n");
@@ -208,13 +223,10 @@
  * call before VT-d translation enable and IOTLB flush operations.
  */
 
-static int snb_igd_quirk;
-boolean_param("snb_igd_quirk", snb_igd_quirk);
-
 void vtd_ops_preamble_quirk(struct iommu* iommu)
 {
     cantiga_vtd_ops_preamble(iommu);
-    if ( snb_igd_quirk )
+    if ( snb_igd_timeout != 0 )
     {
         spin_lock(&igd_lock);
 
@@ -228,7 +240,7 @@
  */
 void vtd_ops_postamble_quirk(struct iommu* iommu)
 {
-    if ( snb_igd_quirk )
+    if ( snb_igd_timeout != 0 )
     {
         snb_vtd_ops_postamble(iommu);
 
@@ -237,6 +249,36 @@
     }
 }
 
+static void __init parse_snb_timeout(const char *s)
+{
+    int t;
+
+    t = parse_bool(s);
+    if ( t < 0 )
+    {
+        if ( *s == '\0' )
+        {
+            t = SNB_IGD_TIMEOUT_LEGACY;
+        }
+        else if ( strcmp(s, "default") == 0 )
+        {
+            t = SNB_IGD_TIMEOUT;
+        }
+        else
+        {
+            t = strtoul(s, NULL, 0);
+        }
+    }
+    else
+    {
+        t = t ? SNB_IGD_TIMEOUT_LEGACY : 0;
+    }
+    snb_igd_timeout = MILLISECS(t);
+
+    return;
+}
+custom_param("snb_igd_quirk", parse_snb_timeout);
+
 /* 5500/5520/X58 Chipset Interrupt remapping errata, for stepping B-3.
  * Fixed in stepping C-2. */
 static void __init tylersburg_intremap_quirk(void)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 05:41:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 05:41:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrgyC-0004R5-Oi; Fri, 21 Nov 2014 05:41:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrgyA-0004Qz-Em
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 05:41:22 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	61/8B-02576-180DE645; Fri, 21 Nov 2014 05:41:21 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416548480!13870418!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6992 invoked from network); 21 Nov 2014 05:41:20 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 05:41:20 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9751CAB09;
	Fri, 21 Nov 2014 05:41:16 +0000 (UTC)
Message-ID: <546ED07B.3030208@suse.com>
Date: Fri, 21 Nov 2014 06:41:15 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	Xen-devel List <xen-devel@lists.xen.org>
References: <546E32BB.8090909@citrix.com>
In-Reply-To: <546E32BB.8090909@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 07:28 PM, Andrew Cooper wrote:
> Hello,
>
> Tim, David and I were discussing this over lunch.  This email is a
> (hopefully accurate) account of our findings, and potential solutions.
> (If I have messed up, please shout.)
>
> Currently, correct live migration of PV domains relies on the toolstack
> (which has a live mapping of the guests p2m) not observing stale values
> when the guest updates its p2m, and the race condition between a p2m
> update and an m2p update.  Realistically, this means no updates to the
> p2m at all, due to several potential race conditions.  Should any race
> conditions happen (e.g. ballooning while live migrating), the effects
> could be anything from an aborted migration to VM memory corruption.
>
> It should be noted that migrationv2 does not fix any of this.  It alters
> the way in which some race conditions might be observed.  During
> development of migrationv2, there was an explicit non-requirement of
> fixing the existing Ballooning+LiveMigration issues we were aware,
> although at the time, we were not aware of this specific set of issues.
> Our goal was to simply make migrationv2 work in the same circumstances
> as previously, but with a bitness-agnostic wire format and
> forward-extensible protocol.
>
>
> As far as these issues are concerned, there are two distinct p2m
> modifications which we care about:
> 1) p2m structure changes (rearranging the layout of the p2m)
> 2) p2m content changes (altering entries in the p2m)
>
> There is no possible way for the toolstack to prevent a domain from
> altering its p2m.  At the moment, ballooning typically only occurs when
> requested by the toolstack, but the underlying operations
> (increase/decrease_reservation, mem_exchange, etc) can be used by the
> guest at any point.  This includes Wei's guest memory fragmentation
> changes.  Changes to the content of the p2m also occur for grant map and
> unmap operations.
>
>
> Currently in PV guests, the p2m is implemented using a 3-level tree,
> with its root in the guests shared_info page.  It provides a hard VM
> memory limit of 4TB for 32bit PV guests (which is far higher than the
> 128GB limit from the compat p2m mappings), or 512GB for 64bit PV guests.
>
> Juergen has a proposed new p2m interface using a virtual linear
> mapping.  This is conceptually similar to the previous implementation
> (which is fine from the toolstacks point of view), but far less
> complicated from the guests point of view, and removes the memory limits
> imposed by the p2m structure.
>
> The new virtual linear mapping suffers from the same interaction issues
> as the old 3-level tree did, but the introduction of the new interface
> affords us an opportunity to make all API modifications at once to
> reduce churn.
>
>
> During live migration, the toolstack maps the guests p2m into a linear
> mapping in the toolstacks virtual address space.  This is done once at
> the start of migration, and never subsequently altered.  During live
> migration, the p2m is cross-verified with the m2p, and frames are sent
> using pfns as a reference, as they will be located in different frames
> on the receiving side.
>
> Should the guest change the p2m structure during live migration, the
> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> resulting in bogus cross-referencing.  Should the guest change an entry
> in the p2m, the p2m frame itself will be resent as it would be marked as
> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> probably stale on the receiving side.
>
>
> Another factor which needs to be taken into account is Remus/COLO, which
> run the domains under live migration conditions for the duration of
> their lifetime.
>
> During the live part of migration, the toolstack already has to be able
> to tolerate failures to normalise the pagetables, which result as a
> consequent of the pagetables being in active.  These failures are fatal
> on the final iteration after the guest has been paused, but the same
> logic could be extended to p2m/m2p issues, if needed.
>
>
> There are several potential solutions to these problems.
>
> 1) Freeze the guests p2m during live migrate
>
> This is the simplest sounding option, but is quite problematic from the
> point of view of the guest.  It is essentially a shared spinlock between
> the toolstack and the guest kernel.  It would prevent any grant
> map/unmap operations from occurring, and might interact badly with
> certain p2m updated in the guest which would previously be expected to
> unconditionally succeed.
>
> Pros) (Can't think of any)
> Cons) Not easy to implement (even conceptually), requires invasive guest
> changes, will cripple Remus/COLO
>
>
> 2) Deep p2m dirty tracking
>
> In the case that a p2m frame is discovered dirty in the logdirty bitmap,
> we can be certain that a write has occurred to it, and in the common
> case, means that the mapping has changed.  The toolstack could maintain
> a non-live copy of the p2m which is updated as new frames are sent.
> When a dirty p2m frame is found, the live and non-live copies can be
> consulted to find which pfn mappings have changed, and locally mark all
> the altered pfns for retransmit.
>
> Pros) No guest changes required
> Cons) Toolstack needs to keep an additional copy of the guests p2m on
> the sending side
>
> 3) Eagerly check for p2m structure changes.
>
> p2m structure changes are rare after boot, but not impossible.  Each
> iteration of live migration, the toolstack can check for dirty
> higher-level p2m frames in the dirty bitmap.  In the case that a
> structure update occurs, the toolstack can use information it already
> has to calculate a subset of pfns affected by the update, and mark them
> for resending.  (This can currently be done to the frame granularity
> given the p2m frame lit, but in combination with 2), could result in
> fewer pfns needing resending.)
>
> Pros) No guest changes required.
> Cons) Moderately high toolstack overhead,  Possibility to resend far
> more pfns than strictly required.
>
> 4) Request p2m structure change updates from the guest
>
> The guest could provide a "p2m generation count" to allow the toolstack
> to evaluate whether the structure had changed.  This would allow the
> live part of migration to periodically re-evaluate whether it should
> remap the p2m to avoid stale mappings.
>
> Pros) Easy to implement alongside the virtual linear mapping support.
> Easy for toolstack and guest
> Cons) Only works with new virtual linear guests.
>
>
> Proposed solution:  A combination of 2, 3 and 4.
>
> For legacy 3-level p2m guests, the toolstack can detect p2m structure
> updates by tracking the p2m top and mid levels in the logdirty bitmap,
> and invalidating the modified subset of pfns.  It has to eagerly check
> the p2m frame list list mfn entry in the shared info to see whether the
> guest has swapped onto a completely new p2m.
>
> For a virtual linear map, the intermediate levels are not available to
> track, but we can require that the guest increment p2m generation clock
> in the shared info.  When the structure changes, the toolstack can remap
> the p2m and calculate the altered subset of pfns, and mark for resend.
>
> The toolstack must also track changes in the p2m itself, and compare to
> a local copy showing the mapping at the time at which the pfn was last
> sent.  This can be used to work out which p2m mappings have changed, and
> also be used to confirm whether the pfns on the receiving side are stale
> or not.
>
> I believe this covered all cases and race conditions.  In the case that
> the p2m is updated before the m2p, the p2m frame will be marked dirty in
> the bitmap, and discoverable on the next iteration.  At that point, if
> the p2m and m2p are inconsistent, the pfn will be deferred until the
> final iteration.  If not, the frame is sent and everything is all ok.
> In the case that the p2m is updated after the m2p, the p2m/m2p will be
> consistent when the dirty bitmap is acted on.
>
>
> Thoughts? (for anyone who has made it this far :)  I think I have
> covered everything.)

Sounds okay.

Two remarks regarding the virtual linear map:
- The intermediate levels could be tracked, as they are memory pages as
   well. It is not practical to do so, however, as there might be lots of
   changes not related to the p2m.
- The generation count is being checked by the tools in a lazy manner.
   This will require an increment of the count by the guest only after
   changing the structure of the p2m map, I think.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 05:41:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 05:41:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrgyC-0004R5-Oi; Fri, 21 Nov 2014 05:41:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrgyA-0004Qz-Em
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 05:41:22 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	61/8B-02576-180DE645; Fri, 21 Nov 2014 05:41:21 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416548480!13870418!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6992 invoked from network); 21 Nov 2014 05:41:20 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 05:41:20 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9751CAB09;
	Fri, 21 Nov 2014 05:41:16 +0000 (UTC)
Message-ID: <546ED07B.3030208@suse.com>
Date: Fri, 21 Nov 2014 06:41:15 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	Xen-devel List <xen-devel@lists.xen.org>
References: <546E32BB.8090909@citrix.com>
In-Reply-To: <546E32BB.8090909@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/20/2014 07:28 PM, Andrew Cooper wrote:
> Hello,
>
> Tim, David and I were discussing this over lunch.  This email is a
> (hopefully accurate) account of our findings, and potential solutions.
> (If I have messed up, please shout.)
>
> Currently, correct live migration of PV domains relies on the toolstack
> (which has a live mapping of the guests p2m) not observing stale values
> when the guest updates its p2m, and the race condition between a p2m
> update and an m2p update.  Realistically, this means no updates to the
> p2m at all, due to several potential race conditions.  Should any race
> conditions happen (e.g. ballooning while live migrating), the effects
> could be anything from an aborted migration to VM memory corruption.
>
> It should be noted that migrationv2 does not fix any of this.  It alters
> the way in which some race conditions might be observed.  During
> development of migrationv2, there was an explicit non-requirement of
> fixing the existing Ballooning+LiveMigration issues we were aware,
> although at the time, we were not aware of this specific set of issues.
> Our goal was to simply make migrationv2 work in the same circumstances
> as previously, but with a bitness-agnostic wire format and
> forward-extensible protocol.
>
>
> As far as these issues are concerned, there are two distinct p2m
> modifications which we care about:
> 1) p2m structure changes (rearranging the layout of the p2m)
> 2) p2m content changes (altering entries in the p2m)
>
> There is no possible way for the toolstack to prevent a domain from
> altering its p2m.  At the moment, ballooning typically only occurs when
> requested by the toolstack, but the underlying operations
> (increase/decrease_reservation, mem_exchange, etc) can be used by the
> guest at any point.  This includes Wei's guest memory fragmentation
> changes.  Changes to the content of the p2m also occur for grant map and
> unmap operations.
>
>
> Currently in PV guests, the p2m is implemented using a 3-level tree,
> with its root in the guests shared_info page.  It provides a hard VM
> memory limit of 4TB for 32bit PV guests (which is far higher than the
> 128GB limit from the compat p2m mappings), or 512GB for 64bit PV guests.
>
> Juergen has a proposed new p2m interface using a virtual linear
> mapping.  This is conceptually similar to the previous implementation
> (which is fine from the toolstacks point of view), but far less
> complicated from the guests point of view, and removes the memory limits
> imposed by the p2m structure.
>
> The new virtual linear mapping suffers from the same interaction issues
> as the old 3-level tree did, but the introduction of the new interface
> affords us an opportunity to make all API modifications at once to
> reduce churn.
>
>
> During live migration, the toolstack maps the guests p2m into a linear
> mapping in the toolstacks virtual address space.  This is done once at
> the start of migration, and never subsequently altered.  During live
> migration, the p2m is cross-verified with the m2p, and frames are sent
> using pfns as a reference, as they will be located in different frames
> on the receiving side.
>
> Should the guest change the p2m structure during live migration, the
> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> resulting in bogus cross-referencing.  Should the guest change an entry
> in the p2m, the p2m frame itself will be resent as it would be marked as
> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> probably stale on the receiving side.
>
>
> Another factor which needs to be taken into account is Remus/COLO, which
> run the domains under live migration conditions for the duration of
> their lifetime.
>
> During the live part of migration, the toolstack already has to be able
> to tolerate failures to normalise the pagetables, which result as a
> consequent of the pagetables being in active.  These failures are fatal
> on the final iteration after the guest has been paused, but the same
> logic could be extended to p2m/m2p issues, if needed.
>
>
> There are several potential solutions to these problems.
>
> 1) Freeze the guests p2m during live migrate
>
> This is the simplest sounding option, but is quite problematic from the
> point of view of the guest.  It is essentially a shared spinlock between
> the toolstack and the guest kernel.  It would prevent any grant
> map/unmap operations from occurring, and might interact badly with
> certain p2m updated in the guest which would previously be expected to
> unconditionally succeed.
>
> Pros) (Can't think of any)
> Cons) Not easy to implement (even conceptually), requires invasive guest
> changes, will cripple Remus/COLO
>
>
> 2) Deep p2m dirty tracking
>
> In the case that a p2m frame is discovered dirty in the logdirty bitmap,
> we can be certain that a write has occurred to it, and in the common
> case, means that the mapping has changed.  The toolstack could maintain
> a non-live copy of the p2m which is updated as new frames are sent.
> When a dirty p2m frame is found, the live and non-live copies can be
> consulted to find which pfn mappings have changed, and locally mark all
> the altered pfns for retransmit.
>
> Pros) No guest changes required
> Cons) Toolstack needs to keep an additional copy of the guests p2m on
> the sending side
>
> 3) Eagerly check for p2m structure changes.
>
> p2m structure changes are rare after boot, but not impossible.  Each
> iteration of live migration, the toolstack can check for dirty
> higher-level p2m frames in the dirty bitmap.  In the case that a
> structure update occurs, the toolstack can use information it already
> has to calculate a subset of pfns affected by the update, and mark them
> for resending.  (This can currently be done to the frame granularity
> given the p2m frame lit, but in combination with 2), could result in
> fewer pfns needing resending.)
>
> Pros) No guest changes required.
> Cons) Moderately high toolstack overhead,  Possibility to resend far
> more pfns than strictly required.
>
> 4) Request p2m structure change updates from the guest
>
> The guest could provide a "p2m generation count" to allow the toolstack
> to evaluate whether the structure had changed.  This would allow the
> live part of migration to periodically re-evaluate whether it should
> remap the p2m to avoid stale mappings.
>
> Pros) Easy to implement alongside the virtual linear mapping support.
> Easy for toolstack and guest
> Cons) Only works with new virtual linear guests.
>
>
> Proposed solution:  A combination of 2, 3 and 4.
>
> For legacy 3-level p2m guests, the toolstack can detect p2m structure
> updates by tracking the p2m top and mid levels in the logdirty bitmap,
> and invalidating the modified subset of pfns.  It has to eagerly check
> the p2m frame list list mfn entry in the shared info to see whether the
> guest has swapped onto a completely new p2m.
>
> For a virtual linear map, the intermediate levels are not available to
> track, but we can require that the guest increment p2m generation clock
> in the shared info.  When the structure changes, the toolstack can remap
> the p2m and calculate the altered subset of pfns, and mark for resend.
>
> The toolstack must also track changes in the p2m itself, and compare to
> a local copy showing the mapping at the time at which the pfn was last
> sent.  This can be used to work out which p2m mappings have changed, and
> also be used to confirm whether the pfns on the receiving side are stale
> or not.
>
> I believe this covered all cases and race conditions.  In the case that
> the p2m is updated before the m2p, the p2m frame will be marked dirty in
> the bitmap, and discoverable on the next iteration.  At that point, if
> the p2m and m2p are inconsistent, the pfn will be deferred until the
> final iteration.  If not, the frame is sent and everything is all ok.
> In the case that the p2m is updated after the m2p, the p2m/m2p will be
> consistent when the dirty bitmap is acted on.
>
>
> Thoughts? (for anyone who has made it this far :)  I think I have
> covered everything.)

Sounds okay.

Two remarks regarding the virtual linear map:
- The intermediate levels could be tracked, as they are memory pages as
   well. It is not practical to do so, however, as there might be lots of
   changes not related to the p2m.
- The generation count is being checked by the tools in a lazy manner.
   This will require an increment of the count by the guest only after
   changing the structure of the p2m map, I think.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 06:26:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 06:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrhfp-00054P-1I; Fri, 21 Nov 2014 06:26:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xrhfn-00054K-2S
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 06:26:27 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	67/C2-03145-21BDE645; Fri, 21 Nov 2014 06:26:26 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416551185!13335131!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11345 invoked from network); 21 Nov 2014 06:26:25 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-27.messagelabs.com with SMTP;
	21 Nov 2014 06:26:25 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 20 Nov 2014 22:26:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,429,1413270000"; d="scan'208";a="635722043"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.112])
	([10.238.130.112])
	by fmsmga002.fm.intel.com with ESMTP; 20 Nov 2014 22:26:21 -0800
Message-ID: <546EDB0D.8030605@intel.com>
Date: Fri, 21 Nov 2014 14:26:21 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>	<544A7CCB0200007800041FBA@mail.emea.novell.com>	<544DB809.9020108@intel.com>	<544E22410200007800042568@mail.emea.novell.com>	<544F27BD.7060003@intel.com>	<544F749A0200007800042B74@mail.emea.novell.com>	<54508F1B.2030903@intel.com>	<5450BBF50200007800043032@mail.emea.novell.com>	<5451D2B5.50609@intel.com>	<54520F2C0200007800043625@mail.emea.novell.com>	<5452F207.1070105@intel.com>	<545352F40200007800043D82@mail.emea.novell.com>	<5456E6E9.1080104@intel.com>	<545750AA02000078000443AD@mail.emea.novell.com>	<54574BC0.7000709@intel.com>	<54575CD60200007800044426@mail.emea.novell.com>	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
In-Reply-To: <545760B60200007800044471@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 18:02, Jan Beulich wrote:
>>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 17:45, Jan Beulich wrote:
>>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
>>>> On 2014/11/3 16:53, Jan Beulich wrote:
>>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>>>>>>> when we really need them.
>>>>>>>>>>>
>>>>>>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>>>>>> include that header (making sure declaration and definition are and
>>>>>>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>>>>>>> (and certain other code system components) the consequences of
>>>>>>>>>>> being lax are much more severe.
>>>>>>>>>>
>>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>>>>>> '<xen/memory.h>,
>>>>>>>>>>
>>>>>>>>>> #include "util.h"
>>>>>>>>>> ...
>>>>>>>>>> #include <xen/memory.h>
>>>>>>>>>>
>>>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>>>>>
>>>>>>>>> Redefine? I said forward declare.
>>>>>>>>
>>>>>>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>>>>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>>>>>
>>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>>>>>
>>>>>>> To me this looks very much like poor programming style, even if in
>>>>>>> the context of hvmloader communicating information via global
>>>>>>> variables rather than function arguments and return values is
>>>>>>
>>>>>> Do you mean you don't like a global variable? But it can be use to get
>>>>>> RDM without more hypercall or function call in the context of hvmloader.
>>>>>
>>>>> This argument which you brought up before, and which we commented
>>>>> on before, is pretty pointless. We don't really care much about doing
>>>>> one or two more hypercalls from hvmloader, unless these would be
>>>>> long-running ones.
>>>>>
>>>>
>>>> Another benefit to use a global variable is that we wouldn't allocate
>>>> xen_reserved_device_memory * N each time, and reduce some duplicated
>>>> codes, unless you mean I should define that as static inside in local.
>>>
>>> Now this reason is indeed worth a consideration. How many times is
>>> the data being needed/retrieved?
>>
>> Currently there are two cases in tools/hvmloader, setup pci and build
>> e820 table. Each time, as you know we don't know how may entries we
>> should require, so we always allocate one instance then according to the
>> return value to allocate the proper instances to get that.
>
> Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
> a more "normal" interface.
>

Just go back here since I realize we always use mem_alloc(), which is 
pick from RESERVED_MEMORY, to allocate all buffer inside this hypercall 
caller in hvmloader, but unfortunately we have no any associated free 
function implementation in hvmloader, so if we call this multiple times 
this means it really waster more memory in RESERVED_MEMORY. So I still 
think one global variable should be fine.

Thanks
Tiejun


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 06:26:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 06:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrhfp-00054P-1I; Fri, 21 Nov 2014 06:26:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xrhfn-00054K-2S
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 06:26:27 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	67/C2-03145-21BDE645; Fri, 21 Nov 2014 06:26:26 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416551185!13335131!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11345 invoked from network); 21 Nov 2014 06:26:25 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-27.messagelabs.com with SMTP;
	21 Nov 2014 06:26:25 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 20 Nov 2014 22:26:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,429,1413270000"; d="scan'208";a="635722043"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.112])
	([10.238.130.112])
	by fmsmga002.fm.intel.com with ESMTP; 20 Nov 2014 22:26:21 -0800
Message-ID: <546EDB0D.8030605@intel.com>
Date: Fri, 21 Nov 2014 14:26:21 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>	<544A7CCB0200007800041FBA@mail.emea.novell.com>	<544DB809.9020108@intel.com>	<544E22410200007800042568@mail.emea.novell.com>	<544F27BD.7060003@intel.com>	<544F749A0200007800042B74@mail.emea.novell.com>	<54508F1B.2030903@intel.com>	<5450BBF50200007800043032@mail.emea.novell.com>	<5451D2B5.50609@intel.com>	<54520F2C0200007800043625@mail.emea.novell.com>	<5452F207.1070105@intel.com>	<545352F40200007800043D82@mail.emea.novell.com>	<5456E6E9.1080104@intel.com>	<545750AA02000078000443AD@mail.emea.novell.com>	<54574BC0.7000709@intel.com>	<54575CD60200007800044426@mail.emea.novell.com>	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
In-Reply-To: <545760B60200007800044471@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/3 18:02, Jan Beulich wrote:
>>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 17:45, Jan Beulich wrote:
>>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
>>>> On 2014/11/3 16:53, Jan Beulich wrote:
>>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern' to them
>>>>>>>>>>>> when we really need them.
>>>>>>>>>>>
>>>>>>>>>>> Please stop thinking this way. Declarations for things defined in .c
>>>>>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>>>>>> include that header (making sure declaration and definition are and
>>>>>>>>>>> remain in sync). I hate having to again repeat my remark that you
>>>>>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>>>>>> Robust and maintainable code are a requirement in the hypervisor
>>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't also
>>>>>>>>>>> apply to application code. It's just that in the hypervisor and kernel
>>>>>>>>>>> (and certain other code system components) the consequences of
>>>>>>>>>>> being lax are much more severe.
>>>>>>>>>>
>>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>>>>>> '<xen/memory.h>,
>>>>>>>>>>
>>>>>>>>>> #include "util.h"
>>>>>>>>>> ...
>>>>>>>>>> #include <xen/memory.h>
>>>>>>>>>>
>>>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>>>>>
>>>>>>>>> Redefine? I said forward declare.
>>>>>>>>
>>>>>>>> Seems we just need to declare hvm_get_reserved_device_memory_map() in
>>>>>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>>>>>
>>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>>>>>
>>>>>>> To me this looks very much like poor programming style, even if in
>>>>>>> the context of hvmloader communicating information via global
>>>>>>> variables rather than function arguments and return values is
>>>>>>
>>>>>> Do you mean you don't like a global variable? But it can be use to get
>>>>>> RDM without more hypercall or function call in the context of hvmloader.
>>>>>
>>>>> This argument which you brought up before, and which we commented
>>>>> on before, is pretty pointless. We don't really care much about doing
>>>>> one or two more hypercalls from hvmloader, unless these would be
>>>>> long-running ones.
>>>>>
>>>>
>>>> Another benefit to use a global variable is that we wouldn't allocate
>>>> xen_reserved_device_memory * N each time, and reduce some duplicated
>>>> codes, unless you mean I should define that as static inside in local.
>>>
>>> Now this reason is indeed worth a consideration. How many times is
>>> the data being needed/retrieved?
>>
>> Currently there are two cases in tools/hvmloader, setup pci and build
>> e820 table. Each time, as you know we don't know how may entries we
>> should require, so we always allocate one instance then according to the
>> return value to allocate the proper instances to get that.
>
> Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
> a more "normal" interface.
>

Just go back here since I realize we always use mem_alloc(), which is 
pick from RESERVED_MEMORY, to allocate all buffer inside this hypercall 
caller in hvmloader, but unfortunately we have no any associated free 
function implementation in hvmloader, so if we call this multiple times 
this means it really waster more memory in RESERVED_MEMORY. So I still 
think one global variable should be fine.

Thanks
Tiejun


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 07:44:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 07:44:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrit7-00064n-W1; Fri, 21 Nov 2014 07:44:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xrit6-00064i-LV
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 07:44:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	57/88-25276-F4DEE645; Fri, 21 Nov 2014 07:44:15 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416555843!13986452!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28889 invoked from network); 21 Nov 2014 07:44:03 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-21.messagelabs.com with SMTP;
	21 Nov 2014 07:44:03 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 20 Nov 2014 23:44:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,429,1413270000"; d="scan'208";a="611659764"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by orsmga001.jf.intel.com with ESMTP; 20 Nov 2014 23:43:58 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 21 Nov 2014 15:43:17 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Fri, 21 Nov 2014 15:43:16 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get
	reserved device memory maps
Thread-Index: AQHQBVQc6n7FIBL490yut4WGX7kogZxqssSA
Date: Fri, 21 Nov 2014 07:43:15 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
	<546EDB0D.8030605@intel.com>
In-Reply-To: <546EDB0D.8030605@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: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Chen, Tiejun
> Sent: Friday, November 21, 2014 2:26 PM
> 
> On 2014/11/3 18:02, Jan Beulich wrote:
> >>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
> >> On 2014/11/3 17:45, Jan Beulich wrote:
> >>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
> >>>> On 2014/11/3 16:53, Jan Beulich wrote:
> >>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
> >>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
> >>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
> >>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
> >>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
> >>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
> >>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
> >>>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern'
> to them
> >>>>>>>>>>>> when we really need them.
> >>>>>>>>>>>
> >>>>>>>>>>> Please stop thinking this way. Declarations for things defined
> in .c
> >>>>>>>>>>> files are to be present in headers, and the defining .c file has to
> >>>>>>>>>>> include that header (making sure declaration and definition are
> and
> >>>>>>>>>>> remain in sync). I hate having to again repeat my remark that
> you
> >>>>>>>>>>> shouldn't forget it's not application code that you're modifying.
> >>>>>>>>>>> Robust and maintainable code are a requirement in the
> hypervisor
> >>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
> >>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't
> also
> >>>>>>>>>>> apply to application code. It's just that in the hypervisor and
> kernel
> >>>>>>>>>>> (and certain other code system components) the consequences
> of
> >>>>>>>>>>> being lax are much more severe.
> >>>>>>>>>>
> >>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
> >>>>>>>>>> '<xen/memory.h>,
> >>>>>>>>>>
> >>>>>>>>>> #include "util.h"
> >>>>>>>>>> ...
> >>>>>>>>>> #include <xen/memory.h>
> >>>>>>>>>>
> >>>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
> >>>>>>>>>
> >>>>>>>>> Redefine? I said forward declare.
> >>>>>>>>
> >>>>>>>> Seems we just need to declare
> hvm_get_reserved_device_memory_map() in
> >>>>>>>> the head file, tools/firmware/hvmloader/util.h,
> >>>>>>>>
> >>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
> >>>>>>>
> >>>>>>> To me this looks very much like poor programming style, even if in
> >>>>>>> the context of hvmloader communicating information via global
> >>>>>>> variables rather than function arguments and return values is
> >>>>>>
> >>>>>> Do you mean you don't like a global variable? But it can be use to get
> >>>>>> RDM without more hypercall or function call in the context of
> hvmloader.
> >>>>>
> >>>>> This argument which you brought up before, and which we commented
> >>>>> on before, is pretty pointless. We don't really care much about doing
> >>>>> one or two more hypercalls from hvmloader, unless these would be
> >>>>> long-running ones.
> >>>>>
> >>>>
> >>>> Another benefit to use a global variable is that we wouldn't allocate
> >>>> xen_reserved_device_memory * N each time, and reduce some
> duplicated
> >>>> codes, unless you mean I should define that as static inside in local.
> >>>
> >>> Now this reason is indeed worth a consideration. How many times is
> >>> the data being needed/retrieved?
> >>
> >> Currently there are two cases in tools/hvmloader, setup pci and build
> >> e820 table. Each time, as you know we don't know how may entries we
> >> should require, so we always allocate one instance then according to the
> >> return value to allocate the proper instances to get that.
> >
> > Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
> > a more "normal" interface.
> >
> 
> Just go back here since I realize we always use mem_alloc(), which is
> pick from RESERVED_MEMORY, to allocate all buffer inside this hypercall
> caller in hvmloader, but unfortunately we have no any associated free
> function implementation in hvmloader, so if we call this multiple times
> this means it really waster more memory in RESERVED_MEMORY. So I still
> think one global variable should be fine.
> 

it's natural to get reserved information once, and then saved for either
one-time or multiple-time references.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 07:44:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 07:44:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrit7-00064n-W1; Fri, 21 Nov 2014 07:44:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xrit6-00064i-LV
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 07:44:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	57/88-25276-F4DEE645; Fri, 21 Nov 2014 07:44:15 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416555843!13986452!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28889 invoked from network); 21 Nov 2014 07:44:03 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-21.messagelabs.com with SMTP;
	21 Nov 2014 07:44:03 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 20 Nov 2014 23:44:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,429,1413270000"; d="scan'208";a="611659764"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by orsmga001.jf.intel.com with ESMTP; 20 Nov 2014 23:43:58 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 21 Nov 2014 15:43:17 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Fri, 21 Nov 2014 15:43:16 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get
	reserved device memory maps
Thread-Index: AQHQBVQc6n7FIBL490yut4WGX7kogZxqssSA
Date: Fri, 21 Nov 2014 07:43:15 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
	<546EDB0D.8030605@intel.com>
In-Reply-To: <546EDB0D.8030605@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: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Chen, Tiejun
> Sent: Friday, November 21, 2014 2:26 PM
> 
> On 2014/11/3 18:02, Jan Beulich wrote:
> >>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
> >> On 2014/11/3 17:45, Jan Beulich wrote:
> >>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
> >>>> On 2014/11/3 16:53, Jan Beulich wrote:
> >>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
> >>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
> >>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
> >>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
> >>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
> >>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
> >>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
> >>>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern'
> to them
> >>>>>>>>>>>> when we really need them.
> >>>>>>>>>>>
> >>>>>>>>>>> Please stop thinking this way. Declarations for things defined
> in .c
> >>>>>>>>>>> files are to be present in headers, and the defining .c file has to
> >>>>>>>>>>> include that header (making sure declaration and definition are
> and
> >>>>>>>>>>> remain in sync). I hate having to again repeat my remark that
> you
> >>>>>>>>>>> shouldn't forget it's not application code that you're modifying.
> >>>>>>>>>>> Robust and maintainable code are a requirement in the
> hypervisor
> >>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
> >>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't
> also
> >>>>>>>>>>> apply to application code. It's just that in the hypervisor and
> kernel
> >>>>>>>>>>> (and certain other code system components) the consequences
> of
> >>>>>>>>>>> being lax are much more severe.
> >>>>>>>>>>
> >>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
> >>>>>>>>>> '<xen/memory.h>,
> >>>>>>>>>>
> >>>>>>>>>> #include "util.h"
> >>>>>>>>>> ...
> >>>>>>>>>> #include <xen/memory.h>
> >>>>>>>>>>
> >>>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
> >>>>>>>>>
> >>>>>>>>> Redefine? I said forward declare.
> >>>>>>>>
> >>>>>>>> Seems we just need to declare
> hvm_get_reserved_device_memory_map() in
> >>>>>>>> the head file, tools/firmware/hvmloader/util.h,
> >>>>>>>>
> >>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
> >>>>>>>
> >>>>>>> To me this looks very much like poor programming style, even if in
> >>>>>>> the context of hvmloader communicating information via global
> >>>>>>> variables rather than function arguments and return values is
> >>>>>>
> >>>>>> Do you mean you don't like a global variable? But it can be use to get
> >>>>>> RDM without more hypercall or function call in the context of
> hvmloader.
> >>>>>
> >>>>> This argument which you brought up before, and which we commented
> >>>>> on before, is pretty pointless. We don't really care much about doing
> >>>>> one or two more hypercalls from hvmloader, unless these would be
> >>>>> long-running ones.
> >>>>>
> >>>>
> >>>> Another benefit to use a global variable is that we wouldn't allocate
> >>>> xen_reserved_device_memory * N each time, and reduce some
> duplicated
> >>>> codes, unless you mean I should define that as static inside in local.
> >>>
> >>> Now this reason is indeed worth a consideration. How many times is
> >>> the data being needed/retrieved?
> >>
> >> Currently there are two cases in tools/hvmloader, setup pci and build
> >> e820 table. Each time, as you know we don't know how may entries we
> >> should require, so we always allocate one instance then according to the
> >> return value to allocate the proper instances to get that.
> >
> > Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
> > a more "normal" interface.
> >
> 
> Just go back here since I realize we always use mem_alloc(), which is
> pick from RESERVED_MEMORY, to allocate all buffer inside this hypercall
> caller in hvmloader, but unfortunately we have no any associated free
> function implementation in hvmloader, so if we call this multiple times
> this means it really waster more memory in RESERVED_MEMORY. So I still
> think one global variable should be fine.
> 

it's natural to get reserved information once, and then saved for either
one-time or multiple-time references.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 07:51:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 07:51:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrj0C-0006D7-T9; Fri, 21 Nov 2014 07:51:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrj0A-0006D2-Ud
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 07:51:35 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	00/04-02576-60FEE645; Fri, 21 Nov 2014 07:51:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416556293!13349300!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7281 invoked from network); 21 Nov 2014 07:51:33 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 07:51:33 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 08:51:32 +0100
Message-Id: <546EFD1502000078000499E3@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 08:51:33 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
In-Reply-To: <20141120195133.GE25423@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
>      ASSERT(d->arch.hvm_domain.irq.dpci);
>  
>      spin_lock(&d->event_lock);
> -    if ( pirq_dpci->state )
> +    if ( test_and_clear_bool(pirq_dpci->masked) )
>      {
>          struct pirq *pirq = dpci_pirq(pirq_dpci);
>          const struct dev_intx_gsi_link *digl;

So this now guards solely against the timeout enforced EOI? Why do
you no longer need to guard against cancellation (i.e. why isn't this
looking at both ->state and ->masked)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 07:51:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 07:51:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrj0C-0006D7-T9; Fri, 21 Nov 2014 07:51:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrj0A-0006D2-Ud
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 07:51:35 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	00/04-02576-60FEE645; Fri, 21 Nov 2014 07:51:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416556293!13349300!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7281 invoked from network); 21 Nov 2014 07:51:33 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 07:51:33 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 08:51:32 +0100
Message-Id: <546EFD1502000078000499E3@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 08:51:33 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
In-Reply-To: <20141120195133.GE25423@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
>      ASSERT(d->arch.hvm_domain.irq.dpci);
>  
>      spin_lock(&d->event_lock);
> -    if ( pirq_dpci->state )
> +    if ( test_and_clear_bool(pirq_dpci->masked) )
>      {
>          struct pirq *pirq = dpci_pirq(pirq_dpci);
>          const struct dev_intx_gsi_link *digl;

So this now guards solely against the timeout enforced EOI? Why do
you no longer need to guard against cancellation (i.e. why isn't this
looking at both ->state and ->masked)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 07:54:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 07:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrj2v-0006Nn-Eg; Fri, 21 Nov 2014 07:54:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrj2u-0006Ng-3R
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 07:54:24 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F2/A2-07724-FAFEE645; Fri, 21 Nov 2014 07:54:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416556456!12835126!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10729 invoked from network); 21 Nov 2014 07:54:16 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 07:54:16 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 08:54:16 +0100
Message-Id: <546EFDB902000078000499E6@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 08:54:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>, "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
	<546EDB0D.8030605@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 08:43, <kevin.tian@intel.com> wrote:
>>  From: Chen, Tiejun
>> Sent: Friday, November 21, 2014 2:26 PM
>> 
>> On 2014/11/3 18:02, Jan Beulich wrote:
>> >>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
>> >> On 2014/11/3 17:45, Jan Beulich wrote:
>> >>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
>> >>>> On 2014/11/3 16:53, Jan Beulich wrote:
>> >>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>> >>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
>> >>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>> >>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>> >>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>> >>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>> >>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>> >>>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern'
>> to them
>> >>>>>>>>>>>> when we really need them.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Please stop thinking this way. Declarations for things defined
>> in .c
>> >>>>>>>>>>> files are to be present in headers, and the defining .c file has to
>> >>>>>>>>>>> include that header (making sure declaration and definition are
>> and
>> >>>>>>>>>>> remain in sync). I hate having to again repeat my remark that
>> you
>> >>>>>>>>>>> shouldn't forget it's not application code that you're modifying.
>> >>>>>>>>>>> Robust and maintainable code are a requirement in the
>> hypervisor
>> >>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>> >>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't
>> also
>> >>>>>>>>>>> apply to application code. It's just that in the hypervisor and
>> kernel
>> >>>>>>>>>>> (and certain other code system components) the consequences
>> of
>> >>>>>>>>>>> being lax are much more severe.
>> >>>>>>>>>>
>> >>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>> >>>>>>>>>> '<xen/memory.h>,
>> >>>>>>>>>>
>> >>>>>>>>>> #include "util.h"
>> >>>>>>>>>> ...
>> >>>>>>>>>> #include <xen/memory.h>
>> >>>>>>>>>>
>> >>>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>> >>>>>>>>>
>> >>>>>>>>> Redefine? I said forward declare.
>> >>>>>>>>
>> >>>>>>>> Seems we just need to declare
>> hvm_get_reserved_device_memory_map() in
>> >>>>>>>> the head file, tools/firmware/hvmloader/util.h,
>> >>>>>>>>
>> >>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>> >>>>>>>
>> >>>>>>> To me this looks very much like poor programming style, even if in
>> >>>>>>> the context of hvmloader communicating information via global
>> >>>>>>> variables rather than function arguments and return values is
>> >>>>>>
>> >>>>>> Do you mean you don't like a global variable? But it can be use to get
>> >>>>>> RDM without more hypercall or function call in the context of
>> hvmloader.
>> >>>>>
>> >>>>> This argument which you brought up before, and which we commented
>> >>>>> on before, is pretty pointless. We don't really care much about doing
>> >>>>> one or two more hypercalls from hvmloader, unless these would be
>> >>>>> long-running ones.
>> >>>>>
>> >>>>
>> >>>> Another benefit to use a global variable is that we wouldn't allocate
>> >>>> xen_reserved_device_memory * N each time, and reduce some
>> duplicated
>> >>>> codes, unless you mean I should define that as static inside in local.
>> >>>
>> >>> Now this reason is indeed worth a consideration. How many times is
>> >>> the data being needed/retrieved?
>> >>
>> >> Currently there are two cases in tools/hvmloader, setup pci and build
>> >> e820 table. Each time, as you know we don't know how may entries we
>> >> should require, so we always allocate one instance then according to the
>> >> return value to allocate the proper instances to get that.
>> >
>> > Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
>> > a more "normal" interface.
>> >
>> 
>> Just go back here since I realize we always use mem_alloc(), which is
>> pick from RESERVED_MEMORY, to allocate all buffer inside this hypercall
>> caller in hvmloader, but unfortunately we have no any associated free
>> function implementation in hvmloader, so if we call this multiple times
>> this means it really waster more memory in RESERVED_MEMORY. So I still
>> think one global variable should be fine.
> 
> it's natural to get reserved information once, and then saved for either
> one-time or multiple-time references.

Not really natural, but possible. Yet if done this way, then the
interface shouldn't give the appearance of retrieving it every time,
i.e. the global should be set up separately and the users of the
data should access the data rather than calling a (fake) function.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 07:54:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 07:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrj2v-0006Nn-Eg; Fri, 21 Nov 2014 07:54:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrj2u-0006Ng-3R
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 07:54:24 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F2/A2-07724-FAFEE645; Fri, 21 Nov 2014 07:54:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416556456!12835126!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10729 invoked from network); 21 Nov 2014 07:54:16 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 07:54:16 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 08:54:16 +0100
Message-Id: <546EFDB902000078000499E6@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 08:54:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>, "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
	<546EDB0D.8030605@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 08:43, <kevin.tian@intel.com> wrote:
>>  From: Chen, Tiejun
>> Sent: Friday, November 21, 2014 2:26 PM
>> 
>> On 2014/11/3 18:02, Jan Beulich wrote:
>> >>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
>> >> On 2014/11/3 17:45, Jan Beulich wrote:
>> >>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
>> >>>> On 2014/11/3 16:53, Jan Beulich wrote:
>> >>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>> >>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
>> >>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>> >>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>> >>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>> >>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>> >>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>> >>>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern'
>> to them
>> >>>>>>>>>>>> when we really need them.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Please stop thinking this way. Declarations for things defined
>> in .c
>> >>>>>>>>>>> files are to be present in headers, and the defining .c file has to
>> >>>>>>>>>>> include that header (making sure declaration and definition are
>> and
>> >>>>>>>>>>> remain in sync). I hate having to again repeat my remark that
>> you
>> >>>>>>>>>>> shouldn't forget it's not application code that you're modifying.
>> >>>>>>>>>>> Robust and maintainable code are a requirement in the
>> hypervisor
>> >>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>> >>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't
>> also
>> >>>>>>>>>>> apply to application code. It's just that in the hypervisor and
>> kernel
>> >>>>>>>>>>> (and certain other code system components) the consequences
>> of
>> >>>>>>>>>>> being lax are much more severe.
>> >>>>>>>>>>
>> >>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>> >>>>>>>>>> '<xen/memory.h>,
>> >>>>>>>>>>
>> >>>>>>>>>> #include "util.h"
>> >>>>>>>>>> ...
>> >>>>>>>>>> #include <xen/memory.h>
>> >>>>>>>>>>
>> >>>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>> >>>>>>>>>
>> >>>>>>>>> Redefine? I said forward declare.
>> >>>>>>>>
>> >>>>>>>> Seems we just need to declare
>> hvm_get_reserved_device_memory_map() in
>> >>>>>>>> the head file, tools/firmware/hvmloader/util.h,
>> >>>>>>>>
>> >>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>> >>>>>>>
>> >>>>>>> To me this looks very much like poor programming style, even if in
>> >>>>>>> the context of hvmloader communicating information via global
>> >>>>>>> variables rather than function arguments and return values is
>> >>>>>>
>> >>>>>> Do you mean you don't like a global variable? But it can be use to get
>> >>>>>> RDM without more hypercall or function call in the context of
>> hvmloader.
>> >>>>>
>> >>>>> This argument which you brought up before, and which we commented
>> >>>>> on before, is pretty pointless. We don't really care much about doing
>> >>>>> one or two more hypercalls from hvmloader, unless these would be
>> >>>>> long-running ones.
>> >>>>>
>> >>>>
>> >>>> Another benefit to use a global variable is that we wouldn't allocate
>> >>>> xen_reserved_device_memory * N each time, and reduce some
>> duplicated
>> >>>> codes, unless you mean I should define that as static inside in local.
>> >>>
>> >>> Now this reason is indeed worth a consideration. How many times is
>> >>> the data being needed/retrieved?
>> >>
>> >> Currently there are two cases in tools/hvmloader, setup pci and build
>> >> e820 table. Each time, as you know we don't know how may entries we
>> >> should require, so we always allocate one instance then according to the
>> >> return value to allocate the proper instances to get that.
>> >
>> > Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
>> > a more "normal" interface.
>> >
>> 
>> Just go back here since I realize we always use mem_alloc(), which is
>> pick from RESERVED_MEMORY, to allocate all buffer inside this hypercall
>> caller in hvmloader, but unfortunately we have no any associated free
>> function implementation in hvmloader, so if we call this multiple times
>> this means it really waster more memory in RESERVED_MEMORY. So I still
>> think one global variable should be fine.
> 
> it's natural to get reserved information once, and then saved for either
> one-time or multiple-time references.

Not really natural, but possible. Yet if done this way, then the
interface shouldn't give the appearance of retrieving it every time,
i.e. the global should be set up separately and the users of the
data should access the data rather than calling a (fake) function.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 08:02:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 08:02:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrjAO-00074w-Ji; Fri, 21 Nov 2014 08:02:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XrjAM-00074o-RD
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 08:02:07 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	A9/A5-27584-E71FE645; Fri, 21 Nov 2014 08:02:06 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416556921!12586557!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31629 invoked from network); 21 Nov 2014 08:02:04 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-206.messagelabs.com with SMTP;
	21 Nov 2014 08:02:04 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 21 Nov 2014 00:02:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,429,1413270000"; d="scan'208";a="641000902"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga002.jf.intel.com with ESMTP; 21 Nov 2014 00:01:57 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 21 Nov 2014 16:01:56 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id
	14.03.0195.001; Fri, 21 Nov 2014 16:01:49 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get
	reserved device memory maps
Thread-Index: AQHQBVQc6n7FIBL490yut4WGX7kogZxqssSA//99KoCAAIgYoA==
Date: Fri, 21 Nov 2014 08:01:48 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FCCE7@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
	<546EDB0D.8030605@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
	<546EFDB902000078000499E6@smtp.nue.novell.com>
In-Reply-To: <546EFDB902000078000499E6@smtp.nue.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: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, November 21, 2014 3:54 PM
> 
> >>> On 21.11.14 at 08:43, <kevin.tian@intel.com> wrote:
> >>  From: Chen, Tiejun
> >> Sent: Friday, November 21, 2014 2:26 PM
> >>
> >> On 2014/11/3 18:02, Jan Beulich wrote:
> >> >>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
> >> >> On 2014/11/3 17:45, Jan Beulich wrote:
> >> >>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
> >> >>>> On 2014/11/3 16:53, Jan Beulich wrote:
> >> >>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
> >> >>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
> >> >>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
> >> >>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
> >> >>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
> >> >>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
> >> >>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
> >> >>>>>>>>>>>> Looks I can remove those stuff from util.h and just add
> 'extern'
> >> to them
> >> >>>>>>>>>>>> when we really need them.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Please stop thinking this way. Declarations for things defined
> >> in .c
> >> >>>>>>>>>>> files are to be present in headers, and the defining .c file has
> to
> >> >>>>>>>>>>> include that header (making sure declaration and definition
> are
> >> and
> >> >>>>>>>>>>> remain in sync). I hate having to again repeat my remark
> that
> >> you
> >> >>>>>>>>>>> shouldn't forget it's not application code that you're
> modifying.
> >> >>>>>>>>>>> Robust and maintainable code are a requirement in the
> >> hypervisor
> >> >>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which -
> just
> >> >>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't
> >> also
> >> >>>>>>>>>>> apply to application code. It's just that in the hypervisor and
> >> kernel
> >> >>>>>>>>>>> (and certain other code system components) the
> consequences
> >> of
> >> >>>>>>>>>>> being lax are much more severe.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
> >> >>>>>>>>>> '<xen/memory.h>,
> >> >>>>>>>>>>
> >> >>>>>>>>>> #include "util.h"
> >> >>>>>>>>>> ...
> >> >>>>>>>>>> #include <xen/memory.h>
> >> >>>>>>>>>>
> >> >>>>>>>>>> We can't redefine struct xen_reserved_device_memory in
> util.h.
> >> >>>>>>>>>
> >> >>>>>>>>> Redefine? I said forward declare.
> >> >>>>>>>>
> >> >>>>>>>> Seems we just need to declare
> >> hvm_get_reserved_device_memory_map() in
> >> >>>>>>>> the head file, tools/firmware/hvmloader/util.h,
> >> >>>>>>>>
> >> >>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
> >> >>>>>>>
> >> >>>>>>> To me this looks very much like poor programming style, even if in
> >> >>>>>>> the context of hvmloader communicating information via global
> >> >>>>>>> variables rather than function arguments and return values is
> >> >>>>>>
> >> >>>>>> Do you mean you don't like a global variable? But it can be use to
> get
> >> >>>>>> RDM without more hypercall or function call in the context of
> >> hvmloader.
> >> >>>>>
> >> >>>>> This argument which you brought up before, and which we
> commented
> >> >>>>> on before, is pretty pointless. We don't really care much about doing
> >> >>>>> one or two more hypercalls from hvmloader, unless these would be
> >> >>>>> long-running ones.
> >> >>>>>
> >> >>>>
> >> >>>> Another benefit to use a global variable is that we wouldn't allocate
> >> >>>> xen_reserved_device_memory * N each time, and reduce some
> >> duplicated
> >> >>>> codes, unless you mean I should define that as static inside in local.
> >> >>>
> >> >>> Now this reason is indeed worth a consideration. How many times is
> >> >>> the data being needed/retrieved?
> >> >>
> >> >> Currently there are two cases in tools/hvmloader, setup pci and build
> >> >> e820 table. Each time, as you know we don't know how may entries we
> >> >> should require, so we always allocate one instance then according to the
> >> >> return value to allocate the proper instances to get that.
> >> >
> >> > Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
> >> > a more "normal" interface.
> >> >
> >>
> >> Just go back here since I realize we always use mem_alloc(), which is
> >> pick from RESERVED_MEMORY, to allocate all buffer inside this hypercall
> >> caller in hvmloader, but unfortunately we have no any associated free
> >> function implementation in hvmloader, so if we call this multiple times
> >> this means it really waster more memory in RESERVED_MEMORY. So I still
> >> think one global variable should be fine.
> >
> > it's natural to get reserved information once, and then saved for either
> > one-time or multiple-time references.
> 
> Not really natural, but possible. Yet if done this way, then the
> interface shouldn't give the appearance of retrieving it every time,
> i.e. the global should be set up separately and the users of the
> data should access the data rather than calling a (fake) function.
> 

that's what I meant.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 08:02:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 08:02:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrjAO-00074w-Ji; Fri, 21 Nov 2014 08:02:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XrjAM-00074o-RD
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 08:02:07 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	A9/A5-27584-E71FE645; Fri, 21 Nov 2014 08:02:06 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416556921!12586557!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31629 invoked from network); 21 Nov 2014 08:02:04 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-206.messagelabs.com with SMTP;
	21 Nov 2014 08:02:04 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 21 Nov 2014 00:02:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,429,1413270000"; d="scan'208";a="641000902"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga002.jf.intel.com with ESMTP; 21 Nov 2014 00:01:57 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 21 Nov 2014 16:01:56 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id
	14.03.0195.001; Fri, 21 Nov 2014 16:01:49 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get
	reserved device memory maps
Thread-Index: AQHQBVQc6n7FIBL490yut4WGX7kogZxqssSA//99KoCAAIgYoA==
Date: Fri, 21 Nov 2014 08:01:48 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1260FCCE7@SHSMSX101.ccr.corp.intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
	<546EDB0D.8030605@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
	<546EFDB902000078000499E6@smtp.nue.novell.com>
In-Reply-To: <546EFDB902000078000499E6@smtp.nue.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: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, November 21, 2014 3:54 PM
> 
> >>> On 21.11.14 at 08:43, <kevin.tian@intel.com> wrote:
> >>  From: Chen, Tiejun
> >> Sent: Friday, November 21, 2014 2:26 PM
> >>
> >> On 2014/11/3 18:02, Jan Beulich wrote:
> >> >>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
> >> >> On 2014/11/3 17:45, Jan Beulich wrote:
> >> >>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
> >> >>>> On 2014/11/3 16:53, Jan Beulich wrote:
> >> >>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
> >> >>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
> >> >>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
> >> >>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
> >> >>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
> >> >>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
> >> >>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
> >> >>>>>>>>>>>> Looks I can remove those stuff from util.h and just add
> 'extern'
> >> to them
> >> >>>>>>>>>>>> when we really need them.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Please stop thinking this way. Declarations for things defined
> >> in .c
> >> >>>>>>>>>>> files are to be present in headers, and the defining .c file has
> to
> >> >>>>>>>>>>> include that header (making sure declaration and definition
> are
> >> and
> >> >>>>>>>>>>> remain in sync). I hate having to again repeat my remark
> that
> >> you
> >> >>>>>>>>>>> shouldn't forget it's not application code that you're
> modifying.
> >> >>>>>>>>>>> Robust and maintainable code are a requirement in the
> >> hypervisor
> >> >>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which -
> just
> >> >>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't
> >> also
> >> >>>>>>>>>>> apply to application code. It's just that in the hypervisor and
> >> kernel
> >> >>>>>>>>>>> (and certain other code system components) the
> consequences
> >> of
> >> >>>>>>>>>>> being lax are much more severe.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
> >> >>>>>>>>>> '<xen/memory.h>,
> >> >>>>>>>>>>
> >> >>>>>>>>>> #include "util.h"
> >> >>>>>>>>>> ...
> >> >>>>>>>>>> #include <xen/memory.h>
> >> >>>>>>>>>>
> >> >>>>>>>>>> We can't redefine struct xen_reserved_device_memory in
> util.h.
> >> >>>>>>>>>
> >> >>>>>>>>> Redefine? I said forward declare.
> >> >>>>>>>>
> >> >>>>>>>> Seems we just need to declare
> >> hvm_get_reserved_device_memory_map() in
> >> >>>>>>>> the head file, tools/firmware/hvmloader/util.h,
> >> >>>>>>>>
> >> >>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
> >> >>>>>>>
> >> >>>>>>> To me this looks very much like poor programming style, even if in
> >> >>>>>>> the context of hvmloader communicating information via global
> >> >>>>>>> variables rather than function arguments and return values is
> >> >>>>>>
> >> >>>>>> Do you mean you don't like a global variable? But it can be use to
> get
> >> >>>>>> RDM without more hypercall or function call in the context of
> >> hvmloader.
> >> >>>>>
> >> >>>>> This argument which you brought up before, and which we
> commented
> >> >>>>> on before, is pretty pointless. We don't really care much about doing
> >> >>>>> one or two more hypercalls from hvmloader, unless these would be
> >> >>>>> long-running ones.
> >> >>>>>
> >> >>>>
> >> >>>> Another benefit to use a global variable is that we wouldn't allocate
> >> >>>> xen_reserved_device_memory * N each time, and reduce some
> >> duplicated
> >> >>>> codes, unless you mean I should define that as static inside in local.
> >> >>>
> >> >>> Now this reason is indeed worth a consideration. How many times is
> >> >>> the data being needed/retrieved?
> >> >>
> >> >> Currently there are two cases in tools/hvmloader, setup pci and build
> >> >> e820 table. Each time, as you know we don't know how may entries we
> >> >> should require, so we always allocate one instance then according to the
> >> >> return value to allocate the proper instances to get that.
> >> >
> >> > Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
> >> > a more "normal" interface.
> >> >
> >>
> >> Just go back here since I realize we always use mem_alloc(), which is
> >> pick from RESERVED_MEMORY, to allocate all buffer inside this hypercall
> >> caller in hvmloader, but unfortunately we have no any associated free
> >> function implementation in hvmloader, so if we call this multiple times
> >> this means it really waster more memory in RESERVED_MEMORY. So I still
> >> think one global variable should be fine.
> >
> > it's natural to get reserved information once, and then saved for either
> > one-time or multiple-time references.
> 
> Not really natural, but possible. Yet if done this way, then the
> interface shouldn't give the appearance of retrieving it every time,
> i.e. the global should be set up separately and the users of the
> data should access the data rather than calling a (fake) function.
> 

that's what I meant.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 08:42:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 08:42:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrjnD-0007YL-80; Fri, 21 Nov 2014 08:42:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrjnC-0007YE-2T
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 08:42:14 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	15/C4-25727-5EAFE645; Fri, 21 Nov 2014 08:42:13 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416559332!12752102!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16291 invoked from network); 21 Nov 2014 08:42:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 08:42:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 56CDAAD00
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 08:42:12 +0000 (UTC)
Message-ID: <546EFAE3.80404@suse.com>
Date: Fri, 21 Nov 2014 09:42:11 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Hypervisor error messages after xl block-detach with
	linux 3.18-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-Transfer-Encoding: 7bit
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,

while testing my "linear p2m list" patches I saw the following
problem (even without my patches in place):

In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
disk image of a guest by attaching it to dom0:

xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
mount /dev/xvda2 /mnt
...
umount /mnt
xl block-detach 0 xvda

Worked without any problem. After some seconds the following messages
were issued on the console:

(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61110 (pfn 1f3f21c)
(XEN) mm.c:2995:d0 Error while pinning mfn 61110
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61110 (pfn 1f3f21c)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61111 (pfn 1f3f21d)
(XEN) mm.c:2995:d0 Error while pinning mfn 61111
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61111 (pfn 1f3f21d)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61120 (pfn 1f3f22c)
(XEN) mm.c:2995:d0 Error while pinning mfn 61120
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61120 (pfn 1f3f22c)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61121 (pfn 1f3f22d)
(XEN) mm.c:2995:d0 Error while pinning mfn 61121
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61121 (pfn 1f3f22d)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61102 (pfn 1f3f20e)
(XEN) mm.c:2995:d0 Error while pinning mfn 61102
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61102 (pfn 1f3f20e)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61103 (pfn 1f3f20f)
(XEN) mm.c:2995:d0 Error while pinning mfn 61103
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61103 (pfn 1f3f20f)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms

Is this a known issue?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 08:42:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 08:42:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrjnD-0007YL-80; Fri, 21 Nov 2014 08:42:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrjnC-0007YE-2T
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 08:42:14 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	15/C4-25727-5EAFE645; Fri, 21 Nov 2014 08:42:13 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416559332!12752102!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16291 invoked from network); 21 Nov 2014 08:42:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 08:42:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 56CDAAD00
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 08:42:12 +0000 (UTC)
Message-ID: <546EFAE3.80404@suse.com>
Date: Fri, 21 Nov 2014 09:42:11 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Hypervisor error messages after xl block-detach with
	linux 3.18-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-Transfer-Encoding: 7bit
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,

while testing my "linear p2m list" patches I saw the following
problem (even without my patches in place):

In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
disk image of a guest by attaching it to dom0:

xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
mount /dev/xvda2 /mnt
...
umount /mnt
xl block-detach 0 xvda

Worked without any problem. After some seconds the following messages
were issued on the console:

(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61110 (pfn 1f3f21c)
(XEN) mm.c:2995:d0 Error while pinning mfn 61110
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61110 (pfn 1f3f21c)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61111 (pfn 1f3f21d)
(XEN) mm.c:2995:d0 Error while pinning mfn 61111
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61111 (pfn 1f3f21d)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61120 (pfn 1f3f22c)
(XEN) mm.c:2995:d0 Error while pinning mfn 61120
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61120 (pfn 1f3f22c)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61121 (pfn 1f3f22d)
(XEN) mm.c:2995:d0 Error while pinning mfn 61121
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61121 (pfn 1f3f22d)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61102 (pfn 1f3f20e)
(XEN) mm.c:2995:d0 Error while pinning mfn 61102
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61102 (pfn 1f3f20e)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61103 (pfn 1f3f20f)
(XEN) mm.c:2995:d0 Error while pinning mfn 61103
(XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 
1000000000000000) for mfn 61103 (pfn 1f3f20f)
(XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms

Is this a known issue?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 08:42:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 08:42:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrjnt-0007cB-Kq; Fri, 21 Nov 2014 08:42:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrjns-0007bz-CU
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 08:42:56 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	1E/99-19763-F0BFE645; Fri, 21 Nov 2014 08:42:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416559374!12603280!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32142 invoked from network); 21 Nov 2014 08:42:55 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 08:42:55 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 09:42:54 +0100
Message-Id: <546F091F0200007800049A1C@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 09:42:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
In-Reply-To: <546E4A17.5040902@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 21:07, <sflist@ihonk.com> wrote:
> Running with mwait-idle=0 solves (hides?) the problem. Next step is to 
> fiddle with the C states?

For that I'd first of all like to know how much use of C states the
system still makes with that option in place. For that I'd need the
output of "xenpm get-cpuidle-states" (actually for comparison
purposes seeing it once with and once without that option in
place would be best). Or alternatively 'c' debug key output.

>> Interesting - all CPUs are executing stuff from Dom1, which be itself 
>> is not indicating a problem, but may (considering the host hang) hint 
>> at guest vCPU-s not getting de-scheduled anymore on one or more of the 
>> CPUs. The 'a' debug key output would hopefully give us enough 
>> information to know whether that's the case. Ideally do 'd' and 'a' a 
>> couple of times each (alternating, and with a few seconds in between). 
> 
> Here ya go (as before, from 9a727a81). I had to pick and choose what 
> parts to pull from the log because it was getting spammed with kernel 
> complaints about the disk subsystem being locked up, so the hypervisor 
> debugging info was hard to read amidst the kernel errors. As ever, let 
> me know if you need more.

Pretty strange: While the first 'a' output suggests that several CPUs
are idle, the first 'd' output contradicts. While this isn't wrong by itself,
it may provide a hint I'm simply unable to interpret yet. In any event
I didn't find what I expected - timers the expiry of which was in the
past.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 08:42:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 08:42:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrjnt-0007cB-Kq; Fri, 21 Nov 2014 08:42:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrjns-0007bz-CU
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 08:42:56 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	1E/99-19763-F0BFE645; Fri, 21 Nov 2014 08:42:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416559374!12603280!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32142 invoked from network); 21 Nov 2014 08:42:55 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 08:42:55 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 09:42:54 +0100
Message-Id: <546F091F0200007800049A1C@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 09:42:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
In-Reply-To: <546E4A17.5040902@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 21:07, <sflist@ihonk.com> wrote:
> Running with mwait-idle=0 solves (hides?) the problem. Next step is to 
> fiddle with the C states?

For that I'd first of all like to know how much use of C states the
system still makes with that option in place. For that I'd need the
output of "xenpm get-cpuidle-states" (actually for comparison
purposes seeing it once with and once without that option in
place would be best). Or alternatively 'c' debug key output.

>> Interesting - all CPUs are executing stuff from Dom1, which be itself 
>> is not indicating a problem, but may (considering the host hang) hint 
>> at guest vCPU-s not getting de-scheduled anymore on one or more of the 
>> CPUs. The 'a' debug key output would hopefully give us enough 
>> information to know whether that's the case. Ideally do 'd' and 'a' a 
>> couple of times each (alternating, and with a few seconds in between). 
> 
> Here ya go (as before, from 9a727a81). I had to pick and choose what 
> parts to pull from the log because it was getting spammed with kernel 
> complaints about the disk subsystem being locked up, so the hypervisor 
> debugging info was hard to read amidst the kernel errors. As ever, let 
> me know if you need more.

Pretty strange: While the first 'a' output suggests that several CPUs
are idle, the first 'd' output contradicts. While this isn't wrong by itself,
it may provide a hint I'm simply unable to interpret yet. In any event
I didn't find what I expected - timers the expiry of which was in the
past.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 08:54:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 08:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrjyz-0007um-S7; Fri, 21 Nov 2014 08:54:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xrjyy-0007uh-18
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 08:54:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3E/9B-09936-FBDFE645; Fri, 21 Nov 2014 08:54:23 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416560061!12203861!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19366 invoked from network); 21 Nov 2014 08:54:22 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-21.messagelabs.com with SMTP;
	21 Nov 2014 08:54:22 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 21 Nov 2014 00:54:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="419717448"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.112])
	([10.238.130.112])
	by FMSMGA003.fm.intel.com with ESMTP; 21 Nov 2014 00:44:49 -0800
Message-ID: <546EFDBA.6020008@intel.com>
Date: Fri, 21 Nov 2014 16:54:18 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Kevin Tian <kevin.tian@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
	<546EDB0D.8030605@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
	<546EFDB902000078000499E6@smtp.nue.novell.com>
In-Reply-To: <546EFDB902000078000499E6@smtp.nue.novell.com>
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/21 15:54, Jan Beulich wrote:
>>>> On 21.11.14 at 08:43, <kevin.tian@intel.com> wrote:
>>>   From: Chen, Tiejun
>>> Sent: Friday, November 21, 2014 2:26 PM
>>>
>>> On 2014/11/3 18:02, Jan Beulich wrote:
>>>>>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/11/3 17:45, Jan Beulich wrote:
>>>>>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
>>>>>>> On 2014/11/3 16:53, Jan Beulich wrote:
>>>>>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>>>>>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>>>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern'
>>> to them
>>>>>>>>>>>>>>> when we really need them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please stop thinking this way. Declarations for things defined
>>> in .c
>>>>>>>>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>>>>>>>>> include that header (making sure declaration and definition are
>>> and
>>>>>>>>>>>>>> remain in sync). I hate having to again repeat my remark that
>>> you
>>>>>>>>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>>>>>>>>> Robust and maintainable code are a requirement in the
>>> hypervisor
>>>>>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't
>>> also
>>>>>>>>>>>>>> apply to application code. It's just that in the hypervisor and
>>> kernel
>>>>>>>>>>>>>> (and certain other code system components) the consequences
>>> of
>>>>>>>>>>>>>> being lax are much more severe.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>>>>>>>>> '<xen/memory.h>,
>>>>>>>>>>>>>
>>>>>>>>>>>>> #include "util.h"
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> #include <xen/memory.h>
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>>>>>>>>
>>>>>>>>>>>> Redefine? I said forward declare.
>>>>>>>>>>>
>>>>>>>>>>> Seems we just need to declare
>>> hvm_get_reserved_device_memory_map() in
>>>>>>>>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>>>>>>>>
>>>>>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>>>>>>>>
>>>>>>>>>> To me this looks very much like poor programming style, even if in
>>>>>>>>>> the context of hvmloader communicating information via global
>>>>>>>>>> variables rather than function arguments and return values is
>>>>>>>>>
>>>>>>>>> Do you mean you don't like a global variable? But it can be use to get
>>>>>>>>> RDM without more hypercall or function call in the context of
>>> hvmloader.
>>>>>>>>
>>>>>>>> This argument which you brought up before, and which we commented
>>>>>>>> on before, is pretty pointless. We don't really care much about doing
>>>>>>>> one or two more hypercalls from hvmloader, unless these would be
>>>>>>>> long-running ones.
>>>>>>>>
>>>>>>>
>>>>>>> Another benefit to use a global variable is that we wouldn't allocate
>>>>>>> xen_reserved_device_memory * N each time, and reduce some
>>> duplicated
>>>>>>> codes, unless you mean I should define that as static inside in local.
>>>>>>
>>>>>> Now this reason is indeed worth a consideration. How many times is
>>>>>> the data being needed/retrieved?
>>>>>
>>>>> Currently there are two cases in tools/hvmloader, setup pci and build
>>>>> e820 table. Each time, as you know we don't know how may entries we
>>>>> should require, so we always allocate one instance then according to the
>>>>> return value to allocate the proper instances to get that.
>>>>
>>>> Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
>>>> a more "normal" interface.
>>>>
>>>
>>> Just go back here since I realize we always use mem_alloc(), which is
>>> pick from RESERVED_MEMORY, to allocate all buffer inside this hypercall
>>> caller in hvmloader, but unfortunately we have no any associated free
>>> function implementation in hvmloader, so if we call this multiple times
>>> this means it really waster more memory in RESERVED_MEMORY. So I still
>>> think one global variable should be fine.
>>
>> it's natural to get reserved information once, and then saved for either
>> one-time or multiple-time references.
>
> Not really natural, but possible. Yet if done this way, then the
> interface shouldn't give the appearance of retrieving it every time,
> i.e. the global should be set up separately and the users of the

Shouldn't we exactly implemented this previously?

+struct xen_mem_reserved_device_memory *rdm_map;

As a global variable, any caller should check if this is !NULL before 
they call that function.

Thanks
Tiejun

> data should access the data rather than calling a (fake) function.
>
> Jan
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 08:54:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 08:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrjyz-0007um-S7; Fri, 21 Nov 2014 08:54:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xrjyy-0007uh-18
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 08:54:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3E/9B-09936-FBDFE645; Fri, 21 Nov 2014 08:54:23 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416560061!12203861!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19366 invoked from network); 21 Nov 2014 08:54:22 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-21.messagelabs.com with SMTP;
	21 Nov 2014 08:54:22 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 21 Nov 2014 00:54:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="419717448"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.112])
	([10.238.130.112])
	by FMSMGA003.fm.intel.com with ESMTP; 21 Nov 2014 00:44:49 -0800
Message-ID: <546EFDBA.6020008@intel.com>
Date: Fri, 21 Nov 2014 16:54:18 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Kevin Tian <kevin.tian@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
	<546EDB0D.8030605@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
	<546EFDB902000078000499E6@smtp.nue.novell.com>
In-Reply-To: <546EFDB902000078000499E6@smtp.nue.novell.com>
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/21 15:54, Jan Beulich wrote:
>>>> On 21.11.14 at 08:43, <kevin.tian@intel.com> wrote:
>>>   From: Chen, Tiejun
>>> Sent: Friday, November 21, 2014 2:26 PM
>>>
>>> On 2014/11/3 18:02, Jan Beulich wrote:
>>>>>>> On 03.11.14 at 10:55, <tiejun.chen@intel.com> wrote:
>>>>> On 2014/11/3 17:45, Jan Beulich wrote:
>>>>>>>>> On 03.11.14 at 10:32, <tiejun.chen@intel.com> wrote:
>>>>>>> On 2014/11/3 16:53, Jan Beulich wrote:
>>>>>>>>>>> On 03.11.14 at 03:22, <tiejun.chen@intel.com> wrote:
>>>>>>>>> On 2014/10/31 16:14, Jan Beulich wrote:
>>>>>>>>>>>>> On 31.10.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>>>>>>>>> On 2014/10/30 17:13, Jan Beulich wrote:
>>>>>>>>>>>>>>> On 30.10.14 at 06:55, <tiejun.chen@intel.com> wrote:
>>>>>>>>>>>>> On 2014/10/29 17:05, Jan Beulich wrote:
>>>>>>>>>>>>>>>>> On 29.10.14 at 07:54, <tiejun.chen@intel.com> wrote:
>>>>>>>>>>>>>>> Looks I can remove those stuff from util.h and just add 'extern'
>>> to them
>>>>>>>>>>>>>>> when we really need them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please stop thinking this way. Declarations for things defined
>>> in .c
>>>>>>>>>>>>>> files are to be present in headers, and the defining .c file has to
>>>>>>>>>>>>>> include that header (making sure declaration and definition are
>>> and
>>>>>>>>>>>>>> remain in sync). I hate having to again repeat my remark that
>>> you
>>>>>>>>>>>>>> shouldn't forget it's not application code that you're modifying.
>>>>>>>>>>>>>> Robust and maintainable code are a requirement in the
>>> hypervisor
>>>>>>>>>>>>>> (and, as said it being an extension of it, hvmloader). Which - just
>>>>>>>>>>>>>> to avoid any misunderstanding - isn't to say that this shouldn't
>>> also
>>>>>>>>>>>>>> apply to application code. It's just that in the hypervisor and
>>> kernel
>>>>>>>>>>>>>> (and certain other code system components) the consequences
>>> of
>>>>>>>>>>>>>> being lax are much more severe.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Okay. But currently, the pci.c file already include 'util.h' and
>>>>>>>>>>>>> '<xen/memory.h>,
>>>>>>>>>>>>>
>>>>>>>>>>>>> #include "util.h"
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> #include <xen/memory.h>
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can't redefine struct xen_reserved_device_memory in util.h.
>>>>>>>>>>>>
>>>>>>>>>>>> Redefine? I said forward declare.
>>>>>>>>>>>
>>>>>>>>>>> Seems we just need to declare
>>> hvm_get_reserved_device_memory_map() in
>>>>>>>>>>> the head file, tools/firmware/hvmloader/util.h,
>>>>>>>>>>>
>>>>>>>>>>> unsigned int hvm_get_reserved_device_memory_map(void);
>>>>>>>>>>
>>>>>>>>>> To me this looks very much like poor programming style, even if in
>>>>>>>>>> the context of hvmloader communicating information via global
>>>>>>>>>> variables rather than function arguments and return values is
>>>>>>>>>
>>>>>>>>> Do you mean you don't like a global variable? But it can be use to get
>>>>>>>>> RDM without more hypercall or function call in the context of
>>> hvmloader.
>>>>>>>>
>>>>>>>> This argument which you brought up before, and which we commented
>>>>>>>> on before, is pretty pointless. We don't really care much about doing
>>>>>>>> one or two more hypercalls from hvmloader, unless these would be
>>>>>>>> long-running ones.
>>>>>>>>
>>>>>>>
>>>>>>> Another benefit to use a global variable is that we wouldn't allocate
>>>>>>> xen_reserved_device_memory * N each time, and reduce some
>>> duplicated
>>>>>>> codes, unless you mean I should define that as static inside in local.
>>>>>>
>>>>>> Now this reason is indeed worth a consideration. How many times is
>>>>>> the data being needed/retrieved?
>>>>>
>>>>> Currently there are two cases in tools/hvmloader, setup pci and build
>>>>> e820 table. Each time, as you know we don't know how may entries we
>>>>> should require, so we always allocate one instance then according to the
>>>>> return value to allocate the proper instances to get that.
>>>>
>>>> Hmm, two uses isn't really that bad, i.e. I'd then still be in favor of
>>>> a more "normal" interface.
>>>>
>>>
>>> Just go back here since I realize we always use mem_alloc(), which is
>>> pick from RESERVED_MEMORY, to allocate all buffer inside this hypercall
>>> caller in hvmloader, but unfortunately we have no any associated free
>>> function implementation in hvmloader, so if we call this multiple times
>>> this means it really waster more memory in RESERVED_MEMORY. So I still
>>> think one global variable should be fine.
>>
>> it's natural to get reserved information once, and then saved for either
>> one-time or multiple-time references.
>
> Not really natural, but possible. Yet if done this way, then the
> interface shouldn't give the appearance of retrieving it every time,
> i.e. the global should be set up separately and the users of the

Shouldn't we exactly implemented this previously?

+struct xen_mem_reserved_device_memory *rdm_map;

As a global variable, any caller should check if this is !NULL before 
they call that function.

Thanks
Tiejun

> data should access the data rather than calling a (fake) function.
>
> Jan
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 09:29:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 09:29:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrkWK-0008LO-MF; Fri, 21 Nov 2014 09:28:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrkWJ-0008LJ-Ar
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 09:28:51 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	2C/A2-28296-2D50F645; Fri, 21 Nov 2014 09:28:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416562128!10450820!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29772 invoked from network); 21 Nov 2014 09:28:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 09:28:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193627733"
Message-ID: <1416562126.26869.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>, Jim Fehlig <jfehlig@suse.com>
Date: Fri, 21 Nov 2014 09:28:46 +0000
In-Reply-To: <CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416475824.14429.1.camel@citrix.com>
	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:53 -0700, Xing Lin wrote:

> I git clone nova-juno from github and searched for 'pygrub'. Here is what i get. 
> 
> 
> .//etc/nova/rootwrap.d/compute.filters:104:# nova/virt/xenapi/vm_utils.py: 'pygrub', '-qn', dev_path
> .//etc/nova/rootwrap.d/compute.filters:105:pygrub: CommandFilter, pygrub, root
> .//nova/tests/unit/virt/xenapi/test_xenapi.py:667:        self.assertEqual(self.vm['PV_bootloader'], 'pygrub')
> .//nova/virt/xenapi/vm_utils.py:298:            rec['PV_bootloader'] = 'pygrub'
> 
> 
> It seems that nova does not specify absolute path for pygrub. 
> 
> 
> I checked libvirt source code and found the following definition.
> 
> 
> .//src/libxl/libxl_conf.h:52:# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"

Thanks for investigating.

I think libvirt is wrong to specify an absolute path here, IMHO by
default it should just specify "pygrub" and let libxl figure out the
correct path. Jim, what do you think?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 09:29:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 09:29:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrkWK-0008LO-MF; Fri, 21 Nov 2014 09:28:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrkWJ-0008LJ-Ar
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 09:28:51 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	2C/A2-28296-2D50F645; Fri, 21 Nov 2014 09:28:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416562128!10450820!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29772 invoked from network); 21 Nov 2014 09:28:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 09:28:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193627733"
Message-ID: <1416562126.26869.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>, Jim Fehlig <jfehlig@suse.com>
Date: Fri, 21 Nov 2014 09:28:46 +0000
In-Reply-To: <CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416475824.14429.1.camel@citrix.com>
	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:53 -0700, Xing Lin wrote:

> I git clone nova-juno from github and searched for 'pygrub'. Here is what i get. 
> 
> 
> .//etc/nova/rootwrap.d/compute.filters:104:# nova/virt/xenapi/vm_utils.py: 'pygrub', '-qn', dev_path
> .//etc/nova/rootwrap.d/compute.filters:105:pygrub: CommandFilter, pygrub, root
> .//nova/tests/unit/virt/xenapi/test_xenapi.py:667:        self.assertEqual(self.vm['PV_bootloader'], 'pygrub')
> .//nova/virt/xenapi/vm_utils.py:298:            rec['PV_bootloader'] = 'pygrub'
> 
> 
> It seems that nova does not specify absolute path for pygrub. 
> 
> 
> I checked libvirt source code and found the following definition.
> 
> 
> .//src/libxl/libxl_conf.h:52:# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"

Thanks for investigating.

I think libvirt is wrong to specify an absolute path here, IMHO by
default it should just specify "pygrub" and let libxl figure out the
correct path. Jim, what do you think?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 09:31:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 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.xen.org>)
	id 1XrkZ5-0008R7-7d; Fri, 21 Nov 2014 09:31:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrkZ4-0008R2-Ld
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 09:31:42 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	B2/6F-26652-E760F645; Fri, 21 Nov 2014 09:31:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416562301!12638549!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18350 invoked from network); 21 Nov 2014 09:31:41 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 09:31:41 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 10:31:41 +0100
Message-Id: <546F148D0200007800049A59@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 10:31:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
In-Reply-To: <546E4A17.5040902@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 21:07, <sflist@ihonk.com> wrote:
> Running with mwait-idle=0 solves (hides?) the problem. Next step is to 
> fiddle with the C states?

So this also prompted me to go over the list of errata. Just to confirm
- your CPU is family 6 model 44? What stepping? And what nominal
frequency?

There are a couple potentially relevant errata (BC36, BC38, BC54,
BC77, BC110).

To exclude BC36, a boot log with "apic-verbosity=debug" and debug
key 'i' output would be necessary.

BC38 should not affect us since we don't enter C states from ISRs.

BC54 is probably irrelevant since we meanwhile know that your
system doesn't really hang hard.

For BC77 it would be worth trying to disable turbo mode instead of
disabling the mwait-idle driver ("xenpm disable-turbo-mode" right
after boot).

And BC110 would be relevant only if without the mwait-idle driver
there would be no use of C3. Plus anyway this would more likely end
up in a hard hang too.

And then, considering that my system with a family 6 model 44 CPU
has never shown anything similar (albeit that doesn't mean all that
much since our workloads are likely very different), you're not
over-clocking? And did you disable hyper-threading on purpose (if
so could you check whether enabling it makes a difference)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 09:31:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 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.xen.org>)
	id 1XrkZ5-0008R7-7d; Fri, 21 Nov 2014 09:31:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrkZ4-0008R2-Ld
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 09:31:42 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	B2/6F-26652-E760F645; Fri, 21 Nov 2014 09:31:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416562301!12638549!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18350 invoked from network); 21 Nov 2014 09:31:41 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 09:31:41 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 10:31:41 +0100
Message-Id: <546F148D0200007800049A59@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 10:31:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
In-Reply-To: <546E4A17.5040902@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 21:07, <sflist@ihonk.com> wrote:
> Running with mwait-idle=0 solves (hides?) the problem. Next step is to 
> fiddle with the C states?

So this also prompted me to go over the list of errata. Just to confirm
- your CPU is family 6 model 44? What stepping? And what nominal
frequency?

There are a couple potentially relevant errata (BC36, BC38, BC54,
BC77, BC110).

To exclude BC36, a boot log with "apic-verbosity=debug" and debug
key 'i' output would be necessary.

BC38 should not affect us since we don't enter C states from ISRs.

BC54 is probably irrelevant since we meanwhile know that your
system doesn't really hang hard.

For BC77 it would be worth trying to disable turbo mode instead of
disabling the mwait-idle driver ("xenpm disable-turbo-mode" right
after boot).

And BC110 would be relevant only if without the mwait-idle driver
there would be no use of C3. Plus anyway this would more likely end
up in a hard hang too.

And then, considering that my system with a family 6 model 44 CPU
has never shown anything similar (albeit that doesn't mean all that
much since our workloads are likely very different), you're not
over-clocking? And did you disable hyper-threading on purpose (if
so could you check whether enabling it makes a difference)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 09:33:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 09: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 1XrkbF-0000Ae-O8; Fri, 21 Nov 2014 09:33:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrkbE-0000AW-82
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 09:33:56 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	F4/26-03148-3070F645; Fri, 21 Nov 2014 09:33:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416562434!13913816!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7765 invoked from network); 21 Nov 2014 09:33:55 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 09:33:55 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 10:33:54 +0100
Message-Id: <546F15120200007800049A65@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 10:33:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
	<546EDB0D.8030605@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
	<546EFDB902000078000499E6@smtp.nue.novell.com>
	<546EFDBA.6020008@intel.com>
In-Reply-To: <546EFDBA.6020008@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 09:54, <tiejun.chen@intel.com> wrote:
> On 2014/11/21 15:54, Jan Beulich wrote:
>>>>> On 21.11.14 at 08:43, <kevin.tian@intel.com> wrote:
>>> it's natural to get reserved information once, and then saved for either
>>> one-time or multiple-time references.
>>
>> Not really natural, but possible. Yet if done this way, then the
>> interface shouldn't give the appearance of retrieving it every time,
>> i.e. the global should be set up separately and the users of the
> 
> Shouldn't we exactly implemented this previously?

Not afair (the mention of how it should not be done above was
specifically targeting what I recall you did so far).

> As a global variable, any caller should check if this is !NULL before 
> they call that function.

Of course.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 09:33:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 09: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 1XrkbF-0000Ae-O8; Fri, 21 Nov 2014 09:33:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrkbE-0000AW-82
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 09:33:56 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	F4/26-03148-3070F645; Fri, 21 Nov 2014 09:33:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416562434!13913816!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7765 invoked from network); 21 Nov 2014 09:33:55 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 09:33:55 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 10:33:54 +0100
Message-Id: <546F15120200007800049A65@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 10:33:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
	<544F27BD.7060003@intel.com>
	<544F749A0200007800042B74@mail.emea.novell.com>
	<54508F1B.2030903@intel.com>
	<5450BBF50200007800043032@mail.emea.novell.com>
	<5451D2B5.50609@intel.com>
	<54520F2C0200007800043625@mail.emea.novell.com>
	<5452F207.1070105@intel.com>
	<545352F40200007800043D82@mail.emea.novell.com>
	<5456E6E9.1080104@intel.com>
	<545750AA02000078000443AD@mail.emea.novell.com>
	<54574BC0.7000709@intel.com>
	<54575CD60200007800044426@mail.emea.novell.com>
	<545750FA.9090001@intel.com>
	<545760B60200007800044471@mail.emea.novell.com>
	<546EDB0D.8030605@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260FCC59@SHSMSX101.ccr.corp.intel.com>
	<546EFDB902000078000499E6@smtp.nue.novell.com>
	<546EFDBA.6020008@intel.com>
In-Reply-To: <546EFDBA.6020008@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 09:54, <tiejun.chen@intel.com> wrote:
> On 2014/11/21 15:54, Jan Beulich wrote:
>>>>> On 21.11.14 at 08:43, <kevin.tian@intel.com> wrote:
>>> it's natural to get reserved information once, and then saved for either
>>> one-time or multiple-time references.
>>
>> Not really natural, but possible. Yet if done this way, then the
>> interface shouldn't give the appearance of retrieving it every time,
>> i.e. the global should be set up separately and the users of the
> 
> Shouldn't we exactly implemented this previously?

Not afair (the mention of how it should not be done above was
specifically targeting what I recall you did so far).

> As a global variable, any caller should check if this is !NULL before 
> they call that function.

Of course.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 09:43:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 09:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrkkI-0000Q6-Qd; Fri, 21 Nov 2014 09:43:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrkkH-0000P6-GJ
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 09:43:17 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	AF/BC-02707-4390F645; Fri, 21 Nov 2014 09:43:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416562994!12609911!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19287 invoked from network); 21 Nov 2014 09:43:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 09:43:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193631997"
Message-ID: <1416562990.26869.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 21 Nov 2014 09:43:10 +0000
In-Reply-To: <546E32BB.8090909@citrix.com>
References: <546E32BB.8090909@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 18:28 +0000, Andrew Cooper wrote:
> Realistically, this means no updates to the
> p2m at all, due to several potential race conditions.

>From the rest of the mail it seems as if you are talking primarily about
changes to the p2m *structure*, i.e. which guest frames contain the p2m
pages, rather than changes to the p2m entries themselves. Is that
correct?

I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
here, where does that fit in?

> As far as these issues are concerned, there are two distinct p2m
> modifications which we care about:
> 1) p2m structure changes (rearranging the layout of the p2m)
> 2) p2m content changes (altering entries in the p2m)
> 
> There is no possible way for the toolstack to prevent a domain from
> altering its p2m.  At the moment, ballooning typically only occurs when
> requested by the toolstack, but the underlying operations
> (increase/decrease_reservation, mem_exchange, etc) can be used by the
> guest at any point.  This includes Wei's guest memory fragmentation
> changes.  Changes to the content of the p2m also occur for grant map and
> unmap operations.
> 
> 
> Currently in PV guests, the p2m is implemented using a 3-level tree,
> with its root in the guests shared_info page.  It provides a hard VM
> memory limit of 4TB for 32bit PV guests (which is far higher than the
> 128GB limit from the compat p2m mappings), or 512GB for 64bit PV guests.
> 
> Juergen has a proposed new p2m interface using a virtual linear
> mapping.  This is conceptually similar to the previous implementation
> (which is fine from the toolstacks point of view), but far less
> complicated from the guests point of view, and removes the memory limits
> imposed by the p2m structure.
> 
> The new virtual linear mapping suffers from the same interaction issues
> as the old 3-level tree did, but the introduction of the new interface
> affords us an opportunity to make all API modifications at once to
> reduce churn.
> 
> 
> During live migration, the toolstack maps the guests p2m into a linear
> mapping in the toolstacks virtual address space.  This is done once at
> the start of migration, and never subsequently altered.  During live
> migration, the p2m is cross-verified with the m2p, and frames are sent
> using pfns as a reference, as they will be located in different frames
> on the receiving side.
> 
> Should the guest change the p2m structure during live migration, the
> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> resulting in bogus cross-referencing.  Should the guest change an entry
> in the p2m, the p2m frame itself will be resent as it would be marked as
> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> probably stale on the receiving side.
> 
> 
> Another factor which needs to be taken into account is Remus/COLO, which
> run the domains under live migration conditions for the duration of
> their lifetime.
> 
> During the live part of migration, the toolstack already has to be able
> to tolerate failures to normalise the pagetables, which result as a
> consequent of the pagetables being in active.  These failures are fatal
> on the final iteration after the guest has been paused, but the same
> logic could be extended to p2m/m2p issues, if needed.
> 
> 
> There are several potential solutions to these problems.
> 
> 1) Freeze the guests p2m during live migrate
> 
> This is the simplest sounding option, but is quite problematic from the
> point of view of the guest.  It is essentially a shared spinlock between
> the toolstack and the guest kernel.  It would prevent any grant
> map/unmap operations from occurring, and might interact badly with
> certain p2m updated in the guest which would previously be expected to
> unconditionally succeed.
> 
> Pros) (Can't think of any)
> Cons) Not easy to implement (even conceptually), requires invasive guest
> changes, will cripple Remus/COLO
> 
> 
> 2) Deep p2m dirty tracking
> 
> In the case that a p2m frame is discovered dirty in the logdirty bitmap,
> we can be certain that a write has occurred to it, and in the common
> case, means that the mapping has changed.  The toolstack could maintain
> a non-live copy of the p2m which is updated as new frames are sent. 
> When a dirty p2m frame is found, the live and non-live copies can be
> consulted to find which pfn mappings have changed, and locally mark all
> the altered pfns for retransmit.
> 
> Pros) No guest changes required
> Cons) Toolstack needs to keep an additional copy of the guests p2m on
> the sending side
> 
> 3) Eagerly check for p2m structure changes.
> 
> p2m structure changes are rare after boot, but not impossible.  Each
> iteration of live migration, the toolstack can check for dirty
> higher-level p2m frames in the dirty bitmap.  In the case that a
> structure update occurs, the toolstack can use information it already
> has to calculate a subset of pfns affected by the update, and mark them
> for resending.  (This can currently be done to the frame granularity
> given the p2m frame lit, but in combination with 2), could result in
> fewer pfns needing resending.)
> 
> Pros) No guest changes required.
> Cons) Moderately high toolstack overhead,  Possibility to resend far
> more pfns than strictly required.
> 
> 4) Request p2m structure change updates from the guest
> 
> The guest could provide a "p2m generation count" to allow the toolstack
> to evaluate whether the structure had changed.  This would allow the
> live part of migration to periodically re-evaluate whether it should
> remap the p2m to avoid stale mappings.
> 
> Pros) Easy to implement alongside the virtual linear mapping support. 
> Easy for toolstack and guest
> Cons) Only works with new virtual linear guests.
> 
> 
> Proposed solution:  A combination of 2, 3 and 4.
> 
> For legacy 3-level p2m guests, the toolstack can detect p2m structure
> updates by tracking the p2m top and mid levels in the logdirty bitmap,
> and invalidating the modified subset of pfns.  It has to eagerly check
> the p2m frame list list mfn entry in the shared info to see whether the
> guest has swapped onto a completely new p2m.
> 
> For a virtual linear map, the intermediate levels are not available to
> track, but we can require that the guest increment p2m generation clock
> in the shared info.  When the structure changes, the toolstack can remap
> the p2m and calculate the altered subset of pfns, and mark for resend.
> 
> The toolstack must also track changes in the p2m itself, and compare to
> a local copy showing the mapping at the time at which the pfn was last
> sent.  This can be used to work out which p2m mappings have changed, and
> also be used to confirm whether the pfns on the receiving side are stale
> or not.
> 
> I believe this covered all cases and race conditions.  In the case that
> the p2m is updated before the m2p, the p2m frame will be marked dirty in
> the bitmap, and discoverable on the next iteration.  At that point, if
> the p2m and m2p are inconsistent, the pfn will be deferred until the
> final iteration.  If not, the frame is sent and everything is all ok. 
> In the case that the p2m is updated after the m2p, the p2m/m2p will be
> consistent when the dirty bitmap is acted on.
> 
> 
> Thoughts? (for anyone who has made it this far :)  I think I have
> covered everything.)
> 
> ~Andrew
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 09:43:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 09:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrkkI-0000Q6-Qd; Fri, 21 Nov 2014 09:43:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrkkH-0000P6-GJ
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 09:43:17 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	AF/BC-02707-4390F645; Fri, 21 Nov 2014 09:43:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416562994!12609911!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19287 invoked from network); 21 Nov 2014 09:43:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 09:43:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193631997"
Message-ID: <1416562990.26869.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 21 Nov 2014 09:43:10 +0000
In-Reply-To: <546E32BB.8090909@citrix.com>
References: <546E32BB.8090909@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 18:28 +0000, Andrew Cooper wrote:
> Realistically, this means no updates to the
> p2m at all, due to several potential race conditions.

>From the rest of the mail it seems as if you are talking primarily about
changes to the p2m *structure*, i.e. which guest frames contain the p2m
pages, rather than changes to the p2m entries themselves. Is that
correct?

I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
here, where does that fit in?

> As far as these issues are concerned, there are two distinct p2m
> modifications which we care about:
> 1) p2m structure changes (rearranging the layout of the p2m)
> 2) p2m content changes (altering entries in the p2m)
> 
> There is no possible way for the toolstack to prevent a domain from
> altering its p2m.  At the moment, ballooning typically only occurs when
> requested by the toolstack, but the underlying operations
> (increase/decrease_reservation, mem_exchange, etc) can be used by the
> guest at any point.  This includes Wei's guest memory fragmentation
> changes.  Changes to the content of the p2m also occur for grant map and
> unmap operations.
> 
> 
> Currently in PV guests, the p2m is implemented using a 3-level tree,
> with its root in the guests shared_info page.  It provides a hard VM
> memory limit of 4TB for 32bit PV guests (which is far higher than the
> 128GB limit from the compat p2m mappings), or 512GB for 64bit PV guests.
> 
> Juergen has a proposed new p2m interface using a virtual linear
> mapping.  This is conceptually similar to the previous implementation
> (which is fine from the toolstacks point of view), but far less
> complicated from the guests point of view, and removes the memory limits
> imposed by the p2m structure.
> 
> The new virtual linear mapping suffers from the same interaction issues
> as the old 3-level tree did, but the introduction of the new interface
> affords us an opportunity to make all API modifications at once to
> reduce churn.
> 
> 
> During live migration, the toolstack maps the guests p2m into a linear
> mapping in the toolstacks virtual address space.  This is done once at
> the start of migration, and never subsequently altered.  During live
> migration, the p2m is cross-verified with the m2p, and frames are sent
> using pfns as a reference, as they will be located in different frames
> on the receiving side.
> 
> Should the guest change the p2m structure during live migration, the
> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> resulting in bogus cross-referencing.  Should the guest change an entry
> in the p2m, the p2m frame itself will be resent as it would be marked as
> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> probably stale on the receiving side.
> 
> 
> Another factor which needs to be taken into account is Remus/COLO, which
> run the domains under live migration conditions for the duration of
> their lifetime.
> 
> During the live part of migration, the toolstack already has to be able
> to tolerate failures to normalise the pagetables, which result as a
> consequent of the pagetables being in active.  These failures are fatal
> on the final iteration after the guest has been paused, but the same
> logic could be extended to p2m/m2p issues, if needed.
> 
> 
> There are several potential solutions to these problems.
> 
> 1) Freeze the guests p2m during live migrate
> 
> This is the simplest sounding option, but is quite problematic from the
> point of view of the guest.  It is essentially a shared spinlock between
> the toolstack and the guest kernel.  It would prevent any grant
> map/unmap operations from occurring, and might interact badly with
> certain p2m updated in the guest which would previously be expected to
> unconditionally succeed.
> 
> Pros) (Can't think of any)
> Cons) Not easy to implement (even conceptually), requires invasive guest
> changes, will cripple Remus/COLO
> 
> 
> 2) Deep p2m dirty tracking
> 
> In the case that a p2m frame is discovered dirty in the logdirty bitmap,
> we can be certain that a write has occurred to it, and in the common
> case, means that the mapping has changed.  The toolstack could maintain
> a non-live copy of the p2m which is updated as new frames are sent. 
> When a dirty p2m frame is found, the live and non-live copies can be
> consulted to find which pfn mappings have changed, and locally mark all
> the altered pfns for retransmit.
> 
> Pros) No guest changes required
> Cons) Toolstack needs to keep an additional copy of the guests p2m on
> the sending side
> 
> 3) Eagerly check for p2m structure changes.
> 
> p2m structure changes are rare after boot, but not impossible.  Each
> iteration of live migration, the toolstack can check for dirty
> higher-level p2m frames in the dirty bitmap.  In the case that a
> structure update occurs, the toolstack can use information it already
> has to calculate a subset of pfns affected by the update, and mark them
> for resending.  (This can currently be done to the frame granularity
> given the p2m frame lit, but in combination with 2), could result in
> fewer pfns needing resending.)
> 
> Pros) No guest changes required.
> Cons) Moderately high toolstack overhead,  Possibility to resend far
> more pfns than strictly required.
> 
> 4) Request p2m structure change updates from the guest
> 
> The guest could provide a "p2m generation count" to allow the toolstack
> to evaluate whether the structure had changed.  This would allow the
> live part of migration to periodically re-evaluate whether it should
> remap the p2m to avoid stale mappings.
> 
> Pros) Easy to implement alongside the virtual linear mapping support. 
> Easy for toolstack and guest
> Cons) Only works with new virtual linear guests.
> 
> 
> Proposed solution:  A combination of 2, 3 and 4.
> 
> For legacy 3-level p2m guests, the toolstack can detect p2m structure
> updates by tracking the p2m top and mid levels in the logdirty bitmap,
> and invalidating the modified subset of pfns.  It has to eagerly check
> the p2m frame list list mfn entry in the shared info to see whether the
> guest has swapped onto a completely new p2m.
> 
> For a virtual linear map, the intermediate levels are not available to
> track, but we can require that the guest increment p2m generation clock
> in the shared info.  When the structure changes, the toolstack can remap
> the p2m and calculate the altered subset of pfns, and mark for resend.
> 
> The toolstack must also track changes in the p2m itself, and compare to
> a local copy showing the mapping at the time at which the pfn was last
> sent.  This can be used to work out which p2m mappings have changed, and
> also be used to confirm whether the pfns on the receiving side are stale
> or not.
> 
> I believe this covered all cases and race conditions.  In the case that
> the p2m is updated before the m2p, the p2m frame will be marked dirty in
> the bitmap, and discoverable on the next iteration.  At that point, if
> the p2m and m2p are inconsistent, the pfn will be deferred until the
> final iteration.  If not, the frame is sent and everything is all ok. 
> In the case that the p2m is updated after the m2p, the p2m/m2p will be
> consistent when the dirty bitmap is acted on.
> 
> 
> Thoughts? (for anyone who has made it this far :)  I think I have
> covered everything.)
> 
> ~Andrew
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 10:09:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrl8t-0000sG-4T; Fri, 21 Nov 2014 10:08:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xrl8r-0000sB-IR
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 10:08:41 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	A6/CC-14214-82F0F645; Fri, 21 Nov 2014 10:08:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416564518!9747747!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20784 invoked from network); 21 Nov 2014 10:08:39 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 10:08:39 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 14BABACFC
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 10:08:37 +0000 (UTC)
Message-ID: <546F0F25.4040707@suse.com>
Date: Fri, 21 Nov 2014 11:08:37 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] WARNings in guest during xl save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 tests of my "linear p2m list" patches I stumbled over some
WARNs issued during xl save and xl restore of a pv-domU with
unpatched linux 3.18-rc5:

during save I saw multiple entries like:
[  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968 
clear_local_APIC+0xa5/0x2b0()
[  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss 
oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev 
x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul 
aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr 
cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
[  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W 
3.18.0-rc5 #30
[  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000 
00000009 c158bdc2
[  176.900393]  000003c8 c103c925 c103c925 000003c8 00000002 00000000 
c15d25eb e8867e64
[  176.900393]  c1054bd9 00000009 00000000 c103c925 00000000 c103cb54 
00000002 00000000
[  176.900393] Call Trace:
[  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
[  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
[  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
[  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
[  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
[  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
[  176.900393]  [<c103cb54>] ? disable_local_APIC+0x24/0x90
[  176.900393]  [<c103ccde>] ? lapic_suspend+0x11e/0x170
[  176.900393]  [<c1360ff9>] ? syscore_suspend+0x79/0x220
[  176.900393]  [<c107e782>] ? set_next_entity+0x62/0x80
[  176.900393]  [<c13165cd>] ? xen_suspend+0x2d/0x110
[  176.900393]  [<c10045df>] ? xen_mc_flush+0x13f/0x170
[  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
[  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
[  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
[  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
[  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
[  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
[  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
[  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
[  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
[  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
[  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
[  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
[  176.900393] ---[ end trace b38596d5cfdcde8d ]---

and during restore:
[  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968 
lapic_resume+0xc6/0x270()
[  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss 
oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev 
x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul 
aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr 
cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
[  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W 
3.18.0-rc5 #30
[  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000 
00000009 c158bdc2
[  176.900393]  000003c8 c103c1e6 c103c1e6 000003c8 c1030020 00000002 
0000001b 00000000
[  176.900393]  c1054bd9 00000009 00000000 c103c1e6 00000000 c16432c0 
0108cdfe c15d25dc
[  176.900393] Call Trace:
[  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
[  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
[  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
[  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
[  176.900393]  [<c1030020>] ? mcheck_cpu_init+0x170/0x4f0
[  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
[  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
[  176.900393]  [<c1360e66>] ? syscore_resume+0x46/0x160
[  176.900393]  [<c1009012>] ? xen_timer_resume+0x42/0x60
[  176.900393]  [<c131661c>] ? xen_suspend+0x7c/0x110
[  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
[  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
[  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
[  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
[  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
[  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
[  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
[  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
[  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
[  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
[  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
[  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
[  176.900393] ---[ end trace b38596d5cfdcde93 ]---

While this seems not to be critical (the system is running after the
restore) I assume disabling/enabling a local APIC on a pv-domain isn't
something we want to happen...


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 10:09:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrl8t-0000sG-4T; Fri, 21 Nov 2014 10:08:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xrl8r-0000sB-IR
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 10:08:41 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	A6/CC-14214-82F0F645; Fri, 21 Nov 2014 10:08:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416564518!9747747!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20784 invoked from network); 21 Nov 2014 10:08:39 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 10:08:39 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 14BABACFC
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 10:08:37 +0000 (UTC)
Message-ID: <546F0F25.4040707@suse.com>
Date: Fri, 21 Nov 2014 11:08:37 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] WARNings in guest during xl save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 tests of my "linear p2m list" patches I stumbled over some
WARNs issued during xl save and xl restore of a pv-domU with
unpatched linux 3.18-rc5:

during save I saw multiple entries like:
[  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968 
clear_local_APIC+0xa5/0x2b0()
[  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss 
oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev 
x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul 
aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr 
cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
[  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W 
3.18.0-rc5 #30
[  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000 
00000009 c158bdc2
[  176.900393]  000003c8 c103c925 c103c925 000003c8 00000002 00000000 
c15d25eb e8867e64
[  176.900393]  c1054bd9 00000009 00000000 c103c925 00000000 c103cb54 
00000002 00000000
[  176.900393] Call Trace:
[  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
[  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
[  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
[  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
[  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
[  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
[  176.900393]  [<c103cb54>] ? disable_local_APIC+0x24/0x90
[  176.900393]  [<c103ccde>] ? lapic_suspend+0x11e/0x170
[  176.900393]  [<c1360ff9>] ? syscore_suspend+0x79/0x220
[  176.900393]  [<c107e782>] ? set_next_entity+0x62/0x80
[  176.900393]  [<c13165cd>] ? xen_suspend+0x2d/0x110
[  176.900393]  [<c10045df>] ? xen_mc_flush+0x13f/0x170
[  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
[  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
[  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
[  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
[  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
[  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
[  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
[  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
[  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
[  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
[  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
[  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
[  176.900393] ---[ end trace b38596d5cfdcde8d ]---

and during restore:
[  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968 
lapic_resume+0xc6/0x270()
[  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss 
oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev 
x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul 
aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr 
cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
[  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W 
3.18.0-rc5 #30
[  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000 
00000009 c158bdc2
[  176.900393]  000003c8 c103c1e6 c103c1e6 000003c8 c1030020 00000002 
0000001b 00000000
[  176.900393]  c1054bd9 00000009 00000000 c103c1e6 00000000 c16432c0 
0108cdfe c15d25dc
[  176.900393] Call Trace:
[  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
[  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
[  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
[  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
[  176.900393]  [<c1030020>] ? mcheck_cpu_init+0x170/0x4f0
[  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
[  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
[  176.900393]  [<c1360e66>] ? syscore_resume+0x46/0x160
[  176.900393]  [<c1009012>] ? xen_timer_resume+0x42/0x60
[  176.900393]  [<c131661c>] ? xen_suspend+0x7c/0x110
[  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
[  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
[  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
[  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
[  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
[  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
[  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
[  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
[  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
[  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
[  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
[  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
[  176.900393] ---[ end trace b38596d5cfdcde93 ]---

While this seems not to be critical (the system is running after the
restore) I assume disabling/enabling a local APIC on a pv-domain isn't
something we want to happen...


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 10:25:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrlOe-0001Ea-U4; Fri, 21 Nov 2014 10:25:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrlOe-0001EU-2R
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 10:25:00 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	6E/A4-09284-BF21F645; Fri, 21 Nov 2014 10:24:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416565496!12956976!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4612 invoked from network); 21 Nov 2014 10:24:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 10:24:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; 
	d="scan'208,217";a="195177909"
Message-ID: <546F12F2.3020809@citrix.com>
Date: Fri, 21 Nov 2014 10:24:50 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546E32BB.8090909@citrix.com>
	<1416562990.26869.10.camel@citrix.com>
In-Reply-To: <1416562990.26869.10.camel@citrix.com>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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: multipart/mixed; boundary="===============1748438345909801221=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1748438345909801221==
Content-Type: multipart/alternative;
	boundary="------------040309030801080206060405"

--------------040309030801080206060405
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 21/11/14 09:43, Ian Campbell wrote:
> On Thu, 2014-11-20 at 18:28 +0000, Andrew Cooper wrote:
>> Realistically, this means no updates to the
>> p2m at all, due to several potential race conditions.
> From the rest of the mail it seems as if you are talking primarily abou=
t
> changes to the p2m *structure*, i.e. which guest frames contain the p2m=

> pages, rather than changes to the p2m entries themselves. Is that
> correct?

I cover both, although the structure changes are the more obvious, and
more complicated to fix.

There are race conditions in both existing implementation between a
p2m/m2p update and the toolstack sampling the dirty bitmap where stale
frames don't get resent.

>
> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
> here, where does that fit in?
>

It is referenced several times, although not by its exact name.

~Andrew

--------------040309030801080206060405
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 21/11/14 09:43, Ian Campbell wrote:<br>
    </div>
    <blockquote cite="mid:1416562990.26869.10.camel@citrix.com"
      type="cite">
      <pre wrap="">On Thu, 2014-11-20 at 18:28 +0000, Andrew Cooper wrote:
</pre>
      <blockquote type="cite" style="color: #000000;">
        <pre wrap=""><span class="moz-txt-citetags"></span>Realistically, this means no updates to the
p2m at all, due to several potential race conditions.
</pre>
      </blockquote>
      <pre wrap="">From the rest of the mail it seems as if you are talking primarily about
changes to the p2m <b class="moz-txt-star"><span class="moz-txt-tag">*</span>structure<span class="moz-txt-tag">*</span></b>, i.e. which guest frames contain the p2m
pages, rather than changes to the p2m entries themselves. Is that
correct?</pre>
    </blockquote>
    <br>
    I cover both, although the structure changes are the more obvious,
    and more complicated to fix.<br>
    <br>
    There are race conditions in both existing implementation between a
    p2m/m2p update and the toolstack sampling the dirty bitmap where
    stale frames don't get resent.<br>
    <br>
    <blockquote cite="mid:1416562990.26869.10.camel@citrix.com"
      type="cite">
      <pre wrap="">

I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
here, where does that fit in?

</pre>
    </blockquote>
    <br>
    It is referenced several times, although not by its exact name.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------040309030801080206060405--


--===============1748438345909801221==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1748438345909801221==--


From xen-devel-bounces@lists.xen.org Fri Nov 21 10:25:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrlOe-0001Ea-U4; Fri, 21 Nov 2014 10:25:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrlOe-0001EU-2R
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 10:25:00 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	6E/A4-09284-BF21F645; Fri, 21 Nov 2014 10:24:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416565496!12956976!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4612 invoked from network); 21 Nov 2014 10:24:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 10:24:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; 
	d="scan'208,217";a="195177909"
Message-ID: <546F12F2.3020809@citrix.com>
Date: Fri, 21 Nov 2014 10:24:50 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546E32BB.8090909@citrix.com>
	<1416562990.26869.10.camel@citrix.com>
In-Reply-To: <1416562990.26869.10.camel@citrix.com>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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: multipart/mixed; boundary="===============1748438345909801221=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1748438345909801221==
Content-Type: multipart/alternative;
	boundary="------------040309030801080206060405"

--------------040309030801080206060405
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 21/11/14 09:43, Ian Campbell wrote:
> On Thu, 2014-11-20 at 18:28 +0000, Andrew Cooper wrote:
>> Realistically, this means no updates to the
>> p2m at all, due to several potential race conditions.
> From the rest of the mail it seems as if you are talking primarily abou=
t
> changes to the p2m *structure*, i.e. which guest frames contain the p2m=

> pages, rather than changes to the p2m entries themselves. Is that
> correct?

I cover both, although the structure changes are the more obvious, and
more complicated to fix.

There are race conditions in both existing implementation between a
p2m/m2p update and the toolstack sampling the dirty bitmap where stale
frames don't get resent.

>
> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
> here, where does that fit in?
>

It is referenced several times, although not by its exact name.

~Andrew

--------------040309030801080206060405
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 21/11/14 09:43, Ian Campbell wrote:<br>
    </div>
    <blockquote cite="mid:1416562990.26869.10.camel@citrix.com"
      type="cite">
      <pre wrap="">On Thu, 2014-11-20 at 18:28 +0000, Andrew Cooper wrote:
</pre>
      <blockquote type="cite" style="color: #000000;">
        <pre wrap=""><span class="moz-txt-citetags"></span>Realistically, this means no updates to the
p2m at all, due to several potential race conditions.
</pre>
      </blockquote>
      <pre wrap="">From the rest of the mail it seems as if you are talking primarily about
changes to the p2m <b class="moz-txt-star"><span class="moz-txt-tag">*</span>structure<span class="moz-txt-tag">*</span></b>, i.e. which guest frames contain the p2m
pages, rather than changes to the p2m entries themselves. Is that
correct?</pre>
    </blockquote>
    <br>
    I cover both, although the structure changes are the more obvious,
    and more complicated to fix.<br>
    <br>
    There are race conditions in both existing implementation between a
    p2m/m2p update and the toolstack sampling the dirty bitmap where
    stale frames don't get resent.<br>
    <br>
    <blockquote cite="mid:1416562990.26869.10.camel@citrix.com"
      type="cite">
      <pre wrap="">

I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
here, where does that fit in?

</pre>
    </blockquote>
    <br>
    It is referenced several times, although not by its exact name.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------040309030801080206060405--


--===============1748438345909801221==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1748438345909801221==--


From xen-devel-bounces@lists.xen.org Fri Nov 21 10:32:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrlW1-0001TZ-V3; Fri, 21 Nov 2014 10:32:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrlW0-0001TS-HN
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 10:32:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	22/3C-09842-3C41F645; Fri, 21 Nov 2014 10:32:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416565954!14349963!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31237 invoked from network); 21 Nov 2014 10:32:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 10:32:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195180017"
Message-ID: <546F14BF.5030705@citrix.com>
Date: Fri, 21 Nov 2014 10:32:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, Xen-devel List <xen-devel@lists.xen.org>
References: <546E32BB.8090909@citrix.com> <546ED07B.3030208@suse.com>
In-Reply-To: <546ED07B.3030208@suse.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 21/11/14 05:41, Juergen Gross wrote:
> On 11/20/2014 07:28 PM, Andrew Cooper wrote:
>> Hello,
>>
>> Tim, David and I were discussing this over lunch.  This email is a
>> (hopefully accurate) account of our findings, and potential solutions.
>> (If I have messed up, please shout.)
>>
>> Currently, correct live migration of PV domains relies on the toolstack
>> (which has a live mapping of the guests p2m) not observing stale values
>> when the guest updates its p2m, and the race condition between a p2m
>> update and an m2p update.  Realistically, this means no updates to the
>> p2m at all, due to several potential race conditions.  Should any race
>> conditions happen (e.g. ballooning while live migrating), the effects
>> could be anything from an aborted migration to VM memory corruption.
>>
>> It should be noted that migrationv2 does not fix any of this.  It alters
>> the way in which some race conditions might be observed.  During
>> development of migrationv2, there was an explicit non-requirement of
>> fixing the existing Ballooning+LiveMigration issues we were aware,
>> although at the time, we were not aware of this specific set of issues.
>> Our goal was to simply make migrationv2 work in the same circumstances
>> as previously, but with a bitness-agnostic wire format and
>> forward-extensible protocol.
>>
>>
>> As far as these issues are concerned, there are two distinct p2m
>> modifications which we care about:
>> 1) p2m structure changes (rearranging the layout of the p2m)
>> 2) p2m content changes (altering entries in the p2m)
>>
>> There is no possible way for the toolstack to prevent a domain from
>> altering its p2m.  At the moment, ballooning typically only occurs when
>> requested by the toolstack, but the underlying operations
>> (increase/decrease_reservation, mem_exchange, etc) can be used by the
>> guest at any point.  This includes Wei's guest memory fragmentation
>> changes.  Changes to the content of the p2m also occur for grant map and
>> unmap operations.
>>
>>
>> Currently in PV guests, the p2m is implemented using a 3-level tree,
>> with its root in the guests shared_info page.  It provides a hard VM
>> memory limit of 4TB for 32bit PV guests (which is far higher than the
>> 128GB limit from the compat p2m mappings), or 512GB for 64bit PV guests.
>>
>> Juergen has a proposed new p2m interface using a virtual linear
>> mapping.  This is conceptually similar to the previous implementation
>> (which is fine from the toolstacks point of view), but far less
>> complicated from the guests point of view, and removes the memory limits
>> imposed by the p2m structure.
>>
>> The new virtual linear mapping suffers from the same interaction issues
>> as the old 3-level tree did, but the introduction of the new interface
>> affords us an opportunity to make all API modifications at once to
>> reduce churn.
>>
>>
>> During live migration, the toolstack maps the guests p2m into a linear
>> mapping in the toolstacks virtual address space.  This is done once at
>> the start of migration, and never subsequently altered.  During live
>> migration, the p2m is cross-verified with the m2p, and frames are sent
>> using pfns as a reference, as they will be located in different frames
>> on the receiving side.
>>
>> Should the guest change the p2m structure during live migration, the
>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
>> resulting in bogus cross-referencing.  Should the guest change an entry
>> in the p2m, the p2m frame itself will be resent as it would be marked as
>> dirty in the logdirty bitmap, but the target pfn will remain unsent and
>> probably stale on the receiving side.
>>
>>
>> Another factor which needs to be taken into account is Remus/COLO, which
>> run the domains under live migration conditions for the duration of
>> their lifetime.
>>
>> During the live part of migration, the toolstack already has to be able
>> to tolerate failures to normalise the pagetables, which result as a
>> consequent of the pagetables being in active.  These failures are fatal
>> on the final iteration after the guest has been paused, but the same
>> logic could be extended to p2m/m2p issues, if needed.
>>
>>
>> There are several potential solutions to these problems.
>>
>> 1) Freeze the guests p2m during live migrate
>>
>> This is the simplest sounding option, but is quite problematic from the
>> point of view of the guest.  It is essentially a shared spinlock between
>> the toolstack and the guest kernel.  It would prevent any grant
>> map/unmap operations from occurring, and might interact badly with
>> certain p2m updated in the guest which would previously be expected to
>> unconditionally succeed.
>>
>> Pros) (Can't think of any)
>> Cons) Not easy to implement (even conceptually), requires invasive guest
>> changes, will cripple Remus/COLO
>>
>>
>> 2) Deep p2m dirty tracking
>>
>> In the case that a p2m frame is discovered dirty in the logdirty bitmap,
>> we can be certain that a write has occurred to it, and in the common
>> case, means that the mapping has changed.  The toolstack could maintain
>> a non-live copy of the p2m which is updated as new frames are sent.
>> When a dirty p2m frame is found, the live and non-live copies can be
>> consulted to find which pfn mappings have changed, and locally mark all
>> the altered pfns for retransmit.
>>
>> Pros) No guest changes required
>> Cons) Toolstack needs to keep an additional copy of the guests p2m on
>> the sending side
>>
>> 3) Eagerly check for p2m structure changes.
>>
>> p2m structure changes are rare after boot, but not impossible.  Each
>> iteration of live migration, the toolstack can check for dirty
>> higher-level p2m frames in the dirty bitmap.  In the case that a
>> structure update occurs, the toolstack can use information it already
>> has to calculate a subset of pfns affected by the update, and mark them
>> for resending.  (This can currently be done to the frame granularity
>> given the p2m frame lit, but in combination with 2), could result in
>> fewer pfns needing resending.)
>>
>> Pros) No guest changes required.
>> Cons) Moderately high toolstack overhead,  Possibility to resend far
>> more pfns than strictly required.
>>
>> 4) Request p2m structure change updates from the guest
>>
>> The guest could provide a "p2m generation count" to allow the toolstack
>> to evaluate whether the structure had changed.  This would allow the
>> live part of migration to periodically re-evaluate whether it should
>> remap the p2m to avoid stale mappings.
>>
>> Pros) Easy to implement alongside the virtual linear mapping support.
>> Easy for toolstack and guest
>> Cons) Only works with new virtual linear guests.
>>
>>
>> Proposed solution:  A combination of 2, 3 and 4.
>>
>> For legacy 3-level p2m guests, the toolstack can detect p2m structure
>> updates by tracking the p2m top and mid levels in the logdirty bitmap,
>> and invalidating the modified subset of pfns.  It has to eagerly check
>> the p2m frame list list mfn entry in the shared info to see whether the
>> guest has swapped onto a completely new p2m.
>>
>> For a virtual linear map, the intermediate levels are not available to
>> track, but we can require that the guest increment p2m generation clock
>> in the shared info.  When the structure changes, the toolstack can remap
>> the p2m and calculate the altered subset of pfns, and mark for resend.
>>
>> The toolstack must also track changes in the p2m itself, and compare to
>> a local copy showing the mapping at the time at which the pfn was last
>> sent.  This can be used to work out which p2m mappings have changed, and
>> also be used to confirm whether the pfns on the receiving side are stale
>> or not.
>>
>> I believe this covered all cases and race conditions.  In the case that
>> the p2m is updated before the m2p, the p2m frame will be marked dirty in
>> the bitmap, and discoverable on the next iteration.  At that point, if
>> the p2m and m2p are inconsistent, the pfn will be deferred until the
>> final iteration.  If not, the frame is sent and everything is all ok.
>> In the case that the p2m is updated after the m2p, the p2m/m2p will be
>> consistent when the dirty bitmap is acted on.
>>
>>
>> Thoughts? (for anyone who has made it this far :)  I think I have
>> covered everything.)
>
> Sounds okay.
>
> Two remarks regarding the virtual linear map:
> - The intermediate levels could be tracked, as they are memory pages as
>   well. It is not practical to do so, however, as there might be lots of
>   changes not related to the p2m.

The intermediate levels are just pagetables, are they not? Or is there a
separate tracking structure?

> - The generation count is being checked by the tools in a lazy manner.
>   This will require an increment of the count by the guest only after
>   changing the structure of the p2m map, I think.

On further consideration, I think this needs to be a lockless
producer/consumer interface, with increment once at start, and once
again at the end.  The toolstack needs some ability to confirm that it
has got a consistent mapping of the virtual p2m, as it cant practically
detect updates via the logdirty bitmap.

It also occurs to me that the toolstack code needs to gain some use of
ACCESS_ONCE() when reading the live p2m.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 10:32:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrlW1-0001TZ-V3; Fri, 21 Nov 2014 10:32:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrlW0-0001TS-HN
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 10:32:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	22/3C-09842-3C41F645; Fri, 21 Nov 2014 10:32:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416565954!14349963!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31237 invoked from network); 21 Nov 2014 10:32:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 10:32:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195180017"
Message-ID: <546F14BF.5030705@citrix.com>
Date: Fri, 21 Nov 2014 10:32:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, Xen-devel List <xen-devel@lists.xen.org>
References: <546E32BB.8090909@citrix.com> <546ED07B.3030208@suse.com>
In-Reply-To: <546ED07B.3030208@suse.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 21/11/14 05:41, Juergen Gross wrote:
> On 11/20/2014 07:28 PM, Andrew Cooper wrote:
>> Hello,
>>
>> Tim, David and I were discussing this over lunch.  This email is a
>> (hopefully accurate) account of our findings, and potential solutions.
>> (If I have messed up, please shout.)
>>
>> Currently, correct live migration of PV domains relies on the toolstack
>> (which has a live mapping of the guests p2m) not observing stale values
>> when the guest updates its p2m, and the race condition between a p2m
>> update and an m2p update.  Realistically, this means no updates to the
>> p2m at all, due to several potential race conditions.  Should any race
>> conditions happen (e.g. ballooning while live migrating), the effects
>> could be anything from an aborted migration to VM memory corruption.
>>
>> It should be noted that migrationv2 does not fix any of this.  It alters
>> the way in which some race conditions might be observed.  During
>> development of migrationv2, there was an explicit non-requirement of
>> fixing the existing Ballooning+LiveMigration issues we were aware,
>> although at the time, we were not aware of this specific set of issues.
>> Our goal was to simply make migrationv2 work in the same circumstances
>> as previously, but with a bitness-agnostic wire format and
>> forward-extensible protocol.
>>
>>
>> As far as these issues are concerned, there are two distinct p2m
>> modifications which we care about:
>> 1) p2m structure changes (rearranging the layout of the p2m)
>> 2) p2m content changes (altering entries in the p2m)
>>
>> There is no possible way for the toolstack to prevent a domain from
>> altering its p2m.  At the moment, ballooning typically only occurs when
>> requested by the toolstack, but the underlying operations
>> (increase/decrease_reservation, mem_exchange, etc) can be used by the
>> guest at any point.  This includes Wei's guest memory fragmentation
>> changes.  Changes to the content of the p2m also occur for grant map and
>> unmap operations.
>>
>>
>> Currently in PV guests, the p2m is implemented using a 3-level tree,
>> with its root in the guests shared_info page.  It provides a hard VM
>> memory limit of 4TB for 32bit PV guests (which is far higher than the
>> 128GB limit from the compat p2m mappings), or 512GB for 64bit PV guests.
>>
>> Juergen has a proposed new p2m interface using a virtual linear
>> mapping.  This is conceptually similar to the previous implementation
>> (which is fine from the toolstacks point of view), but far less
>> complicated from the guests point of view, and removes the memory limits
>> imposed by the p2m structure.
>>
>> The new virtual linear mapping suffers from the same interaction issues
>> as the old 3-level tree did, but the introduction of the new interface
>> affords us an opportunity to make all API modifications at once to
>> reduce churn.
>>
>>
>> During live migration, the toolstack maps the guests p2m into a linear
>> mapping in the toolstacks virtual address space.  This is done once at
>> the start of migration, and never subsequently altered.  During live
>> migration, the p2m is cross-verified with the m2p, and frames are sent
>> using pfns as a reference, as they will be located in different frames
>> on the receiving side.
>>
>> Should the guest change the p2m structure during live migration, the
>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
>> resulting in bogus cross-referencing.  Should the guest change an entry
>> in the p2m, the p2m frame itself will be resent as it would be marked as
>> dirty in the logdirty bitmap, but the target pfn will remain unsent and
>> probably stale on the receiving side.
>>
>>
>> Another factor which needs to be taken into account is Remus/COLO, which
>> run the domains under live migration conditions for the duration of
>> their lifetime.
>>
>> During the live part of migration, the toolstack already has to be able
>> to tolerate failures to normalise the pagetables, which result as a
>> consequent of the pagetables being in active.  These failures are fatal
>> on the final iteration after the guest has been paused, but the same
>> logic could be extended to p2m/m2p issues, if needed.
>>
>>
>> There are several potential solutions to these problems.
>>
>> 1) Freeze the guests p2m during live migrate
>>
>> This is the simplest sounding option, but is quite problematic from the
>> point of view of the guest.  It is essentially a shared spinlock between
>> the toolstack and the guest kernel.  It would prevent any grant
>> map/unmap operations from occurring, and might interact badly with
>> certain p2m updated in the guest which would previously be expected to
>> unconditionally succeed.
>>
>> Pros) (Can't think of any)
>> Cons) Not easy to implement (even conceptually), requires invasive guest
>> changes, will cripple Remus/COLO
>>
>>
>> 2) Deep p2m dirty tracking
>>
>> In the case that a p2m frame is discovered dirty in the logdirty bitmap,
>> we can be certain that a write has occurred to it, and in the common
>> case, means that the mapping has changed.  The toolstack could maintain
>> a non-live copy of the p2m which is updated as new frames are sent.
>> When a dirty p2m frame is found, the live and non-live copies can be
>> consulted to find which pfn mappings have changed, and locally mark all
>> the altered pfns for retransmit.
>>
>> Pros) No guest changes required
>> Cons) Toolstack needs to keep an additional copy of the guests p2m on
>> the sending side
>>
>> 3) Eagerly check for p2m structure changes.
>>
>> p2m structure changes are rare after boot, but not impossible.  Each
>> iteration of live migration, the toolstack can check for dirty
>> higher-level p2m frames in the dirty bitmap.  In the case that a
>> structure update occurs, the toolstack can use information it already
>> has to calculate a subset of pfns affected by the update, and mark them
>> for resending.  (This can currently be done to the frame granularity
>> given the p2m frame lit, but in combination with 2), could result in
>> fewer pfns needing resending.)
>>
>> Pros) No guest changes required.
>> Cons) Moderately high toolstack overhead,  Possibility to resend far
>> more pfns than strictly required.
>>
>> 4) Request p2m structure change updates from the guest
>>
>> The guest could provide a "p2m generation count" to allow the toolstack
>> to evaluate whether the structure had changed.  This would allow the
>> live part of migration to periodically re-evaluate whether it should
>> remap the p2m to avoid stale mappings.
>>
>> Pros) Easy to implement alongside the virtual linear mapping support.
>> Easy for toolstack and guest
>> Cons) Only works with new virtual linear guests.
>>
>>
>> Proposed solution:  A combination of 2, 3 and 4.
>>
>> For legacy 3-level p2m guests, the toolstack can detect p2m structure
>> updates by tracking the p2m top and mid levels in the logdirty bitmap,
>> and invalidating the modified subset of pfns.  It has to eagerly check
>> the p2m frame list list mfn entry in the shared info to see whether the
>> guest has swapped onto a completely new p2m.
>>
>> For a virtual linear map, the intermediate levels are not available to
>> track, but we can require that the guest increment p2m generation clock
>> in the shared info.  When the structure changes, the toolstack can remap
>> the p2m and calculate the altered subset of pfns, and mark for resend.
>>
>> The toolstack must also track changes in the p2m itself, and compare to
>> a local copy showing the mapping at the time at which the pfn was last
>> sent.  This can be used to work out which p2m mappings have changed, and
>> also be used to confirm whether the pfns on the receiving side are stale
>> or not.
>>
>> I believe this covered all cases and race conditions.  In the case that
>> the p2m is updated before the m2p, the p2m frame will be marked dirty in
>> the bitmap, and discoverable on the next iteration.  At that point, if
>> the p2m and m2p are inconsistent, the pfn will be deferred until the
>> final iteration.  If not, the frame is sent and everything is all ok.
>> In the case that the p2m is updated after the m2p, the p2m/m2p will be
>> consistent when the dirty bitmap is acted on.
>>
>>
>> Thoughts? (for anyone who has made it this far :)  I think I have
>> covered everything.)
>
> Sounds okay.
>
> Two remarks regarding the virtual linear map:
> - The intermediate levels could be tracked, as they are memory pages as
>   well. It is not practical to do so, however, as there might be lots of
>   changes not related to the p2m.

The intermediate levels are just pagetables, are they not? Or is there a
separate tracking structure?

> - The generation count is being checked by the tools in a lazy manner.
>   This will require an increment of the count by the guest only after
>   changing the structure of the p2m map, I think.

On further consideration, I think this needs to be a lockless
producer/consumer interface, with increment once at start, and once
again at the end.  The toolstack needs some ability to confirm that it
has got a consistent mapping of the virtual p2m, as it cant practically
detect updates via the logdirty bitmap.

It also occurs to me that the toolstack code needs to gain some use of
ACCESS_ONCE() when reading the live p2m.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 10:44:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrlgr-0001lA-DP; Fri, 21 Nov 2014 10:43:49 +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 1Xrlgp-0001l5-By
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 10:43:47 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	B4/A0-02712-2671F645; Fri, 21 Nov 2014 10:43:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416566625!13971266!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 486 invoked from network); 21 Nov 2014 10:43:46 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 10:43:46 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 11:43:45 +0100
Message-Id: <546F25700200007800049AB4@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 11:43:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <546E32BB.8090909@citrix.com>
In-Reply-To: <546E32BB.8090909@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
> Should the guest change the p2m structure during live migration, the
> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> resulting in bogus cross-referencing.  Should the guest change an entry
> in the p2m, the p2m frame itself will be resent as it would be marked as
> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> probably stale on the receiving side.

MMU_MACHPHYS_UPDATE processing marks the page being changed
as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
callers thereof) should do so too?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 10:44:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrlgr-0001lA-DP; Fri, 21 Nov 2014 10:43:49 +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 1Xrlgp-0001l5-By
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 10:43:47 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	B4/A0-02712-2671F645; Fri, 21 Nov 2014 10:43:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416566625!13971266!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 486 invoked from network); 21 Nov 2014 10:43:46 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 10:43:46 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 11:43:45 +0100
Message-Id: <546F25700200007800049AB4@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 11:43:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <546E32BB.8090909@citrix.com>
In-Reply-To: <546E32BB.8090909@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
> Should the guest change the p2m structure during live migration, the
> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> resulting in bogus cross-referencing.  Should the guest change an entry
> in the p2m, the p2m frame itself will be resent as it would be marked as
> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> probably stale on the receiving side.

MMU_MACHPHYS_UPDATE processing marks the page being changed
as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
callers thereof) should do so too?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 10:47:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrljy-0001s4-DY; Fri, 21 Nov 2014 10:47: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 1Xrljw-0001rw-GG
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 10:47:00 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	65/C8-22737-3281F645; Fri, 21 Nov 2014 10:46:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416566817!9757602!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9450 invoked from network); 21 Nov 2014 10:46:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 10:46:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195184181"
Message-ID: <1416566814.26869.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 21 Nov 2014 10:46:54 +0000
In-Reply-To: <546F12F2.3020809@citrix.com>
References: <546E32BB.8090909@citrix.com>
	<1416562990.26869.10.camel@citrix.com> <546F12F2.3020809@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
> On 21/11/14 09:43, Ian Campbell wrote:
> 
> > On Thu, 2014-11-20 at 18:28 +0000, Andrew Cooper wrote:
> > > Realistically, this means no updates to the
> > > p2m at all, due to several potential race conditions.
> > From the rest of the mail it seems as if you are talking primarily about
> > changes to the p2m *structure*, i.e. which guest frames contain the p2m
> > pages, rather than changes to the p2m entries themselves. Is that
> > correct?
> 
> I cover both, although the structure changes are the more obvious, and
> more complicated to fix.

Sure.

> There are race conditions in both existing implementation between a
> p2m/m2p update and the toolstack sampling the dirty bitmap where stale
> frames don't get resent.
> 
> > 
> > I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
> > here, where does that fit in?
> > 
> 
> It is referenced several times, although not by its exact name.

Hence no explicit mention.

It's ambiguous when you refer to "higher level frames" (which I presume
are the reference you are referring to) because some kernels (perhaps
only historic ones, I've not been keeping up) keep both an N-level tree
of their own internally and the toolstack visible frame_list_list
(sometimes partially overlapping at some level). Is every reference to
"higher level frames" actually intended to be a reference to
pfn_to_mfn_frame_list_list or not?

It seems like sometimes you are talking at times about tracking the
kernel's internal structure and not just pfn_to_mfn_frame_list_list and
I'm not sure why that would be. I'm also not sure why
pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
AFAIK the guest is still obliged to keep that up to date regardless of
the scheme it uses internally for accessing the p2m.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 10:47:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrljy-0001s4-DY; Fri, 21 Nov 2014 10:47: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 1Xrljw-0001rw-GG
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 10:47:00 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	65/C8-22737-3281F645; Fri, 21 Nov 2014 10:46:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416566817!9757602!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9450 invoked from network); 21 Nov 2014 10:46:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 10:46:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195184181"
Message-ID: <1416566814.26869.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 21 Nov 2014 10:46:54 +0000
In-Reply-To: <546F12F2.3020809@citrix.com>
References: <546E32BB.8090909@citrix.com>
	<1416562990.26869.10.camel@citrix.com> <546F12F2.3020809@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
> On 21/11/14 09:43, Ian Campbell wrote:
> 
> > On Thu, 2014-11-20 at 18:28 +0000, Andrew Cooper wrote:
> > > Realistically, this means no updates to the
> > > p2m at all, due to several potential race conditions.
> > From the rest of the mail it seems as if you are talking primarily about
> > changes to the p2m *structure*, i.e. which guest frames contain the p2m
> > pages, rather than changes to the p2m entries themselves. Is that
> > correct?
> 
> I cover both, although the structure changes are the more obvious, and
> more complicated to fix.

Sure.

> There are race conditions in both existing implementation between a
> p2m/m2p update and the toolstack sampling the dirty bitmap where stale
> frames don't get resent.
> 
> > 
> > I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
> > here, where does that fit in?
> > 
> 
> It is referenced several times, although not by its exact name.

Hence no explicit mention.

It's ambiguous when you refer to "higher level frames" (which I presume
are the reference you are referring to) because some kernels (perhaps
only historic ones, I've not been keeping up) keep both an N-level tree
of their own internally and the toolstack visible frame_list_list
(sometimes partially overlapping at some level). Is every reference to
"higher level frames" actually intended to be a reference to
pfn_to_mfn_frame_list_list or not?

It seems like sometimes you are talking at times about tracking the
kernel's internal structure and not just pfn_to_mfn_frame_list_list and
I'm not sure why that would be. I'm also not sure why
pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
AFAIK the guest is still obliged to keep that up to date regardless of
the scheme it uses internally for accessing the p2m.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 10:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:55:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrlrn-000286-Ht; Fri, 21 Nov 2014 10:55:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xrlrm-000281-BX
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 10:55:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DB/3C-25276-90A1F645; Fri, 21 Nov 2014 10:55:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416567303!12239682!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1391 invoked from network); 21 Nov 2014 10:55:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 10:55:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195186213"
Message-ID: <546F19FF.5070706@citrix.com>
Date: Fri, 21 Nov 2014 10:54:55 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546E32BB.8090909@citrix.com>
	<546F25700200007800049AB4@smtp.nue.novell.com>
In-Reply-To: <546F25700200007800049AB4@smtp.nue.novell.com>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 21/11/14 10:43, Jan Beulich wrote:
>>>> On 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
>> Should the guest change the p2m structure during live migration, the
>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
>> resulting in bogus cross-referencing.  Should the guest change an entry
>> in the p2m, the p2m frame itself will be resent as it would be marked as
>> dirty in the logdirty bitmap, but the target pfn will remain unsent and
>> probably stale on the receiving side.
> MMU_MACHPHYS_UPDATE processing marks the page being changed
> as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
> callers thereof) should do so too?
>
> Jan
>

This is certainly needed to fix HVM ballooning and live migration
issues, although now you point it out, it applies just as much to PV
guests as HVM guests.

I believe this might allow the toolstack to avoid keeping a second copy
of the p2m.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 10:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 10:55:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrlrn-000286-Ht; Fri, 21 Nov 2014 10:55:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xrlrm-000281-BX
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 10:55:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DB/3C-25276-90A1F645; Fri, 21 Nov 2014 10:55:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416567303!12239682!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1391 invoked from network); 21 Nov 2014 10:55:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 10:55:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195186213"
Message-ID: <546F19FF.5070706@citrix.com>
Date: Fri, 21 Nov 2014 10:54:55 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546E32BB.8090909@citrix.com>
	<546F25700200007800049AB4@smtp.nue.novell.com>
In-Reply-To: <546F25700200007800049AB4@smtp.nue.novell.com>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 21/11/14 10:43, Jan Beulich wrote:
>>>> On 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
>> Should the guest change the p2m structure during live migration, the
>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
>> resulting in bogus cross-referencing.  Should the guest change an entry
>> in the p2m, the p2m frame itself will be resent as it would be marked as
>> dirty in the logdirty bitmap, but the target pfn will remain unsent and
>> probably stale on the receiving side.
> MMU_MACHPHYS_UPDATE processing marks the page being changed
> as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
> callers thereof) should do so too?
>
> Jan
>

This is certainly needed to fix HVM ballooning and live migration
issues, although now you point it out, it applies just as much to PV
guests as HVM guests.

I believe this might allow the toolstack to avoid keeping a second copy
of the p2m.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:04:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11: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 1Xrm0e-0002N4-JM; Fri, 21 Nov 2014 11:04: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 1Xrm0d-0002Mz-Np
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:04:15 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	5A/7A-09284-E2C1F645; Fri, 21 Nov 2014 11:04:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416567851!10477976!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24330 invoked from network); 21 Nov 2014 11:04:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:04:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193655458"
Message-ID: <1416567797.26869.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Gedalya <gedalya@gedalya.net>
Date: Fri, 21 Nov 2014 11:03:17 +0000
In-Reply-To: <546EADD0.8010002@gedalya.net>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, 767295@bugs.debian.org, xen-devel@lists.xen.org,
	ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 22:13 -0500, Gedalya wrote:
> On 11/20/2014 03:21 PM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
> >> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> >> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> >> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> >> up leaked.
> >>
> >> The memory pool currently supports mmap'd buffers as well as a directly
> >> allocated buffers, however the try decode routines make use of realloc and do
> >> not fit well into this model. Introduce a concept of an external memory block
> >> to the memory pool and provide an interface to register such memory.
> >>
> >> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> >> mmap_ prefix since they are now also used for external memory blocks.
> >>
> >> We are only seeing this now because the gzip decoder doesn't leak and it's only
> >> relatively recently that kernels in the wild have switched to better
> >> compression.
> >>
> >> This is https://bugs.debian.org/767295
> >>
> >> Reported by: Gedalya <gedalya@gedalya.net>
> > Gedelya,
> >
> > Could you also test this patch to make sure it does fix the
> > reported issue please?
> 
> So here's what happens now.
> 1. Starts up tiny
> 2. reboot: leak
> 3. reboot: freed (process larger, but the delta is all/mostly shared pages)
> 4. reboot: leak
> 5. reboot: freed
> etc..

WTF, how very strange!

> root@xen:~/xen-pkgs# xl cr /etc/xen/auto/asterisk_deb80.cfg
> Parsing config from /etc/xen/auto/asterisk_deb80.cfg
> root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
> root     22981  0.0  0.0  95968   588 ?        SLsl 21:55   0:00 /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
> root@xen:~/xen-pkgs# pmap -x 22981
> 22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
> Address           Kbytes     RSS   Dirty Mode  Mapping
> 0000000000400000     144     128       0 r-x-- xl
> 0000000000623000       4       4       4 r---- xl
> 0000000000624000       8       8       8 rw--- xl
> 0000000000626000       4       4       4 rw---   [ anon ]
> 00000000009a6000     288     240     240 rw---   [ anon ]
> 00007f14d4000000     132       8       8 rw---   [ anon ]
> 00007f14d4021000   65404       0       0 -----   [ anon ]
> << snip >>
> ---------------- ------- ------- -------
> total kB           95968    2728     596
> 
> --- reboot domu ---
> 
> root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
> root     22981  0.6  3.3 131652 20008 ?        SLsl 21:55   0:00 /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
> root@xen:~/xen-pkgs# pmap -x 22981
> 22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
> Address           Kbytes     RSS   Dirty Mode  Mapping
> 0000000000400000     144     144       0 r-x-- xl
> 0000000000623000       4       4       4 r---- xl
> 0000000000624000       8       8       8 rw--- xl
> 0000000000626000       4       4       4 rw---   [ anon ]
> 00000000009a6000     288     288     288 rw---   [ anon ]
> 00000000009ee000   35676   16772   16772 rw---   [ anon ]

This is the (temporarily) leaked mapping, right?

> Tried valgrind, it doesn't look like it was able to see what was going on

Indeed. The values for total heap usage at exist and still reachable etc
also don't seem to account for the ~3M of mapping on each iteration.

I don't know how glibc's allocator works, but I suppose it isn't
impossible that it is retaining some mappings of free regions and
collecting them to free later somehow, which just happens to only
trigger every other reboot (e.g. perhaps it is based on some threshold
of free memory).

...investigates...

So, http://man7.org/linux/man-pages/man3/malloc.3.html talks about
special behaviour using mmap for allocations above MMAP_THRESHOLD (128K
by default), which we will be hitting here I think. That explains the
anon mapping.

http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about
various dynamic thresholds for growing and shrinking the heap. My guess
is that we are bouncing up and down over some threshold with every other
reboot.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:04:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11: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 1Xrm0e-0002N4-JM; Fri, 21 Nov 2014 11:04: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 1Xrm0d-0002Mz-Np
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:04:15 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	5A/7A-09284-E2C1F645; Fri, 21 Nov 2014 11:04:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416567851!10477976!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24330 invoked from network); 21 Nov 2014 11:04:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:04:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193655458"
Message-ID: <1416567797.26869.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Gedalya <gedalya@gedalya.net>
Date: Fri, 21 Nov 2014 11:03:17 +0000
In-Reply-To: <546EADD0.8010002@gedalya.net>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, 767295@bugs.debian.org, xen-devel@lists.xen.org,
	ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 22:13 -0500, Gedalya wrote:
> On 11/20/2014 03:21 PM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
> >> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> >> is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> >> than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> >> up leaked.
> >>
> >> The memory pool currently supports mmap'd buffers as well as a directly
> >> allocated buffers, however the try decode routines make use of realloc and do
> >> not fit well into this model. Introduce a concept of an external memory block
> >> to the memory pool and provide an interface to register such memory.
> >>
> >> The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> >> mmap_ prefix since they are now also used for external memory blocks.
> >>
> >> We are only seeing this now because the gzip decoder doesn't leak and it's only
> >> relatively recently that kernels in the wild have switched to better
> >> compression.
> >>
> >> This is https://bugs.debian.org/767295
> >>
> >> Reported by: Gedalya <gedalya@gedalya.net>
> > Gedelya,
> >
> > Could you also test this patch to make sure it does fix the
> > reported issue please?
> 
> So here's what happens now.
> 1. Starts up tiny
> 2. reboot: leak
> 3. reboot: freed (process larger, but the delta is all/mostly shared pages)
> 4. reboot: leak
> 5. reboot: freed
> etc..

WTF, how very strange!

> root@xen:~/xen-pkgs# xl cr /etc/xen/auto/asterisk_deb80.cfg
> Parsing config from /etc/xen/auto/asterisk_deb80.cfg
> root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
> root     22981  0.0  0.0  95968   588 ?        SLsl 21:55   0:00 /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
> root@xen:~/xen-pkgs# pmap -x 22981
> 22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
> Address           Kbytes     RSS   Dirty Mode  Mapping
> 0000000000400000     144     128       0 r-x-- xl
> 0000000000623000       4       4       4 r---- xl
> 0000000000624000       8       8       8 rw--- xl
> 0000000000626000       4       4       4 rw---   [ anon ]
> 00000000009a6000     288     240     240 rw---   [ anon ]
> 00007f14d4000000     132       8       8 rw---   [ anon ]
> 00007f14d4021000   65404       0       0 -----   [ anon ]
> << snip >>
> ---------------- ------- ------- -------
> total kB           95968    2728     596
> 
> --- reboot domu ---
> 
> root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
> root     22981  0.6  3.3 131652 20008 ?        SLsl 21:55   0:00 /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
> root@xen:~/xen-pkgs# pmap -x 22981
> 22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
> Address           Kbytes     RSS   Dirty Mode  Mapping
> 0000000000400000     144     144       0 r-x-- xl
> 0000000000623000       4       4       4 r---- xl
> 0000000000624000       8       8       8 rw--- xl
> 0000000000626000       4       4       4 rw---   [ anon ]
> 00000000009a6000     288     288     288 rw---   [ anon ]
> 00000000009ee000   35676   16772   16772 rw---   [ anon ]

This is the (temporarily) leaked mapping, right?

> Tried valgrind, it doesn't look like it was able to see what was going on

Indeed. The values for total heap usage at exist and still reachable etc
also don't seem to account for the ~3M of mapping on each iteration.

I don't know how glibc's allocator works, but I suppose it isn't
impossible that it is retaining some mappings of free regions and
collecting them to free later somehow, which just happens to only
trigger every other reboot (e.g. perhaps it is based on some threshold
of free memory).

...investigates...

So, http://man7.org/linux/man-pages/man3/malloc.3.html talks about
special behaviour using mmap for allocations above MMAP_THRESHOLD (128K
by default), which we will be hitting here I think. That explains the
anon mapping.

http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about
various dynamic thresholds for growing and shrinking the heap. My guess
is that we are bouncing up and down over some threshold with every other
reboot.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:05:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11: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 1Xrm2C-0002SJ-3A; Fri, 21 Nov 2014 11:05:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1Xrm2A-0002SD-Qm
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 11:05:51 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	17/AE-24124-E8C1F645; Fri, 21 Nov 2014 11:05:50 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416567944!8524296!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12903 invoked from network); 21 Nov 2014 11:05:44 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:05:44 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so11628974wiw.1
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 03:05:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=wnCZSqjiuCHtHwlav7YHix+R3ubd6f0+kBYBStEJstI=;
	b=IYJDq6i+LzwL+ju080+CYQkqSBoNW4DVUua8x/ao3ymOzwO6/755rZlcdjOIlbHODi
	6YVMHjwqygjCU908fN0ZcsEF8csOlipJ5FOYrmJs0d9H+H1rWr1yOKCVUx5B1Pggy9H6
	e5uCR3m6omeeWrj1DjeTAcYtpUtMI9Gg7bCjn90WJsFIhzFt7ezqB+9zYEUtJnwCr0sd
	Z1JW4PDpgIFlFuTxm6GJyKDVRWFct02NL0prC/lcEppgsrLXGIRdBjaPv8/d0KJrcrfm
	VZ2R61sSDEUSh64cY8kwBaIfjf1IRVu1K7bBF9VYZXwpTK/bke4TnDIiSIN9uDT/odCz
	PTaw==
X-Gm-Message-State: ALoCoQmN1Pr3qT5cwc1Nh9hmafpZLV1NYnJPvybnaAhx9EhQ5suCGoj/1W/28+o3Glh9N1X5p+jC
X-Received: by 10.194.184.199 with SMTP id ew7mr6341003wjc.85.1416567944085;
	Fri, 21 Nov 2014 03:05:44 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id q9sm10829710wix.6.2014.11.21.03.05.40
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 21 Nov 2014 03:05:43 -0800 (PST)
Message-ID: <546F1C8F.4020905@m2r.biz>
Date: Fri, 21 Nov 2014 12:05:51 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <53BBA83C.3010307@m2r.biz>
	<1404809604.30343.5.camel@cihla.spice.brq.redhat.com>
	<53BBC2AA.4030503@m2r.biz> <53BBC952.1040902@m2r.biz>
	<54130761.6080501@m2r.biz> <541C2D39.1060607@m2r.biz>
	<54648477.5040505@m2r.biz> <5464A27D.4020107@m2r.biz>
	<546DCEB4.5000205@m2r.biz>
In-Reply-To: <546DCEB4.5000205@m2r.biz>
Cc: Anthony PERARD <anthony.perard@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Spice-devel] screen freezed for 2-3 minutes on
 spice connect on xen windows 7 domU's with qxl after save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5671796681831524772=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============5671796681831524772==
Content-Type: multipart/alternative;
 boundary="------------010201070203040206060506"

This is a multi-part message in MIME format.
--------------010201070203040206060506
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Length: 45534
Content-Transfer-Encoding: quoted-printable

Il 20/11/2014 12:21, Fabio Fantoni ha scritto:
> Il 13/11/2014 13:22, Fabio Fantoni ha scritto:
>> Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
>>> Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
>>>> Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
>>>>> Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
>>>>>> Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
>>>>>>> Il 08/07/2014 10:53, David Ja=9Aa ha scritto:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
>>>>>>>>> On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
>>>>>>>>> client with
>>>>>>>>> spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good 
>>>>>>>>> as kvm
>>>>>>>>> except for one problem after xl save/restore, when after 
>>>>>>>>> restore on
>>>>>>>>> spice client connect  the domU's screen freezed for 2-3 
>>>>>>>>> minutes (and
>>>>>>>>> seems also windows), after this time seems that all return to 
>>>>>>>>> works
>>>>>>>>> correctly.
>>>>>>>>> This problem happen also if spice client connect long time 
>>>>>>>>> after restore.
>>>>>>>>> With stdvga not have this problem but stdvga has many missed 
>>>>>>>>> resolutions
>>>>>>>>> and bad refresh performance.
>>>>>>>>>
>>>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>>> Client and server logs would certainly help. Please run:
>>>>>>>>    * virt-viewer with --spice-debug option
>>>>>>>>    * spice-server with SPICE_DEBUG_LEVEL environment variable set
>>>>>>>>      to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
>>>>>>>> http://libvirt.org/drvqemu.html#qemucommand )
>>>>>>>> and note the location in the logs where the freeze takes place.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> David
>>>>>>>
>>>>>>> Thanks for your reply, in attachments:
>>>>>>> - domU's xl cfg: W7.cfg
>>>>>>> - xl -vvv create/save/restore: xen logs.txt
>>>>>>> - remote-viewer with --spice-debug after domU's start until xl 
>>>>>>> save: spicelog-1.txt (zipped)
>>>>>>> - remote-viewer with --spice-debug after domU's xl restore: 
>>>>>>> spicelog-2.txt
>>>>>>
>>>>>> Sorry for my forgetfulness, here also qemu's log:
>>>>>> - after domU's start until xl save: qemu-dm-W7.log.1
>>>>>> - after domU's xl restore: qemu-dm-W7.log
>>>>>>
>>>>>>>
>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>>
>>>>>>>
>>>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Spice-devel mailing list
>>>>>>>> Spice-devel@lists.freedesktop.org
>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>>>
>>>>>
>>>>> The problem persist, this time I saw these in xl dmesg after restore:
>>>>>
>>>>> (XEN) HVM2 restore: CPU 0
>>>>> (XEN) HVM2 restore: CPU 1
>>>>> (XEN) HVM2 restore: PIC 0
>>>>> (XEN) HVM2 restore: PIC 1
>>>>> (XEN) HVM2 restore: IOAPIC 0
>>>>> (XEN) HVM2 restore: LAPIC 0
>>>>> (XEN) HVM2 restore: LAPIC 1
>>>>> (XEN) HVM2 restore: LAPIC_REGS 0
>>>>> (XEN) HVM2 restore: LAPIC_REGS 1
>>>>> (XEN) HVM2 restore: PCI_IRQ 0
>>>>> (XEN) HVM2 restore: ISA_IRQ 0
>>>>> (XEN) HVM2 restore: PCI_LINK 0
>>>>> (XEN) HVM2 restore: PIT 0
>>>>> (XEN) HVM2 restore: RTC 0
>>>>> (XEN) HVM2 restore: HPET 0
>>>>> (XEN) HVM2 restore: PMTIMER 0
>>>>> (XEN) HVM2 restore: MTRR 0
>>>>> (XEN) HVM2 restore: MTRR 1
>>>>> (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
>>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 0
>>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 1
>>>>> (XEN) HVM2 restore: VMCE_VCPU 0
>>>>> (XEN) HVM2 restore: VMCE_VCPU 1
>>>>> (XEN) HVM2 restore: TSC_ADJUST 0
>>>>> (XEN) HVM2 restore: TSC_ADJUST 1
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
>>>>> (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from 
>>>>> (4) to (32) frames.
>>>>> (XEN) irq.c:380: Dom2 callback via changed to GSI 24
>>>>>
>>>>> Tested on latest staging (commit 
>>>>> 7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:
>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>>>
>>>>> If you need more informations or tests tell me and I'll post them.
>>>>> Thanks for any reply and sorry for my bad english.
>>>>
>>>> I did another tests updating to latest git staging (commit 
>>>> 3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of 
>>>> "only" 2-3 minutes but now when it appears to restart (after 2-3 
>>>> minutes) windows domUs undefinitely hangs instead.
>>>> No further details in xen and domU's logs.
>>>>
>>>> If you need more tests/details tell me and I'll do them.
>>>>
>>>> Thanks for any reply.
>>>
>>> I did a new test with xen build based on tag 4.5.0-rc2 and on xl 
>>> dmesg show these errors:
>>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>>> Before and after save/restore, with stdvga instead not show them.
>>
>> Sorry, I found that was introduced by new winpv drivers update 
>> instead and I solved applying this patch:
>> x86/hvm: Add per-vcpu evtchn upcalls v3 
>> http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html
>> About save/restore problem with qxl I still not found a solution or 
>> at least the exact cause :(
>
> I tried a strace on qemu process when windows (in domU) is in temp. 
> freeze and still does many operations (seems similar), I post below a 
> small part if can be useful.
> I noted for example some of these lines:
> read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
> temporarily unavailable)
> Is it normal=3F
>
> ...
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 4197512}, NULL, 8) =3D 2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, 
> revents=3DPOLLIN}], left {0, 4193071})
> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
> read(30, "W\0\0\0", 4)                  =3D 4
> write(30, "W\0\0\0", 4)                 =3D 4
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0
> gettimeofday({1416480295, 28658}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0
> gettimeofday({1416480295, 28811}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})
> *read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
> temporarily unavailable)*
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
> clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D 0x7f4a3b2cc000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D 0x7f4a3b2cb000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D 0x7f4a3b2ca000
> clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D 0x7f4a3b2c9000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D 0x7f4a3b2c8000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D 0x7f4a3b2c7000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D 0x7f4a3b2c6000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D 0x7f4a3b2c5000
> clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D 0x7f4a3b2c4000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D 0x7f4a3b2c3000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D 0x7f4a3b2c2000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D 0x7f4a3b2c1000
> clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> read(6, "\1\0\0\0\0\0\0\0", 512)        =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0
> gettimeofday({1416480295, 35292}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0
> gettimeofday({1416480295, 35746}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0
> gettimeofday({1416480295, 35898}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 13233688}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
> revents=3DPOLLIN}], left {0, 13227138})
> read(20, 
> "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"..., 
> 69632) =3D 101
> clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0
> gettimeofday({1416480295, 36400}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0
> gettimeofday({1416480295, 36550}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 12581076}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
> revents=3DPOLLIN}], left {0, 12576281})
> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
> read(20, 
> "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"..., 
> 69632) =3D 101
> clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0
> gettimeofday({1416480295, 37123}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0
> gettimeofday({1416480295, 37273}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 11857546}, NULL, 8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 
> 9477611})
> *read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
> temporarily unavailable)*
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> read(6, "\5\0\0\0\0\0\0\0", 512)        =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0
> gettimeofday({1416480295, 40643}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0
> gettimeofday({1416480295, 40946}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0
> gettimeofday({1416480295, 41097}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d4000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d3000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d2000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d1000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d0000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2cf000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2ce000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2cd000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2cc000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2cb000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2ca000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c9000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c8000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c7000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c6000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c5000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b435000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b434000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b433000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b432000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2db000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2da000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d9000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d8000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d7000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d6000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d5000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0
> gettimeofday({1416480295, 48329}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0
> gettimeofday({1416480295, 48632}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0
> gettimeofday({1416480295, 48783}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, 
> revents=3DPOLLIN}], left {0, 0})
> read(8, "\4\0\0\0\0\0\0\0", 16)         =3D 8
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c4000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c3000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c2000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c1000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
> clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0
> gettimeofday({1416480295, 52051}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0
> gettimeofday({1416480295, 52426}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0
> gettimeofday({1416480295, 52576}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
> clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
> clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0
> gettimeofday({1416480295, 55341}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0
> gettimeofday({1416480295, 55725}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0
> gettimeofday({1416480295, 55876}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, 
> revents=3DPOLLIN}], left {0, 0})
> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b435000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b434000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b433000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b432000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2db000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2da000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d9000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d8000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
> read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0
> gettimeofday({1416480295, 58810}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0
> gettimeofday({1416480295, 59114}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0
> gettimeofday({1416480295, 59265}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
> revents=3DPOLLIN}], left {0, 0})
> ...
>
> Strace of domU's qemu process during freeze can be useful=3F I must do a 
> more specific tests=3F
> If you need more informations/tests tell me and I'll post them.

xen save/restore seems don't save hvm domUs vga's videoram but kvm/qemu 
save yes, is it correct=3F
can be the cause of problem and/or other problem=3F

>
> Thanks for any reply and sorry for my bad english.
>
>
>>
>>>
>>> Below I posted full xl dmesg of domU, if you need more 
>>> informations/tests tell me and I'll post them.
>>>
>>>
>>>> (d4) HVM Loader
>>>> (d4) Detected Xen v4.5.0-rc
>>>> (d4) Xenbus rings @0xfeffc000, event channel 1
>>>> (d4) System requested SeaBIOS
>>>> (d4) CPU speed is 2660 MHz
>>>> (d4) Relocating guest memory for lowmem MMIO space disabled
>>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -> 5
>>>> (d4) PCI-ISA link 0 routed to IRQ5
>>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -> 10
>>>> (d4) PCI-ISA link 1 routed to IRQ10
>>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -> 11
>>>> (d4) PCI-ISA link 2 routed to IRQ11
>>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -> 5
>>>> (d4) PCI-ISA link 3 routed to IRQ5
>>>> (d4) pci dev 01:3 INTA->IRQ10
>>>> (d4) pci dev 02:0 INTA->IRQ11
>>>> (d4) pci dev 03:0 INTA->IRQ5
>>>> (d4) pci dev 04:0 INTA->IRQ5
>>>> (d4) pci dev 05:0 INTA->IRQ10
>>>> (d4) pci dev 06:0 INTA->IRQ11
>>>> (d4) pci dev 1d:0 INTA->IRQ10
>>>> (d4) pci dev 1d:1 INTB->IRQ11
>>>> (d4) pci dev 1d:2 INTC->IRQ5
>>>> (d4) pci dev 1d:7 INTD->IRQ5
>>>> (d4) No RAM in high memory; setting high_mem resource base to 100000000
>>>> (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>>> (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>>> (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>>> (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>>> (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>>> (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>>> (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>>> (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>>> (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>>> (d4) pci dev 02:0 bar 10 size 000000100: 00000c001
>>>> (d4) pci dev 06:0 bar 10 size 000000100: 00000c101
>>>> (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>>> (d4) pci dev 04:0 bar 10 size 000000020: 00000c201
>>>> (d4) pci dev 05:0 bar 1c size 000000020: 00000c221
>>>> (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>>> (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>>> (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>>> (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>>> (d4) Multiprocessor initialisation:
>>>> (d4)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>> ... done.
>>>> (d4)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>> ... done.
>>>> (d4) Testing HVM environment:
>>>> (d4)  - REP INSB across page boundaries ... passed
>>>> (d4)  - GS base MSRs and SWAPGS ... passed
>>>> (d4) Passed 2 of 2 tests
>>>> (d4) Writing SMBIOS tables ...
>>>> (d4) Loading SeaBIOS ...
>>>> (d4) Creating MP tables ...
>>>> (d4) Loading ACPI ...
>>>> (d4) S3 disabled
>>>> (d4) S4 disabled
>>>> (d4) vm86 TSS at fc00a100
>>>> (d4) BIOS map:
>>>> (d4)  10000-100d3: Scratch space
>>>> (d4)  c0000-fffff: Main BIOS
>>>> (d4) E820 table:
>>>> (d4)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>>> (d4)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>>> (d4)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>>> (d4)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>>> (d4)  HOLE: 00000000:78000000 - 00000000:fc000000
>>>> (d4)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>>> (d4) Invoking SeaBIOS ...
>>>> (d4) SeaBIOS (version 
>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>> (d4)
>>>> (d4) Found Xen hypervisor signature at 40000100
>>>> (d4) Running on QEMU (i440fx)
>>>> (d4) xen: copy e820...
>>>> (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>>> (d4) CPU Mhz=3D2661
>>>> (d4) Found 13 PCI devices (max PCI bus is 00)
>>>> (d4) Allocated Xen hypercall page at 77fff000
>>>> (d4) Detected Xen v4.5.0-rc
>>>> (d4) xen: copy BIOS tables...
>>>> (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>>> (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>>> (d4) Copying PIR from 0x00010030 to 0x000f0dc0
>>>> (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>>> (d4) Using pmtimer, ioport 0xb008
>>>> (d4) Scan for VGA option rom
>>>> (d4) Running option rom at c000:0003
>>>> (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes
>>>> (d4) pmm call arg1=3D0
>>>> (d4) Turning on vga text mode console
>>>> (d4) SeaBIOS (version 
>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>> (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838
>>>> (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)
>>>> (d4) Found 0 lpt ports
>>>> (d4) Found 0 serial ports
>>>> (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>>> (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>>> (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)
>>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>>> (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
>>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
>>>> (d4) UHCI init on dev 00:1d.0 (io=3Dc240)
>>>> (d4) UHCI init on dev 00:1d.1 (io=3Dc260)
>>>> (d4) UHCI init on dev 00:1d.2 (io=3Dc280)
>>>> (d4) PS2 keyboard initialized
>>>> (d4) All threads complete.
>>>> (d4) Scan for option roms
>>>> (d4) Running option rom at c980:0003
>>>> (d4) pmm call arg1=3D1
>>>> (d4) pmm call arg1=3D0
>>>> (d4) pmm call arg1=3D1
>>>> (d4) pmm call arg1=3D0
>>>> (d4) Searching bootorder for: /pci@i0cf8/*@6
>>>> (d4)
>>>> (d4) Press F12 for boot menu.
>>>> (d4)
>>>> (d4) Searching bootorder for: HALT
>>>> (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba 
>>>> LCHS=3D1024/255/63 s=3D102400000
>>>> (d4)
>>>> (d4) Space available for UMB: ca800-ee800, f0000-f0ce0
>>>> (d4) Returned 258048 bytes of ZoneHigh
>>>> (d4) e820 map has 6 items:
>>>> (d4)   0: 0000000000000000 - 000000000009fc00 =3D 1 RAM
>>>> (d4)   1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED
>>>> (d4)   2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED
>>>> (d4)   3: 0000000000100000 - 0000000077fff000 =3D 1 RAM
>>>> (d4)   4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED
>>>> (d4)   5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED
>>>> (d4) enter handle_19:
>>>> (d4)   NULL
>>>> (d4) Booting from DVD/CD...
>>>> (d4) Device reports MEDIUM NOT PRESENT
>>>> (d4) scsi_is_ready returned -1
>>>> (d4) Boot failed: Could not read from CDROM (code 0003)
>>>> (d4) enter handle_18:
>>>> (d4)   NULL
>>>> (d4) Booting from Hard Disk...
>>>> (d4) Booting from 0000:7c00
>>>> (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 
>>>> sp: 1 build: 1db1
>>>> (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
>>>> (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
>>>> (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
>>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -> 0
>>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -> 0
>>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -> 0
>>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -> 0
>>>> *(XEN) hvm.c:6119:d4v1 Bad HVM op 23.**
>>>> **(XEN) hvm.c:6119:d4v1 Bad HVM op 23.*
>>>> (XEN) irq.c:380: Dom4 callback via changed to GSI 24
>>>> (XEN) HVM4 save: CPU
>>>> (XEN) HVM4 save: PIC
>>>> (XEN) HVM4 save: IOAPIC
>>>> (XEN) HVM4 save: LAPIC
>>>> (XEN) HVM4 save: LAPIC_REGS
>>>> (XEN) HVM4 save: PCI_IRQ
>>>> (XEN) HVM4 save: ISA_IRQ
>>>> (XEN) HVM4 save: PCI_LINK
>>>> (XEN) HVM4 save: PIT
>>>> (XEN) HVM4 save: RTC
>>>> (XEN) HVM4 save: HPET
>>>> (XEN) HVM4 save: PMTIMER
>>>> (XEN) HVM4 save: MTRR
>>>> (XEN) HVM4 save: VIRIDIAN_DOMAIN
>>>> (XEN) HVM4 save: CPU_XSAVE
>>>> (XEN) HVM4 save: VIRIDIAN_VCPU
>>>> (XEN) HVM4 save: VMCE_VCPU
>>>> (XEN) HVM4 save: TSC_ADJUST
>>>> (XEN) HVM5 restore: CPU 0
>>>> (XEN) HVM5 restore: CPU 1
>>>> (XEN) HVM5 restore: PIC 0
>>>> (XEN) HVM5 restore: PIC 1
>>>> (XEN) HVM5 restore: IOAPIC 0
>>>> (XEN) HVM5 restore: LAPIC 0
>>>> (XEN) HVM5 restore: LAPIC 1
>>>> (XEN) HVM5 restore: LAPIC_REGS 0
>>>> (XEN) HVM5 restore: LAPIC_REGS 1
>>>> (XEN) HVM5 restore: PCI_IRQ 0
>>>> (XEN) HVM5 restore: ISA_IRQ 0
>>>> (XEN) HVM5 restore: PCI_LINK 0
>>>> (XEN) HVM5 restore: PIT 0
>>>> (XEN) HVM5 restore: RTC 0
>>>> (XEN) HVM5 restore: HPET 0
>>>> (XEN) HVM5 restore: PMTIMER 0
>>>> (XEN) HVM5 restore: MTRR 0
>>>> (XEN) HVM5 restore: MTRR 1
>>>> (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0
>>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 0
>>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 1
>>>> (XEN) HVM5 restore: VMCE_VCPU 0
>>>> (XEN) HVM5 restore: VMCE_VCPU 1
>>>> (XEN) HVM5 restore: TSC_ADJUST 0
>>>> (XEN) HVM5 restore: TSC_ADJUST 1
>>>> (XEN) irq.c:380: Dom5 callback via changed to None
>>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>>>> (XEN) irq.c:380: Dom5 callback via changed to GSI 24
>>>
>>>
>>
>


--------------010201070203040206060506
Content-Type: text/html; charset=windows-1252
Content-Length: 59109
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Il 20/11/2014 12:21, Fabio Fantoni ha
      scritto:<br>
    </div>
    <blockquote cite=3D"mid:546DCEB4.5000205@m2r.biz" type=3D"cite">
      <meta content=3D"text/html; charset=3Dwindows-1252"
        http-equiv=3D"Content-Type">
      <div class=3D"moz-cite-prefix">Il 13/11/2014 13:22, Fabio Fantoni ha
        scritto:<br>
      </div>
      <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite">
        <meta content=3D"text/html; charset=3Dwindows-1252"
          http-equiv=3D"Content-Type">
        <div class=3D"moz-cite-prefix">Il 13/11/2014 11:14, Fabio Fantoni
          ha scritto:<br>
        </div>
        <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite">
          <meta content=3D"text/html; charset=3Dwindows-1252"
            http-equiv=3D"Content-Type">
          <div class=3D"moz-cite-prefix">Il 19/09/2014 15:18, Fabio
            Fantoni ha scritto:<br>
          </div>
          <blockquote cite=3D"mid:541C2D39.1060607@m2r.biz" type=3D"cite">Il
            12/09/2014 16:46, Fabio Fantoni ha scritto: <br>
            <blockquote type=3D"cite">Il 08/07/2014 12:34, Fabio Fantoni
              ha scritto: <br>
              <blockquote type=3D"cite">Il 08/07/2014 12:06, Fabio Fantoni
                ha scritto: <br>
                <blockquote type=3D"cite">Il 08/07/2014 10:53, David Ja=9Aa
                  ha scritto: <br>
                  <blockquote type=3D"cite">Hi, <br>
                    <br>
                    On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni
                    wrote: <br>
                    <blockquote type=3D"cite">On xen 4.5 (tried with qemu
                      2.0.0/2.1-rc0, spice 0.12.5 and client with <br>
                      spice-gtk 0.23/0.25) windows 7 domUs with qxl vga
                      works good as kvm <br>
                      except for one problem after xl save/restore, when
                      after restore on <br>
                      spice client connect=A0 the domU's screen freezed
                      for 2-3 minutes (and <br>
                      seems also windows), after this time seems that
                      all return to works <br>
                      correctly. <br>
                      This problem happen also if spice client connect
                      long time after restore. <br>
                      With stdvga not have this problem but stdvga has
                      many missed resolutions <br>
                      and bad refresh performance. <br>
                      <br>
                      If you need more tests/informations tell me and
                      I'll post them. <br>
                    </blockquote>
                    Client and server logs would certainly help. Please
                    run: <br>
                    =A0=A0 * virt-viewer with --spice-debug option <br>
                    =A0=A0 * spice-server with SPICE_DEBUG_LEVEL environment
                    variable set <br>
                    =A0=A0=A0=A0 to 4 or 5 (if you use qemu+libvirt, use
                    qemu:env element: <br>
                    =A0=A0=A0=A0 <a moz-do-not-send=3D"true"
                      class=3D"moz-txt-link-freetext"
                      href=3D"http://libvirt.org/drvqemu.html#qemucommand">http://libvirt.org/drvqemu.html#qemucommand</a>
                    ) <br>
                    and note the location in the logs where the freeze
                    takes place. <br>
                    <br>
                    Regards, <br>
                    <br>
                    David <br>
                  </blockquote>
                  <br>
                  Thanks for your reply, in attachments: <br>
                  - domU's xl cfg: W7.cfg <br>
                  - xl -vvv create/save/restore: xen logs.txt <br>
                  - remote-viewer with --spice-debug after domU's start
                  until xl save: spicelog-1.txt (zipped) <br>
                  - remote-viewer with --spice-debug after domU's xl
                  restore: spicelog-2.txt <br>
                </blockquote>
                <br>
                Sorry for my forgetfulness, here also qemu's log: <br>
                - after domU's start until xl save: qemu-dm-W7.log.1 <br>
                - after domU's xl restore: qemu-dm-W7.log <br>
                <br>
                <blockquote type=3D"cite"> <br>
                  If you need more tests/informations tell me and I'll
                  post them. <br>
                  <br>
                  <br>
                  <blockquote type=3D"cite">Thanks for any reply and sorry
                    for my bad english. <br>
                    <br>
                    _______________________________________________ <br>
                    Spice-devel mailing list <br>
                    <a moz-do-not-send=3D"true"
                      class=3D"moz-txt-link-abbreviated"
                      href=3D"mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a>
                    <br>
                    <a moz-do-not-send=3D"true"
                      class=3D"moz-txt-link-freetext"
                      href=3D"http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a>
                    <br>
                  </blockquote>
                </blockquote>
                <br>
              </blockquote>
              <br>
              The problem persist, this time I saw these in xl dmesg
              after restore: <br>
              <br>
              (XEN) HVM2 restore: CPU 0 <br>
              (XEN) HVM2 restore: CPU 1 <br>
              (XEN) HVM2 restore: PIC 0 <br>
              (XEN) HVM2 restore: PIC 1 <br>
              (XEN) HVM2 restore: IOAPIC 0 <br>
              (XEN) HVM2 restore: LAPIC 0 <br>
              (XEN) HVM2 restore: LAPIC 1 <br>
              (XEN) HVM2 restore: LAPIC_REGS 0 <br>
              (XEN) HVM2 restore: LAPIC_REGS 1 <br>
              (XEN) HVM2 restore: PCI_IRQ 0 <br>
              (XEN) HVM2 restore: ISA_IRQ 0 <br>
              (XEN) HVM2 restore: PCI_LINK 0 <br>
              (XEN) HVM2 restore: PIT 0 <br>
              (XEN) HVM2 restore: RTC 0 <br>
              (XEN) HVM2 restore: HPET 0 <br>
              (XEN) HVM2 restore: PMTIMER 0 <br>
              (XEN) HVM2 restore: MTRR 0 <br>
              (XEN) HVM2 restore: MTRR 1 <br>
              (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0 <br>
              (XEN) HVM2 restore: VIRIDIAN_VCPU 0 <br>
              (XEN) HVM2 restore: VIRIDIAN_VCPU 1 <br>
              (XEN) HVM2 restore: VMCE_VCPU 0 <br>
              (XEN) HVM2 restore: VMCE_VCPU 1 <br>
              (XEN) HVM2 restore: TSC_ADJUST 0 <br>
              (XEN) HVM2 restore: TSC_ADJUST 1 <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
              <br>
              (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant
              table from (4) to (32) frames. <br>
              (XEN) irq.c:380: Dom2 callback via changed to GSI 24 <br>
              <br>
              Tested on latest staging (commit
              7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice
              patches: <br>
              <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
                href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a>
              <br>
              <br>
              If you need more informations or tests tell me and I'll
              post them. <br>
              Thanks for any reply and sorry for my bad english. <br>
            </blockquote>
            <br>
            I did another tests updating to latest git staging (commit
            3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore
            problem of "only" 2-3 minutes but now when it appears to
            restart (after 2-3 minutes) windows domUs undefinitely hangs
            instead. <br>
            No further details in xen and domU's logs. <br>
            <br>
            If you need more tests/details tell me and I'll do them. <br>
            <br>
            Thanks for any reply. <br>
          </blockquote>
          <br>
          I did a new test with xen build based on tag 4.5.0-rc2 and on
          xl dmesg show these errors:<br>
          <blockquote type=3D"cite"><b>(XEN) hvm.c:6119:d5v0 Bad HVM op
              23.</b></blockquote>
          Before and after save/restore, with stdvga instead not show
          them.<br>
        </blockquote>
        <br>
        Sorry, I found that was introduced by new winpv drivers update
        instead and I solved applying this patch:<br>
        x86/hvm: Add per-vcpu evtchn upcalls v3 <a
          moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html">http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html</a><br>
        About save/restore problem with qxl I still not found a solution
        or at least the exact cause :(<br>
      </blockquote>
      <br>
      I tried a strace on qemu process when windows (in domU) is in
      temp. freeze and still does many operations (seems similar), I
      post below a small part if can be useful.<br>
      I noted for example some of these lines:<br>
      read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
      temporarily unavailable)<br>
      Is it normal=3F<br>
      <br>
      ...<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 4197512}, NULL, 8)
      =3D 2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0,
      4193071})<br>
      read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      read(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
      write(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0<br>
      gettimeofday({1416480295, 28658}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0<br>
      gettimeofday({1416480295, 28811}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
      ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
      <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
        temporarily unavailable)</b><br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
      0x7f4a3b435000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
      0x7f4a3b434000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
      0x7f4a3b433000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
      0x7f4a3b432000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
      0x7f4a3b2db000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
      0x7f4a3b2da000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
      0x7f4a3b2d9000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
      0x7f4a3b2d8000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
      0x7f4a3b2d7000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
      0x7f4a3b2d6000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
      0x7f4a3b2d5000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
      0x7f4a3b2d4000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
      0x7f4a3b2d3000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
      0x7f4a3b2d2000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
      0x7f4a3b2d1000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
      0x7f4a3b2d0000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
      0x7f4a3b2cf000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
      0x7f4a3b2ce000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
      0x7f4a3b2cd000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D
      0x7f4a3b2cc000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D
      0x7f4a3b2cb000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D
      0x7f4a3b2ca000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D
      0x7f4a3b2c9000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D
      0x7f4a3b2c8000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D
      0x7f4a3b2c7000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D
      0x7f4a3b2c6000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D
      0x7f4a3b2c5000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D
      0x7f4a3b2c4000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D
      0x7f4a3b2c3000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D
      0x7f4a3b2c2000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D
      0x7f4a3b2c1000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      read(6, "\1\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0<br>
      gettimeofday({1416480295, 35292}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0<br>
      gettimeofday({1416480295, 35746}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0<br>
      gettimeofday({1416480295, 35898}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 13233688}, NULL,
      8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left
      {0, 13227138})<br>
      read(20,
      "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"...,

      69632) =3D 101<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0<br>
      gettimeofday({1416480295, 36400}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0<br>
      gettimeofday({1416480295, 36550}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 12581076}, NULL,
      8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left
      {0, 12576281})<br>
      read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      read(20,
      "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"...,

      69632) =3D 101<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0<br>
      gettimeofday({1416480295, 37123}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0<br>
      gettimeofday({1416480295, 37273}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 11857546}, NULL,
      8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 9477611})<br>
      <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
        temporarily unavailable)</b><br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      read(6, "\5\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0<br>
      gettimeofday({1416480295, 40643}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0<br>
      gettimeofday({1416480295, 40946}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0<br>
      gettimeofday({1416480295, 41097}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
      ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d0000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2cf000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2ce000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2cd000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2cc000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2cb000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2ca000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0<br>
      gettimeofday({1416480295, 48329}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0<br>
      gettimeofday({1416480295, 48632}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0<br>
      gettimeofday({1416480295, 48783}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
      ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
      read(8, "\4\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
      0x7f4a3b435000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
      0x7f4a3b434000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
      0x7f4a3b433000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
      0x7f4a3b432000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
      0x7f4a3b2db000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
      0x7f4a3b2da000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
      0x7f4a3b2d9000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
      0x7f4a3b2d8000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0<br>
      gettimeofday({1416480295, 52051}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0<br>
      gettimeofday({1416480295, 52426}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0<br>
      gettimeofday({1416480295, 52576}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
      ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
      read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
      0x7f4a3b2d7000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
      0x7f4a3b2d6000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
      0x7f4a3b2d5000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
      0x7f4a3b2d4000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
      0x7f4a3b2d3000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
      0x7f4a3b2d2000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
      0x7f4a3b2d1000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
      0x7f4a3b2d0000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
      0x7f4a3b2cf000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
      0x7f4a3b2ce000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
      0x7f4a3b2cd000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0<br>
      gettimeofday({1416480295, 55341}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0<br>
      gettimeofday({1416480295, 55725}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0<br>
      gettimeofday({1416480295, 55876}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
      ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
      read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
      read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0<br>
      gettimeofday({1416480295, 58810}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0<br>
      gettimeofday({1416480295, 59114}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0<br>
      gettimeofday({1416480295, 59265}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
      ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
      ...<br>
      <br>
      Strace of domU's qemu process during freeze can be useful=3F I must
      do a more specific tests=3F<br>
      If you need more informations/tests tell me and I'll post them.<br>
    </blockquote>
    <br>
    <span>xen save/restore seems don't save hvm domUs vga's videoram but
      kvm/qemu save yes, is it correct=3F<br>
      can be the cause of problem and/or other problem=3F<br>
    </span><br>
    <blockquote cite=3D"mid:546DCEB4.5000205@m2r.biz" type=3D"cite"> <br>
      Thanks for any reply and sorry for my bad english.<br>
      <br>
      <br>
      <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite"> <br>
        <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite"> <br>
          Below I posted full xl dmesg of domU, if you need more
          informations/tests tell me and I'll post them.<br>
          <br>
          <br>
          <blockquote type=3D"cite">(d4) HVM Loader<br>
            (d4) Detected Xen v4.5.0-rc<br>
            (d4) Xenbus rings @0xfeffc000, event channel 1<br>
            (d4) System requested SeaBIOS<br>
            (d4) CPU speed is 2660 MHz<br>
            (d4) Relocating guest memory for lowmem MMIO space disabled<br>
            (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -&gt; 5<br>
            (d4) PCI-ISA link 0 routed to IRQ5<br>
            (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -&gt; 10<br>
            (d4) PCI-ISA link 1 routed to IRQ10<br>
            (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -&gt; 11<br>
            (d4) PCI-ISA link 2 routed to IRQ11<br>
            (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -&gt; 5<br>
            (d4) PCI-ISA link 3 routed to IRQ5<br>
            (d4) pci dev 01:3 INTA-&gt;IRQ10<br>
            (d4) pci dev 02:0 INTA-&gt;IRQ11<br>
            (d4) pci dev 03:0 INTA-&gt;IRQ5<br>
            (d4) pci dev 04:0 INTA-&gt;IRQ5<br>
            (d4) pci dev 05:0 INTA-&gt;IRQ10<br>
            (d4) pci dev 06:0 INTA-&gt;IRQ11<br>
            (d4) pci dev 1d:0 INTA-&gt;IRQ10<br>
            (d4) pci dev 1d:1 INTB-&gt;IRQ11<br>
            (d4) pci dev 1d:2 INTC-&gt;IRQ5<br>
            (d4) pci dev 1d:7 INTD-&gt;IRQ5<br>
            (d4) No RAM in high memory; setting high_mem resource base
            to 100000000<br>
            (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000<br>
            (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000<br>
            (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008<br>
            (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000<br>
            (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000<br>
            (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000<br>
            (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000<br>
            (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000<br>
            (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000<br>
            (d4) pci dev 02:0 bar 10 size 000000100: 00000c001<br>
            (d4) pci dev 06:0 bar 10 size 000000100: 00000c101<br>
            (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000<br>
            (d4) pci dev 04:0 bar 10 size 000000020: 00000c201<br>
            (d4) pci dev 05:0 bar 1c size 000000020: 00000c221<br>
            (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241<br>
            (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261<br>
            (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281<br>
            (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1<br>
            (d4) Multiprocessor initialisation:<br>
            (d4)=A0 - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs
            [1/8] ... done.<br>
            (d4)=A0 - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs
            [1/8] ... done.<br>
            (d4) Testing HVM environment:<br>
            (d4)=A0 - REP INSB across page boundaries ... passed<br>
            (d4)=A0 - GS base MSRs and SWAPGS ... passed<br>
            (d4) Passed 2 of 2 tests<br>
            (d4) Writing SMBIOS tables ...<br>
            (d4) Loading SeaBIOS ...<br>
            (d4) Creating MP tables ...<br>
            (d4) Loading ACPI ...<br>
            (d4) S3 disabled<br>
            (d4) S4 disabled<br>
            (d4) vm86 TSS at fc00a100<br>
            (d4) BIOS map:<br>
            (d4)=A0 10000-100d3: Scratch space<br>
            (d4)=A0 c0000-fffff: Main BIOS<br>
            (d4) E820 table:<br>
            (d4)=A0 [00]: 00000000:00000000 - 00000000:000a0000: RAM<br>
            (d4)=A0 HOLE: 00000000:000a0000 - 00000000:000c0000<br>
            (d4)=A0 [01]: 00000000:000c0000 - 00000000:00100000: RESERVED<br>
            (d4)=A0 [02]: 00000000:00100000 - 00000000:78000000: RAM<br>
            (d4)=A0 HOLE: 00000000:78000000 - 00000000:fc000000<br>
            (d4)=A0 [03]: 00000000:fc000000 - 00000001:00000000: RESERVED<br>
            (d4) Invoking SeaBIOS ...<br>
            (d4) SeaBIOS (version
            debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
            (d4) <br>
            (d4) Found Xen hypervisor signature at 40000100<br>
            (d4) Running on QEMU (i440fx)<br>
            (d4) xen: copy e820...<br>
            (d4) Relocating init from 0x000df619 to 0x77fae600 (size
            71995)<br>
            (d4) CPU Mhz=3D2661<br>
            (d4) Found 13 PCI devices (max PCI bus is 00)<br>
            (d4) Allocated Xen hypercall page at 77fff000<br>
            (d4) Detected Xen v4.5.0-rc<br>
            (d4) xen: copy BIOS tables...<br>
            (d4) Copying SMBIOS entry point from 0x00010010 to
            0x000f0f40<br>
            (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40<br>
            (d4) Copying PIR from 0x00010030 to 0x000f0dc0<br>
            (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90<br>
            (d4) Using pmtimer, ioport 0xb008<br>
            (d4) Scan for VGA option rom<br>
            (d4) Running option rom at c000:0003<br>
            (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes<br>
            (d4) pmm call arg1=3D0<br>
            (d4) Turning on vga text mode console<br>
            (d4) SeaBIOS (version
            debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
            (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838<br>
            (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)<br>
            (d4) Found 0 lpt ports<br>
            (d4) Found 0 serial ports<br>
            (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)<br>
            (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)<br>
            (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)<br>
            (d4) Searching bootorder for:
            /pci@i0cf8/*@1,1/drive@0/disk@0<br>
            (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]<br>
            (d4) Searching bootorder for:
            /pci@i0cf8/*@1,1/drive@0/disk@1<br>
            (d4) UHCI init on dev 00:1d.0 (io=3Dc240)<br>
            (d4) UHCI init on dev 00:1d.1 (io=3Dc260)<br>
            (d4) UHCI init on dev 00:1d.2 (io=3Dc280)<br>
            (d4) PS2 keyboard initialized<br>
            (d4) All threads complete.<br>
            (d4) Scan for option roms<br>
            (d4) Running option rom at c980:0003<br>
            (d4) pmm call arg1=3D1<br>
            (d4) pmm call arg1=3D0<br>
            (d4) pmm call arg1=3D1<br>
            (d4) pmm call arg1=3D0<br>
            (d4) Searching bootorder for: /pci@i0cf8/*@6<br>
            (d4) <br>
            (d4) Press F12 for boot menu.<br>
            (d4) <br>
            (d4) Searching bootorder for: HALT<br>
            (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba
            LCHS=3D1024/255/63 s=3D102400000<br>
            (d4) <br>
            (d4) Space available for UMB: ca800-ee800, f0000-f0ce0<br>
            (d4) Returned 258048 bytes of ZoneHigh<br>
            (d4) e820 map has 6 items:<br>
            (d4)=A0=A0 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM<br>
            (d4)=A0=A0 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED<br>
            (d4)=A0=A0 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED<br>
            (d4)=A0=A0 3: 0000000000100000 - 0000000077fff000 =3D 1 RAM<br>
            (d4)=A0=A0 4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED<br>
            (d4)=A0=A0 5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED<br>
            (d4) enter handle_19:<br>
            (d4)=A0=A0 NULL<br>
            (d4) Booting from DVD/CD...<br>
            (d4) Device reports MEDIUM NOT PRESENT<br>
            (d4) scsi_is_ready returned -1<br>
            (d4) Boot failed: Could not read from CDROM (code 0003)<br>
            (d4) enter handle_18:<br>
            (d4)=A0=A0 NULL<br>
            (d4) Booting from Hard Disk...<br>
            (d4) Booting from 0000:7c00<br>
            (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6
            minor: 1 sp: 1 build: 1db1<br>
            (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff<br>
            (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe<br>
            (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd<br>
            (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -&gt; 0<br>
            (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -&gt; 0<br>
            (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -&gt; 0<br>
            (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -&gt; 0<br>
            <b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><b><br>
            </b><b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><br>
            (XEN) irq.c:380: Dom4 callback via changed to GSI 24<br>
            (XEN) HVM4 save: CPU<br>
            (XEN) HVM4 save: PIC<br>
            (XEN) HVM4 save: IOAPIC<br>
            (XEN) HVM4 save: LAPIC<br>
            (XEN) HVM4 save: LAPIC_REGS<br>
            (XEN) HVM4 save: PCI_IRQ<br>
            (XEN) HVM4 save: ISA_IRQ<br>
            (XEN) HVM4 save: PCI_LINK<br>
            (XEN) HVM4 save: PIT<br>
            (XEN) HVM4 save: RTC<br>
            (XEN) HVM4 save: HPET<br>
            (XEN) HVM4 save: PMTIMER<br>
            (XEN) HVM4 save: MTRR<br>
            (XEN) HVM4 save: VIRIDIAN_DOMAIN<br>
            (XEN) HVM4 save: CPU_XSAVE<br>
            (XEN) HVM4 save: VIRIDIAN_VCPU<br>
            (XEN) HVM4 save: VMCE_VCPU<br>
            (XEN) HVM4 save: TSC_ADJUST<br>
            (XEN) HVM5 restore: CPU 0<br>
            (XEN) HVM5 restore: CPU 1<br>
            (XEN) HVM5 restore: PIC 0<br>
            (XEN) HVM5 restore: PIC 1<br>
            (XEN) HVM5 restore: IOAPIC 0<br>
            (XEN) HVM5 restore: LAPIC 0<br>
            (XEN) HVM5 restore: LAPIC 1<br>
            (XEN) HVM5 restore: LAPIC_REGS 0<br>
            (XEN) HVM5 restore: LAPIC_REGS 1<br>
            (XEN) HVM5 restore: PCI_IRQ 0<br>
            (XEN) HVM5 restore: ISA_IRQ 0<br>
            (XEN) HVM5 restore: PCI_LINK 0<br>
            (XEN) HVM5 restore: PIT 0<br>
            (XEN) HVM5 restore: RTC 0<br>
            (XEN) HVM5 restore: HPET 0<br>
            (XEN) HVM5 restore: PMTIMER 0<br>
            (XEN) HVM5 restore: MTRR 0<br>
            (XEN) HVM5 restore: MTRR 1<br>
            (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0<br>
            (XEN) HVM5 restore: VIRIDIAN_VCPU 0<br>
            (XEN) HVM5 restore: VIRIDIAN_VCPU 1<br>
            (XEN) HVM5 restore: VMCE_VCPU 0<br>
            (XEN) HVM5 restore: VMCE_VCPU 1<br>
            (XEN) HVM5 restore: TSC_ADJUST 0<br>
            (XEN) HVM5 restore: TSC_ADJUST 1<br>
            (XEN) irq.c:380: Dom5 callback via changed to None<br>
            <b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
            </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
            </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
            </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><br>
            (XEN) irq.c:380: Dom5 callback via changed to GSI 24</blockquote>
          <br>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------010201070203040206060506--


--===============5671796681831524772==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5671796681831524772==--


From xen-devel-bounces@lists.xen.org Fri Nov 21 11:05:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11: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 1Xrm2C-0002SJ-3A; Fri, 21 Nov 2014 11:05:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1Xrm2A-0002SD-Qm
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 11:05:51 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	17/AE-24124-E8C1F645; Fri, 21 Nov 2014 11:05:50 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416567944!8524296!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12903 invoked from network); 21 Nov 2014 11:05:44 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:05:44 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so11628974wiw.1
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 03:05:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=wnCZSqjiuCHtHwlav7YHix+R3ubd6f0+kBYBStEJstI=;
	b=IYJDq6i+LzwL+ju080+CYQkqSBoNW4DVUua8x/ao3ymOzwO6/755rZlcdjOIlbHODi
	6YVMHjwqygjCU908fN0ZcsEF8csOlipJ5FOYrmJs0d9H+H1rWr1yOKCVUx5B1Pggy9H6
	e5uCR3m6omeeWrj1DjeTAcYtpUtMI9Gg7bCjn90WJsFIhzFt7ezqB+9zYEUtJnwCr0sd
	Z1JW4PDpgIFlFuTxm6GJyKDVRWFct02NL0prC/lcEppgsrLXGIRdBjaPv8/d0KJrcrfm
	VZ2R61sSDEUSh64cY8kwBaIfjf1IRVu1K7bBF9VYZXwpTK/bke4TnDIiSIN9uDT/odCz
	PTaw==
X-Gm-Message-State: ALoCoQmN1Pr3qT5cwc1Nh9hmafpZLV1NYnJPvybnaAhx9EhQ5suCGoj/1W/28+o3Glh9N1X5p+jC
X-Received: by 10.194.184.199 with SMTP id ew7mr6341003wjc.85.1416567944085;
	Fri, 21 Nov 2014 03:05:44 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id q9sm10829710wix.6.2014.11.21.03.05.40
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 21 Nov 2014 03:05:43 -0800 (PST)
Message-ID: <546F1C8F.4020905@m2r.biz>
Date: Fri, 21 Nov 2014 12:05:51 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <53BBA83C.3010307@m2r.biz>
	<1404809604.30343.5.camel@cihla.spice.brq.redhat.com>
	<53BBC2AA.4030503@m2r.biz> <53BBC952.1040902@m2r.biz>
	<54130761.6080501@m2r.biz> <541C2D39.1060607@m2r.biz>
	<54648477.5040505@m2r.biz> <5464A27D.4020107@m2r.biz>
	<546DCEB4.5000205@m2r.biz>
In-Reply-To: <546DCEB4.5000205@m2r.biz>
Cc: Anthony PERARD <anthony.perard@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Spice-devel] screen freezed for 2-3 minutes on
 spice connect on xen windows 7 domU's with qxl after save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5671796681831524772=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============5671796681831524772==
Content-Type: multipart/alternative;
 boundary="------------010201070203040206060506"

This is a multi-part message in MIME format.
--------------010201070203040206060506
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Length: 45534
Content-Transfer-Encoding: quoted-printable

Il 20/11/2014 12:21, Fabio Fantoni ha scritto:
> Il 13/11/2014 13:22, Fabio Fantoni ha scritto:
>> Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
>>> Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
>>>> Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
>>>>> Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
>>>>>> Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
>>>>>>> Il 08/07/2014 10:53, David Ja=9Aa ha scritto:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
>>>>>>>>> On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
>>>>>>>>> client with
>>>>>>>>> spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good 
>>>>>>>>> as kvm
>>>>>>>>> except for one problem after xl save/restore, when after 
>>>>>>>>> restore on
>>>>>>>>> spice client connect  the domU's screen freezed for 2-3 
>>>>>>>>> minutes (and
>>>>>>>>> seems also windows), after this time seems that all return to 
>>>>>>>>> works
>>>>>>>>> correctly.
>>>>>>>>> This problem happen also if spice client connect long time 
>>>>>>>>> after restore.
>>>>>>>>> With stdvga not have this problem but stdvga has many missed 
>>>>>>>>> resolutions
>>>>>>>>> and bad refresh performance.
>>>>>>>>>
>>>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>>> Client and server logs would certainly help. Please run:
>>>>>>>>    * virt-viewer with --spice-debug option
>>>>>>>>    * spice-server with SPICE_DEBUG_LEVEL environment variable set
>>>>>>>>      to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
>>>>>>>> http://libvirt.org/drvqemu.html#qemucommand )
>>>>>>>> and note the location in the logs where the freeze takes place.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> David
>>>>>>>
>>>>>>> Thanks for your reply, in attachments:
>>>>>>> - domU's xl cfg: W7.cfg
>>>>>>> - xl -vvv create/save/restore: xen logs.txt
>>>>>>> - remote-viewer with --spice-debug after domU's start until xl 
>>>>>>> save: spicelog-1.txt (zipped)
>>>>>>> - remote-viewer with --spice-debug after domU's xl restore: 
>>>>>>> spicelog-2.txt
>>>>>>
>>>>>> Sorry for my forgetfulness, here also qemu's log:
>>>>>> - after domU's start until xl save: qemu-dm-W7.log.1
>>>>>> - after domU's xl restore: qemu-dm-W7.log
>>>>>>
>>>>>>>
>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>>
>>>>>>>
>>>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Spice-devel mailing list
>>>>>>>> Spice-devel@lists.freedesktop.org
>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>>>
>>>>>
>>>>> The problem persist, this time I saw these in xl dmesg after restore:
>>>>>
>>>>> (XEN) HVM2 restore: CPU 0
>>>>> (XEN) HVM2 restore: CPU 1
>>>>> (XEN) HVM2 restore: PIC 0
>>>>> (XEN) HVM2 restore: PIC 1
>>>>> (XEN) HVM2 restore: IOAPIC 0
>>>>> (XEN) HVM2 restore: LAPIC 0
>>>>> (XEN) HVM2 restore: LAPIC 1
>>>>> (XEN) HVM2 restore: LAPIC_REGS 0
>>>>> (XEN) HVM2 restore: LAPIC_REGS 1
>>>>> (XEN) HVM2 restore: PCI_IRQ 0
>>>>> (XEN) HVM2 restore: ISA_IRQ 0
>>>>> (XEN) HVM2 restore: PCI_LINK 0
>>>>> (XEN) HVM2 restore: PIT 0
>>>>> (XEN) HVM2 restore: RTC 0
>>>>> (XEN) HVM2 restore: HPET 0
>>>>> (XEN) HVM2 restore: PMTIMER 0
>>>>> (XEN) HVM2 restore: MTRR 0
>>>>> (XEN) HVM2 restore: MTRR 1
>>>>> (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
>>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 0
>>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 1
>>>>> (XEN) HVM2 restore: VMCE_VCPU 0
>>>>> (XEN) HVM2 restore: VMCE_VCPU 1
>>>>> (XEN) HVM2 restore: TSC_ADJUST 0
>>>>> (XEN) HVM2 restore: TSC_ADJUST 1
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
>>>>> (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from 
>>>>> (4) to (32) frames.
>>>>> (XEN) irq.c:380: Dom2 callback via changed to GSI 24
>>>>>
>>>>> Tested on latest staging (commit 
>>>>> 7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:
>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>>>
>>>>> If you need more informations or tests tell me and I'll post them.
>>>>> Thanks for any reply and sorry for my bad english.
>>>>
>>>> I did another tests updating to latest git staging (commit 
>>>> 3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of 
>>>> "only" 2-3 minutes but now when it appears to restart (after 2-3 
>>>> minutes) windows domUs undefinitely hangs instead.
>>>> No further details in xen and domU's logs.
>>>>
>>>> If you need more tests/details tell me and I'll do them.
>>>>
>>>> Thanks for any reply.
>>>
>>> I did a new test with xen build based on tag 4.5.0-rc2 and on xl 
>>> dmesg show these errors:
>>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>>> Before and after save/restore, with stdvga instead not show them.
>>
>> Sorry, I found that was introduced by new winpv drivers update 
>> instead and I solved applying this patch:
>> x86/hvm: Add per-vcpu evtchn upcalls v3 
>> http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html
>> About save/restore problem with qxl I still not found a solution or 
>> at least the exact cause :(
>
> I tried a strace on qemu process when windows (in domU) is in temp. 
> freeze and still does many operations (seems similar), I post below a 
> small part if can be useful.
> I noted for example some of these lines:
> read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
> temporarily unavailable)
> Is it normal=3F
>
> ...
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 4197512}, NULL, 8) =3D 2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, 
> revents=3DPOLLIN}], left {0, 4193071})
> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
> read(30, "W\0\0\0", 4)                  =3D 4
> write(30, "W\0\0\0", 4)                 =3D 4
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0
> gettimeofday({1416480295, 28658}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0
> gettimeofday({1416480295, 28811}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})
> *read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
> temporarily unavailable)*
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
> clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D 0x7f4a3b2cc000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D 0x7f4a3b2cb000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D 0x7f4a3b2ca000
> clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D 0x7f4a3b2c9000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D 0x7f4a3b2c8000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D 0x7f4a3b2c7000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D 0x7f4a3b2c6000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D 0x7f4a3b2c5000
> clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D 0x7f4a3b2c4000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D 0x7f4a3b2c3000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D 0x7f4a3b2c2000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D 0x7f4a3b2c1000
> clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> read(6, "\1\0\0\0\0\0\0\0", 512)        =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0
> gettimeofday({1416480295, 35292}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0
> gettimeofday({1416480295, 35746}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0
> gettimeofday({1416480295, 35898}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 13233688}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
> revents=3DPOLLIN}], left {0, 13227138})
> read(20, 
> "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"..., 
> 69632) =3D 101
> clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0
> gettimeofday({1416480295, 36400}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0
> gettimeofday({1416480295, 36550}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 12581076}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
> revents=3DPOLLIN}], left {0, 12576281})
> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
> read(20, 
> "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"..., 
> 69632) =3D 101
> clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0
> gettimeofday({1416480295, 37123}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0
> gettimeofday({1416480295, 37273}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 11857546}, NULL, 8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 
> 9477611})
> *read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
> temporarily unavailable)*
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> read(6, "\5\0\0\0\0\0\0\0", 512)        =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0
> gettimeofday({1416480295, 40643}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0
> gettimeofday({1416480295, 40946}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0
> gettimeofday({1416480295, 41097}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d4000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d3000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d2000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d1000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d0000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2cf000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2ce000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2cd000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2cc000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2cb000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2ca000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c9000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c8000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c7000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c6000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c5000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b435000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b434000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b433000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b432000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2db000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2da000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d9000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d8000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d7000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d6000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d5000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0
> gettimeofday({1416480295, 48329}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0
> gettimeofday({1416480295, 48632}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0
> gettimeofday({1416480295, 48783}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, 
> revents=3DPOLLIN}], left {0, 0})
> read(8, "\4\0\0\0\0\0\0\0", 16)         =3D 8
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c4000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c3000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c2000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2c1000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
> clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0
> gettimeofday({1416480295, 52051}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0
> gettimeofday({1416480295, 52426}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0
> gettimeofday({1416480295, 52576}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 1 ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
> clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
> clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0
> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
> clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0
> gettimeofday({1416480295, 55341}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0
> gettimeofday({1416480295, 55725}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0
> gettimeofday({1416480295, 55876}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, 
> revents=3DPOLLIN}], left {0, 0})
> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b435000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b434000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b433000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b432000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2db000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2da000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d9000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
> munmap(0x7f4a3b2d8000, 4096)            =3D 0
> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
> read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0
> gettimeofday({1416480295, 58810}, NULL) =3D 0
> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
> clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0
> gettimeofday({1416480295, 59114}, NULL) =3D 0
> clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0
> gettimeofday({1416480295, 59265}, NULL) =3D 0
> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, events=3DPOLLIN|POLLERR|POLLHUP}, 
> {fd=3D8, events=3DPOLLIN}, {fd=3D9, events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 
> 18, {0, 0}, NULL, 8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, 
> revents=3DPOLLIN}], left {0, 0})
> ...
>
> Strace of domU's qemu process during freeze can be useful=3F I must do a 
> more specific tests=3F
> If you need more informations/tests tell me and I'll post them.

xen save/restore seems don't save hvm domUs vga's videoram but kvm/qemu 
save yes, is it correct=3F
can be the cause of problem and/or other problem=3F

>
> Thanks for any reply and sorry for my bad english.
>
>
>>
>>>
>>> Below I posted full xl dmesg of domU, if you need more 
>>> informations/tests tell me and I'll post them.
>>>
>>>
>>>> (d4) HVM Loader
>>>> (d4) Detected Xen v4.5.0-rc
>>>> (d4) Xenbus rings @0xfeffc000, event channel 1
>>>> (d4) System requested SeaBIOS
>>>> (d4) CPU speed is 2660 MHz
>>>> (d4) Relocating guest memory for lowmem MMIO space disabled
>>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -> 5
>>>> (d4) PCI-ISA link 0 routed to IRQ5
>>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -> 10
>>>> (d4) PCI-ISA link 1 routed to IRQ10
>>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -> 11
>>>> (d4) PCI-ISA link 2 routed to IRQ11
>>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -> 5
>>>> (d4) PCI-ISA link 3 routed to IRQ5
>>>> (d4) pci dev 01:3 INTA->IRQ10
>>>> (d4) pci dev 02:0 INTA->IRQ11
>>>> (d4) pci dev 03:0 INTA->IRQ5
>>>> (d4) pci dev 04:0 INTA->IRQ5
>>>> (d4) pci dev 05:0 INTA->IRQ10
>>>> (d4) pci dev 06:0 INTA->IRQ11
>>>> (d4) pci dev 1d:0 INTA->IRQ10
>>>> (d4) pci dev 1d:1 INTB->IRQ11
>>>> (d4) pci dev 1d:2 INTC->IRQ5
>>>> (d4) pci dev 1d:7 INTD->IRQ5
>>>> (d4) No RAM in high memory; setting high_mem resource base to 100000000
>>>> (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>>> (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>>> (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>>> (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>>> (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>>> (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>>> (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>>> (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>>> (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>>> (d4) pci dev 02:0 bar 10 size 000000100: 00000c001
>>>> (d4) pci dev 06:0 bar 10 size 000000100: 00000c101
>>>> (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>>> (d4) pci dev 04:0 bar 10 size 000000020: 00000c201
>>>> (d4) pci dev 05:0 bar 1c size 000000020: 00000c221
>>>> (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>>> (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>>> (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>>> (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>>> (d4) Multiprocessor initialisation:
>>>> (d4)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>> ... done.
>>>> (d4)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>> ... done.
>>>> (d4) Testing HVM environment:
>>>> (d4)  - REP INSB across page boundaries ... passed
>>>> (d4)  - GS base MSRs and SWAPGS ... passed
>>>> (d4) Passed 2 of 2 tests
>>>> (d4) Writing SMBIOS tables ...
>>>> (d4) Loading SeaBIOS ...
>>>> (d4) Creating MP tables ...
>>>> (d4) Loading ACPI ...
>>>> (d4) S3 disabled
>>>> (d4) S4 disabled
>>>> (d4) vm86 TSS at fc00a100
>>>> (d4) BIOS map:
>>>> (d4)  10000-100d3: Scratch space
>>>> (d4)  c0000-fffff: Main BIOS
>>>> (d4) E820 table:
>>>> (d4)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>>> (d4)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>>> (d4)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>>> (d4)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>>> (d4)  HOLE: 00000000:78000000 - 00000000:fc000000
>>>> (d4)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>>> (d4) Invoking SeaBIOS ...
>>>> (d4) SeaBIOS (version 
>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>> (d4)
>>>> (d4) Found Xen hypervisor signature at 40000100
>>>> (d4) Running on QEMU (i440fx)
>>>> (d4) xen: copy e820...
>>>> (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>>> (d4) CPU Mhz=3D2661
>>>> (d4) Found 13 PCI devices (max PCI bus is 00)
>>>> (d4) Allocated Xen hypercall page at 77fff000
>>>> (d4) Detected Xen v4.5.0-rc
>>>> (d4) xen: copy BIOS tables...
>>>> (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>>> (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>>> (d4) Copying PIR from 0x00010030 to 0x000f0dc0
>>>> (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>>> (d4) Using pmtimer, ioport 0xb008
>>>> (d4) Scan for VGA option rom
>>>> (d4) Running option rom at c000:0003
>>>> (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes
>>>> (d4) pmm call arg1=3D0
>>>> (d4) Turning on vga text mode console
>>>> (d4) SeaBIOS (version 
>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>> (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838
>>>> (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)
>>>> (d4) Found 0 lpt ports
>>>> (d4) Found 0 serial ports
>>>> (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>>> (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>>> (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)
>>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>>> (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
>>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
>>>> (d4) UHCI init on dev 00:1d.0 (io=3Dc240)
>>>> (d4) UHCI init on dev 00:1d.1 (io=3Dc260)
>>>> (d4) UHCI init on dev 00:1d.2 (io=3Dc280)
>>>> (d4) PS2 keyboard initialized
>>>> (d4) All threads complete.
>>>> (d4) Scan for option roms
>>>> (d4) Running option rom at c980:0003
>>>> (d4) pmm call arg1=3D1
>>>> (d4) pmm call arg1=3D0
>>>> (d4) pmm call arg1=3D1
>>>> (d4) pmm call arg1=3D0
>>>> (d4) Searching bootorder for: /pci@i0cf8/*@6
>>>> (d4)
>>>> (d4) Press F12 for boot menu.
>>>> (d4)
>>>> (d4) Searching bootorder for: HALT
>>>> (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba 
>>>> LCHS=3D1024/255/63 s=3D102400000
>>>> (d4)
>>>> (d4) Space available for UMB: ca800-ee800, f0000-f0ce0
>>>> (d4) Returned 258048 bytes of ZoneHigh
>>>> (d4) e820 map has 6 items:
>>>> (d4)   0: 0000000000000000 - 000000000009fc00 =3D 1 RAM
>>>> (d4)   1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED
>>>> (d4)   2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED
>>>> (d4)   3: 0000000000100000 - 0000000077fff000 =3D 1 RAM
>>>> (d4)   4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED
>>>> (d4)   5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED
>>>> (d4) enter handle_19:
>>>> (d4)   NULL
>>>> (d4) Booting from DVD/CD...
>>>> (d4) Device reports MEDIUM NOT PRESENT
>>>> (d4) scsi_is_ready returned -1
>>>> (d4) Boot failed: Could not read from CDROM (code 0003)
>>>> (d4) enter handle_18:
>>>> (d4)   NULL
>>>> (d4) Booting from Hard Disk...
>>>> (d4) Booting from 0000:7c00
>>>> (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 
>>>> sp: 1 build: 1db1
>>>> (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
>>>> (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
>>>> (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
>>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -> 0
>>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -> 0
>>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -> 0
>>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -> 0
>>>> *(XEN) hvm.c:6119:d4v1 Bad HVM op 23.**
>>>> **(XEN) hvm.c:6119:d4v1 Bad HVM op 23.*
>>>> (XEN) irq.c:380: Dom4 callback via changed to GSI 24
>>>> (XEN) HVM4 save: CPU
>>>> (XEN) HVM4 save: PIC
>>>> (XEN) HVM4 save: IOAPIC
>>>> (XEN) HVM4 save: LAPIC
>>>> (XEN) HVM4 save: LAPIC_REGS
>>>> (XEN) HVM4 save: PCI_IRQ
>>>> (XEN) HVM4 save: ISA_IRQ
>>>> (XEN) HVM4 save: PCI_LINK
>>>> (XEN) HVM4 save: PIT
>>>> (XEN) HVM4 save: RTC
>>>> (XEN) HVM4 save: HPET
>>>> (XEN) HVM4 save: PMTIMER
>>>> (XEN) HVM4 save: MTRR
>>>> (XEN) HVM4 save: VIRIDIAN_DOMAIN
>>>> (XEN) HVM4 save: CPU_XSAVE
>>>> (XEN) HVM4 save: VIRIDIAN_VCPU
>>>> (XEN) HVM4 save: VMCE_VCPU
>>>> (XEN) HVM4 save: TSC_ADJUST
>>>> (XEN) HVM5 restore: CPU 0
>>>> (XEN) HVM5 restore: CPU 1
>>>> (XEN) HVM5 restore: PIC 0
>>>> (XEN) HVM5 restore: PIC 1
>>>> (XEN) HVM5 restore: IOAPIC 0
>>>> (XEN) HVM5 restore: LAPIC 0
>>>> (XEN) HVM5 restore: LAPIC 1
>>>> (XEN) HVM5 restore: LAPIC_REGS 0
>>>> (XEN) HVM5 restore: LAPIC_REGS 1
>>>> (XEN) HVM5 restore: PCI_IRQ 0
>>>> (XEN) HVM5 restore: ISA_IRQ 0
>>>> (XEN) HVM5 restore: PCI_LINK 0
>>>> (XEN) HVM5 restore: PIT 0
>>>> (XEN) HVM5 restore: RTC 0
>>>> (XEN) HVM5 restore: HPET 0
>>>> (XEN) HVM5 restore: PMTIMER 0
>>>> (XEN) HVM5 restore: MTRR 0
>>>> (XEN) HVM5 restore: MTRR 1
>>>> (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0
>>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 0
>>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 1
>>>> (XEN) HVM5 restore: VMCE_VCPU 0
>>>> (XEN) HVM5 restore: VMCE_VCPU 1
>>>> (XEN) HVM5 restore: TSC_ADJUST 0
>>>> (XEN) HVM5 restore: TSC_ADJUST 1
>>>> (XEN) irq.c:380: Dom5 callback via changed to None
>>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>>>> (XEN) irq.c:380: Dom5 callback via changed to GSI 24
>>>
>>>
>>
>


--------------010201070203040206060506
Content-Type: text/html; charset=windows-1252
Content-Length: 59109
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Il 20/11/2014 12:21, Fabio Fantoni ha
      scritto:<br>
    </div>
    <blockquote cite=3D"mid:546DCEB4.5000205@m2r.biz" type=3D"cite">
      <meta content=3D"text/html; charset=3Dwindows-1252"
        http-equiv=3D"Content-Type">
      <div class=3D"moz-cite-prefix">Il 13/11/2014 13:22, Fabio Fantoni ha
        scritto:<br>
      </div>
      <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite">
        <meta content=3D"text/html; charset=3Dwindows-1252"
          http-equiv=3D"Content-Type">
        <div class=3D"moz-cite-prefix">Il 13/11/2014 11:14, Fabio Fantoni
          ha scritto:<br>
        </div>
        <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite">
          <meta content=3D"text/html; charset=3Dwindows-1252"
            http-equiv=3D"Content-Type">
          <div class=3D"moz-cite-prefix">Il 19/09/2014 15:18, Fabio
            Fantoni ha scritto:<br>
          </div>
          <blockquote cite=3D"mid:541C2D39.1060607@m2r.biz" type=3D"cite">Il
            12/09/2014 16:46, Fabio Fantoni ha scritto: <br>
            <blockquote type=3D"cite">Il 08/07/2014 12:34, Fabio Fantoni
              ha scritto: <br>
              <blockquote type=3D"cite">Il 08/07/2014 12:06, Fabio Fantoni
                ha scritto: <br>
                <blockquote type=3D"cite">Il 08/07/2014 10:53, David Ja=9Aa
                  ha scritto: <br>
                  <blockquote type=3D"cite">Hi, <br>
                    <br>
                    On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni
                    wrote: <br>
                    <blockquote type=3D"cite">On xen 4.5 (tried with qemu
                      2.0.0/2.1-rc0, spice 0.12.5 and client with <br>
                      spice-gtk 0.23/0.25) windows 7 domUs with qxl vga
                      works good as kvm <br>
                      except for one problem after xl save/restore, when
                      after restore on <br>
                      spice client connect=A0 the domU's screen freezed
                      for 2-3 minutes (and <br>
                      seems also windows), after this time seems that
                      all return to works <br>
                      correctly. <br>
                      This problem happen also if spice client connect
                      long time after restore. <br>
                      With stdvga not have this problem but stdvga has
                      many missed resolutions <br>
                      and bad refresh performance. <br>
                      <br>
                      If you need more tests/informations tell me and
                      I'll post them. <br>
                    </blockquote>
                    Client and server logs would certainly help. Please
                    run: <br>
                    =A0=A0 * virt-viewer with --spice-debug option <br>
                    =A0=A0 * spice-server with SPICE_DEBUG_LEVEL environment
                    variable set <br>
                    =A0=A0=A0=A0 to 4 or 5 (if you use qemu+libvirt, use
                    qemu:env element: <br>
                    =A0=A0=A0=A0 <a moz-do-not-send=3D"true"
                      class=3D"moz-txt-link-freetext"
                      href=3D"http://libvirt.org/drvqemu.html#qemucommand">http://libvirt.org/drvqemu.html#qemucommand</a>
                    ) <br>
                    and note the location in the logs where the freeze
                    takes place. <br>
                    <br>
                    Regards, <br>
                    <br>
                    David <br>
                  </blockquote>
                  <br>
                  Thanks for your reply, in attachments: <br>
                  - domU's xl cfg: W7.cfg <br>
                  - xl -vvv create/save/restore: xen logs.txt <br>
                  - remote-viewer with --spice-debug after domU's start
                  until xl save: spicelog-1.txt (zipped) <br>
                  - remote-viewer with --spice-debug after domU's xl
                  restore: spicelog-2.txt <br>
                </blockquote>
                <br>
                Sorry for my forgetfulness, here also qemu's log: <br>
                - after domU's start until xl save: qemu-dm-W7.log.1 <br>
                - after domU's xl restore: qemu-dm-W7.log <br>
                <br>
                <blockquote type=3D"cite"> <br>
                  If you need more tests/informations tell me and I'll
                  post them. <br>
                  <br>
                  <br>
                  <blockquote type=3D"cite">Thanks for any reply and sorry
                    for my bad english. <br>
                    <br>
                    _______________________________________________ <br>
                    Spice-devel mailing list <br>
                    <a moz-do-not-send=3D"true"
                      class=3D"moz-txt-link-abbreviated"
                      href=3D"mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a>
                    <br>
                    <a moz-do-not-send=3D"true"
                      class=3D"moz-txt-link-freetext"
                      href=3D"http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a>
                    <br>
                  </blockquote>
                </blockquote>
                <br>
              </blockquote>
              <br>
              The problem persist, this time I saw these in xl dmesg
              after restore: <br>
              <br>
              (XEN) HVM2 restore: CPU 0 <br>
              (XEN) HVM2 restore: CPU 1 <br>
              (XEN) HVM2 restore: PIC 0 <br>
              (XEN) HVM2 restore: PIC 1 <br>
              (XEN) HVM2 restore: IOAPIC 0 <br>
              (XEN) HVM2 restore: LAPIC 0 <br>
              (XEN) HVM2 restore: LAPIC 1 <br>
              (XEN) HVM2 restore: LAPIC_REGS 0 <br>
              (XEN) HVM2 restore: LAPIC_REGS 1 <br>
              (XEN) HVM2 restore: PCI_IRQ 0 <br>
              (XEN) HVM2 restore: ISA_IRQ 0 <br>
              (XEN) HVM2 restore: PCI_LINK 0 <br>
              (XEN) HVM2 restore: PIT 0 <br>
              (XEN) HVM2 restore: RTC 0 <br>
              (XEN) HVM2 restore: HPET 0 <br>
              (XEN) HVM2 restore: PMTIMER 0 <br>
              (XEN) HVM2 restore: MTRR 0 <br>
              (XEN) HVM2 restore: MTRR 1 <br>
              (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0 <br>
              (XEN) HVM2 restore: VIRIDIAN_VCPU 0 <br>
              (XEN) HVM2 restore: VIRIDIAN_VCPU 1 <br>
              (XEN) HVM2 restore: VMCE_VCPU 0 <br>
              (XEN) HVM2 restore: VMCE_VCPU 1 <br>
              (XEN) HVM2 restore: TSC_ADJUST 0 <br>
              (XEN) HVM2 restore: TSC_ADJUST 1 <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
              <br>
              (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
              <br>
              (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant
              table from (4) to (32) frames. <br>
              (XEN) irq.c:380: Dom2 callback via changed to GSI 24 <br>
              <br>
              Tested on latest staging (commit
              7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice
              patches: <br>
              <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
                href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a>
              <br>
              <br>
              If you need more informations or tests tell me and I'll
              post them. <br>
              Thanks for any reply and sorry for my bad english. <br>
            </blockquote>
            <br>
            I did another tests updating to latest git staging (commit
            3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore
            problem of "only" 2-3 minutes but now when it appears to
            restart (after 2-3 minutes) windows domUs undefinitely hangs
            instead. <br>
            No further details in xen and domU's logs. <br>
            <br>
            If you need more tests/details tell me and I'll do them. <br>
            <br>
            Thanks for any reply. <br>
          </blockquote>
          <br>
          I did a new test with xen build based on tag 4.5.0-rc2 and on
          xl dmesg show these errors:<br>
          <blockquote type=3D"cite"><b>(XEN) hvm.c:6119:d5v0 Bad HVM op
              23.</b></blockquote>
          Before and after save/restore, with stdvga instead not show
          them.<br>
        </blockquote>
        <br>
        Sorry, I found that was introduced by new winpv drivers update
        instead and I solved applying this patch:<br>
        x86/hvm: Add per-vcpu evtchn upcalls v3 <a
          moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html">http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html</a><br>
        About save/restore problem with qxl I still not found a solution
        or at least the exact cause :(<br>
      </blockquote>
      <br>
      I tried a strace on qemu process when windows (in domU) is in
      temp. freeze and still does many operations (seems similar), I
      post below a small part if can be useful.<br>
      I noted for example some of these lines:<br>
      read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
      temporarily unavailable)<br>
      Is it normal=3F<br>
      <br>
      ...<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 4197512}, NULL, 8)
      =3D 2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0,
      4193071})<br>
      read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      read(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
      write(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0<br>
      gettimeofday({1416480295, 28658}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0<br>
      gettimeofday({1416480295, 28811}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
      ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
      <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
        temporarily unavailable)</b><br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
      0x7f4a3b435000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
      0x7f4a3b434000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
      0x7f4a3b433000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
      0x7f4a3b432000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
      0x7f4a3b2db000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
      0x7f4a3b2da000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
      0x7f4a3b2d9000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
      0x7f4a3b2d8000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
      0x7f4a3b2d7000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
      0x7f4a3b2d6000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
      0x7f4a3b2d5000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
      0x7f4a3b2d4000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
      0x7f4a3b2d3000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
      0x7f4a3b2d2000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
      0x7f4a3b2d1000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
      0x7f4a3b2d0000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
      0x7f4a3b2cf000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
      0x7f4a3b2ce000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
      0x7f4a3b2cd000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D
      0x7f4a3b2cc000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D
      0x7f4a3b2cb000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D
      0x7f4a3b2ca000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D
      0x7f4a3b2c9000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D
      0x7f4a3b2c8000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D
      0x7f4a3b2c7000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D
      0x7f4a3b2c6000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D
      0x7f4a3b2c5000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D
      0x7f4a3b2c4000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D
      0x7f4a3b2c3000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D
      0x7f4a3b2c2000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D
      0x7f4a3b2c1000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      read(6, "\1\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0<br>
      gettimeofday({1416480295, 35292}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0<br>
      gettimeofday({1416480295, 35746}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0<br>
      gettimeofday({1416480295, 35898}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 13233688}, NULL,
      8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left
      {0, 13227138})<br>
      read(20,
      "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"...,

      69632) =3D 101<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0<br>
      gettimeofday({1416480295, 36400}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0<br>
      gettimeofday({1416480295, 36550}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 12581076}, NULL,
      8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left
      {0, 12576281})<br>
      read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      read(20,
      "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"...,

      69632) =3D 101<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0<br>
      gettimeofday({1416480295, 37123}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0<br>
      gettimeofday({1416480295, 37273}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 11857546}, NULL,
      8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 9477611})<br>
      <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
        temporarily unavailable)</b><br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      read(6, "\5\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0<br>
      gettimeofday({1416480295, 40643}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0<br>
      gettimeofday({1416480295, 40946}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0<br>
      gettimeofday({1416480295, 41097}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
      ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d0000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2cf000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2ce000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2cd000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2cc000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2cb000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2ca000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0<br>
      gettimeofday({1416480295, 48329}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0<br>
      gettimeofday({1416480295, 48632}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0<br>
      gettimeofday({1416480295, 48783}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
      ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
      read(8, "\4\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2c1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
      0x7f4a3b435000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
      0x7f4a3b434000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
      0x7f4a3b433000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
      0x7f4a3b432000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
      0x7f4a3b2db000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
      0x7f4a3b2da000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
      0x7f4a3b2d9000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
      0x7f4a3b2d8000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0<br>
      gettimeofday({1416480295, 52051}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0<br>
      gettimeofday({1416480295, 52426}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0<br>
      gettimeofday({1416480295, 52576}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
      ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
      read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
      0x7f4a3b2d7000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
      0x7f4a3b2d6000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
      0x7f4a3b2d5000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
      0x7f4a3b2d4000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
      0x7f4a3b2d3000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
      0x7f4a3b2d2000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
      0x7f4a3b2d1000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
      0x7f4a3b2d0000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
      0x7f4a3b2cf000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
      0x7f4a3b2ce000<br>
      ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
      mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
      0x7f4a3b2cd000<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0<br>
      futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0<br>
      gettimeofday({1416480295, 55341}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0<br>
      gettimeofday({1416480295, 55725}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0<br>
      gettimeofday({1416480295, 55876}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
      ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
      read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
      munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
      ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
      read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0<br>
      gettimeofday({1416480295, 58810}, NULL) =3D 0<br>
      write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0<br>
      gettimeofday({1416480295, 59114}, NULL) =3D 0<br>
      clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0<br>
      gettimeofday({1416480295, 59265}, NULL) =3D 0<br>
      ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
      events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
      events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
      ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
      ...<br>
      <br>
      Strace of domU's qemu process during freeze can be useful=3F I must
      do a more specific tests=3F<br>
      If you need more informations/tests tell me and I'll post them.<br>
    </blockquote>
    <br>
    <span>xen save/restore seems don't save hvm domUs vga's videoram but
      kvm/qemu save yes, is it correct=3F<br>
      can be the cause of problem and/or other problem=3F<br>
    </span><br>
    <blockquote cite=3D"mid:546DCEB4.5000205@m2r.biz" type=3D"cite"> <br>
      Thanks for any reply and sorry for my bad english.<br>
      <br>
      <br>
      <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite"> <br>
        <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite"> <br>
          Below I posted full xl dmesg of domU, if you need more
          informations/tests tell me and I'll post them.<br>
          <br>
          <br>
          <blockquote type=3D"cite">(d4) HVM Loader<br>
            (d4) Detected Xen v4.5.0-rc<br>
            (d4) Xenbus rings @0xfeffc000, event channel 1<br>
            (d4) System requested SeaBIOS<br>
            (d4) CPU speed is 2660 MHz<br>
            (d4) Relocating guest memory for lowmem MMIO space disabled<br>
            (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -&gt; 5<br>
            (d4) PCI-ISA link 0 routed to IRQ5<br>
            (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -&gt; 10<br>
            (d4) PCI-ISA link 1 routed to IRQ10<br>
            (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -&gt; 11<br>
            (d4) PCI-ISA link 2 routed to IRQ11<br>
            (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -&gt; 5<br>
            (d4) PCI-ISA link 3 routed to IRQ5<br>
            (d4) pci dev 01:3 INTA-&gt;IRQ10<br>
            (d4) pci dev 02:0 INTA-&gt;IRQ11<br>
            (d4) pci dev 03:0 INTA-&gt;IRQ5<br>
            (d4) pci dev 04:0 INTA-&gt;IRQ5<br>
            (d4) pci dev 05:0 INTA-&gt;IRQ10<br>
            (d4) pci dev 06:0 INTA-&gt;IRQ11<br>
            (d4) pci dev 1d:0 INTA-&gt;IRQ10<br>
            (d4) pci dev 1d:1 INTB-&gt;IRQ11<br>
            (d4) pci dev 1d:2 INTC-&gt;IRQ5<br>
            (d4) pci dev 1d:7 INTD-&gt;IRQ5<br>
            (d4) No RAM in high memory; setting high_mem resource base
            to 100000000<br>
            (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000<br>
            (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000<br>
            (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008<br>
            (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000<br>
            (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000<br>
            (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000<br>
            (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000<br>
            (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000<br>
            (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000<br>
            (d4) pci dev 02:0 bar 10 size 000000100: 00000c001<br>
            (d4) pci dev 06:0 bar 10 size 000000100: 00000c101<br>
            (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000<br>
            (d4) pci dev 04:0 bar 10 size 000000020: 00000c201<br>
            (d4) pci dev 05:0 bar 1c size 000000020: 00000c221<br>
            (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241<br>
            (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261<br>
            (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281<br>
            (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1<br>
            (d4) Multiprocessor initialisation:<br>
            (d4)=A0 - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs
            [1/8] ... done.<br>
            (d4)=A0 - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs
            [1/8] ... done.<br>
            (d4) Testing HVM environment:<br>
            (d4)=A0 - REP INSB across page boundaries ... passed<br>
            (d4)=A0 - GS base MSRs and SWAPGS ... passed<br>
            (d4) Passed 2 of 2 tests<br>
            (d4) Writing SMBIOS tables ...<br>
            (d4) Loading SeaBIOS ...<br>
            (d4) Creating MP tables ...<br>
            (d4) Loading ACPI ...<br>
            (d4) S3 disabled<br>
            (d4) S4 disabled<br>
            (d4) vm86 TSS at fc00a100<br>
            (d4) BIOS map:<br>
            (d4)=A0 10000-100d3: Scratch space<br>
            (d4)=A0 c0000-fffff: Main BIOS<br>
            (d4) E820 table:<br>
            (d4)=A0 [00]: 00000000:00000000 - 00000000:000a0000: RAM<br>
            (d4)=A0 HOLE: 00000000:000a0000 - 00000000:000c0000<br>
            (d4)=A0 [01]: 00000000:000c0000 - 00000000:00100000: RESERVED<br>
            (d4)=A0 [02]: 00000000:00100000 - 00000000:78000000: RAM<br>
            (d4)=A0 HOLE: 00000000:78000000 - 00000000:fc000000<br>
            (d4)=A0 [03]: 00000000:fc000000 - 00000001:00000000: RESERVED<br>
            (d4) Invoking SeaBIOS ...<br>
            (d4) SeaBIOS (version
            debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
            (d4) <br>
            (d4) Found Xen hypervisor signature at 40000100<br>
            (d4) Running on QEMU (i440fx)<br>
            (d4) xen: copy e820...<br>
            (d4) Relocating init from 0x000df619 to 0x77fae600 (size
            71995)<br>
            (d4) CPU Mhz=3D2661<br>
            (d4) Found 13 PCI devices (max PCI bus is 00)<br>
            (d4) Allocated Xen hypercall page at 77fff000<br>
            (d4) Detected Xen v4.5.0-rc<br>
            (d4) xen: copy BIOS tables...<br>
            (d4) Copying SMBIOS entry point from 0x00010010 to
            0x000f0f40<br>
            (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40<br>
            (d4) Copying PIR from 0x00010030 to 0x000f0dc0<br>
            (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90<br>
            (d4) Using pmtimer, ioport 0xb008<br>
            (d4) Scan for VGA option rom<br>
            (d4) Running option rom at c000:0003<br>
            (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes<br>
            (d4) pmm call arg1=3D0<br>
            (d4) Turning on vga text mode console<br>
            (d4) SeaBIOS (version
            debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
            (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838<br>
            (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)<br>
            (d4) Found 0 lpt ports<br>
            (d4) Found 0 serial ports<br>
            (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)<br>
            (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)<br>
            (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)<br>
            (d4) Searching bootorder for:
            /pci@i0cf8/*@1,1/drive@0/disk@0<br>
            (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]<br>
            (d4) Searching bootorder for:
            /pci@i0cf8/*@1,1/drive@0/disk@1<br>
            (d4) UHCI init on dev 00:1d.0 (io=3Dc240)<br>
            (d4) UHCI init on dev 00:1d.1 (io=3Dc260)<br>
            (d4) UHCI init on dev 00:1d.2 (io=3Dc280)<br>
            (d4) PS2 keyboard initialized<br>
            (d4) All threads complete.<br>
            (d4) Scan for option roms<br>
            (d4) Running option rom at c980:0003<br>
            (d4) pmm call arg1=3D1<br>
            (d4) pmm call arg1=3D0<br>
            (d4) pmm call arg1=3D1<br>
            (d4) pmm call arg1=3D0<br>
            (d4) Searching bootorder for: /pci@i0cf8/*@6<br>
            (d4) <br>
            (d4) Press F12 for boot menu.<br>
            (d4) <br>
            (d4) Searching bootorder for: HALT<br>
            (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba
            LCHS=3D1024/255/63 s=3D102400000<br>
            (d4) <br>
            (d4) Space available for UMB: ca800-ee800, f0000-f0ce0<br>
            (d4) Returned 258048 bytes of ZoneHigh<br>
            (d4) e820 map has 6 items:<br>
            (d4)=A0=A0 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM<br>
            (d4)=A0=A0 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED<br>
            (d4)=A0=A0 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED<br>
            (d4)=A0=A0 3: 0000000000100000 - 0000000077fff000 =3D 1 RAM<br>
            (d4)=A0=A0 4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED<br>
            (d4)=A0=A0 5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED<br>
            (d4) enter handle_19:<br>
            (d4)=A0=A0 NULL<br>
            (d4) Booting from DVD/CD...<br>
            (d4) Device reports MEDIUM NOT PRESENT<br>
            (d4) scsi_is_ready returned -1<br>
            (d4) Boot failed: Could not read from CDROM (code 0003)<br>
            (d4) enter handle_18:<br>
            (d4)=A0=A0 NULL<br>
            (d4) Booting from Hard Disk...<br>
            (d4) Booting from 0000:7c00<br>
            (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6
            minor: 1 sp: 1 build: 1db1<br>
            (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff<br>
            (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe<br>
            (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd<br>
            (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -&gt; 0<br>
            (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -&gt; 0<br>
            (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -&gt; 0<br>
            (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -&gt; 0<br>
            <b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><b><br>
            </b><b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><br>
            (XEN) irq.c:380: Dom4 callback via changed to GSI 24<br>
            (XEN) HVM4 save: CPU<br>
            (XEN) HVM4 save: PIC<br>
            (XEN) HVM4 save: IOAPIC<br>
            (XEN) HVM4 save: LAPIC<br>
            (XEN) HVM4 save: LAPIC_REGS<br>
            (XEN) HVM4 save: PCI_IRQ<br>
            (XEN) HVM4 save: ISA_IRQ<br>
            (XEN) HVM4 save: PCI_LINK<br>
            (XEN) HVM4 save: PIT<br>
            (XEN) HVM4 save: RTC<br>
            (XEN) HVM4 save: HPET<br>
            (XEN) HVM4 save: PMTIMER<br>
            (XEN) HVM4 save: MTRR<br>
            (XEN) HVM4 save: VIRIDIAN_DOMAIN<br>
            (XEN) HVM4 save: CPU_XSAVE<br>
            (XEN) HVM4 save: VIRIDIAN_VCPU<br>
            (XEN) HVM4 save: VMCE_VCPU<br>
            (XEN) HVM4 save: TSC_ADJUST<br>
            (XEN) HVM5 restore: CPU 0<br>
            (XEN) HVM5 restore: CPU 1<br>
            (XEN) HVM5 restore: PIC 0<br>
            (XEN) HVM5 restore: PIC 1<br>
            (XEN) HVM5 restore: IOAPIC 0<br>
            (XEN) HVM5 restore: LAPIC 0<br>
            (XEN) HVM5 restore: LAPIC 1<br>
            (XEN) HVM5 restore: LAPIC_REGS 0<br>
            (XEN) HVM5 restore: LAPIC_REGS 1<br>
            (XEN) HVM5 restore: PCI_IRQ 0<br>
            (XEN) HVM5 restore: ISA_IRQ 0<br>
            (XEN) HVM5 restore: PCI_LINK 0<br>
            (XEN) HVM5 restore: PIT 0<br>
            (XEN) HVM5 restore: RTC 0<br>
            (XEN) HVM5 restore: HPET 0<br>
            (XEN) HVM5 restore: PMTIMER 0<br>
            (XEN) HVM5 restore: MTRR 0<br>
            (XEN) HVM5 restore: MTRR 1<br>
            (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0<br>
            (XEN) HVM5 restore: VIRIDIAN_VCPU 0<br>
            (XEN) HVM5 restore: VIRIDIAN_VCPU 1<br>
            (XEN) HVM5 restore: VMCE_VCPU 0<br>
            (XEN) HVM5 restore: VMCE_VCPU 1<br>
            (XEN) HVM5 restore: TSC_ADJUST 0<br>
            (XEN) HVM5 restore: TSC_ADJUST 1<br>
            (XEN) irq.c:380: Dom5 callback via changed to None<br>
            <b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
            </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
            </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
            </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><br>
            (XEN) irq.c:380: Dom5 callback via changed to GSI 24</blockquote>
          <br>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------010201070203040206060506--


--===============5671796681831524772==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5671796681831524772==--


From xen-devel-bounces@lists.xen.org Fri Nov 21 11:08:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11: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 1Xrm4i-0002br-CL; Fri, 21 Nov 2014 11:08:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xrm4h-0002bk-SF
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:08:27 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	00/93-02699-B2D1F645; Fri, 21 Nov 2014 11:08:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416568104!13962684!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28993 invoked from network); 21 Nov 2014 11:08:26 -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;
	21 Nov 2014 11:08:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195190576"
Message-ID: <546F1CF8.8010900@citrix.com>
Date: Fri, 21 Nov 2014 11:07:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546E32BB.8090909@citrix.com>	
	<1416562990.26869.10.camel@citrix.com>
	<546F12F2.3020809@citrix.com>
	<1416566814.26869.14.camel@citrix.com>
In-Reply-To: <1416566814.26869.14.camel@citrix.com>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 21/11/14 10:46, Ian Campbell wrote:
> On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
>> On 21/11/14 09:43, Ian Campbell wrote:
>>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
>>> here, where does that fit in?
>>>
>> It is referenced several times, although not by its exact name.
> Hence no explicit mention.
>
> It's ambiguous when you refer to "higher level frames" (which I presume
> are the reference you are referring to) because some kernels (perhaps
> only historic ones, I've not been keeping up) keep both an N-level tree
> of their own internally and the toolstack visible frame_list_list
> (sometimes partially overlapping at some level). Is every reference to
> "higher level frames" actually intended to be a reference to
> pfn_to_mfn_frame_list_list or not?

"higher level frames" would be the toolstack-abi-defined first and
second level lists.  The logdirty infrastructure can be used to detect
writes to these frames, and therefore detect structural changes to the p2m.

I would like to hope that every kernel out there keeps this information
correctly up-to-date and updates it in an appropriate order...

>
> It seems like sometimes you are talking at times about tracking the
> kernel's internal structure and not just pfn_to_mfn_frame_list_list and
> I'm not sure why that would be.

I apologise for giving this impression.  It was not intended.

> I'm also not sure why
> pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
> AFAIK the guest is still obliged to keep that up to date regardless of
> the scheme it uses internally for accessing the p2m.

There are two reasons for the virtual linear p2m, the primary one being
to break the hard 512GB limit given the old 3-level table.

A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
the virtual linear method, a PV guest explicitly sets
pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
adjacent information.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:08:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11: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 1Xrm4i-0002br-CL; Fri, 21 Nov 2014 11:08:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xrm4h-0002bk-SF
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:08:27 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	00/93-02699-B2D1F645; Fri, 21 Nov 2014 11:08:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416568104!13962684!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28993 invoked from network); 21 Nov 2014 11:08:26 -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;
	21 Nov 2014 11:08:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195190576"
Message-ID: <546F1CF8.8010900@citrix.com>
Date: Fri, 21 Nov 2014 11:07:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546E32BB.8090909@citrix.com>	
	<1416562990.26869.10.camel@citrix.com>
	<546F12F2.3020809@citrix.com>
	<1416566814.26869.14.camel@citrix.com>
In-Reply-To: <1416566814.26869.14.camel@citrix.com>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 21/11/14 10:46, Ian Campbell wrote:
> On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
>> On 21/11/14 09:43, Ian Campbell wrote:
>>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
>>> here, where does that fit in?
>>>
>> It is referenced several times, although not by its exact name.
> Hence no explicit mention.
>
> It's ambiguous when you refer to "higher level frames" (which I presume
> are the reference you are referring to) because some kernels (perhaps
> only historic ones, I've not been keeping up) keep both an N-level tree
> of their own internally and the toolstack visible frame_list_list
> (sometimes partially overlapping at some level). Is every reference to
> "higher level frames" actually intended to be a reference to
> pfn_to_mfn_frame_list_list or not?

"higher level frames" would be the toolstack-abi-defined first and
second level lists.  The logdirty infrastructure can be used to detect
writes to these frames, and therefore detect structural changes to the p2m.

I would like to hope that every kernel out there keeps this information
correctly up-to-date and updates it in an appropriate order...

>
> It seems like sometimes you are talking at times about tracking the
> kernel's internal structure and not just pfn_to_mfn_frame_list_list and
> I'm not sure why that would be.

I apologise for giving this impression.  It was not intended.

> I'm also not sure why
> pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
> AFAIK the guest is still obliged to keep that up to date regardless of
> the scheme it uses internally for accessing the p2m.

There are two reasons for the virtual linear p2m, the primary one being
to break the hard 512GB limit given the old 3-level table.

A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
the virtual linear method, a PV guest explicitly sets
pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
adjacent information.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:12:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11: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 1Xrm8U-0002qm-18; Fri, 21 Nov 2014 11:12:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xrm8S-0002qg-EL
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:12:20 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	2D/F7-28296-31E1F645; Fri, 21 Nov 2014 11:12:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416568337!10480519!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24830 invoked from network); 21 Nov 2014 11:12:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:12:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193658646"
Message-ID: <1416568333.26869.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Gedalya <gedalya@gedalya.net>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 21 Nov 2014 11:12:13 +0000
In-Reply-To: <1416567797.26869.18.camel@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>
	<1416567797.26869.18.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, 767295@bugs.debian.org, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote:
> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about
> various dynamic thresholds for growing and shrinking the heap. My guess
> is that we are bouncing up and down over some threshold with every other
> reboot.

IOW I'm not overly concerned with this apparent bi-modality, so long as
the amount isn't increasing in the long term...

I think the original patch should go in.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:12:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11: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 1Xrm8U-0002qm-18; Fri, 21 Nov 2014 11:12:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xrm8S-0002qg-EL
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:12:20 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	2D/F7-28296-31E1F645; Fri, 21 Nov 2014 11:12:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416568337!10480519!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24830 invoked from network); 21 Nov 2014 11:12:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:12:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193658646"
Message-ID: <1416568333.26869.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Gedalya <gedalya@gedalya.net>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 21 Nov 2014 11:12:13 +0000
In-Reply-To: <1416567797.26869.18.camel@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>
	<1416567797.26869.18.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, 767295@bugs.debian.org, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote:
> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about
> various dynamic thresholds for growing and shrinking the heap. My guess
> is that we are bouncing up and down over some threshold with every other
> reboot.

IOW I'm not overly concerned with this apparent bi-modality, so long as
the amount isn't increasing in the long term...

I think the original patch should go in.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:12:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:12:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrm8w-0002tD-Dl; Fri, 21 Nov 2014 11:12:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrm8u-0002t4-OK
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:12:48 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	9E/E8-02702-F2E1F645; Fri, 21 Nov 2014 11:12:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416568365!9336489!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14345 invoked from network); 21 Nov 2014 11:12:46 -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 Nov 2014 11:12:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195192543"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 06:12:44 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xrm8q-0000tY-Bs;
	Fri, 21 Nov 2014 11:12:44 +0000
Date: Fri, 21 Nov 2014 11:12:44 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141121111244.GA18698@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
> When parsing bitmap objects JSON parser will create libxl_bitmap
> map of the smallest size needed.
> 
> This can cause problems when saved image file specifies CPU affinity.
> For example, if 'vcpu_hard_affinity' in the saved image has only the
> first CPU specified, just a single byte will be allocated and
> libxl_bitmap->size will be set to 1.
> 
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> since the destination bitmap is created for maximum number of CPUs.
> 
> We could allocate that bitmap of the same size as the source, however,
> it is later passed to xc_vcpu_setaffinity() which expects it to be
> sized to the max number of CPUs
> 
> Instead, we should allow copying the (smaller) bitmap read by the parser
> and keep the rest of bytes in the destination map unmodified (zero in
> this case)
> 

What about copying large bitmap to a smaller one? Say, you migrate to
a host whose number of cpus is smaller than the size of the source
bitmap. Is this a valid use case?

Should we have a "best effort" copy function? That is,

  size = min(source_size, destination_size)
  copy(source, destination, size)

In any case I think this is a regression and should be fixed for 4.5.

Wei.

> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  tools/libxl/libxl.c       |    4 ++--
>  tools/libxl/libxl_utils.c |    7 +++++++
>  tools/libxl/libxl_utils.h |    2 ++
>  3 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..84fd2ca 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5319,7 +5319,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>          if (rc)
>              goto out;
>  
> -        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
> +        libxl_bitmap_copy_partial(ctx, &hard, cpumap_hard);
>          flags = XEN_VCPUAFFINITY_HARD;
>      }
>      if (cpumap_soft) {
> @@ -5327,7 +5327,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>          if (rc)
>              goto out;
>  
> -        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
> +        libxl_bitmap_copy_partial(ctx, &soft, cpumap_soft);
>          flags |= XEN_VCPUAFFINITY_SOFT;
>      }
>  
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 58df4f3..2a08bef 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>      memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>  }
>  
> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
> +                               const libxl_bitmap *sptr)
> +{
> +    assert(dptr->size >= sptr->size);
> +    memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
> +}
> +
>  void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
>                               libxl_bitmap *dptr,
>                               const libxl_bitmap *sptr)
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> index 117b229..d4d0a51 100644
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -80,6 +80,8 @@ void libxl_bitmap_copy_alloc(libxl_ctx *ctx, libxl_bitmap *dptr,
>                               const libxl_bitmap *sptr);
>  void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>                         const libxl_bitmap *sptr);
> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
> +                               const libxl_bitmap *sptr);
>  int libxl_bitmap_is_full(const libxl_bitmap *bitmap);
>  int libxl_bitmap_is_empty(const libxl_bitmap *bitmap);
>  int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
> -- 
> 1.7.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:12:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:12:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrm8w-0002tD-Dl; Fri, 21 Nov 2014 11:12:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrm8u-0002t4-OK
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:12:48 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	9E/E8-02702-F2E1F645; Fri, 21 Nov 2014 11:12:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416568365!9336489!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14345 invoked from network); 21 Nov 2014 11:12:46 -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 Nov 2014 11:12:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195192543"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 06:12:44 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xrm8q-0000tY-Bs;
	Fri, 21 Nov 2014 11:12:44 +0000
Date: Fri, 21 Nov 2014 11:12:44 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141121111244.GA18698@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
> When parsing bitmap objects JSON parser will create libxl_bitmap
> map of the smallest size needed.
> 
> This can cause problems when saved image file specifies CPU affinity.
> For example, if 'vcpu_hard_affinity' in the saved image has only the
> first CPU specified, just a single byte will be allocated and
> libxl_bitmap->size will be set to 1.
> 
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> since the destination bitmap is created for maximum number of CPUs.
> 
> We could allocate that bitmap of the same size as the source, however,
> it is later passed to xc_vcpu_setaffinity() which expects it to be
> sized to the max number of CPUs
> 
> Instead, we should allow copying the (smaller) bitmap read by the parser
> and keep the rest of bytes in the destination map unmodified (zero in
> this case)
> 

What about copying large bitmap to a smaller one? Say, you migrate to
a host whose number of cpus is smaller than the size of the source
bitmap. Is this a valid use case?

Should we have a "best effort" copy function? That is,

  size = min(source_size, destination_size)
  copy(source, destination, size)

In any case I think this is a regression and should be fixed for 4.5.

Wei.

> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  tools/libxl/libxl.c       |    4 ++--
>  tools/libxl/libxl_utils.c |    7 +++++++
>  tools/libxl/libxl_utils.h |    2 ++
>  3 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..84fd2ca 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5319,7 +5319,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>          if (rc)
>              goto out;
>  
> -        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
> +        libxl_bitmap_copy_partial(ctx, &hard, cpumap_hard);
>          flags = XEN_VCPUAFFINITY_HARD;
>      }
>      if (cpumap_soft) {
> @@ -5327,7 +5327,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>          if (rc)
>              goto out;
>  
> -        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
> +        libxl_bitmap_copy_partial(ctx, &soft, cpumap_soft);
>          flags |= XEN_VCPUAFFINITY_SOFT;
>      }
>  
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 58df4f3..2a08bef 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>      memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>  }
>  
> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
> +                               const libxl_bitmap *sptr)
> +{
> +    assert(dptr->size >= sptr->size);
> +    memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
> +}
> +
>  void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
>                               libxl_bitmap *dptr,
>                               const libxl_bitmap *sptr)
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> index 117b229..d4d0a51 100644
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -80,6 +80,8 @@ void libxl_bitmap_copy_alloc(libxl_ctx *ctx, libxl_bitmap *dptr,
>                               const libxl_bitmap *sptr);
>  void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>                         const libxl_bitmap *sptr);
> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
> +                               const libxl_bitmap *sptr);
>  int libxl_bitmap_is_full(const libxl_bitmap *bitmap);
>  int libxl_bitmap_is_empty(const libxl_bitmap *bitmap);
>  int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
> -- 
> 1.7.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:15:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:15:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmBD-00033g-Vu; Fri, 21 Nov 2014 11:15:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrmBC-00033b-3q
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:15:10 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	6A/90-09284-DBE1F645; Fri, 21 Nov 2014 11:15:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416568506!12862736!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18509 invoked from network); 21 Nov 2014 11:15:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:15:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195193006"
Message-ID: <1416568502.26869.24.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 21 Nov 2014 11:15:02 +0000
In-Reply-To: <546F1CF8.8010900@citrix.com>
References: <546E32BB.8090909@citrix.com>
	<1416562990.26869.10.camel@citrix.com> <546F12F2.3020809@citrix.com>
	<1416566814.26869.14.camel@citrix.com> <546F1CF8.8010900@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 Fri, 2014-11-21 at 11:07 +0000, Andrew Cooper wrote:
> On 21/11/14 10:46, Ian Campbell wrote:
> > On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
> >> On 21/11/14 09:43, Ian Campbell wrote:
> >>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
> >>> here, where does that fit in?
> >>>
> >> It is referenced several times, although not by its exact name.
> > Hence no explicit mention.
> >
> > It's ambiguous when you refer to "higher level frames" (which I presume
> > are the reference you are referring to) because some kernels (perhaps
> > only historic ones, I've not been keeping up) keep both an N-level tree
> > of their own internally and the toolstack visible frame_list_list
> > (sometimes partially overlapping at some level). Is every reference to
> > "higher level frames" actually intended to be a reference to
> > pfn_to_mfn_frame_list_list or not?
> 
> "higher level frames" would be the toolstack-abi-defined first and
> second level lists.  The logdirty infrastructure can be used to detect
> writes to these frames, and therefore detect structural changes to the p2m.
> 
> I would like to hope that every kernel out there keeps this information
> correctly up-to-date and updates it in an appropriate order...
> 
> >
> > It seems like sometimes you are talking at times about tracking the
> > kernel's internal structure and not just pfn_to_mfn_frame_list_list and
> > I'm not sure why that would be.
> 
> I apologise for giving this impression.  It was not intended.

Great, I just wanted to be sure we were all on the same page, since
scrobbling around in the kernel's internal data structures would clearly
be mad...

> 
> > I'm also not sure why
> > pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
> > AFAIK the guest is still obliged to keep that up to date regardless of
> > the scheme it uses internally for accessing the p2m.
> 
> There are two reasons for the virtual linear p2m, the primary one being
> to break the hard 512GB limit given the old 3-level table.
> 
> A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
> it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
> the virtual linear method, a PV guest explicitly sets
> pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
> adjacent information.

Oh, I hadn't realised this linear p2m stuff involved a guest ABI change.
Have I somehow completely missed the xen.git side of these patches? I
thought I'd only seen linux.git ones (and hence wasn't looking very
closely). 

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:15:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:15:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmBD-00033g-Vu; Fri, 21 Nov 2014 11:15:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrmBC-00033b-3q
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:15:10 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	6A/90-09284-DBE1F645; Fri, 21 Nov 2014 11:15:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416568506!12862736!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18509 invoked from network); 21 Nov 2014 11:15:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:15:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195193006"
Message-ID: <1416568502.26869.24.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 21 Nov 2014 11:15:02 +0000
In-Reply-To: <546F1CF8.8010900@citrix.com>
References: <546E32BB.8090909@citrix.com>
	<1416562990.26869.10.camel@citrix.com> <546F12F2.3020809@citrix.com>
	<1416566814.26869.14.camel@citrix.com> <546F1CF8.8010900@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 Fri, 2014-11-21 at 11:07 +0000, Andrew Cooper wrote:
> On 21/11/14 10:46, Ian Campbell wrote:
> > On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
> >> On 21/11/14 09:43, Ian Campbell wrote:
> >>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
> >>> here, where does that fit in?
> >>>
> >> It is referenced several times, although not by its exact name.
> > Hence no explicit mention.
> >
> > It's ambiguous when you refer to "higher level frames" (which I presume
> > are the reference you are referring to) because some kernels (perhaps
> > only historic ones, I've not been keeping up) keep both an N-level tree
> > of their own internally and the toolstack visible frame_list_list
> > (sometimes partially overlapping at some level). Is every reference to
> > "higher level frames" actually intended to be a reference to
> > pfn_to_mfn_frame_list_list or not?
> 
> "higher level frames" would be the toolstack-abi-defined first and
> second level lists.  The logdirty infrastructure can be used to detect
> writes to these frames, and therefore detect structural changes to the p2m.
> 
> I would like to hope that every kernel out there keeps this information
> correctly up-to-date and updates it in an appropriate order...
> 
> >
> > It seems like sometimes you are talking at times about tracking the
> > kernel's internal structure and not just pfn_to_mfn_frame_list_list and
> > I'm not sure why that would be.
> 
> I apologise for giving this impression.  It was not intended.

Great, I just wanted to be sure we were all on the same page, since
scrobbling around in the kernel's internal data structures would clearly
be mad...

> 
> > I'm also not sure why
> > pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
> > AFAIK the guest is still obliged to keep that up to date regardless of
> > the scheme it uses internally for accessing the p2m.
> 
> There are two reasons for the virtual linear p2m, the primary one being
> to break the hard 512GB limit given the old 3-level table.
> 
> A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
> it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
> the virtual linear method, a PV guest explicitly sets
> pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
> adjacent information.

Oh, I hadn't realised this linear p2m stuff involved a guest ABI change.
Have I somehow completely missed the xen.git side of these patches? I
thought I'd only seen linux.git ones (and hence wasn't looking very
closely). 

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:20:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmGT-0003FZ-Oz; Fri, 21 Nov 2014 11:20:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrmGS-0003FU-Ci
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:20:36 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A9/9B-26652-3002F645; Fri, 21 Nov 2014 11:20:35 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416568834!12628206!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21272 invoked from network); 21 Nov 2014 11:20:35 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 11:20:35 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8A8BEAD00;
	Fri, 21 Nov 2014 11:20:33 +0000 (UTC)
Message-ID: <546F2000.9020802@suse.com>
Date: Fri, 21 Nov 2014 12:20:32 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>
References: <546E32BB.8090909@citrix.com>		
	<1416562990.26869.10.camel@citrix.com>
	<546F12F2.3020809@citrix.com>	
	<1416566814.26869.14.camel@citrix.com>
	<546F1CF8.8010900@citrix.com>
	<1416568502.26869.24.camel@citrix.com>
In-Reply-To: <1416568502.26869.24.camel@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 12:15 PM, Ian Campbell wrote:
> On Fri, 2014-11-21 at 11:07 +0000, Andrew Cooper wrote:
>> On 21/11/14 10:46, Ian Campbell wrote:
>>> On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
>>>> On 21/11/14 09:43, Ian Campbell wrote:
>>>>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
>>>>> here, where does that fit in?
>>>>>
>>>> It is referenced several times, although not by its exact name.
>>> Hence no explicit mention.
>>>
>>> It's ambiguous when you refer to "higher level frames" (which I presume
>>> are the reference you are referring to) because some kernels (perhaps
>>> only historic ones, I've not been keeping up) keep both an N-level tree
>>> of their own internally and the toolstack visible frame_list_list
>>> (sometimes partially overlapping at some level). Is every reference to
>>> "higher level frames" actually intended to be a reference to
>>> pfn_to_mfn_frame_list_list or not?
>>
>> "higher level frames" would be the toolstack-abi-defined first and
>> second level lists.  The logdirty infrastructure can be used to detect
>> writes to these frames, and therefore detect structural changes to the p2m.
>>
>> I would like to hope that every kernel out there keeps this information
>> correctly up-to-date and updates it in an appropriate order...
>>
>>>
>>> It seems like sometimes you are talking at times about tracking the
>>> kernel's internal structure and not just pfn_to_mfn_frame_list_list and
>>> I'm not sure why that would be.
>>
>> I apologise for giving this impression.  It was not intended.
>
> Great, I just wanted to be sure we were all on the same page, since
> scrobbling around in the kernel's internal data structures would clearly
> be mad...
>
>>
>>> I'm also not sure why
>>> pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
>>> AFAIK the guest is still obliged to keep that up to date regardless of
>>> the scheme it uses internally for accessing the p2m.
>>
>> There are two reasons for the virtual linear p2m, the primary one being
>> to break the hard 512GB limit given the old 3-level table.
>>
>> A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
>> it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
>> the virtual linear method, a PV guest explicitly sets
>> pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
>> adjacent information.
>
> Oh, I hadn't realised this linear p2m stuff involved a guest ABI change.
> Have I somehow completely missed the xen.git side of these patches? I
> thought I'd only seen linux.git ones (and hence wasn't looking very
> closely).

V1 of the patches suggesting such a change have been posted a week ago:

http://lists.xen.org/archives/html/xen-devel/2014-11/msg01276.html

The linear p2m stuff is a prerequisite for this change, not the reason
for it.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:20:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmGT-0003FZ-Oz; Fri, 21 Nov 2014 11:20:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrmGS-0003FU-Ci
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:20:36 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A9/9B-26652-3002F645; Fri, 21 Nov 2014 11:20:35 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416568834!12628206!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21272 invoked from network); 21 Nov 2014 11:20:35 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 11:20:35 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8A8BEAD00;
	Fri, 21 Nov 2014 11:20:33 +0000 (UTC)
Message-ID: <546F2000.9020802@suse.com>
Date: Fri, 21 Nov 2014 12:20:32 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>
References: <546E32BB.8090909@citrix.com>		
	<1416562990.26869.10.camel@citrix.com>
	<546F12F2.3020809@citrix.com>	
	<1416566814.26869.14.camel@citrix.com>
	<546F1CF8.8010900@citrix.com>
	<1416568502.26869.24.camel@citrix.com>
In-Reply-To: <1416568502.26869.24.camel@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 12:15 PM, Ian Campbell wrote:
> On Fri, 2014-11-21 at 11:07 +0000, Andrew Cooper wrote:
>> On 21/11/14 10:46, Ian Campbell wrote:
>>> On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
>>>> On 21/11/14 09:43, Ian Campbell wrote:
>>>>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
>>>>> here, where does that fit in?
>>>>>
>>>> It is referenced several times, although not by its exact name.
>>> Hence no explicit mention.
>>>
>>> It's ambiguous when you refer to "higher level frames" (which I presume
>>> are the reference you are referring to) because some kernels (perhaps
>>> only historic ones, I've not been keeping up) keep both an N-level tree
>>> of their own internally and the toolstack visible frame_list_list
>>> (sometimes partially overlapping at some level). Is every reference to
>>> "higher level frames" actually intended to be a reference to
>>> pfn_to_mfn_frame_list_list or not?
>>
>> "higher level frames" would be the toolstack-abi-defined first and
>> second level lists.  The logdirty infrastructure can be used to detect
>> writes to these frames, and therefore detect structural changes to the p2m.
>>
>> I would like to hope that every kernel out there keeps this information
>> correctly up-to-date and updates it in an appropriate order...
>>
>>>
>>> It seems like sometimes you are talking at times about tracking the
>>> kernel's internal structure and not just pfn_to_mfn_frame_list_list and
>>> I'm not sure why that would be.
>>
>> I apologise for giving this impression.  It was not intended.
>
> Great, I just wanted to be sure we were all on the same page, since
> scrobbling around in the kernel's internal data structures would clearly
> be mad...
>
>>
>>> I'm also not sure why
>>> pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
>>> AFAIK the guest is still obliged to keep that up to date regardless of
>>> the scheme it uses internally for accessing the p2m.
>>
>> There are two reasons for the virtual linear p2m, the primary one being
>> to break the hard 512GB limit given the old 3-level table.
>>
>> A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
>> it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
>> the virtual linear method, a PV guest explicitly sets
>> pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
>> adjacent information.
>
> Oh, I hadn't realised this linear p2m stuff involved a guest ABI change.
> Have I somehow completely missed the xen.git side of these patches? I
> thought I'd only seen linux.git ones (and hence wasn't looking very
> closely).

V1 of the patches suggesting such a change have been posted a week ago:

http://lists.xen.org/archives/html/xen-devel/2014-11/msg01276.html

The linear p2m stuff is a prerequisite for this change, not the reason
for it.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:24:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:24:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmK0-0003Rx-CT; Fri, 21 Nov 2014 11:24: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 1XrmJz-0003Rq-4I
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:24:15 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	1F/32-09284-ED02F645; Fri, 21 Nov 2014 11:24:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416569052!9204399!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14583 invoked from network); 21 Nov 2014 11:24:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:24:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193661772"
Message-ID: <1416569047.26869.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <jgross@suse.com>
Date: Fri, 21 Nov 2014 11:24:07 +0000
In-Reply-To: <546F2000.9020802@suse.com>
References: <546E32BB.8090909@citrix.com>
	<1416562990.26869.10.camel@citrix.com> <546F12F2.3020809@citrix.com>
	<1416566814.26869.14.camel@citrix.com> <546F1CF8.8010900@citrix.com>
	<1416568502.26869.24.camel@citrix.com> <546F2000.9020802@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Shriram
	Rajagopalan <rshriram@cs.ubc.ca>, Hongyang Yang <yanghy@cn.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 Fri, 2014-11-21 at 12:20 +0100, Juergen Gross wrote:
> On 11/21/2014 12:15 PM, Ian Campbell wrote:
> > On Fri, 2014-11-21 at 11:07 +0000, Andrew Cooper wrote:
> >> On 21/11/14 10:46, Ian Campbell wrote:
> >>> On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
> >>>> On 21/11/14 09:43, Ian Campbell wrote:
> >>>>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
> >>>>> here, where does that fit in?
> >>>>>
> >>>> It is referenced several times, although not by its exact name.
> >>> Hence no explicit mention.
> >>>
> >>> It's ambiguous when you refer to "higher level frames" (which I presume
> >>> are the reference you are referring to) because some kernels (perhaps
> >>> only historic ones, I've not been keeping up) keep both an N-level tree
> >>> of their own internally and the toolstack visible frame_list_list
> >>> (sometimes partially overlapping at some level). Is every reference to
> >>> "higher level frames" actually intended to be a reference to
> >>> pfn_to_mfn_frame_list_list or not?
> >>
> >> "higher level frames" would be the toolstack-abi-defined first and
> >> second level lists.  The logdirty infrastructure can be used to detect
> >> writes to these frames, and therefore detect structural changes to the p2m.
> >>
> >> I would like to hope that every kernel out there keeps this information
> >> correctly up-to-date and updates it in an appropriate order...
> >>
> >>>
> >>> It seems like sometimes you are talking at times about tracking the
> >>> kernel's internal structure and not just pfn_to_mfn_frame_list_list and
> >>> I'm not sure why that would be.
> >>
> >> I apologise for giving this impression.  It was not intended.
> >
> > Great, I just wanted to be sure we were all on the same page, since
> > scrobbling around in the kernel's internal data structures would clearly
> > be mad...
> >
> >>
> >>> I'm also not sure why
> >>> pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
> >>> AFAIK the guest is still obliged to keep that up to date regardless of
> >>> the scheme it uses internally for accessing the p2m.
> >>
> >> There are two reasons for the virtual linear p2m, the primary one being
> >> to break the hard 512GB limit given the old 3-level table.
> >>
> >> A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
> >> it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
> >> the virtual linear method, a PV guest explicitly sets
> >> pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
> >> adjacent information.
> >
> > Oh, I hadn't realised this linear p2m stuff involved a guest ABI change.
> > Have I somehow completely missed the xen.git side of these patches? I
> > thought I'd only seen linux.git ones (and hence wasn't looking very
> > closely).
> 
> V1 of the patches suggesting such a change have been posted a week ago:
> 
> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01276.html

Ah, thanks. I had indeed ignored that as "just another iteration of the
linux patches", oops!

> The linear p2m stuff is a prerequisite for this change, not the reason
> for it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:24:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:24:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmK0-0003Rx-CT; Fri, 21 Nov 2014 11:24: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 1XrmJz-0003Rq-4I
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:24:15 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	1F/32-09284-ED02F645; Fri, 21 Nov 2014 11:24:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416569052!9204399!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14583 invoked from network); 21 Nov 2014 11:24:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:24:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193661772"
Message-ID: <1416569047.26869.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <jgross@suse.com>
Date: Fri, 21 Nov 2014 11:24:07 +0000
In-Reply-To: <546F2000.9020802@suse.com>
References: <546E32BB.8090909@citrix.com>
	<1416562990.26869.10.camel@citrix.com> <546F12F2.3020809@citrix.com>
	<1416566814.26869.14.camel@citrix.com> <546F1CF8.8010900@citrix.com>
	<1416568502.26869.24.camel@citrix.com> <546F2000.9020802@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Shriram
	Rajagopalan <rshriram@cs.ubc.ca>, Hongyang Yang <yanghy@cn.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 Fri, 2014-11-21 at 12:20 +0100, Juergen Gross wrote:
> On 11/21/2014 12:15 PM, Ian Campbell wrote:
> > On Fri, 2014-11-21 at 11:07 +0000, Andrew Cooper wrote:
> >> On 21/11/14 10:46, Ian Campbell wrote:
> >>> On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
> >>>> On 21/11/14 09:43, Ian Campbell wrote:
> >>>>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
> >>>>> here, where does that fit in?
> >>>>>
> >>>> It is referenced several times, although not by its exact name.
> >>> Hence no explicit mention.
> >>>
> >>> It's ambiguous when you refer to "higher level frames" (which I presume
> >>> are the reference you are referring to) because some kernels (perhaps
> >>> only historic ones, I've not been keeping up) keep both an N-level tree
> >>> of their own internally and the toolstack visible frame_list_list
> >>> (sometimes partially overlapping at some level). Is every reference to
> >>> "higher level frames" actually intended to be a reference to
> >>> pfn_to_mfn_frame_list_list or not?
> >>
> >> "higher level frames" would be the toolstack-abi-defined first and
> >> second level lists.  The logdirty infrastructure can be used to detect
> >> writes to these frames, and therefore detect structural changes to the p2m.
> >>
> >> I would like to hope that every kernel out there keeps this information
> >> correctly up-to-date and updates it in an appropriate order...
> >>
> >>>
> >>> It seems like sometimes you are talking at times about tracking the
> >>> kernel's internal structure and not just pfn_to_mfn_frame_list_list and
> >>> I'm not sure why that would be.
> >>
> >> I apologise for giving this impression.  It was not intended.
> >
> > Great, I just wanted to be sure we were all on the same page, since
> > scrobbling around in the kernel's internal data structures would clearly
> > be mad...
> >
> >>
> >>> I'm also not sure why
> >>> pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
> >>> AFAIK the guest is still obliged to keep that up to date regardless of
> >>> the scheme it uses internally for accessing the p2m.
> >>
> >> There are two reasons for the virtual linear p2m, the primary one being
> >> to break the hard 512GB limit given the old 3-level table.
> >>
> >> A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
> >> it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
> >> the virtual linear method, a PV guest explicitly sets
> >> pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
> >> adjacent information.
> >
> > Oh, I hadn't realised this linear p2m stuff involved a guest ABI change.
> > Have I somehow completely missed the xen.git side of these patches? I
> > thought I'd only seen linux.git ones (and hence wasn't looking very
> > closely).
> 
> V1 of the patches suggesting such a change have been posted a week ago:
> 
> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01276.html

Ah, thanks. I had indeed ignored that as "just another iteration of the
linux patches", oops!

> The linear p2m stuff is a prerequisite for this change, not the reason
> for it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:26:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmMK-0003Yi-Tx; Fri, 21 Nov 2014 11:26:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XrmMJ-0003Yd-Kp
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:26:39 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	A7/65-02707-E612F645; Fri, 21 Nov 2014 11:26:38 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416569187!12636307!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTc5NzEgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17792 invoked from network); 21 Nov 2014 11:26:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:26:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; 
	d="asc'?scan'208";a="193662386"
Received: from [127.0.0.1] (10.80.16.66) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 06:26:26 -0500
Message-ID: <1416569185.20516.8.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Fri, 21 Nov 2014 11:26:25 +0000
In-Reply-To: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6505362266485923778=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6505362266485923778==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Sl7hztBN5p6xVS4QEL3F"

--=-Sl7hztBN5p6xVS4QEL3F
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-11-20 at 16:27 -0500, Boris Ostrovsky wrote:

> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 58df4f3..2a08bef 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap =
*dptr,
>      memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>  }
> =20
> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
> +                               const libxl_bitmap *sptr)
> +{
> +    assert(dptr->size >=3D sptr->size);
> +    memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
> +}
> +
Looking at other callers of libxl_bitmap_copy(), I think something like
this makes sense for pretty much all of them.

And even abstracting from them, and thinking to how a function like
'libxl_bitmap_copy()' this should behave, copying only the "common part"
makes sense to me.

So, should we make libxl_bitmap_copy() behave like implemented above,
rather than introducing a new function. I know this is public stable
API, but I think this is a fine behavioral change, isn't it?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Sl7hztBN5p6xVS4QEL3F
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 v2

iEYEABECAAYFAlRvIWEACgkQk4XaBE3IOsTgXgCeLdrlytQQWoLy9M8+g5v+HPDa
UrYAoKzTvsYypeHTad0BXHiylTgsLP2x
=Fdax
-----END PGP SIGNATURE-----

--=-Sl7hztBN5p6xVS4QEL3F--


--===============6505362266485923778==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6505362266485923778==--


From xen-devel-bounces@lists.xen.org Fri Nov 21 11:26:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmMK-0003Yi-Tx; Fri, 21 Nov 2014 11:26:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XrmMJ-0003Yd-Kp
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 11:26:39 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	A7/65-02707-E612F645; Fri, 21 Nov 2014 11:26:38 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416569187!12636307!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTc5NzEgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17792 invoked from network); 21 Nov 2014 11:26:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:26:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; 
	d="asc'?scan'208";a="193662386"
Received: from [127.0.0.1] (10.80.16.66) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 06:26:26 -0500
Message-ID: <1416569185.20516.8.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Fri, 21 Nov 2014 11:26:25 +0000
In-Reply-To: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6505362266485923778=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6505362266485923778==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Sl7hztBN5p6xVS4QEL3F"

--=-Sl7hztBN5p6xVS4QEL3F
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-11-20 at 16:27 -0500, Boris Ostrovsky wrote:

> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 58df4f3..2a08bef 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap =
*dptr,
>      memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>  }
> =20
> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
> +                               const libxl_bitmap *sptr)
> +{
> +    assert(dptr->size >=3D sptr->size);
> +    memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
> +}
> +
Looking at other callers of libxl_bitmap_copy(), I think something like
this makes sense for pretty much all of them.

And even abstracting from them, and thinking to how a function like
'libxl_bitmap_copy()' this should behave, copying only the "common part"
makes sense to me.

So, should we make libxl_bitmap_copy() behave like implemented above,
rather than introducing a new function. I know this is public stable
API, but I think this is a fine behavioral change, isn't it?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Sl7hztBN5p6xVS4QEL3F
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 v2

iEYEABECAAYFAlRvIWEACgkQk4XaBE3IOsTgXgCeLdrlytQQWoLy9M8+g5v+HPDa
UrYAoKzTvsYypeHTad0BXHiylTgsLP2x
=Fdax
-----END PGP SIGNATURE-----

--=-Sl7hztBN5p6xVS4QEL3F--


--===============6505362266485923778==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6505362266485923778==--


From xen-devel-bounces@lists.xen.org Fri Nov 21 11:44:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:44:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmdR-0003sp-QF; Fri, 21 Nov 2014 11:44: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@citrix.com>) id 1XrmdR-0003sk-07
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 11:44:21 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	E7/EC-29352-4952F645; Fri, 21 Nov 2014 11:44:20 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416570258!7245727!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19210 invoked from network); 21 Nov 2014 11:44:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:44:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195200227"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 06:44:15 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrmdL-0001Rs-FJ;
	Fri, 21 Nov 2014 11:44:15 +0000
Date: Fri, 21 Nov 2014 11:43:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <1416484225-28054-5-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411211137520.12596@kaball.uk.xensource.com>
References: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
	<1416484225-28054-5-git-send-email-david.vrabel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4/4] x86/xen: assume a 64-bit DMA mask is
	required
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, David Vrabel wrote:
> On a Xen PV guest the DMA addresses and physical addresses are not 1:1
> (such as Xen PV guests) and the generic dma_get_required_mask() does
> not return the correct mask (since it uses max_pfn).
> 
> Some device drivers (such as mptsas, mpt2sas) use
> dma_get_required_mask() to set the device's DMA mask to allow them to
> use only 32-bit DMA addresses in hardware structures.  This results in
> unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
> impacting performance significantly.
> 
> We could base the DMA mask on the maximum MFN but:
> 
> a) The hypercall op to get the maximum MFN (XENMEM_maximum_ram_page)
> will truncate the result to an int in 32-bit guests.
> 
> b) Future uses of the IOMMU in Xen may map frames at bus addresses
> above the end of RAM.
> 
> So, just assume a 64-bit DMA mask is always required.
 
That's OK for me but at this point I am unsure whether swiotlb-xen is
the right place to put this function.  It feels more like something that
should be introduced in pci-swiotlb-xen.c or arch/x86/xen/mmu.c?

If I were to introduce it on ARM, I would add it to arch/arm/xen/mm.c.


> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>
>  arch/x86/xen/pci-swiotlb-xen.c |    1 +
>  drivers/xen/swiotlb-xen.c      |    9 +++++++++
>  include/xen/swiotlb-xen.h      |    4 ++++
>  3 files changed, 14 insertions(+)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index 0e98e5d..a5d180a 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -31,6 +31,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
>  	.map_page = xen_swiotlb_map_page,
>  	.unmap_page = xen_swiotlb_unmap_page,
>  	.dma_supported = xen_swiotlb_dma_supported,
> +	.get_required_mask = xen_swiotlb_get_required_mask,
>  };
>  
>  /*
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ebd8f21..767d048 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -42,9 +42,11 @@
>  #include <xen/page.h>
>  #include <xen/xen-ops.h>
>  #include <xen/hvc-console.h>
> +#include <xen/interface/memory.h>
>  
>  #include <asm/dma-mapping.h>
>  #include <asm/xen/page-coherent.h>
> +#include <asm/xen/hypercall.h>
>  
>  #include <trace/events/swiotlb.h>
>  /*
> @@ -683,3 +685,10 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
> +
> +u64
> +xen_swiotlb_get_required_mask(struct device *dev)
> +{
> +	return DMA_BIT_MASK(64);
> +}
> +EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index 8b2eb93..6408888 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -58,4 +58,8 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
>  
>  extern int
>  xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
> +
> +extern u64
> +xen_swiotlb_get_required_mask(struct device *dev);
> +
>  #endif /* __LINUX_SWIOTLB_XEN_H */
> -- 
> 1.7.10.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  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://secure-web.cisco.com/1uIZMIeWCQQAJEnGQc6XX-CEjdCVm87GER9t4JEG7wumHKaVAK-6pwSilKvT3RCicfLK8CEakvw_GaO39BTHmmtTqFXSad9_K_6hMXHETF0twK9R1Pdq_kGKFl6aw081mC3L6qVNyOQdb-Hyqn38-_ESRf6rGMDflx4RA3XBEjGA/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:44:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:44:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmdR-0003sp-QF; Fri, 21 Nov 2014 11:44: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@citrix.com>) id 1XrmdR-0003sk-07
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 11:44:21 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	E7/EC-29352-4952F645; Fri, 21 Nov 2014 11:44:20 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416570258!7245727!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19210 invoked from network); 21 Nov 2014 11:44:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 11:44:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="195200227"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 06:44:15 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrmdL-0001Rs-FJ;
	Fri, 21 Nov 2014 11:44:15 +0000
Date: Fri, 21 Nov 2014 11:43:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <1416484225-28054-5-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411211137520.12596@kaball.uk.xensource.com>
References: <1416484225-28054-1-git-send-email-david.vrabel@citrix.com>
	<1416484225-28054-5-git-send-email-david.vrabel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4/4] x86/xen: assume a 64-bit DMA mask is
	required
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Nov 2014, David Vrabel wrote:
> On a Xen PV guest the DMA addresses and physical addresses are not 1:1
> (such as Xen PV guests) and the generic dma_get_required_mask() does
> not return the correct mask (since it uses max_pfn).
> 
> Some device drivers (such as mptsas, mpt2sas) use
> dma_get_required_mask() to set the device's DMA mask to allow them to
> use only 32-bit DMA addresses in hardware structures.  This results in
> unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
> impacting performance significantly.
> 
> We could base the DMA mask on the maximum MFN but:
> 
> a) The hypercall op to get the maximum MFN (XENMEM_maximum_ram_page)
> will truncate the result to an int in 32-bit guests.
> 
> b) Future uses of the IOMMU in Xen may map frames at bus addresses
> above the end of RAM.
> 
> So, just assume a 64-bit DMA mask is always required.
 
That's OK for me but at this point I am unsure whether swiotlb-xen is
the right place to put this function.  It feels more like something that
should be introduced in pci-swiotlb-xen.c or arch/x86/xen/mmu.c?

If I were to introduce it on ARM, I would add it to arch/arm/xen/mm.c.


> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>
>  arch/x86/xen/pci-swiotlb-xen.c |    1 +
>  drivers/xen/swiotlb-xen.c      |    9 +++++++++
>  include/xen/swiotlb-xen.h      |    4 ++++
>  3 files changed, 14 insertions(+)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index 0e98e5d..a5d180a 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -31,6 +31,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
>  	.map_page = xen_swiotlb_map_page,
>  	.unmap_page = xen_swiotlb_unmap_page,
>  	.dma_supported = xen_swiotlb_dma_supported,
> +	.get_required_mask = xen_swiotlb_get_required_mask,
>  };
>  
>  /*
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ebd8f21..767d048 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -42,9 +42,11 @@
>  #include <xen/page.h>
>  #include <xen/xen-ops.h>
>  #include <xen/hvc-console.h>
> +#include <xen/interface/memory.h>
>  
>  #include <asm/dma-mapping.h>
>  #include <asm/xen/page-coherent.h>
> +#include <asm/xen/hypercall.h>
>  
>  #include <trace/events/swiotlb.h>
>  /*
> @@ -683,3 +685,10 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
> +
> +u64
> +xen_swiotlb_get_required_mask(struct device *dev)
> +{
> +	return DMA_BIT_MASK(64);
> +}
> +EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index 8b2eb93..6408888 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -58,4 +58,8 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
>  
>  extern int
>  xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
> +
> +extern u64
> +xen_swiotlb_get_required_mask(struct device *dev);
> +
>  #endif /* __LINUX_SWIOTLB_XEN_H */
> -- 
> 1.7.10.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  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://secure-web.cisco.com/1uIZMIeWCQQAJEnGQc6XX-CEjdCVm87GER9t4JEG7wumHKaVAK-6pwSilKvT3RCicfLK8CEakvw_GaO39BTHmmtTqFXSad9_K_6hMXHETF0twK9R1Pdq_kGKFl6aw081mC3L6qVNyOQdb-Hyqn38-_ESRf6rGMDflx4RA3XBEjGA/http%3A%2F%2Fwww.tux.org%2Flkml%2F
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:49:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:49:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrmhy-00043G-Ge; Fri, 21 Nov 2014 11:49:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xrmhx-000439-Ci
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 11:49:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E0/20-09936-CA62F645; Fri, 21 Nov 2014 11:49:00 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416570538!14427751!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11651 invoked from network); 21 Nov 2014 11:49:00 -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;
	21 Nov 2014 11:49:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193667428"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 06:48:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xrmhr-0001XK-RX;
	Fri, 21 Nov 2014 11:48:55 +0000
Date: Fri, 21 Nov 2014 11:48:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411211147450.12596@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-mips@linux-mips.org, airlied@linux.ie,
	dri-devel@lists.freedesktop.org, xen-devel@lists.xensource.com,
	linux@arm.linux.org.uk, vinod.koul@intel.com, deller@gmx.de,
	jejb@parisc-linux.org, dwmw2@infradead.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	alexander.deucher@amd.com, bhelgaas@google.com,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, ralf@linux-mips.org,
	iommu@lists.linux-foundation.org, David Vrabel <david.vrabel@citrix.com>,
	dmaengine@vger.kernel.org, torvalds@linux-foundation.org,
	christian.koenig@amd.com
Subject: Re: [Xen-devel] [RFC] add a struct page* parameter to
	dma_map_ops.unmap_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 Mon, 17 Nov 2014, Stefano Stabellini wrote:
> Hi all,
> I am writing this email to ask for your advice.
> 
> On architectures where dma addresses are different from physical
> addresses, it can be difficult to retrieve the physical address of a
> page from its dma address.
> 
> Specifically this is the case for Xen on arm and arm64 but I think that
> other architectures might have the same issue.
> 
> Knowing the physical address is necessary to be able to issue any
> required cache maintenance operations when unmap_page,
> sync_single_for_cpu and sync_single_for_device are called.
> 
> Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
> sync_single_for_device would make Linux dma handling on Xen on arm and
> arm64 much easier and quicker.
> 
> I think that other drivers have similar problems, such as the Intel
> IOMMU driver having to call find_iova and walking down an rbtree to get
> the physical address in its implementation of unmap_page.
> 
> Callers have the struct page* in their hands already from the previous
> map_page call so it shouldn't be an issue for them.  A problem does
> exist however: there are about 280 callers of dma_unmap_page and
> pci_unmap_page. We have even more callers of the dma_sync_single_for_*
> functions.
> 
> 
> 
> Is such a change even conceivable? How would one go about it?
> 
> I think that Xen would not be the only one to gain from it, but I would
> like to have a confirmation from others: given the magnitude of the
> changes involved I would actually prefer to avoid them unless multiple
> drivers/archs/subsystems could really benefit from them.

Given the lack of interest from the community, I am going to drop this
idea.




> Cheers,
> 
> Stefano
> 
> 
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index d5d3881..158a765 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -31,8 +31,9 @@ struct dma_map_ops {
>  			       unsigned long offset, size_t size,
>  			       enum dma_data_direction dir,
>  			       struct dma_attrs *attrs);
> -	void (*unmap_page)(struct device *dev, dma_addr_t dma_handle,
> -			   size_t size, enum dma_data_direction dir,
> +	void (*unmap_page)(struct device *dev, struct page *page,
> +			   dma_addr_t dma_handle, size_t size,
> +			   enum dma_data_direction dir,
>  			   struct dma_attrs *attrs);
>  	int (*map_sg)(struct device *dev, struct scatterlist *sg,
>  		      int nents, enum dma_data_direction dir,
> @@ -41,10 +42,10 @@ struct dma_map_ops {
>  			 struct scatterlist *sg, int nents,
>  			 enum dma_data_direction dir,
>  			 struct dma_attrs *attrs);
> -	void (*sync_single_for_cpu)(struct device *dev,
> +	void (*sync_single_for_cpu)(struct device *dev, struct page *page,
>  				    dma_addr_t dma_handle, size_t size,
>  				    enum dma_data_direction dir);
> -	void (*sync_single_for_device)(struct device *dev,
> +	void (*sync_single_for_device)(struct device *dev, struct page *page,
>  				       dma_addr_t dma_handle, size_t size,
>  				       enum dma_data_direction dir);
>  	void (*sync_sg_for_cpu)(struct device *dev,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:49:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:49:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrmhy-00043G-Ge; Fri, 21 Nov 2014 11:49:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xrmhx-000439-Ci
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 11:49:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E0/20-09936-CA62F645; Fri, 21 Nov 2014 11:49:00 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416570538!14427751!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11651 invoked from network); 21 Nov 2014 11:49:00 -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;
	21 Nov 2014 11:49:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193667428"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 06:48:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xrmhr-0001XK-RX;
	Fri, 21 Nov 2014 11:48:55 +0000
Date: Fri, 21 Nov 2014 11:48:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411211147450.12596@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-mips@linux-mips.org, airlied@linux.ie,
	dri-devel@lists.freedesktop.org, xen-devel@lists.xensource.com,
	linux@arm.linux.org.uk, vinod.koul@intel.com, deller@gmx.de,
	jejb@parisc-linux.org, dwmw2@infradead.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	alexander.deucher@amd.com, bhelgaas@google.com,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, ralf@linux-mips.org,
	iommu@lists.linux-foundation.org, David Vrabel <david.vrabel@citrix.com>,
	dmaengine@vger.kernel.org, torvalds@linux-foundation.org,
	christian.koenig@amd.com
Subject: Re: [Xen-devel] [RFC] add a struct page* parameter to
	dma_map_ops.unmap_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 Mon, 17 Nov 2014, Stefano Stabellini wrote:
> Hi all,
> I am writing this email to ask for your advice.
> 
> On architectures where dma addresses are different from physical
> addresses, it can be difficult to retrieve the physical address of a
> page from its dma address.
> 
> Specifically this is the case for Xen on arm and arm64 but I think that
> other architectures might have the same issue.
> 
> Knowing the physical address is necessary to be able to issue any
> required cache maintenance operations when unmap_page,
> sync_single_for_cpu and sync_single_for_device are called.
> 
> Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
> sync_single_for_device would make Linux dma handling on Xen on arm and
> arm64 much easier and quicker.
> 
> I think that other drivers have similar problems, such as the Intel
> IOMMU driver having to call find_iova and walking down an rbtree to get
> the physical address in its implementation of unmap_page.
> 
> Callers have the struct page* in their hands already from the previous
> map_page call so it shouldn't be an issue for them.  A problem does
> exist however: there are about 280 callers of dma_unmap_page and
> pci_unmap_page. We have even more callers of the dma_sync_single_for_*
> functions.
> 
> 
> 
> Is such a change even conceivable? How would one go about it?
> 
> I think that Xen would not be the only one to gain from it, but I would
> like to have a confirmation from others: given the magnitude of the
> changes involved I would actually prefer to avoid them unless multiple
> drivers/archs/subsystems could really benefit from them.

Given the lack of interest from the community, I am going to drop this
idea.




> Cheers,
> 
> Stefano
> 
> 
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index d5d3881..158a765 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -31,8 +31,9 @@ struct dma_map_ops {
>  			       unsigned long offset, size_t size,
>  			       enum dma_data_direction dir,
>  			       struct dma_attrs *attrs);
> -	void (*unmap_page)(struct device *dev, dma_addr_t dma_handle,
> -			   size_t size, enum dma_data_direction dir,
> +	void (*unmap_page)(struct device *dev, struct page *page,
> +			   dma_addr_t dma_handle, size_t size,
> +			   enum dma_data_direction dir,
>  			   struct dma_attrs *attrs);
>  	int (*map_sg)(struct device *dev, struct scatterlist *sg,
>  		      int nents, enum dma_data_direction dir,
> @@ -41,10 +42,10 @@ struct dma_map_ops {
>  			 struct scatterlist *sg, int nents,
>  			 enum dma_data_direction dir,
>  			 struct dma_attrs *attrs);
> -	void (*sync_single_for_cpu)(struct device *dev,
> +	void (*sync_single_for_cpu)(struct device *dev, struct page *page,
>  				    dma_addr_t dma_handle, size_t size,
>  				    enum dma_data_direction dir);
> -	void (*sync_single_for_device)(struct device *dev,
> +	void (*sync_single_for_device)(struct device *dev, struct page *page,
>  				       dma_addr_t dma_handle, size_t size,
>  				       enum dma_data_direction dir);
>  	void (*sync_sg_for_cpu)(struct device *dev,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:50:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmjU-00048k-WD; Fri, 21 Nov 2014 11:50:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrmjT-00048a-1k
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 11:50:35 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	07/2D-23865-A072F645; Fri, 21 Nov 2014 11:50:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416570631!12983028!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2506 invoked from network); 21 Nov 2014 11:50:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 11:50:33 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALBoR7M006607
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 11:50:28 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALBoPuI012426
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 11:50:27 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALBoOtJ012129; Fri, 21 Nov 2014 11:50:24 GMT
Received: from [IPv6:2607:fb90:2405:f91c:53f:5d67:f782:e915] (/172.56.34.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 03:50:23 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <546EFD1502000078000499E3@smtp.nue.novell.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 21 Nov 2014 06:50:16 -0500
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
	to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>struct hvm_pirq_dpci *pirq_dpci)
>>      ASSERT(d->arch.hvm_domain.irq.dpci);
>>  
>>      spin_lock(&d->event_lock);
>> -    if ( pirq_dpci->state )
>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
>>      {
>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
>>          const struct dev_intx_gsi_link *digl;
>
>So this now guards solely against the timeout enforced EOI? Why do
>you no longer need to guard against cancellation (i.e. why isn't this
>looking at both ->state and ->masked)?
>

The previous state check was superfluous as the dpci_softirq would check for the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).

I actually had an cleanup patch that would have removed the 'if (pirq_dpci->state) ' and move the code for Xen 4.6.

Anyhow waiting to see if Sander was able to test with this patch.

>Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 11:50:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 11:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmjU-00048k-WD; Fri, 21 Nov 2014 11:50:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrmjT-00048a-1k
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 11:50:35 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	07/2D-23865-A072F645; Fri, 21 Nov 2014 11:50:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416570631!12983028!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2506 invoked from network); 21 Nov 2014 11:50:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 11:50:33 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALBoR7M006607
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 11:50:28 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALBoPuI012426
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 11:50:27 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALBoOtJ012129; Fri, 21 Nov 2014 11:50:24 GMT
Received: from [IPv6:2607:fb90:2405:f91c:53f:5d67:f782:e915] (/172.56.34.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 03:50:23 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <546EFD1502000078000499E3@smtp.nue.novell.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 21 Nov 2014 06:50:16 -0500
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
	to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>struct hvm_pirq_dpci *pirq_dpci)
>>      ASSERT(d->arch.hvm_domain.irq.dpci);
>>  
>>      spin_lock(&d->event_lock);
>> -    if ( pirq_dpci->state )
>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
>>      {
>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
>>          const struct dev_intx_gsi_link *digl;
>
>So this now guards solely against the timeout enforced EOI? Why do
>you no longer need to guard against cancellation (i.e. why isn't this
>looking at both ->state and ->masked)?
>

The previous state check was superfluous as the dpci_softirq would check for the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).

I actually had an cleanup patch that would have removed the 'if (pirq_dpci->state) ' and move the code for Xen 4.6.

Anyhow waiting to see if Sander was able to test with this patch.

>Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:04:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmwE-0004gl-JV; Fri, 21 Nov 2014 12:03:46 +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 1XrmwE-0004gf-0u
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 12:03:46 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	14/A4-08051-12A2F645; Fri, 21 Nov 2014 12:03:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416571424!14004944!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26214 invoked from network); 21 Nov 2014 12:03:44 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 12:03:44 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 13:03:43 +0100
Message-Id: <546F382F0200007800049B49@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 13:03:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
In-Reply-To: <FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 12:50, <konrad.wilk@oracle.com> wrote:
> On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
>>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>>struct hvm_pirq_dpci *pirq_dpci)
>>>      ASSERT(d->arch.hvm_domain.irq.dpci);
>>>  
>>>      spin_lock(&d->event_lock);
>>> -    if ( pirq_dpci->state )
>>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
>>>      {
>>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
>>>          const struct dev_intx_gsi_link *digl;
>>
>>So this now guards solely against the timeout enforced EOI? Why do
>>you no longer need to guard against cancellation (i.e. why isn't this
>>looking at both ->state and ->masked)?
>>
> 
> The previous state check was superfluous as the dpci_softirq would check for 
> the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).

I thought so first too, but then how is the guarding against
cancellation working now?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:04:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrmwE-0004gl-JV; Fri, 21 Nov 2014 12:03:46 +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 1XrmwE-0004gf-0u
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 12:03:46 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	14/A4-08051-12A2F645; Fri, 21 Nov 2014 12:03:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416571424!14004944!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26214 invoked from network); 21 Nov 2014 12:03:44 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 12:03:44 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 13:03:43 +0100
Message-Id: <546F382F0200007800049B49@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 13:03:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
In-Reply-To: <FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 12:50, <konrad.wilk@oracle.com> wrote:
> On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
>>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>>struct hvm_pirq_dpci *pirq_dpci)
>>>      ASSERT(d->arch.hvm_domain.irq.dpci);
>>>  
>>>      spin_lock(&d->event_lock);
>>> -    if ( pirq_dpci->state )
>>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
>>>      {
>>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
>>>          const struct dev_intx_gsi_link *digl;
>>
>>So this now guards solely against the timeout enforced EOI? Why do
>>you no longer need to guard against cancellation (i.e. why isn't this
>>looking at both ->state and ->masked)?
>>
> 
> The previous state check was superfluous as the dpci_softirq would check for 
> the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).

I thought so first too, but then how is the guarding against
cancellation working now?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:16:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrn7w-0004w7-Qh; Fri, 21 Nov 2014 12:15: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 1Xrn7v-0004w2-Um
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 12:15:52 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	A9/E1-14727-6FC2F645; Fri, 21 Nov 2014 12:15:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416572150!7253450!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28775 invoked from network); 21 Nov 2014 12:15:50 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 12:15:50 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 13:15:49 +0100
Message-Id: <546F3B060200007800049B5D@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 13:15:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Juergen Gross" <JGross@suse.com>
References: <546E32BB.8090909@citrix.com>
	<1416562990.26869.10.camel@citrix.com> <546F12F2.3020809@citrix.com>
	<1416566814.26869.14.camel@citrix.com> <546F1CF8.8010900@citrix.com>
	<1416568502.26869.24.camel@citrix.com> <546F2000.9020802@suse.com>
	<1416569047.26869.25.camel@citrix.com>
In-Reply-To: <1416569047.26869.25.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	ShriramRajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 21.11.14 at 12:24, <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-11-21 at 12:20 +0100, Juergen Gross wrote:
>> On 11/21/2014 12:15 PM, Ian Campbell wrote:
>> > On Fri, 2014-11-21 at 11:07 +0000, Andrew Cooper wrote:
>> >> On 21/11/14 10:46, Ian Campbell wrote:
>> >>> On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
>> >>>> On 21/11/14 09:43, Ian Campbell wrote:
>> >>>>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
>> >>>>> here, where does that fit in?
>> >>>>>
>> >>>> It is referenced several times, although not by its exact name.
>> >>> Hence no explicit mention.
>> >>>
>> >>> It's ambiguous when you refer to "higher level frames" (which I presume
>> >>> are the reference you are referring to) because some kernels (perhaps
>> >>> only historic ones, I've not been keeping up) keep both an N-level tree
>> >>> of their own internally and the toolstack visible frame_list_list
>> >>> (sometimes partially overlapping at some level). Is every reference to
>> >>> "higher level frames" actually intended to be a reference to
>> >>> pfn_to_mfn_frame_list_list or not?
>> >>
>> >> "higher level frames" would be the toolstack-abi-defined first and
>> >> second level lists.  The logdirty infrastructure can be used to detect
>> >> writes to these frames, and therefore detect structural changes to the p2m.
>> >>
>> >> I would like to hope that every kernel out there keeps this information
>> >> correctly up-to-date and updates it in an appropriate order...
>> >>
>> >>>
>> >>> It seems like sometimes you are talking at times about tracking the
>> >>> kernel's internal structure and not just pfn_to_mfn_frame_list_list and
>> >>> I'm not sure why that would be.
>> >>
>> >> I apologise for giving this impression.  It was not intended.
>> >
>> > Great, I just wanted to be sure we were all on the same page, since
>> > scrobbling around in the kernel's internal data structures would clearly
>> > be mad...
>> >
>> >>
>> >>> I'm also not sure why
>> >>> pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
>> >>> AFAIK the guest is still obliged to keep that up to date regardless of
>> >>> the scheme it uses internally for accessing the p2m.
>> >>
>> >> There are two reasons for the virtual linear p2m, the primary one being
>> >> to break the hard 512GB limit given the old 3-level table.
>> >>
>> >> A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
>> >> it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
>> >> the virtual linear method, a PV guest explicitly sets
>> >> pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
>> >> adjacent information.
>> >
>> > Oh, I hadn't realised this linear p2m stuff involved a guest ABI change.
>> > Have I somehow completely missed the xen.git side of these patches? I
>> > thought I'd only seen linux.git ones (and hence wasn't looking very
>> > closely).
>> 
>> V1 of the patches suggesting such a change have been posted a week ago:
>> 
>> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01276.html 
> 
> Ah, thanks. I had indeed ignored that as "just another iteration of the
> linux patches", oops!

So did I, not the least because it was sent to David and Konrad
rather than Cc-ing the hypervisor side maintainers (other than
me).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:16:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrn7w-0004w7-Qh; Fri, 21 Nov 2014 12:15: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 1Xrn7v-0004w2-Um
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 12:15:52 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	A9/E1-14727-6FC2F645; Fri, 21 Nov 2014 12:15:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416572150!7253450!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28775 invoked from network); 21 Nov 2014 12:15:50 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 12:15:50 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 13:15:49 +0100
Message-Id: <546F3B060200007800049B5D@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 13:15:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Juergen Gross" <JGross@suse.com>
References: <546E32BB.8090909@citrix.com>
	<1416562990.26869.10.camel@citrix.com> <546F12F2.3020809@citrix.com>
	<1416566814.26869.14.camel@citrix.com> <546F1CF8.8010900@citrix.com>
	<1416568502.26869.24.camel@citrix.com> <546F2000.9020802@suse.com>
	<1416569047.26869.25.camel@citrix.com>
In-Reply-To: <1416569047.26869.25.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	ShriramRajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 21.11.14 at 12:24, <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-11-21 at 12:20 +0100, Juergen Gross wrote:
>> On 11/21/2014 12:15 PM, Ian Campbell wrote:
>> > On Fri, 2014-11-21 at 11:07 +0000, Andrew Cooper wrote:
>> >> On 21/11/14 10:46, Ian Campbell wrote:
>> >>> On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
>> >>>> On 21/11/14 09:43, Ian Campbell wrote:
>> >>>>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
>> >>>>> here, where does that fit in?
>> >>>>>
>> >>>> It is referenced several times, although not by its exact name.
>> >>> Hence no explicit mention.
>> >>>
>> >>> It's ambiguous when you refer to "higher level frames" (which I presume
>> >>> are the reference you are referring to) because some kernels (perhaps
>> >>> only historic ones, I've not been keeping up) keep both an N-level tree
>> >>> of their own internally and the toolstack visible frame_list_list
>> >>> (sometimes partially overlapping at some level). Is every reference to
>> >>> "higher level frames" actually intended to be a reference to
>> >>> pfn_to_mfn_frame_list_list or not?
>> >>
>> >> "higher level frames" would be the toolstack-abi-defined first and
>> >> second level lists.  The logdirty infrastructure can be used to detect
>> >> writes to these frames, and therefore detect structural changes to the p2m.
>> >>
>> >> I would like to hope that every kernel out there keeps this information
>> >> correctly up-to-date and updates it in an appropriate order...
>> >>
>> >>>
>> >>> It seems like sometimes you are talking at times about tracking the
>> >>> kernel's internal structure and not just pfn_to_mfn_frame_list_list and
>> >>> I'm not sure why that would be.
>> >>
>> >> I apologise for giving this impression.  It was not intended.
>> >
>> > Great, I just wanted to be sure we were all on the same page, since
>> > scrobbling around in the kernel's internal data structures would clearly
>> > be mad...
>> >
>> >>
>> >>> I'm also not sure why
>> >>> pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
>> >>> AFAIK the guest is still obliged to keep that up to date regardless of
>> >>> the scheme it uses internally for accessing the p2m.
>> >>
>> >> There are two reasons for the virtual linear p2m, the primary one being
>> >> to break the hard 512GB limit given the old 3-level table.
>> >>
>> >> A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
>> >> it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
>> >> the virtual linear method, a PV guest explicitly sets
>> >> pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
>> >> adjacent information.
>> >
>> > Oh, I hadn't realised this linear p2m stuff involved a guest ABI change.
>> > Have I somehow completely missed the xen.git side of these patches? I
>> > thought I'd only seen linux.git ones (and hence wasn't looking very
>> > closely).
>> 
>> V1 of the patches suggesting such a change have been posted a week ago:
>> 
>> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01276.html 
> 
> Ah, thanks. I had indeed ignored that as "just another iteration of the
> linux patches", oops!

So did I, not the least because it was sent to David and Konrad
rather than Cc-ing the hypervisor side maintainers (other than
me).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:21:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrnCr-00053I-H6; Fri, 21 Nov 2014 12:20:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrnCp-00053B-Vz
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 12:20:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F8/6A-09936-72E2F645; Fri, 21 Nov 2014 12:20:55 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416572454!14339523!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6782 invoked from network); 21 Nov 2014 12:20:54 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 12:20:54 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 04014AD08;
	Fri, 21 Nov 2014 12:20:53 +0000 (UTC)
Message-ID: <546F2E24.2000800@suse.com>
Date: Fri, 21 Nov 2014 13:20:52 +0100
From: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, 
 Ian Campbell <Ian.Campbell@citrix.com>
References: <546E32BB.8090909@citrix.com>	<1416562990.26869.10.camel@citrix.com>
	<546F12F2.3020809@citrix.com>	<1416566814.26869.14.camel@citrix.com>
	<546F1CF8.8010900@citrix.com>	<1416568502.26869.24.camel@citrix.com>
	<546F2000.9020802@suse.com>	<1416569047.26869.25.camel@citrix.com>
	<546F3B060200007800049B5D@smtp.nue.novell.com>
In-Reply-To: <546F3B060200007800049B5D@smtp.nue.novell.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	ShriramRajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 01:15 PM, Jan Beulich wrote:
>>>> On 21.11.14 at 12:24, <Ian.Campbell@citrix.com> wrote:
>> On Fri, 2014-11-21 at 12:20 +0100, Juergen Gross wrote:
>>> On 11/21/2014 12:15 PM, Ian Campbell wrote:
>>>> On Fri, 2014-11-21 at 11:07 +0000, Andrew Cooper wrote:
>>>>> On 21/11/14 10:46, Ian Campbell wrote:
>>>>>> On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
>>>>>>> On 21/11/14 09:43, Ian Campbell wrote:
>>>>>>>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
>>>>>>>> here, where does that fit in?
>>>>>>>>
>>>>>>> It is referenced several times, although not by its exact name.
>>>>>> Hence no explicit mention.
>>>>>>
>>>>>> It's ambiguous when you refer to "higher level frames" (which I presume
>>>>>> are the reference you are referring to) because some kernels (perhaps
>>>>>> only historic ones, I've not been keeping up) keep both an N-level tree
>>>>>> of their own internally and the toolstack visible frame_list_list
>>>>>> (sometimes partially overlapping at some level). Is every reference to
>>>>>> "higher level frames" actually intended to be a reference to
>>>>>> pfn_to_mfn_frame_list_list or not?
>>>>>
>>>>> "higher level frames" would be the toolstack-abi-defined first and
>>>>> second level lists.  The logdirty infrastructure can be used to detect
>>>>> writes to these frames, and therefore detect structural changes to the p2m.
>>>>>
>>>>> I would like to hope that every kernel out there keeps this information
>>>>> correctly up-to-date and updates it in an appropriate order...
>>>>>
>>>>>>
>>>>>> It seems like sometimes you are talking at times about tracking the
>>>>>> kernel's internal structure and not just pfn_to_mfn_frame_list_list and
>>>>>> I'm not sure why that would be.
>>>>>
>>>>> I apologise for giving this impression.  It was not intended.
>>>>
>>>> Great, I just wanted to be sure we were all on the same page, since
>>>> scrobbling around in the kernel's internal data structures would clearly
>>>> be mad...
>>>>
>>>>>
>>>>>> I'm also not sure why
>>>>>> pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
>>>>>> AFAIK the guest is still obliged to keep that up to date regardless of
>>>>>> the scheme it uses internally for accessing the p2m.
>>>>>
>>>>> There are two reasons for the virtual linear p2m, the primary one being
>>>>> to break the hard 512GB limit given the old 3-level table.
>>>>>
>>>>> A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
>>>>> it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
>>>>> the virtual linear method, a PV guest explicitly sets
>>>>> pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
>>>>> adjacent information.
>>>>
>>>> Oh, I hadn't realised this linear p2m stuff involved a guest ABI change.
>>>> Have I somehow completely missed the xen.git side of these patches? I
>>>> thought I'd only seen linux.git ones (and hence wasn't looking very
>>>> closely).
>>>
>>> V1 of the patches suggesting such a change have been posted a week ago:
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01276.html
>>
>> Ah, thanks. I had indeed ignored that as "just another iteration of the
>> linux patches", oops!
>
> So did I, not the least because it was sent to David and Konrad
> rather than Cc-ing the hypervisor side maintainers (other than
> me).

Oops, sorry.

Will do better for V2.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:21:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrnCr-00053I-H6; Fri, 21 Nov 2014 12:20:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrnCp-00053B-Vz
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 12:20:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F8/6A-09936-72E2F645; Fri, 21 Nov 2014 12:20:55 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416572454!14339523!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6782 invoked from network); 21 Nov 2014 12:20:54 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 12:20:54 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 04014AD08;
	Fri, 21 Nov 2014 12:20:53 +0000 (UTC)
Message-ID: <546F2E24.2000800@suse.com>
Date: Fri, 21 Nov 2014 13:20:52 +0100
From: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, 
 Ian Campbell <Ian.Campbell@citrix.com>
References: <546E32BB.8090909@citrix.com>	<1416562990.26869.10.camel@citrix.com>
	<546F12F2.3020809@citrix.com>	<1416566814.26869.14.camel@citrix.com>
	<546F1CF8.8010900@citrix.com>	<1416568502.26869.24.camel@citrix.com>
	<546F2000.9020802@suse.com>	<1416569047.26869.25.camel@citrix.com>
	<546F3B060200007800049B5D@smtp.nue.novell.com>
In-Reply-To: <546F3B060200007800049B5D@smtp.nue.novell.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	ShriramRajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 01:15 PM, Jan Beulich wrote:
>>>> On 21.11.14 at 12:24, <Ian.Campbell@citrix.com> wrote:
>> On Fri, 2014-11-21 at 12:20 +0100, Juergen Gross wrote:
>>> On 11/21/2014 12:15 PM, Ian Campbell wrote:
>>>> On Fri, 2014-11-21 at 11:07 +0000, Andrew Cooper wrote:
>>>>> On 21/11/14 10:46, Ian Campbell wrote:
>>>>>> On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
>>>>>>> On 21/11/14 09:43, Ian Campbell wrote:
>>>>>>>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
>>>>>>>> here, where does that fit in?
>>>>>>>>
>>>>>>> It is referenced several times, although not by its exact name.
>>>>>> Hence no explicit mention.
>>>>>>
>>>>>> It's ambiguous when you refer to "higher level frames" (which I presume
>>>>>> are the reference you are referring to) because some kernels (perhaps
>>>>>> only historic ones, I've not been keeping up) keep both an N-level tree
>>>>>> of their own internally and the toolstack visible frame_list_list
>>>>>> (sometimes partially overlapping at some level). Is every reference to
>>>>>> "higher level frames" actually intended to be a reference to
>>>>>> pfn_to_mfn_frame_list_list or not?
>>>>>
>>>>> "higher level frames" would be the toolstack-abi-defined first and
>>>>> second level lists.  The logdirty infrastructure can be used to detect
>>>>> writes to these frames, and therefore detect structural changes to the p2m.
>>>>>
>>>>> I would like to hope that every kernel out there keeps this information
>>>>> correctly up-to-date and updates it in an appropriate order...
>>>>>
>>>>>>
>>>>>> It seems like sometimes you are talking at times about tracking the
>>>>>> kernel's internal structure and not just pfn_to_mfn_frame_list_list and
>>>>>> I'm not sure why that would be.
>>>>>
>>>>> I apologise for giving this impression.  It was not intended.
>>>>
>>>> Great, I just wanted to be sure we were all on the same page, since
>>>> scrobbling around in the kernel's internal data structures would clearly
>>>> be mad...
>>>>
>>>>>
>>>>>> I'm also not sure why
>>>>>> pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
>>>>>> AFAIK the guest is still obliged to keep that up to date regardless of
>>>>>> the scheme it uses internally for accessing the p2m.
>>>>>
>>>>> There are two reasons for the virtual linear p2m, the primary one being
>>>>> to break the hard 512GB limit given the old 3-level table.
>>>>>
>>>>> A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
>>>>> it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
>>>>> the virtual linear method, a PV guest explicitly sets
>>>>> pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
>>>>> adjacent information.
>>>>
>>>> Oh, I hadn't realised this linear p2m stuff involved a guest ABI change.
>>>> Have I somehow completely missed the xen.git side of these patches? I
>>>> thought I'd only seen linux.git ones (and hence wasn't looking very
>>>> closely).
>>>
>>> V1 of the patches suggesting such a change have been posted a week ago:
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01276.html
>>
>> Ah, thanks. I had indeed ignored that as "just another iteration of the
>> linux patches", oops!
>
> So did I, not the least because it was sent to David and Konrad
> rather than Cc-ing the hypervisor side maintainers (other than
> me).

Oops, sorry.

Will do better for V2.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:23:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrnF1-0005Ah-0g; Fri, 21 Nov 2014 12:23:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrnF0-0005Aa-HL
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 12:23:10 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	EE/83-22777-DAE2F645; Fri, 21 Nov 2014 12:23:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416572589!7372240!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18948 invoked from network); 21 Nov 2014 12:23:09 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 12:23:09 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 13:23:08 +0100
Message-Id: <546F3CBE0200007800049B77@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 13:23:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-2-git-send-email-jgross@suse.com>
In-Reply-To: <1415957846-22703-2-git-send-email-jgross@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -224,7 +224,12 @@ struct arch_shared_info {
>      /* Frame containing list of mfns containing list of mfns containing p2m. */
>      xen_pfn_t     pfn_to_mfn_frame_list_list;
>      unsigned long nmi_reason;
> -    uint64_t pad[32];
> +    /*
> +     * Following two fields are valid if pfn_to_mfn_frame_list_list contains
> +     * ~0UL.
> +     */
> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
> +    unsigned long p2m_as_root;  /* mfn of the top level page table */

xen_pfn_t please. And what does the "as" in the name stand for?
It's also kind of unclear in the description what "the page table root"
is, as I don't think there are many OSes which use just a single set
of page tables (i.e. just a single address space). Not having followed
the discussion closely - what is this needed for anyway?

> --- a/xen/include/public/features.h
> +++ b/xen/include/public/features.h
> @@ -99,6 +99,9 @@
>  #define XENFEAT_grant_map_identity        12
>   */
>  
> +/* x86: guest may specify virtual address of p2m list */
> +#define XENFEAT_virtual_p2m               13

The name to me suggests something that's not real. Perhaps better
XENFEAT_virtually_mapped_p2m or XENFEAT_p2m_va{,ddr}?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:23:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrnF1-0005Ah-0g; Fri, 21 Nov 2014 12:23:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrnF0-0005Aa-HL
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 12:23:10 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	EE/83-22777-DAE2F645; Fri, 21 Nov 2014 12:23:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416572589!7372240!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18948 invoked from network); 21 Nov 2014 12:23:09 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 12:23:09 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 13:23:08 +0100
Message-Id: <546F3CBE0200007800049B77@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 13:23:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-2-git-send-email-jgross@suse.com>
In-Reply-To: <1415957846-22703-2-git-send-email-jgross@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -224,7 +224,12 @@ struct arch_shared_info {
>      /* Frame containing list of mfns containing list of mfns containing p2m. */
>      xen_pfn_t     pfn_to_mfn_frame_list_list;
>      unsigned long nmi_reason;
> -    uint64_t pad[32];
> +    /*
> +     * Following two fields are valid if pfn_to_mfn_frame_list_list contains
> +     * ~0UL.
> +     */
> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
> +    unsigned long p2m_as_root;  /* mfn of the top level page table */

xen_pfn_t please. And what does the "as" in the name stand for?
It's also kind of unclear in the description what "the page table root"
is, as I don't think there are many OSes which use just a single set
of page tables (i.e. just a single address space). Not having followed
the discussion closely - what is this needed for anyway?

> --- a/xen/include/public/features.h
> +++ b/xen/include/public/features.h
> @@ -99,6 +99,9 @@
>  #define XENFEAT_grant_map_identity        12
>   */
>  
> +/* x86: guest may specify virtual address of p2m list */
> +#define XENFEAT_virtual_p2m               13

The name to me suggests something that's not real. Perhaps better
XENFEAT_virtually_mapped_p2m or XENFEAT_p2m_va{,ddr}?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:26:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12: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 1XrnIE-0005Jg-Jm; Fri, 21 Nov 2014 12:26:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrnID-0005JZ-NM
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 12:26:29 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3A/B3-09936-47F2F645; Fri, 21 Nov 2014 12:26:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416572788!14437319!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23086 invoked from network); 21 Nov 2014 12:26:28 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 12:26:28 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 13:26:28 +0100
Message-Id: <546F3D840200007800049B86@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 13:26:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-3-git-send-email-jgross@suse.com>
In-Reply-To: <1415957846-22703-3-git-send-email-jgross@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH 2/4] introduce arch_get_features()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
> The XENVER_get_features sub command of the xen_version hypercall is
> handled completely in common/kernel.c despite of some architecture
> dependant parts.
> 
> Move the architecture dependant parts in an own function in
> arch/*/domain.c
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Acked-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:26:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12: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 1XrnIE-0005Jg-Jm; Fri, 21 Nov 2014 12:26:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrnID-0005JZ-NM
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 12:26:29 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3A/B3-09936-47F2F645; Fri, 21 Nov 2014 12:26:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416572788!14437319!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23086 invoked from network); 21 Nov 2014 12:26:28 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 12:26:28 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 13:26:28 +0100
Message-Id: <546F3D840200007800049B86@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 13:26:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-3-git-send-email-jgross@suse.com>
In-Reply-To: <1415957846-22703-3-git-send-email-jgross@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH 2/4] introduce arch_get_features()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
> The XENVER_get_features sub command of the xen_version hypercall is
> handled completely in common/kernel.c despite of some architecture
> dependant parts.
> 
> Move the architecture dependant parts in an own function in
> arch/*/domain.c
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Acked-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:26:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:26:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrnIN-0005L6-K1; Fri, 21 Nov 2014 12:26:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrnIL-0005KF-Jn; Fri, 21 Nov 2014 12:26:37 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	CE/BA-23865-C7F2F645; Fri, 21 Nov 2014 12:26:36 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416572794!10503069!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9611 invoked from network); 21 Nov 2014 12:26:35 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-14.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Nov 2014 12:26:35 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrnHq-0004T8-3k; Fri, 21 Nov 2014 12:26:06 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrnHp-00011b-Fj; Fri, 21 Nov 2014 12:26:05 +0000
Date: Fri, 21 Nov 2014 12:26:05 +0000
Message-Id: <E1XrnHp-00011b-Fj@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 113 (CVE-2014-9030) - Guest
 effectable page reference leak in MMU_MACHPHYS_UPDATE handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2014-9030 / XSA-113
                              version 2

  Guest effectable page reference leak in MMU_MACHPHYS_UPDATE handling

UPDATES IN VERSION 2
====================

CVE assigned.

ISSUE DESCRIPTION
=================

An error handling path in the processing of MMU_MACHPHYS_UPDATE failed
to drop a page reference which was acquired in an earlier processing
step.

IMPACT
======

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.

Only domains controlling HVM guests can exploit this vulnerability.
(This includes domains providing hardware emulation services to HVM
guests.)

VULNERABLE SYSTEMS
==================

Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
Older versions have not been inspected.  ARM systems are not vulnerable.

This vulnerability is only applicable to Xen systems using stub domains
or other forms of disaggregation of control domains for HVM guests.

MITIGATION
==========

Running only PV guests will avoid this issue.

(The security of a Xen system using stub domains is still better than
with a qemu-dm running as an unrestricted dom0 process.  Therefore
users with these configurations should not switch to an unrestricted
dom0 qemu-dm.)

NOTE REGARDING LACK OF EMBARGO
==============================

A draft of this advisory was mistakenly sent to xen-devel.  The Xen
Project Security Team apologises for this error.  We are working to
share best working practices amongst the team to reduce the risks of
recurrance.

CREDITS
=======

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa113.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x

$ sha256sum xsa113*.patch
a0f2b792a6b4648151f85fe13961b0bf309a568ed03e1b1d4ea01e4eabf1b18e  xsa113.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUby8sAAoJEIP+FMlX6CvZgTMH+gJVBouqw0FL2njjs3SCvAeh
ntGmK31VE5a0dt98UCI6oPXpHJAN40M4Ib2dsubpGpyeA/bpakfu2RUnZhzvVuah
7d5pXt08HiZHOeDfBdrcnZ8rFS77w50ZBY9R6jpF6h/ABBKtVobT6jTxmh2xoGFw
YqzsDxaA2bgytyDCNcAcYGWQYFy06tmzuaMX9h1Ozxt/YTxxhkNTPTJNVoUQppMc
zD/BixwfYLe7o0jo+/3k12e1/tXEvtyW/r9uyvhhE+HgRT68JA3tluqlsd1IbYhP
C2u7C9z/Mlf2fe2ONyEqEBXofikV5oahmMKWxkKNQ2Y6i9LJaLuoz1SBX1m8OKg=
=BwdT
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa113.patch"
Content-Disposition: attachment; filename="xsa113.patch"
Content-Transfer-Encoding: base64

eDg2L21tOiBmaXggYSByZWZlcmVuY2UgY291bnRpbmcgZXJyb3IgaW4gTU1V
X01BQ0hQSFlTX1VQREFURQoKQW55IGRvbWFpbiB3aGljaCBjYW4gcGFzcyB0
aGUgWFNNIGNoZWNrIGFnYWluc3QgYSB0cmFuc2xhdGVkIGd1ZXN0IGNhbiBj
YXVzZSBhCnBhZ2UgcmVmZXJlbmNlIHRvIGJlIGxlYWtlZC4KCldoaWxlIHNo
dWZmbGluZyB0aGUgb3JkZXIgb2YgY2hlY2tzLCBkcm9wIHRoZSBxdWl0ZS1w
b2ludGxlc3MgTUVNX0xPRygpLiAgVGhpcwpicmluZ3MgdGhlIGNoZWNrIGlu
IGxpbmUgd2l0aCBzaW1pbGFyIGNoZWNrcyBpbiB0aGUgdmljaW5pdHkuCgpE
aXNjb3ZlcmVkIHdoaWxlIHJldmlld2luZyB0aGUgWFNBLTEwOS8xMTAgZm9s
bG93dXAgc2VyaWVzLgoKVGhpcyBpcyBYU0EtMTEzLgoKU2lnbmVkLW9mZi1i
eTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4K
UmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
UmV2aWV3ZWQtYnk6IFRpbSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoKLS0tIGEv
eGVuL2FyY2gveDg2L21tLmMKKysrIGIveGVuL2FyY2gveDg2L21tLmMKQEAg
LTM2MTksNiArMzYxOSwxMiBAQCBsb25nIGRvX21tdV91cGRhdGUoCiAKICAg
ICAgICAgY2FzZSBNTVVfTUFDSFBIWVNfVVBEQVRFOgogCisgICAgICAgICAg
ICBpZiAoIHVubGlrZWx5KHBhZ2luZ19tb2RlX3RyYW5zbGF0ZShwZ19vd25l
cikpICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICByYyA9IC1F
SU5WQUw7CisgICAgICAgICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICB9
CisKICAgICAgICAgICAgIG1mbiA9IHJlcS5wdHIgPj4gUEFHRV9TSElGVDsK
ICAgICAgICAgICAgIGdwZm4gPSByZXEudmFsOwogCkBAIC0zNjM4LDEzICsz
NjQ0LDYgQEAgbG9uZyBkb19tbXVfdXBkYXRlKAogICAgICAgICAgICAgICAg
IGJyZWFrOwogICAgICAgICAgICAgfQogCi0gICAgICAgICAgICBpZiAoIHVu
bGlrZWx5KHBhZ2luZ19tb2RlX3RyYW5zbGF0ZShwZ19vd25lcikpICkKLSAg
ICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBNRU1fTE9HKCJNYWNoLXBo
eXMgdXBkYXRlIG9uIGF1dG8tdHJhbnNsYXRlIGd1ZXN0Iik7Ci0gICAgICAg
ICAgICAgICAgcmMgPSAtRUlOVkFMOwotICAgICAgICAgICAgICAgIGJyZWFr
OwotICAgICAgICAgICAgfQotCiAgICAgICAgICAgICBzZXRfZ3Bmbl9mcm9t
X21mbihtZm4sIGdwZm4pOwogCiAgICAgICAgICAgICBwYWdpbmdfbWFya19k
aXJ0eShwZ19vd25lciwgbWZuKTsK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Fri Nov 21 12:26:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:26:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrnIN-0005L6-K1; Fri, 21 Nov 2014 12:26:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrnIL-0005KF-Jn; Fri, 21 Nov 2014 12:26:37 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	CE/BA-23865-C7F2F645; Fri, 21 Nov 2014 12:26:36 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416572794!10503069!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9611 invoked from network); 21 Nov 2014 12:26:35 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-14.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Nov 2014 12:26:35 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrnHq-0004T8-3k; Fri, 21 Nov 2014 12:26:06 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XrnHp-00011b-Fj; Fri, 21 Nov 2014 12:26:05 +0000
Date: Fri, 21 Nov 2014 12:26:05 +0000
Message-Id: <E1XrnHp-00011b-Fj@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 113 (CVE-2014-9030) - Guest
 effectable page reference leak in MMU_MACHPHYS_UPDATE handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2014-9030 / XSA-113
                              version 2

  Guest effectable page reference leak in MMU_MACHPHYS_UPDATE handling

UPDATES IN VERSION 2
====================

CVE assigned.

ISSUE DESCRIPTION
=================

An error handling path in the processing of MMU_MACHPHYS_UPDATE failed
to drop a page reference which was acquired in an earlier processing
step.

IMPACT
======

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.

Only domains controlling HVM guests can exploit this vulnerability.
(This includes domains providing hardware emulation services to HVM
guests.)

VULNERABLE SYSTEMS
==================

Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
Older versions have not been inspected.  ARM systems are not vulnerable.

This vulnerability is only applicable to Xen systems using stub domains
or other forms of disaggregation of control domains for HVM guests.

MITIGATION
==========

Running only PV guests will avoid this issue.

(The security of a Xen system using stub domains is still better than
with a qemu-dm running as an unrestricted dom0 process.  Therefore
users with these configurations should not switch to an unrestricted
dom0 qemu-dm.)

NOTE REGARDING LACK OF EMBARGO
==============================

A draft of this advisory was mistakenly sent to xen-devel.  The Xen
Project Security Team apologises for this error.  We are working to
share best working practices amongst the team to reduce the risks of
recurrance.

CREDITS
=======

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa113.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x

$ sha256sum xsa113*.patch
a0f2b792a6b4648151f85fe13961b0bf309a568ed03e1b1d4ea01e4eabf1b18e  xsa113.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUby8sAAoJEIP+FMlX6CvZgTMH+gJVBouqw0FL2njjs3SCvAeh
ntGmK31VE5a0dt98UCI6oPXpHJAN40M4Ib2dsubpGpyeA/bpakfu2RUnZhzvVuah
7d5pXt08HiZHOeDfBdrcnZ8rFS77w50ZBY9R6jpF6h/ABBKtVobT6jTxmh2xoGFw
YqzsDxaA2bgytyDCNcAcYGWQYFy06tmzuaMX9h1Ozxt/YTxxhkNTPTJNVoUQppMc
zD/BixwfYLe7o0jo+/3k12e1/tXEvtyW/r9uyvhhE+HgRT68JA3tluqlsd1IbYhP
C2u7C9z/Mlf2fe2ONyEqEBXofikV5oahmMKWxkKNQ2Y6i9LJaLuoz1SBX1m8OKg=
=BwdT
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa113.patch"
Content-Disposition: attachment; filename="xsa113.patch"
Content-Transfer-Encoding: base64

eDg2L21tOiBmaXggYSByZWZlcmVuY2UgY291bnRpbmcgZXJyb3IgaW4gTU1V
X01BQ0hQSFlTX1VQREFURQoKQW55IGRvbWFpbiB3aGljaCBjYW4gcGFzcyB0
aGUgWFNNIGNoZWNrIGFnYWluc3QgYSB0cmFuc2xhdGVkIGd1ZXN0IGNhbiBj
YXVzZSBhCnBhZ2UgcmVmZXJlbmNlIHRvIGJlIGxlYWtlZC4KCldoaWxlIHNo
dWZmbGluZyB0aGUgb3JkZXIgb2YgY2hlY2tzLCBkcm9wIHRoZSBxdWl0ZS1w
b2ludGxlc3MgTUVNX0xPRygpLiAgVGhpcwpicmluZ3MgdGhlIGNoZWNrIGlu
IGxpbmUgd2l0aCBzaW1pbGFyIGNoZWNrcyBpbiB0aGUgdmljaW5pdHkuCgpE
aXNjb3ZlcmVkIHdoaWxlIHJldmlld2luZyB0aGUgWFNBLTEwOS8xMTAgZm9s
bG93dXAgc2VyaWVzLgoKVGhpcyBpcyBYU0EtMTEzLgoKU2lnbmVkLW9mZi1i
eTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4K
UmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
UmV2aWV3ZWQtYnk6IFRpbSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoKLS0tIGEv
eGVuL2FyY2gveDg2L21tLmMKKysrIGIveGVuL2FyY2gveDg2L21tLmMKQEAg
LTM2MTksNiArMzYxOSwxMiBAQCBsb25nIGRvX21tdV91cGRhdGUoCiAKICAg
ICAgICAgY2FzZSBNTVVfTUFDSFBIWVNfVVBEQVRFOgogCisgICAgICAgICAg
ICBpZiAoIHVubGlrZWx5KHBhZ2luZ19tb2RlX3RyYW5zbGF0ZShwZ19vd25l
cikpICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICByYyA9IC1F
SU5WQUw7CisgICAgICAgICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICB9
CisKICAgICAgICAgICAgIG1mbiA9IHJlcS5wdHIgPj4gUEFHRV9TSElGVDsK
ICAgICAgICAgICAgIGdwZm4gPSByZXEudmFsOwogCkBAIC0zNjM4LDEzICsz
NjQ0LDYgQEAgbG9uZyBkb19tbXVfdXBkYXRlKAogICAgICAgICAgICAgICAg
IGJyZWFrOwogICAgICAgICAgICAgfQogCi0gICAgICAgICAgICBpZiAoIHVu
bGlrZWx5KHBhZ2luZ19tb2RlX3RyYW5zbGF0ZShwZ19vd25lcikpICkKLSAg
ICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBNRU1fTE9HKCJNYWNoLXBo
eXMgdXBkYXRlIG9uIGF1dG8tdHJhbnNsYXRlIGd1ZXN0Iik7Ci0gICAgICAg
ICAgICAgICAgcmMgPSAtRUlOVkFMOwotICAgICAgICAgICAgICAgIGJyZWFr
OwotICAgICAgICAgICAgfQotCiAgICAgICAgICAgICBzZXRfZ3Bmbl9mcm9t
X21mbihtZm4sIGdwZm4pOwogCiAgICAgICAgICAgICBwYWdpbmdfbWFya19k
aXJ0eShwZ19vd25lciwgbWZuKTsK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Fri Nov 21 12:52:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12: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 1XrngZ-0006VI-5U; Fri, 21 Nov 2014 12:51:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XrngY-0006VA-7G
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 12:51:38 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	33/82-03148-9553F645; Fri, 21 Nov 2014 12:51:37 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416574296!14008291!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10050 invoked from network); 21 Nov 2014 12:51:36 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 21 Nov 2014 12:51:36 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:57192 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xrnef-0008Bz-8Q; Fri, 21 Nov 2014 13:49:41 +0100
Date: Fri, 21 Nov 2014 13:51:24 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1346109865.20141121135124@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
MIME-Version: 1.0
Cc: andrew.cooper3@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
	to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 21, 2014, 12:50:16 PM, you wrote:

> On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
>>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>>struct hvm_pirq_dpci *pirq_dpci)
>>>      ASSERT(d->arch.hvm_domain.irq.dpci);
>>>  
>>>      spin_lock(&d->event_lock);
>>> -    if ( pirq_dpci->state )
>>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
>>>      {
>>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
>>>          const struct dev_intx_gsi_link *digl;
>>
>>So this now guards solely against the timeout enforced EOI? Why do
>>you no longer need to guard against cancellation (i.e. why isn't this
>>looking at both ->state and ->masked)?
>>

> The previous state check was superfluous as the dpci_softirq would check for the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).

> I actually had an cleanup patch that would have removed the 'if (pirq_dpci->state) ' and move the code for Xen 4.6.

> Anyhow waiting to see if Sander was able to test with this patch.

>>Jan

Hi Konrad / Jan,

I have tested it for 3 hours now, no host crash so far (even after applying some 
extra stress to the guest).

--
Sander



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:52:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12: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 1XrngZ-0006VI-5U; Fri, 21 Nov 2014 12:51:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XrngY-0006VA-7G
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 12:51:38 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	33/82-03148-9553F645; Fri, 21 Nov 2014 12:51:37 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416574296!14008291!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10050 invoked from network); 21 Nov 2014 12:51:36 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 21 Nov 2014 12:51:36 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:57192 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xrnef-0008Bz-8Q; Fri, 21 Nov 2014 13:49:41 +0100
Date: Fri, 21 Nov 2014 13:51:24 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1346109865.20141121135124@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
MIME-Version: 1.0
Cc: andrew.cooper3@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
	to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, November 21, 2014, 12:50:16 PM, you wrote:

> On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
>>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>>struct hvm_pirq_dpci *pirq_dpci)
>>>      ASSERT(d->arch.hvm_domain.irq.dpci);
>>>  
>>>      spin_lock(&d->event_lock);
>>> -    if ( pirq_dpci->state )
>>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
>>>      {
>>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
>>>          const struct dev_intx_gsi_link *digl;
>>
>>So this now guards solely against the timeout enforced EOI? Why do
>>you no longer need to guard against cancellation (i.e. why isn't this
>>looking at both ->state and ->masked)?
>>

> The previous state check was superfluous as the dpci_softirq would check for the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).

> I actually had an cleanup patch that would have removed the 'if (pirq_dpci->state) ' and move the code for Xen 4.6.

> Anyhow waiting to see if Sander was able to test with this patch.

>>Jan

Hi Konrad / Jan,

I have tested it for 3 hours now, no host crash so far (even after applying some 
extra stress to the guest).

--
Sander



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:57:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:57:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrnmY-0006nb-4k; Fri, 21 Nov 2014 12:57:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrnmW-0006nW-Li
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 12:57:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	15/FD-09936-CC63F645; Fri, 21 Nov 2014 12:57:48 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416574667!10971652!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10787 invoked from network); 21 Nov 2014 12:57:47 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 12:57:47 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 80A7CAB09;
	Fri, 21 Nov 2014 12:57:46 +0000 (UTC)
Message-ID: <546F36C9.3020004@suse.com>
Date: Fri, 21 Nov 2014 13:57:45 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>
	<546F3CBE0200007800049B77@smtp.nue.novell.com>
In-Reply-To: <546F3CBE0200007800049B77@smtp.nue.novell.com>
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, david.vrabel@citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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

On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
>> --- a/xen/include/public/arch-x86/xen.h
>> +++ b/xen/include/public/arch-x86/xen.h
>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>       /* Frame containing list of mfns containing list of mfns containing p2m. */
>>       xen_pfn_t     pfn_to_mfn_frame_list_list;
>>       unsigned long nmi_reason;
>> -    uint64_t pad[32];
>> +    /*
>> +     * Following two fields are valid if pfn_to_mfn_frame_list_list contains
>> +     * ~0UL.
>> +     */
>> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
>> +    unsigned long p2m_as_root;  /* mfn of the top level page table */
>
> xen_pfn_t please. And what does the "as" in the name stand for?

"as" is address space. I can rename it to e.g. "p2m_pgd_mfn".

> It's also kind of unclear in the description what "the page table root"
> is, as I don't think there are many OSes which use just a single set
> of page tables (i.e. just a single address space). Not having followed
> the discussion closely - what is this needed for anyway?

It's a replacement of the pfn_to_mfn_frame_list_list using the same
page table as the kernel for accessing the p2m list. We need the root
of the page table and the virtual address of the p2m list.

>
>> --- a/xen/include/public/features.h
>> +++ b/xen/include/public/features.h
>> @@ -99,6 +99,9 @@
>>   #define XENFEAT_grant_map_identity        12
>>    */
>>
>> +/* x86: guest may specify virtual address of p2m list */
>> +#define XENFEAT_virtual_p2m               13
>
> The name to me suggests something that's not real. Perhaps better
> XENFEAT_virtually_mapped_p2m or XENFEAT_p2m_va{,ddr}?

Yeah, that's better. I'll use XENFEAT_p2m_vaddr.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 12:57:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 12:57:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrnmY-0006nb-4k; Fri, 21 Nov 2014 12:57:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrnmW-0006nW-Li
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 12:57:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	15/FD-09936-CC63F645; Fri, 21 Nov 2014 12:57:48 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416574667!10971652!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10787 invoked from network); 21 Nov 2014 12:57:47 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 12:57:47 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 80A7CAB09;
	Fri, 21 Nov 2014 12:57:46 +0000 (UTC)
Message-ID: <546F36C9.3020004@suse.com>
Date: Fri, 21 Nov 2014 13:57:45 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>
	<546F3CBE0200007800049B77@smtp.nue.novell.com>
In-Reply-To: <546F3CBE0200007800049B77@smtp.nue.novell.com>
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, david.vrabel@citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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

On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
>> --- a/xen/include/public/arch-x86/xen.h
>> +++ b/xen/include/public/arch-x86/xen.h
>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>       /* Frame containing list of mfns containing list of mfns containing p2m. */
>>       xen_pfn_t     pfn_to_mfn_frame_list_list;
>>       unsigned long nmi_reason;
>> -    uint64_t pad[32];
>> +    /*
>> +     * Following two fields are valid if pfn_to_mfn_frame_list_list contains
>> +     * ~0UL.
>> +     */
>> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
>> +    unsigned long p2m_as_root;  /* mfn of the top level page table */
>
> xen_pfn_t please. And what does the "as" in the name stand for?

"as" is address space. I can rename it to e.g. "p2m_pgd_mfn".

> It's also kind of unclear in the description what "the page table root"
> is, as I don't think there are many OSes which use just a single set
> of page tables (i.e. just a single address space). Not having followed
> the discussion closely - what is this needed for anyway?

It's a replacement of the pfn_to_mfn_frame_list_list using the same
page table as the kernel for accessing the p2m list. We need the root
of the page table and the virtual address of the p2m list.

>
>> --- a/xen/include/public/features.h
>> +++ b/xen/include/public/features.h
>> @@ -99,6 +99,9 @@
>>   #define XENFEAT_grant_map_identity        12
>>    */
>>
>> +/* x86: guest may specify virtual address of p2m list */
>> +#define XENFEAT_virtual_p2m               13
>
> The name to me suggests something that's not real. Perhaps better
> XENFEAT_virtually_mapped_p2m or XENFEAT_p2m_va{,ddr}?

Yeah, that's better. I'll use XENFEAT_p2m_vaddr.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5R-0007Kt-Rz; Fri, 21 Nov 2014 13:17: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 1Xro5P-0007Ib-Pv
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:19 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	79/89-02696-F5B3F645; Fri, 21 Nov 2014 13:17:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29677 invoked from network); 21 Nov 2014 13:17:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695934"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:15 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5K-0003Au-91;
	Fri, 21 Nov 2014 13:17:15 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:59 +0000
Message-ID: <1416575824-15555-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 10/15] Osstest/Debian: support adding
	a rootdelay property to bootargs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

arndale appears to be quite slow (and asynchronous) at finding it's scsi
controller. rootdelay=3 seems to do the trick.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 Osstest/Debian.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8b70442..bdbb55d 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -694,9 +694,11 @@ END
 	my @bootargs;
 
 	my $root=target_guest_lv_name($ho,"root");
+	my $rootdelay=get_host_property($ho, "rootdelay");
 	my $console=get_host_native_linux_console($ho);
 
 	push @bootargs, "root=$root";
+	push @bootargs, "rootdelay=$rootdelay" if $rootdelay;
 	push @bootargs, "console=$console" unless $console eq "NONE";
 
 	my $bootargs = join ' ', @bootargs;
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5N-0007Hd-8Z; Fri, 21 Nov 2014 13:17:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5L-0007GT-Qw
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:15 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	52/0D-02698-B5B3F645; Fri, 21 Nov 2014 13:17:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4854 invoked from network); 21 Nov 2014 13:17:14 -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;
	21 Nov 2014 13:17:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229167"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:13 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5I-0003Al-5H;
	Fri, 21 Nov 2014 13:17:13 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:12 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:57 +0000
Message-ID: <1416575824-15555-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 08/15] Osstest/Debian: Support for
	loading an FDT from u-boot 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

The currently supported platform provides an FDT preloaded at 0x1000. Replace
this with ${fdt_addr} (which the current platform exposes) and for platforms
which do not provide an fdt arrange to load the relevant file as named in the
${fdtfile} (which is conventionally provided by u-boot for platforms which need
this).

Drop some random memory clearing rune, I've no idea what the intended purpose
was, 0x800000 doesn't correspond to any $foo_addr_r on the midway systems for
example.

Also get rid of the scsi scan which must necessarily have already happened
(since the boot.scr itselfs lives on a scsi drive).

Lastly, add some echos to show progress through the script, as an aid to
debugging.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v2: Refactor uboot dtb loading scriptlet, which previously appeared twice
---
 Osstest/Debian.pm | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 1b4d7a7..9530aa4 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -114,6 +114,15 @@ sub bl_getmenu_open ($$$) {
     return $f;
 }
 
+sub uboot_scr_load_dtb () {
+    return <<'END';
+if test -z "\${fdt_addr}" && test -n "\${fdtfile}" ; then
+    echo Loading dtbs/\${fdtfile}
+    ext2load scsi 0 \${fdt_addr_r} dtbs/\${fdtfile}
+    setenv fdt_addr \${fdt_addr_r}
+fi
+END
+}
 sub setupboot_uboot ($$$) {
     my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
     my $bl= { };
@@ -132,6 +141,8 @@ sub setupboot_uboot ($$$) {
 
 	my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', '');
 
+	my $load_dtb = uboot_scr_load_dtb();
+
 	target_cmd_root($ho, <<END);
 if test ! -f /boot/$kern ; then
     exit 1
@@ -143,9 +154,7 @@ cp -n /boot/boot.scr /boot/boot.scr.bak
 xen=`readlink /boot/$xen`
 
 cat >/boot/boot <<EOF
-
-mw.l 800000 0 10000
-scsi scan
+${load_dtb}
 
 fdt addr \\\${fdt_addr}
 fdt resize
@@ -692,6 +701,8 @@ END
 
 	my $bootargs = join ' ', @bootargs;
 
+	my $load_dtb = uboot_scr_load_dtb();
+
 	preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
 set -ex
@@ -703,11 +714,13 @@ initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
 cat >\$r/boot/boot <<EOF
 setenv bootargs $bootargs
-mw.l 800000 0 10000
-scsi scan
+${load_dtb}
+echo Loading \$kernel
 ext2load scsi 0 \\\${kernel_addr_r} \$kernel
+echo Loading \$initrd
 ext2load scsi 0 \\\${ramdisk_addr_r} \$initrd
-bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} 0x1000
+echo Booting
+bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr}
 EOF
 
 in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5L-0007Gt-Su; Fri, 21 Nov 2014 13:17:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5K-0007GL-PR
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:14 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	68/B9-02699-A5B3F645; Fri, 21 Nov 2014 13:17:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29045 invoked from network); 21 Nov 2014 13:17:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695895"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:12 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5H-0003Ai-44;
	Fri, 21 Nov 2014 13:17:12 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:56 +0000
Message-ID: <1416575824-15555-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 07/15] Osstest/Debian: Install dtbs
	into target filesystem in /boot/dtbs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 done whenever dtbs.tar.gz exists. mg-debian-installer-update produces
the necessary inputs on the relevant platform (armhf).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: More careful check/stat for existence of dtbs.tar.gz
v2: Install dtbs iff dtbs.tar.gz exists.
---
 Osstest/Debian.pm | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 33a4ca4..1b4d7a7 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -20,6 +20,8 @@ package Osstest::Debian;
 use strict;
 use warnings;
 
+use POSIX;
+
 use IO::File;
 use File::Copy;
 
@@ -514,6 +516,9 @@ sub preseed_create ($$;@) {
     my $disk= $xopts{DiskDevice} || '/dev/sda';
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
+    my $d_i= $ho->{Tftp}{Path}.'/'.$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.
+	$c{TftpDiVersion}.'-'.$ho->{Suite};
+
     my $hostsq= $dbh_tests->prepare(<<END);
         SELECT val FROM runvars
          WHERE flight=? AND name LIKE '%host'
@@ -627,12 +632,29 @@ $overlays
 echo latecmd done.
 END
 
+    my $dtbs = "$d_i/dtbs.tar.gz";
+    if (!stat $dtbs) {
+        $!==&ENOENT or die "dtbs $!";
+    } elsif (-e _) {
+	my $durl = create_webfile($ho, "dtbs", sub {
+	    copy("$d_i/dtbs.tar.gz", $_[0])
+		or die "Copy dtbs failed: $!";
+	});
+	preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+r=/target
+
+wget -O \$r/tmp/dtbs.tar.gz $durl
+
+in-target tar -C /boot -xaf /tmp/dtbs.tar.gz
+END
+    }
+
     foreach my $kp (keys %{ $ho->{Flags} }) {
 	$kp =~ s/need-kernel-deb-// or next;
 
-	my $d_i= $ho->{Tftp}{Path}.'/'.$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.
-	    $c{TftpDiVersion}.'-'.$ho->{Suite};
-
 	my $kurl = create_webfile($ho, "kernel", sub {
 	    copy("$d_i/$kp.deb", $_[0])
 		or die "Copy kernel failed: $!";
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5H-0007Fg-Ts; Fri, 21 Nov 2014 13:17:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5G-0007FU-3v
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:10 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	C7/57-02696-55B3F645; Fri, 21 Nov 2014 13:17:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28574 invoked from network); 21 Nov 2014 13:17:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695869"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:07 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5B-0003AT-Rn;
	Fri, 21 Nov 2014 13:17:06 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:51 +0000
Message-ID: <1416575824-15555-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 02/15] ts-kernel-build: enable
	CONFIG_IKCONFIG{_PROC}
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This makes the kernel's .config available in /proc/config.gz and embeds a copy
which can be extracted with linux/scripts/extract-ikconfig (which I've not
tried, but have no reason to doubt).

Having this around can be handy with an older osstest installed test box and to
confirm you've booted the kernel you think you have when you are messing with
.config options.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-kernel-build | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ts-kernel-build b/ts-kernel-build
index 3b48920..f02205f 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -436,6 +436,9 @@ setopt CONFIG_MIGRATION n
 
 setopt CONFIG_ACPI_HOTPLUG_MEMORY n
 
+setopt CONFIG_IKCONFIG y
+setopt CONFIG_IKCONFIG_PROC y
+
 # Should all be set one way or another in defconfig but aren't
 setopt CONFIG_NUMA n
 setopt CONFIG_X86_VSMP n
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5P-0007If-Km; Fri, 21 Nov 2014 13:17:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5O-0007IA-HM
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:18 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	EA/BD-02954-D5B3F645; Fri, 21 Nov 2014 13:17:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4908 invoked from network); 21 Nov 2014 13:17:15 -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;
	21 Nov 2014 13:17:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229168"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:13 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5F-0003Ad-1d;
	Fri, 21 Nov 2014 13:17:10 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:54 +0000
Message-ID: <1416575824-15555-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 05/15] Osstest/PDU: Add eth008.pm
	method to control the ARM rack PDU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This controls the eth008 relay board: http://www.robot-electronics.co.uk/htm/eth008tech.htm

Due to the use of the CGI interface this requires firmware version 4+.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Use LWP::UserAgent
v2: Pass username and password via a netrc file.
---
 Osstest/PDU/eth008.pm | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)
 create mode 100644 Osstest/PDU/eth008.pm

diff --git a/Osstest/PDU/eth008.pm b/Osstest/PDU/eth008.pm
new file mode 100644
index 0000000..fc5fa96
--- /dev/null
+++ b/Osstest/PDU/eth008.pm
@@ -0,0 +1,65 @@
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2014 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+package Osstest::PDU::eth008;
+
+use strict;
+use warnings;
+
+use Osstest;
+use Osstest::TestSupport;
+use LWP::UserAgent;
+
+BEGIN {
+    use Exporter ();
+    our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
+    $VERSION     = 1.00;
+    @ISA         = qw(Exporter);
+    @EXPORT      = qw();
+    %EXPORT_TAGS = ( );
+
+    @EXPORT_OK   = qw();
+}
+
+sub new {
+    my ($class, $ho, $methname, $pdu, $user, $pass, $port, @opts) = @_;
+    return bless { Host => $ho,
+		   PDU => $pdu,
+		   User => $user,
+		   Pass => $pass,
+		   Port => $port,
+		   Opts => \@opts }, $class;
+}
+
+sub pdu_power_state {
+    my ($mo, $on) = @_;
+    my $op= $on ? "DOA" : "DOI"; # Digital Output (In)Active
+
+    # Use the CGI interface since it is less prone to being firewalled
+    # off, unlike the standard interface on port 17494. This is only
+    # available from firmware v4 onwards.
+
+    my $ua = LWP::UserAgent->new;
+
+    $ua->credentials("$mo->{PDU}:80", "Protected", $mo->{User}, $mo->{Pass});
+
+    my $resp = $ua->get("http://$mo->{PDU}/io.cgi?$op$mo->{Port}=0");
+
+    die "failed" unless $resp->is_success;
+    logm($resp->decoded_content);
+}
+
+1;
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5J-0007G7-LJ; Fri, 21 Nov 2014 13:17:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5H-0007Fe-Ry
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:12 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	F1/CD-02702-65B3F645; Fri, 21 Nov 2014 13:17:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4408 invoked from network); 21 Nov 2014 13:17:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229121"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:08 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5C-0003AW-Sp;
	Fri, 21 Nov 2014 13:17:07 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:52 +0000
Message-ID: <1416575824-15555-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 03/15] Add simple helper to update DI
	for all architectures.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Uses DebianNonfreeFirmware, even (especially) for production, so move the
README stanza out of standalone only section. The current default matches what
is in the current production versions of DI.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 README                         | 16 ++++++++--------
 mg-debian-installer-update-all | 31 +++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+), 8 deletions(-)
 create mode 100755 mg-debian-installer-update-all

diff --git a/README b/README
index 1226369..3fe5ecc 100644
--- a/README
+++ b/README
@@ -360,14 +360,6 @@ DebianPreseed
    but you will need to set some NTP servers here if your firewall
    doesn't permit NTP to Debian's pool.ntp.org servers.
 
-DebianNonfreeFirmware
-  List of debs of non-free firmware to include in the massaged
-  debian-installer.  You will need this if you want to use network
-  card which requires non-free firmware.  The default is just
-  "firmware-bnx2'.  If your host operating system doesn't have
-  grep-dctrl (for example because it's not Debian) then you must set
-  this to the empty string, by writing  DebianNonfreeFirmware=''
-
 ========================================
 
 Config settings relevant only to standalone mode
@@ -420,6 +412,14 @@ GuestDebianSuite   defaults to DebianSuite
 
 DebianPreseed      added to existing preseed file
 
+DebianNonfreeFirmware
+  List of debs of non-free firmware to include in the massaged
+  debian-installer.  You will need this if you want to use network
+  card which requires non-free firmware.  The default is just
+  "firmware-bnx2'.  If your host operating system doesn't have
+  grep-dctrl (for example because it's not Debian) then you must set
+  this to the empty string, by writing  DebianNonfreeFirmware=''
+
 TftpFoo_<scope> and TftpFoo
 
     Describes various properties relating to Tftp in a given <scope>,
diff --git a/mg-debian-installer-update-all b/mg-debian-installer-update-all
new file mode 100755
index 0000000..eca4a5f
--- /dev/null
+++ b/mg-debian-installer-update-all
@@ -0,0 +1,31 @@
+#!/bin/bash
+# usage
+#   ./mg-debian-installer-update-all
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2015 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+set -e
+
+. cri-getconfig
+
+suite=`getconfig DebianSuite`
+fws=`getconfig DebianNonfreeFirmware`
+arches="armhf amd64 i386"
+
+for arch in $arches ; do
+    ./mg-debian-installer-update $suite $arch $fws
+done
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5I-0007Fr-9U; Fri, 21 Nov 2014 13:17:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5G-0007FZ-RD
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:11 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B8/57-02696-55B3F645; Fri, 21 Nov 2014 13:17:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28202 invoked from network); 21 Nov 2014 13:17:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695861"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:06 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5A-0003AR-Qa;
	Fri, 21 Nov 2014 13:17:05 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:50 +0000
Message-ID: <1416575824-15555-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 01/15] standalone: Introduce
	"HostGroups" for use in OSSTEST_CONFIG
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This saves repeating identical HostProp and HostFlags for sets of identical
machines. e.g.

    HostGroupProp_cubietruck_LinuxSerialConsole ttyS0
    HostGroupProp_cubietruck_Build_Make_Flags -j12
    HostGroupProp_cubietruck_XenSerialConsole dtuart
    HostGroupProp_cubietruck_XenDTUARTPath /soc@01c00000/serial@01c28000
    HostGroupFlags_cubietruck suite-wheezy,equiv-cubietruck,need-kernel-deb-armmp,no-di-kernel,need-uboot-bootscr

    HostGroup_braque cubietruck
    HostProp_braque_Fqdn braque.uk.xensource.com

    HostGroup_picaso cubietruck
    HostProp_picaso_Fqdn picaso.uk.xensource.com

    HostGroup_metzinger cubietruck
    HostProp_metzinger metzinger.uk.xensource.com

    HostGroup_gleizes cubietruck
    HostProp_gleizes_Fqdn gleizes.uk.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Simplify lookup of HostGroup_FOO
v2: Set HostGroup props after DB
    Clarify docs
---
 Osstest/HostDB/Static.pm |  2 ++
 Osstest/TestSupport.pm   | 17 ++++++++++++++++-
 README                   | 22 ++++++++++++++++++++++
 3 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/Osstest/HostDB/Static.pm b/Osstest/HostDB/Static.pm
index d0c13a1..ad18395 100644
--- a/Osstest/HostDB/Static.pm
+++ b/Osstest/HostDB/Static.pm
@@ -58,6 +58,8 @@ sub get_flags ($$) { #method
     };
 
     $process->('HostFlags');
+    $process->("HostGroupFlags_$ho->{Properties}{HostGroup}")
+	if $ho->{Properties}{HostGroup};
     $process->("HostFlags_$ho->{Name}");
 
     return $flags;
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 46b6720..a3b6936 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -767,7 +767,13 @@ sub selecthost ($) {
 	$ho->{Properties}{$pn} = $val;
     };
 
-    # First, we use the config file's general properites as defaults
+    # First, set the prop group if any.
+    if ( $c{"HostGroup_${name}"} ) {
+	$setprop->("HostGroup", $c{"HostGroup_${name}"});
+	logm("Host $name is in HostGroup $ho->{Properties}{HostGroup}");
+    }
+
+    # Next, we use the config file's general properites as defaults
     foreach my $k (keys %c) {
 	next unless $k =~ m/^HostProp_([A-Z].*)$/;
 	$setprop->($1, $c{$k});
@@ -776,6 +782,15 @@ sub selecthost ($) {
     # Then we read in the HostDB's properties
     $mhostdb->get_properties($name, $ho->{Properties});
 
+    # Next, we set any HostGroup based properties
+    if ( $ho->{Properties}{HostGroup} ) {
+	foreach my $k (keys %c) {
+	    next unless $k =~ m/^HostGroupProp_([-a-z0-9]+)_(.*)$/;
+	    next unless $1 eq $ho->{Properties}{HostGroup};
+	    $setprop->($2, $c{$k});
+	}
+    }
+
     # Finally, we override any host-specific properties from the config
     foreach my $k (keys %c) {
 	next unless $k =~ m/^HostProp_([-a-z0-9]+)_(.*)$/;
diff --git a/README b/README
index 9a85549..1226369 100644
--- a/README
+++ b/README
@@ -333,6 +333,28 @@ HostProp_<testbox>_TftpScope
    Defines the Tftp scope (i.e. subnet) where this host resides. See
    "TftpFoo_<scope> and TftpFoo" below.
 
+HostFlags_<testbox>
+   Defines a set of flags for the host. Flags is a list separated by
+   whitespace, comma or semi-colon. A flag can be unset by prepending
+   a !. Only used in standalone mode.
+
+HostGroup_<testbox> <group>
+   Defines a group of similar hosts of which <testbox> is a
+   member. This can then be used with HostGroupProp and HostGroupFlags
+
+HostGroupProps_<group>_<prop>
+   Equivalent to writing HostProp_<testbox>_<prop> for every testbox
+   which declares HostGroup_<testbox>_<group>. Allows setting a set of
+   common properties for a group of similar machines. These settings
+   take precedence over the database provided settings, but are
+   themselves overridden by host-specific properties.
+
+HostGroupFlags_<group>
+   Equivalent to writing HostFlags_<testbox> for every testbox which
+   declares HostGroup_<testbox>_<group>. Allows setting a set of
+   common flags for a group of similar machines. These flags are
+   merged with the host specific flags. Only used in standalone mode.
+
 DebianPreseed
    Text to add to the debian-installer preseed file.  Optional
    but you will need to set some NTP servers here if your firewall
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5L-0007GQ-BU; Fri, 21 Nov 2014 13:17:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5J-0007G2-FW
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:13 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	43/06-27785-85B3F645; Fri, 21 Nov 2014 13:17:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4592 invoked from network); 21 Nov 2014 13:17:12 -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;
	21 Nov 2014 13:17:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229136"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:11 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5G-0003Af-2r;
	Fri, 21 Nov 2014 13:17:11 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:10 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:55 +0000
Message-ID: <1416575824-15555-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 06/15] Osstest/Debian: Refactor code
	to set bootargs in u-boot 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 Osstest/Debian.pm | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..33a4ca4 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -660,9 +660,15 @@ END
     }
 
     if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
+	my @bootargs;
+
 	my $root=target_guest_lv_name($ho,"root");
-	my $console = get_host_native_linux_console($ho);
-	my $consolecmd = "console=$console" unless $console eq "NONE";
+	my $console=get_host_native_linux_console($ho);
+
+	push @bootargs, "root=$root";
+	push @bootargs, "console=$console" unless $console eq "NONE";
+
+	my $bootargs = join ' ', @bootargs;
 
 	preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
@@ -674,7 +680,7 @@ kernel=`readlink \$r/vmlinuz | sed -e 's|boot/||'`
 initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
 cat >\$r/boot/boot <<EOF
-setenv bootargs $consolecmd root=$root
+setenv bootargs $bootargs
 mw.l 800000 0 10000
 scsi scan
 ext2load scsi 0 \\\${kernel_addr_r} \$kernel
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5Y-0007TB-02; Fri, 21 Nov 2014 13:17:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5V-0007Pk-Tj
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:26 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	19/75-24124-56B3F645; Fri, 21 Nov 2014 13:17:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416575843!7267635!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25897 invoked from network); 21 Nov 2014 13:17:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695994"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:21 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5P-0003BF-OX;
	Fri, 21 Nov 2014 13:17:20 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:19 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:04 +0000
Message-ID: <1416575824-15555-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 15/15] Debian: Create boot.scr with a
	suffix and copy to boot.scr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This ensures that we always have a boot script to boot at least the native
Debian kernel and Xen available, even after multiple iterations of
installation, which is handy when debugging a system.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Debian.pm | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 82669a5..18586fc 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -152,12 +152,12 @@ if test ! -f /boot/$kern ; then
     exit 1
 fi
 # Save a copy of the original
-cp -n /boot/boot /boot/boot.bak
-cp -n /boot/boot.scr /boot/boot.scr.bak
+cp -n /boot/boot.xen /boot/boot.xen.bak
+cp -n /boot/boot.scr.xen /boot/boot.scr.xen.bak
 
 xen=`readlink /boot/$xen`
 
-cat >/boot/boot <<EOF
+cat >/boot/boot.xen <<EOF
 ${load_dtb}
 
 fdt addr \\\${fdt_addr}
@@ -194,7 +194,8 @@ fdt print /chosen
 echo Booting \\\${xen_addr_r} - \\\${fdt_addr}
 bootz \\\${xen_addr_r} - \\\${fdt_addr}
 EOF
-mkimage -A arm -T script -d /boot/boot /boot/boot.scr
+mkimage -A arm -T script -d /boot/boot.xen /boot/boot.scr.xen
+cp /boot/boot.scr.xen /boot/boot.scr
 END
     };
 
@@ -716,7 +717,7 @@ r=/target #/
 kernel=`readlink \$r/vmlinuz | sed -e 's|boot/||'`
 initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
-cat >\$r/boot/boot <<EOF
+cat >\$r/boot/boot.deb <<EOF
 setenv bootargs $bootargs
 ${load_dtb}
 echo Loading \$kernel
@@ -727,7 +728,8 @@ echo Booting
 bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr}
 EOF
 
-in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr
+in-target mkimage -A arm -T script -d /boot/boot.deb /boot/boot.scr.deb
+in-target cp /boot/boot.scr.deb /boot/boot.scr
 END
     }
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5U-0007OQ-Hx; Fri, 21 Nov 2014 13:17:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5S-0007Kz-CW
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:22 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	50/52-02953-16B3F645; Fri, 21 Nov 2014 13:17:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5479 invoked from network); 21 Nov 2014 13:17:21 -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;
	21 Nov 2014 13:17:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229215"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:20 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5O-0003B9-NN;
	Fri, 21 Nov 2014 13:17:19 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:03 +0000
Message-ID: <1416575824-15555-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 14/15] ts-kernel-build: Adjust kernel
	.config to work on the arndale boards.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Various drivers are missing from multi_v7_defconfig in v3.16, also some drivers
which don't play nice are enabled by default, so remove them.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: This is a more extensive version of "ts-kernel-build: Enable
CONFIG_PHY_EXYNOS5250_SATA". Ian acked that but this does a lot more so I've
dropped it.
---
 ts-kernel-build | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/ts-kernel-build b/ts-kernel-build
index f02205f..b2f19cf 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -171,6 +171,41 @@ setopt CONFIG_BLK_DEV_NBD y
 # At least with Linux 3.4.77 on wheezy, the nbd module is
 # not loaded automatically.
 
+# Enabling Exynos4 forces wierd CONFIG_HZ==200, and we don't
+# support that platform anyway.
+setopt CONFIG_ARCH_EXYNOS4 n
+
+# Having these on breaks USB
+setopt CONFIG_SAMSUNG_USB2PHY n
+setopt CONFIG_SAMSUNG_USB3PHY n
+
+# These cause i2c bus timeout errors on boot.
+# https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/f1DW9NcSPVU?
+# http://patchwork.ozlabs.org/patch/337812/
+setopt CONFIG_SENSORS_LM90 n
+setopt CONFIG_ICS932S401 n
+
+# Enable some additional drivers for Arndale.
+setopt CONFIG_PHY_EXYNOS5250_SATA m
+setopt CONFIG_USB_EHCI_EXYNOS m
+setopt CONFIG_USB_OHCI_EXYNOS m
+setopt CONFIG_USB_HSIC_USB3503 m
+setopt CONFIG_USB_DWC3 m
+setopt CONFIG_USB_DWC3_HOST y
+setopt CONFIG_USB_DWC3_EXYNOS m
+setopt CONFIG_USB_DWC3_PCI n
+setopt CONFIG_PHY_SAMSUNG_USB2 m
+setopt CONFIG_PHY_EXYNOS5250_USB2 y
+setopt CONFIG_PHY_EXYNOS5_USBDRD m
+setopt CONFIG_RTC_DRV_S5M y
+setopt CONFIG_COMMON_CLK_S2MPS11 m
+setopt CONFIG_I2C_S3C2410 y
+setopt CONFIG_MMC_DW m
+setopt CONFIG_MMC_DW_EXYNOS m
+setopt CONFIG_REGULATOR_S5M8767 m
+
+####
+
 END
 
 our $config_features= <<END;
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5U-0007Nr-3k; Fri, 21 Nov 2014 13:17:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5S-0007Kq-3d
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:22 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	76/CB-20609-16B3F645; Fri, 21 Nov 2014 13:17:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!8
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29842 invoked from network); 21 Nov 2014 13:17:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695965"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:19 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5N-0003B4-Ek;
	Fri, 21 Nov 2014 13:17:18 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:17 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:02 +0000
Message-ID: <1416575824-15555-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 13/15] Osstest/Debian: Add 0x prefix
	to $filesize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret
it properly. See http://lists.denx.de/pipermail/u-boot/2014-October/193622.html

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Reference ML thread.
v2: New patch, previously included in "Osstest/Debian: Workaround oddities in
    the u-boot script parser.". Note that the oddities with requiring a space
    before the ">" is no longer reproducible with the latest u-boot.
---
 Osstest/Debian.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 3e56c1f..82669a5 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -177,7 +177,7 @@ echo command line: \\\${bootargs}
 ext2load scsi 0 \\\${kernel_addr_r} $kern
 fdt mknod /chosen module\@0
 fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module"
-fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} \\\${filesize}>
+fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} 0x\\\${filesize}>
 # clk_ignore_unused is due to http://bugs.xenproject.org/xen/bug/45
 fdt set /chosen/module\@0 bootargs "$xenkopt ro root=$root clk_ignore_unused"
 echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize})
@@ -186,7 +186,7 @@ echo command line: $xenkopt ro root=$root
 ext2load scsi 0 \\\${ramdisk_addr_r} $initrd
 fdt mknod /chosen module\@1
 fdt set /chosen/module\@1 compatible "xen,linux-initrd" "xen,multiboot-module"
-fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} \\\${filesize}>
+fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} 0x\\\${filesize}>
 echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize})
 
 fdt print /chosen
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5Q-0007JV-EL; Fri, 21 Nov 2014 13:17:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5P-0007IO-5x
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:19 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	35/ED-02702-E5B3F645; Fri, 21 Nov 2014 13:17:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29562 invoked from network); 21 Nov 2014 13:17:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695923"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:14 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5J-0003Ap-7r;
	Fri, 21 Nov 2014 13:17:14 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:13 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:58 +0000
Message-ID: <1416575824-15555-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 09/15] Osstest/Debian: Add support
	for "ExtraInitramfsModules" host property
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 arndale platform needs a bunch of clk, phy and regulator stuff in order to
access its root filesystem. However mkinitramfs is not (currently?) able to
figure this out and therefore doesn't include them in the initrd. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762042

Add a new host prop which can list these required additional module and
arranges for a suitable /etc/initramfs-tools/modules to be created on install.

Using the new HostGroupProp syntax the required modules are:

HostGroupProp_arndale_ExtraInitramfsModules clk-s2mps11 s5m8767 i2c-s3c2410 phy-exynos5250-sata

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v2: References to bugs.
---
 Osstest/Debian.pm | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 9530aa4..8b70442 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -727,6 +727,23 @@ in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr
 END
     }
 
+    my $modules = get_host_property($ho, "ExtraInitramfsModules", "NONE");
+    if ( $modules ne "NONE" )
+    {
+	# This is currently the best available way to add modules to
+	# the installed initramfs. See
+	# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764805
+        preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+for i in $modules ; do
+    echo \$i >> /target/etc/initramfs-tools/modules
+done
+in-target update-initramfs -u -k all
+END
+    }
+
     my @extra_packages = ();
     push(@extra_packages, "u-boot-tools") if $ho->{Flags}{'need-uboot-bootscr'};
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5J-0007GE-WC; Fri, 21 Nov 2014 13:17:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5I-0007Ff-3N
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:12 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	5D/7C-02699-75B3F645; Fri, 21 Nov 2014 13:17:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28734 invoked from network); 21 Nov 2014 13:17:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695882"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:09 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5D-0003AZ-Tv;
	Fri, 21 Nov 2014 13:17:08 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:53 +0000
Message-ID: <1416575824-15555-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 04/15] make-flight: Run a basic test
	on each arm platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Unlike x86 there is enough variation in the ARM platforms that it is worth
having a basic test on each as part of a standard run. This relies on each host
having an appropriate platform-$platform host flag.

The existing test-ARCH-ARCH-xl test is retained as a floating test, while a new
variant is added for each distinct platform present in the hostdb which is tied
to that platform type. The intention is that only arm platforms will have
platforms at first, although perhaps platform-intel and platform-amd could be
added in the future too.

There are currently no platform-* flags in the hostdb, so tested with
s/platform-/equiv-/ and:

  ( set -ex ;
    source ./cri-getplatforms ;
    blessing=real ;
    export OSSTEST_CONFIG=production-config ;
    for p in '' `getplatforms "armhf"` ; do
      set +x ;
      echo PLATFORM: $p ;
    done
  )
which prints:
  PLATFORM:
  PLATFORM: marilith
and with s/armhf/amd64/:
  PLATFORM:
  PLATFORM: rackservers-s40670
  PLATFORM: r310-moth
  PLATFORM: rackservers-s40680
  PLATFORM: dell-r310
  PLATFORM: rackservers-s40679
  PLATFORM: rackservers-s40663
  PLATFORM: rackservers-q21011

Also tested in standalone mode with a ~/.xen-osstest/config containing:

  PlatformsArmhf midway cubietruck arndale

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
v3:
    Split /\s+/
---
v2:
    Use platform-* prop not equiv-*
    Select platforms from host db
---
 Osstest/HostDB/Executive.pm | 28 ++++++++++++++++++++++++++++
 Osstest/HostDB/Static.pm    |  9 +++++++++
 README                      |  3 +++
 cri-getplatforms            | 25 +++++++++++++++++++++++++
 make-flight                 |  9 +++++++--
 5 files changed, 72 insertions(+), 2 deletions(-)
 create mode 100755 cri-getplatforms

diff --git a/Osstest/HostDB/Executive.pm b/Osstest/HostDB/Executive.pm
index b2c8dc9..6257829 100644
--- a/Osstest/HostDB/Executive.pm
+++ b/Osstest/HostDB/Executive.pm
@@ -67,6 +67,34 @@ END
     return $flags;
 }
 
+sub get_arch_platforms ($$) {
+    my ($hd, $blessing, $arch) = @_;
+
+    my @plats = ( );
+    my $platsq = $dbh_tests->prepare(<<END);
+SELECT DISTINCT hostflag
+           FROM hostflags h0
+   WHERE EXISTS (
+       SELECT *
+         FROM hostflags h1, hostflags h2
+        WHERE h0.hostname = h1.hostname AND h1.hostname = h2.hostname
+          AND h1.hostflag = ?
+          AND h2.hostflag = ?
+   )
+   AND hostflag like 'platform-%';
+END
+
+    $platsq->execute("blessed-$blessing", "arch-$arch");
+
+    while (my ($plat) = $platsq->fetchrow_array()) {
+	$plat =~ s/^platform-//g or die;
+	push @plats, $plat;
+    }
+
+    $platsq->finish();
+    return @plats;
+}
+
 sub default_methods ($$) {
     my ($hd, $ho) = @_;
 
diff --git a/Osstest/HostDB/Static.pm b/Osstest/HostDB/Static.pm
index ad18395..60f5d3c 100644
--- a/Osstest/HostDB/Static.pm
+++ b/Osstest/HostDB/Static.pm
@@ -65,6 +65,15 @@ sub get_flags ($$) { #method
     return $flags;
 }
 
+sub get_arch_platforms ($$) {
+    my ($hd, $blessing, $arch) = @_;
+
+    my $prop = "Platforms".ucfirst($arch);
+
+    return split /\s+/, $c{$prop} if $c{$prop};
+    return () unless $c{$prop};
+}
+
 sub default_methods ($$) { #method
     my ($hd, $ho) = @_;
 
diff --git a/README b/README
index 3fe5ecc..35532b7 100644
--- a/README
+++ b/README
@@ -395,6 +395,9 @@ The keys in ~/.ssh/id_{rsa,dsa}.pub and ~/.ssh/authorized_keys
 
 TestHostKeypairPath
 
+Platforms<Arch>
+   List of platforms (i.e. distinct host types) to run a basic test on.
+
 HostProp_GenEtherPrefixBase 5e:36:0e:f5
 # 	                               :00:01 guest number in job appended
 #            in standalone jobdb, ^^^^^ xor'd with low 16 bits of your uid
diff --git a/cri-getplatforms b/cri-getplatforms
new file mode 100755
index 0000000..067730c
--- /dev/null
+++ b/cri-getplatforms
@@ -0,0 +1,25 @@
+# -*- bash -*-
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2014 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+getplatforms () {
+        perl -e '
+                use Osstest;
+                csreadconfig();
+                print join " ", $mhostdb->get_arch_platforms("'$blessing'", "'$1'") or die $!;
+        '
+}
diff --git a/make-flight b/make-flight
index 9963a46..0814eba 100755
--- a/make-flight
+++ b/make-flight
@@ -27,6 +27,7 @@ buildflight=$4
 flight=`./cs-flight-create $blessing $branch`
 
 . cri-common
+. cri-getplatforms
 . ap-common
 . mfi-common
 
@@ -284,10 +285,14 @@ do_passthrough_tests () {
 test_matrix_do_one () {
 
   # Basic PV Linux test with xl
+  for platform in '' `getplatforms $xenarch` ; do
+    suffix=${platform:+-$platform}
+    hostflags=${most_hostflags}${platform:+,platform-$platform}
 
-  job_create_test test-$xenarch$kern-$dom0arch-xl test-debian xl \
+    job_create_test test-$xenarch$kern-$dom0arch-xl$suffix test-debian xl \
             $xenarch $dom0arch                                   \
-            $debian_runvars all_hostflags=$most_hostflags
+            $debian_runvars all_hostflags=$hostflags
+  done
 
   job_create_test test-$xenarch$kern-$dom0arch-libvirt test-debian libvirt \
             $xenarch $dom0arch                                       \
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5Q-0007J5-1y; Fri, 21 Nov 2014 13:17:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5P-0007IL-4D
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:19 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	4A/49-02576-E5B3F645; Fri, 21 Nov 2014 13:17:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5222 invoked from network); 21 Nov 2014 13:17:17 -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;
	21 Nov 2014 13:17:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229198"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:16 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5L-0003Ay-Av;
	Fri, 21 Nov 2014 13:17:16 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:00 +0000
Message-ID: <1416575824-15555-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 11/15] Osstest/Debian: Remove
	hardcoded midway specific addresses from boot.scr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This depends on a change to the hostdb to add "0x01000000" as the value of a
new UBootSetXenAddrR property of the midway machines.

Most platforms will need something similar. For both cubietruck and arndale
0x41000000.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Move the property to a specific one like I was supposed to last time
v2: s/go along with/depends on/
---
 Osstest/Debian.pm | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index bdbb55d..0f92661 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -140,9 +140,13 @@ sub setupboot_uboot ($$$) {
 	logm("Linux options: $xenkopt");
 
 	my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', '');
+	my $xen_addr_r = get_host_property($ho, 'UBootSetXenAddrR', undef);
 
 	my $load_dtb = uboot_scr_load_dtb();
 
+	my $set_xen_addr_r =
+	    $xen_addr_r ? "setenv xen_addr_r $xen_addr_r" : "";
+
 	target_cmd_root($ho, <<END);
 if test ! -f /boot/$kern ; then
     exit 1
@@ -160,14 +164,11 @@ fdt addr \\\${fdt_addr}
 fdt resize
 
 ${early_commands}
+${set_xen_addr_r}
 
 fdt set /chosen \\\#address-cells <1>
 fdt set /chosen \\\#size-cells <1>
 
-setenv xen_addr_r 0x01000000
-#   kernel_addr_r=0x02000000
-#  ramdisk_addr_r=0x04000000
-
 ext2load scsi 0 \\\${xen_addr_r} \$xen
 setenv bootargs "$xenhopt"
 echo Loaded \$xen to \\\${xen_addr_r} (\\\${filesize})
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5S-0007LP-Bc; Fri, 21 Nov 2014 13:17:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5R-0007Jr-AO
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:21 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	07/F3-08051-06B3F645; Fri, 21 Nov 2014 13:17:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29775 invoked from network); 21 Nov 2014 13:17:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695954"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:17 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5M-0003B0-CL;
	Fri, 21 Nov 2014 13:17:17 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:16 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:01 +0000
Message-ID: <1416575824-15555-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 12/15] Osstest/Debian: Add
	"clk_ignore_unused" to default 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

dom0 is not aware that some clocks are actually in use (e.g. by the
hypervisor), so this stops the kernel from messing with (specifically,
disabling) those clocks. It's harmless even when not needed.

Really there ought to be some interface to communicate this from Xen to dom0,
or some other mechanism to gate things. See http://bugs.xenproject.org/xen/bug/45

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: More verbiage about why this is done
v2: New patch, previously incorrectly included in "Osstest/Debian: Workaround
    oddities in the u-boot script parser."
---
 Osstest/Debian.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 0f92661..3e56c1f 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -178,7 +178,8 @@ ext2load scsi 0 \\\${kernel_addr_r} $kern
 fdt mknod /chosen module\@0
 fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module"
 fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} \\\${filesize}>
-fdt set /chosen/module\@0 bootargs "$xenkopt ro root=$root"
+# clk_ignore_unused is due to http://bugs.xenproject.org/xen/bug/45
+fdt set /chosen/module\@0 bootargs "$xenkopt ro root=$root clk_ignore_unused"
 echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize})
 echo command line: $xenkopt ro root=$root
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5S-0007LP-Bc; Fri, 21 Nov 2014 13:17:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5R-0007Jr-AO
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:21 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	07/F3-08051-06B3F645; Fri, 21 Nov 2014 13:17:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29775 invoked from network); 21 Nov 2014 13:17:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695954"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:17 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5M-0003B0-CL;
	Fri, 21 Nov 2014 13:17:17 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:16 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:01 +0000
Message-ID: <1416575824-15555-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 12/15] Osstest/Debian: Add
	"clk_ignore_unused" to default 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

dom0 is not aware that some clocks are actually in use (e.g. by the
hypervisor), so this stops the kernel from messing with (specifically,
disabling) those clocks. It's harmless even when not needed.

Really there ought to be some interface to communicate this from Xen to dom0,
or some other mechanism to gate things. See http://bugs.xenproject.org/xen/bug/45

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: More verbiage about why this is done
v2: New patch, previously incorrectly included in "Osstest/Debian: Workaround
    oddities in the u-boot script parser."
---
 Osstest/Debian.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 0f92661..3e56c1f 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -178,7 +178,8 @@ ext2load scsi 0 \\\${kernel_addr_r} $kern
 fdt mknod /chosen module\@0
 fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module"
 fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} \\\${filesize}>
-fdt set /chosen/module\@0 bootargs "$xenkopt ro root=$root"
+# clk_ignore_unused is due to http://bugs.xenproject.org/xen/bug/45
+fdt set /chosen/module\@0 bootargs "$xenkopt ro root=$root clk_ignore_unused"
 echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize})
 echo command line: $xenkopt ro root=$root
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5N-0007Hd-8Z; Fri, 21 Nov 2014 13:17:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5L-0007GT-Qw
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:15 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	52/0D-02698-B5B3F645; Fri, 21 Nov 2014 13:17:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4854 invoked from network); 21 Nov 2014 13:17:14 -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;
	21 Nov 2014 13:17:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229167"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:13 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5I-0003Al-5H;
	Fri, 21 Nov 2014 13:17:13 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:12 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:57 +0000
Message-ID: <1416575824-15555-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 08/15] Osstest/Debian: Support for
	loading an FDT from u-boot 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

The currently supported platform provides an FDT preloaded at 0x1000. Replace
this with ${fdt_addr} (which the current platform exposes) and for platforms
which do not provide an fdt arrange to load the relevant file as named in the
${fdtfile} (which is conventionally provided by u-boot for platforms which need
this).

Drop some random memory clearing rune, I've no idea what the intended purpose
was, 0x800000 doesn't correspond to any $foo_addr_r on the midway systems for
example.

Also get rid of the scsi scan which must necessarily have already happened
(since the boot.scr itselfs lives on a scsi drive).

Lastly, add some echos to show progress through the script, as an aid to
debugging.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v2: Refactor uboot dtb loading scriptlet, which previously appeared twice
---
 Osstest/Debian.pm | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 1b4d7a7..9530aa4 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -114,6 +114,15 @@ sub bl_getmenu_open ($$$) {
     return $f;
 }
 
+sub uboot_scr_load_dtb () {
+    return <<'END';
+if test -z "\${fdt_addr}" && test -n "\${fdtfile}" ; then
+    echo Loading dtbs/\${fdtfile}
+    ext2load scsi 0 \${fdt_addr_r} dtbs/\${fdtfile}
+    setenv fdt_addr \${fdt_addr_r}
+fi
+END
+}
 sub setupboot_uboot ($$$) {
     my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
     my $bl= { };
@@ -132,6 +141,8 @@ sub setupboot_uboot ($$$) {
 
 	my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', '');
 
+	my $load_dtb = uboot_scr_load_dtb();
+
 	target_cmd_root($ho, <<END);
 if test ! -f /boot/$kern ; then
     exit 1
@@ -143,9 +154,7 @@ cp -n /boot/boot.scr /boot/boot.scr.bak
 xen=`readlink /boot/$xen`
 
 cat >/boot/boot <<EOF
-
-mw.l 800000 0 10000
-scsi scan
+${load_dtb}
 
 fdt addr \\\${fdt_addr}
 fdt resize
@@ -692,6 +701,8 @@ END
 
 	my $bootargs = join ' ', @bootargs;
 
+	my $load_dtb = uboot_scr_load_dtb();
+
 	preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
 set -ex
@@ -703,11 +714,13 @@ initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
 cat >\$r/boot/boot <<EOF
 setenv bootargs $bootargs
-mw.l 800000 0 10000
-scsi scan
+${load_dtb}
+echo Loading \$kernel
 ext2load scsi 0 \\\${kernel_addr_r} \$kernel
+echo Loading \$initrd
 ext2load scsi 0 \\\${ramdisk_addr_r} \$initrd
-bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} 0x1000
+echo Booting
+bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr}
 EOF
 
 in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5Q-0007J5-1y; Fri, 21 Nov 2014 13:17:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5P-0007IL-4D
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:19 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	4A/49-02576-E5B3F645; Fri, 21 Nov 2014 13:17:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5222 invoked from network); 21 Nov 2014 13:17:17 -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;
	21 Nov 2014 13:17:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229198"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:16 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5L-0003Ay-Av;
	Fri, 21 Nov 2014 13:17:16 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:00 +0000
Message-ID: <1416575824-15555-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 11/15] Osstest/Debian: Remove
	hardcoded midway specific addresses from boot.scr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This depends on a change to the hostdb to add "0x01000000" as the value of a
new UBootSetXenAddrR property of the midway machines.

Most platforms will need something similar. For both cubietruck and arndale
0x41000000.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Move the property to a specific one like I was supposed to last time
v2: s/go along with/depends on/
---
 Osstest/Debian.pm | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index bdbb55d..0f92661 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -140,9 +140,13 @@ sub setupboot_uboot ($$$) {
 	logm("Linux options: $xenkopt");
 
 	my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', '');
+	my $xen_addr_r = get_host_property($ho, 'UBootSetXenAddrR', undef);
 
 	my $load_dtb = uboot_scr_load_dtb();
 
+	my $set_xen_addr_r =
+	    $xen_addr_r ? "setenv xen_addr_r $xen_addr_r" : "";
+
 	target_cmd_root($ho, <<END);
 if test ! -f /boot/$kern ; then
     exit 1
@@ -160,14 +164,11 @@ fdt addr \\\${fdt_addr}
 fdt resize
 
 ${early_commands}
+${set_xen_addr_r}
 
 fdt set /chosen \\\#address-cells <1>
 fdt set /chosen \\\#size-cells <1>
 
-setenv xen_addr_r 0x01000000
-#   kernel_addr_r=0x02000000
-#  ramdisk_addr_r=0x04000000
-
 ext2load scsi 0 \\\${xen_addr_r} \$xen
 setenv bootargs "$xenhopt"
 echo Loaded \$xen to \\\${xen_addr_r} (\\\${filesize})
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5U-0007OQ-Hx; Fri, 21 Nov 2014 13:17:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5S-0007Kz-CW
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:22 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	50/52-02953-16B3F645; Fri, 21 Nov 2014 13:17:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5479 invoked from network); 21 Nov 2014 13:17:21 -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;
	21 Nov 2014 13:17:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229215"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:20 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5O-0003B9-NN;
	Fri, 21 Nov 2014 13:17:19 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:03 +0000
Message-ID: <1416575824-15555-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 14/15] ts-kernel-build: Adjust kernel
	.config to work on the arndale boards.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Various drivers are missing from multi_v7_defconfig in v3.16, also some drivers
which don't play nice are enabled by default, so remove them.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: This is a more extensive version of "ts-kernel-build: Enable
CONFIG_PHY_EXYNOS5250_SATA". Ian acked that but this does a lot more so I've
dropped it.
---
 ts-kernel-build | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/ts-kernel-build b/ts-kernel-build
index f02205f..b2f19cf 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -171,6 +171,41 @@ setopt CONFIG_BLK_DEV_NBD y
 # At least with Linux 3.4.77 on wheezy, the nbd module is
 # not loaded automatically.
 
+# Enabling Exynos4 forces wierd CONFIG_HZ==200, and we don't
+# support that platform anyway.
+setopt CONFIG_ARCH_EXYNOS4 n
+
+# Having these on breaks USB
+setopt CONFIG_SAMSUNG_USB2PHY n
+setopt CONFIG_SAMSUNG_USB3PHY n
+
+# These cause i2c bus timeout errors on boot.
+# https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/f1DW9NcSPVU?
+# http://patchwork.ozlabs.org/patch/337812/
+setopt CONFIG_SENSORS_LM90 n
+setopt CONFIG_ICS932S401 n
+
+# Enable some additional drivers for Arndale.
+setopt CONFIG_PHY_EXYNOS5250_SATA m
+setopt CONFIG_USB_EHCI_EXYNOS m
+setopt CONFIG_USB_OHCI_EXYNOS m
+setopt CONFIG_USB_HSIC_USB3503 m
+setopt CONFIG_USB_DWC3 m
+setopt CONFIG_USB_DWC3_HOST y
+setopt CONFIG_USB_DWC3_EXYNOS m
+setopt CONFIG_USB_DWC3_PCI n
+setopt CONFIG_PHY_SAMSUNG_USB2 m
+setopt CONFIG_PHY_EXYNOS5250_USB2 y
+setopt CONFIG_PHY_EXYNOS5_USBDRD m
+setopt CONFIG_RTC_DRV_S5M y
+setopt CONFIG_COMMON_CLK_S2MPS11 m
+setopt CONFIG_I2C_S3C2410 y
+setopt CONFIG_MMC_DW m
+setopt CONFIG_MMC_DW_EXYNOS m
+setopt CONFIG_REGULATOR_S5M8767 m
+
+####
+
 END
 
 our $config_features= <<END;
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5L-0007GQ-BU; Fri, 21 Nov 2014 13:17:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5J-0007G2-FW
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:13 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	43/06-27785-85B3F645; Fri, 21 Nov 2014 13:17:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4592 invoked from network); 21 Nov 2014 13:17:12 -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;
	21 Nov 2014 13:17:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229136"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:11 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5G-0003Af-2r;
	Fri, 21 Nov 2014 13:17:11 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:10 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:55 +0000
Message-ID: <1416575824-15555-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 06/15] Osstest/Debian: Refactor code
	to set bootargs in u-boot 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 Osstest/Debian.pm | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..33a4ca4 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -660,9 +660,15 @@ END
     }
 
     if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
+	my @bootargs;
+
 	my $root=target_guest_lv_name($ho,"root");
-	my $console = get_host_native_linux_console($ho);
-	my $consolecmd = "console=$console" unless $console eq "NONE";
+	my $console=get_host_native_linux_console($ho);
+
+	push @bootargs, "root=$root";
+	push @bootargs, "console=$console" unless $console eq "NONE";
+
+	my $bootargs = join ' ', @bootargs;
 
 	preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
@@ -674,7 +680,7 @@ kernel=`readlink \$r/vmlinuz | sed -e 's|boot/||'`
 initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
 cat >\$r/boot/boot <<EOF
-setenv bootargs $consolecmd root=$root
+setenv bootargs $bootargs
 mw.l 800000 0 10000
 scsi scan
 ext2load scsi 0 \\\${kernel_addr_r} \$kernel
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5R-0007Kt-Rz; Fri, 21 Nov 2014 13:17: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 1Xro5P-0007Ib-Pv
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:19 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	79/89-02696-F5B3F645; Fri, 21 Nov 2014 13:17:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29677 invoked from network); 21 Nov 2014 13:17:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695934"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:15 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5K-0003Au-91;
	Fri, 21 Nov 2014 13:17:15 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:59 +0000
Message-ID: <1416575824-15555-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 10/15] Osstest/Debian: support adding
	a rootdelay property to bootargs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

arndale appears to be quite slow (and asynchronous) at finding it's scsi
controller. rootdelay=3 seems to do the trick.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 Osstest/Debian.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8b70442..bdbb55d 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -694,9 +694,11 @@ END
 	my @bootargs;
 
 	my $root=target_guest_lv_name($ho,"root");
+	my $rootdelay=get_host_property($ho, "rootdelay");
 	my $console=get_host_native_linux_console($ho);
 
 	push @bootargs, "root=$root";
+	push @bootargs, "rootdelay=$rootdelay" if $rootdelay;
 	push @bootargs, "console=$console" unless $console eq "NONE";
 
 	my $bootargs = join ' ', @bootargs;
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5U-0007Nr-3k; Fri, 21 Nov 2014 13:17:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5S-0007Kq-3d
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:22 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	76/CB-20609-16B3F645; Fri, 21 Nov 2014 13:17:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!8
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29842 invoked from network); 21 Nov 2014 13:17:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695965"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:19 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5N-0003B4-Ek;
	Fri, 21 Nov 2014 13:17:18 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:17 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:02 +0000
Message-ID: <1416575824-15555-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 13/15] Osstest/Debian: Add 0x prefix
	to $filesize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret
it properly. See http://lists.denx.de/pipermail/u-boot/2014-October/193622.html

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Reference ML thread.
v2: New patch, previously included in "Osstest/Debian: Workaround oddities in
    the u-boot script parser.". Note that the oddities with requiring a space
    before the ">" is no longer reproducible with the latest u-boot.
---
 Osstest/Debian.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 3e56c1f..82669a5 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -177,7 +177,7 @@ echo command line: \\\${bootargs}
 ext2load scsi 0 \\\${kernel_addr_r} $kern
 fdt mknod /chosen module\@0
 fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module"
-fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} \\\${filesize}>
+fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} 0x\\\${filesize}>
 # clk_ignore_unused is due to http://bugs.xenproject.org/xen/bug/45
 fdt set /chosen/module\@0 bootargs "$xenkopt ro root=$root clk_ignore_unused"
 echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize})
@@ -186,7 +186,7 @@ echo command line: $xenkopt ro root=$root
 ext2load scsi 0 \\\${ramdisk_addr_r} $initrd
 fdt mknod /chosen module\@1
 fdt set /chosen/module\@1 compatible "xen,linux-initrd" "xen,multiboot-module"
-fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} \\\${filesize}>
+fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} 0x\\\${filesize}>
 echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize})
 
 fdt print /chosen
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5P-0007If-Km; Fri, 21 Nov 2014 13:17:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5O-0007IA-HM
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:18 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	EA/BD-02954-D5B3F645; Fri, 21 Nov 2014 13:17:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4908 invoked from network); 21 Nov 2014 13:17:15 -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;
	21 Nov 2014 13:17:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229168"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:13 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5F-0003Ad-1d;
	Fri, 21 Nov 2014 13:17:10 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:54 +0000
Message-ID: <1416575824-15555-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 05/15] Osstest/PDU: Add eth008.pm
	method to control the ARM rack PDU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This controls the eth008 relay board: http://www.robot-electronics.co.uk/htm/eth008tech.htm

Due to the use of the CGI interface this requires firmware version 4+.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Use LWP::UserAgent
v2: Pass username and password via a netrc file.
---
 Osstest/PDU/eth008.pm | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)
 create mode 100644 Osstest/PDU/eth008.pm

diff --git a/Osstest/PDU/eth008.pm b/Osstest/PDU/eth008.pm
new file mode 100644
index 0000000..fc5fa96
--- /dev/null
+++ b/Osstest/PDU/eth008.pm
@@ -0,0 +1,65 @@
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2014 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+package Osstest::PDU::eth008;
+
+use strict;
+use warnings;
+
+use Osstest;
+use Osstest::TestSupport;
+use LWP::UserAgent;
+
+BEGIN {
+    use Exporter ();
+    our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
+    $VERSION     = 1.00;
+    @ISA         = qw(Exporter);
+    @EXPORT      = qw();
+    %EXPORT_TAGS = ( );
+
+    @EXPORT_OK   = qw();
+}
+
+sub new {
+    my ($class, $ho, $methname, $pdu, $user, $pass, $port, @opts) = @_;
+    return bless { Host => $ho,
+		   PDU => $pdu,
+		   User => $user,
+		   Pass => $pass,
+		   Port => $port,
+		   Opts => \@opts }, $class;
+}
+
+sub pdu_power_state {
+    my ($mo, $on) = @_;
+    my $op= $on ? "DOA" : "DOI"; # Digital Output (In)Active
+
+    # Use the CGI interface since it is less prone to being firewalled
+    # off, unlike the standard interface on port 17494. This is only
+    # available from firmware v4 onwards.
+
+    my $ua = LWP::UserAgent->new;
+
+    $ua->credentials("$mo->{PDU}:80", "Protected", $mo->{User}, $mo->{Pass});
+
+    my $resp = $ua->get("http://$mo->{PDU}/io.cgi?$op$mo->{Port}=0");
+
+    die "failed" unless $resp->is_success;
+    logm($resp->decoded_content);
+}
+
+1;
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5Q-0007JV-EL; Fri, 21 Nov 2014 13:17:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5P-0007IO-5x
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:19 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	35/ED-02702-E5B3F645; Fri, 21 Nov 2014 13:17:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29562 invoked from network); 21 Nov 2014 13:17:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695923"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:14 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5J-0003Ap-7r;
	Fri, 21 Nov 2014 13:17:14 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:13 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:58 +0000
Message-ID: <1416575824-15555-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 09/15] Osstest/Debian: Add support
	for "ExtraInitramfsModules" host property
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 arndale platform needs a bunch of clk, phy and regulator stuff in order to
access its root filesystem. However mkinitramfs is not (currently?) able to
figure this out and therefore doesn't include them in the initrd. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762042

Add a new host prop which can list these required additional module and
arranges for a suitable /etc/initramfs-tools/modules to be created on install.

Using the new HostGroupProp syntax the required modules are:

HostGroupProp_arndale_ExtraInitramfsModules clk-s2mps11 s5m8767 i2c-s3c2410 phy-exynos5250-sata

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v2: References to bugs.
---
 Osstest/Debian.pm | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 9530aa4..8b70442 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -727,6 +727,23 @@ in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr
 END
     }
 
+    my $modules = get_host_property($ho, "ExtraInitramfsModules", "NONE");
+    if ( $modules ne "NONE" )
+    {
+	# This is currently the best available way to add modules to
+	# the installed initramfs. See
+	# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764805
+        preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+for i in $modules ; do
+    echo \$i >> /target/etc/initramfs-tools/modules
+done
+in-target update-initramfs -u -k all
+END
+    }
+
     my @extra_packages = ();
     push(@extra_packages, "u-boot-tools") if $ho->{Flags}{'need-uboot-bootscr'};
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5H-0007Fg-Ts; Fri, 21 Nov 2014 13:17:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5G-0007FU-3v
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:10 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	C7/57-02696-55B3F645; Fri, 21 Nov 2014 13:17:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28574 invoked from network); 21 Nov 2014 13:17:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695869"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:07 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5B-0003AT-Rn;
	Fri, 21 Nov 2014 13:17:06 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:51 +0000
Message-ID: <1416575824-15555-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 02/15] ts-kernel-build: enable
	CONFIG_IKCONFIG{_PROC}
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This makes the kernel's .config available in /proc/config.gz and embeds a copy
which can be extracted with linux/scripts/extract-ikconfig (which I've not
tried, but have no reason to doubt).

Having this around can be handy with an older osstest installed test box and to
confirm you've booted the kernel you think you have when you are messing with
.config options.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-kernel-build | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ts-kernel-build b/ts-kernel-build
index 3b48920..f02205f 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -436,6 +436,9 @@ setopt CONFIG_MIGRATION n
 
 setopt CONFIG_ACPI_HOTPLUG_MEMORY n
 
+setopt CONFIG_IKCONFIG y
+setopt CONFIG_IKCONFIG_PROC y
+
 # Should all be set one way or another in defconfig but aren't
 setopt CONFIG_NUMA n
 setopt CONFIG_X86_VSMP n
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5L-0007Gt-Su; Fri, 21 Nov 2014 13:17:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5K-0007GL-PR
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:14 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	68/B9-02699-A5B3F645; Fri, 21 Nov 2014 13:17:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29045 invoked from network); 21 Nov 2014 13:17:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695895"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:12 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5H-0003Ai-44;
	Fri, 21 Nov 2014 13:17:12 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:56 +0000
Message-ID: <1416575824-15555-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 07/15] Osstest/Debian: Install dtbs
	into target filesystem in /boot/dtbs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 done whenever dtbs.tar.gz exists. mg-debian-installer-update produces
the necessary inputs on the relevant platform (armhf).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: More careful check/stat for existence of dtbs.tar.gz
v2: Install dtbs iff dtbs.tar.gz exists.
---
 Osstest/Debian.pm | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 33a4ca4..1b4d7a7 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -20,6 +20,8 @@ package Osstest::Debian;
 use strict;
 use warnings;
 
+use POSIX;
+
 use IO::File;
 use File::Copy;
 
@@ -514,6 +516,9 @@ sub preseed_create ($$;@) {
     my $disk= $xopts{DiskDevice} || '/dev/sda';
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
+    my $d_i= $ho->{Tftp}{Path}.'/'.$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.
+	$c{TftpDiVersion}.'-'.$ho->{Suite};
+
     my $hostsq= $dbh_tests->prepare(<<END);
         SELECT val FROM runvars
          WHERE flight=? AND name LIKE '%host'
@@ -627,12 +632,29 @@ $overlays
 echo latecmd done.
 END
 
+    my $dtbs = "$d_i/dtbs.tar.gz";
+    if (!stat $dtbs) {
+        $!==&ENOENT or die "dtbs $!";
+    } elsif (-e _) {
+	my $durl = create_webfile($ho, "dtbs", sub {
+	    copy("$d_i/dtbs.tar.gz", $_[0])
+		or die "Copy dtbs failed: $!";
+	});
+	preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+r=/target
+
+wget -O \$r/tmp/dtbs.tar.gz $durl
+
+in-target tar -C /boot -xaf /tmp/dtbs.tar.gz
+END
+    }
+
     foreach my $kp (keys %{ $ho->{Flags} }) {
 	$kp =~ s/need-kernel-deb-// or next;
 
-	my $d_i= $ho->{Tftp}{Path}.'/'.$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.
-	    $c{TftpDiVersion}.'-'.$ho->{Suite};
-
 	my $kurl = create_webfile($ho, "kernel", sub {
 	    copy("$d_i/$kp.deb", $_[0])
 		or die "Copy kernel failed: $!";
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5I-0007Fr-9U; Fri, 21 Nov 2014 13:17:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5G-0007FZ-RD
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:11 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B8/57-02696-55B3F645; Fri, 21 Nov 2014 13:17:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28202 invoked from network); 21 Nov 2014 13:17:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695861"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:06 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5A-0003AR-Qa;
	Fri, 21 Nov 2014 13:17:05 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:50 +0000
Message-ID: <1416575824-15555-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 01/15] standalone: Introduce
	"HostGroups" for use in OSSTEST_CONFIG
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This saves repeating identical HostProp and HostFlags for sets of identical
machines. e.g.

    HostGroupProp_cubietruck_LinuxSerialConsole ttyS0
    HostGroupProp_cubietruck_Build_Make_Flags -j12
    HostGroupProp_cubietruck_XenSerialConsole dtuart
    HostGroupProp_cubietruck_XenDTUARTPath /soc@01c00000/serial@01c28000
    HostGroupFlags_cubietruck suite-wheezy,equiv-cubietruck,need-kernel-deb-armmp,no-di-kernel,need-uboot-bootscr

    HostGroup_braque cubietruck
    HostProp_braque_Fqdn braque.uk.xensource.com

    HostGroup_picaso cubietruck
    HostProp_picaso_Fqdn picaso.uk.xensource.com

    HostGroup_metzinger cubietruck
    HostProp_metzinger metzinger.uk.xensource.com

    HostGroup_gleizes cubietruck
    HostProp_gleizes_Fqdn gleizes.uk.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Simplify lookup of HostGroup_FOO
v2: Set HostGroup props after DB
    Clarify docs
---
 Osstest/HostDB/Static.pm |  2 ++
 Osstest/TestSupport.pm   | 17 ++++++++++++++++-
 README                   | 22 ++++++++++++++++++++++
 3 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/Osstest/HostDB/Static.pm b/Osstest/HostDB/Static.pm
index d0c13a1..ad18395 100644
--- a/Osstest/HostDB/Static.pm
+++ b/Osstest/HostDB/Static.pm
@@ -58,6 +58,8 @@ sub get_flags ($$) { #method
     };
 
     $process->('HostFlags');
+    $process->("HostGroupFlags_$ho->{Properties}{HostGroup}")
+	if $ho->{Properties}{HostGroup};
     $process->("HostFlags_$ho->{Name}");
 
     return $flags;
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 46b6720..a3b6936 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -767,7 +767,13 @@ sub selecthost ($) {
 	$ho->{Properties}{$pn} = $val;
     };
 
-    # First, we use the config file's general properites as defaults
+    # First, set the prop group if any.
+    if ( $c{"HostGroup_${name}"} ) {
+	$setprop->("HostGroup", $c{"HostGroup_${name}"});
+	logm("Host $name is in HostGroup $ho->{Properties}{HostGroup}");
+    }
+
+    # Next, we use the config file's general properites as defaults
     foreach my $k (keys %c) {
 	next unless $k =~ m/^HostProp_([A-Z].*)$/;
 	$setprop->($1, $c{$k});
@@ -776,6 +782,15 @@ sub selecthost ($) {
     # Then we read in the HostDB's properties
     $mhostdb->get_properties($name, $ho->{Properties});
 
+    # Next, we set any HostGroup based properties
+    if ( $ho->{Properties}{HostGroup} ) {
+	foreach my $k (keys %c) {
+	    next unless $k =~ m/^HostGroupProp_([-a-z0-9]+)_(.*)$/;
+	    next unless $1 eq $ho->{Properties}{HostGroup};
+	    $setprop->($2, $c{$k});
+	}
+    }
+
     # Finally, we override any host-specific properties from the config
     foreach my $k (keys %c) {
 	next unless $k =~ m/^HostProp_([-a-z0-9]+)_(.*)$/;
diff --git a/README b/README
index 9a85549..1226369 100644
--- a/README
+++ b/README
@@ -333,6 +333,28 @@ HostProp_<testbox>_TftpScope
    Defines the Tftp scope (i.e. subnet) where this host resides. See
    "TftpFoo_<scope> and TftpFoo" below.
 
+HostFlags_<testbox>
+   Defines a set of flags for the host. Flags is a list separated by
+   whitespace, comma or semi-colon. A flag can be unset by prepending
+   a !. Only used in standalone mode.
+
+HostGroup_<testbox> <group>
+   Defines a group of similar hosts of which <testbox> is a
+   member. This can then be used with HostGroupProp and HostGroupFlags
+
+HostGroupProps_<group>_<prop>
+   Equivalent to writing HostProp_<testbox>_<prop> for every testbox
+   which declares HostGroup_<testbox>_<group>. Allows setting a set of
+   common properties for a group of similar machines. These settings
+   take precedence over the database provided settings, but are
+   themselves overridden by host-specific properties.
+
+HostGroupFlags_<group>
+   Equivalent to writing HostFlags_<testbox> for every testbox which
+   declares HostGroup_<testbox>_<group>. Allows setting a set of
+   common flags for a group of similar machines. These flags are
+   merged with the host specific flags. Only used in standalone mode.
+
 DebianPreseed
    Text to add to the debian-installer preseed file.  Optional
    but you will need to set some NTP servers here if your firewall
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5Y-0007TB-02; Fri, 21 Nov 2014 13:17:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5V-0007Pk-Tj
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:26 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	19/75-24124-56B3F645; Fri, 21 Nov 2014 13:17:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416575843!7267635!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25897 invoked from network); 21 Nov 2014 13:17:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695994"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:21 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5P-0003BF-OX;
	Fri, 21 Nov 2014 13:17:20 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:19 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:04 +0000
Message-ID: <1416575824-15555-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 15/15] Debian: Create boot.scr with a
	suffix and copy to boot.scr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This ensures that we always have a boot script to boot at least the native
Debian kernel and Xen available, even after multiple iterations of
installation, which is handy when debugging a system.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Debian.pm | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 82669a5..18586fc 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -152,12 +152,12 @@ if test ! -f /boot/$kern ; then
     exit 1
 fi
 # Save a copy of the original
-cp -n /boot/boot /boot/boot.bak
-cp -n /boot/boot.scr /boot/boot.scr.bak
+cp -n /boot/boot.xen /boot/boot.xen.bak
+cp -n /boot/boot.scr.xen /boot/boot.scr.xen.bak
 
 xen=`readlink /boot/$xen`
 
-cat >/boot/boot <<EOF
+cat >/boot/boot.xen <<EOF
 ${load_dtb}
 
 fdt addr \\\${fdt_addr}
@@ -194,7 +194,8 @@ fdt print /chosen
 echo Booting \\\${xen_addr_r} - \\\${fdt_addr}
 bootz \\\${xen_addr_r} - \\\${fdt_addr}
 EOF
-mkimage -A arm -T script -d /boot/boot /boot/boot.scr
+mkimage -A arm -T script -d /boot/boot.xen /boot/boot.scr.xen
+cp /boot/boot.scr.xen /boot/boot.scr
 END
     };
 
@@ -716,7 +717,7 @@ r=/target #/
 kernel=`readlink \$r/vmlinuz | sed -e 's|boot/||'`
 initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
-cat >\$r/boot/boot <<EOF
+cat >\$r/boot/boot.deb <<EOF
 setenv bootargs $bootargs
 ${load_dtb}
 echo Loading \$kernel
@@ -727,7 +728,8 @@ echo Booting
 bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr}
 EOF
 
-in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr
+in-target mkimage -A arm -T script -d /boot/boot.deb /boot/boot.scr.deb
+in-target cp /boot/boot.scr.deb /boot/boot.scr
 END
     }
 
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5J-0007GE-WC; Fri, 21 Nov 2014 13:17:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5I-0007Ff-3N
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:12 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	5D/7C-02699-75B3F645; Fri, 21 Nov 2014 13:17:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416575827!13996777!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28734 invoked from network); 21 Nov 2014 13:17:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193695882"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:09 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5D-0003AZ-Tv;
	Fri, 21 Nov 2014 13:17:08 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:53 +0000
Message-ID: <1416575824-15555-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 04/15] make-flight: Run a basic test
	on each arm platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Unlike x86 there is enough variation in the ARM platforms that it is worth
having a basic test on each as part of a standard run. This relies on each host
having an appropriate platform-$platform host flag.

The existing test-ARCH-ARCH-xl test is retained as a floating test, while a new
variant is added for each distinct platform present in the hostdb which is tied
to that platform type. The intention is that only arm platforms will have
platforms at first, although perhaps platform-intel and platform-amd could be
added in the future too.

There are currently no platform-* flags in the hostdb, so tested with
s/platform-/equiv-/ and:

  ( set -ex ;
    source ./cri-getplatforms ;
    blessing=real ;
    export OSSTEST_CONFIG=production-config ;
    for p in '' `getplatforms "armhf"` ; do
      set +x ;
      echo PLATFORM: $p ;
    done
  )
which prints:
  PLATFORM:
  PLATFORM: marilith
and with s/armhf/amd64/:
  PLATFORM:
  PLATFORM: rackservers-s40670
  PLATFORM: r310-moth
  PLATFORM: rackservers-s40680
  PLATFORM: dell-r310
  PLATFORM: rackservers-s40679
  PLATFORM: rackservers-s40663
  PLATFORM: rackservers-q21011

Also tested in standalone mode with a ~/.xen-osstest/config containing:

  PlatformsArmhf midway cubietruck arndale

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
v3:
    Split /\s+/
---
v2:
    Use platform-* prop not equiv-*
    Select platforms from host db
---
 Osstest/HostDB/Executive.pm | 28 ++++++++++++++++++++++++++++
 Osstest/HostDB/Static.pm    |  9 +++++++++
 README                      |  3 +++
 cri-getplatforms            | 25 +++++++++++++++++++++++++
 make-flight                 |  9 +++++++--
 5 files changed, 72 insertions(+), 2 deletions(-)
 create mode 100755 cri-getplatforms

diff --git a/Osstest/HostDB/Executive.pm b/Osstest/HostDB/Executive.pm
index b2c8dc9..6257829 100644
--- a/Osstest/HostDB/Executive.pm
+++ b/Osstest/HostDB/Executive.pm
@@ -67,6 +67,34 @@ END
     return $flags;
 }
 
+sub get_arch_platforms ($$) {
+    my ($hd, $blessing, $arch) = @_;
+
+    my @plats = ( );
+    my $platsq = $dbh_tests->prepare(<<END);
+SELECT DISTINCT hostflag
+           FROM hostflags h0
+   WHERE EXISTS (
+       SELECT *
+         FROM hostflags h1, hostflags h2
+        WHERE h0.hostname = h1.hostname AND h1.hostname = h2.hostname
+          AND h1.hostflag = ?
+          AND h2.hostflag = ?
+   )
+   AND hostflag like 'platform-%';
+END
+
+    $platsq->execute("blessed-$blessing", "arch-$arch");
+
+    while (my ($plat) = $platsq->fetchrow_array()) {
+	$plat =~ s/^platform-//g or die;
+	push @plats, $plat;
+    }
+
+    $platsq->finish();
+    return @plats;
+}
+
 sub default_methods ($$) {
     my ($hd, $ho) = @_;
 
diff --git a/Osstest/HostDB/Static.pm b/Osstest/HostDB/Static.pm
index ad18395..60f5d3c 100644
--- a/Osstest/HostDB/Static.pm
+++ b/Osstest/HostDB/Static.pm
@@ -65,6 +65,15 @@ sub get_flags ($$) { #method
     return $flags;
 }
 
+sub get_arch_platforms ($$) {
+    my ($hd, $blessing, $arch) = @_;
+
+    my $prop = "Platforms".ucfirst($arch);
+
+    return split /\s+/, $c{$prop} if $c{$prop};
+    return () unless $c{$prop};
+}
+
 sub default_methods ($$) { #method
     my ($hd, $ho) = @_;
 
diff --git a/README b/README
index 3fe5ecc..35532b7 100644
--- a/README
+++ b/README
@@ -395,6 +395,9 @@ The keys in ~/.ssh/id_{rsa,dsa}.pub and ~/.ssh/authorized_keys
 
 TestHostKeypairPath
 
+Platforms<Arch>
+   List of platforms (i.e. distinct host types) to run a basic test on.
+
 HostProp_GenEtherPrefixBase 5e:36:0e:f5
 # 	                               :00:01 guest number in job appended
 #            in standalone jobdb, ^^^^^ xor'd with low 16 bits of your uid
diff --git a/cri-getplatforms b/cri-getplatforms
new file mode 100755
index 0000000..067730c
--- /dev/null
+++ b/cri-getplatforms
@@ -0,0 +1,25 @@
+# -*- bash -*-
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2014 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+getplatforms () {
+        perl -e '
+                use Osstest;
+                csreadconfig();
+                print join " ", $mhostdb->get_arch_platforms("'$blessing'", "'$1'") or die $!;
+        '
+}
diff --git a/make-flight b/make-flight
index 9963a46..0814eba 100755
--- a/make-flight
+++ b/make-flight
@@ -27,6 +27,7 @@ buildflight=$4
 flight=`./cs-flight-create $blessing $branch`
 
 . cri-common
+. cri-getplatforms
 . ap-common
 . mfi-common
 
@@ -284,10 +285,14 @@ do_passthrough_tests () {
 test_matrix_do_one () {
 
   # Basic PV Linux test with xl
+  for platform in '' `getplatforms $xenarch` ; do
+    suffix=${platform:+-$platform}
+    hostflags=${most_hostflags}${platform:+,platform-$platform}
 
-  job_create_test test-$xenarch$kern-$dom0arch-xl test-debian xl \
+    job_create_test test-$xenarch$kern-$dom0arch-xl$suffix test-debian xl \
             $xenarch $dom0arch                                   \
-            $debian_runvars all_hostflags=$most_hostflags
+            $debian_runvars all_hostflags=$hostflags
+  done
 
   job_create_test test-$xenarch$kern-$dom0arch-libvirt test-debian libvirt \
             $xenarch $dom0arch                                       \
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5J-0007G7-LJ; Fri, 21 Nov 2014 13:17:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5H-0007Fe-Ry
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:12 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	F1/CD-02702-65B3F645; Fri, 21 Nov 2014 13:17:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416575829!13439228!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4408 invoked from network); 21 Nov 2014 13:17:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:17:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195229121"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 08:17:08 -0500
Received: from kazak.uk.xensource.com ([10.80.2.80]
	helo=zakaz.uk.xensource.com)	by ukmail1.uk.xensource.com with smtp
	(Exim
	4.69)	(envelope-from <ian.campbell@citrix.com>)	id 1Xro5C-0003AW-Sp;
	Fri, 21 Nov 2014 13:17:07 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 21 Nov
	2014 13:17:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:16:52 +0000
Message-ID: <1416575824-15555-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v3 03/15] Add simple helper to update DI
	for all architectures.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Uses DebianNonfreeFirmware, even (especially) for production, so move the
README stanza out of standalone only section. The current default matches what
is in the current production versions of DI.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 README                         | 16 ++++++++--------
 mg-debian-installer-update-all | 31 +++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+), 8 deletions(-)
 create mode 100755 mg-debian-installer-update-all

diff --git a/README b/README
index 1226369..3fe5ecc 100644
--- a/README
+++ b/README
@@ -360,14 +360,6 @@ DebianPreseed
    but you will need to set some NTP servers here if your firewall
    doesn't permit NTP to Debian's pool.ntp.org servers.
 
-DebianNonfreeFirmware
-  List of debs of non-free firmware to include in the massaged
-  debian-installer.  You will need this if you want to use network
-  card which requires non-free firmware.  The default is just
-  "firmware-bnx2'.  If your host operating system doesn't have
-  grep-dctrl (for example because it's not Debian) then you must set
-  this to the empty string, by writing  DebianNonfreeFirmware=''
-
 ========================================
 
 Config settings relevant only to standalone mode
@@ -420,6 +412,14 @@ GuestDebianSuite   defaults to DebianSuite
 
 DebianPreseed      added to existing preseed file
 
+DebianNonfreeFirmware
+  List of debs of non-free firmware to include in the massaged
+  debian-installer.  You will need this if you want to use network
+  card which requires non-free firmware.  The default is just
+  "firmware-bnx2'.  If your host operating system doesn't have
+  grep-dctrl (for example because it's not Debian) then you must set
+  this to the empty string, by writing  DebianNonfreeFirmware=''
+
 TftpFoo_<scope> and TftpFoo
 
     Describes various properties relating to Tftp in a given <scope>,
diff --git a/mg-debian-installer-update-all b/mg-debian-installer-update-all
new file mode 100755
index 0000000..eca4a5f
--- /dev/null
+++ b/mg-debian-installer-update-all
@@ -0,0 +1,31 @@
+#!/bin/bash
+# usage
+#   ./mg-debian-installer-update-all
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2015 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+set -e
+
+. cri-getconfig
+
+suite=`getconfig DebianSuite`
+fws=`getconfig DebianNonfreeFirmware`
+arches="armhf amd64 i386"
+
+for arch in $arches ; do
+    ./mg-debian-installer-update $suite $arch $fws
+done
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5y-0007uk-Jo; Fri, 21 Nov 2014 13:17:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5w-0007st-Ub
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A3/2A-09842-08B3F645; Fri, 21 Nov 2014 13:17:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416575870!6391347!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19202 invoked from network); 21 Nov 2014 13:17:51 -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;
	21 Nov 2014 13:17:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193696198"
Message-ID: <1416575868.26869.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:48 +0000
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 00/15] support for ARM32 arndale
 and cubietruck 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

On Thu, 2014-11-20 at 17:37 +0000, Ian Campbell wrote:
> This series

Which I fat fingered and sent to "xendevel" instead of xen-devel@lists.
I've just resent with the right things. Sorry for the noise.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:17:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:17:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xro5y-0007uk-Jo; Fri, 21 Nov 2014 13:17:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xro5w-0007st-Ub
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:17:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A3/2A-09842-08B3F645; Fri, 21 Nov 2014 13:17:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416575870!6391347!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19202 invoked from network); 21 Nov 2014 13:17:51 -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;
	21 Nov 2014 13:17:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193696198"
Message-ID: <1416575868.26869.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:17:48 +0000
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 00/15] support for ARM32 arndale
 and cubietruck 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

On Thu, 2014-11-20 at 17:37 +0000, Ian Campbell wrote:
> This series

Which I fat fingered and sent to "xendevel" instead of xen-devel@lists.
I've just resent with the right things. Sorry for the noise.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:26:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XroDy-00010j-Ry; Fri, 21 Nov 2014 13:26:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XroDx-00010e-RO
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 13:26:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	93/01-25276-17D3F645; Fri, 21 Nov 2014 13:26:09 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416576367!14082085!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17714 invoked from network); 21 Nov 2014 13:26:08 -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;
	21 Nov 2014 13:26:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193698539"
Message-ID: <546F3D6D.9030204@citrix.com>
Date: Fri, 21 Nov 2014 13:26:05 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, Jan Beulich <JBeulich@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<546F3CBE0200007800049B77@smtp.nue.novell.com>
	<546F36C9.3020004@suse.com>
In-Reply-To: <546F36C9.3020004@suse.com>
X-DLP: MIA1
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, david.vrabel@citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/11/14 12:57, Juergen Gross wrote:
> On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
>>> --- a/xen/include/public/arch-x86/xen.h
>>> +++ b/xen/include/public/arch-x86/xen.h
>>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>>       /* Frame containing list of mfns containing list of mfns
>>> containing p2m. */
>>>       xen_pfn_t     pfn_to_mfn_frame_list_list;
>>>       unsigned long nmi_reason;
>>> -    uint64_t pad[32];
>>> +    /*
>>> +     * Following two fields are valid if pfn_to_mfn_frame_list_list
>>> contains
>>> +     * ~0UL.
>>> +     */
>>> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
>>> +    unsigned long p2m_as_root;  /* mfn of the top level page table */
>>
>> xen_pfn_t please. And what does the "as" in the name stand for?
>
> "as" is address space. I can rename it to e.g. "p2m_pgd_mfn".

That is a linuxism in naming, which is also not accurate.

>From my understanding, this frame must be an L4 table for 64bit guests,
and an L3 table for 32bit guests.  I.e. it is effectively a cr3 with
which to use the p2m_vaddr field above?

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:26:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XroDy-00010j-Ry; Fri, 21 Nov 2014 13:26:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XroDx-00010e-RO
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 13:26:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	93/01-25276-17D3F645; Fri, 21 Nov 2014 13:26:09 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416576367!14082085!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17714 invoked from network); 21 Nov 2014 13:26:08 -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;
	21 Nov 2014 13:26:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193698539"
Message-ID: <546F3D6D.9030204@citrix.com>
Date: Fri, 21 Nov 2014 13:26:05 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, Jan Beulich <JBeulich@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<546F3CBE0200007800049B77@smtp.nue.novell.com>
	<546F36C9.3020004@suse.com>
In-Reply-To: <546F36C9.3020004@suse.com>
X-DLP: MIA1
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, david.vrabel@citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/11/14 12:57, Juergen Gross wrote:
> On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
>>> --- a/xen/include/public/arch-x86/xen.h
>>> +++ b/xen/include/public/arch-x86/xen.h
>>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>>       /* Frame containing list of mfns containing list of mfns
>>> containing p2m. */
>>>       xen_pfn_t     pfn_to_mfn_frame_list_list;
>>>       unsigned long nmi_reason;
>>> -    uint64_t pad[32];
>>> +    /*
>>> +     * Following two fields are valid if pfn_to_mfn_frame_list_list
>>> contains
>>> +     * ~0UL.
>>> +     */
>>> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
>>> +    unsigned long p2m_as_root;  /* mfn of the top level page table */
>>
>> xen_pfn_t please. And what does the "as" in the name stand for?
>
> "as" is address space. I can rename it to e.g. "p2m_pgd_mfn".

That is a linuxism in naming, which is also not accurate.

>From my understanding, this frame must be an L4 table for 64bit guests,
and an L3 table for 32bit guests.  I.e. it is effectively a cr3 with
which to use the p2m_vaddr field above?

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:28:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13: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 1XroGA-00016z-G0; Fri, 21 Nov 2014 13:28:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XroG8-00016s-9I
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 13:28:24 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	9A/C3-25547-7FD3F645; Fri, 21 Nov 2014 13:28:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416576502!12978090!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26060 invoked from network); 21 Nov 2014 13:28:23 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:28:23 -0000
Received: by mail-wi0-f178.google.com with SMTP id hi2so8806382wib.11
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 05:28:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=mb4pWiqfbFsq/ScZmPh8G3Y8S1R2Y9gd5aVMypp328Y=;
	b=LhQsgB1tVJCgjab6LuCsY6yNwYpwyj2L4dngazqhh7hJdmhHDyrIaCxq6uWNtbicEA
	c4VZAET4MeXsur+xVGx+8zIqHjA3nFMyBXPiVJIZ/W4rjSTm22wm6D2GqAxksOoYZoop
	iJ39vYqvPjtJa3obux+39mOjpzATlv5rBG6tWN+mh0FqnjyGJ9v1bAcxZWJBWWMHTDN5
	jAQ+ZfuyoYWesVJ088eEQzD5VSuuEklKsRG1vzfbjxvWcp6jlJJuo/oWBwqhBjPj0rSQ
	tIOyRf6XufW4Q+C/gpvAioC1QmzU99dNntgiudeUWOC78Jrp0AgCpi0WqhK/jKjoDyOg
	o8kw==
X-Gm-Message-State: ALoCoQmkS3tDd7shqqrefHhHbp0o2Ee376XCZnoJyl9+Fdq5ROYEzngcW0GwIz94XiIiX1ibCvtC
X-Received: by 10.180.24.193 with SMTP id w1mr5270675wif.34.1416576100897;
	Fri, 21 Nov 2014 05:21:40 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ff2sm1092147wib.4.2014.11.21.05.21.39
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 21 Nov 2014 05:21:40 -0800 (PST)
Message-ID: <546F3C60.8030903@linaro.org>
Date: Fri, 21 Nov 2014 13:21:36 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xensource.com, 
	jbeulich@suse.com, konrad.wilk@oracle.com, david.vrabel@citrix.com
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-3-git-send-email-jgross@suse.com>
In-Reply-To: <1415957846-22703-3-git-send-email-jgross@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/4] introduce arch_get_features()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Juergen,

On 11/14/2014 09:37 AM, Juergen Gross wrote:
> The XENVER_get_features sub command of the xen_version hypercall is
> handled completely in common/kernel.c despite of some architecture
> dependant parts.
> 
> Move the architecture dependant parts in an own function in
> arch/*/domain.c
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

For the ARM part:

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

> ---
>  xen/arch/arm/domain.c    |  5 +++++
>  xen/arch/x86/domain.c    | 30 ++++++++++++++++++++++++++++++
>  xen/common/kernel.c      | 22 ++--------------------
>  xen/include/xen/domain.h |  2 ++
>  4 files changed, 39 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 7221bc8..dc5a3fb 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -823,6 +823,11 @@ void vcpu_block_unless_event_pending(struct vcpu *v)
>          vcpu_unblock(current);
>  }
>  
> +uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
> +{
> +    return 0;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index ae0a344..d98aabd 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2166,6 +2166,36 @@ static int __init init_vcpu_kick_softirq(void)
>  }
>  __initcall(init_vcpu_kick_softirq);
>  
> +uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
> +{
> +    uint32_t submap = 0;
> +
> +    switch ( submap_idx )
> +    {
> +    case 0:
> +        switch ( d->guest_type )
> +        {
> +        case guest_type_pv:
> +            submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
> +                      (1U << XENFEAT_highmem_assist) |
> +                      (1U << XENFEAT_gnttab_map_avail_bits);
> +            break;
> +        case guest_type_pvh:
> +            submap |= (1U << XENFEAT_hvm_safe_pvclock) |
> +                      (1U << XENFEAT_supervisor_mode_kernel) |
> +                      (1U << XENFEAT_hvm_callback_vector);
> +            break;
> +        case guest_type_hvm:
> +            submap |= (1U << XENFEAT_hvm_safe_pvclock) |
> +                      (1U << XENFEAT_hvm_callback_vector) |
> +                      (1U << XENFEAT_hvm_pirqs);
> +            break;
> +        }
> +        break;
> +    }
> +
> +    return submap;
> +}
>  
>  /*
>   * Local variables:
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index d23c422..d22a860 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -312,31 +312,13 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>                  fi.submap |= 1U << XENFEAT_supervisor_mode_kernel;
>              if ( is_hardware_domain(current->domain) )
>                  fi.submap |= 1U << XENFEAT_dom0;
> -#ifdef CONFIG_X86
> -            switch ( d->guest_type )
> -            {
> -            case guest_type_pv:
> -                fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
> -                             (1U << XENFEAT_highmem_assist) |
> -                             (1U << XENFEAT_gnttab_map_avail_bits);
> -                break;
> -            case guest_type_pvh:
> -                fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
> -                             (1U << XENFEAT_supervisor_mode_kernel) |
> -                             (1U << XENFEAT_hvm_callback_vector);
> -                break;
> -            case guest_type_hvm:
> -                fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
> -                             (1U << XENFEAT_hvm_callback_vector) |
> -                             (1U << XENFEAT_hvm_pirqs);
> -                break;
> -            }
> -#endif
>              break;
>          default:
>              return -EINVAL;
>          }
>  
> +        fi.submap |= arch_get_features(d, fi.submap_idx);
> +
>          if ( copy_to_guest(arg, &fi, 1) )
>              return -EFAULT;
>          return 0;
> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> index 9215b0e..0d12dc0 100644
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -80,6 +80,8 @@ extern spinlock_t vcpu_alloc_lock;
>  bool_t domctl_lock_acquire(void);
>  void domctl_lock_release(void);
>  
> +uint32_t arch_get_features(struct domain *d, unsigned int submap_idx);
> +
>  /*
>   * Continue the current hypercall via func(data) on specified cpu.
>   * If this function returns 0 then the function is guaranteed to run at some
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:28:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13: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 1XroGA-00016z-G0; Fri, 21 Nov 2014 13:28:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XroG8-00016s-9I
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 13:28:24 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	9A/C3-25547-7FD3F645; Fri, 21 Nov 2014 13:28:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416576502!12978090!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26060 invoked from network); 21 Nov 2014 13:28:23 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:28:23 -0000
Received: by mail-wi0-f178.google.com with SMTP id hi2so8806382wib.11
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 05:28:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=mb4pWiqfbFsq/ScZmPh8G3Y8S1R2Y9gd5aVMypp328Y=;
	b=LhQsgB1tVJCgjab6LuCsY6yNwYpwyj2L4dngazqhh7hJdmhHDyrIaCxq6uWNtbicEA
	c4VZAET4MeXsur+xVGx+8zIqHjA3nFMyBXPiVJIZ/W4rjSTm22wm6D2GqAxksOoYZoop
	iJ39vYqvPjtJa3obux+39mOjpzATlv5rBG6tWN+mh0FqnjyGJ9v1bAcxZWJBWWMHTDN5
	jAQ+ZfuyoYWesVJ088eEQzD5VSuuEklKsRG1vzfbjxvWcp6jlJJuo/oWBwqhBjPj0rSQ
	tIOyRf6XufW4Q+C/gpvAioC1QmzU99dNntgiudeUWOC78Jrp0AgCpi0WqhK/jKjoDyOg
	o8kw==
X-Gm-Message-State: ALoCoQmkS3tDd7shqqrefHhHbp0o2Ee376XCZnoJyl9+Fdq5ROYEzngcW0GwIz94XiIiX1ibCvtC
X-Received: by 10.180.24.193 with SMTP id w1mr5270675wif.34.1416576100897;
	Fri, 21 Nov 2014 05:21:40 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ff2sm1092147wib.4.2014.11.21.05.21.39
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 21 Nov 2014 05:21:40 -0800 (PST)
Message-ID: <546F3C60.8030903@linaro.org>
Date: Fri, 21 Nov 2014 13:21:36 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xensource.com, 
	jbeulich@suse.com, konrad.wilk@oracle.com, david.vrabel@citrix.com
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-3-git-send-email-jgross@suse.com>
In-Reply-To: <1415957846-22703-3-git-send-email-jgross@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/4] introduce arch_get_features()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Juergen,

On 11/14/2014 09:37 AM, Juergen Gross wrote:
> The XENVER_get_features sub command of the xen_version hypercall is
> handled completely in common/kernel.c despite of some architecture
> dependant parts.
> 
> Move the architecture dependant parts in an own function in
> arch/*/domain.c
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

For the ARM part:

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

> ---
>  xen/arch/arm/domain.c    |  5 +++++
>  xen/arch/x86/domain.c    | 30 ++++++++++++++++++++++++++++++
>  xen/common/kernel.c      | 22 ++--------------------
>  xen/include/xen/domain.h |  2 ++
>  4 files changed, 39 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 7221bc8..dc5a3fb 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -823,6 +823,11 @@ void vcpu_block_unless_event_pending(struct vcpu *v)
>          vcpu_unblock(current);
>  }
>  
> +uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
> +{
> +    return 0;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index ae0a344..d98aabd 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2166,6 +2166,36 @@ static int __init init_vcpu_kick_softirq(void)
>  }
>  __initcall(init_vcpu_kick_softirq);
>  
> +uint32_t arch_get_features(struct domain *d, unsigned int submap_idx)
> +{
> +    uint32_t submap = 0;
> +
> +    switch ( submap_idx )
> +    {
> +    case 0:
> +        switch ( d->guest_type )
> +        {
> +        case guest_type_pv:
> +            submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
> +                      (1U << XENFEAT_highmem_assist) |
> +                      (1U << XENFEAT_gnttab_map_avail_bits);
> +            break;
> +        case guest_type_pvh:
> +            submap |= (1U << XENFEAT_hvm_safe_pvclock) |
> +                      (1U << XENFEAT_supervisor_mode_kernel) |
> +                      (1U << XENFEAT_hvm_callback_vector);
> +            break;
> +        case guest_type_hvm:
> +            submap |= (1U << XENFEAT_hvm_safe_pvclock) |
> +                      (1U << XENFEAT_hvm_callback_vector) |
> +                      (1U << XENFEAT_hvm_pirqs);
> +            break;
> +        }
> +        break;
> +    }
> +
> +    return submap;
> +}
>  
>  /*
>   * Local variables:
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index d23c422..d22a860 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -312,31 +312,13 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>                  fi.submap |= 1U << XENFEAT_supervisor_mode_kernel;
>              if ( is_hardware_domain(current->domain) )
>                  fi.submap |= 1U << XENFEAT_dom0;
> -#ifdef CONFIG_X86
> -            switch ( d->guest_type )
> -            {
> -            case guest_type_pv:
> -                fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
> -                             (1U << XENFEAT_highmem_assist) |
> -                             (1U << XENFEAT_gnttab_map_avail_bits);
> -                break;
> -            case guest_type_pvh:
> -                fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
> -                             (1U << XENFEAT_supervisor_mode_kernel) |
> -                             (1U << XENFEAT_hvm_callback_vector);
> -                break;
> -            case guest_type_hvm:
> -                fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
> -                             (1U << XENFEAT_hvm_callback_vector) |
> -                             (1U << XENFEAT_hvm_pirqs);
> -                break;
> -            }
> -#endif
>              break;
>          default:
>              return -EINVAL;
>          }
>  
> +        fi.submap |= arch_get_features(d, fi.submap_idx);
> +
>          if ( copy_to_guest(arg, &fi, 1) )
>              return -EFAULT;
>          return 0;
> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> index 9215b0e..0d12dc0 100644
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -80,6 +80,8 @@ extern spinlock_t vcpu_alloc_lock;
>  bool_t domctl_lock_acquire(void);
>  void domctl_lock_release(void);
>  
> +uint32_t arch_get_features(struct domain *d, unsigned int submap_idx);
> +
>  /*
>   * Continue the current hypercall via func(data) on specified cpu.
>   * If this function returns 0 then the function is guaranteed to run at some
> 


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:32:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:32:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XroJv-0001IY-5V; Fri, 21 Nov 2014 13:32:19 +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 1XroJu-0001IT-MP
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:32:18 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	73/7E-11581-2EE3F645; Fri, 21 Nov 2014 13:32:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416576735!9796993!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27315 invoked from network); 21 Nov 2014 13:32:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:32:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193700827"
Message-ID: <546F3EDD.3020006@citrix.com>
Date: Fri, 21 Nov 2014 13:32:13 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>	
	<1416499238.14429.39.camel@citrix.com>
	<546E1206.5080403@citrix.com> <1416500123.20161.3.camel@citrix.com>
	<546E1ABB.6090308@oracle.com>
In-Reply-To: <546E1ABB.6090308@oracle.com>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/11/14 16:45, Boris Ostrovsky wrote:
> On 11/20/2014 11:15 AM, Ian Campbell wrote:
>> On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
>>> On 20/11/14 16:00, Ian Campbell wrote:
>>>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>>>>> c/s d1b93ea causes substantial functional regressions in pygrub's
>>>>> ability to
>>>>> parse bootloader configuration files.
>>>>>
>>>>> c/s d1b93ea itself changed an an interface which previously used
>>>>> exclusively
>>>>> integers, to using strings in the case of a grub configuration
>>>>> with explicit
>>>>> default set, along with changing the code calling the interface to
>>>>> require a
>>>>> string.  The default value for "default" remained as an integer.
>>>>>
>>>>> As a result, any Extlinux or Lilo configuration (which drives this
>>>>> interface
>>>>> exclusively with integers), or Grub configuration which doesn't
>>>>> explicitly
>>>>> declare a default will die with an AttributeError when attempting
>>>>> to call
>>>>> "self.cf.default.isdigit()" where "default" is an integer.
>>>>>
>>>>> Sadly, this AttributeError gets swallowed by the blanket ignore in
>>>>> the loop
>>>>> which searches partitions for valid bootloader configurations,
>>>>> causing the
>>>>> issue to be reported as "Unable to find partition containing kernel"
>>>>>
>>>>> This patch attempts to fix the issue by altering all parts of this
>>>>> interface
>>>>> to use strings, as opposed to integers.
>>>> Would it be less invasive at this point in the release to have the
>>>> place
>>>> where this stuff is used do isinstance(s, str) and isinstance(s, int)?
>>> It would be BaseString not str, but I am fairly sure the classes have
>>> altered through Py2's history.  I would not be any more confident with
>>> that as a solution as trying to correctly to start with.
>> Actually isinstance(s, basestring) is what the webpage I was looking at
>> said, but I cut-n-pasted the wrong thing.
>>
>> But regardless could it not do something like:
>>     if !isinstance(foo.cf.default, int):
>
> I think it would be the other way around, e.g. (not tested):
>
> diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> index aa7e562..7250f45 100644
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -457,7 +457,9 @@ class Grub:
>          self.cf.parse(buf)
>
>      def image_index(self):
> -        if self.cf.default.isdigit():
> +        if isinstance(self.cf.default, int)
> +            sel = self.cf.default
> +        elif if self.cf.default.isdigit():
>              sel = int(self.cf.default)
>          else:
>              # We don't fully support submenus. Look for the leaf
> value in
>
> but yes, this looks less intrusive (assuming this the only place where
> we'd hit this error).
>

That does look plausibly like it would fix the issue.

However, I can't help but feeing that this is hacking around a broken
patch in the first place.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:32:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:32:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XroJv-0001IY-5V; Fri, 21 Nov 2014 13:32:19 +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 1XroJu-0001IT-MP
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 13:32:18 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	73/7E-11581-2EE3F645; Fri, 21 Nov 2014 13:32:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416576735!9796993!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27315 invoked from network); 21 Nov 2014 13:32:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:32:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193700827"
Message-ID: <546F3EDD.3020006@citrix.com>
Date: Fri, 21 Nov 2014 13:32:13 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>	
	<1416499238.14429.39.camel@citrix.com>
	<546E1206.5080403@citrix.com> <1416500123.20161.3.camel@citrix.com>
	<546E1ABB.6090308@oracle.com>
In-Reply-To: <546E1ABB.6090308@oracle.com>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/11/14 16:45, Boris Ostrovsky wrote:
> On 11/20/2014 11:15 AM, Ian Campbell wrote:
>> On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
>>> On 20/11/14 16:00, Ian Campbell wrote:
>>>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>>>>> c/s d1b93ea causes substantial functional regressions in pygrub's
>>>>> ability to
>>>>> parse bootloader configuration files.
>>>>>
>>>>> c/s d1b93ea itself changed an an interface which previously used
>>>>> exclusively
>>>>> integers, to using strings in the case of a grub configuration
>>>>> with explicit
>>>>> default set, along with changing the code calling the interface to
>>>>> require a
>>>>> string.  The default value for "default" remained as an integer.
>>>>>
>>>>> As a result, any Extlinux or Lilo configuration (which drives this
>>>>> interface
>>>>> exclusively with integers), or Grub configuration which doesn't
>>>>> explicitly
>>>>> declare a default will die with an AttributeError when attempting
>>>>> to call
>>>>> "self.cf.default.isdigit()" where "default" is an integer.
>>>>>
>>>>> Sadly, this AttributeError gets swallowed by the blanket ignore in
>>>>> the loop
>>>>> which searches partitions for valid bootloader configurations,
>>>>> causing the
>>>>> issue to be reported as "Unable to find partition containing kernel"
>>>>>
>>>>> This patch attempts to fix the issue by altering all parts of this
>>>>> interface
>>>>> to use strings, as opposed to integers.
>>>> Would it be less invasive at this point in the release to have the
>>>> place
>>>> where this stuff is used do isinstance(s, str) and isinstance(s, int)?
>>> It would be BaseString not str, but I am fairly sure the classes have
>>> altered through Py2's history.  I would not be any more confident with
>>> that as a solution as trying to correctly to start with.
>> Actually isinstance(s, basestring) is what the webpage I was looking at
>> said, but I cut-n-pasted the wrong thing.
>>
>> But regardless could it not do something like:
>>     if !isinstance(foo.cf.default, int):
>
> I think it would be the other way around, e.g. (not tested):
>
> diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> index aa7e562..7250f45 100644
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -457,7 +457,9 @@ class Grub:
>          self.cf.parse(buf)
>
>      def image_index(self):
> -        if self.cf.default.isdigit():
> +        if isinstance(self.cf.default, int)
> +            sel = self.cf.default
> +        elif if self.cf.default.isdigit():
>              sel = int(self.cf.default)
>          else:
>              # We don't fully support submenus. Look for the leaf
> value in
>
> but yes, this looks less intrusive (assuming this the only place where
> we'd hit this error).
>

That does look plausibly like it would fix the issue.

However, I can't help but feeing that this is hacking around a broken
patch in the first place.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:37:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:37:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XroOt-0001ZZ-5a; Fri, 21 Nov 2014 13:37:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XroOs-0001ZU-GW
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 13:37:26 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	87/C0-27623-5104F645; Fri, 21 Nov 2014 13:37:25 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416577045!12928878!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21698 invoked from network); 21 Nov 2014 13:37:25 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 13:37:25 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 60979AD2E;
	Fri, 21 Nov 2014 13:37:24 +0000 (UTC)
Message-ID: <546F4013.5060402@suse.com>
Date: Fri, 21 Nov 2014 14:37:23 +0100
From: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<546F3CBE0200007800049B77@smtp.nue.novell.com>	<546F36C9.3020004@suse.com>
	<546F3D6D.9030204@citrix.com>
In-Reply-To: <546F3D6D.9030204@citrix.com>
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, david.vrabel@citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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

On 11/21/2014 02:26 PM, Andrew Cooper wrote:
> On 21/11/14 12:57, Juergen Gross wrote:
>> On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>>>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
>>>> --- a/xen/include/public/arch-x86/xen.h
>>>> +++ b/xen/include/public/arch-x86/xen.h
>>>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>>>        /* Frame containing list of mfns containing list of mfns
>>>> containing p2m. */
>>>>        xen_pfn_t     pfn_to_mfn_frame_list_list;
>>>>        unsigned long nmi_reason;
>>>> -    uint64_t pad[32];
>>>> +    /*
>>>> +     * Following two fields are valid if pfn_to_mfn_frame_list_list
>>>> contains
>>>> +     * ~0UL.
>>>> +     */
>>>> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
>>>> +    unsigned long p2m_as_root;  /* mfn of the top level page table */
>>>
>>> xen_pfn_t please. And what does the "as" in the name stand for?
>>
>> "as" is address space. I can rename it to e.g. "p2m_pgd_mfn".
>
> That is a linuxism in naming, which is also not accurate.
>
>  From my understanding, this frame must be an L4 table for 64bit guests,
> and an L3 table for 32bit guests.  I.e. it is effectively a cr3 with
> which to use the p2m_vaddr field above?

Okay, so p2m_cr3 then?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:37:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:37:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XroOt-0001ZZ-5a; Fri, 21 Nov 2014 13:37:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XroOs-0001ZU-GW
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 13:37:26 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	87/C0-27623-5104F645; Fri, 21 Nov 2014 13:37:25 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416577045!12928878!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21698 invoked from network); 21 Nov 2014 13:37:25 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 13:37:25 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 60979AD2E;
	Fri, 21 Nov 2014 13:37:24 +0000 (UTC)
Message-ID: <546F4013.5060402@suse.com>
Date: Fri, 21 Nov 2014 14:37:23 +0100
From: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<546F3CBE0200007800049B77@smtp.nue.novell.com>	<546F36C9.3020004@suse.com>
	<546F3D6D.9030204@citrix.com>
In-Reply-To: <546F3D6D.9030204@citrix.com>
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, david.vrabel@citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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

On 11/21/2014 02:26 PM, Andrew Cooper wrote:
> On 21/11/14 12:57, Juergen Gross wrote:
>> On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>>>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
>>>> --- a/xen/include/public/arch-x86/xen.h
>>>> +++ b/xen/include/public/arch-x86/xen.h
>>>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>>>        /* Frame containing list of mfns containing list of mfns
>>>> containing p2m. */
>>>>        xen_pfn_t     pfn_to_mfn_frame_list_list;
>>>>        unsigned long nmi_reason;
>>>> -    uint64_t pad[32];
>>>> +    /*
>>>> +     * Following two fields are valid if pfn_to_mfn_frame_list_list
>>>> contains
>>>> +     * ~0UL.
>>>> +     */
>>>> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
>>>> +    unsigned long p2m_as_root;  /* mfn of the top level page table */
>>>
>>> xen_pfn_t please. And what does the "as" in the name stand for?
>>
>> "as" is address space. I can rename it to e.g. "p2m_pgd_mfn".
>
> That is a linuxism in naming, which is also not accurate.
>
>  From my understanding, this frame must be an L4 table for 64bit guests,
> and an L3 table for 32bit guests.  I.e. it is effectively a cr3 with
> which to use the p2m_vaddr field above?

Okay, so p2m_cr3 then?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:44:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:44:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XroVS-0001nS-WE; Fri, 21 Nov 2014 13: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 1XroVR-0001nN-TU
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 13:44:14 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	0B/DE-14727-DA14F645; Fri, 21 Nov 2014 13:44:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416577451!9799733!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13039 invoked from network); 21 Nov 2014 13:44:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:44:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195237984"
Message-ID: <1416577449.17932.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:44:09 +0000
In-Reply-To: <1416506849-10498-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1416506849-10498-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH] README.planner: Document the
 resource planning system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 18:07 +0000, Ian Jackson wrote:

> +   Automatic runs create a new ownd task for each job (in become-task

At first I thought ownd was a typo for owned, but I see that it is
called this in the source...

> +The main client in the planning process is
> +ts-hosts-allocate-Executive.  That program contains the heuristics for
> +choosing good tests hosts under various conditions.

s/tests/test/ I think, or maybe an apostrophe?

> +
> +Command-line users can use mg-allocate -U to obtain resources through
> +the planning process.  mg-allocate participates with a high queue
> +priority so that command-line allocations will take precedence over
> +automatic test runs.  (mg-allocate without -U bypasses the planner and
> +can be used to `grab' resources which happen currently to be free.)
> +
> +The distinction between `idle' and `allocatable' resources exists so
> +that newly-freed resources are properly offered first to the tasks at
> +the front of the queue.  ms-ownerdaemon sets all idle resources to
> +allocatable at the start of each planning cycle.

This paragraph makes the first reference to this idle vs. allocatable
concept, but seems to expect that these have already been discussed.

Perhaps s/The/A/ at the start would help but I think more is needed. It
is implied (I think) that the allocation strategy described in all of
the preceding paragraphs operates only on allocatable resources and not
idle ones, or maybe vice versa? Or maybe one or the other is only
available to tasks at the front of the queue? Anyway, can this be made
explicit please.

Having read further I now see this is describe somewhat in the 'types of
task' section. So perhaps all which is needed is a forward reference, or
some rejigging of the ordering of the doc.

> +If the ms-ownerdaemon fails and is restarted, the tasks which were
> +clients of the previous ms-owerdaemon cannot be automatically cleaned
> +up.  The new ms-ownerdaemon will annotate them with `previous'.  The
> +administrator can then clean them up manually, if she knows that all
> +the corresponding actual processes are no longer running.

Perhaps the recipe for this cleanup could be added to README.dev?

> +
> +
> +Types of task
> +-------------
> +
> + * static tasks.  Usual for command-line use.  They are manually
> +   created (with ./mg-hosts manual-task-create) and not normally ever
> +   destroyed.

FWIW there is an explicit example of this in README.dev.

> +     magic/idle
> +
> +        The resource is free but has perhaps only recently become so.
> +        It can be allocated outside the planning process, but proceses

"processes".

> +        participating in planning should regard the resource as
> +        unavailable.
> +
> +     magic/shared
> +
> +        The resource has been divided into shares.  It is unavailable
> +        in its own right without being unshared first.  The individual
> +        shares have their own owners.

"See below for more information on sharing".

(I was just about to ask something which is answered down there...)

> +
> +Sharing
> +-------
> +Likewise a process which finds a shared resource completely idle can
> +unshare it.  That is:
> +    * Check that all the shares are allocatable
> +    * Delete all the rows representing the shares

Is there a race here? Or does the check actually imply allocates each of
them to itself?
 
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:44:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:44:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XroVS-0001nS-WE; Fri, 21 Nov 2014 13: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 1XroVR-0001nN-TU
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 13:44:14 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	0B/DE-14727-DA14F645; Fri, 21 Nov 2014 13:44:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416577451!9799733!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13039 invoked from network); 21 Nov 2014 13:44:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 13:44:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195237984"
Message-ID: <1416577449.17932.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 21 Nov 2014 13:44:09 +0000
In-Reply-To: <1416506849-10498-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1416506849-10498-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [OSSTEST PATCH] README.planner: Document the
 resource planning system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 18:07 +0000, Ian Jackson wrote:

> +   Automatic runs create a new ownd task for each job (in become-task

At first I thought ownd was a typo for owned, but I see that it is
called this in the source...

> +The main client in the planning process is
> +ts-hosts-allocate-Executive.  That program contains the heuristics for
> +choosing good tests hosts under various conditions.

s/tests/test/ I think, or maybe an apostrophe?

> +
> +Command-line users can use mg-allocate -U to obtain resources through
> +the planning process.  mg-allocate participates with a high queue
> +priority so that command-line allocations will take precedence over
> +automatic test runs.  (mg-allocate without -U bypasses the planner and
> +can be used to `grab' resources which happen currently to be free.)
> +
> +The distinction between `idle' and `allocatable' resources exists so
> +that newly-freed resources are properly offered first to the tasks at
> +the front of the queue.  ms-ownerdaemon sets all idle resources to
> +allocatable at the start of each planning cycle.

This paragraph makes the first reference to this idle vs. allocatable
concept, but seems to expect that these have already been discussed.

Perhaps s/The/A/ at the start would help but I think more is needed. It
is implied (I think) that the allocation strategy described in all of
the preceding paragraphs operates only on allocatable resources and not
idle ones, or maybe vice versa? Or maybe one or the other is only
available to tasks at the front of the queue? Anyway, can this be made
explicit please.

Having read further I now see this is describe somewhat in the 'types of
task' section. So perhaps all which is needed is a forward reference, or
some rejigging of the ordering of the doc.

> +If the ms-ownerdaemon fails and is restarted, the tasks which were
> +clients of the previous ms-owerdaemon cannot be automatically cleaned
> +up.  The new ms-ownerdaemon will annotate them with `previous'.  The
> +administrator can then clean them up manually, if she knows that all
> +the corresponding actual processes are no longer running.

Perhaps the recipe for this cleanup could be added to README.dev?

> +
> +
> +Types of task
> +-------------
> +
> + * static tasks.  Usual for command-line use.  They are manually
> +   created (with ./mg-hosts manual-task-create) and not normally ever
> +   destroyed.

FWIW there is an explicit example of this in README.dev.

> +     magic/idle
> +
> +        The resource is free but has perhaps only recently become so.
> +        It can be allocated outside the planning process, but proceses

"processes".

> +        participating in planning should regard the resource as
> +        unavailable.
> +
> +     magic/shared
> +
> +        The resource has been divided into shares.  It is unavailable
> +        in its own right without being unshared first.  The individual
> +        shares have their own owners.

"See below for more information on sharing".

(I was just about to ask something which is answered down there...)

> +
> +Sharing
> +-------
> +Likewise a process which finds a shared resource completely idle can
> +unshare it.  That is:
> +    * Check that all the shares are allocatable
> +    * Delete all the rows representing the shares

Is there a race here? Or does the check actually imply allocates each of
them to itself?
 
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 13:58:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:58:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xroig-00021k-EY; Fri, 21 Nov 2014 13:57:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xroif-00021f-8R
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 13:57:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	09/3E-09842-0E44F645; Fri, 21 Nov 2014 13:57:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416578270!6401911!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11493 invoked from network); 21 Nov 2014 13:57:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 13:57:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALDvneW026308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 13:57:50 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALDvmRv009652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 13:57:49 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALDvmTL027544; Fri, 21 Nov 2014 13:57:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 05:57:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 325E9118822; Fri, 21 Nov 2014 08:57:47 -0500 (EST)
Date: Fri, 21 Nov 2014 08:57:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141121135747.GB2886@laptop.dumpdata.com>
References: <546EFAE3.80404@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546EFAE3.80404@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-rc5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
> Hi,
> 
> while testing my "linear p2m list" patches I saw the following
> problem (even without my patches in place):
> 
> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
> disk image of a guest by attaching it to dom0:
> 
> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
> mount /dev/xvda2 /mnt
> ...
> umount /mnt
> xl block-detach 0 xvda
> 
> Worked without any problem. After some seconds the following messages
> were issued on the console:
> 
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61110 (pfn 1f3f21c)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61110
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61110 (pfn 1f3f21c)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61111 (pfn 1f3f21d)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61111
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61111 (pfn 1f3f21d)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61120 (pfn 1f3f22c)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61120
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61120 (pfn 1f3f22c)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61121 (pfn 1f3f22d)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61121
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61121 (pfn 1f3f22d)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61102 (pfn 1f3f20e)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61102
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61102 (pfn 1f3f20e)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61103 (pfn 1f3f20f)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61103
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61103 (pfn 1f3f20f)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> 
> Is this a known issue?

No. First time I see it.
> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 21 13:58:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 13:58:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xroig-00021k-EY; Fri, 21 Nov 2014 13:57:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xroif-00021f-8R
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 13:57:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	09/3E-09842-0E44F645; Fri, 21 Nov 2014 13:57:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416578270!6401911!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11493 invoked from network); 21 Nov 2014 13:57:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 13:57:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALDvneW026308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 13:57:50 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALDvmRv009652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 13:57:49 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALDvmTL027544; Fri, 21 Nov 2014 13:57:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 05:57:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 325E9118822; Fri, 21 Nov 2014 08:57:47 -0500 (EST)
Date: Fri, 21 Nov 2014 08:57:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141121135747.GB2886@laptop.dumpdata.com>
References: <546EFAE3.80404@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546EFAE3.80404@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-rc5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
> Hi,
> 
> while testing my "linear p2m list" patches I saw the following
> problem (even without my patches in place):
> 
> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
> disk image of a guest by attaching it to dom0:
> 
> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
> mount /dev/xvda2 /mnt
> ...
> umount /mnt
> xl block-detach 0 xvda
> 
> Worked without any problem. After some seconds the following messages
> were issued on the console:
> 
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61110 (pfn 1f3f21c)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61110
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61110 (pfn 1f3f21c)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61111 (pfn 1f3f21d)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61111
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61111 (pfn 1f3f21d)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61120 (pfn 1f3f22c)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61120
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61120 (pfn 1f3f22c)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61121 (pfn 1f3f22d)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61121
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61121 (pfn 1f3f22d)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61102 (pfn 1f3f20e)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61102
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61102 (pfn 1f3f20e)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61103 (pfn 1f3f20f)
> (XEN) mm.c:2995:d0 Error while pinning mfn 61103
> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
> for mfn 61103 (pfn 1f3f20f)
> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
> 
> Is this a known issue?

No. First time I see it.
> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 21 14:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrorY-0002Nd-Fi; Fri, 21 Nov 2014 14:07:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrorX-0002NP-94
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 14:07:03 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	53/D3-09284-6074F645; Fri, 21 Nov 2014 14:07:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416578820!12986317!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3910 invoked from network); 21 Nov 2014 14:07:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:07:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195245088"
Message-ID: <546F468A.2030606@citrix.com>
Date: Fri, 21 Nov 2014 14:04:58 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, Jan Beulich
	<JBeulich@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<546F3CBE0200007800049B77@smtp.nue.novell.com>	<546F36C9.3020004@suse.com>
	<546F3D6D.9030204@citrix.com> <546F4013.5060402@suse.com>
In-Reply-To: <546F4013.5060402@suse.com>
X-DLP: MIA2
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, david.vrabel@citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/11/14 13:37, J=FCrgen Gro=DF wrote:
> On 11/21/2014 02:26 PM, Andrew Cooper wrote:
>> On 21/11/14 12:57, Juergen Gross wrote:
>>> On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>>>>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
>>>>> --- a/xen/include/public/arch-x86/xen.h
>>>>> +++ b/xen/include/public/arch-x86/xen.h
>>>>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>>>>        /* Frame containing list of mfns containing list of mfns
>>>>> containing p2m. */
>>>>>        xen_pfn_t     pfn_to_mfn_frame_list_list;
>>>>>        unsigned long nmi_reason;
>>>>> -    uint64_t pad[32];
>>>>> +    /*
>>>>> +     * Following two fields are valid if pfn_to_mfn_frame_list_list
>>>>> contains
>>>>> +     * ~0UL.
>>>>> +     */
>>>>> +    unsigned long p2m_vaddr;    /* virtual address of the p2m
>>>>> list */
>>>>> +    unsigned long p2m_as_root;  /* mfn of the top level page
>>>>> table */
>>>>
>>>> xen_pfn_t please. And what does the "as" in the name stand for?
>>>
>>> "as" is address space. I can rename it to e.g. "p2m_pgd_mfn".
>>
>> That is a linuxism in naming, which is also not accurate.
>>
>>  From my understanding, this frame must be an L4 table for 64bit guests,
>> and an L3 table for 32bit guests.  I.e. it is effectively a cr3 with
>> which to use the p2m_vaddr field above?
>
> Okay, so p2m_cr3 then?
>
>

I think that is reasonable, along with the comment explaining that it
must reference an L4 or L3 frame, depending on the width of the guest. =

In the case of a 32bit guest, it should be a magic folded pfn, in the
same representation that cr3 has in the vcpu register state.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrorY-0002Nd-Fi; Fri, 21 Nov 2014 14:07:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrorX-0002NP-94
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 14:07:03 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	53/D3-09284-6074F645; Fri, 21 Nov 2014 14:07:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416578820!12986317!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3910 invoked from network); 21 Nov 2014 14:07:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:07:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195245088"
Message-ID: <546F468A.2030606@citrix.com>
Date: Fri, 21 Nov 2014 14:04:58 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: =?windows-1252?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, Jan Beulich
	<JBeulich@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>	<1415957846-22703-2-git-send-email-jgross@suse.com>	<546F3CBE0200007800049B77@smtp.nue.novell.com>	<546F36C9.3020004@suse.com>
	<546F3D6D.9030204@citrix.com> <546F4013.5060402@suse.com>
In-Reply-To: <546F4013.5060402@suse.com>
X-DLP: MIA2
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, david.vrabel@citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/11/14 13:37, J=FCrgen Gro=DF wrote:
> On 11/21/2014 02:26 PM, Andrew Cooper wrote:
>> On 21/11/14 12:57, Juergen Gross wrote:
>>> On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>>>>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
>>>>> --- a/xen/include/public/arch-x86/xen.h
>>>>> +++ b/xen/include/public/arch-x86/xen.h
>>>>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>>>>        /* Frame containing list of mfns containing list of mfns
>>>>> containing p2m. */
>>>>>        xen_pfn_t     pfn_to_mfn_frame_list_list;
>>>>>        unsigned long nmi_reason;
>>>>> -    uint64_t pad[32];
>>>>> +    /*
>>>>> +     * Following two fields are valid if pfn_to_mfn_frame_list_list
>>>>> contains
>>>>> +     * ~0UL.
>>>>> +     */
>>>>> +    unsigned long p2m_vaddr;    /* virtual address of the p2m
>>>>> list */
>>>>> +    unsigned long p2m_as_root;  /* mfn of the top level page
>>>>> table */
>>>>
>>>> xen_pfn_t please. And what does the "as" in the name stand for?
>>>
>>> "as" is address space. I can rename it to e.g. "p2m_pgd_mfn".
>>
>> That is a linuxism in naming, which is also not accurate.
>>
>>  From my understanding, this frame must be an L4 table for 64bit guests,
>> and an L3 table for 32bit guests.  I.e. it is effectively a cr3 with
>> which to use the p2m_vaddr field above?
>
> Okay, so p2m_cr3 then?
>
>

I think that is reasonable, along with the comment explaining that it
must reference an L4 or L3 frame, depending on the width of the guest. =

In the case of a 32bit guest, it should be a magic folded pfn, in the
same representation that cr3 has in the vcpu register state.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:07:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xros8-0002T8-Ss; Fri, 21 Nov 2014 14:07: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 1Xros7-0002Sy-Ty
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:07:40 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	B4/68-24124-B274F645; Fri, 21 Nov 2014 14:07:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416578857!12677422!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26771 invoked from network); 21 Nov 2014 14:07:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:07:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195245298"
Message-ID: <1416578732.17932.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Fri, 21 Nov 2014 14:05:32 +0000
In-Reply-To: <1416562126.26869.8.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416475824.14429.1.camel@citrix.com>
	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
	<1416562126.26869.8.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>, Roger Pau
	=?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 09:28 +0000, Ian Campbell wrote:
> I think libvirt is wrong to specify an absolute path here, IMHO by
> default it should just specify "pygrub" and let libxl figure out the
> correct path. Jim, what do you think?

e.g. something like the following untested (but pretty obvious[0])
patch.

I'm currently rebuilding Debian's libvirt package with this included so
I can give it a go.

Ian.

[0] famous last words, I know!

8<---------------

>From 4edbcbdc7e28896121832d8e226e7aeccf30633c Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 21 Nov 2014 14:00:38 +0000
Subject: [PATCH] libxl: Allow libxl to find pygrub binary.

Specifying an explicit path to pygrub (e.g. BINDIR "/pygrub") only works if
Xen and libvirt happen to be installed to the same prefix. A more flexible
approach is to simply specify "pygrub" which will cause libxl to use the
correct path which it knows (since it is built with the same prefix as pygrub).

This is particular problematic in the Debian packaging, since the Debian Xen
package relocates pygrub into a libexec dir, however I think this change makes
sense upstream.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 src/libxl/libxl_conf.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 25f77ea..3669e68 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -53,7 +53,7 @@
 # define LIBXL_LIB_DIR LOCALSTATEDIR "/lib/libvirt/libxl"
 # define LIBXL_SAVE_DIR LIBXL_LIB_DIR "/save"
 # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump"
-# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
+# define "pygrub"
 
 /* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new
  * parameter has been added, representative of 'VCPU soft affinity'. If one
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:07:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xros8-0002T8-Ss; Fri, 21 Nov 2014 14:07: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 1Xros7-0002Sy-Ty
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:07:40 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	B4/68-24124-B274F645; Fri, 21 Nov 2014 14:07:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416578857!12677422!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26771 invoked from network); 21 Nov 2014 14:07:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:07:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195245298"
Message-ID: <1416578732.17932.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Fri, 21 Nov 2014 14:05:32 +0000
In-Reply-To: <1416562126.26869.8.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416475824.14429.1.camel@citrix.com>
	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
	<1416562126.26869.8.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>, Roger Pau
	=?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 09:28 +0000, Ian Campbell wrote:
> I think libvirt is wrong to specify an absolute path here, IMHO by
> default it should just specify "pygrub" and let libxl figure out the
> correct path. Jim, what do you think?

e.g. something like the following untested (but pretty obvious[0])
patch.

I'm currently rebuilding Debian's libvirt package with this included so
I can give it a go.

Ian.

[0] famous last words, I know!

8<---------------

>From 4edbcbdc7e28896121832d8e226e7aeccf30633c Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 21 Nov 2014 14:00:38 +0000
Subject: [PATCH] libxl: Allow libxl to find pygrub binary.

Specifying an explicit path to pygrub (e.g. BINDIR "/pygrub") only works if
Xen and libvirt happen to be installed to the same prefix. A more flexible
approach is to simply specify "pygrub" which will cause libxl to use the
correct path which it knows (since it is built with the same prefix as pygrub).

This is particular problematic in the Debian packaging, since the Debian Xen
package relocates pygrub into a libexec dir, however I think this change makes
sense upstream.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 src/libxl/libxl_conf.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 25f77ea..3669e68 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -53,7 +53,7 @@
 # define LIBXL_LIB_DIR LOCALSTATEDIR "/lib/libvirt/libxl"
 # define LIBXL_SAVE_DIR LIBXL_LIB_DIR "/save"
 # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump"
-# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
+# define "pygrub"
 
 /* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new
  * parameter has been added, representative of 'VCPU soft affinity'. If one
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:07:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrosC-0002UC-8n; Fri, 21 Nov 2014 14:07:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrosB-0002Tr-CB
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 14:07:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B6/E1-09842-E274F645; Fri, 21 Nov 2014 14:07:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416578862!10990815!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2169 invoked from network); 21 Nov 2014 14:07:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 14:07:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 14:07:41 +0000
Message-Id: <546F553C0200007800049C79@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 14:07:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-2-git-send-email-jgross@suse.com>
	<546F3CBE0200007800049B77@smtp.nue.novell.com>
	<546F36C9.3020004@suse.com>
	<546F3D6D.9030204@citrix.com> <546F4013.5060402@suse.com>
In-Reply-To: <546F4013.5060402@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, david.vrabel@citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 14:37, <JGross@suse.com> wrote:
> On 11/21/2014 02:26 PM, Andrew Cooper wrote:
>> On 21/11/14 12:57, Juergen Gross wrote:
>>> On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>>>>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
>>>>> --- a/xen/include/public/arch-x86/xen.h
>>>>> +++ b/xen/include/public/arch-x86/xen.h
>>>>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>>>>        /* Frame containing list of mfns containing list of mfns
>>>>> containing p2m. */
>>>>>        xen_pfn_t     pfn_to_mfn_frame_list_list;
>>>>>        unsigned long nmi_reason;
>>>>> -    uint64_t pad[32];
>>>>> +    /*
>>>>> +     * Following two fields are valid if pfn_to_mfn_frame_list_list
>>>>> contains
>>>>> +     * ~0UL.
>>>>> +     */
>>>>> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
>>>>> +    unsigned long p2m_as_root;  /* mfn of the top level page table */
>>>>
>>>> xen_pfn_t please. And what does the "as" in the name stand for?
>>>
>>> "as" is address space. I can rename it to e.g. "p2m_pgd_mfn".
>>
>> That is a linuxism in naming, which is also not accurate.
>>
>>  From my understanding, this frame must be an L4 table for 64bit guests,
>> and an L3 table for 32bit guests.  I.e. it is effectively a cr3 with
>> which to use the p2m_vaddr field above?
> 
> Okay, so p2m_cr3 then?

I'm okay with that, but would think p2m_pt_root would be more
generic. Considering PAE, wouldn't this need to be a 64-bit value
then even in the 32-bit interface? Or alternatively be represented
as MFN instead?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:07:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrosC-0002UC-8n; Fri, 21 Nov 2014 14:07:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrosB-0002Tr-CB
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 14:07:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B6/E1-09842-E274F645; Fri, 21 Nov 2014 14:07:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416578862!10990815!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2169 invoked from network); 21 Nov 2014 14:07:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 14:07:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 14:07:41 +0000
Message-Id: <546F553C0200007800049C79@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 14:07:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1415957846-22703-1-git-send-email-jgross@suse.com>
	<1415957846-22703-2-git-send-email-jgross@suse.com>
	<546F3CBE0200007800049B77@smtp.nue.novell.com>
	<546F36C9.3020004@suse.com>
	<546F3D6D.9030204@citrix.com> <546F4013.5060402@suse.com>
In-Reply-To: <546F4013.5060402@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, david.vrabel@citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support
 linear p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 14:37, <JGross@suse.com> wrote:
> On 11/21/2014 02:26 PM, Andrew Cooper wrote:
>> On 21/11/14 12:57, Juergen Gross wrote:
>>> On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>>>>>> On 14.11.14 at 10:37, <"jgross@suse.com".non-mime.internet> wrote:
>>>>> --- a/xen/include/public/arch-x86/xen.h
>>>>> +++ b/xen/include/public/arch-x86/xen.h
>>>>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>>>>        /* Frame containing list of mfns containing list of mfns
>>>>> containing p2m. */
>>>>>        xen_pfn_t     pfn_to_mfn_frame_list_list;
>>>>>        unsigned long nmi_reason;
>>>>> -    uint64_t pad[32];
>>>>> +    /*
>>>>> +     * Following two fields are valid if pfn_to_mfn_frame_list_list
>>>>> contains
>>>>> +     * ~0UL.
>>>>> +     */
>>>>> +    unsigned long p2m_vaddr;    /* virtual address of the p2m list */
>>>>> +    unsigned long p2m_as_root;  /* mfn of the top level page table */
>>>>
>>>> xen_pfn_t please. And what does the "as" in the name stand for?
>>>
>>> "as" is address space. I can rename it to e.g. "p2m_pgd_mfn".
>>
>> That is a linuxism in naming, which is also not accurate.
>>
>>  From my understanding, this frame must be an L4 table for 64bit guests,
>> and an L3 table for 32bit guests.  I.e. it is effectively a cr3 with
>> which to use the p2m_vaddr field above?
> 
> Okay, so p2m_cr3 then?

I'm okay with that, but would think p2m_pt_root would be more
generic. Considering PAE, wouldn't this need to be a 64-bit value
then even in the 32-bit interface? Or alternatively be represented
as MFN instead?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:13:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:13:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xroxb-0002v9-2j; Fri, 21 Nov 2014 14:13:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XroxY-0002ul-TN
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 14:13:17 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	6B/2C-31453-C784F645; Fri, 21 Nov 2014 14:13:16 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416579195!12711361!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24998 invoked from network); 21 Nov 2014 14:13:15 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:13:15 -0000
Received: by mail-qa0-f45.google.com with SMTP id x12so3473763qac.18
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 06:13:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=GkFBPhY6NgfJBHSjB0CCTcqIHFK7KScWL+5vX14ZJxs=;
	b=HcarPXWtlO6elq827YI0MfjoNw+ECsEFH+hIFV/9SDFUAgnE53VZIssHd9bVCp2tjq
	dVIwKVHQNlUgtArh4GBu8UbbNsiw/s8s9hutVmUSAreL0a6wR0WCpe3s8JukLHQDGrKT
	EcJlADg/WFF8Tnqb+qhWDAszepOZ5Ej1WyAuuCFgfms/CJ5QxeDizvp6y+AaCAoMXNx9
	lVcbqTO8WPCVId1T8UW1pjyyuG8HLg0/nNkaKzoiHrRf1HIMq4M4+lHInsbENqjYiRUT
	XhXyIHVkWuFXIb/jAIZpjsgUOUKP8oTRsRWy6x0jfFxdIYzJElkFTpjTCdL25htyZ1KM
	ZKDA==
X-Gm-Message-State: ALoCoQlyRprCfSIN2UxRsPQcQ7itLs7u71svw7iesXAbakE6MOObcu8k0S3SdO0phoIPe9806i54
X-Received: by 10.140.89.200 with SMTP id v66mr6494696qgd.85.1416579194788;
	Fri, 21 Nov 2014 06:13:14 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([185.25.64.249])
	by mx.google.com with ESMTPSA id 9sm4733749qau.37.2014.11.21.06.13.13
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 21 Nov 2014 06:13:14 -0800 (PST)
Message-ID: <546F4875.40709@linaro.org>
Date: Fri, 21 Nov 2014 14:13:09 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<546DCA3F.2030508@linaro.org> <546DCB30.6040400@linaro.org>
	<alpine.DEB.2.02.1411201521320.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411201521320.12596@kaball.uk.xensource.com>
Cc: julien.grall@citrix.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Stefano,

On 20/11/2014 15:54, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Julien Grall wrote:
>> On 11/20/2014 11:02 AM, Julien Grall wrote:
>>> Hi Stefano,
>>>
>>> On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
>>>> UIE being set can cause maintenance interrupts to occur when Xen writes
>>>> to one or more LR registers. The effect is a busy loop around the
>>>> interrupt handler in Xen
>>>> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
>>>>
>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>>>> CC: konrad.wilk@oracle.com
>>>> ---
>>>>
>>>> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
>>>> bad side effects on any other platforms as far as I can tell. It should
>>>> go in 4.5.
>>>
>>>  From Andrii's mail, there is a bad side effect. We can receive spurious
>>> interrupt.
>>>
>>> On V1, you said that you tried this patch on midway. I would prefer if
>>> you give a try on  platform that would really be used (such as xgene or
>>> seattle). As we know Midway won't be used in prod.
>>
>> And maybe give a try to gicv3 too as it's common code.
>
> I don't have a gicv3 test environment ready but it works on xgene too

I gave a try on the Foundation Model and didn't see any specific regression:

Tested-by: Julien Grall <julien.grall@linaro.org>

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:13:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:13:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xroxb-0002v9-2j; Fri, 21 Nov 2014 14:13:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XroxY-0002ul-TN
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 14:13:17 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	6B/2C-31453-C784F645; Fri, 21 Nov 2014 14:13:16 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416579195!12711361!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24998 invoked from network); 21 Nov 2014 14:13:15 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:13:15 -0000
Received: by mail-qa0-f45.google.com with SMTP id x12so3473763qac.18
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 06:13:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=GkFBPhY6NgfJBHSjB0CCTcqIHFK7KScWL+5vX14ZJxs=;
	b=HcarPXWtlO6elq827YI0MfjoNw+ECsEFH+hIFV/9SDFUAgnE53VZIssHd9bVCp2tjq
	dVIwKVHQNlUgtArh4GBu8UbbNsiw/s8s9hutVmUSAreL0a6wR0WCpe3s8JukLHQDGrKT
	EcJlADg/WFF8Tnqb+qhWDAszepOZ5Ej1WyAuuCFgfms/CJ5QxeDizvp6y+AaCAoMXNx9
	lVcbqTO8WPCVId1T8UW1pjyyuG8HLg0/nNkaKzoiHrRf1HIMq4M4+lHInsbENqjYiRUT
	XhXyIHVkWuFXIb/jAIZpjsgUOUKP8oTRsRWy6x0jfFxdIYzJElkFTpjTCdL25htyZ1KM
	ZKDA==
X-Gm-Message-State: ALoCoQlyRprCfSIN2UxRsPQcQ7itLs7u71svw7iesXAbakE6MOObcu8k0S3SdO0phoIPe9806i54
X-Received: by 10.140.89.200 with SMTP id v66mr6494696qgd.85.1416579194788;
	Fri, 21 Nov 2014 06:13:14 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([185.25.64.249])
	by mx.google.com with ESMTPSA id 9sm4733749qau.37.2014.11.21.06.13.13
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 21 Nov 2014 06:13:14 -0800 (PST)
Message-ID: <546F4875.40709@linaro.org>
Date: Fri, 21 Nov 2014 14:13:09 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1416480804-25651-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<546DCA3F.2030508@linaro.org> <546DCB30.6040400@linaro.org>
	<alpine.DEB.2.02.1411201521320.12596@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411201521320.12596@kaball.uk.xensource.com>
Cc: julien.grall@citrix.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, andrii.tseglytskyi@globallogic.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Stefano,

On 20/11/2014 15:54, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Julien Grall wrote:
>> On 11/20/2014 11:02 AM, Julien Grall wrote:
>>> Hi Stefano,
>>>
>>> On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
>>>> UIE being set can cause maintenance interrupts to occur when Xen writes
>>>> to one or more LR registers. The effect is a busy loop around the
>>>> interrupt handler in Xen
>>>> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
>>>>
>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>>>> CC: konrad.wilk@oracle.com
>>>> ---
>>>>
>>>> Konrad, this fixes an actual bug, at least on OMAP5. It should have no
>>>> bad side effects on any other platforms as far as I can tell. It should
>>>> go in 4.5.
>>>
>>>  From Andrii's mail, there is a bad side effect. We can receive spurious
>>> interrupt.
>>>
>>> On V1, you said that you tried this patch on midway. I would prefer if
>>> you give a try on  platform that would really be used (such as xgene or
>>> seattle). As we know Midway won't be used in prod.
>>
>> And maybe give a try to gicv3 too as it's common code.
>
> I don't have a gicv3 test environment ready but it works on xgene too

I gave a try on the Foundation Model and didn't see any specific regression:

Tested-by: Julien Grall <julien.grall@linaro.org>

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:19:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrp3b-00037c-2Z; Fri, 21 Nov 2014 14:19: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 1Xrp3Z-00037X-FX
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:19:29 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	DC/CE-26652-0F94F645; Fri, 21 Nov 2014 14:19:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416579567!12664446!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26066 invoked from network); 21 Nov 2014 14:19:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:19:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193717329"
Message-ID: <1416579506.17932.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>, Andrew Cooper
	<Andrew.Cooper3@citrix.com>
Date: Fri, 21 Nov 2014 14:18:26 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] running pygrub on split-partition disk layouts.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

An absolute age ago Michael posted a patch to allow pygrub to work with
split-partition layouts (i.e. those where the guests disk cfg refers to
xvda1, xvda2, etc rather than an xvda with a partition table). See
http://lists.xen.org/archives/html/xen-devel/2011-01/msg02076.html
(patch itself is below).

Apparently at the time I was of the opinion that this was a reasonable
workaround for the underlying issue (although I seem to have thought I
had a better solution, not so sure right now...).

I'm not sure why it didn't go in (in the likely event I just dropped the
ball -- sorry!).

Anyway, this resurfaced recently in the context of Debian bug #745419:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745419#27

#745419 seems to be unrelated to Michael's issue, it is a full disk
image case with an MBR etc.

Michael, are you still carrying this patch to the Fedora packages? If so
presumably it is without issue in the field so to speak?

Should the patch be resurrected for either 4.5 or 4.6? Or does anyone
have any other insights into the various issues?

Ian.

--- xen-4.1.0/tools/pygrub/src/pygrub.orig	2010-12-31 15:24:11.000000000 +0000
+++ xen-4.1.0/tools/pygrub/src/pygrub	2011-01-30 18:58:17.000000000 +0000
@@ -96,6 +96,7 @@
 
     fd = os.open(file, os.O_RDONLY)
     buf = os.read(fd, 512)
+    offzerocount = 0
     for poff in (446, 462, 478, 494): # partition offsets
 
         # MBR contains a 16 byte descriptor per partition
@@ -105,6 +106,7 @@
         
         # offset == 0 implies this partition is not enabled
         if offset == 0:
+            offzerocount += 1
             continue
 
         if type == FDISK_PART_SOLARIS or type == FDISK_PART_SOLARIS_OLD:
@@ -123,6 +125,9 @@
         else:
             part_offs.append(offset)
 
+    if offzerocount == 4:
+        # Might be a grub boot sector pretending to be an MBR
+        part_offs.append(0)
     return part_offs
 
 class GrubLineEditor(curses.textpad.Textbox):



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:19:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrp3f-00037x-ED; Fri, 21 Nov 2014 14:19:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xrp3e-00037n-18
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:19:34 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	0E/49-02957-5F94F645; Fri, 21 Nov 2014 14:19:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416579571!14014555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21502 invoked from network); 21 Nov 2014 14:19:32 -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;
	21 Nov 2014 14:19:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195250364"
Message-ID: <546F49CD.1020907@citrix.com>
Date: Fri, 21 Nov 2014 14:18:53 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>	<54648EB3.8040703@citrix.com>	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>	<1415955718.31613.34.camel@citrix.com>	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>	<1416227964.5466.12.camel@citrix.com>	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>	<1416475824.14429.1.camel@citrix.com>	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>	<1416562126.26869.8.camel@citrix.com>
	<1416578732.17932.9.camel@citrix.com>
In-Reply-To: <1416578732.17932.9.camel@citrix.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/11/14 14:05, Ian Campbell wrote:
> On Fri, 2014-11-21 at 09:28 +0000, Ian Campbell wrote:
>> I think libvirt is wrong to specify an absolute path here, IMHO by
>> default it should just specify "pygrub" and let libxl figure out the
>> correct path. Jim, what do you think?
> 
> e.g. something like the following untested (but pretty obvious[0])
> patch.
[...]
> +# define "pygrub"

I'm going to go with pretty obviously broken.  You're missing the macro
name.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:19:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrp3b-00037c-2Z; Fri, 21 Nov 2014 14:19: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 1Xrp3Z-00037X-FX
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:19:29 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	DC/CE-26652-0F94F645; Fri, 21 Nov 2014 14:19:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416579567!12664446!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26066 invoked from network); 21 Nov 2014 14:19:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:19:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193717329"
Message-ID: <1416579506.17932.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>, Andrew Cooper
	<Andrew.Cooper3@citrix.com>
Date: Fri, 21 Nov 2014 14:18:26 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] running pygrub on split-partition disk layouts.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

An absolute age ago Michael posted a patch to allow pygrub to work with
split-partition layouts (i.e. those where the guests disk cfg refers to
xvda1, xvda2, etc rather than an xvda with a partition table). See
http://lists.xen.org/archives/html/xen-devel/2011-01/msg02076.html
(patch itself is below).

Apparently at the time I was of the opinion that this was a reasonable
workaround for the underlying issue (although I seem to have thought I
had a better solution, not so sure right now...).

I'm not sure why it didn't go in (in the likely event I just dropped the
ball -- sorry!).

Anyway, this resurfaced recently in the context of Debian bug #745419:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745419#27

#745419 seems to be unrelated to Michael's issue, it is a full disk
image case with an MBR etc.

Michael, are you still carrying this patch to the Fedora packages? If so
presumably it is without issue in the field so to speak?

Should the patch be resurrected for either 4.5 or 4.6? Or does anyone
have any other insights into the various issues?

Ian.

--- xen-4.1.0/tools/pygrub/src/pygrub.orig	2010-12-31 15:24:11.000000000 +0000
+++ xen-4.1.0/tools/pygrub/src/pygrub	2011-01-30 18:58:17.000000000 +0000
@@ -96,6 +96,7 @@
 
     fd = os.open(file, os.O_RDONLY)
     buf = os.read(fd, 512)
+    offzerocount = 0
     for poff in (446, 462, 478, 494): # partition offsets
 
         # MBR contains a 16 byte descriptor per partition
@@ -105,6 +106,7 @@
         
         # offset == 0 implies this partition is not enabled
         if offset == 0:
+            offzerocount += 1
             continue
 
         if type == FDISK_PART_SOLARIS or type == FDISK_PART_SOLARIS_OLD:
@@ -123,6 +125,9 @@
         else:
             part_offs.append(offset)
 
+    if offzerocount == 4:
+        # Might be a grub boot sector pretending to be an MBR
+        part_offs.append(0)
     return part_offs
 
 class GrubLineEditor(curses.textpad.Textbox):



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:19:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrp3f-00037x-ED; Fri, 21 Nov 2014 14:19:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xrp3e-00037n-18
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:19:34 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	0E/49-02957-5F94F645; Fri, 21 Nov 2014 14:19:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416579571!14014555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21502 invoked from network); 21 Nov 2014 14:19:32 -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;
	21 Nov 2014 14:19:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195250364"
Message-ID: <546F49CD.1020907@citrix.com>
Date: Fri, 21 Nov 2014 14:18:53 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>	<54648EB3.8040703@citrix.com>	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>	<1415955718.31613.34.camel@citrix.com>	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>	<1416227964.5466.12.camel@citrix.com>	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>	<1416475824.14429.1.camel@citrix.com>	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>	<1416562126.26869.8.camel@citrix.com>
	<1416578732.17932.9.camel@citrix.com>
In-Reply-To: <1416578732.17932.9.camel@citrix.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/11/14 14:05, Ian Campbell wrote:
> On Fri, 2014-11-21 at 09:28 +0000, Ian Campbell wrote:
>> I think libvirt is wrong to specify an absolute path here, IMHO by
>> default it should just specify "pygrub" and let libxl figure out the
>> correct path. Jim, what do you think?
> 
> e.g. something like the following untested (but pretty obvious[0])
> patch.
[...]
> +# define "pygrub"

I'm going to go with pretty obviously broken.  You're missing the macro
name.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:32:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:32:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpFc-0003Vr-O1; Fri, 21 Nov 2014 14:31: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@citrix.com>) id 1XrpFa-0003Vm-Kz
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 14:31:54 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	B2/51-22777-9DC4F645; Fri, 21 Nov 2014 14:31:53 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416580311!12673256!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20992 invoked from network); 21 Nov 2014 14:31:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:31:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193722603"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 09:31:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrpFE-0004WM-EL;
	Fri, 21 Nov 2014 14:31:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 21 Nov 2014 14:31:30 +0000
Message-ID: <1416580290-4615-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UIE being set can cause maintenance interrupts to occur when Xen writes
to one or more LR registers. The effect is a busy loop around the
interrupt handler in Xen
(http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
Tested-by: Julien Grall <julien.grall@linaro.org>
Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/arch/arm/gic.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..e7a1af5 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -527,8 +529,6 @@ void gic_inject(void)
 
     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
         gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
-    else
-        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
 }
 
 static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
@@ -598,6 +598,11 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
      * Receiving the interrupt is going to cause gic_inject to be called
      * on return to guest that is going to clear the old LRs and inject
      * new interrupts.
+     *
+     * Do not add code here: maintenance interrupts caused by setting
+     * GICH_HCR_UIE, might read as spurious interrupts (1023) because
+     * GICH_HCR_UIE is cleared before reading GICC_IAR. As a consequence
+     * this handler is not called.
      */
 }
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:32:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:32:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpFc-0003Vr-O1; Fri, 21 Nov 2014 14:31: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@citrix.com>) id 1XrpFa-0003Vm-Kz
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 14:31:54 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	B2/51-22777-9DC4F645; Fri, 21 Nov 2014 14:31:53 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416580311!12673256!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20992 invoked from network); 21 Nov 2014 14:31:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:31:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193722603"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 09:31:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrpFE-0004WM-EL;
	Fri, 21 Nov 2014 14:31:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 21 Nov 2014 14:31:30 +0000
Message-ID: <1416580290-4615-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 for-4.5] xen/arm: clear UIE on hypervisor
	entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UIE being set can cause maintenance interrupts to occur when Xen writes
to one or more LR registers. The effect is a busy loop around the
interrupt handler in Xen
(http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
Tested-by: Julien Grall <julien.grall@linaro.org>
Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/arch/arm/gic.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 70d10d6..e7a1af5 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -403,6 +403,8 @@ void gic_clear_lrs(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
+
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask),
@@ -527,8 +529,6 @@ void gic_inject(void)
 
     if ( !list_empty(&current->arch.vgic.lr_pending) && lr_all_full() )
         gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
-    else
-        gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
 }
 
 static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
@@ -598,6 +598,11 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
      * Receiving the interrupt is going to cause gic_inject to be called
      * on return to guest that is going to clear the old LRs and inject
      * new interrupts.
+     *
+     * Do not add code here: maintenance interrupts caused by setting
+     * GICH_HCR_UIE, might read as spurious interrupts (1023) because
+     * GICH_HCR_UIE is cleared before reading GICC_IAR. As a consequence
+     * this handler is not called.
      */
 }
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:33:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:33:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpGf-0003Zj-5p; Fri, 21 Nov 2014 14:33:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrpGd-0003ZI-Ix
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:33:00 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	E8/5E-25547-A1D4F645; Fri, 21 Nov 2014 14:32:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416580376!12982257!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25846 invoked from network); 21 Nov 2014 14:32:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:32:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193723194"
Message-ID: <1416580373.17932.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 21 Nov 2014 14:32:53 +0000
In-Reply-To: <546F49CD.1020907@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416475824.14429.1.camel@citrix.com>
	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
	<1416562126.26869.8.camel@citrix.com>
	<1416578732.17932.9.camel@citrix.com> <546F49CD.1020907@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 14:18 +0000, David Vrabel wrote:
> On 21/11/14 14:05, Ian Campbell wrote:
> > On Fri, 2014-11-21 at 09:28 +0000, Ian Campbell wrote:
> >> I think libvirt is wrong to specify an absolute path here, IMHO by
> >> default it should just specify "pygrub" and let libxl figure out the
> >> correct path. Jim, what do you think?
> > 
> > e.g. something like the following untested (but pretty obvious[0])
> > patch.
> [...]
> > +# define "pygrub"
> 
> I'm going to go with pretty obviously broken.  You're missing the macro
> name.

Doh! Indeed...

Lets try that again...

8<----------

>From 9f2d8da8264b426f54b92378e9e00973694193d4 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 21 Nov 2014 14:00:38 +0000
Subject: [PATCH] libxl: Allow libxl to find pygrub binary.

Specifying an explicit path to pygrub (e.g. BINDIR "/pygrub") only works if
Xen and libvirt happen to be installed to the same prefix. A more flexible
approach is to simply specify "pygrub" which will cause libxl to use the
correct path which it knows (since it is built with the same prefix as pygrub).

This is particular problematic in the Debian packaging, since the Debian Xen
package relocates pygrub into a libexec dir, however I think this change makes
sense upstream.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 .gnulib                |    2 +-
 src/libxl/libxl_conf.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.gnulib b/.gnulib
index 9565c3b..2d28074 160000
--- a/.gnulib
+++ b/.gnulib
@@ -1 +1 @@
-Subproject commit 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d
+Subproject commit 2d280742a9e30088aa169f53353765d5daafe4c0
diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 25f77ea..d7a3971 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -53,7 +53,7 @@
 # define LIBXL_LIB_DIR LOCALSTATEDIR "/lib/libvirt/libxl"
 # define LIBXL_SAVE_DIR LIBXL_LIB_DIR "/save"
 # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump"
-# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
+# define LIBXL_BOOTLOADER_PATH "pygrub"
 
 /* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new
  * parameter has been added, representative of 'VCPU soft affinity'. If one
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:33:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:33:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpGf-0003Zj-5p; Fri, 21 Nov 2014 14:33:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrpGd-0003ZI-Ix
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:33:00 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	E8/5E-25547-A1D4F645; Fri, 21 Nov 2014 14:32:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416580376!12982257!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25846 invoked from network); 21 Nov 2014 14:32:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:32:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193723194"
Message-ID: <1416580373.17932.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 21 Nov 2014 14:32:53 +0000
In-Reply-To: <546F49CD.1020907@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416475824.14429.1.camel@citrix.com>
	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
	<1416562126.26869.8.camel@citrix.com>
	<1416578732.17932.9.camel@citrix.com> <546F49CD.1020907@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 14:18 +0000, David Vrabel wrote:
> On 21/11/14 14:05, Ian Campbell wrote:
> > On Fri, 2014-11-21 at 09:28 +0000, Ian Campbell wrote:
> >> I think libvirt is wrong to specify an absolute path here, IMHO by
> >> default it should just specify "pygrub" and let libxl figure out the
> >> correct path. Jim, what do you think?
> > 
> > e.g. something like the following untested (but pretty obvious[0])
> > patch.
> [...]
> > +# define "pygrub"
> 
> I'm going to go with pretty obviously broken.  You're missing the macro
> name.

Doh! Indeed...

Lets try that again...

8<----------

>From 9f2d8da8264b426f54b92378e9e00973694193d4 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 21 Nov 2014 14:00:38 +0000
Subject: [PATCH] libxl: Allow libxl to find pygrub binary.

Specifying an explicit path to pygrub (e.g. BINDIR "/pygrub") only works if
Xen and libvirt happen to be installed to the same prefix. A more flexible
approach is to simply specify "pygrub" which will cause libxl to use the
correct path which it knows (since it is built with the same prefix as pygrub).

This is particular problematic in the Debian packaging, since the Debian Xen
package relocates pygrub into a libexec dir, however I think this change makes
sense upstream.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 .gnulib                |    2 +-
 src/libxl/libxl_conf.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.gnulib b/.gnulib
index 9565c3b..2d28074 160000
--- a/.gnulib
+++ b/.gnulib
@@ -1 +1 @@
-Subproject commit 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d
+Subproject commit 2d280742a9e30088aa169f53353765d5daafe4c0
diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 25f77ea..d7a3971 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -53,7 +53,7 @@
 # define LIBXL_LIB_DIR LOCALSTATEDIR "/lib/libvirt/libxl"
 # define LIBXL_SAVE_DIR LIBXL_LIB_DIR "/save"
 # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump"
-# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
+# define LIBXL_BOOTLOADER_PATH "pygrub"
 
 /* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new
  * parameter has been added, representative of 'VCPU soft affinity'. If one
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:39:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:39:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpMY-0003sz-8Y; Fri, 21 Nov 2014 14:39:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrpMW-0003su-Hq
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 14:39:04 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	C6/F2-24859-78E4F645; Fri, 21 Nov 2014 14:39:03 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416580743!9258375!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18140 invoked from network); 21 Nov 2014 14:39:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 14:39:03 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B06E3AC54
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 14:39:02 +0000 (UTC)
Message-ID: <546F4E86.8060801@suse.com>
Date: Fri, 21 Nov 2014 15:39:02 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

again a fallout from my "linear p2m list" tests:

Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
wrong device to the domain. The MMIO address was too large for a
MFN of a 32-bit system (it was 380003200000-3800036fffff).

Instead of rejecting the operation Xen tried to perform it resulting
in a (quite understandable) failure in the domU.

I think either the hypervisor or the tools should refuse to do
PCI-passthrough in this case.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:39:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:39:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpMY-0003sz-8Y; Fri, 21 Nov 2014 14:39:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrpMW-0003su-Hq
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 14:39:04 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	C6/F2-24859-78E4F645; Fri, 21 Nov 2014 14:39:03 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416580743!9258375!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18140 invoked from network); 21 Nov 2014 14:39:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 14:39:03 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B06E3AC54
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 14:39:02 +0000 (UTC)
Message-ID: <546F4E86.8060801@suse.com>
Date: Fri, 21 Nov 2014 15:39:02 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

again a fallout from my "linear p2m list" tests:

Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
wrong device to the domain. The MMIO address was too large for a
MFN of a 32-bit system (it was 380003200000-3800036fffff).

Instead of rejecting the operation Xen tried to perform it resulting
in a (quite understandable) failure in the domU.

I think either the hypervisor or the tools should refuse to do
PCI-passthrough in this case.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:40:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpO2-0003y3-NX; Fri, 21 Nov 2014 14:40:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrpO1-0003xu-Ab
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:40:37 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	7A/95-25727-4EE4F645; Fri, 21 Nov 2014 14:40:36 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416580834!10540451!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24148 invoked from network); 21 Nov 2014 14:40:35 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 14:40:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALEeSeQ018125
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 14:40:29 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALEeSi6004961
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 14:40:28 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALEeSJc004948; Fri, 21 Nov 2014 14:40:28 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 06:40:27 -0800
Message-ID: <546F4F83.8010704@oracle.com>
Date: Fri, 21 Nov 2014 09:43:15 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141121111244.GA18698@zion.uk.xensource.com>
In-Reply-To: <20141121111244.GA18698@zion.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 06:12 AM, Wei Liu wrote:
> On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
>> When parsing bitmap objects JSON parser will create libxl_bitmap
>> map of the smallest size needed.
>>
>> This can cause problems when saved image file specifies CPU affinity.
>> For example, if 'vcpu_hard_affinity' in the saved image has only the
>> first CPU specified, just a single byte will be allocated and
>> libxl_bitmap->size will be set to 1.
>>
>> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
>> since the destination bitmap is created for maximum number of CPUs.
>>
>> We could allocate that bitmap of the same size as the source, however,
>> it is later passed to xc_vcpu_setaffinity() which expects it to be
>> sized to the max number of CPUs
>>
>> Instead, we should allow copying the (smaller) bitmap read by the parser
>> and keep the rest of bytes in the destination map unmodified (zero in
>> this case)
>>
> What about copying large bitmap to a smaller one? Say, you migrate to
> a host whose number of cpus is smaller than the size of the source
> bitmap. Is this a valid use case?
>
> Should we have a "best effort" copy function? That is,
>
>    size = min(source_size, destination_size)
>    copy(source, destination, size)

Right, I haven't thought about it for the reversed case.

-boris


>
> In any case I think this is a regression and should be fixed for 4.5.
>
> Wei.
>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>   tools/libxl/libxl.c       |    4 ++--
>>   tools/libxl/libxl_utils.c |    7 +++++++
>>   tools/libxl/libxl_utils.h |    2 ++
>>   3 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index f7961f6..84fd2ca 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -5319,7 +5319,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>>           if (rc)
>>               goto out;
>>   
>> -        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
>> +        libxl_bitmap_copy_partial(ctx, &hard, cpumap_hard);
>>           flags = XEN_VCPUAFFINITY_HARD;
>>       }
>>       if (cpumap_soft) {
>> @@ -5327,7 +5327,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>>           if (rc)
>>               goto out;
>>   
>> -        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
>> +        libxl_bitmap_copy_partial(ctx, &soft, cpumap_soft);
>>           flags |= XEN_VCPUAFFINITY_SOFT;
>>       }
>>   
>> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
>> index 58df4f3..2a08bef 100644
>> --- a/tools/libxl/libxl_utils.c
>> +++ b/tools/libxl/libxl_utils.c
>> @@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>>       memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>>   }
>>   
>> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
>> +                               const libxl_bitmap *sptr)
>> +{
>> +    assert(dptr->size >= sptr->size);
>> +    memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
>> +}
>> +
>>   void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
>>                                libxl_bitmap *dptr,
>>                                const libxl_bitmap *sptr)
>> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
>> index 117b229..d4d0a51 100644
>> --- a/tools/libxl/libxl_utils.h
>> +++ b/tools/libxl/libxl_utils.h
>> @@ -80,6 +80,8 @@ void libxl_bitmap_copy_alloc(libxl_ctx *ctx, libxl_bitmap *dptr,
>>                                const libxl_bitmap *sptr);
>>   void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>>                          const libxl_bitmap *sptr);
>> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
>> +                               const libxl_bitmap *sptr);
>>   int libxl_bitmap_is_full(const libxl_bitmap *bitmap);
>>   int libxl_bitmap_is_empty(const libxl_bitmap *bitmap);
>>   int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
>> -- 
>> 1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:40:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpO2-0003y3-NX; Fri, 21 Nov 2014 14:40:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrpO1-0003xu-Ab
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:40:37 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	7A/95-25727-4EE4F645; Fri, 21 Nov 2014 14:40:36 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416580834!10540451!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24148 invoked from network); 21 Nov 2014 14:40:35 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 14:40:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALEeSeQ018125
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 14:40:29 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALEeSi6004961
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 14:40:28 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALEeSJc004948; Fri, 21 Nov 2014 14:40:28 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 06:40:27 -0800
Message-ID: <546F4F83.8010704@oracle.com>
Date: Fri, 21 Nov 2014 09:43:15 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141121111244.GA18698@zion.uk.xensource.com>
In-Reply-To: <20141121111244.GA18698@zion.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 06:12 AM, Wei Liu wrote:
> On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
>> When parsing bitmap objects JSON parser will create libxl_bitmap
>> map of the smallest size needed.
>>
>> This can cause problems when saved image file specifies CPU affinity.
>> For example, if 'vcpu_hard_affinity' in the saved image has only the
>> first CPU specified, just a single byte will be allocated and
>> libxl_bitmap->size will be set to 1.
>>
>> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
>> since the destination bitmap is created for maximum number of CPUs.
>>
>> We could allocate that bitmap of the same size as the source, however,
>> it is later passed to xc_vcpu_setaffinity() which expects it to be
>> sized to the max number of CPUs
>>
>> Instead, we should allow copying the (smaller) bitmap read by the parser
>> and keep the rest of bytes in the destination map unmodified (zero in
>> this case)
>>
> What about copying large bitmap to a smaller one? Say, you migrate to
> a host whose number of cpus is smaller than the size of the source
> bitmap. Is this a valid use case?
>
> Should we have a "best effort" copy function? That is,
>
>    size = min(source_size, destination_size)
>    copy(source, destination, size)

Right, I haven't thought about it for the reversed case.

-boris


>
> In any case I think this is a regression and should be fixed for 4.5.
>
> Wei.
>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>   tools/libxl/libxl.c       |    4 ++--
>>   tools/libxl/libxl_utils.c |    7 +++++++
>>   tools/libxl/libxl_utils.h |    2 ++
>>   3 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index f7961f6..84fd2ca 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -5319,7 +5319,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>>           if (rc)
>>               goto out;
>>   
>> -        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
>> +        libxl_bitmap_copy_partial(ctx, &hard, cpumap_hard);
>>           flags = XEN_VCPUAFFINITY_HARD;
>>       }
>>       if (cpumap_soft) {
>> @@ -5327,7 +5327,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>>           if (rc)
>>               goto out;
>>   
>> -        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
>> +        libxl_bitmap_copy_partial(ctx, &soft, cpumap_soft);
>>           flags |= XEN_VCPUAFFINITY_SOFT;
>>       }
>>   
>> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
>> index 58df4f3..2a08bef 100644
>> --- a/tools/libxl/libxl_utils.c
>> +++ b/tools/libxl/libxl_utils.c
>> @@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>>       memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>>   }
>>   
>> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
>> +                               const libxl_bitmap *sptr)
>> +{
>> +    assert(dptr->size >= sptr->size);
>> +    memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
>> +}
>> +
>>   void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
>>                                libxl_bitmap *dptr,
>>                                const libxl_bitmap *sptr)
>> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
>> index 117b229..d4d0a51 100644
>> --- a/tools/libxl/libxl_utils.h
>> +++ b/tools/libxl/libxl_utils.h
>> @@ -80,6 +80,8 @@ void libxl_bitmap_copy_alloc(libxl_ctx *ctx, libxl_bitmap *dptr,
>>                                const libxl_bitmap *sptr);
>>   void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>>                          const libxl_bitmap *sptr);
>> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
>> +                               const libxl_bitmap *sptr);
>>   int libxl_bitmap_is_full(const libxl_bitmap *bitmap);
>>   int libxl_bitmap_is_empty(const libxl_bitmap *bitmap);
>>   int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
>> -- 
>> 1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:43:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:43:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpR6-00049B-Rr; Fri, 21 Nov 2014 14:43:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XrpR4-00048v-M8
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 14:43:47 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	D3/D2-14214-2AF4F645; Fri, 21 Nov 2014 14:43:46 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416581021!12685781!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12190 invoked from network); 21 Nov 2014 14:43:41 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:43:41 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so12228050wiv.0
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 06:43:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=RIAF3i6JGfzuvTHCaUfrFL+odE+h7JSRHpiRHEDqka8=;
	b=Fe7xLfu71u8G3x4y5AlfNvOTFHn6kNz1045jxrtgZaYghQDoQFxb660QoIxddM5egS
	Wkm/Iui0tIMPVRa8ZZhWC3KUzv663tWSROdndxnH8RcHCnzXzg/BJGiImCL3Jq05L8Lj
	3Fdb5ItU6e2TQio2fYxTQUFTr2w8ggTnVz7xw7GKXRKZBhry+Nr3lwJqfjOxAN7AA6Zq
	9nyBn35U2MmJPrZMwlFX3zUHkezh4kW6P2102PNpBCUAZ0UmGAfEIuVOS2NisHqomEMS
	EP3oP6YKBfD86jIsD/6uWhT3SVreh2qlLB9PlzyxK6Oz7ChZN3suLP2MicUp6P/ZdloV
	Lrxw==
X-Gm-Message-State: ALoCoQmuuj3/EIqeg6gjuGIEDgk7WKuaUKcYNLkPXAILFhsmPeHf7grpRszYtVXpx4XzA9ey+egh
X-Received: by 10.180.78.73 with SMTP id z9mr25899457wiw.52.1416581019993;
	Fri, 21 Nov 2014 06:43:39 -0800 (PST)
Received: from [192.168.1.15] ([83.211.73.126])
	by mx.google.com with ESMTPSA id w5sm9017753wif.18.2014.11.21.06.43.34
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 21 Nov 2014 06:43:39 -0800 (PST)
Message-ID: <546F4FA0.1070908@m2r.biz>
Date: Fri, 21 Nov 2014 15:43:44 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <53BBA83C.3010307@m2r.biz>
	<1404809604.30343.5.camel@cihla.spice.brq.redhat.com>
	<53BBC2AA.4030503@m2r.biz> <53BBC952.1040902@m2r.biz>
	<54130761.6080501@m2r.biz> <541C2D39.1060607@m2r.biz>
	<54648477.5040505@m2r.biz> <5464A27D.4020107@m2r.biz>
	<546DCEB4.5000205@m2r.biz> <546F1C8F.4020905@m2r.biz>
In-Reply-To: <546F1C8F.4020905@m2r.biz>
Cc: Anthony PERARD <anthony.perard@citrix.com>, kraxel@redhat.com,
	Jan Beulich <JBeulich@suse.com>,
	stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Spice-devel] screen freezed for 2-3 minutes on
 spice connect on xen windows 7 domU's with qxl after save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6722474865592102136=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6722474865592102136==
Content-Type: multipart/alternative;
 boundary="------------040901030006070203030403"

This is a multi-part message in MIME format.
--------------040901030006070203030403
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Length: 47184
Content-Transfer-Encoding: quoted-printable

Il 21/11/2014 12:05, Fabio Fantoni ha scritto:
> Il 20/11/2014 12:21, Fabio Fantoni ha scritto:
>> Il 13/11/2014 13:22, Fabio Fantoni ha scritto:
>>> Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
>>>> Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
>>>>> Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
>>>>>> Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
>>>>>>> Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
>>>>>>>> Il 08/07/2014 10:53, David Ja=9Aa ha scritto:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
>>>>>>>>>> On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
>>>>>>>>>> client with
>>>>>>>>>> spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good 
>>>>>>>>>> as kvm
>>>>>>>>>> except for one problem after xl save/restore, when after 
>>>>>>>>>> restore on
>>>>>>>>>> spice client connect  the domU's screen freezed for 2-3 
>>>>>>>>>> minutes (and
>>>>>>>>>> seems also windows), after this time seems that all return to 
>>>>>>>>>> works
>>>>>>>>>> correctly.
>>>>>>>>>> This problem happen also if spice client connect long time 
>>>>>>>>>> after restore.
>>>>>>>>>> With stdvga not have this problem but stdvga has many missed 
>>>>>>>>>> resolutions
>>>>>>>>>> and bad refresh performance.
>>>>>>>>>>
>>>>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>>>> Client and server logs would certainly help. Please run:
>>>>>>>>>    * virt-viewer with --spice-debug option
>>>>>>>>>    * spice-server with SPICE_DEBUG_LEVEL environment variable set
>>>>>>>>>      to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
>>>>>>>>> http://libvirt.org/drvqemu.html#qemucommand )
>>>>>>>>> and note the location in the logs where the freeze takes place.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>
>>>>>>>> Thanks for your reply, in attachments:
>>>>>>>> - domU's xl cfg: W7.cfg
>>>>>>>> - xl -vvv create/save/restore: xen logs.txt
>>>>>>>> - remote-viewer with --spice-debug after domU's start until xl 
>>>>>>>> save: spicelog-1.txt (zipped)
>>>>>>>> - remote-viewer with --spice-debug after domU's xl restore: 
>>>>>>>> spicelog-2.txt
>>>>>>>
>>>>>>> Sorry for my forgetfulness, here also qemu's log:
>>>>>>> - after domU's start until xl save: qemu-dm-W7.log.1
>>>>>>> - after domU's xl restore: qemu-dm-W7.log
>>>>>>>
>>>>>>>>
>>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Spice-devel mailing list
>>>>>>>>> Spice-devel@lists.freedesktop.org
>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>>>>
>>>>>>
>>>>>> The problem persist, this time I saw these in xl dmesg after 
>>>>>> restore:
>>>>>>
>>>>>> (XEN) HVM2 restore: CPU 0
>>>>>> (XEN) HVM2 restore: CPU 1
>>>>>> (XEN) HVM2 restore: PIC 0
>>>>>> (XEN) HVM2 restore: PIC 1
>>>>>> (XEN) HVM2 restore: IOAPIC 0
>>>>>> (XEN) HVM2 restore: LAPIC 0
>>>>>> (XEN) HVM2 restore: LAPIC 1
>>>>>> (XEN) HVM2 restore: LAPIC_REGS 0
>>>>>> (XEN) HVM2 restore: LAPIC_REGS 1
>>>>>> (XEN) HVM2 restore: PCI_IRQ 0
>>>>>> (XEN) HVM2 restore: ISA_IRQ 0
>>>>>> (XEN) HVM2 restore: PCI_LINK 0
>>>>>> (XEN) HVM2 restore: PIT 0
>>>>>> (XEN) HVM2 restore: RTC 0
>>>>>> (XEN) HVM2 restore: HPET 0
>>>>>> (XEN) HVM2 restore: PMTIMER 0
>>>>>> (XEN) HVM2 restore: MTRR 0
>>>>>> (XEN) HVM2 restore: MTRR 1
>>>>>> (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
>>>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 0
>>>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 1
>>>>>> (XEN) HVM2 restore: VMCE_VCPU 0
>>>>>> (XEN) HVM2 restore: VMCE_VCPU 1
>>>>>> (XEN) HVM2 restore: TSC_ADJUST 0
>>>>>> (XEN) HVM2 restore: TSC_ADJUST 1
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
>>>>>> (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from 
>>>>>> (4) to (32) frames.
>>>>>> (XEN) irq.c:380: Dom2 callback via changed to GSI 24
>>>>>>
>>>>>> Tested on latest staging (commit 
>>>>>> 7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:
>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>>>>
>>>>>> If you need more informations or tests tell me and I'll post them.
>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>
>>>>> I did another tests updating to latest git staging (commit 
>>>>> 3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of 
>>>>> "only" 2-3 minutes but now when it appears to restart (after 2-3 
>>>>> minutes) windows domUs undefinitely hangs instead.
>>>>> No further details in xen and domU's logs.
>>>>>
>>>>> If you need more tests/details tell me and I'll do them.
>>>>>
>>>>> Thanks for any reply.
>>>>
>>>> I did a new test with xen build based on tag 4.5.0-rc2 and on xl 
>>>> dmesg show these errors:
>>>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>>>> Before and after save/restore, with stdvga instead not show them.
>>>
>>> Sorry, I found that was introduced by new winpv drivers update 
>>> instead and I solved applying this patch:
>>> x86/hvm: Add per-vcpu evtchn upcalls v3 
>>> http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html
>>> About save/restore problem with qxl I still not found a solution or 
>>> at least the exact cause :(
>>
>> I tried a strace on qemu process when windows (in domU) is in temp. 
>> freeze and still does many operations (seems similar), I post below a 
>> small part if can be useful.
>> I noted for example some of these lines:
>> read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
>> temporarily unavailable)
>> Is it normal=3F
>>
>> ...
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 4197512}, NULL, 8) =3D 
>> 2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 4193071})
>> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
>> read(30, "W\0\0\0", 4)                  =3D 4
>> write(30, "W\0\0\0", 4)                 =3D 4
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0
>> gettimeofday({1416480295, 28658}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0
>> gettimeofday({1416480295, 28811}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1 
>> ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})
>> *read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
>> temporarily unavailable)*
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
>> clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D 0x7f4a3b2cc000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D 0x7f4a3b2cb000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D 0x7f4a3b2ca000
>> clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D 0x7f4a3b2c9000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D 0x7f4a3b2c8000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D 0x7f4a3b2c7000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D 0x7f4a3b2c6000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D 0x7f4a3b2c5000
>> clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D 0x7f4a3b2c4000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D 0x7f4a3b2c3000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D 0x7f4a3b2c2000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D 0x7f4a3b2c1000
>> clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> read(6, "\1\0\0\0\0\0\0\0", 512)        =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0
>> gettimeofday({1416480295, 35292}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0
>> gettimeofday({1416480295, 35746}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0
>> gettimeofday({1416480295, 35898}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 13233688}, NULL, 8) =3D 
>> 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 13227138})
>> read(20, 
>> "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"..., 
>> 69632) =3D 101
>> clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0
>> gettimeofday({1416480295, 36400}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0
>> gettimeofday({1416480295, 36550}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 12581076}, NULL, 8) =3D 
>> 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 12576281})
>> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
>> read(20, 
>> "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"..., 
>> 69632) =3D 101
>> clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0
>> gettimeofday({1416480295, 37123}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0
>> gettimeofday({1416480295, 37273}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 11857546}, NULL, 8) =3D 
>> 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 9477611})
>> *read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
>> temporarily unavailable)*
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> read(6, "\5\0\0\0\0\0\0\0", 512)        =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0
>> gettimeofday({1416480295, 40643}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0
>> gettimeofday({1416480295, 40946}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0
>> gettimeofday({1416480295, 41097}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1 
>> ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d4000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d3000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d2000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d1000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d0000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2cf000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2ce000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2cd000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2cc000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2cb000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2ca000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c9000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c8000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c7000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c6000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c5000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b435000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b434000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b433000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b432000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2db000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2da000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d9000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d8000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d7000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d6000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d5000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0
>> gettimeofday({1416480295, 48329}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0
>> gettimeofday({1416480295, 48632}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0
>> gettimeofday({1416480295, 48783}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2 
>> ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})
>> read(8, "\4\0\0\0\0\0\0\0", 16)         =3D 8
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c4000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c3000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c2000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c1000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
>> clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0
>> gettimeofday({1416480295, 52051}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0
>> gettimeofday({1416480295, 52426}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0
>> gettimeofday({1416480295, 52576}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1 
>> ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
>> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
>> clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
>> clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0
>> gettimeofday({1416480295, 55341}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0
>> gettimeofday({1416480295, 55725}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0
>> gettimeofday({1416480295, 55876}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2 
>> ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})
>> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b435000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b434000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b433000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b432000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2db000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2da000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d9000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d8000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
>> read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0
>> gettimeofday({1416480295, 58810}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0
>> gettimeofday({1416480295, 59114}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0
>> gettimeofday({1416480295, 59265}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2 
>> ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 0})
>> ...
>>
>> Strace of domU's qemu process during freeze can be useful=3F I must do 
>> a more specific tests=3F
>> If you need more informations/tests tell me and I'll post them.
>
> xen save/restore seems don't save hvm domUs vga's videoram but 
> kvm/qemu save yes, is it correct=3F
> can be the cause of problem and/or other problem=3F

I tried also remote-viewer with --spice-debug and after restore 
connecting with it show initial screen image correct, freeze after with 
line:
     (remote-viewer:3300): GSpice-DEBUG: channel-main.c:1185 main-1:0: 
monitor config: #0 1364x668+0+0 @ 32 bpp
and after some second spice screen become black and show these:
     (remote-viewer:3300): GSpice-DEBUG: channel-cursor.c:480 
cursor-4:0: cursor_handle_reset, init_done: 1
     (remote-viewer:3300): GSpice-DEBUG: channel-display.c:1744 
display-2:0: 0: FIXME primary destroy, but is display really disabled=3F

this can be related to the "freeze" or is only a conseguence=3F

>
>>
>> Thanks for any reply and sorry for my bad english.
>>
>>
>>>
>>>>
>>>> Below I posted full xl dmesg of domU, if you need more 
>>>> informations/tests tell me and I'll post them.
>>>>
>>>>
>>>>> (d4) HVM Loader
>>>>> (d4) Detected Xen v4.5.0-rc
>>>>> (d4) Xenbus rings @0xfeffc000, event channel 1
>>>>> (d4) System requested SeaBIOS
>>>>> (d4) CPU speed is 2660 MHz
>>>>> (d4) Relocating guest memory for lowmem MMIO space disabled
>>>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -> 5
>>>>> (d4) PCI-ISA link 0 routed to IRQ5
>>>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -> 10
>>>>> (d4) PCI-ISA link 1 routed to IRQ10
>>>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -> 11
>>>>> (d4) PCI-ISA link 2 routed to IRQ11
>>>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -> 5
>>>>> (d4) PCI-ISA link 3 routed to IRQ5
>>>>> (d4) pci dev 01:3 INTA->IRQ10
>>>>> (d4) pci dev 02:0 INTA->IRQ11
>>>>> (d4) pci dev 03:0 INTA->IRQ5
>>>>> (d4) pci dev 04:0 INTA->IRQ5
>>>>> (d4) pci dev 05:0 INTA->IRQ10
>>>>> (d4) pci dev 06:0 INTA->IRQ11
>>>>> (d4) pci dev 1d:0 INTA->IRQ10
>>>>> (d4) pci dev 1d:1 INTB->IRQ11
>>>>> (d4) pci dev 1d:2 INTC->IRQ5
>>>>> (d4) pci dev 1d:7 INTD->IRQ5
>>>>> (d4) No RAM in high memory; setting high_mem resource base to 
>>>>> 100000000
>>>>> (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>>>> (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>>>> (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>>>> (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>>>> (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>>>> (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>>>> (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>>>> (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>>>> (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>>>> (d4) pci dev 02:0 bar 10 size 000000100: 00000c001
>>>>> (d4) pci dev 06:0 bar 10 size 000000100: 00000c101
>>>>> (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>>>> (d4) pci dev 04:0 bar 10 size 000000020: 00000c201
>>>>> (d4) pci dev 05:0 bar 1c size 000000020: 00000c221
>>>>> (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>>>> (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>>>> (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>>>> (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>>>> (d4) Multiprocessor initialisation:
>>>>> (d4)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>>> ... done.
>>>>> (d4)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>>> ... done.
>>>>> (d4) Testing HVM environment:
>>>>> (d4)  - REP INSB across page boundaries ... passed
>>>>> (d4)  - GS base MSRs and SWAPGS ... passed
>>>>> (d4) Passed 2 of 2 tests
>>>>> (d4) Writing SMBIOS tables ...
>>>>> (d4) Loading SeaBIOS ...
>>>>> (d4) Creating MP tables ...
>>>>> (d4) Loading ACPI ...
>>>>> (d4) S3 disabled
>>>>> (d4) S4 disabled
>>>>> (d4) vm86 TSS at fc00a100
>>>>> (d4) BIOS map:
>>>>> (d4)  10000-100d3: Scratch space
>>>>> (d4)  c0000-fffff: Main BIOS
>>>>> (d4) E820 table:
>>>>> (d4)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>>>> (d4)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>>>> (d4)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>>>> (d4)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>>>> (d4)  HOLE: 00000000:78000000 - 00000000:fc000000
>>>>> (d4)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>>>> (d4) Invoking SeaBIOS ...
>>>>> (d4) SeaBIOS (version 
>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>> (d4)
>>>>> (d4) Found Xen hypervisor signature at 40000100
>>>>> (d4) Running on QEMU (i440fx)
>>>>> (d4) xen: copy e820...
>>>>> (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>>>> (d4) CPU Mhz=3D2661
>>>>> (d4) Found 13 PCI devices (max PCI bus is 00)
>>>>> (d4) Allocated Xen hypercall page at 77fff000
>>>>> (d4) Detected Xen v4.5.0-rc
>>>>> (d4) xen: copy BIOS tables...
>>>>> (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>>>> (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>>>> (d4) Copying PIR from 0x00010030 to 0x000f0dc0
>>>>> (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>>>> (d4) Using pmtimer, ioport 0xb008
>>>>> (d4) Scan for VGA option rom
>>>>> (d4) Running option rom at c000:0003
>>>>> (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes
>>>>> (d4) pmm call arg1=3D0
>>>>> (d4) Turning on vga text mode console
>>>>> (d4) SeaBIOS (version 
>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>> (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838
>>>>> (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)
>>>>> (d4) Found 0 lpt ports
>>>>> (d4) Found 0 serial ports
>>>>> (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>>>> (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>>>> (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)
>>>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>>>> (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
>>>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
>>>>> (d4) UHCI init on dev 00:1d.0 (io=3Dc240)
>>>>> (d4) UHCI init on dev 00:1d.1 (io=3Dc260)
>>>>> (d4) UHCI init on dev 00:1d.2 (io=3Dc280)
>>>>> (d4) PS2 keyboard initialized
>>>>> (d4) All threads complete.
>>>>> (d4) Scan for option roms
>>>>> (d4) Running option rom at c980:0003
>>>>> (d4) pmm call arg1=3D1
>>>>> (d4) pmm call arg1=3D0
>>>>> (d4) pmm call arg1=3D1
>>>>> (d4) pmm call arg1=3D0
>>>>> (d4) Searching bootorder for: /pci@i0cf8/*@6
>>>>> (d4)
>>>>> (d4) Press F12 for boot menu.
>>>>> (d4)
>>>>> (d4) Searching bootorder for: HALT
>>>>> (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba 
>>>>> LCHS=3D1024/255/63 s=3D102400000
>>>>> (d4)
>>>>> (d4) Space available for UMB: ca800-ee800, f0000-f0ce0
>>>>> (d4) Returned 258048 bytes of ZoneHigh
>>>>> (d4) e820 map has 6 items:
>>>>> (d4)   0: 0000000000000000 - 000000000009fc00 =3D 1 RAM
>>>>> (d4)   1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED
>>>>> (d4)   2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED
>>>>> (d4)   3: 0000000000100000 - 0000000077fff000 =3D 1 RAM
>>>>> (d4)   4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED
>>>>> (d4)   5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED
>>>>> (d4) enter handle_19:
>>>>> (d4)   NULL
>>>>> (d4) Booting from DVD/CD...
>>>>> (d4) Device reports MEDIUM NOT PRESENT
>>>>> (d4) scsi_is_ready returned -1
>>>>> (d4) Boot failed: Could not read from CDROM (code 0003)
>>>>> (d4) enter handle_18:
>>>>> (d4)   NULL
>>>>> (d4) Booting from Hard Disk...
>>>>> (d4) Booting from 0000:7c00
>>>>> (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 
>>>>> sp: 1 build: 1db1
>>>>> (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
>>>>> (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
>>>>> (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
>>>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -> 0
>>>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -> 0
>>>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -> 0
>>>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -> 0
>>>>> *(XEN) hvm.c:6119:d4v1 Bad HVM op 23.**
>>>>> **(XEN) hvm.c:6119:d4v1 Bad HVM op 23.*
>>>>> (XEN) irq.c:380: Dom4 callback via changed to GSI 24
>>>>> (XEN) HVM4 save: CPU
>>>>> (XEN) HVM4 save: PIC
>>>>> (XEN) HVM4 save: IOAPIC
>>>>> (XEN) HVM4 save: LAPIC
>>>>> (XEN) HVM4 save: LAPIC_REGS
>>>>> (XEN) HVM4 save: PCI_IRQ
>>>>> (XEN) HVM4 save: ISA_IRQ
>>>>> (XEN) HVM4 save: PCI_LINK
>>>>> (XEN) HVM4 save: PIT
>>>>> (XEN) HVM4 save: RTC
>>>>> (XEN) HVM4 save: HPET
>>>>> (XEN) HVM4 save: PMTIMER
>>>>> (XEN) HVM4 save: MTRR
>>>>> (XEN) HVM4 save: VIRIDIAN_DOMAIN
>>>>> (XEN) HVM4 save: CPU_XSAVE
>>>>> (XEN) HVM4 save: VIRIDIAN_VCPU
>>>>> (XEN) HVM4 save: VMCE_VCPU
>>>>> (XEN) HVM4 save: TSC_ADJUST
>>>>> (XEN) HVM5 restore: CPU 0
>>>>> (XEN) HVM5 restore: CPU 1
>>>>> (XEN) HVM5 restore: PIC 0
>>>>> (XEN) HVM5 restore: PIC 1
>>>>> (XEN) HVM5 restore: IOAPIC 0
>>>>> (XEN) HVM5 restore: LAPIC 0
>>>>> (XEN) HVM5 restore: LAPIC 1
>>>>> (XEN) HVM5 restore: LAPIC_REGS 0
>>>>> (XEN) HVM5 restore: LAPIC_REGS 1
>>>>> (XEN) HVM5 restore: PCI_IRQ 0
>>>>> (XEN) HVM5 restore: ISA_IRQ 0
>>>>> (XEN) HVM5 restore: PCI_LINK 0
>>>>> (XEN) HVM5 restore: PIT 0
>>>>> (XEN) HVM5 restore: RTC 0
>>>>> (XEN) HVM5 restore: HPET 0
>>>>> (XEN) HVM5 restore: PMTIMER 0
>>>>> (XEN) HVM5 restore: MTRR 0
>>>>> (XEN) HVM5 restore: MTRR 1
>>>>> (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0
>>>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 0
>>>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 1
>>>>> (XEN) HVM5 restore: VMCE_VCPU 0
>>>>> (XEN) HVM5 restore: VMCE_VCPU 1
>>>>> (XEN) HVM5 restore: TSC_ADJUST 0
>>>>> (XEN) HVM5 restore: TSC_ADJUST 1
>>>>> (XEN) irq.c:380: Dom5 callback via changed to None
>>>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>>>>> (XEN) irq.c:380: Dom5 callback via changed to GSI 24
>>>>
>>>>
>>>
>>
>


--------------040901030006070203030403
Content-Type: text/html; charset=windows-1252
Content-Length: 62486
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Il 21/11/2014 12:05, Fabio Fantoni ha
      scritto:<br>
    </div>
    <blockquote cite=3D"mid:546F1C8F.4020905@m2r.biz" type=3D"cite">
      <meta content=3D"text/html; charset=3Dwindows-1252"
        http-equiv=3D"Content-Type">
      <div class=3D"moz-cite-prefix">Il 20/11/2014 12:21, Fabio Fantoni ha
        scritto:<br>
      </div>
      <blockquote cite=3D"mid:546DCEB4.5000205@m2r.biz" type=3D"cite">
        <meta content=3D"text/html; charset=3Dwindows-1252"
          http-equiv=3D"Content-Type">
        <div class=3D"moz-cite-prefix">Il 13/11/2014 13:22, Fabio Fantoni
          ha scritto:<br>
        </div>
        <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite">
          <meta content=3D"text/html; charset=3Dwindows-1252"
            http-equiv=3D"Content-Type">
          <div class=3D"moz-cite-prefix">Il 13/11/2014 11:14, Fabio
            Fantoni ha scritto:<br>
          </div>
          <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite">
            <meta content=3D"text/html; charset=3Dwindows-1252"
              http-equiv=3D"Content-Type">
            <div class=3D"moz-cite-prefix">Il 19/09/2014 15:18, Fabio
              Fantoni ha scritto:<br>
            </div>
            <blockquote cite=3D"mid:541C2D39.1060607@m2r.biz" type=3D"cite">Il

              12/09/2014 16:46, Fabio Fantoni ha scritto: <br>
              <blockquote type=3D"cite">Il 08/07/2014 12:34, Fabio Fantoni
                ha scritto: <br>
                <blockquote type=3D"cite">Il 08/07/2014 12:06, Fabio
                  Fantoni ha scritto: <br>
                  <blockquote type=3D"cite">Il 08/07/2014 10:53, David
                    Ja=9Aa ha scritto: <br>
                    <blockquote type=3D"cite">Hi, <br>
                      <br>
                      On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni
                      wrote: <br>
                      <blockquote type=3D"cite">On xen 4.5 (tried with
                        qemu 2.0.0/2.1-rc0, spice 0.12.5 and client with
                        <br>
                        spice-gtk 0.23/0.25) windows 7 domUs with qxl
                        vga works good as kvm <br>
                        except for one problem after xl save/restore,
                        when after restore on <br>
                        spice client connect=A0 the domU's screen freezed
                        for 2-3 minutes (and <br>
                        seems also windows), after this time seems that
                        all return to works <br>
                        correctly. <br>
                        This problem happen also if spice client connect
                        long time after restore. <br>
                        With stdvga not have this problem but stdvga has
                        many missed resolutions <br>
                        and bad refresh performance. <br>
                        <br>
                        If you need more tests/informations tell me and
                        I'll post them. <br>
                      </blockquote>
                      Client and server logs would certainly help.
                      Please run: <br>
                      =A0=A0 * virt-viewer with --spice-debug option <br>
                      =A0=A0 * spice-server with SPICE_DEBUG_LEVEL
                      environment variable set <br>
                      =A0=A0=A0=A0 to 4 or 5 (if you use qemu+libvirt, use
                      qemu:env element: <br>
                      =A0=A0=A0=A0 <a moz-do-not-send=3D"true"
                        class=3D"moz-txt-link-freetext"
                        href=3D"http://libvirt.org/drvqemu.html#qemucommand">http://libvirt.org/drvqemu.html#qemucommand</a>
                      ) <br>
                      and note the location in the logs where the freeze
                      takes place. <br>
                      <br>
                      Regards, <br>
                      <br>
                      David <br>
                    </blockquote>
                    <br>
                    Thanks for your reply, in attachments: <br>
                    - domU's xl cfg: W7.cfg <br>
                    - xl -vvv create/save/restore: xen logs.txt <br>
                    - remote-viewer with --spice-debug after domU's
                    start until xl save: spicelog-1.txt (zipped) <br>
                    - remote-viewer with --spice-debug after domU's xl
                    restore: spicelog-2.txt <br>
                  </blockquote>
                  <br>
                  Sorry for my forgetfulness, here also qemu's log: <br>
                  - after domU's start until xl save: qemu-dm-W7.log.1 <br>
                  - after domU's xl restore: qemu-dm-W7.log <br>
                  <br>
                  <blockquote type=3D"cite"> <br>
                    If you need more tests/informations tell me and I'll
                    post them. <br>
                    <br>
                    <br>
                    <blockquote type=3D"cite">Thanks for any reply and
                      sorry for my bad english. <br>
                      <br>
                      _______________________________________________ <br>
                      Spice-devel mailing list <br>
                      <a moz-do-not-send=3D"true"
                        class=3D"moz-txt-link-abbreviated"
                        href=3D"mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a>
                      <br>
                      <a moz-do-not-send=3D"true"
                        class=3D"moz-txt-link-freetext"
                        href=3D"http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a>
                      <br>
                    </blockquote>
                  </blockquote>
                  <br>
                </blockquote>
                <br>
                The problem persist, this time I saw these in xl dmesg
                after restore: <br>
                <br>
                (XEN) HVM2 restore: CPU 0 <br>
                (XEN) HVM2 restore: CPU 1 <br>
                (XEN) HVM2 restore: PIC 0 <br>
                (XEN) HVM2 restore: PIC 1 <br>
                (XEN) HVM2 restore: IOAPIC 0 <br>
                (XEN) HVM2 restore: LAPIC 0 <br>
                (XEN) HVM2 restore: LAPIC 1 <br>
                (XEN) HVM2 restore: LAPIC_REGS 0 <br>
                (XEN) HVM2 restore: LAPIC_REGS 1 <br>
                (XEN) HVM2 restore: PCI_IRQ 0 <br>
                (XEN) HVM2 restore: ISA_IRQ 0 <br>
                (XEN) HVM2 restore: PCI_LINK 0 <br>
                (XEN) HVM2 restore: PIT 0 <br>
                (XEN) HVM2 restore: RTC 0 <br>
                (XEN) HVM2 restore: HPET 0 <br>
                (XEN) HVM2 restore: PMTIMER 0 <br>
                (XEN) HVM2 restore: MTRR 0 <br>
                (XEN) HVM2 restore: MTRR 1 <br>
                (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0 <br>
                (XEN) HVM2 restore: VIRIDIAN_VCPU 0 <br>
                (XEN) HVM2 restore: VIRIDIAN_VCPU 1 <br>
                (XEN) HVM2 restore: VMCE_VCPU 0 <br>
                (XEN) HVM2 restore: VMCE_VCPU 1 <br>
                (XEN) HVM2 restore: TSC_ADJUST 0 <br>
                (XEN) HVM2 restore: TSC_ADJUST 1 <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77579
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757a
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757b
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757c
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757d
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757e
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757f
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77580
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77581
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77582
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77583
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77584
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77585
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77586
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77587
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77588
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77589
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758a
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758b
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758c
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758d
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758e
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758f
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77590
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77591
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77592
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77593
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77594
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77595
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77596
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77597
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77598
                invalid <br>
                (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant
                table from (4) to (32) frames. <br>
                (XEN) irq.c:380: Dom2 callback via changed to GSI 24 <br>
                <br>
                Tested on latest staging (commit
                7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice
                patches: <br>
                <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a>
                <br>
                <br>
                If you need more informations or tests tell me and I'll
                post them. <br>
                Thanks for any reply and sorry for my bad english. <br>
              </blockquote>
              <br>
              I did another tests updating to latest git staging (commit
              3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore
              problem of "only" 2-3 minutes but now when it appears to
              restart (after 2-3 minutes) windows domUs undefinitely
              hangs instead. <br>
              No further details in xen and domU's logs. <br>
              <br>
              If you need more tests/details tell me and I'll do them. <br>
              <br>
              Thanks for any reply. <br>
            </blockquote>
            <br>
            I did a new test with xen build based on tag 4.5.0-rc2 and
            on xl dmesg show these errors:<br>
            <blockquote type=3D"cite"><b>(XEN) hvm.c:6119:d5v0 Bad HVM op
                23.</b></blockquote>
            Before and after save/restore, with stdvga instead not show
            them.<br>
          </blockquote>
          <br>
          Sorry, I found that was introduced by new winpv drivers update
          instead and I solved applying this patch:<br>
          x86/hvm: Add per-vcpu evtchn upcalls v3 <a
            moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html">http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html</a><br>
          About save/restore problem with qxl I still not found a
          solution or at least the exact cause :(<br>
        </blockquote>
        <br>
        I tried a strace on qemu process when windows (in domU) is in
        temp. freeze and still does many operations (seems similar), I
        post below a small part if can be useful.<br>
        I noted for example some of these lines:<br>
        read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
        temporarily unavailable)<br>
        Is it normal=3F<br>
        <br>
        ...<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 4197512}, NULL,
        8) =3D 2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left
        {0, 4193071})<br>
        read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        read(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
        write(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0<br>
        gettimeofday({1416480295, 28658}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0<br>
        gettimeofday({1416480295, 28811}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
        ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
        <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
          temporarily unavailable)</b><br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
        0x7f4a3b435000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
        0x7f4a3b434000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
        0x7f4a3b433000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
        0x7f4a3b432000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
        0x7f4a3b2db000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
        0x7f4a3b2da000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
        0x7f4a3b2d9000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
        0x7f4a3b2d8000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
        0x7f4a3b2d7000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
        0x7f4a3b2d6000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
        0x7f4a3b2d5000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
        0x7f4a3b2d4000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
        0x7f4a3b2d3000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
        0x7f4a3b2d2000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
        0x7f4a3b2d1000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
        0x7f4a3b2d0000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
        0x7f4a3b2cf000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
        0x7f4a3b2ce000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
        0x7f4a3b2cd000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D
        0x7f4a3b2cc000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D
        0x7f4a3b2cb000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D
        0x7f4a3b2ca000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D
        0x7f4a3b2c9000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D
        0x7f4a3b2c8000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D
        0x7f4a3b2c7000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D
        0x7f4a3b2c6000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D
        0x7f4a3b2c5000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D
        0x7f4a3b2c4000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D
        0x7f4a3b2c3000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D
        0x7f4a3b2c2000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D
        0x7f4a3b2c1000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        read(6, "\1\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0<br>
        gettimeofday({1416480295, 35292}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0<br>
        gettimeofday({1416480295, 35746}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0<br>
        gettimeofday({1416480295, 35898}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 13233688}, NULL,
        8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left
        {0, 13227138})<br>
        read(20,
        "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"...,


        69632) =3D 101<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0<br>
        gettimeofday({1416480295, 36400}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0<br>
        gettimeofday({1416480295, 36550}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 12581076}, NULL,
        8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left
        {0, 12576281})<br>
        read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        read(20,
        "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"...,


        69632) =3D 101<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0<br>
        gettimeofday({1416480295, 37123}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0<br>
        gettimeofday({1416480295, 37273}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 11857546}, NULL,
        8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 9477611})<br>
        <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
          temporarily unavailable)</b><br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        read(6, "\5\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0<br>
        gettimeofday({1416480295, 40643}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0<br>
        gettimeofday({1416480295, 40946}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0<br>
        gettimeofday({1416480295, 41097}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
        ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d0000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2cf000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2ce000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2cd000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2cc000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2cb000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2ca000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0<br>
        gettimeofday({1416480295, 48329}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0<br>
        gettimeofday({1416480295, 48632}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0<br>
        gettimeofday({1416480295, 48783}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
        ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
        read(8, "\4\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
        0x7f4a3b435000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
        0x7f4a3b434000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
        0x7f4a3b433000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
        0x7f4a3b432000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
        0x7f4a3b2db000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
        0x7f4a3b2da000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
        0x7f4a3b2d9000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
        0x7f4a3b2d8000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0<br>
        gettimeofday({1416480295, 52051}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0<br>
        gettimeofday({1416480295, 52426}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0<br>
        gettimeofday({1416480295, 52576}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
        ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
        read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
        0x7f4a3b2d7000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
        0x7f4a3b2d6000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
        0x7f4a3b2d5000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
        0x7f4a3b2d4000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
        0x7f4a3b2d3000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
        0x7f4a3b2d2000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
        0x7f4a3b2d1000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
        0x7f4a3b2d0000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
        0x7f4a3b2cf000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
        0x7f4a3b2ce000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
        0x7f4a3b2cd000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0<br>
        gettimeofday({1416480295, 55341}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0<br>
        gettimeofday({1416480295, 55725}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0<br>
        gettimeofday({1416480295, 55876}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
        ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
        read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
        read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0<br>
        gettimeofday({1416480295, 58810}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0<br>
        gettimeofday({1416480295, 59114}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0<br>
        gettimeofday({1416480295, 59265}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
        ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
        ...<br>
        <br>
        Strace of domU's qemu process during freeze can be useful=3F I
        must do a more specific tests=3F<br>
        If you need more informations/tests tell me and I'll post them.<br>
      </blockquote>
      <br>
      <span>xen save/restore seems don't save hvm domUs vga's videoram
        but kvm/qemu save yes, is it correct=3F<br>
        can be the cause of problem and/or other problem=3F<br>
      </span></blockquote>
    <br>
    I tried also remote-viewer with --spice-debug and after restore
    connecting with it show initial screen image correct, freeze after
    with line:<br>
    =A0=A0=A0 (remote-viewer:3300): GSpice-DEBUG: channel-main.c:1185
    main-1:0: monitor config: #0 1364x668+0+0 @ 32 bpp<br>
    and after some second spice screen become black and show these:<br>
    =A0=A0=A0 (remote-viewer:3300): GSpice-DEBUG: channel-cursor.c:480
    cursor-4:0: cursor_handle_reset, init_done: 1<br>
    =A0=A0=A0 (remote-viewer:3300): GSpice-DEBUG: channel-display.c:1744
    display-2:0: 0: FIXME primary destroy, but is display really
    disabled=3F<br>
    <br>
    <span>this can be related to the "freeze" or is only a conseguence=3F</span><br>
    <br>
    <blockquote cite=3D"mid:546F1C8F.4020905@m2r.biz" type=3D"cite"><span> </span><br>
      <blockquote cite=3D"mid:546DCEB4.5000205@m2r.biz" type=3D"cite"> <br>
        Thanks for any reply and sorry for my bad english.<br>
        <br>
        <br>
        <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite"> <br>
          <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite"> <br>
            Below I posted full xl dmesg of domU, if you need more
            informations/tests tell me and I'll post them.<br>
            <br>
            <br>
            <blockquote type=3D"cite">(d4) HVM Loader<br>
              (d4) Detected Xen v4.5.0-rc<br>
              (d4) Xenbus rings @0xfeffc000, event channel 1<br>
              (d4) System requested SeaBIOS<br>
              (d4) CPU speed is 2660 MHz<br>
              (d4) Relocating guest memory for lowmem MMIO space
              disabled<br>
              (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -&gt; 5<br>
              (d4) PCI-ISA link 0 routed to IRQ5<br>
              (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -&gt; 10<br>
              (d4) PCI-ISA link 1 routed to IRQ10<br>
              (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -&gt; 11<br>
              (d4) PCI-ISA link 2 routed to IRQ11<br>
              (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -&gt; 5<br>
              (d4) PCI-ISA link 3 routed to IRQ5<br>
              (d4) pci dev 01:3 INTA-&gt;IRQ10<br>
              (d4) pci dev 02:0 INTA-&gt;IRQ11<br>
              (d4) pci dev 03:0 INTA-&gt;IRQ5<br>
              (d4) pci dev 04:0 INTA-&gt;IRQ5<br>
              (d4) pci dev 05:0 INTA-&gt;IRQ10<br>
              (d4) pci dev 06:0 INTA-&gt;IRQ11<br>
              (d4) pci dev 1d:0 INTA-&gt;IRQ10<br>
              (d4) pci dev 1d:1 INTB-&gt;IRQ11<br>
              (d4) pci dev 1d:2 INTC-&gt;IRQ5<br>
              (d4) pci dev 1d:7 INTD-&gt;IRQ5<br>
              (d4) No RAM in high memory; setting high_mem resource base
              to 100000000<br>
              (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000<br>
              (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000<br>
              (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008<br>
              (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000<br>
              (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000<br>
              (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000<br>
              (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000<br>
              (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000<br>
              (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000<br>
              (d4) pci dev 02:0 bar 10 size 000000100: 00000c001<br>
              (d4) pci dev 06:0 bar 10 size 000000100: 00000c101<br>
              (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000<br>
              (d4) pci dev 04:0 bar 10 size 000000020: 00000c201<br>
              (d4) pci dev 05:0 bar 1c size 000000020: 00000c221<br>
              (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241<br>
              (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261<br>
              (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281<br>
              (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1<br>
              (d4) Multiprocessor initialisation:<br>
              (d4)=A0 - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs
              [1/8] ... done.<br>
              (d4)=A0 - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs
              [1/8] ... done.<br>
              (d4) Testing HVM environment:<br>
              (d4)=A0 - REP INSB across page boundaries ... passed<br>
              (d4)=A0 - GS base MSRs and SWAPGS ... passed<br>
              (d4) Passed 2 of 2 tests<br>
              (d4) Writing SMBIOS tables ...<br>
              (d4) Loading SeaBIOS ...<br>
              (d4) Creating MP tables ...<br>
              (d4) Loading ACPI ...<br>
              (d4) S3 disabled<br>
              (d4) S4 disabled<br>
              (d4) vm86 TSS at fc00a100<br>
              (d4) BIOS map:<br>
              (d4)=A0 10000-100d3: Scratch space<br>
              (d4)=A0 c0000-fffff: Main BIOS<br>
              (d4) E820 table:<br>
              (d4)=A0 [00]: 00000000:00000000 - 00000000:000a0000: RAM<br>
              (d4)=A0 HOLE: 00000000:000a0000 - 00000000:000c0000<br>
              (d4)=A0 [01]: 00000000:000c0000 - 00000000:00100000:
              RESERVED<br>
              (d4)=A0 [02]: 00000000:00100000 - 00000000:78000000: RAM<br>
              (d4)=A0 HOLE: 00000000:78000000 - 00000000:fc000000<br>
              (d4)=A0 [03]: 00000000:fc000000 - 00000001:00000000:
              RESERVED<br>
              (d4) Invoking SeaBIOS ...<br>
              (d4) SeaBIOS (version
              debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
              (d4) <br>
              (d4) Found Xen hypervisor signature at 40000100<br>
              (d4) Running on QEMU (i440fx)<br>
              (d4) xen: copy e820...<br>
              (d4) Relocating init from 0x000df619 to 0x77fae600 (size
              71995)<br>
              (d4) CPU Mhz=3D2661<br>
              (d4) Found 13 PCI devices (max PCI bus is 00)<br>
              (d4) Allocated Xen hypercall page at 77fff000<br>
              (d4) Detected Xen v4.5.0-rc<br>
              (d4) xen: copy BIOS tables...<br>
              (d4) Copying SMBIOS entry point from 0x00010010 to
              0x000f0f40<br>
              (d4) Copying MPTABLE from 0xfc001160/fc001170 to
              0x000f0e40<br>
              (d4) Copying PIR from 0x00010030 to 0x000f0dc0<br>
              (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90<br>
              (d4) Using pmtimer, ioport 0xb008<br>
              (d4) Scan for VGA option rom<br>
              (d4) Running option rom at c000:0003<br>
              (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes<br>
              (d4) pmm call arg1=3D0<br>
              (d4) Turning on vga text mode console<br>
              (d4) SeaBIOS (version
              debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
              (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838<br>
              (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)<br>
              (d4) Found 0 lpt ports<br>
              (d4) Found 0 serial ports<br>
              (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)<br>
              (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)<br>
              (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)<br>
              (d4) Searching bootorder for:
              /pci@i0cf8/*@1,1/drive@0/disk@0<br>
              (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]<br>
              (d4) Searching bootorder for:
              /pci@i0cf8/*@1,1/drive@0/disk@1<br>
              (d4) UHCI init on dev 00:1d.0 (io=3Dc240)<br>
              (d4) UHCI init on dev 00:1d.1 (io=3Dc260)<br>
              (d4) UHCI init on dev 00:1d.2 (io=3Dc280)<br>
              (d4) PS2 keyboard initialized<br>
              (d4) All threads complete.<br>
              (d4) Scan for option roms<br>
              (d4) Running option rom at c980:0003<br>
              (d4) pmm call arg1=3D1<br>
              (d4) pmm call arg1=3D0<br>
              (d4) pmm call arg1=3D1<br>
              (d4) pmm call arg1=3D0<br>
              (d4) Searching bootorder for: /pci@i0cf8/*@6<br>
              (d4) <br>
              (d4) Press F12 for boot menu.<br>
              (d4) <br>
              (d4) Searching bootorder for: HALT<br>
              (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba
              LCHS=3D1024/255/63 s=3D102400000<br>
              (d4) <br>
              (d4) Space available for UMB: ca800-ee800, f0000-f0ce0<br>
              (d4) Returned 258048 bytes of ZoneHigh<br>
              (d4) e820 map has 6 items:<br>
              (d4)=A0=A0 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM<br>
              (d4)=A0=A0 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED<br>
              (d4)=A0=A0 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED<br>
              (d4)=A0=A0 3: 0000000000100000 - 0000000077fff000 =3D 1 RAM<br>
              (d4)=A0=A0 4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED<br>
              (d4)=A0=A0 5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED<br>
              (d4) enter handle_19:<br>
              (d4)=A0=A0 NULL<br>
              (d4) Booting from DVD/CD...<br>
              (d4) Device reports MEDIUM NOT PRESENT<br>
              (d4) scsi_is_ready returned -1<br>
              (d4) Boot failed: Could not read from CDROM (code 0003)<br>
              (d4) enter handle_18:<br>
              (d4)=A0=A0 NULL<br>
              (d4) Booting from Hard Disk...<br>
              (d4) Booting from 0000:7c00<br>
              (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6
              minor: 1 sp: 1 build: 1db1<br>
              (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff<br>
              (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe<br>
              (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd<br>
              (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -&gt; 0<br>
              (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -&gt; 0<br>
              (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -&gt; 0<br>
              (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -&gt; 0<br>
              <b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><b><br>
              </b><b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><br>
              (XEN) irq.c:380: Dom4 callback via changed to GSI 24<br>
              (XEN) HVM4 save: CPU<br>
              (XEN) HVM4 save: PIC<br>
              (XEN) HVM4 save: IOAPIC<br>
              (XEN) HVM4 save: LAPIC<br>
              (XEN) HVM4 save: LAPIC_REGS<br>
              (XEN) HVM4 save: PCI_IRQ<br>
              (XEN) HVM4 save: ISA_IRQ<br>
              (XEN) HVM4 save: PCI_LINK<br>
              (XEN) HVM4 save: PIT<br>
              (XEN) HVM4 save: RTC<br>
              (XEN) HVM4 save: HPET<br>
              (XEN) HVM4 save: PMTIMER<br>
              (XEN) HVM4 save: MTRR<br>
              (XEN) HVM4 save: VIRIDIAN_DOMAIN<br>
              (XEN) HVM4 save: CPU_XSAVE<br>
              (XEN) HVM4 save: VIRIDIAN_VCPU<br>
              (XEN) HVM4 save: VMCE_VCPU<br>
              (XEN) HVM4 save: TSC_ADJUST<br>
              (XEN) HVM5 restore: CPU 0<br>
              (XEN) HVM5 restore: CPU 1<br>
              (XEN) HVM5 restore: PIC 0<br>
              (XEN) HVM5 restore: PIC 1<br>
              (XEN) HVM5 restore: IOAPIC 0<br>
              (XEN) HVM5 restore: LAPIC 0<br>
              (XEN) HVM5 restore: LAPIC 1<br>
              (XEN) HVM5 restore: LAPIC_REGS 0<br>
              (XEN) HVM5 restore: LAPIC_REGS 1<br>
              (XEN) HVM5 restore: PCI_IRQ 0<br>
              (XEN) HVM5 restore: ISA_IRQ 0<br>
              (XEN) HVM5 restore: PCI_LINK 0<br>
              (XEN) HVM5 restore: PIT 0<br>
              (XEN) HVM5 restore: RTC 0<br>
              (XEN) HVM5 restore: HPET 0<br>
              (XEN) HVM5 restore: PMTIMER 0<br>
              (XEN) HVM5 restore: MTRR 0<br>
              (XEN) HVM5 restore: MTRR 1<br>
              (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0<br>
              (XEN) HVM5 restore: VIRIDIAN_VCPU 0<br>
              (XEN) HVM5 restore: VIRIDIAN_VCPU 1<br>
              (XEN) HVM5 restore: VMCE_VCPU 0<br>
              (XEN) HVM5 restore: VMCE_VCPU 1<br>
              (XEN) HVM5 restore: TSC_ADJUST 0<br>
              (XEN) HVM5 restore: TSC_ADJUST 1<br>
              (XEN) irq.c:380: Dom5 callback via changed to None<br>
              <b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
              </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
              </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
              </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><br>
              (XEN) irq.c:380: Dom5 callback via changed to GSI 24</blockquote>
            <br>
            <br>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------040901030006070203030403--


--===============6722474865592102136==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6722474865592102136==--


From xen-devel-bounces@lists.xen.org Fri Nov 21 14:43:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:43:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpR6-00049B-Rr; Fri, 21 Nov 2014 14:43:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XrpR4-00048v-M8
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 14:43:47 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	D3/D2-14214-2AF4F645; Fri, 21 Nov 2014 14:43:46 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416581021!12685781!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12190 invoked from network); 21 Nov 2014 14:43:41 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:43:41 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so12228050wiv.0
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Nov 2014 06:43:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=RIAF3i6JGfzuvTHCaUfrFL+odE+h7JSRHpiRHEDqka8=;
	b=Fe7xLfu71u8G3x4y5AlfNvOTFHn6kNz1045jxrtgZaYghQDoQFxb660QoIxddM5egS
	Wkm/Iui0tIMPVRa8ZZhWC3KUzv663tWSROdndxnH8RcHCnzXzg/BJGiImCL3Jq05L8Lj
	3Fdb5ItU6e2TQio2fYxTQUFTr2w8ggTnVz7xw7GKXRKZBhry+Nr3lwJqfjOxAN7AA6Zq
	9nyBn35U2MmJPrZMwlFX3zUHkezh4kW6P2102PNpBCUAZ0UmGAfEIuVOS2NisHqomEMS
	EP3oP6YKBfD86jIsD/6uWhT3SVreh2qlLB9PlzyxK6Oz7ChZN3suLP2MicUp6P/ZdloV
	Lrxw==
X-Gm-Message-State: ALoCoQmuuj3/EIqeg6gjuGIEDgk7WKuaUKcYNLkPXAILFhsmPeHf7grpRszYtVXpx4XzA9ey+egh
X-Received: by 10.180.78.73 with SMTP id z9mr25899457wiw.52.1416581019993;
	Fri, 21 Nov 2014 06:43:39 -0800 (PST)
Received: from [192.168.1.15] ([83.211.73.126])
	by mx.google.com with ESMTPSA id w5sm9017753wif.18.2014.11.21.06.43.34
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 21 Nov 2014 06:43:39 -0800 (PST)
Message-ID: <546F4FA0.1070908@m2r.biz>
Date: Fri, 21 Nov 2014 15:43:44 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	spice-devel@lists.freedesktop.org
References: <53BBA83C.3010307@m2r.biz>
	<1404809604.30343.5.camel@cihla.spice.brq.redhat.com>
	<53BBC2AA.4030503@m2r.biz> <53BBC952.1040902@m2r.biz>
	<54130761.6080501@m2r.biz> <541C2D39.1060607@m2r.biz>
	<54648477.5040505@m2r.biz> <5464A27D.4020107@m2r.biz>
	<546DCEB4.5000205@m2r.biz> <546F1C8F.4020905@m2r.biz>
In-Reply-To: <546F1C8F.4020905@m2r.biz>
Cc: Anthony PERARD <anthony.perard@citrix.com>, kraxel@redhat.com,
	Jan Beulich <JBeulich@suse.com>,
	stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Spice-devel] screen freezed for 2-3 minutes on
 spice connect on xen windows 7 domU's with qxl after save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6722474865592102136=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6722474865592102136==
Content-Type: multipart/alternative;
 boundary="------------040901030006070203030403"

This is a multi-part message in MIME format.
--------------040901030006070203030403
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Length: 47184
Content-Transfer-Encoding: quoted-printable

Il 21/11/2014 12:05, Fabio Fantoni ha scritto:
> Il 20/11/2014 12:21, Fabio Fantoni ha scritto:
>> Il 13/11/2014 13:22, Fabio Fantoni ha scritto:
>>> Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
>>>> Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
>>>>> Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
>>>>>> Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
>>>>>>> Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
>>>>>>>> Il 08/07/2014 10:53, David Ja=9Aa ha scritto:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
>>>>>>>>>> On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
>>>>>>>>>> client with
>>>>>>>>>> spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good 
>>>>>>>>>> as kvm
>>>>>>>>>> except for one problem after xl save/restore, when after 
>>>>>>>>>> restore on
>>>>>>>>>> spice client connect  the domU's screen freezed for 2-3 
>>>>>>>>>> minutes (and
>>>>>>>>>> seems also windows), after this time seems that all return to 
>>>>>>>>>> works
>>>>>>>>>> correctly.
>>>>>>>>>> This problem happen also if spice client connect long time 
>>>>>>>>>> after restore.
>>>>>>>>>> With stdvga not have this problem but stdvga has many missed 
>>>>>>>>>> resolutions
>>>>>>>>>> and bad refresh performance.
>>>>>>>>>>
>>>>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>>>> Client and server logs would certainly help. Please run:
>>>>>>>>>    * virt-viewer with --spice-debug option
>>>>>>>>>    * spice-server with SPICE_DEBUG_LEVEL environment variable set
>>>>>>>>>      to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
>>>>>>>>> http://libvirt.org/drvqemu.html#qemucommand )
>>>>>>>>> and note the location in the logs where the freeze takes place.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>
>>>>>>>> Thanks for your reply, in attachments:
>>>>>>>> - domU's xl cfg: W7.cfg
>>>>>>>> - xl -vvv create/save/restore: xen logs.txt
>>>>>>>> - remote-viewer with --spice-debug after domU's start until xl 
>>>>>>>> save: spicelog-1.txt (zipped)
>>>>>>>> - remote-viewer with --spice-debug after domU's xl restore: 
>>>>>>>> spicelog-2.txt
>>>>>>>
>>>>>>> Sorry for my forgetfulness, here also qemu's log:
>>>>>>> - after domU's start until xl save: qemu-dm-W7.log.1
>>>>>>> - after domU's xl restore: qemu-dm-W7.log
>>>>>>>
>>>>>>>>
>>>>>>>> If you need more tests/informations tell me and I'll post them.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Spice-devel mailing list
>>>>>>>>> Spice-devel@lists.freedesktop.org
>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>>>>
>>>>>>
>>>>>> The problem persist, this time I saw these in xl dmesg after 
>>>>>> restore:
>>>>>>
>>>>>> (XEN) HVM2 restore: CPU 0
>>>>>> (XEN) HVM2 restore: CPU 1
>>>>>> (XEN) HVM2 restore: PIC 0
>>>>>> (XEN) HVM2 restore: PIC 1
>>>>>> (XEN) HVM2 restore: IOAPIC 0
>>>>>> (XEN) HVM2 restore: LAPIC 0
>>>>>> (XEN) HVM2 restore: LAPIC 1
>>>>>> (XEN) HVM2 restore: LAPIC_REGS 0
>>>>>> (XEN) HVM2 restore: LAPIC_REGS 1
>>>>>> (XEN) HVM2 restore: PCI_IRQ 0
>>>>>> (XEN) HVM2 restore: ISA_IRQ 0
>>>>>> (XEN) HVM2 restore: PCI_LINK 0
>>>>>> (XEN) HVM2 restore: PIT 0
>>>>>> (XEN) HVM2 restore: RTC 0
>>>>>> (XEN) HVM2 restore: HPET 0
>>>>>> (XEN) HVM2 restore: PMTIMER 0
>>>>>> (XEN) HVM2 restore: MTRR 0
>>>>>> (XEN) HVM2 restore: MTRR 1
>>>>>> (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
>>>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 0
>>>>>> (XEN) HVM2 restore: VIRIDIAN_VCPU 1
>>>>>> (XEN) HVM2 restore: VMCE_VCPU 0
>>>>>> (XEN) HVM2 restore: VMCE_VCPU 1
>>>>>> (XEN) HVM2 restore: TSC_ADJUST 0
>>>>>> (XEN) HVM2 restore: TSC_ADJUST 1
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
>>>>>> (XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
>>>>>> (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from 
>>>>>> (4) to (32) frames.
>>>>>> (XEN) irq.c:380: Dom2 callback via changed to GSI 24
>>>>>>
>>>>>> Tested on latest staging (commit 
>>>>>> 7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:
>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>>>>>>
>>>>>> If you need more informations or tests tell me and I'll post them.
>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>
>>>>> I did another tests updating to latest git staging (commit 
>>>>> 3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore problem of 
>>>>> "only" 2-3 minutes but now when it appears to restart (after 2-3 
>>>>> minutes) windows domUs undefinitely hangs instead.
>>>>> No further details in xen and domU's logs.
>>>>>
>>>>> If you need more tests/details tell me and I'll do them.
>>>>>
>>>>> Thanks for any reply.
>>>>
>>>> I did a new test with xen build based on tag 4.5.0-rc2 and on xl 
>>>> dmesg show these errors:
>>>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>>>> Before and after save/restore, with stdvga instead not show them.
>>>
>>> Sorry, I found that was introduced by new winpv drivers update 
>>> instead and I solved applying this patch:
>>> x86/hvm: Add per-vcpu evtchn upcalls v3 
>>> http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html
>>> About save/restore problem with qxl I still not found a solution or 
>>> at least the exact cause :(
>>
>> I tried a strace on qemu process when windows (in domU) is in temp. 
>> freeze and still does many operations (seems similar), I post below a 
>> small part if can be useful.
>> I noted for example some of these lines:
>> read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
>> temporarily unavailable)
>> Is it normal=3F
>>
>> ...
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 4197512}, NULL, 8) =3D 
>> 2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 4193071})
>> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
>> read(30, "W\0\0\0", 4)                  =3D 4
>> write(30, "W\0\0\0", 4)                 =3D 4
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0
>> gettimeofday({1416480295, 28658}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0
>> gettimeofday({1416480295, 28811}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1 
>> ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})
>> *read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
>> temporarily unavailable)*
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
>> clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D 0x7f4a3b2cc000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D 0x7f4a3b2cb000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D 0x7f4a3b2ca000
>> clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D 0x7f4a3b2c9000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D 0x7f4a3b2c8000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D 0x7f4a3b2c7000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D 0x7f4a3b2c6000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D 0x7f4a3b2c5000
>> clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D 0x7f4a3b2c4000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D 0x7f4a3b2c3000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D 0x7f4a3b2c2000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D 0x7f4a3b2c1000
>> clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> read(6, "\1\0\0\0\0\0\0\0", 512)        =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0
>> gettimeofday({1416480295, 35292}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0
>> gettimeofday({1416480295, 35746}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0
>> gettimeofday({1416480295, 35898}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 13233688}, NULL, 8) =3D 
>> 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 13227138})
>> read(20, 
>> "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"..., 
>> 69632) =3D 101
>> clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0
>> gettimeofday({1416480295, 36400}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0
>> gettimeofday({1416480295, 36550}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 12581076}, NULL, 8) =3D 
>> 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 12576281})
>> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
>> read(20, 
>> "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"..., 
>> 69632) =3D 101
>> clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0
>> gettimeofday({1416480295, 37123}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0
>> gettimeofday({1416480295, 37273}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 11857546}, NULL, 8) =3D 
>> 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 9477611})
>> *read(8, 0x7fffb5d09ac0, 16)             =3D -1 EAGAIN (Resource 
>> temporarily unavailable)*
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> read(6, "\5\0\0\0\0\0\0\0", 512)        =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0
>> gettimeofday({1416480295, 40643}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0
>> gettimeofday({1416480295, 40946}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0
>> gettimeofday({1416480295, 41097}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1 
>> ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d4000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d3000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d2000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d1000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d0000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2cf000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2ce000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2cd000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2cc000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2cb000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2ca000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c9000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c8000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c7000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c6000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c5000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b435000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b434000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b433000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b432000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2db000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2da000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d9000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d8000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d7000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d6000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d5000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0
>> gettimeofday({1416480295, 48329}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0
>> gettimeofday({1416480295, 48632}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0
>> gettimeofday({1416480295, 48783}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2 
>> ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})
>> read(8, "\4\0\0\0\0\0\0\0", 16)         =3D 8
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c4000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c3000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c2000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2c1000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D 0x7f4a3b435000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D 0x7f4a3b434000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D 0x7f4a3b433000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D 0x7f4a3b432000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D 0x7f4a3b2db000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D 0x7f4a3b2da000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D 0x7f4a3b2d9000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D 0x7f4a3b2d8000
>> clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0
>> gettimeofday({1416480295, 52051}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0
>> gettimeofday({1416480295, 52426}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0
>> gettimeofday({1416480295, 52576}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1 
>> ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})
>> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D 0x7f4a3b2d7000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D 0x7f4a3b2d6000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D 0x7f4a3b2d5000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D 0x7f4a3b2d4000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D 0x7f4a3b2d3000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D 0x7f4a3b2d2000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D 0x7f4a3b2d1000
>> clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D 0x7f4a3b2d0000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D 0x7f4a3b2cf000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D 0x7f4a3b2ce000
>> ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0
>> mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D 0x7f4a3b2cd000
>> clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0
>> futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1
>> clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0
>> gettimeofday({1416480295, 55341}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0
>> gettimeofday({1416480295, 55725}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0
>> gettimeofday({1416480295, 55876}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2 
>> ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})
>> read(8, "\2\0\0\0\0\0\0\0", 16)         =3D 8
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b435000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b434000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b433000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b432000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2db000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2da000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d9000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0
>> munmap(0x7f4a3b2d8000, 4096)            =3D 0
>> ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> write(6, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0
>> read(6, "\6\0\0\0\0\0\0\0", 512)        =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0
>> gettimeofday({1416480295, 58810}, NULL) =3D 0
>> write(8, "\1\0\0\0\0\0\0\0", 8)         =3D 8
>> clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0
>> gettimeofday({1416480295, 59114}, NULL) =3D 0
>> clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0
>> gettimeofday({1416480295, 59265}, NULL) =3D 0
>> ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5, 
>> events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9, 
>> events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2 
>> ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 0})
>> ...
>>
>> Strace of domU's qemu process during freeze can be useful=3F I must do 
>> a more specific tests=3F
>> If you need more informations/tests tell me and I'll post them.
>
> xen save/restore seems don't save hvm domUs vga's videoram but 
> kvm/qemu save yes, is it correct=3F
> can be the cause of problem and/or other problem=3F

I tried also remote-viewer with --spice-debug and after restore 
connecting with it show initial screen image correct, freeze after with 
line:
     (remote-viewer:3300): GSpice-DEBUG: channel-main.c:1185 main-1:0: 
monitor config: #0 1364x668+0+0 @ 32 bpp
and after some second spice screen become black and show these:
     (remote-viewer:3300): GSpice-DEBUG: channel-cursor.c:480 
cursor-4:0: cursor_handle_reset, init_done: 1
     (remote-viewer:3300): GSpice-DEBUG: channel-display.c:1744 
display-2:0: 0: FIXME primary destroy, but is display really disabled=3F

this can be related to the "freeze" or is only a conseguence=3F

>
>>
>> Thanks for any reply and sorry for my bad english.
>>
>>
>>>
>>>>
>>>> Below I posted full xl dmesg of domU, if you need more 
>>>> informations/tests tell me and I'll post them.
>>>>
>>>>
>>>>> (d4) HVM Loader
>>>>> (d4) Detected Xen v4.5.0-rc
>>>>> (d4) Xenbus rings @0xfeffc000, event channel 1
>>>>> (d4) System requested SeaBIOS
>>>>> (d4) CPU speed is 2660 MHz
>>>>> (d4) Relocating guest memory for lowmem MMIO space disabled
>>>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -> 5
>>>>> (d4) PCI-ISA link 0 routed to IRQ5
>>>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -> 10
>>>>> (d4) PCI-ISA link 1 routed to IRQ10
>>>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -> 11
>>>>> (d4) PCI-ISA link 2 routed to IRQ11
>>>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -> 5
>>>>> (d4) PCI-ISA link 3 routed to IRQ5
>>>>> (d4) pci dev 01:3 INTA->IRQ10
>>>>> (d4) pci dev 02:0 INTA->IRQ11
>>>>> (d4) pci dev 03:0 INTA->IRQ5
>>>>> (d4) pci dev 04:0 INTA->IRQ5
>>>>> (d4) pci dev 05:0 INTA->IRQ10
>>>>> (d4) pci dev 06:0 INTA->IRQ11
>>>>> (d4) pci dev 1d:0 INTA->IRQ10
>>>>> (d4) pci dev 1d:1 INTB->IRQ11
>>>>> (d4) pci dev 1d:2 INTC->IRQ5
>>>>> (d4) pci dev 1d:7 INTD->IRQ5
>>>>> (d4) No RAM in high memory; setting high_mem resource base to 
>>>>> 100000000
>>>>> (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000
>>>>> (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000
>>>>> (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008
>>>>> (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000
>>>>> (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000
>>>>> (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000
>>>>> (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000
>>>>> (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000
>>>>> (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000
>>>>> (d4) pci dev 02:0 bar 10 size 000000100: 00000c001
>>>>> (d4) pci dev 06:0 bar 10 size 000000100: 00000c101
>>>>> (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000
>>>>> (d4) pci dev 04:0 bar 10 size 000000020: 00000c201
>>>>> (d4) pci dev 05:0 bar 1c size 000000020: 00000c221
>>>>> (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241
>>>>> (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261
>>>>> (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281
>>>>> (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1
>>>>> (d4) Multiprocessor initialisation:
>>>>> (d4)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>>> ... done.
>>>>> (d4)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] 
>>>>> ... done.
>>>>> (d4) Testing HVM environment:
>>>>> (d4)  - REP INSB across page boundaries ... passed
>>>>> (d4)  - GS base MSRs and SWAPGS ... passed
>>>>> (d4) Passed 2 of 2 tests
>>>>> (d4) Writing SMBIOS tables ...
>>>>> (d4) Loading SeaBIOS ...
>>>>> (d4) Creating MP tables ...
>>>>> (d4) Loading ACPI ...
>>>>> (d4) S3 disabled
>>>>> (d4) S4 disabled
>>>>> (d4) vm86 TSS at fc00a100
>>>>> (d4) BIOS map:
>>>>> (d4)  10000-100d3: Scratch space
>>>>> (d4)  c0000-fffff: Main BIOS
>>>>> (d4) E820 table:
>>>>> (d4)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
>>>>> (d4)  HOLE: 00000000:000a0000 - 00000000:000c0000
>>>>> (d4)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
>>>>> (d4)  [02]: 00000000:00100000 - 00000000:78000000: RAM
>>>>> (d4)  HOLE: 00000000:78000000 - 00000000:fc000000
>>>>> (d4)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>>>> (d4) Invoking SeaBIOS ...
>>>>> (d4) SeaBIOS (version 
>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>> (d4)
>>>>> (d4) Found Xen hypervisor signature at 40000100
>>>>> (d4) Running on QEMU (i440fx)
>>>>> (d4) xen: copy e820...
>>>>> (d4) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
>>>>> (d4) CPU Mhz=3D2661
>>>>> (d4) Found 13 PCI devices (max PCI bus is 00)
>>>>> (d4) Allocated Xen hypercall page at 77fff000
>>>>> (d4) Detected Xen v4.5.0-rc
>>>>> (d4) xen: copy BIOS tables...
>>>>> (d4) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
>>>>> (d4) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f0e40
>>>>> (d4) Copying PIR from 0x00010030 to 0x000f0dc0
>>>>> (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
>>>>> (d4) Using pmtimer, ioport 0xb008
>>>>> (d4) Scan for VGA option rom
>>>>> (d4) Running option rom at c000:0003
>>>>> (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes
>>>>> (d4) pmm call arg1=3D0
>>>>> (d4) Turning on vga text mode console
>>>>> (d4) SeaBIOS (version 
>>>>> debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
>>>>> (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838
>>>>> (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)
>>>>> (d4) Found 0 lpt ports
>>>>> (d4) Found 0 serial ports
>>>>> (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>>>>> (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>>>>> (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)
>>>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>>>>> (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
>>>>> (d4) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
>>>>> (d4) UHCI init on dev 00:1d.0 (io=3Dc240)
>>>>> (d4) UHCI init on dev 00:1d.1 (io=3Dc260)
>>>>> (d4) UHCI init on dev 00:1d.2 (io=3Dc280)
>>>>> (d4) PS2 keyboard initialized
>>>>> (d4) All threads complete.
>>>>> (d4) Scan for option roms
>>>>> (d4) Running option rom at c980:0003
>>>>> (d4) pmm call arg1=3D1
>>>>> (d4) pmm call arg1=3D0
>>>>> (d4) pmm call arg1=3D1
>>>>> (d4) pmm call arg1=3D0
>>>>> (d4) Searching bootorder for: /pci@i0cf8/*@6
>>>>> (d4)
>>>>> (d4) Press F12 for boot menu.
>>>>> (d4)
>>>>> (d4) Searching bootorder for: HALT
>>>>> (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba 
>>>>> LCHS=3D1024/255/63 s=3D102400000
>>>>> (d4)
>>>>> (d4) Space available for UMB: ca800-ee800, f0000-f0ce0
>>>>> (d4) Returned 258048 bytes of ZoneHigh
>>>>> (d4) e820 map has 6 items:
>>>>> (d4)   0: 0000000000000000 - 000000000009fc00 =3D 1 RAM
>>>>> (d4)   1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED
>>>>> (d4)   2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED
>>>>> (d4)   3: 0000000000100000 - 0000000077fff000 =3D 1 RAM
>>>>> (d4)   4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED
>>>>> (d4)   5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED
>>>>> (d4) enter handle_19:
>>>>> (d4)   NULL
>>>>> (d4) Booting from DVD/CD...
>>>>> (d4) Device reports MEDIUM NOT PRESENT
>>>>> (d4) scsi_is_ready returned -1
>>>>> (d4) Boot failed: Could not read from CDROM (code 0003)
>>>>> (d4) enter handle_18:
>>>>> (d4)   NULL
>>>>> (d4) Booting from Hard Disk...
>>>>> (d4) Booting from 0000:7c00
>>>>> (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 
>>>>> sp: 1 build: 1db1
>>>>> (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
>>>>> (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
>>>>> (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd
>>>>> (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -> 0
>>>>> (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -> 0
>>>>> (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -> 0
>>>>> (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -> 0
>>>>> *(XEN) hvm.c:6119:d4v1 Bad HVM op 23.**
>>>>> **(XEN) hvm.c:6119:d4v1 Bad HVM op 23.*
>>>>> (XEN) irq.c:380: Dom4 callback via changed to GSI 24
>>>>> (XEN) HVM4 save: CPU
>>>>> (XEN) HVM4 save: PIC
>>>>> (XEN) HVM4 save: IOAPIC
>>>>> (XEN) HVM4 save: LAPIC
>>>>> (XEN) HVM4 save: LAPIC_REGS
>>>>> (XEN) HVM4 save: PCI_IRQ
>>>>> (XEN) HVM4 save: ISA_IRQ
>>>>> (XEN) HVM4 save: PCI_LINK
>>>>> (XEN) HVM4 save: PIT
>>>>> (XEN) HVM4 save: RTC
>>>>> (XEN) HVM4 save: HPET
>>>>> (XEN) HVM4 save: PMTIMER
>>>>> (XEN) HVM4 save: MTRR
>>>>> (XEN) HVM4 save: VIRIDIAN_DOMAIN
>>>>> (XEN) HVM4 save: CPU_XSAVE
>>>>> (XEN) HVM4 save: VIRIDIAN_VCPU
>>>>> (XEN) HVM4 save: VMCE_VCPU
>>>>> (XEN) HVM4 save: TSC_ADJUST
>>>>> (XEN) HVM5 restore: CPU 0
>>>>> (XEN) HVM5 restore: CPU 1
>>>>> (XEN) HVM5 restore: PIC 0
>>>>> (XEN) HVM5 restore: PIC 1
>>>>> (XEN) HVM5 restore: IOAPIC 0
>>>>> (XEN) HVM5 restore: LAPIC 0
>>>>> (XEN) HVM5 restore: LAPIC 1
>>>>> (XEN) HVM5 restore: LAPIC_REGS 0
>>>>> (XEN) HVM5 restore: LAPIC_REGS 1
>>>>> (XEN) HVM5 restore: PCI_IRQ 0
>>>>> (XEN) HVM5 restore: ISA_IRQ 0
>>>>> (XEN) HVM5 restore: PCI_LINK 0
>>>>> (XEN) HVM5 restore: PIT 0
>>>>> (XEN) HVM5 restore: RTC 0
>>>>> (XEN) HVM5 restore: HPET 0
>>>>> (XEN) HVM5 restore: PMTIMER 0
>>>>> (XEN) HVM5 restore: MTRR 0
>>>>> (XEN) HVM5 restore: MTRR 1
>>>>> (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0
>>>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 0
>>>>> (XEN) HVM5 restore: VIRIDIAN_VCPU 1
>>>>> (XEN) HVM5 restore: VMCE_VCPU 0
>>>>> (XEN) HVM5 restore: VMCE_VCPU 1
>>>>> (XEN) HVM5 restore: TSC_ADJUST 0
>>>>> (XEN) HVM5 restore: TSC_ADJUST 1
>>>>> (XEN) irq.c:380: Dom5 callback via changed to None
>>>>> *(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.**
>>>>> **(XEN) hvm.c:6119:d5v0 Bad HVM op 23.*
>>>>> (XEN) irq.c:380: Dom5 callback via changed to GSI 24
>>>>
>>>>
>>>
>>
>


--------------040901030006070203030403
Content-Type: text/html; charset=windows-1252
Content-Length: 62486
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Il 21/11/2014 12:05, Fabio Fantoni ha
      scritto:<br>
    </div>
    <blockquote cite=3D"mid:546F1C8F.4020905@m2r.biz" type=3D"cite">
      <meta content=3D"text/html; charset=3Dwindows-1252"
        http-equiv=3D"Content-Type">
      <div class=3D"moz-cite-prefix">Il 20/11/2014 12:21, Fabio Fantoni ha
        scritto:<br>
      </div>
      <blockquote cite=3D"mid:546DCEB4.5000205@m2r.biz" type=3D"cite">
        <meta content=3D"text/html; charset=3Dwindows-1252"
          http-equiv=3D"Content-Type">
        <div class=3D"moz-cite-prefix">Il 13/11/2014 13:22, Fabio Fantoni
          ha scritto:<br>
        </div>
        <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite">
          <meta content=3D"text/html; charset=3Dwindows-1252"
            http-equiv=3D"Content-Type">
          <div class=3D"moz-cite-prefix">Il 13/11/2014 11:14, Fabio
            Fantoni ha scritto:<br>
          </div>
          <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite">
            <meta content=3D"text/html; charset=3Dwindows-1252"
              http-equiv=3D"Content-Type">
            <div class=3D"moz-cite-prefix">Il 19/09/2014 15:18, Fabio
              Fantoni ha scritto:<br>
            </div>
            <blockquote cite=3D"mid:541C2D39.1060607@m2r.biz" type=3D"cite">Il

              12/09/2014 16:46, Fabio Fantoni ha scritto: <br>
              <blockquote type=3D"cite">Il 08/07/2014 12:34, Fabio Fantoni
                ha scritto: <br>
                <blockquote type=3D"cite">Il 08/07/2014 12:06, Fabio
                  Fantoni ha scritto: <br>
                  <blockquote type=3D"cite">Il 08/07/2014 10:53, David
                    Ja=9Aa ha scritto: <br>
                    <blockquote type=3D"cite">Hi, <br>
                      <br>
                      On =DAt, 2014-07-08 at 10:13 +0200, Fabio Fantoni
                      wrote: <br>
                      <blockquote type=3D"cite">On xen 4.5 (tried with
                        qemu 2.0.0/2.1-rc0, spice 0.12.5 and client with
                        <br>
                        spice-gtk 0.23/0.25) windows 7 domUs with qxl
                        vga works good as kvm <br>
                        except for one problem after xl save/restore,
                        when after restore on <br>
                        spice client connect=A0 the domU's screen freezed
                        for 2-3 minutes (and <br>
                        seems also windows), after this time seems that
                        all return to works <br>
                        correctly. <br>
                        This problem happen also if spice client connect
                        long time after restore. <br>
                        With stdvga not have this problem but stdvga has
                        many missed resolutions <br>
                        and bad refresh performance. <br>
                        <br>
                        If you need more tests/informations tell me and
                        I'll post them. <br>
                      </blockquote>
                      Client and server logs would certainly help.
                      Please run: <br>
                      =A0=A0 * virt-viewer with --spice-debug option <br>
                      =A0=A0 * spice-server with SPICE_DEBUG_LEVEL
                      environment variable set <br>
                      =A0=A0=A0=A0 to 4 or 5 (if you use qemu+libvirt, use
                      qemu:env element: <br>
                      =A0=A0=A0=A0 <a moz-do-not-send=3D"true"
                        class=3D"moz-txt-link-freetext"
                        href=3D"http://libvirt.org/drvqemu.html#qemucommand">http://libvirt.org/drvqemu.html#qemucommand</a>
                      ) <br>
                      and note the location in the logs where the freeze
                      takes place. <br>
                      <br>
                      Regards, <br>
                      <br>
                      David <br>
                    </blockquote>
                    <br>
                    Thanks for your reply, in attachments: <br>
                    - domU's xl cfg: W7.cfg <br>
                    - xl -vvv create/save/restore: xen logs.txt <br>
                    - remote-viewer with --spice-debug after domU's
                    start until xl save: spicelog-1.txt (zipped) <br>
                    - remote-viewer with --spice-debug after domU's xl
                    restore: spicelog-2.txt <br>
                  </blockquote>
                  <br>
                  Sorry for my forgetfulness, here also qemu's log: <br>
                  - after domU's start until xl save: qemu-dm-W7.log.1 <br>
                  - after domU's xl restore: qemu-dm-W7.log <br>
                  <br>
                  <blockquote type=3D"cite"> <br>
                    If you need more tests/informations tell me and I'll
                    post them. <br>
                    <br>
                    <br>
                    <blockquote type=3D"cite">Thanks for any reply and
                      sorry for my bad english. <br>
                      <br>
                      _______________________________________________ <br>
                      Spice-devel mailing list <br>
                      <a moz-do-not-send=3D"true"
                        class=3D"moz-txt-link-abbreviated"
                        href=3D"mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a>
                      <br>
                      <a moz-do-not-send=3D"true"
                        class=3D"moz-txt-link-freetext"
                        href=3D"http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a>
                      <br>
                    </blockquote>
                  </blockquote>
                  <br>
                </blockquote>
                <br>
                The problem persist, this time I saw these in xl dmesg
                after restore: <br>
                <br>
                (XEN) HVM2 restore: CPU 0 <br>
                (XEN) HVM2 restore: CPU 1 <br>
                (XEN) HVM2 restore: PIC 0 <br>
                (XEN) HVM2 restore: PIC 1 <br>
                (XEN) HVM2 restore: IOAPIC 0 <br>
                (XEN) HVM2 restore: LAPIC 0 <br>
                (XEN) HVM2 restore: LAPIC 1 <br>
                (XEN) HVM2 restore: LAPIC_REGS 0 <br>
                (XEN) HVM2 restore: LAPIC_REGS 1 <br>
                (XEN) HVM2 restore: PCI_IRQ 0 <br>
                (XEN) HVM2 restore: ISA_IRQ 0 <br>
                (XEN) HVM2 restore: PCI_LINK 0 <br>
                (XEN) HVM2 restore: PIT 0 <br>
                (XEN) HVM2 restore: RTC 0 <br>
                (XEN) HVM2 restore: HPET 0 <br>
                (XEN) HVM2 restore: PMTIMER 0 <br>
                (XEN) HVM2 restore: MTRR 0 <br>
                (XEN) HVM2 restore: MTRR 1 <br>
                (XEN) HVM2 restore: VIRIDIAN_DOMAIN 0 <br>
                (XEN) HVM2 restore: VIRIDIAN_VCPU 0 <br>
                (XEN) HVM2 restore: VIRIDIAN_VCPU 1 <br>
                (XEN) HVM2 restore: VMCE_VCPU 0 <br>
                (XEN) HVM2 restore: VMCE_VCPU 1 <br>
                (XEN) HVM2 restore: TSC_ADJUST 0 <br>
                (XEN) HVM2 restore: TSC_ADJUST 1 <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77579
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757a
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757b
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757c
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757d
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757e
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7757f
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77580
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77581
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77582
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77583
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77584
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77585
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77586
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77587
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77588
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77589
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758a
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758b
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758c
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758d
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758e
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 7758f
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77590
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77591
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77592
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77593
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77594
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77595
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77596
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77597
                invalid <br>
                (XEN) memory.c:216:d2v0 Domain 2 page number 77598
                invalid <br>
                (XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant
                table from (4) to (32) frames. <br>
                (XEN) irq.c:380: Dom2 callback via changed to GSI 24 <br>
                <br>
                Tested on latest staging (commit
                7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice
                patches: <br>
                <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a>
                <br>
                <br>
                If you need more informations or tests tell me and I'll
                post them. <br>
                Thanks for any reply and sorry for my bad english. <br>
              </blockquote>
              <br>
              I did another tests updating to latest git staging (commit
              3e2331d271cc0882e4013c8f20398c46c35f90a1) and is nomore
              problem of "only" 2-3 minutes but now when it appears to
              restart (after 2-3 minutes) windows domUs undefinitely
              hangs instead. <br>
              No further details in xen and domU's logs. <br>
              <br>
              If you need more tests/details tell me and I'll do them. <br>
              <br>
              Thanks for any reply. <br>
            </blockquote>
            <br>
            I did a new test with xen build based on tag 4.5.0-rc2 and
            on xl dmesg show these errors:<br>
            <blockquote type=3D"cite"><b>(XEN) hvm.c:6119:d5v0 Bad HVM op
                23.</b></blockquote>
            Before and after save/restore, with stdvga instead not show
            them.<br>
          </blockquote>
          <br>
          Sorry, I found that was introduced by new winpv drivers update
          instead and I solved applying this patch:<br>
          x86/hvm: Add per-vcpu evtchn upcalls v3 <a
            moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html">http://lists.xen.org/archives/html/xen-devel/2014-11/msg00752.html</a><br>
          About save/restore problem with qxl I still not found a
          solution or at least the exact cause :(<br>
        </blockquote>
        <br>
        I tried a strace on qemu process when windows (in domU) is in
        temp. freeze and still does many operations (seems similar), I
        post below a small part if can be useful.<br>
        I noted for example some of these lines:<br>
        read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
        temporarily unavailable)<br>
        Is it normal=3F<br>
        <br>
        ...<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 4197512}, NULL,
        8) =3D 2 ([{fd=3D30, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left
        {0, 4193071})<br>
        read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        read(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
        write(30, "W\0\0\0", 4)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 4<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 89449721}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 89526013}) =3D 0<br>
        gettimeofday({1416480295, 28658}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 89678802}) =3D 0<br>
        gettimeofday({1416480295, 28811}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
        ([{fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
        <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
          temporarily unavailable)</b><br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
        0x7f4a3b435000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
        0x7f4a3b434000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
        0x7f4a3b433000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
        0x7f4a3b432000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
        0x7f4a3b2db000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
        0x7f4a3b2da000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
        0x7f4a3b2d9000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
        0x7f4a3b2d8000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
        0x7f4a3b2d7000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
        0x7f4a3b2d6000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
        0x7f4a3b2d5000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 91880930}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
        0x7f4a3b2d4000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
        0x7f4a3b2d3000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
        0x7f4a3b2d2000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
        0x7f4a3b2d1000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
        0x7f4a3b2d0000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
        0x7f4a3b2cf000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
        0x7f4a3b2ce000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
        0x7f4a3b2cd000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x14000) =3D
        0x7f4a3b2cc000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x15000) =3D
        0x7f4a3b2cb000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x16000) =3D
        0x7f4a3b2ca000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 93792961}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x17000) =3D
        0x7f4a3b2c9000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x18000) =3D
        0x7f4a3b2c8000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x19000) =3D
        0x7f4a3b2c7000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1a000) =3D
        0x7f4a3b2c6000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1b000) =3D
        0x7f4a3b2c5000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 94895166}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1c000) =3D
        0x7f4a3b2c4000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1d000) =3D
        0x7f4a3b2c3000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1e000) =3D
        0x7f4a3b2c2000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1f000) =3D
        0x7f4a3b2c1000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 95826884}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        read(6, "\1\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96084347}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96160414}) =3D 0<br>
        gettimeofday({1416480295, 35292}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96389311}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96463937}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96539139}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96614031}) =3D 0<br>
        gettimeofday({1416480295, 35746}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 96766312}) =3D 0<br>
        gettimeofday({1416480295, 35898}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 13233688}, NULL,
        8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left
        {0, 13227138})<br>
        read(20,
        "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\302@\0"...,


        69632) =3D 101<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 97192856}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 97267978}) =3D 0<br>
        gettimeofday({1416480295, 36400}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 97418924}) =3D 0<br>
        gettimeofday({1416480295, 36550}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 12581076}, NULL,
        8) =3D 2 ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left
        {0, 12576281})<br>
        read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        read(20,
        "\2\0\0\0\0\0\0\0\0\0x+\313q\231\354\0\35r\336\233\326\10\0E\0\0Mp\303@\0"...,


        69632) =3D 101<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 97915644}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 97990808}) =3D 0<br>
        gettimeofday({1416480295, 37123}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 98142454}) =3D 0<br>
        gettimeofday({1416480295, 37273}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 11857546}, NULL,
        8) =3D 1 ([{fd=3D6, revents=3DPOLLIN}], left {0, 9477611})<br>
        <b>read(8, 0x7fffb5d09ac0, 16)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D -1 EAGAIN (Resource
          temporarily unavailable)</b><br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        read(6, "\5\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 101436871}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 101511629}) =3D 0<br>
        gettimeofday({1416480295, 40643}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 101739580}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 101814222}) =3D 0<br>
        gettimeofday({1416480295, 40946}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 101966019}) =3D 0<br>
        gettimeofday({1416480295, 41097}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
        ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d0000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2cf000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2ce000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2cd000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2cc000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2cb000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2ca000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 104926625}) =3D 0<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 106215131}) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d7000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d6000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d5000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 108790323}) =3D 0<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 109101155}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 109197529}) =3D 0<br>
        gettimeofday({1416480295, 48329}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 109425673}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 109500338}) =3D 0<br>
        gettimeofday({1416480295, 48632}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 109652242}) =3D 0<br>
        gettimeofday({1416480295, 48783}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
        ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
        read(8, "\4\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c4000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c3000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c2000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2c1000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 111044545}) =3D 0<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x1000) =3D
        0x7f4a3b435000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x2000) =3D
        0x7f4a3b434000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x3000) =3D
        0x7f4a3b433000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x4000) =3D
        0x7f4a3b432000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x5000) =3D
        0x7f4a3b2db000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x6000) =3D
        0x7f4a3b2da000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x7000) =3D
        0x7f4a3b2d9000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x8000) =3D
        0x7f4a3b2d8000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 112505496}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 112845620}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 112919875}) =3D 0<br>
        gettimeofday({1416480295, 52051}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 113146496}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 113220805}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 113295291}) =3D 0<br>
        gettimeofday({1416480295, 52426}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 113444996}) =3D 0<br>
        gettimeofday({1416480295, 52576}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 1
        ([{fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
        read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x9000) =3D
        0x7f4a3b2d7000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xa000) =3D
        0x7f4a3b2d6000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xb000) =3D
        0x7f4a3b2d5000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xc000) =3D
        0x7f4a3b2d4000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xd000) =3D
        0x7f4a3b2d3000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xe000) =3D
        0x7f4a3b2d2000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0xf000) =3D
        0x7f4a3b2d1000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 115162643}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x10000) =3D
        0x7f4a3b2d0000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x11000) =3D
        0x7f4a3b2cf000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x12000) =3D
        0x7f4a3b2ce000<br>
        ioctl(31, GIGASET_REDIR, 0x7fffb5d09700) =3D 0<br>
        mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, 31, 0x13000) =3D
        0x7f4a3b2cd000<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 115964897}) =3D 0<br>
        futex(0x7f4a3d396708, FUTEX_WAKE_PRIVATE, 1) =3D 1<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116134364}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116209521}) =3D 0<br>
        gettimeofday({1416480295, 55341}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116437231}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116519253}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116594135}) =3D 0<br>
        gettimeofday({1416480295, 55725}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 116744907}) =3D 0<br>
        gettimeofday({1416480295, 55876}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
        ([{fd=3D8, revents=3DPOLLIN}, {fd=3D6, revents=3DPOLLIN}], left {0, 0})<br>
        read(8, "\2\0\0\0\0\0\0\0", 16)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b435000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b434000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b433000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b432000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2db000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2da000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d9000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        ioctl(31, GIGASET_BRKCHARS, 0x7fffb5d098a0) =3D 0<br>
        munmap(0x7f4a3b2d8000, 4096)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0<br>
        ioctl(31, GIGASET_CONFIG, 0x7fffb5d09890) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 119055248}) =3D 0<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        write(6, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        ioctl(30, EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fffb5d098b0) =3D 0<br>
        read(6, "\6\0\0\0\0\0\0\0", 512)=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 119599841}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 119676398}) =3D 0<br>
        gettimeofday({1416480295, 58810}, NULL) =3D 0<br>
        write(8, "\1\0\0\0\0\0\0\0", 8)=A0=A0=A0=A0=A0=A0=A0=A0 =3D 8<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 119906131}) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 119981106}) =3D 0<br>
        gettimeofday({1416480295, 59114}, NULL) =3D 0<br>
        clock_gettime(CLOCK_MONOTONIC, {699, 120133916}) =3D 0<br>
        gettimeofday({1416480295, 59265}, NULL) =3D 0<br>
        ppoll([{fd=3D45, events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D44,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D42,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D40,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D39,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D38,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D37,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D36,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D30,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D22,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D25,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D20,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D19,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D14,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D5,
        events=3DPOLLIN|POLLERR|POLLHUP}, {fd=3D8, events=3DPOLLIN}, {fd=3D9,
        events=3DPOLLIN}, {fd=3D6, events=3DPOLLIN}], 18, {0, 0}, NULL, 8) =3D 2
        ([{fd=3D20, revents=3DPOLLIN}, {fd=3D8, revents=3DPOLLIN}], left {0, 0})<br>
        ...<br>
        <br>
        Strace of domU's qemu process during freeze can be useful=3F I
        must do a more specific tests=3F<br>
        If you need more informations/tests tell me and I'll post them.<br>
      </blockquote>
      <br>
      <span>xen save/restore seems don't save hvm domUs vga's videoram
        but kvm/qemu save yes, is it correct=3F<br>
        can be the cause of problem and/or other problem=3F<br>
      </span></blockquote>
    <br>
    I tried also remote-viewer with --spice-debug and after restore
    connecting with it show initial screen image correct, freeze after
    with line:<br>
    =A0=A0=A0 (remote-viewer:3300): GSpice-DEBUG: channel-main.c:1185
    main-1:0: monitor config: #0 1364x668+0+0 @ 32 bpp<br>
    and after some second spice screen become black and show these:<br>
    =A0=A0=A0 (remote-viewer:3300): GSpice-DEBUG: channel-cursor.c:480
    cursor-4:0: cursor_handle_reset, init_done: 1<br>
    =A0=A0=A0 (remote-viewer:3300): GSpice-DEBUG: channel-display.c:1744
    display-2:0: 0: FIXME primary destroy, but is display really
    disabled=3F<br>
    <br>
    <span>this can be related to the "freeze" or is only a conseguence=3F</span><br>
    <br>
    <blockquote cite=3D"mid:546F1C8F.4020905@m2r.biz" type=3D"cite"><span> </span><br>
      <blockquote cite=3D"mid:546DCEB4.5000205@m2r.biz" type=3D"cite"> <br>
        Thanks for any reply and sorry for my bad english.<br>
        <br>
        <br>
        <blockquote cite=3D"mid:5464A27D.4020107@m2r.biz" type=3D"cite"> <br>
          <blockquote cite=3D"mid:54648477.5040505@m2r.biz" type=3D"cite"> <br>
            Below I posted full xl dmesg of domU, if you need more
            informations/tests tell me and I'll post them.<br>
            <br>
            <br>
            <blockquote type=3D"cite">(d4) HVM Loader<br>
              (d4) Detected Xen v4.5.0-rc<br>
              (d4) Xenbus rings @0xfeffc000, event channel 1<br>
              (d4) System requested SeaBIOS<br>
              (d4) CPU speed is 2660 MHz<br>
              (d4) Relocating guest memory for lowmem MMIO space
              disabled<br>
              (XEN) irq.c:270: Dom4 PCI link 0 changed 0 -&gt; 5<br>
              (d4) PCI-ISA link 0 routed to IRQ5<br>
              (XEN) irq.c:270: Dom4 PCI link 1 changed 0 -&gt; 10<br>
              (d4) PCI-ISA link 1 routed to IRQ10<br>
              (XEN) irq.c:270: Dom4 PCI link 2 changed 0 -&gt; 11<br>
              (d4) PCI-ISA link 2 routed to IRQ11<br>
              (XEN) irq.c:270: Dom4 PCI link 3 changed 0 -&gt; 5<br>
              (d4) PCI-ISA link 3 routed to IRQ5<br>
              (d4) pci dev 01:3 INTA-&gt;IRQ10<br>
              (d4) pci dev 02:0 INTA-&gt;IRQ11<br>
              (d4) pci dev 03:0 INTA-&gt;IRQ5<br>
              (d4) pci dev 04:0 INTA-&gt;IRQ5<br>
              (d4) pci dev 05:0 INTA-&gt;IRQ10<br>
              (d4) pci dev 06:0 INTA-&gt;IRQ11<br>
              (d4) pci dev 1d:0 INTA-&gt;IRQ10<br>
              (d4) pci dev 1d:1 INTB-&gt;IRQ11<br>
              (d4) pci dev 1d:2 INTC-&gt;IRQ5<br>
              (d4) pci dev 1d:7 INTD-&gt;IRQ5<br>
              (d4) No RAM in high memory; setting high_mem resource base
              to 100000000<br>
              (d4) pci dev 05:0 bar 10 size 004000000: 0f0000000<br>
              (d4) pci dev 05:0 bar 14 size 004000000: 0f4000000<br>
              (d4) pci dev 02:0 bar 14 size 001000000: 0f8000008<br>
              (d4) pci dev 06:0 bar 30 size 000040000: 0f9000000<br>
              (d4) pci dev 05:0 bar 30 size 000010000: 0f9040000<br>
              (d4) pci dev 03:0 bar 10 size 000004000: 0f9050000<br>
              (d4) pci dev 05:0 bar 18 size 000002000: 0f9054000<br>
              (d4) pci dev 04:0 bar 14 size 000001000: 0f9056000<br>
              (d4) pci dev 1d:7 bar 10 size 000001000: 0f9057000<br>
              (d4) pci dev 02:0 bar 10 size 000000100: 00000c001<br>
              (d4) pci dev 06:0 bar 10 size 000000100: 00000c101<br>
              (d4) pci dev 06:0 bar 14 size 000000100: 0f9058000<br>
              (d4) pci dev 04:0 bar 10 size 000000020: 00000c201<br>
              (d4) pci dev 05:0 bar 1c size 000000020: 00000c221<br>
              (d4) pci dev 1d:0 bar 20 size 000000020: 00000c241<br>
              (d4) pci dev 1d:1 bar 20 size 000000020: 00000c261<br>
              (d4) pci dev 1d:2 bar 20 size 000000020: 00000c281<br>
              (d4) pci dev 01:1 bar 20 size 000000010: 00000c2a1<br>
              (d4) Multiprocessor initialisation:<br>
              (d4)=A0 - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs
              [1/8] ... done.<br>
              (d4)=A0 - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs
              [1/8] ... done.<br>
              (d4) Testing HVM environment:<br>
              (d4)=A0 - REP INSB across page boundaries ... passed<br>
              (d4)=A0 - GS base MSRs and SWAPGS ... passed<br>
              (d4) Passed 2 of 2 tests<br>
              (d4) Writing SMBIOS tables ...<br>
              (d4) Loading SeaBIOS ...<br>
              (d4) Creating MP tables ...<br>
              (d4) Loading ACPI ...<br>
              (d4) S3 disabled<br>
              (d4) S4 disabled<br>
              (d4) vm86 TSS at fc00a100<br>
              (d4) BIOS map:<br>
              (d4)=A0 10000-100d3: Scratch space<br>
              (d4)=A0 c0000-fffff: Main BIOS<br>
              (d4) E820 table:<br>
              (d4)=A0 [00]: 00000000:00000000 - 00000000:000a0000: RAM<br>
              (d4)=A0 HOLE: 00000000:000a0000 - 00000000:000c0000<br>
              (d4)=A0 [01]: 00000000:000c0000 - 00000000:00100000:
              RESERVED<br>
              (d4)=A0 [02]: 00000000:00100000 - 00000000:78000000: RAM<br>
              (d4)=A0 HOLE: 00000000:78000000 - 00000000:fc000000<br>
              (d4)=A0 [03]: 00000000:fc000000 - 00000001:00000000:
              RESERVED<br>
              (d4) Invoking SeaBIOS ...<br>
              (d4) SeaBIOS (version
              debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
              (d4) <br>
              (d4) Found Xen hypervisor signature at 40000100<br>
              (d4) Running on QEMU (i440fx)<br>
              (d4) xen: copy e820...<br>
              (d4) Relocating init from 0x000df619 to 0x77fae600 (size
              71995)<br>
              (d4) CPU Mhz=3D2661<br>
              (d4) Found 13 PCI devices (max PCI bus is 00)<br>
              (d4) Allocated Xen hypercall page at 77fff000<br>
              (d4) Detected Xen v4.5.0-rc<br>
              (d4) xen: copy BIOS tables...<br>
              (d4) Copying SMBIOS entry point from 0x00010010 to
              0x000f0f40<br>
              (d4) Copying MPTABLE from 0xfc001160/fc001170 to
              0x000f0e40<br>
              (d4) Copying PIR from 0x00010030 to 0x000f0dc0<br>
              (d4) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90<br>
              (d4) Using pmtimer, ioport 0xb008<br>
              (d4) Scan for VGA option rom<br>
              (d4) Running option rom at c000:0003<br>
              (XEN) stdvga.c:147:d4v0 entering stdvga and caching modes<br>
              (d4) pmm call arg1=3D0<br>
              (d4) Turning on vga text mode console<br>
              (d4) SeaBIOS (version
              debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)<br>
              (d4) Machine UUID 9d836955-983f-4413-89c3-6893ea19d838<br>
              (d4) EHCI init on dev 00:1d.7 (regs=3D0xf9057020)<br>
              (d4) Found 0 lpt ports<br>
              (d4) Found 0 serial ports<br>
              (d4) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)<br>
              (d4) ATA controller 2 at 170/374/0 (irq 15 dev 9)<br>
              (d4) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (50000 MiBytes)<br>
              (d4) Searching bootorder for:
              /pci@i0cf8/*@1,1/drive@0/disk@0<br>
              (d4) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]<br>
              (d4) Searching bootorder for:
              /pci@i0cf8/*@1,1/drive@0/disk@1<br>
              (d4) UHCI init on dev 00:1d.0 (io=3Dc240)<br>
              (d4) UHCI init on dev 00:1d.1 (io=3Dc260)<br>
              (d4) UHCI init on dev 00:1d.2 (io=3Dc280)<br>
              (d4) PS2 keyboard initialized<br>
              (d4) All threads complete.<br>
              (d4) Scan for option roms<br>
              (d4) Running option rom at c980:0003<br>
              (d4) pmm call arg1=3D1<br>
              (d4) pmm call arg1=3D0<br>
              (d4) pmm call arg1=3D1<br>
              (d4) pmm call arg1=3D0<br>
              (d4) Searching bootorder for: /pci@i0cf8/*@6<br>
              (d4) <br>
              (d4) Press F12 for boot menu.<br>
              (d4) <br>
              (d4) Searching bootorder for: HALT<br>
              (d4) drive 0x000f0d40: PCHS=3D16383/16/63 translation=3Dlba
              LCHS=3D1024/255/63 s=3D102400000<br>
              (d4) <br>
              (d4) Space available for UMB: ca800-ee800, f0000-f0ce0<br>
              (d4) Returned 258048 bytes of ZoneHigh<br>
              (d4) e820 map has 6 items:<br>
              (d4)=A0=A0 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM<br>
              (d4)=A0=A0 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED<br>
              (d4)=A0=A0 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED<br>
              (d4)=A0=A0 3: 0000000000100000 - 0000000077fff000 =3D 1 RAM<br>
              (d4)=A0=A0 4: 0000000077fff000 - 0000000078000000 =3D 2 RESERVED<br>
              (d4)=A0=A0 5: 00000000fc000000 - 0000000100000000 =3D 2 RESERVED<br>
              (d4) enter handle_19:<br>
              (d4)=A0=A0 NULL<br>
              (d4) Booting from DVD/CD...<br>
              (d4) Device reports MEDIUM NOT PRESENT<br>
              (d4) scsi_is_ready returned -1<br>
              (d4) Boot failed: Could not read from CDROM (code 0003)<br>
              (d4) enter handle_18:<br>
              (d4)=A0=A0 NULL<br>
              (d4) Booting from Hard Disk...<br>
              (d4) Booting from 0000:7c00<br>
              (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6
              minor: 1 sp: 1 build: 1db1<br>
              (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff<br>
              (XEN) d4v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe<br>
              (XEN) d4v1: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffd<br>
              (XEN) irq.c:270: Dom4 PCI link 0 changed 5 -&gt; 0<br>
              (XEN) irq.c:270: Dom4 PCI link 1 changed 10 -&gt; 0<br>
              (XEN) irq.c:270: Dom4 PCI link 2 changed 11 -&gt; 0<br>
              (XEN) irq.c:270: Dom4 PCI link 3 changed 5 -&gt; 0<br>
              <b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><b><br>
              </b><b>(XEN) hvm.c:6119:d4v1 Bad HVM op 23.</b><br>
              (XEN) irq.c:380: Dom4 callback via changed to GSI 24<br>
              (XEN) HVM4 save: CPU<br>
              (XEN) HVM4 save: PIC<br>
              (XEN) HVM4 save: IOAPIC<br>
              (XEN) HVM4 save: LAPIC<br>
              (XEN) HVM4 save: LAPIC_REGS<br>
              (XEN) HVM4 save: PCI_IRQ<br>
              (XEN) HVM4 save: ISA_IRQ<br>
              (XEN) HVM4 save: PCI_LINK<br>
              (XEN) HVM4 save: PIT<br>
              (XEN) HVM4 save: RTC<br>
              (XEN) HVM4 save: HPET<br>
              (XEN) HVM4 save: PMTIMER<br>
              (XEN) HVM4 save: MTRR<br>
              (XEN) HVM4 save: VIRIDIAN_DOMAIN<br>
              (XEN) HVM4 save: CPU_XSAVE<br>
              (XEN) HVM4 save: VIRIDIAN_VCPU<br>
              (XEN) HVM4 save: VMCE_VCPU<br>
              (XEN) HVM4 save: TSC_ADJUST<br>
              (XEN) HVM5 restore: CPU 0<br>
              (XEN) HVM5 restore: CPU 1<br>
              (XEN) HVM5 restore: PIC 0<br>
              (XEN) HVM5 restore: PIC 1<br>
              (XEN) HVM5 restore: IOAPIC 0<br>
              (XEN) HVM5 restore: LAPIC 0<br>
              (XEN) HVM5 restore: LAPIC 1<br>
              (XEN) HVM5 restore: LAPIC_REGS 0<br>
              (XEN) HVM5 restore: LAPIC_REGS 1<br>
              (XEN) HVM5 restore: PCI_IRQ 0<br>
              (XEN) HVM5 restore: ISA_IRQ 0<br>
              (XEN) HVM5 restore: PCI_LINK 0<br>
              (XEN) HVM5 restore: PIT 0<br>
              (XEN) HVM5 restore: RTC 0<br>
              (XEN) HVM5 restore: HPET 0<br>
              (XEN) HVM5 restore: PMTIMER 0<br>
              (XEN) HVM5 restore: MTRR 0<br>
              (XEN) HVM5 restore: MTRR 1<br>
              (XEN) HVM5 restore: VIRIDIAN_DOMAIN 0<br>
              (XEN) HVM5 restore: VIRIDIAN_VCPU 0<br>
              (XEN) HVM5 restore: VIRIDIAN_VCPU 1<br>
              (XEN) HVM5 restore: VMCE_VCPU 0<br>
              (XEN) HVM5 restore: VMCE_VCPU 1<br>
              (XEN) HVM5 restore: TSC_ADJUST 0<br>
              (XEN) HVM5 restore: TSC_ADJUST 1<br>
              (XEN) irq.c:380: Dom5 callback via changed to None<br>
              <b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
              </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
              </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><b><br>
              </b><b>(XEN) hvm.c:6119:d5v0 Bad HVM op 23.</b><br>
              (XEN) irq.c:380: Dom5 callback via changed to GSI 24</blockquote>
            <br>
            <br>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------040901030006070203030403--


--===============6722474865592102136==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6722474865592102136==--


From xen-devel-bounces@lists.xen.org Fri Nov 21 14:44:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:44:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpS6-0004EA-Lx; Fri, 21 Nov 2014 14:44:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrpS5-0004E1-ET
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:44:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DD/55-09842-0EF4F645; Fri, 21 Nov 2014 14:44:48 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416581086!14446197!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9274 invoked from network); 21 Nov 2014 14:44:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 14:44:48 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALEieBK015201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 14:44:41 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALEiUhV018653
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 14:44:35 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALEiS1Z018569; Fri, 21 Nov 2014 14:44:29 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 06:44:26 -0800
Message-ID: <546F5071.5070607@oracle.com>
Date: Fri, 21 Nov 2014 09:47:13 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416569185.20516.8.camel@Abyss>
In-Reply-To: <1416569185.20516.8.camel@Abyss>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 06:26 AM, Dario Faggioli wrote:
> On Thu, 2014-11-20 at 16:27 -0500, Boris Ostrovsky wrote:
>
>> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
>> index 58df4f3..2a08bef 100644
>> --- a/tools/libxl/libxl_utils.c
>> +++ b/tools/libxl/libxl_utils.c
>> @@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>>       memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>>   }
>>   
>> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
>> +                               const libxl_bitmap *sptr)
>> +{
>> +    assert(dptr->size >= sptr->size);
>> +    memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
>> +}
>> +
> Looking at other callers of libxl_bitmap_copy(), I think something like
> this makes sense for pretty much all of them.
>
> And even abstracting from them, and thinking to how a function like
> 'libxl_bitmap_copy()' this should behave, copying only the "common part"
> makes sense to me.
>
> So, should we make libxl_bitmap_copy() behave like implemented above,
> rather than introducing a new function. I know this is public stable
> API, but I think this is a fine behavioral change, isn't it?

I did consider this but wasn't sure about it from the point of view of 
API behavior. If people feel it's OK to slightly change behavior here 
I'd rather go this route.


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:44:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:44:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpS6-0004EA-Lx; Fri, 21 Nov 2014 14:44:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrpS5-0004E1-ET
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 14:44:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DD/55-09842-0EF4F645; Fri, 21 Nov 2014 14:44:48 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416581086!14446197!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9274 invoked from network); 21 Nov 2014 14:44:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 14:44:48 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALEieBK015201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 14:44:41 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALEiUhV018653
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 14:44:35 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALEiS1Z018569; Fri, 21 Nov 2014 14:44:29 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 06:44:26 -0800
Message-ID: <546F5071.5070607@oracle.com>
Date: Fri, 21 Nov 2014 09:47:13 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416569185.20516.8.camel@Abyss>
In-Reply-To: <1416569185.20516.8.camel@Abyss>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 06:26 AM, Dario Faggioli wrote:
> On Thu, 2014-11-20 at 16:27 -0500, Boris Ostrovsky wrote:
>
>> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
>> index 58df4f3..2a08bef 100644
>> --- a/tools/libxl/libxl_utils.c
>> +++ b/tools/libxl/libxl_utils.c
>> @@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>>       memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>>   }
>>   
>> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
>> +                               const libxl_bitmap *sptr)
>> +{
>> +    assert(dptr->size >= sptr->size);
>> +    memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
>> +}
>> +
> Looking at other callers of libxl_bitmap_copy(), I think something like
> this makes sense for pretty much all of them.
>
> And even abstracting from them, and thinking to how a function like
> 'libxl_bitmap_copy()' this should behave, copying only the "common part"
> makes sense to me.
>
> So, should we make libxl_bitmap_copy() behave like implemented above,
> rather than introducing a new function. I know this is public stable
> API, but I think this is a fine behavioral change, isn't it?

I did consider this but wasn't sure about it from the point of view of 
API behavior. If people feel it's OK to slightly change behavior here 
I'd rather go this route.


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:45:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14: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 1XrpT0-0004KG-3e; Fri, 21 Nov 2014 14:45:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrpSz-0004K1-7W
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 14:45:45 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	31/E5-09936-8105F645; Fri, 21 Nov 2014 14:45:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416581142!14476358!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9610 invoked from network); 21 Nov 2014 14:45:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:45:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195260664"
Message-ID: <546F4FFF.1080101@citrix.com>
Date: Fri, 21 Nov 2014 14:45:19 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <546F4E86.8060801@suse.com>
In-Reply-To: <546F4E86.8060801@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 14:39, Juergen Gross wrote:
> Hi,
>
> again a fallout from my "linear p2m list" tests:
>
> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
> wrong device to the domain. The MMIO address was too large for a
> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>
> Instead of rejecting the operation Xen tried to perform it resulting
> in a (quite understandable) failure in the domU.
>
> I think either the hypervisor or the tools should refuse to do
> PCI-passthrough in this case.
>

What actually goes wrong?  Does the 32bit guest truncate the MMIO region
to 44 bits and try to map that?

I would completely agree that something (libxl?) should refuse this
attempt to do passthrough, but I think pci-front should also kick up a
fuss if it is able to detect this error.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:45:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14: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 1XrpT0-0004KG-3e; Fri, 21 Nov 2014 14:45:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XrpSz-0004K1-7W
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 14:45:45 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	31/E5-09936-8105F645; Fri, 21 Nov 2014 14:45:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416581142!14476358!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9610 invoked from network); 21 Nov 2014 14:45:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 14:45:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195260664"
Message-ID: <546F4FFF.1080101@citrix.com>
Date: Fri, 21 Nov 2014 14:45:19 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <546F4E86.8060801@suse.com>
In-Reply-To: <546F4E86.8060801@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 14:39, Juergen Gross wrote:
> Hi,
>
> again a fallout from my "linear p2m list" tests:
>
> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
> wrong device to the domain. The MMIO address was too large for a
> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>
> Instead of rejecting the operation Xen tried to perform it resulting
> in a (quite understandable) failure in the domU.
>
> I think either the hypervisor or the tools should refuse to do
> PCI-passthrough in this case.
>

What actually goes wrong?  Does the 32bit guest truncate the MMIO region
to 44 bits and try to map that?

I would completely agree that something (libxl?) should refuse this
attempt to do passthrough, but I think pci-front should also kick up a
fuss if it is able to detect this error.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:55:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:55:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpbm-0004iL-6p; Fri, 21 Nov 2014 14:54:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrpbk-0004i4-6s
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 14:54:48 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	22/4B-23865-7325F645; Fri, 21 Nov 2014 14:54:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416581686!9262871!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2707 invoked from network); 21 Nov 2014 14:54:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 14:54:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 14:54:46 +0000
Message-Id: <546F60470200007800049D06@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 14:54:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <546F4E86.8060801@suse.com>
In-Reply-To: <546F4E86.8060801@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
 addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 15:39, <JGross@suse.com> wrote:
> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
> wrong device to the domain. The MMIO address was too large for a
> MFN of a 32-bit system (it was 380003200000-3800036fffff).
> 
> Instead of rejecting the operation Xen tried to perform it resulting
> in a (quite understandable) failure in the domU.
> 
> I think either the hypervisor or the tools should refuse to do
> PCI-passthrough in this case.

What's wrong with this large an address? 32-bit PV uses PAE, i.e.
can map them. If the kernel isn't capable of that that's not
something to make Xen (or the tools) refuse such assignments. I
would only see an issue if a hypercall interface involved here isn't
using wide enough fields (but these addresses should be read
from the BARs, i.e. no hypercall involved).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 14:55:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 14:55:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpbm-0004iL-6p; Fri, 21 Nov 2014 14:54:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrpbk-0004i4-6s
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 14:54:48 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	22/4B-23865-7325F645; Fri, 21 Nov 2014 14:54:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416581686!9262871!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2707 invoked from network); 21 Nov 2014 14:54:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 14:54:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 14:54:46 +0000
Message-Id: <546F60470200007800049D06@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 14:54:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <546F4E86.8060801@suse.com>
In-Reply-To: <546F4E86.8060801@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
 addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 15:39, <JGross@suse.com> wrote:
> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
> wrong device to the domain. The MMIO address was too large for a
> MFN of a 32-bit system (it was 380003200000-3800036fffff).
> 
> Instead of rejecting the operation Xen tried to perform it resulting
> in a (quite understandable) failure in the domU.
> 
> I think either the hypervisor or the tools should refuse to do
> PCI-passthrough in this case.

What's wrong with this large an address? 32-bit PV uses PAE, i.e.
can map them. If the kernel isn't capable of that that's not
something to make Xen (or the tools) refuse such assignments. I
would only see an issue if a hypercall interface involved here isn't
using wide enough fields (but these addresses should be read
from the BARs, i.e. no hypercall involved).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:02:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpin-0004xv-34; Fri, 21 Nov 2014 15:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xrpim-0004xq-Kn
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:02:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BD/A1-09936-CE35F645; Fri, 21 Nov 2014 15:02:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416582121!14383561!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5847 invoked from network); 21 Nov 2014 15:02:03 -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 Nov 2014 15:02:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195266414"
Message-ID: <546F53B8.5040502@citrix.com>
Date: Fri, 21 Nov 2014 15:01:12 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Juergen Gross <JGross@suse.com>
References: <546F4E86.8060801@suse.com>
	<546F60470200007800049D06@mail.emea.novell.com>
In-Reply-To: <546F60470200007800049D06@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 14:54, Jan Beulich wrote:
>>>> On 21.11.14 at 15:39, <JGross@suse.com> wrote:
>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>> wrong device to the domain. The MMIO address was too large for a
>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>
>> Instead of rejecting the operation Xen tried to perform it resulting
>> in a (quite understandable) failure in the domU.
>>
>> I think either the hypervisor or the tools should refuse to do
>> PCI-passthrough in this case.
> What's wrong with this large an address?

It is wider than 44 bits, so doesn't fit in a 32bit pfn for p2m/m2p
update operations.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:02:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpin-0004xv-34; Fri, 21 Nov 2014 15:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xrpim-0004xq-Kn
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:02:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BD/A1-09936-CE35F645; Fri, 21 Nov 2014 15:02:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416582121!14383561!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5847 invoked from network); 21 Nov 2014 15:02:03 -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 Nov 2014 15:02:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195266414"
Message-ID: <546F53B8.5040502@citrix.com>
Date: Fri, 21 Nov 2014 15:01:12 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Juergen Gross <JGross@suse.com>
References: <546F4E86.8060801@suse.com>
	<546F60470200007800049D06@mail.emea.novell.com>
In-Reply-To: <546F60470200007800049D06@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 14:54, Jan Beulich wrote:
>>>> On 21.11.14 at 15:39, <JGross@suse.com> wrote:
>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>> wrong device to the domain. The MMIO address was too large for a
>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>
>> Instead of rejecting the operation Xen tried to perform it resulting
>> in a (quite understandable) failure in the domU.
>>
>> I think either the hypervisor or the tools should refuse to do
>> PCI-passthrough in this case.
> What's wrong with this large an address?

It is wider than 44 bits, so doesn't fit in a 32bit pfn for p2m/m2p
update operations.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:05:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 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.xen.org>)
	id 1Xrplc-0005AF-LV; Fri, 21 Nov 2014 15:05:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xrplb-0005A8-MW
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 15:04:59 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	DD/A1-02698-A945F645; Fri, 21 Nov 2014 15:04:58 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416582298!14014770!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22147 invoked from network); 21 Nov 2014 15:04:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:04:58 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B8CF9AB43;
	Fri, 21 Nov 2014 15:04:57 +0000 (UTC)
Message-ID: <546F5499.5000501@suse.com>
Date: Fri, 21 Nov 2014 16:04:57 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <546F4E86.8060801@suse.com> <546F4FFF.1080101@citrix.com>
In-Reply-To: <546F4FFF.1080101@citrix.com>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 03:45 PM, Andrew Cooper wrote:
> On 21/11/14 14:39, Juergen Gross wrote:
>> Hi,
>>
>> again a fallout from my "linear p2m list" tests:
>>
>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>> wrong device to the domain. The MMIO address was too large for a
>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>
>> Instead of rejecting the operation Xen tried to perform it resulting
>> in a (quite understandable) failure in the domU.
>>
>> I think either the hypervisor or the tools should refuse to do
>> PCI-passthrough in this case.
>>
>
> What actually goes wrong?  Does the 32bit guest truncate the MMIO region
> to 44 bits and try to map that?

I think it is 42 bits (the top 2 bits of the MFN are the "identity" and
"foreign" bits).

>
> I would completely agree that something (libxl?) should refuse this
> attempt to do passthrough, but I think pci-front should also kick up a
> fuss if it is able to detect this error.

Indeed.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:05:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 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.xen.org>)
	id 1Xrplc-0005AF-LV; Fri, 21 Nov 2014 15:05:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xrplb-0005A8-MW
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 15:04:59 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	DD/A1-02698-A945F645; Fri, 21 Nov 2014 15:04:58 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416582298!14014770!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22147 invoked from network); 21 Nov 2014 15:04:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:04:58 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B8CF9AB43;
	Fri, 21 Nov 2014 15:04:57 +0000 (UTC)
Message-ID: <546F5499.5000501@suse.com>
Date: Fri, 21 Nov 2014 16:04:57 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <546F4E86.8060801@suse.com> <546F4FFF.1080101@citrix.com>
In-Reply-To: <546F4FFF.1080101@citrix.com>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 03:45 PM, Andrew Cooper wrote:
> On 21/11/14 14:39, Juergen Gross wrote:
>> Hi,
>>
>> again a fallout from my "linear p2m list" tests:
>>
>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>> wrong device to the domain. The MMIO address was too large for a
>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>
>> Instead of rejecting the operation Xen tried to perform it resulting
>> in a (quite understandable) failure in the domU.
>>
>> I think either the hypervisor or the tools should refuse to do
>> PCI-passthrough in this case.
>>
>
> What actually goes wrong?  Does the 32bit guest truncate the MMIO region
> to 44 bits and try to map that?

I think it is 42 bits (the top 2 bits of the MFN are the "identity" and
"foreign" bits).

>
> I would completely agree that something (libxl?) should refuse this
> attempt to do passthrough, but I think pci-front should also kick up a
> fuss if it is able to detect this error.

Indeed.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnp-0005Ir-TG; Fri, 21 Nov 2014 15:07:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpno-0005I3-Ad
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:16 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	03/2C-25727-3255F645; Fri, 21 Nov 2014 15:07:15 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6931 invoked from network); 21 Nov 2014 15:07:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735622"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-JH;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:45 +0000
Message-ID: <1416582421-10789-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 03/19] libxc: allocate memory with vNUMA
	information 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxc/include/xc_dom.h |    5 +++
 tools/libxc/xc_dom_x86.c     |   72 +++++++++++++++++++++++++++++++++++-------
 tools/libxc/xc_private.h     |    2 ++
 3 files changed, 68 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6ae6a9f..eb8e2ce 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -162,6 +162,11 @@ struct xc_dom_image {
     struct xc_dom_loader *kernel_loader;
     void *private_loader;
 
+    /* vNUMA information */
+    unsigned int *vnode_to_pnode;
+    uint64_t *vnode_size;
+    unsigned int nr_vnodes;
+
     /* kernel loader */
     struct xc_dom_arch *arch_hooks;
     /* allocate up to virt_alloc_end */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index bf06fe4..3286232 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -759,7 +759,8 @@ static int x86_shadow(xc_interface *xch, domid_t domid)
 int arch_setup_meminit(struct xc_dom_image *dom)
 {
     int rc;
-    xen_pfn_t pfn, allocsz, i, j, mfn;
+    xen_pfn_t pfn, allocsz, mfn, total, pfn_base;
+    int i, j;
 
     rc = x86_compat(dom->xch, dom->guest_domid, dom->guest_type);
     if ( rc )
@@ -811,18 +812,67 @@ int arch_setup_meminit(struct xc_dom_image *dom)
         /* setup initial p2m */
         for ( pfn = 0; pfn < dom->total_pages; pfn++ )
             dom->p2m_host[pfn] = pfn;
-        
+
+        /* setup dummy vNUMA information if it's not provided */
+        if ( dom->nr_vnodes == 0 )
+        {
+            dom->nr_vnodes = 1;
+            dom->vnode_to_pnode = xc_dom_malloc(dom,
+                                                sizeof(*dom->vnode_to_pnode));
+            dom->vnode_to_pnode[0] = XC_VNUMA_NO_NODE;
+            dom->vnode_size = xc_dom_malloc(dom, sizeof(*dom->vnode_size));
+            dom->vnode_size[0] = ((dom->total_pages << PAGE_SHIFT) >> 20);
+        }
+
+        total = 0;
+        for ( i = 0; i < dom->nr_vnodes; i++ )
+            total += ((dom->vnode_size[i] << 20) >> PAGE_SHIFT);
+        if ( total != dom->total_pages )
+        {
+            xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+                         "%s: number of pages requested by vNUMA (0x%"PRIpfn") mismatches number of pages configured for domain (0x%"PRIpfn")\n",
+                         __FUNCTION__, total, dom->total_pages);
+            return -EINVAL;
+        }
+
         /* allocate guest memory */
-        for ( i = rc = allocsz = 0;
-              (i < dom->total_pages) && !rc;
-              i += allocsz )
+        pfn_base = 0;
+        for ( i = 0; i < dom->nr_vnodes; i++ )
         {
-            allocsz = dom->total_pages - i;
-            if ( allocsz > 1024*1024 )
-                allocsz = 1024*1024;
-            rc = xc_domain_populate_physmap_exact(
-                dom->xch, dom->guest_domid, allocsz,
-                0, 0, &dom->p2m_host[i]);
+            unsigned int memflags;
+            uint64_t pages;
+
+            memflags = 0;
+            if ( dom->vnode_to_pnode[i] != XC_VNUMA_NO_NODE )
+            {
+                memflags |= XENMEMF_exact_node(dom->vnode_to_pnode[i]);
+                memflags |= XENMEMF_exact_node_request;
+            }
+
+            pages = (dom->vnode_size[i] << 20) >> PAGE_SHIFT;
+
+            for ( j = 0; j < pages; j += allocsz )
+            {
+                allocsz = pages - j;
+                if ( allocsz > 1024*1024 )
+                    allocsz = 1024*1024;
+
+                rc = xc_domain_populate_physmap_exact(dom->xch,
+                         dom->guest_domid, allocsz, 0, memflags,
+                         &dom->p2m_host[pfn_base+j]);
+
+                if ( rc )
+                {
+                    if ( dom->vnode_to_pnode[i] != XC_VNUMA_NO_NODE )
+                        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+                                     "%s: fail to allocate 0x%"PRIx64" pages for vnode %d on pnode %d out of 0x%"PRIpfn"\n",
+                                     __FUNCTION__, pages, i,
+                                     dom->vnode_to_pnode[i], dom->total_pages);
+                    return rc;
+                }
+            }
+
+            pfn_base += pages;
         }
 
         /* Ensure no unclaimed pages are left unused.
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 45b8644..1809674 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -35,6 +35,8 @@
 
 #include <xen/sys/privcmd.h>
 
+#define XC_VNUMA_NO_NODE (~0U)
+
 #if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG) && !defined(__MINIOS__)
 /* Compile in Valgrind client requests? */
 #include <valgrind/memcheck.h>
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnr-0005K9-9h; Fri, 21 Nov 2014 15:07:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnp-0005II-8j
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:17 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	4F/83-11581-4255F645; Fri, 21 Nov 2014 15:07:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416582433!12681604!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20949 invoked from network); 21 Nov 2014 15:07:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735623"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-K0;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:46 +0000
Message-ID: <1416582421-10789-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 04/19] libxl: add emacs local variables in
	libxl_{x86, arm}.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_arm.c |    8 ++++++++
 tools/libxl/libxl_x86.c |    8 ++++++++
 2 files changed, 16 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 448ac07..34d21f5 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -706,3 +706,11 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
 
     return 0;
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 7589060..9ceb373 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -324,3 +324,11 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
 {
     return 0;
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnt-0005MR-1E; Fri, 21 Nov 2014 15:07:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnq-0005JL-TE
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:19 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	C6/3F-28296-5255F645; Fri, 21 Nov 2014 15:07:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7147 invoked from network); 21 Nov 2014 15:07:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735626"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Mi;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:50 +0000
Message-ID: <1416582421-10789-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 08/19] libxl: x86: factor out e820_host_sanitize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function gets the machine E820 map and sanitize it according to PV
guest configuration.

This will be used in later patch.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_x86.c |   31 ++++++++++++++++++++++---------
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 9ceb373..e959e37 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -207,6 +207,27 @@ static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
     return 0;
 }
 
+static int e820_host_sanitize(libxl__gc *gc,
+                              libxl_domain_build_info *b_info,
+                              struct e820entry map[],
+                              uint32_t *nr)
+{
+    int rc;
+
+    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);
+    return rc;
+}
+
 static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid,
         libxl_domain_config *d_config)
 {
@@ -223,15 +244,7 @@ static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid,
     if (!libxl_defbool_val(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);
+    rc = e820_host_sanitize(gc, b_info, map, &nr);
     if (rc)
         return ERROR_FAIL;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnp-0005Ib-Hw; Fri, 21 Nov 2014 15:07:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnn-0005Hu-D5
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:15 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	17/1F-28296-2255F645; Fri, 21 Nov 2014 15:07:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6836 invoked from network); 21 Nov 2014 15:07:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735620"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Ia;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:44 +0000
Message-ID: <1416582421-10789-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 02/19] xen: make two memory hypercalls
	vNUMA-aware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 XENMEM_increase_reservation and XENMEM_populate_physmap
vNUMA-aware.

That is, if guest requests Xen to allocate memory for specific vnode,
Xen can translate vnode to pnode using vNUMA information of that guest.

XENMEMF_vnode is introduced for the guest to mark the node number is in
fact virtual node number and should be translated by Xen.

XENFEAT_memory_op_vnode_supported is introduced to indicate that Xen is
able to translate virtual node to physical node.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 xen/common/memory.c           |   58 ++++++++++++++++++++++++++++++++++++++---
 xen/include/public/features.h |    3 +++
 xen/include/public/memory.h   |    2 ++
 3 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index cc36e39..afdfd04 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -692,6 +692,49 @@ out:
     return rc;
 }
 
+static int translate_vnode_to_pnode(struct domain *d,
+                                    struct xen_memory_reservation *r,
+                                    struct memop_args *a)
+{
+    int rc = 0;
+    unsigned int vnode, pnode;
+
+    /* Note: we don't strictly require non-supported bits set to zero,
+     * so we may have exact_vnode bit set for old guests that don't
+     * support vNUMA.
+     *
+     * To distinguish spurious vnode request v.s. real one, check if
+     * d->vnuma exists.
+     */
+    if ( r->mem_flags & XENMEMF_vnode )
+    {
+        read_lock(&d->vnuma_rwlock);
+        if ( d->vnuma )
+        {
+            vnode = XENMEMF_get_node(r->mem_flags);
+
+            if ( vnode < d->vnuma->nr_vnodes )
+            {
+                pnode = d->vnuma->vnode_to_pnode[vnode];
+
+                a->memflags &=
+                    ~MEMF_node(XENMEMF_get_node(r->mem_flags));
+
+                if ( pnode != NUMA_NO_NODE )
+                {
+                    a->memflags |= MEMF_exact_node;
+                    a->memflags |= MEMF_node(pnode);
+                }
+            }
+            else
+                rc = -EINVAL;
+        }
+        read_unlock(&d->vnuma_rwlock);
+    }
+
+    return rc;
+}
+
 long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d;
@@ -734,10 +777,6 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             args.memflags = MEMF_bits(address_bits);
         }
 
-        args.memflags |= MEMF_node(XENMEMF_get_node(reservation.mem_flags));
-        if ( reservation.mem_flags & XENMEMF_exact_node_request )
-            args.memflags |= MEMF_exact_node;
-
         if ( op == XENMEM_populate_physmap
              && (reservation.mem_flags & XENMEMF_populate_on_demand) )
             args.memflags |= MEMF_populate_on_demand;
@@ -747,6 +786,17 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             return start_extent;
         args.domain = d;
 
+        args.memflags |= MEMF_node(XENMEMF_get_node(reservation.mem_flags));
+        if ( reservation.mem_flags & XENMEMF_exact_node_request )
+            args.memflags |= MEMF_exact_node;
+
+        rc = translate_vnode_to_pnode(d, &reservation, &args);
+        if ( rc )
+        {
+            rcu_unlock_domain(d);
+            return rc;
+        }
+
         rc = xsm_memory_adjust_reservation(XSM_TARGET, current->domain, d);
         if ( rc )
         {
diff --git a/xen/include/public/features.h b/xen/include/public/features.h
index 16d92aa..9f33502 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -99,6 +99,9 @@
 #define XENFEAT_grant_map_identity        12
  */
 
+/* Guset can use XENMEMF_vnode to specify virtual node for memory op. */
+#define XENFEAT_memory_op_vnode_supported 13
+
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index f021958..f2e5d14 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -55,6 +55,8 @@
 /* Flag to request allocation only from the node specified */
 #define XENMEMF_exact_node_request  (1<<17)
 #define XENMEMF_exact_node(n) (XENMEMF_node(n) | XENMEMF_exact_node_request)
+/* Flag to indicate the node specified is virtual node */
+#define XENMEMF_vnode  (1<<18)
 #endif
 
 struct xen_memory_reservation {
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpns-0005Ls-KV; Fri, 21 Nov 2014 15:07:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnq-0005Io-A4
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:18 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	B5/71-19763-5255F645; Fri, 21 Nov 2014 15:07:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416582433!12681604!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21074 invoked from network); 21 Nov 2014 15:07:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735631"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-NR;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:51 +0000
Message-ID: <1416582421-10789-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 09/19] libxl: functions to build vmemranges 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

One vmemrange is generated for each vnode. And for those guests who care
about machine E820 map, vmemranges are further split to accommodate
memory holes.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_arch.h     |    6 ++++
 tools/libxl/libxl_arm.c      |    9 +++++
 tools/libxl/libxl_internal.h |    5 +++
 tools/libxl/libxl_vnuma.c    |   34 +++++++++++++++++++
 tools/libxl/libxl_x86.c      |   74 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 128 insertions(+)

diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index d3bc136..e249048 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -27,4 +27,10 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
 int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
                                       libxl_domain_build_info *info,
                                       struct xc_dom_image *dom);
+
+/* build vNUMA vmemrange with arch specific information */
+int libxl__arch_vnuma_build_vmemrange(libxl__gc *gc,
+                                      uint32_t domid,
+                                      libxl_domain_build_info *b_info,
+                                      libxl__domain_build_state *state);
 #endif
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 34d21f5..1f1bc24 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -707,6 +707,15 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
     return 0;
 }
 
+int libxl__arch_vnuma_build_vmemrange(libxl__gc *gc,
+                                      uint32_t domid,
+                                      libxl_domain_build_info *info,
+                                      libxl__domain_build_state *state)
+{
+    /* Don't touch anything. */
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ee76df6..b1b60cb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3397,6 +3397,11 @@ int libxl__vnuma_config_check(libxl__gc *gc,
                               const libxl_domain_build_info *b_info,
                               const libxl__domain_build_state *state);
 
+int libxl__vnuma_build_vmemrange_pv(libxl__gc *gc,
+                                    uint32_t domid,
+                                    libxl_domain_build_info *b_info,
+                                    libxl__domain_build_state *state);
+
 _hidden int libxl__ms_vm_genid_set(libxl__gc *gc, uint32_t domid,
                                    const libxl_ms_vm_genid *id);
 
diff --git a/tools/libxl/libxl_vnuma.c b/tools/libxl/libxl_vnuma.c
index f5912e6..1d50606 100644
--- a/tools/libxl/libxl_vnuma.c
+++ b/tools/libxl/libxl_vnuma.c
@@ -14,6 +14,7 @@
  */
 #include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
+#include "libxl_arch.h"
 #include <stdlib.h>
 
 /* Sort vmemranges in ascending order with "start" */
@@ -129,6 +130,39 @@ out:
     return rc;
 }
 
+/* Build vmemranges for PV guest */
+int libxl__vnuma_build_vmemrange_pv(libxl__gc *gc,
+                                    uint32_t domid,
+                                    libxl_domain_build_info *b_info,
+                                    libxl__domain_build_state *state)
+{
+    int i;
+    uint64_t next;
+    vmemrange_t *v = NULL;
+
+    assert(state->vmemranges == NULL);
+
+    /* Generate one vmemrange for each virtual node. */
+    next = 0;
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        libxl_vnode_info *p = &b_info->vnuma_nodes[i];
+
+        v = libxl__realloc(gc, v, sizeof(*v) * (i+1));
+
+        v[i].start = next;
+        v[i].end = next + (p->mem << 20); /* mem is in MiB */
+        v[i].flags = 0;
+        v[i].nid = i;
+
+        next = v[i].end;
+    }
+
+    state->vmemranges = v;
+    state->num_vmemranges = i;
+
+    return libxl__arch_vnuma_build_vmemrange(gc, domid, b_info, state);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index e959e37..8e7af6a 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -338,6 +338,80 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
     return 0;
 }
 
+int libxl__arch_vnuma_build_vmemrange(libxl__gc *gc,
+                                      uint32_t domid,
+                                      libxl_domain_build_info *b_info,
+                                      libxl__domain_build_state *state)
+{
+    int i, x, n, rc;
+    uint32_t nr_e820;
+    struct e820entry map[E820MAX];
+    vmemrange_t *v;
+
+    /* Only touch vmemranges if it's PV guest and e820_host is true */
+    if (!(b_info->type == LIBXL_DOMAIN_TYPE_PV &&
+          libxl_defbool_val(b_info->u.pv.e820_host))) {
+        rc = 0;
+        goto out;
+    }
+
+    rc = e820_host_sanitize(gc, b_info, map, &nr_e820);
+    if (rc) goto out;
+
+    /* Ditch old vmemranges and start with host E820 map. Note, memory
+     * was gc allocated.
+     */
+    state->vmemranges = NULL;
+    state->num_vmemranges = 0;
+
+    n = 0; /* E820 counter */
+    x = 0;
+    v = NULL;
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        libxl_vnode_info *p = &b_info->vnuma_nodes[i];
+        uint64_t remaining = (p->mem << 20);
+
+        while (remaining > 0) {
+            if (n >= nr_e820) {
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /* Skip non RAM region */
+            if (map[n].type != E820_RAM) {
+                n++;
+                continue;
+            }
+
+            v = libxl__realloc(gc, v, sizeof(vmemrange_t) * (x+1));
+
+            if (map[n].size >= remaining) {
+                v[x].start = map[n].addr;
+                v[x].end = map[n].addr + remaining;
+                map[n].addr += remaining;
+                map[n].size -= remaining;
+                remaining = 0;
+            } else {
+                v[x].start = map[n].addr;
+                v[x].end = map[n].addr + map[n].size;
+                remaining -= map[n].size;
+                n++;
+            }
+
+            v[x].flags = 0;
+            v[x].nid = i;
+            x++;
+        }
+    }
+
+    state->vmemranges = v;
+    state->num_vmemranges = x;
+
+    rc = 0;
+out:
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpns-0005LG-4Q; Fri, 21 Nov 2014 15:07:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnp-0005IY-Uf
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:18 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	80/3F-28296-5255F645; Fri, 21 Nov 2014 15:07:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416582435!12946201!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26106 invoked from network); 21 Nov 2014 15:07:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735628"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-M1;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:49 +0000
Message-ID: <1416582421-10789-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 07/19] libxl: introduce libxl__vnuma_config_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 vNUMA function (and future ones) is placed in a new file called
libxl_vnuma.c

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl_internal.h |    5 ++
 tools/libxl/libxl_vnuma.c    |  138 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 144 insertions(+), 1 deletion(-)
 create mode 100644 tools/libxl/libxl_vnuma.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index df08c8a..9fcdfb1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -93,7 +93,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_aoutils.o libxl_numa.o \
+			libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o \
 			libxl_save_callout.o _libxl_save_msgs_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7ee7482..ee76df6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3392,6 +3392,11 @@ void libxl__numa_candidate_put_nodemap(libxl__gc *gc,
     libxl_bitmap_copy(CTX, &cndt->nodemap, nodemap);
 }
 
+/* Check if vNUMA config is valid. Returns 0 if valid. */
+int libxl__vnuma_config_check(libxl__gc *gc,
+                              const libxl_domain_build_info *b_info,
+                              const libxl__domain_build_state *state);
+
 _hidden int libxl__ms_vm_genid_set(libxl__gc *gc, uint32_t domid,
                                    const libxl_ms_vm_genid *id);
 
diff --git a/tools/libxl/libxl_vnuma.c b/tools/libxl/libxl_vnuma.c
new file mode 100644
index 0000000..f5912e6
--- /dev/null
+++ b/tools/libxl/libxl_vnuma.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2014      Citrix Ltd.
+ * Author Wei Liu <wei.liu2@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxl_internal.h"
+#include <stdlib.h>
+
+/* Sort vmemranges in ascending order with "start" */
+static int compare_vmemrange(const void *a, const void *b)
+{
+    const vmemrange_t *x = a, *y = b;
+    if (x->start < y->start)
+        return -1;
+    if (x->start > y->start)
+        return 1;
+    return 0;
+}
+
+/* Check if vNUMA configuration is valid:
+ *  1. all pnodes inside vnode_to_pnode array are valid
+ *  2. one vcpu belongs to and only belongs to one vnode
+ *  3. each vmemrange is valid and doesn't overlap with each other
+ */
+int libxl__vnuma_config_check(libxl__gc *gc,
+			      const libxl_domain_build_info *b_info,
+                              const libxl__domain_build_state *state)
+{
+    int i, j, rc = ERROR_INVAL, nr_nodes;
+    libxl_numainfo *ninfo = NULL;
+    uint64_t total_ram = 0;
+    libxl_bitmap cpumap;
+    libxl_vnode_info *p;
+
+    libxl_bitmap_init(&cpumap);
+
+    /* Check pnode specified is valid */
+    ninfo = libxl_get_numainfo(CTX, &nr_nodes);
+    if (!ninfo) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "libxl_get_numainfo failed");
+        goto out;
+    }
+
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        uint32_t pnode;
+
+        p = &b_info->vnuma_nodes[i];
+        pnode = p->pnode;
+
+        /* The pnode specified is not valid? */
+        if (pnode >= nr_nodes) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "Invalid pnode %d specified",
+                       pnode);
+            goto out;
+        }
+
+        total_ram += p->mem;
+    }
+
+    if (total_ram != (b_info->max_memkb >> 10)) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "Total ram in vNUMA configuration 0x%"PRIx64" while maxmem specified 0x%"PRIx64,
+                   total_ram, (b_info->max_memkb >> 10));
+        goto out;
+    }
+
+    /* Check vcpu mapping */
+    libxl_cpu_bitmap_alloc(CTX, &cpumap, b_info->max_vcpus);
+    libxl_bitmap_set_none(&cpumap);
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        p = &b_info->vnuma_nodes[i];
+        libxl_for_each_set_bit(j, p->vcpus) {
+            if (!libxl_bitmap_test(&cpumap, j))
+                libxl_bitmap_set(&cpumap, j);
+            else {
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                           "Try to assign vcpu %d to vnode %d while it's already assigned to other vnode",
+                           j, i);
+                goto out;
+            }
+        }
+    }
+
+    for (i = 0; i < b_info->max_vcpus; i++) {
+        if (!libxl_bitmap_test(&cpumap, i)) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "Vcpu %d is not assigned to any vnode", i);
+            goto out;
+        }
+    }
+
+    /* Check vmemranges */
+    qsort(state->vmemranges, state->num_vmemranges, sizeof(vmemrange_t),
+          compare_vmemrange);
+
+    for (i = 0; i < state->num_vmemranges; i++) {
+        if (state->vmemranges[i].end < state->vmemranges[i].start) {
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                           "Vmemrange end < start");
+                goto out;
+        }
+    }
+
+    for (i = 0; i < state->num_vmemranges - 1; i++) {
+        if (state->vmemranges[i].end > state->vmemranges[i+1].start) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "Vmemranges overlapped, 0x%"PRIx64"-0x%"PRIx64", 0x%"PRIx64"-0x%"PRIx64,
+                       state->vmemranges[i].start, state->vmemranges[i].end,
+                       state->vmemranges[i+1].start, state->vmemranges[i+1].end);
+            goto out;
+        }
+    }
+
+    rc = 0;
+out:
+    if (ninfo) libxl_numainfo_dispose(ninfo);
+    libxl_bitmap_dispose(&cpumap);
+    return rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnp-0005Ir-TG; Fri, 21 Nov 2014 15:07:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpno-0005I3-Ad
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:16 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	03/2C-25727-3255F645; Fri, 21 Nov 2014 15:07:15 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6931 invoked from network); 21 Nov 2014 15:07:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735622"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-JH;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:45 +0000
Message-ID: <1416582421-10789-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 03/19] libxc: allocate memory with vNUMA
	information 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxc/include/xc_dom.h |    5 +++
 tools/libxc/xc_dom_x86.c     |   72 +++++++++++++++++++++++++++++++++++-------
 tools/libxc/xc_private.h     |    2 ++
 3 files changed, 68 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6ae6a9f..eb8e2ce 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -162,6 +162,11 @@ struct xc_dom_image {
     struct xc_dom_loader *kernel_loader;
     void *private_loader;
 
+    /* vNUMA information */
+    unsigned int *vnode_to_pnode;
+    uint64_t *vnode_size;
+    unsigned int nr_vnodes;
+
     /* kernel loader */
     struct xc_dom_arch *arch_hooks;
     /* allocate up to virt_alloc_end */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index bf06fe4..3286232 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -759,7 +759,8 @@ static int x86_shadow(xc_interface *xch, domid_t domid)
 int arch_setup_meminit(struct xc_dom_image *dom)
 {
     int rc;
-    xen_pfn_t pfn, allocsz, i, j, mfn;
+    xen_pfn_t pfn, allocsz, mfn, total, pfn_base;
+    int i, j;
 
     rc = x86_compat(dom->xch, dom->guest_domid, dom->guest_type);
     if ( rc )
@@ -811,18 +812,67 @@ int arch_setup_meminit(struct xc_dom_image *dom)
         /* setup initial p2m */
         for ( pfn = 0; pfn < dom->total_pages; pfn++ )
             dom->p2m_host[pfn] = pfn;
-        
+
+        /* setup dummy vNUMA information if it's not provided */
+        if ( dom->nr_vnodes == 0 )
+        {
+            dom->nr_vnodes = 1;
+            dom->vnode_to_pnode = xc_dom_malloc(dom,
+                                                sizeof(*dom->vnode_to_pnode));
+            dom->vnode_to_pnode[0] = XC_VNUMA_NO_NODE;
+            dom->vnode_size = xc_dom_malloc(dom, sizeof(*dom->vnode_size));
+            dom->vnode_size[0] = ((dom->total_pages << PAGE_SHIFT) >> 20);
+        }
+
+        total = 0;
+        for ( i = 0; i < dom->nr_vnodes; i++ )
+            total += ((dom->vnode_size[i] << 20) >> PAGE_SHIFT);
+        if ( total != dom->total_pages )
+        {
+            xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+                         "%s: number of pages requested by vNUMA (0x%"PRIpfn") mismatches number of pages configured for domain (0x%"PRIpfn")\n",
+                         __FUNCTION__, total, dom->total_pages);
+            return -EINVAL;
+        }
+
         /* allocate guest memory */
-        for ( i = rc = allocsz = 0;
-              (i < dom->total_pages) && !rc;
-              i += allocsz )
+        pfn_base = 0;
+        for ( i = 0; i < dom->nr_vnodes; i++ )
         {
-            allocsz = dom->total_pages - i;
-            if ( allocsz > 1024*1024 )
-                allocsz = 1024*1024;
-            rc = xc_domain_populate_physmap_exact(
-                dom->xch, dom->guest_domid, allocsz,
-                0, 0, &dom->p2m_host[i]);
+            unsigned int memflags;
+            uint64_t pages;
+
+            memflags = 0;
+            if ( dom->vnode_to_pnode[i] != XC_VNUMA_NO_NODE )
+            {
+                memflags |= XENMEMF_exact_node(dom->vnode_to_pnode[i]);
+                memflags |= XENMEMF_exact_node_request;
+            }
+
+            pages = (dom->vnode_size[i] << 20) >> PAGE_SHIFT;
+
+            for ( j = 0; j < pages; j += allocsz )
+            {
+                allocsz = pages - j;
+                if ( allocsz > 1024*1024 )
+                    allocsz = 1024*1024;
+
+                rc = xc_domain_populate_physmap_exact(dom->xch,
+                         dom->guest_domid, allocsz, 0, memflags,
+                         &dom->p2m_host[pfn_base+j]);
+
+                if ( rc )
+                {
+                    if ( dom->vnode_to_pnode[i] != XC_VNUMA_NO_NODE )
+                        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+                                     "%s: fail to allocate 0x%"PRIx64" pages for vnode %d on pnode %d out of 0x%"PRIpfn"\n",
+                                     __FUNCTION__, pages, i,
+                                     dom->vnode_to_pnode[i], dom->total_pages);
+                    return rc;
+                }
+            }
+
+            pfn_base += pages;
         }
 
         /* Ensure no unclaimed pages are left unused.
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 45b8644..1809674 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -35,6 +35,8 @@
 
 #include <xen/sys/privcmd.h>
 
+#define XC_VNUMA_NO_NODE (~0U)
+
 #if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG) && !defined(__MINIOS__)
 /* Compile in Valgrind client requests? */
 #include <valgrind/memcheck.h>
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpns-0005Ls-KV; Fri, 21 Nov 2014 15:07:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnq-0005Io-A4
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:18 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	B5/71-19763-5255F645; Fri, 21 Nov 2014 15:07:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416582433!12681604!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21074 invoked from network); 21 Nov 2014 15:07:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735631"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-NR;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:51 +0000
Message-ID: <1416582421-10789-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 09/19] libxl: functions to build vmemranges 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

One vmemrange is generated for each vnode. And for those guests who care
about machine E820 map, vmemranges are further split to accommodate
memory holes.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_arch.h     |    6 ++++
 tools/libxl/libxl_arm.c      |    9 +++++
 tools/libxl/libxl_internal.h |    5 +++
 tools/libxl/libxl_vnuma.c    |   34 +++++++++++++++++++
 tools/libxl/libxl_x86.c      |   74 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 128 insertions(+)

diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index d3bc136..e249048 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -27,4 +27,10 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
 int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
                                       libxl_domain_build_info *info,
                                       struct xc_dom_image *dom);
+
+/* build vNUMA vmemrange with arch specific information */
+int libxl__arch_vnuma_build_vmemrange(libxl__gc *gc,
+                                      uint32_t domid,
+                                      libxl_domain_build_info *b_info,
+                                      libxl__domain_build_state *state);
 #endif
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 34d21f5..1f1bc24 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -707,6 +707,15 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
     return 0;
 }
 
+int libxl__arch_vnuma_build_vmemrange(libxl__gc *gc,
+                                      uint32_t domid,
+                                      libxl_domain_build_info *info,
+                                      libxl__domain_build_state *state)
+{
+    /* Don't touch anything. */
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ee76df6..b1b60cb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3397,6 +3397,11 @@ int libxl__vnuma_config_check(libxl__gc *gc,
                               const libxl_domain_build_info *b_info,
                               const libxl__domain_build_state *state);
 
+int libxl__vnuma_build_vmemrange_pv(libxl__gc *gc,
+                                    uint32_t domid,
+                                    libxl_domain_build_info *b_info,
+                                    libxl__domain_build_state *state);
+
 _hidden int libxl__ms_vm_genid_set(libxl__gc *gc, uint32_t domid,
                                    const libxl_ms_vm_genid *id);
 
diff --git a/tools/libxl/libxl_vnuma.c b/tools/libxl/libxl_vnuma.c
index f5912e6..1d50606 100644
--- a/tools/libxl/libxl_vnuma.c
+++ b/tools/libxl/libxl_vnuma.c
@@ -14,6 +14,7 @@
  */
 #include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
+#include "libxl_arch.h"
 #include <stdlib.h>
 
 /* Sort vmemranges in ascending order with "start" */
@@ -129,6 +130,39 @@ out:
     return rc;
 }
 
+/* Build vmemranges for PV guest */
+int libxl__vnuma_build_vmemrange_pv(libxl__gc *gc,
+                                    uint32_t domid,
+                                    libxl_domain_build_info *b_info,
+                                    libxl__domain_build_state *state)
+{
+    int i;
+    uint64_t next;
+    vmemrange_t *v = NULL;
+
+    assert(state->vmemranges == NULL);
+
+    /* Generate one vmemrange for each virtual node. */
+    next = 0;
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        libxl_vnode_info *p = &b_info->vnuma_nodes[i];
+
+        v = libxl__realloc(gc, v, sizeof(*v) * (i+1));
+
+        v[i].start = next;
+        v[i].end = next + (p->mem << 20); /* mem is in MiB */
+        v[i].flags = 0;
+        v[i].nid = i;
+
+        next = v[i].end;
+    }
+
+    state->vmemranges = v;
+    state->num_vmemranges = i;
+
+    return libxl__arch_vnuma_build_vmemrange(gc, domid, b_info, state);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index e959e37..8e7af6a 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -338,6 +338,80 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
     return 0;
 }
 
+int libxl__arch_vnuma_build_vmemrange(libxl__gc *gc,
+                                      uint32_t domid,
+                                      libxl_domain_build_info *b_info,
+                                      libxl__domain_build_state *state)
+{
+    int i, x, n, rc;
+    uint32_t nr_e820;
+    struct e820entry map[E820MAX];
+    vmemrange_t *v;
+
+    /* Only touch vmemranges if it's PV guest and e820_host is true */
+    if (!(b_info->type == LIBXL_DOMAIN_TYPE_PV &&
+          libxl_defbool_val(b_info->u.pv.e820_host))) {
+        rc = 0;
+        goto out;
+    }
+
+    rc = e820_host_sanitize(gc, b_info, map, &nr_e820);
+    if (rc) goto out;
+
+    /* Ditch old vmemranges and start with host E820 map. Note, memory
+     * was gc allocated.
+     */
+    state->vmemranges = NULL;
+    state->num_vmemranges = 0;
+
+    n = 0; /* E820 counter */
+    x = 0;
+    v = NULL;
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        libxl_vnode_info *p = &b_info->vnuma_nodes[i];
+        uint64_t remaining = (p->mem << 20);
+
+        while (remaining > 0) {
+            if (n >= nr_e820) {
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
+            /* Skip non RAM region */
+            if (map[n].type != E820_RAM) {
+                n++;
+                continue;
+            }
+
+            v = libxl__realloc(gc, v, sizeof(vmemrange_t) * (x+1));
+
+            if (map[n].size >= remaining) {
+                v[x].start = map[n].addr;
+                v[x].end = map[n].addr + remaining;
+                map[n].addr += remaining;
+                map[n].size -= remaining;
+                remaining = 0;
+            } else {
+                v[x].start = map[n].addr;
+                v[x].end = map[n].addr + map[n].size;
+                remaining -= map[n].size;
+                n++;
+            }
+
+            v[x].flags = 0;
+            v[x].nid = i;
+            x++;
+        }
+    }
+
+    state->vmemranges = v;
+    state->num_vmemranges = x;
+
+    rc = 0;
+out:
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnr-0005Km-NL; Fri, 21 Nov 2014 15:07:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnp-0005IN-DE
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:17 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	18/6C-09284-4255F645; Fri, 21 Nov 2014 15:07:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7068 invoked from network); 21 Nov 2014 15:07:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735624"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Ki;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:47 +0000
Message-ID: <1416582421-10789-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 05/19] libxl: introduce vNUMA 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_types.idl |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..75855fb 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -353,6 +353,13 @@ libxl_domain_sched_params = Struct("domain_sched_params",[
     ("budget",       integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),
     ])
 
+libxl_vnode_info = Struct("vnode_info", [
+    ("mem", uint64), # memory size of this node, in MiB
+    ("distances", Array(uint32, "num_distances")), # distances from this node to other nodes
+    ("pnode", uint32), # physical node of this node
+    ("vcpus", libxl_bitmap), # vcpus in this node
+    ])
+
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("avail_vcpus",     libxl_bitmap),
@@ -373,6 +380,8 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("blkdev_start",    string),
+
+    ("vnuma_nodes", Array(libxl_vnode_info, "num_vnuma_nodes")),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", libxl_defbool),
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnq-0005JO-F7; Fri, 21 Nov 2014 15:07:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpno-0005I9-Nr
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:16 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	6C/67-07724-4255F645; Fri, 21 Nov 2014 15:07:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6975 invoked from network); 21 Nov 2014 15:07:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735625"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-LM;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:48 +0000
Message-ID: <1416582421-10789-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 06/19] libxl: add vmemrange to
	libxl__domain_build_state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we haven't exported vmemrange interface to libxl user.
Vmemranges are generated during domain build.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_internal.h |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..7ee7482 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -971,6 +971,9 @@ typedef struct {
     libxl__file_reference pv_ramdisk;
     const char * pv_cmdline;
     bool pvh_enabled;
+
+    vmemrange_t *vmemranges;
+    uint32_t num_vmemranges;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnr-0005K9-9h; Fri, 21 Nov 2014 15:07:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnp-0005II-8j
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:17 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	4F/83-11581-4255F645; Fri, 21 Nov 2014 15:07:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416582433!12681604!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20949 invoked from network); 21 Nov 2014 15:07:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735623"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-K0;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:46 +0000
Message-ID: <1416582421-10789-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 04/19] libxl: add emacs local variables in
	libxl_{x86, arm}.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_arm.c |    8 ++++++++
 tools/libxl/libxl_x86.c |    8 ++++++++
 2 files changed, 16 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 448ac07..34d21f5 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -706,3 +706,11 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
 
     return 0;
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 7589060..9ceb373 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -324,3 +324,11 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
 {
     return 0;
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnq-0005JO-F7; Fri, 21 Nov 2014 15:07:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpno-0005I9-Nr
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:16 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	6C/67-07724-4255F645; Fri, 21 Nov 2014 15:07:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6975 invoked from network); 21 Nov 2014 15:07:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735625"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-LM;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:48 +0000
Message-ID: <1416582421-10789-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 06/19] libxl: add vmemrange to
	libxl__domain_build_state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we haven't exported vmemrange interface to libxl user.
Vmemranges are generated during domain build.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_internal.h |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..7ee7482 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -971,6 +971,9 @@ typedef struct {
     libxl__file_reference pv_ramdisk;
     const char * pv_cmdline;
     bool pvh_enabled;
+
+    vmemrange_t *vmemranges;
+    uint32_t num_vmemranges;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnq-0005Jh-Qu; Fri, 21 Nov 2014 15:07:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpno-0005IB-S8
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:17 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	9B/E4-02697-4255F645; Fri, 21 Nov 2014 15:07:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416582433!12681604!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20821 invoked from network); 21 Nov 2014 15:07:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735621"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Ft;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:42 +0000
Message-ID: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/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 virtual NUMA support for both PV and HVM guest.
That is, admin can configure via libxl what virtual NUMA topology the guest
sees.

This is the stage 1 (basic vNUMA support) and part of stage 2 (vNUMA-ware
ballooning, hypervisor side) described in my previous email to xen-devel [0].

This series is broken into several parts:

1. xen patches: vNUMA debug output and vNUMA-aware memory hypercall support.
2. libxc/libxl support for PV vNUMA.
3. libxc/libxl support for HVM vNUMA.
4. xl vNUMA configuration documentation and parser.

I think one significant difference from Elena's work is that this patch series
makes use of multiple vmemranges should there be a memory hole, instead of
shrinking ram. This matches the behaviour of real hardware.

The vNUMA auto placement algorithm is missing at the moment and Dario is
working on it.

This series can be found at:
 git://xenbits.xen.org/people/liuw/xen.git wip.vnuma-v1 

With this series, the following configuration can be used to enabled virtual
NUMA support, and it works for both PV and HVM guests.

memory = 6000
vnuma_memory = [3000, 3000]
vnuma_vcpu_map = [0, 1]
vnuma_pnode_map = [0, 0]
vnuma_vdistances = [10, 30] # optional

dmesg output for HVM guest:

[    0.000000] ACPI: SRAT 00000000fc009ff0 000C8 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: SLIT 00000000fc00a0c0 00030 (v01    Xen      HVM 00000000 HVML 00000000)
<...snip...>
[    0.000000] SRAT: PXM 0 -> APIC 0x00 -> Node 0
[    0.000000] SRAT: PXM 1 -> APIC 0x02 -> Node 1
[    0.000000] SRAT: Node 0 PXM 0 [mem 0x00000000-0xbb7fffff]
[    0.000000] SRAT: Node 1 PXM 1 [mem 0xbb800000-0xefffffff]
[    0.000000] SRAT: Node 1 PXM 1 [mem 0x100000000-0x186ffffff]
[    0.000000] NUMA: Initialized distance table, cnt=2
[    0.000000] NUMA: Node 1 [mem 0xbb800000-0xefffffff] + [mem 0x100000000-0x1867fffff] -> [mem 0xbb800000-0x1867fffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0xbb7fffff]
[    0.000000]   NODE_DATA [mem 0xbb7fc000-0xbb7fffff]
[    0.000000] Initmem setup node 1 [mem 0xbb800000-0x1867fffff]
[    0.000000]   NODE_DATA [mem 0x1867f7000-0x1867fafff]
[    0.000000]  [ffffea0000000000-ffffea00029fffff] PMD -> [ffff8800b8600000-ffff8800baffffff] on node 0
[    0.000000]  [ffffea0002a00000-ffffea00055fffff] PMD -> [ffff880183000000-ffff8801859fffff] on node 1
<...snip...>
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0xbb7fffff]
[    0.000000]   node   1: [mem 0xbb800000-0xefffefff]
[    0.000000]   node   1: [mem 0x100000000-0x1867fffff]

numactl output for HVM guest:

available: 2 nodes (0-1)
node 0 cpus: 0
node 0 size: 2999 MB
node 0 free: 2546 MB
node 1 cpus: 1
node 1 size: 2991 MB
node 1 free: 2144 MB
node distances:
node   0   1 
  0:  10  30 
  1:  30  10 

dmesg output for PV guest:

[    0.000000] NUMA: Initialized distance table, cnt=2
[    0.000000] NUMA: Node 1 [mem 0xbb800000-0xce68efff] + [mem 0x100000000-0x1a8970fff] -> [mem 0xbb800000-0x1a8970fff]
[    0.000000] NODE_DATA(0) allocated [mem 0xbb7fc000-0xbb7fffff]
[    0.000000] NODE_DATA(1) allocated [mem 0x1a8969000-0x1a896cfff]

numactl output for PV guest:

available: 2 nodes (0-1)
node 0 cpus: 0
node 0 size: 2944 MB
node 0 free: 2917 MB
node 1 cpus: 1
node 1 size: 2934 MB
node 1 free: 2904 MB
node distances:
node   0   1 
  0:  10  30
  1:  30  10

And for a HVM guest on a real NUMA-capable machine:

(XEN) Memory location of each domain:
(XEN) Domain 0 (total: 262144):
(XEN)     Node 0: 245758
(XEN)     Node 1: 16386
(XEN) Domain 2 (total: 2097226):
(XEN)     Node 0: 1046335
(XEN)     Node 1: 1050891
(XEN)      2 vnodes, 4 vcpus
(XEN)        vnode   0 - pnode 0
(XEN)         3840 MB:  0x0 - 0xf0000000
(XEN)         256 MB:  0x100000000 - 0x110000000
(XEN)         vcpus: 0 1 
(XEN)        vnode   1 - pnode 1
(XEN)         4096 MB:  0x110000000 - 0x210000000
(XEN)         vcpus: 2 3 

Wei.

[0] <20141111173606.GC21312@zion.uk.xensource.com>

Wei Liu (19):
  xen: dump vNUMA information with debug key "u"
  xen: make two memory hypercalls vNUMA-aware
  libxc: allocate memory with vNUMA information for PV guest
  libxl: add emacs local variables in libxl_{x86,arm}.c
  libxl: introduce vNUMA types
  libxl: add vmemrange to libxl__domain_build_state
  libxl: introduce libxl__vnuma_config_check
  libxl: x86: factor out e820_host_sanitize
  libxl: functions to build vmemranges for PV guest
  libxl: build, check and pass vNUMA info to Xen for PV guest
  hvmloader: add new fields for vNUMA information
  hvmloader: construct SRAT
  hvmloader: construct SLIT
  hvmloader: disallow memory relocation when vNUMA is enabled
  libxc: allocate memory with vNUMA information for HVM guest
  libxl: build, check and pass vNUMA info to Xen for HVM guest
  libxl: refactor hvm_build_set_params
  libxl: fill vNUMA information in hvm info
  xl: vNUMA support

 docs/man/xl.cfg.pod.5                   |   32 +++++
 tools/firmware/hvmloader/acpi/acpi2_0.h |   61 +++++++++
 tools/firmware/hvmloader/acpi/build.c   |  104 ++++++++++++++
 tools/firmware/hvmloader/pci.c          |   13 ++
 tools/libxc/include/xc_dom.h            |    5 +
 tools/libxc/include/xenguest.h          |    7 +
 tools/libxc/xc_dom_x86.c                |   72 ++++++++--
 tools/libxc/xc_hvm_build_x86.c          |  224 +++++++++++++++++++-----------
 tools/libxc/xc_private.h                |    2 +
 tools/libxl/Makefile                    |    2 +-
 tools/libxl/libxl_arch.h                |    6 +
 tools/libxl/libxl_arm.c                 |   17 +++
 tools/libxl/libxl_create.c              |    9 ++
 tools/libxl/libxl_dom.c                 |  172 ++++++++++++++++++++---
 tools/libxl/libxl_internal.h            |   18 +++
 tools/libxl/libxl_types.idl             |    9 ++
 tools/libxl/libxl_vnuma.c               |  228 +++++++++++++++++++++++++++++++
 tools/libxl/libxl_x86.c                 |  113 +++++++++++++--
 tools/libxl/xl_cmdimpl.c                |  151 ++++++++++++++++++++
 xen/arch/x86/numa.c                     |   46 ++++++-
 xen/common/memory.c                     |   58 +++++++-
 xen/include/public/features.h           |    3 +
 xen/include/public/hvm/hvm_info_table.h |   19 +++
 xen/include/public/memory.h             |    2 +
 24 files changed, 1247 insertions(+), 126 deletions(-)
 create mode 100644 tools/libxl/libxl_vnuma.c

-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnq-0005Jh-Qu; Fri, 21 Nov 2014 15:07:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpno-0005IB-S8
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:17 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	9B/E4-02697-4255F645; Fri, 21 Nov 2014 15:07:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416582433!12681604!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20821 invoked from network); 21 Nov 2014 15:07:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735621"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Ft;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:42 +0000
Message-ID: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/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 virtual NUMA support for both PV and HVM guest.
That is, admin can configure via libxl what virtual NUMA topology the guest
sees.

This is the stage 1 (basic vNUMA support) and part of stage 2 (vNUMA-ware
ballooning, hypervisor side) described in my previous email to xen-devel [0].

This series is broken into several parts:

1. xen patches: vNUMA debug output and vNUMA-aware memory hypercall support.
2. libxc/libxl support for PV vNUMA.
3. libxc/libxl support for HVM vNUMA.
4. xl vNUMA configuration documentation and parser.

I think one significant difference from Elena's work is that this patch series
makes use of multiple vmemranges should there be a memory hole, instead of
shrinking ram. This matches the behaviour of real hardware.

The vNUMA auto placement algorithm is missing at the moment and Dario is
working on it.

This series can be found at:
 git://xenbits.xen.org/people/liuw/xen.git wip.vnuma-v1 

With this series, the following configuration can be used to enabled virtual
NUMA support, and it works for both PV and HVM guests.

memory = 6000
vnuma_memory = [3000, 3000]
vnuma_vcpu_map = [0, 1]
vnuma_pnode_map = [0, 0]
vnuma_vdistances = [10, 30] # optional

dmesg output for HVM guest:

[    0.000000] ACPI: SRAT 00000000fc009ff0 000C8 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: SLIT 00000000fc00a0c0 00030 (v01    Xen      HVM 00000000 HVML 00000000)
<...snip...>
[    0.000000] SRAT: PXM 0 -> APIC 0x00 -> Node 0
[    0.000000] SRAT: PXM 1 -> APIC 0x02 -> Node 1
[    0.000000] SRAT: Node 0 PXM 0 [mem 0x00000000-0xbb7fffff]
[    0.000000] SRAT: Node 1 PXM 1 [mem 0xbb800000-0xefffffff]
[    0.000000] SRAT: Node 1 PXM 1 [mem 0x100000000-0x186ffffff]
[    0.000000] NUMA: Initialized distance table, cnt=2
[    0.000000] NUMA: Node 1 [mem 0xbb800000-0xefffffff] + [mem 0x100000000-0x1867fffff] -> [mem 0xbb800000-0x1867fffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0xbb7fffff]
[    0.000000]   NODE_DATA [mem 0xbb7fc000-0xbb7fffff]
[    0.000000] Initmem setup node 1 [mem 0xbb800000-0x1867fffff]
[    0.000000]   NODE_DATA [mem 0x1867f7000-0x1867fafff]
[    0.000000]  [ffffea0000000000-ffffea00029fffff] PMD -> [ffff8800b8600000-ffff8800baffffff] on node 0
[    0.000000]  [ffffea0002a00000-ffffea00055fffff] PMD -> [ffff880183000000-ffff8801859fffff] on node 1
<...snip...>
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0xbb7fffff]
[    0.000000]   node   1: [mem 0xbb800000-0xefffefff]
[    0.000000]   node   1: [mem 0x100000000-0x1867fffff]

numactl output for HVM guest:

available: 2 nodes (0-1)
node 0 cpus: 0
node 0 size: 2999 MB
node 0 free: 2546 MB
node 1 cpus: 1
node 1 size: 2991 MB
node 1 free: 2144 MB
node distances:
node   0   1 
  0:  10  30 
  1:  30  10 

dmesg output for PV guest:

[    0.000000] NUMA: Initialized distance table, cnt=2
[    0.000000] NUMA: Node 1 [mem 0xbb800000-0xce68efff] + [mem 0x100000000-0x1a8970fff] -> [mem 0xbb800000-0x1a8970fff]
[    0.000000] NODE_DATA(0) allocated [mem 0xbb7fc000-0xbb7fffff]
[    0.000000] NODE_DATA(1) allocated [mem 0x1a8969000-0x1a896cfff]

numactl output for PV guest:

available: 2 nodes (0-1)
node 0 cpus: 0
node 0 size: 2944 MB
node 0 free: 2917 MB
node 1 cpus: 1
node 1 size: 2934 MB
node 1 free: 2904 MB
node distances:
node   0   1 
  0:  10  30
  1:  30  10

And for a HVM guest on a real NUMA-capable machine:

(XEN) Memory location of each domain:
(XEN) Domain 0 (total: 262144):
(XEN)     Node 0: 245758
(XEN)     Node 1: 16386
(XEN) Domain 2 (total: 2097226):
(XEN)     Node 0: 1046335
(XEN)     Node 1: 1050891
(XEN)      2 vnodes, 4 vcpus
(XEN)        vnode   0 - pnode 0
(XEN)         3840 MB:  0x0 - 0xf0000000
(XEN)         256 MB:  0x100000000 - 0x110000000
(XEN)         vcpus: 0 1 
(XEN)        vnode   1 - pnode 1
(XEN)         4096 MB:  0x110000000 - 0x210000000
(XEN)         vcpus: 2 3 

Wei.

[0] <20141111173606.GC21312@zion.uk.xensource.com>

Wei Liu (19):
  xen: dump vNUMA information with debug key "u"
  xen: make two memory hypercalls vNUMA-aware
  libxc: allocate memory with vNUMA information for PV guest
  libxl: add emacs local variables in libxl_{x86,arm}.c
  libxl: introduce vNUMA types
  libxl: add vmemrange to libxl__domain_build_state
  libxl: introduce libxl__vnuma_config_check
  libxl: x86: factor out e820_host_sanitize
  libxl: functions to build vmemranges for PV guest
  libxl: build, check and pass vNUMA info to Xen for PV guest
  hvmloader: add new fields for vNUMA information
  hvmloader: construct SRAT
  hvmloader: construct SLIT
  hvmloader: disallow memory relocation when vNUMA is enabled
  libxc: allocate memory with vNUMA information for HVM guest
  libxl: build, check and pass vNUMA info to Xen for HVM guest
  libxl: refactor hvm_build_set_params
  libxl: fill vNUMA information in hvm info
  xl: vNUMA support

 docs/man/xl.cfg.pod.5                   |   32 +++++
 tools/firmware/hvmloader/acpi/acpi2_0.h |   61 +++++++++
 tools/firmware/hvmloader/acpi/build.c   |  104 ++++++++++++++
 tools/firmware/hvmloader/pci.c          |   13 ++
 tools/libxc/include/xc_dom.h            |    5 +
 tools/libxc/include/xenguest.h          |    7 +
 tools/libxc/xc_dom_x86.c                |   72 ++++++++--
 tools/libxc/xc_hvm_build_x86.c          |  224 +++++++++++++++++++-----------
 tools/libxc/xc_private.h                |    2 +
 tools/libxl/Makefile                    |    2 +-
 tools/libxl/libxl_arch.h                |    6 +
 tools/libxl/libxl_arm.c                 |   17 +++
 tools/libxl/libxl_create.c              |    9 ++
 tools/libxl/libxl_dom.c                 |  172 ++++++++++++++++++++---
 tools/libxl/libxl_internal.h            |   18 +++
 tools/libxl/libxl_types.idl             |    9 ++
 tools/libxl/libxl_vnuma.c               |  228 +++++++++++++++++++++++++++++++
 tools/libxl/libxl_x86.c                 |  113 +++++++++++++--
 tools/libxl/xl_cmdimpl.c                |  151 ++++++++++++++++++++
 xen/arch/x86/numa.c                     |   46 ++++++-
 xen/common/memory.c                     |   58 +++++++-
 xen/include/public/features.h           |    3 +
 xen/include/public/hvm/hvm_info_table.h |   19 +++
 xen/include/public/memory.h             |    2 +
 24 files changed, 1247 insertions(+), 126 deletions(-)
 create mode 100644 tools/libxl/libxl_vnuma.c

-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnp-0005Ib-Hw; Fri, 21 Nov 2014 15:07:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnn-0005Hu-D5
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:15 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	17/1F-28296-2255F645; Fri, 21 Nov 2014 15:07:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6836 invoked from network); 21 Nov 2014 15:07:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735620"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Ia;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:44 +0000
Message-ID: <1416582421-10789-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 02/19] xen: make two memory hypercalls
	vNUMA-aware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 XENMEM_increase_reservation and XENMEM_populate_physmap
vNUMA-aware.

That is, if guest requests Xen to allocate memory for specific vnode,
Xen can translate vnode to pnode using vNUMA information of that guest.

XENMEMF_vnode is introduced for the guest to mark the node number is in
fact virtual node number and should be translated by Xen.

XENFEAT_memory_op_vnode_supported is introduced to indicate that Xen is
able to translate virtual node to physical node.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 xen/common/memory.c           |   58 ++++++++++++++++++++++++++++++++++++++---
 xen/include/public/features.h |    3 +++
 xen/include/public/memory.h   |    2 ++
 3 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index cc36e39..afdfd04 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -692,6 +692,49 @@ out:
     return rc;
 }
 
+static int translate_vnode_to_pnode(struct domain *d,
+                                    struct xen_memory_reservation *r,
+                                    struct memop_args *a)
+{
+    int rc = 0;
+    unsigned int vnode, pnode;
+
+    /* Note: we don't strictly require non-supported bits set to zero,
+     * so we may have exact_vnode bit set for old guests that don't
+     * support vNUMA.
+     *
+     * To distinguish spurious vnode request v.s. real one, check if
+     * d->vnuma exists.
+     */
+    if ( r->mem_flags & XENMEMF_vnode )
+    {
+        read_lock(&d->vnuma_rwlock);
+        if ( d->vnuma )
+        {
+            vnode = XENMEMF_get_node(r->mem_flags);
+
+            if ( vnode < d->vnuma->nr_vnodes )
+            {
+                pnode = d->vnuma->vnode_to_pnode[vnode];
+
+                a->memflags &=
+                    ~MEMF_node(XENMEMF_get_node(r->mem_flags));
+
+                if ( pnode != NUMA_NO_NODE )
+                {
+                    a->memflags |= MEMF_exact_node;
+                    a->memflags |= MEMF_node(pnode);
+                }
+            }
+            else
+                rc = -EINVAL;
+        }
+        read_unlock(&d->vnuma_rwlock);
+    }
+
+    return rc;
+}
+
 long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d;
@@ -734,10 +777,6 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             args.memflags = MEMF_bits(address_bits);
         }
 
-        args.memflags |= MEMF_node(XENMEMF_get_node(reservation.mem_flags));
-        if ( reservation.mem_flags & XENMEMF_exact_node_request )
-            args.memflags |= MEMF_exact_node;
-
         if ( op == XENMEM_populate_physmap
              && (reservation.mem_flags & XENMEMF_populate_on_demand) )
             args.memflags |= MEMF_populate_on_demand;
@@ -747,6 +786,17 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             return start_extent;
         args.domain = d;
 
+        args.memflags |= MEMF_node(XENMEMF_get_node(reservation.mem_flags));
+        if ( reservation.mem_flags & XENMEMF_exact_node_request )
+            args.memflags |= MEMF_exact_node;
+
+        rc = translate_vnode_to_pnode(d, &reservation, &args);
+        if ( rc )
+        {
+            rcu_unlock_domain(d);
+            return rc;
+        }
+
         rc = xsm_memory_adjust_reservation(XSM_TARGET, current->domain, d);
         if ( rc )
         {
diff --git a/xen/include/public/features.h b/xen/include/public/features.h
index 16d92aa..9f33502 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -99,6 +99,9 @@
 #define XENFEAT_grant_map_identity        12
  */
 
+/* Guset can use XENMEMF_vnode to specify virtual node for memory op. */
+#define XENFEAT_memory_op_vnode_supported 13
+
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index f021958..f2e5d14 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -55,6 +55,8 @@
 /* Flag to request allocation only from the node specified */
 #define XENMEMF_exact_node_request  (1<<17)
 #define XENMEMF_exact_node(n) (XENMEMF_node(n) | XENMEMF_exact_node_request)
+/* Flag to indicate the node specified is virtual node */
+#define XENMEMF_vnode  (1<<18)
 #endif
 
 struct xen_memory_reservation {
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpno-0005I5-5t; Fri, 21 Nov 2014 15:07:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnm-0005Hr-Rq
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:14 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	53/BE-25547-2255F645; Fri, 21 Nov 2014 15:07:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6703 invoked from network); 21 Nov 2014 15:07:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735619"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-GZ;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:43 +0000
Message-ID: <1416582421-10789-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Elena Ufimsteva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 01/19] xen: dump vNUMA information with debug
	key "u"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Elena Ufimsteva <ufimtseva@gmail.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 xen/arch/x86/numa.c |   46 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 628a40a..d27c30f 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -363,10 +363,12 @@ EXPORT_SYMBOL(node_data);
 static void dump_numa(unsigned char key)
 {
     s_time_t now = NOW();
-    int i;
+    int i, j, err, n;
     struct domain *d;
     struct page_info *page;
     unsigned int page_num_node[MAX_NUMNODES];
+    uint64_t mem;
+    struct vnuma_info *vnuma;
 
     printk("'%c' pressed -> dumping numa info (now-0x%X:%08X)\n", key,
            (u32)(now>>32), (u32)now);
@@ -408,6 +410,48 @@ static void dump_numa(unsigned char key)
 
         for_each_online_node ( i )
             printk("    Node %u: %u\n", i, page_num_node[i]);
+
+        if ( !d->vnuma )
+                continue;
+
+        vnuma = d->vnuma;
+        printk("     %u vnodes, %u vcpus\n", vnuma->nr_vnodes, d->max_vcpus);
+        for ( i = 0; i < vnuma->nr_vnodes; i++ )
+        {
+            err = snprintf(keyhandler_scratch, 12, "%u",
+                    vnuma->vnode_to_pnode[i]);
+            if ( err < 0 || vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
+                snprintf(keyhandler_scratch, 3, "???");
+
+            printk("       vnode %3u - pnode %s\n", i, keyhandler_scratch);
+            for ( j = 0; j < vnuma->nr_vmemranges; j++ )
+            {
+                if ( vnuma->vmemrange[j].nid == i )
+                {
+                    mem = vnuma->vmemrange[j].end - vnuma->vmemrange[j].start;
+                    printk("        %"PRIu64" MB: ", mem >> 20);
+                    printk(" 0x%"PRIx64" - 0x%"PRIx64"\n",
+                           vnuma->vmemrange[j].start,
+                           vnuma->vmemrange[j].end);
+                }
+            }
+
+            printk("        vcpus: ");
+            for ( j = 0, n = 0; j < d->max_vcpus; j++ )
+            {
+                if ( vnuma->vcpu_to_vnode[j] == i )
+                {
+                    if ( (n + 1) % 8 == 0 )
+                        printk("%d\n", j);
+                    else if ( !(n % 8) && n != 0 )
+                        printk("                %d ", j);
+                    else
+                        printk("%d ", j);
+                    n++;
+                }
+            }
+            printk("\n");
+        }
     }
 
     rcu_read_unlock(&domlist_read_lock);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpns-0005LG-4Q; Fri, 21 Nov 2014 15:07:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnp-0005IY-Uf
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:18 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	80/3F-28296-5255F645; Fri, 21 Nov 2014 15:07:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416582435!12946201!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26106 invoked from network); 21 Nov 2014 15:07:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735628"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-M1;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:49 +0000
Message-ID: <1416582421-10789-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 07/19] libxl: introduce libxl__vnuma_config_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 vNUMA function (and future ones) is placed in a new file called
libxl_vnuma.c

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl_internal.h |    5 ++
 tools/libxl/libxl_vnuma.c    |  138 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 144 insertions(+), 1 deletion(-)
 create mode 100644 tools/libxl/libxl_vnuma.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index df08c8a..9fcdfb1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -93,7 +93,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_aoutils.o libxl_numa.o \
+			libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o \
 			libxl_save_callout.o _libxl_save_msgs_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7ee7482..ee76df6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3392,6 +3392,11 @@ void libxl__numa_candidate_put_nodemap(libxl__gc *gc,
     libxl_bitmap_copy(CTX, &cndt->nodemap, nodemap);
 }
 
+/* Check if vNUMA config is valid. Returns 0 if valid. */
+int libxl__vnuma_config_check(libxl__gc *gc,
+                              const libxl_domain_build_info *b_info,
+                              const libxl__domain_build_state *state);
+
 _hidden int libxl__ms_vm_genid_set(libxl__gc *gc, uint32_t domid,
                                    const libxl_ms_vm_genid *id);
 
diff --git a/tools/libxl/libxl_vnuma.c b/tools/libxl/libxl_vnuma.c
new file mode 100644
index 0000000..f5912e6
--- /dev/null
+++ b/tools/libxl/libxl_vnuma.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2014      Citrix Ltd.
+ * Author Wei Liu <wei.liu2@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxl_internal.h"
+#include <stdlib.h>
+
+/* Sort vmemranges in ascending order with "start" */
+static int compare_vmemrange(const void *a, const void *b)
+{
+    const vmemrange_t *x = a, *y = b;
+    if (x->start < y->start)
+        return -1;
+    if (x->start > y->start)
+        return 1;
+    return 0;
+}
+
+/* Check if vNUMA configuration is valid:
+ *  1. all pnodes inside vnode_to_pnode array are valid
+ *  2. one vcpu belongs to and only belongs to one vnode
+ *  3. each vmemrange is valid and doesn't overlap with each other
+ */
+int libxl__vnuma_config_check(libxl__gc *gc,
+			      const libxl_domain_build_info *b_info,
+                              const libxl__domain_build_state *state)
+{
+    int i, j, rc = ERROR_INVAL, nr_nodes;
+    libxl_numainfo *ninfo = NULL;
+    uint64_t total_ram = 0;
+    libxl_bitmap cpumap;
+    libxl_vnode_info *p;
+
+    libxl_bitmap_init(&cpumap);
+
+    /* Check pnode specified is valid */
+    ninfo = libxl_get_numainfo(CTX, &nr_nodes);
+    if (!ninfo) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "libxl_get_numainfo failed");
+        goto out;
+    }
+
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        uint32_t pnode;
+
+        p = &b_info->vnuma_nodes[i];
+        pnode = p->pnode;
+
+        /* The pnode specified is not valid? */
+        if (pnode >= nr_nodes) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "Invalid pnode %d specified",
+                       pnode);
+            goto out;
+        }
+
+        total_ram += p->mem;
+    }
+
+    if (total_ram != (b_info->max_memkb >> 10)) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "Total ram in vNUMA configuration 0x%"PRIx64" while maxmem specified 0x%"PRIx64,
+                   total_ram, (b_info->max_memkb >> 10));
+        goto out;
+    }
+
+    /* Check vcpu mapping */
+    libxl_cpu_bitmap_alloc(CTX, &cpumap, b_info->max_vcpus);
+    libxl_bitmap_set_none(&cpumap);
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        p = &b_info->vnuma_nodes[i];
+        libxl_for_each_set_bit(j, p->vcpus) {
+            if (!libxl_bitmap_test(&cpumap, j))
+                libxl_bitmap_set(&cpumap, j);
+            else {
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                           "Try to assign vcpu %d to vnode %d while it's already assigned to other vnode",
+                           j, i);
+                goto out;
+            }
+        }
+    }
+
+    for (i = 0; i < b_info->max_vcpus; i++) {
+        if (!libxl_bitmap_test(&cpumap, i)) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "Vcpu %d is not assigned to any vnode", i);
+            goto out;
+        }
+    }
+
+    /* Check vmemranges */
+    qsort(state->vmemranges, state->num_vmemranges, sizeof(vmemrange_t),
+          compare_vmemrange);
+
+    for (i = 0; i < state->num_vmemranges; i++) {
+        if (state->vmemranges[i].end < state->vmemranges[i].start) {
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                           "Vmemrange end < start");
+                goto out;
+        }
+    }
+
+    for (i = 0; i < state->num_vmemranges - 1; i++) {
+        if (state->vmemranges[i].end > state->vmemranges[i+1].start) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "Vmemranges overlapped, 0x%"PRIx64"-0x%"PRIx64", 0x%"PRIx64"-0x%"PRIx64,
+                       state->vmemranges[i].start, state->vmemranges[i].end,
+                       state->vmemranges[i+1].start, state->vmemranges[i+1].end);
+            goto out;
+        }
+    }
+
+    rc = 0;
+out:
+    if (ninfo) libxl_numainfo_dispose(ninfo);
+    libxl_bitmap_dispose(&cpumap);
+    return rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnt-0005MR-1E; Fri, 21 Nov 2014 15:07:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnq-0005JL-TE
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:19 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	C6/3F-28296-5255F645; Fri, 21 Nov 2014 15:07:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7147 invoked from network); 21 Nov 2014 15:07:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735626"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Mi;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:50 +0000
Message-ID: <1416582421-10789-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 08/19] libxl: x86: factor out e820_host_sanitize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function gets the machine E820 map and sanitize it according to PV
guest configuration.

This will be used in later patch.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_x86.c |   31 ++++++++++++++++++++++---------
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 9ceb373..e959e37 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -207,6 +207,27 @@ static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
     return 0;
 }
 
+static int e820_host_sanitize(libxl__gc *gc,
+                              libxl_domain_build_info *b_info,
+                              struct e820entry map[],
+                              uint32_t *nr)
+{
+    int rc;
+
+    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);
+    return rc;
+}
+
 static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid,
         libxl_domain_config *d_config)
 {
@@ -223,15 +244,7 @@ static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid,
     if (!libxl_defbool_val(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);
+    rc = e820_host_sanitize(gc, b_info, map, &nr);
     if (rc)
         return ERROR_FAIL;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpno-0005I5-5t; Fri, 21 Nov 2014 15:07:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnm-0005Hr-Rq
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:14 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	53/BE-25547-2255F645; Fri, 21 Nov 2014 15:07:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6703 invoked from network); 21 Nov 2014 15:07:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735619"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-GZ;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:43 +0000
Message-ID: <1416582421-10789-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Elena Ufimsteva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 01/19] xen: dump vNUMA information with debug
	key "u"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Elena Ufimsteva <ufimtseva@gmail.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 xen/arch/x86/numa.c |   46 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 628a40a..d27c30f 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -363,10 +363,12 @@ EXPORT_SYMBOL(node_data);
 static void dump_numa(unsigned char key)
 {
     s_time_t now = NOW();
-    int i;
+    int i, j, err, n;
     struct domain *d;
     struct page_info *page;
     unsigned int page_num_node[MAX_NUMNODES];
+    uint64_t mem;
+    struct vnuma_info *vnuma;
 
     printk("'%c' pressed -> dumping numa info (now-0x%X:%08X)\n", key,
            (u32)(now>>32), (u32)now);
@@ -408,6 +410,48 @@ static void dump_numa(unsigned char key)
 
         for_each_online_node ( i )
             printk("    Node %u: %u\n", i, page_num_node[i]);
+
+        if ( !d->vnuma )
+                continue;
+
+        vnuma = d->vnuma;
+        printk("     %u vnodes, %u vcpus\n", vnuma->nr_vnodes, d->max_vcpus);
+        for ( i = 0; i < vnuma->nr_vnodes; i++ )
+        {
+            err = snprintf(keyhandler_scratch, 12, "%u",
+                    vnuma->vnode_to_pnode[i]);
+            if ( err < 0 || vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
+                snprintf(keyhandler_scratch, 3, "???");
+
+            printk("       vnode %3u - pnode %s\n", i, keyhandler_scratch);
+            for ( j = 0; j < vnuma->nr_vmemranges; j++ )
+            {
+                if ( vnuma->vmemrange[j].nid == i )
+                {
+                    mem = vnuma->vmemrange[j].end - vnuma->vmemrange[j].start;
+                    printk("        %"PRIu64" MB: ", mem >> 20);
+                    printk(" 0x%"PRIx64" - 0x%"PRIx64"\n",
+                           vnuma->vmemrange[j].start,
+                           vnuma->vmemrange[j].end);
+                }
+            }
+
+            printk("        vcpus: ");
+            for ( j = 0, n = 0; j < d->max_vcpus; j++ )
+            {
+                if ( vnuma->vcpu_to_vnode[j] == i )
+                {
+                    if ( (n + 1) % 8 == 0 )
+                        printk("%d\n", j);
+                    else if ( !(n % 8) && n != 0 )
+                        printk("                %d ", j);
+                    else
+                        printk("%d ", j);
+                    n++;
+                }
+            }
+            printk("\n");
+        }
     }
 
     rcu_read_unlock(&domlist_read_lock);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:07:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpnr-0005Km-NL; Fri, 21 Nov 2014 15:07:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrpnp-0005IN-DE
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:07:17 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	18/6C-09284-4255F645; Fri, 21 Nov 2014 15:07:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416582432!12927286!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7068 invoked from network); 21 Nov 2014 15:07:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:07:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193735624"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:07:02 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Ki;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:47 +0000
Message-ID: <1416582421-10789-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 05/19] libxl: introduce vNUMA 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_types.idl |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..75855fb 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -353,6 +353,13 @@ libxl_domain_sched_params = Struct("domain_sched_params",[
     ("budget",       integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),
     ])
 
+libxl_vnode_info = Struct("vnode_info", [
+    ("mem", uint64), # memory size of this node, in MiB
+    ("distances", Array(uint32, "num_distances")), # distances from this node to other nodes
+    ("pnode", uint32), # physical node of this node
+    ("vcpus", libxl_bitmap), # vcpus in this node
+    ])
+
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("avail_vcpus",     libxl_bitmap),
@@ -373,6 +380,8 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("blkdev_start",    string),
+
+    ("vnuma_nodes", Array(libxl_vnode_info, "num_vnuma_nodes")),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", libxl_defbool),
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:14:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:14:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpuh-0006e5-7k; Fri, 21 Nov 2014 15:14:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrpuf-0006e0-Q8
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:14:22 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	69/43-27584-DC65F645; Fri, 21 Nov 2014 15:14:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416582858!7412231!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26458 invoked from network); 21 Nov 2014 15:14:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 15:14:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALFEBHE023305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 15:14:12 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFE9gw010910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 15:14:10 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFE9En009679; Fri, 21 Nov 2014 15:14:09 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 07:14:09 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id F2ECA11892C; Fri, 21 Nov 2014 10:14:07 -0500 (EST)
Date: Fri, 21 Nov 2014 10:14:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121151407.GD2886@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ"
Content-Disposition: inline
In-Reply-To: <546F382F0200007800049B49@smtp.nue.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Nov 21, 2014 at 01:03:43PM +0100, Jan Beulich wrote:
> >>> On 21.11.14 at 12:50, <konrad.wilk@oracle.com> wrote:
> > On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
> >>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
> >>struct hvm_pirq_dpci *pirq_dpci)
> >>>      ASSERT(d->arch.hvm_domain.irq.dpci);
> >>>  
> >>>      spin_lock(&d->event_lock);
> >>> -    if ( pirq_dpci->state )
> >>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
> >>>      {
> >>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
> >>>          const struct dev_intx_gsi_link *digl;
> >>
> >>So this now guards solely against the timeout enforced EOI? Why do
> >>you no longer need to guard against cancellation (i.e. why isn't this
> >>looking at both ->state and ->masked)?
> >>
> > 
> > The previous state check was superfluous as the dpci_softirq would check for 
> > the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).
> 
> I thought so first too, but then how is the guarding against
> cancellation working now?

Since there are two forms of cancellation, lets consider each one seperatly:

1). pt_irq_create_bind and pt_irq_destroy_bind. Each of them calling 
    pt_pirq_softirq_reset in the 'error' case or in the normal path of destruction.
    When that happens the action handler for the IRQ is removed the moment we call
    pirq_guest_unbind. As such we only have to deal with the potential outstanding
    pirq_dpci waiting to be serviced. Since we did the 'pt_pirq_softirq_reset'
    we have changed the state from STATE_SCHED to zero. That means dpci_softirq will
    NOT go in:
	if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               
        {                                                                       
            hvm_dirq_assist(d, pirq_dpci);                                      
            put_domain(d);                                                      
        }                                         
   and not call hvm_dirq_assist. The 'masked' will be set which is OK, as the moment
   the pirq is restored (pt_irq_create_bind), the 'hvm_do_IRQ_dpci' will stamp
   'masked' again and schedule the hvm_pirq_dpic. In that sense that logic is
   unchanged. We could add and 'else pirq_dpci->masked = 0' for clarity in
   'dpci_softirq' but it does not change the logic (as only hvm_dirq_assist cares
   about it and it is not called).

2). The 'pt_irq_guest_eoi' cancelling the 'hvm_dirq_assist' from running. That
   now is added - which f6dd295381f4b6a66acddacf46bca8940586c8d8
    "dpci: replace tasklet with softirq" broke. That is the cancellation between
   IRQ timeout and the hvm_dirq_assist.

3). 'pt_irq_destroy_bind' and an outstanding timer (so two cancellations at once).

   If during that time (say before the 8ms is up) the 'pt_irq_destroy_bind' is
   called it will:

    a) clear all the 'digl_list' entries - so if pt_irq_guest_eoi -
      (which takes the same lock as 'pt_irq_destroy_bind') is invoked at that
      time it won't be able to do much.
    b) kills the timer (no more 'pt_irq_guest_eoi' ),
    c) and clear STATE_SCHED so it will no longer try to run 'hvm_dirq_assist'.

   If during that time an interrupt does happen, depending on where we are in the
   teardown path - it will either send one more event in the guest or just not
   do much.

   (Thought I did spot a bug in that, see #5 below).


 4). The other case is where 'pt_irq_destroy_bind' is called while 'pt_irq_guest_eoi'
  (timeout) is in progress. AT that point nothing can happen as 'pt_irq_time_out' has
  taken the lock, so 'pt_irq_destroy_bind' cannot continue until the lock is released.

  If another interrupt is triggered and it is scheduled in, we are back at the 3)
  scenario.

 5). 'pt_irq_destroy_bind' is called while an 'hvm_dirq_assist' is just about
to service. The 'pt_irq_destroy_bind' takes the lock first and kills the
timer (and it failed at the cmpxchg since the 'state' is in STATE_RUN)  - and the
moment it releases the spinlock, 'hvm_dirq_assist' thunders in and calls
'set_timer' hitting an ASSERT.

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 4d8c02f..c5cf7c7 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -539,6 +539,7 @@ int pt_irq_destroy_bind(
          * call to pt_pirq_softirq_reset.
          */
         pt_pirq_softirq_reset(pirq_dpci);
+        pirq_dpci->masked = 0;
 
         pirq_cleanup_check(pirq, d);
     }


which will be make 'hvm_dirq_assist' inhibit calling 'set_timer' as it won't
go past:
    if ( test_and_clear_bool(pirq_dpci->masked) )                               

(which is right after the spin-lock that 'pt_irq_destroy_bind' spins on).

Let me roll in the above code snippet in the patch.

Now looking at the various error cancellations points, we have the PT_IRQ_TYPE_MSI
which we can ignore as we do not use the timer (and hvm_dirq_assist never gets to
call 'set_timer). The PT_IRQ_TYPE_PCI|PT_IRQ_TYPE_MSI_TRANSLATE error path we can
ignore that as 'There is no path for __do_IRQ to schedule softirq as IRQ_GUEST is
not set.' - so it won't ever schedule the 'hvm_dirq_dpci'. The only case we do
have to worry about is during the destruction.

Attached and inline patch:

>From 23cc8d6039c1a6002cbcb7ca4a06b20b818d3534 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 14:28:11 -0500
Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

commit f6dd295381f4b6a66acddacf46bca8940586c8d8
"dpci: replace tasklet with softirq" used the 'masked' as an
two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
between 'raise_softirq_for' and 'dpci_softirq' to determine whether
the 'struct hvm_pirq_dpci' can be re-scheduled.

However it ignored the 'pt_irq_guest_eoi' was not adhering to the proper
dialogue and was not using locked cmpxchg or test_bit operations and
ended setting 'state' set to zero. That meant 'raise_softirq_for' was
free to schedule it while the 'struct hvm_pirq_dpci'' was still on an
per-cpu list causing an list corruption.

The code would trigger the following path causing list corruption:

    \-timer_softirq_action
    	pt_irq_time_out calls pt_pirq_softirq_cancel sets state to 0.
            pirq_dpci is still on dpci_list.
    \- dpci_sofitrq
    	while (!list_emptry(&our_list))
    		list_del, but has not yet done 'entry->next = LIST_POISON1;'
    [interrupt happens]
    	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
    [interrupt is done, back to dpci_softirq]
    	finishes the entry->next = LIST_POISON1;
    		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
    	ends the loop, exits.

    \- dpci_softirq
    	while (!list_emtpry)
    		list_del, but ->next already has LIST_POISON1 and we blow up.

An alternative solution was proposed (adding STATE_ZOMBIE and making
pt_irq_time_out use the cmpxchg protocol on 'state'), which fixed the above
issue but had an fatal bug. It would miss interrupts that are to be scheduled!

This patch brings back the 'masked' boolean which is used as an
communication channel between 'hvm_do_IRQ_dpci', 'hvm_dirq_assist' and
'pt_irq_guest_eoi'. When we have an interrupt we set 'masked'. Anytime
'hvm_dirq_assist' or 'pt_irq_guest_eoi' executes - it clears it.

The 'state' is left as a seperate mechanism to provide an mechanism between
'raise_sofitrq' and 'softirq_dpci' to communicate the state of the
'struct hvm_dirq_pirq'.

However since we have now two seperate machines we have to deal with an
cancellations and outstanding interrupt being serviced: 'pt_irq_destroy_bind'
is called while an 'hvm_dirq_assist' is just about to service.
The 'pt_irq_destroy_bind' takes the lock first and kills the timer - and
the moment it releases the spinlock, 'hvm_dirq_assist' thunders in and calls
'set_timer' hitting an ASSERT.

By clearing the 'masked' in the 'pt_irq_destroy_bind' we take care of that
scenario by inhibiting 'hvm_dirq_assist' to call the 'set_timer'.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
v2: Deal with 'masked' in pt_irq_destroy_bind.
---
 xen/drivers/passthrough/io.c | 6 ++++--
 xen/include/xen/hvm/irq.h    | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..c5cf7c7 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -142,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pirq_dpci->masked = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -539,6 +539,7 @@ int pt_irq_destroy_bind(
          * call to pt_pirq_softirq_reset.
          */
         pt_pirq_softirq_reset(pirq_dpci);
+        pirq_dpci->masked = 0;
 
         pirq_cleanup_check(pirq, d);
     }
@@ -610,6 +611,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
+    pirq_dpci->masked = 1;
     raise_softirq_for(pirq_dpci);
     return 1;
 }
@@ -669,7 +671,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( pirq_dpci->state )
+    if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..3996f1f 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -94,6 +94,7 @@ struct hvm_irq_dpci {
 struct hvm_pirq_dpci {
     uint32_t flags;
     unsigned int state;
+    bool_t masked;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
-- 
1.9.3


--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-dpci-Add-masked-as-an-gate-for-hvm_dirq_assist-to-pr.patch"

>From 23cc8d6039c1a6002cbcb7ca4a06b20b818d3534 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 14:28:11 -0500
Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

commit f6dd295381f4b6a66acddacf46bca8940586c8d8
"dpci: replace tasklet with softirq" used the 'masked' as an
two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
between 'raise_softirq_for' and 'dpci_softirq' to determine whether
the 'struct hvm_pirq_dpci' can be re-scheduled.

However it ignored the 'pt_irq_guest_eoi' was not adhering to the proper
dialogue and was not using locked cmpxchg or test_bit operations and
ended setting 'state' set to zero. That meant 'raise_softirq_for' was
free to schedule it while the 'struct hvm_pirq_dpci'' was still on an
per-cpu list causing an list corruption.

The code would trigger the following path causing list corruption:

    \-timer_softirq_action
    	pt_irq_time_out calls pt_pirq_softirq_cancel sets state to 0.
            pirq_dpci is still on dpci_list.
    \- dpci_sofitrq
    	while (!list_emptry(&our_list))
    		list_del, but has not yet done 'entry->next = LIST_POISON1;'
    [interrupt happens]
    	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
    [interrupt is done, back to dpci_softirq]
    	finishes the entry->next = LIST_POISON1;
    		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
    	ends the loop, exits.

    \- dpci_softirq
    	while (!list_emtpry)
    		list_del, but ->next already has LIST_POISON1 and we blow up.

An alternative solution was proposed (adding STATE_ZOMBIE and making
pt_irq_time_out use the cmpxchg protocol on 'state'), which fixed the above
issue but had an fatal bug. It would miss interrupts that are to be scheduled!

This patch brings back the 'masked' boolean which is used as an
communication channel between 'hvm_do_IRQ_dpci', 'hvm_dirq_assist' and
'pt_irq_guest_eoi'. When we have an interrupt we set 'masked'. Anytime
'hvm_dirq_assist' or 'pt_irq_guest_eoi' executes - it clears it.

The 'state' is left as a seperate mechanism to provide an mechanism between
'raise_sofitrq' and 'softirq_dpci' to communicate the state of the
'struct hvm_dirq_pirq'.

However since we have now two seperate machines we have to deal with an
cancellations and outstanding interrupt being serviced: 'pt_irq_destroy_bind'
is called while an 'hvm_dirq_assist' is just about to service.
The 'pt_irq_destroy_bind' takes the lock first and kills the timer - and
the moment it releases the spinlock, 'hvm_dirq_assist' thunders in and calls
'set_timer' hitting an ASSERT.

By clearing the 'masked' in the 'pt_irq_destroy_bind' we take care of that
scenario by inhibiting 'hvm_dirq_assist' to call the 'set_timer'.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
v2: Deal with 'masked' in pt_irq_destroy_bind.
---
 xen/drivers/passthrough/io.c | 6 ++++--
 xen/include/xen/hvm/irq.h    | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..c5cf7c7 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -142,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pirq_dpci->masked = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -539,6 +539,7 @@ int pt_irq_destroy_bind(
          * call to pt_pirq_softirq_reset.
          */
         pt_pirq_softirq_reset(pirq_dpci);
+        pirq_dpci->masked = 0;
 
         pirq_cleanup_check(pirq, d);
     }
@@ -610,6 +611,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
+    pirq_dpci->masked = 1;
     raise_softirq_for(pirq_dpci);
     return 1;
 }
@@ -669,7 +671,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( pirq_dpci->state )
+    if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..3996f1f 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -94,6 +94,7 @@ struct hvm_irq_dpci {
 struct hvm_pirq_dpci {
     uint32_t flags;
     unsigned int state;
+    bool_t masked;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
-- 
1.9.3


--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--lrZ03NoBR/3+SXJZ--


From xen-devel-bounces@lists.xen.org Fri Nov 21 15:14:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:14:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrpuh-0006e5-7k; Fri, 21 Nov 2014 15:14:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrpuf-0006e0-Q8
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:14:22 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	69/43-27584-DC65F645; Fri, 21 Nov 2014 15:14:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416582858!7412231!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26458 invoked from network); 21 Nov 2014 15:14:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 15:14:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALFEBHE023305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 15:14:12 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFE9gw010910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 15:14:10 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFE9En009679; Fri, 21 Nov 2014 15:14:09 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 07:14:09 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id F2ECA11892C; Fri, 21 Nov 2014 10:14:07 -0500 (EST)
Date: Fri, 21 Nov 2014 10:14:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121151407.GD2886@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ"
Content-Disposition: inline
In-Reply-To: <546F382F0200007800049B49@smtp.nue.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Nov 21, 2014 at 01:03:43PM +0100, Jan Beulich wrote:
> >>> On 21.11.14 at 12:50, <konrad.wilk@oracle.com> wrote:
> > On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
> >>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
> >>struct hvm_pirq_dpci *pirq_dpci)
> >>>      ASSERT(d->arch.hvm_domain.irq.dpci);
> >>>  
> >>>      spin_lock(&d->event_lock);
> >>> -    if ( pirq_dpci->state )
> >>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
> >>>      {
> >>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
> >>>          const struct dev_intx_gsi_link *digl;
> >>
> >>So this now guards solely against the timeout enforced EOI? Why do
> >>you no longer need to guard against cancellation (i.e. why isn't this
> >>looking at both ->state and ->masked)?
> >>
> > 
> > The previous state check was superfluous as the dpci_softirq would check for 
> > the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).
> 
> I thought so first too, but then how is the guarding against
> cancellation working now?

Since there are two forms of cancellation, lets consider each one seperatly:

1). pt_irq_create_bind and pt_irq_destroy_bind. Each of them calling 
    pt_pirq_softirq_reset in the 'error' case or in the normal path of destruction.
    When that happens the action handler for the IRQ is removed the moment we call
    pirq_guest_unbind. As such we only have to deal with the potential outstanding
    pirq_dpci waiting to be serviced. Since we did the 'pt_pirq_softirq_reset'
    we have changed the state from STATE_SCHED to zero. That means dpci_softirq will
    NOT go in:
	if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               
        {                                                                       
            hvm_dirq_assist(d, pirq_dpci);                                      
            put_domain(d);                                                      
        }                                         
   and not call hvm_dirq_assist. The 'masked' will be set which is OK, as the moment
   the pirq is restored (pt_irq_create_bind), the 'hvm_do_IRQ_dpci' will stamp
   'masked' again and schedule the hvm_pirq_dpic. In that sense that logic is
   unchanged. We could add and 'else pirq_dpci->masked = 0' for clarity in
   'dpci_softirq' but it does not change the logic (as only hvm_dirq_assist cares
   about it and it is not called).

2). The 'pt_irq_guest_eoi' cancelling the 'hvm_dirq_assist' from running. That
   now is added - which f6dd295381f4b6a66acddacf46bca8940586c8d8
    "dpci: replace tasklet with softirq" broke. That is the cancellation between
   IRQ timeout and the hvm_dirq_assist.

3). 'pt_irq_destroy_bind' and an outstanding timer (so two cancellations at once).

   If during that time (say before the 8ms is up) the 'pt_irq_destroy_bind' is
   called it will:

    a) clear all the 'digl_list' entries - so if pt_irq_guest_eoi -
      (which takes the same lock as 'pt_irq_destroy_bind') is invoked at that
      time it won't be able to do much.
    b) kills the timer (no more 'pt_irq_guest_eoi' ),
    c) and clear STATE_SCHED so it will no longer try to run 'hvm_dirq_assist'.

   If during that time an interrupt does happen, depending on where we are in the
   teardown path - it will either send one more event in the guest or just not
   do much.

   (Thought I did spot a bug in that, see #5 below).


 4). The other case is where 'pt_irq_destroy_bind' is called while 'pt_irq_guest_eoi'
  (timeout) is in progress. AT that point nothing can happen as 'pt_irq_time_out' has
  taken the lock, so 'pt_irq_destroy_bind' cannot continue until the lock is released.

  If another interrupt is triggered and it is scheduled in, we are back at the 3)
  scenario.

 5). 'pt_irq_destroy_bind' is called while an 'hvm_dirq_assist' is just about
to service. The 'pt_irq_destroy_bind' takes the lock first and kills the
timer (and it failed at the cmpxchg since the 'state' is in STATE_RUN)  - and the
moment it releases the spinlock, 'hvm_dirq_assist' thunders in and calls
'set_timer' hitting an ASSERT.

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 4d8c02f..c5cf7c7 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -539,6 +539,7 @@ int pt_irq_destroy_bind(
          * call to pt_pirq_softirq_reset.
          */
         pt_pirq_softirq_reset(pirq_dpci);
+        pirq_dpci->masked = 0;
 
         pirq_cleanup_check(pirq, d);
     }


which will be make 'hvm_dirq_assist' inhibit calling 'set_timer' as it won't
go past:
    if ( test_and_clear_bool(pirq_dpci->masked) )                               

(which is right after the spin-lock that 'pt_irq_destroy_bind' spins on).

Let me roll in the above code snippet in the patch.

Now looking at the various error cancellations points, we have the PT_IRQ_TYPE_MSI
which we can ignore as we do not use the timer (and hvm_dirq_assist never gets to
call 'set_timer). The PT_IRQ_TYPE_PCI|PT_IRQ_TYPE_MSI_TRANSLATE error path we can
ignore that as 'There is no path for __do_IRQ to schedule softirq as IRQ_GUEST is
not set.' - so it won't ever schedule the 'hvm_dirq_dpci'. The only case we do
have to worry about is during the destruction.

Attached and inline patch:

>From 23cc8d6039c1a6002cbcb7ca4a06b20b818d3534 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 14:28:11 -0500
Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

commit f6dd295381f4b6a66acddacf46bca8940586c8d8
"dpci: replace tasklet with softirq" used the 'masked' as an
two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
between 'raise_softirq_for' and 'dpci_softirq' to determine whether
the 'struct hvm_pirq_dpci' can be re-scheduled.

However it ignored the 'pt_irq_guest_eoi' was not adhering to the proper
dialogue and was not using locked cmpxchg or test_bit operations and
ended setting 'state' set to zero. That meant 'raise_softirq_for' was
free to schedule it while the 'struct hvm_pirq_dpci'' was still on an
per-cpu list causing an list corruption.

The code would trigger the following path causing list corruption:

    \-timer_softirq_action
    	pt_irq_time_out calls pt_pirq_softirq_cancel sets state to 0.
            pirq_dpci is still on dpci_list.
    \- dpci_sofitrq
    	while (!list_emptry(&our_list))
    		list_del, but has not yet done 'entry->next = LIST_POISON1;'
    [interrupt happens]
    	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
    [interrupt is done, back to dpci_softirq]
    	finishes the entry->next = LIST_POISON1;
    		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
    	ends the loop, exits.

    \- dpci_softirq
    	while (!list_emtpry)
    		list_del, but ->next already has LIST_POISON1 and we blow up.

An alternative solution was proposed (adding STATE_ZOMBIE and making
pt_irq_time_out use the cmpxchg protocol on 'state'), which fixed the above
issue but had an fatal bug. It would miss interrupts that are to be scheduled!

This patch brings back the 'masked' boolean which is used as an
communication channel between 'hvm_do_IRQ_dpci', 'hvm_dirq_assist' and
'pt_irq_guest_eoi'. When we have an interrupt we set 'masked'. Anytime
'hvm_dirq_assist' or 'pt_irq_guest_eoi' executes - it clears it.

The 'state' is left as a seperate mechanism to provide an mechanism between
'raise_sofitrq' and 'softirq_dpci' to communicate the state of the
'struct hvm_dirq_pirq'.

However since we have now two seperate machines we have to deal with an
cancellations and outstanding interrupt being serviced: 'pt_irq_destroy_bind'
is called while an 'hvm_dirq_assist' is just about to service.
The 'pt_irq_destroy_bind' takes the lock first and kills the timer - and
the moment it releases the spinlock, 'hvm_dirq_assist' thunders in and calls
'set_timer' hitting an ASSERT.

By clearing the 'masked' in the 'pt_irq_destroy_bind' we take care of that
scenario by inhibiting 'hvm_dirq_assist' to call the 'set_timer'.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
v2: Deal with 'masked' in pt_irq_destroy_bind.
---
 xen/drivers/passthrough/io.c | 6 ++++--
 xen/include/xen/hvm/irq.h    | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..c5cf7c7 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -142,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pirq_dpci->masked = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -539,6 +539,7 @@ int pt_irq_destroy_bind(
          * call to pt_pirq_softirq_reset.
          */
         pt_pirq_softirq_reset(pirq_dpci);
+        pirq_dpci->masked = 0;
 
         pirq_cleanup_check(pirq, d);
     }
@@ -610,6 +611,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
+    pirq_dpci->masked = 1;
     raise_softirq_for(pirq_dpci);
     return 1;
 }
@@ -669,7 +671,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( pirq_dpci->state )
+    if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..3996f1f 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -94,6 +94,7 @@ struct hvm_irq_dpci {
 struct hvm_pirq_dpci {
     uint32_t flags;
     unsigned int state;
+    bool_t masked;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
-- 
1.9.3


--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-dpci-Add-masked-as-an-gate-for-hvm_dirq_assist-to-pr.patch"

>From 23cc8d6039c1a6002cbcb7ca4a06b20b818d3534 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 14:28:11 -0500
Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

commit f6dd295381f4b6a66acddacf46bca8940586c8d8
"dpci: replace tasklet with softirq" used the 'masked' as an
two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
between 'raise_softirq_for' and 'dpci_softirq' to determine whether
the 'struct hvm_pirq_dpci' can be re-scheduled.

However it ignored the 'pt_irq_guest_eoi' was not adhering to the proper
dialogue and was not using locked cmpxchg or test_bit operations and
ended setting 'state' set to zero. That meant 'raise_softirq_for' was
free to schedule it while the 'struct hvm_pirq_dpci'' was still on an
per-cpu list causing an list corruption.

The code would trigger the following path causing list corruption:

    \-timer_softirq_action
    	pt_irq_time_out calls pt_pirq_softirq_cancel sets state to 0.
            pirq_dpci is still on dpci_list.
    \- dpci_sofitrq
    	while (!list_emptry(&our_list))
    		list_del, but has not yet done 'entry->next = LIST_POISON1;'
    [interrupt happens]
    	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
    [interrupt is done, back to dpci_softirq]
    	finishes the entry->next = LIST_POISON1;
    		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
    	ends the loop, exits.

    \- dpci_softirq
    	while (!list_emtpry)
    		list_del, but ->next already has LIST_POISON1 and we blow up.

An alternative solution was proposed (adding STATE_ZOMBIE and making
pt_irq_time_out use the cmpxchg protocol on 'state'), which fixed the above
issue but had an fatal bug. It would miss interrupts that are to be scheduled!

This patch brings back the 'masked' boolean which is used as an
communication channel between 'hvm_do_IRQ_dpci', 'hvm_dirq_assist' and
'pt_irq_guest_eoi'. When we have an interrupt we set 'masked'. Anytime
'hvm_dirq_assist' or 'pt_irq_guest_eoi' executes - it clears it.

The 'state' is left as a seperate mechanism to provide an mechanism between
'raise_sofitrq' and 'softirq_dpci' to communicate the state of the
'struct hvm_dirq_pirq'.

However since we have now two seperate machines we have to deal with an
cancellations and outstanding interrupt being serviced: 'pt_irq_destroy_bind'
is called while an 'hvm_dirq_assist' is just about to service.
The 'pt_irq_destroy_bind' takes the lock first and kills the timer - and
the moment it releases the spinlock, 'hvm_dirq_assist' thunders in and calls
'set_timer' hitting an ASSERT.

By clearing the 'masked' in the 'pt_irq_destroy_bind' we take care of that
scenario by inhibiting 'hvm_dirq_assist' to call the 'set_timer'.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
v2: Deal with 'masked' in pt_irq_destroy_bind.
---
 xen/drivers/passthrough/io.c | 6 ++++--
 xen/include/xen/hvm/irq.h    | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..c5cf7c7 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -142,7 +142,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pirq_dpci->masked = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -539,6 +539,7 @@ int pt_irq_destroy_bind(
          * call to pt_pirq_softirq_reset.
          */
         pt_pirq_softirq_reset(pirq_dpci);
+        pirq_dpci->masked = 0;
 
         pirq_cleanup_check(pirq, d);
     }
@@ -610,6 +611,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
+    pirq_dpci->masked = 1;
     raise_softirq_for(pirq_dpci);
     return 1;
 }
@@ -669,7 +671,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( pirq_dpci->state )
+    if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..3996f1f 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -94,6 +94,7 @@ struct hvm_irq_dpci {
 struct hvm_pirq_dpci {
     uint32_t flags;
     unsigned int state;
+    bool_t masked;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
-- 
1.9.3


--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--lrZ03NoBR/3+SXJZ--


From xen-devel-bounces@lists.xen.org Fri Nov 21 15:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1Xrpv4-0006gE-PC; Fri, 21 Nov 2014 15:14:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrpv3-0006g6-IA
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:14:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9F/4B-09842-4E65F645; Fri, 21 Nov 2014 15:14:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416582883!6422982!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7379 invoked from network); 21 Nov 2014 15:14:44 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:14:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALFEcWO023760
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 15:14:38 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFEbu0011134
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 15:14:37 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFEauv011001; Fri, 21 Nov 2014 15:14:36 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 07:14:36 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id DD07911892F; Fri, 21 Nov 2014 10:14:35 -0500 (EST)
Date: Fri, 21 Nov 2014 10:14:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141121151435.GE2886@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<1346109865.20141121135124@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346109865.20141121135124@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: andrew.cooper3@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 01:51:24PM +0100, Sander Eikelenboom wrote:
> 
> Friday, November 21, 2014, 12:50:16 PM, you wrote:
> 
> > On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
> >>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
> >>struct hvm_pirq_dpci *pirq_dpci)
> >>>      ASSERT(d->arch.hvm_domain.irq.dpci);
> >>>  
> >>>      spin_lock(&d->event_lock);
> >>> -    if ( pirq_dpci->state )
> >>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
> >>>      {
> >>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
> >>>          const struct dev_intx_gsi_link *digl;
> >>
> >>So this now guards solely against the timeout enforced EOI? Why do
> >>you no longer need to guard against cancellation (i.e. why isn't this
> >>looking at both ->state and ->masked)?
> >>
> 
> > The previous state check was superfluous as the dpci_softirq would check for the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).
> 
> > I actually had an cleanup patch that would have removed the 'if (pirq_dpci->state) ' and move the code for Xen 4.6.
> 
> > Anyhow waiting to see if Sander was able to test with this patch.
> 
> >>Jan
> 
> Hi Konrad / Jan,
> 
> I have tested it for 3 hours now, no host crash so far (even after applying some 
> extra stress to the guest).

Yeey! Thank you for being so flexible and willing to test these patches out!
> 
> --
> Sander
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1Xrpv4-0006gE-PC; Fri, 21 Nov 2014 15:14:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrpv3-0006g6-IA
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:14:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9F/4B-09842-4E65F645; Fri, 21 Nov 2014 15:14:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416582883!6422982!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7379 invoked from network); 21 Nov 2014 15:14:44 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:14:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALFEcWO023760
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 15:14:38 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFEbu0011134
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 15:14:37 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFEauv011001; Fri, 21 Nov 2014 15:14:36 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 07:14:36 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id DD07911892F; Fri, 21 Nov 2014 10:14:35 -0500 (EST)
Date: Fri, 21 Nov 2014 10:14:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141121151435.GE2886@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<1346109865.20141121135124@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346109865.20141121135124@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: andrew.cooper3@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 01:51:24PM +0100, Sander Eikelenboom wrote:
> 
> Friday, November 21, 2014, 12:50:16 PM, you wrote:
> 
> > On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
> >>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
> >>struct hvm_pirq_dpci *pirq_dpci)
> >>>      ASSERT(d->arch.hvm_domain.irq.dpci);
> >>>  
> >>>      spin_lock(&d->event_lock);
> >>> -    if ( pirq_dpci->state )
> >>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
> >>>      {
> >>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
> >>>          const struct dev_intx_gsi_link *digl;
> >>
> >>So this now guards solely against the timeout enforced EOI? Why do
> >>you no longer need to guard against cancellation (i.e. why isn't this
> >>looking at both ->state and ->masked)?
> >>
> 
> > The previous state check was superfluous as the dpci_softirq would check for the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).
> 
> > I actually had an cleanup patch that would have removed the 'if (pirq_dpci->state) ' and move the code for Xen 4.6.
> 
> > Anyhow waiting to see if Sander was able to test with this patch.
> 
> >>Jan
> 
> Hi Konrad / Jan,
> 
> I have tested it for 3 hours now, no host crash so far (even after applying some 
> extra stress to the guest).

Yeey! Thank you for being so flexible and willing to test these patches out!
> 
> --
> Sander
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:15:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpvV-0006kf-5x; Fri, 21 Nov 2014 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 <konrad.wilk@oracle.com>) id 1XrpvT-0006kD-UC
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 15:15:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	26/1C-09842-FF65F645; Fri, 21 Nov 2014 15:15:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416582909!12312124!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23415 invoked from network); 21 Nov 2014 15:15:10 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:15:10 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALFF16N000982
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 15:15:02 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFExn4012177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 15:15:01 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALFEwXb015415; Fri, 21 Nov 2014 15:14:59 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 07:14:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8944E118931; Fri, 21 Nov 2014 10:14:57 -0500 (EST)
Date: Fri, 21 Nov 2014 10:14:57 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>, boris.ostrovsky@oracle.com
Message-ID: <20141121151457.GF2886@laptop.dumpdata.com>
References: <546F0F25.4040707@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F0F25.4040707@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] WARNings in guest during xl save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 11:08:37AM +0100, Juergen Gross wrote:
> Hi,
> 
> during tests of my "linear p2m list" patches I stumbled over some
> WARNs issued during xl save and xl restore of a pv-domU with
> unpatched linux 3.18-rc5:

Boris had an patch for this I htink..
> 
> during save I saw multiple entries like:
> [  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968
> clear_local_APIC+0xa5/0x2b0()
> [  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss
> oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev
> x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul
> aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr
> cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
> [  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W
> 3.18.0-rc5 #30
> [  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000
> 00000009 c158bdc2
> [  176.900393]  000003c8 c103c925 c103c925 000003c8 00000002 00000000
> c15d25eb e8867e64
> [  176.900393]  c1054bd9 00000009 00000000 c103c925 00000000 c103cb54
> 00000002 00000000
> [  176.900393] Call Trace:
> [  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
> [  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
> [  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
> [  176.900393]  [<c103cb54>] ? disable_local_APIC+0x24/0x90
> [  176.900393]  [<c103ccde>] ? lapic_suspend+0x11e/0x170
> [  176.900393]  [<c1360ff9>] ? syscore_suspend+0x79/0x220
> [  176.900393]  [<c107e782>] ? set_next_entity+0x62/0x80
> [  176.900393]  [<c13165cd>] ? xen_suspend+0x2d/0x110
> [  176.900393]  [<c10045df>] ? xen_mc_flush+0x13f/0x170
> [  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
> [  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
> [  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
> [  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
> [  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
> [  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
> [  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
> [  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
> [  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
> [  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
> [  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
> [  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
> [  176.900393] ---[ end trace b38596d5cfdcde8d ]---
> 
> and during restore:
> [  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968
> lapic_resume+0xc6/0x270()
> [  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss
> oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev
> x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul
> aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr
> cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
> [  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W
> 3.18.0-rc5 #30
> [  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000
> 00000009 c158bdc2
> [  176.900393]  000003c8 c103c1e6 c103c1e6 000003c8 c1030020 00000002
> 0000001b 00000000
> [  176.900393]  c1054bd9 00000009 00000000 c103c1e6 00000000 c16432c0
> 0108cdfe c15d25dc
> [  176.900393] Call Trace:
> [  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
> [  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
> [  176.900393]  [<c1030020>] ? mcheck_cpu_init+0x170/0x4f0
> [  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
> [  176.900393]  [<c1360e66>] ? syscore_resume+0x46/0x160
> [  176.900393]  [<c1009012>] ? xen_timer_resume+0x42/0x60
> [  176.900393]  [<c131661c>] ? xen_suspend+0x7c/0x110
> [  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
> [  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
> [  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
> [  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
> [  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
> [  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
> [  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
> [  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
> [  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
> [  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
> [  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
> [  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
> [  176.900393] ---[ end trace b38596d5cfdcde93 ]---
> 
> While this seems not to be critical (the system is running after the
> restore) I assume disabling/enabling a local APIC on a pv-domain isn't
> something we want to happen...
> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 21 15:15:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpvV-0006kf-5x; Fri, 21 Nov 2014 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 <konrad.wilk@oracle.com>) id 1XrpvT-0006kD-UC
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 15:15:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	26/1C-09842-FF65F645; Fri, 21 Nov 2014 15:15:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416582909!12312124!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23415 invoked from network); 21 Nov 2014 15:15:10 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:15:10 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALFF16N000982
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 15:15:02 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFExn4012177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 15:15:01 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALFEwXb015415; Fri, 21 Nov 2014 15:14:59 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 07:14:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8944E118931; Fri, 21 Nov 2014 10:14:57 -0500 (EST)
Date: Fri, 21 Nov 2014 10:14:57 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>, boris.ostrovsky@oracle.com
Message-ID: <20141121151457.GF2886@laptop.dumpdata.com>
References: <546F0F25.4040707@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F0F25.4040707@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] WARNings in guest during xl save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 11:08:37AM +0100, Juergen Gross wrote:
> Hi,
> 
> during tests of my "linear p2m list" patches I stumbled over some
> WARNs issued during xl save and xl restore of a pv-domU with
> unpatched linux 3.18-rc5:

Boris had an patch for this I htink..
> 
> during save I saw multiple entries like:
> [  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968
> clear_local_APIC+0xa5/0x2b0()
> [  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss
> oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev
> x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul
> aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr
> cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
> [  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W
> 3.18.0-rc5 #30
> [  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000
> 00000009 c158bdc2
> [  176.900393]  000003c8 c103c925 c103c925 000003c8 00000002 00000000
> c15d25eb e8867e64
> [  176.900393]  c1054bd9 00000009 00000000 c103c925 00000000 c103cb54
> 00000002 00000000
> [  176.900393] Call Trace:
> [  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
> [  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
> [  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
> [  176.900393]  [<c103cb54>] ? disable_local_APIC+0x24/0x90
> [  176.900393]  [<c103ccde>] ? lapic_suspend+0x11e/0x170
> [  176.900393]  [<c1360ff9>] ? syscore_suspend+0x79/0x220
> [  176.900393]  [<c107e782>] ? set_next_entity+0x62/0x80
> [  176.900393]  [<c13165cd>] ? xen_suspend+0x2d/0x110
> [  176.900393]  [<c10045df>] ? xen_mc_flush+0x13f/0x170
> [  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
> [  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
> [  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
> [  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
> [  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
> [  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
> [  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
> [  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
> [  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
> [  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
> [  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
> [  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
> [  176.900393] ---[ end trace b38596d5cfdcde8d ]---
> 
> and during restore:
> [  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968
> lapic_resume+0xc6/0x270()
> [  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss
> oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev
> x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul
> aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr
> cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
> [  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W
> 3.18.0-rc5 #30
> [  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000
> 00000009 c158bdc2
> [  176.900393]  000003c8 c103c1e6 c103c1e6 000003c8 c1030020 00000002
> 0000001b 00000000
> [  176.900393]  c1054bd9 00000009 00000000 c103c1e6 00000000 c16432c0
> 0108cdfe c15d25dc
> [  176.900393] Call Trace:
> [  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
> [  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
> [  176.900393]  [<c1030020>] ? mcheck_cpu_init+0x170/0x4f0
> [  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
> [  176.900393]  [<c1360e66>] ? syscore_resume+0x46/0x160
> [  176.900393]  [<c1009012>] ? xen_timer_resume+0x42/0x60
> [  176.900393]  [<c131661c>] ? xen_suspend+0x7c/0x110
> [  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
> [  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
> [  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
> [  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
> [  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
> [  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
> [  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
> [  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
> [  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
> [  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
> [  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
> [  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
> [  176.900393] ---[ end trace b38596d5cfdcde93 ]---
> 
> While this seems not to be critical (the system is running after the
> restore) I assume disabling/enabling a local APIC on a pv-domain isn't
> something we want to happen...
> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 21 15:17:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:17:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpxY-0006zu-UQ; Fri, 21 Nov 2014 15:17:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrpxW-0006ze-Sr
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:17:18 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	B6/D3-25714-E775F645; Fri, 21 Nov 2014 15:17:18 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416583037!12693844!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27587 invoked from network); 21 Nov 2014 15:17:17 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:17:17 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 66282ABE2
	for <xen-devel@lists.xenproject.org>;
	Fri, 21 Nov 2014 15:17:17 +0000 (UTC)
Message-ID: <546F577C.6080207@suse.com>
Date: Fri, 21 Nov 2014 16:17:16 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546F4E86.8060801@suse.com> <546F60470200007800049D06@suse.com>
In-Reply-To: <546F60470200007800049D06@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 03:54 PM, Jan Beulich wrote:
>>>> On 21.11.14 at 15:39, <JGross@suse.com> wrote:
>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>> wrong device to the domain. The MMIO address was too large for a
>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>
>> Instead of rejecting the operation Xen tried to perform it resulting
>> in a (quite understandable) failure in the domU.
>>
>> I think either the hypervisor or the tools should refuse to do
>> PCI-passthrough in this case.
>
> What's wrong with this large an address? 32-bit PV uses PAE, i.e.
> can map them. If the kernel isn't capable of that that's not
> something to make Xen (or the tools) refuse such assignments. I
> would only see an issue if a hypercall interface involved here isn't
> using wide enough fields (but these addresses should be read
> from the BARs, i.e. no hypercall involved).

The MFN format is part of the pv-ABI. And a MFN of a 32-bit pv-guest is
only 32 bits (even if don't take the invalid bit into account).

Should a pv-guest really be capable to map an address outside it's
accessible MFN-range?

Are the tools capable of processing such a mapping in case of saving the
domain?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:17:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:17:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrpxY-0006zu-UQ; Fri, 21 Nov 2014 15:17:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XrpxW-0006ze-Sr
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:17:18 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	B6/D3-25714-E775F645; Fri, 21 Nov 2014 15:17:18 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416583037!12693844!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27587 invoked from network); 21 Nov 2014 15:17:17 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:17:17 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 66282ABE2
	for <xen-devel@lists.xenproject.org>;
	Fri, 21 Nov 2014 15:17:17 +0000 (UTC)
Message-ID: <546F577C.6080207@suse.com>
Date: Fri, 21 Nov 2014 16:17:16 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546F4E86.8060801@suse.com> <546F60470200007800049D06@suse.com>
In-Reply-To: <546F60470200007800049D06@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 03:54 PM, Jan Beulich wrote:
>>>> On 21.11.14 at 15:39, <JGross@suse.com> wrote:
>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>> wrong device to the domain. The MMIO address was too large for a
>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>
>> Instead of rejecting the operation Xen tried to perform it resulting
>> in a (quite understandable) failure in the domU.
>>
>> I think either the hypervisor or the tools should refuse to do
>> PCI-passthrough in this case.
>
> What's wrong with this large an address? 32-bit PV uses PAE, i.e.
> can map them. If the kernel isn't capable of that that's not
> something to make Xen (or the tools) refuse such assignments. I
> would only see an issue if a hypercall interface involved here isn't
> using wide enough fields (but these addresses should be read
> from the BARs, i.e. no hypercall involved).

The MFN format is part of the pv-ABI. And a MFN of a 32-bit pv-guest is
only 32 bits (even if don't take the invalid bit into account).

Should a pv-guest really be capable to map an address outside it's
accessible MFN-range?

Are the tools capable of processing such a mapping in case of saving the
domain?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:18:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1XrpyK-00075V-Bq; Fri, 21 Nov 2014 15:18:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrpyJ-00075F-Cm
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 15:18:07 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	E3/24-03145-EA75F645; Fri, 21 Nov 2014 15:18:06 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416583084!14043419!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20580 invoked from network); 21 Nov 2014 15:18:05 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:18:05 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALFI32v005342
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 15:18:04 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFI2wh022530
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 15:18:02 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFI1ju025366; Fri, 21 Nov 2014 15:18:01 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 07:18:01 -0800
Message-ID: <546F5851.7050209@oracle.com>
Date: Fri, 21 Nov 2014 10:20:49 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Juergen Gross <jgross@suse.com>
References: <546F0F25.4040707@suse.com>
	<20141121151457.GF2886@laptop.dumpdata.com>
In-Reply-To: <20141121151457.GF2886@laptop.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] WARNings in guest during xl save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 10:14 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 11:08:37AM +0100, Juergen Gross wrote:
>> Hi,
>>
>> during tests of my "linear p2m list" patches I stumbled over some
>> WARNs issued during xl save and xl restore of a pv-domU with
>> unpatched linux 3.18-rc5:
> Boris had an patch for this I htink..


Right, I submitted a patch a while ago to disable APIC power management 
for PV but it didn't get anywhere (needed a response from x86 maintainers)

http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00153.html

Strangely enough, I don't remember seeing this error since then for some 
reason.

-boris


>> during save I saw multiple entries like:
>> [  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968
>> clear_local_APIC+0xa5/0x2b0()
>> [  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss
>> oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev
>> x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul
>> aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr
>> cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
>> [  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W
>> 3.18.0-rc5 #30
>> [  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000
>> 00000009 c158bdc2
>> [  176.900393]  000003c8 c103c925 c103c925 000003c8 00000002 00000000
>> c15d25eb e8867e64
>> [  176.900393]  c1054bd9 00000009 00000000 c103c925 00000000 c103cb54
>> 00000002 00000000
>> [  176.900393] Call Trace:
>> [  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
>> [  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
>> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
>> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
>> [  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
>> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
>> [  176.900393]  [<c103cb54>] ? disable_local_APIC+0x24/0x90
>> [  176.900393]  [<c103ccde>] ? lapic_suspend+0x11e/0x170
>> [  176.900393]  [<c1360ff9>] ? syscore_suspend+0x79/0x220
>> [  176.900393]  [<c107e782>] ? set_next_entity+0x62/0x80
>> [  176.900393]  [<c13165cd>] ? xen_suspend+0x2d/0x110
>> [  176.900393]  [<c10045df>] ? xen_mc_flush+0x13f/0x170
>> [  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
>> [  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
>> [  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
>> [  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
>> [  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
>> [  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
>> [  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
>> [  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
>> [  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
>> [  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
>> [  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
>> [  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
>> [  176.900393] ---[ end trace b38596d5cfdcde8d ]---
>>
>> and during restore:
>> [  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968
>> lapic_resume+0xc6/0x270()
>> [  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss
>> oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev
>> x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul
>> aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr
>> cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
>> [  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W
>> 3.18.0-rc5 #30
>> [  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000
>> 00000009 c158bdc2
>> [  176.900393]  000003c8 c103c1e6 c103c1e6 000003c8 c1030020 00000002
>> 0000001b 00000000
>> [  176.900393]  c1054bd9 00000009 00000000 c103c1e6 00000000 c16432c0
>> 0108cdfe c15d25dc
>> [  176.900393] Call Trace:
>> [  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
>> [  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
>> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
>> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
>> [  176.900393]  [<c1030020>] ? mcheck_cpu_init+0x170/0x4f0
>> [  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
>> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
>> [  176.900393]  [<c1360e66>] ? syscore_resume+0x46/0x160
>> [  176.900393]  [<c1009012>] ? xen_timer_resume+0x42/0x60
>> [  176.900393]  [<c131661c>] ? xen_suspend+0x7c/0x110
>> [  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
>> [  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
>> [  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
>> [  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
>> [  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
>> [  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
>> [  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
>> [  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
>> [  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
>> [  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
>> [  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
>> [  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
>> [  176.900393] ---[ end trace b38596d5cfdcde93 ]---
>>
>> While this seems not to be critical (the system is running after the
>> restore) I assume disabling/enabling a local APIC on a pv-domain isn't
>> something we want to happen...
>>
>>
>> Juergen
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Nov 21 15:18:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1XrpyK-00075V-Bq; Fri, 21 Nov 2014 15:18:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrpyJ-00075F-Cm
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 15:18:07 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	E3/24-03145-EA75F645; Fri, 21 Nov 2014 15:18:06 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416583084!14043419!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20580 invoked from network); 21 Nov 2014 15:18:05 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:18:05 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALFI32v005342
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 15:18:04 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFI2wh022530
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 15:18:02 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALFI1ju025366; Fri, 21 Nov 2014 15:18:01 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 07:18:01 -0800
Message-ID: <546F5851.7050209@oracle.com>
Date: Fri, 21 Nov 2014 10:20:49 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Juergen Gross <jgross@suse.com>
References: <546F0F25.4040707@suse.com>
	<20141121151457.GF2886@laptop.dumpdata.com>
In-Reply-To: <20141121151457.GF2886@laptop.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] WARNings in guest during xl save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 10:14 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 11:08:37AM +0100, Juergen Gross wrote:
>> Hi,
>>
>> during tests of my "linear p2m list" patches I stumbled over some
>> WARNs issued during xl save and xl restore of a pv-domU with
>> unpatched linux 3.18-rc5:
> Boris had an patch for this I htink..


Right, I submitted a patch a while ago to disable APIC power management 
for PV but it didn't get anywhere (needed a response from x86 maintainers)

http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00153.html

Strangely enough, I don't remember seeing this error since then for some 
reason.

-boris


>> during save I saw multiple entries like:
>> [  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968
>> clear_local_APIC+0xa5/0x2b0()
>> [  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss
>> oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev
>> x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul
>> aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr
>> cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
>> [  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W
>> 3.18.0-rc5 #30
>> [  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000
>> 00000009 c158bdc2
>> [  176.900393]  000003c8 c103c925 c103c925 000003c8 00000002 00000000
>> c15d25eb e8867e64
>> [  176.900393]  c1054bd9 00000009 00000000 c103c925 00000000 c103cb54
>> 00000002 00000000
>> [  176.900393] Call Trace:
>> [  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
>> [  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
>> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
>> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
>> [  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
>> [  176.900393]  [<c103c925>] ? clear_local_APIC+0xa5/0x2b0
>> [  176.900393]  [<c103cb54>] ? disable_local_APIC+0x24/0x90
>> [  176.900393]  [<c103ccde>] ? lapic_suspend+0x11e/0x170
>> [  176.900393]  [<c1360ff9>] ? syscore_suspend+0x79/0x220
>> [  176.900393]  [<c107e782>] ? set_next_entity+0x62/0x80
>> [  176.900393]  [<c13165cd>] ? xen_suspend+0x2d/0x110
>> [  176.900393]  [<c10045df>] ? xen_mc_flush+0x13f/0x170
>> [  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
>> [  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
>> [  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
>> [  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
>> [  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
>> [  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
>> [  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
>> [  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
>> [  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
>> [  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
>> [  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
>> [  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
>> [  176.900393] ---[ end trace b38596d5cfdcde8d ]---
>>
>> and during restore:
>> [  176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968
>> lapic_resume+0xc6/0x270()
>> [  176.900393] Modules linked in: cfg80211 rfkill nfsd auth_rpcgss
>> oid_registry nfs_acl nfs lockd grace fscache sunrpc evdev
>> x86_pkg_temp_thermal thermal_sys snd_pcm coretemp snd_timer crc32_pclmul
>> aesni_intel snd xts soundcore aes_i586 lrw gf128mul ablk_helper pcspkr
>> cryptd fuse autofs4 ext4 crc16 mbcache jbd2 crc32c_intel
>> [  176.900393] CPU: 0 PID: 9 Comm: migration/0 Tainted: G        W
>> 3.18.0-rc5 #30
>> [  176.900393]  00000009 c14c40b2 00000000 c1054b10 c1599538 00000000
>> 00000009 c158bdc2
>> [  176.900393]  000003c8 c103c1e6 c103c1e6 000003c8 c1030020 00000002
>> 0000001b 00000000
>> [  176.900393]  c1054bd9 00000009 00000000 c103c1e6 00000000 c16432c0
>> 0108cdfe c15d25dc
>> [  176.900393] Call Trace:
>> [  176.900393]  [<c14c40b2>] ? dump_stack+0x3e/0x4e
>> [  176.900393]  [<c1054b10>] ? warn_slowpath_common+0x90/0xc0
>> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
>> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
>> [  176.900393]  [<c1030020>] ? mcheck_cpu_init+0x170/0x4f0
>> [  176.900393]  [<c1054bd9>] ? warn_slowpath_null+0x19/0x20
>> [  176.900393]  [<c103c1e6>] ? lapic_resume+0xc6/0x270
>> [  176.900393]  [<c1360e66>] ? syscore_resume+0x46/0x160
>> [  176.900393]  [<c1009012>] ? xen_timer_resume+0x42/0x60
>> [  176.900393]  [<c131661c>] ? xen_suspend+0x7c/0x110
>> [  176.900393]  [<c10d5619>] ? multi_cpu_stop+0xa9/0xd0
>> [  176.900393]  [<c10d5570>] ? cpu_stop_should_run+0x50/0x50
>> [  176.900393]  [<c10d5771>] ? cpu_stopper_thread+0x71/0x100
>> [  176.900393]  [<c1074214>] ? finish_task_switch+0x34/0xd0
>> [  176.900393]  [<c14c513d>] ? __schedule+0x23d/0x7f0
>> [  176.900393]  [<c10897f4>] ? __wake_up_common+0x44/0x70
>> [  176.900393]  [<c14c8962>] ? _raw_spin_lock_irqsave+0x12/0x60
>> [  176.900393]  [<c1071f22>] ? smpboot_thread_fn+0xd2/0x170
>> [  176.900393]  [<c1071e50>] ? SyS_setgroups+0x110/0x110
>> [  176.900393]  [<c106e801>] ? kthread+0xa1/0xc0
>> [  176.900393]  [<c14c8ea1>] ? ret_from_kernel_thread+0x21/0x30
>> [  176.900393]  [<c106e760>] ? kthread_create_on_node+0x120/0x120
>> [  176.900393] ---[ end trace b38596d5cfdcde93 ]---
>>
>> While this seems not to be critical (the system is running after the
>> restore) I assume disabling/enabling a local APIC on a pv-domain isn't
>> something we want to happen...
>>
>>
>> Juergen
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Nov 21 15:19:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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.xen.org>)
	id 1XrpzN-0007CI-QM; Fri, 21 Nov 2014 15:19:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XrpzM-0007C6-TD
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:19:13 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	1E/35-25547-0F75F645; Fri, 21 Nov 2014 15:19:12 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416583149!12980370!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24382 invoked from network); 21 Nov 2014 15:19:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:19:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195274027"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:18:23 -0500
Received: from perard.uk.xensource.com ([10.80.2.84])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1XrpyZ-0005KO-Db;
	Fri, 21 Nov 2014 15:18:23 +0000
Date: Fri, 21 Nov 2014 15:18:23 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141121151823.GE1617@perard.uk.xensource.com>
References: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141117094117.GF11070@zion.uk.xensource.com>
	<1416220159.27385.20.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416220159.27385.20.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Chao Peng <chao.p.peng@linux.intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: avoid bringing up vcpus already
	online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 10:29:19AM +0000, Ian Campbell wrote:
> On Mon, 2014-11-17 at 09:41 +0000, Wei Liu wrote:
> > On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
> > > Avoid sending duplicated qmp commands and eliminate the confusing error
> > > messages like "Unable to add CPU: 0, it already exists".
> > > 
> > > Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> > > ---
> > >  tools/libxl/libxl.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > index f7961f6..d040e5c 100644
> > > --- a/tools/libxl/libxl.c
> > > +++ b/tools/libxl/libxl.c
> > > @@ -5450,7 +5450,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid,
> > >          LOGE(ERROR, "getting domain info list");
> > >          return ERROR_FAIL;
> > >      }
> > > -    for (i = 0; i <= info.vcpu_max_id; i++) {
> > > +    for (i = info.vcpu_online; i <= info.vcpu_max_id; i++) {
> > 
> > I don't think this is right. You're making an assumption that vcpu 0 to
> > vcpu "info.vcpu_online" are online, which might not be true in hotplug /
> > hot-unplug scenario.
> 
> Indeed. Adding Anthony for his input.

It's probably not a good "fix" to avoid the error message. As Wei said,
vcpu 0 to vcpu ${info.vcpu_online} might not all be online.

At the time I've written this function, there were no way to query QEMU
to know which CPU are online. So the only way was to send the QMP
command anyway and get an error back. Unfortunately, the error that QEMU
send back is not suppose to be parsed (as it's only for human to read
and might change in the futur) and libxl_qmp is not ready to handle this
kind of error in a better way, so it just print them.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:19:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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.xen.org>)
	id 1XrpzN-0007CI-QM; Fri, 21 Nov 2014 15:19:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XrpzM-0007C6-TD
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:19:13 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	1E/35-25547-0F75F645; Fri, 21 Nov 2014 15:19:12 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416583149!12980370!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24382 invoked from network); 21 Nov 2014 15:19:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:19:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195274027"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:18:23 -0500
Received: from perard.uk.xensource.com ([10.80.2.84])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1XrpyZ-0005KO-Db;
	Fri, 21 Nov 2014 15:18:23 +0000
Date: Fri, 21 Nov 2014 15:18:23 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141121151823.GE1617@perard.uk.xensource.com>
References: <1416216538-15926-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141117094117.GF11070@zion.uk.xensource.com>
	<1416220159.27385.20.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416220159.27385.20.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Chao Peng <chao.p.peng@linux.intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: avoid bringing up vcpus already
	online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 17, 2014 at 10:29:19AM +0000, Ian Campbell wrote:
> On Mon, 2014-11-17 at 09:41 +0000, Wei Liu wrote:
> > On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
> > > Avoid sending duplicated qmp commands and eliminate the confusing error
> > > messages like "Unable to add CPU: 0, it already exists".
> > > 
> > > Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> > > ---
> > >  tools/libxl/libxl.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > index f7961f6..d040e5c 100644
> > > --- a/tools/libxl/libxl.c
> > > +++ b/tools/libxl/libxl.c
> > > @@ -5450,7 +5450,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid,
> > >          LOGE(ERROR, "getting domain info list");
> > >          return ERROR_FAIL;
> > >      }
> > > -    for (i = 0; i <= info.vcpu_max_id; i++) {
> > > +    for (i = info.vcpu_online; i <= info.vcpu_max_id; i++) {
> > 
> > I don't think this is right. You're making an assumption that vcpu 0 to
> > vcpu "info.vcpu_online" are online, which might not be true in hotplug /
> > hot-unplug scenario.
> 
> Indeed. Adding Anthony for his input.

It's probably not a good "fix" to avoid the error message. As Wei said,
vcpu 0 to vcpu ${info.vcpu_online} might not all be online.

At the time I've written this function, there were no way to query QEMU
to know which CPU are online. So the only way was to send the QMP
command anyway and get an error back. Unfortunately, the error that QEMU
send back is not suppose to be parsed (as it's only for human to read
and might change in the futur) and libxl_qmp is not ready to handle this
kind of error in a better way, so it just print them.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:26:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq5t-0007iE-Mz; Fri, 21 Nov 2014 15:25:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrq5r-0007i9-Qs
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:25:55 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	A8/BD-02699-3895F645; Fri, 21 Nov 2014 15:25:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416583552!8620417!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9722 invoked from network); 21 Nov 2014 15:25:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:25:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195277116"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:25:43 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-O7;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:52 +0000
Message-ID: <1416582421-10789-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 10/19] libxl: build,
	check and pass vNUMA info to Xen 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_dom.c |   71 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..7339bbc 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -512,6 +512,51 @@ retry_transaction:
     return 0;
 }
 
+static int set_vnuma_info(libxl__gc *gc, uint32_t domid,
+                          const libxl_domain_build_info *info,
+                          const libxl__domain_build_state *state)
+{
+    int rc = 0;
+    int i, nr_vdistance;
+    unsigned int *vcpu_to_vnode, *vnode_to_pnode, *vdistance = NULL;
+
+    vcpu_to_vnode = libxl__calloc(gc, info->max_vcpus,
+                                  sizeof(unsigned int));
+    vnode_to_pnode = libxl__calloc(gc, info->num_vnuma_nodes,
+                                   sizeof(unsigned int));
+
+    nr_vdistance = info->num_vnuma_nodes * info->num_vnuma_nodes;
+    vdistance = libxl__calloc(gc, nr_vdistance, sizeof(unsigned int));
+
+    for (i = 0; i < info->num_vnuma_nodes; i++) {
+        libxl_vnode_info *v = &info->vnuma_nodes[i];
+        int bit;
+
+        /* vnode to pnode mapping */
+        vnode_to_pnode[i] = v->pnode;
+
+        /* vcpu to vnode mapping */
+        libxl_for_each_set_bit(bit, v->vcpus)
+            vcpu_to_vnode[bit] = i;
+
+        /* node distances */
+        assert(info->num_vnuma_nodes == v->num_distances);
+        memcpy(vdistance + (i * info->num_vnuma_nodes),
+               v->distances,
+               v->num_distances * sizeof(unsigned int));
+    }
+
+    if ( xc_domain_setvnuma(CTX->xch, domid, info->num_vnuma_nodes,
+                            state->num_vmemranges, info->max_vcpus,
+                            state->vmemranges, vdistance,
+                            vcpu_to_vnode, vnode_to_pnode) < 0 ) {
+        LOGE(ERROR, "xc_domain_setvnuma failed");
+        rc = ERROR_FAIL;
+    }
+
+    return rc;
+}
+
 int libxl__build_pv(libxl__gc *gc, uint32_t domid,
              libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
@@ -569,6 +614,32 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
     dom->xenstore_domid = state->store_domid;
     dom->claim_enabled = libxl_defbool_val(info->claim_mode);
 
+    if (info->num_vnuma_nodes != 0) {
+        int i;
+
+        ret = libxl__vnuma_build_vmemrange_pv(gc, domid, info, state);
+        if (ret) {
+            LOGE(ERROR, "cannot build vmemranges");
+            goto out;
+        }
+        ret = libxl__vnuma_config_check(gc, info, state);
+        if (ret) goto out;
+
+        ret = set_vnuma_info(gc, domid, info, state);
+        if (ret) goto out;
+
+        dom->nr_vnodes = info->num_vnuma_nodes;
+        dom->vnode_to_pnode = xc_dom_malloc(dom, sizeof(*dom->vnode_to_pnode) *
+                                            dom->nr_vnodes);
+        dom->vnode_size = xc_dom_malloc(dom, sizeof(*dom->vnode_size) *
+                                        dom->nr_vnodes);
+
+        for (i = 0; i < dom->nr_vnodes; i++) {
+            dom->vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
+            dom->vnode_size[i] = info->vnuma_nodes[i].mem;
+        }
+    }
+
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LOGE(ERROR, "xc_dom_boot_xen_init failed");
         goto out;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:26:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq5t-0007iE-Mz; Fri, 21 Nov 2014 15:25:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrq5r-0007i9-Qs
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:25:55 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	A8/BD-02699-3895F645; Fri, 21 Nov 2014 15:25:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416583552!8620417!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9722 invoked from network); 21 Nov 2014 15:25:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:25:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195277116"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:25:43 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-O7;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:52 +0000
Message-ID: <1416582421-10789-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 10/19] libxl: build,
	check and pass vNUMA info to Xen 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_dom.c |   71 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..7339bbc 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -512,6 +512,51 @@ retry_transaction:
     return 0;
 }
 
+static int set_vnuma_info(libxl__gc *gc, uint32_t domid,
+                          const libxl_domain_build_info *info,
+                          const libxl__domain_build_state *state)
+{
+    int rc = 0;
+    int i, nr_vdistance;
+    unsigned int *vcpu_to_vnode, *vnode_to_pnode, *vdistance = NULL;
+
+    vcpu_to_vnode = libxl__calloc(gc, info->max_vcpus,
+                                  sizeof(unsigned int));
+    vnode_to_pnode = libxl__calloc(gc, info->num_vnuma_nodes,
+                                   sizeof(unsigned int));
+
+    nr_vdistance = info->num_vnuma_nodes * info->num_vnuma_nodes;
+    vdistance = libxl__calloc(gc, nr_vdistance, sizeof(unsigned int));
+
+    for (i = 0; i < info->num_vnuma_nodes; i++) {
+        libxl_vnode_info *v = &info->vnuma_nodes[i];
+        int bit;
+
+        /* vnode to pnode mapping */
+        vnode_to_pnode[i] = v->pnode;
+
+        /* vcpu to vnode mapping */
+        libxl_for_each_set_bit(bit, v->vcpus)
+            vcpu_to_vnode[bit] = i;
+
+        /* node distances */
+        assert(info->num_vnuma_nodes == v->num_distances);
+        memcpy(vdistance + (i * info->num_vnuma_nodes),
+               v->distances,
+               v->num_distances * sizeof(unsigned int));
+    }
+
+    if ( xc_domain_setvnuma(CTX->xch, domid, info->num_vnuma_nodes,
+                            state->num_vmemranges, info->max_vcpus,
+                            state->vmemranges, vdistance,
+                            vcpu_to_vnode, vnode_to_pnode) < 0 ) {
+        LOGE(ERROR, "xc_domain_setvnuma failed");
+        rc = ERROR_FAIL;
+    }
+
+    return rc;
+}
+
 int libxl__build_pv(libxl__gc *gc, uint32_t domid,
              libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
@@ -569,6 +614,32 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
     dom->xenstore_domid = state->store_domid;
     dom->claim_enabled = libxl_defbool_val(info->claim_mode);
 
+    if (info->num_vnuma_nodes != 0) {
+        int i;
+
+        ret = libxl__vnuma_build_vmemrange_pv(gc, domid, info, state);
+        if (ret) {
+            LOGE(ERROR, "cannot build vmemranges");
+            goto out;
+        }
+        ret = libxl__vnuma_config_check(gc, info, state);
+        if (ret) goto out;
+
+        ret = set_vnuma_info(gc, domid, info, state);
+        if (ret) goto out;
+
+        dom->nr_vnodes = info->num_vnuma_nodes;
+        dom->vnode_to_pnode = xc_dom_malloc(dom, sizeof(*dom->vnode_to_pnode) *
+                                            dom->nr_vnodes);
+        dom->vnode_size = xc_dom_malloc(dom, sizeof(*dom->vnode_size) *
+                                        dom->nr_vnodes);
+
+        for (i = 0; i < dom->nr_vnodes; i++) {
+            dom->vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
+            dom->vnode_size[i] = info->vnuma_nodes[i].mem;
+        }
+    }
+
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LOGE(ERROR, "xc_dom_boot_xen_init failed");
         goto out;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:26:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:26:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq6J-0007kO-3x; Fri, 21 Nov 2014 15:26:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrq6I-0007kH-Ca
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:26:22 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	7B/E0-03148-D995F645; Fri, 21 Nov 2014 15:26:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416583577!14045435!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25451 invoked from network); 21 Nov 2014 15:26:18 -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;
	21 Nov 2014 15:26:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193742939"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:26:14 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Uk;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:57 +0000
Message-ID: <1416582421-10789-16-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 15/19] libxc: allocate memory with vNUMA
	information for HVM guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And then returns low memory end, high memory end and mmio start to
caller.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxc/include/xenguest.h |    7 ++
 tools/libxc/xc_hvm_build_x86.c |  224 ++++++++++++++++++++++++++--------------
 2 files changed, 151 insertions(+), 80 deletions(-)

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 40bbac8..dca0375 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -230,6 +230,13 @@ struct xc_hvm_build_args {
     struct xc_hvm_firmware_module smbios_module;
     /* Whether to use claim hypercall (1 - enable, 0 - disable). */
     int claim_enabled;
+    unsigned int nr_vnodes;
+    unsigned int *vnode_to_pnode;
+    uint64_t *vnode_size;;
+    /* Out parameters  */
+    uint64_t lowmem_end;
+    uint64_t highmem_end;
+    uint64_t mmio_start;
 };
 
 /**
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..54d3dc8 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -89,7 +89,8 @@ static int modules_init(struct xc_hvm_build_args *args,
 }
 
 static void build_hvm_info(void *hvm_info_page, uint64_t mem_size,
-                           uint64_t mmio_start, uint64_t mmio_size)
+                           uint64_t mmio_start, uint64_t mmio_size,
+                           struct xc_hvm_build_args *args)
 {
     struct hvm_info_table *hvm_info = (struct hvm_info_table *)
         (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
@@ -119,6 +120,10 @@ static void build_hvm_info(void *hvm_info_page, uint64_t mem_size,
     hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
     hvm_info->reserved_mem_pgstart = ioreq_server_pfn(0);
 
+    args->lowmem_end = lowmem_end;
+    args->highmem_end = highmem_end;
+    args->mmio_start = mmio_start;
+
     /* Finish with the checksum. */
     for ( i = 0, sum = 0; i < hvm_info->length; i++ )
         sum += ((uint8_t *)hvm_info)[i];
@@ -244,7 +249,7 @@ static int setup_guest(xc_interface *xch,
                        char *image, unsigned long image_size)
 {
     xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = args->mem_size >> PAGE_SHIFT;
+    unsigned long i, j, 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;
@@ -258,13 +263,13 @@ static int setup_guest(xc_interface *xch,
     xen_capabilities_info_t caps;
     unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
         stat_1gb_pages = 0;
-    int pod_mode = 0;
+    unsigned int memflags = 0;
     int claim_enabled = args->claim_enabled;
     xen_pfn_t special_array[NR_SPECIAL_PAGES];
     xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
-
-    if ( nr_pages > target_pages )
-        pod_mode = XENMEMF_populate_on_demand;
+    uint64_t dummy_vnode_size;
+    unsigned int dummy_vnode_to_pnode;
+    uint64_t total;
 
     memset(&elf, 0, sizeof(elf));
     if ( elf_init(&elf, image, image_size) != 0 )
@@ -276,6 +281,37 @@ static int setup_guest(xc_interface *xch,
     v_start = 0;
     v_end = args->mem_size;
 
+    if ( nr_pages > target_pages )
+        memflags |= XENMEMF_populate_on_demand;
+
+    if ( args->nr_vnodes == 0 )
+    {
+        /* Build dummy vnode information */
+        args->nr_vnodes = 1;
+        dummy_vnode_to_pnode = XC_VNUMA_NO_NODE;
+        dummy_vnode_size = args->mem_size >> 20;
+        args->vnode_size = &dummy_vnode_size;
+        args->vnode_to_pnode = &dummy_vnode_to_pnode;
+    }
+    else
+    {
+        if ( nr_pages > target_pages )
+        {
+            PERROR("Cannot enable vNUMA and PoD at the same time");
+            goto error_out;
+        }
+    }
+
+    total = 0;
+    for ( i = 0; i < args->nr_vnodes; i++ )
+        total += (args->vnode_size[i] << 20);
+    if ( total != args->mem_size )
+    {
+        PERROR("Memory size requested by vNUMA (0x%"PRIx64") mismatches memory size configured for domain (0x%"PRIx64")",
+               total, args->mem_size);
+        goto error_out;
+    }
+
     if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
     {
         PERROR("Could not get Xen capabilities");
@@ -320,7 +356,7 @@ static int setup_guest(xc_interface *xch,
         }
     }
 
-    if ( pod_mode )
+    if ( memflags & XENMEMF_populate_on_demand )
     {
         /*
          * Subtract VGA_HOLE_SIZE from target_pages for the VGA
@@ -349,103 +385,128 @@ static int setup_guest(xc_interface *xch,
      * ensure that we can be preempted and hence dom0 remains responsive.
      */
     rc = xc_domain_populate_physmap_exact(
-        xch, dom, 0xa0, 0, pod_mode, &page_array[0x00]);
+        xch, dom, 0xa0, 0, memflags, &page_array[0x00]);
     cur_pages = 0xc0;
     stat_normal_pages = 0xc0;
 
-    while ( (rc == 0) && (nr_pages > cur_pages) )
+    for ( i = 0; i < args->nr_vnodes; i++ )
     {
-        /* 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];
+        unsigned int new_memflags = memflags;
+        uint64_t pages, finished;
 
-        /* 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,
-                              mmio_start, mmio_size) )
+        if ( args->vnode_to_pnode[i] != XC_VNUMA_NO_NODE )
         {
-            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, sp_extents);
-
-            if ( done > 0 )
-            {
-                stat_1gb_pages += done;
-                done <<= SUPERPAGE_1GB_SHIFT;
-                cur_pages += done;
-                count -= done;
-            }
+            new_memflags |= XENMEMF_exact_node(args->vnode_to_pnode[i]);
+            new_memflags |= XENMEMF_exact_node_request;
         }
 
-        if ( count != 0 )
+        pages = (args->vnode_size[i] << 20) >> PAGE_SHIFT;
+        /* Consider vga hole belongs to node 0 */
+        if ( i == 0 )
+            finished = 0xc0;
+        else
+            finished = 0;
+
+        while ( (rc == 0) && (pages > finished) )
         {
-            /* Clip count to maximum 8MB extent. */
-            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
+            /* Clip count to maximum 1GB extent. */
+            unsigned long count = pages - finished;
+            unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
+
             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 )
+
+            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,
+                                  mmio_start, mmio_size) )
             {
                 long done;
-                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
+                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_2MB_SHIFT)];
+                for ( j = 0; j < nr_extents; j++ )
+                    sp_extents[j] = page_array[cur_pages+(j<<SUPERPAGE_1GB_SHIFT)];
 
-                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
-                                                  pod_mode, sp_extents);
+                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
+                                                  new_memflags, sp_extents);
 
                 if ( done > 0 )
                 {
-                    stat_2mb_pages += done;
-                    done <<= SUPERPAGE_2MB_SHIFT;
+                    stat_1gb_pages += done;
+                    done <<= SUPERPAGE_1GB_SHIFT;
                     cur_pages += done;
+                    finished += done;
                     count -= done;
                 }
             }
-        }
 
-        /* Fall back to 4kB extents. */
-        if ( count != 0 )
-        {
-            rc = xc_domain_populate_physmap_exact(
-                xch, dom, count, 0, pod_mode, &page_array[cur_pages]);
-            cur_pages += count;
-            stat_normal_pages += count;
+            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 ( j = 0; j < nr_extents; j++ )
+                        sp_extents[j] = page_array[cur_pages+(j<<SUPERPAGE_2MB_SHIFT)];
+
+                    done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
+                                                      new_memflags, sp_extents);
+
+                    if ( done > 0 )
+                    {
+                        stat_2mb_pages += done;
+                        done <<= SUPERPAGE_2MB_SHIFT;
+                        cur_pages += done;
+                        finished += done;
+                        count -= done;
+                    }
+                }
+            }
+
+            /* Fall back to 4kB extents. */
+            if ( count != 0 )
+            {
+                rc = xc_domain_populate_physmap_exact(
+                    xch, dom, count, 0, new_memflags, &page_array[cur_pages]);
+                cur_pages += count;
+                finished += count;
+                stat_normal_pages += count;
+            }
         }
+
+        if ( rc != 0 )
+            break;
     }
 
     if ( rc != 0 )
@@ -469,7 +530,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, mmio_start, mmio_size);
+    build_hvm_info(hvm_info_page, v_end, mmio_start, mmio_size, args);
     munmap(hvm_info_page, PAGE_SIZE);
 
     /* Allocate and clear special pages. */
@@ -608,6 +669,9 @@ int xc_hvm_build(xc_interface *xch, uint32_t domid,
             args.acpi_module.guest_addr_out;
         hvm_args->smbios_module.guest_addr_out = 
             args.smbios_module.guest_addr_out;
+        hvm_args->lowmem_end = args.lowmem_end;
+        hvm_args->highmem_end = args.highmem_end;
+        hvm_args->mmio_start = args.mmio_start;
     }
 
     free(image);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:26:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:26:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq6J-0007kO-3x; Fri, 21 Nov 2014 15:26:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrq6I-0007kH-Ca
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:26:22 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	7B/E0-03148-D995F645; Fri, 21 Nov 2014 15:26:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416583577!14045435!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25451 invoked from network); 21 Nov 2014 15:26:18 -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;
	21 Nov 2014 15:26:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193742939"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:26:14 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Uk;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:57 +0000
Message-ID: <1416582421-10789-16-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 15/19] libxc: allocate memory with vNUMA
	information for HVM guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And then returns low memory end, high memory end and mmio start to
caller.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxc/include/xenguest.h |    7 ++
 tools/libxc/xc_hvm_build_x86.c |  224 ++++++++++++++++++++++++++--------------
 2 files changed, 151 insertions(+), 80 deletions(-)

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 40bbac8..dca0375 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -230,6 +230,13 @@ struct xc_hvm_build_args {
     struct xc_hvm_firmware_module smbios_module;
     /* Whether to use claim hypercall (1 - enable, 0 - disable). */
     int claim_enabled;
+    unsigned int nr_vnodes;
+    unsigned int *vnode_to_pnode;
+    uint64_t *vnode_size;;
+    /* Out parameters  */
+    uint64_t lowmem_end;
+    uint64_t highmem_end;
+    uint64_t mmio_start;
 };
 
 /**
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..54d3dc8 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -89,7 +89,8 @@ static int modules_init(struct xc_hvm_build_args *args,
 }
 
 static void build_hvm_info(void *hvm_info_page, uint64_t mem_size,
-                           uint64_t mmio_start, uint64_t mmio_size)
+                           uint64_t mmio_start, uint64_t mmio_size,
+                           struct xc_hvm_build_args *args)
 {
     struct hvm_info_table *hvm_info = (struct hvm_info_table *)
         (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
@@ -119,6 +120,10 @@ static void build_hvm_info(void *hvm_info_page, uint64_t mem_size,
     hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
     hvm_info->reserved_mem_pgstart = ioreq_server_pfn(0);
 
+    args->lowmem_end = lowmem_end;
+    args->highmem_end = highmem_end;
+    args->mmio_start = mmio_start;
+
     /* Finish with the checksum. */
     for ( i = 0, sum = 0; i < hvm_info->length; i++ )
         sum += ((uint8_t *)hvm_info)[i];
@@ -244,7 +249,7 @@ static int setup_guest(xc_interface *xch,
                        char *image, unsigned long image_size)
 {
     xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = args->mem_size >> PAGE_SHIFT;
+    unsigned long i, j, 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;
@@ -258,13 +263,13 @@ static int setup_guest(xc_interface *xch,
     xen_capabilities_info_t caps;
     unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
         stat_1gb_pages = 0;
-    int pod_mode = 0;
+    unsigned int memflags = 0;
     int claim_enabled = args->claim_enabled;
     xen_pfn_t special_array[NR_SPECIAL_PAGES];
     xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
-
-    if ( nr_pages > target_pages )
-        pod_mode = XENMEMF_populate_on_demand;
+    uint64_t dummy_vnode_size;
+    unsigned int dummy_vnode_to_pnode;
+    uint64_t total;
 
     memset(&elf, 0, sizeof(elf));
     if ( elf_init(&elf, image, image_size) != 0 )
@@ -276,6 +281,37 @@ static int setup_guest(xc_interface *xch,
     v_start = 0;
     v_end = args->mem_size;
 
+    if ( nr_pages > target_pages )
+        memflags |= XENMEMF_populate_on_demand;
+
+    if ( args->nr_vnodes == 0 )
+    {
+        /* Build dummy vnode information */
+        args->nr_vnodes = 1;
+        dummy_vnode_to_pnode = XC_VNUMA_NO_NODE;
+        dummy_vnode_size = args->mem_size >> 20;
+        args->vnode_size = &dummy_vnode_size;
+        args->vnode_to_pnode = &dummy_vnode_to_pnode;
+    }
+    else
+    {
+        if ( nr_pages > target_pages )
+        {
+            PERROR("Cannot enable vNUMA and PoD at the same time");
+            goto error_out;
+        }
+    }
+
+    total = 0;
+    for ( i = 0; i < args->nr_vnodes; i++ )
+        total += (args->vnode_size[i] << 20);
+    if ( total != args->mem_size )
+    {
+        PERROR("Memory size requested by vNUMA (0x%"PRIx64") mismatches memory size configured for domain (0x%"PRIx64")",
+               total, args->mem_size);
+        goto error_out;
+    }
+
     if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
     {
         PERROR("Could not get Xen capabilities");
@@ -320,7 +356,7 @@ static int setup_guest(xc_interface *xch,
         }
     }
 
-    if ( pod_mode )
+    if ( memflags & XENMEMF_populate_on_demand )
     {
         /*
          * Subtract VGA_HOLE_SIZE from target_pages for the VGA
@@ -349,103 +385,128 @@ static int setup_guest(xc_interface *xch,
      * ensure that we can be preempted and hence dom0 remains responsive.
      */
     rc = xc_domain_populate_physmap_exact(
-        xch, dom, 0xa0, 0, pod_mode, &page_array[0x00]);
+        xch, dom, 0xa0, 0, memflags, &page_array[0x00]);
     cur_pages = 0xc0;
     stat_normal_pages = 0xc0;
 
-    while ( (rc == 0) && (nr_pages > cur_pages) )
+    for ( i = 0; i < args->nr_vnodes; i++ )
     {
-        /* 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];
+        unsigned int new_memflags = memflags;
+        uint64_t pages, finished;
 
-        /* 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,
-                              mmio_start, mmio_size) )
+        if ( args->vnode_to_pnode[i] != XC_VNUMA_NO_NODE )
         {
-            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, sp_extents);
-
-            if ( done > 0 )
-            {
-                stat_1gb_pages += done;
-                done <<= SUPERPAGE_1GB_SHIFT;
-                cur_pages += done;
-                count -= done;
-            }
+            new_memflags |= XENMEMF_exact_node(args->vnode_to_pnode[i]);
+            new_memflags |= XENMEMF_exact_node_request;
         }
 
-        if ( count != 0 )
+        pages = (args->vnode_size[i] << 20) >> PAGE_SHIFT;
+        /* Consider vga hole belongs to node 0 */
+        if ( i == 0 )
+            finished = 0xc0;
+        else
+            finished = 0;
+
+        while ( (rc == 0) && (pages > finished) )
         {
-            /* Clip count to maximum 8MB extent. */
-            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
+            /* Clip count to maximum 1GB extent. */
+            unsigned long count = pages - finished;
+            unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
+
             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 )
+
+            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,
+                                  mmio_start, mmio_size) )
             {
                 long done;
-                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
+                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_2MB_SHIFT)];
+                for ( j = 0; j < nr_extents; j++ )
+                    sp_extents[j] = page_array[cur_pages+(j<<SUPERPAGE_1GB_SHIFT)];
 
-                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
-                                                  pod_mode, sp_extents);
+                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
+                                                  new_memflags, sp_extents);
 
                 if ( done > 0 )
                 {
-                    stat_2mb_pages += done;
-                    done <<= SUPERPAGE_2MB_SHIFT;
+                    stat_1gb_pages += done;
+                    done <<= SUPERPAGE_1GB_SHIFT;
                     cur_pages += done;
+                    finished += done;
                     count -= done;
                 }
             }
-        }
 
-        /* Fall back to 4kB extents. */
-        if ( count != 0 )
-        {
-            rc = xc_domain_populate_physmap_exact(
-                xch, dom, count, 0, pod_mode, &page_array[cur_pages]);
-            cur_pages += count;
-            stat_normal_pages += count;
+            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 ( j = 0; j < nr_extents; j++ )
+                        sp_extents[j] = page_array[cur_pages+(j<<SUPERPAGE_2MB_SHIFT)];
+
+                    done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
+                                                      new_memflags, sp_extents);
+
+                    if ( done > 0 )
+                    {
+                        stat_2mb_pages += done;
+                        done <<= SUPERPAGE_2MB_SHIFT;
+                        cur_pages += done;
+                        finished += done;
+                        count -= done;
+                    }
+                }
+            }
+
+            /* Fall back to 4kB extents. */
+            if ( count != 0 )
+            {
+                rc = xc_domain_populate_physmap_exact(
+                    xch, dom, count, 0, new_memflags, &page_array[cur_pages]);
+                cur_pages += count;
+                finished += count;
+                stat_normal_pages += count;
+            }
         }
+
+        if ( rc != 0 )
+            break;
     }
 
     if ( rc != 0 )
@@ -469,7 +530,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, mmio_start, mmio_size);
+    build_hvm_info(hvm_info_page, v_end, mmio_start, mmio_size, args);
     munmap(hvm_info_page, PAGE_SIZE);
 
     /* Allocate and clear special pages. */
@@ -608,6 +669,9 @@ int xc_hvm_build(xc_interface *xch, uint32_t domid,
             args.acpi_module.guest_addr_out;
         hvm_args->smbios_module.guest_addr_out = 
             args.smbios_module.guest_addr_out;
+        hvm_args->lowmem_end = args.lowmem_end;
+        hvm_args->highmem_end = args.highmem_end;
+        hvm_args->mmio_start = args.mmio_start;
     }
 
     free(image);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:26:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:26:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq6l-0007pm-O5; Fri, 21 Nov 2014 15:26:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrq6k-0007pT-H0
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:26:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F5/BC-25276-9B95F645; Fri, 21 Nov 2014 15:26:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416583608!14469998!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14392 invoked from network); 21 Nov 2014 15:26:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:26:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193743134"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:26:29 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1Xrpna-000597-1y;
	Fri, 21 Nov 2014 15:07:02 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:07:00 +0000
Message-ID: <1416582421-10789-19-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 18/19] libxl: fill vNUMA information in hvm 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_dom.c |   27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index bace1cb..5980d87 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -707,7 +707,13 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
     uint64_t str_mfn, cons_mfn;
-    int i, rc;
+    int i, j, rc;
+
+    if (state->num_vmemranges > HVM_MAX_VMEMRANGES ||
+        info->num_vnuma_nodes * info->num_vnuma_nodes > HVM_MAX_LOCALITIES) {
+        rc = ERROR_INVAL;
+        goto out;
+    }
 
     va_map = xc_map_foreign_range(handle, domid,
                                   XC_PAGE_SIZE, PROT_READ | PROT_WRITE,
@@ -722,6 +728,25 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     va_hvm->nr_vcpus = info->max_vcpus;
     memset(va_hvm->vcpu_online, 0, sizeof(va_hvm->vcpu_online));
     memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size);
+
+    va_hvm->nr_nodes = info->num_vnuma_nodes;
+    va_hvm->nr_localities = info->num_vnuma_nodes;
+    for (i = 0; i < info->num_vnuma_nodes; i++) {
+        int bit;
+        libxl_for_each_set_bit(bit, info->vnuma_nodes[i].vcpus)
+            va_hvm->vcpu_to_vnode[bit] = i;
+        for (j = 0; j < info->vnuma_nodes[i].num_distances; j++)
+            va_hvm->localities[i*info->num_vnuma_nodes+j] =
+                info->vnuma_nodes[i].distances[j];
+    }
+    for (i = 0; i < state->num_vmemranges; i++) {
+        va_hvm->vmemranges[i].start = state->vmemranges[i].start;
+        va_hvm->vmemranges[i].end = state->vmemranges[i].end;
+        va_hvm->vmemranges[i].flags = state->vmemranges[i].flags;
+        va_hvm->vmemranges[i].nid = state->vmemranges[i].nid;
+    }
+    va_hvm->nr_vmemranges = state->num_vmemranges;
+
     for (i = 0, sum = 0; i < va_hvm->length; i++)
         sum += ((uint8_t *) va_hvm)[i];
     va_hvm->checksum -= sum;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:26:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:26:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq6l-0007pm-O5; Fri, 21 Nov 2014 15:26:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrq6k-0007pT-H0
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:26:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F5/BC-25276-9B95F645; Fri, 21 Nov 2014 15:26:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416583608!14469998!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14392 invoked from network); 21 Nov 2014 15:26:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:26:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193743134"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:26:29 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1Xrpna-000597-1y;
	Fri, 21 Nov 2014 15:07:02 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:07:00 +0000
Message-ID: <1416582421-10789-19-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 18/19] libxl: fill vNUMA information in hvm 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_dom.c |   27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index bace1cb..5980d87 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -707,7 +707,13 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
     uint64_t str_mfn, cons_mfn;
-    int i, rc;
+    int i, j, rc;
+
+    if (state->num_vmemranges > HVM_MAX_VMEMRANGES ||
+        info->num_vnuma_nodes * info->num_vnuma_nodes > HVM_MAX_LOCALITIES) {
+        rc = ERROR_INVAL;
+        goto out;
+    }
 
     va_map = xc_map_foreign_range(handle, domid,
                                   XC_PAGE_SIZE, PROT_READ | PROT_WRITE,
@@ -722,6 +728,25 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     va_hvm->nr_vcpus = info->max_vcpus;
     memset(va_hvm->vcpu_online, 0, sizeof(va_hvm->vcpu_online));
     memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size);
+
+    va_hvm->nr_nodes = info->num_vnuma_nodes;
+    va_hvm->nr_localities = info->num_vnuma_nodes;
+    for (i = 0; i < info->num_vnuma_nodes; i++) {
+        int bit;
+        libxl_for_each_set_bit(bit, info->vnuma_nodes[i].vcpus)
+            va_hvm->vcpu_to_vnode[bit] = i;
+        for (j = 0; j < info->vnuma_nodes[i].num_distances; j++)
+            va_hvm->localities[i*info->num_vnuma_nodes+j] =
+                info->vnuma_nodes[i].distances[j];
+    }
+    for (i = 0; i < state->num_vmemranges; i++) {
+        va_hvm->vmemranges[i].start = state->vmemranges[i].start;
+        va_hvm->vmemranges[i].end = state->vmemranges[i].end;
+        va_hvm->vmemranges[i].flags = state->vmemranges[i].flags;
+        va_hvm->vmemranges[i].nid = state->vmemranges[i].nid;
+    }
+    va_hvm->nr_vmemranges = state->num_vmemranges;
+
     for (i = 0, sum = 0; i < va_hvm->length; i++)
         sum += ((uint8_t *) va_hvm)[i];
     va_hvm->checksum -= sum;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:27:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:27:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq7M-0007vf-60; Fri, 21 Nov 2014 15:27:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrq7K-0007vI-Gl
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:27:26 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	88/70-17694-DD95F645; Fri, 21 Nov 2014 15:27:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416583643!9270964!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4505 invoked from network); 21 Nov 2014 15:27:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:27:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195277766"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:26:48 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-U6;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:56 +0000
Message-ID: <1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 14/19] hvmloader: disallow memory relocation
	when vNUMA is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
---
 tools/firmware/hvmloader/pci.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 4e8d803..d7ea740 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -88,6 +88,19 @@ void pci_setup(void)
     printf("Relocating guest memory for lowmem MMIO space %s\n",
            allow_memory_relocate?"enabled":"disabled");
 
+    /* Disallow low memory relocation when vNUMA is enabled, because
+     * relocated memory ends up off node. Further more, even if we
+     * dynamically expand node coverage in hvmloader, low memory and
+     * high memory may reside in different physical nodes, blindly
+     * relocates low memory to high memory gives us a sub-optimal
+     * configuration.
+     */
+    if ( hvm_info->nr_nodes != 0 && allow_memory_relocate )
+    {
+        allow_memory_relocate = false;
+        printf("vNUMA enabled, relocating guest memory for lowmem MMIO space disabled\n");
+    }
+
     s = xenstore_read("platform/mmio_hole_size", NULL);
     if ( s )
         mmio_hole_size = strtoll(s, NULL, 0);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:27:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:27:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq7M-0007vo-IQ; Fri, 21 Nov 2014 15:27:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrq7L-0007vQ-9Z
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:27:27 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	3E/04-25547-ED95F645; Fri, 21 Nov 2014 15:27:26 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416583643!9270964!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4659 invoked from network); 21 Nov 2014 15:27:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:27:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195277787"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:27:19 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1Xrpna-000597-1H;
	Fri, 21 Nov 2014 15:07:02 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:59 +0000
Message-ID: <1416582421-10789-18-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 17/19] libxl: refactor hvm_build_set_params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes:
1. Take care of function calls that can fail.
2. Use proper libxl error handling style.
3. Pass in build state instead of individual fields.

This is mechanical change in preparation for later patch.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_dom.c |   48 +++++++++++++++++++++++++++--------------------
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3fe3092..bace1cb 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -702,20 +702,20 @@ out:
 
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
-                                int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn,
-                                domid_t store_domid, domid_t console_domid)
+                                libxl__domain_build_state *state)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
     uint64_t str_mfn, cons_mfn;
-    int i;
+    int i, rc;
 
     va_map = xc_map_foreign_range(handle, domid,
                                   XC_PAGE_SIZE, PROT_READ | PROT_WRITE,
                                   HVM_INFO_PFN);
-    if (va_map == NULL)
-        return -1;
+    if (va_map == NULL) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
     va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
@@ -727,16 +727,27 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     va_hvm->checksum -= sum;
     munmap(va_map, XC_PAGE_SIZE);
 
-    xc_hvm_param_get(handle, domid, HVM_PARAM_STORE_PFN, &str_mfn);
-    xc_hvm_param_get(handle, domid, HVM_PARAM_CONSOLE_PFN, &cons_mfn);
-    xc_hvm_param_set(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
-    xc_hvm_param_set(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
-
-    *store_mfn = str_mfn;
-    *console_mfn = cons_mfn;
-
-    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
-    return 0;
+    rc = xc_hvm_param_get(handle, domid, HVM_PARAM_STORE_PFN, &str_mfn);
+    if (rc) { rc = ERROR_FAIL; goto out; }
+    rc = xc_hvm_param_get(handle, domid, HVM_PARAM_CONSOLE_PFN, &cons_mfn);
+    if (rc) { rc = ERROR_FAIL; goto out; }
+    rc = xc_hvm_param_set(handle, domid, HVM_PARAM_STORE_EVTCHN,
+                          state->store_port);
+    if (rc) { rc = ERROR_FAIL; goto out; }
+    rc = xc_hvm_param_set(handle, domid, HVM_PARAM_CONSOLE_EVTCHN,
+                          state->console_port);
+    if (rc) { rc = ERROR_FAIL; goto out; }
+
+    state->store_mfn = str_mfn;
+    state->console_mfn = cons_mfn;
+
+    rc = xc_dom_gnttab_hvm_seed(handle, domid, state->console_mfn,
+                                state->store_mfn,
+                                state->console_domid,
+                                state->store_domid);
+    if (rc) { rc = ERROR_FAIL; goto out; }
+out:
+    return rc;
 }
 
 static int hvm_build_set_xs_values(libxl__gc *gc,
@@ -918,10 +929,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         ret = set_vnuma_info(gc, domid, info, state);
         if (ret) goto out;
     }
-    ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port,
-                               &state->console_mfn, state->store_domid,
-                               state->console_domid);
+    ret = hvm_build_set_params(ctx->xch, domid, info, state);
     if (ret) {
         LOGEV(ERROR, ret, "hvm build set params failed");
         goto out;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:27:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:27:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq7M-0007vf-60; Fri, 21 Nov 2014 15:27:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrq7K-0007vI-Gl
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:27:26 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	88/70-17694-DD95F645; Fri, 21 Nov 2014 15:27:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416583643!9270964!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4505 invoked from network); 21 Nov 2014 15:27:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:27:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195277766"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:26:48 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-U6;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:56 +0000
Message-ID: <1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 14/19] hvmloader: disallow memory relocation
	when vNUMA is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
---
 tools/firmware/hvmloader/pci.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 4e8d803..d7ea740 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -88,6 +88,19 @@ void pci_setup(void)
     printf("Relocating guest memory for lowmem MMIO space %s\n",
            allow_memory_relocate?"enabled":"disabled");
 
+    /* Disallow low memory relocation when vNUMA is enabled, because
+     * relocated memory ends up off node. Further more, even if we
+     * dynamically expand node coverage in hvmloader, low memory and
+     * high memory may reside in different physical nodes, blindly
+     * relocates low memory to high memory gives us a sub-optimal
+     * configuration.
+     */
+    if ( hvm_info->nr_nodes != 0 && allow_memory_relocate )
+    {
+        allow_memory_relocate = false;
+        printf("vNUMA enabled, relocating guest memory for lowmem MMIO space disabled\n");
+    }
+
     s = xenstore_read("platform/mmio_hole_size", NULL);
     if ( s )
         mmio_hole_size = strtoll(s, NULL, 0);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:27:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:27:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq7M-0007vo-IQ; Fri, 21 Nov 2014 15:27:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrq7L-0007vQ-9Z
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:27:27 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	3E/04-25547-ED95F645; Fri, 21 Nov 2014 15:27:26 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416583643!9270964!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4659 invoked from network); 21 Nov 2014 15:27:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:27:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195277787"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:27:19 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1Xrpna-000597-1H;
	Fri, 21 Nov 2014 15:07:02 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:59 +0000
Message-ID: <1416582421-10789-18-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 17/19] libxl: refactor hvm_build_set_params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes:
1. Take care of function calls that can fail.
2. Use proper libxl error handling style.
3. Pass in build state instead of individual fields.

This is mechanical change in preparation for later patch.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_dom.c |   48 +++++++++++++++++++++++++++--------------------
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3fe3092..bace1cb 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -702,20 +702,20 @@ out:
 
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
-                                int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn,
-                                domid_t store_domid, domid_t console_domid)
+                                libxl__domain_build_state *state)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
     uint64_t str_mfn, cons_mfn;
-    int i;
+    int i, rc;
 
     va_map = xc_map_foreign_range(handle, domid,
                                   XC_PAGE_SIZE, PROT_READ | PROT_WRITE,
                                   HVM_INFO_PFN);
-    if (va_map == NULL)
-        return -1;
+    if (va_map == NULL) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
     va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
@@ -727,16 +727,27 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     va_hvm->checksum -= sum;
     munmap(va_map, XC_PAGE_SIZE);
 
-    xc_hvm_param_get(handle, domid, HVM_PARAM_STORE_PFN, &str_mfn);
-    xc_hvm_param_get(handle, domid, HVM_PARAM_CONSOLE_PFN, &cons_mfn);
-    xc_hvm_param_set(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
-    xc_hvm_param_set(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
-
-    *store_mfn = str_mfn;
-    *console_mfn = cons_mfn;
-
-    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
-    return 0;
+    rc = xc_hvm_param_get(handle, domid, HVM_PARAM_STORE_PFN, &str_mfn);
+    if (rc) { rc = ERROR_FAIL; goto out; }
+    rc = xc_hvm_param_get(handle, domid, HVM_PARAM_CONSOLE_PFN, &cons_mfn);
+    if (rc) { rc = ERROR_FAIL; goto out; }
+    rc = xc_hvm_param_set(handle, domid, HVM_PARAM_STORE_EVTCHN,
+                          state->store_port);
+    if (rc) { rc = ERROR_FAIL; goto out; }
+    rc = xc_hvm_param_set(handle, domid, HVM_PARAM_CONSOLE_EVTCHN,
+                          state->console_port);
+    if (rc) { rc = ERROR_FAIL; goto out; }
+
+    state->store_mfn = str_mfn;
+    state->console_mfn = cons_mfn;
+
+    rc = xc_dom_gnttab_hvm_seed(handle, domid, state->console_mfn,
+                                state->store_mfn,
+                                state->console_domid,
+                                state->store_domid);
+    if (rc) { rc = ERROR_FAIL; goto out; }
+out:
+    return rc;
 }
 
 static int hvm_build_set_xs_values(libxl__gc *gc,
@@ -918,10 +929,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         ret = set_vnuma_info(gc, domid, info, state);
         if (ret) goto out;
     }
-    ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port,
-                               &state->console_mfn, state->store_domid,
-                               state->console_domid);
+    ret = hvm_build_set_params(ctx->xch, domid, info, state);
     if (ret) {
         LOGEV(ERROR, ret, "hvm build set params failed");
         goto out;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:28:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq7v-00085V-Vn; Fri, 21 Nov 2014 15:28:03 +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 1Xrq7t-00084l-Cw
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:28:01 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	81/B8-25714-00A5F645; Fri, 21 Nov 2014 15:28:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416583678!9823705!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15200 invoked from network); 21 Nov 2014 15:27:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:27:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195278101"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:27:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-QN;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:54 +0000
Message-ID: <1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 12/19] hvmloader: construct SRAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |   53 ++++++++++++++++++++++++
 tools/firmware/hvmloader/acpi/build.c   |   68 +++++++++++++++++++++++++++++++
 2 files changed, 121 insertions(+)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 7b22d80..6169213 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -364,6 +364,57 @@ struct acpi_20_madt_intsrcovr {
 };
 
 /*
+ * System Resource Affinity Table header definition (SRAT)
+ */
+struct acpi_20_srat {
+    struct acpi_header header;
+    uint32_t table_revision;
+    uint32_t reserved2[2];
+};
+
+#define ACPI_SRAT_TABLE_REVISION 1
+
+/*
+ * System Resource Affinity Table structure types.
+ */
+#define ACPI_PROCESSOR_AFFINITY 0x0
+#define ACPI_MEMORY_AFFINITY    0x1
+struct acpi_20_srat_processor {
+    uint8_t type;
+    uint8_t length;
+    uint8_t domain;
+    uint8_t apic_id;
+    uint32_t flags;
+    uint8_t sapic_id;
+    uint8_t domain_hi[3];
+    uint32_t reserved;
+};
+
+/*
+ * Local APIC Affinity Flags.  All other bits are reserved and must be 0.
+ */
+#define ACPI_LOCAL_APIC_AFFIN_ENABLED (1 << 0)
+
+struct acpi_20_srat_memory {
+    uint8_t type;
+    uint8_t length;
+    uint32_t domain;
+    uint16_t reserved;
+    uint64_t base_address;
+    uint64_t mem_length;
+    uint32_t reserved2;
+    uint32_t flags;
+    uint64_t reserved3;
+};
+
+/*
+ * Memory Affinity Flags.  All other bits are reserved and must be 0.
+ */
+#define ACPI_MEM_AFFIN_ENABLED (1 << 0)
+#define ACPI_MEM_AFFIN_HOTPLUGGABLE (1 << 1)
+#define ACPI_MEM_AFFIN_NONVOLATILE (1 << 2)
+
+/*
  * Table Signatures.
  */
 #define ACPI_2_0_RSDP_SIGNATURE ASCII64('R','S','D',' ','P','T','R',' ')
@@ -375,6 +426,7 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_TCPA_SIGNATURE ASCII32('T','C','P','A')
 #define ACPI_2_0_HPET_SIGNATURE ASCII32('H','P','E','T')
 #define ACPI_2_0_WAET_SIGNATURE ASCII32('W','A','E','T')
+#define ACPI_2_0_SRAT_SIGNATURE ASCII32('S','R','A','T')
 
 /*
  * Table revision numbers.
@@ -388,6 +440,7 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_HPET_REVISION 0x01
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
+#define ACPI_2_0_SRAT_REVISION 0x01
 
 #pragma pack ()
 
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 1431296..b90344a 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -203,6 +203,66 @@ static struct acpi_20_waet *construct_waet(void)
     return waet;
 }
 
+static struct acpi_20_srat *construct_srat(void)
+{
+    struct acpi_20_srat *srat;
+    struct acpi_20_srat_processor *processor;
+    struct acpi_20_srat_memory *memory;
+    unsigned int size;
+    void *p;
+    int i;
+    uint64_t mem;
+
+    size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
+        sizeof(*memory) * hvm_info->nr_vmemranges;
+
+    p = mem_alloc(size, 16);
+    if (!p) return NULL;
+
+    srat = p;
+    memset(srat, 0, sizeof(*srat));
+    srat->header.signature    = ACPI_2_0_SRAT_SIGNATURE;
+    srat->header.revision     = ACPI_2_0_SRAT_REVISION;
+    fixed_strcpy(srat->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(srat->header.oem_table_id, ACPI_OEM_TABLE_ID);
+    srat->header.oem_revision = ACPI_OEM_REVISION;
+    srat->header.creator_id   = ACPI_CREATOR_ID;
+    srat->header.creator_revision = ACPI_CREATOR_REVISION;
+    srat->table_revision      = ACPI_SRAT_TABLE_REVISION;
+
+    processor = (struct acpi_20_srat_processor *)(srat + 1);
+    for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+    {
+        memset(processor, 0, sizeof(*processor));
+        processor->type     = ACPI_PROCESSOR_AFFINITY;
+        processor->length   = sizeof(*processor);
+        processor->domain   = hvm_info->vcpu_to_vnode[i];
+        processor->apic_id  = LAPIC_ID(i);
+        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
+        processor->sapic_id = 0;
+        processor++;
+    }
+
+    memory = (struct acpi_20_srat_memory *)processor;
+    for ( i = 0; i < hvm_info->nr_vmemranges; i++ )
+    {
+        mem = hvm_info->vmemranges[i].end - hvm_info->vmemranges[i].start;
+        memset(memory, 0, sizeof(*memory));
+        memory->type          = ACPI_MEMORY_AFFINITY;
+        memory->length        = sizeof(*memory);
+        memory->domain        = hvm_info->vmemranges[i].nid;
+        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
+        memory->base_address  = hvm_info->vmemranges[i].start;
+        memory->mem_length    = mem;
+        memory++;
+    }
+
+    srat->header.length = size;
+    set_checksum(srat, offsetof(struct acpi_header, checksum), size);
+
+    return srat;
+}
+
 static int construct_passthrough_tables(unsigned long *table_ptrs,
                                         int nr_tables)
 {
@@ -257,6 +317,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     struct acpi_20_hpet *hpet;
     struct acpi_20_waet *waet;
     struct acpi_20_tcpa *tcpa;
+    struct acpi_20_srat *srat;
     unsigned char *ssdt;
     static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
     uint16_t *tis_hdr;
@@ -270,6 +331,13 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         table_ptrs[nr_tables++] = (unsigned long)madt;
     }
 
+    if ( hvm_info->nr_nodes > 0 )
+    {
+        srat = construct_srat();
+        if (!srat) return -1;
+        table_ptrs[nr_tables++] = (unsigned long)srat;
+    }
+
     /* HPET. */
     if ( hpet_exists(ACPI_HPET_ADDRESS) )
     {
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:28:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq7v-00085V-Vn; Fri, 21 Nov 2014 15:28:03 +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 1Xrq7t-00084l-Cw
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:28:01 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	81/B8-25714-00A5F645; Fri, 21 Nov 2014 15:28:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416583678!9823705!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15200 invoked from network); 21 Nov 2014 15:27:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:27:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="195278101"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:27:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-QN;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:54 +0000
Message-ID: <1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 12/19] hvmloader: construct SRAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |   53 ++++++++++++++++++++++++
 tools/firmware/hvmloader/acpi/build.c   |   68 +++++++++++++++++++++++++++++++
 2 files changed, 121 insertions(+)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 7b22d80..6169213 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -364,6 +364,57 @@ struct acpi_20_madt_intsrcovr {
 };
 
 /*
+ * System Resource Affinity Table header definition (SRAT)
+ */
+struct acpi_20_srat {
+    struct acpi_header header;
+    uint32_t table_revision;
+    uint32_t reserved2[2];
+};
+
+#define ACPI_SRAT_TABLE_REVISION 1
+
+/*
+ * System Resource Affinity Table structure types.
+ */
+#define ACPI_PROCESSOR_AFFINITY 0x0
+#define ACPI_MEMORY_AFFINITY    0x1
+struct acpi_20_srat_processor {
+    uint8_t type;
+    uint8_t length;
+    uint8_t domain;
+    uint8_t apic_id;
+    uint32_t flags;
+    uint8_t sapic_id;
+    uint8_t domain_hi[3];
+    uint32_t reserved;
+};
+
+/*
+ * Local APIC Affinity Flags.  All other bits are reserved and must be 0.
+ */
+#define ACPI_LOCAL_APIC_AFFIN_ENABLED (1 << 0)
+
+struct acpi_20_srat_memory {
+    uint8_t type;
+    uint8_t length;
+    uint32_t domain;
+    uint16_t reserved;
+    uint64_t base_address;
+    uint64_t mem_length;
+    uint32_t reserved2;
+    uint32_t flags;
+    uint64_t reserved3;
+};
+
+/*
+ * Memory Affinity Flags.  All other bits are reserved and must be 0.
+ */
+#define ACPI_MEM_AFFIN_ENABLED (1 << 0)
+#define ACPI_MEM_AFFIN_HOTPLUGGABLE (1 << 1)
+#define ACPI_MEM_AFFIN_NONVOLATILE (1 << 2)
+
+/*
  * Table Signatures.
  */
 #define ACPI_2_0_RSDP_SIGNATURE ASCII64('R','S','D',' ','P','T','R',' ')
@@ -375,6 +426,7 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_TCPA_SIGNATURE ASCII32('T','C','P','A')
 #define ACPI_2_0_HPET_SIGNATURE ASCII32('H','P','E','T')
 #define ACPI_2_0_WAET_SIGNATURE ASCII32('W','A','E','T')
+#define ACPI_2_0_SRAT_SIGNATURE ASCII32('S','R','A','T')
 
 /*
  * Table revision numbers.
@@ -388,6 +440,7 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_HPET_REVISION 0x01
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
+#define ACPI_2_0_SRAT_REVISION 0x01
 
 #pragma pack ()
 
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 1431296..b90344a 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -203,6 +203,66 @@ static struct acpi_20_waet *construct_waet(void)
     return waet;
 }
 
+static struct acpi_20_srat *construct_srat(void)
+{
+    struct acpi_20_srat *srat;
+    struct acpi_20_srat_processor *processor;
+    struct acpi_20_srat_memory *memory;
+    unsigned int size;
+    void *p;
+    int i;
+    uint64_t mem;
+
+    size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
+        sizeof(*memory) * hvm_info->nr_vmemranges;
+
+    p = mem_alloc(size, 16);
+    if (!p) return NULL;
+
+    srat = p;
+    memset(srat, 0, sizeof(*srat));
+    srat->header.signature    = ACPI_2_0_SRAT_SIGNATURE;
+    srat->header.revision     = ACPI_2_0_SRAT_REVISION;
+    fixed_strcpy(srat->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(srat->header.oem_table_id, ACPI_OEM_TABLE_ID);
+    srat->header.oem_revision = ACPI_OEM_REVISION;
+    srat->header.creator_id   = ACPI_CREATOR_ID;
+    srat->header.creator_revision = ACPI_CREATOR_REVISION;
+    srat->table_revision      = ACPI_SRAT_TABLE_REVISION;
+
+    processor = (struct acpi_20_srat_processor *)(srat + 1);
+    for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+    {
+        memset(processor, 0, sizeof(*processor));
+        processor->type     = ACPI_PROCESSOR_AFFINITY;
+        processor->length   = sizeof(*processor);
+        processor->domain   = hvm_info->vcpu_to_vnode[i];
+        processor->apic_id  = LAPIC_ID(i);
+        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
+        processor->sapic_id = 0;
+        processor++;
+    }
+
+    memory = (struct acpi_20_srat_memory *)processor;
+    for ( i = 0; i < hvm_info->nr_vmemranges; i++ )
+    {
+        mem = hvm_info->vmemranges[i].end - hvm_info->vmemranges[i].start;
+        memset(memory, 0, sizeof(*memory));
+        memory->type          = ACPI_MEMORY_AFFINITY;
+        memory->length        = sizeof(*memory);
+        memory->domain        = hvm_info->vmemranges[i].nid;
+        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
+        memory->base_address  = hvm_info->vmemranges[i].start;
+        memory->mem_length    = mem;
+        memory++;
+    }
+
+    srat->header.length = size;
+    set_checksum(srat, offsetof(struct acpi_header, checksum), size);
+
+    return srat;
+}
+
 static int construct_passthrough_tables(unsigned long *table_ptrs,
                                         int nr_tables)
 {
@@ -257,6 +317,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     struct acpi_20_hpet *hpet;
     struct acpi_20_waet *waet;
     struct acpi_20_tcpa *tcpa;
+    struct acpi_20_srat *srat;
     unsigned char *ssdt;
     static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
     uint16_t *tis_hdr;
@@ -270,6 +331,13 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         table_ptrs[nr_tables++] = (unsigned long)madt;
     }
 
+    if ( hvm_info->nr_nodes > 0 )
+    {
+        srat = construct_srat();
+        if (!srat) return -1;
+        table_ptrs[nr_tables++] = (unsigned long)srat;
+    }
+
     /* HPET. */
     if ( hpet_exists(ACPI_HPET_ADDRESS) )
     {
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:29:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1Xrq8w-0008I2-F7; Fri, 21 Nov 2014 15:29:06 +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 1Xrq8v-0008Hm-Eh
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:29:05 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	4F/BE-26858-04A5F645; Fri, 21 Nov 2014 15:29:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416583739!10552258!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21349 invoked from network); 21 Nov 2014 15:29:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:29:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193744161"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:27:58 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-SE;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:55 +0000
Message-ID: <1416582421-10789-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 13/19] hvmloader: construct SLIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |    8 +++++++
 tools/firmware/hvmloader/acpi/build.c   |   36 +++++++++++++++++++++++++++++++
 2 files changed, 44 insertions(+)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 6169213..d698095 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -414,6 +414,12 @@ struct acpi_20_srat_memory {
 #define ACPI_MEM_AFFIN_HOTPLUGGABLE (1 << 1)
 #define ACPI_MEM_AFFIN_NONVOLATILE (1 << 2)
 
+struct acpi_20_slit {
+    struct acpi_header header;
+    uint64_t localities;
+    uint8_t entry[0];
+};
+
 /*
  * Table Signatures.
  */
@@ -427,6 +433,7 @@ struct acpi_20_srat_memory {
 #define ACPI_2_0_HPET_SIGNATURE ASCII32('H','P','E','T')
 #define ACPI_2_0_WAET_SIGNATURE ASCII32('W','A','E','T')
 #define ACPI_2_0_SRAT_SIGNATURE ASCII32('S','R','A','T')
+#define ACPI_2_0_SLIT_SIGNATURE ASCII32('S','L','I','T')
 
 /*
  * Table revision numbers.
@@ -441,6 +448,7 @@ struct acpi_20_srat_memory {
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
 #define ACPI_2_0_SRAT_REVISION 0x01
+#define ACPI_2_0_SLIT_REVISION 0x01
 
 #pragma pack ()
 
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index b90344a..95fd603 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -263,6 +263,38 @@ static struct acpi_20_srat *construct_srat(void)
     return srat;
 }
 
+static struct acpi_20_slit *construct_slit(void)
+{
+    struct acpi_20_slit *slit;
+    unsigned int num, size;
+    int i;
+
+    num = hvm_info->nr_localities * hvm_info->nr_localities;
+    size = sizeof(*slit) + num * sizeof(uint8_t);
+
+    slit = mem_alloc(size, 16);
+    if (!slit) return NULL;
+
+    memset(slit, 0, size);
+    slit->header.signature    = ACPI_2_0_SLIT_SIGNATURE;
+    slit->header.revision     = ACPI_2_0_SLIT_REVISION;
+    fixed_strcpy(slit->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(slit->header.oem_table_id, ACPI_OEM_TABLE_ID);
+    slit->header.oem_revision = ACPI_OEM_REVISION;
+    slit->header.creator_id   = ACPI_CREATOR_ID;
+    slit->header.creator_revision = ACPI_CREATOR_REVISION;
+
+    for ( i = 0; i < num; i++ )
+        slit->entry[i] = hvm_info->localities[i];
+
+    slit->localities = hvm_info->nr_localities;
+
+    slit->header.length = size;
+    set_checksum(slit, offsetof(struct acpi_header, checksum), size);
+
+    return slit;
+}
+
 static int construct_passthrough_tables(unsigned long *table_ptrs,
                                         int nr_tables)
 {
@@ -318,6 +350,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     struct acpi_20_waet *waet;
     struct acpi_20_tcpa *tcpa;
     struct acpi_20_srat *srat;
+    struct acpi_20_slit *slit;
     unsigned char *ssdt;
     static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
     uint16_t *tis_hdr;
@@ -336,6 +369,9 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         srat = construct_srat();
         if (!srat) return -1;
         table_ptrs[nr_tables++] = (unsigned long)srat;
+        slit = construct_slit();
+        if (!slit) return -1;
+        table_ptrs[nr_tables++] = (unsigned long)slit;
     }
 
     /* HPET. */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:29:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1Xrq8w-0008I2-F7; Fri, 21 Nov 2014 15:29:06 +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 1Xrq8v-0008Hm-Eh
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:29:05 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	4F/BE-26858-04A5F645; Fri, 21 Nov 2014 15:29:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416583739!10552258!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21349 invoked from network); 21 Nov 2014 15:29:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:29:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193744161"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:27:58 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-SE;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:55 +0000
Message-ID: <1416582421-10789-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 13/19] hvmloader: construct SLIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |    8 +++++++
 tools/firmware/hvmloader/acpi/build.c   |   36 +++++++++++++++++++++++++++++++
 2 files changed, 44 insertions(+)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 6169213..d698095 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -414,6 +414,12 @@ struct acpi_20_srat_memory {
 #define ACPI_MEM_AFFIN_HOTPLUGGABLE (1 << 1)
 #define ACPI_MEM_AFFIN_NONVOLATILE (1 << 2)
 
+struct acpi_20_slit {
+    struct acpi_header header;
+    uint64_t localities;
+    uint8_t entry[0];
+};
+
 /*
  * Table Signatures.
  */
@@ -427,6 +433,7 @@ struct acpi_20_srat_memory {
 #define ACPI_2_0_HPET_SIGNATURE ASCII32('H','P','E','T')
 #define ACPI_2_0_WAET_SIGNATURE ASCII32('W','A','E','T')
 #define ACPI_2_0_SRAT_SIGNATURE ASCII32('S','R','A','T')
+#define ACPI_2_0_SLIT_SIGNATURE ASCII32('S','L','I','T')
 
 /*
  * Table revision numbers.
@@ -441,6 +448,7 @@ struct acpi_20_srat_memory {
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
 #define ACPI_2_0_SRAT_REVISION 0x01
+#define ACPI_2_0_SLIT_REVISION 0x01
 
 #pragma pack ()
 
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index b90344a..95fd603 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -263,6 +263,38 @@ static struct acpi_20_srat *construct_srat(void)
     return srat;
 }
 
+static struct acpi_20_slit *construct_slit(void)
+{
+    struct acpi_20_slit *slit;
+    unsigned int num, size;
+    int i;
+
+    num = hvm_info->nr_localities * hvm_info->nr_localities;
+    size = sizeof(*slit) + num * sizeof(uint8_t);
+
+    slit = mem_alloc(size, 16);
+    if (!slit) return NULL;
+
+    memset(slit, 0, size);
+    slit->header.signature    = ACPI_2_0_SLIT_SIGNATURE;
+    slit->header.revision     = ACPI_2_0_SLIT_REVISION;
+    fixed_strcpy(slit->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(slit->header.oem_table_id, ACPI_OEM_TABLE_ID);
+    slit->header.oem_revision = ACPI_OEM_REVISION;
+    slit->header.creator_id   = ACPI_CREATOR_ID;
+    slit->header.creator_revision = ACPI_CREATOR_REVISION;
+
+    for ( i = 0; i < num; i++ )
+        slit->entry[i] = hvm_info->localities[i];
+
+    slit->localities = hvm_info->nr_localities;
+
+    slit->header.length = size;
+    set_checksum(slit, offsetof(struct acpi_header, checksum), size);
+
+    return slit;
+}
+
 static int construct_passthrough_tables(unsigned long *table_ptrs,
                                         int nr_tables)
 {
@@ -318,6 +350,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     struct acpi_20_waet *waet;
     struct acpi_20_tcpa *tcpa;
     struct acpi_20_srat *srat;
+    struct acpi_20_slit *slit;
     unsigned char *ssdt;
     static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
     uint16_t *tis_hdr;
@@ -336,6 +369,9 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         srat = construct_srat();
         if (!srat) return -1;
         table_ptrs[nr_tables++] = (unsigned long)srat;
+        slit = construct_slit();
+        if (!slit) return -1;
+        table_ptrs[nr_tables++] = (unsigned long)slit;
     }
 
     /* HPET. */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:29:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1Xrq8y-0008J2-Rj; Fri, 21 Nov 2014 15:29:08 +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 1Xrq8x-0008Hz-2w
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:29:07 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	9A/61-05632-24A5F645; Fri, 21 Nov 2014 15:29:06 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416583739!10552258!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21521 invoked from network); 21 Nov 2014 15:29:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:29:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193744171"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:28:29 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-VS;
	Fri, 21 Nov 2014 15:07:02 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:58 +0000
Message-ID: <1416582421-10789-17-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 16/19] libxl: build,
	check and pass vNUMA info to Xen for HVM guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Libxc has more involvement in building vmemranges in HVM case. The
building of vmemranges is placed after xc_hvm_build returns, because it
relies on memory hole information provided by xc_hvm_build.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_create.c   |    9 +++++++
 tools/libxl/libxl_dom.c      |   28 +++++++++++++++++++++
 tools/libxl/libxl_internal.h |    5 ++++
 tools/libxl/libxl_vnuma.c    |   56 ++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 98 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..1d96a5f 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -843,6 +843,15 @@ static void initiate_domain_create(libxl__egc *egc,
         goto error_out;
     }
 
+    /* Disallow PoD and vNUMA to be enabled at the same time because PoD
+     * pool is not vNUMA-aware yet.
+     */
+    if (pod_enabled && d_config->b_info.num_vnuma_nodes) {
+        ret = ERROR_INVAL;
+        LOG(ERROR, "Cannot enable PoD and vNUMA at the same time");
+        goto error_out;
+    }
+
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7339bbc..3fe3092 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -884,12 +884,40 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
 
+    if (info->num_vnuma_nodes != 0) {
+        int i;
+
+        args.nr_vnodes = info->num_vnuma_nodes;
+        args.vnode_to_pnode = libxl__malloc(gc, sizeof(*args.vnode_to_pnode) *
+                                            args.nr_vnodes);
+        args.vnode_size = libxl__malloc(gc, sizeof(*args.vnode_size) *
+                                        args.nr_vnodes);
+        for (i = 0; i < args.nr_vnodes; i++) {
+            args.vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
+            args.vnode_size[i] = info->vnuma_nodes[i].mem;
+        }
+
+        /* Consider video ram belongs to node 0 */
+        args.vnode_size[0] -= (info->video_memkb >> 10);
+    }
+
     ret = xc_hvm_build(ctx->xch, domid, &args);
     if (ret) {
         LOGEV(ERROR, ret, "hvm building failed");
         goto out;
     }
 
+    if (info->num_vnuma_nodes != 0) {
+        ret = libxl__vnuma_build_vmemrange_hvm(gc, domid, info, state, &args);
+        if (ret) {
+            LOGEV(ERROR, ret, "hvm build vmemranges failed");
+            goto out;
+        }
+        ret = libxl__vnuma_config_check(gc, info, state);
+        if (ret) goto out;
+        ret = set_vnuma_info(gc, domid, info, state);
+        if (ret) goto out;
+    }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
                                &state->store_mfn, state->console_port,
                                &state->console_mfn, state->store_domid,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b1b60cb..02e2bce 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3401,6 +3401,11 @@ int libxl__vnuma_build_vmemrange_pv(libxl__gc *gc,
                                     uint32_t domid,
                                     libxl_domain_build_info *b_info,
                                     libxl__domain_build_state *state);
+int libxl__vnuma_build_vmemrange_hvm(libxl__gc *gc,
+                                     uint32_t domid,
+                                     libxl_domain_build_info *b_info,
+                                     libxl__domain_build_state *state,
+                                     struct xc_hvm_build_args *args);
 
 _hidden int libxl__ms_vm_genid_set(libxl__gc *gc, uint32_t domid,
                                    const libxl_ms_vm_genid *id);
diff --git a/tools/libxl/libxl_vnuma.c b/tools/libxl/libxl_vnuma.c
index 1d50606..5609dce 100644
--- a/tools/libxl/libxl_vnuma.c
+++ b/tools/libxl/libxl_vnuma.c
@@ -163,6 +163,62 @@ int libxl__vnuma_build_vmemrange_pv(libxl__gc *gc,
     return libxl__arch_vnuma_build_vmemrange(gc, domid, b_info, state);
 }
 
+/* Build vmemranges for HVM guest */
+int libxl__vnuma_build_vmemrange_hvm(libxl__gc *gc,
+                                     uint32_t domid,
+                                     libxl_domain_build_info *b_info,
+                                     libxl__domain_build_state *state,
+                                     struct xc_hvm_build_args *args)
+{
+    uint64_t hole_start, hole_end, next;
+    int i, x;
+    vmemrange_t *v;
+
+    /* Derive vmemranges from vnode size and memory hole.
+     *
+     * Guest physical address space layout:
+     * [0, hole_start) [hole_start, hole_end) [hole_end, highmem_end)
+     */
+    hole_start = args->lowmem_end < args->mmio_start ?
+        args->lowmem_end : args->mmio_start;
+    hole_end = (args->mmio_start + args->mmio_size) > (1ULL << 32) ?
+        (args->mmio_start + args->mmio_size) : (1ULL << 32);
+
+    assert(state->vmemranges == NULL);
+
+    next = 0;
+    x = 0;
+    v = NULL;
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        libxl_vnode_info *p = &b_info->vnuma_nodes[i];
+        uint64_t remaining = (p->mem << 20);
+
+        while (remaining > 0) {
+            uint64_t count = remaining;
+
+            if (next >= hole_start && next < hole_end)
+                next = hole_end;
+            if ((next < hole_start) && (next + remaining >= hole_start))
+                count = hole_start - next;
+
+            v = libxl__realloc(gc, v, sizeof(vmemrange_t) * (x + 1));
+            v[x].start = next;
+            v[x].end = next + count;
+            v[x].flags = 0;
+            v[x].nid = i;
+
+            x++;
+            remaining -= count;
+            next += count;
+        }
+    }
+
+    state->vmemranges = v;
+    state->num_vmemranges = x;
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:29:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1Xrq8y-0008J2-Rj; Fri, 21 Nov 2014 15:29:08 +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 1Xrq8x-0008Hz-2w
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:29:07 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	9A/61-05632-24A5F645; Fri, 21 Nov 2014 15:29:06 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416583739!10552258!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21521 invoked from network); 21 Nov 2014 15:29:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:29:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193744171"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:28:29 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-VS;
	Fri, 21 Nov 2014 15:07:02 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:58 +0000
Message-ID: <1416582421-10789-17-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 16/19] libxl: build,
	check and pass vNUMA info to Xen for HVM guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Libxc has more involvement in building vmemranges in HVM case. The
building of vmemranges is placed after xc_hvm_build returns, because it
relies on memory hole information provided by xc_hvm_build.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 tools/libxl/libxl_create.c   |    9 +++++++
 tools/libxl/libxl_dom.c      |   28 +++++++++++++++++++++
 tools/libxl/libxl_internal.h |    5 ++++
 tools/libxl/libxl_vnuma.c    |   56 ++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 98 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..1d96a5f 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -843,6 +843,15 @@ static void initiate_domain_create(libxl__egc *egc,
         goto error_out;
     }
 
+    /* Disallow PoD and vNUMA to be enabled at the same time because PoD
+     * pool is not vNUMA-aware yet.
+     */
+    if (pod_enabled && d_config->b_info.num_vnuma_nodes) {
+        ret = ERROR_INVAL;
+        LOG(ERROR, "Cannot enable PoD and vNUMA at the same time");
+        goto error_out;
+    }
+
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7339bbc..3fe3092 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -884,12 +884,40 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
 
+    if (info->num_vnuma_nodes != 0) {
+        int i;
+
+        args.nr_vnodes = info->num_vnuma_nodes;
+        args.vnode_to_pnode = libxl__malloc(gc, sizeof(*args.vnode_to_pnode) *
+                                            args.nr_vnodes);
+        args.vnode_size = libxl__malloc(gc, sizeof(*args.vnode_size) *
+                                        args.nr_vnodes);
+        for (i = 0; i < args.nr_vnodes; i++) {
+            args.vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
+            args.vnode_size[i] = info->vnuma_nodes[i].mem;
+        }
+
+        /* Consider video ram belongs to node 0 */
+        args.vnode_size[0] -= (info->video_memkb >> 10);
+    }
+
     ret = xc_hvm_build(ctx->xch, domid, &args);
     if (ret) {
         LOGEV(ERROR, ret, "hvm building failed");
         goto out;
     }
 
+    if (info->num_vnuma_nodes != 0) {
+        ret = libxl__vnuma_build_vmemrange_hvm(gc, domid, info, state, &args);
+        if (ret) {
+            LOGEV(ERROR, ret, "hvm build vmemranges failed");
+            goto out;
+        }
+        ret = libxl__vnuma_config_check(gc, info, state);
+        if (ret) goto out;
+        ret = set_vnuma_info(gc, domid, info, state);
+        if (ret) goto out;
+    }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
                                &state->store_mfn, state->console_port,
                                &state->console_mfn, state->store_domid,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b1b60cb..02e2bce 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3401,6 +3401,11 @@ int libxl__vnuma_build_vmemrange_pv(libxl__gc *gc,
                                     uint32_t domid,
                                     libxl_domain_build_info *b_info,
                                     libxl__domain_build_state *state);
+int libxl__vnuma_build_vmemrange_hvm(libxl__gc *gc,
+                                     uint32_t domid,
+                                     libxl_domain_build_info *b_info,
+                                     libxl__domain_build_state *state,
+                                     struct xc_hvm_build_args *args);
 
 _hidden int libxl__ms_vm_genid_set(libxl__gc *gc, uint32_t domid,
                                    const libxl_ms_vm_genid *id);
diff --git a/tools/libxl/libxl_vnuma.c b/tools/libxl/libxl_vnuma.c
index 1d50606..5609dce 100644
--- a/tools/libxl/libxl_vnuma.c
+++ b/tools/libxl/libxl_vnuma.c
@@ -163,6 +163,62 @@ int libxl__vnuma_build_vmemrange_pv(libxl__gc *gc,
     return libxl__arch_vnuma_build_vmemrange(gc, domid, b_info, state);
 }
 
+/* Build vmemranges for HVM guest */
+int libxl__vnuma_build_vmemrange_hvm(libxl__gc *gc,
+                                     uint32_t domid,
+                                     libxl_domain_build_info *b_info,
+                                     libxl__domain_build_state *state,
+                                     struct xc_hvm_build_args *args)
+{
+    uint64_t hole_start, hole_end, next;
+    int i, x;
+    vmemrange_t *v;
+
+    /* Derive vmemranges from vnode size and memory hole.
+     *
+     * Guest physical address space layout:
+     * [0, hole_start) [hole_start, hole_end) [hole_end, highmem_end)
+     */
+    hole_start = args->lowmem_end < args->mmio_start ?
+        args->lowmem_end : args->mmio_start;
+    hole_end = (args->mmio_start + args->mmio_size) > (1ULL << 32) ?
+        (args->mmio_start + args->mmio_size) : (1ULL << 32);
+
+    assert(state->vmemranges == NULL);
+
+    next = 0;
+    x = 0;
+    v = NULL;
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        libxl_vnode_info *p = &b_info->vnuma_nodes[i];
+        uint64_t remaining = (p->mem << 20);
+
+        while (remaining > 0) {
+            uint64_t count = remaining;
+
+            if (next >= hole_start && next < hole_end)
+                next = hole_end;
+            if ((next < hole_start) && (next + remaining >= hole_start))
+                count = hole_start - next;
+
+            v = libxl__realloc(gc, v, sizeof(vmemrange_t) * (x + 1));
+            v[x].start = next;
+            v[x].end = next + count;
+            v[x].flags = 0;
+            v[x].nid = i;
+
+            x++;
+            remaining -= count;
+            next += count;
+        }
+    }
+
+    state->vmemranges = v;
+    state->num_vmemranges = x;
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:29:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:29:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq9E-0008Oy-Hd; Fri, 21 Nov 2014 15:29:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux+xen-devel=lists.xensource.com@arm.linux.org.uk>)
	id 1Xrq9C-0008OD-Lz
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 15:29:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	ED/24-09842-25A5F645; Fri, 21 Nov 2014 15:29:22 +0000
X-Env-Sender: linux+xen-devel=lists.xensource.com@arm.linux.org.uk
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416583758!12315711!1
X-Originating-IP: [78.32.30.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5045 invoked from network); 21 Nov 2014 15:29:19 -0000
Received: from pandora.arm.linux.org.uk (HELO pandora.arm.linux.org.uk)
	(78.32.30.218)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:29:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=arm.linux.org.uk; s=pandora-2014; 
	h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=EhFgnerHTEM0abCifuqdmneNUkC+4RQWLapvi2ra5W0=; 
	b=XKv0O5ue88hkwn/A/xbjK9utIqRNrfF0X3w63DDU9FdG6imYEhMkT6HCBPFPDnCoZoMhnQJA0xddyV0OVrlhkzlmgEQWw8ypRcU2Qw9ziA2kAdkrOY5aX64G3QrYnk0EjFqLZNCa0Q+yqUND+xQvRU59Vp4ROX247gmsH6UpJ3M=;
Received: from n2100.arm.linux.org.uk
	([fd8f:7570:feb6:1:214:fdff:fe10:4f86]:35105)
	by pandora.arm.linux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
	(Exim 4.82_1-5b7a7c0-XX) (envelope-from <linux@arm.linux.org.uk>)
	id 1Xrq92-0001EP-Tt; Fri, 21 Nov 2014 15:29:13 +0000
Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76)
	(envelope-from <linux@n2100.arm.linux.org.uk>)
	id 1Xrq8z-0001Gl-G7; Fri, 21 Nov 2014 15:29:09 +0000
Date: Fri, 21 Nov 2014 15:29:09 +0000
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141121152908.GU4042@n2100.arm.linux.org.uk>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411181649000.27247@kaball.uk.xensource.com>
	<20141120000736.GN4042@n2100.arm.linux.org.uk>
	<alpine.DEB.2.02.1411201036400.12596@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411201036400.12596@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 05/13] arm: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 10:39:32AM +0000, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Russell King - ARM Linux wrote:
> > On Tue, Nov 18, 2014 at 04:49:21PM +0000, Stefano Stabellini wrote:
> > > ping?
> > 
> > Sending something which wants my attention _To:_ me is always a good idea :)
> 
> I'll keep that in mind :-)
> 
> 
> > The patch is fine in itself, but I have a niggle about the
> > is_device_dma_coherent() - provided this is only used in architecture
> > specific code, that should be fine.  It could probably do with a comment
> > to that effect in an attempt to discourage drivers using it (thereby
> > becoming less portable to other architectures.)
> 
> Can I take this as an Acked-by?
> Good point regarding the comment. Maybe I can add:
> 
> /* do not use this function in a driver */

Provided it gets such a comment, yes.  Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:29:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:29:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq9E-0008Oy-Hd; Fri, 21 Nov 2014 15:29:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux+xen-devel=lists.xensource.com@arm.linux.org.uk>)
	id 1Xrq9C-0008OD-Lz
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 15:29:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	ED/24-09842-25A5F645; Fri, 21 Nov 2014 15:29:22 +0000
X-Env-Sender: linux+xen-devel=lists.xensource.com@arm.linux.org.uk
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416583758!12315711!1
X-Originating-IP: [78.32.30.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5045 invoked from network); 21 Nov 2014 15:29:19 -0000
Received: from pandora.arm.linux.org.uk (HELO pandora.arm.linux.org.uk)
	(78.32.30.218)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:29:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=arm.linux.org.uk; s=pandora-2014; 
	h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=EhFgnerHTEM0abCifuqdmneNUkC+4RQWLapvi2ra5W0=; 
	b=XKv0O5ue88hkwn/A/xbjK9utIqRNrfF0X3w63DDU9FdG6imYEhMkT6HCBPFPDnCoZoMhnQJA0xddyV0OVrlhkzlmgEQWw8ypRcU2Qw9ziA2kAdkrOY5aX64G3QrYnk0EjFqLZNCa0Q+yqUND+xQvRU59Vp4ROX247gmsH6UpJ3M=;
Received: from n2100.arm.linux.org.uk
	([fd8f:7570:feb6:1:214:fdff:fe10:4f86]:35105)
	by pandora.arm.linux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
	(Exim 4.82_1-5b7a7c0-XX) (envelope-from <linux@arm.linux.org.uk>)
	id 1Xrq92-0001EP-Tt; Fri, 21 Nov 2014 15:29:13 +0000
Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76)
	(envelope-from <linux@n2100.arm.linux.org.uk>)
	id 1Xrq8z-0001Gl-G7; Fri, 21 Nov 2014 15:29:09 +0000
Date: Fri, 21 Nov 2014 15:29:09 +0000
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141121152908.GU4042@n2100.arm.linux.org.uk>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411141158560.26318@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411181649000.27247@kaball.uk.xensource.com>
	<20141120000736.GN4042@n2100.arm.linux.org.uk>
	<alpine.DEB.2.02.1411201036400.12596@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411201036400.12596@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 05/13] arm: introduce
	is_device_dma_coherent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 10:39:32AM +0000, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Russell King - ARM Linux wrote:
> > On Tue, Nov 18, 2014 at 04:49:21PM +0000, Stefano Stabellini wrote:
> > > ping?
> > 
> > Sending something which wants my attention _To:_ me is always a good idea :)
> 
> I'll keep that in mind :-)
> 
> 
> > The patch is fine in itself, but I have a niggle about the
> > is_device_dma_coherent() - provided this is only used in architecture
> > specific code, that should be fine.  It could probably do with a comment
> > to that effect in an attempt to discourage drivers using it (thereby
> > becoming less portable to other architectures.)
> 
> Can I take this as an Acked-by?
> Good point regarding the comment. Maybe I can add:
> 
> /* do not use this function in a driver */

Provided it gets such a comment, yes.  Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:29:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:29:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq9Z-0008W3-Vn; Fri, 21 Nov 2014 15:29:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xrq9Y-0008VO-Rx
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 15:29:44 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	88/82-05632-86A5F645; Fri, 21 Nov 2014 15:29:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416583782!12960301!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32027 invoked from network); 21 Nov 2014 15:29:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:29:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193744403"
Message-ID: <546F5A64.2050901@citrix.com>
Date: Fri, 21 Nov 2014 15:29:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <546F4E86.8060801@suse.com> <546F4FFF.1080101@citrix.com>
	<546F5499.5000501@suse.com>
In-Reply-To: <546F5499.5000501@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 15:04, Juergen Gross wrote:
> On 11/21/2014 03:45 PM, Andrew Cooper wrote:
>> On 21/11/14 14:39, Juergen Gross wrote:
>>> Hi,
>>>
>>> again a fallout from my "linear p2m list" tests:
>>>
>>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>>> wrong device to the domain. The MMIO address was too large for a
>>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>>
>>> Instead of rejecting the operation Xen tried to perform it resulting
>>> in a (quite understandable) failure in the domU.
>>>
>>> I think either the hypervisor or the tools should refuse to do
>>> PCI-passthrough in this case.
>>>
>>
>> What actually goes wrong?  Does the 32bit guest truncate the MMIO region
>> to 44 bits and try to map that?
>
> I think it is 42 bits (the top 2 bits of the MFN are the "identity" and
> "foreign" bits).

This is a very grey area in desperate need of some clarification.

There is nothing (I am aware of) in the API or ABI, not even an
INVALID_PFN/INVALID_MFN constant.  ~0UL is independently defined in
several locations, but I believe that only Linux has the notion of a
foreign bit in the p2m; Xen and the Toolstack don't appear to have this
concept.

When developing migration v2, there was quite a lot of digging through
history to find out what was safe.  The top bit being set in the guests
p2m used to mean "this is an skb frame and can safely be left behind on
migrate"  (This change was subsequently backed out).  This was back in
the days when max_pfn was 0x1000, and there were plenty of "free" bits
in the top of a 32bit unsigned long.

None of the interfaces like this have been re-evaluated as machines have
become larger.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:29:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:29:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq9Z-0008W3-Vn; Fri, 21 Nov 2014 15:29:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xrq9Y-0008VO-Rx
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 15:29:44 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	88/82-05632-86A5F645; Fri, 21 Nov 2014 15:29:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416583782!12960301!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32027 invoked from network); 21 Nov 2014 15:29:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:29:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193744403"
Message-ID: <546F5A64.2050901@citrix.com>
Date: Fri, 21 Nov 2014 15:29:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <546F4E86.8060801@suse.com> <546F4FFF.1080101@citrix.com>
	<546F5499.5000501@suse.com>
In-Reply-To: <546F5499.5000501@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 15:04, Juergen Gross wrote:
> On 11/21/2014 03:45 PM, Andrew Cooper wrote:
>> On 21/11/14 14:39, Juergen Gross wrote:
>>> Hi,
>>>
>>> again a fallout from my "linear p2m list" tests:
>>>
>>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>>> wrong device to the domain. The MMIO address was too large for a
>>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>>
>>> Instead of rejecting the operation Xen tried to perform it resulting
>>> in a (quite understandable) failure in the domU.
>>>
>>> I think either the hypervisor or the tools should refuse to do
>>> PCI-passthrough in this case.
>>>
>>
>> What actually goes wrong?  Does the 32bit guest truncate the MMIO region
>> to 44 bits and try to map that?
>
> I think it is 42 bits (the top 2 bits of the MFN are the "identity" and
> "foreign" bits).

This is a very grey area in desperate need of some clarification.

There is nothing (I am aware of) in the API or ABI, not even an
INVALID_PFN/INVALID_MFN constant.  ~0UL is independently defined in
several locations, but I believe that only Linux has the notion of a
foreign bit in the p2m; Xen and the Toolstack don't appear to have this
concept.

When developing migration v2, there was quite a lot of digging through
history to find out what was safe.  The top bit being set in the guests
p2m used to mean "this is an skb frame and can safely be left behind on
migrate"  (This change was subsequently backed out).  This was back in
the days when max_pfn was 0x1000, and there were plenty of "free" bits
in the top of a 32bit unsigned long.

None of the interfaces like this have been re-evaluated as machines have
become larger.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:30:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq9n-00009v-E2; Fri, 21 Nov 2014 15:29:59 +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 1Xrq9m-00009E-6G
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:29:58 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	F1/CF-22819-57A5F645; Fri, 21 Nov 2014 15:29:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416583795!9824110!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31003 invoked from network); 21 Nov 2014 15:29:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:29:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193744465"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:29:04 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Pq;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:53 +0000
Message-ID: <1416582421-10789-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 11/19] hvmloader: add new fields for vNUMA
	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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 xen/include/public/hvm/hvm_info_table.h |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/xen/include/public/hvm/hvm_info_table.h b/xen/include/public/hvm/hvm_info_table.h
index 36085fa..9d3f218 100644
--- a/xen/include/public/hvm/hvm_info_table.h
+++ b/xen/include/public/hvm/hvm_info_table.h
@@ -32,6 +32,17 @@
 /* Maximum we can support with current vLAPIC ID mapping. */
 #define HVM_MAX_VCPUS        128
 
+#define HVM_MAX_NODES         16
+#define HVM_MAX_LOCALITIES    (HVM_MAX_NODES * HVM_MAX_NODES)
+
+#define HVM_MAX_VMEMRANGES    64
+struct hvm_info_vmemrange {
+    uint64_t start;
+    uint64_t end;
+    uint32_t flags;
+    uint32_t nid;
+};
+
 struct hvm_info_table {
     char        signature[8]; /* "HVM INFO" */
     uint32_t    length;
@@ -67,6 +78,14 @@ struct hvm_info_table {
 
     /* Bitmap of which CPUs are online at boot time. */
     uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
+
+    /* Virtual NUMA information */
+    uint32_t    nr_nodes;
+    uint8_t     vcpu_to_vnode[HVM_MAX_VCPUS];
+    uint32_t    nr_vmemranges;
+    struct hvm_info_vmemrange vmemranges[HVM_MAX_VMEMRANGES];
+    uint64_t    nr_localities;
+    uint8_t     localities[HVM_MAX_LOCALITIES];
 };
 
 #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:30:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq9n-00009v-E2; Fri, 21 Nov 2014 15:29:59 +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 1Xrq9m-00009E-6G
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:29:58 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	F1/CF-22819-57A5F645; Fri, 21 Nov 2014 15:29:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416583795!9824110!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31003 invoked from network); 21 Nov 2014 15:29:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:29:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193744465"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:29:04 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XrpnZ-000597-Pq;
	Fri, 21 Nov 2014 15:07:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:06:53 +0000
Message-ID: <1416582421-10789-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 11/19] hvmloader: add new fields for vNUMA
	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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 xen/include/public/hvm/hvm_info_table.h |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/xen/include/public/hvm/hvm_info_table.h b/xen/include/public/hvm/hvm_info_table.h
index 36085fa..9d3f218 100644
--- a/xen/include/public/hvm/hvm_info_table.h
+++ b/xen/include/public/hvm/hvm_info_table.h
@@ -32,6 +32,17 @@
 /* Maximum we can support with current vLAPIC ID mapping. */
 #define HVM_MAX_VCPUS        128
 
+#define HVM_MAX_NODES         16
+#define HVM_MAX_LOCALITIES    (HVM_MAX_NODES * HVM_MAX_NODES)
+
+#define HVM_MAX_VMEMRANGES    64
+struct hvm_info_vmemrange {
+    uint64_t start;
+    uint64_t end;
+    uint32_t flags;
+    uint32_t nid;
+};
+
 struct hvm_info_table {
     char        signature[8]; /* "HVM INFO" */
     uint32_t    length;
@@ -67,6 +78,14 @@ struct hvm_info_table {
 
     /* Bitmap of which CPUs are online at boot time. */
     uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
+
+    /* Virtual NUMA information */
+    uint32_t    nr_nodes;
+    uint8_t     vcpu_to_vnode[HVM_MAX_VCPUS];
+    uint32_t    nr_vmemranges;
+    struct hvm_info_vmemrange vmemranges[HVM_MAX_VMEMRANGES];
+    uint64_t    nr_localities;
+    uint8_t     localities[HVM_MAX_LOCALITIES];
 };
 
 #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:30:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq9o-0000Az-QQ; Fri, 21 Nov 2014 15:30:00 +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 1Xrq9n-00009u-Rw
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:30:00 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	69/47-01660-77A5F645; Fri, 21 Nov 2014 15:29:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416583795!9824110!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31230 invoked from network); 21 Nov 2014 15:29:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:29:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193744490"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:29:39 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1Xrpna-000597-48;
	Fri, 21 Nov 2014 15:07:02 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:07:01 +0000
Message-ID: <1416582421-10789-20-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 19/19] xl: vNUMA support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 includes configuration options parser and documentation.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 docs/man/xl.cfg.pod.5    |   32 ++++++++++
 tools/libxl/xl_cmdimpl.c |  151 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 183 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 622ea53..0394d53 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -266,6 +266,38 @@ it will crash.
 
 =back
 
+=head3 Virtual NUMA Memory Allocation
+
+=over 4
+
+=item B<vnuma_memory=[ NUMBER, NUMBER, ... ]>
+
+Specify the size of memory covered by each virtual NUMA node. The number of
+elements in the list also implicitly defines the number of virtual NUMA nodes.
+
+The sum of all elements in this list should be equal to memory size specified
+by B<maxmem=> in guest configuration file, or B<memory=> if B<maxmem=> is not
+specified.
+
+=item B<vnuma_vcpu_map=[ NUMBER, NUMBER, ... ]>
+
+Specifiy which virutal NUMA node a specific vcpu belongs to. The number of
+elements in this list should be equal to B<maxvcpus=> in guest configuration
+file, or B<vcpus=> if B<maxvcpus=> is not specified.
+
+=item B<vnuma_pnode_map=[ NUMBER, NUMBER, ... ]>
+
+Specifiy which physical NUMA node a specific virtual NUMA node maps to. The
+number of elements in this list should be equal to the number of virtual
+NUMA nodes defined in B<vnuma_memory=>.
+
+=item B<vnuma_vidstance=[ NUMBER, NUMBER ]>
+
+Specify distance from local node to local node and local node to remote node
+respectively. This is optional. If not specified, [10,20] will be used.
+
+=back
+
 =head3 Event Actions
 
 =over 4
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9afef3f..d82e41a 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -904,6 +904,155 @@ static void replace_string(char **str, const char *val)
     *str = xstrdup(val);
 }
 
+static void parse_vnuma_config(const XLU_Config *config,
+                               libxl_domain_build_info *b_info)
+{
+    int i;
+    XLU_ConfigList *vnuma_memory, *vnuma_vcpu_map, *vnuma_pnode_map,
+        *vnuma_vdistances;
+    int num_vnuma_memory, num_vnuma_vcpu_map, num_vnuma_pnode_map,
+        num_vnuma_vdistances;
+    const char *buf;
+    libxl_physinfo physinfo;
+    uint32_t nr_nodes;
+    unsigned long local, remote; /* vdistance */
+    unsigned long val;
+    char *ep;
+
+    libxl_physinfo_init(&physinfo);
+    if (libxl_get_physinfo(ctx, &physinfo) != 0) {
+        libxl_physinfo_dispose(&physinfo);
+        fprintf(stderr, "libxl_physinfo failed.\n");
+        exit(1);
+    }
+    nr_nodes = physinfo.nr_nodes;
+    libxl_physinfo_dispose(&physinfo);
+
+    if (xlu_cfg_get_list(config, "vnuma_memory", &vnuma_memory,
+                         &num_vnuma_memory, 1))
+        return;              /* No vnuma config */
+
+    b_info->num_vnuma_nodes = num_vnuma_memory;
+    b_info->vnuma_nodes = xmalloc(num_vnuma_memory * sizeof(libxl_vnode_info));
+
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        libxl_vnode_info *p = &b_info->vnuma_nodes[i];
+
+        libxl_vnode_info_init(p);
+        libxl_cpu_bitmap_alloc(ctx, &p->vcpus, b_info->max_vcpus);
+        libxl_bitmap_set_none(&p->vcpus);
+        p->distances = xmalloc(b_info->num_vnuma_nodes * sizeof(uint32_t));
+        p->num_distances = b_info->num_vnuma_nodes;
+    }
+
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        buf = xlu_cfg_get_listitem(vnuma_memory, i);
+        val = strtoul(buf, &ep, 10);
+        if (ep == buf) {
+            fprintf(stderr, "xl: Invalid argument parsing vnuma memory: %s\n", buf);
+            exit(1);
+        }
+        b_info->vnuma_nodes[i].mem = val;
+    }
+
+    if (xlu_cfg_get_list(config, "vnuma_vcpu_map", &vnuma_vcpu_map,
+                         &num_vnuma_vcpu_map, 1)) {
+        fprintf(stderr, "No vcpu to vnode map specified\n");
+        exit(1);
+    }
+
+    i = 0;
+    while (i < b_info->max_vcpus &&
+           (buf = xlu_cfg_get_listitem(vnuma_vcpu_map, i)) != NULL) {
+        val = strtoul(buf, &ep, 10);
+        if (ep == buf) {
+            fprintf(stderr, "xl: Invalid argument parsing vcpu map: %s\n", buf);
+            exit(1);
+        }
+        if (val >= num_vnuma_memory) {
+            fprintf(stderr, "xl: Invalid vnode number specified: %lu\n", val);
+            exit(1);
+        }
+        libxl_bitmap_set(&b_info->vnuma_nodes[val].vcpus, i);
+        i++;
+    }
+
+    if (i != b_info->max_vcpus) {
+        fprintf(stderr, "xl: Not enough elements in vnuma_vcpu_map, provided %d, required %d\n",
+                i + 1, b_info->max_vcpus);
+        exit(1);
+    }
+
+    if (xlu_cfg_get_list(config, "vnuma_pnode_map", &vnuma_pnode_map,
+                         &num_vnuma_pnode_map, 1)) {
+        fprintf(stderr, "No vnode to pnode map specified\n");
+        exit(1);
+    }
+
+    i = 0;
+    while (i < num_vnuma_pnode_map &&
+           (buf = xlu_cfg_get_listitem(vnuma_pnode_map, i)) != NULL) {
+        val = strtoul(buf, &ep, 10);
+        if (ep == buf) {
+            fprintf(stderr, "xl: Invalid argument parsing vnode to pnode map: %s\n", buf);
+            exit(1);
+        }
+        if (val >= nr_nodes) {
+            fprintf(stderr, "xl: Invalid pnode number specified: %lu\n", val);
+            exit(1);
+        }
+
+        b_info->vnuma_nodes[i].pnode = val;
+
+        i++;
+    }
+
+    if (i != b_info->num_vnuma_nodes) {
+        fprintf(stderr, "xl: Not enough elements in vnuma_vnode_map, provided %d, required %d\n",
+                i + 1, b_info->num_vnuma_nodes);
+        exit(1);
+    }
+
+    /* Set default values for distances, then try to parse config */
+    local = 10;
+    remote = 20;
+    if (!xlu_cfg_get_list(config, "vnuma_vdistances", &vnuma_vdistances,
+                          &num_vnuma_vdistances, 1)) {
+        if (num_vnuma_vdistances != 2) {
+            fprintf(stderr, "xl: vnuma_vdistances array can only contain 2 elements\n");
+            exit(1);
+        }
+
+        buf = xlu_cfg_get_listitem(vnuma_vdistances, 0);
+        local = strtoul(buf, &ep, 10);
+        if (ep == buf) {
+            fprintf(stderr, "xl: Invalid argument parsing vdistances map: %s\n", buf);
+            exit(1);
+        }
+
+        buf = xlu_cfg_get_listitem(vnuma_vdistances, 1);
+        remote = strtoul(buf, &ep, 10);
+        if (ep == buf) {
+            fprintf(stderr, "xl: Invalid argument parsing vdistances map: %s\n", buf);
+            exit(1);
+        }
+
+    }
+
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        int j;
+        uint32_t *x = b_info->vnuma_nodes[i].distances;
+
+        for (j = 0; j < b_info->vnuma_nodes[i].num_distances; j++) {
+            if (i == j)
+                x[j] = local;
+            else
+                x[j] = remote;
+        }
+    }
+
+}
+
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -1093,6 +1242,8 @@ static void parse_config_data(const char *config_source,
         }
     }
 
+    parse_vnuma_config(config, b_info);
+
     if (!xlu_cfg_get_long(config, "rtc_timeoffset", &l, 0))
         b_info->rtc_timeoffset = l;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:30:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrq9o-0000Az-QQ; Fri, 21 Nov 2014 15:30:00 +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 1Xrq9n-00009u-Rw
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:30:00 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	69/47-01660-77A5F645; Fri, 21 Nov 2014 15:29:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416583795!9824110!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31230 invoked from network); 21 Nov 2014 15:29:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 15:29:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,431,1413244800"; d="scan'208";a="193744490"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 10:29:39 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1Xrpna-000597-48;
	Fri, 21 Nov 2014 15:07:02 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 21 Nov 2014 15:07:01 +0000
Message-ID: <1416582421-10789-20-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: [Xen-devel] [PATCH 19/19] xl: vNUMA support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 includes configuration options parser and documentation.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>
---
 docs/man/xl.cfg.pod.5    |   32 ++++++++++
 tools/libxl/xl_cmdimpl.c |  151 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 183 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 622ea53..0394d53 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -266,6 +266,38 @@ it will crash.
 
 =back
 
+=head3 Virtual NUMA Memory Allocation
+
+=over 4
+
+=item B<vnuma_memory=[ NUMBER, NUMBER, ... ]>
+
+Specify the size of memory covered by each virtual NUMA node. The number of
+elements in the list also implicitly defines the number of virtual NUMA nodes.
+
+The sum of all elements in this list should be equal to memory size specified
+by B<maxmem=> in guest configuration file, or B<memory=> if B<maxmem=> is not
+specified.
+
+=item B<vnuma_vcpu_map=[ NUMBER, NUMBER, ... ]>
+
+Specifiy which virutal NUMA node a specific vcpu belongs to. The number of
+elements in this list should be equal to B<maxvcpus=> in guest configuration
+file, or B<vcpus=> if B<maxvcpus=> is not specified.
+
+=item B<vnuma_pnode_map=[ NUMBER, NUMBER, ... ]>
+
+Specifiy which physical NUMA node a specific virtual NUMA node maps to. The
+number of elements in this list should be equal to the number of virtual
+NUMA nodes defined in B<vnuma_memory=>.
+
+=item B<vnuma_vidstance=[ NUMBER, NUMBER ]>
+
+Specify distance from local node to local node and local node to remote node
+respectively. This is optional. If not specified, [10,20] will be used.
+
+=back
+
 =head3 Event Actions
 
 =over 4
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9afef3f..d82e41a 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -904,6 +904,155 @@ static void replace_string(char **str, const char *val)
     *str = xstrdup(val);
 }
 
+static void parse_vnuma_config(const XLU_Config *config,
+                               libxl_domain_build_info *b_info)
+{
+    int i;
+    XLU_ConfigList *vnuma_memory, *vnuma_vcpu_map, *vnuma_pnode_map,
+        *vnuma_vdistances;
+    int num_vnuma_memory, num_vnuma_vcpu_map, num_vnuma_pnode_map,
+        num_vnuma_vdistances;
+    const char *buf;
+    libxl_physinfo physinfo;
+    uint32_t nr_nodes;
+    unsigned long local, remote; /* vdistance */
+    unsigned long val;
+    char *ep;
+
+    libxl_physinfo_init(&physinfo);
+    if (libxl_get_physinfo(ctx, &physinfo) != 0) {
+        libxl_physinfo_dispose(&physinfo);
+        fprintf(stderr, "libxl_physinfo failed.\n");
+        exit(1);
+    }
+    nr_nodes = physinfo.nr_nodes;
+    libxl_physinfo_dispose(&physinfo);
+
+    if (xlu_cfg_get_list(config, "vnuma_memory", &vnuma_memory,
+                         &num_vnuma_memory, 1))
+        return;              /* No vnuma config */
+
+    b_info->num_vnuma_nodes = num_vnuma_memory;
+    b_info->vnuma_nodes = xmalloc(num_vnuma_memory * sizeof(libxl_vnode_info));
+
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        libxl_vnode_info *p = &b_info->vnuma_nodes[i];
+
+        libxl_vnode_info_init(p);
+        libxl_cpu_bitmap_alloc(ctx, &p->vcpus, b_info->max_vcpus);
+        libxl_bitmap_set_none(&p->vcpus);
+        p->distances = xmalloc(b_info->num_vnuma_nodes * sizeof(uint32_t));
+        p->num_distances = b_info->num_vnuma_nodes;
+    }
+
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        buf = xlu_cfg_get_listitem(vnuma_memory, i);
+        val = strtoul(buf, &ep, 10);
+        if (ep == buf) {
+            fprintf(stderr, "xl: Invalid argument parsing vnuma memory: %s\n", buf);
+            exit(1);
+        }
+        b_info->vnuma_nodes[i].mem = val;
+    }
+
+    if (xlu_cfg_get_list(config, "vnuma_vcpu_map", &vnuma_vcpu_map,
+                         &num_vnuma_vcpu_map, 1)) {
+        fprintf(stderr, "No vcpu to vnode map specified\n");
+        exit(1);
+    }
+
+    i = 0;
+    while (i < b_info->max_vcpus &&
+           (buf = xlu_cfg_get_listitem(vnuma_vcpu_map, i)) != NULL) {
+        val = strtoul(buf, &ep, 10);
+        if (ep == buf) {
+            fprintf(stderr, "xl: Invalid argument parsing vcpu map: %s\n", buf);
+            exit(1);
+        }
+        if (val >= num_vnuma_memory) {
+            fprintf(stderr, "xl: Invalid vnode number specified: %lu\n", val);
+            exit(1);
+        }
+        libxl_bitmap_set(&b_info->vnuma_nodes[val].vcpus, i);
+        i++;
+    }
+
+    if (i != b_info->max_vcpus) {
+        fprintf(stderr, "xl: Not enough elements in vnuma_vcpu_map, provided %d, required %d\n",
+                i + 1, b_info->max_vcpus);
+        exit(1);
+    }
+
+    if (xlu_cfg_get_list(config, "vnuma_pnode_map", &vnuma_pnode_map,
+                         &num_vnuma_pnode_map, 1)) {
+        fprintf(stderr, "No vnode to pnode map specified\n");
+        exit(1);
+    }
+
+    i = 0;
+    while (i < num_vnuma_pnode_map &&
+           (buf = xlu_cfg_get_listitem(vnuma_pnode_map, i)) != NULL) {
+        val = strtoul(buf, &ep, 10);
+        if (ep == buf) {
+            fprintf(stderr, "xl: Invalid argument parsing vnode to pnode map: %s\n", buf);
+            exit(1);
+        }
+        if (val >= nr_nodes) {
+            fprintf(stderr, "xl: Invalid pnode number specified: %lu\n", val);
+            exit(1);
+        }
+
+        b_info->vnuma_nodes[i].pnode = val;
+
+        i++;
+    }
+
+    if (i != b_info->num_vnuma_nodes) {
+        fprintf(stderr, "xl: Not enough elements in vnuma_vnode_map, provided %d, required %d\n",
+                i + 1, b_info->num_vnuma_nodes);
+        exit(1);
+    }
+
+    /* Set default values for distances, then try to parse config */
+    local = 10;
+    remote = 20;
+    if (!xlu_cfg_get_list(config, "vnuma_vdistances", &vnuma_vdistances,
+                          &num_vnuma_vdistances, 1)) {
+        if (num_vnuma_vdistances != 2) {
+            fprintf(stderr, "xl: vnuma_vdistances array can only contain 2 elements\n");
+            exit(1);
+        }
+
+        buf = xlu_cfg_get_listitem(vnuma_vdistances, 0);
+        local = strtoul(buf, &ep, 10);
+        if (ep == buf) {
+            fprintf(stderr, "xl: Invalid argument parsing vdistances map: %s\n", buf);
+            exit(1);
+        }
+
+        buf = xlu_cfg_get_listitem(vnuma_vdistances, 1);
+        remote = strtoul(buf, &ep, 10);
+        if (ep == buf) {
+            fprintf(stderr, "xl: Invalid argument parsing vdistances map: %s\n", buf);
+            exit(1);
+        }
+
+    }
+
+    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
+        int j;
+        uint32_t *x = b_info->vnuma_nodes[i].distances;
+
+        for (j = 0; j < b_info->vnuma_nodes[i].num_distances; j++) {
+            if (i == j)
+                x[j] = local;
+            else
+                x[j] = remote;
+        }
+    }
+
+}
+
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -1093,6 +1242,8 @@ static void parse_config_data(const char *config_source,
         }
     }
 
+    parse_vnuma_config(config, b_info);
+
     if (!xlu_cfg_get_long(config, "rtc_timeoffset", &l, 0))
         b_info->rtc_timeoffset = l;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:39:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1XrqIO-0000v2-II; Fri, 21 Nov 2014 15:38: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 1XrqIN-0000ux-DU
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:38:51 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	96/3B-14727-A8C5F645; Fri, 21 Nov 2014 15:38:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416584330!9355364!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6911 invoked from network); 21 Nov 2014 15:38:50 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 15:38:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 15:38:49 +0000
Message-Id: <546F6A9A0200007800049DCE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 15:38:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <546F4E86.8060801@suse.com>
	<546F60470200007800049D06@mail.emea.novell.com>
	<546F53B8.5040502@citrix.com>
In-Reply-To: <546F53B8.5040502@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
 addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:01, <andrew.cooper3@citrix.com> wrote:
> On 21/11/14 14:54, Jan Beulich wrote:
>>>>> On 21.11.14 at 15:39, <JGross@suse.com> wrote:
>>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>>> wrong device to the domain. The MMIO address was too large for a
>>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>>
>>> Instead of rejecting the operation Xen tried to perform it resulting
>>> in a (quite understandable) failure in the domU.
>>>
>>> I think either the hypervisor or the tools should refuse to do
>>> PCI-passthrough in this case.
>> What's wrong with this large an address?
> 
> It is wider than 44 bits, so doesn't fit in a 32bit pfn for p2m/m2p
> update operations.

MMIO regions don't go into these tables.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:39:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1XrqIO-0000v2-II; Fri, 21 Nov 2014 15:38: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 1XrqIN-0000ux-DU
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:38:51 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	96/3B-14727-A8C5F645; Fri, 21 Nov 2014 15:38:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416584330!9355364!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6911 invoked from network); 21 Nov 2014 15:38:50 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 15:38:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 15:38:49 +0000
Message-Id: <546F6A9A0200007800049DCE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 15:38:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <546F4E86.8060801@suse.com>
	<546F60470200007800049D06@mail.emea.novell.com>
	<546F53B8.5040502@citrix.com>
In-Reply-To: <546F53B8.5040502@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
 addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:01, <andrew.cooper3@citrix.com> wrote:
> On 21/11/14 14:54, Jan Beulich wrote:
>>>>> On 21.11.14 at 15:39, <JGross@suse.com> wrote:
>>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>>> wrong device to the domain. The MMIO address was too large for a
>>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>>
>>> Instead of rejecting the operation Xen tried to perform it resulting
>>> in a (quite understandable) failure in the domU.
>>>
>>> I think either the hypervisor or the tools should refuse to do
>>> PCI-passthrough in this case.
>> What's wrong with this large an address?
> 
> It is wider than 44 bits, so doesn't fit in a 32bit pfn for p2m/m2p
> update operations.

MMIO regions don't go into these tables.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:40:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:40:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrqJt-0000z9-0g; Fri, 21 Nov 2014 15:40:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrqJs-0000z2-3B
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:40:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	65/D0-09936-7EC5F645; Fri, 21 Nov 2014 15:40:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416584420!14473469!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19598 invoked from network); 21 Nov 2014 15:40:21 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:40:21 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 15:40:20 +0000
Message-Id: <546F6AF50200007800049DD1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 15:40:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <546F4E86.8060801@suse.com> <546F60470200007800049D06@suse.com>
	<546F577C.6080207@suse.com>
In-Reply-To: <546F577C.6080207@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
 addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:17, <JGross@suse.com> wrote:
> On 11/21/2014 03:54 PM, Jan Beulich wrote:
>>>>> On 21.11.14 at 15:39, <JGross@suse.com> wrote:
>>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>>> wrong device to the domain. The MMIO address was too large for a
>>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>>
>>> Instead of rejecting the operation Xen tried to perform it resulting
>>> in a (quite understandable) failure in the domU.
>>>
>>> I think either the hypervisor or the tools should refuse to do
>>> PCI-passthrough in this case.
>>
>> What's wrong with this large an address? 32-bit PV uses PAE, i.e.
>> can map them. If the kernel isn't capable of that that's not
>> something to make Xen (or the tools) refuse such assignments. I
>> would only see an issue if a hypercall interface involved here isn't
>> using wide enough fields (but these addresses should be read
>> from the BARs, i.e. no hypercall involved).
> 
> The MFN format is part of the pv-ABI. And a MFN of a 32-bit pv-guest is
> only 32 bits (even if don't take the invalid bit into account).
> 
> Should a pv-guest really be capable to map an address outside it's
> accessible MFN-range?

For MMIO, why not? All that counts there is the page table entry
format.

> Are the tools capable of processing such a mapping in case of saving the
> domain?

MMIO isn't subject to saving/restoring.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:40:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:40:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrqJt-0000z9-0g; Fri, 21 Nov 2014 15:40:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrqJs-0000z2-3B
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:40:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	65/D0-09936-7EC5F645; Fri, 21 Nov 2014 15:40:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416584420!14473469!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19598 invoked from network); 21 Nov 2014 15:40:21 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:40:21 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 15:40:20 +0000
Message-Id: <546F6AF50200007800049DD1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 15:40:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <546F4E86.8060801@suse.com> <546F60470200007800049D06@suse.com>
	<546F577C.6080207@suse.com>
In-Reply-To: <546F577C.6080207@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
 addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:17, <JGross@suse.com> wrote:
> On 11/21/2014 03:54 PM, Jan Beulich wrote:
>>>>> On 21.11.14 at 15:39, <JGross@suse.com> wrote:
>>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>>> wrong device to the domain. The MMIO address was too large for a
>>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>>
>>> Instead of rejecting the operation Xen tried to perform it resulting
>>> in a (quite understandable) failure in the domU.
>>>
>>> I think either the hypervisor or the tools should refuse to do
>>> PCI-passthrough in this case.
>>
>> What's wrong with this large an address? 32-bit PV uses PAE, i.e.
>> can map them. If the kernel isn't capable of that that's not
>> something to make Xen (or the tools) refuse such assignments. I
>> would only see an issue if a hypercall interface involved here isn't
>> using wide enough fields (but these addresses should be read
>> from the BARs, i.e. no hypercall involved).
> 
> The MFN format is part of the pv-ABI. And a MFN of a 32-bit pv-guest is
> only 32 bits (even if don't take the invalid bit into account).
> 
> Should a pv-guest really be capable to map an address outside it's
> accessible MFN-range?

For MMIO, why not? All that counts there is the page table entry
format.

> Are the tools capable of processing such a mapping in case of saving the
> domain?

MMIO isn't subject to saving/restoring.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:48:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1XrqRq-0001Sl-0f; Fri, 21 Nov 2014 15:48:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrqRp-0001Sg-4I
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:48:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A3/05-09842-4DE5F645; Fri, 21 Nov 2014 15:48:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416584913!6431626!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11794 invoked from network); 21 Nov 2014 15:48:35 -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;
	21 Nov 2014 15:48:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193752338"
Message-ID: <546F5ECE.1000903@citrix.com>
Date: Fri, 21 Nov 2014 15:48:30 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
References: <546F4E86.8060801@suse.com>	<546F60470200007800049D06@mail.emea.novell.com>	<546F53B8.5040502@citrix.com>
	<546F6A9A0200007800049DCE@mail.emea.novell.com>
In-Reply-To: <546F6A9A0200007800049DCE@mail.emea.novell.com>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 15:38, Jan Beulich wrote:
>>>> On 21.11.14 at 16:01, <andrew.cooper3@citrix.com> wrote:
>> On 21/11/14 14:54, Jan Beulich wrote:
>>>>>> On 21.11.14 at 15:39, <JGross@suse.com> wrote:
>>>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>>>> wrong device to the domain. The MMIO address was too large for a
>>>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>>>
>>>> Instead of rejecting the operation Xen tried to perform it resulting
>>>> in a (quite understandable) failure in the domU.
>>>>
>>>> I think either the hypervisor or the tools should refuse to do
>>>> PCI-passthrough in this case.
>>> What's wrong with this large an address?
>>
>> It is wider than 44 bits, so doesn't fit in a 32bit pfn for p2m/m2p
>> update operations.
> 
> MMIO regions don't go into these tables.

They do in upstream kernels.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:48:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15: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 1XrqRq-0001Sl-0f; Fri, 21 Nov 2014 15:48:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrqRp-0001Sg-4I
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:48:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A3/05-09842-4DE5F645; Fri, 21 Nov 2014 15:48:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416584913!6431626!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11794 invoked from network); 21 Nov 2014 15:48:35 -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;
	21 Nov 2014 15:48:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193752338"
Message-ID: <546F5ECE.1000903@citrix.com>
Date: Fri, 21 Nov 2014 15:48:30 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
References: <546F4E86.8060801@suse.com>	<546F60470200007800049D06@mail.emea.novell.com>	<546F53B8.5040502@citrix.com>
	<546F6A9A0200007800049DCE@mail.emea.novell.com>
In-Reply-To: <546F6A9A0200007800049DCE@mail.emea.novell.com>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 15:38, Jan Beulich wrote:
>>>> On 21.11.14 at 16:01, <andrew.cooper3@citrix.com> wrote:
>> On 21/11/14 14:54, Jan Beulich wrote:
>>>>>> On 21.11.14 at 15:39, <JGross@suse.com> wrote:
>>>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>>>> wrong device to the domain. The MMIO address was too large for a
>>>> MFN of a 32-bit system (it was 380003200000-3800036fffff).
>>>>
>>>> Instead of rejecting the operation Xen tried to perform it resulting
>>>> in a (quite understandable) failure in the domU.
>>>>
>>>> I think either the hypervisor or the tools should refuse to do
>>>> PCI-passthrough in this case.
>>> What's wrong with this large an address?
>>
>> It is wider than 44 bits, so doesn't fit in a 32bit pfn for p2m/m2p
>> update operations.
> 
> MMIO regions don't go into these tables.

They do in upstream kernels.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:55:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:55:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrqYe-0001ie-4N; Fri, 21 Nov 2014 15:55:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrqYc-0001iZ-Ag
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:55:38 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	95/58-02957-9706F645; Fri, 21 Nov 2014 15:55:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416585336!14065966!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 586 invoked from network); 21 Nov 2014 15:55:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:55:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 15:55:36 +0000
Message-Id: <546F6E890200007800049DF9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 15:55:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
	<20141121151407.GD2886@laptop.dumpdata.com>
In-Reply-To: <20141121151407.GD2886@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 16:14, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 21, 2014 at 01:03:43PM +0100, Jan Beulich wrote:
>> >>> On 21.11.14 at 12:50, <konrad.wilk@oracle.com> wrote:
>> > On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
>> >>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>> >>struct hvm_pirq_dpci *pirq_dpci)
>> >>>      ASSERT(d->arch.hvm_domain.irq.dpci);
>> >>>  
>> >>>      spin_lock(&d->event_lock);
>> >>> -    if ( pirq_dpci->state )
>> >>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
>> >>>      {
>> >>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
>> >>>          const struct dev_intx_gsi_link *digl;
>> >>
>> >>So this now guards solely against the timeout enforced EOI? Why do
>> >>you no longer need to guard against cancellation (i.e. why isn't this
>> >>looking at both ->state and ->masked)?
>> >>
>> > 
>> > The previous state check was superfluous as the dpci_softirq would check for 
>> > the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).
>> 
>> I thought so first too, but then how is the guarding against
>> cancellation working now?
> 
> Since there are two forms of cancellation, lets consider each one seperatly:
> 
> 1). pt_irq_create_bind and pt_irq_destroy_bind. Each of them calling 
>     pt_pirq_softirq_reset in the 'error' case or in the normal path of destruction.
>     When that happens the action handler for the IRQ is removed the moment we call
>     pirq_guest_unbind. As such we only have to deal with the potential outstanding
>     pirq_dpci waiting to be serviced. Since we did the 'pt_pirq_softirq_reset'
>     we have changed the state from STATE_SCHED to zero. That means dpci_softirq will
>     NOT go in:
> 	if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               

Unless the flag got set again in the meantime. Since the event lock
is being acquired right before the line quoted above, _that_ is
what needs closely looking at (and why I was asking about the
deletion of the [at the first glance unnecessary] checking of ->state
in hvm_dirq_assist()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 15:55:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 15:55:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrqYe-0001ie-4N; Fri, 21 Nov 2014 15:55:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrqYc-0001iZ-Ag
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 15:55:38 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	95/58-02957-9706F645; Fri, 21 Nov 2014 15:55:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416585336!14065966!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 586 invoked from network); 21 Nov 2014 15:55:37 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 15:55:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 15:55:36 +0000
Message-Id: <546F6E890200007800049DF9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 15:55:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
	<20141121151407.GD2886@laptop.dumpdata.com>
In-Reply-To: <20141121151407.GD2886@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 16:14, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 21, 2014 at 01:03:43PM +0100, Jan Beulich wrote:
>> >>> On 21.11.14 at 12:50, <konrad.wilk@oracle.com> wrote:
>> > On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
>> >>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>> >>struct hvm_pirq_dpci *pirq_dpci)
>> >>>      ASSERT(d->arch.hvm_domain.irq.dpci);
>> >>>  
>> >>>      spin_lock(&d->event_lock);
>> >>> -    if ( pirq_dpci->state )
>> >>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
>> >>>      {
>> >>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
>> >>>          const struct dev_intx_gsi_link *digl;
>> >>
>> >>So this now guards solely against the timeout enforced EOI? Why do
>> >>you no longer need to guard against cancellation (i.e. why isn't this
>> >>looking at both ->state and ->masked)?
>> >>
>> > 
>> > The previous state check was superfluous as the dpci_softirq would check for 
>> > the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).
>> 
>> I thought so first too, but then how is the guarding against
>> cancellation working now?
> 
> Since there are two forms of cancellation, lets consider each one seperatly:
> 
> 1). pt_irq_create_bind and pt_irq_destroy_bind. Each of them calling 
>     pt_pirq_softirq_reset in the 'error' case or in the normal path of destruction.
>     When that happens the action handler for the IRQ is removed the moment we call
>     pirq_guest_unbind. As such we only have to deal with the potential outstanding
>     pirq_dpci waiting to be serviced. Since we did the 'pt_pirq_softirq_reset'
>     we have changed the state from STATE_SCHED to zero. That means dpci_softirq will
>     NOT go in:
> 	if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               

Unless the flag got set again in the meantime. Since the event lock
is being acquired right before the line quoted above, _that_ is
what needs closely looking at (and why I was asking about the
deletion of the [at the first glance unnecessary] checking of ->state
in hvm_dirq_assist()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:00:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:00:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrqdC-00029w-3L; Fri, 21 Nov 2014 16:00:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrqdA-00029l-To
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 16:00:21 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	4F/FE-25547-4916F645; Fri, 21 Nov 2014 16:00:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416585619!13030707!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15645 invoked from network); 21 Nov 2014 16:00:19 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:00:19 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 16:00:19 +0000
Message-Id: <546F6FA30200007800049E00@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 16:00:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <546F4E86.8060801@suse.com>
	<546F60470200007800049D06@mail.emea.novell.com>
	<546F53B8.5040502@citrix.com>
	<546F6A9A0200007800049DCE@mail.emea.novell.com>
	<546F5ECE.1000903@citrix.com>
In-Reply-To: <546F5ECE.1000903@citrix.com>
Mime-Version: 1.0
Content-Length: 1820
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
 addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDIxLjExLjE0IGF0IDE2OjQ4LCA8ZGF2aWQudnJhYmVsQGNpdHJpeC5jb20+IHdyb3Rl
Ogo+IE9uIDIxLzExLzE0IDE1OjM4LCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4gT24gMjEuMTEu
MTQgYXQgMTY6MDEsIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPiB3cm90ZToKPj4+IE9uIDIx
LzExLzE0IDE0OjU0LCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+PiBPbiAyMS4xMS4xNCBhdCAx
NTozOSwgPEpHcm9zc0BzdXNlLmNvbT4gd3JvdGU6Cj4+Pj4+IFRyeWluZyB0byBkbyBQQ0ktcGFz
c3Rocm91Z2ggd2l0aCBhIDMyLWJpdCBwdi1kb21haW4gSSBwYXNzZWQgdGhlCj4+Pj4+IHdyb25n
IGRldmljZSB0byB0aGUgZG9tYWluLiBUaGUgTU1JTyBhZGRyZXNzIHdhcyB0b28gbGFyZ2UgZm9y
IGEKPj4+Pj4gTUZOIG9mIGEgMzItYml0IHN5c3RlbSAoaXQgd2FzIDM4MDAwMzIwMDAwMC0zODAw
MDM2ZmZmZmYpLgo+Pj4+Pgo+Pj4+PiBJbnN0ZWFkIG9mIHJlamVjdGluZyB0aGUgb3BlcmF0aW9u
IFhlbiB0cmllZCB0byBwZXJmb3JtIGl0IHJlc3VsdGluZwo+Pj4+PiBpbiBhIChxdWl0ZSB1bmRl
cnN0YW5kYWJsZSkgZmFpbHVyZSBpbiB0aGUgZG9tVS4KPj4+Pj4KPj4+Pj4gSSB0aGluayBlaXRo
ZXIgdGhlIGh5cGVydmlzb3Igb3IgdGhlIHRvb2xzIHNob3VsZCByZWZ1c2UgdG8gZG8KPj4+Pj4g
UENJLXBhc3N0aHJvdWdoIGluIHRoaXMgY2FzZS4KPj4+PiBXaGF0J3Mgd3Jvbmcgd2l0aCB0aGlz
IGxhcmdlIGFuIGFkZHJlc3M/Cj4+Pgo+Pj4gSXQgaXMgd2lkZXIgdGhhbiA0NCBiaXRzLCBzbyBk
b2Vzbid0IGZpdCBpbiBhIDMyYml0IHBmbiBmb3IgcDJtL20ycAo+Pj4gdXBkYXRlIG9wZXJhdGlv
bnMuCj4+IAo+PiBNTUlPIHJlZ2lvbnMgZG9uJ3QgZ28gaW50byB0aGVzZSB0YWJsZXMuCj4gCj4g
VGhleSBkbyBpbiB1cHN0cmVhbSBrZXJuZWxzLgoKV2hpY2ggc3RpbGwgaXMgbm8gcmVhc29uIHRv
IG1ha2UgdGhlIGh5cGVydmlzb3Igb3IgdG9vbHMgcmVmdXNlCmFueXRoaW5nIGhlcmUuIEEgY2hl
Y2sgbGlrZSB0aGUgb25lIErDvHJnZW4gaXMgYXNraW5nIGZvciBzaG91bGQKYmUgYWRkZWQgb25s
eSBpZiBzb21ldGhpbmcgaW4gdGhlIHB1YmxpYyBpbnRlcmZhY2UgcHJldmVudHMgdGhpcwpmcm9t
IHdvcmtpbmc7IGV2ZXJ5dGhpbmcgYmV5b25kIHNob3VsZCBiZSBkZWFsdCB3aXRoIGJ5IHRoZQpy
ZXNwZWN0aXZlIGtlcm5lbC4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:00:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:00:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrqdC-00029w-3L; Fri, 21 Nov 2014 16:00:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrqdA-00029l-To
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 16:00:21 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	4F/FE-25547-4916F645; Fri, 21 Nov 2014 16:00:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416585619!13030707!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15645 invoked from network); 21 Nov 2014 16:00:19 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:00:19 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 16:00:19 +0000
Message-Id: <546F6FA30200007800049E00@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 16:00:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <546F4E86.8060801@suse.com>
	<546F60470200007800049D06@mail.emea.novell.com>
	<546F53B8.5040502@citrix.com>
	<546F6A9A0200007800049DCE@mail.emea.novell.com>
	<546F5ECE.1000903@citrix.com>
In-Reply-To: <546F5ECE.1000903@citrix.com>
Mime-Version: 1.0
Content-Length: 1820
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
 addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDIxLjExLjE0IGF0IDE2OjQ4LCA8ZGF2aWQudnJhYmVsQGNpdHJpeC5jb20+IHdyb3Rl
Ogo+IE9uIDIxLzExLzE0IDE1OjM4LCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4gT24gMjEuMTEu
MTQgYXQgMTY6MDEsIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPiB3cm90ZToKPj4+IE9uIDIx
LzExLzE0IDE0OjU0LCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+PiBPbiAyMS4xMS4xNCBhdCAx
NTozOSwgPEpHcm9zc0BzdXNlLmNvbT4gd3JvdGU6Cj4+Pj4+IFRyeWluZyB0byBkbyBQQ0ktcGFz
c3Rocm91Z2ggd2l0aCBhIDMyLWJpdCBwdi1kb21haW4gSSBwYXNzZWQgdGhlCj4+Pj4+IHdyb25n
IGRldmljZSB0byB0aGUgZG9tYWluLiBUaGUgTU1JTyBhZGRyZXNzIHdhcyB0b28gbGFyZ2UgZm9y
IGEKPj4+Pj4gTUZOIG9mIGEgMzItYml0IHN5c3RlbSAoaXQgd2FzIDM4MDAwMzIwMDAwMC0zODAw
MDM2ZmZmZmYpLgo+Pj4+Pgo+Pj4+PiBJbnN0ZWFkIG9mIHJlamVjdGluZyB0aGUgb3BlcmF0aW9u
IFhlbiB0cmllZCB0byBwZXJmb3JtIGl0IHJlc3VsdGluZwo+Pj4+PiBpbiBhIChxdWl0ZSB1bmRl
cnN0YW5kYWJsZSkgZmFpbHVyZSBpbiB0aGUgZG9tVS4KPj4+Pj4KPj4+Pj4gSSB0aGluayBlaXRo
ZXIgdGhlIGh5cGVydmlzb3Igb3IgdGhlIHRvb2xzIHNob3VsZCByZWZ1c2UgdG8gZG8KPj4+Pj4g
UENJLXBhc3N0aHJvdWdoIGluIHRoaXMgY2FzZS4KPj4+PiBXaGF0J3Mgd3Jvbmcgd2l0aCB0aGlz
IGxhcmdlIGFuIGFkZHJlc3M/Cj4+Pgo+Pj4gSXQgaXMgd2lkZXIgdGhhbiA0NCBiaXRzLCBzbyBk
b2Vzbid0IGZpdCBpbiBhIDMyYml0IHBmbiBmb3IgcDJtL20ycAo+Pj4gdXBkYXRlIG9wZXJhdGlv
bnMuCj4+IAo+PiBNTUlPIHJlZ2lvbnMgZG9uJ3QgZ28gaW50byB0aGVzZSB0YWJsZXMuCj4gCj4g
VGhleSBkbyBpbiB1cHN0cmVhbSBrZXJuZWxzLgoKV2hpY2ggc3RpbGwgaXMgbm8gcmVhc29uIHRv
IG1ha2UgdGhlIGh5cGVydmlzb3Igb3IgdG9vbHMgcmVmdXNlCmFueXRoaW5nIGhlcmUuIEEgY2hl
Y2sgbGlrZSB0aGUgb25lIErDvHJnZW4gaXMgYXNraW5nIGZvciBzaG91bGQKYmUgYWRkZWQgb25s
eSBpZiBzb21ldGhpbmcgaW4gdGhlIHB1YmxpYyBpbnRlcmZhY2UgcHJldmVudHMgdGhpcwpmcm9t
IHdvcmtpbmc7IGV2ZXJ5dGhpbmcgYmV5b25kIHNob3VsZCBiZSBkZWFsdCB3aXRoIGJ5IHRoZQpy
ZXNwZWN0aXZlIGtlcm5lbC4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:02:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrqfR-0002Qy-OR; Fri, 21 Nov 2014 16:02:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrqfQ-0002Qe-Om
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 16:02:40 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	D9/D5-17694-0226F645; Fri, 21 Nov 2014 16:02:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416585757!13018351!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29418 invoked from network); 21 Nov 2014 16:02:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 16:02:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193757499"
Message-ID: <546F61EE.90108@citrix.com>
Date: Fri, 21 Nov 2014 16:01:50 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546F4E86.8060801@suse.com>
	<546F60470200007800049D06@mail.emea.novell.com>
	<546F53B8.5040502@citrix.com>
	<546F6A9A0200007800049DCE@mail.emea.novell.com>
	<546F5ECE.1000903@citrix.com>
	<546F6FA30200007800049E00@mail.emea.novell.com>
In-Reply-To: <546F6FA30200007800049E00@mail.emea.novell.com>
Content-Length: 1934
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjEvMTEvMTQgMTY6MDAsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDIxLjExLjE0IGF0
IDE2OjQ4LCA8ZGF2aWQudnJhYmVsQGNpdHJpeC5jb20+IHdyb3RlOgo+PiBPbiAyMS8xMS8xNCAx
NTozOCwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+PiBPbiAyMS4xMS4xNCBhdCAxNjowMSwgPGFu
ZHJldy5jb29wZXIzQGNpdHJpeC5jb20+IHdyb3RlOgo+Pj4+IE9uIDIxLzExLzE0IDE0OjU0LCBK
YW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+Pj4gT24gMjEuMTEuMTQgYXQgMTU6MzksIDxKR3Jvc3NA
c3VzZS5jb20+IHdyb3RlOgo+Pj4+Pj4gVHJ5aW5nIHRvIGRvIFBDSS1wYXNzdGhyb3VnaCB3aXRo
IGEgMzItYml0IHB2LWRvbWFpbiBJIHBhc3NlZCB0aGUKPj4+Pj4+IHdyb25nIGRldmljZSB0byB0
aGUgZG9tYWluLiBUaGUgTU1JTyBhZGRyZXNzIHdhcyB0b28gbGFyZ2UgZm9yIGEKPj4+Pj4+IE1G
TiBvZiBhIDMyLWJpdCBzeXN0ZW0gKGl0IHdhcyAzODAwMDMyMDAwMDAtMzgwMDAzNmZmZmZmKS4K
Pj4+Pj4+Cj4+Pj4+PiBJbnN0ZWFkIG9mIHJlamVjdGluZyB0aGUgb3BlcmF0aW9uIFhlbiB0cmll
ZCB0byBwZXJmb3JtIGl0IHJlc3VsdGluZwo+Pj4+Pj4gaW4gYSAocXVpdGUgdW5kZXJzdGFuZGFi
bGUpIGZhaWx1cmUgaW4gdGhlIGRvbVUuCj4+Pj4+Pgo+Pj4+Pj4gSSB0aGluayBlaXRoZXIgdGhl
IGh5cGVydmlzb3Igb3IgdGhlIHRvb2xzIHNob3VsZCByZWZ1c2UgdG8gZG8KPj4+Pj4+IFBDSS1w
YXNzdGhyb3VnaCBpbiB0aGlzIGNhc2UuCj4+Pj4+IFdoYXQncyB3cm9uZyB3aXRoIHRoaXMgbGFy
Z2UgYW4gYWRkcmVzcz8KPj4+Pgo+Pj4+IEl0IGlzIHdpZGVyIHRoYW4gNDQgYml0cywgc28gZG9l
c24ndCBmaXQgaW4gYSAzMmJpdCBwZm4gZm9yIHAybS9tMnAKPj4+PiB1cGRhdGUgb3BlcmF0aW9u
cy4KPj4+Cj4+PiBNTUlPIHJlZ2lvbnMgZG9uJ3QgZ28gaW50byB0aGVzZSB0YWJsZXMuCj4+Cj4+
IFRoZXkgZG8gaW4gdXBzdHJlYW0ga2VybmVscy4KPiAKPiBXaGljaCBzdGlsbCBpcyBubyByZWFz
b24gdG8gbWFrZSB0aGUgaHlwZXJ2aXNvciBvciB0b29scyByZWZ1c2UKPiBhbnl0aGluZyBoZXJl
LiBBIGNoZWNrIGxpa2UgdGhlIG9uZSBKw7xyZ2VuIGlzIGFza2luZyBmb3Igc2hvdWxkCj4gYmUg
YWRkZWQgb25seSBpZiBzb21ldGhpbmcgaW4gdGhlIHB1YmxpYyBpbnRlcmZhY2UgcHJldmVudHMg
dGhpcwo+IGZyb20gd29ya2luZzsgZXZlcnl0aGluZyBiZXlvbmQgc2hvdWxkIGJlIGRlYWx0IHdp
dGggYnkgdGhlCj4gcmVzcGVjdGl2ZSBrZXJuZWwuCgpJIGFncmVlLgoKRGF2aWQKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:02:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrqfR-0002Qy-OR; Fri, 21 Nov 2014 16:02:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XrqfQ-0002Qe-Om
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 16:02:40 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	D9/D5-17694-0226F645; Fri, 21 Nov 2014 16:02:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416585757!13018351!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29418 invoked from network); 21 Nov 2014 16:02:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 16:02:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193757499"
Message-ID: <546F61EE.90108@citrix.com>
Date: Fri, 21 Nov 2014 16:01:50 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546F4E86.8060801@suse.com>
	<546F60470200007800049D06@mail.emea.novell.com>
	<546F53B8.5040502@citrix.com>
	<546F6A9A0200007800049DCE@mail.emea.novell.com>
	<546F5ECE.1000903@citrix.com>
	<546F6FA30200007800049E00@mail.emea.novell.com>
In-Reply-To: <546F6FA30200007800049E00@mail.emea.novell.com>
Content-Length: 1934
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] PCI-passthrough for 32 bit guests and high MMIO
	addresses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjEvMTEvMTQgMTY6MDAsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDIxLjExLjE0IGF0
IDE2OjQ4LCA8ZGF2aWQudnJhYmVsQGNpdHJpeC5jb20+IHdyb3RlOgo+PiBPbiAyMS8xMS8xNCAx
NTozOCwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+PiBPbiAyMS4xMS4xNCBhdCAxNjowMSwgPGFu
ZHJldy5jb29wZXIzQGNpdHJpeC5jb20+IHdyb3RlOgo+Pj4+IE9uIDIxLzExLzE0IDE0OjU0LCBK
YW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+Pj4gT24gMjEuMTEuMTQgYXQgMTU6MzksIDxKR3Jvc3NA
c3VzZS5jb20+IHdyb3RlOgo+Pj4+Pj4gVHJ5aW5nIHRvIGRvIFBDSS1wYXNzdGhyb3VnaCB3aXRo
IGEgMzItYml0IHB2LWRvbWFpbiBJIHBhc3NlZCB0aGUKPj4+Pj4+IHdyb25nIGRldmljZSB0byB0
aGUgZG9tYWluLiBUaGUgTU1JTyBhZGRyZXNzIHdhcyB0b28gbGFyZ2UgZm9yIGEKPj4+Pj4+IE1G
TiBvZiBhIDMyLWJpdCBzeXN0ZW0gKGl0IHdhcyAzODAwMDMyMDAwMDAtMzgwMDAzNmZmZmZmKS4K
Pj4+Pj4+Cj4+Pj4+PiBJbnN0ZWFkIG9mIHJlamVjdGluZyB0aGUgb3BlcmF0aW9uIFhlbiB0cmll
ZCB0byBwZXJmb3JtIGl0IHJlc3VsdGluZwo+Pj4+Pj4gaW4gYSAocXVpdGUgdW5kZXJzdGFuZGFi
bGUpIGZhaWx1cmUgaW4gdGhlIGRvbVUuCj4+Pj4+Pgo+Pj4+Pj4gSSB0aGluayBlaXRoZXIgdGhl
IGh5cGVydmlzb3Igb3IgdGhlIHRvb2xzIHNob3VsZCByZWZ1c2UgdG8gZG8KPj4+Pj4+IFBDSS1w
YXNzdGhyb3VnaCBpbiB0aGlzIGNhc2UuCj4+Pj4+IFdoYXQncyB3cm9uZyB3aXRoIHRoaXMgbGFy
Z2UgYW4gYWRkcmVzcz8KPj4+Pgo+Pj4+IEl0IGlzIHdpZGVyIHRoYW4gNDQgYml0cywgc28gZG9l
c24ndCBmaXQgaW4gYSAzMmJpdCBwZm4gZm9yIHAybS9tMnAKPj4+PiB1cGRhdGUgb3BlcmF0aW9u
cy4KPj4+Cj4+PiBNTUlPIHJlZ2lvbnMgZG9uJ3QgZ28gaW50byB0aGVzZSB0YWJsZXMuCj4+Cj4+
IFRoZXkgZG8gaW4gdXBzdHJlYW0ga2VybmVscy4KPiAKPiBXaGljaCBzdGlsbCBpcyBubyByZWFz
b24gdG8gbWFrZSB0aGUgaHlwZXJ2aXNvciBvciB0b29scyByZWZ1c2UKPiBhbnl0aGluZyBoZXJl
LiBBIGNoZWNrIGxpa2UgdGhlIG9uZSBKw7xyZ2VuIGlzIGFza2luZyBmb3Igc2hvdWxkCj4gYmUg
YWRkZWQgb25seSBpZiBzb21ldGhpbmcgaW4gdGhlIHB1YmxpYyBpbnRlcmZhY2UgcHJldmVudHMg
dGhpcwo+IGZyb20gd29ya2luZzsgZXZlcnl0aGluZyBiZXlvbmQgc2hvdWxkIGJlIGRlYWx0IHdp
dGggYnkgdGhlCj4gcmVzcGVjdGl2ZSBrZXJuZWwuCgpJIGFncmVlLgoKRGF2aWQKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:25:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:25:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrr1d-00036j-0n; Fri, 21 Nov 2014 16:25:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrr1b-00036e-CW
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:25:35 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	BD/C8-07724-E776F645; Fri, 21 Nov 2014 16:25:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416587133!13022443!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23634 invoked from network); 21 Nov 2014 16:25:33 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:25:33 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 16:25:33 +0000
Message-Id: <546F758E0200007800049E30@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 16:25:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/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.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> memory = 6000
> vnuma_memory = [3000, 3000]

So what would

memory = 6000
vnuma_memory = [3000, 2000]

or

memory = 6000
vnuma_memory = [3000, 4000]

mean? Redundant specification of values is always a problem...
Would be possible to extend "memory" to allow for a vector as well
as a single value?

> vnuma_vcpu_map = [0, 1]
> vnuma_pnode_map = [0, 0]
> vnuma_vdistances = [10, 30] # optional

Being optional, would the real distances be used instead? And what
meaning does this apparently one dimensional array here have for
the actually two dimensional SLIT? (Read: An example with more
than two nodes would be useful.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:25:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:25:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrr1d-00036j-0n; Fri, 21 Nov 2014 16:25:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrr1b-00036e-CW
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:25:35 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	BD/C8-07724-E776F645; Fri, 21 Nov 2014 16:25:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416587133!13022443!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23634 invoked from network); 21 Nov 2014 16:25:33 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:25:33 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 16:25:33 +0000
Message-Id: <546F758E0200007800049E30@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 16:25:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/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.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> memory = 6000
> vnuma_memory = [3000, 3000]

So what would

memory = 6000
vnuma_memory = [3000, 2000]

or

memory = 6000
vnuma_memory = [3000, 4000]

mean? Redundant specification of values is always a problem...
Would be possible to extend "memory" to allow for a vector as well
as a single value?

> vnuma_vcpu_map = [0, 1]
> vnuma_pnode_map = [0, 0]
> vnuma_vdistances = [10, 30] # optional

Being optional, would the real distances be used instead? And what
meaning does this apparently one dimensional array here have for
the actually two dimensional SLIT? (Read: An example with more
than two nodes would be useful.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:26:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrr2V-00039p-Ey; Fri, 21 Nov 2014 16:26:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xrr2T-00039c-DJ
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:26:29 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	05/41-08051-4B76F645; Fri, 21 Nov 2014 16:26:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416587186!13485473!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32690 invoked from network); 21 Nov 2014 16:26:28 -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;
	21 Nov 2014 16:26:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193767392"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:25:55 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xrr1v-0006OH-Ho;
	Fri, 21 Nov 2014 16:25:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xrr1v-0005D9-9q;
	Fri, 21 Nov 2014 16:25:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21615.26514.841362.847055@mariner.uk.xensource.com>
Date: Fri, 21 Nov 2014 16:25:54 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1416575824-15555-1-git-send-email-ian.campbell@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
	<1416575824-15555-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 01/15] standalone: Introduce
	"HostGroups" for use in OSSTEST_CONFIG
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH OSSTEST v3 01/15] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG"):
> This saves repeating identical HostProp and HostFlags for sets of identical
> machines. e.g.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:26:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrr2V-00039p-Ey; Fri, 21 Nov 2014 16:26:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xrr2T-00039c-DJ
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:26:29 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	05/41-08051-4B76F645; Fri, 21 Nov 2014 16:26:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416587186!13485473!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32690 invoked from network); 21 Nov 2014 16:26:28 -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;
	21 Nov 2014 16:26:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193767392"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:25:55 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xrr1v-0006OH-Ho;
	Fri, 21 Nov 2014 16:25:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xrr1v-0005D9-9q;
	Fri, 21 Nov 2014 16:25:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21615.26514.841362.847055@mariner.uk.xensource.com>
Date: Fri, 21 Nov 2014 16:25:54 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1416575824-15555-1-git-send-email-ian.campbell@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
	<1416575824-15555-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 01/15] standalone: Introduce
	"HostGroups" for use in OSSTEST_CONFIG
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH OSSTEST v3 01/15] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG"):
> This saves repeating identical HostProp and HostFlags for sets of identical
> machines. e.g.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:27:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrr31-0003DZ-Rh; Fri, 21 Nov 2014 16:27:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xrr30-0003DN-Pu
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:27:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BC/81-09842-6D76F645; Fri, 21 Nov 2014 16:27:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416587219!7173566!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18322 invoked from network); 21 Nov 2014 16:27:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 16:27:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193767759"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:26:56 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xrr2u-0006P9-CN;
	Fri, 21 Nov 2014 16:26:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xrr2t-0005DQ-Ta;
	Fri, 21 Nov 2014 16:26:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21615.26575.341786.22359@mariner.uk.xensource.com>
Date: Fri, 21 Nov 2014 16:26:55 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1416575824-15555-2-git-send-email-ian.campbell@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
	<1416575824-15555-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 02/15] ts-kernel-build: enable
	CONFIG_IKCONFIG{_PROC}
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH OSSTEST v3 02/15] ts-kernel-build: enable CONFIG_IKCONFIG{_PROC}"):
> This makes the kernel's .config available in /proc/config.gz and embeds a co\
py
> which can be extracted with linux/scripts/extract-ikconfig (which I've not
> tried, but have no reason to doubt).

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(But, can you make your editor produce commit messages which are less
than 70-75 columns wide, so they don't get wrap damage when I reply?)

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:27:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrr31-0003DZ-Rh; Fri, 21 Nov 2014 16:27:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xrr30-0003DN-Pu
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:27:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BC/81-09842-6D76F645; Fri, 21 Nov 2014 16:27:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416587219!7173566!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18322 invoked from network); 21 Nov 2014 16:27:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 16:27:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193767759"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:26:56 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xrr2u-0006P9-CN;
	Fri, 21 Nov 2014 16:26:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xrr2t-0005DQ-Ta;
	Fri, 21 Nov 2014 16:26:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21615.26575.341786.22359@mariner.uk.xensource.com>
Date: Fri, 21 Nov 2014 16:26:55 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1416575824-15555-2-git-send-email-ian.campbell@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
	<1416575824-15555-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 02/15] ts-kernel-build: enable
	CONFIG_IKCONFIG{_PROC}
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH OSSTEST v3 02/15] ts-kernel-build: enable CONFIG_IKCONFIG{_PROC}"):
> This makes the kernel's .config available in /proc/config.gz and embeds a co\
py
> which can be extracted with linux/scripts/extract-ikconfig (which I've not
> tried, but have no reason to doubt).

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(But, can you make your editor produce commit messages which are less
than 70-75 columns wide, so they don't get wrap damage when I reply?)

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:31:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:31:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrr77-0003U8-Hg; Fri, 21 Nov 2014 16:31:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xrr76-0003U3-IA
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:31:16 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	60/FC-03145-3D86F645; Fri, 21 Nov 2014 16:31:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416587473!14025579!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12018 invoked from network); 21 Nov 2014 16:31:15 -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;
	21 Nov 2014 16:31:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193768915"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:30:48 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xrr6e-0006Rz-E0;
	Fri, 21 Nov 2014 16:30:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xrr6d-0005EF-UE;
	Fri, 21 Nov 2014 16:30:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21615.26807.571099.632254@mariner.uk.xensource.com>
Date: Fri, 21 Nov 2014 16:30:47 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1416575824-15555-4-git-send-email-ian.campbell@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
	<1416575824-15555-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/15] make-flight: Run a basic
	test on each arm platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH OSSTEST v3 04/15] make-flight: Run a basic test on each arm platform"):
> Unlike x86 there is enough variation in the ARM platforms that it is
> worth having a basic test on each as part of a standard run. This
> relies on each host having an appropriate platform-$platform host
> flag.

Commit message rewrapped so I can quote it.

I have just noticed, looking at some of your actual patches in
osstest.git, that `git log' has wrap damage in an 80-column xterm.

Would it be too much to ask you to go through this series and rewrap
the commit messages ?

Aside from that,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:31:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:31:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrr77-0003U8-Hg; Fri, 21 Nov 2014 16:31:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xrr76-0003U3-IA
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:31:16 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	60/FC-03145-3D86F645; Fri, 21 Nov 2014 16:31:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416587473!14025579!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12018 invoked from network); 21 Nov 2014 16:31:15 -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;
	21 Nov 2014 16:31:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193768915"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:30:48 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xrr6e-0006Rz-E0;
	Fri, 21 Nov 2014 16:30:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xrr6d-0005EF-UE;
	Fri, 21 Nov 2014 16:30:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21615.26807.571099.632254@mariner.uk.xensource.com>
Date: Fri, 21 Nov 2014 16:30:47 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1416575824-15555-4-git-send-email-ian.campbell@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
	<1416575824-15555-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/15] make-flight: Run a basic
	test on each arm platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH OSSTEST v3 04/15] make-flight: Run a basic test on each arm platform"):
> Unlike x86 there is enough variation in the ARM platforms that it is
> worth having a basic test on each as part of a standard run. This
> relies on each host having an appropriate platform-$platform host
> flag.

Commit message rewrapped so I can quote it.

I have just noticed, looking at some of your actual patches in
osstest.git, that `git log' has wrap damage in an 80-column xterm.

Would it be too much to ask you to go through this series and rewrap
the commit messages ?

Aside from that,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:31:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrr7g-0003XG-UX; Fri, 21 Nov 2014 16:31:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xrr7e-0003X0-RR
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 16:31:51 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	84/9D-03145-6F86F645; Fri, 21 Nov 2014 16:31:50 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416587507!8635081!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5211 invoked from network); 21 Nov 2014 16:31:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 16:31:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195303813"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:31:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xrr7L-0006Sv-On;
	Fri, 21 Nov 2014 16:31:31 +0000
Date: Fri, 21 Nov 2014 16:31:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1415792454-23161-10-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1411211617090.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-10-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 10/13] xen/arm/arm64: introduce
 xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Nov 2014, Stefano Stabellini wrote:
> Introduce an arch specific function to find out whether a particular dma
> mapping operation needs to bounce on the swiotlb buffer.
> 
> On ARM and ARM64, if the page involved is a foreign page and the device
> is not coherent, we need to bounce because at unmap time we cannot
> execute any required cache maintenance operations (we don't know how to
> find the pfn from the mfn).
> 
> No change of behaviour for x86.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

I am thinking of asking a backport of this patch to 3.16+

The catch is that is_device_dma_coherent is not available on older
kernels, so I'll have to change the arm implementation of
xen_arch_need_swiotlb to:

+bool xen_arch_need_swiotlb(struct device *dev,
+			   unsigned long pfn,
+			   unsigned long mfn)
+{
+	return pfn != mfn;
+}
+

It is going to make things slower but it is going to fix the issue with
cache flushing buffers for non-coherent devices.

Konrad, are you OK with that?


> Changes in v6:
> - fix ts.
> 
> Changes in v5:
> - fix indentation.
> ---
>  arch/arm/include/asm/xen/page.h |    4 ++++
>  arch/arm/xen/mm.c               |    7 +++++++
>  arch/x86/include/asm/xen/page.h |    7 +++++++
>  drivers/xen/swiotlb-xen.c       |    5 ++++-
>  4 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 135c24a..68c739b 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn);
> +
>  #endif /* _ASM_ARM_XEN_PAGE_H */
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index ab700e1..28ebf3e 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -100,6 +100,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
>  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
>  }
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn)
> +{
> +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> +}
> +
>  int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
>  				 unsigned int address_bits,
>  				 dma_addr_t *dma_handle)
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index c949923..f58ef6c 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
>  #define xen_remap(cookie, size) ioremap((cookie), (size));
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +static inline bool xen_arch_need_swiotlb(struct device *dev,
> +					 unsigned long pfn,
> +					 unsigned long mfn)
> +{
> +	return false;
> +}
> +
>  #endif /* _ASM_X86_XEN_PAGE_H */
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ad2c5eb..3725ee4 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
>  	 * buffering it.
>  	 */
>  	if (dma_capable(dev, dev_addr, size) &&
> -	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
> +	    !range_straddles_page_boundary(phys, size) &&
> +		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
> +		!swiotlb_force) {
>  		/* we are not interested in the dma_addr returned by
>  		 * xen_dma_map_page, only in the potential cache flushes executed
>  		 * by the function. */
> @@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>  		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
>  
>  		if (swiotlb_force ||
> +		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
>  		    !dma_capable(hwdev, dev_addr, sg->length) ||
>  		    range_straddles_page_boundary(paddr, sg->length)) {
>  			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:31:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrr7g-0003XG-UX; Fri, 21 Nov 2014 16:31:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xrr7e-0003X0-RR
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 16:31:51 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	84/9D-03145-6F86F645; Fri, 21 Nov 2014 16:31:50 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416587507!8635081!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5211 invoked from network); 21 Nov 2014 16:31:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 16:31:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195303813"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:31:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xrr7L-0006Sv-On;
	Fri, 21 Nov 2014 16:31:31 +0000
Date: Fri, 21 Nov 2014 16:31:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1415792454-23161-10-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1411211617090.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-10-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 10/13] xen/arm/arm64: introduce
 xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Nov 2014, Stefano Stabellini wrote:
> Introduce an arch specific function to find out whether a particular dma
> mapping operation needs to bounce on the swiotlb buffer.
> 
> On ARM and ARM64, if the page involved is a foreign page and the device
> is not coherent, we need to bounce because at unmap time we cannot
> execute any required cache maintenance operations (we don't know how to
> find the pfn from the mfn).
> 
> No change of behaviour for x86.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

I am thinking of asking a backport of this patch to 3.16+

The catch is that is_device_dma_coherent is not available on older
kernels, so I'll have to change the arm implementation of
xen_arch_need_swiotlb to:

+bool xen_arch_need_swiotlb(struct device *dev,
+			   unsigned long pfn,
+			   unsigned long mfn)
+{
+	return pfn != mfn;
+}
+

It is going to make things slower but it is going to fix the issue with
cache flushing buffers for non-coherent devices.

Konrad, are you OK with that?


> Changes in v6:
> - fix ts.
> 
> Changes in v5:
> - fix indentation.
> ---
>  arch/arm/include/asm/xen/page.h |    4 ++++
>  arch/arm/xen/mm.c               |    7 +++++++
>  arch/x86/include/asm/xen/page.h |    7 +++++++
>  drivers/xen/swiotlb-xen.c       |    5 ++++-
>  4 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 135c24a..68c739b 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn);
> +
>  #endif /* _ASM_ARM_XEN_PAGE_H */
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index ab700e1..28ebf3e 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -100,6 +100,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
>  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
>  }
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn)
> +{
> +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> +}
> +
>  int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
>  				 unsigned int address_bits,
>  				 dma_addr_t *dma_handle)
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index c949923..f58ef6c 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
>  #define xen_remap(cookie, size) ioremap((cookie), (size));
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +static inline bool xen_arch_need_swiotlb(struct device *dev,
> +					 unsigned long pfn,
> +					 unsigned long mfn)
> +{
> +	return false;
> +}
> +
>  #endif /* _ASM_X86_XEN_PAGE_H */
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ad2c5eb..3725ee4 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
>  	 * buffering it.
>  	 */
>  	if (dma_capable(dev, dev_addr, size) &&
> -	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
> +	    !range_straddles_page_boundary(phys, size) &&
> +		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
> +		!swiotlb_force) {
>  		/* we are not interested in the dma_addr returned by
>  		 * xen_dma_map_page, only in the potential cache flushes executed
>  		 * by the function. */
> @@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>  		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
>  
>  		if (swiotlb_force ||
> +		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
>  		    !dma_capable(hwdev, dev_addr, sg->length) ||
>  		    range_straddles_page_boundary(paddr, sg->length)) {
>  			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:35:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16: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 1XrrBJ-0003tI-P7; Fri, 21 Nov 2014 16:35: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 1XrrBI-0003tB-Gq
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:35:36 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A0/FD-17735-7D96F645; Fri, 21 Nov 2014 16:35:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416587733!12998385!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12471 invoked from network); 21 Nov 2014 16:35:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 16:35:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195305376"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:35:31 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrrBD-0006Vf-AH;
	Fri, 21 Nov 2014 16:35:31 +0000
Date: Fri, 21 Nov 2014 16:35:31 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121163531.GA16712@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<546F758E0200007800049E30@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F758E0200007800049E30@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 04:25:34PM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> > memory = 6000
> > vnuma_memory = [3000, 3000]
> 
> So what would
> 
> memory = 6000
> vnuma_memory = [3000, 2000]
> 
> or
> 
> memory = 6000
> vnuma_memory = [3000, 4000]
> 

Those are not valid configurations at the moment. I have checks in libxl
to mandate sum of vnuma_memory equals to memory (in fact, maxmem).

> mean? Redundant specification of values is always a problem...
> Would be possible to extend "memory" to allow for a vector as well
> as a single value?
> 

Yes, I think it can be done in backward compatible way.

> > vnuma_vcpu_map = [0, 1]
> > vnuma_pnode_map = [0, 0]
> > vnuma_vdistances = [10, 30] # optional
> 
> Being optional, would the real distances be used instead? And what

Default value of [10, 20] will be used.

> meaning does this apparently one dimensional array here have for
> the actually two dimensional SLIT? (Read: An example with more
> than two nodes would be useful.)
> 

The first element of [X, Y] is local distance, the second element is
remote distance.

For a 4 node system:

     0    1    2    3
0    X    Y    Y    Y 
1    Y    X    Y    Y
2    Y    Y    X    Y
3    Y    Y    Y    X

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:35:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16: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 1XrrBJ-0003tI-P7; Fri, 21 Nov 2014 16:35: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 1XrrBI-0003tB-Gq
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:35:36 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A0/FD-17735-7D96F645; Fri, 21 Nov 2014 16:35:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416587733!12998385!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12471 invoked from network); 21 Nov 2014 16:35:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 16:35:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195305376"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:35:31 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrrBD-0006Vf-AH;
	Fri, 21 Nov 2014 16:35:31 +0000
Date: Fri, 21 Nov 2014 16:35:31 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121163531.GA16712@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<546F758E0200007800049E30@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F758E0200007800049E30@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 04:25:34PM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> > memory = 6000
> > vnuma_memory = [3000, 3000]
> 
> So what would
> 
> memory = 6000
> vnuma_memory = [3000, 2000]
> 
> or
> 
> memory = 6000
> vnuma_memory = [3000, 4000]
> 

Those are not valid configurations at the moment. I have checks in libxl
to mandate sum of vnuma_memory equals to memory (in fact, maxmem).

> mean? Redundant specification of values is always a problem...
> Would be possible to extend "memory" to allow for a vector as well
> as a single value?
> 

Yes, I think it can be done in backward compatible way.

> > vnuma_vcpu_map = [0, 1]
> > vnuma_pnode_map = [0, 0]
> > vnuma_vdistances = [10, 30] # optional
> 
> Being optional, would the real distances be used instead? And what

Default value of [10, 20] will be used.

> meaning does this apparently one dimensional array here have for
> the actually two dimensional SLIT? (Read: An example with more
> than two nodes would be useful.)
> 

The first element of [X, Y] is local distance, the second element is
remote distance.

For a 4 node system:

     0    1    2    3
0    X    Y    Y    Y 
1    Y    X    Y    Y
2    Y    Y    X    Y
3    Y    Y    Y    X

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:39:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16: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 1XrrFK-00041s-F9; Fri, 21 Nov 2014 16:39:46 +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 1XrrFJ-00041l-ET
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:39:45 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F4/6F-08051-0DA6F645; Fri, 21 Nov 2014 16:39:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416587983!14062920!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11614 invoked from network); 21 Nov 2014 16:39:44 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:39:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 16:39:43 +0000
Message-Id: <546F78E10200007800049E5A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 16:39:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-2-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-2-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Elena Ufimsteva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 01/19] xen: dump vNUMA information with
 debug key "u"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> Signed-off-by: Elena Ufimsteva <ufimtseva@gmail.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> ---
>  xen/arch/x86/numa.c |   46 +++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
> index 628a40a..d27c30f 100644
> --- a/xen/arch/x86/numa.c
> +++ b/xen/arch/x86/numa.c
> @@ -363,10 +363,12 @@ EXPORT_SYMBOL(node_data);
>  static void dump_numa(unsigned char key)
>  {
>      s_time_t now = NOW();
> -    int i;
> +    int i, j, err, n;

unsigned int please for all but err.

> @@ -408,6 +410,48 @@ static void dump_numa(unsigned char key)
>  
>          for_each_online_node ( i )
>              printk("    Node %u: %u\n", i, page_num_node[i]);
> +
> +        if ( !d->vnuma )
> +                continue;
> +
> +        vnuma = d->vnuma;
> +        printk("     %u vnodes, %u vcpus\n", vnuma->nr_vnodes, d->max_vcpus);
> +        for ( i = 0; i < vnuma->nr_vnodes; i++ )
> +        {
> +            err = snprintf(keyhandler_scratch, 12, "%u",
> +                    vnuma->vnode_to_pnode[i]);
> +            if ( err < 0 || vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
> +                snprintf(keyhandler_scratch, 3, "???");

strcpy() would be much cheaper here.

> +
> +            printk("       vnode %3u - pnode %s\n", i, keyhandler_scratch);
> +            for ( j = 0; j < vnuma->nr_vmemranges; j++ )
> +            {
> +                if ( vnuma->vmemrange[j].nid == i )
> +                {
> +                    mem = vnuma->vmemrange[j].end - vnuma->vmemrange[j].start;
> +                    printk("        %"PRIu64" MB: ", mem >> 20);
> +                    printk(" 0x%"PRIx64" - 0x%"PRIx64"\n",
> +                           vnuma->vmemrange[j].start,
> +                           vnuma->vmemrange[j].end);

Where possible please don't split printk()s of a single output line. Also
%# instead of 0x% please (but maybe padding the values so the
align properly would be the better change; that would also eliminate
the need for explicit leading spaces).

> +                }
> +            }
> +
> +            printk("        vcpus: ");
> +            for ( j = 0, n = 0; j < d->max_vcpus; j++ )
> +            {
> +                if ( vnuma->vcpu_to_vnode[j] == i )
> +                {
> +                    if ( (n + 1) % 8 == 0 )
> +                        printk("%d\n", j);
> +                    else if ( !(n % 8) && n != 0 )
> +                        printk("                %d ", j);
> +                    else
> +                        printk("%d ", j);

Same here - left padding them to make them aligned will likely make
the result quite a bit easier to grok especially for large guests.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:39:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16: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 1XrrFK-00041s-F9; Fri, 21 Nov 2014 16:39:46 +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 1XrrFJ-00041l-ET
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:39:45 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F4/6F-08051-0DA6F645; Fri, 21 Nov 2014 16:39:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416587983!14062920!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11614 invoked from network); 21 Nov 2014 16:39:44 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:39:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 16:39:43 +0000
Message-Id: <546F78E10200007800049E5A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 16:39:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-2-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-2-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Elena Ufimsteva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 01/19] xen: dump vNUMA information with
 debug key "u"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> Signed-off-by: Elena Ufimsteva <ufimtseva@gmail.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> ---
>  xen/arch/x86/numa.c |   46 +++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
> index 628a40a..d27c30f 100644
> --- a/xen/arch/x86/numa.c
> +++ b/xen/arch/x86/numa.c
> @@ -363,10 +363,12 @@ EXPORT_SYMBOL(node_data);
>  static void dump_numa(unsigned char key)
>  {
>      s_time_t now = NOW();
> -    int i;
> +    int i, j, err, n;

unsigned int please for all but err.

> @@ -408,6 +410,48 @@ static void dump_numa(unsigned char key)
>  
>          for_each_online_node ( i )
>              printk("    Node %u: %u\n", i, page_num_node[i]);
> +
> +        if ( !d->vnuma )
> +                continue;
> +
> +        vnuma = d->vnuma;
> +        printk("     %u vnodes, %u vcpus\n", vnuma->nr_vnodes, d->max_vcpus);
> +        for ( i = 0; i < vnuma->nr_vnodes; i++ )
> +        {
> +            err = snprintf(keyhandler_scratch, 12, "%u",
> +                    vnuma->vnode_to_pnode[i]);
> +            if ( err < 0 || vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
> +                snprintf(keyhandler_scratch, 3, "???");

strcpy() would be much cheaper here.

> +
> +            printk("       vnode %3u - pnode %s\n", i, keyhandler_scratch);
> +            for ( j = 0; j < vnuma->nr_vmemranges; j++ )
> +            {
> +                if ( vnuma->vmemrange[j].nid == i )
> +                {
> +                    mem = vnuma->vmemrange[j].end - vnuma->vmemrange[j].start;
> +                    printk("        %"PRIu64" MB: ", mem >> 20);
> +                    printk(" 0x%"PRIx64" - 0x%"PRIx64"\n",
> +                           vnuma->vmemrange[j].start,
> +                           vnuma->vmemrange[j].end);

Where possible please don't split printk()s of a single output line. Also
%# instead of 0x% please (but maybe padding the values so the
align properly would be the better change; that would also eliminate
the need for explicit leading spaces).

> +                }
> +            }
> +
> +            printk("        vcpus: ");
> +            for ( j = 0, n = 0; j < d->max_vcpus; j++ )
> +            {
> +                if ( vnuma->vcpu_to_vnode[j] == i )
> +                {
> +                    if ( (n + 1) % 8 == 0 )
> +                        printk("%d\n", j);
> +                    else if ( !(n % 8) && n != 0 )
> +                        printk("                %d ", j);
> +                    else
> +                        printk("%d ", j);

Same here - left padding them to make them aligned will likely make
the result quite a bit easier to grok especially for large guests.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:42:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:42:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrHe-00048y-5X; Fri, 21 Nov 2014 16:42:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrrHc-00048Z-BK
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:42:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	05/47-09842-F5B6F645; Fri, 21 Nov 2014 16:42:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416588127!14505261!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21324 invoked from network); 21 Nov 2014 16:42:07 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:42:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 16:42:06 +0000
Message-Id: <546F796F0200007800049E5D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 16:42:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<546F758E0200007800049E30@mail.emea.novell.com>
	<20141121163531.GA16712@zion.uk.xensource.com>
In-Reply-To: <20141121163531.GA16712@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/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.11.14 at 17:35, <wei.liu2@citrix.com> wrote:
> On Fri, Nov 21, 2014 at 04:25:34PM +0000, Jan Beulich wrote:
>> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
>> > vnuma_vdistances = [10, 30] # optional
>> 
>> Being optional, would the real distances be used instead? And what
> 
> Default value of [10, 20] will be used.

That's bad. Would it be very difficult to use the host values?

>> meaning does this apparently one dimensional array here have for
>> the actually two dimensional SLIT? (Read: An example with more
>> than two nodes would be useful.)
>> 
> 
> The first element of [X, Y] is local distance, the second element is
> remote distance.
> 
> For a 4 node system:
> 
>      0    1    2    3
> 0    X    Y    Y    Y 
> 1    Y    X    Y    Y
> 2    Y    Y    X    Y
> 3    Y    Y    Y    X

That may match up with how most current NUMA systems look like,
but do we really want to bake in an oversimplification like this?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:42:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:42:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrHe-00048y-5X; Fri, 21 Nov 2014 16:42:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XrrHc-00048Z-BK
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:42:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	05/47-09842-F5B6F645; Fri, 21 Nov 2014 16:42:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416588127!14505261!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21324 invoked from network); 21 Nov 2014 16:42:07 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:42:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 16:42:06 +0000
Message-Id: <546F796F0200007800049E5D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 16:42:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<546F758E0200007800049E30@mail.emea.novell.com>
	<20141121163531.GA16712@zion.uk.xensource.com>
In-Reply-To: <20141121163531.GA16712@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/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.11.14 at 17:35, <wei.liu2@citrix.com> wrote:
> On Fri, Nov 21, 2014 at 04:25:34PM +0000, Jan Beulich wrote:
>> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
>> > vnuma_vdistances = [10, 30] # optional
>> 
>> Being optional, would the real distances be used instead? And what
> 
> Default value of [10, 20] will be used.

That's bad. Would it be very difficult to use the host values?

>> meaning does this apparently one dimensional array here have for
>> the actually two dimensional SLIT? (Read: An example with more
>> than two nodes would be useful.)
>> 
> 
> The first element of [X, Y] is local distance, the second element is
> remote distance.
> 
> For a 4 node system:
> 
>      0    1    2    3
> 0    X    Y    Y    Y 
> 1    Y    X    Y    Y
> 2    Y    Y    X    Y
> 3    Y    Y    Y    X

That may match up with how most current NUMA systems look like,
but do we really want to bake in an oversimplification like this?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:45:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrKq-0004UN-Vu; Fri, 21 Nov 2014 16:45:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrrKp-0004UI-JE
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 16:45:27 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	71/DB-03145-62C6F645; Fri, 21 Nov 2014 16:45:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416588324!13489553!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30309 invoked from network); 21 Nov 2014 16:45:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:45:25 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALGjJSc031083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 16:45:19 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALGjFW6024565
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 16:45:18 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALGjFgX012961; Fri, 21 Nov 2014 16:45:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 08:45:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 61FF1118A10; Fri, 21 Nov 2014 11:45:13 -0500 (EST)
Date: Fri, 21 Nov 2014 11:45:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121164513.GA6798@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
	<20141121151407.GD2886@laptop.dumpdata.com>
	<546F6E890200007800049DF9@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F6E890200007800049DF9@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 03:55:37PM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 16:14, <konrad.wilk@oracle.com> wrote:
> > On Fri, Nov 21, 2014 at 01:03:43PM +0100, Jan Beulich wrote:
> >> >>> On 21.11.14 at 12:50, <konrad.wilk@oracle.com> wrote:
> >> > On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
> >> >>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
> >> >>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
> >> >>struct hvm_pirq_dpci *pirq_dpci)
> >> >>>      ASSERT(d->arch.hvm_domain.irq.dpci);
> >> >>>  
> >> >>>      spin_lock(&d->event_lock);
> >> >>> -    if ( pirq_dpci->state )
> >> >>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
> >> >>>      {
> >> >>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
> >> >>>          const struct dev_intx_gsi_link *digl;
> >> >>
> >> >>So this now guards solely against the timeout enforced EOI? Why do
> >> >>you no longer need to guard against cancellation (i.e. why isn't this
> >> >>looking at both ->state and ->masked)?
> >> >>
> >> > 
> >> > The previous state check was superfluous as the dpci_softirq would check for 
> >> > the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).
> >> 
> >> I thought so first too, but then how is the guarding against
> >> cancellation working now?
> > 
> > Since there are two forms of cancellation, lets consider each one seperatly:
> > 
> > 1). pt_irq_create_bind and pt_irq_destroy_bind. Each of them calling 
> >     pt_pirq_softirq_reset in the 'error' case or in the normal path of destruction.
> >     When that happens the action handler for the IRQ is removed the moment we call
> >     pirq_guest_unbind. As such we only have to deal with the potential outstanding
> >     pirq_dpci waiting to be serviced. Since we did the 'pt_pirq_softirq_reset'
> >     we have changed the state from STATE_SCHED to zero. That means dpci_softirq will
> >     NOT go in:
> > 	if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               
> 
> Unless the flag got set again in the meantime. Since the event lock

I am having a hard time seeing when 'state' be set in that scenario.

The 'raise_softirq_for' is called when 'pirq->dpci->flags' has some value. That
gets cleared in 'pt_irq_create_bind' and 'pt_irq_destroy_bind'. Also inside
of those functions we try our best to change the 'state' from STATE_SCHED to zero.

But lets imagine we are in 'hvm_dirq_assist' right about to take the lock,
and another CPU is calling 'pt_irq_create_bind'.

The 'pt_irq_create_bind' will spin on:

                                                                                 
234     /*                                                                          
235      * A crude 'while' loop with us dropping the spinlock and giving            
236      * the softirq_dpci a chance to run.                                        
237      * We MUST check for this condition as the softirq could be scheduled       
238      * and hasn't run yet. Note that this code replaced tasklet_kill which      
239      * would have spun forever and would do the same thing (wait to flush out   
240      * outstanding hvm_dirq_assist calls.                                       
241      */                                                                         
242     if ( pt_pirq_softirq_active(pirq_dpci) )                                    
243     {                                                                           
244         spin_unlock(&d->event_lock);                                            
245         cpu_relax();                                                            
246         goto restart;                                                           

OK, so that is not it.

Lets try another case - 'pt_irq_creates_bind' is in the error path:

   rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);   
279                 if ( unlikely(rc) )                                             
280                 {                                                               
281                     pirq_guest_unbind(d, info);                                 
282                     /*                                                          
283                      * Between 'pirq_guest_bind' and before 'pirq_guest_unbind' 
284                      * an interrupt can be scheduled. No more of them are going 
285                      * to be scheduled but we must deal with the one that may be
286                      * in the queue.                                            
287                      */                                                         
288                     pt_pirq_softirq_reset(pirq_dpci);                  

And right at that moment the softirq is running. It has already set
STATE_RUN and just cleared STATE_SCHED and is executing 'hvm_dirq_assist'.
It is stuck on the spin_lock waiting for that.

The 'pt_irq_create_bind' fails in 'pt_pirq_softirq_reset' to change the 'state'
(as the state is in 'STATE_RUN', not 'STATE_SCHED').  'pt_irq_create_bind' continues
on with setting '->flag=0' and unlocks the lock.

'hvm_dirq_assist' grabs the lock and continues one (and state is STATE_RUN).
Since 'flag = 0' and 'digl_list' is empty, it thunders through the 'hvm_dirq_assist'
not doing anything. Well, it ends up calling the dreaded 'set_timer' - which will hit
another assert as it has never been initialized. Adding in 'mapping = 0' on the
error paths for MSI takes care of that.  That will take care of that - and I just
rolled 'masked =0' in the pt_pirq_softirq_reset function.

The legacy interrupt does not have this window, so it cannot do it.

> is being acquired right before the line quoted above, _that_ is

No. The event lock is acquired in 'hvm_dirq_assist' which would be
checking the 'mapping', not 'state'.

   spin_lock(&d->event_lock);                                                  
   if ( test_and_clear_bool(pirq_dpci->masked) )  

> what needs closely looking at (and why I was asking about the
> deletion of the [at the first glance unnecessary] checking of ->state
> in hvm_dirq_assist()).


>From 90d00db0949a8e796d7f812134753a54b2fe3d51 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 14:28:11 -0500
Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

commit f6dd295381f4b6a66acddacf46bca8940586c8d8
"dpci: replace tasklet with softirq" used the 'masked' as an
two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
between 'raise_softirq_for' and 'dpci_softirq' to determine whether
the 'struct hvm_pirq_dpci' can be re-scheduled.

However it ignored the 'pt_irq_guest_eoi' was not adhering to the proper
dialogue and was not using locked cmpxchg or test_bit operations and
ended setting 'state' set to zero. That meant 'raise_softirq_for' was
free to schedule it while the 'struct hvm_pirq_dpci'' was still on an
per-cpu list causing an list corruption.

The code would trigger the following path causing list corruption:

    \-timer_softirq_action
    	pt_irq_time_out calls pt_pirq_softirq_cancel sets state to 0.
            pirq_dpci is still on dpci_list.
    \- dpci_sofitrq
    	while (!list_emptry(&our_list))
    		list_del, but has not yet done 'entry->next = LIST_POISON1;'
    [interrupt happens]
    	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
    [interrupt is done, back to dpci_softirq]
    	finishes the entry->next = LIST_POISON1;
    		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
    	ends the loop, exits.

    \- dpci_softirq
    	while (!list_emtpry)
    		list_del, but ->next already has LIST_POISON1 and we blow up.

An alternative solution was proposed (adding STATE_ZOMBIE and making
pt_irq_time_out use the cmpxchg protocol on 'state'), which fixed the above
issue but had an fatal bug. It would miss interrupts that are to be scheduled!

This patch brings back the 'masked' boolean which is used as an
communication channel between 'hvm_do_IRQ_dpci', 'hvm_dirq_assist' and
'pt_irq_guest_eoi'. When we have an interrupt we set 'masked'. Anytime
'hvm_dirq_assist' or 'pt_irq_guest_eoi' executes - it clears it.

The 'state' is left as a seperate mechanism to provide an mechanism between
'raise_sofitrq' and 'softirq_dpci' to communicate the state of the
'struct hvm_dirq_pirq'.

However since we have now two seperate machines we have to deal with an
cancellations and outstanding interrupt being serviced: 'pt_irq_destroy_bind'
is called while an 'hvm_dirq_assist' is just about to service.
The 'pt_irq_destroy_bind' takes the lock first and kills the timer - and
the moment it releases the spinlock, 'hvm_dirq_assist' thunders in and calls
'set_timer' hitting an ASSERT.

By clearing the 'masked' in the 'pt_irq_destroy_bind' we take care of that
scenario by inhibiting 'hvm_dirq_assist' to call the 'set_timer'.

In the 'pt_irq_create_bind' - in the error cases we could be seeing
an softirq scheduled right away and being serviced (though stuck at
the spinlock).  The 'pt_irq_create_bind' fails in 'pt_pirq_softirq_reset'
to change the 'state' (as the state is in 'STATE_RUN', not 'STATE_SCHED').
'pt_irq_create_bind' continues on with setting '->flag=0' and unlocks the lock.

'hvm_dirq_assist' grabs the lock and continues one. Since 'flag = 0' and
'digl_list' is empty, it thunders through the 'hvm_dirq_assist' not doing
anything until it hits 'set_timer' which is undefined for MSI. Adding
in 'masked=0' for the MSI case fixes that.

The legacy interrupt one does not need it as there is no chance of
do_IRQ being called at that point.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
v2: Deal with 'masked' in pt_irq_destroy_bind.
v3: Deal with 'masked' in pt_irq_create_bind.
---
 xen/drivers/passthrough/io.c | 12 ++++++++++--
 xen/include/xen/hvm/irq.h    |  1 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..ae050df 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -129,6 +129,13 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
         pirq_dpci->dom = NULL;
         break;
     }
+    /*
+     * Inhibit 'hvm_dirq_assist' from doing anything useful and at worst
+     * calling 'set_timer' which will blow up (as we have called kill_timer
+     * or never initialized it). Note that we hold the lock that
+     * 'hvm_dirq_assist' could be spinning on.
+     */
+    pirq_dpci->masked = 0;
 }
 
 bool_t pt_irq_need_timer(uint32_t flags)
@@ -142,7 +149,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pirq_dpci->masked = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -610,6 +617,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
+    pirq_dpci->masked = 1;
     raise_softirq_for(pirq_dpci);
     return 1;
 }
@@ -669,7 +677,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( pirq_dpci->state )
+    if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..3996f1f 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -94,6 +94,7 @@ struct hvm_irq_dpci {
 struct hvm_pirq_dpci {
     uint32_t flags;
     unsigned int state;
+    bool_t masked;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:45:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrKq-0004UN-Vu; Fri, 21 Nov 2014 16:45:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrrKp-0004UI-JE
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 16:45:27 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	71/DB-03145-62C6F645; Fri, 21 Nov 2014 16:45:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416588324!13489553!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30309 invoked from network); 21 Nov 2014 16:45:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:45:25 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALGjJSc031083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 16:45:19 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALGjFW6024565
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 16:45:18 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALGjFgX012961; Fri, 21 Nov 2014 16:45:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 08:45:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 61FF1118A10; Fri, 21 Nov 2014 11:45:13 -0500 (EST)
Date: Fri, 21 Nov 2014 11:45:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121164513.GA6798@laptop.dumpdata.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
	<20141121151407.GD2886@laptop.dumpdata.com>
	<546F6E890200007800049DF9@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F6E890200007800049DF9@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 03:55:37PM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 16:14, <konrad.wilk@oracle.com> wrote:
> > On Fri, Nov 21, 2014 at 01:03:43PM +0100, Jan Beulich wrote:
> >> >>> On 21.11.14 at 12:50, <konrad.wilk@oracle.com> wrote:
> >> > On November 21, 2014 2:51:33 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
> >> >>>>> On 20.11.14 at 20:51, <konrad.wilk@oracle.com> wrote:
> >> >>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
> >> >>struct hvm_pirq_dpci *pirq_dpci)
> >> >>>      ASSERT(d->arch.hvm_domain.irq.dpci);
> >> >>>  
> >> >>>      spin_lock(&d->event_lock);
> >> >>> -    if ( pirq_dpci->state )
> >> >>> +    if ( test_and_clear_bool(pirq_dpci->masked) )
> >> >>>      {
> >> >>>          struct pirq *pirq = dpci_pirq(pirq_dpci);
> >> >>>          const struct dev_intx_gsi_link *digl;
> >> >>
> >> >>So this now guards solely against the timeout enforced EOI? Why do
> >> >>you no longer need to guard against cancellation (i.e. why isn't this
> >> >>looking at both ->state and ->masked)?
> >> >>
> >> > 
> >> > The previous state check was superfluous as the dpci_softirq would check for 
> >> > the valid STATE_ before calling hvm_dirq_assist (and deal with cancellation).
> >> 
> >> I thought so first too, but then how is the guarding against
> >> cancellation working now?
> > 
> > Since there are two forms of cancellation, lets consider each one seperatly:
> > 
> > 1). pt_irq_create_bind and pt_irq_destroy_bind. Each of them calling 
> >     pt_pirq_softirq_reset in the 'error' case or in the normal path of destruction.
> >     When that happens the action handler for the IRQ is removed the moment we call
> >     pirq_guest_unbind. As such we only have to deal with the potential outstanding
> >     pirq_dpci waiting to be serviced. Since we did the 'pt_pirq_softirq_reset'
> >     we have changed the state from STATE_SCHED to zero. That means dpci_softirq will
> >     NOT go in:
> > 	if ( test_and_clear_bit(STATE_SCHED, &pirq_dpci->state) )               
> 
> Unless the flag got set again in the meantime. Since the event lock

I am having a hard time seeing when 'state' be set in that scenario.

The 'raise_softirq_for' is called when 'pirq->dpci->flags' has some value. That
gets cleared in 'pt_irq_create_bind' and 'pt_irq_destroy_bind'. Also inside
of those functions we try our best to change the 'state' from STATE_SCHED to zero.

But lets imagine we are in 'hvm_dirq_assist' right about to take the lock,
and another CPU is calling 'pt_irq_create_bind'.

The 'pt_irq_create_bind' will spin on:

                                                                                 
234     /*                                                                          
235      * A crude 'while' loop with us dropping the spinlock and giving            
236      * the softirq_dpci a chance to run.                                        
237      * We MUST check for this condition as the softirq could be scheduled       
238      * and hasn't run yet. Note that this code replaced tasklet_kill which      
239      * would have spun forever and would do the same thing (wait to flush out   
240      * outstanding hvm_dirq_assist calls.                                       
241      */                                                                         
242     if ( pt_pirq_softirq_active(pirq_dpci) )                                    
243     {                                                                           
244         spin_unlock(&d->event_lock);                                            
245         cpu_relax();                                                            
246         goto restart;                                                           

OK, so that is not it.

Lets try another case - 'pt_irq_creates_bind' is in the error path:

   rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);   
279                 if ( unlikely(rc) )                                             
280                 {                                                               
281                     pirq_guest_unbind(d, info);                                 
282                     /*                                                          
283                      * Between 'pirq_guest_bind' and before 'pirq_guest_unbind' 
284                      * an interrupt can be scheduled. No more of them are going 
285                      * to be scheduled but we must deal with the one that may be
286                      * in the queue.                                            
287                      */                                                         
288                     pt_pirq_softirq_reset(pirq_dpci);                  

And right at that moment the softirq is running. It has already set
STATE_RUN and just cleared STATE_SCHED and is executing 'hvm_dirq_assist'.
It is stuck on the spin_lock waiting for that.

The 'pt_irq_create_bind' fails in 'pt_pirq_softirq_reset' to change the 'state'
(as the state is in 'STATE_RUN', not 'STATE_SCHED').  'pt_irq_create_bind' continues
on with setting '->flag=0' and unlocks the lock.

'hvm_dirq_assist' grabs the lock and continues one (and state is STATE_RUN).
Since 'flag = 0' and 'digl_list' is empty, it thunders through the 'hvm_dirq_assist'
not doing anything. Well, it ends up calling the dreaded 'set_timer' - which will hit
another assert as it has never been initialized. Adding in 'mapping = 0' on the
error paths for MSI takes care of that.  That will take care of that - and I just
rolled 'masked =0' in the pt_pirq_softirq_reset function.

The legacy interrupt does not have this window, so it cannot do it.

> is being acquired right before the line quoted above, _that_ is

No. The event lock is acquired in 'hvm_dirq_assist' which would be
checking the 'mapping', not 'state'.

   spin_lock(&d->event_lock);                                                  
   if ( test_and_clear_bool(pirq_dpci->masked) )  

> what needs closely looking at (and why I was asking about the
> deletion of the [at the first glance unnecessary] checking of ->state
> in hvm_dirq_assist()).


>From 90d00db0949a8e796d7f812134753a54b2fe3d51 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 14:28:11 -0500
Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

commit f6dd295381f4b6a66acddacf46bca8940586c8d8
"dpci: replace tasklet with softirq" used the 'masked' as an
two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
between 'raise_softirq_for' and 'dpci_softirq' to determine whether
the 'struct hvm_pirq_dpci' can be re-scheduled.

However it ignored the 'pt_irq_guest_eoi' was not adhering to the proper
dialogue and was not using locked cmpxchg or test_bit operations and
ended setting 'state' set to zero. That meant 'raise_softirq_for' was
free to schedule it while the 'struct hvm_pirq_dpci'' was still on an
per-cpu list causing an list corruption.

The code would trigger the following path causing list corruption:

    \-timer_softirq_action
    	pt_irq_time_out calls pt_pirq_softirq_cancel sets state to 0.
            pirq_dpci is still on dpci_list.
    \- dpci_sofitrq
    	while (!list_emptry(&our_list))
    		list_del, but has not yet done 'entry->next = LIST_POISON1;'
    [interrupt happens]
    	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
    [interrupt is done, back to dpci_softirq]
    	finishes the entry->next = LIST_POISON1;
    		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
    	ends the loop, exits.

    \- dpci_softirq
    	while (!list_emtpry)
    		list_del, but ->next already has LIST_POISON1 and we blow up.

An alternative solution was proposed (adding STATE_ZOMBIE and making
pt_irq_time_out use the cmpxchg protocol on 'state'), which fixed the above
issue but had an fatal bug. It would miss interrupts that are to be scheduled!

This patch brings back the 'masked' boolean which is used as an
communication channel between 'hvm_do_IRQ_dpci', 'hvm_dirq_assist' and
'pt_irq_guest_eoi'. When we have an interrupt we set 'masked'. Anytime
'hvm_dirq_assist' or 'pt_irq_guest_eoi' executes - it clears it.

The 'state' is left as a seperate mechanism to provide an mechanism between
'raise_sofitrq' and 'softirq_dpci' to communicate the state of the
'struct hvm_dirq_pirq'.

However since we have now two seperate machines we have to deal with an
cancellations and outstanding interrupt being serviced: 'pt_irq_destroy_bind'
is called while an 'hvm_dirq_assist' is just about to service.
The 'pt_irq_destroy_bind' takes the lock first and kills the timer - and
the moment it releases the spinlock, 'hvm_dirq_assist' thunders in and calls
'set_timer' hitting an ASSERT.

By clearing the 'masked' in the 'pt_irq_destroy_bind' we take care of that
scenario by inhibiting 'hvm_dirq_assist' to call the 'set_timer'.

In the 'pt_irq_create_bind' - in the error cases we could be seeing
an softirq scheduled right away and being serviced (though stuck at
the spinlock).  The 'pt_irq_create_bind' fails in 'pt_pirq_softirq_reset'
to change the 'state' (as the state is in 'STATE_RUN', not 'STATE_SCHED').
'pt_irq_create_bind' continues on with setting '->flag=0' and unlocks the lock.

'hvm_dirq_assist' grabs the lock and continues one. Since 'flag = 0' and
'digl_list' is empty, it thunders through the 'hvm_dirq_assist' not doing
anything until it hits 'set_timer' which is undefined for MSI. Adding
in 'masked=0' for the MSI case fixes that.

The legacy interrupt one does not need it as there is no chance of
do_IRQ being called at that point.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
v2: Deal with 'masked' in pt_irq_destroy_bind.
v3: Deal with 'masked' in pt_irq_create_bind.
---
 xen/drivers/passthrough/io.c | 12 ++++++++++--
 xen/include/xen/hvm/irq.h    |  1 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..ae050df 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -129,6 +129,13 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
         pirq_dpci->dom = NULL;
         break;
     }
+    /*
+     * Inhibit 'hvm_dirq_assist' from doing anything useful and at worst
+     * calling 'set_timer' which will blow up (as we have called kill_timer
+     * or never initialized it). Note that we hold the lock that
+     * 'hvm_dirq_assist' could be spinning on.
+     */
+    pirq_dpci->masked = 0;
 }
 
 bool_t pt_irq_need_timer(uint32_t flags)
@@ -142,7 +149,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pirq_dpci->masked = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -610,6 +617,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
+    pirq_dpci->masked = 1;
     raise_softirq_for(pirq_dpci);
     return 1;
 }
@@ -669,7 +677,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( pirq_dpci->state )
+    if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..3996f1f 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -94,6 +94,7 @@ struct hvm_irq_dpci {
 struct hvm_pirq_dpci {
     uint32_t flags;
     unsigned int state;
+    bool_t masked;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:48:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:48:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrO8-0004cL-LH; Fri, 21 Nov 2014 16:48:52 +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 1XrrO7-0004cC-Bc
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 16:48:51 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	D2/16-02698-2FC6F645; Fri, 21 Nov 2014 16:48:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416588528!14058760!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16447 invoked from network); 21 Nov 2014 16:48:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:48:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALGmC5W023904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 16:48:13 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALGmBjf004131
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 16:48:12 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALGmA4I022492; Fri, 21 Nov 2014 16:48:10 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 08:48:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1D1D6118A15; Fri, 21 Nov 2014 11:48:09 -0500 (EST)
Date: Fri, 21 Nov 2014 11:48:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141121164808.GB6798@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411211617090.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411211617090.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 10/13] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 04:31:31PM +0000, Stefano Stabellini wrote:
> On Wed, 12 Nov 2014, Stefano Stabellini wrote:
> > Introduce an arch specific function to find out whether a particular dma
> > mapping operation needs to bounce on the swiotlb buffer.
> > 
> > On ARM and ARM64, if the page involved is a foreign page and the device
> > is not coherent, we need to bounce because at unmap time we cannot
> > execute any required cache maintenance operations (we don't know how to
> > find the pfn from the mfn).
> > 
> > No change of behaviour for x86.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> I am thinking of asking a backport of this patch to 3.16+
> 
> The catch is that is_device_dma_coherent is not available on older
> kernels, so I'll have to change the arm implementation of
> xen_arch_need_swiotlb to:
> 
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn)
> +{
> +	return pfn != mfn;
> +}
> +
> 
> It is going to make things slower but it is going to fix the issue with
> cache flushing buffers for non-coherent devices.
> 
> Konrad, are you OK with that?

Looks fine.
> 
> 
> > Changes in v6:
> > - fix ts.
> > 
> > Changes in v5:
> > - fix indentation.
> > ---
> >  arch/arm/include/asm/xen/page.h |    4 ++++
> >  arch/arm/xen/mm.c               |    7 +++++++
> >  arch/x86/include/asm/xen/page.h |    7 +++++++
> >  drivers/xen/swiotlb-xen.c       |    5 ++++-
> >  4 files changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> > index 135c24a..68c739b 100644
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> >  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
> >  #define xen_unmap(cookie) iounmap((cookie))
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn);
> > +
> >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> > index ab700e1..28ebf3e 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -100,6 +100,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
> >  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
> >  }
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn)
> > +{
> > +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> > +}
> > +
> >  int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
> >  				 unsigned int address_bits,
> >  				 dma_addr_t *dma_handle)
> > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > index c949923..f58ef6c 100644
> > --- a/arch/x86/include/asm/xen/page.h
> > +++ b/arch/x86/include/asm/xen/page.h
> > @@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
> >  #define xen_remap(cookie, size) ioremap((cookie), (size));
> >  #define xen_unmap(cookie) iounmap((cookie))
> >  
> > +static inline bool xen_arch_need_swiotlb(struct device *dev,
> > +					 unsigned long pfn,
> > +					 unsigned long mfn)
> > +{
> > +	return false;
> > +}
> > +
> >  #endif /* _ASM_X86_XEN_PAGE_H */
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ad2c5eb..3725ee4 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
> >  	 * buffering it.
> >  	 */
> >  	if (dma_capable(dev, dev_addr, size) &&
> > -	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
> > +	    !range_straddles_page_boundary(phys, size) &&
> > +		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
> > +		!swiotlb_force) {
> >  		/* we are not interested in the dma_addr returned by
> >  		 * xen_dma_map_page, only in the potential cache flushes executed
> >  		 * by the function. */
> > @@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
> >  		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
> >  
> >  		if (swiotlb_force ||
> > +		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
> >  		    !dma_capable(hwdev, dev_addr, sg->length) ||
> >  		    range_straddles_page_boundary(paddr, sg->length)) {
> >  			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
> > -- 
> > 1.7.10.4
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:48:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:48:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrO8-0004cL-LH; Fri, 21 Nov 2014 16:48:52 +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 1XrrO7-0004cC-Bc
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 16:48:51 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	D2/16-02698-2FC6F645; Fri, 21 Nov 2014 16:48:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416588528!14058760!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16447 invoked from network); 21 Nov 2014 16:48:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 16:48:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALGmC5W023904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 16:48:13 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALGmBjf004131
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 16:48:12 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALGmA4I022492; Fri, 21 Nov 2014 16:48:10 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 08:48:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1D1D6118A15; Fri, 21 Nov 2014 11:48:09 -0500 (EST)
Date: Fri, 21 Nov 2014 11:48:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141121164808.GB6798@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411121130020.26318@kaball.uk.xensource.com>
	<1415792454-23161-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1411211617090.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411211617090.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v9 10/13] xen/arm/arm64: introduce
	xen_arch_need_swiotlb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 04:31:31PM +0000, Stefano Stabellini wrote:
> On Wed, 12 Nov 2014, Stefano Stabellini wrote:
> > Introduce an arch specific function to find out whether a particular dma
> > mapping operation needs to bounce on the swiotlb buffer.
> > 
> > On ARM and ARM64, if the page involved is a foreign page and the device
> > is not coherent, we need to bounce because at unmap time we cannot
> > execute any required cache maintenance operations (we don't know how to
> > find the pfn from the mfn).
> > 
> > No change of behaviour for x86.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> I am thinking of asking a backport of this patch to 3.16+
> 
> The catch is that is_device_dma_coherent is not available on older
> kernels, so I'll have to change the arm implementation of
> xen_arch_need_swiotlb to:
> 
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   unsigned long pfn,
> +			   unsigned long mfn)
> +{
> +	return pfn != mfn;
> +}
> +
> 
> It is going to make things slower but it is going to fix the issue with
> cache flushing buffers for non-coherent devices.
> 
> Konrad, are you OK with that?

Looks fine.
> 
> 
> > Changes in v6:
> > - fix ts.
> > 
> > Changes in v5:
> > - fix indentation.
> > ---
> >  arch/arm/include/asm/xen/page.h |    4 ++++
> >  arch/arm/xen/mm.c               |    7 +++++++
> >  arch/x86/include/asm/xen/page.h |    7 +++++++
> >  drivers/xen/swiotlb-xen.c       |    5 ++++-
> >  4 files changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> > index 135c24a..68c739b 100644
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> >  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
> >  #define xen_unmap(cookie) iounmap((cookie))
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn);
> > +
> >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> > index ab700e1..28ebf3e 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -100,6 +100,13 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
> >  	__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
> >  }
> >  
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +			   unsigned long pfn,
> > +			   unsigned long mfn)
> > +{
> > +	return ((pfn != mfn) && !is_device_dma_coherent(dev));
> > +}
> > +
> >  int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
> >  				 unsigned int address_bits,
> >  				 dma_addr_t *dma_handle)
> > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > index c949923..f58ef6c 100644
> > --- a/arch/x86/include/asm/xen/page.h
> > +++ b/arch/x86/include/asm/xen/page.h
> > @@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
> >  #define xen_remap(cookie, size) ioremap((cookie), (size));
> >  #define xen_unmap(cookie) iounmap((cookie))
> >  
> > +static inline bool xen_arch_need_swiotlb(struct device *dev,
> > +					 unsigned long pfn,
> > +					 unsigned long mfn)
> > +{
> > +	return false;
> > +}
> > +
> >  #endif /* _ASM_X86_XEN_PAGE_H */
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ad2c5eb..3725ee4 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
> >  	 * buffering it.
> >  	 */
> >  	if (dma_capable(dev, dev_addr, size) &&
> > -	    !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
> > +	    !range_straddles_page_boundary(phys, size) &&
> > +		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
> > +		!swiotlb_force) {
> >  		/* we are not interested in the dma_addr returned by
> >  		 * xen_dma_map_page, only in the potential cache flushes executed
> >  		 * by the function. */
> > @@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
> >  		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
> >  
> >  		if (swiotlb_force ||
> > +		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
> >  		    !dma_capable(hwdev, dev_addr, sg->length) ||
> >  		    range_straddles_page_boundary(paddr, sg->length)) {
> >  			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
> > -- 
> > 1.7.10.4
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:53:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:53:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrSm-0004vR-IC; Fri, 21 Nov 2014 16:53:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1XrrSl-0004vM-S2
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:53:39 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	0A/A7-29352-31E6F645; Fri, 21 Nov 2014 16:53:39 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416588817!12702715!1
X-Originating-IP: [209.85.216.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11834 invoked from network); 21 Nov 2014 16:53:38 -0000
Received: from mail-qc0-f180.google.com (HELO mail-qc0-f180.google.com)
	(209.85.216.180)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 16:53:38 -0000
Received: by mail-qc0-f180.google.com with SMTP id i8so4099344qcq.11
	for <xen-devel@lists.xen.org>; Fri, 21 Nov 2014 08:53:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=+HmewQ63eiiE5eT0H5dhHJ3A9gcDj0khfRQhJ94w/Zc=;
	b=PPGxTLqrlfp19kktlReS8fqh1Ums8z6iq5HzNq6+n7VC8bzhxQ9uGRE6pdkglzAEd/
	aZkgtsB5u9G9NqH/RO01JTLK8z+EEuwwh776c+RzKxI8WOr3lnNoVVvFRXTLCnCespXh
	nfS1C5TQUawVA7gVz4uMswyaJtPIAdrtKYtip8uZUa392UQEd2nYLrBllyTHywAQPFji
	/7pGsck2B6ptktpWxC3Yes+Y8hYInypS295eC2KMXXiBLek3TAzA17NVa2VYJwen69Vw
	YgxwBQkqfbOlKtDxwccm+djKVtnQKnyMKyQULybEzrj2mRmsXrfBb/aDrInFIzBM3o8a
	ZYMg==
X-Received: by 10.140.27.194 with SMTP id 60mr7508799qgx.57.1416588817679;
	Fri, 21 Nov 2014 08:53:37 -0800 (PST)
Received: from smartin-envy.nemo.cl ([201.189.88.185])
	by mx.google.com with ESMTPSA id f74sm5077943qgd.32.2014.11.21.08.53.35
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Fri, 21 Nov 2014 08:53:36 -0800 (PST)
Date: Fri, 21 Nov 2014 13:53:32 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <11981298.20141121135332@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141119205335.GB19961@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
	<546B86990200007800048DBF@mail.emea.novell.com>
	<6916092.20141119121209@gmail.com>
	<20141119205335.GB19961@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Hello Konrad and Jan,


> There was a bug in Xen pcibackend that I thought I upstreamed which could
> be releated. It was not restoring the right registers to the PCI-device.

> They are attached.

Thanks for the patches, however I have been finding some very
interesting things.

I decided to keep Xen out of the equation and booted into plain
vanilla Linux. I then ran the FLR and got the same problem in the PCI
configuration, all BARs were set to 0 and all reads to the PCI memory
returned ff. I then manually wrote the correct values into the
PCI BAR registers, and hey presto, reads to the PCI memory started
working again!

Looks like my workaround for moment will be to store the PCI
configuration registers before and resetting them after. Not cool, but
something really strange is going on...

Thanks for your help.

Regards.


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:53:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:53:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrSm-0004vR-IC; Fri, 21 Nov 2014 16:53:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <furryfuttock@gmail.com>) id 1XrrSl-0004vM-S2
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:53:39 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	0A/A7-29352-31E6F645; Fri, 21 Nov 2014 16:53:39 +0000
X-Env-Sender: furryfuttock@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416588817!12702715!1
X-Originating-IP: [209.85.216.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11834 invoked from network); 21 Nov 2014 16:53:38 -0000
Received: from mail-qc0-f180.google.com (HELO mail-qc0-f180.google.com)
	(209.85.216.180)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 16:53:38 -0000
Received: by mail-qc0-f180.google.com with SMTP id i8so4099344qcq.11
	for <xen-devel@lists.xen.org>; Fri, 21 Nov 2014 08:53:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:message-id:to:cc:subject:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding;
	bh=+HmewQ63eiiE5eT0H5dhHJ3A9gcDj0khfRQhJ94w/Zc=;
	b=PPGxTLqrlfp19kktlReS8fqh1Ums8z6iq5HzNq6+n7VC8bzhxQ9uGRE6pdkglzAEd/
	aZkgtsB5u9G9NqH/RO01JTLK8z+EEuwwh776c+RzKxI8WOr3lnNoVVvFRXTLCnCespXh
	nfS1C5TQUawVA7gVz4uMswyaJtPIAdrtKYtip8uZUa392UQEd2nYLrBllyTHywAQPFji
	/7pGsck2B6ptktpWxC3Yes+Y8hYInypS295eC2KMXXiBLek3TAzA17NVa2VYJwen69Vw
	YgxwBQkqfbOlKtDxwccm+djKVtnQKnyMKyQULybEzrj2mRmsXrfBb/aDrInFIzBM3o8a
	ZYMg==
X-Received: by 10.140.27.194 with SMTP id 60mr7508799qgx.57.1416588817679;
	Fri, 21 Nov 2014 08:53:37 -0800 (PST)
Received: from smartin-envy.nemo.cl ([201.189.88.185])
	by mx.google.com with ESMTPSA id f74sm5077943qgd.32.2014.11.21.08.53.35
	for <multiple recipients>
	(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
	Fri, 21 Nov 2014 08:53:36 -0800 (PST)
Date: Fri, 21 Nov 2014 13:53:32 -0300
From: Simon Martin <furryfuttock@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <11981298.20141121135332@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141119205335.GB19961@laptop.dumpdata.com>
References: <198478230.20141113102921@gmail.com> 
	<5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
	<546B86990200007800048DBF@mail.emea.novell.com>
	<6916092.20141119121209@gmail.com>
	<20141119205335.GB19961@laptop.dumpdata.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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

Hello Konrad and Jan,


> There was a bug in Xen pcibackend that I thought I upstreamed which could
> be releated. It was not restoring the right registers to the PCI-device.

> They are attached.

Thanks for the patches, however I have been finding some very
interesting things.

I decided to keep Xen out of the equation and booted into plain
vanilla Linux. I then ran the FLR and got the same problem in the PCI
configuration, all BARs were set to 0 and all reads to the PCI memory
returned ff. I then manually wrote the correct values into the
PCI BAR registers, and hey presto, reads to the PCI memory started
working again!

Looks like my workaround for moment will be to store the PCI
configuration registers before and resetting them after. Not cool, but
something really strange is going on...

Thanks for your help.

Regards.


-- 
Best regards,
 Simon                            mailto:furryfuttock@gmail.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:56:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrVU-000517-4E; Fri, 21 Nov 2014 16:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XrrVS-000511-Qx
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:56:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1F/9B-15461-ABE6F645; Fri, 21 Nov 2014 16:56:26 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416588981!7179891!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2066 invoked from network); 21 Nov 2014 16:56:25 -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;
	21 Nov 2014 16:56:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193777257"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:55:55 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrrUx-0006mh-5p;
	Fri, 21 Nov 2014 16:55:55 +0000
Date: Fri, 21 Nov 2014 16:55:55 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121165555.GA17120@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<546F758E0200007800049E30@mail.emea.novell.com>
	<20141121163531.GA16712@zion.uk.xensource.com>
	<546F796F0200007800049E5D@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F796F0200007800049E5D@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 04:42:07PM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 17:35, <wei.liu2@citrix.com> wrote:
> > On Fri, Nov 21, 2014 at 04:25:34PM +0000, Jan Beulich wrote:
> >> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> >> > vnuma_vdistances = [10, 30] # optional
> >> 
> >> Being optional, would the real distances be used instead? And what
> > 
> > Default value of [10, 20] will be used.
> 
> That's bad. Would it be very difficult to use the host values?
> 

It's easy. I will do that in next iteration.

> >> meaning does this apparently one dimensional array here have for
> >> the actually two dimensional SLIT? (Read: An example with more
> >> than two nodes would be useful.)
> >> 
> > 
> > The first element of [X, Y] is local distance, the second element is
> > remote distance.
> > 
> > For a 4 node system:
> > 
> >      0    1    2    3
> > 0    X    Y    Y    Y 
> > 1    Y    X    Y    Y
> > 2    Y    Y    X    Y
> > 3    Y    Y    Y    X
> 
> That may match up with how most current NUMA systems look like,
> but do we really want to bake in an oversimplification like this?
> 

I want to clarify this is only *xl* option, libxl interface is capable
of specifying every single element in SLIT.

Nonetheless I'm all for having a configuration option that would meet
both present and future need. Do you have anything in mind? Are you
suggesting we should allow specifying every element in SLIT in xl?

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:56:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrVU-000517-4E; Fri, 21 Nov 2014 16:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XrrVS-000511-Qx
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:56:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1F/9B-15461-ABE6F645; Fri, 21 Nov 2014 16:56:26 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416588981!7179891!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2066 invoked from network); 21 Nov 2014 16:56:25 -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;
	21 Nov 2014 16:56:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193777257"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 11:55:55 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrrUx-0006mh-5p;
	Fri, 21 Nov 2014 16:55:55 +0000
Date: Fri, 21 Nov 2014 16:55:55 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121165555.GA17120@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<546F758E0200007800049E30@mail.emea.novell.com>
	<20141121163531.GA16712@zion.uk.xensource.com>
	<546F796F0200007800049E5D@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F796F0200007800049E5D@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 04:42:07PM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 17:35, <wei.liu2@citrix.com> wrote:
> > On Fri, Nov 21, 2014 at 04:25:34PM +0000, Jan Beulich wrote:
> >> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> >> > vnuma_vdistances = [10, 30] # optional
> >> 
> >> Being optional, would the real distances be used instead? And what
> > 
> > Default value of [10, 20] will be used.
> 
> That's bad. Would it be very difficult to use the host values?
> 

It's easy. I will do that in next iteration.

> >> meaning does this apparently one dimensional array here have for
> >> the actually two dimensional SLIT? (Read: An example with more
> >> than two nodes would be useful.)
> >> 
> > 
> > The first element of [X, Y] is local distance, the second element is
> > remote distance.
> > 
> > For a 4 node system:
> > 
> >      0    1    2    3
> > 0    X    Y    Y    Y 
> > 1    Y    X    Y    Y
> > 2    Y    Y    X    Y
> > 3    Y    Y    Y    X
> 
> That may match up with how most current NUMA systems look like,
> but do we really want to bake in an oversimplification like this?
> 

I want to clarify this is only *xl* option, libxl interface is capable
of specifying every single element in SLIT.

Nonetheless I'm all for having a configuration option that would meet
both present and future need. Do you have anything in mind? Are you
suggesting we should allow specifying every element in SLIT in xl?

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 16:59:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16: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 1XrrYk-0005As-OA; Fri, 21 Nov 2014 16:59:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrrYj-0005Am-AU
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:59:49 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	7B/FF-02712-48F6F645; Fri, 21 Nov 2014 16:59:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416589185!14079626!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12216 invoked from network); 21 Nov 2014 16:59:47 -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;
	21 Nov 2014 16:59:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195313681"
Message-ID: <1416589182.26329.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Fri, 21 Nov 2014 16:59:42 +0000
In-Reply-To: <CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, Stefan Bader <stefan.bader@canonical.com>,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 11:57 -0700, Xing Lin wrote:
> Hi Ian,
> 
> 
> Both of your two points are valid. There is no need to install
> virt-manager. And the patch to start a qemu process in /etc/init.d/xen
> seems to be enough for launching instances from horizon. I have
> updated the wiki page.  Please review it at 
> 
> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno

FYI I've filed a few bugs/patches in Debian based on the issues you've
found here:

http://bugs.debian.org/770456 -- xen: start qemu for dom0 from initscript
http://bugs.debian.org/770468 -- qemu: backport fix for qemu crash
http://bugs.debian.org/770485 -- libvirt: pygrub path 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 Nov 21 16:59:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 16: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 1XrrYk-0005As-OA; Fri, 21 Nov 2014 16:59:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XrrYj-0005Am-AU
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 16:59:49 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	7B/FF-02712-48F6F645; Fri, 21 Nov 2014 16:59:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416589185!14079626!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12216 invoked from network); 21 Nov 2014 16:59:47 -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;
	21 Nov 2014 16:59:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195313681"
Message-ID: <1416589182.26329.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xing Lin <linxingnku@gmail.com>
Date: Fri, 21 Nov 2014 16:59:42 +0000
In-Reply-To: <CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, Stefan Bader <stefan.bader@canonical.com>,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-19 at 11:57 -0700, Xing Lin wrote:
> Hi Ian,
> 
> 
> Both of your two points are valid. There is no need to install
> virt-manager. And the patch to start a qemu process in /etc/init.d/xen
> seems to be enough for launching instances from horizon. I have
> updated the wiki page.  Please review it at 
> 
> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno

FYI I've filed a few bugs/patches in Debian based on the issues you've
found here:

http://bugs.debian.org/770456 -- xen: start qemu for dom0 from initscript
http://bugs.debian.org/770468 -- qemu: backport fix for qemu crash
http://bugs.debian.org/770485 -- libvirt: pygrub path 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 Nov 21 17:00:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrZD-0005Ew-54; Fri, 21 Nov 2014 17:00:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrrZB-0005Ei-3H
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:00:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	28/04-25276-0AF6F645; Fri, 21 Nov 2014 17:00:16 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416589213!14491398!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5059 invoked from network); 21 Nov 2014 17:00:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 17:00:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193778543"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 12:00:06 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrrZ0-0006q5-39;
	Fri, 21 Nov 2014 17:00:06 +0000
Date: Fri, 21 Nov 2014 17:00:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-kernel@vger.kernel.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] small swiotlb-xen fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
I have a couple of small straightforward fixes for swiotlb-xen for 3.19.

Cheers,

Stefano


Stefano Stabellini (2):
      swiotlb-xen: call xen_dma_sync_single_for_device when appropriate
      swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single

 drivers/xen/swiotlb-xen.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:00:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrZD-0005Ew-54; Fri, 21 Nov 2014 17:00:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrrZB-0005Ei-3H
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:00:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	28/04-25276-0AF6F645; Fri, 21 Nov 2014 17:00:16 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416589213!14491398!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5059 invoked from network); 21 Nov 2014 17:00:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 17:00:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193778543"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 12:00:06 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrrZ0-0006q5-39;
	Fri, 21 Nov 2014 17:00:06 +0000
Date: Fri, 21 Nov 2014 17:00:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-kernel@vger.kernel.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] small swiotlb-xen fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
I have a couple of small straightforward fixes for swiotlb-xen for 3.19.

Cheers,

Stefano


Stefano Stabellini (2):
      swiotlb-xen: call xen_dma_sync_single_for_device when appropriate
      swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single

 drivers/xen/swiotlb-xen.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:00:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrZi-0005KK-N0; Fri, 21 Nov 2014 17:00:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrrZh-0005K7-QN
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:00:49 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	4C/52-02702-1CF6F645; Fri, 21 Nov 2014 17:00:49 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416589247!14079902!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22065 invoked from network); 21 Nov 2014 17:00:48 -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;
	21 Nov 2014 17:00:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193778965"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 12:00:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrrZM-0006qq-EY;
	Fri, 21 Nov 2014 17:00:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 21 Nov 2014 17:00:20 +0000
Message-ID: <1416589220-7720-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	david.vrabel@citrix.com, stable@vger.kernel.org
Subject: [Xen-devel] [PATCH 2/2] swiotlb-xen: pass dev_addr to
	swiotlb_tbl_unmap_single
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Need to pass the pointer within the swiotlb internal buffer to the
swiotlb library, that in the case of xen_unmap_single is dev_addr, not
paddr.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: konrad.wilk@oracle.com
CC: stable@vger.kernel.org
---
 drivers/xen/swiotlb-xen.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 810ad41..5ea1e3c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -451,7 +451,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr)) {
-		swiotlb_tbl_unmap_single(hwdev, paddr, size, dir);
+		swiotlb_tbl_unmap_single(hwdev, dev_addr, size, dir);
 		return;
 	}
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:00:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrZi-0005KK-N0; Fri, 21 Nov 2014 17:00:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrrZh-0005K7-QN
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:00:49 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	4C/52-02702-1CF6F645; Fri, 21 Nov 2014 17:00:49 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416589247!14079902!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22065 invoked from network); 21 Nov 2014 17:00:48 -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;
	21 Nov 2014 17:00:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193778965"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 12:00:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrrZM-0006qq-EY;
	Fri, 21 Nov 2014 17:00:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 21 Nov 2014 17:00:20 +0000
Message-ID: <1416589220-7720-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	david.vrabel@citrix.com, stable@vger.kernel.org
Subject: [Xen-devel] [PATCH 2/2] swiotlb-xen: pass dev_addr to
	swiotlb_tbl_unmap_single
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Need to pass the pointer within the swiotlb internal buffer to the
swiotlb library, that in the case of xen_unmap_single is dev_addr, not
paddr.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: konrad.wilk@oracle.com
CC: stable@vger.kernel.org
---
 drivers/xen/swiotlb-xen.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 810ad41..5ea1e3c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -451,7 +451,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 
 	/* NOTE: We use dev_addr here, not paddr! */
 	if (is_xen_swiotlb_buffer(dev_addr)) {
-		swiotlb_tbl_unmap_single(hwdev, paddr, size, dir);
+		swiotlb_tbl_unmap_single(hwdev, dev_addr, size, dir);
 		return;
 	}
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:01:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:01:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrra8-0005OD-52; Fri, 21 Nov 2014 17:01:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrra6-0005O1-VF
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:01:15 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	15/3E-25727-ADF6F645; Fri, 21 Nov 2014 17:01:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416589271!13073969!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23348 invoked from network); 21 Nov 2014 17:01:12 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:01:12 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALH16P6020588
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:01:07 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sALH15sY010140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:01:06 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALH15Io005884; Fri, 21 Nov 2014 17:01:05 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:01:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 252A1118A3C; Fri, 21 Nov 2014 12:01:04 -0500 (EST)
Date: Fri, 21 Nov 2014 12:01:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141121170103.GA8314@laptop.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416497310.14429.20.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: wei.liu2@citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:28:30PM +0000, Ian Campbell wrote:
> On Wed, 2014-11-19 at 16:25 -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote:
> > > Hi Konrad, I have another release ack request:
> > > 
> > > Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > > > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > > > still some places in xenstore are not updated, including:
> > > > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> > > > This patch series updates /vm/<uuid>/name in xenstore,
> > > 
> > > This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
> > > bugfix which I think should go into Xen 4.5.
> > > 
> > > The risk WITHOUT this patch is that there are out-of-tree tools which
> > > look here for the domain name and will get confused after it is
> > > renamed.
> > 
> > When was this introduced? Did it exist with Xend?
> 
> Based on:
>  git grep domain\" RELEASE-4.4.0  tools/python/
>  git grep domain\' RELEASE-4.4.0 tools/python/
> it doesn't appear so, but someone with a xend install would be needed to
> confirm for sure.
> 
> Given that this has always been wrong for a libxl domain after migration
> it seems likely to me that noone is looking at this field.

And this is not a regression though.

What I am understanding is that we advertise to out-side toolstack
users for a couple of releases something which is misleading and wrong.

My fear is that there such toolstack users out there who will
get their pitchforks out when this shows up.

But perhaps there is a way to mitigate this. Is there another way
(and can it be in the commit description) to get the proper
domain name? I presume it is just looking at /local/domain/%d/name ?

As such could this be added:

"The proper way to get the domain name is to get it from
/local/domain/%d/name instead from this field."

Or such?
 
> > 
> > > 
> > > The risk WITH this patch is that the implementation could be wrong
> > > somehow, in which case the code would need to be updated again.  But
> > > it's a very small patch and has been fully reviewed.
> > 
> > I checked QEMU and didn't find anything in there.
> 
> Great.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:01:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:01:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrra8-0005OD-52; Fri, 21 Nov 2014 17:01:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrra6-0005O1-VF
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:01:15 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	15/3E-25727-ADF6F645; Fri, 21 Nov 2014 17:01:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416589271!13073969!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23348 invoked from network); 21 Nov 2014 17:01:12 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:01:12 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALH16P6020588
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:01:07 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sALH15sY010140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:01:06 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALH15Io005884; Fri, 21 Nov 2014 17:01:05 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:01:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 252A1118A3C; Fri, 21 Nov 2014 12:01:04 -0500 (EST)
Date: Fri, 21 Nov 2014 12:01:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141121170103.GA8314@laptop.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416497310.14429.20.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: wei.liu2@citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 03:28:30PM +0000, Ian Campbell wrote:
> On Wed, 2014-11-19 at 16:25 -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote:
> > > Hi Konrad, I have another release ack request:
> > > 
> > > Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > > > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > > > still some places in xenstore are not updated, including:
> > > > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> > > > This patch series updates /vm/<uuid>/name in xenstore,
> > > 
> > > This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
> > > bugfix which I think should go into Xen 4.5.
> > > 
> > > The risk WITHOUT this patch is that there are out-of-tree tools which
> > > look here for the domain name and will get confused after it is
> > > renamed.
> > 
> > When was this introduced? Did it exist with Xend?
> 
> Based on:
>  git grep domain\" RELEASE-4.4.0  tools/python/
>  git grep domain\' RELEASE-4.4.0 tools/python/
> it doesn't appear so, but someone with a xend install would be needed to
> confirm for sure.
> 
> Given that this has always been wrong for a libxl domain after migration
> it seems likely to me that noone is looking at this field.

And this is not a regression though.

What I am understanding is that we advertise to out-side toolstack
users for a couple of releases something which is misleading and wrong.

My fear is that there such toolstack users out there who will
get their pitchforks out when this shows up.

But perhaps there is a way to mitigate this. Is there another way
(and can it be in the commit description) to get the proper
domain name? I presume it is just looking at /local/domain/%d/name ?

As such could this be added:

"The proper way to get the domain name is to get it from
/local/domain/%d/name instead from this field."

Or such?
 
> > 
> > > 
> > > The risk WITH this patch is that the implementation could be wrong
> > > somehow, in which case the code would need to be updated again.  But
> > > it's a very small patch and has been fully reviewed.
> > 
> > I checked QEMU and didn't find anything in there.
> 
> Great.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrraL-0005RP-IE; Fri, 21 Nov 2014 17:01:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrraJ-0005Qw-Mz
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:01:27 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	1B/FA-02954-7EF6F645; Fri, 21 Nov 2014 17:01:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416589284!14080072!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28433 invoked from network); 21 Nov 2014 17:01:26 -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;
	21 Nov 2014 17:01:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193778969"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 12:00:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrrZM-0006qq-Dx;
	Fri, 21 Nov 2014 17:00:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 21 Nov 2014 17:00:19 +0000
Message-ID: <1416589220-7720-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	david.vrabel@citrix.com, stable@vger.kernel.org
Subject: [Xen-devel] [PATCH 1/2] swiotlb-xen: call
	xen_dma_sync_single_for_device when appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In xen_swiotlb_sync_single we always call xen_dma_sync_single_for_cpu,
even when we should call xen_dma_sync_single_for_device. Fix that.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: konrad.wilk@oracle.com
CC: stable@vger.kernel.org
---
 drivers/xen/swiotlb-xen.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 153cf14..810ad41 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -502,7 +502,7 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
 		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
 
 	if (target == SYNC_FOR_DEVICE)
-		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
+		xen_dma_sync_single_for_device(hwdev, dev_addr, size, dir);
 
 	if (dir != DMA_FROM_DEVICE)
 		return;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrraL-0005RP-IE; Fri, 21 Nov 2014 17:01:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrraJ-0005Qw-Mz
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:01:27 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	1B/FA-02954-7EF6F645; Fri, 21 Nov 2014 17:01:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416589284!14080072!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28433 invoked from network); 21 Nov 2014 17:01:26 -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;
	21 Nov 2014 17:01:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193778969"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 12:00:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrrZM-0006qq-Dx;
	Fri, 21 Nov 2014 17:00:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 21 Nov 2014 17:00:19 +0000
Message-ID: <1416589220-7720-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	david.vrabel@citrix.com, stable@vger.kernel.org
Subject: [Xen-devel] [PATCH 1/2] swiotlb-xen: call
	xen_dma_sync_single_for_device when appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In xen_swiotlb_sync_single we always call xen_dma_sync_single_for_cpu,
even when we should call xen_dma_sync_single_for_device. Fix that.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: konrad.wilk@oracle.com
CC: stable@vger.kernel.org
---
 drivers/xen/swiotlb-xen.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 153cf14..810ad41 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -502,7 +502,7 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t dev_addr,
 		swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
 
 	if (target == SYNC_FOR_DEVICE)
-		xen_dma_sync_single_for_cpu(hwdev, dev_addr, size, dir);
+		xen_dma_sync_single_for_device(hwdev, dev_addr, size, dir);
 
 	if (dir != DMA_FROM_DEVICE)
 		return;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:03:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:03:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrrc0-0005ps-3H; Fri, 21 Nov 2014 17:03: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 1Xrrby-0005pW-Cu
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:03:10 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	43/F2-11581-D407F645; Fri, 21 Nov 2014 17:03:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416589388!12743754!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1181 invoked from network); 21 Nov 2014 17:03:08 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 17:03:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 17:03:08 +0000
Message-Id: <546F7E5D0200007800049EA3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 17:03:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-3-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/19] xen: make two memory hypercalls
	vNUMA-aware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> @@ -747,6 +786,17 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>              return start_extent;
>          args.domain = d;
>  
> +        args.memflags |= MEMF_node(XENMEMF_get_node(reservation.mem_flags));
> +        if ( reservation.mem_flags & XENMEMF_exact_node_request )
> +            args.memflags |= MEMF_exact_node;
> +
> +        rc = translate_vnode_to_pnode(d, &reservation, &args);
> +        if ( rc )
> +        {
> +            rcu_unlock_domain(d);
> +            return rc;

I'm afraid you got misguided here by the (buggy) adjacent XSM error
path: You shouldn't return a negative error code but "start_extent"
here. And I'll try to remember to fix the XSM path post-4.5.

> +/* Guset can use XENMEMF_vnode to specify virtual node for memory op. */
> +#define XENFEAT_memory_op_vnode_supported 13

You introduce this flag but then don't use it? Also there's a typo in
the comment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:03:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:03:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrrc0-0005ps-3H; Fri, 21 Nov 2014 17:03: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 1Xrrby-0005pW-Cu
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:03:10 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	43/F2-11581-D407F645; Fri, 21 Nov 2014 17:03:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416589388!12743754!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1181 invoked from network); 21 Nov 2014 17:03:08 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 17:03:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 17:03:08 +0000
Message-Id: <546F7E5D0200007800049EA3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 17:03:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-3-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/19] xen: make two memory hypercalls
	vNUMA-aware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> @@ -747,6 +786,17 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>              return start_extent;
>          args.domain = d;
>  
> +        args.memflags |= MEMF_node(XENMEMF_get_node(reservation.mem_flags));
> +        if ( reservation.mem_flags & XENMEMF_exact_node_request )
> +            args.memflags |= MEMF_exact_node;
> +
> +        rc = translate_vnode_to_pnode(d, &reservation, &args);
> +        if ( rc )
> +        {
> +            rcu_unlock_domain(d);
> +            return rc;

I'm afraid you got misguided here by the (buggy) adjacent XSM error
path: You shouldn't return a negative error code but "start_extent"
here. And I'll try to remember to fix the XSM path post-4.5.

> +/* Guset can use XENMEMF_vnode to specify virtual node for memory op. */
> +#define XENFEAT_memory_op_vnode_supported 13

You introduce this flag but then don't use it? Also there's a typo in
the comment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:05:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrrds-000658-JJ; Fri, 21 Nov 2014 17:05:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrrdr-00064q-7o
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:05:07 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	21/70-26858-2C07F645; Fri, 21 Nov 2014 17:05:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416589505!9293460!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13853 invoked from network); 21 Nov 2014 17:05:06 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:05:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 17:05:05 +0000
Message-Id: <546F7ED30200007800049EC5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 17:05:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<546F758E0200007800049E30@mail.emea.novell.com>
	<20141121163531.GA16712@zion.uk.xensource.com>
	<546F796F0200007800049E5D@mail.emea.novell.com>
	<20141121165555.GA17120@zion.uk.xensource.com>
In-Reply-To: <20141121165555.GA17120@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/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.11.14 at 17:55, <wei.liu2@citrix.com> wrote:
> Nonetheless I'm all for having a configuration option that would meet
> both present and future need. Do you have anything in mind? Are you
> suggesting we should allow specifying every element in SLIT in xl?

I think that would be desirable.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:05:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrrds-000658-JJ; Fri, 21 Nov 2014 17:05:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xrrdr-00064q-7o
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:05:07 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	21/70-26858-2C07F645; Fri, 21 Nov 2014 17:05:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416589505!9293460!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13853 invoked from network); 21 Nov 2014 17:05:06 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:05:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 21 Nov 2014 17:05:05 +0000
Message-Id: <546F7ED30200007800049EC5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 21 Nov 2014 17:05:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<546F758E0200007800049E30@mail.emea.novell.com>
	<20141121163531.GA16712@zion.uk.xensource.com>
	<546F796F0200007800049E5D@mail.emea.novell.com>
	<20141121165555.GA17120@zion.uk.xensource.com>
In-Reply-To: <20141121165555.GA17120@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/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.11.14 at 17:55, <wei.liu2@citrix.com> wrote:
> Nonetheless I'm all for having a configuration option that would meet
> both present and future need. Do you have anything in mind? Are you
> suggesting we should allow specifying every element in SLIT in xl?

I think that would be desirable.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:09:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrriL-0006Jp-GT; Fri, 21 Nov 2014 17:09:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrriK-0006Jk-Mu
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:09:44 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	8B/00-20609-8D17F645; Fri, 21 Nov 2014 17:09:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416589782!10730557!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12093 invoked from network); 21 Nov 2014 17:09:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:09:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALH9alZ031493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:09:37 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALH9Z1I003558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:09:36 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALH9Zio017925; Fri, 21 Nov 2014 17:09:35 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:09:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EFAD4118A56; Fri, 21 Nov 2014 12:09:33 -0500 (EST)
Date: Fri, 21 Nov 2014 12:09:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141121170933.GB8314@laptop.dumpdata.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416499238.14429.39.camel@citrix.com>
	<546E1206.5080403@citrix.com> <1416500123.20161.3.camel@citrix.com>
	<546E1ABB.6090308@oracle.com> <546F3EDD.3020006@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F3EDD.3020006@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 01:32:13PM +0000, Andrew Cooper wrote:
> On 20/11/14 16:45, Boris Ostrovsky wrote:
> > On 11/20/2014 11:15 AM, Ian Campbell wrote:
> >> On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
> >>> On 20/11/14 16:00, Ian Campbell wrote:
> >>>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
> >>>>> c/s d1b93ea causes substantial functional regressions in pygrub's
> >>>>> ability to
> >>>>> parse bootloader configuration files.
> >>>>>
> >>>>> c/s d1b93ea itself changed an an interface which previously used
> >>>>> exclusively
> >>>>> integers, to using strings in the case of a grub configuration
> >>>>> with explicit
> >>>>> default set, along with changing the code calling the interface to
> >>>>> require a
> >>>>> string.  The default value for "default" remained as an integer.
> >>>>>
> >>>>> As a result, any Extlinux or Lilo configuration (which drives this
> >>>>> interface
> >>>>> exclusively with integers), or Grub configuration which doesn't
> >>>>> explicitly
> >>>>> declare a default will die with an AttributeError when attempting
> >>>>> to call
> >>>>> "self.cf.default.isdigit()" where "default" is an integer.
> >>>>>
> >>>>> Sadly, this AttributeError gets swallowed by the blanket ignore in
> >>>>> the loop
> >>>>> which searches partitions for valid bootloader configurations,
> >>>>> causing the
> >>>>> issue to be reported as "Unable to find partition containing kernel"
> >>>>>
> >>>>> This patch attempts to fix the issue by altering all parts of this
> >>>>> interface
> >>>>> to use strings, as opposed to integers.
> >>>> Would it be less invasive at this point in the release to have the
> >>>> place
> >>>> where this stuff is used do isinstance(s, str) and isinstance(s, int)?
> >>> It would be BaseString not str, but I am fairly sure the classes have
> >>> altered through Py2's history.  I would not be any more confident with
> >>> that as a solution as trying to correctly to start with.
> >> Actually isinstance(s, basestring) is what the webpage I was looking at
> >> said, but I cut-n-pasted the wrong thing.
> >>
> >> But regardless could it not do something like:
> >>     if !isinstance(foo.cf.default, int):
> >
> > I think it would be the other way around, e.g. (not tested):
> >
> > diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> > index aa7e562..7250f45 100644
> > --- a/tools/pygrub/src/pygrub
> > +++ b/tools/pygrub/src/pygrub
> > @@ -457,7 +457,9 @@ class Grub:
> >          self.cf.parse(buf)
> >
> >      def image_index(self):
> > -        if self.cf.default.isdigit():
> > +        if isinstance(self.cf.default, int)
> > +            sel = self.cf.default
> > +        elif if self.cf.default.isdigit():
> >              sel = int(self.cf.default)
> >          else:
> >              # We don't fully support submenus. Look for the leaf
> > value in
> >
> > but yes, this looks less intrusive (assuming this the only place where
> > we'd hit this error).
> >
> 
> That does look plausibly like it would fix the issue.
> 
> However, I can't help but feeing that this is hacking around a broken
> patch in the first place.

I cannot think of a reason you would ever feel that way!
<surreptitiously checks the roll of Xen 4.5 band-aid>

We know that the existing patches work fine for a host of Fedora
families (15->21) (thought I need to double check that the testing framework
that we have is using pygrub and not pvgrub), SLESs and RHEL5s, and OL6s.

The ones that I am worried about are the ExtLinux and such which
I didn't realize would use 'pygrub'.

Thought I just remembered a bug with OL7 grub entries - that is if
you go in the interactive menu things broke down. Boris, do you
remember if that was fixed or just 'deferred'?

> 
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:09:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrriL-0006Jp-GT; Fri, 21 Nov 2014 17:09:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrriK-0006Jk-Mu
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:09:44 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	8B/00-20609-8D17F645; Fri, 21 Nov 2014 17:09:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416589782!10730557!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12093 invoked from network); 21 Nov 2014 17:09:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:09:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALH9alZ031493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:09:37 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALH9Z1I003558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:09:36 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALH9Zio017925; Fri, 21 Nov 2014 17:09:35 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:09:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EFAD4118A56; Fri, 21 Nov 2014 12:09:33 -0500 (EST)
Date: Fri, 21 Nov 2014 12:09:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141121170933.GB8314@laptop.dumpdata.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416499238.14429.39.camel@citrix.com>
	<546E1206.5080403@citrix.com> <1416500123.20161.3.camel@citrix.com>
	<546E1ABB.6090308@oracle.com> <546F3EDD.3020006@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F3EDD.3020006@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 01:32:13PM +0000, Andrew Cooper wrote:
> On 20/11/14 16:45, Boris Ostrovsky wrote:
> > On 11/20/2014 11:15 AM, Ian Campbell wrote:
> >> On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
> >>> On 20/11/14 16:00, Ian Campbell wrote:
> >>>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
> >>>>> c/s d1b93ea causes substantial functional regressions in pygrub's
> >>>>> ability to
> >>>>> parse bootloader configuration files.
> >>>>>
> >>>>> c/s d1b93ea itself changed an an interface which previously used
> >>>>> exclusively
> >>>>> integers, to using strings in the case of a grub configuration
> >>>>> with explicit
> >>>>> default set, along with changing the code calling the interface to
> >>>>> require a
> >>>>> string.  The default value for "default" remained as an integer.
> >>>>>
> >>>>> As a result, any Extlinux or Lilo configuration (which drives this
> >>>>> interface
> >>>>> exclusively with integers), or Grub configuration which doesn't
> >>>>> explicitly
> >>>>> declare a default will die with an AttributeError when attempting
> >>>>> to call
> >>>>> "self.cf.default.isdigit()" where "default" is an integer.
> >>>>>
> >>>>> Sadly, this AttributeError gets swallowed by the blanket ignore in
> >>>>> the loop
> >>>>> which searches partitions for valid bootloader configurations,
> >>>>> causing the
> >>>>> issue to be reported as "Unable to find partition containing kernel"
> >>>>>
> >>>>> This patch attempts to fix the issue by altering all parts of this
> >>>>> interface
> >>>>> to use strings, as opposed to integers.
> >>>> Would it be less invasive at this point in the release to have the
> >>>> place
> >>>> where this stuff is used do isinstance(s, str) and isinstance(s, int)?
> >>> It would be BaseString not str, but I am fairly sure the classes have
> >>> altered through Py2's history.  I would not be any more confident with
> >>> that as a solution as trying to correctly to start with.
> >> Actually isinstance(s, basestring) is what the webpage I was looking at
> >> said, but I cut-n-pasted the wrong thing.
> >>
> >> But regardless could it not do something like:
> >>     if !isinstance(foo.cf.default, int):
> >
> > I think it would be the other way around, e.g. (not tested):
> >
> > diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> > index aa7e562..7250f45 100644
> > --- a/tools/pygrub/src/pygrub
> > +++ b/tools/pygrub/src/pygrub
> > @@ -457,7 +457,9 @@ class Grub:
> >          self.cf.parse(buf)
> >
> >      def image_index(self):
> > -        if self.cf.default.isdigit():
> > +        if isinstance(self.cf.default, int)
> > +            sel = self.cf.default
> > +        elif if self.cf.default.isdigit():
> >              sel = int(self.cf.default)
> >          else:
> >              # We don't fully support submenus. Look for the leaf
> > value in
> >
> > but yes, this looks less intrusive (assuming this the only place where
> > we'd hit this error).
> >
> 
> That does look plausibly like it would fix the issue.
> 
> However, I can't help but feeing that this is hacking around a broken
> patch in the first place.

I cannot think of a reason you would ever feel that way!
<surreptitiously checks the roll of Xen 4.5 band-aid>

We know that the existing patches work fine for a host of Fedora
families (15->21) (thought I need to double check that the testing framework
that we have is using pygrub and not pvgrub), SLESs and RHEL5s, and OL6s.

The ones that I am worried about are the ExtLinux and such which
I didn't realize would use 'pygrub'.

Thought I just remembered a bug with OL7 grub entries - that is if
you go in the interactive menu things broke down. Boris, do you
remember if that was fixed or just 'deferred'?

> 
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:14:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17: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 1XrrnG-0006b4-7R; Fri, 21 Nov 2014 17:14:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XrrnE-0006az-UJ
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:14:49 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	C9/37-11581-8037F645; Fri, 21 Nov 2014 17:14:48 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416590087!8606430!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17956 invoked from network); 21 Nov 2014 17:14:47 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-11.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Nov 2014 17:14:47 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XrrnB-0007WN-Uu; Fri, 21 Nov 2014 17:14:45 +0000
Message-ID: <546F7304.8090508@canonical.com>
Date: Fri, 21 Nov 2014 18:14:44 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
 Xing Lin <linxingnku@gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>	
	<54648EB3.8040703@citrix.com>	
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>	
	<1415955718.31613.34.camel@citrix.com>	
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>	
	<1416227964.5466.12.camel@citrix.com>	
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416589182.26329.11.camel@citrix.com>
In-Reply-To: <1416589182.26329.11.camel@citrix.com>
Cc: xen-devel@lists.xen.org,
	=?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7477319163071865212=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============7477319163071865212==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="Mu2hWUxRPglhsUC6I2U1HrFqcd9Vtg7Hm"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Mu2hWUxRPglhsUC6I2U1HrFqcd9Vtg7Hm
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 21.11.2014 17:59, Ian Campbell wrote:
> On Wed, 2014-11-19 at 11:57 -0700, Xing Lin wrote:
>> Hi Ian,
>>
>>
>> Both of your two points are valid. There is no need to install
>> virt-manager. And the patch to start a qemu process in /etc/init.d/xen=

>> seems to be enough for launching instances from horizon. I have
>> updated the wiki page.  Please review it at=20
>>
>> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
>=20
> FYI I've filed a few bugs/patches in Debian based on the issues you've
> found here:
>=20
> http://bugs.debian.org/770456 -- xen: start qemu for dom0 from initscri=
pt
> http://bugs.debian.org/770468 -- qemu: backport fix for qemu crash
> http://bugs.debian.org/770485 -- libvirt: pygrub path thing.

Thanks for the links. Will try to shadow those in launchpad next week. Fo=
r qemu
Xing opened http://bugs.launchpad.net/bugs/1394327

>=20
>=20
> Ian.
>=20



--Mu2hWUxRPglhsUC6I2U1HrFqcd9Vtg7Hm
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

iQIcBAEBCgAGBQJUb3MEAAoJEOhnXe7L7s6jyHAQAMITf5ZwvjWOdWxkIG7TIX66
hNnDyC3ttJLYvnY0d2GePujYx5tlFHRWJ7h/HFM3WuCJ3hCl9gPjD+zoiBIJ05jy
g9lpPDBbsudqYKOArlUcWMzJd/E+VLlnDZWNAbXU8+Rgca3W9Lg897CvVnBjJmhZ
k7jHiLISo59FejpTsbmOMke2bt1Rwv3qfkSnoa4uX+2uERBxKGqHnjb6kHk4CwXF
WV2GcpbRTufLludVwb9/OdRbQd1nCa4AIH101/wzg+HcmQWN0Ztsu5ZofRDN8NUF
dSbLTecBD2nx2dh/CmS+4iCSk6LSW7DLWph7QT6Pfp1yEs+JHXcNdiVEwkGQAmMF
NByWM7aRaBPqeqwcW4CaDQj5QMVR7byG7jvj91vl4Io2OhcDe1OgfCEoN+pgQurR
7JTrLBdfK7qrFdhmazBRqsitgH6iSxCZ7JKlN9UbxH84U0Lw8vGZyi143OllVkes
BcIOX2IukBX18fbBG06UlK8H/NtCs1frdjBaG2rJBESgjSeqBIu2NJNnxPU3C6MJ
6wyzBz0GwClcfv2mcTGrKp09uRBqrHNA3oZvKyRU959k4G/2qfREZGGO7dJnrJnO
jzRCTGbE2hKHVGJ09cskJURe4XOTd0VV9ywP7K7qUJ7sCjxcpv/kc6szHq/+Kv2Q
xZmSQNZEC9d0UzbdTmB/
=EC5k
-----END PGP SIGNATURE-----

--Mu2hWUxRPglhsUC6I2U1HrFqcd9Vtg7Hm--


--===============7477319163071865212==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7477319163071865212==--


From xen-devel-bounces@lists.xen.org Fri Nov 21 17:14:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17: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 1XrrnG-0006b4-7R; Fri, 21 Nov 2014 17:14:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1XrrnE-0006az-UJ
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:14:49 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	C9/37-11581-8037F645; Fri, 21 Nov 2014 17:14:48 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416590087!8606430!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17956 invoked from network); 21 Nov 2014 17:14:47 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-11.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Nov 2014 17:14:47 -0000
Received: from hsi-kbw-109-193-156-102.hsi7.kabel-badenwuerttemberg.de
	([109.193.156.102] helo=[192.168.2.194])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1XrrnB-0007WN-Uu; Fri, 21 Nov 2014 17:14:45 +0000
Message-ID: <546F7304.8090508@canonical.com>
Date: Fri, 21 Nov 2014 18:14:44 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
 Xing Lin <linxingnku@gmail.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>	
	<54648EB3.8040703@citrix.com>	
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>	
	<1415955718.31613.34.camel@citrix.com>	
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>	
	<1416227964.5466.12.camel@citrix.com>	
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416589182.26329.11.camel@citrix.com>
In-Reply-To: <1416589182.26329.11.camel@citrix.com>
Cc: xen-devel@lists.xen.org,
	=?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7477319163071865212=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============7477319163071865212==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="Mu2hWUxRPglhsUC6I2U1HrFqcd9Vtg7Hm"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Mu2hWUxRPglhsUC6I2U1HrFqcd9Vtg7Hm
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 21.11.2014 17:59, Ian Campbell wrote:
> On Wed, 2014-11-19 at 11:57 -0700, Xing Lin wrote:
>> Hi Ian,
>>
>>
>> Both of your two points are valid. There is no need to install
>> virt-manager. And the patch to start a qemu process in /etc/init.d/xen=

>> seems to be enough for launching instances from horizon. I have
>> updated the wiki page.  Please review it at=20
>>
>> http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
>=20
> FYI I've filed a few bugs/patches in Debian based on the issues you've
> found here:
>=20
> http://bugs.debian.org/770456 -- xen: start qemu for dom0 from initscri=
pt
> http://bugs.debian.org/770468 -- qemu: backport fix for qemu crash
> http://bugs.debian.org/770485 -- libvirt: pygrub path thing.

Thanks for the links. Will try to shadow those in launchpad next week. Fo=
r qemu
Xing opened http://bugs.launchpad.net/bugs/1394327

>=20
>=20
> Ian.
>=20



--Mu2hWUxRPglhsUC6I2U1HrFqcd9Vtg7Hm
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

iQIcBAEBCgAGBQJUb3MEAAoJEOhnXe7L7s6jyHAQAMITf5ZwvjWOdWxkIG7TIX66
hNnDyC3ttJLYvnY0d2GePujYx5tlFHRWJ7h/HFM3WuCJ3hCl9gPjD+zoiBIJ05jy
g9lpPDBbsudqYKOArlUcWMzJd/E+VLlnDZWNAbXU8+Rgca3W9Lg897CvVnBjJmhZ
k7jHiLISo59FejpTsbmOMke2bt1Rwv3qfkSnoa4uX+2uERBxKGqHnjb6kHk4CwXF
WV2GcpbRTufLludVwb9/OdRbQd1nCa4AIH101/wzg+HcmQWN0Ztsu5ZofRDN8NUF
dSbLTecBD2nx2dh/CmS+4iCSk6LSW7DLWph7QT6Pfp1yEs+JHXcNdiVEwkGQAmMF
NByWM7aRaBPqeqwcW4CaDQj5QMVR7byG7jvj91vl4Io2OhcDe1OgfCEoN+pgQurR
7JTrLBdfK7qrFdhmazBRqsitgH6iSxCZ7JKlN9UbxH84U0Lw8vGZyi143OllVkes
BcIOX2IukBX18fbBG06UlK8H/NtCs1frdjBaG2rJBESgjSeqBIu2NJNnxPU3C6MJ
6wyzBz0GwClcfv2mcTGrKp09uRBqrHNA3oZvKyRU959k4G/2qfREZGGO7dJnrJnO
jzRCTGbE2hKHVGJ09cskJURe4XOTd0VV9ywP7K7qUJ7sCjxcpv/kc6szHq/+Kv2Q
xZmSQNZEC9d0UzbdTmB/
=EC5k
-----END PGP SIGNATURE-----

--Mu2hWUxRPglhsUC6I2U1HrFqcd9Vtg7Hm--


--===============7477319163071865212==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7477319163071865212==--


From xen-devel-bounces@lists.xen.org Fri Nov 21 17:22:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:22:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrrug-0006tn-Vz; Fri, 21 Nov 2014 17:22:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xrruf-0006tb-2G
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:22:29 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	D8/D1-02696-4D47F645; Fri, 21 Nov 2014 17:22:28 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416590546!14076307!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7846 invoked from network); 21 Nov 2014 17:22:27 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:22:27 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALHMMdT014887
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:22:23 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHMKFF017022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:22:21 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHMKO5020110; Fri, 21 Nov 2014 17:22:20 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:22:20 -0800
Message-ID: <546F7574.9020005@oracle.com>
Date: Fri, 21 Nov 2014 12:25:08 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416499238.14429.39.camel@citrix.com>
	<546E1206.5080403@citrix.com> <1416500123.20161.3.camel@citrix.com>
	<546E1ABB.6090308@oracle.com> <546F3EDD.3020006@citrix.com>
	<20141121170933.GB8314@laptop.dumpdata.com>
In-Reply-To: <20141121170933.GB8314@laptop.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 12:09 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 01:32:13PM +0000, Andrew Cooper wrote:
>> That does look plausibly like it would fix the issue.
>>
>> However, I can't help but feeing that this is hacking around a broken
>> patch in the first place.
> I cannot think of a reason you would ever feel that way!
> <surreptitiously checks the roll of Xen 4.5 band-aid>
>
> We know that the existing patches work fine for a host of Fedora
> families (15->21) (thought I need to double check that the testing framework
> that we have is using pygrub and not pvgrub), SLESs and RHEL5s, and OL6s.
>
> The ones that I am worried about are the ExtLinux and such which
> I didn't realize would use 'pygrub'.
>
> Thought I just remembered a bug with OL7 grub entries - that is if
> you go in the interactive menu things broke down. Boris, do you
> remember if that was fixed or just 'deferred'?

The only bug that I remember that had to do pygrub and OL7 was the fact 
that pygrub cannot parse grubenv (and therefore it's not really 
OL7-specific).

We decided not to fix it.


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:22:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:22:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrrug-0006tn-Vz; Fri, 21 Nov 2014 17:22:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xrruf-0006tb-2G
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:22:29 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	D8/D1-02696-4D47F645; Fri, 21 Nov 2014 17:22:28 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416590546!14076307!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7846 invoked from network); 21 Nov 2014 17:22:27 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:22:27 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALHMMdT014887
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:22:23 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHMKFF017022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:22:21 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHMKO5020110; Fri, 21 Nov 2014 17:22:20 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:22:20 -0800
Message-ID: <546F7574.9020005@oracle.com>
Date: Fri, 21 Nov 2014 12:25:08 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416499238.14429.39.camel@citrix.com>
	<546E1206.5080403@citrix.com> <1416500123.20161.3.camel@citrix.com>
	<546E1ABB.6090308@oracle.com> <546F3EDD.3020006@citrix.com>
	<20141121170933.GB8314@laptop.dumpdata.com>
In-Reply-To: <20141121170933.GB8314@laptop.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 12:09 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 01:32:13PM +0000, Andrew Cooper wrote:
>> That does look plausibly like it would fix the issue.
>>
>> However, I can't help but feeing that this is hacking around a broken
>> patch in the first place.
> I cannot think of a reason you would ever feel that way!
> <surreptitiously checks the roll of Xen 4.5 band-aid>
>
> We know that the existing patches work fine for a host of Fedora
> families (15->21) (thought I need to double check that the testing framework
> that we have is using pygrub and not pvgrub), SLESs and RHEL5s, and OL6s.
>
> The ones that I am worried about are the ExtLinux and such which
> I didn't realize would use 'pygrub'.
>
> Thought I just remembered a bug with OL7 grub entries - that is if
> you go in the interactive menu things broke down. Boris, do you
> remember if that was fixed or just 'deferred'?

The only bug that I remember that had to do pygrub and OL7 was the fact 
that pygrub cannot parse grubenv (and therefore it's not really 
OL7-specific).

We decided not to fix it.


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:26:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrryE-00076w-L3; Fri, 21 Nov 2014 17:26:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrryD-00076o-OI
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:26:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	40/12-25276-1B57F645; Fri, 21 Nov 2014 17:26:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416590767!14498450!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8762 invoked from network); 21 Nov 2014 17:26:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:26:08 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALHQ4BD007890
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:26:05 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHQ4mo001304
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:26:04 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHQ4Z2001286; Fri, 21 Nov 2014 17:26:04 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:26:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 21C73118A83; Fri, 21 Nov 2014 12:26:03 -0500 (EST)
Date: Fri, 21 Nov 2014 12:26:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Simon Martin <furryfuttock@gmail.com>
Message-ID: <20141121172602.GE8314@laptop.dumpdata.com>
References: <5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
	<546B86990200007800048DBF@mail.emea.novell.com>
	<6916092.20141119121209@gmail.com>
	<20141119205335.GB19961@laptop.dumpdata.com>
	<11981298.20141121135332@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <11981298.20141121135332@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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, Nov 21, 2014 at 01:53:32PM -0300, Simon Martin wrote:
> Hello Konrad and Jan,
> 
> 
> > There was a bug in Xen pcibackend that I thought I upstreamed which could
> > be releated. It was not restoring the right registers to the PCI-device.
> 
> > They are attached.
> 
> Thanks for the patches, however I have been finding some very
> interesting things.
> 
> I decided to keep Xen out of the equation and booted into plain
> vanilla Linux. I then ran the FLR and got the same problem in the PCI
> configuration, all BARs were set to 0 and all reads to the PCI memory
> returned ff. I then manually wrote the correct values into the
> PCI BAR registers, and hey presto, reads to the PCI memory started
> working again!
> 
> Looks like my workaround for moment will be to store the PCI
> configuration registers before and resetting them after. Not cool, but
> something really strange is going on...

Right. Which is what the pciback does now (minus the bugs that the
two patches fix).

Look for pci_restore_config and pci_save_config
> 
> Thanks for your help.
> 
> Regards.
> 
> 
> -- 
> Best regards,
>  Simon                            mailto:furryfuttock@gmail.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:26:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrryE-00076w-L3; Fri, 21 Nov 2014 17:26:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrryD-00076o-OI
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:26:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	40/12-25276-1B57F645; Fri, 21 Nov 2014 17:26:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416590767!14498450!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8762 invoked from network); 21 Nov 2014 17:26:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:26:08 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALHQ4BD007890
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:26:05 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHQ4mo001304
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:26:04 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHQ4Z2001286; Fri, 21 Nov 2014 17:26:04 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:26:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 21C73118A83; Fri, 21 Nov 2014 12:26:03 -0500 (EST)
Date: Fri, 21 Nov 2014 12:26:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Simon Martin <furryfuttock@gmail.com>
Message-ID: <20141121172602.GE8314@laptop.dumpdata.com>
References: <5464C971020000780004739B@mail.emea.novell.com>
	<196307380.20141113120732@gmail.com>
	<5464E1D9020000780004746B@mail.emea.novell.com>
	<429773295.20141113144907@gmail.com>
	<5465CB080200007800047845@mail.emea.novell.com>
	<19872515.20141118132405@gmail.com>
	<546B86990200007800048DBF@mail.emea.novell.com>
	<6916092.20141119121209@gmail.com>
	<20141119205335.GB19961@laptop.dumpdata.com>
	<11981298.20141121135332@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <11981298.20141121135332@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems accessing passthrough PCI 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, Nov 21, 2014 at 01:53:32PM -0300, Simon Martin wrote:
> Hello Konrad and Jan,
> 
> 
> > There was a bug in Xen pcibackend that I thought I upstreamed which could
> > be releated. It was not restoring the right registers to the PCI-device.
> 
> > They are attached.
> 
> Thanks for the patches, however I have been finding some very
> interesting things.
> 
> I decided to keep Xen out of the equation and booted into plain
> vanilla Linux. I then ran the FLR and got the same problem in the PCI
> configuration, all BARs were set to 0 and all reads to the PCI memory
> returned ff. I then manually wrote the correct values into the
> PCI BAR registers, and hey presto, reads to the PCI memory started
> working again!
> 
> Looks like my workaround for moment will be to store the PCI
> configuration registers before and resetting them after. Not cool, but
> something really strange is going on...

Right. Which is what the pciback does now (minus the bugs that the
two patches fix).

Look for pci_restore_config and pci_save_config
> 
> Thanks for your help.
> 
> Regards.
> 
> 
> -- 
> Best regards,
>  Simon                            mailto:furryfuttock@gmail.com
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:27:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17: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 1Xrrz6-0007Dc-2K; Fri, 21 Nov 2014 17:27:04 +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 1Xrrz4-0007DM-U7
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:27:03 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	D5/16-02953-6E57F645; Fri, 21 Nov 2014 17:27:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416590820!14066221!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12724 invoked from network); 21 Nov 2014 17:27:01 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:27:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALHQtSP008775
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:26:55 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHQsWG029303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:26:55 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHQr6D013383; Fri, 21 Nov 2014 17:26:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:26:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 913D8118A86; Fri, 21 Nov 2014 12:26:52 -0500 (EST)
Date: Fri, 21 Nov 2014 12:26:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141121172652.GF8314@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 0/2] small swiotlb-xen fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 05:00:05PM +0000, Stefano Stabellini wrote:
> Hi all,
> I have a couple of small straightforward fixes for swiotlb-xen for 3.19.
> 

They look fine to me.

Thanks.
> Cheers,
> 
> Stefano
> 
> 
> Stefano Stabellini (2):
>       swiotlb-xen: call xen_dma_sync_single_for_device when appropriate
>       swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single
> 
>  drivers/xen/swiotlb-xen.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:27:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17: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 1Xrrz6-0007Dc-2K; Fri, 21 Nov 2014 17:27:04 +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 1Xrrz4-0007DM-U7
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:27:03 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	D5/16-02953-6E57F645; Fri, 21 Nov 2014 17:27:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416590820!14066221!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12724 invoked from network); 21 Nov 2014 17:27:01 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:27:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALHQtSP008775
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:26:55 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHQsWG029303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:26:55 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHQr6D013383; Fri, 21 Nov 2014 17:26:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:26:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 913D8118A86; Fri, 21 Nov 2014 12:26:52 -0500 (EST)
Date: Fri, 21 Nov 2014 12:26:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141121172652.GF8314@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 0/2] small swiotlb-xen fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 05:00:05PM +0000, Stefano Stabellini wrote:
> Hi all,
> I have a couple of small straightforward fixes for swiotlb-xen for 3.19.
> 

They look fine to me.

Thanks.
> Cheers,
> 
> Stefano
> 
> 
> Stefano Stabellini (2):
>       swiotlb-xen: call xen_dma_sync_single_for_device when appropriate
>       swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single
> 
>  drivers/xen/swiotlb-xen.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:27:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:27:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrzT-0007Gl-F5; Fri, 21 Nov 2014 17:27:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrrzS-0007Gc-E2
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:27:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A6/9E-15461-DF57F645; Fri, 21 Nov 2014 17:27:25 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416590843!14512810!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28924 invoked from network); 21 Nov 2014 17:27:25 -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;
	21 Nov 2014 17:27:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195318485"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 12:11:09 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xrrjh-00071D-Jx;
	Fri, 21 Nov 2014 17:11:09 +0000
Date: Fri, 21 Nov 2014 17:11:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
In-Reply-To: <1416494946.14429.13.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any NICs
 except the first to avoid wasting 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

The rom is used for pxebooting. We don't need to allow pxebooting from
more than one network card.  Loading a romfile for every NIC wastes
memory and as a matter of fact breaks configurations with more than 4
NICs as QEMU fails to allocate memory on behalf of the guest.

With this fix, it is possible to assign more than 4 rtl8139 NICs to the
guest.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..f907ca9 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 LIBXL_NIC_TYPE_VIF_IOEMU);
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
-                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
+                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
                                                 nics[i].model, nics[i].devid,
-                                                nics[i].devid, smac));
+                                                nics[i].devid, smac,
+                                                i ? ",romfile=\"\"" : ""));
                 flexarray_append(dm_args, "-netdev");
                 flexarray_append(dm_args, GCSPRINTF(
                                           "type=tap,id=net%d,ifname=%s,"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:27:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:27:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrrzT-0007Gl-F5; Fri, 21 Nov 2014 17:27:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrrzS-0007Gc-E2
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:27:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A6/9E-15461-DF57F645; Fri, 21 Nov 2014 17:27:25 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416590843!14512810!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28924 invoked from network); 21 Nov 2014 17:27:25 -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;
	21 Nov 2014 17:27:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195318485"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 12:11:09 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xrrjh-00071D-Jx;
	Fri, 21 Nov 2014 17:11:09 +0000
Date: Fri, 21 Nov 2014 17:11:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
In-Reply-To: <1416494946.14429.13.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
References: <1ac72b0.26f7c.149ae18f6bb.Coremail.hanyandong@iie.ac.cn>
	<1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any NICs
 except the first to avoid wasting 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

The rom is used for pxebooting. We don't need to allow pxebooting from
more than one network card.  Loading a romfile for every NIC wastes
memory and as a matter of fact breaks configurations with more than 4
NICs as QEMU fails to allocate memory on behalf of the guest.

With this fix, it is possible to assign more than 4 rtl8139 NICs to the
guest.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..f907ca9 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 LIBXL_NIC_TYPE_VIF_IOEMU);
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
-                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
+                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
                                                 nics[i].model, nics[i].devid,
-                                                nics[i].devid, smac));
+                                                nics[i].devid, smac,
+                                                i ? ",romfile=\"\"" : ""));
                 flexarray_append(dm_args, "-netdev");
                 flexarray_append(dm_args, GCSPRINTF(
                                           "type=tap,id=net%d,ifname=%s,"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:30:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrs2R-0007bG-2M; Fri, 21 Nov 2014 17:30: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 1Xrs2P-0007b5-HV
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:30:29 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	C3/A0-17735-4B67F645; Fri, 21 Nov 2014 17:30:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416591026!9298378!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5999 invoked from network); 21 Nov 2014 17:30:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 17:30:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193789676"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 12:30:24 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xrs2K-0007Ht-68;
	Fri, 21 Nov 2014 17:30:24 +0000
Date: Fri, 21 Nov 2014 17:30:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121173024.GA17978@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-3-git-send-email-wei.liu2@citrix.com>
	<546F7E5D0200007800049EA3@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F7E5D0200007800049EA3@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/19] xen: make two memory hypercalls
	vNUMA-aware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 05:03:09PM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> > @@ -747,6 +786,17 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> >              return start_extent;
> >          args.domain = d;
> >  
> > +        args.memflags |= MEMF_node(XENMEMF_get_node(reservation.mem_flags));
> > +        if ( reservation.mem_flags & XENMEMF_exact_node_request )
> > +            args.memflags |= MEMF_exact_node;
> > +
> > +        rc = translate_vnode_to_pnode(d, &reservation, &args);
> > +        if ( rc )
> > +        {
> > +            rcu_unlock_domain(d);
> > +            return rc;
> 
> I'm afraid you got misguided here by the (buggy) adjacent XSM error
> path: You shouldn't return a negative error code but "start_extent"
> here. And I'll try to remember to fix the XSM path post-4.5.
> 

Fixed.

> > +/* Guset can use XENMEMF_vnode to specify virtual node for memory op. */
> > +#define XENFEAT_memory_op_vnode_supported 13
> 
> You introduce this flag but then don't use it? Also there's a typo in
> the comment.
> 

Oops, a hunk is missing. Fixed.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:30:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrs2R-0007bG-2M; Fri, 21 Nov 2014 17:30: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 1Xrs2P-0007b5-HV
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:30:29 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	C3/A0-17735-4B67F645; Fri, 21 Nov 2014 17:30:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416591026!9298378!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5999 invoked from network); 21 Nov 2014 17:30:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 17:30:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193789676"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 12:30:24 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xrs2K-0007Ht-68;
	Fri, 21 Nov 2014 17:30:24 +0000
Date: Fri, 21 Nov 2014 17:30:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141121173024.GA17978@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-3-git-send-email-wei.liu2@citrix.com>
	<546F7E5D0200007800049EA3@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F7E5D0200007800049EA3@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/19] xen: make two memory hypercalls
	vNUMA-aware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 05:03:09PM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> > @@ -747,6 +786,17 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> >              return start_extent;
> >          args.domain = d;
> >  
> > +        args.memflags |= MEMF_node(XENMEMF_get_node(reservation.mem_flags));
> > +        if ( reservation.mem_flags & XENMEMF_exact_node_request )
> > +            args.memflags |= MEMF_exact_node;
> > +
> > +        rc = translate_vnode_to_pnode(d, &reservation, &args);
> > +        if ( rc )
> > +        {
> > +            rcu_unlock_domain(d);
> > +            return rc;
> 
> I'm afraid you got misguided here by the (buggy) adjacent XSM error
> path: You shouldn't return a negative error code but "start_extent"
> here. And I'll try to remember to fix the XSM path post-4.5.
> 

Fixed.

> > +/* Guset can use XENMEMF_vnode to specify virtual node for memory op. */
> > +#define XENFEAT_memory_op_vnode_supported 13
> 
> You introduce this flag but then don't use it? Also there's a typo in
> the comment.
> 

Oops, a hunk is missing. Fixed.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:35:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:35:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrs6p-0007pL-0l; Fri, 21 Nov 2014 17:35:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrs6n-0007pG-56
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:35:01 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	8C/9B-28296-4C77F645; Fri, 21 Nov 2014 17:35:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416591298!13023597!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30872 invoked from network); 21 Nov 2014 17:34:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:34:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALHYjwp030151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:34:46 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHYgbI008012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 17:34:44 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALHYedj025648; Fri, 21 Nov 2014 17:34:41 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:34:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5ABE0118A97; Fri, 21 Nov 2014 12:34:37 -0500 (EST)
Date: Fri, 21 Nov 2014 12:34:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141121173437.GA14331@laptop.dumpdata.com>
References: <1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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 Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> The rom is used for pxebooting. We don't need to allow pxebooting from
> more than one network card.  Loading a romfile for every NIC wastes

Why not? Why can't we PXE boot from each network card?

> memory and as a matter of fact breaks configurations with more than 4
> NICs as QEMU fails to allocate memory on behalf of the guest.

What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
and ne2k ?

Don't you want to load the ROM for each one?
> 
> With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> guest.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 3e191c3..f907ca9 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
>                  flexarray_append(dm_args, "-device");
>                  flexarray_append(dm_args,
> -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
>                                                  nics[i].model, nics[i].devid,
> -                                                nics[i].devid, smac));
> +                                                nics[i].devid, smac,
> +                                                i ? ",romfile=\"\"" : ""));
>                  flexarray_append(dm_args, "-netdev");
>                  flexarray_append(dm_args, GCSPRINTF(
>                                            "type=tap,id=net%d,ifname=%s,"
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:35:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:35:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrs6p-0007pL-0l; Fri, 21 Nov 2014 17:35:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrs6n-0007pG-56
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:35:01 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	8C/9B-28296-4C77F645; Fri, 21 Nov 2014 17:35:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416591298!13023597!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30872 invoked from network); 21 Nov 2014 17:34:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:34:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALHYjwp030151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:34:46 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHYgbI008012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 17:34:44 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALHYedj025648; Fri, 21 Nov 2014 17:34:41 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:34:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5ABE0118A97; Fri, 21 Nov 2014 12:34:37 -0500 (EST)
Date: Fri, 21 Nov 2014 12:34:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141121173437.GA14331@laptop.dumpdata.com>
References: <1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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 Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> The rom is used for pxebooting. We don't need to allow pxebooting from
> more than one network card.  Loading a romfile for every NIC wastes

Why not? Why can't we PXE boot from each network card?

> memory and as a matter of fact breaks configurations with more than 4
> NICs as QEMU fails to allocate memory on behalf of the guest.

What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
and ne2k ?

Don't you want to load the ROM for each one?
> 
> With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> guest.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 3e191c3..f907ca9 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
>                  flexarray_append(dm_args, "-device");
>                  flexarray_append(dm_args,
> -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
>                                                  nics[i].model, nics[i].devid,
> -                                                nics[i].devid, smac));
> +                                                nics[i].devid, smac,
> +                                                i ? ",romfile=\"\"" : ""));
>                  flexarray_append(dm_args, "-netdev");
>                  flexarray_append(dm_args, GCSPRINTF(
>                                            "type=tap,id=net%d,ifname=%s,"
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:37:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:37:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrs8z-00083N-J1; Fri, 21 Nov 2014 17:37:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xrs8y-00083I-3N
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:37:16 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	30/12-02696-B487F645; Fri, 21 Nov 2014 17:37:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416591433!14074220!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19966 invoked from network); 21 Nov 2014 17:37:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 17:37:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195321525"
Message-ID: <1416590516.26329.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <libvir-list@redhat.com>, Jim Fehlig <jfehlig@suse.com>
Date: Fri, 21 Nov 2014 17:21:56 +0000
In-Reply-To: <1416580373.17932.15.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416475824.14429.1.camel@citrix.com>
	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
	<1416562126.26869.8.camel@citrix.com>
	<1416578732.17932.9.camel@citrix.com>
	<546F49CD.1020907@citrix.com> <1416580373.17932.15.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, David Vrabel <david.vrabel@citrix.com>,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 14:32 +0000, Ian Campbell wrote:

I've now built and tested this with the 1.2.9 Debian package, works like
a charm...

> From 9f2d8da8264b426f54b92378e9e00973694193d4 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 21 Nov 2014 14:00:38 +0000
> Subject: [PATCH] libxl: Allow libxl to find pygrub binary.
> 
> Specifying an explicit path to pygrub (e.g. BINDIR "/pygrub") only works if
> Xen and libvirt happen to be installed to the same prefix. A more flexible
> approach is to simply specify "pygrub" which will cause libxl to use the
> correct path which it knows (since it is built with the same prefix as pygrub).
> 
> This is particular problematic in the Debian packaging, since the Debian Xen
> package relocates pygrub into a libexec dir, however I think this change makes
> sense upstream.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  .gnulib                |    2 +-
>  src/libxl/libxl_conf.h |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/.gnulib b/.gnulib
> index 9565c3b..2d28074 160000
> --- a/.gnulib
> +++ b/.gnulib
> @@ -1 +1 @@
> -Subproject commit 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d
> +Subproject commit 2d280742a9e30088aa169f53353765d5daafe4c0
> diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
> index 25f77ea..d7a3971 100644
> --- a/src/libxl/libxl_conf.h
> +++ b/src/libxl/libxl_conf.h
> @@ -53,7 +53,7 @@
>  # define LIBXL_LIB_DIR LOCALSTATEDIR "/lib/libvirt/libxl"
>  # define LIBXL_SAVE_DIR LIBXL_LIB_DIR "/save"
>  # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump"
> -# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
> +# define LIBXL_BOOTLOADER_PATH "pygrub"
>  
>  /* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new
>   * parameter has been added, representative of 'VCPU soft affinity'. If one



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:37:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:37:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrs8z-00083N-J1; Fri, 21 Nov 2014 17:37:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xrs8y-00083I-3N
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 17:37:16 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	30/12-02696-B487F645; Fri, 21 Nov 2014 17:37:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416591433!14074220!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19966 invoked from network); 21 Nov 2014 17:37:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 17:37:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195321525"
Message-ID: <1416590516.26329.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <libvir-list@redhat.com>, Jim Fehlig <jfehlig@suse.com>
Date: Fri, 21 Nov 2014 17:21:56 +0000
In-Reply-To: <1416580373.17932.15.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416475824.14429.1.camel@citrix.com>
	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
	<1416562126.26869.8.camel@citrix.com>
	<1416578732.17932.9.camel@citrix.com>
	<546F49CD.1020907@citrix.com> <1416580373.17932.15.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, David Vrabel <david.vrabel@citrix.com>,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 14:32 +0000, Ian Campbell wrote:

I've now built and tested this with the 1.2.9 Debian package, works like
a charm...

> From 9f2d8da8264b426f54b92378e9e00973694193d4 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 21 Nov 2014 14:00:38 +0000
> Subject: [PATCH] libxl: Allow libxl to find pygrub binary.
> 
> Specifying an explicit path to pygrub (e.g. BINDIR "/pygrub") only works if
> Xen and libvirt happen to be installed to the same prefix. A more flexible
> approach is to simply specify "pygrub" which will cause libxl to use the
> correct path which it knows (since it is built with the same prefix as pygrub).
> 
> This is particular problematic in the Debian packaging, since the Debian Xen
> package relocates pygrub into a libexec dir, however I think this change makes
> sense upstream.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  .gnulib                |    2 +-
>  src/libxl/libxl_conf.h |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/.gnulib b/.gnulib
> index 9565c3b..2d28074 160000
> --- a/.gnulib
> +++ b/.gnulib
> @@ -1 +1 @@
> -Subproject commit 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d
> +Subproject commit 2d280742a9e30088aa169f53353765d5daafe4c0
> diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
> index 25f77ea..d7a3971 100644
> --- a/src/libxl/libxl_conf.h
> +++ b/src/libxl/libxl_conf.h
> @@ -53,7 +53,7 @@
>  # define LIBXL_LIB_DIR LOCALSTATEDIR "/lib/libvirt/libxl"
>  # define LIBXL_SAVE_DIR LIBXL_LIB_DIR "/save"
>  # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump"
> -# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
> +# define LIBXL_BOOTLOADER_PATH "pygrub"
>  
>  /* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new
>   * parameter has been added, representative of 'VCPU soft affinity'. If one



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:44:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:44:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsFz-0008Nu-FG; Fri, 21 Nov 2014 17:44:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrsFx-0008Np-La
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 17:44:29 +0000
Content-Length: 18413
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	86/62-02953-DF97F645; Fri, 21 Nov 2014 17:44:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416591866!13499708!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22233 invoked from network); 21 Nov 2014 17:44:27 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:44:27 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALHgLA3027093
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:42:22 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sALHgGRb017324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:42:17 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHgGbv021466; Fri, 21 Nov 2014 17:42:16 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:42:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0FF83118AA5; Fri, 21 Nov 2014 12:42:11 -0500 (EST)
From: konrad.wilk@oracle.com
To: <tiejun.chen@intel.com>, <konrad.wilk@oracle.com>,
	<andrew.cooper3@citrix.com>, <avanzini.arianna@gmail.com>,
	<boris.ostrovsky@oracle.com>, <ufimtseva@gmail.com>,
	<guijianfeng@cn.fujitsu.com>, <eddie.dong@intel.com>,
	<roger.pau@citrix.com>, <artem.mygaiev@globallogic.com>,
	<ian.jackson@eu.citrix.com>, <daniel.kiper@oracle.com>,
	<ian.campbell@citrix.com>, <Ian.Jackson@eu.citrix.com>,
	<Kelly.Zytaruk@amd.com>, <anthony.perard@citrix.com>,
	<mukesh.rathor@oracle.com>, <dslutz@verizon.com>, <aravindp@cisco.com>, 
	<josh.whitehead@dornerworks.com>, <robert.vanvossen@dornerworks.com>,
	<Paul.Skentzos@dornerworks.com>, <Steve.VanderLeest@dornerworks.com>,
	<andrii.tseglytskyi@globallogic.com>, <yang.z.zhang@intel.com>,
	<ross.lagerwall@citrix.com>, <malcolm.crossley@citrix.com>,
	<george.dunlap@eu.citrix.com>, <bob.liu@oracle.com>,
	<yjhyun.yoo@samsung.com>, <serge.broslavsky@linaro.org>,
	<christoffer.dall@linaro.org>, <julien.grall@linaro.org>,
	<manishjaggi.oss@gmail.com>, <caobosimon@gmail.com>, <jgross@suse.com>, 
	<olaf@aepfle.d.e>, <wency@cn.fujitsu.com>, <dave.scott@citrix.com>,
	<david.vrabel@citrix.com>, <yanghy@cn.fujitsu.com>,
	<zhigang.x.wang@oracle.com>, <Wei.Liu2@citrix.com>,
	<xen-devel@lists.xenproject.org>, <stefano.stabellini@eu.citrix.com>,
	<tklengyel@sec.in.tum.de>, <suriyan.r@gmail.com>,
	<vijay.kilari@gmail.com>, <Vijaya.Kumar@caviumnetworks.com>,
	<talex5@gmail.com>, <parth.dixit@linaro.org>,
	<Ian.Campbell@citrix.com>, <roy.franz@linaro.org>,
	<chao.p.peng@linux.intel.com>, <mengxu@cis.upenn.edu>,
	<rcojocaru@bitdefender.com>, <feng.wu@intel.com>,
	<Aravind.Gopalakrishnan@amd.com>, <Suravee.Suthikulpanit@amd.com>,
	<Paul.Durrant@citrix.com>, <dario.faggioli@citrix.com>,
	<m.a.young@durham.ac.uk>, <mcgrof@suse.com>
Message-Id: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
Date: Fri, 21 Nov 2014 12:42:11 -0500 (EST)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] Xen 4.5-rc2 post update (RC2 was out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1771986765291969522=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1771986765291969522==
Content-Length: 18616
Content-Transfer-Encoding: quoted-printable

Feature patchsets that did not make it in by today have been put
on the deferred list. If you think your feature should make it by Xen 4.5-RC3
please make your case.

Xen 4.5-rc2 was out on Monday (11th). There are three known issues, if I have
missed one (or more) please respond.

(see 'Known Issues' below) which are to be fixed by RC3 - if:
 - The maintainers are fine with it,
 - The risk is minimal to common code paths.

Details for the test-day are at

http://wiki.xen.org/wiki/Xen_4.5_RC2_test_instructions

In terms of bugs, we have:

#11 qxl hypervisor support
#13 Re: [Xen-devel] man page example: xm block-attach
#18 xl improve support for migration over non-sshlike tunnels
#19 xl migrate transport improvements
#22 xl does not support specifying virtual function for passthrough device
#23 Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks
#24 xl missing support for encrypted VNC
#27 Re: [Xen-devel] xend vs xl with pci=3D['<bdf'] wherein the '<bdf>' are not owned by pciback or pcistub will still launch.
#28 support PCI hole resize in qemu-xen

[Isn't this fixed by Don's 'mmio_hole' patches=3F]

#30 libxl should implement non-suspend-cancel based resume path
#36 credit2 only uses one runqueue instead of one runq per socket
#38 Implement VT-d large pages so we can avoid sharing between EPT
#40 linux pvops: fpu corruption due to incorrect assumptions
#42 "linux, S3 resume of PVHVM fails - missing call to xen_arch_post_suspend=3F"
#43 "30s delay loading xenfb driver on some systems"
#44 Security policy ambiguities - XSA-108 process post-mortem
#45 arm: domain 0 disables clocks which are in fact being used


=3D Timeline =3D

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:


* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
* RC2: Nov 11th
* RC2 Test-day: Nov 13th

 <=3D=3D=3D=3D WE ARE HERE =3D=3D=3D>

* RC3: Nov 24th
* RC3 Test-day: Nov 25th
* Release: 10th December 2014

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  The feature freeze may be
slipped for especially important features which are near completion.

Bug-fixes, if Acked-by by maintainer, can go anytime before the First
RC. Later on we will need to figure out the risk of regression/reward
to eliminate the possiblity of a bug introducing another bug.

=3D Prognosis =3D

The states are: none -> fair -> ok -> good -> done

none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok   - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs

=3D Feature freeze exception =3D

Remember our goal for the release:
  1. A bug-free release
  2. An awesome release
  3. An on-time release

Accepting a new feature may make Xen more awesome; but it also
introduces a risk that it will introduce more bugs.  That bug may be
found before the release (threatening #3), or it may not be found
until after the release (threatening #1).  Each freeze exception
request will attempt to balance the benefits (how awesome the
exception is) vs the risks (will it cause the release to slip, or
worse, cause a bug which goes un-noticed into the final release).

The idea is that today we will be pretty permissive, but that we will
become progressively more conservative until the first RC, which was
scheduled for 3 weeks' time (October 25).  After that, we will only
accept bug fixes.

Bug fixes can be checked in without a freeze exception throughout the
code freeze, unless the maintainer thinks they are particularly high
risk.  In later RC's, we may even begin rejecting bug fixes if the
broken functionality is small and the risk to other functionality is
high.

Document changes can go in anytime if the maintainer is OK with it.

Features which are currently marked "experimental" or do not at the
moment work at all cannot be broken really; so changes to code only
used by those features should be able to get a freeze exception
easily.

Features which change or add new interfaces which will need to be
supported in a backwards-compatible way (for instance, vNUMA) will
need freeze exceptions to make sure that the interface itself has
enough time to be considered stable.

These are guidelines and principles to give you an idea where we're
coming from; if you think there's a good reason why making an
exception for you will help us achieve goals 1-3 above better than not
doing so, feel free to make your case.

=3D Open =3D

=3D=3D Known issues =3D=3D 

*  xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/RAM (good)
   RFC v6
   Treating pieces as bug-fixes only.
  -  Tiejun Chen

*  PCI passthrough of INTx legacy devices can trigger list corruption (good)
   Sander reported it. Two different types of patches available.
  -  Konrad Rzeszutek Wilk

*  pygrub does not handle certain configurations. (fair)
   an RFC patch posted.
  -  Andrew Cooper

=3D=3D Linux =3D=3D 

*  Linux block multiqueue (ok)
   v2 posted.
  -  Arianna Avanzini

*  VPMU - 'perf' support in Linux (ok)
   Depends on Xen patches
   Acked by David Vrabel
  -  Boris Ostrovsky

*  vNUMA in Linux (ok)
   v6 posted
   git://gitorious.org/vnuma/linux_vnuma.git
  -  Elena Ufimtseva

*  vsyscall in Linux (fair)
  -  Konrad Rzeszutek Wilk

*  COLO Agent in Linux (fair)
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  vAPIC in PVHVM guests (Linux side) (none)
  -  Boris Ostrovsky

=3D=3D FreeBSD =3D=3D 

*  PVH FreeBSD dom0 (ok)
   FreeBSD 11 goal. Toolstack side done in Xen 4.5
  -  Roger Pau Monn=C3=A9

=3D=3D Other OSes (MiniOS, QNX) =3D=3D 

*  PV drivers for automotive kernels (fair)
  -  Artem Mygaiev

*  mini-os: xenbus changes for rump kernels (ok)
   git://xenbits.xen.org/people/iwj/rumpuser-xen.git
   branch: base.dev-xen-xenbus.v1..dev-xen-xenbus.v1
   v2 posted
  -  Ian Jackson

=3D=3D GRUB2 =3D=3D 

*  GRUB2 multiboot2 (fair)
  -  Daniel Kiper

=3D=3D OSSTEST =3D=3D 

*  OSSTest: libvirt (good)
  -  Ian Campbell

=3D=3D Deferred to QEMU v2.next =3D=3D 

*  Using qemu-upstream in a stubdomain (fair)
   Will use rump kernels.
  -  Ian Jackson

*  AMD Radeon PCI GPU passthrough (none)
   Focusing on Xen 4.2 and qemu-traditional
  -  Kelly Zytaruk

*  Intel IGD PCI GPU passthrough (ok)
   v5 posted
  -  Chen, Tiejun

*  Update Xen tree to use upstream OVMF (fair)
  -  Anthony PERARD

=3D=3D Deferred to Xen hypervisor 4.6 =3D=3D 

*  VPMU - 'perf' support in Xen (good)
   v14 posted
   Need reviews/final ack.
  -  Boris Ostrovsky

*  Xen Boot Information (xbi) (ok)
   Dependency for GRUB2 + EFI work
   http://lists.xen.org/archives/html/xen-devel/2014-10/msg02068.html
   v4, No go for full patchset. Only some of the patches.
   No ARM EFI hardware (yet) available to test them.
  -  Daniel Kiper

*  PVH - AMD hardware support. (fair)
   Posted.
  -  Mukesh Rathor

*  VMware backdoor (hypercall) (ok)
   v5 posted.
  -  Don Slutz

*  extending mem_access support to PV domain (fair)
   RFC v2
  -  Aravindh Puthiyaparambil (aravindp)

*  Repurpose SEDF Scheduler for Real-time (fair)
   RFC patch posted (v2)
  -  Joshua Whitehead, Robert VanVossen

*  ARM remote processor iommu module (GPUs + IPUs) (fair)
   v3 posted
  -  Andrii Tseglytskyi

*  dirty vram / IOMMU bug (fair)
   http://bugs.xenproject.org/xen/bug/38
  -  Zhang, Yang Z

*  Xen multiboot2-EFI support (fair)
   Needed for GrUB2
   Depends on Xen Boot info (rework multiboot and other structs)
   See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html
   RFC posted
  -  Daniel Kiper

*  Support controlling the max C-state sub-state (fair)
   v3 posted
   Hadn't see the patch reposted.
  -  Ross Lagerwall

*  IOMMU ABI for guests to map their DMA regions (fair)
  -  Malcolm Crossley

*  Default to credit2 (none)
   cpu pinning, numa affinity and cpu reservation
  -  George Dunlap

*  Convert tasklet to per-cpu tasklets (fair)
   RFC posted
  -  Konrad Rzeszutek Wilk

*  Further tmem cleanups/fixes (16TB etc) (fair)
  -  Bob Liu

*  1TB slow destruction (ok)
  -  Bob Liu

*  ARM VM save/restore/live migration (none)
   Need to rebased against migrationv2 - no code posted.
  -  Junghyun Yoo

*  ARM GICv2m support (none)
  -  Linaro (unknown)

*  ARM - SMMU resync of Linux's one (none)
  -  Julien Grall

*  ARM - passthrough of non-PCI (none)
  -  Julien Grall

*  ARM64 (Cavium Thunder)  PCI passthrough (fair)
  -  Manish Jaggi

*  ARM - Remove XEN_DOMCTL_arm_configure_domain band-aid and make it part of create_domain. (none)
  -  Julien Grall

=3D=3D Deferred to Xen toolstack 4.6 =3D=3D 

*  pvUSB support in libxl (none)
  -  Simon Cao

*  vNUMA in Xen toolstack (ok)
   v11 posted
   Hypervisor part in
   git://gitorious.org/vnuma/xen_vnuma.git:v11
  -  Elena Ufimtseva

*  pvscsi in libxl (fair)
  -  Juergen Gross and Olaf

*  COarse-grain LOck-stepping Virtual Machines in Xen (fair)
   RFC v3 posted, based on remus-v19
  -  Wen Congyang
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  extend the xenstore ring with a 'closing' signal (fair)
   RFC patch posted
  -  David Scott

*  New Migration (v2). (good)
   v7 (libxc and libxl)
   git://xenbits.xen.org/people/andrewcoop/xen.git
   Seems that it might need to slip or we run v1 alongside v2.
  -  Andrew Cooper & David Vrabel

*  libxl migrationv2 patches. (none)
  -  Andrew Cooper & David Vrabel

*  tmem migrationv2 patches. (none)
  -  Bob Liu & Andrew Cooper & David Vrabel

*  Remus using migration-v2 (fair)
   RFC posted - depends on v6 of 'New Migration'
  -  Yang Hongyang

*  snapshot API extension (checkpointing disk) (ok)
   v5
   His email bounces.
  -  Bamvor Jian Zhang

*  Rearrange and cleanup installation destination directories (/var -> var/lib/xen) (fair)
  -  Daniel Kiper

*  libxl/xl - xm compatibility mode for mem-max and mem-set; (ok)
  -  Daniel Kiper

*  xl list --long (and some related xl commands) have some bugs (none)
  -  Zhigang Wang

*  Xen HPET interrupt fixes (fair)
   behind migration v2
  -  Andrew Cooper

*  cpuid leveling (none)
   http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-D.pdf
  -  Andrew Cooper

*  live migration knobs, there is no suitable code yet, just ideas (none)
    http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html
  -  Olaf Hering

*  xl does not handle migrate interruption gracefully (none)
   If you start a localhost migrate, and press "Ctrl-C" in the middle, you get two hung domains
  -  Ian Jackson

*  IO-NUMA - hwloc and xl (none)
   Andrew Cooper had an RFC patch for hwloc
   add restrictions  as to which devices cannot safely/functionally be split apart.
  -  Boris Ostrovsky

*  HVM guest NUMA (SRAT) (fair)
   RFC posted.
  -  Wei Liu

*  PVH - Migration of PVH DomUs. (none)
   Depends on migration2 code
  -  Roger Pau Monn=C3=A9

*  PVH - Migration of guests from a PVH dom0  (none)
   Depends on migration2 code
  -  Roger Pau Monn=C3=A9

=3D=3D Deferred to Linux's after Xen 4.6 =3D=3D 

*  Linux ARM - Device assigment usage in Linux code (arch/arm) non-PCI (none)
   Depends on Xen pieces which are on the Xen 4.6 list.
  -  Julien Grall

*  Linux ARM - Device assigment (PCI) (none)
   Depends on Xen pieces which are on the Xen 4.6 list.
  -  Manish Jaggi

*  pvUSB in Linux (fronted and backend) (Fair)
  -  Juergen Gross

=3D=3D Up for grabs =3D=3D 

*  OSSTest - also test Linux PVH guests

*  PoD fixes
   if you boot with memory <=3D maxmem we have a size estimation bug

*  TLB flushing without locks in Xen

*  xl does not support specifying virtual function for passthrough device
   http://bugs.xenproject.org/xen/bug/22

*  PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with PCI/GPU passthrough
   http://bugs.xenproject.org/xen/bug/28

*  libx{c,l} error handling cleanup 

*  Adding missing 'xend' features in libxl

*  xl list -l on a dom0-only system

*  xl list -l doesn't contain tty console port

*  xl: passing more defaults in configuration in xl.conf
   There are a number of options for which it might be useful to pass a default in xl.conf.  For example, if we could have a default "backend" parameter for vifs, then it would be easy to switch back and forth between a backend in a driver domain and a backend in dom0.

*  PVH - PVH working with shadow.
   Based on Tim's work

*  PVH - PCI passthrough for DomU.

*  AMD performance regressions

*  Performance due to hypercall preemption. More preemptions - slower. (none)

=3D=3D Completed =3D=3D 

=3D=3D Hypervisor =3D=3D 

*  ARM - introduce GNTTABOP_cache_flush (ok)
   v11
  -  Stefano Stabellini

*  ARM - VGIC emulation (done)
   Reposted as gic and vgic fixes and improvements
   v12
  -  Stefano Stabellini

*  ARM implement mem_access (done)
   v12, two patches for Xen 4.6
   https://github.com/tklengyel/xen/tree arm_memaccess_12-for-4.5
  -  Tamas K Lengyel

*  ARM - Add Odroid-XU (Exynos5410) support (done)
   v6
  -  Suriyan Ramasami

*  ARM GICv3 support (done)
   v11 posted
  -  Vijay Kilari

*  ARM implement mem_access (done)
   v12, two patches for Xen 4.6
   https://github.com/tklengyel/xen/tree arm_memaccess_12-for-4.5
  -  Tamas K Lengyel

*  ARM - MiniOS (done)
   v7 posted
  -  Thomas Leonard

*  ARM XEN_DOMCTL_memory_mapping hypercall for ARM (done)
   v12 posted.
  -  Arianna Avanzini

*  ARM - XENFEAT_grant_map_11 (aka map grants refs at pfn =3D mfn) (done)
   Provide kernels an grant->MFN lookup
   v4
  -  Stefano Stabellini

*  ARM PSCI v0.2 (done)
   v11 posted
  -  Parth Dixit

*  ARM  - IOMMU support (done)
  -  Julien Grall

*  ARM Interrupt latency reduction (no maintenance interrupts) (done)
  -  Stefano Stabellini

*  ARM DRA7 support (done)
   v3 posted
   v3 with comments applied
  -  Andrii Tseglytskyi

*  ARM: Use super pages in p2m (done)
   v5 posted
  -  Ian Campbell

*  ARM Xen UEFI booting on ARM (done)
   v5
  -  Roy Franz

*  Cache QoS Monitoring - hypercalls (done)
   Just hypercalls - no toolstack changes.
   v15
   Hit a snag with rdmsr/IPI/wrmsr/IPI, possible redesign
  -  Chao Peng, Dongxiao Xu, and Shantong Kang

*  XenRT (Preemptive Global Earliest Deadline First) (done)
   v3
  -  Meng Xu

*  Introspection of HVM guests (done)
   v10, split out in for 4.5 (smaller subset)
  -  Razvan Cojocaru

*  alternative_asm in Xen (done)
  -  Feng Wu

*  SMAP (done)
  -  Feng Wu

*  Re-write of vHPET (done)
   aka hvm/hpet: Detect comparator values in the past
  -  Don Slutz

*  vAPIC in PVHVM guests (Xen side) (done)
  -  Boris Ostrovsky

*  Xen PVH dom0 (done)
  -  Mukesh Rathor

*  amd_ucode cleanups, verify patch size(enhancement) (mostly in master except one patch)

*  Data breakpoint Extension support (new-feat) (in master)

*  Feature masking MSR support (enhancement) (in master)

*  Support BRCM TruManage chip (Serial over LAN support) (new-feat) (in master)

*  fix vmce_amd* functions, unify mce_amd mcheck initialization (fixes/cleanups)

*  multiple AMD container files appended together in initrd (early initramfs)
  -  Aravind and Suravee

*  NUMA memory scrubbing (done)
  -  Konrad Rzeszutek Wilk

*  ioreq-server, aka secondary emulators (done)
  -  Paul Durrant

*  Soft affinity for vcpus (was NUMA affinity for vcpus) (good)
   v11 posted
  -  Dario Faggioli

*  HT enabled, virtualization overhead is high (Xen 4.4) (done)
   kernbench demonstrated it
   Looking and tracing
   http://www.gossamer-threads.com/lists/xen/devel/339409
   False alarm.
  -  Dario Faggioli

=3D=3D lib{xc,xl} and toolstack =3D=3D 

*  Systemd integration (done)
   Affects CentOS7, SLES12, Fedora Core 21 and Debian Jessie. Xen source contains systemd files that can be used to configure the various run-time services. In the past the distributions would carry their own version of it - but now we host them. This is not yet complete - [[http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg03064.html patches]] for this are being worked on for RC2.
  -  Wei and Olaf

*  Stubdomains build issues (done)
   stubdomains will not build. Fix is in staging (and will make RC2) or [[http://lists.xen.org/archives/html/xen-devel/2014-10/msg02925.html stubdom/Makefile should use QEMU_TRADITIONAL_LOC]]
  -  Michael Young

*  Building against libxl (outside code) (done)
   If you are building against libxl for any APIs before Xen 4.5 you will encounter building errors.
  -  Andrew Cooper

*  Build systems fixes/improvements (done)
  -  Andrew Cooper

*  libxl work - JSON to keep track of guest configs (done)
   Some patches merged, need to post more.
  -  Wei Liu

*  Remus in Xen (libxl) (done)
   v19
   url:  https://github.com/macrosheep/xen/tree/remus-v19
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  libvirt and xl discard support, so that libvirt can start using it (done)
  -  Olaf Hering

*  OSSTest: upstream QEMU (done)
  -  Ian Campbell

*  rework VM Generation ID (done)
   v7 posted
  -  David Vrabel

*  systemd support (done)
   v11
  -  Luis R. Rodriguez

*  Soft affinity for vcpus libxl/xl changes (done)
   v13 posted
  -  Dario Faggioli

=3D=3D QEMU =3D=3D 

*  Bigger PCI hole in QEMU (done)
   Needs to be rebased
  -  Don Slutz

*  QEMU 2.0 branch for qemu-upstream (done)
   It is v2.0 with 2.1 Xen backports.
  -  Stefano Stabellini

*  Xen PV block driver in OVMF (UEFI in guest) (done)
   v3
   In OVMF upstream. Not part of Xen 4.5
  -  Anthony PERARD

=3D=3D Linux 3.18 and earlier =3D=3D 

*  pvSCSI in Linux (fronted and backend) (done)
   v6
  -  Juergen Gross

*  Linux PVH dom0 (done)
  -  Mukesh Rathor

*  Netback multiqueue (good)
  -  Wei Liu

*  Linux pvops of Xen EFI hypercall support (done)
  -  Daniel Kiper

*  "Short" grant copy (just header) of packets. (done)
  -  Zoltan Kiss

*  Fix PAT in Linux kernel (aka Full support for PAT) (done)
   Acked and reposted for v3.18. Waiting for x86 maintainers.
   Ingo has been giving advice.
   In for 3.19
  -  Juergen Gross



--===============1771986765291969522==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1771986765291969522==--

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:44:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:44:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsFz-0008Nu-FG; Fri, 21 Nov 2014 17:44:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrsFx-0008Np-La
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 17:44:29 +0000
Content-Length: 18413
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	86/62-02953-DF97F645; Fri, 21 Nov 2014 17:44:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416591866!13499708!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22233 invoked from network); 21 Nov 2014 17:44:27 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:44:27 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALHgLA3027093
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 17:42:22 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sALHgGRb017324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 17:42:17 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALHgGbv021466; Fri, 21 Nov 2014 17:42:16 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 09:42:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0FF83118AA5; Fri, 21 Nov 2014 12:42:11 -0500 (EST)
From: konrad.wilk@oracle.com
To: <tiejun.chen@intel.com>, <konrad.wilk@oracle.com>,
	<andrew.cooper3@citrix.com>, <avanzini.arianna@gmail.com>,
	<boris.ostrovsky@oracle.com>, <ufimtseva@gmail.com>,
	<guijianfeng@cn.fujitsu.com>, <eddie.dong@intel.com>,
	<roger.pau@citrix.com>, <artem.mygaiev@globallogic.com>,
	<ian.jackson@eu.citrix.com>, <daniel.kiper@oracle.com>,
	<ian.campbell@citrix.com>, <Ian.Jackson@eu.citrix.com>,
	<Kelly.Zytaruk@amd.com>, <anthony.perard@citrix.com>,
	<mukesh.rathor@oracle.com>, <dslutz@verizon.com>, <aravindp@cisco.com>, 
	<josh.whitehead@dornerworks.com>, <robert.vanvossen@dornerworks.com>,
	<Paul.Skentzos@dornerworks.com>, <Steve.VanderLeest@dornerworks.com>,
	<andrii.tseglytskyi@globallogic.com>, <yang.z.zhang@intel.com>,
	<ross.lagerwall@citrix.com>, <malcolm.crossley@citrix.com>,
	<george.dunlap@eu.citrix.com>, <bob.liu@oracle.com>,
	<yjhyun.yoo@samsung.com>, <serge.broslavsky@linaro.org>,
	<christoffer.dall@linaro.org>, <julien.grall@linaro.org>,
	<manishjaggi.oss@gmail.com>, <caobosimon@gmail.com>, <jgross@suse.com>, 
	<olaf@aepfle.d.e>, <wency@cn.fujitsu.com>, <dave.scott@citrix.com>,
	<david.vrabel@citrix.com>, <yanghy@cn.fujitsu.com>,
	<zhigang.x.wang@oracle.com>, <Wei.Liu2@citrix.com>,
	<xen-devel@lists.xenproject.org>, <stefano.stabellini@eu.citrix.com>,
	<tklengyel@sec.in.tum.de>, <suriyan.r@gmail.com>,
	<vijay.kilari@gmail.com>, <Vijaya.Kumar@caviumnetworks.com>,
	<talex5@gmail.com>, <parth.dixit@linaro.org>,
	<Ian.Campbell@citrix.com>, <roy.franz@linaro.org>,
	<chao.p.peng@linux.intel.com>, <mengxu@cis.upenn.edu>,
	<rcojocaru@bitdefender.com>, <feng.wu@intel.com>,
	<Aravind.Gopalakrishnan@amd.com>, <Suravee.Suthikulpanit@amd.com>,
	<Paul.Durrant@citrix.com>, <dario.faggioli@citrix.com>,
	<m.a.young@durham.ac.uk>, <mcgrof@suse.com>
Message-Id: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
Date: Fri, 21 Nov 2014 12:42:11 -0500 (EST)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] Xen 4.5-rc2 post update (RC2 was out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1771986765291969522=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1771986765291969522==
Content-Length: 18616
Content-Transfer-Encoding: quoted-printable

Feature patchsets that did not make it in by today have been put
on the deferred list. If you think your feature should make it by Xen 4.5-RC3
please make your case.

Xen 4.5-rc2 was out on Monday (11th). There are three known issues, if I have
missed one (or more) please respond.

(see 'Known Issues' below) which are to be fixed by RC3 - if:
 - The maintainers are fine with it,
 - The risk is minimal to common code paths.

Details for the test-day are at

http://wiki.xen.org/wiki/Xen_4.5_RC2_test_instructions

In terms of bugs, we have:

#11 qxl hypervisor support
#13 Re: [Xen-devel] man page example: xm block-attach
#18 xl improve support for migration over non-sshlike tunnels
#19 xl migrate transport improvements
#22 xl does not support specifying virtual function for passthrough device
#23 Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks
#24 xl missing support for encrypted VNC
#27 Re: [Xen-devel] xend vs xl with pci=3D['<bdf'] wherein the '<bdf>' are not owned by pciback or pcistub will still launch.
#28 support PCI hole resize in qemu-xen

[Isn't this fixed by Don's 'mmio_hole' patches=3F]

#30 libxl should implement non-suspend-cancel based resume path
#36 credit2 only uses one runqueue instead of one runq per socket
#38 Implement VT-d large pages so we can avoid sharing between EPT
#40 linux pvops: fpu corruption due to incorrect assumptions
#42 "linux, S3 resume of PVHVM fails - missing call to xen_arch_post_suspend=3F"
#43 "30s delay loading xenfb driver on some systems"
#44 Security policy ambiguities - XSA-108 process post-mortem
#45 arm: domain 0 disables clocks which are in fact being used


=3D Timeline =3D

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:


* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
* RC2: Nov 11th
* RC2 Test-day: Nov 13th

 <=3D=3D=3D=3D WE ARE HERE =3D=3D=3D>

* RC3: Nov 24th
* RC3 Test-day: Nov 25th
* Release: 10th December 2014

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  The feature freeze may be
slipped for especially important features which are near completion.

Bug-fixes, if Acked-by by maintainer, can go anytime before the First
RC. Later on we will need to figure out the risk of regression/reward
to eliminate the possiblity of a bug introducing another bug.

=3D Prognosis =3D

The states are: none -> fair -> ok -> good -> done

none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok   - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs

=3D Feature freeze exception =3D

Remember our goal for the release:
  1. A bug-free release
  2. An awesome release
  3. An on-time release

Accepting a new feature may make Xen more awesome; but it also
introduces a risk that it will introduce more bugs.  That bug may be
found before the release (threatening #3), or it may not be found
until after the release (threatening #1).  Each freeze exception
request will attempt to balance the benefits (how awesome the
exception is) vs the risks (will it cause the release to slip, or
worse, cause a bug which goes un-noticed into the final release).

The idea is that today we will be pretty permissive, but that we will
become progressively more conservative until the first RC, which was
scheduled for 3 weeks' time (October 25).  After that, we will only
accept bug fixes.

Bug fixes can be checked in without a freeze exception throughout the
code freeze, unless the maintainer thinks they are particularly high
risk.  In later RC's, we may even begin rejecting bug fixes if the
broken functionality is small and the risk to other functionality is
high.

Document changes can go in anytime if the maintainer is OK with it.

Features which are currently marked "experimental" or do not at the
moment work at all cannot be broken really; so changes to code only
used by those features should be able to get a freeze exception
easily.

Features which change or add new interfaces which will need to be
supported in a backwards-compatible way (for instance, vNUMA) will
need freeze exceptions to make sure that the interface itself has
enough time to be considered stable.

These are guidelines and principles to give you an idea where we're
coming from; if you think there's a good reason why making an
exception for you will help us achieve goals 1-3 above better than not
doing so, feel free to make your case.

=3D Open =3D

=3D=3D Known issues =3D=3D 

*  xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/RAM (good)
   RFC v6
   Treating pieces as bug-fixes only.
  -  Tiejun Chen

*  PCI passthrough of INTx legacy devices can trigger list corruption (good)
   Sander reported it. Two different types of patches available.
  -  Konrad Rzeszutek Wilk

*  pygrub does not handle certain configurations. (fair)
   an RFC patch posted.
  -  Andrew Cooper

=3D=3D Linux =3D=3D 

*  Linux block multiqueue (ok)
   v2 posted.
  -  Arianna Avanzini

*  VPMU - 'perf' support in Linux (ok)
   Depends on Xen patches
   Acked by David Vrabel
  -  Boris Ostrovsky

*  vNUMA in Linux (ok)
   v6 posted
   git://gitorious.org/vnuma/linux_vnuma.git
  -  Elena Ufimtseva

*  vsyscall in Linux (fair)
  -  Konrad Rzeszutek Wilk

*  COLO Agent in Linux (fair)
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  vAPIC in PVHVM guests (Linux side) (none)
  -  Boris Ostrovsky

=3D=3D FreeBSD =3D=3D 

*  PVH FreeBSD dom0 (ok)
   FreeBSD 11 goal. Toolstack side done in Xen 4.5
  -  Roger Pau Monn=C3=A9

=3D=3D Other OSes (MiniOS, QNX) =3D=3D 

*  PV drivers for automotive kernels (fair)
  -  Artem Mygaiev

*  mini-os: xenbus changes for rump kernels (ok)
   git://xenbits.xen.org/people/iwj/rumpuser-xen.git
   branch: base.dev-xen-xenbus.v1..dev-xen-xenbus.v1
   v2 posted
  -  Ian Jackson

=3D=3D GRUB2 =3D=3D 

*  GRUB2 multiboot2 (fair)
  -  Daniel Kiper

=3D=3D OSSTEST =3D=3D 

*  OSSTest: libvirt (good)
  -  Ian Campbell

=3D=3D Deferred to QEMU v2.next =3D=3D 

*  Using qemu-upstream in a stubdomain (fair)
   Will use rump kernels.
  -  Ian Jackson

*  AMD Radeon PCI GPU passthrough (none)
   Focusing on Xen 4.2 and qemu-traditional
  -  Kelly Zytaruk

*  Intel IGD PCI GPU passthrough (ok)
   v5 posted
  -  Chen, Tiejun

*  Update Xen tree to use upstream OVMF (fair)
  -  Anthony PERARD

=3D=3D Deferred to Xen hypervisor 4.6 =3D=3D 

*  VPMU - 'perf' support in Xen (good)
   v14 posted
   Need reviews/final ack.
  -  Boris Ostrovsky

*  Xen Boot Information (xbi) (ok)
   Dependency for GRUB2 + EFI work
   http://lists.xen.org/archives/html/xen-devel/2014-10/msg02068.html
   v4, No go for full patchset. Only some of the patches.
   No ARM EFI hardware (yet) available to test them.
  -  Daniel Kiper

*  PVH - AMD hardware support. (fair)
   Posted.
  -  Mukesh Rathor

*  VMware backdoor (hypercall) (ok)
   v5 posted.
  -  Don Slutz

*  extending mem_access support to PV domain (fair)
   RFC v2
  -  Aravindh Puthiyaparambil (aravindp)

*  Repurpose SEDF Scheduler for Real-time (fair)
   RFC patch posted (v2)
  -  Joshua Whitehead, Robert VanVossen

*  ARM remote processor iommu module (GPUs + IPUs) (fair)
   v3 posted
  -  Andrii Tseglytskyi

*  dirty vram / IOMMU bug (fair)
   http://bugs.xenproject.org/xen/bug/38
  -  Zhang, Yang Z

*  Xen multiboot2-EFI support (fair)
   Needed for GrUB2
   Depends on Xen Boot info (rework multiboot and other structs)
   See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html
   RFC posted
  -  Daniel Kiper

*  Support controlling the max C-state sub-state (fair)
   v3 posted
   Hadn't see the patch reposted.
  -  Ross Lagerwall

*  IOMMU ABI for guests to map their DMA regions (fair)
  -  Malcolm Crossley

*  Default to credit2 (none)
   cpu pinning, numa affinity and cpu reservation
  -  George Dunlap

*  Convert tasklet to per-cpu tasklets (fair)
   RFC posted
  -  Konrad Rzeszutek Wilk

*  Further tmem cleanups/fixes (16TB etc) (fair)
  -  Bob Liu

*  1TB slow destruction (ok)
  -  Bob Liu

*  ARM VM save/restore/live migration (none)
   Need to rebased against migrationv2 - no code posted.
  -  Junghyun Yoo

*  ARM GICv2m support (none)
  -  Linaro (unknown)

*  ARM - SMMU resync of Linux's one (none)
  -  Julien Grall

*  ARM - passthrough of non-PCI (none)
  -  Julien Grall

*  ARM64 (Cavium Thunder)  PCI passthrough (fair)
  -  Manish Jaggi

*  ARM - Remove XEN_DOMCTL_arm_configure_domain band-aid and make it part of create_domain. (none)
  -  Julien Grall

=3D=3D Deferred to Xen toolstack 4.6 =3D=3D 

*  pvUSB support in libxl (none)
  -  Simon Cao

*  vNUMA in Xen toolstack (ok)
   v11 posted
   Hypervisor part in
   git://gitorious.org/vnuma/xen_vnuma.git:v11
  -  Elena Ufimtseva

*  pvscsi in libxl (fair)
  -  Juergen Gross and Olaf

*  COarse-grain LOck-stepping Virtual Machines in Xen (fair)
   RFC v3 posted, based on remus-v19
  -  Wen Congyang
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  extend the xenstore ring with a 'closing' signal (fair)
   RFC patch posted
  -  David Scott

*  New Migration (v2). (good)
   v7 (libxc and libxl)
   git://xenbits.xen.org/people/andrewcoop/xen.git
   Seems that it might need to slip or we run v1 alongside v2.
  -  Andrew Cooper & David Vrabel

*  libxl migrationv2 patches. (none)
  -  Andrew Cooper & David Vrabel

*  tmem migrationv2 patches. (none)
  -  Bob Liu & Andrew Cooper & David Vrabel

*  Remus using migration-v2 (fair)
   RFC posted - depends on v6 of 'New Migration'
  -  Yang Hongyang

*  snapshot API extension (checkpointing disk) (ok)
   v5
   His email bounces.
  -  Bamvor Jian Zhang

*  Rearrange and cleanup installation destination directories (/var -> var/lib/xen) (fair)
  -  Daniel Kiper

*  libxl/xl - xm compatibility mode for mem-max and mem-set; (ok)
  -  Daniel Kiper

*  xl list --long (and some related xl commands) have some bugs (none)
  -  Zhigang Wang

*  Xen HPET interrupt fixes (fair)
   behind migration v2
  -  Andrew Cooper

*  cpuid leveling (none)
   http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-D.pdf
  -  Andrew Cooper

*  live migration knobs, there is no suitable code yet, just ideas (none)
    http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html
  -  Olaf Hering

*  xl does not handle migrate interruption gracefully (none)
   If you start a localhost migrate, and press "Ctrl-C" in the middle, you get two hung domains
  -  Ian Jackson

*  IO-NUMA - hwloc and xl (none)
   Andrew Cooper had an RFC patch for hwloc
   add restrictions  as to which devices cannot safely/functionally be split apart.
  -  Boris Ostrovsky

*  HVM guest NUMA (SRAT) (fair)
   RFC posted.
  -  Wei Liu

*  PVH - Migration of PVH DomUs. (none)
   Depends on migration2 code
  -  Roger Pau Monn=C3=A9

*  PVH - Migration of guests from a PVH dom0  (none)
   Depends on migration2 code
  -  Roger Pau Monn=C3=A9

=3D=3D Deferred to Linux's after Xen 4.6 =3D=3D 

*  Linux ARM - Device assigment usage in Linux code (arch/arm) non-PCI (none)
   Depends on Xen pieces which are on the Xen 4.6 list.
  -  Julien Grall

*  Linux ARM - Device assigment (PCI) (none)
   Depends on Xen pieces which are on the Xen 4.6 list.
  -  Manish Jaggi

*  pvUSB in Linux (fronted and backend) (Fair)
  -  Juergen Gross

=3D=3D Up for grabs =3D=3D 

*  OSSTest - also test Linux PVH guests

*  PoD fixes
   if you boot with memory <=3D maxmem we have a size estimation bug

*  TLB flushing without locks in Xen

*  xl does not support specifying virtual function for passthrough device
   http://bugs.xenproject.org/xen/bug/22

*  PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with PCI/GPU passthrough
   http://bugs.xenproject.org/xen/bug/28

*  libx{c,l} error handling cleanup 

*  Adding missing 'xend' features in libxl

*  xl list -l on a dom0-only system

*  xl list -l doesn't contain tty console port

*  xl: passing more defaults in configuration in xl.conf
   There are a number of options for which it might be useful to pass a default in xl.conf.  For example, if we could have a default "backend" parameter for vifs, then it would be easy to switch back and forth between a backend in a driver domain and a backend in dom0.

*  PVH - PVH working with shadow.
   Based on Tim's work

*  PVH - PCI passthrough for DomU.

*  AMD performance regressions

*  Performance due to hypercall preemption. More preemptions - slower. (none)

=3D=3D Completed =3D=3D 

=3D=3D Hypervisor =3D=3D 

*  ARM - introduce GNTTABOP_cache_flush (ok)
   v11
  -  Stefano Stabellini

*  ARM - VGIC emulation (done)
   Reposted as gic and vgic fixes and improvements
   v12
  -  Stefano Stabellini

*  ARM implement mem_access (done)
   v12, two patches for Xen 4.6
   https://github.com/tklengyel/xen/tree arm_memaccess_12-for-4.5
  -  Tamas K Lengyel

*  ARM - Add Odroid-XU (Exynos5410) support (done)
   v6
  -  Suriyan Ramasami

*  ARM GICv3 support (done)
   v11 posted
  -  Vijay Kilari

*  ARM implement mem_access (done)
   v12, two patches for Xen 4.6
   https://github.com/tklengyel/xen/tree arm_memaccess_12-for-4.5
  -  Tamas K Lengyel

*  ARM - MiniOS (done)
   v7 posted
  -  Thomas Leonard

*  ARM XEN_DOMCTL_memory_mapping hypercall for ARM (done)
   v12 posted.
  -  Arianna Avanzini

*  ARM - XENFEAT_grant_map_11 (aka map grants refs at pfn =3D mfn) (done)
   Provide kernels an grant->MFN lookup
   v4
  -  Stefano Stabellini

*  ARM PSCI v0.2 (done)
   v11 posted
  -  Parth Dixit

*  ARM  - IOMMU support (done)
  -  Julien Grall

*  ARM Interrupt latency reduction (no maintenance interrupts) (done)
  -  Stefano Stabellini

*  ARM DRA7 support (done)
   v3 posted
   v3 with comments applied
  -  Andrii Tseglytskyi

*  ARM: Use super pages in p2m (done)
   v5 posted
  -  Ian Campbell

*  ARM Xen UEFI booting on ARM (done)
   v5
  -  Roy Franz

*  Cache QoS Monitoring - hypercalls (done)
   Just hypercalls - no toolstack changes.
   v15
   Hit a snag with rdmsr/IPI/wrmsr/IPI, possible redesign
  -  Chao Peng, Dongxiao Xu, and Shantong Kang

*  XenRT (Preemptive Global Earliest Deadline First) (done)
   v3
  -  Meng Xu

*  Introspection of HVM guests (done)
   v10, split out in for 4.5 (smaller subset)
  -  Razvan Cojocaru

*  alternative_asm in Xen (done)
  -  Feng Wu

*  SMAP (done)
  -  Feng Wu

*  Re-write of vHPET (done)
   aka hvm/hpet: Detect comparator values in the past
  -  Don Slutz

*  vAPIC in PVHVM guests (Xen side) (done)
  -  Boris Ostrovsky

*  Xen PVH dom0 (done)
  -  Mukesh Rathor

*  amd_ucode cleanups, verify patch size(enhancement) (mostly in master except one patch)

*  Data breakpoint Extension support (new-feat) (in master)

*  Feature masking MSR support (enhancement) (in master)

*  Support BRCM TruManage chip (Serial over LAN support) (new-feat) (in master)

*  fix vmce_amd* functions, unify mce_amd mcheck initialization (fixes/cleanups)

*  multiple AMD container files appended together in initrd (early initramfs)
  -  Aravind and Suravee

*  NUMA memory scrubbing (done)
  -  Konrad Rzeszutek Wilk

*  ioreq-server, aka secondary emulators (done)
  -  Paul Durrant

*  Soft affinity for vcpus (was NUMA affinity for vcpus) (good)
   v11 posted
  -  Dario Faggioli

*  HT enabled, virtualization overhead is high (Xen 4.4) (done)
   kernbench demonstrated it
   Looking and tracing
   http://www.gossamer-threads.com/lists/xen/devel/339409
   False alarm.
  -  Dario Faggioli

=3D=3D lib{xc,xl} and toolstack =3D=3D 

*  Systemd integration (done)
   Affects CentOS7, SLES12, Fedora Core 21 and Debian Jessie. Xen source contains systemd files that can be used to configure the various run-time services. In the past the distributions would carry their own version of it - but now we host them. This is not yet complete - [[http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg03064.html patches]] for this are being worked on for RC2.
  -  Wei and Olaf

*  Stubdomains build issues (done)
   stubdomains will not build. Fix is in staging (and will make RC2) or [[http://lists.xen.org/archives/html/xen-devel/2014-10/msg02925.html stubdom/Makefile should use QEMU_TRADITIONAL_LOC]]
  -  Michael Young

*  Building against libxl (outside code) (done)
   If you are building against libxl for any APIs before Xen 4.5 you will encounter building errors.
  -  Andrew Cooper

*  Build systems fixes/improvements (done)
  -  Andrew Cooper

*  libxl work - JSON to keep track of guest configs (done)
   Some patches merged, need to post more.
  -  Wei Liu

*  Remus in Xen (libxl) (done)
   v19
   url:  https://github.com/macrosheep/xen/tree/remus-v19
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  libvirt and xl discard support, so that libvirt can start using it (done)
  -  Olaf Hering

*  OSSTest: upstream QEMU (done)
  -  Ian Campbell

*  rework VM Generation ID (done)
   v7 posted
  -  David Vrabel

*  systemd support (done)
   v11
  -  Luis R. Rodriguez

*  Soft affinity for vcpus libxl/xl changes (done)
   v13 posted
  -  Dario Faggioli

=3D=3D QEMU =3D=3D 

*  Bigger PCI hole in QEMU (done)
   Needs to be rebased
  -  Don Slutz

*  QEMU 2.0 branch for qemu-upstream (done)
   It is v2.0 with 2.1 Xen backports.
  -  Stefano Stabellini

*  Xen PV block driver in OVMF (UEFI in guest) (done)
   v3
   In OVMF upstream. Not part of Xen 4.5
  -  Anthony PERARD

=3D=3D Linux 3.18 and earlier =3D=3D 

*  pvSCSI in Linux (fronted and backend) (done)
   v6
  -  Juergen Gross

*  Linux PVH dom0 (done)
  -  Mukesh Rathor

*  Netback multiqueue (good)
  -  Wei Liu

*  Linux pvops of Xen EFI hypercall support (done)
  -  Daniel Kiper

*  "Short" grant copy (just header) of packets. (done)
  -  Zoltan Kiss

*  Fix PAT in Linux kernel (aka Full support for PAT) (done)
   Acked and reposted for v3.18. Waiting for x86 maintainers.
   Ingo has been giving advice.
   In for 3.19
  -  Juergen Gross



--===============1771986765291969522==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1771986765291969522==--

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:47:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsIP-0008VW-6E; Fri, 21 Nov 2014 17:47:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrsIO-0008VQ-4P
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:47:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2E/60-15461-39A7F645; Fri, 21 Nov 2014 17:46:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416592016!14419817!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15006 invoked from network); 21 Nov 2014 17:46:57 -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 Nov 2014 17:46:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195328653"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 12:40:46 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrsCM-00012C-1t;
	Fri, 21 Nov 2014 17:40:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrsCL-0007sv-KU;
	Fri, 21 Nov 2014 17:40:45 +0000
Date: Fri, 21 Nov 2014 17:40:45 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31747-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31747: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31747 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31747/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          f6bdde8127b10e2bc3f21549dc9c960672ad7718
baseline version:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=f6bdde8127b10e2bc3f21549dc9c960672ad7718
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen f6bdde8127b10e2bc3f21549dc9c960672ad7718
+ branch=rumpuserxen
+ revision=f6bdde8127b10e2bc3f21549dc9c960672ad7718
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git f6bdde8127b10e2bc3f21549dc9c960672ad7718:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   9716ed6..f6bdde8  f6bdde8127b10e2bc3f21549dc9c960672ad7718 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:47:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsIP-0008VW-6E; Fri, 21 Nov 2014 17:47:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrsIO-0008VQ-4P
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 17:47:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2E/60-15461-39A7F645; Fri, 21 Nov 2014 17:46:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416592016!14419817!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15006 invoked from network); 21 Nov 2014 17:46:57 -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 Nov 2014 17:46:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195328653"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 12:40:46 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrsCM-00012C-1t;
	Fri, 21 Nov 2014 17:40:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrsCL-0007sv-KU;
	Fri, 21 Nov 2014 17:40:45 +0000
Date: Fri, 21 Nov 2014 17:40:45 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31747-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31747: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31747 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31747/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          f6bdde8127b10e2bc3f21549dc9c960672ad7718
baseline version:
 rumpuserxen          9716ed62cb1d73254b552e2077497d684c81639d

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=f6bdde8127b10e2bc3f21549dc9c960672ad7718
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen f6bdde8127b10e2bc3f21549dc9c960672ad7718
+ branch=rumpuserxen
+ revision=f6bdde8127b10e2bc3f21549dc9c960672ad7718
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git f6bdde8127b10e2bc3f21549dc9c960672ad7718:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   9716ed6..f6bdde8  f6bdde8127b10e2bc3f21549dc9c960672ad7718 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:54:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsPf-0000OM-4s; Fri, 21 Nov 2014 17:54:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XrsPe-0000OH-2b
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 17:54:30 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	D0/85-17694-55C7F645; Fri, 21 Nov 2014 17:54:29 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416592467!12991471!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1364 invoked from network); 21 Nov 2014 17:54:28 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:54:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416592468; x=1448128468;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=PmeLlhdtrAxdYZKPBUxka8N7mOi3AIN/NulbCnVTcxQ=;
	b=lHNjgSnhbkts0PUh2Hedax9iKFWGXnzQIVV731lTfWwD0w44hztDDkr1
	8WxATcjNmhbPDPcLdaJq+Nv2Lw0IlUNhGKCQDVwj7Pvbzy+ihuL3KSzys
	M/Hky+P1ZQuTt4O7nGzjcgl006mxpFU7ADUe04FNVG9wwOKumEaHM09BS A=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 21 Nov 2014 17:54:23 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="876515035"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([162.47.3.109])
	by fldsmtpi03.verizon.com with ESMTP; 21 Nov 2014 17:54:09 +0000
Message-ID: <546F7C40.8090906@terremark.com>
Date: Fri, 21 Nov 2014 12:54:08 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: konrad.wilk@oracle.com
References: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
In-Reply-To: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
Cc: artem.mygaiev@globallogic.com, Steve.VanderLeest@dornerworks.com,
	mengxu@cis.upenn.edu, m.a.young@durham.ac.uk,
	chao.p.peng@linux.intel.com, zhigang.x.wang@oracle.com,
	parth.dixit@linaro.org, boris.ostrovsky@oracle.com,
	manishjaggi.oss@gmail.com, Paul.Skentzos@dornerworks.com,
	vijay.kilari@gmail.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, daniel.kiper@oracle.com,
	josh.whitehead@dornerworks.com, avanzini.arianna@gmail.com,
	anthony.perard@citrix.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, feng.wu@intel.com,
	yjhyun.yoo@samsung.com, suriyan.r@gmail.com,
	ian.campbell@citrix.com, wency@cn.fujitsu.com,
	stefano.stabellini@eu.citrix.com, mcgrof@suse.com,
	julien.grall@linaro.org, talex5@gmail.com,
	robert.vanvossen@dornerworks.com, roy.franz@linaro.org,
	yang.z.zhang@intel.com, Paul.Durrant@citrix.com, olaf@aepfle.d.e,
	ufimtseva@gmail.com, andrii.tseglytskyi@globallogic.com,
	jgross@suse.com, dave.scott@citrix.com, yanghy@cn.fujitsu.com,
	Wei.Liu2@citrix.com, Vijaya.Kumar@caviumnetworks.com,
	george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	dario.faggioli@citrix.com, eddie.dong@intel.com,
	Kelly.Zytaruk@amd.com, dslutz@verizon.com,
	tklengyel@sec.in.tum.de, ross.lagerwall@citrix.com,
	Aravind.Gopalakrishnan@amd.com, david.vrabel@citrix.com,
	Suravee.Suthikulpanit@amd.com, aravindp@cisco.com,
	tiejun.chen@intel.com, malcolm.crossley@citrix.com,
	caobosimon@gmail.com, ian.jackson@eu.citrix.com,
	christoffer.dall@linaro.org, roger.pau@citrix.com
Subject: Re: [Xen-devel] Xen 4.5-rc2 post update (RC2 was out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/14 12:42, konrad.wilk@oracle.com wrote:
> Feature patchsets that did not make it in by today have been put
> on the deferred list. If you think your feature should make it by Xen 4.5-RC3
> please make your case.
>
> Xen 4.5-rc2 was out on Monday (11th). There are three known issues, if I have
> missed one (or more) please respond.
>
> (see 'Known Issues' below) which are to be fixed by RC3 - if:
>   - The maintainers are fine with it,
>   - The risk is minimal to common code paths.
>
> Details for the test-day are at
>
> http://wiki.xen.org/wiki/Xen_4.5_RC2_test_instructions
>
> In terms of bugs, we have:
>
> #11 qxl hypervisor support
> #13 Re: [Xen-devel] man page example: xm block-attach
> #18 xl improve support for migration over non-sshlike tunnels
> #19 xl migrate transport improvements
> #22 xl does not support specifying virtual function for passthrough device
> #23 Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks
> #24 xl missing support for encrypted VNC
> #27 Re: [Xen-devel] xend vs xl with pci=['<bdf'] wherein the '<bdf>' are not owned by pciback or pcistub will still launch.
> #28 support PCI hole resize in qemu-xen
>
> [Isn't this fixed by Don's 'mmio_hole' patches?]

I consider "mmio_hole" a work around for this.  The is more that can be done
here.

    -Don Slutz



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 17:54:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 17:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsPf-0000OM-4s; Fri, 21 Nov 2014 17:54:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XrsPe-0000OH-2b
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 17:54:30 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	D0/85-17694-55C7F645; Fri, 21 Nov 2014 17:54:29 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416592467!12991471!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1364 invoked from network); 21 Nov 2014 17:54:28 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 17:54:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416592468; x=1448128468;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=PmeLlhdtrAxdYZKPBUxka8N7mOi3AIN/NulbCnVTcxQ=;
	b=lHNjgSnhbkts0PUh2Hedax9iKFWGXnzQIVV731lTfWwD0w44hztDDkr1
	8WxATcjNmhbPDPcLdaJq+Nv2Lw0IlUNhGKCQDVwj7Pvbzy+ihuL3KSzys
	M/Hky+P1ZQuTt4O7nGzjcgl006mxpFU7ADUe04FNVG9wwOKumEaHM09BS A=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 21 Nov 2014 17:54:23 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="876515035"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([162.47.3.109])
	by fldsmtpi03.verizon.com with ESMTP; 21 Nov 2014 17:54:09 +0000
Message-ID: <546F7C40.8090906@terremark.com>
Date: Fri, 21 Nov 2014 12:54:08 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: konrad.wilk@oracle.com
References: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
In-Reply-To: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
Cc: artem.mygaiev@globallogic.com, Steve.VanderLeest@dornerworks.com,
	mengxu@cis.upenn.edu, m.a.young@durham.ac.uk,
	chao.p.peng@linux.intel.com, zhigang.x.wang@oracle.com,
	parth.dixit@linaro.org, boris.ostrovsky@oracle.com,
	manishjaggi.oss@gmail.com, Paul.Skentzos@dornerworks.com,
	vijay.kilari@gmail.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, daniel.kiper@oracle.com,
	josh.whitehead@dornerworks.com, avanzini.arianna@gmail.com,
	anthony.perard@citrix.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, feng.wu@intel.com,
	yjhyun.yoo@samsung.com, suriyan.r@gmail.com,
	ian.campbell@citrix.com, wency@cn.fujitsu.com,
	stefano.stabellini@eu.citrix.com, mcgrof@suse.com,
	julien.grall@linaro.org, talex5@gmail.com,
	robert.vanvossen@dornerworks.com, roy.franz@linaro.org,
	yang.z.zhang@intel.com, Paul.Durrant@citrix.com, olaf@aepfle.d.e,
	ufimtseva@gmail.com, andrii.tseglytskyi@globallogic.com,
	jgross@suse.com, dave.scott@citrix.com, yanghy@cn.fujitsu.com,
	Wei.Liu2@citrix.com, Vijaya.Kumar@caviumnetworks.com,
	george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	dario.faggioli@citrix.com, eddie.dong@intel.com,
	Kelly.Zytaruk@amd.com, dslutz@verizon.com,
	tklengyel@sec.in.tum.de, ross.lagerwall@citrix.com,
	Aravind.Gopalakrishnan@amd.com, david.vrabel@citrix.com,
	Suravee.Suthikulpanit@amd.com, aravindp@cisco.com,
	tiejun.chen@intel.com, malcolm.crossley@citrix.com,
	caobosimon@gmail.com, ian.jackson@eu.citrix.com,
	christoffer.dall@linaro.org, roger.pau@citrix.com
Subject: Re: [Xen-devel] Xen 4.5-rc2 post update (RC2 was out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/14 12:42, konrad.wilk@oracle.com wrote:
> Feature patchsets that did not make it in by today have been put
> on the deferred list. If you think your feature should make it by Xen 4.5-RC3
> please make your case.
>
> Xen 4.5-rc2 was out on Monday (11th). There are three known issues, if I have
> missed one (or more) please respond.
>
> (see 'Known Issues' below) which are to be fixed by RC3 - if:
>   - The maintainers are fine with it,
>   - The risk is minimal to common code paths.
>
> Details for the test-day are at
>
> http://wiki.xen.org/wiki/Xen_4.5_RC2_test_instructions
>
> In terms of bugs, we have:
>
> #11 qxl hypervisor support
> #13 Re: [Xen-devel] man page example: xm block-attach
> #18 xl improve support for migration over non-sshlike tunnels
> #19 xl migrate transport improvements
> #22 xl does not support specifying virtual function for passthrough device
> #23 Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks
> #24 xl missing support for encrypted VNC
> #27 Re: [Xen-devel] xend vs xl with pci=['<bdf'] wherein the '<bdf>' are not owned by pciback or pcistub will still launch.
> #28 support PCI hole resize in qemu-xen
>
> [Isn't this fixed by Don's 'mmio_hole' patches?]

I consider "mmio_hole" a work around for this.  The is more that can be done
here.

    -Don Slutz



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:05:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:05:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsZh-0000lh-Mr; Fri, 21 Nov 2014 18:04:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XrsZg-0000lW-JB
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 18:04:52 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	DB/D2-02696-3CE7F645; Fri, 21 Nov 2014 18:04:51 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416593089!14082121!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26542 invoked from network); 21 Nov 2014 18:04:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 18:04:51 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALI4k3h001045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 18:04:46 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALI4inm006825
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 18:04:44 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALI4iQd006818; Fri, 21 Nov 2014 18:04:44 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 10:04:44 -0800
Message-ID: <546F7EBA.6000207@oracle.com>
Date: Fri, 21 Nov 2014 13:04:42 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, konrad.wilk@oracle.com
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
	<20141114100939.GB30599@zion.uk.xensource.com>
	<1415960555.21321.28.camel@citrix.com>
In-Reply-To: <1415960555.21321.28.camel@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 05:22 AM, Ian Campbell wrote:
> On Fri, 2014-11-14 at 10:09 +0000, Wei Liu wrote:
>> On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
>>> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
>>>> Unconditionally print out the partial configuration.
>>>
>>> Can you provide an example of what such a configuration looks like?
>>>
>>
>>     {
>>         "domid": 2,
>>         "config": {
>>             "c_info": {
>>                 "name": "s0-raw-vnuma",
>>                 "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
>>             },
>>             "b_info": {
>>                 "sched_params": {
>>
>>                 },
>>                 "type.invalid": {
>>
>>                 }
>>             }
>>         }
>>     }
> 
> Great, thanks. I propose to insert this into the commit message as I
> check it in (once I check who's acked it etc)
> 
>> Libxl still complains because it tries to read some nodes that don't
>> exist, so xl will just print it out on stderr. This is the same
>> behaviour as before though.
> 
> I think that's tolerable for 4.5 at least.

I also think this is OK for 4.5.

Konrad: can pickup this for next rc?

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:05:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:05:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsZZ-0000lI-Aj; Fri, 21 Nov 2014 18:04:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrsZX-0000lB-5j
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 18:04:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	90/3E-09842-ABE7F645; Fri, 21 Nov 2014 18:04:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416593080!14489732!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28860 invoked from network); 21 Nov 2014 18:04:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 18:04:41 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALI2eQZ018486
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 18:02:41 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALI2cxm000497
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 18:02:39 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALI2Zid018287; Fri, 21 Nov 2014 18:02:36 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 10:02:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D604C118ACF; Fri, 21 Nov 2014 13:02:31 -0500 (EST)
Date: Fri, 21 Nov 2014 13:02:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Don Slutz <dslutz@verizon.com>
Message-ID: <20141121180231.GA15476@laptop.dumpdata.com>
References: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
	<546F7C40.8090906@terremark.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F7C40.8090906@terremark.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: artem.mygaiev@globallogic.com, Steve.VanderLeest@dornerworks.com,
	mengxu@cis.upenn.edu, m.a.young@durham.ac.uk,
	chao.p.peng@linux.intel.com, zhigang.x.wang@oracle.com,
	parth.dixit@linaro.org, boris.ostrovsky@oracle.com,
	manishjaggi.oss@gmail.com, Paul.Skentzos@dornerworks.com,
	vijay.kilari@gmail.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, daniel.kiper@oracle.com,
	josh.whitehead@dornerworks.com, avanzini.arianna@gmail.com,
	yang.z.zhang@intel.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, feng.wu@intel.com,
	yjhyun.yoo@samsung.com, suriyan.r@gmail.com,
	ian.campbell@citrix.com, wency@cn.fujitsu.com,
	stefano.stabellini@eu.citrix.com, mcgrof@suse.com,
	julien.grall@linaro.org, talex5@gmail.com,
	robert.vanvossen@dornerworks.com, roy.franz@linaro.org,
	anthony.perard@citrix.com, Paul.Durrant@citrix.com,
	olaf@aepfle.d.e, ufimtseva@gmail.com,
	andrii.tseglytskyi@globallogic.com, jgross@suse.com,
	dave.scott@citrix.com, yanghy@cn.fujitsu.com,
	Wei.Liu2@citrix.com, Vijaya.Kumar@caviumnetworks.com,
	george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	dario.faggioli@citrix.com, eddie.dong@intel.com,
	Kelly.Zytaruk@amd.com, tklengyel@sec.in.tum.de,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	david.vrabel@citrix.com, Suravee.Suthikulpanit@amd.com,
	aravindp@cisco.com, tiejun.chen@intel.com,
	malcolm.crossley@citrix.com, caobosimon@gmail.com,
	ian.jackson@eu.citrix.com, christoffer.dall@linaro.org,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] Xen 4.5-rc2 post update (RC2 was out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 12:54:08PM -0500, Don Slutz wrote:
> On 11/21/14 12:42, konrad.wilk@oracle.com wrote:
> >Feature patchsets that did not make it in by today have been put
> >on the deferred list. If you think your feature should make it by Xen 4.5-RC3
> >please make your case.
> >
> >Xen 4.5-rc2 was out on Monday (11th). There are three known issues, if I have
> >missed one (or more) please respond.
> >
> >(see 'Known Issues' below) which are to be fixed by RC3 - if:
> >  - The maintainers are fine with it,
> >  - The risk is minimal to common code paths.
> >
> >Details for the test-day are at
> >
> >http://wiki.xen.org/wiki/Xen_4.5_RC2_test_instructions
> >
> >In terms of bugs, we have:
> >
> >#11 qxl hypervisor support
> >#13 Re: [Xen-devel] man page example: xm block-attach
> >#18 xl improve support for migration over non-sshlike tunnels
> >#19 xl migrate transport improvements
> >#22 xl does not support specifying virtual function for passthrough device
> >#23 Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks
> >#24 xl missing support for encrypted VNC
> >#27 Re: [Xen-devel] xend vs xl with pci=['<bdf'] wherein the '<bdf>' are not owned by pciback or pcistub will still launch.
> >#28 support PCI hole resize in qemu-xen
> >
> >[Isn't this fixed by Don's 'mmio_hole' patches?]
> 
> I consider "mmio_hole" a work around for this.  The is more that can be done
> here.

Yeah, I had a discussion with George about this and it seems that the proper fix to this
is quite involved (perhaps make it a XEn 4.6 feature/fix?). I need somehow to update the
bug system to mention how to use 'mmio_hole' for this.

Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:05:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:05:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsZh-0000lh-Mr; Fri, 21 Nov 2014 18:04:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XrsZg-0000lW-JB
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 18:04:52 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	DB/D2-02696-3CE7F645; Fri, 21 Nov 2014 18:04:51 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416593089!14082121!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26542 invoked from network); 21 Nov 2014 18:04:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 18:04:51 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALI4k3h001045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 18:04:46 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALI4inm006825
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 18:04:44 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALI4iQd006818; Fri, 21 Nov 2014 18:04:44 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 10:04:44 -0800
Message-ID: <546F7EBA.6000207@oracle.com>
Date: Fri, 21 Nov 2014 13:04:42 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, konrad.wilk@oracle.com
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
	<20141114100939.GB30599@zion.uk.xensource.com>
	<1415960555.21321.28.camel@citrix.com>
In-Reply-To: <1415960555.21321.28.camel@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/14/2014 05:22 AM, Ian Campbell wrote:
> On Fri, 2014-11-14 at 10:09 +0000, Wei Liu wrote:
>> On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
>>> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
>>>> Unconditionally print out the partial configuration.
>>>
>>> Can you provide an example of what such a configuration looks like?
>>>
>>
>>     {
>>         "domid": 2,
>>         "config": {
>>             "c_info": {
>>                 "name": "s0-raw-vnuma",
>>                 "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
>>             },
>>             "b_info": {
>>                 "sched_params": {
>>
>>                 },
>>                 "type.invalid": {
>>
>>                 }
>>             }
>>         }
>>     }
> 
> Great, thanks. I propose to insert this into the commit message as I
> check it in (once I check who's acked it etc)
> 
>> Libxl still complains because it tries to read some nodes that don't
>> exist, so xl will just print it out on stderr. This is the same
>> behaviour as before though.
> 
> I think that's tolerable for 4.5 at least.

I also think this is OK for 4.5.

Konrad: can pickup this for next rc?

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:05:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:05:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsZZ-0000lI-Aj; Fri, 21 Nov 2014 18:04:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrsZX-0000lB-5j
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 18:04:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	90/3E-09842-ABE7F645; Fri, 21 Nov 2014 18:04:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416593080!14489732!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28860 invoked from network); 21 Nov 2014 18:04:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 18:04:41 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALI2eQZ018486
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 18:02:41 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALI2cxm000497
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 18:02:39 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALI2Zid018287; Fri, 21 Nov 2014 18:02:36 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 10:02:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D604C118ACF; Fri, 21 Nov 2014 13:02:31 -0500 (EST)
Date: Fri, 21 Nov 2014 13:02:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Don Slutz <dslutz@verizon.com>
Message-ID: <20141121180231.GA15476@laptop.dumpdata.com>
References: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
	<546F7C40.8090906@terremark.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F7C40.8090906@terremark.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: artem.mygaiev@globallogic.com, Steve.VanderLeest@dornerworks.com,
	mengxu@cis.upenn.edu, m.a.young@durham.ac.uk,
	chao.p.peng@linux.intel.com, zhigang.x.wang@oracle.com,
	parth.dixit@linaro.org, boris.ostrovsky@oracle.com,
	manishjaggi.oss@gmail.com, Paul.Skentzos@dornerworks.com,
	vijay.kilari@gmail.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, daniel.kiper@oracle.com,
	josh.whitehead@dornerworks.com, avanzini.arianna@gmail.com,
	yang.z.zhang@intel.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, feng.wu@intel.com,
	yjhyun.yoo@samsung.com, suriyan.r@gmail.com,
	ian.campbell@citrix.com, wency@cn.fujitsu.com,
	stefano.stabellini@eu.citrix.com, mcgrof@suse.com,
	julien.grall@linaro.org, talex5@gmail.com,
	robert.vanvossen@dornerworks.com, roy.franz@linaro.org,
	anthony.perard@citrix.com, Paul.Durrant@citrix.com,
	olaf@aepfle.d.e, ufimtseva@gmail.com,
	andrii.tseglytskyi@globallogic.com, jgross@suse.com,
	dave.scott@citrix.com, yanghy@cn.fujitsu.com,
	Wei.Liu2@citrix.com, Vijaya.Kumar@caviumnetworks.com,
	george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	dario.faggioli@citrix.com, eddie.dong@intel.com,
	Kelly.Zytaruk@amd.com, tklengyel@sec.in.tum.de,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	david.vrabel@citrix.com, Suravee.Suthikulpanit@amd.com,
	aravindp@cisco.com, tiejun.chen@intel.com,
	malcolm.crossley@citrix.com, caobosimon@gmail.com,
	ian.jackson@eu.citrix.com, christoffer.dall@linaro.org,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] Xen 4.5-rc2 post update (RC2 was out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 12:54:08PM -0500, Don Slutz wrote:
> On 11/21/14 12:42, konrad.wilk@oracle.com wrote:
> >Feature patchsets that did not make it in by today have been put
> >on the deferred list. If you think your feature should make it by Xen 4.5-RC3
> >please make your case.
> >
> >Xen 4.5-rc2 was out on Monday (11th). There are three known issues, if I have
> >missed one (or more) please respond.
> >
> >(see 'Known Issues' below) which are to be fixed by RC3 - if:
> >  - The maintainers are fine with it,
> >  - The risk is minimal to common code paths.
> >
> >Details for the test-day are at
> >
> >http://wiki.xen.org/wiki/Xen_4.5_RC2_test_instructions
> >
> >In terms of bugs, we have:
> >
> >#11 qxl hypervisor support
> >#13 Re: [Xen-devel] man page example: xm block-attach
> >#18 xl improve support for migration over non-sshlike tunnels
> >#19 xl migrate transport improvements
> >#22 xl does not support specifying virtual function for passthrough device
> >#23 Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks
> >#24 xl missing support for encrypted VNC
> >#27 Re: [Xen-devel] xend vs xl with pci=['<bdf'] wherein the '<bdf>' are not owned by pciback or pcistub will still launch.
> >#28 support PCI hole resize in qemu-xen
> >
> >[Isn't this fixed by Don's 'mmio_hole' patches?]
> 
> I consider "mmio_hole" a work around for this.  The is more that can be done
> here.

Yeah, I had a discussion with George about this and it seems that the proper fix to this
is quite involved (perhaps make it a XEn 4.6 feature/fix?). I need somehow to update the
bug system to mention how to use 'mmio_hole' for this.

Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:09:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrse1-0000zq-Cw; Fri, 21 Nov 2014 18:09:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrse0-0000zj-6e
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 18:09:20 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	7D/14-02698-FCF7F645; Fri, 21 Nov 2014 18:09:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416593357!14042908!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2394 invoked from network); 21 Nov 2014 18:09:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 18:09:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALI9A92026632
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 18:09:10 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALI99P2002577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 18:09:10 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALI98qd008477; Fri, 21 Nov 2014 18:09:09 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 10:09:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 47908118ADC; Fri, 21 Nov 2014 13:09:07 -0500 (EST)
Date: Fri, 21 Nov 2014 13:09:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141121180907.GA15778@laptop.dumpdata.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
	<20141114100939.GB30599@zion.uk.xensource.com>
	<1415960555.21321.28.camel@citrix.com>
	<546F7EBA.6000207@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F7EBA.6000207@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 01:04:42PM -0500, Zhigang Wang wrote:
> On 11/14/2014 05:22 AM, Ian Campbell wrote:
> > On Fri, 2014-11-14 at 10:09 +0000, Wei Liu wrote:
> >> On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
> >>> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> >>>> Unconditionally print out the partial configuration.
> >>>
> >>> Can you provide an example of what such a configuration looks like?
> >>>
> >>
> >>     {
> >>         "domid": 2,
> >>         "config": {
> >>             "c_info": {
> >>                 "name": "s0-raw-vnuma",
> >>                 "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
> >>             },
> >>             "b_info": {
> >>                 "sched_params": {
> >>
> >>                 },
> >>                 "type.invalid": {
> >>
> >>                 }
> >>             }
> >>         }
> >>     }
> > 
> > Great, thanks. I propose to insert this into the commit message as I
> > check it in (once I check who's acked it etc)
> > 
> >> Libxl still complains because it tries to read some nodes that don't
> >> exist, so xl will just print it out on stderr. This is the same
> >> behaviour as before though.
> > 
> > I think that's tolerable for 4.5 at least.
> 
> I also think this is OK for 4.5.
> 
> Konrad: can pickup this for next rc?

Please see http://lists.xen.org/archives/html/xen-devel/2014-11/msg01238.html
> 
> Thanks,
> 
> Zhigang
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:09:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrse1-0000zq-Cw; Fri, 21 Nov 2014 18:09:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrse0-0000zj-6e
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 18:09:20 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	7D/14-02698-FCF7F645; Fri, 21 Nov 2014 18:09:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416593357!14042908!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2394 invoked from network); 21 Nov 2014 18:09:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 18:09:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALI9A92026632
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 18:09:10 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALI99P2002577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 18:09:10 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALI98qd008477; Fri, 21 Nov 2014 18:09:09 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 10:09:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 47908118ADC; Fri, 21 Nov 2014 13:09:07 -0500 (EST)
Date: Fri, 21 Nov 2014 13:09:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20141121180907.GA15778@laptop.dumpdata.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
	<20141114100939.GB30599@zion.uk.xensource.com>
	<1415960555.21321.28.camel@citrix.com>
	<546F7EBA.6000207@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F7EBA.6000207@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 01:04:42PM -0500, Zhigang Wang wrote:
> On 11/14/2014 05:22 AM, Ian Campbell wrote:
> > On Fri, 2014-11-14 at 10:09 +0000, Wei Liu wrote:
> >> On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
> >>> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> >>>> Unconditionally print out the partial configuration.
> >>>
> >>> Can you provide an example of what such a configuration looks like?
> >>>
> >>
> >>     {
> >>         "domid": 2,
> >>         "config": {
> >>             "c_info": {
> >>                 "name": "s0-raw-vnuma",
> >>                 "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
> >>             },
> >>             "b_info": {
> >>                 "sched_params": {
> >>
> >>                 },
> >>                 "type.invalid": {
> >>
> >>                 }
> >>             }
> >>         }
> >>     }
> > 
> > Great, thanks. I propose to insert this into the commit message as I
> > check it in (once I check who's acked it etc)
> > 
> >> Libxl still complains because it tries to read some nodes that don't
> >> exist, so xl will just print it out on stderr. This is the same
> >> behaviour as before though.
> > 
> > I think that's tolerable for 4.5 at least.
> 
> I also think this is OK for 4.5.
> 
> Konrad: can pickup this for next rc?

Please see http://lists.xen.org/archives/html/xen-devel/2014-11/msg01238.html
> 
> Thanks,
> 
> Zhigang
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:14:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrsii-0001KC-A2; Fri, 21 Nov 2014 18:14:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrsig-0001K7-RP
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 18:14:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8A/75-09842-2F08F645; Fri, 21 Nov 2014 18:14:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416593646!6459819!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31580 invoked from network); 21 Nov 2014 18:14:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 18:14:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195340486"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 13:14:03 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrsiZ-00084g-Ey;
	Fri, 21 Nov 2014 18:14:03 +0000
Date: Fri, 21 Nov 2014 18:14:03 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141121181403.GB17978@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
	<20141114100939.GB30599@zion.uk.xensource.com>
	<1415960555.21321.28.camel@citrix.com>
	<546F7EBA.6000207@oracle.com>
	<20141121180907.GA15778@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141121180907.GA15778@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Zhigang Wang <zhigang.x.wang@oracle.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 01:09:07PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 01:04:42PM -0500, Zhigang Wang wrote:
> > On 11/14/2014 05:22 AM, Ian Campbell wrote:
> > > On Fri, 2014-11-14 at 10:09 +0000, Wei Liu wrote:
> > >> On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
> > >>> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > >>>> Unconditionally print out the partial configuration.
> > >>>
> > >>> Can you provide an example of what such a configuration looks like?
> > >>>
> > >>
> > >>     {
> > >>         "domid": 2,
> > >>         "config": {
> > >>             "c_info": {
> > >>                 "name": "s0-raw-vnuma",
> > >>                 "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
> > >>             },
> > >>             "b_info": {
> > >>                 "sched_params": {
> > >>
> > >>                 },
> > >>                 "type.invalid": {
> > >>
> > >>                 }
> > >>             }
> > >>         }
> > >>     }
> > > 
> > > Great, thanks. I propose to insert this into the commit message as I
> > > check it in (once I check who's acked it etc)
> > > 
> > >> Libxl still complains because it tries to read some nodes that don't
> > >> exist, so xl will just print it out on stderr. This is the same
> > >> behaviour as before though.
> > > 
> > > I think that's tolerable for 4.5 at least.
> > 
> > I also think this is OK for 4.5.
> > 
> > Konrad: can pickup this for next rc?
> 
> Please see http://lists.xen.org/archives/html/xen-devel/2014-11/msg01238.html

Unfortunately I myself want to retract this series because I don't want
to give special consideration for ERROR_JSON_CONFIG_EMPTY.

I think all you need is to have such skeleton, right? I can do it in
xl...

Wei.

> > 
> > Thanks,
> > 
> > Zhigang
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:14:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrsii-0001KC-A2; Fri, 21 Nov 2014 18:14:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrsig-0001K7-RP
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 18:14:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8A/75-09842-2F08F645; Fri, 21 Nov 2014 18:14:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416593646!6459819!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31580 invoked from network); 21 Nov 2014 18:14:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 18:14:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195340486"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 13:14:03 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XrsiZ-00084g-Ey;
	Fri, 21 Nov 2014 18:14:03 +0000
Date: Fri, 21 Nov 2014 18:14:03 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141121181403.GB17978@zion.uk.xensource.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
	<20141114100939.GB30599@zion.uk.xensource.com>
	<1415960555.21321.28.camel@citrix.com>
	<546F7EBA.6000207@oracle.com>
	<20141121180907.GA15778@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141121180907.GA15778@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Zhigang Wang <zhigang.x.wang@oracle.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 01:09:07PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 01:04:42PM -0500, Zhigang Wang wrote:
> > On 11/14/2014 05:22 AM, Ian Campbell wrote:
> > > On Fri, 2014-11-14 at 10:09 +0000, Wei Liu wrote:
> > >> On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
> > >>> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
> > >>>> Unconditionally print out the partial configuration.
> > >>>
> > >>> Can you provide an example of what such a configuration looks like?
> > >>>
> > >>
> > >>     {
> > >>         "domid": 2,
> > >>         "config": {
> > >>             "c_info": {
> > >>                 "name": "s0-raw-vnuma",
> > >>                 "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
> > >>             },
> > >>             "b_info": {
> > >>                 "sched_params": {
> > >>
> > >>                 },
> > >>                 "type.invalid": {
> > >>
> > >>                 }
> > >>             }
> > >>         }
> > >>     }
> > > 
> > > Great, thanks. I propose to insert this into the commit message as I
> > > check it in (once I check who's acked it etc)
> > > 
> > >> Libxl still complains because it tries to read some nodes that don't
> > >> exist, so xl will just print it out on stderr. This is the same
> > >> behaviour as before though.
> > > 
> > > I think that's tolerable for 4.5 at least.
> > 
> > I also think this is OK for 4.5.
> > 
> > Konrad: can pickup this for next rc?
> 
> Please see http://lists.xen.org/archives/html/xen-devel/2014-11/msg01238.html

Unfortunately I myself want to retract this series because I don't want
to give special consideration for ERROR_JSON_CONFIG_EMPTY.

I think all you need is to have such skeleton, right? I can do it in
xl...

Wei.

> > 
> > Thanks,
> > 
> > Zhigang
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:25:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrstQ-0001cZ-HG; Fri, 21 Nov 2014 18:25:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XrstP-0001cU-Ju
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 18:25:15 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	05/AE-31453-A838F645; Fri, 21 Nov 2014 18:25:14 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416594312!12729957!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3741 invoked from network); 21 Nov 2014 18:25:14 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 18:25:14 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALIP4Tu013445
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 18:25:05 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALIP2Ra002162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 18:25:03 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALIP2AS018098; Fri, 21 Nov 2014 18:25:02 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 10:25:02 -0800
Message-ID: <546F837D.1040102@oracle.com>
Date: Fri, 21 Nov 2014 13:25:01 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
	<20141114100939.GB30599@zion.uk.xensource.com>
	<1415960555.21321.28.camel@citrix.com>
	<546F7EBA.6000207@oracle.com>
	<20141121180907.GA15778@laptop.dumpdata.com>
	<20141121181403.GB17978@zion.uk.xensource.com>
In-Reply-To: <20141121181403.GB17978@zion.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, ian.jackson@eu.citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 01:14 PM, Wei Liu wrote:
> On Fri, Nov 21, 2014 at 01:09:07PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Nov 21, 2014 at 01:04:42PM -0500, Zhigang Wang wrote:
>>> On 11/14/2014 05:22 AM, Ian Campbell wrote:
>>>> On Fri, 2014-11-14 at 10:09 +0000, Wei Liu wrote:
>>>>> On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
>>>>>> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
>>>>>>> Unconditionally print out the partial configuration.
>>>>>>
>>>>>> Can you provide an example of what such a configuration looks like?
>>>>>>
>>>>>
>>>>>     {
>>>>>         "domid": 2,
>>>>>         "config": {
>>>>>             "c_info": {
>>>>>                 "name": "s0-raw-vnuma",
>>>>>                 "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
>>>>>             },
>>>>>             "b_info": {
>>>>>                 "sched_params": {
>>>>>
>>>>>                 },
>>>>>                 "type.invalid": {
>>>>>
>>>>>                 }
>>>>>             }
>>>>>         }
>>>>>     }
>>>>
>>>> Great, thanks. I propose to insert this into the commit message as I
>>>> check it in (once I check who's acked it etc)
>>>>
>>>>> Libxl still complains because it tries to read some nodes that don't
>>>>> exist, so xl will just print it out on stderr. This is the same
>>>>> behaviour as before though.
>>>>
>>>> I think that's tolerable for 4.5 at least.
>>>
>>> I also think this is OK for 4.5.
>>>
>>> Konrad: can pickup this for next rc?
>>
>> Please see http://lists.xen.org/archives/html/xen-devel/2014-11/msg01238.html
> 
> Unfortunately I myself want to retract this series because I don't want
> to give special consideration for ERROR_JSON_CONFIG_EMPTY.
> 
> I think all you need is to have such skeleton, right? I can do it in
> xl...

Yes. I need a skeleton in `xl list -l` to indicate the domain is running.

If we can have the info as in `xl list`, that will be great:

   domid, name, uuid, avail_vcpus, target_memkb

   # xl list
    Name                                          ID   Mem VCPUs      State   Time(s)
    Domain-0                                       0   856     4     r-----    2758.9
    0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:25:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrstQ-0001cZ-HG; Fri, 21 Nov 2014 18:25:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1XrstP-0001cU-Ju
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 18:25:15 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	05/AE-31453-A838F645; Fri, 21 Nov 2014 18:25:14 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416594312!12729957!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3741 invoked from network); 21 Nov 2014 18:25:14 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 18:25:14 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALIP4Tu013445
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 18:25:05 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALIP2Ra002162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 18:25:03 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALIP2AS018098; Fri, 21 Nov 2014 18:25:02 GMT
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 10:25:02 -0800
Message-ID: <546F837D.1040102@oracle.com>
Date: Fri, 21 Nov 2014 13:25:01 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1415811865-19981-1-git-send-email-wei.liu2@citrix.com>
	<1415811865-19981-3-git-send-email-wei.liu2@citrix.com>
	<1415959140.21321.21.camel@citrix.com>
	<20141114100939.GB30599@zion.uk.xensource.com>
	<1415960555.21321.28.camel@citrix.com>
	<546F7EBA.6000207@oracle.com>
	<20141121180907.GA15778@laptop.dumpdata.com>
	<20141121181403.GB17978@zion.uk.xensource.com>
In-Reply-To: <20141121181403.GB17978@zion.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, ian.jackson@eu.citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 2/2] xl: print out partial
 configuration in long mode of list command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 01:14 PM, Wei Liu wrote:
> On Fri, Nov 21, 2014 at 01:09:07PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Nov 21, 2014 at 01:04:42PM -0500, Zhigang Wang wrote:
>>> On 11/14/2014 05:22 AM, Ian Campbell wrote:
>>>> On Fri, 2014-11-14 at 10:09 +0000, Wei Liu wrote:
>>>>> On Fri, Nov 14, 2014 at 09:59:00AM +0000, Ian Campbell wrote:
>>>>>> On Wed, 2014-11-12 at 17:04 +0000, Wei Liu wrote:
>>>>>>> Unconditionally print out the partial configuration.
>>>>>>
>>>>>> Can you provide an example of what such a configuration looks like?
>>>>>>
>>>>>
>>>>>     {
>>>>>         "domid": 2,
>>>>>         "config": {
>>>>>             "c_info": {
>>>>>                 "name": "s0-raw-vnuma",
>>>>>                 "uuid": "a8bed4ac-a0fe-4166-8eac-feeb007a2110"
>>>>>             },
>>>>>             "b_info": {
>>>>>                 "sched_params": {
>>>>>
>>>>>                 },
>>>>>                 "type.invalid": {
>>>>>
>>>>>                 }
>>>>>             }
>>>>>         }
>>>>>     }
>>>>
>>>> Great, thanks. I propose to insert this into the commit message as I
>>>> check it in (once I check who's acked it etc)
>>>>
>>>>> Libxl still complains because it tries to read some nodes that don't
>>>>> exist, so xl will just print it out on stderr. This is the same
>>>>> behaviour as before though.
>>>>
>>>> I think that's tolerable for 4.5 at least.
>>>
>>> I also think this is OK for 4.5.
>>>
>>> Konrad: can pickup this for next rc?
>>
>> Please see http://lists.xen.org/archives/html/xen-devel/2014-11/msg01238.html
> 
> Unfortunately I myself want to retract this series because I don't want
> to give special consideration for ERROR_JSON_CONFIG_EMPTY.
> 
> I think all you need is to have such skeleton, right? I can do it in
> xl...

Yes. I need a skeleton in `xl list -l` to indicate the domain is running.

If we can have the info as in `xl list`, that will be great:

   domid, name, uuid, avail_vcpus, target_memkb

   # xl list
    Name                                          ID   Mem VCPUs      State   Time(s)
    Domain-0                                       0   856     4     r-----    2758.9
    0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:26:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:26:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsuP-0001gX-V9; Fri, 21 Nov 2014 18:26:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrsuO-0001gL-8r
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 18:26:16 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	37/0D-02698-7C38F645; Fri, 21 Nov 2014 18:26:15 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416594373!9440249!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2172 invoked from network); 21 Nov 2014 18:26:14 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 18:26:14 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALIQ7eV014665
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 18:26:08 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALIQ5Pn005657
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 18:26:06 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALIQ57g021399; Fri, 21 Nov 2014 18:26:05 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 10:26:05 -0800
Message-ID: <546F8464.5000906@oracle.com>
Date: Fri, 21 Nov 2014 13:28:52 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: konrad.wilk@oracle.com, xen-devel <xen-devel@lists.xenproject.org>,
	ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
References: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
In-Reply-To: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: Re: [Xen-devel] Xen 4.5-rc2 post update (RC2 was out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(Followup list trimmed)

On 11/21/2014 12:42 PM, konrad.wilk@oracle.com wrote:
>
> = Open =
>
> == Known issues ==
>
> *  xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/RAM (good)
>     RFC v6
>     Treating pieces as bug-fixes only.
>    -  Tiejun Chen
>
> *  PCI passthrough of INTx legacy devices can trigger list corruption (good)
>     Sander reported it. Two different types of patches available.
>    -  Konrad Rzeszutek Wilk
>
> *  pygrub does not handle certain configurations. (fair)
>     an RFC patch posted.
>    -  Andrew Cooper

There is a regression in libxl's bitmap handling during a restore. I 
need libxl maintainers to decide which of the two suggested ways to fix 
it I should use. Both are fairly trivial.

There is also a bug in libxl's PCI detach code. In fact, two bugs, both 
related to a race between libxl, qemu and guest. IanJ suggested a simple 
patch for one (which, in fact, fixes a regression) but the second bug 
will probably take me a while (need to make detaching call chain 
asynchronous).

> == Linux ==
>
>
> *  vAPIC in PVHVM guests (Linux side) (none)
>    -  Boris Ostrovsky

This, I believe, is queued for 3.19.

boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:26:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:26:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrsuP-0001gX-V9; Fri, 21 Nov 2014 18:26:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XrsuO-0001gL-8r
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 18:26:16 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	37/0D-02698-7C38F645; Fri, 21 Nov 2014 18:26:15 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416594373!9440249!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2172 invoked from network); 21 Nov 2014 18:26:14 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 18:26:14 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALIQ7eV014665
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 18:26:08 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALIQ5Pn005657
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 18:26:06 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALIQ57g021399; Fri, 21 Nov 2014 18:26:05 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 10:26:05 -0800
Message-ID: <546F8464.5000906@oracle.com>
Date: Fri, 21 Nov 2014 13:28:52 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: konrad.wilk@oracle.com, xen-devel <xen-devel@lists.xenproject.org>,
	ian.jackson@eu.citrix.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
References: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
In-Reply-To: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: Re: [Xen-devel] Xen 4.5-rc2 post update (RC2 was out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(Followup list trimmed)

On 11/21/2014 12:42 PM, konrad.wilk@oracle.com wrote:
>
> = Open =
>
> == Known issues ==
>
> *  xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/RAM (good)
>     RFC v6
>     Treating pieces as bug-fixes only.
>    -  Tiejun Chen
>
> *  PCI passthrough of INTx legacy devices can trigger list corruption (good)
>     Sander reported it. Two different types of patches available.
>    -  Konrad Rzeszutek Wilk
>
> *  pygrub does not handle certain configurations. (fair)
>     an RFC patch posted.
>    -  Andrew Cooper

There is a regression in libxl's bitmap handling during a restore. I 
need libxl maintainers to decide which of the two suggested ways to fix 
it I should use. Both are fairly trivial.

There is also a bug in libxl's PCI detach code. In fact, two bugs, both 
related to a race between libxl, qemu and guest. IanJ suggested a simple 
patch for one (which, in fact, fixes a regression) but the second bug 
will probably take me a while (need to make detaching call chain 
asynchronous).

> == Linux ==
>
>
> *  vAPIC in PVHVM guests (Linux side) (none)
>    -  Boris Ostrovsky

This, I believe, is queued for 3.19.

boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:49:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrtGQ-0002GR-NA; Fri, 21 Nov 2014 18:49:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrtGO-0002GM-QX
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 18:49:00 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	43/B4-14214-C198F645; Fri, 21 Nov 2014 18:49:00 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416595736!12727260!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22257 invoked from network); 21 Nov 2014 18:48:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 18:48:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193815061"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 13:48:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrtGH-0008Uc-AN;
	Fri, 21 Nov 2014 18:48:53 +0000
Date: Fri, 21 Nov 2014 18:48:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141121173437.GA14331@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
References: <1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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 Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > The rom is used for pxebooting. We don't need to allow pxebooting from
> > more than one network card.  Loading a romfile for every NIC wastes
> 
> Why not? Why can't we PXE boot from each network card?

I take it back: you are right, at the moment it is actually possible to
pxe boot from the fourth nic for example. Maybe we could just load the
first four romfiles and skip the others (four is the limit before QEMU
fails to allocate any more memory).

TBH not all the emulated nics need a romfile but I wouldn't want to go
down at that level of details beause they become QEMU implementation
details. I wouldn't want to tie libxl to a certain version of QEMU in
any way.

A better way would be handling memory allocation errors in QEMU but QEMU
doesn't do that at the moment and the change there would be certainly
more invasive that a couple of lines in libxl.


> > memory and as a matter of fact breaks configurations with more than 4
> > NICs as QEMU fails to allocate memory on behalf of the guest.
> 
> What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> and ne2k ?
> 
> Don't you want to load the ROM for each one?

The rom cannot be reused in QEMU among multiple instances of the same
nic, so having four different types of nics or just one type doesn't
change anything.


> > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > guest.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index 3e191c3..f907ca9 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> >                  flexarray_append(dm_args, "-device");
> >                  flexarray_append(dm_args,
> > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> >                                                  nics[i].model, nics[i].devid,
> > -                                                nics[i].devid, smac));
> > +                                                nics[i].devid, smac,
> > +                                                i ? ",romfile=\"\"" : ""));
> >                  flexarray_append(dm_args, "-netdev");
> >                  flexarray_append(dm_args, GCSPRINTF(
> >                                            "type=tap,id=net%d,ifname=%s,"
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 18:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 18:49:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrtGQ-0002GR-NA; Fri, 21 Nov 2014 18:49:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XrtGO-0002GM-QX
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 18:49:00 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	43/B4-14214-C198F645; Fri, 21 Nov 2014 18:49:00 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416595736!12727260!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22257 invoked from network); 21 Nov 2014 18:48:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 18:48:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193815061"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 13:48:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XrtGH-0008Uc-AN;
	Fri, 21 Nov 2014 18:48:53 +0000
Date: Fri, 21 Nov 2014 18:48:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141121173437.GA14331@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
References: <1415967767.7113.19.camel@citrix.com>
	<a0cc29.27c3f.149b13c965c.Coremail.hanyandong@iie.ac.cn>
	<1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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 Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > The rom is used for pxebooting. We don't need to allow pxebooting from
> > more than one network card.  Loading a romfile for every NIC wastes
> 
> Why not? Why can't we PXE boot from each network card?

I take it back: you are right, at the moment it is actually possible to
pxe boot from the fourth nic for example. Maybe we could just load the
first four romfiles and skip the others (four is the limit before QEMU
fails to allocate any more memory).

TBH not all the emulated nics need a romfile but I wouldn't want to go
down at that level of details beause they become QEMU implementation
details. I wouldn't want to tie libxl to a certain version of QEMU in
any way.

A better way would be handling memory allocation errors in QEMU but QEMU
doesn't do that at the moment and the change there would be certainly
more invasive that a couple of lines in libxl.


> > memory and as a matter of fact breaks configurations with more than 4
> > NICs as QEMU fails to allocate memory on behalf of the guest.
> 
> What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> and ne2k ?
> 
> Don't you want to load the ROM for each one?

The rom cannot be reused in QEMU among multiple instances of the same
nic, so having four different types of nics or just one type doesn't
change anything.


> > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > guest.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index 3e191c3..f907ca9 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> >                  flexarray_append(dm_args, "-device");
> >                  flexarray_append(dm_args,
> > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> >                                                  nics[i].model, nics[i].devid,
> > -                                                nics[i].devid, smac));
> > +                                                nics[i].devid, smac,
> > +                                                i ? ",romfile=\"\"" : ""));
> >                  flexarray_append(dm_args, "-netdev");
> >                  flexarray_append(dm_args, GCSPRINTF(
> >                                            "type=tap,id=net%d,ifname=%s,"
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 19:06:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 19: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 1XrtWn-0002lK-F4; Fri, 21 Nov 2014 19:05:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XrtWm-0002lF-6d
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 19:05:56 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	58/0C-26740-31D8F645; Fri, 21 Nov 2014 19:05:55 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416596754!13021887!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2650 invoked from network); 21 Nov 2014 19:05:54 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 19:05:54 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sALJ5cOE003726;
	Fri, 21 Nov 2014 19:05:42 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost3.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sALJ5S8i003168
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 19:05:28 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sALJ5SXb011734;
	Fri, 21 Nov 2014 19:05:28 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sALJ5RQp011730; Fri, 21 Nov 2014 19:05:28 GMT
Date: Fri, 21 Nov 2014 19:05:27 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416579506.17932.10.camel@citrix.com>
Message-ID: <alpine.DEB.2.00.1411211900240.12582@procyon.dur.ac.uk>
References: <1416579506.17932.10.camel@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sALJ5cOE003726
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: [Xen-devel] running pygrub on split-partition disk layouts.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Nov 2014, Ian Campbell wrote:

> An absolute age ago Michael posted a patch to allow pygrub to work with
> split-partition layouts (i.e. those where the guests disk cfg refers to
> xvda1, xvda2, etc rather than an xvda with a partition table). See
> http://lists.xen.org/archives/html/xen-devel/2011-01/msg02076.html
> (patch itself is below).
>
> Apparently at the time I was of the opinion that this was a reasonable
> workaround for the underlying issue (although I seem to have thought I
> had a better solution, not so sure right now...).
>
> I'm not sure why it didn't go in (in the likely event I just dropped the
> ball -- sorry!).
>
> Anyway, this resurfaced recently in the context of Debian bug #745419:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745419#27
>
> #745419 seems to be unrelated to Michael's issue, it is a full disk
> image case with an MBR etc.
>
> Michael, are you still carrying this patch to the Fedora packages? If so
> presumably it is without issue in the field so to speak?

Yes, it is still in Fedora (with a minor change to get it to apply as a 
line was added in the surrounding code). I haven't seen any bug reports 
relating to this patch.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 19:06:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 19: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 1XrtWn-0002lK-F4; Fri, 21 Nov 2014 19:05:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XrtWm-0002lF-6d
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 19:05:56 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	58/0C-26740-31D8F645; Fri, 21 Nov 2014 19:05:55 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416596754!13021887!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2650 invoked from network); 21 Nov 2014 19:05:54 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 19:05:54 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sALJ5cOE003726;
	Fri, 21 Nov 2014 19:05:42 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost3.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sALJ5S8i003168
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 19:05:28 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sALJ5SXb011734;
	Fri, 21 Nov 2014 19:05:28 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sALJ5RQp011730; Fri, 21 Nov 2014 19:05:28 GMT
Date: Fri, 21 Nov 2014 19:05:27 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416579506.17932.10.camel@citrix.com>
Message-ID: <alpine.DEB.2.00.1411211900240.12582@procyon.dur.ac.uk>
References: <1416579506.17932.10.camel@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sALJ5cOE003726
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: [Xen-devel] running pygrub on split-partition disk layouts.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Nov 2014, Ian Campbell wrote:

> An absolute age ago Michael posted a patch to allow pygrub to work with
> split-partition layouts (i.e. those where the guests disk cfg refers to
> xvda1, xvda2, etc rather than an xvda with a partition table). See
> http://lists.xen.org/archives/html/xen-devel/2011-01/msg02076.html
> (patch itself is below).
>
> Apparently at the time I was of the opinion that this was a reasonable
> workaround for the underlying issue (although I seem to have thought I
> had a better solution, not so sure right now...).
>
> I'm not sure why it didn't go in (in the likely event I just dropped the
> ball -- sorry!).
>
> Anyway, this resurfaced recently in the context of Debian bug #745419:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745419#27
>
> #745419 seems to be unrelated to Michael's issue, it is a full disk
> image case with an MBR etc.
>
> Michael, are you still carrying this patch to the Fedora packages? If so
> presumably it is without issue in the field so to speak?

Yes, it is still in Fedora (with a minor change to get it to apply as a 
line was added in the surrounding code). I haven't seen any bug reports 
relating to this patch.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 19:08:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 19:08:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrtZ7-0002r6-W7; Fri, 21 Nov 2014 19:08:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrtZ5-0002qy-Sa
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 19:08:20 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	65/4C-22819-3AD8F645; Fri, 21 Nov 2014 19:08:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416596897!12725849!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20286 invoked from network); 21 Nov 2014 19:08:18 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 19:08:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALJ81TX012048
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 19:08:01 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALJ7xWS022216
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 19:08:00 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALJ7xOT020974; Fri, 21 Nov 2014 19:07:59 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 11:07:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A9B51118B23; Fri, 21 Nov 2014 14:07:57 -0500 (EST)
Date: Fri, 21 Nov 2014 14:07:57 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141121190757.GA16038@laptop.dumpdata.com>
References: <1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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 Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > > The rom is used for pxebooting. We don't need to allow pxebooting from
> > > more than one network card.  Loading a romfile for every NIC wastes
> > 
> > Why not? Why can't we PXE boot from each network card?
> 
> I take it back: you are right, at the moment it is actually possible to
> pxe boot from the fourth nic for example. Maybe we could just load the
> first four romfiles and skip the others (four is the limit before QEMU
> fails to allocate any more memory).

The limit is in the count of ROMs or the memory consumption? What if you
also do PCI passthrough? Does that figure in this calculation?
> 
> TBH not all the emulated nics need a romfile but I wouldn't want to go
> down at that level of details beause they become QEMU implementation
> details. I wouldn't want to tie libxl to a certain version of QEMU in
> any way.
> 
> A better way would be handling memory allocation errors in QEMU but QEMU
> doesn't do that at the moment and the change there would be certainly
> more invasive that a couple of lines in libxl.
> 
> 
> > > memory and as a matter of fact breaks configurations with more than 4
> > > NICs as QEMU fails to allocate memory on behalf of the guest.
> > 
> > What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> > and ne2k ?
> > 
> > Don't you want to load the ROM for each one?
> 
> The rom cannot be reused in QEMU among multiple instances of the same
> nic, so having four different types of nics or just one type doesn't
> change anything.
> 
> 
> > > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > > guest.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > index 3e191c3..f907ca9 100644
> > > --- a/tools/libxl/libxl_dm.c
> > > +++ b/tools/libxl/libxl_dm.c
> > > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> > >                  flexarray_append(dm_args, "-device");
> > >                  flexarray_append(dm_args,
> > > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> > >                                                  nics[i].model, nics[i].devid,
> > > -                                                nics[i].devid, smac));
> > > +                                                nics[i].devid, smac,
> > > +                                                i ? ",romfile=\"\"" : ""));
> > >                  flexarray_append(dm_args, "-netdev");
> > >                  flexarray_append(dm_args, GCSPRINTF(
> > >                                            "type=tap,id=net%d,ifname=%s,"
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 19:08:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 19:08:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrtZ7-0002r6-W7; Fri, 21 Nov 2014 19:08:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrtZ5-0002qy-Sa
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 19:08:20 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	65/4C-22819-3AD8F645; Fri, 21 Nov 2014 19:08:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416596897!12725849!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20286 invoked from network); 21 Nov 2014 19:08:18 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 19:08:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALJ81TX012048
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 19:08:01 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALJ7xWS022216
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 19:08:00 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALJ7xOT020974; Fri, 21 Nov 2014 19:07:59 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 11:07:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A9B51118B23; Fri, 21 Nov 2014 14:07:57 -0500 (EST)
Date: Fri, 21 Nov 2014 14:07:57 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141121190757.GA16038@laptop.dumpdata.com>
References: <1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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 Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > > The rom is used for pxebooting. We don't need to allow pxebooting from
> > > more than one network card.  Loading a romfile for every NIC wastes
> > 
> > Why not? Why can't we PXE boot from each network card?
> 
> I take it back: you are right, at the moment it is actually possible to
> pxe boot from the fourth nic for example. Maybe we could just load the
> first four romfiles and skip the others (four is the limit before QEMU
> fails to allocate any more memory).

The limit is in the count of ROMs or the memory consumption? What if you
also do PCI passthrough? Does that figure in this calculation?
> 
> TBH not all the emulated nics need a romfile but I wouldn't want to go
> down at that level of details beause they become QEMU implementation
> details. I wouldn't want to tie libxl to a certain version of QEMU in
> any way.
> 
> A better way would be handling memory allocation errors in QEMU but QEMU
> doesn't do that at the moment and the change there would be certainly
> more invasive that a couple of lines in libxl.
> 
> 
> > > memory and as a matter of fact breaks configurations with more than 4
> > > NICs as QEMU fails to allocate memory on behalf of the guest.
> > 
> > What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> > and ne2k ?
> > 
> > Don't you want to load the ROM for each one?
> 
> The rom cannot be reused in QEMU among multiple instances of the same
> nic, so having four different types of nics or just one type doesn't
> change anything.
> 
> 
> > > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > > guest.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > index 3e191c3..f907ca9 100644
> > > --- a/tools/libxl/libxl_dm.c
> > > +++ b/tools/libxl/libxl_dm.c
> > > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> > >                  flexarray_append(dm_args, "-device");
> > >                  flexarray_append(dm_args,
> > > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> > >                                                  nics[i].model, nics[i].devid,
> > > -                                                nics[i].devid, smac));
> > > +                                                nics[i].devid, smac,
> > > +                                                i ? ",romfile=\"\"" : ""));
> > >                  flexarray_append(dm_args, "-netdev");
> > >                  flexarray_append(dm_args, GCSPRINTF(
> > >                                            "type=tap,id=net%d,ifname=%s,"
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 19:42:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 19:42:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xru6M-0003ah-97; Fri, 21 Nov 2014 19:42:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xru6K-0003ac-KC
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 19:42:40 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	F5/98-20609-0B59F645; Fri, 21 Nov 2014 19:42:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416598955!10750896!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22718 invoked from network); 21 Nov 2014 19:42:38 -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;
	21 Nov 2014 19:42:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193833788"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 14:41:55 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xru5a-0001cE-Mm;
	Fri, 21 Nov 2014 19:41:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xru5a-0000jt-CU;
	Fri, 21 Nov 2014 19:41:54 +0000
Date: Fri, 21 Nov 2014 19:41:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31680-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31680: 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 31680 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31680/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad
baseline version:
 libvirt              121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac

------------------------------------------------------------
People who touched revisions under test:
  Daniel P. Berrange <berrange@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=6c79469ccc3245b9572dcaabe8cd620ba3fabfad
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 6c79469ccc3245b9572dcaabe8cd620ba3fabfad
+ branch=libvirt
+ revision=6c79469ccc3245b9572dcaabe8cd620ba3fabfad
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 6c79469ccc3245b9572dcaabe8cd620ba3fabfad:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   121fc4f..6c79469  6c79469ccc3245b9572dcaabe8cd620ba3fabfad -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 19:42:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 19:42:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xru6M-0003ah-97; Fri, 21 Nov 2014 19:42:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xru6K-0003ac-KC
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 19:42:40 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	F5/98-20609-0B59F645; Fri, 21 Nov 2014 19:42:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416598955!10750896!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22718 invoked from network); 21 Nov 2014 19:42:38 -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;
	21 Nov 2014 19:42:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193833788"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 14:41:55 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xru5a-0001cE-Mm;
	Fri, 21 Nov 2014 19:41:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xru5a-0000jt-CU;
	Fri, 21 Nov 2014 19:41:54 +0000
Date: Fri, 21 Nov 2014 19:41:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31680-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31680: 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 31680 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31680/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad
baseline version:
 libvirt              121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac

------------------------------------------------------------
People who touched revisions under test:
  Daniel P. Berrange <berrange@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=6c79469ccc3245b9572dcaabe8cd620ba3fabfad
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 6c79469ccc3245b9572dcaabe8cd620ba3fabfad
+ branch=libvirt
+ revision=6c79469ccc3245b9572dcaabe8cd620ba3fabfad
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 6c79469ccc3245b9572dcaabe8cd620ba3fabfad:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   121fc4f..6c79469  6c79469ccc3245b9572dcaabe8cd620ba3fabfad -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 19:57:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 19:57:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XruK2-0003yA-Ln; Fri, 21 Nov 2014 19:56:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XruK1-0003y5-6j
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 19:56:49 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	1A/03-18267-0099F645; Fri, 21 Nov 2014 19:56:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416599806!9316650!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15298 invoked from network); 21 Nov 2014 19:56:47 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 19:56:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALJua5m003435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 19:56:37 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sALJua3F021805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 19:56:36 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALJuZmO008935; Fri, 21 Nov 2014 19:56:35 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 11:56:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 461FC118B4D; Fri, 21 Nov 2014 14:56:31 -0500 (EST)
Date: Fri, 21 Nov 2014 14:56:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141121195631.GA16313@laptop.dumpdata.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/19] hvmloader: disallow memory relocation
 when vNUMA is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 03:06:56PM +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  tools/firmware/hvmloader/pci.c |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index 4e8d803..d7ea740 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -88,6 +88,19 @@ void pci_setup(void)
>      printf("Relocating guest memory for lowmem MMIO space %s\n",
>             allow_memory_relocate?"enabled":"disabled");
>  
> +    /* Disallow low memory relocation when vNUMA is enabled, because
> +     * relocated memory ends up off node. Further more, even if we
> +     * dynamically expand node coverage in hvmloader, low memory and
> +     * high memory may reside in different physical nodes, blindly
> +     * relocates low memory to high memory gives us a sub-optimal
> +     * configuration.

And this is done in hvmloader, so the toolstack has no inkling that
we need to relocate memory to make space for the PCI.

In such case I would not have this check here. Instead put it in 
libxl and disallow vNUMA with PCI passthrough.

And then the fix is to take the logic that is in hvmloader for PCI
BAR size relocation and move it in libxl. Then it can construct the
proper vNUMA topology and also fix an outstanding QEMU-xen bug.

> +     */
> +    if ( hvm_info->nr_nodes != 0 && allow_memory_relocate )
> +    {
> +        allow_memory_relocate = false;
> +        printf("vNUMA enabled, relocating guest memory for lowmem MMIO space disabled\n");
> +    }
> +
>      s = xenstore_read("platform/mmio_hole_size", NULL);
>      if ( s )
>          mmio_hole_size = strtoll(s, NULL, 0);
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 19:57:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 19:57:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XruK2-0003yA-Ln; Fri, 21 Nov 2014 19:56:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XruK1-0003y5-6j
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 19:56:49 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	1A/03-18267-0099F645; Fri, 21 Nov 2014 19:56:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416599806!9316650!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15298 invoked from network); 21 Nov 2014 19:56:47 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 19:56:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALJua5m003435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 19:56:37 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sALJua3F021805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 19:56:36 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALJuZmO008935; Fri, 21 Nov 2014 19:56:35 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 11:56:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 461FC118B4D; Fri, 21 Nov 2014 14:56:31 -0500 (EST)
Date: Fri, 21 Nov 2014 14:56:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141121195631.GA16313@laptop.dumpdata.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/19] hvmloader: disallow memory relocation
 when vNUMA is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 03:06:56PM +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  tools/firmware/hvmloader/pci.c |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index 4e8d803..d7ea740 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -88,6 +88,19 @@ void pci_setup(void)
>      printf("Relocating guest memory for lowmem MMIO space %s\n",
>             allow_memory_relocate?"enabled":"disabled");
>  
> +    /* Disallow low memory relocation when vNUMA is enabled, because
> +     * relocated memory ends up off node. Further more, even if we
> +     * dynamically expand node coverage in hvmloader, low memory and
> +     * high memory may reside in different physical nodes, blindly
> +     * relocates low memory to high memory gives us a sub-optimal
> +     * configuration.

And this is done in hvmloader, so the toolstack has no inkling that
we need to relocate memory to make space for the PCI.

In such case I would not have this check here. Instead put it in 
libxl and disallow vNUMA with PCI passthrough.

And then the fix is to take the logic that is in hvmloader for PCI
BAR size relocation and move it in libxl. Then it can construct the
proper vNUMA topology and also fix an outstanding QEMU-xen bug.

> +     */
> +    if ( hvm_info->nr_nodes != 0 && allow_memory_relocate )
> +    {
> +        allow_memory_relocate = false;
> +        printf("vNUMA enabled, relocating guest memory for lowmem MMIO space disabled\n");
> +    }
> +
>      s = xenstore_read("platform/mmio_hole_size", NULL);
>      if ( s )
>          mmio_hole_size = strtoll(s, NULL, 0);
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:02:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20:02:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XruPC-0004Fn-DQ; Fri, 21 Nov 2014 20:02: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 1XruPB-0004Fi-7f
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:02:09 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	9C/8E-27584-04A9F645; Fri, 21 Nov 2014 20:02:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416600126!12724063!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13986 invoked from network); 21 Nov 2014 20:02:07 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 20:02:07 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALK210m010756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 20:02:02 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALK20CO013223
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 20:02:01 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALK1xwm009880; Fri, 21 Nov 2014 20:02:00 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 12:01:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8E6A6118B53; Fri, 21 Nov 2014 15:01:58 -0500 (EST)
Date: Fri, 21 Nov 2014 15:01:58 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141121200158.GB16313@laptop.dumpdata.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 03:06:42PM +0000, Wei Liu wrote:
> Hi all
> 
> This patch series implements virtual NUMA support for both PV and HVM guest.
> That is, admin can configure via libxl what virtual NUMA topology the guest
> sees.
> 
> This is the stage 1 (basic vNUMA support) and part of stage 2 (vNUMA-ware
> ballooning, hypervisor side) described in my previous email to xen-devel [0].
> 
> This series is broken into several parts:
> 
> 1. xen patches: vNUMA debug output and vNUMA-aware memory hypercall support.
> 2. libxc/libxl support for PV vNUMA.
> 3. libxc/libxl support for HVM vNUMA.
> 4. xl vNUMA configuration documentation and parser.
> 
> I think one significant difference from Elena's work is that this patch series
> makes use of multiple vmemranges should there be a memory hole, instead of
> shrinking ram. This matches the behaviour of real hardware.

Are some of the patches then borrowed from Elena? If so, she should be credited
in the patches?
> 
> The vNUMA auto placement algorithm is missing at the moment and Dario is
> working on it.
> 
> This series can be found at:
>  git://xenbits.xen.org/people/liuw/xen.git wip.vnuma-v1 
> 
> With this series, the following configuration can be used to enabled virtual
> NUMA support, and it works for both PV and HVM guests.
> 
> memory = 6000
> vnuma_memory = [3000, 3000]
> vnuma_vcpu_map = [0, 1]
> vnuma_pnode_map = [0, 0]
> vnuma_vdistances = [10, 30] # optional
> 
> dmesg output for HVM guest:
> 
> [    0.000000] ACPI: SRAT 00000000fc009ff0 000C8 (v01    Xen      HVM 00000000 HVML 00000000)
> [    0.000000] ACPI: SLIT 00000000fc00a0c0 00030 (v01    Xen      HVM 00000000 HVML 00000000)
> <...snip...>
> [    0.000000] SRAT: PXM 0 -> APIC 0x00 -> Node 0
> [    0.000000] SRAT: PXM 1 -> APIC 0x02 -> Node 1
> [    0.000000] SRAT: Node 0 PXM 0 [mem 0x00000000-0xbb7fffff]
> [    0.000000] SRAT: Node 1 PXM 1 [mem 0xbb800000-0xefffffff]
> [    0.000000] SRAT: Node 1 PXM 1 [mem 0x100000000-0x186ffffff]
> [    0.000000] NUMA: Initialized distance table, cnt=2
> [    0.000000] NUMA: Node 1 [mem 0xbb800000-0xefffffff] + [mem 0x100000000-0x1867fffff] -> [mem 0xbb800000-0x1867fffff]
> [    0.000000] Initmem setup node 0 [mem 0x00000000-0xbb7fffff]
> [    0.000000]   NODE_DATA [mem 0xbb7fc000-0xbb7fffff]
> [    0.000000] Initmem setup node 1 [mem 0xbb800000-0x1867fffff]
> [    0.000000]   NODE_DATA [mem 0x1867f7000-0x1867fafff]
> [    0.000000]  [ffffea0000000000-ffffea00029fffff] PMD -> [ffff8800b8600000-ffff8800baffffff] on node 0
> [    0.000000]  [ffffea0002a00000-ffffea00055fffff] PMD -> [ffff880183000000-ffff8801859fffff] on node 1
> <...snip...>
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x00001000-0x0009efff]
> [    0.000000]   node   0: [mem 0x00100000-0xbb7fffff]
> [    0.000000]   node   1: [mem 0xbb800000-0xefffefff]
> [    0.000000]   node   1: [mem 0x100000000-0x1867fffff]
> 
> numactl output for HVM guest:
> 
> available: 2 nodes (0-1)
> node 0 cpus: 0
> node 0 size: 2999 MB
> node 0 free: 2546 MB
> node 1 cpus: 1
> node 1 size: 2991 MB
> node 1 free: 2144 MB
> node distances:
> node   0   1 
>   0:  10  30 
>   1:  30  10 
> 
> dmesg output for PV guest:
> 
> [    0.000000] NUMA: Initialized distance table, cnt=2
> [    0.000000] NUMA: Node 1 [mem 0xbb800000-0xce68efff] + [mem 0x100000000-0x1a8970fff] -> [mem 0xbb800000-0x1a8970fff]
> [    0.000000] NODE_DATA(0) allocated [mem 0xbb7fc000-0xbb7fffff]
> [    0.000000] NODE_DATA(1) allocated [mem 0x1a8969000-0x1a896cfff]
> 
> numactl output for PV guest:
> 
> available: 2 nodes (0-1)
> node 0 cpus: 0
> node 0 size: 2944 MB
> node 0 free: 2917 MB
> node 1 cpus: 1
> node 1 size: 2934 MB
> node 1 free: 2904 MB
> node distances:
> node   0   1 
>   0:  10  30
>   1:  30  10
> 
> And for a HVM guest on a real NUMA-capable machine:
> 
> (XEN) Memory location of each domain:
> (XEN) Domain 0 (total: 262144):
> (XEN)     Node 0: 245758
> (XEN)     Node 1: 16386
> (XEN) Domain 2 (total: 2097226):
> (XEN)     Node 0: 1046335
> (XEN)     Node 1: 1050891
> (XEN)      2 vnodes, 4 vcpus
> (XEN)        vnode   0 - pnode 0
> (XEN)         3840 MB:  0x0 - 0xf0000000
> (XEN)         256 MB:  0x100000000 - 0x110000000
> (XEN)         vcpus: 0 1 
> (XEN)        vnode   1 - pnode 1
> (XEN)         4096 MB:  0x110000000 - 0x210000000
> (XEN)         vcpus: 2 3 
> 
> Wei.
> 
> [0] <20141111173606.GC21312@zion.uk.xensource.com>
> 
> Wei Liu (19):
>   xen: dump vNUMA information with debug key "u"
>   xen: make two memory hypercalls vNUMA-aware
>   libxc: allocate memory with vNUMA information for PV guest
>   libxl: add emacs local variables in libxl_{x86,arm}.c
>   libxl: introduce vNUMA types
>   libxl: add vmemrange to libxl__domain_build_state
>   libxl: introduce libxl__vnuma_config_check
>   libxl: x86: factor out e820_host_sanitize
>   libxl: functions to build vmemranges for PV guest
>   libxl: build, check and pass vNUMA info to Xen for PV guest
>   hvmloader: add new fields for vNUMA information
>   hvmloader: construct SRAT
>   hvmloader: construct SLIT
>   hvmloader: disallow memory relocation when vNUMA is enabled
>   libxc: allocate memory with vNUMA information for HVM guest
>   libxl: build, check and pass vNUMA info to Xen for HVM guest
>   libxl: refactor hvm_build_set_params
>   libxl: fill vNUMA information in hvm info
>   xl: vNUMA support
> 
>  docs/man/xl.cfg.pod.5                   |   32 +++++
>  tools/firmware/hvmloader/acpi/acpi2_0.h |   61 +++++++++
>  tools/firmware/hvmloader/acpi/build.c   |  104 ++++++++++++++
>  tools/firmware/hvmloader/pci.c          |   13 ++
>  tools/libxc/include/xc_dom.h            |    5 +
>  tools/libxc/include/xenguest.h          |    7 +
>  tools/libxc/xc_dom_x86.c                |   72 ++++++++--
>  tools/libxc/xc_hvm_build_x86.c          |  224 +++++++++++++++++++-----------
>  tools/libxc/xc_private.h                |    2 +
>  tools/libxl/Makefile                    |    2 +-
>  tools/libxl/libxl_arch.h                |    6 +
>  tools/libxl/libxl_arm.c                 |   17 +++
>  tools/libxl/libxl_create.c              |    9 ++
>  tools/libxl/libxl_dom.c                 |  172 ++++++++++++++++++++---
>  tools/libxl/libxl_internal.h            |   18 +++
>  tools/libxl/libxl_types.idl             |    9 ++
>  tools/libxl/libxl_vnuma.c               |  228 +++++++++++++++++++++++++++++++
>  tools/libxl/libxl_x86.c                 |  113 +++++++++++++--
>  tools/libxl/xl_cmdimpl.c                |  151 ++++++++++++++++++++
>  xen/arch/x86/numa.c                     |   46 ++++++-
>  xen/common/memory.c                     |   58 +++++++-
>  xen/include/public/features.h           |    3 +
>  xen/include/public/hvm/hvm_info_table.h |   19 +++
>  xen/include/public/memory.h             |    2 +
>  24 files changed, 1247 insertions(+), 126 deletions(-)
>  create mode 100644 tools/libxl/libxl_vnuma.c
> 
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:02:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20:02:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XruPC-0004Fn-DQ; Fri, 21 Nov 2014 20:02: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 1XruPB-0004Fi-7f
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:02:09 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	9C/8E-27584-04A9F645; Fri, 21 Nov 2014 20:02:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416600126!12724063!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13986 invoked from network); 21 Nov 2014 20:02:07 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 20:02:07 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALK210m010756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 20:02:02 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALK20CO013223
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 20:02:01 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALK1xwm009880; Fri, 21 Nov 2014 20:02:00 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 12:01:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8E6A6118B53; Fri, 21 Nov 2014 15:01:58 -0500 (EST)
Date: Fri, 21 Nov 2014 15:01:58 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141121200158.GB16313@laptop.dumpdata.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 03:06:42PM +0000, Wei Liu wrote:
> Hi all
> 
> This patch series implements virtual NUMA support for both PV and HVM guest.
> That is, admin can configure via libxl what virtual NUMA topology the guest
> sees.
> 
> This is the stage 1 (basic vNUMA support) and part of stage 2 (vNUMA-ware
> ballooning, hypervisor side) described in my previous email to xen-devel [0].
> 
> This series is broken into several parts:
> 
> 1. xen patches: vNUMA debug output and vNUMA-aware memory hypercall support.
> 2. libxc/libxl support for PV vNUMA.
> 3. libxc/libxl support for HVM vNUMA.
> 4. xl vNUMA configuration documentation and parser.
> 
> I think one significant difference from Elena's work is that this patch series
> makes use of multiple vmemranges should there be a memory hole, instead of
> shrinking ram. This matches the behaviour of real hardware.

Are some of the patches then borrowed from Elena? If so, she should be credited
in the patches?
> 
> The vNUMA auto placement algorithm is missing at the moment and Dario is
> working on it.
> 
> This series can be found at:
>  git://xenbits.xen.org/people/liuw/xen.git wip.vnuma-v1 
> 
> With this series, the following configuration can be used to enabled virtual
> NUMA support, and it works for both PV and HVM guests.
> 
> memory = 6000
> vnuma_memory = [3000, 3000]
> vnuma_vcpu_map = [0, 1]
> vnuma_pnode_map = [0, 0]
> vnuma_vdistances = [10, 30] # optional
> 
> dmesg output for HVM guest:
> 
> [    0.000000] ACPI: SRAT 00000000fc009ff0 000C8 (v01    Xen      HVM 00000000 HVML 00000000)
> [    0.000000] ACPI: SLIT 00000000fc00a0c0 00030 (v01    Xen      HVM 00000000 HVML 00000000)
> <...snip...>
> [    0.000000] SRAT: PXM 0 -> APIC 0x00 -> Node 0
> [    0.000000] SRAT: PXM 1 -> APIC 0x02 -> Node 1
> [    0.000000] SRAT: Node 0 PXM 0 [mem 0x00000000-0xbb7fffff]
> [    0.000000] SRAT: Node 1 PXM 1 [mem 0xbb800000-0xefffffff]
> [    0.000000] SRAT: Node 1 PXM 1 [mem 0x100000000-0x186ffffff]
> [    0.000000] NUMA: Initialized distance table, cnt=2
> [    0.000000] NUMA: Node 1 [mem 0xbb800000-0xefffffff] + [mem 0x100000000-0x1867fffff] -> [mem 0xbb800000-0x1867fffff]
> [    0.000000] Initmem setup node 0 [mem 0x00000000-0xbb7fffff]
> [    0.000000]   NODE_DATA [mem 0xbb7fc000-0xbb7fffff]
> [    0.000000] Initmem setup node 1 [mem 0xbb800000-0x1867fffff]
> [    0.000000]   NODE_DATA [mem 0x1867f7000-0x1867fafff]
> [    0.000000]  [ffffea0000000000-ffffea00029fffff] PMD -> [ffff8800b8600000-ffff8800baffffff] on node 0
> [    0.000000]  [ffffea0002a00000-ffffea00055fffff] PMD -> [ffff880183000000-ffff8801859fffff] on node 1
> <...snip...>
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x00001000-0x0009efff]
> [    0.000000]   node   0: [mem 0x00100000-0xbb7fffff]
> [    0.000000]   node   1: [mem 0xbb800000-0xefffefff]
> [    0.000000]   node   1: [mem 0x100000000-0x1867fffff]
> 
> numactl output for HVM guest:
> 
> available: 2 nodes (0-1)
> node 0 cpus: 0
> node 0 size: 2999 MB
> node 0 free: 2546 MB
> node 1 cpus: 1
> node 1 size: 2991 MB
> node 1 free: 2144 MB
> node distances:
> node   0   1 
>   0:  10  30 
>   1:  30  10 
> 
> dmesg output for PV guest:
> 
> [    0.000000] NUMA: Initialized distance table, cnt=2
> [    0.000000] NUMA: Node 1 [mem 0xbb800000-0xce68efff] + [mem 0x100000000-0x1a8970fff] -> [mem 0xbb800000-0x1a8970fff]
> [    0.000000] NODE_DATA(0) allocated [mem 0xbb7fc000-0xbb7fffff]
> [    0.000000] NODE_DATA(1) allocated [mem 0x1a8969000-0x1a896cfff]
> 
> numactl output for PV guest:
> 
> available: 2 nodes (0-1)
> node 0 cpus: 0
> node 0 size: 2944 MB
> node 0 free: 2917 MB
> node 1 cpus: 1
> node 1 size: 2934 MB
> node 1 free: 2904 MB
> node distances:
> node   0   1 
>   0:  10  30
>   1:  30  10
> 
> And for a HVM guest on a real NUMA-capable machine:
> 
> (XEN) Memory location of each domain:
> (XEN) Domain 0 (total: 262144):
> (XEN)     Node 0: 245758
> (XEN)     Node 1: 16386
> (XEN) Domain 2 (total: 2097226):
> (XEN)     Node 0: 1046335
> (XEN)     Node 1: 1050891
> (XEN)      2 vnodes, 4 vcpus
> (XEN)        vnode   0 - pnode 0
> (XEN)         3840 MB:  0x0 - 0xf0000000
> (XEN)         256 MB:  0x100000000 - 0x110000000
> (XEN)         vcpus: 0 1 
> (XEN)        vnode   1 - pnode 1
> (XEN)         4096 MB:  0x110000000 - 0x210000000
> (XEN)         vcpus: 2 3 
> 
> Wei.
> 
> [0] <20141111173606.GC21312@zion.uk.xensource.com>
> 
> Wei Liu (19):
>   xen: dump vNUMA information with debug key "u"
>   xen: make two memory hypercalls vNUMA-aware
>   libxc: allocate memory with vNUMA information for PV guest
>   libxl: add emacs local variables in libxl_{x86,arm}.c
>   libxl: introduce vNUMA types
>   libxl: add vmemrange to libxl__domain_build_state
>   libxl: introduce libxl__vnuma_config_check
>   libxl: x86: factor out e820_host_sanitize
>   libxl: functions to build vmemranges for PV guest
>   libxl: build, check and pass vNUMA info to Xen for PV guest
>   hvmloader: add new fields for vNUMA information
>   hvmloader: construct SRAT
>   hvmloader: construct SLIT
>   hvmloader: disallow memory relocation when vNUMA is enabled
>   libxc: allocate memory with vNUMA information for HVM guest
>   libxl: build, check and pass vNUMA info to Xen for HVM guest
>   libxl: refactor hvm_build_set_params
>   libxl: fill vNUMA information in hvm info
>   xl: vNUMA support
> 
>  docs/man/xl.cfg.pod.5                   |   32 +++++
>  tools/firmware/hvmloader/acpi/acpi2_0.h |   61 +++++++++
>  tools/firmware/hvmloader/acpi/build.c   |  104 ++++++++++++++
>  tools/firmware/hvmloader/pci.c          |   13 ++
>  tools/libxc/include/xc_dom.h            |    5 +
>  tools/libxc/include/xenguest.h          |    7 +
>  tools/libxc/xc_dom_x86.c                |   72 ++++++++--
>  tools/libxc/xc_hvm_build_x86.c          |  224 +++++++++++++++++++-----------
>  tools/libxc/xc_private.h                |    2 +
>  tools/libxl/Makefile                    |    2 +-
>  tools/libxl/libxl_arch.h                |    6 +
>  tools/libxl/libxl_arm.c                 |   17 +++
>  tools/libxl/libxl_create.c              |    9 ++
>  tools/libxl/libxl_dom.c                 |  172 ++++++++++++++++++++---
>  tools/libxl/libxl_internal.h            |   18 +++
>  tools/libxl/libxl_types.idl             |    9 ++
>  tools/libxl/libxl_vnuma.c               |  228 +++++++++++++++++++++++++++++++
>  tools/libxl/libxl_x86.c                 |  113 +++++++++++++--
>  tools/libxl/xl_cmdimpl.c                |  151 ++++++++++++++++++++
>  xen/arch/x86/numa.c                     |   46 ++++++-
>  xen/common/memory.c                     |   58 +++++++-
>  xen/include/public/features.h           |    3 +
>  xen/include/public/hvm/hvm_info_table.h |   19 +++
>  xen/include/public/memory.h             |    2 +
>  24 files changed, 1247 insertions(+), 126 deletions(-)
>  create mode 100644 tools/libxl/libxl_vnuma.c
> 
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:03:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20: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 1XruQn-0004LB-T3; Fri, 21 Nov 2014 20:03:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1XruQm-0004L1-Qq
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:03:48 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	60/6E-27623-4AA9F645; Fri, 21 Nov 2014 20:03:48 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416600224!13007843!1
X-Originating-IP: [137.65.250.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18532 invoked from network); 21 Nov 2014 20:03:47 -0000
Received: from smtp2.provo.novell.com (HELO smtp2.provo.novell.com)
	(137.65.250.81)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 20:03:47 -0000
Received: from jfehlig2.provo.novell.com (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by smtp2.provo.novell.com with ESMTP (TLS encrypted);
	Fri, 21 Nov 2014 13:03:34 -0700
Message-ID: <546F9A95.1040909@suse.com>
Date: Fri, 21 Nov 2014 13:03:33 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	David Vrabel <david.vrabel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>	<54648EB3.8040703@citrix.com>	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>	<1415955718.31613.34.camel@citrix.com>	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>	<1416227964.5466.12.camel@citrix.com>	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>	<1416475824.14429.1.camel@citrix.com>	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>	<1416562126.26869.8.camel@citrix.com>	<1416578732.17932.9.camel@citrix.com>
	<546F49CD.1020907@citrix.com>
	<1416580373.17932.15.camel@citrix.com>
In-Reply-To: <1416580373.17932.15.camel@citrix.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xen.org,
	=?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 07:32 AM, Ian Campbell wrote:
> >From 9f2d8da8264b426f54b92378e9e00973694193d4 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 21 Nov 2014 14:00:38 +0000
> Subject: [PATCH] libxl: Allow libxl to find pygrub binary.
>
> Specifying an explicit path to pygrub (e.g. BINDIR "/pygrub") only works if
> Xen and libvirt happen to be installed to the same prefix. A more flexible
> approach is to simply specify "pygrub" which will cause libxl to use the
> correct path which it knows (since it is built with the same prefix as pygrub).
>
> This is particular problematic in the Debian packaging, since the Debian Xen
> package relocates pygrub into a libexec dir, however I think this change makes
> sense upstream.

Yep agreed.  I forgot about making this change a few weeks back after seeing the 
following in the logs when not explicitly specifying a bootloader

libxl: warning: libxl_bootloader.c:413:bootloader_disk_attached_cb: 
bootloader='/usr/bin/pygrub' is deprecated; use bootloader='pygrub' instead

>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>   .gnulib                |    2 +-
>   src/libxl/libxl_conf.h |    2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/.gnulib b/.gnulib
> index 9565c3b..2d28074 160000
> --- a/.gnulib
> +++ b/.gnulib
> @@ -1 +1 @@
> -Subproject commit 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d
> +Subproject commit 2d280742a9e30088aa169f53353765d5daafe4c0

ACK and pushed after removing this hunk.

Regards,
Jim

> diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
> index 25f77ea..d7a3971 100644
> --- a/src/libxl/libxl_conf.h
> +++ b/src/libxl/libxl_conf.h
> @@ -53,7 +53,7 @@
>   # define LIBXL_LIB_DIR LOCALSTATEDIR "/lib/libvirt/libxl"
>   # define LIBXL_SAVE_DIR LIBXL_LIB_DIR "/save"
>   # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump"
> -# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
> +# define LIBXL_BOOTLOADER_PATH "pygrub"
>   
>   /* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new
>    * parameter has been added, representative of 'VCPU soft affinity'. If one


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:03:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20: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 1XruQn-0004LB-T3; Fri, 21 Nov 2014 20:03:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1XruQm-0004L1-Qq
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:03:48 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	60/6E-27623-4AA9F645; Fri, 21 Nov 2014 20:03:48 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416600224!13007843!1
X-Originating-IP: [137.65.250.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18532 invoked from network); 21 Nov 2014 20:03:47 -0000
Received: from smtp2.provo.novell.com (HELO smtp2.provo.novell.com)
	(137.65.250.81)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 20:03:47 -0000
Received: from jfehlig2.provo.novell.com (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by smtp2.provo.novell.com with ESMTP (TLS encrypted);
	Fri, 21 Nov 2014 13:03:34 -0700
Message-ID: <546F9A95.1040909@suse.com>
Date: Fri, 21 Nov 2014 13:03:33 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	David Vrabel <david.vrabel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>	<54648EB3.8040703@citrix.com>	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>	<1415955718.31613.34.camel@citrix.com>	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>	<1416227964.5466.12.camel@citrix.com>	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>	<1416475824.14429.1.camel@citrix.com>	<CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>	<1416562126.26869.8.camel@citrix.com>	<1416578732.17932.9.camel@citrix.com>
	<546F49CD.1020907@citrix.com>
	<1416580373.17932.15.camel@citrix.com>
In-Reply-To: <1416580373.17932.15.camel@citrix.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xen.org,
	=?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 07:32 AM, Ian Campbell wrote:
> >From 9f2d8da8264b426f54b92378e9e00973694193d4 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 21 Nov 2014 14:00:38 +0000
> Subject: [PATCH] libxl: Allow libxl to find pygrub binary.
>
> Specifying an explicit path to pygrub (e.g. BINDIR "/pygrub") only works if
> Xen and libvirt happen to be installed to the same prefix. A more flexible
> approach is to simply specify "pygrub" which will cause libxl to use the
> correct path which it knows (since it is built with the same prefix as pygrub).
>
> This is particular problematic in the Debian packaging, since the Debian Xen
> package relocates pygrub into a libexec dir, however I think this change makes
> sense upstream.

Yep agreed.  I forgot about making this change a few weeks back after seeing the 
following in the logs when not explicitly specifying a bootloader

libxl: warning: libxl_bootloader.c:413:bootloader_disk_attached_cb: 
bootloader='/usr/bin/pygrub' is deprecated; use bootloader='pygrub' instead

>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>   .gnulib                |    2 +-
>   src/libxl/libxl_conf.h |    2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/.gnulib b/.gnulib
> index 9565c3b..2d28074 160000
> --- a/.gnulib
> +++ b/.gnulib
> @@ -1 +1 @@
> -Subproject commit 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d
> +Subproject commit 2d280742a9e30088aa169f53353765d5daafe4c0

ACK and pushed after removing this hunk.

Regards,
Jim

> diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
> index 25f77ea..d7a3971 100644
> --- a/src/libxl/libxl_conf.h
> +++ b/src/libxl/libxl_conf.h
> @@ -53,7 +53,7 @@
>   # define LIBXL_LIB_DIR LOCALSTATEDIR "/lib/libvirt/libxl"
>   # define LIBXL_SAVE_DIR LIBXL_LIB_DIR "/save"
>   # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump"
> -# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
> +# define LIBXL_BOOTLOADER_PATH "pygrub"
>   
>   /* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new
>    * parameter has been added, representative of 'VCPU soft affinity'. If one


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:20:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20: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 1XrugM-0004df-HP; Fri, 21 Nov 2014 20:19:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gedalya@gedalya.net>) id 1XrugL-0004da-CP
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:19:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	44/FD-09842-86E9F645; Fri, 21 Nov 2014 20:19:52 +0000
X-Env-Sender: gedalya@gedalya.net
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416601190!12363774!1
X-Originating-IP: [47.21.139.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20260 invoked from network); 21 Nov 2014 20:19:51 -0000
Received: from mail.gedalya.net (HELO mail.gedalya.net) (47.21.139.35)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Nov 2014 20:19:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gedalya.net;
	s=rsa1; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=s1fv90ZPNmM04Xmz2bjQ3mzbdJG7gLELChIzzPabfkQ=; 
	b=MdBSYIA2J7z9DqhXvhFvs5Bes4H1PmDJx6UHqGwp89aZFXgCDpdgjTtTL6iOC5NtDxMny1HJwwYMaK+V778G/rL34ExChQSVWONZdfzB5cz/QSJoBEWO0Cp1hcSJ2OXl8d/8x/5f/uDUf7xuEvBNxqRi/owCd+3P9vRhVxwa6zPITeyUFICbhp3qiB2MF1gXf7b4+8RIc4FjeWJD3ZIKMWXMF9knS/ZLbm+rr8dc756hZigoI2G5e8S55SGjtXza+Ivy80Ntp5PNJouNfNFg/u1MUmJVDWHaYpOBisZJaT48gHTjD+gta5o9jetNxJilmYEs3+p1i0vvUnJUvG9DOA==;
Received: from [192.168.9.10] by mail.gedalya.net with esmtpsa
	(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84)
	(envelope-from <gedalya@gedalya.net>)
	id 1XrugB-00020Q-9j; Fri, 21 Nov 2014 15:19:43 -0500
Message-ID: <546F9E5F.2000408@gedalya.net>
Date: Fri, 21 Nov 2014 15:19:43 -0500
From: Gedalya <gedalya@gedalya.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>	
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>
	<1416567797.26869.18.camel@citrix.com>
In-Reply-To: <1416567797.26869.18.camel@citrix.com>
Cc: wei.liu2@citrix.com, 767295@bugs.debian.org, xen-devel@lists.xen.org,
	ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 06:03 AM, Ian Campbell wrote:
>
>> So here's what happens now.
>> 1. Starts up tiny
>> 2. reboot: leak
>> 3. reboot: freed (process larger, but the delta is all/mostly shared pages)
>> 4. reboot: leak
>> 5. reboot: freed
>> etc..
> WTF, how very strange!
:-)

>
>> --- reboot domu ---
>>
>> root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
>> root     22981  0.6  3.3 131652 20008 ?        SLsl 21:55   0:00 /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
>> root@xen:~/xen-pkgs# pmap -x 22981
>> 22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
>> Address           Kbytes     RSS   Dirty Mode  Mapping
>> 0000000000400000     144     144       0 r-x-- xl
>> 0000000000623000       4       4       4 r---- xl
>> 0000000000624000       8       8       8 rw--- xl
>> 0000000000626000       4       4       4 rw---   [ anon ]
>> 00000000009a6000     288     288     288 rw---   [ anon ]
>> 00000000009ee000   35676   16772   16772 rw---   [ anon ]
> This is the (temporarily) leaked mapping, right?
Yea that's the one that popped in after the reboot..
About 16 MB.

>
>> Tried valgrind, it doesn't look like it was able to see what was going on
> Indeed. The values for total heap usage at exist and still reachable etc
> also don't seem to account for the ~3M of mapping on each iteration.
>
> I don't know how glibc's allocator works, but I suppose it isn't
> impossible that it is retaining some mappings of free regions and
> collecting them to free later somehow, which just happens to only
> trigger every other reboot (e.g. perhaps it is based on some threshold
> of free memory).
>
> ...investigates...
>
> So, http://man7.org/linux/man-pages/man3/malloc.3.html talks about
> special behaviour using mmap for allocations above MMAP_THRESHOLD (128K
> by default), which we will be hitting here I think. That explains the
> anon mapping.
>
> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about
> various dynamic thresholds for growing and shrinking the heap. My guess
> is that we are bouncing up and down over some threshold with every other
> reboot.
>
> Ian.
OK this is way over my head.. I don't have a full and precise 
understanding of all of the above, but let me try to comment nevertheless.
There are two issues here. The added mappings (as I understand, files, 
non-anon, shared) do happen only on reboot, but they're not a real 
memory leak issue because they are shared with other processes, so no 
matter ho many xl processes we have, it's only another 2.6 or so MB 
added to the total memory usage of the server, right?
On the other hand we have this anon area, 16 MB, that pops in on one 
reboot and gets freed on the next. That's the real issue, as I see it..!
And all that only starts happening after the last line of valgrind 
output. Valgrind only had output up to the first boot of the VM, none later.
For a fresh, non-rebooted domu, the xl process shows up as in top as 
~588 KB RES, 0 SHR, how can the latter be anyway?? I don't understand.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:20:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20: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 1XrugM-0004df-HP; Fri, 21 Nov 2014 20:19:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gedalya@gedalya.net>) id 1XrugL-0004da-CP
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:19:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	44/FD-09842-86E9F645; Fri, 21 Nov 2014 20:19:52 +0000
X-Env-Sender: gedalya@gedalya.net
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416601190!12363774!1
X-Originating-IP: [47.21.139.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20260 invoked from network); 21 Nov 2014 20:19:51 -0000
Received: from mail.gedalya.net (HELO mail.gedalya.net) (47.21.139.35)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Nov 2014 20:19:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gedalya.net;
	s=rsa1; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=s1fv90ZPNmM04Xmz2bjQ3mzbdJG7gLELChIzzPabfkQ=; 
	b=MdBSYIA2J7z9DqhXvhFvs5Bes4H1PmDJx6UHqGwp89aZFXgCDpdgjTtTL6iOC5NtDxMny1HJwwYMaK+V778G/rL34ExChQSVWONZdfzB5cz/QSJoBEWO0Cp1hcSJ2OXl8d/8x/5f/uDUf7xuEvBNxqRi/owCd+3P9vRhVxwa6zPITeyUFICbhp3qiB2MF1gXf7b4+8RIc4FjeWJD3ZIKMWXMF9knS/ZLbm+rr8dc756hZigoI2G5e8S55SGjtXza+Ivy80Ntp5PNJouNfNFg/u1MUmJVDWHaYpOBisZJaT48gHTjD+gta5o9jetNxJilmYEs3+p1i0vvUnJUvG9DOA==;
Received: from [192.168.9.10] by mail.gedalya.net with esmtpsa
	(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84)
	(envelope-from <gedalya@gedalya.net>)
	id 1XrugB-00020Q-9j; Fri, 21 Nov 2014 15:19:43 -0500
Message-ID: <546F9E5F.2000408@gedalya.net>
Date: Fri, 21 Nov 2014 15:19:43 -0500
From: Gedalya <gedalya@gedalya.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>	
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>
	<1416567797.26869.18.camel@citrix.com>
In-Reply-To: <1416567797.26869.18.camel@citrix.com>
Cc: wei.liu2@citrix.com, 767295@bugs.debian.org, xen-devel@lists.xen.org,
	ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 06:03 AM, Ian Campbell wrote:
>
>> So here's what happens now.
>> 1. Starts up tiny
>> 2. reboot: leak
>> 3. reboot: freed (process larger, but the delta is all/mostly shared pages)
>> 4. reboot: leak
>> 5. reboot: freed
>> etc..
> WTF, how very strange!
:-)

>
>> --- reboot domu ---
>>
>> root@xen:~/xen-pkgs# ps aux | grep asterisk_deb80
>> root     22981  0.6  3.3 131652 20008 ?        SLsl 21:55   0:00 /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
>> root@xen:~/xen-pkgs# pmap -x 22981
>> 22981:   /usr/lib/xen-4.4/bin/xl cr /etc/xen/auto/asterisk_deb80.cfg
>> Address           Kbytes     RSS   Dirty Mode  Mapping
>> 0000000000400000     144     144       0 r-x-- xl
>> 0000000000623000       4       4       4 r---- xl
>> 0000000000624000       8       8       8 rw--- xl
>> 0000000000626000       4       4       4 rw---   [ anon ]
>> 00000000009a6000     288     288     288 rw---   [ anon ]
>> 00000000009ee000   35676   16772   16772 rw---   [ anon ]
> This is the (temporarily) leaked mapping, right?
Yea that's the one that popped in after the reboot..
About 16 MB.

>
>> Tried valgrind, it doesn't look like it was able to see what was going on
> Indeed. The values for total heap usage at exist and still reachable etc
> also don't seem to account for the ~3M of mapping on each iteration.
>
> I don't know how glibc's allocator works, but I suppose it isn't
> impossible that it is retaining some mappings of free regions and
> collecting them to free later somehow, which just happens to only
> trigger every other reboot (e.g. perhaps it is based on some threshold
> of free memory).
>
> ...investigates...
>
> So, http://man7.org/linux/man-pages/man3/malloc.3.html talks about
> special behaviour using mmap for allocations above MMAP_THRESHOLD (128K
> by default), which we will be hitting here I think. That explains the
> anon mapping.
>
> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about
> various dynamic thresholds for growing and shrinking the heap. My guess
> is that we are bouncing up and down over some threshold with every other
> reboot.
>
> Ian.
OK this is way over my head.. I don't have a full and precise 
understanding of all of the above, but let me try to comment nevertheless.
There are two issues here. The added mappings (as I understand, files, 
non-anon, shared) do happen only on reboot, but they're not a real 
memory leak issue because they are shared with other processes, so no 
matter ho many xl processes we have, it's only another 2.6 or so MB 
added to the total memory usage of the server, right?
On the other hand we have this anon area, 16 MB, that pops in on one 
reboot and gets freed on the next. That's the real issue, as I see it..!
And all that only starts happening after the last line of valgrind 
output. Valgrind only had output up to the first boot of the VM, none later.
For a fresh, non-rebooted domu, the xl process shows up as in top as 
~588 KB RES, 0 SHR, how can the latter be anyway?? I don't understand.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:25:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrulN-0004td-EX; Fri, 21 Nov 2014 20:25:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gedalya@gedalya.net>) id 1XrulL-0004tY-MM
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:25:03 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	3D/B8-08051-F9F9F645; Fri, 21 Nov 2014 20:25:03 +0000
X-Env-Sender: gedalya@gedalya.net
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416601501!8667531!1
X-Originating-IP: [47.21.139.35]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27336 invoked from network); 21 Nov 2014 20:25:02 -0000
Received: from mail.gedalya.net (HELO mail.gedalya.net) (47.21.139.35)
	by server-16.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Nov 2014 20:25:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gedalya.net;
	s=rsa1; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=TTdeRcR2ID8lrvEW158RLS7NGSauF75DwWeLCosGQqA=; 
	b=cbV0bbuLiOxqWKAxvDo/n6qhuwng4LBYMBxUwwmKDit/NdKTSdWLKMG4b1XJvptTVssKKl9d4RZ3MHQNMTpdWzEPKjF5ArngqJjRCWSG6+qvSLE1wG1u4GX2xRvdmUPF7B84evN1Fbz4Ipxc7as0GUJvNRF8FTcDxw2bjX0HE5vqIHCmQ9BiPn0MaMXgff62LiFFZoWKPhExG6jhi2y51xjTjxaG/hpPuf0PxUKtrig9klJq8N6XUgVNmD4N4+GSLagNTzku8+2UjvtftreRFbvkEQcfT0DUmWU9R3EMqW1vnJcRmILVN+edN/oEl6HSI5u6YFWzwR0gaNzy63o1bg==;
Received: from [192.168.9.10] by mail.gedalya.net with esmtpsa
	(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84)
	(envelope-from <gedalya@gedalya.net>)
	id 1XrulI-00021C-CL; Fri, 21 Nov 2014 15:25:00 -0500
Message-ID: <546F9F9C.5090507@gedalya.net>
Date: Fri, 21 Nov 2014 15:25:00 -0500
From: Gedalya <gedalya@gedalya.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>	
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>	
	<1416567797.26869.18.camel@citrix.com>
	<1416568333.26869.22.camel@citrix.com>
In-Reply-To: <1416568333.26869.22.camel@citrix.com>
Cc: ian.jackson@eu.citrix.com, 767295@bugs.debian.org, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 06:12 AM, Ian Campbell wrote:
> On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote:
>> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about
>> various dynamic thresholds for growing and shrinking the heap. My guess
>> is that we are bouncing up and down over some threshold with every other
>> reboot.
> IOW I'm not overly concerned with this apparent bi-modality, so long as
> the amount isn't increasing in the long term...
>
> I think the original patch should go in.
>
> Ian.
>
>
It's an improvement, but consider this:
Someone has a xen host running wheezy, 40 domu's, with 768MB for dom0, 
worked fine so far. Tries upgrading to jessie, and lo, each domu process 
takes up only 588 KB on dom0, great!
Then a new kernel package is released, all domu's get rebooted once. All 
host memory is now full. Dude might have had other plans for that 
memory... This is dead memory so I guess it can be swapped out, not 
easily a scenario where the server totally crashes, but it's a bit ugly, 
we're talking about memory usage leaping from 0.6 to 16 MB per domu.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:25:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrulN-0004td-EX; Fri, 21 Nov 2014 20:25:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gedalya@gedalya.net>) id 1XrulL-0004tY-MM
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:25:03 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	3D/B8-08051-F9F9F645; Fri, 21 Nov 2014 20:25:03 +0000
X-Env-Sender: gedalya@gedalya.net
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416601501!8667531!1
X-Originating-IP: [47.21.139.35]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27336 invoked from network); 21 Nov 2014 20:25:02 -0000
Received: from mail.gedalya.net (HELO mail.gedalya.net) (47.21.139.35)
	by server-16.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Nov 2014 20:25:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gedalya.net;
	s=rsa1; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=TTdeRcR2ID8lrvEW158RLS7NGSauF75DwWeLCosGQqA=; 
	b=cbV0bbuLiOxqWKAxvDo/n6qhuwng4LBYMBxUwwmKDit/NdKTSdWLKMG4b1XJvptTVssKKl9d4RZ3MHQNMTpdWzEPKjF5ArngqJjRCWSG6+qvSLE1wG1u4GX2xRvdmUPF7B84evN1Fbz4Ipxc7as0GUJvNRF8FTcDxw2bjX0HE5vqIHCmQ9BiPn0MaMXgff62LiFFZoWKPhExG6jhi2y51xjTjxaG/hpPuf0PxUKtrig9klJq8N6XUgVNmD4N4+GSLagNTzku8+2UjvtftreRFbvkEQcfT0DUmWU9R3EMqW1vnJcRmILVN+edN/oEl6HSI5u6YFWzwR0gaNzy63o1bg==;
Received: from [192.168.9.10] by mail.gedalya.net with esmtpsa
	(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84)
	(envelope-from <gedalya@gedalya.net>)
	id 1XrulI-00021C-CL; Fri, 21 Nov 2014 15:25:00 -0500
Message-ID: <546F9F9C.5090507@gedalya.net>
Date: Fri, 21 Nov 2014 15:25:00 -0500
From: Gedalya <gedalya@gedalya.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>	
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>	
	<1416567797.26869.18.camel@citrix.com>
	<1416568333.26869.22.camel@citrix.com>
In-Reply-To: <1416568333.26869.22.camel@citrix.com>
Cc: ian.jackson@eu.citrix.com, 767295@bugs.debian.org, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 06:12 AM, Ian Campbell wrote:
> On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote:
>> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about
>> various dynamic thresholds for growing and shrinking the heap. My guess
>> is that we are bouncing up and down over some threshold with every other
>> reboot.
> IOW I'm not overly concerned with this apparent bi-modality, so long as
> the amount isn't increasing in the long term...
>
> I think the original patch should go in.
>
> Ian.
>
>
It's an improvement, but consider this:
Someone has a xen host running wheezy, 40 domu's, with 768MB for dom0, 
worked fine so far. Tries upgrading to jessie, and lo, each domu process 
takes up only 588 KB on dom0, great!
Then a new kernel package is released, all domu's get rebooted once. All 
host memory is now full. Dude might have had other plans for that 
memory... This is dead memory so I guess it can be swapped out, not 
easily a scenario where the server totally crashes, but it's a bit ugly, 
we're talking about memory usage leaping from 0.6 to 16 MB per domu.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:45:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20: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 1Xrv4e-0005EW-8Z; Fri, 21 Nov 2014 20:45:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrv4c-0005ER-V5
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:44:59 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	DA/76-15461-A44AF645; Fri, 21 Nov 2014 20:44:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416602693!11062931!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1609 invoked from network); 21 Nov 2014 20:44:57 -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;
	21 Nov 2014 20:44:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193856813"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 15:44:49 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xrv4T-0001cf-4E;
	Fri, 21 Nov 2014 20:44:49 +0000
Date: Fri, 21 Nov 2014 20:44:49 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141121204449.GA19915@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<20141121200158.GB16313@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141121200158.GB16313@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 03:01:58PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 03:06:42PM +0000, Wei Liu wrote:
> > Hi all
> > 
> > This patch series implements virtual NUMA support for both PV and HVM guest.
> > That is, admin can configure via libxl what virtual NUMA topology the guest
> > sees.
> > 
> > This is the stage 1 (basic vNUMA support) and part of stage 2 (vNUMA-ware
> > ballooning, hypervisor side) described in my previous email to xen-devel [0].
> > 
> > This series is broken into several parts:
> > 
> > 1. xen patches: vNUMA debug output and vNUMA-aware memory hypercall support.
> > 2. libxc/libxl support for PV vNUMA.
> > 3. libxc/libxl support for HVM vNUMA.
> > 4. xl vNUMA configuration documentation and parser.
> > 
> > I think one significant difference from Elena's work is that this patch series
> > makes use of multiple vmemranges should there be a memory hole, instead of
> > shrinking ram. This matches the behaviour of real hardware.
> 
> Are some of the patches then borrowed from Elena? If so, she should be credited
> in the patches?
> > 

Due to the fact that libxl interface changed, as well as lots of
assumptions, I only have one patch taken from her (the first one) and
rewrote PV toolstack implementation.

Elena, if you discover that I didn't credit you for later patches, don't
hesitate to tell me. ;-)

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:45:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20: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 1Xrv4e-0005EW-8Z; Fri, 21 Nov 2014 20:45:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xrv4c-0005ER-V5
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:44:59 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	DA/76-15461-A44AF645; Fri, 21 Nov 2014 20:44:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416602693!11062931!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1609 invoked from network); 21 Nov 2014 20:44:57 -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;
	21 Nov 2014 20:44:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="193856813"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 21 Nov 2014 15:44:49 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xrv4T-0001cf-4E;
	Fri, 21 Nov 2014 20:44:49 +0000
Date: Fri, 21 Nov 2014 20:44:49 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141121204449.GA19915@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<20141121200158.GB16313@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141121200158.GB16313@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/19] Virtual NUMA for 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 03:01:58PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 03:06:42PM +0000, Wei Liu wrote:
> > Hi all
> > 
> > This patch series implements virtual NUMA support for both PV and HVM guest.
> > That is, admin can configure via libxl what virtual NUMA topology the guest
> > sees.
> > 
> > This is the stage 1 (basic vNUMA support) and part of stage 2 (vNUMA-ware
> > ballooning, hypervisor side) described in my previous email to xen-devel [0].
> > 
> > This series is broken into several parts:
> > 
> > 1. xen patches: vNUMA debug output and vNUMA-aware memory hypercall support.
> > 2. libxc/libxl support for PV vNUMA.
> > 3. libxc/libxl support for HVM vNUMA.
> > 4. xl vNUMA configuration documentation and parser.
> > 
> > I think one significant difference from Elena's work is that this patch series
> > makes use of multiple vmemranges should there be a memory hole, instead of
> > shrinking ram. This matches the behaviour of real hardware.
> 
> Are some of the patches then borrowed from Elena? If so, she should be credited
> in the patches?
> > 

Due to the fact that libxl interface changed, as well as lots of
assumptions, I only have one patch taken from her (the first one) and
rewrote PV toolstack implementation.

Elena, if you discover that I didn't credit you for later patches, don't
hesitate to tell me. ;-)

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:57:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20: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 1XrvGY-0005T4-Iv; Fri, 21 Nov 2014 20:57:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XrvGX-0005Sz-BN
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:57:17 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	28/08-24124-C27AF645; Fri, 21 Nov 2014 20:57:16 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416603435!12770828!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12462 invoked from network); 21 Nov 2014 20:57:15 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-4.tower-206.messagelabs.com with SMTP;
	21 Nov 2014 20:57:15 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sALKvEip000993;
	Fri, 21 Nov 2014 14:57:14 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sALKvEwO000992;
	Fri, 21 Nov 2014 14:57:14 -0600
Date: Fri, 21 Nov 2014 14:57:14 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201411212057.sALKvEwO000992@wind.enjellic.com>
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: xen-devel@lists.xen.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Fri, 21 Nov 2014 14:57:14 -0600 (CST)
Subject: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, hope the week is ending well for everyone.

As readers of the list may remember we've kept the ATI primary adapter
passthrough patches current for qemu-traditional on Xen for a number
of years.  Our 'run-passthrough' utility for binding/unbind devices
and running a Windows guest with passthrough have enjoyed a tidy
number of downloads through the years as well.

We are taking on a passthrough project and in the process upgrading
our infrastructure to 4.4.x.  We also need to take on the issue of
passing Intel IGD adapters through to a windows guest.  We are
currently working on an Intel Q77 (DQ77KB) board in preparation for
moving to Q87 boards.

The Intel display adapter is showing up as the standard 00:02.0 PCI
device and things go south pretty quickly.  We create a slot for the
device on the pciback driver and as soon as we bind the device the
machine goes out like a light, no logs or diagnostics, just instantly
stone dead.

This issue is invariant over pciback in vpci or passthrough modes.  It
also occurs instantly when the pciback assignment is made with 'xl
pci-assignable-add'.

We will throw a '#define DEBUG 1' in the top of all the xen-pciback
driver code and see if we can get more information out of it.  I just
wanted to get this in front of the list in case this is a well known
issue or we are headed into other problems we should know about.

I'm assuming that qemu-traditional will handle an IGD primary
passthrough.  If any of the Intel guys are reading this give me a
shout with some directions/advice if we need to roll up our sleeves
and modify the device emulator.

At least it is an "Outlaw Josey Whales bug', not hard to track, leaves
dead machines wherever it goes... :-)

Best wishes for a pleasant weekend to everyone.

Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"The cynics are right nine times out of ten."
                                -- H. L. Mencken

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 20:57:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 20: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 1XrvGY-0005T4-Iv; Fri, 21 Nov 2014 20:57:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XrvGX-0005Sz-BN
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 20:57:17 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	28/08-24124-C27AF645; Fri, 21 Nov 2014 20:57:16 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416603435!12770828!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12462 invoked from network); 21 Nov 2014 20:57:15 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-4.tower-206.messagelabs.com with SMTP;
	21 Nov 2014 20:57:15 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sALKvEip000993;
	Fri, 21 Nov 2014 14:57:14 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sALKvEwO000992;
	Fri, 21 Nov 2014 14:57:14 -0600
Date: Fri, 21 Nov 2014 14:57:14 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201411212057.sALKvEwO000992@wind.enjellic.com>
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: xen-devel@lists.xen.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Fri, 21 Nov 2014 14:57:14 -0600 (CST)
Subject: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, hope the week is ending well for everyone.

As readers of the list may remember we've kept the ATI primary adapter
passthrough patches current for qemu-traditional on Xen for a number
of years.  Our 'run-passthrough' utility for binding/unbind devices
and running a Windows guest with passthrough have enjoyed a tidy
number of downloads through the years as well.

We are taking on a passthrough project and in the process upgrading
our infrastructure to 4.4.x.  We also need to take on the issue of
passing Intel IGD adapters through to a windows guest.  We are
currently working on an Intel Q77 (DQ77KB) board in preparation for
moving to Q87 boards.

The Intel display adapter is showing up as the standard 00:02.0 PCI
device and things go south pretty quickly.  We create a slot for the
device on the pciback driver and as soon as we bind the device the
machine goes out like a light, no logs or diagnostics, just instantly
stone dead.

This issue is invariant over pciback in vpci or passthrough modes.  It
also occurs instantly when the pciback assignment is made with 'xl
pci-assignable-add'.

We will throw a '#define DEBUG 1' in the top of all the xen-pciback
driver code and see if we can get more information out of it.  I just
wanted to get this in front of the list in case this is a well known
issue or we are headed into other problems we should know about.

I'm assuming that qemu-traditional will handle an IGD primary
passthrough.  If any of the Intel guys are reading this give me a
shout with some directions/advice if we need to roll up our sleeves
and modify the device emulator.

At least it is an "Outlaw Josey Whales bug', not hard to track, leaves
dead machines wherever it goes... :-)

Best wishes for a pleasant weekend to everyone.

Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"The cynics are right nine times out of ten."
                                -- H. L. Mencken

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 21:02:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 21:02:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrvLi-0005dr-Ao; Fri, 21 Nov 2014 21:02:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XrvLg-0005dh-G4
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 21:02:36 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	39/5A-02954-B68AF645; Fri, 21 Nov 2014 21:02:35 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416603754!14109651!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12655 invoked from network); 21 Nov 2014 21:02:35 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-8.tower-27.messagelabs.com with SMTP;
	21 Nov 2014 21:02:35 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sALL2X9E001073
	for <xen-devel@lists.xen.org>; Fri, 21 Nov 2014 15:02:33 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sALL2XZu001067
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:02:33 -0600
Date: Fri, 21 Nov 2014 15:02:33 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201411212102.sALL2XZu001067@wind.enjellic.com>
In-Reply-To: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
	"[Xen-devel] Q77 IGD instantly crashes on xen-pciback bind." (Nov 21,
	2:57pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: xen-devel@lists.xen.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Fri, 21 Nov 2014 15:02:34 -0600 (CST)
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Nov 21,  2:57pm, "Dr. Greg Wettstein" wrote:
} Subject: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.

> Hi, hope the week is ending well for everyone.

As I was walking out the door I remembered I had been delinquent with
information.  The dom0 kernel is 32-bit 3.14.22 straight from
kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.

The machine hang is reproducible in the absence of even starting a
guest so the problem appears to be specific to the process of
preparing the device for export through xen-pciback.

Greg

}-- End of excerpt from "Dr. Greg Wettstein"

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Fools ignore complexity.  Pragmatists suffer it.  Some can avoid it.
Geniuses remove it.
                                -- Perliss' Programming Proverb #58
                                   SIGPLAN National, Sept. 1982

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 21:02:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 21:02:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrvLi-0005dr-Ao; Fri, 21 Nov 2014 21:02:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XrvLg-0005dh-G4
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 21:02:36 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	39/5A-02954-B68AF645; Fri, 21 Nov 2014 21:02:35 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416603754!14109651!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12655 invoked from network); 21 Nov 2014 21:02:35 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-8.tower-27.messagelabs.com with SMTP;
	21 Nov 2014 21:02:35 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sALL2X9E001073
	for <xen-devel@lists.xen.org>; Fri, 21 Nov 2014 15:02:33 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sALL2XZu001067
	for xen-devel@lists.xen.org; Fri, 21 Nov 2014 15:02:33 -0600
Date: Fri, 21 Nov 2014 15:02:33 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201411212102.sALL2XZu001067@wind.enjellic.com>
In-Reply-To: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
	"[Xen-devel] Q77 IGD instantly crashes on xen-pciback bind." (Nov 21,
	2:57pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: xen-devel@lists.xen.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Fri, 21 Nov 2014 15:02:34 -0600 (CST)
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Nov 21,  2:57pm, "Dr. Greg Wettstein" wrote:
} Subject: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.

> Hi, hope the week is ending well for everyone.

As I was walking out the door I remembered I had been delinquent with
information.  The dom0 kernel is 32-bit 3.14.22 straight from
kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.

The machine hang is reproducible in the absence of even starting a
guest so the problem appears to be specific to the process of
preparing the device for export through xen-pciback.

Greg

}-- End of excerpt from "Dr. Greg Wettstein"

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Fools ignore complexity.  Pragmatists suffer it.  Some can avoid it.
Geniuses remove it.
                                -- Perliss' Programming Proverb #58
                                   SIGPLAN National, Sept. 1982

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 21:26:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 21:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrvih-00063w-GS; Fri, 21 Nov 2014 21:26:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xrvig-00063r-B6
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 21:26:22 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	F7/37-02707-DFDAF645; Fri, 21 Nov 2014 21:26:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416605178!7341809!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16458 invoked from network); 21 Nov 2014 21:26:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 21:26:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195407206"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 16:26:14 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrviY-00027d-Ui;
	Fri, 21 Nov 2014 21:26:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrviY-0002Zr-Nr;
	Fri, 21 Nov 2014 21:26:14 +0000
Date: Fri, 21 Nov 2014 21:26:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31681-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31681: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31681 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31681/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 31659

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 31659

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  09ff8eadec09233b905f79579900006fb17dd55f
baseline version:
 xen                  0540b854f6733759593e829bc3f13c9b45974e32

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <Ian.Jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 09ff8eadec09233b905f79579900006fb17dd55f
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Nov 5 14:32:47 2014 +0000

    libxl: CODING_STYLE: Discuss existing style problems
    
    Document that:
     - the existing code is not all confirming yet
     - code should conform
     - we will sometimes accept patches with nonconforming elements if
       they don't make matters worse.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit dbdd03d0ad4ad93f1db50341fac56a514c726552
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Nov 5 14:26:59 2014 +0000

    libxl: CODING_STYLE: Mention function out parameters
    
    We seem to use both `_r' and `_out'.  Document both.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit b162d7d487f44803df96e6da6bf9bb37f59b276b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Nov 5 14:26:30 2014 +0000

    libxl: CODING_STYLE: Deprecate `error' for out blocks
    
    We should have only one name for this and `out' is more prevalent.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 0d8e5375af9d782ce40c1a2f9914952ffc83c98a
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Nov 5 14:25:03 2014 +0000

    libxl: CODING_STYLE: Much new material
    
    Discuss:
    
        Memory allocation
        Conventional variable names
        Convenience macros
        Error handling
        Idempotent data structure construction/destruction
        Asynchronous/long-running operations
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 1d68c1a70e00ed95ef0889cfa005379dab27b37d
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:16:23 2014 +0100

    x86emul: enforce privilege level restrictions when loading CS
    
    Privilege level checks were basically missing for the CS case, the
    only check that was done (RPL == DPL for nonconforming segments)
    was solely covering a single special case (return to non-conforming
    segment).
    
    Additionally in long mode the L bit set requires the D bit to be clear,
    as was recently pointed out for KVM by Nadav Amit
    <namit@cs.technion.ac.il>.
    
    Finally we also need to force the loaded selector's RPL to CPL (at
    least as long as lret/retf emulation doesn't support privilege level
    changes).
    
    This is CVE-2014-8595 / XSA-110.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit e4292c5aac41b80f33d4877104348d5ee7c95aa4
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:15:21 2014 +0100

    x86: don't allow page table updates on non-PV page tables in do_mmu_update()
    
    paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
    consistently supported for non-PV guests (they'd deref NULL for PVH or
    non-HAP HVM ones). Don't allow respective MMU_* operations on the
    page tables of such domains.
    
    This is CVE-2014-8594 / XSA-109.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 21:26:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 21:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrvih-00063w-GS; Fri, 21 Nov 2014 21:26:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xrvig-00063r-B6
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 21:26:22 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	F7/37-02707-DFDAF645; Fri, 21 Nov 2014 21:26:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416605178!7341809!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16458 invoked from network); 21 Nov 2014 21:26:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 21:26:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="195407206"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 16:26:14 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrviY-00027d-Ui;
	Fri, 21 Nov 2014 21:26:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrviY-0002Zr-Nr;
	Fri, 21 Nov 2014 21:26:14 +0000
Date: Fri, 21 Nov 2014 21:26:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31681-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31681: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31681 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31681/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 31659

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 31659

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  09ff8eadec09233b905f79579900006fb17dd55f
baseline version:
 xen                  0540b854f6733759593e829bc3f13c9b45974e32

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <Ian.Jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 09ff8eadec09233b905f79579900006fb17dd55f
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Nov 5 14:32:47 2014 +0000

    libxl: CODING_STYLE: Discuss existing style problems
    
    Document that:
     - the existing code is not all confirming yet
     - code should conform
     - we will sometimes accept patches with nonconforming elements if
       they don't make matters worse.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit dbdd03d0ad4ad93f1db50341fac56a514c726552
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Nov 5 14:26:59 2014 +0000

    libxl: CODING_STYLE: Mention function out parameters
    
    We seem to use both `_r' and `_out'.  Document both.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit b162d7d487f44803df96e6da6bf9bb37f59b276b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Nov 5 14:26:30 2014 +0000

    libxl: CODING_STYLE: Deprecate `error' for out blocks
    
    We should have only one name for this and `out' is more prevalent.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 0d8e5375af9d782ce40c1a2f9914952ffc83c98a
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Nov 5 14:25:03 2014 +0000

    libxl: CODING_STYLE: Much new material
    
    Discuss:
    
        Memory allocation
        Conventional variable names
        Convenience macros
        Error handling
        Idempotent data structure construction/destruction
        Asynchronous/long-running operations
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 1d68c1a70e00ed95ef0889cfa005379dab27b37d
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:16:23 2014 +0100

    x86emul: enforce privilege level restrictions when loading CS
    
    Privilege level checks were basically missing for the CS case, the
    only check that was done (RPL == DPL for nonconforming segments)
    was solely covering a single special case (return to non-conforming
    segment).
    
    Additionally in long mode the L bit set requires the D bit to be clear,
    as was recently pointed out for KVM by Nadav Amit
    <namit@cs.technion.ac.il>.
    
    Finally we also need to force the loaded selector's RPL to CPL (at
    least as long as lret/retf emulation doesn't support privilege level
    changes).
    
    This is CVE-2014-8595 / XSA-110.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit e4292c5aac41b80f33d4877104348d5ee7c95aa4
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:15:21 2014 +0100

    x86: don't allow page table updates on non-PV page tables in do_mmu_update()
    
    paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
    consistently supported for non-PV guests (they'd deref NULL for PVH or
    non-HAP HVM ones). Don't allow respective MMU_* operations on the
    page tables of such domains.
    
    This is CVE-2014-8594 / XSA-109.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:04:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:04:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwIw-0006YW-Io; Fri, 21 Nov 2014 22:03:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwIv-0006YR-5e
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:03:49 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	36/43-27584-4C6BF645; Fri, 21 Nov 2014 22:03:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416607426!8632276!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16834 invoked from network); 21 Nov 2014 22:03:47 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 22:03:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALM3gXR001951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:03:43 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALM3fv5005481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 22:03:41 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALM3eMD013728; Fri, 21 Nov 2014 22:03:40 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:03:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A3DE8118BDC; Fri, 21 Nov 2014 17:03:38 -0500 (EST)
Date: Fri, 21 Nov 2014 17:03:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com
Message-ID: <20141121220338.GA17981@laptop.dumpdata.com>
References: <545B9C5F020000780004561B@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545B9C5F020000780004561B@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-pciback: drop SR-IOV VFs when PF driver
	unloads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 03:05:51PM +0000, Jan Beulich wrote:
> When a PF driver unloads, it may find it necessary to leave the VFs
> around simply because of pciback having marked them as assigned to a
> guest. Utilize a suitable notification to let go of the VFs, thus
> allowing the PF to go back into the state it was before its driver
> loaded (which in particular allows the driver to be loaded again with
> it being able to create the VFs anew, but which also allows to then
> pass through the PF instead of the VFs).
> 
> Don't do this however for any VFs currently in active use by a guest.

I rewrote it a bit to be more in the style of pciback:


>From d364ca863f5d506750171ca014f6100080b029dc Mon Sep 17 00:00:00 2001
From: Jan Beulich <JBeulich@suse.com>
Date: Thu, 6 Nov 2014 15:05:51 +0000
Subject: [PATCH] xen-pciback: drop SR-IOV VFs when PF driver unloads

When a PF driver unloads, it may find it necessary to leave the VFs
around simply because of pciback having marked them as assigned to a
guest. Utilize a suitable notification to let go of the VFs, thus
allowing the PF to go back into the state it was before its driver
loaded (which in particular allows the driver to be loaded again with
it being able to create the VFs anew, but which also allows to then
pass through the PF instead of the VFs).

Don't do this however for any VFs currently in active use by a guest.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
[v2: Removed the switch statement, moved it about]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 43 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 017069a..0763e01 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -1502,6 +1502,42 @@ parse_error:
 fs_initcall(pcistub_init);
 #endif
 
+#ifdef CONFIG_PCI_IOV
+static int pci_stub_notifier(struct notifier_block *nb,
+			     unsigned long action, void *data)
+{
+	struct device *dev = data;
+	const struct pci_dev *pdev = to_pci_dev(dev);
+	struct pcistub_device *psdev;
+	unsigned long flags;
+	bool found = false;
+
+	if (action != BUS_NOTIFY_UNBIND_DRIVER)
+		goto out;
+
+	if (!pdev->is_physfn)
+		goto out;
+
+	spin_lock_irqsave(&pcistub_devices_lock, flags);
+	list_for_each_entry(psdev, &pcistub_devices, dev_list) {
+		if (!psdev->pdev && psdev->dev != pdev
+		    && pci_physfn(psdev->dev) == pdev) {
+			found = true;
+			break;
+		}
+	}
+	spin_unlock_irqrestore(&pcistub_devices_lock, flags);
+	if (found)
+		device_release_driver(&psdev->dev->dev);
+out:
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block pci_stub_nb = {
+	.notifier_call = pci_stub_notifier,
+};
+#endif
+
 static int __init xen_pcibk_init(void)
 {
 	int err;
@@ -1523,12 +1559,19 @@ static int __init xen_pcibk_init(void)
 	err = xen_pcibk_xenbus_register();
 	if (err)
 		pcistub_exit();
+#ifdef CONFIG_PCI_IOV
+	else
+		bus_register_notifier(&pci_bus_type, &pci_stub_nb);
+#endif
 
 	return err;
 }
 
 static void __exit xen_pcibk_cleanup(void)
 {
+#ifdef CONFIG_PCI_IOV
+	bus_unregister_notifier(&pci_bus_type, &pci_stub_nb);
+#endif
 	xen_pcibk_xenbus_unregister();
 	pcistub_exit();
 }
-- 
1.9.3



Haven't yet tested it.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
>  drivers/xen/xen-pciback/pci_stub.c |   46 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> --- 3.18-rc3/drivers/xen/xen-pciback/pci_stub.c
> +++ 3.18-rc3-pciback-release-VFs/drivers/xen/xen-pciback/pci_stub.c
> @@ -1502,6 +1502,45 @@ parse_error:
>  fs_initcall(pcistub_init);
>  #endif
>  
> +#ifdef CONFIG_PCI_IOV
> +static int pci_stub_notifier(struct notifier_block *nb,
> +			     unsigned long action, void *data)
> +{
> +	struct device *dev = data;
> +	const struct pci_dev *pdev = to_pci_dev(dev);
> +
> +	switch (action) {
> +	case BUS_NOTIFY_UNBIND_DRIVER:
> +		if (!pdev->is_physfn)
> +			break;
> +		for (;;) {
> +			struct pcistub_device *psdev;
> +			unsigned long flags;
> +			bool found = false;
> +
> +			spin_lock_irqsave(&pcistub_devices_lock, flags);
> +			list_for_each_entry(psdev, &pcistub_devices, dev_list)
> +				if (!psdev->pdev && psdev->dev != pdev
> +				    && pci_physfn(psdev->dev) == pdev) {
> +					found = true;
> +					break;
> +				}
> +			spin_unlock_irqrestore(&pcistub_devices_lock, flags);
> +			if (!found)
> +				break;
> +			device_release_driver(&psdev->dev->dev);
> +		}
> +		break;
> +	}
> +
> +	return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block pci_stub_nb = {
> +	.notifier_call = pci_stub_notifier,
> +};
> +#endif
> +
>  static int __init xen_pcibk_init(void)
>  {
>  	int err;
> @@ -1523,12 +1562,19 @@ static int __init xen_pcibk_init(void)
>  	err = xen_pcibk_xenbus_register();
>  	if (err)
>  		pcistub_exit();
> +#ifdef CONFIG_PCI_IOV
> +	else
> +		bus_register_notifier(&pci_bus_type, &pci_stub_nb);
> +#endif
>  
>  	return err;
>  }
>  
>  static void __exit xen_pcibk_cleanup(void)
>  {
> +#ifdef CONFIG_PCI_IOV
> +	bus_unregister_notifier(&pci_bus_type, &pci_stub_nb);
> +#endif
>  	xen_pcibk_xenbus_unregister();
>  	pcistub_exit();
>  }
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:04:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:04:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwIw-0006YW-Io; Fri, 21 Nov 2014 22:03:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwIv-0006YR-5e
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:03:49 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	36/43-27584-4C6BF645; Fri, 21 Nov 2014 22:03:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416607426!8632276!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16834 invoked from network); 21 Nov 2014 22:03:47 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 22:03:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALM3gXR001951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:03:43 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALM3fv5005481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 22:03:41 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALM3eMD013728; Fri, 21 Nov 2014 22:03:40 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:03:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A3DE8118BDC; Fri, 21 Nov 2014 17:03:38 -0500 (EST)
Date: Fri, 21 Nov 2014 17:03:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com
Message-ID: <20141121220338.GA17981@laptop.dumpdata.com>
References: <545B9C5F020000780004561B@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545B9C5F020000780004561B@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-pciback: drop SR-IOV VFs when PF driver
	unloads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 06, 2014 at 03:05:51PM +0000, Jan Beulich wrote:
> When a PF driver unloads, it may find it necessary to leave the VFs
> around simply because of pciback having marked them as assigned to a
> guest. Utilize a suitable notification to let go of the VFs, thus
> allowing the PF to go back into the state it was before its driver
> loaded (which in particular allows the driver to be loaded again with
> it being able to create the VFs anew, but which also allows to then
> pass through the PF instead of the VFs).
> 
> Don't do this however for any VFs currently in active use by a guest.

I rewrote it a bit to be more in the style of pciback:


>From d364ca863f5d506750171ca014f6100080b029dc Mon Sep 17 00:00:00 2001
From: Jan Beulich <JBeulich@suse.com>
Date: Thu, 6 Nov 2014 15:05:51 +0000
Subject: [PATCH] xen-pciback: drop SR-IOV VFs when PF driver unloads

When a PF driver unloads, it may find it necessary to leave the VFs
around simply because of pciback having marked them as assigned to a
guest. Utilize a suitable notification to let go of the VFs, thus
allowing the PF to go back into the state it was before its driver
loaded (which in particular allows the driver to be loaded again with
it being able to create the VFs anew, but which also allows to then
pass through the PF instead of the VFs).

Don't do this however for any VFs currently in active use by a guest.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
[v2: Removed the switch statement, moved it about]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 43 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 017069a..0763e01 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -1502,6 +1502,42 @@ parse_error:
 fs_initcall(pcistub_init);
 #endif
 
+#ifdef CONFIG_PCI_IOV
+static int pci_stub_notifier(struct notifier_block *nb,
+			     unsigned long action, void *data)
+{
+	struct device *dev = data;
+	const struct pci_dev *pdev = to_pci_dev(dev);
+	struct pcistub_device *psdev;
+	unsigned long flags;
+	bool found = false;
+
+	if (action != BUS_NOTIFY_UNBIND_DRIVER)
+		goto out;
+
+	if (!pdev->is_physfn)
+		goto out;
+
+	spin_lock_irqsave(&pcistub_devices_lock, flags);
+	list_for_each_entry(psdev, &pcistub_devices, dev_list) {
+		if (!psdev->pdev && psdev->dev != pdev
+		    && pci_physfn(psdev->dev) == pdev) {
+			found = true;
+			break;
+		}
+	}
+	spin_unlock_irqrestore(&pcistub_devices_lock, flags);
+	if (found)
+		device_release_driver(&psdev->dev->dev);
+out:
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block pci_stub_nb = {
+	.notifier_call = pci_stub_notifier,
+};
+#endif
+
 static int __init xen_pcibk_init(void)
 {
 	int err;
@@ -1523,12 +1559,19 @@ static int __init xen_pcibk_init(void)
 	err = xen_pcibk_xenbus_register();
 	if (err)
 		pcistub_exit();
+#ifdef CONFIG_PCI_IOV
+	else
+		bus_register_notifier(&pci_bus_type, &pci_stub_nb);
+#endif
 
 	return err;
 }
 
 static void __exit xen_pcibk_cleanup(void)
 {
+#ifdef CONFIG_PCI_IOV
+	bus_unregister_notifier(&pci_bus_type, &pci_stub_nb);
+#endif
 	xen_pcibk_xenbus_unregister();
 	pcistub_exit();
 }
-- 
1.9.3



Haven't yet tested it.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
>  drivers/xen/xen-pciback/pci_stub.c |   46 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> --- 3.18-rc3/drivers/xen/xen-pciback/pci_stub.c
> +++ 3.18-rc3-pciback-release-VFs/drivers/xen/xen-pciback/pci_stub.c
> @@ -1502,6 +1502,45 @@ parse_error:
>  fs_initcall(pcistub_init);
>  #endif
>  
> +#ifdef CONFIG_PCI_IOV
> +static int pci_stub_notifier(struct notifier_block *nb,
> +			     unsigned long action, void *data)
> +{
> +	struct device *dev = data;
> +	const struct pci_dev *pdev = to_pci_dev(dev);
> +
> +	switch (action) {
> +	case BUS_NOTIFY_UNBIND_DRIVER:
> +		if (!pdev->is_physfn)
> +			break;
> +		for (;;) {
> +			struct pcistub_device *psdev;
> +			unsigned long flags;
> +			bool found = false;
> +
> +			spin_lock_irqsave(&pcistub_devices_lock, flags);
> +			list_for_each_entry(psdev, &pcistub_devices, dev_list)
> +				if (!psdev->pdev && psdev->dev != pdev
> +				    && pci_physfn(psdev->dev) == pdev) {
> +					found = true;
> +					break;
> +				}
> +			spin_unlock_irqrestore(&pcistub_devices_lock, flags);
> +			if (!found)
> +				break;
> +			device_release_driver(&psdev->dev->dev);
> +		}
> +		break;
> +	}
> +
> +	return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block pci_stub_nb = {
> +	.notifier_call = pci_stub_notifier,
> +};
> +#endif
> +
>  static int __init xen_pcibk_init(void)
>  {
>  	int err;
> @@ -1523,12 +1562,19 @@ static int __init xen_pcibk_init(void)
>  	err = xen_pcibk_xenbus_register();
>  	if (err)
>  		pcistub_exit();
> +#ifdef CONFIG_PCI_IOV
> +	else
> +		bus_register_notifier(&pci_bus_type, &pci_stub_nb);
> +#endif
>  
>  	return err;
>  }
>  
>  static void __exit xen_pcibk_cleanup(void)
>  {
> +#ifdef CONFIG_PCI_IOV
> +	bus_unregister_notifier(&pci_bus_type, &pci_stub_nb);
> +#endif
>  	xen_pcibk_xenbus_unregister();
>  	pcistub_exit();
>  }
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWi-0006rh-Fz; Fri, 21 Nov 2014 22:18:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWg-0006qx-Ss
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F2/12-25276-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416608280!6486204!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17983 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHv86004391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:58 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHud7005671
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:17:56 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHuCV019401; Fri, 21 Nov 2014 22:17:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1EE5F118C00; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:48 -0500
Message-Id: <1416608271-18931-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 4/7] xen/pciback: Print out the domain owning
	the 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>
MIME-Version: 1.0
Content-Type: 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 had been printing it only if the device was built with
debug enabled. But this information is useful in the field
to troubleshoot.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/xen/xen-pciback/xenbus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index eeee499..fe17c80 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -247,7 +247,7 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
 	if (err)
 		goto out;
 
-	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
+	dev_info(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
 	if (xen_register_device_domain_owner(dev,
 					     pdev->xdev->otherend_id) != 0) {
 		dev_err(&dev->dev, "Stealing ownership from dom%d.\n",
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWj-0006rv-6g; Fri, 21 Nov 2014 22:18:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWh-0006r5-7R
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:03 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	66/DA-02699-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416608280!14097881!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27485 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHvaY004392
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sALMHuUF020351
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALMHt4q020308; Fri, 21 Nov 2014 22:17:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 23F80118C01; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:49 -0500
Message-Id: <1416608271-18931-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 5/7] xen/pciback: Remove tons of dereferences
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 little cleanup. No functional difference.

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index e5ff09d..843a2ba 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -631,10 +631,12 @@ static pci_ers_result_t common_process(struct pcistub_device *psdev,
 {
 	pci_ers_result_t res = result;
 	struct xen_pcie_aer_op *aer_op;
+	struct xen_pcibk_device *pdev = psdev->pdev;
+	struct xen_pci_sharedinfo *sh_info = pdev->sh_info;
 	int ret;
 
 	/*with PV AER drivers*/
-	aer_op = &(psdev->pdev->sh_info->aer_op);
+	aer_op = &(sh_info->aer_op);
 	aer_op->cmd = aer_cmd ;
 	/*useful for error_detected callback*/
 	aer_op->err = state;
@@ -655,36 +657,36 @@ static pci_ers_result_t common_process(struct pcistub_device *psdev,
 	* this flag to judge whether we need to check pci-front give aer
 	* service ack signal
 	*/
-	set_bit(_PCIB_op_pending, (unsigned long *)&psdev->pdev->flags);
+	set_bit(_PCIB_op_pending, (unsigned long *)&pdev->flags);
 
 	/*It is possible that a pcifront conf_read_write ops request invokes
 	* the callback which cause the spurious execution of wake_up.
 	* Yet it is harmless and better than a spinlock here
 	*/
 	set_bit(_XEN_PCIB_active,
-		(unsigned long *)&psdev->pdev->sh_info->flags);
+		(unsigned long *)&sh_info->flags);
 	wmb();
-	notify_remote_via_irq(psdev->pdev->evtchn_irq);
+	notify_remote_via_irq(pdev->evtchn_irq);
 
 	ret = wait_event_timeout(xen_pcibk_aer_wait_queue,
 				 !(test_bit(_XEN_PCIB_active, (unsigned long *)
-				 &psdev->pdev->sh_info->flags)), 300*HZ);
+				 &sh_info->flags)), 300*HZ);
 
 	if (!ret) {
 		if (test_bit(_XEN_PCIB_active,
-			(unsigned long *)&psdev->pdev->sh_info->flags)) {
+			(unsigned long *)&sh_info->flags)) {
 			dev_err(&psdev->dev->dev,
 				"pcifront aer process not responding!\n");
 			clear_bit(_XEN_PCIB_active,
-			  (unsigned long *)&psdev->pdev->sh_info->flags);
+			  (unsigned long *)&sh_info->flags);
 			aer_op->err = PCI_ERS_RESULT_NONE;
 			return res;
 		}
 	}
-	clear_bit(_PCIB_op_pending, (unsigned long *)&psdev->pdev->flags);
+	clear_bit(_PCIB_op_pending, (unsigned long *)&pdev->flags);
 
 	if (test_bit(_XEN_PCIF_active,
-		(unsigned long *)&psdev->pdev->sh_info->flags)) {
+		(unsigned long *)&sh_info->flags)) {
 		dev_dbg(&psdev->dev->dev,
 			"schedule pci_conf service in " DRV_NAME "\n");
 		xen_pcibk_test_and_schedule_op(psdev->pdev);
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWi-0006rW-4h; Fri, 21 Nov 2014 22:18:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWg-0006qw-Ib
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:02 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	B7/3B-22777-91ABF645; Fri, 21 Nov 2014 22:18:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416608279!9870941!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18000 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 22:18:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHtm4019028
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:55 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sALMHsjU020265
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:17:55 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHr60005600; Fri, 21 Nov 2014 22:17:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4E068118BF5; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:44 -0500
Message-Id: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH v4] Fixes for PCI backend for 3.19
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hey,

The last time I posted these patches: https://lkml.org/lkml/2014/7/8/533
was so long ago that I don't even remember most comments. The only
one that stuck in mind was David's recommendation to add a new PCI API
call and use that. See patch #6 and #7.

The original posting (v3) had an extra patch that would do slot and
bus reset using do_flr SysFS attribute. I will revisit that once I am
done with this patchset.

I also seem to have had in my a bunch of 'SoB' from David - which
makes no sense - unless I pulled from his tree. Anyhow wherewere
I saw them I removed them.

Please take a look and comment. If I missed some comment from months
ago hopefully the new version has clarified them.


 drivers/pci/pci.c                     |  5 +--
 drivers/xen/xen-pciback/passthrough.c | 14 ++++++--
 drivers/xen/xen-pciback/pci_stub.c    | 60 ++++++++++++++++++++++-------------
 drivers/xen/xen-pciback/pciback.h     |  7 ++--
 drivers/xen/xen-pciback/vpci.c        | 14 ++++++--
 drivers/xen/xen-pciback/xenbus.c      |  4 +--
 include/linux/device.h                |  5 +++
 include/linux/pci.h                   |  2 ++
 8 files changed, 76 insertions(+), 35 deletions(-)

Konrad Rzeszutek Wilk (7):
      xen/pciback: Don't deadlock when unbinding.
      driver core: Provide an wrapper around the mutex to do lockdep warnings
      xen/pciback: Include the domain id if removing the device whilst still in use
      xen/pciback: Print out the domain owning the device.
      xen/pciback: Remove tons of dereferences
      PCI: Expose pci_load_saved_state for public consumption.
      xen/pciback: Restore configuration space when detaching from a guest.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWj-0006sJ-Th; Fri, 21 Nov 2014 22:18:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWh-0006qy-6o
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:03 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	CC/17-02576-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416608280!14097880!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27477 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:01 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHvp2004393
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHuw2023119
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHuQ1019423; Fri, 21 Nov 2014 22:17:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:56 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CC3F8118C03; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:51 -0500
Message-Id: <1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 7/7] xen/pciback: Restore configuration space
	when detaching from a 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>
MIME-Version: 1.0
Content-Type: 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 commit "xen/pciback: Don't deadlock when unbinding." was using
the version of pci_reset_function which would lock the device lock.
That is no good as we can dead-lock. As such we swapped to using
the lock-less version and requiring that the callers
of 'pcistub_put_pci_dev' take the device lock. And as such
this bug got exposed.

Using the lock-less version is  OK, except that we tried to
use 'pci_restore_state' after the lock-less version of
__pci_reset_function_locked - which won't work as 'state_saved'
is set to false. Said 'state_saved' is a toggle boolean that
is to be used by the sequence of a) pci_save_state/pci_restore_state
or b) pci_load_and_free_saved_state/pci_restore_state. We don't
want to use a) as the guest might have messed up the PCI
configuration space and we want it to revert to the state
when the PCI device was binded to us. Therefore we pick
b) to restore the configuration space.

We restore from our 'golden' version of PCI configuration space, when an:
 - Device is unbinded from pciback
 - Device is detached from a guest.

Reported-by:  Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 843a2ba..eb8b58e 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -105,7 +105,7 @@ static void pcistub_device_release(struct kref *kref)
 	 */
 	__pci_reset_function_locked(dev);
 	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
-		dev_dbg(&dev->dev, "Could not reload PCI state\n");
+		dev_info(&dev->dev, "Could not reload PCI state\n");
 	else
 		pci_restore_state(dev);
 
@@ -257,6 +257,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 {
 	struct pcistub_device *psdev, *found_psdev = NULL;
 	unsigned long flags;
+	struct xen_pcibk_dev_data *dev_data;
+	int ret;
 
 	spin_lock_irqsave(&pcistub_devices_lock, flags);
 
@@ -279,9 +281,19 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	 * (so it's ready for the next domain)
 	 */
 	device_lock_assert(&dev->dev);
-	__pci_reset_function_locked(dev);
-	pci_restore_state(dev);
-
+	dev_data = pci_get_drvdata(dev);
+	ret = pci_load_saved_state(dev, dev_data->pci_saved_state);
+	if (ret < 0)
+		dev_warn(&dev->dev, "Could not reload PCI state\n");
+	else {
+		__pci_reset_function_locked(dev);
+		/*
+		 * The usual sequence is pci_save_state & pci_restore_state
+		 * but the guest might have messed the configuration space up.
+		 * Use the initial version (when device was bound to us).
+		 */
+		pci_restore_state(dev);
+	}
 	/* This disables the device. */
 	xen_pcibk_reset_device(dev);
 
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWj-0006sA-Hq; Fri, 21 Nov 2014 22:18:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWh-0006r0-6q
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:03 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B9/99-02957-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416608280!14108522!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22143 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:01 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHvUc004390
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHuW9019406
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:17:56 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHu9q023100; Fri, 21 Nov 2014 22:17:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7E41B118C02; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:50 -0500
Message-Id: <1416608271-18931-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 6/7] PCI: Expose pci_load_saved_state for
	public consumption.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 have the pci_load_and_free_saved_state, and pci_store_saved_state
but are missing the functionality to just load the state
multiple times in the PCI device without having to free/save
the state.

This patch makes it possible to use this function.

CC: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/pci/pci.c   | 5 +++--
 include/linux/pci.h | 2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 625a4ac..f00a9d6 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1142,8 +1142,8 @@ EXPORT_SYMBOL_GPL(pci_store_saved_state);
  * @dev: PCI device that we're dealing with
  * @state: Saved state returned from pci_store_saved_state()
  */
-static int pci_load_saved_state(struct pci_dev *dev,
-				struct pci_saved_state *state)
+int pci_load_saved_state(struct pci_dev *dev,
+			 struct pci_saved_state *state)
 {
 	struct pci_cap_saved_data *cap;
 
@@ -1171,6 +1171,7 @@ static int pci_load_saved_state(struct pci_dev *dev,
 	dev->state_saved = true;
 	return 0;
 }
+EXPORT_SYMBOL_GPL(pci_load_saved_state);
 
 /**
  * pci_load_and_free_saved_state - Reload the save state pointed to by state,
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 5be8db4..08088cb1 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1003,6 +1003,8 @@ void __iomem __must_check *pci_platform_rom(struct pci_dev *pdev, size_t *size);
 int pci_save_state(struct pci_dev *dev);
 void pci_restore_state(struct pci_dev *dev);
 struct pci_saved_state *pci_store_saved_state(struct pci_dev *dev);
+int pci_load_saved_state(struct pci_dev *dev,
+			 struct pci_saved_state *state);
 int pci_load_and_free_saved_state(struct pci_dev *dev,
 				  struct pci_saved_state **state);
 struct pci_cap_saved_state *pci_find_saved_cap(struct pci_dev *dev, char cap);
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWk-0006sS-8c; Fri, 21 Nov 2014 22:18:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWh-0006rA-JX
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	93/12-25276-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416608281!14495268!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18045 invoked from network); 21 Nov 2014 22:18:02 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHvGv019042
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:58 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHt9R019360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:17:56 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHtJP023068; Fri, 21 Nov 2014 22:17:55 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6B72E118BF7; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:45 -0500
Message-Id: <1416608271-18931-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 1/7] xen/pciback: Don't deadlock when
	unbinding.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As commit 0a9fd0152929db372ff61b0d6c280fdd34ae8bdb
'xen/pciback: Document the entry points for 'pcistub_put_pci_dev''
explained there are four entry points in this function.
Two of them are when the user fiddles in the SysFS to
unbind a device which might be in use by a guest or not.

Both 'unbind' states will cause a deadlock as the the PCI lock has
already been taken, which then pci_device_reset tries to take.

We can simplify this by requiring that all callers of
pcistub_put_pci_dev MUST hold the device lock. And then
we can just call the lockless version of pci_device_reset.

To make it even simpler we will modify xen_pcibk_release_pci_dev
to quality whether it should take a lock or not - as it ends
up calling xen_pcibk_release_pci_dev and needs to hold the lock.

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/passthrough.c | 14 +++++++++++---
 drivers/xen/xen-pciback/pci_stub.c    | 12 ++++++------
 drivers/xen/xen-pciback/pciback.h     |  7 ++++---
 drivers/xen/xen-pciback/vpci.c        | 14 +++++++++++---
 drivers/xen/xen-pciback/xenbus.c      |  2 +-
 5 files changed, 33 insertions(+), 16 deletions(-)

diff --git a/drivers/xen/xen-pciback/passthrough.c b/drivers/xen/xen-pciback/passthrough.c
index 828dddc..f16a30e 100644
--- a/drivers/xen/xen-pciback/passthrough.c
+++ b/drivers/xen/xen-pciback/passthrough.c
@@ -69,7 +69,7 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 }
 
 static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					struct pci_dev *dev)
+					struct pci_dev *dev, bool lock)
 {
 	struct passthrough_dev_data *dev_data = pdev->pci_dev_data;
 	struct pci_dev_entry *dev_entry, *t;
@@ -87,8 +87,13 @@ static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
 
 	mutex_unlock(&dev_data->lock);
 
-	if (found_dev)
+	if (found_dev) {
+		if (lock)
+			device_lock(&found_dev->dev);
 		pcistub_put_pci_dev(found_dev);
+		if (lock)
+			device_unlock(&found_dev->dev);
+	}
 }
 
 static int __xen_pcibk_init_devices(struct xen_pcibk_device *pdev)
@@ -156,8 +161,11 @@ static void __xen_pcibk_release_devices(struct xen_pcibk_device *pdev)
 	struct pci_dev_entry *dev_entry, *t;
 
 	list_for_each_entry_safe(dev_entry, t, &dev_data->dev_list, list) {
+		struct pci_dev *dev = dev_entry->dev;
 		list_del(&dev_entry->list);
-		pcistub_put_pci_dev(dev_entry->dev);
+		device_lock(&dev->dev);
+		pcistub_put_pci_dev(dev);
+		device_unlock(&dev->dev);
 		kfree(dev_entry);
 	}
 
diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 017069a..9cbe1a3 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -250,6 +250,8 @@ struct pci_dev *pcistub_get_pci_dev(struct xen_pcibk_device *pdev,
  *  - 'echo BDF > unbind' with a guest still using it. See pcistub_remove
  *
  *  As such we have to be careful.
+ *
+ *  To make this easier, the caller has to hold the device lock.
  */
 void pcistub_put_pci_dev(struct pci_dev *dev)
 {
@@ -276,11 +278,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* Cleanup our device
 	 * (so it's ready for the next domain)
 	 */
-
-	/* This is OK - we are running from workqueue context
-	 * and want to inhibit the user from fiddling with 'reset'
-	 */
-	pci_reset_function(dev);
+	lockdep_assert_held(&dev->dev.mutex);
+	__pci_reset_function_locked(dev);
 	pci_restore_state(dev);
 
 	/* This disables the device. */
@@ -567,7 +566,8 @@ static void pcistub_remove(struct pci_dev *dev)
 			/* N.B. This ends up calling pcistub_put_pci_dev which ends up
 			 * doing the FLR. */
 			xen_pcibk_release_pci_dev(found_psdev->pdev,
-						found_psdev->dev);
+						found_psdev->dev,
+						false /* caller holds the lock. */);
 		}
 
 		spin_lock_irqsave(&pcistub_devices_lock, flags);
diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
index f72af87..58e38d5 100644
--- a/drivers/xen/xen-pciback/pciback.h
+++ b/drivers/xen/xen-pciback/pciback.h
@@ -99,7 +99,8 @@ struct xen_pcibk_backend {
 		    unsigned int *domain, unsigned int *bus,
 		    unsigned int *devfn);
 	int (*publish)(struct xen_pcibk_device *pdev, publish_pci_root_cb cb);
-	void (*release)(struct xen_pcibk_device *pdev, struct pci_dev *dev);
+	void (*release)(struct xen_pcibk_device *pdev, struct pci_dev *dev,
+                        bool lock);
 	int (*add)(struct xen_pcibk_device *pdev, struct pci_dev *dev,
 		   int devid, publish_pci_dev_cb publish_cb);
 	struct pci_dev *(*get)(struct xen_pcibk_device *pdev,
@@ -122,10 +123,10 @@ static inline int xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 }
 
 static inline void xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					     struct pci_dev *dev)
+					     struct pci_dev *dev, bool lock)
 {
 	if (xen_pcibk_backend && xen_pcibk_backend->release)
-		return xen_pcibk_backend->release(pdev, dev);
+		return xen_pcibk_backend->release(pdev, dev, lock);
 }
 
 static inline struct pci_dev *
diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
index 51afff9..c99f8bb 100644
--- a/drivers/xen/xen-pciback/vpci.c
+++ b/drivers/xen/xen-pciback/vpci.c
@@ -145,7 +145,7 @@ out:
 }
 
 static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					struct pci_dev *dev)
+					struct pci_dev *dev, bool lock)
 {
 	int slot;
 	struct vpci_dev_data *vpci_dev = pdev->pci_dev_data;
@@ -169,8 +169,13 @@ static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
 out:
 	mutex_unlock(&vpci_dev->lock);
 
-	if (found_dev)
+	if (found_dev) {
+		if (lock)
+			device_lock(&found_dev->dev);
 		pcistub_put_pci_dev(found_dev);
+		if (lock)
+			device_unlock(&found_dev->dev);
+	}
 }
 
 static int __xen_pcibk_init_devices(struct xen_pcibk_device *pdev)
@@ -208,8 +213,11 @@ static void __xen_pcibk_release_devices(struct xen_pcibk_device *pdev)
 		struct pci_dev_entry *e, *tmp;
 		list_for_each_entry_safe(e, tmp, &vpci_dev->dev_list[slot],
 					 list) {
+			struct pci_dev *dev = e->dev;
 			list_del(&e->list);
-			pcistub_put_pci_dev(e->dev);
+			device_lock(&dev->dev);
+			pcistub_put_pci_dev(dev);
+			device_unlock(&dev->dev);
 			kfree(e);
 		}
 	}
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index ad8d30c..eeee499 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -291,7 +291,7 @@ static int xen_pcibk_remove_device(struct xen_pcibk_device *pdev,
 
 	/* N.B. This ends up calling pcistub_put_pci_dev which ends up
 	 * doing the FLR. */
-	xen_pcibk_release_pci_dev(pdev, dev);
+	xen_pcibk_release_pci_dev(pdev, dev, true /* use the lock. */);
 
 out:
 	return err;
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWi-0006ro-Qj; Fri, 21 Nov 2014 22:18:04 +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 1XrwWh-0006qz-7A
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:03 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	78/57-02696-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416608280!14089362!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3806 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHu0S004384
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHutM005673
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 22:17:56 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALMHtad020292; Fri, 21 Nov 2014 22:17:55 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7F8A9118BF9; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:46 -0500
Message-Id: <1416608271-18931-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 2/7] driver core: Provide an wrapper around
	the mutex to do lockdep 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of open-coding it in drivers that want to double check
that their functions are indeed holding the device lock.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/xen/xen-pciback/pci_stub.c | 2 +-
 include/linux/device.h             | 5 +++++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 9cbe1a3..8b77089 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -278,7 +278,7 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* Cleanup our device
 	 * (so it's ready for the next domain)
 	 */
-	lockdep_assert_held(&dev->dev.mutex);
+	device_lock_assert(&dev->dev);
 	__pci_reset_function_locked(dev);
 	pci_restore_state(dev);
 
diff --git a/include/linux/device.h b/include/linux/device.h
index ce1f2160..41d6a75 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -911,6 +911,11 @@ static inline void device_unlock(struct device *dev)
 	mutex_unlock(&dev->mutex);
 }
 
+static inline void device_lock_assert(struct device *dev)
+{
+	lockdep_assert_held(&dev->mutex);
+}
+
 void driver_init(void);
 
 /*
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWi-0006rh-Fz; Fri, 21 Nov 2014 22:18:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWg-0006qx-Ss
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F2/12-25276-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416608280!6486204!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17983 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHv86004391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:58 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHud7005671
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:17:56 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHuCV019401; Fri, 21 Nov 2014 22:17:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1EE5F118C00; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:48 -0500
Message-Id: <1416608271-18931-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 4/7] xen/pciback: Print out the domain owning
	the 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>
MIME-Version: 1.0
Content-Type: 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 had been printing it only if the device was built with
debug enabled. But this information is useful in the field
to troubleshoot.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/xen/xen-pciback/xenbus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index eeee499..fe17c80 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -247,7 +247,7 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
 	if (err)
 		goto out;
 
-	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
+	dev_info(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
 	if (xen_register_device_domain_owner(dev,
 					     pdev->xdev->otherend_id) != 0) {
 		dev_err(&dev->dev, "Stealing ownership from dom%d.\n",
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWk-0006t5-QK; Fri, 21 Nov 2014 22:18:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWi-0006rR-4H
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A5/EB-15461-B1ABF645; Fri, 21 Nov 2014 22:18:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416608281!14492565!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20871 invoked from network); 21 Nov 2014 22:18:02 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHvG3019041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:58 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHuP6019408
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 22:17:56 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALMHt7m020290; Fri, 21 Nov 2014 22:17:55 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 98975118BFB; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:47 -0500
Message-Id: <1416608271-18931-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 3/7] xen/pciback: Include the domain id if
	removing the device whilst still in use
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cleanup the function a bit - also include the id of the
domain that is using the device.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 8b77089..e5ff09d 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -553,12 +553,14 @@ static void pcistub_remove(struct pci_dev *dev)
 	spin_unlock_irqrestore(&pcistub_devices_lock, flags);
 
 	if (found_psdev) {
-		dev_dbg(&dev->dev, "found device to remove - in use? %p\n",
-			found_psdev->pdev);
+		dev_dbg(&dev->dev, "found device to remove %s\n",
+			found_psdev->pdev ? "- in-use" : "");
 
 		if (found_psdev->pdev) {
-			pr_warn("****** removing device %s while still in-use! ******\n",
-			       pci_name(found_psdev->dev));
+			int domid = xen_find_device_domain_owner(dev);
+
+			pr_warn("****** removing device %s while still in-use by domain %d! ******\n",
+			       pci_name(found_psdev->dev), domid);
 			pr_warn("****** driver domain may still access this device's i/o resources!\n");
 			pr_warn("****** shutdown driver domain before binding device\n");
 			pr_warn("****** to other drivers or domains\n");
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWi-0006rW-4h; Fri, 21 Nov 2014 22:18:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWg-0006qw-Ib
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:02 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	B7/3B-22777-91ABF645; Fri, 21 Nov 2014 22:18:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416608279!9870941!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18000 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 22:18:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHtm4019028
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:55 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sALMHsjU020265
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:17:55 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHr60005600; Fri, 21 Nov 2014 22:17:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4E068118BF5; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:44 -0500
Message-Id: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH v4] Fixes for PCI backend for 3.19
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hey,

The last time I posted these patches: https://lkml.org/lkml/2014/7/8/533
was so long ago that I don't even remember most comments. The only
one that stuck in mind was David's recommendation to add a new PCI API
call and use that. See patch #6 and #7.

The original posting (v3) had an extra patch that would do slot and
bus reset using do_flr SysFS attribute. I will revisit that once I am
done with this patchset.

I also seem to have had in my a bunch of 'SoB' from David - which
makes no sense - unless I pulled from his tree. Anyhow wherewere
I saw them I removed them.

Please take a look and comment. If I missed some comment from months
ago hopefully the new version has clarified them.


 drivers/pci/pci.c                     |  5 +--
 drivers/xen/xen-pciback/passthrough.c | 14 ++++++--
 drivers/xen/xen-pciback/pci_stub.c    | 60 ++++++++++++++++++++++-------------
 drivers/xen/xen-pciback/pciback.h     |  7 ++--
 drivers/xen/xen-pciback/vpci.c        | 14 ++++++--
 drivers/xen/xen-pciback/xenbus.c      |  4 +--
 include/linux/device.h                |  5 +++
 include/linux/pci.h                   |  2 ++
 8 files changed, 76 insertions(+), 35 deletions(-)

Konrad Rzeszutek Wilk (7):
      xen/pciback: Don't deadlock when unbinding.
      driver core: Provide an wrapper around the mutex to do lockdep warnings
      xen/pciback: Include the domain id if removing the device whilst still in use
      xen/pciback: Print out the domain owning the device.
      xen/pciback: Remove tons of dereferences
      PCI: Expose pci_load_saved_state for public consumption.
      xen/pciback: Restore configuration space when detaching from a guest.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWi-0006ro-Qj; Fri, 21 Nov 2014 22:18:04 +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 1XrwWh-0006qz-7A
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:03 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	78/57-02696-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416608280!14089362!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3806 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHu0S004384
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHutM005673
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 22:17:56 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALMHtad020292; Fri, 21 Nov 2014 22:17:55 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7F8A9118BF9; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:46 -0500
Message-Id: <1416608271-18931-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 2/7] driver core: Provide an wrapper around
	the mutex to do lockdep 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of open-coding it in drivers that want to double check
that their functions are indeed holding the device lock.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/xen/xen-pciback/pci_stub.c | 2 +-
 include/linux/device.h             | 5 +++++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 9cbe1a3..8b77089 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -278,7 +278,7 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* Cleanup our device
 	 * (so it's ready for the next domain)
 	 */
-	lockdep_assert_held(&dev->dev.mutex);
+	device_lock_assert(&dev->dev);
 	__pci_reset_function_locked(dev);
 	pci_restore_state(dev);
 
diff --git a/include/linux/device.h b/include/linux/device.h
index ce1f2160..41d6a75 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -911,6 +911,11 @@ static inline void device_unlock(struct device *dev)
 	mutex_unlock(&dev->mutex);
 }
 
+static inline void device_lock_assert(struct device *dev)
+{
+	lockdep_assert_held(&dev->mutex);
+}
+
 void driver_init(void);
 
 /*
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWj-0006sA-Hq; Fri, 21 Nov 2014 22:18:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWh-0006r0-6q
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:03 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B9/99-02957-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416608280!14108522!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22143 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:01 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHvUc004390
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHuW9019406
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:17:56 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHu9q023100; Fri, 21 Nov 2014 22:17:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7E41B118C02; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:50 -0500
Message-Id: <1416608271-18931-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 6/7] PCI: Expose pci_load_saved_state for
	public consumption.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 have the pci_load_and_free_saved_state, and pci_store_saved_state
but are missing the functionality to just load the state
multiple times in the PCI device without having to free/save
the state.

This patch makes it possible to use this function.

CC: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/pci/pci.c   | 5 +++--
 include/linux/pci.h | 2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 625a4ac..f00a9d6 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1142,8 +1142,8 @@ EXPORT_SYMBOL_GPL(pci_store_saved_state);
  * @dev: PCI device that we're dealing with
  * @state: Saved state returned from pci_store_saved_state()
  */
-static int pci_load_saved_state(struct pci_dev *dev,
-				struct pci_saved_state *state)
+int pci_load_saved_state(struct pci_dev *dev,
+			 struct pci_saved_state *state)
 {
 	struct pci_cap_saved_data *cap;
 
@@ -1171,6 +1171,7 @@ static int pci_load_saved_state(struct pci_dev *dev,
 	dev->state_saved = true;
 	return 0;
 }
+EXPORT_SYMBOL_GPL(pci_load_saved_state);
 
 /**
  * pci_load_and_free_saved_state - Reload the save state pointed to by state,
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 5be8db4..08088cb1 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1003,6 +1003,8 @@ void __iomem __must_check *pci_platform_rom(struct pci_dev *pdev, size_t *size);
 int pci_save_state(struct pci_dev *dev);
 void pci_restore_state(struct pci_dev *dev);
 struct pci_saved_state *pci_store_saved_state(struct pci_dev *dev);
+int pci_load_saved_state(struct pci_dev *dev,
+			 struct pci_saved_state *state);
 int pci_load_and_free_saved_state(struct pci_dev *dev,
 				  struct pci_saved_state **state);
 struct pci_cap_saved_state *pci_find_saved_cap(struct pci_dev *dev, char cap);
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWj-0006rv-6g; Fri, 21 Nov 2014 22:18:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWh-0006r5-7R
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:03 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	66/DA-02699-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416608280!14097881!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27485 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHvaY004392
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sALMHuUF020351
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALMHt4q020308; Fri, 21 Nov 2014 22:17:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 23F80118C01; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:49 -0500
Message-Id: <1416608271-18931-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 5/7] xen/pciback: Remove tons of dereferences
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 little cleanup. No functional difference.

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index e5ff09d..843a2ba 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -631,10 +631,12 @@ static pci_ers_result_t common_process(struct pcistub_device *psdev,
 {
 	pci_ers_result_t res = result;
 	struct xen_pcie_aer_op *aer_op;
+	struct xen_pcibk_device *pdev = psdev->pdev;
+	struct xen_pci_sharedinfo *sh_info = pdev->sh_info;
 	int ret;
 
 	/*with PV AER drivers*/
-	aer_op = &(psdev->pdev->sh_info->aer_op);
+	aer_op = &(sh_info->aer_op);
 	aer_op->cmd = aer_cmd ;
 	/*useful for error_detected callback*/
 	aer_op->err = state;
@@ -655,36 +657,36 @@ static pci_ers_result_t common_process(struct pcistub_device *psdev,
 	* this flag to judge whether we need to check pci-front give aer
 	* service ack signal
 	*/
-	set_bit(_PCIB_op_pending, (unsigned long *)&psdev->pdev->flags);
+	set_bit(_PCIB_op_pending, (unsigned long *)&pdev->flags);
 
 	/*It is possible that a pcifront conf_read_write ops request invokes
 	* the callback which cause the spurious execution of wake_up.
 	* Yet it is harmless and better than a spinlock here
 	*/
 	set_bit(_XEN_PCIB_active,
-		(unsigned long *)&psdev->pdev->sh_info->flags);
+		(unsigned long *)&sh_info->flags);
 	wmb();
-	notify_remote_via_irq(psdev->pdev->evtchn_irq);
+	notify_remote_via_irq(pdev->evtchn_irq);
 
 	ret = wait_event_timeout(xen_pcibk_aer_wait_queue,
 				 !(test_bit(_XEN_PCIB_active, (unsigned long *)
-				 &psdev->pdev->sh_info->flags)), 300*HZ);
+				 &sh_info->flags)), 300*HZ);
 
 	if (!ret) {
 		if (test_bit(_XEN_PCIB_active,
-			(unsigned long *)&psdev->pdev->sh_info->flags)) {
+			(unsigned long *)&sh_info->flags)) {
 			dev_err(&psdev->dev->dev,
 				"pcifront aer process not responding!\n");
 			clear_bit(_XEN_PCIB_active,
-			  (unsigned long *)&psdev->pdev->sh_info->flags);
+			  (unsigned long *)&sh_info->flags);
 			aer_op->err = PCI_ERS_RESULT_NONE;
 			return res;
 		}
 	}
-	clear_bit(_PCIB_op_pending, (unsigned long *)&psdev->pdev->flags);
+	clear_bit(_PCIB_op_pending, (unsigned long *)&pdev->flags);
 
 	if (test_bit(_XEN_PCIF_active,
-		(unsigned long *)&psdev->pdev->sh_info->flags)) {
+		(unsigned long *)&sh_info->flags)) {
 		dev_dbg(&psdev->dev->dev,
 			"schedule pci_conf service in " DRV_NAME "\n");
 		xen_pcibk_test_and_schedule_op(psdev->pdev);
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWk-0006sS-8c; Fri, 21 Nov 2014 22:18:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWh-0006rA-JX
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	93/12-25276-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416608281!14495268!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18045 invoked from network); 21 Nov 2014 22:18:02 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHvGv019042
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:58 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHt9R019360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:17:56 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHtJP023068; Fri, 21 Nov 2014 22:17:55 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6B72E118BF7; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:45 -0500
Message-Id: <1416608271-18931-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 1/7] xen/pciback: Don't deadlock when
	unbinding.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As commit 0a9fd0152929db372ff61b0d6c280fdd34ae8bdb
'xen/pciback: Document the entry points for 'pcistub_put_pci_dev''
explained there are four entry points in this function.
Two of them are when the user fiddles in the SysFS to
unbind a device which might be in use by a guest or not.

Both 'unbind' states will cause a deadlock as the the PCI lock has
already been taken, which then pci_device_reset tries to take.

We can simplify this by requiring that all callers of
pcistub_put_pci_dev MUST hold the device lock. And then
we can just call the lockless version of pci_device_reset.

To make it even simpler we will modify xen_pcibk_release_pci_dev
to quality whether it should take a lock or not - as it ends
up calling xen_pcibk_release_pci_dev and needs to hold the lock.

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/passthrough.c | 14 +++++++++++---
 drivers/xen/xen-pciback/pci_stub.c    | 12 ++++++------
 drivers/xen/xen-pciback/pciback.h     |  7 ++++---
 drivers/xen/xen-pciback/vpci.c        | 14 +++++++++++---
 drivers/xen/xen-pciback/xenbus.c      |  2 +-
 5 files changed, 33 insertions(+), 16 deletions(-)

diff --git a/drivers/xen/xen-pciback/passthrough.c b/drivers/xen/xen-pciback/passthrough.c
index 828dddc..f16a30e 100644
--- a/drivers/xen/xen-pciback/passthrough.c
+++ b/drivers/xen/xen-pciback/passthrough.c
@@ -69,7 +69,7 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 }
 
 static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					struct pci_dev *dev)
+					struct pci_dev *dev, bool lock)
 {
 	struct passthrough_dev_data *dev_data = pdev->pci_dev_data;
 	struct pci_dev_entry *dev_entry, *t;
@@ -87,8 +87,13 @@ static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
 
 	mutex_unlock(&dev_data->lock);
 
-	if (found_dev)
+	if (found_dev) {
+		if (lock)
+			device_lock(&found_dev->dev);
 		pcistub_put_pci_dev(found_dev);
+		if (lock)
+			device_unlock(&found_dev->dev);
+	}
 }
 
 static int __xen_pcibk_init_devices(struct xen_pcibk_device *pdev)
@@ -156,8 +161,11 @@ static void __xen_pcibk_release_devices(struct xen_pcibk_device *pdev)
 	struct pci_dev_entry *dev_entry, *t;
 
 	list_for_each_entry_safe(dev_entry, t, &dev_data->dev_list, list) {
+		struct pci_dev *dev = dev_entry->dev;
 		list_del(&dev_entry->list);
-		pcistub_put_pci_dev(dev_entry->dev);
+		device_lock(&dev->dev);
+		pcistub_put_pci_dev(dev);
+		device_unlock(&dev->dev);
 		kfree(dev_entry);
 	}
 
diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 017069a..9cbe1a3 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -250,6 +250,8 @@ struct pci_dev *pcistub_get_pci_dev(struct xen_pcibk_device *pdev,
  *  - 'echo BDF > unbind' with a guest still using it. See pcistub_remove
  *
  *  As such we have to be careful.
+ *
+ *  To make this easier, the caller has to hold the device lock.
  */
 void pcistub_put_pci_dev(struct pci_dev *dev)
 {
@@ -276,11 +278,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* Cleanup our device
 	 * (so it's ready for the next domain)
 	 */
-
-	/* This is OK - we are running from workqueue context
-	 * and want to inhibit the user from fiddling with 'reset'
-	 */
-	pci_reset_function(dev);
+	lockdep_assert_held(&dev->dev.mutex);
+	__pci_reset_function_locked(dev);
 	pci_restore_state(dev);
 
 	/* This disables the device. */
@@ -567,7 +566,8 @@ static void pcistub_remove(struct pci_dev *dev)
 			/* N.B. This ends up calling pcistub_put_pci_dev which ends up
 			 * doing the FLR. */
 			xen_pcibk_release_pci_dev(found_psdev->pdev,
-						found_psdev->dev);
+						found_psdev->dev,
+						false /* caller holds the lock. */);
 		}
 
 		spin_lock_irqsave(&pcistub_devices_lock, flags);
diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
index f72af87..58e38d5 100644
--- a/drivers/xen/xen-pciback/pciback.h
+++ b/drivers/xen/xen-pciback/pciback.h
@@ -99,7 +99,8 @@ struct xen_pcibk_backend {
 		    unsigned int *domain, unsigned int *bus,
 		    unsigned int *devfn);
 	int (*publish)(struct xen_pcibk_device *pdev, publish_pci_root_cb cb);
-	void (*release)(struct xen_pcibk_device *pdev, struct pci_dev *dev);
+	void (*release)(struct xen_pcibk_device *pdev, struct pci_dev *dev,
+                        bool lock);
 	int (*add)(struct xen_pcibk_device *pdev, struct pci_dev *dev,
 		   int devid, publish_pci_dev_cb publish_cb);
 	struct pci_dev *(*get)(struct xen_pcibk_device *pdev,
@@ -122,10 +123,10 @@ static inline int xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 }
 
 static inline void xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					     struct pci_dev *dev)
+					     struct pci_dev *dev, bool lock)
 {
 	if (xen_pcibk_backend && xen_pcibk_backend->release)
-		return xen_pcibk_backend->release(pdev, dev);
+		return xen_pcibk_backend->release(pdev, dev, lock);
 }
 
 static inline struct pci_dev *
diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
index 51afff9..c99f8bb 100644
--- a/drivers/xen/xen-pciback/vpci.c
+++ b/drivers/xen/xen-pciback/vpci.c
@@ -145,7 +145,7 @@ out:
 }
 
 static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
-					struct pci_dev *dev)
+					struct pci_dev *dev, bool lock)
 {
 	int slot;
 	struct vpci_dev_data *vpci_dev = pdev->pci_dev_data;
@@ -169,8 +169,13 @@ static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev,
 out:
 	mutex_unlock(&vpci_dev->lock);
 
-	if (found_dev)
+	if (found_dev) {
+		if (lock)
+			device_lock(&found_dev->dev);
 		pcistub_put_pci_dev(found_dev);
+		if (lock)
+			device_unlock(&found_dev->dev);
+	}
 }
 
 static int __xen_pcibk_init_devices(struct xen_pcibk_device *pdev)
@@ -208,8 +213,11 @@ static void __xen_pcibk_release_devices(struct xen_pcibk_device *pdev)
 		struct pci_dev_entry *e, *tmp;
 		list_for_each_entry_safe(e, tmp, &vpci_dev->dev_list[slot],
 					 list) {
+			struct pci_dev *dev = e->dev;
 			list_del(&e->list);
-			pcistub_put_pci_dev(e->dev);
+			device_lock(&dev->dev);
+			pcistub_put_pci_dev(dev);
+			device_unlock(&dev->dev);
 			kfree(e);
 		}
 	}
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index ad8d30c..eeee499 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -291,7 +291,7 @@ static int xen_pcibk_remove_device(struct xen_pcibk_device *pdev,
 
 	/* N.B. This ends up calling pcistub_put_pci_dev which ends up
 	 * doing the FLR. */
-	xen_pcibk_release_pci_dev(pdev, dev);
+	xen_pcibk_release_pci_dev(pdev, dev, true /* use the lock. */);
 
 out:
 	return err;
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWk-0006t5-QK; Fri, 21 Nov 2014 22:18:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWi-0006rR-4H
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A5/EB-15461-B1ABF645; Fri, 21 Nov 2014 22:18:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416608281!14492565!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20871 invoked from network); 21 Nov 2014 22:18:02 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHvG3019041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:58 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHuP6019408
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Nov 2014 22:17:56 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sALMHt7m020290; Fri, 21 Nov 2014 22:17:55 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 98975118BFB; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:47 -0500
Message-Id: <1416608271-18931-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 3/7] xen/pciback: Include the domain id if
	removing the device whilst still in use
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cleanup the function a bit - also include the id of the
domain that is using the device.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 8b77089..e5ff09d 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -553,12 +553,14 @@ static void pcistub_remove(struct pci_dev *dev)
 	spin_unlock_irqrestore(&pcistub_devices_lock, flags);
 
 	if (found_psdev) {
-		dev_dbg(&dev->dev, "found device to remove - in use? %p\n",
-			found_psdev->pdev);
+		dev_dbg(&dev->dev, "found device to remove %s\n",
+			found_psdev->pdev ? "- in-use" : "");
 
 		if (found_psdev->pdev) {
-			pr_warn("****** removing device %s while still in-use! ******\n",
-			       pci_name(found_psdev->dev));
+			int domid = xen_find_device_domain_owner(dev);
+
+			pr_warn("****** removing device %s while still in-use by domain %d! ******\n",
+			       pci_name(found_psdev->dev), domid);
 			pr_warn("****** driver domain may still access this device's i/o resources!\n");
 			pr_warn("****** shutdown driver domain before binding device\n");
 			pr_warn("****** to other drivers or domains\n");
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:18:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrwWj-0006sJ-Th; Fri, 21 Nov 2014 22:18:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XrwWh-0006qy-6o
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:18:03 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	CC/17-02576-A1ABF645; Fri, 21 Nov 2014 22:18:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416608280!14097880!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27477 invoked from network); 21 Nov 2014 22:18:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:18:01 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMHvp2004393
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHuw2023119
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:17:57 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMHuQ1019423; Fri, 21 Nov 2014 22:17:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:17:56 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CC3F8118C03; Fri, 21 Nov 2014 17:17:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
Date: Fri, 21 Nov 2014 17:17:51 -0500
Message-Id: <1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v4 7/7] xen/pciback: Restore configuration space
	when detaching from a 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>
MIME-Version: 1.0
Content-Type: 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 commit "xen/pciback: Don't deadlock when unbinding." was using
the version of pci_reset_function which would lock the device lock.
That is no good as we can dead-lock. As such we swapped to using
the lock-less version and requiring that the callers
of 'pcistub_put_pci_dev' take the device lock. And as such
this bug got exposed.

Using the lock-less version is  OK, except that we tried to
use 'pci_restore_state' after the lock-less version of
__pci_reset_function_locked - which won't work as 'state_saved'
is set to false. Said 'state_saved' is a toggle boolean that
is to be used by the sequence of a) pci_save_state/pci_restore_state
or b) pci_load_and_free_saved_state/pci_restore_state. We don't
want to use a) as the guest might have messed up the PCI
configuration space and we want it to revert to the state
when the PCI device was binded to us. Therefore we pick
b) to restore the configuration space.

We restore from our 'golden' version of PCI configuration space, when an:
 - Device is unbinded from pciback
 - Device is detached from a guest.

Reported-by:  Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 843a2ba..eb8b58e 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -105,7 +105,7 @@ static void pcistub_device_release(struct kref *kref)
 	 */
 	__pci_reset_function_locked(dev);
 	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
-		dev_dbg(&dev->dev, "Could not reload PCI state\n");
+		dev_info(&dev->dev, "Could not reload PCI state\n");
 	else
 		pci_restore_state(dev);
 
@@ -257,6 +257,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 {
 	struct pcistub_device *psdev, *found_psdev = NULL;
 	unsigned long flags;
+	struct xen_pcibk_dev_data *dev_data;
+	int ret;
 
 	spin_lock_irqsave(&pcistub_devices_lock, flags);
 
@@ -279,9 +281,19 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	 * (so it's ready for the next domain)
 	 */
 	device_lock_assert(&dev->dev);
-	__pci_reset_function_locked(dev);
-	pci_restore_state(dev);
-
+	dev_data = pci_get_drvdata(dev);
+	ret = pci_load_saved_state(dev, dev_data->pci_saved_state);
+	if (ret < 0)
+		dev_warn(&dev->dev, "Could not reload PCI state\n");
+	else {
+		__pci_reset_function_locked(dev);
+		/*
+		 * The usual sequence is pci_save_state & pci_restore_state
+		 * but the guest might have messed the configuration space up.
+		 * Use the initial version (when device was bound to us).
+		 */
+		pci_restore_state(dev);
+	}
 	/* This disables the device. */
 	xen_pcibk_reset_device(dev);
 
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:35:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrwn5-00084A-HO; Fri, 21 Nov 2014 22:34:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrwn4-000845-Vj
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:34:59 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	ED/22-09284-21EBF645; Fri, 21 Nov 2014 22:34:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416609295!13104336!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29261 invoked from network); 21 Nov 2014 22:34:57 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:34:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMXDvk019872
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:33:14 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMXBXI010037
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:33:12 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMXBDC028590; Fri, 21 Nov 2014 22:33:11 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:33:11 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BBCA7118C9E; Fri, 21 Nov 2014 17:33:09 -0500 (EST)
Date: Fri, 21 Nov 2014 17:33:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20141121223309.GC19283@laptop.dumpdata.com>
References: <CALCETrUh_6tWdTyDwZ4U1BDSnN1khbGDGBvCTO3MVcdU-X23QA@mail.gmail.com>
	<20141121162742.GB15461@htj.dyndns.org>
	<CALCETrUcuDh8c27cEHmoM7jo_kozJbYxV3p1H2LhmzBa16XOyQ@mail.gmail.com>
	<CA+55aFxU2q_-PVx+6fXGkXdAt3oaxvqxzy29Nrn989uTiVXvCg@mail.gmail.com>
	<20141121170805.GD30603@home.goodmis.org>
	<CA+55aFw+axXZhez-5x8zWFw1=6OazMbj=va8nt9GZHsrxsKewQ@mail.gmail.com>
	<CALCETrUp5kCnzFokCKVf3kn7K_d_5YP-phyNfL4rFR0tMZJi2A@mail.gmail.com>
	<CA+55aFxn_T=UgBUwqkRJvALygrNORaB6ox3nowvHpV6yFBfDoA@mail.gmail.com>
	<CA+55aFyEnuByhPM3FEdi=Q0WGuJWiBgtkWNAbRLHDpmPRaqnQA@mail.gmail.com>
	<alpine.DEB.2.11.1411212049220.6439@nanos>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.11.1411212049220.6439@nanos>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Don Zickus <dzickus@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	xen-devel@lists.xenproject.org, Tejun Heo <tj@kernel.org>,
	Dave Jones <davej@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [Xen-devel] frequent lockups in 3.18rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 08:51:43PM +0100, Thomas Gleixner wrote:
> On Fri, 21 Nov 2014, Linus Torvalds wrote:
> > Here's the simplified end result. Again, this is TOTALLY UNTESTED. I
> > compiled it and verified that the code generation looks like what I'd
> > have expected, but that's literally it.
> > 
> >   static noinline int vmalloc_fault(unsigned long address)
> >   {
> >         pgd_t *pgd_dst;
> >         pgdval_t pgd_entry;
> >         unsigned index = pgd_index(address);
> > 
> >         if (index < KERNEL_PGD_BOUNDARY)
> >                 return -1;
> > 
> >         pgd_entry = init_mm.pgd[index].pgd;
> >         if (!pgd_entry)
> >                 return -1;
> > 
> >         pgd_dst = __va(PAGE_MASK & read_cr3());
> >         pgd_dst += index;
> > 
> >         if (pgd_dst->pgd)
> >                 return -1;
> > 
> >         ACCESS_ONCE(pgd_dst->pgd) = pgd_entry;
> 
> This will break paravirt. set_pgd/set_pmd are paravirt functions.
> 
> But I'm fine with breaking it, then you just need to change
> CONFIG_PARAVIRT to 'def_bool n'

That is not very nice.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 22:35:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 22:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrwn5-00084A-HO; Fri, 21 Nov 2014 22:34:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xrwn4-000845-Vj
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:34:59 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	ED/22-09284-21EBF645; Fri, 21 Nov 2014 22:34:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416609295!13104336!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29261 invoked from network); 21 Nov 2014 22:34:57 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 22:34:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sALMXDvk019872
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Nov 2014 22:33:14 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMXBXI010037
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Nov 2014 22:33:12 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sALMXBDC028590; Fri, 21 Nov 2014 22:33:11 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Nov 2014 14:33:11 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BBCA7118C9E; Fri, 21 Nov 2014 17:33:09 -0500 (EST)
Date: Fri, 21 Nov 2014 17:33:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20141121223309.GC19283@laptop.dumpdata.com>
References: <CALCETrUh_6tWdTyDwZ4U1BDSnN1khbGDGBvCTO3MVcdU-X23QA@mail.gmail.com>
	<20141121162742.GB15461@htj.dyndns.org>
	<CALCETrUcuDh8c27cEHmoM7jo_kozJbYxV3p1H2LhmzBa16XOyQ@mail.gmail.com>
	<CA+55aFxU2q_-PVx+6fXGkXdAt3oaxvqxzy29Nrn989uTiVXvCg@mail.gmail.com>
	<20141121170805.GD30603@home.goodmis.org>
	<CA+55aFw+axXZhez-5x8zWFw1=6OazMbj=va8nt9GZHsrxsKewQ@mail.gmail.com>
	<CALCETrUp5kCnzFokCKVf3kn7K_d_5YP-phyNfL4rFR0tMZJi2A@mail.gmail.com>
	<CA+55aFxn_T=UgBUwqkRJvALygrNORaB6ox3nowvHpV6yFBfDoA@mail.gmail.com>
	<CA+55aFyEnuByhPM3FEdi=Q0WGuJWiBgtkWNAbRLHDpmPRaqnQA@mail.gmail.com>
	<alpine.DEB.2.11.1411212049220.6439@nanos>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.11.1411212049220.6439@nanos>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Don Zickus <dzickus@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	xen-devel@lists.xenproject.org, Tejun Heo <tj@kernel.org>,
	Dave Jones <davej@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [Xen-devel] frequent lockups in 3.18rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 08:51:43PM +0100, Thomas Gleixner wrote:
> On Fri, 21 Nov 2014, Linus Torvalds wrote:
> > Here's the simplified end result. Again, this is TOTALLY UNTESTED. I
> > compiled it and verified that the code generation looks like what I'd
> > have expected, but that's literally it.
> > 
> >   static noinline int vmalloc_fault(unsigned long address)
> >   {
> >         pgd_t *pgd_dst;
> >         pgdval_t pgd_entry;
> >         unsigned index = pgd_index(address);
> > 
> >         if (index < KERNEL_PGD_BOUNDARY)
> >                 return -1;
> > 
> >         pgd_entry = init_mm.pgd[index].pgd;
> >         if (!pgd_entry)
> >                 return -1;
> > 
> >         pgd_dst = __va(PAGE_MASK & read_cr3());
> >         pgd_dst += index;
> > 
> >         if (pgd_dst->pgd)
> >                 return -1;
> > 
> >         ACCESS_ONCE(pgd_dst->pgd) = pgd_entry;
> 
> This will break paravirt. set_pgd/set_pmd are paravirt functions.
> 
> But I'm fine with breaking it, then you just need to change
> CONFIG_PARAVIRT to 'def_bool n'

That is not very nice.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 23:17:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 23:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrxRs-00009u-9C; Fri, 21 Nov 2014 23:17:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrxRr-00009m-EQ
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 23:17:07 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	BF/CD-26858-2F7CF645; Fri, 21 Nov 2014 23:17:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416611824!13026206!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11188 invoked from network); 21 Nov 2014 23:17:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 23:17:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,433,1413244800"; d="scan'208";a="195438927"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 18:17:03 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrxRm-0002eg-Qf;
	Fri, 21 Nov 2014 23:17:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrxRm-0006k8-Kh;
	Fri, 21 Nov 2014 23:17:02 +0000
Date: Fri, 21 Nov 2014 23:17:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31683-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31683: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31683 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31683/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 31241

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 31665
 test-amd64-amd64-xl           5 xen-boot                    fail pass in 31665
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                    fail pass in 31665
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot            fail pass in 31665
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot     fail in 31665 pass in 31683
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 31665 pass in 31683

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31665 never pass

version targeted for testing:
 linux                fc14f9c1272f62c3e8d01300f52467c0d9af50f9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
561 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 22279 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 21 23:17:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Nov 2014 23:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrxRs-00009u-9C; Fri, 21 Nov 2014 23:17:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XrxRr-00009m-EQ
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 23:17:07 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	BF/CD-26858-2F7CF645; Fri, 21 Nov 2014 23:17:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416611824!13026206!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11188 invoked from network); 21 Nov 2014 23:17:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2014 23:17:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,433,1413244800"; d="scan'208";a="195438927"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 18:17:03 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XrxRm-0002eg-Qf;
	Fri, 21 Nov 2014 23:17:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XrxRm-0006k8-Kh;
	Fri, 21 Nov 2014 23:17:02 +0000
Date: Fri, 21 Nov 2014 23:17:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31683-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31683: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31683 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31683/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 31241

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 31665
 test-amd64-amd64-xl           5 xen-boot                    fail pass in 31665
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                    fail pass in 31665
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot            fail pass in 31665
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot     fail in 31665 pass in 31683
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 31665 pass in 31683

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31665 never pass

version targeted for testing:
 linux                fc14f9c1272f62c3e8d01300f52467c0d9af50f9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
561 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 22279 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 Nov 22 01:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 01:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrz4G-0007TD-71; Sat, 22 Nov 2014 01:00:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xrz4E-0007Dq-Ii
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 01:00:50 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	82/71-26858-140EF645; Sat, 22 Nov 2014 01:00:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416618047!13055513!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28173 invoked from network); 22 Nov 2014 01:00:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 01:00:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,434,1413244800"; d="scan'208";a="193921569"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 20:00:45 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xrz49-0003BJ-8U;
	Sat, 22 Nov 2014 01:00:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xrz48-0003WW-WB;
	Sat, 22 Nov 2014 01:00:45 +0000
Date: Sat, 22 Nov 2014 01:00:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31686-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31686: 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 31686 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31686/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31651

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5
baseline version:
 qemuu                4e70f9271dabc58fbf14680843bfac510c193152

------------------------------------------------------------
People who touched revisions under test:
  Amit Shah <amit.shah@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Christoph Seifert <christoph.seifert@posteo.de>
  Don Slutz <dslutz@verizon.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael S. Tsirkin <mst@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefan Hajnoczi <stefanha@redhat.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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-mainline
+ revision=af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-mainline af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5
+ branch=qemu-mainline
+ revision=af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ qemuubranch=qemu-mainline
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' xqemu-mainline = x ']'
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://git.qemu.org/qemu.git
++ : daily-cron.qemu-mainline
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-mainline
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-mainline
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-mainline
+ git push osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   4e70f92..af3ff19  af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5 -> mainline/xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 01:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 01:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xrz4G-0007TD-71; Sat, 22 Nov 2014 01:00:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xrz4E-0007Dq-Ii
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 01:00:50 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	82/71-26858-140EF645; Sat, 22 Nov 2014 01:00:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416618047!13055513!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28173 invoked from network); 22 Nov 2014 01:00:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 01:00:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,434,1413244800"; d="scan'208";a="193921569"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 20:00:45 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xrz49-0003BJ-8U;
	Sat, 22 Nov 2014 01:00:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xrz48-0003WW-WB;
	Sat, 22 Nov 2014 01:00:45 +0000
Date: Sat, 22 Nov 2014 01:00:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31686-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31686: 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 31686 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31686/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31651

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5
baseline version:
 qemuu                4e70f9271dabc58fbf14680843bfac510c193152

------------------------------------------------------------
People who touched revisions under test:
  Amit Shah <amit.shah@redhat.com>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Christoph Seifert <christoph.seifert@posteo.de>
  Don Slutz <dslutz@verizon.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Kevin Wolf <kwolf@redhat.com>
  Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael S. Tsirkin <mst@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefan Hajnoczi <stefanha@redhat.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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-mainline
+ revision=af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-mainline af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5
+ branch=qemu-mainline
+ revision=af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ qemuubranch=qemu-mainline
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' xqemu-mainline = x ']'
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://git.qemu.org/qemu.git
++ : daily-cron.qemu-mainline
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-mainline
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-mainline
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-mainline
+ git push osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   4e70f92..af3ff19  af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5 -> mainline/xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 01:18:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 01:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrzKy-0005pb-Ev; Sat, 22 Nov 2014 01:18:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1XrzKx-0005pT-C5
	for xen-devel@lists.xenproject.org; Sat, 22 Nov 2014 01:18:07 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	5F/7B-05632-E44EF645; Sat, 22 Nov 2014 01:18:06 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416619085!13118019!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26157 invoked from network); 22 Nov 2014 01:18:05 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 22 Nov 2014 01:18:05 -0000
Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80)
	(envelope-from <tglx@linutronix.de>)
	id 1XrzKh-0001m0-De; Sat, 22 Nov 2014 02:17:51 +0100
Date: Sat, 22 Nov 2014 02:17:52 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141121223309.GC19283@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.11.1411220216570.6439@nanos>
References: <CALCETrUh_6tWdTyDwZ4U1BDSnN1khbGDGBvCTO3MVcdU-X23QA@mail.gmail.com>
	<20141121162742.GB15461@htj.dyndns.org>
	<CALCETrUcuDh8c27cEHmoM7jo_kozJbYxV3p1H2LhmzBa16XOyQ@mail.gmail.com>
	<CA+55aFxU2q_-PVx+6fXGkXdAt3oaxvqxzy29Nrn989uTiVXvCg@mail.gmail.com>
	<20141121170805.GD30603@home.goodmis.org>
	<CA+55aFw+axXZhez-5x8zWFw1=6OazMbj=va8nt9GZHsrxsKewQ@mail.gmail.com>
	<CALCETrUp5kCnzFokCKVf3kn7K_d_5YP-phyNfL4rFR0tMZJi2A@mail.gmail.com>
	<CA+55aFxn_T=UgBUwqkRJvALygrNORaB6ox3nowvHpV6yFBfDoA@mail.gmail.com>
	<CA+55aFyEnuByhPM3FEdi=Q0WGuJWiBgtkWNAbRLHDpmPRaqnQA@mail.gmail.com>
	<alpine.DEB.2.11.1411212049220.6439@nanos>
	<20141121223309.GC19283@laptop.dumpdata.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: Don Zickus <dzickus@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	xen-devel@lists.xenproject.org, Tejun Heo <tj@kernel.org>,
	Dave Jones <davej@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [Xen-devel] frequent lockups in 3.18rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 08:51:43PM +0100, Thomas Gleixner wrote:
 > > On Fri, 21 Nov 2014, Linus Torvalds wrote:
> > > Here's the simplified end result. Again, this is TOTALLY UNTESTED. I
> > > compiled it and verified that the code generation looks like what I'd
> > > have expected, but that's literally it.
> > > 
> > >   static noinline int vmalloc_fault(unsigned long address)
> > >   {
> > >         pgd_t *pgd_dst;
> > >         pgdval_t pgd_entry;
> > >         unsigned index = pgd_index(address);
> > > 
> > >         if (index < KERNEL_PGD_BOUNDARY)
> > >                 return -1;
> > > 
> > >         pgd_entry = init_mm.pgd[index].pgd;
> > >         if (!pgd_entry)
> > >                 return -1;
> > > 
> > >         pgd_dst = __va(PAGE_MASK & read_cr3());
> > >         pgd_dst += index;
> > > 
> > >         if (pgd_dst->pgd)
> > >                 return -1;
> > > 
> > >         ACCESS_ONCE(pgd_dst->pgd) = pgd_entry;
> > 
> > This will break paravirt. set_pgd/set_pmd are paravirt functions.
> > 
> > But I'm fine with breaking it, then you just need to change
> > CONFIG_PARAVIRT to 'def_bool n'
> 
> That is not very nice.

Maybe not nice, but sensible.

Thanks,

	tglx


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 01:18:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 01:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XrzKy-0005pb-Ev; Sat, 22 Nov 2014 01:18:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1XrzKx-0005pT-C5
	for xen-devel@lists.xenproject.org; Sat, 22 Nov 2014 01:18:07 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	5F/7B-05632-E44EF645; Sat, 22 Nov 2014 01:18:06 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416619085!13118019!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26157 invoked from network); 22 Nov 2014 01:18:05 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 22 Nov 2014 01:18:05 -0000
Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80)
	(envelope-from <tglx@linutronix.de>)
	id 1XrzKh-0001m0-De; Sat, 22 Nov 2014 02:17:51 +0100
Date: Sat, 22 Nov 2014 02:17:52 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141121223309.GC19283@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.11.1411220216570.6439@nanos>
References: <CALCETrUh_6tWdTyDwZ4U1BDSnN1khbGDGBvCTO3MVcdU-X23QA@mail.gmail.com>
	<20141121162742.GB15461@htj.dyndns.org>
	<CALCETrUcuDh8c27cEHmoM7jo_kozJbYxV3p1H2LhmzBa16XOyQ@mail.gmail.com>
	<CA+55aFxU2q_-PVx+6fXGkXdAt3oaxvqxzy29Nrn989uTiVXvCg@mail.gmail.com>
	<20141121170805.GD30603@home.goodmis.org>
	<CA+55aFw+axXZhez-5x8zWFw1=6OazMbj=va8nt9GZHsrxsKewQ@mail.gmail.com>
	<CALCETrUp5kCnzFokCKVf3kn7K_d_5YP-phyNfL4rFR0tMZJi2A@mail.gmail.com>
	<CA+55aFxn_T=UgBUwqkRJvALygrNORaB6ox3nowvHpV6yFBfDoA@mail.gmail.com>
	<CA+55aFyEnuByhPM3FEdi=Q0WGuJWiBgtkWNAbRLHDpmPRaqnQA@mail.gmail.com>
	<alpine.DEB.2.11.1411212049220.6439@nanos>
	<20141121223309.GC19283@laptop.dumpdata.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: Don Zickus <dzickus@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	xen-devel@lists.xenproject.org, Tejun Heo <tj@kernel.org>,
	Dave Jones <davej@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [Xen-devel] frequent lockups in 3.18rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 08:51:43PM +0100, Thomas Gleixner wrote:
 > > On Fri, 21 Nov 2014, Linus Torvalds wrote:
> > > Here's the simplified end result. Again, this is TOTALLY UNTESTED. I
> > > compiled it and verified that the code generation looks like what I'd
> > > have expected, but that's literally it.
> > > 
> > >   static noinline int vmalloc_fault(unsigned long address)
> > >   {
> > >         pgd_t *pgd_dst;
> > >         pgdval_t pgd_entry;
> > >         unsigned index = pgd_index(address);
> > > 
> > >         if (index < KERNEL_PGD_BOUNDARY)
> > >                 return -1;
> > > 
> > >         pgd_entry = init_mm.pgd[index].pgd;
> > >         if (!pgd_entry)
> > >                 return -1;
> > > 
> > >         pgd_dst = __va(PAGE_MASK & read_cr3());
> > >         pgd_dst += index;
> > > 
> > >         if (pgd_dst->pgd)
> > >                 return -1;
> > > 
> > >         ACCESS_ONCE(pgd_dst->pgd) = pgd_entry;
> > 
> > This will break paravirt. set_pgd/set_pmd are paravirt functions.
> > 
> > But I'm fine with breaking it, then you just need to change
> > CONFIG_PARAVIRT to 'def_bool n'
> 
> That is not very nice.

Maybe not nice, but sensible.

Thanks,

	tglx


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 02:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 02:31:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xs0T8-0006eX-D4; Sat, 22 Nov 2014 02:30:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xs0T6-0006eS-8M
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 02:30:36 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	49/AC-19763-B45FF645; Sat, 22 Nov 2014 02:30:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416623433!9884481!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25186 invoked from network); 22 Nov 2014 02:30:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 02:30:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,435,1413244800"; d="scan'208";a="195475557"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 21:30:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs0T0-0003c8-Pz;
	Sat, 22 Nov 2014 02:30:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs0T0-0006KC-DV;
	Sat, 22 Nov 2014 02:30:30 +0000
Date: Sat, 22 Nov 2014 02:30:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31691-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31691: 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 31691 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31691/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10  fail baseline untested
 test-amd64-i386-xl-credit2    9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10  fail baseline untested
 test-amd64-i386-xl           14 guest-localmigrate.2    fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu 11 guest-saverestore       fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                36391a5b6e7af0f505962c9810b31d674b98ecfd
baseline version:
 linux                fc14f9c1272f62c3e8d01300f52467c0d9af50f9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 02:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 02:31:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xs0T8-0006eX-D4; Sat, 22 Nov 2014 02:30:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xs0T6-0006eS-8M
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 02:30:36 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	49/AC-19763-B45FF645; Sat, 22 Nov 2014 02:30:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416623433!9884481!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25186 invoked from network); 22 Nov 2014 02:30:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 02:30:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,435,1413244800"; d="scan'208";a="195475557"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 21:30:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs0T0-0003c8-Pz;
	Sat, 22 Nov 2014 02:30:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs0T0-0006KC-DV;
	Sat, 22 Nov 2014 02:30:30 +0000
Date: Sat, 22 Nov 2014 02:30:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31691-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31691: 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 31691 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31691/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10  fail baseline untested
 test-amd64-i386-xl-credit2    9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10  fail baseline untested
 test-amd64-i386-xl           14 guest-localmigrate.2    fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu 11 guest-saverestore       fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                36391a5b6e7af0f505962c9810b31d674b98ecfd
baseline version:
 linux                fc14f9c1272f62c3e8d01300f52467c0d9af50f9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 03:22:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 03: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 1Xs1Go-00073j-KZ; Sat, 22 Nov 2014 03:21:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xs1Gn-00073e-2l
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 03:21:57 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	69/E3-26858-45100745; Sat, 22 Nov 2014 03:21:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416626514!13125805!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31198 invoked from network); 22 Nov 2014 03:21:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 03:21:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,435,1413244800"; d="scan'208";a="193942325"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 22:21:52 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs1Gi-0003rT-LU;
	Sat, 22 Nov 2014 03:21:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs1Gi-0004rG-Dy;
	Sat, 22 Nov 2014 03:21:52 +0000
Date: Sat, 22 Nov 2014 03:21:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31694-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31694: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31694 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31694/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 31536

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  82fa0623454a52c7d1812a9419c4cc09567d243d
baseline version:
 xen                  d6281e354393f1c8a02fac55f4f611b4d4856303

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 82fa0623454a52c7d1812a9419c4cc09567d243d
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:31:21 2014 +0100

    x86emul: enforce privilege level restrictions when loading CS
    
    Privilege level checks were basically missing for the CS case, the
    only check that was done (RPL == DPL for nonconforming segments)
    was solely covering a single special case (return to non-conforming
    segment).
    
    Additionally in long mode the L bit set requires the D bit to be clear,
    as was recently pointed out for KVM by Nadav Amit
    <namit@cs.technion.ac.il>.
    
    Finally we also need to force the loaded selector's RPL to CPL (at
    least as long as lret/retf emulation doesn't support privilege level
    changes).
    
    This is CVE-2014-8595 / XSA-110.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: 1d68c1a70e00ed95ef0889cfa005379dab27b37d
    master date: 2014-11-18 14:16:23 +0100

commit c6e304d8335c9d8c447d743fd1163fbe8bccf245
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:30:37 2014 +0100

    x86: don't allow page table updates on non-PV page tables in do_mmu_update()
    
    paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
    consistently supported for non-PV guests (they'd deref NULL for PVH or
    non-HAP HVM ones). Don't allow respective MMU_* operations on the
    page tables of such domains.
    
    This is CVE-2014-8594 / XSA-109.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    master commit: e4292c5aac41b80f33d4877104348d5ee7c95aa4
    master date: 2014-11-18 14:15:21 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 03:22:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 03: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 1Xs1Go-00073j-KZ; Sat, 22 Nov 2014 03:21:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xs1Gn-00073e-2l
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 03:21:57 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	69/E3-26858-45100745; Sat, 22 Nov 2014 03:21:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416626514!13125805!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31198 invoked from network); 22 Nov 2014 03:21:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 03:21:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,435,1413244800"; d="scan'208";a="193942325"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 21 Nov 2014 22:21:52 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs1Gi-0003rT-LU;
	Sat, 22 Nov 2014 03:21:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs1Gi-0004rG-Dy;
	Sat, 22 Nov 2014 03:21:52 +0000
Date: Sat, 22 Nov 2014 03:21:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31694-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31694: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31694 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31694/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 31536

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  82fa0623454a52c7d1812a9419c4cc09567d243d
baseline version:
 xen                  d6281e354393f1c8a02fac55f4f611b4d4856303

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 82fa0623454a52c7d1812a9419c4cc09567d243d
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:31:21 2014 +0100

    x86emul: enforce privilege level restrictions when loading CS
    
    Privilege level checks were basically missing for the CS case, the
    only check that was done (RPL == DPL for nonconforming segments)
    was solely covering a single special case (return to non-conforming
    segment).
    
    Additionally in long mode the L bit set requires the D bit to be clear,
    as was recently pointed out for KVM by Nadav Amit
    <namit@cs.technion.ac.il>.
    
    Finally we also need to force the loaded selector's RPL to CPL (at
    least as long as lret/retf emulation doesn't support privilege level
    changes).
    
    This is CVE-2014-8595 / XSA-110.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: 1d68c1a70e00ed95ef0889cfa005379dab27b37d
    master date: 2014-11-18 14:16:23 +0100

commit c6e304d8335c9d8c447d743fd1163fbe8bccf245
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:30:37 2014 +0100

    x86: don't allow page table updates on non-PV page tables in do_mmu_update()
    
    paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
    consistently supported for non-PV guests (they'd deref NULL for PVH or
    non-HAP HVM ones). Don't allow respective MMU_* operations on the
    page tables of such domains.
    
    This is CVE-2014-8594 / XSA-109.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    master commit: e4292c5aac41b80f33d4877104348d5ee7c95aa4
    master date: 2014-11-18 14:15:21 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 05:12:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 05:12:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xs2z6-000831-Gv; Sat, 22 Nov 2014 05:11:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xs2z4-00080q-W3
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 05:11:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	96/D5-09842-21B10745; Sat, 22 Nov 2014 05:11:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416633104!14206264!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17140 invoked from network); 22 Nov 2014 05:11:45 -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;
	22 Nov 2014 05:11:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,435,1413244800"; d="scan'208";a="193974824"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 00:11:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs2yz-0004O9-Kj;
	Sat, 22 Nov 2014 05:11:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs2yo-0005vd-Fk;
	Sat, 22 Nov 2014 05:11:39 +0000
Date: Sat, 22 Nov 2014 05:11:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31716-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31716: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31716 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31716/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-intel  7 redhat-install      fail pass in 31675
 test-amd64-i386-xl            3 host-install(3)  broken in 31675 pass in 31716
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 31675 pass in 31716
 test-amd64-i386-freebsd10-amd64 3 host-install(3) broken in 31675 pass in 31716

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 30846 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 Nov 22 05:12:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 05:12:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xs2z6-000831-Gv; Sat, 22 Nov 2014 05:11:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xs2z4-00080q-W3
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 05:11:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	96/D5-09842-21B10745; Sat, 22 Nov 2014 05:11:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416633104!14206264!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17140 invoked from network); 22 Nov 2014 05:11:45 -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;
	22 Nov 2014 05:11:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,435,1413244800"; d="scan'208";a="193974824"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 00:11:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs2yz-0004O9-Kj;
	Sat, 22 Nov 2014 05:11:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs2yo-0005vd-Fk;
	Sat, 22 Nov 2014 05:11:39 +0000
Date: Sat, 22 Nov 2014 05:11:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31716-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31716: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31716 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31716/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-intel  7 redhat-install      fail pass in 31675
 test-amd64-i386-xl            3 host-install(3)  broken in 31675 pass in 31716
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 31675 pass in 31716
 test-amd64-i386-freebsd10-amd64 3 host-install(3) broken in 31675 pass in 31716

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                be70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
750 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 30846 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 Nov 22 09:29:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 09:29:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xs70S-0001lr-7B; Sat, 22 Nov 2014 09:29:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xs70Q-0001lm-3e
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 09:29:26 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	1C/FE-02699-57750745; Sat, 22 Nov 2014 09:29:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416648562!10811889!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4700 invoked from network); 22 Nov 2014 09:29:24 -0000
Received: from unknown (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 09:29:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,436,1413244800"; d="scan'208";a="195542518"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 04:28:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs6zw-0005fF-2V;
	Sat, 22 Nov 2014 09:28:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs6zv-0007R8-RI;
	Sat, 22 Nov 2014 09:28:55 +0000
Date: Sat, 22 Nov 2014 09:28:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31726-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31726: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31726 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31726/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen        3 host-install(3)         broken REGR. vs. 31630

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 31673
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)       broken pass in 31673
 test-i386-i386-libvirt        5 xen-boot           fail in 31673 pass in 31726

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair         17 guest-migrate/src_host/dst_host fail like 31592
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31630

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31673 never pass
 build-i386-rumpuserxen        5 rumpuserxen-build     fail in 31673 never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop        fail in 31673 never pass

version targeted for testing:
 xen                  301bd3e8c53f2478da537a223386e153d046a063
baseline version:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       broken  
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-i386-rumpuserxen host-install(3)
broken-step test-i386-i386-xl-qemuu-winxpsp3 host-install(3)

Not pushing.

------------------------------------------------------------
commit 301bd3e8c53f2478da537a223386e153d046a063
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:33:55 2014 +0100

    x86emul: enforce privilege level restrictions when loading CS
    
    Privilege level checks were basically missing for the CS case, the
    only check that was done (RPL == DPL for nonconforming segments)
    was solely covering a single special case (return to non-conforming
    segment).
    
    Additionally in long mode the L bit set requires the D bit to be clear,
    as was recently pointed out for KVM by Nadav Amit
    <namit@cs.technion.ac.il>.
    
    Finally we also need to force the loaded selector's RPL to CPL (at
    least as long as lret/retf emulation doesn't support privilege level
    changes).
    
    This is CVE-2014-8595 / XSA-110.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 6791ab169fe6b2cd7c69a5140cd229d036e706b0
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:32:57 2014 +0100

    x86: don't allow page table updates on non-PV page tables in do_mmu_update()
    
    paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
    consistently supported for non-PV guests (they'd deref NULL for PVH or
    non-HAP HVM ones). Don't allow respective MMU_* operations on the
    page tables of such domains.
    
    This is CVE-2014-8594 / XSA-109.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 09:29:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 09:29:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xs70S-0001lr-7B; Sat, 22 Nov 2014 09:29:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xs70Q-0001lm-3e
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 09:29:26 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	1C/FE-02699-57750745; Sat, 22 Nov 2014 09:29:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416648562!10811889!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4700 invoked from network); 22 Nov 2014 09:29:24 -0000
Received: from unknown (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 09:29:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,436,1413244800"; d="scan'208";a="195542518"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 04:28:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs6zw-0005fF-2V;
	Sat, 22 Nov 2014 09:28:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs6zv-0007R8-RI;
	Sat, 22 Nov 2014 09:28:55 +0000
Date: Sat, 22 Nov 2014 09:28:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31726-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31726: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31726 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31726/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen        3 host-install(3)         broken REGR. vs. 31630

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 31673
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)       broken pass in 31673
 test-i386-i386-libvirt        5 xen-boot           fail in 31673 pass in 31726

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair         17 guest-migrate/src_host/dst_host fail like 31592
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31630

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31673 never pass
 build-i386-rumpuserxen        5 rumpuserxen-build     fail in 31673 never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop        fail in 31673 never pass

version targeted for testing:
 xen                  301bd3e8c53f2478da537a223386e153d046a063
baseline version:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       broken  
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-i386-rumpuserxen host-install(3)
broken-step test-i386-i386-xl-qemuu-winxpsp3 host-install(3)

Not pushing.

------------------------------------------------------------
commit 301bd3e8c53f2478da537a223386e153d046a063
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:33:55 2014 +0100

    x86emul: enforce privilege level restrictions when loading CS
    
    Privilege level checks were basically missing for the CS case, the
    only check that was done (RPL == DPL for nonconforming segments)
    was solely covering a single special case (return to non-conforming
    segment).
    
    Additionally in long mode the L bit set requires the D bit to be clear,
    as was recently pointed out for KVM by Nadav Amit
    <namit@cs.technion.ac.il>.
    
    Finally we also need to force the loaded selector's RPL to CPL (at
    least as long as lret/retf emulation doesn't support privilege level
    changes).
    
    This is CVE-2014-8595 / XSA-110.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 6791ab169fe6b2cd7c69a5140cd229d036e706b0
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:32:57 2014 +0100

    x86: don't allow page table updates on non-PV page tables in do_mmu_update()
    
    paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
    consistently supported for non-PV guests (they'd deref NULL for PVH or
    non-HAP HVM ones). Don't allow respective MMU_* operations on the
    page tables of such domains.
    
    This is CVE-2014-8594 / XSA-109.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 10:48:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 10:48:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xs8EG-0002MY-OG; Sat, 22 Nov 2014 10:47: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@citrix.com>) id 1Xs8EF-0002MT-6f
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 10:47:47 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	2E/C0-31453-2D960745; Sat, 22 Nov 2014 10:47:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416653264!12817738!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10834 invoked from network); 22 Nov 2014 10:47:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 10:47:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,436,1413244800"; d="scan'208";a="194060413"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 05:47:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs8E9-00062k-Pu;
	Sat, 22 Nov 2014 10:47:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs8E9-0005ac-In;
	Sat, 22 Nov 2014 10:47:41 +0000
Date: Sat, 22 Nov 2014 10:47:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31729-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31729: 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 31729 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31729/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 31647
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31647

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10    fail REGR. vs. 31647

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a
baseline version:
 qemuu                0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51

------------------------------------------------------------
People who touched revisions under test:
  Don Slutz <dslutz@verizon.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-qemut-winxpsp3-vcpus1 host-install(3)

Not pushing.

------------------------------------------------------------
commit a230ec3101ddda868252c036ea960af2b2d6cd5a
Author: Don Slutz <dslutz@verizon.com>
Date:   Mon Nov 17 16:20:39 2014 -0500

    hw/ide/core.c: Prevent SIGSEGV during migration
    
    The other callers to blk_set_enable_write_cache() in this file
    already check for s->blk == NULL.
    
    upstream-commit-id: 6b896ab261942f441a16836e3fa3c83f3f4488b9
    
    Signed-off-by: Don Slutz <dslutz@verizon.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Message-id: 1416259239-13281-1-git-send-email-dslutz@verizon.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    
    Conflicts:
    	hw/ide/core.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 10:48:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 10:48:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xs8EG-0002MY-OG; Sat, 22 Nov 2014 10:47: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@citrix.com>) id 1Xs8EF-0002MT-6f
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 10:47:47 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	2E/C0-31453-2D960745; Sat, 22 Nov 2014 10:47:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416653264!12817738!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10834 invoked from network); 22 Nov 2014 10:47:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 10:47:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,436,1413244800"; d="scan'208";a="194060413"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 05:47:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs8E9-00062k-Pu;
	Sat, 22 Nov 2014 10:47:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs8E9-0005ac-In;
	Sat, 22 Nov 2014 10:47:41 +0000
Date: Sat, 22 Nov 2014 10:47:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31729-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31729: 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 31729 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31729/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 31647
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31647

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10    fail REGR. vs. 31647

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a
baseline version:
 qemuu                0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51

------------------------------------------------------------
People who touched revisions under test:
  Don Slutz <dslutz@verizon.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-qemut-winxpsp3-vcpus1 host-install(3)

Not pushing.

------------------------------------------------------------
commit a230ec3101ddda868252c036ea960af2b2d6cd5a
Author: Don Slutz <dslutz@verizon.com>
Date:   Mon Nov 17 16:20:39 2014 -0500

    hw/ide/core.c: Prevent SIGSEGV during migration
    
    The other callers to blk_set_enable_write_cache() in this file
    already check for s->blk == NULL.
    
    upstream-commit-id: 6b896ab261942f441a16836e3fa3c83f3f4488b9
    
    Signed-off-by: Don Slutz <dslutz@verizon.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Message-id: 1416259239-13281-1-git-send-email-dslutz@verizon.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    
    Conflicts:
    	hw/ide/core.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 11:54:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 11:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xs9GR-0002s1-0R; Sat, 22 Nov 2014 11:54:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xs9GQ-0002rw-2b
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 11:54:06 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	C6/AA-05632-D5970745; Sat, 22 Nov 2014 11:54:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416657243!13058441!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11454 invoked from network); 22 Nov 2014 11:54:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 11:54:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,437,1413244800"; d="scan'208";a="195564839"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 06:54:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs9GL-0006MI-08;
	Sat, 22 Nov 2014 11:54:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs9GK-0003i4-Qt;
	Sat, 22 Nov 2014 11:54:00 +0000
Date: Sat, 22 Nov 2014 11:54:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31733-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31733: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31733 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31733/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 31669

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
baseline version:
 xen                  d279f6e1344871d71e379cc06c7baa6d4f9f0b29

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Thu Nov 20 17:43:39 2014 +0100

    x86/mm: fix a reference counting error in MMU_MACHPHYS_UPDATE
    
    Any domain which can pass the XSM check against a translated guest can cause a
    page reference to be leaked.
    
    While shuffling the order of checks, drop the quite-pointless MEM_LOG().  This
    brings the check in line with similar checks in the vicinity.
    
    Discovered while reviewing the XSA-109/110 followup series.
    
    This is XSA-113.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 11:54:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 11:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xs9GR-0002s1-0R; Sat, 22 Nov 2014 11:54:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xs9GQ-0002rw-2b
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 11:54:06 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	C6/AA-05632-D5970745; Sat, 22 Nov 2014 11:54:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416657243!13058441!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11454 invoked from network); 22 Nov 2014 11:54:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 11:54:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,437,1413244800"; d="scan'208";a="195564839"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 06:54:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xs9GL-0006MI-08;
	Sat, 22 Nov 2014 11:54:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xs9GK-0003i4-Qt;
	Sat, 22 Nov 2014 11:54:00 +0000
Date: Sat, 22 Nov 2014 11:54:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31733-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31733: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31733 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31733/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 31669

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
baseline version:
 xen                  d279f6e1344871d71e379cc06c7baa6d4f9f0b29

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Thu Nov 20 17:43:39 2014 +0100

    x86/mm: fix a reference counting error in MMU_MACHPHYS_UPDATE
    
    Any domain which can pass the XSM check against a translated guest can cause a
    page reference to be leaked.
    
    While shuffling the order of checks, drop the quite-pointless MEM_LOG().  This
    brings the check in line with similar checks in the vicinity.
    
    Discovered while reviewing the XSA-109/110 followup series.
    
    This is XSA-113.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 16:42:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 16:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsDkd-00059a-0g; Sat, 22 Nov 2014 16:41: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@citrix.com>) id 1XsDkb-00059V-8O
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 16:41:33 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	11/31-14727-CBCB0745; Sat, 22 Nov 2014 16:41:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416674490!12858714!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1874 invoked from network); 22 Nov 2014 16:41:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 16:41:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,437,1413244800"; d="scan'208";a="194195083"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 11:41:18 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsDkM-0007kD-0T;
	Sat, 22 Nov 2014 16:41:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsDkL-0004y7-Rc;
	Sat, 22 Nov 2014 16:41:17 +0000
Date: Sat, 22 Nov 2014 16:41:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31761-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31761: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31761 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31761/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 31680

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              b7d1bee2b9a8d7ed76456447b090702223da39f5
baseline version:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad

------------------------------------------------------------
People who touched revisions under test:
  Anirban Chakraborty <abchak@juniper.net>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Giuseppe Scrivano <gscrivan@redhat.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nehal J Wani <nehaljw.kkd1@gmail.com>
  Peter Krempa <pkrempa@redhat.com>
  Yohan BELLEGUIC <yohan.belleguic@diateam.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 610 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 Nov 22 16:42:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 16:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsDkd-00059a-0g; Sat, 22 Nov 2014 16:41: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@citrix.com>) id 1XsDkb-00059V-8O
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 16:41:33 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	11/31-14727-CBCB0745; Sat, 22 Nov 2014 16:41:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416674490!12858714!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1874 invoked from network); 22 Nov 2014 16:41:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 16:41:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,437,1413244800"; d="scan'208";a="194195083"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 11:41:18 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsDkM-0007kD-0T;
	Sat, 22 Nov 2014 16:41:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsDkL-0004y7-Rc;
	Sat, 22 Nov 2014 16:41:17 +0000
Date: Sat, 22 Nov 2014 16:41:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31761-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31761: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31761 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31761/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 31680

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              b7d1bee2b9a8d7ed76456447b090702223da39f5
baseline version:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad

------------------------------------------------------------
People who touched revisions under test:
  Anirban Chakraborty <abchak@juniper.net>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Giuseppe Scrivano <gscrivan@redhat.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nehal J Wani <nehaljw.kkd1@gmail.com>
  Peter Krempa <pkrempa@redhat.com>
  Yohan BELLEGUIC <yohan.belleguic@diateam.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 610 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 Nov 22 19:25:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 19:25:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsGIU-0006Fk-BL; Sat, 22 Nov 2014 19:24:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XsGIS-0006Ff-Em
	for xen-devel@lists.xen.org; Sat, 22 Nov 2014 19:24:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	97/DD-15461-7F2E0745; Sat, 22 Nov 2014 19:24:39 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416684278!14621400!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15586 invoked from network); 22 Nov 2014 19:24:38 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2014 19:24:38 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAMJOQmY010138
	for <xen-devel@lists.xen.org>; Sat, 22 Nov 2014 19:24:30 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAMJOLW4029131
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Sat, 22 Nov 2014 19:24:21 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAMJOLik025658
	for <xen-devel@lists.xen.org>; Sat, 22 Nov 2014 19:24:21 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAMJOLgv025654
	for <xen-devel@lists.xen.org>; Sat, 22 Nov 2014 19:24:21 GMT
Date: Sat, 22 Nov 2014 19:24:21 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-2129309582-1416684261=:26346"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAMJOQmY010138
Subject: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-2129309582-1416684261=:26346
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

While investigating a bug reported on Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1166461
I discovered the following

xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the 
bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. 
There are actually two issues here

* the segfault in libxl-save-helper --restore-domain (as reported in the 
bug above) occurs if the guest memory is 1024M (on my 4G box) and is 
presumably because the allocated memory eventually runs out

* the segfault doesn't occur if the guest memory is 128M, but the 
migration still fails. The first attached file contains the log from a run 
with xl -v migrate --debug domid localhost (with mfn and duplicated lines 
stripped out to make the size manageable).

I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl 
migrate doesn't work for me at all - see the second attached file for the 
output of xl -v migrate domid localhost .

 	Mchael Young
--8323329-2129309582-1416684261=:26346
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xl.-v.--debug.fail.4.4
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xl.-v.--debug.fail.4.4

bWlncmF0aW9uIHRhcmdldDogUmVhZHkgdG8gcmVjZWl2ZSBkb21haW4uDQpT
YXZpbmcgdG8gbWlncmF0aW9uIHN0cmVhbSBuZXcgeGwgZm9ybWF0IChpbmZv
IDB4MC8weDAvMTI5NCkNCkxvYWRpbmcgbmV3IHNhdmUgZmlsZSA8aW5jb21p
bmcgbWlncmF0aW9uIHN0cmVhbT4gKG5ldyB4bCBmbXQgaW5mbyAweDAvMHgw
LzEyOTQpDQogU2F2ZWZpbGUgY29udGFpbnMgeGwgZG9tYWluIGNvbmZpZw0K
eGM6IGRldGFpbDogeGNfZG9tYWluX3NhdmU6IHN0YXJ0aW5nIHNhdmUgb2Yg
ZG9taWQgMjMNCnhjOiBkZXRhaWw6IEhhZCAwIHVuZXhwbGFpbmVkIGVudHJp
ZXMgaW4gcDJtIHRhYmxlDQp4YzogZGV0YWlsOiANCnhjOiBwcm9ncmVzczog
UmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMjA0OC8zMjc2OCAgICA2JQ0KeGM6
IGRldGFpbDogDQp4YzogcHJvZ3Jlc3M6IFJlbG9hZGluZyBtZW1vcnkgcGFn
ZXM6IDYxNDQvMzI3NjggICAxOCUNCnhjOiBkZXRhaWw6IA0KeGM6IHhjOiBk
ZXRhaWw6IA0KeGM6IGRldGFpbDogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczog
ODE5Mi8zMjc2OCAgIDI1JQ0KDQp4YzogZGV0YWlsOiANCnhjOiB4YzogcHJv
Z3Jlc3M6IFJlbG9hZGluZyBtZW1vcnkgcGFnZXM6IDEwMjQwLzMyNzY4ICAg
MzElDQp4YzogZGV0YWlsOiANCnhjOiB4YzogcHJvZ3Jlc3M6IFJlbG9hZGlu
ZyBtZW1vcnkgcGFnZXM6IDE0MzM2LzMyNzY4ICAgNDMlDQp4YzogZGV0YWls
OiANCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMTYz
ODQvMzI3NjggICA1MCUNCnhjOiBkZXRhaWw6IA0KeGM6IHByb2dyZXNzOiBS
ZWxvYWRpbmcgbWVtb3J5IHBhZ2VzOiAxODQzMi8zMjc2OCAgIDU2JQ0KeGM6
IGRldGFpbDogDQp4YzogeGM6IHByb2dyZXNzOiBSZWxvYWRpbmcgbWVtb3J5
IHBhZ2VzOiAyMDQ4MC8zMjc2OCAgIDYyJQ0KZGV0YWlsOiANCnhjOiBkZXRh
aWw6IA0KeGM6IHByb2dyZXNzOiBSZWxvYWRpbmcgbWVtb3J5IHBhZ2VzOiAy
MjUyOC8zMjc2OCAgIDY4JQ0KeGM6IGRldGFpbDogDQp4YzogeGM6IHByb2dy
ZXNzOiBSZWxvYWRpbmcgbWVtb3J5IHBhZ2VzOiAyNDU3Ni8zMjc2OCAgIDc1
JQ0KZGV0YWlsOiANCnhjOiBkZXRhaWw6IA0KeGM6IHhjOiBkZXRhaWw6IA0K
UmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMjY2MjQvMzI3NjggICA4MSV4Yzog
ZGV0YWlsOiANCnhjOiANCnhjOiBkZXRhaWw6IA0KeGM6IHhjOiBwcm9ncmVz
czogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMjg2NzIvMzI3NjggICA4NyUN
CmRldGFpbDogDQp4YzogZGV0YWlsOiANCnhjOiBwcm9ncmVzczogUmVsb2Fk
aW5nIG1lbW9yeSBwYWdlczogMzA3MjAvMzI3NjggICA5MyUNCnhjOiBkZXRh
aWw6IA0KeGM6IGRldGFpbDogZGVsdGEgNDU5OW1zLCBkb20wIDk2JSwgdGFy
Z2V0IDAlLCBzZW50IDIzMk1iL3MsIGRpcnRpZWQgME1iL3MgODIgcGFnZXMN
CnhjOiBkZXRhaWw6IA0KcHJvZ3Jlc3M6IFJlbG9hZGluZyBtZW1vcnkgcGFn
ZXM6IDMyNjg3LzMyNzY4ICAgOTklDQp4YzogZGV0YWlsOiANCnhjOiBkZXRh
aWw6IGRlbHRhIDE2NTltcywgZG9tMCA5MCUsIHRhcmdldCAwJSwgc2VudCAx
TWIvcywgZGlydGllZCAxTWIvcyA4MiBwYWdlcw0KeGM6IGRldGFpbDogDQp4
YzogZGV0YWlsOiBkZWx0YSAxNjcwbXMsIGRvbTAgODUlLCB0YXJnZXQgMCUs
IHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1iL3MgODEgcGFnZXMNCnhjOiBkZXRh
aWw6IA0KeGM6IGRldGFpbDogZGVsdGEgMTY3OW1zLCBkb20wIDg1JSwgdGFy
Z2V0IDAlLCBzZW50IDFNYi9zLCBkaXJ0aWVkIDFNYi9zIDczIHBhZ2VzDQp4
YzogZGV0YWlsOiANCnhjOiBkZXRhaWw6IGRlbHRhIDE2NjZtcywgZG9tMCA4
NiUsIHRhcmdldCAwJSwgc2VudCAxTWIvcywgZGlydGllZCAxTWIvcyA4MSBw
YWdlcw0KeGM6IGRldGFpbDogDQp4YzogZGV0YWlsOiBkZWx0YSAxNjgzbXMs
IGRvbTAgODUlLCB0YXJnZXQgMCUsIHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1i
L3MgNzMgcGFnZXMNCnhjOiBkZXRhaWw6IA0KeGM6IGRldGFpbDogZGVsdGEg
MTY3NG1zLCBkb20wIDg1JSwgdGFyZ2V0IDAlLCBzZW50IDFNYi9zLCBkaXJ0
aWVkIDFNYi9zIDgzIHBhZ2VzDQp4YzogZGV0YWlsOiANCnhjOiBkZXRhaWw6
IGRlbHRhIDE2NzhtcywgZG9tMCA4NSUsIHRhcmdldCAwJSwgc2VudCAxTWIv
cywgZGlydGllZCAxTWIvcyA4MiBwYWdlcw0KeGM6IGRldGFpbDogDQp4Yzog
ZGV0YWlsOiBkZWx0YSAxNjc2bXMsIGRvbTAgODUlLCB0YXJnZXQgMCUsIHNl
bnQgMU1iL3MsIGRpcnRpZWQgMU1iL3MgNzMgcGFnZXMNCnhjOiBkZXRhaWw6
IA0KeGM6IGRldGFpbDogZGVsdGEgMTY4OW1zLCBkb20wIDg3JSwgdGFyZ2V0
IDAlLCBzZW50IDFNYi9zLCBkaXJ0aWVkIDFNYi9zIDgyIHBhZ2VzDQp4Yzog
ZGV0YWlsOiANCnhjOiBkZXRhaWw6IGRlbHRhIDE2ODRtcywgZG9tMCA4NSUs
IHRhcmdldCAwJSwgc2VudCAxTWIvcywgZGlydGllZCAxTWIvcyA3MyBwYWdl
cw0KeGM6IGRldGFpbDogDQp4YzogZGV0YWlsOiBkZWx0YSAxNjc4bXMsIGRv
bTAgODYlLCB0YXJnZXQgMCUsIHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1iL3Mg
ODEgcGFnZXMNCnhjOiBkZXRhaWw6IA0KeGM6IGRldGFpbDogZGVsdGEgMTY2
NG1zLCBkb20wIDg2JSwgdGFyZ2V0IDAlLCBzZW50IDFNYi9zLCBkaXJ0aWVk
IDFNYi9zIDc1IHBhZ2VzDQp4YzogZGV0YWlsOiANCnhjOiBkZXRhaWw6IGRl
bHRhIDE3MDFtcywgZG9tMCA4NiUsIHRhcmdldCAwJSwgc2VudCAxTWIvcywg
ZGlydGllZCAxTWIvcyA5MCBwYWdlcw0KeGM6IGRldGFpbDogDQp4YzogZGV0
YWlsOiBkZWx0YSAxNjc4bXMsIGRvbTAgODclLCB0YXJnZXQgMCUsIHNlbnQg
MU1iL3MsIGRpcnRpZWQgMU1iL3MgNzQgcGFnZXMNCnhjOiBkZXRhaWw6IA0K
eGM6IGRldGFpbDogZGVsdGEgMTY1MW1zLCBkb20wIDg5JSwgdGFyZ2V0IDAl
LCBzZW50IDFNYi9zLCBkaXJ0aWVkIDFNYi9zIDc1IHBhZ2VzDQp4YzogZGV0
YWlsOiANCnhjOiBkZXRhaWw6IGRlbHRhIDE2NzdtcywgZG9tMCA4NSUsIHRh
cmdldCAwJSwgc2VudCAxTWIvcywgZGlydGllZCAxTWIvcyA4MSBwYWdlcw0K
eGM6IGRldGFpbDogDQp4YzogZGV0YWlsOiBkZWx0YSAxNjQ0bXMsIGRvbTAg
ODklLCB0YXJnZXQgMCUsIHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1iL3MgNzMg
cGFnZXMNCnhjOiBkZXRhaWw6IA0KDQp4YzogZGV0YWlsOiANCnhjOiBkZXRh
aWw6IGRlbHRhIDE2NTZtcywgZG9tMCA4NyUsIHRhcmdldCAwJSwgc2VudCAx
TWIvcywgZGlydGllZCAxTWIvcyA4MiBwYWdlcw0KeGM6IGRldGFpbDogDQp4
YzogZGV0YWlsOiBkZWx0YSAxNjQ3bXMsIGRvbTAgODglLCB0YXJnZXQgMCUs
IHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1iL3MgODMgcGFnZXMNCnhjOiBkZXRh
aWw6IA0KeGM6IGRldGFpbDogZGVsdGEgMTY2MG1zLCBkb20wIDg2JSwgdGFy
Z2V0IDAlLCBzZW50IDFNYi9zLCBkaXJ0aWVkIDFNYi9zIDc0IHBhZ2VzDQp4
YzogZGV0YWlsOiANCnhjOiBkZXRhaWw6IGRlbHRhIDI3NjBtcywgZG9tMCA5
OCUsIHRhcmdldCAwJSwgc2VudCAwTWIvcywgZGlydGllZCAwTWIvcyA4NCBw
YWdlcw0KeGM6IGRldGFpbDogDQp4YzogZGV0YWlsOiBkZWx0YSAxNjM1bXMs
IGRvbTAgOTElLCB0YXJnZXQgMCUsIHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1i
L3MgODEgcGFnZXMNCnhjOiBkZXRhaWw6IA0KeGM6IGRldGFpbDogZGVsdGEg
MjAzNW1zLCBkb20wIDk2JSwgdGFyZ2V0IDAlLCBzZW50IDFNYi9zLCBkaXJ0
aWVkIDFNYi9zIDc1IHBhZ2VzDQp4YzogZGV0YWlsOiANCnhjOiBkZXRhaWw6
IGRlbHRhIDIyMThtcywgZG9tMCA5NyUsIHRhcmdldCAwJSwgc2VudCAxTWIv
cywgZGlydGllZCAxTWIvcyA5MCBwYWdlcw0KeGM6IGRldGFpbDogDQp4Yzog
ZGV0YWlsOiBkZWx0YSAxNjY2bXMsIGRvbTAgOTYlLCB0YXJnZXQgMCUsIHNl
bnQgMU1iL3MsIGRpcnRpZWQgMU1iL3MgNzMgcGFnZXMNCnhjOiBkZXRhaWw6
IA0KeGM6IGRldGFpbDogZGVsdGEgMTY4N21zLCBkb20wIDk5JSwgdGFyZ2V0
IDAlLCBzZW50IDFNYi9zLCBkaXJ0aWVkIDFNYi9zIDc0IHBhZ2VzDQp4Yzog
ZGV0YWlsOiANCnhjOiBkZXRhaWw6IGRlbHRhIDE3NjVtcywgZG9tMCA5NSUs
IHRhcmdldCAwJSwgc2VudCAxTWIvcywgZGlydGllZCAxTWIvcyA4MiBwYWdl
cw0KeGM6IGRldGFpbDogDQp4YzogZGV0YWlsOiBTdGFydCBsYXN0IGl0ZXJh
dGlvbg0KeGM6IGRldGFpbDogU1VTUEVORCBzaGluZm8gMDAwZGMwY2INCnhj
OiBkZXRhaWw6IGRlbHRhIDE5MDZtcywgZG9tMCA4NiUsIHRhcmdldCAwJSwg
c2VudCAxTWIvcywgZGlydGllZCAzTWIvcyAyMDggcGFnZXMNCnhjOiBkZXRh
aWw6IA0KeGM6IGRldGFpbDogZGVsdGEgMjQxN21zLCBkb20wIDkyJSwgdGFy
Z2V0IDAlLCBzZW50IDJNYi9zLCBkaXJ0aWVkIDJNYi9zIDIwOCBwYWdlcw0K
eGM6IGRldGFpbDogVG90YWwgcGFnZXMgc2VudD0gMzUxMDcgKDEuMDd4KQ0K
eGM6IGRldGFpbDogKG9mIHdoaWNoIDAgd2VyZSBmaXh1cHMpDQp4YzogZGV0
YWlsOiBFbnRlcmluZyBkZWJ1ZyByZXNlbmQtYWxsIG1vZGUNCnhjOiBwcm9n
cmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMzYxMzEvMzI3NjggIDEx
MCUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMzgx
NzkvMzI3NjggIDExNiUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9y
eSBwYWdlczogNDAyMjcvMzI3NjggIDEyMiUNCnhjOiBwcm9ncmVzczogUmVs
b2FkaW5nIG1lbW9yeSBwYWdlczogNDIyNzUvMzI3NjggIDEyOSUNCnhjOiBw
cm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogNDQzMjMvMzI3Njgg
IDEzNSUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczog
NDYzNzEvMzI3NjggIDE0MSUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1l
bW9yeSBwYWdlczogNDg0MTkvMzI3NjggIDE0NyUNCnhjOiBwcm9ncmVzczog
UmVsb2FkaW5nIG1lbW9yeSBwYWdlczogNTA0NjcvMzI3NjggIDE1NCUNCnhj
OiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogNTI1MTUvMzI3
NjggIDE2MCUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdl
czogNTQ1NjMvMzI3NjggIDE2NiUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5n
IG1lbW9yeSBwYWdlczogNTY2MTEvMzI3NjggIDE3MiUNCnhjOiBwcm9ncmVz
czogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogNTg2NTkvMzI3NjggIDE3OSUN
CnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogNjA3MDcv
MzI3NjggIDE4NSUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBw
YWdlczogNjI3NTUvMzI3NjggIDE5MSUNCnhjOiBwcm9ncmVzczogUmVsb2Fk
aW5nIG1lbW9yeSBwYWdlczogNjQ4MDMvMzI3NjggIDE5NyUNCnhjOiBkZXRh
aWw6IGRlbHRhIDE2NjJtcywgZG9tMCA5NSUsIHRhcmdldCAwJSwgc2VudCA2
NDZNYi9zLCBkaXJ0aWVkIDRNYi9zIDIwOCBwYWdlcw0KeGM6IGRldGFpbDog
VG90YWwgcGFnZXMgc2VudD0gNjc4NzUgKDIuMDd4KQ0KeGM6IGRldGFpbDog
KG9mIHdoaWNoIDAgd2VyZSBmaXh1cHMpDQp4YzogZGV0YWlsOiBBbGwgbWVt
b3J5IGlzIHNhdmVkDQp4YzogcHJvZ3Jlc3M6IFJlbG9hZGluZyBtZW1vcnkg
cGFnZXM6IDY2ODUxLzMyNzY4ICAyMDQlDQp4YzogZGV0YWlsOiBTYXZlIGV4
aXQgb2YgZG9taWQgMjMgd2l0aCByYz0wDQptaWdyYXRpb24gcmVjZWl2ZXIg
c3RyZWFtIGNvbnRhaW5lZCB1bmV4cGVjdGVkIGRhdGEgaW5zdGVhZCBvZiBy
ZWFkeSBtZXNzYWdlDQooY29tbWFuZCBydW4gd2FzOiBleGVjIHNzaCBsb2Nh
bGhvc3QgeGwgbWlncmF0ZS1yZWNlaXZlIC1kICkNCm1pZ3JhdGlvbiB0YXJn
ZXQ6IFRyYW5zZmVyIGNvbXBsZXRlLCByZXF1ZXN0aW5nIHBlcm1pc3Npb24g
dG8gc3RhcnQgZG9tYWluLg0KbGlieGw6IGVycm9yOiBsaWJ4bF91dGlscy5j
OjM5NjpsaWJ4bF9yZWFkX2V4YWN0bHk6IGZpbGUvc3RyZWFtIHRydW5jYXRl
ZCByZWFkaW5nIEdPIG1lc3NhZ2UgZnJvbSBtaWdyYXRpb24gc3RyZWFtDQpt
aWdyYXRpb24gdGFyZ2V0OiBGYWlsdXJlLCBkZXN0cm95aW5nIG91ciBjb3B5
Lg0KbWlncmF0aW9uIHRhcmdldDogQ2xlYW51cCBPSywgZ3JhbnRpbmcgc2Vu
ZGVyIHBlcm1pc3Npb24gdG8gcmVzdW1lLg0KTWlncmF0aW9uIGZhaWxlZCwg
cmVzdW1pbmcgYXQgc2VuZGVyLg0K

--8323329-2129309582-1416684261=:26346
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xl.-v.fail.4.5
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xl.-v.fail.4.5

bWlncmF0aW9uIHRhcmdldDogUmVhZHkgdG8gcmVjZWl2ZSBkb21haW4uDQpT
YXZpbmcgdG8gbWlncmF0aW9uIHN0cmVhbSBuZXcgeGwgZm9ybWF0IChpbmZv
IDB4MS8weDAvMTE4MikNCkxvYWRpbmcgbmV3IHNhdmUgZmlsZSA8aW5jb21p
bmcgbWlncmF0aW9uIHN0cmVhbT4gKG5ldyB4bCBmbXQgaW5mbyAweDEvMHgw
LzExODIpDQogU2F2ZWZpbGUgY29udGFpbnMgeGwgZG9tYWluIGNvbmZpZyBp
biBKU09OIGZvcm1hdA0KeGM6IGRldGFpbDogeGNfZG9tYWluX3NhdmU6IHN0
YXJ0aW5nIHNhdmUgb2YgZG9taWQgNA0KeGM6IGRldGFpbDogSGFkIDAgdW5l
eHBsYWluZWQgZW50cmllcyBpbiBwMm0gdGFibGUNCnhjOiBkZXRhaWw6IHhj
X2RvbWFpbl9yZXN0b3JlOiBzdGFydGluZyByZXN0b3JlIG9mIG5ldyBkb21p
ZCA2DQp4YzogZGV0YWlsOiB4Y19kb21haW5fcmVzdG9yZTogcDJtX3NpemUg
PSA0MDAwMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsg
Zmlyc3QgcGZuIDANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MjE7IGZpcnN0IHBmbiA0MDANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIg
MCwgIDEwMjQ7IGZpcnN0IHBmbiA4MDANCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDk1MDsgZmlyc3QgcGZuIGMwMA0KeGM6IGRldGFpbDogTWFw
cGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDEwMDANCnhjOiBkZXRh
aWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxNDAwDQp4
YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDIyOyBmaXJzdCBwZm4g
MTgwMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAxNzsgZmly
c3QgcGZuIDFjMDENCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MTg7IGZpcnN0IHBmbiAyMDBkDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICAxMDI0OyBmaXJzdCBwZm4gMjQwZA0KeGM6IGRldGFpbDogTWFwcGlu
ZyBvcmRlciAwLCAgODI4OyBmaXJzdCBwZm4gMjgwZA0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAwNjsgZmlyc3QgcGZuIDJjMGQNCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAzMDBk
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDE2OyBmaXJzdCBw
Zm4gMzQwZg0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyMjsg
Zmlyc3QgcGZuIDM4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwg
IDkwMTsgZmlyc3QgcGZuIDNjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiA0MDEwDQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gNDQxMA0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDQ4MTANCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiA0
YzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJz
dCBwZm4gNTAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAy
NDsgZmlyc3QgcGZuIDU0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIg
MCwgIDEwMjQ7IGZpcnN0IHBmbiA1ODEwDQp4YzogZGV0YWlsOiBNYXBwaW5n
IG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gNWMxMA0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDYwMTANCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiA2NDEw
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBw
Zm4gNjgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsg
Zmlyc3QgcGZuIDZjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwg
IDEwMjQ7IGZpcnN0IHBmbiA3MDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9y
ZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gNzQxMA0KeGM6IGRldGFpbDogTWFw
cGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDc4MTANCnhjOiBkZXRh
aWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiA3YzEwDQp4
YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4g
ODAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmly
c3QgcGZuIDg0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MjQ7IGZpcnN0IHBmbiA4ODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICAxMDI0OyBmaXJzdCBwZm4gOGMxMA0KeGM6IGRldGFpbDogTWFwcGlu
ZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDkwMTANCnhjOiBkZXRhaWw6
IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiA5NDEwDQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gOTgx
MA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3Qg
cGZuIDljMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7
IGZpcnN0IHBmbiBhMDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICAxMDI0OyBmaXJzdCBwZm4gYTQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBv
cmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIGE4MTANCnhjOiBkZXRhaWw6IE1h
cHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiBhYzEwDQp4YzogZGV0
YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gYjAxMA0K
eGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZu
IGI0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZp
cnN0IHBmbiBiODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAx
MDI0OyBmaXJzdCBwZm4gYmMxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRl
ciAwLCAgMTAyNDsgZmlyc3QgcGZuIGMwMTANCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiBjNDEwDQp4YzogZGV0YWls
OiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gYzgxMA0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIGNj
MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0
IHBmbiBkMDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0
OyBmaXJzdCBwZm4gZDQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgMTAyNDsgZmlyc3QgcGZuIGQ4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiBkYzEwDQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gZTAxMA0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIGU0MTAN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBm
biBlODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBm
aXJzdCBwZm4gZWMxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
MTAyNDsgZmlyc3QgcGZuIGYwMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiBmNDEwDQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gZjgxMA0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIGZjMTANCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAx
MDAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmly
c3QgcGZuIDEwNDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAx
MDI0OyBmaXJzdCBwZm4gMTA4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxMGMxMA0KeGM6IGRldGFpbDogTWFw
cGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDExMDEwDQp4YzogZGV0
YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTE0MTAN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBm
biAxMTgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsg
Zmlyc3QgcGZuIDExYzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICAxMDI0OyBmaXJzdCBwZm4gMTIwMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxMjQxMA0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDEyODEwDQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTJj
MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0
IHBmbiAxMzAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAy
NDsgZmlyc3QgcGZuIDEzNDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICAxMDI0OyBmaXJzdCBwZm4gMTM4MTANCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxM2MxMA0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDE0MDEwDQp4
YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4g
MTQ0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZp
cnN0IHBmbiAxNDgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
MTAyNDsgZmlyc3QgcGZuIDE0YzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9y
ZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTUwMTANCnhjOiBkZXRhaWw6IE1h
cHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxNTQxMA0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDE1ODEw
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBw
Zm4gMTVjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7
IGZpcnN0IHBmbiAxNjAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgMTAyNDsgZmlyc3QgcGZuIDE2NDEwDQp4YzogZGV0YWlsOiBNYXBwaW5n
IG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTY4MTANCnhjOiBkZXRhaWw6
IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxNmMxMA0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDE3
MDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJz
dCBwZm4gMTc0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MjQ7IGZpcnN0IHBmbiAxNzgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRl
ciAwLCAgMTAyNDsgZmlyc3QgcGZuIDE3YzEwDQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTgwMTANCnhjOiBkZXRh
aWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxODQxMA0K
eGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZu
IDE4ODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBm
aXJzdCBwZm4gMThjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwg
IDEwMjQ7IGZpcnN0IHBmbiAxOTAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBv
cmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDE5NDEwDQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTk4MTANCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxOWMx
MA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3Qg
cGZuIDFhMDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0
OyBmaXJzdCBwZm4gMWE0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIg
MCwgIDEwMjQ7IGZpcnN0IHBmbiAxYTgxMA0KeGM6IGRldGFpbDogTWFwcGlu
ZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDFhYzEwDQp4YzogZGV0YWls
OiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMWIwMTANCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAx
YjQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmly
c3QgcGZuIDFiODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAx
MDI0OyBmaXJzdCBwZm4gMWJjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxYzAxMA0KeGM6IGRldGFpbDogTWFw
cGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDFjNDEwDQp4YzogZGV0
YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMWM4MTAN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBm
biAxY2MxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsg
Zmlyc3QgcGZuIDFkMDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICAxMDI0OyBmaXJzdCBwZm4gMWQ0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxZDgxMA0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDFkYzEwDQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMWUw
MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0
IHBmbiAxZTQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAy
NDsgZmlyc3QgcGZuIDFlODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICAxMDI0OyBmaXJzdCBwZm4gMWVjMTANCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxZjAxMA0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDFmNDEwDQp4
YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4g
MWY4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZp
cnN0IHBmbiAxZmMxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
MTAyNDsgZmlyc3QgcGZuIDIwMDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9y
ZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjA0MTANCnhjOiBkZXRhaWw6IE1h
cHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyMDgxMA0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDIwYzEw
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBw
Zm4gMjEwMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7
IGZpcnN0IHBmbiAyMTQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgMTAyNDsgZmlyc3QgcGZuIDIxODEwDQp4YzogZGV0YWlsOiBNYXBwaW5n
IG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjFjMTANCnhjOiBkZXRhaWw6
IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyMjAxMA0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDIy
NDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJz
dCBwZm4gMjI4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MjQ7IGZpcnN0IHBmbiAyMmMxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRl
ciAwLCAgMTAyNDsgZmlyc3QgcGZuIDIzMDEwDQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjM0MTANCnhjOiBkZXRh
aWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyMzgxMA0K
eGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZu
IDIzYzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBm
aXJzdCBwZm4gMjQwMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwg
IDEwMjQ7IGZpcnN0IHBmbiAyNDQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBv
cmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDI0ODEwDQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjRjMTANCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyNTAx
MA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3Qg
cGZuIDI1NDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0
OyBmaXJzdCBwZm4gMjU4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIg
MCwgIDEwMjQ7IGZpcnN0IHBmbiAyNWMxMA0KeGM6IGRldGFpbDogTWFwcGlu
ZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDI2MDEwDQp4YzogZGV0YWls
OiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjY0MTANCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAy
NjgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmly
c3QgcGZuIDI2YzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAx
MDI0OyBmaXJzdCBwZm4gMjcwMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyNzQxMA0KeGM6IGRldGFpbDogTWFw
cGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDI3ODEwDQp4YzogZGV0
YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjdjMTAN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBm
biAyODAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsg
Zmlyc3QgcGZuIDI4NDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICAxMDI0OyBmaXJzdCBwZm4gMjg4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyOGMxMA0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDI5MDEwDQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjk0
MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0
IHBmbiAyOTgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAy
NDsgZmlyc3QgcGZuIDI5YzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICAxMDI0OyBmaXJzdCBwZm4gMmEwMTANCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyYTQxMA0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDJhODEwDQp4
YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4g
MmFjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZp
cnN0IHBmbiAyYjAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
MTAyNDsgZmlyc3QgcGZuIDJiNDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9y
ZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMmI4MTANCnhjOiBkZXRhaWw6IE1h
cHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyYmMxMA0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDJjMDEw
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBw
Zm4gMmM0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7
IGZpcnN0IHBmbiAyYzgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgMTAyNDsgZmlyc3QgcGZuIDJjYzEwDQp4YzogZGV0YWlsOiBNYXBwaW5n
IG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMmQwMTANCnhjOiBkZXRhaWw6
IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyZDQxMA0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDJk
ODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDIxOyBmaXJz
dCBwZm4gMmRjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MDA7IGZpcnN0IHBmbiAyZTAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRl
ciAwLCAgMTY1OyBmaXJzdCBwZm4gMmU0MTMNCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDMzMzsgZmlyc3QgcGZuIDJlODEzDQp4YzogZGV0YWls
OiBNYXBwaW5nIG9yZGVyIDAsICA2MDM7IGZpcnN0IHBmbiAyZWMxMw0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTczOyBmaXJzdCBwZm4gMmYw
MTMNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDg2NjsgZmlyc3Qg
cGZuIDJmNDEzDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5MDQ7
IGZpcnN0IHBmbiAyZjgxNA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgOTMwOyBmaXJzdCBwZm4gMmZjMTgNCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDk0MTsgZmlyc3QgcGZuIDMwMDIyDQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICA5ODM7IGZpcnN0IHBmbiAzMDQyNA0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTc2OyBmaXJzdCBwZm4gMzA4MjQN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDk3MzsgZmlyc3QgcGZu
IDMwYzI0DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5Nzc7IGZp
cnN0IHBmbiAzMTAyNA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
OTc2OyBmaXJzdCBwZm4gMzE0MjQNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDk5NDsgZmlyc3QgcGZuIDMxODI3DQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICA5MTc7IGZpcnN0IHBmbiAzMWMyNw0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgODcwOyBmaXJzdCBwZm4gMzIwMjcNCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDk2ODsgZmlyc3QgcGZuIDMy
NDI3DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA4ODQ7IGZpcnN0
IHBmbiAzMjgyNw0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTUx
OyBmaXJzdCBwZm4gMzJjMjcNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIg
MCwgIDk0OTsgZmlyc3QgcGZuIDMzMDI3DQp4YzogZGV0YWlsOiBNYXBwaW5n
IG9yZGVyIDAsICA5OTg7IGZpcnN0IHBmbiAzMzQyNw0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAxMTsgZmlyc3QgcGZuIDMzODI3DQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5MTA7IGZpcnN0IHBmbiAzM2My
Yg0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTA4OyBmaXJzdCBw
Zm4gMzQwMmINCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDcwODsg
Zmlyc3QgcGZuIDM0NDM0DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICA4MzU7IGZpcnN0IHBmbiAzNDgzNA0KeGM6IGRldGFpbDogTWFwcGluZyBv
cmRlciAwLCAgNzExOyBmaXJzdCBwZm4gMzRjMzQNCnhjOiBkZXRhaWw6IE1h
cHBpbmcgb3JkZXIgMCwgIDUyNTsgZmlyc3QgcGZuIDM1MDM0DQp4YzogZGV0
YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA2Mzc7IGZpcnN0IHBmbiAzNTQzNA0K
eGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgNzEyOyBmaXJzdCBwZm4g
MzU4MzQNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDk1NjsgZmly
c3QgcGZuIDM1YzM5DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA2
Njg7IGZpcnN0IHBmbiAzNjAzNQ0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRl
ciAwLCAgODYyOyBmaXJzdCBwZm4gMzY0MzUNCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDkyNzsgZmlyc3QgcGZuIDM2ODM1DQp4YzogZGV0YWls
OiBNYXBwaW5nIG9yZGVyIDAsICA5Mzg7IGZpcnN0IHBmbiAzNmMzNQ0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTA4OyBmaXJzdCBwZm4gMzcw
MzUNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDg4MDsgZmlyc3Qg
cGZuIDM3NDM1DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5NTg7
IGZpcnN0IHBmbiAzNzgzNQ0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgOTIwOyBmaXJzdCBwZm4gMzdjMzUNCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDg1MDsgZmlyc3QgcGZuIDM4MDM2DQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICA5NjY7IGZpcnN0IHBmbiAzODQzNg0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTcxOyBmaXJzdCBwZm4gMzg4M2IN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDk5MTsgZmlyc3QgcGZu
IDM4YzNhDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5NTE7IGZp
cnN0IHBmbiAzOTA0MQ0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
ODM4OyBmaXJzdCBwZm4gMzk0M2UNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDgxMzsgZmlyc3QgcGZuIDM5ODNlDQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICA4Mzc7IGZpcnN0IHBmbiAzOWMzZQ0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgNzg0OyBmaXJzdCBwZm4gM2EwM2UNCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDgwNjsgZmlyc3QgcGZuIDNh
NDU4DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA4ODY7IGZpcnN0
IHBmbiAzYTg0Mg0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAy
MjsgZmlyc3QgcGZuIDNhYzQyDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICA5NDA7IGZpcnN0IHBmbiAzYjA0Mg0KeGM6IGRldGFpbDogTWFwcGlu
ZyBvcmRlciAwLCAgOTU4OyBmaXJzdCBwZm4gM2I0NDINCnhjOiBkZXRhaWw6
IE1hcHBpbmcgb3JkZXIgMCwgIDk4MDsgZmlyc3QgcGZuIDNiODQ0DQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA3NTc7IGZpcnN0IHBmbiAzYmM2
MA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgNDY2OyBmaXJzdCBw
Zm4gM2NhMDANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDkyNTsg
Zmlyc3QgcGZuIDNjY2ExDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICAxMDI0OyBmaXJzdCBwZm4gM2QwYWUNCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDk2MTsgZmlyc3QgcGZuIDNkNGFmDQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICAxMDIzOyBmaXJzdCBwZm4gM2Q4YmENCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDkzNjsgZmlyc3QgcGZuIDNkY2Nj
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5MDA7IGZpcnN0IHBm
biAzZTBkMw0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgODIzOyBm
aXJzdCBwZm4gM2U0ZTINCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwg
IDEwMjQ7IGZpcnN0IHBmbiAzZThkNw0KeGM6IGRldGFpbDogTWFwcGluZyBv
cmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDNlY2Q3DQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gM2YwZDcNCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDg4NjsgZmlyc3QgcGZuIDNmNGQ3
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5MjI7IGZpcnN0IHBm
biAzZjhmNA0KeGM6IGRldGFpbDogZGVsdGEgMTU4MDFtcywgZG9tMCA5NSUs
IHRhcmdldCAwJSwgc2VudCA1NDNNYi9zLCBkaXJ0aWVkIDBNYi9zIDMxNCBw
YWdlcw0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMjY4OyBmaXJz
dCBwZm4gM2ZjZjQNCnhjOiBkZXRhaWw6IGRlbHRhIDIzbXMsIGRvbTAgMTAw
JSwgdGFyZ2V0IDAlLCBzZW50IDQ0N01iL3MsIGRpcnRpZWQgME1iL3MgMCBw
YWdlcw0KeGM6IGRldGFpbDogU3RhcnQgbGFzdCBpdGVyYXRpb24NCnhjOiBS
ZWxvYWRpbmcgbWVtb3J5IHBhZ2VzOiAyNjIyMTMvMjYyMTQ0ICAxMDAleGM6
IGRldGFpbDogU1VTUEVORCBzaGluZm8gMDAwODJmYmMNCnhjOiBkZXRhaWw6
IGRlbHRhIDE3bXMsIGRvbTAgNTglLCB0YXJnZXQgNTglLCBzZW50IDBNYi9z
LCBkaXJ0aWVkIDEwMzNNYi9zIDUzNiBwYWdlcw0KeGM6IGRldGFpbDogZGVs
dGEgOG1zLCBkb20wIDEwMCUsIHRhcmdldCAwJSwgc2VudCAyMTk1TWIvcywg
ZGlydGllZCAyMTk1TWIvcyA1MzYgcGFnZXMNCnhjOiBkZXRhaWw6IFRvdGFs
IHBhZ2VzIHNlbnQ9IDI2Mjc0OSAoMS4wMHgpDQp4YzogZGV0YWlsOiAob2Yg
d2hpY2ggMCB3ZXJlIGZpeHVwcykNCnhjOiBkZXRhaWw6IEFsbCBtZW1vcnkg
aXMgc2F2ZWQNCnhjOiBlcnJvcjogRXJyb3IgcXVlcnlpbmcgbWF4aW11bSBu
dW1iZXIgb2YgTVNScyBmb3IgVkNQVTAgKDEgPSBPcGVyYXRpb24gbm90IHBl
cm1pdHRlZCk6IEludGVybmFsIGVycm9yDQp4YzogZGV0YWlsOiBTYXZlIGV4
aXQgb2YgZG9taWQgNCB3aXRoIGVycm5vPTENCmxpYnhsOiBlcnJvcjogbGli
eGxfZG9tLmM6MTg2NDpsaWJ4bF9feGNfZG9tYWluX3NhdmVfZG9uZTogc2F2
aW5nIGRvbWFpbjogZG9tYWluIHJlc3BvbmRlZCB0byBzdXNwZW5kIHJlcXVl
c3Q6IE9wZXJhdGlvbiBub3QgcGVybWl0dGVkDQpsaWJ4bDogZXJyb3I6IGxp
YnhsX2RvbS5jOjIwMjE6cmVtdXNfdGVhcmRvd25fZG9uZTogUmVtdXM6IGZh
aWxlZCB0byB0ZWFyZG93biBkZXZpY2UgZm9yIGd1ZXN0IHdpdGggZG9taWQg
NCwgcmMgLTMNCm1pZ3JhdGlvbiBzZW5kZXI6IGxpYnhsX2RvbWFpbl9zdXNw
ZW5kIGZhaWxlZCAocmM9LTMpDQp4YzogZXJyb3I6IDAtbGVuZ3RoIHJlYWQ6
IEludGVybmFsIGVycm9yICAgICAgIA0KeGM6IGVycm9yOiByZGV4YWN0IGZh
aWxlZCAocmVhZCByYzogMCwgZXJybm86IDApOiBJbnRlcm5hbCBlcnJvcg0K
eGM6IGVycm9yOiBFcnJvciB3aGVuIHJlYWRpbmcgc2hhcmVkIGluZm8gcGFn
ZSAoMCA9IFN1Y2Nlc3MpOiBJbnRlcm5hbCBlcnJvcg0KeGM6IGVycm9yOiBl
cnJvciBidWZmZXJpbmcgaW1hZ2UgdGFpbDogSW50ZXJuYWwgZXJyb3INCnhj
OiBkZXRhaWw6IFJlc3RvcmUgZXhpdCBvZiBkb21pZCA2IHdpdGggcmM9MSAg
DQpsaWJ4bDogZXJyb3I6IGxpYnhsX2NyZWF0ZS5jOjEwMzI6bGlieGxfX3hj
X2RvbWFpbl9yZXN0b3JlX2RvbmU6IHJlc3RvcmluZyBkb21haW46IFJlc291
cmNlIHRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlDQpsaWJ4bDogZXJyb3I6IGxp
YnhsX2NyZWF0ZS5jOjExMDQ6ZG9tY3JlYXRlX3JlYnVpbGRfZG9uZTogY2Fu
bm90IChyZS0pYnVpbGQgZG9tYWluOiAtMw0KbGlieGw6IGVycm9yOiBsaWJ4
bC5jOjE1NDI6bGlieGxfX2Rlc3Ryb3lfZG9taWQ6IG5vbi1leGlzdGFudCBk
b21haW4gNg0KbGlieGw6IGVycm9yOiBsaWJ4bC5jOjE1MDY6ZG9tYWluX2Rl
c3Ryb3lfY2FsbGJhY2s6IHVuYWJsZSB0byBkZXN0cm95IGd1ZXN0IHdpdGgg
ZG9taWQgNg0KbGlieGw6IGVycm9yOiBsaWJ4bF9jcmVhdGUuYzoxNDYyOmRv
bWNyZWF0ZV9kZXN0cnVjdGlvbl9jYjogdW5hYmxlIHRvIGRlc3Ryb3kgZG9t
YWluIDYgZm9sbG93aW5nIGZhaWxlZCBjcmVhdGlvbg0KbWlncmF0aW9uIHRh
cmdldDogRG9tYWluIGNyZWF0aW9uIGZhaWxlZCAoY29kZSAtMykuDQpsaWJ4
bDogaW5mbzogbGlieGxfZXhlYy5jOjExODpsaWJ4bF9yZXBvcnRfY2hpbGRf
ZXhpdHN0YXR1czogbWlncmF0aW9uIHRyYW5zcG9ydCBwcm9jZXNzIFs1MzI2
XSBleGl0ZWQgd2l0aCBlcnJvciBzdGF0dXMgMw0KTWlncmF0aW9uIGZhaWxl
ZCwgcmVzdW1pbmcgYXQgc2VuZGVyLg0K

--8323329-2129309582-1416684261=:26346
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-2129309582-1416684261=:26346--


From xen-devel-bounces@lists.xen.org Sat Nov 22 19:25:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 19:25:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsGIU-0006Fk-BL; Sat, 22 Nov 2014 19:24:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XsGIS-0006Ff-Em
	for xen-devel@lists.xen.org; Sat, 22 Nov 2014 19:24:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	97/DD-15461-7F2E0745; Sat, 22 Nov 2014 19:24:39 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416684278!14621400!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15586 invoked from network); 22 Nov 2014 19:24:38 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2014 19:24:38 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAMJOQmY010138
	for <xen-devel@lists.xen.org>; Sat, 22 Nov 2014 19:24:30 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAMJOLW4029131
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Sat, 22 Nov 2014 19:24:21 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAMJOLik025658
	for <xen-devel@lists.xen.org>; Sat, 22 Nov 2014 19:24:21 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAMJOLgv025654
	for <xen-devel@lists.xen.org>; Sat, 22 Nov 2014 19:24:21 GMT
Date: Sat, 22 Nov 2014 19:24:21 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-2129309582-1416684261=:26346"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAMJOQmY010138
Subject: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-2129309582-1416684261=:26346
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

While investigating a bug reported on Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1166461
I discovered the following

xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the 
bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. 
There are actually two issues here

* the segfault in libxl-save-helper --restore-domain (as reported in the 
bug above) occurs if the guest memory is 1024M (on my 4G box) and is 
presumably because the allocated memory eventually runs out

* the segfault doesn't occur if the guest memory is 128M, but the 
migration still fails. The first attached file contains the log from a run 
with xl -v migrate --debug domid localhost (with mfn and duplicated lines 
stripped out to make the size manageable).

I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl 
migrate doesn't work for me at all - see the second attached file for the 
output of xl -v migrate domid localhost .

 	Mchael Young
--8323329-2129309582-1416684261=:26346
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xl.-v.--debug.fail.4.4
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xl.-v.--debug.fail.4.4

bWlncmF0aW9uIHRhcmdldDogUmVhZHkgdG8gcmVjZWl2ZSBkb21haW4uDQpT
YXZpbmcgdG8gbWlncmF0aW9uIHN0cmVhbSBuZXcgeGwgZm9ybWF0IChpbmZv
IDB4MC8weDAvMTI5NCkNCkxvYWRpbmcgbmV3IHNhdmUgZmlsZSA8aW5jb21p
bmcgbWlncmF0aW9uIHN0cmVhbT4gKG5ldyB4bCBmbXQgaW5mbyAweDAvMHgw
LzEyOTQpDQogU2F2ZWZpbGUgY29udGFpbnMgeGwgZG9tYWluIGNvbmZpZw0K
eGM6IGRldGFpbDogeGNfZG9tYWluX3NhdmU6IHN0YXJ0aW5nIHNhdmUgb2Yg
ZG9taWQgMjMNCnhjOiBkZXRhaWw6IEhhZCAwIHVuZXhwbGFpbmVkIGVudHJp
ZXMgaW4gcDJtIHRhYmxlDQp4YzogZGV0YWlsOiANCnhjOiBwcm9ncmVzczog
UmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMjA0OC8zMjc2OCAgICA2JQ0KeGM6
IGRldGFpbDogDQp4YzogcHJvZ3Jlc3M6IFJlbG9hZGluZyBtZW1vcnkgcGFn
ZXM6IDYxNDQvMzI3NjggICAxOCUNCnhjOiBkZXRhaWw6IA0KeGM6IHhjOiBk
ZXRhaWw6IA0KeGM6IGRldGFpbDogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczog
ODE5Mi8zMjc2OCAgIDI1JQ0KDQp4YzogZGV0YWlsOiANCnhjOiB4YzogcHJv
Z3Jlc3M6IFJlbG9hZGluZyBtZW1vcnkgcGFnZXM6IDEwMjQwLzMyNzY4ICAg
MzElDQp4YzogZGV0YWlsOiANCnhjOiB4YzogcHJvZ3Jlc3M6IFJlbG9hZGlu
ZyBtZW1vcnkgcGFnZXM6IDE0MzM2LzMyNzY4ICAgNDMlDQp4YzogZGV0YWls
OiANCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMTYz
ODQvMzI3NjggICA1MCUNCnhjOiBkZXRhaWw6IA0KeGM6IHByb2dyZXNzOiBS
ZWxvYWRpbmcgbWVtb3J5IHBhZ2VzOiAxODQzMi8zMjc2OCAgIDU2JQ0KeGM6
IGRldGFpbDogDQp4YzogeGM6IHByb2dyZXNzOiBSZWxvYWRpbmcgbWVtb3J5
IHBhZ2VzOiAyMDQ4MC8zMjc2OCAgIDYyJQ0KZGV0YWlsOiANCnhjOiBkZXRh
aWw6IA0KeGM6IHByb2dyZXNzOiBSZWxvYWRpbmcgbWVtb3J5IHBhZ2VzOiAy
MjUyOC8zMjc2OCAgIDY4JQ0KeGM6IGRldGFpbDogDQp4YzogeGM6IHByb2dy
ZXNzOiBSZWxvYWRpbmcgbWVtb3J5IHBhZ2VzOiAyNDU3Ni8zMjc2OCAgIDc1
JQ0KZGV0YWlsOiANCnhjOiBkZXRhaWw6IA0KeGM6IHhjOiBkZXRhaWw6IA0K
UmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMjY2MjQvMzI3NjggICA4MSV4Yzog
ZGV0YWlsOiANCnhjOiANCnhjOiBkZXRhaWw6IA0KeGM6IHhjOiBwcm9ncmVz
czogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMjg2NzIvMzI3NjggICA4NyUN
CmRldGFpbDogDQp4YzogZGV0YWlsOiANCnhjOiBwcm9ncmVzczogUmVsb2Fk
aW5nIG1lbW9yeSBwYWdlczogMzA3MjAvMzI3NjggICA5MyUNCnhjOiBkZXRh
aWw6IA0KeGM6IGRldGFpbDogZGVsdGEgNDU5OW1zLCBkb20wIDk2JSwgdGFy
Z2V0IDAlLCBzZW50IDIzMk1iL3MsIGRpcnRpZWQgME1iL3MgODIgcGFnZXMN
CnhjOiBkZXRhaWw6IA0KcHJvZ3Jlc3M6IFJlbG9hZGluZyBtZW1vcnkgcGFn
ZXM6IDMyNjg3LzMyNzY4ICAgOTklDQp4YzogZGV0YWlsOiANCnhjOiBkZXRh
aWw6IGRlbHRhIDE2NTltcywgZG9tMCA5MCUsIHRhcmdldCAwJSwgc2VudCAx
TWIvcywgZGlydGllZCAxTWIvcyA4MiBwYWdlcw0KeGM6IGRldGFpbDogDQp4
YzogZGV0YWlsOiBkZWx0YSAxNjcwbXMsIGRvbTAgODUlLCB0YXJnZXQgMCUs
IHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1iL3MgODEgcGFnZXMNCnhjOiBkZXRh
aWw6IA0KeGM6IGRldGFpbDogZGVsdGEgMTY3OW1zLCBkb20wIDg1JSwgdGFy
Z2V0IDAlLCBzZW50IDFNYi9zLCBkaXJ0aWVkIDFNYi9zIDczIHBhZ2VzDQp4
YzogZGV0YWlsOiANCnhjOiBkZXRhaWw6IGRlbHRhIDE2NjZtcywgZG9tMCA4
NiUsIHRhcmdldCAwJSwgc2VudCAxTWIvcywgZGlydGllZCAxTWIvcyA4MSBw
YWdlcw0KeGM6IGRldGFpbDogDQp4YzogZGV0YWlsOiBkZWx0YSAxNjgzbXMs
IGRvbTAgODUlLCB0YXJnZXQgMCUsIHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1i
L3MgNzMgcGFnZXMNCnhjOiBkZXRhaWw6IA0KeGM6IGRldGFpbDogZGVsdGEg
MTY3NG1zLCBkb20wIDg1JSwgdGFyZ2V0IDAlLCBzZW50IDFNYi9zLCBkaXJ0
aWVkIDFNYi9zIDgzIHBhZ2VzDQp4YzogZGV0YWlsOiANCnhjOiBkZXRhaWw6
IGRlbHRhIDE2NzhtcywgZG9tMCA4NSUsIHRhcmdldCAwJSwgc2VudCAxTWIv
cywgZGlydGllZCAxTWIvcyA4MiBwYWdlcw0KeGM6IGRldGFpbDogDQp4Yzog
ZGV0YWlsOiBkZWx0YSAxNjc2bXMsIGRvbTAgODUlLCB0YXJnZXQgMCUsIHNl
bnQgMU1iL3MsIGRpcnRpZWQgMU1iL3MgNzMgcGFnZXMNCnhjOiBkZXRhaWw6
IA0KeGM6IGRldGFpbDogZGVsdGEgMTY4OW1zLCBkb20wIDg3JSwgdGFyZ2V0
IDAlLCBzZW50IDFNYi9zLCBkaXJ0aWVkIDFNYi9zIDgyIHBhZ2VzDQp4Yzog
ZGV0YWlsOiANCnhjOiBkZXRhaWw6IGRlbHRhIDE2ODRtcywgZG9tMCA4NSUs
IHRhcmdldCAwJSwgc2VudCAxTWIvcywgZGlydGllZCAxTWIvcyA3MyBwYWdl
cw0KeGM6IGRldGFpbDogDQp4YzogZGV0YWlsOiBkZWx0YSAxNjc4bXMsIGRv
bTAgODYlLCB0YXJnZXQgMCUsIHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1iL3Mg
ODEgcGFnZXMNCnhjOiBkZXRhaWw6IA0KeGM6IGRldGFpbDogZGVsdGEgMTY2
NG1zLCBkb20wIDg2JSwgdGFyZ2V0IDAlLCBzZW50IDFNYi9zLCBkaXJ0aWVk
IDFNYi9zIDc1IHBhZ2VzDQp4YzogZGV0YWlsOiANCnhjOiBkZXRhaWw6IGRl
bHRhIDE3MDFtcywgZG9tMCA4NiUsIHRhcmdldCAwJSwgc2VudCAxTWIvcywg
ZGlydGllZCAxTWIvcyA5MCBwYWdlcw0KeGM6IGRldGFpbDogDQp4YzogZGV0
YWlsOiBkZWx0YSAxNjc4bXMsIGRvbTAgODclLCB0YXJnZXQgMCUsIHNlbnQg
MU1iL3MsIGRpcnRpZWQgMU1iL3MgNzQgcGFnZXMNCnhjOiBkZXRhaWw6IA0K
eGM6IGRldGFpbDogZGVsdGEgMTY1MW1zLCBkb20wIDg5JSwgdGFyZ2V0IDAl
LCBzZW50IDFNYi9zLCBkaXJ0aWVkIDFNYi9zIDc1IHBhZ2VzDQp4YzogZGV0
YWlsOiANCnhjOiBkZXRhaWw6IGRlbHRhIDE2NzdtcywgZG9tMCA4NSUsIHRh
cmdldCAwJSwgc2VudCAxTWIvcywgZGlydGllZCAxTWIvcyA4MSBwYWdlcw0K
eGM6IGRldGFpbDogDQp4YzogZGV0YWlsOiBkZWx0YSAxNjQ0bXMsIGRvbTAg
ODklLCB0YXJnZXQgMCUsIHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1iL3MgNzMg
cGFnZXMNCnhjOiBkZXRhaWw6IA0KDQp4YzogZGV0YWlsOiANCnhjOiBkZXRh
aWw6IGRlbHRhIDE2NTZtcywgZG9tMCA4NyUsIHRhcmdldCAwJSwgc2VudCAx
TWIvcywgZGlydGllZCAxTWIvcyA4MiBwYWdlcw0KeGM6IGRldGFpbDogDQp4
YzogZGV0YWlsOiBkZWx0YSAxNjQ3bXMsIGRvbTAgODglLCB0YXJnZXQgMCUs
IHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1iL3MgODMgcGFnZXMNCnhjOiBkZXRh
aWw6IA0KeGM6IGRldGFpbDogZGVsdGEgMTY2MG1zLCBkb20wIDg2JSwgdGFy
Z2V0IDAlLCBzZW50IDFNYi9zLCBkaXJ0aWVkIDFNYi9zIDc0IHBhZ2VzDQp4
YzogZGV0YWlsOiANCnhjOiBkZXRhaWw6IGRlbHRhIDI3NjBtcywgZG9tMCA5
OCUsIHRhcmdldCAwJSwgc2VudCAwTWIvcywgZGlydGllZCAwTWIvcyA4NCBw
YWdlcw0KeGM6IGRldGFpbDogDQp4YzogZGV0YWlsOiBkZWx0YSAxNjM1bXMs
IGRvbTAgOTElLCB0YXJnZXQgMCUsIHNlbnQgMU1iL3MsIGRpcnRpZWQgMU1i
L3MgODEgcGFnZXMNCnhjOiBkZXRhaWw6IA0KeGM6IGRldGFpbDogZGVsdGEg
MjAzNW1zLCBkb20wIDk2JSwgdGFyZ2V0IDAlLCBzZW50IDFNYi9zLCBkaXJ0
aWVkIDFNYi9zIDc1IHBhZ2VzDQp4YzogZGV0YWlsOiANCnhjOiBkZXRhaWw6
IGRlbHRhIDIyMThtcywgZG9tMCA5NyUsIHRhcmdldCAwJSwgc2VudCAxTWIv
cywgZGlydGllZCAxTWIvcyA5MCBwYWdlcw0KeGM6IGRldGFpbDogDQp4Yzog
ZGV0YWlsOiBkZWx0YSAxNjY2bXMsIGRvbTAgOTYlLCB0YXJnZXQgMCUsIHNl
bnQgMU1iL3MsIGRpcnRpZWQgMU1iL3MgNzMgcGFnZXMNCnhjOiBkZXRhaWw6
IA0KeGM6IGRldGFpbDogZGVsdGEgMTY4N21zLCBkb20wIDk5JSwgdGFyZ2V0
IDAlLCBzZW50IDFNYi9zLCBkaXJ0aWVkIDFNYi9zIDc0IHBhZ2VzDQp4Yzog
ZGV0YWlsOiANCnhjOiBkZXRhaWw6IGRlbHRhIDE3NjVtcywgZG9tMCA5NSUs
IHRhcmdldCAwJSwgc2VudCAxTWIvcywgZGlydGllZCAxTWIvcyA4MiBwYWdl
cw0KeGM6IGRldGFpbDogDQp4YzogZGV0YWlsOiBTdGFydCBsYXN0IGl0ZXJh
dGlvbg0KeGM6IGRldGFpbDogU1VTUEVORCBzaGluZm8gMDAwZGMwY2INCnhj
OiBkZXRhaWw6IGRlbHRhIDE5MDZtcywgZG9tMCA4NiUsIHRhcmdldCAwJSwg
c2VudCAxTWIvcywgZGlydGllZCAzTWIvcyAyMDggcGFnZXMNCnhjOiBkZXRh
aWw6IA0KeGM6IGRldGFpbDogZGVsdGEgMjQxN21zLCBkb20wIDkyJSwgdGFy
Z2V0IDAlLCBzZW50IDJNYi9zLCBkaXJ0aWVkIDJNYi9zIDIwOCBwYWdlcw0K
eGM6IGRldGFpbDogVG90YWwgcGFnZXMgc2VudD0gMzUxMDcgKDEuMDd4KQ0K
eGM6IGRldGFpbDogKG9mIHdoaWNoIDAgd2VyZSBmaXh1cHMpDQp4YzogZGV0
YWlsOiBFbnRlcmluZyBkZWJ1ZyByZXNlbmQtYWxsIG1vZGUNCnhjOiBwcm9n
cmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMzYxMzEvMzI3NjggIDEx
MCUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogMzgx
NzkvMzI3NjggIDExNiUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9y
eSBwYWdlczogNDAyMjcvMzI3NjggIDEyMiUNCnhjOiBwcm9ncmVzczogUmVs
b2FkaW5nIG1lbW9yeSBwYWdlczogNDIyNzUvMzI3NjggIDEyOSUNCnhjOiBw
cm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogNDQzMjMvMzI3Njgg
IDEzNSUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczog
NDYzNzEvMzI3NjggIDE0MSUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1l
bW9yeSBwYWdlczogNDg0MTkvMzI3NjggIDE0NyUNCnhjOiBwcm9ncmVzczog
UmVsb2FkaW5nIG1lbW9yeSBwYWdlczogNTA0NjcvMzI3NjggIDE1NCUNCnhj
OiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogNTI1MTUvMzI3
NjggIDE2MCUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdl
czogNTQ1NjMvMzI3NjggIDE2NiUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5n
IG1lbW9yeSBwYWdlczogNTY2MTEvMzI3NjggIDE3MiUNCnhjOiBwcm9ncmVz
czogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogNTg2NTkvMzI3NjggIDE3OSUN
CnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBwYWdlczogNjA3MDcv
MzI3NjggIDE4NSUNCnhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9yeSBw
YWdlczogNjI3NTUvMzI3NjggIDE5MSUNCnhjOiBwcm9ncmVzczogUmVsb2Fk
aW5nIG1lbW9yeSBwYWdlczogNjQ4MDMvMzI3NjggIDE5NyUNCnhjOiBkZXRh
aWw6IGRlbHRhIDE2NjJtcywgZG9tMCA5NSUsIHRhcmdldCAwJSwgc2VudCA2
NDZNYi9zLCBkaXJ0aWVkIDRNYi9zIDIwOCBwYWdlcw0KeGM6IGRldGFpbDog
VG90YWwgcGFnZXMgc2VudD0gNjc4NzUgKDIuMDd4KQ0KeGM6IGRldGFpbDog
KG9mIHdoaWNoIDAgd2VyZSBmaXh1cHMpDQp4YzogZGV0YWlsOiBBbGwgbWVt
b3J5IGlzIHNhdmVkDQp4YzogcHJvZ3Jlc3M6IFJlbG9hZGluZyBtZW1vcnkg
cGFnZXM6IDY2ODUxLzMyNzY4ICAyMDQlDQp4YzogZGV0YWlsOiBTYXZlIGV4
aXQgb2YgZG9taWQgMjMgd2l0aCByYz0wDQptaWdyYXRpb24gcmVjZWl2ZXIg
c3RyZWFtIGNvbnRhaW5lZCB1bmV4cGVjdGVkIGRhdGEgaW5zdGVhZCBvZiBy
ZWFkeSBtZXNzYWdlDQooY29tbWFuZCBydW4gd2FzOiBleGVjIHNzaCBsb2Nh
bGhvc3QgeGwgbWlncmF0ZS1yZWNlaXZlIC1kICkNCm1pZ3JhdGlvbiB0YXJn
ZXQ6IFRyYW5zZmVyIGNvbXBsZXRlLCByZXF1ZXN0aW5nIHBlcm1pc3Npb24g
dG8gc3RhcnQgZG9tYWluLg0KbGlieGw6IGVycm9yOiBsaWJ4bF91dGlscy5j
OjM5NjpsaWJ4bF9yZWFkX2V4YWN0bHk6IGZpbGUvc3RyZWFtIHRydW5jYXRl
ZCByZWFkaW5nIEdPIG1lc3NhZ2UgZnJvbSBtaWdyYXRpb24gc3RyZWFtDQpt
aWdyYXRpb24gdGFyZ2V0OiBGYWlsdXJlLCBkZXN0cm95aW5nIG91ciBjb3B5
Lg0KbWlncmF0aW9uIHRhcmdldDogQ2xlYW51cCBPSywgZ3JhbnRpbmcgc2Vu
ZGVyIHBlcm1pc3Npb24gdG8gcmVzdW1lLg0KTWlncmF0aW9uIGZhaWxlZCwg
cmVzdW1pbmcgYXQgc2VuZGVyLg0K

--8323329-2129309582-1416684261=:26346
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xl.-v.fail.4.5
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xl.-v.fail.4.5

bWlncmF0aW9uIHRhcmdldDogUmVhZHkgdG8gcmVjZWl2ZSBkb21haW4uDQpT
YXZpbmcgdG8gbWlncmF0aW9uIHN0cmVhbSBuZXcgeGwgZm9ybWF0IChpbmZv
IDB4MS8weDAvMTE4MikNCkxvYWRpbmcgbmV3IHNhdmUgZmlsZSA8aW5jb21p
bmcgbWlncmF0aW9uIHN0cmVhbT4gKG5ldyB4bCBmbXQgaW5mbyAweDEvMHgw
LzExODIpDQogU2F2ZWZpbGUgY29udGFpbnMgeGwgZG9tYWluIGNvbmZpZyBp
biBKU09OIGZvcm1hdA0KeGM6IGRldGFpbDogeGNfZG9tYWluX3NhdmU6IHN0
YXJ0aW5nIHNhdmUgb2YgZG9taWQgNA0KeGM6IGRldGFpbDogSGFkIDAgdW5l
eHBsYWluZWQgZW50cmllcyBpbiBwMm0gdGFibGUNCnhjOiBkZXRhaWw6IHhj
X2RvbWFpbl9yZXN0b3JlOiBzdGFydGluZyByZXN0b3JlIG9mIG5ldyBkb21p
ZCA2DQp4YzogZGV0YWlsOiB4Y19kb21haW5fcmVzdG9yZTogcDJtX3NpemUg
PSA0MDAwMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsg
Zmlyc3QgcGZuIDANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MjE7IGZpcnN0IHBmbiA0MDANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIg
MCwgIDEwMjQ7IGZpcnN0IHBmbiA4MDANCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDk1MDsgZmlyc3QgcGZuIGMwMA0KeGM6IGRldGFpbDogTWFw
cGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDEwMDANCnhjOiBkZXRh
aWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxNDAwDQp4
YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDIyOyBmaXJzdCBwZm4g
MTgwMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAxNzsgZmly
c3QgcGZuIDFjMDENCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MTg7IGZpcnN0IHBmbiAyMDBkDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICAxMDI0OyBmaXJzdCBwZm4gMjQwZA0KeGM6IGRldGFpbDogTWFwcGlu
ZyBvcmRlciAwLCAgODI4OyBmaXJzdCBwZm4gMjgwZA0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAwNjsgZmlyc3QgcGZuIDJjMGQNCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAzMDBk
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDE2OyBmaXJzdCBw
Zm4gMzQwZg0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyMjsg
Zmlyc3QgcGZuIDM4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwg
IDkwMTsgZmlyc3QgcGZuIDNjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiA0MDEwDQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gNDQxMA0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDQ4MTANCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiA0
YzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJz
dCBwZm4gNTAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAy
NDsgZmlyc3QgcGZuIDU0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIg
MCwgIDEwMjQ7IGZpcnN0IHBmbiA1ODEwDQp4YzogZGV0YWlsOiBNYXBwaW5n
IG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gNWMxMA0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDYwMTANCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiA2NDEw
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBw
Zm4gNjgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsg
Zmlyc3QgcGZuIDZjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwg
IDEwMjQ7IGZpcnN0IHBmbiA3MDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9y
ZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gNzQxMA0KeGM6IGRldGFpbDogTWFw
cGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDc4MTANCnhjOiBkZXRh
aWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiA3YzEwDQp4
YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4g
ODAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmly
c3QgcGZuIDg0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MjQ7IGZpcnN0IHBmbiA4ODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICAxMDI0OyBmaXJzdCBwZm4gOGMxMA0KeGM6IGRldGFpbDogTWFwcGlu
ZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDkwMTANCnhjOiBkZXRhaWw6
IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiA5NDEwDQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gOTgx
MA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3Qg
cGZuIDljMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7
IGZpcnN0IHBmbiBhMDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICAxMDI0OyBmaXJzdCBwZm4gYTQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBv
cmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIGE4MTANCnhjOiBkZXRhaWw6IE1h
cHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiBhYzEwDQp4YzogZGV0
YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gYjAxMA0K
eGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZu
IGI0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZp
cnN0IHBmbiBiODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAx
MDI0OyBmaXJzdCBwZm4gYmMxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRl
ciAwLCAgMTAyNDsgZmlyc3QgcGZuIGMwMTANCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiBjNDEwDQp4YzogZGV0YWls
OiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gYzgxMA0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIGNj
MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0
IHBmbiBkMDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0
OyBmaXJzdCBwZm4gZDQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgMTAyNDsgZmlyc3QgcGZuIGQ4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiBkYzEwDQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gZTAxMA0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIGU0MTAN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBm
biBlODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBm
aXJzdCBwZm4gZWMxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
MTAyNDsgZmlyc3QgcGZuIGYwMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiBmNDEwDQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gZjgxMA0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIGZjMTANCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAx
MDAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmly
c3QgcGZuIDEwNDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAx
MDI0OyBmaXJzdCBwZm4gMTA4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxMGMxMA0KeGM6IGRldGFpbDogTWFw
cGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDExMDEwDQp4YzogZGV0
YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTE0MTAN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBm
biAxMTgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsg
Zmlyc3QgcGZuIDExYzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICAxMDI0OyBmaXJzdCBwZm4gMTIwMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxMjQxMA0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDEyODEwDQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTJj
MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0
IHBmbiAxMzAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAy
NDsgZmlyc3QgcGZuIDEzNDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICAxMDI0OyBmaXJzdCBwZm4gMTM4MTANCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxM2MxMA0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDE0MDEwDQp4
YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4g
MTQ0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZp
cnN0IHBmbiAxNDgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
MTAyNDsgZmlyc3QgcGZuIDE0YzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9y
ZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTUwMTANCnhjOiBkZXRhaWw6IE1h
cHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxNTQxMA0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDE1ODEw
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBw
Zm4gMTVjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7
IGZpcnN0IHBmbiAxNjAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgMTAyNDsgZmlyc3QgcGZuIDE2NDEwDQp4YzogZGV0YWlsOiBNYXBwaW5n
IG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTY4MTANCnhjOiBkZXRhaWw6
IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxNmMxMA0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDE3
MDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJz
dCBwZm4gMTc0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MjQ7IGZpcnN0IHBmbiAxNzgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRl
ciAwLCAgMTAyNDsgZmlyc3QgcGZuIDE3YzEwDQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTgwMTANCnhjOiBkZXRh
aWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxODQxMA0K
eGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZu
IDE4ODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBm
aXJzdCBwZm4gMThjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwg
IDEwMjQ7IGZpcnN0IHBmbiAxOTAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBv
cmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDE5NDEwDQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMTk4MTANCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxOWMx
MA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3Qg
cGZuIDFhMDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0
OyBmaXJzdCBwZm4gMWE0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIg
MCwgIDEwMjQ7IGZpcnN0IHBmbiAxYTgxMA0KeGM6IGRldGFpbDogTWFwcGlu
ZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDFhYzEwDQp4YzogZGV0YWls
OiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMWIwMTANCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAx
YjQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmly
c3QgcGZuIDFiODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAx
MDI0OyBmaXJzdCBwZm4gMWJjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxYzAxMA0KeGM6IGRldGFpbDogTWFw
cGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDFjNDEwDQp4YzogZGV0
YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMWM4MTAN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBm
biAxY2MxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsg
Zmlyc3QgcGZuIDFkMDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICAxMDI0OyBmaXJzdCBwZm4gMWQ0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxZDgxMA0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDFkYzEwDQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMWUw
MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0
IHBmbiAxZTQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAy
NDsgZmlyc3QgcGZuIDFlODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICAxMDI0OyBmaXJzdCBwZm4gMWVjMTANCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAxZjAxMA0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDFmNDEwDQp4
YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4g
MWY4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZp
cnN0IHBmbiAxZmMxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
MTAyNDsgZmlyc3QgcGZuIDIwMDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9y
ZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjA0MTANCnhjOiBkZXRhaWw6IE1h
cHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyMDgxMA0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDIwYzEw
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBw
Zm4gMjEwMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7
IGZpcnN0IHBmbiAyMTQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgMTAyNDsgZmlyc3QgcGZuIDIxODEwDQp4YzogZGV0YWlsOiBNYXBwaW5n
IG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjFjMTANCnhjOiBkZXRhaWw6
IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyMjAxMA0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDIy
NDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJz
dCBwZm4gMjI4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MjQ7IGZpcnN0IHBmbiAyMmMxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRl
ciAwLCAgMTAyNDsgZmlyc3QgcGZuIDIzMDEwDQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjM0MTANCnhjOiBkZXRh
aWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyMzgxMA0K
eGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZu
IDIzYzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBm
aXJzdCBwZm4gMjQwMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwg
IDEwMjQ7IGZpcnN0IHBmbiAyNDQxMA0KeGM6IGRldGFpbDogTWFwcGluZyBv
cmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDI0ODEwDQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjRjMTANCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyNTAx
MA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3Qg
cGZuIDI1NDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0
OyBmaXJzdCBwZm4gMjU4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIg
MCwgIDEwMjQ7IGZpcnN0IHBmbiAyNWMxMA0KeGM6IGRldGFpbDogTWFwcGlu
ZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDI2MDEwDQp4YzogZGV0YWls
OiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjY0MTANCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAy
NjgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmly
c3QgcGZuIDI2YzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAx
MDI0OyBmaXJzdCBwZm4gMjcwMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyNzQxMA0KeGM6IGRldGFpbDogTWFw
cGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDI3ODEwDQp4YzogZGV0
YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjdjMTAN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBm
biAyODAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsg
Zmlyc3QgcGZuIDI4NDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICAxMDI0OyBmaXJzdCBwZm4gMjg4MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyOGMxMA0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDI5MDEwDQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMjk0
MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0
IHBmbiAyOTgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAy
NDsgZmlyc3QgcGZuIDI5YzEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICAxMDI0OyBmaXJzdCBwZm4gMmEwMTANCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyYTQxMA0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDJhODEwDQp4
YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4g
MmFjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZp
cnN0IHBmbiAyYjAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
MTAyNDsgZmlyc3QgcGZuIDJiNDEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9y
ZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMmI4MTANCnhjOiBkZXRhaWw6IE1h
cHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyYmMxMA0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDJjMDEw
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBw
Zm4gMmM0MTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7
IGZpcnN0IHBmbiAyYzgxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgMTAyNDsgZmlyc3QgcGZuIDJjYzEwDQp4YzogZGV0YWlsOiBNYXBwaW5n
IG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gMmQwMTANCnhjOiBkZXRhaWw6
IE1hcHBpbmcgb3JkZXIgMCwgIDEwMjQ7IGZpcnN0IHBmbiAyZDQxMA0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDJk
ODEwDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICAxMDIxOyBmaXJz
dCBwZm4gMmRjMTANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDEw
MDA7IGZpcnN0IHBmbiAyZTAxMA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRl
ciAwLCAgMTY1OyBmaXJzdCBwZm4gMmU0MTMNCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDMzMzsgZmlyc3QgcGZuIDJlODEzDQp4YzogZGV0YWls
OiBNYXBwaW5nIG9yZGVyIDAsICA2MDM7IGZpcnN0IHBmbiAyZWMxMw0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTczOyBmaXJzdCBwZm4gMmYw
MTMNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDg2NjsgZmlyc3Qg
cGZuIDJmNDEzDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5MDQ7
IGZpcnN0IHBmbiAyZjgxNA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgOTMwOyBmaXJzdCBwZm4gMmZjMTgNCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDk0MTsgZmlyc3QgcGZuIDMwMDIyDQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICA5ODM7IGZpcnN0IHBmbiAzMDQyNA0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTc2OyBmaXJzdCBwZm4gMzA4MjQN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDk3MzsgZmlyc3QgcGZu
IDMwYzI0DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5Nzc7IGZp
cnN0IHBmbiAzMTAyNA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
OTc2OyBmaXJzdCBwZm4gMzE0MjQNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDk5NDsgZmlyc3QgcGZuIDMxODI3DQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICA5MTc7IGZpcnN0IHBmbiAzMWMyNw0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgODcwOyBmaXJzdCBwZm4gMzIwMjcNCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDk2ODsgZmlyc3QgcGZuIDMy
NDI3DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA4ODQ7IGZpcnN0
IHBmbiAzMjgyNw0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTUx
OyBmaXJzdCBwZm4gMzJjMjcNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIg
MCwgIDk0OTsgZmlyc3QgcGZuIDMzMDI3DQp4YzogZGV0YWlsOiBNYXBwaW5n
IG9yZGVyIDAsICA5OTg7IGZpcnN0IHBmbiAzMzQyNw0KeGM6IGRldGFpbDog
TWFwcGluZyBvcmRlciAwLCAgMTAxMTsgZmlyc3QgcGZuIDMzODI3DQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5MTA7IGZpcnN0IHBmbiAzM2My
Yg0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTA4OyBmaXJzdCBw
Zm4gMzQwMmINCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDcwODsg
Zmlyc3QgcGZuIDM0NDM0DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICA4MzU7IGZpcnN0IHBmbiAzNDgzNA0KeGM6IGRldGFpbDogTWFwcGluZyBv
cmRlciAwLCAgNzExOyBmaXJzdCBwZm4gMzRjMzQNCnhjOiBkZXRhaWw6IE1h
cHBpbmcgb3JkZXIgMCwgIDUyNTsgZmlyc3QgcGZuIDM1MDM0DQp4YzogZGV0
YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA2Mzc7IGZpcnN0IHBmbiAzNTQzNA0K
eGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgNzEyOyBmaXJzdCBwZm4g
MzU4MzQNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDk1NjsgZmly
c3QgcGZuIDM1YzM5DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA2
Njg7IGZpcnN0IHBmbiAzNjAzNQ0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRl
ciAwLCAgODYyOyBmaXJzdCBwZm4gMzY0MzUNCnhjOiBkZXRhaWw6IE1hcHBp
bmcgb3JkZXIgMCwgIDkyNzsgZmlyc3QgcGZuIDM2ODM1DQp4YzogZGV0YWls
OiBNYXBwaW5nIG9yZGVyIDAsICA5Mzg7IGZpcnN0IHBmbiAzNmMzNQ0KeGM6
IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTA4OyBmaXJzdCBwZm4gMzcw
MzUNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDg4MDsgZmlyc3Qg
cGZuIDM3NDM1DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5NTg7
IGZpcnN0IHBmbiAzNzgzNQ0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAw
LCAgOTIwOyBmaXJzdCBwZm4gMzdjMzUNCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDg1MDsgZmlyc3QgcGZuIDM4MDM2DQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICA5NjY7IGZpcnN0IHBmbiAzODQzNg0KeGM6IGRl
dGFpbDogTWFwcGluZyBvcmRlciAwLCAgOTcxOyBmaXJzdCBwZm4gMzg4M2IN
CnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDk5MTsgZmlyc3QgcGZu
IDM4YzNhDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5NTE7IGZp
cnN0IHBmbiAzOTA0MQ0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAg
ODM4OyBmaXJzdCBwZm4gMzk0M2UNCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3Jk
ZXIgMCwgIDgxMzsgZmlyc3QgcGZuIDM5ODNlDQp4YzogZGV0YWlsOiBNYXBw
aW5nIG9yZGVyIDAsICA4Mzc7IGZpcnN0IHBmbiAzOWMzZQ0KeGM6IGRldGFp
bDogTWFwcGluZyBvcmRlciAwLCAgNzg0OyBmaXJzdCBwZm4gM2EwM2UNCnhj
OiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDgwNjsgZmlyc3QgcGZuIDNh
NDU4DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA4ODY7IGZpcnN0
IHBmbiAzYTg0Mg0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMTAy
MjsgZmlyc3QgcGZuIDNhYzQyDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVy
IDAsICA5NDA7IGZpcnN0IHBmbiAzYjA0Mg0KeGM6IGRldGFpbDogTWFwcGlu
ZyBvcmRlciAwLCAgOTU4OyBmaXJzdCBwZm4gM2I0NDINCnhjOiBkZXRhaWw6
IE1hcHBpbmcgb3JkZXIgMCwgIDk4MDsgZmlyc3QgcGZuIDNiODQ0DQp4Yzog
ZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA3NTc7IGZpcnN0IHBmbiAzYmM2
MA0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgNDY2OyBmaXJzdCBw
Zm4gM2NhMDANCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDkyNTsg
Zmlyc3QgcGZuIDNjY2ExDQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAs
ICAxMDI0OyBmaXJzdCBwZm4gM2QwYWUNCnhjOiBkZXRhaWw6IE1hcHBpbmcg
b3JkZXIgMCwgIDk2MTsgZmlyc3QgcGZuIDNkNGFmDQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICAxMDIzOyBmaXJzdCBwZm4gM2Q4YmENCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDkzNjsgZmlyc3QgcGZuIDNkY2Nj
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5MDA7IGZpcnN0IHBm
biAzZTBkMw0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgODIzOyBm
aXJzdCBwZm4gM2U0ZTINCnhjOiBkZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwg
IDEwMjQ7IGZpcnN0IHBmbiAzZThkNw0KeGM6IGRldGFpbDogTWFwcGluZyBv
cmRlciAwLCAgMTAyNDsgZmlyc3QgcGZuIDNlY2Q3DQp4YzogZGV0YWlsOiBN
YXBwaW5nIG9yZGVyIDAsICAxMDI0OyBmaXJzdCBwZm4gM2YwZDcNCnhjOiBk
ZXRhaWw6IE1hcHBpbmcgb3JkZXIgMCwgIDg4NjsgZmlyc3QgcGZuIDNmNGQ3
DQp4YzogZGV0YWlsOiBNYXBwaW5nIG9yZGVyIDAsICA5MjI7IGZpcnN0IHBm
biAzZjhmNA0KeGM6IGRldGFpbDogZGVsdGEgMTU4MDFtcywgZG9tMCA5NSUs
IHRhcmdldCAwJSwgc2VudCA1NDNNYi9zLCBkaXJ0aWVkIDBNYi9zIDMxNCBw
YWdlcw0KeGM6IGRldGFpbDogTWFwcGluZyBvcmRlciAwLCAgMjY4OyBmaXJz
dCBwZm4gM2ZjZjQNCnhjOiBkZXRhaWw6IGRlbHRhIDIzbXMsIGRvbTAgMTAw
JSwgdGFyZ2V0IDAlLCBzZW50IDQ0N01iL3MsIGRpcnRpZWQgME1iL3MgMCBw
YWdlcw0KeGM6IGRldGFpbDogU3RhcnQgbGFzdCBpdGVyYXRpb24NCnhjOiBS
ZWxvYWRpbmcgbWVtb3J5IHBhZ2VzOiAyNjIyMTMvMjYyMTQ0ICAxMDAleGM6
IGRldGFpbDogU1VTUEVORCBzaGluZm8gMDAwODJmYmMNCnhjOiBkZXRhaWw6
IGRlbHRhIDE3bXMsIGRvbTAgNTglLCB0YXJnZXQgNTglLCBzZW50IDBNYi9z
LCBkaXJ0aWVkIDEwMzNNYi9zIDUzNiBwYWdlcw0KeGM6IGRldGFpbDogZGVs
dGEgOG1zLCBkb20wIDEwMCUsIHRhcmdldCAwJSwgc2VudCAyMTk1TWIvcywg
ZGlydGllZCAyMTk1TWIvcyA1MzYgcGFnZXMNCnhjOiBkZXRhaWw6IFRvdGFs
IHBhZ2VzIHNlbnQ9IDI2Mjc0OSAoMS4wMHgpDQp4YzogZGV0YWlsOiAob2Yg
d2hpY2ggMCB3ZXJlIGZpeHVwcykNCnhjOiBkZXRhaWw6IEFsbCBtZW1vcnkg
aXMgc2F2ZWQNCnhjOiBlcnJvcjogRXJyb3IgcXVlcnlpbmcgbWF4aW11bSBu
dW1iZXIgb2YgTVNScyBmb3IgVkNQVTAgKDEgPSBPcGVyYXRpb24gbm90IHBl
cm1pdHRlZCk6IEludGVybmFsIGVycm9yDQp4YzogZGV0YWlsOiBTYXZlIGV4
aXQgb2YgZG9taWQgNCB3aXRoIGVycm5vPTENCmxpYnhsOiBlcnJvcjogbGli
eGxfZG9tLmM6MTg2NDpsaWJ4bF9feGNfZG9tYWluX3NhdmVfZG9uZTogc2F2
aW5nIGRvbWFpbjogZG9tYWluIHJlc3BvbmRlZCB0byBzdXNwZW5kIHJlcXVl
c3Q6IE9wZXJhdGlvbiBub3QgcGVybWl0dGVkDQpsaWJ4bDogZXJyb3I6IGxp
YnhsX2RvbS5jOjIwMjE6cmVtdXNfdGVhcmRvd25fZG9uZTogUmVtdXM6IGZh
aWxlZCB0byB0ZWFyZG93biBkZXZpY2UgZm9yIGd1ZXN0IHdpdGggZG9taWQg
NCwgcmMgLTMNCm1pZ3JhdGlvbiBzZW5kZXI6IGxpYnhsX2RvbWFpbl9zdXNw
ZW5kIGZhaWxlZCAocmM9LTMpDQp4YzogZXJyb3I6IDAtbGVuZ3RoIHJlYWQ6
IEludGVybmFsIGVycm9yICAgICAgIA0KeGM6IGVycm9yOiByZGV4YWN0IGZh
aWxlZCAocmVhZCByYzogMCwgZXJybm86IDApOiBJbnRlcm5hbCBlcnJvcg0K
eGM6IGVycm9yOiBFcnJvciB3aGVuIHJlYWRpbmcgc2hhcmVkIGluZm8gcGFn
ZSAoMCA9IFN1Y2Nlc3MpOiBJbnRlcm5hbCBlcnJvcg0KeGM6IGVycm9yOiBl
cnJvciBidWZmZXJpbmcgaW1hZ2UgdGFpbDogSW50ZXJuYWwgZXJyb3INCnhj
OiBkZXRhaWw6IFJlc3RvcmUgZXhpdCBvZiBkb21pZCA2IHdpdGggcmM9MSAg
DQpsaWJ4bDogZXJyb3I6IGxpYnhsX2NyZWF0ZS5jOjEwMzI6bGlieGxfX3hj
X2RvbWFpbl9yZXN0b3JlX2RvbmU6IHJlc3RvcmluZyBkb21haW46IFJlc291
cmNlIHRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlDQpsaWJ4bDogZXJyb3I6IGxp
YnhsX2NyZWF0ZS5jOjExMDQ6ZG9tY3JlYXRlX3JlYnVpbGRfZG9uZTogY2Fu
bm90IChyZS0pYnVpbGQgZG9tYWluOiAtMw0KbGlieGw6IGVycm9yOiBsaWJ4
bC5jOjE1NDI6bGlieGxfX2Rlc3Ryb3lfZG9taWQ6IG5vbi1leGlzdGFudCBk
b21haW4gNg0KbGlieGw6IGVycm9yOiBsaWJ4bC5jOjE1MDY6ZG9tYWluX2Rl
c3Ryb3lfY2FsbGJhY2s6IHVuYWJsZSB0byBkZXN0cm95IGd1ZXN0IHdpdGgg
ZG9taWQgNg0KbGlieGw6IGVycm9yOiBsaWJ4bF9jcmVhdGUuYzoxNDYyOmRv
bWNyZWF0ZV9kZXN0cnVjdGlvbl9jYjogdW5hYmxlIHRvIGRlc3Ryb3kgZG9t
YWluIDYgZm9sbG93aW5nIGZhaWxlZCBjcmVhdGlvbg0KbWlncmF0aW9uIHRh
cmdldDogRG9tYWluIGNyZWF0aW9uIGZhaWxlZCAoY29kZSAtMykuDQpsaWJ4
bDogaW5mbzogbGlieGxfZXhlYy5jOjExODpsaWJ4bF9yZXBvcnRfY2hpbGRf
ZXhpdHN0YXR1czogbWlncmF0aW9uIHRyYW5zcG9ydCBwcm9jZXNzIFs1MzI2
XSBleGl0ZWQgd2l0aCBlcnJvciBzdGF0dXMgMw0KTWlncmF0aW9uIGZhaWxl
ZCwgcmVzdW1pbmcgYXQgc2VuZGVyLg0K

--8323329-2129309582-1416684261=:26346
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-2129309582-1416684261=:26346--


From xen-devel-bounces@lists.xen.org Sat Nov 22 20:25:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 20:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsHFE-0006la-2r; Sat, 22 Nov 2014 20:25:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsHFC-0006lV-E9
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 20:25:22 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F4/28-02957-131F0745; Sat, 22 Nov 2014 20:25:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416687919!14185236!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18297 invoked from network); 22 Nov 2014 20:25:20 -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;
	22 Nov 2014 20:25:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,438,1413244800"; d="scan'208";a="194288566"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 15:24:55 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsHEl-0000O8-4h;
	Sat, 22 Nov 2014 20:24:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsHEk-0007Cj-Vi;
	Sat, 22 Nov 2014 20:24:54 +0000
Date: Sat, 22 Nov 2014 20:24:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31766-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31766: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31766 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31766/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 31241

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 31683
 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate/x10 fail pass in 31683
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot        fail in 31683 pass in 31766
 test-amd64-amd64-xl           5 xen-boot           fail in 31683 pass in 31766
 test-amd64-amd64-xl-sedf-pin  5 xen-boot           fail in 31683 pass in 31766
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot   fail in 31683 pass in 31766

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                fc14f9c1272f62c3e8d01300f52467c0d9af50f9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
561 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 22279 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 Nov 22 20:25:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 20:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsHFE-0006la-2r; Sat, 22 Nov 2014 20:25:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsHFC-0006lV-E9
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 20:25:22 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F4/28-02957-131F0745; Sat, 22 Nov 2014 20:25:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416687919!14185236!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18297 invoked from network); 22 Nov 2014 20:25:20 -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;
	22 Nov 2014 20:25:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,438,1413244800"; d="scan'208";a="194288566"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 15:24:55 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsHEl-0000O8-4h;
	Sat, 22 Nov 2014 20:24:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsHEk-0007Cj-Vi;
	Sat, 22 Nov 2014 20:24:54 +0000
Date: Sat, 22 Nov 2014 20:24:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31766-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31766: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31766 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31766/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 31241

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 31683
 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate/x10 fail pass in 31683
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot        fail in 31683 pass in 31766
 test-amd64-amd64-xl           5 xen-boot           fail in 31683 pass in 31766
 test-amd64-amd64-xl-sedf-pin  5 xen-boot           fail in 31683 pass in 31766
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot   fail in 31683 pass in 31766

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                fc14f9c1272f62c3e8d01300f52467c0d9af50f9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
561 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 22279 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 Nov 22 21:50:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 21:50:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsIZ2-0007K3-6N; Sat, 22 Nov 2014 21:49:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsIZ0-0007Jy-EW
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 21:49:54 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	E3/FB-02576-10501745; Sat, 22 Nov 2014 21:49:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416692991!14204030!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16060 invoked from network); 22 Nov 2014 21:49:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 21:49:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,438,1413244800"; d="scan'208";a="195657333"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 16:49:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsIYv-0000o2-3D;
	Sat, 22 Nov 2014 21:49:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsIYu-0008I7-Rn;
	Sat, 22 Nov 2014 21:49:48 +0000
Date: Sat, 22 Nov 2014 21:49:48 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31773-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31773: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31773 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31773/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          cdb4bff22f578ceb0731db509274133d99c1f4f5
baseline version:
 rumpuserxen          f6bdde8127b10e2bc3f21549dc9c960672ad7718

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=cdb4bff22f578ceb0731db509274133d99c1f4f5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen cdb4bff22f578ceb0731db509274133d99c1f4f5
+ branch=rumpuserxen
+ revision=cdb4bff22f578ceb0731db509274133d99c1f4f5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git cdb4bff22f578ceb0731db509274133d99c1f4f5:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   f6bdde8..cdb4bff  cdb4bff22f578ceb0731db509274133d99c1f4f5 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 21:50:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 21:50:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsIZ2-0007K3-6N; Sat, 22 Nov 2014 21:49:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsIZ0-0007Jy-EW
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 21:49:54 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	E3/FB-02576-10501745; Sat, 22 Nov 2014 21:49:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416692991!14204030!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16060 invoked from network); 22 Nov 2014 21:49:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 21:49:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,438,1413244800"; d="scan'208";a="195657333"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 16:49:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsIYv-0000o2-3D;
	Sat, 22 Nov 2014 21:49:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsIYu-0008I7-Rn;
	Sat, 22 Nov 2014 21:49:48 +0000
Date: Sat, 22 Nov 2014 21:49:48 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31773-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31773: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31773 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31773/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          cdb4bff22f578ceb0731db509274133d99c1f4f5
baseline version:
 rumpuserxen          f6bdde8127b10e2bc3f21549dc9c960672ad7718

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=cdb4bff22f578ceb0731db509274133d99c1f4f5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen cdb4bff22f578ceb0731db509274133d99c1f4f5
+ branch=rumpuserxen
+ revision=cdb4bff22f578ceb0731db509274133d99c1f4f5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git cdb4bff22f578ceb0731db509274133d99c1f4f5:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   f6bdde8..cdb4bff  cdb4bff22f578ceb0731db509274133d99c1f4f5 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 22:12:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 22:12:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsIuu-0007c7-BS; Sat, 22 Nov 2014 22:12: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@citrix.com>) id 1XsIus-0007c2-Ur
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 22:12:31 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	B9/24-24124-E4A01745; Sat, 22 Nov 2014 22:12:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416694347!7420981!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1154 invoked from network); 22 Nov 2014 22:12:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 22:12:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,438,1413244800"; d="scan'208";a="194327973"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 17:11:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsIuJ-0000ub-Fn;
	Sat, 22 Nov 2014 22:11:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsIuJ-0007W1-B2;
	Sat, 22 Nov 2014 22:11:55 +0000
Date: Sat, 22 Nov 2014 22:11:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31768-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31768: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31768 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31768/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt      5 xen-boot                  fail REGR. vs. 31686
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 31686

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10    fail REGR. vs. 31686
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31686

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                0e88f478508b566152c6681f4889ed9830a2c0a5
baseline version:
 qemuu                af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Amit Shah <amit.shah@redhat.com>
  ChenLiang <chenliang88@huawei.com>
  Fabien Chouteau <chouteau@adacore.com>
  Fam Zheng <famz@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Leif Lindholm <leif.lindholm@linaro.org>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefan Hajnoczi <stefanha@redhat.com>
  Tom Musta <tommusta@gmail.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 0e88f478508b566152c6681f4889ed9830a2c0a5
Merge: a00c117 b0af844
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Fri Nov 21 14:15:37 2014 +0000

    Merge remote-tracking branch 'remotes/stefanha/tags/net-pull-request' into staging
    
    # gpg: Signature made Fri 21 Nov 2014 11:12:37 GMT using RSA key ID 81AB73C8
    # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>"
    # gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>"
    
    * remotes/stefanha/tags/net-pull-request:
      rtl8139: fix Pointer to local outside scope
      pcnet: fix Negative array index read
      net/socket: fix Uninitialized scalar variable
      net/slirp: fix memory leak
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit a00c1173385741007f71ce505d092f4cc174f449
Merge: 9c7074d b310a2a
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Fri Nov 21 13:22:18 2014 +0000

    Merge remote-tracking branch 'remotes/kraxel/tags/pull-gtk-20141121-1' into staging
    
    gtk: two bugfixes for 2.2.
    
    # gpg: Signature made Fri 21 Nov 2014 07:38:45 GMT using RSA key ID D3E87138
    # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
    # gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
    # gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"
    
    * remotes/kraxel/tags/pull-gtk-20141121-1:
      gtk: Don't crash if -nodefaults
      gtk: fix possible memory leak about local_err
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit b0af844007841609cc11fab58f838bd105cbe144
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Thu Nov 20 19:35:03 2014 +0800

    rtl8139: fix Pointer to local outside scope
    
    Coverity spot:
     Assigning: iov = struct iovec [3]({{buf, 12UL},
                           {(void *)dot1q_buf, 4UL},
                           {buf + 12, size - 12}})
     (address of temporary variable of type struct iovec [3]).
     out_of_scope: Temporary variable of type struct iovec [3] goes out of scope.
    
    Pointer to local outside scope (RETURN_LOCAL)
    use_invalid:
     Using iov, which points to an out-of-scope temporary variable of type struct iovec [3].
    
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

commit 7b50d00911ddd6d56a766ac5671e47304c20a21b
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Thu Nov 20 19:35:02 2014 +0800

    pcnet: fix Negative array index read
    
    s->xmit_pos maybe assigned to a negative value (-1),
    but in this branch variable s->xmit_pos as an index to
    array s->buffer. Let's add a check for s->xmit_pos.
    
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

commit 8db804ac412010fc96397c2d67ee6417eccd9d34
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Thu Nov 20 19:35:01 2014 +0800

    net/socket: fix Uninitialized scalar variable
    
    If is_connected parameter is false, the saddr
    variable will no initialize. Coverity report:
    uninit_use: Using uninitialized value saddr.sin_port.
    
    We don't need add saddr information to nc->info_str
    when is_connected is false.
    
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

commit 7a8919dc29a9f46dcadd950c2aa1acf74f28974d
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Thu Nov 20 19:35:00 2014 +0800

    net/slirp: fix memory leak
    
    commit b412eb61 introduce 'cmd:' target for guestfwd,
    and fwd don't be used in this scenario, and will leak
    memory in true branch with 'cmd:'. Let's allocate memory
    for fwd variable just in else statement.
    
    Cc: Alexander Graf <agraf@suse.de>
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

commit b310a2a6095ec927a42cc1aba520a316be0faf51
Author: Fam Zheng <famz@redhat.com>
Date:   Fri Nov 21 09:59:09 2014 +0800

    gtk: Don't crash if -nodefaults
    
    This fixes a crash by just skipping the vte resize hack if cur is NULL.
    
    Reproducer:
    
    qemu-system-x86_64 -nodefaults
    
    Signed-off-by: Fam Zheng <famz@redhat.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

commit 8a0f9b5263bb3a96d574ca78ad3b8f1d7bf8b12b
Author: zhanghailiang <zhang.zhanghailiang@huawei.com>
Date:   Fri Nov 14 11:25:28 2014 +0800

    gtk: fix possible memory leak about local_err
    
    local_err in gd_vc_gfx_init() is not freed, and we don't use it,
    so remove it.
    
    Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

commit 9c7074da5ec64e1fd61df881ab291f75541ff2b0
Author: Leif Lindholm <leif.lindholm@linaro.org>
Date:   Wed Nov 19 11:08:45 2014 +0000

    hw/arm/virt: set stdout-path instead of linux,stdout-path
    
    ePAPR 1.1 defines the stdout-path property, making the os-specific
    linux,stdout-path property redundant. Change the DT setup for ARM virt
    to use the generic property - supported by Linux since 3.15.
    
    The old QEMU behaviour was not present in any released version of
    QEMU, and was only added to QEMU after the kernel changed, so
    this should not break any existing setups.
    
    Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
    [PMM: add note to commit about the old behaviour never hving been
    in a released version of QEMU]
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit ff323a6b5468523aab07d376875685ec00385f44
Merge: f75ad80 76cb658
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Thu Nov 20 14:02:24 2014 +0000

    Merge remote-tracking branch 'remotes/agraf/tags/signed-ppc-for-upstream' into staging
    
    Patch queue for ppc - 2014-11-20
    
    Hopefully the last few fixups for 2.2:
    
      - KVM memory slot fix (should usually only occur on PPC)
      - e300 fix
      - Altivec mtvscr instruction fix
    
    # gpg: Signature made Thu 20 Nov 2014 13:53:34 GMT using RSA key ID 03FEDC60
    # gpg: Good signature from "Alexander Graf <agraf@suse.de>"
    # gpg:                 aka "Alexander Graf <alex@csgraf.de>"
    
    * remotes/agraf/tags/signed-ppc-for-upstream:
      target-ppc: Altivec's mtvscr Decodes Wrong Register
      kvm: Fix memory slot page alignment logic
      target-ppc: Fix breakpoint registers for e300
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 76cb6584196b6f35d6e9b5124974d3eba643f772
Author: Tom Musta <tommusta@gmail.com>
Date:   Fri Nov 14 14:01:41 2014 -0600

    target-ppc: Altivec's mtvscr Decodes Wrong Register
    
    The Move to Vector Status and Control Register (mtvscr) instruction
    uses VRB as the source register.  Fix the code generator to correctly
    decode the VRB field.  That is, use "rB(ctx->opcode)" instead of
    "rD(ctx->opcode)".
    
    Signed-off-by: Tom Musta <tommusta@gmail.com>
    Signed-off-by: Alexander Graf <agraf@suse.de>

commit f2a64032a14c642d0ddc9a7a846fc3d737deede5
Author: Alexander Graf <agraf@suse.de>
Date:   Fri Nov 7 22:12:48 2014 +0100

    kvm: Fix memory slot page alignment logic
    
    Memory slots have to be page aligned to get entered into KVM. There
    is existing logic that tries to ensure that we pad memory slots that
    are not page aligned to the biggest region that would still fit in the
    alignment requirements.
    
    Unfortunately, that logic is broken. It tries to calculate the start
    offset based on the region size.
    
    Fix up the logic to do the thing it was intended to do and document it
    properly in the comment above it.
    
    With this patch applied, I can successfully run an e500 guest with more
    than 3GB RAM (at which point RAM starts overlapping subpage memory regions).
    
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Alexander Graf <agraf@suse.de>

commit 3ade1a055c9ac6c351a008703e30fb831f23b941
Author: Fabien Chouteau <chouteau@adacore.com>
Date:   Thu Nov 6 17:23:50 2014 +0100

    target-ppc: Fix breakpoint registers for e300
    
    In the previous patch, the registers were added to init_proc_G2LE
    instead of init_proc_e300.
    
    Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
    Signed-off-by: Alexander Graf <agraf@suse.de>

commit f75ad80f6c8ce0d83224076bd3445c77451977d5
Merge: af3ff19 6c1b663
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Thu Nov 20 13:00:28 2014 +0000

    Merge remote-tracking branch 'remotes/amit-migration/tags/for-2.2-2' into staging
    
    Fix from a while back that unfortunately got ignored.  Dave Gilbert says
    it may actually fix a case where autoconverge would break on a repeat
    migration (and not just fix stats).
    
    # gpg: Signature made Thu 20 Nov 2014 12:52:41 GMT using RSA key ID 854083B6
    # gpg: Good signature from "Amit Shah <amit@amitshah.net>"
    # gpg:                 aka "Amit Shah <amit@kernel.org>"
    # gpg:                 aka "Amit Shah <amitshah@gmx.net>"
    
    * remotes/amit-migration/tags/for-2.2-2:
      migration: static variables will not be reset at second migration
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 6c1b663c4c3725bc4bc33f78ed266ddef80a2ca8
Author: ChenLiang <chenliang88@huawei.com>
Date:   Thu Mar 20 20:15:03 2014 +0800

    migration: static variables will not be reset at second migration
    
    The static variables in migration_bitmap_sync will not be reset in
    the case of a second attempted migration.
    
    Signed-off-by: ChenLiang <chenliang88@huawei.com>
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Signed-off-by: Amit Shah <amit.shah@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 22 22:12:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Nov 2014 22:12:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsIuu-0007c7-BS; Sat, 22 Nov 2014 22:12: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@citrix.com>) id 1XsIus-0007c2-Ur
	for xen-devel@lists.xensource.com; Sat, 22 Nov 2014 22:12:31 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	B9/24-24124-E4A01745; Sat, 22 Nov 2014 22:12:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416694347!7420981!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1154 invoked from network); 22 Nov 2014 22:12:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 22:12:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,438,1413244800"; d="scan'208";a="194327973"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 17:11:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsIuJ-0000ub-Fn;
	Sat, 22 Nov 2014 22:11:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsIuJ-0007W1-B2;
	Sat, 22 Nov 2014 22:11:55 +0000
Date: Sat, 22 Nov 2014 22:11:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31768-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31768: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31768 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31768/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt      5 xen-boot                  fail REGR. vs. 31686
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 31686

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10    fail REGR. vs. 31686
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31686

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                0e88f478508b566152c6681f4889ed9830a2c0a5
baseline version:
 qemuu                af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Amit Shah <amit.shah@redhat.com>
  ChenLiang <chenliang88@huawei.com>
  Fabien Chouteau <chouteau@adacore.com>
  Fam Zheng <famz@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Leif Lindholm <leif.lindholm@linaro.org>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefan Hajnoczi <stefanha@redhat.com>
  Tom Musta <tommusta@gmail.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 0e88f478508b566152c6681f4889ed9830a2c0a5
Merge: a00c117 b0af844
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Fri Nov 21 14:15:37 2014 +0000

    Merge remote-tracking branch 'remotes/stefanha/tags/net-pull-request' into staging
    
    # gpg: Signature made Fri 21 Nov 2014 11:12:37 GMT using RSA key ID 81AB73C8
    # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>"
    # gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>"
    
    * remotes/stefanha/tags/net-pull-request:
      rtl8139: fix Pointer to local outside scope
      pcnet: fix Negative array index read
      net/socket: fix Uninitialized scalar variable
      net/slirp: fix memory leak
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit a00c1173385741007f71ce505d092f4cc174f449
Merge: 9c7074d b310a2a
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Fri Nov 21 13:22:18 2014 +0000

    Merge remote-tracking branch 'remotes/kraxel/tags/pull-gtk-20141121-1' into staging
    
    gtk: two bugfixes for 2.2.
    
    # gpg: Signature made Fri 21 Nov 2014 07:38:45 GMT using RSA key ID D3E87138
    # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
    # gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
    # gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"
    
    * remotes/kraxel/tags/pull-gtk-20141121-1:
      gtk: Don't crash if -nodefaults
      gtk: fix possible memory leak about local_err
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit b0af844007841609cc11fab58f838bd105cbe144
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Thu Nov 20 19:35:03 2014 +0800

    rtl8139: fix Pointer to local outside scope
    
    Coverity spot:
     Assigning: iov = struct iovec [3]({{buf, 12UL},
                           {(void *)dot1q_buf, 4UL},
                           {buf + 12, size - 12}})
     (address of temporary variable of type struct iovec [3]).
     out_of_scope: Temporary variable of type struct iovec [3] goes out of scope.
    
    Pointer to local outside scope (RETURN_LOCAL)
    use_invalid:
     Using iov, which points to an out-of-scope temporary variable of type struct iovec [3].
    
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

commit 7b50d00911ddd6d56a766ac5671e47304c20a21b
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Thu Nov 20 19:35:02 2014 +0800

    pcnet: fix Negative array index read
    
    s->xmit_pos maybe assigned to a negative value (-1),
    but in this branch variable s->xmit_pos as an index to
    array s->buffer. Let's add a check for s->xmit_pos.
    
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

commit 8db804ac412010fc96397c2d67ee6417eccd9d34
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Thu Nov 20 19:35:01 2014 +0800

    net/socket: fix Uninitialized scalar variable
    
    If is_connected parameter is false, the saddr
    variable will no initialize. Coverity report:
    uninit_use: Using uninitialized value saddr.sin_port.
    
    We don't need add saddr information to nc->info_str
    when is_connected is false.
    
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

commit 7a8919dc29a9f46dcadd950c2aa1acf74f28974d
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Thu Nov 20 19:35:00 2014 +0800

    net/slirp: fix memory leak
    
    commit b412eb61 introduce 'cmd:' target for guestfwd,
    and fwd don't be used in this scenario, and will leak
    memory in true branch with 'cmd:'. Let's allocate memory
    for fwd variable just in else statement.
    
    Cc: Alexander Graf <agraf@suse.de>
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

commit b310a2a6095ec927a42cc1aba520a316be0faf51
Author: Fam Zheng <famz@redhat.com>
Date:   Fri Nov 21 09:59:09 2014 +0800

    gtk: Don't crash if -nodefaults
    
    This fixes a crash by just skipping the vte resize hack if cur is NULL.
    
    Reproducer:
    
    qemu-system-x86_64 -nodefaults
    
    Signed-off-by: Fam Zheng <famz@redhat.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

commit 8a0f9b5263bb3a96d574ca78ad3b8f1d7bf8b12b
Author: zhanghailiang <zhang.zhanghailiang@huawei.com>
Date:   Fri Nov 14 11:25:28 2014 +0800

    gtk: fix possible memory leak about local_err
    
    local_err in gd_vc_gfx_init() is not freed, and we don't use it,
    so remove it.
    
    Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

commit 9c7074da5ec64e1fd61df881ab291f75541ff2b0
Author: Leif Lindholm <leif.lindholm@linaro.org>
Date:   Wed Nov 19 11:08:45 2014 +0000

    hw/arm/virt: set stdout-path instead of linux,stdout-path
    
    ePAPR 1.1 defines the stdout-path property, making the os-specific
    linux,stdout-path property redundant. Change the DT setup for ARM virt
    to use the generic property - supported by Linux since 3.15.
    
    The old QEMU behaviour was not present in any released version of
    QEMU, and was only added to QEMU after the kernel changed, so
    this should not break any existing setups.
    
    Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
    [PMM: add note to commit about the old behaviour never hving been
    in a released version of QEMU]
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit ff323a6b5468523aab07d376875685ec00385f44
Merge: f75ad80 76cb658
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Thu Nov 20 14:02:24 2014 +0000

    Merge remote-tracking branch 'remotes/agraf/tags/signed-ppc-for-upstream' into staging
    
    Patch queue for ppc - 2014-11-20
    
    Hopefully the last few fixups for 2.2:
    
      - KVM memory slot fix (should usually only occur on PPC)
      - e300 fix
      - Altivec mtvscr instruction fix
    
    # gpg: Signature made Thu 20 Nov 2014 13:53:34 GMT using RSA key ID 03FEDC60
    # gpg: Good signature from "Alexander Graf <agraf@suse.de>"
    # gpg:                 aka "Alexander Graf <alex@csgraf.de>"
    
    * remotes/agraf/tags/signed-ppc-for-upstream:
      target-ppc: Altivec's mtvscr Decodes Wrong Register
      kvm: Fix memory slot page alignment logic
      target-ppc: Fix breakpoint registers for e300
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 76cb6584196b6f35d6e9b5124974d3eba643f772
Author: Tom Musta <tommusta@gmail.com>
Date:   Fri Nov 14 14:01:41 2014 -0600

    target-ppc: Altivec's mtvscr Decodes Wrong Register
    
    The Move to Vector Status and Control Register (mtvscr) instruction
    uses VRB as the source register.  Fix the code generator to correctly
    decode the VRB field.  That is, use "rB(ctx->opcode)" instead of
    "rD(ctx->opcode)".
    
    Signed-off-by: Tom Musta <tommusta@gmail.com>
    Signed-off-by: Alexander Graf <agraf@suse.de>

commit f2a64032a14c642d0ddc9a7a846fc3d737deede5
Author: Alexander Graf <agraf@suse.de>
Date:   Fri Nov 7 22:12:48 2014 +0100

    kvm: Fix memory slot page alignment logic
    
    Memory slots have to be page aligned to get entered into KVM. There
    is existing logic that tries to ensure that we pad memory slots that
    are not page aligned to the biggest region that would still fit in the
    alignment requirements.
    
    Unfortunately, that logic is broken. It tries to calculate the start
    offset based on the region size.
    
    Fix up the logic to do the thing it was intended to do and document it
    properly in the comment above it.
    
    With this patch applied, I can successfully run an e500 guest with more
    than 3GB RAM (at which point RAM starts overlapping subpage memory regions).
    
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Alexander Graf <agraf@suse.de>

commit 3ade1a055c9ac6c351a008703e30fb831f23b941
Author: Fabien Chouteau <chouteau@adacore.com>
Date:   Thu Nov 6 17:23:50 2014 +0100

    target-ppc: Fix breakpoint registers for e300
    
    In the previous patch, the registers were added to init_proc_G2LE
    instead of init_proc_e300.
    
    Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
    Signed-off-by: Alexander Graf <agraf@suse.de>

commit f75ad80f6c8ce0d83224076bd3445c77451977d5
Merge: af3ff19 6c1b663
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Thu Nov 20 13:00:28 2014 +0000

    Merge remote-tracking branch 'remotes/amit-migration/tags/for-2.2-2' into staging
    
    Fix from a while back that unfortunately got ignored.  Dave Gilbert says
    it may actually fix a case where autoconverge would break on a repeat
    migration (and not just fix stats).
    
    # gpg: Signature made Thu 20 Nov 2014 12:52:41 GMT using RSA key ID 854083B6
    # gpg: Good signature from "Amit Shah <amit@amitshah.net>"
    # gpg:                 aka "Amit Shah <amit@kernel.org>"
    # gpg:                 aka "Amit Shah <amitshah@gmx.net>"
    
    * remotes/amit-migration/tags/for-2.2-2:
      migration: static variables will not be reset at second migration
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 6c1b663c4c3725bc4bc33f78ed266ddef80a2ca8
Author: ChenLiang <chenliang88@huawei.com>
Date:   Thu Mar 20 20:15:03 2014 +0800

    migration: static variables will not be reset at second migration
    
    The static variables in migration_bitmap_sync will not be reset in
    the case of a second attempted migration.
    
    Signed-off-by: ChenLiang <chenliang88@huawei.com>
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Signed-off-by: Amit Shah <amit.shah@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 01:29:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 01:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsLye-0004k8-GA; Sun, 23 Nov 2014 01:28:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XsLyd-0004k3-3W
	for xen-devel@lists.xen.org; Sun, 23 Nov 2014 01:28:36 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/EB-25276-24831745; Sun, 23 Nov 2014 01:28:34 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416706107!14675408!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27294 invoked from network); 23 Nov 2014 01:28:28 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2014 01:28:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416706105; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : Subject :
	References : In-Reply-To : Content-Type : Content-Transfer-Encoding;
	bh=b2xGpvqOiDa/Jg1ciOIV99GK70ZYvbLtGAzAkGf+zR4=;
	b=Yy6bVbpeqA8v+bUnS3bHdCJFv8bfKt1LCdThQN+JKEb3dM/g2QeEy4KEWoee7x2h852f49uPizu/n77zx8mFE2EsZHoDx5PJdIFOM4ATNYIs+thFPLwfInx0n+8ovteKZcs91Nw+9rzOko9kETwzKIw/sL6ICGwaHm3Z+xecvgA=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Sat, 22 Nov 2014 17:28:23 -0800
	id 0000000000030596.54713837.00000C49
Message-ID: <54713848.3020401@ihonk.com>
Date: Sat, 22 Nov 2014 17:28:40 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org,
	=?windows-1252?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>,
	Don Slutz <dslutz@verizon.com>
References: <5457F79B.2020300@ihonk.com>
	<20141104082012.GY12451@reaktio.net>	<5458B55C0200007800044B33@mail.emea.novell.com>	<5460716A.7090905@ihonk.com>	<54608A8B0200007800045E58@mail.emea.novell.com>	<54611A86.4000200@ihonk.com>	<5461D15C02000078000464D7@mail.emea.novell.com>	<546A4AD4.3030002@ihonk.com>	<546B094C0200007800048A5C@mail.emea.novell.com>	<546D429A.5020906@ihonk.com>	<546DAD6502000078000492FD@mail.emea.novell.com>	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
In-Reply-To: <546F091F0200007800049A1C@smtp.nue.novell.com>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 0:42, Jan Beulich wrote:
>>>> On 20.11.14 at 21:07, <sflist@ihonk.com> wrote:
>> Running with mwait-idle=0 solves (hides?) the problem. Next step is to
>> fiddle with the C states?
> For that I'd first of all like to know how much use of C states the
> system still makes with that option in place. For that I'd need the
> output of "xenpm get-cpuidle-states" (actually for comparison
> purposes seeing it once with and once without that option in
> place would be best). Or alternatively 'c' debug key output.

With mwait-idle=0:

(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930624784]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]
(XEN) ==cpu1==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930681815]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]
(XEN) ==cpu2==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930766930]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]
(XEN) ==cpu3==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930824772]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]
(XEN) ==cpu4==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930882528]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]
(XEN) ==cpu5==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930940315]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]

Without mwait-idle=0:

(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00004503] method[  FFH] 
duration[1668990535]
(XEN)     C2:   type[C1] latency[010] usage[00009956] method[  FFH] 
duration[4639219546]
(XEN)     C3:   type[C2] latency[020] usage[00654270] method[  FFH] 
duration[882706893390]
(XEN)     C4:   type[C3] latency[200] usage[01483059] method[  FFH] 
duration[35921809585234]
(XEN)    *C0:   usage[02151788] duration[62576274678]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[870647607639] CC6[35852001619202] CC7[0]
(XEN) ==cpu1==
(XEN) active state:             C4
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00297689] method[  FFH] 
duration[1941100848]
(XEN)     C2:   type[C1] latency[010] usage[00001168] method[  FFH] 
duration[1442327615]
(XEN)     C3:   type[C2] latency[020] usage[00006546] method[  FFH] 
duration[8936496716]
(XEN)    *C4:   type[C3] latency[200] usage[01558115] method[  FFH] 
duration[36835128713631]
(XEN)     C0:   usage[01863518] duration[25952414199]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[8737041745] CC6[36744372677161] CC7[0]
(XEN) ==cpu2==
(XEN) active state:             C4
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00289127] method[  FFH] 
duration[1652020841]
(XEN)     C2:   type[C1] latency[010] usage[00000522] method[  FFH] 
duration[1133871888]
(XEN)     C3:   type[C2] latency[020] usage[00004190] method[  FFH] 
duration[5497931261]
(XEN)    *C4:   type[C3] latency[200] usage[01466569] method[  FFH] 
duration[36844578249201]
(XEN)     C0:   usage[01760408] duration[20539080318]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[5364573735] CC6[36756863793181] CC7[0]
(XEN) ==cpu3==
(XEN) active state:             C4
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00323774] method[  FFH] 
duration[21886547916]
(XEN)     C2:   type[C1] latency[010] usage[00000609] method[  FFH] 
duration[45620838149]
(XEN)     C3:   type[C2] latency[020] usage[00006012] method[  FFH] 
duration[1209202160481]
(XEN)    *C4:   type[C3] latency[200] usage[00081570] method[  FFH] 
duration[35586514444690]
(XEN)     C0:   usage[00411965] duration[10177272890]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[1208967409452] CC6[35580116939846] CC7[0]
(XEN) ==cpu4==
(XEN) active state:             C4
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00305724] method[  FFH] 
duration[2083310858]
(XEN)     C2:   type[C1] latency[010] usage[00000597] method[  FFH] 
duration[2346319460]
(XEN)     C3:   type[C2] latency[020] usage[00004138] method[  FFH] 
duration[67793456157]
(XEN)    *C4:   type[C3] latency[200] usage[00274791] method[  FFH] 
duration[36779940944067]
(XEN)     C0:   usage[00585250] duration[21237335856]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[67665029339] CC6[36762696627875] CC7[0]
(XEN) ==cpu5==
(XEN) active state:             C4
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00299747] method[  FFH] 
duration[20553360971]
(XEN)     C2:   type[C1] latency[010] usage[00000609] method[  FFH] 
duration[42279548469]
(XEN)     C3:   type[C2] latency[020] usage[00005673] method[  FFH] 
duration[1169803847553]
(XEN)    *C4:   type[C3] latency[200] usage[00095108] method[  FFH] 
duration[35630372847429]
(XEN)     C0:   usage[00401137] duration[10391860839]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[1169586367967] CC6[35622884210881] CC7[0]


>>> Interesting - all CPUs are executing stuff from Dom1, which be itself
>>> is not indicating a problem, but may (considering the host hang) hint
>>> at guest vCPU-s not getting de-scheduled anymore on one or more of the
>>> CPUs. The 'a' debug key output would hopefully give us enough
>>> information to know whether that's the case. Ideally do 'd' and 'a' a
>>> couple of times each (alternating, and with a few seconds in between).
>> Here ya go (as before, from 9a727a81). I had to pick and choose what
>> parts to pull from the log because it was getting spammed with kernel
>> complaints about the disk subsystem being locked up, so the hypervisor
>> debugging info was hard to read amidst the kernel errors. As ever, let
>> me know if you need more.
> Pretty strange: While the first 'a' output suggests that several CPUs
> are idle, the first 'd' output contradicts. While this isn't wrong by itself,
> it may provide a hint I'm simply unable to interpret yet. In any event
> I didn't find what I expected - timers the expiry of which was in the
> past.

Would this strangeness be explained if the first invocations of 'a' and 
'd' weren't actually contiguous? Because of the log spamming I had to 
discard a number of invocations, which I think I did between the first 
two invocations I passed on to you. Here's another attempt, these are 
contiguous, this is from an attempt with turbo mode disabled:

(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        2680us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=        7344us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN)   ex=        7344us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=      989016us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=    14334142us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=   143474414us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=      500179us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=     2272179us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN) CPU01:
(XEN)   ex=        4179us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=        7914us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=        7344us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN) CPU02:
(XEN)   ex=        7344us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=        7408us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=      236179us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex= 26738118512us timer=ffff830c18437290 
cb=rtc_alarm_cb(ffff830c184371f0)
(XEN)   ex=       30039us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=        7344us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex=        7405us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=       30053us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=        7344us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=        7405us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=     2272179us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=       30061us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=         179us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=        1074us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=   501037117us timer=ffff830c184375d0 
cb=pmt_timer_callback(ffff830c184375a8)
(XEN)   ex=        7408us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=        7344us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  fffffffffffffff7   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 000037d3e7b7ffcf   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffdb478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000000000000001   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000037d3e7b7f98e   r14: 000000000000000f
(XEN) r15: fffffa8000bcf3d0   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fefb8684ee
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a0ce80   rcx: fffff80002a0cec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80000ba6e70
(XEN) rbp: 000000000000000f   rsp: fffff80000ba6be0   r8: fffff80002a0cfa0
(XEN) r9:  000034da77fd3a29   r10: fffff80002a0cfa0   r11: fffff80000ba6d30
(XEN) r12: fffff80000ba6d30   r13: 000037d3e7c82ee7   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: fffff88001333898
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d0801dc4fe>] vmx_vmexit_handler+0x311/0x195e
(XEN) RFLAGS: 0000000000000297   CONTEXT: hypervisor
(XEN) rax: 0000000000187000   rbx: ffff830c3dca7f18   rcx: 000000000000ffff
(XEN) rdx: 00003a4400000000   rsi: 0000000000000000   rdi: ffff830c3dca7f18
(XEN) rbp: ffff830c3dca7f08   rsp: ffff830c3dca7d98   r8: fffff880031ea140
(XEN) r9:  0000000000000000   r10: fffff880031ea190   r11: 00000003429653d0
(XEN) r12: ffff8300a99a5000   r13: 0000000000000028   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1b5d6000   cr2: 000007fef93521dc
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7d98:
(XEN)    ffff8300a99a5000 ffff8300a99a5000 ffff8300a99a5000 ffff830c3dcaa088
(XEN)    ffff830c3dca7e08 0000000000000000 ffff830c3dca7de8 ffff830c3dca0000
(XEN)    ffff830c3dcaa0a0 ffff8300a99a5000 000014e14d5273bf ffff8300a99a5000
(XEN)    ffff830c3dcaa088 0000000001c9c380 0000000000000292 ffff830c3dca7e28
(XEN)    ffff82d08012a80f ffff8300a99a5000 ffff830c3dca7e98 ffff82d0801caea5
(XEN)    ffff830c3dca7ec8 ffff8300a99a5508 ffff82d080321280 ffff830c3dcaa0a0
(XEN)    ffff830c3dca7e78 ffff830c3dca7e88 ffff82d0801b5277 ffff8300a99a5000
(XEN)    000014e14d5273bf ffff8300a99a5000 ffff830c3dca7f08 ffff82d0801e0f69
(XEN)    ffff830c3dca7f18 ffff8300a99a5000 ffff830c3dca7f08 ffff82d0801ddba6
(XEN)    ffff830c3dca0000 0000000000000058 ffff830c3dca7ef8 ffff82d08012a1b3
(XEN)    ffff8300a99a5000 ffff8300a99a5000 fffff880031ea518 0000000000001000
(XEN)    0000000000000000 0000000000000058 000000000000432f ffff82d0801e3c81
(XEN)    0000000000000058 0000000000000000 0000000000001000 fffff880031ea518
(XEN)    000000000000432f 00003a44732bdba0 00000003429653d0 fffff880031ea190
(XEN)    0000000000000000 fffff880031ea140 00003a44732bda2e 000000000000ffff
(XEN)    00003a4400000000 0000000000000000 0000000000000097 0000beef0000beef
(XEN)    fffff80002e112bf 000000bf0000beef 0000000000000002 fffff880031ea0e0
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    000000000000beef 0000000000000003 ffff8300a99a5000 0000003bbd988e00
(XEN)    0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801dc4fe>] vmx_vmexit_handler+0x311/0x195e
(XEN)    [<ffff82d0801e3c81>] vmx_asm_vmexit_handler+0x41/0xc0
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff80002e112bf>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 00003a44732bda2e   rbx: 00003a44732bdba0   rcx: 000000000000ffff
(XEN) rdx: 00003a4400000000   rsi: 0000000000000000   rdi: 0000000000000097
(XEN) rbp: 000000000000432f   rsp: fffff880031ea0e0   r8: fffff880031ea140
(XEN) r9:  0000000000000000   r10: fffff880031ea190   r11: 00000003429653d0
(XEN) r12: fffff880031ea518   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  ffffffffffffffdf   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 000037d3e7b7f0a9   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a99a7000   rcx: 0000000000000005
(XEN) rdx: ffff830c3dc80000   rsi: 0000000000000004   rdi: ffff830c3dc8e088
(XEN) rbp: ffff830c3dc87ec8   rsp: ffff830c3dc87e40   r8: ffff830c3dc8e0a0
(XEN) r9:  0000000000000000   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: 000014e162f97027   r13: ffff8300a99a7000   r14: ffff830c3dc8e088
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c182ef000   cr2: 000007fffffa9478
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc87e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dc8e0a0 0000000500c87e78
(XEN)    ffff830c3dc8e080 ffff82d0801b5277 ffff8300a99a7000 fffff88002ec0d70
(XEN)    ffff8300a99a7000 0000000001c9c380 ffff82d0801e0f00 ffff830c3dc87f08
(XEN)    ffff82d0802f8280 ffff82d0802f8000 ffffffffffffffff ffff830c3dc80000
(XEN)    fffff6fc4003b208 ffff830c3dc87ef8 ffff82d08012a1b3 ffff8300a99a7000
(XEN)    fffff88002ec0d70 000037d3e7b7f896 000000000000000f ffff830c3dc87f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a fffff6fc4003b208
(XEN)    000000000000000f 000037d3e7b7f896 fffff88002ec0d70 000000000000000f
(XEN)    fffff88002eb6180 fffff88002ec0d70 fffff88002eb62a0 0000000000000001
(XEN)    fffff88002eb62a0 0000000000000002 fffff88002eb61c0 0000000000000400
(XEN)    0000000000000000 fffff88002ec0eb0 0000beef0000beef fffff8000294a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002ec0c20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000005 ffff8300a99a7000 0000003bbd96ce00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  0000000000000001   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 000037d3e7b7f896   r14: 000000000000000f
(XEN) r15: fffff6fc4003b208   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffa9478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        3021us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=        7725us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=        7725us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN)   ex=   134454796us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=      652872us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=     5314524us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN) CPU01:
(XEN)   ex=        7725us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=        7789us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex= 26729098894us timer=ffff830c18437290 
cb=rtc_alarm_cb(ffff830c184371f0)
(XEN)   ex=       30023us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=        7725us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=        7791us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       24560us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN) CPU03:
(XEN)   ex=         249us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=        1041us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=      216560us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex=        8273us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=        7725us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN) CPU04:
(XEN)   ex=        7725us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=        7790us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=     1016560us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=     1252560us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=       30054us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=        7725us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=        7789us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=       40560us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=   492017498us timer=ffff830c184375d0 
cb=pmt_timer_callback(ffff830c184375a8)
(XEN)   ex=       30068us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  fffffffffffffff7   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 000037d3e7b7ffcf   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffdb478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000294a214>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a0ce80   rcx: fffff80002a0cec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80000ba6e70
(XEN) rbp: 000000000000000f   rsp: fffff80000ba6be0   r8: fffff80002a0cfa0
(XEN) r9:  000034da77fd3a29   r10: fffff80002a0cfa0   r11: fffff80000ba6d30
(XEN) r12: fffff80000ba6d30   r13: 000037d3e7c82ee7   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: fffff88001333898
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a99a2000   rcx: 0000000000000002
(XEN) rdx: ffff830c3dcb0000   rsi: 0000000000000002   rdi: ffff830c3dcb8088
(XEN) rbp: ffff830c3dcb7ec8   rsp: ffff830c3dcb7e40   r8: ffff830c3dcb80a0
(XEN) r9:  000014e3652e1b9a   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: 000014e36521c02b   r13: ffff8300a99a2000   r14: ffff830c3dcb8088
(XEN) r15: 00000000000f4240   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1a237000   cr2: 000007fef93521dc
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dcb7e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dcb80a0 0000000200cb7e78
(XEN)    ffff830c3dcb8080 ffff82d0801b5277 ffff8300a99a2000 fffff88002e4ad70
(XEN)    ffff8300a99a2000 00000000000f4240 ffff82d0801e0f00 ffff830c3dcb7f08
(XEN)    ffff82d0802f8100 ffff82d0802f8000 ffffffffffffffff ffff830c3dcb0000
(XEN)    0000000000000001 ffff830c3dcb7ef8 ffff82d08012a1b3 ffff8300a99a2000
(XEN)    fffff88002e4ad70 000037d3e7b7f0a9 000000000000000f ffff830c3dcb7f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 000037d3e7b7f0a9 fffff88002e4ad70 000000000000000f
(XEN)    fffff88002e40180 fffff88002e4ad70 fffff88002e402a0 ffffffffffffffdf
(XEN)    fffff88002e402a0 0000000000000002 fffff88002e401c0 0000000000000400
(XEN)    0000000000000000 fffff88002e4aeb0 0000beef0000beef fffff8000294a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002e4ac20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000002 ffff8300a99a2000 0000003bbd996e00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  ffffffffffffffdf   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 000037d3e7b7f0a9   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  0000000000000001   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 000037d3e7b7f896   r14: 000000000000000f
(XEN) r15: fffff6fc4003b208   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffa9478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff80002e112c3>]
(XEN) RFLAGS: 0000000000000006   CONTEXT: hvm guest
(XEN) rax: 00000000876ba63c   rbx: 00003a4a876bd272   rcx: 000000000000ffff
(XEN) rdx: 0000000000003a4a   rsi: 0000000000000000   rdi: 000000000000002e
(XEN) rbp: 000000000000943d   rsp: fffff880031ea0e0   r8: fffff880031ea140
(XEN) r9:  0000000000000000   r10: fffff880031ea190   r11: 00000003429653d0
(XEN) r12: fffff880031ea518   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000000000000001   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000037d3e7b7f98e   r14: 000000000000000f
(XEN) r15: fffffa8000bcf3d0   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fefb8684ee
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        3787us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=      780451us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=        4953us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=   126582023us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=    13441754us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=        9226us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=       14953us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN) CPU01:
(XEN)   ex=         223us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex=        1028us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=       14953us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=        5271us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN) CPU02:
(XEN)   ex=        1037us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=        6999us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=        5324us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       14953us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN) CPU03:
(XEN)   ex=        5392us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=       14953us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex= 26721226121us timer=ffff830c18437290 
cb=rtc_alarm_cb(ffff830c184371f0)
(XEN)   ex=      340334us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=       30050us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=        5381us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=       14953us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=     1379787us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=       51787us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=       30063us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=        5323us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=       14953us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=   484144725us timer=ffff830c184375d0 
cb=pmt_timer_callback(ffff830c184375a8)
(XEN)   ex=       30075us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a0ce80   rcx: fffff80002a0cec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80000ba6e70
(XEN) rbp: 000000000000000f   rsp: fffff80000ba6be0   r8: fffff80002a0cfa0
(XEN) r9:  000034da77fd3a29   r10: fffff80002a0cfa0   r11: fffff80000ba6d30
(XEN) r12: fffff80000ba6d30   r13: 000037d3e7c82ee7   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: fffff88001333898
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff80002e112c1>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 00003a4fa26b020b   rbx: 00003a4fa26b0c79   rcx: 000000000000ffff
(XEN) rdx: 00003a4f00000000   rsi: 0000000000000000   rdi: 000000000000005d
(XEN) rbp: 000000000000054a   rsp: fffff880031ea0e0   r8: fffff880031ea140
(XEN) r9:  0000000000000000   r10: fffff880031ea190   r11: 00000003429653d0
(XEN) r12: fffff880031ea518   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000000000000001   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000037d3e7b7f98e   r14: 000000000000000f
(XEN) r15: fffffa8000bcf3d0   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fefb8684ee
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a99a2000   rcx: 0000000000000003
(XEN) rdx: ffff830c3dca0000   rsi: 0000000000000004   rdi: ffff830c3dcaa088
(XEN) rbp: ffff830c3dca7ec8   rsp: ffff830c3dca7e40   r8: ffff830c3dcaa0a0
(XEN) r9:  0000000000000000   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: 000014e55456c519   r13: ffff8300a99a2000   r14: ffff830c3dcaa088
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1a237000   cr2: 000007fef93521dc
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dcaa0a0 0000000300ca7e78
(XEN)    ffff830c3dcaa080 ffff82d0801b5277 ffff8300a99a2000 fffff88002e4ad70
(XEN)    ffff8300a99a2000 0000000001c9c380 ffff82d0801e0f00 ffff830c3dca7f08
(XEN)    ffff82d0802f8180 ffff82d0802f8000 ffffffffffffffff ffff830c3dca0000
(XEN)    0000000000000001 ffff830c3dca7ef8 ffff82d08012a1b3 ffff8300a99a2000
(XEN)    fffff88002e4ad70 000037d3e7b7f0a9 000000000000000f ffff830c3dca7f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 000037d3e7b7f0a9 fffff88002e4ad70 000000000000000f
(XEN)    fffff88002e40180 fffff88002e4ad70 fffff88002e402a0 ffffffffffffffdf
(XEN)    fffff88002e402a0 0000000000000002 fffff88002e401c0 0000000000000400
(XEN)    0000000000000000 fffff88002e4aeb0 0000beef0000beef fffff8000294a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002e4ac20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000003 ffff8300a99a2000 0000003bbd988e00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  ffffffffffffffdf   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 000037d3e7b7f0a9   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  0000000000000001   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 000037d3e7b7f896   r14: 000000000000000f
(XEN) r15: fffff6fc4003b208   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffa9478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  fffffffffffffff7   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 000037d3e7b7ffcf   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffdb478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)

Going to continue replying to your next email here, as I'd like to 
minimize my impact on the list.

On 11/21/2014 1:31, Jan Beulich wrote:
>>>> On 20.11.14 at 21:07, <sflist@ihonk.com> wrote:
>> Running with mwait-idle=0 solves (hides?) the problem. Next step is to
>> fiddle with the C states?
> So this also prompted me to go over the list of errata. Just to confirm
> - your CPU is family 6 model 44? What stepping? And what nominal
> frequency?

CPU information for one of the cores, 2.8 GHz is nominal, stepping is 2. 
Not sure how to translate that stepping number into Intel's format:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Intel(R) Xeon(R) CPU           X5660  @ 2.80GHz
stepping        : 2
microcode       : 0x1a
cpu MHz         : 2800.184
cache size      : 12288 KB
physical id     : 0
siblings        : 6
core id         : 0
cpu cores       : 6
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mca cmov pat 
clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good 
nopl nonstop_tsc pni pclmulqdq monitor est ssse3 cx16 sse4_1 sse4_2 
popcnt aes hypervisor lahf_lm ida arat epb dtherm
bogomips        : 5600.36
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:


> There are a couple potentially relevant errata (BC36, BC38, BC54,
> BC77, BC110).
>
> To exclude BC36, a boot log with "apic-verbosity=debug" and debug
> key 'i' output would be necessary.

Done, see the very end of the email.

> BC38 should not affect us since we don't enter C states from ISRs.
>
> BC54 is probably irrelevant since we meanwhile know that your
> system doesn't really hang hard.
>
> For BC77 it would be worth trying to disable turbo mode instead of
> disabling the mwait-idle driver ("xenpm disable-turbo-mode" right
> after boot).

I looked up BC77 but as a result found this document[1], which seems to 
relate to the i7.  Would this[2] not be the relevant document?

[1] 
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/core-i7-900-ee-and-desktop-processor-series-32nm-spec-update.pdf

[2] 
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-5600-specification-update.pdf

In any case, I ran a test with turbo mode disabled via "xenpm 
disable-turbo-mode" and the host hung.

> And BC110 would be relevant only if without the mwait-idle driver
> there would be no use of C3. Plus anyway this would more likely end
> up in a hard hang too.
>
> And then, considering that my system with a family 6 model 44 CPU
> has never shown anything similar (albeit that doesn't mean all that
> much since our workloads are likely very different), you're not
> over-clocking?

No, no overclocking at all.

> And did you disable hyper-threading on purpose (if
> so could you check whether enabling it makes a difference)?

Yes, I disabled HT intentionally. I've tested with it enabled and with 6 
vCPUs assigned to the domU and the host hung. Took quite a bit longer 
than usual to hang, though, 11 hours.

As promised, below is the apic-verbosity=debug log, with 'i'. Thanks!

Steve

  Xen 4.5-unstable
(XEN) Xen version 4.5-unstable (steve@) (gcc (Debian 4.9.1-19) 4.9.1) 
debug=y Thu Nov 20 11:00:27 PST 2014
(XEN) Latest ChangeSet: Thu Sep 18 14:43:49 2014 +0200 git:9a727a8-dirty
(XEN) Bootloader: GRUB 2.02~beta2-15
(XEN) Command line: placeholder cpufreq=xen:ondemand cpuidle 
clocksource=hpet loglvl=all guest_loglvl=all iommu=no-intremap,debug 
com1=115200,8n1 console=com1,vga apic-verbosity=debug
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 2 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d000 (usable)
(XEN)  000000000009d000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf7a0000 (usable)
(XEN)  00000000bf7a0000 - 00000000bf7ca000 (ACPI data)
(XEN)  00000000bf7ca000 - 00000000bf7cc000 (ACPI NVS)
(XEN)  00000000bf7cc000 - 00000000c0000000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000F6A40, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT BF7BF38F, 0084 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: FACP BF7C98D1, 00F4 (r3 LENOVO TC-61     60400D0 PTL         2)
(XEN) ACPI: DSDT BF7BF413, A43A (r1 LENOVO TC-61     60400D0 MSFT 100000E)
(XEN) ACPI: FACS BF7CBFC0, 0040
(XEN) ACPI: SSDT BF7AF33B, 2694 (r1  INTEL PPM RCM  80000001 INTL 20061109)
(XEN) ACPI: SLIT BF7C99E9, 0030 (r1 Intel  TYLERBRG  60400D0 LOHR       5A)
(XEN) ACPI: TCPA BF7C9A19, 0032 (r1 LENOVO TC-61     60400D0 PTL         0)
(XEN) ACPI: SLIC BF7C9A4B, 0176 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: SRAT BF7C9BC1, 00E0 (r1 Intel  Tylerbrg  60400D0 PHX.        1)
(XEN) ACPI: DMAR BF7C9CA1, 01C0 (r1 Intel  OEMDMAR   60400D0 LOHR        1)
(XEN) ACPI: APIC BF7C9E61, 00A0 (r1 PTLTD       APIC    60400D0 
LTP        0)
(XEN) ACPI: MCFG BF7C9F01, 003C (r1 PTLTD    MCFG    60400D0 LTP        0)
(XEN) ACPI: HPET BF7C9F3D, 0038 (r1 PTLTD  HPETTBL   60400D0 LTP        1)
(XEN) ACPI: BOOT BF7C9F75, 0028 (r1 PTLTD  $SBFTBL$  60400D0 LTP        1)
(XEN) ACPI: ASF! BF7C9F9D, 0063 (r32 LENOVO TC-61     60400D0 PTL         1)
(XEN) System RAM: 49143MB (50322676kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: Node 0 PXM 0 0-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-c40000000
(XEN) NUMA: Using 20 for the hash shift.
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000f6a70
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1008
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1004,1:0], pm1x_evt[1:1000,1:0]
(XEN) ACPI:             wakeup_vec[bf7cbfcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(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: 0x8086a301 base: 0xfed00000
(XEN) [VT-D]dmar.c:788: Host address width 40
(XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:472:   dmaru->address = fe710000
(XEN) [VT-D]iommu.c:1145: drhd->address = fe710000 iommu->reg = 
ffff82c000201000
(XEN) [VT-D]iommu.c:1147: cap = c90780106f0462 ecap = f0207f
(XEN) [VT-D]dmar.c:397:  IOAPIC: 0000:f0:1f.7
(XEN) [VT-D]dmar.c:486:   flags: INCLUDE_ALL
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.1
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.7
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.1
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.2
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.3
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7cd000 end_address 
bf7dbfff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e4000 end_address 
bf7e4fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.1
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e5000 end_address 
bf7e5fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7ea000 end_address 
bf7eafff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e6000 end_address 
bf7e6fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.1
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e7000 end_address 
bf7e7fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.2
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e8000 end_address 
bf7e8fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.3
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e9000 end_address 
bf7e9fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7eb000 end_address 
bf7ebfff
(XEN) [VT-D]dmar.c:812: found ACPI_DMAR_ATSR:
(XEN) [VT-D]dmar.c:705:   atsru->all_ports: 0
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:01.0 start=0 sec=1 sub=1
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:03.0 start=0 sec=2 sub=2
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:07.0 start=0 sec=3 sub=3
(XEN) ERST table was not found
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 6 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 1144 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2800.166 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) alt table ffff82d0802d1cd0 -> ffff82d0802d2cf0
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 09
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-09
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB.
(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 not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping disabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 64 KiB.
(XEN) mwait-idle: MWAIT substates: 0x1120
(XEN) mwait-idle: v0.4 model 0x2c
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 6 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x7c8000
(XEN) elf_parse_binary: phdr: paddr=0x1800000 memsz=0xed000
(XEN) elf_parse_binary: phdr: paddr=0x18ed000 memsz=0x14f40
(XEN) elf_parse_binary: phdr: paddr=0x1902000 memsz=0x614000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x1f16000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff819021f0
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = 
"!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
(XEN) elf_xen_parse_note: SUPPORTED_FEATURES = 0x90d
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff81f16000
(XEN)     virt_entry       = 0xffffffff819021f0
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f16000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c00000000->0000000c10000000 (12316675 pages 
to be allocated)
(XEN)  Init. ramdisk: 0000000c3f0da000->0000000c3ffff86e
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81f16000
(XEN)  Init. ramdisk: ffffffff81f16000->ffffffff82e3b86e
(XEN)  Phys-Mach map: ffffffff82e3c000->ffffffff88cbb948
(XEN)  Start info:    ffffffff88cbc000->ffffffff88cbc4b4
(XEN)  Page tables:   ffffffff88cbd000->ffffffff88d08000
(XEN)  Boot stack:    ffffffff88d08000->ffffffff88d09000
(XEN)  TOTAL:         ffffffff80000000->ffffffff89000000
(XEN)  ENTRY ADDRESS: ffffffff819021f0
(XEN) Dom0 has maximum 6 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff817c8000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81800000 -> 0xffffffff818ed000
(XEN) elf_load_binary: phdr 2 at 0xffffffff818ed000 -> 0xffffffff81901f40
(XEN) elf_load_binary: phdr 3 at 0xffffffff81902000 -> 0xffffffff81a1f000
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:00:00.0 map
(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:14.0
(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:14.1
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:14.2
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.1
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.2
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.3
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.4
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.5
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.6
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.7
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1a.0
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1a.1
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1a.7
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:1b.0
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1d.0
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1d.1
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1d.2
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1d.3
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1d.7
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1f.0
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1f.2
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1f.3
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:01:00.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:02:00.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:05:00.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:09:00.0
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:0a:0e.0
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:00.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:00.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.2 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.3 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.4 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.5 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:03.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:03.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:03.2 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:03.4 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:04.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:04.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:04.2 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:04.3 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:05.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:05.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:05.2 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:05.3 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:06.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:06.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:06.2 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:06.3 map
(XEN) [VT-D]iommu.c:738: iommu_enable_translation: iommu->reg = 
ffff82c000201000
(XEN) Scrubbing Free RAM on 1 nodes using 6 CPUs
(XEN) 
..................................................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch 
input to Xen)
(XEN) Freed 288kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.16-3-amd64 
(debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-12) ) 
#1 SMP Debian 3.16.5-1 (2014-10-10)
[    0.000000] Command line: placeholder 
root=/dev/mapper/vg_g2-lv_g2_root ro console=hvc0 earlyprintk=serial 
xencons=hvc debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 
LOGLEVEL=8 sched_debug
[    0.000000] Freeing 9d-100 pfn range: 99 pages freed
[    0.000000] Freeing bf7a0-100000 pfn range: 264288 pages freed
[    0.000000] Released 264387 pages of unused memory
[    0.000000] Set 264387 page(s) to 1-1 mapping
[    0.000000] Populating bcff29-c107ec pfn range: 264387 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
[    0.000000] Xen: [mem 0x000000000009d000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000bf79ffff] usable
[    0.000000] Xen: [mem 0x00000000bf7a0000-0x00000000bf7c9fff] ACPI data
[    0.000000] Xen: [mem 0x00000000bf7ca000-0x00000000bf7cbfff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000bf7cc000-0x00000000bfffffff] reserved
[    0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved
[    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000c3fffffff] usable
[    0.000000] bootconsole [earlyser0] enabled
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.6 present.
[    0.000000] DMI: LENOVO 4158WRG/LENOVO, BIOS 61KT50AUS 01/14/2014
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] AGP: No AGP bridge found
[    0.000000] e820: last_pfn = 0xc40000 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xbf7a0 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] init_memory_mapping: [mem 0xc10400000-0xc105fffff]
[    0.000000]  [mem 0xc10400000-0xc105fffff] page 4k
[    0.000000] BRK [0x01b61000, 0x01b61fff] PGTABLE
[    0.000000] BRK [0x01b62000, 0x01b62fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0xc10000000-0xc103fffff]
[    0.000000]  [mem 0xc10000000-0xc103fffff] page 4k
[    0.000000] BRK [0x01b63000, 0x01b63fff] PGTABLE
[    0.000000] BRK [0x01b64000, 0x01b64fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0xc00000000-0xc0fffffff]
[    0.000000]  [mem 0xc00000000-0xc0fffffff] page 4k
[    0.000000] BRK [0x01b65000, 0x01b65fff] PGTABLE
[    0.000000] BRK [0x01b66000, 0x01b66fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x00100000-0xbf79ffff]
[    0.000000]  [mem 0x00100000-0xbf79ffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x100000000-0xbffffffff]
[    0.000000]  [mem 0x100000000-0xbffffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0xc10600000-0xc3fffffff]
[    0.000000]  [mem 0xc10600000-0xc3fffffff] page 4k
[    0.000000] log_buf_len: 16777216
[    0.000000] early log buf free: 127372(97%)
[    0.000000] RAMDISK: [mem 0x01f16000-0x02e3bfff]
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000000F6A40 000024 (v02 PTLTD )
[    0.000000] ACPI: XSDT 0x00000000BF7BF38F 000084 (v01 LENOVO TC-61    
060400D0  LTP 00000000)
[    0.000000] ACPI: FACP 0x00000000BF7C98D1 0000F4 (v03 LENOVO TC-61    
060400D0 PTL  00000002)
[    0.000000] ACPI: DSDT 0x00000000BF7BF413 00A43A (v01 LENOVO TC-61    
060400D0 MSFT 0100000E)
[    0.000000] ACPI: FACS 0x00000000BF7CBFC0 000040
[    0.000000] ACPI: SSDT 0x00000000BF7AF33B 002694 (v01 INTEL  PPM RCM  
80000001 INTL 20061109)
[    0.000000] ACPI: SLIT 0x00000000BF7C99E9 000030 (v01 Intel TYLERBRG 
060400D0 LOHR 0000005A)
[    0.000000] ACPI: TCPA 0x00000000BF7C9A19 000032 (v01 LENOVO TC-61    
060400D0 PTL  00000000)
[    0.000000] ACPI: SLIC 0x00000000BF7C9A4B 000176 (v01 LENOVO TC-61    
060400D0  LTP 00000000)
[    0.000000] ACPI: SRAT 0x00000000BF7C9BC1 0000E0 (v01 Intel Tylerbrg 
060400D0 PHX. 00000001)
[    0.000000] ACPI: XMAR 0x00000000BF7C9CA1 0001C0 (v01 Intel OEMDMAR  
060400D0 LOHR 00000001)
[    0.000000] ACPI: APIC 0x00000000BF7C9E61 0000A0 (v01 PTLTD  ? APIC   
060400D0  LTP 00000000)
[    0.000000] ACPI: MCFG 0x00000000BF7C9F01 00003C (v01 PTLTD MCFG   
060400D0  LTP 00000000)
[    0.000000] ACPI: HPET 0x00000000BF7C9F3D 000038 (v01 PTLTD HPETTBL  
060400D0  LTP 00000001)
[    0.000000] ACPI: BOOT 0x00000000BF7C9F75 000028 (v01 PTLTD $SBFTBL$ 
060400D0  LTP 00000001)
[    0.000000] ACPI: ASF! 0x00000000BF7C9F9D 000063 (v32 LENOVO TC-61    
060400D0 PTL  00000001)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000c3fffffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0xc3fffffff]
[    0.000000]   NODE_DATA [mem 0xc107e7000-0xc107ebfff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0xc3fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009cfff]
[    0.000000]   node   0: [mem 0x00100000-0xbf79ffff]
[    0.000000]   node   0: [mem 0x100000000-0xc3fffffff]
[    0.000000] On node 0 totalpages: 12580668
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 21 pages reserved
[    0.000000]   DMA zone: 3996 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 10667 pages used for memmap
[    0.000000]   DMA32 zone: 780192 pages, LIFO batch:31
[    0.000000]   Normal zone: 161280 pages used for memmap
[    0.000000]   Normal zone: 11796480 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 
0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[    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: 0x8086a301 base: 0xfed00000
[    0.000000] smpboot: Allowing 6 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 40
[    0.000000] PM: Registered nosave memory: [mem 0x0009d000-0x000fffff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7a0000-0xbf7c9fff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7ca000-0xbf7cbfff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7cc000-0xbfffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xc0000000-0xf7ffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xf8000000-0xfbffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfc000000-0xfebfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfec0ffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfec10000-0xfedfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfeefffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfef00000-0xfeffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xff000000-0xffffffff]
[    0.000000] e820: [mem 0xc0000000-0xf7ffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.5-unstable (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 
nr_cpu_ids:6 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880c03400000 s85824 
r8192 d20672 u262144
[    0.000000] pcpu-alloc: s85824 r8192 d20672 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 - -
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  
Total pages: 12408644
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: placeholder 
root=/dev/mapper/vg_g2-lv_g2_root ro console=hvc0 earlyprintk=serial 
xencons=hvc debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 
LOGLEVEL=8 sched_debug
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] software IO TLB [mem 0xbd4e00000-0xbd8e00000] (64MB) 
mapped at [ffff880bd4e00000-ffff880bd8dfffff]
[    0.000000] Memory: 48548972K/50322672K available (5189K kernel code, 
942K rwdata, 1824K rodata, 1200K init, 840K bss, 1773700K reserved)
[    0.000000] Hierarchical RCU implementation.
[    0.000000]     RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000]     RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=6.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6
[    0.000000] NR_IRQS:33024 nr_irqs:728 16
[    0.000000] xen:events: Using FIFO-based ABI
[    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: --> 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 [hvc0] enabled

[    0.000000] console [hvc0] enabled
[    0.000000] bootconsole [earlyser0] disabled

[    0.000000] bootconsole [earlyser0] disabled
[    0.000000] bootconsole [xenboot0] disabled

[    0.000000] bootconsole [xenboot0] disabled
[    0.000000] Xen: using vcpuop timer interface

[    0.000000] installing Xen timer for CPU 0

[    0.000000] tsc: Detected 2800.166 MHz processor

[   10.913942] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 5600.33 BogoMIPS (lpj=11200664)

[   10.913948] pid_max: default: 32768 minimum: 301

[   10.913957] ACPI: Core revision 20140424

[   10.918311] ACPI: All ACPI Tables successfully acquired

[   10.925345] Security Framework initialized

[   10.925354] AppArmor: AppArmor disabled by boot time parameter

[   10.925357] Yama: disabled by default; enable with sysctl kernel.yama.*

[   10.933807] Dentry cache hash table entries: 8388608 (order: 14, 
67108864 bytes)

[   11.051238] Inode-cache hash table entries: 4194304 (order: 13, 
33554432 bytes)

[   11.055771] Mount-cache hash table entries: 131072 (order: 8, 1048576 
bytes)

[   11.055917] Mountpoint-cache hash table entries: 131072 (order: 8, 
1048576 bytes)

[   11.056359] Initializing cgroup subsys memory

[   11.056365] Initializing cgroup subsys devices

[   11.056372] Initializing cgroup subsys freezer

[   11.056376] Initializing cgroup subsys net_cls

[   11.056380] Initializing cgroup subsys blkio

[   11.056385] Initializing cgroup subsys perf_event

[   11.056388] Initializing cgroup subsys net_prio

[   11.056437] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'

[   11.056437] ENERGY_PERF_BIAS: View and update with 
x86_energy_perf_policy(8)

[   11.056443] CPU: Physical Processor ID: 0

[   11.056445] CPU: Processor Core ID: 0

[   11.056448] mce: CPU supports 2 MCE banks

[   11.056462] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7

[   11.056462] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0

[   11.056462] tlb_flushall_shift: 6

[   11.056527] Freeing SMP alternatives memory: 20K (ffffffff81a19000 - 
ffffffff81a1e000)

[   11.057351] ftrace: allocating 21546 entries in 85 pages

[   11.064078] Performance Events: unsupported p6 CPU model 44 no PMU 
driver, software events only.

[   11.065170] NMI watchdog: disabled (cpu0): hardware events not enabled

[   11.065246] installing Xen timer for CPU 1

[   11.065590] installing Xen timer for CPU 2

[   11.065965] installing Xen timer for CPU 3

[   11.066389] installing Xen timer for CPU 4

[   11.066751] installing Xen timer for CPU 5

[   11.066998] x86: Booted up 1 node, 6 CPUs

[   11.067017] CPU0 attaching sched-domain:

[   11.067020]  domain 0: span 0-5 level MC

[   11.067022]   groups: 0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 
2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 
5 (cpu_capacity = 1023)

[   11.067033] CPU1 attaching sched-domain:

[   11.067035]  domain 0: span 0-5 level MC

[   11.067037]   groups: 1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 
3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 
0 (cpu_capacity = 1023)

[   11.067047] CPU2 attaching sched-domain:

[   11.067049]  domain 0: span 0-5 level MC

[   11.067051]   groups: 2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 
4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 
1 (cpu_capacity = 1023)

[   11.067061] CPU3 attaching sched-domain:

[   11.067063]  domain 0: span 0-5 level MC

[   11.067065]   groups: 3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 
5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 
2 (cpu_capacity = 1023)

[   11.067075] CPU4 attaching sched-domain:

[   11.067077]  domain 0: span 0-5 level MC

[   11.067079]   groups: 4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 
0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 
3 (cpu_capacity = 1023)

[   11.067089] CPU5 attaching sched-domain:

[   11.067091]  domain 0: span 0-5 level MC

[   11.067093]   groups: 5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 
1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 
4 (cpu_capacity = 1023)

[   11.067472] devtmpfs: initialized

[   11.073663] PM: Registering ACPI NVS region [mem 
0xbf7ca000-0xbf7cbfff] (8192 bytes)

[   11.074540] pinctrl core: initialized pinctrl subsystem

[   11.074698] NET: Registered protocol family 16

[   11.074711] xen:grant_table: Grant tables using version 1 layout

[   11.074725] Grant table initialized

[   11.075185] ACPI FADT declares the system doesn't support PCIe ASPM, 
so disable it

[   11.075189] ACPI: bus type PCI registered

[   11.075192] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5

[   11.075445] PCI: MMCONFIG for domain 0000 [bus 00-09] at [mem 
0xf8000000-0xf89fffff] (base 0xf8000000)

[   11.075450] PCI: MMCONFIG at [mem 0xf8000000-0xf89fffff] reserved in E820

[   11.076571] PCI: Using configuration type 1 for base access

[   11.089430] ACPI: Added _OSI(Module Device)

[   11.089434] ACPI: Added _OSI(Processor Device)

[   11.089436] ACPI: Added _OSI(3.0 _SCP Extensions)

[   11.089438] ACPI: Added _OSI(Processor Aggregator Device)

[   11.092694] ACPI: Interpreter enabled

[   11.092700] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep 
State [\_S1_] (20140424/hwxface-580)

[   11.092706] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep 
State [\_S2_] (20140424/hwxface-580)

[   11.092717] ACPI: (supports S0 S3 S4 S5)

[   11.092719] ACPI: Using IOAPIC for interrupt routing

[   11.092741] PCI: Using host bridge windows from ACPI; if necessary, 
use "pci=nocrs" and report a bug

[   11.108183] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])

[   11.108191] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM 
ClockPM Segments MSI]

[   11.108401] acpi PNP0A03:00: _OSC: OS now controls [PCIeHotplug PME 
AER PCIeCapability]

[   11.109031] acpi PNP0A03:00: [Firmware Info]: MMCONFIG for domain 
0000 [bus 00-09] only partially covers this bridge

[   11.109200] PCI host bridge to bus 0000:00

[   11.109204] pci_bus 0000:00: root bus resource [bus 00-ff]

[   11.109207] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7]

[   11.109210] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff]

[   11.109212] pci_bus 0000:00: root bus resource [mem 
0x000a0000-0x000bffff]

[   11.109215] pci_bus 0000:00: root bus resource [mem 
0x000d0000-0x000d3fff]

[   11.109218] pci_bus 0000:00: root bus resource [mem 
0x000d4000-0x000d7fff]

[   11.109221] pci_bus 0000:00: root bus resource [mem 
0x000d8000-0x000dbfff]

[   11.109224] pci_bus 0000:00: root bus resource [mem 
0x000dc000-0x000dffff]

[   11.109227] pci_bus 0000:00: root bus resource [mem 
0xc0000000-0xfdffffff]

[   11.109245] pci 0000:00:00.0: [8086:3406] type 00 class 0x060000

[   11.109341] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold

(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) PCI add device 0000:00:00.0
[   11.109451] pci 0000:00:01.0: [8086:3408] type 01 class 0x060400

[   11.109556] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold

[   11.109603] pci 0000:00:01.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) PCI add device 0000:00:01.0
[   11.109668] pci 0000:00:03.0: [8086:340a] type 01 class 0x060400

[   11.109781] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold

[   11.109830] pci 0000:00:03.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) PCI add device 0000:00:03.0
[   11.109898] pci 0000:00:07.0: [8086:340e] type 01 class 0x060400

[   11.109995] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold

[   11.110045] pci 0000:00:07.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) PCI add device 0000:00:07.0
[   11.110117] pci 0000:00:14.0: [8086:342e] type 00 class 0x080000

(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) PCI add device 0000:00:14.0
[   11.110272] pci 0000:00:14.1: [8086:3422] type 00 class 0x080000

(XEN) PCI add device 0000:00:14.1
[   11.110443] pci 0000:00:14.2: [8086:3423] type 00 class 0x080000

(XEN) PCI add device 0000:00:14.2
[   11.110605] pci 0000:00:16.0: [8086:3430] type 00 class 0x088000

[   11.110626] pci 0000:00:16.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.0
[   11.110786] pci 0000:00:16.1: [8086:3431] type 00 class 0x088000

[   11.110806] pci 0000:00:16.1: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.1
[   11.110964] pci 0000:00:16.2: [8086:3432] type 00 class 0x088000

[   11.110985] pci 0000:00:16.2: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.2
[   11.111143] pci 0000:00:16.3: [8086:3433] type 00 class 0x088000

[   11.111164] pci 0000:00:16.3: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.3
[   11.111324] pci 0000:00:16.4: [8086:3429] type 00 class 0x088000

[   11.111344] pci 0000:00:16.4: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.4
[   11.111503] pci 0000:00:16.5: [8086:342a] type 00 class 0x088000

[   11.111523] pci 0000:00:16.5: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.5
[   11.111682] pci 0000:00:16.6: [8086:342b] type 00 class 0x088000

[   11.111703] pci 0000:00:16.6: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.6
[   11.111881] pci 0000:00:16.7: [8086:342c] type 00 class 0x088000

[   11.111902] pci 0000:00:16.7: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.7
[   11.112063] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c0300

[   11.112131] pci 0000:00:1a.0: reg 0x20: [io  0x1800-0x181f]

[   11.112236] pci 0000:00:1a.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.0
[   11.112294] pci 0000:00:1a.1: [8086:3a38] type 00 class 0x0c0300

[   11.112387] pci 0000:00:1a.1: reg 0x20: [io  0x1820-0x183f]

[   11.112515] pci 0000:00:1a.1: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.1
[   11.112585] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0320

[   11.112617] pci 0000:00:1a.7: reg 0x10: [mem 0xec604000-0xec6043ff]

[   11.112755] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold

[   11.112800] pci 0000:00:1a.7: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.7
[   11.112858] pci 0000:00:1b.0: [8086:3a3e] type 00 class 0x040300

[   11.112884] pci 0000:00:1b.0: reg 0x10: [mem 0xec600000-0xec603fff 64bit]

[   11.113000] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold

(XEN) PCI add device 0000:00:1b.0
[   11.113091] pci 0000:00:1c.0: [8086:3a40] type 01 class 0x060400

[   11.113225] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold

[   11.113273] pci 0000:00:1c.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.0
[   11.113330] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x060400

[   11.113449] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold

[   11.113497] pci 0000:00:1c.4: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.4
[   11.113549] pci 0000:00:1c.5: [8086:3a4a] type 01 class 0x060400

[   11.113668] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold

[   11.113717] pci 0000:00:1c.5: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.5
[   11.113780] pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300

[   11.113848] pci 0000:00:1d.0: reg 0x20: [io  0x1840-0x185f]

[   11.113955] pci 0000:00:1d.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.0
[   11.114008] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300

[   11.114076] pci 0000:00:1d.1: reg 0x20: [io  0x1860-0x187f]

[   11.114182] pci 0000:00:1d.1: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.1
[   11.114240] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300

[   11.114331] pci 0000:00:1d.2: reg 0x20: [io  0x1880-0x189f]

[   11.114461] pci 0000:00:1d.2: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.2
[   11.114538] pci 0000:00:1d.3: [8086:3a39] type 00 class 0x0c0300

[   11.114622] pci 0000:00:1d.3: reg 0x20: [io  0x18a0-0x18bf]

[   11.114726] pci 0000:00:1d.3: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.3
[   11.114790] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320

[   11.114823] pci 0000:00:1d.7: reg 0x10: [mem 0xec605000-0xec6053ff]

[   11.114960] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold

[   11.115005] pci 0000:00:1d.7: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.7
[   11.115056] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401

[   11.115166] pci 0000:00:1e.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1e.0
[   11.115218] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x060100

(XEN) PCI add device 0000:00:1f.0
[   11.115446] pci 0000:00:1f.2: [8086:3a22] type 00 class 0x010601

[   11.115477] pci 0000:00:1f.2: reg 0x10: [io  0x18f0-0x18f7]

[   11.115490] pci 0000:00:1f.2: reg 0x14: [io  0x18e4-0x18e7]

[   11.115503] pci 0000:00:1f.2: reg 0x18: [io  0x18e8-0x18ef]

[   11.115516] pci 0000:00:1f.2: reg 0x1c: [io  0x18e0-0x18e3]

[   11.115528] pci 0000:00:1f.2: reg 0x20: [io  0x18c0-0x18df]

[   11.115541] pci 0000:00:1f.2: reg 0x24: [mem 0xec606000-0xec6067ff]

[   11.115617] pci 0000:00:1f.2: PME# supported from D3hot

(XEN) PCI add device 0000:00:1f.2
[   11.115703] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500

[   11.115728] pci 0000:00:1f.3: reg 0x10: [mem 0xec607000-0xec6070ff 64bit]

[   11.115762] pci 0000:00:1f.3: reg 0x20: [io  0x1100-0x111f]

(XEN) PCI add device 0000:00:1f.3
[   11.115968] pci 0000:01:00.0: [11ab:6485] type 00 class 0x010400

[   11.116011] pci 0000:01:00.0: reg 0x18: [io  0x2000-0x207f]

[   11.116041] pci 0000:01:00.0: reg 0x20: [mem 0xec000000-0xec00ffff 64bit]

[   11.116055] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0003ffff pref]

[   11.116117] pci 0000:01:00.0: supports D1

[   11.116119] pci 0000:01:00.0: PME# supported from D0 D1 D3hot

[   11.116150] pci 0000:01:00.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:01:00.0
[   11.121894] pci 0000:00:01.0: PCI bridge to [bus 01]

[   11.121909] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]

[   11.121920] pci 0000:00:01.0:   bridge window [mem 0xec000000-0xec0fffff]

[   11.122054] pci 0000:02:00.0: [10de:05fe] type 00 class 0x030000

[   11.122071] pci 0000:02:00.0: reg 0x10: [mem 0xea000000-0xeaffffff]

[   11.122087] pci 0000:02:00.0: reg 0x14: [mem 0xd0000000-0xdfffffff 
64bit pref]

[   11.1[   11.886737] tg3 0000:05:00.0: no hotplug settings from platform

[   11.886873] pci_bus 0000:07: Allocating resources

[   11.886956] pcieport 0000:06:00.0: bridge window [io 0x1000-0x0fff] 
to [bus 07-09] add_size 1000

[   11.886961] pcieport 0000:06:00.0: bridge window [mem 
0x00100000-0x000fffff 64bit pref] to [bus 07-09] add_size 200000

[   11.886966] pcieport 0000:06:00.0: res[15]=[mem 0x00100000-0x000fffff 
64bit pref] get_res_add_size add_size 200000

[   11.886970] pcieport 0000:06:00.0: res[13]=[io  0x1000-0x0fff] 
get_res_add_size add_size 1000

[   11.886976] pcieport 0000:06:00.0: BAR 15: assigned [mem 
0xc0600000-0xc07fffff 64bit pref]

[   11.886979] pcieport 0000:06:00.0: BAR 13: assigned [io 0x7000-0x7fff]

[   11.887002] pcieport 0000:06:00.0: no hotplug settings from platform

[   11.887024] pcieport 0000:07:02.0: no hotplug settings from platform

[   11.887045] pcieport 0000:07:03.0: no hotplug settings from platform

[   11.887059] tg3 0000:09:00.0: no hotplug settings from platform

[   11.994139] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[   11.994195] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

[   11.994218] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[   11.997794] ata2.00: ATAPI: HL-DT-STDVD-RAM GH60N, NY02, max UDMA/100

[   12.000368] ata1.00: ATA-8: WDC WD3000BLFS-08YBU0, 04.04V04, max UDMA/100

[   12.000376] ata1.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 
31/32), AA

[   12.000605] ata3.00: ATA-8: WDC WD3000BLFS-08YBU0, 04.04V04, max UDMA/100

[   12.000633] ata3.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 
31/32), AA

[   12.002074] ata2.00: configured for UDMA/100

[   12.006362] ata1.00: configured for UDMA/100

[   12.006685] scsi 1:0:0:0: Direct-Access     ATA      WDC WD3000BLFS-0 
4V04 PQ: 0 ANSI: 5

[   12.007576] ata3.00: configured for UDMA/100

[   12.010795] scsi 2:0:0:0: CD-ROM            HL-DT-ST DVD-RAM GH60N    
NY02 PQ: 0 ANSI: 5

[   12.020253] scsi 3:0:0:0: Direct-Access     ATA      WDC WD3000BLFS-0 
4V04 PQ: 0 ANSI: 5

[   12.023987] sd 1:0:0:0: [sda] 586072368 512-byte logical blocks: (300 
GB/279 GiB)

[   12.024095] sd 1:0:0:0: [sda] Write Protect is off

[   12.024099] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00

[   12.024137] sd 1:0:0:0: [sda] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA

[   12.026873] sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw 
xa/form2 cdda tray

[   12.026877] cdrom: Uniform CD-ROM driver Revision: 3.20

[   12.027026] sr 2:0:0:0: Attached scsi CD-ROM sr0

[   12.027143] sd 3:0:0:0: [sdb] 586072368 512-byte logical blocks: (300 
GB/279 GiB)

[   12.027173] sd 3:0:0:0: [sdb] Write Protect is off

[   12.027177] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00

[   12.027190] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA

[   12.027657] sd 1:0:0:0: Attached scsi generic sg0 type 0

[   12.027714] sr 2:0:0:0: Attached scsi generic sg1 type 5

[   12.027760] sd 3:0:0:0: Attached scsi generic sg2 type 0

[   12.033518]  sdb: sdb1 sdb2

[   12.033848] sd 3:0:0:0: [sdb] Attached SCSI disk

[   12.035876]  sda: sda1 sda2

[   12.036699] sd 1:0:0:0: [sda] Attached SCSI disk

[   12.115971] md: bind<sdb1>

[   12.116953] md: bind<sdb2>

[   12.120452] md: bind<sda1>

[   12.132123] md: raid1 personality registered for level 1

[   12.132627] md/raid1:md0: active with 2 out of 2 mirrors

[   12.132652] md0: detected capacity change from 0 to 536805376

[   12.132993]  md0: unknown partition table

[   12.138313] md: bind<sda2>

[   12.140816] md/raid1:md1: active with 2 out of 2 mirrors

[   12.140884] created bitmap (3 pages) for device md1

[   12.141017] md1: bitmap initialized from disk: read 1 pages, set 0 of 
4462 bits

[   12.149347] md1: detected capacity change from 0 to 299396562944

[   12.165820]  md1: unknown partition table

[   12.207392] usb 1-4: New USB device found, idVendor=0bda, idProduct=0181

[   12.207402] usb 1-4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[   12.207408] usb 1-4: Product: USB2.0-CRW

[   12.207413] usb 1-4: Manufacturer: Generic

[   12.207417] usb 1-4: SerialNumber: 20060413092100000

[   12.215524] usb-storage 1-4:1.0: USB Mass Storage device detected

[   12.215864] scsi7 : usb-storage 1-4:1.0

[   12.215924] usbcore: registered new interface driver usb-storage

[   12.506248] usb 6-2: new low-speed USB device number 2 using uhci_hcd

[   12.693319] usb 6-2: New USB device found, idVendor=17ef, idProduct=6009

[   12.693329] usb 6-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0

[   12.693336] usb 6-2: Product: ThinkPad USB Keyboard with TrackPoint

[   12.693342] usb 6-2: Manufacturer: Lite-On Technology Corp.

[   12.698056] hidraw: raw HID events driver (C) Jiri Kosina

[   12.743346] usbcore: registered new interface driver usbhid

[   12.743353] usbhid: USB HID core driver

[   12.744735] input: Lite-On Technology Corp. ThinkPad USB Keyboard 
with TrackPoint as 
/devices/pci0000:00/0000:00:1d.2/usb6/6-2/6-2:1.0/0003:17EF:6009.0001/input/input2

[   12.744927] lenovo_tpkbd 0003:17EF:6009.0001: input,hidraw0: USB HID 
v1.10 Keyboard [Lite-On Technology Corp. ThinkPad USB Keyboard with 
TrackPoint] on usb-0000:00:1d.2-2/input0

[   12.761360] input: Lite-On Technology Corp. ThinkPad USB Keyboard 
with TrackPoint as 
/devices/pci0000:00/0000:00:1d.2/usb6/6-2/6-2:1.1/0003:17EF:6009.0002/input/input3

[   12.762013] lenovo_tpkbd 0003:17EF:6009.0002: input,hiddev0,hidraw1: 
USB HID v1.10 Mouse [Lite-On Technology Corp. ThinkPad USB Keyboard with 
TrackPoint] on usb-0000:00:1d.2-2/input1

[   13.217937] scsi 7:0:0:0: Direct-Access     Generic- Compact Flash    
1.00 PQ: 0 ANSI: 0 CCS

[   13.221024] scsi 7:0:0:1: Direct-Access     Generic- SM/xD-Picture    
1.00 PQ: 0 ANSI: 0 CCS

[   13.224150] scsi 7:0:0:2: Direct-Access     Generic- SD/MMC           
1.00 PQ: 0 ANSI: 0 CCS

[   13.227396] scsi 7:0:0:3: Direct-Access     Generic- MS/MS-Pro/HG     
1.00 PQ: 0 ANSI: 0 CCS

[   13.228034] sd 7:0:0:0: Attached scsi generic sg3 type 0

[   13.228345] sd 7:0:0:1: Attached scsi generic sg4 type 0

[   13.228574] sd 7:0:0:2: Attached scsi generic sg5 type 0

[   13.228785] sd 7:0:0:3: Attached scsi generic sg6 type 0

[   13.346389] sd 7:0:0:1: [sdd] Attached SCSI removable disk

[   13.349011] sd 7:0:0:2: [sde] Attached SCSI removable disk

[   13.351524] sd 7:0:0:3: [sdf] Attached SCSI removable disk

[   13.354008] sd 7:0:0:0: [sdc] Attached SCSI removable disk

[   14.394199] random: nonblocking pool is initialized

[   16.542191] scsi0 : mvsas

[   20.145393] device-mapper: uevent: version 1.0.3

[   20.145537] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) 
initialised: dm-devel@redhat.com

[   20.402023] PM: Starting manual resume from disk

[   20.402038] PM: Hibernation image partition 253:1 present

[   20.402040] PM: Looking for hibernation image.

[   20.402260] PM: Image not found (code -22)

[   20.402268] PM: Hibernation image not present or could not be loaded.

[   20.428292] EXT4-fs (dm-0): mounted filesystem with ordered data 
mode. Opts: (null)


INIT: version 2.88 booting


[info] Using makefile-style concurrent boot in runlevel S.

calling: info

[....] Starting the hotplug events dispatcher: udevd[   21.400512] 
systemd-udevd[385]: starting version 215

[?25l[?1c7[ ok 8[?25h[?0c.

[....] Synthesizing the initial hotplug events...calling: trigger

[?25l[?1c7[ ok 8[?25h[?0cdone.

[....] Waiting for /dev to be fully populated...calling: settle

[   21.753344] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4

[   21.765849] dca service started, version 1.12.1

[   21.778668] EDAC MC: Ver: 3.0.0

[   21.783168] Monitor-Mwait will be used to enter C-1 state

[   21.783245] Monitor-Mwait will be used to enter C-3 state

[   21.783295] Monitor-Mwait will be used to enter C-3 state

[   21.786434] Warning: Processor Platform Limit not supported.

[   21.797492] ioatdma: Intel(R) QuickData Technology Driver 4.00

[   21.797594] ioatdma 0000:00:16.0: enabling device (0000 -> 0002)

[   21.797772] ioatdma 0000:00:16.0: can't derive routing for PCI INT A

[   21.797776] ioatdma 0000:00:16.0: PCI INT A: no GSI

[   21.797986] ioatdma 0000:00:16.1: enabling device (0000 -> 0002)

[   21.798177] ioatdma 0000:00:16.1: can't derive routing for PCI INT B

[   21.798181] ioatdma 0000:00:16.1: PCI INT B: no GSI

[   21.798368] ioatdma 0000:00:16.2: enabling device (0000 -> 0002)

[   21.798545] ioatdma 0000:00:16.2: can't derive routing for PCI INT C

[   21.798548] ioatdma 0000:00:16.2: PCI INT C: no GSI

[   21.798739] ioatdma 0000:00:16.3: enabling device (0000 -> 0002)

[   21.798914] ioatdma 0000:00:16.3: can't derive routing for PCI INT D

[   21.798918] ioatdma 0000:00:16.3: PCI INT D: no GSI

[   21.799112] ioatdma 0000:00:16.4: enabling device (0000 -> 0002)

[   21.799287] ioatdma 0000:00:16.4: can't derive routing for PCI INT A

[   21.799291] ioatdma 0000:00:16.4: PCI INT A: no GSI

[   21.799471] ioatdma 0000:00:16.5: enabling device (0000 -> 0002)

[   21.799646] ioatdma 0000:00:16.5: can't derive routing for PCI INT B

[   21.799650] ioatdma 0000:00:16.5: PCI INT B: no GSI

[   21.799841] ioatdma 0000:00:16.6: enabling device (0000 -> 0002)

[   21.800039] ioatdma 0000:00:16.6: can't derive routing for PCI INT C

[   21.800042] ioatdma 0000:00:16.6: PCI INT C: no GSI

[   21.800235] ioatdma 0000:00:16.7: enabling device (0000 -> 0002)

[   21.800410] ioatdma 0000:00:16.7: can't derive routing for PCI INT D

[   21.800414] ioatdma 0000:00:16.7: PCI INT D: no GSI

[   21.823210] input: Power Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0C:00/input/input4

[   21.823218] ACPI: Power Button [PWRB]

[   21.823257] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5

[   21.823261] ACPI: Power Button [PWRF]

[   21.826900] wmi: Mapper loaded

[   21.868557] tpm_tis 00:00: 1.2 TPM (device-id 0x1002, rev-id 2)

[   21.886793] ACPI Warning: SystemIO range 
0x0000000000001028-0x000000000000102f conflicts with OpRegion 
0x0000000000001000-0x000000000000102f (\_SB_.PCI0.LPC0.PMIO) 
(20140424/utaddress-258)

[   21.886803] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   21.886809] ACPI Warning: SystemIO range 
0x00000000000011b0-0x00000000000011bf conflicts with OpRegion 
0x0000000000001180-0x00000000000011bf (\_SB_.PCI0.LPC0.GPOX) 
(20140424/utaddress-258)

[   21.886816] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   21.886819] ACPI Warning: SystemIO range 
0x0000000000001180-0x00000000000011af conflicts with OpRegion 
0x0000000000001180-0x00000000000011bf (\_SB_.PCI0.LPC0.GPOX) 
(20140424/utaddress-258)

[   21.886826] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   21.886829] lpc_ich: Resource conflict(s) found affecting gpio_ich

[   21.947151] xen: registering gsi 16 triggering 0 polarity 1

[   21.947158] Already setup the GSI :16

[   21.983732] xen: registering gsi 17 triggering 0 polarity 1

[   21.983738] Already setup the GSI :17

[   21.983758] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt

[   22.136624] SSE version of gcm_enc/dec engaged.

[   22.140249] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)

[   22.145847] alg: No test for crc32 (crc32-pclmul)

[   22.206627] iTCO_vendor_support: vendor-support=0

[   22.207326] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11

[   22.207358] iTCO_wdt: Found a ICH10 TCO device (Version=2, 
TCOBASE=0x1060)

[   22.207508] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

[   22.353888] sound hdaudioC0D2: autoconfig: line_outs=4 
(0x12/0x16/0x24/0x25/0x0) type:line

[   22.353902] sound hdaudioC0D2:    speaker_outs=1 (0x13/0x0/0x0/0x0/0x0)

[   22.353905] sound hdaudioC0D2:    hp_outs=1 (0x11/0x0/0x0/0x0/0x0)

[   22.353908] sound hdaudioC0D2:    mono: mono_out=0x0

[   22.353911] sound hdaudioC0D2:    dig-out=0x1b/0x0

[   22.353913] sound hdaudioC0D2:    inputs:

[   22.353916] sound hdaudioC0D2:      Front Mic=0x14

[   22.353919] sound hdaudioC0D2:      Rear Mic=0x17

[   22.353921] sound hdaudioC0D2:      Line=0x15

[   22.353923] sound hdaudioC0D2:    dig-in=0x1c

[   22.366866] input: HDA Digital PCBeep as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D2/input7

[   22.367371] input: HDA Intel Front Mic as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input8

[   22.367459] input: HDA Intel Rear Mic as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input9

[   22.367977] input: HDA Intel Line as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input10

[   22.368546] input: HDA Intel Line Out Front as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input11

[   22.368616] input: HDA Intel Line Out Surround as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input12

[   22.368680] input: HDA Intel Line Out CLFE as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input13

[   22.368745] input: HDA Intel Line Out Side as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input14

[   22.368819] input: HDA Intel Front Headphone as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input15

[   23.874188] tpm_tis 00:00: tpm_transmit: tpm_send: error -62

[   23.874205] tpm_tis 00:00: A TPM error (-62) occurred attempting to 
determine the timeouts

[   23.886254] tpm_tis 00:00: Adjusting TPM timeout parameters.

[   23.934213] tpm_tis 00:00: TPM is disabled/deactivated (0x6)

[?25l[?1c7[ ok 8[?25h[?0cdone.

[....] Setting parameters of disc: (none)[?25l[?1c7[ 
ok 8[?25h[?0c.


[....] Setting preliminary keymap...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[   24.563713] EXT4-fs (dm-0): re-mounted. Opts: (null)

[....] Checking root file system...fsck from util-linux 2.25.1


/dev/mapper/vg_g2-lv_g2_root: clean, 276615/1048576 files, 
3663404/4194304 blocks


[?25l[?1c7[ ok 8[?25h[?0cdone.


[   24.723128] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro

[   25.036256] xen_acpi_processor: Uploading Xen processor PM info

[   25.055115] xen_pciback: backend is vpci

[   25.081652] fuse init (API version 7.23)

[info] Loading kernel module xen-acpi-processor.


[info] Loading kernel module xen-pciback.


[info] Loading kernel module fuse.


[....] Cleaning up temporary files... 
/tmp[?25l[?1c7[ ok 8[?25h[?0c.


[....] Generating udev events for MD 
arrays...[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Setting up LVM Volume Groups...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Activating lvm and md swap...[   25.748811] Adding 2097148k swap 
on /dev/mapper/vg_g2-lv_g2_swap.  Priority:-1 extents:1 across:2097148k FS

[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Checking file systems...fsck from util-linux 2.25.1


/dev/md0: clean, 334/131072 files, 74476/524224 blocks


[?25l[?1c7[ ok 8[?25h[?0cdone.


[   26.072686] EXT4-fs (md0): mounting ext3 file system using the ext4 
subsystem

[   26.082564] EXT4-fs (md0): mounted filesystem with ordered data mode. 
Opts: (null)

[....] Mounting local filesystems...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Activating swapfile swap...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Cleaning up temporary files...[?25l[?1c7[ ok 
8[?25h[?0c.


[....] Setting kernel variables ...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[   26.766049] Bridge firewalling registered

[   26.773155] device eth0 entered promiscuous mode

[   26.822319] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[   26.825755] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready

[....] Configuring network interfaces...


Waiting for br0 to get ready (MAXWAIT is 32 seconds).


[   29.990761] tg3 0000:05:00.0 eth0: Link is up at 1000 Mbps, full duplex

[   29.990778] tg3 0000:05:00.0 eth0: Flow control is on for TX and on 
for RX

[   29.990798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[   29.990821] br0: port 1(eth0) entered forwarding state

[   29.990829] br0: port 1(eth0) entered forwarding state

[   29.990849] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready

[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Cleaning up temporary files...[?25l[?1c7[ ok 
8[?25h[?0c.


[info] Setting console screen modes.


setterm: cannot (un)set powersave mode: Inappropriate ioctl for device


[9;30][14;30][....] Setting up console font and 
keymap...[?25l[?1c7[ ok 8[?25h[?0cdone.


[   30.864229] ttyS0: LSR safety check engaged!

[   30.866679] ttyS0: LSR safety check engaged!

Loading the saved-state of the serial devices...


/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A


[....] Setting up X socket directories... /tmp/.X11-unix 
/tmp/.ICE-unix[?25l[?1c7[ ok 8[?25h[?0c.


[....] Setting sensors limits[?25l[?1c7[ ok 
8[?25h[?0c.



INIT: Entering runlevel: 2



[info] Using makefile-style concurrent boot in runlevel 2.


[....] Starting enhanced syslogd: 
rsyslogd[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting MD monitoring service: mdadm 
--monitor[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting ACPI services...[?25l[?1c7[ ok 
8[?25h[?0c.


[....] Starting mouse interface server: 
gpm[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting periodic command scheduler: 
cron[?25l[?1c7[ ok 8[?25h[?0c.


[....] Loading cpufreq kernel modules...modprobe: ERROR: could not 
insert 'cpufreq_userspace': No such device


modprobe: ERROR: could not insert 'cpufreq_stats': Invalid argument


modprobe: ERROR: could not insert 'cpufreq_powersave': No such device


modprobe: ERROR: could not insert 'cpufreq_conservative': No such device


[?25l[?1c7[ ok 8[?25h[?0cdone (none).


[....] Starting system message bus: dbus[?25l[?1c7[ 
ok 8[?25h[?0c.


[   31.825880] xen:xen_evtchn: Event-channel device installed

[....] CPUFreq Utilities: Setting ondemand CPUFreq governor...disabled, 
governor not available...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Starting OpenBSD Secure Shell server: 
sshd[?25l[?1c7[ ok 8[?25h[?0c.


Starting /usr/local/sbin/oxenstored...


Setting domain 0 name, domid and JSON config...


Done setting up Dom0


Starting xenconsoled...


Starting QEMU as disk backend for dom0


[9;0][14;0]


[   35.632309] pciback 0000:02:00.0: seizing device

[   35.632389] pciback 0000:02:00.0: enabling device (0004 -> 0007)

[   35.632475] xen: registering gsi 16 triggering 0 polarity 1

[   35.632487] Already setup the GSI :16

libxl: warning: libxl_pci.c:706:libxl__device_pci_assignable_add: 
0000:02:00.0 not bound to a driver, will not be rebound.




Debian GNU/Linux jessie/sid g2 hvc0



g2 login: [   45.034166] br0: port 1(eth0) entered forwarding state

(XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input 
to DOM0)
(XEN) IRQ information:
(XEN)    IRQ:   0 affinity:01 vec:f0 type=IO-APIC-edge status=00000000 
timer_interrupt()
(XEN)    IRQ:   1 affinity:01 vec:30 type=IO-APIC-edge status=00000014 
in-flight=0 domain-list=0:  1(---),
(XEN)    IRQ:   3 affinity:01 vec:38 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   4 affinity:01 vec:f1 type=IO-APIC-edge status=00000000 
ns16550_interrupt()
(XEN)    IRQ:   5 affinity:01 vec:40 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   6 affinity:01 vec:48 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0:  6(---),
(XEN)    IRQ:   7 affinity:01 vec:50 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   8 affinity:01 vec:58 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0:  8(---),
(XEN)    IRQ:   9 affinity:01 vec:60 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0:  9(---),
(XEN)    IRQ:  10 affinity:01 vec:68 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  11 affinity:01 vec:70 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  12 affinity:01 vec:78 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0: 12(---),
(XEN)    IRQ:  13 affinity:3f vec:88 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  14 affinity:01 vec:90 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  15 affinity:01 vec:98 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  16 affinity:01 vec:a0 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 16(---),
(XEN)    IRQ:  17 affinity:01 vec:a8 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 17(---),
(XEN)    IRQ:  18 affinity:01 vec:b0 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 18(---),
(XEN)    IRQ:  19 affinity:01 vec:b8 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 19(---),
(XEN)    IRQ:  24 affinity:3f vec:28 type=DMA_MSI status=00000000 
iommu_page_fault()
(XEN)    IRQ:  25 affinity:01 vec:c0 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:279(---),
(XEN)    IRQ:  26 affinity:01 vec:c8 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:278(---),
(XEN)    IRQ:  27 affinity:01 vec:d0 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:277(---),
(XEN)    IRQ:  28 affinity:01 vec:d8 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:276(---),
(XEN)    IRQ:  29 affinity:01 vec:21 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:275(---),
(XEN)    IRQ:  30 affinity:01 vec:29 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:274(---),
(XEN)    IRQ:  31 affinity:3f vec:31 type=PCI-MSI status=00000002 
mapped, unbound
(XEN)    IRQ:  32 affinity:3f vec:39 type=PCI-MSI status=00000002 
mapped, unbound
(XEN)    IRQ:  33 affinity:01 vec:49 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:271(---),
(XEN)    IRQ:  34 affinity:01 vec:51 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:270(---),
(XEN)    IRQ:  35 affinity:01 vec:59 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:269(---),
(XEN)    IRQ:  36 affinity:01 vec:61 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:268(---),
(XEN)    IRQ:  37 affinity:01 vec:69 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:267(---),
(XEN)    IRQ:  38 affinity:01 vec:71 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:266(---),
(XEN)    IRQ:  39 affinity:01 vec:79 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:265(---),
(XEN)    IRQ:  40 affinity:01 vec:81 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:264(---),
(XEN)    IRQ:  41 affinity:01 vec:89 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:263(---),
(XEN)    IRQ:  42 affinity:01 vec:91 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:262(---),
(XEN)    IRQ:  43 affinity:01 vec:99 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:261(---),
(XEN) Direct vector information:
(XEN)    0x20 -> irq_move_cleanup_interrupt()
(XEN)    0xf2 -> cmci_interrupt()
(XEN)    0xf3 -> intel_thermal_interrupt()
(XEN)    0xf9 -> pmu_apic_interrupt()
(XEN)    0xfa -> apic_timer_interrupt()
(XEN)    0xfb -> call_function_interrupt()
(XEN)    0xfc -> event_check_interrupt()
(XEN)    0xfd -> invalidate_interrupt()
(XEN)    0xfe -> error_interrupt()
(XEN)    0xff -> spurious_interrupt()
(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 48:
(XEN)       Apic 0x00, Pin  1: vec=30 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  3 Vec 56:
(XEN)       Apic 0x00, Pin  3: vec=38 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 64:
(XEN)       Apic 0x00, Pin  5: vec=40 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  6 Vec 72:
(XEN)       Apic 0x00, Pin  6: vec=48 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  7 Vec 80:
(XEN)       Apic 0x00, Pin  7: vec=50 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  8 Vec 88:
(XEN)       Apic 0x00, Pin  8: vec=58 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  9 Vec 96:
(XEN)       Apic 0x00, Pin  9: vec=60 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 10 Vec104:
(XEN)       Apic 0x00, Pin 10: vec=68 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 11 Vec112:
(XEN)       Apic 0x00, Pin 11: vec=70 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 12 Vec120:
(XEN)       Apic 0x00, Pin 12: vec=78 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 13 Vec136:
(XEN)       Apic 0x00, Pin 13: vec=88 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=1 dest_id:63
(XEN)     IRQ 14 Vec144:
(XEN)       Apic 0x00, Pin 14: vec=90 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 15 Vec152:
(XEN)       Apic 0x00, Pin 15: vec=98 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 16 Vec160:
(XEN)       Apic 0x00, Pin 16: vec=a0 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 17 Vec168:
(XEN)       Apic 0x00, Pin 17: vec=a8 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 18 Vec176:
(XEN)       Apic 0x00, Pin 18: vec=b0 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 19 Vec184:
(XEN)       Apic 0x00, Pin 19: vec=b8 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 01:29:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 01:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsLye-0004k8-GA; Sun, 23 Nov 2014 01:28:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XsLyd-0004k3-3W
	for xen-devel@lists.xen.org; Sun, 23 Nov 2014 01:28:36 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/EB-25276-24831745; Sun, 23 Nov 2014 01:28:34 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416706107!14675408!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27294 invoked from network); 23 Nov 2014 01:28:28 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2014 01:28:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416706105; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : Subject :
	References : In-Reply-To : Content-Type : Content-Transfer-Encoding;
	bh=b2xGpvqOiDa/Jg1ciOIV99GK70ZYvbLtGAzAkGf+zR4=;
	b=Yy6bVbpeqA8v+bUnS3bHdCJFv8bfKt1LCdThQN+JKEb3dM/g2QeEy4KEWoee7x2h852f49uPizu/n77zx8mFE2EsZHoDx5PJdIFOM4ATNYIs+thFPLwfInx0n+8ovteKZcs91Nw+9rzOko9kETwzKIw/sL6ICGwaHm3Z+xecvgA=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Sat, 22 Nov 2014 17:28:23 -0800
	id 0000000000030596.54713837.00000C49
Message-ID: <54713848.3020401@ihonk.com>
Date: Sat, 22 Nov 2014 17:28:40 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org,
	=?windows-1252?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>,
	Don Slutz <dslutz@verizon.com>
References: <5457F79B.2020300@ihonk.com>
	<20141104082012.GY12451@reaktio.net>	<5458B55C0200007800044B33@mail.emea.novell.com>	<5460716A.7090905@ihonk.com>	<54608A8B0200007800045E58@mail.emea.novell.com>	<54611A86.4000200@ihonk.com>	<5461D15C02000078000464D7@mail.emea.novell.com>	<546A4AD4.3030002@ihonk.com>	<546B094C0200007800048A5C@mail.emea.novell.com>	<546D429A.5020906@ihonk.com>	<546DAD6502000078000492FD@mail.emea.novell.com>	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
In-Reply-To: <546F091F0200007800049A1C@smtp.nue.novell.com>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 0:42, Jan Beulich wrote:
>>>> On 20.11.14 at 21:07, <sflist@ihonk.com> wrote:
>> Running with mwait-idle=0 solves (hides?) the problem. Next step is to
>> fiddle with the C states?
> For that I'd first of all like to know how much use of C states the
> system still makes with that option in place. For that I'd need the
> output of "xenpm get-cpuidle-states" (actually for comparison
> purposes seeing it once with and once without that option in
> place would be best). Or alternatively 'c' debug key output.

With mwait-idle=0:

(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930624784]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]
(XEN) ==cpu1==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930681815]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]
(XEN) ==cpu2==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930766930]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]
(XEN) ==cpu3==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930824772]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]
(XEN) ==cpu4==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930882528]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]
(XEN) ==cpu5==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
duration[0]
(XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
duration[0]
(XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
duration[0]
(XEN)    *C0:   usage[00000000] duration[46930940315]
(XEN) PC2[0] PC3[0] PC6[0] PC7[0]
(XEN) CC3[0] CC6[0] CC7[0]

Without mwait-idle=0:

(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00004503] method[  FFH] 
duration[1668990535]
(XEN)     C2:   type[C1] latency[010] usage[00009956] method[  FFH] 
duration[4639219546]
(XEN)     C3:   type[C2] latency[020] usage[00654270] method[  FFH] 
duration[882706893390]
(XEN)     C4:   type[C3] latency[200] usage[01483059] method[  FFH] 
duration[35921809585234]
(XEN)    *C0:   usage[02151788] duration[62576274678]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[870647607639] CC6[35852001619202] CC7[0]
(XEN) ==cpu1==
(XEN) active state:             C4
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00297689] method[  FFH] 
duration[1941100848]
(XEN)     C2:   type[C1] latency[010] usage[00001168] method[  FFH] 
duration[1442327615]
(XEN)     C3:   type[C2] latency[020] usage[00006546] method[  FFH] 
duration[8936496716]
(XEN)    *C4:   type[C3] latency[200] usage[01558115] method[  FFH] 
duration[36835128713631]
(XEN)     C0:   usage[01863518] duration[25952414199]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[8737041745] CC6[36744372677161] CC7[0]
(XEN) ==cpu2==
(XEN) active state:             C4
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00289127] method[  FFH] 
duration[1652020841]
(XEN)     C2:   type[C1] latency[010] usage[00000522] method[  FFH] 
duration[1133871888]
(XEN)     C3:   type[C2] latency[020] usage[00004190] method[  FFH] 
duration[5497931261]
(XEN)    *C4:   type[C3] latency[200] usage[01466569] method[  FFH] 
duration[36844578249201]
(XEN)     C0:   usage[01760408] duration[20539080318]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[5364573735] CC6[36756863793181] CC7[0]
(XEN) ==cpu3==
(XEN) active state:             C4
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00323774] method[  FFH] 
duration[21886547916]
(XEN)     C2:   type[C1] latency[010] usage[00000609] method[  FFH] 
duration[45620838149]
(XEN)     C3:   type[C2] latency[020] usage[00006012] method[  FFH] 
duration[1209202160481]
(XEN)    *C4:   type[C3] latency[200] usage[00081570] method[  FFH] 
duration[35586514444690]
(XEN)     C0:   usage[00411965] duration[10177272890]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[1208967409452] CC6[35580116939846] CC7[0]
(XEN) ==cpu4==
(XEN) active state:             C4
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00305724] method[  FFH] 
duration[2083310858]
(XEN)     C2:   type[C1] latency[010] usage[00000597] method[  FFH] 
duration[2346319460]
(XEN)     C3:   type[C2] latency[020] usage[00004138] method[  FFH] 
duration[67793456157]
(XEN)    *C4:   type[C3] latency[200] usage[00274791] method[  FFH] 
duration[36779940944067]
(XEN)     C0:   usage[00585250] duration[21237335856]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[67665029339] CC6[36762696627875] CC7[0]
(XEN) ==cpu5==
(XEN) active state:             C4
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[00299747] method[  FFH] 
duration[20553360971]
(XEN)     C2:   type[C1] latency[010] usage[00000609] method[  FFH] 
duration[42279548469]
(XEN)     C3:   type[C2] latency[020] usage[00005673] method[  FFH] 
duration[1169803847553]
(XEN)    *C4:   type[C3] latency[200] usage[00095108] method[  FFH] 
duration[35630372847429]
(XEN)     C0:   usage[00401137] duration[10391860839]
(XEN) PC2[0] PC3[1932546211563] PC6[32621026287476] PC7[0]
(XEN) CC3[1169586367967] CC6[35622884210881] CC7[0]


>>> Interesting - all CPUs are executing stuff from Dom1, which be itself
>>> is not indicating a problem, but may (considering the host hang) hint
>>> at guest vCPU-s not getting de-scheduled anymore on one or more of the
>>> CPUs. The 'a' debug key output would hopefully give us enough
>>> information to know whether that's the case. Ideally do 'd' and 'a' a
>>> couple of times each (alternating, and with a few seconds in between).
>> Here ya go (as before, from 9a727a81). I had to pick and choose what
>> parts to pull from the log because it was getting spammed with kernel
>> complaints about the disk subsystem being locked up, so the hypervisor
>> debugging info was hard to read amidst the kernel errors. As ever, let
>> me know if you need more.
> Pretty strange: While the first 'a' output suggests that several CPUs
> are idle, the first 'd' output contradicts. While this isn't wrong by itself,
> it may provide a hint I'm simply unable to interpret yet. In any event
> I didn't find what I expected - timers the expiry of which was in the
> past.

Would this strangeness be explained if the first invocations of 'a' and 
'd' weren't actually contiguous? Because of the log spamming I had to 
discard a number of invocations, which I think I did between the first 
two invocations I passed on to you. Here's another attempt, these are 
contiguous, this is from an attempt with turbo mode disabled:

(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        2680us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=        7344us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN)   ex=        7344us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=      989016us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=    14334142us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=   143474414us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=      500179us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=     2272179us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN) CPU01:
(XEN)   ex=        4179us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=        7914us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=        7344us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN) CPU02:
(XEN)   ex=        7344us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=        7408us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=      236179us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex= 26738118512us timer=ffff830c18437290 
cb=rtc_alarm_cb(ffff830c184371f0)
(XEN)   ex=       30039us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=        7344us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex=        7405us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=       30053us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=        7344us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=        7405us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=     2272179us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=       30061us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=         179us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=        1074us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=   501037117us timer=ffff830c184375d0 
cb=pmt_timer_callback(ffff830c184375a8)
(XEN)   ex=        7408us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=        7344us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  fffffffffffffff7   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 000037d3e7b7ffcf   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffdb478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000000000000001   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000037d3e7b7f98e   r14: 000000000000000f
(XEN) r15: fffffa8000bcf3d0   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fefb8684ee
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a0ce80   rcx: fffff80002a0cec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80000ba6e70
(XEN) rbp: 000000000000000f   rsp: fffff80000ba6be0   r8: fffff80002a0cfa0
(XEN) r9:  000034da77fd3a29   r10: fffff80002a0cfa0   r11: fffff80000ba6d30
(XEN) r12: fffff80000ba6d30   r13: 000037d3e7c82ee7   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: fffff88001333898
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d0801dc4fe>] vmx_vmexit_handler+0x311/0x195e
(XEN) RFLAGS: 0000000000000297   CONTEXT: hypervisor
(XEN) rax: 0000000000187000   rbx: ffff830c3dca7f18   rcx: 000000000000ffff
(XEN) rdx: 00003a4400000000   rsi: 0000000000000000   rdi: ffff830c3dca7f18
(XEN) rbp: ffff830c3dca7f08   rsp: ffff830c3dca7d98   r8: fffff880031ea140
(XEN) r9:  0000000000000000   r10: fffff880031ea190   r11: 00000003429653d0
(XEN) r12: ffff8300a99a5000   r13: 0000000000000028   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1b5d6000   cr2: 000007fef93521dc
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7d98:
(XEN)    ffff8300a99a5000 ffff8300a99a5000 ffff8300a99a5000 ffff830c3dcaa088
(XEN)    ffff830c3dca7e08 0000000000000000 ffff830c3dca7de8 ffff830c3dca0000
(XEN)    ffff830c3dcaa0a0 ffff8300a99a5000 000014e14d5273bf ffff8300a99a5000
(XEN)    ffff830c3dcaa088 0000000001c9c380 0000000000000292 ffff830c3dca7e28
(XEN)    ffff82d08012a80f ffff8300a99a5000 ffff830c3dca7e98 ffff82d0801caea5
(XEN)    ffff830c3dca7ec8 ffff8300a99a5508 ffff82d080321280 ffff830c3dcaa0a0
(XEN)    ffff830c3dca7e78 ffff830c3dca7e88 ffff82d0801b5277 ffff8300a99a5000
(XEN)    000014e14d5273bf ffff8300a99a5000 ffff830c3dca7f08 ffff82d0801e0f69
(XEN)    ffff830c3dca7f18 ffff8300a99a5000 ffff830c3dca7f08 ffff82d0801ddba6
(XEN)    ffff830c3dca0000 0000000000000058 ffff830c3dca7ef8 ffff82d08012a1b3
(XEN)    ffff8300a99a5000 ffff8300a99a5000 fffff880031ea518 0000000000001000
(XEN)    0000000000000000 0000000000000058 000000000000432f ffff82d0801e3c81
(XEN)    0000000000000058 0000000000000000 0000000000001000 fffff880031ea518
(XEN)    000000000000432f 00003a44732bdba0 00000003429653d0 fffff880031ea190
(XEN)    0000000000000000 fffff880031ea140 00003a44732bda2e 000000000000ffff
(XEN)    00003a4400000000 0000000000000000 0000000000000097 0000beef0000beef
(XEN)    fffff80002e112bf 000000bf0000beef 0000000000000002 fffff880031ea0e0
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    000000000000beef 0000000000000003 ffff8300a99a5000 0000003bbd988e00
(XEN)    0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801dc4fe>] vmx_vmexit_handler+0x311/0x195e
(XEN)    [<ffff82d0801e3c81>] vmx_asm_vmexit_handler+0x41/0xc0
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff80002e112bf>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 00003a44732bda2e   rbx: 00003a44732bdba0   rcx: 000000000000ffff
(XEN) rdx: 00003a4400000000   rsi: 0000000000000000   rdi: 0000000000000097
(XEN) rbp: 000000000000432f   rsp: fffff880031ea0e0   r8: fffff880031ea140
(XEN) r9:  0000000000000000   r10: fffff880031ea190   r11: 00000003429653d0
(XEN) r12: fffff880031ea518   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  ffffffffffffffdf   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 000037d3e7b7f0a9   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a99a7000   rcx: 0000000000000005
(XEN) rdx: ffff830c3dc80000   rsi: 0000000000000004   rdi: ffff830c3dc8e088
(XEN) rbp: ffff830c3dc87ec8   rsp: ffff830c3dc87e40   r8: ffff830c3dc8e0a0
(XEN) r9:  0000000000000000   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: 000014e162f97027   r13: ffff8300a99a7000   r14: ffff830c3dc8e088
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c182ef000   cr2: 000007fffffa9478
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dc87e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dc8e0a0 0000000500c87e78
(XEN)    ffff830c3dc8e080 ffff82d0801b5277 ffff8300a99a7000 fffff88002ec0d70
(XEN)    ffff8300a99a7000 0000000001c9c380 ffff82d0801e0f00 ffff830c3dc87f08
(XEN)    ffff82d0802f8280 ffff82d0802f8000 ffffffffffffffff ffff830c3dc80000
(XEN)    fffff6fc4003b208 ffff830c3dc87ef8 ffff82d08012a1b3 ffff8300a99a7000
(XEN)    fffff88002ec0d70 000037d3e7b7f896 000000000000000f ffff830c3dc87f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a fffff6fc4003b208
(XEN)    000000000000000f 000037d3e7b7f896 fffff88002ec0d70 000000000000000f
(XEN)    fffff88002eb6180 fffff88002ec0d70 fffff88002eb62a0 0000000000000001
(XEN)    fffff88002eb62a0 0000000000000002 fffff88002eb61c0 0000000000000400
(XEN)    0000000000000000 fffff88002ec0eb0 0000beef0000beef fffff8000294a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002ec0c20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000005 ffff8300a99a7000 0000003bbd96ce00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  0000000000000001   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 000037d3e7b7f896   r14: 000000000000000f
(XEN) r15: fffff6fc4003b208   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffa9478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        3021us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=        7725us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=        7725us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN)   ex=   134454796us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=      652872us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=     5314524us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN) CPU01:
(XEN)   ex=        7725us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=        7789us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex= 26729098894us timer=ffff830c18437290 
cb=rtc_alarm_cb(ffff830c184371f0)
(XEN)   ex=       30023us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=        7725us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=        7791us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       24560us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN) CPU03:
(XEN)   ex=         249us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=        1041us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=      216560us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex=        8273us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=        7725us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN) CPU04:
(XEN)   ex=        7725us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=        7790us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=     1016560us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=     1252560us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=       30054us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=        7725us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=        7789us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=       40560us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=   492017498us timer=ffff830c184375d0 
cb=pmt_timer_callback(ffff830c184375a8)
(XEN)   ex=       30068us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  fffffffffffffff7   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 000037d3e7b7ffcf   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffdb478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000294a214>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a0ce80   rcx: fffff80002a0cec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80000ba6e70
(XEN) rbp: 000000000000000f   rsp: fffff80000ba6be0   r8: fffff80002a0cfa0
(XEN) r9:  000034da77fd3a29   r10: fffff80002a0cfa0   r11: fffff80000ba6d30
(XEN) r12: fffff80000ba6d30   r13: 000037d3e7c82ee7   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: fffff88001333898
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a99a2000   rcx: 0000000000000002
(XEN) rdx: ffff830c3dcb0000   rsi: 0000000000000002   rdi: ffff830c3dcb8088
(XEN) rbp: ffff830c3dcb7ec8   rsp: ffff830c3dcb7e40   r8: ffff830c3dcb80a0
(XEN) r9:  000014e3652e1b9a   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: 000014e36521c02b   r13: ffff8300a99a2000   r14: ffff830c3dcb8088
(XEN) r15: 00000000000f4240   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1a237000   cr2: 000007fef93521dc
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dcb7e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dcb80a0 0000000200cb7e78
(XEN)    ffff830c3dcb8080 ffff82d0801b5277 ffff8300a99a2000 fffff88002e4ad70
(XEN)    ffff8300a99a2000 00000000000f4240 ffff82d0801e0f00 ffff830c3dcb7f08
(XEN)    ffff82d0802f8100 ffff82d0802f8000 ffffffffffffffff ffff830c3dcb0000
(XEN)    0000000000000001 ffff830c3dcb7ef8 ffff82d08012a1b3 ffff8300a99a2000
(XEN)    fffff88002e4ad70 000037d3e7b7f0a9 000000000000000f ffff830c3dcb7f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 000037d3e7b7f0a9 fffff88002e4ad70 000000000000000f
(XEN)    fffff88002e40180 fffff88002e4ad70 fffff88002e402a0 ffffffffffffffdf
(XEN)    fffff88002e402a0 0000000000000002 fffff88002e401c0 0000000000000400
(XEN)    0000000000000000 fffff88002e4aeb0 0000beef0000beef fffff8000294a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002e4ac20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000002 ffff8300a99a2000 0000003bbd996e00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  ffffffffffffffdf   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 000037d3e7b7f0a9   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  0000000000000001   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 000037d3e7b7f896   r14: 000000000000000f
(XEN) r15: fffff6fc4003b208   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffa9478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff80002e112c3>]
(XEN) RFLAGS: 0000000000000006   CONTEXT: hvm guest
(XEN) rax: 00000000876ba63c   rbx: 00003a4a876bd272   rcx: 000000000000ffff
(XEN) rdx: 0000000000003a4a   rsi: 0000000000000000   rdi: 000000000000002e
(XEN) rbp: 000000000000943d   rsp: fffff880031ea0e0   r8: fffff880031ea140
(XEN) r9:  0000000000000000   r10: fffff880031ea190   r11: 00000003429653d0
(XEN) r12: fffff880031ea518   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000000000000001   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000037d3e7b7f98e   r14: 000000000000000f
(XEN) r15: fffffa8000bcf3d0   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fefb8684ee
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        3787us timer=ffff8300bf527060 
cb=vcpu_singleshot_timer_fn(ffff8300bf527000)
(XEN)   ex=      780451us timer=ffff82d08031d280 
cb=time_calibration(0000000000000000)
(XEN)   ex=        4953us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=   126582023us timer=ffff82d08031d1e0 
cb=plt_overflow(0000000000000000)
(XEN)   ex=    13441754us timer=ffff82d08031f4e0 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=        9226us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=       14953us timer=ffff82d080321560 
cb=do_dbs_timer(ffff82d0803215a0)
(XEN) CPU01:
(XEN)   ex=         223us timer=ffff8300bf525060 
cb=vcpu_singleshot_timer_fn(ffff8300bf525000)
(XEN)   ex=        1028us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=       14953us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=        5271us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN) CPU02:
(XEN)   ex=        1037us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=        6999us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=        5324us timer=ffff830c3dc797c8 
cb=csched_tick(0000000000000002)
(XEN)   ex=       14953us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN) CPU03:
(XEN)   ex=        5392us timer=ffff830c3dcac088 
cb=csched_tick(0000000000000003)
(XEN)   ex=       14953us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex= 26721226121us timer=ffff830c18437290 
cb=rtc_alarm_cb(ffff830c184371f0)
(XEN)   ex=      340334us timer=ffff8300bf526060 
cb=vcpu_singleshot_timer_fn(ffff8300bf526000)
(XEN)   ex=       30050us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=        5381us timer=ffff830c3dcac8d8 
cb=csched_tick(0000000000000004)
(XEN)   ex=       14953us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=     1379787us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=       51787us timer=ffff8300bf524060 
cb=vcpu_singleshot_timer_fn(ffff8300bf524000)
(XEN)   ex=       30063us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=        5323us timer=ffff830c3dc8d178 
cb=csched_tick(0000000000000005)
(XEN)   ex=       14953us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=   484144725us timer=ffff830c184375d0 
cb=pmt_timer_callback(ffff830c184375a8)
(XEN)   ex=       30075us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v0): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a0ce80   rcx: fffff80002a0cec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80000ba6e70
(XEN) rbp: 000000000000000f   rsp: fffff80000ba6be0   r8: fffff80002a0cfa0
(XEN) r9:  000034da77fd3a29   r10: fffff80002a0cfa0   r11: fffff80000ba6d30
(XEN) r12: fffff80000ba6d30   r13: 000037d3e7c82ee7   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: fffff88001333898
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v4): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff80002e112c1>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 00003a4fa26b020b   rbx: 00003a4fa26b0c79   rcx: 000000000000ffff
(XEN) rdx: 00003a4f00000000   rsi: 0000000000000000   rdi: 000000000000005d
(XEN) rbp: 000000000000054a   rsp: fffff880031ea0e0   r8: fffff880031ea140
(XEN) r9:  0000000000000000   r10: fffff880031ea190   r11: 00000003429653d0
(XEN) r12: fffff880031ea518   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v3): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  0000000000000001   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 000037d3e7b7f98e   r14: 000000000000000f
(XEN) r15: fffffa8000bcf3d0   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fefb8684ee
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a99a2000   rcx: 0000000000000003
(XEN) rdx: ffff830c3dca0000   rsi: 0000000000000004   rdi: ffff830c3dcaa088
(XEN) rbp: ffff830c3dca7ec8   rsp: ffff830c3dca7e40   r8: ffff830c3dcaa0a0
(XEN) r9:  0000000000000000   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: 000014e55456c519   r13: ffff8300a99a2000   r14: ffff830c3dcaa088
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1a237000   cr2: 000007fef93521dc
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7e40:
(XEN)    ffff82d080126ec5 ffff82d080321280 ffff830c3dcaa0a0 0000000300ca7e78
(XEN)    ffff830c3dcaa080 ffff82d0801b5277 ffff8300a99a2000 fffff88002e4ad70
(XEN)    ffff8300a99a2000 0000000001c9c380 ffff82d0801e0f00 ffff830c3dca7f08
(XEN)    ffff82d0802f8180 ffff82d0802f8000 ffffffffffffffff ffff830c3dca0000
(XEN)    0000000000000001 ffff830c3dca7ef8 ffff82d08012a1b3 ffff8300a99a2000
(XEN)    fffff88002e4ad70 000037d3e7b7f0a9 000000000000000f ffff830c3dca7f08
(XEN)    ffff82d08012a20b 000000000000000f ffff82d0801e3d2a 0000000000000001
(XEN)    000000000000000f 000037d3e7b7f0a9 fffff88002e4ad70 000000000000000f
(XEN)    fffff88002e40180 fffff88002e4ad70 fffff88002e402a0 ffffffffffffffdf
(XEN)    fffff88002e402a0 0000000000000002 fffff88002e401c0 0000000000000400
(XEN)    0000000000000000 fffff88002e4aeb0 0000beef0000beef fffff8000294a20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002e4ac20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000003 ffff8300a99a2000 0000003bbd988e00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012a9a1>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012a1b3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012a20b>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e3d2a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v1): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002e40180   rcx: fffff88002e401c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002e4aeb0
(XEN) rbp: 000000000000000f   rsp: fffff88002e4ac20   r8: fffff88002e402a0
(XEN) r9:  ffffffffffffffdf   r10: fffff88002e402a0   r11: fffff88002e4ad70
(XEN) r12: fffff88002e4ad70   r13: 000037d3e7b7f0a9   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fef93521dc
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v2): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000294a20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  0000000000000001   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 000037d3e7b7f896   r14: 000000000000000f
(XEN) r15: fffff6fc4003b208   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffa9478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v5): ***
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000294a20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  fffffffffffffff7   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 000037d3e7b7ffcf   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffdb478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)

Going to continue replying to your next email here, as I'd like to 
minimize my impact on the list.

On 11/21/2014 1:31, Jan Beulich wrote:
>>>> On 20.11.14 at 21:07, <sflist@ihonk.com> wrote:
>> Running with mwait-idle=0 solves (hides?) the problem. Next step is to
>> fiddle with the C states?
> So this also prompted me to go over the list of errata. Just to confirm
> - your CPU is family 6 model 44? What stepping? And what nominal
> frequency?

CPU information for one of the cores, 2.8 GHz is nominal, stepping is 2. 
Not sure how to translate that stepping number into Intel's format:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Intel(R) Xeon(R) CPU           X5660  @ 2.80GHz
stepping        : 2
microcode       : 0x1a
cpu MHz         : 2800.184
cache size      : 12288 KB
physical id     : 0
siblings        : 6
core id         : 0
cpu cores       : 6
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mca cmov pat 
clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good 
nopl nonstop_tsc pni pclmulqdq monitor est ssse3 cx16 sse4_1 sse4_2 
popcnt aes hypervisor lahf_lm ida arat epb dtherm
bogomips        : 5600.36
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:


> There are a couple potentially relevant errata (BC36, BC38, BC54,
> BC77, BC110).
>
> To exclude BC36, a boot log with "apic-verbosity=debug" and debug
> key 'i' output would be necessary.

Done, see the very end of the email.

> BC38 should not affect us since we don't enter C states from ISRs.
>
> BC54 is probably irrelevant since we meanwhile know that your
> system doesn't really hang hard.
>
> For BC77 it would be worth trying to disable turbo mode instead of
> disabling the mwait-idle driver ("xenpm disable-turbo-mode" right
> after boot).

I looked up BC77 but as a result found this document[1], which seems to 
relate to the i7.  Would this[2] not be the relevant document?

[1] 
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/core-i7-900-ee-and-desktop-processor-series-32nm-spec-update.pdf

[2] 
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-5600-specification-update.pdf

In any case, I ran a test with turbo mode disabled via "xenpm 
disable-turbo-mode" and the host hung.

> And BC110 would be relevant only if without the mwait-idle driver
> there would be no use of C3. Plus anyway this would more likely end
> up in a hard hang too.
>
> And then, considering that my system with a family 6 model 44 CPU
> has never shown anything similar (albeit that doesn't mean all that
> much since our workloads are likely very different), you're not
> over-clocking?

No, no overclocking at all.

> And did you disable hyper-threading on purpose (if
> so could you check whether enabling it makes a difference)?

Yes, I disabled HT intentionally. I've tested with it enabled and with 6 
vCPUs assigned to the domU and the host hung. Took quite a bit longer 
than usual to hang, though, 11 hours.

As promised, below is the apic-verbosity=debug log, with 'i'. Thanks!

Steve

  Xen 4.5-unstable
(XEN) Xen version 4.5-unstable (steve@) (gcc (Debian 4.9.1-19) 4.9.1) 
debug=y Thu Nov 20 11:00:27 PST 2014
(XEN) Latest ChangeSet: Thu Sep 18 14:43:49 2014 +0200 git:9a727a8-dirty
(XEN) Bootloader: GRUB 2.02~beta2-15
(XEN) Command line: placeholder cpufreq=xen:ondemand cpuidle 
clocksource=hpet loglvl=all guest_loglvl=all iommu=no-intremap,debug 
com1=115200,8n1 console=com1,vga apic-verbosity=debug
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 2 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d000 (usable)
(XEN)  000000000009d000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf7a0000 (usable)
(XEN)  00000000bf7a0000 - 00000000bf7ca000 (ACPI data)
(XEN)  00000000bf7ca000 - 00000000bf7cc000 (ACPI NVS)
(XEN)  00000000bf7cc000 - 00000000c0000000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000F6A40, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT BF7BF38F, 0084 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: FACP BF7C98D1, 00F4 (r3 LENOVO TC-61     60400D0 PTL         2)
(XEN) ACPI: DSDT BF7BF413, A43A (r1 LENOVO TC-61     60400D0 MSFT 100000E)
(XEN) ACPI: FACS BF7CBFC0, 0040
(XEN) ACPI: SSDT BF7AF33B, 2694 (r1  INTEL PPM RCM  80000001 INTL 20061109)
(XEN) ACPI: SLIT BF7C99E9, 0030 (r1 Intel  TYLERBRG  60400D0 LOHR       5A)
(XEN) ACPI: TCPA BF7C9A19, 0032 (r1 LENOVO TC-61     60400D0 PTL         0)
(XEN) ACPI: SLIC BF7C9A4B, 0176 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: SRAT BF7C9BC1, 00E0 (r1 Intel  Tylerbrg  60400D0 PHX.        1)
(XEN) ACPI: DMAR BF7C9CA1, 01C0 (r1 Intel  OEMDMAR   60400D0 LOHR        1)
(XEN) ACPI: APIC BF7C9E61, 00A0 (r1 PTLTD       APIC    60400D0 
LTP        0)
(XEN) ACPI: MCFG BF7C9F01, 003C (r1 PTLTD    MCFG    60400D0 LTP        0)
(XEN) ACPI: HPET BF7C9F3D, 0038 (r1 PTLTD  HPETTBL   60400D0 LTP        1)
(XEN) ACPI: BOOT BF7C9F75, 0028 (r1 PTLTD  $SBFTBL$  60400D0 LTP        1)
(XEN) ACPI: ASF! BF7C9F9D, 0063 (r32 LENOVO TC-61     60400D0 PTL         1)
(XEN) System RAM: 49143MB (50322676kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: Node 0 PXM 0 0-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-c40000000
(XEN) NUMA: Using 20 for the hash shift.
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000f6a70
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1008
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1004,1:0], pm1x_evt[1:1000,1:0]
(XEN) ACPI:             wakeup_vec[bf7cbfcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(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: 0x8086a301 base: 0xfed00000
(XEN) [VT-D]dmar.c:788: Host address width 40
(XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:472:   dmaru->address = fe710000
(XEN) [VT-D]iommu.c:1145: drhd->address = fe710000 iommu->reg = 
ffff82c000201000
(XEN) [VT-D]iommu.c:1147: cap = c90780106f0462 ecap = f0207f
(XEN) [VT-D]dmar.c:397:  IOAPIC: 0000:f0:1f.7
(XEN) [VT-D]dmar.c:486:   flags: INCLUDE_ALL
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.1
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.7
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.1
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.2
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.3
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7cd000 end_address 
bf7dbfff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e4000 end_address 
bf7e4fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.1
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e5000 end_address 
bf7e5fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7ea000 end_address 
bf7eafff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e6000 end_address 
bf7e6fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.1
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e7000 end_address 
bf7e7fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.2
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e8000 end_address 
bf7e8fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.3
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e9000 end_address 
bf7e9fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7eb000 end_address 
bf7ebfff
(XEN) [VT-D]dmar.c:812: found ACPI_DMAR_ATSR:
(XEN) [VT-D]dmar.c:705:   atsru->all_ports: 0
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:01.0 start=0 sec=1 sub=1
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:03.0 start=0 sec=2 sub=2
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:07.0 start=0 sec=3 sub=3
(XEN) ERST table was not found
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 6 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 1144 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2800.166 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) alt table ffff82d0802d1cd0 -> ffff82d0802d2cf0
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 09
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-09
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB.
(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 not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping disabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 64 KiB.
(XEN) mwait-idle: MWAIT substates: 0x1120
(XEN) mwait-idle: v0.4 model 0x2c
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 6 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x7c8000
(XEN) elf_parse_binary: phdr: paddr=0x1800000 memsz=0xed000
(XEN) elf_parse_binary: phdr: paddr=0x18ed000 memsz=0x14f40
(XEN) elf_parse_binary: phdr: paddr=0x1902000 memsz=0x614000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x1f16000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff819021f0
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = 
"!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
(XEN) elf_xen_parse_note: SUPPORTED_FEATURES = 0x90d
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff81f16000
(XEN)     virt_entry       = 0xffffffff819021f0
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f16000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c00000000->0000000c10000000 (12316675 pages 
to be allocated)
(XEN)  Init. ramdisk: 0000000c3f0da000->0000000c3ffff86e
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81f16000
(XEN)  Init. ramdisk: ffffffff81f16000->ffffffff82e3b86e
(XEN)  Phys-Mach map: ffffffff82e3c000->ffffffff88cbb948
(XEN)  Start info:    ffffffff88cbc000->ffffffff88cbc4b4
(XEN)  Page tables:   ffffffff88cbd000->ffffffff88d08000
(XEN)  Boot stack:    ffffffff88d08000->ffffffff88d09000
(XEN)  TOTAL:         ffffffff80000000->ffffffff89000000
(XEN)  ENTRY ADDRESS: ffffffff819021f0
(XEN) Dom0 has maximum 6 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff817c8000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81800000 -> 0xffffffff818ed000
(XEN) elf_load_binary: phdr 2 at 0xffffffff818ed000 -> 0xffffffff81901f40
(XEN) elf_load_binary: phdr 3 at 0xffffffff81902000 -> 0xffffffff81a1f000
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:00:00.0 map
(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:14.0
(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:14.1
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:14.2
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.1
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.2
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.3
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.4
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.5
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.6
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:16.7
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1a.0
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1a.1
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1a.7
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:00:1b.0
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1d.0
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1d.1
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1d.2
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1d.3
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1d.7
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1f.0
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1f.2
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:1f.3
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:01:00.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:02:00.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:05:00.0
(XEN) [VT-D]iommu.c:1440: d0:PCIe: map 0000:09:00.0
(XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:0a:0e.0
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:00.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:00.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.2 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.3 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.4 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:02.5 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:03.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:03.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:03.2 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:03.4 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:04.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:04.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:04.2 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:04.3 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:05.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:05.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:05.2 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:05.3 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:06.0 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:06.1 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:06.2 map
(XEN) [VT-D]iommu.c:1426: d0:Hostbridge: skip 0000:3f:06.3 map
(XEN) [VT-D]iommu.c:738: iommu_enable_translation: iommu->reg = 
ffff82c000201000
(XEN) Scrubbing Free RAM on 1 nodes using 6 CPUs
(XEN) 
..................................................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch 
input to Xen)
(XEN) Freed 288kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.16-3-amd64 
(debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-12) ) 
#1 SMP Debian 3.16.5-1 (2014-10-10)
[    0.000000] Command line: placeholder 
root=/dev/mapper/vg_g2-lv_g2_root ro console=hvc0 earlyprintk=serial 
xencons=hvc debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 
LOGLEVEL=8 sched_debug
[    0.000000] Freeing 9d-100 pfn range: 99 pages freed
[    0.000000] Freeing bf7a0-100000 pfn range: 264288 pages freed
[    0.000000] Released 264387 pages of unused memory
[    0.000000] Set 264387 page(s) to 1-1 mapping
[    0.000000] Populating bcff29-c107ec pfn range: 264387 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
[    0.000000] Xen: [mem 0x000000000009d000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000bf79ffff] usable
[    0.000000] Xen: [mem 0x00000000bf7a0000-0x00000000bf7c9fff] ACPI data
[    0.000000] Xen: [mem 0x00000000bf7ca000-0x00000000bf7cbfff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000bf7cc000-0x00000000bfffffff] reserved
[    0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved
[    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000c3fffffff] usable
[    0.000000] bootconsole [earlyser0] enabled
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.6 present.
[    0.000000] DMI: LENOVO 4158WRG/LENOVO, BIOS 61KT50AUS 01/14/2014
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] AGP: No AGP bridge found
[    0.000000] e820: last_pfn = 0xc40000 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xbf7a0 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] init_memory_mapping: [mem 0xc10400000-0xc105fffff]
[    0.000000]  [mem 0xc10400000-0xc105fffff] page 4k
[    0.000000] BRK [0x01b61000, 0x01b61fff] PGTABLE
[    0.000000] BRK [0x01b62000, 0x01b62fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0xc10000000-0xc103fffff]
[    0.000000]  [mem 0xc10000000-0xc103fffff] page 4k
[    0.000000] BRK [0x01b63000, 0x01b63fff] PGTABLE
[    0.000000] BRK [0x01b64000, 0x01b64fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0xc00000000-0xc0fffffff]
[    0.000000]  [mem 0xc00000000-0xc0fffffff] page 4k
[    0.000000] BRK [0x01b65000, 0x01b65fff] PGTABLE
[    0.000000] BRK [0x01b66000, 0x01b66fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x00100000-0xbf79ffff]
[    0.000000]  [mem 0x00100000-0xbf79ffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x100000000-0xbffffffff]
[    0.000000]  [mem 0x100000000-0xbffffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0xc10600000-0xc3fffffff]
[    0.000000]  [mem 0xc10600000-0xc3fffffff] page 4k
[    0.000000] log_buf_len: 16777216
[    0.000000] early log buf free: 127372(97%)
[    0.000000] RAMDISK: [mem 0x01f16000-0x02e3bfff]
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000000F6A40 000024 (v02 PTLTD )
[    0.000000] ACPI: XSDT 0x00000000BF7BF38F 000084 (v01 LENOVO TC-61    
060400D0  LTP 00000000)
[    0.000000] ACPI: FACP 0x00000000BF7C98D1 0000F4 (v03 LENOVO TC-61    
060400D0 PTL  00000002)
[    0.000000] ACPI: DSDT 0x00000000BF7BF413 00A43A (v01 LENOVO TC-61    
060400D0 MSFT 0100000E)
[    0.000000] ACPI: FACS 0x00000000BF7CBFC0 000040
[    0.000000] ACPI: SSDT 0x00000000BF7AF33B 002694 (v01 INTEL  PPM RCM  
80000001 INTL 20061109)
[    0.000000] ACPI: SLIT 0x00000000BF7C99E9 000030 (v01 Intel TYLERBRG 
060400D0 LOHR 0000005A)
[    0.000000] ACPI: TCPA 0x00000000BF7C9A19 000032 (v01 LENOVO TC-61    
060400D0 PTL  00000000)
[    0.000000] ACPI: SLIC 0x00000000BF7C9A4B 000176 (v01 LENOVO TC-61    
060400D0  LTP 00000000)
[    0.000000] ACPI: SRAT 0x00000000BF7C9BC1 0000E0 (v01 Intel Tylerbrg 
060400D0 PHX. 00000001)
[    0.000000] ACPI: XMAR 0x00000000BF7C9CA1 0001C0 (v01 Intel OEMDMAR  
060400D0 LOHR 00000001)
[    0.000000] ACPI: APIC 0x00000000BF7C9E61 0000A0 (v01 PTLTD  ? APIC   
060400D0  LTP 00000000)
[    0.000000] ACPI: MCFG 0x00000000BF7C9F01 00003C (v01 PTLTD MCFG   
060400D0  LTP 00000000)
[    0.000000] ACPI: HPET 0x00000000BF7C9F3D 000038 (v01 PTLTD HPETTBL  
060400D0  LTP 00000001)
[    0.000000] ACPI: BOOT 0x00000000BF7C9F75 000028 (v01 PTLTD $SBFTBL$ 
060400D0  LTP 00000001)
[    0.000000] ACPI: ASF! 0x00000000BF7C9F9D 000063 (v32 LENOVO TC-61    
060400D0 PTL  00000001)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000c3fffffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0xc3fffffff]
[    0.000000]   NODE_DATA [mem 0xc107e7000-0xc107ebfff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0xc3fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009cfff]
[    0.000000]   node   0: [mem 0x00100000-0xbf79ffff]
[    0.000000]   node   0: [mem 0x100000000-0xc3fffffff]
[    0.000000] On node 0 totalpages: 12580668
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 21 pages reserved
[    0.000000]   DMA zone: 3996 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 10667 pages used for memmap
[    0.000000]   DMA32 zone: 780192 pages, LIFO batch:31
[    0.000000]   Normal zone: 161280 pages used for memmap
[    0.000000]   Normal zone: 11796480 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 
0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[    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: 0x8086a301 base: 0xfed00000
[    0.000000] smpboot: Allowing 6 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 40
[    0.000000] PM: Registered nosave memory: [mem 0x0009d000-0x000fffff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7a0000-0xbf7c9fff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7ca000-0xbf7cbfff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7cc000-0xbfffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xc0000000-0xf7ffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xf8000000-0xfbffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfc000000-0xfebfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfec0ffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfec10000-0xfedfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfeefffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfef00000-0xfeffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xff000000-0xffffffff]
[    0.000000] e820: [mem 0xc0000000-0xf7ffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.5-unstable (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 
nr_cpu_ids:6 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880c03400000 s85824 
r8192 d20672 u262144
[    0.000000] pcpu-alloc: s85824 r8192 d20672 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 - -
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  
Total pages: 12408644
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: placeholder 
root=/dev/mapper/vg_g2-lv_g2_root ro console=hvc0 earlyprintk=serial 
xencons=hvc debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 
LOGLEVEL=8 sched_debug
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] software IO TLB [mem 0xbd4e00000-0xbd8e00000] (64MB) 
mapped at [ffff880bd4e00000-ffff880bd8dfffff]
[    0.000000] Memory: 48548972K/50322672K available (5189K kernel code, 
942K rwdata, 1824K rodata, 1200K init, 840K bss, 1773700K reserved)
[    0.000000] Hierarchical RCU implementation.
[    0.000000]     RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000]     RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=6.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6
[    0.000000] NR_IRQS:33024 nr_irqs:728 16
[    0.000000] xen:events: Using FIFO-based ABI
[    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: --> 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 [hvc0] enabled

[    0.000000] console [hvc0] enabled
[    0.000000] bootconsole [earlyser0] disabled

[    0.000000] bootconsole [earlyser0] disabled
[    0.000000] bootconsole [xenboot0] disabled

[    0.000000] bootconsole [xenboot0] disabled
[    0.000000] Xen: using vcpuop timer interface

[    0.000000] installing Xen timer for CPU 0

[    0.000000] tsc: Detected 2800.166 MHz processor

[   10.913942] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 5600.33 BogoMIPS (lpj=11200664)

[   10.913948] pid_max: default: 32768 minimum: 301

[   10.913957] ACPI: Core revision 20140424

[   10.918311] ACPI: All ACPI Tables successfully acquired

[   10.925345] Security Framework initialized

[   10.925354] AppArmor: AppArmor disabled by boot time parameter

[   10.925357] Yama: disabled by default; enable with sysctl kernel.yama.*

[   10.933807] Dentry cache hash table entries: 8388608 (order: 14, 
67108864 bytes)

[   11.051238] Inode-cache hash table entries: 4194304 (order: 13, 
33554432 bytes)

[   11.055771] Mount-cache hash table entries: 131072 (order: 8, 1048576 
bytes)

[   11.055917] Mountpoint-cache hash table entries: 131072 (order: 8, 
1048576 bytes)

[   11.056359] Initializing cgroup subsys memory

[   11.056365] Initializing cgroup subsys devices

[   11.056372] Initializing cgroup subsys freezer

[   11.056376] Initializing cgroup subsys net_cls

[   11.056380] Initializing cgroup subsys blkio

[   11.056385] Initializing cgroup subsys perf_event

[   11.056388] Initializing cgroup subsys net_prio

[   11.056437] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'

[   11.056437] ENERGY_PERF_BIAS: View and update with 
x86_energy_perf_policy(8)

[   11.056443] CPU: Physical Processor ID: 0

[   11.056445] CPU: Processor Core ID: 0

[   11.056448] mce: CPU supports 2 MCE banks

[   11.056462] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7

[   11.056462] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0

[   11.056462] tlb_flushall_shift: 6

[   11.056527] Freeing SMP alternatives memory: 20K (ffffffff81a19000 - 
ffffffff81a1e000)

[   11.057351] ftrace: allocating 21546 entries in 85 pages

[   11.064078] Performance Events: unsupported p6 CPU model 44 no PMU 
driver, software events only.

[   11.065170] NMI watchdog: disabled (cpu0): hardware events not enabled

[   11.065246] installing Xen timer for CPU 1

[   11.065590] installing Xen timer for CPU 2

[   11.065965] installing Xen timer for CPU 3

[   11.066389] installing Xen timer for CPU 4

[   11.066751] installing Xen timer for CPU 5

[   11.066998] x86: Booted up 1 node, 6 CPUs

[   11.067017] CPU0 attaching sched-domain:

[   11.067020]  domain 0: span 0-5 level MC

[   11.067022]   groups: 0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 
2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 
5 (cpu_capacity = 1023)

[   11.067033] CPU1 attaching sched-domain:

[   11.067035]  domain 0: span 0-5 level MC

[   11.067037]   groups: 1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 
3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 
0 (cpu_capacity = 1023)

[   11.067047] CPU2 attaching sched-domain:

[   11.067049]  domain 0: span 0-5 level MC

[   11.067051]   groups: 2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 
4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 
1 (cpu_capacity = 1023)

[   11.067061] CPU3 attaching sched-domain:

[   11.067063]  domain 0: span 0-5 level MC

[   11.067065]   groups: 3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 
5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 
2 (cpu_capacity = 1023)

[   11.067075] CPU4 attaching sched-domain:

[   11.067077]  domain 0: span 0-5 level MC

[   11.067079]   groups: 4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 
0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 
3 (cpu_capacity = 1023)

[   11.067089] CPU5 attaching sched-domain:

[   11.067091]  domain 0: span 0-5 level MC

[   11.067093]   groups: 5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 
1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 
4 (cpu_capacity = 1023)

[   11.067472] devtmpfs: initialized

[   11.073663] PM: Registering ACPI NVS region [mem 
0xbf7ca000-0xbf7cbfff] (8192 bytes)

[   11.074540] pinctrl core: initialized pinctrl subsystem

[   11.074698] NET: Registered protocol family 16

[   11.074711] xen:grant_table: Grant tables using version 1 layout

[   11.074725] Grant table initialized

[   11.075185] ACPI FADT declares the system doesn't support PCIe ASPM, 
so disable it

[   11.075189] ACPI: bus type PCI registered

[   11.075192] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5

[   11.075445] PCI: MMCONFIG for domain 0000 [bus 00-09] at [mem 
0xf8000000-0xf89fffff] (base 0xf8000000)

[   11.075450] PCI: MMCONFIG at [mem 0xf8000000-0xf89fffff] reserved in E820

[   11.076571] PCI: Using configuration type 1 for base access

[   11.089430] ACPI: Added _OSI(Module Device)

[   11.089434] ACPI: Added _OSI(Processor Device)

[   11.089436] ACPI: Added _OSI(3.0 _SCP Extensions)

[   11.089438] ACPI: Added _OSI(Processor Aggregator Device)

[   11.092694] ACPI: Interpreter enabled

[   11.092700] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep 
State [\_S1_] (20140424/hwxface-580)

[   11.092706] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep 
State [\_S2_] (20140424/hwxface-580)

[   11.092717] ACPI: (supports S0 S3 S4 S5)

[   11.092719] ACPI: Using IOAPIC for interrupt routing

[   11.092741] PCI: Using host bridge windows from ACPI; if necessary, 
use "pci=nocrs" and report a bug

[   11.108183] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])

[   11.108191] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM 
ClockPM Segments MSI]

[   11.108401] acpi PNP0A03:00: _OSC: OS now controls [PCIeHotplug PME 
AER PCIeCapability]

[   11.109031] acpi PNP0A03:00: [Firmware Info]: MMCONFIG for domain 
0000 [bus 00-09] only partially covers this bridge

[   11.109200] PCI host bridge to bus 0000:00

[   11.109204] pci_bus 0000:00: root bus resource [bus 00-ff]

[   11.109207] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7]

[   11.109210] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff]

[   11.109212] pci_bus 0000:00: root bus resource [mem 
0x000a0000-0x000bffff]

[   11.109215] pci_bus 0000:00: root bus resource [mem 
0x000d0000-0x000d3fff]

[   11.109218] pci_bus 0000:00: root bus resource [mem 
0x000d4000-0x000d7fff]

[   11.109221] pci_bus 0000:00: root bus resource [mem 
0x000d8000-0x000dbfff]

[   11.109224] pci_bus 0000:00: root bus resource [mem 
0x000dc000-0x000dffff]

[   11.109227] pci_bus 0000:00: root bus resource [mem 
0xc0000000-0xfdffffff]

[   11.109245] pci 0000:00:00.0: [8086:3406] type 00 class 0x060000

[   11.109341] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold

(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) PCI add device 0000:00:00.0
[   11.109451] pci 0000:00:01.0: [8086:3408] type 01 class 0x060400

[   11.109556] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold

[   11.109603] pci 0000:00:01.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) PCI add device 0000:00:01.0
[   11.109668] pci 0000:00:03.0: [8086:340a] type 01 class 0x060400

[   11.109781] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold

[   11.109830] pci 0000:00:03.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) PCI add device 0000:00:03.0
[   11.109898] pci 0000:00:07.0: [8086:340e] type 01 class 0x060400

[   11.109995] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold

[   11.110045] pci 0000:00:07.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) PCI add device 0000:00:07.0
[   11.110117] pci 0000:00:14.0: [8086:342e] type 00 class 0x080000

(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) PCI add device 0000:00:14.0
[   11.110272] pci 0000:00:14.1: [8086:3422] type 00 class 0x080000

(XEN) PCI add device 0000:00:14.1
[   11.110443] pci 0000:00:14.2: [8086:3423] type 00 class 0x080000

(XEN) PCI add device 0000:00:14.2
[   11.110605] pci 0000:00:16.0: [8086:3430] type 00 class 0x088000

[   11.110626] pci 0000:00:16.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.0
[   11.110786] pci 0000:00:16.1: [8086:3431] type 00 class 0x088000

[   11.110806] pci 0000:00:16.1: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.1
[   11.110964] pci 0000:00:16.2: [8086:3432] type 00 class 0x088000

[   11.110985] pci 0000:00:16.2: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.2
[   11.111143] pci 0000:00:16.3: [8086:3433] type 00 class 0x088000

[   11.111164] pci 0000:00:16.3: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.3
[   11.111324] pci 0000:00:16.4: [8086:3429] type 00 class 0x088000

[   11.111344] pci 0000:00:16.4: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.4
[   11.111503] pci 0000:00:16.5: [8086:342a] type 00 class 0x088000

[   11.111523] pci 0000:00:16.5: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.5
[   11.111682] pci 0000:00:16.6: [8086:342b] type 00 class 0x088000

[   11.111703] pci 0000:00:16.6: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.6
[   11.111881] pci 0000:00:16.7: [8086:342c] type 00 class 0x088000

[   11.111902] pci 0000:00:16.7: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.7
[   11.112063] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c0300

[   11.112131] pci 0000:00:1a.0: reg 0x20: [io  0x1800-0x181f]

[   11.112236] pci 0000:00:1a.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.0
[   11.112294] pci 0000:00:1a.1: [8086:3a38] type 00 class 0x0c0300

[   11.112387] pci 0000:00:1a.1: reg 0x20: [io  0x1820-0x183f]

[   11.112515] pci 0000:00:1a.1: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.1
[   11.112585] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0320

[   11.112617] pci 0000:00:1a.7: reg 0x10: [mem 0xec604000-0xec6043ff]

[   11.112755] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold

[   11.112800] pci 0000:00:1a.7: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.7
[   11.112858] pci 0000:00:1b.0: [8086:3a3e] type 00 class 0x040300

[   11.112884] pci 0000:00:1b.0: reg 0x10: [mem 0xec600000-0xec603fff 64bit]

[   11.113000] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold

(XEN) PCI add device 0000:00:1b.0
[   11.113091] pci 0000:00:1c.0: [8086:3a40] type 01 class 0x060400

[   11.113225] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold

[   11.113273] pci 0000:00:1c.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.0
[   11.113330] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x060400

[   11.113449] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold

[   11.113497] pci 0000:00:1c.4: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.4
[   11.113549] pci 0000:00:1c.5: [8086:3a4a] type 01 class 0x060400

[   11.113668] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold

[   11.113717] pci 0000:00:1c.5: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.5
[   11.113780] pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300

[   11.113848] pci 0000:00:1d.0: reg 0x20: [io  0x1840-0x185f]

[   11.113955] pci 0000:00:1d.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.0
[   11.114008] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300

[   11.114076] pci 0000:00:1d.1: reg 0x20: [io  0x1860-0x187f]

[   11.114182] pci 0000:00:1d.1: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.1
[   11.114240] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300

[   11.114331] pci 0000:00:1d.2: reg 0x20: [io  0x1880-0x189f]

[   11.114461] pci 0000:00:1d.2: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.2
[   11.114538] pci 0000:00:1d.3: [8086:3a39] type 00 class 0x0c0300

[   11.114622] pci 0000:00:1d.3: reg 0x20: [io  0x18a0-0x18bf]

[   11.114726] pci 0000:00:1d.3: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.3
[   11.114790] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320

[   11.114823] pci 0000:00:1d.7: reg 0x10: [mem 0xec605000-0xec6053ff]

[   11.114960] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold

[   11.115005] pci 0000:00:1d.7: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.7
[   11.115056] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401

[   11.115166] pci 0000:00:1e.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1e.0
[   11.115218] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x060100

(XEN) PCI add device 0000:00:1f.0
[   11.115446] pci 0000:00:1f.2: [8086:3a22] type 00 class 0x010601

[   11.115477] pci 0000:00:1f.2: reg 0x10: [io  0x18f0-0x18f7]

[   11.115490] pci 0000:00:1f.2: reg 0x14: [io  0x18e4-0x18e7]

[   11.115503] pci 0000:00:1f.2: reg 0x18: [io  0x18e8-0x18ef]

[   11.115516] pci 0000:00:1f.2: reg 0x1c: [io  0x18e0-0x18e3]

[   11.115528] pci 0000:00:1f.2: reg 0x20: [io  0x18c0-0x18df]

[   11.115541] pci 0000:00:1f.2: reg 0x24: [mem 0xec606000-0xec6067ff]

[   11.115617] pci 0000:00:1f.2: PME# supported from D3hot

(XEN) PCI add device 0000:00:1f.2
[   11.115703] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500

[   11.115728] pci 0000:00:1f.3: reg 0x10: [mem 0xec607000-0xec6070ff 64bit]

[   11.115762] pci 0000:00:1f.3: reg 0x20: [io  0x1100-0x111f]

(XEN) PCI add device 0000:00:1f.3
[   11.115968] pci 0000:01:00.0: [11ab:6485] type 00 class 0x010400

[   11.116011] pci 0000:01:00.0: reg 0x18: [io  0x2000-0x207f]

[   11.116041] pci 0000:01:00.0: reg 0x20: [mem 0xec000000-0xec00ffff 64bit]

[   11.116055] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0003ffff pref]

[   11.116117] pci 0000:01:00.0: supports D1

[   11.116119] pci 0000:01:00.0: PME# supported from D0 D1 D3hot

[   11.116150] pci 0000:01:00.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:01:00.0
[   11.121894] pci 0000:00:01.0: PCI bridge to [bus 01]

[   11.121909] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]

[   11.121920] pci 0000:00:01.0:   bridge window [mem 0xec000000-0xec0fffff]

[   11.122054] pci 0000:02:00.0: [10de:05fe] type 00 class 0x030000

[   11.122071] pci 0000:02:00.0: reg 0x10: [mem 0xea000000-0xeaffffff]

[   11.122087] pci 0000:02:00.0: reg 0x14: [mem 0xd0000000-0xdfffffff 
64bit pref]

[   11.1[   11.886737] tg3 0000:05:00.0: no hotplug settings from platform

[   11.886873] pci_bus 0000:07: Allocating resources

[   11.886956] pcieport 0000:06:00.0: bridge window [io 0x1000-0x0fff] 
to [bus 07-09] add_size 1000

[   11.886961] pcieport 0000:06:00.0: bridge window [mem 
0x00100000-0x000fffff 64bit pref] to [bus 07-09] add_size 200000

[   11.886966] pcieport 0000:06:00.0: res[15]=[mem 0x00100000-0x000fffff 
64bit pref] get_res_add_size add_size 200000

[   11.886970] pcieport 0000:06:00.0: res[13]=[io  0x1000-0x0fff] 
get_res_add_size add_size 1000

[   11.886976] pcieport 0000:06:00.0: BAR 15: assigned [mem 
0xc0600000-0xc07fffff 64bit pref]

[   11.886979] pcieport 0000:06:00.0: BAR 13: assigned [io 0x7000-0x7fff]

[   11.887002] pcieport 0000:06:00.0: no hotplug settings from platform

[   11.887024] pcieport 0000:07:02.0: no hotplug settings from platform

[   11.887045] pcieport 0000:07:03.0: no hotplug settings from platform

[   11.887059] tg3 0000:09:00.0: no hotplug settings from platform

[   11.994139] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[   11.994195] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

[   11.994218] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[   11.997794] ata2.00: ATAPI: HL-DT-STDVD-RAM GH60N, NY02, max UDMA/100

[   12.000368] ata1.00: ATA-8: WDC WD3000BLFS-08YBU0, 04.04V04, max UDMA/100

[   12.000376] ata1.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 
31/32), AA

[   12.000605] ata3.00: ATA-8: WDC WD3000BLFS-08YBU0, 04.04V04, max UDMA/100

[   12.000633] ata3.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 
31/32), AA

[   12.002074] ata2.00: configured for UDMA/100

[   12.006362] ata1.00: configured for UDMA/100

[   12.006685] scsi 1:0:0:0: Direct-Access     ATA      WDC WD3000BLFS-0 
4V04 PQ: 0 ANSI: 5

[   12.007576] ata3.00: configured for UDMA/100

[   12.010795] scsi 2:0:0:0: CD-ROM            HL-DT-ST DVD-RAM GH60N    
NY02 PQ: 0 ANSI: 5

[   12.020253] scsi 3:0:0:0: Direct-Access     ATA      WDC WD3000BLFS-0 
4V04 PQ: 0 ANSI: 5

[   12.023987] sd 1:0:0:0: [sda] 586072368 512-byte logical blocks: (300 
GB/279 GiB)

[   12.024095] sd 1:0:0:0: [sda] Write Protect is off

[   12.024099] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00

[   12.024137] sd 1:0:0:0: [sda] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA

[   12.026873] sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw 
xa/form2 cdda tray

[   12.026877] cdrom: Uniform CD-ROM driver Revision: 3.20

[   12.027026] sr 2:0:0:0: Attached scsi CD-ROM sr0

[   12.027143] sd 3:0:0:0: [sdb] 586072368 512-byte logical blocks: (300 
GB/279 GiB)

[   12.027173] sd 3:0:0:0: [sdb] Write Protect is off

[   12.027177] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00

[   12.027190] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA

[   12.027657] sd 1:0:0:0: Attached scsi generic sg0 type 0

[   12.027714] sr 2:0:0:0: Attached scsi generic sg1 type 5

[   12.027760] sd 3:0:0:0: Attached scsi generic sg2 type 0

[   12.033518]  sdb: sdb1 sdb2

[   12.033848] sd 3:0:0:0: [sdb] Attached SCSI disk

[   12.035876]  sda: sda1 sda2

[   12.036699] sd 1:0:0:0: [sda] Attached SCSI disk

[   12.115971] md: bind<sdb1>

[   12.116953] md: bind<sdb2>

[   12.120452] md: bind<sda1>

[   12.132123] md: raid1 personality registered for level 1

[   12.132627] md/raid1:md0: active with 2 out of 2 mirrors

[   12.132652] md0: detected capacity change from 0 to 536805376

[   12.132993]  md0: unknown partition table

[   12.138313] md: bind<sda2>

[   12.140816] md/raid1:md1: active with 2 out of 2 mirrors

[   12.140884] created bitmap (3 pages) for device md1

[   12.141017] md1: bitmap initialized from disk: read 1 pages, set 0 of 
4462 bits

[   12.149347] md1: detected capacity change from 0 to 299396562944

[   12.165820]  md1: unknown partition table

[   12.207392] usb 1-4: New USB device found, idVendor=0bda, idProduct=0181

[   12.207402] usb 1-4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[   12.207408] usb 1-4: Product: USB2.0-CRW

[   12.207413] usb 1-4: Manufacturer: Generic

[   12.207417] usb 1-4: SerialNumber: 20060413092100000

[   12.215524] usb-storage 1-4:1.0: USB Mass Storage device detected

[   12.215864] scsi7 : usb-storage 1-4:1.0

[   12.215924] usbcore: registered new interface driver usb-storage

[   12.506248] usb 6-2: new low-speed USB device number 2 using uhci_hcd

[   12.693319] usb 6-2: New USB device found, idVendor=17ef, idProduct=6009

[   12.693329] usb 6-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0

[   12.693336] usb 6-2: Product: ThinkPad USB Keyboard with TrackPoint

[   12.693342] usb 6-2: Manufacturer: Lite-On Technology Corp.

[   12.698056] hidraw: raw HID events driver (C) Jiri Kosina

[   12.743346] usbcore: registered new interface driver usbhid

[   12.743353] usbhid: USB HID core driver

[   12.744735] input: Lite-On Technology Corp. ThinkPad USB Keyboard 
with TrackPoint as 
/devices/pci0000:00/0000:00:1d.2/usb6/6-2/6-2:1.0/0003:17EF:6009.0001/input/input2

[   12.744927] lenovo_tpkbd 0003:17EF:6009.0001: input,hidraw0: USB HID 
v1.10 Keyboard [Lite-On Technology Corp. ThinkPad USB Keyboard with 
TrackPoint] on usb-0000:00:1d.2-2/input0

[   12.761360] input: Lite-On Technology Corp. ThinkPad USB Keyboard 
with TrackPoint as 
/devices/pci0000:00/0000:00:1d.2/usb6/6-2/6-2:1.1/0003:17EF:6009.0002/input/input3

[   12.762013] lenovo_tpkbd 0003:17EF:6009.0002: input,hiddev0,hidraw1: 
USB HID v1.10 Mouse [Lite-On Technology Corp. ThinkPad USB Keyboard with 
TrackPoint] on usb-0000:00:1d.2-2/input1

[   13.217937] scsi 7:0:0:0: Direct-Access     Generic- Compact Flash    
1.00 PQ: 0 ANSI: 0 CCS

[   13.221024] scsi 7:0:0:1: Direct-Access     Generic- SM/xD-Picture    
1.00 PQ: 0 ANSI: 0 CCS

[   13.224150] scsi 7:0:0:2: Direct-Access     Generic- SD/MMC           
1.00 PQ: 0 ANSI: 0 CCS

[   13.227396] scsi 7:0:0:3: Direct-Access     Generic- MS/MS-Pro/HG     
1.00 PQ: 0 ANSI: 0 CCS

[   13.228034] sd 7:0:0:0: Attached scsi generic sg3 type 0

[   13.228345] sd 7:0:0:1: Attached scsi generic sg4 type 0

[   13.228574] sd 7:0:0:2: Attached scsi generic sg5 type 0

[   13.228785] sd 7:0:0:3: Attached scsi generic sg6 type 0

[   13.346389] sd 7:0:0:1: [sdd] Attached SCSI removable disk

[   13.349011] sd 7:0:0:2: [sde] Attached SCSI removable disk

[   13.351524] sd 7:0:0:3: [sdf] Attached SCSI removable disk

[   13.354008] sd 7:0:0:0: [sdc] Attached SCSI removable disk

[   14.394199] random: nonblocking pool is initialized

[   16.542191] scsi0 : mvsas

[   20.145393] device-mapper: uevent: version 1.0.3

[   20.145537] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) 
initialised: dm-devel@redhat.com

[   20.402023] PM: Starting manual resume from disk

[   20.402038] PM: Hibernation image partition 253:1 present

[   20.402040] PM: Looking for hibernation image.

[   20.402260] PM: Image not found (code -22)

[   20.402268] PM: Hibernation image not present or could not be loaded.

[   20.428292] EXT4-fs (dm-0): mounted filesystem with ordered data 
mode. Opts: (null)


INIT: version 2.88 booting


[info] Using makefile-style concurrent boot in runlevel S.

calling: info

[....] Starting the hotplug events dispatcher: udevd[   21.400512] 
systemd-udevd[385]: starting version 215

[?25l[?1c7[ ok 8[?25h[?0c.

[....] Synthesizing the initial hotplug events...calling: trigger

[?25l[?1c7[ ok 8[?25h[?0cdone.

[....] Waiting for /dev to be fully populated...calling: settle

[   21.753344] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4

[   21.765849] dca service started, version 1.12.1

[   21.778668] EDAC MC: Ver: 3.0.0

[   21.783168] Monitor-Mwait will be used to enter C-1 state

[   21.783245] Monitor-Mwait will be used to enter C-3 state

[   21.783295] Monitor-Mwait will be used to enter C-3 state

[   21.786434] Warning: Processor Platform Limit not supported.

[   21.797492] ioatdma: Intel(R) QuickData Technology Driver 4.00

[   21.797594] ioatdma 0000:00:16.0: enabling device (0000 -> 0002)

[   21.797772] ioatdma 0000:00:16.0: can't derive routing for PCI INT A

[   21.797776] ioatdma 0000:00:16.0: PCI INT A: no GSI

[   21.797986] ioatdma 0000:00:16.1: enabling device (0000 -> 0002)

[   21.798177] ioatdma 0000:00:16.1: can't derive routing for PCI INT B

[   21.798181] ioatdma 0000:00:16.1: PCI INT B: no GSI

[   21.798368] ioatdma 0000:00:16.2: enabling device (0000 -> 0002)

[   21.798545] ioatdma 0000:00:16.2: can't derive routing for PCI INT C

[   21.798548] ioatdma 0000:00:16.2: PCI INT C: no GSI

[   21.798739] ioatdma 0000:00:16.3: enabling device (0000 -> 0002)

[   21.798914] ioatdma 0000:00:16.3: can't derive routing for PCI INT D

[   21.798918] ioatdma 0000:00:16.3: PCI INT D: no GSI

[   21.799112] ioatdma 0000:00:16.4: enabling device (0000 -> 0002)

[   21.799287] ioatdma 0000:00:16.4: can't derive routing for PCI INT A

[   21.799291] ioatdma 0000:00:16.4: PCI INT A: no GSI

[   21.799471] ioatdma 0000:00:16.5: enabling device (0000 -> 0002)

[   21.799646] ioatdma 0000:00:16.5: can't derive routing for PCI INT B

[   21.799650] ioatdma 0000:00:16.5: PCI INT B: no GSI

[   21.799841] ioatdma 0000:00:16.6: enabling device (0000 -> 0002)

[   21.800039] ioatdma 0000:00:16.6: can't derive routing for PCI INT C

[   21.800042] ioatdma 0000:00:16.6: PCI INT C: no GSI

[   21.800235] ioatdma 0000:00:16.7: enabling device (0000 -> 0002)

[   21.800410] ioatdma 0000:00:16.7: can't derive routing for PCI INT D

[   21.800414] ioatdma 0000:00:16.7: PCI INT D: no GSI

[   21.823210] input: Power Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0C:00/input/input4

[   21.823218] ACPI: Power Button [PWRB]

[   21.823257] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5

[   21.823261] ACPI: Power Button [PWRF]

[   21.826900] wmi: Mapper loaded

[   21.868557] tpm_tis 00:00: 1.2 TPM (device-id 0x1002, rev-id 2)

[   21.886793] ACPI Warning: SystemIO range 
0x0000000000001028-0x000000000000102f conflicts with OpRegion 
0x0000000000001000-0x000000000000102f (\_SB_.PCI0.LPC0.PMIO) 
(20140424/utaddress-258)

[   21.886803] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   21.886809] ACPI Warning: SystemIO range 
0x00000000000011b0-0x00000000000011bf conflicts with OpRegion 
0x0000000000001180-0x00000000000011bf (\_SB_.PCI0.LPC0.GPOX) 
(20140424/utaddress-258)

[   21.886816] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   21.886819] ACPI Warning: SystemIO range 
0x0000000000001180-0x00000000000011af conflicts with OpRegion 
0x0000000000001180-0x00000000000011bf (\_SB_.PCI0.LPC0.GPOX) 
(20140424/utaddress-258)

[   21.886826] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   21.886829] lpc_ich: Resource conflict(s) found affecting gpio_ich

[   21.947151] xen: registering gsi 16 triggering 0 polarity 1

[   21.947158] Already setup the GSI :16

[   21.983732] xen: registering gsi 17 triggering 0 polarity 1

[   21.983738] Already setup the GSI :17

[   21.983758] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt

[   22.136624] SSE version of gcm_enc/dec engaged.

[   22.140249] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)

[   22.145847] alg: No test for crc32 (crc32-pclmul)

[   22.206627] iTCO_vendor_support: vendor-support=0

[   22.207326] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11

[   22.207358] iTCO_wdt: Found a ICH10 TCO device (Version=2, 
TCOBASE=0x1060)

[   22.207508] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

[   22.353888] sound hdaudioC0D2: autoconfig: line_outs=4 
(0x12/0x16/0x24/0x25/0x0) type:line

[   22.353902] sound hdaudioC0D2:    speaker_outs=1 (0x13/0x0/0x0/0x0/0x0)

[   22.353905] sound hdaudioC0D2:    hp_outs=1 (0x11/0x0/0x0/0x0/0x0)

[   22.353908] sound hdaudioC0D2:    mono: mono_out=0x0

[   22.353911] sound hdaudioC0D2:    dig-out=0x1b/0x0

[   22.353913] sound hdaudioC0D2:    inputs:

[   22.353916] sound hdaudioC0D2:      Front Mic=0x14

[   22.353919] sound hdaudioC0D2:      Rear Mic=0x17

[   22.353921] sound hdaudioC0D2:      Line=0x15

[   22.353923] sound hdaudioC0D2:    dig-in=0x1c

[   22.366866] input: HDA Digital PCBeep as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D2/input7

[   22.367371] input: HDA Intel Front Mic as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input8

[   22.367459] input: HDA Intel Rear Mic as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input9

[   22.367977] input: HDA Intel Line as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input10

[   22.368546] input: HDA Intel Line Out Front as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input11

[   22.368616] input: HDA Intel Line Out Surround as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input12

[   22.368680] input: HDA Intel Line Out CLFE as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input13

[   22.368745] input: HDA Intel Line Out Side as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input14

[   22.368819] input: HDA Intel Front Headphone as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input15

[   23.874188] tpm_tis 00:00: tpm_transmit: tpm_send: error -62

[   23.874205] tpm_tis 00:00: A TPM error (-62) occurred attempting to 
determine the timeouts

[   23.886254] tpm_tis 00:00: Adjusting TPM timeout parameters.

[   23.934213] tpm_tis 00:00: TPM is disabled/deactivated (0x6)

[?25l[?1c7[ ok 8[?25h[?0cdone.

[....] Setting parameters of disc: (none)[?25l[?1c7[ 
ok 8[?25h[?0c.


[....] Setting preliminary keymap...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[   24.563713] EXT4-fs (dm-0): re-mounted. Opts: (null)

[....] Checking root file system...fsck from util-linux 2.25.1


/dev/mapper/vg_g2-lv_g2_root: clean, 276615/1048576 files, 
3663404/4194304 blocks


[?25l[?1c7[ ok 8[?25h[?0cdone.


[   24.723128] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro

[   25.036256] xen_acpi_processor: Uploading Xen processor PM info

[   25.055115] xen_pciback: backend is vpci

[   25.081652] fuse init (API version 7.23)

[info] Loading kernel module xen-acpi-processor.


[info] Loading kernel module xen-pciback.


[info] Loading kernel module fuse.


[....] Cleaning up temporary files... 
/tmp[?25l[?1c7[ ok 8[?25h[?0c.


[....] Generating udev events for MD 
arrays...[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Setting up LVM Volume Groups...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Activating lvm and md swap...[   25.748811] Adding 2097148k swap 
on /dev/mapper/vg_g2-lv_g2_swap.  Priority:-1 extents:1 across:2097148k FS

[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Checking file systems...fsck from util-linux 2.25.1


/dev/md0: clean, 334/131072 files, 74476/524224 blocks


[?25l[?1c7[ ok 8[?25h[?0cdone.


[   26.072686] EXT4-fs (md0): mounting ext3 file system using the ext4 
subsystem

[   26.082564] EXT4-fs (md0): mounted filesystem with ordered data mode. 
Opts: (null)

[....] Mounting local filesystems...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Activating swapfile swap...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Cleaning up temporary files...[?25l[?1c7[ ok 
8[?25h[?0c.


[....] Setting kernel variables ...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[   26.766049] Bridge firewalling registered

[   26.773155] device eth0 entered promiscuous mode

[   26.822319] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[   26.825755] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready

[....] Configuring network interfaces...


Waiting for br0 to get ready (MAXWAIT is 32 seconds).


[   29.990761] tg3 0000:05:00.0 eth0: Link is up at 1000 Mbps, full duplex

[   29.990778] tg3 0000:05:00.0 eth0: Flow control is on for TX and on 
for RX

[   29.990798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[   29.990821] br0: port 1(eth0) entered forwarding state

[   29.990829] br0: port 1(eth0) entered forwarding state

[   29.990849] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready

[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Cleaning up temporary files...[?25l[?1c7[ ok 
8[?25h[?0c.


[info] Setting console screen modes.


setterm: cannot (un)set powersave mode: Inappropriate ioctl for device


[9;30][14;30][....] Setting up console font and 
keymap...[?25l[?1c7[ ok 8[?25h[?0cdone.


[   30.864229] ttyS0: LSR safety check engaged!

[   30.866679] ttyS0: LSR safety check engaged!

Loading the saved-state of the serial devices...


/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A


[....] Setting up X socket directories... /tmp/.X11-unix 
/tmp/.ICE-unix[?25l[?1c7[ ok 8[?25h[?0c.


[....] Setting sensors limits[?25l[?1c7[ ok 
8[?25h[?0c.



INIT: Entering runlevel: 2



[info] Using makefile-style concurrent boot in runlevel 2.


[....] Starting enhanced syslogd: 
rsyslogd[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting MD monitoring service: mdadm 
--monitor[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting ACPI services...[?25l[?1c7[ ok 
8[?25h[?0c.


[....] Starting mouse interface server: 
gpm[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting periodic command scheduler: 
cron[?25l[?1c7[ ok 8[?25h[?0c.


[....] Loading cpufreq kernel modules...modprobe: ERROR: could not 
insert 'cpufreq_userspace': No such device


modprobe: ERROR: could not insert 'cpufreq_stats': Invalid argument


modprobe: ERROR: could not insert 'cpufreq_powersave': No such device


modprobe: ERROR: could not insert 'cpufreq_conservative': No such device


[?25l[?1c7[ ok 8[?25h[?0cdone (none).


[....] Starting system message bus: dbus[?25l[?1c7[ 
ok 8[?25h[?0c.


[   31.825880] xen:xen_evtchn: Event-channel device installed

[....] CPUFreq Utilities: Setting ondemand CPUFreq governor...disabled, 
governor not available...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Starting OpenBSD Secure Shell server: 
sshd[?25l[?1c7[ ok 8[?25h[?0c.


Starting /usr/local/sbin/oxenstored...


Setting domain 0 name, domid and JSON config...


Done setting up Dom0


Starting xenconsoled...


Starting QEMU as disk backend for dom0


[9;0][14;0]


[   35.632309] pciback 0000:02:00.0: seizing device

[   35.632389] pciback 0000:02:00.0: enabling device (0004 -> 0007)

[   35.632475] xen: registering gsi 16 triggering 0 polarity 1

[   35.632487] Already setup the GSI :16

libxl: warning: libxl_pci.c:706:libxl__device_pci_assignable_add: 
0000:02:00.0 not bound to a driver, will not be rebound.




Debian GNU/Linux jessie/sid g2 hvc0



g2 login: [   45.034166] br0: port 1(eth0) entered forwarding state

(XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input 
to DOM0)
(XEN) IRQ information:
(XEN)    IRQ:   0 affinity:01 vec:f0 type=IO-APIC-edge status=00000000 
timer_interrupt()
(XEN)    IRQ:   1 affinity:01 vec:30 type=IO-APIC-edge status=00000014 
in-flight=0 domain-list=0:  1(---),
(XEN)    IRQ:   3 affinity:01 vec:38 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   4 affinity:01 vec:f1 type=IO-APIC-edge status=00000000 
ns16550_interrupt()
(XEN)    IRQ:   5 affinity:01 vec:40 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   6 affinity:01 vec:48 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0:  6(---),
(XEN)    IRQ:   7 affinity:01 vec:50 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   8 affinity:01 vec:58 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0:  8(---),
(XEN)    IRQ:   9 affinity:01 vec:60 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0:  9(---),
(XEN)    IRQ:  10 affinity:01 vec:68 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  11 affinity:01 vec:70 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  12 affinity:01 vec:78 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0: 12(---),
(XEN)    IRQ:  13 affinity:3f vec:88 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  14 affinity:01 vec:90 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  15 affinity:01 vec:98 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  16 affinity:01 vec:a0 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 16(---),
(XEN)    IRQ:  17 affinity:01 vec:a8 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 17(---),
(XEN)    IRQ:  18 affinity:01 vec:b0 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 18(---),
(XEN)    IRQ:  19 affinity:01 vec:b8 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 19(---),
(XEN)    IRQ:  24 affinity:3f vec:28 type=DMA_MSI status=00000000 
iommu_page_fault()
(XEN)    IRQ:  25 affinity:01 vec:c0 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:279(---),
(XEN)    IRQ:  26 affinity:01 vec:c8 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:278(---),
(XEN)    IRQ:  27 affinity:01 vec:d0 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:277(---),
(XEN)    IRQ:  28 affinity:01 vec:d8 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:276(---),
(XEN)    IRQ:  29 affinity:01 vec:21 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:275(---),
(XEN)    IRQ:  30 affinity:01 vec:29 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:274(---),
(XEN)    IRQ:  31 affinity:3f vec:31 type=PCI-MSI status=00000002 
mapped, unbound
(XEN)    IRQ:  32 affinity:3f vec:39 type=PCI-MSI status=00000002 
mapped, unbound
(XEN)    IRQ:  33 affinity:01 vec:49 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:271(---),
(XEN)    IRQ:  34 affinity:01 vec:51 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:270(---),
(XEN)    IRQ:  35 affinity:01 vec:59 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:269(---),
(XEN)    IRQ:  36 affinity:01 vec:61 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:268(---),
(XEN)    IRQ:  37 affinity:01 vec:69 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:267(---),
(XEN)    IRQ:  38 affinity:01 vec:71 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:266(---),
(XEN)    IRQ:  39 affinity:01 vec:79 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:265(---),
(XEN)    IRQ:  40 affinity:01 vec:81 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:264(---),
(XEN)    IRQ:  41 affinity:01 vec:89 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:263(---),
(XEN)    IRQ:  42 affinity:01 vec:91 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:262(---),
(XEN)    IRQ:  43 affinity:01 vec:99 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:261(---),
(XEN) Direct vector information:
(XEN)    0x20 -> irq_move_cleanup_interrupt()
(XEN)    0xf2 -> cmci_interrupt()
(XEN)    0xf3 -> intel_thermal_interrupt()
(XEN)    0xf9 -> pmu_apic_interrupt()
(XEN)    0xfa -> apic_timer_interrupt()
(XEN)    0xfb -> call_function_interrupt()
(XEN)    0xfc -> event_check_interrupt()
(XEN)    0xfd -> invalidate_interrupt()
(XEN)    0xfe -> error_interrupt()
(XEN)    0xff -> spurious_interrupt()
(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 48:
(XEN)       Apic 0x00, Pin  1: vec=30 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  3 Vec 56:
(XEN)       Apic 0x00, Pin  3: vec=38 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 64:
(XEN)       Apic 0x00, Pin  5: vec=40 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  6 Vec 72:
(XEN)       Apic 0x00, Pin  6: vec=48 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  7 Vec 80:
(XEN)       Apic 0x00, Pin  7: vec=50 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  8 Vec 88:
(XEN)       Apic 0x00, Pin  8: vec=58 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  9 Vec 96:
(XEN)       Apic 0x00, Pin  9: vec=60 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 10 Vec104:
(XEN)       Apic 0x00, Pin 10: vec=68 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 11 Vec112:
(XEN)       Apic 0x00, Pin 11: vec=70 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 12 Vec120:
(XEN)       Apic 0x00, Pin 12: vec=78 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 13 Vec136:
(XEN)       Apic 0x00, Pin 13: vec=88 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=1 dest_id:63
(XEN)     IRQ 14 Vec144:
(XEN)       Apic 0x00, Pin 14: vec=90 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 15 Vec152:
(XEN)       Apic 0x00, Pin 15: vec=98 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 16 Vec160:
(XEN)       Apic 0x00, Pin 16: vec=a0 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 17 Vec168:
(XEN)       Apic 0x00, Pin 17: vec=a8 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 18 Vec176:
(XEN)       Apic 0x00, Pin 18: vec=b0 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 19 Vec184:
(XEN)       Apic 0x00, Pin 19: vec=b8 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 02:03:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 02:03:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsMWM-0005RX-9N; Sun, 23 Nov 2014 02:03:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsMWL-0005RS-7C
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 02:03:25 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	07/D0-02954-C6041745; Sun, 23 Nov 2014 02:03:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416708200!14188920!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25247 invoked from network); 23 Nov 2014 02:03:22 -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;
	23 Nov 2014 02:03:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,440,1413244800"; d="scan'208";a="194452725"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 21:02:14 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsMVC-000223-FC;
	Sun, 23 Nov 2014 02:02:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsMVC-0000Gv-8i;
	Sun, 23 Nov 2014 02:02:14 +0000
Date: Sun, 23 Nov 2014 02:02:14 +0000
Message-ID: <E1XsMVC-0000Gv-8i@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [libvirt bisection] complete build-armhf-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

branch xen-unstable
xen branch xen-unstable
job build-armhf-libvirt
test libvirt-build

Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
Tree: libvirt git://libvirt.org/libvirt.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  2aa167cafd507730890c54dc577fff0968ee7386
  Bug not present: bac66a6066631b60a8f3ebcc37be515980419d0d


  commit 2aa167cafd507730890c54dc577fff0968ee7386
  Author: Eric Blake <eblake@redhat.com>
  Date:   Mon Nov 17 17:18:58 2014 -0700
  
      virdbus: don't force users to pass int for bool values
      
      Use of an 'int' to represent a 'bool' value is confusing.  Just
      because dbus made the mistake of cementing their 4-byte wire
      format of dbus_bool_t into their API doesn't mean we have to
      repeat the mistake.  With a little bit of finesse, we can
      guarantee that we provide a large-enough value to the DBus
      code, while still copying only the relevant one-byte bool
      to the client code, and isolate the rest of our code base from
      the DBus stupidity.
      
      * src/util/virdbus.c (GET_NEXT_VAL): Add parameter.
      (virDBusMessageIterDecode): Adjust all clients.
      * src/util/virpolkit.c (virPolkitCheckAuth): Use nicer type.
      * tests/virdbustest.c (testMessageSimple, testMessageStruct):
      Test new behavior.
      
      Signed-off-by: Eric Blake <eblake@redhat.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.libvirt.build-armhf-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31761 fail [host=marilith-n4] / 31680 ok.
Failure / basis pass flights: 31761 / 31680
Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
Tree: libvirt git://libvirt.org/libvirt.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 6dd16adf3feba066fba6d32a5cadc2c949967072 b7d1bee2b9a8d7ed76456447b090702223da39f5 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
Basis pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb 6c79469ccc3245b9572dcaabe8cd620ba3fabfad 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Generating revisions with ./adhoc-revtuple-generator  git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]#e9dd4906da30642172e6bb1ff2703e8e2c912fcb-6dd16adf3feba066fba6d32a5cadc2c949967072 git://libvirt.org/libvirt.git#6c79469ccc3245b9572dcaabe8cd620ba3fabfad-b7d1bee2b9a8d7ed76456447b090702223da39f5 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51-0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 git://xenbits.xen.org/xen.git#e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2-0540b854f6733759593e829bc3f13c9b45974e32
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/gnulib
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/libvirt
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/gnulib
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/libvirt
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 3001 nodes in revision graph
Searching for test results:
 31680 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb 6c79469ccc3245b9572dcaabe8cd620ba3fabfad 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31799 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb bac66a6066631b60a8f3ebcc37be515980419d0d 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31791 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 225f483314b64d71fc5819ee7a73f3aff3e8280b 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31805 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 2aa167cafd507730890c54dc577fff0968ee7386 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31808 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 2aa167cafd507730890c54dc577fff0968ee7386 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31793 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb 6c79469ccc3245b9572dcaabe8cd620ba3fabfad 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31761 fail 6dd16adf3feba066fba6d32a5cadc2c949967072 b7d1bee2b9a8d7ed76456447b090702223da39f5 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31794 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 6d8054b68407a3385b33c867a425ad8278b0b8f0 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31786 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb 6c79469ccc3245b9572dcaabe8cd620ba3fabfad 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31796 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb 9b7e7e3474a7694e7dbee17e88008fa03e618c4a 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31789 fail 6dd16adf3feba066fba6d32a5cadc2c949967072 b7d1bee2b9a8d7ed76456447b090702223da39f5 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31797 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 2aa167cafd507730890c54dc577fff0968ee7386 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31800 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 2aa167cafd507730890c54dc577fff0968ee7386 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31806 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb bac66a6066631b60a8f3ebcc37be515980419d0d 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31804 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb bac66a6066631b60a8f3ebcc37be515980419d0d 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
Searching for interesting versions
 Result found: flight 31680 (pass), for basis pass
 Result found: flight 31761 (fail), for basis failure
 Repro found: flight 31786 (pass), for basis pass
 Repro found: flight 31789 (fail), for basis failure
 0 revisions at e9dd4906da30642172e6bb1ff2703e8e2c912fcb bac66a6066631b60a8f3ebcc37be515980419d0d 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
No revisions left to test, checking graph state.
 Result found: flight 31799 (pass), for last pass
 Result found: flight 31800 (fail), for first failure
 Repro found: flight 31804 (pass), for last pass
 Repro found: flight 31805 (fail), for first failure
 Repro found: flight 31806 (pass), for last pass
 Repro found: flight 31808 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  2aa167cafd507730890c54dc577fff0968ee7386
  Bug not present: bac66a6066631b60a8f3ebcc37be515980419d0d

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/libvirt
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 2aa167cafd507730890c54dc577fff0968ee7386
  Author: Eric Blake <eblake@redhat.com>
  Date:   Mon Nov 17 17:18:58 2014 -0700
  
      virdbus: don't force users to pass int for bool values
      
      Use of an 'int' to represent a 'bool' value is confusing.  Just
      because dbus made the mistake of cementing their 4-byte wire
      format of dbus_bool_t into their API doesn't mean we have to
      repeat the mistake.  With a little bit of finesse, we can
      guarantee that we provide a large-enough value to the DBus
      code, while still copying only the relevant one-byte bool
      to the client code, and isolate the rest of our code base from
      the DBus stupidity.
      
      * src/util/virdbus.c (GET_NEXT_VAL): Add parameter.
      (virDBusMessageIterDecode): Adjust all clients.
      * src/util/virpolkit.c (virPolkitCheckAuth): Use nicer type.
      * tests/virdbustest.c (testMessageSimple, testMessageStruct):
      Test new behavior.
      
      Signed-off-by: Eric Blake <eblake@redhat.com>

Revision graph left in /home/xc_osstest/results/bisect.libvirt.build-armhf-libvirt.libvirt-build.{dot,ps,png,html}.
----------------------------------------
31808: tolerable ALL FAIL

flight 31808 libvirt real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31808/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build           fail baseline untested


jobs:
 build-armhf-libvirt                                          fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Nov 23 02:03:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 02:03:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsMWM-0005RX-9N; Sun, 23 Nov 2014 02:03:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsMWL-0005RS-7C
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 02:03:25 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	07/D0-02954-C6041745; Sun, 23 Nov 2014 02:03:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416708200!14188920!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25247 invoked from network); 23 Nov 2014 02:03:22 -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;
	23 Nov 2014 02:03:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,440,1413244800"; d="scan'208";a="194452725"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 21:02:14 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsMVC-000223-FC;
	Sun, 23 Nov 2014 02:02:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsMVC-0000Gv-8i;
	Sun, 23 Nov 2014 02:02:14 +0000
Date: Sun, 23 Nov 2014 02:02:14 +0000
Message-ID: <E1XsMVC-0000Gv-8i@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [libvirt bisection] complete build-armhf-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

branch xen-unstable
xen branch xen-unstable
job build-armhf-libvirt
test libvirt-build

Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
Tree: libvirt git://libvirt.org/libvirt.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  2aa167cafd507730890c54dc577fff0968ee7386
  Bug not present: bac66a6066631b60a8f3ebcc37be515980419d0d


  commit 2aa167cafd507730890c54dc577fff0968ee7386
  Author: Eric Blake <eblake@redhat.com>
  Date:   Mon Nov 17 17:18:58 2014 -0700
  
      virdbus: don't force users to pass int for bool values
      
      Use of an 'int' to represent a 'bool' value is confusing.  Just
      because dbus made the mistake of cementing their 4-byte wire
      format of dbus_bool_t into their API doesn't mean we have to
      repeat the mistake.  With a little bit of finesse, we can
      guarantee that we provide a large-enough value to the DBus
      code, while still copying only the relevant one-byte bool
      to the client code, and isolate the rest of our code base from
      the DBus stupidity.
      
      * src/util/virdbus.c (GET_NEXT_VAL): Add parameter.
      (virDBusMessageIterDecode): Adjust all clients.
      * src/util/virpolkit.c (virPolkitCheckAuth): Use nicer type.
      * tests/virdbustest.c (testMessageSimple, testMessageStruct):
      Test new behavior.
      
      Signed-off-by: Eric Blake <eblake@redhat.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.libvirt.build-armhf-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31761 fail [host=marilith-n4] / 31680 ok.
Failure / basis pass flights: 31761 / 31680
Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
Tree: libvirt git://libvirt.org/libvirt.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 6dd16adf3feba066fba6d32a5cadc2c949967072 b7d1bee2b9a8d7ed76456447b090702223da39f5 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
Basis pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb 6c79469ccc3245b9572dcaabe8cd620ba3fabfad 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Generating revisions with ./adhoc-revtuple-generator  git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]#e9dd4906da30642172e6bb1ff2703e8e2c912fcb-6dd16adf3feba066fba6d32a5cadc2c949967072 git://libvirt.org/libvirt.git#6c79469ccc3245b9572dcaabe8cd620ba3fabfad-b7d1bee2b9a8d7ed76456447b090702223da39f5 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51-0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 git://xenbits.xen.org/xen.git#e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2-0540b854f6733759593e829bc3f13c9b45974e32
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/gnulib
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/libvirt
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/gnulib
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/libvirt
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 3001 nodes in revision graph
Searching for test results:
 31680 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb 6c79469ccc3245b9572dcaabe8cd620ba3fabfad 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31799 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb bac66a6066631b60a8f3ebcc37be515980419d0d 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31791 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 225f483314b64d71fc5819ee7a73f3aff3e8280b 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31805 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 2aa167cafd507730890c54dc577fff0968ee7386 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31808 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 2aa167cafd507730890c54dc577fff0968ee7386 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31793 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb 6c79469ccc3245b9572dcaabe8cd620ba3fabfad 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31761 fail 6dd16adf3feba066fba6d32a5cadc2c949967072 b7d1bee2b9a8d7ed76456447b090702223da39f5 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31794 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 6d8054b68407a3385b33c867a425ad8278b0b8f0 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31786 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb 6c79469ccc3245b9572dcaabe8cd620ba3fabfad 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31796 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb 9b7e7e3474a7694e7dbee17e88008fa03e618c4a 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31789 fail 6dd16adf3feba066fba6d32a5cadc2c949967072 b7d1bee2b9a8d7ed76456447b090702223da39f5 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31797 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 2aa167cafd507730890c54dc577fff0968ee7386 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31800 fail e9dd4906da30642172e6bb1ff2703e8e2c912fcb 2aa167cafd507730890c54dc577fff0968ee7386 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31806 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb bac66a6066631b60a8f3ebcc37be515980419d0d 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31804 pass e9dd4906da30642172e6bb1ff2703e8e2c912fcb bac66a6066631b60a8f3ebcc37be515980419d0d 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
Searching for interesting versions
 Result found: flight 31680 (pass), for basis pass
 Result found: flight 31761 (fail), for basis failure
 Repro found: flight 31786 (pass), for basis pass
 Repro found: flight 31789 (fail), for basis failure
 0 revisions at e9dd4906da30642172e6bb1ff2703e8e2c912fcb bac66a6066631b60a8f3ebcc37be515980419d0d 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
No revisions left to test, checking graph state.
 Result found: flight 31799 (pass), for last pass
 Result found: flight 31800 (fail), for first failure
 Repro found: flight 31804 (pass), for last pass
 Repro found: flight 31805 (fail), for first failure
 Repro found: flight 31806 (pass), for last pass
 Repro found: flight 31808 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  2aa167cafd507730890c54dc577fff0968ee7386
  Bug not present: bac66a6066631b60a8f3ebcc37be515980419d0d

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/libvirt
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 2aa167cafd507730890c54dc577fff0968ee7386
  Author: Eric Blake <eblake@redhat.com>
  Date:   Mon Nov 17 17:18:58 2014 -0700
  
      virdbus: don't force users to pass int for bool values
      
      Use of an 'int' to represent a 'bool' value is confusing.  Just
      because dbus made the mistake of cementing their 4-byte wire
      format of dbus_bool_t into their API doesn't mean we have to
      repeat the mistake.  With a little bit of finesse, we can
      guarantee that we provide a large-enough value to the DBus
      code, while still copying only the relevant one-byte bool
      to the client code, and isolate the rest of our code base from
      the DBus stupidity.
      
      * src/util/virdbus.c (GET_NEXT_VAL): Add parameter.
      (virDBusMessageIterDecode): Adjust all clients.
      * src/util/virpolkit.c (virPolkitCheckAuth): Use nicer type.
      * tests/virdbustest.c (testMessageSimple, testMessageStruct):
      Test new behavior.
      
      Signed-off-by: Eric Blake <eblake@redhat.com>

Revision graph left in /home/xc_osstest/results/bisect.libvirt.build-armhf-libvirt.libvirt-build.{dot,ps,png,html}.
----------------------------------------
31808: tolerable ALL FAIL

flight 31808 libvirt real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31808/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build           fail baseline untested


jobs:
 build-armhf-libvirt                                          fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Nov 23 03:53:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 03:53:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsOEc-000680-Gw; Sun, 23 Nov 2014 03:53:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsOEb-00067v-7N
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 03:53:13 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	6E/CB-24859-82A51745; Sun, 23 Nov 2014 03:53:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416714790!13201064!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5241 invoked from network); 23 Nov 2014 03:53:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2014 03:53:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,441,1413244800"; d="scan'208";a="194499363"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 22:51:11 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsOCd-0002YR-H2;
	Sun, 23 Nov 2014 03:51:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsOCd-0005Pd-Ar;
	Sun, 23 Nov 2014 03:51:11 +0000
Date: Sun, 23 Nov 2014 03:51:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31772-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31772: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31772 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31772/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 31536

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 11 guest-saverestore         fail REGR. vs. 31536

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
baseline version:
 xen                  d6281e354393f1c8a02fac55f4f611b4d4856303

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Thu Nov 20 17:45:04 2014 +0100

    x86/mm: fix a reference counting error in MMU_MACHPHYS_UPDATE
    
    Any domain which can pass the XSM check against a translated guest can cause a
    page reference to be leaked.
    
    While shuffling the order of checks, drop the quite-pointless MEM_LOG().  This
    brings the check in line with similar checks in the vicinity.
    
    Discovered while reviewing the XSA-109/110 followup series.
    
    This is XSA-113.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 82fa0623454a52c7d1812a9419c4cc09567d243d
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:31:21 2014 +0100

    x86emul: enforce privilege level restrictions when loading CS
    
    Privilege level checks were basically missing for the CS case, the
    only check that was done (RPL == DPL for nonconforming segments)
    was solely covering a single special case (return to non-conforming
    segment).
    
    Additionally in long mode the L bit set requires the D bit to be clear,
    as was recently pointed out for KVM by Nadav Amit
    <namit@cs.technion.ac.il>.
    
    Finally we also need to force the loaded selector's RPL to CPL (at
    least as long as lret/retf emulation doesn't support privilege level
    changes).
    
    This is CVE-2014-8595 / XSA-110.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: 1d68c1a70e00ed95ef0889cfa005379dab27b37d
    master date: 2014-11-18 14:16:23 +0100

commit c6e304d8335c9d8c447d743fd1163fbe8bccf245
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:30:37 2014 +0100

    x86: don't allow page table updates on non-PV page tables in do_mmu_update()
    
    paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
    consistently supported for non-PV guests (they'd deref NULL for PVH or
    non-HAP HVM ones). Don't allow respective MMU_* operations on the
    page tables of such domains.
    
    This is CVE-2014-8594 / XSA-109.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    master commit: e4292c5aac41b80f33d4877104348d5ee7c95aa4
    master date: 2014-11-18 14:15:21 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 03:53:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 03:53:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsOEc-000680-Gw; Sun, 23 Nov 2014 03:53:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsOEb-00067v-7N
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 03:53:13 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	6E/CB-24859-82A51745; Sun, 23 Nov 2014 03:53:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416714790!13201064!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5241 invoked from network); 23 Nov 2014 03:53:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2014 03:53:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,441,1413244800"; d="scan'208";a="194499363"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 22 Nov 2014 22:51:11 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsOCd-0002YR-H2;
	Sun, 23 Nov 2014 03:51:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsOCd-0005Pd-Ar;
	Sun, 23 Nov 2014 03:51:11 +0000
Date: Sun, 23 Nov 2014 03:51:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31772-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31772: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31772 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31772/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 31536

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 11 guest-saverestore         fail REGR. vs. 31536

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
baseline version:
 xen                  d6281e354393f1c8a02fac55f4f611b4d4856303

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Thu Nov 20 17:45:04 2014 +0100

    x86/mm: fix a reference counting error in MMU_MACHPHYS_UPDATE
    
    Any domain which can pass the XSM check against a translated guest can cause a
    page reference to be leaked.
    
    While shuffling the order of checks, drop the quite-pointless MEM_LOG().  This
    brings the check in line with similar checks in the vicinity.
    
    Discovered while reviewing the XSA-109/110 followup series.
    
    This is XSA-113.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 82fa0623454a52c7d1812a9419c4cc09567d243d
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:31:21 2014 +0100

    x86emul: enforce privilege level restrictions when loading CS
    
    Privilege level checks were basically missing for the CS case, the
    only check that was done (RPL == DPL for nonconforming segments)
    was solely covering a single special case (return to non-conforming
    segment).
    
    Additionally in long mode the L bit set requires the D bit to be clear,
    as was recently pointed out for KVM by Nadav Amit
    <namit@cs.technion.ac.il>.
    
    Finally we also need to force the loaded selector's RPL to CPL (at
    least as long as lret/retf emulation doesn't support privilege level
    changes).
    
    This is CVE-2014-8595 / XSA-110.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: 1d68c1a70e00ed95ef0889cfa005379dab27b37d
    master date: 2014-11-18 14:16:23 +0100

commit c6e304d8335c9d8c447d743fd1163fbe8bccf245
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 18 14:30:37 2014 +0100

    x86: don't allow page table updates on non-PV page tables in do_mmu_update()
    
    paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
    consistently supported for non-PV guests (they'd deref NULL for PVH or
    non-HAP HVM ones). Don't allow respective MMU_* operations on the
    page tables of such domains.
    
    This is CVE-2014-8594 / XSA-109.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    master commit: e4292c5aac41b80f33d4877104348d5ee7c95aa4
    master date: 2014-11-18 14:15:21 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 07:30:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 07:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsRcF-0007rB-5f; Sun, 23 Nov 2014 07:29:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsRcD-0007r6-Us
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 07:29:50 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	D7/DA-26652-CEC81745; Sun, 23 Nov 2014 07:29:48 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416727786!5267752!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16178 invoked from network); 23 Nov 2014 07:29:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2014 07:29:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,442,1413244800"; d="scan'208";a="195727672"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 02:29:45 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsRc9-0003g9-7r;
	Sun, 23 Nov 2014 07:29:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsRc9-0000pg-2T;
	Sun, 23 Nov 2014 07:29:45 +0000
Date: Sun, 23 Nov 2014 07:29:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31775-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31775: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31775 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31775/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 33063 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 Nov 23 07:30:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 07:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsRcF-0007rB-5f; Sun, 23 Nov 2014 07:29:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsRcD-0007r6-Us
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 07:29:50 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	D7/DA-26652-CEC81745; Sun, 23 Nov 2014 07:29:48 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416727786!5267752!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16178 invoked from network); 23 Nov 2014 07:29:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2014 07:29:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,442,1413244800"; d="scan'208";a="195727672"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 02:29:45 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsRc9-0003g9-7r;
	Sun, 23 Nov 2014 07:29:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsRc9-0000pg-2T;
	Sun, 23 Nov 2014 07:29:45 +0000
Date: Sun, 23 Nov 2014 07:29:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31775-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31775: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31775 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31775/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 33063 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 Nov 23 10:11:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 10:11:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsU8F-00013J-AU; Sun, 23 Nov 2014 10:11:03 +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 1XsU8C-00013E-8D
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 10:11:00 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	EE/03-28865-3B2B1745; Sun, 23 Nov 2014 10:10:59 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416737457!7571865!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6613 invoked from network); 23 Nov 2014 10:10:58 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2014 10:10: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 sANAApcU024501
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Sun, 23 Nov 2014 05:10:52 -0500
Received: from redhat.com (ovpn-116-38.ams2.redhat.com [10.36.116.38])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sANAAmUR030478; Sun, 23 Nov 2014 05:10:49 -0500
Date: Sun, 23 Nov 2014 12:10:47 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141123101047.GA3109@redhat.com>
References: <1407836957-29098-1-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1407836957-29098-1-git-send-email-tiejun.chen@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v5][PATCH 0/4] xen: introduce new machine for IGD
	passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Aug 12, 2014 at 05:49:13PM +0800, Tiejun Chen wrote:
> v5:
> 
> * Simplify to make sure its really inherited from the standard one in patch #3
> * Then drop the original patch #3

I carried
	i440fx: make types configurable at run-time
	pc_init1: pass parameters just with types
	xen:hw:pci-host:piix: create host bridge to passthrough
	qom-test: blacklist xenigd
	xen:hw:i386:pc_piix: introduce new machine for IGD passthrough

on my branch for a while now, but I'm not sure it's all still needed.
If yes simply include these patches next time you repost the
patchset.

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 10:11:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 10:11:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsU8F-00013J-AU; Sun, 23 Nov 2014 10:11:03 +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 1XsU8C-00013E-8D
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 10:11:00 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	EE/03-28865-3B2B1745; Sun, 23 Nov 2014 10:10:59 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416737457!7571865!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6613 invoked from network); 23 Nov 2014 10:10:58 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2014 10:10: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 sANAApcU024501
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Sun, 23 Nov 2014 05:10:52 -0500
Received: from redhat.com (ovpn-116-38.ams2.redhat.com [10.36.116.38])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id sANAAmUR030478; Sun, 23 Nov 2014 05:10:49 -0500
Date: Sun, 23 Nov 2014 12:10:47 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141123101047.GA3109@redhat.com>
References: <1407836957-29098-1-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1407836957-29098-1-git-send-email-tiejun.chen@intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v5][PATCH 0/4] xen: introduce new machine for IGD
	passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Aug 12, 2014 at 05:49:13PM +0800, Tiejun Chen wrote:
> v5:
> 
> * Simplify to make sure its really inherited from the standard one in patch #3
> * Then drop the original patch #3

I carried
	i440fx: make types configurable at run-time
	pc_init1: pass parameters just with types
	xen:hw:pci-host:piix: create host bridge to passthrough
	qom-test: blacklist xenigd
	xen:hw:i386:pc_piix: introduce new machine for IGD passthrough

on my branch for a while now, but I'm not sure it's all still needed.
If yes simply include these patches next time you repost the
patchset.

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 13: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 1XsWni-00029e-HG; Sun, 23 Nov 2014 13:02:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsWng-00029Y-Pb
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 13:02:01 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	EE/D8-17958-7CAD1745; Sun, 23 Nov 2014 13:01:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416747717!9509041!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10842 invoked from network); 23 Nov 2014 13:01:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2014 13:01:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,443,1413244800"; d="scan'208";a="195770477"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 08:01:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsWnc-0005RC-3U;
	Sun, 23 Nov 2014 13:01:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsWnb-0001CR-TF;
	Sun, 23 Nov 2014 13:01:55 +0000
Date: Sun, 23 Nov 2014 13:01:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31779-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31779: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31779 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31779/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31647

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install       fail pass in 31729
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10 fail in 31729 pass in 31779
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 31729 pass in 31779

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop      fail in 31729 never pass

version targeted for testing:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a
baseline version:
 qemuu                0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51

------------------------------------------------------------
People who touched revisions under test:
  Don Slutz <dslutz@verizon.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 a230ec3101ddda868252c036ea960af2b2d6cd5a
Author: Don Slutz <dslutz@verizon.com>
Date:   Mon Nov 17 16:20:39 2014 -0500

    hw/ide/core.c: Prevent SIGSEGV during migration
    
    The other callers to blk_set_enable_write_cache() in this file
    already check for s->blk == NULL.
    
    upstream-commit-id: 6b896ab261942f441a16836e3fa3c83f3f4488b9
    
    Signed-off-by: Don Slutz <dslutz@verizon.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Message-id: 1416259239-13281-1-git-send-email-dslutz@verizon.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    
    Conflicts:
    	hw/ide/core.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 13:02:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 13: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 1XsWni-00029e-HG; Sun, 23 Nov 2014 13:02:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsWng-00029Y-Pb
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 13:02:01 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	EE/D8-17958-7CAD1745; Sun, 23 Nov 2014 13:01:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416747717!9509041!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10842 invoked from network); 23 Nov 2014 13:01:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2014 13:01:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,443,1413244800"; d="scan'208";a="195770477"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 08:01:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsWnc-0005RC-3U;
	Sun, 23 Nov 2014 13:01:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsWnb-0001CR-TF;
	Sun, 23 Nov 2014 13:01:55 +0000
Date: Sun, 23 Nov 2014 13:01:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31779-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31779: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31779 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31779/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31647

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install       fail pass in 31729
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10 fail in 31729 pass in 31779
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 31729 pass in 31779

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop      fail in 31729 never pass

version targeted for testing:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a
baseline version:
 qemuu                0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51

------------------------------------------------------------
People who touched revisions under test:
  Don Slutz <dslutz@verizon.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 a230ec3101ddda868252c036ea960af2b2d6cd5a
Author: Don Slutz <dslutz@verizon.com>
Date:   Mon Nov 17 16:20:39 2014 -0500

    hw/ide/core.c: Prevent SIGSEGV during migration
    
    The other callers to blk_set_enable_write_cache() in this file
    already check for s->blk == NULL.
    
    upstream-commit-id: 6b896ab261942f441a16836e3fa3c83f3f4488b9
    
    Signed-off-by: Don Slutz <dslutz@verizon.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Message-id: 1416259239-13281-1-git-send-email-dslutz@verizon.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    
    Conflicts:
    	hw/ide/core.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 14:06:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 14:06:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsXnT-0002cv-UK; Sun, 23 Nov 2014 14:05:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1XsXnS-0002cq-UT
	for xen-devel@lists.xen.org; Sun, 23 Nov 2014 14:05:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BA/79-09842-EB9E1745; Sun, 23 Nov 2014 14:05:50 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416751549!14721757!1
X-Originating-IP: [62.142.5.109]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTA5ID0+IDk1MjIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5070 invoked from network); 23 Nov 2014 14:05:49 -0000
Received: from emh03.mail.saunalahti.fi (HELO emh03.mail.saunalahti.fi)
	(62.142.5.109)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2014 14:05:49 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh03.mail.saunalahti.fi (Postfix) with ESMTP id C320F18879A;
	Sun, 23 Nov 2014 16:05:48 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 83D4436C01F; Sun, 23 Nov 2014 16:05:48 +0200 (EET)
Date: Sun, 23 Nov 2014 16:05:48 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: greg@enjellic.com
Message-ID: <20141123140548.GL12451@reaktio.net>
References: <greg@wind.enjellic.com>
	<201411212102.sALL2XZu001067@wind.enjellic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201411212102.sALL2XZu001067@wind.enjellic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 03:02:33PM -0600, Dr. Greg Wettstein wrote:
> On Nov 21,  2:57pm, "Dr. Greg Wettstein" wrote:
> } Subject: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
> 
> > Hi, hope the week is ending well for everyone.
> 
> As I was walking out the door I remembered I had been delinquent with
> information.  The dom0 kernel is 32-bit 3.14.22 straight from
> kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.
>

Wow, quite an old thread :)
 
So you're still seeing the same problem with recent Xen/Linux versions.. 


> The machine hang is reproducible in the absence of even starting a
> guest so the problem appears to be specific to the process of
> preparing the device for export through xen-pciback.
> 

OK.. Maybe Konrad has some thoughts about this.


-- Pasi


> Greg
> 
> }-- End of excerpt from "Dr. Greg Wettstein"
> 
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: greg@enjellic.com
> ------------------------------------------------------------------------------
> "Fools ignore complexity.  Pragmatists suffer it.  Some can avoid it.
> Geniuses remove it.
>                                 -- Perliss' Programming Proverb #58
>                                    SIGPLAN National, Sept. 1982
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 14:06:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 14:06:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsXnT-0002cv-UK; Sun, 23 Nov 2014 14:05:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1XsXnS-0002cq-UT
	for xen-devel@lists.xen.org; Sun, 23 Nov 2014 14:05:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BA/79-09842-EB9E1745; Sun, 23 Nov 2014 14:05:50 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416751549!14721757!1
X-Originating-IP: [62.142.5.109]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTA5ID0+IDk1MjIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5070 invoked from network); 23 Nov 2014 14:05:49 -0000
Received: from emh03.mail.saunalahti.fi (HELO emh03.mail.saunalahti.fi)
	(62.142.5.109)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2014 14:05:49 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh03.mail.saunalahti.fi (Postfix) with ESMTP id C320F18879A;
	Sun, 23 Nov 2014 16:05:48 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 83D4436C01F; Sun, 23 Nov 2014 16:05:48 +0200 (EET)
Date: Sun, 23 Nov 2014 16:05:48 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: greg@enjellic.com
Message-ID: <20141123140548.GL12451@reaktio.net>
References: <greg@wind.enjellic.com>
	<201411212102.sALL2XZu001067@wind.enjellic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201411212102.sALL2XZu001067@wind.enjellic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 03:02:33PM -0600, Dr. Greg Wettstein wrote:
> On Nov 21,  2:57pm, "Dr. Greg Wettstein" wrote:
> } Subject: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
> 
> > Hi, hope the week is ending well for everyone.
> 
> As I was walking out the door I remembered I had been delinquent with
> information.  The dom0 kernel is 32-bit 3.14.22 straight from
> kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.
>

Wow, quite an old thread :)
 
So you're still seeing the same problem with recent Xen/Linux versions.. 


> The machine hang is reproducible in the absence of even starting a
> guest so the problem appears to be specific to the process of
> preparing the device for export through xen-pciback.
> 

OK.. Maybe Konrad has some thoughts about this.


-- Pasi


> Greg
> 
> }-- End of excerpt from "Dr. Greg Wettstein"
> 
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: greg@enjellic.com
> ------------------------------------------------------------------------------
> "Fools ignore complexity.  Pragmatists suffer it.  Some can avoid it.
> Geniuses remove it.
>                                 -- Perliss' Programming Proverb #58
>                                    SIGPLAN National, Sept. 1982
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 14:23:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 14:23:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsY4i-0002qD-OF; Sun, 23 Nov 2014 14:23:40 +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 1XsY4h-0002q8-JF
	for xen-devel@lists.xen.org; Sun, 23 Nov 2014 14:23:39 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	02/74-11608-AEDE1745; Sun, 23 Nov 2014 14:23:38 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416752617!13226359!1
X-Originating-IP: [62.142.5.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTE3ID0+IDk1NDU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9646 invoked from network); 23 Nov 2014 14:23:38 -0000
Received: from emh07.mail.saunalahti.fi (HELO emh07.mail.saunalahti.fi)
	(62.142.5.117)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2014 14:23:38 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 28857400E;
	Sun, 23 Nov 2014 16:23:36 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EA6F636C01F; Sun, 23 Nov 2014 16:23:36 +0200 (EET)
Date: Sun, 23 Nov 2014 16:23:36 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: greg@enjellic.com
Message-ID: <20141123142336.GM12451@reaktio.net>
References: <greg@wind.enjellic.com>
	<201411212102.sALL2XZu001067@wind.enjellic.com>
	<20141123140548.GL12451@reaktio.net>
MIME-Version: 1.0
Content-Length: 2094
Content-Disposition: inline
In-Reply-To: <20141123140548.GL12451@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Nov 23, 2014 at 04:05:48PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Fri, Nov 21, 2014 at 03:02:33PM -0600, Dr. Greg Wettstein wrote:
> > On Nov 21,  2:57pm, "Dr. Greg Wettstein" wrote:
> > } Subject: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
> > =

> > > Hi, hope the week is ending well for everyone.
> > =

> > As I was walking out the door I remembered I had been delinquent with
> > information.  The dom0 kernel is 32-bit 3.14.22 straight from
> > kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.
> >
> =

> Wow, quite an old thread :)
> =



Oh, there's also the new thread about this, I guess it's better to continue=
 there :)

http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02123.html



-- Pasi

 =

> So you're still seeing the same problem with recent Xen/Linux versions.. =

> =

> =

> > The machine hang is reproducible in the absence of even starting a
> > guest so the problem appears to be specific to the process of
> > preparing the device for export through xen-pciback.
> > =

> =

> OK.. Maybe Konrad has some thoughts about this.
> =

> =

> -- Pasi
> =

> =

> > Greg
> > =

> > }-- End of excerpt from "Dr. Greg Wettstein"
> > =

> > As always,
> > Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> > 4206 N. 19th Ave.           Specializing in information infra-structure
> > Fargo, ND  58102            development.
> > PH: 701-281-1686
> > FAX: 701-281-3949           EMAIL: greg@enjellic.com
> > -----------------------------------------------------------------------=
-------
> > "Fools ignore complexity.  Pragmatists suffer it.  Some can avoid it.
> > Geniuses remove it.
> >                                 -- Perliss' Programming Proverb #58
> >                                    SIGPLAN National, Sept. 1982
> > =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 14:23:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 14:23:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsY4i-0002qD-OF; Sun, 23 Nov 2014 14:23:40 +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 1XsY4h-0002q8-JF
	for xen-devel@lists.xen.org; Sun, 23 Nov 2014 14:23:39 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	02/74-11608-AEDE1745; Sun, 23 Nov 2014 14:23:38 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416752617!13226359!1
X-Originating-IP: [62.142.5.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTE3ID0+IDk1NDU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9646 invoked from network); 23 Nov 2014 14:23:38 -0000
Received: from emh07.mail.saunalahti.fi (HELO emh07.mail.saunalahti.fi)
	(62.142.5.117)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2014 14:23:38 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 28857400E;
	Sun, 23 Nov 2014 16:23:36 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EA6F636C01F; Sun, 23 Nov 2014 16:23:36 +0200 (EET)
Date: Sun, 23 Nov 2014 16:23:36 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: greg@enjellic.com
Message-ID: <20141123142336.GM12451@reaktio.net>
References: <greg@wind.enjellic.com>
	<201411212102.sALL2XZu001067@wind.enjellic.com>
	<20141123140548.GL12451@reaktio.net>
MIME-Version: 1.0
Content-Length: 2094
Content-Disposition: inline
In-Reply-To: <20141123140548.GL12451@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Nov 23, 2014 at 04:05:48PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Fri, Nov 21, 2014 at 03:02:33PM -0600, Dr. Greg Wettstein wrote:
> > On Nov 21,  2:57pm, "Dr. Greg Wettstein" wrote:
> > } Subject: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
> > =

> > > Hi, hope the week is ending well for everyone.
> > =

> > As I was walking out the door I remembered I had been delinquent with
> > information.  The dom0 kernel is 32-bit 3.14.22 straight from
> > kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.
> >
> =

> Wow, quite an old thread :)
> =



Oh, there's also the new thread about this, I guess it's better to continue=
 there :)

http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02123.html



-- Pasi

 =

> So you're still seeing the same problem with recent Xen/Linux versions.. =

> =

> =

> > The machine hang is reproducible in the absence of even starting a
> > guest so the problem appears to be specific to the process of
> > preparing the device for export through xen-pciback.
> > =

> =

> OK.. Maybe Konrad has some thoughts about this.
> =

> =

> -- Pasi
> =

> =

> > Greg
> > =

> > }-- End of excerpt from "Dr. Greg Wettstein"
> > =

> > As always,
> > Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> > 4206 N. 19th Ave.           Specializing in information infra-structure
> > Fargo, ND  58102            development.
> > PH: 701-281-1686
> > FAX: 701-281-3949           EMAIL: greg@enjellic.com
> > -----------------------------------------------------------------------=
-------
> > "Fools ignore complexity.  Pragmatists suffer it.  Some can avoid it.
> > Geniuses remove it.
> >                                 -- Perliss' Programming Proverb #58
> >                                    SIGPLAN National, Sept. 1982
> > =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 14:26:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 14:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsY7r-0002wq-Aj; Sun, 23 Nov 2014 14:26:55 +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 1XsY7p-0002wi-44
	for xen-devel@lists.xen.org; Sun, 23 Nov 2014 14:26:53 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	DB/40-26858-CAEE1745; Sun, 23 Nov 2014 14:26:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416752811!13226622!1
X-Originating-IP: [62.142.5.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTE3ID0+IDk1NDU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20367 invoked from network); 23 Nov 2014 14:26:51 -0000
Received: from emh07.mail.saunalahti.fi (HELO emh07.mail.saunalahti.fi)
	(62.142.5.117)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2014 14:26:51 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 409363FCC;
	Sun, 23 Nov 2014 16:26:51 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 114AC36C01F; Sun, 23 Nov 2014 16:26:51 +0200 (EET)
Date: Sun, 23 Nov 2014 16:26:50 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: greg@enjellic.com
Message-ID: <20141123142650.GN12451@reaktio.net>
References: <201411212057.sALKvEwO000992@wind.enjellic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201411212057.sALKvEwO000992@wind.enjellic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 02:57:14PM -0600, Dr. Greg Wettstein wrote:
> Hi, hope the week is ending well for everyone.
> 
> As readers of the list may remember we've kept the ATI primary adapter
> passthrough patches current for qemu-traditional on Xen for a number
> of years.  Our 'run-passthrough' utility for binding/unbind devices
> and running a Windows guest with passthrough have enjoyed a tidy
> number of downloads through the years as well.
> 
> We are taking on a passthrough project and in the process upgrading
> our infrastructure to 4.4.x.  We also need to take on the issue of
> passing Intel IGD adapters through to a windows guest.  We are
> currently working on an Intel Q77 (DQ77KB) board in preparation for
> moving to Q87 boards.
> 
> The Intel display adapter is showing up as the standard 00:02.0 PCI
> device and things go south pretty quickly.  We create a slot for the
> device on the pciback driver and as soon as we bind the device the
> machine goes out like a light, no logs or diagnostics, just instantly
> stone dead.
>

This might be a stupid question, but here goes anyway:
Do you have serial console set up? And all the debug/verbose options specified for Xen and Linux? 


Thanks,

-- Pasi

 
> This issue is invariant over pciback in vpci or passthrough modes.  It
> also occurs instantly when the pciback assignment is made with 'xl
> pci-assignable-add'.
> 
> We will throw a '#define DEBUG 1' in the top of all the xen-pciback
> driver code and see if we can get more information out of it.  I just
> wanted to get this in front of the list in case this is a well known
> issue or we are headed into other problems we should know about.
> 
> I'm assuming that qemu-traditional will handle an IGD primary
> passthrough.  If any of the Intel guys are reading this give me a
> shout with some directions/advice if we need to roll up our sleeves
> and modify the device emulator.
> 
> At least it is an "Outlaw Josey Whales bug', not hard to track, leaves
> dead machines wherever it goes... :-)
> 
> Best wishes for a pleasant weekend to everyone.
> 
> Greg
> 
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: greg@enjellic.com
> ------------------------------------------------------------------------------
> "The cynics are right nine times out of ten."
>                                 -- H. L. Mencken
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 14:26:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 14:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsY7r-0002wq-Aj; Sun, 23 Nov 2014 14:26:55 +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 1XsY7p-0002wi-44
	for xen-devel@lists.xen.org; Sun, 23 Nov 2014 14:26:53 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	DB/40-26858-CAEE1745; Sun, 23 Nov 2014 14:26:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416752811!13226622!1
X-Originating-IP: [62.142.5.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTE3ID0+IDk1NDU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20367 invoked from network); 23 Nov 2014 14:26:51 -0000
Received: from emh07.mail.saunalahti.fi (HELO emh07.mail.saunalahti.fi)
	(62.142.5.117)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2014 14:26:51 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 409363FCC;
	Sun, 23 Nov 2014 16:26:51 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 114AC36C01F; Sun, 23 Nov 2014 16:26:51 +0200 (EET)
Date: Sun, 23 Nov 2014 16:26:50 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: greg@enjellic.com
Message-ID: <20141123142650.GN12451@reaktio.net>
References: <201411212057.sALKvEwO000992@wind.enjellic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201411212057.sALKvEwO000992@wind.enjellic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 02:57:14PM -0600, Dr. Greg Wettstein wrote:
> Hi, hope the week is ending well for everyone.
> 
> As readers of the list may remember we've kept the ATI primary adapter
> passthrough patches current for qemu-traditional on Xen for a number
> of years.  Our 'run-passthrough' utility for binding/unbind devices
> and running a Windows guest with passthrough have enjoyed a tidy
> number of downloads through the years as well.
> 
> We are taking on a passthrough project and in the process upgrading
> our infrastructure to 4.4.x.  We also need to take on the issue of
> passing Intel IGD adapters through to a windows guest.  We are
> currently working on an Intel Q77 (DQ77KB) board in preparation for
> moving to Q87 boards.
> 
> The Intel display adapter is showing up as the standard 00:02.0 PCI
> device and things go south pretty quickly.  We create a slot for the
> device on the pciback driver and as soon as we bind the device the
> machine goes out like a light, no logs or diagnostics, just instantly
> stone dead.
>

This might be a stupid question, but here goes anyway:
Do you have serial console set up? And all the debug/verbose options specified for Xen and Linux? 


Thanks,

-- Pasi

 
> This issue is invariant over pciback in vpci or passthrough modes.  It
> also occurs instantly when the pciback assignment is made with 'xl
> pci-assignable-add'.
> 
> We will throw a '#define DEBUG 1' in the top of all the xen-pciback
> driver code and see if we can get more information out of it.  I just
> wanted to get this in front of the list in case this is a well known
> issue or we are headed into other problems we should know about.
> 
> I'm assuming that qemu-traditional will handle an IGD primary
> passthrough.  If any of the Intel guys are reading this give me a
> shout with some directions/advice if we need to roll up our sleeves
> and modify the device emulator.
> 
> At least it is an "Outlaw Josey Whales bug', not hard to track, leaves
> dead machines wherever it goes... :-)
> 
> Best wishes for a pleasant weekend to everyone.
> 
> Greg
> 
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: greg@enjellic.com
> ------------------------------------------------------------------------------
> "The cynics are right nine times out of ten."
>                                 -- H. L. Mencken
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 18:13:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 18: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.xen.org>)
	id 1Xsbed-0004gS-P4; Sun, 23 Nov 2014 18:12:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xsbec-0004gN-Qv
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 18:12:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1B/15-25276-AA322745; Sun, 23 Nov 2014 18:12:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416766376!14756772!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16950 invoked from network); 23 Nov 2014 18:12:57 -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 Nov 2014 18:12:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,444,1413244800"; d="scan'208";a="194767087"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 13:12:25 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xsbe4-0006vg-Pi;
	Sun, 23 Nov 2014 18:12:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xsbe4-0004jc-K2;
	Sun, 23 Nov 2014 18:12:24 +0000
Date: Sun, 23 Nov 2014 18:12:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31787-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31787: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31787 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31787/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 31680

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              42874fa45f9fab99212d0ba3f66cf4671ddb0a30
baseline version:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad

------------------------------------------------------------
People who touched revisions under test:
  Anirban Chakraborty <abchak@juniper.net>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Giuseppe Scrivano <gscrivan@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nehal J Wani <nehaljw.kkd1@gmail.com>
  Peter Krempa <pkrempa@redhat.com>
  Yohan BELLEGUIC <yohan.belleguic@diateam.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 704 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 Nov 23 18:13:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 18: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.xen.org>)
	id 1Xsbed-0004gS-P4; Sun, 23 Nov 2014 18:12:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xsbec-0004gN-Qv
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 18:12:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1B/15-25276-AA322745; Sun, 23 Nov 2014 18:12:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416766376!14756772!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16950 invoked from network); 23 Nov 2014 18:12:57 -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 Nov 2014 18:12:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,444,1413244800"; d="scan'208";a="194767087"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 13:12:25 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xsbe4-0006vg-Pi;
	Sun, 23 Nov 2014 18:12:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xsbe4-0004jc-K2;
	Sun, 23 Nov 2014 18:12:24 +0000
Date: Sun, 23 Nov 2014 18:12:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31787-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31787: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31787 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31787/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 31680

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              42874fa45f9fab99212d0ba3f66cf4671ddb0a30
baseline version:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad

------------------------------------------------------------
People who touched revisions under test:
  Anirban Chakraborty <abchak@juniper.net>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Giuseppe Scrivano <gscrivan@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nehal J Wani <nehaljw.kkd1@gmail.com>
  Peter Krempa <pkrempa@redhat.com>
  Yohan BELLEGUIC <yohan.belleguic@diateam.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 704 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 Nov 23 19:49:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 19:49:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsdA2-0005GF-Jl; Sun, 23 Nov 2014 19:49:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsdA0-0005GA-Is
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 19:49:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	40/33-25276-74A32745; Sun, 23 Nov 2014 19:49:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416772164!7437414!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8606 invoked from network); 23 Nov 2014 19:49:25 -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;
	23 Nov 2014 19:49:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,444,1413244800"; d="scan'208";a="194802838"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 14:49:04 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xsd9c-0007Ot-1o;
	Sun, 23 Nov 2014 19:49:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xsd9b-0001Ko-PP;
	Sun, 23 Nov 2014 19:49:03 +0000
Date: Sun, 23 Nov 2014 19:49:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31760-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31760: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31760 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31760/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 31601

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31601

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 seabios              9f505f715793d99235bd6b4afb2ca7b96ba5729b
baseline version:
 seabios              b0d42bd03225ad61e5421e12b57f633f84637328

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9f505f715793d99235bd6b4afb2ca7b96ba5729b
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Wed Nov 12 18:00:30 2014 -0500

    pciinit: Fix build warning in mch_pci_slot_get_irq()
    
    Some old versions of gcc warn that 'irq might be used uninitialized'.
    Replace the switch statement with an if statement to suppress the
    warning.
    
    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

commit 83c82769d1246a00e1773764505184cb95d4f663
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Wed Nov 12 17:49:33 2014 -0500

    Fix build issue on gcc34
    
    Older versions of gcc may not inline on_extra_stack() and thus cause a
    link error when compiling in 32bit segmented mode.  Test for MODE16
    explicitly in stack_hop_back() to prevent the problem.
    
    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 19:49:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 19:49:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsdA2-0005GF-Jl; Sun, 23 Nov 2014 19:49:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsdA0-0005GA-Is
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 19:49:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	40/33-25276-74A32745; Sun, 23 Nov 2014 19:49:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416772164!7437414!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8606 invoked from network); 23 Nov 2014 19:49:25 -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;
	23 Nov 2014 19:49:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,444,1413244800"; d="scan'208";a="194802838"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 14:49:04 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xsd9c-0007Ot-1o;
	Sun, 23 Nov 2014 19:49:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xsd9b-0001Ko-PP;
	Sun, 23 Nov 2014 19:49:03 +0000
Date: Sun, 23 Nov 2014 19:49:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31760-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31760: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31760 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31760/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 31601

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31601

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 seabios              9f505f715793d99235bd6b4afb2ca7b96ba5729b
baseline version:
 seabios              b0d42bd03225ad61e5421e12b57f633f84637328

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 9f505f715793d99235bd6b4afb2ca7b96ba5729b
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Wed Nov 12 18:00:30 2014 -0500

    pciinit: Fix build warning in mch_pci_slot_get_irq()
    
    Some old versions of gcc warn that 'irq might be used uninitialized'.
    Replace the switch statement with an if statement to suppress the
    warning.
    
    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

commit 83c82769d1246a00e1773764505184cb95d4f663
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Wed Nov 12 17:49:33 2014 -0500

    Fix build issue on gcc34
    
    Older versions of gcc may not inline on_extra_stack() and thus cause a
    link error when compiling in 32bit segmented mode.  Test for MODE16
    explicitly in stack_hop_back() to prevent the problem.
    
    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 20:18:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 20:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsdbc-0005bk-4i; Sun, 23 Nov 2014 20:18:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsdbZ-0005bf-Sc
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 20:17:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5A/5B-25276-5F042745; Sun, 23 Nov 2014 20:17:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416773875!14670271!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19237 invoked from network); 23 Nov 2014 20:17:56 -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 Nov 2014 20:17:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,444,1413244800"; d="scan'208";a="195845804"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 15:17:53 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsdbV-0007Xc-8E;
	Sun, 23 Nov 2014 20:17:53 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsdbV-0002I4-2H;
	Sun, 23 Nov 2014 20:17:53 +0000
Date: Sun, 23 Nov 2014 20:17:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31781-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31781: 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 31781 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31781/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
baseline version:
 xen                  d279f6e1344871d71e379cc06c7baa6d4f9f0b29

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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.4-testing
+ revision=7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.4-testing 7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
+ branch=xen-4.4-testing
+ revision=7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.4-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.4-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.4-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.4-testing.git
++ : daily-cron.xen-4.4-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.4-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.4-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.4-testing
+ xenversion=xen-4.4
+ xenversion=4.4
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 7679aeb444ed3bc4de0f473c16c47eab7d2f9d33:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   d279f6e..7679aeb  7679aeb444ed3bc4de0f473c16c47eab7d2f9d33 -> stable-4.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 20:18:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 20:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsdbc-0005bk-4i; Sun, 23 Nov 2014 20:18:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsdbZ-0005bf-Sc
	for xen-devel@lists.xensource.com; Sun, 23 Nov 2014 20:17:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5A/5B-25276-5F042745; Sun, 23 Nov 2014 20:17:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416773875!14670271!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19237 invoked from network); 23 Nov 2014 20:17:56 -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 Nov 2014 20:17:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,444,1413244800"; d="scan'208";a="195845804"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 15:17:53 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsdbV-0007Xc-8E;
	Sun, 23 Nov 2014 20:17:53 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsdbV-0002I4-2H;
	Sun, 23 Nov 2014 20:17:53 +0000
Date: Sun, 23 Nov 2014 20:17:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31781-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31781: 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 31781 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31781/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
baseline version:
 xen                  d279f6e1344871d71e379cc06c7baa6d4f9f0b29

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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.4-testing
+ revision=7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.4-testing 7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
+ branch=xen-4.4-testing
+ revision=7679aeb444ed3bc4de0f473c16c47eab7d2f9d33
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.4-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.4-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.4-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.4-testing.git
++ : daily-cron.xen-4.4-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.4-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.4-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.4-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.4-testing
+ xenversion=xen-4.4
+ xenversion=4.4
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 7679aeb444ed3bc4de0f473c16c47eab7d2f9d33:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   d279f6e..7679aeb  7679aeb444ed3bc4de0f473c16c47eab7d2f9d33 -> stable-4.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 22:36:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 22:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsfks-0006QQ-TX; Sun, 23 Nov 2014 22:35:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xsfkr-0006QL-5H
	for xen-devel@lists.xen.org; Sun, 23 Nov 2014 22:35:41 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	94/FB-22737-C3162745; Sun, 23 Nov 2014 22:35:40 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416782139!7495891!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4074 invoked from network); 23 Nov 2014 22:35:39 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2014 22:35:39 -0000
Received: by mail-wg0-f46.google.com with SMTP id x12so11058009wgg.5
	for <xen-devel@lists.xen.org>; Sun, 23 Nov 2014 14:35:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:content-type:content-transfer-encoding;
	bh=+sQpCgU+qt991lh/coGETM1ZWjjILSKkoSL9AqfQqAE=;
	b=OZeRpm+h2mMIojExFW3p0g63nkx90tnnPke3r+DySRWwTxOR9RN7n2qi0y1yTEIatc
	x78bOjqcro02u5kKSKWH8Y0847KOTvvLZ1X8cuyOPDQ0igwuGZ7QLsfeNAvuJAsb5x8P
	1ZAJdh9G8dOROJJh7H4S3+dTxdvlvf+lU+XRgTnfaEQAvI9lZKDjuPzjN82wtTGdoSbz
	YEprWLyMbbICYTBUK+XdCC4HcqM6LeRh86VlN7D+7R33F47FpTlXVed6DXONfmRdoRwx
	NuIQNCYXXtvP3abu2ljwAofFbVs+LBCyw3/kXplqAfRcYLFb9l24R0ou5k0ibz8olEq0
	I+Hw==
X-Gm-Message-State: ALoCoQlZFFEeVvJO0KqxbGqPmT/IDK6HGeGc1dLAi/azRPuTAJPunuhb8KiT8IYjMcvwoWduWJjU
X-Received: by 10.180.84.98 with SMTP id x2mr4543548wiy.14.1416782138900;
	Sun, 23 Nov 2014 14:35:38 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id 4sm15024749wjs.24.2014.11.23.14.35.37
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 23 Nov 2014 14:35:38 -0800 (PST)
Message-ID: <54726138.3090003@linaro.org>
Date: Sun, 23 Nov 2014 22:35:36 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: freebsd-xen@freebsd.org, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	gibbs@freebsd.org, freebsd-arm@freebsd.org, roger.pau@citrix.com
Cc: Denis Schneider <v1ne2go@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [RFC v2] Add support for Xen ARM guest on FreeBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello all,

At the beginning of the year, I have sent a first RFC to add support for 
FreeBSD on Xen ARM [1].

The first version was very primitive: hardcoded DTB, only single 
user-mode support,...

Since then, I have improved the support and rebased everything on 
master. Thanks for the FreeBSD ARM team which did a great job and remove 
all most of my issues (Userspace hanging, Device Tree Bindings).

Major changes in this new version:
  	* Add Device Tree support via Linux Boot ABI
	* Add zImage support
	* Netfront support
	* Blkfront fixes
	* DOM0 support (separate branch see below)

The former item is very hackish. I was wondering if there is another way 
to do it? Or maybe we should support FreeBSD Bootloader in ARM guest?

The patch series is divided in X parts:
	* #1 - #14: Clean up and bug fixes for Xen. They can be applied without 
the rest of the series
         * #15 - #19: Update Xen interface to 4.4 and fix compilation. 
It's required for ARM.
         * #20 - #26: Update Xen code to support ARM
         * #27 - #33: Rework the event channel code for supporting ARM. 
I will work with Royger to come with a common interface with x86
         * #34 - #36: Add support for ARM in Xen code
         * #37 - #46: ARM bug fixes and new features. Some of thoses 
patches (#37 - #40) could be applied without the rest of the series
         * #47 - #48: Add Xen ARM platform

I don't really know how works patch review on Freebsd. Therefore, I 
provided the series in git format and file format. All based on Royger's 
pvh dom0 work v8:
   git://xenbits.xen.org/people/julieng/freebsd.git branch xen-arm-v2
   http://xenbits.xen.org/people/julieng/xen-arm-v2.1/

As said above, there is a separate branch for DOM0, the patches are not 
part of this series. The support has been done and demoed for the 
Arndale (though I've been tested since a while), but there is lots of 
work to clean up (device tree stuff and hack in the code):
   git://xenbits.xen.org/people/julieng/freebsd.git branch dom0-arm-v0
   http://xenbits.xen.org/people/julieng/dom0-arm-v0

TODO:
	* Add SMP/PSCI support in FreeBSD. Could be useful other platform too
	* Only FreeBSD to load anywhere. Currently there is a 2M alignment 
which require a patch in Xen.
         * ELF support in Xen ARM? Not sure it's useful.

Any help, comments, questions are welcomed.

Sincerely yours,

[1] http://lists.freebsd.org/pipermail/freebsd-xen/2014-January/001974.html

============= Instruction to test FreeBSD on Xen on ARM ===========

FreeBSD miss some support to fully boot on Xen ARM. This patch applied 
to Xen ARM help FreeBSD to boot correctly for the time being:
	* https://patches.linaro.org/32742/

To compile and boot Xen on your board, you can refer to the wiki page:
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions

The instruction to compile FreeBSD for Xen on ARM:
$ truncate -s 512 xenvm.img
$ sudo mdconfig -f xenvm.img -u0
$ sudo newfs /dev/md0
$ sudo mount /dev/md0 /mnt

$ sudo make TARGET_ARCH=armv6 kernel-toolchain
$ sudo make TARGET_ARCH=armv6 KERNCONF=XENHVM buildkernel
$ sudo make TARGET_ARCH=armv6 buildworld
$ sudo make TARGET_ARCH=armv6 DESTDIR=/mnt installworld distribution

$ echo "/dev/xbd0       /       ufs     rw      1       1" > /mnt/etc/fstab
$ vi /mnt/etc/ttys (add the line 'xc0 "/usr/libexec/getty Pc" xterm on 
secure")

$ sudo umount /mnt
$ sudo mdconfig -d u0

Then you can copy the rootfs and the kernel to DOM 0 on your board.

To boot the a FreeBSD your will required the following configuration file
$ cat freebsd.xl
kernel="kernel"
memory=64
name="freebsd"
vcpus=1
autoballon="off"
disk=[ 'phy:/dev/loop0,xvda,w' ]
$ losetup /dev/loop0 xenvm.img
$ xl create freebsd.xl
$ xl console freebsd

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 23 22:36:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Nov 2014 22:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsfks-0006QQ-TX; Sun, 23 Nov 2014 22:35:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xsfkr-0006QL-5H
	for xen-devel@lists.xen.org; Sun, 23 Nov 2014 22:35:41 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	94/FB-22737-C3162745; Sun, 23 Nov 2014 22:35:40 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416782139!7495891!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4074 invoked from network); 23 Nov 2014 22:35:39 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2014 22:35:39 -0000
Received: by mail-wg0-f46.google.com with SMTP id x12so11058009wgg.5
	for <xen-devel@lists.xen.org>; Sun, 23 Nov 2014 14:35:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:content-type:content-transfer-encoding;
	bh=+sQpCgU+qt991lh/coGETM1ZWjjILSKkoSL9AqfQqAE=;
	b=OZeRpm+h2mMIojExFW3p0g63nkx90tnnPke3r+DySRWwTxOR9RN7n2qi0y1yTEIatc
	x78bOjqcro02u5kKSKWH8Y0847KOTvvLZ1X8cuyOPDQ0igwuGZ7QLsfeNAvuJAsb5x8P
	1ZAJdh9G8dOROJJh7H4S3+dTxdvlvf+lU+XRgTnfaEQAvI9lZKDjuPzjN82wtTGdoSbz
	YEprWLyMbbICYTBUK+XdCC4HcqM6LeRh86VlN7D+7R33F47FpTlXVed6DXONfmRdoRwx
	NuIQNCYXXtvP3abu2ljwAofFbVs+LBCyw3/kXplqAfRcYLFb9l24R0ou5k0ibz8olEq0
	I+Hw==
X-Gm-Message-State: ALoCoQlZFFEeVvJO0KqxbGqPmT/IDK6HGeGc1dLAi/azRPuTAJPunuhb8KiT8IYjMcvwoWduWJjU
X-Received: by 10.180.84.98 with SMTP id x2mr4543548wiy.14.1416782138900;
	Sun, 23 Nov 2014 14:35:38 -0800 (PST)
Received: from Juliens-MacBook-Pro.local
	(cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93])
	by mx.google.com with ESMTPSA id 4sm15024749wjs.24.2014.11.23.14.35.37
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 23 Nov 2014 14:35:38 -0800 (PST)
Message-ID: <54726138.3090003@linaro.org>
Date: Sun, 23 Nov 2014 22:35:36 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: freebsd-xen@freebsd.org, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	gibbs@freebsd.org, freebsd-arm@freebsd.org, roger.pau@citrix.com
Cc: Denis Schneider <v1ne2go@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [RFC v2] Add support for Xen ARM guest on FreeBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello all,

At the beginning of the year, I have sent a first RFC to add support for 
FreeBSD on Xen ARM [1].

The first version was very primitive: hardcoded DTB, only single 
user-mode support,...

Since then, I have improved the support and rebased everything on 
master. Thanks for the FreeBSD ARM team which did a great job and remove 
all most of my issues (Userspace hanging, Device Tree Bindings).

Major changes in this new version:
  	* Add Device Tree support via Linux Boot ABI
	* Add zImage support
	* Netfront support
	* Blkfront fixes
	* DOM0 support (separate branch see below)

The former item is very hackish. I was wondering if there is another way 
to do it? Or maybe we should support FreeBSD Bootloader in ARM guest?

The patch series is divided in X parts:
	* #1 - #14: Clean up and bug fixes for Xen. They can be applied without 
the rest of the series
         * #15 - #19: Update Xen interface to 4.4 and fix compilation. 
It's required for ARM.
         * #20 - #26: Update Xen code to support ARM
         * #27 - #33: Rework the event channel code for supporting ARM. 
I will work with Royger to come with a common interface with x86
         * #34 - #36: Add support for ARM in Xen code
         * #37 - #46: ARM bug fixes and new features. Some of thoses 
patches (#37 - #40) could be applied without the rest of the series
         * #47 - #48: Add Xen ARM platform

I don't really know how works patch review on Freebsd. Therefore, I 
provided the series in git format and file format. All based on Royger's 
pvh dom0 work v8:
   git://xenbits.xen.org/people/julieng/freebsd.git branch xen-arm-v2
   http://xenbits.xen.org/people/julieng/xen-arm-v2.1/

As said above, there is a separate branch for DOM0, the patches are not 
part of this series. The support has been done and demoed for the 
Arndale (though I've been tested since a while), but there is lots of 
work to clean up (device tree stuff and hack in the code):
   git://xenbits.xen.org/people/julieng/freebsd.git branch dom0-arm-v0
   http://xenbits.xen.org/people/julieng/dom0-arm-v0

TODO:
	* Add SMP/PSCI support in FreeBSD. Could be useful other platform too
	* Only FreeBSD to load anywhere. Currently there is a 2M alignment 
which require a patch in Xen.
         * ELF support in Xen ARM? Not sure it's useful.

Any help, comments, questions are welcomed.

Sincerely yours,

[1] http://lists.freebsd.org/pipermail/freebsd-xen/2014-January/001974.html

============= Instruction to test FreeBSD on Xen on ARM ===========

FreeBSD miss some support to fully boot on Xen ARM. This patch applied 
to Xen ARM help FreeBSD to boot correctly for the time being:
	* https://patches.linaro.org/32742/

To compile and boot Xen on your board, you can refer to the wiki page:
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions

The instruction to compile FreeBSD for Xen on ARM:
$ truncate -s 512 xenvm.img
$ sudo mdconfig -f xenvm.img -u0
$ sudo newfs /dev/md0
$ sudo mount /dev/md0 /mnt

$ sudo make TARGET_ARCH=armv6 kernel-toolchain
$ sudo make TARGET_ARCH=armv6 KERNCONF=XENHVM buildkernel
$ sudo make TARGET_ARCH=armv6 buildworld
$ sudo make TARGET_ARCH=armv6 DESTDIR=/mnt installworld distribution

$ echo "/dev/xbd0       /       ufs     rw      1       1" > /mnt/etc/fstab
$ vi /mnt/etc/ttys (add the line 'xc0 "/usr/libexec/getty Pc" xterm on 
secure")

$ sudo umount /mnt
$ sudo mdconfig -d u0

Then you can copy the rootfs and the kernel to DOM 0 on your board.

To boot the a FreeBSD your will required the following configuration file
$ cat freebsd.xl
kernel="kernel"
memory=64
name="freebsd"
vcpus=1
autoballon="off"
disk=[ 'phy:/dev/loop0,xvda,w' ]
$ losetup /dev/loop0 xenvm.img
$ xl create freebsd.xl
$ xl console freebsd

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 00:08:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 00:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XshBw-0007fB-Sq; Mon, 24 Nov 2014 00:07:44 +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 1XshBw-0007f3-1B
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 00:07:44 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	8D/D6-28865-FC672745; Mon, 24 Nov 2014 00:07:43 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416787662!12888878!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1061 invoked from network); 24 Nov 2014 00:07:42 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 00:07:42 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAO07WZn007324
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 00:07:37 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAO07RMx015332
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 00:07:27 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAO07RN7029178
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 00:07:27 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAO07RV7029174
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 00:07:27 GMT
Date: Mon, 24 Nov 2014 00:07:27 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
In-Reply-To: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
Message-ID: <alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.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: sAO07WZn007324
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 22 Nov 2014, M A Young wrote:

> While investigating a bug reported on Red Hat Bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
> I discovered the following
>
> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the bug 
> report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There are 
> actually two issues here
>
> * the segfault in libxl-save-helper --restore-domain (as reported in the bug 
> above) occurs if the guest memory is 1024M (on my 4G box) and is presumably 
> because the allocated memory eventually runs out

I have found a bit more out about this. The segfault at at line 1378 of 
tools/libxc/xc_domain_restore.c which is
                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
                         csum_page(buf));
and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the 
array. This occurs in the verification phase.

> * the segfault doesn't occur if the guest memory is 128M, but the migration 
> still fails. The first attached file contains the log from a run with xl -v 
> migrate --debug domid localhost (with mfn and duplicated lines stripped out 
> to make the size manageable).

The difference actually seems to be down to how active the VM is rather 
than the memory size (my small memory test system was doing very little, 
my larger system was a full OS install). In the non-segfault case the 
problem was the printf and printf_info commands in the create_domain() 
routine in tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass 
status messages back from the restoring dom0, these commands cause an 
unexpected message. If you move them onto stderr then the migration 
completes in the non-segfault case.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 00:08:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 00:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XshBw-0007fB-Sq; Mon, 24 Nov 2014 00:07:44 +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 1XshBw-0007f3-1B
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 00:07:44 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	8D/D6-28865-FC672745; Mon, 24 Nov 2014 00:07:43 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416787662!12888878!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1061 invoked from network); 24 Nov 2014 00:07:42 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 00:07:42 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAO07WZn007324
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 00:07:37 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAO07RMx015332
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 00:07:27 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAO07RN7029178
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 00:07:27 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAO07RV7029174
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 00:07:27 GMT
Date: Mon, 24 Nov 2014 00:07:27 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
In-Reply-To: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
Message-ID: <alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.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: sAO07WZn007324
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 22 Nov 2014, M A Young wrote:

> While investigating a bug reported on Red Hat Bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
> I discovered the following
>
> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the bug 
> report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There are 
> actually two issues here
>
> * the segfault in libxl-save-helper --restore-domain (as reported in the bug 
> above) occurs if the guest memory is 1024M (on my 4G box) and is presumably 
> because the allocated memory eventually runs out

I have found a bit more out about this. The segfault at at line 1378 of 
tools/libxc/xc_domain_restore.c which is
                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
                         csum_page(buf));
and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the 
array. This occurs in the verification phase.

> * the segfault doesn't occur if the guest memory is 128M, but the migration 
> still fails. The first attached file contains the log from a run with xl -v 
> migrate --debug domid localhost (with mfn and duplicated lines stripped out 
> to make the size manageable).

The difference actually seems to be down to how active the VM is rather 
than the memory size (my small memory test system was doing very little, 
my larger system was a full OS install). In the non-segfault case the 
problem was the printf and printf_info commands in the create_domain() 
routine in tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass 
status messages back from the restoring dom0, these commands cause an 
unexpected message. If you move them onto stderr then the migration 
completes in the non-segfault case.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 00:32:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 00:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XshZK-0007x5-1X; Mon, 24 Nov 2014 00:31:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XshZI-0007x0-Jl
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 00:31:52 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	88/F2-03145-77C72745; Mon, 24 Nov 2014 00:31:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416789109!14319779!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9573 invoked from network); 24 Nov 2014 00:31:51 -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;
	24 Nov 2014 00:31:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,445,1413244800"; d="scan'208";a="194928856"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 19:31:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XshYm-0000K3-Rr;
	Mon, 24 Nov 2014 00:31:20 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XshYm-0007sZ-IN;
	Mon, 24 Nov 2014 00:31:20 +0000
Date: Mon, 24 Nov 2014 00:31:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31795-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31795: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31795 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31795/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-qemut-rhel6hvm-amd  9 guest-start.2       fail REGR. vs. 31241
 test-amd64-i386-xl           11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-xl-qemut-debianhvm-amd64 13 guest-localmigrate/x10 fail REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 14 guest-stop   fail REGR. vs. 31241
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 31241
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 31241
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 guest-localmigrate fail REGR. vs. 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                8a84e01e147f44111988f9d8ccd2eaa30215a0f2
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
638 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)

Not pushing.

(No revision log; it would be 26386 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 Nov 24 00:32:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 00:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XshZK-0007x5-1X; Mon, 24 Nov 2014 00:31:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XshZI-0007x0-Jl
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 00:31:52 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	88/F2-03145-77C72745; Mon, 24 Nov 2014 00:31:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416789109!14319779!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9573 invoked from network); 24 Nov 2014 00:31:51 -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;
	24 Nov 2014 00:31:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,445,1413244800"; d="scan'208";a="194928856"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 19:31:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XshYm-0000K3-Rr;
	Mon, 24 Nov 2014 00:31:20 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XshYm-0007sZ-IN;
	Mon, 24 Nov 2014 00:31:20 +0000
Date: Mon, 24 Nov 2014 00:31:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31795-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31795: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31795 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31795/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-qemut-rhel6hvm-amd  9 guest-start.2       fail REGR. vs. 31241
 test-amd64-i386-xl           11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-xl-qemut-debianhvm-amd64 13 guest-localmigrate/x10 fail REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 14 guest-stop   fail REGR. vs. 31241
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 31241
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 31241
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 guest-localmigrate fail REGR. vs. 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 linux                8a84e01e147f44111988f9d8ccd2eaa30215a0f2
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
638 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)

Not pushing.

(No revision log; it would be 26386 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 Nov 24 00:40:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 00: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 1Xshhf-00088x-6j; Mon, 24 Nov 2014 00:40:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xshhe-00088s-AE
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 00:40:30 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	3D/8F-18267-D7E72745; Mon, 24 Nov 2014 00:40:29 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416789628!10845787!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22250 invoked from network); 24 Nov 2014 00:40:29 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-31.messagelabs.com with SMTP;
	24 Nov 2014 00:40:29 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 23 Nov 2014 16:40:27 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,445,1413270000"; d="scan'208";a="642277698"
Received: from unknown (HELO [10.238.130.109]) ([10.238.130.109])
	by orsmga002.jf.intel.com with ESMTP; 23 Nov 2014 16:40:25 -0800
Message-ID: <54727E79.4040904@intel.com>
Date: Mon, 24 Nov 2014 08:40:25 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1407836957-29098-1-git-send-email-tiejun.chen@intel.com>
	<20141123101047.GA3109@redhat.com>
In-Reply-To: <20141123101047.GA3109@redhat.com>
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v5][PATCH 0/4] xen: introduce new machine for IGD
	passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/23 18:10, Michael S. Tsirkin wrote:
> On Tue, Aug 12, 2014 at 05:49:13PM +0800, Tiejun Chen wrote:
>> v5:
>>
>> * Simplify to make sure its really inherited from the standard one in patch #3
>> * Then drop the original patch #3
>
> I carried
> 	i440fx: make types configurable at run-time
> 	pc_init1: pass parameters just with types
> 	xen:hw:pci-host:piix: create host bridge to passthrough
> 	qom-test: blacklist xenigd
> 	xen:hw:i386:pc_piix: introduce new machine for IGD passthrough
>
> on my branch for a while now, but I'm not sure it's all still needed.

They may not be necessary since you and Paolo already are fine to live 
without that separate machine specific to IGD passthrough.

> If yes simply include these patches next time you repost the
> patchset.

Anyway, I will comment this point once I can issue next revision.

Thanks for your reminder.

Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 00:40:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 00: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 1Xshhf-00088x-6j; Mon, 24 Nov 2014 00:40:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1Xshhe-00088s-AE
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 00:40:30 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	3D/8F-18267-D7E72745; Mon, 24 Nov 2014 00:40:29 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416789628!10845787!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22250 invoked from network); 24 Nov 2014 00:40:29 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-31.messagelabs.com with SMTP;
	24 Nov 2014 00:40:29 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 23 Nov 2014 16:40:27 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,445,1413270000"; d="scan'208";a="642277698"
Received: from unknown (HELO [10.238.130.109]) ([10.238.130.109])
	by orsmga002.jf.intel.com with ESMTP; 23 Nov 2014 16:40:25 -0800
Message-ID: <54727E79.4040904@intel.com>
Date: Mon, 24 Nov 2014 08:40:25 +0800
From: "Chen, Tiejun" <tiejun.chen@intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1407836957-29098-1-git-send-email-tiejun.chen@intel.com>
	<20141123101047.GA3109@redhat.com>
In-Reply-To: <20141123101047.GA3109@redhat.com>
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [v5][PATCH 0/4] xen: introduce new machine for IGD
	passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2014/11/23 18:10, Michael S. Tsirkin wrote:
> On Tue, Aug 12, 2014 at 05:49:13PM +0800, Tiejun Chen wrote:
>> v5:
>>
>> * Simplify to make sure its really inherited from the standard one in patch #3
>> * Then drop the original patch #3
>
> I carried
> 	i440fx: make types configurable at run-time
> 	pc_init1: pass parameters just with types
> 	xen:hw:pci-host:piix: create host bridge to passthrough
> 	qom-test: blacklist xenigd
> 	xen:hw:i386:pc_piix: introduce new machine for IGD passthrough
>
> on my branch for a while now, but I'm not sure it's all still needed.

They may not be necessary since you and Paolo already are fine to live 
without that separate machine specific to IGD passthrough.

> If yes simply include these patches next time you repost the
> patchset.

Anyway, I will comment this point once I can issue next revision.

Thanks for your reminder.

Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 01:57:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 01:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsits-0004Tb-G7; Mon, 24 Nov 2014 01:57:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1Xsitr-0004TW-1J
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 01:57:11 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	06/80-08051-67092745; Mon, 24 Nov 2014 01:57:10 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416794227!14311821!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18905 invoked from network); 24 Nov 2014 01:57:09 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-13.tower-27.messagelabs.com with SMTP;
	24 Nov 2014 01:57:09 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43862083"
Received: from localhost (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 24 Nov 2014 09:53:13 +0800
Received: from G08CNEXCHPEKD01.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAO1uB14019511
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 09:56:11 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 24 Nov 2014 09:56:30 +0800
Message-ID: <547290D7.2020506@cn.fujitsu.com>
Date: Mon, 24 Nov 2014 09:58:47 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen devel <xen-devel@lists.xen.org>
X-Originating-IP: [10.167.226.91]
Subject: [Xen-devel] virtio on Xen cannot work
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When I try to use virtio on xen(HVM guest), qemu crashed. Here is the backtrace:
(gdb) bt
#0  0x00007f49581f0b55 in raise () from /lib64/libc.so.6
#1  0x00007f49581f2131 in abort () from /lib64/libc.so.6
#2  0x00007f495af2af32 in xen_ram_addr_from_mapcache (ptr=0x7f4951858ac8) at /root/work/xen/tools/qemu-xen-dir/xen-mapcache.c:316
#3  0x00007f495ae30fb3 in qemu_ram_addr_from_host (ptr=0x7f4951858ac8, ram_addr=0x7fff564dc9b0) at /root/work/xen/tools/qemu-xen-dir/exec.c:1508
#4  0x00007f495ae33424 in address_space_unmap (as=0x7f495b7c3520, buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2315
#5  0x00007f495ae335b3 in cpu_physical_memory_unmap (buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2353
#6  0x00007f495ae9058d in virtqueue_fill (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1, idx=0) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:258
#7  0x00007f495ae90a0d in virtqueue_push (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:286
#8  0x00007f495ae82cf3 in virtio_net_handle_ctrl (vdev=0x7f495b92a5d0, vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/net/virtio-net.c:806
#9  0x00007f495ae925e5 in virtio_queue_notify_vq (vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:729
#10 0x00007f495ae926c3 in virtio_queue_notify (vdev=0x7f495b92a5d0, n=2) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:735
#11 0x00007f495ad743c2 in virtio_ioport_write (opaque=0x7f495b929cd0, addr=16, val=2) at hw/virtio/virtio-pci.c:301
#12 0x00007f495ad74923 in virtio_pci_config_write (opaque=0x7f495b929cd0, addr=16, val=2, size=2) at hw/virtio/virtio-pci.c:433
#13 0x00007f495ae9f071 in memory_region_write_accessor (mr=0x7f495b92a468, addr=16, value=0x7fff564e8d08, size=2, shift=0, mask=65535) at /root/work/xen/tools/qemu-xen-dir/memory.c:441
#14 0x00007f495ae9f1ad in access_with_adjusted_size (addr=16, value=0x7fff564e8d08, size=2, access_size_min=1, access_size_max=4, access=0x7f495ae9efe8 <memory_region_write_accessor>, mr=0x7f495b92a468)
    at /root/work/xen/tools/qemu-xen-dir/memory.c:478
#15 0x00007f495aea200e in memory_region_dispatch_write (mr=0x7f495b92a468, addr=16, data=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:985
#16 0x00007f495aea5824 in io_mem_write (mr=0x7f495b92a468, addr=16, val=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:1744
#17 0x00007f495ae328d3 in address_space_rw (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2, is_write=true) at /root/work/xen/tools/qemu-xen-dir/exec.c:2029
#18 0x00007f495ae32c85 in address_space_write (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2) at /root/work/xen/tools/qemu-xen-dir/exec.c:2091
#19 0x00007f495ae9c130 in cpu_outw (addr=49200, val=2) at /root/work/xen/tools/qemu-xen-dir/ioport.c:77
#20 0x00007f495af289d0 in do_outp (addr=49200, size=2, val=2) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:668
#21 0x00007f495af28b94 in cpu_ioreq_pio (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:729
#22 0x00007f495af28ee5 in handle_ioreq (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:781
#23 0x00007f495af29237 in cpu_handle_ioreq (opaque=0x7f495b884ad0) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:856
#24 0x00007f495ad7d2c2 in qemu_iohandler_poll (pollfds=0x7f495b823820, ret=1) at iohandler.c:143
#25 0x00007f495ad7e2fd in main_loop_wait (nonblocking=0) at main-loop.c:485
#26 0x00007f495ae1386f in main_loop () at vl.c:2056
#27 0x00007f495ae1af17 in main (argc=35, argv=0x7fff564e94c8, envp=0x7fff564e95e8) at vl.c:4535
(gdb) q

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 01:57:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 01:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsits-0004Tb-G7; Mon, 24 Nov 2014 01:57:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1Xsitr-0004TW-1J
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 01:57:11 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	06/80-08051-67092745; Mon, 24 Nov 2014 01:57:10 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416794227!14311821!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18905 invoked from network); 24 Nov 2014 01:57:09 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-13.tower-27.messagelabs.com with SMTP;
	24 Nov 2014 01:57:09 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43862083"
Received: from localhost (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 24 Nov 2014 09:53:13 +0800
Received: from G08CNEXCHPEKD01.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAO1uB14019511
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 09:56:11 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 24 Nov 2014 09:56:30 +0800
Message-ID: <547290D7.2020506@cn.fujitsu.com>
Date: Mon, 24 Nov 2014 09:58:47 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: xen devel <xen-devel@lists.xen.org>
X-Originating-IP: [10.167.226.91]
Subject: [Xen-devel] virtio on Xen cannot work
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When I try to use virtio on xen(HVM guest), qemu crashed. Here is the backtrace:
(gdb) bt
#0  0x00007f49581f0b55 in raise () from /lib64/libc.so.6
#1  0x00007f49581f2131 in abort () from /lib64/libc.so.6
#2  0x00007f495af2af32 in xen_ram_addr_from_mapcache (ptr=0x7f4951858ac8) at /root/work/xen/tools/qemu-xen-dir/xen-mapcache.c:316
#3  0x00007f495ae30fb3 in qemu_ram_addr_from_host (ptr=0x7f4951858ac8, ram_addr=0x7fff564dc9b0) at /root/work/xen/tools/qemu-xen-dir/exec.c:1508
#4  0x00007f495ae33424 in address_space_unmap (as=0x7f495b7c3520, buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2315
#5  0x00007f495ae335b3 in cpu_physical_memory_unmap (buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2353
#6  0x00007f495ae9058d in virtqueue_fill (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1, idx=0) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:258
#7  0x00007f495ae90a0d in virtqueue_push (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:286
#8  0x00007f495ae82cf3 in virtio_net_handle_ctrl (vdev=0x7f495b92a5d0, vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/net/virtio-net.c:806
#9  0x00007f495ae925e5 in virtio_queue_notify_vq (vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:729
#10 0x00007f495ae926c3 in virtio_queue_notify (vdev=0x7f495b92a5d0, n=2) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:735
#11 0x00007f495ad743c2 in virtio_ioport_write (opaque=0x7f495b929cd0, addr=16, val=2) at hw/virtio/virtio-pci.c:301
#12 0x00007f495ad74923 in virtio_pci_config_write (opaque=0x7f495b929cd0, addr=16, val=2, size=2) at hw/virtio/virtio-pci.c:433
#13 0x00007f495ae9f071 in memory_region_write_accessor (mr=0x7f495b92a468, addr=16, value=0x7fff564e8d08, size=2, shift=0, mask=65535) at /root/work/xen/tools/qemu-xen-dir/memory.c:441
#14 0x00007f495ae9f1ad in access_with_adjusted_size (addr=16, value=0x7fff564e8d08, size=2, access_size_min=1, access_size_max=4, access=0x7f495ae9efe8 <memory_region_write_accessor>, mr=0x7f495b92a468)
    at /root/work/xen/tools/qemu-xen-dir/memory.c:478
#15 0x00007f495aea200e in memory_region_dispatch_write (mr=0x7f495b92a468, addr=16, data=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:985
#16 0x00007f495aea5824 in io_mem_write (mr=0x7f495b92a468, addr=16, val=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:1744
#17 0x00007f495ae328d3 in address_space_rw (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2, is_write=true) at /root/work/xen/tools/qemu-xen-dir/exec.c:2029
#18 0x00007f495ae32c85 in address_space_write (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2) at /root/work/xen/tools/qemu-xen-dir/exec.c:2091
#19 0x00007f495ae9c130 in cpu_outw (addr=49200, val=2) at /root/work/xen/tools/qemu-xen-dir/ioport.c:77
#20 0x00007f495af289d0 in do_outp (addr=49200, size=2, val=2) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:668
#21 0x00007f495af28b94 in cpu_ioreq_pio (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:729
#22 0x00007f495af28ee5 in handle_ioreq (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:781
#23 0x00007f495af29237 in cpu_handle_ioreq (opaque=0x7f495b884ad0) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:856
#24 0x00007f495ad7d2c2 in qemu_iohandler_poll (pollfds=0x7f495b823820, ret=1) at iohandler.c:143
#25 0x00007f495ad7e2fd in main_loop_wait (nonblocking=0) at main-loop.c:485
#26 0x00007f495ae1386f in main_loop () at vl.c:2056
#27 0x00007f495ae1af17 in main (argc=35, argv=0x7fff564e94c8, envp=0x7fff564e95e8) at vl.c:4535
(gdb) q

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 04:07:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 04:07:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xskvq-0006S6-SB; Mon, 24 Nov 2014 04:07: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@citrix.com>) id 1Xskvo-0006S1-W3
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 04:07:21 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	8B/97-22737-8FEA2745; Mon, 24 Nov 2014 04:07:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416802037!12941484!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27578 invoked from network); 24 Nov 2014 04:07:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 04:07:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,446,1413244800"; d="scan'208";a="195918834"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 23:07:15 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xskvj-0001MP-Go;
	Mon, 24 Nov 2014 04:07:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xskvj-0002tu-Ai;
	Mon, 24 Nov 2014 04:07:15 +0000
Date: Mon, 24 Nov 2014 04:07:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31764-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31764: 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 31764 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31764/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31659

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
baseline version:
 xen                  0540b854f6733759593e829bc3f13c9b45974e32

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Clark Laughlin <clark.laughlin@linaro.org>
  Euan Harris <euan.harris@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <Ian.Jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
+ branch=xen-unstable
+ revision=6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   0540b85..6913fa3  6913fa31fa898f45ecc3b00e2397b8ebc75c8df4 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 04:07:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 04:07:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xskvq-0006S6-SB; Mon, 24 Nov 2014 04:07: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@citrix.com>) id 1Xskvo-0006S1-W3
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 04:07:21 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	8B/97-22737-8FEA2745; Mon, 24 Nov 2014 04:07:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416802037!12941484!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27578 invoked from network); 24 Nov 2014 04:07:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 04:07:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,446,1413244800"; d="scan'208";a="195918834"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 23:07:15 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xskvj-0001MP-Go;
	Mon, 24 Nov 2014 04:07:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xskvj-0002tu-Ai;
	Mon, 24 Nov 2014 04:07:15 +0000
Date: Mon, 24 Nov 2014 04:07:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31764-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31764: 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 31764 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31764/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31659

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
baseline version:
 xen                  0540b854f6733759593e829bc3f13c9b45974e32

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Clark Laughlin <clark.laughlin@linaro.org>
  Euan Harris <euan.harris@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <Ian.Jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
+ branch=xen-unstable
+ revision=6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   0540b85..6913fa3  6913fa31fa898f45ecc3b00e2397b8ebc75c8df4 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 04:54:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 04: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 1Xslfb-0007Dz-Ar; Mon, 24 Nov 2014 04:54:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XslfZ-0007Du-LF
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 04:54:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1E/C4-25276-D0AB2745; Mon, 24 Nov 2014 04:54:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416804872!12025035!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19475 invoked from network); 24 Nov 2014 04:54:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 04:54:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,446,1413244800"; d="scan'208";a="195034210"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 23:52:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xsldw-0001a6-5B;
	Mon, 24 Nov 2014 04:52:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xsldv-0001LI-Vb;
	Mon, 24 Nov 2014 04:52:55 +0000
Date: Mon, 24 Nov 2014 04:52:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31771-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31771: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31771 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31771/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-xl-credit2   12 guest-localmigrate      fail baseline untested
 test-amd64-amd64-xl-sedf-pin  9 guest-start             fail baseline untested
 test-amd64-i386-xl           11 guest-saverestore       fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu 11 guest-saverestore       fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-i386-xl-qemut-winxpsp3  3 host-install(3)  broken baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                ed6778aef7428a6c5fc1acf08a3e9126f5eef770
baseline version:
 linux                fc14f9c1272f62c3e8d01300f52467c0d9af50f9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 04:54:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 04: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 1Xslfb-0007Dz-Ar; Mon, 24 Nov 2014 04:54:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XslfZ-0007Du-LF
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 04:54:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1E/C4-25276-D0AB2745; Mon, 24 Nov 2014 04:54:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416804872!12025035!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19475 invoked from network); 24 Nov 2014 04:54:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 04:54:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,446,1413244800"; d="scan'208";a="195034210"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 23 Nov 2014 23:52:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xsldw-0001a6-5B;
	Mon, 24 Nov 2014 04:52:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xsldv-0001LI-Vb;
	Mon, 24 Nov 2014 04:52:55 +0000
Date: Mon, 24 Nov 2014 04:52:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31771-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31771: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31771 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31771/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-xl-credit2   12 guest-localmigrate      fail baseline untested
 test-amd64-amd64-xl-sedf-pin  9 guest-start             fail baseline untested
 test-amd64-i386-xl           11 guest-saverestore       fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu 11 guest-saverestore       fail baseline untested
 test-armhf-armhf-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-i386-xl-qemut-winxpsp3  3 host-install(3)  broken baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                ed6778aef7428a6c5fc1acf08a3e9126f5eef770
baseline version:
 linux                fc14f9c1272f62c3e8d01300f52467c0d9af50f9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 05:42:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 05: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 1XsmPm-0007pQ-If; Mon, 24 Nov 2014 05:42: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@citrix.com>) id 1XsmPl-0007pL-73
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 05:42:21 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	53/B3-22819-C35C2745; Mon, 24 Nov 2014 05:42:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416807737!12951746!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3789 invoked from network); 24 Nov 2014 05:42:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 05:42:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="195048770"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 00:40:35 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsmO3-0001oI-Dd;
	Mon, 24 Nov 2014 05:40:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsmO3-0000KX-7l;
	Mon, 24 Nov 2014 05:40:35 +0000
Date: Mon, 24 Nov 2014 05:40:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31801-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31801: 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 31801 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31801/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt      4 xen-install                 fail pass in 31768
 test-amd64-amd64-libvirt      5 xen-boot           fail in 31768 pass in 31801
 test-amd64-amd64-xl-sedf 15 guest-localmigrate/x10 fail in 31768 pass in 31801
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 31768 pass in 31801

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31686

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-armhf-armhf-libvirt      9 guest-start           fail in 31768 never pass

version targeted for testing:
 qemuu                0e88f478508b566152c6681f4889ed9830a2c0a5
baseline version:
 qemuu                af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Amit Shah <amit.shah@redhat.com>
  ChenLiang <chenliang88@huawei.com>
  Fabien Chouteau <chouteau@adacore.com>
  Fam Zheng <famz@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Leif Lindholm <leif.lindholm@linaro.org>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefan Hajnoczi <stefanha@redhat.com>
  Tom Musta <tommusta@gmail.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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-mainline
+ revision=0e88f478508b566152c6681f4889ed9830a2c0a5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-mainline 0e88f478508b566152c6681f4889ed9830a2c0a5
+ branch=qemu-mainline
+ revision=0e88f478508b566152c6681f4889ed9830a2c0a5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ qemuubranch=qemu-mainline
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' xqemu-mainline = x ']'
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://git.qemu.org/qemu.git
++ : daily-cron.qemu-mainline
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-mainline
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-mainline
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-mainline
+ git push osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git 0e88f478508b566152c6681f4889ed9830a2c0a5:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   af3ff19..0e88f47  0e88f478508b566152c6681f4889ed9830a2c0a5 -> mainline/xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 05:42:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 05: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 1XsmPm-0007pQ-If; Mon, 24 Nov 2014 05:42: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@citrix.com>) id 1XsmPl-0007pL-73
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 05:42:21 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	53/B3-22819-C35C2745; Mon, 24 Nov 2014 05:42:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416807737!12951746!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3789 invoked from network); 24 Nov 2014 05:42:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 05:42:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="195048770"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 00:40:35 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsmO3-0001oI-Dd;
	Mon, 24 Nov 2014 05:40:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsmO3-0000KX-7l;
	Mon, 24 Nov 2014 05:40:35 +0000
Date: Mon, 24 Nov 2014 05:40:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31801-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31801: 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 31801 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31801/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt      4 xen-install                 fail pass in 31768
 test-amd64-amd64-libvirt      5 xen-boot           fail in 31768 pass in 31801
 test-amd64-amd64-xl-sedf 15 guest-localmigrate/x10 fail in 31768 pass in 31801
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 31768 pass in 31801

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31686

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-armhf-armhf-libvirt      9 guest-start           fail in 31768 never pass

version targeted for testing:
 qemuu                0e88f478508b566152c6681f4889ed9830a2c0a5
baseline version:
 qemuu                af3ff19b48f0bbf3a8bd35c47460358e8c6ae5e5

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Amit Shah <amit.shah@redhat.com>
  ChenLiang <chenliang88@huawei.com>
  Fabien Chouteau <chouteau@adacore.com>
  Fam Zheng <famz@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Leif Lindholm <leif.lindholm@linaro.org>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefan Hajnoczi <stefanha@redhat.com>
  Tom Musta <tommusta@gmail.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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-mainline
+ revision=0e88f478508b566152c6681f4889ed9830a2c0a5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-mainline 0e88f478508b566152c6681f4889ed9830a2c0a5
+ branch=qemu-mainline
+ revision=0e88f478508b566152c6681f4889ed9830a2c0a5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ qemuubranch=qemu-mainline
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' xqemu-mainline = x ']'
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://git.qemu.org/qemu.git
++ : daily-cron.qemu-mainline
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-mainline
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-mainline
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-mainline
+ git push osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git 0e88f478508b566152c6681f4889ed9830a2c0a5:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   af3ff19..0e88f47  0e88f478508b566152c6681f4889ed9830a2c0a5 -> mainline/xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 07:44:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 07: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 1XsoJS-0000L2-2u; Mon, 24 Nov 2014 07:43:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XsoJQ-0000Kx-CI
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 07:43:56 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	4B/CC-29352-BB1E2745; Mon, 24 Nov 2014 07:43:55 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416815034!12987335!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19685 invoked from network); 24 Nov 2014 07:43:54 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-7.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 07:43:54 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 23 Nov 2014 23:36:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="420679607"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by FMSMGA003.fm.intel.com with ESMTP; 23 Nov 2014 23:34:11 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 24 Nov 2014 15:43:50 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Mon, 24 Nov 2014 15:43:49 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/nWuLyPytmG9lUW9P9kyZB1iX5xvcsYQ
Date: Mon, 24 Nov 2014 07:43:49 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A68B84@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<546354D7.2040703@oracle.com>
In-Reply-To: <546354D7.2040703@oracle.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: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
> Sent: Wednesday, November 12, 2014 8:39 PM
> To: Hu, Robert; xen-devel@lists.xen.org
> Cc: JBeulich@suse.com
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> 
> On 11/12/2014 01:58 AM, Hu, Robert wrote:
> > 2. Failed to hotplug a VT-d device with XEN4.5-RC1
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> 
> 
> This should be addressed by these two:
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00875.html
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00874.html
Tried, these patches works. When will they get in?
> 
> -boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 07:44:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 07: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 1XsoJS-0000L2-2u; Mon, 24 Nov 2014 07:43:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1XsoJQ-0000Kx-CI
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 07:43:56 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	4B/CC-29352-BB1E2745; Mon, 24 Nov 2014 07:43:55 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416815034!12987335!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19685 invoked from network); 24 Nov 2014 07:43:54 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-7.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 07:43:54 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 23 Nov 2014 23:36:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="420679607"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by FMSMGA003.fm.intel.com with ESMTP; 23 Nov 2014 23:34:11 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 24 Nov 2014 15:43:50 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Mon, 24 Nov 2014 15:43:49 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/nWuLyPytmG9lUW9P9kyZB1iX5xvcsYQ
Date: Mon, 24 Nov 2014 07:43:49 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A68B84@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<546354D7.2040703@oracle.com>
In-Reply-To: <546354D7.2040703@oracle.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: "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
> Sent: Wednesday, November 12, 2014 8:39 PM
> To: Hu, Robert; xen-devel@lists.xen.org
> Cc: JBeulich@suse.com
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> 
> On 11/12/2014 01:58 AM, Hu, Robert wrote:
> > 2. Failed to hotplug a VT-d device with XEN4.5-RC1
> >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> 
> 
> This should be addressed by these two:
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00875.html
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00874.html
Tried, these patches works. When will they get in?
> 
> -boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 07:54:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 07: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 1XsoTJ-0000WE-Bc; Mon, 24 Nov 2014 07:54:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XsoTI-0000W9-PL
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 07:54:08 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	FE/AF-02699-024E2745; Mon, 24 Nov 2014 07:54:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416815647!13785999!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1200 invoked from network); 24 Nov 2014 07:54:07 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 07:54:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 07:54:07 +0000
Message-Id: <5472F22B020000780004A28C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 07:54:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <545B9C5F020000780004561B@mail.emea.novell.com>
	<20141121220338.GA17981@laptop.dumpdata.com>
In-Reply-To: <20141121220338.GA17981@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, boris.ostrovsky@oracle.com,
	david.vrabel@citrix.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-pciback: drop SR-IOV VFs when PF driver
 unloads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 23:03, <konrad.wilk@oracle.com> wrote:
> I rewrote it a bit to be more in the style of pciback:
>[...]
> [v2: Removed the switch statement, moved it about]

What you don't mention here is that you also removed the outer
loop, yet that breaks functionality afaict: There can (and I suppose
normally will) be multiple VFs needing device_release_driver() called
when a single PF goes away.

Also I'm not really happy for a patch with my S-o-b underneath to
introduce goto-s without real need.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 07:54:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 07: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 1XsoTJ-0000WE-Bc; Mon, 24 Nov 2014 07:54:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XsoTI-0000W9-PL
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 07:54:08 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	FE/AF-02699-024E2745; Mon, 24 Nov 2014 07:54:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416815647!13785999!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1200 invoked from network); 24 Nov 2014 07:54:07 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 07:54:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 07:54:07 +0000
Message-Id: <5472F22B020000780004A28C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 07:54:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <545B9C5F020000780004561B@mail.emea.novell.com>
	<20141121220338.GA17981@laptop.dumpdata.com>
In-Reply-To: <20141121220338.GA17981@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, boris.ostrovsky@oracle.com,
	david.vrabel@citrix.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-pciback: drop SR-IOV VFs when PF driver
 unloads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 23:03, <konrad.wilk@oracle.com> wrote:
> I rewrote it a bit to be more in the style of pciback:
>[...]
> [v2: Removed the switch statement, moved it about]

What you don't mention here is that you also removed the outer
loop, yet that breaks functionality afaict: There can (and I suppose
normally will) be multiple VFs needing device_release_driver() called
when a single PF goes away.

Also I'm not really happy for a patch with my S-o-b underneath to
introduce goto-s without real need.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:13:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:13:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsolx-0001Gl-R9; Mon, 24 Nov 2014 08:13:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1Xsolw-0001Gg-Ir
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:13:24 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	E3/22-25547-3A8E2745; Mon, 24 Nov 2014 08:13:23 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416816802!13351206!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2872 invoked from network); 24 Nov 2014 08:13:23 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-31.messagelabs.com with SMTP;
	24 Nov 2014 08:13:23 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 24 Nov 2014 00:13:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="420689049"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by FMSMGA003.fm.intel.com with ESMTP; 24 Nov 2014 00:03:37 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 24 Nov 2014 16:13:17 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.110]) with mapi id
	14.03.0195.001; Mon, 24 Nov 2014 16:13:15 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
	PCI device hotplug
Thread-Index: AQHQBDxZgKlo/w4W40WCwErmunMnaJxn7vSAgAACGYCAATXKAIAGTPiA
Date: Mon, 24 Nov 2014 08:13:16 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A68BC9@SHSMSX103.ccr.corp.intel.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
	<20141119210154.GB20440@laptop.dumpdata.com>
	<20141119212123.GA27349@zion.uk.xensource.com>
	<20141119212853.GM20440@laptop.dumpdata.com>
	<1416499060.14429.33.camel@citrix.com>
In-Reply-To: <1416499060.14429.33.camel@citrix.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: Wei Liu <wei.liu2@citrix.com>, "Li, Liang Z" <liang.z.li@intel.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: Thursday, November 20, 2014 11:58 PM
> To: Konrad Rzeszutek Wilk
> Cc: Ian Jackson; Li, Liang Z; Wei Liu; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for PCI
> device hotplug
> 
> On Wed, 2014-11-19 at 16:28 -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 19, 2014 at 09:21:23PM +0000, Wei Liu wrote:
> > > On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Mon, Nov 17, 2014 at 12:10:34PM +0000, Wei Liu wrote:
> > > > > The existence check is to make sure a device is not added to a guest
> > > > > multiple times.
> > > > >
> > > > > PCI device backend path has different rules from vif, disk etc. For
> > > > > example:
> > > > > /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> > > > > /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> > > > > /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> > > > > /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> > > > >
> > > > > The devid for PCI devices is hardcoded 0. libxl__device_exists only
> > > > > checks up to /local/.../9/0 so it always returns true even the device is
> > > > > assignable.
> > > > >
> > > > > Remove invocation of libxl__device_exists. We're sure at this point that
> > > > > the PCI device is assignable (hence no xenstore entry or JSON entry).
> > > > > The check is done before hand. For HVM guest it's done by calling
> > > > > xc_test_assign_device and for PV guest it's done by calling
> > > > > pciback_dev_is_assigned.
> > > > >
> > > > > Reported-by: Li, Liang Z <liang.z.li@intel.com>
> > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > > > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > > > > ---
> > > > > This patch fixes a regression in 4.5.
> > > >
> > > > Ouch! That needs then to be fixed.
> > > >
> > > > Is the version you would want to commit? I did test it - and it
> > >
> > > Yes.
> >
> > Then Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Applied.
Hi, I'm new here. Shall I ask where does this patch apply to? shall I expect to see this issue fixed in Xen 4.5-RC3?
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 24 08:13:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:13:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsolx-0001Gl-R9; Mon, 24 Nov 2014 08:13:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@intel.com>) id 1Xsolw-0001Gg-Ir
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:13:24 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	E3/22-25547-3A8E2745; Mon, 24 Nov 2014 08:13:23 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416816802!13351206!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2872 invoked from network); 24 Nov 2014 08:13:23 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-31.messagelabs.com with SMTP;
	24 Nov 2014 08:13:23 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 24 Nov 2014 00:13:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="420689049"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by FMSMGA003.fm.intel.com with ESMTP; 24 Nov 2014 00:03:37 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 24 Nov 2014 16:13:17 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.110]) with mapi id
	14.03.0195.001; Mon, 24 Nov 2014 16:13:15 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
	PCI device hotplug
Thread-Index: AQHQBDxZgKlo/w4W40WCwErmunMnaJxn7vSAgAACGYCAATXKAIAGTPiA
Date: Mon, 24 Nov 2014 08:13:16 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A68BC9@SHSMSX103.ccr.corp.intel.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
	<20141119210154.GB20440@laptop.dumpdata.com>
	<20141119212123.GA27349@zion.uk.xensource.com>
	<20141119212853.GM20440@laptop.dumpdata.com>
	<1416499060.14429.33.camel@citrix.com>
In-Reply-To: <1416499060.14429.33.camel@citrix.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: Wei Liu <wei.liu2@citrix.com>, "Li, Liang Z" <liang.z.li@intel.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: Thursday, November 20, 2014 11:58 PM
> To: Konrad Rzeszutek Wilk
> Cc: Ian Jackson; Li, Liang Z; Wei Liu; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for PCI
> device hotplug
> 
> On Wed, 2014-11-19 at 16:28 -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 19, 2014 at 09:21:23PM +0000, Wei Liu wrote:
> > > On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Mon, Nov 17, 2014 at 12:10:34PM +0000, Wei Liu wrote:
> > > > > The existence check is to make sure a device is not added to a guest
> > > > > multiple times.
> > > > >
> > > > > PCI device backend path has different rules from vif, disk etc. For
> > > > > example:
> > > > > /local/domain/0/backend/pci/9/0/dev-1/0000:03:10.1
> > > > > /local/domain/0/backend/pci/9/0/key-1/0000:03:10.1
> > > > > /local/domain/0/backend/pci/9/0/dev-2/0000:03:10.2
> > > > > /local/domain/0/backend/pci/9/0/key-2/0000:03:10.2
> > > > >
> > > > > The devid for PCI devices is hardcoded 0. libxl__device_exists only
> > > > > checks up to /local/.../9/0 so it always returns true even the device is
> > > > > assignable.
> > > > >
> > > > > Remove invocation of libxl__device_exists. We're sure at this point that
> > > > > the PCI device is assignable (hence no xenstore entry or JSON entry).
> > > > > The check is done before hand. For HVM guest it's done by calling
> > > > > xc_test_assign_device and for PV guest it's done by calling
> > > > > pciback_dev_is_assigned.
> > > > >
> > > > > Reported-by: Li, Liang Z <liang.z.li@intel.com>
> > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > > > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > > > > ---
> > > > > This patch fixes a regression in 4.5.
> > > >
> > > > Ouch! That needs then to be fixed.
> > > >
> > > > Is the version you would want to commit? I did test it - and it
> > >
> > > Yes.
> >
> > Then Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Applied.
Hi, I'm new here. Shall I ask where does this patch apply to? shall I expect to see this issue fixed in Xen 4.5-RC3?
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 24 08:14:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xson4-0001LC-8w; Mon, 24 Nov 2014 08:14:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xson2-0001L2-Eu
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:14:32 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	BB/F0-24124-7E8E2745; Mon, 24 Nov 2014 08:14:31 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416816867!12972580!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24351 invoked from network); 24 Nov 2014 08:14:28 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 08:14:28 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 24 Nov 2014 00:14:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="420689590"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 24 Nov 2014 00:04:44 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun, 23 Nov 2014 23:10:50 -0500
Message-Id: <1416802250-9852-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [v2 0/4] QEMU:Xen stubdom vTPM for HVM virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

*INTRODUCTION*
The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to interact with a TPM in a virtual machine the same way they interact with a TPM on the physical system. Each virtual machine gets its own unique, emulated, software TPM. Each major component of vTPM is implemented as a stubdom, providing secure separation guaranteed by the hypervisor.

The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed from mini-os TPM backend driver.

*ARCHITECTURE*
The architecture of stubdom vTPM for HVM virtual machine:

            +--------------------+
            | Windows/Linux DomU | ...
            |        |  ^        |
            |        v  |        |
            |  Qemu tpm1.2 Tis   |
            |        |  ^        |
            |        v  |        |
            | XenStubdoms backend|
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |      XenDevOps     |
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |  mini-os/tpmback   |
            |        |  ^        |
            |        v  |        |
            |   vtpm-stubdom     | ...
            |        |  ^        |
            |        v  |        |
            |  mini-os/tpmfront  |
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |  mini-os/tpmback   |
            |        |  ^        |
            |        v  |        |
            |  vtpmmgr-stubdom   |
            |        |  ^        |
            |        v  |        |
            |  mini-os/tpm_tis   |
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |    Hardware TPM    |
            +--------------------+



 * Windows/Linux DomU:
    The HVM based guest that wants to use a vTPM. There may be
    more than one of these.

 * Qemu tpm1.2 Tis:
    Implementation of the tpm1.2 Tis interface for HVM virtual
    machines. It is Qemu emulation device.

 * vTPM xenstubdoms driver:
    Qemu vTPM driver. This driver provides vtpm initialization
    and sending data and commends to a para-virtualized vtpm
    stubdom.

 * XenDevOps:
    Register Xen stubdom vTPM frontend driver, and transfer any
    request/repond between TPM xenstubdoms driver and Xen vTPM
    stubdom. Facilitate communications between Xen vTPM stubdom
    and vTPM xenstubdoms driver.

 * mini-os/tpmback:
    Mini-os TPM backend driver. The Linux frontend driver connects
    to this backend driver to facilitate communications between the
    Linux DomU and its vTPM. This driver is also used by vtpmmgr
    stubdom to communicate with vtpm-stubdom.

 * vtpm-stubdom:
    A mini-os stub domain that implements a vTPM. There is a
    one to one mapping between running vtpm-stubdom instances and
    logical vtpms on the system. The vTPM Platform Configuration
    Registers (PCRs) are all initialized to zero.

 * mini-os/tpmfront:
    Mini-os TPM frontend driver. The vTPM mini-os domain vtpm
    stubdom uses this driver to communicate with vtpmmgr-stubdom.
    This driver could also be used separately to implement a mini-os
    domain that wishes to use a vTPM of its own.

 * vtpmmgr-stubdom:
    A mini-os domain that implements the vTPM manager. There is only
    one vTPM manager and it should be running during the entire lifetime
    of the machine. vtpmmgr domain securely stores encryption keys for
    each of the vtpms and accesses to the hardware TPM to get the root of
    trust for the entire system.

 * mini-os/tpm_tis:
    Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
    This driver used by vtpmmgr-stubdom to talk directly to the hardware
    TPM. Communication is facilitated by mapping hardware memory pages
    into vtpmmgr stubdom.

 * Hardware TPM: The physical TPM 1.2 that is soldered onto the motherboard.


Changes in v2:
    adding xen_fe_register() that handle any Xen PV frontend registration
    remove a private structure 'QEMUBH'
    change version number to 2.3 in qapi-schema.json
    move hw/xen/xen_stubdom_vtpm.c to hw/tpm/xen_stubdom_vtpm.c

Quan Xu (4):
  Qemu-Xen-vTPM: Support for Xen stubdom vTPM command line options
  Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend driver
  Qemu-Xen-vTPM: Qemu vTPM xenstubdoms driver.
  Qemu-Xen-vTPM: QEMU machine class is initialized before tpm_init()

 configure                    |  14 ++
 hmp.c                        |   7 +
 hw/tpm/Makefile.objs         |   2 +
 hw/tpm/tpm_xenstubdoms.c     | 238 ++++++++++++++++++++++++++++++++
 hw/tpm/xen_stubdom_vtpm.c    | 321 +++++++++++++++++++++++++++++++++++++++++++
 hw/xen/xen_backend.c         | 272 ++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  11 ++
 include/hw/xen/xen_common.h  |   6 +
 qapi-schema.json             |  20 ++-
 qemu-options.hx              |  13 +-
 tpm.c                        |   7 +-
 vl.c                         |  16 ++-
 xen-hvm.c                    |  13 ++
 13 files changed, 929 insertions(+), 11 deletions(-)
 create mode 100644 hw/tpm/tpm_xenstubdoms.c
 create mode 100644 hw/tpm/xen_stubdom_vtpm.c

-- 
1.8.3.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:14:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xson4-0001LC-8w; Mon, 24 Nov 2014 08:14:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xson2-0001L2-Eu
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:14:32 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	BB/F0-24124-7E8E2745; Mon, 24 Nov 2014 08:14:31 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416816867!12972580!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24351 invoked from network); 24 Nov 2014 08:14:28 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 08:14:28 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 24 Nov 2014 00:14:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="420689590"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 24 Nov 2014 00:04:44 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun, 23 Nov 2014 23:10:50 -0500
Message-Id: <1416802250-9852-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [v2 0/4] QEMU:Xen stubdom vTPM for HVM virtual machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

*INTRODUCTION*
The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to interact with a TPM in a virtual machine the same way they interact with a TPM on the physical system. Each virtual machine gets its own unique, emulated, software TPM. Each major component of vTPM is implemented as a stubdom, providing secure separation guaranteed by the hypervisor.

The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed from mini-os TPM backend driver.

*ARCHITECTURE*
The architecture of stubdom vTPM for HVM virtual machine:

            +--------------------+
            | Windows/Linux DomU | ...
            |        |  ^        |
            |        v  |        |
            |  Qemu tpm1.2 Tis   |
            |        |  ^        |
            |        v  |        |
            | XenStubdoms backend|
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |      XenDevOps     |
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |  mini-os/tpmback   |
            |        |  ^        |
            |        v  |        |
            |   vtpm-stubdom     | ...
            |        |  ^        |
            |        v  |        |
            |  mini-os/tpmfront  |
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |  mini-os/tpmback   |
            |        |  ^        |
            |        v  |        |
            |  vtpmmgr-stubdom   |
            |        |  ^        |
            |        v  |        |
            |  mini-os/tpm_tis   |
            +--------------------+
                     |  ^
                     v  |
            +--------------------+
            |    Hardware TPM    |
            +--------------------+



 * Windows/Linux DomU:
    The HVM based guest that wants to use a vTPM. There may be
    more than one of these.

 * Qemu tpm1.2 Tis:
    Implementation of the tpm1.2 Tis interface for HVM virtual
    machines. It is Qemu emulation device.

 * vTPM xenstubdoms driver:
    Qemu vTPM driver. This driver provides vtpm initialization
    and sending data and commends to a para-virtualized vtpm
    stubdom.

 * XenDevOps:
    Register Xen stubdom vTPM frontend driver, and transfer any
    request/repond between TPM xenstubdoms driver and Xen vTPM
    stubdom. Facilitate communications between Xen vTPM stubdom
    and vTPM xenstubdoms driver.

 * mini-os/tpmback:
    Mini-os TPM backend driver. The Linux frontend driver connects
    to this backend driver to facilitate communications between the
    Linux DomU and its vTPM. This driver is also used by vtpmmgr
    stubdom to communicate with vtpm-stubdom.

 * vtpm-stubdom:
    A mini-os stub domain that implements a vTPM. There is a
    one to one mapping between running vtpm-stubdom instances and
    logical vtpms on the system. The vTPM Platform Configuration
    Registers (PCRs) are all initialized to zero.

 * mini-os/tpmfront:
    Mini-os TPM frontend driver. The vTPM mini-os domain vtpm
    stubdom uses this driver to communicate with vtpmmgr-stubdom.
    This driver could also be used separately to implement a mini-os
    domain that wishes to use a vTPM of its own.

 * vtpmmgr-stubdom:
    A mini-os domain that implements the vTPM manager. There is only
    one vTPM manager and it should be running during the entire lifetime
    of the machine. vtpmmgr domain securely stores encryption keys for
    each of the vtpms and accesses to the hardware TPM to get the root of
    trust for the entire system.

 * mini-os/tpm_tis:
    Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
    This driver used by vtpmmgr-stubdom to talk directly to the hardware
    TPM. Communication is facilitated by mapping hardware memory pages
    into vtpmmgr stubdom.

 * Hardware TPM: The physical TPM 1.2 that is soldered onto the motherboard.


Changes in v2:
    adding xen_fe_register() that handle any Xen PV frontend registration
    remove a private structure 'QEMUBH'
    change version number to 2.3 in qapi-schema.json
    move hw/xen/xen_stubdom_vtpm.c to hw/tpm/xen_stubdom_vtpm.c

Quan Xu (4):
  Qemu-Xen-vTPM: Support for Xen stubdom vTPM command line options
  Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend driver
  Qemu-Xen-vTPM: Qemu vTPM xenstubdoms driver.
  Qemu-Xen-vTPM: QEMU machine class is initialized before tpm_init()

 configure                    |  14 ++
 hmp.c                        |   7 +
 hw/tpm/Makefile.objs         |   2 +
 hw/tpm/tpm_xenstubdoms.c     | 238 ++++++++++++++++++++++++++++++++
 hw/tpm/xen_stubdom_vtpm.c    | 321 +++++++++++++++++++++++++++++++++++++++++++
 hw/xen/xen_backend.c         | 272 ++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  11 ++
 include/hw/xen/xen_common.h  |   6 +
 qapi-schema.json             |  20 ++-
 qemu-options.hx              |  13 +-
 tpm.c                        |   7 +-
 vl.c                         |  16 ++-
 xen-hvm.c                    |  13 ++
 13 files changed, 929 insertions(+), 11 deletions(-)
 create mode 100644 hw/tpm/tpm_xenstubdoms.c
 create mode 100644 hw/tpm/xen_stubdom_vtpm.c

-- 
1.8.3.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08: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 1Xson8-0001MH-QB; Mon, 24 Nov 2014 08:14:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xson7-0001Lo-AV
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:14:37 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	B4/44-09284-CE8E2745; Mon, 24 Nov 2014 08:14:36 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416816872!13273068!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2252 invoked from network); 24 Nov 2014 08:14:33 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-31.messagelabs.com with SMTP;
	24 Nov 2014 08:14:33 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2014 00:14:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,447,1413270000"; d="scan'208";a="612968683"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 24 Nov 2014 00:14:31 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun, 23 Nov 2014 23:10:56 -0500
Message-Id: <1416802256-9928-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: stefano.stabellini@eu.citrix.com, Quan Xu <quan.xu@intel.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
	frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This drvier transfers any request/repond between TPM xenstubdoms
driver and Xen vTPM stubdom, and facilitates communications between
Xen vTPM stubdom domain and vTPM xenstubdoms driver

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/tpm/Makefile.objs         |   1 +
 hw/tpm/xen_stubdom_vtpm.c    | 321 +++++++++++++++++++++++++++++++++++++++++++
 hw/xen/xen_backend.c         | 272 ++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  11 ++
 include/hw/xen/xen_common.h  |   6 +
 xen-hvm.c                    |  13 ++
 6 files changed, 624 insertions(+)
 create mode 100644 hw/tpm/xen_stubdom_vtpm.c

diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 99f5983..87efb01 100644
--- a/hw/tpm/Makefile.objs
+++ b/hw/tpm/Makefile.objs
@@ -1,2 +1,3 @@
 common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
 common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
diff --git a/hw/tpm/xen_stubdom_vtpm.c b/hw/tpm/xen_stubdom_vtpm.c
new file mode 100644
index 0000000..4fd6053
--- /dev/null
+++ b/hw/tpm/xen_stubdom_vtpm.c
@@ -0,0 +1,321 @@
+/*
+ * Connect to Xen vTPM stubdom domain
+ *
+ *  Copyright (c) 2014 Intel Corporation
+ *  Authors:
+ *    Quan Xu <quan.xu@intel.com>
+ *
+ * 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 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, see <http://www.gnu.org/licenses/>
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdarg.h>
+#include <string.h>
+#include <unistd.h>
+#include <signal.h>
+#include <inttypes.h>
+#include <time.h>
+#include <fcntl.h>
+#include <errno.h>
+#include <sys/ioctl.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <sys/uio.h>
+
+#include "hw/hw.h"
+#include "block/aio.h"
+#include "hw/xen/xen_backend.h"
+
+enum tpmif_state {
+    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel complete */
+    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
+    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
+    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
+};
+
+static AioContext *vtpm_aio_ctx;
+
+enum status_bits {
+    VTPM_STATUS_RUNNING  = 0x1,
+    VTPM_STATUS_IDLE     = 0x2,
+    VTPM_STATUS_RESULT   = 0x4,
+    VTPM_STATUS_CANCELED = 0x8,
+};
+
+struct tpmif_shared_page {
+    uint32_t length;         /* request/response length in bytes */
+
+    uint8_t  state;           /* enum tpmif_state */
+    uint8_t  locality;        /* for the current request */
+    uint8_t  pad;             /* should be zero */
+
+    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be zero */
+    uint32_t extra_pages[0]; /* grant IDs; length is actually nr_extra_pages */
+};
+
+struct XenVtpmDev {
+    struct XenDevice xendev;  /* must be first */
+    struct           tpmif_shared_page *shr;
+    xc_gntshr        *xen_xcs;
+    int              ring_ref;
+    int              bedomid;
+    QEMUBH           *sr_bh;
+};
+
+static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
+{
+    switch (vtpmdev->shr->state) {
+    case TPMIF_STATE_IDLE:
+    case TPMIF_STATE_FINISH:
+        return VTPM_STATUS_IDLE;
+    case TPMIF_STATE_SUBMIT:
+    case TPMIF_STATE_CANCEL:
+        return VTPM_STATUS_RUNNING;
+    default:
+        return 0;
+    }
+}
+
+static int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)
+{
+    xs_transaction_t xbt = XBT_NULL;
+
+    if (xendev->fe_state == xbus) {
+        return 0;
+    }
+
+    xendev->fe_state = xbus;
+
+retry_transaction:
+    xbt = xs_transaction_start(xenstore);
+    if (xbt == XBT_NULL) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(xendev->fe, "state", xbus)) {
+        goto abort_transaction;
+    }
+
+    if (!xs_transaction_end(xenstore, xbt, 0)) {
+        if (errno == EAGAIN) {
+            goto retry_transaction;
+        }
+    }
+
+    return 0;
+
+abort_transaction:
+    xs_transaction_end(xenstore, xbt, 1);
+    return -1;
+}
+
+static bool vtpm_aio_wait(AioContext *ctx)
+{
+    return aio_poll(ctx, true);
+}
+
+static void sr_bh_handler(void *opaque)
+{
+}
+
+static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    struct tpmif_shared_page *shr = vtpmdev->shr;
+    unsigned int offset;
+
+    if (shr->state == TPMIF_STATE_IDLE) {
+        return -ECANCELED;
+    }
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpm_aio_ctx);
+    }
+
+    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
+    memcpy(buf, offset + (uint8_t *)shr, shr->length);
+    *count = shr->length;
+
+    return 0;
+}
+
+static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    struct tpmif_shared_page *shr = vtpmdev->shr;
+    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpm_aio_ctx);
+    }
+
+    memcpy(offset + (uint8_t *)shr, buf, count);
+    shr->length = count;
+    barrier();
+    shr->state = TPMIF_STATE_SUBMIT;
+    xen_wmb();
+    xen_be_send_notify(&vtpmdev->xendev);
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpm_aio_ctx);
+    }
+
+    return count;
+}
+
+static int vtpm_initialise(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    xs_transaction_t xbt = XBT_NULL;
+    unsigned int ring_ref;
+
+    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev, "frontend");
+    if (vtpmdev->xendev.fe == NULL) {
+        return -1;
+    }
+
+    /* Get backend domid */
+    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
+                             &vtpmdev->bedomid)) {
+        return -1;
+    }
+
+    /*alloc share page*/
+    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs, vtpmdev->bedomid, 1,
+                                         &ring_ref, PROT_READ|PROT_WRITE);
+    vtpmdev->ring_ref = ring_ref;
+    if (vtpmdev->shr == NULL) {
+        return -1;
+    }
+
+    /*Create event channel */
+    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0, vtpmdev->bedomid)) {
+        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+        return -1;
+    }
+
+    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
+                     vtpmdev->xendev.local_port);
+
+again:
+    xbt = xs_transaction_start(xenstore);
+    if (xbt == XBT_NULL) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
+                           vtpmdev->ring_ref)) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
+                           vtpmdev->xendev.local_port)) {
+        goto abort_transaction;
+    }
+
+    /* Publish protocol v2 feature */
+    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1)) {
+        goto abort_transaction;
+    }
+
+    if (!xs_transaction_end(xenstore, xbt, 0)) {
+        if (errno == EAGAIN) {
+            goto again;
+        }
+    }
+    /* Tell vtpm backend that we are ready */
+    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
+
+    return 0;
+
+abort_transaction:
+    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+    xs_transaction_end(xenstore, xbt, 1);
+    return -1;
+}
+
+static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    int be_state;
+
+    if (strcmp(node, "state") == 0) {
+        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
+        switch (be_state) {
+        case XenbusStateConnected:
+            /*TODO*/
+            break;
+        case XenbusStateClosing:
+        case XenbusStateClosed:
+            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
+            break;
+        default:
+            break;
+        }
+    }
+}
+
+static int vtpm_free(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    aio_poll(vtpm_aio_ctx, false);
+    qemu_bh_delete(vtpmdev->sr_bh);
+    if (vtpmdev->shr) {
+        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+    }
+    xc_interface_close(vtpmdev->xen_xcs);
+    return 0;
+}
+
+static void vtpm_alloc(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+
+    vtpm_aio_ctx = aio_context_new(NULL);
+    if (vtpm_aio_ctx == NULL) {
+        return;
+    }
+    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler, vtpmdev);
+    qemu_bh_schedule(vtpmdev->sr_bh);
+    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
+}
+
+static void vtpm_event(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+
+    qemu_bh_schedule(vtpmdev->sr_bh);
+}
+
+struct XenDevOps xen_vtpmdev_ops = {
+    .size             = sizeof(struct XenVtpmDev),
+    .flags            = DEVOPS_FLAG_IGNORE_STATE |
+                        DEVOPS_FLAG_STUBDOM_BE,
+    .event            = vtpm_event,
+    .free             = vtpm_free,
+    .alloc            = vtpm_alloc,
+    .initialise       = vtpm_initialise,
+    .backend_changed  = vtpm_backend_changed,
+    .recv             = vtpm_recv,
+    .send             = vtpm_send,
+};
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..5e7cfe5 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state)
     return 0;
 }
 
+/*get stubdom backend*/
+static char *xen_stubdom_be(const char *type, int dom, int dev)
+{
+    char *val, *domu;
+    char path[XEN_BUFSIZE];
+    unsigned int len, ival;
+
+    /*front domu*/
+    domu = xs_get_domain_path(xenstore, dom);
+    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
+             domu, type, dev);
+    g_free(domu);
+
+    val = xs_read(xenstore, 0, path, &len);
+    if (!val || 1 != sscanf(val, "%d", &ival)) {
+        g_free(val);
+        return NULL;
+    }
+    g_free(val);
+
+    /*backend domu*/
+    domu = xs_get_domain_path(xenstore, ival);
+
+    return domu;
+}
+
 /* ------------------------------------------------------------- */
 
 struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
@@ -273,6 +299,68 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
 }
 
 /*
+ * get xen stubdom backend device, allocate a new one if it doesn't exist.
+ */
+static struct XenDevice *xen_stubdom_be_get_xendev(const char *type,
+                         int dom, int dev, struct XenDevOps *ops)
+{
+    struct XenDevice *xendev;
+    char *stub;
+
+    xendev = xen_be_find_xendev(type, dom, dev);
+    if (xendev) {
+        return xendev;
+    }
+
+    /* init new xendev */
+    xendev = g_malloc0(ops->size);
+    xendev->type  = type;
+    xendev->dom   = dom;
+    xendev->dev   = dev;
+    xendev->ops   = ops;
+
+    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
+        stub = xen_stubdom_be(xendev->type, xendev->dom, xendev->dev);
+        snprintf(xendev->be, sizeof(xendev->be), "%s/backend/%s/%d/%d",
+                 stub, xendev->type, xendev->dom, xendev->dev);
+        g_free(stub);
+    }
+    snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
+             xendev->type, xendev->dev);
+
+    xendev->debug      = debug;
+    xendev->local_port = -1;
+
+    xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
+    if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
+        xen_be_printf(NULL, 0, "can't open evtchn device\n");
+        g_free(xendev);
+        return NULL;
+    }
+    fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
+
+    if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
+        xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
+        if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
+            xen_be_printf(NULL, 0, "can't open gnttab device\n");
+            xc_evtchn_close(xendev->evtchndev);
+            g_free(xendev);
+            return NULL;
+        }
+    } else {
+        xendev->gnttabdev = XC_HANDLER_INITIAL_VALUE;
+    }
+
+    QTAILQ_INSERT_TAIL(&xendevs, xendev, next);
+
+    if (xendev->ops->alloc) {
+        xendev->ops->alloc(xendev);
+    }
+
+    return xendev;
+}
+
+/*
  * release xen backend device.
  */
 static struct XenDevice *xen_be_del_xendev(int dom, int dev)
@@ -611,6 +699,47 @@ static int xenstore_scan(const char *type, int dom, struct XenDevOps *ops)
     return 0;
 }
 
+static void stubdom_update_be(char *watch, char *type, int dom,
+                              struct XenDevOps *ops)
+{
+    struct XenDevice *xendev;
+    char path[XEN_BUFSIZE];
+    char *ptr, *bepath;
+    unsigned int len, dev;
+
+    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
+        return;
+    }
+
+    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
+    ptr = strstr(watch, path);
+    if (ptr == NULL) {
+        return;
+    }
+
+    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
+        strcpy(path, "");
+        if (sscanf(ptr+len, "/%u", &dev) != 1) {
+            dev = -1;
+        }
+    }
+
+    if (dev == -1) {
+        return;
+    }
+
+    xendev = xen_be_get_xendev(type, dom, dev, ops);
+    if (xendev != NULL) {
+        bepath = xs_read(xenstore, 0, xendev->be, &len);
+        if (bepath == NULL) {
+            xen_be_del_xendev(dom, dev);
+        } else {
+            free(bepath);
+            xen_be_backend_changed(xendev, path);
+        }
+    }
+}
+
 static void xenstore_update_be(char *watch, char *type, int dom,
                                struct XenDevOps *ops)
 {
@@ -681,6 +810,10 @@ static void xenstore_update(void *unused)
     if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
         xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
     }
+    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%" PRIxPTR,
+               &type, &dom, &ops) == 3) {
+        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
+    }
 
 cleanup:
     free(vec);
@@ -732,11 +865,114 @@ err:
     return -1;
 }
 
+static int stubdom_check(struct XenDevice *xendev, uint32_t domid,
+                         int handle)
+{
+    int rc = 0;
+
+    if (xendev->ops->init) {
+        rc = xendev->ops->init(xendev);
+    }
+
+    if (rc != 0) {
+        xen_be_printf(xendev, 0, "xendev %s init error\n",
+                     xendev->name);
+       goto err;
+    }
+
+    if (xendev->ops->initialise) {
+        rc = xendev->ops->initialise(xendev);
+    }
+
+    if (rc != 0) {
+        xen_be_printf(xendev, 0, "xendev %s initialise error\n",
+                     xendev->name);
+       goto err;
+    }
+
+    if (xendev->ops->connected) {
+        xendev->ops->connected(xendev);
+    }
+
+    return rc;
+
+err:
+    xen_be_del_xendev(domid, handle);
+    return -1;
+}
+
+static int xenstore_stubdom_scan(const char *type, uint32_t domid,
+                                 struct XenDevOps *ops)
+{
+    struct XenDevice *xendev;
+    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
+    char *domu;
+    unsigned int cdev, j;
+    char **dev = NULL;
+
+    /*stubom : /local/domain/ID */
+    domu = xs_get_domain_path(xenstore, domid);
+    snprintf(path, sizeof(path), "%s/device/%s",
+             domu, type);
+    free(domu);
+    dev = xs_directory(xenstore, 0, path, &cdev);
+    if (dev == NULL) {
+        return 0;
+    }
+
+    for (j = 0; j < cdev; j++) {
+        xendev = xen_stubdom_be_get_xendev(type, domid,
+                                           atoi(dev[j]), ops);
+        if (xendev == NULL) {
+            xen_be_printf(xendev, 0, "xendev is NULL.\n");
+            continue;
+        }
+
+        /* simplify QEMU side, a thread is running in Xen stubdom, which will
+         * connect frontend when the frontend is initialised.
+         */
+        if (stubdom_check(xendev, domid, atoi(dev[j])) < 0) {
+            xen_be_printf(xendev, 0, "xendev stubdom_check error.\n");
+            continue;
+        }
+
+        /*setup watch*/
+        snprintf(token, sizeof(token), "stub:%p:%d:%p",
+                 type, domid, xendev->ops);
+        if (!xs_watch(xenstore, xendev->be, token)) {
+            xen_be_printf(xendev, 0, "xs_watch failed.\n");
+            continue;
+        }
+    }
+
+    free(dev);
+    return 0;
+}
+
+int xen_fe_register(const char *type, struct XenDevOps *ops)
+{
+    return xenstore_stubdom_scan(type, xen_domid, ops);
+}
+
 int xen_be_register(const char *type, struct XenDevOps *ops)
 {
     return xenstore_scan(type, xen_domid, ops);
 }
 
+int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom)
+{
+    xendev->local_port = xc_evtchn_bind_unbound_port(xendev->evtchndev,
+                                                     remote_dom);
+    if (xendev->local_port == -1) {
+        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
+        return -1;
+    }
+    xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
+    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
+                        xen_be_evtchn_event, NULL, xendev);
+    return 0;
+}
+
 int xen_be_bind_evtchn(struct XenDevice *xendev)
 {
     if (xendev->local_port != -1) {
@@ -770,6 +1006,42 @@ int xen_be_send_notify(struct XenDevice *xendev)
     return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
 }
 
+int xen_vtpm_send(unsigned char *buf, size_t count)
+{
+    struct XenDevice *xendev;
+    int rc = -1;
+
+    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
+    if (xendev == NULL) {
+        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
+        return -1;
+    }
+
+    if (xendev->ops->send) {
+        rc = xendev->ops->send(xendev, buf, count);
+    }
+
+    return rc;
+}
+
+int xen_vtpm_recv(unsigned char *buf, size_t *count)
+{
+    struct XenDevice *xendev;
+    int rc = -1;
+
+    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
+    if (xendev == NULL) {
+        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
+        return -1;
+    }
+
+    if (xendev->ops->recv) {
+        xendev->ops->recv(xendev, buf, count);
+    }
+
+    return rc;
+}
+
 /*
  * msg_level:
  *  0 == errors (stderr + logfile).
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 3b4125e..f2d5489 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -15,6 +15,8 @@ struct XenDevice;
 #define DEVOPS_FLAG_NEED_GNTDEV   1
 /* don't expect frontend doing correct state transitions (aka console quirk) */
 #define DEVOPS_FLAG_IGNORE_STATE  2
+/*dev backend is stubdom*/
+#define DEVOPS_FLAG_STUBDOM_BE    4
 
 struct XenDevOps {
     size_t    size;
@@ -26,6 +28,8 @@ struct XenDevOps {
     void      (*event)(struct XenDevice *xendev);
     void      (*disconnect)(struct XenDevice *xendev);
     int       (*free)(struct XenDevice *xendev);
+    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t count);
+    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t *count);
     void      (*backend_changed)(struct XenDevice *xendev, const char *node);
     void      (*frontend_changed)(struct XenDevice *xendev, const char *node);
 };
@@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice *xendev);
 void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...)
     GCC_FMT_ATTR(3, 4);
 
+/*Xen stubdom vtpm*/
+int xen_fe_register(const char *type, struct XenDevOps *ops);
+int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
+int xen_vtpm_send(unsigned char *buf, size_t count);
+int xen_vtpm_recv(unsigned char *buf, size_t *count);
+
 /* actual backend drivers */
 extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
 extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c */
 extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
 extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c        */
 extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c         */
+extern struct XenDevOps xen_vtpmdev_ops;      /* xen_stubdom_vtpm.c*/
 
 void xen_init_display(int domid);
 
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 95612a4..fb43084 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
     return xc_interface_open(logger, dombuild_logger, open_flags);
 }
 
+static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
+                                           unsigned int open_flags)
+{
+    return xc_gntshr_open(logger, open_flags);
+}
+
 /* FIXME There is now way to have the xen fd */
 static inline int xc_fd(xc_interface *xen_xc)
 {
diff --git a/xen-hvm.c b/xen-hvm.c
index 21f1cbb..854b8f7 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
     int i, rc;
     unsigned long ioreq_pfn;
     unsigned long bufioreq_evtchn;
+
+#ifdef CONFIG_TPM_XENSTUBDOMS
+    unsigned long stubdom_vtpm = 0;
+#endif
+
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
         fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
         return -1;
     }
+
+#ifdef CONFIG_TPM_XENSTUBDOMS
+    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
+    if (stubdom_vtpm) {
+        xen_fe_register("vtpm", &xen_vtpmdev_ops);
+    }
+#endif
+
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
-- 
1.8.3.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08: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 1XsonE-0001Ng-6s; Mon, 24 Nov 2014 08:14:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XsonC-0001N6-6u
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:14:42 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	14/9D-22819-1F8E2745; Mon, 24 Nov 2014 08:14:41 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416816879!7658777!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6698 invoked from network); 24 Nov 2014 08:14:40 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-10.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 08:14:40 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 24 Nov 2014 00:07:27 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,447,1413270000"; d="scan'208";a="627257371"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 24 Nov 2014 00:14:27 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun, 23 Nov 2014 23:10:53 -0500
Message-Id: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: lcapitulino@redhat.com, eblake@redhat.com, armbru@redhat.com,
	Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [v2 1/4] Qemu-Xen-vTPM: Support for Xen stubdom vTPM
	command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 configure        | 14 ++++++++++++++
 hmp.c            |  7 +++++++
 qapi-schema.json | 20 ++++++++++++++++++--
 qemu-options.hx  | 13 +++++++++++--
 tpm.c            |  7 ++++++-
 5 files changed, 56 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index a9e4d49..d63b8a1 100755
--- a/configure
+++ b/configure
@@ -2942,6 +2942,16 @@ else
 fi
 
 ##########################################
+# TPM xenstubdoms is only on x86 Linux
+
+if test "$targetos" = Linux && test "$cpu" = i386 -o "$cpu" = x86_64 && \
+   test "$xen" = "yes"; then
+  tpm_xenstubdoms=$tpm
+else
+  tpm_xenstubdoms=no
+fi
+
+##########################################
 # attr probe
 
 if test "$attr" != "no" ; then
@@ -4333,6 +4343,7 @@ echo "gcov              $gcov_tool"
 echo "gcov enabled      $gcov"
 echo "TPM support       $tpm"
 echo "libssh2 support   $libssh2"
+echo "TPM xenstubdoms   $tpm_xenstubdoms"
 echo "TPM passthrough   $tpm_passthrough"
 echo "QOM debugging     $qom_cast_debug"
 echo "vhdx              $vhdx"
@@ -4810,6 +4821,9 @@ if test "$tpm" = "yes"; then
   if test "$tpm_passthrough" = "yes"; then
     echo "CONFIG_TPM_PASSTHROUGH=y" >> $config_host_mak
   fi
+  if test "$tpm_xenstubdoms" = "yes"; then
+    echo "CONFIG_TPM_XENSTUBDOMS=y" >> $config_host_mak
+  fi
 fi
 
 echo "TRACE_BACKENDS=$trace_backends" >> $config_host_mak
diff --git a/hmp.c b/hmp.c
index 63d7686..1df3ec7 100644
--- a/hmp.c
+++ b/hmp.c
@@ -689,6 +689,7 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
     Error *err = NULL;
     unsigned int c = 0;
     TPMPassthroughOptions *tpo;
+    TPMXenstubdomsOptions *txo;
 
     info_list = qmp_query_tpm(&err);
     if (err) {
@@ -718,6 +719,12 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
                            tpo->has_cancel_path ? ",cancel-path=" : "",
                            tpo->has_cancel_path ? tpo->cancel_path : "");
             break;
+        case TPM_TYPE_OPTIONS_KIND_XENSTUBDOMS:
+            txo = ti->options->xenstubdoms;
+            if (!txo) {
+                monitor_printf(mon, "null TPMXenstubdomsOptions error!\n");
+            }
+            break;
         case TPM_TYPE_OPTIONS_KIND_MAX:
             break;
         }
diff --git a/qapi-schema.json b/qapi-schema.json
index 24379ab..17e9d0f 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2855,8 +2855,12 @@
 # @passthrough: TPM passthrough type
 #
 # Since: 1.5
+#
+# @xenstubdoms: TPM xenstubdoms type
+#
+# Since: 2.3
 ##
-{ 'enum': 'TpmType', 'data': [ 'passthrough' ] }
+{ 'enum': 'TpmType', 'data': [ 'passthrough', 'xenstubdoms' ] }
 
 ##
 # @query-tpm-types:
@@ -2884,6 +2888,16 @@
 { 'type': 'TPMPassthroughOptions', 'data': { '*path' : 'str',
                                              '*cancel-path' : 'str'} }
 
+# @TPMXenstubdomsOptions:
+#
+# Information about the TPM xenstubdoms type
+#
+# Since: 2.3
+##
+{ 'type': 'TPMXenstubdomsOptions', 'data': {  } }
+#
+##
+
 ##
 # @TpmTypeOptions:
 #
@@ -2894,7 +2908,9 @@
 # Since: 1.5
 ##
 { 'union': 'TpmTypeOptions',
-   'data': { 'passthrough' : 'TPMPassthroughOptions' } }
+  'data': { 'passthrough' : 'TPMPassthroughOptions',
+            'xenstubdoms' : 'TPMXenstubdomsOptions' } }
+##
 
 ##
 # @TpmInfo:
diff --git a/qemu-options.hx b/qemu-options.hx
index 1e7d5b8..fd73f57 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2485,7 +2485,8 @@ DEF("tpmdev", HAS_ARG, QEMU_OPTION_tpmdev, \
     "-tpmdev passthrough,id=id[,path=path][,cancel-path=path]\n"
     "                use path to provide path to a character device; default is /dev/tpm0\n"
     "                use cancel-path to provide path to TPM's cancel sysfs entry; if\n"
-    "                not provided it will be searched for in /sys/class/misc/tpm?/device\n",
+    "                not provided it will be searched for in /sys/class/misc/tpm?/device\n"
+    "-tpmdev xenstubdoms,id=id\n",
     QEMU_ARCH_ALL)
 STEXI
 
@@ -2495,7 +2496,8 @@ The general form of a TPM device option is:
 @item -tpmdev @var{backend} ,id=@var{id} [,@var{options}]
 @findex -tpmdev
 Backend type must be:
-@option{passthrough}.
+@option{passthrough}, or
+@option{xenstubdoms}.
 
 The specific backend type will determine the applicable options.
 The @code{-tpmdev} option creates the TPM backend and requires a
@@ -2545,6 +2547,13 @@ To create a passthrough TPM use the following two options:
 Note that the @code{-tpmdev} id is @code{tpm0} and is referenced by
 @code{tpmdev=tpm0} in the device option.
 
+To create a xenstubdoms TPM use the following two options:
+@example
+-tpmdev xenstubdoms,id=tpm0 -device tpm-tis,tpmdev=tpm0
+@end example
+Note that the @code{-tpmdev} id is @code{tpm0} and is referenced by
+@code{tpmdev=tpm0} in the device option.
+
 @end table
 
 ETEXI
diff --git a/tpm.c b/tpm.c
index c371023..ee9acb8 100644
--- a/tpm.c
+++ b/tpm.c
@@ -25,7 +25,7 @@ static QLIST_HEAD(, TPMBackend) tpm_backends =
 
 
 #define TPM_MAX_MODELS      1
-#define TPM_MAX_DRIVERS     1
+#define TPM_MAX_DRIVERS     2
 
 static TPMDriverOps const *be_drivers[TPM_MAX_DRIVERS] = {
     NULL,
@@ -256,6 +256,7 @@ static TPMInfo *qmp_query_tpm_inst(TPMBackend *drv)
 {
     TPMInfo *res = g_new0(TPMInfo, 1);
     TPMPassthroughOptions *tpo;
+    TPMXenstubdomsOptions *txo;
 
     res->id = g_strdup(drv->id);
     res->model = drv->fe_model;
@@ -275,6 +276,10 @@ static TPMInfo *qmp_query_tpm_inst(TPMBackend *drv)
             tpo->has_cancel_path = true;
         }
         break;
+    case TPM_TYPE_XENSTUBDOMS:
+        res->options->kind = TPM_TYPE_OPTIONS_KIND_XENSTUBDOMS;
+        txo = g_new0(TPMXenstubdomsOptions, 1);
+        res->options->xenstubdoms = txo;
     case TPM_TYPE_MAX:
         break;
     }
-- 
1.8.3.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08: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 1XsonE-0001OG-Op; Mon, 24 Nov 2014 08:14:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XsonD-0001NN-9i
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:14:43 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	2B/42-14214-2F8E2745; Mon, 24 Nov 2014 08:14:42 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416816879!7658777!2
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6849 invoked from network); 24 Nov 2014 08:14:41 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-10.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 08:14:41 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 24 Nov 2014 00:07:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="420689655"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 24 Nov 2014 00:04:54 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun, 23 Nov 2014 23:10:59 -0500
Message-Id: <1416802259-9965-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: stefano.stabellini@eu.citrix.com, quan.xu@intel.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [v2 3/4] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms driver.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This driver provides vTPM initialization and sending data and TPM
commends to a Xen stubdom vTPM domain.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/tpm/Makefile.objs     |   1 +
 hw/tpm/tpm_xenstubdoms.c | 238 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 239 insertions(+)
 create mode 100644 hw/tpm/tpm_xenstubdoms.c

diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 87efb01..20f0a7b 100644
--- a/hw/tpm/Makefile.objs
+++ b/hw/tpm/Makefile.objs
@@ -1,3 +1,4 @@
 common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
 common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o
 common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
new file mode 100644
index 0000000..845df18
--- /dev/null
+++ b/hw/tpm/tpm_xenstubdoms.c
@@ -0,0 +1,238 @@
+/*
+ * Xen Stubdom vTPM driver
+ *
+ *  Copyright (c) 2014 Intel Corporation
+ *  Authors:
+ *    Quan Xu <quan.xu@intel.com>
+ *
+ * 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 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, see <http://www.gnu.org/licenses/>
+ */
+
+#include <dirent.h>
+#include "qemu-common.h"
+#include "qapi/error.h"
+#include "qemu/sockets.h"
+#include "qemu/log.h"
+#include "sysemu/tpm_backend.h"
+#include "tpm_int.h"
+#include "hw/hw.h"
+#include "hw/i386/pc.h"
+#include "hw/xen/xen_backend.h"
+#include "sysemu/tpm_backend_int.h"
+#include "tpm_tis.h"
+
+#ifdef DEBUG_TPM
+#define DPRINTF(fmt, ...) \
+    do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+    do { } while (0)
+#endif
+
+#define TYPE_TPM_XENSTUBDOMS "tpm-xenstubdoms"
+#define TPM_XENSTUBDOMS(obj) \
+    OBJECT_CHECK(TPMXenstubdomsState, (obj), TYPE_TPM_XENSTUBDOMS)
+
+static const TPMDriverOps tpm_xenstubdoms_driver;
+
+/* data structures */
+typedef struct TPMXenstubdomsThreadParams {
+    TPMState *tpm_state;
+    TPMRecvDataCB *recv_data_callback;
+    TPMBackend *tb;
+} TPMXenstubdomsThreadParams;
+
+struct TPMXenstubdomsState {
+    TPMBackend parent;
+    TPMBackendThread tbt;
+    TPMXenstubdomsThreadParams tpm_thread_params;
+    bool had_startup_error;
+};
+
+typedef struct TPMXenstubdomsState TPMXenstubdomsState;
+
+/* functions */
+
+static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb);
+
+static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
+{
+    size_t rlen;
+    xen_vtpm_send(locty_data->w_buffer.buffer, locty_data->w_offset);
+    xen_vtpm_recv(locty_data->r_buffer.buffer, &rlen);
+    return 0;
+}
+
+static void tpm_xenstubdoms_worker_thread(gpointer data,
+                                          gpointer user_data)
+{
+    TPMXenstubdomsThreadParams *thr_parms = user_data;
+    TPMBackendCmd cmd = (TPMBackendCmd)data;
+
+    switch (cmd) {
+    case TPM_BACKEND_CMD_PROCESS_CMD:
+        /* here need a the cmd process function */
+        tpm_xenstubdoms_unix_transfer(thr_parms->tpm_state->locty_data);
+        thr_parms->recv_data_callback(thr_parms->tpm_state,
+                                      thr_parms->tpm_state->locty_number);
+        break;
+    case TPM_BACKEND_CMD_INIT:
+    case TPM_BACKEND_CMD_END:
+    case TPM_BACKEND_CMD_TPM_RESET:
+        /* nothing to do */
+        break;
+    }
+}
+
+/*
+ *  * Start the TPM (thread). If it had been started before, then terminate
+ *   * and start it again.
+ *    */
+static int tpm_xenstubdoms_startup_tpm(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_backend_thread_tpm_reset(&tpm_xs->tbt, tpm_xenstubdoms_worker_thread,
+                                 &tpm_xs->tpm_thread_params);
+
+    return 0;
+}
+
+static void tpm_xenstubdoms_reset(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_backend_thread_end(&tpm_xs->tbt);
+    tpm_xs->had_startup_error = false;
+}
+
+static int tpm_xenstubdoms_init(TPMBackend *tb, TPMState *s,
+                                TPMRecvDataCB *recv_data_cb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_xs->tpm_thread_params.tpm_state = s;
+    tpm_xs->tpm_thread_params.recv_data_callback = recv_data_cb;
+    tpm_xs->tpm_thread_params.tb = tb;
+    return 0;
+}
+
+static bool tpm_xenstubdoms_get_tpm_established_flag(TPMBackend *tb)
+{
+    return false;
+}
+
+static bool tpm_xenstubdoms_get_startup_error(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    return tpm_xs->had_startup_error;
+}
+
+static size_t tpm_xenstubdoms_realloc_buffer(TPMSizedBuffer *sb)
+{
+    size_t wanted_size = 4096; /* Linux tpm.c buffer size */
+
+    if (sb->size != wanted_size) {
+        sb->buffer = g_realloc(sb->buffer, wanted_size);
+        sb->size = wanted_size;
+    }
+    return sb->size;
+}
+
+static void tpm_xenstubdoms_deliver_request(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+    tpm_backend_thread_deliver_request(&tpm_xs->tbt);
+}
+
+static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb)
+{
+}
+
+static const char *tpm_xenstubdoms_create_desc(void)
+{
+    return "Xenstubdoms TPM backend driver";
+}
+
+static TPMBackend *tpm_xenstubdoms_create(QemuOpts *opts, const char *id)
+{
+    Object *obj = object_new(TYPE_TPM_XENSTUBDOMS);
+    TPMBackend *tb = TPM_BACKEND(obj);
+
+    tb->id = g_strdup(id);
+    tb->fe_model = -1;
+    tb->ops = &tpm_xenstubdoms_driver;
+    return tb;
+}
+
+static void tpm_xenstubdoms_destroy(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xh = TPM_XENSTUBDOMS(tb);
+    tpm_backend_thread_end(&tpm_xh->tbt);
+
+    g_free(tb->id);
+}
+
+static const QemuOptDesc tpm_xenstubdoms_cmdline_opts[] = {
+    TPM_STANDARD_CMDLINE_OPTS,
+    {},
+};
+
+static const TPMDriverOps tpm_xenstubdoms_driver = {
+    .type                     = TPM_TYPE_XENSTUBDOMS,
+    .opts                     = tpm_xenstubdoms_cmdline_opts,
+    .desc                     = tpm_xenstubdoms_create_desc,
+    .create                   = tpm_xenstubdoms_create,
+    .destroy                  = tpm_xenstubdoms_destroy,
+    .init                     = tpm_xenstubdoms_init,
+    .startup_tpm              = tpm_xenstubdoms_startup_tpm,
+    .realloc_buffer           = tpm_xenstubdoms_realloc_buffer,
+    .reset                    = tpm_xenstubdoms_reset,
+    .had_startup_error        = tpm_xenstubdoms_get_startup_error,
+    .deliver_request          = tpm_xenstubdoms_deliver_request,
+    .cancel_cmd               = tpm_xenstubdoms_cancel_cmd,
+    .get_tpm_established_flag = tpm_xenstubdoms_get_tpm_established_flag,
+};
+
+static void tpm_xenstubdoms_inst_init(Object *obj)
+{
+}
+
+static void tpm_xenstubdoms_inst_finalize(Object *obj)
+{
+}
+
+static void tpm_xenstubdoms_class_init(ObjectClass *klass, void *data)
+{
+    TPMBackendClass *tbc = TPM_BACKEND_CLASS(klass);
+    tbc->ops = &tpm_xenstubdoms_driver;
+}
+
+static const TypeInfo tpm_xenstubdoms_info = {
+    .name = TYPE_TPM_XENSTUBDOMS,
+    .parent = TYPE_TPM_BACKEND,
+    .instance_size = sizeof(TPMXenstubdomsState),
+    .class_init = tpm_xenstubdoms_class_init,
+    .instance_init = tpm_xenstubdoms_inst_init,
+    .instance_finalize = tpm_xenstubdoms_inst_finalize,
+};
+
+static void tpm_xenstubdoms_register(void)
+{
+    type_register_static(&tpm_xenstubdoms_info);
+    tpm_register_driver(&tpm_xenstubdoms_driver);
+}
+
+type_init(tpm_xenstubdoms_register)
-- 
1.8.3.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08: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 1Xson8-0001MH-QB; Mon, 24 Nov 2014 08:14:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Xson7-0001Lo-AV
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:14:37 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	B4/44-09284-CE8E2745; Mon, 24 Nov 2014 08:14:36 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416816872!13273068!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2252 invoked from network); 24 Nov 2014 08:14:33 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-31.messagelabs.com with SMTP;
	24 Nov 2014 08:14:33 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2014 00:14:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,447,1413270000"; d="scan'208";a="612968683"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 24 Nov 2014 00:14:31 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun, 23 Nov 2014 23:10:56 -0500
Message-Id: <1416802256-9928-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: stefano.stabellini@eu.citrix.com, Quan Xu <quan.xu@intel.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
	frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This drvier transfers any request/repond between TPM xenstubdoms
driver and Xen vTPM stubdom, and facilitates communications between
Xen vTPM stubdom domain and vTPM xenstubdoms driver

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/tpm/Makefile.objs         |   1 +
 hw/tpm/xen_stubdom_vtpm.c    | 321 +++++++++++++++++++++++++++++++++++++++++++
 hw/xen/xen_backend.c         | 272 ++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  11 ++
 include/hw/xen/xen_common.h  |   6 +
 xen-hvm.c                    |  13 ++
 6 files changed, 624 insertions(+)
 create mode 100644 hw/tpm/xen_stubdom_vtpm.c

diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 99f5983..87efb01 100644
--- a/hw/tpm/Makefile.objs
+++ b/hw/tpm/Makefile.objs
@@ -1,2 +1,3 @@
 common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
 common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
diff --git a/hw/tpm/xen_stubdom_vtpm.c b/hw/tpm/xen_stubdom_vtpm.c
new file mode 100644
index 0000000..4fd6053
--- /dev/null
+++ b/hw/tpm/xen_stubdom_vtpm.c
@@ -0,0 +1,321 @@
+/*
+ * Connect to Xen vTPM stubdom domain
+ *
+ *  Copyright (c) 2014 Intel Corporation
+ *  Authors:
+ *    Quan Xu <quan.xu@intel.com>
+ *
+ * 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 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, see <http://www.gnu.org/licenses/>
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdarg.h>
+#include <string.h>
+#include <unistd.h>
+#include <signal.h>
+#include <inttypes.h>
+#include <time.h>
+#include <fcntl.h>
+#include <errno.h>
+#include <sys/ioctl.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <sys/uio.h>
+
+#include "hw/hw.h"
+#include "block/aio.h"
+#include "hw/xen/xen_backend.h"
+
+enum tpmif_state {
+    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel complete */
+    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
+    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
+    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
+};
+
+static AioContext *vtpm_aio_ctx;
+
+enum status_bits {
+    VTPM_STATUS_RUNNING  = 0x1,
+    VTPM_STATUS_IDLE     = 0x2,
+    VTPM_STATUS_RESULT   = 0x4,
+    VTPM_STATUS_CANCELED = 0x8,
+};
+
+struct tpmif_shared_page {
+    uint32_t length;         /* request/response length in bytes */
+
+    uint8_t  state;           /* enum tpmif_state */
+    uint8_t  locality;        /* for the current request */
+    uint8_t  pad;             /* should be zero */
+
+    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be zero */
+    uint32_t extra_pages[0]; /* grant IDs; length is actually nr_extra_pages */
+};
+
+struct XenVtpmDev {
+    struct XenDevice xendev;  /* must be first */
+    struct           tpmif_shared_page *shr;
+    xc_gntshr        *xen_xcs;
+    int              ring_ref;
+    int              bedomid;
+    QEMUBH           *sr_bh;
+};
+
+static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
+{
+    switch (vtpmdev->shr->state) {
+    case TPMIF_STATE_IDLE:
+    case TPMIF_STATE_FINISH:
+        return VTPM_STATUS_IDLE;
+    case TPMIF_STATE_SUBMIT:
+    case TPMIF_STATE_CANCEL:
+        return VTPM_STATUS_RUNNING;
+    default:
+        return 0;
+    }
+}
+
+static int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)
+{
+    xs_transaction_t xbt = XBT_NULL;
+
+    if (xendev->fe_state == xbus) {
+        return 0;
+    }
+
+    xendev->fe_state = xbus;
+
+retry_transaction:
+    xbt = xs_transaction_start(xenstore);
+    if (xbt == XBT_NULL) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(xendev->fe, "state", xbus)) {
+        goto abort_transaction;
+    }
+
+    if (!xs_transaction_end(xenstore, xbt, 0)) {
+        if (errno == EAGAIN) {
+            goto retry_transaction;
+        }
+    }
+
+    return 0;
+
+abort_transaction:
+    xs_transaction_end(xenstore, xbt, 1);
+    return -1;
+}
+
+static bool vtpm_aio_wait(AioContext *ctx)
+{
+    return aio_poll(ctx, true);
+}
+
+static void sr_bh_handler(void *opaque)
+{
+}
+
+static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    struct tpmif_shared_page *shr = vtpmdev->shr;
+    unsigned int offset;
+
+    if (shr->state == TPMIF_STATE_IDLE) {
+        return -ECANCELED;
+    }
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpm_aio_ctx);
+    }
+
+    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
+    memcpy(buf, offset + (uint8_t *)shr, shr->length);
+    *count = shr->length;
+
+    return 0;
+}
+
+static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    struct tpmif_shared_page *shr = vtpmdev->shr;
+    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpm_aio_ctx);
+    }
+
+    memcpy(offset + (uint8_t *)shr, buf, count);
+    shr->length = count;
+    barrier();
+    shr->state = TPMIF_STATE_SUBMIT;
+    xen_wmb();
+    xen_be_send_notify(&vtpmdev->xendev);
+
+    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
+        vtpm_aio_wait(vtpm_aio_ctx);
+    }
+
+    return count;
+}
+
+static int vtpm_initialise(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    xs_transaction_t xbt = XBT_NULL;
+    unsigned int ring_ref;
+
+    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev, "frontend");
+    if (vtpmdev->xendev.fe == NULL) {
+        return -1;
+    }
+
+    /* Get backend domid */
+    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
+                             &vtpmdev->bedomid)) {
+        return -1;
+    }
+
+    /*alloc share page*/
+    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs, vtpmdev->bedomid, 1,
+                                         &ring_ref, PROT_READ|PROT_WRITE);
+    vtpmdev->ring_ref = ring_ref;
+    if (vtpmdev->shr == NULL) {
+        return -1;
+    }
+
+    /*Create event channel */
+    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0, vtpmdev->bedomid)) {
+        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+        return -1;
+    }
+
+    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
+                     vtpmdev->xendev.local_port);
+
+again:
+    xbt = xs_transaction_start(xenstore);
+    if (xbt == XBT_NULL) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
+                           vtpmdev->ring_ref)) {
+        goto abort_transaction;
+    }
+
+    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
+                           vtpmdev->xendev.local_port)) {
+        goto abort_transaction;
+    }
+
+    /* Publish protocol v2 feature */
+    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1)) {
+        goto abort_transaction;
+    }
+
+    if (!xs_transaction_end(xenstore, xbt, 0)) {
+        if (errno == EAGAIN) {
+            goto again;
+        }
+    }
+    /* Tell vtpm backend that we are ready */
+    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
+
+    return 0;
+
+abort_transaction:
+    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+    xs_transaction_end(xenstore, xbt, 1);
+    return -1;
+}
+
+static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    int be_state;
+
+    if (strcmp(node, "state") == 0) {
+        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
+        switch (be_state) {
+        case XenbusStateConnected:
+            /*TODO*/
+            break;
+        case XenbusStateClosing:
+        case XenbusStateClosed:
+            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
+            break;
+        default:
+            break;
+        }
+    }
+}
+
+static int vtpm_free(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+    aio_poll(vtpm_aio_ctx, false);
+    qemu_bh_delete(vtpmdev->sr_bh);
+    if (vtpmdev->shr) {
+        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
+    }
+    xc_interface_close(vtpmdev->xen_xcs);
+    return 0;
+}
+
+static void vtpm_alloc(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+
+    vtpm_aio_ctx = aio_context_new(NULL);
+    if (vtpm_aio_ctx == NULL) {
+        return;
+    }
+    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler, vtpmdev);
+    qemu_bh_schedule(vtpmdev->sr_bh);
+    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
+}
+
+static void vtpm_event(struct XenDevice *xendev)
+{
+    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
+                                              xendev);
+
+    qemu_bh_schedule(vtpmdev->sr_bh);
+}
+
+struct XenDevOps xen_vtpmdev_ops = {
+    .size             = sizeof(struct XenVtpmDev),
+    .flags            = DEVOPS_FLAG_IGNORE_STATE |
+                        DEVOPS_FLAG_STUBDOM_BE,
+    .event            = vtpm_event,
+    .free             = vtpm_free,
+    .alloc            = vtpm_alloc,
+    .initialise       = vtpm_initialise,
+    .backend_changed  = vtpm_backend_changed,
+    .recv             = vtpm_recv,
+    .send             = vtpm_send,
+};
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..5e7cfe5 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state)
     return 0;
 }
 
+/*get stubdom backend*/
+static char *xen_stubdom_be(const char *type, int dom, int dev)
+{
+    char *val, *domu;
+    char path[XEN_BUFSIZE];
+    unsigned int len, ival;
+
+    /*front domu*/
+    domu = xs_get_domain_path(xenstore, dom);
+    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
+             domu, type, dev);
+    g_free(domu);
+
+    val = xs_read(xenstore, 0, path, &len);
+    if (!val || 1 != sscanf(val, "%d", &ival)) {
+        g_free(val);
+        return NULL;
+    }
+    g_free(val);
+
+    /*backend domu*/
+    domu = xs_get_domain_path(xenstore, ival);
+
+    return domu;
+}
+
 /* ------------------------------------------------------------- */
 
 struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
@@ -273,6 +299,68 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
 }
 
 /*
+ * get xen stubdom backend device, allocate a new one if it doesn't exist.
+ */
+static struct XenDevice *xen_stubdom_be_get_xendev(const char *type,
+                         int dom, int dev, struct XenDevOps *ops)
+{
+    struct XenDevice *xendev;
+    char *stub;
+
+    xendev = xen_be_find_xendev(type, dom, dev);
+    if (xendev) {
+        return xendev;
+    }
+
+    /* init new xendev */
+    xendev = g_malloc0(ops->size);
+    xendev->type  = type;
+    xendev->dom   = dom;
+    xendev->dev   = dev;
+    xendev->ops   = ops;
+
+    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
+        stub = xen_stubdom_be(xendev->type, xendev->dom, xendev->dev);
+        snprintf(xendev->be, sizeof(xendev->be), "%s/backend/%s/%d/%d",
+                 stub, xendev->type, xendev->dom, xendev->dev);
+        g_free(stub);
+    }
+    snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
+             xendev->type, xendev->dev);
+
+    xendev->debug      = debug;
+    xendev->local_port = -1;
+
+    xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
+    if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
+        xen_be_printf(NULL, 0, "can't open evtchn device\n");
+        g_free(xendev);
+        return NULL;
+    }
+    fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
+
+    if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
+        xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
+        if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
+            xen_be_printf(NULL, 0, "can't open gnttab device\n");
+            xc_evtchn_close(xendev->evtchndev);
+            g_free(xendev);
+            return NULL;
+        }
+    } else {
+        xendev->gnttabdev = XC_HANDLER_INITIAL_VALUE;
+    }
+
+    QTAILQ_INSERT_TAIL(&xendevs, xendev, next);
+
+    if (xendev->ops->alloc) {
+        xendev->ops->alloc(xendev);
+    }
+
+    return xendev;
+}
+
+/*
  * release xen backend device.
  */
 static struct XenDevice *xen_be_del_xendev(int dom, int dev)
@@ -611,6 +699,47 @@ static int xenstore_scan(const char *type, int dom, struct XenDevOps *ops)
     return 0;
 }
 
+static void stubdom_update_be(char *watch, char *type, int dom,
+                              struct XenDevOps *ops)
+{
+    struct XenDevice *xendev;
+    char path[XEN_BUFSIZE];
+    char *ptr, *bepath;
+    unsigned int len, dev;
+
+    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
+        return;
+    }
+
+    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
+    ptr = strstr(watch, path);
+    if (ptr == NULL) {
+        return;
+    }
+
+    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
+        strcpy(path, "");
+        if (sscanf(ptr+len, "/%u", &dev) != 1) {
+            dev = -1;
+        }
+    }
+
+    if (dev == -1) {
+        return;
+    }
+
+    xendev = xen_be_get_xendev(type, dom, dev, ops);
+    if (xendev != NULL) {
+        bepath = xs_read(xenstore, 0, xendev->be, &len);
+        if (bepath == NULL) {
+            xen_be_del_xendev(dom, dev);
+        } else {
+            free(bepath);
+            xen_be_backend_changed(xendev, path);
+        }
+    }
+}
+
 static void xenstore_update_be(char *watch, char *type, int dom,
                                struct XenDevOps *ops)
 {
@@ -681,6 +810,10 @@ static void xenstore_update(void *unused)
     if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
         xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
     }
+    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%" PRIxPTR,
+               &type, &dom, &ops) == 3) {
+        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
+    }
 
 cleanup:
     free(vec);
@@ -732,11 +865,114 @@ err:
     return -1;
 }
 
+static int stubdom_check(struct XenDevice *xendev, uint32_t domid,
+                         int handle)
+{
+    int rc = 0;
+
+    if (xendev->ops->init) {
+        rc = xendev->ops->init(xendev);
+    }
+
+    if (rc != 0) {
+        xen_be_printf(xendev, 0, "xendev %s init error\n",
+                     xendev->name);
+       goto err;
+    }
+
+    if (xendev->ops->initialise) {
+        rc = xendev->ops->initialise(xendev);
+    }
+
+    if (rc != 0) {
+        xen_be_printf(xendev, 0, "xendev %s initialise error\n",
+                     xendev->name);
+       goto err;
+    }
+
+    if (xendev->ops->connected) {
+        xendev->ops->connected(xendev);
+    }
+
+    return rc;
+
+err:
+    xen_be_del_xendev(domid, handle);
+    return -1;
+}
+
+static int xenstore_stubdom_scan(const char *type, uint32_t domid,
+                                 struct XenDevOps *ops)
+{
+    struct XenDevice *xendev;
+    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
+    char *domu;
+    unsigned int cdev, j;
+    char **dev = NULL;
+
+    /*stubom : /local/domain/ID */
+    domu = xs_get_domain_path(xenstore, domid);
+    snprintf(path, sizeof(path), "%s/device/%s",
+             domu, type);
+    free(domu);
+    dev = xs_directory(xenstore, 0, path, &cdev);
+    if (dev == NULL) {
+        return 0;
+    }
+
+    for (j = 0; j < cdev; j++) {
+        xendev = xen_stubdom_be_get_xendev(type, domid,
+                                           atoi(dev[j]), ops);
+        if (xendev == NULL) {
+            xen_be_printf(xendev, 0, "xendev is NULL.\n");
+            continue;
+        }
+
+        /* simplify QEMU side, a thread is running in Xen stubdom, which will
+         * connect frontend when the frontend is initialised.
+         */
+        if (stubdom_check(xendev, domid, atoi(dev[j])) < 0) {
+            xen_be_printf(xendev, 0, "xendev stubdom_check error.\n");
+            continue;
+        }
+
+        /*setup watch*/
+        snprintf(token, sizeof(token), "stub:%p:%d:%p",
+                 type, domid, xendev->ops);
+        if (!xs_watch(xenstore, xendev->be, token)) {
+            xen_be_printf(xendev, 0, "xs_watch failed.\n");
+            continue;
+        }
+    }
+
+    free(dev);
+    return 0;
+}
+
+int xen_fe_register(const char *type, struct XenDevOps *ops)
+{
+    return xenstore_stubdom_scan(type, xen_domid, ops);
+}
+
 int xen_be_register(const char *type, struct XenDevOps *ops)
 {
     return xenstore_scan(type, xen_domid, ops);
 }
 
+int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom)
+{
+    xendev->local_port = xc_evtchn_bind_unbound_port(xendev->evtchndev,
+                                                     remote_dom);
+    if (xendev->local_port == -1) {
+        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
+        return -1;
+    }
+    xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
+    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
+                        xen_be_evtchn_event, NULL, xendev);
+    return 0;
+}
+
 int xen_be_bind_evtchn(struct XenDevice *xendev)
 {
     if (xendev->local_port != -1) {
@@ -770,6 +1006,42 @@ int xen_be_send_notify(struct XenDevice *xendev)
     return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
 }
 
+int xen_vtpm_send(unsigned char *buf, size_t count)
+{
+    struct XenDevice *xendev;
+    int rc = -1;
+
+    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
+    if (xendev == NULL) {
+        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
+        return -1;
+    }
+
+    if (xendev->ops->send) {
+        rc = xendev->ops->send(xendev, buf, count);
+    }
+
+    return rc;
+}
+
+int xen_vtpm_recv(unsigned char *buf, size_t *count)
+{
+    struct XenDevice *xendev;
+    int rc = -1;
+
+    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
+    if (xendev == NULL) {
+        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
+        return -1;
+    }
+
+    if (xendev->ops->recv) {
+        xendev->ops->recv(xendev, buf, count);
+    }
+
+    return rc;
+}
+
 /*
  * msg_level:
  *  0 == errors (stderr + logfile).
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 3b4125e..f2d5489 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -15,6 +15,8 @@ struct XenDevice;
 #define DEVOPS_FLAG_NEED_GNTDEV   1
 /* don't expect frontend doing correct state transitions (aka console quirk) */
 #define DEVOPS_FLAG_IGNORE_STATE  2
+/*dev backend is stubdom*/
+#define DEVOPS_FLAG_STUBDOM_BE    4
 
 struct XenDevOps {
     size_t    size;
@@ -26,6 +28,8 @@ struct XenDevOps {
     void      (*event)(struct XenDevice *xendev);
     void      (*disconnect)(struct XenDevice *xendev);
     int       (*free)(struct XenDevice *xendev);
+    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t count);
+    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t *count);
     void      (*backend_changed)(struct XenDevice *xendev, const char *node);
     void      (*frontend_changed)(struct XenDevice *xendev, const char *node);
 };
@@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice *xendev);
 void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...)
     GCC_FMT_ATTR(3, 4);
 
+/*Xen stubdom vtpm*/
+int xen_fe_register(const char *type, struct XenDevOps *ops);
+int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
+int xen_vtpm_send(unsigned char *buf, size_t count);
+int xen_vtpm_recv(unsigned char *buf, size_t *count);
+
 /* actual backend drivers */
 extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
 extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c */
 extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
 extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c        */
 extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c         */
+extern struct XenDevOps xen_vtpmdev_ops;      /* xen_stubdom_vtpm.c*/
 
 void xen_init_display(int domid);
 
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 95612a4..fb43084 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
     return xc_interface_open(logger, dombuild_logger, open_flags);
 }
 
+static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
+                                           unsigned int open_flags)
+{
+    return xc_gntshr_open(logger, open_flags);
+}
+
 /* FIXME There is now way to have the xen fd */
 static inline int xc_fd(xc_interface *xen_xc)
 {
diff --git a/xen-hvm.c b/xen-hvm.c
index 21f1cbb..854b8f7 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
     int i, rc;
     unsigned long ioreq_pfn;
     unsigned long bufioreq_evtchn;
+
+#ifdef CONFIG_TPM_XENSTUBDOMS
+    unsigned long stubdom_vtpm = 0;
+#endif
+
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
         fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
         return -1;
     }
+
+#ifdef CONFIG_TPM_XENSTUBDOMS
+    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
+    if (stubdom_vtpm) {
+        xen_fe_register("vtpm", &xen_vtpmdev_ops);
+    }
+#endif
+
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
-- 
1.8.3.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08: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 1XsonG-0001P6-5c; Mon, 24 Nov 2014 08:14:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XsonE-0001Nj-MM
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:14:44 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	48/EF-25714-4F8E2745; Mon, 24 Nov 2014 08:14:44 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416816881!10065857!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29262 invoked from network); 24 Nov 2014 08:14:42 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 08:14:42 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 24 Nov 2014 00:14:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,447,1413270000"; d="scan'208";a="627257428"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 24 Nov 2014 00:14:38 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun, 23 Nov 2014 23:11:03 -0500
Message-Id: <1416802263-10004-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: pbonzini@redhat.com, Quan Xu <quan.xu@intel.com>, aliguori@amazon.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [v2 4/4] Qemu-Xen-vTPM: QEMU machine class is
	initialized before tpm_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>
MIME-Version: 1.0
Content-Type: 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 sure QEMU machine class is initialized and QEMU has registered
Xen stubdom vTPM driver when call tpm_init()

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 vl.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/vl.c b/vl.c
index f6b3546..dd437e1 100644
--- a/vl.c
+++ b/vl.c
@@ -4114,12 +4114,6 @@ int main(int argc, char **argv, char **envp)
         exit(1);
     }
 
-#ifdef CONFIG_TPM
-    if (tpm_init() < 0) {
-        exit(1);
-    }
-#endif
-
     /* init the bluetooth world */
     if (foreach_device_config(DEV_BT, bt_parse))
         exit(1);
@@ -4225,6 +4219,16 @@ int main(int argc, char **argv, char **envp)
             exit(1);
     }
 
+    /* For compatible with Xen stubdom vTPM driver, make
+     * sure QEMU machine class is initialized and QEMU has
+     * registered Xen stubdom vTPM driver ..
+    */
+#ifdef CONFIG_TPM
+    if (tpm_init() < 0) {
+        exit(1);
+    }
+#endif
+
     /* init generic devices */
     if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func, NULL, 1) != 0)
         exit(1);
-- 
1.8.3.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08: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 1XsonE-0001Ng-6s; Mon, 24 Nov 2014 08:14:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XsonC-0001N6-6u
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:14:42 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	14/9D-22819-1F8E2745; Mon, 24 Nov 2014 08:14:41 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416816879!7658777!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6698 invoked from network); 24 Nov 2014 08:14:40 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-10.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 08:14:40 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 24 Nov 2014 00:07:27 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,447,1413270000"; d="scan'208";a="627257371"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 24 Nov 2014 00:14:27 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun, 23 Nov 2014 23:10:53 -0500
Message-Id: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: lcapitulino@redhat.com, eblake@redhat.com, armbru@redhat.com,
	Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [v2 1/4] Qemu-Xen-vTPM: Support for Xen stubdom vTPM
	command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 configure        | 14 ++++++++++++++
 hmp.c            |  7 +++++++
 qapi-schema.json | 20 ++++++++++++++++++--
 qemu-options.hx  | 13 +++++++++++--
 tpm.c            |  7 ++++++-
 5 files changed, 56 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index a9e4d49..d63b8a1 100755
--- a/configure
+++ b/configure
@@ -2942,6 +2942,16 @@ else
 fi
 
 ##########################################
+# TPM xenstubdoms is only on x86 Linux
+
+if test "$targetos" = Linux && test "$cpu" = i386 -o "$cpu" = x86_64 && \
+   test "$xen" = "yes"; then
+  tpm_xenstubdoms=$tpm
+else
+  tpm_xenstubdoms=no
+fi
+
+##########################################
 # attr probe
 
 if test "$attr" != "no" ; then
@@ -4333,6 +4343,7 @@ echo "gcov              $gcov_tool"
 echo "gcov enabled      $gcov"
 echo "TPM support       $tpm"
 echo "libssh2 support   $libssh2"
+echo "TPM xenstubdoms   $tpm_xenstubdoms"
 echo "TPM passthrough   $tpm_passthrough"
 echo "QOM debugging     $qom_cast_debug"
 echo "vhdx              $vhdx"
@@ -4810,6 +4821,9 @@ if test "$tpm" = "yes"; then
   if test "$tpm_passthrough" = "yes"; then
     echo "CONFIG_TPM_PASSTHROUGH=y" >> $config_host_mak
   fi
+  if test "$tpm_xenstubdoms" = "yes"; then
+    echo "CONFIG_TPM_XENSTUBDOMS=y" >> $config_host_mak
+  fi
 fi
 
 echo "TRACE_BACKENDS=$trace_backends" >> $config_host_mak
diff --git a/hmp.c b/hmp.c
index 63d7686..1df3ec7 100644
--- a/hmp.c
+++ b/hmp.c
@@ -689,6 +689,7 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
     Error *err = NULL;
     unsigned int c = 0;
     TPMPassthroughOptions *tpo;
+    TPMXenstubdomsOptions *txo;
 
     info_list = qmp_query_tpm(&err);
     if (err) {
@@ -718,6 +719,12 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
                            tpo->has_cancel_path ? ",cancel-path=" : "",
                            tpo->has_cancel_path ? tpo->cancel_path : "");
             break;
+        case TPM_TYPE_OPTIONS_KIND_XENSTUBDOMS:
+            txo = ti->options->xenstubdoms;
+            if (!txo) {
+                monitor_printf(mon, "null TPMXenstubdomsOptions error!\n");
+            }
+            break;
         case TPM_TYPE_OPTIONS_KIND_MAX:
             break;
         }
diff --git a/qapi-schema.json b/qapi-schema.json
index 24379ab..17e9d0f 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2855,8 +2855,12 @@
 # @passthrough: TPM passthrough type
 #
 # Since: 1.5
+#
+# @xenstubdoms: TPM xenstubdoms type
+#
+# Since: 2.3
 ##
-{ 'enum': 'TpmType', 'data': [ 'passthrough' ] }
+{ 'enum': 'TpmType', 'data': [ 'passthrough', 'xenstubdoms' ] }
 
 ##
 # @query-tpm-types:
@@ -2884,6 +2888,16 @@
 { 'type': 'TPMPassthroughOptions', 'data': { '*path' : 'str',
                                              '*cancel-path' : 'str'} }
 
+# @TPMXenstubdomsOptions:
+#
+# Information about the TPM xenstubdoms type
+#
+# Since: 2.3
+##
+{ 'type': 'TPMXenstubdomsOptions', 'data': {  } }
+#
+##
+
 ##
 # @TpmTypeOptions:
 #
@@ -2894,7 +2908,9 @@
 # Since: 1.5
 ##
 { 'union': 'TpmTypeOptions',
-   'data': { 'passthrough' : 'TPMPassthroughOptions' } }
+  'data': { 'passthrough' : 'TPMPassthroughOptions',
+            'xenstubdoms' : 'TPMXenstubdomsOptions' } }
+##
 
 ##
 # @TpmInfo:
diff --git a/qemu-options.hx b/qemu-options.hx
index 1e7d5b8..fd73f57 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2485,7 +2485,8 @@ DEF("tpmdev", HAS_ARG, QEMU_OPTION_tpmdev, \
     "-tpmdev passthrough,id=id[,path=path][,cancel-path=path]\n"
     "                use path to provide path to a character device; default is /dev/tpm0\n"
     "                use cancel-path to provide path to TPM's cancel sysfs entry; if\n"
-    "                not provided it will be searched for in /sys/class/misc/tpm?/device\n",
+    "                not provided it will be searched for in /sys/class/misc/tpm?/device\n"
+    "-tpmdev xenstubdoms,id=id\n",
     QEMU_ARCH_ALL)
 STEXI
 
@@ -2495,7 +2496,8 @@ The general form of a TPM device option is:
 @item -tpmdev @var{backend} ,id=@var{id} [,@var{options}]
 @findex -tpmdev
 Backend type must be:
-@option{passthrough}.
+@option{passthrough}, or
+@option{xenstubdoms}.
 
 The specific backend type will determine the applicable options.
 The @code{-tpmdev} option creates the TPM backend and requires a
@@ -2545,6 +2547,13 @@ To create a passthrough TPM use the following two options:
 Note that the @code{-tpmdev} id is @code{tpm0} and is referenced by
 @code{tpmdev=tpm0} in the device option.
 
+To create a xenstubdoms TPM use the following two options:
+@example
+-tpmdev xenstubdoms,id=tpm0 -device tpm-tis,tpmdev=tpm0
+@end example
+Note that the @code{-tpmdev} id is @code{tpm0} and is referenced by
+@code{tpmdev=tpm0} in the device option.
+
 @end table
 
 ETEXI
diff --git a/tpm.c b/tpm.c
index c371023..ee9acb8 100644
--- a/tpm.c
+++ b/tpm.c
@@ -25,7 +25,7 @@ static QLIST_HEAD(, TPMBackend) tpm_backends =
 
 
 #define TPM_MAX_MODELS      1
-#define TPM_MAX_DRIVERS     1
+#define TPM_MAX_DRIVERS     2
 
 static TPMDriverOps const *be_drivers[TPM_MAX_DRIVERS] = {
     NULL,
@@ -256,6 +256,7 @@ static TPMInfo *qmp_query_tpm_inst(TPMBackend *drv)
 {
     TPMInfo *res = g_new0(TPMInfo, 1);
     TPMPassthroughOptions *tpo;
+    TPMXenstubdomsOptions *txo;
 
     res->id = g_strdup(drv->id);
     res->model = drv->fe_model;
@@ -275,6 +276,10 @@ static TPMInfo *qmp_query_tpm_inst(TPMBackend *drv)
             tpo->has_cancel_path = true;
         }
         break;
+    case TPM_TYPE_XENSTUBDOMS:
+        res->options->kind = TPM_TYPE_OPTIONS_KIND_XENSTUBDOMS;
+        txo = g_new0(TPMXenstubdomsOptions, 1);
+        res->options->xenstubdoms = txo;
     case TPM_TYPE_MAX:
         break;
     }
-- 
1.8.3.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08: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 1XsonE-0001OG-Op; Mon, 24 Nov 2014 08:14:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XsonD-0001NN-9i
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:14:43 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	2B/42-14214-2F8E2745; Mon, 24 Nov 2014 08:14:42 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416816879!7658777!2
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6849 invoked from network); 24 Nov 2014 08:14:41 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-10.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 08:14:41 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 24 Nov 2014 00:07:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="420689655"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 24 Nov 2014 00:04:54 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun, 23 Nov 2014 23:10:59 -0500
Message-Id: <1416802259-9965-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: stefano.stabellini@eu.citrix.com, quan.xu@intel.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [v2 3/4] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms driver.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This driver provides vTPM initialization and sending data and TPM
commends to a Xen stubdom vTPM domain.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/tpm/Makefile.objs     |   1 +
 hw/tpm/tpm_xenstubdoms.c | 238 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 239 insertions(+)
 create mode 100644 hw/tpm/tpm_xenstubdoms.c

diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 87efb01..20f0a7b 100644
--- a/hw/tpm/Makefile.objs
+++ b/hw/tpm/Makefile.objs
@@ -1,3 +1,4 @@
 common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
 common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o
 common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
new file mode 100644
index 0000000..845df18
--- /dev/null
+++ b/hw/tpm/tpm_xenstubdoms.c
@@ -0,0 +1,238 @@
+/*
+ * Xen Stubdom vTPM driver
+ *
+ *  Copyright (c) 2014 Intel Corporation
+ *  Authors:
+ *    Quan Xu <quan.xu@intel.com>
+ *
+ * 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 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, see <http://www.gnu.org/licenses/>
+ */
+
+#include <dirent.h>
+#include "qemu-common.h"
+#include "qapi/error.h"
+#include "qemu/sockets.h"
+#include "qemu/log.h"
+#include "sysemu/tpm_backend.h"
+#include "tpm_int.h"
+#include "hw/hw.h"
+#include "hw/i386/pc.h"
+#include "hw/xen/xen_backend.h"
+#include "sysemu/tpm_backend_int.h"
+#include "tpm_tis.h"
+
+#ifdef DEBUG_TPM
+#define DPRINTF(fmt, ...) \
+    do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+    do { } while (0)
+#endif
+
+#define TYPE_TPM_XENSTUBDOMS "tpm-xenstubdoms"
+#define TPM_XENSTUBDOMS(obj) \
+    OBJECT_CHECK(TPMXenstubdomsState, (obj), TYPE_TPM_XENSTUBDOMS)
+
+static const TPMDriverOps tpm_xenstubdoms_driver;
+
+/* data structures */
+typedef struct TPMXenstubdomsThreadParams {
+    TPMState *tpm_state;
+    TPMRecvDataCB *recv_data_callback;
+    TPMBackend *tb;
+} TPMXenstubdomsThreadParams;
+
+struct TPMXenstubdomsState {
+    TPMBackend parent;
+    TPMBackendThread tbt;
+    TPMXenstubdomsThreadParams tpm_thread_params;
+    bool had_startup_error;
+};
+
+typedef struct TPMXenstubdomsState TPMXenstubdomsState;
+
+/* functions */
+
+static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb);
+
+static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
+{
+    size_t rlen;
+    xen_vtpm_send(locty_data->w_buffer.buffer, locty_data->w_offset);
+    xen_vtpm_recv(locty_data->r_buffer.buffer, &rlen);
+    return 0;
+}
+
+static void tpm_xenstubdoms_worker_thread(gpointer data,
+                                          gpointer user_data)
+{
+    TPMXenstubdomsThreadParams *thr_parms = user_data;
+    TPMBackendCmd cmd = (TPMBackendCmd)data;
+
+    switch (cmd) {
+    case TPM_BACKEND_CMD_PROCESS_CMD:
+        /* here need a the cmd process function */
+        tpm_xenstubdoms_unix_transfer(thr_parms->tpm_state->locty_data);
+        thr_parms->recv_data_callback(thr_parms->tpm_state,
+                                      thr_parms->tpm_state->locty_number);
+        break;
+    case TPM_BACKEND_CMD_INIT:
+    case TPM_BACKEND_CMD_END:
+    case TPM_BACKEND_CMD_TPM_RESET:
+        /* nothing to do */
+        break;
+    }
+}
+
+/*
+ *  * Start the TPM (thread). If it had been started before, then terminate
+ *   * and start it again.
+ *    */
+static int tpm_xenstubdoms_startup_tpm(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_backend_thread_tpm_reset(&tpm_xs->tbt, tpm_xenstubdoms_worker_thread,
+                                 &tpm_xs->tpm_thread_params);
+
+    return 0;
+}
+
+static void tpm_xenstubdoms_reset(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_backend_thread_end(&tpm_xs->tbt);
+    tpm_xs->had_startup_error = false;
+}
+
+static int tpm_xenstubdoms_init(TPMBackend *tb, TPMState *s,
+                                TPMRecvDataCB *recv_data_cb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    tpm_xs->tpm_thread_params.tpm_state = s;
+    tpm_xs->tpm_thread_params.recv_data_callback = recv_data_cb;
+    tpm_xs->tpm_thread_params.tb = tb;
+    return 0;
+}
+
+static bool tpm_xenstubdoms_get_tpm_established_flag(TPMBackend *tb)
+{
+    return false;
+}
+
+static bool tpm_xenstubdoms_get_startup_error(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+
+    return tpm_xs->had_startup_error;
+}
+
+static size_t tpm_xenstubdoms_realloc_buffer(TPMSizedBuffer *sb)
+{
+    size_t wanted_size = 4096; /* Linux tpm.c buffer size */
+
+    if (sb->size != wanted_size) {
+        sb->buffer = g_realloc(sb->buffer, wanted_size);
+        sb->size = wanted_size;
+    }
+    return sb->size;
+}
+
+static void tpm_xenstubdoms_deliver_request(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
+    tpm_backend_thread_deliver_request(&tpm_xs->tbt);
+}
+
+static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb)
+{
+}
+
+static const char *tpm_xenstubdoms_create_desc(void)
+{
+    return "Xenstubdoms TPM backend driver";
+}
+
+static TPMBackend *tpm_xenstubdoms_create(QemuOpts *opts, const char *id)
+{
+    Object *obj = object_new(TYPE_TPM_XENSTUBDOMS);
+    TPMBackend *tb = TPM_BACKEND(obj);
+
+    tb->id = g_strdup(id);
+    tb->fe_model = -1;
+    tb->ops = &tpm_xenstubdoms_driver;
+    return tb;
+}
+
+static void tpm_xenstubdoms_destroy(TPMBackend *tb)
+{
+    TPMXenstubdomsState *tpm_xh = TPM_XENSTUBDOMS(tb);
+    tpm_backend_thread_end(&tpm_xh->tbt);
+
+    g_free(tb->id);
+}
+
+static const QemuOptDesc tpm_xenstubdoms_cmdline_opts[] = {
+    TPM_STANDARD_CMDLINE_OPTS,
+    {},
+};
+
+static const TPMDriverOps tpm_xenstubdoms_driver = {
+    .type                     = TPM_TYPE_XENSTUBDOMS,
+    .opts                     = tpm_xenstubdoms_cmdline_opts,
+    .desc                     = tpm_xenstubdoms_create_desc,
+    .create                   = tpm_xenstubdoms_create,
+    .destroy                  = tpm_xenstubdoms_destroy,
+    .init                     = tpm_xenstubdoms_init,
+    .startup_tpm              = tpm_xenstubdoms_startup_tpm,
+    .realloc_buffer           = tpm_xenstubdoms_realloc_buffer,
+    .reset                    = tpm_xenstubdoms_reset,
+    .had_startup_error        = tpm_xenstubdoms_get_startup_error,
+    .deliver_request          = tpm_xenstubdoms_deliver_request,
+    .cancel_cmd               = tpm_xenstubdoms_cancel_cmd,
+    .get_tpm_established_flag = tpm_xenstubdoms_get_tpm_established_flag,
+};
+
+static void tpm_xenstubdoms_inst_init(Object *obj)
+{
+}
+
+static void tpm_xenstubdoms_inst_finalize(Object *obj)
+{
+}
+
+static void tpm_xenstubdoms_class_init(ObjectClass *klass, void *data)
+{
+    TPMBackendClass *tbc = TPM_BACKEND_CLASS(klass);
+    tbc->ops = &tpm_xenstubdoms_driver;
+}
+
+static const TypeInfo tpm_xenstubdoms_info = {
+    .name = TYPE_TPM_XENSTUBDOMS,
+    .parent = TYPE_TPM_BACKEND,
+    .instance_size = sizeof(TPMXenstubdomsState),
+    .class_init = tpm_xenstubdoms_class_init,
+    .instance_init = tpm_xenstubdoms_inst_init,
+    .instance_finalize = tpm_xenstubdoms_inst_finalize,
+};
+
+static void tpm_xenstubdoms_register(void)
+{
+    type_register_static(&tpm_xenstubdoms_info);
+    tpm_register_driver(&tpm_xenstubdoms_driver);
+}
+
+type_init(tpm_xenstubdoms_register)
-- 
1.8.3.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08: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 1XsonG-0001P6-5c; Mon, 24 Nov 2014 08:14:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XsonE-0001Nj-MM
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:14:44 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	48/EF-25714-4F8E2745; Mon, 24 Nov 2014 08:14:44 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416816881!10065857!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29262 invoked from network); 24 Nov 2014 08:14:42 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 08:14:42 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 24 Nov 2014 00:14:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,447,1413270000"; d="scan'208";a="627257428"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 24 Nov 2014 00:14:38 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Sun, 23 Nov 2014 23:11:03 -0500
Message-Id: <1416802263-10004-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: pbonzini@redhat.com, Quan Xu <quan.xu@intel.com>, aliguori@amazon.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [v2 4/4] Qemu-Xen-vTPM: QEMU machine class is
	initialized before tpm_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>
MIME-Version: 1.0
Content-Type: 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 sure QEMU machine class is initialized and QEMU has registered
Xen stubdom vTPM driver when call tpm_init()

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 vl.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/vl.c b/vl.c
index f6b3546..dd437e1 100644
--- a/vl.c
+++ b/vl.c
@@ -4114,12 +4114,6 @@ int main(int argc, char **argv, char **envp)
         exit(1);
     }
 
-#ifdef CONFIG_TPM
-    if (tpm_init() < 0) {
-        exit(1);
-    }
-#endif
-
     /* init the bluetooth world */
     if (foreach_device_config(DEV_BT, bt_parse))
         exit(1);
@@ -4225,6 +4219,16 @@ int main(int argc, char **argv, char **envp)
             exit(1);
     }
 
+    /* For compatible with Xen stubdom vTPM driver, make
+     * sure QEMU machine class is initialized and QEMU has
+     * registered Xen stubdom vTPM driver ..
+    */
+#ifdef CONFIG_TPM
+    if (tpm_init() < 0) {
+        exit(1);
+    }
+#endif
+
     /* init generic devices */
     if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func, NULL, 1) != 0)
         exit(1);
-- 
1.8.3.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:15:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:15:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsonf-0001ao-Jh; Mon, 24 Nov 2014 08:15: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@citrix.com>) id 1Xsone-0001a6-5H
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 08:15:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5E/68-15461-D09E2745; Mon, 24 Nov 2014 08:15:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416816907!12048388!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10132 invoked from network); 24 Nov 2014 08:15:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 08:15:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="195968951"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 03:15:06 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xsona-0002aP-4t;
	Mon, 24 Nov 2014 08:15:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsonZ-0002Vl-TQ;
	Mon, 24 Nov 2014 08:15:05 +0000
Date: Mon, 24 Nov 2014 08:15:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31778-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31778: 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 31778 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31778/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair           7 xen-boot/src_host            fail   like 31630
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31630

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  dc37cab1d0f567639f52cad654068a7e56652e2e
baseline version:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.2-testing
+ revision=dc37cab1d0f567639f52cad654068a7e56652e2e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing dc37cab1d0f567639f52cad654068a7e56652e2e
+ branch=xen-4.2-testing
+ revision=dc37cab1d0f567639f52cad654068a7e56652e2e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.2-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.2-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.2-testing
+ xenversion=xen-4.2
+ xenversion=4.2
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git dc37cab1d0f567639f52cad654068a7e56652e2e:stable-4.2
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   c844974..dc37cab  dc37cab1d0f567639f52cad654068a7e56652e2e -> stable-4.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:15:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:15:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsonf-0001ao-Jh; Mon, 24 Nov 2014 08:15: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@citrix.com>) id 1Xsone-0001a6-5H
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 08:15:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5E/68-15461-D09E2745; Mon, 24 Nov 2014 08:15:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416816907!12048388!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10132 invoked from network); 24 Nov 2014 08:15:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 08:15:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="195968951"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 03:15:06 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xsona-0002aP-4t;
	Mon, 24 Nov 2014 08:15:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsonZ-0002Vl-TQ;
	Mon, 24 Nov 2014 08:15:05 +0000
Date: Mon, 24 Nov 2014 08:15:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31778-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31778: 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 31778 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31778/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair           7 xen-boot/src_host            fail   like 31630
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31630

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  dc37cab1d0f567639f52cad654068a7e56652e2e
baseline version:
 xen                  c844974caf1501b6527533ab2a3d27ea8920ab90

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.2-testing
+ revision=dc37cab1d0f567639f52cad654068a7e56652e2e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing dc37cab1d0f567639f52cad654068a7e56652e2e
+ branch=xen-4.2-testing
+ revision=dc37cab1d0f567639f52cad654068a7e56652e2e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.2-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.2-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.2-testing
+ xenversion=xen-4.2
+ xenversion=4.2
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git dc37cab1d0f567639f52cad654068a7e56652e2e:stable-4.2
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   c844974..dc37cab  dc37cab1d0f567639f52cad654068a7e56652e2e -> stable-4.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:46:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:46:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspGx-0002Ot-5V; Mon, 24 Nov 2014 08:45:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XspGw-0002Oo-8X
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:45:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	44/8A-15461-520F2745; Mon, 24 Nov 2014 08:45:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416818725!14800457!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1141 invoked from network); 24 Nov 2014 08:45:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 08:45:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 08:45:24 +0000
Message-Id: <5472FE31020000780004A2D5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 08:45:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
In-Reply-To: <54713848.3020401@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 02:28, <sflist@ihonk.com> wrote:
> With mwait-idle=0:
> 
> (XEN) 'c' pressed -> printing ACPI Cx structures
> (XEN) ==cpu0==
> (XEN) active state:             C0
> (XEN) max_cstate:               C7
> (XEN) states:
> (XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
> duration[0]
> (XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
> duration[0]
> (XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
> duration[0]
> (XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
> duration[0]
> (XEN)    *C0:   usage[00000000] duration[46930624784]
> (XEN) PC2[0] PC3[0] PC6[0] PC7[0]
> (XEN) CC3[0] CC6[0] CC7[0]
>[...]

Very interesting - the hypervisor has C-state information, but never
entered any of them. That certainly explains the difference between
using/not using the ,wait-idle driver, but puts us back to there being
a more general issue with C-state use on this CPU model. Possibly
related to C2 having entry method "NONE", but then again I can't
see how such a state could get entered into the table the first place:
set_cx() bails upon check_cx() returning an error, and hence its
switch()'s default statement should never be reached. Plus even if an
array entry was set to "NONE", it should simply be ignored when
looking for a state to enter. I'll probably need to put together a
debugging patch to figure out what's going on here.

In any event C2 being set to "NONE" and that information presumably
coming from firmware is an indication that there's a problem with C2
(note that the numbering doesn't really match up with what the
document says, this likely really is C1E) on that CPU. Which gets us
back to ...

> CPU information for one of the cores, 2.8 GHz is nominal, stepping is 2. 
> Not sure how to translate that stepping number into Intel's format:
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5660  @ 2.80GHz
> stepping        : 2
>[...]
>> There are a couple potentially relevant errata (BC36, BC38, BC54,
>> BC77, BC110).
>>
>> To exclude BC36, a boot log with "apic-verbosity=debug" and debug
>> key 'i' output would be necessary.
> 
> Done, see the very end of the email.
> 
>> BC38 should not affect us since we don't enter C states from ISRs.
>>
>> BC54 is probably irrelevant since we meanwhile know that your
>> system doesn't really hang hard.
>>
>> For BC77 it would be worth trying to disable turbo mode instead of
>> disabling the mwait-idle driver ("xenpm disable-turbo-mode" right
>> after boot).
> 
> I looked up BC77 but as a result found this document[1], which seems to 
> relate to the i7.  Would this[2] not be the relevant document?
> 
> [1] 
> http://www.intel.com/content/dam/www/public/us/en/documents/specification-upd
> ates/core-i7-900-ee-and-desktop-processor-series-32nm-spec-update.pdf
> 
> [2] 
> http://www.intel.com/content/dam/www/public/us/en/documents/specification-upd
> ates/xeon-5600-specification-update.pdf

Indeed. I wasn't aware that there are family/model/stepping tuples
that can be both Xeon and desktop CPUs.

> As promised, below is the apic-verbosity=debug log, with 'i'. Thanks!

I'm sorry, I misspelled the option, it's really "apic_verbosity=debug".
The 'i' output at least already confirms that there are no ExtINT
entries among the IO-APIC RTEs.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:46:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:46:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspGx-0002Ot-5V; Mon, 24 Nov 2014 08:45:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XspGw-0002Oo-8X
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:45:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	44/8A-15461-520F2745; Mon, 24 Nov 2014 08:45:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416818725!14800457!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1141 invoked from network); 24 Nov 2014 08:45:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 08:45:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 08:45:24 +0000
Message-Id: <5472FE31020000780004A2D5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 08:45:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
In-Reply-To: <54713848.3020401@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 02:28, <sflist@ihonk.com> wrote:
> With mwait-idle=0:
> 
> (XEN) 'c' pressed -> printing ACPI Cx structures
> (XEN) ==cpu0==
> (XEN) active state:             C0
> (XEN) max_cstate:               C7
> (XEN) states:
> (XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
> duration[0]
> (XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
> duration[0]
> (XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
> duration[0]
> (XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
> duration[0]
> (XEN)    *C0:   usage[00000000] duration[46930624784]
> (XEN) PC2[0] PC3[0] PC6[0] PC7[0]
> (XEN) CC3[0] CC6[0] CC7[0]
>[...]

Very interesting - the hypervisor has C-state information, but never
entered any of them. That certainly explains the difference between
using/not using the ,wait-idle driver, but puts us back to there being
a more general issue with C-state use on this CPU model. Possibly
related to C2 having entry method "NONE", but then again I can't
see how such a state could get entered into the table the first place:
set_cx() bails upon check_cx() returning an error, and hence its
switch()'s default statement should never be reached. Plus even if an
array entry was set to "NONE", it should simply be ignored when
looking for a state to enter. I'll probably need to put together a
debugging patch to figure out what's going on here.

In any event C2 being set to "NONE" and that information presumably
coming from firmware is an indication that there's a problem with C2
(note that the numbering doesn't really match up with what the
document says, this likely really is C1E) on that CPU. Which gets us
back to ...

> CPU information for one of the cores, 2.8 GHz is nominal, stepping is 2. 
> Not sure how to translate that stepping number into Intel's format:
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5660  @ 2.80GHz
> stepping        : 2
>[...]
>> There are a couple potentially relevant errata (BC36, BC38, BC54,
>> BC77, BC110).
>>
>> To exclude BC36, a boot log with "apic-verbosity=debug" and debug
>> key 'i' output would be necessary.
> 
> Done, see the very end of the email.
> 
>> BC38 should not affect us since we don't enter C states from ISRs.
>>
>> BC54 is probably irrelevant since we meanwhile know that your
>> system doesn't really hang hard.
>>
>> For BC77 it would be worth trying to disable turbo mode instead of
>> disabling the mwait-idle driver ("xenpm disable-turbo-mode" right
>> after boot).
> 
> I looked up BC77 but as a result found this document[1], which seems to 
> relate to the i7.  Would this[2] not be the relevant document?
> 
> [1] 
> http://www.intel.com/content/dam/www/public/us/en/documents/specification-upd
> ates/core-i7-900-ee-and-desktop-processor-series-32nm-spec-update.pdf
> 
> [2] 
> http://www.intel.com/content/dam/www/public/us/en/documents/specification-upd
> ates/xeon-5600-specification-update.pdf

Indeed. I wasn't aware that there are family/model/stepping tuples
that can be both Xeon and desktop CPUs.

> As promised, below is the apic-verbosity=debug log, with 'i'. Thanks!

I'm sorry, I misspelled the option, it's really "apic_verbosity=debug".
The 'i' output at least already confirms that there are no ExtINT
entries among the IO-APIC RTEs.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:52:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspNl-0002cF-90; Mon, 24 Nov 2014 08:52:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XspNj-0002cA-Nn
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:52:27 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	C0/A2-14214-BC1F2745; Mon, 24 Nov 2014 08:52:27 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416819143!12937590!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28978 invoked from network); 24 Nov 2014 08:52:23 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 08:52:23 -0000
Received: by mail-wi0-f178.google.com with SMTP id hi2so4907936wib.11
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 00:52:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=cqTsn0WK8crEsPz7U+n8fXmUNw+Ojl3Q9juT1IFoH1k=;
	b=FJ5LCqHr4aqLrPFMGtNsOiBd7fpDDNFWVvPhv63NWlSJ0XmiN+4OjPvXp6GF/d15FZ
	G8zokDVKuLpPiYEm7G+IS11krBgzY8M6HOjsYWlJgH85nIxTT/XQZcTMlBIoooQIhr42
	Sl2mNytFizGdwhIqIuLeGaYc8J1OpCXLWyJk7qkV1TV/i0KXwxmVB2RE1e3kM4g4weno
	hh6k+d1v0fFmZcwV3T65IJiQH5glrbKFdr9Z4t5keuoqwDeWK+lILjayPviGi5DrOBYv
	dcUr8bJDP2zaqoOqh5KGAhl/Q8w3nShhOHNgPfm4jn0L7UUkZGNX+PmsbrlE10H7/vXo
	gX4g==
X-Gm-Message-State: ALoCoQmtXK2Q5xce1rQYT0fAUVViYrPYwKuUTwywo+WOSMH0SQozXf72dhUEV3NluMQABsBBza+p
X-Received: by 10.180.206.4 with SMTP id lk4mr19803894wic.47.1416819143059;
	Mon, 24 Nov 2014 00:52:23 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	bj7sm20032091wjc.33.2014.11.24.00.52.21 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 24 Nov 2014 00:52:22 -0800 (PST)
Message-ID: <5472F1DA.4080508@m2r.biz>
Date: Mon, 24 Nov 2014 09:52:42 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Wen Congyang <wency@cn.fujitsu.com>, xen devel <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
References: <547290D7.2020506@cn.fujitsu.com>
In-Reply-To: <547290D7.2020506@cn.fujitsu.com>
Cc: anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 24/11/2014 02:58, Wen Congyang ha scritto:
> When I try to use virtio on xen(HVM guest), qemu crashed. Here is the backtrace:
> (gdb) bt
> #0  0x00007f49581f0b55 in raise () from /lib64/libc.so.6
> #1  0x00007f49581f2131 in abort () from /lib64/libc.so.6
> #2  0x00007f495af2af32 in xen_ram_addr_from_mapcache (ptr=0x7f4951858ac8) at /root/work/xen/tools/qemu-xen-dir/xen-mapcache.c:316
> #3  0x00007f495ae30fb3 in qemu_ram_addr_from_host (ptr=0x7f4951858ac8, ram_addr=0x7fff564dc9b0) at /root/work/xen/tools/qemu-xen-dir/exec.c:1508
> #4  0x00007f495ae33424 in address_space_unmap (as=0x7f495b7c3520, buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2315
> #5  0x00007f495ae335b3 in cpu_physical_memory_unmap (buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2353
> #6  0x00007f495ae9058d in virtqueue_fill (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1, idx=0) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:258
> #7  0x00007f495ae90a0d in virtqueue_push (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:286
> #8  0x00007f495ae82cf3 in virtio_net_handle_ctrl (vdev=0x7f495b92a5d0, vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/net/virtio-net.c:806
> #9  0x00007f495ae925e5 in virtio_queue_notify_vq (vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:729
> #10 0x00007f495ae926c3 in virtio_queue_notify (vdev=0x7f495b92a5d0, n=2) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:735
> #11 0x00007f495ad743c2 in virtio_ioport_write (opaque=0x7f495b929cd0, addr=16, val=2) at hw/virtio/virtio-pci.c:301
> #12 0x00007f495ad74923 in virtio_pci_config_write (opaque=0x7f495b929cd0, addr=16, val=2, size=2) at hw/virtio/virtio-pci.c:433
> #13 0x00007f495ae9f071 in memory_region_write_accessor (mr=0x7f495b92a468, addr=16, value=0x7fff564e8d08, size=2, shift=0, mask=65535) at /root/work/xen/tools/qemu-xen-dir/memory.c:441
> #14 0x00007f495ae9f1ad in access_with_adjusted_size (addr=16, value=0x7fff564e8d08, size=2, access_size_min=1, access_size_max=4, access=0x7f495ae9efe8 <memory_region_write_accessor>, mr=0x7f495b92a468)
>      at /root/work/xen/tools/qemu-xen-dir/memory.c:478
> #15 0x00007f495aea200e in memory_region_dispatch_write (mr=0x7f495b92a468, addr=16, data=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:985
> #16 0x00007f495aea5824 in io_mem_write (mr=0x7f495b92a468, addr=16, val=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:1744
> #17 0x00007f495ae328d3 in address_space_rw (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2, is_write=true) at /root/work/xen/tools/qemu-xen-dir/exec.c:2029
> #18 0x00007f495ae32c85 in address_space_write (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2) at /root/work/xen/tools/qemu-xen-dir/exec.c:2091
> #19 0x00007f495ae9c130 in cpu_outw (addr=49200, val=2) at /root/work/xen/tools/qemu-xen-dir/ioport.c:77
> #20 0x00007f495af289d0 in do_outp (addr=49200, size=2, val=2) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:668
> #21 0x00007f495af28b94 in cpu_ioreq_pio (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:729
> #22 0x00007f495af28ee5 in handle_ioreq (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:781
> #23 0x00007f495af29237 in cpu_handle_ioreq (opaque=0x7f495b884ad0) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:856
> #24 0x00007f495ad7d2c2 in qemu_iohandler_poll (pollfds=0x7f495b823820, ret=1) at iohandler.c:143
> #25 0x00007f495ad7e2fd in main_loop_wait (nonblocking=0) at main-loop.c:485
> #26 0x00007f495ae1386f in main_loop () at vl.c:2056
> #27 0x00007f495ae1af17 in main (argc=35, argv=0x7fff564e94c8, envp=0x7fff564e95e8) at vl.c:4535
> (gdb) q
>
>
Added qemu-devel and qemu maintainer in xen to cc.

@Wen Congyang: when you report a bug is useful add more details and 
logs, domU's xl cfg, domU's qemu log, xen and qemu version used ecc...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:52:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspNl-0002cF-90; Mon, 24 Nov 2014 08:52:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XspNj-0002cA-Nn
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 08:52:27 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	C0/A2-14214-BC1F2745; Mon, 24 Nov 2014 08:52:27 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416819143!12937590!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28978 invoked from network); 24 Nov 2014 08:52:23 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 08:52:23 -0000
Received: by mail-wi0-f178.google.com with SMTP id hi2so4907936wib.11
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 00:52:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=cqTsn0WK8crEsPz7U+n8fXmUNw+Ojl3Q9juT1IFoH1k=;
	b=FJ5LCqHr4aqLrPFMGtNsOiBd7fpDDNFWVvPhv63NWlSJ0XmiN+4OjPvXp6GF/d15FZ
	G8zokDVKuLpPiYEm7G+IS11krBgzY8M6HOjsYWlJgH85nIxTT/XQZcTMlBIoooQIhr42
	Sl2mNytFizGdwhIqIuLeGaYc8J1OpCXLWyJk7qkV1TV/i0KXwxmVB2RE1e3kM4g4weno
	hh6k+d1v0fFmZcwV3T65IJiQH5glrbKFdr9Z4t5keuoqwDeWK+lILjayPviGi5DrOBYv
	dcUr8bJDP2zaqoOqh5KGAhl/Q8w3nShhOHNgPfm4jn0L7UUkZGNX+PmsbrlE10H7/vXo
	gX4g==
X-Gm-Message-State: ALoCoQmtXK2Q5xce1rQYT0fAUVViYrPYwKuUTwywo+WOSMH0SQozXf72dhUEV3NluMQABsBBza+p
X-Received: by 10.180.206.4 with SMTP id lk4mr19803894wic.47.1416819143059;
	Mon, 24 Nov 2014 00:52:23 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	bj7sm20032091wjc.33.2014.11.24.00.52.21 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 24 Nov 2014 00:52:22 -0800 (PST)
Message-ID: <5472F1DA.4080508@m2r.biz>
Date: Mon, 24 Nov 2014 09:52:42 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Wen Congyang <wency@cn.fujitsu.com>, xen devel <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
References: <547290D7.2020506@cn.fujitsu.com>
In-Reply-To: <547290D7.2020506@cn.fujitsu.com>
Cc: anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 24/11/2014 02:58, Wen Congyang ha scritto:
> When I try to use virtio on xen(HVM guest), qemu crashed. Here is the backtrace:
> (gdb) bt
> #0  0x00007f49581f0b55 in raise () from /lib64/libc.so.6
> #1  0x00007f49581f2131 in abort () from /lib64/libc.so.6
> #2  0x00007f495af2af32 in xen_ram_addr_from_mapcache (ptr=0x7f4951858ac8) at /root/work/xen/tools/qemu-xen-dir/xen-mapcache.c:316
> #3  0x00007f495ae30fb3 in qemu_ram_addr_from_host (ptr=0x7f4951858ac8, ram_addr=0x7fff564dc9b0) at /root/work/xen/tools/qemu-xen-dir/exec.c:1508
> #4  0x00007f495ae33424 in address_space_unmap (as=0x7f495b7c3520, buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2315
> #5  0x00007f495ae335b3 in cpu_physical_memory_unmap (buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2353
> #6  0x00007f495ae9058d in virtqueue_fill (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1, idx=0) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:258
> #7  0x00007f495ae90a0d in virtqueue_push (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:286
> #8  0x00007f495ae82cf3 in virtio_net_handle_ctrl (vdev=0x7f495b92a5d0, vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/net/virtio-net.c:806
> #9  0x00007f495ae925e5 in virtio_queue_notify_vq (vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:729
> #10 0x00007f495ae926c3 in virtio_queue_notify (vdev=0x7f495b92a5d0, n=2) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:735
> #11 0x00007f495ad743c2 in virtio_ioport_write (opaque=0x7f495b929cd0, addr=16, val=2) at hw/virtio/virtio-pci.c:301
> #12 0x00007f495ad74923 in virtio_pci_config_write (opaque=0x7f495b929cd0, addr=16, val=2, size=2) at hw/virtio/virtio-pci.c:433
> #13 0x00007f495ae9f071 in memory_region_write_accessor (mr=0x7f495b92a468, addr=16, value=0x7fff564e8d08, size=2, shift=0, mask=65535) at /root/work/xen/tools/qemu-xen-dir/memory.c:441
> #14 0x00007f495ae9f1ad in access_with_adjusted_size (addr=16, value=0x7fff564e8d08, size=2, access_size_min=1, access_size_max=4, access=0x7f495ae9efe8 <memory_region_write_accessor>, mr=0x7f495b92a468)
>      at /root/work/xen/tools/qemu-xen-dir/memory.c:478
> #15 0x00007f495aea200e in memory_region_dispatch_write (mr=0x7f495b92a468, addr=16, data=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:985
> #16 0x00007f495aea5824 in io_mem_write (mr=0x7f495b92a468, addr=16, val=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:1744
> #17 0x00007f495ae328d3 in address_space_rw (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2, is_write=true) at /root/work/xen/tools/qemu-xen-dir/exec.c:2029
> #18 0x00007f495ae32c85 in address_space_write (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2) at /root/work/xen/tools/qemu-xen-dir/exec.c:2091
> #19 0x00007f495ae9c130 in cpu_outw (addr=49200, val=2) at /root/work/xen/tools/qemu-xen-dir/ioport.c:77
> #20 0x00007f495af289d0 in do_outp (addr=49200, size=2, val=2) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:668
> #21 0x00007f495af28b94 in cpu_ioreq_pio (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:729
> #22 0x00007f495af28ee5 in handle_ioreq (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:781
> #23 0x00007f495af29237 in cpu_handle_ioreq (opaque=0x7f495b884ad0) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:856
> #24 0x00007f495ad7d2c2 in qemu_iohandler_poll (pollfds=0x7f495b823820, ret=1) at iohandler.c:143
> #25 0x00007f495ad7e2fd in main_loop_wait (nonblocking=0) at main-loop.c:485
> #26 0x00007f495ae1386f in main_loop () at vl.c:2056
> #27 0x00007f495ae1af17 in main (argc=35, argv=0x7fff564e94c8, envp=0x7fff564e95e8) at vl.c:4535
> (gdb) q
>
>
Added qemu-devel and qemu maintainer in xen to cc.

@Wen Congyang: when you report a bug is useful add more details and 
logs, domU's xl cfg, domU's qemu log, xen and qemu version used ecc...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:58:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspTH-0002kU-1H; Mon, 24 Nov 2014 08:58:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XspTG-0002kP-36
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 08:58:10 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	53/C1-02576-123F2745; Mon, 24 Nov 2014 08:58:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416819488!9740531!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23672 invoked from network); 24 Nov 2014 08:58:08 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 08:58:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 08:58:08 +0000
Message-Id: <5473012D020000780004A2E6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 08:58:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
	<20141121151407.GD2886@laptop.dumpdata.com>
	<546F6E890200007800049DF9@mail.emea.novell.com>
	<20141121164513.GA6798@laptop.dumpdata.com>
In-Reply-To: <20141121164513.GA6798@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 17:45, <konrad.wilk@oracle.com> wrote:
> From 90d00db0949a8e796d7f812134753a54b2fe3d51 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Thu, 20 Nov 2014 14:28:11 -0500
> Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to 
> process.

So am I right in understanding that this is then the only thing that
needs to go into the tree to fix Sander's problem? No zombie state
anymore?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 08:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 08:58:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspTH-0002kU-1H; Mon, 24 Nov 2014 08:58:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XspTG-0002kP-36
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 08:58:10 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	53/C1-02576-123F2745; Mon, 24 Nov 2014 08:58:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416819488!9740531!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23672 invoked from network); 24 Nov 2014 08:58:08 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 08:58:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 08:58:08 +0000
Message-Id: <5473012D020000780004A2E6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 08:58:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
	<20141121151407.GD2886@laptop.dumpdata.com>
	<546F6E890200007800049DF9@mail.emea.novell.com>
	<20141121164513.GA6798@laptop.dumpdata.com>
In-Reply-To: <20141121164513.GA6798@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
 to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 17:45, <konrad.wilk@oracle.com> wrote:
> From 90d00db0949a8e796d7f812134753a54b2fe3d51 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Thu, 20 Nov 2014 14:28:11 -0500
> Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to 
> process.

So am I right in understanding that this is then the only thing that
needs to go into the tree to fix Sander's problem? No zombie state
anymore?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:09:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09: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 1Xspdl-0002z6-GK; Mon, 24 Nov 2014 09:09:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xspdk-0002z1-8Z
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:09:00 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	29/A0-03145-BA5F2745; Mon, 24 Nov 2014 09:08:59 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416820137!14386567!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18496 invoked from network); 24 Nov 2014 09:08:58 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 09:08:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416820136; h=Received :
	Content-Type : Mime-Version : Subject : From : X-Mailer : In-Reply-To :
	Date : Cc : Content-Transfer-Encoding : Message-Id : References : To;
	bh=usHtpv9T1/j5gKOdC1kxm1VACBC34zxuMBF5rvS3pPY=;
	b=eKK8x+2s66j7E9ACsOc5KF88vHp3tmMNGxKnc6N/zWU0edrGbDZD9ghlQgZy3FJoug39fTR9fXY/VisuLRRYF+d6gMaJHWmNkdGgfp35NxNqgyZnD2eRegFk0lAETUHk1Qx176hLpqcpJJLpddPSgMBhOx79Xu89vGbDHendWX0=
Received: from [10.0.0.195] ([::ffff:174.65.75.5])
	(AUTH: PLAIN sflist@ihonk.com, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by wapdot.org with ESMTPSA; Mon, 24 Nov 2014 01:08:56 -0800
	id 00000000000304B8.5472F5A8.0000231F
Mime-Version: 1.0 (1.0)
From: Steve Freitas <sflist@ihonk.com>
X-Mailer: iPhone Mail (12B435)
In-Reply-To: <5472FE31020000780004A2D5@mail.emea.novell.com>
Date: Mon, 24 Nov 2014 01:08:55 -0800
Message-Id: <7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Nov 24, 2014, at 00:45, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 23.11.14 at 02:28, <sflist@ihonk.com> wrote:
>> With mwait-idle=0:
>> 
>> (XEN) 'c' pressed -> printing ACPI Cx structures
>> (XEN) ==cpu0==
>> (XEN) active state:             C0
>> (XEN) max_cstate:               C7
>> (XEN) states:
>> (XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
>> duration[0]
>> (XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
>> duration[0]
>> (XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
>> duration[0]
>> (XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
>> duration[0]
>> (XEN)    *C0:   usage[00000000] duration[46930624784]
>> (XEN) PC2[0] PC3[0] PC6[0] PC7[0]
>> (XEN) CC3[0] CC6[0] CC7[0]
>> [...]
> 
> Very interesting - the hypervisor has C-state information, but never
> entered any of them. That certainly explains the difference between
> using/not using the ,wait-idle driver, but puts us back to there being
> a more general issue with C-state use on this CPU model. Possibly
> related to C2 having entry method "NONE", but then again I can't
> see how such a state could get entered into the table the first place:
> set_cx() bails upon check_cx() returning an error, and hence its
> switch()'s default statement should never be reached. Plus even if an
> array entry was set to "NONE", it should simply be ignored when
> looking for a state to enter. I'll probably need to put together a
> debugging patch to figure out what's going on here.
> 

Okay, happy to give it a go whenever you have the time to put something together.

> 
>> 
>> As promised, below is the apic-verbosity=debug log, with 'i'. Thanks!
> 
> I'm sorry, I misspelled the option, it's really "apic_verbosity=debug".
> The 'i' output at least already confirms that there are no ExtINT
> entries among the IO-APIC RTEs.
> 
> 

No sweat. Do you need me to run it again with the corrected option?

Thanks!

Steve
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:09:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09: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 1Xspdl-0002z6-GK; Mon, 24 Nov 2014 09:09:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xspdk-0002z1-8Z
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:09:00 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	29/A0-03145-BA5F2745; Mon, 24 Nov 2014 09:08:59 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416820137!14386567!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18496 invoked from network); 24 Nov 2014 09:08:58 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 09:08:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416820136; h=Received :
	Content-Type : Mime-Version : Subject : From : X-Mailer : In-Reply-To :
	Date : Cc : Content-Transfer-Encoding : Message-Id : References : To;
	bh=usHtpv9T1/j5gKOdC1kxm1VACBC34zxuMBF5rvS3pPY=;
	b=eKK8x+2s66j7E9ACsOc5KF88vHp3tmMNGxKnc6N/zWU0edrGbDZD9ghlQgZy3FJoug39fTR9fXY/VisuLRRYF+d6gMaJHWmNkdGgfp35NxNqgyZnD2eRegFk0lAETUHk1Qx176hLpqcpJJLpddPSgMBhOx79Xu89vGbDHendWX0=
Received: from [10.0.0.195] ([::ffff:174.65.75.5])
	(AUTH: PLAIN sflist@ihonk.com, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by wapdot.org with ESMTPSA; Mon, 24 Nov 2014 01:08:56 -0800
	id 00000000000304B8.5472F5A8.0000231F
Mime-Version: 1.0 (1.0)
From: Steve Freitas <sflist@ihonk.com>
X-Mailer: iPhone Mail (12B435)
In-Reply-To: <5472FE31020000780004A2D5@mail.emea.novell.com>
Date: Mon, 24 Nov 2014 01:08:55 -0800
Message-Id: <7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Nov 24, 2014, at 00:45, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 23.11.14 at 02:28, <sflist@ihonk.com> wrote:
>> With mwait-idle=0:
>> 
>> (XEN) 'c' pressed -> printing ACPI Cx structures
>> (XEN) ==cpu0==
>> (XEN) active state:             C0
>> (XEN) max_cstate:               C7
>> (XEN) states:
>> (XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH] 
>> duration[0]
>> (XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE] 
>> duration[0]
>> (XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH] 
>> duration[0]
>> (XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH] 
>> duration[0]
>> (XEN)    *C0:   usage[00000000] duration[46930624784]
>> (XEN) PC2[0] PC3[0] PC6[0] PC7[0]
>> (XEN) CC3[0] CC6[0] CC7[0]
>> [...]
> 
> Very interesting - the hypervisor has C-state information, but never
> entered any of them. That certainly explains the difference between
> using/not using the ,wait-idle driver, but puts us back to there being
> a more general issue with C-state use on this CPU model. Possibly
> related to C2 having entry method "NONE", but then again I can't
> see how such a state could get entered into the table the first place:
> set_cx() bails upon check_cx() returning an error, and hence its
> switch()'s default statement should never be reached. Plus even if an
> array entry was set to "NONE", it should simply be ignored when
> looking for a state to enter. I'll probably need to put together a
> debugging patch to figure out what's going on here.
> 

Okay, happy to give it a go whenever you have the time to put something together.

> 
>> 
>> As promised, below is the apic-verbosity=debug log, with 'i'. Thanks!
> 
> I'm sorry, I misspelled the option, it's really "apic_verbosity=debug".
> The 'i' output at least already confirms that there are no ExtINT
> entries among the IO-APIC RTEs.
> 
> 

No sweat. Do you need me to run it again with the corrected option?

Thanks!

Steve
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:16:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:16:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspkV-0003AZ-Bs; Mon, 24 Nov 2014 09:15:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XspkU-0003AU-7s
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:15:58 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	67/2C-14214-D47F2745; Mon, 24 Nov 2014 09:15:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416820556!12982754!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21866 invoked from network); 24 Nov 2014 09:15:57 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 09:15:57 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 09:15:56 +0000
Message-Id: <54730559020000780004A311@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 09:15:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
In-Reply-To: <7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 10:08, <sflist@ihonk.com> wrote:
> On Nov 24, 2014, at 00:45, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 23.11.14 at 02:28, <sflist@ihonk.com> wrote:
>>> As promised, below is the apic-verbosity=debug log, with 'i'. Thanks!
>> 
>> I'm sorry, I misspelled the option, it's really "apic_verbosity=debug".
>> The 'i' output at least already confirms that there are no ExtINT
>> entries among the IO-APIC RTEs.
> 
> No sweat. Do you need me to run it again with the corrected option?

Yes please, just to be certain we can discount that one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:16:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:16:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspkV-0003AZ-Bs; Mon, 24 Nov 2014 09:15:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XspkU-0003AU-7s
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:15:58 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	67/2C-14214-D47F2745; Mon, 24 Nov 2014 09:15:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416820556!12982754!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21866 invoked from network); 24 Nov 2014 09:15:57 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 09:15:57 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 09:15:56 +0000
Message-Id: <54730559020000780004A311@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 09:15:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
In-Reply-To: <7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 10:08, <sflist@ihonk.com> wrote:
> On Nov 24, 2014, at 00:45, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 23.11.14 at 02:28, <sflist@ihonk.com> wrote:
>>> As promised, below is the apic-verbosity=debug log, with 'i'. Thanks!
>> 
>> I'm sorry, I misspelled the option, it's really "apic_verbosity=debug".
>> The 'i' output at least already confirms that there are no ExtINT
>> entries among the IO-APIC RTEs.
> 
> No sweat. Do you need me to run it again with the corrected option?

Yes please, just to be certain we can discount that one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:17:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09: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 1Xspld-0003Eh-Pw; Mon, 24 Nov 2014 09:17:09 +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 1Xsplc-0003ER-0s
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:17:08 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	55/A3-18267-397F2745; Mon, 24 Nov 2014 09:17:07 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416820625!13367994!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24701 invoked from network); 24 Nov 2014 09:17:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 09:17:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="195982910"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 04:17:04 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsplY-00026n-79;
	Mon, 24 Nov 2014 09:17:04 +0000
Date: Mon, 24 Nov 2014 09:17:04 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141124091704.GA30053@zion.uk.xensource.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
	<20141119210154.GB20440@laptop.dumpdata.com>
	<20141119212123.GA27349@zion.uk.xensource.com>
	<20141119212853.GM20440@laptop.dumpdata.com>
	<1416499060.14429.33.camel@citrix.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A68BC9@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A68BC9@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, "Li,
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 08:13:16AM +0000, Hu, Robert wrote:
[...]
> 
> > Applied.

> Hi, I'm new here. Shall I ask where does this patch apply to? shall I

http://xenbits.xen.org/gitweb/?p=xen.git;a=summary

Patches are applied to staging branch and then pushed to master branch
after they pass tests.

> expect to see this issue fixed in Xen 4.5-RC3?

Yes.

Wei.

> > 
> > 
> > 
> > _______________________________________________ Xen-devel mailing
> > list Xen-devel@lists.xen.org http://lists.xen.org/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 Nov 24 09:17:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09: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 1Xspld-0003Eh-Pw; Mon, 24 Nov 2014 09:17:09 +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 1Xsplc-0003ER-0s
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:17:08 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	55/A3-18267-397F2745; Mon, 24 Nov 2014 09:17:07 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1416820625!13367994!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24701 invoked from network); 24 Nov 2014 09:17:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 09:17:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="195982910"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 04:17:04 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsplY-00026n-79;
	Mon, 24 Nov 2014 09:17:04 +0000
Date: Mon, 24 Nov 2014 09:17:04 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141124091704.GA30053@zion.uk.xensource.com>
References: <1416226234-30743-1-git-send-email-wei.liu2@citrix.com>
	<20141119210154.GB20440@laptop.dumpdata.com>
	<20141119212123.GA27349@zion.uk.xensource.com>
	<20141119212853.GM20440@laptop.dumpdata.com>
	<1416499060.14429.33.camel@citrix.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A68BC9@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A68BC9@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, "Li,
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for
 PCI device hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 08:13:16AM +0000, Hu, Robert wrote:
[...]
> 
> > Applied.

> Hi, I'm new here. Shall I ask where does this patch apply to? shall I

http://xenbits.xen.org/gitweb/?p=xen.git;a=summary

Patches are applied to staging branch and then pushed to master branch
after they pass tests.

> expect to see this issue fixed in Xen 4.5-RC3?

Yes.

Wei.

> > 
> > 
> > 
> > _______________________________________________ Xen-devel mailing
> > list Xen-devel@lists.xen.org http://lists.xen.org/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 Nov 24 09:22:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xspqx-0003Tu-JJ; Mon, 24 Nov 2014 09:22: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 1Xspqv-0003Tp-La
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:22:37 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	E5/D7-25727-CD8F2745; Mon, 24 Nov 2014 09:22:36 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416820955!13230789!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 934 invoked from network); 24 Nov 2014 09:22:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 09:22:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="195132612"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 04:21:50 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XspqA-0002EX-64;
	Mon, 24 Nov 2014 09:21:50 +0000
Date: Mon, 24 Nov 2014 09:21:50 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141124092150.GB30053@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
	<20141121195631.GA16313@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141121195631.GA16313@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/19] hvmloader: disallow memory relocation
 when vNUMA is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 02:56:31PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 03:06:56PM +0000, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: George Dunlap <george.dunlap@eu.citrix.com>
> > ---
> >  tools/firmware/hvmloader/pci.c |   13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> > index 4e8d803..d7ea740 100644
> > --- a/tools/firmware/hvmloader/pci.c
> > +++ b/tools/firmware/hvmloader/pci.c
> > @@ -88,6 +88,19 @@ void pci_setup(void)
> >      printf("Relocating guest memory for lowmem MMIO space %s\n",
> >             allow_memory_relocate?"enabled":"disabled");
> >  
> > +    /* Disallow low memory relocation when vNUMA is enabled, because
> > +     * relocated memory ends up off node. Further more, even if we
> > +     * dynamically expand node coverage in hvmloader, low memory and
> > +     * high memory may reside in different physical nodes, blindly
> > +     * relocates low memory to high memory gives us a sub-optimal
> > +     * configuration.
> 
> And this is done in hvmloader, so the toolstack has no inkling that
> we need to relocate memory to make space for the PCI.
> 
> In such case I would not have this check here. Instead put it in 
> libxl 

You're right, I think this should be placed in libxl.

> and disallow vNUMA with PCI passthrough.
> 
> And then the fix is to take the logic that is in hvmloader for PCI
> BAR size relocation and move it in libxl. Then it can construct the
> proper vNUMA topology and also fix an outstanding QEMU-xen bug.
> 

But FYI not only PCI passthrough requires larger memory hole. A user can
use device_model_args_extra (don't remember the exact name) to
instrument QEMU to emulate arbitrary PCI devices.

Wei.

> > +     */
> > +    if ( hvm_info->nr_nodes != 0 && allow_memory_relocate )
> > +    {
> > +        allow_memory_relocate = false;
> > +        printf("vNUMA enabled, relocating guest memory for lowmem MMIO space disabled\n");
> > +    }
> > +
> >      s = xenstore_read("platform/mmio_hole_size", NULL);
> >      if ( s )
> >          mmio_hole_size = strtoll(s, NULL, 0);
> > -- 
> > 1.7.10.4
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:22:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xspqx-0003Tu-JJ; Mon, 24 Nov 2014 09:22: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 1Xspqv-0003Tp-La
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:22:37 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	E5/D7-25727-CD8F2745; Mon, 24 Nov 2014 09:22:36 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416820955!13230789!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 934 invoked from network); 24 Nov 2014 09:22:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 09:22:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="195132612"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 04:21:50 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XspqA-0002EX-64;
	Mon, 24 Nov 2014 09:21:50 +0000
Date: Mon, 24 Nov 2014 09:21:50 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141124092150.GB30053@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
	<20141121195631.GA16313@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141121195631.GA16313@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/19] hvmloader: disallow memory relocation
 when vNUMA is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 02:56:31PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 03:06:56PM +0000, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: George Dunlap <george.dunlap@eu.citrix.com>
> > ---
> >  tools/firmware/hvmloader/pci.c |   13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> > index 4e8d803..d7ea740 100644
> > --- a/tools/firmware/hvmloader/pci.c
> > +++ b/tools/firmware/hvmloader/pci.c
> > @@ -88,6 +88,19 @@ void pci_setup(void)
> >      printf("Relocating guest memory for lowmem MMIO space %s\n",
> >             allow_memory_relocate?"enabled":"disabled");
> >  
> > +    /* Disallow low memory relocation when vNUMA is enabled, because
> > +     * relocated memory ends up off node. Further more, even if we
> > +     * dynamically expand node coverage in hvmloader, low memory and
> > +     * high memory may reside in different physical nodes, blindly
> > +     * relocates low memory to high memory gives us a sub-optimal
> > +     * configuration.
> 
> And this is done in hvmloader, so the toolstack has no inkling that
> we need to relocate memory to make space for the PCI.
> 
> In such case I would not have this check here. Instead put it in 
> libxl 

You're right, I think this should be placed in libxl.

> and disallow vNUMA with PCI passthrough.
> 
> And then the fix is to take the logic that is in hvmloader for PCI
> BAR size relocation and move it in libxl. Then it can construct the
> proper vNUMA topology and also fix an outstanding QEMU-xen bug.
> 

But FYI not only PCI passthrough requires larger memory hole. A user can
use device_model_args_extra (don't remember the exact name) to
instrument QEMU to emulate arbitrary PCI devices.

Wei.

> > +     */
> > +    if ( hvm_info->nr_nodes != 0 && allow_memory_relocate )
> > +    {
> > +        allow_memory_relocate = false;
> > +        printf("vNUMA enabled, relocating guest memory for lowmem MMIO space disabled\n");
> > +    }
> > +
> >      s = xenstore_read("platform/mmio_hole_size", NULL);
> >      if ( s )
> >          mmio_hole_size = strtoll(s, NULL, 0);
> > -- 
> > 1.7.10.4
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:23:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsprP-0003Vl-0S; Mon, 24 Nov 2014 09:23:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1XsprN-0003VY-SO
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:23:06 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	1F/69-25547-9F8F2745; Mon, 24 Nov 2014 09:23:05 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416820981!13371405!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13255 invoked from network); 24 Nov 2014 09:23:03 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-16.tower-31.messagelabs.com with SMTP;
	24 Nov 2014 09:23:03 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43880427"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 24 Nov 2014 17:19:46 +0800
Received: from G08CNEXCHPEKD01.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAO9MhQ8013322;
	Mon, 24 Nov 2014 17:22:43 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 24 Nov 2014 17:23:03 +0800
Message-ID: <5472F980.6030208@cn.fujitsu.com>
Date: Mon, 24 Nov 2014 17:25:20 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Fabio Fantoni <fabio.fantoni@m2r.biz>, xen devel <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
In-Reply-To: <5472F1DA.4080508@m2r.biz>
X-Originating-IP: [10.167.226.91]
Cc: anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu crash with virtio on Xen domUs (backtrace
	included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 04:52 PM, Fabio Fantoni wrote:
> Il 24/11/2014 02:58, Wen Congyang ha scritto:
>> When I try to use virtio on xen(HVM guest), qemu crashed. Here is the backtrace:
>> (gdb) bt
>> #0  0x00007f49581f0b55 in raise () from /lib64/libc.so.6
>> #1  0x00007f49581f2131 in abort () from /lib64/libc.so.6
>> #2  0x00007f495af2af32 in xen_ram_addr_from_mapcache (ptr=0x7f4951858ac8) at /root/work/xen/tools/qemu-xen-dir/xen-mapcache.c:316
>> #3  0x00007f495ae30fb3 in qemu_ram_addr_from_host (ptr=0x7f4951858ac8, ram_addr=0x7fff564dc9b0) at /root/work/xen/tools/qemu-xen-dir/exec.c:1508
>> #4  0x00007f495ae33424 in address_space_unmap (as=0x7f495b7c3520, buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2315
>> #5  0x00007f495ae335b3 in cpu_physical_memory_unmap (buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2353
>> #6  0x00007f495ae9058d in virtqueue_fill (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1, idx=0) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:258
>> #7  0x00007f495ae90a0d in virtqueue_push (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:286
>> #8  0x00007f495ae82cf3 in virtio_net_handle_ctrl (vdev=0x7f495b92a5d0, vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/net/virtio-net.c:806
>> #9  0x00007f495ae925e5 in virtio_queue_notify_vq (vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:729
>> #10 0x00007f495ae926c3 in virtio_queue_notify (vdev=0x7f495b92a5d0, n=2) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:735
>> #11 0x00007f495ad743c2 in virtio_ioport_write (opaque=0x7f495b929cd0, addr=16, val=2) at hw/virtio/virtio-pci.c:301
>> #12 0x00007f495ad74923 in virtio_pci_config_write (opaque=0x7f495b929cd0, addr=16, val=2, size=2) at hw/virtio/virtio-pci.c:433
>> #13 0x00007f495ae9f071 in memory_region_write_accessor (mr=0x7f495b92a468, addr=16, value=0x7fff564e8d08, size=2, shift=0, mask=65535) at /root/work/xen/tools/qemu-xen-dir/memory.c:441
>> #14 0x00007f495ae9f1ad in access_with_adjusted_size (addr=16, value=0x7fff564e8d08, size=2, access_size_min=1, access_size_max=4, access=0x7f495ae9efe8 <memory_region_write_accessor>, mr=0x7f495b92a468)
>>      at /root/work/xen/tools/qemu-xen-dir/memory.c:478
>> #15 0x00007f495aea200e in memory_region_dispatch_write (mr=0x7f495b92a468, addr=16, data=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:985
>> #16 0x00007f495aea5824 in io_mem_write (mr=0x7f495b92a468, addr=16, val=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:1744
>> #17 0x00007f495ae328d3 in address_space_rw (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2, is_write=true) at /root/work/xen/tools/qemu-xen-dir/exec.c:2029
>> #18 0x00007f495ae32c85 in address_space_write (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2) at /root/work/xen/tools/qemu-xen-dir/exec.c:2091
>> #19 0x00007f495ae9c130 in cpu_outw (addr=49200, val=2) at /root/work/xen/tools/qemu-xen-dir/ioport.c:77
>> #20 0x00007f495af289d0 in do_outp (addr=49200, size=2, val=2) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:668
>> #21 0x00007f495af28b94 in cpu_ioreq_pio (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:729
>> #22 0x00007f495af28ee5 in handle_ioreq (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:781
>> #23 0x00007f495af29237 in cpu_handle_ioreq (opaque=0x7f495b884ad0) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:856
>> #24 0x00007f495ad7d2c2 in qemu_iohandler_poll (pollfds=0x7f495b823820, ret=1) at iohandler.c:143
>> #25 0x00007f495ad7e2fd in main_loop_wait (nonblocking=0) at main-loop.c:485
>> #26 0x00007f495ae1386f in main_loop () at vl.c:2056
>> #27 0x00007f495ae1af17 in main (argc=35, argv=0x7fff564e94c8, envp=0x7fff564e95e8) at vl.c:4535
>> (gdb) q
>>
>>
> Added qemu-devel and qemu maintainer in xen to cc.
> 
> @Wen Congyang: when you report a bug is useful add more details and logs, domU's xl cfg, domU's qemu log, xen and qemu version used ecc...
> .
> 

The config file is not backuped before changing. I remember I only change vcpus and nic model.
Here is the config file:
===================================================
builder='hvm'

memory = 2048
vcpus=2
cpus="3"

name = "hvm_nopv"

disk = [ 'format=raw,devtype=disk,access=w,vdev=hda,target=/data/images/xen/hvm_nopv/suse/hvm.img'
#      , 'format=raw,devtype=disk,access=w,vdev=hdb,target=/data/images/xen/hvm_nopv/suse/hvm_data.img'
       ]

vif = [ 'mac=00:16:4f:00:00:11, bridge=br0, model=virtio-net' ]

#-----------------------------------------------------------------------------
# boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot="c"

sdl=0

vnc=1

vnclisten='0.0.0.0'

vncunused = 1

stdvga = 0

serial='pty'

apic=1
apci=1
pae=1

extid=0
keymap="en-us"
localtime=1
hpet=1

usbdevice='tablet'

xen_platform_pci=0
===================================================

qemu log(/var/log/xen/qemu-xxx):
char device redirected to /dev/pts/2 (label serial0)
xen_ram_addr_from_mapcache, could not find 0x7f267bd828e8

qemu version:
qemu-upstream-unstable:
http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=summary
commit: ca78cc83650b535d7e24baeaea32947be0141534

xl: not the newest, commit c90a755f261b8ccb3dac7e1f695122cac95c6053. I change
some codes(remus related/suspend/resume...)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:23:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsprP-0003Vl-0S; Mon, 24 Nov 2014 09:23:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1XsprN-0003VY-SO
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:23:06 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	1F/69-25547-9F8F2745; Mon, 24 Nov 2014 09:23:05 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416820981!13371405!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13255 invoked from network); 24 Nov 2014 09:23:03 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-16.tower-31.messagelabs.com with SMTP;
	24 Nov 2014 09:23:03 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43880427"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 24 Nov 2014 17:19:46 +0800
Received: from G08CNEXCHPEKD01.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAO9MhQ8013322;
	Mon, 24 Nov 2014 17:22:43 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Mon, 24 Nov 2014 17:23:03 +0800
Message-ID: <5472F980.6030208@cn.fujitsu.com>
Date: Mon, 24 Nov 2014 17:25:20 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Fabio Fantoni <fabio.fantoni@m2r.biz>, xen devel <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
In-Reply-To: <5472F1DA.4080508@m2r.biz>
X-Originating-IP: [10.167.226.91]
Cc: anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu crash with virtio on Xen domUs (backtrace
	included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 04:52 PM, Fabio Fantoni wrote:
> Il 24/11/2014 02:58, Wen Congyang ha scritto:
>> When I try to use virtio on xen(HVM guest), qemu crashed. Here is the backtrace:
>> (gdb) bt
>> #0  0x00007f49581f0b55 in raise () from /lib64/libc.so.6
>> #1  0x00007f49581f2131 in abort () from /lib64/libc.so.6
>> #2  0x00007f495af2af32 in xen_ram_addr_from_mapcache (ptr=0x7f4951858ac8) at /root/work/xen/tools/qemu-xen-dir/xen-mapcache.c:316
>> #3  0x00007f495ae30fb3 in qemu_ram_addr_from_host (ptr=0x7f4951858ac8, ram_addr=0x7fff564dc9b0) at /root/work/xen/tools/qemu-xen-dir/exec.c:1508
>> #4  0x00007f495ae33424 in address_space_unmap (as=0x7f495b7c3520, buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2315
>> #5  0x00007f495ae335b3 in cpu_physical_memory_unmap (buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2353
>> #6  0x00007f495ae9058d in virtqueue_fill (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1, idx=0) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:258
>> #7  0x00007f495ae90a0d in virtqueue_push (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:286
>> #8  0x00007f495ae82cf3 in virtio_net_handle_ctrl (vdev=0x7f495b92a5d0, vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/net/virtio-net.c:806
>> #9  0x00007f495ae925e5 in virtio_queue_notify_vq (vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:729
>> #10 0x00007f495ae926c3 in virtio_queue_notify (vdev=0x7f495b92a5d0, n=2) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:735
>> #11 0x00007f495ad743c2 in virtio_ioport_write (opaque=0x7f495b929cd0, addr=16, val=2) at hw/virtio/virtio-pci.c:301
>> #12 0x00007f495ad74923 in virtio_pci_config_write (opaque=0x7f495b929cd0, addr=16, val=2, size=2) at hw/virtio/virtio-pci.c:433
>> #13 0x00007f495ae9f071 in memory_region_write_accessor (mr=0x7f495b92a468, addr=16, value=0x7fff564e8d08, size=2, shift=0, mask=65535) at /root/work/xen/tools/qemu-xen-dir/memory.c:441
>> #14 0x00007f495ae9f1ad in access_with_adjusted_size (addr=16, value=0x7fff564e8d08, size=2, access_size_min=1, access_size_max=4, access=0x7f495ae9efe8 <memory_region_write_accessor>, mr=0x7f495b92a468)
>>      at /root/work/xen/tools/qemu-xen-dir/memory.c:478
>> #15 0x00007f495aea200e in memory_region_dispatch_write (mr=0x7f495b92a468, addr=16, data=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:985
>> #16 0x00007f495aea5824 in io_mem_write (mr=0x7f495b92a468, addr=16, val=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:1744
>> #17 0x00007f495ae328d3 in address_space_rw (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2, is_write=true) at /root/work/xen/tools/qemu-xen-dir/exec.c:2029
>> #18 0x00007f495ae32c85 in address_space_write (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2) at /root/work/xen/tools/qemu-xen-dir/exec.c:2091
>> #19 0x00007f495ae9c130 in cpu_outw (addr=49200, val=2) at /root/work/xen/tools/qemu-xen-dir/ioport.c:77
>> #20 0x00007f495af289d0 in do_outp (addr=49200, size=2, val=2) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:668
>> #21 0x00007f495af28b94 in cpu_ioreq_pio (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:729
>> #22 0x00007f495af28ee5 in handle_ioreq (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:781
>> #23 0x00007f495af29237 in cpu_handle_ioreq (opaque=0x7f495b884ad0) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:856
>> #24 0x00007f495ad7d2c2 in qemu_iohandler_poll (pollfds=0x7f495b823820, ret=1) at iohandler.c:143
>> #25 0x00007f495ad7e2fd in main_loop_wait (nonblocking=0) at main-loop.c:485
>> #26 0x00007f495ae1386f in main_loop () at vl.c:2056
>> #27 0x00007f495ae1af17 in main (argc=35, argv=0x7fff564e94c8, envp=0x7fff564e95e8) at vl.c:4535
>> (gdb) q
>>
>>
> Added qemu-devel and qemu maintainer in xen to cc.
> 
> @Wen Congyang: when you report a bug is useful add more details and logs, domU's xl cfg, domU's qemu log, xen and qemu version used ecc...
> .
> 

The config file is not backuped before changing. I remember I only change vcpus and nic model.
Here is the config file:
===================================================
builder='hvm'

memory = 2048
vcpus=2
cpus="3"

name = "hvm_nopv"

disk = [ 'format=raw,devtype=disk,access=w,vdev=hda,target=/data/images/xen/hvm_nopv/suse/hvm.img'
#      , 'format=raw,devtype=disk,access=w,vdev=hdb,target=/data/images/xen/hvm_nopv/suse/hvm_data.img'
       ]

vif = [ 'mac=00:16:4f:00:00:11, bridge=br0, model=virtio-net' ]

#-----------------------------------------------------------------------------
# boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot="c"

sdl=0

vnc=1

vnclisten='0.0.0.0'

vncunused = 1

stdvga = 0

serial='pty'

apic=1
apci=1
pae=1

extid=0
keymap="en-us"
localtime=1
hpet=1

usbdevice='tablet'

xen_platform_pci=0
===================================================

qemu log(/var/log/xen/qemu-xxx):
char device redirected to /dev/pts/2 (label serial0)
xen_ram_addr_from_mapcache, could not find 0x7f267bd828e8

qemu version:
qemu-upstream-unstable:
http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=summary
commit: ca78cc83650b535d7e24baeaea32947be0141534

xl: not the newest, commit c90a755f261b8ccb3dac7e1f695122cac95c6053. I change
some codes(remus related/suspend/resume...)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsps9-0003d7-2Q; Mon, 24 Nov 2014 09:23:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mitchelh@codeaurora.org>) id 1Xruf7-0004dB-4R
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 20:18:37 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	7A/D6-11581-C1E9F645; Fri, 21 Nov 2014 20:18:36 +0000
X-Env-Sender: mitchelh@codeaurora.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416601114!9391906!1
X-Originating-IP: [198.145.11.231]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28307 invoked from network); 21 Nov 2014 20:18:35 -0000
Received: from smtp.codeaurora.org (HELO smtp.codeaurora.org) (198.145.11.231)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 20:18:35 -0000
Received: from smtp.codeaurora.org (localhost [127.0.0.1])
	by smtp.codeaurora.org (Postfix) with ESMTP id 659AD13F90E;
	Fri, 21 Nov 2014 20:18:33 +0000 (UTC)
Received: by smtp.codeaurora.org (Postfix, from userid 486)
	id 536CA13F91F; Fri, 21 Nov 2014 20:18:33 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	pdx-caf-smtp.dmz.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham version=3.3.1
Received: from localhost (i-global254.qualcomm.com [199.106.103.254])
	(using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: mitchelh@smtp.codeaurora.org)
	by smtp.codeaurora.org (Postfix) with ESMTPSA id C96EB13F90E;
	Fri, 21 Nov 2014 20:18:32 +0000 (UTC)
From: Mitchel Humpherys <mitchelh@codeaurora.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411211147450.12596@kaball.uk.xensource.com>
Date: Fri, 21 Nov 2014 12:18:32 -0800
In-Reply-To: <alpine.DEB.2.02.1411211147450.12596@kaball.uk.xensource.com>
	(Stefano Stabellini's message of "Fri, 21 Nov 2014 11:48:33 +0000")
Message-ID: <vnkwh9xs2tpj.fsf@mitchelh-linux.qualcomm.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV using ClamSMTP
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Cc: linux-mips@linux-mips.org, airlied@linux.ie,
	dri-devel@lists.freedesktop.org, xen-devel@lists.xensource.com,
	linux@arm.linux.org.uk, vinod.koul@intel.com, deller@gmx.de,
	jejb@parisc-linux.org, dwmw2@infradead.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	dmaengine@vger.kernel.org, bhelgaas@google.com,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, ralf@linux-mips.org,
	iommu@lists.linux-foundation.org, David Vrabel <david.vrabel@citrix.com>,
	alexander.deucher@amd.com, torvalds@linux-foundation.org,
	christian.koenig@amd.com
Subject: Re: [Xen-devel] [RFC] add a struct page* parameter to
	dma_map_ops.unmap_page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21 2014 at 03:48:33 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 17 Nov 2014, Stefano Stabellini wrote:
>> Hi all,
>> I am writing this email to ask for your advice.
>> 
>> On architectures where dma addresses are different from physical
>> addresses, it can be difficult to retrieve the physical address of a
>> page from its dma address.
>> 
>> Specifically this is the case for Xen on arm and arm64 but I think that
>> other architectures might have the same issue.
>> 
>> Knowing the physical address is necessary to be able to issue any
>> required cache maintenance operations when unmap_page,
>> sync_single_for_cpu and sync_single_for_device are called.
>> 
>> Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
>> sync_single_for_device would make Linux dma handling on Xen on arm and
>> arm64 much easier and quicker.
>> 
>> I think that other drivers have similar problems, such as the Intel
>> IOMMU driver having to call find_iova and walking down an rbtree to get
>> the physical address in its implementation of unmap_page.
>> 
>> Callers have the struct page* in their hands already from the previous
>> map_page call so it shouldn't be an issue for them.  A problem does
>> exist however: there are about 280 callers of dma_unmap_page and
>> pci_unmap_page. We have even more callers of the dma_sync_single_for_*
>> functions.
>> 
>> 
>> 
>> Is such a change even conceivable? How would one go about it?
>> 
>> I think that Xen would not be the only one to gain from it, but I would
>> like to have a confirmation from others: given the magnitude of the
>> changes involved I would actually prefer to avoid them unless multiple
>> drivers/archs/subsystems could really benefit from them.
>
> Given the lack of interest from the community, I am going to drop this
> idea.

Actually it sounds like the right API design to me.  As a bonus it
should help performance a bit as well.  For example, the current
implementations of dma_sync_single_for_{cpu,device} and dma_unmap_page
on ARM while using the IOMMU mapper
(arm_iommu_sync_single_for_{cpu,device}, arm_iommu_unmap_page) all call
iommu_iova_to_phys which generally results in a page table walk or a
hardware register write/poll/read.

The problem, as you mentioned, is that there are a ton of callers of the
existing APIs.  I think David Vrabel had a good suggestion for dealing
with this:

On Mon, Nov 17 2014 at 06:43:46 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> You may need to consider a parallel set of map/unmap API calls that
> return/accept a handle, and then converting drivers one-by-one as
> required, instead of trying to convert every single driver at once.

However, I'm not sure whether the costs of having a parallel set of APIs
outweigh the benefits of a cleaner API and a slight performance boost...
But I hope the idea isn't completely abandoned without some profiling or
other evidence of its benefits (e.g. patches showing how drivers could
be simplified with the new APIs).


-Mitch

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsps8-0003cw-Lw; Mon, 24 Nov 2014 09:23:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linxingnku@gmail.com>) id 1XrbXM-00043E-9i
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 23:53:20 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	67/58-03148-FEE7E645; Thu, 20 Nov 2014 23:53:19 +0000
X-Env-Sender: linxingnku@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416527598!13889317!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8024 invoked from network); 20 Nov 2014 23:53:18 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 23:53:18 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so7117455wiw.4
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 15:53:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=YjTIUuv5HlV4c5/eUnQMNc9YE+L3pNicPIfTFBGAj4w=;
	b=zqWiUKtgJmTgu3bSRVV3bCuWRaiLEZYYA77ba+Ccvq7fNDTu8Pu+Qfd7hkZDvIIS6F
	5hbpylkvrOls6VXYdTemHK7CQSfJy97PENvS8KXsari8sWdFb+St6muGplI2WxLE5LIE
	suY1so/KKoJYLz+kvSQ6XSYvNcynRoaz1P6Svsk9Nsbc0Tb+HNCK1q+Iohp8Vlm7580I
	uUhmIKYYRb+SXrbPV9G2MiG02SIJAwZ4wbG5dsZnEP+xypie9OD+KUxd0Ii8d/uTne6k
	uAsiCRP2mjQ1E4sTkb4YohMtHnhLMMnL1Hv+L3g7zATZLYrcUy3fyKkOR9Teb5qwQiNL
	jdZg==
MIME-Version: 1.0
X-Received: by 10.180.92.234 with SMTP id cp10mr8872496wib.16.1416527597993;
	Thu, 20 Nov 2014 15:53:17 -0800 (PST)
Received: by 10.27.132.86 with HTTP; Thu, 20 Nov 2014 15:53:17 -0800 (PST)
In-Reply-To: <1416475824.14429.1.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416475824.14429.1.camel@citrix.com>
Date: Thu, 20 Nov 2014 16:53:17 -0700
Message-ID: <CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
From: Xing Lin <linxingnku@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Cc: xen-devel@lists.xen.org,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7051954705347876481=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7051954705347876481==
Content-Type: multipart/alternative; boundary=f46d04388e574b044005085308db

--f46d04388e574b044005085308db
Content-Type: text/plain; charset=UTF-8

Hi,

I git clone nova-juno from github and searched for 'pygrub'. Here is what i
get.

.//etc/nova/rootwrap.d/compute.filters:104:# nova/virt/xenapi/vm_utils.py:
'pygrub', '-qn', dev_path
.//etc/nova/rootwrap.d/compute.filters:105:pygrub: CommandFilter, pygrub,
root
.//nova/tests/unit/virt/xenapi/test_xenapi.py:667:
 self.assertEqual(self.vm['PV_bootloader'], 'pygrub')
.//nova/virt/xenapi/vm_utils.py:298:            rec['PV_bootloader'] =
'pygrub'

It seems that nova does not specify absolute path for pygrub.

I checked libvirt source code and found the following definition.

.//src/libxl/libxl_conf.h:52:# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"

Searched further for difinition of BINDIR revealed the followings.

Xing:libvirt-1.2.2 xing$ grep BINDIR -Rn ./
.//ChangeLog:48645:  SBINDIR "/libvirtd"
.//ChangeLog:48646:  SBINDIR "/libvirtd_dbg"
.//build-aux/ltmain.sh:2408:  -bindir BINDIR    specify path to binaries
directory (for systems where
.//gnulib/lib/Makefile.in:2499:  echo '#define BINDIR "$(bindir)"'; \
.//gnulib/lib/Makefile.in:2500:  echo '#define SBINDIR "$(sbindir)"'; \
.//gnulib/lib/gnulib.mk:303:  echo '#define BINDIR "$(bindir)"'; \
.//gnulib/lib/gnulib.mk:304:  echo '#define SBINDIR "$(sbindir)"'; \

I guess BINDIR was pointed to /usr/bin.

-Xing

On Thu, Nov 20, 2014 at 2:30 AM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Wed, 2014-11-19 at 11:57 -0700, Xing Lin wrote:
> > Hi Ian,
> >
> >
> > Both of your two points are valid. There is no need to install
> > virt-manager. And the patch to start a qemu process in /etc/init.d/xen
> > seems to be enough for launching instances from horizon. I have
> > updated the wiki page.  Please review it at
> >
> > http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
>
> Looks much better, thanks!
>
> I think the need to symlink pygrub to /usr/bin should be considered an
> openstack bug. I presume nova specifies the absolute path, when it
> should just say "pygrub" by default and let the toolstack find the
> default one.
>
> Ian.
>
>
>

--f46d04388e574b044005085308db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I git clone nova-juno from github a=
nd searched for &#39;pygrub&#39;. Here is what i get.=C2=A0</div><div><br><=
/div><div><div>.//etc/nova/rootwrap.d/compute.filters:104:# nova/virt/xenap=
i/vm_utils.py: &#39;pygrub&#39;, &#39;-qn&#39;, dev_path</div><div>.//etc/n=
ova/rootwrap.d/compute.filters:105:pygrub: CommandFilter, pygrub, root</div=
><div>.//nova/tests/unit/virt/xenapi/test_xenapi.py:667: =C2=A0 =C2=A0 =C2=
=A0 =C2=A0self.assertEqual(self.vm[&#39;PV_bootloader&#39;], &#39;pygrub&#3=
9;)</div><div>.//nova/virt/xenapi/vm_utils.py:298: =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0rec[&#39;PV_bootloader&#39;] =3D &#39;pygrub&#39;</div></d=
iv><div><br></div><div>It seems that nova does not specify absolute path fo=
r pygrub.=C2=A0</div><div><br></div><div>I checked libvirt source code and =
found the following definition.</div><div><br></div><div>.//src/libxl/libxl=
_conf.h:52:# define LIBXL_BOOTLOADER_PATH BINDIR &quot;/pygrub&quot;</div><=
div><br></div><div>Searched further for difinition of BINDIR revealed the f=
ollowings.=C2=A0</div><div><br></div><div><div>Xing:libvirt-1.2.2 xing$ gre=
p BINDIR -Rn ./</div><div>.//ChangeLog:48645:<span class=3D"" style=3D"whit=
e-space:pre">	</span> =C2=A0SBINDIR &quot;/libvirtd&quot;</div><div>.//Chan=
geLog:48646:<span class=3D"" style=3D"white-space:pre">	</span> =C2=A0SBIND=
IR &quot;/libvirtd_dbg&quot;</div><div>.//build-aux/ltmain.sh:2408: =C2=A0-=
bindir BINDIR =C2=A0 =C2=A0specify path to binaries directory (for systems =
where</div><div>.//gnulib/lib/Makefile.in:2499:<span class=3D"" style=3D"wh=
ite-space:pre">	</span> =C2=A0echo &#39;#define BINDIR &quot;$(bindir)&quot=
;&#39;; \</div><div>.//gnulib/lib/Makefile.in:2500:<span class=3D"" style=
=3D"white-space:pre">	</span> =C2=A0echo &#39;#define SBINDIR &quot;$(sbind=
ir)&quot;&#39;; \</div><div>.//gnulib/lib/<a href=3D"http://gnulib.mk:303">=
gnulib.mk:303</a>:<span class=3D"" style=3D"white-space:pre">	</span> =C2=
=A0echo &#39;#define BINDIR &quot;$(bindir)&quot;&#39;; \</div><div>.//gnul=
ib/lib/<a href=3D"http://gnulib.mk:304">gnulib.mk:304</a>:<span class=3D"" =
style=3D"white-space:pre">	</span> =C2=A0echo &#39;#define SBINDIR &quot;$(=
sbindir)&quot;&#39;; \</div></div><div><br></div><div>I guess BINDIR was po=
inted to /usr/bin.=C2=A0</div><div><br></div><div>-Xing=C2=A0</div></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 20, 201=
4 at 2:30 AM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Camp=
bell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, 2014-11-19=
 at 11:57 -0700, Xing Lin wrote:<br>
&gt; Hi Ian,<br>
&gt;<br>
&gt;<br>
&gt; Both of your two points are valid. There is no need to install<br>
&gt; virt-manager. And the patch to start a qemu process in /etc/init.d/xen=
<br>
&gt; seems to be enough for launching instances from horizon. I have<br>
&gt; updated the wiki page.=C2=A0 Please review it at<br>
&gt;<br>
&gt; <a href=3D"http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenSta=
ck_juno" target=3D"_blank">http://wiki.xenproject.org/wiki/Xen_via_libvirt_=
for_OpenStack_juno</a><br>
<br>
</span>Looks much better, thanks!<br>
<br>
I think the need to symlink pygrub to /usr/bin should be considered an<br>
openstack bug. I presume nova specifies the absolute path, when it<br>
should just say &quot;pygrub&quot; by default and let the toolstack find th=
e<br>
default one.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--f46d04388e574b044005085308db--


--===============7051954705347876481==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7051954705347876481==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsps8-0003cw-Lw; Mon, 24 Nov 2014 09:23:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linxingnku@gmail.com>) id 1XrbXM-00043E-9i
	for xen-devel@lists.xen.org; Thu, 20 Nov 2014 23:53:20 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	67/58-03148-FEE7E645; Thu, 20 Nov 2014 23:53:19 +0000
X-Env-Sender: linxingnku@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416527598!13889317!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8024 invoked from network); 20 Nov 2014 23:53:18 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2014 23:53:18 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so7117455wiw.4
	for <xen-devel@lists.xen.org>; Thu, 20 Nov 2014 15:53:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=YjTIUuv5HlV4c5/eUnQMNc9YE+L3pNicPIfTFBGAj4w=;
	b=zqWiUKtgJmTgu3bSRVV3bCuWRaiLEZYYA77ba+Ccvq7fNDTu8Pu+Qfd7hkZDvIIS6F
	5hbpylkvrOls6VXYdTemHK7CQSfJy97PENvS8KXsari8sWdFb+St6muGplI2WxLE5LIE
	suY1so/KKoJYLz+kvSQ6XSYvNcynRoaz1P6Svsk9Nsbc0Tb+HNCK1q+Iohp8Vlm7580I
	uUhmIKYYRb+SXrbPV9G2MiG02SIJAwZ4wbG5dsZnEP+xypie9OD+KUxd0Ii8d/uTne6k
	uAsiCRP2mjQ1E4sTkb4YohMtHnhLMMnL1Hv+L3g7zATZLYrcUy3fyKkOR9Teb5qwQiNL
	jdZg==
MIME-Version: 1.0
X-Received: by 10.180.92.234 with SMTP id cp10mr8872496wib.16.1416527597993;
	Thu, 20 Nov 2014 15:53:17 -0800 (PST)
Received: by 10.27.132.86 with HTTP; Thu, 20 Nov 2014 15:53:17 -0800 (PST)
In-Reply-To: <1416475824.14429.1.camel@citrix.com>
References: <CA+J9cpa8bR0v9Po1ZmTiPbdat7XbmiVYyg0ALPq+gtHxf3WGeA@mail.gmail.com>
	<54648EB3.8040703@citrix.com>
	<CA+J9cpZqVa4mfCQzHPTLVoMCCFeNJQ+M_HwY4-2zhBQMYzHK2g@mail.gmail.com>
	<1415955718.31613.34.camel@citrix.com>
	<CA+J9cpbcJETKqAkr0pqo_bjR8+Sr33YS0+PK85UZ+TowfkWtTw@mail.gmail.com>
	<1416227964.5466.12.camel@citrix.com>
	<CA+J9cpZP_GUCtXJVZGL0M94UCVCygPxcsZGpT4_rSPrQbvfz5w@mail.gmail.com>
	<1416475824.14429.1.camel@citrix.com>
Date: Thu, 20 Nov 2014 16:53:17 -0700
Message-ID: <CA+J9cpam6taP+V9Eh7ifmC5S29uXgRaehLcuPW6NVC5-MsnTKA@mail.gmail.com>
From: Xing Lin <linxingnku@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Cc: xen-devel@lists.xen.org,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7051954705347876481=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7051954705347876481==
Content-Type: multipart/alternative; boundary=f46d04388e574b044005085308db

--f46d04388e574b044005085308db
Content-Type: text/plain; charset=UTF-8

Hi,

I git clone nova-juno from github and searched for 'pygrub'. Here is what i
get.

.//etc/nova/rootwrap.d/compute.filters:104:# nova/virt/xenapi/vm_utils.py:
'pygrub', '-qn', dev_path
.//etc/nova/rootwrap.d/compute.filters:105:pygrub: CommandFilter, pygrub,
root
.//nova/tests/unit/virt/xenapi/test_xenapi.py:667:
 self.assertEqual(self.vm['PV_bootloader'], 'pygrub')
.//nova/virt/xenapi/vm_utils.py:298:            rec['PV_bootloader'] =
'pygrub'

It seems that nova does not specify absolute path for pygrub.

I checked libvirt source code and found the following definition.

.//src/libxl/libxl_conf.h:52:# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"

Searched further for difinition of BINDIR revealed the followings.

Xing:libvirt-1.2.2 xing$ grep BINDIR -Rn ./
.//ChangeLog:48645:  SBINDIR "/libvirtd"
.//ChangeLog:48646:  SBINDIR "/libvirtd_dbg"
.//build-aux/ltmain.sh:2408:  -bindir BINDIR    specify path to binaries
directory (for systems where
.//gnulib/lib/Makefile.in:2499:  echo '#define BINDIR "$(bindir)"'; \
.//gnulib/lib/Makefile.in:2500:  echo '#define SBINDIR "$(sbindir)"'; \
.//gnulib/lib/gnulib.mk:303:  echo '#define BINDIR "$(bindir)"'; \
.//gnulib/lib/gnulib.mk:304:  echo '#define SBINDIR "$(sbindir)"'; \

I guess BINDIR was pointed to /usr/bin.

-Xing

On Thu, Nov 20, 2014 at 2:30 AM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Wed, 2014-11-19 at 11:57 -0700, Xing Lin wrote:
> > Hi Ian,
> >
> >
> > Both of your two points are valid. There is no need to install
> > virt-manager. And the patch to start a qemu process in /etc/init.d/xen
> > seems to be enough for launching instances from horizon. I have
> > updated the wiki page.  Please review it at
> >
> > http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno
>
> Looks much better, thanks!
>
> I think the need to symlink pygrub to /usr/bin should be considered an
> openstack bug. I presume nova specifies the absolute path, when it
> should just say "pygrub" by default and let the toolstack find the
> default one.
>
> Ian.
>
>
>

--f46d04388e574b044005085308db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I git clone nova-juno from github a=
nd searched for &#39;pygrub&#39;. Here is what i get.=C2=A0</div><div><br><=
/div><div><div>.//etc/nova/rootwrap.d/compute.filters:104:# nova/virt/xenap=
i/vm_utils.py: &#39;pygrub&#39;, &#39;-qn&#39;, dev_path</div><div>.//etc/n=
ova/rootwrap.d/compute.filters:105:pygrub: CommandFilter, pygrub, root</div=
><div>.//nova/tests/unit/virt/xenapi/test_xenapi.py:667: =C2=A0 =C2=A0 =C2=
=A0 =C2=A0self.assertEqual(self.vm[&#39;PV_bootloader&#39;], &#39;pygrub&#3=
9;)</div><div>.//nova/virt/xenapi/vm_utils.py:298: =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0rec[&#39;PV_bootloader&#39;] =3D &#39;pygrub&#39;</div></d=
iv><div><br></div><div>It seems that nova does not specify absolute path fo=
r pygrub.=C2=A0</div><div><br></div><div>I checked libvirt source code and =
found the following definition.</div><div><br></div><div>.//src/libxl/libxl=
_conf.h:52:# define LIBXL_BOOTLOADER_PATH BINDIR &quot;/pygrub&quot;</div><=
div><br></div><div>Searched further for difinition of BINDIR revealed the f=
ollowings.=C2=A0</div><div><br></div><div><div>Xing:libvirt-1.2.2 xing$ gre=
p BINDIR -Rn ./</div><div>.//ChangeLog:48645:<span class=3D"" style=3D"whit=
e-space:pre">	</span> =C2=A0SBINDIR &quot;/libvirtd&quot;</div><div>.//Chan=
geLog:48646:<span class=3D"" style=3D"white-space:pre">	</span> =C2=A0SBIND=
IR &quot;/libvirtd_dbg&quot;</div><div>.//build-aux/ltmain.sh:2408: =C2=A0-=
bindir BINDIR =C2=A0 =C2=A0specify path to binaries directory (for systems =
where</div><div>.//gnulib/lib/Makefile.in:2499:<span class=3D"" style=3D"wh=
ite-space:pre">	</span> =C2=A0echo &#39;#define BINDIR &quot;$(bindir)&quot=
;&#39;; \</div><div>.//gnulib/lib/Makefile.in:2500:<span class=3D"" style=
=3D"white-space:pre">	</span> =C2=A0echo &#39;#define SBINDIR &quot;$(sbind=
ir)&quot;&#39;; \</div><div>.//gnulib/lib/<a href=3D"http://gnulib.mk:303">=
gnulib.mk:303</a>:<span class=3D"" style=3D"white-space:pre">	</span> =C2=
=A0echo &#39;#define BINDIR &quot;$(bindir)&quot;&#39;; \</div><div>.//gnul=
ib/lib/<a href=3D"http://gnulib.mk:304">gnulib.mk:304</a>:<span class=3D"" =
style=3D"white-space:pre">	</span> =C2=A0echo &#39;#define SBINDIR &quot;$(=
sbindir)&quot;&#39;; \</div></div><div><br></div><div>I guess BINDIR was po=
inted to /usr/bin.=C2=A0</div><div><br></div><div>-Xing=C2=A0</div></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 20, 201=
4 at 2:30 AM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Camp=
bell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, 2014-11-19=
 at 11:57 -0700, Xing Lin wrote:<br>
&gt; Hi Ian,<br>
&gt;<br>
&gt;<br>
&gt; Both of your two points are valid. There is no need to install<br>
&gt; virt-manager. And the patch to start a qemu process in /etc/init.d/xen=
<br>
&gt; seems to be enough for launching instances from horizon. I have<br>
&gt; updated the wiki page.=C2=A0 Please review it at<br>
&gt;<br>
&gt; <a href=3D"http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenSta=
ck_juno" target=3D"_blank">http://wiki.xenproject.org/wiki/Xen_via_libvirt_=
for_OpenStack_juno</a><br>
<br>
</span>Looks much better, thanks!<br>
<br>
I think the need to symlink pygrub to /usr/bin should be considered an<br>
openstack bug. I presume nova specifies the absolute path, when it<br>
should just say &quot;pygrub&quot; by default and let the toolstack find th=
e<br>
default one.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--f46d04388e574b044005085308db--


--===============7051954705347876481==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7051954705347876481==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsps9-0003dM-GJ; Mon, 24 Nov 2014 09:23:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <suhani@Brocade.com>) id 1XrvWX-0005x0-UZ
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 21:13:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	02/92-15461-D0BAF645; Fri, 21 Nov 2014 21:13:49 +0000
X-Env-Sender: suhani@Brocade.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416604427!11065858!1
X-Originating-IP: [67.231.144.122]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjcuMjMxLjE0NC4xMjIgPT4gMTgyMjA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13251 invoked from network); 21 Nov 2014 21:13:48 -0000
Received: from mx0a-000f0801.pphosted.com (HELO mx0a-000f0801.pphosted.com)
	(67.231.144.122)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 21:13:48 -0000
Received: from pps.filterd (m0048193 [127.0.0.1])
	by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id
	sALL08Ah009674
	for <xen-devel@lists.xenproject.org>; Fri, 21 Nov 2014 13:13:46 -0800
Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13])
	by mx0a-000f0801.pphosted.com with ESMTP id 1qsjpbn53a-2
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for <xen-devel@lists.xenproject.org>; Fri, 21 Nov 2014 13:13:46 -0800
Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by
	HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP
	Server (TLS) id 14.3.123.3; Fri, 21 Nov 2014 13:13:44 -0800
Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by
	BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP
	Server (TLS) id 14.3.123.3; Fri, 21 Nov 2014 14:13:43 -0700
Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by
	BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP
	Server (TLS) id 15.0.847.32; Fri, 21 Nov 2014 14:13:43 -0700
Received: from BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9]) by
	BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9%23]) with
	mapi id 15.00.0847.030; Fri, 21 Nov 2014 14:13:43 -0700
From: Suhani Gupta <suhani@Brocade.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Thread-Topic: Virtio disk type for xen VM
Thread-Index: AdAFz/rtvvboYnNeR76h0poXIQSCSw==
Date: Fri, 21 Nov 2014 21:13:43 +0000
Message-ID: <4cdd95a441484755ae46dac0deb43b70@BRMWP-EXMB11.corp.brocade.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.120.62.157]
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28,
	0.0.0000
	definitions=2014-11-21_07:2014-11-21, 2014-11-21,
	1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
	suspectscore=0 phishscore=0
	adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx
	scancount=1
	engine=7.0.1-1402240000 definitions=main-1411210171
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Subject: [Xen-devel] Virtio disk type for xen VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6277634255091727380=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6277634255091727380==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_4cdd95a441484755ae46dac0deb43b70BRMWPEXMB11corpbrocadec_"

--_000_4cdd95a441484755ae46dac0deb43b70BRMWPEXMB11corpbrocadec_
Content-Type: text/plain; charset="us-ascii"

Hi,

I want to assign virtio disk bus type to a VM in Xenserver. How to do it?

Thanks and Regards
Suhani Gupta


--_000_4cdd95a441484755ae46dac0deb43b70BRMWPEXMB11corpbrocadec_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"Bradley Hand ITC";
	panose-1:3 7 4 2 5 3 2 3 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I want to assign virtio disk bus type to a VM in Xen=
server. How to do it?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><b><span style=3D"font-family:&quot;Bradley Hand ITC=
&quot;;color:black">Thanks and Regards<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><b><span style=3D"font-family:&quot;Bradley Hand ITC=
&quot;;color:black">Suhani Gupta<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_4cdd95a441484755ae46dac0deb43b70BRMWPEXMB11corpbrocadec_--


--===============6277634255091727380==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6277634255091727380==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsps9-0003d7-2Q; Mon, 24 Nov 2014 09:23:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mitchelh@codeaurora.org>) id 1Xruf7-0004dB-4R
	for xen-devel@lists.xensource.com; Fri, 21 Nov 2014 20:18:37 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	7A/D6-11581-C1E9F645; Fri, 21 Nov 2014 20:18:36 +0000
X-Env-Sender: mitchelh@codeaurora.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416601114!9391906!1
X-Originating-IP: [198.145.11.231]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28307 invoked from network); 21 Nov 2014 20:18:35 -0000
Received: from smtp.codeaurora.org (HELO smtp.codeaurora.org) (198.145.11.231)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2014 20:18:35 -0000
Received: from smtp.codeaurora.org (localhost [127.0.0.1])
	by smtp.codeaurora.org (Postfix) with ESMTP id 659AD13F90E;
	Fri, 21 Nov 2014 20:18:33 +0000 (UTC)
Received: by smtp.codeaurora.org (Postfix, from userid 486)
	id 536CA13F91F; Fri, 21 Nov 2014 20:18:33 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	pdx-caf-smtp.dmz.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham version=3.3.1
Received: from localhost (i-global254.qualcomm.com [199.106.103.254])
	(using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: mitchelh@smtp.codeaurora.org)
	by smtp.codeaurora.org (Postfix) with ESMTPSA id C96EB13F90E;
	Fri, 21 Nov 2014 20:18:32 +0000 (UTC)
From: Mitchel Humpherys <mitchelh@codeaurora.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1411111644490.26318@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411211147450.12596@kaball.uk.xensource.com>
Date: Fri, 21 Nov 2014 12:18:32 -0800
In-Reply-To: <alpine.DEB.2.02.1411211147450.12596@kaball.uk.xensource.com>
	(Stefano Stabellini's message of "Fri, 21 Nov 2014 11:48:33 +0000")
Message-ID: <vnkwh9xs2tpj.fsf@mitchelh-linux.qualcomm.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV using ClamSMTP
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Cc: linux-mips@linux-mips.org, airlied@linux.ie,
	dri-devel@lists.freedesktop.org, xen-devel@lists.xensource.com,
	linux@arm.linux.org.uk, vinod.koul@intel.com, deller@gmx.de,
	jejb@parisc-linux.org, dwmw2@infradead.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	dmaengine@vger.kernel.org, bhelgaas@google.com,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, ralf@linux-mips.org,
	iommu@lists.linux-foundation.org, David Vrabel <david.vrabel@citrix.com>,
	alexander.deucher@amd.com, torvalds@linux-foundation.org,
	christian.koenig@amd.com
Subject: Re: [Xen-devel] [RFC] add a struct page* parameter to
	dma_map_ops.unmap_page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21 2014 at 03:48:33 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 17 Nov 2014, Stefano Stabellini wrote:
>> Hi all,
>> I am writing this email to ask for your advice.
>> 
>> On architectures where dma addresses are different from physical
>> addresses, it can be difficult to retrieve the physical address of a
>> page from its dma address.
>> 
>> Specifically this is the case for Xen on arm and arm64 but I think that
>> other architectures might have the same issue.
>> 
>> Knowing the physical address is necessary to be able to issue any
>> required cache maintenance operations when unmap_page,
>> sync_single_for_cpu and sync_single_for_device are called.
>> 
>> Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
>> sync_single_for_device would make Linux dma handling on Xen on arm and
>> arm64 much easier and quicker.
>> 
>> I think that other drivers have similar problems, such as the Intel
>> IOMMU driver having to call find_iova and walking down an rbtree to get
>> the physical address in its implementation of unmap_page.
>> 
>> Callers have the struct page* in their hands already from the previous
>> map_page call so it shouldn't be an issue for them.  A problem does
>> exist however: there are about 280 callers of dma_unmap_page and
>> pci_unmap_page. We have even more callers of the dma_sync_single_for_*
>> functions.
>> 
>> 
>> 
>> Is such a change even conceivable? How would one go about it?
>> 
>> I think that Xen would not be the only one to gain from it, but I would
>> like to have a confirmation from others: given the magnitude of the
>> changes involved I would actually prefer to avoid them unless multiple
>> drivers/archs/subsystems could really benefit from them.
>
> Given the lack of interest from the community, I am going to drop this
> idea.

Actually it sounds like the right API design to me.  As a bonus it
should help performance a bit as well.  For example, the current
implementations of dma_sync_single_for_{cpu,device} and dma_unmap_page
on ARM while using the IOMMU mapper
(arm_iommu_sync_single_for_{cpu,device}, arm_iommu_unmap_page) all call
iommu_iova_to_phys which generally results in a page table walk or a
hardware register write/poll/read.

The problem, as you mentioned, is that there are a ton of callers of the
existing APIs.  I think David Vrabel had a good suggestion for dealing
with this:

On Mon, Nov 17 2014 at 06:43:46 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> You may need to consider a parallel set of map/unmap API calls that
> return/accept a handle, and then converting drivers one-by-one as
> required, instead of trying to convert every single driver at once.

However, I'm not sure whether the costs of having a parallel set of APIs
outweigh the benefits of a cleaner API and a slight performance boost...
But I hope the idea isn't completely abandoned without some profiling or
other evidence of its benefits (e.g. patches showing how drivers could
be simplified with the new APIs).


-Mitch

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsps9-0003dM-GJ; Mon, 24 Nov 2014 09:23:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <suhani@Brocade.com>) id 1XrvWX-0005x0-UZ
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 21:13:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	02/92-15461-D0BAF645; Fri, 21 Nov 2014 21:13:49 +0000
X-Env-Sender: suhani@Brocade.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416604427!11065858!1
X-Originating-IP: [67.231.144.122]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjcuMjMxLjE0NC4xMjIgPT4gMTgyMjA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13251 invoked from network); 21 Nov 2014 21:13:48 -0000
Received: from mx0a-000f0801.pphosted.com (HELO mx0a-000f0801.pphosted.com)
	(67.231.144.122)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2014 21:13:48 -0000
Received: from pps.filterd (m0048193 [127.0.0.1])
	by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id
	sALL08Ah009674
	for <xen-devel@lists.xenproject.org>; Fri, 21 Nov 2014 13:13:46 -0800
Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13])
	by mx0a-000f0801.pphosted.com with ESMTP id 1qsjpbn53a-2
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for <xen-devel@lists.xenproject.org>; Fri, 21 Nov 2014 13:13:46 -0800
Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by
	HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP
	Server (TLS) id 14.3.123.3; Fri, 21 Nov 2014 13:13:44 -0800
Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by
	BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP
	Server (TLS) id 14.3.123.3; Fri, 21 Nov 2014 14:13:43 -0700
Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by
	BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP
	Server (TLS) id 15.0.847.32; Fri, 21 Nov 2014 14:13:43 -0700
Received: from BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9]) by
	BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9%23]) with
	mapi id 15.00.0847.030; Fri, 21 Nov 2014 14:13:43 -0700
From: Suhani Gupta <suhani@Brocade.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Thread-Topic: Virtio disk type for xen VM
Thread-Index: AdAFz/rtvvboYnNeR76h0poXIQSCSw==
Date: Fri, 21 Nov 2014 21:13:43 +0000
Message-ID: <4cdd95a441484755ae46dac0deb43b70@BRMWP-EXMB11.corp.brocade.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.120.62.157]
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28,
	0.0.0000
	definitions=2014-11-21_07:2014-11-21, 2014-11-21,
	1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
	suspectscore=0 phishscore=0
	adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx
	scancount=1
	engine=7.0.1-1402240000 definitions=main-1411210171
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Subject: [Xen-devel] Virtio disk type for xen VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6277634255091727380=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6277634255091727380==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_4cdd95a441484755ae46dac0deb43b70BRMWPEXMB11corpbrocadec_"

--_000_4cdd95a441484755ae46dac0deb43b70BRMWPEXMB11corpbrocadec_
Content-Type: text/plain; charset="us-ascii"

Hi,

I want to assign virtio disk bus type to a VM in Xenserver. How to do it?

Thanks and Regards
Suhani Gupta


--_000_4cdd95a441484755ae46dac0deb43b70BRMWPEXMB11corpbrocadec_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"Bradley Hand ITC";
	panose-1:3 7 4 2 5 3 2 3 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I want to assign virtio disk bus type to a VM in Xen=
server. How to do it?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><b><span style=3D"font-family:&quot;Bradley Hand ITC=
&quot;;color:black">Thanks and Regards<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><b><span style=3D"font-family:&quot;Bradley Hand ITC=
&quot;;color:black">Suhani Gupta<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_4cdd95a441484755ae46dac0deb43b70BRMWPEXMB11corpbrocadec_--


--===============6277634255091727380==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6277634255091727380==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsps9-0003dc-TZ; Mon, 24 Nov 2014 09:23:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <khoroshilov@ispras.ru>) id 1Xrx84-0008Nx-Ql
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:56:40 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	A4/35-02957-823CF645; Fri, 21 Nov 2014 22:56:40 +0000
X-Env-Sender: khoroshilov@ispras.ru
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416610599!14092302!1
X-Originating-IP: [83.149.199.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21670 invoked from network); 21 Nov 2014 22:56:39 -0000
Received: from mail.ispras.ru (HELO mail.ispras.ru) (83.149.199.45)
	by server-13.tower-27.messagelabs.com with SMTP;
	21 Nov 2014 22:56:39 -0000
Received: from localhost.localdomain (ppp83-237-20-3.pppoe.mtu-net.ru
	[83.237.20.3])
	by mail.ispras.ru (Postfix) with ESMTPSA id E49D154006F;
	Sat, 22 Nov 2014 01:56:37 +0300 (MSK)
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
To: Ian Campbell <ian.campbell@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>
Date: Sat, 22 Nov 2014 01:56:28 +0300
Message-Id: <1416610588-19816-1-git-send-email-khoroshilov@ispras.ru>
X-Mailer: git-send-email 1.9.1
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Cc: ldv-project@linuxtesting.org, xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org, Alexey Khoroshilov <khoroshilov@ispras.ru>,
	netdev@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen-netback: do not report success if
	xenvif_alloc() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenvif_alloc() failes, netback_probe() reports success as well as
"online" uevent is emitted. It does not make any sense, but it just
misleads users.

The patch implements propagation of error code if xenvif creation fails.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
 drivers/net/xen-netback/xenbus.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 4e56a27f9689..fab0d4b42f58 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -39,7 +39,7 @@ struct backend_info {
 static int connect_rings(struct backend_info *be, struct xenvif_queue *queue);
 static void connect(struct backend_info *be);
 static int read_xenbus_vif_flags(struct backend_info *be);
-static void backend_create_xenvif(struct backend_info *be);
+static int backend_create_xenvif(struct backend_info *be);
 static void unregister_hotplug_status_watch(struct backend_info *be);
 static void set_backend_state(struct backend_info *be,
 			      enum xenbus_state state);
@@ -352,7 +352,9 @@ static int netback_probe(struct xenbus_device *dev,
 	be->state = XenbusStateInitWait;
 
 	/* This kicks hotplug scripts, so do it immediately. */
-	backend_create_xenvif(be);
+	err = backend_create_xenvif(be);
+	if (err)
+		goto fail;
 
 	return 0;
 
@@ -397,19 +399,19 @@ static int netback_uevent(struct xenbus_device *xdev,
 }
 
 
-static void backend_create_xenvif(struct backend_info *be)
+static int backend_create_xenvif(struct backend_info *be)
 {
 	int err;
 	long handle;
 	struct xenbus_device *dev = be->dev;
 
 	if (be->vif != NULL)
-		return;
+		return 0;
 
 	err = xenbus_scanf(XBT_NIL, dev->nodename, "handle", "%li", &handle);
 	if (err != 1) {
 		xenbus_dev_fatal(dev, err, "reading handle");
-		return;
+		return (err < 0) ? err : -EINVAL;
 	}
 
 	be->vif = xenvif_alloc(&dev->dev, dev->otherend_id, handle);
@@ -417,10 +419,11 @@ static void backend_create_xenvif(struct backend_info *be)
 		err = PTR_ERR(be->vif);
 		be->vif = NULL;
 		xenbus_dev_fatal(dev, err, "creating interface");
-		return;
+		return err;
 	}
 
 	kobject_uevent(&dev->dev.kobj, KOBJ_ONLINE);
+	return 0;
 }
 
 static void backend_disconnect(struct backend_info *be)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsps9-0003dc-TZ; Mon, 24 Nov 2014 09:23:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <khoroshilov@ispras.ru>) id 1Xrx84-0008Nx-Ql
	for xen-devel@lists.xenproject.org; Fri, 21 Nov 2014 22:56:40 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	A4/35-02957-823CF645; Fri, 21 Nov 2014 22:56:40 +0000
X-Env-Sender: khoroshilov@ispras.ru
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416610599!14092302!1
X-Originating-IP: [83.149.199.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21670 invoked from network); 21 Nov 2014 22:56:39 -0000
Received: from mail.ispras.ru (HELO mail.ispras.ru) (83.149.199.45)
	by server-13.tower-27.messagelabs.com with SMTP;
	21 Nov 2014 22:56:39 -0000
Received: from localhost.localdomain (ppp83-237-20-3.pppoe.mtu-net.ru
	[83.237.20.3])
	by mail.ispras.ru (Postfix) with ESMTPSA id E49D154006F;
	Sat, 22 Nov 2014 01:56:37 +0300 (MSK)
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
To: Ian Campbell <ian.campbell@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>
Date: Sat, 22 Nov 2014 01:56:28 +0300
Message-Id: <1416610588-19816-1-git-send-email-khoroshilov@ispras.ru>
X-Mailer: git-send-email 1.9.1
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Cc: ldv-project@linuxtesting.org, xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org, Alexey Khoroshilov <khoroshilov@ispras.ru>,
	netdev@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen-netback: do not report success if
	xenvif_alloc() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenvif_alloc() failes, netback_probe() reports success as well as
"online" uevent is emitted. It does not make any sense, but it just
misleads users.

The patch implements propagation of error code if xenvif creation fails.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
 drivers/net/xen-netback/xenbus.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 4e56a27f9689..fab0d4b42f58 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -39,7 +39,7 @@ struct backend_info {
 static int connect_rings(struct backend_info *be, struct xenvif_queue *queue);
 static void connect(struct backend_info *be);
 static int read_xenbus_vif_flags(struct backend_info *be);
-static void backend_create_xenvif(struct backend_info *be);
+static int backend_create_xenvif(struct backend_info *be);
 static void unregister_hotplug_status_watch(struct backend_info *be);
 static void set_backend_state(struct backend_info *be,
 			      enum xenbus_state state);
@@ -352,7 +352,9 @@ static int netback_probe(struct xenbus_device *dev,
 	be->state = XenbusStateInitWait;
 
 	/* This kicks hotplug scripts, so do it immediately. */
-	backend_create_xenvif(be);
+	err = backend_create_xenvif(be);
+	if (err)
+		goto fail;
 
 	return 0;
 
@@ -397,19 +399,19 @@ static int netback_uevent(struct xenbus_device *xdev,
 }
 
 
-static void backend_create_xenvif(struct backend_info *be)
+static int backend_create_xenvif(struct backend_info *be)
 {
 	int err;
 	long handle;
 	struct xenbus_device *dev = be->dev;
 
 	if (be->vif != NULL)
-		return;
+		return 0;
 
 	err = xenbus_scanf(XBT_NIL, dev->nodename, "handle", "%li", &handle);
 	if (err != 1) {
 		xenbus_dev_fatal(dev, err, "reading handle");
-		return;
+		return (err < 0) ? err : -EINVAL;
 	}
 
 	be->vif = xenvif_alloc(&dev->dev, dev->otherend_id, handle);
@@ -417,10 +419,11 @@ static void backend_create_xenvif(struct backend_info *be)
 		err = PTR_ERR(be->vif);
 		be->vif = NULL;
 		xenbus_dev_fatal(dev, err, "creating interface");
-		return;
+		return err;
 	}
 
 	kobject_uevent(&dev->dev.kobj, KOBJ_ONLINE);
+	return 0;
 }
 
 static void backend_disconnect(struct backend_info *be)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspsA-0003e0-A4; Mon, 24 Nov 2014 09:23:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vianom@gmail.com>) id 1XsIer-0007U6-0c
	for xen-devel@lists.xen.org; Sat, 22 Nov 2014 21:55:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	13/FF-15461-C6601745; Sat, 22 Nov 2014 21:55:56 +0000
X-Env-Sender: vianom@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416693355!14288958!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29232 invoked from network); 22 Nov 2014 21:55:55 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 21:55:55 -0000
Received: by mail-wi0-f182.google.com with SMTP id h11so2404677wiw.15
	for <xen-devel@lists.xen.org>; Sat, 22 Nov 2014 13:55:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=nrANDl/6via+UwVMlYyJsN+7yM8ybFGmdBBCsFGkP9s=;
	b=lgX32waq64Fj4O6d2i6llLN2SVE6aeKt76G6tNv4W/pklcjYmxaGzveEmhDXeAZ5Jx
	0xFc9W74mCzajjWZ/KV4hShYv7hJBCo+4sXdT/j49ISFOo+IjTBXV+Q4z/lblrkbBnBm
	Gc6BAGMUeFdd681A7s7GXwTfY9noASMyyFfJ0ZWkFtSXow5LXnjOhHE+2ocLVHlS5swf
	E19rCz4uTGuUp2RiZc/DUcEpanJahzlZjLkZoTWB/6LOtEHI9C3ynmV7EqSmwiilWRrR
	qDl5ZGQ76/HliSaJA8ALGXMLPjwLJDx2uotIUWCrJlnrrRfiI2sE4LuaccMNwyzxFXEW
	gfNw==
MIME-Version: 1.0
X-Received: by 10.194.93.168 with SMTP id cv8mr20708834wjb.114.1416693355411; 
	Sat, 22 Nov 2014 13:55:55 -0800 (PST)
Received: by 10.216.35.1 with HTTP; Sat, 22 Nov 2014 13:55:55 -0800 (PST)
Date: Sat, 22 Nov 2014 22:55:55 +0100
Message-ID: <CAE9jt38GBcTbvUCYMx=MHF5ig0Q3OO9F0q5PmjRk_tVDxxcUkg@mail.gmail.com>
From: leon zawodowiec <vianom@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Subject: [Xen-devel] Xen 4.2 time dilation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6552812903146644623=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6552812903146644623==
Content-Type: multipart/alternative; boundary=047d7bb0399e347e31050879a026

--047d7bb0399e347e31050879a026
Content-Type: text/plain; charset=UTF-8

Hello,

I'm in progress of my engeenering thesis which concerns Xen 4.2 on CentOS
6.5 kernel. I have to make time dilation in Xen(slower time). Please tell
me if it is possible to make it just by editing Xen source files without
touching kernel??(and which files are responsible for that?)

Thank you for replies,
Best regards

--047d7bb0399e347e31050879a026
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hello,<br><br></div>I&#39;m in progress of =
my engeenering thesis which concerns Xen 4.2 on CentOS 6.5 kernel. I have t=
o make time dilation in Xen(slower time). Please tell me if it is possible =
to make it just by editing Xen source files without touching kernel??(and w=
hich files are responsible for that?) <br><br></div>Thank you for replies,<=
br></div>Best regards<br></div>

--047d7bb0399e347e31050879a026--


--===============6552812903146644623==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6552812903146644623==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspsA-0003e0-A4; Mon, 24 Nov 2014 09:23:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vianom@gmail.com>) id 1XsIer-0007U6-0c
	for xen-devel@lists.xen.org; Sat, 22 Nov 2014 21:55:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	13/FF-15461-C6601745; Sat, 22 Nov 2014 21:55:56 +0000
X-Env-Sender: vianom@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416693355!14288958!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29232 invoked from network); 22 Nov 2014 21:55:55 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2014 21:55:55 -0000
Received: by mail-wi0-f182.google.com with SMTP id h11so2404677wiw.15
	for <xen-devel@lists.xen.org>; Sat, 22 Nov 2014 13:55:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=nrANDl/6via+UwVMlYyJsN+7yM8ybFGmdBBCsFGkP9s=;
	b=lgX32waq64Fj4O6d2i6llLN2SVE6aeKt76G6tNv4W/pklcjYmxaGzveEmhDXeAZ5Jx
	0xFc9W74mCzajjWZ/KV4hShYv7hJBCo+4sXdT/j49ISFOo+IjTBXV+Q4z/lblrkbBnBm
	Gc6BAGMUeFdd681A7s7GXwTfY9noASMyyFfJ0ZWkFtSXow5LXnjOhHE+2ocLVHlS5swf
	E19rCz4uTGuUp2RiZc/DUcEpanJahzlZjLkZoTWB/6LOtEHI9C3ynmV7EqSmwiilWRrR
	qDl5ZGQ76/HliSaJA8ALGXMLPjwLJDx2uotIUWCrJlnrrRfiI2sE4LuaccMNwyzxFXEW
	gfNw==
MIME-Version: 1.0
X-Received: by 10.194.93.168 with SMTP id cv8mr20708834wjb.114.1416693355411; 
	Sat, 22 Nov 2014 13:55:55 -0800 (PST)
Received: by 10.216.35.1 with HTTP; Sat, 22 Nov 2014 13:55:55 -0800 (PST)
Date: Sat, 22 Nov 2014 22:55:55 +0100
Message-ID: <CAE9jt38GBcTbvUCYMx=MHF5ig0Q3OO9F0q5PmjRk_tVDxxcUkg@mail.gmail.com>
From: leon zawodowiec <vianom@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Subject: [Xen-devel] Xen 4.2 time dilation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6552812903146644623=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6552812903146644623==
Content-Type: multipart/alternative; boundary=047d7bb0399e347e31050879a026

--047d7bb0399e347e31050879a026
Content-Type: text/plain; charset=UTF-8

Hello,

I'm in progress of my engeenering thesis which concerns Xen 4.2 on CentOS
6.5 kernel. I have to make time dilation in Xen(slower time). Please tell
me if it is possible to make it just by editing Xen source files without
touching kernel??(and which files are responsible for that?)

Thank you for replies,
Best regards

--047d7bb0399e347e31050879a026
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hello,<br><br></div>I&#39;m in progress of =
my engeenering thesis which concerns Xen 4.2 on CentOS 6.5 kernel. I have t=
o make time dilation in Xen(slower time). Please tell me if it is possible =
to make it just by editing Xen source files without touching kernel??(and w=
hich files are responsible for that?) <br><br></div>Thank you for replies,<=
br></div>Best regards<br></div>

--047d7bb0399e347e31050879a026--


--===============6552812903146644623==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6552812903146644623==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspsA-0003eL-NU; Mon, 24 Nov 2014 09:23:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aragrawal@cs.wisc.edu>) id 1Xskjq-0006IX-7B
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 03:54:58 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	5C/FF-02699-11CA2745; Mon, 24 Nov 2014 03:54:57 +0000
X-Env-Sender: aragrawal@cs.wisc.edu
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416801295!8908855!1
X-Originating-IP: [128.105.6.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23597 invoked from network); 24 Nov 2014 03:54:56 -0000
Received: from sandstone.cs.wisc.edu (HELO sandstone.cs.wisc.edu)
	(128.105.6.39)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 03:54:56 -0000
Received: from webmail.cs.wisc.edu (lilo.cs.wisc.edu [128.105.7.102])
	by sandstone.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id sAO3st1R026411
	for <xen-devel@lists.xenproject.org>; Sun, 23 Nov 2014 21:54:55 -0600
MIME-Version: 1.0
Date: Sun, 23 Nov 2014 21:54:55 -0600
From: aragrawal <aragrawal@cs.wisc.edu>
To: xen-devel@lists.xenproject.org
Message-ID: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
X-Sender: aragrawal@cs.wisc.edu
User-Agent: Roundcube Webmail/0.9.5
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Subject: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 interested in getting the block I/O rate fixed for a Virtual 
Machine. However, it seems that there are no such options to control the 
block I/O rate via the VM configuration file.
Going through the net, I see suggestions to configure the xen_blkback 
driver using ionice to get that done.

I would like to know if there are any plans to include any such 
configuration option.
Also, are there any particular reason (apart from the fact that there 
are other ways to get this done) for the absence of such configuration 
option?


Thanks
Ankit Agrawal

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:24:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspsA-0003eL-NU; Mon, 24 Nov 2014 09:23:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aragrawal@cs.wisc.edu>) id 1Xskjq-0006IX-7B
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 03:54:58 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	5C/FF-02699-11CA2745; Mon, 24 Nov 2014 03:54:57 +0000
X-Env-Sender: aragrawal@cs.wisc.edu
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416801295!8908855!1
X-Originating-IP: [128.105.6.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23597 invoked from network); 24 Nov 2014 03:54:56 -0000
Received: from sandstone.cs.wisc.edu (HELO sandstone.cs.wisc.edu)
	(128.105.6.39)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 03:54:56 -0000
Received: from webmail.cs.wisc.edu (lilo.cs.wisc.edu [128.105.7.102])
	by sandstone.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id sAO3st1R026411
	for <xen-devel@lists.xenproject.org>; Sun, 23 Nov 2014 21:54:55 -0600
MIME-Version: 1.0
Date: Sun, 23 Nov 2014 21:54:55 -0600
From: aragrawal <aragrawal@cs.wisc.edu>
To: xen-devel@lists.xenproject.org
Message-ID: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
X-Sender: aragrawal@cs.wisc.edu
User-Agent: Roundcube Webmail/0.9.5
X-Mailman-Approved-At: Mon, 24 Nov 2014 09:23:51 +0000
Subject: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 interested in getting the block I/O rate fixed for a Virtual 
Machine. However, it seems that there are no such options to control the 
block I/O rate via the VM configuration file.
Going through the net, I see suggestions to configure the xen_blkback 
driver using ionice to get that done.

I would like to know if there are any plans to include any such 
configuration option.
Also, are there any particular reason (apart from the fact that there 
are other ways to get this done) for the absence of such configuration 
option?


Thanks
Ankit Agrawal

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:29:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:29:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspxY-0004XN-N0; Mon, 24 Nov 2014 09:29:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XspxX-0004XI-0A
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:29:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	86/CC-09842-67AF2745; Mon, 24 Nov 2014 09:29:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416821365!14496436!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13237 invoked from network); 24 Nov 2014 09:29:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 09:29:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 09:29:25 +0000
Message-Id: <54730881020000780004A34C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 09:29:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
	<20141121195631.GA16313@laptop.dumpdata.com>
In-Reply-To: <20141121195631.GA16313@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/19] hvmloader: disallow memory relocation
 when vNUMA is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 20:56, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 21, 2014 at 03:06:56PM +0000, Wei Liu wrote:
>> --- a/tools/firmware/hvmloader/pci.c
>> +++ b/tools/firmware/hvmloader/pci.c
>> @@ -88,6 +88,19 @@ void pci_setup(void)
>>      printf("Relocating guest memory for lowmem MMIO space %s\n",
>>             allow_memory_relocate?"enabled":"disabled");
>>  
>> +    /* Disallow low memory relocation when vNUMA is enabled, because
>> +     * relocated memory ends up off node. Further more, even if we
>> +     * dynamically expand node coverage in hvmloader, low memory and
>> +     * high memory may reside in different physical nodes, blindly
>> +     * relocates low memory to high memory gives us a sub-optimal
>> +     * configuration.
> 
> And this is done in hvmloader, so the toolstack has no inkling that
> we need to relocate memory to make space for the PCI.
> 
> In such case I would not have this check here. Instead put it in 
> libxl and disallow vNUMA with PCI passthrough.
> 
> And then the fix is to take the logic that is in hvmloader for PCI
> BAR size relocation and move it in libxl. Then it can construct the
> proper vNUMA topology and also fix an outstanding QEMU-xen bug.

The problem then being that two code pieces pretty far apart from
one another need to be kept in perfect sync. Not really nice in
terms of maintainability. I'd really prefer hvmloader to re-write the
vNUMA info (on real hardware firmware also needs to take care of
the memory holes - there's no magic external entity there either).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:29:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:29:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XspxY-0004XN-N0; Mon, 24 Nov 2014 09:29:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XspxX-0004XI-0A
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:29:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	86/CC-09842-67AF2745; Mon, 24 Nov 2014 09:29:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416821365!14496436!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13237 invoked from network); 24 Nov 2014 09:29:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 09:29:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 09:29:25 +0000
Message-Id: <54730881020000780004A34C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 09:29:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
	<20141121195631.GA16313@laptop.dumpdata.com>
In-Reply-To: <20141121195631.GA16313@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/19] hvmloader: disallow memory relocation
 when vNUMA is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 20:56, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 21, 2014 at 03:06:56PM +0000, Wei Liu wrote:
>> --- a/tools/firmware/hvmloader/pci.c
>> +++ b/tools/firmware/hvmloader/pci.c
>> @@ -88,6 +88,19 @@ void pci_setup(void)
>>      printf("Relocating guest memory for lowmem MMIO space %s\n",
>>             allow_memory_relocate?"enabled":"disabled");
>>  
>> +    /* Disallow low memory relocation when vNUMA is enabled, because
>> +     * relocated memory ends up off node. Further more, even if we
>> +     * dynamically expand node coverage in hvmloader, low memory and
>> +     * high memory may reside in different physical nodes, blindly
>> +     * relocates low memory to high memory gives us a sub-optimal
>> +     * configuration.
> 
> And this is done in hvmloader, so the toolstack has no inkling that
> we need to relocate memory to make space for the PCI.
> 
> In such case I would not have this check here. Instead put it in 
> libxl and disallow vNUMA with PCI passthrough.
> 
> And then the fix is to take the logic that is in hvmloader for PCI
> BAR size relocation and move it in libxl. Then it can construct the
> proper vNUMA topology and also fix an outstanding QEMU-xen bug.

The problem then being that two code pieces pretty far apart from
one another need to be kept in perfect sync. Not really nice in
terms of maintainability. I'd really prefer hvmloader to re-write the
vNUMA info (on real hardware firmware also needs to take care of
the memory holes - there's no magic external entity there either).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:44:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqBZ-0004ls-50; Mon, 24 Nov 2014 09:43:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XsqBY-0004ln-HL
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:43:56 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	9B/91-09284-BDDF2745; Mon, 24 Nov 2014 09:43:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416822233!13334720!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20462 invoked from network); 24 Nov 2014 09:43:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 09:43:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="195990297"
Message-ID: <1416822231.26329.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Blake <eblake@redhat.com>
Date: Mon, 24 Nov 2014 09:43:51 +0000
In-Reply-To: <546FD5D2.60400@redhat.com>
References: <20141120101240.2a75f384@m> <546E7674.1060204@redhat.com>
	<546FD5D2.60400@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	cemeyer@uw.edu, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH 1/2] virdbus: don't force users to
 pass int for bool values
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 17:16 -0700, Eric Blake wrote:
> On 11/20/2014 04:17 PM, Eric Blake wrote:
> > On 11/20/2014 08:12 AM, Conrad Meyer wrote:
> >> Hi Eric,
> >>
> >> I think this change breaks build on FreeBSD:
> >>
> >>   CC       util/libvirt_util_la-virdbus.lo
> >> util/virdbus.c:956:13: error: cast from 'bool *' to 'dbus_bool_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Werror,-Wcast-align]
> >>             GET_NEXT_VAL(dbus_bool_t, bool_val, bool, "%d");
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> util/virdbus.c:858:17: note: expanded from macro 'GET_NEXT_VAL'
> >>             x = (dbustype *)(*xptrptr + (*narrayptr - 1));              \
> >>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.
> > 
> > Valid complaint, so I'll have to figure something out to avoid it.  :(
> > Thanks for the heads up.
> 
> Thanks again for flagging this!
> 
> We had a pre-existing bug.  Even something like "a&n" was broken on
> encoding, because even though type 'n' (int16_t) promotes to a full
> 'int' when parsed via varargs, passing an array of shorts and then
> dereferencing it via (int*) will read beyond array bounds.  We had a
> hole in our testsuite for never testing arrayref with sub-int types,
> even before my commit added 'bool *' to the list of sub-int types that
> we now need to support.

I'm, guessing that this is the same underlying issue as:
        util/virdbus.c: In function 'virDBusMessageIterDecode':
        util/virdbus.c:956:346: error: cast increases required alignment of target type [-Werror=cast-align]
        
which we are seeing in the Xen automated tests [0, 1] (on armhf only,
probably compiler dependent?).

Ian.

[0] http://www.chiark.greenend.org.uk/~xensrcts/logs/31787/build-armhf-libvirt/5.ts-libvirt-build.log
[1] http://www.chiark.greenend.org.uk/~xensrcts/logs/31787/build-armhf-libvirt/info.html



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:44:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqBZ-0004ls-50; Mon, 24 Nov 2014 09:43:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XsqBY-0004ln-HL
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:43:56 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	9B/91-09284-BDDF2745; Mon, 24 Nov 2014 09:43:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416822233!13334720!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20462 invoked from network); 24 Nov 2014 09:43:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 09:43:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="195990297"
Message-ID: <1416822231.26329.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Blake <eblake@redhat.com>
Date: Mon, 24 Nov 2014 09:43:51 +0000
In-Reply-To: <546FD5D2.60400@redhat.com>
References: <20141120101240.2a75f384@m> <546E7674.1060204@redhat.com>
	<546FD5D2.60400@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	cemeyer@uw.edu, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH 1/2] virdbus: don't force users to
 pass int for bool values
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 17:16 -0700, Eric Blake wrote:
> On 11/20/2014 04:17 PM, Eric Blake wrote:
> > On 11/20/2014 08:12 AM, Conrad Meyer wrote:
> >> Hi Eric,
> >>
> >> I think this change breaks build on FreeBSD:
> >>
> >>   CC       util/libvirt_util_la-virdbus.lo
> >> util/virdbus.c:956:13: error: cast from 'bool *' to 'dbus_bool_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Werror,-Wcast-align]
> >>             GET_NEXT_VAL(dbus_bool_t, bool_val, bool, "%d");
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> util/virdbus.c:858:17: note: expanded from macro 'GET_NEXT_VAL'
> >>             x = (dbustype *)(*xptrptr + (*narrayptr - 1));              \
> >>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.
> > 
> > Valid complaint, so I'll have to figure something out to avoid it.  :(
> > Thanks for the heads up.
> 
> Thanks again for flagging this!
> 
> We had a pre-existing bug.  Even something like "a&n" was broken on
> encoding, because even though type 'n' (int16_t) promotes to a full
> 'int' when parsed via varargs, passing an array of shorts and then
> dereferencing it via (int*) will read beyond array bounds.  We had a
> hole in our testsuite for never testing arrayref with sub-int types,
> even before my commit added 'bool *' to the list of sub-int types that
> we now need to support.

I'm, guessing that this is the same underlying issue as:
        util/virdbus.c: In function 'virDBusMessageIterDecode':
        util/virdbus.c:956:346: error: cast increases required alignment of target type [-Werror=cast-align]
        
which we are seeing in the Xen automated tests [0, 1] (on armhf only,
probably compiler dependent?).

Ian.

[0] http://www.chiark.greenend.org.uk/~xensrcts/logs/31787/build-armhf-libvirt/5.ts-libvirt-build.log
[1] http://www.chiark.greenend.org.uk/~xensrcts/logs/31787/build-armhf-libvirt/info.html



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:56:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:56:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqMj-0005B9-5N; Mon, 24 Nov 2014 09:55:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XsqMh-0005B3-H1
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 09:55:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	98/04-25276-E8003745; Mon, 24 Nov 2014 09:55:26 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416822926!14821590!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21887 invoked from network); 24 Nov 2014 09:55:26 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 09:55:26 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A0609ACF1;
	Mon, 24 Nov 2014 09:55:25 +0000 (UTC)
Message-ID: <5473008C.4080604@suse.com>
Date: Mon, 24 Nov 2014 10:55:24 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <546EFAE3.80404@suse.com>
	<20141121135747.GB2886@laptop.dumpdata.com>
In-Reply-To: <20141121135747.GB2886@laptop.dumpdata.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
>> Hi,
>>
>> while testing my "linear p2m list" patches I saw the following
>> problem (even without my patches in place):
>>
>> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
>> disk image of a guest by attaching it to dom0:
>>
>> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
>> mount /dev/xvda2 /mnt
>> ...
>> umount /mnt
>> xl block-detach 0 xvda

Did some more testing:
- Seems to occur only when attaching a block device to dom0, problem
   shows up only after doing the block-detach.
- Sometimes I see only NMI watchdog messages, looking into hanging cpu
   state via xen debug keys I can see the cpu(s) in question are spinning
   in _raw_spin_lock():
   __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
   The hanging cpus were executing some random user processes (cron,
   bash, xargs), cr2 contained user addresses.
- Up to now I've seen the problem on a rather huge machine only (128GB,
   120 cpus). I just did a quick test on my laptop and nothing bad
   happened.
- Even on the huge machine just doing block-attach and block-detach
   without mounting the filesystem on the disk was harmless.

Any ideas how to find the problem?


Juergen

>>
>> Worked without any problem. After some seconds the following messages
>> were issued on the console:
>>
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61110 (pfn 1f3f21c)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61110
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61110 (pfn 1f3f21c)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61111 (pfn 1f3f21d)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61111
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61111 (pfn 1f3f21d)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61120 (pfn 1f3f22c)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61120
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61120 (pfn 1f3f22c)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61121 (pfn 1f3f22d)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61121
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61121 (pfn 1f3f22d)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61102 (pfn 1f3f20e)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61102
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61102 (pfn 1f3f20e)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61103 (pfn 1f3f20f)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61103
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61103 (pfn 1f3f20f)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>>
>> Is this a known issue?
>
> No. First time I see it.
>>
>>
>> Juergen
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:56:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:56:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqMj-0005B9-5N; Mon, 24 Nov 2014 09:55:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XsqMh-0005B3-H1
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 09:55:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	98/04-25276-E8003745; Mon, 24 Nov 2014 09:55:26 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416822926!14821590!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21887 invoked from network); 24 Nov 2014 09:55:26 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 09:55:26 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A0609ACF1;
	Mon, 24 Nov 2014 09:55:25 +0000 (UTC)
Message-ID: <5473008C.4080604@suse.com>
Date: Mon, 24 Nov 2014 10:55:24 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <546EFAE3.80404@suse.com>
	<20141121135747.GB2886@laptop.dumpdata.com>
In-Reply-To: <20141121135747.GB2886@laptop.dumpdata.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
>> Hi,
>>
>> while testing my "linear p2m list" patches I saw the following
>> problem (even without my patches in place):
>>
>> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
>> disk image of a guest by attaching it to dom0:
>>
>> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
>> mount /dev/xvda2 /mnt
>> ...
>> umount /mnt
>> xl block-detach 0 xvda

Did some more testing:
- Seems to occur only when attaching a block device to dom0, problem
   shows up only after doing the block-detach.
- Sometimes I see only NMI watchdog messages, looking into hanging cpu
   state via xen debug keys I can see the cpu(s) in question are spinning
   in _raw_spin_lock():
   __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
   The hanging cpus were executing some random user processes (cron,
   bash, xargs), cr2 contained user addresses.
- Up to now I've seen the problem on a rather huge machine only (128GB,
   120 cpus). I just did a quick test on my laptop and nothing bad
   happened.
- Even on the huge machine just doing block-attach and block-detach
   without mounting the filesystem on the disk was harmless.

Any ideas how to find the problem?


Juergen

>>
>> Worked without any problem. After some seconds the following messages
>> were issued on the console:
>>
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61110 (pfn 1f3f21c)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61110
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61110 (pfn 1f3f21c)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61111 (pfn 1f3f21d)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61111
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61111 (pfn 1f3f21d)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61120 (pfn 1f3f22c)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61120
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61120 (pfn 1f3f22c)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61121 (pfn 1f3f22d)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61121
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61121 (pfn 1f3f22d)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61102 (pfn 1f3f20e)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61102
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61102 (pfn 1f3f20e)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61103 (pfn 1f3f20f)
>> (XEN) mm.c:2995:d0 Error while pinning mfn 61103
>> (XEN) mm.c:2352:d0 Bad type (saw 7400000000000002 != exp 1000000000000000)
>> for mfn 61103 (pfn 1f3f20f)
>> (XEN) mm.c:906:d0 Attempt to create linear p.t. with write perms
>>
>> Is this a known issue?
>
> No. First time I see it.
>>
>>
>> Juergen
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 09:58:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqPi-0005Ku-Rk; Mon, 24 Nov 2014 09:58:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XsqPi-0005Ko-2x
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:58:34 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	04/AF-31453-94103745; Mon, 24 Nov 2014 09:58:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416823112!12964715!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25093 invoked from network); 24 Nov 2014 09:58:32 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 09:58:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 09:58:32 +0000
Message-Id: <54730F55020000780004A370@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 09:58:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-12-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-12-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/19] hvmloader: add new fields for vNUMA
 information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> --- a/xen/include/public/hvm/hvm_info_table.h
> +++ b/xen/include/public/hvm/hvm_info_table.h
> @@ -32,6 +32,17 @@
>  /* Maximum we can support with current vLAPIC ID mapping. */
>  #define HVM_MAX_VCPUS        128
>  
> +#define HVM_MAX_NODES         16
> +#define HVM_MAX_LOCALITIES    (HVM_MAX_NODES * HVM_MAX_NODES)
> +
> +#define HVM_MAX_VMEMRANGES    64
> +struct hvm_info_vmemrange {
> +    uint64_t start;
> +    uint64_t end;
> +    uint32_t flags;
> +    uint32_t nid;
> +};
> +
>  struct hvm_info_table {
>      char        signature[8]; /* "HVM INFO" */
>      uint32_t    length;
> @@ -67,6 +78,14 @@ struct hvm_info_table {
>  
>      /* Bitmap of which CPUs are online at boot time. */
>      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
> +
> +    /* Virtual NUMA information */
> +    uint32_t    nr_nodes;
> +    uint8_t     vcpu_to_vnode[HVM_MAX_VCPUS];
> +    uint32_t    nr_vmemranges;
> +    struct hvm_info_vmemrange vmemranges[HVM_MAX_VMEMRANGES];
> +    uint64_t    nr_localities;
> +    uint8_t     localities[HVM_MAX_LOCALITIES];
>  };
>  
>  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */

Is this really the right place? This is a public interface, which we
shouldn't modify in ways making future changes more cumbersome.
In particular, once we finally get the LAPIC ID brokenness fixed,
HVM_MAX_VCPUS won't need to be limited to 128 anymore. And
we likely would want to keep things simple an retain the bitmap
where it currently sits, just extending its size. With all of the data
above (supposedly, or we made a mistake somewhere) being
retrievable via hypercall, what is the rationale for doing things
this way in the first place (the lack of any kind of description is of
course not really helpful 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 Nov 24 09:58:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 09:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqPi-0005Ku-Rk; Mon, 24 Nov 2014 09:58:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XsqPi-0005Ko-2x
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 09:58:34 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	04/AF-31453-94103745; Mon, 24 Nov 2014 09:58:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416823112!12964715!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25093 invoked from network); 24 Nov 2014 09:58:32 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 09:58:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 09:58:32 +0000
Message-Id: <54730F55020000780004A370@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 09:58:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-12-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-12-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/19] hvmloader: add new fields for vNUMA
 information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> --- a/xen/include/public/hvm/hvm_info_table.h
> +++ b/xen/include/public/hvm/hvm_info_table.h
> @@ -32,6 +32,17 @@
>  /* Maximum we can support with current vLAPIC ID mapping. */
>  #define HVM_MAX_VCPUS        128
>  
> +#define HVM_MAX_NODES         16
> +#define HVM_MAX_LOCALITIES    (HVM_MAX_NODES * HVM_MAX_NODES)
> +
> +#define HVM_MAX_VMEMRANGES    64
> +struct hvm_info_vmemrange {
> +    uint64_t start;
> +    uint64_t end;
> +    uint32_t flags;
> +    uint32_t nid;
> +};
> +
>  struct hvm_info_table {
>      char        signature[8]; /* "HVM INFO" */
>      uint32_t    length;
> @@ -67,6 +78,14 @@ struct hvm_info_table {
>  
>      /* Bitmap of which CPUs are online at boot time. */
>      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
> +
> +    /* Virtual NUMA information */
> +    uint32_t    nr_nodes;
> +    uint8_t     vcpu_to_vnode[HVM_MAX_VCPUS];
> +    uint32_t    nr_vmemranges;
> +    struct hvm_info_vmemrange vmemranges[HVM_MAX_VMEMRANGES];
> +    uint64_t    nr_localities;
> +    uint8_t     localities[HVM_MAX_LOCALITIES];
>  };
>  
>  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */

Is this really the right place? This is a public interface, which we
shouldn't modify in ways making future changes more cumbersome.
In particular, once we finally get the LAPIC ID brokenness fixed,
HVM_MAX_VCPUS won't need to be limited to 128 anymore. And
we likely would want to keep things simple an retain the bitmap
where it currently sits, just extending its size. With all of the data
above (supposedly, or we made a mistake somewhere) being
retrievable via hypercall, what is the rationale for doing things
this way in the first place (the lack of any kind of description is of
course not really helpful 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 Nov 24 10:00:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:00:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqRS-0005Xr-CS; Mon, 24 Nov 2014 10:00:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XsqRR-0005Xj-36
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:00:21 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	68/CD-09842-4B103745; Mon, 24 Nov 2014 10:00:20 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416823219!11402568!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30292 invoked from network); 24 Nov 2014 10:00:19 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-16.tower-21.messagelabs.com with SMTP;
	24 Nov 2014 10:00:19 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sAO9xoEA014700;
	Mon, 24 Nov 2014 03:59:50 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sAO9xnqh014699;
	Mon, 24 Nov 2014 03:59:49 -0600
Date: Mon, 24 Nov 2014 03:59:49 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201411240959.sAO9xnqh014699@wind.enjellic.com>
In-Reply-To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
	"Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind." (Nov
	23, 4:26pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Mon, 24 Nov 2014 03:59:50 -0600 (CST)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Nov 23,  4:26pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:
} Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.

Hi Pasi, hope your week is starting out well, hi to Konrad from Oracle
as well as I see you included him.

> On Fri, Nov 21, 2014 at 02:57:14PM -0600, Dr. Greg Wettstein wrote:
> > Hi, hope the week is ending well for everyone.
> > 
> > As readers of the list may remember we've kept the ATI primary adapter
> > passthrough patches current for qemu-traditional on Xen for a number
> > of years.  Our 'run-passthrough' utility for binding/unbind devices
> > and running a Windows guest with passthrough have enjoyed a tidy
> > number of downloads through the years as well.
> > 
> > We are taking on a passthrough project and in the process upgrading
> > our infrastructure to 4.4.x.  We also need to take on the issue of
> > passing Intel IGD adapters through to a windows guest.  We are
> > currently working on an Intel Q77 (DQ77KB) board in preparation for
> > moving to Q87 boards.
> > 
> > The Intel display adapter is showing up as the standard 00:02.0 PCI
> > device and things go south pretty quickly.  We create a slot for the
> > device on the pciback driver and as soon as we bind the device the
> > machine goes out like a light, no logs or diagnostics, just instantly
> > stone dead.

I'm consolidating your comment from your other response as well so we
keep this on the same thread.

>> As I was walking out the door I remembered I had been delinquent
>> with information.  The dom0 kernel is 32-bit 3.14.22 straight from
>> kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.

> Wow, quite an old thread :)
>  
> So you're still seeing the same problem with recent Xen/Linux
> versions.. 

Yes, the perils of platforming for 7 year field deployments... :-)

I can certainly build up a toolchain against the HEAD of XEN git and
the most recent release of the kernel if everyone feels that would be
beneficial.

> This might be a stupid question, but here goes anyway: Do you have
> serial console set up? And all the debug/verbose options specified
> for Xen and Linux?

The platform in question doesn't have any serial ports, at least not
surfaced.  We will need to do a bit of wiring if we need to go in that
direction.

Now that I have the machine in a harness in the lab I will stick a
'#define DEBUG 1' in the top of drivers/xen/xen-pciback/pci_stub.c
since that is where the action seems to be going on.

The platform is headed for a measured computing environment so I
thought there may be some type of conflict with tboot holding a
reference to the VGA driver but I verified the issue in a straight
hypervisor boot.

I see that Tiejun Chen from Intel is sorting out issues with respect
to the need to export the ISA bridge into the device emulator in order
to support passthrough on these IGD devices.  I bound the 00:1f.0 ISA
bridge device to pciback and that worked but it did not change the
behavior of the regression.  When the 00:02.0 device is bound to
pciback the display is cleared and the machine dies in its tracks.

I will turn up debugging in pci_stub and see if I can pinpoint where
things blow up, somewhere in pcistub_init_device() I would imagine.

> Thanks,
> 
> -- Pasi

Have a good day.

}-- End of excerpt from Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Snow removal teaches all the important elements of succesful corporate
 politics:  1.) Be the first one to work.  2.) Always signal your
 intentions before moving.  3.) Be damn sure you're driving something
 big enough to deal with anything that decides not to get out of your way."
                                -- Dr. G.W. Wettstein
                                   Guerrilla Tactics for Corporate Survival

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:00:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:00:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqRS-0005Xr-CS; Mon, 24 Nov 2014 10:00:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XsqRR-0005Xj-36
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:00:21 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	68/CD-09842-4B103745; Mon, 24 Nov 2014 10:00:20 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416823219!11402568!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30292 invoked from network); 24 Nov 2014 10:00:19 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-16.tower-21.messagelabs.com with SMTP;
	24 Nov 2014 10:00:19 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sAO9xoEA014700;
	Mon, 24 Nov 2014 03:59:50 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sAO9xnqh014699;
	Mon, 24 Nov 2014 03:59:49 -0600
Date: Mon, 24 Nov 2014 03:59:49 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201411240959.sAO9xnqh014699@wind.enjellic.com>
In-Reply-To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
	"Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind." (Nov
	23, 4:26pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Mon, 24 Nov 2014 03:59:50 -0600 (CST)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Nov 23,  4:26pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:
} Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.

Hi Pasi, hope your week is starting out well, hi to Konrad from Oracle
as well as I see you included him.

> On Fri, Nov 21, 2014 at 02:57:14PM -0600, Dr. Greg Wettstein wrote:
> > Hi, hope the week is ending well for everyone.
> > 
> > As readers of the list may remember we've kept the ATI primary adapter
> > passthrough patches current for qemu-traditional on Xen for a number
> > of years.  Our 'run-passthrough' utility for binding/unbind devices
> > and running a Windows guest with passthrough have enjoyed a tidy
> > number of downloads through the years as well.
> > 
> > We are taking on a passthrough project and in the process upgrading
> > our infrastructure to 4.4.x.  We also need to take on the issue of
> > passing Intel IGD adapters through to a windows guest.  We are
> > currently working on an Intel Q77 (DQ77KB) board in preparation for
> > moving to Q87 boards.
> > 
> > The Intel display adapter is showing up as the standard 00:02.0 PCI
> > device and things go south pretty quickly.  We create a slot for the
> > device on the pciback driver and as soon as we bind the device the
> > machine goes out like a light, no logs or diagnostics, just instantly
> > stone dead.

I'm consolidating your comment from your other response as well so we
keep this on the same thread.

>> As I was walking out the door I remembered I had been delinquent
>> with information.  The dom0 kernel is 32-bit 3.14.22 straight from
>> kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.

> Wow, quite an old thread :)
>  
> So you're still seeing the same problem with recent Xen/Linux
> versions.. 

Yes, the perils of platforming for 7 year field deployments... :-)

I can certainly build up a toolchain against the HEAD of XEN git and
the most recent release of the kernel if everyone feels that would be
beneficial.

> This might be a stupid question, but here goes anyway: Do you have
> serial console set up? And all the debug/verbose options specified
> for Xen and Linux?

The platform in question doesn't have any serial ports, at least not
surfaced.  We will need to do a bit of wiring if we need to go in that
direction.

Now that I have the machine in a harness in the lab I will stick a
'#define DEBUG 1' in the top of drivers/xen/xen-pciback/pci_stub.c
since that is where the action seems to be going on.

The platform is headed for a measured computing environment so I
thought there may be some type of conflict with tboot holding a
reference to the VGA driver but I verified the issue in a straight
hypervisor boot.

I see that Tiejun Chen from Intel is sorting out issues with respect
to the need to export the ISA bridge into the device emulator in order
to support passthrough on these IGD devices.  I bound the 00:1f.0 ISA
bridge device to pciback and that worked but it did not change the
behavior of the regression.  When the 00:02.0 device is bound to
pciback the display is cleared and the machine dies in its tracks.

I will turn up debugging in pci_stub and see if I can pinpoint where
things blow up, somewhere in pcistub_init_device() I would imagine.

> Thanks,
> 
> -- Pasi

Have a good day.

}-- End of excerpt from Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Snow removal teaches all the important elements of succesful corporate
 politics:  1.) Be the first one to work.  2.) Always signal your
 intentions before moving.  3.) Be damn sure you're driving something
 big enough to deal with anything that decides not to get out of your way."
                                -- Dr. G.W. Wettstein
                                   Guerrilla Tactics for Corporate Survival

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:01:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:01:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqSS-0005d9-AO; Mon, 24 Nov 2014 10:01:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsqSR-0005d3-IG
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 10:01:23 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	E4/0C-02697-2F103745; Mon, 24 Nov 2014 10:01:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416823279!12956123!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32517 invoked from network); 24 Nov 2014 10:01:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:01:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195994710"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:00:54 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsqRx-0003Aq-Ur;
	Mon, 24 Nov 2014 10:00:53 +0000
Date: Mon, 24 Nov 2014 10:00:53 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Alexey Khoroshilov <khoroshilov@ispras.ru>
Message-ID: <20141124100053.GC30053@zion.uk.xensource.com>
References: <1416610588-19816-1-git-send-email-khoroshilov@ispras.ru>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416610588-19816-1-git-send-email-khoroshilov@ispras.ru>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ldv-project@linuxtesting.org, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netback: do not report success if
 xenvif_alloc() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Nov 22, 2014 at 01:56:28AM +0300, Alexey Khoroshilov wrote:
> If xenvif_alloc() failes, netback_probe() reports success as well as
> "online" uevent is emitted. It does not make any sense, but it just

Sorry, I don't follow. KOBJ_ONLINE event is not emitted in the event of
xenvif_alloc fails, is it?

> misleads users.
> 
> The patch implements propagation of error code if xenvif creation fails.
> 

This patch not only implements propagation of error code when xenvif
creation fails, but also when xenbus_scanf fails. You can simply write
"This patch implements propagation of error code for
backend_create_xenvif".

The rest of this patch looks good to me. Can you rewrite commit message
and resubmit, thanks.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:01:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:01:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqSS-0005d9-AO; Mon, 24 Nov 2014 10:01:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsqSR-0005d3-IG
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 10:01:23 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	E4/0C-02697-2F103745; Mon, 24 Nov 2014 10:01:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416823279!12956123!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32517 invoked from network); 24 Nov 2014 10:01:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:01:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195994710"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:00:54 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsqRx-0003Aq-Ur;
	Mon, 24 Nov 2014 10:00:53 +0000
Date: Mon, 24 Nov 2014 10:00:53 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Alexey Khoroshilov <khoroshilov@ispras.ru>
Message-ID: <20141124100053.GC30053@zion.uk.xensource.com>
References: <1416610588-19816-1-git-send-email-khoroshilov@ispras.ru>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416610588-19816-1-git-send-email-khoroshilov@ispras.ru>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ldv-project@linuxtesting.org, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netback: do not report success if
 xenvif_alloc() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Nov 22, 2014 at 01:56:28AM +0300, Alexey Khoroshilov wrote:
> If xenvif_alloc() failes, netback_probe() reports success as well as
> "online" uevent is emitted. It does not make any sense, but it just

Sorry, I don't follow. KOBJ_ONLINE event is not emitted in the event of
xenvif_alloc fails, is it?

> misleads users.
> 
> The patch implements propagation of error code if xenvif creation fails.
> 

This patch not only implements propagation of error code when xenvif
creation fails, but also when xenbus_scanf fails. You can simply write
"This patch implements propagation of error code for
backend_create_xenvif".

The rest of this patch looks good to me. Can you rewrite commit message
and resubmit, thanks.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:02:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:02:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqTF-0005mZ-Tk; Mon, 24 Nov 2014 10:02:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XsqTE-0005mC-2K
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 10:02:12 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	C8/D9-25547-32203745; Mon, 24 Nov 2014 10:02:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416823329!13340361!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28889 invoked from network); 24 Nov 2014 10:02:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:02:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195995174"
Message-ID: <1416823327.26329.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <jgross@suse.com>
Date: Mon, 24 Nov 2014 10:02:07 +0000
In-Reply-To: <5473008C.4080604@suse.com>
References: <546EFAE3.80404@suse.com>
	<20141121135747.GB2886@laptop.dumpdata.com> <5473008C.4080604@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-rc5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
> On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
> >> Hi,
> >>
> >> while testing my "linear p2m list" patches I saw the following
> >> problem (even without my patches in place):
> >>
> >> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
> >> disk image of a guest by attaching it to dom0:
> >>
> >> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
> >> mount /dev/xvda2 /mnt
> >> ...
> >> umount /mnt
> >> xl block-detach 0 xvda
> 
> Did some more testing:
> - Seems to occur only when attaching a block device to dom0

That means a qdisk backed situation then, I think.

Is your qemu up to date?

http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=commit;h=abbbc2f09a53f8f9ee565356ab11a78af006e45e resulted in slightly different messages, but could be related?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:02:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:02:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqTF-0005mZ-Tk; Mon, 24 Nov 2014 10:02:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XsqTE-0005mC-2K
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 10:02:12 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	C8/D9-25547-32203745; Mon, 24 Nov 2014 10:02:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416823329!13340361!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28889 invoked from network); 24 Nov 2014 10:02:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:02:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195995174"
Message-ID: <1416823327.26329.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <jgross@suse.com>
Date: Mon, 24 Nov 2014 10:02:07 +0000
In-Reply-To: <5473008C.4080604@suse.com>
References: <546EFAE3.80404@suse.com>
	<20141121135747.GB2886@laptop.dumpdata.com> <5473008C.4080604@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-rc5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
> On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
> >> Hi,
> >>
> >> while testing my "linear p2m list" patches I saw the following
> >> problem (even without my patches in place):
> >>
> >> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
> >> disk image of a guest by attaching it to dom0:
> >>
> >> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
> >> mount /dev/xvda2 /mnt
> >> ...
> >> umount /mnt
> >> xl block-detach 0 xvda
> 
> Did some more testing:
> - Seems to occur only when attaching a block device to dom0

That means a qdisk backed situation then, I think.

Is your qemu up to date?

http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=commit;h=abbbc2f09a53f8f9ee565356ab11a78af006e45e resulted in slightly different messages, but could be related?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:08:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 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.xen.org>)
	id 1XsqYW-00068y-T7; Mon, 24 Nov 2014 10:07:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsqYW-00068p-AO
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:07:40 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	A1/9A-02699-A6303745; Mon, 24 Nov 2014 10:07:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416823656!14377495!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25102 invoked from network); 24 Nov 2014 10:07: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;
	24 Nov 2014 10:07:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195997105"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:07:35 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsqYR-0003Q8-Np;
	Mon, 24 Nov 2014 10:07:35 +0000
Date: Mon, 24 Nov 2014 10:07:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124100735.GD30053@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-12-git-send-email-wei.liu2@citrix.com>
	<54730F55020000780004A370@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54730F55020000780004A370@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/19] hvmloader: add new fields for vNUMA
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 09:58:29AM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> > --- a/xen/include/public/hvm/hvm_info_table.h
> > +++ b/xen/include/public/hvm/hvm_info_table.h
> > @@ -32,6 +32,17 @@
> >  /* Maximum we can support with current vLAPIC ID mapping. */
> >  #define HVM_MAX_VCPUS        128
> >  
> > +#define HVM_MAX_NODES         16
> > +#define HVM_MAX_LOCALITIES    (HVM_MAX_NODES * HVM_MAX_NODES)
> > +
> > +#define HVM_MAX_VMEMRANGES    64
> > +struct hvm_info_vmemrange {
> > +    uint64_t start;
> > +    uint64_t end;
> > +    uint32_t flags;
> > +    uint32_t nid;
> > +};
> > +
> >  struct hvm_info_table {
> >      char        signature[8]; /* "HVM INFO" */
> >      uint32_t    length;
> > @@ -67,6 +78,14 @@ struct hvm_info_table {
> >  
> >      /* Bitmap of which CPUs are online at boot time. */
> >      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
> > +
> > +    /* Virtual NUMA information */
> > +    uint32_t    nr_nodes;
> > +    uint8_t     vcpu_to_vnode[HVM_MAX_VCPUS];
> > +    uint32_t    nr_vmemranges;
> > +    struct hvm_info_vmemrange vmemranges[HVM_MAX_VMEMRANGES];
> > +    uint64_t    nr_localities;
> > +    uint8_t     localities[HVM_MAX_LOCALITIES];
> >  };
> >  
> >  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */
> 
> Is this really the right place? This is a public interface, which we
> shouldn't modify in ways making future changes more cumbersome.
> In particular, once we finally get the LAPIC ID brokenness fixed,
> HVM_MAX_VCPUS won't need to be limited to 128 anymore. And
> we likely would want to keep things simple an retain the bitmap
> where it currently sits, just extending its size. With all of the data
> above (supposedly, or we made a mistake somewhere) being
> retrievable via hypercall, what is the rationale for doing things
> this way in the first place (the lack of any kind of description is of
> course not really helpful here)?
> 

My thought was that this is interface between libxl and hvmloader, and
the way it's used suggests that this is canonical way of doing things. I
might have got this wrong in the first place.

So I take it you're of the opinion this piece of information should be
retrieved via hypercall in hvmloader, right? That's OK (and even better)
for me.

Wei.


> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:08:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 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.xen.org>)
	id 1XsqYW-00068y-T7; Mon, 24 Nov 2014 10:07:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsqYW-00068p-AO
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:07:40 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	A1/9A-02699-A6303745; Mon, 24 Nov 2014 10:07:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416823656!14377495!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25102 invoked from network); 24 Nov 2014 10:07: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;
	24 Nov 2014 10:07:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195997105"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:07:35 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsqYR-0003Q8-Np;
	Mon, 24 Nov 2014 10:07:35 +0000
Date: Mon, 24 Nov 2014 10:07:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124100735.GD30053@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-12-git-send-email-wei.liu2@citrix.com>
	<54730F55020000780004A370@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54730F55020000780004A370@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/19] hvmloader: add new fields for vNUMA
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 09:58:29AM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> > --- a/xen/include/public/hvm/hvm_info_table.h
> > +++ b/xen/include/public/hvm/hvm_info_table.h
> > @@ -32,6 +32,17 @@
> >  /* Maximum we can support with current vLAPIC ID mapping. */
> >  #define HVM_MAX_VCPUS        128
> >  
> > +#define HVM_MAX_NODES         16
> > +#define HVM_MAX_LOCALITIES    (HVM_MAX_NODES * HVM_MAX_NODES)
> > +
> > +#define HVM_MAX_VMEMRANGES    64
> > +struct hvm_info_vmemrange {
> > +    uint64_t start;
> > +    uint64_t end;
> > +    uint32_t flags;
> > +    uint32_t nid;
> > +};
> > +
> >  struct hvm_info_table {
> >      char        signature[8]; /* "HVM INFO" */
> >      uint32_t    length;
> > @@ -67,6 +78,14 @@ struct hvm_info_table {
> >  
> >      /* Bitmap of which CPUs are online at boot time. */
> >      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
> > +
> > +    /* Virtual NUMA information */
> > +    uint32_t    nr_nodes;
> > +    uint8_t     vcpu_to_vnode[HVM_MAX_VCPUS];
> > +    uint32_t    nr_vmemranges;
> > +    struct hvm_info_vmemrange vmemranges[HVM_MAX_VMEMRANGES];
> > +    uint64_t    nr_localities;
> > +    uint8_t     localities[HVM_MAX_LOCALITIES];
> >  };
> >  
> >  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */
> 
> Is this really the right place? This is a public interface, which we
> shouldn't modify in ways making future changes more cumbersome.
> In particular, once we finally get the LAPIC ID brokenness fixed,
> HVM_MAX_VCPUS won't need to be limited to 128 anymore. And
> we likely would want to keep things simple an retain the bitmap
> where it currently sits, just extending its size. With all of the data
> above (supposedly, or we made a mistake somewhere) being
> retrievable via hypercall, what is the rationale for doing things
> this way in the first place (the lack of any kind of description is of
> course not really helpful here)?
> 

My thought was that this is interface between libxl and hvmloader, and
the way it's used suggests that this is canonical way of doing things. I
might have got this wrong in the first place.

So I take it you're of the opinion this piece of information should be
retrieved via hypercall in hvmloader, right? That's OK (and even better)
for me.

Wei.


> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:09:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqZe-0006FT-BV; Mon, 24 Nov 2014 10:08:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XsqZc-0006FJ-Jy
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:08:48 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	A7/18-02696-FA303745; Mon, 24 Nov 2014 10:08:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416823727!14377912!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4249 invoked from network); 24 Nov 2014 10:08:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:08:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:08:47 +0000
Message-Id: <547311BA020000780004A39E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:08:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/19] hvmloader: construct SRAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -203,6 +203,66 @@ static struct acpi_20_waet *construct_waet(void)
>      return waet;
>  }
>  
> +static struct acpi_20_srat *construct_srat(void)
> +{
> +    struct acpi_20_srat *srat;
> +    struct acpi_20_srat_processor *processor;
> +    struct acpi_20_srat_memory *memory;
> +    unsigned int size;
> +    void *p;
> +    int i;
> +    uint64_t mem;
> +
> +    size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
> +        sizeof(*memory) * hvm_info->nr_vmemranges;
> +
> +    p = mem_alloc(size, 16);
> +    if (!p) return NULL;
> +
> +    srat = p;
> +    memset(srat, 0, sizeof(*srat));
> +    srat->header.signature    = ACPI_2_0_SRAT_SIGNATURE;
> +    srat->header.revision     = ACPI_2_0_SRAT_REVISION;
> +    fixed_strcpy(srat->header.oem_id, ACPI_OEM_ID);
> +    fixed_strcpy(srat->header.oem_table_id, ACPI_OEM_TABLE_ID);
> +    srat->header.oem_revision = ACPI_OEM_REVISION;
> +    srat->header.creator_id   = ACPI_CREATOR_ID;
> +    srat->header.creator_revision = ACPI_CREATOR_REVISION;
> +    srat->table_revision      = ACPI_SRAT_TABLE_REVISION;
> +
> +    processor = (struct acpi_20_srat_processor *)(srat + 1);
> +    for ( i = 0; i < hvm_info->nr_vcpus; i++ )
> +    {
> +        memset(processor, 0, sizeof(*processor));
> +        processor->type     = ACPI_PROCESSOR_AFFINITY;
> +        processor->length   = sizeof(*processor);
> +        processor->domain   = hvm_info->vcpu_to_vnode[i];
> +        processor->apic_id  = LAPIC_ID(i);
> +        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
> +        processor->sapic_id = 0;

Either you initialize all fields explicitly and drop the memset(), or
you consistently avoid explicit zero initializers (as being redundant).

> @@ -270,6 +331,13 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
>          table_ptrs[nr_tables++] = (unsigned long)madt;
>      }
>  
> +    if ( hvm_info->nr_nodes > 0 )
> +    {
> +        srat = construct_srat();
> +        if (!srat) return -1;

I don't think failure to set up secondary information (especially when
it requires a variable size table and hence has [slightly] higher
likelihood of table space allocation failing) should result in skipping
other table setup.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:09:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqZe-0006FT-BV; Mon, 24 Nov 2014 10:08:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XsqZc-0006FJ-Jy
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:08:48 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	A7/18-02696-FA303745; Mon, 24 Nov 2014 10:08:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416823727!14377912!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4249 invoked from network); 24 Nov 2014 10:08:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:08:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:08:47 +0000
Message-Id: <547311BA020000780004A39E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:08:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/19] hvmloader: construct SRAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -203,6 +203,66 @@ static struct acpi_20_waet *construct_waet(void)
>      return waet;
>  }
>  
> +static struct acpi_20_srat *construct_srat(void)
> +{
> +    struct acpi_20_srat *srat;
> +    struct acpi_20_srat_processor *processor;
> +    struct acpi_20_srat_memory *memory;
> +    unsigned int size;
> +    void *p;
> +    int i;
> +    uint64_t mem;
> +
> +    size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
> +        sizeof(*memory) * hvm_info->nr_vmemranges;
> +
> +    p = mem_alloc(size, 16);
> +    if (!p) return NULL;
> +
> +    srat = p;
> +    memset(srat, 0, sizeof(*srat));
> +    srat->header.signature    = ACPI_2_0_SRAT_SIGNATURE;
> +    srat->header.revision     = ACPI_2_0_SRAT_REVISION;
> +    fixed_strcpy(srat->header.oem_id, ACPI_OEM_ID);
> +    fixed_strcpy(srat->header.oem_table_id, ACPI_OEM_TABLE_ID);
> +    srat->header.oem_revision = ACPI_OEM_REVISION;
> +    srat->header.creator_id   = ACPI_CREATOR_ID;
> +    srat->header.creator_revision = ACPI_CREATOR_REVISION;
> +    srat->table_revision      = ACPI_SRAT_TABLE_REVISION;
> +
> +    processor = (struct acpi_20_srat_processor *)(srat + 1);
> +    for ( i = 0; i < hvm_info->nr_vcpus; i++ )
> +    {
> +        memset(processor, 0, sizeof(*processor));
> +        processor->type     = ACPI_PROCESSOR_AFFINITY;
> +        processor->length   = sizeof(*processor);
> +        processor->domain   = hvm_info->vcpu_to_vnode[i];
> +        processor->apic_id  = LAPIC_ID(i);
> +        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
> +        processor->sapic_id = 0;

Either you initialize all fields explicitly and drop the memset(), or
you consistently avoid explicit zero initializers (as being redundant).

> @@ -270,6 +331,13 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
>          table_ptrs[nr_tables++] = (unsigned long)madt;
>      }
>  
> +    if ( hvm_info->nr_nodes > 0 )
> +    {
> +        srat = construct_srat();
> +        if (!srat) return -1;

I don't think failure to set up secondary information (especially when
it requires a variable size table and hence has [slightly] higher
likelihood of table space allocation failing) should result in skipping
other table setup.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:12:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsqce-0006Tj-1r; Mon, 24 Nov 2014 10:11:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xsqcc-0006TA-K7
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:11:54 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	65/2E-09284-66403745; Mon, 24 Nov 2014 10:11:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416823910!8952059!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27345 invoked from network); 24 Nov 2014 10:11:50 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:11:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:11:50 +0000
Message-Id: <54731272020000780004A3A1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:11:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-14-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-14-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 13/19] hvmloader: construct SLIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -263,6 +263,38 @@ static struct acpi_20_srat *construct_srat(void)
>      return srat;
>  }
>  
> +static struct acpi_20_slit *construct_slit(void)
> +{
> +    struct acpi_20_slit *slit;
> +    unsigned int num, size;
> +    int i;
>[...]
> +    for ( i = 0; i < num; i++ )

How can i be signed here when num is unsigned. Even without the
common desire to have variables that can't be negative declared
unsigned, inconsistencies like this should be avoided.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:12:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsqce-0006Tj-1r; Mon, 24 Nov 2014 10:11:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xsqcc-0006TA-K7
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:11:54 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	65/2E-09284-66403745; Mon, 24 Nov 2014 10:11:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416823910!8952059!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27345 invoked from network); 24 Nov 2014 10:11:50 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:11:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:11:50 +0000
Message-Id: <54731272020000780004A3A1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:11:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-14-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-14-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 13/19] hvmloader: construct SLIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -263,6 +263,38 @@ static struct acpi_20_srat *construct_srat(void)
>      return srat;
>  }
>  
> +static struct acpi_20_slit *construct_slit(void)
> +{
> +    struct acpi_20_slit *slit;
> +    unsigned int num, size;
> +    int i;
>[...]
> +    for ( i = 0; i < num; i++ )

How can i be signed here when num is unsigned. Even without the
common desire to have variables that can't be negative declared
unsigned, inconsistencies like this should be avoided.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:13:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:13:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqeO-0006e5-IU; Mon, 24 Nov 2014 10:13:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsqeN-0006dx-Tj
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:13:44 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	06/5C-25276-7D403745; Mon, 24 Nov 2014 10:13:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416824021!14867008!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20171 invoked from network); 24 Nov 2014 10:13:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:13:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195998587"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:13:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsqeK-0003Wa-Kq;
	Mon, 24 Nov 2014 10:13:40 +0000
Date: Mon, 24 Nov 2014 10:13:40 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124101340.GE30053@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
	<547311BA020000780004A39E@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547311BA020000780004A39E@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/19] hvmloader: construct SRAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 10:08:42AM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> > --- a/tools/firmware/hvmloader/acpi/build.c
> > +++ b/tools/firmware/hvmloader/acpi/build.c
> > @@ -203,6 +203,66 @@ static struct acpi_20_waet *construct_waet(void)
> >      return waet;
> >  }
> >  
> > +static struct acpi_20_srat *construct_srat(void)
> > +{
> > +    struct acpi_20_srat *srat;
> > +    struct acpi_20_srat_processor *processor;
> > +    struct acpi_20_srat_memory *memory;
> > +    unsigned int size;
> > +    void *p;
> > +    int i;
> > +    uint64_t mem;
> > +
> > +    size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
> > +        sizeof(*memory) * hvm_info->nr_vmemranges;
> > +
> > +    p = mem_alloc(size, 16);
> > +    if (!p) return NULL;
> > +
> > +    srat = p;
> > +    memset(srat, 0, sizeof(*srat));
> > +    srat->header.signature    = ACPI_2_0_SRAT_SIGNATURE;
> > +    srat->header.revision     = ACPI_2_0_SRAT_REVISION;
> > +    fixed_strcpy(srat->header.oem_id, ACPI_OEM_ID);
> > +    fixed_strcpy(srat->header.oem_table_id, ACPI_OEM_TABLE_ID);
> > +    srat->header.oem_revision = ACPI_OEM_REVISION;
> > +    srat->header.creator_id   = ACPI_CREATOR_ID;
> > +    srat->header.creator_revision = ACPI_CREATOR_REVISION;
> > +    srat->table_revision      = ACPI_SRAT_TABLE_REVISION;
> > +
> > +    processor = (struct acpi_20_srat_processor *)(srat + 1);
> > +    for ( i = 0; i < hvm_info->nr_vcpus; i++ )
> > +    {
> > +        memset(processor, 0, sizeof(*processor));
> > +        processor->type     = ACPI_PROCESSOR_AFFINITY;
> > +        processor->length   = sizeof(*processor);
> > +        processor->domain   = hvm_info->vcpu_to_vnode[i];
> > +        processor->apic_id  = LAPIC_ID(i);
> > +        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
> > +        processor->sapic_id = 0;
> 
> Either you initialize all fields explicitly and drop the memset(), or
> you consistently avoid explicit zero initializers (as being redundant).
> 

Ack.

> > @@ -270,6 +331,13 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
> >          table_ptrs[nr_tables++] = (unsigned long)madt;
> >      }
> >  
> > +    if ( hvm_info->nr_nodes > 0 )
> > +    {
> > +        srat = construct_srat();
> > +        if (!srat) return -1;
> 
> I don't think failure to set up secondary information (especially when
> it requires a variable size table and hence has [slightly] higher
> likelihood of table space allocation failing) should result in skipping
> other table setup.
> 

But MADT, HPET and WAET are treated like that. I want to be
consistent.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:13:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:13:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqeO-0006e5-IU; Mon, 24 Nov 2014 10:13:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsqeN-0006dx-Tj
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:13:44 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	06/5C-25276-7D403745; Mon, 24 Nov 2014 10:13:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416824021!14867008!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20171 invoked from network); 24 Nov 2014 10:13:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:13:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195998587"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:13:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsqeK-0003Wa-Kq;
	Mon, 24 Nov 2014 10:13:40 +0000
Date: Mon, 24 Nov 2014 10:13:40 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124101340.GE30053@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
	<547311BA020000780004A39E@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547311BA020000780004A39E@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/19] hvmloader: construct SRAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 10:08:42AM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> > --- a/tools/firmware/hvmloader/acpi/build.c
> > +++ b/tools/firmware/hvmloader/acpi/build.c
> > @@ -203,6 +203,66 @@ static struct acpi_20_waet *construct_waet(void)
> >      return waet;
> >  }
> >  
> > +static struct acpi_20_srat *construct_srat(void)
> > +{
> > +    struct acpi_20_srat *srat;
> > +    struct acpi_20_srat_processor *processor;
> > +    struct acpi_20_srat_memory *memory;
> > +    unsigned int size;
> > +    void *p;
> > +    int i;
> > +    uint64_t mem;
> > +
> > +    size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
> > +        sizeof(*memory) * hvm_info->nr_vmemranges;
> > +
> > +    p = mem_alloc(size, 16);
> > +    if (!p) return NULL;
> > +
> > +    srat = p;
> > +    memset(srat, 0, sizeof(*srat));
> > +    srat->header.signature    = ACPI_2_0_SRAT_SIGNATURE;
> > +    srat->header.revision     = ACPI_2_0_SRAT_REVISION;
> > +    fixed_strcpy(srat->header.oem_id, ACPI_OEM_ID);
> > +    fixed_strcpy(srat->header.oem_table_id, ACPI_OEM_TABLE_ID);
> > +    srat->header.oem_revision = ACPI_OEM_REVISION;
> > +    srat->header.creator_id   = ACPI_CREATOR_ID;
> > +    srat->header.creator_revision = ACPI_CREATOR_REVISION;
> > +    srat->table_revision      = ACPI_SRAT_TABLE_REVISION;
> > +
> > +    processor = (struct acpi_20_srat_processor *)(srat + 1);
> > +    for ( i = 0; i < hvm_info->nr_vcpus; i++ )
> > +    {
> > +        memset(processor, 0, sizeof(*processor));
> > +        processor->type     = ACPI_PROCESSOR_AFFINITY;
> > +        processor->length   = sizeof(*processor);
> > +        processor->domain   = hvm_info->vcpu_to_vnode[i];
> > +        processor->apic_id  = LAPIC_ID(i);
> > +        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
> > +        processor->sapic_id = 0;
> 
> Either you initialize all fields explicitly and drop the memset(), or
> you consistently avoid explicit zero initializers (as being redundant).
> 

Ack.

> > @@ -270,6 +331,13 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
> >          table_ptrs[nr_tables++] = (unsigned long)madt;
> >      }
> >  
> > +    if ( hvm_info->nr_nodes > 0 )
> > +    {
> > +        srat = construct_srat();
> > +        if (!srat) return -1;
> 
> I don't think failure to set up secondary information (especially when
> it requires a variable size table and hence has [slightly] higher
> likelihood of table space allocation failing) should result in skipping
> other table setup.
> 

But MADT, HPET and WAET are treated like that. I want to be
consistent.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:16:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqgP-0006m4-2w; Mon, 24 Nov 2014 10:15:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XsqgN-0006lw-Dq
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:15:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/E0-25276-25503745; Mon, 24 Nov 2014 10:15:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416824146!14818879!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7690 invoked from network); 24 Nov 2014 10:15:46 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:15:46 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:15:45 +0000
Message-Id: <5473135E020000780004A3BA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:15:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: GeorgeDunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/19] hvmloader: disallow memory relocation
 when vNUMA is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

So this is the fourth patch now without any description whatsoever.

> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -88,6 +88,19 @@ void pci_setup(void)
>      printf("Relocating guest memory for lowmem MMIO space %s\n",
>             allow_memory_relocate?"enabled":"disabled");
>  
> +    /* Disallow low memory relocation when vNUMA is enabled, because
> +     * relocated memory ends up off node. Further more, even if we
> +     * dynamically expand node coverage in hvmloader, low memory and
> +     * high memory may reside in different physical nodes, blindly
> +     * relocates low memory to high memory gives us a sub-optimal
> +     * configuration.
> +     */
> +    if ( hvm_info->nr_nodes != 0 && allow_memory_relocate )
> +    {
> +        allow_memory_relocate = false;
> +        printf("vNUMA enabled, relocating guest memory for lowmem MMIO space disabled\n");
> +    }

Apart from the comment violating our coding style, as already
indicated in the reply to Konrad's comment I don't think this is
the right approach. If it is meant to be a temporary measure, the
comment should say so (and perhaps have a TBD or similar grep-
able mark in it).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:16:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqgP-0006m4-2w; Mon, 24 Nov 2014 10:15:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XsqgN-0006lw-Dq
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:15:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/E0-25276-25503745; Mon, 24 Nov 2014 10:15:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416824146!14818879!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7690 invoked from network); 24 Nov 2014 10:15:46 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:15:46 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:15:45 +0000
Message-Id: <5473135E020000780004A3BA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:15:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1416582421-10789-15-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: GeorgeDunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/19] hvmloader: disallow memory relocation
 when vNUMA is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

So this is the fourth patch now without any description whatsoever.

> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -88,6 +88,19 @@ void pci_setup(void)
>      printf("Relocating guest memory for lowmem MMIO space %s\n",
>             allow_memory_relocate?"enabled":"disabled");
>  
> +    /* Disallow low memory relocation when vNUMA is enabled, because
> +     * relocated memory ends up off node. Further more, even if we
> +     * dynamically expand node coverage in hvmloader, low memory and
> +     * high memory may reside in different physical nodes, blindly
> +     * relocates low memory to high memory gives us a sub-optimal
> +     * configuration.
> +     */
> +    if ( hvm_info->nr_nodes != 0 && allow_memory_relocate )
> +    {
> +        allow_memory_relocate = false;
> +        printf("vNUMA enabled, relocating guest memory for lowmem MMIO space disabled\n");
> +    }

Apart from the comment violating our coding style, as already
indicated in the reply to Konrad's comment I don't think this is
the right approach. If it is meant to be a temporary measure, the
comment should say so (and perhaps have a TBD or similar grep-
able mark in it).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:20:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10: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 1Xsql1-0006wZ-QR; Mon, 24 Nov 2014 10:20:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xsql0-0006wU-IN
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 10:20:34 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	AD/46-14727-17603745; Mon, 24 Nov 2014 10:20:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416824431!12970896!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23548 invoked from network); 24 Nov 2014 10:20:32 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:20:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:20:31 +0000
Message-Id: <5473147C020000780004A3D5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:20:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <546EFAE3.80404@suse.com>
	<20141121135747.GB2886@laptop.dumpdata.com> <5473008C.4080604@suse.com>
In-Reply-To: <5473008C.4080604@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-rc5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.11.14 at 10:55, <JGross@suse.com> wrote:
> - Sometimes I see only NMI watchdog messages, looking into hanging cpu
>    state via xen debug keys I can see the cpu(s) in question are spinning
>    in _raw_spin_lock():
>    __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
>    The hanging cpus were executing some random user processes (cron,
>    bash, xargs), cr2 contained user addresses.

Is this perhaps what
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02135.html
appears to be about?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:20:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10: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 1Xsql1-0006wZ-QR; Mon, 24 Nov 2014 10:20:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xsql0-0006wU-IN
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 10:20:34 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	AD/46-14727-17603745; Mon, 24 Nov 2014 10:20:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416824431!12970896!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23548 invoked from network); 24 Nov 2014 10:20:32 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:20:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:20:31 +0000
Message-Id: <5473147C020000780004A3D5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:20:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <546EFAE3.80404@suse.com>
	<20141121135747.GB2886@laptop.dumpdata.com> <5473008C.4080604@suse.com>
In-Reply-To: <5473008C.4080604@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-rc5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.11.14 at 10:55, <JGross@suse.com> wrote:
> - Sometimes I see only NMI watchdog messages, looking into hanging cpu
>    state via xen debug keys I can see the cpu(s) in question are spinning
>    in _raw_spin_lock():
>    __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
>    The hanging cpus were executing some random user processes (cron,
>    bash, xargs), cr2 contained user addresses.

Is this perhaps what
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02135.html
appears to be about?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:22:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqnB-00077Y-BC; Mon, 24 Nov 2014 10:22:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xsqn9-00077H-CF
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:22:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	54/57-09842-6F603745; Mon, 24 Nov 2014 10:22:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416824566!14821044!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6107 invoked from network); 24 Nov 2014 10:22:46 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:22:46 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:22:45 +0000
Message-Id: <54731503020000780004A3E4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:22:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-12-git-send-email-wei.liu2@citrix.com>
	<54730F55020000780004A370@mail.emea.novell.com>
	<20141124100735.GD30053@zion.uk.xensource.com>
In-Reply-To: <20141124100735.GD30053@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/19] hvmloader: add new fields for vNUMA
 information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.11.14 at 11:07, <wei.liu2@citrix.com> wrote:
> On Mon, Nov 24, 2014 at 09:58:29AM +0000, Jan Beulich wrote:
>> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
>> > --- a/xen/include/public/hvm/hvm_info_table.h
>> > +++ b/xen/include/public/hvm/hvm_info_table.h
>> > @@ -32,6 +32,17 @@
>> >  /* Maximum we can support with current vLAPIC ID mapping. */
>> >  #define HVM_MAX_VCPUS        128
>> >  
>> > +#define HVM_MAX_NODES         16
>> > +#define HVM_MAX_LOCALITIES    (HVM_MAX_NODES * HVM_MAX_NODES)
>> > +
>> > +#define HVM_MAX_VMEMRANGES    64
>> > +struct hvm_info_vmemrange {
>> > +    uint64_t start;
>> > +    uint64_t end;
>> > +    uint32_t flags;
>> > +    uint32_t nid;
>> > +};
>> > +
>> >  struct hvm_info_table {
>> >      char        signature[8]; /* "HVM INFO" */
>> >      uint32_t    length;
>> > @@ -67,6 +78,14 @@ struct hvm_info_table {
>> >  
>> >      /* Bitmap of which CPUs are online at boot time. */
>> >      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
>> > +
>> > +    /* Virtual NUMA information */
>> > +    uint32_t    nr_nodes;
>> > +    uint8_t     vcpu_to_vnode[HVM_MAX_VCPUS];
>> > +    uint32_t    nr_vmemranges;
>> > +    struct hvm_info_vmemrange vmemranges[HVM_MAX_VMEMRANGES];
>> > +    uint64_t    nr_localities;
>> > +    uint8_t     localities[HVM_MAX_LOCALITIES];
>> >  };
>> >  
>> >  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */
>> 
>> Is this really the right place? This is a public interface, which we
>> shouldn't modify in ways making future changes more cumbersome.
>> In particular, once we finally get the LAPIC ID brokenness fixed,
>> HVM_MAX_VCPUS won't need to be limited to 128 anymore. And
>> we likely would want to keep things simple an retain the bitmap
>> where it currently sits, just extending its size. With all of the data
>> above (supposedly, or we made a mistake somewhere) being
>> retrievable via hypercall, what is the rationale for doing things
>> this way in the first place (the lack of any kind of description is of
>> course not really helpful here)?
>> 
> 
> My thought was that this is interface between libxl and hvmloader, and
> the way it's used suggests that this is canonical way of doing things. I
> might have got this wrong in the first place.
> 
> So I take it you're of the opinion this piece of information should be
> retrieved via hypercall in hvmloader, right? That's OK (and even better)
> for me.

Yes - that other interface should be used only for things that
can't be communicated to the guest in another (sane) way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:22:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsqnB-00077Y-BC; Mon, 24 Nov 2014 10:22:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xsqn9-00077H-CF
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:22:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	54/57-09842-6F603745; Mon, 24 Nov 2014 10:22:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416824566!14821044!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6107 invoked from network); 24 Nov 2014 10:22:46 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:22:46 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:22:45 +0000
Message-Id: <54731503020000780004A3E4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:22:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-12-git-send-email-wei.liu2@citrix.com>
	<54730F55020000780004A370@mail.emea.novell.com>
	<20141124100735.GD30053@zion.uk.xensource.com>
In-Reply-To: <20141124100735.GD30053@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/19] hvmloader: add new fields for vNUMA
 information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.11.14 at 11:07, <wei.liu2@citrix.com> wrote:
> On Mon, Nov 24, 2014 at 09:58:29AM +0000, Jan Beulich wrote:
>> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
>> > --- a/xen/include/public/hvm/hvm_info_table.h
>> > +++ b/xen/include/public/hvm/hvm_info_table.h
>> > @@ -32,6 +32,17 @@
>> >  /* Maximum we can support with current vLAPIC ID mapping. */
>> >  #define HVM_MAX_VCPUS        128
>> >  
>> > +#define HVM_MAX_NODES         16
>> > +#define HVM_MAX_LOCALITIES    (HVM_MAX_NODES * HVM_MAX_NODES)
>> > +
>> > +#define HVM_MAX_VMEMRANGES    64
>> > +struct hvm_info_vmemrange {
>> > +    uint64_t start;
>> > +    uint64_t end;
>> > +    uint32_t flags;
>> > +    uint32_t nid;
>> > +};
>> > +
>> >  struct hvm_info_table {
>> >      char        signature[8]; /* "HVM INFO" */
>> >      uint32_t    length;
>> > @@ -67,6 +78,14 @@ struct hvm_info_table {
>> >  
>> >      /* Bitmap of which CPUs are online at boot time. */
>> >      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
>> > +
>> > +    /* Virtual NUMA information */
>> > +    uint32_t    nr_nodes;
>> > +    uint8_t     vcpu_to_vnode[HVM_MAX_VCPUS];
>> > +    uint32_t    nr_vmemranges;
>> > +    struct hvm_info_vmemrange vmemranges[HVM_MAX_VMEMRANGES];
>> > +    uint64_t    nr_localities;
>> > +    uint8_t     localities[HVM_MAX_LOCALITIES];
>> >  };
>> >  
>> >  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */
>> 
>> Is this really the right place? This is a public interface, which we
>> shouldn't modify in ways making future changes more cumbersome.
>> In particular, once we finally get the LAPIC ID brokenness fixed,
>> HVM_MAX_VCPUS won't need to be limited to 128 anymore. And
>> we likely would want to keep things simple an retain the bitmap
>> where it currently sits, just extending its size. With all of the data
>> above (supposedly, or we made a mistake somewhere) being
>> retrievable via hypercall, what is the rationale for doing things
>> this way in the first place (the lack of any kind of description is of
>> course not really helpful here)?
>> 
> 
> My thought was that this is interface between libxl and hvmloader, and
> the way it's used suggests that this is canonical way of doing things. I
> might have got this wrong in the first place.
> 
> So I take it you're of the opinion this piece of information should be
> retrieved via hypercall in hvmloader, right? That's OK (and even better)
> for me.

Yes - that other interface should be used only for things that
can't be communicated to the guest in another (sane) way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:27:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:27:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsqr4-0007Js-6k; Mon, 24 Nov 2014 10:26:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xsqr2-0007Jn-NE
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:26:48 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	38/77-02699-8E703745; Mon, 24 Nov 2014 10:26:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416824807!14412228!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25820 invoked from network); 24 Nov 2014 10:26:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:26:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:26:47 +0000
Message-Id: <547315F4020000780004A3E7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:26:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
	<547311BA020000780004A39E@mail.emea.novell.com>
	<20141124101340.GE30053@zion.uk.xensource.com>
In-Reply-To: <20141124101340.GE30053@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/19] hvmloader: construct SRAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 11:13, <wei.liu2@citrix.com> wrote:
> On Mon, Nov 24, 2014 at 10:08:42AM +0000, Jan Beulich wrote:
>> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
>> > @@ -270,6 +331,13 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
>> >          table_ptrs[nr_tables++] = (unsigned long)madt;
>> >      }
>> >  
>> > +    if ( hvm_info->nr_nodes > 0 )
>> > +    {
>> > +        srat = construct_srat();
>> > +        if (!srat) return -1;
>> 
>> I don't think failure to set up secondary information (especially when
>> it requires a variable size table and hence has [slightly] higher
>> likelihood of table space allocation failing) should result in skipping
>> other table setup.
> 
> But MADT, HPET and WAET are treated like that. I want to be
> consistent.

I kind of expected you to say that, and specifically added the
reference to SRAT and SLIT being variable size (and perhaps
relatively big). While MADT is variable size too, it (other than the
tables you add here) is kind of essential for the guest to come up
in ACPI mode. Which btw also tells us that these two tables
should be added as late as possible, to avoid them exhausting
memory before other, essential allocations got done.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:27:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:27:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsqr4-0007Js-6k; Mon, 24 Nov 2014 10:26:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xsqr2-0007Jn-NE
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:26:48 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	38/77-02699-8E703745; Mon, 24 Nov 2014 10:26:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416824807!14412228!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25820 invoked from network); 24 Nov 2014 10:26:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:26:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 10:26:47 +0000
Message-Id: <547315F4020000780004A3E7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 10:26:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
	<547311BA020000780004A39E@mail.emea.novell.com>
	<20141124101340.GE30053@zion.uk.xensource.com>
In-Reply-To: <20141124101340.GE30053@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/19] hvmloader: construct SRAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 11:13, <wei.liu2@citrix.com> wrote:
> On Mon, Nov 24, 2014 at 10:08:42AM +0000, Jan Beulich wrote:
>> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
>> > @@ -270,6 +331,13 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
>> >          table_ptrs[nr_tables++] = (unsigned long)madt;
>> >      }
>> >  
>> > +    if ( hvm_info->nr_nodes > 0 )
>> > +    {
>> > +        srat = construct_srat();
>> > +        if (!srat) return -1;
>> 
>> I don't think failure to set up secondary information (especially when
>> it requires a variable size table and hence has [slightly] higher
>> likelihood of table space allocation failing) should result in skipping
>> other table setup.
> 
> But MADT, HPET and WAET are treated like that. I want to be
> consistent.

I kind of expected you to say that, and specifically added the
reference to SRAT and SLIT being variable size (and perhaps
relatively big). While MADT is variable size too, it (other than the
tables you add here) is kind of essential for the guest to come up
in ACPI mode. Which btw also tells us that these two tables
should be added as late as possible, to avoid them exhausting
memory before other, essential allocations got done.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:38:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:38:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsr1o-0007ZS-EQ; Mon, 24 Nov 2014 10:37: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 1Xsr1n-0007ZN-3b
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:37:55 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	E5/46-19763-28A03745; Mon, 24 Nov 2014 10:37:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416825470!13004809!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2396 invoked from network); 24 Nov 2014 10:37:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:37:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196005436"
Message-ID: <1416825467.26329.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Gedalya <gedalya@gedalya.net>
Date: Mon, 24 Nov 2014 10:37:47 +0000
In-Reply-To: <546F9F9C.5090507@gedalya.net>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>	 <1416567797.26869.18.camel@citrix.com>
	<1416568333.26869.22.camel@citrix.com> <546F9F9C.5090507@gedalya.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, 767295@bugs.debian.org, xen-devel@lists.xen.org,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 15:25 -0500, Gedalya wrote:
> On 11/21/2014 06:12 AM, Ian Campbell wrote:
> > On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote:
> >> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about
> >> various dynamic thresholds for growing and shrinking the heap. My guess
> >> is that we are bouncing up and down over some threshold with every other
> >> reboot.
> > IOW I'm not overly concerned with this apparent bi-modality, so long as
> > the amount isn't increasing in the long term...
> >
> > I think the original patch should go in.
> >
> > Ian.
> >
> >
> It's an improvement, but consider this:
> Someone has a xen host running wheezy, 40 domu's, with 768MB for dom0, 
> worked fine so far. Tries upgrading to jessie, and lo, each domu process 
> takes up only 588 KB on dom0, great!
> Then a new kernel package is released, all domu's get rebooted once. All 
> host memory is now full. Dude might have had other plans for that 
> memory... This is dead memory so I guess it can be swapped out, not 
> easily a scenario where the server totally crashes, but it's a bit ugly, 
> we're talking about memory usage leaping from 0.6 to 16 MB per domu.

Unfortunately this is down to the behaviour of the libc and not
something which appears to be under application control. 

The following program demonstrates the same behaviour and is certainly
not leaking anything. Notice that at "Freed block at XXXXX. Everything
is now freed, end of day" there is still an anon mapping of that
address. Notice also that the "in use" figures are zero.

If this concerns you then you should probably take a look at mallopt(3)
and/or be talking to the libc folks about it. It's not an xl issue
AFAICT.

Ian.

#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <malloc.h>

#define KB 196

int main(int argc, char **argv)
{
	void *p;
	char buf[1000];

	snprintf(buf, 1000, "pmap -x %d", getpid());

	printf("Start of day\n");
	system(buf);
	malloc_stats();

	printf("\n=========================\n\n");

	p = malloc(KB*0x1000);

	printf("allocated %dKB block at %p\n", KB, p);
	system(buf);
	malloc_stats();

	printf("\n=========================\n\n");

	free(p);

	printf("Freed block at %p\n", p);
	system(buf);
	malloc_stats();

	printf("\n=========================\n\n");

	p = malloc(KB*0x1000);

	printf("Allocated another %dKB block at %p\n", KB, p);
	system(buf);
	malloc_stats();

	printf("\n=========================\n\n");

	free(p);

	printf("Freed block at %p. Everything is now freed, end of day\n", p);
	system(buf);
	malloc_stats();

	printf("\n=========================\n\n");

	return 0;

}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:38:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:38:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsr1o-0007ZS-EQ; Mon, 24 Nov 2014 10:37: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 1Xsr1n-0007ZN-3b
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:37:55 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	E5/46-19763-28A03745; Mon, 24 Nov 2014 10:37:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416825470!13004809!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2396 invoked from network); 24 Nov 2014 10:37:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:37:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196005436"
Message-ID: <1416825467.26329.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Gedalya <gedalya@gedalya.net>
Date: Mon, 24 Nov 2014 10:37:47 +0000
In-Reply-To: <546F9F9C.5090507@gedalya.net>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120202114.GE31889@laptop.dumpdata.com>
	<546EADD0.8010002@gedalya.net>	 <1416567797.26869.18.camel@citrix.com>
	<1416568333.26869.22.camel@citrix.com> <546F9F9C.5090507@gedalya.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, 767295@bugs.debian.org, xen-devel@lists.xen.org,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 15:25 -0500, Gedalya wrote:
> On 11/21/2014 06:12 AM, Ian Campbell wrote:
> > On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote:
> >> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about
> >> various dynamic thresholds for growing and shrinking the heap. My guess
> >> is that we are bouncing up and down over some threshold with every other
> >> reboot.
> > IOW I'm not overly concerned with this apparent bi-modality, so long as
> > the amount isn't increasing in the long term...
> >
> > I think the original patch should go in.
> >
> > Ian.
> >
> >
> It's an improvement, but consider this:
> Someone has a xen host running wheezy, 40 domu's, with 768MB for dom0, 
> worked fine so far. Tries upgrading to jessie, and lo, each domu process 
> takes up only 588 KB on dom0, great!
> Then a new kernel package is released, all domu's get rebooted once. All 
> host memory is now full. Dude might have had other plans for that 
> memory... This is dead memory so I guess it can be swapped out, not 
> easily a scenario where the server totally crashes, but it's a bit ugly, 
> we're talking about memory usage leaping from 0.6 to 16 MB per domu.

Unfortunately this is down to the behaviour of the libc and not
something which appears to be under application control. 

The following program demonstrates the same behaviour and is certainly
not leaking anything. Notice that at "Freed block at XXXXX. Everything
is now freed, end of day" there is still an anon mapping of that
address. Notice also that the "in use" figures are zero.

If this concerns you then you should probably take a look at mallopt(3)
and/or be talking to the libc folks about it. It's not an xl issue
AFAICT.

Ian.

#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <malloc.h>

#define KB 196

int main(int argc, char **argv)
{
	void *p;
	char buf[1000];

	snprintf(buf, 1000, "pmap -x %d", getpid());

	printf("Start of day\n");
	system(buf);
	malloc_stats();

	printf("\n=========================\n\n");

	p = malloc(KB*0x1000);

	printf("allocated %dKB block at %p\n", KB, p);
	system(buf);
	malloc_stats();

	printf("\n=========================\n\n");

	free(p);

	printf("Freed block at %p\n", p);
	system(buf);
	malloc_stats();

	printf("\n=========================\n\n");

	p = malloc(KB*0x1000);

	printf("Allocated another %dKB block at %p\n", KB, p);
	system(buf);
	malloc_stats();

	printf("\n=========================\n\n");

	free(p);

	printf("Freed block at %p. Everything is now freed, end of day\n", p);
	system(buf);
	malloc_stats();

	printf("\n=========================\n\n");

	return 0;

}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:42:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:42:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsr6Z-0007nb-6U; Mon, 24 Nov 2014 10:42:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xsr6X-0007nQ-Pl
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:42:49 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	6D/62-27623-9AB03745; Mon, 24 Nov 2014 10:42:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416825767!13382654!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11237 invoked from network); 24 Nov 2014 10:42:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:42:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196006446"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:41:27 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xsr5D-0004B4-Bz;
	Mon, 24 Nov 2014 10:41:27 +0000
Date: Mon, 24 Nov 2014 10:41:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141124104127.GF30053@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
> When parsing bitmap objects JSON parser will create libxl_bitmap
> map of the smallest size needed.
> 
> This can cause problems when saved image file specifies CPU affinity.
> For example, if 'vcpu_hard_affinity' in the saved image has only the
> first CPU specified, just a single byte will be allocated and
> libxl_bitmap->size will be set to 1.
> 
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> since the destination bitmap is created for maximum number of CPUs.
> 
> We could allocate that bitmap of the same size as the source, however,
> it is later passed to xc_vcpu_setaffinity() which expects it to be
> sized to the max number of CPUs
> 
> Instead, we should allow copying the (smaller) bitmap read by the parser
> and keep the rest of bytes in the destination map unmodified (zero in
> this case)
> 

Here is some more thoughts on this issue:

This API is used by VCPU placement and NUMA placement logic in libxl. To
fix the breakage, we don't necessary need to expose new API or change
API behaviour, we only need to have a internal function to do it.

The reversed case (large bitmap to small one) is not valid in libxl, as
in the pinning will fail. But bitmap copy happens before that, we would
still need to deal with that. Dario, can you provide some input on
the expected behaviour?

The partial copy function should explicitly zero-out all remaining bits.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:42:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:42:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsr6Z-0007nb-6U; Mon, 24 Nov 2014 10:42:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xsr6X-0007nQ-Pl
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:42:49 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	6D/62-27623-9AB03745; Mon, 24 Nov 2014 10:42:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416825767!13382654!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11237 invoked from network); 24 Nov 2014 10:42:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:42:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196006446"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:41:27 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xsr5D-0004B4-Bz;
	Mon, 24 Nov 2014 10:41:27 +0000
Date: Mon, 24 Nov 2014 10:41:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141124104127.GF30053@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
> When parsing bitmap objects JSON parser will create libxl_bitmap
> map of the smallest size needed.
> 
> This can cause problems when saved image file specifies CPU affinity.
> For example, if 'vcpu_hard_affinity' in the saved image has only the
> first CPU specified, just a single byte will be allocated and
> libxl_bitmap->size will be set to 1.
> 
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> since the destination bitmap is created for maximum number of CPUs.
> 
> We could allocate that bitmap of the same size as the source, however,
> it is later passed to xc_vcpu_setaffinity() which expects it to be
> sized to the max number of CPUs
> 
> Instead, we should allow copying the (smaller) bitmap read by the parser
> and keep the rest of bytes in the destination map unmodified (zero in
> this case)
> 

Here is some more thoughts on this issue:

This API is used by VCPU placement and NUMA placement logic in libxl. To
fix the breakage, we don't necessary need to expose new API or change
API behaviour, we only need to have a internal function to do it.

The reversed case (large bitmap to small one) is not valid in libxl, as
in the pinning will fail. But bitmap copy happens before that, we would
still need to deal with that. Dario, can you provide some input on
the expected behaviour?

The partial copy function should explicitly zero-out all remaining bits.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:47:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrAd-0007w4-0p; Mon, 24 Nov 2014 10:47:03 +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 1XsrAb-0007vy-Hz
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:47:01 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	73/65-22777-4AC03745; Mon, 24 Nov 2014 10:47:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416826018!12982193!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13032 invoked from network); 24 Nov 2014 10:47:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:47:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196007945"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:46:13 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xsr9o-0004Iz-MI;
	Mon, 24 Nov 2014 10:46:12 +0000
Date: Mon, 24 Nov 2014 10:46:12 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124104612.GG30053@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
	<547311BA020000780004A39E@mail.emea.novell.com>
	<20141124101340.GE30053@zion.uk.xensource.com>
	<547315F4020000780004A3E7@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547315F4020000780004A3E7@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/19] hvmloader: construct SRAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 10:26:44AM +0000, Jan Beulich wrote:
> >>> On 24.11.14 at 11:13, <wei.liu2@citrix.com> wrote:
> > On Mon, Nov 24, 2014 at 10:08:42AM +0000, Jan Beulich wrote:
> >> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> >> > @@ -270,6 +331,13 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
> >> >          table_ptrs[nr_tables++] = (unsigned long)madt;
> >> >      }
> >> >  
> >> > +    if ( hvm_info->nr_nodes > 0 )
> >> > +    {
> >> > +        srat = construct_srat();
> >> > +        if (!srat) return -1;
> >> 
> >> I don't think failure to set up secondary information (especially when
> >> it requires a variable size table and hence has [slightly] higher
> >> likelihood of table space allocation failing) should result in skipping
> >> other table setup.
> > 
> > But MADT, HPET and WAET are treated like that. I want to be
> > consistent.
> 
> I kind of expected you to say that, and specifically added the
> reference to SRAT and SLIT being variable size (and perhaps
> relatively big). While MADT is variable size too, it (other than the
> tables you add here) is kind of essential for the guest to come up
> in ACPI mode. Which btw also tells us that these two tables
> should be added as late as possible, to avoid them exhausting
> memory before other, essential allocations got done.
> 

So the plan is:

1. Move SRAT and SLIT down.
2. Don't return -1 on failure (and print warning).

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:47:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrAd-0007w4-0p; Mon, 24 Nov 2014 10:47:03 +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 1XsrAb-0007vy-Hz
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:47:01 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	73/65-22777-4AC03745; Mon, 24 Nov 2014 10:47:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416826018!12982193!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13032 invoked from network); 24 Nov 2014 10:47:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:47:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196007945"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:46:13 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xsr9o-0004Iz-MI;
	Mon, 24 Nov 2014 10:46:12 +0000
Date: Mon, 24 Nov 2014 10:46:12 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124104612.GG30053@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-13-git-send-email-wei.liu2@citrix.com>
	<547311BA020000780004A39E@mail.emea.novell.com>
	<20141124101340.GE30053@zion.uk.xensource.com>
	<547315F4020000780004A3E7@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547315F4020000780004A3E7@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/19] hvmloader: construct SRAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 10:26:44AM +0000, Jan Beulich wrote:
> >>> On 24.11.14 at 11:13, <wei.liu2@citrix.com> wrote:
> > On Mon, Nov 24, 2014 at 10:08:42AM +0000, Jan Beulich wrote:
> >> >>> On 21.11.14 at 16:06, <wei.liu2@citrix.com> wrote:
> >> > @@ -270,6 +331,13 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
> >> >          table_ptrs[nr_tables++] = (unsigned long)madt;
> >> >      }
> >> >  
> >> > +    if ( hvm_info->nr_nodes > 0 )
> >> > +    {
> >> > +        srat = construct_srat();
> >> > +        if (!srat) return -1;
> >> 
> >> I don't think failure to set up secondary information (especially when
> >> it requires a variable size table and hence has [slightly] higher
> >> likelihood of table space allocation failing) should result in skipping
> >> other table setup.
> > 
> > But MADT, HPET and WAET are treated like that. I want to be
> > consistent.
> 
> I kind of expected you to say that, and specifically added the
> reference to SRAT and SLIT being variable size (and perhaps
> relatively big). While MADT is variable size too, it (other than the
> tables you add here) is kind of essential for the guest to come up
> in ACPI mode. Which btw also tells us that these two tables
> should be added as late as possible, to avoid them exhausting
> memory before other, essential allocations got done.
> 

So the plan is:

1. Move SRAT and SLIT down.
2. Don't return -1 on failure (and print warning).

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:47:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:47:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrB5-0007yg-E9; Mon, 24 Nov 2014 10:47:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsrB4-0007yX-9s
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:47:30 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	38/8D-15461-1CC03745; Mon, 24 Nov 2014 10:47:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416826048!14828744!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17705 invoked from network); 24 Nov 2014 10:47:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:47:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196008259"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:47:03 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsrAd-0004J3-8h;
	Mon, 24 Nov 2014 10:47:03 +0000
Date: Mon, 24 Nov 2014 10:47:03 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141124104703.GH30053@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141124104127.GF30053@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CC'ing Dario...

On Mon, Nov 24, 2014 at 10:41:27AM +0000, Wei Liu wrote:
> On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
> > When parsing bitmap objects JSON parser will create libxl_bitmap
> > map of the smallest size needed.
> > 
> > This can cause problems when saved image file specifies CPU affinity.
> > For example, if 'vcpu_hard_affinity' in the saved image has only the
> > first CPU specified, just a single byte will be allocated and
> > libxl_bitmap->size will be set to 1.
> > 
> > This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> > since the destination bitmap is created for maximum number of CPUs.
> > 
> > We could allocate that bitmap of the same size as the source, however,
> > it is later passed to xc_vcpu_setaffinity() which expects it to be
> > sized to the max number of CPUs
> > 
> > Instead, we should allow copying the (smaller) bitmap read by the parser
> > and keep the rest of bytes in the destination map unmodified (zero in
> > this case)
> > 
> 
> Here is some more thoughts on this issue:
> 
> This API is used by VCPU placement and NUMA placement logic in libxl. To
> fix the breakage, we don't necessary need to expose new API or change
> API behaviour, we only need to have a internal function to do it.
> 
> The reversed case (large bitmap to small one) is not valid in libxl, as
> in the pinning will fail. But bitmap copy happens before that, we would
> still need to deal with that. Dario, can you provide some input on
> the expected behaviour?
> 
> The partial copy function should explicitly zero-out all remaining bits.
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:47:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:47:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrB5-0007yg-E9; Mon, 24 Nov 2014 10:47:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsrB4-0007yX-9s
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 10:47:30 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	38/8D-15461-1CC03745; Mon, 24 Nov 2014 10:47:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416826048!14828744!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17705 invoked from network); 24 Nov 2014 10:47:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 10:47:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196008259"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 05:47:03 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsrAd-0004J3-8h;
	Mon, 24 Nov 2014 10:47:03 +0000
Date: Mon, 24 Nov 2014 10:47:03 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141124104703.GH30053@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141124104127.GF30053@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CC'ing Dario...

On Mon, Nov 24, 2014 at 10:41:27AM +0000, Wei Liu wrote:
> On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
> > When parsing bitmap objects JSON parser will create libxl_bitmap
> > map of the smallest size needed.
> > 
> > This can cause problems when saved image file specifies CPU affinity.
> > For example, if 'vcpu_hard_affinity' in the saved image has only the
> > first CPU specified, just a single byte will be allocated and
> > libxl_bitmap->size will be set to 1.
> > 
> > This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> > since the destination bitmap is created for maximum number of CPUs.
> > 
> > We could allocate that bitmap of the same size as the source, however,
> > it is later passed to xc_vcpu_setaffinity() which expects it to be
> > sized to the max number of CPUs
> > 
> > Instead, we should allow copying the (smaller) bitmap read by the parser
> > and keep the rest of bytes in the destination map unmodified (zero in
> > this case)
> > 
> 
> Here is some more thoughts on this issue:
> 
> This API is used by VCPU placement and NUMA placement logic in libxl. To
> fix the breakage, we don't necessary need to expose new API or change
> API behaviour, we only need to have a internal function to do it.
> 
> The reversed case (large bitmap to small one) is not valid in libxl, as
> in the pinning will fail. But bitmap copy happens before that, we would
> still need to deal with that. Dario, can you provide some input on
> the expected behaviour?
> 
> The partial copy function should explicitly zero-out all remaining bits.
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:58:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrLF-0008Ge-KH; Mon, 24 Nov 2014 10:58:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <khoroshilov@ispras.ru>) id 1Xsr8f-0007to-1t
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 10:45:01 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	E5/85-14214-C2C03745; Mon, 24 Nov 2014 10:45:00 +0000
X-Env-Sender: khoroshilov@ispras.ru
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416825899!7579202!1
X-Originating-IP: [83.149.199.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23759 invoked from network); 24 Nov 2014 10:44:59 -0000
Received: from mail.ispras.ru (HELO mail.ispras.ru) (83.149.199.45)
	by server-14.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 10:44:59 -0000
Received: from [10.10.2.181] (pluton2.ispras.ru [83.149.199.44])
	by mail.ispras.ru (Postfix) with ESMTPSA id BFA0054006F;
	Mon, 24 Nov 2014 13:44:58 +0300 (MSK)
Message-ID: <54730C2A.3020108@ispras.ru>
Date: Mon, 24 Nov 2014 13:44:58 +0300
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1416610588-19816-1-git-send-email-khoroshilov@ispras.ru>
	<20141124100053.GC30053@zion.uk.xensource.com>
In-Reply-To: <20141124100053.GC30053@zion.uk.xensource.com>
X-Mailman-Approved-At: Mon, 24 Nov 2014 10:57:59 +0000
Cc: ldv-project@linuxtesting.org, xen-devel@lists.xenproject.org,
	Ian Campbell <ian.campbell@citrix.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-netback: do not report success if
 xenvif_alloc() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24.11.2014 13:00, Wei Liu wrote:
> On Sat, Nov 22, 2014 at 01:56:28AM +0300, Alexey Khoroshilov wrote:
>> If xenvif_alloc() failes, netback_probe() reports success as well as
>> "online" uevent is emitted. It does not make any sense, but it just
> Sorry, I don't follow. KOBJ_ONLINE event is not emitted in the event of
> xenvif_alloc fails, is it?
Yes, you are right.
>
>> misleads users.
>>
>> The patch implements propagation of error code if xenvif creation fails.
>>
> This patch not only implements propagation of error code when xenvif
> creation fails, but also when xenbus_scanf fails. You can simply write
> "This patch implements propagation of error code for
> backend_create_xenvif".
>
> The rest of this patch looks good to me. Can you rewrite commit message
> and resubmit, thanks.
Ok.

--
Thank you,
Alexey

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:58:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrLF-0008Ge-KH; Mon, 24 Nov 2014 10:58:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <khoroshilov@ispras.ru>) id 1Xsr8f-0007to-1t
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 10:45:01 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	E5/85-14214-C2C03745; Mon, 24 Nov 2014 10:45:00 +0000
X-Env-Sender: khoroshilov@ispras.ru
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416825899!7579202!1
X-Originating-IP: [83.149.199.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23759 invoked from network); 24 Nov 2014 10:44:59 -0000
Received: from mail.ispras.ru (HELO mail.ispras.ru) (83.149.199.45)
	by server-14.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 10:44:59 -0000
Received: from [10.10.2.181] (pluton2.ispras.ru [83.149.199.44])
	by mail.ispras.ru (Postfix) with ESMTPSA id BFA0054006F;
	Mon, 24 Nov 2014 13:44:58 +0300 (MSK)
Message-ID: <54730C2A.3020108@ispras.ru>
Date: Mon, 24 Nov 2014 13:44:58 +0300
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1416610588-19816-1-git-send-email-khoroshilov@ispras.ru>
	<20141124100053.GC30053@zion.uk.xensource.com>
In-Reply-To: <20141124100053.GC30053@zion.uk.xensource.com>
X-Mailman-Approved-At: Mon, 24 Nov 2014 10:57:59 +0000
Cc: ldv-project@linuxtesting.org, xen-devel@lists.xenproject.org,
	Ian Campbell <ian.campbell@citrix.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-netback: do not report success if
 xenvif_alloc() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24.11.2014 13:00, Wei Liu wrote:
> On Sat, Nov 22, 2014 at 01:56:28AM +0300, Alexey Khoroshilov wrote:
>> If xenvif_alloc() failes, netback_probe() reports success as well as
>> "online" uevent is emitted. It does not make any sense, but it just
> Sorry, I don't follow. KOBJ_ONLINE event is not emitted in the event of
> xenvif_alloc fails, is it?
Yes, you are right.
>
>> misleads users.
>>
>> The patch implements propagation of error code if xenvif creation fails.
>>
> This patch not only implements propagation of error code when xenvif
> creation fails, but also when xenbus_scanf fails. You can simply write
> "This patch implements propagation of error code for
> backend_create_xenvif".
>
> The rest of this patch looks good to me. Can you rewrite commit message
> and resubmit, thanks.
Ok.

--
Thank you,
Alexey

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:59:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrMg-0008LP-70; Mon, 24 Nov 2014 10:59:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XsrMf-0008LI-7g
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 10:59:29 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	FA/B0-03145-09F03745; Mon, 24 Nov 2014 10:59:28 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416826767!14404653!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6753 invoked from network); 24 Nov 2014 10:59:28 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:59:28 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9B042ACEE;
	Mon, 24 Nov 2014 10:59:27 +0000 (UTC)
Message-ID: <54730F8F.7080905@suse.com>
Date: Mon, 24 Nov 2014 11:59:27 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546EFAE3.80404@suse.com>	
	<20141121135747.GB2886@laptop.dumpdata.com>
	<5473008C.4080604@suse.com> <5473147C020000780004A3D5@suse.com>
In-Reply-To: <5473147C020000780004A3D5@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 11:20 AM, Jan Beulich wrote:
>>>> On 24.11.14 at 10:55, <JGross@suse.com> wrote:
>> - Sometimes I see only NMI watchdog messages, looking into hanging cpu
>>     state via xen debug keys I can see the cpu(s) in question are spinning
>>     in _raw_spin_lock():
>>     __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
>>     The hanging cpus were executing some random user processes (cron,
>>     bash, xargs), cr2 contained user addresses.
>
> Is this perhaps what
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02135.html
> appears to be about?

Hmm, I'm not sure.

I'll try a 3.17 kernel to verify.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 10:59:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 10:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrMg-0008LP-70; Mon, 24 Nov 2014 10:59:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XsrMf-0008LI-7g
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 10:59:29 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	FA/B0-03145-09F03745; Mon, 24 Nov 2014 10:59:28 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416826767!14404653!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6753 invoked from network); 24 Nov 2014 10:59:28 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 10:59:28 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9B042ACEE;
	Mon, 24 Nov 2014 10:59:27 +0000 (UTC)
Message-ID: <54730F8F.7080905@suse.com>
Date: Mon, 24 Nov 2014 11:59:27 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546EFAE3.80404@suse.com>	
	<20141121135747.GB2886@laptop.dumpdata.com>
	<5473008C.4080604@suse.com> <5473147C020000780004A3D5@suse.com>
In-Reply-To: <5473147C020000780004A3D5@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 11:20 AM, Jan Beulich wrote:
>>>> On 24.11.14 at 10:55, <JGross@suse.com> wrote:
>> - Sometimes I see only NMI watchdog messages, looking into hanging cpu
>>     state via xen debug keys I can see the cpu(s) in question are spinning
>>     in _raw_spin_lock():
>>     __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
>>     The hanging cpus were executing some random user processes (cron,
>>     bash, xargs), cr2 contained user addresses.
>
> Is this perhaps what
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02135.html
> appears to be about?

Hmm, I'm not sure.

I'll try a 3.17 kernel to verify.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:00:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrN9-0008PB-KQ; Mon, 24 Nov 2014 10:59:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <khoroshilov@ispras.ru>) id 1XsrLV-0008H8-7S
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 10:58:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CC/03-15461-84F03745; Mon, 24 Nov 2014 10:58:16 +0000
X-Env-Sender: khoroshilov@ispras.ru
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416826695!11420940!1
X-Originating-IP: [83.149.199.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25198 invoked from network); 24 Nov 2014 10:58:15 -0000
Received: from mail.ispras.ru (HELO mail.ispras.ru) (83.149.199.45)
	by server-16.tower-21.messagelabs.com with SMTP;
	24 Nov 2014 10:58:15 -0000
Received: from hednb2.intra.ispras.ru (pluton2.ispras.ru [83.149.199.44])
	by mail.ispras.ru (Postfix) with ESMTPSA id 5321F54006F;
	Mon, 24 Nov 2014 13:58:15 +0300 (MSK)
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 24 Nov 2014 13:58:00 +0300
Message-Id: <1416826680-19145-1-git-send-email-khoroshilov@ispras.ru>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <20141124100053.GC30053@zion.uk.xensource.com>
X-Mailman-Approved-At: Mon, 24 Nov 2014 10:59:58 +0000
Cc: ldv-project@linuxtesting.org, Ian Campbell <ian.campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org, Alexey Khoroshilov <khoroshilov@ispras.ru>
Subject: [Xen-devel] [PATCH] xen-netback: do not report success if
	backend_create_xenvif() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenvif_alloc() or xenbus_scanf() fail in backend_create_xenvif(),
xenbus is left in offline mode but netback_probe() reports success.

The patch implements propagation of error code for backend_create_xenvif().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
 drivers/net/xen-netback/xenbus.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 4e56a27f9689..fab0d4b42f58 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -39,7 +39,7 @@ struct backend_info {
 static int connect_rings(struct backend_info *be, struct xenvif_queue *queue);
 static void connect(struct backend_info *be);
 static int read_xenbus_vif_flags(struct backend_info *be);
-static void backend_create_xenvif(struct backend_info *be);
+static int backend_create_xenvif(struct backend_info *be);
 static void unregister_hotplug_status_watch(struct backend_info *be);
 static void set_backend_state(struct backend_info *be,
 			      enum xenbus_state state);
@@ -352,7 +352,9 @@ static int netback_probe(struct xenbus_device *dev,
 	be->state = XenbusStateInitWait;
 
 	/* This kicks hotplug scripts, so do it immediately. */
-	backend_create_xenvif(be);
+	err = backend_create_xenvif(be);
+	if (err)
+		goto fail;
 
 	return 0;
 
@@ -397,19 +399,19 @@ static int netback_uevent(struct xenbus_device *xdev,
 }
 
 
-static void backend_create_xenvif(struct backend_info *be)
+static int backend_create_xenvif(struct backend_info *be)
 {
 	int err;
 	long handle;
 	struct xenbus_device *dev = be->dev;
 
 	if (be->vif != NULL)
-		return;
+		return 0;
 
 	err = xenbus_scanf(XBT_NIL, dev->nodename, "handle", "%li", &handle);
 	if (err != 1) {
 		xenbus_dev_fatal(dev, err, "reading handle");
-		return;
+		return (err < 0) ? err : -EINVAL;
 	}
 
 	be->vif = xenvif_alloc(&dev->dev, dev->otherend_id, handle);
@@ -417,10 +419,11 @@ static void backend_create_xenvif(struct backend_info *be)
 		err = PTR_ERR(be->vif);
 		be->vif = NULL;
 		xenbus_dev_fatal(dev, err, "creating interface");
-		return;
+		return err;
 	}
 
 	kobject_uevent(&dev->dev.kobj, KOBJ_ONLINE);
+	return 0;
 }
 
 static void backend_disconnect(struct backend_info *be)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:00:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrN9-0008PB-KQ; Mon, 24 Nov 2014 10:59:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <khoroshilov@ispras.ru>) id 1XsrLV-0008H8-7S
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 10:58:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CC/03-15461-84F03745; Mon, 24 Nov 2014 10:58:16 +0000
X-Env-Sender: khoroshilov@ispras.ru
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416826695!11420940!1
X-Originating-IP: [83.149.199.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25198 invoked from network); 24 Nov 2014 10:58:15 -0000
Received: from mail.ispras.ru (HELO mail.ispras.ru) (83.149.199.45)
	by server-16.tower-21.messagelabs.com with SMTP;
	24 Nov 2014 10:58:15 -0000
Received: from hednb2.intra.ispras.ru (pluton2.ispras.ru [83.149.199.44])
	by mail.ispras.ru (Postfix) with ESMTPSA id 5321F54006F;
	Mon, 24 Nov 2014 13:58:15 +0300 (MSK)
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 24 Nov 2014 13:58:00 +0300
Message-Id: <1416826680-19145-1-git-send-email-khoroshilov@ispras.ru>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <20141124100053.GC30053@zion.uk.xensource.com>
X-Mailman-Approved-At: Mon, 24 Nov 2014 10:59:58 +0000
Cc: ldv-project@linuxtesting.org, Ian Campbell <ian.campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org, Alexey Khoroshilov <khoroshilov@ispras.ru>
Subject: [Xen-devel] [PATCH] xen-netback: do not report success if
	backend_create_xenvif() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenvif_alloc() or xenbus_scanf() fail in backend_create_xenvif(),
xenbus is left in offline mode but netback_probe() reports success.

The patch implements propagation of error code for backend_create_xenvif().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
 drivers/net/xen-netback/xenbus.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 4e56a27f9689..fab0d4b42f58 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -39,7 +39,7 @@ struct backend_info {
 static int connect_rings(struct backend_info *be, struct xenvif_queue *queue);
 static void connect(struct backend_info *be);
 static int read_xenbus_vif_flags(struct backend_info *be);
-static void backend_create_xenvif(struct backend_info *be);
+static int backend_create_xenvif(struct backend_info *be);
 static void unregister_hotplug_status_watch(struct backend_info *be);
 static void set_backend_state(struct backend_info *be,
 			      enum xenbus_state state);
@@ -352,7 +352,9 @@ static int netback_probe(struct xenbus_device *dev,
 	be->state = XenbusStateInitWait;
 
 	/* This kicks hotplug scripts, so do it immediately. */
-	backend_create_xenvif(be);
+	err = backend_create_xenvif(be);
+	if (err)
+		goto fail;
 
 	return 0;
 
@@ -397,19 +399,19 @@ static int netback_uevent(struct xenbus_device *xdev,
 }
 
 
-static void backend_create_xenvif(struct backend_info *be)
+static int backend_create_xenvif(struct backend_info *be)
 {
 	int err;
 	long handle;
 	struct xenbus_device *dev = be->dev;
 
 	if (be->vif != NULL)
-		return;
+		return 0;
 
 	err = xenbus_scanf(XBT_NIL, dev->nodename, "handle", "%li", &handle);
 	if (err != 1) {
 		xenbus_dev_fatal(dev, err, "reading handle");
-		return;
+		return (err < 0) ? err : -EINVAL;
 	}
 
 	be->vif = xenvif_alloc(&dev->dev, dev->otherend_id, handle);
@@ -417,10 +419,11 @@ static void backend_create_xenvif(struct backend_info *be)
 		err = PTR_ERR(be->vif);
 		be->vif = NULL;
 		xenbus_dev_fatal(dev, err, "creating interface");
-		return;
+		return err;
 	}
 
 	kobject_uevent(&dev->dev.kobj, KOBJ_ONLINE);
+	return 0;
 }
 
 static void backend_disconnect(struct backend_info *be)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:03:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrQf-0000M7-3d; Mon, 24 Nov 2014 11:03:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsrQe-0000Lv-Ea
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 11:03:36 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	DE/2D-25714-78013745; Mon, 24 Nov 2014 11:03:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416827013!10108558!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8971 invoked from network); 24 Nov 2014 11:03:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 11:03:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196013134"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 06:03:09 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsrQC-0004Zo-Lb;
	Mon, 24 Nov 2014 11:03:08 +0000
Date: Mon, 24 Nov 2014 11:03:08 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Alexey Khoroshilov <khoroshilov@ispras.ru>
Message-ID: <20141124110308.GA322@zion.uk.xensource.com>
References: <20141124100053.GC30053@zion.uk.xensource.com>
	<1416826680-19145-1-git-send-email-khoroshilov@ispras.ru>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416826680-19145-1-git-send-email-khoroshilov@ispras.ru>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ldv-project@linuxtesting.org, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netback: do not report success if
 backend_create_xenvif() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 01:58:00PM +0300, Alexey Khoroshilov wrote:
> If xenvif_alloc() or xenbus_scanf() fail in backend_create_xenvif(),
> xenbus is left in offline mode but netback_probe() reports success.
> 
> The patch implements propagation of error code for backend_create_xenvif().
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>

Acked-by: Wei Liu <wei.liu2@citrix.com>

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:03:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrQf-0000M7-3d; Mon, 24 Nov 2014 11:03:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsrQe-0000Lv-Ea
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 11:03:36 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	DE/2D-25714-78013745; Mon, 24 Nov 2014 11:03:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416827013!10108558!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8971 invoked from network); 24 Nov 2014 11:03:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 11:03:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196013134"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 06:03:09 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsrQC-0004Zo-Lb;
	Mon, 24 Nov 2014 11:03:08 +0000
Date: Mon, 24 Nov 2014 11:03:08 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Alexey Khoroshilov <khoroshilov@ispras.ru>
Message-ID: <20141124110308.GA322@zion.uk.xensource.com>
References: <20141124100053.GC30053@zion.uk.xensource.com>
	<1416826680-19145-1-git-send-email-khoroshilov@ispras.ru>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416826680-19145-1-git-send-email-khoroshilov@ispras.ru>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ldv-project@linuxtesting.org, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netback: do not report success if
 backend_create_xenvif() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 01:58:00PM +0300, Alexey Khoroshilov wrote:
> If xenvif_alloc() or xenbus_scanf() fail in backend_create_xenvif(),
> xenbus is left in offline mode but netback_probe() reports success.
> 
> The patch implements propagation of error code for backend_create_xenvif().
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>

Acked-by: Wei Liu <wei.liu2@citrix.com>

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:05:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrSE-0000Vs-KL; Mon, 24 Nov 2014 11:05:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsrSD-0000Vg-3l
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 11:05:13 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	AA/45-27623-8E013745; Mon, 24 Nov 2014 11:05:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416827109!13262170!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9109 invoked from network); 24 Nov 2014 11:05:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 11:05:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195173918"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 06:03:09 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsrQD-0003OZ-H5;
	Mon, 24 Nov 2014 11:03:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsrQD-0002jW-7a;
	Mon, 24 Nov 2014 11:03:09 +0000
Date: Mon, 24 Nov 2014 11:03:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31784-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31784: 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 31784 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31784/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 30755
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 30755

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                2dc2565902d3c24108c4b7101e91957fd068a242
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
370 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl host-install(3)

Not pushing.

(No revision log; it would be 12352 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 Nov 24 11:05:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsrSE-0000Vs-KL; Mon, 24 Nov 2014 11:05:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsrSD-0000Vg-3l
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 11:05:13 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	AA/45-27623-8E013745; Mon, 24 Nov 2014 11:05:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416827109!13262170!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9109 invoked from network); 24 Nov 2014 11:05:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 11:05:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195173918"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 06:03:09 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsrQD-0003OZ-H5;
	Mon, 24 Nov 2014 11:03:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsrQD-0002jW-7a;
	Mon, 24 Nov 2014 11:03:09 +0000
Date: Mon, 24 Nov 2014 11:03:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31784-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31784: 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 31784 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31784/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 30755
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 30755

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                2dc2565902d3c24108c4b7101e91957fd068a242
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
370 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl host-install(3)

Not pushing.

(No revision log; it would be 12352 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 Nov 24 11:28:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsrok-00019s-9h; Mon, 24 Nov 2014 11:28:30 +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 1Xsroj-00019m-11
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 11:28:29 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	6C/15-22777-C5613745; Mon, 24 Nov 2014 11:28:28 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416828507!9644963!1
X-Originating-IP: [62.142.5.109]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTA5ID0+IDk1MjIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11205 invoked from network); 24 Nov 2014 11:28:27 -0000
Received: from emh03.mail.saunalahti.fi (HELO emh03.mail.saunalahti.fi)
	(62.142.5.109)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 11:28:27 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh03.mail.saunalahti.fi (Postfix) with ESMTP id AFE63188854;
	Mon, 24 Nov 2014 13:28:26 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7796636C01F; Mon, 24 Nov 2014 13:28:26 +0200 (EET)
Date: Mon, 24 Nov 2014 13:28:26 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: greg@enjellic.com
Message-ID: <20141124112826.GO12451@reaktio.net>
References: <pasik@iki.fi>
 <201411240959.sAO9xnqh014699@wind.enjellic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201411240959.sAO9xnqh014699@wind.enjellic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 03:59:49AM -0600, Dr. Greg Wettstein wrote:
> On Nov 23,  4:26pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:
> } Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
> 
> Hi Pasi, hope your week is starting out well, hi to Konrad from Oracle
> as well as I see you included him.
>

Hello,

 
> > On Fri, Nov 21, 2014 at 02:57:14PM -0600, Dr. Greg Wettstein wrote:
> > > Hi, hope the week is ending well for everyone.
> > > 
> > > As readers of the list may remember we've kept the ATI primary adapter
> > > passthrough patches current for qemu-traditional on Xen for a number
> > > of years.  Our 'run-passthrough' utility for binding/unbind devices
> > > and running a Windows guest with passthrough have enjoyed a tidy
> > > number of downloads through the years as well.
> > > 
> > > We are taking on a passthrough project and in the process upgrading
> > > our infrastructure to 4.4.x.  We also need to take on the issue of
> > > passing Intel IGD adapters through to a windows guest.  We are
> > > currently working on an Intel Q77 (DQ77KB) board in preparation for
> > > moving to Q87 boards.
> > > 
> > > The Intel display adapter is showing up as the standard 00:02.0 PCI
> > > device and things go south pretty quickly.  We create a slot for the
> > > device on the pciback driver and as soon as we bind the device the
> > > machine goes out like a light, no logs or diagnostics, just instantly
> > > stone dead.
> 
> I'm consolidating your comment from your other response as well so we
> keep this on the same thread.
> 

OK.


> >> As I was walking out the door I remembered I had been delinquent
> >> with information.  The dom0 kernel is 32-bit 3.14.22 straight from
> >> kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.
> 
> > Wow, quite an old thread :)
> >  
> > So you're still seeing the same problem with recent Xen/Linux
> > versions.. 
> 
> Yes, the perils of platforming for 7 year field deployments... :-)
> 
> I can certainly build up a toolchain against the HEAD of XEN git and
> the most recent release of the kernel if everyone feels that would be
> beneficial.
> 
> > This might be a stupid question, but here goes anyway: Do you have
> > serial console set up? And all the debug/verbose options specified
> > for Xen and Linux?
> 
> The platform in question doesn't have any serial ports, at least not
> surfaced.  We will need to do a bit of wiring if we need to go in that
> direction.
> 

You mentioned it's Intel Q77 chipset based motherboard.. 
which means it should have Intel AMT functionality, which provides SOL (Serial-over-LAN),
which you can use as a serial console for Xen.

There are tools (at least amtterm) that you can use on another box to connect to the AMT SOL remotely..



> Now that I have the machine in a harness in the lab I will stick a
> '#define DEBUG 1' in the top of drivers/xen/xen-pciback/pci_stub.c
> since that is where the action seems to be going on.
> 
> The platform is headed for a measured computing environment so I
> thought there may be some type of conflict with tboot holding a
> reference to the VGA driver but I verified the issue in a straight
> hypervisor boot.
> 
> I see that Tiejun Chen from Intel is sorting out issues with respect
> to the need to export the ISA bridge into the device emulator in order
> to support passthrough on these IGD devices.  I bound the 00:1f.0 ISA
> bridge device to pciback and that worked but it did not change the
> behavior of the regression.  When the 00:02.0 device is bound to
> pciback the display is cleared and the machine dies in its tracks.
> 

Yeah, Tiejun is working on upstreaming the IGD passthru patches to Qemu-upstream.

Qemu-dm-traditional already has (most of) the IGD passthru patches. 


Hope that helps,

-- Pasi

> I will turn up debugging in pci_stub and see if I can pinpoint where
> things blow up, somewhere in pcistub_init_device() I would imagine.
> 
> > Thanks,
> > 
> > -- Pasi
> 
> Have a good day.
> 
> }-- End of excerpt from Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=
> 
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: greg@enjellic.com
> ------------------------------------------------------------------------------
> "Snow removal teaches all the important elements of succesful corporate
>  politics:  1.) Be the first one to work.  2.) Always signal your
>  intentions before moving.  3.) Be damn sure you're driving something
>  big enough to deal with anything that decides not to get out of your way."
>                                 -- Dr. G.W. Wettstein
>                                    Guerrilla Tactics for Corporate Survival

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:28:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsrok-00019s-9h; Mon, 24 Nov 2014 11:28:30 +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 1Xsroj-00019m-11
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 11:28:29 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	6C/15-22777-C5613745; Mon, 24 Nov 2014 11:28:28 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416828507!9644963!1
X-Originating-IP: [62.142.5.109]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTA5ID0+IDk1MjIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11205 invoked from network); 24 Nov 2014 11:28:27 -0000
Received: from emh03.mail.saunalahti.fi (HELO emh03.mail.saunalahti.fi)
	(62.142.5.109)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 11:28:27 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh03.mail.saunalahti.fi (Postfix) with ESMTP id AFE63188854;
	Mon, 24 Nov 2014 13:28:26 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7796636C01F; Mon, 24 Nov 2014 13:28:26 +0200 (EET)
Date: Mon, 24 Nov 2014 13:28:26 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: greg@enjellic.com
Message-ID: <20141124112826.GO12451@reaktio.net>
References: <pasik@iki.fi>
 <201411240959.sAO9xnqh014699@wind.enjellic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201411240959.sAO9xnqh014699@wind.enjellic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 03:59:49AM -0600, Dr. Greg Wettstein wrote:
> On Nov 23,  4:26pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:
> } Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
> 
> Hi Pasi, hope your week is starting out well, hi to Konrad from Oracle
> as well as I see you included him.
>

Hello,

 
> > On Fri, Nov 21, 2014 at 02:57:14PM -0600, Dr. Greg Wettstein wrote:
> > > Hi, hope the week is ending well for everyone.
> > > 
> > > As readers of the list may remember we've kept the ATI primary adapter
> > > passthrough patches current for qemu-traditional on Xen for a number
> > > of years.  Our 'run-passthrough' utility for binding/unbind devices
> > > and running a Windows guest with passthrough have enjoyed a tidy
> > > number of downloads through the years as well.
> > > 
> > > We are taking on a passthrough project and in the process upgrading
> > > our infrastructure to 4.4.x.  We also need to take on the issue of
> > > passing Intel IGD adapters through to a windows guest.  We are
> > > currently working on an Intel Q77 (DQ77KB) board in preparation for
> > > moving to Q87 boards.
> > > 
> > > The Intel display adapter is showing up as the standard 00:02.0 PCI
> > > device and things go south pretty quickly.  We create a slot for the
> > > device on the pciback driver and as soon as we bind the device the
> > > machine goes out like a light, no logs or diagnostics, just instantly
> > > stone dead.
> 
> I'm consolidating your comment from your other response as well so we
> keep this on the same thread.
> 

OK.


> >> As I was walking out the door I remembered I had been delinquent
> >> with information.  The dom0 kernel is 32-bit 3.14.22 straight from
> >> kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.
> 
> > Wow, quite an old thread :)
> >  
> > So you're still seeing the same problem with recent Xen/Linux
> > versions.. 
> 
> Yes, the perils of platforming for 7 year field deployments... :-)
> 
> I can certainly build up a toolchain against the HEAD of XEN git and
> the most recent release of the kernel if everyone feels that would be
> beneficial.
> 
> > This might be a stupid question, but here goes anyway: Do you have
> > serial console set up? And all the debug/verbose options specified
> > for Xen and Linux?
> 
> The platform in question doesn't have any serial ports, at least not
> surfaced.  We will need to do a bit of wiring if we need to go in that
> direction.
> 

You mentioned it's Intel Q77 chipset based motherboard.. 
which means it should have Intel AMT functionality, which provides SOL (Serial-over-LAN),
which you can use as a serial console for Xen.

There are tools (at least amtterm) that you can use on another box to connect to the AMT SOL remotely..



> Now that I have the machine in a harness in the lab I will stick a
> '#define DEBUG 1' in the top of drivers/xen/xen-pciback/pci_stub.c
> since that is where the action seems to be going on.
> 
> The platform is headed for a measured computing environment so I
> thought there may be some type of conflict with tboot holding a
> reference to the VGA driver but I verified the issue in a straight
> hypervisor boot.
> 
> I see that Tiejun Chen from Intel is sorting out issues with respect
> to the need to export the ISA bridge into the device emulator in order
> to support passthrough on these IGD devices.  I bound the 00:1f.0 ISA
> bridge device to pciback and that worked but it did not change the
> behavior of the regression.  When the 00:02.0 device is bound to
> pciback the display is cleared and the machine dies in its tracks.
> 

Yeah, Tiejun is working on upstreaming the IGD passthru patches to Qemu-upstream.

Qemu-dm-traditional already has (most of) the IGD passthru patches. 


Hope that helps,

-- Pasi

> I will turn up debugging in pci_stub and see if I can pinpoint where
> things blow up, somewhere in pcistub_init_device() I would imagine.
> 
> > Thanks,
> > 
> > -- Pasi
> 
> Have a good day.
> 
> }-- End of excerpt from Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=
> 
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: greg@enjellic.com
> ------------------------------------------------------------------------------
> "Snow removal teaches all the important elements of succesful corporate
>  politics:  1.) Be the first one to work.  2.) Always signal your
>  intentions before moving.  3.) Be damn sure you're driving something
>  big enough to deal with anything that decides not to get out of your way."
>                                 -- Dr. G.W. Wettstein
>                                    Guerrilla Tactics for Corporate Survival

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:41:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xss17-0001VT-Kx; Mon, 24 Nov 2014 11:41:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xss16-0001VO-Gk
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 11:41:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	94/52-09842-B5913745; Mon, 24 Nov 2014 11:41:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416829275!14881057!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 728 invoked from network); 24 Nov 2014 11:41:15 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 11:41:15 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 11:41:14 +0000
Message-Id: <54732768020000780004A48C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 11:41:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
In-Reply-To: <7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1E2B3448.2__="
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part1E2B3448.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 24.11.14 at 10:08, <sflist@ihonk.com> wrote:
> On Nov 24, 2014, at 00:45, Jan Beulich <JBeulich@suse.com> wrote:
>=20
>>>>> On 23.11.14 at 02:28, <sflist@ihonk.com> wrote:
>>> With mwait-idle=3D0:
>>>=20
>>> (XEN) 'c' pressed -> printing ACPI Cx structures
>>> (XEN) =3D=3Dcpu0=3D=3D
>>> (XEN) active state:             C0
>>> (XEN) max_cstate:               C7
>>> (XEN) states:
>>> (XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH]=20
>>> duration[0]
>>> (XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE]=20
>>> duration[0]
>>> (XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH]=20
>>> duration[0]
>>> (XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH]=20
>>> duration[0]
>>> (XEN)    *C0:   usage[00000000] duration[46930624784]
>>> (XEN) PC2[0] PC3[0] PC6[0] PC7[0]
>>> (XEN) CC3[0] CC6[0] CC7[0]
>>> [...]
>>=20
>> Very interesting - the hypervisor has C-state information, but never
>> entered any of them. That certainly explains the difference between
>> using/not using the ,wait-idle driver, but puts us back to there being
>> a more general issue with C-state use on this CPU model. Possibly
>> related to C2 having entry method "NONE", but then again I can't
>> see how such a state could get entered into the table the first place:
>> set_cx() bails upon check_cx() returning an error, and hence its
>> switch()'s default statement should never be reached. Plus even if an
>> array entry was set to "NONE", it should simply be ignored when
>> looking for a state to enter. I'll probably need to put together a
>> debugging patch to figure out what's going on here.
>=20
> Okay, happy to give it a go whenever you have the time to put =
something=20
> together.

While putting this together I found the reason for the strange
C2: line, and the attached debugging patch already has the fix
for it (which I'll also submit separately, and hence you may need
to drop that specific hunk should you end up applying it on a tree
which already has that fix). You'll need to again run with
"mwait-idle=3D0", and it's the boot messages along with the 'c'
debug key output that's of interest.

Thanks, Jan


--=__Part1E2B3448.2__=
Content-Type: text/plain; name="Freitas-Cx.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="Freitas-Cx.patch"

--- unstable.orig/xen/arch/x86/acpi/cpu_idle.c=0A+++ unstable/xen/arch/x86/=
acpi/cpu_idle.c=0A@@ -58,7 +58,7 @@=0A #include <xen/notifier.h>=0A =
#include <xen/cpu.h>=0A =0A-/*#define DEBUG_PM_CX*/=0A+#define DEBUG_PM_CX=
=0A =0A #define GET_HW_RES_IN_NS(msr, val) \=0A     do { rdmsrl(msr, val); =
val =3D tsc_ticks2ns(val); } while( 0 )=0A@@ -238,6 +238,9 @@ static char* =
acpi_cstate_method_name[] =3D=0A     "HALT"=0A };=0A =0A+struct reasons { =
unsigned long max, pwr, urg, nxt; };//temp=0A+static DEFINE_PER_CPU(struct =
reasons, reasons);//temp=0A+=0A static void print_acpi_power(uint32_t cpu, =
struct acpi_processor_power *power)=0A {=0A     uint32_t i, idle_usage =3D =
0;=0A@@ -273,6 +276,8 @@ static void print_acpi_power(uint32_t cp=0A     =
printk((last_state_idx =3D=3D 0) ? "   *" : "    ");=0A     printk("C0:\tus=
age[%08d] duration[%"PRId64"]\n",=0A            idle_usage, NOW() - =
idle_res);=0A+printk("max=3D%lx pwr=3D%lx urg=3D%lx nxt=3D%lx\n",//temp=0A+=
       per_cpu(reasons.max, cpu), per_cpu(reasons.pwr, cpu), per_cpu(reason=
s.urg, cpu), per_cpu(reasons.nxt, cpu));=0A =0A     print_hw_residencies(cp=
u);=0A }=0A@@ -501,6 +506,7 @@ static void acpi_processor_idle(void)=0A    =
 u32 exp =3D 0, pred =3D 0;=0A     u32 irq_traced[4] =3D { 0 };=0A =
=0A+next_state =3D 1;//temp=0A     if ( max_cstate > 0 && power && =
!sched_has_urgent_vcpu() &&=0A          (next_state =3D cpuidle_current_gov=
ernor->select(power)) > 0 )=0A     {=0A@@ -519,6 +525,10 @@ static void =
acpi_processor_idle(void)=0A     }=0A     if ( !cx )=0A     {=0A+this_cpu(r=
easons.max) +=3D max_cstate <=3D 0;//temp=0A+this_cpu(reasons.pwr) +=3D =
!power;//temp=0A+this_cpu(reasons.urg) +=3D !!sched_has_urgent_vcpu();//tem=
p=0A+this_cpu(reasons.nxt) +=3D next_state <=3D 0;//temp=0A         if ( =
pm_idle_save )=0A             pm_idle_save();=0A         else=0A@@ -1007,6 =
+1017,7 @@ static void set_cx(=0A         cx->entry_method =3D ACPI_CSTATE_=
EM_SYSIO;=0A         break;=0A     default:=0A+printk("CPU%u: C%u space =
%x?\n", acpi_power->cpu, xen_cx->type, xen_cx->reg.space_id);//temp=0A     =
    cx->entry_method =3D ACPI_CSTATE_EM_NONE;=0A         break;=0A     =
}=0A@@ -1015,7 +1026,7 @@ static void set_cx(=0A     cx->target_residency =
=3D cx->latency * latency_factor;=0A =0A     smp_wmb();=0A-    acpi_power->=
count++;=0A+    acpi_power->count +=3D (cx->type !=3D ACPI_STATE_C1);=0A   =
  if ( cx->type =3D=3D ACPI_STATE_C1 || cx->type =3D=3D ACPI_STATE_C2 )=0A =
        acpi_power->safe_state =3D cx;=0A }=0A@@ -1141,6 +1152,7 @@ long =
set_cx_pminfo(uint32_t cpu, struct =0A =0A     /* FIXME: C-state dependency=
 is not supported by far */=0A =0A+printk("CPU%u: %pS, %pS\n", cpu, =
pm_idle_save, pm_idle);//temp=0A     if ( cpu_id =3D=3D 0 )=0A     {=0A    =
     if ( pm_idle_save =3D=3D NULL )=0A
--=__Part1E2B3448.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part1E2B3448.2__=--


From xen-devel-bounces@lists.xen.org Mon Nov 24 11:41:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xss17-0001VT-Kx; Mon, 24 Nov 2014 11:41:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xss16-0001VO-Gk
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 11:41:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	94/52-09842-B5913745; Mon, 24 Nov 2014 11:41:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416829275!14881057!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 728 invoked from network); 24 Nov 2014 11:41:15 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 11:41:15 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 11:41:14 +0000
Message-Id: <54732768020000780004A48C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 11:41:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
In-Reply-To: <7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1E2B3448.2__="
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part1E2B3448.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 24.11.14 at 10:08, <sflist@ihonk.com> wrote:
> On Nov 24, 2014, at 00:45, Jan Beulich <JBeulich@suse.com> wrote:
>=20
>>>>> On 23.11.14 at 02:28, <sflist@ihonk.com> wrote:
>>> With mwait-idle=3D0:
>>>=20
>>> (XEN) 'c' pressed -> printing ACPI Cx structures
>>> (XEN) =3D=3Dcpu0=3D=3D
>>> (XEN) active state:             C0
>>> (XEN) max_cstate:               C7
>>> (XEN) states:
>>> (XEN)     C1:   type[C1] latency[001] usage[00000000] method[  FFH]=20
>>> duration[0]
>>> (XEN)     C2:   type[C0] latency[000] usage[00000000] method[ NONE]=20
>>> duration[0]
>>> (XEN)     C3:   type[C3] latency[064] usage[00000000] method[  FFH]=20
>>> duration[0]
>>> (XEN)     C4:   type[C3] latency[096] usage[00000000] method[  FFH]=20
>>> duration[0]
>>> (XEN)    *C0:   usage[00000000] duration[46930624784]
>>> (XEN) PC2[0] PC3[0] PC6[0] PC7[0]
>>> (XEN) CC3[0] CC6[0] CC7[0]
>>> [...]
>>=20
>> Very interesting - the hypervisor has C-state information, but never
>> entered any of them. That certainly explains the difference between
>> using/not using the ,wait-idle driver, but puts us back to there being
>> a more general issue with C-state use on this CPU model. Possibly
>> related to C2 having entry method "NONE", but then again I can't
>> see how such a state could get entered into the table the first place:
>> set_cx() bails upon check_cx() returning an error, and hence its
>> switch()'s default statement should never be reached. Plus even if an
>> array entry was set to "NONE", it should simply be ignored when
>> looking for a state to enter. I'll probably need to put together a
>> debugging patch to figure out what's going on here.
>=20
> Okay, happy to give it a go whenever you have the time to put =
something=20
> together.

While putting this together I found the reason for the strange
C2: line, and the attached debugging patch already has the fix
for it (which I'll also submit separately, and hence you may need
to drop that specific hunk should you end up applying it on a tree
which already has that fix). You'll need to again run with
"mwait-idle=3D0", and it's the boot messages along with the 'c'
debug key output that's of interest.

Thanks, Jan


--=__Part1E2B3448.2__=
Content-Type: text/plain; name="Freitas-Cx.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="Freitas-Cx.patch"

--- unstable.orig/xen/arch/x86/acpi/cpu_idle.c=0A+++ unstable/xen/arch/x86/=
acpi/cpu_idle.c=0A@@ -58,7 +58,7 @@=0A #include <xen/notifier.h>=0A =
#include <xen/cpu.h>=0A =0A-/*#define DEBUG_PM_CX*/=0A+#define DEBUG_PM_CX=
=0A =0A #define GET_HW_RES_IN_NS(msr, val) \=0A     do { rdmsrl(msr, val); =
val =3D tsc_ticks2ns(val); } while( 0 )=0A@@ -238,6 +238,9 @@ static char* =
acpi_cstate_method_name[] =3D=0A     "HALT"=0A };=0A =0A+struct reasons { =
unsigned long max, pwr, urg, nxt; };//temp=0A+static DEFINE_PER_CPU(struct =
reasons, reasons);//temp=0A+=0A static void print_acpi_power(uint32_t cpu, =
struct acpi_processor_power *power)=0A {=0A     uint32_t i, idle_usage =3D =
0;=0A@@ -273,6 +276,8 @@ static void print_acpi_power(uint32_t cp=0A     =
printk((last_state_idx =3D=3D 0) ? "   *" : "    ");=0A     printk("C0:\tus=
age[%08d] duration[%"PRId64"]\n",=0A            idle_usage, NOW() - =
idle_res);=0A+printk("max=3D%lx pwr=3D%lx urg=3D%lx nxt=3D%lx\n",//temp=0A+=
       per_cpu(reasons.max, cpu), per_cpu(reasons.pwr, cpu), per_cpu(reason=
s.urg, cpu), per_cpu(reasons.nxt, cpu));=0A =0A     print_hw_residencies(cp=
u);=0A }=0A@@ -501,6 +506,7 @@ static void acpi_processor_idle(void)=0A    =
 u32 exp =3D 0, pred =3D 0;=0A     u32 irq_traced[4] =3D { 0 };=0A =
=0A+next_state =3D 1;//temp=0A     if ( max_cstate > 0 && power && =
!sched_has_urgent_vcpu() &&=0A          (next_state =3D cpuidle_current_gov=
ernor->select(power)) > 0 )=0A     {=0A@@ -519,6 +525,10 @@ static void =
acpi_processor_idle(void)=0A     }=0A     if ( !cx )=0A     {=0A+this_cpu(r=
easons.max) +=3D max_cstate <=3D 0;//temp=0A+this_cpu(reasons.pwr) +=3D =
!power;//temp=0A+this_cpu(reasons.urg) +=3D !!sched_has_urgent_vcpu();//tem=
p=0A+this_cpu(reasons.nxt) +=3D next_state <=3D 0;//temp=0A         if ( =
pm_idle_save )=0A             pm_idle_save();=0A         else=0A@@ -1007,6 =
+1017,7 @@ static void set_cx(=0A         cx->entry_method =3D ACPI_CSTATE_=
EM_SYSIO;=0A         break;=0A     default:=0A+printk("CPU%u: C%u space =
%x?\n", acpi_power->cpu, xen_cx->type, xen_cx->reg.space_id);//temp=0A     =
    cx->entry_method =3D ACPI_CSTATE_EM_NONE;=0A         break;=0A     =
}=0A@@ -1015,7 +1026,7 @@ static void set_cx(=0A     cx->target_residency =
=3D cx->latency * latency_factor;=0A =0A     smp_wmb();=0A-    acpi_power->=
count++;=0A+    acpi_power->count +=3D (cx->type !=3D ACPI_STATE_C1);=0A   =
  if ( cx->type =3D=3D ACPI_STATE_C1 || cx->type =3D=3D ACPI_STATE_C2 )=0A =
        acpi_power->safe_state =3D cx;=0A }=0A@@ -1141,6 +1152,7 @@ long =
set_cx_pminfo(uint32_t cpu, struct =0A =0A     /* FIXME: C-state dependency=
 is not supported by far */=0A =0A+printk("CPU%u: %pS, %pS\n", cpu, =
pm_idle_save, pm_idle);//temp=0A     if ( cpu_id =3D=3D 0 )=0A     {=0A    =
     if ( pm_idle_save =3D=3D NULL )=0A
--=__Part1E2B3448.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part1E2B3448.2__=--


From xen-devel-bounces@lists.xen.org Mon Nov 24 11:47:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:47:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xss7B-0001nx-PK; Mon, 24 Nov 2014 11:47:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xss7B-0001ns-06
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 11:47:33 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	D4/12-09284-4DA13745; Mon, 24 Nov 2014 11:47:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416829651!13357087!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5709 invoked from network); 24 Nov 2014 11:47:31 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 11:47:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 11:47:31 +0000
Message-Id: <547328E0020000780004A4A1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 11:47:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part95A0BFC0.0__="
Subject: [Xen-devel] [PATCH] x86/cpuidle: don't count C1 multiple times
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part95A0BFC0.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Commit 4ca6f9f0 ("x86/cpuidle: publish new states only after fully
initializing them") resulted in the state counter to be incremented
for C1 despite that using a fixed table entry (and the statically
initialized counter value already accounting for it and C0).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -1015,7 +1015,7 @@ static void set_cx(
     cx->target_residency =3D cx->latency * latency_factor;
=20
     smp_wmb();
-    acpi_power->count++;
+    acpi_power->count +=3D (cx->type !=3D ACPI_STATE_C1);
     if ( cx->type =3D=3D ACPI_STATE_C1 || cx->type =3D=3D ACPI_STATE_C2 )
         acpi_power->safe_state =3D cx;
 }




--=__Part95A0BFC0.0__=
Content-Type: text/plain; name="x86-count-C1-once.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-count-C1-once.patch"

x86/cpuidle: don't count C1 multiple times=0A=0ACommit 4ca6f9f0 ("x86/cpuid=
le: publish new states only after fully=0Ainitializing them") resulted in =
the state counter to be incremented=0Afor C1 despite that using a fixed =
table entry (and the statically=0Ainitialized counter value already =
accounting for it and C0).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.c=
om>=0A=0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cpu_i=
dle.c=0A@@ -1015,7 +1015,7 @@ static void set_cx(=0A     cx->target_residen=
cy =3D cx->latency * latency_factor;=0A =0A     smp_wmb();=0A-    =
acpi_power->count++;=0A+    acpi_power->count +=3D (cx->type !=3D =
ACPI_STATE_C1);=0A     if ( cx->type =3D=3D ACPI_STATE_C1 || cx->type =
=3D=3D ACPI_STATE_C2 )=0A         acpi_power->safe_state =3D cx;=0A }=0A
--=__Part95A0BFC0.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

--=__Part95A0BFC0.0__=--


From xen-devel-bounces@lists.xen.org Mon Nov 24 11:47:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:47:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xss7B-0001nx-PK; Mon, 24 Nov 2014 11:47:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xss7B-0001ns-06
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 11:47:33 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	D4/12-09284-4DA13745; Mon, 24 Nov 2014 11:47:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416829651!13357087!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5709 invoked from network); 24 Nov 2014 11:47:31 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 11:47:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 11:47:31 +0000
Message-Id: <547328E0020000780004A4A1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 11:47:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part95A0BFC0.0__="
Subject: [Xen-devel] [PATCH] x86/cpuidle: don't count C1 multiple times
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part95A0BFC0.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Commit 4ca6f9f0 ("x86/cpuidle: publish new states only after fully
initializing them") resulted in the state counter to be incremented
for C1 despite that using a fixed table entry (and the statically
initialized counter value already accounting for it and C0).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -1015,7 +1015,7 @@ static void set_cx(
     cx->target_residency =3D cx->latency * latency_factor;
=20
     smp_wmb();
-    acpi_power->count++;
+    acpi_power->count +=3D (cx->type !=3D ACPI_STATE_C1);
     if ( cx->type =3D=3D ACPI_STATE_C1 || cx->type =3D=3D ACPI_STATE_C2 )
         acpi_power->safe_state =3D cx;
 }




--=__Part95A0BFC0.0__=
Content-Type: text/plain; name="x86-count-C1-once.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-count-C1-once.patch"

x86/cpuidle: don't count C1 multiple times=0A=0ACommit 4ca6f9f0 ("x86/cpuid=
le: publish new states only after fully=0Ainitializing them") resulted in =
the state counter to be incremented=0Afor C1 despite that using a fixed =
table entry (and the statically=0Ainitialized counter value already =
accounting for it and C0).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.c=
om>=0A=0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cpu_i=
dle.c=0A@@ -1015,7 +1015,7 @@ static void set_cx(=0A     cx->target_residen=
cy =3D cx->latency * latency_factor;=0A =0A     smp_wmb();=0A-    =
acpi_power->count++;=0A+    acpi_power->count +=3D (cx->type !=3D =
ACPI_STATE_C1);=0A     if ( cx->type =3D=3D ACPI_STATE_C1 || cx->type =
=3D=3D ACPI_STATE_C2 )=0A         acpi_power->safe_state =3D cx;=0A }=0A
--=__Part95A0BFC0.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

--=__Part95A0BFC0.0__=--


From xen-devel-bounces@lists.xen.org Mon Nov 24 11:49:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xss94-0001vQ-F9; Mon, 24 Nov 2014 11:49: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 1Xss92-0001vG-LI
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 11:49:28 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	27/46-29352-74B13745; Mon, 24 Nov 2014 11:49:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416829767!12983780!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9860 invoked from network); 24 Nov 2014 11:49:27 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 11:49:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 11:49:27 +0000
Message-Id: <54732954020000780004A4AB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 11:49:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
In-Reply-To: <546DCAB102000078000493E0@smtp.nue.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 0/3] x86: XSA-109/110 follow-up (to be
 considered for 4.5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.11.14 at 11:04, <JBeulich@suse.com> wrote:
> 1: tighten page table owner checking in do_mmu_update()
> 2: don't ignore foreigndom input on various MMUEXT ops
> 3: HVM: don't crash guest upon problems occurring in user mode
> 
> Reason to request considering this for 4.5: Tightened argument
> checking (as done in the first two patches) reduces the chances
> of them getting abused. Not unduly crashing the guest (as done
> in the third one) may avoid future security issues of guest user
> mode affecting the guest kernel.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Hi Konrad - looks like I forgot to Cc you...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:49:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xss94-0001vQ-F9; Mon, 24 Nov 2014 11:49: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 1Xss92-0001vG-LI
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 11:49:28 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	27/46-29352-74B13745; Mon, 24 Nov 2014 11:49:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1416829767!12983780!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9860 invoked from network); 24 Nov 2014 11:49:27 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 11:49:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 11:49:27 +0000
Message-Id: <54732954020000780004A4AB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 11:49:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
In-Reply-To: <546DCAB102000078000493E0@smtp.nue.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 0/3] x86: XSA-109/110 follow-up (to be
 considered for 4.5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.11.14 at 11:04, <JBeulich@suse.com> wrote:
> 1: tighten page table owner checking in do_mmu_update()
> 2: don't ignore foreigndom input on various MMUEXT ops
> 3: HVM: don't crash guest upon problems occurring in user mode
> 
> Reason to request considering this for 4.5: Tightened argument
> checking (as done in the first two patches) reduces the chances
> of them getting abused. Not unduly crashing the guest (as done
> in the third one) may avoid future security issues of guest user
> mode affecting the guest kernel.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Hi Konrad - looks like I forgot to Cc you...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:50:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11: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 1XssA8-000214-T5; Mon, 24 Nov 2014 11:50:36 +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 1XssA7-00020u-LV
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 11:50:35 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	45/5A-02696-A8B13745; Mon, 24 Nov 2014 11:50:34 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416829833!14418628!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23451 invoked from network); 24 Nov 2014 11:50:33 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 11:50:33 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so5347234wiw.14
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 03:50:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=p19xQidnAX5FBE1mUxRG5llfZQTLaC6qweJtRdo9As8=;
	b=pE0bP36577uBKdTfLRM3TAei14OVepI8wNidsuJYBYTGhJhRZKpSTgoqSwaMkgCCEf
	PnT7/Nr3SeA+Pp3SPqeT7DSNHoaZcr6TNhZLWMaUeTJr1aL4FPDYRirC3KCif+MGh7Tp
	1d3tSaDB2tatifqZQpQbdPse5FqMUieTTSao+y2+sUE/kd/qZEUfMj9gvH3gaTcrhZBi
	EbS0VYoFTqKIyjmG6JIy+HoeyKdlu9HIxE1H1PEzKZest9qgPsGbJGyTkfUjItlDOE8v
	/bJLjEBI5VAxKUGLwOIs5JOxXUzBzMqMEfAcLuhD6ZRKMj+GI6hPRnlUzEqNNAjr2/tt
	WUwA==
MIME-Version: 1.0
X-Received: by 10.180.24.72 with SMTP id s8mr21121268wif.73.1416829833631;
	Mon, 24 Nov 2014 03:50:33 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 24 Nov 2014 03:50:33 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
Date: Mon, 24 Nov 2014 11:50:33 +0000
X-Google-Sender-Auth: xSMyith8OkMl3_-7Kfp_uaKcvks
Message-ID: <CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <Wei.Liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
> On Sat, 22 Nov 2014, M A Young wrote:
>
>> While investigating a bug reported on Red Hat Bugzilla
>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>> I discovered the following
>>
>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>> are actually two issues here
>>
>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>> presumably because the allocated memory eventually runs out
>
>
> I have found a bit more out about this. The segfault at at line 1378 of
> tools/libxc/xc_domain_restore.c which is
>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>                         csum_page(buf));
> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
> array. This occurs in the verification phase.
>
>> * the segfault doesn't occur if the guest memory is 128M, but the
>> migration still fails. The first attached file contains the log from a run
>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>> stripped out to make the size manageable).
>
>
> The difference actually seems to be down to how active the VM is rather than
> the memory size (my small memory test system was doing very little, my
> larger system was a full OS install). In the non-segfault case the problem
> was the printf and printf_info commands in the create_domain() routine in
> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
> back from the restoring dom0, these commands cause an unexpected message. If
> you move them onto stderr then the migration completes in the non-segfault
> case.

Good job tracking those down -- are there patches in the works?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:50:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11: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 1XssA8-000214-T5; Mon, 24 Nov 2014 11:50:36 +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 1XssA7-00020u-LV
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 11:50:35 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	45/5A-02696-A8B13745; Mon, 24 Nov 2014 11:50:34 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416829833!14418628!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23451 invoked from network); 24 Nov 2014 11:50:33 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 11:50:33 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so5347234wiw.14
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 03:50:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=p19xQidnAX5FBE1mUxRG5llfZQTLaC6qweJtRdo9As8=;
	b=pE0bP36577uBKdTfLRM3TAei14OVepI8wNidsuJYBYTGhJhRZKpSTgoqSwaMkgCCEf
	PnT7/Nr3SeA+Pp3SPqeT7DSNHoaZcr6TNhZLWMaUeTJr1aL4FPDYRirC3KCif+MGh7Tp
	1d3tSaDB2tatifqZQpQbdPse5FqMUieTTSao+y2+sUE/kd/qZEUfMj9gvH3gaTcrhZBi
	EbS0VYoFTqKIyjmG6JIy+HoeyKdlu9HIxE1H1PEzKZest9qgPsGbJGyTkfUjItlDOE8v
	/bJLjEBI5VAxKUGLwOIs5JOxXUzBzMqMEfAcLuhD6ZRKMj+GI6hPRnlUzEqNNAjr2/tt
	WUwA==
MIME-Version: 1.0
X-Received: by 10.180.24.72 with SMTP id s8mr21121268wif.73.1416829833631;
	Mon, 24 Nov 2014 03:50:33 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 24 Nov 2014 03:50:33 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
Date: Mon, 24 Nov 2014 11:50:33 +0000
X-Google-Sender-Auth: xSMyith8OkMl3_-7Kfp_uaKcvks
Message-ID: <CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <Wei.Liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
> On Sat, 22 Nov 2014, M A Young wrote:
>
>> While investigating a bug reported on Red Hat Bugzilla
>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>> I discovered the following
>>
>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>> are actually two issues here
>>
>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>> presumably because the allocated memory eventually runs out
>
>
> I have found a bit more out about this. The segfault at at line 1378 of
> tools/libxc/xc_domain_restore.c which is
>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>                         csum_page(buf));
> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
> array. This occurs in the verification phase.
>
>> * the segfault doesn't occur if the guest memory is 128M, but the
>> migration still fails. The first attached file contains the log from a run
>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>> stripped out to make the size manageable).
>
>
> The difference actually seems to be down to how active the VM is rather than
> the memory size (my small memory test system was doing very little, my
> larger system was a full OS install). In the non-segfault case the problem
> was the printf and printf_info commands in the create_domain() routine in
> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
> back from the restoring dom0, these commands cause an unexpected message. If
> you move them onto stderr then the migration completes in the non-segfault
> case.

Good job tracking those down -- are there patches in the works?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:56:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:56:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XssFy-0002Hk-OP; Mon, 24 Nov 2014 11:56:38 +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 1XssFx-0002Hf-UW
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 11:56:38 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	49/DE-24124-5FC13745; Mon, 24 Nov 2014 11:56:37 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416830196!13049522!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8494 invoked from network); 24 Nov 2014 11:56:36 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 11:56:36 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so5414545wiv.0
	for <xen-devel@lists.xenproject.org>;
	Mon, 24 Nov 2014 03:56:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=cFs3kcGQ3LeMoHNG4vz0adCkUtjUYLXd9FrIQk1/H3c=;
	b=WD3S0g6PFwOqgiyG3IlLkGkN/oSNNuHgHKj/hIZB2yNlbepBuhxAVgjRUPbTaewzmP
	4y9+IWhxKxLtV6frqXfgrggjJwfovKU9/S/2IOsZgkt6YVZnTGUDU+RToRc4/elnOnAk
	4hgRsRLWrZoy7XZ4SRcr6rJniG1ixwOC7PQQ+6nCBexU/jj1B2Rvwi6e8MqDYWEyJ3w8
	cOkhuLfWkcEQMeMudtfvDb66lj6b3miY2TOOf5JHJgh0YRsgUEOZDSRyiK/7HjVxrhuF
	XpShW6vVhxKKYklxtJQRMx0XTI1NcdMu0MBCRMUamtM14o0YCknXJaWBbIiw74DQVxiH
	9GZg==
MIME-Version: 1.0
X-Received: by 10.180.81.134 with SMTP id a6mr20481508wiy.11.1416830196094;
	Mon, 24 Nov 2014 03:56:36 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 24 Nov 2014 03:56:36 -0800 (PST)
In-Reply-To: <4cdd95a441484755ae46dac0deb43b70@BRMWP-EXMB11.corp.brocade.com>
References: <4cdd95a441484755ae46dac0deb43b70@BRMWP-EXMB11.corp.brocade.com>
Date: Mon, 24 Nov 2014 11:56:36 +0000
X-Google-Sender-Auth: SI9bvw--2iMw8QxE4fZQmVO-9uY
Message-ID: <CAFLBxZbY2gos30xXBS3h8-oWe9dFzTrcC3ToA7D5MfJwNHn3nw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Suhani Gupta <suhani@brocade.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Virtio disk type for xen VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 9:13 PM, Suhani Gupta <suhani@brocade.com> wrote:
> Hi,
>
>
>
> I want to assign virtio disk bus type to a VM in Xenserver. How to do it?

This list is for development of the XenProject.  XenServer is a
product based on Xen, but it differs significantly.  Please ask this
question on one of the XenServer support channels.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:56:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:56:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XssFy-0002Hk-OP; Mon, 24 Nov 2014 11:56:38 +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 1XssFx-0002Hf-UW
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 11:56:38 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	49/DE-24124-5FC13745; Mon, 24 Nov 2014 11:56:37 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416830196!13049522!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8494 invoked from network); 24 Nov 2014 11:56:36 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 11:56:36 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so5414545wiv.0
	for <xen-devel@lists.xenproject.org>;
	Mon, 24 Nov 2014 03:56:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=cFs3kcGQ3LeMoHNG4vz0adCkUtjUYLXd9FrIQk1/H3c=;
	b=WD3S0g6PFwOqgiyG3IlLkGkN/oSNNuHgHKj/hIZB2yNlbepBuhxAVgjRUPbTaewzmP
	4y9+IWhxKxLtV6frqXfgrggjJwfovKU9/S/2IOsZgkt6YVZnTGUDU+RToRc4/elnOnAk
	4hgRsRLWrZoy7XZ4SRcr6rJniG1ixwOC7PQQ+6nCBexU/jj1B2Rvwi6e8MqDYWEyJ3w8
	cOkhuLfWkcEQMeMudtfvDb66lj6b3miY2TOOf5JHJgh0YRsgUEOZDSRyiK/7HjVxrhuF
	XpShW6vVhxKKYklxtJQRMx0XTI1NcdMu0MBCRMUamtM14o0YCknXJaWBbIiw74DQVxiH
	9GZg==
MIME-Version: 1.0
X-Received: by 10.180.81.134 with SMTP id a6mr20481508wiy.11.1416830196094;
	Mon, 24 Nov 2014 03:56:36 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 24 Nov 2014 03:56:36 -0800 (PST)
In-Reply-To: <4cdd95a441484755ae46dac0deb43b70@BRMWP-EXMB11.corp.brocade.com>
References: <4cdd95a441484755ae46dac0deb43b70@BRMWP-EXMB11.corp.brocade.com>
Date: Mon, 24 Nov 2014 11:56:36 +0000
X-Google-Sender-Auth: SI9bvw--2iMw8QxE4fZQmVO-9uY
Message-ID: <CAFLBxZbY2gos30xXBS3h8-oWe9dFzTrcC3ToA7D5MfJwNHn3nw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Suhani Gupta <suhani@brocade.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Virtio disk type for xen VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 21, 2014 at 9:13 PM, Suhani Gupta <suhani@brocade.com> wrote:
> Hi,
>
>
>
> I want to assign virtio disk bus type to a VM in Xenserver. How to do it?

This list is for development of the XenProject.  XenServer is a
product based on Xen, but it differs significantly.  Please ask this
question on one of the XenServer support channels.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:58:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:58:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XssHK-0002MU-6l; Mon, 24 Nov 2014 11:58:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XssHI-0002MP-Lv
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 11:58:00 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	50/34-27623-74D13745; Mon, 24 Nov 2014 11:57:59 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416830277!13338899!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30168 invoked from network); 24 Nov 2014 11:57:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 11:57:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195195543"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 06:57:17 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XssGb-0005kb-D8;
	Mon, 24 Nov 2014 11:57:17 +0000
Date: Mon, 24 Nov 2014 11:57:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141121172652.GF8314@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411241157020.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
	<20141121172652.GF8314@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] small swiotlb-xen fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 05:00:05PM +0000, Stefano Stabellini wrote:
> > Hi all,
> > I have a couple of small straightforward fixes for swiotlb-xen for 3.19.
> > 
> 
> They look fine to me.

Applied to devel/for-linus-3.19



> Thanks.
> > Cheers,
> > 
> > Stefano
> > 
> > 
> > Stefano Stabellini (2):
> >       swiotlb-xen: call xen_dma_sync_single_for_device when appropriate
> >       swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single
> > 
> >  drivers/xen/swiotlb-xen.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 11:58:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 11:58:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XssHK-0002MU-6l; Mon, 24 Nov 2014 11:58:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XssHI-0002MP-Lv
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 11:58:00 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	50/34-27623-74D13745; Mon, 24 Nov 2014 11:57:59 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1416830277!13338899!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30168 invoked from network); 24 Nov 2014 11:57:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 11:57:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195195543"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 06:57:17 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XssGb-0005kb-D8;
	Mon, 24 Nov 2014 11:57:17 +0000
Date: Mon, 24 Nov 2014 11:57:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141121172652.GF8314@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411241157020.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411211657430.2675@kaball.uk.xensource.com>
	<20141121172652.GF8314@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] small swiotlb-xen fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 05:00:05PM +0000, Stefano Stabellini wrote:
> > Hi all,
> > I have a couple of small straightforward fixes for swiotlb-xen for 3.19.
> > 
> 
> They look fine to me.

Applied to devel/for-linus-3.19



> Thanks.
> > Cheers,
> > 
> > Stefano
> > 
> > 
> > Stefano Stabellini (2):
> >       swiotlb-xen: call xen_dma_sync_single_for_device when appropriate
> >       swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single
> > 
> >  drivers/xen/swiotlb-xen.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:07:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XssQ7-0002kN-PR; Mon, 24 Nov 2014 12:07:07 +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 1XssQ6-0002kF-TG
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 12:07:07 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	44/41-19763-A6F13745; Mon, 24 Nov 2014 12:07:06 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416830825!12988746!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23870 invoked from network); 24 Nov 2014 12:07:05 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 12:07:05 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOC6YuA017593;
	Mon, 24 Nov 2014 12:06:38 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOC6Qvs001354
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 12:06:26 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.5+Sun/8.11.1) with ESMTP id sAOC6QIN001634;
	Mon, 24 Nov 2014 12:06:26 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.5+Sun/8.14.5/Submit) with ESMTP id
	sAOC6QNt001631; Mon, 24 Nov 2014 12:06:26 GMT
Date: Mon, 24 Nov 2014 12:06:25 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
Message-ID: <alpine.GSO.2.00.1411241203280.1328@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.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: sAOC6YuA017593
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <Wei.Liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Mon, 24 Nov 2014, George Dunlap wrote:

> On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
>> On Sat, 22 Nov 2014, M A Young wrote:
>>
>>> While investigating a bug reported on Red Hat Bugzilla
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>> I discovered the following
>>>
>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>>> are actually two issues here
>>>
>>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>>> presumably because the allocated memory eventually runs out
>>
>>
>> I have found a bit more out about this. The segfault at at line 1378 of
>> tools/libxc/xc_domain_restore.c which is
>>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>>                         csum_page(buf));
>> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
>> array. This occurs in the verification phase.
>>
>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>> migration still fails. The first attached file contains the log from a run
>>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>>> stripped out to make the size manageable).
>>
>>
>> The difference actually seems to be down to how active the VM is rather than
>> the memory size (my small memory test system was doing very little, my
>> larger system was a full OS install). In the non-segfault case the problem
>> was the printf and printf_info commands in the create_domain() routine in
>> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
>> back from the restoring dom0, these commands cause an unexpected message. If
>> you move them onto stderr then the migration completes in the non-segfault
>> case.
>
> Good job tracking those down -- are there patches in the works?

I have a partial patch for the printf printf_info problem, which works for 
me but doesn't cover printing the info in sxp format. I haven't worked out 
what is leading up to the segfault yet.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:07:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XssQ7-0002kN-PR; Mon, 24 Nov 2014 12:07:07 +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 1XssQ6-0002kF-TG
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 12:07:07 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	44/41-19763-A6F13745; Mon, 24 Nov 2014 12:07:06 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416830825!12988746!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23870 invoked from network); 24 Nov 2014 12:07:05 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 12:07:05 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOC6YuA017593;
	Mon, 24 Nov 2014 12:06:38 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOC6Qvs001354
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 12:06:26 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.5+Sun/8.11.1) with ESMTP id sAOC6QIN001634;
	Mon, 24 Nov 2014 12:06:26 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.5+Sun/8.14.5/Submit) with ESMTP id
	sAOC6QNt001631; Mon, 24 Nov 2014 12:06:26 GMT
Date: Mon, 24 Nov 2014 12:06:25 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
Message-ID: <alpine.GSO.2.00.1411241203280.1328@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.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: sAOC6YuA017593
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <Wei.Liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Mon, 24 Nov 2014, George Dunlap wrote:

> On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
>> On Sat, 22 Nov 2014, M A Young wrote:
>>
>>> While investigating a bug reported on Red Hat Bugzilla
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>> I discovered the following
>>>
>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>>> are actually two issues here
>>>
>>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>>> presumably because the allocated memory eventually runs out
>>
>>
>> I have found a bit more out about this. The segfault at at line 1378 of
>> tools/libxc/xc_domain_restore.c which is
>>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>>                         csum_page(buf));
>> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
>> array. This occurs in the verification phase.
>>
>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>> migration still fails. The first attached file contains the log from a run
>>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>>> stripped out to make the size manageable).
>>
>>
>> The difference actually seems to be down to how active the VM is rather than
>> the memory size (my small memory test system was doing very little, my
>> larger system was a full OS install). In the non-segfault case the problem
>> was the printf and printf_info commands in the create_domain() routine in
>> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
>> back from the restoring dom0, these commands cause an unexpected message. If
>> you move them onto stderr then the migration completes in the non-segfault
>> case.
>
> Good job tracking those down -- are there patches in the works?

I have a partial patch for the printf printf_info problem, which works for 
me but doesn't cover printing the info in sxp format. I haven't worked out 
what is leading up to the segfault yet.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:07:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:07:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XssQg-0002mR-5l; Mon, 24 Nov 2014 12:07:42 +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 1XssQf-0002mK-6b
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 12:07:41 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	9B/2F-02954-C8F13745; Mon, 24 Nov 2014 12:07:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416830859!14434437!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27922 invoked from network); 24 Nov 2014 12:07:40 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:07:40 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so5375640wiv.17
	for <xen-devel@lists.xenproject.org>;
	Mon, 24 Nov 2014 04:07:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=ct+Khvi7JQhRHzVfODMSzNvOYt5WebAL0euvpnr2NSU=;
	b=dL6lw4IPFXWXp5zZrGpmthfWJO5gYOalofp9PPuQbgzSuQZ/N2zrzre47GPs2GqZlQ
	WkkJUekMOfd0RkGrJv6nPAIsD9HYshgzpaySAamvJwqnNvq/sK2WDFindxx6UkVplj46
	LGmg+Im7mrDyxpv74EOeDsvIuGv5toxtZ8f5H8ssrKXfk6mdbRhKesiWnd+Rb9JlhOqP
	4G/avx9eD55n6JibDzkrb6wCjd3USRd1qgcvBi7Lef7x8XpqbrBVjcJCAj7CZwfIFsne
	9pO5EDMfEXRV5+8xtibYRNSzg5kXfkyD58N8WPyCEl8UfWURtTLd7XRjSNUP5H6pl8s/
	Naeg==
MIME-Version: 1.0
X-Received: by 10.180.103.6 with SMTP id fs6mr5113137wib.11.1416830859494;
	Mon, 24 Nov 2014 04:07:39 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 24 Nov 2014 04:07:39 -0800 (PST)
In-Reply-To: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
References: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
Date: Mon, 24 Nov 2014 12:07:39 +0000
X-Google-Sender-Auth: CMeFvzPB4WCHjWHPxQC41egedJQ
Message-ID: <CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: aragrawal <aragrawal@cs.wisc.edu>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 3:54 AM, aragrawal <aragrawal@cs.wisc.edu> wrote:
> Hi
>
> I am interested in getting the block I/O rate fixed for a Virtual Machine.
> However, it seems that there are no such options to control the block I/O
> rate via the VM configuration file.
> Going through the net, I see suggestions to configure the xen_blkback driver
> using ionice to get that done.
>
> I would like to know if there are any plans to include any such
> configuration option.
> Also, are there any particular reason (apart from the fact that there are
> other ways to get this done) for the absence of such configuration option?

I'm pretty sure it's just because nobody had asked for it yet.

We can put it on our list of things to think about doing / projects
for people new to the community.

We also accept patches. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:07:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:07:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XssQg-0002mR-5l; Mon, 24 Nov 2014 12:07:42 +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 1XssQf-0002mK-6b
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 12:07:41 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	9B/2F-02954-C8F13745; Mon, 24 Nov 2014 12:07:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1416830859!14434437!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27922 invoked from network); 24 Nov 2014 12:07:40 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:07:40 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so5375640wiv.17
	for <xen-devel@lists.xenproject.org>;
	Mon, 24 Nov 2014 04:07:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=ct+Khvi7JQhRHzVfODMSzNvOYt5WebAL0euvpnr2NSU=;
	b=dL6lw4IPFXWXp5zZrGpmthfWJO5gYOalofp9PPuQbgzSuQZ/N2zrzre47GPs2GqZlQ
	WkkJUekMOfd0RkGrJv6nPAIsD9HYshgzpaySAamvJwqnNvq/sK2WDFindxx6UkVplj46
	LGmg+Im7mrDyxpv74EOeDsvIuGv5toxtZ8f5H8ssrKXfk6mdbRhKesiWnd+Rb9JlhOqP
	4G/avx9eD55n6JibDzkrb6wCjd3USRd1qgcvBi7Lef7x8XpqbrBVjcJCAj7CZwfIFsne
	9pO5EDMfEXRV5+8xtibYRNSzg5kXfkyD58N8WPyCEl8UfWURtTLd7XRjSNUP5H6pl8s/
	Naeg==
MIME-Version: 1.0
X-Received: by 10.180.103.6 with SMTP id fs6mr5113137wib.11.1416830859494;
	Mon, 24 Nov 2014 04:07:39 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 24 Nov 2014 04:07:39 -0800 (PST)
In-Reply-To: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
References: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
Date: Mon, 24 Nov 2014 12:07:39 +0000
X-Google-Sender-Auth: CMeFvzPB4WCHjWHPxQC41egedJQ
Message-ID: <CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: aragrawal <aragrawal@cs.wisc.edu>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 3:54 AM, aragrawal <aragrawal@cs.wisc.edu> wrote:
> Hi
>
> I am interested in getting the block I/O rate fixed for a Virtual Machine.
> However, it seems that there are no such options to control the block I/O
> rate via the VM configuration file.
> Going through the net, I see suggestions to configure the xen_blkback driver
> using ionice to get that done.
>
> I would like to know if there are any plans to include any such
> configuration option.
> Also, are there any particular reason (apart from the fact that there are
> other ways to get this done) for the absence of such configuration option?

I'm pretty sure it's just because nobody had asked for it yet.

We can put it on our list of things to think about doing / projects
for people new to the community.

We also accept patches. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:17:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xssa9-00037V-Nq; Mon, 24 Nov 2014 12:17:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xssa7-00037Q-Kg
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 12:17:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B6/7B-25276-6D123745; Mon, 24 Nov 2014 12:17:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416831444!14549275!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13889 invoked from network); 24 Nov 2014 12:17:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:17:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196034419"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 07:17:15 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XssZu-0006GO-Uu;
	Mon, 24 Nov 2014 12:17:14 +0000
Date: Mon, 24 Nov 2014 12:17:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141121190757.GA16038@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
References: <1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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 Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > > > The rom is used for pxebooting. We don't need to allow pxebooting from
> > > > more than one network card.  Loading a romfile for every NIC wastes
> > > 
> > > Why not? Why can't we PXE boot from each network card?
> > 
> > I take it back: you are right, at the moment it is actually possible to
> > pxe boot from the fourth nic for example. Maybe we could just load the
> > first four romfiles and skip the others (four is the limit before QEMU
> > fails to allocate any more memory).
> 
> The limit is in the count of ROMs or the memory consumption?

The limit is memory consumption.


> What if you also do PCI passthrough? Does that figure in this calculation?

In the case of PCI passthrough, roms are remapped, so they shouldn't
affect memory consumption.

 
> > TBH not all the emulated nics need a romfile but I wouldn't want to go
> > down at that level of details beause they become QEMU implementation
> > details. I wouldn't want to tie libxl to a certain version of QEMU in
> > any way.
> > 
> > A better way would be handling memory allocation errors in QEMU but QEMU
> > doesn't do that at the moment and the change there would be certainly
> > more invasive that a couple of lines in libxl.
> > 
> > 
> > > > memory and as a matter of fact breaks configurations with more than 4
> > > > NICs as QEMU fails to allocate memory on behalf of the guest.
> > > 
> > > What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> > > and ne2k ?
> > > 
> > > Don't you want to load the ROM for each one?
> > 
> > The rom cannot be reused in QEMU among multiple instances of the same
> > nic, so having four different types of nics or just one type doesn't
> > change anything.
> > 
> > 
> > > > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > > > guest.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > 
> > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > index 3e191c3..f907ca9 100644
> > > > --- a/tools/libxl/libxl_dm.c
> > > > +++ b/tools/libxl/libxl_dm.c
> > > > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> > > >                  flexarray_append(dm_args, "-device");
> > > >                  flexarray_append(dm_args,
> > > > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > > > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> > > >                                                  nics[i].model, nics[i].devid,
> > > > -                                                nics[i].devid, smac));
> > > > +                                                nics[i].devid, smac,
> > > > +                                                i ? ",romfile=\"\"" : ""));
> > > >                  flexarray_append(dm_args, "-netdev");
> > > >                  flexarray_append(dm_args, GCSPRINTF(
> > > >                                            "type=tap,id=net%d,ifname=%s,"
> > > > 
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org
> > > > http://lists.xen.org/xen-devel
> > > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:17:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xssa9-00037V-Nq; Mon, 24 Nov 2014 12:17:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xssa7-00037Q-Kg
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 12:17:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B6/7B-25276-6D123745; Mon, 24 Nov 2014 12:17:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416831444!14549275!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13889 invoked from network); 24 Nov 2014 12:17:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:17:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196034419"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 07:17:15 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XssZu-0006GO-Uu;
	Mon, 24 Nov 2014 12:17:14 +0000
Date: Mon, 24 Nov 2014 12:17:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141121190757.GA16038@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
References: <1416217990.27385.10.camel@citrix.com>
	<alpine.DEB.2.02.1411171237340.26318@kaball.uk.xensource.com>
	<1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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 Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > > > The rom is used for pxebooting. We don't need to allow pxebooting from
> > > > more than one network card.  Loading a romfile for every NIC wastes
> > > 
> > > Why not? Why can't we PXE boot from each network card?
> > 
> > I take it back: you are right, at the moment it is actually possible to
> > pxe boot from the fourth nic for example. Maybe we could just load the
> > first four romfiles and skip the others (four is the limit before QEMU
> > fails to allocate any more memory).
> 
> The limit is in the count of ROMs or the memory consumption?

The limit is memory consumption.


> What if you also do PCI passthrough? Does that figure in this calculation?

In the case of PCI passthrough, roms are remapped, so they shouldn't
affect memory consumption.

 
> > TBH not all the emulated nics need a romfile but I wouldn't want to go
> > down at that level of details beause they become QEMU implementation
> > details. I wouldn't want to tie libxl to a certain version of QEMU in
> > any way.
> > 
> > A better way would be handling memory allocation errors in QEMU but QEMU
> > doesn't do that at the moment and the change there would be certainly
> > more invasive that a couple of lines in libxl.
> > 
> > 
> > > > memory and as a matter of fact breaks configurations with more than 4
> > > > NICs as QEMU fails to allocate memory on behalf of the guest.
> > > 
> > > What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> > > and ne2k ?
> > > 
> > > Don't you want to load the ROM for each one?
> > 
> > The rom cannot be reused in QEMU among multiple instances of the same
> > nic, so having four different types of nics or just one type doesn't
> > change anything.
> > 
> > 
> > > > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > > > guest.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > 
> > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > index 3e191c3..f907ca9 100644
> > > > --- a/tools/libxl/libxl_dm.c
> > > > +++ b/tools/libxl/libxl_dm.c
> > > > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> > > >                  flexarray_append(dm_args, "-device");
> > > >                  flexarray_append(dm_args,
> > > > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > > > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> > > >                                                  nics[i].model, nics[i].devid,
> > > > -                                                nics[i].devid, smac));
> > > > +                                                nics[i].devid, smac,
> > > > +                                                i ? ",romfile=\"\"" : ""));
> > > >                  flexarray_append(dm_args, "-netdev");
> > > >                  flexarray_append(dm_args, GCSPRINTF(
> > > >                                            "type=tap,id=net%d,ifname=%s,"
> > > > 
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org
> > > > http://lists.xen.org/xen-devel
> > > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:22:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsseX-0003Jq-En; Mon, 24 Nov 2014 12:22:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsseV-0003JY-V5
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 12:22:00 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	C2/03-02576-7E223745; Mon, 24 Nov 2014 12:21:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416831716!14419556!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7355 invoked from network); 24 Nov 2014 12:21:58 -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;
	24 Nov 2014 12:21:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196035463"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 07:21:55 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsseR-0003ls-Dc;
	Mon, 24 Nov 2014 12:21:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsseR-0002BB-73;
	Mon, 24 Nov 2014 12:21:55 +0000
Date: Mon, 24 Nov 2014 12:21:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31827-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31827: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31827 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31827/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 31680

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              42874fa45f9fab99212d0ba3f66cf4671ddb0a30
baseline version:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad

------------------------------------------------------------
People who touched revisions under test:
  Anirban Chakraborty <abchak@juniper.net>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Giuseppe Scrivano <gscrivan@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nehal J Wani <nehaljw.kkd1@gmail.com>
  Peter Krempa <pkrempa@redhat.com>
  Yohan BELLEGUIC <yohan.belleguic@diateam.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 704 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 Nov 24 12:22:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsseX-0003Jq-En; Mon, 24 Nov 2014 12:22:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XsseV-0003JY-V5
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 12:22:00 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	C2/03-02576-7E223745; Mon, 24 Nov 2014 12:21:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416831716!14419556!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7355 invoked from network); 24 Nov 2014 12:21:58 -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;
	24 Nov 2014 12:21:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196035463"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 07:21:55 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsseR-0003ls-Dc;
	Mon, 24 Nov 2014 12:21:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsseR-0002BB-73;
	Mon, 24 Nov 2014 12:21:55 +0000
Date: Mon, 24 Nov 2014 12:21:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31827-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31827: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31827 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31827/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 31680

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              42874fa45f9fab99212d0ba3f66cf4671ddb0a30
baseline version:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad

------------------------------------------------------------
People who touched revisions under test:
  Anirban Chakraborty <abchak@juniper.net>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Giuseppe Scrivano <gscrivan@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nehal J Wani <nehaljw.kkd1@gmail.com>
  Peter Krempa <pkrempa@redhat.com>
  Yohan BELLEGUIC <yohan.belleguic@diateam.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 704 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 Nov 24 12:22:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsseZ-0003KX-QW; Mon, 24 Nov 2014 12:22:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XsseY-0003Jy-7p
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 12:22:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	44/04-25276-9E223745; Mon, 24 Nov 2014 12:22:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416831720!14825956!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19634 invoked from network); 24 Nov 2014 12:22:01 -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;
	24 Nov 2014 12:22:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195206072"
Message-ID: <1416831682.8878.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Mon, 24 Nov 2014 12:21:22 +0000
In-Reply-To: <alpine.GSO.2.00.1411241203280.1328@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<alpine.GSO.2.00.1411241203280.1328@algedi.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-24 at 12:06 +0000, M A Young wrote:
> 
> On Mon, 24 Nov 2014, George Dunlap wrote:
> 
> > On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
> >> On Sat, 22 Nov 2014, M A Young wrote:
> >>
> >>> While investigating a bug reported on Red Hat Bugzilla
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
> >>> I discovered the following
> >>>
> >>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
> >>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
> >>> are actually two issues here
> >>>
> >>> * the segfault in libxl-save-helper --restore-domain (as reported in the
> >>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
> >>> presumably because the allocated memory eventually runs out
> >>
> >>
> >> I have found a bit more out about this. The segfault at at line 1378 of
> >> tools/libxc/xc_domain_restore.c which is
> >>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
> >>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
> >>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
> >>                         csum_page(buf));
> >> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
> >> array. This occurs in the verification phase.
> >>
> >>> * the segfault doesn't occur if the guest memory is 128M, but the
> >>> migration still fails. The first attached file contains the log from a run
> >>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
> >>> stripped out to make the size manageable).
> >>
> >>
> >> The difference actually seems to be down to how active the VM is rather than
> >> the memory size (my small memory test system was doing very little, my
> >> larger system was a full OS install). In the non-segfault case the problem
> >> was the printf and printf_info commands in the create_domain() routine in
> >> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
> >> back from the restoring dom0, these commands cause an unexpected message. If
> >> you move them onto stderr then the migration completes in the non-segfault
> >> case.
> >
> > Good job tracking those down -- are there patches in the works?
> 
> I have a partial patch for the printf printf_info problem, which works for 
> me but doesn't cover printing the info in sxp format.

Am I right that is all related to the use of --debug and or -vm? and
that a plain "xl migrate" works ok?

It's still a bug of course, but changes the severity (somehow, not sure
to what extent IMHO it does etc).

>  I haven't worked out 
> what is leading up to the segfault yet.
> 
>  	Michael Young



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:22:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsseZ-0003KX-QW; Mon, 24 Nov 2014 12:22:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XsseY-0003Jy-7p
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 12:22:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	44/04-25276-9E223745; Mon, 24 Nov 2014 12:22:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416831720!14825956!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19634 invoked from network); 24 Nov 2014 12:22:01 -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;
	24 Nov 2014 12:22:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195206072"
Message-ID: <1416831682.8878.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Mon, 24 Nov 2014 12:21:22 +0000
In-Reply-To: <alpine.GSO.2.00.1411241203280.1328@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<alpine.GSO.2.00.1411241203280.1328@algedi.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-24 at 12:06 +0000, M A Young wrote:
> 
> On Mon, 24 Nov 2014, George Dunlap wrote:
> 
> > On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
> >> On Sat, 22 Nov 2014, M A Young wrote:
> >>
> >>> While investigating a bug reported on Red Hat Bugzilla
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
> >>> I discovered the following
> >>>
> >>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
> >>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
> >>> are actually two issues here
> >>>
> >>> * the segfault in libxl-save-helper --restore-domain (as reported in the
> >>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
> >>> presumably because the allocated memory eventually runs out
> >>
> >>
> >> I have found a bit more out about this. The segfault at at line 1378 of
> >> tools/libxc/xc_domain_restore.c which is
> >>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
> >>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
> >>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
> >>                         csum_page(buf));
> >> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
> >> array. This occurs in the verification phase.
> >>
> >>> * the segfault doesn't occur if the guest memory is 128M, but the
> >>> migration still fails. The first attached file contains the log from a run
> >>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
> >>> stripped out to make the size manageable).
> >>
> >>
> >> The difference actually seems to be down to how active the VM is rather than
> >> the memory size (my small memory test system was doing very little, my
> >> larger system was a full OS install). In the non-segfault case the problem
> >> was the printf and printf_info commands in the create_domain() routine in
> >> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
> >> back from the restoring dom0, these commands cause an unexpected message. If
> >> you move them onto stderr then the migration completes in the non-segfault
> >> case.
> >
> > Good job tracking those down -- are there patches in the works?
> 
> I have a partial patch for the printf printf_info problem, which works for 
> me but doesn't cover printing the info in sxp format.

Am I right that is all related to the use of --debug and or -vm? and
that a plain "xl migrate" works ok?

It's still a bug of course, but changes the severity (somehow, not sure
to what extent IMHO it does etc).

>  I haven't worked out 
> what is leading up to the segfault yet.
> 
>  	Michael Young



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:25:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12: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 1Xssi4-0003Z6-G7; Mon, 24 Nov 2014 12:25:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xssi2-0003Yz-Jv
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 12:25:38 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	52/7D-02953-1C323745; Mon, 24 Nov 2014 12:25:37 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416831937!9805725!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25394 invoked from network); 24 Nov 2014 12:25:37 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:25:37 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so12175186wgh.12
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 04:25:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=vyQWLQLLdoe0WL7DoO7ADl1tLPICjW+ywzK/xL2gRjY=;
	b=BnhcJQ/org64Q1xypkrPlYWim2dV4Liu1bSyFwS+1ADl3yeiHgO/h4ZF54Z24r8FTL
	lQnMWxuiskGuuLfX+NYaAdAnteqqvbtVt31S/jqVxfuBTODI4Zj/d+jIWfMrO2JQgo3I
	7KfMH2QaPTpPYEx2ov18FtvSuQZN+xMdUjfNxKmXJTIb/hth8oXmDyJDCA6nNsUBn8O0
	he0P5QkO+JgLU25ux6TZ2DiwzRnkW/MilWZ+5jkTvQMdR/hbMlB5Tm1Wb237451WhhEJ
	ZXmwbbYXqDlMLuXiUg65TWIgqEmxWXaI8NCgcX9wJ0Oo40TQ6ujaaWs3hvoaWI9e2Gyk
	jYuw==
MIME-Version: 1.0
X-Received: by 10.180.103.6 with SMTP id fs6mr5255301wib.11.1416831937060;
	Mon, 24 Nov 2014 04:25:37 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 24 Nov 2014 04:25:37 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
Date: Mon, 24 Nov 2014 12:25:37 +0000
X-Google-Sender-Auth: XgJ_D4NUwVQRzDCxrQBiXv9XApc
Message-ID: <CAFLBxZZD8mufgkWBcF9F8RMhqXconf7VzeuCJOXumh4mJQjJCQ@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: M A Young <m.a.young@durham.ac.uk>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Nov 22, 2014 at 7:24 PM, M A Young <m.a.young@durham.ac.uk> wrote:
> While investigating a bug reported on Red Hat Bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
> I discovered the following
>
> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the bug
> report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There are
> actually two issues here
>
> * the segfault in libxl-save-helper --restore-domain (as reported in the bug
> above) occurs if the guest memory is 1024M (on my 4G box) and is presumably
> because the allocated memory eventually runs out
>
> * the segfault doesn't occur if the guest memory is 128M, but the migration
> still fails. The first attached file contains the log from a run with xl -v
> migrate --debug domid localhost (with mfn and duplicated lines stripped out
> to make the size manageable).
>
> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
> migrate doesn't work for me at all - see the second attached file for the
> output of xl -v migrate domid localhost .

Could you resend this as a separate message so we can debug it separately?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:25:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12: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 1Xssi4-0003Z6-G7; Mon, 24 Nov 2014 12:25:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xssi2-0003Yz-Jv
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 12:25:38 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	52/7D-02953-1C323745; Mon, 24 Nov 2014 12:25:37 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416831937!9805725!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25394 invoked from network); 24 Nov 2014 12:25:37 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:25:37 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so12175186wgh.12
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 04:25:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=vyQWLQLLdoe0WL7DoO7ADl1tLPICjW+ywzK/xL2gRjY=;
	b=BnhcJQ/org64Q1xypkrPlYWim2dV4Liu1bSyFwS+1ADl3yeiHgO/h4ZF54Z24r8FTL
	lQnMWxuiskGuuLfX+NYaAdAnteqqvbtVt31S/jqVxfuBTODI4Zj/d+jIWfMrO2JQgo3I
	7KfMH2QaPTpPYEx2ov18FtvSuQZN+xMdUjfNxKmXJTIb/hth8oXmDyJDCA6nNsUBn8O0
	he0P5QkO+JgLU25ux6TZ2DiwzRnkW/MilWZ+5jkTvQMdR/hbMlB5Tm1Wb237451WhhEJ
	ZXmwbbYXqDlMLuXiUg65TWIgqEmxWXaI8NCgcX9wJ0Oo40TQ6ujaaWs3hvoaWI9e2Gyk
	jYuw==
MIME-Version: 1.0
X-Received: by 10.180.103.6 with SMTP id fs6mr5255301wib.11.1416831937060;
	Mon, 24 Nov 2014 04:25:37 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 24 Nov 2014 04:25:37 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
Date: Mon, 24 Nov 2014 12:25:37 +0000
X-Google-Sender-Auth: XgJ_D4NUwVQRzDCxrQBiXv9XApc
Message-ID: <CAFLBxZZD8mufgkWBcF9F8RMhqXconf7VzeuCJOXumh4mJQjJCQ@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: M A Young <m.a.young@durham.ac.uk>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Nov 22, 2014 at 7:24 PM, M A Young <m.a.young@durham.ac.uk> wrote:
> While investigating a bug reported on Red Hat Bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
> I discovered the following
>
> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the bug
> report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There are
> actually two issues here
>
> * the segfault in libxl-save-helper --restore-domain (as reported in the bug
> above) occurs if the guest memory is 1024M (on my 4G box) and is presumably
> because the allocated memory eventually runs out
>
> * the segfault doesn't occur if the guest memory is 128M, but the migration
> still fails. The first attached file contains the log from a run with xl -v
> migrate --debug domid localhost (with mfn and duplicated lines stripped out
> to make the size manageable).
>
> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
> migrate doesn't work for me at all - see the second attached file for the
> output of xl -v migrate domid localhost .

Could you resend this as a separate message so we can debug it separately?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:29:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xssm6-0003jV-Aq; Mon, 24 Nov 2014 12:29:50 +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 1Xssm5-0003jQ-KK
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 12:29:49 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	2C/9F-22777-CB423745; Mon, 24 Nov 2014 12:29:48 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416832187!13033637!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25356 invoked from network); 24 Nov 2014 12:29:48 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 12:29:48 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOCTWX8019037;
	Mon, 24 Nov 2014 12:29:36 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOCTQdm005107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 12:29:26 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.5+Sun/8.11.1) with ESMTP id sAOCTPt5001703;
	Mon, 24 Nov 2014 12:29:25 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.5+Sun/8.14.5/Submit) with ESMTP id
	sAOCTPoE001700; Mon, 24 Nov 2014 12:29:25 GMT
Date: Mon, 24 Nov 2014 12:29:25 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416831682.8878.1.camel@citrix.com>
Message-ID: <alpine.GSO.2.00.1411241226470.1328@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<alpine.GSO.2.00.1411241203280.1328@algedi.dur.ac.uk>
	<1416831682.8878.1.camel@citrix.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAOCTWX8019037
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Mon, 24 Nov 2014, Ian Campbell wrote:

> On Mon, 2014-11-24 at 12:06 +0000, M A Young wrote:
>>
>> On Mon, 24 Nov 2014, George Dunlap wrote:
>>
>>> On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
>>>> On Sat, 22 Nov 2014, M A Young wrote:
>>>>
>>>>> While investigating a bug reported on Red Hat Bugzilla
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>>> I discovered the following
>>>>>
>>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>>>>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>>>>> are actually two issues here
>>>>>
>>>>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>>>>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>>> presumably because the allocated memory eventually runs out
>>>>
>>>>
>>>> I have found a bit more out about this. The segfault at at line 1378 of
>>>> tools/libxc/xc_domain_restore.c which is
>>>>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>>>>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>>>>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>>>>                         csum_page(buf));
>>>> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
>>>> array. This occurs in the verification phase.
>>>>
>>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>>> migration still fails. The first attached file contains the log from a run
>>>>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>>>>> stripped out to make the size manageable).
>>>>
>>>>
>>>> The difference actually seems to be down to how active the VM is rather than
>>>> the memory size (my small memory test system was doing very little, my
>>>> larger system was a full OS install). In the non-segfault case the problem
>>>> was the printf and printf_info commands in the create_domain() routine in
>>>> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
>>>> back from the restoring dom0, these commands cause an unexpected message. If
>>>> you move them onto stderr then the migration completes in the non-segfault
>>>> case.
>>>
>>> Good job tracking those down -- are there patches in the works?
>>
>> I have a partial patch for the printf printf_info problem, which works for
>> me but doesn't cover printing the info in sxp format.
>
> Am I right that is all related to the use of --debug and or -vm? and
> that a plain "xl migrate" works ok?
>
> It's still a bug of course, but changes the severity (somehow, not sure
> to what extent IMHO it does etc).

A plain xl migrate does work on 4.4. I didn't get xl migrate working on 
4.5-rc1 but was waiting for rc3 before trying to debug that.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:29:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xssm6-0003jV-Aq; Mon, 24 Nov 2014 12:29:50 +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 1Xssm5-0003jQ-KK
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 12:29:49 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	2C/9F-22777-CB423745; Mon, 24 Nov 2014 12:29:48 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416832187!13033637!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25356 invoked from network); 24 Nov 2014 12:29:48 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 12:29:48 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOCTWX8019037;
	Mon, 24 Nov 2014 12:29:36 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOCTQdm005107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 12:29:26 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.5+Sun/8.11.1) with ESMTP id sAOCTPt5001703;
	Mon, 24 Nov 2014 12:29:25 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.5+Sun/8.14.5/Submit) with ESMTP id
	sAOCTPoE001700; Mon, 24 Nov 2014 12:29:25 GMT
Date: Mon, 24 Nov 2014 12:29:25 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416831682.8878.1.camel@citrix.com>
Message-ID: <alpine.GSO.2.00.1411241226470.1328@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<alpine.GSO.2.00.1411241203280.1328@algedi.dur.ac.uk>
	<1416831682.8878.1.camel@citrix.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAOCTWX8019037
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <Wei.Liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Mon, 24 Nov 2014, Ian Campbell wrote:

> On Mon, 2014-11-24 at 12:06 +0000, M A Young wrote:
>>
>> On Mon, 24 Nov 2014, George Dunlap wrote:
>>
>>> On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
>>>> On Sat, 22 Nov 2014, M A Young wrote:
>>>>
>>>>> While investigating a bug reported on Red Hat Bugzilla
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>>> I discovered the following
>>>>>
>>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>>>>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>>>>> are actually two issues here
>>>>>
>>>>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>>>>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>>> presumably because the allocated memory eventually runs out
>>>>
>>>>
>>>> I have found a bit more out about this. The segfault at at line 1378 of
>>>> tools/libxc/xc_domain_restore.c which is
>>>>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>>>>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>>>>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>>>>                         csum_page(buf));
>>>> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
>>>> array. This occurs in the verification phase.
>>>>
>>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>>> migration still fails. The first attached file contains the log from a run
>>>>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>>>>> stripped out to make the size manageable).
>>>>
>>>>
>>>> The difference actually seems to be down to how active the VM is rather than
>>>> the memory size (my small memory test system was doing very little, my
>>>> larger system was a full OS install). In the non-segfault case the problem
>>>> was the printf and printf_info commands in the create_domain() routine in
>>>> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
>>>> back from the restoring dom0, these commands cause an unexpected message. If
>>>> you move them onto stderr then the migration completes in the non-segfault
>>>> case.
>>>
>>> Good job tracking those down -- are there patches in the works?
>>
>> I have a partial patch for the printf printf_info problem, which works for
>> me but doesn't cover printing the info in sxp format.
>
> Am I right that is all related to the use of --debug and or -vm? and
> that a plain "xl migrate" works ok?
>
> It's still a bug of course, but changes the severity (somehow, not sure
> to what extent IMHO it does etc).

A plain xl migrate does work on 4.4. I didn't get xl migrate working on 
4.5-rc1 but was waiting for rc3 before trying to debug that.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:33:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsspZ-0003vf-42; Mon, 24 Nov 2014 12:33: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@citrix.com>) id 1XsspX-0003vR-Vq
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 12:33:24 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	7E/5D-28865-39523745; Mon, 24 Nov 2014 12:33:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416832400!13059017!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18652 invoked from network); 24 Nov 2014 12:33:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:33:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196038777"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 07:33:19 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsspT-0003pY-F9;
	Mon, 24 Nov 2014 12:33:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsspT-0005lI-9J;
	Mon, 24 Nov 2014 12:33:19 +0000
Date: Mon, 24 Nov 2014 12:33:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31811-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31811: 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 31811 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31811/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
baseline version:
 xen                  d6281e354393f1c8a02fac55f4f611b4d4856303

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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.3-testing
+ revision=62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.3-testing 62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
+ branch=xen-4.3-testing
+ revision=62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.3-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.3-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.3-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git
++ : daily-cron.xen-4.3-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.3-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.3-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.3-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.3-testing
+ xenversion=xen-4.3
+ xenversion=4.3
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 62f1b78417f3a9afe8d40ee3c0d2f0495240cf47:stable-4.3
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   d6281e3..62f1b78  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47 -> stable-4.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:33:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsspZ-0003vf-42; Mon, 24 Nov 2014 12:33: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@citrix.com>) id 1XsspX-0003vR-Vq
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 12:33:24 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	7E/5D-28865-39523745; Mon, 24 Nov 2014 12:33:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416832400!13059017!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18652 invoked from network); 24 Nov 2014 12:33:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:33:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="196038777"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 07:33:19 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XsspT-0003pY-F9;
	Mon, 24 Nov 2014 12:33:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XsspT-0005lI-9J;
	Mon, 24 Nov 2014 12:33:19 +0000
Date: Mon, 24 Nov 2014 12:33:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31811-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31811: 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 31811 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31811/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
baseline version:
 xen                  d6281e354393f1c8a02fac55f4f611b4d4856303

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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.3-testing
+ revision=62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.3-testing 62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
+ branch=xen-4.3-testing
+ revision=62f1b78417f3a9afe8d40ee3c0d2f0495240cf47
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.3-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.3-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.3-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : daily-cron.xen-4.3-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git
++ : daily-cron.xen-4.3-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.3-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.3-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.3-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.3-testing
+ xenversion=xen-4.3
+ xenversion=4.3
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 62f1b78417f3a9afe8d40ee3c0d2f0495240cf47:stable-4.3
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   d6281e3..62f1b78  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47 -> stable-4.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:42:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:42:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xssxx-0004Ey-9t; Mon, 24 Nov 2014 12:42:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xssxv-0004Et-KW
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 12:42:03 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	13/64-02696-B9723745; Mon, 24 Nov 2014 12:42:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416832918!14441086!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27655 invoked from network); 24 Nov 2014 12:41:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:41:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195214695"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 07:41:43 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xssxb-0006jg-C0;
	Mon, 24 Nov 2014 12:41:43 +0000
Date: Mon, 24 Nov 2014 12:41:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141124124143.GA11483@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
> While investigating a bug reported on Red Hat Bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
> I discovered the following
> 
> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the bug
> report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There are
> actually two issues here
> 
> * the segfault in libxl-save-helper --restore-domain (as reported in the bug
> above) occurs if the guest memory is 1024M (on my 4G box) and is presumably
> because the allocated memory eventually runs out
> 
> * the segfault doesn't occur if the guest memory is 128M, but the migration
> still fails. The first attached file contains the log from a run with xl -v
> migrate --debug domid localhost (with mfn and duplicated lines stripped out
> to make the size manageable).
> 
> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
> migrate doesn't work for me at all - see the second attached file for the
> output of xl -v migrate domid localhost .
> 
> 	Mchael Young

[...]
> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s, dirtied 0Mb/s 314 pages
> xc: detail: Mapping order 0,  268; first pfn 3fcf4
> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied 0Mb/s 0 pages
> xc: detail: Start last iteration
> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND shinfo 00082fbc
> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied 1033Mb/s 536 pages
> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied 2195Mb/s 536 pages
> xc: detail: Total pages sent= 262749 (1.00x)
> xc: detail: (of which 0 were fixups)
> xc: detail: All memory is saved
> xc: error: Error querying maximum number of MSRs for VCPU0 (1 = Operation not permitted): Internal error

Per your description this is the output of "xl -v migrate domid
localhost", so no "--debug" is involved. (Just to make sure...)

This error message means a domctl fails, which should be addressed
first?

FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
for me. :-(

Is there anything I need to do to trigger this failure?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:42:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:42:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xssxx-0004Ey-9t; Mon, 24 Nov 2014 12:42:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xssxv-0004Et-KW
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 12:42:03 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	13/64-02696-B9723745; Mon, 24 Nov 2014 12:42:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416832918!14441086!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27655 invoked from network); 24 Nov 2014 12:41:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:41:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195214695"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 07:41:43 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xssxb-0006jg-C0;
	Mon, 24 Nov 2014 12:41:43 +0000
Date: Mon, 24 Nov 2014 12:41:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141124124143.GA11483@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
> While investigating a bug reported on Red Hat Bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
> I discovered the following
> 
> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the bug
> report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There are
> actually two issues here
> 
> * the segfault in libxl-save-helper --restore-domain (as reported in the bug
> above) occurs if the guest memory is 1024M (on my 4G box) and is presumably
> because the allocated memory eventually runs out
> 
> * the segfault doesn't occur if the guest memory is 128M, but the migration
> still fails. The first attached file contains the log from a run with xl -v
> migrate --debug domid localhost (with mfn and duplicated lines stripped out
> to make the size manageable).
> 
> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
> migrate doesn't work for me at all - see the second attached file for the
> output of xl -v migrate domid localhost .
> 
> 	Mchael Young

[...]
> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s, dirtied 0Mb/s 314 pages
> xc: detail: Mapping order 0,  268; first pfn 3fcf4
> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied 0Mb/s 0 pages
> xc: detail: Start last iteration
> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND shinfo 00082fbc
> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied 1033Mb/s 536 pages
> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied 2195Mb/s 536 pages
> xc: detail: Total pages sent= 262749 (1.00x)
> xc: detail: (of which 0 were fixups)
> xc: detail: All memory is saved
> xc: error: Error querying maximum number of MSRs for VCPU0 (1 = Operation not permitted): Internal error

Per your description this is the output of "xl -v migrate domid
localhost", so no "--debug" is involved. (Just to make sure...)

This error message means a domctl fails, which should be addressed
first?

FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
for me. :-(

Is there anything I need to do to trigger this failure?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:43:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:43:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsszJ-0004Je-OL; Mon, 24 Nov 2014 12:43:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XsszI-0004JX-PH
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 12:43:28 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	15/D7-09842-0F723745; Mon, 24 Nov 2014 12:43:28 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416833007!14557014!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29419 invoked from network); 24 Nov 2014 12:43:27 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:43:27 -0000
Received: by mail-wg0-f46.google.com with SMTP id x12so12057548wgg.19
	for <xen-devel@lists.xenproject.org>;
	Mon, 24 Nov 2014 04:43:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=dQpYXxzjuKbti12Pr+2XqK6rwY8JK05Q2B5ncCMX7WE=;
	b=n/G5D9Pm5LSb/IWbaWLl+GAN13bY9OI6ReHFBHz1G90km3fcgYpQsmuJa/Sk39MB1k
	E26oDDP6cSCJ1RAYx9HRlYeGHIo7wn4bY3Z3PDiq+8ssmttcwvfXjyOBC3lxdjRV8FeZ
	uwlgRk9YtBTr2dpLrnnmoEHS5Tv7fKpp8gBfexOkfb2wK+ck2TISTrs5opiBto7zWpvt
	Rj8TC2hx15h6eWUSdRnXj5n30v/r4sCsuX/hFZU17IaF+z3AFPSPcXJtNqAWAmczUjSA
	/LwpYwGvff9vV1sb4+OmZ6Z4WV9qXlcxLIadS12g3KUWxZGW38D/Ttpc5N8Ev1q71PDt
	dBYg==
MIME-Version: 1.0
X-Received: by 10.180.108.77 with SMTP id hi13mr21579729wib.73.1416833007251; 
	Mon, 24 Nov 2014 04:43:27 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 24 Nov 2014 04:43:27 -0800 (PST)
In-Reply-To: <546DCC9F02000078000493F4@smtp.nue.novell.com>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCC9F02000078000493F4@smtp.nue.novell.com>
Date: Mon, 24 Nov 2014 12:43:27 +0000
X-Google-Sender-Auth: gbp4xqFopBL3qBKYF_A6idadLvY
Message-ID: <CAFLBxZYeAZOgu_X++dNLzenrZaLFDwUdn8W-Ndf92cm5-5bKGA@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: don't ignore foreigndom input on
 various MMUEXT ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 10:12 AM, Jan Beulich <JBeulich@suse.com> wrote:
> Instead properly fail requests that shouldn't be issued on foreign
> domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
> operation to work that way.

I take it this is for 4.6?

I've looked through it and everything looks OK.

But I agree with Tim, that having so many different changes all at the
same time makes the patch hard to review.

In particular, I'd rather start with a patch to get rid of "okay"
entirely; then make MMUEXT_{CLEAR,COPY}_PAGE use foreingndom instead
of current; then have a patch which returns -EPERM for the other ones;
then a patch to get rid of spage in MMUEXT_[UN]MARK_SUPER.

Regarding MMUEXT_{CLEAR,COPY}_PAGE: This is effectively changing the
interface.  Are we sure there are no callers which just expect them to
work on current, and don't set foreigndom properly?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:43:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:43:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsszJ-0004Je-OL; Mon, 24 Nov 2014 12:43:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XsszI-0004JX-PH
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 12:43:28 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	15/D7-09842-0F723745; Mon, 24 Nov 2014 12:43:28 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416833007!14557014!1
X-Originating-IP: [74.125.82.46]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29419 invoked from network); 24 Nov 2014 12:43:27 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 12:43:27 -0000
Received: by mail-wg0-f46.google.com with SMTP id x12so12057548wgg.19
	for <xen-devel@lists.xenproject.org>;
	Mon, 24 Nov 2014 04:43:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=dQpYXxzjuKbti12Pr+2XqK6rwY8JK05Q2B5ncCMX7WE=;
	b=n/G5D9Pm5LSb/IWbaWLl+GAN13bY9OI6ReHFBHz1G90km3fcgYpQsmuJa/Sk39MB1k
	E26oDDP6cSCJ1RAYx9HRlYeGHIo7wn4bY3Z3PDiq+8ssmttcwvfXjyOBC3lxdjRV8FeZ
	uwlgRk9YtBTr2dpLrnnmoEHS5Tv7fKpp8gBfexOkfb2wK+ck2TISTrs5opiBto7zWpvt
	Rj8TC2hx15h6eWUSdRnXj5n30v/r4sCsuX/hFZU17IaF+z3AFPSPcXJtNqAWAmczUjSA
	/LwpYwGvff9vV1sb4+OmZ6Z4WV9qXlcxLIadS12g3KUWxZGW38D/Ttpc5N8Ev1q71PDt
	dBYg==
MIME-Version: 1.0
X-Received: by 10.180.108.77 with SMTP id hi13mr21579729wib.73.1416833007251; 
	Mon, 24 Nov 2014 04:43:27 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Mon, 24 Nov 2014 04:43:27 -0800 (PST)
In-Reply-To: <546DCC9F02000078000493F4@smtp.nue.novell.com>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCC9F02000078000493F4@smtp.nue.novell.com>
Date: Mon, 24 Nov 2014 12:43:27 +0000
X-Google-Sender-Auth: gbp4xqFopBL3qBKYF_A6idadLvY
Message-ID: <CAFLBxZYeAZOgu_X++dNLzenrZaLFDwUdn8W-Ndf92cm5-5bKGA@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: don't ignore foreigndom input on
 various MMUEXT ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 20, 2014 at 10:12 AM, Jan Beulich <JBeulich@suse.com> wrote:
> Instead properly fail requests that shouldn't be issued on foreign
> domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
> operation to work that way.

I take it this is for 4.6?

I've looked through it and everything looks OK.

But I agree with Tim, that having so many different changes all at the
same time makes the patch hard to review.

In particular, I'd rather start with a patch to get rid of "okay"
entirely; then make MMUEXT_{CLEAR,COPY}_PAGE use foreingndom instead
of current; then have a patch which returns -EPERM for the other ones;
then a patch to get rid of spage in MMUEXT_[UN]MARK_SUPER.

Regarding MMUEXT_{CLEAR,COPY}_PAGE: This is effectively changing the
interface.  Are we sure there are no callers which just expect them to
work on current, and don't set foreigndom properly?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:50:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:50:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xst5n-0004Uu-KL; Mon, 24 Nov 2014 12:50:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xst5l-0004Up-VS
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 12:50:10 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	48/01-17735-18923745; Mon, 24 Nov 2014 12:50:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416833408!13292211!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10243 invoked from network); 24 Nov 2014 12:50:08 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 12:50:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 12:50:08 +0000
Message-Id: <5473378C020000780004A58B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 12:50:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <dunlapg@umich.edu>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCC9F02000078000493F4@smtp.nue.novell.com>
	<CAFLBxZYeAZOgu_X++dNLzenrZaLFDwUdn8W-Ndf92cm5-5bKGA@mail.gmail.com>
In-Reply-To: <CAFLBxZYeAZOgu_X++dNLzenrZaLFDwUdn8W-Ndf92cm5-5bKGA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: don't ignore foreigndom input on
 various MMUEXT ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.11.14 at 13:43, <dunlapg@umich.edu> wrote:
> On Thu, Nov 20, 2014 at 10:12 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> Instead properly fail requests that shouldn't be issued on foreign
>> domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
>> operation to work that way.
> 
> I take it this is for 4.6?

Not really, as said in the cover letter.

> I've looked through it and everything looks OK.
> 
> But I agree with Tim, that having so many different changes all at the
> same time makes the patch hard to review.
> 
> In particular, I'd rather start with a patch to get rid of "okay"
> entirely; then make MMUEXT_{CLEAR,COPY}_PAGE use foreingndom instead
> of current; then have a patch which returns -EPERM for the other ones;
> then a patch to get rid of spage in MMUEXT_[UN]MARK_SUPER.

Yes, that's how I would have done it following Tim's comments if
there wasn't the desire for backporting - that'll become quite a bit
more involved if I do the cleanup patch removing "okay" first. And
doing the -EPERM one first would mean that the backport needs to
carefully add properly setting "okay". Splitting the clear/copy page
change from the -EPERM one doesn't make much sense to me at
all considering the title (and hence purpose) of the patch.

> Regarding MMUEXT_{CLEAR,COPY}_PAGE: This is effectively changing the
> interface.  Are we sure there are no callers which just expect them to
> work on current, and don't set foreigndom properly?

As much or as little as "all of the sudden" returning -EPERM in such
a case for other sub-ops. They never were meant to be used that
way, and the original omission of those checks shouldn't preclude us
from adding them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:50:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12:50:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xst5n-0004Uu-KL; Mon, 24 Nov 2014 12:50:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xst5l-0004Up-VS
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 12:50:10 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	48/01-17735-18923745; Mon, 24 Nov 2014 12:50:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416833408!13292211!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10243 invoked from network); 24 Nov 2014 12:50:08 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 12:50:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 12:50:08 +0000
Message-Id: <5473378C020000780004A58B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 12:50:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <dunlapg@umich.edu>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<546DCC9F02000078000493F4@smtp.nue.novell.com>
	<CAFLBxZYeAZOgu_X++dNLzenrZaLFDwUdn8W-Ndf92cm5-5bKGA@mail.gmail.com>
In-Reply-To: <CAFLBxZYeAZOgu_X++dNLzenrZaLFDwUdn8W-Ndf92cm5-5bKGA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] x86: don't ignore foreigndom input on
 various MMUEXT ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.11.14 at 13:43, <dunlapg@umich.edu> wrote:
> On Thu, Nov 20, 2014 at 10:12 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> Instead properly fail requests that shouldn't be issued on foreign
>> domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
>> operation to work that way.
> 
> I take it this is for 4.6?

Not really, as said in the cover letter.

> I've looked through it and everything looks OK.
> 
> But I agree with Tim, that having so many different changes all at the
> same time makes the patch hard to review.
> 
> In particular, I'd rather start with a patch to get rid of "okay"
> entirely; then make MMUEXT_{CLEAR,COPY}_PAGE use foreingndom instead
> of current; then have a patch which returns -EPERM for the other ones;
> then a patch to get rid of spage in MMUEXT_[UN]MARK_SUPER.

Yes, that's how I would have done it following Tim's comments if
there wasn't the desire for backporting - that'll become quite a bit
more involved if I do the cleanup patch removing "okay" first. And
doing the -EPERM one first would mean that the backport needs to
carefully add properly setting "okay". Splitting the clear/copy page
change from the -EPERM one doesn't make much sense to me at
all considering the title (and hence purpose) of the patch.

> Regarding MMUEXT_{CLEAR,COPY}_PAGE: This is effectively changing the
> interface.  Are we sure there are no callers which just expect them to
> work on current, and don't set foreigndom properly?

As much or as little as "all of the sudden" returning -EPERM in such
a case for other sub-ops. They never were meant to be used that
way, and the original omission of those checks shouldn't preclude us
from adding them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:59:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12: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 1XstEA-0004kB-Rf; Mon, 24 Nov 2014 12:58:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XstE9-0004k6-9s
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 12:58:49 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	AA/BD-25727-88B23745; Mon, 24 Nov 2014 12:58:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416833927!13437769!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15211 invoked from network); 24 Nov 2014 12:58:48 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 24 Nov 2014 12:58:48 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50890 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XstC8-0005qH-A0; Mon, 24 Nov 2014 13:56:44 +0100
Date: Mon, 24 Nov 2014 13:58:46 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <748614644.20141124135846@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5473012D020000780004A2E6@mail.emea.novell.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
	<20141121151407.GD2886@laptop.dumpdata.com>
	<546F6E890200007800049DF9@mail.emea.novell.com>
	<20141121164513.GA6798@laptop.dumpdata.com>
	<5473012D020000780004A2E6@mail.emea.novell.com>
MIME-Version: 1.0
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
	to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQpNb25kYXksIE5vdmVtYmVyIDI0LCAyMDE0LCA5OjU4OjA1IEFNLCB5b3Ugd3JvdGU6Cgo+Pj4+
IE9uIDIxLjExLjE0IGF0IDE3OjQ1LCA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4gd3JvdGU6Cj4+
IEZyb20gOTBkMDBkYjA5NDlhOGU3OTZkN2Y4MTIxMzQ3NTNhNTRiMmZlM2Q1MSBNb24gU2VwIDE3
IDAwOjAwOjAwIDIwMDEKPj4gRnJvbTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2ls
a0BvcmFjbGUuY29tPgo+PiBEYXRlOiBUaHUsIDIwIE5vdiAyMDE0IDE0OjI4OjExIC0wNTAwCj4+
IFN1YmplY3Q6IFtQQVRDSF0gZHBjaTogQWRkICdtYXNrZWQnIGFzIGFuIGdhdGUgZm9yIGh2bV9k
aXJxX2Fzc2lzdCB0byAKPj4gcHJvY2Vzcy4KCj4gU28gYW0gSSByaWdodCBpbiB1bmRlcnN0YW5k
aW5nIHRoYXQgdGhpcyBpcyB0aGVuIHRoZSBvbmx5IHRoaW5nIHRoYXQKPiBuZWVkcyB0byBnbyBp
bnRvIHRoZSB0cmVlIHRvIGZpeCBTYW5kZXIncyBwcm9ibGVtPyBObyB6b21iaWUgc3RhdGUKPiBh
bnltb3JlPwoKPiBKYW4KCgpIaSBKYW4sCgpZZXMgdGhpcyBzaW5nbGUgcGF0Y2ggIndvcmtzIGZv
ciBtZSLihKIuCgotLQpTYW5kZXIKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Nov 24 12:59:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 12: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 1XstEA-0004kB-Rf; Mon, 24 Nov 2014 12:58:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XstE9-0004k6-9s
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 12:58:49 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	AA/BD-25727-88B23745; Mon, 24 Nov 2014 12:58:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416833927!13437769!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15211 invoked from network); 24 Nov 2014 12:58:48 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 24 Nov 2014 12:58:48 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50890 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XstC8-0005qH-A0; Mon, 24 Nov 2014 13:56:44 +0100
Date: Mon, 24 Nov 2014 13:58:46 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <748614644.20141124135846@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5473012D020000780004A2E6@mail.emea.novell.com>
References: <1416435695-23784-1-git-send-email-konrad.wilk@oracle.com>
	<1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
	<20141121151407.GD2886@laptop.dumpdata.com>
	<546F6E890200007800049DF9@mail.emea.novell.com>
	<20141121164513.GA6798@laptop.dumpdata.com>
	<5473012D020000780004A2E6@mail.emea.novell.com>
MIME-Version: 1.0
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state
	to allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQpNb25kYXksIE5vdmVtYmVyIDI0LCAyMDE0LCA5OjU4OjA1IEFNLCB5b3Ugd3JvdGU6Cgo+Pj4+
IE9uIDIxLjExLjE0IGF0IDE3OjQ1LCA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4gd3JvdGU6Cj4+
IEZyb20gOTBkMDBkYjA5NDlhOGU3OTZkN2Y4MTIxMzQ3NTNhNTRiMmZlM2Q1MSBNb24gU2VwIDE3
IDAwOjAwOjAwIDIwMDEKPj4gRnJvbTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2ls
a0BvcmFjbGUuY29tPgo+PiBEYXRlOiBUaHUsIDIwIE5vdiAyMDE0IDE0OjI4OjExIC0wNTAwCj4+
IFN1YmplY3Q6IFtQQVRDSF0gZHBjaTogQWRkICdtYXNrZWQnIGFzIGFuIGdhdGUgZm9yIGh2bV9k
aXJxX2Fzc2lzdCB0byAKPj4gcHJvY2Vzcy4KCj4gU28gYW0gSSByaWdodCBpbiB1bmRlcnN0YW5k
aW5nIHRoYXQgdGhpcyBpcyB0aGVuIHRoZSBvbmx5IHRoaW5nIHRoYXQKPiBuZWVkcyB0byBnbyBp
bnRvIHRoZSB0cmVlIHRvIGZpeCBTYW5kZXIncyBwcm9ibGVtPyBObyB6b21iaWUgc3RhdGUKPiBh
bnltb3JlPwoKPiBKYW4KCgpIaSBKYW4sCgpZZXMgdGhpcyBzaW5nbGUgcGF0Y2ggIndvcmtzIGZv
ciBtZSLihKIuCgotLQpTYW5kZXIKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Nov 24 13:14:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 13:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XstSX-0005Bq-Uw; Mon, 24 Nov 2014 13:13:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XstSW-0005Bl-F9
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 13:13:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	03/06-25276-30F23745; Mon, 24 Nov 2014 13:13:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416834817!14938066!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11143 invoked from network); 24 Nov 2014 13:13:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 13:13:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195232407"
Message-ID: <54732EF5.5040607@citrix.com>
Date: Mon, 24 Nov 2014 13:13:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>, M A Young
	<m.a.young@durham.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
In-Reply-To: <CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
X-DLP: MIA1
Cc: Wei Liu <Wei.Liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/11/14 11:50, George Dunlap wrote:
> On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
>> On Sat, 22 Nov 2014, M A Young wrote:
>>
>>> While investigating a bug reported on Red Hat Bugzilla
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>> I discovered the following
>>>
>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>>> are actually two issues here
>>>
>>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>>> presumably because the allocated memory eventually runs out
>>
>> I have found a bit more out about this. The segfault at at line 1378 of
>> tools/libxc/xc_domain_restore.c which is
>>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>>                         csum_page(buf));
>> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
>> array. This occurs in the verification phase.
>>
>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>> migration still fails. The first attached file contains the log from a run
>>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>>> stripped out to make the size manageable).
>>
>> The difference actually seems to be down to how active the VM is rather than
>> the memory size (my small memory test system was doing very little, my
>> larger system was a full OS install). In the non-segfault case the problem
>> was the printf and printf_info commands in the create_domain() routine in
>> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
>> back from the restoring dom0, these commands cause an unexpected message. If
>> you move them onto stderr then the migration completes in the non-segfault
>> case.
> Good job tracking those down -- are there patches in the works?

The segfault for "--debug" has already been identified and a patch
posted by Wen Congyang

The call to csum_page() incorrectly calculates the offset it is supposed
to checksum, and wanders beyond the mapping of guest space.

Patch in 1409908261-18682-3-git-send-email-wency@cn.fujitsu.com

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 13:14:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 13:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XstSX-0005Bq-Uw; Mon, 24 Nov 2014 13:13:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XstSW-0005Bl-F9
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 13:13:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	03/06-25276-30F23745; Mon, 24 Nov 2014 13:13:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416834817!14938066!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11143 invoked from network); 24 Nov 2014 13:13:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 13:13:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="195232407"
Message-ID: <54732EF5.5040607@citrix.com>
Date: Mon, 24 Nov 2014 13:13:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>, M A Young
	<m.a.young@durham.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
In-Reply-To: <CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
X-DLP: MIA1
Cc: Wei Liu <Wei.Liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/11/14 11:50, George Dunlap wrote:
> On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
>> On Sat, 22 Nov 2014, M A Young wrote:
>>
>>> While investigating a bug reported on Red Hat Bugzilla
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>> I discovered the following
>>>
>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>>> are actually two issues here
>>>
>>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>>> presumably because the allocated memory eventually runs out
>>
>> I have found a bit more out about this. The segfault at at line 1378 of
>> tools/libxc/xc_domain_restore.c which is
>>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>>                         csum_page(buf));
>> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
>> array. This occurs in the verification phase.
>>
>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>> migration still fails. The first attached file contains the log from a run
>>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>>> stripped out to make the size manageable).
>>
>> The difference actually seems to be down to how active the VM is rather than
>> the memory size (my small memory test system was doing very little, my
>> larger system was a full OS install). In the non-segfault case the problem
>> was the printf and printf_info commands in the create_domain() routine in
>> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
>> back from the restoring dom0, these commands cause an unexpected message. If
>> you move them onto stderr then the migration completes in the non-segfault
>> case.
> Good job tracking those down -- are there patches in the works?

The segfault for "--debug" has already been identified and a patch
posted by Wen Congyang

The call to csum_page() incorrectly calculates the offset it is supposed
to checksum, and wanders beyond the mapping of guest space.

Patch in 1409908261-18682-3-git-send-email-wency@cn.fujitsu.com

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 13:16:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 13:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XstVS-0005Hm-HY; Mon, 24 Nov 2014 13:16:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XstVQ-0005He-EO
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 13:16:40 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	EE/10-27785-7BF23745; Mon, 24 Nov 2014 13:16:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416834997!14447059!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11502 invoked from network); 24 Nov 2014 13:16:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 13:16:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195233931"
Message-ID: <54732F8E.4060507@citrix.com>
Date: Mon, 24 Nov 2014 13:15:58 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
In-Reply-To: <20141124124143.GA11483@zion.uk.xensource.com>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/11/14 12:41, Wei Liu wrote:
> On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
>> While investigating a bug reported on Red Hat Bugzilla
>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>> I discovered the following
>>
>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the bug
>> report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There are
>> actually two issues here
>>
>> * the segfault in libxl-save-helper --restore-domain (as reported in the bug
>> above) occurs if the guest memory is 1024M (on my 4G box) and is presumably
>> because the allocated memory eventually runs out
>>
>> * the segfault doesn't occur if the guest memory is 128M, but the migration
>> still fails. The first attached file contains the log from a run with xl -v
>> migrate --debug domid localhost (with mfn and duplicated lines stripped out
>> to make the size manageable).
>>
>> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
>> migrate doesn't work for me at all - see the second attached file for the
>> output of xl -v migrate domid localhost .
>>
>> 	Mchael Young
> [...]
>> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s, dirtied 0Mb/s 314 pages
>> xc: detail: Mapping order 0,  268; first pfn 3fcf4
>> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied 0Mb/s 0 pages
>> xc: detail: Start last iteration
>> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND shinfo 00082fbc
>> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied 1033Mb/s 536 pages
>> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied 2195Mb/s 536 pages
>> xc: detail: Total pages sent= 262749 (1.00x)
>> xc: detail: (of which 0 were fixups)
>> xc: detail: All memory is saved
>> xc: error: Error querying maximum number of MSRs for VCPU0 (1 = Operation not permitted): Internal error
> Per your description this is the output of "xl -v migrate domid
> localhost", so no "--debug" is involved. (Just to make sure...)
>
> This error message means a domctl fails, which should be addressed
> first?
>
> FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
> for me. :-(
>
> Is there anything I need to do to trigger this failure?

Is XSM in use?  I can't think of any other reason why that hypercall
would fail with EPERM.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 13:16:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 13:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XstVS-0005Hm-HY; Mon, 24 Nov 2014 13:16:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XstVQ-0005He-EO
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 13:16:40 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	EE/10-27785-7BF23745; Mon, 24 Nov 2014 13:16:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416834997!14447059!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11502 invoked from network); 24 Nov 2014 13:16:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 13:16:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195233931"
Message-ID: <54732F8E.4060507@citrix.com>
Date: Mon, 24 Nov 2014 13:15:58 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
In-Reply-To: <20141124124143.GA11483@zion.uk.xensource.com>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/11/14 12:41, Wei Liu wrote:
> On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
>> While investigating a bug reported on Red Hat Bugzilla
>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>> I discovered the following
>>
>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the bug
>> report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There are
>> actually two issues here
>>
>> * the segfault in libxl-save-helper --restore-domain (as reported in the bug
>> above) occurs if the guest memory is 1024M (on my 4G box) and is presumably
>> because the allocated memory eventually runs out
>>
>> * the segfault doesn't occur if the guest memory is 128M, but the migration
>> still fails. The first attached file contains the log from a run with xl -v
>> migrate --debug domid localhost (with mfn and duplicated lines stripped out
>> to make the size manageable).
>>
>> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
>> migrate doesn't work for me at all - see the second attached file for the
>> output of xl -v migrate domid localhost .
>>
>> 	Mchael Young
> [...]
>> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s, dirtied 0Mb/s 314 pages
>> xc: detail: Mapping order 0,  268; first pfn 3fcf4
>> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied 0Mb/s 0 pages
>> xc: detail: Start last iteration
>> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND shinfo 00082fbc
>> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied 1033Mb/s 536 pages
>> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied 2195Mb/s 536 pages
>> xc: detail: Total pages sent= 262749 (1.00x)
>> xc: detail: (of which 0 were fixups)
>> xc: detail: All memory is saved
>> xc: error: Error querying maximum number of MSRs for VCPU0 (1 = Operation not permitted): Internal error
> Per your description this is the output of "xl -v migrate domid
> localhost", so no "--debug" is involved. (Just to make sure...)
>
> This error message means a domctl fails, which should be addressed
> first?
>
> FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
> for me. :-(
>
> Is there anything I need to do to trigger this failure?

Is XSM in use?  I can't think of any other reason why that hypercall
would fail with EPERM.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:10:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsuKp-00060H-Sf; Mon, 24 Nov 2014 14:09:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsuKo-00060C-Ts
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:09:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0C/9D-15461-A2C33745; Mon, 24 Nov 2014 14:09:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416838184!14955466!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28932 invoked from network); 24 Nov 2014 14:09:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 14:09:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196075020"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 09:09:43 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsuKl-0008Qb-CE;
	Mon, 24 Nov 2014 14:09:43 +0000
Date: Mon, 24 Nov 2014 14:09:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141124140939.GA14073@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54732EF5.5040607@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <Wei.Liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 01:13:25PM +0000, Andrew Cooper wrote:
> On 24/11/14 11:50, George Dunlap wrote:
> > On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
> >> On Sat, 22 Nov 2014, M A Young wrote:
> >>
> >>> While investigating a bug reported on Red Hat Bugzilla
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
> >>> I discovered the following
> >>>
> >>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
> >>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
> >>> are actually two issues here
> >>>
> >>> * the segfault in libxl-save-helper --restore-domain (as reported in the
> >>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
> >>> presumably because the allocated memory eventually runs out
> >>
> >> I have found a bit more out about this. The segfault at at line 1378 of
> >> tools/libxc/xc_domain_restore.c which is
> >>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
> >>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
> >>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
> >>                         csum_page(buf));
> >> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
> >> array. This occurs in the verification phase.
> >>
> >>> * the segfault doesn't occur if the guest memory is 128M, but the
> >>> migration still fails. The first attached file contains the log from a run
> >>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
> >>> stripped out to make the size manageable).
> >>
> >> The difference actually seems to be down to how active the VM is rather than
> >> the memory size (my small memory test system was doing very little, my
> >> larger system was a full OS install). In the non-segfault case the problem
> >> was the printf and printf_info commands in the create_domain() routine in
> >> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
> >> back from the restoring dom0, these commands cause an unexpected message. If
> >> you move them onto stderr then the migration completes in the non-segfault
> >> case.
> > Good job tracking those down -- are there patches in the works?
> 
> The segfault for "--debug" has already been identified and a patch
> posted by Wen Congyang
> 
> The call to csum_page() incorrectly calculates the offset it is supposed
> to checksum, and wanders beyond the mapping of guest space.
> 
> Patch in 1409908261-18682-3-git-send-email-wency@cn.fujitsu.com
> 

And the said patch has been applied (3460eeb3fc2) so we're fine.

Wei.

> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:10:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsuKp-00060H-Sf; Mon, 24 Nov 2014 14:09:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XsuKo-00060C-Ts
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:09:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0C/9D-15461-A2C33745; Mon, 24 Nov 2014 14:09:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416838184!14955466!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28932 invoked from network); 24 Nov 2014 14:09:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 14:09:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196075020"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 09:09:43 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XsuKl-0008Qb-CE;
	Mon, 24 Nov 2014 14:09:43 +0000
Date: Mon, 24 Nov 2014 14:09:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141124140939.GA14073@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54732EF5.5040607@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <Wei.Liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 01:13:25PM +0000, Andrew Cooper wrote:
> On 24/11/14 11:50, George Dunlap wrote:
> > On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
> >> On Sat, 22 Nov 2014, M A Young wrote:
> >>
> >>> While investigating a bug reported on Red Hat Bugzilla
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
> >>> I discovered the following
> >>>
> >>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
> >>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
> >>> are actually two issues here
> >>>
> >>> * the segfault in libxl-save-helper --restore-domain (as reported in the
> >>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
> >>> presumably because the allocated memory eventually runs out
> >>
> >> I have found a bit more out about this. The segfault at at line 1378 of
> >> tools/libxc/xc_domain_restore.c which is
> >>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
> >>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
> >>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
> >>                         csum_page(buf));
> >> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
> >> array. This occurs in the verification phase.
> >>
> >>> * the segfault doesn't occur if the guest memory is 128M, but the
> >>> migration still fails. The first attached file contains the log from a run
> >>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
> >>> stripped out to make the size manageable).
> >>
> >> The difference actually seems to be down to how active the VM is rather than
> >> the memory size (my small memory test system was doing very little, my
> >> larger system was a full OS install). In the non-segfault case the problem
> >> was the printf and printf_info commands in the create_domain() routine in
> >> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
> >> back from the restoring dom0, these commands cause an unexpected message. If
> >> you move them onto stderr then the migration completes in the non-segfault
> >> case.
> > Good job tracking those down -- are there patches in the works?
> 
> The segfault for "--debug" has already been identified and a patch
> posted by Wen Congyang
> 
> The call to csum_page() incorrectly calculates the offset it is supposed
> to checksum, and wanders beyond the mapping of guest space.
> 
> Patch in 1409908261-18682-3-git-send-email-wency@cn.fujitsu.com
> 

And the said patch has been applied (3460eeb3fc2) so we're fine.

Wei.

> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:15:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsuQ9-0006ED-Kg; Mon, 24 Nov 2014 14:15:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XsuQ7-0006E8-VC
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:15:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A6/68-15461-37D33745; Mon, 24 Nov 2014 14:15:15 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416838513!14892957!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21641 invoked from network); 24 Nov 2014 14:15:14 -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;
	24 Nov 2014 14:15:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195265416"
Message-ID: <54733D04.2030104@citrix.com>
Date: Mon, 24 Nov 2014 14:13:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
	<20141124140939.GA14073@zion.uk.xensource.com>
In-Reply-To: <20141124140939.GA14073@zion.uk.xensource.com>
X-DLP: MIA2
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/11/14 14:09, Wei Liu wrote:
> On Mon, Nov 24, 2014 at 01:13:25PM +0000, Andrew Cooper wrote:
>> On 24/11/14 11:50, George Dunlap wrote:
>>> On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
>>>> On Sat, 22 Nov 2014, M A Young wrote:
>>>>
>>>>> While investigating a bug reported on Red Hat Bugzilla
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>>> I discovered the following
>>>>>
>>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>>>>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>>>>> are actually two issues here
>>>>>
>>>>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>>>>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>>> presumably because the allocated memory eventually runs out
>>>> I have found a bit more out about this. The segfault at at line 1378 of
>>>> tools/libxc/xc_domain_restore.c which is
>>>>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>>>>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>>>>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>>>>                         csum_page(buf));
>>>> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
>>>> array. This occurs in the verification phase.
>>>>
>>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>>> migration still fails. The first attached file contains the log from a run
>>>>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>>>>> stripped out to make the size manageable).
>>>> The difference actually seems to be down to how active the VM is rather than
>>>> the memory size (my small memory test system was doing very little, my
>>>> larger system was a full OS install). In the non-segfault case the problem
>>>> was the printf and printf_info commands in the create_domain() routine in
>>>> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
>>>> back from the restoring dom0, these commands cause an unexpected message. If
>>>> you move them onto stderr then the migration completes in the non-segfault
>>>> case.
>>> Good job tracking those down -- are there patches in the works?
>> The segfault for "--debug" has already been identified and a patch
>> posted by Wen Congyang
>>
>> The call to csum_page() incorrectly calculates the offset it is supposed
>> to checksum, and wanders beyond the mapping of guest space.
>>
>> Patch in 1409908261-18682-3-git-send-email-wency@cn.fujitsu.com
>>
> And the said patch has been applied (3460eeb3fc2) so we're fine.

But not backported to 4.4, which is why Michael is falling over it.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:15:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsuQ9-0006ED-Kg; Mon, 24 Nov 2014 14:15:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XsuQ7-0006E8-VC
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:15:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A6/68-15461-37D33745; Mon, 24 Nov 2014 14:15:15 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416838513!14892957!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21641 invoked from network); 24 Nov 2014 14:15:14 -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;
	24 Nov 2014 14:15:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195265416"
Message-ID: <54733D04.2030104@citrix.com>
Date: Mon, 24 Nov 2014 14:13:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
	<20141124140939.GA14073@zion.uk.xensource.com>
In-Reply-To: <20141124140939.GA14073@zion.uk.xensource.com>
X-DLP: MIA2
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/11/14 14:09, Wei Liu wrote:
> On Mon, Nov 24, 2014 at 01:13:25PM +0000, Andrew Cooper wrote:
>> On 24/11/14 11:50, George Dunlap wrote:
>>> On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
>>>> On Sat, 22 Nov 2014, M A Young wrote:
>>>>
>>>>> While investigating a bug reported on Red Hat Bugzilla
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>>> I discovered the following
>>>>>
>>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>>>>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>>>>> are actually two issues here
>>>>>
>>>>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>>>>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>>> presumably because the allocated memory eventually runs out
>>>> I have found a bit more out about this. The segfault at at line 1378 of
>>>> tools/libxc/xc_domain_restore.c which is
>>>>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>>>>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>>>>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>>>>                         csum_page(buf));
>>>> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
>>>> array. This occurs in the verification phase.
>>>>
>>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>>> migration still fails. The first attached file contains the log from a run
>>>>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>>>>> stripped out to make the size manageable).
>>>> The difference actually seems to be down to how active the VM is rather than
>>>> the memory size (my small memory test system was doing very little, my
>>>> larger system was a full OS install). In the non-segfault case the problem
>>>> was the printf and printf_info commands in the create_domain() routine in
>>>> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
>>>> back from the restoring dom0, these commands cause an unexpected message. If
>>>> you move them onto stderr then the migration completes in the non-segfault
>>>> case.
>>> Good job tracking those down -- are there patches in the works?
>> The segfault for "--debug" has already been identified and a patch
>> posted by Wen Congyang
>>
>> The call to csum_page() incorrectly calculates the offset it is supposed
>> to checksum, and wanders beyond the mapping of guest space.
>>
>> Patch in 1409908261-18682-3-git-send-email-wency@cn.fujitsu.com
>>
> And the said patch has been applied (3460eeb3fc2) so we're fine.

But not backported to 4.4, which is why Michael is falling over it.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:32:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14:32:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsugi-0006XI-8r; Mon, 24 Nov 2014 14:32:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Xsugg-0006XD-JP
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:32:22 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A9/9B-23865-57143745; Mon, 24 Nov 2014 14:32:21 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416839541!13475354!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11073 invoked from network); 24 Nov 2014 14:32:21 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 14:32:21 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOEW8aI021242;
	Mon, 24 Nov 2014 14:32:12 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOEW3OV021242
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 14:32:03 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.5+Sun/8.11.1) with ESMTP id sAOEW37s001823;
	Mon, 24 Nov 2014 14:32:03 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.5+Sun/8.14.5/Submit) with ESMTP id
	sAOEW25G001820; Mon, 24 Nov 2014 14:32:02 GMT
Date: Mon, 24 Nov 2014 14:32:02 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <54732F8E.4060507@citrix.com>
Message-ID: <alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAOEW8aI021242
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Andrew Cooper wrote:

> On 24/11/14 12:41, Wei Liu wrote:
>> On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
>>> While investigating a bug reported on Red Hat Bugzilla
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>> I discovered the following
>>>
>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the bug
>>> report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There are
>>> actually two issues here
>>>
>>> * the segfault in libxl-save-helper --restore-domain (as reported in the bug
>>> above) occurs if the guest memory is 1024M (on my 4G box) and is presumably
>>> because the allocated memory eventually runs out
>>>
>>> * the segfault doesn't occur if the guest memory is 128M, but the migration
>>> still fails. The first attached file contains the log from a run with xl -v
>>> migrate --debug domid localhost (with mfn and duplicated lines stripped out
>>> to make the size manageable).
>>>
>>> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
>>> migrate doesn't work for me at all - see the second attached file for the
>>> output of xl -v migrate domid localhost .
>>>
>>> 	Mchael Young
>> [...]
>>> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s, dirtied 0Mb/s 314 pages
>>> xc: detail: Mapping order 0,  268; first pfn 3fcf4
>>> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied 0Mb/s 0 pages
>>> xc: detail: Start last iteration
>>> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND shinfo 00082fbc
>>> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied 1033Mb/s 536 pages
>>> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied 2195Mb/s 536 pages
>>> xc: detail: Total pages sent= 262749 (1.00x)
>>> xc: detail: (of which 0 were fixups)
>>> xc: detail: All memory is saved
>>> xc: error: Error querying maximum number of MSRs for VCPU0 (1 = Operation not permitted): Internal error
>> Per your description this is the output of "xl -v migrate domid
>> localhost", so no "--debug" is involved. (Just to make sure...)
>>
>> This error message means a domctl fails, which should be addressed
>> first?
>>
>> FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
>> for me. :-(
>>
>> Is there anything I need to do to trigger this failure?
>
> Is XSM in use?  I can't think of any other reason why that hypercall
> would fail with EPERM.

XSM is built in (I wanted to allow the option of people using it) but I 
didn't think it was active.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:32:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14:32:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsugi-0006XI-8r; Mon, 24 Nov 2014 14:32:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Xsugg-0006XD-JP
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:32:22 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A9/9B-23865-57143745; Mon, 24 Nov 2014 14:32:21 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416839541!13475354!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11073 invoked from network); 24 Nov 2014 14:32:21 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 14:32:21 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOEW8aI021242;
	Mon, 24 Nov 2014 14:32:12 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOEW3OV021242
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 14:32:03 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.5+Sun/8.11.1) with ESMTP id sAOEW37s001823;
	Mon, 24 Nov 2014 14:32:03 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.5+Sun/8.14.5/Submit) with ESMTP id
	sAOEW25G001820; Mon, 24 Nov 2014 14:32:02 GMT
Date: Mon, 24 Nov 2014 14:32:02 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <54732F8E.4060507@citrix.com>
Message-ID: <alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAOEW8aI021242
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Andrew Cooper wrote:

> On 24/11/14 12:41, Wei Liu wrote:
>> On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
>>> While investigating a bug reported on Red Hat Bugzilla
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>> I discovered the following
>>>
>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the bug
>>> report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There are
>>> actually two issues here
>>>
>>> * the segfault in libxl-save-helper --restore-domain (as reported in the bug
>>> above) occurs if the guest memory is 1024M (on my 4G box) and is presumably
>>> because the allocated memory eventually runs out
>>>
>>> * the segfault doesn't occur if the guest memory is 128M, but the migration
>>> still fails. The first attached file contains the log from a run with xl -v
>>> migrate --debug domid localhost (with mfn and duplicated lines stripped out
>>> to make the size manageable).
>>>
>>> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
>>> migrate doesn't work for me at all - see the second attached file for the
>>> output of xl -v migrate domid localhost .
>>>
>>> 	Mchael Young
>> [...]
>>> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s, dirtied 0Mb/s 314 pages
>>> xc: detail: Mapping order 0,  268; first pfn 3fcf4
>>> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied 0Mb/s 0 pages
>>> xc: detail: Start last iteration
>>> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND shinfo 00082fbc
>>> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied 1033Mb/s 536 pages
>>> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied 2195Mb/s 536 pages
>>> xc: detail: Total pages sent= 262749 (1.00x)
>>> xc: detail: (of which 0 were fixups)
>>> xc: detail: All memory is saved
>>> xc: error: Error querying maximum number of MSRs for VCPU0 (1 = Operation not permitted): Internal error
>> Per your description this is the output of "xl -v migrate domid
>> localhost", so no "--debug" is involved. (Just to make sure...)
>>
>> This error message means a domctl fails, which should be addressed
>> first?
>>
>> FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
>> for me. :-(
>>
>> Is there anything I need to do to trigger this failure?
>
> Is XSM in use?  I can't think of any other reason why that hypercall
> would fail with EPERM.

XSM is built in (I wanted to allow the option of people using it) but I 
didn't think it was active.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:41:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14: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 1Xsuow-0006ff-6s; Mon, 24 Nov 2014 14:40:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xsuov-0006fa-Lz
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 14:40:53 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	EC/CF-25714-37343745; Mon, 24 Nov 2014 14:40:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416840048!13021193!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19267 invoked from network); 24 Nov 2014 14:40:49 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 14:40:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOEeXGB016813
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 14:40:34 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOEeTcE007842
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 14:40:31 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOEeTqm007834; Mon, 24 Nov 2014 14:40:29 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 06:40:29 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BE34A1190C2; Mon, 24 Nov 2014 09:40:05 -0500 (EST)
Date: Mon, 24 Nov 2014 09:40:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124144005.GA2683@laptop.dumpdata.com>
References: <1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
	<20141121151407.GD2886@laptop.dumpdata.com>
	<546F6E890200007800049DF9@mail.emea.novell.com>
	<20141121164513.GA6798@laptop.dumpdata.com>
	<5473012D020000780004A2E6@mail.emea.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <5473012D020000780004A2E6@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: [Xen-devel] Is: dpci: Add 'masked' as an gate for hvm_dirq_assist
 to process. Was:Re: [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state to
 allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Nov 24, 2014 at 08:58:05AM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 17:45, <konrad.wilk@oracle.com> wrote:
> > From 90d00db0949a8e796d7f812134753a54b2fe3d51 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Thu, 20 Nov 2014 14:28:11 -0500
> > Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to 
> > process.
> 
> So am I right in understanding that this is then the only thing that
> needs to go into the tree to fix Sander's problem? No zombie state

Yes.
> anymore?

Correct. Just that single tiny patch. Here it is attached for your
convience.

> 
> Jan
> 

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-dpci-Add-masked-as-an-gate-for-hvm_dirq_assist-to-pr.patch"

>From 90d00db0949a8e796d7f812134753a54b2fe3d51 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 14:28:11 -0500
Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

commit f6dd295381f4b6a66acddacf46bca8940586c8d8
"dpci: replace tasklet with softirq" used the 'masked' as an
two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
between 'raise_softirq_for' and 'dpci_softirq' to determine whether
the 'struct hvm_pirq_dpci' can be re-scheduled.

However it ignored the 'pt_irq_guest_eoi' was not adhering to the proper
dialogue and was not using locked cmpxchg or test_bit operations and
ended setting 'state' set to zero. That meant 'raise_softirq_for' was
free to schedule it while the 'struct hvm_pirq_dpci'' was still on an
per-cpu list causing an list corruption.

The code would trigger the following path causing list corruption:

    \-timer_softirq_action
    	pt_irq_time_out calls pt_pirq_softirq_cancel sets state to 0.
            pirq_dpci is still on dpci_list.
    \- dpci_sofitrq
    	while (!list_emptry(&our_list))
    		list_del, but has not yet done 'entry->next = LIST_POISON1;'
    [interrupt happens]
    	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
    [interrupt is done, back to dpci_softirq]
    	finishes the entry->next = LIST_POISON1;
    		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
    	ends the loop, exits.

    \- dpci_softirq
    	while (!list_emtpry)
    		list_del, but ->next already has LIST_POISON1 and we blow up.

An alternative solution was proposed (adding STATE_ZOMBIE and making
pt_irq_time_out use the cmpxchg protocol on 'state'), which fixed the above
issue but had an fatal bug. It would miss interrupts that are to be scheduled!

This patch brings back the 'masked' boolean which is used as an
communication channel between 'hvm_do_IRQ_dpci', 'hvm_dirq_assist' and
'pt_irq_guest_eoi'. When we have an interrupt we set 'masked'. Anytime
'hvm_dirq_assist' or 'pt_irq_guest_eoi' executes - it clears it.

The 'state' is left as a seperate mechanism to provide an mechanism between
'raise_sofitrq' and 'softirq_dpci' to communicate the state of the
'struct hvm_dirq_pirq'.

However since we have now two seperate machines we have to deal with an
cancellations and outstanding interrupt being serviced: 'pt_irq_destroy_bind'
is called while an 'hvm_dirq_assist' is just about to service.
The 'pt_irq_destroy_bind' takes the lock first and kills the timer - and
the moment it releases the spinlock, 'hvm_dirq_assist' thunders in and calls
'set_timer' hitting an ASSERT.

By clearing the 'masked' in the 'pt_irq_destroy_bind' we take care of that
scenario by inhibiting 'hvm_dirq_assist' to call the 'set_timer'.

In the 'pt_irq_create_bind' - in the error cases we could be seeing
an softirq scheduled right away and being serviced (though stuck at
the spinlock).  The 'pt_irq_create_bind' fails in 'pt_pirq_softirq_reset'
to change the 'state' (as the state is in 'STATE_RUN', not 'STATE_SCHED').
'pt_irq_create_bind' continues on with setting '->flag=0' and unlocks the lock.

'hvm_dirq_assist' grabs the lock and continues one. Since 'flag = 0' and
'digl_list' is empty, it thunders through the 'hvm_dirq_assist' not doing
anything until it hits 'set_timer' which is undefined for MSI. Adding
in 'masked=0' for the MSI case fixes that.

The legacy interrupt one does not need it as there is no chance of
do_IRQ being called at that point.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
v2: Deal with 'masked' in pt_irq_destroy_bind.
v3: Deal with 'masked' in pt_irq_create_bind.
---
 xen/drivers/passthrough/io.c | 12 ++++++++++--
 xen/include/xen/hvm/irq.h    |  1 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..ae050df 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -129,6 +129,13 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
         pirq_dpci->dom = NULL;
         break;
     }
+    /*
+     * Inhibit 'hvm_dirq_assist' from doing anything useful and at worst
+     * calling 'set_timer' which will blow up (as we have called kill_timer
+     * or never initialized it). Note that we hold the lock that
+     * 'hvm_dirq_assist' could be spinning on.
+     */
+    pirq_dpci->masked = 0;
 }
 
 bool_t pt_irq_need_timer(uint32_t flags)
@@ -142,7 +149,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pirq_dpci->masked = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -610,6 +617,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
+    pirq_dpci->masked = 1;
     raise_softirq_for(pirq_dpci);
     return 1;
 }
@@ -669,7 +677,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( pirq_dpci->state )
+    if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..3996f1f 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -94,6 +94,7 @@ struct hvm_irq_dpci {
 struct hvm_pirq_dpci {
     uint32_t flags;
     unsigned int state;
+    bool_t masked;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
-- 
1.9.3


--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--a8Wt8u1KmwUX3Y2C--


From xen-devel-bounces@lists.xen.org Mon Nov 24 14:41:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14: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 1Xsuow-0006ff-6s; Mon, 24 Nov 2014 14:40:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xsuov-0006fa-Lz
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 14:40:53 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	EC/CF-25714-37343745; Mon, 24 Nov 2014 14:40:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416840048!13021193!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19267 invoked from network); 24 Nov 2014 14:40:49 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 14:40:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOEeXGB016813
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 14:40:34 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOEeTcE007842
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 14:40:31 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOEeTqm007834; Mon, 24 Nov 2014 14:40:29 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 06:40:29 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BE34A1190C2; Mon, 24 Nov 2014 09:40:05 -0500 (EST)
Date: Mon, 24 Nov 2014 09:40:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124144005.GA2683@laptop.dumpdata.com>
References: <1416435695-23784-3-git-send-email-konrad.wilk@oracle.com>
	<546DD6BF0200007800049471@smtp.nue.novell.com>
	<20141120195133.GE25423@laptop.dumpdata.com>
	<546EFD1502000078000499E3@smtp.nue.novell.com>
	<FCBE717C-1D43-497C-ADDE-4275A113B42C@oracle.com>
	<546F382F0200007800049B49@smtp.nue.novell.com>
	<20141121151407.GD2886@laptop.dumpdata.com>
	<546F6E890200007800049DF9@mail.emea.novell.com>
	<20141121164513.GA6798@laptop.dumpdata.com>
	<5473012D020000780004A2E6@mail.emea.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <5473012D020000780004A2E6@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	linux@eikelenboom.it
Subject: [Xen-devel] Is: dpci: Add 'masked' as an gate for hvm_dirq_assist
 to process. Was:Re: [for-xen-4.5 PATCH v2 2/2] dpci: Add ZOMBIE state to
 allow the softirq to finish with the dpci_pirq.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Nov 24, 2014 at 08:58:05AM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 17:45, <konrad.wilk@oracle.com> wrote:
> > From 90d00db0949a8e796d7f812134753a54b2fe3d51 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Thu, 20 Nov 2014 14:28:11 -0500
> > Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to 
> > process.
> 
> So am I right in understanding that this is then the only thing that
> needs to go into the tree to fix Sander's problem? No zombie state

Yes.
> anymore?

Correct. Just that single tiny patch. Here it is attached for your
convience.

> 
> Jan
> 

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-dpci-Add-masked-as-an-gate-for-hvm_dirq_assist-to-pr.patch"

>From 90d00db0949a8e796d7f812134753a54b2fe3d51 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Nov 2014 14:28:11 -0500
Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to process.

commit f6dd295381f4b6a66acddacf46bca8940586c8d8
"dpci: replace tasklet with softirq" used the 'masked' as an
two-bit state mechanism (STATE_SCHED, STATE_RUN) to communicate
between 'raise_softirq_for' and 'dpci_softirq' to determine whether
the 'struct hvm_pirq_dpci' can be re-scheduled.

However it ignored the 'pt_irq_guest_eoi' was not adhering to the proper
dialogue and was not using locked cmpxchg or test_bit operations and
ended setting 'state' set to zero. That meant 'raise_softirq_for' was
free to schedule it while the 'struct hvm_pirq_dpci'' was still on an
per-cpu list causing an list corruption.

The code would trigger the following path causing list corruption:

    \-timer_softirq_action
    	pt_irq_time_out calls pt_pirq_softirq_cancel sets state to 0.
            pirq_dpci is still on dpci_list.
    \- dpci_sofitrq
    	while (!list_emptry(&our_list))
    		list_del, but has not yet done 'entry->next = LIST_POISON1;'
    [interrupt happens]
    	raise_softirq checks state which is zero. Adds pirq_dpci to the dpci_list.
    [interrupt is done, back to dpci_softirq]
    	finishes the entry->next = LIST_POISON1;
    		.. test STATE_SCHED returns true, so executes the hvm_dirq_assist.
    	ends the loop, exits.

    \- dpci_softirq
    	while (!list_emtpry)
    		list_del, but ->next already has LIST_POISON1 and we blow up.

An alternative solution was proposed (adding STATE_ZOMBIE and making
pt_irq_time_out use the cmpxchg protocol on 'state'), which fixed the above
issue but had an fatal bug. It would miss interrupts that are to be scheduled!

This patch brings back the 'masked' boolean which is used as an
communication channel between 'hvm_do_IRQ_dpci', 'hvm_dirq_assist' and
'pt_irq_guest_eoi'. When we have an interrupt we set 'masked'. Anytime
'hvm_dirq_assist' or 'pt_irq_guest_eoi' executes - it clears it.

The 'state' is left as a seperate mechanism to provide an mechanism between
'raise_sofitrq' and 'softirq_dpci' to communicate the state of the
'struct hvm_dirq_pirq'.

However since we have now two seperate machines we have to deal with an
cancellations and outstanding interrupt being serviced: 'pt_irq_destroy_bind'
is called while an 'hvm_dirq_assist' is just about to service.
The 'pt_irq_destroy_bind' takes the lock first and kills the timer - and
the moment it releases the spinlock, 'hvm_dirq_assist' thunders in and calls
'set_timer' hitting an ASSERT.

By clearing the 'masked' in the 'pt_irq_destroy_bind' we take care of that
scenario by inhibiting 'hvm_dirq_assist' to call the 'set_timer'.

In the 'pt_irq_create_bind' - in the error cases we could be seeing
an softirq scheduled right away and being serviced (though stuck at
the spinlock).  The 'pt_irq_create_bind' fails in 'pt_pirq_softirq_reset'
to change the 'state' (as the state is in 'STATE_RUN', not 'STATE_SCHED').
'pt_irq_create_bind' continues on with setting '->flag=0' and unlocks the lock.

'hvm_dirq_assist' grabs the lock and continues one. Since 'flag = 0' and
'digl_list' is empty, it thunders through the 'hvm_dirq_assist' not doing
anything until it hits 'set_timer' which is undefined for MSI. Adding
in 'masked=0' for the MSI case fixes that.

The legacy interrupt one does not need it as there is no chance of
do_IRQ being called at that point.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
v2: Deal with 'masked' in pt_irq_destroy_bind.
v3: Deal with 'masked' in pt_irq_create_bind.
---
 xen/drivers/passthrough/io.c | 12 ++++++++++--
 xen/include/xen/hvm/irq.h    |  1 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index efc66dc..ae050df 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -129,6 +129,13 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
         pirq_dpci->dom = NULL;
         break;
     }
+    /*
+     * Inhibit 'hvm_dirq_assist' from doing anything useful and at worst
+     * calling 'set_timer' which will blow up (as we have called kill_timer
+     * or never initialized it). Note that we hold the lock that
+     * 'hvm_dirq_assist' could be spinning on.
+     */
+    pirq_dpci->masked = 0;
 }
 
 bool_t pt_irq_need_timer(uint32_t flags)
@@ -142,7 +149,7 @@ static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
     if ( __test_and_clear_bit(_HVM_IRQ_DPCI_EOI_LATCH_SHIFT,
                               &pirq_dpci->flags) )
     {
-        pirq_dpci->state = 0;
+        pirq_dpci->masked = 0;
         pirq_dpci->pending = 0;
         pirq_guest_eoi(dpci_pirq(pirq_dpci));
     }
@@ -610,6 +617,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
          !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
         return 0;
 
+    pirq_dpci->masked = 1;
     raise_softirq_for(pirq_dpci);
     return 1;
 }
@@ -669,7 +677,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
     ASSERT(d->arch.hvm_domain.irq.dpci);
 
     spin_lock(&d->event_lock);
-    if ( pirq_dpci->state )
+    if ( test_and_clear_bool(pirq_dpci->masked) )
     {
         struct pirq *pirq = dpci_pirq(pirq_dpci);
         const struct dev_intx_gsi_link *digl;
diff --git a/xen/include/xen/hvm/irq.h b/xen/include/xen/hvm/irq.h
index 9709397..3996f1f 100644
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -94,6 +94,7 @@ struct hvm_irq_dpci {
 struct hvm_pirq_dpci {
     uint32_t flags;
     unsigned int state;
+    bool_t masked;
     uint16_t pending;
     struct list_head digl_list;
     struct domain *dom;
-- 
1.9.3


--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--a8Wt8u1KmwUX3Y2C--


From xen-devel-bounces@lists.xen.org Mon Nov 24 14:43:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14: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 1Xsur4-0006rd-Tl; Mon, 24 Nov 2014 14:43:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xsur3-0006rY-EX
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:43:05 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	BC/C3-17958-8F343745; Mon, 24 Nov 2014 14:43:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416840182!13439565!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17057 invoked from network); 24 Nov 2014 14:43:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 14:43:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196091441"
Message-ID: <547343F4.80509@citrix.com>
Date: Mon, 24 Nov 2014 14:43:00 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
In-Reply-To: <alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/11/14 14:32, M A Young wrote:
> On Mon, 24 Nov 2014, Andrew Cooper wrote:
>
>> On 24/11/14 12:41, Wei Liu wrote:
>>> On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
>>>> While investigating a bug reported on Red Hat Bugzilla
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>> I discovered the following
>>>>
>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv
>>>> (the bug
>>>> report is for Xen 4.3 hvm ) when xl migrate domid localhost works.
>>>> There are
>>>> actually two issues here
>>>>
>>>> * the segfault in libxl-save-helper --restore-domain (as reported
>>>> in the bug
>>>> above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>> presumably
>>>> because the allocated memory eventually runs out
>>>>
>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>> migration
>>>> still fails. The first attached file contains the log from a run
>>>> with xl -v
>>>> migrate --debug domid localhost (with mfn and duplicated lines
>>>> stripped out
>>>> to make the size manageable).
>>>>
>>>> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
>>>> migrate doesn't work for me at all - see the second attached file
>>>> for the
>>>> output of xl -v migrate domid localhost .
>>>>
>>>>     Mchael Young
>>> [...]
>>>> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s,
>>>> dirtied 0Mb/s 314 pages
>>>> xc: detail: Mapping order 0,  268; first pfn 3fcf4
>>>> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied
>>>> 0Mb/s 0 pages
>>>> xc: detail: Start last iteration
>>>> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND
>>>> shinfo 00082fbc
>>>> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied
>>>> 1033Mb/s 536 pages
>>>> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied
>>>> 2195Mb/s 536 pages
>>>> xc: detail: Total pages sent= 262749 (1.00x)
>>>> xc: detail: (of which 0 were fixups)
>>>> xc: detail: All memory is saved
>>>> xc: error: Error querying maximum number of MSRs for VCPU0 (1 =
>>>> Operation not permitted): Internal error
>>> Per your description this is the output of "xl -v migrate domid
>>> localhost", so no "--debug" is involved. (Just to make sure...)
>>>
>>> This error message means a domctl fails, which should be addressed
>>> first?
>>>
>>> FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
>>> for me. :-(
>>>
>>> Is there anything I need to do to trigger this failure?
>>
>> Is XSM in use?  I can't think of any other reason why that hypercall
>> would fail with EPERM.
>
> XSM is built in (I wanted to allow the option of people using it) but
> I didn't think it was active.
>
>     Michael Young

I don't believe there is any concept of "available but not active",
which probably means that the default policy is missing an entry for
this hypercall.

Can you check the hypervisor console around this failure and see whether
a flask error concerning domctl 72 is reported?

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:43:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14: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 1Xsur4-0006rd-Tl; Mon, 24 Nov 2014 14:43:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xsur3-0006rY-EX
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:43:05 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	BC/C3-17958-8F343745; Mon, 24 Nov 2014 14:43:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416840182!13439565!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17057 invoked from network); 24 Nov 2014 14:43:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 14:43:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196091441"
Message-ID: <547343F4.80509@citrix.com>
Date: Mon, 24 Nov 2014 14:43:00 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
In-Reply-To: <alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/11/14 14:32, M A Young wrote:
> On Mon, 24 Nov 2014, Andrew Cooper wrote:
>
>> On 24/11/14 12:41, Wei Liu wrote:
>>> On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
>>>> While investigating a bug reported on Red Hat Bugzilla
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>> I discovered the following
>>>>
>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv
>>>> (the bug
>>>> report is for Xen 4.3 hvm ) when xl migrate domid localhost works.
>>>> There are
>>>> actually two issues here
>>>>
>>>> * the segfault in libxl-save-helper --restore-domain (as reported
>>>> in the bug
>>>> above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>> presumably
>>>> because the allocated memory eventually runs out
>>>>
>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>> migration
>>>> still fails. The first attached file contains the log from a run
>>>> with xl -v
>>>> migrate --debug domid localhost (with mfn and duplicated lines
>>>> stripped out
>>>> to make the size manageable).
>>>>
>>>> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
>>>> migrate doesn't work for me at all - see the second attached file
>>>> for the
>>>> output of xl -v migrate domid localhost .
>>>>
>>>>     Mchael Young
>>> [...]
>>>> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s,
>>>> dirtied 0Mb/s 314 pages
>>>> xc: detail: Mapping order 0,  268; first pfn 3fcf4
>>>> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied
>>>> 0Mb/s 0 pages
>>>> xc: detail: Start last iteration
>>>> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND
>>>> shinfo 00082fbc
>>>> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied
>>>> 1033Mb/s 536 pages
>>>> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied
>>>> 2195Mb/s 536 pages
>>>> xc: detail: Total pages sent= 262749 (1.00x)
>>>> xc: detail: (of which 0 were fixups)
>>>> xc: detail: All memory is saved
>>>> xc: error: Error querying maximum number of MSRs for VCPU0 (1 =
>>>> Operation not permitted): Internal error
>>> Per your description this is the output of "xl -v migrate domid
>>> localhost", so no "--debug" is involved. (Just to make sure...)
>>>
>>> This error message means a domctl fails, which should be addressed
>>> first?
>>>
>>> FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
>>> for me. :-(
>>>
>>> Is there anything I need to do to trigger this failure?
>>
>> Is XSM in use?  I can't think of any other reason why that hypercall
>> would fail with EPERM.
>
> XSM is built in (I wanted to allow the option of people using it) but
> I didn't think it was active.
>
>     Michael Young

I don't believe there is any concept of "available but not active",
which probably means that the default policy is missing an entry for
this hypercall.

Can you check the hypervisor console around this failure and see whether
a flask error concerning domctl 72 is reported?

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:51:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14:51:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsuyv-00073c-3D; Mon, 24 Nov 2014 14:51:13 +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 1Xsuyt-00073X-EP
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 14:51:11 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	FF/19-02702-ED543745; Mon, 24 Nov 2014 14:51:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416840668!14462530!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17996 invoked from network); 24 Nov 2014 14:51:10 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 14:51:10 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOEp7Lk032191
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 14:51:07 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOEp6Uj012628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 14:51:06 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAOEp5HM003925; Mon, 24 Nov 2014 14:51:05 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 06:51:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 900BC1190CF; Mon, 24 Nov 2014 09:51:06 -0500 (EST)
Date: Mon, 24 Nov 2014 09:51:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124145106.GC3000@laptop.dumpdata.com>
References: <545B9C5F020000780004561B@mail.emea.novell.com>
	<20141121220338.GA17981@laptop.dumpdata.com>
	<5472F22B020000780004A28C@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5472F22B020000780004A28C@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, boris.ostrovsky@oracle.com,
	david.vrabel@citrix.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-pciback: drop SR-IOV VFs when PF driver
	unloads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 07:54:03AM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 23:03, <konrad.wilk@oracle.com> wrote:
> > I rewrote it a bit to be more in the style of pciback:
> >[...]
> > [v2: Removed the switch statement, moved it about]
> 
> What you don't mention here is that you also removed the outer
> loop, yet that breaks functionality afaict: There can (and I suppose
> normally will) be multiple VFs needing device_release_driver() called
> when a single PF goes away.

Good point.
> 
> Also I'm not really happy for a patch with my S-o-b underneath to
> introduce goto-s without real need.

Will ditch them.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:51:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14:51:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsuyv-00073c-3D; Mon, 24 Nov 2014 14:51:13 +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 1Xsuyt-00073X-EP
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 14:51:11 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	FF/19-02702-ED543745; Mon, 24 Nov 2014 14:51:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416840668!14462530!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17996 invoked from network); 24 Nov 2014 14:51:10 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 14:51:10 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOEp7Lk032191
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 14:51:07 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOEp6Uj012628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 14:51:06 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAOEp5HM003925; Mon, 24 Nov 2014 14:51:05 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 06:51:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 900BC1190CF; Mon, 24 Nov 2014 09:51:06 -0500 (EST)
Date: Mon, 24 Nov 2014 09:51:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124145106.GC3000@laptop.dumpdata.com>
References: <545B9C5F020000780004561B@mail.emea.novell.com>
	<20141121220338.GA17981@laptop.dumpdata.com>
	<5472F22B020000780004A28C@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5472F22B020000780004A28C@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, boris.ostrovsky@oracle.com,
	david.vrabel@citrix.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-pciback: drop SR-IOV VFs when PF driver
	unloads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 07:54:03AM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 23:03, <konrad.wilk@oracle.com> wrote:
> > I rewrote it a bit to be more in the style of pciback:
> >[...]
> > [v2: Removed the switch statement, moved it about]
> 
> What you don't mention here is that you also removed the outer
> loop, yet that breaks functionality afaict: There can (and I suppose
> normally will) be multiple VFs needing device_release_driver() called
> when a single PF goes away.

Good point.
> 
> Also I'm not really happy for a patch with my S-o-b underneath to
> introduce goto-s without real need.

Will ditch them.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:54:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsv2A-0007Ha-P1; Mon, 24 Nov 2014 14:54:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xsv29-0007HU-0u
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:54:33 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5F/B7-25276-8A643745; Mon, 24 Nov 2014 14:54:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416840870!14872321!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9766 invoked from network); 24 Nov 2014 14:54:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 14:54:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOEsMFJ004437
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 14:54:23 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOEsLP3011357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 14:54:21 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOEsKeN024295; Mon, 24 Nov 2014 14:54:20 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 06:54:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 262A31190D2; Mon, 24 Nov 2014 09:54:22 -0500 (EST)
Date: Mon, 24 Nov 2014 09:54:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Hu, Robert" <robert.hu@intel.com>, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Message-ID: <20141124145421.GD3000@laptop.dumpdata.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<546354D7.2040703@oracle.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A68B84@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A68B84@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed to
 fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 07:43:49AM +0000, Hu, Robert wrote:
> > -----Original Message-----
> > From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
> > Sent: Wednesday, November 12, 2014 8:39 PM
> > To: Hu, Robert; xen-devel@lists.xen.org
> > Cc: JBeulich@suse.com
> > Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> > 
> > 
> > On 11/12/2014 01:58 AM, Hu, Robert wrote:
> > > 2. Failed to hotplug a VT-d device with XEN4.5-RC1
> > >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> > 
> > 
> > This should be addressed by these two:
> > http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00875.html
> > http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00874.html
> Tried, these patches works. When will they get in?

CC-ed Ian's so they are aware of the independent testing done by Intel.

Thank you!
> > 
> > -boris
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 24 14:54:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsv2A-0007Ha-P1; Mon, 24 Nov 2014 14:54:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xsv29-0007HU-0u
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:54:33 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5F/B7-25276-8A643745; Mon, 24 Nov 2014 14:54:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416840870!14872321!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9766 invoked from network); 24 Nov 2014 14:54:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 14:54:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOEsMFJ004437
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 14:54:23 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOEsLP3011357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 14:54:21 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOEsKeN024295; Mon, 24 Nov 2014 14:54:20 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 06:54:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 262A31190D2; Mon, 24 Nov 2014 09:54:22 -0500 (EST)
Date: Mon, 24 Nov 2014 09:54:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Hu, Robert" <robert.hu@intel.com>, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Message-ID: <20141124145421.GD3000@laptop.dumpdata.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<546354D7.2040703@oracle.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A68B84@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A68B84@SHSMSX103.ccr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed to
 fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 07:43:49AM +0000, Hu, Robert wrote:
> > -----Original Message-----
> > From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
> > Sent: Wednesday, November 12, 2014 8:39 PM
> > To: Hu, Robert; xen-devel@lists.xen.org
> > Cc: JBeulich@suse.com
> > Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> > 
> > 
> > On 11/12/2014 01:58 AM, Hu, Robert wrote:
> > > 2. Failed to hotplug a VT-d device with XEN4.5-RC1
> > >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
> > 
> > 
> > This should be addressed by these two:
> > http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00875.html
> > http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00874.html
> Tried, these patches works. When will they get in?

CC-ed Ian's so they are aware of the independent testing done by Intel.

Thank you!
> > 
> > -boris
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 24 14:55:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14: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 1Xsv2z-0007LN-6O; Mon, 24 Nov 2014 14:55:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xsv2y-0007LE-7p
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:55:24 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A3/59-25276-BD643745; Mon, 24 Nov 2014 14:55:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416840921!12177786!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5130 invoked from network); 24 Nov 2014 14:55:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 14:55:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196097585"
Message-ID: <1416840918.8878.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Daniel De Graaf
	<dgdegra@tycho.nsa.gov>
Date: Mon, 24 Nov 2014 14:55:18 +0000
In-Reply-To: <547343F4.80509@citrix.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
	<547343F4.80509@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, Wei Liu <wei.liu2@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-24 at 14:43 +0000, Andrew Cooper wrote:
> On 24/11/14 14:32, M A Young wrote:
> > On Mon, 24 Nov 2014, Andrew Cooper wrote:
> >> Is XSM in use?  I can't think of any other reason why that hypercall
> >> would fail with EPERM.
> >
> > XSM is built in (I wanted to allow the option of people using it) but
> > I didn't think it was active.
> 
> I don't believe there is any concept of "available but not active",

I think there is, the "dummy" policy which is loaded when there is no
explicit policy given should behave as if xsm were disabled. AIUI all
the XSM_* and xsm_default_action stuff is supposed to semi automatically
ensure this is the case at compile time. CC-ing Daniel to confirm/deny.

> which probably means that the default policy is missing an entry for
> this hypercall.

That said domctl is XSM_OTHER, which basically means "special one off
handling" I think. But it basically turns into XSM_DM_PRIV for a small
handful of subops and XSM_PRIV for the rest. Since this is a migration
the relevant domain is certainly PRIV I think.

Ian.

> Can you check the hypervisor console around this failure and see whether
> a flask error concerning domctl 72 is reported?
> 
> ~Andrew
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 14:55:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 14: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 1Xsv2z-0007LN-6O; Mon, 24 Nov 2014 14:55:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xsv2y-0007LE-7p
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:55:24 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A3/59-25276-BD643745; Mon, 24 Nov 2014 14:55:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416840921!12177786!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5130 invoked from network); 24 Nov 2014 14:55:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 14:55:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196097585"
Message-ID: <1416840918.8878.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Daniel De Graaf
	<dgdegra@tycho.nsa.gov>
Date: Mon, 24 Nov 2014 14:55:18 +0000
In-Reply-To: <547343F4.80509@citrix.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
	<547343F4.80509@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, Wei Liu <wei.liu2@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-24 at 14:43 +0000, Andrew Cooper wrote:
> On 24/11/14 14:32, M A Young wrote:
> > On Mon, 24 Nov 2014, Andrew Cooper wrote:
> >> Is XSM in use?  I can't think of any other reason why that hypercall
> >> would fail with EPERM.
> >
> > XSM is built in (I wanted to allow the option of people using it) but
> > I didn't think it was active.
> 
> I don't believe there is any concept of "available but not active",

I think there is, the "dummy" policy which is loaded when there is no
explicit policy given should behave as if xsm were disabled. AIUI all
the XSM_* and xsm_default_action stuff is supposed to semi automatically
ensure this is the case at compile time. CC-ing Daniel to confirm/deny.

> which probably means that the default policy is missing an entry for
> this hypercall.

That said domctl is XSM_OTHER, which basically means "special one off
handling" I think. But it basically turns into XSM_DM_PRIV for a small
handful of subops and XSM_PRIV for the rest. Since this is a migration
the relevant domain is certainly PRIV I think.

Ian.

> Can you check the hypervisor console around this failure and see whether
> a flask error concerning domctl 72 is reported?
> 
> ~Andrew
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:00:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsv7P-0007YB-TA; Mon, 24 Nov 2014 14:59:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhuanchen@gmail.com>) id 1Xsv7O-0007Y6-4I
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:59:58 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4C/3E-09842-DE743745; Mon, 24 Nov 2014 14:59:57 +0000
X-Env-Sender: zhuanchen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416841196!14970247!1
X-Originating-IP: [209.85.192.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11104 invoked from network); 24 Nov 2014 14:59:56 -0000
Received: from mail-qg0-f52.google.com (HELO mail-qg0-f52.google.com)
	(209.85.192.52)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 14:59:56 -0000
Received: by mail-qg0-f52.google.com with SMTP id a108so6905088qge.11
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 06:59:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=28RZDRFz7TEmwjS6BeCmolfZy1Dmjx3XGWnU2QKE2FE=;
	b=l2rmRA1CynJUjITtPOAHJ/njh/19nGBW8q3YH29f2uvZh0xU54nPOt384KhBTo5E80
	bedFIyaGIKZJCIi8LYE7gAro/7TeU7Igb3g4qhwZnXoBhuUEg/622a/c5oxdWuyunV82
	dlNX1DoSUmFrZefuo5MW7hCFzApVNvWOTpR10nXjzhUKUI+7krihUgEUlTkupZf0BCFb
	spsq9myGQt7AhgHBGS6SxIoxKBm9ejoIBEs6l0I3wg5PJha5P7DmSeEgZu1nrc3uQ3Ci
	RUw0mdEpUi2AbhlLpeds1V0axub4IOaJHGWLv3C13TjYI7cPX6P2+4DR3u5KEKT2uUJR
	1ltw==
X-Received: by 10.224.80.6 with SMTP id r6mr29195668qak.5.1416841196068; Mon,
	24 Nov 2014 06:59:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.246.130 with HTTP; Mon, 24 Nov 2014 06:59:35 -0800 (PST)
From: Zhuan Chen <zhuanchen@gmail.com>
Date: Mon, 24 Nov 2014 09:59:35 -0500
Message-ID: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Building 32-bit xen.efi for 32-bit EFI 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

Hi,

I am wondering whether it's possible to build 32-bit xen.efi for the
32-bit EFI platform? One way of building xen.efi I learnt is to make
the binutils configured with the x86_64-pep emulation (according to
the document http://xenbits.xenproject.org/docs/unstable/misc/efi.html).
The resulted xen.efi is 64-bit mode. Is it possible to build xen.efi
as the 32-bit mode?

The reason for this question is due to my effort of installing Xen on
the Asus Transformer Book T100, which is one of the Bay Trail Atom
(64-bit processors) tablets shipped with 32-bit EFI firmware. This
requires the support of the 32-bit EFI bootloader. Such platforms seem
to become common and Linux kernel from 3.15 also provides the EFI
mixed mode to support 64-bit kernels running from 32-bit EFI firmware.

Thanks,
Zhuan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:00:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsv7P-0007YB-TA; Mon, 24 Nov 2014 14:59:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhuanchen@gmail.com>) id 1Xsv7O-0007Y6-4I
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 14:59:58 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4C/3E-09842-DE743745; Mon, 24 Nov 2014 14:59:57 +0000
X-Env-Sender: zhuanchen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1416841196!14970247!1
X-Originating-IP: [209.85.192.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11104 invoked from network); 24 Nov 2014 14:59:56 -0000
Received: from mail-qg0-f52.google.com (HELO mail-qg0-f52.google.com)
	(209.85.192.52)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 14:59:56 -0000
Received: by mail-qg0-f52.google.com with SMTP id a108so6905088qge.11
	for <xen-devel@lists.xen.org>; Mon, 24 Nov 2014 06:59:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=28RZDRFz7TEmwjS6BeCmolfZy1Dmjx3XGWnU2QKE2FE=;
	b=l2rmRA1CynJUjITtPOAHJ/njh/19nGBW8q3YH29f2uvZh0xU54nPOt384KhBTo5E80
	bedFIyaGIKZJCIi8LYE7gAro/7TeU7Igb3g4qhwZnXoBhuUEg/622a/c5oxdWuyunV82
	dlNX1DoSUmFrZefuo5MW7hCFzApVNvWOTpR10nXjzhUKUI+7krihUgEUlTkupZf0BCFb
	spsq9myGQt7AhgHBGS6SxIoxKBm9ejoIBEs6l0I3wg5PJha5P7DmSeEgZu1nrc3uQ3Ci
	RUw0mdEpUi2AbhlLpeds1V0axub4IOaJHGWLv3C13TjYI7cPX6P2+4DR3u5KEKT2uUJR
	1ltw==
X-Received: by 10.224.80.6 with SMTP id r6mr29195668qak.5.1416841196068; Mon,
	24 Nov 2014 06:59:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.246.130 with HTTP; Mon, 24 Nov 2014 06:59:35 -0800 (PST)
From: Zhuan Chen <zhuanchen@gmail.com>
Date: Mon, 24 Nov 2014 09:59:35 -0500
Message-ID: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Building 32-bit xen.efi for 32-bit EFI 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

Hi,

I am wondering whether it's possible to build 32-bit xen.efi for the
32-bit EFI platform? One way of building xen.efi I learnt is to make
the binutils configured with the x86_64-pep emulation (according to
the document http://xenbits.xenproject.org/docs/unstable/misc/efi.html).
The resulted xen.efi is 64-bit mode. Is it possible to build xen.efi
as the 32-bit mode?

The reason for this question is due to my effort of installing Xen on
the Asus Transformer Book T100, which is one of the Bay Trail Atom
(64-bit processors) tablets shipped with 32-bit EFI firmware. This
requires the support of the 32-bit EFI bootloader. Such platforms seem
to become common and Linux kernel from 3.15 also provides the EFI
mixed mode to support 64-bit kernels running from 32-bit EFI firmware.

Thanks,
Zhuan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:06:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:06:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvDr-0007ow-OI; Mon, 24 Nov 2014 15:06:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XsvDp-0007or-Q8
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 15:06:37 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	1A/3B-23865-D7943745; Mon, 24 Nov 2014 15:06:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416841594!13446629!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10923 invoked from network); 24 Nov 2014 15:06:36 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:06:36 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOF65ME002620
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:06:06 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOF64dD027835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 15:06:05 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOF64lc027794; Mon, 24 Nov 2014 15:06:04 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:06:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D09021190FB; Mon, 24 Nov 2014 10:06:05 -0500 (EST)
Date: Mon, 24 Nov 2014 10:06:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141124150605.GA3946@laptop.dumpdata.com>
References: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
	<CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	aragrawal <aragrawal@cs.wisc.edu>
Subject: Re: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 12:07:39PM +0000, George Dunlap wrote:
> On Mon, Nov 24, 2014 at 3:54 AM, aragrawal <aragrawal@cs.wisc.edu> wrote:
> > Hi
> >
> > I am interested in getting the block I/O rate fixed for a Virtual Machine.
> > However, it seems that there are no such options to control the block I/O
> > rate via the VM configuration file.
> > Going through the net, I see suggestions to configure the xen_blkback driver
> > using ionice to get that done.
> >
> > I would like to know if there are any plans to include any such
> > configuration option.
> > Also, are there any particular reason (apart from the fact that there are
> > other ways to get this done) for the absence of such configuration option?
> 
> I'm pretty sure it's just because nobody had asked for it yet.
> 
> We can put it on our list of things to think about doing / projects
> for people new to the community.
> 
> We also accept patches. :-)

Patches for this were in the past posted - it just that nobody explained
to the maintainer (me) why the dm-* or io-nice would not do the same job.

I sadly don't remember from whom they were or such.
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:06:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:06:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvDr-0007ow-OI; Mon, 24 Nov 2014 15:06:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XsvDp-0007or-Q8
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 15:06:37 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	1A/3B-23865-D7943745; Mon, 24 Nov 2014 15:06:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416841594!13446629!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10923 invoked from network); 24 Nov 2014 15:06:36 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:06:36 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOF65ME002620
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:06:06 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOF64dD027835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 15:06:05 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOF64lc027794; Mon, 24 Nov 2014 15:06:04 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:06:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D09021190FB; Mon, 24 Nov 2014 10:06:05 -0500 (EST)
Date: Mon, 24 Nov 2014 10:06:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141124150605.GA3946@laptop.dumpdata.com>
References: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
	<CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	aragrawal <aragrawal@cs.wisc.edu>
Subject: Re: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 12:07:39PM +0000, George Dunlap wrote:
> On Mon, Nov 24, 2014 at 3:54 AM, aragrawal <aragrawal@cs.wisc.edu> wrote:
> > Hi
> >
> > I am interested in getting the block I/O rate fixed for a Virtual Machine.
> > However, it seems that there are no such options to control the block I/O
> > rate via the VM configuration file.
> > Going through the net, I see suggestions to configure the xen_blkback driver
> > using ionice to get that done.
> >
> > I would like to know if there are any plans to include any such
> > configuration option.
> > Also, are there any particular reason (apart from the fact that there are
> > other ways to get this done) for the absence of such configuration option?
> 
> I'm pretty sure it's just because nobody had asked for it yet.
> 
> We can put it on our list of things to think about doing / projects
> for people new to the community.
> 
> We also accept patches. :-)

Patches for this were in the past posted - it just that nobody explained
to the maintainer (me) why the dm-* or io-nice would not do the same job.

I sadly don't remember from whom they were or such.
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:07:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvEM-0007rA-4j; Mon, 24 Nov 2014 15:07: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 1XsvEK-0007qu-2j
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 15:07:08 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	F3/2C-29352-B9943745; Mon, 24 Nov 2014 15:07:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416841625!9699758!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1598 invoked from network); 24 Nov 2014 15:07:06 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 15:07:06 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOF6qQS022808
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:06:52 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOF6m5O015899
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 15:06:49 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOF6mrE029905; Mon, 24 Nov 2014 15:06:48 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:06:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 972BF1190FD; Mon, 24 Nov 2014 10:06:49 -0500 (EST)
Date: Mon, 24 Nov 2014 10:06:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141124150649.GB3946@laptop.dumpdata.com>
References: <1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > > > > The rom is used for pxebooting. We don't need to allow pxebooting from
> > > > > more than one network card.  Loading a romfile for every NIC wastes
> > > > 
> > > > Why not? Why can't we PXE boot from each network card?
> > > 
> > > I take it back: you are right, at the moment it is actually possible to
> > > pxe boot from the fourth nic for example. Maybe we could just load the
> > > first four romfiles and skip the others (four is the limit before QEMU
> > > fails to allocate any more memory).
> > 
> > The limit is in the count of ROMs or the memory consumption?
> 
> The limit is memory consumption.

Um, how big are those ROMs? Gigs?

> 
> 
> > What if you also do PCI passthrough? Does that figure in this calculation?
> 
> In the case of PCI passthrough, roms are remapped, so they shouldn't
> affect memory consumption.
> 
>  
> > > TBH not all the emulated nics need a romfile but I wouldn't want to go
> > > down at that level of details beause they become QEMU implementation
> > > details. I wouldn't want to tie libxl to a certain version of QEMU in
> > > any way.
> > > 
> > > A better way would be handling memory allocation errors in QEMU but QEMU
> > > doesn't do that at the moment and the change there would be certainly
> > > more invasive that a couple of lines in libxl.
> > > 
> > > 
> > > > > memory and as a matter of fact breaks configurations with more than 4
> > > > > NICs as QEMU fails to allocate memory on behalf of the guest.
> > > > 
> > > > What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> > > > and ne2k ?
> > > > 
> > > > Don't you want to load the ROM for each one?
> > > 
> > > The rom cannot be reused in QEMU among multiple instances of the same
> > > nic, so having four different types of nics or just one type doesn't
> > > change anything.
> > > 
> > > 
> > > > > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > > > > guest.
> > > > > 
> > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > 
> > > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > > index 3e191c3..f907ca9 100644
> > > > > --- a/tools/libxl/libxl_dm.c
> > > > > +++ b/tools/libxl/libxl_dm.c
> > > > > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > > >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> > > > >                  flexarray_append(dm_args, "-device");
> > > > >                  flexarray_append(dm_args,
> > > > > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > > > > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> > > > >                                                  nics[i].model, nics[i].devid,
> > > > > -                                                nics[i].devid, smac));
> > > > > +                                                nics[i].devid, smac,
> > > > > +                                                i ? ",romfile=\"\"" : ""));
> > > > >                  flexarray_append(dm_args, "-netdev");
> > > > >                  flexarray_append(dm_args, GCSPRINTF(
> > > > >                                            "type=tap,id=net%d,ifname=%s,"
> > > > > 
> > > > > _______________________________________________
> > > > > Xen-devel mailing list
> > > > > Xen-devel@lists.xen.org
> > > > > http://lists.xen.org/xen-devel
> > > > 
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:07:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvEM-0007rA-4j; Mon, 24 Nov 2014 15:07: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 1XsvEK-0007qu-2j
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 15:07:08 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	F3/2C-29352-B9943745; Mon, 24 Nov 2014 15:07:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416841625!9699758!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1598 invoked from network); 24 Nov 2014 15:07:06 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 15:07:06 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOF6qQS022808
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:06:52 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOF6m5O015899
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 15:06:49 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOF6mrE029905; Mon, 24 Nov 2014 15:06:48 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:06:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 972BF1190FD; Mon, 24 Nov 2014 10:06:49 -0500 (EST)
Date: Mon, 24 Nov 2014 10:06:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141124150649.GB3946@laptop.dumpdata.com>
References: <1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > > > > The rom is used for pxebooting. We don't need to allow pxebooting from
> > > > > more than one network card.  Loading a romfile for every NIC wastes
> > > > 
> > > > Why not? Why can't we PXE boot from each network card?
> > > 
> > > I take it back: you are right, at the moment it is actually possible to
> > > pxe boot from the fourth nic for example. Maybe we could just load the
> > > first four romfiles and skip the others (four is the limit before QEMU
> > > fails to allocate any more memory).
> > 
> > The limit is in the count of ROMs or the memory consumption?
> 
> The limit is memory consumption.

Um, how big are those ROMs? Gigs?

> 
> 
> > What if you also do PCI passthrough? Does that figure in this calculation?
> 
> In the case of PCI passthrough, roms are remapped, so they shouldn't
> affect memory consumption.
> 
>  
> > > TBH not all the emulated nics need a romfile but I wouldn't want to go
> > > down at that level of details beause they become QEMU implementation
> > > details. I wouldn't want to tie libxl to a certain version of QEMU in
> > > any way.
> > > 
> > > A better way would be handling memory allocation errors in QEMU but QEMU
> > > doesn't do that at the moment and the change there would be certainly
> > > more invasive that a couple of lines in libxl.
> > > 
> > > 
> > > > > memory and as a matter of fact breaks configurations with more than 4
> > > > > NICs as QEMU fails to allocate memory on behalf of the guest.
> > > > 
> > > > What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> > > > and ne2k ?
> > > > 
> > > > Don't you want to load the ROM for each one?
> > > 
> > > The rom cannot be reused in QEMU among multiple instances of the same
> > > nic, so having four different types of nics or just one type doesn't
> > > change anything.
> > > 
> > > 
> > > > > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > > > > guest.
> > > > > 
> > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > 
> > > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > > index 3e191c3..f907ca9 100644
> > > > > --- a/tools/libxl/libxl_dm.c
> > > > > +++ b/tools/libxl/libxl_dm.c
> > > > > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > > >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> > > > >                  flexarray_append(dm_args, "-device");
> > > > >                  flexarray_append(dm_args,
> > > > > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > > > > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> > > > >                                                  nics[i].model, nics[i].devid,
> > > > > -                                                nics[i].devid, smac));
> > > > > +                                                nics[i].devid, smac,
> > > > > +                                                i ? ",romfile=\"\"" : ""));
> > > > >                  flexarray_append(dm_args, "-netdev");
> > > > >                  flexarray_append(dm_args, GCSPRINTF(
> > > > >                                            "type=tap,id=net%d,ifname=%s,"
> > > > > 
> > > > > _______________________________________________
> > > > > Xen-devel mailing list
> > > > > Xen-devel@lists.xen.org
> > > > > http://lists.xen.org/xen-devel
> > > > 
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:09:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:09:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvGf-00082l-R4; Mon, 24 Nov 2014 15:09:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XsvGe-00082Y-I5
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 15:09:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DC/83-09842-B2A43745; Mon, 24 Nov 2014 15:09:31 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416841771!14944433!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10571 invoked from network); 24 Nov 2014 15:09:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:09:31 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id E4E07AC7D
	for <xen-devel@lists.xensource.com>;
	Mon, 24 Nov 2014 15:09:30 +0000 (UTC)
Message-ID: <54734A2A.9000301@suse.com>
Date: Mon, 24 Nov 2014 16:09:30 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546EFAE3.80404@suse.com>		<20141121135747.GB2886@laptop.dumpdata.com>	<5473008C.4080604@suse.com>
	<5473147C020000780004A3D5@suse.com> <54730F8F.7080905@suse.com>
In-Reply-To: <54730F8F.7080905@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 11:59 AM, Juergen Gross wrote:
> On 11/24/2014 11:20 AM, Jan Beulich wrote:
>>>>> On 24.11.14 at 10:55, <JGross@suse.com> wrote:
>>> - Sometimes I see only NMI watchdog messages, looking into hanging cpu
>>>     state via xen debug keys I can see the cpu(s) in question are
>>> spinning
>>>     in _raw_spin_lock():
>>>     __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
>>>     The hanging cpus were executing some random user processes (cron,
>>>     bash, xargs), cr2 contained user addresses.
>>
>> Is this perhaps what
>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02135.html
>> appears to be about?
>
> Hmm, I'm not sure.
>
> I'll try a 3.17 kernel to verify.

Still seeing the issue, but less frequent. OTOH I just found in above
thread in lkml that 3.17 is showing that issue, too. :-(

I'll try to setup a pv-variant of Linus' patch and test it...


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:09:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:09:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvGf-00082l-R4; Mon, 24 Nov 2014 15:09:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XsvGe-00082Y-I5
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 15:09:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DC/83-09842-B2A43745; Mon, 24 Nov 2014 15:09:31 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416841771!14944433!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10571 invoked from network); 24 Nov 2014 15:09:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:09:31 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id E4E07AC7D
	for <xen-devel@lists.xensource.com>;
	Mon, 24 Nov 2014 15:09:30 +0000 (UTC)
Message-ID: <54734A2A.9000301@suse.com>
Date: Mon, 24 Nov 2014 16:09:30 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546EFAE3.80404@suse.com>		<20141121135747.GB2886@laptop.dumpdata.com>	<5473008C.4080604@suse.com>
	<5473147C020000780004A3D5@suse.com> <54730F8F.7080905@suse.com>
In-Reply-To: <54730F8F.7080905@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 11:59 AM, Juergen Gross wrote:
> On 11/24/2014 11:20 AM, Jan Beulich wrote:
>>>>> On 24.11.14 at 10:55, <JGross@suse.com> wrote:
>>> - Sometimes I see only NMI watchdog messages, looking into hanging cpu
>>>     state via xen debug keys I can see the cpu(s) in question are
>>> spinning
>>>     in _raw_spin_lock():
>>>     __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
>>>     The hanging cpus were executing some random user processes (cron,
>>>     bash, xargs), cr2 contained user addresses.
>>
>> Is this perhaps what
>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02135.html
>> appears to be about?
>
> Hmm, I'm not sure.
>
> I'll try a 3.17 kernel to verify.

Still seeing the issue, but less frequent. OTOH I just found in above
thread in lkml that 3.17 is showing that issue, too. :-(

I'll try to setup a pv-variant of Linus' patch and test it...


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:10:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15: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 1XsvHp-00089n-9b; Mon, 24 Nov 2014 15:10:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XsvHn-00089T-II
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 15:10:43 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	EE/C7-24859-27A43745; Mon, 24 Nov 2014 15:10:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416841840!13463325!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13802 invoked from network); 24 Nov 2014 15:10:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:10:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOFAPUv008672
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:10:26 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAOFAPCx016823
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 15:10:25 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFAOMD012471; Mon, 24 Nov 2014 15:10:25 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:10:24 -0800
Message-ID: <54734B0D.1090201@oracle.com>
Date: Mon, 24 Nov 2014 10:13:17 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Hu, Robert" <robert.hu@intel.com>, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<546354D7.2040703@oracle.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A68B84@SHSMSX103.ccr.corp.intel.com>
	<20141124145421.GD3000@laptop.dumpdata.com>
In-Reply-To: <20141124145421.GD3000@laptop.dumpdata.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed
 to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 09:54 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 24, 2014 at 07:43:49AM +0000, Hu, Robert wrote:
>>> -----Original Message-----
>>> From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
>>> Sent: Wednesday, November 12, 2014 8:39 PM
>>> To: Hu, Robert; xen-devel@lists.xen.org
>>> Cc: JBeulich@suse.com
>>> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
>>>
>>>
>>> On 11/12/2014 01:58 AM, Hu, Robert wrote:
>>>> 2. Failed to hotplug a VT-d device with XEN4.5-RC1
>>>>     http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
>>>
>>> This should be addressed by these two:
>>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00875.html
>>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00874.html
>> Tried, these patches works. When will they get in?


They won't get in in the form that they are now. I will need to rework them.

For this specific problem though I think

http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html

should be sufficient. Please give it a try.

Thanks.
-boris


> CC-ed Ian's so they are aware of the independent testing done by Intel.
>
> Thank you!
>>> -boris
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Nov 24 15:10:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15: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 1XsvHp-00089n-9b; Mon, 24 Nov 2014 15:10:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XsvHn-00089T-II
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 15:10:43 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	EE/C7-24859-27A43745; Mon, 24 Nov 2014 15:10:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1416841840!13463325!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13802 invoked from network); 24 Nov 2014 15:10:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:10:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOFAPUv008672
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:10:26 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAOFAPCx016823
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 15:10:25 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFAOMD012471; Mon, 24 Nov 2014 15:10:25 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:10:24 -0800
Message-ID: <54734B0D.1090201@oracle.com>
Date: Mon, 24 Nov 2014 10:13:17 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Hu, Robert" <robert.hu@intel.com>, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<546354D7.2040703@oracle.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A68B84@SHSMSX103.ccr.corp.intel.com>
	<20141124145421.GD3000@laptop.dumpdata.com>
In-Reply-To: <20141124145421.GD3000@laptop.dumpdata.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed
 to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 09:54 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 24, 2014 at 07:43:49AM +0000, Hu, Robert wrote:
>>> -----Original Message-----
>>> From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
>>> Sent: Wednesday, November 12, 2014 8:39 PM
>>> To: Hu, Robert; xen-devel@lists.xen.org
>>> Cc: JBeulich@suse.com
>>> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
>>>
>>>
>>> On 11/12/2014 01:58 AM, Hu, Robert wrote:
>>>> 2. Failed to hotplug a VT-d device with XEN4.5-RC1
>>>>     http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
>>>
>>> This should be addressed by these two:
>>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00875.html
>>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00874.html
>> Tried, these patches works. When will they get in?


They won't get in in the form that they are now. I will need to rework them.

For this specific problem though I think

http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html

should be sufficient. Please give it a try.

Thanks.
-boris


> CC-ed Ian's so they are aware of the independent testing done by Intel.
>
> Thank you!
>>> -boris
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Nov 24 15:12:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:12:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvJO-0008JC-RE; Mon, 24 Nov 2014 15:12:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XsvJM-0008Is-Te
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 15:12:21 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C2/50-02957-4DA43745; Mon, 24 Nov 2014 15:12:20 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416841928!9068422!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2245 invoked from network); 24 Nov 2014 15:12:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 15:12:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196105737"
Message-ID: <54734A33.6040600@citrix.com>
Date: Mon, 24 Nov 2014 15:09:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Zhuan Chen <zhuanchen@gmail.com>, <xen-devel@lists.xen.org>
References: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
In-Reply-To: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] Building 32-bit xen.efi for 32-bit EFI 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

On 24/11/14 14:59, Zhuan Chen wrote:
> Hi,
>
> I am wondering whether it's possible to build 32-bit xen.efi for the
> 32-bit EFI platform? One way of building xen.efi I learnt is to make
> the binutils configured with the x86_64-pep emulation (according to
> the document http://xenbits.xenproject.org/docs/unstable/misc/efi.html).
> The resulted xen.efi is 64-bit mode. Is it possible to build xen.efi
> as the 32-bit mode?
>
> The reason for this question is due to my effort of installing Xen on
> the Asus Transformer Book T100, which is one of the Bay Trail Atom
> (64-bit processors) tablets shipped with 32-bit EFI firmware. This
> requires the support of the 32-bit EFI bootloader. Such platforms seem
> to become common and Linux kernel from 3.15 also provides the EFI
> mixed mode to support 64-bit kernels running from 32-bit EFI firmware.
>
> Thanks,
> Zhuan

32bit Xen support was removed in Xen 4.3, so building a pure 32bit
hypervisor is not possible.

There is an argument to be made for building a 32bit Xen.efi which is
bootable by a 32bit firmware and moves into 64bit mode on boot.

There is however no support for this that I am aware of.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:12:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:12:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvJO-0008JC-RE; Mon, 24 Nov 2014 15:12:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XsvJM-0008Is-Te
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 15:12:21 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C2/50-02957-4DA43745; Mon, 24 Nov 2014 15:12:20 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416841928!9068422!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2245 invoked from network); 24 Nov 2014 15:12:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 15:12:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196105737"
Message-ID: <54734A33.6040600@citrix.com>
Date: Mon, 24 Nov 2014 15:09:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Zhuan Chen <zhuanchen@gmail.com>, <xen-devel@lists.xen.org>
References: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
In-Reply-To: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] Building 32-bit xen.efi for 32-bit EFI 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

On 24/11/14 14:59, Zhuan Chen wrote:
> Hi,
>
> I am wondering whether it's possible to build 32-bit xen.efi for the
> 32-bit EFI platform? One way of building xen.efi I learnt is to make
> the binutils configured with the x86_64-pep emulation (according to
> the document http://xenbits.xenproject.org/docs/unstable/misc/efi.html).
> The resulted xen.efi is 64-bit mode. Is it possible to build xen.efi
> as the 32-bit mode?
>
> The reason for this question is due to my effort of installing Xen on
> the Asus Transformer Book T100, which is one of the Bay Trail Atom
> (64-bit processors) tablets shipped with 32-bit EFI firmware. This
> requires the support of the 32-bit EFI bootloader. Such platforms seem
> to become common and Linux kernel from 3.15 also provides the EFI
> mixed mode to support 64-bit kernels running from 32-bit EFI firmware.
>
> Thanks,
> Zhuan

32bit Xen support was removed in Xen 4.3, so building a pure 32bit
hypervisor is not possible.

There is an argument to be made for building a 32bit Xen.efi which is
bootable by a 32bit firmware and moves into 64bit mode on boot.

There is however no support for this that I am aware of.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:14:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:14:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvLc-00005S-0V; Mon, 24 Nov 2014 15:14: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 1XsvLa-00005I-RU
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 15:14:38 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	7A/9F-01660-D5B43745; Mon, 24 Nov 2014 15:14:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416842074!13049434!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17267 invoked from network); 24 Nov 2014 15:14:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 15:14:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195301637"
Message-ID: <1416841880.8878.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 24 Nov 2014 15:11:20 +0000
In-Reply-To: <20141124150605.GA3946@laptop.dumpdata.com>
References: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
	<CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
	<20141124150605.GA3946@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	aragrawal <aragrawal@cs.wisc.edu>
Subject: Re: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-24 at 10:06 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 24, 2014 at 12:07:39PM +0000, George Dunlap wrote:
> > On Mon, Nov 24, 2014 at 3:54 AM, aragrawal <aragrawal@cs.wisc.edu> wrote:
> > > Hi
> > >
> > > I am interested in getting the block I/O rate fixed for a Virtual Machine.
> > > However, it seems that there are no such options to control the block I/O
> > > rate via the VM configuration file.
> > > Going through the net, I see suggestions to configure the xen_blkback driver
> > > using ionice to get that done.
> > >
> > > I would like to know if there are any plans to include any such
> > > configuration option.
> > > Also, are there any particular reason (apart from the fact that there are
> > > other ways to get this done) for the absence of such configuration option?
> > 
> > I'm pretty sure it's just because nobody had asked for it yet.
> > 
> > We can put it on our list of things to think about doing / projects
> > for people new to the community.
> > 
> > We also accept patches. :-)
> 
> Patches for this were in the past posted - it just that nobody explained
> to the maintainer (me) why the dm-* or io-nice would not do the same job.

AIUI the question here is why the toolstack doesn't integrate a guest
cfg file setting to configure dm-* and/or io-nice, rather than why
blkback doesn't duplicate their functionality.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:14:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:14:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvLc-00005S-0V; Mon, 24 Nov 2014 15:14: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 1XsvLa-00005I-RU
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 15:14:38 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	7A/9F-01660-D5B43745; Mon, 24 Nov 2014 15:14:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416842074!13049434!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17267 invoked from network); 24 Nov 2014 15:14:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 15:14:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195301637"
Message-ID: <1416841880.8878.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 24 Nov 2014 15:11:20 +0000
In-Reply-To: <20141124150605.GA3946@laptop.dumpdata.com>
References: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
	<CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
	<20141124150605.GA3946@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	aragrawal <aragrawal@cs.wisc.edu>
Subject: Re: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-24 at 10:06 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 24, 2014 at 12:07:39PM +0000, George Dunlap wrote:
> > On Mon, Nov 24, 2014 at 3:54 AM, aragrawal <aragrawal@cs.wisc.edu> wrote:
> > > Hi
> > >
> > > I am interested in getting the block I/O rate fixed for a Virtual Machine.
> > > However, it seems that there are no such options to control the block I/O
> > > rate via the VM configuration file.
> > > Going through the net, I see suggestions to configure the xen_blkback driver
> > > using ionice to get that done.
> > >
> > > I would like to know if there are any plans to include any such
> > > configuration option.
> > > Also, are there any particular reason (apart from the fact that there are
> > > other ways to get this done) for the absence of such configuration option?
> > 
> > I'm pretty sure it's just because nobody had asked for it yet.
> > 
> > We can put it on our list of things to think about doing / projects
> > for people new to the community.
> > 
> > We also accept patches. :-)
> 
> Patches for this were in the past posted - it just that nobody explained
> to the maintainer (me) why the dm-* or io-nice would not do the same job.

AIUI the question here is why the toolstack doesn't integrate a guest
cfg file setting to configure dm-* and/or io-nice, rather than why
blkback doesn't duplicate their functionality.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:21:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:21:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvRy-0000RK-63; Mon, 24 Nov 2014 15:21: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 1XsvRx-0000RD-27
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 15:21:13 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	4F/8D-02696-8EC43745; Mon, 24 Nov 2014 15:21:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416842470!14480223!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31166 invoked from network); 24 Nov 2014 15:21:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:21:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOFKe9X011087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:20:41 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFKdrl009908
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 15:20:40 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAOFKcug026386; Mon, 24 Nov 2014 15:20:38 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:20:38 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 093F2119119; Mon, 24 Nov 2014 10:20:40 -0500 (EST)
Date: Mon, 24 Nov 2014 10:20:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141124152039.GC3946@laptop.dumpdata.com>
References: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
	<CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
	<20141124150605.GA3946@laptop.dumpdata.com>
	<1416841880.8878.7.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416841880.8878.7.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	aragrawal <aragrawal@cs.wisc.edu>
Subject: Re: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 03:11:20PM +0000, Ian Campbell wrote:
> On Mon, 2014-11-24 at 10:06 -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 24, 2014 at 12:07:39PM +0000, George Dunlap wrote:
> > > On Mon, Nov 24, 2014 at 3:54 AM, aragrawal <aragrawal@cs.wisc.edu> wrote:
> > > > Hi
> > > >
> > > > I am interested in getting the block I/O rate fixed for a Virtual Machine.
> > > > However, it seems that there are no such options to control the block I/O
> > > > rate via the VM configuration file.
> > > > Going through the net, I see suggestions to configure the xen_blkback driver
> > > > using ionice to get that done.
> > > >
> > > > I would like to know if there are any plans to include any such
> > > > configuration option.
> > > > Also, are there any particular reason (apart from the fact that there are
> > > > other ways to get this done) for the absence of such configuration option?
> > > 
> > > I'm pretty sure it's just because nobody had asked for it yet.
> > > 
> > > We can put it on our list of things to think about doing / projects
> > > for people new to the community.
> > > 
> > > We also accept patches. :-)
> > 
> > Patches for this were in the past posted - it just that nobody explained
> > to the maintainer (me) why the dm-* or io-nice would not do the same job.
> 
> AIUI the question here is why the toolstack doesn't integrate a guest
> cfg file setting to configure dm-* and/or io-nice, rather than why
> blkback doesn't duplicate their functionality.

Ah, that is a different question. That certainly could be done by somebody
who has the time.
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:21:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:21:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvRy-0000RK-63; Mon, 24 Nov 2014 15:21: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 1XsvRx-0000RD-27
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 15:21:13 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	4F/8D-02696-8EC43745; Mon, 24 Nov 2014 15:21:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416842470!14480223!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31166 invoked from network); 24 Nov 2014 15:21:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:21:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOFKe9X011087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:20:41 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFKdrl009908
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 15:20:40 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAOFKcug026386; Mon, 24 Nov 2014 15:20:38 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:20:38 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 093F2119119; Mon, 24 Nov 2014 10:20:40 -0500 (EST)
Date: Mon, 24 Nov 2014 10:20:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141124152039.GC3946@laptop.dumpdata.com>
References: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
	<CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
	<20141124150605.GA3946@laptop.dumpdata.com>
	<1416841880.8878.7.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416841880.8878.7.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	aragrawal <aragrawal@cs.wisc.edu>
Subject: Re: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 03:11:20PM +0000, Ian Campbell wrote:
> On Mon, 2014-11-24 at 10:06 -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 24, 2014 at 12:07:39PM +0000, George Dunlap wrote:
> > > On Mon, Nov 24, 2014 at 3:54 AM, aragrawal <aragrawal@cs.wisc.edu> wrote:
> > > > Hi
> > > >
> > > > I am interested in getting the block I/O rate fixed for a Virtual Machine.
> > > > However, it seems that there are no such options to control the block I/O
> > > > rate via the VM configuration file.
> > > > Going through the net, I see suggestions to configure the xen_blkback driver
> > > > using ionice to get that done.
> > > >
> > > > I would like to know if there are any plans to include any such
> > > > configuration option.
> > > > Also, are there any particular reason (apart from the fact that there are
> > > > other ways to get this done) for the absence of such configuration option?
> > > 
> > > I'm pretty sure it's just because nobody had asked for it yet.
> > > 
> > > We can put it on our list of things to think about doing / projects
> > > for people new to the community.
> > > 
> > > We also accept patches. :-)
> > 
> > Patches for this were in the past posted - it just that nobody explained
> > to the maintainer (me) why the dm-* or io-nice would not do the same job.
> 
> AIUI the question here is why the toolstack doesn't integrate a guest
> cfg file setting to configure dm-* and/or io-nice, rather than why
> blkback doesn't duplicate their functionality.

Ah, that is a different question. That certainly could be done by somebody
who has the time.
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:23:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15: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.xen.org>)
	id 1XsvTy-0000hR-Nz; Mon, 24 Nov 2014 15:23:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XsvTx-0000hG-8j
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 15:23:17 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	20/76-25547-46D43745; Mon, 24 Nov 2014 15:23:16 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416842592!9044044!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17677 invoked from network); 24 Nov 2014 15:23:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 15:23:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196112984"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 10:23:09 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XsvTp-0001Yb-IO;
	Mon, 24 Nov 2014 15:23:09 +0000
Date: Mon, 24 Nov 2014 15:23:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Wen Congyang <wency@cn.fujitsu.com>
In-Reply-To: <5472F980.6030208@cn.fujitsu.com>
Message-ID: <alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	xen devel <xen-devel@lists.xen.org>, Fabio Fantoni <fabio.fantoni@m2r.biz>,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] qemu crash with virtio on Xen domUs (backtrace
	included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CC'ing Paolo.


Wen,
thanks for the logs.

I investigated a little bit and it seems to me that the bug occurs when
QEMU tries to unmap only a portion of a memory region previously mapped.
That doesn't work with xen-mapcache.

See these logs for example:

DEBUG address_space_map phys_addr=78ed8b44 vaddr=7f9609bedb44 len=0xa
DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6

that leads to the error:

xen_ram_addr_from_mapcache, could not find 0x7fab50afbb68


Paolo, do you know why virtio would call address_space_unmap with a
different set of arguments compared to the previous address_space_map
call?


On Mon, 24 Nov 2014, Wen Congyang wrote:
> On 11/24/2014 04:52 PM, Fabio Fantoni wrote:
> > Il 24/11/2014 02:58, Wen Congyang ha scritto:
> >> When I try to use virtio on xen(HVM guest), qemu crashed. Here is the backtrace:
> >> (gdb) bt
> >> #0  0x00007f49581f0b55 in raise () from /lib64/libc.so.6
> >> #1  0x00007f49581f2131 in abort () from /lib64/libc.so.6
> >> #2  0x00007f495af2af32 in xen_ram_addr_from_mapcache (ptr=0x7f4951858ac8) at /root/work/xen/tools/qemu-xen-dir/xen-mapcache.c:316
> >> #3  0x00007f495ae30fb3 in qemu_ram_addr_from_host (ptr=0x7f4951858ac8, ram_addr=0x7fff564dc9b0) at /root/work/xen/tools/qemu-xen-dir/exec.c:1508
> >> #4  0x00007f495ae33424 in address_space_unmap (as=0x7f495b7c3520, buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2315
> >> #5  0x00007f495ae335b3 in cpu_physical_memory_unmap (buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2353
> >> #6  0x00007f495ae9058d in virtqueue_fill (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1, idx=0) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:258
> >> #7  0x00007f495ae90a0d in virtqueue_push (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:286
> >> #8  0x00007f495ae82cf3 in virtio_net_handle_ctrl (vdev=0x7f495b92a5d0, vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/net/virtio-net.c:806
> >> #9  0x00007f495ae925e5 in virtio_queue_notify_vq (vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:729
> >> #10 0x00007f495ae926c3 in virtio_queue_notify (vdev=0x7f495b92a5d0, n=2) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:735
> >> #11 0x00007f495ad743c2 in virtio_ioport_write (opaque=0x7f495b929cd0, addr=16, val=2) at hw/virtio/virtio-pci.c:301
> >> #12 0x00007f495ad74923 in virtio_pci_config_write (opaque=0x7f495b929cd0, addr=16, val=2, size=2) at hw/virtio/virtio-pci.c:433
> >> #13 0x00007f495ae9f071 in memory_region_write_accessor (mr=0x7f495b92a468, addr=16, value=0x7fff564e8d08, size=2, shift=0, mask=65535) at /root/work/xen/tools/qemu-xen-dir/memory.c:441
> >> #14 0x00007f495ae9f1ad in access_with_adjusted_size (addr=16, value=0x7fff564e8d08, size=2, access_size_min=1, access_size_max=4, access=0x7f495ae9efe8 <memory_region_write_accessor>, mr=0x7f495b92a468)
> >>      at /root/work/xen/tools/qemu-xen-dir/memory.c:478
> >> #15 0x00007f495aea200e in memory_region_dispatch_write (mr=0x7f495b92a468, addr=16, data=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:985
> >> #16 0x00007f495aea5824 in io_mem_write (mr=0x7f495b92a468, addr=16, val=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:1744
> >> #17 0x00007f495ae328d3 in address_space_rw (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2, is_write=true) at /root/work/xen/tools/qemu-xen-dir/exec.c:2029
> >> #18 0x00007f495ae32c85 in address_space_write (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2) at /root/work/xen/tools/qemu-xen-dir/exec.c:2091
> >> #19 0x00007f495ae9c130 in cpu_outw (addr=49200, val=2) at /root/work/xen/tools/qemu-xen-dir/ioport.c:77
> >> #20 0x00007f495af289d0 in do_outp (addr=49200, size=2, val=2) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:668
> >> #21 0x00007f495af28b94 in cpu_ioreq_pio (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:729
> >> #22 0x00007f495af28ee5 in handle_ioreq (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:781
> >> #23 0x00007f495af29237 in cpu_handle_ioreq (opaque=0x7f495b884ad0) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:856
> >> #24 0x00007f495ad7d2c2 in qemu_iohandler_poll (pollfds=0x7f495b823820, ret=1) at iohandler.c:143
> >> #25 0x00007f495ad7e2fd in main_loop_wait (nonblocking=0) at main-loop.c:485
> >> #26 0x00007f495ae1386f in main_loop () at vl.c:2056
> >> #27 0x00007f495ae1af17 in main (argc=35, argv=0x7fff564e94c8, envp=0x7fff564e95e8) at vl.c:4535
> >> (gdb) q
> >>
> >>
> > Added qemu-devel and qemu maintainer in xen to cc.
> > 
> > @Wen Congyang: when you report a bug is useful add more details and logs, domU's xl cfg, domU's qemu log, xen and qemu version used ecc...
> > .
> > 
> 
> The config file is not backuped before changing. I remember I only change vcpus and nic model.
> Here is the config file:
> ===================================================
> builder='hvm'
> 
> memory = 2048
> vcpus=2
> cpus="3"
> 
> name = "hvm_nopv"
> 
> disk = [ 'format=raw,devtype=disk,access=w,vdev=hda,target=/data/images/xen/hvm_nopv/suse/hvm.img'
> #      , 'format=raw,devtype=disk,access=w,vdev=hdb,target=/data/images/xen/hvm_nopv/suse/hvm_data.img'
>        ]
> 
> vif = [ 'mac=00:16:4f:00:00:11, bridge=br0, model=virtio-net' ]
> 
> #-----------------------------------------------------------------------------
> # boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d)
> # default: hard disk, cd-rom, floppy
> boot="c"
> 
> sdl=0
> 
> vnc=1
> 
> vnclisten='0.0.0.0'
> 
> vncunused = 1
> 
> stdvga = 0
> 
> serial='pty'
> 
> apic=1
> apci=1
> pae=1
> 
> extid=0
> keymap="en-us"
> localtime=1
> hpet=1
> 
> usbdevice='tablet'
> 
> xen_platform_pci=0
> ===================================================
> 
> qemu log(/var/log/xen/qemu-xxx):
> char device redirected to /dev/pts/2 (label serial0)
> xen_ram_addr_from_mapcache, could not find 0x7f267bd828e8
> 
> qemu version:
> qemu-upstream-unstable:
> http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=summary
> commit: ca78cc83650b535d7e24baeaea32947be0141534
> 
> xl: not the newest, commit c90a755f261b8ccb3dac7e1f695122cac95c6053. I change
> some codes(remus related/suspend/resume...)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:23:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15: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.xen.org>)
	id 1XsvTy-0000hR-Nz; Mon, 24 Nov 2014 15:23:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XsvTx-0000hG-8j
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 15:23:17 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	20/76-25547-46D43745; Mon, 24 Nov 2014 15:23:16 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416842592!9044044!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17677 invoked from network); 24 Nov 2014 15:23:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 15:23:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196112984"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 10:23:09 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XsvTp-0001Yb-IO;
	Mon, 24 Nov 2014 15:23:09 +0000
Date: Mon, 24 Nov 2014 15:23:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Wen Congyang <wency@cn.fujitsu.com>
In-Reply-To: <5472F980.6030208@cn.fujitsu.com>
Message-ID: <alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	xen devel <xen-devel@lists.xen.org>, Fabio Fantoni <fabio.fantoni@m2r.biz>,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] qemu crash with virtio on Xen domUs (backtrace
	included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CC'ing Paolo.


Wen,
thanks for the logs.

I investigated a little bit and it seems to me that the bug occurs when
QEMU tries to unmap only a portion of a memory region previously mapped.
That doesn't work with xen-mapcache.

See these logs for example:

DEBUG address_space_map phys_addr=78ed8b44 vaddr=7f9609bedb44 len=0xa
DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6

that leads to the error:

xen_ram_addr_from_mapcache, could not find 0x7fab50afbb68


Paolo, do you know why virtio would call address_space_unmap with a
different set of arguments compared to the previous address_space_map
call?


On Mon, 24 Nov 2014, Wen Congyang wrote:
> On 11/24/2014 04:52 PM, Fabio Fantoni wrote:
> > Il 24/11/2014 02:58, Wen Congyang ha scritto:
> >> When I try to use virtio on xen(HVM guest), qemu crashed. Here is the backtrace:
> >> (gdb) bt
> >> #0  0x00007f49581f0b55 in raise () from /lib64/libc.so.6
> >> #1  0x00007f49581f2131 in abort () from /lib64/libc.so.6
> >> #2  0x00007f495af2af32 in xen_ram_addr_from_mapcache (ptr=0x7f4951858ac8) at /root/work/xen/tools/qemu-xen-dir/xen-mapcache.c:316
> >> #3  0x00007f495ae30fb3 in qemu_ram_addr_from_host (ptr=0x7f4951858ac8, ram_addr=0x7fff564dc9b0) at /root/work/xen/tools/qemu-xen-dir/exec.c:1508
> >> #4  0x00007f495ae33424 in address_space_unmap (as=0x7f495b7c3520, buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2315
> >> #5  0x00007f495ae335b3 in cpu_physical_memory_unmap (buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2353
> >> #6  0x00007f495ae9058d in virtqueue_fill (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1, idx=0) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:258
> >> #7  0x00007f495ae90a0d in virtqueue_push (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:286
> >> #8  0x00007f495ae82cf3 in virtio_net_handle_ctrl (vdev=0x7f495b92a5d0, vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/net/virtio-net.c:806
> >> #9  0x00007f495ae925e5 in virtio_queue_notify_vq (vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:729
> >> #10 0x00007f495ae926c3 in virtio_queue_notify (vdev=0x7f495b92a5d0, n=2) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:735
> >> #11 0x00007f495ad743c2 in virtio_ioport_write (opaque=0x7f495b929cd0, addr=16, val=2) at hw/virtio/virtio-pci.c:301
> >> #12 0x00007f495ad74923 in virtio_pci_config_write (opaque=0x7f495b929cd0, addr=16, val=2, size=2) at hw/virtio/virtio-pci.c:433
> >> #13 0x00007f495ae9f071 in memory_region_write_accessor (mr=0x7f495b92a468, addr=16, value=0x7fff564e8d08, size=2, shift=0, mask=65535) at /root/work/xen/tools/qemu-xen-dir/memory.c:441
> >> #14 0x00007f495ae9f1ad in access_with_adjusted_size (addr=16, value=0x7fff564e8d08, size=2, access_size_min=1, access_size_max=4, access=0x7f495ae9efe8 <memory_region_write_accessor>, mr=0x7f495b92a468)
> >>      at /root/work/xen/tools/qemu-xen-dir/memory.c:478
> >> #15 0x00007f495aea200e in memory_region_dispatch_write (mr=0x7f495b92a468, addr=16, data=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:985
> >> #16 0x00007f495aea5824 in io_mem_write (mr=0x7f495b92a468, addr=16, val=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:1744
> >> #17 0x00007f495ae328d3 in address_space_rw (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2, is_write=true) at /root/work/xen/tools/qemu-xen-dir/exec.c:2029
> >> #18 0x00007f495ae32c85 in address_space_write (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2) at /root/work/xen/tools/qemu-xen-dir/exec.c:2091
> >> #19 0x00007f495ae9c130 in cpu_outw (addr=49200, val=2) at /root/work/xen/tools/qemu-xen-dir/ioport.c:77
> >> #20 0x00007f495af289d0 in do_outp (addr=49200, size=2, val=2) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:668
> >> #21 0x00007f495af28b94 in cpu_ioreq_pio (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:729
> >> #22 0x00007f495af28ee5 in handle_ioreq (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:781
> >> #23 0x00007f495af29237 in cpu_handle_ioreq (opaque=0x7f495b884ad0) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:856
> >> #24 0x00007f495ad7d2c2 in qemu_iohandler_poll (pollfds=0x7f495b823820, ret=1) at iohandler.c:143
> >> #25 0x00007f495ad7e2fd in main_loop_wait (nonblocking=0) at main-loop.c:485
> >> #26 0x00007f495ae1386f in main_loop () at vl.c:2056
> >> #27 0x00007f495ae1af17 in main (argc=35, argv=0x7fff564e94c8, envp=0x7fff564e95e8) at vl.c:4535
> >> (gdb) q
> >>
> >>
> > Added qemu-devel and qemu maintainer in xen to cc.
> > 
> > @Wen Congyang: when you report a bug is useful add more details and logs, domU's xl cfg, domU's qemu log, xen and qemu version used ecc...
> > .
> > 
> 
> The config file is not backuped before changing. I remember I only change vcpus and nic model.
> Here is the config file:
> ===================================================
> builder='hvm'
> 
> memory = 2048
> vcpus=2
> cpus="3"
> 
> name = "hvm_nopv"
> 
> disk = [ 'format=raw,devtype=disk,access=w,vdev=hda,target=/data/images/xen/hvm_nopv/suse/hvm.img'
> #      , 'format=raw,devtype=disk,access=w,vdev=hdb,target=/data/images/xen/hvm_nopv/suse/hvm_data.img'
>        ]
> 
> vif = [ 'mac=00:16:4f:00:00:11, bridge=br0, model=virtio-net' ]
> 
> #-----------------------------------------------------------------------------
> # boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d)
> # default: hard disk, cd-rom, floppy
> boot="c"
> 
> sdl=0
> 
> vnc=1
> 
> vnclisten='0.0.0.0'
> 
> vncunused = 1
> 
> stdvga = 0
> 
> serial='pty'
> 
> apic=1
> apci=1
> pae=1
> 
> extid=0
> keymap="en-us"
> localtime=1
> hpet=1
> 
> usbdevice='tablet'
> 
> xen_platform_pci=0
> ===================================================
> 
> qemu log(/var/log/xen/qemu-xxx):
> char device redirected to /dev/pts/2 (label serial0)
> xen_ram_addr_from_mapcache, could not find 0x7f267bd828e8
> 
> qemu version:
> qemu-upstream-unstable:
> http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=summary
> commit: ca78cc83650b535d7e24baeaea32947be0141534
> 
> xl: not the newest, commit c90a755f261b8ccb3dac7e1f695122cac95c6053. I change
> some codes(remus related/suspend/resume...)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:24:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:24:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvVH-0000pJ-82; Mon, 24 Nov 2014 15:24:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XsvVF-0000p9-4H
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 15:24:37 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	49/47-02957-4BD43745; Mon, 24 Nov 2014 15:24:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416842672!9072269!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18256 invoked from network); 24 Nov 2014 15:24:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 15:24:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195307846"
Message-ID: <1416842562.8878.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon, 24 Nov 2014 15:22:42 +0000
In-Reply-To: <54734A33.6040600@citrix.com>
References: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
	<54734A33.6040600@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Zhuan Chen <zhuanchen@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Building 32-bit xen.efi for 32-bit EFI 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

On Mon, 2014-11-24 at 15:09 +0000, Andrew Cooper wrote:
> On 24/11/14 14:59, Zhuan Chen wrote:
> > Hi,
> >
> > I am wondering whether it's possible to build 32-bit xen.efi for the
> > 32-bit EFI platform? One way of building xen.efi I learnt is to make
> > the binutils configured with the x86_64-pep emulation (according to
> > the document http://xenbits.xenproject.org/docs/unstable/misc/efi.html).
> > The resulted xen.efi is 64-bit mode. Is it possible to build xen.efi
> > as the 32-bit mode?
> >
> > The reason for this question is due to my effort of installing Xen on
> > the Asus Transformer Book T100, which is one of the Bay Trail Atom
> > (64-bit processors) tablets shipped with 32-bit EFI firmware. This
> > requires the support of the 32-bit EFI bootloader. Such platforms seem
> > to become common and Linux kernel from 3.15 also provides the EFI
> > mixed mode to support 64-bit kernels running from 32-bit EFI firmware.
> >
> > Thanks,
> > Zhuan
> 
> 32bit Xen support was removed in Xen 4.3, so building a pure 32bit
> hypervisor is not possible.

That's not what was asked for.

> There is an argument to be made for building a 32bit Xen.efi which is
> bootable by a 32bit firmware and moves into 64bit mode on boot.

This was.

> There is however no support for this that I am aware of.

Me neither.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:24:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:24:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvVH-0000pJ-82; Mon, 24 Nov 2014 15:24:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XsvVF-0000p9-4H
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 15:24:37 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	49/47-02957-4BD43745; Mon, 24 Nov 2014 15:24:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1416842672!9072269!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18256 invoked from network); 24 Nov 2014 15:24:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 15:24:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195307846"
Message-ID: <1416842562.8878.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon, 24 Nov 2014 15:22:42 +0000
In-Reply-To: <54734A33.6040600@citrix.com>
References: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
	<54734A33.6040600@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Zhuan Chen <zhuanchen@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Building 32-bit xen.efi for 32-bit EFI 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

On Mon, 2014-11-24 at 15:09 +0000, Andrew Cooper wrote:
> On 24/11/14 14:59, Zhuan Chen wrote:
> > Hi,
> >
> > I am wondering whether it's possible to build 32-bit xen.efi for the
> > 32-bit EFI platform? One way of building xen.efi I learnt is to make
> > the binutils configured with the x86_64-pep emulation (according to
> > the document http://xenbits.xenproject.org/docs/unstable/misc/efi.html).
> > The resulted xen.efi is 64-bit mode. Is it possible to build xen.efi
> > as the 32-bit mode?
> >
> > The reason for this question is due to my effort of installing Xen on
> > the Asus Transformer Book T100, which is one of the Bay Trail Atom
> > (64-bit processors) tablets shipped with 32-bit EFI firmware. This
> > requires the support of the 32-bit EFI bootloader. Such platforms seem
> > to become common and Linux kernel from 3.15 also provides the EFI
> > mixed mode to support 64-bit kernels running from 32-bit EFI firmware.
> >
> > Thanks,
> > Zhuan
> 
> 32bit Xen support was removed in Xen 4.3, so building a pure 32bit
> hypervisor is not possible.

That's not what was asked for.

> There is an argument to be made for building a 32bit Xen.efi which is
> bootable by a 32bit firmware and moves into 64bit mode on boot.

This was.

> There is however no support for this that I am aware of.

Me neither.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:26:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvX3-00010I-0V; Mon, 24 Nov 2014 15:26:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XsvX2-00010B-4I
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 15:26:28 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	D3/CB-03148-32E43745; Mon, 24 Nov 2014 15:26:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416842769!13918318!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32667 invoked from network); 24 Nov 2014 15:26:12 -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;
	24 Nov 2014 15:26:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196114362"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 10:26:07 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XsvWh-0001bw-6m;
	Mon, 24 Nov 2014 15:26:07 +0000
Date: Mon, 24 Nov 2014 15:26:04 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141124150649.GB3946@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
References: <1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
	<20141124150649.GB3946@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
> > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > > > > > The rom is used for pxebooting. We don't need to allow pxebooting from
> > > > > > more than one network card.  Loading a romfile for every NIC wastes
> > > > > 
> > > > > Why not? Why can't we PXE boot from each network card?
> > > > 
> > > > I take it back: you are right, at the moment it is actually possible to
> > > > pxe boot from the fourth nic for example. Maybe we could just load the
> > > > first four romfiles and skip the others (four is the limit before QEMU
> > > > fails to allocate any more memory).
> > > 
> > > The limit is in the count of ROMs or the memory consumption?
> > 
> > The limit is memory consumption.
> 
> Um, how big are those ROMs? Gigs?

I think they are 60K each in the case of rtl8139.
However they are accounted on top of the ram of the guest, that's why
the allocation fails. Strictly speaking I guess it shouldn't work even
the first time around.

Maybe the bug is in libxl memory allocation, that doesn't account for
rom sizes.


> > > What if you also do PCI passthrough? Does that figure in this calculation?
> > 
> > In the case of PCI passthrough, roms are remapped, so they shouldn't
> > affect memory consumption.
> > 
> >  
> > > > TBH not all the emulated nics need a romfile but I wouldn't want to go
> > > > down at that level of details beause they become QEMU implementation
> > > > details. I wouldn't want to tie libxl to a certain version of QEMU in
> > > > any way.
> > > > 
> > > > A better way would be handling memory allocation errors in QEMU but QEMU
> > > > doesn't do that at the moment and the change there would be certainly
> > > > more invasive that a couple of lines in libxl.
> > > > 
> > > > 
> > > > > > memory and as a matter of fact breaks configurations with more than 4
> > > > > > NICs as QEMU fails to allocate memory on behalf of the guest.
> > > > > 
> > > > > What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> > > > > and ne2k ?
> > > > > 
> > > > > Don't you want to load the ROM for each one?
> > > > 
> > > > The rom cannot be reused in QEMU among multiple instances of the same
> > > > nic, so having four different types of nics or just one type doesn't
> > > > change anything.
> > > > 
> > > > 
> > > > > > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > > > > > guest.
> > > > > > 
> > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > 
> > > > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > > > index 3e191c3..f907ca9 100644
> > > > > > --- a/tools/libxl/libxl_dm.c
> > > > > > +++ b/tools/libxl/libxl_dm.c
> > > > > > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > > > >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> > > > > >                  flexarray_append(dm_args, "-device");
> > > > > >                  flexarray_append(dm_args,
> > > > > > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > > > > > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> > > > > >                                                  nics[i].model, nics[i].devid,
> > > > > > -                                                nics[i].devid, smac));
> > > > > > +                                                nics[i].devid, smac,
> > > > > > +                                                i ? ",romfile=\"\"" : ""));
> > > > > >                  flexarray_append(dm_args, "-netdev");
> > > > > >                  flexarray_append(dm_args, GCSPRINTF(
> > > > > >                                            "type=tap,id=net%d,ifname=%s,"
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Xen-devel mailing list
> > > > > > Xen-devel@lists.xen.org
> > > > > > http://lists.xen.org/xen-devel
> > > > > 
> > > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:26:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvX3-00010I-0V; Mon, 24 Nov 2014 15:26:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XsvX2-00010B-4I
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 15:26:28 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	D3/CB-03148-32E43745; Mon, 24 Nov 2014 15:26:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416842769!13918318!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32667 invoked from network); 24 Nov 2014 15:26:12 -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;
	24 Nov 2014 15:26:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196114362"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 10:26:07 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XsvWh-0001bw-6m;
	Mon, 24 Nov 2014 15:26:07 +0000
Date: Mon, 24 Nov 2014 15:26:04 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141124150649.GB3946@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
References: <1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
	<20141124150649.GB3946@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
> > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > > > > > The rom is used for pxebooting. We don't need to allow pxebooting from
> > > > > > more than one network card.  Loading a romfile for every NIC wastes
> > > > > 
> > > > > Why not? Why can't we PXE boot from each network card?
> > > > 
> > > > I take it back: you are right, at the moment it is actually possible to
> > > > pxe boot from the fourth nic for example. Maybe we could just load the
> > > > first four romfiles and skip the others (four is the limit before QEMU
> > > > fails to allocate any more memory).
> > > 
> > > The limit is in the count of ROMs or the memory consumption?
> > 
> > The limit is memory consumption.
> 
> Um, how big are those ROMs? Gigs?

I think they are 60K each in the case of rtl8139.
However they are accounted on top of the ram of the guest, that's why
the allocation fails. Strictly speaking I guess it shouldn't work even
the first time around.

Maybe the bug is in libxl memory allocation, that doesn't account for
rom sizes.


> > > What if you also do PCI passthrough? Does that figure in this calculation?
> > 
> > In the case of PCI passthrough, roms are remapped, so they shouldn't
> > affect memory consumption.
> > 
> >  
> > > > TBH not all the emulated nics need a romfile but I wouldn't want to go
> > > > down at that level of details beause they become QEMU implementation
> > > > details. I wouldn't want to tie libxl to a certain version of QEMU in
> > > > any way.
> > > > 
> > > > A better way would be handling memory allocation errors in QEMU but QEMU
> > > > doesn't do that at the moment and the change there would be certainly
> > > > more invasive that a couple of lines in libxl.
> > > > 
> > > > 
> > > > > > memory and as a matter of fact breaks configurations with more than 4
> > > > > > NICs as QEMU fails to allocate memory on behalf of the guest.
> > > > > 
> > > > > What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> > > > > and ne2k ?
> > > > > 
> > > > > Don't you want to load the ROM for each one?
> > > > 
> > > > The rom cannot be reused in QEMU among multiple instances of the same
> > > > nic, so having four different types of nics or just one type doesn't
> > > > change anything.
> > > > 
> > > > 
> > > > > > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > > > > > guest.
> > > > > > 
> > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > 
> > > > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > > > index 3e191c3..f907ca9 100644
> > > > > > --- a/tools/libxl/libxl_dm.c
> > > > > > +++ b/tools/libxl/libxl_dm.c
> > > > > > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > > > >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> > > > > >                  flexarray_append(dm_args, "-device");
> > > > > >                  flexarray_append(dm_args,
> > > > > > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > > > > > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> > > > > >                                                  nics[i].model, nics[i].devid,
> > > > > > -                                                nics[i].devid, smac));
> > > > > > +                                                nics[i].devid, smac,
> > > > > > +                                                i ? ",romfile=\"\"" : ""));
> > > > > >                  flexarray_append(dm_args, "-netdev");
> > > > > >                  flexarray_append(dm_args, GCSPRINTF(
> > > > > >                                            "type=tap,id=net%d,ifname=%s,"
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Xen-devel mailing list
> > > > > > Xen-devel@lists.xen.org
> > > > > > http://lists.xen.org/xen-devel
> > > > > 
> > > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:45:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:45:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsvpc-0001VF-T7; Mon, 24 Nov 2014 15:45:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xsvpb-0001VA-LY
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 15:45:39 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	C3/65-20609-3A253745; Mon, 24 Nov 2014 15:45:39 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416843936!14509163!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12491 invoked from network); 24 Nov 2014 15:45:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:45:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOFjSEn016805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:45:29 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFjRiS019526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 15:45:28 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFjRi5012174; Mon, 24 Nov 2014 15:45:27 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:45:26 -0800
Message-ID: <54735343.1020208@oracle.com>
Date: Mon, 24 Nov 2014 10:48:19 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
In-Reply-To: <20141124104703.GH30053@zion.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: ian.campbell@citrix.com, Dario Faggioli <dario.faggioli@citrix.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 05:47 AM, Wei Liu wrote:
> CC'ing Dario...
>
> On Mon, Nov 24, 2014 at 10:41:27AM +0000, Wei Liu wrote:
>> On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
>>> When parsing bitmap objects JSON parser will create libxl_bitmap
>>> map of the smallest size needed.
>>>
>>> This can cause problems when saved image file specifies CPU affinity.
>>> For example, if 'vcpu_hard_affinity' in the saved image has only the
>>> first CPU specified, just a single byte will be allocated and
>>> libxl_bitmap->size will be set to 1.
>>>
>>> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
>>> since the destination bitmap is created for maximum number of CPUs.
>>>
>>> We could allocate that bitmap of the same size as the source, however,
>>> it is later passed to xc_vcpu_setaffinity() which expects it to be
>>> sized to the max number of CPUs
>>>
>>> Instead, we should allow copying the (smaller) bitmap read by the parser
>>> and keep the rest of bytes in the destination map unmodified (zero in
>>> this case)
>>>
>> Here is some more thoughts on this issue:
>>
>> This API is used by VCPU placement and NUMA placement logic in libxl. To
>> fix the breakage, we don't necessary need to expose new API or change
>> API behaviour, we only need to have a internal function to do it.
>>
>> The reversed case (large bitmap to small one) is not valid in libxl, as
>> in the pinning will fail. But bitmap copy happens before that, we would
>> still need to deal with that. Dario, can you provide some input on
>> the expected behaviour?

I understand that hypervisor will ignore bits that are beyond what it 
knows about --- see xenctl_bitmap_to_bitmap(). And libxl will will issue 
a warning. But only if byte-sized bitmaps are the same. If they are not 
will will pop the assertion (in debug builds).

>>
>> The partial copy function should explicitly zero-out all remaining bits.

I actually thought that partial copy function should do just that --- 
copy bits that it has and leave others unchanged. The caller, if desires 
so, should have cleared the mask prior to the call. (This is for the 
case when destination is larger than source, of course).


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:45:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:45:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsvpc-0001VF-T7; Mon, 24 Nov 2014 15:45:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xsvpb-0001VA-LY
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 15:45:39 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	C3/65-20609-3A253745; Mon, 24 Nov 2014 15:45:39 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416843936!14509163!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12491 invoked from network); 24 Nov 2014 15:45:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:45:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOFjSEn016805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:45:29 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFjRiS019526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 15:45:28 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFjRi5012174; Mon, 24 Nov 2014 15:45:27 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:45:26 -0800
Message-ID: <54735343.1020208@oracle.com>
Date: Mon, 24 Nov 2014 10:48:19 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
In-Reply-To: <20141124104703.GH30053@zion.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: ian.campbell@citrix.com, Dario Faggioli <dario.faggioli@citrix.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 05:47 AM, Wei Liu wrote:
> CC'ing Dario...
>
> On Mon, Nov 24, 2014 at 10:41:27AM +0000, Wei Liu wrote:
>> On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
>>> When parsing bitmap objects JSON parser will create libxl_bitmap
>>> map of the smallest size needed.
>>>
>>> This can cause problems when saved image file specifies CPU affinity.
>>> For example, if 'vcpu_hard_affinity' in the saved image has only the
>>> first CPU specified, just a single byte will be allocated and
>>> libxl_bitmap->size will be set to 1.
>>>
>>> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
>>> since the destination bitmap is created for maximum number of CPUs.
>>>
>>> We could allocate that bitmap of the same size as the source, however,
>>> it is later passed to xc_vcpu_setaffinity() which expects it to be
>>> sized to the max number of CPUs
>>>
>>> Instead, we should allow copying the (smaller) bitmap read by the parser
>>> and keep the rest of bytes in the destination map unmodified (zero in
>>> this case)
>>>
>> Here is some more thoughts on this issue:
>>
>> This API is used by VCPU placement and NUMA placement logic in libxl. To
>> fix the breakage, we don't necessary need to expose new API or change
>> API behaviour, we only need to have a internal function to do it.
>>
>> The reversed case (large bitmap to small one) is not valid in libxl, as
>> in the pinning will fail. But bitmap copy happens before that, we would
>> still need to deal with that. Dario, can you provide some input on
>> the expected behaviour?

I understand that hypervisor will ignore bits that are beyond what it 
knows about --- see xenctl_bitmap_to_bitmap(). And libxl will will issue 
a warning. But only if byte-sized bitmaps are the same. If they are not 
will will pop the assertion (in debug builds).

>>
>> The partial copy function should explicitly zero-out all remaining bits.

I actually thought that partial copy function should do just that --- 
copy bits that it has and leave others unchanged. The caller, if desires 
so, should have cleared the mask prior to the call. (This is for the 
case when destination is larger than source, of course).


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:47:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvrA-0001Zb-CG; Mon, 24 Nov 2014 15:47:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xsvr8-0001ZU-4l
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 15:47:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E7/B7-25276-10353745; Mon, 24 Nov 2014 15:47:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416844031!14968875!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8924 invoked from network); 24 Nov 2014 15:47:12 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:47:12 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOFksh2030771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:46:55 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFkreL024408
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 15:46:54 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFkrYB020098; Mon, 24 Nov 2014 15:46:53 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:46:52 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7C0D91192E1; Mon, 24 Nov 2014 10:46:51 -0500 (EST)
Date: Mon, 24 Nov 2014 10:46:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141124154651.GA5988@laptop.dumpdata.com>
References: <1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
	<20141124150649.GB3946@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 03:26:04PM +0000, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
> > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> > > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > > > > > > The rom is used for pxebooting. We don't need to allow pxebooting from
> > > > > > > more than one network card.  Loading a romfile for every NIC wastes
> > > > > > 
> > > > > > Why not? Why can't we PXE boot from each network card?
> > > > > 
> > > > > I take it back: you are right, at the moment it is actually possible to
> > > > > pxe boot from the fourth nic for example. Maybe we could just load the
> > > > > first four romfiles and skip the others (four is the limit before QEMU
> > > > > fails to allocate any more memory).
> > > > 
> > > > The limit is in the count of ROMs or the memory consumption?
> > > 
> > > The limit is memory consumption.
> > 
> > Um, how big are those ROMs? Gigs?
> 
> I think they are 60K each in the case of rtl8139.
> However they are accounted on top of the ram of the guest, that's why
> the allocation fails. Strictly speaking I guess it shouldn't work even
> the first time around.

HA!
> 
> Maybe the bug is in libxl memory allocation, that doesn't account for
> rom sizes.

Or maybe the VGA hole size calculation is used for this. Anyhow, why aren't
we using the guest memory as instead of increasing the memory. Or is
this just an accounting issue in QEMU?
> 
> 
> > > > What if you also do PCI passthrough? Does that figure in this calculation?
> > > 
> > > In the case of PCI passthrough, roms are remapped, so they shouldn't
> > > affect memory consumption.
> > > 
> > >  
> > > > > TBH not all the emulated nics need a romfile but I wouldn't want to go
> > > > > down at that level of details beause they become QEMU implementation
> > > > > details. I wouldn't want to tie libxl to a certain version of QEMU in
> > > > > any way.
> > > > > 
> > > > > A better way would be handling memory allocation errors in QEMU but QEMU
> > > > > doesn't do that at the moment and the change there would be certainly
> > > > > more invasive that a couple of lines in libxl.
> > > > > 
> > > > > 
> > > > > > > memory and as a matter of fact breaks configurations with more than 4
> > > > > > > NICs as QEMU fails to allocate memory on behalf of the guest.
> > > > > > 
> > > > > > What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> > > > > > and ne2k ?
> > > > > > 
> > > > > > Don't you want to load the ROM for each one?
> > > > > 
> > > > > The rom cannot be reused in QEMU among multiple instances of the same
> > > > > nic, so having four different types of nics or just one type doesn't
> > > > > change anything.
> > > > > 
> > > > > 
> > > > > > > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > > > > > > guest.
> > > > > > > 
> > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > > 
> > > > > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > > > > index 3e191c3..f907ca9 100644
> > > > > > > --- a/tools/libxl/libxl_dm.c
> > > > > > > +++ b/tools/libxl/libxl_dm.c
> > > > > > > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > > > > >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> > > > > > >                  flexarray_append(dm_args, "-device");
> > > > > > >                  flexarray_append(dm_args,
> > > > > > > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > > > > > > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> > > > > > >                                                  nics[i].model, nics[i].devid,
> > > > > > > -                                                nics[i].devid, smac));
> > > > > > > +                                                nics[i].devid, smac,
> > > > > > > +                                                i ? ",romfile=\"\"" : ""));
> > > > > > >                  flexarray_append(dm_args, "-netdev");
> > > > > > >                  flexarray_append(dm_args, GCSPRINTF(
> > > > > > >                                            "type=tap,id=net%d,ifname=%s,"
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Xen-devel mailing list
> > > > > > > Xen-devel@lists.xen.org
> > > > > > > http://lists.xen.org/xen-devel
> > > > > > 
> > > > 
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 15:47:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 15:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsvrA-0001Zb-CG; Mon, 24 Nov 2014 15:47:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xsvr8-0001ZU-4l
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 15:47:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E7/B7-25276-10353745; Mon, 24 Nov 2014 15:47:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416844031!14968875!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8924 invoked from network); 24 Nov 2014 15:47:12 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 15:47:12 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOFksh2030771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 15:46:55 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFkreL024408
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 15:46:54 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOFkrYB020098; Mon, 24 Nov 2014 15:46:53 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 07:46:52 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7C0D91192E1; Mon, 24 Nov 2014 10:46:51 -0500 (EST)
Date: Mon, 24 Nov 2014 10:46:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141124154651.GA5988@laptop.dumpdata.com>
References: <1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
	<20141124150649.GB3946@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 03:26:04PM +0000, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
> > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> > > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
> > > > > > > The rom is used for pxebooting. We don't need to allow pxebooting from
> > > > > > > more than one network card.  Loading a romfile for every NIC wastes
> > > > > > 
> > > > > > Why not? Why can't we PXE boot from each network card?
> > > > > 
> > > > > I take it back: you are right, at the moment it is actually possible to
> > > > > pxe boot from the fourth nic for example. Maybe we could just load the
> > > > > first four romfiles and skip the others (four is the limit before QEMU
> > > > > fails to allocate any more memory).
> > > > 
> > > > The limit is in the count of ROMs or the memory consumption?
> > > 
> > > The limit is memory consumption.
> > 
> > Um, how big are those ROMs? Gigs?
> 
> I think they are 60K each in the case of rtl8139.
> However they are accounted on top of the ram of the guest, that's why
> the allocation fails. Strictly speaking I guess it shouldn't work even
> the first time around.

HA!
> 
> Maybe the bug is in libxl memory allocation, that doesn't account for
> rom sizes.

Or maybe the VGA hole size calculation is used for this. Anyhow, why aren't
we using the guest memory as instead of increasing the memory. Or is
this just an accounting issue in QEMU?
> 
> 
> > > > What if you also do PCI passthrough? Does that figure in this calculation?
> > > 
> > > In the case of PCI passthrough, roms are remapped, so they shouldn't
> > > affect memory consumption.
> > > 
> > >  
> > > > > TBH not all the emulated nics need a romfile but I wouldn't want to go
> > > > > down at that level of details beause they become QEMU implementation
> > > > > details. I wouldn't want to tie libxl to a certain version of QEMU in
> > > > > any way.
> > > > > 
> > > > > A better way would be handling memory allocation errors in QEMU but QEMU
> > > > > doesn't do that at the moment and the change there would be certainly
> > > > > more invasive that a couple of lines in libxl.
> > > > > 
> > > > > 
> > > > > > > memory and as a matter of fact breaks configurations with more than 4
> > > > > > > NICs as QEMU fails to allocate memory on behalf of the guest.
> > > > > > 
> > > > > > What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
> > > > > > and ne2k ?
> > > > > > 
> > > > > > Don't you want to load the ROM for each one?
> > > > > 
> > > > > The rom cannot be reused in QEMU among multiple instances of the same
> > > > > nic, so having four different types of nics or just one type doesn't
> > > > > change anything.
> > > > > 
> > > > > 
> > > > > > > With this fix, it is possible to assign more than 4 rtl8139 NICs to the
> > > > > > > guest.
> > > > > > > 
> > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > > 
> > > > > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > > > > index 3e191c3..f907ca9 100644
> > > > > > > --- a/tools/libxl/libxl_dm.c
> > > > > > > +++ b/tools/libxl/libxl_dm.c
> > > > > > > @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > > > > >                                                  LIBXL_NIC_TYPE_VIF_IOEMU);
> > > > > > >                  flexarray_append(dm_args, "-device");
> > > > > > >                  flexarray_append(dm_args,
> > > > > > > -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
> > > > > > > +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
> > > > > > >                                                  nics[i].model, nics[i].devid,
> > > > > > > -                                                nics[i].devid, smac));
> > > > > > > +                                                nics[i].devid, smac,
> > > > > > > +                                                i ? ",romfile=\"\"" : ""));
> > > > > > >                  flexarray_append(dm_args, "-netdev");
> > > > > > >                  flexarray_append(dm_args, GCSPRINTF(
> > > > > > >                                            "type=tap,id=net%d,ifname=%s,"
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Xen-devel mailing list
> > > > > > > Xen-devel@lists.xen.org
> > > > > > > http://lists.xen.org/xen-devel
> > > > > > 
> > > > 
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:07:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16: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 1XswAX-0002OQ-Bo; Mon, 24 Nov 2014 16:07:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XswAW-0002OL-Fb
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 16:07:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BC/89-15461-3B753745; Mon, 24 Nov 2014 16:07:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416845233!14975871!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16157 invoked from network); 24 Nov 2014 16:07:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 16:07:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195336516"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 11:04:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xsw7N-0004qK-HZ;
	Mon, 24 Nov 2014 16:04:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xsw7L-0008Al-7r;
	Mon, 24 Nov 2014 16:03:59 +0000
Date: Mon, 24 Nov 2014 16:03:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31817-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31817: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31817 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31817/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 33063 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 Nov 24 16:07:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16: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 1XswAX-0002OQ-Bo; Mon, 24 Nov 2014 16:07:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XswAW-0002OL-Fb
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 16:07:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BC/89-15461-3B753745; Mon, 24 Nov 2014 16:07:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416845233!14975871!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16157 invoked from network); 24 Nov 2014 16:07:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 16:07:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195336516"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Mon, 24 Nov 2014 11:04:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xsw7N-0004qK-HZ;
	Mon, 24 Nov 2014 16:04:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xsw7L-0008Al-7r;
	Mon, 24 Nov 2014 16:03:59 +0000
Date: Mon, 24 Nov 2014 16:03:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31817-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31817: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31817 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31817/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 33063 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 Nov 24 16:09:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswCZ-0002UX-1Z; Mon, 24 Nov 2014 16:09:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XswCX-0002US-Ps
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 16:09:22 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	F1/19-02697-13853745; Mon, 24 Nov 2014 16:09:21 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416845358!7660759!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12440 invoked from network); 24 Nov 2014 16:09:20 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 16:09:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416845360; x=1448381360;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=+wV11O2yWLBsyH3rOhGWDzFlb0xV2TcvVj8v9sBSpdI=;
	b=XIKklCuFyssgv0Daj159zTPB5jCTRXnEju+jb+u3esfKrHcCQu4Tdst5
	uYku5NCtxq3ccNf2vDvbfwkkOEzqGTyfNtI7TN7HKRh4Vha6EhY844P3/
	1GGy3/5S/1mvHboM3DY1Ex9PjrGZkqjh/ruK2o5EZKKL3ix16NoJK4K5c w=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 24 Nov 2014 16:09:18 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="876736965"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.80])
	by fldsmtpi02.verizon.com with ESMTP; 24 Nov 2014 16:09:16 +0000
Message-ID: <5473582C.6080000@terremark.com>
Date: Mon, 24 Nov 2014 11:09:16 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1416474814.29243.59.camel@citrix.com>	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>	<1416483731.14429.8.camel@citrix.com>	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>	<1416494946.14429.13.camel@citrix.com>	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>	<20141121173437.GA14331@laptop.dumpdata.com>	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>	<20141121190757.GA16038@laptop.dumpdata.com>	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>	<20141124150649.GB3946@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/14 10:26, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
>> On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
>>> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
>>>> On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
>>>>> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
>>>>>> On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
>>>>>>> The rom is used for pxebooting. We don't need to allow pxebooting from
>>>>>>> more than one network card.  Loading a romfile for every NIC wastes
>>>>>> Why not? Why can't we PXE boot from each network card?
>>>>> I take it back: you are right, at the moment it is actually possible to
>>>>> pxe boot from the fourth nic for example. Maybe we could just load the
>>>>> first four romfiles and skip the others (four is the limit before QEMU
>>>>> fails to allocate any more memory).
>>>> The limit is in the count of ROMs or the memory consumption?
>>> The limit is memory consumption.
>> Um, how big are those ROMs? Gigs?
> I think they are 60K each in the case of rtl8139.
> However they are accounted on top of the ram of the guest, that's why
> the allocation fails. Strictly speaking I guess it shouldn't work even
> the first time around.

My extra QEMU debug says:

xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42010000 
mr.name=rtl8139.rom
e1000 vhdr enabled
xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42050000 
mr.name=e1000.rom

And that matches the max of 4.

#define LIBXL_MAXMEM_CONSTANT 1024

is what controls this.

> Maybe the bug is in libxl memory allocation, that doesn't account for
> rom sizes.

Yes.

    -Don Slutz

>
>>>> What if you also do PCI passthrough? Does that figure in this calculation?
>>> In the case of PCI passthrough, roms are remapped, so they shouldn't
>>> affect memory consumption.
>>>
>>>   
>>>>> TBH not all the emulated nics need a romfile but I wouldn't want to go
>>>>> down at that level of details beause they become QEMU implementation
>>>>> details. I wouldn't want to tie libxl to a certain version of QEMU in
>>>>> any way.
>>>>>
>>>>> A better way would be handling memory allocation errors in QEMU but QEMU
>>>>> doesn't do that at the moment and the change there would be certainly
>>>>> more invasive that a couple of lines in libxl.
>>>>>
>>>>>
>>>>>>> memory and as a matter of fact breaks configurations with more than 4
>>>>>>> NICs as QEMU fails to allocate memory on behalf of the guest.
>>>>>> What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
>>>>>> and ne2k ?
>>>>>>
>>>>>> Don't you want to load the ROM for each one?
>>>>> The rom cannot be reused in QEMU among multiple instances of the same
>>>>> nic, so having four different types of nics or just one type doesn't
>>>>> change anything.
>>>>>
>>>>>
>>>>>>> With this fix, it is possible to assign more than 4 rtl8139 NICs to the
>>>>>>> guest.
>>>>>>>
>>>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>>>>>
>>>>>>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>>>>>>> index 3e191c3..f907ca9 100644
>>>>>>> --- a/tools/libxl/libxl_dm.c
>>>>>>> +++ b/tools/libxl/libxl_dm.c
>>>>>>> @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>>>>>>>                                                   LIBXL_NIC_TYPE_VIF_IOEMU);
>>>>>>>                   flexarray_append(dm_args, "-device");
>>>>>>>                   flexarray_append(dm_args,
>>>>>>> -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
>>>>>>> +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
>>>>>>>                                                   nics[i].model, nics[i].devid,
>>>>>>> -                                                nics[i].devid, smac));
>>>>>>> +                                                nics[i].devid, smac,
>>>>>>> +                                                i ? ",romfile=\"\"" : ""));
>>>>>>>                   flexarray_append(dm_args, "-netdev");
>>>>>>>                   flexarray_append(dm_args, GCSPRINTF(
>>>>>>>                                             "type=tap,id=net%d,ifname=%s,"
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xen-devel mailing list
>>>>>>> Xen-devel@lists.xen.org
>>>>>>> http://lists.xen.org/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:09:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswCZ-0002UX-1Z; Mon, 24 Nov 2014 16:09:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XswCX-0002US-Ps
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 16:09:22 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	F1/19-02697-13853745; Mon, 24 Nov 2014 16:09:21 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1416845358!7660759!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12440 invoked from network); 24 Nov 2014 16:09:20 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 16:09:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416845360; x=1448381360;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=+wV11O2yWLBsyH3rOhGWDzFlb0xV2TcvVj8v9sBSpdI=;
	b=XIKklCuFyssgv0Daj159zTPB5jCTRXnEju+jb+u3esfKrHcCQu4Tdst5
	uYku5NCtxq3ccNf2vDvbfwkkOEzqGTyfNtI7TN7HKRh4Vha6EhY844P3/
	1GGy3/5S/1mvHboM3DY1Ex9PjrGZkqjh/ruK2o5EZKKL3ix16NoJK4K5c w=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 24 Nov 2014 16:09:18 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="876736965"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.80])
	by fldsmtpi02.verizon.com with ESMTP; 24 Nov 2014 16:09:16 +0000
Message-ID: <5473582C.6080000@terremark.com>
Date: Mon, 24 Nov 2014 11:09:16 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1416474814.29243.59.camel@citrix.com>	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>	<1416483731.14429.8.camel@citrix.com>	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>	<1416494946.14429.13.camel@citrix.com>	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>	<20141121173437.GA14331@laptop.dumpdata.com>	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>	<20141121190757.GA16038@laptop.dumpdata.com>	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>	<20141124150649.GB3946@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/14 10:26, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
>> On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
>>> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
>>>> On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
>>>>> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
>>>>>> On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini wrote:
>>>>>>> The rom is used for pxebooting. We don't need to allow pxebooting from
>>>>>>> more than one network card.  Loading a romfile for every NIC wastes
>>>>>> Why not? Why can't we PXE boot from each network card?
>>>>> I take it back: you are right, at the moment it is actually possible to
>>>>> pxe boot from the fourth nic for example. Maybe we could just load the
>>>>> first four romfiles and skip the others (four is the limit before QEMU
>>>>> fails to allocate any more memory).
>>>> The limit is in the count of ROMs or the memory consumption?
>>> The limit is memory consumption.
>> Um, how big are those ROMs? Gigs?
> I think they are 60K each in the case of rtl8139.
> However they are accounted on top of the ram of the guest, that's why
> the allocation fails. Strictly speaking I guess it shouldn't work even
> the first time around.

My extra QEMU debug says:

xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42010000 
mr.name=rtl8139.rom
e1000 vhdr enabled
xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42050000 
mr.name=e1000.rom

And that matches the max of 4.

#define LIBXL_MAXMEM_CONSTANT 1024

is what controls this.

> Maybe the bug is in libxl memory allocation, that doesn't account for
> rom sizes.

Yes.

    -Don Slutz

>
>>>> What if you also do PCI passthrough? Does that figure in this calculation?
>>> In the case of PCI passthrough, roms are remapped, so they shouldn't
>>> affect memory consumption.
>>>
>>>   
>>>>> TBH not all the emulated nics need a romfile but I wouldn't want to go
>>>>> down at that level of details beause they become QEMU implementation
>>>>> details. I wouldn't want to tie libxl to a certain version of QEMU in
>>>>> any way.
>>>>>
>>>>> A better way would be handling memory allocation errors in QEMU but QEMU
>>>>> doesn't do that at the moment and the change there would be certainly
>>>>> more invasive that a couple of lines in libxl.
>>>>>
>>>>>
>>>>>>> memory and as a matter of fact breaks configurations with more than 4
>>>>>>> NICs as QEMU fails to allocate memory on behalf of the guest.
>>>>>> What if you have four different type of NICs? Say 1 rlt8193, 1 e1000, one eepro,
>>>>>> and ne2k ?
>>>>>>
>>>>>> Don't you want to load the ROM for each one?
>>>>> The rom cannot be reused in QEMU among multiple instances of the same
>>>>> nic, so having four different types of nics or just one type doesn't
>>>>> change anything.
>>>>>
>>>>>
>>>>>>> With this fix, it is possible to assign more than 4 rtl8139 NICs to the
>>>>>>> guest.
>>>>>>>
>>>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>>>>>
>>>>>>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>>>>>>> index 3e191c3..f907ca9 100644
>>>>>>> --- a/tools/libxl/libxl_dm.c
>>>>>>> +++ b/tools/libxl/libxl_dm.c
>>>>>>> @@ -674,9 +674,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>>>>>>>                                                   LIBXL_NIC_TYPE_VIF_IOEMU);
>>>>>>>                   flexarray_append(dm_args, "-device");
>>>>>>>                   flexarray_append(dm_args,
>>>>>>> -                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
>>>>>>> +                   libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s%s",
>>>>>>>                                                   nics[i].model, nics[i].devid,
>>>>>>> -                                                nics[i].devid, smac));
>>>>>>> +                                                nics[i].devid, smac,
>>>>>>> +                                                i ? ",romfile=\"\"" : ""));
>>>>>>>                   flexarray_append(dm_args, "-netdev");
>>>>>>>                   flexarray_append(dm_args, GCSPRINTF(
>>>>>>>                                             "type=tap,id=net%d,ifname=%s,"
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xen-devel mailing list
>>>>>>> Xen-devel@lists.xen.org
>>>>>>> http://lists.xen.org/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:16:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:16:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswJR-0002mr-0I; Mon, 24 Nov 2014 16:16:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XswJP-0002mm-Cd
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 16:16:27 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	7B/E4-27785-AD953745; Mon, 24 Nov 2014 16:16:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416845781!14517000!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1424 invoked from network); 24 Nov 2014 16:16:25 -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;
	24 Nov 2014 16:16:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196142423"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 11:15:51 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XswIp-0002aQ-MH;
	Mon, 24 Nov 2014 16:15:51 +0000
Date: Mon, 24 Nov 2014 16:15:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Quan Xu <quan.xu@intel.com>
In-Reply-To: <1416802256-9928-1-git-send-email-quan.xu@intel.com>
Message-ID: <alpine.DEB.2.02.1411241544410.2675@kaball.uk.xensource.com>
References: <1416802256-9928-1-git-send-email-quan.xu@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
 frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 23 Nov 2014, Quan Xu wrote:
> This drvier transfers any request/repond between TPM xenstubdoms
> driver and Xen vTPM stubdom, and facilitates communications between
> Xen vTPM stubdom domain and vTPM xenstubdoms driver
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>

This patch needs a better description, see my past request:

http://marc.info/?l=xen-devel&m=141501570709022&w=2


>  hw/tpm/Makefile.objs         |   1 +
>  hw/tpm/xen_stubdom_vtpm.c    | 321 +++++++++++++++++++++++++++++++++++++++++++
>  hw/xen/xen_backend.c         | 272 ++++++++++++++++++++++++++++++++++++
>  include/hw/xen/xen_backend.h |  11 ++
>  include/hw/xen/xen_common.h  |   6 +
>  xen-hvm.c                    |  13 ++
>  6 files changed, 624 insertions(+)
>  create mode 100644 hw/tpm/xen_stubdom_vtpm.c
> 
> diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
> index 99f5983..87efb01 100644
> --- a/hw/tpm/Makefile.objs
> +++ b/hw/tpm/Makefile.objs
> @@ -1,2 +1,3 @@
>  common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
>  common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
> +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> diff --git a/hw/tpm/xen_stubdom_vtpm.c b/hw/tpm/xen_stubdom_vtpm.c
> new file mode 100644
> index 0000000..4fd6053
> --- /dev/null
> +++ b/hw/tpm/xen_stubdom_vtpm.c

I would just call it xen_vtpm_frontend.c

I don't think that the fact that the backend is probably run in a
stubdom is relevant here. The only thing that matter is that this is a
PV frontend.


Also if this is the vtpm specific frontend, where is the file that
introduces the generic frontend registration framework, as previously
discussed?

http://marc.info/?l=xen-devel&m=141528935207946&w=2

I think we should have a hw/xen/xen_frontend.c file, introducing
xen_fe_register etc, and a separate hw/tpm/xen_stubdom_vtpm.c with the
vtpm specific stuff.


> @@ -0,0 +1,321 @@
> +/*
> + * Connect to Xen vTPM stubdom domain
> + *
> + *  Copyright (c) 2014 Intel Corporation
> + *  Authors:
> + *    Quan Xu <quan.xu@intel.com>
> + *
> + * 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 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, see <http://www.gnu.org/licenses/>
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <stdarg.h>
> +#include <string.h>
> +#include <unistd.h>
> +#include <signal.h>
> +#include <inttypes.h>
> +#include <time.h>
> +#include <fcntl.h>
> +#include <errno.h>
> +#include <sys/ioctl.h>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <sys/mman.h>
> +#include <sys/uio.h>
> +
> +#include "hw/hw.h"
> +#include "block/aio.h"
> +#include "hw/xen/xen_backend.h"
> +
> +enum tpmif_state {
> +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel complete */
> +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> +};
> +
> +static AioContext *vtpm_aio_ctx;
> +
> +enum status_bits {
> +    VTPM_STATUS_RUNNING  = 0x1,
> +    VTPM_STATUS_IDLE     = 0x2,
> +    VTPM_STATUS_RESULT   = 0x4,
> +    VTPM_STATUS_CANCELED = 0x8,
> +};
> +
> +struct tpmif_shared_page {
> +    uint32_t length;         /* request/response length in bytes */
> +
> +    uint8_t  state;           /* enum tpmif_state */
> +    uint8_t  locality;        /* for the current request */
> +    uint8_t  pad;             /* should be zero */
> +
> +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be zero */
> +    uint32_t extra_pages[0]; /* grant IDs; length is actually nr_extra_pages */
> +};
> +
> +struct XenVtpmDev {
> +    struct XenDevice xendev;  /* must be first */
> +    struct           tpmif_shared_page *shr;
> +    xc_gntshr        *xen_xcs;
> +    int              ring_ref;
> +    int              bedomid;
> +    QEMUBH           *sr_bh;
> +};
> +
> +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> +{
> +    switch (vtpmdev->shr->state) {
> +    case TPMIF_STATE_IDLE:
> +    case TPMIF_STATE_FINISH:
> +        return VTPM_STATUS_IDLE;
> +    case TPMIF_STATE_SUBMIT:
> +    case TPMIF_STATE_CANCEL:
> +        return VTPM_STATUS_RUNNING;
> +    default:
> +        return 0;
> +    }
> +}
> +
> +static int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)
> +{
> +    xs_transaction_t xbt = XBT_NULL;
> +
> +    if (xendev->fe_state == xbus) {
> +        return 0;
> +    }
> +
> +    xendev->fe_state = xbus;
> +
> +retry_transaction:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto retry_transaction;
> +        }
> +    }
> +
> +    return 0;
> +
> +abort_transaction:
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}

This would probably end up in xen_frontend.c


> +static bool vtpm_aio_wait(AioContext *ctx)
> +{
> +    return aio_poll(ctx, true);
> +}
> +
> +static void sr_bh_handler(void *opaque)
> +{
> +}
> +
> +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset;
> +
> +    if (shr->state == TPMIF_STATE_IDLE) {
> +        return -ECANCELED;
> +    }
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpm_aio_ctx);
> +    }
> +
> +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> +    *count = shr->length;
> +
> +    return 0;
> +}
> +
> +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpm_aio_ctx);
> +    }
> +
> +    memcpy(offset + (uint8_t *)shr, buf, count);
> +    shr->length = count;
> +    barrier();
> +    shr->state = TPMIF_STATE_SUBMIT;
> +    xen_wmb();
> +    xen_be_send_notify(&vtpmdev->xendev);
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpm_aio_ctx);
> +    }
> +
> +    return count;
> +}
> +
> +static int vtpm_initialise(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    xs_transaction_t xbt = XBT_NULL;
> +    unsigned int ring_ref;
> +
> +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev, "frontend");
> +    if (vtpmdev->xendev.fe == NULL) {
> +        return -1;
> +    }
> +
> +    /* Get backend domid */
> +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> +                             &vtpmdev->bedomid)) {
> +        return -1;
> +    }
> +
> +    /*alloc share page*/
> +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs, vtpmdev->bedomid, 1,
> +                                         &ring_ref, PROT_READ|PROT_WRITE);
> +    vtpmdev->ring_ref = ring_ref;
> +    if (vtpmdev->shr == NULL) {
> +        return -1;
> +    }
> +
> +    /*Create event channel */
> +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0, vtpmdev->bedomid)) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +        return -1;
> +    }
> +
> +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> +                     vtpmdev->xendev.local_port);
> +
> +again:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> +                           vtpmdev->ring_ref)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> +                           vtpmdev->xendev.local_port)) {
> +        goto abort_transaction;
> +    }
> +
> +    /* Publish protocol v2 feature */
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto again;
> +        }
> +    }
> +    /* Tell vtpm backend that we are ready */
> +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> +
> +    return 0;
> +
> +abort_transaction:
> +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}
> +
> +static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    int be_state;
> +
> +    if (strcmp(node, "state") == 0) {
> +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> +        switch (be_state) {
> +        case XenbusStateConnected:
> +            /*TODO*/
> +            break;
> +        case XenbusStateClosing:
> +        case XenbusStateClosed:
> +            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
> +            break;
> +        default:
> +            break;
> +        }
> +    }
> +}

This would probably end up in xen_backend.c


> +static int vtpm_free(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    aio_poll(vtpm_aio_ctx, false);
> +    qemu_bh_delete(vtpmdev->sr_bh);
> +    if (vtpmdev->shr) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    }
> +    xc_interface_close(vtpmdev->xen_xcs);
> +    return 0;
> +}
> +
> +static void vtpm_alloc(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    vtpm_aio_ctx = aio_context_new(NULL);
> +    if (vtpm_aio_ctx == NULL) {
> +        return;
> +    }
> +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler, vtpmdev);
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> +}
> +
> +static void vtpm_event(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +}
> +
> +struct XenDevOps xen_vtpmdev_ops = {
> +    .size             = sizeof(struct XenVtpmDev),
> +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> +                        DEVOPS_FLAG_STUBDOM_BE,
> +    .event            = vtpm_event,
> +    .free             = vtpm_free,
> +    .alloc            = vtpm_alloc,
> +    .initialise       = vtpm_initialise,
> +    .backend_changed  = vtpm_backend_changed,
> +    .recv             = vtpm_recv,
> +    .send             = vtpm_send,

I don't think that recv and send should be part of the XenDevOps
interface. This interface is supposed to be a generic interface to
implement a Xen PV backend (or frontend maybe). recv and send are
specific to the vtpm driver, so they should not be here.


> +};
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index b2cb22b..5e7cfe5 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state)
>      return 0;
>  }
>  
> +/*get stubdom backend*/
> +static char *xen_stubdom_be(const char *type, int dom, int dev)
> +{
> +    char *val, *domu;
> +    char path[XEN_BUFSIZE];
> +    unsigned int len, ival;
> +
> +    /*front domu*/
> +    domu = xs_get_domain_path(xenstore, dom);
> +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> +             domu, type, dev);
> +    g_free(domu);
> +
> +    val = xs_read(xenstore, 0, path, &len);
> +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> +        g_free(val);
> +        return NULL;
> +    }
> +    g_free(val);
> +
> +    /*backend domu*/
> +    domu = xs_get_domain_path(xenstore, ival);
> +
> +    return domu;
> +}

This looks like a function to find the backend path. Instead of
duplicating functionalities with xenstore_read_be_str, we should just
make sure that xenstore_read_be_str works with backends other than dom0.

If we really do need a new function, that I don't think is the case, it
should be as generic as possible, so it should be called something like
xenstore_read_be_str and be in xen_frontend.c.


>  /* ------------------------------------------------------------- */
>  
>  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
> @@ -273,6 +299,68 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
>  }
>  
>  /*
> + * get xen stubdom backend device, allocate a new one if it doesn't exist.
> + */
> +static struct XenDevice *xen_stubdom_be_get_xendev(const char *type,
> +                         int dom, int dev, struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char *stub;
> +
> +    xendev = xen_be_find_xendev(type, dom, dev);
> +    if (xendev) {
> +        return xendev;
> +    }
> +
> +    /* init new xendev */
> +    xendev = g_malloc0(ops->size);
> +    xendev->type  = type;
> +    xendev->dom   = dom;
> +    xendev->dev   = dev;
> +    xendev->ops   = ops;
> +
> +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> +        stub = xen_stubdom_be(xendev->type, xendev->dom, xendev->dev);
> +        snprintf(xendev->be, sizeof(xendev->be), "%s/backend/%s/%d/%d",
> +                 stub, xendev->type, xendev->dom, xendev->dev);
> +        g_free(stub);
> +    }
> +    snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> +             xendev->type, xendev->dev);
> +
> +    xendev->debug      = debug;
> +    xendev->local_port = -1;
> +
> +    xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
> +    if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
> +        xen_be_printf(NULL, 0, "can't open evtchn device\n");
> +        g_free(xendev);
> +        return NULL;
> +    }
> +    fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
> +
> +    if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
> +        xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
> +        if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
> +            xen_be_printf(NULL, 0, "can't open gnttab device\n");
> +            xc_evtchn_close(xendev->evtchndev);
> +            g_free(xendev);
> +            return NULL;
> +        }
> +    } else {
> +        xendev->gnttabdev = XC_HANDLER_INITIAL_VALUE;
> +    }
> +
> +    QTAILQ_INSERT_TAIL(&xendevs, xendev, next);
> +
> +    if (xendev->ops->alloc) {
> +        xendev->ops->alloc(xendev);
> +    }
> +
> +    return xendev;
> +}

Same here: this should be called xen_fe_get_xendev and be in
xen_frontend.c

Nothing should be called *_stubdom_*: we don't care about stubdoms in
QEMU, only about frontends and backends.


> +/*
>   * release xen backend device.
>   */
>  static struct XenDevice *xen_be_del_xendev(int dom, int dev)
> @@ -611,6 +699,47 @@ static int xenstore_scan(const char *type, int dom, struct XenDevOps *ops)
>      return 0;
>  }
>  
> +static void stubdom_update_be(char *watch, char *type, int dom,
> +                              struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE];
> +    char *ptr, *bepath;
> +    unsigned int len, dev;
> +
> +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> +        return;
> +    }
> +
> +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> +    ptr = strstr(watch, path);
> +    if (ptr == NULL) {
> +        return;
> +    }
> +
> +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> +        strcpy(path, "");
> +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> +            dev = -1;
> +        }
> +    }
> +
> +    if (dev == -1) {
> +        return;
> +    }
> +
> +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> +    if (xendev != NULL) {
> +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> +        if (bepath == NULL) {
> +            xen_be_del_xendev(dom, dev);
> +        } else {
> +            free(bepath);
> +            xen_be_backend_changed(xendev, path);
> +        }
> +    }
> +}

ditto


>  static void xenstore_update_be(char *watch, char *type, int dom,
>                                 struct XenDevOps *ops)
>  {
> @@ -681,6 +810,10 @@ static void xenstore_update(void *unused)
>      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
>          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
>      }
> +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%" PRIxPTR,
> +               &type, &dom, &ops) == 3) {
> +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
> +    }
>  
>  cleanup:
>      free(vec);
> @@ -732,11 +865,114 @@ err:
>      return -1;
>  }
>  
> +static int stubdom_check(struct XenDevice *xendev, uint32_t domid,
> +                         int handle)
> +{
> +    int rc = 0;
> +
> +    if (xendev->ops->init) {
> +        rc = xendev->ops->init(xendev);
> +    }
> +
> +    if (rc != 0) {
> +        xen_be_printf(xendev, 0, "xendev %s init error\n",
> +                     xendev->name);
> +       goto err;
> +    }
> +
> +    if (xendev->ops->initialise) {
> +        rc = xendev->ops->initialise(xendev);
> +    }
> +
> +    if (rc != 0) {
> +        xen_be_printf(xendev, 0, "xendev %s initialise error\n",
> +                     xendev->name);
> +       goto err;
> +    }
> +
> +    if (xendev->ops->connected) {
> +        xendev->ops->connected(xendev);
> +    }
> +
> +    return rc;
> +
> +err:
> +    xen_be_del_xendev(domid, handle);
> +    return -1;
> +}

ditto


> +static int xenstore_stubdom_scan(const char *type, uint32_t domid,
> +                                 struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> +    char *domu;
> +    unsigned int cdev, j;
> +    char **dev = NULL;
> +
> +    /*stubom : /local/domain/ID */
> +    domu = xs_get_domain_path(xenstore, domid);
> +    snprintf(path, sizeof(path), "%s/device/%s",
> +             domu, type);
> +    free(domu);
> +    dev = xs_directory(xenstore, 0, path, &cdev);
> +    if (dev == NULL) {
> +        return 0;
> +    }
> +
> +    for (j = 0; j < cdev; j++) {
> +        xendev = xen_stubdom_be_get_xendev(type, domid,
> +                                           atoi(dev[j]), ops);
> +        if (xendev == NULL) {
> +            xen_be_printf(xendev, 0, "xendev is NULL.\n");
> +            continue;
> +        }
> +
> +        /* simplify QEMU side, a thread is running in Xen stubdom, which will
> +         * connect frontend when the frontend is initialised.
> +         */
> +        if (stubdom_check(xendev, domid, atoi(dev[j])) < 0) {
> +            xen_be_printf(xendev, 0, "xendev stubdom_check error.\n");
> +            continue;
> +        }
> +
> +        /*setup watch*/
> +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> +                 type, domid, xendev->ops);
> +        if (!xs_watch(xenstore, xendev->be, token)) {
> +            xen_be_printf(xendev, 0, "xs_watch failed.\n");
> +            continue;
> +        }
> +    }
> +
> +    free(dev);
> +    return 0;
> +}

ditto


> +int xen_fe_register(const char *type, struct XenDevOps *ops)
> +{
> +    return xenstore_stubdom_scan(type, xen_domid, ops);
> +}
> +
>  int xen_be_register(const char *type, struct XenDevOps *ops)
>  {
>      return xenstore_scan(type, xen_domid, ops);
>  }
>  
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom)
> +{
> +    xendev->local_port = xc_evtchn_bind_unbound_port(xendev->evtchndev,
> +                                                     remote_dom);
> +    if (xendev->local_port == -1) {
> +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> +        return -1;
> +    }
> +    xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
> +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> +                        xen_be_evtchn_event, NULL, xendev);
> +    return 0;
> +}
> +
>  int xen_be_bind_evtchn(struct XenDevice *xendev)
>  {
>      if (xendev->local_port != -1) {
> @@ -770,6 +1006,42 @@ int xen_be_send_notify(struct XenDevice *xendev)
>      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
>  }
>  
> +int xen_vtpm_send(unsigned char *buf, size_t count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->send) {
> +        rc = xendev->ops->send(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}
> +
> +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->recv) {
> +        xendev->ops->recv(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}

I don't these we should have these two functions here, they don't belong
to the QEMU internal Xen backend (or frontend) interface.


>  /*
>   * msg_level:
>   *  0 == errors (stderr + logfile).
> diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
> index 3b4125e..f2d5489 100644
> --- a/include/hw/xen/xen_backend.h
> +++ b/include/hw/xen/xen_backend.h
> @@ -15,6 +15,8 @@ struct XenDevice;
>  #define DEVOPS_FLAG_NEED_GNTDEV   1
>  /* don't expect frontend doing correct state transitions (aka console quirk) */
>  #define DEVOPS_FLAG_IGNORE_STATE  2
> +/*dev backend is stubdom*/
> +#define DEVOPS_FLAG_STUBDOM_BE    4
>  
>  struct XenDevOps {
>      size_t    size;
> @@ -26,6 +28,8 @@ struct XenDevOps {
>      void      (*event)(struct XenDevice *xendev);
>      void      (*disconnect)(struct XenDevice *xendev);
>      int       (*free)(struct XenDevice *xendev);
> +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t count);
> +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t *count);
>      void      (*backend_changed)(struct XenDevice *xendev, const char *node);
>      void      (*frontend_changed)(struct XenDevice *xendev, const char *node);
>  };
> @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice *xendev);
>  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...)
>      GCC_FMT_ATTR(3, 4);
>  
> +/*Xen stubdom vtpm*/
> +int xen_fe_register(const char *type, struct XenDevOps *ops);
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
> +int xen_vtpm_send(unsigned char *buf, size_t count);
> +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> +
>  /* actual backend drivers */
>  extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
>  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c */
>  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
>  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c        */
>  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c         */
> +extern struct XenDevOps xen_vtpmdev_ops;      /* xen_stubdom_vtpm.c*/
>  
>  void xen_init_display(int domid);
>  
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 95612a4..fb43084 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
>      return xc_interface_open(logger, dombuild_logger, open_flags);
>  }
>  
> +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> +                                           unsigned int open_flags)
> +{
> +    return xc_gntshr_open(logger, open_flags);
> +}
> +
>  /* FIXME There is now way to have the xen fd */
>  static inline int xc_fd(xc_interface *xen_xc)
>  {
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 21f1cbb..854b8f7 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>      int i, rc;
>      unsigned long ioreq_pfn;
>      unsigned long bufioreq_evtchn;
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    unsigned long stubdom_vtpm = 0;
> +#endif
> +
>      XenIOState *state;
>  
>      state = g_malloc0(sizeof (XenIOState));
> @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>          fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
>          return -1;
>      }
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);

HVM params are used for domain wide configuration, visible to the guest
too.  I don't think that this parameter is actually supposed to be guest
visible?
If not, it should be passed to QEMU via command line or hmp/qmp.


> +    if (stubdom_vtpm) {
> +        xen_fe_register("vtpm", &xen_vtpmdev_ops);
> +    }
> +#endif
> +
>      xen_be_register("console", &xen_console_ops);
>      xen_be_register("vkbd", &xen_kbdmouse_ops);
>      xen_be_register("qdisk", &xen_blkdev_ops);
> -- 
> 1.8.3.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:16:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:16:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswJR-0002mr-0I; Mon, 24 Nov 2014 16:16:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XswJP-0002mm-Cd
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 16:16:27 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	7B/E4-27785-AD953745; Mon, 24 Nov 2014 16:16:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416845781!14517000!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1424 invoked from network); 24 Nov 2014 16:16:25 -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;
	24 Nov 2014 16:16:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196142423"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 11:15:51 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XswIp-0002aQ-MH;
	Mon, 24 Nov 2014 16:15:51 +0000
Date: Mon, 24 Nov 2014 16:15:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Quan Xu <quan.xu@intel.com>
In-Reply-To: <1416802256-9928-1-git-send-email-quan.xu@intel.com>
Message-ID: <alpine.DEB.2.02.1411241544410.2675@kaball.uk.xensource.com>
References: <1416802256-9928-1-git-send-email-quan.xu@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
 frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 23 Nov 2014, Quan Xu wrote:
> This drvier transfers any request/repond between TPM xenstubdoms
> driver and Xen vTPM stubdom, and facilitates communications between
> Xen vTPM stubdom domain and vTPM xenstubdoms driver
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>

This patch needs a better description, see my past request:

http://marc.info/?l=xen-devel&m=141501570709022&w=2


>  hw/tpm/Makefile.objs         |   1 +
>  hw/tpm/xen_stubdom_vtpm.c    | 321 +++++++++++++++++++++++++++++++++++++++++++
>  hw/xen/xen_backend.c         | 272 ++++++++++++++++++++++++++++++++++++
>  include/hw/xen/xen_backend.h |  11 ++
>  include/hw/xen/xen_common.h  |   6 +
>  xen-hvm.c                    |  13 ++
>  6 files changed, 624 insertions(+)
>  create mode 100644 hw/tpm/xen_stubdom_vtpm.c
> 
> diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
> index 99f5983..87efb01 100644
> --- a/hw/tpm/Makefile.objs
> +++ b/hw/tpm/Makefile.objs
> @@ -1,2 +1,3 @@
>  common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
>  common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
> +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> diff --git a/hw/tpm/xen_stubdom_vtpm.c b/hw/tpm/xen_stubdom_vtpm.c
> new file mode 100644
> index 0000000..4fd6053
> --- /dev/null
> +++ b/hw/tpm/xen_stubdom_vtpm.c

I would just call it xen_vtpm_frontend.c

I don't think that the fact that the backend is probably run in a
stubdom is relevant here. The only thing that matter is that this is a
PV frontend.


Also if this is the vtpm specific frontend, where is the file that
introduces the generic frontend registration framework, as previously
discussed?

http://marc.info/?l=xen-devel&m=141528935207946&w=2

I think we should have a hw/xen/xen_frontend.c file, introducing
xen_fe_register etc, and a separate hw/tpm/xen_stubdom_vtpm.c with the
vtpm specific stuff.


> @@ -0,0 +1,321 @@
> +/*
> + * Connect to Xen vTPM stubdom domain
> + *
> + *  Copyright (c) 2014 Intel Corporation
> + *  Authors:
> + *    Quan Xu <quan.xu@intel.com>
> + *
> + * 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 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, see <http://www.gnu.org/licenses/>
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <stdarg.h>
> +#include <string.h>
> +#include <unistd.h>
> +#include <signal.h>
> +#include <inttypes.h>
> +#include <time.h>
> +#include <fcntl.h>
> +#include <errno.h>
> +#include <sys/ioctl.h>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <sys/mman.h>
> +#include <sys/uio.h>
> +
> +#include "hw/hw.h"
> +#include "block/aio.h"
> +#include "hw/xen/xen_backend.h"
> +
> +enum tpmif_state {
> +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel complete */
> +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> +};
> +
> +static AioContext *vtpm_aio_ctx;
> +
> +enum status_bits {
> +    VTPM_STATUS_RUNNING  = 0x1,
> +    VTPM_STATUS_IDLE     = 0x2,
> +    VTPM_STATUS_RESULT   = 0x4,
> +    VTPM_STATUS_CANCELED = 0x8,
> +};
> +
> +struct tpmif_shared_page {
> +    uint32_t length;         /* request/response length in bytes */
> +
> +    uint8_t  state;           /* enum tpmif_state */
> +    uint8_t  locality;        /* for the current request */
> +    uint8_t  pad;             /* should be zero */
> +
> +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be zero */
> +    uint32_t extra_pages[0]; /* grant IDs; length is actually nr_extra_pages */
> +};
> +
> +struct XenVtpmDev {
> +    struct XenDevice xendev;  /* must be first */
> +    struct           tpmif_shared_page *shr;
> +    xc_gntshr        *xen_xcs;
> +    int              ring_ref;
> +    int              bedomid;
> +    QEMUBH           *sr_bh;
> +};
> +
> +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> +{
> +    switch (vtpmdev->shr->state) {
> +    case TPMIF_STATE_IDLE:
> +    case TPMIF_STATE_FINISH:
> +        return VTPM_STATUS_IDLE;
> +    case TPMIF_STATE_SUBMIT:
> +    case TPMIF_STATE_CANCEL:
> +        return VTPM_STATUS_RUNNING;
> +    default:
> +        return 0;
> +    }
> +}
> +
> +static int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)
> +{
> +    xs_transaction_t xbt = XBT_NULL;
> +
> +    if (xendev->fe_state == xbus) {
> +        return 0;
> +    }
> +
> +    xendev->fe_state = xbus;
> +
> +retry_transaction:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto retry_transaction;
> +        }
> +    }
> +
> +    return 0;
> +
> +abort_transaction:
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}

This would probably end up in xen_frontend.c


> +static bool vtpm_aio_wait(AioContext *ctx)
> +{
> +    return aio_poll(ctx, true);
> +}
> +
> +static void sr_bh_handler(void *opaque)
> +{
> +}
> +
> +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset;
> +
> +    if (shr->state == TPMIF_STATE_IDLE) {
> +        return -ECANCELED;
> +    }
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpm_aio_ctx);
> +    }
> +
> +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> +    *count = shr->length;
> +
> +    return 0;
> +}
> +
> +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    struct tpmif_shared_page *shr = vtpmdev->shr;
> +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpm_aio_ctx);
> +    }
> +
> +    memcpy(offset + (uint8_t *)shr, buf, count);
> +    shr->length = count;
> +    barrier();
> +    shr->state = TPMIF_STATE_SUBMIT;
> +    xen_wmb();
> +    xen_be_send_notify(&vtpmdev->xendev);
> +
> +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> +        vtpm_aio_wait(vtpm_aio_ctx);
> +    }
> +
> +    return count;
> +}
> +
> +static int vtpm_initialise(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    xs_transaction_t xbt = XBT_NULL;
> +    unsigned int ring_ref;
> +
> +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev, "frontend");
> +    if (vtpmdev->xendev.fe == NULL) {
> +        return -1;
> +    }
> +
> +    /* Get backend domid */
> +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> +                             &vtpmdev->bedomid)) {
> +        return -1;
> +    }
> +
> +    /*alloc share page*/
> +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs, vtpmdev->bedomid, 1,
> +                                         &ring_ref, PROT_READ|PROT_WRITE);
> +    vtpmdev->ring_ref = ring_ref;
> +    if (vtpmdev->shr == NULL) {
> +        return -1;
> +    }
> +
> +    /*Create event channel */
> +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0, vtpmdev->bedomid)) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +        return -1;
> +    }
> +
> +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> +                     vtpmdev->xendev.local_port);
> +
> +again:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> +                           vtpmdev->ring_ref)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> +                           vtpmdev->xendev.local_port)) {
> +        goto abort_transaction;
> +    }
> +
> +    /* Publish protocol v2 feature */
> +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto again;
> +        }
> +    }
> +    /* Tell vtpm backend that we are ready */
> +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> +
> +    return 0;
> +
> +abort_transaction:
> +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}
> +
> +static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    int be_state;
> +
> +    if (strcmp(node, "state") == 0) {
> +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> +        switch (be_state) {
> +        case XenbusStateConnected:
> +            /*TODO*/
> +            break;
> +        case XenbusStateClosing:
> +        case XenbusStateClosed:
> +            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
> +            break;
> +        default:
> +            break;
> +        }
> +    }
> +}

This would probably end up in xen_backend.c


> +static int vtpm_free(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +    aio_poll(vtpm_aio_ctx, false);
> +    qemu_bh_delete(vtpmdev->sr_bh);
> +    if (vtpmdev->shr) {
> +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> +    }
> +    xc_interface_close(vtpmdev->xen_xcs);
> +    return 0;
> +}
> +
> +static void vtpm_alloc(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    vtpm_aio_ctx = aio_context_new(NULL);
> +    if (vtpm_aio_ctx == NULL) {
> +        return;
> +    }
> +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler, vtpmdev);
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> +}
> +
> +static void vtpm_event(struct XenDevice *xendev)
> +{
> +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> +                                              xendev);
> +
> +    qemu_bh_schedule(vtpmdev->sr_bh);
> +}
> +
> +struct XenDevOps xen_vtpmdev_ops = {
> +    .size             = sizeof(struct XenVtpmDev),
> +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> +                        DEVOPS_FLAG_STUBDOM_BE,
> +    .event            = vtpm_event,
> +    .free             = vtpm_free,
> +    .alloc            = vtpm_alloc,
> +    .initialise       = vtpm_initialise,
> +    .backend_changed  = vtpm_backend_changed,
> +    .recv             = vtpm_recv,
> +    .send             = vtpm_send,

I don't think that recv and send should be part of the XenDevOps
interface. This interface is supposed to be a generic interface to
implement a Xen PV backend (or frontend maybe). recv and send are
specific to the vtpm driver, so they should not be here.


> +};
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index b2cb22b..5e7cfe5 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state)
>      return 0;
>  }
>  
> +/*get stubdom backend*/
> +static char *xen_stubdom_be(const char *type, int dom, int dev)
> +{
> +    char *val, *domu;
> +    char path[XEN_BUFSIZE];
> +    unsigned int len, ival;
> +
> +    /*front domu*/
> +    domu = xs_get_domain_path(xenstore, dom);
> +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> +             domu, type, dev);
> +    g_free(domu);
> +
> +    val = xs_read(xenstore, 0, path, &len);
> +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> +        g_free(val);
> +        return NULL;
> +    }
> +    g_free(val);
> +
> +    /*backend domu*/
> +    domu = xs_get_domain_path(xenstore, ival);
> +
> +    return domu;
> +}

This looks like a function to find the backend path. Instead of
duplicating functionalities with xenstore_read_be_str, we should just
make sure that xenstore_read_be_str works with backends other than dom0.

If we really do need a new function, that I don't think is the case, it
should be as generic as possible, so it should be called something like
xenstore_read_be_str and be in xen_frontend.c.


>  /* ------------------------------------------------------------- */
>  
>  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
> @@ -273,6 +299,68 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
>  }
>  
>  /*
> + * get xen stubdom backend device, allocate a new one if it doesn't exist.
> + */
> +static struct XenDevice *xen_stubdom_be_get_xendev(const char *type,
> +                         int dom, int dev, struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char *stub;
> +
> +    xendev = xen_be_find_xendev(type, dom, dev);
> +    if (xendev) {
> +        return xendev;
> +    }
> +
> +    /* init new xendev */
> +    xendev = g_malloc0(ops->size);
> +    xendev->type  = type;
> +    xendev->dom   = dom;
> +    xendev->dev   = dev;
> +    xendev->ops   = ops;
> +
> +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> +        stub = xen_stubdom_be(xendev->type, xendev->dom, xendev->dev);
> +        snprintf(xendev->be, sizeof(xendev->be), "%s/backend/%s/%d/%d",
> +                 stub, xendev->type, xendev->dom, xendev->dev);
> +        g_free(stub);
> +    }
> +    snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> +             xendev->type, xendev->dev);
> +
> +    xendev->debug      = debug;
> +    xendev->local_port = -1;
> +
> +    xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
> +    if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
> +        xen_be_printf(NULL, 0, "can't open evtchn device\n");
> +        g_free(xendev);
> +        return NULL;
> +    }
> +    fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
> +
> +    if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
> +        xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
> +        if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
> +            xen_be_printf(NULL, 0, "can't open gnttab device\n");
> +            xc_evtchn_close(xendev->evtchndev);
> +            g_free(xendev);
> +            return NULL;
> +        }
> +    } else {
> +        xendev->gnttabdev = XC_HANDLER_INITIAL_VALUE;
> +    }
> +
> +    QTAILQ_INSERT_TAIL(&xendevs, xendev, next);
> +
> +    if (xendev->ops->alloc) {
> +        xendev->ops->alloc(xendev);
> +    }
> +
> +    return xendev;
> +}

Same here: this should be called xen_fe_get_xendev and be in
xen_frontend.c

Nothing should be called *_stubdom_*: we don't care about stubdoms in
QEMU, only about frontends and backends.


> +/*
>   * release xen backend device.
>   */
>  static struct XenDevice *xen_be_del_xendev(int dom, int dev)
> @@ -611,6 +699,47 @@ static int xenstore_scan(const char *type, int dom, struct XenDevOps *ops)
>      return 0;
>  }
>  
> +static void stubdom_update_be(char *watch, char *type, int dom,
> +                              struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE];
> +    char *ptr, *bepath;
> +    unsigned int len, dev;
> +
> +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> +        return;
> +    }
> +
> +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> +    ptr = strstr(watch, path);
> +    if (ptr == NULL) {
> +        return;
> +    }
> +
> +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> +        strcpy(path, "");
> +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> +            dev = -1;
> +        }
> +    }
> +
> +    if (dev == -1) {
> +        return;
> +    }
> +
> +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> +    if (xendev != NULL) {
> +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> +        if (bepath == NULL) {
> +            xen_be_del_xendev(dom, dev);
> +        } else {
> +            free(bepath);
> +            xen_be_backend_changed(xendev, path);
> +        }
> +    }
> +}

ditto


>  static void xenstore_update_be(char *watch, char *type, int dom,
>                                 struct XenDevOps *ops)
>  {
> @@ -681,6 +810,10 @@ static void xenstore_update(void *unused)
>      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
>          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
>      }
> +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%" PRIxPTR,
> +               &type, &dom, &ops) == 3) {
> +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
> +    }
>  
>  cleanup:
>      free(vec);
> @@ -732,11 +865,114 @@ err:
>      return -1;
>  }
>  
> +static int stubdom_check(struct XenDevice *xendev, uint32_t domid,
> +                         int handle)
> +{
> +    int rc = 0;
> +
> +    if (xendev->ops->init) {
> +        rc = xendev->ops->init(xendev);
> +    }
> +
> +    if (rc != 0) {
> +        xen_be_printf(xendev, 0, "xendev %s init error\n",
> +                     xendev->name);
> +       goto err;
> +    }
> +
> +    if (xendev->ops->initialise) {
> +        rc = xendev->ops->initialise(xendev);
> +    }
> +
> +    if (rc != 0) {
> +        xen_be_printf(xendev, 0, "xendev %s initialise error\n",
> +                     xendev->name);
> +       goto err;
> +    }
> +
> +    if (xendev->ops->connected) {
> +        xendev->ops->connected(xendev);
> +    }
> +
> +    return rc;
> +
> +err:
> +    xen_be_del_xendev(domid, handle);
> +    return -1;
> +}

ditto


> +static int xenstore_stubdom_scan(const char *type, uint32_t domid,
> +                                 struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> +    char *domu;
> +    unsigned int cdev, j;
> +    char **dev = NULL;
> +
> +    /*stubom : /local/domain/ID */
> +    domu = xs_get_domain_path(xenstore, domid);
> +    snprintf(path, sizeof(path), "%s/device/%s",
> +             domu, type);
> +    free(domu);
> +    dev = xs_directory(xenstore, 0, path, &cdev);
> +    if (dev == NULL) {
> +        return 0;
> +    }
> +
> +    for (j = 0; j < cdev; j++) {
> +        xendev = xen_stubdom_be_get_xendev(type, domid,
> +                                           atoi(dev[j]), ops);
> +        if (xendev == NULL) {
> +            xen_be_printf(xendev, 0, "xendev is NULL.\n");
> +            continue;
> +        }
> +
> +        /* simplify QEMU side, a thread is running in Xen stubdom, which will
> +         * connect frontend when the frontend is initialised.
> +         */
> +        if (stubdom_check(xendev, domid, atoi(dev[j])) < 0) {
> +            xen_be_printf(xendev, 0, "xendev stubdom_check error.\n");
> +            continue;
> +        }
> +
> +        /*setup watch*/
> +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> +                 type, domid, xendev->ops);
> +        if (!xs_watch(xenstore, xendev->be, token)) {
> +            xen_be_printf(xendev, 0, "xs_watch failed.\n");
> +            continue;
> +        }
> +    }
> +
> +    free(dev);
> +    return 0;
> +}

ditto


> +int xen_fe_register(const char *type, struct XenDevOps *ops)
> +{
> +    return xenstore_stubdom_scan(type, xen_domid, ops);
> +}
> +
>  int xen_be_register(const char *type, struct XenDevOps *ops)
>  {
>      return xenstore_scan(type, xen_domid, ops);
>  }
>  
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom)
> +{
> +    xendev->local_port = xc_evtchn_bind_unbound_port(xendev->evtchndev,
> +                                                     remote_dom);
> +    if (xendev->local_port == -1) {
> +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> +        return -1;
> +    }
> +    xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
> +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> +                        xen_be_evtchn_event, NULL, xendev);
> +    return 0;
> +}
> +
>  int xen_be_bind_evtchn(struct XenDevice *xendev)
>  {
>      if (xendev->local_port != -1) {
> @@ -770,6 +1006,42 @@ int xen_be_send_notify(struct XenDevice *xendev)
>      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
>  }
>  
> +int xen_vtpm_send(unsigned char *buf, size_t count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->send) {
> +        rc = xendev->ops->send(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}
> +
> +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> +{
> +    struct XenDevice *xendev;
> +    int rc = -1;
> +
> +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> +    if (xendev == NULL) {
> +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> +        return -1;
> +    }
> +
> +    if (xendev->ops->recv) {
> +        xendev->ops->recv(xendev, buf, count);
> +    }
> +
> +    return rc;
> +}

I don't these we should have these two functions here, they don't belong
to the QEMU internal Xen backend (or frontend) interface.


>  /*
>   * msg_level:
>   *  0 == errors (stderr + logfile).
> diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
> index 3b4125e..f2d5489 100644
> --- a/include/hw/xen/xen_backend.h
> +++ b/include/hw/xen/xen_backend.h
> @@ -15,6 +15,8 @@ struct XenDevice;
>  #define DEVOPS_FLAG_NEED_GNTDEV   1
>  /* don't expect frontend doing correct state transitions (aka console quirk) */
>  #define DEVOPS_FLAG_IGNORE_STATE  2
> +/*dev backend is stubdom*/
> +#define DEVOPS_FLAG_STUBDOM_BE    4
>  
>  struct XenDevOps {
>      size_t    size;
> @@ -26,6 +28,8 @@ struct XenDevOps {
>      void      (*event)(struct XenDevice *xendev);
>      void      (*disconnect)(struct XenDevice *xendev);
>      int       (*free)(struct XenDevice *xendev);
> +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t count);
> +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t *count);
>      void      (*backend_changed)(struct XenDevice *xendev, const char *node);
>      void      (*frontend_changed)(struct XenDevice *xendev, const char *node);
>  };
> @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice *xendev);
>  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...)
>      GCC_FMT_ATTR(3, 4);
>  
> +/*Xen stubdom vtpm*/
> +int xen_fe_register(const char *type, struct XenDevOps *ops);
> +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
> +int xen_vtpm_send(unsigned char *buf, size_t count);
> +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> +
>  /* actual backend drivers */
>  extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
>  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c */
>  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
>  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c        */
>  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c         */
> +extern struct XenDevOps xen_vtpmdev_ops;      /* xen_stubdom_vtpm.c*/
>  
>  void xen_init_display(int domid);
>  
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 95612a4..fb43084 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
>      return xc_interface_open(logger, dombuild_logger, open_flags);
>  }
>  
> +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> +                                           unsigned int open_flags)
> +{
> +    return xc_gntshr_open(logger, open_flags);
> +}
> +
>  /* FIXME There is now way to have the xen fd */
>  static inline int xc_fd(xc_interface *xen_xc)
>  {
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 21f1cbb..854b8f7 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>      int i, rc;
>      unsigned long ioreq_pfn;
>      unsigned long bufioreq_evtchn;
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    unsigned long stubdom_vtpm = 0;
> +#endif
> +
>      XenIOState *state;
>  
>      state = g_malloc0(sizeof (XenIOState));
> @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
>          fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
>          return -1;
>      }
> +
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);

HVM params are used for domain wide configuration, visible to the guest
too.  I don't think that this parameter is actually supposed to be guest
visible?
If not, it should be passed to QEMU via command line or hmp/qmp.


> +    if (stubdom_vtpm) {
> +        xen_fe_register("vtpm", &xen_vtpmdev_ops);
> +    }
> +#endif
> +
>      xen_be_register("console", &xen_console_ops);
>      xen_be_register("vkbd", &xen_kbdmouse_ops);
>      xen_be_register("qdisk", &xen_blkdev_ops);
> -- 
> 1.8.3.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:16:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswJr-0002pV-Ju; Mon, 24 Nov 2014 16:16:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XswJq-0002pN-9a
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 16:16:54 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	01/92-02576-5F953745; Mon, 24 Nov 2014 16:16:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416845812!14493742!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27415 invoked from network); 24 Nov 2014 16:16:52 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 16:16:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 16:16:52 +0000
Message-Id: <54736800020000780004A71C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 16:16:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhuan Chen" <zhuanchen@gmail.com>
References: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
In-Reply-To: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Building 32-bit xen.efi for 32-bit EFI 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

>>> On 24.11.14 at 15:59, <zhuanchen@gmail.com> wrote:
> I am wondering whether it's possible to build 32-bit xen.efi for the
> 32-bit EFI platform? One way of building xen.efi I learnt is to make
> the binutils configured with the x86_64-pep emulation (according to
> the document http://xenbits.xenproject.org/docs/unstable/misc/efi.html).
> The resulted xen.efi is 64-bit mode. Is it possible to build xen.efi
> as the 32-bit mode?
> 
> The reason for this question is due to my effort of installing Xen on
> the Asus Transformer Book T100, which is one of the Bay Trail Atom
> (64-bit processors) tablets shipped with 32-bit EFI firmware. This
> requires the support of the 32-bit EFI bootloader. Such platforms seem
> to become common and Linux kernel from 3.15 also provides the EFI
> mixed mode to support 64-bit kernels running from 32-bit EFI firmware.

This mixed mode support is kind of crippled, as it suppresses all use
of runtime services. But that aside, as others said what you ask for
is currently not possible - feel free to submit patches to improve the
situation, but be aware that a number of assumptions of being 64-bit
are currently made in the boot loader code, so you'd have to do
careful code review first to spot all places needing adjustment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:16:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswJr-0002pV-Ju; Mon, 24 Nov 2014 16:16:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XswJq-0002pN-9a
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 16:16:54 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	01/92-02576-5F953745; Mon, 24 Nov 2014 16:16:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416845812!14493742!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27415 invoked from network); 24 Nov 2014 16:16:52 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 16:16:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 24 Nov 2014 16:16:52 +0000
Message-Id: <54736800020000780004A71C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 24 Nov 2014 16:16:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhuan Chen" <zhuanchen@gmail.com>
References: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
In-Reply-To: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Building 32-bit xen.efi for 32-bit EFI 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

>>> On 24.11.14 at 15:59, <zhuanchen@gmail.com> wrote:
> I am wondering whether it's possible to build 32-bit xen.efi for the
> 32-bit EFI platform? One way of building xen.efi I learnt is to make
> the binutils configured with the x86_64-pep emulation (according to
> the document http://xenbits.xenproject.org/docs/unstable/misc/efi.html).
> The resulted xen.efi is 64-bit mode. Is it possible to build xen.efi
> as the 32-bit mode?
> 
> The reason for this question is due to my effort of installing Xen on
> the Asus Transformer Book T100, which is one of the Bay Trail Atom
> (64-bit processors) tablets shipped with 32-bit EFI firmware. This
> requires the support of the 32-bit EFI bootloader. Such platforms seem
> to become common and Linux kernel from 3.15 also provides the EFI
> mixed mode to support 64-bit kernels running from 32-bit EFI firmware.

This mixed mode support is kind of crippled, as it suppresses all use
of runtime services. But that aside, as others said what you ask for
is currently not possible - feel free to submit patches to improve the
situation, but be aware that a number of assumptions of being 64-bit
are currently made in the boot loader code, so you'd have to do
careful code review first to spot all places needing adjustment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:20:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswN6-00032h-8J; Mon, 24 Nov 2014 16:20:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XswN4-00032Y-OY
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 16:20:14 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	84/BB-05632-EBA53745; Mon, 24 Nov 2014 16:20:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416846004!13538786!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7718 invoked from network); 24 Nov 2014 16:20:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 16:20:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196144759"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 11:20:05 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XswMv-0002gb-Id;
	Mon, 24 Nov 2014 16:20:05 +0000
Date: Mon, 24 Nov 2014 16:20:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Quan Xu <quan.xu@intel.com>
In-Reply-To: <1416802259-9965-1-git-send-email-quan.xu@intel.com>
Message-ID: <alpine.DEB.2.02.1411241616160.2675@kaball.uk.xensource.com>
References: <1416802259-9965-1-git-send-email-quan.xu@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v2 3/4] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms
	driver.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 23 Nov 2014, Quan Xu wrote:
> This driver provides vTPM initialization and sending data and TPM
> commends to a Xen stubdom vTPM domain.
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>

We need a better, more detailed, patch description here.


>  hw/tpm/Makefile.objs     |   1 +
>  hw/tpm/tpm_xenstubdoms.c | 238 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 239 insertions(+)
>  create mode 100644 hw/tpm/tpm_xenstubdoms.c
> 
> diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
> index 87efb01..20f0a7b 100644
> --- a/hw/tpm/Makefile.objs
> +++ b/hw/tpm/Makefile.objs
> @@ -1,3 +1,4 @@
>  common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
>  common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
> +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o
>  common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
> new file mode 100644
> index 0000000..845df18
> --- /dev/null
> +++ b/hw/tpm/tpm_xenstubdoms.c
> @@ -0,0 +1,238 @@
> +/*
> + * Xen Stubdom vTPM driver
> + *
> + *  Copyright (c) 2014 Intel Corporation
> + *  Authors:
> + *    Quan Xu <quan.xu@intel.com>
> + *
> + * 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 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, see <http://www.gnu.org/licenses/>
> + */
> +
> +#include <dirent.h>
> +#include "qemu-common.h"
> +#include "qapi/error.h"
> +#include "qemu/sockets.h"
> +#include "qemu/log.h"
> +#include "sysemu/tpm_backend.h"
> +#include "tpm_int.h"
> +#include "hw/hw.h"
> +#include "hw/i386/pc.h"
> +#include "hw/xen/xen_backend.h"
> +#include "sysemu/tpm_backend_int.h"
> +#include "tpm_tis.h"
> +
> +#ifdef DEBUG_TPM
> +#define DPRINTF(fmt, ...) \
> +    do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTF(fmt, ...) \
> +    do { } while (0)
> +#endif
> +
> +#define TYPE_TPM_XENSTUBDOMS "tpm-xenstubdoms"
> +#define TPM_XENSTUBDOMS(obj) \
> +    OBJECT_CHECK(TPMXenstubdomsState, (obj), TYPE_TPM_XENSTUBDOMS)
> +
> +static const TPMDriverOps tpm_xenstubdoms_driver;
> +
> +/* data structures */
> +typedef struct TPMXenstubdomsThreadParams {
> +    TPMState *tpm_state;
> +    TPMRecvDataCB *recv_data_callback;
> +    TPMBackend *tb;
> +} TPMXenstubdomsThreadParams;
> +
> +struct TPMXenstubdomsState {
> +    TPMBackend parent;
> +    TPMBackendThread tbt;
> +    TPMXenstubdomsThreadParams tpm_thread_params;
> +    bool had_startup_error;
> +};
> +
> +typedef struct TPMXenstubdomsState TPMXenstubdomsState;
> +
> +/* functions */
> +
> +static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb);
> +
> +static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
> +{
> +    size_t rlen;
> +    xen_vtpm_send(locty_data->w_buffer.buffer, locty_data->w_offset);
> +    xen_vtpm_recv(locty_data->r_buffer.buffer, &rlen);
> +    return 0;
> +}

Don't try to make the xen_vtpm_send and xen_vtpm_recv call generic. You
could just called them directly from here, no abstraction.


> +static void tpm_xenstubdoms_worker_thread(gpointer data,
> +                                          gpointer user_data)
> +{
> +    TPMXenstubdomsThreadParams *thr_parms = user_data;
> +    TPMBackendCmd cmd = (TPMBackendCmd)data;
> +
> +    switch (cmd) {
> +    case TPM_BACKEND_CMD_PROCESS_CMD:
> +        /* here need a the cmd process function */
> +        tpm_xenstubdoms_unix_transfer(thr_parms->tpm_state->locty_data);
> +        thr_parms->recv_data_callback(thr_parms->tpm_state,
> +                                      thr_parms->tpm_state->locty_number);
> +        break;
> +    case TPM_BACKEND_CMD_INIT:
> +    case TPM_BACKEND_CMD_END:
> +    case TPM_BACKEND_CMD_TPM_RESET:
> +        /* nothing to do */
> +        break;
> +    }
> +}
> +
> +/*
> + *  * Start the TPM (thread). If it had been started before, then terminate
> + *   * and start it again.
> + *    */
> +static int tpm_xenstubdoms_startup_tpm(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_backend_thread_tpm_reset(&tpm_xs->tbt, tpm_xenstubdoms_worker_thread,
> +                                 &tpm_xs->tpm_thread_params);
> +
> +    return 0;
> +}
> +
> +static void tpm_xenstubdoms_reset(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_backend_thread_end(&tpm_xs->tbt);
> +    tpm_xs->had_startup_error = false;
> +}
> +
> +static int tpm_xenstubdoms_init(TPMBackend *tb, TPMState *s,
> +                                TPMRecvDataCB *recv_data_cb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_xs->tpm_thread_params.tpm_state = s;
> +    tpm_xs->tpm_thread_params.recv_data_callback = recv_data_cb;
> +    tpm_xs->tpm_thread_params.tb = tb;
> +    return 0;
> +}
> +
> +static bool tpm_xenstubdoms_get_tpm_established_flag(TPMBackend *tb)
> +{
> +    return false;
> +}
> +
> +static bool tpm_xenstubdoms_get_startup_error(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    return tpm_xs->had_startup_error;
> +}
> +
> +static size_t tpm_xenstubdoms_realloc_buffer(TPMSizedBuffer *sb)
> +{
> +    size_t wanted_size = 4096; /* Linux tpm.c buffer size */
> +
> +    if (sb->size != wanted_size) {
> +        sb->buffer = g_realloc(sb->buffer, wanted_size);
> +        sb->size = wanted_size;
> +    }
> +    return sb->size;
> +}
> +
> +static void tpm_xenstubdoms_deliver_request(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +    tpm_backend_thread_deliver_request(&tpm_xs->tbt);
> +}
> +
> +static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb)
> +{
> +}
> +
> +static const char *tpm_xenstubdoms_create_desc(void)
> +{
> +    return "Xenstubdoms TPM backend driver";
> +}
> +
> +static TPMBackend *tpm_xenstubdoms_create(QemuOpts *opts, const char *id)
> +{
> +    Object *obj = object_new(TYPE_TPM_XENSTUBDOMS);
> +    TPMBackend *tb = TPM_BACKEND(obj);
> +
> +    tb->id = g_strdup(id);
> +    tb->fe_model = -1;
> +    tb->ops = &tpm_xenstubdoms_driver;
> +    return tb;
> +}
> +
> +static void tpm_xenstubdoms_destroy(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xh = TPM_XENSTUBDOMS(tb);
> +    tpm_backend_thread_end(&tpm_xh->tbt);
> +
> +    g_free(tb->id);
> +}
> +
> +static const QemuOptDesc tpm_xenstubdoms_cmdline_opts[] = {
> +    TPM_STANDARD_CMDLINE_OPTS,
> +    {},
> +};
> +
> +static const TPMDriverOps tpm_xenstubdoms_driver = {
> +    .type                     = TPM_TYPE_XENSTUBDOMS,
> +    .opts                     = tpm_xenstubdoms_cmdline_opts,
> +    .desc                     = tpm_xenstubdoms_create_desc,
> +    .create                   = tpm_xenstubdoms_create,
> +    .destroy                  = tpm_xenstubdoms_destroy,
> +    .init                     = tpm_xenstubdoms_init,
> +    .startup_tpm              = tpm_xenstubdoms_startup_tpm,
> +    .realloc_buffer           = tpm_xenstubdoms_realloc_buffer,
> +    .reset                    = tpm_xenstubdoms_reset,
> +    .had_startup_error        = tpm_xenstubdoms_get_startup_error,
> +    .deliver_request          = tpm_xenstubdoms_deliver_request,
> +    .cancel_cmd               = tpm_xenstubdoms_cancel_cmd,
> +    .get_tpm_established_flag = tpm_xenstubdoms_get_tpm_established_flag,
> +};
> +
> +static void tpm_xenstubdoms_inst_init(Object *obj)
> +{
> +}
> +
> +static void tpm_xenstubdoms_inst_finalize(Object *obj)
> +{
> +}
> +
> +static void tpm_xenstubdoms_class_init(ObjectClass *klass, void *data)
> +{
> +    TPMBackendClass *tbc = TPM_BACKEND_CLASS(klass);
> +    tbc->ops = &tpm_xenstubdoms_driver;
> +}
> +
> +static const TypeInfo tpm_xenstubdoms_info = {
> +    .name = TYPE_TPM_XENSTUBDOMS,
> +    .parent = TYPE_TPM_BACKEND,
> +    .instance_size = sizeof(TPMXenstubdomsState),
> +    .class_init = tpm_xenstubdoms_class_init,
> +    .instance_init = tpm_xenstubdoms_inst_init,
> +    .instance_finalize = tpm_xenstubdoms_inst_finalize,
> +};
> +
> +static void tpm_xenstubdoms_register(void)
> +{
> +    type_register_static(&tpm_xenstubdoms_info);
> +    tpm_register_driver(&tpm_xenstubdoms_driver);
> +}
> +
> +type_init(tpm_xenstubdoms_register)
> -- 
> 1.8.3.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:20:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswN6-00032h-8J; Mon, 24 Nov 2014 16:20:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XswN4-00032Y-OY
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 16:20:14 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	84/BB-05632-EBA53745; Mon, 24 Nov 2014 16:20:14 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416846004!13538786!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7718 invoked from network); 24 Nov 2014 16:20:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 16:20:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="196144759"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 11:20:05 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XswMv-0002gb-Id;
	Mon, 24 Nov 2014 16:20:05 +0000
Date: Mon, 24 Nov 2014 16:20:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Quan Xu <quan.xu@intel.com>
In-Reply-To: <1416802259-9965-1-git-send-email-quan.xu@intel.com>
Message-ID: <alpine.DEB.2.02.1411241616160.2675@kaball.uk.xensource.com>
References: <1416802259-9965-1-git-send-email-quan.xu@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v2 3/4] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms
	driver.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 23 Nov 2014, Quan Xu wrote:
> This driver provides vTPM initialization and sending data and TPM
> commends to a Xen stubdom vTPM domain.
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>

We need a better, more detailed, patch description here.


>  hw/tpm/Makefile.objs     |   1 +
>  hw/tpm/tpm_xenstubdoms.c | 238 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 239 insertions(+)
>  create mode 100644 hw/tpm/tpm_xenstubdoms.c
> 
> diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
> index 87efb01..20f0a7b 100644
> --- a/hw/tpm/Makefile.objs
> +++ b/hw/tpm/Makefile.objs
> @@ -1,3 +1,4 @@
>  common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
>  common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
> +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o
>  common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
> new file mode 100644
> index 0000000..845df18
> --- /dev/null
> +++ b/hw/tpm/tpm_xenstubdoms.c
> @@ -0,0 +1,238 @@
> +/*
> + * Xen Stubdom vTPM driver
> + *
> + *  Copyright (c) 2014 Intel Corporation
> + *  Authors:
> + *    Quan Xu <quan.xu@intel.com>
> + *
> + * 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 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, see <http://www.gnu.org/licenses/>
> + */
> +
> +#include <dirent.h>
> +#include "qemu-common.h"
> +#include "qapi/error.h"
> +#include "qemu/sockets.h"
> +#include "qemu/log.h"
> +#include "sysemu/tpm_backend.h"
> +#include "tpm_int.h"
> +#include "hw/hw.h"
> +#include "hw/i386/pc.h"
> +#include "hw/xen/xen_backend.h"
> +#include "sysemu/tpm_backend_int.h"
> +#include "tpm_tis.h"
> +
> +#ifdef DEBUG_TPM
> +#define DPRINTF(fmt, ...) \
> +    do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTF(fmt, ...) \
> +    do { } while (0)
> +#endif
> +
> +#define TYPE_TPM_XENSTUBDOMS "tpm-xenstubdoms"
> +#define TPM_XENSTUBDOMS(obj) \
> +    OBJECT_CHECK(TPMXenstubdomsState, (obj), TYPE_TPM_XENSTUBDOMS)
> +
> +static const TPMDriverOps tpm_xenstubdoms_driver;
> +
> +/* data structures */
> +typedef struct TPMXenstubdomsThreadParams {
> +    TPMState *tpm_state;
> +    TPMRecvDataCB *recv_data_callback;
> +    TPMBackend *tb;
> +} TPMXenstubdomsThreadParams;
> +
> +struct TPMXenstubdomsState {
> +    TPMBackend parent;
> +    TPMBackendThread tbt;
> +    TPMXenstubdomsThreadParams tpm_thread_params;
> +    bool had_startup_error;
> +};
> +
> +typedef struct TPMXenstubdomsState TPMXenstubdomsState;
> +
> +/* functions */
> +
> +static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb);
> +
> +static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
> +{
> +    size_t rlen;
> +    xen_vtpm_send(locty_data->w_buffer.buffer, locty_data->w_offset);
> +    xen_vtpm_recv(locty_data->r_buffer.buffer, &rlen);
> +    return 0;
> +}

Don't try to make the xen_vtpm_send and xen_vtpm_recv call generic. You
could just called them directly from here, no abstraction.


> +static void tpm_xenstubdoms_worker_thread(gpointer data,
> +                                          gpointer user_data)
> +{
> +    TPMXenstubdomsThreadParams *thr_parms = user_data;
> +    TPMBackendCmd cmd = (TPMBackendCmd)data;
> +
> +    switch (cmd) {
> +    case TPM_BACKEND_CMD_PROCESS_CMD:
> +        /* here need a the cmd process function */
> +        tpm_xenstubdoms_unix_transfer(thr_parms->tpm_state->locty_data);
> +        thr_parms->recv_data_callback(thr_parms->tpm_state,
> +                                      thr_parms->tpm_state->locty_number);
> +        break;
> +    case TPM_BACKEND_CMD_INIT:
> +    case TPM_BACKEND_CMD_END:
> +    case TPM_BACKEND_CMD_TPM_RESET:
> +        /* nothing to do */
> +        break;
> +    }
> +}
> +
> +/*
> + *  * Start the TPM (thread). If it had been started before, then terminate
> + *   * and start it again.
> + *    */
> +static int tpm_xenstubdoms_startup_tpm(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_backend_thread_tpm_reset(&tpm_xs->tbt, tpm_xenstubdoms_worker_thread,
> +                                 &tpm_xs->tpm_thread_params);
> +
> +    return 0;
> +}
> +
> +static void tpm_xenstubdoms_reset(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_backend_thread_end(&tpm_xs->tbt);
> +    tpm_xs->had_startup_error = false;
> +}
> +
> +static int tpm_xenstubdoms_init(TPMBackend *tb, TPMState *s,
> +                                TPMRecvDataCB *recv_data_cb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    tpm_xs->tpm_thread_params.tpm_state = s;
> +    tpm_xs->tpm_thread_params.recv_data_callback = recv_data_cb;
> +    tpm_xs->tpm_thread_params.tb = tb;
> +    return 0;
> +}
> +
> +static bool tpm_xenstubdoms_get_tpm_established_flag(TPMBackend *tb)
> +{
> +    return false;
> +}
> +
> +static bool tpm_xenstubdoms_get_startup_error(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +
> +    return tpm_xs->had_startup_error;
> +}
> +
> +static size_t tpm_xenstubdoms_realloc_buffer(TPMSizedBuffer *sb)
> +{
> +    size_t wanted_size = 4096; /* Linux tpm.c buffer size */
> +
> +    if (sb->size != wanted_size) {
> +        sb->buffer = g_realloc(sb->buffer, wanted_size);
> +        sb->size = wanted_size;
> +    }
> +    return sb->size;
> +}
> +
> +static void tpm_xenstubdoms_deliver_request(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xs = TPM_XENSTUBDOMS(tb);
> +    tpm_backend_thread_deliver_request(&tpm_xs->tbt);
> +}
> +
> +static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb)
> +{
> +}
> +
> +static const char *tpm_xenstubdoms_create_desc(void)
> +{
> +    return "Xenstubdoms TPM backend driver";
> +}
> +
> +static TPMBackend *tpm_xenstubdoms_create(QemuOpts *opts, const char *id)
> +{
> +    Object *obj = object_new(TYPE_TPM_XENSTUBDOMS);
> +    TPMBackend *tb = TPM_BACKEND(obj);
> +
> +    tb->id = g_strdup(id);
> +    tb->fe_model = -1;
> +    tb->ops = &tpm_xenstubdoms_driver;
> +    return tb;
> +}
> +
> +static void tpm_xenstubdoms_destroy(TPMBackend *tb)
> +{
> +    TPMXenstubdomsState *tpm_xh = TPM_XENSTUBDOMS(tb);
> +    tpm_backend_thread_end(&tpm_xh->tbt);
> +
> +    g_free(tb->id);
> +}
> +
> +static const QemuOptDesc tpm_xenstubdoms_cmdline_opts[] = {
> +    TPM_STANDARD_CMDLINE_OPTS,
> +    {},
> +};
> +
> +static const TPMDriverOps tpm_xenstubdoms_driver = {
> +    .type                     = TPM_TYPE_XENSTUBDOMS,
> +    .opts                     = tpm_xenstubdoms_cmdline_opts,
> +    .desc                     = tpm_xenstubdoms_create_desc,
> +    .create                   = tpm_xenstubdoms_create,
> +    .destroy                  = tpm_xenstubdoms_destroy,
> +    .init                     = tpm_xenstubdoms_init,
> +    .startup_tpm              = tpm_xenstubdoms_startup_tpm,
> +    .realloc_buffer           = tpm_xenstubdoms_realloc_buffer,
> +    .reset                    = tpm_xenstubdoms_reset,
> +    .had_startup_error        = tpm_xenstubdoms_get_startup_error,
> +    .deliver_request          = tpm_xenstubdoms_deliver_request,
> +    .cancel_cmd               = tpm_xenstubdoms_cancel_cmd,
> +    .get_tpm_established_flag = tpm_xenstubdoms_get_tpm_established_flag,
> +};
> +
> +static void tpm_xenstubdoms_inst_init(Object *obj)
> +{
> +}
> +
> +static void tpm_xenstubdoms_inst_finalize(Object *obj)
> +{
> +}
> +
> +static void tpm_xenstubdoms_class_init(ObjectClass *klass, void *data)
> +{
> +    TPMBackendClass *tbc = TPM_BACKEND_CLASS(klass);
> +    tbc->ops = &tpm_xenstubdoms_driver;
> +}
> +
> +static const TypeInfo tpm_xenstubdoms_info = {
> +    .name = TYPE_TPM_XENSTUBDOMS,
> +    .parent = TYPE_TPM_BACKEND,
> +    .instance_size = sizeof(TPMXenstubdomsState),
> +    .class_init = tpm_xenstubdoms_class_init,
> +    .instance_init = tpm_xenstubdoms_inst_init,
> +    .instance_finalize = tpm_xenstubdoms_inst_finalize,
> +};
> +
> +static void tpm_xenstubdoms_register(void)
> +{
> +    type_register_static(&tpm_xenstubdoms_info);
> +    tpm_register_driver(&tpm_xenstubdoms_driver);
> +}
> +
> +type_init(tpm_xenstubdoms_register)
> -- 
> 1.8.3.2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:21:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 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 1XswOC-00038k-Hg; Mon, 24 Nov 2014 16:21:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1XswOB-00038a-2M
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 16:21:23 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	D9/D5-25727-20B53745; Mon, 24 Nov 2014 16:21:22 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416846079!13539056!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13713 invoked from network); 24 Nov 2014 16:21:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 16:21:21 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAOGLCkK019370
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 24 Nov 2014 11:21:12 -0500
Received: from [10.3.113.9] ([10.3.113.9])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAOGLBtq031659; Mon, 24 Nov 2014 11:21:11 -0500
Message-ID: <54735AF7.2060103@redhat.com>
Date: Mon, 24 Nov 2014 09:21:11 -0700
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20141120101240.2a75f384@m> <546E7674.1060204@redhat.com>	
	<546FD5D2.60400@redhat.com> <1416822231.26329.19.camel@citrix.com>
In-Reply-To: <1416822231.26329.19.camel@citrix.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: libvir-list@redhat.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	cemeyer@uw.edu, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH 1/2] virdbus: don't force users to
 pass int for bool values
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3290284648009694906=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============3290284648009694906==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="BHrSQLE3WnjDgxJUjFQdeqRUGoxx6mp98"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--BHrSQLE3WnjDgxJUjFQdeqRUGoxx6mp98
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/24/2014 02:43 AM, Ian Campbell wrote:

>>>>
>>>> I think this change breaks build on FreeBSD:
>>>>
>>>>   CC       util/libvirt_util_la-virdbus.lo
>>>> util/virdbus.c:956:13: error: cast from 'bool *' to 'dbus_bool_t *' =
(aka 'unsigned int *') increases required alignment from 1 to 4 [-Werror,=
-Wcast-align]
>>>>             GET_NEXT_VAL(dbus_bool_t, bool_val, bool, "%d");
>>>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> util/virdbus.c:858:17: note: expanded from macro 'GET_NEXT_VAL'
>>>>             x =3D (dbustype *)(*xptrptr + (*narrayptr - 1));        =
      \
>>>>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error ge=
nerated.
>>>
>>> Valid complaint, so I'll have to figure something out to avoid it.  :=
(

> I'm, guessing that this is the same underlying issue as:
>         util/virdbus.c: In function 'virDBusMessageIterDecode':
>         util/virdbus.c:956:346: error: cast increases required alignmen=
t of target type [-Werror=3Dcast-align]

Yes.

>        =20
> which we are seeing in the Xen automated tests [0, 1] (on armhf only,
> probably compiler dependent?).

So, do I have an ACK on my proposed fix yet? :)
https://www.redhat.com/archives/libvir-list/2014-November/msg00838.html

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--BHrSQLE3WnjDgxJUjFQdeqRUGoxx6mp98
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
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg

iQEcBAEBCAAGBQJUc1r3AAoJEKeha0olJ0NqNE4H+wX1LUqNGCPU7Q+sI9Q+I8fB
mqO6K09IGDYUWtPmSh227V0LZR5llM81GQk+B3wDCpc5NR0Ssw4vLyTBb+nvmBFP
qVUx+UG2JZ4rESwIwrZW66gL3HG9ExkcXHTDTBlCme/ba7XwDk1FPSYI012CIOv1
GZHMfQfc2nkm7Pm/XsHerTKV2jhgRP+Cwu+doE8F0PiieP7cbDVTAVlbyMQfTkd9
HTkjzVybwAlm2SQ4+lUHJ6FFQGIdkRXpoIPJ3HbnAV71gApDN+VmeNNFy4dMlbVm
AT98ANuZr5MCVi6piID5LlC4CGADKkIa38twIeBDTojgk1vUGlU2XIxuSYG7zyg=
=PiwK
-----END PGP SIGNATURE-----

--BHrSQLE3WnjDgxJUjFQdeqRUGoxx6mp98--


--===============3290284648009694906==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3290284648009694906==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 16:21:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 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 1XswOC-00038k-Hg; Mon, 24 Nov 2014 16:21:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1XswOB-00038a-2M
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 16:21:23 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	D9/D5-25727-20B53745; Mon, 24 Nov 2014 16:21:22 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416846079!13539056!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13713 invoked from network); 24 Nov 2014 16:21:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 16:21:21 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAOGLCkK019370
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 24 Nov 2014 11:21:12 -0500
Received: from [10.3.113.9] ([10.3.113.9])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAOGLBtq031659; Mon, 24 Nov 2014 11:21:11 -0500
Message-ID: <54735AF7.2060103@redhat.com>
Date: Mon, 24 Nov 2014 09:21:11 -0700
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20141120101240.2a75f384@m> <546E7674.1060204@redhat.com>	
	<546FD5D2.60400@redhat.com> <1416822231.26329.19.camel@citrix.com>
In-Reply-To: <1416822231.26329.19.camel@citrix.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: libvir-list@redhat.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	cemeyer@uw.edu, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH 1/2] virdbus: don't force users to
 pass int for bool values
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3290284648009694906=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============3290284648009694906==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="BHrSQLE3WnjDgxJUjFQdeqRUGoxx6mp98"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--BHrSQLE3WnjDgxJUjFQdeqRUGoxx6mp98
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/24/2014 02:43 AM, Ian Campbell wrote:

>>>>
>>>> I think this change breaks build on FreeBSD:
>>>>
>>>>   CC       util/libvirt_util_la-virdbus.lo
>>>> util/virdbus.c:956:13: error: cast from 'bool *' to 'dbus_bool_t *' =
(aka 'unsigned int *') increases required alignment from 1 to 4 [-Werror,=
-Wcast-align]
>>>>             GET_NEXT_VAL(dbus_bool_t, bool_val, bool, "%d");
>>>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> util/virdbus.c:858:17: note: expanded from macro 'GET_NEXT_VAL'
>>>>             x =3D (dbustype *)(*xptrptr + (*narrayptr - 1));        =
      \
>>>>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error ge=
nerated.
>>>
>>> Valid complaint, so I'll have to figure something out to avoid it.  :=
(

> I'm, guessing that this is the same underlying issue as:
>         util/virdbus.c: In function 'virDBusMessageIterDecode':
>         util/virdbus.c:956:346: error: cast increases required alignmen=
t of target type [-Werror=3Dcast-align]

Yes.

>        =20
> which we are seeing in the Xen automated tests [0, 1] (on armhf only,
> probably compiler dependent?).

So, do I have an ACK on my proposed fix yet? :)
https://www.redhat.com/archives/libvir-list/2014-November/msg00838.html

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--BHrSQLE3WnjDgxJUjFQdeqRUGoxx6mp98
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
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg

iQEcBAEBCAAGBQJUc1r3AAoJEKeha0olJ0NqNE4H+wX1LUqNGCPU7Q+sI9Q+I8fB
mqO6K09IGDYUWtPmSh227V0LZR5llM81GQk+B3wDCpc5NR0Ssw4vLyTBb+nvmBFP
qVUx+UG2JZ4rESwIwrZW66gL3HG9ExkcXHTDTBlCme/ba7XwDk1FPSYI012CIOv1
GZHMfQfc2nkm7Pm/XsHerTKV2jhgRP+Cwu+doE8F0PiieP7cbDVTAVlbyMQfTkd9
HTkjzVybwAlm2SQ4+lUHJ6FFQGIdkRXpoIPJ3HbnAV71gApDN+VmeNNFy4dMlbVm
AT98ANuZr5MCVi6piID5LlC4CGADKkIa38twIeBDTojgk1vUGlU2XIxuSYG7zyg=
=PiwK
-----END PGP SIGNATURE-----

--BHrSQLE3WnjDgxJUjFQdeqRUGoxx6mp98--


--===============3290284648009694906==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3290284648009694906==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 16:21:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:21:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswOb-0003Cy-Ux; Mon, 24 Nov 2014 16:21:49 +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 1XswOa-0003CR-1T
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 16:21:48 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	FE/AA-14727-B1B53745; Mon, 24 Nov 2014 16:21:47 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416846104!13045581!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23522 invoked from network); 24 Nov 2014 16:21:46 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 16:21:46 -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
	sAOGKLO6031335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 24 Nov 2014 11:20:22 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sAOGKKQH031333;
	Mon, 24 Nov 2014 11:20:20 -0500
Date: Mon, 24 Nov 2014 12:20:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: konrad.wilk@oracle.com
Message-ID: <20141124162020.GA30888@andromeda.dapyr.net>
References: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: artem.mygaiev@globallogic.com, Steve.VanderLeest@dornerworks.com,
	mengxu@cis.upenn.edu, m.a.young@durham.ac.uk,
	chao.p.peng@linux.intel.com, zhigang.x.wang@oracle.com,
	parth.dixit@linaro.org, boris.ostrovsky@oracle.com,
	manishjaggi.oss@gmail.com, Paul.Skentzos@dornerworks.com,
	vijay.kilari@gmail.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, daniel.kiper@oracle.com,
	josh.whitehead@dornerworks.com, avanzini.arianna@gmail.com,
	anthony.perard@citrix.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, feng.wu@intel.com,
	yjhyun.yoo@samsung.com, suriyan.r@gmail.com,
	ian.campbell@citrix.com, wency@cn.fujitsu.com,
	stefano.stabellini@eu.citrix.com, mcgrof@suse.com,
	julien.grall@linaro.org, talex5@gmail.com,
	robert.vanvossen@dornerworks.com, roy.franz@linaro.org,
	yang.z.zhang@intel.com, Paul.Durrant@citrix.com, olaf@aepfle.d.e,
	ufimtseva@gmail.com, andrii.tseglytskyi@globallogic.com,
	jgross@suse.com, dave.scott@citrix.com, yanghy@cn.fujitsu.com,
	Wei.Liu2@citrix.com, Vijaya.Kumar@caviumnetworks.com,
	george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	dario.faggioli@citrix.com, eddie.dong@intel.com,
	Kelly.Zytaruk@amd.com, dslutz@verizon.com,
	tklengyel@sec.in.tum.de, ross.lagerwall@citrix.com,
	Aravind.Gopalakrishnan@amd.com, david.vrabel@citrix.com,
	Suravee.Suthikulpanit@amd.com, aravindp@cisco.com,
	tiejun.chen@intel.com, malcolm.crossley@citrix.com,
	caobosimon@gmail.com, ian.jackson@eu.citrix.com,
	christoffer.dall@linaro.org, roger.pau@citrix.com
Subject: [Xen-devel] Is: Slip. RC3 out to Dec 3rd. Was:Re: Xen 4.5-rc2 post
	update (RC2 was out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> = Timeline =
> 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> 
> 
> * Feature Freeze: 24th September 2014
> * First RC: 24th October [Friday!]
> * RC2: Nov 11th
> * RC2 Test-day: Nov 13th
> 
>  <==== WE ARE HERE ===>
> 
> * RC3: Nov 24th

Slip. We still have outstanding bugs (two of which are regressions)
which I would very much like to have in RC3. As such we are slipping
with RC3 to Dec 3rd, which means:

> * RC3 Test-day: Nov 25th
> * Release: 10th December 2014

That this date is moved out. Based on my previous way I would have
moved it by a week - which moves the release to the 17th (and test
day on Friday). But that is way way to close for me and I don't think
we will have anybody testing on Fri 18th to the end of the year.

Instead we are going to do:

 RC3: Dec 3rd.
 RC3 Test-day: Dec 4th (or 7th).

 RC4: Dec 15th
 RC4 Test-day: Dec 17th

 Release Date: Jan 7th.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:21:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:21:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswOb-0003Cy-Ux; Mon, 24 Nov 2014 16:21:49 +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 1XswOa-0003CR-1T
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 16:21:48 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	FE/AA-14727-B1B53745; Mon, 24 Nov 2014 16:21:47 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416846104!13045581!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23522 invoked from network); 24 Nov 2014 16:21:46 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 16:21:46 -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
	sAOGKLO6031335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 24 Nov 2014 11:20:22 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sAOGKKQH031333;
	Mon, 24 Nov 2014 11:20:20 -0500
Date: Mon, 24 Nov 2014 12:20:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: konrad.wilk@oracle.com
Message-ID: <20141124162020.GA30888@andromeda.dapyr.net>
References: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141121174212.0FF83118AA5@laptop.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: artem.mygaiev@globallogic.com, Steve.VanderLeest@dornerworks.com,
	mengxu@cis.upenn.edu, m.a.young@durham.ac.uk,
	chao.p.peng@linux.intel.com, zhigang.x.wang@oracle.com,
	parth.dixit@linaro.org, boris.ostrovsky@oracle.com,
	manishjaggi.oss@gmail.com, Paul.Skentzos@dornerworks.com,
	vijay.kilari@gmail.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, daniel.kiper@oracle.com,
	josh.whitehead@dornerworks.com, avanzini.arianna@gmail.com,
	anthony.perard@citrix.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, feng.wu@intel.com,
	yjhyun.yoo@samsung.com, suriyan.r@gmail.com,
	ian.campbell@citrix.com, wency@cn.fujitsu.com,
	stefano.stabellini@eu.citrix.com, mcgrof@suse.com,
	julien.grall@linaro.org, talex5@gmail.com,
	robert.vanvossen@dornerworks.com, roy.franz@linaro.org,
	yang.z.zhang@intel.com, Paul.Durrant@citrix.com, olaf@aepfle.d.e,
	ufimtseva@gmail.com, andrii.tseglytskyi@globallogic.com,
	jgross@suse.com, dave.scott@citrix.com, yanghy@cn.fujitsu.com,
	Wei.Liu2@citrix.com, Vijaya.Kumar@caviumnetworks.com,
	george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	dario.faggioli@citrix.com, eddie.dong@intel.com,
	Kelly.Zytaruk@amd.com, dslutz@verizon.com,
	tklengyel@sec.in.tum.de, ross.lagerwall@citrix.com,
	Aravind.Gopalakrishnan@amd.com, david.vrabel@citrix.com,
	Suravee.Suthikulpanit@amd.com, aravindp@cisco.com,
	tiejun.chen@intel.com, malcolm.crossley@citrix.com,
	caobosimon@gmail.com, ian.jackson@eu.citrix.com,
	christoffer.dall@linaro.org, roger.pau@citrix.com
Subject: [Xen-devel] Is: Slip. RC3 out to Dec 3rd. Was:Re: Xen 4.5-rc2 post
	update (RC2 was out 2014-Nov-11th)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> = Timeline =
> 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> 
> 
> * Feature Freeze: 24th September 2014
> * First RC: 24th October [Friday!]
> * RC2: Nov 11th
> * RC2 Test-day: Nov 13th
> 
>  <==== WE ARE HERE ===>
> 
> * RC3: Nov 24th

Slip. We still have outstanding bugs (two of which are regressions)
which I would very much like to have in RC3. As such we are slipping
with RC3 to Dec 3rd, which means:

> * RC3 Test-day: Nov 25th
> * Release: 10th December 2014

That this date is moved out. Based on my previous way I would have
moved it by a week - which moves the release to the 17th (and test
day on Friday). But that is way way to close for me and I don't think
we will have anybody testing on Fri 18th to the end of the year.

Instead we are going to do:

 RC3: Dec 3rd.
 RC3 Test-day: Dec 4th (or 7th).

 RC4: Dec 15th
 RC4 Test-day: Dec 17th

 Release Date: Jan 7th.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:28:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:28:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswUt-0003gr-Po; Mon, 24 Nov 2014 16:28:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XswUs-0003gk-SR
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 16:28:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B6/0B-09842-2AC53745; Mon, 24 Nov 2014 16:28:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416846495!12824825!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6256 invoked from network); 24 Nov 2014 16:28:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 16:28:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195350347"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 11:25:19 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XswRz-0002nA-4L;
	Mon, 24 Nov 2014 16:25:19 +0000
Date: Mon, 24 Nov 2014 16:25:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411241544410.2675@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411241623500.2675@kaball.uk.xensource.com>
References: <1416802256-9928-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411241544410.2675@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: qemu-devel@nongnu.org, Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
 frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> On Sun, 23 Nov 2014, Quan Xu wrote:
> > +static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> > +                                              xendev);
> > +    int be_state;
> > +
> > +    if (strcmp(node, "state") == 0) {
> > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > +        switch (be_state) {
> > +        case XenbusStateConnected:
> > +            /*TODO*/
> > +            break;
> > +        case XenbusStateClosing:
> > +        case XenbusStateClosed:
> > +            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
> > +            break;
> > +        default:
> > +            break;
> > +        }
> > +    }
> > +}
> 
> This would probably end up in xen_backend.c

Sorry, I meant xen_frontend.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:28:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:28:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XswUt-0003gr-Po; Mon, 24 Nov 2014 16:28:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XswUs-0003gk-SR
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 16:28:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B6/0B-09842-2AC53745; Mon, 24 Nov 2014 16:28:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1416846495!12824825!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6256 invoked from network); 24 Nov 2014 16:28:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 16:28:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208";a="195350347"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 11:25:19 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XswRz-0002nA-4L;
	Mon, 24 Nov 2014 16:25:19 +0000
Date: Mon, 24 Nov 2014 16:25:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411241544410.2675@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411241623500.2675@kaball.uk.xensource.com>
References: <1416802256-9928-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411241544410.2675@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: qemu-devel@nongnu.org, Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
 frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> On Sun, 23 Nov 2014, Quan Xu wrote:
> > +static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct XenVtpmDev,
> > +                                              xendev);
> > +    int be_state;
> > +
> > +    if (strcmp(node, "state") == 0) {
> > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > +        switch (be_state) {
> > +        case XenbusStateConnected:
> > +            /*TODO*/
> > +            break;
> > +        case XenbusStateClosing:
> > +        case XenbusStateClosed:
> > +            xenbus_switch_state(&vtpmdev->xendev, XenbusStateClosing);
> > +            break;
> > +        default:
> > +            break;
> > +        }
> > +    }
> > +}
> 
> This would probably end up in xen_backend.c

Sorry, I meant xen_frontend.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:36:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:36:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xswcm-0003z5-Pf; Mon, 24 Nov 2014 16:36:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xswcl-0003z0-UI
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 16:36:28 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2D/3D-15461-B8E53745; Mon, 24 Nov 2014 16:36:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416846985!14968834!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26972 invoked from network); 24 Nov 2014 16:36:26 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 16:36:26 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOGaOFW028251
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 16:36:25 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOGaNLN027583
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 16:36:24 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOGaNml027578; Mon, 24 Nov 2014 16:36:23 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 08:36:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A74D1119349; Mon, 24 Nov 2014 11:36:22 -0500 (EST)
Date: Mon, 24 Nov 2014 11:36:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124163622.GA7449@laptop.dumpdata.com>
References: <547328E0020000780004A4A1@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547328E0020000780004A4A1@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] x86/cpuidle: don't count C1 multiple times
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 11:47:28AM +0000, Jan Beulich wrote:
> Commit 4ca6f9f0 ("x86/cpuidle: publish new states only after fully
> initializing them") resulted in the state counter to be incremented
> for C1 despite that using a fixed table entry (and the statically
> initialized counter value already accounting for it and C0).
> 

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reported-by: Steve Freitas <sflist@ihonk.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(thought it would be good to get from Steve an confirmation that this
fixes it - which I believe is 99% the case).

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -1015,7 +1015,7 @@ static void set_cx(
>      cx->target_residency = cx->latency * latency_factor;
>  
>      smp_wmb();
> -    acpi_power->count++;
> +    acpi_power->count += (cx->type != ACPI_STATE_C1);
>      if ( cx->type == ACPI_STATE_C1 || cx->type == ACPI_STATE_C2 )
>          acpi_power->safe_state = cx;
>  }
> 
> 
> 

> x86/cpuidle: don't count C1 multiple times
> 
> Commit 4ca6f9f0 ("x86/cpuidle: publish new states only after fully
> initializing them") resulted in the state counter to be incremented
> for C1 despite that using a fixed table entry (and the statically
> initialized counter value already accounting for it and C0).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -1015,7 +1015,7 @@ static void set_cx(
>      cx->target_residency = cx->latency * latency_factor;
>  
>      smp_wmb();
> -    acpi_power->count++;
> +    acpi_power->count += (cx->type != ACPI_STATE_C1);
>      if ( cx->type == ACPI_STATE_C1 || cx->type == ACPI_STATE_C2 )
>          acpi_power->safe_state = cx;
>  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 16:36:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 16:36:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xswcm-0003z5-Pf; Mon, 24 Nov 2014 16:36:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xswcl-0003z0-UI
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 16:36:28 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2D/3D-15461-B8E53745; Mon, 24 Nov 2014 16:36:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416846985!14968834!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26972 invoked from network); 24 Nov 2014 16:36:26 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 16:36:26 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOGaOFW028251
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 16:36:25 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOGaNLN027583
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 16:36:24 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOGaNml027578; Mon, 24 Nov 2014 16:36:23 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 08:36:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A74D1119349; Mon, 24 Nov 2014 11:36:22 -0500 (EST)
Date: Mon, 24 Nov 2014 11:36:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124163622.GA7449@laptop.dumpdata.com>
References: <547328E0020000780004A4A1@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547328E0020000780004A4A1@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] x86/cpuidle: don't count C1 multiple times
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 11:47:28AM +0000, Jan Beulich wrote:
> Commit 4ca6f9f0 ("x86/cpuidle: publish new states only after fully
> initializing them") resulted in the state counter to be incremented
> for C1 despite that using a fixed table entry (and the statically
> initialized counter value already accounting for it and C0).
> 

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reported-by: Steve Freitas <sflist@ihonk.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(thought it would be good to get from Steve an confirmation that this
fixes it - which I believe is 99% the case).

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -1015,7 +1015,7 @@ static void set_cx(
>      cx->target_residency = cx->latency * latency_factor;
>  
>      smp_wmb();
> -    acpi_power->count++;
> +    acpi_power->count += (cx->type != ACPI_STATE_C1);
>      if ( cx->type == ACPI_STATE_C1 || cx->type == ACPI_STATE_C2 )
>          acpi_power->safe_state = cx;
>  }
> 
> 
> 

> x86/cpuidle: don't count C1 multiple times
> 
> Commit 4ca6f9f0 ("x86/cpuidle: publish new states only after fully
> initializing them") resulted in the state counter to be incremented
> for C1 despite that using a fixed table entry (and the statically
> initialized counter value already accounting for it and C0).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -1015,7 +1015,7 @@ static void set_cx(
>      cx->target_residency = cx->latency * latency_factor;
>  
>      smp_wmb();
> -    acpi_power->count++;
> +    acpi_power->count += (cx->type != ACPI_STATE_C1);
>      if ( cx->type == ACPI_STATE_C1 || cx->type == ACPI_STATE_C2 )
>          acpi_power->safe_state = cx;
>  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 17:09:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsx8f-0004vq-FT; Mon, 24 Nov 2014 17:09:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xsx8e-0004vl-Gy
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 17:09:24 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	82/40-25727-34663745; Mon, 24 Nov 2014 17:09:23 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416848960!13479402!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13783 invoked from network); 24 Nov 2014 17:09:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 17:09:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,450,1413244800"; d="scan'208";a="196167300"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 12:07:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xsx6q-0003b0-SO;
	Mon, 24 Nov 2014 17:07:32 +0000
Date: Mon, 24 Nov 2014 17:07:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Don Slutz <dslutz@verizon.com>
In-Reply-To: <5473582C.6080000@terremark.com>
Message-ID: <alpine.DEB.2.02.1411241706090.2675@kaball.uk.xensource.com>
References: <1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
	<20141124150649.GB3946@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
	<5473582C.6080000@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Don Slutz wrote:
> On 11/24/14 10:26, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
> > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> > > > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini
> > > > > > > wrote:
> > > > > > > > The rom is used for pxebooting. We don't need to allow
> > > > > > > > pxebooting from
> > > > > > > > more than one network card.  Loading a romfile for every NIC
> > > > > > > > wastes
> > > > > > > Why not? Why can't we PXE boot from each network card?
> > > > > > I take it back: you are right, at the moment it is actually possible
> > > > > > to
> > > > > > pxe boot from the fourth nic for example. Maybe we could just load
> > > > > > the
> > > > > > first four romfiles and skip the others (four is the limit before
> > > > > > QEMU
> > > > > > fails to allocate any more memory).
> > > > > The limit is in the count of ROMs or the memory consumption?
> > > > The limit is memory consumption.
> > > Um, how big are those ROMs? Gigs?
> > I think they are 60K each in the case of rtl8139.
> > However they are accounted on top of the ram of the guest, that's why
> > the allocation fails. Strictly speaking I guess it shouldn't work even
> > the first time around.
> 
> My extra QEMU debug says:
> 
> xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42010000
> mr.name=rtl8139.rom
> e1000 vhdr enabled
> xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42050000
> mr.name=e1000.rom
> 
> And that matches the max of 4.
> 
> #define LIBXL_MAXMEM_CONSTANT 1024
> 
> is what controls this.
> 
> > Maybe the bug is in libxl memory allocation, that doesn't account for
> > rom sizes.
> 
> Yes.

Here is a better patch.

---

libxl: account for romfile memory

Account for memory needed for emulated network card rom files.
Assume 256K for each romfile.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..2edb194 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4527,6 +4527,33 @@ out:
 
 /******************************************************************************/
 
+int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
+{
+    int i, count_rom, rc;
+    libxl_domain_config local_d_config;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    if (d_config == NULL) {
+        libxl_domain_config_init(&local_d_config);
+        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
+        if (rc < 0)
+            return rc;
+        d_config = &local_d_config;
+    }
+
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
+        return 0;
+
+    for (i = 0, count_rom = 0; i < d_config->num_nics; i++) {
+        if (d_config->nics[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU)
+            count_rom++;
+    }
+
+    return count_rom*LIBXL_ROMSIZE_KB;
+
+    return 0;
+}
+
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 {
     GC_INIT(ctx);
@@ -4550,11 +4577,14 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
         goto out;
     }
-    rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + LIBXL_MAXMEM_CONSTANT);
+    rc = xc_domain_setmaxmem(ctx->xch, domid,
+                             max_memkb + LIBXL_MAXMEM_CONSTANT
+                             + libxl__get_rom_memory_kb(gc, domid, NULL));
     if (rc != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "xc_domain_setmaxmem domid=%d memkb=%d failed "
-                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
+                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT +
+                libxl__get_rom_memory_kb(gc, domid, NULL), rc);
         goto out;
     }
 
@@ -4770,11 +4800,12 @@ retry_transaction:
     if (enforce) {
         memorykb = new_target_memkb;
         rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
-                LIBXL_MAXMEM_CONSTANT);
+                LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid, NULL));
         if (rc != 0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
-                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
+                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT +
+                    libxl__get_rom_memory_kb(gc, domid, NULL), rc);
             abort_transaction = 1;
             goto out;
         }
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..ca254f9 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -406,7 +406,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     }
 
     if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
-        LIBXL_MAXMEM_CONSTANT) < 0) {
+        LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid, d_config)) < 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't set max memory");
         return ERROR_FAIL;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..33826ea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -90,6 +90,7 @@
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
 #define LIBXL_MAXMEM_CONSTANT 1024
+#define LIBXL_ROMSIZE_KB 256
 #define LIBXL_PV_EXTRA_MEMORY 1024
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
@@ -1023,6 +1024,12 @@ _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
                                           uint32_t domid, const char *cmd);
 
+/* Returns the amount of extra mem required to allocate roms or an libxl
+ * error code on error.
+ * The *d_config parameter is optional.
+ */
+_hidden int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
+
 /* from xl_device */
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 17:09:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsx8f-0004vq-FT; Mon, 24 Nov 2014 17:09:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xsx8e-0004vl-Gy
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 17:09:24 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	82/40-25727-34663745; Mon, 24 Nov 2014 17:09:23 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416848960!13479402!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13783 invoked from network); 24 Nov 2014 17:09:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 17:09:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,450,1413244800"; d="scan'208";a="196167300"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 12:07:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xsx6q-0003b0-SO;
	Mon, 24 Nov 2014 17:07:32 +0000
Date: Mon, 24 Nov 2014 17:07:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Don Slutz <dslutz@verizon.com>
In-Reply-To: <5473582C.6080000@terremark.com>
Message-ID: <alpine.DEB.2.02.1411241706090.2675@kaball.uk.xensource.com>
References: <1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
	<20141124150649.GB3946@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
	<5473582C.6080000@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Don Slutz wrote:
> On 11/24/14 10:26, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
> > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
> > > > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini
> > > > > > > wrote:
> > > > > > > > The rom is used for pxebooting. We don't need to allow
> > > > > > > > pxebooting from
> > > > > > > > more than one network card.  Loading a romfile for every NIC
> > > > > > > > wastes
> > > > > > > Why not? Why can't we PXE boot from each network card?
> > > > > > I take it back: you are right, at the moment it is actually possible
> > > > > > to
> > > > > > pxe boot from the fourth nic for example. Maybe we could just load
> > > > > > the
> > > > > > first four romfiles and skip the others (four is the limit before
> > > > > > QEMU
> > > > > > fails to allocate any more memory).
> > > > > The limit is in the count of ROMs or the memory consumption?
> > > > The limit is memory consumption.
> > > Um, how big are those ROMs? Gigs?
> > I think they are 60K each in the case of rtl8139.
> > However they are accounted on top of the ram of the guest, that's why
> > the allocation fails. Strictly speaking I guess it shouldn't work even
> > the first time around.
> 
> My extra QEMU debug says:
> 
> xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42010000
> mr.name=rtl8139.rom
> e1000 vhdr enabled
> xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42050000
> mr.name=e1000.rom
> 
> And that matches the max of 4.
> 
> #define LIBXL_MAXMEM_CONSTANT 1024
> 
> is what controls this.
> 
> > Maybe the bug is in libxl memory allocation, that doesn't account for
> > rom sizes.
> 
> Yes.

Here is a better patch.

---

libxl: account for romfile memory

Account for memory needed for emulated network card rom files.
Assume 256K for each romfile.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..2edb194 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4527,6 +4527,33 @@ out:
 
 /******************************************************************************/
 
+int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
+{
+    int i, count_rom, rc;
+    libxl_domain_config local_d_config;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    if (d_config == NULL) {
+        libxl_domain_config_init(&local_d_config);
+        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
+        if (rc < 0)
+            return rc;
+        d_config = &local_d_config;
+    }
+
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
+        return 0;
+
+    for (i = 0, count_rom = 0; i < d_config->num_nics; i++) {
+        if (d_config->nics[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU)
+            count_rom++;
+    }
+
+    return count_rom*LIBXL_ROMSIZE_KB;
+
+    return 0;
+}
+
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 {
     GC_INIT(ctx);
@@ -4550,11 +4577,14 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
         goto out;
     }
-    rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + LIBXL_MAXMEM_CONSTANT);
+    rc = xc_domain_setmaxmem(ctx->xch, domid,
+                             max_memkb + LIBXL_MAXMEM_CONSTANT
+                             + libxl__get_rom_memory_kb(gc, domid, NULL));
     if (rc != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "xc_domain_setmaxmem domid=%d memkb=%d failed "
-                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
+                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT +
+                libxl__get_rom_memory_kb(gc, domid, NULL), rc);
         goto out;
     }
 
@@ -4770,11 +4800,12 @@ retry_transaction:
     if (enforce) {
         memorykb = new_target_memkb;
         rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
-                LIBXL_MAXMEM_CONSTANT);
+                LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid, NULL));
         if (rc != 0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
-                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
+                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT +
+                    libxl__get_rom_memory_kb(gc, domid, NULL), rc);
             abort_transaction = 1;
             goto out;
         }
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..ca254f9 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -406,7 +406,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     }
 
     if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
-        LIBXL_MAXMEM_CONSTANT) < 0) {
+        LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid, d_config)) < 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't set max memory");
         return ERROR_FAIL;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..33826ea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -90,6 +90,7 @@
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
 #define LIBXL_MAXMEM_CONSTANT 1024
+#define LIBXL_ROMSIZE_KB 256
 #define LIBXL_PV_EXTRA_MEMORY 1024
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
@@ -1023,6 +1024,12 @@ _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
                                           uint32_t domid, const char *cmd);
 
+/* Returns the amount of extra mem required to allocate roms or an libxl
+ * error code on error.
+ * The *d_config parameter is optional.
+ */
+_hidden int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
+
 /* from xl_device */
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 17:11:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17: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 1XsxAW-00051m-2T; Mon, 24 Nov 2014 17:11:20 +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 1XsxAU-00051b-Vb
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 17:11:19 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	68/36-29352-6B663745; Mon, 24 Nov 2014 17:11:18 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416849076!10197749!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6226 invoked from network); 24 Nov 2014 17:11:17 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 17:11:17 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	sAOHBFip001235
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 24 Nov 2014 12:11:15 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sAOHBFNx001233;
	Mon, 24 Nov 2014 12:11:15 -0500
Date: Mon, 24 Nov 2014 13:11:15 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124171115.GA31940@andromeda.dapyr.net>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<54732954020000780004A4AB@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54732954020000780004A4AB@mail.emea.novell.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 0/3] x86: XSA-109/110 follow-up (to be
	considered for 4.5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 11:49:24AM +0000, Jan Beulich wrote:
> >>> On 20.11.14 at 11:04, <JBeulich@suse.com> wrote:
> > 1: tighten page table owner checking in do_mmu_update()
> > 2: don't ignore foreigndom input on various MMUEXT ops
> > 3: HVM: don't crash guest upon problems occurring in user mode
> > 
> > Reason to request considering this for 4.5: Tightened argument
> > checking (as done in the first two patches) reduces the chances
> > of them getting abused. Not unduly crashing the guest (as done
> > in the third one) may avoid future security issues of guest user
> > mode affecting the guest kernel.
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Hi Konrad - looks like I forgot to Cc you...

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> 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 Mon Nov 24 17:11:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17: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 1XsxAW-00051m-2T; Mon, 24 Nov 2014 17:11:20 +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 1XsxAU-00051b-Vb
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 17:11:19 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	68/36-29352-6B663745; Mon, 24 Nov 2014 17:11:18 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416849076!10197749!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6226 invoked from network); 24 Nov 2014 17:11:17 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 17:11:17 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	sAOHBFip001235
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 24 Nov 2014 12:11:15 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sAOHBFNx001233;
	Mon, 24 Nov 2014 12:11:15 -0500
Date: Mon, 24 Nov 2014 13:11:15 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141124171115.GA31940@andromeda.dapyr.net>
References: <546DCAB102000078000493E0@smtp.nue.novell.com>
	<54732954020000780004A4AB@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54732954020000780004A4AB@mail.emea.novell.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 0/3] x86: XSA-109/110 follow-up (to be
	considered for 4.5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 11:49:24AM +0000, Jan Beulich wrote:
> >>> On 20.11.14 at 11:04, <JBeulich@suse.com> wrote:
> > 1: tighten page table owner checking in do_mmu_update()
> > 2: don't ignore foreigndom input on various MMUEXT ops
> > 3: HVM: don't crash guest upon problems occurring in user mode
> > 
> > Reason to request considering this for 4.5: Tightened argument
> > checking (as done in the first two patches) reduces the chances
> > of them getting abused. Not unduly crashing the guest (as done
> > in the third one) may avoid future security issues of guest user
> > mode affecting the guest kernel.
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Hi Konrad - looks like I forgot to Cc you...

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> 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 Mon Nov 24 17:19:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsxIM-0005Jn-1i; Mon, 24 Nov 2014 17:19:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1XsxIK-0005Ji-F7
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 17:19:24 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	9F/0C-02698-B9863745; Mon, 24 Nov 2014 17:19:23 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416849561!14520378!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7429 invoked from network); 24 Nov 2014 17:19:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 17:19:22 -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 sAOHJGrE010823
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 24 Nov 2014 12:19:17 -0500
Received: from [10.3.113.9] ([10.3.113.9])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAOHJGdw027781; Mon, 24 Nov 2014 12:19:16 -0500
Message-ID: <54736893.6060802@redhat.com>
Date: Mon, 24 Nov 2014 10:19:15 -0700
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Quan Xu <quan.xu@intel.com>, qemu-devel@nongnu.org
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: lcapitulino@redhat.com, armbru@redhat.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v2 1/4] Qemu-Xen-vTPM: Support for Xen stubdom
 vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4086091358504060100=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============4086091358504060100==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="DF9ctCF3cW1dvU2EMtiCWRB0oismv1i7K"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--DF9ctCF3cW1dvU2EMtiCWRB0oismv1i7K
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/23/2014 09:10 PM, Quan Xu wrote:
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  configure        | 14 ++++++++++++++
>  hmp.c            |  7 +++++++
>  qapi-schema.json | 20 ++++++++++++++++++--
>  qemu-options.hx  | 13 +++++++++++--
>  tpm.c            |  7 ++++++-
>  5 files changed, 56 insertions(+), 5 deletions(-)
>=20

> +++ b/qapi-schema.json
> @@ -2855,8 +2855,12 @@
>  # @passthrough: TPM passthrough type
>  #
>  # Since: 1.5
> +#
> +# @xenstubdoms: TPM xenstubdoms type
> +#
> +# Since: 2.3

Typically, this would be done as:

# @passthrough: TPM passthrough type
#
# @xenstubdoms: TPM xenstubdoms type (since 2.3)
#
# Since: 1.5

as the enum itself was added in 1.5, not 2.3.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--DF9ctCF3cW1dvU2EMtiCWRB0oismv1i7K
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
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg

iQEcBAEBCAAGBQJUc2iUAAoJEKeha0olJ0NqPyUH/isiJsLr1B2gX/ZzH5nwmosk
6bfHlL1x1h0mZWlC9GOr+gHLaiL8h7L0KWHcqviHoIUM6NIqLvwi0CipVm7AD24o
TI5cx/lHLc5WaF7UBljuhFjNoZ4NslH/tPt48a6VzrXtEc/eQZuq/wcMlu8GsdyY
+NGiYA8eZZdkBJWtErOOmKjLqXjQ5Oq+vbO8SQzqkTGpHIESiaSkoW5KRiPywIkI
UKzK/CW/e7xA9aptijo9gFlGxv2OjHpu5RXcmAPNpuT3joUWZbJ8uTSe2XGvEAiu
8KIDj7EJJUhg3ub1FtxzvM79p6kGaOFeYqutXBxuiDdR5iA5nGL85ej08BK8eS8=
=mfa7
-----END PGP SIGNATURE-----

--DF9ctCF3cW1dvU2EMtiCWRB0oismv1i7K--


--===============4086091358504060100==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4086091358504060100==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 17:19:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsxIM-0005Jn-1i; Mon, 24 Nov 2014 17:19:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1XsxIK-0005Ji-F7
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 17:19:24 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	9F/0C-02698-B9863745; Mon, 24 Nov 2014 17:19:23 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416849561!14520378!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7429 invoked from network); 24 Nov 2014 17:19:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 17:19:22 -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 sAOHJGrE010823
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 24 Nov 2014 12:19:17 -0500
Received: from [10.3.113.9] ([10.3.113.9])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAOHJGdw027781; Mon, 24 Nov 2014 12:19:16 -0500
Message-ID: <54736893.6060802@redhat.com>
Date: Mon, 24 Nov 2014 10:19:15 -0700
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Quan Xu <quan.xu@intel.com>, qemu-devel@nongnu.org
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: lcapitulino@redhat.com, armbru@redhat.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v2 1/4] Qemu-Xen-vTPM: Support for Xen stubdom
 vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4086091358504060100=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============4086091358504060100==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="DF9ctCF3cW1dvU2EMtiCWRB0oismv1i7K"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--DF9ctCF3cW1dvU2EMtiCWRB0oismv1i7K
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/23/2014 09:10 PM, Quan Xu wrote:
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  configure        | 14 ++++++++++++++
>  hmp.c            |  7 +++++++
>  qapi-schema.json | 20 ++++++++++++++++++--
>  qemu-options.hx  | 13 +++++++++++--
>  tpm.c            |  7 ++++++-
>  5 files changed, 56 insertions(+), 5 deletions(-)
>=20

> +++ b/qapi-schema.json
> @@ -2855,8 +2855,12 @@
>  # @passthrough: TPM passthrough type
>  #
>  # Since: 1.5
> +#
> +# @xenstubdoms: TPM xenstubdoms type
> +#
> +# Since: 2.3

Typically, this would be done as:

# @passthrough: TPM passthrough type
#
# @xenstubdoms: TPM xenstubdoms type (since 2.3)
#
# Since: 1.5

as the enum itself was added in 1.5, not 2.3.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--DF9ctCF3cW1dvU2EMtiCWRB0oismv1i7K
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
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg

iQEcBAEBCAAGBQJUc2iUAAoJEKeha0olJ0NqPyUH/isiJsLr1B2gX/ZzH5nwmosk
6bfHlL1x1h0mZWlC9GOr+gHLaiL8h7L0KWHcqviHoIUM6NIqLvwi0CipVm7AD24o
TI5cx/lHLc5WaF7UBljuhFjNoZ4NslH/tPt48a6VzrXtEc/eQZuq/wcMlu8GsdyY
+NGiYA8eZZdkBJWtErOOmKjLqXjQ5Oq+vbO8SQzqkTGpHIESiaSkoW5KRiPywIkI
UKzK/CW/e7xA9aptijo9gFlGxv2OjHpu5RXcmAPNpuT3joUWZbJ8uTSe2XGvEAiu
8KIDj7EJJUhg3ub1FtxzvM79p6kGaOFeYqutXBxuiDdR5iA5nGL85ej08BK8eS8=
=mfa7
-----END PGP SIGNATURE-----

--DF9ctCF3cW1dvU2EMtiCWRB0oismv1i7K--


--===============4086091358504060100==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4086091358504060100==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 17:28:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsxQg-0005ZI-Fu; Mon, 24 Nov 2014 17:28:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XsxQd-0005ZD-QQ
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 17:27:59 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	09/65-09842-F9A63745; Mon, 24 Nov 2014 17:27:59 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416850078!6948782!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1072 invoked from network); 24 Nov 2014 17:27:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 17:27:58 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 55E8AACDE
	for <xen-devel@lists.xensource.com>;
	Mon, 24 Nov 2014 17:27:58 +0000 (UTC)
Message-ID: <54736A9D.3010901@suse.com>
Date: Mon, 24 Nov 2014 18:27:57 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546EFAE3.80404@suse.com>		<20141121135747.GB2886@laptop.dumpdata.com>	<5473008C.4080604@suse.com>	<5473147C020000780004A3D5@suse.com>
	<54730F8F.7080905@suse.com> <54734A2A.9000301@suse.com>
In-Reply-To: <54734A2A.9000301@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 04:09 PM, Juergen Gross wrote:
> On 11/24/2014 11:59 AM, Juergen Gross wrote:
>> On 11/24/2014 11:20 AM, Jan Beulich wrote:
>>>>>> On 24.11.14 at 10:55, <JGross@suse.com> wrote:
>>>> - Sometimes I see only NMI watchdog messages, looking into hanging cpu
>>>>     state via xen debug keys I can see the cpu(s) in question are
>>>> spinning
>>>>     in _raw_spin_lock():
>>>>     __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
>>>>     The hanging cpus were executing some random user processes (cron,
>>>>     bash, xargs), cr2 contained user addresses.
>>>
>>> Is this perhaps what
>>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02135.html
>>>
>>> appears to be about?
>>
>> Hmm, I'm not sure.
>>
>> I'll try a 3.17 kernel to verify.
>
> Still seeing the issue, but less frequent. OTOH I just found in above
> thread in lkml that 3.17 is showing that issue, too. :-(
>
> I'll try to setup a pv-variant of Linus' patch and test it...

First test seems to be okay, no immediate NMI message...

Any idea why the block-attach/detach would trigger this problem so
easily? I can see the dependency on the high cpu count, but fail to do
so for the xl actions.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 17:28:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsxQg-0005ZI-Fu; Mon, 24 Nov 2014 17:28:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XsxQd-0005ZD-QQ
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 17:27:59 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	09/65-09842-F9A63745; Mon, 24 Nov 2014 17:27:59 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416850078!6948782!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1072 invoked from network); 24 Nov 2014 17:27:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 17:27:58 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 55E8AACDE
	for <xen-devel@lists.xensource.com>;
	Mon, 24 Nov 2014 17:27:58 +0000 (UTC)
Message-ID: <54736A9D.3010901@suse.com>
Date: Mon, 24 Nov 2014 18:27:57 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546EFAE3.80404@suse.com>		<20141121135747.GB2886@laptop.dumpdata.com>	<5473008C.4080604@suse.com>	<5473147C020000780004A3D5@suse.com>
	<54730F8F.7080905@suse.com> <54734A2A.9000301@suse.com>
In-Reply-To: <54734A2A.9000301@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 04:09 PM, Juergen Gross wrote:
> On 11/24/2014 11:59 AM, Juergen Gross wrote:
>> On 11/24/2014 11:20 AM, Jan Beulich wrote:
>>>>>> On 24.11.14 at 10:55, <JGross@suse.com> wrote:
>>>> - Sometimes I see only NMI watchdog messages, looking into hanging cpu
>>>>     state via xen debug keys I can see the cpu(s) in question are
>>>> spinning
>>>>     in _raw_spin_lock():
>>>>     __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
>>>>     The hanging cpus were executing some random user processes (cron,
>>>>     bash, xargs), cr2 contained user addresses.
>>>
>>> Is this perhaps what
>>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02135.html
>>>
>>> appears to be about?
>>
>> Hmm, I'm not sure.
>>
>> I'll try a 3.17 kernel to verify.
>
> Still seeing the issue, but less frequent. OTOH I just found in above
> thread in lkml that 3.17 is showing that issue, too. :-(
>
> I'll try to setup a pv-variant of Linus' patch and test it...

First test seems to be okay, no immediate NMI message...

Any idea why the block-attach/detach would trigger this problem so
easily? I can see the dependency on the high cpu count, but fail to do
so for the xl actions.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 17:32:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsxUY-0005jG-4k; Mon, 24 Nov 2014 17:32:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1XsxUW-0005hY-Hl
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 17:32:00 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	59/33-01660-F8B63745; Mon, 24 Nov 2014 17:31:59 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416850317!10201023!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24585 invoked from network); 24 Nov 2014 17:31:59 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 17:31:59 -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 sAOHVMQs021813
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 24 Nov 2014 12:31:22 -0500
Received: from [10.3.113.9] ([10.3.113.9])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAOHVLhO007000; Mon, 24 Nov 2014 12:31:21 -0500
Message-ID: <54736B69.1050408@redhat.com>
Date: Mon, 24 Nov 2014 10:31:21 -0700
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Quan Xu <quan.xu@intel.com>, qemu-devel@nongnu.org
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
	<54736893.6060802@redhat.com>
In-Reply-To: <54736893.6060802@redhat.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xen.org, armbru@redhat.com, lcapitulino@redhat.com
Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2078632715119757231=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============2078632715119757231==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="xq4meJiknN8cv4VCkaucTfbfsNL5KwBg8"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--xq4meJiknN8cv4VCkaucTfbfsNL5KwBg8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/24/2014 10:19 AM, Eric Blake wrote:
> On 11/23/2014 09:10 PM, Quan Xu wrote:
>> Signed-off-by: Quan Xu <quan.xu@intel.com>
>> ---
>>  configure        | 14 ++++++++++++++
>>  hmp.c            |  7 +++++++
>>  qapi-schema.json | 20 ++++++++++++++++++--
>>  qemu-options.hx  | 13 +++++++++++--
>>  tpm.c            |  7 ++++++-
>>  5 files changed, 56 insertions(+), 5 deletions(-)

Also, this message was not threaded properly; it appeared as a top-level
thread along with three other threads for its siblings, instead of all
four patches being in-reply-to the 0/4 cover letter.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--xq4meJiknN8cv4VCkaucTfbfsNL5KwBg8
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
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg

iQEcBAEBCAAGBQJUc2tpAAoJEKeha0olJ0NqcdYH/jN8etC6cRuL8YRYqXe/I0io
j93NglJsFB5j941b5LeCSI5fVtiZgTXftqt1uwZUn3Weh5tasXKi0/u4WS2go95C
OdRnK9e14qMLgWu5x2ahy63Dq04sKN17T4JANM3bK2h4MkNSHQs8qOIX6jKv7mWs
VBF6HDVQpaSmJCUtFXQSPeHjPJVVv0oqFImlOxngt6Ws5MEfqhDpC30gTdRweIg0
ALs5SZRRfKk2AWkXhjDO0XybA5JcdgM5j1SRtKdLKXxv4CRsC9eO9MQXAFH5MTHW
vxWV7qF09ipK1ukoT8iprJBoiATtRC4g4+JfDJq0bCsCpL/NPs1c6s+yy8oPiTU=
=MxI4
-----END PGP SIGNATURE-----

--xq4meJiknN8cv4VCkaucTfbfsNL5KwBg8--


--===============2078632715119757231==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2078632715119757231==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 17:32:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XsxUY-0005jG-4k; Mon, 24 Nov 2014 17:32:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1XsxUW-0005hY-Hl
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 17:32:00 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	59/33-01660-F8B63745; Mon, 24 Nov 2014 17:31:59 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416850317!10201023!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24585 invoked from network); 24 Nov 2014 17:31:59 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 17:31:59 -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 sAOHVMQs021813
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 24 Nov 2014 12:31:22 -0500
Received: from [10.3.113.9] ([10.3.113.9])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAOHVLhO007000; Mon, 24 Nov 2014 12:31:21 -0500
Message-ID: <54736B69.1050408@redhat.com>
Date: Mon, 24 Nov 2014 10:31:21 -0700
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Quan Xu <quan.xu@intel.com>, qemu-devel@nongnu.org
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
	<54736893.6060802@redhat.com>
In-Reply-To: <54736893.6060802@redhat.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xen.org, armbru@redhat.com, lcapitulino@redhat.com
Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2078632715119757231=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============2078632715119757231==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="xq4meJiknN8cv4VCkaucTfbfsNL5KwBg8"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--xq4meJiknN8cv4VCkaucTfbfsNL5KwBg8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/24/2014 10:19 AM, Eric Blake wrote:
> On 11/23/2014 09:10 PM, Quan Xu wrote:
>> Signed-off-by: Quan Xu <quan.xu@intel.com>
>> ---
>>  configure        | 14 ++++++++++++++
>>  hmp.c            |  7 +++++++
>>  qapi-schema.json | 20 ++++++++++++++++++--
>>  qemu-options.hx  | 13 +++++++++++--
>>  tpm.c            |  7 ++++++-
>>  5 files changed, 56 insertions(+), 5 deletions(-)

Also, this message was not threaded properly; it appeared as a top-level
thread along with three other threads for its siblings, instead of all
four patches being in-reply-to the 0/4 cover letter.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--xq4meJiknN8cv4VCkaucTfbfsNL5KwBg8
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
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg

iQEcBAEBCAAGBQJUc2tpAAoJEKeha0olJ0NqcdYH/jN8etC6cRuL8YRYqXe/I0io
j93NglJsFB5j941b5LeCSI5fVtiZgTXftqt1uwZUn3Weh5tasXKi0/u4WS2go95C
OdRnK9e14qMLgWu5x2ahy63Dq04sKN17T4JANM3bK2h4MkNSHQs8qOIX6jKv7mWs
VBF6HDVQpaSmJCUtFXQSPeHjPJVVv0oqFImlOxngt6Ws5MEfqhDpC30gTdRweIg0
ALs5SZRRfKk2AWkXhjDO0XybA5JcdgM5j1SRtKdLKXxv4CRsC9eO9MQXAFH5MTHW
vxWV7qF09ipK1ukoT8iprJBoiATtRC4g4+JfDJq0bCsCpL/NPs1c6s+yy8oPiTU=
=MxI4
-----END PGP SIGNATURE-----

--xq4meJiknN8cv4VCkaucTfbfsNL5KwBg8--


--===============2078632715119757231==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2078632715119757231==--


From xen-devel-bounces@lists.xen.org Mon Nov 24 17:33:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17: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 1XsxVx-0005tD-KM; Mon, 24 Nov 2014 17:33:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XsxVv-0005t4-EM
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 17:33:27 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	B8/00-28296-6EB63745; Mon, 24 Nov 2014 17:33:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416850403!13483929!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13360 invoked from network); 24 Nov 2014 17:33:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 17:33:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,450,1413244800"; d="scan'208";a="196178791"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 12:32:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XsxVG-000403-ES;
	Mon, 24 Nov 2014 17:32:46 +0000
Date: Mon, 24 Nov 2014 17:32:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wen Congyang <wency@cn.fujitsu.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	xen devel <xen-devel@lists.xen.org>, Fabio Fantoni <fabio.fantoni@m2r.biz>,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] qemu crash with virtio on Xen domUs (backtrace
 included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> CC'ing Paolo.
> 
> 
> Wen,
> thanks for the logs.
> 
> I investigated a little bit and it seems to me that the bug occurs when
> QEMU tries to unmap only a portion of a memory region previously mapped.
> That doesn't work with xen-mapcache.
> 
> See these logs for example:
> 
> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6

Sorry the logs don't quite match, it was supposed to be:

DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6



> that leads to the error:
> 
> xen_ram_addr_from_mapcache, could not find 0x7fab50afbb68
> 
> 
> Paolo, do you know why virtio would call address_space_unmap with a
> different set of arguments compared to the previous address_space_map
> call?
> 
> 
> On Mon, 24 Nov 2014, Wen Congyang wrote:
> > On 11/24/2014 04:52 PM, Fabio Fantoni wrote:
> > > Il 24/11/2014 02:58, Wen Congyang ha scritto:
> > >> When I try to use virtio on xen(HVM guest), qemu crashed. Here is the backtrace:
> > >> (gdb) bt
> > >> #0  0x00007f49581f0b55 in raise () from /lib64/libc.so.6
> > >> #1  0x00007f49581f2131 in abort () from /lib64/libc.so.6
> > >> #2  0x00007f495af2af32 in xen_ram_addr_from_mapcache (ptr=0x7f4951858ac8) at /root/work/xen/tools/qemu-xen-dir/xen-mapcache.c:316
> > >> #3  0x00007f495ae30fb3 in qemu_ram_addr_from_host (ptr=0x7f4951858ac8, ram_addr=0x7fff564dc9b0) at /root/work/xen/tools/qemu-xen-dir/exec.c:1508
> > >> #4  0x00007f495ae33424 in address_space_unmap (as=0x7f495b7c3520, buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2315
> > >> #5  0x00007f495ae335b3 in cpu_physical_memory_unmap (buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2353
> > >> #6  0x00007f495ae9058d in virtqueue_fill (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1, idx=0) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:258
> > >> #7  0x00007f495ae90a0d in virtqueue_push (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:286
> > >> #8  0x00007f495ae82cf3 in virtio_net_handle_ctrl (vdev=0x7f495b92a5d0, vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/net/virtio-net.c:806
> > >> #9  0x00007f495ae925e5 in virtio_queue_notify_vq (vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:729
> > >> #10 0x00007f495ae926c3 in virtio_queue_notify (vdev=0x7f495b92a5d0, n=2) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:735
> > >> #11 0x00007f495ad743c2 in virtio_ioport_write (opaque=0x7f495b929cd0, addr=16, val=2) at hw/virtio/virtio-pci.c:301
> > >> #12 0x00007f495ad74923 in virtio_pci_config_write (opaque=0x7f495b929cd0, addr=16, val=2, size=2) at hw/virtio/virtio-pci.c:433
> > >> #13 0x00007f495ae9f071 in memory_region_write_accessor (mr=0x7f495b92a468, addr=16, value=0x7fff564e8d08, size=2, shift=0, mask=65535) at /root/work/xen/tools/qemu-xen-dir/memory.c:441
> > >> #14 0x00007f495ae9f1ad in access_with_adjusted_size (addr=16, value=0x7fff564e8d08, size=2, access_size_min=1, access_size_max=4, access=0x7f495ae9efe8 <memory_region_write_accessor>, mr=0x7f495b92a468)
> > >>      at /root/work/xen/tools/qemu-xen-dir/memory.c:478
> > >> #15 0x00007f495aea200e in memory_region_dispatch_write (mr=0x7f495b92a468, addr=16, data=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:985
> > >> #16 0x00007f495aea5824 in io_mem_write (mr=0x7f495b92a468, addr=16, val=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:1744
> > >> #17 0x00007f495ae328d3 in address_space_rw (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2, is_write=true) at /root/work/xen/tools/qemu-xen-dir/exec.c:2029
> > >> #18 0x00007f495ae32c85 in address_space_write (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2) at /root/work/xen/tools/qemu-xen-dir/exec.c:2091
> > >> #19 0x00007f495ae9c130 in cpu_outw (addr=49200, val=2) at /root/work/xen/tools/qemu-xen-dir/ioport.c:77
> > >> #20 0x00007f495af289d0 in do_outp (addr=49200, size=2, val=2) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:668
> > >> #21 0x00007f495af28b94 in cpu_ioreq_pio (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:729
> > >> #22 0x00007f495af28ee5 in handle_ioreq (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:781
> > >> #23 0x00007f495af29237 in cpu_handle_ioreq (opaque=0x7f495b884ad0) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:856
> > >> #24 0x00007f495ad7d2c2 in qemu_iohandler_poll (pollfds=0x7f495b823820, ret=1) at iohandler.c:143
> > >> #25 0x00007f495ad7e2fd in main_loop_wait (nonblocking=0) at main-loop.c:485
> > >> #26 0x00007f495ae1386f in main_loop () at vl.c:2056
> > >> #27 0x00007f495ae1af17 in main (argc=35, argv=0x7fff564e94c8, envp=0x7fff564e95e8) at vl.c:4535
> > >> (gdb) q
> > >>
> > >>
> > > Added qemu-devel and qemu maintainer in xen to cc.
> > > 
> > > @Wen Congyang: when you report a bug is useful add more details and logs, domU's xl cfg, domU's qemu log, xen and qemu version used ecc...
> > > .
> > > 
> > 
> > The config file is not backuped before changing. I remember I only change vcpus and nic model.
> > Here is the config file:
> > ===================================================
> > builder='hvm'
> > 
> > memory = 2048
> > vcpus=2
> > cpus="3"
> > 
> > name = "hvm_nopv"
> > 
> > disk = [ 'format=raw,devtype=disk,access=w,vdev=hda,target=/data/images/xen/hvm_nopv/suse/hvm.img'
> > #      , 'format=raw,devtype=disk,access=w,vdev=hdb,target=/data/images/xen/hvm_nopv/suse/hvm_data.img'
> >        ]
> > 
> > vif = [ 'mac=00:16:4f:00:00:11, bridge=br0, model=virtio-net' ]
> > 
> > #-----------------------------------------------------------------------------
> > # boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d)
> > # default: hard disk, cd-rom, floppy
> > boot="c"
> > 
> > sdl=0
> > 
> > vnc=1
> > 
> > vnclisten='0.0.0.0'
> > 
> > vncunused = 1
> > 
> > stdvga = 0
> > 
> > serial='pty'
> > 
> > apic=1
> > apci=1
> > pae=1
> > 
> > extid=0
> > keymap="en-us"
> > localtime=1
> > hpet=1
> > 
> > usbdevice='tablet'
> > 
> > xen_platform_pci=0
> > ===================================================
> > 
> > qemu log(/var/log/xen/qemu-xxx):
> > char device redirected to /dev/pts/2 (label serial0)
> > xen_ram_addr_from_mapcache, could not find 0x7f267bd828e8
> > 
> > qemu version:
> > qemu-upstream-unstable:
> > http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=summary
> > commit: ca78cc83650b535d7e24baeaea32947be0141534
> > 
> > xl: not the newest, commit c90a755f261b8ccb3dac7e1f695122cac95c6053. I change
> > some codes(remus related/suspend/resume...)
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 24 17:33:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 17: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 1XsxVx-0005tD-KM; Mon, 24 Nov 2014 17:33:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XsxVv-0005t4-EM
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 17:33:27 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	B8/00-28296-6EB63745; Mon, 24 Nov 2014 17:33:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416850403!13483929!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13360 invoked from network); 24 Nov 2014 17:33:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 17:33:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,450,1413244800"; d="scan'208";a="196178791"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 12:32:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XsxVG-000403-ES;
	Mon, 24 Nov 2014 17:32:46 +0000
Date: Mon, 24 Nov 2014 17:32:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wen Congyang <wency@cn.fujitsu.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	xen devel <xen-devel@lists.xen.org>, Fabio Fantoni <fabio.fantoni@m2r.biz>,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] qemu crash with virtio on Xen domUs (backtrace
 included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> CC'ing Paolo.
> 
> 
> Wen,
> thanks for the logs.
> 
> I investigated a little bit and it seems to me that the bug occurs when
> QEMU tries to unmap only a portion of a memory region previously mapped.
> That doesn't work with xen-mapcache.
> 
> See these logs for example:
> 
> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6

Sorry the logs don't quite match, it was supposed to be:

DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6



> that leads to the error:
> 
> xen_ram_addr_from_mapcache, could not find 0x7fab50afbb68
> 
> 
> Paolo, do you know why virtio would call address_space_unmap with a
> different set of arguments compared to the previous address_space_map
> call?
> 
> 
> On Mon, 24 Nov 2014, Wen Congyang wrote:
> > On 11/24/2014 04:52 PM, Fabio Fantoni wrote:
> > > Il 24/11/2014 02:58, Wen Congyang ha scritto:
> > >> When I try to use virtio on xen(HVM guest), qemu crashed. Here is the backtrace:
> > >> (gdb) bt
> > >> #0  0x00007f49581f0b55 in raise () from /lib64/libc.so.6
> > >> #1  0x00007f49581f2131 in abort () from /lib64/libc.so.6
> > >> #2  0x00007f495af2af32 in xen_ram_addr_from_mapcache (ptr=0x7f4951858ac8) at /root/work/xen/tools/qemu-xen-dir/xen-mapcache.c:316
> > >> #3  0x00007f495ae30fb3 in qemu_ram_addr_from_host (ptr=0x7f4951858ac8, ram_addr=0x7fff564dc9b0) at /root/work/xen/tools/qemu-xen-dir/exec.c:1508
> > >> #4  0x00007f495ae33424 in address_space_unmap (as=0x7f495b7c3520, buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2315
> > >> #5  0x00007f495ae335b3 in cpu_physical_memory_unmap (buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at /root/work/xen/tools/qemu-xen-dir/exec.c:2353
> > >> #6  0x00007f495ae9058d in virtqueue_fill (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1, idx=0) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:258
> > >> #7  0x00007f495ae90a0d in virtqueue_push (vq=0x7f495b931250, elem=0x7fff564dcb00, len=1) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:286
> > >> #8  0x00007f495ae82cf3 in virtio_net_handle_ctrl (vdev=0x7f495b92a5d0, vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/net/virtio-net.c:806
> > >> #9  0x00007f495ae925e5 in virtio_queue_notify_vq (vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:729
> > >> #10 0x00007f495ae926c3 in virtio_queue_notify (vdev=0x7f495b92a5d0, n=2) at /root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:735
> > >> #11 0x00007f495ad743c2 in virtio_ioport_write (opaque=0x7f495b929cd0, addr=16, val=2) at hw/virtio/virtio-pci.c:301
> > >> #12 0x00007f495ad74923 in virtio_pci_config_write (opaque=0x7f495b929cd0, addr=16, val=2, size=2) at hw/virtio/virtio-pci.c:433
> > >> #13 0x00007f495ae9f071 in memory_region_write_accessor (mr=0x7f495b92a468, addr=16, value=0x7fff564e8d08, size=2, shift=0, mask=65535) at /root/work/xen/tools/qemu-xen-dir/memory.c:441
> > >> #14 0x00007f495ae9f1ad in access_with_adjusted_size (addr=16, value=0x7fff564e8d08, size=2, access_size_min=1, access_size_max=4, access=0x7f495ae9efe8 <memory_region_write_accessor>, mr=0x7f495b92a468)
> > >>      at /root/work/xen/tools/qemu-xen-dir/memory.c:478
> > >> #15 0x00007f495aea200e in memory_region_dispatch_write (mr=0x7f495b92a468, addr=16, data=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:985
> > >> #16 0x00007f495aea5824 in io_mem_write (mr=0x7f495b92a468, addr=16, val=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:1744
> > >> #17 0x00007f495ae328d3 in address_space_rw (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2, is_write=true) at /root/work/xen/tools/qemu-xen-dir/exec.c:2029
> > >> #18 0x00007f495ae32c85 in address_space_write (as=0x7f495b7c3600, addr=49200, buf=0x7fff564e8e60 "\002", len=2) at /root/work/xen/tools/qemu-xen-dir/exec.c:2091
> > >> #19 0x00007f495ae9c130 in cpu_outw (addr=49200, val=2) at /root/work/xen/tools/qemu-xen-dir/ioport.c:77
> > >> #20 0x00007f495af289d0 in do_outp (addr=49200, size=2, val=2) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:668
> > >> #21 0x00007f495af28b94 in cpu_ioreq_pio (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:729
> > >> #22 0x00007f495af28ee5 in handle_ioreq (req=0x7f495ab25000) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:781
> > >> #23 0x00007f495af29237 in cpu_handle_ioreq (opaque=0x7f495b884ad0) at /root/work/xen/tools/qemu-xen-dir/xen-hvm.c:856
> > >> #24 0x00007f495ad7d2c2 in qemu_iohandler_poll (pollfds=0x7f495b823820, ret=1) at iohandler.c:143
> > >> #25 0x00007f495ad7e2fd in main_loop_wait (nonblocking=0) at main-loop.c:485
> > >> #26 0x00007f495ae1386f in main_loop () at vl.c:2056
> > >> #27 0x00007f495ae1af17 in main (argc=35, argv=0x7fff564e94c8, envp=0x7fff564e95e8) at vl.c:4535
> > >> (gdb) q
> > >>
> > >>
> > > Added qemu-devel and qemu maintainer in xen to cc.
> > > 
> > > @Wen Congyang: when you report a bug is useful add more details and logs, domU's xl cfg, domU's qemu log, xen and qemu version used ecc...
> > > .
> > > 
> > 
> > The config file is not backuped before changing. I remember I only change vcpus and nic model.
> > Here is the config file:
> > ===================================================
> > builder='hvm'
> > 
> > memory = 2048
> > vcpus=2
> > cpus="3"
> > 
> > name = "hvm_nopv"
> > 
> > disk = [ 'format=raw,devtype=disk,access=w,vdev=hda,target=/data/images/xen/hvm_nopv/suse/hvm.img'
> > #      , 'format=raw,devtype=disk,access=w,vdev=hdb,target=/data/images/xen/hvm_nopv/suse/hvm_data.img'
> >        ]
> > 
> > vif = [ 'mac=00:16:4f:00:00:11, bridge=br0, model=virtio-net' ]
> > 
> > #-----------------------------------------------------------------------------
> > # boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d)
> > # default: hard disk, cd-rom, floppy
> > boot="c"
> > 
> > sdl=0
> > 
> > vnc=1
> > 
> > vnclisten='0.0.0.0'
> > 
> > vncunused = 1
> > 
> > stdvga = 0
> > 
> > serial='pty'
> > 
> > apic=1
> > apci=1
> > pae=1
> > 
> > extid=0
> > keymap="en-us"
> > localtime=1
> > hpet=1
> > 
> > usbdevice='tablet'
> > 
> > xen_platform_pci=0
> > ===================================================
> > 
> > qemu log(/var/log/xen/qemu-xxx):
> > char device redirected to /dev/pts/2 (label serial0)
> > xen_ram_addr_from_mapcache, could not find 0x7f267bd828e8
> > 
> > qemu version:
> > qemu-upstream-unstable:
> > http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=summary
> > commit: ca78cc83650b535d7e24baeaea32947be0141534
> > 
> > xl: not the newest, commit c90a755f261b8ccb3dac7e1f695122cac95c6053. I change
> > some codes(remus related/suspend/resume...)
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 24 18:45:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 18:45:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsyd8-000750-K2; Mon, 24 Nov 2014 18:44:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xsyd6-00074v-Ts
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 18:44:57 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	27/30-28296-7AC73745; Mon, 24 Nov 2014 18:44:55 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416854692!13557668!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28678 invoked from network); 24 Nov 2014 18:44:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 18:44:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,450,1413244800"; d="scan'208";a="196214454"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 13:44:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xsycz-0005JL-2g;
	Mon, 24 Nov 2014 18:44:49 +0000
Date: Mon, 24 Nov 2014 18:44:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <qemu-devel@nongnu.org>
In-Reply-To: <alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> > CC'ing Paolo.
> > 
> > 
> > Wen,
> > thanks for the logs.
> > 
> > I investigated a little bit and it seems to me that the bug occurs when
> > QEMU tries to unmap only a portion of a memory region previously mapped.
> > That doesn't work with xen-mapcache.
> > 
> > See these logs for example:
> > 
> > DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> > DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> 
> Sorry the logs don't quite match, it was supposed to be:
> 
> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6

It looks like the problem is caused by iov_discard_front, called by
virtio_net_handle_ctrl. By changing iov_base after the sg has already
been mapped (cpu_physical_memory_map), it causes a leak in the mapping
because the corresponding cpu_physical_memory_unmap will only unmap a
portion of the original sg.  On Xen the problem is worse because
xen-mapcache aborts.

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 2ac6ce5..b2b5c2d 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
     struct iovec *iov;
     unsigned int iov_cnt;
 
-    while (virtqueue_pop(vq, &elem)) {
+    while (virtqueue_pop_nomap(vq, &elem)) {
         if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
             iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
             error_report("virtio-net ctrl missing headers");
@@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
 
         iov = elem.out_sg;
         iov_cnt = elem.out_num;
-        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
         iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
+
+        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
+        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
+
+        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
         if (s != sizeof(ctrl)) {
             status = VIRTIO_NET_ERR;
         } else if (ctrl.class == VIRTIO_NET_CTRL_RX) {
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 3e4b70c..6a4bd3a 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -446,7 +446,7 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
     }
 }
 
-int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
+int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem)
 {
     unsigned int i, head, max;
     hwaddr desc_pa = vq->vring.desc;
@@ -505,9 +505,6 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
         }
     } while ((i = virtqueue_next_desc(desc_pa, i, max)) != max);
 
-    /* Now map what we have collected */
-    virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
-    virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
 
     elem->index = head;
 
@@ -517,6 +514,16 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
     return elem->in_num + elem->out_num;
 }
 
+int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
+{
+    int rc = virtqueue_pop_nomap(vq, elem);
+    if (rc > 0) {
+        virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
+        virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
+    }
+    return rc;
+}
+
 /* virtio device */
 static void virtio_notify_vector(VirtIODevice *vdev, uint16_t vector)
 {
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 3e54e90..40a3977 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -174,6 +174,7 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
 void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
     size_t num_sg, int is_write);
 int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem);
+int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem);
 int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes,
                           unsigned int out_bytes);
 void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 18:45:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 18:45:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsyd8-000750-K2; Mon, 24 Nov 2014 18:44:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xsyd6-00074v-Ts
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 18:44:57 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	27/30-28296-7AC73745; Mon, 24 Nov 2014 18:44:55 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416854692!13557668!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28678 invoked from network); 24 Nov 2014 18:44:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2014 18:44:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,450,1413244800"; d="scan'208";a="196214454"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 13:44:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xsycz-0005JL-2g;
	Mon, 24 Nov 2014 18:44:49 +0000
Date: Mon, 24 Nov 2014 18:44:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <qemu-devel@nongnu.org>
In-Reply-To: <alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> > CC'ing Paolo.
> > 
> > 
> > Wen,
> > thanks for the logs.
> > 
> > I investigated a little bit and it seems to me that the bug occurs when
> > QEMU tries to unmap only a portion of a memory region previously mapped.
> > That doesn't work with xen-mapcache.
> > 
> > See these logs for example:
> > 
> > DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> > DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> 
> Sorry the logs don't quite match, it was supposed to be:
> 
> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6

It looks like the problem is caused by iov_discard_front, called by
virtio_net_handle_ctrl. By changing iov_base after the sg has already
been mapped (cpu_physical_memory_map), it causes a leak in the mapping
because the corresponding cpu_physical_memory_unmap will only unmap a
portion of the original sg.  On Xen the problem is worse because
xen-mapcache aborts.

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 2ac6ce5..b2b5c2d 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
     struct iovec *iov;
     unsigned int iov_cnt;
 
-    while (virtqueue_pop(vq, &elem)) {
+    while (virtqueue_pop_nomap(vq, &elem)) {
         if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
             iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
             error_report("virtio-net ctrl missing headers");
@@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
 
         iov = elem.out_sg;
         iov_cnt = elem.out_num;
-        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
         iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
+
+        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
+        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
+
+        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
         if (s != sizeof(ctrl)) {
             status = VIRTIO_NET_ERR;
         } else if (ctrl.class == VIRTIO_NET_CTRL_RX) {
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 3e4b70c..6a4bd3a 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -446,7 +446,7 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
     }
 }
 
-int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
+int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem)
 {
     unsigned int i, head, max;
     hwaddr desc_pa = vq->vring.desc;
@@ -505,9 +505,6 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
         }
     } while ((i = virtqueue_next_desc(desc_pa, i, max)) != max);
 
-    /* Now map what we have collected */
-    virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
-    virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
 
     elem->index = head;
 
@@ -517,6 +514,16 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
     return elem->in_num + elem->out_num;
 }
 
+int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
+{
+    int rc = virtqueue_pop_nomap(vq, elem);
+    if (rc > 0) {
+        virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
+        virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
+    }
+    return rc;
+}
+
 /* virtio device */
 static void virtio_notify_vector(VirtIODevice *vdev, uint16_t vector)
 {
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 3e54e90..40a3977 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -174,6 +174,7 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
 void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
     size_t num_sg, int is_write);
 int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem);
+int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem);
 int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes,
                           unsigned int out_bytes);
 void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 18:53:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 18:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsykw-0007JH-Ie; Mon, 24 Nov 2014 18:53:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xsyku-0007JC-TH
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 18:53:01 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	F8/53-17694-C8E73745; Mon, 24 Nov 2014 18:53:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416855177!13380632!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25054 invoked from network); 24 Nov 2014 18:52:59 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 18:52:59 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOIqhsM029377
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 18:52:44 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOIqf2j018350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 18:52:41 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOIqfId018336; Mon, 24 Nov 2014 18:52:41 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 10:52:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C18171194D8; Mon, 24 Nov 2014 13:52:39 -0500 (EST)
Date: Mon, 24 Nov 2014 13:52:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141124185239.GA10034@laptop.dumpdata.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com, qemu-devel@nongnu.org,
	xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 06:44:45PM +0000, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> > > CC'ing Paolo.
> > > 
> > > 
> > > Wen,
> > > thanks for the logs.
> > > 
> > > I investigated a little bit and it seems to me that the bug occurs when
> > > QEMU tries to unmap only a portion of a memory region previously mapped.
> > > That doesn't work with xen-mapcache.
> > > 
> > > See these logs for example:
> > > 
> > > DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> > > DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> > 
> > Sorry the logs don't quite match, it was supposed to be:
> > 
> > DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
> > DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> 
> It looks like the problem is caused by iov_discard_front, called by
> virtio_net_handle_ctrl. By changing iov_base after the sg has already
> been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> because the corresponding cpu_physical_memory_unmap will only unmap a
> portion of the original sg.  On Xen the problem is worse because
> xen-mapcache aborts.

Didn't um Andy post patches for ths:

http://lists.xen.org/archives/html/xen-devel/2014-09/msg02864.html

> 
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 2ac6ce5..b2b5c2d 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>      struct iovec *iov;
>      unsigned int iov_cnt;
>  
> -    while (virtqueue_pop(vq, &elem)) {
> +    while (virtqueue_pop_nomap(vq, &elem)) {
>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
>              error_report("virtio-net ctrl missing headers");
> @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>  
>          iov = elem.out_sg;
>          iov_cnt = elem.out_num;
> -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> +
> +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> +
> +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          if (s != sizeof(ctrl)) {
>              status = VIRTIO_NET_ERR;
>          } else if (ctrl.class == VIRTIO_NET_CTRL_RX) {
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 3e4b70c..6a4bd3a 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -446,7 +446,7 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
>      }
>  }
>  
> -int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem)
>  {
>      unsigned int i, head, max;
>      hwaddr desc_pa = vq->vring.desc;
> @@ -505,9 +505,6 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
>          }
>      } while ((i = virtqueue_next_desc(desc_pa, i, max)) != max);
>  
> -    /* Now map what we have collected */
> -    virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> -    virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
>  
>      elem->index = head;
>  
> @@ -517,6 +514,16 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
>      return elem->in_num + elem->out_num;
>  }
>  
> +int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> +{
> +    int rc = virtqueue_pop_nomap(vq, elem);
> +    if (rc > 0) {
> +        virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> +        virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
> +    }
> +    return rc;
> +}
> +
>  /* virtio device */
>  static void virtio_notify_vector(VirtIODevice *vdev, uint16_t vector)
>  {
> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> index 3e54e90..40a3977 100644
> --- a/include/hw/virtio/virtio.h
> +++ b/include/hw/virtio/virtio.h
> @@ -174,6 +174,7 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
>  void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
>      size_t num_sg, int is_write);
>  int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem);
> +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem);
>  int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes,
>                            unsigned int out_bytes);
>  void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes,
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 24 18:53:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 18:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsykw-0007JH-Ie; Mon, 24 Nov 2014 18:53:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xsyku-0007JC-TH
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 18:53:01 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	F8/53-17694-C8E73745; Mon, 24 Nov 2014 18:53:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416855177!13380632!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25054 invoked from network); 24 Nov 2014 18:52:59 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 18:52:59 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOIqhsM029377
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 18:52:44 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOIqf2j018350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 18:52:41 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOIqfId018336; Mon, 24 Nov 2014 18:52:41 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 10:52:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C18171194D8; Mon, 24 Nov 2014 13:52:39 -0500 (EST)
Date: Mon, 24 Nov 2014 13:52:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141124185239.GA10034@laptop.dumpdata.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com, qemu-devel@nongnu.org,
	xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 06:44:45PM +0000, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> > > CC'ing Paolo.
> > > 
> > > 
> > > Wen,
> > > thanks for the logs.
> > > 
> > > I investigated a little bit and it seems to me that the bug occurs when
> > > QEMU tries to unmap only a portion of a memory region previously mapped.
> > > That doesn't work with xen-mapcache.
> > > 
> > > See these logs for example:
> > > 
> > > DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> > > DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> > 
> > Sorry the logs don't quite match, it was supposed to be:
> > 
> > DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
> > DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> 
> It looks like the problem is caused by iov_discard_front, called by
> virtio_net_handle_ctrl. By changing iov_base after the sg has already
> been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> because the corresponding cpu_physical_memory_unmap will only unmap a
> portion of the original sg.  On Xen the problem is worse because
> xen-mapcache aborts.

Didn't um Andy post patches for ths:

http://lists.xen.org/archives/html/xen-devel/2014-09/msg02864.html

> 
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 2ac6ce5..b2b5c2d 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>      struct iovec *iov;
>      unsigned int iov_cnt;
>  
> -    while (virtqueue_pop(vq, &elem)) {
> +    while (virtqueue_pop_nomap(vq, &elem)) {
>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
>              error_report("virtio-net ctrl missing headers");
> @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>  
>          iov = elem.out_sg;
>          iov_cnt = elem.out_num;
> -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> +
> +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> +
> +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          if (s != sizeof(ctrl)) {
>              status = VIRTIO_NET_ERR;
>          } else if (ctrl.class == VIRTIO_NET_CTRL_RX) {
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 3e4b70c..6a4bd3a 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -446,7 +446,7 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
>      }
>  }
>  
> -int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem)
>  {
>      unsigned int i, head, max;
>      hwaddr desc_pa = vq->vring.desc;
> @@ -505,9 +505,6 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
>          }
>      } while ((i = virtqueue_next_desc(desc_pa, i, max)) != max);
>  
> -    /* Now map what we have collected */
> -    virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> -    virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
>  
>      elem->index = head;
>  
> @@ -517,6 +514,16 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
>      return elem->in_num + elem->out_num;
>  }
>  
> +int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> +{
> +    int rc = virtqueue_pop_nomap(vq, elem);
> +    if (rc > 0) {
> +        virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> +        virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
> +    }
> +    return rc;
> +}
> +
>  /* virtio device */
>  static void virtio_notify_vector(VirtIODevice *vdev, uint16_t vector)
>  {
> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> index 3e54e90..40a3977 100644
> --- a/include/hw/virtio/virtio.h
> +++ b/include/hw/virtio/virtio.h
> @@ -174,6 +174,7 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
>  void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
>      size_t num_sg, int is_write);
>  int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem);
> +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem);
>  int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes,
>                            unsigned int out_bytes);
>  void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes,
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 24 19:04:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 19:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsyvx-0007Zv-PE; Mon, 24 Nov 2014 19:04:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xsyvw-0007Zq-2B
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 19:04:24 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3E/F5-25276-73183745; Mon, 24 Nov 2014 19:04:23 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416855861!14929421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16390 invoked from network); 24 Nov 2014 19:04: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;
	24 Nov 2014 19:04:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,450,1413244800"; d="scan'208";a="195456898"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 14:01:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XsytO-0005YZ-1h;
	Mon, 24 Nov 2014 19:01:46 +0000
Date: Mon, 24 Nov 2014 19:01:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141124185239.GA10034@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411241900500.2675@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
	<20141124185239.GA10034@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 24, 2014 at 06:44:45PM +0000, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> > > On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> > > > CC'ing Paolo.
> > > > 
> > > > 
> > > > Wen,
> > > > thanks for the logs.
> > > > 
> > > > I investigated a little bit and it seems to me that the bug occurs when
> > > > QEMU tries to unmap only a portion of a memory region previously mapped.
> > > > That doesn't work with xen-mapcache.
> > > > 
> > > > See these logs for example:
> > > > 
> > > > DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> > > > DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> > > 
> > > Sorry the logs don't quite match, it was supposed to be:
> > > 
> > > DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
> > > DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> > 
> > It looks like the problem is caused by iov_discard_front, called by
> > virtio_net_handle_ctrl. By changing iov_base after the sg has already
> > been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> > because the corresponding cpu_physical_memory_unmap will only unmap a
> > portion of the original sg.  On Xen the problem is worse because
> > xen-mapcache aborts.
> 
> Didn't um Andy post patches for ths:
> 
> http://lists.xen.org/archives/html/xen-devel/2014-09/msg02864.html

It looks like these are fixing a linux side issue (the frontend) while
this patch is for a bug in QEMU (the backend).


> > 
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 2ac6ce5..b2b5c2d 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >      struct iovec *iov;
> >      unsigned int iov_cnt;
> >  
> > -    while (virtqueue_pop(vq, &elem)) {
> > +    while (virtqueue_pop_nomap(vq, &elem)) {
> >          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
> >              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
> >              error_report("virtio-net ctrl missing headers");
> > @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >  
> >          iov = elem.out_sg;
> >          iov_cnt = elem.out_num;
> > -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> >          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> > +
> > +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> > +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> > +
> > +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> >          if (s != sizeof(ctrl)) {
> >              status = VIRTIO_NET_ERR;
> >          } else if (ctrl.class == VIRTIO_NET_CTRL_RX) {
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index 3e4b70c..6a4bd3a 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -446,7 +446,7 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
> >      }
> >  }
> >  
> > -int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> > +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem)
> >  {
> >      unsigned int i, head, max;
> >      hwaddr desc_pa = vq->vring.desc;
> > @@ -505,9 +505,6 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> >          }
> >      } while ((i = virtqueue_next_desc(desc_pa, i, max)) != max);
> >  
> > -    /* Now map what we have collected */
> > -    virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> > -    virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
> >  
> >      elem->index = head;
> >  
> > @@ -517,6 +514,16 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> >      return elem->in_num + elem->out_num;
> >  }
> >  
> > +int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> > +{
> > +    int rc = virtqueue_pop_nomap(vq, elem);
> > +    if (rc > 0) {
> > +        virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> > +        virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
> > +    }
> > +    return rc;
> > +}
> > +
> >  /* virtio device */
> >  static void virtio_notify_vector(VirtIODevice *vdev, uint16_t vector)
> >  {
> > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > index 3e54e90..40a3977 100644
> > --- a/include/hw/virtio/virtio.h
> > +++ b/include/hw/virtio/virtio.h
> > @@ -174,6 +174,7 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
> >  void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
> >      size_t num_sg, int is_write);
> >  int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem);
> > +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem);
> >  int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes,
> >                            unsigned int out_bytes);
> >  void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes,
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Nov 24 19:04:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 19:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xsyvx-0007Zv-PE; Mon, 24 Nov 2014 19:04:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xsyvw-0007Zq-2B
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 19:04:24 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3E/F5-25276-73183745; Mon, 24 Nov 2014 19:04:23 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416855861!14929421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16390 invoked from network); 24 Nov 2014 19:04: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;
	24 Nov 2014 19:04:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,450,1413244800"; d="scan'208";a="195456898"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Mon, 24 Nov 2014 14:01:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XsytO-0005YZ-1h;
	Mon, 24 Nov 2014 19:01:46 +0000
Date: Mon, 24 Nov 2014 19:01:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141124185239.GA10034@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1411241900500.2675@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
	<20141124185239.GA10034@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 24, 2014 at 06:44:45PM +0000, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> > > On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> > > > CC'ing Paolo.
> > > > 
> > > > 
> > > > Wen,
> > > > thanks for the logs.
> > > > 
> > > > I investigated a little bit and it seems to me that the bug occurs when
> > > > QEMU tries to unmap only a portion of a memory region previously mapped.
> > > > That doesn't work with xen-mapcache.
> > > > 
> > > > See these logs for example:
> > > > 
> > > > DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> > > > DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> > > 
> > > Sorry the logs don't quite match, it was supposed to be:
> > > 
> > > DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
> > > DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> > 
> > It looks like the problem is caused by iov_discard_front, called by
> > virtio_net_handle_ctrl. By changing iov_base after the sg has already
> > been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> > because the corresponding cpu_physical_memory_unmap will only unmap a
> > portion of the original sg.  On Xen the problem is worse because
> > xen-mapcache aborts.
> 
> Didn't um Andy post patches for ths:
> 
> http://lists.xen.org/archives/html/xen-devel/2014-09/msg02864.html

It looks like these are fixing a linux side issue (the frontend) while
this patch is for a bug in QEMU (the backend).


> > 
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 2ac6ce5..b2b5c2d 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >      struct iovec *iov;
> >      unsigned int iov_cnt;
> >  
> > -    while (virtqueue_pop(vq, &elem)) {
> > +    while (virtqueue_pop_nomap(vq, &elem)) {
> >          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
> >              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
> >              error_report("virtio-net ctrl missing headers");
> > @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >  
> >          iov = elem.out_sg;
> >          iov_cnt = elem.out_num;
> > -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> >          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> > +
> > +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> > +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> > +
> > +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> >          if (s != sizeof(ctrl)) {
> >              status = VIRTIO_NET_ERR;
> >          } else if (ctrl.class == VIRTIO_NET_CTRL_RX) {
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index 3e4b70c..6a4bd3a 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -446,7 +446,7 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
> >      }
> >  }
> >  
> > -int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> > +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem)
> >  {
> >      unsigned int i, head, max;
> >      hwaddr desc_pa = vq->vring.desc;
> > @@ -505,9 +505,6 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> >          }
> >      } while ((i = virtqueue_next_desc(desc_pa, i, max)) != max);
> >  
> > -    /* Now map what we have collected */
> > -    virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> > -    virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
> >  
> >      elem->index = head;
> >  
> > @@ -517,6 +514,16 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> >      return elem->in_num + elem->out_num;
> >  }
> >  
> > +int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> > +{
> > +    int rc = virtqueue_pop_nomap(vq, elem);
> > +    if (rc > 0) {
> > +        virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> > +        virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
> > +    }
> > +    return rc;
> > +}
> > +
> >  /* virtio device */
> >  static void virtio_notify_vector(VirtIODevice *vdev, uint16_t vector)
> >  {
> > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > index 3e54e90..40a3977 100644
> > --- a/include/hw/virtio/virtio.h
> > +++ b/include/hw/virtio/virtio.h
> > @@ -174,6 +174,7 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
> >  void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
> >      size_t num_sg, int is_write);
> >  int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem);
> > +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem);
> >  int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes,
> >                            unsigned int out_bytes);
> >  void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes,
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Nov 24 19:32:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 19:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XszN4-0008KT-SW; Mon, 24 Nov 2014 19:32:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XszN3-0008KO-94
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 19:32:25 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B7/DA-17958-8C783745; Mon, 24 Nov 2014 19:32:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416857542!13503528!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13713 invoked from network); 24 Nov 2014 19:32:23 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-2.tower-31.messagelabs.com with SMTP;
	24 Nov 2014 19:32:23 -0000
X-TM-IMSS-Message-ID: <2e6298a90001a5b3@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 2e6298a90001a5b3 ;
	Mon, 24 Nov 2014 14:32:09 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAOJVmcm020505; 
	Mon, 24 Nov 2014 14:31:58 -0500
Message-ID: <547386C8.7060405@tycho.nsa.gov>
Date: Mon, 24 Nov 2014 14:28:08 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>	
	<20141124124143.GA11483@zion.uk.xensource.com>	
	<54732F8E.4060507@citrix.com>	
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>	
	<547343F4.80509@citrix.com> <1416840918.8878.4.camel@citrix.com>
In-Reply-To: <1416840918.8878.4.camel@citrix.com>
Cc: xen-devel@lists.xen.org, Wei Liu <wei.liu2@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 09:55 AM, Ian Campbell wrote:
> On Mon, 2014-11-24 at 14:43 +0000, Andrew Cooper wrote:
>> On 24/11/14 14:32, M A Young wrote:
>>> On Mon, 24 Nov 2014, Andrew Cooper wrote:
>>>> Is XSM in use?  I can't think of any other reason why that hypercall
>>>> would fail with EPERM.
>>>
>>> XSM is built in (I wanted to allow the option of people using it) but
>>> I didn't think it was active.
>>
>> I don't believe there is any concept of "available but not active",
>
> I think there is, the "dummy" policy which is loaded when there is no
> explicit policy given should behave as if xsm were disabled. AIUI all
> the XSM_* and xsm_default_action stuff is supposed to semi automatically
> ensure this is the case at compile time. CC-ing Daniel to confirm/deny.

Yes.  The case where XSM is enabled at compile time but using the dummy
module is supposed to produce identical behavior to disabling XSM at
compile time.

The hypervisor parameter flask_enabled controls this run-time switching.

>> which probably means that the default policy is missing an entry for
>> this hypercall.
>
> That said domctl is XSM_OTHER, which basically means "special one off
> handling" I think. But it basically turns into XSM_DM_PRIV for a small
> handful of subops and XSM_PRIV for the rest. Since this is a migration
> the relevant domain is certainly PRIV I think.
>
> Ian.
>
>> Can you check the hypervisor console around this failure and see whether
>> a flask error concerning domctl 72 is reported?
>>
>> ~Andrew

If you get any mention of AVC messages, then FLASK is active and the dummy
policy is not being used.  The FLASK security server can be active without
loading a policy: this is intended to allow dom0 to load the XSM policy in
cases where it is not possible to have the bootloader do it (which is the
preferred method).

If FLASK is active, then any domctl not in the list of handled domctls (see
the large switch statement in xsm/flask/hooks.c) will return -EPERM and
will print an error to the hypervisor console, as Andrew pointed out.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 19:32:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 19:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XszN4-0008KT-SW; Mon, 24 Nov 2014 19:32:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XszN3-0008KO-94
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 19:32:25 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B7/DA-17958-8C783745; Mon, 24 Nov 2014 19:32:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416857542!13503528!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13713 invoked from network); 24 Nov 2014 19:32:23 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-2.tower-31.messagelabs.com with SMTP;
	24 Nov 2014 19:32:23 -0000
X-TM-IMSS-Message-ID: <2e6298a90001a5b3@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 2e6298a90001a5b3 ;
	Mon, 24 Nov 2014 14:32:09 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAOJVmcm020505; 
	Mon, 24 Nov 2014 14:31:58 -0500
Message-ID: <547386C8.7060405@tycho.nsa.gov>
Date: Mon, 24 Nov 2014 14:28:08 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>	
	<20141124124143.GA11483@zion.uk.xensource.com>	
	<54732F8E.4060507@citrix.com>	
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>	
	<547343F4.80509@citrix.com> <1416840918.8878.4.camel@citrix.com>
In-Reply-To: <1416840918.8878.4.camel@citrix.com>
Cc: xen-devel@lists.xen.org, Wei Liu <wei.liu2@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 09:55 AM, Ian Campbell wrote:
> On Mon, 2014-11-24 at 14:43 +0000, Andrew Cooper wrote:
>> On 24/11/14 14:32, M A Young wrote:
>>> On Mon, 24 Nov 2014, Andrew Cooper wrote:
>>>> Is XSM in use?  I can't think of any other reason why that hypercall
>>>> would fail with EPERM.
>>>
>>> XSM is built in (I wanted to allow the option of people using it) but
>>> I didn't think it was active.
>>
>> I don't believe there is any concept of "available but not active",
>
> I think there is, the "dummy" policy which is loaded when there is no
> explicit policy given should behave as if xsm were disabled. AIUI all
> the XSM_* and xsm_default_action stuff is supposed to semi automatically
> ensure this is the case at compile time. CC-ing Daniel to confirm/deny.

Yes.  The case where XSM is enabled at compile time but using the dummy
module is supposed to produce identical behavior to disabling XSM at
compile time.

The hypervisor parameter flask_enabled controls this run-time switching.

>> which probably means that the default policy is missing an entry for
>> this hypercall.
>
> That said domctl is XSM_OTHER, which basically means "special one off
> handling" I think. But it basically turns into XSM_DM_PRIV for a small
> handful of subops and XSM_PRIV for the rest. Since this is a migration
> the relevant domain is certainly PRIV I think.
>
> Ian.
>
>> Can you check the hypervisor console around this failure and see whether
>> a flask error concerning domctl 72 is reported?
>>
>> ~Andrew

If you get any mention of AVC messages, then FLASK is active and the dummy
policy is not being used.  The FLASK security server can be active without
loading a policy: this is intended to allow dom0 to load the XSM policy in
cases where it is not possible to have the bootloader do it (which is the
preferred method).

If FLASK is active, then any domctl not in the list of handled domctls (see
the large switch statement in xsm/flask/hooks.c) will return -EPERM and
will print an error to the hypervisor console, as Andrew pointed out.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 19:59:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 19:59:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XszmZ-0000Cs-9a; Mon, 24 Nov 2014 19:58:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XszmX-0000Cn-9y
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 19:58:45 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D2/F3-02696-4FD83745; Mon, 24 Nov 2014 19:58:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416859122!14525382!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2684 invoked from network); 24 Nov 2014 19:58:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 19:58:43 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOJweiT007180
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 19:58:41 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOJwdGC022298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 19:58:39 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOJwdxA022290; Mon, 24 Nov 2014 19:58:39 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 11:58:38 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org
Date: Mon, 24 Nov 2014 14:49:14 -0500
Message-Id: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for PVH
	guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently when VPMU is enabled on a system both HVM and PVH VPCUs will
initialize their VPMUs, including setting up vpmu_ops. As result even
though VPMU will not work for PVH guests (APIC is not supported there),
the guest may decide to perform a write to a PMU MSR. This will cause a
call to is_vlapic_lvtpc_enabled() which will crash the hypervisor, e.g.:

 (XEN) Xen call trace:
 (XEN)    [<ffff82d0801ca06f>] is_vlapic_lvtpc_enabled+0x13/0x22
 (XEN)    [<ffff82d0801e2a15>] core2_vpmu_do_wrmsr+0x415/0x589
 (XEN)    [<ffff82d0801cedaa>] vpmu_do_wrmsr+0x2a/0x33
 (XEN)    [<ffff82d0801dd648>] vmx_msr_write_intercept+0x268/0x557
 (XEN)    [<ffff82d0801bcd2e>] hvm_msr_write_intercept+0x36c/0x39b
 (XEN)    [<ffff82d0801e0a0e>] vmx_vmexit_handler+0x1082/0x185b
 (XEN)    [<ffff82d0801e74c1>] vmx_asm_vmexit_handler+0x41/0xc0

If we prevent VPMU from being initialized on PVH guests we will avoid
those accesses.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/vpmu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index aec7b5f..4daa993 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -218,6 +218,9 @@ void vpmu_initialise(struct vcpu *v)
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t vendor = current_cpu_data.x86_vendor;
 
+    if ( is_pvh_vcpu(v) )
+        return;
+
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         vpmu_destroy(v);
     vpmu_clear(vpmu);
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 19:59:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 19:59:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XszmZ-0000Cs-9a; Mon, 24 Nov 2014 19:58:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XszmX-0000Cn-9y
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 19:58:45 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D2/F3-02696-4FD83745; Mon, 24 Nov 2014 19:58:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416859122!14525382!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2684 invoked from network); 24 Nov 2014 19:58:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 19:58:43 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAOJweiT007180
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Nov 2014 19:58:41 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOJwdGC022298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 24 Nov 2014 19:58:39 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAOJwdxA022290; Mon, 24 Nov 2014 19:58:39 GMT
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-89.usdhcp.oraclecorp.com.com
	(/10.152.54.238) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 11:58:38 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org
Date: Mon, 24 Nov 2014 14:49:14 -0500
Message-Id: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for PVH
	guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently when VPMU is enabled on a system both HVM and PVH VPCUs will
initialize their VPMUs, including setting up vpmu_ops. As result even
though VPMU will not work for PVH guests (APIC is not supported there),
the guest may decide to perform a write to a PMU MSR. This will cause a
call to is_vlapic_lvtpc_enabled() which will crash the hypervisor, e.g.:

 (XEN) Xen call trace:
 (XEN)    [<ffff82d0801ca06f>] is_vlapic_lvtpc_enabled+0x13/0x22
 (XEN)    [<ffff82d0801e2a15>] core2_vpmu_do_wrmsr+0x415/0x589
 (XEN)    [<ffff82d0801cedaa>] vpmu_do_wrmsr+0x2a/0x33
 (XEN)    [<ffff82d0801dd648>] vmx_msr_write_intercept+0x268/0x557
 (XEN)    [<ffff82d0801bcd2e>] hvm_msr_write_intercept+0x36c/0x39b
 (XEN)    [<ffff82d0801e0a0e>] vmx_vmexit_handler+0x1082/0x185b
 (XEN)    [<ffff82d0801e74c1>] vmx_asm_vmexit_handler+0x41/0xc0

If we prevent VPMU from being initialized on PVH guests we will avoid
those accesses.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/vpmu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index aec7b5f..4daa993 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -218,6 +218,9 @@ void vpmu_initialise(struct vcpu *v)
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t vendor = current_cpu_data.x86_vendor;
 
+    if ( is_pvh_vcpu(v) )
+        return;
+
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         vpmu_destroy(v);
     vpmu_clear(vpmu);
-- 
1.8.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 20:12:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 20:12:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xszzv-0000gv-Rg; Mon, 24 Nov 2014 20:12:35 +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 1Xszzu-0000gq-8R
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 20:12:34 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	9A/06-29352-13193745; Mon, 24 Nov 2014 20:12:33 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416859952!13091452!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23021 invoked from network); 24 Nov 2014 20:12:33 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 20:12:33 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOKCCgF013981;
	Mon, 24 Nov 2014 20:12:16 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOKC7aX029055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 20:12:07 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAOKC76l018241;
	Mon, 24 Nov 2014 20:12:07 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAOKC6ii018237; Mon, 24 Nov 2014 20:12:06 GMT
Date: Mon, 24 Nov 2014 20:12:06 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <547343F4.80509@citrix.com>
Message-ID: <alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
	<547343F4.80509@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAOKCCgF013981
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Mon, 24 Nov 2014, Andrew Cooper wrote:

> On 24/11/14 14:32, M A Young wrote:
>> On Mon, 24 Nov 2014, Andrew Cooper wrote:
>>
>>> On 24/11/14 12:41, Wei Liu wrote:
>>>> On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
>>>>> While investigating a bug reported on Red Hat Bugzilla
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>>> I discovered the following
>>>>>
>>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv
>>>>> (the bug
>>>>> report is for Xen 4.3 hvm ) when xl migrate domid localhost works.
>>>>> There are
>>>>> actually two issues here
>>>>>
>>>>> * the segfault in libxl-save-helper --restore-domain (as reported
>>>>> in the bug
>>>>> above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>>> presumably
>>>>> because the allocated memory eventually runs out
>>>>>
>>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>>> migration
>>>>> still fails. The first attached file contains the log from a run
>>>>> with xl -v
>>>>> migrate --debug domid localhost (with mfn and duplicated lines
>>>>> stripped out
>>>>> to make the size manageable).
>>>>>
>>>>> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
>>>>> migrate doesn't work for me at all - see the second attached file
>>>>> for the
>>>>> output of xl -v migrate domid localhost .
>>>>>
>>>>>     Mchael Young
>>>> [...]
>>>>> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s,
>>>>> dirtied 0Mb/s 314 pages
>>>>> xc: detail: Mapping order 0,  268; first pfn 3fcf4
>>>>> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied
>>>>> 0Mb/s 0 pages
>>>>> xc: detail: Start last iteration
>>>>> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND
>>>>> shinfo 00082fbc
>>>>> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied
>>>>> 1033Mb/s 536 pages
>>>>> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied
>>>>> 2195Mb/s 536 pages
>>>>> xc: detail: Total pages sent= 262749 (1.00x)
>>>>> xc: detail: (of which 0 were fixups)
>>>>> xc: detail: All memory is saved
>>>>> xc: error: Error querying maximum number of MSRs for VCPU0 (1 =
>>>>> Operation not permitted): Internal error
>>>> Per your description this is the output of "xl -v migrate domid
>>>> localhost", so no "--debug" is involved. (Just to make sure...)
>>>>
>>>> This error message means a domctl fails, which should be addressed
>>>> first?
>>>>
>>>> FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
>>>> for me. :-(
>>>>
>>>> Is there anything I need to do to trigger this failure?
>>>
>>> Is XSM in use?  I can't think of any other reason why that hypercall
>>> would fail with EPERM.
>>
>> XSM is built in (I wanted to allow the option of people using it) but
>> I didn't think it was active.
>>
>>     Michael Young
>
> I don't believe there is any concept of "available but not active",
> which probably means that the default policy is missing an entry for
> this hypercall.
>
> Can you check the hypervisor console around this failure and see whether
> a flask error concerning domctl 72 is reported?

I do. The error is
(XEN) flask_domctl: Unknown op 72

Incidentally, Flask is running in permissive mode.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 20:12:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 20:12:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xszzv-0000gv-Rg; Mon, 24 Nov 2014 20:12:35 +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 1Xszzu-0000gq-8R
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 20:12:34 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	9A/06-29352-13193745; Mon, 24 Nov 2014 20:12:33 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416859952!13091452!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23021 invoked from network); 24 Nov 2014 20:12:33 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 20:12:33 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOKCCgF013981;
	Mon, 24 Nov 2014 20:12:16 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAOKC7aX029055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Nov 2014 20:12:07 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAOKC76l018241;
	Mon, 24 Nov 2014 20:12:07 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAOKC6ii018237; Mon, 24 Nov 2014 20:12:06 GMT
Date: Mon, 24 Nov 2014 20:12:06 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <547343F4.80509@citrix.com>
Message-ID: <alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
	<547343F4.80509@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAOKCCgF013981
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Mon, 24 Nov 2014, Andrew Cooper wrote:

> On 24/11/14 14:32, M A Young wrote:
>> On Mon, 24 Nov 2014, Andrew Cooper wrote:
>>
>>> On 24/11/14 12:41, Wei Liu wrote:
>>>> On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
>>>>> While investigating a bug reported on Red Hat Bugzilla
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>>> I discovered the following
>>>>>
>>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv
>>>>> (the bug
>>>>> report is for Xen 4.3 hvm ) when xl migrate domid localhost works.
>>>>> There are
>>>>> actually two issues here
>>>>>
>>>>> * the segfault in libxl-save-helper --restore-domain (as reported
>>>>> in the bug
>>>>> above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>>> presumably
>>>>> because the allocated memory eventually runs out
>>>>>
>>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>>> migration
>>>>> still fails. The first attached file contains the log from a run
>>>>> with xl -v
>>>>> migrate --debug domid localhost (with mfn and duplicated lines
>>>>> stripped out
>>>>> to make the size manageable).
>>>>>
>>>>> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
>>>>> migrate doesn't work for me at all - see the second attached file
>>>>> for the
>>>>> output of xl -v migrate domid localhost .
>>>>>
>>>>>     Mchael Young
>>>> [...]
>>>>> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s,
>>>>> dirtied 0Mb/s 314 pages
>>>>> xc: detail: Mapping order 0,  268; first pfn 3fcf4
>>>>> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied
>>>>> 0Mb/s 0 pages
>>>>> xc: detail: Start last iteration
>>>>> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND
>>>>> shinfo 00082fbc
>>>>> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied
>>>>> 1033Mb/s 536 pages
>>>>> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied
>>>>> 2195Mb/s 536 pages
>>>>> xc: detail: Total pages sent= 262749 (1.00x)
>>>>> xc: detail: (of which 0 were fixups)
>>>>> xc: detail: All memory is saved
>>>>> xc: error: Error querying maximum number of MSRs for VCPU0 (1 =
>>>>> Operation not permitted): Internal error
>>>> Per your description this is the output of "xl -v migrate domid
>>>> localhost", so no "--debug" is involved. (Just to make sure...)
>>>>
>>>> This error message means a domctl fails, which should be addressed
>>>> first?
>>>>
>>>> FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
>>>> for me. :-(
>>>>
>>>> Is there anything I need to do to trigger this failure?
>>>
>>> Is XSM in use?  I can't think of any other reason why that hypercall
>>> would fail with EPERM.
>>
>> XSM is built in (I wanted to allow the option of people using it) but
>> I didn't think it was active.
>>
>>     Michael Young
>
> I don't believe there is any concept of "available but not active",
> which probably means that the default policy is missing an entry for
> this hypercall.
>
> Can you check the hypervisor console around this failure and see whether
> a flask error concerning domctl 72 is reported?

I do. The error is
(XEN) flask_domctl: Unknown op 72

Incidentally, Flask is running in permissive mode.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 20:36:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 20: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 1Xt0Mg-00012P-3t; Mon, 24 Nov 2014 20:36:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xt0Me-00012K-QF
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 20:36:05 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	7A/FC-02712-4B693745; Mon, 24 Nov 2014 20:36:04 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416861361!14531599!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2911 invoked from network); 24 Nov 2014 20:36:03 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 20:36:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416861363; x=1448397363;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=8O7lYN5Ams/6iKlsEeleK7CNdU8olm/f0k9QTbh8lN8=;
	b=iDNyYoDOnKjK29ZGECiyZenpdqqfDajY5XTwO0irYv5F3spzZgjCwtaE
	tGYSTz3mtmW29g7T1nDpcaDu3IA4DdeNiZOU5SIXwCKmEZnDPWDQ62xQ0
	MIGcVnPkk8Bw19cTwITLli1qWPkNEQRVJbUZ1zkdO7Z5WMZrruLLQQ+Hi A=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 24 Nov 2014 20:36:00 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,451,1413244800"; d="scan'208";a="913381535"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.80])
	by fldsmtpi01.verizon.com with ESMTP; 24 Nov 2014 20:35:59 +0000
Message-ID: <547396AE.7050806@terremark.com>
Date: Mon, 24 Nov 2014 15:35:58 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Don Slutz <dslutz@verizon.com>
References: <1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
	<20141124150649.GB3946@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
	<5473582C.6080000@terremark.com>
	<alpine.DEB.2.02.1411241706090.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411241706090.2675@kaball.uk.xensource.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/14 12:07, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Don Slutz wrote:
>> On 11/24/14 10:26, Stefano Stabellini wrote:
>>> On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
>>>> On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
>>>>> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
>>>>>> On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
>>>>>>> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
>>>>>>>> On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini
>>>>>>>> wrote:
>>>>>>>>> The rom is used for pxebooting. We don't need to allow
>>>>>>>>> pxebooting from
>>>>>>>>> more than one network card.  Loading a romfile for every NIC
>>>>>>>>> wastes
>>>>>>>> Why not? Why can't we PXE boot from each network card?
>>>>>>> I take it back: you are right, at the moment it is actually possible
>>>>>>> to
>>>>>>> pxe boot from the fourth nic for example. Maybe we could just load
>>>>>>> the
>>>>>>> first four romfiles and skip the others (four is the limit before
>>>>>>> QEMU
>>>>>>> fails to allocate any more memory).
>>>>>> The limit is in the count of ROMs or the memory consumption?
>>>>> The limit is memory consumption.
>>>> Um, how big are those ROMs? Gigs?
>>> I think they are 60K each in the case of rtl8139.
>>> However they are accounted on top of the ram of the guest, that's why
>>> the allocation fails. Strictly speaking I guess it shouldn't work even
>>> the first time around.
>> My extra QEMU debug says:
>>
>> xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42010000
>> mr.name=rtl8139.rom
>> e1000 vhdr enabled
>> xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42050000
>> mr.name=e1000.rom
>>
>> And that matches the max of 4.
>>
>> #define LIBXL_MAXMEM_CONSTANT 1024
>>
>> is what controls this.
>>
>>> Maybe the bug is in libxl memory allocation, that doesn't account for
>>> rom sizes.
>> Yes.
> Here is a better patch.
>
> ---
>
> libxl: account for romfile memory
>
> Account for memory needed for emulated network card rom files.
> Assume 256K for each romfile.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

This looks to be a good idea, just not fully done.

> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..2edb194 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4527,6 +4527,33 @@ out:
>   
>   /******************************************************************************/
>   
> +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> +{
> +    int i, count_rom, rc;
> +    libxl_domain_config local_d_config;
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +
> +    if (d_config == NULL) {
> +        libxl_domain_config_init(&local_d_config);
> +        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
> +        if (rc < 0)
> +            return rc;
> +        d_config = &local_d_config;
> +    }
> +
> +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> +        return 0;
> +
> +    for (i = 0, count_rom = 0; i < d_config->num_nics; i++) {
> +        if (d_config->nics[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU)
> +            count_rom++;
> +    }
> +
> +    return count_rom*LIBXL_ROMSIZE_KB;
> +
> +    return 0;

2 return statements?

> +}
> +
>   int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
>   {
>       GC_INIT(ctx);
> @@ -4550,11 +4577,14 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
>           goto out;
>       }
> -    rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + LIBXL_MAXMEM_CONSTANT);
> +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> +                             + libxl__get_rom_memory_kb(gc, domid, NULL));

Here (and the rest) need to check for error's.  Also I think that
LIBXL_MAXMEM_CONSTANT can be dropped here.  I found out that

#define LIBXL_HVM_EXTRA_MEMORY 2048

Should be

#define LIBXL_HVM_EXTRA_MEMORY (LIBXL_MAXMEM_CONSTANT + 1024)

if you change the size of the ROM memory for QEMU.  I have only done the 
static
change.

    -Don Slutz


>       if (rc != 0) {
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                   "xc_domain_setmaxmem domid=%d memkb=%d failed "
> -                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
> +                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT +
> +                libxl__get_rom_memory_kb(gc, domid, NULL), rc);
>           goto out;
>       }
>   
> @@ -4770,11 +4800,12 @@ retry_transaction:
>       if (enforce) {
>           memorykb = new_target_memkb;
>           rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
> -                LIBXL_MAXMEM_CONSTANT);
> +                LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid, NULL));
>           if (rc != 0) {
>               LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                       "xc_domain_setmaxmem domid=%d memkb=%d failed "
> -                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
> +                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT +
> +                    libxl__get_rom_memory_kb(gc, domid, NULL), rc);
>               abort_transaction = 1;
>               goto out;
>           }
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 74ea84b..ca254f9 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -406,7 +406,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>       }
>   
>       if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> -        LIBXL_MAXMEM_CONSTANT) < 0) {
> +        LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid, d_config)) < 0) {
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't set max memory");
>           return ERROR_FAIL;
>       }
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4361421..33826ea 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -90,6 +90,7 @@
>   #define LIBXL_XENCONSOLE_LIMIT 1048576
>   #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
>   #define LIBXL_MAXMEM_CONSTANT 1024
> +#define LIBXL_ROMSIZE_KB 256
>   #define LIBXL_PV_EXTRA_MEMORY 1024
>   #define LIBXL_HVM_EXTRA_MEMORY 2048
>   #define LIBXL_MIN_DOM0_MEM (128*1024)
> @@ -1023,6 +1024,12 @@ _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
>   _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
>                                             uint32_t domid, const char *cmd);
>   
> +/* Returns the amount of extra mem required to allocate roms or an libxl
> + * error code on error.
> + * The *d_config parameter is optional.
> + */
> +_hidden int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
> +
>   /* from xl_device */
>   _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
>   _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 20:36:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 20: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 1Xt0Mg-00012P-3t; Mon, 24 Nov 2014 20:36:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xt0Me-00012K-QF
	for xen-devel@lists.xensource.com; Mon, 24 Nov 2014 20:36:05 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	7A/FC-02712-4B693745; Mon, 24 Nov 2014 20:36:04 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416861361!14531599!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2911 invoked from network); 24 Nov 2014 20:36:03 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 20:36:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1416861363; x=1448397363;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=8O7lYN5Ams/6iKlsEeleK7CNdU8olm/f0k9QTbh8lN8=;
	b=iDNyYoDOnKjK29ZGECiyZenpdqqfDajY5XTwO0irYv5F3spzZgjCwtaE
	tGYSTz3mtmW29g7T1nDpcaDu3IA4DdeNiZOU5SIXwCKmEZnDPWDQ62xQ0
	MIGcVnPkk8Bw19cTwITLli1qWPkNEQRVJbUZ1zkdO7Z5WMZrruLLQQ+Hi A=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 24 Nov 2014 20:36:00 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,451,1413244800"; d="scan'208";a="913381535"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.80])
	by fldsmtpi01.verizon.com with ESMTP; 24 Nov 2014 20:35:59 +0000
Message-ID: <547396AE.7050806@terremark.com>
Date: Mon, 24 Nov 2014 15:35:58 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Don Slutz <dslutz@verizon.com>
References: <1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
	<20141124150649.GB3946@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
	<5473582C.6080000@terremark.com>
	<alpine.DEB.2.02.1411241706090.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411241706090.2675@kaball.uk.xensource.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/14 12:07, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Don Slutz wrote:
>> On 11/24/14 10:26, Stefano Stabellini wrote:
>>> On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
>>>> On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
>>>>> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
>>>>>> On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini wrote:
>>>>>>> On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
>>>>>>>> On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini
>>>>>>>> wrote:
>>>>>>>>> The rom is used for pxebooting. We don't need to allow
>>>>>>>>> pxebooting from
>>>>>>>>> more than one network card.  Loading a romfile for every NIC
>>>>>>>>> wastes
>>>>>>>> Why not? Why can't we PXE boot from each network card?
>>>>>>> I take it back: you are right, at the moment it is actually possible
>>>>>>> to
>>>>>>> pxe boot from the fourth nic for example. Maybe we could just load
>>>>>>> the
>>>>>>> first four romfiles and skip the others (four is the limit before
>>>>>>> QEMU
>>>>>>> fails to allocate any more memory).
>>>>>> The limit is in the count of ROMs or the memory consumption?
>>>>> The limit is memory consumption.
>>>> Um, how big are those ROMs? Gigs?
>>> I think they are 60K each in the case of rtl8139.
>>> However they are accounted on top of the ram of the guest, that's why
>>> the allocation fails. Strictly speaking I guess it shouldn't work even
>>> the first time around.
>> My extra QEMU debug says:
>>
>> xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42010000
>> mr.name=rtl8139.rom
>> e1000 vhdr enabled
>> xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42050000
>> mr.name=e1000.rom
>>
>> And that matches the max of 4.
>>
>> #define LIBXL_MAXMEM_CONSTANT 1024
>>
>> is what controls this.
>>
>>> Maybe the bug is in libxl memory allocation, that doesn't account for
>>> rom sizes.
>> Yes.
> Here is a better patch.
>
> ---
>
> libxl: account for romfile memory
>
> Account for memory needed for emulated network card rom files.
> Assume 256K for each romfile.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

This looks to be a good idea, just not fully done.

> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..2edb194 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4527,6 +4527,33 @@ out:
>   
>   /******************************************************************************/
>   
> +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> +{
> +    int i, count_rom, rc;
> +    libxl_domain_config local_d_config;
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +
> +    if (d_config == NULL) {
> +        libxl_domain_config_init(&local_d_config);
> +        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
> +        if (rc < 0)
> +            return rc;
> +        d_config = &local_d_config;
> +    }
> +
> +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> +        return 0;
> +
> +    for (i = 0, count_rom = 0; i < d_config->num_nics; i++) {
> +        if (d_config->nics[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU)
> +            count_rom++;
> +    }
> +
> +    return count_rom*LIBXL_ROMSIZE_KB;
> +
> +    return 0;

2 return statements?

> +}
> +
>   int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
>   {
>       GC_INIT(ctx);
> @@ -4550,11 +4577,14 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
>           goto out;
>       }
> -    rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + LIBXL_MAXMEM_CONSTANT);
> +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> +                             + libxl__get_rom_memory_kb(gc, domid, NULL));

Here (and the rest) need to check for error's.  Also I think that
LIBXL_MAXMEM_CONSTANT can be dropped here.  I found out that

#define LIBXL_HVM_EXTRA_MEMORY 2048

Should be

#define LIBXL_HVM_EXTRA_MEMORY (LIBXL_MAXMEM_CONSTANT + 1024)

if you change the size of the ROM memory for QEMU.  I have only done the 
static
change.

    -Don Slutz


>       if (rc != 0) {
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                   "xc_domain_setmaxmem domid=%d memkb=%d failed "
> -                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
> +                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT +
> +                libxl__get_rom_memory_kb(gc, domid, NULL), rc);
>           goto out;
>       }
>   
> @@ -4770,11 +4800,12 @@ retry_transaction:
>       if (enforce) {
>           memorykb = new_target_memkb;
>           rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
> -                LIBXL_MAXMEM_CONSTANT);
> +                LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid, NULL));
>           if (rc != 0) {
>               LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                       "xc_domain_setmaxmem domid=%d memkb=%d failed "
> -                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
> +                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT +
> +                    libxl__get_rom_memory_kb(gc, domid, NULL), rc);
>               abort_transaction = 1;
>               goto out;
>           }
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 74ea84b..ca254f9 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -406,7 +406,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>       }
>   
>       if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> -        LIBXL_MAXMEM_CONSTANT) < 0) {
> +        LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid, d_config)) < 0) {
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't set max memory");
>           return ERROR_FAIL;
>       }
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4361421..33826ea 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -90,6 +90,7 @@
>   #define LIBXL_XENCONSOLE_LIMIT 1048576
>   #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
>   #define LIBXL_MAXMEM_CONSTANT 1024
> +#define LIBXL_ROMSIZE_KB 256
>   #define LIBXL_PV_EXTRA_MEMORY 1024
>   #define LIBXL_HVM_EXTRA_MEMORY 2048
>   #define LIBXL_MIN_DOM0_MEM (128*1024)
> @@ -1023,6 +1024,12 @@ _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
>   _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
>                                             uint32_t domid, const char *cmd);
>   
> +/* Returns the amount of extra mem required to allocate roms or an libxl
> + * error code on error.
> + * The *d_config parameter is optional.
> + */
> +_hidden int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
> +
>   /* from xl_device */
>   _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
>   _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 21:15:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 21:15:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xt0yO-0001cC-2Y; Mon, 24 Nov 2014 21:15:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Xt0yM-0001c7-2D
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 21:15:02 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	44/E2-27584-5DF93745; Mon, 24 Nov 2014 21:15:01 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416863700!5526109!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26214 invoked from network); 24 Nov 2014 21:15:00 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-3.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 21:15:00 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 078C458724C;
	Mon, 24 Nov 2014 13:14:58 -0800 (PST)
Date: Mon, 24 Nov 2014 16:14:57 -0500 (EST)
Message-Id: <20141124.161457.416165119227187597.davem@davemloft.net>
To: khoroshilov@ispras.ru
From: David Miller <davem@davemloft.net>
In-Reply-To: <1416826680-19145-1-git-send-email-khoroshilov@ispras.ru>
References: <20141124100053.GC30053@zion.uk.xensource.com>
	<1416826680-19145-1-git-send-email-khoroshilov@ispras.ru>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Mon, 24 Nov 2014 13:14:59 -0800 (PST)
Cc: ldv-project@linuxtesting.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netback: do not report success if
 backend_create_xenvif() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date: Mon, 24 Nov 2014 13:58:00 +0300

> If xenvif_alloc() or xenbus_scanf() fail in backend_create_xenvif(),
> xenbus is left in offline mode but netback_probe() reports success.
> 
> The patch implements propagation of error code for backend_create_xenvif().
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 21:15:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 21:15:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xt0yO-0001cC-2Y; Mon, 24 Nov 2014 21:15:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Xt0yM-0001c7-2D
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 21:15:02 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	44/E2-27584-5DF93745; Mon, 24 Nov 2014 21:15:01 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416863700!5526109!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26214 invoked from network); 24 Nov 2014 21:15:00 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-3.tower-206.messagelabs.com with SMTP;
	24 Nov 2014 21:15:00 -0000
Received: from localhost (nat-pool-rdu-t.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 078C458724C;
	Mon, 24 Nov 2014 13:14:58 -0800 (PST)
Date: Mon, 24 Nov 2014 16:14:57 -0500 (EST)
Message-Id: <20141124.161457.416165119227187597.davem@davemloft.net>
To: khoroshilov@ispras.ru
From: David Miller <davem@davemloft.net>
In-Reply-To: <1416826680-19145-1-git-send-email-khoroshilov@ispras.ru>
References: <20141124100053.GC30053@zion.uk.xensource.com>
	<1416826680-19145-1-git-send-email-khoroshilov@ispras.ru>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Mon, 24 Nov 2014 13:14:59 -0800 (PST)
Cc: ldv-project@linuxtesting.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netback: do not report success if
 backend_create_xenvif() fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date: Mon, 24 Nov 2014 13:58:00 +0300

> If xenvif_alloc() or xenbus_scanf() fail in backend_create_xenvif(),
> xenbus is left in offline mode but netback_probe() reports success.
> 
> The patch implements propagation of error code for backend_create_xenvif().
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 22:09:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 22: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 1Xt1p1-0002Hc-Fi; Mon, 24 Nov 2014 22:09:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Xt1p0-0002HX-2u
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 22:09:26 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	98/CE-25276-59CA3745; Mon, 24 Nov 2014 22:09:25 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416866964!11575354!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4047 invoked from network); 24 Nov 2014 22:09:24 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-16.tower-21.messagelabs.com with SMTP;
	24 Nov 2014 22:09:24 -0000
X-TM-IMSS-Message-ID: <52c444cf0001d1a8@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 52c444cf0001d1a8 ;
	Mon, 24 Nov 2014 17:09:24 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAOM93Nj031854; 
	Mon, 24 Nov 2014 17:09:13 -0500
Message-ID: <5473ABA2.6080901@tycho.nsa.gov>
Date: Mon, 24 Nov 2014 17:05:22 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>,
	Andrew Cooper <andrew.cooper3@citrix.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
	<547343F4.80509@citrix.com>
	<alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 03:12 PM, M A Young wrote:
> On Mon, 24 Nov 2014, Andrew Cooper wrote:
>> On 24/11/14 14:32, M A Young wrote:
>>> On Mon, 24 Nov 2014, Andrew Cooper wrote:
>>>> On 24/11/14 12:41, Wei Liu wrote:
>>>>> On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
>>>>>> While investigating a bug reported on Red Hat Bugzilla
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>>>> I discovered the following
>>>>>>
>>>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv
>>>>>> (the bug
>>>>>> report is for Xen 4.3 hvm ) when xl migrate domid localhost works.
>>>>>> There are
>>>>>> actually two issues here
>>>>>>
>>>>>> * the segfault in libxl-save-helper --restore-domain (as reported
>>>>>> in the bug
>>>>>> above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>>>> presumably
>>>>>> because the allocated memory eventually runs out
>>>>>>
>>>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>>>> migration
>>>>>> still fails. The first attached file contains the log from a run
>>>>>> with xl -v
>>>>>> migrate --debug domid localhost (with mfn and duplicated lines
>>>>>> stripped out
>>>>>> to make the size manageable).
>>>>>>
>>>>>> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
>>>>>> migrate doesn't work for me at all - see the second attached file
>>>>>> for the
>>>>>> output of xl -v migrate domid localhost .
>>>>>>
>>>>>>     Mchael Young
>>>>> [...]
>>>>>> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s,
>>>>>> dirtied 0Mb/s 314 pages
>>>>>> xc: detail: Mapping order 0,  268; first pfn 3fcf4
>>>>>> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied
>>>>>> 0Mb/s 0 pages
>>>>>> xc: detail: Start last iteration
>>>>>> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND
>>>>>> shinfo 00082fbc
>>>>>> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied
>>>>>> 1033Mb/s 536 pages
>>>>>> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied
>>>>>> 2195Mb/s 536 pages
>>>>>> xc: detail: Total pages sent= 262749 (1.00x)
>>>>>> xc: detail: (of which 0 were fixups)
>>>>>> xc: detail: All memory is saved
>>>>>> xc: error: Error querying maximum number of MSRs for VCPU0 (1 =
>>>>>> Operation not permitted): Internal error
>>>>> Per your description this is the output of "xl -v migrate domid
>>>>> localhost", so no "--debug" is involved. (Just to make sure...)
>>>>>
>>>>> This error message means a domctl fails, which should be addressed
>>>>> first?
>>>>>
>>>>> FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
>>>>> for me. :-(
>>>>>
>>>>> Is there anything I need to do to trigger this failure?
>>>>
>>>> Is XSM in use?  I can't think of any other reason why that hypercall
>>>> would fail with EPERM.
>>>
>>> XSM is built in (I wanted to allow the option of people using it) but
>>> I didn't think it was active.
>>>
>>>     Michael Young
>>
>> I don't believe there is any concept of "available but not active",
>> which probably means that the default policy is missing an entry for
>> this hypercall.
>>
>> Can you check the hypervisor console around this failure and see whether
>> a flask error concerning domctl 72 is reported?
>
> I do. The error is
> (XEN) flask_domctl: Unknown op 72
>
> Incidentally, Flask is running in permissive mode.
>
>      Michael Young
>

This means that the new domctl needs to be added to the switch statement
in flask/hooks.c.  This error is triggered in permissive mode because it
is a code error rather than a policy error (which is what permissive mode
is intended to debug).

It looks like neither XEN_DOMCTL_get_vcpu_msrs or XEN_DOMCTL_set_vcpu_msrs
have a FLASK hook.  Andrew, did you want to add these since you introduced
the ops?

Unless you can think of a reason why there would be a reason to split the
access, I think it makes sense to reuse the permissions that are used for
XEN_DOMCTL_{get,set}_ext_vcpucontext.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 22:09:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 22: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 1Xt1p1-0002Hc-Fi; Mon, 24 Nov 2014 22:09:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Xt1p0-0002HX-2u
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 22:09:26 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	98/CE-25276-59CA3745; Mon, 24 Nov 2014 22:09:25 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416866964!11575354!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4047 invoked from network); 24 Nov 2014 22:09:24 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-16.tower-21.messagelabs.com with SMTP;
	24 Nov 2014 22:09:24 -0000
X-TM-IMSS-Message-ID: <52c444cf0001d1a8@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 52c444cf0001d1a8 ;
	Mon, 24 Nov 2014 17:09:24 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAOM93Nj031854; 
	Mon, 24 Nov 2014 17:09:13 -0500
Message-ID: <5473ABA2.6080901@tycho.nsa.gov>
Date: Mon, 24 Nov 2014 17:05:22 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>,
	Andrew Cooper <andrew.cooper3@citrix.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
	<547343F4.80509@citrix.com>
	<alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 03:12 PM, M A Young wrote:
> On Mon, 24 Nov 2014, Andrew Cooper wrote:
>> On 24/11/14 14:32, M A Young wrote:
>>> On Mon, 24 Nov 2014, Andrew Cooper wrote:
>>>> On 24/11/14 12:41, Wei Liu wrote:
>>>>> On Sat, Nov 22, 2014 at 07:24:21PM +0000, M A Young wrote:
>>>>>> While investigating a bug reported on Red Hat Bugzilla
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>>>> I discovered the following
>>>>>>
>>>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv
>>>>>> (the bug
>>>>>> report is for Xen 4.3 hvm ) when xl migrate domid localhost works.
>>>>>> There are
>>>>>> actually two issues here
>>>>>>
>>>>>> * the segfault in libxl-save-helper --restore-domain (as reported
>>>>>> in the bug
>>>>>> above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>>>> presumably
>>>>>> because the allocated memory eventually runs out
>>>>>>
>>>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>>>> migration
>>>>>> still fails. The first attached file contains the log from a run
>>>>>> with xl -v
>>>>>> migrate --debug domid localhost (with mfn and duplicated lines
>>>>>> stripped out
>>>>>> to make the size manageable).
>>>>>>
>>>>>> I then tried xen 4.5-rc1 to see if the bug was fixed and found that xl
>>>>>> migrate doesn't work for me at all - see the second attached file
>>>>>> for the
>>>>>> output of xl -v migrate domid localhost .
>>>>>>
>>>>>>     Mchael Young
>>>>> [...]
>>>>>> xc: detail: delta 15801ms, dom0 95%, target 0%, sent 543Mb/s,
>>>>>> dirtied 0Mb/s 314 pages
>>>>>> xc: detail: Mapping order 0,  268; first pfn 3fcf4
>>>>>> xc: detail: delta 23ms, dom0 100%, target 0%, sent 447Mb/s, dirtied
>>>>>> 0Mb/s 0 pages
>>>>>> xc: detail: Start last iteration
>>>>>> xc: Reloading memory pages: 262213/262144  100%xc: detail: SUSPEND
>>>>>> shinfo 00082fbc
>>>>>> xc: detail: delta 17ms, dom0 58%, target 58%, sent 0Mb/s, dirtied
>>>>>> 1033Mb/s 536 pages
>>>>>> xc: detail: delta 8ms, dom0 100%, target 0%, sent 2195Mb/s, dirtied
>>>>>> 2195Mb/s 536 pages
>>>>>> xc: detail: Total pages sent= 262749 (1.00x)
>>>>>> xc: detail: (of which 0 were fixups)
>>>>>> xc: detail: All memory is saved
>>>>>> xc: error: Error querying maximum number of MSRs for VCPU0 (1 =
>>>>>> Operation not permitted): Internal error
>>>>> Per your description this is the output of "xl -v migrate domid
>>>>> localhost", so no "--debug" is involved. (Just to make sure...)
>>>>>
>>>>> This error message means a domctl fails, which should be addressed
>>>>> first?
>>>>>
>>>>> FWIW I tried "xl -v migrate domid localhost" for a PV guest it worked
>>>>> for me. :-(
>>>>>
>>>>> Is there anything I need to do to trigger this failure?
>>>>
>>>> Is XSM in use?  I can't think of any other reason why that hypercall
>>>> would fail with EPERM.
>>>
>>> XSM is built in (I wanted to allow the option of people using it) but
>>> I didn't think it was active.
>>>
>>>     Michael Young
>>
>> I don't believe there is any concept of "available but not active",
>> which probably means that the default policy is missing an entry for
>> this hypercall.
>>
>> Can you check the hypervisor console around this failure and see whether
>> a flask error concerning domctl 72 is reported?
>
> I do. The error is
> (XEN) flask_domctl: Unknown op 72
>
> Incidentally, Flask is running in permissive mode.
>
>      Michael Young
>

This means that the new domctl needs to be added to the switch statement
in flask/hooks.c.  This error is triggered in permissive mode because it
is a code error rather than a policy error (which is what permissive mode
is intended to debug).

It looks like neither XEN_DOMCTL_get_vcpu_msrs or XEN_DOMCTL_set_vcpu_msrs
have a FLASK hook.  Andrew, did you want to add these since you introduced
the ops?

Unless you can think of a reason why there would be a reason to split the
access, I think it makes sense to reuse the permissions that are used for
XEN_DOMCTL_{get,set}_ext_vcpucontext.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 22:17:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 22: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 1Xt1wb-0002VN-EP; Mon, 24 Nov 2014 22:17:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xt1wa-0002VI-1Q
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 22:17:16 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	04/18-22737-B6EA3745; Mon, 24 Nov 2014 22:17:15 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416867429!7825089!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19857 invoked from network); 24 Nov 2014 22:17:10 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 22:17:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416867428; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=jYM2BlIMuFrurb1cwKc4DZOjNEeXwXcHPkHMSNMFbWg=;
	b=gIUUTKY5LLbLoIklAsGWzmza4SYG8STccVzzRLGynKiSGlB7nN/rNefIbAJbs8YPIS4lOvDvMf051iv2wEaD4YMZBVSU/Zdy3kYT1+x46Z3CWo7W+O6gdM2rNRAWnL6HAUm1yvDe0YlFic/LVY+zL+Hwobvgwwl7O1GtuCEaX80=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 24 Nov 2014 14:17:07 -0800
	id 0000000000030434.5473AE63.00007A92
Message-ID: <5473AE78.5070505@ihonk.com>
Date: Mon, 24 Nov 2014 14:17:28 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5457F79B.2020300@ihonk.com>
	<20141104082012.GY12451@reaktio.net>	<5458B55C0200007800044B33@mail.emea.novell.com>	<5460716A.7090905@ihonk.com>	<54608A8B0200007800045E58@mail.emea.novell.com>	<54611A86.4000200@ihonk.com>	<5461D15C02000078000464D7@mail.emea.novell.com>	<546A4AD4.3030002@ihonk.com>	<546B094C0200007800048A5C@mail.emea.novell.com>	<546D429A.5020906@ihonk.com>	<546DAD6502000078000492FD@mail.emea.novell.com>	<546E4A17.5040902@ihonk.com>	<546F091F0200007800049A1C@smtp.nue.novell.com>	<54713848.3020401@ihonk.com>	<5472FE31020000780004A2D5@mail.emea.novell.com>	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
In-Reply-To: <54732768020000780004A48C@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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.11.14 at 10:08,<sflist@ihonk.com>  wrote:
> On Nov 24, 2014, at 00:45, Jan Beulich<JBeulich@suse.com>  wrote:
>>>>> On 23.11.14 at 02:28,<sflist@ihonk.com>  wrote:
>>> As promised, below is the apic-verbosity=debug log, with 'i'. Thanks!
>> I'm sorry, I misspelled the option, it's really "apic_verbosity=debug".
>> The 'i' output at least already confirms that there are no ExtINT
>> entries among the IO-APIC RTEs.
> No sweat. Do you need me to run it again with the corrected option?
> Yes please, just to be certain we can discount that one.
>

I'm combining this action with your patch, see below. Please let me know 
if this was incorrect.

On 11/24/2014 3:41, Jan Beulich wrote:
> While putting this together I found the reason for the strange C2: 
> line, and the attached debugging patch already has the fix for it 
> (which I'll also submit separately, and hence you may need to drop 
> that specific hunk should you end up applying it on a tree which 
> already has that fix). You'll need to again run with "mwait-idle=0", 
> and it's the boot messages along with the 'c' debug key output that's 
> of interest. Thanks, Jan

I applied the patch to 4.5-rc2, this was the patch output:

steve@g2:~/git/xen$ patch -p1 < ../Freitas-Cx.patch
patching file xen/arch/x86/acpi/cpu_idle.c
Hunk #2 succeeded at 229 (offset -9 lines).
Hunk #3 succeeded at 263 (offset -10 lines).
Hunk #4 succeeded at 491 (offset -10 lines).
Hunk #5 succeeded at 504 (offset -15 lines).
Hunk #6 succeeded at 992 (offset -15 lines).
Hunk #7 succeeded at 1000 (offset -15 lines).
patch unexpectedly ends in middle of line
Hunk #8 succeeded at 1126 with fuzz 1 (offset -15 lines).

And here's the boot log, with 'c' and 'i' output from Xen:

[?25lGNU GRUB  version 2.02~beta2-15

+----------------------------------------------------------------------------+||||||||||||||||||||||||+----------------------------------------------------------------------------+ 
Use the ^ and v keys to select which entry is highlighted.
       Press enter to boot the selected OS, `e' to edit the commands
       before booting or `c' for a 
command-line.                            *Debian 
GNU/Linux, with Xen hypervisor  Advanced options 
for Debian GNU/Linux (with Xen hypervisor)                
 Debian GNU/Linux  Advanced 
options for Debian GNU/Linux  
  
  
  
     The 
highlighted entry will be executed automatically in 
10s.                 The highlighted entry will be 
executed automatically in 9s.                    The 
highlighted entry will be executed automatically in 
8s.                    The highlighted entry will be 
executed automatically in 7s.                    The 
highlighted entry will be executed automatically in 
6s.                    The highlighted entry will be 
executed automatically in 5s.                    The 
highlighted entry will be executed automatically in 
4s.                    The highlighted entry will be 
executed automatically in 3s.                    The 
highlighted entry will be executed automatically in 
2s.                    The highlighted entry will be 
executed automatically in 1s.                    The 
highlighted entry will be executed automatically in 0s. 
[?25hLoading Xen xen ...
Loading Linux 3.16-3-amd64 ...
Loading initial ramdisk ...
  Xen 4.5.0-rc
(XEN) Xen version 4.5.0-rc (steve@) (gcc (Debian 4.9.1-19) 4.9.1) 
debug=y Mon Nov 24 13:47:48 PST 2014
(XEN) Latest ChangeSet: Tue Nov 11 09:40:20 2014 -0500 git:cacfcc5-dirty
(XEN) Bootloader: GRUB 2.02~beta2-15
(XEN) Command line: placeholder cpufreq=xen:ondemand cpuidle 
clocksource=hpet loglvl=all guest_loglvl=all iommu=no-intremap,debug 
com1=115200,8n1 console=com1,vga apic_verbosity=debug mwait-idle=0
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 2 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d000 (usable)
(XEN)  000000000009d000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf7a0000 (usable)
(XEN)  00000000bf7a0000 - 00000000bf7ca000 (ACPI data)
(XEN)  00000000bf7ca000 - 00000000bf7cc000 (ACPI NVS)
(XEN)  00000000bf7cc000 - 00000000c0000000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000F6A40, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT BF7BF38F, 0084 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: FACP BF7C98D1, 00F4 (r3 LENOVO TC-61     60400D0 PTL         2)
(XEN) ACPI: DSDT BF7BF413, A43A (r1 LENOVO TC-61     60400D0 MSFT 100000E)
(XEN) ACPI: FACS BF7CBFC0, 0040
(XEN) ACPI: SSDT BF7AF33B, 2694 (r1  INTEL PPM RCM  80000001 INTL 20061109)
(XEN) ACPI: SLIT BF7C99E9, 0030 (r1 Intel  TYLERBRG  60400D0 LOHR       5A)
(XEN) ACPI: TCPA BF7C9A19, 0032 (r1 LENOVO TC-61     60400D0 PTL         0)
(XEN) ACPI: SLIC BF7C9A4B, 0176 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: SRAT BF7C9BC1, 00E0 (r1 Intel  Tylerbrg  60400D0 PHX.        1)
(XEN) ACPI: DMAR BF7C9CA1, 01C0 (r1 Intel  OEMDMAR   60400D0 LOHR        1)
(XEN) ACPI: APIC BF7C9E61, 00A0 (r1 PTLTD       APIC    60400D0 
LTP        0)
(XEN) ACPI: MCFG BF7C9F01, 003C (r1 PTLTD    MCFG    60400D0 LTP        0)
(XEN) ACPI: HPET BF7C9F3D, 0038 (r1 PTLTD  HPETTBL   60400D0 LTP        1)
(XEN) ACPI: BOOT BF7C9F75, 0028 (r1 PTLTD  $SBFTBL$  60400D0 LTP        1)
(XEN) ACPI: ASF! BF7C9F9D, 0063 (r32 LENOVO TC-61     60400D0 PTL         1)
(XEN) System RAM: 49143MB (50322676kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: Node 0 PXM 0 0-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-c40000000
(XEN) NUMA: Using 20 for the hash shift.
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000f6a70
(XEN) DMI present.
(XEN) APIC boot state is 'xapic'
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1008
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1004,1:0], pm1x_evt[1:1000,1:0]
(XEN) ACPI:             wakeup_vec[bf7cbfcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(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: 0x8086a301 base: 0xfed00000
(XEN) [VT-D]dmar.c:788: Host address width 40
(XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:472:   dmaru->address = fe710000
(XEN) [VT-D]iommu.c:1146: drhd->address = fe710000 iommu->reg = 
ffff82c000201000
(XEN) [VT-D]iommu.c:1148: cap = c90780106f0462 ecap = f0207f
(XEN) [VT-D]dmar.c:397:  IOAPIC: 0000:f0:1f.7
(XEN) [VT-D]dmar.c:486:   flags: INCLUDE_ALL
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.1
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.7
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.1
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.2
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.3
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7cd000 end_address 
bf7dbfff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e4000 end_address 
bf7e4fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.1
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e5000 end_address 
bf7e5fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7ea000 end_address 
bf7eafff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e6000 end_address 
bf7e6fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.1
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e7000 end_address 
bf7e7fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.2
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e8000 end_address 
bf7e8fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.3
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e9000 end_address 
bf7e9fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7eb000 end_address 
bf7ebfff
(XEN) [VT-D]dmar.c:812: found ACPI_DMAR_ATSR:
(XEN) [VT-D]dmar.c:705:   atsru->all_ports: 0
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:01.0 start=0 sec=1 sub=1
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:03.0 start=0 sec=2 sub=2
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:07.0 start=0 sec=3 sub=3
(XEN) ERST table was not found
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 6 CPUs (0 hotplug CPUs)
(XEN) mapped APIC to ffff82cfffdfb000 (fee00000)
(XEN) mapped IOAPIC to ffff82cfffdfa000 (fec00000)
(XEN) IRQ limits: 24 GSI, 1144 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2800.164 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) alt table ffff82d0802d7fd0 -> ffff82d0802d8ff0
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 09
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-09
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB.
(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 not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping disabled
(XEN) Getting VERSION: 1060015
(XEN) Getting VERSION: 1060015
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) Getting ID: 0
(XEN) Getting LVT0: 700
(XEN) Getting LVT1: 400
(XEN) Suppress EOI broadcast on CPU#0
(XEN) enabled ExtINT on CPU#0
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) init IO_APIC IRQs
(XEN)  IO-APIC (apicid-pin) 1-0, 1-16, 1-17, 1-18, 1-19, 1-20, 1-21, 
1-22, 1-23 not connected.
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) number of MP IRQ sources: 15.
(XEN) number of IO-APIC #1 registers: 24.
(XEN) testing the IO APIC.......................
(XEN) IO APIC #1......
(XEN) .... register #00: 01000000
(XEN) .......    : physical APIC id: 01
(XEN) .......    : Delivery Type: 0
(XEN) .......    : LTS          : 0
(XEN) .... register #01: 00170020
(XEN) .......     : max redirection entries: 0017
(XEN) .......     : PRQ implemented: 0
(XEN) .......     : IO APIC version: 0020
(XEN) .... IRQ redirection table:
(XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
(XEN)  00 000 00  1    0    0   0   0    0    0    00
(XEN)  01 001 01  0    0    0   0   0    1    1    30
(XEN)  02 001 01  0    0    0   0   0    1    1    F0
(XEN)  03 001 01  0    0    0   0   0    1    1    38
(XEN)  04 001 01  0    0    0   0   0    1    1    F1
(XEN)  05 001 01  0    0    0   0   0    1    1    40
(XEN)  06 001 01  0    0    0   0   0    1    1    48
(XEN)  07 001 01  0    0    0   0   0    1    1    50
(XEN)  08 001 01  0    0    0   0   0    1    1    58
(XEN)  09 001 01  1    1    0   0   0    1    1    60
(XEN)  0a 001 01  0    0    0   0   0    1    1    68
(XEN)  0b 001 01  0    0    0   0   0    1    1    70
(XEN)  0c 001 01  0    0    0   0   0    1    1    78
(XEN)  0d 001 01  0    0    0   0   0    1    1    88
(XEN)  0e 001 01  0    0    0   0   0    1    1    90
(XEN)  0f 001 01  0    0    0   0   0    1    1    98
(XEN)  10 000 00  1    0    0   0   0    0    0    00
(XEN)  11 000 00  1    0    0   0   0    0    0    00
(XEN)  12 000 00  1    0    0   0   0    0    0    00
(XEN)  13 000 00  1    0    0   0   0    0    0    00
(XEN)  14 000 00  1    0    0   0   0    0    0    00
(XEN)  15 000 00  1    0    0   0   0    0    0    00
(XEN)  16 000 00  1    0    0   0   0    0    0    00
(XEN)  17 000 00  1    0    0   0   0    0    0    00
(XEN) Using vector-based indexing
(XEN) IRQ to pin mappings:
(XEN) IRQ240 -> 0:2
(XEN) IRQ48 -> 0:1
(XEN) IRQ56 -> 0:3
(XEN) IRQ241 -> 0:4
(XEN) IRQ64 -> 0:5
(XEN) IRQ72 -> 0:6
(XEN) IRQ80 -> 0:7
(XEN) IRQ88 -> 0:8
(XEN) IRQ96 -> 0:9
(XEN) IRQ104 -> 0:10
(XEN) IRQ112 -> 0:11
(XEN) IRQ120 -> 0:12
(XEN) IRQ136 -> 0:13
(XEN) IRQ144 -> 0:14
(XEN) IRQ152 -> 0:15
(XEN) .................................... done.
(XEN) Using local APIC timer interrupts.
(XEN) calibrating APIC timer ...
(XEN) ..... CPU clock speed is 2800.1136 MHz.
(XEN) ..... host bus clock speed is 133.3387 MHz.
(XEN) ..... bus_scale = 0x888d
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 64 KiB.
(XEN) mwait-idle: disabled
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Suppress EOI broadcast on CPU#1
(XEN) masked ExtINT on CPU#1
(XEN) Suppress EOI broadcast on CPU#2
(XEN) masked ExtINT on CPU#2
(XEN) Suppress EOI broadcast on CPU#3
(XEN) masked ExtINT on CPU#3
(XEN) Suppress EOI broadcast on CPU#4
(XEN) masked ExtINT on CPU#4
(XEN) Suppress EOI broadcast on CPU#5
(XEN) masked ExtINT on CPU#5
(XEN) Brought up 6 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x7c8000
(XEN) elf_parse_binary: phdr: paddr=0x1800000 memsz=0xed000
(XEN) elf_parse_binary: phdr: paddr=0x18ed000 memsz=0x14f40
(XEN) elf_parse_binary: phdr: paddr=0x1902000 memsz=0x614000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x1f16000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff819021f0
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = 
"!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
(XEN) elf_xen_parse_note: SUPPORTED_FEATURES = 0x90d
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff81f16000
(XEN)     virt_entry       = 0xffffffff819021f0
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f16000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c00000000->0000000c10000000 (12316667 pages 
to be allocated)
(XEN)  Init. ramdisk: 0000000c3f0da000->0000000c3ffff86e
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81f16000
(XEN)  Init. ramdisk: ffffffff81f16000->ffffffff82e3b86e
(XEN)  Phys-Mach map: ffffffff82e3c000->ffffffff88cbb908
(XEN)  Start info:    ffffffff88cbc000->ffffffff88cbc4b4
(XEN)  Page tables:   ffffffff88cbd000->ffffffff88d08000
(XEN)  Boot stack:    ffffffff88d08000->ffffffff88d09000
(XEN)  TOTAL:         ffffffff80000000->ffffffff89000000
(XEN)  ENTRY ADDRESS: ffffffff819021f0
(XEN) Dom0 has maximum 6 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff817c8000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81800000 -> 0xffffffff818ed000
(XEN) elf_load_binary: phdr 2 at 0xffffffff818ed000 -> 0xffffffff81901f40
(XEN) elf_load_binary: phdr 3 at 0xffffffff81902000 -> 0xffffffff81a1f000
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:00:00.0 map
(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:14.0
(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:14.1
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:14.2
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.1
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.2
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.3
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.4
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.5
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.6
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.7
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1a.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1a.1
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1a.7
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:1b.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1d.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1d.1
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1d.2
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1d.3
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1d.7
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1f.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1f.2
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1f.3
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:01:00.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:02:00.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:05:00.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:09:00.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:0a:0e.0
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:00.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:00.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.2 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.3 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.4 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.5 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:03.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:03.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:03.2 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:03.4 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:04.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:04.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:04.2 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:04.3 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:05.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:05.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:05.2 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:05.3 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:06.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:06.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:06.2 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:06.3 map
(XEN) [VT-D]iommu.c:739: iommu_enable_translation: iommu->reg = 
ffff82c000201000
(XEN) Scrubbing Free RAM on 1 nodes using 6 CPUs
(XEN) 
..................................................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch 
input to Xen)
(XEN) Freed 296kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.16-3-amd64 
(debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-12) ) 
#1 SMP Debian 3.16.5-1 (2014-10-10)
[    0.000000] Command line: placeholder 
root=/dev/mapper/vg_g2-lv_g2_root ro console=hvc0 earlyprintk=serial 
xencons=hvc debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 
LOGLEVEL=8 sched_debug
[    0.000000] Freeing 9d-100 pfn range: 99 pages freed
[    0.000000] Freeing bf7a0-100000 pfn range: 264288 pages freed
[    0.000000] Released 264387 pages of unused memory
[    0.000000] Set 264387 page(s) to 1-1 mapping
[    0.000000] Populating bcff21-c107e4 pfn range: 264387 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
[    0.000000] Xen: [mem 0x000000000009d000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000bf79ffff] usable
[    0.000000] Xen: [mem 0x00000000bf7a0000-0x00000000bf7c9fff] ACPI data
[    0.000000] Xen: [mem 0x00000000bf7ca000-0x00000000bf7cbfff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000bf7cc000-0x00000000bfffffff] reserved
[    0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] Xen: [mem 0x00000000fe710000-0x00000000fe710fff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved
[    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000c3fffffff] usable
[    0.000000] bootconsole [earlyser0] enabled
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.6 present.
[    0.000000] DMI: LENOVO 4158WRG/LENOVO, BIOS 61KT50AUS 01/14/2014
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] AGP: No AGP bridge found
[    0.000000] e820: last_pfn = 0xc40000 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xbf7a0 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] init_memory_mapping: [mem 0xc10400000-0xc105fffff]
[    0.000000]  [mem 0xc10400000-0xc105fffff] page 4k
[    0.000000] BRK [0x01b61000, 0x01b61fff] PGTABLE
[    0.000000] BRK [0x01b62000, 0x01b62fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0xc10000000-0xc103fffff]
[    0.000000]  [mem 0xc10000000-0xc103fffff] page 4k
[    0.000000] BRK [0x01b63000, 0x01b63fff] PGTABLE
[    0.000000] BRK [0x01b64000, 0x01b64fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0xc00000000-0xc0fffffff]
[    0.000000]  [mem 0xc00000000-0xc0fffffff] page 4k
[    0.000000] BRK [0x01b65000, 0x01b65fff] PGTABLE
[    0.000000] BRK [0x01b66000, 0x01b66fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x00100000-0xbf79ffff]
[    0.000000]  [mem 0x00100000-0xbf79ffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x100000000-0xbffffffff]
[    0.000000]  [mem 0x100000000-0xbffffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0xc10600000-0xc3fffffff]
[    0.000000]  [mem 0xc10600000-0xc3fffffff] page 4k
[    0.000000] log_buf_len: 16777216
[    0.000000] early log buf free: 127296(97%)
[    0.000000] RAMDISK: [mem 0x01f16000-0x02e3bfff]
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000000F6A40 000024 (v02 PTLTD )
[    0.000000] ACPI: XSDT 0x00000000BF7BF38F 000084 (v01 LENOVO TC-61    
060400D0  LTP 00000000)
[    0.000000] ACPI: FACP 0x00000000BF7C98D1 0000F4 (v03 LENOVO TC-61    
060400D0 PTL  00000002)
[    0.000000] ACPI: DSDT 0x00000000BF7BF413 00A43A (v01 LENOVO TC-61    
060400D0 MSFT 0100000E)
[    0.000000] ACPI: FACS 0x00000000BF7CBFC0 000040
[    0.000000] ACPI: SSDT 0x00000000BF7AF33B 002694 (v01 INTEL  PPM RCM  
80000001 INTL 20061109)
[    0.000000] ACPI: SLIT 0x00000000BF7C99E9 000030 (v01 Intel TYLERBRG 
060400D0 LOHR 0000005A)
[    0.000000] ACPI: TCPA 0x00000000BF7C9A19 000032 (v01 LENOVO TC-61    
060400D0 PTL  00000000)
[    0.000000] ACPI: SLIC 0x00000000BF7C9A4B 000176 (v01 LENOVO TC-61    
060400D0  LTP 00000000)
[    0.000000] ACPI: SRAT 0x00000000BF7C9BC1 0000E0 (v01 Intel Tylerbrg 
060400D0 PHX. 00000001)
[    0.000000] ACPI: XMAR 0x00000000BF7C9CA1 0001C0 (v01 Intel OEMDMAR  
060400D0 LOHR 00000001)
[    0.000000] ACPI: APIC 0x00000000BF7C9E61 0000A0 (v01 PTLTD  ? APIC   
060400D0  LTP 00000000)
[    0.000000] ACPI: MCFG 0x00000000BF7C9F01 00003C (v01 PTLTD MCFG   
060400D0  LTP 00000000)
[    0.000000] ACPI: HPET 0x00000000BF7C9F3D 000038 (v01 PTLTD HPETTBL  
060400D0  LTP 00000001)
[    0.000000] ACPI: BOOT 0x00000000BF7C9F75 000028 (v01 PTLTD $SBFTBL$ 
060400D0  LTP 00000001)
[    0.000000] ACPI: ASF! 0x00000000BF7C9F9D 000063 (v32 LENOVO TC-61    
060400D0 PTL  00000001)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000c3fffffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0xc3fffffff]
[    0.000000]   NODE_DATA [mem 0xc107df000-0xc107e3fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0xc3fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009cfff]
[    0.000000]   node   0: [mem 0x00100000-0xbf79ffff]
[    0.000000]   node   0: [mem 0x100000000-0xc3fffffff]
[    0.000000] On node 0 totalpages: 12580668
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 21 pages reserved
[    0.000000]   DMA zone: 3996 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 10667 pages used for memmap
[    0.000000]   DMA32 zone: 780192 pages, LIFO batch:31
[    0.000000]   Normal zone: 161280 pages used for memmap
[    0.000000]   Normal zone: 11796480 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 
0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[    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: 0x8086a301 base: 0xfed00000
[    0.000000] smpboot: Allowing 6 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 40
[    0.000000] PM: Registered nosave memory: [mem 0x0009d000-0x000fffff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7a0000-0xbf7c9fff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7ca000-0xbf7cbfff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7cc000-0xbfffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xc0000000-0xf7ffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xf8000000-0xfbffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfc000000-0xfe70ffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfe710000-0xfe710fff]
[    0.000000] PM: Registered nosave memory: [mem 0xfe711000-0xfebfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfec0ffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfec10000-0xfedfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfeefffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfef00000-0xfeffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xff000000-0xffffffff]
[    0.000000] e820: [mem 0xc0000000-0xf7ffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.5.0-rc (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 
nr_cpu_ids:6 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880c03400000 s85824 
r8192 d20672 u262144
[    0.000000] pcpu-alloc: s85824 r8192 d20672 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 - -
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  
Total pages: 12408644
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: placeholder 
root=/dev/mapper/vg_g2-lv_g2_root ro console=hvc0 earlyprintk=serial 
xencons=hvc debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 
LOGLEVEL=8 sched_debug
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] software IO TLB [mem 0xbd4e00000-0xbd8e00000] (64MB) 
mapped at [ffff880bd4e00000-ffff880bd8dfffff]
[    0.000000] Memory: 48548940K/50322672K available (5189K kernel code, 
942K rwdata, 1824K rodata, 1200K init, 840K bss, 1773732K reserved)
[    0.000000] Hierarchical RCU implementation.
[    0.000000]     RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000]     RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=6.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6
[    0.000000] NR_IRQS:33024 nr_irqs:728 16
[    0.000000] xen:events: Using FIFO-based ABI
[    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)
(XEN) IOAPIC[0]: Set PCI routing entry (1-9 -> 0x60 -> IRQ 9 Mode:1 
Active:0)
[    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: --> 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 [hvc0] enabled

[    0.000000] console [hvc0] enabled
[    0.000000] bootconsole [earlyser0] disabled

[    0.000000] bootconsole [earlyser0] disabled
[    0.000000] bootconsole [xenboot0] disabled

[    0.000000] bootconsole [xenboot0] disabled
[    0.000000] Xen: using vcpuop timer interface

[    0.000000] installing Xen timer for CPU 0

[    0.000000] tsc: Detected 2800.164 MHz processor

[   11.929093] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 5600.32 BogoMIPS (lpj=11200656)

[   11.929098] pid_max: default: 32768 minimum: 301

[   11.929107] ACPI: Core revision 20140424

[   11.933681] ACPI: All ACPI Tables successfully acquired

[   11.940307] Security Framework initialized

[   11.940317] AppArmor: AppArmor disabled by boot time parameter

[   11.940320] Yama: disabled by default; enable with sysctl kernel.yama.*

[   11.948791] Dentry cache hash table entries: 8388608 (order: 14, 
67108864 bytes)

[   11.962761] Inode-cache hash table entries: 4194304 (order: 13, 
33554432 bytes)

[   11.967450] Mount-cache hash table entries: 131072 (order: 8, 1048576 
bytes)

[   11.967602] Mountpoint-cache hash table entries: 131072 (order: 8, 
1048576 bytes)

[   11.968060] Initializing cgroup subsys memory

[   11.968066] Initializing cgroup subsys devices

[   11.968073] Initializing cgroup subsys freezer

[   11.968077] Initializing cgroup subsys net_cls

[   11.968082] Initializing cgroup subsys blkio

[   11.968086] Initializing cgroup subsys perf_event

[   11.968089] Initializing cgroup subsys net_prio

[   11.968142] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'

[   11.968142] ENERGY_PERF_BIAS: View and update with 
x86_energy_perf_policy(8)

[   11.968171] CPU: Physical Processor ID: 0

[   11.968173] CPU: Processor Core ID: 0

[   11.968176] mce: CPU supports 2 MCE banks

[   11.968191] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7

[   11.968191] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0

[   11.968191] tlb_flushall_shift: 6

[   11.968257] Freeing SMP alternatives memory: 20K (ffffffff81a19000 - 
ffffffff81a1e000)

[   11.969139] ftrace: allocating 21546 entries in 85 pages

[   11.976086] Performance Events: unsupported p6 CPU model 44 no PMU 
driver, software events only.

[   11.977204] NMI watchdog: disabled (cpu0): hardware events not enabled

[   11.977282] installing Xen timer for CPU 1

[   11.977528] installing Xen timer for CPU 2

[   11.977726] installing Xen timer for CPU 3

[   11.977921] installing Xen timer for CPU 4

[   11.978123] installing Xen timer for CPU 5

[   11.978244] x86: Booted up 1 node, 6 CPUs

[   11.978264] CPU0 attaching sched-domain:

[   11.978267]  domain 0: span 0-5 level MC

[   11.978269]   groups: 0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 
2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 
5 (cpu_capacity = 1023)

[   11.978281] CPU1 attaching sched-domain:

[   11.978283]  domain 0: span 0-5 level MC

[   11.978285]   groups: 1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 
3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 
0 (cpu_capacity = 1023)

[   11.978296] CPU2 attaching sched-domain:

[   11.978298]  domain 0: span 0-5 level MC

[   11.978300]   groups: 2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 
4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 
1 (cpu_capacity = 1023)

[   11.978310] CPU3 attaching sched-domain:

[   11.978312]  domain 0: span 0-5 level MC

[   11.978314]   groups: 3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 
5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 
2 (cpu_capacity = 1023)

[   11.978324] CPU4 attaching sched-domain:

[   11.978326]  domain 0: span 0-5 level MC

[   11.978328]   groups: 4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 
0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 
3 (cpu_capacity = 1023)

[   11.978339] CPU5 attaching sched-domain:

[   11.978341]  domain 0: span 0-5 level MC

[   11.978343]   groups: 5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 
1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 
4 (cpu_capacity = 1023)

[   11.978524] devtmpfs: initialized

[   11.984790] PM: Registering ACPI NVS region [mem 
0xbf7ca000-0xbf7cbfff] (8192 bytes)

[   11.985592] pinctrl core: initialized pinctrl subsystem

[   11.985667] NET: Registered protocol family 16

[   11.985679] xen:grant_table: Grant tables using version 1 layout

[   11.985690] Grant table initialized

[   11.985944] ACPI FADT declares the system doesn't support PCIe ASPM, 
so disable it

[   11.985949] ACPI: bus type PCI registered

[   11.985951] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5

[   11.986130] PCI: MMCONFIG for domain 0000 [bus 00-09] at [mem 
0xf8000000-0xf89fffff] (base 0xf8000000)

[   11.986135] PCI: MMCONFIG at [mem 0xf8000000-0xf89fffff] reserved in E820

[   11.987060] PCI: Using configuration type 1 for base access

[   11.996829] ACPI: Added _OSI(Module Device)

[   11.996852] ACPI: Added _OSI(Processor Device)

[   11.996854] ACPI: Added _OSI(3.0 _SCP Extensions)

[   11.996856] ACPI: Added _OSI(Processor Aggregator Device)

[   11.999982] ACPI: Interpreter enabled

[   11.999989] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep 
State [\_S1_] (20140424/hwxface-580)

[   11.999994] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep 
State [\_S2_] (20140424/hwxface-580)

[   12.000006] ACPI: (supports S0 S3 S4 S5)

[   12.000008] ACPI: Using IOAPIC for interrupt routing

[   12.000032] PCI: Using host bridge windows from ACPI; if necessary, 
use "pci=nocrs" and report a bug

[   12.013771] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])

[   12.013779] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM 
ClockPM Segments MSI]

[   12.013998] acpi PNP0A03:00: _OSC: OS now controls [PCIeHotplug PME 
AER PCIeCapability]

[   12.014671] acpi PNP0A03:00: [Firmware Info]: MMCONFIG for domain 
0000 [bus 00-09] only partially covers this bridge

[   12.014847] PCI host bridge to bus 0000:00

[   12.014851] pci_bus 0000:00: root bus resource [bus 00-ff]

[   12.014878] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7]

[   12.014881] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff]

[   12.014884] pci_bus 0000:00: root bus resource [mem 
0x000a0000-0x000bffff]

[   12.014887] pci_bus 0000:00: root bus resource [mem 
0x000d0000-0x000d3fff]

[   12.014890] pci_bus 0000:00: root bus resource [mem 
0x000d4000-0x000d7fff]

[   12.014893] pci_bus 0000:00: root bus resource [mem 
0x000d8000-0x000dbfff]

[   12.014896] pci_bus 0000:00: root bus resource [mem 
0x000dc000-0x000dffff]

[   12.014899] pci_bus 0000:00: root bus resource [mem 
0xc0000000-0xfdffffff]

[   12.014918] pci 0000:00:00.0: [8086:3406] type 00 class 0x060000

[   12.015018] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold

(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) PCI add device 0000:00:00.0
[   12.015131] pci 0000:00:01.0: [8086:3408] type 01 class 0x060400

[   12.015239] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold

[   12.015288] pci 0000:00:01.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) PCI add device 0000:00:01.0
[   12.015356] pci 0000:00:03.0: [8086:340a] type 01 class 0x060400

[   12.015464] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold

[   12.015513] pci 0000:00:03.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) PCI add device 0000:00:03.0
[   12.015583] pci 0000:00:07.0: [8086:340e] type 01 class 0x060400

[   12.015682] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold

[   12.015733] pci 0000:00:07.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) PCI add device 0000:00:07.0
[   12.015807] pci 0000:00:14.0: [8086:342e] type 00 class 0x080000

(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) PCI add device 0000:00:14.0
[   12.015968] pci 0000:00:14.1: [8086:3422] type 00 class 0x080000

(XEN) PCI add device 0000:00:14.1
[   12.016122] pci 0000:00:14.2: [8086:3423] type 00 class 0x080000

(XEN) PCI add device 0000:00:14.2
[   12.016294] pci 0000:00:16.0: [8086:3430] type 00 class 0x088000

[   12.016316] pci 0000:00:16.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.0
[   12.016480] pci 0000:00:16.1: [8086:3431] type 00 class 0x088000

[   12.016502] pci 0000:00:16.1: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.1
[   12.016667] pci 0000:00:16.2: [8086:3432] type 00 class 0x088000

[   12.016688] pci 0000:00:16.2: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.2
[   12.016853] pci 0000:00:16.3: [8086:3433] type 00 class 0x088000

[   12.016874] pci 0000:00:16.3: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.3
[   12.017039] pci 0000:00:16.4: [8086:3429] type 00 class 0x088000

[   12.017060] pci 0000:00:16.4: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.4
[   12.017226] pci 0000:00:16.5: [8086:342a] type 00 class 0x088000

[   12.017247] pci 0000:00:16.5: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.5
[   12.017411] pci 0000:00:16.6: [8086:342b] type 00 class 0x088000

[   12.017433] pci 0000:00:16.6: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.6
[   12.017597] pci 0000:00:16.7: [8086:342c] type 00 class 0x088000

[   12.017618] pci 0000:00:16.7: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.7
[   12.017784] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c0300

[   12.017854] pci 0000:00:1a.0: reg 0x20: [io  0x1800-0x181f]

[   12.017963] pci 0000:00:1a.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.0
[   12.018018] pci 0000:00:1a.1: [8086:3a38] type 00 class 0x0c0300

[   12.018088] pci 0000:00:1a.1: reg 0x20: [io  0x1820-0x183f]

[   12.018207] pci 0000:00:1a.1: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.1
[   12.018277] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0320

[   12.018311] pci 0000:00:1a.7: reg 0x10: [mem 0xec604000-0xec6043ff]

[   12.018451] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold

[   12.018498] pci 0000:00:1a.7: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.7
[   12.018558] pci 0000:00:1b.0: [8086:3a3e] type 00 class 0x040300

[   12.018585] pci 0000:00:1b.0: reg 0x10: [mem 0xec600000-0xec603fff 64bit]

[   12.018704] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold

(XEN) PCI add device 0000:00:1b.0
[   12.018798] pci 0000:00:1c.0: [8086:3a40] type 01 class 0x060400

[   12.018912] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold

[   12.018962] pci 0000:00:1c.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.0
[   12.019022] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x060400

[   12.019158] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold

[   12.019209] pci 0000:00:1c.4: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.4
[   12.019263] pci 0000:00:1c.5: [8086:3a4a] type 01 class 0x060400

[   12.019385] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold

[   12.019436] pci 0000:00:1c.5: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.5
[   12.019493] pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300

[   12.019562] pci 0000:00:1d.0: reg 0x20: [io  0x1840-0x185f]

[   12.019670] pci 0000:00:1d.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.0
[   12.019724] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300

[   12.019794] pci 0000:00:1d.1: reg 0x20: [io  0x1860-0x187f]

[   12.019902] pci 0000:00:1d.1: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.1
[   12.019960] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300

[   12.020055] pci 0000:00:1d.2: reg 0x20: [io  0x1880-0x189f]

[   12.020185] pci 0000:00:1d.2: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.2
[   12.020243] pci 0000:00:1d.3: [8086:3a39] type 00 class 0x0c0300

[   12.020313] pci 0000:00:1d.3: reg 0x20: [io  0x18a0-0x18bf]

[   12.020422] pci 0000:00:1d.3: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.3
[   12.020490] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320

[   12.020524] pci 0000:00:1d.7: reg 0x10: [mem 0xec605000-0xec6053ff]

[   12.020664] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold

[   12.020711] pci 0000:00:1d.7: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.7
[   12.020764] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401

[   12.020878] pci 0000:00:1e.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1e.0
[   12.020932] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x060100

(XEN) PCI add device 0000:00:1f.0
[   12.021167] pci 0000:00:1f.2: [8086:3a22] type 00 class 0x010601

[   12.021199] pci 0000:00:1f.2: reg 0x10: [io  0x18f0-0x18f7]

[   12.021212] pci 0000:00:1f.2: reg 0x14: [io  0x18e4-0x18e7]

[   12.021225] pci 0000:00:1f.2: reg 0x18: [io  0x18e8-0x18ef]

[   12.021238] pci 0000:00:1f.2: reg 0x1c: [io  0x18e0-0x18e3]

[   12.021252] pci 0000:00:1f.2: reg 0x20: [io  0x18c0-0x18df]

[   12.021265] pci 0000:00:1f.2: reg 0x24: [mem 0xec606000-0xec6067ff]

[   12.021343] pci 0000:00:1f.2: PME# supported from D3hot

(XEN) PCI add device 0000:00:1f.2
[   12.021433] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500

[   12.021459] pci 0000:00:1f.3: reg 0x10: [mem 0xec607000-0xec6070ff 64bit]

[   12.021494] pci 0000:00:1f.3: reg 0x20: [io  0x1100-0x111f]

(XEN) PCI add device 0000:00:1f.3
[   12.021686] pci 0000:01:00.0: [11ab:6485] type 00 class 0x010400

[   12.021730] pci 0000:01:00.0: reg 0x18: [io  0x2000-0x207f]

[   12.021761] pci 0000:01:00.0: reg 0x20: [mem 0xec000000-0xec00ffff 64bit]

[   12.021776] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0003ffff pref]

[   12.021839] pci 0000:01:00.0: supports D1

[   12.021842] pci 0000:01:00.0: PME# supported from D0 D1 D3hot

[   12.021874] pci 0000:01:00.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:01:00.0
[   12.132501] pci 0000:00:01.0: PCI bridge to [bus 01]

[   12.132513] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]

[   12.132523] pci 0000:00:01.0:   bridge window [mem 0xec000000-0xec0fffff]

[   12.132640] pci 0000:02:00.0: [10de:05fe] type 00 class 0x030000

[   12[   12.916581] tg3 0000:05:00.0: no hotplug settings from platform

[   12.916719] pci_bus 0000:07: Allocating resources

[   12.916778] pcieport 0000:06:00.0: bridge window [io 0x1000-0x0fff] 
to [bus 07-09] add_size 1000

[   12.916783] pcieport 0000:06:00.0: bridge window [mem 
0x00100000-0x000fffff 64bit pref] to [bus 07-09] add_size 200000

[   12.916788] pcieport 0000:06:00.0: res[15]=[mem 0x00100000-0x000fffff 
64bit pref] get_res_add_size add_size 200000

[   12.916793] pcieport 0000:06:00.0: res[13]=[io  0x1000-0x0fff] 
get_res_add_size add_size 1000

[   12.916799] pcieport 0000:06:00.0: BAR 15: assigned [mem 
0xc0600000-0xc07fffff 64bit pref]

[   12.916802] pcieport 0000:06:00.0: BAR 13: assigned [io 0x7000-0x7fff]

[   12.916825] pcieport 0000:06:00.0: no hotplug settings from platform

[   12.916848] pcieport 0000:07:02.0: no hotplug settings from platform

[   12.916870] pcieport 0000:07:03.0: no hotplug settings from platform

[   12.916885] tg3 0000:09:00.0: no hotplug settings from platform

[   13.000128] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

[   13.000151] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[   13.000172] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[   13.003705] ata2.00: ATAPI: HL-DT-STDVD-RAM GH60N, NY02, max UDMA/100

[   13.006112] ata1.00: ATA-8: WDC WD3000BLFS-08YBU0, 04.04V04, max UDMA/100

[   13.006119] ata1.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 
31/32), AA

[   13.006464] ata3.00: ATA-8: WDC WD3000BLFS-08YBU0, 04.04V04, max UDMA/100

[   13.006471] ata3.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 
31/32), AA

[   13.008025] ata2.00: configured for UDMA/100

[   13.012115] ata1.00: configured for UDMA/100

[   13.012249] scsi 1:0:0:0: Direct-Access     ATA      WDC WD3000BLFS-0 
4V04 PQ: 0 ANSI: 5

[   13.013518] ata3.00: configured for UDMA/100

[   13.015809] scsi 2:0:0:0: CD-ROM            HL-DT-ST DVD-RAM GH60N    
NY02 PQ: 0 ANSI: 5

[   13.025883] scsi 3:0:0:0: Direct-Access     ATA      WDC WD3000BLFS-0 
4V04 PQ: 0 ANSI: 5

[   13.028500] sd 1:0:0:0: [sda] 586072368 512-byte logical blocks: (300 
GB/279 GiB)

[   13.028604] sd 1:0:0:0: [sda] Write Protect is off

[   13.028609] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00

[   13.028651] sd 1:0:0:0: [sda] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA

[   13.031377] sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw 
xa/form2 cdda tray

[   13.031386] cdrom: Uniform CD-ROM driver Revision: 3.20

[   13.031517] sr 2:0:0:0: Attached scsi CD-ROM sr0

[   13.031631] sd 3:0:0:0: [sdb] 586072368 512-byte logical blocks: (300 
GB/279 GiB)

[   13.031724] sd 3:0:0:0: [sdb] Write Protect is off

[   13.031728] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00

[   13.031768] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA

[   13.032021] sd 1:0:0:0: Attached scsi generic sg0 type 0

[   13.032079] sr 2:0:0:0: Attached scsi generic sg1 type 5

[   13.032124] sd 3:0:0:0: Attached scsi generic sg2 type 0

[   13.037844]  sda: sda1 sda2

[   13.038211] sd 1:0:0:0: [sda] Attached SCSI disk

[   13.043673]  sdb: sdb1 sdb2

[   13.043983] sd 3:0:0:0: [sdb] Attached SCSI disk

[   13.121238] md: bind<sdb2>

[   13.122241] md: bind<sda1>

[   13.132958] md: bind<sda2>

[   13.135006] md: raid1 personality registered for level 1

[   13.135363] md/raid1:md1: active with 2 out of 2 mirrors

[   13.135437] created bitmap (3 pages) for device md1

[   13.135600] md1: bitmap initialized from disk: read 1 pages, set 0 of 
4462 bits

[   13.140431] md1: detected capacity change from 0 to 299396562944

[   13.143731]  md1: unknown partition table

[   13.152229] md: bind<sdb1>

[   13.154307] md/raid1:md0: active with 2 out of 2 mirrors

[   13.154327] md0: detected capacity change from 0 to 536805376

[   13.160470]  md0: unknown partition table

[   13.232470] usb 1-4: New USB device found, idVendor=0bda, idProduct=0181

[   13.232480] usb 1-4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[   13.232486] usb 1-4: Product: USB2.0-CRW

[   13.232491] usb 1-4: Manufacturer: Generic

[   13.232495] usb 1-4: SerialNumber: 20060413092100000

[   13.239350] usb-storage 1-4:1.0: USB Mass Storage device detected

[   13.239478] scsi7 : usb-storage 1-4:1.0

[   13.239535] usbcore: registered new interface driver usb-storage

[   13.532137] usb 7-2: new low-speed USB device number 2 using uhci_hcd

[   13.923165] usb 7-2: New USB device found, idVendor=17ef, idProduct=6009

[   13.923174] usb 7-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0

[   13.923181] usb 7-2: Product: ThinkPad USB Keyboard with TrackPoint

[   13.923186] usb 7-2: Manufacturer: Lite-On Technology Corp.

[   13.927205] hidraw: raw HID events driver (C) Jiri Kosina

[   13.972212] usbcore: registered new interface driver usbhid

[   13.972215] usbhid: USB HID core driver

[   13.972906] input: Lite-On Technology Corp. ThinkPad USB Keyboard 
with TrackPoint as 
/devices/pci0000:00/0000:00:1d.2/usb7/7-2/7-2:1.0/0003:17EF:6009.0001/input/input2

[   13.972969] lenovo_tpkbd 0003:17EF:6009.0001: input,hidraw0: USB HID 
v1.10 Keyboard [Lite-On Technology Corp. ThinkPad USB Keyboard with 
TrackPoint] on usb-0000:00:1d.2-2/input0

[   13.990235] input: Lite-On Technology Corp. ThinkPad USB Keyboard 
with TrackPoint as 
/devices/pci0000:00/0000:00:1d.2/usb7/7-2/7-2:1.1/0003:17EF:6009.0002/input/input3

[   13.990392] lenovo_tpkbd 0003:17EF:6009.0002: input,hiddev0,hidraw1: 
USB HID v1.10 Mouse [Lite-On Technology Corp. ThinkPad USB Keyboard with 
TrackPoint] on usb-0000:00:1d.2-2/input1

[   14.239376] scsi 7:0:0:0: Direct-Access     Generic- Compact Flash    
1.00 PQ: 0 ANSI: 0 CCS

[   14.242371] scsi 7:0:0:1: Direct-Access     Generic- SM/xD-Picture    
1.00 PQ: 0 ANSI: 0 CCS

[   14.245371] scsi 7:0:0:2: Direct-Access     Generic- SD/MMC           
1.00 PQ: 0 ANSI: 0 CCS

[   14.248495] scsi 7:0:0:3: Direct-Access     Generic- MS/MS-Pro/HG     
1.00 PQ: 0 ANSI: 0 CCS

[   14.248736] sd 7:0:0:0: Attached scsi generic sg3 type 0

[   14.248893] sd 7:0:0:1: Attached scsi generic sg4 type 0

[   14.249071] sd 7:0:0:2: Attached scsi generic sg5 type 0

[   14.249291] sd 7:0:0:3: Attached scsi generic sg6 type 0

[   14.340337] random: nonblocking pool is initialized

[   14.362979] sd 7:0:0:0: [sdc] Attached SCSI removable disk

[   14.365478] sd 7:0:0:1: [sdd] Attached SCSI removable disk

[   14.368123] sd 7:0:0:2: [sde] Attached SCSI removable disk

[   14.370608] sd 7:0:0:3: [sdf] Attached SCSI removable disk

[   17.556123] scsi0 : mvsas

[   21.183838] device-mapper: uevent: version 1.0.3

[   21.183918] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) 
initialised: dm-devel@redhat.com

[   21.448437] PM: Starting manual resume from disk

[   21.448452] PM: Hibernation image partition 253:1 present

[   21.448455] PM: Looking for hibernation image.

[   21.448623] PM: Image not found (code -22)

[   21.448634] PM: Hibernation image not present or could not be loaded.

[   21.467950] EXT4-fs (dm-0): mounted filesystem with ordered data 
mode. Opts: (null)


INIT: version 2.88 booting


[info] Using makefile-style concurrent boot in runlevel S.

calling: info

[....] Starting the hotplug events dispatcher: udevd[   22.384236] 
systemd-udevd[387]: starting version 215

[?25l[?1c7[ ok 8[?25h[?0c.

[....] Synthesizing the initial hotplug events...calling: trigger

[?25l[?1c7[ ok 8[?25h[?0cdone.

[....] Waiting for /dev to be fully populated...calling: settle

[   22.771824] dca service started, version 1.12.1

[   22.787412] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4

[   22.793212] Monitor-Mwait will be used to enter C-1 state

[   22.793243] Monitor-Mwait will be used to enter C-3 state

[   22.793262] Monitor-Mwait will be used to enter C-3 state

[   22.796020] Warning: Processor Platform Limit not supported.

[   22.798559] EDAC MC: Ver: 3.0.0

[   22.819933] ioatdma: Intel(R) QuickData Technology Driver 4.00

[   22.819978] ioatdma 0000:00:16.0: enabling device (0000 -> 0002)

[   22.820180] ioatdma 0000:00:16.0: can't derive routing for PCI INT A

[   22.820184] ioatdma 0000:00:16.0: PCI INT A: no GSI

[   22.820398] ioatdma 0000:00:16.1: enabling device (0000 -> 0002)

[   22.820569] ioatdma 0000:00:16.1: can't derive routing for PCI INT B

[   22.820572] ioatdma 0000:00:16.1: PCI INT B: no GSI

[   22.820767] ioatdma 0000:00:16.2: enabling device (0000 -> 0002)

[   22.820938] ioatdma 0000:00:16.2: can't derive routing for PCI INT C

[   22.820941] ioatdma 0000:00:16.2: PCI INT C: no GSI

[   22.821127] ioatdma 0000:00:16.3: enabling device (0000 -> 0002)

[   22.821320] ioatdma 0000:00:16.3: can't derive routing for PCI INT D

[   22.821324] ioatdma 0000:00:16.3: PCI INT D: no GSI

[   22.821529] ioatdma 0000:00:16.4: enabling device (0000 -> 0002)

[   22.821700] ioatdma 0000:00:16.4: can't derive routing for PCI INT A

[   22.821704] ioatdma 0000:00:16.4: PCI INT A: no GSI

[   22.821891] ioatdma 0000:00:16.5: enabling device (0000 -> 0002)

[   22.822061] ioatdma 0000:00:16.5: can't derive routing for PCI INT B

[   22.822065] ioatdma 0000:00:16.5: PCI INT B: no GSI

[   22.822261] ioatdma 0000:00:16.6: enabling device (0000 -> 0002)

[   22.822432] ioatdma 0000:00:16.6: can't derive routing for PCI INT C

[   22.822435] ioatdma 0000:00:16.6: PCI INT C: no GSI

[   22.822621] ioatdma 0000:00:16.7: enabling device (0000 -> 0002)

[   22.822792] ioatdma 0000:00:16.7: can't derive routing for PCI INT D

[   22.822796] ioatdma 0000:00:16.7: PCI INT D: no GSI

[   22.829482] xen: registering gsi 16 triggering 0 polarity 1

[   22.829489] Already setup the GSI :16

[   22.830810] input: Power Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0C:00/input/input4

[   22.830818] ACPI: Power Button [PWRB]

[   22.830857] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5

[   22.830861] ACPI: Power Button [PWRF]

[   22.840696] wmi: Mapper loaded

[   22.844439] tpm_tis 00:00: 1.2 TPM (device-id 0x1002, rev-id 2)

[   22.908910] ACPI Warning: SystemIO range 
0x0000000000001028-0x000000000000102f conflicts with OpRegion 
0x0000000000001000-0x000000000000102f (\_SB_.PCI0.LPC0.PMIO) 
(20140424/utaddress-258)

[   22.908920] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   22.908927] ACPI Warning: SystemIO range 
0x00000000000011b0-0x00000000000011bf conflicts with OpRegion 
0x0000000000001180-0x00000000000011bf (\_SB_.PCI0.LPC0.GPOX) 
(20140424/utaddress-258)

[   22.908934] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   22.908937] ACPI Warning: SystemIO range 
0x0000000000001180-0x00000000000011af conflicts with OpRegion 
0x0000000000001180-0x00000000000011bf (\_SB_.PCI0.LPC0.GPOX) 
(20140424/utaddress-258)

[   22.908944] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   22.908947] lpc_ich: Resource conflict(s) found affecting gpio_ich

[   22.925327] xen: registering gsi 17 triggering 0 polarity 1

[   22.925334] Already setup the GSI :17

[   22.925356] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt

[   23.054556] SSE version of gcm_enc/dec engaged.

[   23.057659] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)

[   23.142657] alg: No test for crc32 (crc32-pclmul)

[   23.188538] iTCO_vendor_support: vendor-support=0

[   23.189004] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11

[   23.189039] iTCO_wdt: Found a ICH10 TCO device (Version=2, 
TCOBASE=0x1060)

[   23.189153] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

[   23.253301] sound hdaudioC0D2: autoconfig: line_outs=4 
(0x12/0x16/0x24/0x25/0x0) type:line

[   23.253315] sound hdaudioC0D2:    speaker_outs=1 (0x13/0x0/0x0/0x0/0x0)

[   23.253318] sound hdaudioC0D2:    hp_outs=1 (0x11/0x0/0x0/0x0/0x0)

[   23.253321] sound hdaudioC0D2:    mono: mono_out=0x0

[   23.253324] sound hdaudioC0D2:    dig-out=0x1b/0x0

[   23.253326] sound hdaudioC0D2:    inputs:

[   23.253329] sound hdaudioC0D2:      Front Mic=0x14

[   23.253332] sound hdaudioC0D2:      Rear Mic=0x17

[   23.253334] sound hdaudioC0D2:      Line=0x15

[   23.253336] sound hdaudioC0D2:    dig-in=0x1c

[   23.265840] input: HDA Digital PCBeep as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D2/input7

[   23.266180] input: HDA Intel Front Mic as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input8

[   23.266275] input: HDA Intel Rear Mic as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input9

[   23.266339] input: HDA Intel Line as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input10

[   23.266414] input: HDA Intel Line Out Front as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input11

[   23.266493] input: HDA Intel Line Out Surround as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input12

[   23.267432] input: HDA Intel Line Out CLFE as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input13

[   23.267659] input: HDA Intel Line Out Side as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input14

[   23.267728] input: HDA Intel Front Headphone as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input15

[   24.852132] tpm_tis 00:00: tpm_transmit: tpm_send: error -62

[   24.852148] tpm_tis 00:00: A TPM error (-62) occurred attempting to 
determine the timeouts

[   24.864212] tpm_tis 00:00: Adjusting TPM timeout parameters.

[   24.912148] tpm_tis 00:00: TPM is disabled/deactivated (0x6)

[?25l[?1c7[ ok 8[?25h[?0cdone.

[....] Setting parameters of disc: (none)[?25l[?1c7[ 
ok 8[?25h[?0c.


[....] Setting preliminary keymap...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[   25.517579] EXT4-fs (dm-0): re-mounted. Opts: (null)

[....] Checking root file system...fsck from util-linux 2.25.1


/dev/mapper/vg_g2-lv_g2_root: clean, 275985/1048576 files, 
3651430/4194304 blocks


[?25l[?1c7[ ok 8[?25h[?0cdone.


[   25.654371] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro

[   25.937101] xen_acpi_processor: Uploading Xen processor PM info

(XEN) cpu0 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) Monitor-Mwait will be used to enter C1 state
(XEN) Monitor-Mwait will be used to enter C3 state
(XEN) CPU0: 0000000000000000, default_idle+0/0x7b
(XEN) cpu1 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) CPU1: default_idle+0/0x7b, acpi_processor_idle+0/0x531
(XEN) cpu2 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) CPU2: default_idle+0/0x7b, acpi_processor_idle+0/0x531
(XEN) cpu3 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) CPU3: default_idle+0/0x7b, acpi_processor_idle+0/0x531
(XEN) cpu4 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) CPU4: default_idle+0/0x7b, acpi_processor_idle+0/0x531
(XEN) cpu5 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) CPU5: default_idle+0/0x7b, acpi_processor_idle+0/0x531
(XEN) cpu6 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) No CPU ID for APIC ID 0x6
(XEN) cpu7 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) cpu8 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) cpu9 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) cpu10 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
[   25.967008] xen_pciback: backend is vpci

[   25.990298] fuse init (API version 7.23)

[info] Loading kernel module xen-acpi-processor.


[info] Loading kernel module xen-pciback.


[info] Loading kernel module fuse.


[....] Cleaning up temporary files... 
/tmp[?25l[?1c7[ ok 8[?25h[?0c.


[....] Generating udev events for MD 
arrays...[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Setting up LVM Volume Groups...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Activating lvm and md swap...[   26.642119] Adding 2097148k swap 
on /dev/mapper/vg_g2-lv_g2_swap.  Priority:-1 extents:1 across:2097148k FS

[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Checking file systems...fsck from util-linux 2.25.1


/dev/md0: clean, 334/131072 files, 74860/524224 blocks


[?25l[?1c7[ ok 8[?25h[?0cdone.


[   26.948583] EXT4-fs (md0): mounting ext3 file system using the ext4 
subsystem

[   26.960457] EXT4-fs (md0): mounted filesystem with ordered data mode. 
Opts: (null)

[....] Mounting local filesystems...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Activating swapfile swap...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Cleaning up temporary files...[?25l[?1c7[ ok 
8[?25h[?0c.


[....] Setting kernel variables ...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[   27.618140] Bridge firewalling registered

[   27.625153] device eth0 entered promiscuous mode

[   27.676402] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[   27.678737] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready

[....] Configuring network interfaces...


Waiting for br0 to get ready (MAXWAIT is 32 seconds).


[   30.819293] tg3 0000:05:00.0 eth0: Link is up at 1000 Mbps, full duplex

[   30.819310] tg3 0000:05:00.0 eth0: Flow control is on for TX and on 
for RX

[   30.819327] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[   30.819350] br0: port 1(eth0) entered forwarding state

[   30.819358] br0: port 1(eth0) entered forwarding state

[   30.819377] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready

[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Cleaning up temporary files...[?25l[?1c7[ ok 
8[?25h[?0c.


[info] Setting console screen modes.


setterm: cannot (un)set powersave mode: Inappropriate ioctl for device


[9;30][14;30][....] Setting up console font and 
keymap...[?25l[?1c7[ ok 8[?25h[?0cdone.


[   31.553893] ttyS0: LSR safety check engaged!

[   31.556055] ttyS0: LSR safety check engaged!

Loading the saved-state of the serial devices...


/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A


[....] Setting up X socket directories... /tmp/.X11-unix 
/tmp/.ICE-unix[?25l[?1c7[ ok 8[?25h[?0c.


[....] Setting sensors limits[?25l[?1c7[ ok 
8[?25h[?0c.



INIT: Entering runlevel: 2



[info] Using makefile-style concurrent boot in runlevel 2.


[....] Starting enhanced syslogd: 
rsyslogd[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting MD monitoring service: mdadm 
--monitor[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting ACPI services...[?25l[?1c7[ ok 
8[?25h[?0c.


[   32.114950] xen:xen_evtchn: Event-channel device installed

[....] Starting mouse interface server: 
gpm[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting periodic command scheduler: 
cron[?25l[?1c7[ ok 8[?25h[?0c.


[....] Loading cpufreq kernel modules...modprobe: ERROR: could not 
insert 'cpufreq_userspace': No such device


modprobe: ERROR: could not insert 'cpufreq_stats': Invalid argument


modprobe: ERROR: could not insert 'cpufreq_powersave': No such device


modprobe: ERROR: could not insert 'cpufreq_conservative': No such device


[?25l[?1c7[ ok 8[?25h[?0cdone (none).


[....] CPUFreq Utilities: Setting ondemand CPUFreq governor...disabled, 
governor not available...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Starting system message bus: dbus[?25l[?1c7[ 
ok 8[?25h[?0c.


[....] Starting OpenBSD Secure Shell server: 
sshd[?25l[?1c7[ ok 8[?25h[?0c.


Starting /usr/local/sbin/oxenstored...


Setting domain 0 name, domid and JSON config...


Done setting up Dom0


Starting xenconsoled...


Starting QEMU as disk backend for dom0


[9;0][14;0]

[   36.119927] pciback 0000:02:00.0: seizing device

[   36.119991] pciback 0000:02:00.0: enabling device (0004 -> 0007)

[   36.120076] xen: registering gsi 16 triggering 0 polarity 1

[   36.120085] Already setup the GSI :16

libxl: warning: libxl_pci.c:706:libxl__device_pci_assignable_add: 
0000:02:00.0 not bound to a driver, will not be rebound.




Debian GNU/Linux jessie/sid g2 hvc0



g2 login: [   45.856185] br0: port 1(eth0) entered forwarding state

(XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input 
to DOM0)
(XEN) IRQ information:
(XEN)    IRQ:   0 affinity:01 vec:f0 type=IO-APIC-edge status=00000000 
timer_interrupt()
(XEN)    IRQ:   1 affinity:01 vec:30 type=IO-APIC-edge status=00000014 
in-flight=0 domain-list=0:  1(---),
(XEN)    IRQ:   3 affinity:01 vec:38 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   4 affinity:01 vec:f1 type=IO-APIC-edge status=00000000 
ns16550_interrupt()
(XEN)    IRQ:   5 affinity:01 vec:40 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   6 affinity:01 vec:48 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0:  6(---),
(XEN)    IRQ:   7 affinity:01 vec:50 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   8 affinity:01 vec:58 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0:  8(---),
(XEN)    IRQ:   9 affinity:01 vec:60 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0:  9(---),
(XEN)    IRQ:  10 affinity:01 vec:68 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  11 affinity:01 vec:70 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  12 affinity:01 vec:78 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0: 12(---),
(XEN)    IRQ:  13 affinity:3f vec:88 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  14 affinity:01 vec:90 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  15 affinity:01 vec:98 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  16 affinity:01 vec:a0 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 16(---),
(XEN)    IRQ:  17 affinity:01 vec:a8 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 17(---),
(XEN)    IRQ:  18 affinity:01 vec:b0 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 18(---),
(XEN)    IRQ:  19 affinity:01 vec:b8 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 19(---),
(XEN)    IRQ:  24 affinity:3f vec:28 type=DMA_MSI status=00000000 
iommu_page_fault()
(XEN)    IRQ:  25 affinity:01 vec:c0 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:279(---),
(XEN)    IRQ:  26 affinity:01 vec:c8 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:278(---),
(XEN)    IRQ:  27 affinity:01 vec:d0 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:277(---),
(XEN)    IRQ:  28 affinity:01 vec:d8 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:276(---),
(XEN)    IRQ:  29 affinity:01 vec:21 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:275(---),
(XEN)    IRQ:  30 affinity:01 vec:29 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:274(---),
(XEN)    IRQ:  31 affinity:3f vec:31 type=PCI-MSI status=00000002 
mapped, unbound
(XEN)    IRQ:  32 affinity:3f vec:39 type=PCI-MSI status=00000002 
mapped, unbound
(XEN)    IRQ:  33 affinity:01 vec:49 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:271(---),
(XEN)    IRQ:  34 affinity:01 vec:51 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:270(---),
(XEN)    IRQ:  35 affinity:01 vec:59 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:269(---),
(XEN)    IRQ:  36 affinity:01 vec:61 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:268(---),
(XEN)    IRQ:  37 affinity:01 vec:69 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:267(---),
(XEN)    IRQ:  38 affinity:01 vec:71 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:266(---),
(XEN)    IRQ:  39 affinity:01 vec:79 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:265(---),
(XEN)    IRQ:  40 affinity:01 vec:81 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:264(---),
(XEN)    IRQ:  41 affinity:01 vec:89 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:263(---),
(XEN)    IRQ:  42 affinity:01 vec:91 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:262(---),
(XEN)    IRQ:  43 affinity:01 vec:99 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:261(---),
(XEN) Direct vector information:
(XEN)    0x20 -> irq_move_cleanup_interrupt()
(XEN)    0xf2 -> cmci_interrupt()
(XEN)    0xf3 -> intel_thermal_interrupt()
(XEN)    0xf9 -> pmu_apic_interrupt()
(XEN)    0xfa -> apic_timer_interrupt()
(XEN)    0xfb -> call_function_interrupt()
(XEN)    0xfc -> event_check_interrupt()
(XEN)    0xfd -> invalidate_interrupt()
(XEN)    0xfe -> error_interrupt()
(XEN)    0xff -> spurious_interrupt()
(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 48:
(XEN)       Apic 0x00, Pin  1: vec=30 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  3 Vec 56:
(XEN)       Apic 0x00, Pin  3: vec=38 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 64:
(XEN)       Apic 0x00, Pin  5: vec=40 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  6 Vec 72:
(XEN)       Apic 0x00, Pin  6: vec=48 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  7 Vec 80:
(XEN)       Apic 0x00, Pin  7: vec=50 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  8 Vec 88:
(XEN)       Apic 0x00, Pin  8: vec=58 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  9 Vec 96:
(XEN)       Apic 0x00, Pin  9: vec=60 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 10 Vec104:
(XEN)       Apic 0x00, Pin 10: vec=68 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 11 Vec112:
(XEN)       Apic 0x00, Pin 11: vec=70 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 12 Vec120:
(XEN)       Apic 0x00, Pin 12: vec=78 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 13 Vec136:
(XEN)       Apic 0x00, Pin 13: vec=88 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=1 dest_id:63
(XEN)     IRQ 14 Vec144:
(XEN)       Apic 0x00, Pin 14: vec=90 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 15 Vec152:
(XEN)       Apic 0x00, Pin 15: vec=98 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 16 Vec160:
(XEN)       Apic 0x00, Pin 16: vec=a0 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 17 Vec168:
(XEN)       Apic 0x00, Pin 17: vec=a8 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 18 Vec176:
(XEN)       Apic 0x00, Pin 18: vec=b0 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 19 Vec184:
(XEN)       Apic 0x00, Pin 19: vec=b8 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:        C0
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00005664] method[  FFH] 
duration[4042540627]
(XEN)     C2:    type[C3] latency[064] usage[00000414] method[  FFH] 
duration[447258888]
(XEN)     C3:    type[C3] latency[096] usage[00002366] method[  FFH] 
duration[28183588810]
(XEN)    *C0:    usage[00008444] duration[26752178344]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[484210884] CC6[27943480555] CC7[0]
(XEN) ==cpu1==
(XEN) active state:        C3
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00002007] method[  FFH] 
duration[4316094103]
(XEN)     C2:    type[C3] latency[064] usage[00000179] method[  FFH] 
duration[430291017]
(XEN)    *C3:    type[C3] latency[096] usage[00000785] method[  FFH] 
duration[27543087914]
(XEN)     C0:    usage[00002971] duration[27136150937]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[498924899] CC6[26514562346] CC7[0]
(XEN) ==cpu2==
(XEN) active state:        C3
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00001925] method[  FFH] 
duration[3925569185]
(XEN)     C2:    type[C3] latency[064] usage[00000199] method[  FFH] 
duration[341001922]
(XEN)    *C3:    type[C3] latency[096] usage[00000761] method[  FFH] 
duration[27805737869]
(XEN)     C0:    usage[00002885] duration[27353411294]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[377373007] CC6[27202250545] CC7[0]
(XEN) ==cpu3==
(XEN) active state:        C3
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00001880] method[  FFH] 
duration[2679771477]
(XEN)     C2:    type[C3] latency[064] usage[00000229] method[  FFH] 
duration[188146428]
(XEN)    *C3:    type[C3] latency[096] usage[00001031] method[  FFH] 
duration[29498117979]
(XEN)     C0:    usage[00003140] duration[27059782098]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[254623106] CC6[28394085736] CC7[0]
(XEN) ==cpu4==
(XEN) active state:        C3
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00001756] method[  FFH] 
duration[2769254927]
(XEN)     C2:    type[C3] latency[064] usage[00000229] method[  FFH] 
duration[301480682]
(XEN)    *C3:    type[C3] latency[096] usage[00000859] method[  FFH] 
duration[28897863294]
(XEN)     C0:    usage[00002844] duration[27457318503]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[383731673] CC6[28101648533] CC7[0]
(XEN) ==cpu5==
(XEN) active state:        C3
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00001570] method[  FFH] 
duration[3273775119]
(XEN)     C2:    type[C3] latency[064] usage[00000265] method[  FFH] 
duration[367342058]
(XEN)    *C3:    type[C3] latency[096] usage[00000719] method[  FFH] 
duration[28591526276]
(XEN)     C0:    usage[00002554] duration[27193372517]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[470602725] CC6[29075968196] CC7[0]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Nov 24 22:17:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Nov 2014 22: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 1Xt1wb-0002VN-EP; Mon, 24 Nov 2014 22:17:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xt1wa-0002VI-1Q
	for xen-devel@lists.xen.org; Mon, 24 Nov 2014 22:17:16 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	04/18-22737-B6EA3745; Mon, 24 Nov 2014 22:17:15 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416867429!7825089!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19857 invoked from network); 24 Nov 2014 22:17:10 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2014 22:17:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416867428; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=jYM2BlIMuFrurb1cwKc4DZOjNEeXwXcHPkHMSNMFbWg=;
	b=gIUUTKY5LLbLoIklAsGWzmza4SYG8STccVzzRLGynKiSGlB7nN/rNefIbAJbs8YPIS4lOvDvMf051iv2wEaD4YMZBVSU/Zdy3kYT1+x46Z3CWo7W+O6gdM2rNRAWnL6HAUm1yvDe0YlFic/LVY+zL+Hwobvgwwl7O1GtuCEaX80=
Received: from [10.0.0.11] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Mon, 24 Nov 2014 14:17:07 -0800
	id 0000000000030434.5473AE63.00007A92
Message-ID: <5473AE78.5070505@ihonk.com>
Date: Mon, 24 Nov 2014 14:17:28 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5457F79B.2020300@ihonk.com>
	<20141104082012.GY12451@reaktio.net>	<5458B55C0200007800044B33@mail.emea.novell.com>	<5460716A.7090905@ihonk.com>	<54608A8B0200007800045E58@mail.emea.novell.com>	<54611A86.4000200@ihonk.com>	<5461D15C02000078000464D7@mail.emea.novell.com>	<546A4AD4.3030002@ihonk.com>	<546B094C0200007800048A5C@mail.emea.novell.com>	<546D429A.5020906@ihonk.com>	<546DAD6502000078000492FD@mail.emea.novell.com>	<546E4A17.5040902@ihonk.com>	<546F091F0200007800049A1C@smtp.nue.novell.com>	<54713848.3020401@ihonk.com>	<5472FE31020000780004A2D5@mail.emea.novell.com>	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
In-Reply-To: <54732768020000780004A48C@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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.11.14 at 10:08,<sflist@ihonk.com>  wrote:
> On Nov 24, 2014, at 00:45, Jan Beulich<JBeulich@suse.com>  wrote:
>>>>> On 23.11.14 at 02:28,<sflist@ihonk.com>  wrote:
>>> As promised, below is the apic-verbosity=debug log, with 'i'. Thanks!
>> I'm sorry, I misspelled the option, it's really "apic_verbosity=debug".
>> The 'i' output at least already confirms that there are no ExtINT
>> entries among the IO-APIC RTEs.
> No sweat. Do you need me to run it again with the corrected option?
> Yes please, just to be certain we can discount that one.
>

I'm combining this action with your patch, see below. Please let me know 
if this was incorrect.

On 11/24/2014 3:41, Jan Beulich wrote:
> While putting this together I found the reason for the strange C2: 
> line, and the attached debugging patch already has the fix for it 
> (which I'll also submit separately, and hence you may need to drop 
> that specific hunk should you end up applying it on a tree which 
> already has that fix). You'll need to again run with "mwait-idle=0", 
> and it's the boot messages along with the 'c' debug key output that's 
> of interest. Thanks, Jan

I applied the patch to 4.5-rc2, this was the patch output:

steve@g2:~/git/xen$ patch -p1 < ../Freitas-Cx.patch
patching file xen/arch/x86/acpi/cpu_idle.c
Hunk #2 succeeded at 229 (offset -9 lines).
Hunk #3 succeeded at 263 (offset -10 lines).
Hunk #4 succeeded at 491 (offset -10 lines).
Hunk #5 succeeded at 504 (offset -15 lines).
Hunk #6 succeeded at 992 (offset -15 lines).
Hunk #7 succeeded at 1000 (offset -15 lines).
patch unexpectedly ends in middle of line
Hunk #8 succeeded at 1126 with fuzz 1 (offset -15 lines).

And here's the boot log, with 'c' and 'i' output from Xen:

[?25lGNU GRUB  version 2.02~beta2-15

+----------------------------------------------------------------------------+||||||||||||||||||||||||+----------------------------------------------------------------------------+ 
Use the ^ and v keys to select which entry is highlighted.
       Press enter to boot the selected OS, `e' to edit the commands
       before booting or `c' for a 
command-line.                            *Debian 
GNU/Linux, with Xen hypervisor  Advanced options 
for Debian GNU/Linux (with Xen hypervisor)                
 Debian GNU/Linux  Advanced 
options for Debian GNU/Linux  
  
  
  
     The 
highlighted entry will be executed automatically in 
10s.                 The highlighted entry will be 
executed automatically in 9s.                    The 
highlighted entry will be executed automatically in 
8s.                    The highlighted entry will be 
executed automatically in 7s.                    The 
highlighted entry will be executed automatically in 
6s.                    The highlighted entry will be 
executed automatically in 5s.                    The 
highlighted entry will be executed automatically in 
4s.                    The highlighted entry will be 
executed automatically in 3s.                    The 
highlighted entry will be executed automatically in 
2s.                    The highlighted entry will be 
executed automatically in 1s.                    The 
highlighted entry will be executed automatically in 0s. 
[?25hLoading Xen xen ...
Loading Linux 3.16-3-amd64 ...
Loading initial ramdisk ...
  Xen 4.5.0-rc
(XEN) Xen version 4.5.0-rc (steve@) (gcc (Debian 4.9.1-19) 4.9.1) 
debug=y Mon Nov 24 13:47:48 PST 2014
(XEN) Latest ChangeSet: Tue Nov 11 09:40:20 2014 -0500 git:cacfcc5-dirty
(XEN) Bootloader: GRUB 2.02~beta2-15
(XEN) Command line: placeholder cpufreq=xen:ondemand cpuidle 
clocksource=hpet loglvl=all guest_loglvl=all iommu=no-intremap,debug 
com1=115200,8n1 console=com1,vga apic_verbosity=debug mwait-idle=0
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 2 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d000 (usable)
(XEN)  000000000009d000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf7a0000 (usable)
(XEN)  00000000bf7a0000 - 00000000bf7ca000 (ACPI data)
(XEN)  00000000bf7ca000 - 00000000bf7cc000 (ACPI NVS)
(XEN)  00000000bf7cc000 - 00000000c0000000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000F6A40, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT BF7BF38F, 0084 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: FACP BF7C98D1, 00F4 (r3 LENOVO TC-61     60400D0 PTL         2)
(XEN) ACPI: DSDT BF7BF413, A43A (r1 LENOVO TC-61     60400D0 MSFT 100000E)
(XEN) ACPI: FACS BF7CBFC0, 0040
(XEN) ACPI: SSDT BF7AF33B, 2694 (r1  INTEL PPM RCM  80000001 INTL 20061109)
(XEN) ACPI: SLIT BF7C99E9, 0030 (r1 Intel  TYLERBRG  60400D0 LOHR       5A)
(XEN) ACPI: TCPA BF7C9A19, 0032 (r1 LENOVO TC-61     60400D0 PTL         0)
(XEN) ACPI: SLIC BF7C9A4B, 0176 (r1 LENOVO TC-61     60400D0 LTP        0)
(XEN) ACPI: SRAT BF7C9BC1, 00E0 (r1 Intel  Tylerbrg  60400D0 PHX.        1)
(XEN) ACPI: DMAR BF7C9CA1, 01C0 (r1 Intel  OEMDMAR   60400D0 LOHR        1)
(XEN) ACPI: APIC BF7C9E61, 00A0 (r1 PTLTD       APIC    60400D0 
LTP        0)
(XEN) ACPI: MCFG BF7C9F01, 003C (r1 PTLTD    MCFG    60400D0 LTP        0)
(XEN) ACPI: HPET BF7C9F3D, 0038 (r1 PTLTD  HPETTBL   60400D0 LTP        1)
(XEN) ACPI: BOOT BF7C9F75, 0028 (r1 PTLTD  $SBFTBL$  60400D0 LTP        1)
(XEN) ACPI: ASF! BF7C9F9D, 0063 (r32 LENOVO TC-61     60400D0 PTL         1)
(XEN) System RAM: 49143MB (50322676kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: Node 0 PXM 0 0-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-c40000000
(XEN) NUMA: Using 20 for the hash shift.
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000f6a70
(XEN) DMI present.
(XEN) APIC boot state is 'xapic'
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1008
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1004,1:0], pm1x_evt[1:1000,1:0]
(XEN) ACPI:             wakeup_vec[bf7cbfcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(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: 0x8086a301 base: 0xfed00000
(XEN) [VT-D]dmar.c:788: Host address width 40
(XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:472:   dmaru->address = fe710000
(XEN) [VT-D]iommu.c:1146: drhd->address = fe710000 iommu->reg = 
ffff82c000201000
(XEN) [VT-D]iommu.c:1148: cap = c90780106f0462 ecap = f0207f
(XEN) [VT-D]dmar.c:397:  IOAPIC: 0000:f0:1f.7
(XEN) [VT-D]dmar.c:486:   flags: INCLUDE_ALL
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.1
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.7
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.1
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.2
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.3
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7cd000 end_address 
bf7dbfff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e4000 end_address 
bf7e4fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.1
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e5000 end_address 
bf7e5fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7ea000 end_address 
bf7eafff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e6000 end_address 
bf7e6fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.1
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e7000 end_address 
bf7e7fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.2
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e8000 end_address 
bf7e8fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.3
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7e9000 end_address 
bf7e9fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.7
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr bf7eb000 end_address 
bf7ebfff
(XEN) [VT-D]dmar.c:812: found ACPI_DMAR_ATSR:
(XEN) [VT-D]dmar.c:705:   atsru->all_ports: 0
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:01.0 start=0 sec=1 sub=1
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:03.0 start=0 sec=2 sub=2
(XEN) [VT-D]dmar.c:353:  bridge: 0000:00:07.0 start=0 sec=3 sub=3
(XEN) ERST table was not found
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 6 CPUs (0 hotplug CPUs)
(XEN) mapped APIC to ffff82cfffdfb000 (fee00000)
(XEN) mapped IOAPIC to ffff82cfffdfa000 (fec00000)
(XEN) IRQ limits: 24 GSI, 1144 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2800.164 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) alt table ffff82d0802d7fd0 -> ffff82d0802d8ff0
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 09
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-09
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB.
(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 not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping disabled
(XEN) Getting VERSION: 1060015
(XEN) Getting VERSION: 1060015
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) Getting ID: 0
(XEN) Getting LVT0: 700
(XEN) Getting LVT1: 400
(XEN) Suppress EOI broadcast on CPU#0
(XEN) enabled ExtINT on CPU#0
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) init IO_APIC IRQs
(XEN)  IO-APIC (apicid-pin) 1-0, 1-16, 1-17, 1-18, 1-19, 1-20, 1-21, 
1-22, 1-23 not connected.
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) number of MP IRQ sources: 15.
(XEN) number of IO-APIC #1 registers: 24.
(XEN) testing the IO APIC.......................
(XEN) IO APIC #1......
(XEN) .... register #00: 01000000
(XEN) .......    : physical APIC id: 01
(XEN) .......    : Delivery Type: 0
(XEN) .......    : LTS          : 0
(XEN) .... register #01: 00170020
(XEN) .......     : max redirection entries: 0017
(XEN) .......     : PRQ implemented: 0
(XEN) .......     : IO APIC version: 0020
(XEN) .... IRQ redirection table:
(XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
(XEN)  00 000 00  1    0    0   0   0    0    0    00
(XEN)  01 001 01  0    0    0   0   0    1    1    30
(XEN)  02 001 01  0    0    0   0   0    1    1    F0
(XEN)  03 001 01  0    0    0   0   0    1    1    38
(XEN)  04 001 01  0    0    0   0   0    1    1    F1
(XEN)  05 001 01  0    0    0   0   0    1    1    40
(XEN)  06 001 01  0    0    0   0   0    1    1    48
(XEN)  07 001 01  0    0    0   0   0    1    1    50
(XEN)  08 001 01  0    0    0   0   0    1    1    58
(XEN)  09 001 01  1    1    0   0   0    1    1    60
(XEN)  0a 001 01  0    0    0   0   0    1    1    68
(XEN)  0b 001 01  0    0    0   0   0    1    1    70
(XEN)  0c 001 01  0    0    0   0   0    1    1    78
(XEN)  0d 001 01  0    0    0   0   0    1    1    88
(XEN)  0e 001 01  0    0    0   0   0    1    1    90
(XEN)  0f 001 01  0    0    0   0   0    1    1    98
(XEN)  10 000 00  1    0    0   0   0    0    0    00
(XEN)  11 000 00  1    0    0   0   0    0    0    00
(XEN)  12 000 00  1    0    0   0   0    0    0    00
(XEN)  13 000 00  1    0    0   0   0    0    0    00
(XEN)  14 000 00  1    0    0   0   0    0    0    00
(XEN)  15 000 00  1    0    0   0   0    0    0    00
(XEN)  16 000 00  1    0    0   0   0    0    0    00
(XEN)  17 000 00  1    0    0   0   0    0    0    00
(XEN) Using vector-based indexing
(XEN) IRQ to pin mappings:
(XEN) IRQ240 -> 0:2
(XEN) IRQ48 -> 0:1
(XEN) IRQ56 -> 0:3
(XEN) IRQ241 -> 0:4
(XEN) IRQ64 -> 0:5
(XEN) IRQ72 -> 0:6
(XEN) IRQ80 -> 0:7
(XEN) IRQ88 -> 0:8
(XEN) IRQ96 -> 0:9
(XEN) IRQ104 -> 0:10
(XEN) IRQ112 -> 0:11
(XEN) IRQ120 -> 0:12
(XEN) IRQ136 -> 0:13
(XEN) IRQ144 -> 0:14
(XEN) IRQ152 -> 0:15
(XEN) .................................... done.
(XEN) Using local APIC timer interrupts.
(XEN) calibrating APIC timer ...
(XEN) ..... CPU clock speed is 2800.1136 MHz.
(XEN) ..... host bus clock speed is 133.3387 MHz.
(XEN) ..... bus_scale = 0x888d
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 64 KiB.
(XEN) mwait-idle: disabled
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Suppress EOI broadcast on CPU#1
(XEN) masked ExtINT on CPU#1
(XEN) Suppress EOI broadcast on CPU#2
(XEN) masked ExtINT on CPU#2
(XEN) Suppress EOI broadcast on CPU#3
(XEN) masked ExtINT on CPU#3
(XEN) Suppress EOI broadcast on CPU#4
(XEN) masked ExtINT on CPU#4
(XEN) Suppress EOI broadcast on CPU#5
(XEN) masked ExtINT on CPU#5
(XEN) Brought up 6 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x7c8000
(XEN) elf_parse_binary: phdr: paddr=0x1800000 memsz=0xed000
(XEN) elf_parse_binary: phdr: paddr=0x18ed000 memsz=0x14f40
(XEN) elf_parse_binary: phdr: paddr=0x1902000 memsz=0x614000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x1f16000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff819021f0
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = 
"!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
(XEN) elf_xen_parse_note: SUPPORTED_FEATURES = 0x90d
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff81f16000
(XEN)     virt_entry       = 0xffffffff819021f0
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f16000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c00000000->0000000c10000000 (12316667 pages 
to be allocated)
(XEN)  Init. ramdisk: 0000000c3f0da000->0000000c3ffff86e
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81f16000
(XEN)  Init. ramdisk: ffffffff81f16000->ffffffff82e3b86e
(XEN)  Phys-Mach map: ffffffff82e3c000->ffffffff88cbb908
(XEN)  Start info:    ffffffff88cbc000->ffffffff88cbc4b4
(XEN)  Page tables:   ffffffff88cbd000->ffffffff88d08000
(XEN)  Boot stack:    ffffffff88d08000->ffffffff88d09000
(XEN)  TOTAL:         ffffffff80000000->ffffffff89000000
(XEN)  ENTRY ADDRESS: ffffffff819021f0
(XEN) Dom0 has maximum 6 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff817c8000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81800000 -> 0xffffffff818ed000
(XEN) elf_load_binary: phdr 2 at 0xffffffff818ed000 -> 0xffffffff81901f40
(XEN) elf_load_binary: phdr 3 at 0xffffffff81902000 -> 0xffffffff81a1f000
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:00:00.0 map
(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:14.0
(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:14.1
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:14.2
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.1
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.2
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.3
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.4
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.5
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.6
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:16.7
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1a.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1a.1
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1a.7
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:1b.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1d.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1d.1
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1d.2
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1d.3
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1d.7
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1f.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1f.2
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1f.3
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:01:00.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:02:00.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:05:00.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:09:00.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:0a:0e.0
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:00.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:00.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.2 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.3 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.4 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:02.5 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:03.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:03.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:03.2 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:03.4 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:04.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:04.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:04.2 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:04.3 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:05.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:05.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:05.2 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:05.3 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:06.0 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:06.1 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:06.2 map
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:3f:06.3 map
(XEN) [VT-D]iommu.c:739: iommu_enable_translation: iommu->reg = 
ffff82c000201000
(XEN) Scrubbing Free RAM on 1 nodes using 6 CPUs
(XEN) 
..................................................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch 
input to Xen)
(XEN) Freed 296kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.16-3-amd64 
(debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-12) ) 
#1 SMP Debian 3.16.5-1 (2014-10-10)
[    0.000000] Command line: placeholder 
root=/dev/mapper/vg_g2-lv_g2_root ro console=hvc0 earlyprintk=serial 
xencons=hvc debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 
LOGLEVEL=8 sched_debug
[    0.000000] Freeing 9d-100 pfn range: 99 pages freed
[    0.000000] Freeing bf7a0-100000 pfn range: 264288 pages freed
[    0.000000] Released 264387 pages of unused memory
[    0.000000] Set 264387 page(s) to 1-1 mapping
[    0.000000] Populating bcff21-c107e4 pfn range: 264387 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
[    0.000000] Xen: [mem 0x000000000009d000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000bf79ffff] usable
[    0.000000] Xen: [mem 0x00000000bf7a0000-0x00000000bf7c9fff] ACPI data
[    0.000000] Xen: [mem 0x00000000bf7ca000-0x00000000bf7cbfff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000bf7cc000-0x00000000bfffffff] reserved
[    0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] Xen: [mem 0x00000000fe710000-0x00000000fe710fff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved
[    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000c3fffffff] usable
[    0.000000] bootconsole [earlyser0] enabled
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.6 present.
[    0.000000] DMI: LENOVO 4158WRG/LENOVO, BIOS 61KT50AUS 01/14/2014
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] AGP: No AGP bridge found
[    0.000000] e820: last_pfn = 0xc40000 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xbf7a0 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] init_memory_mapping: [mem 0xc10400000-0xc105fffff]
[    0.000000]  [mem 0xc10400000-0xc105fffff] page 4k
[    0.000000] BRK [0x01b61000, 0x01b61fff] PGTABLE
[    0.000000] BRK [0x01b62000, 0x01b62fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0xc10000000-0xc103fffff]
[    0.000000]  [mem 0xc10000000-0xc103fffff] page 4k
[    0.000000] BRK [0x01b63000, 0x01b63fff] PGTABLE
[    0.000000] BRK [0x01b64000, 0x01b64fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0xc00000000-0xc0fffffff]
[    0.000000]  [mem 0xc00000000-0xc0fffffff] page 4k
[    0.000000] BRK [0x01b65000, 0x01b65fff] PGTABLE
[    0.000000] BRK [0x01b66000, 0x01b66fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x00100000-0xbf79ffff]
[    0.000000]  [mem 0x00100000-0xbf79ffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x100000000-0xbffffffff]
[    0.000000]  [mem 0x100000000-0xbffffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0xc10600000-0xc3fffffff]
[    0.000000]  [mem 0xc10600000-0xc3fffffff] page 4k
[    0.000000] log_buf_len: 16777216
[    0.000000] early log buf free: 127296(97%)
[    0.000000] RAMDISK: [mem 0x01f16000-0x02e3bfff]
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000000F6A40 000024 (v02 PTLTD )
[    0.000000] ACPI: XSDT 0x00000000BF7BF38F 000084 (v01 LENOVO TC-61    
060400D0  LTP 00000000)
[    0.000000] ACPI: FACP 0x00000000BF7C98D1 0000F4 (v03 LENOVO TC-61    
060400D0 PTL  00000002)
[    0.000000] ACPI: DSDT 0x00000000BF7BF413 00A43A (v01 LENOVO TC-61    
060400D0 MSFT 0100000E)
[    0.000000] ACPI: FACS 0x00000000BF7CBFC0 000040
[    0.000000] ACPI: SSDT 0x00000000BF7AF33B 002694 (v01 INTEL  PPM RCM  
80000001 INTL 20061109)
[    0.000000] ACPI: SLIT 0x00000000BF7C99E9 000030 (v01 Intel TYLERBRG 
060400D0 LOHR 0000005A)
[    0.000000] ACPI: TCPA 0x00000000BF7C9A19 000032 (v01 LENOVO TC-61    
060400D0 PTL  00000000)
[    0.000000] ACPI: SLIC 0x00000000BF7C9A4B 000176 (v01 LENOVO TC-61    
060400D0  LTP 00000000)
[    0.000000] ACPI: SRAT 0x00000000BF7C9BC1 0000E0 (v01 Intel Tylerbrg 
060400D0 PHX. 00000001)
[    0.000000] ACPI: XMAR 0x00000000BF7C9CA1 0001C0 (v01 Intel OEMDMAR  
060400D0 LOHR 00000001)
[    0.000000] ACPI: APIC 0x00000000BF7C9E61 0000A0 (v01 PTLTD  ? APIC   
060400D0  LTP 00000000)
[    0.000000] ACPI: MCFG 0x00000000BF7C9F01 00003C (v01 PTLTD MCFG   
060400D0  LTP 00000000)
[    0.000000] ACPI: HPET 0x00000000BF7C9F3D 000038 (v01 PTLTD HPETTBL  
060400D0  LTP 00000001)
[    0.000000] ACPI: BOOT 0x00000000BF7C9F75 000028 (v01 PTLTD $SBFTBL$ 
060400D0  LTP 00000001)
[    0.000000] ACPI: ASF! 0x00000000BF7C9F9D 000063 (v32 LENOVO TC-61    
060400D0 PTL  00000001)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000c3fffffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0xc3fffffff]
[    0.000000]   NODE_DATA [mem 0xc107df000-0xc107e3fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0xc3fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009cfff]
[    0.000000]   node   0: [mem 0x00100000-0xbf79ffff]
[    0.000000]   node   0: [mem 0x100000000-0xc3fffffff]
[    0.000000] On node 0 totalpages: 12580668
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 21 pages reserved
[    0.000000]   DMA zone: 3996 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 10667 pages used for memmap
[    0.000000]   DMA32 zone: 780192 pages, LIFO batch:31
[    0.000000]   Normal zone: 161280 pages used for memmap
[    0.000000]   Normal zone: 11796480 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 
0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[    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: 0x8086a301 base: 0xfed00000
[    0.000000] smpboot: Allowing 6 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 40
[    0.000000] PM: Registered nosave memory: [mem 0x0009d000-0x000fffff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7a0000-0xbf7c9fff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7ca000-0xbf7cbfff]
[    0.000000] PM: Registered nosave memory: [mem 0xbf7cc000-0xbfffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xc0000000-0xf7ffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xf8000000-0xfbffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfc000000-0xfe70ffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfe710000-0xfe710fff]
[    0.000000] PM: Registered nosave memory: [mem 0xfe711000-0xfebfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfec0ffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfec10000-0xfedfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfeefffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfef00000-0xfeffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xff000000-0xffffffff]
[    0.000000] e820: [mem 0xc0000000-0xf7ffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.5.0-rc (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 
nr_cpu_ids:6 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880c03400000 s85824 
r8192 d20672 u262144
[    0.000000] pcpu-alloc: s85824 r8192 d20672 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 - -
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  
Total pages: 12408644
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: placeholder 
root=/dev/mapper/vg_g2-lv_g2_root ro console=hvc0 earlyprintk=serial 
xencons=hvc debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 
LOGLEVEL=8 sched_debug
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] software IO TLB [mem 0xbd4e00000-0xbd8e00000] (64MB) 
mapped at [ffff880bd4e00000-ffff880bd8dfffff]
[    0.000000] Memory: 48548940K/50322672K available (5189K kernel code, 
942K rwdata, 1824K rodata, 1200K init, 840K bss, 1773732K reserved)
[    0.000000] Hierarchical RCU implementation.
[    0.000000]     RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000]     RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=6.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6
[    0.000000] NR_IRQS:33024 nr_irqs:728 16
[    0.000000] xen:events: Using FIFO-based ABI
[    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)
(XEN) IOAPIC[0]: Set PCI routing entry (1-9 -> 0x60 -> IRQ 9 Mode:1 
Active:0)
[    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: --> 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 [hvc0] enabled

[    0.000000] console [hvc0] enabled
[    0.000000] bootconsole [earlyser0] disabled

[    0.000000] bootconsole [earlyser0] disabled
[    0.000000] bootconsole [xenboot0] disabled

[    0.000000] bootconsole [xenboot0] disabled
[    0.000000] Xen: using vcpuop timer interface

[    0.000000] installing Xen timer for CPU 0

[    0.000000] tsc: Detected 2800.164 MHz processor

[   11.929093] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 5600.32 BogoMIPS (lpj=11200656)

[   11.929098] pid_max: default: 32768 minimum: 301

[   11.929107] ACPI: Core revision 20140424

[   11.933681] ACPI: All ACPI Tables successfully acquired

[   11.940307] Security Framework initialized

[   11.940317] AppArmor: AppArmor disabled by boot time parameter

[   11.940320] Yama: disabled by default; enable with sysctl kernel.yama.*

[   11.948791] Dentry cache hash table entries: 8388608 (order: 14, 
67108864 bytes)

[   11.962761] Inode-cache hash table entries: 4194304 (order: 13, 
33554432 bytes)

[   11.967450] Mount-cache hash table entries: 131072 (order: 8, 1048576 
bytes)

[   11.967602] Mountpoint-cache hash table entries: 131072 (order: 8, 
1048576 bytes)

[   11.968060] Initializing cgroup subsys memory

[   11.968066] Initializing cgroup subsys devices

[   11.968073] Initializing cgroup subsys freezer

[   11.968077] Initializing cgroup subsys net_cls

[   11.968082] Initializing cgroup subsys blkio

[   11.968086] Initializing cgroup subsys perf_event

[   11.968089] Initializing cgroup subsys net_prio

[   11.968142] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'

[   11.968142] ENERGY_PERF_BIAS: View and update with 
x86_energy_perf_policy(8)

[   11.968171] CPU: Physical Processor ID: 0

[   11.968173] CPU: Processor Core ID: 0

[   11.968176] mce: CPU supports 2 MCE banks

[   11.968191] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7

[   11.968191] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0

[   11.968191] tlb_flushall_shift: 6

[   11.968257] Freeing SMP alternatives memory: 20K (ffffffff81a19000 - 
ffffffff81a1e000)

[   11.969139] ftrace: allocating 21546 entries in 85 pages

[   11.976086] Performance Events: unsupported p6 CPU model 44 no PMU 
driver, software events only.

[   11.977204] NMI watchdog: disabled (cpu0): hardware events not enabled

[   11.977282] installing Xen timer for CPU 1

[   11.977528] installing Xen timer for CPU 2

[   11.977726] installing Xen timer for CPU 3

[   11.977921] installing Xen timer for CPU 4

[   11.978123] installing Xen timer for CPU 5

[   11.978244] x86: Booted up 1 node, 6 CPUs

[   11.978264] CPU0 attaching sched-domain:

[   11.978267]  domain 0: span 0-5 level MC

[   11.978269]   groups: 0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 
2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 
5 (cpu_capacity = 1023)

[   11.978281] CPU1 attaching sched-domain:

[   11.978283]  domain 0: span 0-5 level MC

[   11.978285]   groups: 1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 
3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 
0 (cpu_capacity = 1023)

[   11.978296] CPU2 attaching sched-domain:

[   11.978298]  domain 0: span 0-5 level MC

[   11.978300]   groups: 2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 
4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 
1 (cpu_capacity = 1023)

[   11.978310] CPU3 attaching sched-domain:

[   11.978312]  domain 0: span 0-5 level MC

[   11.978314]   groups: 3 (cpu_capacity = 1023) 4 (cpu_capacity = 1023) 
5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 
2 (cpu_capacity = 1023)

[   11.978324] CPU4 attaching sched-domain:

[   11.978326]  domain 0: span 0-5 level MC

[   11.978328]   groups: 4 (cpu_capacity = 1023) 5 (cpu_capacity = 1023) 
0 (cpu_capacity = 1023) 1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 
3 (cpu_capacity = 1023)

[   11.978339] CPU5 attaching sched-domain:

[   11.978341]  domain 0: span 0-5 level MC

[   11.978343]   groups: 5 (cpu_capacity = 1023) 0 (cpu_capacity = 1023) 
1 (cpu_capacity = 1023) 2 (cpu_capacity = 1023) 3 (cpu_capacity = 1023) 
4 (cpu_capacity = 1023)

[   11.978524] devtmpfs: initialized

[   11.984790] PM: Registering ACPI NVS region [mem 
0xbf7ca000-0xbf7cbfff] (8192 bytes)

[   11.985592] pinctrl core: initialized pinctrl subsystem

[   11.985667] NET: Registered protocol family 16

[   11.985679] xen:grant_table: Grant tables using version 1 layout

[   11.985690] Grant table initialized

[   11.985944] ACPI FADT declares the system doesn't support PCIe ASPM, 
so disable it

[   11.985949] ACPI: bus type PCI registered

[   11.985951] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5

[   11.986130] PCI: MMCONFIG for domain 0000 [bus 00-09] at [mem 
0xf8000000-0xf89fffff] (base 0xf8000000)

[   11.986135] PCI: MMCONFIG at [mem 0xf8000000-0xf89fffff] reserved in E820

[   11.987060] PCI: Using configuration type 1 for base access

[   11.996829] ACPI: Added _OSI(Module Device)

[   11.996852] ACPI: Added _OSI(Processor Device)

[   11.996854] ACPI: Added _OSI(3.0 _SCP Extensions)

[   11.996856] ACPI: Added _OSI(Processor Aggregator Device)

[   11.999982] ACPI: Interpreter enabled

[   11.999989] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep 
State [\_S1_] (20140424/hwxface-580)

[   11.999994] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep 
State [\_S2_] (20140424/hwxface-580)

[   12.000006] ACPI: (supports S0 S3 S4 S5)

[   12.000008] ACPI: Using IOAPIC for interrupt routing

[   12.000032] PCI: Using host bridge windows from ACPI; if necessary, 
use "pci=nocrs" and report a bug

[   12.013771] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])

[   12.013779] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM 
ClockPM Segments MSI]

[   12.013998] acpi PNP0A03:00: _OSC: OS now controls [PCIeHotplug PME 
AER PCIeCapability]

[   12.014671] acpi PNP0A03:00: [Firmware Info]: MMCONFIG for domain 
0000 [bus 00-09] only partially covers this bridge

[   12.014847] PCI host bridge to bus 0000:00

[   12.014851] pci_bus 0000:00: root bus resource [bus 00-ff]

[   12.014878] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7]

[   12.014881] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff]

[   12.014884] pci_bus 0000:00: root bus resource [mem 
0x000a0000-0x000bffff]

[   12.014887] pci_bus 0000:00: root bus resource [mem 
0x000d0000-0x000d3fff]

[   12.014890] pci_bus 0000:00: root bus resource [mem 
0x000d4000-0x000d7fff]

[   12.014893] pci_bus 0000:00: root bus resource [mem 
0x000d8000-0x000dbfff]

[   12.014896] pci_bus 0000:00: root bus resource [mem 
0x000dc000-0x000dffff]

[   12.014899] pci_bus 0000:00: root bus resource [mem 
0xc0000000-0xfdffffff]

[   12.014918] pci 0000:00:00.0: [8086:3406] type 00 class 0x060000

[   12.015018] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold

(XEN) Found masked UR signaling on 0000:00:00.0
(XEN) PCI add device 0000:00:00.0
[   12.015131] pci 0000:00:01.0: [8086:3408] type 01 class 0x060400

[   12.015239] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold

[   12.015288] pci 0000:00:01.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:01.0
(XEN) PCI add device 0000:00:01.0
[   12.015356] pci 0000:00:03.0: [8086:340a] type 01 class 0x060400

[   12.015464] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold

[   12.015513] pci 0000:00:03.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:03.0
(XEN) PCI add device 0000:00:03.0
[   12.015583] pci 0000:00:07.0: [8086:340e] type 01 class 0x060400

[   12.015682] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold

[   12.015733] pci 0000:00:07.0: System wakeup disabled by ACPI

(XEN) Found masked UR signaling on 0000:00:07.0
(XEN) PCI add device 0000:00:07.0
[   12.015807] pci 0000:00:14.0: [8086:342e] type 00 class 0x080000

(XEN) Masked VT-d error signaling on 0000:00:14.0
(XEN) PCI add device 0000:00:14.0
[   12.015968] pci 0000:00:14.1: [8086:3422] type 00 class 0x080000

(XEN) PCI add device 0000:00:14.1
[   12.016122] pci 0000:00:14.2: [8086:3423] type 00 class 0x080000

(XEN) PCI add device 0000:00:14.2
[   12.016294] pci 0000:00:16.0: [8086:3430] type 00 class 0x088000

[   12.016316] pci 0000:00:16.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.0
[   12.016480] pci 0000:00:16.1: [8086:3431] type 00 class 0x088000

[   12.016502] pci 0000:00:16.1: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.1
[   12.016667] pci 0000:00:16.2: [8086:3432] type 00 class 0x088000

[   12.016688] pci 0000:00:16.2: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.2
[   12.016853] pci 0000:00:16.3: [8086:3433] type 00 class 0x088000

[   12.016874] pci 0000:00:16.3: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.3
[   12.017039] pci 0000:00:16.4: [8086:3429] type 00 class 0x088000

[   12.017060] pci 0000:00:16.4: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.4
[   12.017226] pci 0000:00:16.5: [8086:342a] type 00 class 0x088000

[   12.017247] pci 0000:00:16.5: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.5
[   12.017411] pci 0000:00:16.6: [8086:342b] type 00 class 0x088000

[   12.017433] pci 0000:00:16.6: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.6
[   12.017597] pci 0000:00:16.7: [8086:342c] type 00 class 0x088000

[   12.017618] pci 0000:00:16.7: reg 0x10: [mem 0x00000000-0x00003fff 64bit]

(XEN) PCI add device 0000:00:16.7
[   12.017784] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c0300

[   12.017854] pci 0000:00:1a.0: reg 0x20: [io  0x1800-0x181f]

[   12.017963] pci 0000:00:1a.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.0
[   12.018018] pci 0000:00:1a.1: [8086:3a38] type 00 class 0x0c0300

[   12.018088] pci 0000:00:1a.1: reg 0x20: [io  0x1820-0x183f]

[   12.018207] pci 0000:00:1a.1: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.1
[   12.018277] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0320

[   12.018311] pci 0000:00:1a.7: reg 0x10: [mem 0xec604000-0xec6043ff]

[   12.018451] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold

[   12.018498] pci 0000:00:1a.7: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1a.7
[   12.018558] pci 0000:00:1b.0: [8086:3a3e] type 00 class 0x040300

[   12.018585] pci 0000:00:1b.0: reg 0x10: [mem 0xec600000-0xec603fff 64bit]

[   12.018704] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold

(XEN) PCI add device 0000:00:1b.0
[   12.018798] pci 0000:00:1c.0: [8086:3a40] type 01 class 0x060400

[   12.018912] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold

[   12.018962] pci 0000:00:1c.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.0
[   12.019022] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x060400

[   12.019158] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold

[   12.019209] pci 0000:00:1c.4: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.4
[   12.019263] pci 0000:00:1c.5: [8086:3a4a] type 01 class 0x060400

[   12.019385] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold

[   12.019436] pci 0000:00:1c.5: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1c.5
[   12.019493] pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300

[   12.019562] pci 0000:00:1d.0: reg 0x20: [io  0x1840-0x185f]

[   12.019670] pci 0000:00:1d.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.0
[   12.019724] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300

[   12.019794] pci 0000:00:1d.1: reg 0x20: [io  0x1860-0x187f]

[   12.019902] pci 0000:00:1d.1: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.1
[   12.019960] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300

[   12.020055] pci 0000:00:1d.2: reg 0x20: [io  0x1880-0x189f]

[   12.020185] pci 0000:00:1d.2: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.2
[   12.020243] pci 0000:00:1d.3: [8086:3a39] type 00 class 0x0c0300

[   12.020313] pci 0000:00:1d.3: reg 0x20: [io  0x18a0-0x18bf]

[   12.020422] pci 0000:00:1d.3: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.3
[   12.020490] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320

[   12.020524] pci 0000:00:1d.7: reg 0x10: [mem 0xec605000-0xec6053ff]

[   12.020664] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold

[   12.020711] pci 0000:00:1d.7: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1d.7
[   12.020764] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401

[   12.020878] pci 0000:00:1e.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:00:1e.0
[   12.020932] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x060100

(XEN) PCI add device 0000:00:1f.0
[   12.021167] pci 0000:00:1f.2: [8086:3a22] type 00 class 0x010601

[   12.021199] pci 0000:00:1f.2: reg 0x10: [io  0x18f0-0x18f7]

[   12.021212] pci 0000:00:1f.2: reg 0x14: [io  0x18e4-0x18e7]

[   12.021225] pci 0000:00:1f.2: reg 0x18: [io  0x18e8-0x18ef]

[   12.021238] pci 0000:00:1f.2: reg 0x1c: [io  0x18e0-0x18e3]

[   12.021252] pci 0000:00:1f.2: reg 0x20: [io  0x18c0-0x18df]

[   12.021265] pci 0000:00:1f.2: reg 0x24: [mem 0xec606000-0xec6067ff]

[   12.021343] pci 0000:00:1f.2: PME# supported from D3hot

(XEN) PCI add device 0000:00:1f.2
[   12.021433] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500

[   12.021459] pci 0000:00:1f.3: reg 0x10: [mem 0xec607000-0xec6070ff 64bit]

[   12.021494] pci 0000:00:1f.3: reg 0x20: [io  0x1100-0x111f]

(XEN) PCI add device 0000:00:1f.3
[   12.021686] pci 0000:01:00.0: [11ab:6485] type 00 class 0x010400

[   12.021730] pci 0000:01:00.0: reg 0x18: [io  0x2000-0x207f]

[   12.021761] pci 0000:01:00.0: reg 0x20: [mem 0xec000000-0xec00ffff 64bit]

[   12.021776] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0003ffff pref]

[   12.021839] pci 0000:01:00.0: supports D1

[   12.021842] pci 0000:01:00.0: PME# supported from D0 D1 D3hot

[   12.021874] pci 0000:01:00.0: System wakeup disabled by ACPI

(XEN) PCI add device 0000:01:00.0
[   12.132501] pci 0000:00:01.0: PCI bridge to [bus 01]

[   12.132513] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]

[   12.132523] pci 0000:00:01.0:   bridge window [mem 0xec000000-0xec0fffff]

[   12.132640] pci 0000:02:00.0: [10de:05fe] type 00 class 0x030000

[   12[   12.916581] tg3 0000:05:00.0: no hotplug settings from platform

[   12.916719] pci_bus 0000:07: Allocating resources

[   12.916778] pcieport 0000:06:00.0: bridge window [io 0x1000-0x0fff] 
to [bus 07-09] add_size 1000

[   12.916783] pcieport 0000:06:00.0: bridge window [mem 
0x00100000-0x000fffff 64bit pref] to [bus 07-09] add_size 200000

[   12.916788] pcieport 0000:06:00.0: res[15]=[mem 0x00100000-0x000fffff 
64bit pref] get_res_add_size add_size 200000

[   12.916793] pcieport 0000:06:00.0: res[13]=[io  0x1000-0x0fff] 
get_res_add_size add_size 1000

[   12.916799] pcieport 0000:06:00.0: BAR 15: assigned [mem 
0xc0600000-0xc07fffff 64bit pref]

[   12.916802] pcieport 0000:06:00.0: BAR 13: assigned [io 0x7000-0x7fff]

[   12.916825] pcieport 0000:06:00.0: no hotplug settings from platform

[   12.916848] pcieport 0000:07:02.0: no hotplug settings from platform

[   12.916870] pcieport 0000:07:03.0: no hotplug settings from platform

[   12.916885] tg3 0000:09:00.0: no hotplug settings from platform

[   13.000128] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

[   13.000151] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[   13.000172] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[   13.003705] ata2.00: ATAPI: HL-DT-STDVD-RAM GH60N, NY02, max UDMA/100

[   13.006112] ata1.00: ATA-8: WDC WD3000BLFS-08YBU0, 04.04V04, max UDMA/100

[   13.006119] ata1.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 
31/32), AA

[   13.006464] ata3.00: ATA-8: WDC WD3000BLFS-08YBU0, 04.04V04, max UDMA/100

[   13.006471] ata3.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 
31/32), AA

[   13.008025] ata2.00: configured for UDMA/100

[   13.012115] ata1.00: configured for UDMA/100

[   13.012249] scsi 1:0:0:0: Direct-Access     ATA      WDC WD3000BLFS-0 
4V04 PQ: 0 ANSI: 5

[   13.013518] ata3.00: configured for UDMA/100

[   13.015809] scsi 2:0:0:0: CD-ROM            HL-DT-ST DVD-RAM GH60N    
NY02 PQ: 0 ANSI: 5

[   13.025883] scsi 3:0:0:0: Direct-Access     ATA      WDC WD3000BLFS-0 
4V04 PQ: 0 ANSI: 5

[   13.028500] sd 1:0:0:0: [sda] 586072368 512-byte logical blocks: (300 
GB/279 GiB)

[   13.028604] sd 1:0:0:0: [sda] Write Protect is off

[   13.028609] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00

[   13.028651] sd 1:0:0:0: [sda] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA

[   13.031377] sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw 
xa/form2 cdda tray

[   13.031386] cdrom: Uniform CD-ROM driver Revision: 3.20

[   13.031517] sr 2:0:0:0: Attached scsi CD-ROM sr0

[   13.031631] sd 3:0:0:0: [sdb] 586072368 512-byte logical blocks: (300 
GB/279 GiB)

[   13.031724] sd 3:0:0:0: [sdb] Write Protect is off

[   13.031728] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00

[   13.031768] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA

[   13.032021] sd 1:0:0:0: Attached scsi generic sg0 type 0

[   13.032079] sr 2:0:0:0: Attached scsi generic sg1 type 5

[   13.032124] sd 3:0:0:0: Attached scsi generic sg2 type 0

[   13.037844]  sda: sda1 sda2

[   13.038211] sd 1:0:0:0: [sda] Attached SCSI disk

[   13.043673]  sdb: sdb1 sdb2

[   13.043983] sd 3:0:0:0: [sdb] Attached SCSI disk

[   13.121238] md: bind<sdb2>

[   13.122241] md: bind<sda1>

[   13.132958] md: bind<sda2>

[   13.135006] md: raid1 personality registered for level 1

[   13.135363] md/raid1:md1: active with 2 out of 2 mirrors

[   13.135437] created bitmap (3 pages) for device md1

[   13.135600] md1: bitmap initialized from disk: read 1 pages, set 0 of 
4462 bits

[   13.140431] md1: detected capacity change from 0 to 299396562944

[   13.143731]  md1: unknown partition table

[   13.152229] md: bind<sdb1>

[   13.154307] md/raid1:md0: active with 2 out of 2 mirrors

[   13.154327] md0: detected capacity change from 0 to 536805376

[   13.160470]  md0: unknown partition table

[   13.232470] usb 1-4: New USB device found, idVendor=0bda, idProduct=0181

[   13.232480] usb 1-4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[   13.232486] usb 1-4: Product: USB2.0-CRW

[   13.232491] usb 1-4: Manufacturer: Generic

[   13.232495] usb 1-4: SerialNumber: 20060413092100000

[   13.239350] usb-storage 1-4:1.0: USB Mass Storage device detected

[   13.239478] scsi7 : usb-storage 1-4:1.0

[   13.239535] usbcore: registered new interface driver usb-storage

[   13.532137] usb 7-2: new low-speed USB device number 2 using uhci_hcd

[   13.923165] usb 7-2: New USB device found, idVendor=17ef, idProduct=6009

[   13.923174] usb 7-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0

[   13.923181] usb 7-2: Product: ThinkPad USB Keyboard with TrackPoint

[   13.923186] usb 7-2: Manufacturer: Lite-On Technology Corp.

[   13.927205] hidraw: raw HID events driver (C) Jiri Kosina

[   13.972212] usbcore: registered new interface driver usbhid

[   13.972215] usbhid: USB HID core driver

[   13.972906] input: Lite-On Technology Corp. ThinkPad USB Keyboard 
with TrackPoint as 
/devices/pci0000:00/0000:00:1d.2/usb7/7-2/7-2:1.0/0003:17EF:6009.0001/input/input2

[   13.972969] lenovo_tpkbd 0003:17EF:6009.0001: input,hidraw0: USB HID 
v1.10 Keyboard [Lite-On Technology Corp. ThinkPad USB Keyboard with 
TrackPoint] on usb-0000:00:1d.2-2/input0

[   13.990235] input: Lite-On Technology Corp. ThinkPad USB Keyboard 
with TrackPoint as 
/devices/pci0000:00/0000:00:1d.2/usb7/7-2/7-2:1.1/0003:17EF:6009.0002/input/input3

[   13.990392] lenovo_tpkbd 0003:17EF:6009.0002: input,hiddev0,hidraw1: 
USB HID v1.10 Mouse [Lite-On Technology Corp. ThinkPad USB Keyboard with 
TrackPoint] on usb-0000:00:1d.2-2/input1

[   14.239376] scsi 7:0:0:0: Direct-Access     Generic- Compact Flash    
1.00 PQ: 0 ANSI: 0 CCS

[   14.242371] scsi 7:0:0:1: Direct-Access     Generic- SM/xD-Picture    
1.00 PQ: 0 ANSI: 0 CCS

[   14.245371] scsi 7:0:0:2: Direct-Access     Generic- SD/MMC           
1.00 PQ: 0 ANSI: 0 CCS

[   14.248495] scsi 7:0:0:3: Direct-Access     Generic- MS/MS-Pro/HG     
1.00 PQ: 0 ANSI: 0 CCS

[   14.248736] sd 7:0:0:0: Attached scsi generic sg3 type 0

[   14.248893] sd 7:0:0:1: Attached scsi generic sg4 type 0

[   14.249071] sd 7:0:0:2: Attached scsi generic sg5 type 0

[   14.249291] sd 7:0:0:3: Attached scsi generic sg6 type 0

[   14.340337] random: nonblocking pool is initialized

[   14.362979] sd 7:0:0:0: [sdc] Attached SCSI removable disk

[   14.365478] sd 7:0:0:1: [sdd] Attached SCSI removable disk

[   14.368123] sd 7:0:0:2: [sde] Attached SCSI removable disk

[   14.370608] sd 7:0:0:3: [sdf] Attached SCSI removable disk

[   17.556123] scsi0 : mvsas

[   21.183838] device-mapper: uevent: version 1.0.3

[   21.183918] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) 
initialised: dm-devel@redhat.com

[   21.448437] PM: Starting manual resume from disk

[   21.448452] PM: Hibernation image partition 253:1 present

[   21.448455] PM: Looking for hibernation image.

[   21.448623] PM: Image not found (code -22)

[   21.448634] PM: Hibernation image not present or could not be loaded.

[   21.467950] EXT4-fs (dm-0): mounted filesystem with ordered data 
mode. Opts: (null)


INIT: version 2.88 booting


[info] Using makefile-style concurrent boot in runlevel S.

calling: info

[....] Starting the hotplug events dispatcher: udevd[   22.384236] 
systemd-udevd[387]: starting version 215

[?25l[?1c7[ ok 8[?25h[?0c.

[....] Synthesizing the initial hotplug events...calling: trigger

[?25l[?1c7[ ok 8[?25h[?0cdone.

[....] Waiting for /dev to be fully populated...calling: settle

[   22.771824] dca service started, version 1.12.1

[   22.787412] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4

[   22.793212] Monitor-Mwait will be used to enter C-1 state

[   22.793243] Monitor-Mwait will be used to enter C-3 state

[   22.793262] Monitor-Mwait will be used to enter C-3 state

[   22.796020] Warning: Processor Platform Limit not supported.

[   22.798559] EDAC MC: Ver: 3.0.0

[   22.819933] ioatdma: Intel(R) QuickData Technology Driver 4.00

[   22.819978] ioatdma 0000:00:16.0: enabling device (0000 -> 0002)

[   22.820180] ioatdma 0000:00:16.0: can't derive routing for PCI INT A

[   22.820184] ioatdma 0000:00:16.0: PCI INT A: no GSI

[   22.820398] ioatdma 0000:00:16.1: enabling device (0000 -> 0002)

[   22.820569] ioatdma 0000:00:16.1: can't derive routing for PCI INT B

[   22.820572] ioatdma 0000:00:16.1: PCI INT B: no GSI

[   22.820767] ioatdma 0000:00:16.2: enabling device (0000 -> 0002)

[   22.820938] ioatdma 0000:00:16.2: can't derive routing for PCI INT C

[   22.820941] ioatdma 0000:00:16.2: PCI INT C: no GSI

[   22.821127] ioatdma 0000:00:16.3: enabling device (0000 -> 0002)

[   22.821320] ioatdma 0000:00:16.3: can't derive routing for PCI INT D

[   22.821324] ioatdma 0000:00:16.3: PCI INT D: no GSI

[   22.821529] ioatdma 0000:00:16.4: enabling device (0000 -> 0002)

[   22.821700] ioatdma 0000:00:16.4: can't derive routing for PCI INT A

[   22.821704] ioatdma 0000:00:16.4: PCI INT A: no GSI

[   22.821891] ioatdma 0000:00:16.5: enabling device (0000 -> 0002)

[   22.822061] ioatdma 0000:00:16.5: can't derive routing for PCI INT B

[   22.822065] ioatdma 0000:00:16.5: PCI INT B: no GSI

[   22.822261] ioatdma 0000:00:16.6: enabling device (0000 -> 0002)

[   22.822432] ioatdma 0000:00:16.6: can't derive routing for PCI INT C

[   22.822435] ioatdma 0000:00:16.6: PCI INT C: no GSI

[   22.822621] ioatdma 0000:00:16.7: enabling device (0000 -> 0002)

[   22.822792] ioatdma 0000:00:16.7: can't derive routing for PCI INT D

[   22.822796] ioatdma 0000:00:16.7: PCI INT D: no GSI

[   22.829482] xen: registering gsi 16 triggering 0 polarity 1

[   22.829489] Already setup the GSI :16

[   22.830810] input: Power Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0C:00/input/input4

[   22.830818] ACPI: Power Button [PWRB]

[   22.830857] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5

[   22.830861] ACPI: Power Button [PWRF]

[   22.840696] wmi: Mapper loaded

[   22.844439] tpm_tis 00:00: 1.2 TPM (device-id 0x1002, rev-id 2)

[   22.908910] ACPI Warning: SystemIO range 
0x0000000000001028-0x000000000000102f conflicts with OpRegion 
0x0000000000001000-0x000000000000102f (\_SB_.PCI0.LPC0.PMIO) 
(20140424/utaddress-258)

[   22.908920] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   22.908927] ACPI Warning: SystemIO range 
0x00000000000011b0-0x00000000000011bf conflicts with OpRegion 
0x0000000000001180-0x00000000000011bf (\_SB_.PCI0.LPC0.GPOX) 
(20140424/utaddress-258)

[   22.908934] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   22.908937] ACPI Warning: SystemIO range 
0x0000000000001180-0x00000000000011af conflicts with OpRegion 
0x0000000000001180-0x00000000000011bf (\_SB_.PCI0.LPC0.GPOX) 
(20140424/utaddress-258)

[   22.908944] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[   22.908947] lpc_ich: Resource conflict(s) found affecting gpio_ich

[   22.925327] xen: registering gsi 17 triggering 0 polarity 1

[   22.925334] Already setup the GSI :17

[   22.925356] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt

[   23.054556] SSE version of gcm_enc/dec engaged.

[   23.057659] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)

[   23.142657] alg: No test for crc32 (crc32-pclmul)

[   23.188538] iTCO_vendor_support: vendor-support=0

[   23.189004] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11

[   23.189039] iTCO_wdt: Found a ICH10 TCO device (Version=2, 
TCOBASE=0x1060)

[   23.189153] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

[   23.253301] sound hdaudioC0D2: autoconfig: line_outs=4 
(0x12/0x16/0x24/0x25/0x0) type:line

[   23.253315] sound hdaudioC0D2:    speaker_outs=1 (0x13/0x0/0x0/0x0/0x0)

[   23.253318] sound hdaudioC0D2:    hp_outs=1 (0x11/0x0/0x0/0x0/0x0)

[   23.253321] sound hdaudioC0D2:    mono: mono_out=0x0

[   23.253324] sound hdaudioC0D2:    dig-out=0x1b/0x0

[   23.253326] sound hdaudioC0D2:    inputs:

[   23.253329] sound hdaudioC0D2:      Front Mic=0x14

[   23.253332] sound hdaudioC0D2:      Rear Mic=0x17

[   23.253334] sound hdaudioC0D2:      Line=0x15

[   23.253336] sound hdaudioC0D2:    dig-in=0x1c

[   23.265840] input: HDA Digital PCBeep as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D2/input7

[   23.266180] input: HDA Intel Front Mic as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input8

[   23.266275] input: HDA Intel Rear Mic as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input9

[   23.266339] input: HDA Intel Line as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input10

[   23.266414] input: HDA Intel Line Out Front as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input11

[   23.266493] input: HDA Intel Line Out Surround as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input12

[   23.267432] input: HDA Intel Line Out CLFE as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input13

[   23.267659] input: HDA Intel Line Out Side as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input14

[   23.267728] input: HDA Intel Front Headphone as 
/devices/pci0000:00/0000:00:1b.0/sound/card0/input15

[   24.852132] tpm_tis 00:00: tpm_transmit: tpm_send: error -62

[   24.852148] tpm_tis 00:00: A TPM error (-62) occurred attempting to 
determine the timeouts

[   24.864212] tpm_tis 00:00: Adjusting TPM timeout parameters.

[   24.912148] tpm_tis 00:00: TPM is disabled/deactivated (0x6)

[?25l[?1c7[ ok 8[?25h[?0cdone.

[....] Setting parameters of disc: (none)[?25l[?1c7[ 
ok 8[?25h[?0c.


[....] Setting preliminary keymap...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[   25.517579] EXT4-fs (dm-0): re-mounted. Opts: (null)

[....] Checking root file system...fsck from util-linux 2.25.1


/dev/mapper/vg_g2-lv_g2_root: clean, 275985/1048576 files, 
3651430/4194304 blocks


[?25l[?1c7[ ok 8[?25h[?0cdone.


[   25.654371] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro

[   25.937101] xen_acpi_processor: Uploading Xen processor PM info

(XEN) cpu0 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) Monitor-Mwait will be used to enter C1 state
(XEN) Monitor-Mwait will be used to enter C3 state
(XEN) CPU0: 0000000000000000, default_idle+0/0x7b
(XEN) cpu1 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) CPU1: default_idle+0/0x7b, acpi_processor_idle+0/0x531
(XEN) cpu2 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) CPU2: default_idle+0/0x7b, acpi_processor_idle+0/0x531
(XEN) cpu3 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) CPU3: default_idle+0/0x7b, acpi_processor_idle+0/0x531
(XEN) cpu4 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) CPU4: default_idle+0/0x7b, acpi_processor_idle+0/0x531
(XEN) cpu5 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) CPU5: default_idle+0/0x7b, acpi_processor_idle+0/0x531
(XEN) cpu6 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) No CPU ID for APIC ID 0x6
(XEN) cpu7 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) cpu8 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) cpu9 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN) cpu10 cx acpi info:
(XEN)     count = 3
(XEN)     flags: bm_cntl[0], bm_chk[1], has_cst[1],
(XEN)            pwr_setup_done[1], bm_rld_set[0]
(XEN)     states[0]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0
(XEN)         type    = 1
(XEN)         latency = 1
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[1]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x10
(XEN)         type    = 3
(XEN)         latency = 64
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
(XEN)     states[2]:
(XEN)         reg.space_id = 0x7f
(XEN)         reg.bit_width = 0x1
(XEN)         reg.bit_offset = 0x2
(XEN)         reg.access_size = 0
(XEN)         reg.address = 0x20
(XEN)         type    = 3
(XEN)         latency = 96
(XEN)         power   = 0
(XEN)         dp(@0x0000000000000000)
[   25.967008] xen_pciback: backend is vpci

[   25.990298] fuse init (API version 7.23)

[info] Loading kernel module xen-acpi-processor.


[info] Loading kernel module xen-pciback.


[info] Loading kernel module fuse.


[....] Cleaning up temporary files... 
/tmp[?25l[?1c7[ ok 8[?25h[?0c.


[....] Generating udev events for MD 
arrays...[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Setting up LVM Volume Groups...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Activating lvm and md swap...[   26.642119] Adding 2097148k swap 
on /dev/mapper/vg_g2-lv_g2_swap.  Priority:-1 extents:1 across:2097148k FS

[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Checking file systems...fsck from util-linux 2.25.1


/dev/md0: clean, 334/131072 files, 74860/524224 blocks


[?25l[?1c7[ ok 8[?25h[?0cdone.


[   26.948583] EXT4-fs (md0): mounting ext3 file system using the ext4 
subsystem

[   26.960457] EXT4-fs (md0): mounted filesystem with ordered data mode. 
Opts: (null)

[....] Mounting local filesystems...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Activating swapfile swap...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Cleaning up temporary files...[?25l[?1c7[ ok 
8[?25h[?0c.


[....] Setting kernel variables ...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[   27.618140] Bridge firewalling registered

[   27.625153] device eth0 entered promiscuous mode

[   27.676402] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[   27.678737] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready

[....] Configuring network interfaces...


Waiting for br0 to get ready (MAXWAIT is 32 seconds).


[   30.819293] tg3 0000:05:00.0 eth0: Link is up at 1000 Mbps, full duplex

[   30.819310] tg3 0000:05:00.0 eth0: Flow control is on for TX and on 
for RX

[   30.819327] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[   30.819350] br0: port 1(eth0) entered forwarding state

[   30.819358] br0: port 1(eth0) entered forwarding state

[   30.819377] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready

[?25l[?1c7[ ok 8[?25h[?0cdone.


[....] Cleaning up temporary files...[?25l[?1c7[ ok 
8[?25h[?0c.


[info] Setting console screen modes.


setterm: cannot (un)set powersave mode: Inappropriate ioctl for device


[9;30][14;30][....] Setting up console font and 
keymap...[?25l[?1c7[ ok 8[?25h[?0cdone.


[   31.553893] ttyS0: LSR safety check engaged!

[   31.556055] ttyS0: LSR safety check engaged!

Loading the saved-state of the serial devices...


/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A


[....] Setting up X socket directories... /tmp/.X11-unix 
/tmp/.ICE-unix[?25l[?1c7[ ok 8[?25h[?0c.


[....] Setting sensors limits[?25l[?1c7[ ok 
8[?25h[?0c.



INIT: Entering runlevel: 2



[info] Using makefile-style concurrent boot in runlevel 2.


[....] Starting enhanced syslogd: 
rsyslogd[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting MD monitoring service: mdadm 
--monitor[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting ACPI services...[?25l[?1c7[ ok 
8[?25h[?0c.


[   32.114950] xen:xen_evtchn: Event-channel device installed

[....] Starting mouse interface server: 
gpm[?25l[?1c7[ ok 8[?25h[?0c.


[....] Starting periodic command scheduler: 
cron[?25l[?1c7[ ok 8[?25h[?0c.


[....] Loading cpufreq kernel modules...modprobe: ERROR: could not 
insert 'cpufreq_userspace': No such device


modprobe: ERROR: could not insert 'cpufreq_stats': Invalid argument


modprobe: ERROR: could not insert 'cpufreq_powersave': No such device


modprobe: ERROR: could not insert 'cpufreq_conservative': No such device


[?25l[?1c7[ ok 8[?25h[?0cdone (none).


[....] CPUFreq Utilities: Setting ondemand CPUFreq governor...disabled, 
governor not available...[?25l[?1c7[ ok 
8[?25h[?0cdone.


[....] Starting system message bus: dbus[?25l[?1c7[ 
ok 8[?25h[?0c.


[....] Starting OpenBSD Secure Shell server: 
sshd[?25l[?1c7[ ok 8[?25h[?0c.


Starting /usr/local/sbin/oxenstored...


Setting domain 0 name, domid and JSON config...


Done setting up Dom0


Starting xenconsoled...


Starting QEMU as disk backend for dom0


[9;0][14;0]

[   36.119927] pciback 0000:02:00.0: seizing device

[   36.119991] pciback 0000:02:00.0: enabling device (0004 -> 0007)

[   36.120076] xen: registering gsi 16 triggering 0 polarity 1

[   36.120085] Already setup the GSI :16

libxl: warning: libxl_pci.c:706:libxl__device_pci_assignable_add: 
0000:02:00.0 not bound to a driver, will not be rebound.




Debian GNU/Linux jessie/sid g2 hvc0



g2 login: [   45.856185] br0: port 1(eth0) entered forwarding state

(XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input 
to DOM0)
(XEN) IRQ information:
(XEN)    IRQ:   0 affinity:01 vec:f0 type=IO-APIC-edge status=00000000 
timer_interrupt()
(XEN)    IRQ:   1 affinity:01 vec:30 type=IO-APIC-edge status=00000014 
in-flight=0 domain-list=0:  1(---),
(XEN)    IRQ:   3 affinity:01 vec:38 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   4 affinity:01 vec:f1 type=IO-APIC-edge status=00000000 
ns16550_interrupt()
(XEN)    IRQ:   5 affinity:01 vec:40 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   6 affinity:01 vec:48 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0:  6(---),
(XEN)    IRQ:   7 affinity:01 vec:50 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:   8 affinity:01 vec:58 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0:  8(---),
(XEN)    IRQ:   9 affinity:01 vec:60 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0:  9(---),
(XEN)    IRQ:  10 affinity:01 vec:68 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  11 affinity:01 vec:70 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  12 affinity:01 vec:78 type=IO-APIC-edge status=00000010 
in-flight=0 domain-list=0: 12(---),
(XEN)    IRQ:  13 affinity:3f vec:88 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  14 affinity:01 vec:90 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  15 affinity:01 vec:98 type=IO-APIC-edge status=00000002 
mapped, unbound
(XEN)    IRQ:  16 affinity:01 vec:a0 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 16(---),
(XEN)    IRQ:  17 affinity:01 vec:a8 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 17(---),
(XEN)    IRQ:  18 affinity:01 vec:b0 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 18(---),
(XEN)    IRQ:  19 affinity:01 vec:b8 type=IO-APIC-level status=00000010 
in-flight=0 domain-list=0: 19(---),
(XEN)    IRQ:  24 affinity:3f vec:28 type=DMA_MSI status=00000000 
iommu_page_fault()
(XEN)    IRQ:  25 affinity:01 vec:c0 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:279(---),
(XEN)    IRQ:  26 affinity:01 vec:c8 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:278(---),
(XEN)    IRQ:  27 affinity:01 vec:d0 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:277(---),
(XEN)    IRQ:  28 affinity:01 vec:d8 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:276(---),
(XEN)    IRQ:  29 affinity:01 vec:21 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:275(---),
(XEN)    IRQ:  30 affinity:01 vec:29 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:274(---),
(XEN)    IRQ:  31 affinity:3f vec:31 type=PCI-MSI status=00000002 
mapped, unbound
(XEN)    IRQ:  32 affinity:3f vec:39 type=PCI-MSI status=00000002 
mapped, unbound
(XEN)    IRQ:  33 affinity:01 vec:49 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:271(---),
(XEN)    IRQ:  34 affinity:01 vec:51 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:270(---),
(XEN)    IRQ:  35 affinity:01 vec:59 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:269(---),
(XEN)    IRQ:  36 affinity:01 vec:61 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:268(---),
(XEN)    IRQ:  37 affinity:01 vec:69 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:267(---),
(XEN)    IRQ:  38 affinity:01 vec:71 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:266(---),
(XEN)    IRQ:  39 affinity:01 vec:79 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:265(---),
(XEN)    IRQ:  40 affinity:01 vec:81 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:264(---),
(XEN)    IRQ:  41 affinity:01 vec:89 type=PCI-MSI/-X status=00000010 
in-flight=0 domain-list=0:263(---),
(XEN)    IRQ:  42 affinity:01 vec:91 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:262(---),
(XEN)    IRQ:  43 affinity:01 vec:99 type=PCI-MSI status=00000010 
in-flight=0 domain-list=0:261(---),
(XEN) Direct vector information:
(XEN)    0x20 -> irq_move_cleanup_interrupt()
(XEN)    0xf2 -> cmci_interrupt()
(XEN)    0xf3 -> intel_thermal_interrupt()
(XEN)    0xf9 -> pmu_apic_interrupt()
(XEN)    0xfa -> apic_timer_interrupt()
(XEN)    0xfb -> call_function_interrupt()
(XEN)    0xfc -> event_check_interrupt()
(XEN)    0xfd -> invalidate_interrupt()
(XEN)    0xfe -> error_interrupt()
(XEN)    0xff -> spurious_interrupt()
(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 48:
(XEN)       Apic 0x00, Pin  1: vec=30 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  3 Vec 56:
(XEN)       Apic 0x00, Pin  3: vec=38 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 64:
(XEN)       Apic 0x00, Pin  5: vec=40 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  6 Vec 72:
(XEN)       Apic 0x00, Pin  6: vec=48 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  7 Vec 80:
(XEN)       Apic 0x00, Pin  7: vec=50 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  8 Vec 88:
(XEN)       Apic 0x00, Pin  8: vec=58 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  9 Vec 96:
(XEN)       Apic 0x00, Pin  9: vec=60 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 10 Vec104:
(XEN)       Apic 0x00, Pin 10: vec=68 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 11 Vec112:
(XEN)       Apic 0x00, Pin 11: vec=70 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 12 Vec120:
(XEN)       Apic 0x00, Pin 12: vec=78 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 13 Vec136:
(XEN)       Apic 0x00, Pin 13: vec=88 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=1 dest_id:63
(XEN)     IRQ 14 Vec144:
(XEN)       Apic 0x00, Pin 14: vec=90 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 15 Vec152:
(XEN)       Apic 0x00, Pin 15: vec=98 delivery=LoPri dest=L status=0 
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ 16 Vec160:
(XEN)       Apic 0x00, Pin 16: vec=a0 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 17 Vec168:
(XEN)       Apic 0x00, Pin 17: vec=a8 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 18 Vec176:
(XEN)       Apic 0x00, Pin 18: vec=b0 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN)     IRQ 19 Vec184:
(XEN)       Apic 0x00, Pin 19: vec=b8 delivery=LoPri dest=L status=0 
polarity=1 irr=0 trig=L mask=0 dest_id:1
(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:        C0
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00005664] method[  FFH] 
duration[4042540627]
(XEN)     C2:    type[C3] latency[064] usage[00000414] method[  FFH] 
duration[447258888]
(XEN)     C3:    type[C3] latency[096] usage[00002366] method[  FFH] 
duration[28183588810]
(XEN)    *C0:    usage[00008444] duration[26752178344]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[484210884] CC6[27943480555] CC7[0]
(XEN) ==cpu1==
(XEN) active state:        C3
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00002007] method[  FFH] 
duration[4316094103]
(XEN)     C2:    type[C3] latency[064] usage[00000179] method[  FFH] 
duration[430291017]
(XEN)    *C3:    type[C3] latency[096] usage[00000785] method[  FFH] 
duration[27543087914]
(XEN)     C0:    usage[00002971] duration[27136150937]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[498924899] CC6[26514562346] CC7[0]
(XEN) ==cpu2==
(XEN) active state:        C3
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00001925] method[  FFH] 
duration[3925569185]
(XEN)     C2:    type[C3] latency[064] usage[00000199] method[  FFH] 
duration[341001922]
(XEN)    *C3:    type[C3] latency[096] usage[00000761] method[  FFH] 
duration[27805737869]
(XEN)     C0:    usage[00002885] duration[27353411294]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[377373007] CC6[27202250545] CC7[0]
(XEN) ==cpu3==
(XEN) active state:        C3
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00001880] method[  FFH] 
duration[2679771477]
(XEN)     C2:    type[C3] latency[064] usage[00000229] method[  FFH] 
duration[188146428]
(XEN)    *C3:    type[C3] latency[096] usage[00001031] method[  FFH] 
duration[29498117979]
(XEN)     C0:    usage[00003140] duration[27059782098]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[254623106] CC6[28394085736] CC7[0]
(XEN) ==cpu4==
(XEN) active state:        C3
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00001756] method[  FFH] 
duration[2769254927]
(XEN)     C2:    type[C3] latency[064] usage[00000229] method[  FFH] 
duration[301480682]
(XEN)    *C3:    type[C3] latency[096] usage[00000859] method[  FFH] 
duration[28897863294]
(XEN)     C0:    usage[00002844] duration[27457318503]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[383731673] CC6[28101648533] CC7[0]
(XEN) ==cpu5==
(XEN) active state:        C3
(XEN) max_cstate:        C7
(XEN) states:
(XEN)     C1:    type[C1] latency[001] usage[00001570] method[  FFH] 
duration[3273775119]
(XEN)     C2:    type[C3] latency[064] usage[00000265] method[  FFH] 
duration[367342058]
(XEN)    *C3:    type[C3] latency[096] usage[00000719] method[  FFH] 
duration[28591526276]
(XEN)     C0:    usage[00002554] duration[27193372517]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
(XEN) CC3[470602725] CC6[29075968196] CC7[0]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 01:30:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 01: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 1Xt4xK-0000ez-H3; Tue, 25 Nov 2014 01:30:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1Xt4xJ-0000eu-2e
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 01:30:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CE/A3-15461-4ABD3745; Tue, 25 Nov 2014 01:30:12 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416879009!12280783!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14538 invoked from network); 25 Nov 2014 01:30:10 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-15.tower-21.messagelabs.com with SMTP;
	25 Nov 2014 01:30:10 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43920750"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 25 Nov 2014 09:26:50 +0800
Received: from G08CNEXCHPEKD01.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAP1TlOA002197;
	Tue, 25 Nov 2014 09:29:47 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Tue, 25 Nov 2014 09:30:08 +0800
Message-ID: <5473DC21.6010709@cn.fujitsu.com>
Date: Tue, 25 Nov 2014 09:32:17 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<qemu-devel@nongnu.org>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
X-Originating-IP: [10.167.226.91]
Cc: mst@redhat.com, xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>> CC'ing Paolo.
>>>
>>>
>>> Wen,
>>> thanks for the logs.
>>>
>>> I investigated a little bit and it seems to me that the bug occurs when
>>> QEMU tries to unmap only a portion of a memory region previously mapped.
>>> That doesn't work with xen-mapcache.
>>>
>>> See these logs for example:
>>>
>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>>
>> Sorry the logs don't quite match, it was supposed to be:
>>
>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> 
> It looks like the problem is caused by iov_discard_front, called by
> virtio_net_handle_ctrl. By changing iov_base after the sg has already
> been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> because the corresponding cpu_physical_memory_unmap will only unmap a
> portion of the original sg.  On Xen the problem is worse because
> xen-mapcache aborts.

This patch works for me.

Thanks
Wen Congyang

> 
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 2ac6ce5..b2b5c2d 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>      struct iovec *iov;
>      unsigned int iov_cnt;
>  
> -    while (virtqueue_pop(vq, &elem)) {
> +    while (virtqueue_pop_nomap(vq, &elem)) {
>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
>              error_report("virtio-net ctrl missing headers");
> @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>  
>          iov = elem.out_sg;
>          iov_cnt = elem.out_num;
> -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> +
> +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> +
> +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          if (s != sizeof(ctrl)) {
>              status = VIRTIO_NET_ERR;
>          } else if (ctrl.class == VIRTIO_NET_CTRL_RX) {
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 3e4b70c..6a4bd3a 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -446,7 +446,7 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
>      }
>  }
>  
> -int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem)
>  {
>      unsigned int i, head, max;
>      hwaddr desc_pa = vq->vring.desc;
> @@ -505,9 +505,6 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
>          }
>      } while ((i = virtqueue_next_desc(desc_pa, i, max)) != max);
>  
> -    /* Now map what we have collected */
> -    virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> -    virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
>  
>      elem->index = head;
>  
> @@ -517,6 +514,16 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
>      return elem->in_num + elem->out_num;
>  }
>  
> +int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> +{
> +    int rc = virtqueue_pop_nomap(vq, elem);
> +    if (rc > 0) {
> +        virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> +        virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
> +    }
> +    return rc;
> +}
> +
>  /* virtio device */
>  static void virtio_notify_vector(VirtIODevice *vdev, uint16_t vector)
>  {
> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> index 3e54e90..40a3977 100644
> --- a/include/hw/virtio/virtio.h
> +++ b/include/hw/virtio/virtio.h
> @@ -174,6 +174,7 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
>  void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
>      size_t num_sg, int is_write);
>  int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem);
> +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem);
>  int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes,
>                            unsigned int out_bytes);
>  void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes,
> .
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 01:30:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 01: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 1Xt4xK-0000ez-H3; Tue, 25 Nov 2014 01:30:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wency@cn.fujitsu.com>) id 1Xt4xJ-0000eu-2e
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 01:30:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CE/A3-15461-4ABD3745; Tue, 25 Nov 2014 01:30:12 +0000
X-Env-Sender: wency@cn.fujitsu.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416879009!12280783!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14538 invoked from network); 25 Nov 2014 01:30:10 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-15.tower-21.messagelabs.com with SMTP;
	25 Nov 2014 01:30:10 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="43920750"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 25 Nov 2014 09:26:50 +0800
Received: from G08CNEXCHPEKD01.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAP1TlOA002197;
	Tue, 25 Nov 2014 09:29:47 +0800
Received: from [10.167.226.91] (10.167.226.91) by
	G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Tue, 25 Nov 2014 09:30:08 +0800
Message-ID: <5473DC21.6010709@cn.fujitsu.com>
Date: Tue, 25 Nov 2014 09:32:17 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<qemu-devel@nongnu.org>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
X-Originating-IP: [10.167.226.91]
Cc: mst@redhat.com, xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>> CC'ing Paolo.
>>>
>>>
>>> Wen,
>>> thanks for the logs.
>>>
>>> I investigated a little bit and it seems to me that the bug occurs when
>>> QEMU tries to unmap only a portion of a memory region previously mapped.
>>> That doesn't work with xen-mapcache.
>>>
>>> See these logs for example:
>>>
>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>>
>> Sorry the logs don't quite match, it was supposed to be:
>>
>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> 
> It looks like the problem is caused by iov_discard_front, called by
> virtio_net_handle_ctrl. By changing iov_base after the sg has already
> been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> because the corresponding cpu_physical_memory_unmap will only unmap a
> portion of the original sg.  On Xen the problem is worse because
> xen-mapcache aborts.

This patch works for me.

Thanks
Wen Congyang

> 
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 2ac6ce5..b2b5c2d 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>      struct iovec *iov;
>      unsigned int iov_cnt;
>  
> -    while (virtqueue_pop(vq, &elem)) {
> +    while (virtqueue_pop_nomap(vq, &elem)) {
>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
>              error_report("virtio-net ctrl missing headers");
> @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>  
>          iov = elem.out_sg;
>          iov_cnt = elem.out_num;
> -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> +
> +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> +
> +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          if (s != sizeof(ctrl)) {
>              status = VIRTIO_NET_ERR;
>          } else if (ctrl.class == VIRTIO_NET_CTRL_RX) {
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 3e4b70c..6a4bd3a 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -446,7 +446,7 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
>      }
>  }
>  
> -int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem)
>  {
>      unsigned int i, head, max;
>      hwaddr desc_pa = vq->vring.desc;
> @@ -505,9 +505,6 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
>          }
>      } while ((i = virtqueue_next_desc(desc_pa, i, max)) != max);
>  
> -    /* Now map what we have collected */
> -    virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> -    virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
>  
>      elem->index = head;
>  
> @@ -517,6 +514,16 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
>      return elem->in_num + elem->out_num;
>  }
>  
> +int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
> +{
> +    int rc = virtqueue_pop_nomap(vq, elem);
> +    if (rc > 0) {
> +        virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
> +        virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
> +    }
> +    return rc;
> +}
> +
>  /* virtio device */
>  static void virtio_notify_vector(VirtIODevice *vdev, uint16_t vector)
>  {
> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> index 3e54e90..40a3977 100644
> --- a/include/hw/virtio/virtio.h
> +++ b/include/hw/virtio/virtio.h
> @@ -174,6 +174,7 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
>  void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
>      size_t num_sg, int is_write);
>  int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem);
> +int virtqueue_pop_nomap(VirtQueue *vq, VirtQueueElement *elem);
>  int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes,
>                            unsigned int out_bytes);
>  void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes,
> .
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 01:50:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 01: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.xen.org>)
	id 1Xt5Gp-0000rt-Jq; Tue, 25 Nov 2014 01:50:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Xt5Go-0000ro-KT
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 01:50:22 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	71/E6-16982-D50E3745; Tue, 25 Nov 2014 01:50:21 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416880219!13527923!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24332 invoked from network); 25 Nov 2014 01:50:20 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-31.messagelabs.com with SMTP;
	25 Nov 2014 01:50:20 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2014 17:50:17 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,452,1413270000"; d="scan'208";a="613468299"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by orsmga001.jf.intel.com with ESMTP; 24 Nov 2014 17:50:07 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 25 Nov 2014 09:47:38 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Tue, 25 Nov 2014 09:47:19 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest
Thread-Index: AQHQAxh40OPG79GTNEGKmyo8ZLinmpxlrM6AgACVuECAADyIKIAAqAiwgAAKSACACWrfYA==
Date: Tue, 25 Nov 2014 01:47:19 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF0EDB@SHSMSX104.ccr.corp.intel.com>
References: <20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
	<20141119095440.GA1409@deinos.phlegethon.org>
In-Reply-To: <20141119095440.GA1409@deinos.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li, 
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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

Tim Deegan wrote on 2014-11-19:
> At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
>> Tim Deegan wrote on 2014-11-18:
>>> In this case, the guest is entitled to _expect_ pagefaults on 1GB
>>> mappings if CPUID claims they are not supported.  That sounds like
>>> an unlikely thing for the guest to be relying on, but Xen itself
>>> does something similar for the SHOPT_FAST_FAULT_PATH (and now also
>>> for IOMMU entries for the deferred caching attribute updates).
>> 
>> Indeed. How about adding the software check (as Andrew mentioned)
>> firstly and leave the hardware problem (Actually, I don't think we
>> can solve it currently).
> 
> I don't think we should change the software path unless we can change
> the hardware behaviour too.  It's better to be consistent, and it
> saves us some cycles in the pt walker.

So if we don't need to add the software check, does this mean current patch is ok?

> 
> Cheers,
> 
> Tim.


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 01:50:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 01: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.xen.org>)
	id 1Xt5Gp-0000rt-Jq; Tue, 25 Nov 2014 01:50:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Xt5Go-0000ro-KT
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 01:50:22 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	71/E6-16982-D50E3745; Tue, 25 Nov 2014 01:50:21 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416880219!13527923!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24332 invoked from network); 25 Nov 2014 01:50:20 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-31.messagelabs.com with SMTP;
	25 Nov 2014 01:50:20 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2014 17:50:17 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,452,1413270000"; d="scan'208";a="613468299"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by orsmga001.jf.intel.com with ESMTP; 24 Nov 2014 17:50:07 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 25 Nov 2014 09:47:38 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Tue, 25 Nov 2014 09:47:19 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest
Thread-Index: AQHQAxh40OPG79GTNEGKmyo8ZLinmpxlrM6AgACVuECAADyIKIAAqAiwgAAKSACACWrfYA==
Date: Tue, 25 Nov 2014 01:47:19 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF0EDB@SHSMSX104.ccr.corp.intel.com>
References: <20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
	<20141119095440.GA1409@deinos.phlegethon.org>
In-Reply-To: <20141119095440.GA1409@deinos.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li, 
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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

Tim Deegan wrote on 2014-11-19:
> At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
>> Tim Deegan wrote on 2014-11-18:
>>> In this case, the guest is entitled to _expect_ pagefaults on 1GB
>>> mappings if CPUID claims they are not supported.  That sounds like
>>> an unlikely thing for the guest to be relying on, but Xen itself
>>> does something similar for the SHOPT_FAST_FAULT_PATH (and now also
>>> for IOMMU entries for the deferred caching attribute updates).
>> 
>> Indeed. How about adding the software check (as Andrew mentioned)
>> firstly and leave the hardware problem (Actually, I don't think we
>> can solve it currently).
> 
> I don't think we should change the software path unless we can change
> the hardware behaviour too.  It's better to be consistent, and it
> saves us some cycles in the pt walker.

So if we don't need to add the software check, does this mean current patch is ok?

> 
> Cheers,
> 
> Tim.


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 03:01:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 03:01:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xt6Mp-0001vP-Cg; Tue, 25 Nov 2014 03:00:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xt6Mo-0001vK-Ht
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 03:00:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	84/C3-09842-5D0F3745; Tue, 25 Nov 2014 03:00:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416884435!14984242!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32637 invoked from network); 25 Nov 2014 03:00:37 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 03:00:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAP30SkQ012186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 03:00:29 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30Q6E014853
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 03:00:27 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30QP5014844; Tue, 25 Nov 2014 03:00:26 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 19:00:26 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 24 Nov 2014 18:06:17 -0500
Message-Id: <1416870378-32481-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 1/2] xen/pci: Defer initialization of MSI ops
	on HVM guests until after x2APIC has been set up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hardware supports APIC virtualization we may decide not to use pirqs
and instead use APIC/x2APIC directly, meaning that we don't want to set
x86_msi.setup_msi_irqs and x86_msi.teardown_msi_irq to Xen-specific routines.
However, x2APIC is not set up by the time pci_xen_hvm_init() is called so we
need to postpone setting these ops until later, when we know which APIC mode
is used.

(Note that currently x2APIC is never initialized on HVM guests. This may
change in the future)

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/pci/xen.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 093f5f4..1370716 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -431,6 +431,14 @@ int __init pci_xen_init(void)
 	return 0;
 }
 
+#ifdef CONFIG_PCI_MSI
+void __init xen_msi_init(void)
+{
+	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
+	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
+}
+#endif
+
 int __init pci_xen_hvm_init(void)
 {
 	if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
@@ -445,8 +453,11 @@ int __init pci_xen_hvm_init(void)
 #endif
 
 #ifdef CONFIG_PCI_MSI
-	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
-	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
+	/*
+	 * We need to wait until after x2apic is initialized
+	 * before we can set MSI IRQ ops.
+	 */
+	x86_platform.apic_post_init = xen_msi_init;
 #endif
 	return 0;
 }
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 03:01:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 03:01:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xt6Mr-0001vb-SY; Tue, 25 Nov 2014 03:00:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xt6Mq-0001vT-0i
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 03:00:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8D/B6-15461-7D0F3745; Tue, 25 Nov 2014 03:00:39 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416884435!12282422!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30210 invoked from network); 25 Nov 2014 03:00:37 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 03:00:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAP30Tpo012187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 03:00:29 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30RQx014945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 03:00:28 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30RmP017867; Tue, 25 Nov 2014 03:00:27 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 19:00:27 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 24 Nov 2014 18:06:18 -0500
Message-Id: <1416870378-32481-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 2/2] xen/pci: Use APIC directly when APIC
	virtualization is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hardware supports APIC/x2APIC virtualization we don't need to use pirqs
for MSI handling and instead use APIC since most APIC accesses (MMIO or MSR)
will now be processed without VMEXITs.

As an example, netperf on the original code produces this profile
(collected wih 'xentrace -e 0x0008ffff -T 5'):

    342 cpu_change
    260 CPUID
  34638 HLT
  64067 INJ_VIRQ
  28374 INTR
  82733 INTR_WINDOW
     10 NPF
  24337 TRAP
 370610 vlapic_accept_pic_intr
 307528 VMENTRY
 307527 VMEXIT
 140998 VMMCALL
    127 wrap_buffer

After applying this patch the same test shows

    230 cpu_change
    260 CPUID
  36542 HLT
    174 INJ_VIRQ
  27250 INTR
    222 INTR_WINDOW
     20 NPF
  24999 TRAP
 381812 vlapic_accept_pic_intr
 166480 VMENTRY
 166479 VMEXIT
  77208 VMMCALL
     81 wrap_buffer

ApacheBench results (ab -n 10000 -c 200) improve by about 10%

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/include/asm/xen/cpuid.h | 91 ++++++++++++++++++++++++++++++++++++++++
 arch/x86/pci/xen.c               | 10 +++++
 2 files changed, 101 insertions(+)
 create mode 100644 arch/x86/include/asm/xen/cpuid.h

diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h
new file mode 100644
index 0000000..0d809e9
--- /dev/null
+++ b/arch/x86/include/asm/xen/cpuid.h
@@ -0,0 +1,91 @@
+/******************************************************************************
+ * arch-x86/cpuid.h
+ *
+ * CPUID interface to Xen.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2007 Citrix Systems, Inc.
+ *
+ * Authors:
+ *    Keir Fraser <keir@xen.org>
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_CPUID_H__
+#define __XEN_PUBLIC_ARCH_X86_CPUID_H__
+
+/*
+ * For compatibility with other hypervisor interfaces, the Xen cpuid leaves
+ * can be found at the first otherwise unused 0x100 aligned boundary starting
+ * from 0x40000000.
+ *
+ * e.g If viridian extensions are enabled for an HVM domain, the Xen cpuid
+ * leaves will start at 0x40000100
+ */
+
+#define XEN_CPUID_FIRST_LEAF 0x40000000
+#define XEN_CPUID_LEAF(i)    (XEN_CPUID_FIRST_LEAF + (i))
+
+/*
+ * Leaf 1 (0x40000x00)
+ * EAX: Largest Xen-information leaf. All leaves up to an including @EAX
+ *      are supported by the Xen host.
+ * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification
+ *      of a Xen host.
+ */
+#define XEN_CPUID_SIGNATURE_EBX 0x566e6558 /* "XenV" */
+#define XEN_CPUID_SIGNATURE_ECX 0x65584d4d /* "MMXe" */
+#define XEN_CPUID_SIGNATURE_EDX 0x4d4d566e /* "nVMM" */
+
+/*
+ * Leaf 2 (0x40000x01)
+ * EAX[31:16]: Xen major version.
+ * EAX[15: 0]: Xen minor version.
+ * EBX-EDX: Reserved (currently all zeroes).
+ */
+
+/*
+ * Leaf 3 (0x40000x02)
+ * EAX: Number of hypercall transfer pages. This register is always guaranteed
+ *      to specify one hypercall page.
+ * EBX: Base address of Xen-specific MSRs.
+ * ECX: Features 1. Unused bits are set to zero.
+ * EDX: Features 2. Unused bits are set to zero.
+ */
+
+/* Does the host support MMU_PT_UPDATE_PRESERVE_AD for this guest? */
+#define _XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD 0
+#define XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD  (1u<<0)
+
+/*
+ * Leaf 5 (0x40000x04)
+ * HVM-specific features
+ */
+
+/* EAX Features */
+/* Virtualized APIC registers */
+#define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0)
+/* Virtualized x2APIC accesses */
+#define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1)
+/* Memory mapped from other domains has valid IOMMU entries */
+#define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
+
+#define XEN_CPUID_MAX_NUM_LEAVES 4
+
+#endif /* __XEN_PUBLIC_ARCH_X86_CPUID_H__ */
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 1370716..e4a5bab 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -23,6 +23,8 @@
 #include <xen/features.h>
 #include <xen/events.h>
 #include <asm/xen/pci.h>
+#include <asm/xen/cpuid.h>
+#include <asm/apic.h>
 #include <asm/i8259.h>
 
 static int xen_pcifront_enable_irq(struct pci_dev *dev)
@@ -434,6 +436,14 @@ int __init pci_xen_init(void)
 #ifdef CONFIG_PCI_MSI
 void __init xen_msi_init(void)
 {
+	if (!disable_apic) {
+		uint32_t eax = cpuid_eax(xen_cpuid_base() + 4);
+
+		if (((eax & XEN_HVM_CPUID_X2APIC_VIRT) && x2apic_mode) ||
+		    ((eax & XEN_HVM_CPUID_APIC_ACCESS_VIRT) && cpu_has_apic))
+			return;
+	}
+
 	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
 	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
 }
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 03:01:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 03:01:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xt6Mt-0001vn-8c; Tue, 25 Nov 2014 03:00:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xt6Ms-0001vg-Jo
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 03:00:42 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	D9/D4-05632-9D0F3745; Tue, 25 Nov 2014 03:00:41 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416884439!13534117!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30297 invoked from network); 25 Nov 2014 03:00:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 03:00:41 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAP30SiI008926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 03:00:30 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30Q4q027729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 03:00:27 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30QTv017791; Tue, 25 Nov 2014 03:00:26 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 19:00:25 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 24 Nov 2014 18:06:16 -0500
Message-Id: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 0/2] xen/pci: Use APIC for MSIs when APIC
	virtualization is supported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v3:
* Explicitly include asm/apic.h in arch/x86/pci/xen.c for !CONFIG_SMP.

Changes in v2:
* New version of cpuid.h file from Xen tree (with a couple of style adjustments)
* Whitespace cleanup

Currently HVM guests handle MSI interrupts using pirqs/event channels, allowing
us to not issue APIC accesses that result in somewhat expensive VMEXITs. When
hardware supports APIC virtualization we don't need to use pirqs anymore
since now guest's APIC accesses can be handled by the processor itself.

There are two patches in this series:

1. Move setting of x86_msi ops to a later point. The reason for doing so is that
we currently decide whether or not to use pirqs before kernel had a chance to
see whether it should be using x2APIC instead of plain APIC. Since hardware may
virtualize either or both of those two we can only make pirqs vs. APIC selection
after kernel has settled down on which APIC version it will use. (Note that
currently x2APIC is not used by HVM guests so technically this patch is not
necessary. However, it probably makes sense to apply it now to avoid
forgetting to do it when we enable x2APIC).

2. Set x86_msi ops to use pirqs only when APIC virtualization is not available.
The commit message describes performance improvements that this change brings.

Boris Ostrovsky (2):
  xen/pci: Defer initialization of MSI ops on HVM guests until after
    x2APIC has been set up
  xen/pci: Use APIC directly when APIC virtualization is supported by
    hardware

 arch/x86/include/asm/xen/cpuid.h | 91 ++++++++++++++++++++++++++++++++++++++++
 arch/x86/pci/xen.c               | 25 ++++++++++-
 2 files changed, 114 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/include/asm/xen/cpuid.h

-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 03:01:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 03:01:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xt6Mt-0001vn-8c; Tue, 25 Nov 2014 03:00:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xt6Ms-0001vg-Jo
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 03:00:42 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	D9/D4-05632-9D0F3745; Tue, 25 Nov 2014 03:00:41 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416884439!13534117!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30297 invoked from network); 25 Nov 2014 03:00:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 03:00:41 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAP30SiI008926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 03:00:30 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30Q4q027729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 03:00:27 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30QTv017791; Tue, 25 Nov 2014 03:00:26 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 19:00:25 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 24 Nov 2014 18:06:16 -0500
Message-Id: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 0/2] xen/pci: Use APIC for MSIs when APIC
	virtualization is supported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v3:
* Explicitly include asm/apic.h in arch/x86/pci/xen.c for !CONFIG_SMP.

Changes in v2:
* New version of cpuid.h file from Xen tree (with a couple of style adjustments)
* Whitespace cleanup

Currently HVM guests handle MSI interrupts using pirqs/event channels, allowing
us to not issue APIC accesses that result in somewhat expensive VMEXITs. When
hardware supports APIC virtualization we don't need to use pirqs anymore
since now guest's APIC accesses can be handled by the processor itself.

There are two patches in this series:

1. Move setting of x86_msi ops to a later point. The reason for doing so is that
we currently decide whether or not to use pirqs before kernel had a chance to
see whether it should be using x2APIC instead of plain APIC. Since hardware may
virtualize either or both of those two we can only make pirqs vs. APIC selection
after kernel has settled down on which APIC version it will use. (Note that
currently x2APIC is not used by HVM guests so technically this patch is not
necessary. However, it probably makes sense to apply it now to avoid
forgetting to do it when we enable x2APIC).

2. Set x86_msi ops to use pirqs only when APIC virtualization is not available.
The commit message describes performance improvements that this change brings.

Boris Ostrovsky (2):
  xen/pci: Defer initialization of MSI ops on HVM guests until after
    x2APIC has been set up
  xen/pci: Use APIC directly when APIC virtualization is supported by
    hardware

 arch/x86/include/asm/xen/cpuid.h | 91 ++++++++++++++++++++++++++++++++++++++++
 arch/x86/pci/xen.c               | 25 ++++++++++-
 2 files changed, 114 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/include/asm/xen/cpuid.h

-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 03:01:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 03:01:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xt6Mp-0001vP-Cg; Tue, 25 Nov 2014 03:00:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xt6Mo-0001vK-Ht
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 03:00:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	84/C3-09842-5D0F3745; Tue, 25 Nov 2014 03:00:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416884435!14984242!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32637 invoked from network); 25 Nov 2014 03:00:37 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 03:00:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAP30SkQ012186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 03:00:29 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30Q6E014853
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 03:00:27 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30QP5014844; Tue, 25 Nov 2014 03:00:26 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 19:00:26 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 24 Nov 2014 18:06:17 -0500
Message-Id: <1416870378-32481-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 1/2] xen/pci: Defer initialization of MSI ops
	on HVM guests until after x2APIC has been set up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hardware supports APIC virtualization we may decide not to use pirqs
and instead use APIC/x2APIC directly, meaning that we don't want to set
x86_msi.setup_msi_irqs and x86_msi.teardown_msi_irq to Xen-specific routines.
However, x2APIC is not set up by the time pci_xen_hvm_init() is called so we
need to postpone setting these ops until later, when we know which APIC mode
is used.

(Note that currently x2APIC is never initialized on HVM guests. This may
change in the future)

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/pci/xen.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 093f5f4..1370716 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -431,6 +431,14 @@ int __init pci_xen_init(void)
 	return 0;
 }
 
+#ifdef CONFIG_PCI_MSI
+void __init xen_msi_init(void)
+{
+	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
+	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
+}
+#endif
+
 int __init pci_xen_hvm_init(void)
 {
 	if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
@@ -445,8 +453,11 @@ int __init pci_xen_hvm_init(void)
 #endif
 
 #ifdef CONFIG_PCI_MSI
-	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
-	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
+	/*
+	 * We need to wait until after x2apic is initialized
+	 * before we can set MSI IRQ ops.
+	 */
+	x86_platform.apic_post_init = xen_msi_init;
 #endif
 	return 0;
 }
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 03:01:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 03:01:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xt6Mr-0001vb-SY; Tue, 25 Nov 2014 03:00:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xt6Mq-0001vT-0i
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 03:00:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8D/B6-15461-7D0F3745; Tue, 25 Nov 2014 03:00:39 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416884435!12282422!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30210 invoked from network); 25 Nov 2014 03:00:37 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 03:00:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAP30Tpo012187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 03:00:29 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30RQx014945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 03:00:28 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAP30RmP017867; Tue, 25 Nov 2014 03:00:27 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Nov 2014 19:00:27 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 24 Nov 2014 18:06:18 -0500
Message-Id: <1416870378-32481-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3 2/2] xen/pci: Use APIC directly when APIC
	virtualization is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hardware supports APIC/x2APIC virtualization we don't need to use pirqs
for MSI handling and instead use APIC since most APIC accesses (MMIO or MSR)
will now be processed without VMEXITs.

As an example, netperf on the original code produces this profile
(collected wih 'xentrace -e 0x0008ffff -T 5'):

    342 cpu_change
    260 CPUID
  34638 HLT
  64067 INJ_VIRQ
  28374 INTR
  82733 INTR_WINDOW
     10 NPF
  24337 TRAP
 370610 vlapic_accept_pic_intr
 307528 VMENTRY
 307527 VMEXIT
 140998 VMMCALL
    127 wrap_buffer

After applying this patch the same test shows

    230 cpu_change
    260 CPUID
  36542 HLT
    174 INJ_VIRQ
  27250 INTR
    222 INTR_WINDOW
     20 NPF
  24999 TRAP
 381812 vlapic_accept_pic_intr
 166480 VMENTRY
 166479 VMEXIT
  77208 VMMCALL
     81 wrap_buffer

ApacheBench results (ab -n 10000 -c 200) improve by about 10%

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/include/asm/xen/cpuid.h | 91 ++++++++++++++++++++++++++++++++++++++++
 arch/x86/pci/xen.c               | 10 +++++
 2 files changed, 101 insertions(+)
 create mode 100644 arch/x86/include/asm/xen/cpuid.h

diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h
new file mode 100644
index 0000000..0d809e9
--- /dev/null
+++ b/arch/x86/include/asm/xen/cpuid.h
@@ -0,0 +1,91 @@
+/******************************************************************************
+ * arch-x86/cpuid.h
+ *
+ * CPUID interface to Xen.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2007 Citrix Systems, Inc.
+ *
+ * Authors:
+ *    Keir Fraser <keir@xen.org>
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_CPUID_H__
+#define __XEN_PUBLIC_ARCH_X86_CPUID_H__
+
+/*
+ * For compatibility with other hypervisor interfaces, the Xen cpuid leaves
+ * can be found at the first otherwise unused 0x100 aligned boundary starting
+ * from 0x40000000.
+ *
+ * e.g If viridian extensions are enabled for an HVM domain, the Xen cpuid
+ * leaves will start at 0x40000100
+ */
+
+#define XEN_CPUID_FIRST_LEAF 0x40000000
+#define XEN_CPUID_LEAF(i)    (XEN_CPUID_FIRST_LEAF + (i))
+
+/*
+ * Leaf 1 (0x40000x00)
+ * EAX: Largest Xen-information leaf. All leaves up to an including @EAX
+ *      are supported by the Xen host.
+ * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification
+ *      of a Xen host.
+ */
+#define XEN_CPUID_SIGNATURE_EBX 0x566e6558 /* "XenV" */
+#define XEN_CPUID_SIGNATURE_ECX 0x65584d4d /* "MMXe" */
+#define XEN_CPUID_SIGNATURE_EDX 0x4d4d566e /* "nVMM" */
+
+/*
+ * Leaf 2 (0x40000x01)
+ * EAX[31:16]: Xen major version.
+ * EAX[15: 0]: Xen minor version.
+ * EBX-EDX: Reserved (currently all zeroes).
+ */
+
+/*
+ * Leaf 3 (0x40000x02)
+ * EAX: Number of hypercall transfer pages. This register is always guaranteed
+ *      to specify one hypercall page.
+ * EBX: Base address of Xen-specific MSRs.
+ * ECX: Features 1. Unused bits are set to zero.
+ * EDX: Features 2. Unused bits are set to zero.
+ */
+
+/* Does the host support MMU_PT_UPDATE_PRESERVE_AD for this guest? */
+#define _XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD 0
+#define XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD  (1u<<0)
+
+/*
+ * Leaf 5 (0x40000x04)
+ * HVM-specific features
+ */
+
+/* EAX Features */
+/* Virtualized APIC registers */
+#define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0)
+/* Virtualized x2APIC accesses */
+#define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1)
+/* Memory mapped from other domains has valid IOMMU entries */
+#define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
+
+#define XEN_CPUID_MAX_NUM_LEAVES 4
+
+#endif /* __XEN_PUBLIC_ARCH_X86_CPUID_H__ */
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 1370716..e4a5bab 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -23,6 +23,8 @@
 #include <xen/features.h>
 #include <xen/events.h>
 #include <asm/xen/pci.h>
+#include <asm/xen/cpuid.h>
+#include <asm/apic.h>
 #include <asm/i8259.h>
 
 static int xen_pcifront_enable_irq(struct pci_dev *dev)
@@ -434,6 +436,14 @@ int __init pci_xen_init(void)
 #ifdef CONFIG_PCI_MSI
 void __init xen_msi_init(void)
 {
+	if (!disable_apic) {
+		uint32_t eax = cpuid_eax(xen_cpuid_base() + 4);
+
+		if (((eax & XEN_HVM_CPUID_X2APIC_VIRT) && x2apic_mode) ||
+		    ((eax & XEN_HVM_CPUID_APIC_ACCESS_VIRT) && cpu_has_apic))
+			return;
+	}
+
 	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
 	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
 }
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 04:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 04:48:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xt82m-0002nW-0Y; Tue, 25 Nov 2014 04:48:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xt82j-0002nR-TJ
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 04:48:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	23/4F-09842-10A04745; Tue, 25 Nov 2014 04:48:01 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416890878!15075730!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21250 invoked from network); 25 Nov 2014 04:47:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 04:47:58 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 197BAAAF1;
	Tue, 25 Nov 2014 04:47:58 +0000 (UTC)
Message-ID: <547409FD.5050803@suse.com>
Date: Tue, 25 Nov 2014 05:47:57 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546EFAE3.80404@suse.com>		<20141121135747.GB2886@laptop.dumpdata.com>	<5473008C.4080604@suse.com>	<5473147C020000780004A3D5@suse.com>
	<54730F8F.7080905@suse.com> <54734A2A.9000301@suse.com>
In-Reply-To: <54734A2A.9000301@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 04:09 PM, Juergen Gross wrote:
> On 11/24/2014 11:59 AM, Juergen Gross wrote:
>> On 11/24/2014 11:20 AM, Jan Beulich wrote:
>>>>>> On 24.11.14 at 10:55, <JGross@suse.com> wrote:
>>>> - Sometimes I see only NMI watchdog messages, looking into hanging cpu
>>>>     state via xen debug keys I can see the cpu(s) in question are
>>>> spinning
>>>>     in _raw_spin_lock():
>>>>     __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
>>>>     The hanging cpus were executing some random user processes (cron,
>>>>     bash, xargs), cr2 contained user addresses.
>>>
>>> Is this perhaps what
>>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02135.html
>>>
>>> appears to be about?
>>
>> Hmm, I'm not sure.
>>
>> I'll try a 3.17 kernel to verify.
>
> Still seeing the issue, but less frequent. OTOH I just found in above
> thread in lkml that 3.17 is showing that issue, too. :-(
>
> I'll try to setup a pv-variant of Linus' patch and test it...

Okay, test survived the night. Seems really to be the same issue.

I think I'm seeing the qemu issue now Ian mentioned:

[  140.182849] xen:grant_table: WARNING: g.e. 0x10 still in use!
[  140.182859] deferring g.e. 0x10 (pfn 0xffffffffffffffff)
[  140.182864] xen:grant_table: WARNING: g.e. 0xf still in use!
[  140.182866] deferring g.e. 0xf (pfn 0xffffffffffffffff)
...
[  140.183128] xen:grant_table: WARNING: g.e. 0x2a still in use!
[  140.183129] deferring g.e. 0x2a (pfn 0xffffffffffffffff)
[  142.182274] xen:grant_table: freeing g.e. 0x9
[  145.182284] xen:grant_table: freeing g.e. 0x44
[  147.182272] xen:grant_table: freeing g.e. 0x43
[  501.182282] xen:grant_table: g.e. 0x10 still pending
[  501.182315] xen:grant_table: g.e. 0xf still pending
...

I'll update qemu and try again...


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 04:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 04:48:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xt82m-0002nW-0Y; Tue, 25 Nov 2014 04:48:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xt82j-0002nR-TJ
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 04:48:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	23/4F-09842-10A04745; Tue, 25 Nov 2014 04:48:01 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416890878!15075730!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21250 invoked from network); 25 Nov 2014 04:47:58 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 04:47:58 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 197BAAAF1;
	Tue, 25 Nov 2014 04:47:58 +0000 (UTC)
Message-ID: <547409FD.5050803@suse.com>
Date: Tue, 25 Nov 2014 05:47:57 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546EFAE3.80404@suse.com>		<20141121135747.GB2886@laptop.dumpdata.com>	<5473008C.4080604@suse.com>	<5473147C020000780004A3D5@suse.com>
	<54730F8F.7080905@suse.com> <54734A2A.9000301@suse.com>
In-Reply-To: <54734A2A.9000301@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 04:09 PM, Juergen Gross wrote:
> On 11/24/2014 11:59 AM, Juergen Gross wrote:
>> On 11/24/2014 11:20 AM, Jan Beulich wrote:
>>>>>> On 24.11.14 at 10:55, <JGross@suse.com> wrote:
>>>> - Sometimes I see only NMI watchdog messages, looking into hanging cpu
>>>>     state via xen debug keys I can see the cpu(s) in question are
>>>> spinning
>>>>     in _raw_spin_lock():
>>>>     __handle_mm_fault()->__pte_alloc()->pmd_lock()->_raw_spin_lock()
>>>>     The hanging cpus were executing some random user processes (cron,
>>>>     bash, xargs), cr2 contained user addresses.
>>>
>>> Is this perhaps what
>>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02135.html
>>>
>>> appears to be about?
>>
>> Hmm, I'm not sure.
>>
>> I'll try a 3.17 kernel to verify.
>
> Still seeing the issue, but less frequent. OTOH I just found in above
> thread in lkml that 3.17 is showing that issue, too. :-(
>
> I'll try to setup a pv-variant of Linus' patch and test it...

Okay, test survived the night. Seems really to be the same issue.

I think I'm seeing the qemu issue now Ian mentioned:

[  140.182849] xen:grant_table: WARNING: g.e. 0x10 still in use!
[  140.182859] deferring g.e. 0x10 (pfn 0xffffffffffffffff)
[  140.182864] xen:grant_table: WARNING: g.e. 0xf still in use!
[  140.182866] deferring g.e. 0xf (pfn 0xffffffffffffffff)
...
[  140.183128] xen:grant_table: WARNING: g.e. 0x2a still in use!
[  140.183129] deferring g.e. 0x2a (pfn 0xffffffffffffffff)
[  142.182274] xen:grant_table: freeing g.e. 0x9
[  145.182284] xen:grant_table: freeing g.e. 0x44
[  147.182272] xen:grant_table: freeing g.e. 0x43
[  501.182282] xen:grant_table: g.e. 0x10 still pending
[  501.182315] xen:grant_table: g.e. 0xf still pending
...

I'll update qemu and try again...


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 06:17:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 06: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 1Xt9R8-0003ey-QD; Tue, 25 Nov 2014 06:17:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasowang@redhat.com>) id 1Xt9R7-0003et-MQ
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 06:17:17 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	24/63-23865-CEE14745; Tue, 25 Nov 2014 06:17:16 +0000
X-Env-Sender: jasowang@redhat.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416896234!11140848!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5050 invoked from network); 25 Nov 2014 06:17:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 06:17:16 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAP6H2m9019610
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 25 Nov 2014 01:17:02 -0500
Received: from [10.66.71.84] (dhcp-66-71-84.eng.nay.redhat.com [10.66.71.84]
	(may be forged))
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAP6GulG006236; Tue, 25 Nov 2014 01:16:57 -0500
Message-ID: <54741ED7.2060500@redhat.com>
Date: Tue, 25 Nov 2014 14:16:55 +0800
From: Jason Wang <jasowang@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org
References: <547290D7.2020506@cn.fujitsu.com>
	<5472F1DA.4080508@m2r.biz>	<5472F980.6030208@cn.fujitsu.com>	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com,
	xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>> CC'ing Paolo.
>>>
>>>
>>> Wen,
>>> thanks for the logs.
>>>
>>> I investigated a little bit and it seems to me that the bug occurs when
>>> QEMU tries to unmap only a portion of a memory region previously mapped.
>>> That doesn't work with xen-mapcache.
>>>
>>> See these logs for example:
>>>
>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>> Sorry the logs don't quite match, it was supposed to be:
>>
>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> It looks like the problem is caused by iov_discard_front, called by
> virtio_net_handle_ctrl. By changing iov_base after the sg has already
> been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> because the corresponding cpu_physical_memory_unmap will only unmap a
> portion of the original sg.  On Xen the problem is worse because
> xen-mapcache aborts.
>
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 2ac6ce5..b2b5c2d 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>      struct iovec *iov;
>      unsigned int iov_cnt;
>  
> -    while (virtqueue_pop(vq, &elem)) {
> +    while (virtqueue_pop_nomap(vq, &elem)) {
>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
>              error_report("virtio-net ctrl missing headers");
> @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>  
>          iov = elem.out_sg;
>          iov_cnt = elem.out_num;
> -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> +
> +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> +
> +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));

Does this really work? The code in fact skips the location that contains
virtio_net_ctrl_hdr. And virtio_net_handle_mac() still calls
iov_discard_front().

How about copy iov to a temp variable and use it in this function?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 06:17:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 06: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 1Xt9R8-0003ey-QD; Tue, 25 Nov 2014 06:17:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasowang@redhat.com>) id 1Xt9R7-0003et-MQ
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 06:17:17 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	24/63-23865-CEE14745; Tue, 25 Nov 2014 06:17:16 +0000
X-Env-Sender: jasowang@redhat.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416896234!11140848!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5050 invoked from network); 25 Nov 2014 06:17:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 06:17:16 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAP6H2m9019610
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 25 Nov 2014 01:17:02 -0500
Received: from [10.66.71.84] (dhcp-66-71-84.eng.nay.redhat.com [10.66.71.84]
	(may be forged))
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAP6GulG006236; Tue, 25 Nov 2014 01:16:57 -0500
Message-ID: <54741ED7.2060500@redhat.com>
Date: Tue, 25 Nov 2014 14:16:55 +0800
From: Jason Wang <jasowang@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org
References: <547290D7.2020506@cn.fujitsu.com>
	<5472F1DA.4080508@m2r.biz>	<5472F980.6030208@cn.fujitsu.com>	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com,
	xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>> CC'ing Paolo.
>>>
>>>
>>> Wen,
>>> thanks for the logs.
>>>
>>> I investigated a little bit and it seems to me that the bug occurs when
>>> QEMU tries to unmap only a portion of a memory region previously mapped.
>>> That doesn't work with xen-mapcache.
>>>
>>> See these logs for example:
>>>
>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>> Sorry the logs don't quite match, it was supposed to be:
>>
>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> It looks like the problem is caused by iov_discard_front, called by
> virtio_net_handle_ctrl. By changing iov_base after the sg has already
> been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> because the corresponding cpu_physical_memory_unmap will only unmap a
> portion of the original sg.  On Xen the problem is worse because
> xen-mapcache aborts.
>
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 2ac6ce5..b2b5c2d 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>      struct iovec *iov;
>      unsigned int iov_cnt;
>  
> -    while (virtqueue_pop(vq, &elem)) {
> +    while (virtqueue_pop_nomap(vq, &elem)) {
>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
>              error_report("virtio-net ctrl missing headers");
> @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>  
>          iov = elem.out_sg;
>          iov_cnt = elem.out_num;
> -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> +
> +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> +
> +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));

Does this really work? The code in fact skips the location that contains
virtio_net_ctrl_hdr. And virtio_net_handle_mac() still calls
iov_discard_front().

How about copy iov to a temp variable and use it in this function?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 07:15:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 07:15:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtAL3-0004CW-Df; Tue, 25 Nov 2014 07:15:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gedalya@gedalya.net>) id 1XtAL1-0004CR-OD
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 07:15:04 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	EE/F8-22819-77C24745; Tue, 25 Nov 2014 07:15:03 +0000
X-Env-Sender: gedalya@gedalya.net
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416899701!13147199!1
X-Originating-IP: [47.21.139.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22579 invoked from network); 25 Nov 2014 07:15:02 -0000
Received: from mail.gedalya.net (HELO mail.gedalya.net) (47.21.139.35)
	by server-2.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Nov 2014 07:15:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gedalya.net;
	s=rsa1; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=M1Ii45rJn3xvm0tdWHLT90hInAo2Oy/uo9qaLhngJUQ=; 
	b=rwHz4CXBSXO8frvAemUBn+Van+9t5p14UFUY6DihdqYEBtbWsHBcpz2nS4VwHXvJxW0gu+3mdLpPTTigHjMwrESwrEvZs7X0ixMzQVrCxVDDqwjyXRrSSC+grkd5iTc0aZNfsy2i7rIjA0nDNdkIQ3Ju+G3A4178DizMqPWLw/pUEEfSY1Bm1ZylHUxv07Rt5ANT135P+WFQg8CFRTD+3kHq902LPpNbMBOCgL2/xKdlw+IGOwSjtRoMUdjmNmleldx0yJTfoGymD7ABDkDAhzAYyErtcjVvUX8S3uvPBkJLaMG1JXOZKYYQbVvi/DlJb8Up2CIQ6NMkBSMk4nmTog==;
Received: from [192.168.9.10] by mail.gedalya.net with esmtpsa
	(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84)
	(envelope-from <gedalya@gedalya.net>)
	id 1XtAKw-0004HO-36; Tue, 25 Nov 2014 02:14:58 -0500
Message-ID: <54742C71.6080908@gedalya.net>
Date: Tue, 25 Nov 2014 02:14:57 -0500
From: Gedalya <gedalya@gedalya.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>		
	<20141120202114.GE31889@laptop.dumpdata.com>	
	<546EADD0.8010002@gedalya.net>	
	<1416567797.26869.18.camel@citrix.com>	
	<1416568333.26869.22.camel@citrix.com>
	<546F9F9C.5090507@gedalya.net>
	<1416825467.26329.30.camel@citrix.com>
In-Reply-To: <1416825467.26329.30.camel@citrix.com>
Cc: ian.jackson@eu.citrix.com, 767295@bugs.debian.org, xen-devel@lists.xen.org,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 05:37 AM, Ian Campbell wrote:
> Unfortunately this is down to the behaviour of the libc and not
> something which appears to be under application control.
>
> The following program demonstrates the same behaviour and is certainly
> not leaking anything. Notice that at "Freed block at XXXXX. Everything
> is now freed, end of day" there is still an anon mapping of that
> address. Notice also that the "in use" figures are zero.
>
> If this concerns you then you should probably take a look at mallopt(3)
> and/or be talking to the libc folks about it. It's not an xl issue
> AFAICT.
Firstly, thank you very much for explaining this in such clear detail, 
above all this has been quite educational for me :-)
After reading the man page, it looks like glibc's behavior here is 
indeed by design. I'm unable to form, much less advocate an opinion 
about how libc should behave, any discussion about libc must be very broad.
Stepping away from the technical details, I still think that any future 
enhancement to make xl go out of its way to free this memory would 
definitely be nice. Right now we have memory that is allocated for a 
single, momentary use and it can stay allocated for the lifetime of a 
domu unnecessarily, taking the size of the xl process to another order 
of magnitude. Even if no longer technically a bug / memory leak, and the 
implied priority, this could still merit someone's attention.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 07:15:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 07:15:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtAL3-0004CW-Df; Tue, 25 Nov 2014 07:15:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gedalya@gedalya.net>) id 1XtAL1-0004CR-OD
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 07:15:04 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	EE/F8-22819-77C24745; Tue, 25 Nov 2014 07:15:03 +0000
X-Env-Sender: gedalya@gedalya.net
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416899701!13147199!1
X-Originating-IP: [47.21.139.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22579 invoked from network); 25 Nov 2014 07:15:02 -0000
Received: from mail.gedalya.net (HELO mail.gedalya.net) (47.21.139.35)
	by server-2.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Nov 2014 07:15:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gedalya.net;
	s=rsa1; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=M1Ii45rJn3xvm0tdWHLT90hInAo2Oy/uo9qaLhngJUQ=; 
	b=rwHz4CXBSXO8frvAemUBn+Van+9t5p14UFUY6DihdqYEBtbWsHBcpz2nS4VwHXvJxW0gu+3mdLpPTTigHjMwrESwrEvZs7X0ixMzQVrCxVDDqwjyXRrSSC+grkd5iTc0aZNfsy2i7rIjA0nDNdkIQ3Ju+G3A4178DizMqPWLw/pUEEfSY1Bm1ZylHUxv07Rt5ANT135P+WFQg8CFRTD+3kHq902LPpNbMBOCgL2/xKdlw+IGOwSjtRoMUdjmNmleldx0yJTfoGymD7ABDkDAhzAYyErtcjVvUX8S3uvPBkJLaMG1JXOZKYYQbVvi/DlJb8Up2CIQ6NMkBSMk4nmTog==;
Received: from [192.168.9.10] by mail.gedalya.net with esmtpsa
	(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84)
	(envelope-from <gedalya@gedalya.net>)
	id 1XtAKw-0004HO-36; Tue, 25 Nov 2014 02:14:58 -0500
Message-ID: <54742C71.6080908@gedalya.net>
Date: Tue, 25 Nov 2014 02:14:57 -0500
From: Gedalya <gedalya@gedalya.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>		
	<20141120202114.GE31889@laptop.dumpdata.com>	
	<546EADD0.8010002@gedalya.net>	
	<1416567797.26869.18.camel@citrix.com>	
	<1416568333.26869.22.camel@citrix.com>
	<546F9F9C.5090507@gedalya.net>
	<1416825467.26329.30.camel@citrix.com>
In-Reply-To: <1416825467.26329.30.camel@citrix.com>
Cc: ian.jackson@eu.citrix.com, 767295@bugs.debian.org, xen-devel@lists.xen.org,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 05:37 AM, Ian Campbell wrote:
> Unfortunately this is down to the behaviour of the libc and not
> something which appears to be under application control.
>
> The following program demonstrates the same behaviour and is certainly
> not leaking anything. Notice that at "Freed block at XXXXX. Everything
> is now freed, end of day" there is still an anon mapping of that
> address. Notice also that the "in use" figures are zero.
>
> If this concerns you then you should probably take a look at mallopt(3)
> and/or be talking to the libc folks about it. It's not an xl issue
> AFAICT.
Firstly, thank you very much for explaining this in such clear detail, 
above all this has been quite educational for me :-)
After reading the man page, it looks like glibc's behavior here is 
indeed by design. I'm unable to form, much less advocate an opinion 
about how libc should behave, any discussion about libc must be very broad.
Stepping away from the technical details, I still think that any future 
enhancement to make xl go out of its way to free this memory would 
definitely be nice. Right now we have memory that is allocated for a 
single, momentary use and it can stay allocated for the lifetime of a 
domu unnecessarily, taking the size of the xl process to another order 
of magnitude. Even if no longer technically a bug / memory leak, and the 
implied priority, this could still merit someone's attention.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 07:17:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 07:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtANI-0004IE-Vj; Tue, 25 Nov 2014 07:17:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aragrawal@cs.wisc.edu>) id 1Xt29Q-0002lT-Ql
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 22:30:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D9/D8-25276-881B3745; Mon, 24 Nov 2014 22:30:32 +0000
X-Env-Sender: aragrawal@cs.wisc.edu
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416868230!6991568!1
X-Originating-IP: [128.105.6.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24585 invoked from network); 24 Nov 2014 22:30:31 -0000
Received: from sandstone.cs.wisc.edu (HELO sandstone.cs.wisc.edu)
	(128.105.6.39)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 22:30:31 -0000
Received: from balthazar.cs.wisc.edu (balthazar.cs.wisc.edu [128.105.15.16])
	by sandstone.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id sAOMUN5Y018844; 
	Mon, 24 Nov 2014 16:30:23 -0600
Message-ID: <5473B17F.3070200@cs.wisc.edu>
Date: Mon, 24 Nov 2014 16:30:23 -0600
From: Ankit Agrawal <aragrawal@cs.wisc.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
References: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
	<CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
	<20141124150605.GA3946@laptop.dumpdata.com>
	<1416841880.8878.7.camel@citrix.com>
	<20141124152039.GC3946@laptop.dumpdata.com>
In-Reply-To: <20141124152039.GC3946@laptop.dumpdata.com>
X-Mailman-Approved-At: Tue, 25 Nov 2014 07:17:24 +0000
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 09:20 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 24, 2014 at 03:11:20PM +0000, Ian Campbell wrote:
>> On Mon, 2014-11-24 at 10:06 -0500, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Nov 24, 2014 at 12:07:39PM +0000, George Dunlap wrote:
>>>> On Mon, Nov 24, 2014 at 3:54 AM, aragrawal <aragrawal@cs.wisc.edu> wrote:
>>>>> Hi
>>>>>
>>>>> I am interested in getting the block I/O rate fixed for a Virtual Machine.
>>>>> However, it seems that there are no such options to control the block I/O
>>>>> rate via the VM configuration file.
>>>>> Going through the net, I see suggestions to configure the xen_blkback driver
>>>>> using ionice to get that done.
>>>>>
>>>>> I would like to know if there are any plans to include any such
>>>>> configuration option.
>>>>> Also, are there any particular reason (apart from the fact that there are
>>>>> other ways to get this done) for the absence of such configuration option?
>>>> I'm pretty sure it's just because nobody had asked for it yet.
>>>>
>>>> We can put it on our list of things to think about doing / projects
>>>> for people new to the community.
>>>>
>>>> We also accept patches. :-)
>>> Patches for this were in the past posted - it just that nobody explained
>>> to the maintainer (me) why the dm-* or io-nice would not do the same job.
>> AIUI the question here is why the toolstack doesn't integrate a guest
>> cfg file setting to configure dm-* and/or io-nice, rather than why
>> blkback doesn't duplicate their functionality.
> Ah, that is a different question. That certainly could be done by somebody
> who has the time.
>> Ian.
>>
>>
Hi

Thanks for the quick reply. I see the time constraint is the only issue 
here.

Regards
Ankit Agrawal

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 07:17:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 07:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtANI-0004IE-Vj; Tue, 25 Nov 2014 07:17:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aragrawal@cs.wisc.edu>) id 1Xt29Q-0002lT-Ql
	for xen-devel@lists.xenproject.org; Mon, 24 Nov 2014 22:30:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D9/D8-25276-881B3745; Mon, 24 Nov 2014 22:30:32 +0000
X-Env-Sender: aragrawal@cs.wisc.edu
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416868230!6991568!1
X-Originating-IP: [128.105.6.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24585 invoked from network); 24 Nov 2014 22:30:31 -0000
Received: from sandstone.cs.wisc.edu (HELO sandstone.cs.wisc.edu)
	(128.105.6.39)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2014 22:30:31 -0000
Received: from balthazar.cs.wisc.edu (balthazar.cs.wisc.edu [128.105.15.16])
	by sandstone.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id sAOMUN5Y018844; 
	Mon, 24 Nov 2014 16:30:23 -0600
Message-ID: <5473B17F.3070200@cs.wisc.edu>
Date: Mon, 24 Nov 2014 16:30:23 -0600
From: Ankit Agrawal <aragrawal@cs.wisc.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
References: <7af096d19bfeabe5d2d5aba22887738a@cs.wisc.edu>
	<CAFLBxZaih2efhRNazt21fur1bUiNd04NKcZu+-zjO9VmMLyvAQ@mail.gmail.com>
	<20141124150605.GA3946@laptop.dumpdata.com>
	<1416841880.8878.7.camel@citrix.com>
	<20141124152039.GC3946@laptop.dumpdata.com>
In-Reply-To: <20141124152039.GC3946@laptop.dumpdata.com>
X-Mailman-Approved-At: Tue, 25 Nov 2014 07:17:24 +0000
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Configure block device IO rate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 09:20 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 24, 2014 at 03:11:20PM +0000, Ian Campbell wrote:
>> On Mon, 2014-11-24 at 10:06 -0500, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Nov 24, 2014 at 12:07:39PM +0000, George Dunlap wrote:
>>>> On Mon, Nov 24, 2014 at 3:54 AM, aragrawal <aragrawal@cs.wisc.edu> wrote:
>>>>> Hi
>>>>>
>>>>> I am interested in getting the block I/O rate fixed for a Virtual Machine.
>>>>> However, it seems that there are no such options to control the block I/O
>>>>> rate via the VM configuration file.
>>>>> Going through the net, I see suggestions to configure the xen_blkback driver
>>>>> using ionice to get that done.
>>>>>
>>>>> I would like to know if there are any plans to include any such
>>>>> configuration option.
>>>>> Also, are there any particular reason (apart from the fact that there are
>>>>> other ways to get this done) for the absence of such configuration option?
>>>> I'm pretty sure it's just because nobody had asked for it yet.
>>>>
>>>> We can put it on our list of things to think about doing / projects
>>>> for people new to the community.
>>>>
>>>> We also accept patches. :-)
>>> Patches for this were in the past posted - it just that nobody explained
>>> to the maintainer (me) why the dm-* or io-nice would not do the same job.
>> AIUI the question here is why the toolstack doesn't integrate a guest
>> cfg file setting to configure dm-* and/or io-nice, rather than why
>> blkback doesn't duplicate their functionality.
> Ah, that is a different question. That certainly could be done by somebody
> who has the time.
>> Ian.
>>
>>
Hi

Thanks for the quick reply. I see the time constraint is the only issue 
here.

Regards
Ankit Agrawal

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 07:45:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 07: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 1XtAnZ-0004ZR-N1; Tue, 25 Nov 2014 07:44:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtAnY-0004ZM-Ir
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 07:44:32 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E0/BD-09284-F5334745; Tue, 25 Nov 2014 07:44:31 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416901471!13657065!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17981 invoked from network); 25 Nov 2014 07:44:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 07:44:31 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A7F11AB07
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Nov 2014 07:44:29 +0000 (UTC)
Message-ID: <5474335D.8010007@suse.com>
Date: Tue, 25 Nov 2014 08:44:29 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Failure on "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-Transfer-Encoding: 7bit
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,

make clean in xen-unstable is failing:

make[2]: Entering directory '/home/gross/xen/tools'
set -e; if test -d qemu-xen-traditional-dir/.; then \
         make -C qemu-xen-traditional-dir clean; \
fi
make[3]: Entering directory 
'/home/gross/xen/tools/qemu-xen-traditional-dir-remote'
Makefile:3: config-host.mak: No such file or directory
Makefile:4: /rules.mak: No such file or directory
make[3]: *** No rule to make target '/rules.mak'.  Stop.
make[3]: Leaving directory 
'/home/gross/xen/tools/qemu-xen-traditional-dir-remote'
Makefile:181: recipe for target 'subdir-clean-qemu-xen-traditional-dir' 
failed
make[2]: *** [subdir-clean-qemu-xen-traditional-dir] Error 2
make[2]: Leaving directory '/home/gross/xen/tools'
/home/gross/xen/tools/../tools/Rules.mk:111: recipe for target 
'subdirs-clean' failed
make[1]: *** [subdirs-clean] Error 2
make[1]: Leaving directory '/home/gross/xen/tools'
Makefile:139: recipe for target 'clean' failed
make: *** [clean] Error 2


I think SRC_PATH is somehow undefined...


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 07:45:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 07: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 1XtAnZ-0004ZR-N1; Tue, 25 Nov 2014 07:44:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtAnY-0004ZM-Ir
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 07:44:32 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E0/BD-09284-F5334745; Tue, 25 Nov 2014 07:44:31 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1416901471!13657065!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17981 invoked from network); 25 Nov 2014 07:44:31 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 07:44:31 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A7F11AB07
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Nov 2014 07:44:29 +0000 (UTC)
Message-ID: <5474335D.8010007@suse.com>
Date: Tue, 25 Nov 2014 08:44:29 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Failure on "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-Transfer-Encoding: 7bit
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,

make clean in xen-unstable is failing:

make[2]: Entering directory '/home/gross/xen/tools'
set -e; if test -d qemu-xen-traditional-dir/.; then \
         make -C qemu-xen-traditional-dir clean; \
fi
make[3]: Entering directory 
'/home/gross/xen/tools/qemu-xen-traditional-dir-remote'
Makefile:3: config-host.mak: No such file or directory
Makefile:4: /rules.mak: No such file or directory
make[3]: *** No rule to make target '/rules.mak'.  Stop.
make[3]: Leaving directory 
'/home/gross/xen/tools/qemu-xen-traditional-dir-remote'
Makefile:181: recipe for target 'subdir-clean-qemu-xen-traditional-dir' 
failed
make[2]: *** [subdir-clean-qemu-xen-traditional-dir] Error 2
make[2]: Leaving directory '/home/gross/xen/tools'
/home/gross/xen/tools/../tools/Rules.mk:111: recipe for target 
'subdirs-clean' failed
make[1]: *** [subdirs-clean] Error 2
make[1]: Leaving directory '/home/gross/xen/tools'
Makefile:139: recipe for target 'clean' failed
make: *** [clean] Error 2


I think SRC_PATH is somehow undefined...


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 07:50:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 07:50:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtAtX-0004hR-Go; Tue, 25 Nov 2014 07:50:43 +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 1XtAtV-0004hM-V0
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 07:50:42 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	18/86-02953-1D434745; Tue, 25 Nov 2014 07:50:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416901840!14619322!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27803 invoked from network); 25 Nov 2014 07:50:40 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 07:50:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 07:50:40 +0000
Message-Id: <547442DD020000780004A8FA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 07:50:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <546EFAE3.80404@suse.com>
	<20141121135747.GB2886@laptop.dumpdata.com> <5473008C.4080604@suse.com>
	<5473147C020000780004A3D5@suse.com> <54730F8F.7080905@suse.com>
	<54734A2A.9000301@suse.com> <54736A9D.3010901@suse.com>
In-Reply-To: <54736A9D.3010901@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-rc5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.11.14 at 18:27, <JGross@suse.com> wrote:
> On 11/24/2014 04:09 PM, Juergen Gross wrote:
>> Still seeing the issue, but less frequent. OTOH I just found in above
>> thread in lkml that 3.17 is showing that issue, too. :-(
>>
>> I'll try to setup a pv-variant of Linus' patch and test it...
> 
> First test seems to be okay, no immediate NMI message...
> 
> Any idea why the block-attach/detach would trigger this problem so
> easily? I can see the dependency on the high cpu count, but fail to do
> so for the xl actions.

No, no idea. It was only the similar symptoms that made me consider
this a possibility.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 07:50:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 07:50:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtAtX-0004hR-Go; Tue, 25 Nov 2014 07:50:43 +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 1XtAtV-0004hM-V0
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 07:50:42 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	18/86-02953-1D434745; Tue, 25 Nov 2014 07:50:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416901840!14619322!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27803 invoked from network); 25 Nov 2014 07:50:40 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 07:50:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 07:50:40 +0000
Message-Id: <547442DD020000780004A8FA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 07:50:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <546EFAE3.80404@suse.com>
	<20141121135747.GB2886@laptop.dumpdata.com> <5473008C.4080604@suse.com>
	<5473147C020000780004A3D5@suse.com> <54730F8F.7080905@suse.com>
	<54734A2A.9000301@suse.com> <54736A9D.3010901@suse.com>
In-Reply-To: <54736A9D.3010901@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-rc5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.11.14 at 18:27, <JGross@suse.com> wrote:
> On 11/24/2014 04:09 PM, Juergen Gross wrote:
>> Still seeing the issue, but less frequent. OTOH I just found in above
>> thread in lkml that 3.17 is showing that issue, too. :-(
>>
>> I'll try to setup a pv-variant of Linus' patch and test it...
> 
> First test seems to be okay, no immediate NMI message...
> 
> Any idea why the block-attach/detach would trigger this problem so
> easily? I can see the dependency on the high cpu count, but fail to do
> so for the xl actions.

No, no idea. It was only the similar symptoms that made me consider
this a possibility.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 08:16:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 08:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtBIC-0005OI-H7; Tue, 25 Nov 2014 08:16: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 1XtBIB-0005OD-49
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 08:16:11 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	27/C5-22737-ACA34745; Tue, 25 Nov 2014 08:16:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416903369!13155413!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28041 invoked from network); 25 Nov 2014 08:16:09 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 08:16:09 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 08:16:09 +0000
Message-Id: <547448D7020000780004A919@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 08:16:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
In-Reply-To: <5473AE78.5070505@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 23:17, <sflist@ihonk.com> wrote:
> I'm combining this action with your patch, see below. Please let me know 
> if this was incorrect.

Thanks, that's perfectly fine.

> (XEN) 'c' pressed -> printing ACPI Cx structures
> (XEN) ==cpu0==
> (XEN) active state:        C0
> (XEN) max_cstate:        C7
> (XEN) states:
> (XEN)     C1:    type[C1] latency[001] usage[00005664] method[  FFH] duration[4042540627]
> (XEN)     C2:    type[C3] latency[064] usage[00000414] method[  FFH] duration[447258888]
> (XEN)     C3:    type[C3] latency[096] usage[00002366] method[  FFH] duration[28183588810]
> (XEN)    *C0:    usage[00008444] duration[26752178344]
> (XEN) max=0 pwr=0 urg=0 nxt=0
> (XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
> (XEN) CC3[484210884] CC6[27943480555] CC7[0]

Interesting, so other than for me (perhaps due to other patches
I have in my tree) the change resulted in C states now being used
again despite mwait-idle=0, which is good. Question now is - with
this being the case, did the hangs re-occur?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 08:16:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 08:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtBIC-0005OI-H7; Tue, 25 Nov 2014 08:16: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 1XtBIB-0005OD-49
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 08:16:11 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	27/C5-22737-ACA34745; Tue, 25 Nov 2014 08:16:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416903369!13155413!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28041 invoked from network); 25 Nov 2014 08:16:09 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 08:16:09 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 08:16:09 +0000
Message-Id: <547448D7020000780004A919@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 08:16:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
In-Reply-To: <5473AE78.5070505@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 23:17, <sflist@ihonk.com> wrote:
> I'm combining this action with your patch, see below. Please let me know 
> if this was incorrect.

Thanks, that's perfectly fine.

> (XEN) 'c' pressed -> printing ACPI Cx structures
> (XEN) ==cpu0==
> (XEN) active state:        C0
> (XEN) max_cstate:        C7
> (XEN) states:
> (XEN)     C1:    type[C1] latency[001] usage[00005664] method[  FFH] duration[4042540627]
> (XEN)     C2:    type[C3] latency[064] usage[00000414] method[  FFH] duration[447258888]
> (XEN)     C3:    type[C3] latency[096] usage[00002366] method[  FFH] duration[28183588810]
> (XEN)    *C0:    usage[00008444] duration[26752178344]
> (XEN) max=0 pwr=0 urg=0 nxt=0
> (XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
> (XEN) CC3[484210884] CC6[27943480555] CC7[0]

Interesting, so other than for me (perhaps due to other patches
I have in my tree) the change resulted in C states now being used
again despite mwait-idle=0, which is good. Question now is - with
this being the case, did the hangs re-occur?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 08:21:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 08:21:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtBMm-0005WE-7L; Tue, 25 Nov 2014 08:20:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtBMl-0005W8-NY
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 08:20:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	27/AA-09842-7EB34745; Tue, 25 Nov 2014 08:20:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416903654!7799521!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19540 invoked from network); 25 Nov 2014 08:20:54 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 08:20:54 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 08:20:53 +0000
Message-Id: <547449F3020000780004A924@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 08:20:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yang Z Zhang" <yang.z.zhang@intel.com>
References: <20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
	<20141119095440.GA1409@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF0EDB@SHSMSX104.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF0EDB@SHSMSX104.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Liang Z Li <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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 25.11.14 at 02:47, <yang.z.zhang@intel.com> wrote:
> Tim Deegan wrote on 2014-11-19:
>> At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
>>> Tim Deegan wrote on 2014-11-18:
>>>> In this case, the guest is entitled to _expect_ pagefaults on 1GB
>>>> mappings if CPUID claims they are not supported.  That sounds like
>>>> an unlikely thing for the guest to be relying on, but Xen itself
>>>> does something similar for the SHOPT_FAST_FAULT_PATH (and now also
>>>> for IOMMU entries for the deferred caching attribute updates).
>>> 
>>> Indeed. How about adding the software check (as Andrew mentioned)
>>> firstly and leave the hardware problem (Actually, I don't think we
>>> can solve it currently).
>> 
>> I don't think we should change the software path unless we can change
>> the hardware behaviour too.  It's better to be consistent, and it
>> saves us some cycles in the pt walker.
> 
> So if we don't need to add the software check, does this mean current patch 
> is ok?

No - Tim having confirmed that shadow mode doesn't support 1Gb
pages, the feature clearly must not be made visible for shadow
mode guest.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 08:21:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 08:21:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtBMm-0005WE-7L; Tue, 25 Nov 2014 08:20:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtBMl-0005W8-NY
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 08:20:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	27/AA-09842-7EB34745; Tue, 25 Nov 2014 08:20:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416903654!7799521!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19540 invoked from network); 25 Nov 2014 08:20:54 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 08:20:54 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 08:20:53 +0000
Message-Id: <547449F3020000780004A924@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 08:20:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yang Z Zhang" <yang.z.zhang@intel.com>
References: <20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
	<20141119095440.GA1409@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF0EDB@SHSMSX104.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF0EDB@SHSMSX104.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Liang Z Li <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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 25.11.14 at 02:47, <yang.z.zhang@intel.com> wrote:
> Tim Deegan wrote on 2014-11-19:
>> At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
>>> Tim Deegan wrote on 2014-11-18:
>>>> In this case, the guest is entitled to _expect_ pagefaults on 1GB
>>>> mappings if CPUID claims they are not supported.  That sounds like
>>>> an unlikely thing for the guest to be relying on, but Xen itself
>>>> does something similar for the SHOPT_FAST_FAULT_PATH (and now also
>>>> for IOMMU entries for the deferred caching attribute updates).
>>> 
>>> Indeed. How about adding the software check (as Andrew mentioned)
>>> firstly and leave the hardware problem (Actually, I don't think we
>>> can solve it currently).
>> 
>> I don't think we should change the software path unless we can change
>> the hardware behaviour too.  It's better to be consistent, and it
>> saves us some cycles in the pt walker.
> 
> So if we don't need to add the software check, does this mean current patch 
> is ok?

No - Tim having confirmed that shadow mode doesn't support 1Gb
pages, the feature clearly must not be made visible for shadow
mode guest.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 08:45:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 08:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtBkV-0005lB-Cj; Tue, 25 Nov 2014 08:45:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtBkU-0005l6-Ay
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 08:45:26 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	19/E5-09284-5A144745; Tue, 25 Nov 2014 08:45:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416905124!13582441!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20703 invoked from network); 25 Nov 2014 08:45:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 08:45:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 08:45:24 +0000
Message-Id: <54744FB2020000780004A935@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 08:45:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
 PVH 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 24.11.14 at 20:49, <boris.ostrovsky@oracle.com> wrote:
> Currently when VPMU is enabled on a system both HVM and PVH VPCUs will
> initialize their VPMUs, including setting up vpmu_ops. As result even
> though VPMU will not work for PVH guests (APIC is not supported there),
> the guest may decide to perform a write to a PMU MSR. This will cause a
> call to is_vlapic_lvtpc_enabled() which will crash the hypervisor, e.g.:
> 
>  (XEN) Xen call trace:
>  (XEN)    [<ffff82d0801ca06f>] is_vlapic_lvtpc_enabled+0x13/0x22
>  (XEN)    [<ffff82d0801e2a15>] core2_vpmu_do_wrmsr+0x415/0x589
>  (XEN)    [<ffff82d0801cedaa>] vpmu_do_wrmsr+0x2a/0x33
>  (XEN)    [<ffff82d0801dd648>] vmx_msr_write_intercept+0x268/0x557
>  (XEN)    [<ffff82d0801bcd2e>] hvm_msr_write_intercept+0x36c/0x39b
>  (XEN)    [<ffff82d0801e0a0e>] vmx_vmexit_handler+0x1082/0x185b
>  (XEN)    [<ffff82d0801e74c1>] vmx_asm_vmexit_handler+0x41/0xc0
> 
> If we prevent VPMU from being initialized on PVH guests we will avoid
> those accesses.

I think this fix is too specific; instead we should mark the LAPIC
disabled, which will implicitly prevent the issue afaict - see below.

Jan

x86/PVH: properly disable vLAPIC

Rather than guarding higher level operations (like vPMU initialization
as suggested by Boris in
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02278.html)
mark the vLAPIC hardware disabled for PVH guests and prevent it from
getting moved out of this state.

Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2217,8 +2217,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
         goto fail1;
 
     /* NB: vlapic_init must be called before hvm_funcs.vcpu_initialise */
-    if ( is_hvm_vcpu(v) )
-        rc = vlapic_init(v);
+    rc = vlapic_init(v);
     if ( rc != 0 ) /* teardown: vlapic_destroy */
         goto fail2;
 
@@ -4483,7 +4482,8 @@ int hvm_msr_write_intercept(unsigned int
         break;
 
     case MSR_IA32_APICBASE:
-        if ( !vlapic_msr_set(vcpu_vlapic(v), msr_content) )
+        if ( unlikely(is_pvh_vcpu(v)) ||
+             !vlapic_msr_set(vcpu_vlapic(v), msr_content) )
             goto gp_fault;
         break;
 
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1429,6 +1429,12 @@ int vlapic_init(struct vcpu *v)
 
     HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "%d", v->vcpu_id);
 
+    if ( is_pvh_vcpu(v) )
+    {
+        vlapic->hw.disabled = VLAPIC_HW_DISABLED;
+        return 0;
+    }
+
     vlapic->pt.source = PTSRC_lapic;
 
     if (vlapic->regs_page == NULL)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 08:45:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 08:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtBkV-0005lB-Cj; Tue, 25 Nov 2014 08:45:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtBkU-0005l6-Ay
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 08:45:26 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	19/E5-09284-5A144745; Tue, 25 Nov 2014 08:45:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416905124!13582441!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20703 invoked from network); 25 Nov 2014 08:45:25 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 08:45:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 08:45:24 +0000
Message-Id: <54744FB2020000780004A935@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 08:45:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
 PVH 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 24.11.14 at 20:49, <boris.ostrovsky@oracle.com> wrote:
> Currently when VPMU is enabled on a system both HVM and PVH VPCUs will
> initialize their VPMUs, including setting up vpmu_ops. As result even
> though VPMU will not work for PVH guests (APIC is not supported there),
> the guest may decide to perform a write to a PMU MSR. This will cause a
> call to is_vlapic_lvtpc_enabled() which will crash the hypervisor, e.g.:
> 
>  (XEN) Xen call trace:
>  (XEN)    [<ffff82d0801ca06f>] is_vlapic_lvtpc_enabled+0x13/0x22
>  (XEN)    [<ffff82d0801e2a15>] core2_vpmu_do_wrmsr+0x415/0x589
>  (XEN)    [<ffff82d0801cedaa>] vpmu_do_wrmsr+0x2a/0x33
>  (XEN)    [<ffff82d0801dd648>] vmx_msr_write_intercept+0x268/0x557
>  (XEN)    [<ffff82d0801bcd2e>] hvm_msr_write_intercept+0x36c/0x39b
>  (XEN)    [<ffff82d0801e0a0e>] vmx_vmexit_handler+0x1082/0x185b
>  (XEN)    [<ffff82d0801e74c1>] vmx_asm_vmexit_handler+0x41/0xc0
> 
> If we prevent VPMU from being initialized on PVH guests we will avoid
> those accesses.

I think this fix is too specific; instead we should mark the LAPIC
disabled, which will implicitly prevent the issue afaict - see below.

Jan

x86/PVH: properly disable vLAPIC

Rather than guarding higher level operations (like vPMU initialization
as suggested by Boris in
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02278.html)
mark the vLAPIC hardware disabled for PVH guests and prevent it from
getting moved out of this state.

Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2217,8 +2217,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
         goto fail1;
 
     /* NB: vlapic_init must be called before hvm_funcs.vcpu_initialise */
-    if ( is_hvm_vcpu(v) )
-        rc = vlapic_init(v);
+    rc = vlapic_init(v);
     if ( rc != 0 ) /* teardown: vlapic_destroy */
         goto fail2;
 
@@ -4483,7 +4482,8 @@ int hvm_msr_write_intercept(unsigned int
         break;
 
     case MSR_IA32_APICBASE:
-        if ( !vlapic_msr_set(vcpu_vlapic(v), msr_content) )
+        if ( unlikely(is_pvh_vcpu(v)) ||
+             !vlapic_msr_set(vcpu_vlapic(v), msr_content) )
             goto gp_fault;
         break;
 
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1429,6 +1429,12 @@ int vlapic_init(struct vcpu *v)
 
     HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "%d", v->vcpu_id);
 
+    if ( is_pvh_vcpu(v) )
+    {
+        vlapic->hw.disabled = VLAPIC_HW_DISABLED;
+        return 0;
+    }
+
     vlapic->pt.source = PTSRC_lapic;
 
     if (vlapic->regs_page == NULL)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 08:52:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 08: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 1XtBrE-0005ws-FM; Tue, 25 Nov 2014 08:52:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XtBrD-0005wn-70
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 08:52:23 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	AA/91-02699-64344745; Tue, 25 Nov 2014 08:52:22 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416905541!14620332!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10951 invoked from network); 25 Nov 2014 08:52:22 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 08:52:22 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAP8q5oA023345;
	Tue, 25 Nov 2014 08:52:09 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAP8q1FC007581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 08:52:01 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.5+Sun/8.11.1) with ESMTP id sAP8q1M3001338;
	Tue, 25 Nov 2014 08:52:01 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.5+Sun/8.14.5/Submit) with ESMTP id
	sAP8q0Qg001335; Tue, 25 Nov 2014 08:52:00 GMT
Date: Tue, 25 Nov 2014 08:52:00 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141124140939.GA14073@zion.uk.xensource.com>
Message-ID: <alpine.GSO.2.00.1411250849030.1332@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
	<20141124140939.GA14073@zion.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: sAP8q5oA023345
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Mon, 24 Nov 2014, Wei Liu wrote:

> On Mon, Nov 24, 2014 at 01:13:25PM +0000, Andrew Cooper wrote:
>> On 24/11/14 11:50, George Dunlap wrote:
>>> On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
>>>> On Sat, 22 Nov 2014, M A Young wrote:
>>>>
>>>>> While investigating a bug reported on Red Hat Bugzilla
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>>> I discovered the following
>>>>>
>>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>>>>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>>>>> are actually two issues here
>>>>>
>>>>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>>>>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>>> presumably because the allocated memory eventually runs out
>>>>
>>>> I have found a bit more out about this. The segfault at at line 1378 of
>>>> tools/libxc/xc_domain_restore.c which is
>>>>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>>>>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>>>>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>>>>                         csum_page(buf));
>>>> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
>>>> array. This occurs in the verification phase.
>>>>
>>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>>> migration still fails. The first attached file contains the log from a run
>>>>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>>>>> stripped out to make the size manageable).
>>>>
>>>> The difference actually seems to be down to how active the VM is rather than
>>>> the memory size (my small memory test system was doing very little, my
>>>> larger system was a full OS install). In the non-segfault case the problem
>>>> was the printf and printf_info commands in the create_domain() routine in
>>>> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
>>>> back from the restoring dom0, these commands cause an unexpected message. If
>>>> you move them onto stderr then the migration completes in the non-segfault
>>>> case.
>>> Good job tracking those down -- are there patches in the works?
>>
>> The segfault for "--debug" has already been identified and a patch
>> posted by Wen Congyang
>>
>> The call to csum_page() incorrectly calculates the offset it is supposed
>> to checksum, and wanders beyond the mapping of guest space.
>>
>> Patch in 1409908261-18682-3-git-send-email-wency@cn.fujitsu.com
>>
>
> And the said patch has been applied (3460eeb3fc2) so we're fine.

However that doesn't fix my crash. I tried with it applied and still saw 
the crash. I also tried 4.5-rc1 (without XSM to avoid my other issue) and 
that crashed as well.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 08:52:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 08: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 1XtBrE-0005ws-FM; Tue, 25 Nov 2014 08:52:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XtBrD-0005wn-70
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 08:52:23 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	AA/91-02699-64344745; Tue, 25 Nov 2014 08:52:22 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416905541!14620332!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10951 invoked from network); 25 Nov 2014 08:52:22 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 08:52:22 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAP8q5oA023345;
	Tue, 25 Nov 2014 08:52:09 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAP8q1FC007581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 08:52:01 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.5+Sun/8.11.1) with ESMTP id sAP8q1M3001338;
	Tue, 25 Nov 2014 08:52:01 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.5+Sun/8.14.5/Submit) with ESMTP id
	sAP8q0Qg001335; Tue, 25 Nov 2014 08:52:00 GMT
Date: Tue, 25 Nov 2014 08:52:00 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141124140939.GA14073@zion.uk.xensource.com>
Message-ID: <alpine.GSO.2.00.1411250849030.1332@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
	<20141124140939.GA14073@zion.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: sAP8q5oA023345
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Mon, 24 Nov 2014, Wei Liu wrote:

> On Mon, Nov 24, 2014 at 01:13:25PM +0000, Andrew Cooper wrote:
>> On 24/11/14 11:50, George Dunlap wrote:
>>> On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
>>>> On Sat, 22 Nov 2014, M A Young wrote:
>>>>
>>>>> While investigating a bug reported on Red Hat Bugzilla
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
>>>>> I discovered the following
>>>>>
>>>>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
>>>>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
>>>>> are actually two issues here
>>>>>
>>>>> * the segfault in libxl-save-helper --restore-domain (as reported in the
>>>>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
>>>>> presumably because the allocated memory eventually runs out
>>>>
>>>> I have found a bit more out about this. The segfault at at line 1378 of
>>>> tools/libxc/xc_domain_restore.c which is
>>>>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>>>>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>>>>                         csum_page(region_base + (i + curbatch)*PAGE_SIZE),
>>>>                         csum_page(buf));
>>>> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
>>>> array. This occurs in the verification phase.
>>>>
>>>>> * the segfault doesn't occur if the guest memory is 128M, but the
>>>>> migration still fails. The first attached file contains the log from a run
>>>>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
>>>>> stripped out to make the size manageable).
>>>>
>>>> The difference actually seems to be down to how active the VM is rather than
>>>> the memory size (my small memory test system was doing very little, my
>>>> larger system was a full OS install). In the non-segfault case the problem
>>>> was the printf and printf_info commands in the create_domain() routine in
>>>> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
>>>> back from the restoring dom0, these commands cause an unexpected message. If
>>>> you move them onto stderr then the migration completes in the non-segfault
>>>> case.
>>> Good job tracking those down -- are there patches in the works?
>>
>> The segfault for "--debug" has already been identified and a patch
>> posted by Wen Congyang
>>
>> The call to csum_page() incorrectly calculates the offset it is supposed
>> to checksum, and wanders beyond the mapping of guest space.
>>
>> Patch in 1409908261-18682-3-git-send-email-wency@cn.fujitsu.com
>>
>
> And the said patch has been applied (3460eeb3fc2) so we're fine.

However that doesn't fix my crash. I tried with it applied and still saw 
the crash. I also tried 4.5-rc1 (without XSM to avoid my other issue) and 
that crashed as well.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 09:01:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:01:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtC0F-00067J-Ha; Tue, 25 Nov 2014 09:01:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtC0D-00067E-TC
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 09:01:42 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B1/51-17958-57544745; Tue, 25 Nov 2014 09:01:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416906100!13488666!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28932 invoked from network); 25 Nov 2014 09:01:40 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 09:01:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 09:01:40 +0000
Message-Id: <54745381020000780004A94C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 09:01:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <5474335D.8010007@suse.com>
In-Reply-To: <5474335D.8010007@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Failure on "make clean"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.11.14 at 08:44, <JGross@suse.com> wrote:
> Hi,
> 
> make clean in xen-unstable is failing:
> 
> make[2]: Entering directory '/home/gross/xen/tools'
> set -e; if test -d qemu-xen-traditional-dir/.; then \
>          make -C qemu-xen-traditional-dir clean; \
> fi
> make[3]: Entering directory 
> '/home/gross/xen/tools/qemu-xen-traditional-dir-remote'
> Makefile:3: config-host.mak: No such file or directory

SRC_PATH gets defined there. This file missing makes me wonder
whether you ran "make clean" without a prior "make". If so,
perhaps the test in tools/Makefile should be altered:

subdir-clean-qemu-xen-traditional-dir:
	set -e; if test -e qemu-xen-traditional-dir/config-host.mak; then \
		$(MAKE) -C qemu-xen-traditional-dir clean; \
	fi

(possibly in a similar way for subdir-clean-qemu-xen-dir), albeit that
may end up leaving an unclean tree when having interrupted qemu's
configure process (not sure in which order it creates files).

Jan

> Makefile:4: /rules.mak: No such file or directory
> make[3]: *** No rule to make target '/rules.mak'.  Stop.
> make[3]: Leaving directory 
> '/home/gross/xen/tools/qemu-xen-traditional-dir-remote'
> Makefile:181: recipe for target 'subdir-clean-qemu-xen-traditional-dir' 
> failed
> make[2]: *** [subdir-clean-qemu-xen-traditional-dir] Error 2
> make[2]: Leaving directory '/home/gross/xen/tools'
> /home/gross/xen/tools/../tools/Rules.mk:111: recipe for target 
> 'subdirs-clean' failed
> make[1]: *** [subdirs-clean] Error 2
> make[1]: Leaving directory '/home/gross/xen/tools'
> Makefile:139: recipe for target 'clean' failed
> make: *** [clean] Error 2
> 
> 
> I think SRC_PATH is somehow undefined...
> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Nov 25 09:01:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:01:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtC0F-00067J-Ha; Tue, 25 Nov 2014 09:01:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtC0D-00067E-TC
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 09:01:42 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B1/51-17958-57544745; Tue, 25 Nov 2014 09:01:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1416906100!13488666!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28932 invoked from network); 25 Nov 2014 09:01:40 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 09:01:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 09:01:40 +0000
Message-Id: <54745381020000780004A94C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 09:01:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <5474335D.8010007@suse.com>
In-Reply-To: <5474335D.8010007@suse.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Failure on "make clean"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.11.14 at 08:44, <JGross@suse.com> wrote:
> Hi,
> 
> make clean in xen-unstable is failing:
> 
> make[2]: Entering directory '/home/gross/xen/tools'
> set -e; if test -d qemu-xen-traditional-dir/.; then \
>          make -C qemu-xen-traditional-dir clean; \
> fi
> make[3]: Entering directory 
> '/home/gross/xen/tools/qemu-xen-traditional-dir-remote'
> Makefile:3: config-host.mak: No such file or directory

SRC_PATH gets defined there. This file missing makes me wonder
whether you ran "make clean" without a prior "make". If so,
perhaps the test in tools/Makefile should be altered:

subdir-clean-qemu-xen-traditional-dir:
	set -e; if test -e qemu-xen-traditional-dir/config-host.mak; then \
		$(MAKE) -C qemu-xen-traditional-dir clean; \
	fi

(possibly in a similar way for subdir-clean-qemu-xen-dir), albeit that
may end up leaving an unclean tree when having interrupted qemu's
configure process (not sure in which order it creates files).

Jan

> Makefile:4: /rules.mak: No such file or directory
> make[3]: *** No rule to make target '/rules.mak'.  Stop.
> make[3]: Leaving directory 
> '/home/gross/xen/tools/qemu-xen-traditional-dir-remote'
> Makefile:181: recipe for target 'subdir-clean-qemu-xen-traditional-dir' 
> failed
> make[2]: *** [subdir-clean-qemu-xen-traditional-dir] Error 2
> make[2]: Leaving directory '/home/gross/xen/tools'
> /home/gross/xen/tools/../tools/Rules.mk:111: recipe for target 
> 'subdirs-clean' failed
> make[1]: *** [subdirs-clean] Error 2
> make[1]: Leaving directory '/home/gross/xen/tools'
> Makefile:139: recipe for target 'clean' failed
> make: *** [clean] Error 2
> 
> 
> I think SRC_PATH is somehow undefined...
> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Nov 25 09:08:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:08:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtC6q-0006HT-Bl; Tue, 25 Nov 2014 09:08:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XtC6p-0006HO-4k
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:08:31 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	C2/3E-22777-E0744745; Tue, 25 Nov 2014 09:08:30 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416906507!10298096!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7915 invoked from network); 25 Nov 2014 09:08:29 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2014 09:08:29 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 02:08:26 -0700
Message-Id: <5474B784020000660007D9AA@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 02:08:20 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
	<5462343C020000660007880A@soto.provo.novell.com>
	<546490D40200006600079701@soto.provo.novell.com>
	<1415878862.21321.9.camel@citrix.com>
In-Reply-To: <1415878862.21321.9.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, George Dunlap <dunlapg@umich.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Ian,

According to previous discussion, snapshot delete and revert are
inclined to be done by high level application itself, won't supply a
libxl API. I'm wondering snapshot create need a new common API?
In fact its main work is save domain and take disk snapshot, xl can
do it too. 

I just write down an overview of the snapshot work (see below).
The problem is: do we need to export API? What kind of API?
In updating Bamvor's code, I think xl can do all the work, libvirt can
do the work too even without libxl's help.

Of course, there are some thing if put in libxl, it will be easier to
use, like the domain snapshot info structure, gentype.py will
directly generate useful init/dispose/to_json/from_json functions.
Or the disk snapshot part can be extracted and placed in libxl or libxlu.

Any suggestions about which part is better to be extracted as libxl
API or better not?

Thanks,
Chunyan

------------------------------------------------------------------------------------------------------
libxl domain snapshot overview

0. Glossary
* Active domain: domain created and started
* Inactive domain: domain created but not started
* Domain snapshot:
  Domain snapshot is a system checkpoint of a domain. It contains
  the memory status at the checkpoint and the disk status.
* Disk-only snapshot:
  Disk-only snapshot only keeps the status of disk, not saving
  memory status. It's a special kind of domain snapshot. It's valid
  when domain is inactive, or domain is paused and all cached data
  has been flushed to disk. Otherwise, disk-only snapshot is a
  useless inconsistent state.

1. Purpose

Domain snapshot is a system checkpoint of a domain. Later, one can
roll back the domain to that checkpoint. It's a very useful backup
function. A domain snapshot contains the memory status at the
checkpoint and the disk status (which we called disk snapshot).

Domain snapshot functionality should include:
* create a domain snapshot
* roll back (or called "revert") to a domain snapshot
* delete a domain snapshot
* list all domain snapshots

Domain Snapshot Support and Not Support:
* support live snapshot
* support internal disk snapshot and external disk snapshot
* support different disk backend types.
* support chain snapshots

* not support snapshot when domain is shutdowning or dying.
* not support disk-only snapshot [1].
                                       
[1]
 This is different from "libvirt".
 To xl, it only concerns active domains, and even when domain
 is paused, there is no data flush to disk operation. So, take
 a disk-only snapshot and then resume, it is as if the guest
 had crashed. For this reason, disk-only snapshot is meaningless
 to xl. Should not support.

 To libvirt, it has active domains and inactive domains, for
 the active domains, as "xl", it's meaning less to take disk-only
 snapshot, but for inactive domains, disk-only snapshot is valid.
 Should support.

2. Requirements

General Requirements:
* ability to save/restore domain memory
* ability to create/delete/apply disk snapshot [2]
* ability to parse user config file
* ability to save/load/update domain snapshot metadata (or called
  domain snapshot info, the metadata at least includes:
  snapshot name, create time, description, memory state file,
  disk snapshot info, parent (in snapshot chain), current (is
  currently applied))

[2] Disk snapshot requirements:
* external tools: qemu-img, lvcreate, vhd-util, etc.
* For a basic goal, we support 'raw' and 'qcow2' backend types only.
  Then only requires qemu:
    use libxl qmp command (better) or "qemu-img"

3. Interaction with other operations:
Generally, when domain is deleted, all snapshots should be deleted
first.

4. General workflow
Create a snapshot:
  * parse user cfg file if passed in
  * check parameter validation
  * check snapshot operation is allowed
  * save domain, saving memory status to file (refer to: save_domain)
  * take disk snapshot (call qmp command)
  * snapshot chain info:
     - get domain snapshots list (this will retrives all snapshot
       metadata files and returns a list)
     - check if domain is currently on some snapshot, if yes, then
       that snapshot is the 'parent' of our snapshot.
  * save snapshot metadata to json file
    (save/load/retrive snapshot metadata files are similar to
     save/load libxl domain config files.)

Delete a snapshot:
  * get snapshot info (retrieve corresponding snapshot metadata
    file and parse into snapshot info)
  * according to options, get snapshot chain info
    - get domain snapshot list (retrieves all snapshot metadata files
      and returns a list)
    - find parent and children of this snapshot
   * delete this snapshot or this snapshot plus children snapshot
    (according to options)
    - remove memory state file (unlink)
    - delete disk snapshot (call qmp command)
    - update snapshot metadata file of children (if not deleted),
      change 'parent'.
    - delete snapshot metadata file of this snapshot

Revert:
  * get snapshot info (retrieve corresponding snapshot metadata
    file and parse into snapshot info)
  * destroy this domain
  * create a new domain from snapshot info
    - apply disk snapshot (qemu-img)
    - a process like restore domain
  * update snapshot metadata, set 'current'.

List:
  * get snapshot info list (retrieves all snapshot metadata files
    and returns a list)
  * print in certain format according info list

>>> On 11/13/2014 at 07:41 PM, in message <1415878862.21321.9.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Wed, 2014-11-12 at 20:07 -0700, Chun Yan Liu wrote: 
> > > > By "active" here, do you you mean "live" (vs paused)?  
> > > Means the domain is started (no matter is running or paused).  
> > > vs (libvirt defines a domain but not started).  
> > > Here,  I should update this to:  
> > > 3). take disk snapshot by qmp command  
> > > libxl only handles active domain.  
>  
> I think the problem here is that different components in the system use 
> different terminology for things or even different concepts (e.g. libxl 
> has no inherent concept of inactive vs active domains, because it only 
> concerns itself with active domains). 
>  
> Perhaps a glossary defining these things would help (also see below). 
>  
> > > > >    libxl_domain_snapshot_delete:   
> > > > >        1). check args validation   
> > > > >        2). remove memory state file.   
> > > > >        3). delete disk snapshot. (for internal disk snapshot, through  
> qmp   
> > > > >            command or qemu-img command)   
> > > >    
> > > > Out of curiosity, why is this necessary?  Is libxl keeping track of   
> > > > the snapshots somewhere?  Or qemu?   
> > > >    
> > > > Or to put it a different way, since the caller knows the filenames,   
> > > > why can't the caller just erase the files themselves?  
> > >   
> > > Ian asks the same question. The only reason I propose an API is:  
> > > xl and libvirt can share the code. And in future, when support many other   
>  
> > > disk  
> > > backend types, there is much repeated code. But as Ian mentioned in  
> > > last version, for handling many disk backend types, maybe better placed in  
>  
> > > libxlu. Well, if both of you object, I'll remove this API.  
>  
> I think the reason we are having these same discussions over again is 
> that this proposal is focusing on the libxl API (e.g. the details of 
> what functions exist and what parameters they take) without an 
> introductory section which provides a broad overview of the 
> architecture, containing e.g. things like: 
>  
>       * What the general requirements for domain snapshotting are; 
>       * What are the constraints which we are operating under; e.g. 
>         libvirt or xl design requirements 
>       * What the various components are (and which, possibly multiple, 
>         entities provide them) and where the various responsibilities 
>         lie. 
>  
> I think we've teased a lot of this sort of thing out in past iterations 
> but without having it written down here I think we are all having 
> trouble agreeing (or remembering that we've agreed) that the API makes 
> sense because we all have different ideas about what the higher level 
> architecture/abstraction should look like. 
>  
> See for example 
> http://xenbits.xen.org/people/dvrabel/event-channels-H.pdf or 
> http://lists.xen.org/archives/html/xen-devel/2014-10/msg03235.html (you 
> don't necessarily need to go all out on that level of formality, but 
> they provide some examples of the sorts of higher level design I'm 
> talking about) 
>  
> I think it would also help with the glossary question above since it 
> would help define the terms. 
>  
> I'm sorry for not observing this sooner. 
>  
> 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 Nov 25 09:08:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:08:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtC6q-0006HT-Bl; Tue, 25 Nov 2014 09:08:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XtC6p-0006HO-4k
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:08:31 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	C2/3E-22777-E0744745; Tue, 25 Nov 2014 09:08:30 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416906507!10298096!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7915 invoked from network); 25 Nov 2014 09:08:29 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2014 09:08:29 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 02:08:26 -0700
Message-Id: <5474B784020000660007D9AA@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 02:08:20 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
	<5462343C020000660007880A@soto.provo.novell.com>
	<546490D40200006600079701@soto.provo.novell.com>
	<1415878862.21321.9.camel@citrix.com>
In-Reply-To: <1415878862.21321.9.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, George Dunlap <dunlapg@umich.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Ian,

According to previous discussion, snapshot delete and revert are
inclined to be done by high level application itself, won't supply a
libxl API. I'm wondering snapshot create need a new common API?
In fact its main work is save domain and take disk snapshot, xl can
do it too. 

I just write down an overview of the snapshot work (see below).
The problem is: do we need to export API? What kind of API?
In updating Bamvor's code, I think xl can do all the work, libvirt can
do the work too even without libxl's help.

Of course, there are some thing if put in libxl, it will be easier to
use, like the domain snapshot info structure, gentype.py will
directly generate useful init/dispose/to_json/from_json functions.
Or the disk snapshot part can be extracted and placed in libxl or libxlu.

Any suggestions about which part is better to be extracted as libxl
API or better not?

Thanks,
Chunyan

------------------------------------------------------------------------------------------------------
libxl domain snapshot overview

0. Glossary
* Active domain: domain created and started
* Inactive domain: domain created but not started
* Domain snapshot:
  Domain snapshot is a system checkpoint of a domain. It contains
  the memory status at the checkpoint and the disk status.
* Disk-only snapshot:
  Disk-only snapshot only keeps the status of disk, not saving
  memory status. It's a special kind of domain snapshot. It's valid
  when domain is inactive, or domain is paused and all cached data
  has been flushed to disk. Otherwise, disk-only snapshot is a
  useless inconsistent state.

1. Purpose

Domain snapshot is a system checkpoint of a domain. Later, one can
roll back the domain to that checkpoint. It's a very useful backup
function. A domain snapshot contains the memory status at the
checkpoint and the disk status (which we called disk snapshot).

Domain snapshot functionality should include:
* create a domain snapshot
* roll back (or called "revert") to a domain snapshot
* delete a domain snapshot
* list all domain snapshots

Domain Snapshot Support and Not Support:
* support live snapshot
* support internal disk snapshot and external disk snapshot
* support different disk backend types.
* support chain snapshots

* not support snapshot when domain is shutdowning or dying.
* not support disk-only snapshot [1].
                                       
[1]
 This is different from "libvirt".
 To xl, it only concerns active domains, and even when domain
 is paused, there is no data flush to disk operation. So, take
 a disk-only snapshot and then resume, it is as if the guest
 had crashed. For this reason, disk-only snapshot is meaningless
 to xl. Should not support.

 To libvirt, it has active domains and inactive domains, for
 the active domains, as "xl", it's meaning less to take disk-only
 snapshot, but for inactive domains, disk-only snapshot is valid.
 Should support.

2. Requirements

General Requirements:
* ability to save/restore domain memory
* ability to create/delete/apply disk snapshot [2]
* ability to parse user config file
* ability to save/load/update domain snapshot metadata (or called
  domain snapshot info, the metadata at least includes:
  snapshot name, create time, description, memory state file,
  disk snapshot info, parent (in snapshot chain), current (is
  currently applied))

[2] Disk snapshot requirements:
* external tools: qemu-img, lvcreate, vhd-util, etc.
* For a basic goal, we support 'raw' and 'qcow2' backend types only.
  Then only requires qemu:
    use libxl qmp command (better) or "qemu-img"

3. Interaction with other operations:
Generally, when domain is deleted, all snapshots should be deleted
first.

4. General workflow
Create a snapshot:
  * parse user cfg file if passed in
  * check parameter validation
  * check snapshot operation is allowed
  * save domain, saving memory status to file (refer to: save_domain)
  * take disk snapshot (call qmp command)
  * snapshot chain info:
     - get domain snapshots list (this will retrives all snapshot
       metadata files and returns a list)
     - check if domain is currently on some snapshot, if yes, then
       that snapshot is the 'parent' of our snapshot.
  * save snapshot metadata to json file
    (save/load/retrive snapshot metadata files are similar to
     save/load libxl domain config files.)

Delete a snapshot:
  * get snapshot info (retrieve corresponding snapshot metadata
    file and parse into snapshot info)
  * according to options, get snapshot chain info
    - get domain snapshot list (retrieves all snapshot metadata files
      and returns a list)
    - find parent and children of this snapshot
   * delete this snapshot or this snapshot plus children snapshot
    (according to options)
    - remove memory state file (unlink)
    - delete disk snapshot (call qmp command)
    - update snapshot metadata file of children (if not deleted),
      change 'parent'.
    - delete snapshot metadata file of this snapshot

Revert:
  * get snapshot info (retrieve corresponding snapshot metadata
    file and parse into snapshot info)
  * destroy this domain
  * create a new domain from snapshot info
    - apply disk snapshot (qemu-img)
    - a process like restore domain
  * update snapshot metadata, set 'current'.

List:
  * get snapshot info list (retrieves all snapshot metadata files
    and returns a list)
  * print in certain format according info list

>>> On 11/13/2014 at 07:41 PM, in message <1415878862.21321.9.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Wed, 2014-11-12 at 20:07 -0700, Chun Yan Liu wrote: 
> > > > By "active" here, do you you mean "live" (vs paused)?  
> > > Means the domain is started (no matter is running or paused).  
> > > vs (libvirt defines a domain but not started).  
> > > Here,  I should update this to:  
> > > 3). take disk snapshot by qmp command  
> > > libxl only handles active domain.  
>  
> I think the problem here is that different components in the system use 
> different terminology for things or even different concepts (e.g. libxl 
> has no inherent concept of inactive vs active domains, because it only 
> concerns itself with active domains). 
>  
> Perhaps a glossary defining these things would help (also see below). 
>  
> > > > >    libxl_domain_snapshot_delete:   
> > > > >        1). check args validation   
> > > > >        2). remove memory state file.   
> > > > >        3). delete disk snapshot. (for internal disk snapshot, through  
> qmp   
> > > > >            command or qemu-img command)   
> > > >    
> > > > Out of curiosity, why is this necessary?  Is libxl keeping track of   
> > > > the snapshots somewhere?  Or qemu?   
> > > >    
> > > > Or to put it a different way, since the caller knows the filenames,   
> > > > why can't the caller just erase the files themselves?  
> > >   
> > > Ian asks the same question. The only reason I propose an API is:  
> > > xl and libvirt can share the code. And in future, when support many other   
>  
> > > disk  
> > > backend types, there is much repeated code. But as Ian mentioned in  
> > > last version, for handling many disk backend types, maybe better placed in  
>  
> > > libxlu. Well, if both of you object, I'll remove this API.  
>  
> I think the reason we are having these same discussions over again is 
> that this proposal is focusing on the libxl API (e.g. the details of 
> what functions exist and what parameters they take) without an 
> introductory section which provides a broad overview of the 
> architecture, containing e.g. things like: 
>  
>       * What the general requirements for domain snapshotting are; 
>       * What are the constraints which we are operating under; e.g. 
>         libvirt or xl design requirements 
>       * What the various components are (and which, possibly multiple, 
>         entities provide them) and where the various responsibilities 
>         lie. 
>  
> I think we've teased a lot of this sort of thing out in past iterations 
> but without having it written down here I think we are all having 
> trouble agreeing (or remembering that we've agreed) that the API makes 
> sense because we all have different ideas about what the higher level 
> architecture/abstraction should look like. 
>  
> See for example 
> http://xenbits.xen.org/people/dvrabel/event-channels-H.pdf or 
> http://lists.xen.org/archives/html/xen-devel/2014-10/msg03235.html (you 
> don't necessarily need to go all out on that level of formality, but 
> they provide some examples of the sorts of higher level design I'm 
> talking about) 
>  
> I think it would also help with the glossary question above since it 
> would help define the terms. 
>  
> I'm sorry for not observing this sooner. 
>  
> 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 Nov 25 09:15:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:15:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtCDu-0006So-DH; Tue, 25 Nov 2014 09:15:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtCDs-0006Sj-SS
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:15:48 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	52/9B-14214-4C844745; Tue, 25 Nov 2014 09:15:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416906945!9829494!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11290 invoked from network); 25 Nov 2014 09:15:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 09:15:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,454,1413244800"; d="scan'208";a="196466609"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 04:15:39 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtCDj-0004KB-9s;
	Tue, 25 Nov 2014 09:15:39 +0000
Date: Tue, 25 Nov 2014 09:15:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141125091539.GA17596@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
	<20141124140939.GA14073@zion.uk.xensource.com>
	<alpine.GSO.2.00.1411250849030.1332@algedi.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.GSO.2.00.1411250849030.1332@algedi.dur.ac.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 08:52:00AM +0000, M A Young wrote:
[...]
> >
> >And the said patch has been applied (3460eeb3fc2) so we're fine.
> 
> However that doesn't fix my crash. I tried with it applied and still saw the
> crash. I also tried 4.5-rc1 (without XSM to avoid my other issue) and that
> crashed as well.
> 

And the log is still the same? If the crash happens in different
location it might be another bug.

Wei.

> 	Michael Young
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 09:15:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:15:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtCDu-0006So-DH; Tue, 25 Nov 2014 09:15:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtCDs-0006Sj-SS
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:15:48 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	52/9B-14214-4C844745; Tue, 25 Nov 2014 09:15:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416906945!9829494!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11290 invoked from network); 25 Nov 2014 09:15:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 09:15:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,454,1413244800"; d="scan'208";a="196466609"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 04:15:39 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtCDj-0004KB-9s;
	Tue, 25 Nov 2014 09:15:39 +0000
Date: Tue, 25 Nov 2014 09:15:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141125091539.GA17596@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
	<20141124140939.GA14073@zion.uk.xensource.com>
	<alpine.GSO.2.00.1411250849030.1332@algedi.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.GSO.2.00.1411250849030.1332@algedi.dur.ac.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 08:52:00AM +0000, M A Young wrote:
[...]
> >
> >And the said patch has been applied (3460eeb3fc2) so we're fine.
> 
> However that doesn't fix my crash. I tried with it applied and still saw the
> crash. I also tried 4.5-rc1 (without XSM to avoid my other issue) and that
> crashed as well.
> 

And the log is still the same? If the crash happens in different
location it might be another bug.

Wei.

> 	Michael Young
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 09:25:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:25:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtCMY-0006d8-F4; Tue, 25 Nov 2014 09:24:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtCMX-0006d3-4R
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 09:24:45 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	18/F8-02954-CDA44745; Tue, 25 Nov 2014 09:24:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416907483!14638574!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6627 invoked from network); 25 Nov 2014 09:24:43 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 09:24:43 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 17157ABE2
	for <xen-devel@lists.xenproject.org>;
	Tue, 25 Nov 2014 09:24:42 +0000 (UTC)
Message-ID: <54744ADA.10504@suse.com>
Date: Tue, 25 Nov 2014 10:24:42 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5474335D.8010007@suse.com> <54745381020000780004A94C@suse.com>
In-Reply-To: <54745381020000780004A94C@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Failure on "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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 10:01 AM, Jan Beulich wrote:
>>>> On 25.11.14 at 08:44, <JGross@suse.com> wrote:
>> Hi,
>>
>> make clean in xen-unstable is failing:
>>
>> make[2]: Entering directory '/home/gross/xen/tools'
>> set -e; if test -d qemu-xen-traditional-dir/.; then \
>>           make -C qemu-xen-traditional-dir clean; \
>> fi
>> make[3]: Entering directory
>> '/home/gross/xen/tools/qemu-xen-traditional-dir-remote'
>> Makefile:3: config-host.mak: No such file or directory
>
> SRC_PATH gets defined there. This file missing makes me wonder
> whether you ran "make clean" without a prior "make". If so,
> perhaps the test in tools/Makefile should be altered:
>
> subdir-clean-qemu-xen-traditional-dir:
> 	set -e; if test -e qemu-xen-traditional-dir/config-host.mak; then \
> 		$(MAKE) -C qemu-xen-traditional-dir clean; \
> 	fi
>
> (possibly in a similar way for subdir-clean-qemu-xen-dir), albeit that
> may end up leaving an unclean tree when having interrupted qemu's
> configure process (not sure in which order it creates files).

I called "make subtree-force-update" before "make clean". This wipes
out tools/qemu-xen-traditional-dir IMHO.

Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 09:25:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:25:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtCMY-0006d8-F4; Tue, 25 Nov 2014 09:24:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtCMX-0006d3-4R
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 09:24:45 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	18/F8-02954-CDA44745; Tue, 25 Nov 2014 09:24:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416907483!14638574!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6627 invoked from network); 25 Nov 2014 09:24:43 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 09:24:43 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 17157ABE2
	for <xen-devel@lists.xenproject.org>;
	Tue, 25 Nov 2014 09:24:42 +0000 (UTC)
Message-ID: <54744ADA.10504@suse.com>
Date: Tue, 25 Nov 2014 10:24:42 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5474335D.8010007@suse.com> <54745381020000780004A94C@suse.com>
In-Reply-To: <54745381020000780004A94C@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Failure on "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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 10:01 AM, Jan Beulich wrote:
>>>> On 25.11.14 at 08:44, <JGross@suse.com> wrote:
>> Hi,
>>
>> make clean in xen-unstable is failing:
>>
>> make[2]: Entering directory '/home/gross/xen/tools'
>> set -e; if test -d qemu-xen-traditional-dir/.; then \
>>           make -C qemu-xen-traditional-dir clean; \
>> fi
>> make[3]: Entering directory
>> '/home/gross/xen/tools/qemu-xen-traditional-dir-remote'
>> Makefile:3: config-host.mak: No such file or directory
>
> SRC_PATH gets defined there. This file missing makes me wonder
> whether you ran "make clean" without a prior "make". If so,
> perhaps the test in tools/Makefile should be altered:
>
> subdir-clean-qemu-xen-traditional-dir:
> 	set -e; if test -e qemu-xen-traditional-dir/config-host.mak; then \
> 		$(MAKE) -C qemu-xen-traditional-dir clean; \
> 	fi
>
> (possibly in a similar way for subdir-clean-qemu-xen-dir), albeit that
> may end up leaving an unclean tree when having interrupted qemu's
> configure process (not sure in which order it creates files).

I called "make subtree-force-update" before "make clean". This wipes
out tools/qemu-xen-traditional-dir IMHO.

Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 09:39:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09: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 1XtCaH-0006no-Rs; Tue, 25 Nov 2014 09:38:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XtCaF-0006nj-EI
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:38:55 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	19/B1-02697-E2E44745; Tue, 25 Nov 2014 09:38:54 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416908331!9069383!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21054 invoked from network); 25 Nov 2014 09:38:52 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2014 09:38:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416908330; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=m0e8DL+l/q4YV4L7EYCRPYH9m5hiivjm+Et85w/4WbE=;
	b=xD5zvI7nx8B7/ZfH+8uptZcZT/OjmAC9haCKV0RfTc9CXFEv7lfzMOlCymKwMOjm/lHdZE338mrsJLniXwmrQFd0qzLpQ5gq+fUiwmbX7jNzG9C3EDvvNq2MHUwvM/xxLrsScDUvE2maEhd4p5rrX1wfYN+vTmsVWOo0/UP5+us=
Received: from [10.0.0.112] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Tue, 25 Nov 2014 01:38:50 -0800
	id 00000000000305D3.54744E2A.00002A5B
Message-ID: <54744E29.8060703@ihonk.com>
Date: Tue, 25 Nov 2014 01:38:49 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5457F79B.2020300@ihonk.com>
	<20141104082012.GY12451@reaktio.net>	<5458B55C0200007800044B33@mail.emea.novell.com>	<5460716A.7090905@ihonk.com>	<54608A8B0200007800045E58@mail.emea.novell.com>	<54611A86.4000200@ihonk.com>	<5461D15C02000078000464D7@mail.emea.novell.com>	<546A4AD4.3030002@ihonk.com>	<546B094C0200007800048A5C@mail.emea.novell.com>	<546D429A.5020906@ihonk.com>	<546DAD6502000078000492FD@mail.emea.novell.com>	<546E4A17.5040902@ihonk.com>	<546F091F0200007800049A1C@smtp.nue.novell.com>	<54713848.3020401@ihonk.com>	<5472FE31020000780004A2D5@mail.emea.novell.com>	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>	<54732768020000780004A48C@mail.emea.novell.com>	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
In-Reply-To: <547448D7020000780004A919@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 12:16 AM, Jan Beulich wrote:
>> (XEN) 'c' pressed -> printing ACPI Cx structures
>> (XEN) ==cpu0==
>> (XEN) active state:        C0
>> (XEN) max_cstate:        C7
>> (XEN) states:
>> (XEN)     C1:    type[C1] latency[001] usage[00005664] method[  FFH] duration[4042540627]
>> (XEN)     C2:    type[C3] latency[064] usage[00000414] method[  FFH] duration[447258888]
>> (XEN)     C3:    type[C3] latency[096] usage[00002366] method[  FFH] duration[28183588810]
>> (XEN)    *C0:    usage[00008444] duration[26752178344]
>> (XEN) max=0 pwr=0 urg=0 nxt=0
>> (XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
>> (XEN) CC3[484210884] CC6[27943480555] CC7[0]
> Interesting, so other than for me (perhaps due to other patches
> I have in my tree) the change resulted in C states now being used
> again despite mwait-idle=0, which is good. Question now is - with
> this being the case, did the hangs re-occur?

Unfortunately they did. (Happened unusually quick this time, though I 
doubt the statistical significance.) Not sure what the desirable output 
is, so I did a couple of 'a' and 'd' requests, capped off by a 'c':

(XEN) *** Dumping CPU0 host state: ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82d08012c9a2>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a943d000   rcx: 0000000000000000
(XEN) rdx: ffff82d0802e0000   rsi: 0000000000000008   rdi: ffff82d080329308
(XEN) rbp: ffff82d0802e7ec8   rsp: ffff82d0802e7e40   r8: ffff82d080329320
(XEN) r9:  0000000000000000   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: 000001227e5280e4   r13: ffff8300a943d000   r14: ffff82d080329308
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1b57c000   cr2: 000007fefca62000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff82d0802e7e40:
(XEN)    ffff82d080128cb5 ffff82d080329300 ffff82d080329320 00000000002e7e78
(XEN)    ffff82d080329300 ffff82d0801b977e ffff8300a943d000 fffff88002f36d70
(XEN)    ffff8300a943d000 0000000001c9c380 ffff82d0801e5600 ffff82d0802e7f08
(XEN)    ffff82d080300080 ffff82d080300080 ffffffffffffffff ffff82d0802e0000
(XEN)    fffffa8004fdff80 ffff82d0802e7ef8 ffff82d08012bfa3 ffff8300a943d000
(XEN)    fffff88002f36d70 0000018507f7ef25 000000000000000f ffff82d0802e7f08
(XEN)    ffff82d08012bffb 000000000000000f ffff82d0801e849a fffffa8004fdff80
(XEN)    000000000000000f 0000018507f7ef25 fffff88002f36d70 000000000000000f
(XEN)    fffff88002f2c180 fffff88002f36d70 fffff88002f2c2a0 fffff880043cb960
(XEN)    fffff88002f2c2a0 0000000000000002 fffff88002f2c1c0 0000000000000400
(XEN)    0000000000000000 fffff88002f36eb0 0000beef0000beef fffff8000293e20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002f36c20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000000 ffff8300a943d000 0000000000000000 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012c9a2>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012bfa3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012bffb>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e849a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v3): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000293e20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  fffff880043cb960   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 0000018507f7ef25   r14: 000000000000000f
(XEN) r15: fffffa8004fdff80   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 00000000536d9000   cr2: 000007fefca62000
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v4): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000293e20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  fffff88002fcaca0   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 0000000000000000   r14: 000000000000000f
(XEN) r15: fffff88002fa6fc0   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffaf478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v5): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000293e20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000001526da65c1e   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 0000018507f90b28   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fefabb2654
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v1): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff80002e052bf>]
(XEN) RFLAGS: 0000000000000006   CONTEXT: hvm guest
(XEN) rax: 000002be8e13da4d   rbx: 000002be8e13e51b   rcx: 000000000000ffff
(XEN) rdx: 000002be00000000   rsi: 0000000000000000   rdi: 00000000000000a5
(XEN) rbp: 000000000000bad2   rsp: fffff88007bd8e80   r8: fffff88007bd8ee0
(XEN) r9:  0000000000000000   r10: fffff88007bd8f30   r11: 000000034291bff0
(XEN) r12: fffff88007bd92b8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 000000005c4ec000   cr2: 000000007730853f
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v0): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000293e20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a00e80   rcx: fffff80002a00ec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80003cfce70
(XEN) rbp: 000000000000000f   rsp: fffff80003cfcbe0   r8: fffff80002a00fa0
(XEN) r9:  0000000000000000   r10: fffff80002a00fa0   r11: fffff80003cfcd30
(XEN) r12: fffff80003cfcd30   r13: 0000018507f832b0   r14: 000000000000000f
(XEN) r15: 0000000000020181   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 00000000b3b80000   cr2: 000007fefcf91444
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v2): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000293e20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  fffff88006775960   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000018507fa203d   r14: 000000000000000f
(XEN) r15: fffffa800451a130   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 000000009b3e8000   cr2: fffff98006d0b008
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        9736us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=       99892us timer=ffff8300bf52c060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52c000)
(XEN)   ex=       10359us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=   101576185us timer=ffff82d080325260 
cb=plt_overflow(0000000000000000)
(XEN)   ex=     7904630us timer=ffff82d080327560 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=      100351us timer=ffff82d080325300 
cb=time_calibration(0000000000000000)
(XEN)   ex=       19736us timer=ffff82d0803295e0 
cb=do_dbs_timer(ffff82d080329620)
(XEN) CPU01:
(XEN)   ex=        9996us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=       19736us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=       30028us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=         177us timer=ffff830c3dc79858 
cb=csched_tick(0000000000000002)
(XEN)   ex=      103892us timer=ffff8300bf52e060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52e000)
(XEN)   ex=         565us timer=ffff8300bf52d060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52d000)
(XEN)   ex=      103892us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex= 80621762913us timer=ffff830c17cc2290 
cb=rtc_alarm_cb(ffff830c17cc21f0)
(XEN)   ex=       19736us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=        1036us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=        9518us timer=ffff830c3dcac0e8 
cb=csched_tick(0000000000000003)
(XEN)   ex=       19736us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex=       30053us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=       10042us timer=ffff830c3dcac968 
cb=csched_tick(0000000000000004)
(XEN)   ex=       19736us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=      103892us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=       30059us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=       10044us timer=ffff830c3dc8d208 
cb=csched_tick(0000000000000005)
(XEN)   ex=       19736us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=    74855186us timer=ffff830c17cc25d0 
cb=pmt_timer_callback(ffff830c17cc25a8)
(XEN)   ex=       23892us timer=ffff8300bf52f060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52f000)
(XEN)   ex=       30068us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v0): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000293e20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a00e80   rcx: fffff80002a00ec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80003cfce70
(XEN) rbp: 000000000000000f   rsp: fffff80003cfcbe0   r8: fffff80002a00fa0
(XEN) r9:  0000000000000000   r10: fffff80002a00fa0   r11: fffff80003cfcd30
(XEN) r12: fffff80003cfcd30   r13: 0000018507f832b0   r14: 000000000000000f
(XEN) r15: 0000000000020181   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 00000000b3b80000   cr2: 000007fefcf91444
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v5): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000293e20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000001526da65c1e   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 0000018507f90b28   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fefabb2654
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 host state: ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    e008:[<ffff82d0801dc4ca>] vmx_do_resume+0x1/0x154
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: ffff8300a943d000   rbx: ffff8300a943d000   rcx: 0000000000000002
(XEN) rdx: ffff830c3dcb0000   rsi: 0000000000000004   rdi: ffff8300a943d000
(XEN) rbp: ffff830c3dcb7e38   rsp: ffff830c3dcb7e28   r8: ffff830c3dcb80a0
(XEN) r9:  0000000000000000   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: 00000123d6398bd9   r13: ffff8300a943d000   r14: ffff830c3dcb8088
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1b57c000   cr2: 000007fefca62000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dcb7e28:
(XEN)    ffff830c3dcb7e38 ffff82d080165e89 ffff830c3dcb7ec8 ffff82d080128cef
(XEN)    ffff82d080329300 ffff830c3dcb80a0 0000000200cb7e78 ffff830c3dcb8080
(XEN)    ffff82d0801b977e ffff8300a943d000 fffff88002f36d70 ffff8300a943d000
(XEN)    0000000001c9c380 ffff82d0801e5600 ffff830c3dcb7f08 ffff82d080300180
(XEN)    ffff82d080300080 ffffffffffffffff ffff830c3dcb0000 fffffa8004fdff80
(XEN)    ffff830c3dcb7ef8 ffff82d08012bfa3 ffff8300a943d000 fffff88002f36d70
(XEN)    0000018507f7ef25 000000000000000f ffff830c3dcb7f08 ffff82d08012bffb
(XEN)    000000000000000f ffff82d0801e849a fffffa8004fdff80 000000000000000f
(XEN)    0000018507f7ef25 fffff88002f36d70 000000000000000f fffff88002f2c180
(XEN)    fffff88002f36d70 fffff88002f2c2a0 fffff880043cb960 fffff88002f2c2a0
(XEN)    0000000000000002 fffff88002f2c1c0 0000000000000400 0000000000000000
(XEN)    fffff88002f36eb0 0000beef0000beef fffff8000293e20c 000000bf0000beef
(XEN)    0000000000000046 fffff88002f36c20 000000000000beef 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 0000000000000002
(XEN)    ffff8300a943d000 0000003bbd98ed80 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801dc4ca>] vmx_do_resume+0x1/0x154
(XEN)    [<ffff82d080128cef>] schedule+0x1b5/0x612
(XEN)    [<ffff82d08012bfa3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012bffb>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e849a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v3): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000293e20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  fffff880043cb960   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 0000018507f7ef25   r14: 000000000000000f
(XEN) r15: fffffa8004fdff80   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 00000000536d9000   cr2: 000007fefca62000
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d08010009f>] __bitmap_empty+0x8/0x96
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff82d080313e00   rcx: 0000000000000006
(XEN) rdx: 0000000000000004   rsi: 0000000000000006   rdi: ffff82d080313e00
(XEN) rbp: ffff830c3dca7e58   rsp: ffff830c3dca7e58   r8: 0000000000000045
(XEN) r9:  000000000000006d   r10: 0000000000000000   r11: fffff88002facd70
(XEN) r12: 0000000000000100   r13: 0000000000000000   r14: ffff830c3dca0000
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1815b000   cr2: 000007fffffaf478
(XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7e58:
(XEN)    ffff830c3dca7e88 ffff82d080186e22 ffff82d0801b977e ffff830c3dca7e98
(XEN)    ffff82d080300080 ffffffffffffffff ffff830c3dca7ec8 ffff82d080186ea2
(XEN)    0000000000000037 0000000000000000 0000000000000000 0000000000000000
(XEN)    ffff830c3dca0000 ffff82d080300200 ffff830c3dca7ef8 ffff82d08012bfa3
(XEN)    ffff8300bf52c000 ffff8300a943c000 0000000000000001 ffff830c3dcaa088
(XEN)    ffff830c3dca7f08 ffff82d08012bffb ffff830c3dca7de8 ffff82d08022fd51
(XEN)    0000000000000000 00000000ffffffed 0000000000000000 ffff880bce434000
(XEN)    0000000000000004 ffffffff818e1800 0000000000000246 ffff880aef7e7aa8
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff810013aa
(XEN)    0000000000000001 00000000deadbeef 00000000deadbeef 0002010000000000
(XEN)    ffffffff810013aa 000000000000e033 0000000000000246 ffff880bce437ec8
(XEN)    000000000000e02b 000000000000beef 000000000000beef 000000000000beef
(XEN)    000000000000beef 0000000000000003 ffff8300bf52c000 0000003bbd980d80
(XEN)    0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08010009f>] __bitmap_empty+0x8/0x96
(XEN)    [<ffff82d080186e22>] flush_area_mask+0x119/0x134
(XEN)    [<ffff82d080186ea2>] new_tlbflush_clock_period+0x65/0x81
(XEN)    [<ffff82d08012bfa3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012bffb>] do_softirq+0x13/0x15
(XEN)    [<ffff82d08022fd51>] process_softirqs+0x21/0x30
(XEN)
(XEN) *** Dumping CPU3 guest state (d0v4): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e033:[<ffffffff810013aa>]
(XEN) RFLAGS: 0000000000000246   EM: 0   CONTEXT: pv guest
(XEN) rax: 0000000000000000   rbx: ffffffff818e1800   rcx: ffffffff810013aa
(XEN) rdx: 0000000000000001   rsi: 00000000deadbeef   rdi: 00000000deadbeef
(XEN) rbp: 0000000000000004   rsp: ffff880bce437ec8   r8: 0000000000000000
(XEN) r9:  0000000000000000   r10: ffff880aef7e7aa8   r11: 0000000000000246
(XEN) r12: ffff880bce434000   r13: 0000000000000000   r14: 00000000ffffffed
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1815b000   cr2: 00007fd8239b7000
(XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffff880bce437ec8:
(XEN)    0000000000000000 ffffffff81855060 ffffffff81009e0c ffffffff8101c849
(XEN)    ffffffff818e1800 0000000000000000 ffffffff810a5d80 ffff880bce434000
(XEN)    0000000000000004 ffff880bce434000 ffff880bce437fd8 c789d0ce26296124
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 ffffffffffffffff 0000000000000000 0000000000000010
(XEN)    0000000000000202 ffff880bce437f58 0000000000000018
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v1): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff80002e052c1>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 000002c273235b8e   rbx: 000002c273236218   rcx: 000000000000ffff
(XEN) rdx: 000002c200000000   rsi: 0000000000000000   rdi: 0000000000000089
(XEN) rbp: 000000000000a191   rsp: fffff88007bd8e80   r8: fffff88007bd8ee0
(XEN) r9:  0000000000000000   r10: fffff88007bd8f30   r11: 000000034291bff0
(XEN) r12: fffff88007bd92b8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 000000005c4ec000   cr2: 000000007730853f
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v2): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000293e214>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  fffff88006775960   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000018507fa203d   r14: 000000000000000f
(XEN) r15: fffffa800451a130   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 000000009b3e8000   cr2: fffff98006d0b008
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        3238us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=        3238us timer=ffff82d0803295e0 
cb=do_dbs_timer(ffff82d080329620)
(XEN)   ex=       23022us timer=ffff8300bf52e060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52e000)
(XEN)   ex=      984001us timer=ffff82d080325300 
cb=time_calibration(0000000000000000)
(XEN)   ex=    97459687us timer=ffff82d080325260 
cb=plt_overflow(0000000000000000)
(XEN)   ex=     3788132us timer=ffff82d080327560 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=       27212us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex= 80617646415us timer=ffff830c17cc2290 
cb=rtc_alarm_cb(ffff830c17cc21f0)
(XEN) CPU01:
(XEN)   ex=        3129us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=        3238us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=       30029us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=        3238us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=        3359us timer=ffff830c3dc79858 
cb=csched_tick(0000000000000002)
(XEN)   ex=      945174us timer=ffff8300bf52c060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52c000)
(XEN)   ex=      771394us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=       30036us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=        3238us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex=        6099us timer=ffff830c3dcac0e8 
cb=csched_tick(0000000000000003)
(XEN)   ex=     3987394us timer=ffff8300bf52d060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52d000)
(XEN)   ex=       15394us timer=ffff8300bf52f060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52f000)
(XEN)   ex=       30047us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=         296us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=        1060us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=        6764us timer=ffff830c3dcac968 
cb=csched_tick(0000000000000004)
(XEN)   ex=        3238us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN) CPU05:
(XEN)   ex=        3238us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=        7336us timer=ffff830c3dc8d208 
cb=csched_tick(0000000000000005)
(XEN)   ex=    70738688us timer=ffff830c17cc25d0 
cb=pmt_timer_callback(ffff830c17cc25a8)
(XEN)   ex=       30070us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00879961] method[  FFH] 
duration[258917692906]
(XEN)     C2:   type[C3] latency[064] usage[00219972] method[  FFH] 
duration[185157317681]
(XEN)     C3:   type[C3] latency[096] usage[00021194] method[  FFH] 
duration[130347582819]
(XEN)    *C0:   usage[01121127] duration[742037344879]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[178118468514] CC6[120838993791] CC7[0]
(XEN) ==cpu1==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00732768] method[  FFH] 
duration[244601938735]
(XEN)     C2:   type[C3] latency[064] usage[00241040] method[  FFH] 
duration[205647145982]
(XEN)     C3:   type[C3] latency[096] usage[00017258] method[  FFH] 
duration[164619828246]
(XEN)    *C0:   usage[00991066] duration[701591066797]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[197708830338] CC6[153278778335] CC7[0]
(XEN) ==cpu2==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00736573] method[  FFH] 
duration[239398385639]
(XEN)     C2:   type[C3] latency[064] usage[00243735] method[  FFH] 
duration[208117053326]
(XEN)     C3:   type[C3] latency[096] usage[00018811] method[  FFH] 
duration[163124076095]
(XEN)    *C0:   usage[00999119] duration[705820535124]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[201124993103] CC6[147956371559] CC7[0]
(XEN) ==cpu3==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00737249] method[  FFH] 
duration[241046283679]
(XEN)     C2:   type[C3] latency[064] usage[00244020] method[  FFH] 
duration[210189165328]
(XEN)     C3:   type[C3] latency[096] usage[00016474] method[  FFH] 
duration[164857248289]
(XEN)    *C0:   usage[00997743] duration[700367394408]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[202741688061] CC6[152613177986] CC7[0]
(XEN) ==cpu4==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00784949] method[  FFH] 
duration[238150508853]
(XEN)     C2:   type[C3] latency[064] usage[00242440] method[  FFH] 
duration[208233744834]
(XEN)     C3:   type[C3] latency[096] usage[00017019] method[  FFH] 
duration[166844569919]
(XEN)    *C0:   usage[01044408] duration[703231307727]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[200748358163] CC6[153896919179] CC7[0]
(XEN) ==cpu5==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00881857] method[  FFH] 
duration[277043571093]
(XEN)     C2:   type[C3] latency[064] usage[00201963] method[  FFH] 
duration[172166602574]
(XEN)     C3:   type[C3] latency[096] usage[00018587] method[  FFH] 
duration[161929908741]
(XEN)    *C0:   usage[01102407] duration[705320088716]
(XEN) max=0 pwr=0 urg=2d nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[166777643669] CC6[150006253526] CC7[0]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 09:39:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09: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 1XtCaH-0006no-Rs; Tue, 25 Nov 2014 09:38:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XtCaF-0006nj-EI
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:38:55 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	19/B1-02697-E2E44745; Tue, 25 Nov 2014 09:38:54 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416908331!9069383!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21054 invoked from network); 25 Nov 2014 09:38:52 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2014 09:38:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1416908330; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=m0e8DL+l/q4YV4L7EYCRPYH9m5hiivjm+Et85w/4WbE=;
	b=xD5zvI7nx8B7/ZfH+8uptZcZT/OjmAC9haCKV0RfTc9CXFEv7lfzMOlCymKwMOjm/lHdZE338mrsJLniXwmrQFd0qzLpQ5gq+fUiwmbX7jNzG9C3EDvvNq2MHUwvM/xxLrsScDUvE2maEhd4p5rrX1wfYN+vTmsVWOo0/UP5+us=
Received: from [10.0.0.112] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Tue, 25 Nov 2014 01:38:50 -0800
	id 00000000000305D3.54744E2A.00002A5B
Message-ID: <54744E29.8060703@ihonk.com>
Date: Tue, 25 Nov 2014 01:38:49 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5457F79B.2020300@ihonk.com>
	<20141104082012.GY12451@reaktio.net>	<5458B55C0200007800044B33@mail.emea.novell.com>	<5460716A.7090905@ihonk.com>	<54608A8B0200007800045E58@mail.emea.novell.com>	<54611A86.4000200@ihonk.com>	<5461D15C02000078000464D7@mail.emea.novell.com>	<546A4AD4.3030002@ihonk.com>	<546B094C0200007800048A5C@mail.emea.novell.com>	<546D429A.5020906@ihonk.com>	<546DAD6502000078000492FD@mail.emea.novell.com>	<546E4A17.5040902@ihonk.com>	<546F091F0200007800049A1C@smtp.nue.novell.com>	<54713848.3020401@ihonk.com>	<5472FE31020000780004A2D5@mail.emea.novell.com>	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>	<54732768020000780004A48C@mail.emea.novell.com>	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
In-Reply-To: <547448D7020000780004A919@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 12:16 AM, Jan Beulich wrote:
>> (XEN) 'c' pressed -> printing ACPI Cx structures
>> (XEN) ==cpu0==
>> (XEN) active state:        C0
>> (XEN) max_cstate:        C7
>> (XEN) states:
>> (XEN)     C1:    type[C1] latency[001] usage[00005664] method[  FFH] duration[4042540627]
>> (XEN)     C2:    type[C3] latency[064] usage[00000414] method[  FFH] duration[447258888]
>> (XEN)     C3:    type[C3] latency[096] usage[00002366] method[  FFH] duration[28183588810]
>> (XEN)    *C0:    usage[00008444] duration[26752178344]
>> (XEN) max=0 pwr=0 urg=0 nxt=0
>> (XEN) PC2[0] PC3[112428588] PC6[21869019218] PC7[0]
>> (XEN) CC3[484210884] CC6[27943480555] CC7[0]
> Interesting, so other than for me (perhaps due to other patches
> I have in my tree) the change resulted in C states now being used
> again despite mwait-idle=0, which is good. Question now is - with
> this being the case, did the hangs re-occur?

Unfortunately they did. (Happened unusually quick this time, though I 
doubt the statistical significance.) Not sure what the desirable output 
is, so I did a couple of 'a' and 'd' requests, capped off by a 'c':

(XEN) *** Dumping CPU0 host state: ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82d08012c9a2>] _spin_unlock_irq+0x30/0x31
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8300a943d000   rcx: 0000000000000000
(XEN) rdx: ffff82d0802e0000   rsi: 0000000000000008   rdi: ffff82d080329308
(XEN) rbp: ffff82d0802e7ec8   rsp: ffff82d0802e7e40   r8: ffff82d080329320
(XEN) r9:  0000000000000000   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: 000001227e5280e4   r13: ffff8300a943d000   r14: ffff82d080329308
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1b57c000   cr2: 000007fefca62000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff82d0802e7e40:
(XEN)    ffff82d080128cb5 ffff82d080329300 ffff82d080329320 00000000002e7e78
(XEN)    ffff82d080329300 ffff82d0801b977e ffff8300a943d000 fffff88002f36d70
(XEN)    ffff8300a943d000 0000000001c9c380 ffff82d0801e5600 ffff82d0802e7f08
(XEN)    ffff82d080300080 ffff82d080300080 ffffffffffffffff ffff82d0802e0000
(XEN)    fffffa8004fdff80 ffff82d0802e7ef8 ffff82d08012bfa3 ffff8300a943d000
(XEN)    fffff88002f36d70 0000018507f7ef25 000000000000000f ffff82d0802e7f08
(XEN)    ffff82d08012bffb 000000000000000f ffff82d0801e849a fffffa8004fdff80
(XEN)    000000000000000f 0000018507f7ef25 fffff88002f36d70 000000000000000f
(XEN)    fffff88002f2c180 fffff88002f36d70 fffff88002f2c2a0 fffff880043cb960
(XEN)    fffff88002f2c2a0 0000000000000002 fffff88002f2c1c0 0000000000000400
(XEN)    0000000000000000 fffff88002f36eb0 0000beef0000beef fffff8000293e20c
(XEN)    000000bf0000beef 0000000000000046 fffff88002f36c20 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000000000000000 ffff8300a943d000 0000000000000000 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012c9a2>] _spin_unlock_irq+0x30/0x31
(XEN)    [<ffff82d08012bfa3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012bffb>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e849a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v3): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000293e20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  fffff880043cb960   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 0000018507f7ef25   r14: 000000000000000f
(XEN) r15: fffffa8004fdff80   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 00000000536d9000   cr2: 000007fefca62000
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v4): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000293e20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fa2180   rcx: fffff88002fa21c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002faceb0
(XEN) rbp: 000000000000000f   rsp: fffff88002facc20   r8: fffff88002fa22a0
(XEN) r9:  fffff88002fcaca0   r10: fffff88002fa22a0   r11: fffff88002facd70
(XEN) r12: fffff88002facd70   r13: 0000000000000000   r14: 000000000000000f
(XEN) r15: fffff88002fa6fc0   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fffffaf478
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v5): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000293e20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000001526da65c1e   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 0000018507f90b28   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fefabb2654
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 guest state (d1v1): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<fffff80002e052bf>]
(XEN) RFLAGS: 0000000000000006   CONTEXT: hvm guest
(XEN) rax: 000002be8e13da4d   rbx: 000002be8e13e51b   rcx: 000000000000ffff
(XEN) rdx: 000002be00000000   rsi: 0000000000000000   rdi: 00000000000000a5
(XEN) rbp: 000000000000bad2   rsp: fffff88007bd8e80   r8: fffff88007bd8ee0
(XEN) r9:  0000000000000000   r10: fffff88007bd8f30   r11: 000000034291bff0
(XEN) r12: fffff88007bd92b8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 000000005c4ec000   cr2: 000000007730853f
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v0): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff8000293e20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a00e80   rcx: fffff80002a00ec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80003cfce70
(XEN) rbp: 000000000000000f   rsp: fffff80003cfcbe0   r8: fffff80002a00fa0
(XEN) r9:  0000000000000000   r10: fffff80002a00fa0   r11: fffff80003cfcd30
(XEN) r12: fffff80003cfcd30   r13: 0000018507f832b0   r14: 000000000000000f
(XEN) r15: 0000000000020181   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 00000000b3b80000   cr2: 000007fefcf91444
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v2): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000293e20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  fffff88006775960   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000018507fa203d   r14: 000000000000000f
(XEN) r15: fffffa800451a130   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 000000009b3e8000   cr2: fffff98006d0b008
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        9736us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=       99892us timer=ffff8300bf52c060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52c000)
(XEN)   ex=       10359us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex=   101576185us timer=ffff82d080325260 
cb=plt_overflow(0000000000000000)
(XEN)   ex=     7904630us timer=ffff82d080327560 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=      100351us timer=ffff82d080325300 
cb=time_calibration(0000000000000000)
(XEN)   ex=       19736us timer=ffff82d0803295e0 
cb=do_dbs_timer(ffff82d080329620)
(XEN) CPU01:
(XEN)   ex=        9996us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=       19736us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=       30028us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=         177us timer=ffff830c3dc79858 
cb=csched_tick(0000000000000002)
(XEN)   ex=      103892us timer=ffff8300bf52e060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52e000)
(XEN)   ex=         565us timer=ffff8300bf52d060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52d000)
(XEN)   ex=      103892us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex= 80621762913us timer=ffff830c17cc2290 
cb=rtc_alarm_cb(ffff830c17cc21f0)
(XEN)   ex=       19736us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=        1036us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=        9518us timer=ffff830c3dcac0e8 
cb=csched_tick(0000000000000003)
(XEN)   ex=       19736us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex=       30053us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=       10042us timer=ffff830c3dcac968 
cb=csched_tick(0000000000000004)
(XEN)   ex=       19736us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN)   ex=      103892us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=       30059us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU05:
(XEN)   ex=       10044us timer=ffff830c3dc8d208 
cb=csched_tick(0000000000000005)
(XEN)   ex=       19736us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=    74855186us timer=ffff830c17cc25d0 
cb=pmt_timer_callback(ffff830c17cc25a8)
(XEN)   ex=       23892us timer=ffff8300bf52f060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52f000)
(XEN)   ex=       30068us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d1v0): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<fffff8000293e20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff80002a00e80   rcx: fffff80002a00ec0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff80003cfce70
(XEN) rbp: 000000000000000f   rsp: fffff80003cfcbe0   r8: fffff80002a00fa0
(XEN) r9:  0000000000000000   r10: fffff80002a00fa0   r11: fffff80003cfcd30
(XEN) r12: fffff80003cfcd30   r13: 0000018507f832b0   r14: 000000000000000f
(XEN) r15: 0000000000020181   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 00000000b3b80000   cr2: 000007fefcf91444
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU1 guest state (d1v5): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<fffff8000293e20e>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002fd8180   rcx: fffff88002fd81c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002fe2eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002fe2c20   r8: fffff88002fd82a0
(XEN) r9:  000001526da65c1e   r10: fffff88002fd82a0   r11: fffff88002fe2d70
(XEN) r12: fffff88002fe2d70   r13: 0000018507f90b28   r14: 000000000000000f
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000007fefabb2654
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU2 host state: ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    e008:[<ffff82d0801dc4ca>] vmx_do_resume+0x1/0x154
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: ffff8300a943d000   rbx: ffff8300a943d000   rcx: 0000000000000002
(XEN) rdx: ffff830c3dcb0000   rsi: 0000000000000004   rdi: ffff8300a943d000
(XEN) rbp: ffff830c3dcb7e38   rsp: ffff830c3dcb7e28   r8: ffff830c3dcb80a0
(XEN) r9:  0000000000000000   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: 00000123d6398bd9   r13: ffff8300a943d000   r14: ffff830c3dcb8088
(XEN) r15: 0000000001c9c380   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1b57c000   cr2: 000007fefca62000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dcb7e28:
(XEN)    ffff830c3dcb7e38 ffff82d080165e89 ffff830c3dcb7ec8 ffff82d080128cef
(XEN)    ffff82d080329300 ffff830c3dcb80a0 0000000200cb7e78 ffff830c3dcb8080
(XEN)    ffff82d0801b977e ffff8300a943d000 fffff88002f36d70 ffff8300a943d000
(XEN)    0000000001c9c380 ffff82d0801e5600 ffff830c3dcb7f08 ffff82d080300180
(XEN)    ffff82d080300080 ffffffffffffffff ffff830c3dcb0000 fffffa8004fdff80
(XEN)    ffff830c3dcb7ef8 ffff82d08012bfa3 ffff8300a943d000 fffff88002f36d70
(XEN)    0000018507f7ef25 000000000000000f ffff830c3dcb7f08 ffff82d08012bffb
(XEN)    000000000000000f ffff82d0801e849a fffffa8004fdff80 000000000000000f
(XEN)    0000018507f7ef25 fffff88002f36d70 000000000000000f fffff88002f2c180
(XEN)    fffff88002f36d70 fffff88002f2c2a0 fffff880043cb960 fffff88002f2c2a0
(XEN)    0000000000000002 fffff88002f2c1c0 0000000000000400 0000000000000000
(XEN)    fffff88002f36eb0 0000beef0000beef fffff8000293e20c 000000bf0000beef
(XEN)    0000000000000046 fffff88002f36c20 000000000000beef 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 0000000000000002
(XEN)    ffff8300a943d000 0000003bbd98ed80 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d0801dc4ca>] vmx_do_resume+0x1/0x154
(XEN)    [<ffff82d080128cef>] schedule+0x1b5/0x612
(XEN)    [<ffff82d08012bfa3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012bffb>] do_softirq+0x13/0x15
(XEN)    [<ffff82d0801e849a>] vmx_asm_do_vmentry+0x2a/0x45
(XEN)
(XEN) *** Dumping CPU2 guest state (d1v3): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<fffff8000293e20c>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002f2c180   rcx: fffff88002f2c1c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002f36eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002f36c20   r8: fffff88002f2c2a0
(XEN) r9:  fffff880043cb960   r10: fffff88002f2c2a0   r11: fffff88002f36d70
(XEN) r12: fffff88002f36d70   r13: 0000018507f7ef25   r14: 000000000000000f
(XEN) r15: fffffa8004fdff80   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 00000000536d9000   cr2: 000007fefca62000
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff82d08010009f>] __bitmap_empty+0x8/0x96
(XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff82d080313e00   rcx: 0000000000000006
(XEN) rdx: 0000000000000004   rsi: 0000000000000006   rdi: ffff82d080313e00
(XEN) rbp: ffff830c3dca7e58   rsp: ffff830c3dca7e58   r8: 0000000000000045
(XEN) r9:  000000000000006d   r10: 0000000000000000   r11: fffff88002facd70
(XEN) r12: 0000000000000100   r13: 0000000000000000   r14: ffff830c3dca0000
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1815b000   cr2: 000007fffffaf478
(XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff830c3dca7e58:
(XEN)    ffff830c3dca7e88 ffff82d080186e22 ffff82d0801b977e ffff830c3dca7e98
(XEN)    ffff82d080300080 ffffffffffffffff ffff830c3dca7ec8 ffff82d080186ea2
(XEN)    0000000000000037 0000000000000000 0000000000000000 0000000000000000
(XEN)    ffff830c3dca0000 ffff82d080300200 ffff830c3dca7ef8 ffff82d08012bfa3
(XEN)    ffff8300bf52c000 ffff8300a943c000 0000000000000001 ffff830c3dcaa088
(XEN)    ffff830c3dca7f08 ffff82d08012bffb ffff830c3dca7de8 ffff82d08022fd51
(XEN)    0000000000000000 00000000ffffffed 0000000000000000 ffff880bce434000
(XEN)    0000000000000004 ffffffff818e1800 0000000000000246 ffff880aef7e7aa8
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff810013aa
(XEN)    0000000000000001 00000000deadbeef 00000000deadbeef 0002010000000000
(XEN)    ffffffff810013aa 000000000000e033 0000000000000246 ffff880bce437ec8
(XEN)    000000000000e02b 000000000000beef 000000000000beef 000000000000beef
(XEN)    000000000000beef 0000000000000003 ffff8300bf52c000 0000003bbd980d80
(XEN)    0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08010009f>] __bitmap_empty+0x8/0x96
(XEN)    [<ffff82d080186e22>] flush_area_mask+0x119/0x134
(XEN)    [<ffff82d080186ea2>] new_tlbflush_clock_period+0x65/0x81
(XEN)    [<ffff82d08012bfa3>] __do_softirq+0x81/0x8c
(XEN)    [<ffff82d08012bffb>] do_softirq+0x13/0x15
(XEN)    [<ffff82d08022fd51>] process_softirqs+0x21/0x30
(XEN)
(XEN) *** Dumping CPU3 guest state (d0v4): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e033:[<ffffffff810013aa>]
(XEN) RFLAGS: 0000000000000246   EM: 0   CONTEXT: pv guest
(XEN) rax: 0000000000000000   rbx: ffffffff818e1800   rcx: ffffffff810013aa
(XEN) rdx: 0000000000000001   rsi: 00000000deadbeef   rdi: 00000000deadbeef
(XEN) rbp: 0000000000000004   rsp: ffff880bce437ec8   r8: 0000000000000000
(XEN) r9:  0000000000000000   r10: ffff880aef7e7aa8   r11: 0000000000000246
(XEN) r12: ffff880bce434000   r13: 0000000000000000   r14: 00000000ffffffed
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000c1815b000   cr2: 00007fd8239b7000
(XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffff880bce437ec8:
(XEN)    0000000000000000 ffffffff81855060 ffffffff81009e0c ffffffff8101c849
(XEN)    ffffffff818e1800 0000000000000000 ffffffff810a5d80 ffff880bce434000
(XEN)    0000000000000004 ffff880bce434000 ffff880bce437fd8 c789d0ce26296124
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 ffffffffffffffff 0000000000000000 0000000000000010
(XEN)    0000000000000202 ffff880bce437f58 0000000000000018
(XEN)
(XEN) *** Dumping CPU4 guest state (d1v1): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffff80002e052c1>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest
(XEN) rax: 000002c273235b8e   rbx: 000002c273236218   rcx: 000000000000ffff
(XEN) rdx: 000002c200000000   rsi: 0000000000000000   rdi: 0000000000000089
(XEN) rbp: 000000000000a191   rsp: fffff88007bd8e80   r8: fffff88007bd8ee0
(XEN) r9:  0000000000000000   r10: fffff88007bd8f30   r11: 000000034291bff0
(XEN) r12: fffff88007bd92b8   r13: 0000000000001000   r14: 0000000000000000
(XEN) r15: 0000000000000058   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 000000005c4ec000   cr2: 000000007730853f
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
(XEN)
(XEN) *** Dumping CPU5 guest state (d1v2): ***
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    0010:[<fffff8000293e214>]
(XEN) RFLAGS: 0000000000000046   CONTEXT: hvm guest
(XEN) rax: 0000000000000002   rbx: fffff88002eb6180   rcx: fffff88002eb61c0
(XEN) rdx: 0000000000000400   rsi: 0000000000000000   rdi: fffff88002ec0eb0
(XEN) rbp: 000000000000000f   rsp: fffff88002ec0c20   r8: fffff88002eb62a0
(XEN) r9:  fffff88006775960   r10: fffff88002eb62a0   r11: fffff88002ec0d70
(XEN) r12: fffff88002ec0d70   r13: 0000018507fa203d   r14: 000000000000000f
(XEN) r15: fffffa800451a130   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 000000009b3e8000   cr2: fffff98006d0b008
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN)
(XEN) Dumping timer queues:
(XEN) CPU00:
(XEN)   ex=        3238us timer=ffff830c3dcc2d08 
cb=csched_tick(0000000000000000)
(XEN)   ex=        3238us timer=ffff82d0803295e0 
cb=do_dbs_timer(ffff82d080329620)
(XEN)   ex=       23022us timer=ffff8300bf52e060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52e000)
(XEN)   ex=      984001us timer=ffff82d080325300 
cb=time_calibration(0000000000000000)
(XEN)   ex=    97459687us timer=ffff82d080325260 
cb=plt_overflow(0000000000000000)
(XEN)   ex=     3788132us timer=ffff82d080327560 
cb=mce_work_fn(0000000000000000)
(XEN)   ex=       27212us timer=ffff830c3dc4b1e0 
cb=csched_acct(ffff830c3dc4b1c0)
(XEN)   ex= 80617646415us timer=ffff830c17cc2290 
cb=rtc_alarm_cb(ffff830c17cc21f0)
(XEN) CPU01:
(XEN)   ex=        3129us timer=ffff830c3dc55f28 
cb=csched_tick(0000000000000001)
(XEN)   ex=        3238us timer=ffff830c3dc7a360 
cb=do_dbs_timer(ffff830c3dc7a3a0)
(XEN)   ex=       30029us timer=ffff830c3dc7a0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU02:
(XEN)   ex=        3238us timer=ffff830c3dcb8360 
cb=do_dbs_timer(ffff830c3dcb83a0)
(XEN)   ex=        3359us timer=ffff830c3dc79858 
cb=csched_tick(0000000000000002)
(XEN)   ex=      945174us timer=ffff8300bf52c060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52c000)
(XEN)   ex=      771394us timer=ffff8300bf798060 
cb=vcpu_singleshot_timer_fn(ffff8300bf798000)
(XEN)   ex=       30036us timer=ffff830c3dcb80a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU03:
(XEN)   ex=        3238us timer=ffff830c3dcaa360 
cb=do_dbs_timer(ffff830c3dcaa3a0)
(XEN)   ex=        6099us timer=ffff830c3dcac0e8 
cb=csched_tick(0000000000000003)
(XEN)   ex=     3987394us timer=ffff8300bf52d060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52d000)
(XEN)   ex=       15394us timer=ffff8300bf52f060 
cb=vcpu_singleshot_timer_fn(ffff8300bf52f000)
(XEN)   ex=       30047us timer=ffff830c3dcaa0a0 
cb=s_timer_fn(0000000000000000)
(XEN) CPU04:
(XEN)   ex=         296us timer=ffff8300bf2fb060 
cb=vcpu_singleshot_timer_fn(ffff8300bf2fb000)
(XEN)   ex=        1060us timer=ffff830c3dc9c0a0 
cb=s_timer_fn(0000000000000000)
(XEN)   ex=        6764us timer=ffff830c3dcac968 
cb=csched_tick(0000000000000004)
(XEN)   ex=        3238us timer=ffff830c3dc9c360 
cb=do_dbs_timer(ffff830c3dc9c3a0)
(XEN) CPU05:
(XEN)   ex=        3238us timer=ffff830c3dc8e360 
cb=do_dbs_timer(ffff830c3dc8e3a0)
(XEN)   ex=        7336us timer=ffff830c3dc8d208 
cb=csched_tick(0000000000000005)
(XEN)   ex=    70738688us timer=ffff830c17cc25d0 
cb=pmt_timer_callback(ffff830c17cc25a8)
(XEN)   ex=       30070us timer=ffff830c3dc8e0a0 
cb=s_timer_fn(0000000000000000)
(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00879961] method[  FFH] 
duration[258917692906]
(XEN)     C2:   type[C3] latency[064] usage[00219972] method[  FFH] 
duration[185157317681]
(XEN)     C3:   type[C3] latency[096] usage[00021194] method[  FFH] 
duration[130347582819]
(XEN)    *C0:   usage[01121127] duration[742037344879]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[178118468514] CC6[120838993791] CC7[0]
(XEN) ==cpu1==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00732768] method[  FFH] 
duration[244601938735]
(XEN)     C2:   type[C3] latency[064] usage[00241040] method[  FFH] 
duration[205647145982]
(XEN)     C3:   type[C3] latency[096] usage[00017258] method[  FFH] 
duration[164619828246]
(XEN)    *C0:   usage[00991066] duration[701591066797]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[197708830338] CC6[153278778335] CC7[0]
(XEN) ==cpu2==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00736573] method[  FFH] 
duration[239398385639]
(XEN)     C2:   type[C3] latency[064] usage[00243735] method[  FFH] 
duration[208117053326]
(XEN)     C3:   type[C3] latency[096] usage[00018811] method[  FFH] 
duration[163124076095]
(XEN)    *C0:   usage[00999119] duration[705820535124]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[201124993103] CC6[147956371559] CC7[0]
(XEN) ==cpu3==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00737249] method[  FFH] 
duration[241046283679]
(XEN)     C2:   type[C3] latency[064] usage[00244020] method[  FFH] 
duration[210189165328]
(XEN)     C3:   type[C3] latency[096] usage[00016474] method[  FFH] 
duration[164857248289]
(XEN)    *C0:   usage[00997743] duration[700367394408]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[202741688061] CC6[152613177986] CC7[0]
(XEN) ==cpu4==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00784949] method[  FFH] 
duration[238150508853]
(XEN)     C2:   type[C3] latency[064] usage[00242440] method[  FFH] 
duration[208233744834]
(XEN)     C3:   type[C3] latency[096] usage[00017019] method[  FFH] 
duration[166844569919]
(XEN)    *C0:   usage[01044408] duration[703231307727]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[200748358163] CC6[153896919179] CC7[0]
(XEN) ==cpu5==
(XEN) active state:             C0
(XEN) max_cstate:               C7
(XEN) states:
(XEN)     C1:   type[C1] latency[001] usage[00881857] method[  FFH] 
duration[277043571093]
(XEN)     C2:   type[C3] latency[064] usage[00201963] method[  FFH] 
duration[172166602574]
(XEN)     C3:   type[C3] latency[096] usage[00018587] method[  FFH] 
duration[161929908741]
(XEN)    *C0:   usage[01102407] duration[705320088716]
(XEN) max=0 pwr=0 urg=2d nxt=0
(XEN) PC2[0] PC3[36377080311] PC6[84924866353] PC7[0]
(XEN) CC3[166777643669] CC6[150006253526] CC7[0]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 09:47:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:47:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtCiN-0006zk-1c; Tue, 25 Nov 2014 09:47:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtCiL-0006zf-WC
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 09:47:18 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	0C/6D-29352-52054745; Tue, 25 Nov 2014 09:47:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416908834!9837990!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26613 invoked from network); 25 Nov 2014 09:47:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 09:47:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,454,1413244800"; d="scan'208";a="196474930"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 04:47:11 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtCiF-0001YY-B6;
	Tue, 25 Nov 2014 09:47:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtCiE-00078W-VL;
	Tue, 25 Nov 2014 09:47:10 +0000
Date: Tue, 25 Nov 2014 09:47:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31838-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31838: 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 31838 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31838/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot              fail pass in 31784
 test-amd64-i386-xl-qemuu-ovmf-amd64  4 xen-install          fail pass in 31784
 test-amd64-i386-xl            3 host-install(3)  broken in 31784 pass in 31838
 test-amd64-i386-pair          7 xen-boot/src_host  fail in 31784 pass in 31838

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                2dc2565902d3c24108c4b7101e91957fd068a242
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
370 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.14
+ revision=2dc2565902d3c24108c4b7101e91957fd068a242
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.14 2dc2565902d3c24108c4b7101e91957fd068a242
+ branch=linux-3.14
+ revision=2dc2565902d3c24108c4b7101e91957fd068a242
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.14
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git = x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git = x ']'
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.14
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.linux-3.14
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree linux-3.14
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.14.y
+ : linux-3.14.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ : tested/linux-3.14
+ : tested/linux-3.14
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git 2dc2565902d3c24108c4b7101e91957fd068a242:tested/linux-3.14
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   d7892a4..2dc2565  2dc2565902d3c24108c4b7101e91957fd068a242 -> tested/linux-3.14
+ 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 Nov 25 09:47:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:47:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtCiN-0006zk-1c; Tue, 25 Nov 2014 09:47:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtCiL-0006zf-WC
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 09:47:18 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	0C/6D-29352-52054745; Tue, 25 Nov 2014 09:47:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416908834!9837990!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26613 invoked from network); 25 Nov 2014 09:47:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 09:47:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,454,1413244800"; d="scan'208";a="196474930"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 04:47:11 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtCiF-0001YY-B6;
	Tue, 25 Nov 2014 09:47:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtCiE-00078W-VL;
	Tue, 25 Nov 2014 09:47:10 +0000
Date: Tue, 25 Nov 2014 09:47:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31838-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 31838: 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 31838 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31838/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot              fail pass in 31784
 test-amd64-i386-xl-qemuu-ovmf-amd64  4 xen-install          fail pass in 31784
 test-amd64-i386-xl            3 host-install(3)  broken in 31784 pass in 31838
 test-amd64-i386-pair          7 xen-boot/src_host  fail in 31784 pass in 31838

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 30755

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                2dc2565902d3c24108c4b7101e91957fd068a242
baseline version:
 linux                d7892a4c389d54bccb9bce8e65eb053a33bbe290

------------------------------------------------------------
370 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.14
+ revision=2dc2565902d3c24108c4b7101e91957fd068a242
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.14 2dc2565902d3c24108c4b7101e91957fd068a242
+ branch=linux-3.14
+ revision=2dc2565902d3c24108c4b7101e91957fd068a242
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.14
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git = x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git = x ']'
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.14
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.linux-3.14
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree linux-3.14
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.14.y
+ : linux-3.14.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ : tested/linux-3.14
+ : tested/linux-3.14
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git 2dc2565902d3c24108c4b7101e91957fd068a242:tested/linux-3.14
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   d7892a4..2dc2565  2dc2565902d3c24108c4b7101e91957fd068a242 -> tested/linux-3.14
+ 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 Nov 25 09:49:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09: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 1XtCkF-00075R-Mc; Tue, 25 Nov 2014 09:49:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XtCkE-00075J-8f
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:49:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E7/0E-25276-99054745; Tue, 25 Nov 2014 09:49:13 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416908950!15124940!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8334 invoked from network); 25 Nov 2014 09:49:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 09:49:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,454,1413244800"; 
	d="asc'?scan'208";a="196038015"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 04:43:00 -0500
Message-ID: <1416908578.7176.10.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Tue, 25 Nov 2014 10:42:58 +0100
In-Reply-To: <54735343.1020208@oracle.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8492256452538998915=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8492256452538998915==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-/8PzkvCqfQoiepgJdr96"

--=-/8PzkvCqfQoiepgJdr96
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-24 at 10:48 -0500, Boris Ostrovsky wrote:
> On 11/24/2014 05:47 AM, Wei Liu wrote:

> >>
> >> The partial copy function should explicitly zero-out all remaining bit=
s.
>=20
> I actually thought that partial copy function should do just that ---=20
> copy bits that it has and leave others unchanged. The caller, if desires=
=20
> so, should have cleared the mask prior to the call. (This is for the=20
> case when destination is larger than source, of course).
>=20
Agreed.

Anyway, AFAIU Wei's proposal, he's saying that this new _copy_partial()
function can be an internal one, i.e., not part of the public  API, or
am I wrong, Wei?

If yes, I agree with that.

This leaves the question of whether we should change the behavior of the
publicly exposed libxl_bitmap_copy(), which I'm still not sure about,
but I guess, if we keep this internal, we can defer thinking to that to
some other period not in between RCs?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-/8PzkvCqfQoiepgJdr96
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 v2

iEYEABECAAYFAlR0TyIACgkQk4XaBE3IOsQBVQCfYGoymOlKysPsrFnzqqv7qvUY
xWYAniIf9JJYeGmEGwgBi8FtaaknUg8L
=x9hZ
-----END PGP SIGNATURE-----

--=-/8PzkvCqfQoiepgJdr96--


--===============8492256452538998915==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8492256452538998915==--


From xen-devel-bounces@lists.xen.org Tue Nov 25 09:49:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09: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 1XtCkF-00075R-Mc; Tue, 25 Nov 2014 09:49:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XtCkE-00075J-8f
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:49:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E7/0E-25276-99054745; Tue, 25 Nov 2014 09:49:13 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416908950!15124940!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8334 invoked from network); 25 Nov 2014 09:49:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 09:49:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,454,1413244800"; 
	d="asc'?scan'208";a="196038015"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 04:43:00 -0500
Message-ID: <1416908578.7176.10.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Tue, 25 Nov 2014 10:42:58 +0100
In-Reply-To: <54735343.1020208@oracle.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8492256452538998915=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8492256452538998915==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-/8PzkvCqfQoiepgJdr96"

--=-/8PzkvCqfQoiepgJdr96
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2014-11-24 at 10:48 -0500, Boris Ostrovsky wrote:
> On 11/24/2014 05:47 AM, Wei Liu wrote:

> >>
> >> The partial copy function should explicitly zero-out all remaining bit=
s.
>=20
> I actually thought that partial copy function should do just that ---=20
> copy bits that it has and leave others unchanged. The caller, if desires=
=20
> so, should have cleared the mask prior to the call. (This is for the=20
> case when destination is larger than source, of course).
>=20
Agreed.

Anyway, AFAIU Wei's proposal, he's saying that this new _copy_partial()
function can be an internal one, i.e., not part of the public  API, or
am I wrong, Wei?

If yes, I agree with that.

This leaves the question of whether we should change the behavior of the
publicly exposed libxl_bitmap_copy(), which I'm still not sure about,
but I guess, if we keep this internal, we can defer thinking to that to
some other period not in between RCs?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-/8PzkvCqfQoiepgJdr96
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 v2

iEYEABECAAYFAlR0TyIACgkQk4XaBE3IOsQBVQCfYGoymOlKysPsrFnzqqv7qvUY
xWYAniIf9JJYeGmEGwgBi8FtaaknUg8L
=x9hZ
-----END PGP SIGNATURE-----

--=-/8PzkvCqfQoiepgJdr96--


--===============8492256452538998915==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8492256452538998915==--


From xen-devel-bounces@lists.xen.org Tue Nov 25 09:55:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:55:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtCqM-0007I5-H9; Tue, 25 Nov 2014 09:55:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtCqK-0007I0-Mq
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:55:32 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	A5/73-20609-41254745; Tue, 25 Nov 2014 09:55:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416909329!14673836!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8552 invoked from network); 25 Nov 2014 09:55: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;
	25 Nov 2014 09:55:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196040565"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 04:48:31 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtCjX-0004yJ-3W;
	Tue, 25 Nov 2014 09:48:31 +0000
Date: Tue, 25 Nov 2014 09:48:31 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141125094831.GC17596@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com> <1416908578.7176.10.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416908578.7176.10.camel@Abyss>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 10:42:58AM +0100, Dario Faggioli wrote:
> On Mon, 2014-11-24 at 10:48 -0500, Boris Ostrovsky wrote:
> > On 11/24/2014 05:47 AM, Wei Liu wrote:
> 
> > >>
> > >> The partial copy function should explicitly zero-out all remaining bits.
> > 
> > I actually thought that partial copy function should do just that --- 
> > copy bits that it has and leave others unchanged. The caller, if desires 
> > so, should have cleared the mask prior to the call. (This is for the 
> > case when destination is larger than source, of course).
> > 
> Agreed.
> 
> Anyway, AFAIU Wei's proposal, he's saying that this new _copy_partial()
> function can be an internal one, i.e., not part of the public  API, or
> am I wrong, Wei?
> 
> If yes, I agree with that.
> 

You're right. I want to make it internal so that we don't need to worry
about the public API for now.

> This leaves the question of whether we should change the behavior of the
> publicly exposed libxl_bitmap_copy(), which I'm still not sure about,
> but I guess, if we keep this internal, we can defer thinking to that to
> some other period not in between RCs?
> 

Yes.

Wei.

> Thanks and Regards,
> Dario
> 
> -- 
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 09:55:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:55:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtCqM-0007I5-H9; Tue, 25 Nov 2014 09:55:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtCqK-0007I0-Mq
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:55:32 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	A5/73-20609-41254745; Tue, 25 Nov 2014 09:55:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416909329!14673836!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8552 invoked from network); 25 Nov 2014 09:55: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;
	25 Nov 2014 09:55:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196040565"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 04:48:31 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtCjX-0004yJ-3W;
	Tue, 25 Nov 2014 09:48:31 +0000
Date: Tue, 25 Nov 2014 09:48:31 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141125094831.GC17596@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com> <1416908578.7176.10.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416908578.7176.10.camel@Abyss>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 10:42:58AM +0100, Dario Faggioli wrote:
> On Mon, 2014-11-24 at 10:48 -0500, Boris Ostrovsky wrote:
> > On 11/24/2014 05:47 AM, Wei Liu wrote:
> 
> > >>
> > >> The partial copy function should explicitly zero-out all remaining bits.
> > 
> > I actually thought that partial copy function should do just that --- 
> > copy bits that it has and leave others unchanged. The caller, if desires 
> > so, should have cleared the mask prior to the call. (This is for the 
> > case when destination is larger than source, of course).
> > 
> Agreed.
> 
> Anyway, AFAIU Wei's proposal, he's saying that this new _copy_partial()
> function can be an internal one, i.e., not part of the public  API, or
> am I wrong, Wei?
> 
> If yes, I agree with that.
> 

You're right. I want to make it internal so that we don't need to worry
about the public API for now.

> This leaves the question of whether we should change the behavior of the
> publicly exposed libxl_bitmap_copy(), which I'm still not sure about,
> but I guess, if we keep this internal, we can defer thinking to that to
> some other period not in between RCs?
> 

Yes.

Wei.

> Thanks and Regards,
> Dario
> 
> -- 
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 09:57:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:57:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtCse-0007Nz-2I; Tue, 25 Nov 2014 09:57: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 1XtCsd-0007Nu-Fo
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:57:55 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	6B/66-25714-2A254745; Tue, 25 Nov 2014 09:57:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416909472!13181810!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19439 invoked from network); 25 Nov 2014 09:57:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 09:57:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196041839"
Message-ID: <1416909092.32327.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Blake <eblake@redhat.com>
Date: Tue, 25 Nov 2014 09:51:32 +0000
In-Reply-To: <54735AF7.2060103@redhat.com>
References: <20141120101240.2a75f384@m> <546E7674.1060204@redhat.com>
	<546FD5D2.60400@redhat.com> <1416822231.26329.19.camel@citrix.com>
	<54735AF7.2060103@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: libvir-list@redhat.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	cemeyer@uw.edu, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH 1/2] virdbus: don't force users to
 pass int for bool values
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-24 at 09:21 -0700, Eric Blake wrote:
> On 11/24/2014 02:43 AM, Ian Campbell wrote:
> 
> >>>>
> >>>> I think this change breaks build on FreeBSD:
> >>>>
> >>>>   CC       util/libvirt_util_la-virdbus.lo
> >>>> util/virdbus.c:956:13: error: cast from 'bool *' to 'dbus_bool_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Werror,-Wcast-align]
> >>>>             GET_NEXT_VAL(dbus_bool_t, bool_val, bool, "%d");
> >>>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>>> util/virdbus.c:858:17: note: expanded from macro 'GET_NEXT_VAL'
> >>>>             x = (dbustype *)(*xptrptr + (*narrayptr - 1));              \
> >>>>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.
> >>>
> >>> Valid complaint, so I'll have to figure something out to avoid it.  :(
> 
> > I'm, guessing that this is the same underlying issue as:
> >         util/virdbus.c: In function 'virDBusMessageIterDecode':
> >         util/virdbus.c:956:346: error: cast increases required alignment of target type [-Werror=cast-align]
> 
> Yes.
> 
> >         
> > which we are seeing in the Xen automated tests [0, 1] (on armhf only,
> > probably compiler dependent?).
> 
> So, do I have an ACK on my proposed fix yet? :)
> https://www.redhat.com/archives/libvir-list/2014-November/msg00838.html

Well, FWIW it looks good to me:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 09:57:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 09:57:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtCse-0007Nz-2I; Tue, 25 Nov 2014 09:57: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 1XtCsd-0007Nu-Fo
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 09:57:55 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	6B/66-25714-2A254745; Tue, 25 Nov 2014 09:57:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1416909472!13181810!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19439 invoked from network); 25 Nov 2014 09:57:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 09:57:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196041839"
Message-ID: <1416909092.32327.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Blake <eblake@redhat.com>
Date: Tue, 25 Nov 2014 09:51:32 +0000
In-Reply-To: <54735AF7.2060103@redhat.com>
References: <20141120101240.2a75f384@m> <546E7674.1060204@redhat.com>
	<546FD5D2.60400@redhat.com> <1416822231.26329.19.camel@citrix.com>
	<54735AF7.2060103@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: libvir-list@redhat.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	cemeyer@uw.edu, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH 1/2] virdbus: don't force users to
 pass int for bool values
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-11-24 at 09:21 -0700, Eric Blake wrote:
> On 11/24/2014 02:43 AM, Ian Campbell wrote:
> 
> >>>>
> >>>> I think this change breaks build on FreeBSD:
> >>>>
> >>>>   CC       util/libvirt_util_la-virdbus.lo
> >>>> util/virdbus.c:956:13: error: cast from 'bool *' to 'dbus_bool_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Werror,-Wcast-align]
> >>>>             GET_NEXT_VAL(dbus_bool_t, bool_val, bool, "%d");
> >>>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>>> util/virdbus.c:858:17: note: expanded from macro 'GET_NEXT_VAL'
> >>>>             x = (dbustype *)(*xptrptr + (*narrayptr - 1));              \
> >>>>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.
> >>>
> >>> Valid complaint, so I'll have to figure something out to avoid it.  :(
> 
> > I'm, guessing that this is the same underlying issue as:
> >         util/virdbus.c: In function 'virDBusMessageIterDecode':
> >         util/virdbus.c:956:346: error: cast increases required alignment of target type [-Werror=cast-align]
> 
> Yes.
> 
> >         
> > which we are seeing in the Xen automated tests [0, 1] (on armhf only,
> > probably compiler dependent?).
> 
> So, do I have an ACK on my proposed fix yet? :)
> https://www.redhat.com/archives/libvir-list/2014-November/msg00838.html

Well, FWIW it looks good to me:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:07:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 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 1XtD1b-0007eJ-3Q; Tue, 25 Nov 2014 10:07:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XtD1Z-0007eE-Mn
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:07:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2B/AD-15461-CC454745; Tue, 25 Nov 2014 10:07:08 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416910026!15145786!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10750 invoked from network); 25 Nov 2014 10:07:06 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:07:06 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so8520685wiv.17
	for <xen-devel@lists.xen.org>; Tue, 25 Nov 2014 02:07:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=HnRQnUSHbeaZGSYqGtNqf6K31jMJiIvf0PPHAOVtukY=;
	b=dWvvhFsxlq4PIY/OSjBlM+7BtOd+El3RZBcvNJpRFLx0WQlXOVQZKULGmT2XRe9p0h
	WSH5vGzKHeSg+jhwB4vDupLNz9G4N7tDz7NDPhF81siINEupHNWubvDu1I9iCvfuznc0
	FiiZd2Bc0A0giEO7l33C66jwDrlTgqQhPY2TR4igwS49Y/IqtR30SmSCqGUeI+nLW6C4
	MJp2MlAbvE6ZbSqh3lzEgBUnf34z86GHhC3mXtrRYmCZjLynNhfxRmtyfUKHxAHyQdLY
	Tyiu7N4xekYhYb5PH2ZEFuK7kqv3cnT3PyAr67ZUo+76N1J9D326hGzZZOSVfaMHY3fC
	kF8g==
MIME-Version: 1.0
X-Received: by 10.180.100.230 with SMTP id fb6mr8870659wib.73.1416910026590;
	Tue, 25 Nov 2014 02:07:06 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Tue, 25 Nov 2014 02:07:06 -0800 (PST)
In-Reply-To: <5473ABA2.6080901@tycho.nsa.gov>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
	<547343F4.80509@citrix.com>
	<alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>
	<5473ABA2.6080901@tycho.nsa.gov>
Date: Tue, 25 Nov 2014 10:07:06 +0000
X-Google-Sender-Auth: gehWJpv_5AsBnqf8apqWFU2G78o
Message-ID: <CAFLBxZZFO+ms+TX4Gmchkb53CWL6EHeoGEcBKEgvMgx3AQaqvg@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 10:05 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> I do. The error is
>> (XEN) flask_domctl: Unknown op 72
>>
>> Incidentally, Flask is running in permissive mode.
>>
>>      Michael Young
>>
>
> This means that the new domctl needs to be added to the switch statement
> in flask/hooks.c.  This error is triggered in permissive mode because it
> is a code error rather than a policy error (which is what permissive mode
> is intended to debug).

If that's the case, should we make that a BUG_ON()?  Or at least an
ASSERT() (which will only bug when compiled with debug=y), followed by
allow if in permissive mode, and deny if in enforcing mode?

Having it default deny, even in permissive mode, breaks the "principle
of least surprise", 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 Nov 25 10:07:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 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 1XtD1b-0007eJ-3Q; Tue, 25 Nov 2014 10:07:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XtD1Z-0007eE-Mn
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:07:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2B/AD-15461-CC454745; Tue, 25 Nov 2014 10:07:08 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416910026!15145786!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10750 invoked from network); 25 Nov 2014 10:07:06 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:07:06 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so8520685wiv.17
	for <xen-devel@lists.xen.org>; Tue, 25 Nov 2014 02:07:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=HnRQnUSHbeaZGSYqGtNqf6K31jMJiIvf0PPHAOVtukY=;
	b=dWvvhFsxlq4PIY/OSjBlM+7BtOd+El3RZBcvNJpRFLx0WQlXOVQZKULGmT2XRe9p0h
	WSH5vGzKHeSg+jhwB4vDupLNz9G4N7tDz7NDPhF81siINEupHNWubvDu1I9iCvfuznc0
	FiiZd2Bc0A0giEO7l33C66jwDrlTgqQhPY2TR4igwS49Y/IqtR30SmSCqGUeI+nLW6C4
	MJp2MlAbvE6ZbSqh3lzEgBUnf34z86GHhC3mXtrRYmCZjLynNhfxRmtyfUKHxAHyQdLY
	Tyiu7N4xekYhYb5PH2ZEFuK7kqv3cnT3PyAr67ZUo+76N1J9D326hGzZZOSVfaMHY3fC
	kF8g==
MIME-Version: 1.0
X-Received: by 10.180.100.230 with SMTP id fb6mr8870659wib.73.1416910026590;
	Tue, 25 Nov 2014 02:07:06 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Tue, 25 Nov 2014 02:07:06 -0800 (PST)
In-Reply-To: <5473ABA2.6080901@tycho.nsa.gov>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
	<547343F4.80509@citrix.com>
	<alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>
	<5473ABA2.6080901@tycho.nsa.gov>
Date: Tue, 25 Nov 2014 10:07:06 +0000
X-Google-Sender-Auth: gehWJpv_5AsBnqf8apqWFU2G78o
Message-ID: <CAFLBxZZFO+ms+TX4Gmchkb53CWL6EHeoGEcBKEgvMgx3AQaqvg@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 10:05 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> I do. The error is
>> (XEN) flask_domctl: Unknown op 72
>>
>> Incidentally, Flask is running in permissive mode.
>>
>>      Michael Young
>>
>
> This means that the new domctl needs to be added to the switch statement
> in flask/hooks.c.  This error is triggered in permissive mode because it
> is a code error rather than a policy error (which is what permissive mode
> is intended to debug).

If that's the case, should we make that a BUG_ON()?  Or at least an
ASSERT() (which will only bug when compiled with debug=y), followed by
allow if in permissive mode, and deny if in enforcing mode?

Having it default deny, even in permissive mode, breaks the "principle
of least surprise", 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 Nov 25 10:21:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10: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 1XtDEs-0007rp-3o; Tue, 25 Nov 2014 10:20:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtDEr-0007rd-8y
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:20:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	64/E6-25276-40854745; Tue, 25 Nov 2014 10:20:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416910849!15100438!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15828 invoked from network); 25 Nov 2014 10:20:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:20:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196483832"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 05:20:48 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtD0b-0005NS-PL;
	Tue, 25 Nov 2014 10:06:09 +0000
Date: Tue, 25 Nov 2014 10:06:09 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141125100609.GA28315@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-18-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416582421-10789-18-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: Re: [Xen-devel] [PATCH 17/19] libxl: refactor hvm_build_set_params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch can be ignored because it's going to be dropped in v2.

Wei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:21:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10: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 1XtDEr-0007ri-OH; Tue, 25 Nov 2014 10:20:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtDEq-0007rY-6y
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:20:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5F/0E-09842-30854745; Tue, 25 Nov 2014 10:20:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416910849!15100438!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15656 invoked from network); 25 Nov 2014 10:20:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:20:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196483828"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 05:20:48 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtD0z-0005OB-AZ;
	Tue, 25 Nov 2014 10:06:33 +0000
Date: Tue, 25 Nov 2014 10:06:33 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141125100633.GB28315@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-19-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416582421-10789-19-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: Re: [Xen-devel] [PATCH 18/19] libxl: fill vNUMA information in hvm
	info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is going to be dropped in v2, please ignore this one.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:21:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10: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 1XtDEs-0007rp-3o; Tue, 25 Nov 2014 10:20:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtDEr-0007rd-8y
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:20:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	64/E6-25276-40854745; Tue, 25 Nov 2014 10:20:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416910849!15100438!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15828 invoked from network); 25 Nov 2014 10:20:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:20:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196483832"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 05:20:48 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtD0b-0005NS-PL;
	Tue, 25 Nov 2014 10:06:09 +0000
Date: Tue, 25 Nov 2014 10:06:09 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141125100609.GA28315@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-18-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416582421-10789-18-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: Re: [Xen-devel] [PATCH 17/19] libxl: refactor hvm_build_set_params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch can be ignored because it's going to be dropped in v2.

Wei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:21:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10: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 1XtDEr-0007ri-OH; Tue, 25 Nov 2014 10:20:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtDEq-0007rY-6y
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:20:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5F/0E-09842-30854745; Tue, 25 Nov 2014 10:20:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416910849!15100438!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15656 invoked from network); 25 Nov 2014 10:20:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:20:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196483828"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 05:20:48 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtD0z-0005OB-AZ;
	Tue, 25 Nov 2014 10:06:33 +0000
Date: Tue, 25 Nov 2014 10:06:33 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141125100633.GB28315@zion.uk.xensource.com>
References: <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>
	<1416582421-10789-19-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416582421-10789-19-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: Re: [Xen-devel] [PATCH 18/19] libxl: fill vNUMA information in hvm
	info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is going to be dropped in v2, please ignore this one.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:27:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10:27:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDKp-000892-Ta; Tue, 25 Nov 2014 10:27:03 +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 1XtDKo-00088x-BE
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:27:02 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	BD/B2-14214-57954745; Tue, 25 Nov 2014 10:27:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416911218!13221595!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5816 invoked from network); 25 Nov 2014 10:27:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:27:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196055329"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 05:19:46 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtD3L-0005VV-8y; Tue, 25 Nov 2014 10:08:59 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Tue, 25 Nov 2014 10:08:58 +0000
Message-ID: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of 28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
As a result, injecting a fault and retrying the the vmentry is likely to fail
in the same way.

While crashing a guest because userspace tickled a hypervisor bug to get up
invalid VMCS state is bad (and usually warrants an XSA), it is better than the
infinite loop caused by this change, and the non-ratelimited console output it
would cause.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

Konrad: A hypervisor infinite loop is quite bad, so I am requesting a release
ack for this.  An alternative would be to revert 28b4baacd5 wholesale, but
most of it is good.

One other alternative, which I would pursue if we were not already in -rc2
would be to add some extra logic to detect repeated vmentry failure and allow
one attempt to shoot userspace before giving up and crashing the domain.
---
 xen/arch/x86/hvm/vmx/vmx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2907afa..9b98595 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2520,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned int exit_reason,
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
 
-    vmx_crash_or_fault(curr);
+    domain_crash(curr->domain);
 }
 
 void vmx_enter_realmode(struct cpu_user_regs *regs)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:27:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10:27:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDKp-000892-Ta; Tue, 25 Nov 2014 10:27:03 +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 1XtDKo-00088x-BE
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:27:02 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	BD/B2-14214-57954745; Tue, 25 Nov 2014 10:27:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1416911218!13221595!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5816 invoked from network); 25 Nov 2014 10:27:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:27:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196055329"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 05:19:46 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtD3L-0005VV-8y; Tue, 25 Nov 2014 10:08:59 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Tue, 25 Nov 2014 10:08:58 +0000
Message-ID: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of 28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
As a result, injecting a fault and retrying the the vmentry is likely to fail
in the same way.

While crashing a guest because userspace tickled a hypervisor bug to get up
invalid VMCS state is bad (and usually warrants an XSA), it is better than the
infinite loop caused by this change, and the non-ratelimited console output it
would cause.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

Konrad: A hypervisor infinite loop is quite bad, so I am requesting a release
ack for this.  An alternative would be to revert 28b4baacd5 wholesale, but
most of it is good.

One other alternative, which I would pursue if we were not already in -rc2
would be to add some extra logic to detect repeated vmentry failure and allow
one attempt to shoot userspace before giving up and crashing the domain.
---
 xen/arch/x86/hvm/vmx/vmx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2907afa..9b98595 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2520,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned int exit_reason,
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
 
-    vmx_crash_or_fault(curr);
+    domain_crash(curr->domain);
 }
 
 void vmx_enter_realmode(struct cpu_user_regs *regs)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:39:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10: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 1XtDX8-0008K9-HG; Tue, 25 Nov 2014 10:39:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtDX7-0008K2-9w
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:39:45 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	8C/B4-18267-07C54745; Tue, 25 Nov 2014 10:39:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416911982!13695522!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29761 invoked from network); 25 Nov 2014 10:39:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:39:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196489220"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 05:39:41 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtDX2-0006q2-PJ;
	Tue, 25 Nov 2014 10:39:40 +0000
Date: Tue, 25 Nov 2014 10:39:40 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141125103940.GC28315@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54735343.1020208@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 10:48:19AM -0500, Boris Ostrovsky wrote:
> On 11/24/2014 05:47 AM, Wei Liu wrote:
> >CC'ing Dario...
> >
> >On Mon, Nov 24, 2014 at 10:41:27AM +0000, Wei Liu wrote:
> >>On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
> >>>When parsing bitmap objects JSON parser will create libxl_bitmap
> >>>map of the smallest size needed.
> >>>
> >>>This can cause problems when saved image file specifies CPU affinity.
> >>>For example, if 'vcpu_hard_affinity' in the saved image has only the
> >>>first CPU specified, just a single byte will be allocated and
> >>>libxl_bitmap->size will be set to 1.
> >>>
> >>>This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> >>>since the destination bitmap is created for maximum number of CPUs.
> >>>
> >>>We could allocate that bitmap of the same size as the source, however,
> >>>it is later passed to xc_vcpu_setaffinity() which expects it to be
> >>>sized to the max number of CPUs
> >>>
> >>>Instead, we should allow copying the (smaller) bitmap read by the parser
> >>>and keep the rest of bytes in the destination map unmodified (zero in
> >>>this case)
> >>>
> >>Here is some more thoughts on this issue:
> >>
> >>This API is used by VCPU placement and NUMA placement logic in libxl. To
> >>fix the breakage, we don't necessary need to expose new API or change
> >>API behaviour, we only need to have a internal function to do it.
> >>
> >>The reversed case (large bitmap to small one) is not valid in libxl, as
> >>in the pinning will fail. But bitmap copy happens before that, we would
> >>still need to deal with that. Dario, can you provide some input on
> >>the expected behaviour?
> 
> I understand that hypervisor will ignore bits that are beyond what it knows
> about --- see xenctl_bitmap_to_bitmap(). And libxl will will issue a
> warning. But only if byte-sized bitmaps are the same. If they are not will
> will pop the assertion (in debug builds).
> 

After a discussion on IRC with Dario, migrating from large host to small
one is legit use case. That means we need to take care about the
reversed case as well.

BTW, are you on xen-devel@freenode? It would be much faster if we can
discuss on IRC.

> >>
> >>The partial copy function should explicitly zero-out all remaining bits.
> 
> I actually thought that partial copy function should do just that --- copy
> bits that it has and leave others unchanged. The caller, if desires so,
> should have cleared the mask prior to the call. (This is for the case when
> destination is larger than source, of course).
> 

This is OK as long as this behaviour is documented.

I will prepare a patch shortly for you to test.

Wei.

> 
> -boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:39:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10: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 1XtDX8-0008K9-HG; Tue, 25 Nov 2014 10:39:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtDX7-0008K2-9w
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:39:45 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	8C/B4-18267-07C54745; Tue, 25 Nov 2014 10:39:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416911982!13695522!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29761 invoked from network); 25 Nov 2014 10:39:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:39:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196489220"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 05:39:41 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtDX2-0006q2-PJ;
	Tue, 25 Nov 2014 10:39:40 +0000
Date: Tue, 25 Nov 2014 10:39:40 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141125103940.GC28315@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54735343.1020208@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 10:48:19AM -0500, Boris Ostrovsky wrote:
> On 11/24/2014 05:47 AM, Wei Liu wrote:
> >CC'ing Dario...
> >
> >On Mon, Nov 24, 2014 at 10:41:27AM +0000, Wei Liu wrote:
> >>On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
> >>>When parsing bitmap objects JSON parser will create libxl_bitmap
> >>>map of the smallest size needed.
> >>>
> >>>This can cause problems when saved image file specifies CPU affinity.
> >>>For example, if 'vcpu_hard_affinity' in the saved image has only the
> >>>first CPU specified, just a single byte will be allocated and
> >>>libxl_bitmap->size will be set to 1.
> >>>
> >>>This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> >>>since the destination bitmap is created for maximum number of CPUs.
> >>>
> >>>We could allocate that bitmap of the same size as the source, however,
> >>>it is later passed to xc_vcpu_setaffinity() which expects it to be
> >>>sized to the max number of CPUs
> >>>
> >>>Instead, we should allow copying the (smaller) bitmap read by the parser
> >>>and keep the rest of bytes in the destination map unmodified (zero in
> >>>this case)
> >>>
> >>Here is some more thoughts on this issue:
> >>
> >>This API is used by VCPU placement and NUMA placement logic in libxl. To
> >>fix the breakage, we don't necessary need to expose new API or change
> >>API behaviour, we only need to have a internal function to do it.
> >>
> >>The reversed case (large bitmap to small one) is not valid in libxl, as
> >>in the pinning will fail. But bitmap copy happens before that, we would
> >>still need to deal with that. Dario, can you provide some input on
> >>the expected behaviour?
> 
> I understand that hypervisor will ignore bits that are beyond what it knows
> about --- see xenctl_bitmap_to_bitmap(). And libxl will will issue a
> warning. But only if byte-sized bitmaps are the same. If they are not will
> will pop the assertion (in debug builds).
> 

After a discussion on IRC with Dario, migrating from large host to small
one is legit use case. That means we need to take care about the
reversed case as well.

BTW, are you on xen-devel@freenode? It would be much faster if we can
discuss on IRC.

> >>
> >>The partial copy function should explicitly zero-out all remaining bits.
> 
> I actually thought that partial copy function should do just that --- copy
> bits that it has and leave others unchanged. The caller, if desires so,
> should have cleared the mask prior to the call. (This is for the case when
> destination is larger than source, of course).
> 

This is OK as long as this behaviour is documented.

I will prepare a patch shortly for you to test.

Wei.

> 
> -boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDZq-0008Te-5Z; Tue, 25 Nov 2014 10:42:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtDZo-0008TX-Pg
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:42:32 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	E4/15-05632-81D54745; Tue, 25 Nov 2014 10:42:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416912151!13678197!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12887 invoked from network); 25 Nov 2014 10:42:31 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 10:42:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 10:42:30 +0000
Message-Id: <54746B24020000780004A9C5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 10:42:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
> As a result, injecting a fault and retrying the the vmentry is likely to 
> fail
> in the same way.

That's not all that unlikely - remember that the change was prompted
by the XSA-110 fix. There CS pieces being in a bad state would get
corrected by the exception injection.

> One other alternative, which I would pursue if we were not already in -rc2
> would be to add some extra logic to detect repeated vmentry failure and 
> allow
> one attempt to shoot userspace before giving up and crashing the domain.

That's not even needed afaict (and if it really is, it can't be all that
difficult/intrusive): Did you observe what you attempt to fix here in
practice, or is this just from theoretical considerations? I ask because
I don't think it can actually happen, as the second time we get here
the guest ought to be in kernel mode (due to the exception injection)
and hence would get crashed anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDZq-0008Te-5Z; Tue, 25 Nov 2014 10:42:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtDZo-0008TX-Pg
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:42:32 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	E4/15-05632-81D54745; Tue, 25 Nov 2014 10:42:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416912151!13678197!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12887 invoked from network); 25 Nov 2014 10:42:31 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 10:42:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 10:42:30 +0000
Message-Id: <54746B24020000780004A9C5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 10:42:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
> As a result, injecting a fault and retrying the the vmentry is likely to 
> fail
> in the same way.

That's not all that unlikely - remember that the change was prompted
by the XSA-110 fix. There CS pieces being in a bad state would get
corrected by the exception injection.

> One other alternative, which I would pursue if we were not already in -rc2
> would be to add some extra logic to detect repeated vmentry failure and 
> allow
> one attempt to shoot userspace before giving up and crashing the domain.

That's not even needed afaict (and if it really is, it can't be all that
difficult/intrusive): Did you observe what you attempt to fix here in
practice, or is this just from theoretical considerations? I ask because
I don't think it can actually happen, as the second time we get here
the guest ought to be in kernel mode (due to the exception injection)
and hence would get crashed anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:48:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDey-0000C2-Tg; Tue, 25 Nov 2014 10:47:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XtDey-0000Bx-2W
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:47:52 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	41/DB-27785-75E54745; Tue, 25 Nov 2014 10:47:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416912470!14638782!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28113 invoked from network); 25 Nov 2014 10:47:50 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 10:47:50 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XtDeg-0008gz-HV; Tue, 25 Nov 2014 10:47:34 +0000
Date: Tue, 25 Nov 2014 11:47:34 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141125104734.GB28049@deinos.phlegethon.org>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:08 +0000 on 25 Nov (1416906538), Andrew Cooper wrote:
> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
> As a result, injecting a fault and retrying the the vmentry is likely to fail
> in the same way.

In particular, the guest's privilege level won't change until _after_
the next vm entry has succeeded.

> While crashing a guest because userspace tickled a hypervisor bug to get up
> invalid VMCS state is bad (and usually warrants an XSA), it is better than the
> infinite loop caused by this change, and the non-ratelimited console output it
> would cause.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:48:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDey-0000C2-Tg; Tue, 25 Nov 2014 10:47:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XtDey-0000Bx-2W
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:47:52 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	41/DB-27785-75E54745; Tue, 25 Nov 2014 10:47:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1416912470!14638782!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28113 invoked from network); 25 Nov 2014 10:47:50 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 10:47:50 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XtDeg-0008gz-HV; Tue, 25 Nov 2014 10:47:34 +0000
Date: Tue, 25 Nov 2014 11:47:34 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141125104734.GB28049@deinos.phlegethon.org>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:08 +0000 on 25 Nov (1416906538), Andrew Cooper wrote:
> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
> As a result, injecting a fault and retrying the the vmentry is likely to fail
> in the same way.

In particular, the guest's privilege level won't change until _after_
the next vm entry has succeeded.

> While crashing a guest because userspace tickled a hypervisor bug to get up
> invalid VMCS state is bad (and usually warrants an XSA), it is better than the
> infinite loop caused by this change, and the non-ratelimited console output it
> would cause.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:52:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDje-0000O5-MH; Tue, 25 Nov 2014 10:52:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtDjd-0000O0-AG
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:52:41 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	1E/67-28296-87F54745; Tue, 25 Nov 2014 10:52:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416912757!13681382!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1816 invoked from network); 25 Nov 2014 10:52:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:52:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196067713"
Message-ID: <54745DF3.8020603@citrix.com>
Date: Tue, 25 Nov 2014 10:46:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
	<54746B24020000780004A9C5@mail.emea.novell.com>
In-Reply-To: <54746B24020000780004A9C5@mail.emea.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 10:42, Jan Beulich wrote:
>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
>> As a result, injecting a fault and retrying the the vmentry is likely to 
>> fail
>> in the same way.
> That's not all that unlikely - remember that the change was prompted
> by the XSA-110 fix. There CS pieces being in a bad state would get
> corrected by the exception injection.
>
>> One other alternative, which I would pursue if we were not already in -rc2
>> would be to add some extra logic to detect repeated vmentry failure and 
>> allow
>> one attempt to shoot userspace before giving up and crashing the domain.
> That's not even needed afaict (and if it really is, it can't be all that
> difficult/intrusive): Did you observe what you attempt to fix here in
> practice, or is this just from theoretical considerations? I ask because
> I don't think it can actually happen, as the second time we get here
> the guest ought to be in kernel mode (due to the exception injection)
> and hence would get crashed anyway.

Only from theoretical considerations.  A bad CS (and possibly SS) would
be fixed by this, but there are many others which wouldn't

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 10:52:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 10:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDje-0000O5-MH; Tue, 25 Nov 2014 10:52:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtDjd-0000O0-AG
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 10:52:41 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	1E/67-28296-87F54745; Tue, 25 Nov 2014 10:52:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416912757!13681382!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1816 invoked from network); 25 Nov 2014 10:52:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 10:52:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196067713"
Message-ID: <54745DF3.8020603@citrix.com>
Date: Tue, 25 Nov 2014 10:46:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
	<54746B24020000780004A9C5@mail.emea.novell.com>
In-Reply-To: <54746B24020000780004A9C5@mail.emea.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 10:42, Jan Beulich wrote:
>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
>> As a result, injecting a fault and retrying the the vmentry is likely to 
>> fail
>> in the same way.
> That's not all that unlikely - remember that the change was prompted
> by the XSA-110 fix. There CS pieces being in a bad state would get
> corrected by the exception injection.
>
>> One other alternative, which I would pursue if we were not already in -rc2
>> would be to add some extra logic to detect repeated vmentry failure and 
>> allow
>> one attempt to shoot userspace before giving up and crashing the domain.
> That's not even needed afaict (and if it really is, it can't be all that
> difficult/intrusive): Did you observe what you attempt to fix here in
> practice, or is this just from theoretical considerations? I ask because
> I don't think it can actually happen, as the second time we get here
> the guest ought to be in kernel mode (due to the exception injection)
> and hence would get crashed anyway.

Only from theoretical considerations.  A bad CS (and possibly SS) would
be fixed by this, but there are many others which wouldn't

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 11:00:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11:00:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDrE-0000Zp-NK; Tue, 25 Nov 2014 11:00:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtDrC-0000Zk-J3
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:00:30 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	A2/FA-28296-D4164745; Tue, 25 Nov 2014 11:00:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416913229!11214168!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20990 invoked from network); 25 Nov 2014 11:00:29 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 11:00:29 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 11:00:28 +0000
Message-Id: <54746F59020000780004A9E9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 11:00:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
In-Reply-To: <54744E29.8060703@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 10:38, <sflist@ihonk.com> wrote:
> On 11/25/2014 12:16 AM, Jan Beulich wrote:
>> Interesting, so other than for me (perhaps due to other patches
>> I have in my tree) the change resulted in C states now being used
>> again despite mwait-idle=0, which is good. Question now is - with
>> this being the case, did the hangs re-occur?
> 
> Unfortunately they did. (Happened unusually quick this time, though I 
> doubt the statistical significance.) Not sure what the desirable output 
> is, so I did a couple of 'a' and 'd' requests, capped off by a 'c':

Okay, so it's not really the mwait-idle driver causing the regression,
but it is C-state related. Hence we're now down to seeing whether all
or just the deeper C states are affected, i.e. I now need to ask you
to play with "max_cstate=". For that you'll have to remember that the
option's effect differs between the ACPI and the MWAIT idle drivers.
In the spirit of bisection I'd suggest using "max_cstate=2" first no
matter which of the two scenarios you pick. If that still hangs,
"max_cstate=1" obviously is the only other thing to try. Should that
not hang (and you left out "mwait-idle=0"), trying "max_cstate=3"
in that same scenario would be the other case to check.

No need for 'd' and 'a' output for the time being, but 'c' output would
be much appreciated for all cases where you observe hangs.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 11:00:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11:00:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDrE-0000Zp-NK; Tue, 25 Nov 2014 11:00:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtDrC-0000Zk-J3
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:00:30 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	A2/FA-28296-D4164745; Tue, 25 Nov 2014 11:00:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416913229!11214168!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20990 invoked from network); 25 Nov 2014 11:00:29 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 11:00:29 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 11:00:28 +0000
Message-Id: <54746F59020000780004A9E9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 11:00:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
In-Reply-To: <54744E29.8060703@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 10:38, <sflist@ihonk.com> wrote:
> On 11/25/2014 12:16 AM, Jan Beulich wrote:
>> Interesting, so other than for me (perhaps due to other patches
>> I have in my tree) the change resulted in C states now being used
>> again despite mwait-idle=0, which is good. Question now is - with
>> this being the case, did the hangs re-occur?
> 
> Unfortunately they did. (Happened unusually quick this time, though I 
> doubt the statistical significance.) Not sure what the desirable output 
> is, so I did a couple of 'a' and 'd' requests, capped off by a 'c':

Okay, so it's not really the mwait-idle driver causing the regression,
but it is C-state related. Hence we're now down to seeing whether all
or just the deeper C states are affected, i.e. I now need to ask you
to play with "max_cstate=". For that you'll have to remember that the
option's effect differs between the ACPI and the MWAIT idle drivers.
In the spirit of bisection I'd suggest using "max_cstate=2" first no
matter which of the two scenarios you pick. If that still hangs,
"max_cstate=1" obviously is the only other thing to try. Should that
not hang (and you left out "mwait-idle=0"), trying "max_cstate=3"
in that same scenario would be the other case to check.

No need for 'd' and 'a' output for the time being, but 'c' output would
be much appreciated for all cases where you observe hangs.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 11:03:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11:03:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDtj-0000ig-8r; Tue, 25 Nov 2014 11:03:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtDti-0000iX-IC
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:03:06 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	68/A2-19763-8E164745; Tue, 25 Nov 2014 11:03:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416913383!13207084!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11857 invoked from network); 25 Nov 2014 11:03:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 11:03:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 11:03:03 +0000
Message-Id: <54746FF4020000780004A9F4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 11:03:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
	<54746B24020000780004A9C5@mail.emea.novell.com>
	<54745DF3.8020603@citrix.com>
In-Reply-To: <54745DF3.8020603@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 11:46, <andrew.cooper3@citrix.com> wrote:
> On 25/11/14 10:42, Jan Beulich wrote:
>>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS 
> state.
>>> As a result, injecting a fault and retrying the the vmentry is likely to 
>>> fail
>>> in the same way.
>> That's not all that unlikely - remember that the change was prompted
>> by the XSA-110 fix. There CS pieces being in a bad state would get
>> corrected by the exception injection.
>>
>>> One other alternative, which I would pursue if we were not already in -rc2
>>> would be to add some extra logic to detect repeated vmentry failure and 
>>> allow
>>> one attempt to shoot userspace before giving up and crashing the domain.
>> That's not even needed afaict (and if it really is, it can't be all that
>> difficult/intrusive): Did you observe what you attempt to fix here in
>> practice, or is this just from theoretical considerations? I ask because
>> I don't think it can actually happen, as the second time we get here
>> the guest ought to be in kernel mode (due to the exception injection)
>> and hence would get crashed anyway.
> 
> Only from theoretical considerations.  A bad CS (and possibly SS) would
> be fixed by this, but there are many others which wouldn't

But that doesn't eliminate the fact that in the second pass we'd find
the guest in kernel mode, and hence crash it. Yet your reply sounds
as if you still think your patch is needed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 11:03:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11:03:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtDtj-0000ig-8r; Tue, 25 Nov 2014 11:03:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtDti-0000iX-IC
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:03:06 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	68/A2-19763-8E164745; Tue, 25 Nov 2014 11:03:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416913383!13207084!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11857 invoked from network); 25 Nov 2014 11:03:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 11:03:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 11:03:03 +0000
Message-Id: <54746FF4020000780004A9F4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 11:03:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
	<54746B24020000780004A9C5@mail.emea.novell.com>
	<54745DF3.8020603@citrix.com>
In-Reply-To: <54745DF3.8020603@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 11:46, <andrew.cooper3@citrix.com> wrote:
> On 25/11/14 10:42, Jan Beulich wrote:
>>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS 
> state.
>>> As a result, injecting a fault and retrying the the vmentry is likely to 
>>> fail
>>> in the same way.
>> That's not all that unlikely - remember that the change was prompted
>> by the XSA-110 fix. There CS pieces being in a bad state would get
>> corrected by the exception injection.
>>
>>> One other alternative, which I would pursue if we were not already in -rc2
>>> would be to add some extra logic to detect repeated vmentry failure and 
>>> allow
>>> one attempt to shoot userspace before giving up and crashing the domain.
>> That's not even needed afaict (and if it really is, it can't be all that
>> difficult/intrusive): Did you observe what you attempt to fix here in
>> practice, or is this just from theoretical considerations? I ask because
>> I don't think it can actually happen, as the second time we get here
>> the guest ought to be in kernel mode (due to the exception injection)
>> and hence would get crashed anyway.
> 
> Only from theoretical considerations.  A bad CS (and possibly SS) would
> be fixed by this, but there are many others which wouldn't

But that doesn't eliminate the fact that in the second pass we'd find
the guest in kernel mode, and hence crash it. Yet your reply sounds
as if you still think your patch is needed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 11:06:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11: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 1XtDwY-0000t0-5b; Tue, 25 Nov 2014 11:06:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtDwW-0000ss-Ah
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:06:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F9/A5-09842-79264745; Tue, 25 Nov 2014 11:05:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416913557!15165622!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31634 invoked from network); 25 Nov 2014 11:05:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 11:05:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196073095"
Message-ID: <547460EB.7090305@citrix.com>
Date: Tue, 25 Nov 2014 10:58:51 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>	<54746B24020000780004A9C5@mail.emea.novell.com>
	<54745DF3.8020603@citrix.com>
In-Reply-To: <54745DF3.8020603@citrix.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 10:46, Andrew Cooper wrote:
> On 25/11/14 10:42, Jan Beulich wrote:
>>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
>>> As a result, injecting a fault and retrying the the vmentry is likely to 
>>> fail
>>> in the same way.
>> That's not all that unlikely - remember that the change was prompted
>> by the XSA-110 fix. There CS pieces being in a bad state would get
>> corrected by the exception injection.
>>
>>> One other alternative, which I would pursue if we were not already in -rc2
>>> would be to add some extra logic to detect repeated vmentry failure and 
>>> allow
>>> one attempt to shoot userspace before giving up and crashing the domain.
>> That's not even needed afaict (and if it really is, it can't be all that
>> difficult/intrusive): Did you observe what you attempt to fix here in
>> practice, or is this just from theoretical considerations? I ask because
>> I don't think it can actually happen, as the second time we get here
>> the guest ought to be in kernel mode (due to the exception injection)
>> and hence would get crashed anyway.
> Only from theoretical considerations.  A bad CS (and possibly SS) would
> be fixed by this, but there are many others which wouldn't

Actually, as Tim correctly points out, a bad CS/SS won't be fixed by
this without emulating the event injection.  Per the XSA-106 followup,
we only ever emulate enough of event injection to cover the dpl checks
on software events for older generation SVM.  We never actually emulate
the context switch itself.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 11:06:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11: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 1XtDwY-0000t0-5b; Tue, 25 Nov 2014 11:06:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtDwW-0000ss-Ah
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:06:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F9/A5-09842-79264745; Tue, 25 Nov 2014 11:05:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416913557!15165622!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31634 invoked from network); 25 Nov 2014 11:05:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 11:05:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196073095"
Message-ID: <547460EB.7090305@citrix.com>
Date: Tue, 25 Nov 2014 10:58:51 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>	<54746B24020000780004A9C5@mail.emea.novell.com>
	<54745DF3.8020603@citrix.com>
In-Reply-To: <54745DF3.8020603@citrix.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 10:46, Andrew Cooper wrote:
> On 25/11/14 10:42, Jan Beulich wrote:
>>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
>>> As a result, injecting a fault and retrying the the vmentry is likely to 
>>> fail
>>> in the same way.
>> That's not all that unlikely - remember that the change was prompted
>> by the XSA-110 fix. There CS pieces being in a bad state would get
>> corrected by the exception injection.
>>
>>> One other alternative, which I would pursue if we were not already in -rc2
>>> would be to add some extra logic to detect repeated vmentry failure and 
>>> allow
>>> one attempt to shoot userspace before giving up and crashing the domain.
>> That's not even needed afaict (and if it really is, it can't be all that
>> difficult/intrusive): Did you observe what you attempt to fix here in
>> practice, or is this just from theoretical considerations? I ask because
>> I don't think it can actually happen, as the second time we get here
>> the guest ought to be in kernel mode (due to the exception injection)
>> and hence would get crashed anyway.
> Only from theoretical considerations.  A bad CS (and possibly SS) would
> be fixed by this, but there are many others which wouldn't

Actually, as Tim correctly points out, a bad CS/SS won't be fixed by
this without emulating the event injection.  Per the XSA-106 followup,
we only ever emulate enough of event injection to cover the dpl checks
on software events for older generation SVM.  We never actually emulate
the context switch itself.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 11:23:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11:23:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtEDT-0001BG-0K; Tue, 25 Nov 2014 11:23:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtEDS-0001BB-0g
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:23:30 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	E6/CD-03148-1B664745; Tue, 25 Nov 2014 11:23:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416914606!14676962!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22834 invoked from network); 25 Nov 2014 11:23:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 11:23:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196079738"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 06:15:22 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtE5a-0007TM-4f;
	Tue, 25 Nov 2014 11:15:22 +0000
Date: Tue, 25 Nov 2014 11:15:22 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141125111522.GD28315@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
	<20141125103940.GC28315@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141125103940.GC28315@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And here it is.

Boris, can you give it a shot?

---8<---
>From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 25 Nov 2014 10:59:47 +0000
Subject: [PATCH] libxl: allow copying between bitmaps of different sizes

When parsing bitmap objects JSON parser will create libxl_bitmap map of the
smallest size needed.

This can cause problems when saved image file specifies CPU affinity.  For
example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
specified, just a single byte will be allocated and libxl_bitmap->size will be
set to 1.

This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
since the destination bitmap is created for maximum number of CPUs.

We could allocate that bitmap of the same size as the source, however, it is
later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
number of CPUs

To fix this issue, introduce an internal function to allowing copying between
bitmaps of different sizes. Note that this function is only used in
libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
placement logic comes into effect when no vcpu / node pinning is provided, so
it always operates on bitmap of the same sizes (that is, size of maximum
number of cpus /nodes).

Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
---
This fixes a regression for 4.5. Can't think of obvious risk.
---
 tools/libxl/libxl.c          |    4 ++--
 tools/libxl/libxl_internal.h |   11 +++++++++++
 tools/libxl/libxl_utils.c    |   15 +++++++++++++++
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..1e9da10 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5320,7 +5320,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
+        libxl__bitmap_copy_best_effort(gc, &hard, cpumap_hard);
         flags = XEN_VCPUAFFINITY_HARD;
     }
     if (cpumap_soft) {
@@ -5328,7 +5328,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
+        libxl__bitmap_copy_best_effort(gc, &soft, cpumap_soft);
         flags |= XEN_VCPUAFFINITY_SOFT;
     }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..a38f695 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3617,6 +3617,17 @@ static inline void libxl__update_config_vtpm(libxl__gc *gc,
         libxl_device_##type##_copy(CTX, DA_p, (dev));           \
     })
 
+/* This function copies X bytes from source to destination bitmap,
+ * where X is the smaller of the two sizes.
+ *
+ * If destination's size is larger than source, the extra bytes are
+ * untouched.
+ *
+ * XXX This is introduced to fix a regression for 4.5. It shall
+ * be revisited in 4.6 time frame.
+ */
+void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
+                                    const libxl_bitmap *sptr);
 #endif
 
 /*
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 58df4f3..3e1ba17 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -614,6 +614,21 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
     memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
 }
 
+/* This function copies X bytes from source to destination bitmap,
+ * where X is the smaller of the two sizes.
+ *
+ * If destination's size is larger than source, the extra bytes are
+ * untouched.
+ */
+void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
+                                    const libxl_bitmap *sptr)
+{
+    int sz;
+
+    sz = dptr->size < sptr->size ? dptr->size : sptr->size;
+    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
+}
+
 void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
                              libxl_bitmap *dptr,
                              const libxl_bitmap *sptr)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 11:23:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11:23:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtEDT-0001BG-0K; Tue, 25 Nov 2014 11:23:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtEDS-0001BB-0g
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:23:30 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	E6/CD-03148-1B664745; Tue, 25 Nov 2014 11:23:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416914606!14676962!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22834 invoked from network); 25 Nov 2014 11:23:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 11:23:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196079738"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 06:15:22 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtE5a-0007TM-4f;
	Tue, 25 Nov 2014 11:15:22 +0000
Date: Tue, 25 Nov 2014 11:15:22 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141125111522.GD28315@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
	<20141125103940.GC28315@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141125103940.GC28315@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And here it is.

Boris, can you give it a shot?

---8<---
>From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 25 Nov 2014 10:59:47 +0000
Subject: [PATCH] libxl: allow copying between bitmaps of different sizes

When parsing bitmap objects JSON parser will create libxl_bitmap map of the
smallest size needed.

This can cause problems when saved image file specifies CPU affinity.  For
example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
specified, just a single byte will be allocated and libxl_bitmap->size will be
set to 1.

This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
since the destination bitmap is created for maximum number of CPUs.

We could allocate that bitmap of the same size as the source, however, it is
later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
number of CPUs

To fix this issue, introduce an internal function to allowing copying between
bitmaps of different sizes. Note that this function is only used in
libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
placement logic comes into effect when no vcpu / node pinning is provided, so
it always operates on bitmap of the same sizes (that is, size of maximum
number of cpus /nodes).

Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
---
This fixes a regression for 4.5. Can't think of obvious risk.
---
 tools/libxl/libxl.c          |    4 ++--
 tools/libxl/libxl_internal.h |   11 +++++++++++
 tools/libxl/libxl_utils.c    |   15 +++++++++++++++
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..1e9da10 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5320,7 +5320,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
+        libxl__bitmap_copy_best_effort(gc, &hard, cpumap_hard);
         flags = XEN_VCPUAFFINITY_HARD;
     }
     if (cpumap_soft) {
@@ -5328,7 +5328,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
+        libxl__bitmap_copy_best_effort(gc, &soft, cpumap_soft);
         flags |= XEN_VCPUAFFINITY_SOFT;
     }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..a38f695 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3617,6 +3617,17 @@ static inline void libxl__update_config_vtpm(libxl__gc *gc,
         libxl_device_##type##_copy(CTX, DA_p, (dev));           \
     })
 
+/* This function copies X bytes from source to destination bitmap,
+ * where X is the smaller of the two sizes.
+ *
+ * If destination's size is larger than source, the extra bytes are
+ * untouched.
+ *
+ * XXX This is introduced to fix a regression for 4.5. It shall
+ * be revisited in 4.6 time frame.
+ */
+void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
+                                    const libxl_bitmap *sptr);
 #endif
 
 /*
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 58df4f3..3e1ba17 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -614,6 +614,21 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
     memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
 }
 
+/* This function copies X bytes from source to destination bitmap,
+ * where X is the smaller of the two sizes.
+ *
+ * If destination's size is larger than source, the extra bytes are
+ * untouched.
+ */
+void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
+                                    const libxl_bitmap *sptr)
+{
+    int sz;
+
+    sz = dptr->size < sptr->size ? dptr->size : sptr->size;
+    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
+}
+
 void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
                              libxl_bitmap *dptr,
                              const libxl_bitmap *sptr)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 11:31:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtELQ-0001KX-3K; Tue, 25 Nov 2014 11:31:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtELO-0001KS-Ds
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:31:42 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2D/0D-25276-D9864745; Tue, 25 Nov 2014 11:31:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416915101!12389455!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 853 invoked from network); 25 Nov 2014 11:31:41 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 11:31:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 11:31:41 +0000
Message-Id: <547476A9020000780004AA29@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 11:31:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
	<54746B24020000780004A9C5@mail.emea.novell.com>
	<54745DF3.8020603@citrix.com> <547460EB.7090305@citrix.com>
In-Reply-To: <547460EB.7090305@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
 28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 11:58, <andrew.cooper3@citrix.com> wrote:
> On 25/11/14 10:46, Andrew Cooper wrote:
>> On 25/11/14 10:42, Jan Beulich wrote:
>>>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS 
> state.
>>>> As a result, injecting a fault and retrying the the vmentry is likely to 
>>>> fail
>>>> in the same way.
>>> That's not all that unlikely - remember that the change was prompted
>>> by the XSA-110 fix. There CS pieces being in a bad state would get
>>> corrected by the exception injection.
>>>
>>>> One other alternative, which I would pursue if we were not already in -rc2
>>>> would be to add some extra logic to detect repeated vmentry failure and 
>>>> allow
>>>> one attempt to shoot userspace before giving up and crashing the domain.
>>> That's not even needed afaict (and if it really is, it can't be all that
>>> difficult/intrusive): Did you observe what you attempt to fix here in
>>> practice, or is this just from theoretical considerations? I ask because
>>> I don't think it can actually happen, as the second time we get here
>>> the guest ought to be in kernel mode (due to the exception injection)
>>> and hence would get crashed anyway.
>> Only from theoretical considerations.  A bad CS (and possibly SS) would
>> be fixed by this, but there are many others which wouldn't
> 
> Actually, as Tim correctly points out, a bad CS/SS won't be fixed by
> this without emulating the event injection.  Per the XSA-106 followup,
> we only ever emulate enough of event injection to cover the dpl checks
> on software events for older generation SVM.  We never actually emulate
> the context switch itself.

Which suggests that rather than doing the partial revert as you
propose we might better extend the check to become "kernel mode
or event injection pending".

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 11:31:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtELQ-0001KX-3K; Tue, 25 Nov 2014 11:31:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtELO-0001KS-Ds
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:31:42 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2D/0D-25276-D9864745; Tue, 25 Nov 2014 11:31:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416915101!12389455!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 853 invoked from network); 25 Nov 2014 11:31:41 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 11:31:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 11:31:41 +0000
Message-Id: <547476A9020000780004AA29@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 11:31:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
	<54746B24020000780004A9C5@mail.emea.novell.com>
	<54745DF3.8020603@citrix.com> <547460EB.7090305@citrix.com>
In-Reply-To: <547460EB.7090305@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
 28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 11:58, <andrew.cooper3@citrix.com> wrote:
> On 25/11/14 10:46, Andrew Cooper wrote:
>> On 25/11/14 10:42, Jan Beulich wrote:
>>>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS 
> state.
>>>> As a result, injecting a fault and retrying the the vmentry is likely to 
>>>> fail
>>>> in the same way.
>>> That's not all that unlikely - remember that the change was prompted
>>> by the XSA-110 fix. There CS pieces being in a bad state would get
>>> corrected by the exception injection.
>>>
>>>> One other alternative, which I would pursue if we were not already in -rc2
>>>> would be to add some extra logic to detect repeated vmentry failure and 
>>>> allow
>>>> one attempt to shoot userspace before giving up and crashing the domain.
>>> That's not even needed afaict (and if it really is, it can't be all that
>>> difficult/intrusive): Did you observe what you attempt to fix here in
>>> practice, or is this just from theoretical considerations? I ask because
>>> I don't think it can actually happen, as the second time we get here
>>> the guest ought to be in kernel mode (due to the exception injection)
>>> and hence would get crashed anyway.
>> Only from theoretical considerations.  A bad CS (and possibly SS) would
>> be fixed by this, but there are many others which wouldn't
> 
> Actually, as Tim correctly points out, a bad CS/SS won't be fixed by
> this without emulating the event injection.  Per the XSA-106 followup,
> we only ever emulate enough of event injection to cover the dpl checks
> on software events for older generation SVM.  We never actually emulate
> the context switch itself.

Which suggests that rather than doing the partial revert as you
propose we might better extend the check to become "kernel mode
or event injection pending".

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 11:41:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtEUc-0001We-CW; Tue, 25 Nov 2014 11:41:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XtEUb-0001WZ-P2
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:41:13 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	BA/59-25727-9DA64745; Tue, 25 Nov 2014 11:41:13 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416915670!13715859!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13695 invoked from network); 25 Nov 2014 11:41:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 11:41:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; 
	d="asc'?scan'208";a="196504366"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 06:41:09 -0500
Message-ID: <1416915667.7176.39.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 25 Nov 2014 12:41:07 +0100
In-Reply-To: <20141125111522.GD28315@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
	<20141125103940.GC28315@zion.uk.xensource.com>
	<20141125111522.GD28315@zion.uk.xensource.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7525583402525280150=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7525583402525280150==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-n7p/agl5pmDgF+uvgu9F"

--=-n7p/agl5pmDgF+uvgu9F
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2014-11-25 at 11:15 +0000, Wei Liu wrote:
> And here it is.
>=20
> Boris, can you give it a shot?
>=20
> ---8<---
> From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
> From: Wei Liu <wei.liu2@citrix.com>
> Date: Tue, 25 Nov 2014 10:59:47 +0000
> Subject: [PATCH] libxl: allow copying between bitmaps of different sizes
>=20
> When parsing bitmap objects JSON parser will create libxl_bitmap map of t=
he
> smallest size needed.
>=20
> This can cause problems when saved image file specifies CPU affinity.  Fo=
r
> example, if 'vcpu_hard_affinity' in the saved image has only the first CP=
U
> specified, just a single byte will be allocated and libxl_bitmap->size wi=
ll be
> set to 1.
>=20
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_c=
opy()
> since the destination bitmap is created for maximum number of CPUs.
>=20
> We could allocate that bitmap of the same size as the source, however, it=
 is
> later passed to xc_vcpu_setaffinity() which expects it to be sized to the=
 max
> number of CPUs
>=20
> To fix this issue, introduce an internal function to allowing copying bet=
ween
> bitmaps of different sizes. Note that this function is only used in
> libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
> libxl_bitmap_copy as well there's no need to replace those invocations.  =
NUMA
> placement logic comes into effect when no vcpu / node pinning is provided=
, so
> it always operates on bitmap of the same sizes (that is, size of maximum
> number of cpus /nodes).
>=20
> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Dario Faggioli <dario.faggioli@citrix.com>
>
If this end up being the approach, it can have the following:

Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-n7p/agl5pmDgF+uvgu9F
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 v2

iEYEABECAAYFAlR0atMACgkQk4XaBE3IOsTo1gCgrYe3N293DmpXoQL8ciM3p0N5
X6YAni1Z/c9DT78GH8CQbacm2PV8zNW9
=FLRn
-----END PGP SIGNATURE-----

--=-n7p/agl5pmDgF+uvgu9F--


--===============7525583402525280150==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7525583402525280150==--


From xen-devel-bounces@lists.xen.org Tue Nov 25 11:41:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 11:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtEUc-0001We-CW; Tue, 25 Nov 2014 11:41:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XtEUb-0001WZ-P2
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 11:41:13 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	BA/59-25727-9DA64745; Tue, 25 Nov 2014 11:41:13 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416915670!13715859!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13695 invoked from network); 25 Nov 2014 11:41:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 11:41:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; 
	d="asc'?scan'208";a="196504366"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 06:41:09 -0500
Message-ID: <1416915667.7176.39.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 25 Nov 2014 12:41:07 +0100
In-Reply-To: <20141125111522.GD28315@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
	<20141125103940.GC28315@zion.uk.xensource.com>
	<20141125111522.GD28315@zion.uk.xensource.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7525583402525280150=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7525583402525280150==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-n7p/agl5pmDgF+uvgu9F"

--=-n7p/agl5pmDgF+uvgu9F
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2014-11-25 at 11:15 +0000, Wei Liu wrote:
> And here it is.
>=20
> Boris, can you give it a shot?
>=20
> ---8<---
> From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
> From: Wei Liu <wei.liu2@citrix.com>
> Date: Tue, 25 Nov 2014 10:59:47 +0000
> Subject: [PATCH] libxl: allow copying between bitmaps of different sizes
>=20
> When parsing bitmap objects JSON parser will create libxl_bitmap map of t=
he
> smallest size needed.
>=20
> This can cause problems when saved image file specifies CPU affinity.  Fo=
r
> example, if 'vcpu_hard_affinity' in the saved image has only the first CP=
U
> specified, just a single byte will be allocated and libxl_bitmap->size wi=
ll be
> set to 1.
>=20
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_c=
opy()
> since the destination bitmap is created for maximum number of CPUs.
>=20
> We could allocate that bitmap of the same size as the source, however, it=
 is
> later passed to xc_vcpu_setaffinity() which expects it to be sized to the=
 max
> number of CPUs
>=20
> To fix this issue, introduce an internal function to allowing copying bet=
ween
> bitmaps of different sizes. Note that this function is only used in
> libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
> libxl_bitmap_copy as well there's no need to replace those invocations.  =
NUMA
> placement logic comes into effect when no vcpu / node pinning is provided=
, so
> it always operates on bitmap of the same sizes (that is, size of maximum
> number of cpus /nodes).
>=20
> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Dario Faggioli <dario.faggioli@citrix.com>
>
If this end up being the approach, it can have the following:

Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-n7p/agl5pmDgF+uvgu9F
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 v2

iEYEABECAAYFAlR0atMACgkQk4XaBE3IOsTo1gCgrYe3N293DmpXoQL8ciM3p0N5
X6YAni1Z/c9DT78GH8CQbacm2PV8zNW9
=FLRn
-----END PGP SIGNATURE-----

--=-n7p/agl5pmDgF+uvgu9F--


--===============7525583402525280150==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7525583402525280150==--


From xen-devel-bounces@lists.xen.org Tue Nov 25 12:11:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtExs-00026H-2f; Tue, 25 Nov 2014 12:11:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtExr-00026C-7n
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 12:11:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	07/43-25276-EE174745; Tue, 25 Nov 2014 12:11:26 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416917484!12409541!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32614 invoked from network); 25 Nov 2014 12:11:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:11:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196512464"
Message-ID: <547471C2.1040909@citrix.com>
Date: Tue, 25 Nov 2014 12:10:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
	<54746B24020000780004A9C5@mail.emea.novell.com>
	<54745DF3.8020603@citrix.com> <547460EB.7090305@citrix.com>
	<547476A9020000780004AA29@mail.emea.novell.com>
In-Reply-To: <547476A9020000780004AA29@mail.emea.novell.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 11:31, Jan Beulich wrote:
>>>> On 25.11.14 at 11:58, <andrew.cooper3@citrix.com> wrote:
>> On 25/11/14 10:46, Andrew Cooper wrote:
>>> On 25/11/14 10:42, Jan Beulich wrote:
>>>>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>>>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS 
>> state.
>>>>> As a result, injecting a fault and retrying the the vmentry is likely to 
>>>>> fail
>>>>> in the same way.
>>>> That's not all that unlikely - remember that the change was prompted
>>>> by the XSA-110 fix. There CS pieces being in a bad state would get
>>>> corrected by the exception injection.
>>>>
>>>>> One other alternative, which I would pursue if we were not already in -rc2
>>>>> would be to add some extra logic to detect repeated vmentry failure and 
>>>>> allow
>>>>> one attempt to shoot userspace before giving up and crashing the domain.
>>>> That's not even needed afaict (and if it really is, it can't be all that
>>>> difficult/intrusive): Did you observe what you attempt to fix here in
>>>> practice, or is this just from theoretical considerations? I ask because
>>>> I don't think it can actually happen, as the second time we get here
>>>> the guest ought to be in kernel mode (due to the exception injection)
>>>> and hence would get crashed anyway.
>>> Only from theoretical considerations.  A bad CS (and possibly SS) would
>>> be fixed by this, but there are many others which wouldn't
>> Actually, as Tim correctly points out, a bad CS/SS won't be fixed by
>> this without emulating the event injection.  Per the XSA-106 followup,
>> we only ever emulate enough of event injection to cover the dpl checks
>> on software events for older generation SVM.  We never actually emulate
>> the context switch itself.
> Which suggests that rather than doing the partial revert as you
> propose we might better extend the check to become "kernel mode
> or event injection pending".

At that point, it is safer just to unconditionally crash on a repeated
vmentry failure, rather than gain a list of conditions which we hope
wont leave us spinning in a loop.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:11:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtExs-00026H-2f; Tue, 25 Nov 2014 12:11:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtExr-00026C-7n
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 12:11:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	07/43-25276-EE174745; Tue, 25 Nov 2014 12:11:26 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416917484!12409541!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32614 invoked from network); 25 Nov 2014 12:11:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:11:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196512464"
Message-ID: <547471C2.1040909@citrix.com>
Date: Tue, 25 Nov 2014 12:10:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
	<54746B24020000780004A9C5@mail.emea.novell.com>
	<54745DF3.8020603@citrix.com> <547460EB.7090305@citrix.com>
	<547476A9020000780004AA29@mail.emea.novell.com>
In-Reply-To: <547476A9020000780004AA29@mail.emea.novell.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
	28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 11:31, Jan Beulich wrote:
>>>> On 25.11.14 at 11:58, <andrew.cooper3@citrix.com> wrote:
>> On 25/11/14 10:46, Andrew Cooper wrote:
>>> On 25/11/14 10:42, Jan Beulich wrote:
>>>>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>>>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS 
>> state.
>>>>> As a result, injecting a fault and retrying the the vmentry is likely to 
>>>>> fail
>>>>> in the same way.
>>>> That's not all that unlikely - remember that the change was prompted
>>>> by the XSA-110 fix. There CS pieces being in a bad state would get
>>>> corrected by the exception injection.
>>>>
>>>>> One other alternative, which I would pursue if we were not already in -rc2
>>>>> would be to add some extra logic to detect repeated vmentry failure and 
>>>>> allow
>>>>> one attempt to shoot userspace before giving up and crashing the domain.
>>>> That's not even needed afaict (and if it really is, it can't be all that
>>>> difficult/intrusive): Did you observe what you attempt to fix here in
>>>> practice, or is this just from theoretical considerations? I ask because
>>>> I don't think it can actually happen, as the second time we get here
>>>> the guest ought to be in kernel mode (due to the exception injection)
>>>> and hence would get crashed anyway.
>>> Only from theoretical considerations.  A bad CS (and possibly SS) would
>>> be fixed by this, but there are many others which wouldn't
>> Actually, as Tim correctly points out, a bad CS/SS won't be fixed by
>> this without emulating the event injection.  Per the XSA-106 followup,
>> we only ever emulate enough of event injection to cover the dpl checks
>> on software events for older generation SVM.  We never actually emulate
>> the context switch itself.
> Which suggests that rather than doing the partial revert as you
> propose we might better extend the check to become "kernel mode
> or event injection pending".

At that point, it is safer just to unconditionally crash on a repeated
vmentry failure, rather than gain a list of conditions which we hope
wont leave us spinning in a loop.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:13:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12: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 1XtEzb-0002EQ-Kn; Tue, 25 Nov 2014 12:13:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtEza-0002EI-8l
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 12:13:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CC/F3-15461-95274745; Tue, 25 Nov 2014 12:13:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416917591!12410112!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15980 invoked from network); 25 Nov 2014 12:13:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:13:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196102570"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 07:05:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtErz-0000Hc-5Y;
	Tue, 25 Nov 2014 12:05:23 +0000
Date: Tue, 25 Nov 2014 12:05:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <1416870378-32481-3-git-send-email-boris.ostrovsky@oracle.com>
Message-ID: <alpine.DEB.2.02.1411251203500.2675@kaball.uk.xensource.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416870378-32481-3-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, david.vrabel@citrix.com, jun.nakajima@intel.com
Subject: Re: [Xen-devel] [PATCH v3 2/2] xen/pci: Use APIC directly when APIC
 virtualization is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
> When hardware supports APIC/x2APIC virtualization we don't need to use pirqs
> for MSI handling and instead use APIC since most APIC accesses (MMIO or MSR)
> will now be processed without VMEXITs.
> 
> As an example, netperf on the original code produces this profile
> (collected wih 'xentrace -e 0x0008ffff -T 5'):
> 
>     342 cpu_change
>     260 CPUID
>   34638 HLT
>   64067 INJ_VIRQ
>   28374 INTR
>   82733 INTR_WINDOW
>      10 NPF
>   24337 TRAP
>  370610 vlapic_accept_pic_intr
>  307528 VMENTRY
>  307527 VMEXIT
>  140998 VMMCALL
>     127 wrap_buffer
> 
> After applying this patch the same test shows
> 
>     230 cpu_change
>     260 CPUID
>   36542 HLT
>     174 INJ_VIRQ
>   27250 INTR
>     222 INTR_WINDOW
>      20 NPF
>   24999 TRAP
>  381812 vlapic_accept_pic_intr
>  166480 VMENTRY
>  166479 VMEXIT
>   77208 VMMCALL
>      81 wrap_buffer
> 
> ApacheBench results (ab -n 10000 -c 200) improve by about 10%

Very nice!


> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  arch/x86/include/asm/xen/cpuid.h | 91 ++++++++++++++++++++++++++++++++++++++++
>  arch/x86/pci/xen.c               | 10 +++++
>  2 files changed, 101 insertions(+)
>  create mode 100644 arch/x86/include/asm/xen/cpuid.h
> 
> diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h
> new file mode 100644
> index 0000000..0d809e9
> --- /dev/null
> +++ b/arch/x86/include/asm/xen/cpuid.h
> @@ -0,0 +1,91 @@
> +/******************************************************************************
> + * arch-x86/cpuid.h
> + *
> + * CPUID interface to Xen.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (c) 2007 Citrix Systems, Inc.
> + *
> + * Authors:
> + *    Keir Fraser <keir@xen.org>
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_X86_CPUID_H__
> +#define __XEN_PUBLIC_ARCH_X86_CPUID_H__
> +
> +/*
> + * For compatibility with other hypervisor interfaces, the Xen cpuid leaves
> + * can be found at the first otherwise unused 0x100 aligned boundary starting
> + * from 0x40000000.
> + *
> + * e.g If viridian extensions are enabled for an HVM domain, the Xen cpuid
> + * leaves will start at 0x40000100
> + */
> +
> +#define XEN_CPUID_FIRST_LEAF 0x40000000
> +#define XEN_CPUID_LEAF(i)    (XEN_CPUID_FIRST_LEAF + (i))
> +
> +/*
> + * Leaf 1 (0x40000x00)
> + * EAX: Largest Xen-information leaf. All leaves up to an including @EAX
> + *      are supported by the Xen host.
> + * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification
> + *      of a Xen host.
> + */
> +#define XEN_CPUID_SIGNATURE_EBX 0x566e6558 /* "XenV" */
> +#define XEN_CPUID_SIGNATURE_ECX 0x65584d4d /* "MMXe" */
> +#define XEN_CPUID_SIGNATURE_EDX 0x4d4d566e /* "nVMM" */
> +
> +/*
> + * Leaf 2 (0x40000x01)
> + * EAX[31:16]: Xen major version.
> + * EAX[15: 0]: Xen minor version.
> + * EBX-EDX: Reserved (currently all zeroes).
> + */
> +
> +/*
> + * Leaf 3 (0x40000x02)
> + * EAX: Number of hypercall transfer pages. This register is always guaranteed
> + *      to specify one hypercall page.
> + * EBX: Base address of Xen-specific MSRs.
> + * ECX: Features 1. Unused bits are set to zero.
> + * EDX: Features 2. Unused bits are set to zero.
> + */
> +
> +/* Does the host support MMU_PT_UPDATE_PRESERVE_AD for this guest? */
> +#define _XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD 0
> +#define XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD  (1u<<0)
> +
> +/*
> + * Leaf 5 (0x40000x04)
> + * HVM-specific features
> + */
> +
> +/* EAX Features */
> +/* Virtualized APIC registers */
> +#define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0)
> +/* Virtualized x2APIC accesses */
> +#define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1)
> +/* Memory mapped from other domains has valid IOMMU entries */
> +#define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
> +
> +#define XEN_CPUID_MAX_NUM_LEAVES 4
> +
> +#endif /* __XEN_PUBLIC_ARCH_X86_CPUID_H__ */
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 1370716..e4a5bab 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -23,6 +23,8 @@
>  #include <xen/features.h>
>  #include <xen/events.h>
>  #include <asm/xen/pci.h>
> +#include <asm/xen/cpuid.h>
> +#include <asm/apic.h>
>  #include <asm/i8259.h>
>  
>  static int xen_pcifront_enable_irq(struct pci_dev *dev)
> @@ -434,6 +436,14 @@ int __init pci_xen_init(void)
>  #ifdef CONFIG_PCI_MSI
>  void __init xen_msi_init(void)
>  {
> +	if (!disable_apic) {
> +		uint32_t eax = cpuid_eax(xen_cpuid_base() + 4);
> +
> +		if (((eax & XEN_HVM_CPUID_X2APIC_VIRT) && x2apic_mode) ||
> +		    ((eax & XEN_HVM_CPUID_APIC_ACCESS_VIRT) && cpu_has_apic))
> +			return;
> +	}

Please add an in-code comment to explain what this check does.


>  	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
>  	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
>  }
> -- 
> 1.9.3
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:13:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12: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 1XtEzb-0002EQ-Kn; Tue, 25 Nov 2014 12:13:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtEza-0002EI-8l
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 12:13:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CC/F3-15461-95274745; Tue, 25 Nov 2014 12:13:13 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1416917591!12410112!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15980 invoked from network); 25 Nov 2014 12:13:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:13:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196102570"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 07:05:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtErz-0000Hc-5Y;
	Tue, 25 Nov 2014 12:05:23 +0000
Date: Tue, 25 Nov 2014 12:05:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <1416870378-32481-3-git-send-email-boris.ostrovsky@oracle.com>
Message-ID: <alpine.DEB.2.02.1411251203500.2675@kaball.uk.xensource.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416870378-32481-3-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, david.vrabel@citrix.com, jun.nakajima@intel.com
Subject: Re: [Xen-devel] [PATCH v3 2/2] xen/pci: Use APIC directly when APIC
 virtualization is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
> When hardware supports APIC/x2APIC virtualization we don't need to use pirqs
> for MSI handling and instead use APIC since most APIC accesses (MMIO or MSR)
> will now be processed without VMEXITs.
> 
> As an example, netperf on the original code produces this profile
> (collected wih 'xentrace -e 0x0008ffff -T 5'):
> 
>     342 cpu_change
>     260 CPUID
>   34638 HLT
>   64067 INJ_VIRQ
>   28374 INTR
>   82733 INTR_WINDOW
>      10 NPF
>   24337 TRAP
>  370610 vlapic_accept_pic_intr
>  307528 VMENTRY
>  307527 VMEXIT
>  140998 VMMCALL
>     127 wrap_buffer
> 
> After applying this patch the same test shows
> 
>     230 cpu_change
>     260 CPUID
>   36542 HLT
>     174 INJ_VIRQ
>   27250 INTR
>     222 INTR_WINDOW
>      20 NPF
>   24999 TRAP
>  381812 vlapic_accept_pic_intr
>  166480 VMENTRY
>  166479 VMEXIT
>   77208 VMMCALL
>      81 wrap_buffer
> 
> ApacheBench results (ab -n 10000 -c 200) improve by about 10%

Very nice!


> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  arch/x86/include/asm/xen/cpuid.h | 91 ++++++++++++++++++++++++++++++++++++++++
>  arch/x86/pci/xen.c               | 10 +++++
>  2 files changed, 101 insertions(+)
>  create mode 100644 arch/x86/include/asm/xen/cpuid.h
> 
> diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h
> new file mode 100644
> index 0000000..0d809e9
> --- /dev/null
> +++ b/arch/x86/include/asm/xen/cpuid.h
> @@ -0,0 +1,91 @@
> +/******************************************************************************
> + * arch-x86/cpuid.h
> + *
> + * CPUID interface to Xen.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (c) 2007 Citrix Systems, Inc.
> + *
> + * Authors:
> + *    Keir Fraser <keir@xen.org>
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_X86_CPUID_H__
> +#define __XEN_PUBLIC_ARCH_X86_CPUID_H__
> +
> +/*
> + * For compatibility with other hypervisor interfaces, the Xen cpuid leaves
> + * can be found at the first otherwise unused 0x100 aligned boundary starting
> + * from 0x40000000.
> + *
> + * e.g If viridian extensions are enabled for an HVM domain, the Xen cpuid
> + * leaves will start at 0x40000100
> + */
> +
> +#define XEN_CPUID_FIRST_LEAF 0x40000000
> +#define XEN_CPUID_LEAF(i)    (XEN_CPUID_FIRST_LEAF + (i))
> +
> +/*
> + * Leaf 1 (0x40000x00)
> + * EAX: Largest Xen-information leaf. All leaves up to an including @EAX
> + *      are supported by the Xen host.
> + * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification
> + *      of a Xen host.
> + */
> +#define XEN_CPUID_SIGNATURE_EBX 0x566e6558 /* "XenV" */
> +#define XEN_CPUID_SIGNATURE_ECX 0x65584d4d /* "MMXe" */
> +#define XEN_CPUID_SIGNATURE_EDX 0x4d4d566e /* "nVMM" */
> +
> +/*
> + * Leaf 2 (0x40000x01)
> + * EAX[31:16]: Xen major version.
> + * EAX[15: 0]: Xen minor version.
> + * EBX-EDX: Reserved (currently all zeroes).
> + */
> +
> +/*
> + * Leaf 3 (0x40000x02)
> + * EAX: Number of hypercall transfer pages. This register is always guaranteed
> + *      to specify one hypercall page.
> + * EBX: Base address of Xen-specific MSRs.
> + * ECX: Features 1. Unused bits are set to zero.
> + * EDX: Features 2. Unused bits are set to zero.
> + */
> +
> +/* Does the host support MMU_PT_UPDATE_PRESERVE_AD for this guest? */
> +#define _XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD 0
> +#define XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD  (1u<<0)
> +
> +/*
> + * Leaf 5 (0x40000x04)
> + * HVM-specific features
> + */
> +
> +/* EAX Features */
> +/* Virtualized APIC registers */
> +#define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0)
> +/* Virtualized x2APIC accesses */
> +#define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1)
> +/* Memory mapped from other domains has valid IOMMU entries */
> +#define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
> +
> +#define XEN_CPUID_MAX_NUM_LEAVES 4
> +
> +#endif /* __XEN_PUBLIC_ARCH_X86_CPUID_H__ */
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 1370716..e4a5bab 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -23,6 +23,8 @@
>  #include <xen/features.h>
>  #include <xen/events.h>
>  #include <asm/xen/pci.h>
> +#include <asm/xen/cpuid.h>
> +#include <asm/apic.h>
>  #include <asm/i8259.h>
>  
>  static int xen_pcifront_enable_irq(struct pci_dev *dev)
> @@ -434,6 +436,14 @@ int __init pci_xen_init(void)
>  #ifdef CONFIG_PCI_MSI
>  void __init xen_msi_init(void)
>  {
> +	if (!disable_apic) {
> +		uint32_t eax = cpuid_eax(xen_cpuid_base() + 4);
> +
> +		if (((eax & XEN_HVM_CPUID_X2APIC_VIRT) && x2apic_mode) ||
> +		    ((eax & XEN_HVM_CPUID_APIC_ACCESS_VIRT) && cpu_has_apic))
> +			return;
> +	}

Please add an in-code comment to explain what this check does.


>  	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
>  	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
>  }
> -- 
> 1.9.3
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:15:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtF25-0002NJ-6c; Tue, 25 Nov 2014 12:15:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtF23-0002N8-Gw
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 12:15:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5D/98-15461-2F274745; Tue, 25 Nov 2014 12:15:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416917744!15105410!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24586 invoked from network); 25 Nov 2014 12:15:46 -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;
	25 Nov 2014 12:15:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196103401"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 07:06:39 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtEtD-0000J6-Ho;
	Tue, 25 Nov 2014 12:06:39 +0000
Date: Tue, 25 Nov 2014 12:06:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <1416870378-32481-2-git-send-email-boris.ostrovsky@oracle.com>
Message-ID: <alpine.DEB.2.02.1411251205220.2675@kaball.uk.xensource.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416870378-32481-2-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, david.vrabel@citrix.com, jun.nakajima@intel.com
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen/pci: Defer initialization of MSI
 ops on HVM guests until after x2APIC has been set up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
> If the hardware supports APIC virtualization we may decide not to use pirqs
> and instead use APIC/x2APIC directly, meaning that we don't want to set
> x86_msi.setup_msi_irqs and x86_msi.teardown_msi_irq to Xen-specific routines.
> However, x2APIC is not set up by the time pci_xen_hvm_init() is called so we
> need to postpone setting these ops until later, when we know which APIC mode
> is used.
> 
> (Note that currently x2APIC is never initialized on HVM guests. This may
> change in the future)

I take that this is safe because no MSIs can be received at this point
(apic_post_init), right?


> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  arch/x86/pci/xen.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 093f5f4..1370716 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -431,6 +431,14 @@ int __init pci_xen_init(void)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_PCI_MSI
> +void __init xen_msi_init(void)
> +{
> +	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
> +	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
> +}
> +#endif
> +
>  int __init pci_xen_hvm_init(void)
>  {
>  	if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
> @@ -445,8 +453,11 @@ int __init pci_xen_hvm_init(void)
>  #endif
>  
>  #ifdef CONFIG_PCI_MSI
> -	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
> -	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
> +	/*
> +	 * We need to wait until after x2apic is initialized
> +	 * before we can set MSI IRQ ops.
> +	 */
> +	x86_platform.apic_post_init = xen_msi_init;
>  #endif
>  	return 0;
>  }
> -- 
> 1.9.3
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:15:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtF25-0002NJ-6c; Tue, 25 Nov 2014 12:15:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtF23-0002N8-Gw
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 12:15:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5D/98-15461-2F274745; Tue, 25 Nov 2014 12:15:46 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416917744!15105410!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24586 invoked from network); 25 Nov 2014 12:15:46 -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;
	25 Nov 2014 12:15:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196103401"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 07:06:39 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtEtD-0000J6-Ho;
	Tue, 25 Nov 2014 12:06:39 +0000
Date: Tue, 25 Nov 2014 12:06:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <1416870378-32481-2-git-send-email-boris.ostrovsky@oracle.com>
Message-ID: <alpine.DEB.2.02.1411251205220.2675@kaball.uk.xensource.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416870378-32481-2-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, david.vrabel@citrix.com, jun.nakajima@intel.com
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen/pci: Defer initialization of MSI
 ops on HVM guests until after x2APIC has been set up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
> If the hardware supports APIC virtualization we may decide not to use pirqs
> and instead use APIC/x2APIC directly, meaning that we don't want to set
> x86_msi.setup_msi_irqs and x86_msi.teardown_msi_irq to Xen-specific routines.
> However, x2APIC is not set up by the time pci_xen_hvm_init() is called so we
> need to postpone setting these ops until later, when we know which APIC mode
> is used.
> 
> (Note that currently x2APIC is never initialized on HVM guests. This may
> change in the future)

I take that this is safe because no MSIs can be received at this point
(apic_post_init), right?


> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  arch/x86/pci/xen.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 093f5f4..1370716 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -431,6 +431,14 @@ int __init pci_xen_init(void)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_PCI_MSI
> +void __init xen_msi_init(void)
> +{
> +	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
> +	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
> +}
> +#endif
> +
>  int __init pci_xen_hvm_init(void)
>  {
>  	if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
> @@ -445,8 +453,11 @@ int __init pci_xen_hvm_init(void)
>  #endif
>  
>  #ifdef CONFIG_PCI_MSI
> -	x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
> -	x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
> +	/*
> +	 * We need to wait until after x2apic is initialized
> +	 * before we can set MSI IRQ ops.
> +	 */
> +	x86_platform.apic_post_init = xen_msi_init;
>  #endif
>  	return 0;
>  }
> -- 
> 1.9.3
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:25:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:25:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFB0-0002Zz-73; Tue, 25 Nov 2014 12:25:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtFAz-0002Zu-Jr
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 12:25:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6F/A9-15461-C1574745; Tue, 25 Nov 2014 12:25:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416918300!15108118!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7789 invoked from network); 25 Nov 2014 12:25:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 12:25:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 12:25:00 +0000
Message-Id: <5474832A020000780004AA66@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 12:24:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
	<54746B24020000780004A9C5@mail.emea.novell.com>
	<54745DF3.8020603@citrix.com> <547460EB.7090305@citrix.com>
	<547476A9020000780004AA29@mail.emea.novell.com>
	<547471C2.1040909@citrix.com>
In-Reply-To: <547471C2.1040909@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
 28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 13:10, <andrew.cooper3@citrix.com> wrote:
> On 25/11/14 11:31, Jan Beulich wrote:
>>>>> On 25.11.14 at 11:58, <andrew.cooper3@citrix.com> wrote:
>>> On 25/11/14 10:46, Andrew Cooper wrote:
>>>> On 25/11/14 10:42, Jan Beulich wrote:
>>>>>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>>>>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS 
>>> state.
>>>>>> As a result, injecting a fault and retrying the the vmentry is likely to 
>>>>>> fail
>>>>>> in the same way.
>>>>> That's not all that unlikely - remember that the change was prompted
>>>>> by the XSA-110 fix. There CS pieces being in a bad state would get
>>>>> corrected by the exception injection.
>>>>>
>>>>>> One other alternative, which I would pursue if we were not already in -rc2
>>>>>> would be to add some extra logic to detect repeated vmentry failure and 
>>>>>> allow
>>>>>> one attempt to shoot userspace before giving up and crashing the domain.
>>>>> That's not even needed afaict (and if it really is, it can't be all that
>>>>> difficult/intrusive): Did you observe what you attempt to fix here in
>>>>> practice, or is this just from theoretical considerations? I ask because
>>>>> I don't think it can actually happen, as the second time we get here
>>>>> the guest ought to be in kernel mode (due to the exception injection)
>>>>> and hence would get crashed anyway.
>>>> Only from theoretical considerations.  A bad CS (and possibly SS) would
>>>> be fixed by this, but there are many others which wouldn't
>>> Actually, as Tim correctly points out, a bad CS/SS won't be fixed by
>>> this without emulating the event injection.  Per the XSA-106 followup,
>>> we only ever emulate enough of event injection to cover the dpl checks
>>> on software events for older generation SVM.  We never actually emulate
>>> the context switch itself.
>> Which suggests that rather than doing the partial revert as you
>> propose we might better extend the check to become "kernel mode
>> or event injection pending".
> 
> At that point, it is safer just to unconditionally crash on a repeated
> vmentry failure, rather than gain a list of conditions which we hope
> wont leave us spinning in a loop.

Crashing on _repeated_ VM entry failure is certainly fine with me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:25:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:25:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFB0-0002Zz-73; Tue, 25 Nov 2014 12:25:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtFAz-0002Zu-Jr
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 12:25:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6F/A9-15461-C1574745; Tue, 25 Nov 2014 12:25:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416918300!15108118!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7789 invoked from network); 25 Nov 2014 12:25:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 12:25:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 12:25:00 +0000
Message-Id: <5474832A020000780004AA66@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 12:24:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416910138-9417-1-git-send-email-andrew.cooper3@citrix.com>
	<54746B24020000780004A9C5@mail.emea.novell.com>
	<54745DF3.8020603@citrix.com> <547460EB.7090305@citrix.com>
	<547476A9020000780004AA29@mail.emea.novell.com>
	<547471C2.1040909@citrix.com>
In-Reply-To: <547471C2.1040909@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of
 28b4baacd5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 13:10, <andrew.cooper3@citrix.com> wrote:
> On 25/11/14 11:31, Jan Beulich wrote:
>>>>> On 25.11.14 at 11:58, <andrew.cooper3@citrix.com> wrote:
>>> On 25/11/14 10:46, Andrew Cooper wrote:
>>>> On 25/11/14 10:42, Jan Beulich wrote:
>>>>>>>> On 25.11.14 at 11:08, <andrew.cooper3@citrix.com> wrote:
>>>>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS 
>>> state.
>>>>>> As a result, injecting a fault and retrying the the vmentry is likely to 
>>>>>> fail
>>>>>> in the same way.
>>>>> That's not all that unlikely - remember that the change was prompted
>>>>> by the XSA-110 fix. There CS pieces being in a bad state would get
>>>>> corrected by the exception injection.
>>>>>
>>>>>> One other alternative, which I would pursue if we were not already in -rc2
>>>>>> would be to add some extra logic to detect repeated vmentry failure and 
>>>>>> allow
>>>>>> one attempt to shoot userspace before giving up and crashing the domain.
>>>>> That's not even needed afaict (and if it really is, it can't be all that
>>>>> difficult/intrusive): Did you observe what you attempt to fix here in
>>>>> practice, or is this just from theoretical considerations? I ask because
>>>>> I don't think it can actually happen, as the second time we get here
>>>>> the guest ought to be in kernel mode (due to the exception injection)
>>>>> and hence would get crashed anyway.
>>>> Only from theoretical considerations.  A bad CS (and possibly SS) would
>>>> be fixed by this, but there are many others which wouldn't
>>> Actually, as Tim correctly points out, a bad CS/SS won't be fixed by
>>> this without emulating the event injection.  Per the XSA-106 followup,
>>> we only ever emulate enough of event injection to cover the dpl checks
>>> on software events for older generation SVM.  We never actually emulate
>>> the context switch itself.
>> Which suggests that rather than doing the partial revert as you
>> propose we might better extend the check to become "kernel mode
>> or event injection pending".
> 
> At that point, it is safer just to unconditionally crash on a repeated
> vmentry failure, rather than gain a list of conditions which we hope
> wont leave us spinning in a loop.

Crashing on _repeated_ VM entry failure is certainly fine with me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:29:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:29:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFEu-0002he-Ru; Tue, 25 Nov 2014 12:29:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtFEt-0002hZ-UY
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 12:29:04 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	CE/C1-25547-E0674745; Tue, 25 Nov 2014 12:29:02 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416918540!13731000!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4095 invoked from network); 25 Nov 2014 12:29:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:29:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196110751"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 07:21:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtF7q-0000bJ-DO;
	Tue, 25 Nov 2014 12:21:46 +0000
Date: Tue, 25 Nov 2014 12:21:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Don Slutz <dslutz@verizon.com>
In-Reply-To: <547396AE.7050806@terremark.com>
Message-ID: <alpine.DEB.2.02.1411251216290.2675@kaball.uk.xensource.com>
References: <1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
	<20141124150649.GB3946@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
	<5473582C.6080000@terremark.com>
	<alpine.DEB.2.02.1411241706090.2675@kaball.uk.xensource.com>
	<547396AE.7050806@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Don Slutz wrote:
> On 11/24/14 12:07, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Don Slutz wrote:
> > > On 11/24/14 10:26, Stefano Stabellini wrote:
> > > > On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
> > > > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > > > On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini
> > > > > > > wrote:
> > > > > > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > > > > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini
> > > > > > > > > wrote:
> > > > > > > > > > The rom is used for pxebooting. We don't need to allow
> > > > > > > > > > pxebooting from
> > > > > > > > > > more than one network card.  Loading a romfile for every NIC
> > > > > > > > > > wastes
> > > > > > > > > Why not? Why can't we PXE boot from each network card?
> > > > > > > > I take it back: you are right, at the moment it is actually
> > > > > > > > possible
> > > > > > > > to
> > > > > > > > pxe boot from the fourth nic for example. Maybe we could just
> > > > > > > > load
> > > > > > > > the
> > > > > > > > first four romfiles and skip the others (four is the limit
> > > > > > > > before
> > > > > > > > QEMU
> > > > > > > > fails to allocate any more memory).
> > > > > > > The limit is in the count of ROMs or the memory consumption?
> > > > > > The limit is memory consumption.
> > > > > Um, how big are those ROMs? Gigs?
> > > > I think they are 60K each in the case of rtl8139.
> > > > However they are accounted on top of the ram of the guest, that's why
> > > > the allocation fails. Strictly speaking I guess it shouldn't work even
> > > > the first time around.
> > > My extra QEMU debug says:
> > > 
> > > xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42010000
> > > mr.name=rtl8139.rom
> > > e1000 vhdr enabled
> > > xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42050000
> > > mr.name=e1000.rom
> > > 
> > > And that matches the max of 4.
> > > 
> > > #define LIBXL_MAXMEM_CONSTANT 1024
> > > 
> > > is what controls this.
> > > 
> > > > Maybe the bug is in libxl memory allocation, that doesn't account for
> > > > rom sizes.
> > > Yes.
> > Here is a better patch.
> > 
> > ---
> > 
> > libxl: account for romfile memory
> > 
> > Account for memory needed for emulated network card rom files.
> > Assume 256K for each romfile.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> This looks to be a good idea, just not fully done.
> 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index de23fec..2edb194 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4527,6 +4527,33 @@ out:
> >     /******************************************************************************/
> >   +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid,
> > libxl_domain_config *d_config)
> > +{
> > +    int i, count_rom, rc;
> > +    libxl_domain_config local_d_config;
> > +    libxl_ctx *ctx = libxl__gc_owner(gc);
> > +
> > +    if (d_config == NULL) {
> > +        libxl_domain_config_init(&local_d_config);
> > +        rc = libxl_retrieve_domain_configuration(ctx, domid,
> > &local_d_config);
> > +        if (rc < 0)
> > +            return rc;
> > +        d_config = &local_d_config;
> > +    }
> > +
> > +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> > +        return 0;
> > +
> > +    for (i = 0, count_rom = 0; i < d_config->num_nics; i++) {
> > +        if (d_config->nics[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU)
> > +            count_rom++;
> > +    }
> > +
> > +    return count_rom*LIBXL_ROMSIZE_KB;
> > +
> > +    return 0;
> 
> 2 return statements?
> 
> > +}
> > +
> >   int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t
> > max_memkb)
> >   {
> >       GC_INIT(ctx);
> > @@ -4550,11 +4577,14 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t
> > domid, uint32_t max_memkb)
> >           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be
> > greater than or or equal to memory_dynamic_max\n");
> >           goto out;
> >       }
> > -    rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb +
> > LIBXL_MAXMEM_CONSTANT);
> > +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> > +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> > +                             + libxl__get_rom_memory_kb(gc, domid, NULL));
> 
> Here (and the rest) need to check for error's.

Good suggestion.


> Also I think that LIBXL_MAXMEM_CONSTANT can be dropped here.

Probably, but I don't know whether there are any other "hidden"
allocations that would begin to fail if I removed LIBXL_MAXMEM_CONSTANT.
I think it is best to leave it as is for the moment and maybe remove it
at the beginning of the next release cycle?


> I found out that
> 
> #define LIBXL_HVM_EXTRA_MEMORY 2048
> 
> Should be
> 
> #define LIBXL_HVM_EXTRA_MEMORY (LIBXL_MAXMEM_CONSTANT + 1024)

OK


> if you change the size of the ROM memory for QEMU.  I have only done the
> static
> change.

I don't understand what you mean here. Yes, if the ROM size changes in
QEMU we'll have an issue, specifically if it increases. However I don't
know how to solve that. I guess it would be another reason to keep
LIBXL_MAXMEM_CONSTANT: have an extra little buffer.


>    -Don Slutz
> 
> 
> >       if (rc != 0) {
> >           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >                   "xc_domain_setmaxmem domid=%d memkb=%d failed "
> > -                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
> > +                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT +
> > +                libxl__get_rom_memory_kb(gc, domid, NULL), rc);
> >           goto out;
> >       }
> >   @@ -4770,11 +4800,12 @@ retry_transaction:
> >       if (enforce) {
> >           memorykb = new_target_memkb;
> >           rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
> > -                LIBXL_MAXMEM_CONSTANT);
> > +                LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid,
> > NULL));
> >           if (rc != 0) {
> >               LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >                       "xc_domain_setmaxmem domid=%d memkb=%d failed "
> > -                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT,
> > rc);
> > +                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT +
> > +                    libxl__get_rom_memory_kb(gc, domid, NULL), rc);
> >               abort_transaction = 1;
> >               goto out;
> >           }
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index 74ea84b..ca254f9 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -406,7 +406,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> >       }
> >         if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> > -        LIBXL_MAXMEM_CONSTANT) < 0) {
> > +        LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid,
> > d_config)) < 0) {
> >           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't set max
> > memory");
> >           return ERROR_FAIL;
> >       }
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index 4361421..33826ea 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -90,6 +90,7 @@
> >   #define LIBXL_XENCONSOLE_LIMIT 1048576
> >   #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
> >   #define LIBXL_MAXMEM_CONSTANT 1024
> > +#define LIBXL_ROMSIZE_KB 256
> >   #define LIBXL_PV_EXTRA_MEMORY 1024
> >   #define LIBXL_HVM_EXTRA_MEMORY 2048
> >   #define LIBXL_MIN_DOM0_MEM (128*1024)
> > @@ -1023,6 +1024,12 @@ _hidden char * libxl__domain_pvcontrol_read(libxl__gc
> > *gc,
> >   _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t
> > t,
> >                                             uint32_t domid, const char
> > *cmd);
> >   +/* Returns the amount of extra mem required to allocate roms or an libxl
> > + * error code on error.
> > + * The *d_config parameter is optional.
> > + */
> > +_hidden int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid,
> > libxl_domain_config *d_config);
> > +
> >   /* from xl_device */
> >   _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend
> > backend);
> >   _hidden char *libxl__device_disk_string_of_format(libxl_disk_format
> > format);
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:29:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:29:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFEu-0002he-Ru; Tue, 25 Nov 2014 12:29:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtFEt-0002hZ-UY
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 12:29:04 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	CE/C1-25547-E0674745; Tue, 25 Nov 2014 12:29:02 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416918540!13731000!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4095 invoked from network); 25 Nov 2014 12:29:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:29:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196110751"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 07:21:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtF7q-0000bJ-DO;
	Tue, 25 Nov 2014 12:21:46 +0000
Date: Tue, 25 Nov 2014 12:21:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Don Slutz <dslutz@verizon.com>
In-Reply-To: <547396AE.7050806@terremark.com>
Message-ID: <alpine.DEB.2.02.1411251216290.2675@kaball.uk.xensource.com>
References: <1416474814.29243.59.camel@citrix.com>
	<alpine.DEB.2.02.1411201139190.12596@kaball.uk.xensource.com>
	<1416483731.14429.8.camel@citrix.com>
	<alpine.DEB.2.02.1411201446180.12596@kaball.uk.xensource.com>
	<1416494946.14429.13.camel@citrix.com>
	<alpine.DEB.2.02.1411211706080.2675@kaball.uk.xensource.com>
	<20141121173437.GA14331@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411211811010.2675@kaball.uk.xensource.com>
	<20141121190757.GA16038@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241210260.2675@kaball.uk.xensource.com>
	<20141124150649.GB3946@laptop.dumpdata.com>
	<alpine.DEB.2.02.1411241523190.2675@kaball.uk.xensource.com>
	<5473582C.6080000@terremark.com>
	<alpine.DEB.2.02.1411241706090.2675@kaball.uk.xensource.com>
	<547396AE.7050806@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: do not load roms for any
 NICs except the first to avoid wasting memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Nov 2014, Don Slutz wrote:
> On 11/24/14 12:07, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Don Slutz wrote:
> > > On 11/24/14 10:26, Stefano Stabellini wrote:
> > > > On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > On Mon, Nov 24, 2014 at 12:17:12PM +0000, Stefano Stabellini wrote:
> > > > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > > > On Fri, Nov 21, 2014 at 06:48:53PM +0000, Stefano Stabellini
> > > > > > > wrote:
> > > > > > > > On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > > > > > On Fri, Nov 21, 2014 at 05:11:09PM +0000, Stefano Stabellini
> > > > > > > > > wrote:
> > > > > > > > > > The rom is used for pxebooting. We don't need to allow
> > > > > > > > > > pxebooting from
> > > > > > > > > > more than one network card.  Loading a romfile for every NIC
> > > > > > > > > > wastes
> > > > > > > > > Why not? Why can't we PXE boot from each network card?
> > > > > > > > I take it back: you are right, at the moment it is actually
> > > > > > > > possible
> > > > > > > > to
> > > > > > > > pxe boot from the fourth nic for example. Maybe we could just
> > > > > > > > load
> > > > > > > > the
> > > > > > > > first four romfiles and skip the others (four is the limit
> > > > > > > > before
> > > > > > > > QEMU
> > > > > > > > fails to allocate any more memory).
> > > > > > > The limit is in the count of ROMs or the memory consumption?
> > > > > > The limit is memory consumption.
> > > > > Um, how big are those ROMs? Gigs?
> > > > I think they are 60K each in the case of rtl8139.
> > > > However they are accounted on top of the ram of the guest, that's why
> > > > the allocation fails. Strictly speaking I guess it shouldn't work even
> > > > the first time around.
> > > My extra QEMU debug says:
> > > 
> > > xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42010000
> > > mr.name=rtl8139.rom
> > > e1000 vhdr enabled
> > > xen_ram_alloc: alloc 40000 bytes (256 Kib) of ram at 42050000
> > > mr.name=e1000.rom
> > > 
> > > And that matches the max of 4.
> > > 
> > > #define LIBXL_MAXMEM_CONSTANT 1024
> > > 
> > > is what controls this.
> > > 
> > > > Maybe the bug is in libxl memory allocation, that doesn't account for
> > > > rom sizes.
> > > Yes.
> > Here is a better patch.
> > 
> > ---
> > 
> > libxl: account for romfile memory
> > 
> > Account for memory needed for emulated network card rom files.
> > Assume 256K for each romfile.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> This looks to be a good idea, just not fully done.
> 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index de23fec..2edb194 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4527,6 +4527,33 @@ out:
> >     /******************************************************************************/
> >   +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid,
> > libxl_domain_config *d_config)
> > +{
> > +    int i, count_rom, rc;
> > +    libxl_domain_config local_d_config;
> > +    libxl_ctx *ctx = libxl__gc_owner(gc);
> > +
> > +    if (d_config == NULL) {
> > +        libxl_domain_config_init(&local_d_config);
> > +        rc = libxl_retrieve_domain_configuration(ctx, domid,
> > &local_d_config);
> > +        if (rc < 0)
> > +            return rc;
> > +        d_config = &local_d_config;
> > +    }
> > +
> > +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> > +        return 0;
> > +
> > +    for (i = 0, count_rom = 0; i < d_config->num_nics; i++) {
> > +        if (d_config->nics[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU)
> > +            count_rom++;
> > +    }
> > +
> > +    return count_rom*LIBXL_ROMSIZE_KB;
> > +
> > +    return 0;
> 
> 2 return statements?
> 
> > +}
> > +
> >   int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t
> > max_memkb)
> >   {
> >       GC_INIT(ctx);
> > @@ -4550,11 +4577,14 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t
> > domid, uint32_t max_memkb)
> >           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be
> > greater than or or equal to memory_dynamic_max\n");
> >           goto out;
> >       }
> > -    rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb +
> > LIBXL_MAXMEM_CONSTANT);
> > +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> > +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> > +                             + libxl__get_rom_memory_kb(gc, domid, NULL));
> 
> Here (and the rest) need to check for error's.

Good suggestion.


> Also I think that LIBXL_MAXMEM_CONSTANT can be dropped here.

Probably, but I don't know whether there are any other "hidden"
allocations that would begin to fail if I removed LIBXL_MAXMEM_CONSTANT.
I think it is best to leave it as is for the moment and maybe remove it
at the beginning of the next release cycle?


> I found out that
> 
> #define LIBXL_HVM_EXTRA_MEMORY 2048
> 
> Should be
> 
> #define LIBXL_HVM_EXTRA_MEMORY (LIBXL_MAXMEM_CONSTANT + 1024)

OK


> if you change the size of the ROM memory for QEMU.  I have only done the
> static
> change.

I don't understand what you mean here. Yes, if the ROM size changes in
QEMU we'll have an issue, specifically if it increases. However I don't
know how to solve that. I guess it would be another reason to keep
LIBXL_MAXMEM_CONSTANT: have an extra little buffer.


>    -Don Slutz
> 
> 
> >       if (rc != 0) {
> >           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >                   "xc_domain_setmaxmem domid=%d memkb=%d failed "
> > -                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
> > +                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT +
> > +                libxl__get_rom_memory_kb(gc, domid, NULL), rc);
> >           goto out;
> >       }
> >   @@ -4770,11 +4800,12 @@ retry_transaction:
> >       if (enforce) {
> >           memorykb = new_target_memkb;
> >           rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
> > -                LIBXL_MAXMEM_CONSTANT);
> > +                LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid,
> > NULL));
> >           if (rc != 0) {
> >               LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >                       "xc_domain_setmaxmem domid=%d memkb=%d failed "
> > -                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT,
> > rc);
> > +                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT +
> > +                    libxl__get_rom_memory_kb(gc, domid, NULL), rc);
> >               abort_transaction = 1;
> >               goto out;
> >           }
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index 74ea84b..ca254f9 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -406,7 +406,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> >       }
> >         if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> > -        LIBXL_MAXMEM_CONSTANT) < 0) {
> > +        LIBXL_MAXMEM_CONSTANT + libxl__get_rom_memory_kb(gc, domid,
> > d_config)) < 0) {
> >           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't set max
> > memory");
> >           return ERROR_FAIL;
> >       }
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index 4361421..33826ea 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -90,6 +90,7 @@
> >   #define LIBXL_XENCONSOLE_LIMIT 1048576
> >   #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
> >   #define LIBXL_MAXMEM_CONSTANT 1024
> > +#define LIBXL_ROMSIZE_KB 256
> >   #define LIBXL_PV_EXTRA_MEMORY 1024
> >   #define LIBXL_HVM_EXTRA_MEMORY 2048
> >   #define LIBXL_MIN_DOM0_MEM (128*1024)
> > @@ -1023,6 +1024,12 @@ _hidden char * libxl__domain_pvcontrol_read(libxl__gc
> > *gc,
> >   _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t
> > t,
> >                                             uint32_t domid, const char
> > *cmd);
> >   +/* Returns the amount of extra mem required to allocate roms or an libxl
> > + * error code on error.
> > + * The *d_config parameter is optional.
> > + */
> > +_hidden int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid,
> > libxl_domain_config *d_config);
> > +
> >   /* from xl_device */
> >   _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend
> > backend);
> >   _hidden char *libxl__device_disk_string_of_format(libxl_disk_format
> > format);
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:36:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFM8-0002v1-3Q; Tue, 25 Nov 2014 12:36:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtFM5-0002uw-TU
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 12:36:30 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BA/0B-09842-DC774745; Tue, 25 Nov 2014 12:36:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416918988!7147166!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27184 invoked from network); 25 Nov 2014 12:36:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 12:36:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 12:36:27 +0000
Message-Id: <547485D8020000780004AA76@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 12:36:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE7D2CAD8.2__="
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH] vNUMA: rename interface 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE7D2CAD8.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

No-one (including me) paid attention during review that these
structures don't adhere to the naming requirements of the public
interface: Consistently use xen_ prefixes at least for all new
additions.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface *xch
                         uint32_t nr_vnodes,
                         uint32_t nr_regions,
                         uint32_t nr_vcpus,
-                        vmemrange_t *vmemrange,
+                        xen_vmemrange_t *vmemrange,
                         unsigned int *vdistance,
                         unsigned int *vcpu_to_vnode,
                         unsigned int *vnode_to_pnode);
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2171,7 +2171,7 @@ int xc_domain_setvnuma(xc_interface *xch
                        uint32_t nr_vnodes,
                        uint32_t nr_vmemranges,
                        uint32_t nr_vcpus,
-                       vmemrange_t *vmemrange,
+                       xen_vmemrange_t *vmemrange,
                        unsigned int *vdistance,
                        unsigned int *vcpu_to_vnode,
                        unsigned int *vnode_to_pnode)
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un
     vnuma->vdistance =3D xmalloc_array(unsigned int, nr_vnodes * =
nr_vnodes);
     vnuma->vcpu_to_vnode =3D xmalloc_array(unsigned int, nr_vcpus);
     vnuma->vnode_to_pnode =3D xmalloc_array(unsigned int, nr_vnodes);
-    vnuma->vmemrange =3D xmalloc_array(vmemrange_t, nr_ranges);
+    vnuma->vmemrange =3D xmalloc_array(xen_vmemrange_t, nr_ranges);
=20
     if ( vnuma->vdistance =3D=3D NULL || vnuma->vmemrange =3D=3D NULL ||
          vnuma->vcpu_to_vnode =3D=3D NULL || vnuma->vnode_to_pnode =3D=3D =
NULL )
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -972,7 +972,7 @@ long do_memory_op(unsigned long cmd, XEN
=20
     case XENMEM_get_vnumainfo:
     {
-        struct vnuma_topology_info topology;
+        struct xen_vnuma_topology_info topology;
         struct domain *d;
         unsigned int dom_vnodes, dom_vranges, dom_vcpus;
         struct vnuma_info tmp;
@@ -1033,7 +1033,7 @@ long do_memory_op(unsigned long cmd, XEN
         read_unlock(&d->vnuma_rwlock);
=20
         tmp.vdistance =3D xmalloc_array(unsigned int, dom_vnodes * =
dom_vnodes);
-        tmp.vmemrange =3D xmalloc_array(vmemrange_t, dom_vranges);
+        tmp.vmemrange =3D xmalloc_array(xen_vmemrange_t, dom_vranges);
         tmp.vcpu_to_vnode =3D xmalloc_array(unsigned int, dom_vcpus);
=20
         if ( tmp.vdistance =3D=3D NULL ||
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -980,7 +980,7 @@ struct xen_domctl_vnuma {
     /*
      * memory rages for each vNUMA node
      */
-    XEN_GUEST_HANDLE_64(vmemrange_t) vmemrange;
+    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
 };
 typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_
 #define XENMEM_get_vnumainfo                26
=20
 /* vNUMA node memory ranges */
-struct vmemrange {
+struct xen_vmemrange {
     uint64_t start, end;
     unsigned int flags;
     unsigned int nid;
 };
-
-typedef struct vmemrange vmemrange_t;
-DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
+typedef struct xen_vmemrange xen_vmemrange_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
=20
 /*
  * vNUMA topology specifies vNUMA node number, distance table,
@@ -548,7 +547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
  * copied back to guest. Domain returns expected values of nr_vnodes,
  * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
  */
-struct vnuma_topology_info {
+struct xen_vnuma_topology_info {
     /* IN */
     domid_t domid;
     uint16_t pad;
@@ -566,12 +565,12 @@ struct vnuma_topology_info {
         uint64_t pad;
     } vcpu_to_vnode;
     union {
-        XEN_GUEST_HANDLE(vmemrange_t) h;
+        XEN_GUEST_HANDLE(xen_vmemrange_t) h;
         uint64_t pad;
     } vmemrange;
 };
-typedef struct vnuma_topology_info vnuma_topology_info_t;
-DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);
+typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
=20
 /* Next available subop number is 27 */
=20
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -100,7 +100,7 @@ struct vnuma_info {
     unsigned int *vdistance;
     unsigned int *vcpu_to_vnode;
     unsigned int *vnode_to_pnode;
-    struct vmemrange *vmemrange;
+    struct xen_vmemrange *vmemrange;
 };
=20
 void vnuma_destroy(struct vnuma_info *vnuma);



--=__PartE7D2CAD8.2__=
Content-Type: text/plain; name="memop-vnuma-rename.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="memop-vnuma-rename.patch"

vNUMA: rename interface structures=0A=0ANo-one (including me) paid =
attention during review that these=0Astructures don't adhere to the naming =
requirements of the public=0Ainterface: Consistently use xen_ prefixes at =
least for all new=0Aadditions.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/tools/libxc/include/xenctrl.h=0A+++ b/tools/libxc/includ=
e/xenctrl.h=0A@@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface =
*xch=0A                         uint32_t nr_vnodes,=0A                     =
    uint32_t nr_regions,=0A                         uint32_t nr_vcpus,=0A- =
                       vmemrange_t *vmemrange,=0A+                        =
xen_vmemrange_t *vmemrange,=0A                         unsigned int =
*vdistance,=0A                         unsigned int *vcpu_to_vnode,=0A     =
                    unsigned int *vnode_to_pnode);=0A--- a/tools/libxc/xc_d=
omain.c=0A+++ b/tools/libxc/xc_domain.c=0A@@ -2171,7 +2171,7 @@ int =
xc_domain_setvnuma(xc_interface *xch=0A                        uint32_t =
nr_vnodes,=0A                        uint32_t nr_vmemranges,=0A            =
            uint32_t nr_vcpus,=0A-                       vmemrange_t =
*vmemrange,=0A+                       xen_vmemrange_t *vmemrange,=0A       =
                 unsigned int *vdistance,=0A                        =
unsigned int *vcpu_to_vnode,=0A                        unsigned int =
*vnode_to_pnode)=0A--- a/xen/common/domctl.c=0A+++ b/xen/common/domctl.c=0A=
@@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un=0A     =
vnuma->vdistance =3D xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);=0A=
     vnuma->vcpu_to_vnode =3D xmalloc_array(unsigned int, nr_vcpus);=0A    =
 vnuma->vnode_to_pnode =3D xmalloc_array(unsigned int, nr_vnodes);=0A-    =
vnuma->vmemrange =3D xmalloc_array(vmemrange_t, nr_ranges);=0A+    =
vnuma->vmemrange =3D xmalloc_array(xen_vmemrange_t, nr_ranges);=0A =0A     =
if ( vnuma->vdistance =3D=3D NULL || vnuma->vmemrange =3D=3D NULL ||=0A    =
      vnuma->vcpu_to_vnode =3D=3D NULL || vnuma->vnode_to_pnode =3D=3D =
NULL )=0A--- a/xen/common/memory.c=0A+++ b/xen/common/memory.c=0A@@ -972,7 =
+972,7 @@ long do_memory_op(unsigned long cmd, XEN=0A =0A     case =
XENMEM_get_vnumainfo:=0A     {=0A-        struct vnuma_topology_info =
topology;=0A+        struct xen_vnuma_topology_info topology;=0A         =
struct domain *d;=0A         unsigned int dom_vnodes, dom_vranges, =
dom_vcpus;=0A         struct vnuma_info tmp;=0A@@ -1033,7 +1033,7 @@ long =
do_memory_op(unsigned long cmd, XEN=0A         read_unlock(&d->vnuma_rwlock=
);=0A =0A         tmp.vdistance =3D xmalloc_array(unsigned int, dom_vnodes =
* dom_vnodes);=0A-        tmp.vmemrange =3D xmalloc_array(vmemrange_t, =
dom_vranges);=0A+        tmp.vmemrange =3D xmalloc_array(xen_vmemrange_t, =
dom_vranges);=0A         tmp.vcpu_to_vnode =3D xmalloc_array(unsigned int, =
dom_vcpus);=0A =0A         if ( tmp.vdistance =3D=3D NULL ||=0A--- =
a/xen/include/public/domctl.h=0A+++ b/xen/include/public/domctl.h=0A@@ =
-980,7 +980,7 @@ struct xen_domctl_vnuma {=0A     /*=0A      * memory =
rages for each vNUMA node=0A      */=0A-    XEN_GUEST_HANDLE_64(vmemrange_t=
) vmemrange;=0A+    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;=0A =
};=0A typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;=0A DEFINE_XEN_GUE=
ST_HANDLE(xen_domctl_vnuma_t);=0A--- a/xen/include/public/memory.h=0A+++ =
b/xen/include/public/memory.h=0A@@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HAND=
LE(xen_mem_sharing_=0A #define XENMEM_get_vnumainfo                26=0A =
=0A /* vNUMA node memory ranges */=0A-struct vmemrange {=0A+struct =
xen_vmemrange {=0A     uint64_t start, end;=0A     unsigned int flags;=0A  =
   unsigned int nid;=0A };=0A-=0A-typedef struct vmemrange vmemrange_t;=0A-=
DEFINE_XEN_GUEST_HANDLE(vmemrange_t);=0A+typedef struct xen_vmemrange =
xen_vmemrange_t;=0A+DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);=0A =0A /*=0A =
 * vNUMA topology specifies vNUMA node number, distance table,=0A@@ -548,7 =
+547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);=0A  * copied back to =
guest. Domain returns expected values of nr_vnodes,=0A  * nr_vmemranges =
and nr_vcpus to guest if the values where incorrect.=0A  */=0A-struct =
vnuma_topology_info {=0A+struct xen_vnuma_topology_info {=0A     /* IN =
*/=0A     domid_t domid;=0A     uint16_t pad;=0A@@ -566,12 +565,12 @@ =
struct vnuma_topology_info {=0A         uint64_t pad;=0A     } vcpu_to_vnod=
e;=0A     union {=0A-        XEN_GUEST_HANDLE(vmemrange_t) h;=0A+        =
XEN_GUEST_HANDLE(xen_vmemrange_t) h;=0A         uint64_t pad;=0A     } =
vmemrange;=0A };=0A-typedef struct vnuma_topology_info vnuma_topology_info_=
t;=0A-DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);=0A+typedef struct =
xen_vnuma_topology_info xen_vnuma_topology_info_t;=0A+DEFINE_XEN_GUEST_HAND=
LE(xen_vnuma_topology_info_t);=0A =0A /* Next available subop number is 27 =
*/=0A =0A--- a/xen/include/xen/domain.h=0A+++ b/xen/include/xen/domain.h=0A=
@@ -100,7 +100,7 @@ struct vnuma_info {=0A     unsigned int *vdistance;=0A =
    unsigned int *vcpu_to_vnode;=0A     unsigned int *vnode_to_pnode;=0A-  =
  struct vmemrange *vmemrange;=0A+    struct xen_vmemrange *vmemrange;=0A =
};=0A =0A void vnuma_destroy(struct vnuma_info *vnuma);=0A
--=__PartE7D2CAD8.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartE7D2CAD8.2__=--


From xen-devel-bounces@lists.xen.org Tue Nov 25 12:36:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFM8-0002v1-3Q; Tue, 25 Nov 2014 12:36:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtFM5-0002uw-TU
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 12:36:30 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BA/0B-09842-DC774745; Tue, 25 Nov 2014 12:36:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416918988!7147166!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27184 invoked from network); 25 Nov 2014 12:36:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 12:36:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 12:36:27 +0000
Message-Id: <547485D8020000780004AA76@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 12:36:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE7D2CAD8.2__="
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH] vNUMA: rename interface 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE7D2CAD8.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

No-one (including me) paid attention during review that these
structures don't adhere to the naming requirements of the public
interface: Consistently use xen_ prefixes at least for all new
additions.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface *xch
                         uint32_t nr_vnodes,
                         uint32_t nr_regions,
                         uint32_t nr_vcpus,
-                        vmemrange_t *vmemrange,
+                        xen_vmemrange_t *vmemrange,
                         unsigned int *vdistance,
                         unsigned int *vcpu_to_vnode,
                         unsigned int *vnode_to_pnode);
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2171,7 +2171,7 @@ int xc_domain_setvnuma(xc_interface *xch
                        uint32_t nr_vnodes,
                        uint32_t nr_vmemranges,
                        uint32_t nr_vcpus,
-                       vmemrange_t *vmemrange,
+                       xen_vmemrange_t *vmemrange,
                        unsigned int *vdistance,
                        unsigned int *vcpu_to_vnode,
                        unsigned int *vnode_to_pnode)
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un
     vnuma->vdistance =3D xmalloc_array(unsigned int, nr_vnodes * =
nr_vnodes);
     vnuma->vcpu_to_vnode =3D xmalloc_array(unsigned int, nr_vcpus);
     vnuma->vnode_to_pnode =3D xmalloc_array(unsigned int, nr_vnodes);
-    vnuma->vmemrange =3D xmalloc_array(vmemrange_t, nr_ranges);
+    vnuma->vmemrange =3D xmalloc_array(xen_vmemrange_t, nr_ranges);
=20
     if ( vnuma->vdistance =3D=3D NULL || vnuma->vmemrange =3D=3D NULL ||
          vnuma->vcpu_to_vnode =3D=3D NULL || vnuma->vnode_to_pnode =3D=3D =
NULL )
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -972,7 +972,7 @@ long do_memory_op(unsigned long cmd, XEN
=20
     case XENMEM_get_vnumainfo:
     {
-        struct vnuma_topology_info topology;
+        struct xen_vnuma_topology_info topology;
         struct domain *d;
         unsigned int dom_vnodes, dom_vranges, dom_vcpus;
         struct vnuma_info tmp;
@@ -1033,7 +1033,7 @@ long do_memory_op(unsigned long cmd, XEN
         read_unlock(&d->vnuma_rwlock);
=20
         tmp.vdistance =3D xmalloc_array(unsigned int, dom_vnodes * =
dom_vnodes);
-        tmp.vmemrange =3D xmalloc_array(vmemrange_t, dom_vranges);
+        tmp.vmemrange =3D xmalloc_array(xen_vmemrange_t, dom_vranges);
         tmp.vcpu_to_vnode =3D xmalloc_array(unsigned int, dom_vcpus);
=20
         if ( tmp.vdistance =3D=3D NULL ||
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -980,7 +980,7 @@ struct xen_domctl_vnuma {
     /*
      * memory rages for each vNUMA node
      */
-    XEN_GUEST_HANDLE_64(vmemrange_t) vmemrange;
+    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
 };
 typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_
 #define XENMEM_get_vnumainfo                26
=20
 /* vNUMA node memory ranges */
-struct vmemrange {
+struct xen_vmemrange {
     uint64_t start, end;
     unsigned int flags;
     unsigned int nid;
 };
-
-typedef struct vmemrange vmemrange_t;
-DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
+typedef struct xen_vmemrange xen_vmemrange_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
=20
 /*
  * vNUMA topology specifies vNUMA node number, distance table,
@@ -548,7 +547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
  * copied back to guest. Domain returns expected values of nr_vnodes,
  * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
  */
-struct vnuma_topology_info {
+struct xen_vnuma_topology_info {
     /* IN */
     domid_t domid;
     uint16_t pad;
@@ -566,12 +565,12 @@ struct vnuma_topology_info {
         uint64_t pad;
     } vcpu_to_vnode;
     union {
-        XEN_GUEST_HANDLE(vmemrange_t) h;
+        XEN_GUEST_HANDLE(xen_vmemrange_t) h;
         uint64_t pad;
     } vmemrange;
 };
-typedef struct vnuma_topology_info vnuma_topology_info_t;
-DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);
+typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
=20
 /* Next available subop number is 27 */
=20
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -100,7 +100,7 @@ struct vnuma_info {
     unsigned int *vdistance;
     unsigned int *vcpu_to_vnode;
     unsigned int *vnode_to_pnode;
-    struct vmemrange *vmemrange;
+    struct xen_vmemrange *vmemrange;
 };
=20
 void vnuma_destroy(struct vnuma_info *vnuma);



--=__PartE7D2CAD8.2__=
Content-Type: text/plain; name="memop-vnuma-rename.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="memop-vnuma-rename.patch"

vNUMA: rename interface structures=0A=0ANo-one (including me) paid =
attention during review that these=0Astructures don't adhere to the naming =
requirements of the public=0Ainterface: Consistently use xen_ prefixes at =
least for all new=0Aadditions.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/tools/libxc/include/xenctrl.h=0A+++ b/tools/libxc/includ=
e/xenctrl.h=0A@@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface =
*xch=0A                         uint32_t nr_vnodes,=0A                     =
    uint32_t nr_regions,=0A                         uint32_t nr_vcpus,=0A- =
                       vmemrange_t *vmemrange,=0A+                        =
xen_vmemrange_t *vmemrange,=0A                         unsigned int =
*vdistance,=0A                         unsigned int *vcpu_to_vnode,=0A     =
                    unsigned int *vnode_to_pnode);=0A--- a/tools/libxc/xc_d=
omain.c=0A+++ b/tools/libxc/xc_domain.c=0A@@ -2171,7 +2171,7 @@ int =
xc_domain_setvnuma(xc_interface *xch=0A                        uint32_t =
nr_vnodes,=0A                        uint32_t nr_vmemranges,=0A            =
            uint32_t nr_vcpus,=0A-                       vmemrange_t =
*vmemrange,=0A+                       xen_vmemrange_t *vmemrange,=0A       =
                 unsigned int *vdistance,=0A                        =
unsigned int *vcpu_to_vnode,=0A                        unsigned int =
*vnode_to_pnode)=0A--- a/xen/common/domctl.c=0A+++ b/xen/common/domctl.c=0A=
@@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un=0A     =
vnuma->vdistance =3D xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);=0A=
     vnuma->vcpu_to_vnode =3D xmalloc_array(unsigned int, nr_vcpus);=0A    =
 vnuma->vnode_to_pnode =3D xmalloc_array(unsigned int, nr_vnodes);=0A-    =
vnuma->vmemrange =3D xmalloc_array(vmemrange_t, nr_ranges);=0A+    =
vnuma->vmemrange =3D xmalloc_array(xen_vmemrange_t, nr_ranges);=0A =0A     =
if ( vnuma->vdistance =3D=3D NULL || vnuma->vmemrange =3D=3D NULL ||=0A    =
      vnuma->vcpu_to_vnode =3D=3D NULL || vnuma->vnode_to_pnode =3D=3D =
NULL )=0A--- a/xen/common/memory.c=0A+++ b/xen/common/memory.c=0A@@ -972,7 =
+972,7 @@ long do_memory_op(unsigned long cmd, XEN=0A =0A     case =
XENMEM_get_vnumainfo:=0A     {=0A-        struct vnuma_topology_info =
topology;=0A+        struct xen_vnuma_topology_info topology;=0A         =
struct domain *d;=0A         unsigned int dom_vnodes, dom_vranges, =
dom_vcpus;=0A         struct vnuma_info tmp;=0A@@ -1033,7 +1033,7 @@ long =
do_memory_op(unsigned long cmd, XEN=0A         read_unlock(&d->vnuma_rwlock=
);=0A =0A         tmp.vdistance =3D xmalloc_array(unsigned int, dom_vnodes =
* dom_vnodes);=0A-        tmp.vmemrange =3D xmalloc_array(vmemrange_t, =
dom_vranges);=0A+        tmp.vmemrange =3D xmalloc_array(xen_vmemrange_t, =
dom_vranges);=0A         tmp.vcpu_to_vnode =3D xmalloc_array(unsigned int, =
dom_vcpus);=0A =0A         if ( tmp.vdistance =3D=3D NULL ||=0A--- =
a/xen/include/public/domctl.h=0A+++ b/xen/include/public/domctl.h=0A@@ =
-980,7 +980,7 @@ struct xen_domctl_vnuma {=0A     /*=0A      * memory =
rages for each vNUMA node=0A      */=0A-    XEN_GUEST_HANDLE_64(vmemrange_t=
) vmemrange;=0A+    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;=0A =
};=0A typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;=0A DEFINE_XEN_GUE=
ST_HANDLE(xen_domctl_vnuma_t);=0A--- a/xen/include/public/memory.h=0A+++ =
b/xen/include/public/memory.h=0A@@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HAND=
LE(xen_mem_sharing_=0A #define XENMEM_get_vnumainfo                26=0A =
=0A /* vNUMA node memory ranges */=0A-struct vmemrange {=0A+struct =
xen_vmemrange {=0A     uint64_t start, end;=0A     unsigned int flags;=0A  =
   unsigned int nid;=0A };=0A-=0A-typedef struct vmemrange vmemrange_t;=0A-=
DEFINE_XEN_GUEST_HANDLE(vmemrange_t);=0A+typedef struct xen_vmemrange =
xen_vmemrange_t;=0A+DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);=0A =0A /*=0A =
 * vNUMA topology specifies vNUMA node number, distance table,=0A@@ -548,7 =
+547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);=0A  * copied back to =
guest. Domain returns expected values of nr_vnodes,=0A  * nr_vmemranges =
and nr_vcpus to guest if the values where incorrect.=0A  */=0A-struct =
vnuma_topology_info {=0A+struct xen_vnuma_topology_info {=0A     /* IN =
*/=0A     domid_t domid;=0A     uint16_t pad;=0A@@ -566,12 +565,12 @@ =
struct vnuma_topology_info {=0A         uint64_t pad;=0A     } vcpu_to_vnod=
e;=0A     union {=0A-        XEN_GUEST_HANDLE(vmemrange_t) h;=0A+        =
XEN_GUEST_HANDLE(xen_vmemrange_t) h;=0A         uint64_t pad;=0A     } =
vmemrange;=0A };=0A-typedef struct vnuma_topology_info vnuma_topology_info_=
t;=0A-DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);=0A+typedef struct =
xen_vnuma_topology_info xen_vnuma_topology_info_t;=0A+DEFINE_XEN_GUEST_HAND=
LE(xen_vnuma_topology_info_t);=0A =0A /* Next available subop number is 27 =
*/=0A =0A--- a/xen/include/xen/domain.h=0A+++ b/xen/include/xen/domain.h=0A=
@@ -100,7 +100,7 @@ struct vnuma_info {=0A     unsigned int *vdistance;=0A =
    unsigned int *vcpu_to_vnode;=0A     unsigned int *vnode_to_pnode;=0A-  =
  struct vmemrange *vmemrange;=0A+    struct xen_vmemrange *vmemrange;=0A =
};=0A =0A void vnuma_destroy(struct vnuma_info *vnuma);=0A
--=__PartE7D2CAD8.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartE7D2CAD8.2__=--


From xen-devel-bounces@lists.xen.org Tue Nov 25 12:49:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12: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 1XtFYF-000374-Li; Tue, 25 Nov 2014 12:49:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtFYD-00036z-UD
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 12:49:02 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	43/A9-28296-DBA74745; Tue, 25 Nov 2014 12:49:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416919740!13677860!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23405 invoked from network); 25 Nov 2014 12:49:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 12:49:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 12:48:59 +0000
Message-Id: <547488C9020000780004AA8C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 12:48:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-10-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416179271-1221-10-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 09/21] x86/VPMU: Add public xenpmu.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -103,6 +103,10 @@
>  !	vcpu_set_singleshot_timer	vcpu.h
>  ?	xenoprof_init			xenoprof.h
>  ?	xenoprof_passive		xenoprof.h
> +?	pmu_intel_ctxt			arch-x86/pmu.h
> +?	pmu_amd_ctxt			arch-x86/pmu.h
> +?	pmu_cntr_pair			arch-x86/pmu.h
> +?	pmu_regs			arch-x86/pmu.h

If another revision turns out necessary, please get these additions
sorted alphabetically.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:49:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12: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 1XtFYF-000374-Li; Tue, 25 Nov 2014 12:49:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtFYD-00036z-UD
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 12:49:02 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	43/A9-28296-DBA74745; Tue, 25 Nov 2014 12:49:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416919740!13677860!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23405 invoked from network); 25 Nov 2014 12:49:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 12:49:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 12:48:59 +0000
Message-Id: <547488C9020000780004AA8C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 12:48:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-10-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416179271-1221-10-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 09/21] x86/VPMU: Add public xenpmu.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -103,6 +103,10 @@
>  !	vcpu_set_singleshot_timer	vcpu.h
>  ?	xenoprof_init			xenoprof.h
>  ?	xenoprof_passive		xenoprof.h
> +?	pmu_intel_ctxt			arch-x86/pmu.h
> +?	pmu_amd_ctxt			arch-x86/pmu.h
> +?	pmu_cntr_pair			arch-x86/pmu.h
> +?	pmu_regs			arch-x86/pmu.h

If another revision turns out necessary, please get these additions
sorted alphabetically.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:53:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFcC-0003H2-AU; Tue, 25 Nov 2014 12:53:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtFcA-0003Gu-VT
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 12:53:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A8/B0-25276-2BB74745; Tue, 25 Nov 2014 12:53:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416919983!15202047!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20033 invoked from network); 25 Nov 2014 12:53:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:53:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; 
	d="scan'208,217";a="196121717"
Message-ID: <547479E2.8040904@citrix.com>
Date: Tue, 25 Nov 2014 12:45:22 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <547485D8020000780004AA76@mail.emea.novell.com>
In-Reply-To: <547485D8020000780004AA76@mail.emea.novell.com>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] vNUMA: rename interface 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: multipart/mixed; boundary="===============4492339436188603862=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4492339436188603862==
Content-Type: multipart/alternative;
	boundary="------------060700030103070905030408"

--------------060700030103070905030408
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit

On 25/11/14 12:36, Jan Beulich wrote:
> No-one (including me) paid attention during review that these
> structures don't adhere to the naming requirements of the public
> interface: Consistently use xen_ prefixes at least for all new
> additions.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Good to catch this before 4.5 gets released and it is harder to justify
the change.

>
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface *xch
>                          uint32_t nr_vnodes,
>                          uint32_t nr_regions,
>                          uint32_t nr_vcpus,
> -                        vmemrange_t *vmemrange,
> +                        xen_vmemrange_t *vmemrange,
>                          unsigned int *vdistance,
>                          unsigned int *vcpu_to_vnode,
>                          unsigned int *vnode_to_pnode);
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -2171,7 +2171,7 @@ int xc_domain_setvnuma(xc_interface *xch
>                         uint32_t nr_vnodes,
>                         uint32_t nr_vmemranges,
>                         uint32_t nr_vcpus,
> -                       vmemrange_t *vmemrange,
> +                       xen_vmemrange_t *vmemrange,
>                         unsigned int *vdistance,
>                         unsigned int *vcpu_to_vnode,
>                         unsigned int *vnode_to_pnode)
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un
>      vnuma->vdistance = xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);
>      vnuma->vcpu_to_vnode = xmalloc_array(unsigned int, nr_vcpus);
>      vnuma->vnode_to_pnode = xmalloc_array(unsigned int, nr_vnodes);
> -    vnuma->vmemrange = xmalloc_array(vmemrange_t, nr_ranges);
> +    vnuma->vmemrange = xmalloc_array(xen_vmemrange_t, nr_ranges);
>  
>      if ( vnuma->vdistance == NULL || vnuma->vmemrange == NULL ||
>           vnuma->vcpu_to_vnode == NULL || vnuma->vnode_to_pnode == NULL )
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -972,7 +972,7 @@ long do_memory_op(unsigned long cmd, XEN
>  
>      case XENMEM_get_vnumainfo:
>      {
> -        struct vnuma_topology_info topology;
> +        struct xen_vnuma_topology_info topology;
>          struct domain *d;
>          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
>          struct vnuma_info tmp;
> @@ -1033,7 +1033,7 @@ long do_memory_op(unsigned long cmd, XEN
>          read_unlock(&d->vnuma_rwlock);
>  
>          tmp.vdistance = xmalloc_array(unsigned int, dom_vnodes * dom_vnodes);
> -        tmp.vmemrange = xmalloc_array(vmemrange_t, dom_vranges);
> +        tmp.vmemrange = xmalloc_array(xen_vmemrange_t, dom_vranges);
>          tmp.vcpu_to_vnode = xmalloc_array(unsigned int, dom_vcpus);
>  
>          if ( tmp.vdistance == NULL ||
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -980,7 +980,7 @@ struct xen_domctl_vnuma {
>      /*
>       * memory rages for each vNUMA node
>       */
> -    XEN_GUEST_HANDLE_64(vmemrange_t) vmemrange;
> +    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
>  };
>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_
>  #define XENMEM_get_vnumainfo                26
>  
>  /* vNUMA node memory ranges */
> -struct vmemrange {
> +struct xen_vmemrange {
>      uint64_t start, end;
>      unsigned int flags;
>      unsigned int nid;
>  };
> -
> -typedef struct vmemrange vmemrange_t;
> -DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
> +typedef struct xen_vmemrange xen_vmemrange_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
>  
>  /*
>   * vNUMA topology specifies vNUMA node number, distance table,
> @@ -548,7 +547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
>   * copied back to guest. Domain returns expected values of nr_vnodes,
>   * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
>   */
> -struct vnuma_topology_info {
> +struct xen_vnuma_topology_info {
>      /* IN */
>      domid_t domid;
>      uint16_t pad;
> @@ -566,12 +565,12 @@ struct vnuma_topology_info {
>          uint64_t pad;
>      } vcpu_to_vnode;
>      union {
> -        XEN_GUEST_HANDLE(vmemrange_t) h;
> +        XEN_GUEST_HANDLE(xen_vmemrange_t) h;
>          uint64_t pad;
>      } vmemrange;
>  };
> -typedef struct vnuma_topology_info vnuma_topology_info_t;
> -DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);
> +typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
>  
>  /* Next available subop number is 27 */
>  
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -100,7 +100,7 @@ struct vnuma_info {
>      unsigned int *vdistance;
>      unsigned int *vcpu_to_vnode;
>      unsigned int *vnode_to_pnode;
> -    struct vmemrange *vmemrange;
> +    struct xen_vmemrange *vmemrange;
>  };
>  
>  void vnuma_destroy(struct vnuma_info *vnuma);
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------060700030103070905030408
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 25/11/14 12:36, Jan Beulich wrote:<br>
    </div>
    <blockquote cite="mid:547485D8020000780004AA76@mail.emea.novell.com"
      type="cite">
      <pre wrap="">No-one (including me) paid attention during review that these
structures don't adhere to the naming requirements of the public
interface: Consistently use xen_ prefixes at least for all new
additions.

Signed-off-by: Jan Beulich <a class="moz-txt-link-rfc2396E" href="mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a></pre>
    </blockquote>
    <br>
    Reviewed-by: Andrew Cooper <a class="moz-txt-link-rfc2396E" href="mailto:andrew.cooper3@citrix.com">&lt;andrew.cooper3@citrix.com&gt;</a><br>
    <br>
    Good to catch this before 4.5 gets released and it is harder to
    justify the change.<br>
    <br>
    <blockquote cite="mid:547485D8020000780004AA76@mail.emea.novell.com"
      type="cite">
      <pre wrap="">

--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface *xch
                         uint32_t nr_vnodes,
                         uint32_t nr_regions,
                         uint32_t nr_vcpus,
-                        vmemrange_t *vmemrange,
+                        xen_vmemrange_t *vmemrange,
                         unsigned int *vdistance,
                         unsigned int *vcpu_to_vnode,
                         unsigned int *vnode_to_pnode);
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2171,7 +2171,7 @@ int xc_domain_setvnuma(xc_interface *xch
                        uint32_t nr_vnodes,
                        uint32_t nr_vmemranges,
                        uint32_t nr_vcpus,
-                       vmemrange_t *vmemrange,
+                       xen_vmemrange_t *vmemrange,
                        unsigned int *vdistance,
                        unsigned int *vcpu_to_vnode,
                        unsigned int *vnode_to_pnode)
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un
     vnuma-&gt;vdistance = xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);
     vnuma-&gt;vcpu_to_vnode = xmalloc_array(unsigned int, nr_vcpus);
     vnuma-&gt;vnode_to_pnode = xmalloc_array(unsigned int, nr_vnodes);
-    vnuma-&gt;vmemrange = xmalloc_array(vmemrange_t, nr_ranges);
+    vnuma-&gt;vmemrange = xmalloc_array(xen_vmemrange_t, nr_ranges);
 
     if ( vnuma-&gt;vdistance == NULL || vnuma-&gt;vmemrange == NULL ||
          vnuma-&gt;vcpu_to_vnode == NULL || vnuma-&gt;vnode_to_pnode == NULL )
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -972,7 +972,7 @@ long do_memory_op(unsigned long cmd, XEN
 
     case XENMEM_get_vnumainfo:
     {
-        struct vnuma_topology_info topology;
+        struct xen_vnuma_topology_info topology;
         struct domain *d;
         unsigned int dom_vnodes, dom_vranges, dom_vcpus;
         struct vnuma_info tmp;
@@ -1033,7 +1033,7 @@ long do_memory_op(unsigned long cmd, XEN
         read_unlock(&amp;d-&gt;vnuma_rwlock);
 
         tmp.vdistance = xmalloc_array(unsigned int, dom_vnodes * dom_vnodes);
-        tmp.vmemrange = xmalloc_array(vmemrange_t, dom_vranges);
+        tmp.vmemrange = xmalloc_array(xen_vmemrange_t, dom_vranges);
         tmp.vcpu_to_vnode = xmalloc_array(unsigned int, dom_vcpus);
 
         if ( tmp.vdistance == NULL ||
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -980,7 +980,7 @@ struct xen_domctl_vnuma {
     /*
      * memory rages for each vNUMA node
      */
-    XEN_GUEST_HANDLE_64(vmemrange_t) vmemrange;
+    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
 };
 typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_
 #define XENMEM_get_vnumainfo                26
 
 /* vNUMA node memory ranges */
-struct vmemrange {
+struct xen_vmemrange {
     uint64_t start, end;
     unsigned int flags;
     unsigned int nid;
 };
-
-typedef struct vmemrange vmemrange_t;
-DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
+typedef struct xen_vmemrange xen_vmemrange_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
 
 /*
  * vNUMA topology specifies vNUMA node number, distance table,
@@ -548,7 +547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
  * copied back to guest. Domain returns expected values of nr_vnodes,
  * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
  */
-struct vnuma_topology_info {
+struct xen_vnuma_topology_info {
     /* IN */
     domid_t domid;
     uint16_t pad;
@@ -566,12 +565,12 @@ struct vnuma_topology_info {
         uint64_t pad;
     } vcpu_to_vnode;
     union {
-        XEN_GUEST_HANDLE(vmemrange_t) h;
+        XEN_GUEST_HANDLE(xen_vmemrange_t) h;
         uint64_t pad;
     } vmemrange;
 };
-typedef struct vnuma_topology_info vnuma_topology_info_t;
-DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);
+typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
 
 /* Next available subop number is 27 */
 
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -100,7 +100,7 @@ struct vnuma_info {
     unsigned int *vdistance;
     unsigned int *vcpu_to_vnode;
     unsigned int *vnode_to_pnode;
-    struct vmemrange *vmemrange;
+    struct xen_vmemrange *vmemrange;
 };
 
 void vnuma_destroy(struct vnuma_info *vnuma);


</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------060700030103070905030408--


--===============4492339436188603862==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4492339436188603862==--


From xen-devel-bounces@lists.xen.org Tue Nov 25 12:53:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFcC-0003H2-AU; Tue, 25 Nov 2014 12:53:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtFcA-0003Gu-VT
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 12:53:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A8/B0-25276-2BB74745; Tue, 25 Nov 2014 12:53:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416919983!15202047!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20033 invoked from network); 25 Nov 2014 12:53:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:53:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; 
	d="scan'208,217";a="196121717"
Message-ID: <547479E2.8040904@citrix.com>
Date: Tue, 25 Nov 2014 12:45:22 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <547485D8020000780004AA76@mail.emea.novell.com>
In-Reply-To: <547485D8020000780004AA76@mail.emea.novell.com>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] vNUMA: rename interface 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: multipart/mixed; boundary="===============4492339436188603862=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4492339436188603862==
Content-Type: multipart/alternative;
	boundary="------------060700030103070905030408"

--------------060700030103070905030408
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit

On 25/11/14 12:36, Jan Beulich wrote:
> No-one (including me) paid attention during review that these
> structures don't adhere to the naming requirements of the public
> interface: Consistently use xen_ prefixes at least for all new
> additions.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Good to catch this before 4.5 gets released and it is harder to justify
the change.

>
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface *xch
>                          uint32_t nr_vnodes,
>                          uint32_t nr_regions,
>                          uint32_t nr_vcpus,
> -                        vmemrange_t *vmemrange,
> +                        xen_vmemrange_t *vmemrange,
>                          unsigned int *vdistance,
>                          unsigned int *vcpu_to_vnode,
>                          unsigned int *vnode_to_pnode);
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -2171,7 +2171,7 @@ int xc_domain_setvnuma(xc_interface *xch
>                         uint32_t nr_vnodes,
>                         uint32_t nr_vmemranges,
>                         uint32_t nr_vcpus,
> -                       vmemrange_t *vmemrange,
> +                       xen_vmemrange_t *vmemrange,
>                         unsigned int *vdistance,
>                         unsigned int *vcpu_to_vnode,
>                         unsigned int *vnode_to_pnode)
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un
>      vnuma->vdistance = xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);
>      vnuma->vcpu_to_vnode = xmalloc_array(unsigned int, nr_vcpus);
>      vnuma->vnode_to_pnode = xmalloc_array(unsigned int, nr_vnodes);
> -    vnuma->vmemrange = xmalloc_array(vmemrange_t, nr_ranges);
> +    vnuma->vmemrange = xmalloc_array(xen_vmemrange_t, nr_ranges);
>  
>      if ( vnuma->vdistance == NULL || vnuma->vmemrange == NULL ||
>           vnuma->vcpu_to_vnode == NULL || vnuma->vnode_to_pnode == NULL )
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -972,7 +972,7 @@ long do_memory_op(unsigned long cmd, XEN
>  
>      case XENMEM_get_vnumainfo:
>      {
> -        struct vnuma_topology_info topology;
> +        struct xen_vnuma_topology_info topology;
>          struct domain *d;
>          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
>          struct vnuma_info tmp;
> @@ -1033,7 +1033,7 @@ long do_memory_op(unsigned long cmd, XEN
>          read_unlock(&d->vnuma_rwlock);
>  
>          tmp.vdistance = xmalloc_array(unsigned int, dom_vnodes * dom_vnodes);
> -        tmp.vmemrange = xmalloc_array(vmemrange_t, dom_vranges);
> +        tmp.vmemrange = xmalloc_array(xen_vmemrange_t, dom_vranges);
>          tmp.vcpu_to_vnode = xmalloc_array(unsigned int, dom_vcpus);
>  
>          if ( tmp.vdistance == NULL ||
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -980,7 +980,7 @@ struct xen_domctl_vnuma {
>      /*
>       * memory rages for each vNUMA node
>       */
> -    XEN_GUEST_HANDLE_64(vmemrange_t) vmemrange;
> +    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
>  };
>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_
>  #define XENMEM_get_vnumainfo                26
>  
>  /* vNUMA node memory ranges */
> -struct vmemrange {
> +struct xen_vmemrange {
>      uint64_t start, end;
>      unsigned int flags;
>      unsigned int nid;
>  };
> -
> -typedef struct vmemrange vmemrange_t;
> -DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
> +typedef struct xen_vmemrange xen_vmemrange_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
>  
>  /*
>   * vNUMA topology specifies vNUMA node number, distance table,
> @@ -548,7 +547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
>   * copied back to guest. Domain returns expected values of nr_vnodes,
>   * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
>   */
> -struct vnuma_topology_info {
> +struct xen_vnuma_topology_info {
>      /* IN */
>      domid_t domid;
>      uint16_t pad;
> @@ -566,12 +565,12 @@ struct vnuma_topology_info {
>          uint64_t pad;
>      } vcpu_to_vnode;
>      union {
> -        XEN_GUEST_HANDLE(vmemrange_t) h;
> +        XEN_GUEST_HANDLE(xen_vmemrange_t) h;
>          uint64_t pad;
>      } vmemrange;
>  };
> -typedef struct vnuma_topology_info vnuma_topology_info_t;
> -DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);
> +typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
>  
>  /* Next available subop number is 27 */
>  
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -100,7 +100,7 @@ struct vnuma_info {
>      unsigned int *vdistance;
>      unsigned int *vcpu_to_vnode;
>      unsigned int *vnode_to_pnode;
> -    struct vmemrange *vmemrange;
> +    struct xen_vmemrange *vmemrange;
>  };
>  
>  void vnuma_destroy(struct vnuma_info *vnuma);
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------060700030103070905030408
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 25/11/14 12:36, Jan Beulich wrote:<br>
    </div>
    <blockquote cite="mid:547485D8020000780004AA76@mail.emea.novell.com"
      type="cite">
      <pre wrap="">No-one (including me) paid attention during review that these
structures don't adhere to the naming requirements of the public
interface: Consistently use xen_ prefixes at least for all new
additions.

Signed-off-by: Jan Beulich <a class="moz-txt-link-rfc2396E" href="mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a></pre>
    </blockquote>
    <br>
    Reviewed-by: Andrew Cooper <a class="moz-txt-link-rfc2396E" href="mailto:andrew.cooper3@citrix.com">&lt;andrew.cooper3@citrix.com&gt;</a><br>
    <br>
    Good to catch this before 4.5 gets released and it is harder to
    justify the change.<br>
    <br>
    <blockquote cite="mid:547485D8020000780004AA76@mail.emea.novell.com"
      type="cite">
      <pre wrap="">

--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface *xch
                         uint32_t nr_vnodes,
                         uint32_t nr_regions,
                         uint32_t nr_vcpus,
-                        vmemrange_t *vmemrange,
+                        xen_vmemrange_t *vmemrange,
                         unsigned int *vdistance,
                         unsigned int *vcpu_to_vnode,
                         unsigned int *vnode_to_pnode);
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2171,7 +2171,7 @@ int xc_domain_setvnuma(xc_interface *xch
                        uint32_t nr_vnodes,
                        uint32_t nr_vmemranges,
                        uint32_t nr_vcpus,
-                       vmemrange_t *vmemrange,
+                       xen_vmemrange_t *vmemrange,
                        unsigned int *vdistance,
                        unsigned int *vcpu_to_vnode,
                        unsigned int *vnode_to_pnode)
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un
     vnuma-&gt;vdistance = xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);
     vnuma-&gt;vcpu_to_vnode = xmalloc_array(unsigned int, nr_vcpus);
     vnuma-&gt;vnode_to_pnode = xmalloc_array(unsigned int, nr_vnodes);
-    vnuma-&gt;vmemrange = xmalloc_array(vmemrange_t, nr_ranges);
+    vnuma-&gt;vmemrange = xmalloc_array(xen_vmemrange_t, nr_ranges);
 
     if ( vnuma-&gt;vdistance == NULL || vnuma-&gt;vmemrange == NULL ||
          vnuma-&gt;vcpu_to_vnode == NULL || vnuma-&gt;vnode_to_pnode == NULL )
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -972,7 +972,7 @@ long do_memory_op(unsigned long cmd, XEN
 
     case XENMEM_get_vnumainfo:
     {
-        struct vnuma_topology_info topology;
+        struct xen_vnuma_topology_info topology;
         struct domain *d;
         unsigned int dom_vnodes, dom_vranges, dom_vcpus;
         struct vnuma_info tmp;
@@ -1033,7 +1033,7 @@ long do_memory_op(unsigned long cmd, XEN
         read_unlock(&amp;d-&gt;vnuma_rwlock);
 
         tmp.vdistance = xmalloc_array(unsigned int, dom_vnodes * dom_vnodes);
-        tmp.vmemrange = xmalloc_array(vmemrange_t, dom_vranges);
+        tmp.vmemrange = xmalloc_array(xen_vmemrange_t, dom_vranges);
         tmp.vcpu_to_vnode = xmalloc_array(unsigned int, dom_vcpus);
 
         if ( tmp.vdistance == NULL ||
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -980,7 +980,7 @@ struct xen_domctl_vnuma {
     /*
      * memory rages for each vNUMA node
      */
-    XEN_GUEST_HANDLE_64(vmemrange_t) vmemrange;
+    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
 };
 typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_
 #define XENMEM_get_vnumainfo                26
 
 /* vNUMA node memory ranges */
-struct vmemrange {
+struct xen_vmemrange {
     uint64_t start, end;
     unsigned int flags;
     unsigned int nid;
 };
-
-typedef struct vmemrange vmemrange_t;
-DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
+typedef struct xen_vmemrange xen_vmemrange_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
 
 /*
  * vNUMA topology specifies vNUMA node number, distance table,
@@ -548,7 +547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
  * copied back to guest. Domain returns expected values of nr_vnodes,
  * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
  */
-struct vnuma_topology_info {
+struct xen_vnuma_topology_info {
     /* IN */
     domid_t domid;
     uint16_t pad;
@@ -566,12 +565,12 @@ struct vnuma_topology_info {
         uint64_t pad;
     } vcpu_to_vnode;
     union {
-        XEN_GUEST_HANDLE(vmemrange_t) h;
+        XEN_GUEST_HANDLE(xen_vmemrange_t) h;
         uint64_t pad;
     } vmemrange;
 };
-typedef struct vnuma_topology_info vnuma_topology_info_t;
-DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);
+typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
 
 /* Next available subop number is 27 */
 
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -100,7 +100,7 @@ struct vnuma_info {
     unsigned int *vdistance;
     unsigned int *vcpu_to_vnode;
     unsigned int *vnode_to_pnode;
-    struct vmemrange *vmemrange;
+    struct xen_vmemrange *vmemrange;
 };
 
 void vnuma_destroy(struct vnuma_info *vnuma);


</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------060700030103070905030408--


--===============4492339436188603862==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4492339436188603862==--


From xen-devel-bounces@lists.xen.org Tue Nov 25 12:54:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:54:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFde-0003M3-QC; Tue, 25 Nov 2014 12:54:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtFdc-0003Ls-Nk
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 12:54:36 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	02/B5-02696-B0C74745; Tue, 25 Nov 2014 12:54:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416920074!14715005!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9281 invoked from network); 25 Nov 2014 12:54:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:54:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196524874"
Message-ID: <1416920071.32327.16.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 25 Nov 2014 12:54:31 +0000
In-Reply-To: <547485D8020000780004AA76@mail.emea.novell.com>
References: <547485D8020000780004AA76@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] vNUMA: rename interface 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

On Tue, 2014-11-25 at 12:36 +0000, Jan Beulich wrote:
> No-one (including me) paid attention during review that these
> structures don't adhere to the naming requirements of the public
> interface: Consistently use xen_ prefixes at least for all new
> additions.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.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 Nov 25 12:54:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:54:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFde-0003M3-QC; Tue, 25 Nov 2014 12:54:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtFdc-0003Ls-Nk
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 12:54:36 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	02/B5-02696-B0C74745; Tue, 25 Nov 2014 12:54:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416920074!14715005!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9281 invoked from network); 25 Nov 2014 12:54:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:54:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196524874"
Message-ID: <1416920071.32327.16.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 25 Nov 2014 12:54:31 +0000
In-Reply-To: <547485D8020000780004AA76@mail.emea.novell.com>
References: <547485D8020000780004AA76@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] vNUMA: rename interface 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

On Tue, 2014-11-25 at 12:36 +0000, Jan Beulich wrote:
> No-one (including me) paid attention during review that these
> structures don't adhere to the naming requirements of the public
> interface: Consistently use xen_ prefixes at least for all new
> additions.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.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 Nov 25 12:59:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:59:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFiP-0003Yz-P0; Tue, 25 Nov 2014 12:59:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtFiO-0003Yu-PP
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 12:59:32 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	C6/89-02576-43D74745; Tue, 25 Nov 2014 12:59:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416920369!14700034!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4082 invoked from network); 25 Nov 2014 12:59:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:59:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196526420"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 07:59:28 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtFiJ-0002Tm-RS;
	Tue, 25 Nov 2014 12:59:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtFiJ-0000mh-FQ;
	Tue, 25 Nov 2014 12:59:27 +0000
Date: Tue, 25 Nov 2014 12:59:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31841-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31841: 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 31841 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31841/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3) broken REGR. vs. 31801
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 31801

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                a31a7475e930dc0b8f27fb71f01ff4f0db92d1f4
baseline version:
 qemuu                0e88f478508b566152c6681f4889ed9830a2c0a5

------------------------------------------------------------
People who touched revisions under test:
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Richard Bilson <rbilson@qnx.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         broken  
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-qemut-win7-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit a31a7475e930dc0b8f27fb71f01ff4f0db92d1f4
Merge: 0e88f47 5224c88
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Mon Nov 24 13:50:22 2014 +0000

    Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
    
    Three patches to fix ExtINT for the QEMU implementation of the local APIC.
    
    # gpg: Signature made Mon 24 Nov 2014 13:38:36 GMT using RSA key ID 78C7AE83
    # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
    # gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>"
    # gpg: WARNING: This key is not certified with sufficiently trusted signatures!
    # gpg:          It is not certain that the signature belongs to the owner.
    # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
    #      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83
    
    * remotes/bonzini/tags/for-upstream:
      apic: fix incorrect handling of ExtINT interrupts wrt processor priority
      apic: fix loss of IPI due to masked ExtINT
      apic: avoid getting out of halted state on masked PIC interrupts
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 5224c88dd3f771702d450780a25f155e0fc8bb2b
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Nov 11 13:14:18 2014 +0100

    apic: fix incorrect handling of ExtINT interrupts wrt processor priority
    
    This fixes another failure with ExtINT, demonstrated by QNX.  The failure
    mode is as follows:
    - IPI sent to cpu 0 (bit set in APIC irr)
    - IPI accepted by cpu 0 (bit cleared in irr, set in isr)
    - IPI sent to cpu 0 (bit set in both irr and isr)
    - PIC interrupt sent to cpu 0
    
    The PIC interrupt causes CPU_INTERRUPT_HARD to be set, but
    apic_irq_pending observes that the highest pending APIC interrupt priority
    (the IPI) is the same as the processor priority (since the IPI is still
    being handled), so apic_get_interrupt returns a spurious interrupt rather
    than the pending PIC interrupt. The result is an endless sequence of
    spurious interrupts, since nothing will clear CPU_INTERRUPT_HARD.
    
    Instead, ExtINT interrupts should have ignored the processor priority.
    Calling apic_check_pic early in apic_get_interrupt ensures that
    apic_deliver_pic_intr is called instead of delivering the spurious
    interrupt.  apic_deliver_pic_intr then clears CPU_INTERRUPT_HARD if needed.
    
    Reported-by: Richard Bilson <rbilson@qnx.com>
    Tested-by: Richard Bilson <rbilson@qnx.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 8092cb71322ca488deeb7c750ff8022ffcc2f9a6
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Nov 11 13:14:14 2014 +0100

    apic: fix loss of IPI due to masked ExtINT
    
    This patch fixes an obscure failure of the QNX kernel on QEMU x86 SMP.
    In QNX, all hardware interrupts come via the PIC, and are delivered by
    the cpu 0 LAPIC in ExtINT mode, while IPIs are delivered by the LAPIC
    in fixed mode.
    
    This bug happens as follows:
    - cpu 0 masks a particular PIC interrupt
    - IPI sent to cpu 0 (CPU_INTERRUPT_HARD is set)
    - before the IPI is accepted, the masked interrupt line is asserted by the
    device
    
    Since the interrupt is masked, apic_deliver_pic_intr will clear
    CPU_INTERRUPT_HARD. The IPI will still be set in the APIC irr, but since
    CPU_INTERRUPT_HARD is not set the cpu will not notice. Depending on the
    scenario this can cause a system hang, i.e. if cpu 0 is expected to unmask
    the interrupt.
    
    In order to fix this, do a full check of the APIC before an EXTINT
    is acknowledged.  This can result in clearing CPU_INTERRUPT_HARD, but
    can also result in delivering the lost IPI.
    
    Reported-by: Richard Bilson <rbilson@qnx.com>
    Tested-by: Richard Bilson <rbilson@qnx.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 60e68042cf70f271308dc6b4b22b609d054af929
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Nov 11 13:14:05 2014 +0100

    apic: avoid getting out of halted state on masked PIC interrupts
    
    After the next patch, if a masked PIC interrupts causes CPU_INTERRUPT_POLL
    to be set, the CPU will spuriously get out of halted state.  While this
    is technically valid, we should avoid that.
    
    Make CPU_INTERRUPT_POLL run apic_update_irq in the right thread and then
    look at CPU_INTERRUPT_HARD.  If CPU_INTERRUPT_HARD does not get set,
    do not report the CPU as having work.
    
    Also move the handling of software-disabled APIC from apic_update_irq
    to apic_irq_pending, and always trigger CPU_INTERRUPT_POLL.  This will
    be important once we will add a case that resets CPU_INTERRUPT_HARD
    from apic_update_irq.  We want to run it even if we go through
    CPU_INTERRUPT_POLL, and even if the local APIC is software disabled.
    
    Reported-by: Richard Bilson <rbilson@qnx.com>
    Tested-by: Richard Bilson <rbilson@qnx.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 12:59:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 12:59:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtFiP-0003Yz-P0; Tue, 25 Nov 2014 12:59:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtFiO-0003Yu-PP
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 12:59:32 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	C6/89-02576-43D74745; Tue, 25 Nov 2014 12:59:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416920369!14700034!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4082 invoked from network); 25 Nov 2014 12:59:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 12:59:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196526420"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 07:59:28 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtFiJ-0002Tm-RS;
	Tue, 25 Nov 2014 12:59:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtFiJ-0000mh-FQ;
	Tue, 25 Nov 2014 12:59:27 +0000
Date: Tue, 25 Nov 2014 12:59:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31841-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31841: 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 31841 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31841/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3) broken REGR. vs. 31801
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 31801

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                a31a7475e930dc0b8f27fb71f01ff4f0db92d1f4
baseline version:
 qemuu                0e88f478508b566152c6681f4889ed9830a2c0a5

------------------------------------------------------------
People who touched revisions under test:
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Richard Bilson <rbilson@qnx.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         broken  
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-qemut-win7-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit a31a7475e930dc0b8f27fb71f01ff4f0db92d1f4
Merge: 0e88f47 5224c88
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Mon Nov 24 13:50:22 2014 +0000

    Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
    
    Three patches to fix ExtINT for the QEMU implementation of the local APIC.
    
    # gpg: Signature made Mon 24 Nov 2014 13:38:36 GMT using RSA key ID 78C7AE83
    # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
    # gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>"
    # gpg: WARNING: This key is not certified with sufficiently trusted signatures!
    # gpg:          It is not certain that the signature belongs to the owner.
    # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
    #      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83
    
    * remotes/bonzini/tags/for-upstream:
      apic: fix incorrect handling of ExtINT interrupts wrt processor priority
      apic: fix loss of IPI due to masked ExtINT
      apic: avoid getting out of halted state on masked PIC interrupts
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 5224c88dd3f771702d450780a25f155e0fc8bb2b
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Nov 11 13:14:18 2014 +0100

    apic: fix incorrect handling of ExtINT interrupts wrt processor priority
    
    This fixes another failure with ExtINT, demonstrated by QNX.  The failure
    mode is as follows:
    - IPI sent to cpu 0 (bit set in APIC irr)
    - IPI accepted by cpu 0 (bit cleared in irr, set in isr)
    - IPI sent to cpu 0 (bit set in both irr and isr)
    - PIC interrupt sent to cpu 0
    
    The PIC interrupt causes CPU_INTERRUPT_HARD to be set, but
    apic_irq_pending observes that the highest pending APIC interrupt priority
    (the IPI) is the same as the processor priority (since the IPI is still
    being handled), so apic_get_interrupt returns a spurious interrupt rather
    than the pending PIC interrupt. The result is an endless sequence of
    spurious interrupts, since nothing will clear CPU_INTERRUPT_HARD.
    
    Instead, ExtINT interrupts should have ignored the processor priority.
    Calling apic_check_pic early in apic_get_interrupt ensures that
    apic_deliver_pic_intr is called instead of delivering the spurious
    interrupt.  apic_deliver_pic_intr then clears CPU_INTERRUPT_HARD if needed.
    
    Reported-by: Richard Bilson <rbilson@qnx.com>
    Tested-by: Richard Bilson <rbilson@qnx.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 8092cb71322ca488deeb7c750ff8022ffcc2f9a6
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Nov 11 13:14:14 2014 +0100

    apic: fix loss of IPI due to masked ExtINT
    
    This patch fixes an obscure failure of the QNX kernel on QEMU x86 SMP.
    In QNX, all hardware interrupts come via the PIC, and are delivered by
    the cpu 0 LAPIC in ExtINT mode, while IPIs are delivered by the LAPIC
    in fixed mode.
    
    This bug happens as follows:
    - cpu 0 masks a particular PIC interrupt
    - IPI sent to cpu 0 (CPU_INTERRUPT_HARD is set)
    - before the IPI is accepted, the masked interrupt line is asserted by the
    device
    
    Since the interrupt is masked, apic_deliver_pic_intr will clear
    CPU_INTERRUPT_HARD. The IPI will still be set in the APIC irr, but since
    CPU_INTERRUPT_HARD is not set the cpu will not notice. Depending on the
    scenario this can cause a system hang, i.e. if cpu 0 is expected to unmask
    the interrupt.
    
    In order to fix this, do a full check of the APIC before an EXTINT
    is acknowledged.  This can result in clearing CPU_INTERRUPT_HARD, but
    can also result in delivering the lost IPI.
    
    Reported-by: Richard Bilson <rbilson@qnx.com>
    Tested-by: Richard Bilson <rbilson@qnx.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 60e68042cf70f271308dc6b4b22b609d054af929
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Nov 11 13:14:05 2014 +0100

    apic: avoid getting out of halted state on masked PIC interrupts
    
    After the next patch, if a masked PIC interrupts causes CPU_INTERRUPT_POLL
    to be set, the CPU will spuriously get out of halted state.  While this
    is technically valid, we should avoid that.
    
    Make CPU_INTERRUPT_POLL run apic_update_irq in the right thread and then
    look at CPU_INTERRUPT_HARD.  If CPU_INTERRUPT_HARD does not get set,
    do not report the CPU as having work.
    
    Also move the handling of software-disabled APIC from apic_update_irq
    to apic_irq_pending, and always trigger CPU_INTERRUPT_POLL.  This will
    be important once we will add a case that resets CPU_INTERRUPT_HARD
    from apic_update_irq.  We want to run it even if we go through
    CPU_INTERRUPT_POLL, and even if the local APIC is software disabled.
    
    Reported-by: Richard Bilson <rbilson@qnx.com>
    Tested-by: Richard Bilson <rbilson@qnx.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:09:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13: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 1XtFrU-0003m7-T9; Tue, 25 Nov 2014 13:08:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtFrT-0003m2-RZ
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 13:08:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EB/3F-09842-76F74745; Tue, 25 Nov 2014 13:08:55 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416920933!11750996!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27741 invoked from network); 25 Nov 2014 13:08:54 -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;
	25 Nov 2014 13:08:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196129356"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 08:00:42 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtFSz-0000yC-VZ;
	Tue, 25 Nov 2014 12:43:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 25 Nov 2014 12:43:32 +0000
Message-ID: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	stefano.stabellini@eu.citrix.com, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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

Account for the extra memory needed for the rom files of any emulated nics:
QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
each them. Assume 256K each.

This patch fixes a QEMU abort() when more than 4 emulated nics are
assigned to a VM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Don Slutz <dslutz@verizon.com>
CC: hanyandong <hanyandong@iie.ac.cn>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>

---

Changes in v2:
- remove double return statement;
- check for return errors;
- check for overflows.
---
 tools/libxl/libxl.c          |   53 +++++++++++++++++++++++++++++++++++++-----
 tools/libxl/libxl_dom.c      |    8 +++++--
 tools/libxl/libxl_internal.h |    7 ++++++
 3 files changed, 60 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..2cdb768 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4527,13 +4527,40 @@ out:
 
 /******************************************************************************/
 
+int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
+{
+    int i, romsize, rc;
+    libxl_domain_config local_d_config;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    if (d_config == NULL) {
+        libxl_domain_config_init(&local_d_config);
+        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
+        if (rc < 0)
+            return rc;
+        d_config = &local_d_config;
+    }
+
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
+        return 0;
+
+    for (i = 0, romsize = 0;
+         i < d_config->num_nics && romsize < INT_MAX;
+         i++) {
+        if (d_config->nics[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU)
+            romsize += LIBXL_ROMSIZE_KB;
+    }
+
+    return romsize;
+}
+
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 {
     GC_INIT(ctx);
     char *mem, *endptr;
     uint32_t memorykb;
     char *dompath = libxl__xs_get_dompath(gc, domid);
-    int rc = 1;
+    int rc = 1, romsize;
 
     mem = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/memory/target", dompath));
     if (!mem) {
@@ -4550,11 +4577,18 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
         goto out;
     }
-    rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + LIBXL_MAXMEM_CONSTANT);
+    rc = libxl__get_rom_memory_kb(gc, domid, NULL);
+    if (rc < 0)
+        goto out;
+    romsize = rc;
+    rc = xc_domain_setmaxmem(ctx->xch, domid,
+                             max_memkb + LIBXL_MAXMEM_CONSTANT
+                             + romsize);
     if (rc != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "xc_domain_setmaxmem domid=%d memkb=%d failed "
-                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
+                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT +
+                romsize, rc);
         goto out;
     }
 
@@ -4683,7 +4717,7 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
         int32_t target_memkb, int relative, int enforce)
 {
     GC_INIT(ctx);
-    int rc = 1, abort_transaction = 0;
+    int rc = 1, abort_transaction = 0, romsize;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     uint32_t current_max_memkb = 0;
@@ -4769,12 +4803,19 @@ retry_transaction:
 
     if (enforce) {
         memorykb = new_target_memkb;
+        rc = libxl__get_rom_memory_kb(gc, domid, NULL);
+        if (rc < 0) {
+            abort_transaction = 1;
+            goto out;
+        }
+        romsize = rc;
         rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
-                LIBXL_MAXMEM_CONSTANT);
+                LIBXL_MAXMEM_CONSTANT + romsize);
         if (rc != 0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
-                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
+                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT +
+                    romsize, rc);
             abort_transaction = 1;
             goto out;
         }
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..733f4c7 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -305,7 +305,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_domain_build_info *const info = &d_config->b_info;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *xs_domid, *con_domid;
-    int rc;
+    int rc, romsize;
 
     if (xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus) != 0) {
         LOG(ERROR, "Couldn't set max vcpu count");
@@ -405,8 +405,12 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         }
     }
 
+	rc = libxl__get_rom_memory_kb(gc, domid, d_config);
+	if (rc < 0)
+		return rc;
+	romsize = rc;
     if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
-        LIBXL_MAXMEM_CONSTANT) < 0) {
+        LIBXL_MAXMEM_CONSTANT + romsize) < 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't set max memory");
         return ERROR_FAIL;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..33826ea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -90,6 +90,7 @@
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
 #define LIBXL_MAXMEM_CONSTANT 1024
+#define LIBXL_ROMSIZE_KB 256
 #define LIBXL_PV_EXTRA_MEMORY 1024
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
@@ -1023,6 +1024,12 @@ _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
                                           uint32_t domid, const char *cmd);
 
+/* Returns the amount of extra mem required to allocate roms or an libxl
+ * error code on error.
+ * The *d_config parameter is optional.
+ */
+_hidden int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
+
 /* from xl_device */
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:09:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13: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 1XtFrU-0003m7-T9; Tue, 25 Nov 2014 13:08:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtFrT-0003m2-RZ
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 13:08:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EB/3F-09842-76F74745; Tue, 25 Nov 2014 13:08:55 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1416920933!11750996!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27741 invoked from network); 25 Nov 2014 13:08:54 -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;
	25 Nov 2014 13:08:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196129356"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 08:00:42 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtFSz-0000yC-VZ;
	Tue, 25 Nov 2014 12:43:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 25 Nov 2014 12:43:32 +0000
Message-ID: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	stefano.stabellini@eu.citrix.com, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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

Account for the extra memory needed for the rom files of any emulated nics:
QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
each them. Assume 256K each.

This patch fixes a QEMU abort() when more than 4 emulated nics are
assigned to a VM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Don Slutz <dslutz@verizon.com>
CC: hanyandong <hanyandong@iie.ac.cn>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>

---

Changes in v2:
- remove double return statement;
- check for return errors;
- check for overflows.
---
 tools/libxl/libxl.c          |   53 +++++++++++++++++++++++++++++++++++++-----
 tools/libxl/libxl_dom.c      |    8 +++++--
 tools/libxl/libxl_internal.h |    7 ++++++
 3 files changed, 60 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..2cdb768 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4527,13 +4527,40 @@ out:
 
 /******************************************************************************/
 
+int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
+{
+    int i, romsize, rc;
+    libxl_domain_config local_d_config;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    if (d_config == NULL) {
+        libxl_domain_config_init(&local_d_config);
+        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
+        if (rc < 0)
+            return rc;
+        d_config = &local_d_config;
+    }
+
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
+        return 0;
+
+    for (i = 0, romsize = 0;
+         i < d_config->num_nics && romsize < INT_MAX;
+         i++) {
+        if (d_config->nics[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU)
+            romsize += LIBXL_ROMSIZE_KB;
+    }
+
+    return romsize;
+}
+
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 {
     GC_INIT(ctx);
     char *mem, *endptr;
     uint32_t memorykb;
     char *dompath = libxl__xs_get_dompath(gc, domid);
-    int rc = 1;
+    int rc = 1, romsize;
 
     mem = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/memory/target", dompath));
     if (!mem) {
@@ -4550,11 +4577,18 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
         goto out;
     }
-    rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + LIBXL_MAXMEM_CONSTANT);
+    rc = libxl__get_rom_memory_kb(gc, domid, NULL);
+    if (rc < 0)
+        goto out;
+    romsize = rc;
+    rc = xc_domain_setmaxmem(ctx->xch, domid,
+                             max_memkb + LIBXL_MAXMEM_CONSTANT
+                             + romsize);
     if (rc != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "xc_domain_setmaxmem domid=%d memkb=%d failed "
-                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
+                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT +
+                romsize, rc);
         goto out;
     }
 
@@ -4683,7 +4717,7 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
         int32_t target_memkb, int relative, int enforce)
 {
     GC_INIT(ctx);
-    int rc = 1, abort_transaction = 0;
+    int rc = 1, abort_transaction = 0, romsize;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     uint32_t current_max_memkb = 0;
@@ -4769,12 +4803,19 @@ retry_transaction:
 
     if (enforce) {
         memorykb = new_target_memkb;
+        rc = libxl__get_rom_memory_kb(gc, domid, NULL);
+        if (rc < 0) {
+            abort_transaction = 1;
+            goto out;
+        }
+        romsize = rc;
         rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
-                LIBXL_MAXMEM_CONSTANT);
+                LIBXL_MAXMEM_CONSTANT + romsize);
         if (rc != 0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
-                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
+                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT +
+                    romsize, rc);
             abort_transaction = 1;
             goto out;
         }
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..733f4c7 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -305,7 +305,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_domain_build_info *const info = &d_config->b_info;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *xs_domid, *con_domid;
-    int rc;
+    int rc, romsize;
 
     if (xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus) != 0) {
         LOG(ERROR, "Couldn't set max vcpu count");
@@ -405,8 +405,12 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         }
     }
 
+	rc = libxl__get_rom_memory_kb(gc, domid, d_config);
+	if (rc < 0)
+		return rc;
+	romsize = rc;
     if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
-        LIBXL_MAXMEM_CONSTANT) < 0) {
+        LIBXL_MAXMEM_CONSTANT + romsize) < 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't set max memory");
         return ERROR_FAIL;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..33826ea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -90,6 +90,7 @@
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
 #define LIBXL_MAXMEM_CONSTANT 1024
+#define LIBXL_ROMSIZE_KB 256
 #define LIBXL_PV_EXTRA_MEMORY 1024
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
@@ -1023,6 +1024,12 @@ _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
                                           uint32_t domid, const char *cmd);
 
+/* Returns the amount of extra mem required to allocate roms or an libxl
+ * error code on error.
+ * The *d_config parameter is optional.
+ */
+_hidden int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
+
 /* from xl_device */
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:36:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGHr-0004B8-Io; Tue, 25 Nov 2014 13:36:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtGHq-0004B3-6X
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 13:36:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B1/34-09842-9C584745; Tue, 25 Nov 2014 13:36:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416922567!15172966!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14383 invoked from network); 25 Nov 2014 13:36:07 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 13:36:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 13:36:07 +0000
Message-Id: <547493D4020000780004AAF3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 13:36:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
> @@ -278,3 +290,139 @@ void vpmu_dump(struct vcpu *v)
>          vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
>  }
>  
> +static s_time_t vpmu_start_ctxt_switch;

Blank line here please.

> +static long vpmu_sched_checkin(void *arg)
> +{
> +    int cpu = cpumask_next(smp_processor_id(), &cpu_online_map);

unsigned int.

> +    int ret;
> +
> +    /* Mode change shouldn't take more than a few (say, 5) seconds. */
> +    if ( NOW() > vpmu_start_ctxt_switch + SECONDS(5) )
> +    {
> +        ret = -EBUSY;
> +        goto fail;
> +    }

So what does this guard against? Holding xenpmu_mode_lock for
5 seconds is not a problem, plus I don't think you actually need a
lock at all. Just using a global, atomically updated flag ought to be
sufficient (the way you use the lock is really nothing else afaict).

> +
> +    if ( cpu < nr_cpu_ids )
> +    {
> +        ret = continue_hypercall_on_cpu(cpu, vpmu_sched_checkin, arg);
> +        if ( ret )
> +            goto fail;
> +    }
> +    else
> +        vpmu_start_ctxt_switch = 0;
> +
> +    return 0;
> +
> + fail:
> +    vpmu_mode = (uint64_t)arg;

Even if we don't support x86-32 anymore, please avoid giving bad
examples: Casts between pointers and integers should always use
(unsigned) long on the integer side.

> +    vpmu_start_ctxt_switch = 0;
> +    return ret;
> +}
> +
> +static int vpmu_force_context_switch(uint64_t old_mode)

Same comment as above regarding the type.

> +{
> +    int ret;
> +
> +    vpmu_start_ctxt_switch = NOW();
> +
> +    ret = continue_hypercall_on_cpu(cpumask_first(&cpu_online_map),
> +                                    vpmu_sched_checkin, (void *)old_mode);
> +    if ( ret )
> +        vpmu_start_ctxt_switch = 0;
> +
> +    return ret;
> +}

I don't think it is guaranteed (independent of implementation details
of continue_hypercall_on_cpu()) that this way you went through the
context switch path once on each CPU if
cpumask_first(&cpu_online_map) == smp_processor_id() here. In
particular it looks like there being a problem calling vcpu_sleep_sync()
in the tasklet handler when v == current (which would be the case
if you started on the "correct" CPU and the tasklet softirq got
handled before the scheduler one). I think you instead want to use
cpumask_cycle() here and above, and finish the whole operation
once you're back on the CPU you started on (the single-pCPU case
may need some extra consideration).

I realize that you simply follow what microcode_update() does, but
I think we should rather correct that one than copy the latent issue
it has elsewhere.

> +long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
> +{
> +    int ret;
> +    struct xen_pmu_params pmu_params;
> +
> +    ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
> +    if ( ret )
> +        return ret;
> +
> +    switch ( op )
> +    {
> +    case XENPMU_mode_set:
> +    {
> +        uint64_t old_mode;

Irrespective of the earlier comments I don't see why this isn't just
unsigned int (or typeof(vpmu_mode)).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:36:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGHr-0004B8-Io; Tue, 25 Nov 2014 13:36:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtGHq-0004B3-6X
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 13:36:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B1/34-09842-9C584745; Tue, 25 Nov 2014 13:36:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1416922567!15172966!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14383 invoked from network); 25 Nov 2014 13:36:07 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 13:36:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 13:36:07 +0000
Message-Id: <547493D4020000780004AAF3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 13:36:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
> @@ -278,3 +290,139 @@ void vpmu_dump(struct vcpu *v)
>          vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
>  }
>  
> +static s_time_t vpmu_start_ctxt_switch;

Blank line here please.

> +static long vpmu_sched_checkin(void *arg)
> +{
> +    int cpu = cpumask_next(smp_processor_id(), &cpu_online_map);

unsigned int.

> +    int ret;
> +
> +    /* Mode change shouldn't take more than a few (say, 5) seconds. */
> +    if ( NOW() > vpmu_start_ctxt_switch + SECONDS(5) )
> +    {
> +        ret = -EBUSY;
> +        goto fail;
> +    }

So what does this guard against? Holding xenpmu_mode_lock for
5 seconds is not a problem, plus I don't think you actually need a
lock at all. Just using a global, atomically updated flag ought to be
sufficient (the way you use the lock is really nothing else afaict).

> +
> +    if ( cpu < nr_cpu_ids )
> +    {
> +        ret = continue_hypercall_on_cpu(cpu, vpmu_sched_checkin, arg);
> +        if ( ret )
> +            goto fail;
> +    }
> +    else
> +        vpmu_start_ctxt_switch = 0;
> +
> +    return 0;
> +
> + fail:
> +    vpmu_mode = (uint64_t)arg;

Even if we don't support x86-32 anymore, please avoid giving bad
examples: Casts between pointers and integers should always use
(unsigned) long on the integer side.

> +    vpmu_start_ctxt_switch = 0;
> +    return ret;
> +}
> +
> +static int vpmu_force_context_switch(uint64_t old_mode)

Same comment as above regarding the type.

> +{
> +    int ret;
> +
> +    vpmu_start_ctxt_switch = NOW();
> +
> +    ret = continue_hypercall_on_cpu(cpumask_first(&cpu_online_map),
> +                                    vpmu_sched_checkin, (void *)old_mode);
> +    if ( ret )
> +        vpmu_start_ctxt_switch = 0;
> +
> +    return ret;
> +}

I don't think it is guaranteed (independent of implementation details
of continue_hypercall_on_cpu()) that this way you went through the
context switch path once on each CPU if
cpumask_first(&cpu_online_map) == smp_processor_id() here. In
particular it looks like there being a problem calling vcpu_sleep_sync()
in the tasklet handler when v == current (which would be the case
if you started on the "correct" CPU and the tasklet softirq got
handled before the scheduler one). I think you instead want to use
cpumask_cycle() here and above, and finish the whole operation
once you're back on the CPU you started on (the single-pCPU case
may need some extra consideration).

I realize that you simply follow what microcode_update() does, but
I think we should rather correct that one than copy the latent issue
it has elsewhere.

> +long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
> +{
> +    int ret;
> +    struct xen_pmu_params pmu_params;
> +
> +    ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
> +    if ( ret )
> +        return ret;
> +
> +    switch ( op )
> +    {
> +    case XENPMU_mode_set:
> +    {
> +        uint64_t old_mode;

Irrespective of the earlier comments I don't see why this isn't just
unsigned int (or typeof(vpmu_mode)).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:49:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGUR-0004MT-Sd; Tue, 25 Nov 2014 13:49:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtGUQ-0004MO-Jq
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 13:49:10 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	71/D3-26652-5D884745; Tue, 25 Nov 2014 13:49:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416923349!7969416!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1666 invoked from network); 25 Nov 2014 13:49:09 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2014 13:49:09 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 13:49:08 +0000
Message-Id: <547496E0020000780004AB05@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 13:49:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
> @@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
>      switch ( vendor )
>      {
>      case X86_VENDOR_AMD:
> -        if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
> -            opt_vpmu_enabled = 0;
> +        if ( svm_vpmu_initialise(v) != 0 )
> +            vpmu_mode = XENPMU_MODE_OFF;
>          break;
>  
>      case X86_VENDOR_INTEL:
> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
> -            opt_vpmu_enabled = 0;
> +        if ( vmx_vpmu_initialise(v) != 0 )
> +            vpmu_mode = XENPMU_MODE_OFF;
>          break;

So this turns off the vPMU globally upon failure of initializing
some random vCPU. Why is that? I see this was the case even
before your entire series, but shouldn't this be fixed _before_
enhancing the whole thing to support PV/PVH?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:49:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGUR-0004MT-Sd; Tue, 25 Nov 2014 13:49:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtGUQ-0004MO-Jq
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 13:49:10 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	71/D3-26652-5D884745; Tue, 25 Nov 2014 13:49:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416923349!7969416!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1666 invoked from network); 25 Nov 2014 13:49:09 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2014 13:49:09 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 13:49:08 +0000
Message-Id: <547496E0020000780004AB05@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 13:49:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
> @@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
>      switch ( vendor )
>      {
>      case X86_VENDOR_AMD:
> -        if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
> -            opt_vpmu_enabled = 0;
> +        if ( svm_vpmu_initialise(v) != 0 )
> +            vpmu_mode = XENPMU_MODE_OFF;
>          break;
>  
>      case X86_VENDOR_INTEL:
> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
> -            opt_vpmu_enabled = 0;
> +        if ( vmx_vpmu_initialise(v) != 0 )
> +            vpmu_mode = XENPMU_MODE_OFF;
>          break;

So this turns off the vPMU globally upon failure of initializing
some random vCPU. Why is that? I see this was the case even
before your entire series, but shouldn't this be fixed _before_
enhancing the whole thing to support PV/PVH?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:51:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13:51:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGWq-0004Tq-Ko; Tue, 25 Nov 2014 13:51:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XtGWp-0004Tl-DV
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 13:51:39 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	8D/EC-14727-A6984745; Tue, 25 Nov 2014 13:51:38 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416923496!13283036!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32035 invoked from network); 25 Nov 2014 13:51:37 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-206.messagelabs.com with SMTP;
	25 Nov 2014 13:51:37 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 25 Nov 2014 05:51:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,455,1413270000"; d="scan'208";a="627978965"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by fmsmga001.fm.intel.com with ESMTP; 25 Nov 2014 05:51:33 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 25 Nov 2014 21:51:32 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Tue, 25 Nov 2014 21:51:25 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Eric Blake <eblake@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
	Xen stubdom vTPM command line options
Thread-Index: AQHQCArFXtNvJVE17EuNR1tsww9REpxvgrqAgAHZizA=
Date: Tue, 25 Nov 2014 13:51:24 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8416DC@SHSMSX101.ccr.corp.intel.com>
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
	<54736893.6060802@redhat.com> <54736B69.1050408@redhat.com>
In-Reply-To: <54736B69.1050408@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "lcapitulino@redhat.com" <lcapitulino@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Eric Blake
> Sent: Tuesday, November 25, 2014 1:31 AM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: xen-devel@lists.xen.org; armbru@redhat.com; lcapitulino@redhat.com
> Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
> Xen stubdom vTPM command line options
> 
> On 11/24/2014 10:19 AM, Eric Blake wrote:
> > On 11/23/2014 09:10 PM, Quan Xu wrote:
> >> Signed-off-by: Quan Xu <quan.xu@intel.com>
> >> ---
> >>  configure        | 14 ++++++++++++++
> >>  hmp.c            |  7 +++++++
> >>  qapi-schema.json | 20 ++++++++++++++++++--  qemu-options.hx  |
> 13
> >> +++++++++++--
> >>  tpm.c            |  7 ++++++-
> >>  5 files changed, 56 insertions(+), 5 deletions(-)
> 
> Also, this message was not threaded properly; it appeared as a top-level
> thread along with three other threads for its siblings, instead of all four
> patches being in-reply-to the 0/4 cover letter.
> 
Thanks Eric.

Should I: 

V2 is version number, 
1. $git format-patch --subject-prefix=v2 -ns --cover-letter master 
  Then, edit 0000-cover-letter.patch 

2. $git format-patch --subject-prefix=v2 -4 
  Then, commit these 4 patch and 0000-cover-letter.patch

right?


Thanks 
Quan Xu

> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:51:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13:51:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGWq-0004Tq-Ko; Tue, 25 Nov 2014 13:51:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XtGWp-0004Tl-DV
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 13:51:39 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	8D/EC-14727-A6984745; Tue, 25 Nov 2014 13:51:38 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416923496!13283036!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32035 invoked from network); 25 Nov 2014 13:51:37 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-206.messagelabs.com with SMTP;
	25 Nov 2014 13:51:37 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 25 Nov 2014 05:51:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,455,1413270000"; d="scan'208";a="627978965"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by fmsmga001.fm.intel.com with ESMTP; 25 Nov 2014 05:51:33 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 25 Nov 2014 21:51:32 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Tue, 25 Nov 2014 21:51:25 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Eric Blake <eblake@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
	Xen stubdom vTPM command line options
Thread-Index: AQHQCArFXtNvJVE17EuNR1tsww9REpxvgrqAgAHZizA=
Date: Tue, 25 Nov 2014 13:51:24 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8416DC@SHSMSX101.ccr.corp.intel.com>
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
	<54736893.6060802@redhat.com> <54736B69.1050408@redhat.com>
In-Reply-To: <54736B69.1050408@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "lcapitulino@redhat.com" <lcapitulino@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Eric Blake
> Sent: Tuesday, November 25, 2014 1:31 AM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: xen-devel@lists.xen.org; armbru@redhat.com; lcapitulino@redhat.com
> Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
> Xen stubdom vTPM command line options
> 
> On 11/24/2014 10:19 AM, Eric Blake wrote:
> > On 11/23/2014 09:10 PM, Quan Xu wrote:
> >> Signed-off-by: Quan Xu <quan.xu@intel.com>
> >> ---
> >>  configure        | 14 ++++++++++++++
> >>  hmp.c            |  7 +++++++
> >>  qapi-schema.json | 20 ++++++++++++++++++--  qemu-options.hx  |
> 13
> >> +++++++++++--
> >>  tpm.c            |  7 ++++++-
> >>  5 files changed, 56 insertions(+), 5 deletions(-)
> 
> Also, this message was not threaded properly; it appeared as a top-level
> thread along with three other threads for its siblings, instead of all four
> patches being in-reply-to the 0/4 cover letter.
> 
Thanks Eric.

Should I: 

V2 is version number, 
1. $git format-patch --subject-prefix=v2 -ns --cover-letter master 
  Then, edit 0000-cover-letter.patch 

2. $git format-patch --subject-prefix=v2 -4 
  Then, commit these 4 patch and 0000-cover-letter.patch

right?


Thanks 
Quan Xu

> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:52:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGY0-0004cP-2z; Tue, 25 Nov 2014 13:52:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XtGXz-0004cI-8S
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 13:52:51 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	86/DF-02953-2B984745; Tue, 25 Nov 2014 13:52:50 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416923569!14728774!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29414 invoked from network); 25 Nov 2014 13:52:49 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-27.messagelabs.com with SMTP;
	25 Nov 2014 13:52:49 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 25 Nov 2014 05:52:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,455,1413270000"; d="scan'208";a="643213437"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by orsmga002.jf.intel.com with ESMTP; 25 Nov 2014 05:52:33 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 25 Nov 2014 21:52:32 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id
	14.03.0195.001; Tue, 25 Nov 2014 21:52:31 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Eric Blake <eblake@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [v2 1/4] Qemu-Xen-vTPM: Support for Xen stubdom vTPM command
	line options
Thread-Index: AQHQCArFXtNvJVE17EuNR1tsww9REpxxXcXQ
Date: Tue, 25 Nov 2014 13:52:30 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8416F7@SHSMSX101.ccr.corp.intel.com>
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
	<54736893.6060802@redhat.com>
In-Reply-To: <54736893.6060802@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "lcapitulino@redhat.com" <lcapitulino@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v2 1/4] Qemu-Xen-vTPM: Support for Xen stubdom
 vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Eric Blake [mailto:eblake@redhat.com]
> Sent: Tuesday, November 25, 2014 1:19 AM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: xen-devel@lists.xen.org; lcapitulino@redhat.com; armbru@redhat.com
> Subject: Re: [v2 1/4] Qemu-Xen-vTPM: Support for Xen stubdom vTPM
> command line options
> 
> On 11/23/2014 09:10 PM, Quan Xu wrote:
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > ---
> >  configure        | 14 ++++++++++++++
> >  hmp.c            |  7 +++++++
> >  qapi-schema.json | 20 ++++++++++++++++++--  qemu-options.hx  | 13
> > +++++++++++--
> >  tpm.c            |  7 ++++++-
> >  5 files changed, 56 insertions(+), 5 deletions(-)
> >
> 
> > +++ b/qapi-schema.json
> > @@ -2855,8 +2855,12 @@
> >  # @passthrough: TPM passthrough type
> >  #
> >  # Since: 1.5
> > +#
> > +# @xenstubdoms: TPM xenstubdoms type
> > +#
> > +# Since: 2.3
> 
> Typically, this would be done as:
> 
> # @passthrough: TPM passthrough type
> #
> # @xenstubdoms: TPM xenstubdoms type (since 2.3) # # Since: 1.5
> 

Thanks  Eric. 
I will modify it as your suggestion in v3.

> as the enum itself was added in 1.5, not 2.3.
> 
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:52:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGY0-0004cP-2z; Tue, 25 Nov 2014 13:52:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XtGXz-0004cI-8S
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 13:52:51 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	86/DF-02953-2B984745; Tue, 25 Nov 2014 13:52:50 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416923569!14728774!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29414 invoked from network); 25 Nov 2014 13:52:49 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-27.messagelabs.com with SMTP;
	25 Nov 2014 13:52:49 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 25 Nov 2014 05:52:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,455,1413270000"; d="scan'208";a="643213437"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by orsmga002.jf.intel.com with ESMTP; 25 Nov 2014 05:52:33 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 25 Nov 2014 21:52:32 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id
	14.03.0195.001; Tue, 25 Nov 2014 21:52:31 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Eric Blake <eblake@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [v2 1/4] Qemu-Xen-vTPM: Support for Xen stubdom vTPM command
	line options
Thread-Index: AQHQCArFXtNvJVE17EuNR1tsww9REpxxXcXQ
Date: Tue, 25 Nov 2014 13:52:30 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8416F7@SHSMSX101.ccr.corp.intel.com>
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
	<54736893.6060802@redhat.com>
In-Reply-To: <54736893.6060802@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "lcapitulino@redhat.com" <lcapitulino@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v2 1/4] Qemu-Xen-vTPM: Support for Xen stubdom
 vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Eric Blake [mailto:eblake@redhat.com]
> Sent: Tuesday, November 25, 2014 1:19 AM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: xen-devel@lists.xen.org; lcapitulino@redhat.com; armbru@redhat.com
> Subject: Re: [v2 1/4] Qemu-Xen-vTPM: Support for Xen stubdom vTPM
> command line options
> 
> On 11/23/2014 09:10 PM, Quan Xu wrote:
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > ---
> >  configure        | 14 ++++++++++++++
> >  hmp.c            |  7 +++++++
> >  qapi-schema.json | 20 ++++++++++++++++++--  qemu-options.hx  | 13
> > +++++++++++--
> >  tpm.c            |  7 ++++++-
> >  5 files changed, 56 insertions(+), 5 deletions(-)
> >
> 
> > +++ b/qapi-schema.json
> > @@ -2855,8 +2855,12 @@
> >  # @passthrough: TPM passthrough type
> >  #
> >  # Since: 1.5
> > +#
> > +# @xenstubdoms: TPM xenstubdoms type
> > +#
> > +# Since: 2.3
> 
> Typically, this would be done as:
> 
> # @passthrough: TPM passthrough type
> #
> # @xenstubdoms: TPM xenstubdoms type (since 2.3) # # Since: 1.5
> 

Thanks  Eric. 
I will modify it as your suggestion in v3.

> as the enum itself was added in 1.5, not 2.3.
> 
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:53:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13:53:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGYq-0004hl-Ga; Tue, 25 Nov 2014 13:53:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtGYp-0004ha-Lt
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 13:53:43 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	CF/5F-02707-6E984745; Tue, 25 Nov 2014 13:53:42 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416923618!13283553!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13697 invoked from network); 25 Nov 2014 13:53:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 13:53:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196548943"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 08:53:41 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtGYm-0002Uw-VW;
	Tue, 25 Nov 2014 13:53:40 +0000
Date: Tue, 25 Nov 2014 13:53:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jason Wang <jasowang@redhat.com>
In-Reply-To: <54741ED7.2060500@redhat.com>
Message-ID: <alpine.DEB.2.02.1411251249380.2675@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
	<54741ED7.2060500@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Jason Wang wrote:
> On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> >> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> >>> CC'ing Paolo.
> >>>
> >>>
> >>> Wen,
> >>> thanks for the logs.
> >>>
> >>> I investigated a little bit and it seems to me that the bug occurs when
> >>> QEMU tries to unmap only a portion of a memory region previously mapped.
> >>> That doesn't work with xen-mapcache.
> >>>
> >>> See these logs for example:
> >>>
> >>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> >>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> >> Sorry the logs don't quite match, it was supposed to be:
> >>
> >> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
> >> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> > It looks like the problem is caused by iov_discard_front, called by
> > virtio_net_handle_ctrl. By changing iov_base after the sg has already
> > been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> > because the corresponding cpu_physical_memory_unmap will only unmap a
> > portion of the original sg.  On Xen the problem is worse because
> > xen-mapcache aborts.
> >
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 2ac6ce5..b2b5c2d 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >      struct iovec *iov;
> >      unsigned int iov_cnt;
> >  
> > -    while (virtqueue_pop(vq, &elem)) {
> > +    while (virtqueue_pop_nomap(vq, &elem)) {
> >          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
> >              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
> >              error_report("virtio-net ctrl missing headers");
> > @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >  
> >          iov = elem.out_sg;
> >          iov_cnt = elem.out_num;
> > -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> >          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> > +
> > +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> > +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> > +
> > +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> 
> Does this really work?

It seems to work here, as in it doesn't crash QEMU and I am able to boot
a guest with network. I didn't try any MAC related commands.


> The code in fact skips the location that contains
> virtio_net_ctrl_hdr. And virtio_net_handle_mac() still calls
> iov_discard_front().
>
> How about copy iov to a temp variable and use it in this function?

That would only work if I moved the cpu_physical_memory_unmap call
outside of virtqueue_fill, so that we can pass different iov to them.
We need to unmap the same iov that was previously mapped by
virtqueue_pop.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 13:53:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 13:53:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGYq-0004hl-Ga; Tue, 25 Nov 2014 13:53:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtGYp-0004ha-Lt
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 13:53:43 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	CF/5F-02707-6E984745; Tue, 25 Nov 2014 13:53:42 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416923618!13283553!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13697 invoked from network); 25 Nov 2014 13:53:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 13:53:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196548943"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 08:53:41 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtGYm-0002Uw-VW;
	Tue, 25 Nov 2014 13:53:40 +0000
Date: Tue, 25 Nov 2014 13:53:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jason Wang <jasowang@redhat.com>
In-Reply-To: <54741ED7.2060500@redhat.com>
Message-ID: <alpine.DEB.2.02.1411251249380.2675@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
	<54741ED7.2060500@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Jason Wang wrote:
> On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> >> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> >>> CC'ing Paolo.
> >>>
> >>>
> >>> Wen,
> >>> thanks for the logs.
> >>>
> >>> I investigated a little bit and it seems to me that the bug occurs when
> >>> QEMU tries to unmap only a portion of a memory region previously mapped.
> >>> That doesn't work with xen-mapcache.
> >>>
> >>> See these logs for example:
> >>>
> >>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> >>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> >> Sorry the logs don't quite match, it was supposed to be:
> >>
> >> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
> >> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> > It looks like the problem is caused by iov_discard_front, called by
> > virtio_net_handle_ctrl. By changing iov_base after the sg has already
> > been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> > because the corresponding cpu_physical_memory_unmap will only unmap a
> > portion of the original sg.  On Xen the problem is worse because
> > xen-mapcache aborts.
> >
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 2ac6ce5..b2b5c2d 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >      struct iovec *iov;
> >      unsigned int iov_cnt;
> >  
> > -    while (virtqueue_pop(vq, &elem)) {
> > +    while (virtqueue_pop_nomap(vq, &elem)) {
> >          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
> >              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
> >              error_report("virtio-net ctrl missing headers");
> > @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >  
> >          iov = elem.out_sg;
> >          iov_cnt = elem.out_num;
> > -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> >          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> > +
> > +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> > +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> > +
> > +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> 
> Does this really work?

It seems to work here, as in it doesn't crash QEMU and I am able to boot
a guest with network. I didn't try any MAC related commands.


> The code in fact skips the location that contains
> virtio_net_ctrl_hdr. And virtio_net_handle_mac() still calls
> iov_discard_front().
>
> How about copy iov to a temp variable and use it in this function?

That would only work if I moved the cpu_physical_memory_unmap call
outside of virtqueue_fill, so that we can pass different iov to them.
We need to unmap the same iov that was previously mapped by
virtqueue_pop.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:04:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:04:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGih-00053O-LN; Tue, 25 Nov 2014 14:03:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtGif-00053J-RW
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:03:53 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	39/37-02954-94C84745; Tue, 25 Nov 2014 14:03:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416924232!14732892!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25156 invoked from network); 25 Nov 2014 14:03:52 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:03:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 14:03:52 +0000
Message-Id: <54749A55020000780004AB2C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 14:03:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-14-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416179271-1221-14-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 13/21] x86/VPMU: Initialize PMU for
 PV(H) 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 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> @@ -362,24 +362,34 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
>      struct xen_pmu_intel_ctxt *core2_vpmu_cxt = NULL;
>      uint64_t *p = NULL;
>  
> -    if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
> -        return 0;
> -
> -    wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
> -    if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
> +    p = xzalloc_bytes(sizeof(uint64_t));

xzalloc(uint64_t)?

> +    if ( !p )
>          goto out_err;
>  
> -    if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
> -        goto out_err;
> -    vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
> -
> -    core2_vpmu_cxt = xzalloc_bytes(sizeof(*core2_vpmu_cxt) +
> -                                   sizeof(uint64_t) * fixed_pmc_cnt +
> -                                   sizeof(struct xen_pmu_cntr_pair) *
> -                                   arch_pmc_cnt);
> -    p = xzalloc(uint64_t);

At least it was that way before...

With that fixed, feel free to add
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:04:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:04:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGih-00053O-LN; Tue, 25 Nov 2014 14:03:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtGif-00053J-RW
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:03:53 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	39/37-02954-94C84745; Tue, 25 Nov 2014 14:03:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416924232!14732892!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25156 invoked from network); 25 Nov 2014 14:03:52 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:03:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 14:03:52 +0000
Message-Id: <54749A55020000780004AB2C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 14:03:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-14-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416179271-1221-14-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 13/21] x86/VPMU: Initialize PMU for
 PV(H) 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 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> @@ -362,24 +362,34 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
>      struct xen_pmu_intel_ctxt *core2_vpmu_cxt = NULL;
>      uint64_t *p = NULL;
>  
> -    if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
> -        return 0;
> -
> -    wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
> -    if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
> +    p = xzalloc_bytes(sizeof(uint64_t));

xzalloc(uint64_t)?

> +    if ( !p )
>          goto out_err;
>  
> -    if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
> -        goto out_err;
> -    vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
> -
> -    core2_vpmu_cxt = xzalloc_bytes(sizeof(*core2_vpmu_cxt) +
> -                                   sizeof(uint64_t) * fixed_pmc_cnt +
> -                                   sizeof(struct xen_pmu_cntr_pair) *
> -                                   arch_pmc_cnt);
> -    p = xzalloc(uint64_t);

At least it was that way before...

With that fixed, feel free to add
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:11:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGqH-0005Bm-JO; Tue, 25 Nov 2014 14:11:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtGqF-0005Bd-Qp
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 14:11:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	16/6E-09842-F1E84745; Tue, 25 Nov 2014 14:11:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416924702!15235679!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32243 invoked from network); 25 Nov 2014 14:11:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:11:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 14:11:42 +0000
Message-Id: <54749C2B020000780004AB42@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 14:11:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <547485D8020000780004AA76@mail.emea.novell.com>
In-Reply-To: <547485D8020000780004AA76@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: [Xen-devel] [PATCH] vNUMA: rename interface 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

>>> On 25.11.14 at 13:36, <JBeulich@suse.com> wrote:
> No-one (including me) paid attention during review that these
> structures don't adhere to the naming requirements of the public
> interface: Consistently use xen_ prefixes at least for all new
> additions.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Sorry, again forgot to Cc you (for 4.5): No functional change, but
avoiding a later (incompatible) interface change.

Jan

> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface *xch
>                          uint32_t nr_vnodes,
>                          uint32_t nr_regions,
>                          uint32_t nr_vcpus,
> -                        vmemrange_t *vmemrange,
> +                        xen_vmemrange_t *vmemrange,
>                          unsigned int *vdistance,
>                          unsigned int *vcpu_to_vnode,
>                          unsigned int *vnode_to_pnode);
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -2171,7 +2171,7 @@ int xc_domain_setvnuma(xc_interface *xch
>                         uint32_t nr_vnodes,
>                         uint32_t nr_vmemranges,
>                         uint32_t nr_vcpus,
> -                       vmemrange_t *vmemrange,
> +                       xen_vmemrange_t *vmemrange,
>                         unsigned int *vdistance,
>                         unsigned int *vcpu_to_vnode,
>                         unsigned int *vnode_to_pnode)
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un
>      vnuma->vdistance = xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);
>      vnuma->vcpu_to_vnode = xmalloc_array(unsigned int, nr_vcpus);
>      vnuma->vnode_to_pnode = xmalloc_array(unsigned int, nr_vnodes);
> -    vnuma->vmemrange = xmalloc_array(vmemrange_t, nr_ranges);
> +    vnuma->vmemrange = xmalloc_array(xen_vmemrange_t, nr_ranges);
>  
>      if ( vnuma->vdistance == NULL || vnuma->vmemrange == NULL ||
>           vnuma->vcpu_to_vnode == NULL || vnuma->vnode_to_pnode == NULL )
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -972,7 +972,7 @@ long do_memory_op(unsigned long cmd, XEN
>  
>      case XENMEM_get_vnumainfo:
>      {
> -        struct vnuma_topology_info topology;
> +        struct xen_vnuma_topology_info topology;
>          struct domain *d;
>          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
>          struct vnuma_info tmp;
> @@ -1033,7 +1033,7 @@ long do_memory_op(unsigned long cmd, XEN
>          read_unlock(&d->vnuma_rwlock);
>  
>          tmp.vdistance = xmalloc_array(unsigned int, dom_vnodes * 
> dom_vnodes);
> -        tmp.vmemrange = xmalloc_array(vmemrange_t, dom_vranges);
> +        tmp.vmemrange = xmalloc_array(xen_vmemrange_t, dom_vranges);
>          tmp.vcpu_to_vnode = xmalloc_array(unsigned int, dom_vcpus);
>  
>          if ( tmp.vdistance == NULL ||
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -980,7 +980,7 @@ struct xen_domctl_vnuma {
>      /*
>       * memory rages for each vNUMA node
>       */
> -    XEN_GUEST_HANDLE_64(vmemrange_t) vmemrange;
> +    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
>  };
>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_
>  #define XENMEM_get_vnumainfo                26
>  
>  /* vNUMA node memory ranges */
> -struct vmemrange {
> +struct xen_vmemrange {
>      uint64_t start, end;
>      unsigned int flags;
>      unsigned int nid;
>  };
> -
> -typedef struct vmemrange vmemrange_t;
> -DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
> +typedef struct xen_vmemrange xen_vmemrange_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
>  
>  /*
>   * vNUMA topology specifies vNUMA node number, distance table,
> @@ -548,7 +547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
>   * copied back to guest. Domain returns expected values of nr_vnodes,
>   * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
>   */
> -struct vnuma_topology_info {
> +struct xen_vnuma_topology_info {
>      /* IN */
>      domid_t domid;
>      uint16_t pad;
> @@ -566,12 +565,12 @@ struct vnuma_topology_info {
>          uint64_t pad;
>      } vcpu_to_vnode;
>      union {
> -        XEN_GUEST_HANDLE(vmemrange_t) h;
> +        XEN_GUEST_HANDLE(xen_vmemrange_t) h;
>          uint64_t pad;
>      } vmemrange;
>  };
> -typedef struct vnuma_topology_info vnuma_topology_info_t;
> -DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);
> +typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
>  
>  /* Next available subop number is 27 */
>  
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -100,7 +100,7 @@ struct vnuma_info {
>      unsigned int *vdistance;
>      unsigned int *vcpu_to_vnode;
>      unsigned int *vnode_to_pnode;
> -    struct vmemrange *vmemrange;
> +    struct xen_vmemrange *vmemrange;
>  };
>  
>  void vnuma_destroy(struct vnuma_info *vnuma);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:11:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtGqH-0005Bm-JO; Tue, 25 Nov 2014 14:11:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtGqF-0005Bd-Qp
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 14:11:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	16/6E-09842-F1E84745; Tue, 25 Nov 2014 14:11:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416924702!15235679!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32243 invoked from network); 25 Nov 2014 14:11:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:11:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 14:11:42 +0000
Message-Id: <54749C2B020000780004AB42@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 14:11:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <547485D8020000780004AA76@mail.emea.novell.com>
In-Reply-To: <547485D8020000780004AA76@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: [Xen-devel] [PATCH] vNUMA: rename interface 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

>>> On 25.11.14 at 13:36, <JBeulich@suse.com> wrote:
> No-one (including me) paid attention during review that these
> structures don't adhere to the naming requirements of the public
> interface: Consistently use xen_ prefixes at least for all new
> additions.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Sorry, again forgot to Cc you (for 4.5): No functional change, but
avoiding a later (incompatible) interface change.

Jan

> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface *xch
>                          uint32_t nr_vnodes,
>                          uint32_t nr_regions,
>                          uint32_t nr_vcpus,
> -                        vmemrange_t *vmemrange,
> +                        xen_vmemrange_t *vmemrange,
>                          unsigned int *vdistance,
>                          unsigned int *vcpu_to_vnode,
>                          unsigned int *vnode_to_pnode);
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -2171,7 +2171,7 @@ int xc_domain_setvnuma(xc_interface *xch
>                         uint32_t nr_vnodes,
>                         uint32_t nr_vmemranges,
>                         uint32_t nr_vcpus,
> -                       vmemrange_t *vmemrange,
> +                       xen_vmemrange_t *vmemrange,
>                         unsigned int *vdistance,
>                         unsigned int *vcpu_to_vnode,
>                         unsigned int *vnode_to_pnode)
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un
>      vnuma->vdistance = xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);
>      vnuma->vcpu_to_vnode = xmalloc_array(unsigned int, nr_vcpus);
>      vnuma->vnode_to_pnode = xmalloc_array(unsigned int, nr_vnodes);
> -    vnuma->vmemrange = xmalloc_array(vmemrange_t, nr_ranges);
> +    vnuma->vmemrange = xmalloc_array(xen_vmemrange_t, nr_ranges);
>  
>      if ( vnuma->vdistance == NULL || vnuma->vmemrange == NULL ||
>           vnuma->vcpu_to_vnode == NULL || vnuma->vnode_to_pnode == NULL )
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -972,7 +972,7 @@ long do_memory_op(unsigned long cmd, XEN
>  
>      case XENMEM_get_vnumainfo:
>      {
> -        struct vnuma_topology_info topology;
> +        struct xen_vnuma_topology_info topology;
>          struct domain *d;
>          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
>          struct vnuma_info tmp;
> @@ -1033,7 +1033,7 @@ long do_memory_op(unsigned long cmd, XEN
>          read_unlock(&d->vnuma_rwlock);
>  
>          tmp.vdistance = xmalloc_array(unsigned int, dom_vnodes * 
> dom_vnodes);
> -        tmp.vmemrange = xmalloc_array(vmemrange_t, dom_vranges);
> +        tmp.vmemrange = xmalloc_array(xen_vmemrange_t, dom_vranges);
>          tmp.vcpu_to_vnode = xmalloc_array(unsigned int, dom_vcpus);
>  
>          if ( tmp.vdistance == NULL ||
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -980,7 +980,7 @@ struct xen_domctl_vnuma {
>      /*
>       * memory rages for each vNUMA node
>       */
> -    XEN_GUEST_HANDLE_64(vmemrange_t) vmemrange;
> +    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
>  };
>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_
>  #define XENMEM_get_vnumainfo                26
>  
>  /* vNUMA node memory ranges */
> -struct vmemrange {
> +struct xen_vmemrange {
>      uint64_t start, end;
>      unsigned int flags;
>      unsigned int nid;
>  };
> -
> -typedef struct vmemrange vmemrange_t;
> -DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
> +typedef struct xen_vmemrange xen_vmemrange_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
>  
>  /*
>   * vNUMA topology specifies vNUMA node number, distance table,
> @@ -548,7 +547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
>   * copied back to guest. Domain returns expected values of nr_vnodes,
>   * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
>   */
> -struct vnuma_topology_info {
> +struct xen_vnuma_topology_info {
>      /* IN */
>      domid_t domid;
>      uint16_t pad;
> @@ -566,12 +565,12 @@ struct vnuma_topology_info {
>          uint64_t pad;
>      } vcpu_to_vnode;
>      union {
> -        XEN_GUEST_HANDLE(vmemrange_t) h;
> +        XEN_GUEST_HANDLE(xen_vmemrange_t) h;
>          uint64_t pad;
>      } vmemrange;
>  };
> -typedef struct vnuma_topology_info vnuma_topology_info_t;
> -DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);
> +typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
>  
>  /* Next available subop number is 27 */
>  
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -100,7 +100,7 @@ struct vnuma_info {
>      unsigned int *vdistance;
>      unsigned int *vcpu_to_vnode;
>      unsigned int *vnode_to_pnode;
> -    struct vmemrange *vmemrange;
> +    struct xen_vmemrange *vmemrange;
>  };
>  
>  void vnuma_destroy(struct vnuma_info *vnuma);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14: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 1XtGt9-0005Kk-5X; Tue, 25 Nov 2014 14:14: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 1XtGt8-0005Ke-4c
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:14:42 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	84/91-22819-1DE84745; Tue, 25 Nov 2014 14:14:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416924877!7976490!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23738 invoked from network); 25 Nov 2014 14:14:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:14:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196558510"
Message-ID: <1416924878.32327.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 25 Nov 2014 14:14:38 +0000
In-Reply-To: <546F3EDD.3020006@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416499238.14429.39.camel@citrix.com> <546E1206.5080403@citrix.com>
	<1416500123.20161.3.camel@citrix.com> <546E1ABB.6090308@oracle.com>
	<546F3EDD.3020006@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 13:32 +0000, Andrew Cooper wrote:
> On 20/11/14 16:45, Boris Ostrovsky wrote:
> > On 11/20/2014 11:15 AM, Ian Campbell wrote:
> >> On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
> >>> On 20/11/14 16:00, Ian Campbell wrote:
> >>>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
> >>>>> c/s d1b93ea causes substantial functional regressions in pygrub's
> >>>>> ability to
> >>>>> parse bootloader configuration files.
> >>>>>
> >>>>> c/s d1b93ea itself changed an an interface which previously used
> >>>>> exclusively
> >>>>> integers, to using strings in the case of a grub configuration
> >>>>> with explicit
> >>>>> default set, along with changing the code calling the interface to
> >>>>> require a
> >>>>> string.  The default value for "default" remained as an integer.
> >>>>>
> >>>>> As a result, any Extlinux or Lilo configuration (which drives this
> >>>>> interface
> >>>>> exclusively with integers), or Grub configuration which doesn't
> >>>>> explicitly
> >>>>> declare a default will die with an AttributeError when attempting
> >>>>> to call
> >>>>> "self.cf.default.isdigit()" where "default" is an integer.
> >>>>>
> >>>>> Sadly, this AttributeError gets swallowed by the blanket ignore in
> >>>>> the loop
> >>>>> which searches partitions for valid bootloader configurations,
> >>>>> causing the
> >>>>> issue to be reported as "Unable to find partition containing kernel"
> >>>>>
> >>>>> This patch attempts to fix the issue by altering all parts of this
> >>>>> interface
> >>>>> to use strings, as opposed to integers.
> >>>> Would it be less invasive at this point in the release to have the
> >>>> place
> >>>> where this stuff is used do isinstance(s, str) and isinstance(s, int)?
> >>> It would be BaseString not str, but I am fairly sure the classes have
> >>> altered through Py2's history.  I would not be any more confident with
> >>> that as a solution as trying to correctly to start with.
> >> Actually isinstance(s, basestring) is what the webpage I was looking at
> >> said, but I cut-n-pasted the wrong thing.
> >>
> >> But regardless could it not do something like:
> >>     if !isinstance(foo.cf.default, int):
> >
> > I think it would be the other way around, e.g. (not tested):
> >
> > diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> > index aa7e562..7250f45 100644
> > --- a/tools/pygrub/src/pygrub
> > +++ b/tools/pygrub/src/pygrub
> > @@ -457,7 +457,9 @@ class Grub:
> >          self.cf.parse(buf)
> >
> >      def image_index(self):
> > -        if self.cf.default.isdigit():
> > +        if isinstance(self.cf.default, int)
> > +            sel = self.cf.default
> > +        elif if self.cf.default.isdigit():
> >              sel = int(self.cf.default)
> >          else:
> >              # We don't fully support submenus. Look for the leaf
> > value in
> >
> > but yes, this looks less intrusive (assuming this the only place where
> > we'd hit this error).
> >
> 
> That does look plausibly like it would fix the issue.

Is someone going to resubmit a patch along these lines then?

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14: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 1XtGt9-0005Kk-5X; Tue, 25 Nov 2014 14:14: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 1XtGt8-0005Ke-4c
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:14:42 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	84/91-22819-1DE84745; Tue, 25 Nov 2014 14:14:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416924877!7976490!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23738 invoked from network); 25 Nov 2014 14:14:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:14:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196558510"
Message-ID: <1416924878.32327.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 25 Nov 2014 14:14:38 +0000
In-Reply-To: <546F3EDD.3020006@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>
	<1416499238.14429.39.camel@citrix.com> <546E1206.5080403@citrix.com>
	<1416500123.20161.3.camel@citrix.com> <546E1ABB.6090308@oracle.com>
	<546F3EDD.3020006@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 13:32 +0000, Andrew Cooper wrote:
> On 20/11/14 16:45, Boris Ostrovsky wrote:
> > On 11/20/2014 11:15 AM, Ian Campbell wrote:
> >> On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
> >>> On 20/11/14 16:00, Ian Campbell wrote:
> >>>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
> >>>>> c/s d1b93ea causes substantial functional regressions in pygrub's
> >>>>> ability to
> >>>>> parse bootloader configuration files.
> >>>>>
> >>>>> c/s d1b93ea itself changed an an interface which previously used
> >>>>> exclusively
> >>>>> integers, to using strings in the case of a grub configuration
> >>>>> with explicit
> >>>>> default set, along with changing the code calling the interface to
> >>>>> require a
> >>>>> string.  The default value for "default" remained as an integer.
> >>>>>
> >>>>> As a result, any Extlinux or Lilo configuration (which drives this
> >>>>> interface
> >>>>> exclusively with integers), or Grub configuration which doesn't
> >>>>> explicitly
> >>>>> declare a default will die with an AttributeError when attempting
> >>>>> to call
> >>>>> "self.cf.default.isdigit()" where "default" is an integer.
> >>>>>
> >>>>> Sadly, this AttributeError gets swallowed by the blanket ignore in
> >>>>> the loop
> >>>>> which searches partitions for valid bootloader configurations,
> >>>>> causing the
> >>>>> issue to be reported as "Unable to find partition containing kernel"
> >>>>>
> >>>>> This patch attempts to fix the issue by altering all parts of this
> >>>>> interface
> >>>>> to use strings, as opposed to integers.
> >>>> Would it be less invasive at this point in the release to have the
> >>>> place
> >>>> where this stuff is used do isinstance(s, str) and isinstance(s, int)?
> >>> It would be BaseString not str, but I am fairly sure the classes have
> >>> altered through Py2's history.  I would not be any more confident with
> >>> that as a solution as trying to correctly to start with.
> >> Actually isinstance(s, basestring) is what the webpage I was looking at
> >> said, but I cut-n-pasted the wrong thing.
> >>
> >> But regardless could it not do something like:
> >>     if !isinstance(foo.cf.default, int):
> >
> > I think it would be the other way around, e.g. (not tested):
> >
> > diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> > index aa7e562..7250f45 100644
> > --- a/tools/pygrub/src/pygrub
> > +++ b/tools/pygrub/src/pygrub
> > @@ -457,7 +457,9 @@ class Grub:
> >          self.cf.parse(buf)
> >
> >      def image_index(self):
> > -        if self.cf.default.isdigit():
> > +        if isinstance(self.cf.default, int)
> > +            sel = self.cf.default
> > +        elif if self.cf.default.isdigit():
> >              sel = int(self.cf.default)
> >          else:
> >              # We don't fully support submenus. Look for the leaf
> > value in
> >
> > but yes, this looks less intrusive (assuming this the only place where
> > we'd hit this error).
> >
> 
> That does look plausibly like it would fix the issue.

Is someone going to resubmit a patch along these lines then?

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:25:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtH2t-0005Za-G0; Tue, 25 Nov 2014 14:24:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtH2s-0005ZV-HN
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:24:46 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	58/9D-02699-D2194745; Tue, 25 Nov 2014 14:24:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416925482!10114439!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19778 invoked from network); 25 Nov 2014 14:24:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:24:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196169626"
Message-ID: <1416924781.32327.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 25 Nov 2014 14:13:01 +0000
In-Reply-To: <20141121170103.GA8314@laptop.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
	<20141121170103.GA8314@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
 updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 12:01 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 20, 2014 at 03:28:30PM +0000, Ian Campbell wrote:
> > On Wed, 2014-11-19 at 16:25 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote:
> > > > Hi Konrad, I have another release ack request:
> > > > 
> > > > Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > > > > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > > > > still some places in xenstore are not updated, including:
> > > > > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> > > > > This patch series updates /vm/<uuid>/name in xenstore,
> > > > 
> > > > This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
> > > > bugfix which I think should go into Xen 4.5.
> > > > 
> > > > The risk WITHOUT this patch is that there are out-of-tree tools which
> > > > look here for the domain name and will get confused after it is
> > > > renamed.
> > > 
> > > When was this introduced? Did it exist with Xend?
> > 
> > Based on:
> >  git grep domain\" RELEASE-4.4.0  tools/python/
> >  git grep domain\' RELEASE-4.4.0 tools/python/
> > it doesn't appear so, but someone with a xend install would be needed to
> > confirm for sure.
> > 
> > Given that this has always been wrong for a libxl domain after migration
> > it seems likely to me that noone is looking at this field.
> 
> And this is not a regression though.
> 
> What I am understanding is that we advertise to out-side toolstack
> users for a couple of releases something which is misleading and wrong.

...and also basically useless, there is really no reason to be looking
for the domain's name under a subset of the backend nodes (only vkb, vfb
and console have this key at all). None of the helper function which we
provide do this.

Also these nodes are not advertised as supported either via
docs/misc/xenstore-paths.markdown or xen/include/public/io/*.h.

> My fear is that there such toolstack users out there who will
> get their pitchforks out when this shows up.
> 
> But perhaps there is a way to mitigate this. Is there another way
> (and can it be in the commit description) to get the proper
> domain name? I presume it is just looking at /local/domain/%d/name ?
> 
> As such could this be added:
> 
> "The proper way to get the domain name is to get it from
> /local/domain/%d/name instead from this field."

The proper way is to use libxl_domid_to_name, not to go scrobbling
around in xenstore. We could say this (or both) in the commit message
though if it would help to reassure you.

Either way I think it really would be best to take this fix rather than
worrying overly about the infinitesimal possibility that someone might
be using this key.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:25:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtH2t-0005Za-G0; Tue, 25 Nov 2014 14:24:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtH2s-0005ZV-HN
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:24:46 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	58/9D-02699-D2194745; Tue, 25 Nov 2014 14:24:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416925482!10114439!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19778 invoked from network); 25 Nov 2014 14:24:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:24:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196169626"
Message-ID: <1416924781.32327.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 25 Nov 2014 14:13:01 +0000
In-Reply-To: <20141121170103.GA8314@laptop.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
	<20141121170103.GA8314@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
 updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 12:01 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 20, 2014 at 03:28:30PM +0000, Ian Campbell wrote:
> > On Wed, 2014-11-19 at 16:25 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote:
> > > > Hi Konrad, I have another release ack request:
> > > > 
> > > > Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > > > > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > > > > still some places in xenstore are not updated, including:
> > > > > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> > > > > This patch series updates /vm/<uuid>/name in xenstore,
> > > > 
> > > > This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
> > > > bugfix which I think should go into Xen 4.5.
> > > > 
> > > > The risk WITHOUT this patch is that there are out-of-tree tools which
> > > > look here for the domain name and will get confused after it is
> > > > renamed.
> > > 
> > > When was this introduced? Did it exist with Xend?
> > 
> > Based on:
> >  git grep domain\" RELEASE-4.4.0  tools/python/
> >  git grep domain\' RELEASE-4.4.0 tools/python/
> > it doesn't appear so, but someone with a xend install would be needed to
> > confirm for sure.
> > 
> > Given that this has always been wrong for a libxl domain after migration
> > it seems likely to me that noone is looking at this field.
> 
> And this is not a regression though.
> 
> What I am understanding is that we advertise to out-side toolstack
> users for a couple of releases something which is misleading and wrong.

...and also basically useless, there is really no reason to be looking
for the domain's name under a subset of the backend nodes (only vkb, vfb
and console have this key at all). None of the helper function which we
provide do this.

Also these nodes are not advertised as supported either via
docs/misc/xenstore-paths.markdown or xen/include/public/io/*.h.

> My fear is that there such toolstack users out there who will
> get their pitchforks out when this shows up.
> 
> But perhaps there is a way to mitigate this. Is there another way
> (and can it be in the commit description) to get the proper
> domain name? I presume it is just looking at /local/domain/%d/name ?
> 
> As such could this be added:
> 
> "The proper way to get the domain name is to get it from
> /local/domain/%d/name instead from this field."

The proper way is to use libxl_domid_to_name, not to go scrobbling
around in xenstore. We could say this (or both) in the commit message
though if it would help to reassure you.

Either way I think it really would be best to take this fix rather than
worrying overly about the infinitesimal possibility that someone might
be using this key.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:28:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:28:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtH6n-0005gg-56; Tue, 25 Nov 2014 14:28:49 +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 1XtH6l-0005gZ-9C
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:28:47 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	E4/AF-08051-E1294745; Tue, 25 Nov 2014 14:28:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416925725!14763644!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20641 invoked from network); 25 Nov 2014 14:28:45 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:28:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 14:28:45 +0000
Message-Id: <5474A028020000780004AB58@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 14:28:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-18-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416179271-1221-18-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 17/21] x86/VPMU: Handle PMU interrupts
 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 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
> +            if ( (vpmu_mode & XENPMU_MODE_SELF) )
> +                cur_regs = guest_cpu_user_regs();
> +            else if ( !guest_mode(regs) && is_hardware_domain(sampling->domain) )
> +            {
> +                cur_regs = regs;
> +                domid = DOMID_XEN;
> +            }
> +            else
> +                cur_regs = guest_cpu_user_regs();

Of course it would be nice to do this with a single if/else pair.

> +            else
> +            {
> +                struct segment_register seg;
> +
> +                hvm_get_segment_register(sampled, x86_seg_cs, &seg);
> +                r->cs = seg.sel;
> +                hvm_get_segment_register(sampled, x86_seg_ss, &seg);
> +                r->ss = seg.sel;
> +                if ( seg.attr.fields.dpl != 0 )
> +                    *flags |= PMU_SAMPLE_USER;

Is that how hardware treats it (CPL != 0 meaning user, rather
than CPL == 3)? Maybe you should surface CPL instead of a
boolean flag?

Anyway, with or without the adjustments (unless you go a 3rd
way)
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:28:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:28:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtH6n-0005gg-56; Tue, 25 Nov 2014 14:28:49 +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 1XtH6l-0005gZ-9C
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:28:47 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	E4/AF-08051-E1294745; Tue, 25 Nov 2014 14:28:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1416925725!14763644!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20641 invoked from network); 25 Nov 2014 14:28:45 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:28:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 14:28:45 +0000
Message-Id: <5474A028020000780004AB58@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 14:28:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-18-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1416179271-1221-18-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 17/21] x86/VPMU: Handle PMU interrupts
 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 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
> +            if ( (vpmu_mode & XENPMU_MODE_SELF) )
> +                cur_regs = guest_cpu_user_regs();
> +            else if ( !guest_mode(regs) && is_hardware_domain(sampling->domain) )
> +            {
> +                cur_regs = regs;
> +                domid = DOMID_XEN;
> +            }
> +            else
> +                cur_regs = guest_cpu_user_regs();

Of course it would be nice to do this with a single if/else pair.

> +            else
> +            {
> +                struct segment_register seg;
> +
> +                hvm_get_segment_register(sampled, x86_seg_cs, &seg);
> +                r->cs = seg.sel;
> +                hvm_get_segment_register(sampled, x86_seg_ss, &seg);
> +                r->ss = seg.sel;
> +                if ( seg.attr.fields.dpl != 0 )
> +                    *flags |= PMU_SAMPLE_USER;

Is that how hardware treats it (CPL != 0 meaning user, rather
than CPL == 3)? Maybe you should surface CPL instead of a
boolean flag?

Anyway, with or without the adjustments (unless you go a 3rd
way)
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:35:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:35:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHDT-0005sF-0c; Tue, 25 Nov 2014 14:35:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtHDS-0005sA-Dq
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:35:42 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	D6/B1-17694-DB394745; Tue, 25 Nov 2014 14:35:41 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416926139!9307209!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16278 invoked from network); 25 Nov 2014 14:35:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:35:41 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPEZcsr030319
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 14:35:38 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPEZags027592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 14:35:37 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPEZapX029392; Tue, 25 Nov 2014 14:35:36 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 06:35:36 -0800
Message-ID: <54749466.1020907@oracle.com>
Date: Tue, 25 Nov 2014 09:38:30 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
	<54744FB2020000780004A935@mail.emea.novell.com>
In-Reply-To: <54744FB2020000780004A935@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
	PVH guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 03:45 AM, Jan Beulich wrote:
> @@ -1429,6 +1429,12 @@ int vlapic_init(struct vcpu *v)
>   
>       HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "%d", v->vcpu_id);
>   
> +    if ( is_pvh_vcpu(v) )
> +    {
> +        vlapic->hw.disabled = VLAPIC_HW_DISABLED;


I did consider doing that but I thought that this flag is meant to be 
set when the guest clears MSR_IA32_APICBASE_ENABLE to disable APIC and 
therefore I'd be overloading it (the flag) in a way.

Regardless, do you think that disabling VPMU for PVH is worth anyway?

-boris



> +        return 0;
> +    }
> +
>       vlapic->pt.source = PTSRC_lapic;
>   
>       if (vlapic->regs_page == NULL)
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:35:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:35:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHDT-0005sF-0c; Tue, 25 Nov 2014 14:35:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtHDS-0005sA-Dq
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:35:42 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	D6/B1-17694-DB394745; Tue, 25 Nov 2014 14:35:41 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416926139!9307209!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16278 invoked from network); 25 Nov 2014 14:35:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:35:41 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPEZcsr030319
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 14:35:38 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPEZags027592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 14:35:37 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPEZapX029392; Tue, 25 Nov 2014 14:35:36 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 06:35:36 -0800
Message-ID: <54749466.1020907@oracle.com>
Date: Tue, 25 Nov 2014 09:38:30 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
	<54744FB2020000780004A935@mail.emea.novell.com>
In-Reply-To: <54744FB2020000780004A935@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
	PVH guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 03:45 AM, Jan Beulich wrote:
> @@ -1429,6 +1429,12 @@ int vlapic_init(struct vcpu *v)
>   
>       HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "%d", v->vcpu_id);
>   
> +    if ( is_pvh_vcpu(v) )
> +    {
> +        vlapic->hw.disabled = VLAPIC_HW_DISABLED;


I did consider doing that but I thought that this flag is meant to be 
set when the guest clears MSR_IA32_APICBASE_ENABLE to disable APIC and 
therefore I'd be overloading it (the flag) in a way.

Regardless, do you think that disabling VPMU for PVH is worth anyway?

-boris



> +        return 0;
> +    }
> +
>       vlapic->pt.source = PTSRC_lapic;
>   
>       if (vlapic->regs_page == NULL)
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:36:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHEM-0005wC-EW; Tue, 25 Nov 2014 14:36:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtHEL-0005w6-JI
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:36:37 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	8B/60-09284-4F394745; Tue, 25 Nov 2014 14:36:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416926194!11284885!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23186 invoked from network); 25 Nov 2014 14:36:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:36:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196175978"
Message-ID: <1416925448.32327.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 25 Nov 2014 14:24:08 +0000
In-Reply-To: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> Account for the extra memory needed for the rom files of any emulated nics:
> QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> each them. Assume 256K each.

I suppose this will have to do for 4.5. Can we do something better in
the future -- like figuring out a way for guests to have
"not-really-RAM" allocations like this which are made by the toolstack
and happen to be backed by RAM not count or something.

> 
> This patch fixes a QEMU abort() when more than 4 emulated nics are
> assigned to a VM.

Are you also going to fix qemu to fail gracefully if it cannot deploy
option roms? abort() seems a bit extreme.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Don Slutz <dslutz@verizon.com>
> CC: hanyandong <hanyandong@iie.ac.cn>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>

You missed Ian J. I've added him.

> 
> ---
> 
> Changes in v2:
> - remove double return statement;
> - check for return errors;
> - check for overflows.
> ---
>  tools/libxl/libxl.c          |   53 +++++++++++++++++++++++++++++++++++++-----
>  tools/libxl/libxl_dom.c      |    8 +++++--
>  tools/libxl/libxl_internal.h |    7 ++++++
>  3 files changed, 60 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..2cdb768 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4527,13 +4527,40 @@ out:
>  
>  /******************************************************************************/
>  
> +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> +{
> +    int i, romsize, rc;
> +    libxl_domain_config local_d_config;
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +
> +    if (d_config == NULL) {
> +        libxl_domain_config_init(&local_d_config);
> +        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
> +        if (rc < 0)
> +            return rc;
> +        d_config = &local_d_config;
> +    }

Perhaps we could store the answer to this function in XS when we build
the domain and simply read it back and account for it in the places
which use it?

Apart from being rather costly reparsing the json every time is going to
behave a bit strangely if NICs are plugged/unplugged at runtime and
ballooning is going on.

> +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> +        return 0;
> +
> +    for (i = 0, romsize = 0;
> +         i < d_config->num_nics && romsize < INT_MAX;

I don't think that romsize < INT_MAX is useful except in the case that
romsize+= results in romsize == INT_MAX. If you actually overflow then
romsize becomes negative which satisfies the condition (and in any case
you are into undefined behaviour territory there anyhow, I think).

Given that INT_MAX is a boat load of ROMs I'd be inclined to just limit
it to INT_MAX/2 or /4 or something.

Or you could do romsize < (INT_MAX - LIBXL_ROMSIZE_KB) I suppose.

> +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> +                             + romsize);

Seems like we ought to have a helper to return the memory overheads,
which would be the constant + the romsize starting from 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 Nov 25 14:36:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHEM-0005wC-EW; Tue, 25 Nov 2014 14:36:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtHEL-0005w6-JI
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:36:37 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	8B/60-09284-4F394745; Tue, 25 Nov 2014 14:36:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1416926194!11284885!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23186 invoked from network); 25 Nov 2014 14:36:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:36:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196175978"
Message-ID: <1416925448.32327.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 25 Nov 2014 14:24:08 +0000
In-Reply-To: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> Account for the extra memory needed for the rom files of any emulated nics:
> QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> each them. Assume 256K each.

I suppose this will have to do for 4.5. Can we do something better in
the future -- like figuring out a way for guests to have
"not-really-RAM" allocations like this which are made by the toolstack
and happen to be backed by RAM not count or something.

> 
> This patch fixes a QEMU abort() when more than 4 emulated nics are
> assigned to a VM.

Are you also going to fix qemu to fail gracefully if it cannot deploy
option roms? abort() seems a bit extreme.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Don Slutz <dslutz@verizon.com>
> CC: hanyandong <hanyandong@iie.ac.cn>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>

You missed Ian J. I've added him.

> 
> ---
> 
> Changes in v2:
> - remove double return statement;
> - check for return errors;
> - check for overflows.
> ---
>  tools/libxl/libxl.c          |   53 +++++++++++++++++++++++++++++++++++++-----
>  tools/libxl/libxl_dom.c      |    8 +++++--
>  tools/libxl/libxl_internal.h |    7 ++++++
>  3 files changed, 60 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..2cdb768 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4527,13 +4527,40 @@ out:
>  
>  /******************************************************************************/
>  
> +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> +{
> +    int i, romsize, rc;
> +    libxl_domain_config local_d_config;
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +
> +    if (d_config == NULL) {
> +        libxl_domain_config_init(&local_d_config);
> +        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
> +        if (rc < 0)
> +            return rc;
> +        d_config = &local_d_config;
> +    }

Perhaps we could store the answer to this function in XS when we build
the domain and simply read it back and account for it in the places
which use it?

Apart from being rather costly reparsing the json every time is going to
behave a bit strangely if NICs are plugged/unplugged at runtime and
ballooning is going on.

> +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> +        return 0;
> +
> +    for (i = 0, romsize = 0;
> +         i < d_config->num_nics && romsize < INT_MAX;

I don't think that romsize < INT_MAX is useful except in the case that
romsize+= results in romsize == INT_MAX. If you actually overflow then
romsize becomes negative which satisfies the condition (and in any case
you are into undefined behaviour territory there anyhow, I think).

Given that INT_MAX is a boat load of ROMs I'd be inclined to just limit
it to INT_MAX/2 or /4 or something.

Or you could do romsize < (INT_MAX - LIBXL_ROMSIZE_KB) I suppose.

> +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> +                             + romsize);

Seems like we ought to have a helper to return the memory overheads,
which would be the constant + the romsize starting from 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 Nov 25 14:43:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:43:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHKW-0006BO-8k; Tue, 25 Nov 2014 14:43:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHKU-0006BJ-Tn
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:42:59 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C5/27-22737-27594745; Tue, 25 Nov 2014 14:42:58 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416926575!9152962!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11739 invoked from network); 25 Nov 2014 14:42:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:42:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196571148"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 09:42:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHK5-0003TP-Fb;
	Tue, 25 Nov 2014 14:42:33 +0000
Date: Tue, 25 Nov 2014 14:42:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, wency@cn.fujitsu.com, mst@redhat.com,
	jasowang@redhat.com, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH 0/4] virtio-net: do not leak cpu mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series fixes a cpu mapping leak in virtio-net.

The bug is caused by virtio_net_handle_ctrl: it maps the entire out_sg
iov, but then modifies it and reduces it (iov_discard_front), and only
unmap the reduced version of the iov.

This causes a crash when running on Xen, but the behaviour is obviously
incorrect without Xen too.

The patch series fixes the issue by allowing virtio_net_handle_ctrl to
unmap the original out_sg iov but still call virtqueue_fill and
virtqueue_flush on the modified iov.

The first three patches do not introduce any functional changes.


Stefano Stabellini (4):
      introduce virtqueue_unmap_sg
      use virtqueue_unmap_sg in virtqueue_fill
      move virtqueue_unmap_sg calls from virtqueue_fill to virtqueue_push
      virtio-net: do not leak cpu mappings

 hw/net/virtio-net.c        |    9 ++++++++-
 hw/virtio/virtio.c         |   43 ++++++++++++++++++++++++-------------------
 include/hw/virtio/virtio.h |    2 ++
 3 files changed, 34 insertions(+), 20 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:43:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:43:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHKW-0006BO-8k; Tue, 25 Nov 2014 14:43:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHKU-0006BJ-Tn
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:42:59 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C5/27-22737-27594745; Tue, 25 Nov 2014 14:42:58 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416926575!9152962!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11739 invoked from network); 25 Nov 2014 14:42:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:42:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196571148"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 09:42:33 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHK5-0003TP-Fb;
	Tue, 25 Nov 2014 14:42:33 +0000
Date: Tue, 25 Nov 2014 14:42:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, wency@cn.fujitsu.com, mst@redhat.com,
	jasowang@redhat.com, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH 0/4] virtio-net: do not leak cpu mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series fixes a cpu mapping leak in virtio-net.

The bug is caused by virtio_net_handle_ctrl: it maps the entire out_sg
iov, but then modifies it and reduces it (iov_discard_front), and only
unmap the reduced version of the iov.

This causes a crash when running on Xen, but the behaviour is obviously
incorrect without Xen too.

The patch series fixes the issue by allowing virtio_net_handle_ctrl to
unmap the original out_sg iov but still call virtqueue_fill and
virtqueue_flush on the modified iov.

The first three patches do not introduce any functional changes.


Stefano Stabellini (4):
      introduce virtqueue_unmap_sg
      use virtqueue_unmap_sg in virtqueue_fill
      move virtqueue_unmap_sg calls from virtqueue_fill to virtqueue_push
      virtio-net: do not leak cpu mappings

 hw/net/virtio-net.c        |    9 ++++++++-
 hw/virtio/virtio.c         |   43 ++++++++++++++++++++++++-------------------
 include/hw/virtio/virtio.h |    2 ++
 3 files changed, 34 insertions(+), 20 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:43:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:43:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHLA-0006Ev-0l; Tue, 25 Nov 2014 14:43:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHL8-0006EV-DR
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:43:38 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	1A/75-27623-99594745; Tue, 25 Nov 2014 14:43:37 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416926615!13695516!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7778 invoked from network); 25 Nov 2014 14:43:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:43:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196571518"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 09:43:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHKy-0003UI-KX;
	Tue, 25 Nov 2014 14:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Tue, 25 Nov 2014 14:43:21 +0000
Message-ID: <1416926603-12397-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, wency@cn.fujitsu.com, mst@redhat.com,
	jasowang@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH 2/4] use virtqueue_unmap_sg in virtqueue_fill
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 virtqueue_unmap_sg to unmap in_sg and out_sg in virtqueue_fill.

No functional changes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: jasowang@redhat.com
CC: wency@cn.fujitsu.com
CC: mst@redhat.com
CC: pbonzini@redhat.com
---
 hw/virtio/virtio.c |   20 ++------------------
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 2621ae6..4af31d0 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -238,26 +238,10 @@ int virtio_queue_empty(VirtQueue *vq)
 void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
                     unsigned int len, unsigned int idx)
 {
-    unsigned int offset;
-    int i;
-
     trace_virtqueue_fill(vq, elem, len, idx);
 
-    offset = 0;
-    for (i = 0; i < elem->in_num; i++) {
-        size_t size = MIN(len - offset, elem->in_sg[i].iov_len);
-
-        cpu_physical_memory_unmap(elem->in_sg[i].iov_base,
-                                  elem->in_sg[i].iov_len,
-                                  1, size);
-
-        offset += size;
-    }
-
-    for (i = 0; i < elem->out_num; i++)
-        cpu_physical_memory_unmap(elem->out_sg[i].iov_base,
-                                  elem->out_sg[i].iov_len,
-                                  0, elem->out_sg[i].iov_len);
+    virtqueue_unmap_sg(elem->in_sg, elem->in_num, 1, len);
+    virtqueue_unmap_sg(elem->out_sg, elem->out_num, 0, UINT_MAX);
 
     idx = (idx + vring_used_idx(vq)) % vq->vring.num;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:43:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:43:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHLA-0006Ev-0l; Tue, 25 Nov 2014 14:43:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHL8-0006EV-DR
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:43:38 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	1A/75-27623-99594745; Tue, 25 Nov 2014 14:43:37 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416926615!13695516!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7778 invoked from network); 25 Nov 2014 14:43:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:43:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196571518"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 09:43:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHKy-0003UI-KX;
	Tue, 25 Nov 2014 14:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Tue, 25 Nov 2014 14:43:21 +0000
Message-ID: <1416926603-12397-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, wency@cn.fujitsu.com, mst@redhat.com,
	jasowang@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH 2/4] use virtqueue_unmap_sg in virtqueue_fill
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 virtqueue_unmap_sg to unmap in_sg and out_sg in virtqueue_fill.

No functional changes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: jasowang@redhat.com
CC: wency@cn.fujitsu.com
CC: mst@redhat.com
CC: pbonzini@redhat.com
---
 hw/virtio/virtio.c |   20 ++------------------
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 2621ae6..4af31d0 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -238,26 +238,10 @@ int virtio_queue_empty(VirtQueue *vq)
 void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
                     unsigned int len, unsigned int idx)
 {
-    unsigned int offset;
-    int i;
-
     trace_virtqueue_fill(vq, elem, len, idx);
 
-    offset = 0;
-    for (i = 0; i < elem->in_num; i++) {
-        size_t size = MIN(len - offset, elem->in_sg[i].iov_len);
-
-        cpu_physical_memory_unmap(elem->in_sg[i].iov_base,
-                                  elem->in_sg[i].iov_len,
-                                  1, size);
-
-        offset += size;
-    }
-
-    for (i = 0; i < elem->out_num; i++)
-        cpu_physical_memory_unmap(elem->out_sg[i].iov_base,
-                                  elem->out_sg[i].iov_len,
-                                  0, elem->out_sg[i].iov_len);
+    virtqueue_unmap_sg(elem->in_sg, elem->in_num, 1, len);
+    virtqueue_unmap_sg(elem->out_sg, elem->out_num, 0, UINT_MAX);
 
     idx = (idx + vring_used_idx(vq)) % vq->vring.num;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:43:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:43:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHL9-0006Eo-Lf; Tue, 25 Nov 2014 14:43:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHL7-0006ES-Te
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:43:38 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	4B/8A-25547-99594745; Tue, 25 Nov 2014 14:43:37 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416926615!13695516!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7700 invoked from network); 25 Nov 2014 14:43:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:43:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196571517"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 09:43:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHKy-0003UI-Jv;
	Tue, 25 Nov 2014 14:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Tue, 25 Nov 2014 14:43:20 +0000
Message-ID: <1416926603-12397-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, wency@cn.fujitsu.com, mst@redhat.com,
	jasowang@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH 1/4] introduce virtqueue_unmap_sg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 function to unmap an sg previously mapped with
virtqueue_map_sg.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: jasowang@redhat.com
CC: wency@cn.fujitsu.com
CC: mst@redhat.com
CC: pbonzini@redhat.com
---
 hw/virtio/virtio.c         |   22 ++++++++++++++++++++++
 include/hw/virtio/virtio.h |    2 ++
 2 files changed, 24 insertions(+)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 3e4b70c..2621ae6 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -446,6 +446,28 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
     }
 }
 
+void virtqueue_unmap_sg(const struct iovec *sg, size_t num_sg,
+                        int is_write, unsigned int len)
+{
+    unsigned int i;
+    unsigned int offset;
+
+    if (num_sg > VIRTQUEUE_MAX_SIZE) {
+        error_report("virtio: unmap attempt out of bounds: %zd > %d",
+                     num_sg, VIRTQUEUE_MAX_SIZE);
+        exit(1);
+    }
+
+    offset = 0;
+    for (i = 0; i < num_sg; i++) {
+        size_t size = MIN(len - offset, sg[i].iov_len);
+
+        cpu_physical_memory_unmap(sg[i].iov_base, sg[i].iov_len, is_write, size);
+
+        offset += size;
+    }
+}
+
 int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
 {
     unsigned int i, head, max;
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 3e54e90..2325053 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -173,6 +173,8 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
 
 void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
     size_t num_sg, int is_write);
+void virtqueue_unmap_sg(const struct iovec *sg, size_t num_sg,
+                        int is_write, unsigned int len);
 int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem);
 int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes,
                           unsigned int out_bytes);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:43:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:43:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHL9-0006Eo-Lf; Tue, 25 Nov 2014 14:43:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHL7-0006ES-Te
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:43:38 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	4B/8A-25547-99594745; Tue, 25 Nov 2014 14:43:37 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416926615!13695516!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7700 invoked from network); 25 Nov 2014 14:43:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:43:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196571517"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 09:43:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHKy-0003UI-Jv;
	Tue, 25 Nov 2014 14:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Tue, 25 Nov 2014 14:43:20 +0000
Message-ID: <1416926603-12397-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, wency@cn.fujitsu.com, mst@redhat.com,
	jasowang@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH 1/4] introduce virtqueue_unmap_sg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 function to unmap an sg previously mapped with
virtqueue_map_sg.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: jasowang@redhat.com
CC: wency@cn.fujitsu.com
CC: mst@redhat.com
CC: pbonzini@redhat.com
---
 hw/virtio/virtio.c         |   22 ++++++++++++++++++++++
 include/hw/virtio/virtio.h |    2 ++
 2 files changed, 24 insertions(+)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 3e4b70c..2621ae6 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -446,6 +446,28 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
     }
 }
 
+void virtqueue_unmap_sg(const struct iovec *sg, size_t num_sg,
+                        int is_write, unsigned int len)
+{
+    unsigned int i;
+    unsigned int offset;
+
+    if (num_sg > VIRTQUEUE_MAX_SIZE) {
+        error_report("virtio: unmap attempt out of bounds: %zd > %d",
+                     num_sg, VIRTQUEUE_MAX_SIZE);
+        exit(1);
+    }
+
+    offset = 0;
+    for (i = 0; i < num_sg; i++) {
+        size_t size = MIN(len - offset, sg[i].iov_len);
+
+        cpu_physical_memory_unmap(sg[i].iov_base, sg[i].iov_len, is_write, size);
+
+        offset += size;
+    }
+}
+
 int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
 {
     unsigned int i, head, max;
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 3e54e90..2325053 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -173,6 +173,8 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
 
 void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
     size_t num_sg, int is_write);
+void virtqueue_unmap_sg(const struct iovec *sg, size_t num_sg,
+                        int is_write, unsigned int len);
 int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem);
 int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes,
                           unsigned int out_bytes);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:43:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:43:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHLA-0006FM-Hi; Tue, 25 Nov 2014 14:43:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHL9-0006Ei-3h
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:43:39 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	D4/9A-25547-A9594745; Tue, 25 Nov 2014 14:43:38 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416926615!13695516!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7872 invoked from network); 25 Nov 2014 14:43:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:43:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196571519"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 09:43:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHKy-0003UI-Mv;
	Tue, 25 Nov 2014 14:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Tue, 25 Nov 2014 14:43:23 +0000
Message-ID: <1416926603-12397-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, wency@cn.fujitsu.com, mst@redhat.com,
	jasowang@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH 4/4] virtio-net: do not leak cpu mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In virtio_net_handle_ctrl unmap the previously mapped out_sg, not a
subset of it.

This patch fixes an abort() when running on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: jasowang@redhat.com
CC: wency@cn.fujitsu.com
CC: mst@redhat.com
CC: pbonzini@redhat.com
---
 hw/net/virtio-net.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 5035313..c9b82f3 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -773,6 +773,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
     VirtQueueElement elem;
     size_t s;
     struct iovec *iov;
+    struct iovec iov_copy[VIRTQUEUE_MAX_SIZE];
     unsigned int iov_cnt;
 
     while (virtqueue_pop(vq, &elem)) {
@@ -782,6 +783,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
             exit(1);
         }
 
+        memcpy(iov_copy, elem.out_sg, elem.out_num*sizeof(struct iovec));
         iov = elem.out_sg;
         iov_cnt = elem.out_num;
         s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
@@ -804,7 +806,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
         assert(s == sizeof(status));
 
         virtqueue_unmap_sg(elem.in_sg, elem.in_num, 1, sizeof(status));
-        virtqueue_unmap_sg(elem.out_sg, elem.out_num, 0, UINT_MAX);
+        virtqueue_unmap_sg(iov_copy, elem.out_num, 0, UINT_MAX);
         virtqueue_fill(vq, &elem, sizeof(status), 0);
         virtqueue_flush(vq, 1);
         virtio_notify(vdev, vq);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:43:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:43:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHLA-0006FM-Hi; Tue, 25 Nov 2014 14:43:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHL9-0006Ei-3h
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:43:39 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	D4/9A-25547-A9594745; Tue, 25 Nov 2014 14:43:38 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416926615!13695516!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7872 invoked from network); 25 Nov 2014 14:43:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:43:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="196571519"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 09:43:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHKy-0003UI-Mv;
	Tue, 25 Nov 2014 14:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Tue, 25 Nov 2014 14:43:23 +0000
Message-ID: <1416926603-12397-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, wency@cn.fujitsu.com, mst@redhat.com,
	jasowang@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH 4/4] virtio-net: do not leak cpu mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In virtio_net_handle_ctrl unmap the previously mapped out_sg, not a
subset of it.

This patch fixes an abort() when running on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: jasowang@redhat.com
CC: wency@cn.fujitsu.com
CC: mst@redhat.com
CC: pbonzini@redhat.com
---
 hw/net/virtio-net.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 5035313..c9b82f3 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -773,6 +773,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
     VirtQueueElement elem;
     size_t s;
     struct iovec *iov;
+    struct iovec iov_copy[VIRTQUEUE_MAX_SIZE];
     unsigned int iov_cnt;
 
     while (virtqueue_pop(vq, &elem)) {
@@ -782,6 +783,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
             exit(1);
         }
 
+        memcpy(iov_copy, elem.out_sg, elem.out_num*sizeof(struct iovec));
         iov = elem.out_sg;
         iov_cnt = elem.out_num;
         s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
@@ -804,7 +806,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
         assert(s == sizeof(status));
 
         virtqueue_unmap_sg(elem.in_sg, elem.in_num, 1, sizeof(status));
-        virtqueue_unmap_sg(elem.out_sg, elem.out_num, 0, UINT_MAX);
+        virtqueue_unmap_sg(iov_copy, elem.out_num, 0, UINT_MAX);
         virtqueue_fill(vq, &elem, sizeof(status), 0);
         virtqueue_flush(vq, 1);
         virtio_notify(vdev, vq);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:45:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:45:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHMQ-0006VR-AS; Tue, 25 Nov 2014 14:44:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XtHMP-0006V8-2F
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:44:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	2E/9D-07724-8E594745; Tue, 25 Nov 2014 14:44:56 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416926690!13756292!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10585 invoked from network); 25 Nov 2014 14:44:51 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-8.tower-31.messagelabs.com with SMTP;
	25 Nov 2014 14:44:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 25 Nov 2014 06:37:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,455,1413270000"; d="scan'208";a="628010069"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by fmsmga001.fm.intel.com with ESMTP; 25 Nov 2014 06:44:32 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 25 Nov 2014 22:44:30 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Tue, 25 Nov 2014 22:44:29 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend driver
Thread-Index: AQHQCAHoGXWQuRHWjU6e4Zjz5rVgr5xxY//A
Date: Tue, 25 Nov 2014 14:44:29 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8417C4@SHSMSX101.ccr.corp.intel.com>
References: <1416802256-9928-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411241544410.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411241544410.2675@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
 frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Tuesday, November 25, 2014 12:16 AM
> To: Xu, Quan
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> stefano.stabellini@eu.citrix.com
> Subject: Re: [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
> driver
> 
> On Sun, 23 Nov 2014, Quan Xu wrote:
> > This drvier transfers any request/repond between TPM xenstubdoms
> > driver and Xen vTPM stubdom, and facilitates communications between
> > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> 
> This patch needs a better description, see my past request:
> 
> http://marc.info/?l=xen-devel&m=141501570709022&w=2
> 
> 
> >  hw/tpm/Makefile.objs         |   1 +
> >  hw/tpm/xen_stubdom_vtpm.c    | 321
> +++++++++++++++++++++++++++++++++++++++++++
> >  hw/xen/xen_backend.c         | 272
> ++++++++++++++++++++++++++++++++++++
> >  include/hw/xen/xen_backend.h |  11 ++
> >  include/hw/xen/xen_common.h  |   6 +
> >  xen-hvm.c                    |  13 ++
> >  6 files changed, 624 insertions(+)
> >  create mode 100644 hw/tpm/xen_stubdom_vtpm.c
> >
> > diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs index
> > 99f5983..87efb01 100644
> > --- a/hw/tpm/Makefile.objs
> > +++ b/hw/tpm/Makefile.objs
> > @@ -1,2 +1,3 @@
> >  common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
> >  common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
> > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> > diff --git a/hw/tpm/xen_stubdom_vtpm.c
> b/hw/tpm/xen_stubdom_vtpm.c new
> > file mode 100644 index 0000000..4fd6053
> > --- /dev/null
> > +++ b/hw/tpm/xen_stubdom_vtpm.c
> 
> I would just call it xen_vtpm_frontend.c
> 
> I don't think that the fact that the backend is probably run in a
> stubdom is relevant here. The only thing that matter is that this is a
> PV frontend.
> 
> 
> Also if this is the vtpm specific frontend, where is the file that
> introduces the generic frontend registration framework, as previously
> discussed?
> 
> http://marc.info/?l=xen-devel&m=141528935207946&w=2
> 
> I think we should have a hw/xen/xen_frontend.c file, introducing
> xen_fe_register etc, and a separate hw/tpm/xen_stubdom_vtpm.c with the
> vtpm specific stuff.
> 
> 
> > @@ -0,0 +1,321 @@
> > +/*
> > + * Connect to Xen vTPM stubdom domain
> > + *
> > + *  Copyright (c) 2014 Intel Corporation
> > + *  Authors:
> > + *    Quan Xu <quan.xu@intel.com>
> > + *
> > + * 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 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, see
> <http://www.gnu.org/licenses/>
> > + */
> > +
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <stdarg.h>
> > +#include <string.h>
> > +#include <unistd.h>
> > +#include <signal.h>
> > +#include <inttypes.h>
> > +#include <time.h>
> > +#include <fcntl.h>
> > +#include <errno.h>
> > +#include <sys/ioctl.h>
> > +#include <sys/types.h>
> > +#include <sys/stat.h>
> > +#include <sys/mman.h>
> > +#include <sys/uio.h>
> > +
> > +#include "hw/hw.h"
> > +#include "block/aio.h"
> > +#include "hw/xen/xen_backend.h"
> > +
> > +enum tpmif_state {
> > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> complete */
> > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> > +};
> > +
> > +static AioContext *vtpm_aio_ctx;
> > +
> > +enum status_bits {
> > +    VTPM_STATUS_RUNNING  = 0x1,
> > +    VTPM_STATUS_IDLE     = 0x2,
> > +    VTPM_STATUS_RESULT   = 0x4,
> > +    VTPM_STATUS_CANCELED = 0x8,
> > +};
> > +
> > +struct tpmif_shared_page {
> > +    uint32_t length;         /* request/response length in bytes */
> > +
> > +    uint8_t  state;           /* enum tpmif_state */
> > +    uint8_t  locality;        /* for the current request */
> > +    uint8_t  pad;             /* should be zero */
> > +
> > +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be
> zero */
> > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> nr_extra_pages */
> > +};
> > +
> > +struct XenVtpmDev {
> > +    struct XenDevice xendev;  /* must be first */
> > +    struct           tpmif_shared_page *shr;
> > +    xc_gntshr        *xen_xcs;
> > +    int              ring_ref;
> > +    int              bedomid;
> > +    QEMUBH           *sr_bh;
> > +};
> > +
> > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> > +{
> > +    switch (vtpmdev->shr->state) {
> > +    case TPMIF_STATE_IDLE:
> > +    case TPMIF_STATE_FINISH:
> > +        return VTPM_STATUS_IDLE;
> > +    case TPMIF_STATE_SUBMIT:
> > +    case TPMIF_STATE_CANCEL:
> > +        return VTPM_STATUS_RUNNING;
> > +    default:
> > +        return 0;
> > +    }
> > +}
> > +
> > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> xenbus_state xbus)
> > +{
> > +    xs_transaction_t xbt = XBT_NULL;
> > +
> > +    if (xendev->fe_state == xbus) {
> > +        return 0;
> > +    }
> > +
> > +    xendev->fe_state = xbus;
> > +
> > +retry_transaction:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto retry_transaction;
> > +        }
> > +    }
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> 
> This would probably end up in xen_frontend.c
> 
> 
> > +static bool vtpm_aio_wait(AioContext *ctx)
> > +{
> > +    return aio_poll(ctx, true);
> > +}
> > +
> > +static void sr_bh_handler(void *opaque)
> > +{
> > +}
> > +
> > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t
> *count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset;
> > +
> > +    if (shr->state == TPMIF_STATE_IDLE) {
> > +        return -ECANCELED;
> > +    }
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpm_aio_ctx);
> > +    }
> > +
> > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > +    *count = shr->length;
> > +
> > +    return 0;
> > +}
> > +
> > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t
> count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpm_aio_ctx);
> > +    }
> > +
> > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > +    shr->length = count;
> > +    barrier();
> > +    shr->state = TPMIF_STATE_SUBMIT;
> > +    xen_wmb();
> > +    xen_be_send_notify(&vtpmdev->xendev);
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpm_aio_ctx);
> > +    }
> > +
> > +    return count;
> > +}
> > +
> > +static int vtpm_initialise(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    xs_transaction_t xbt = XBT_NULL;
> > +    unsigned int ring_ref;
> > +
> > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> "frontend");
> > +    if (vtpmdev->xendev.fe == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /* Get backend domid */
> > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > +                             &vtpmdev->bedomid)) {
> > +        return -1;
> > +    }
> > +
> > +    /*alloc share page*/
> > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> vtpmdev->bedomid, 1,
> > +                                         &ring_ref,
> PROT_READ|PROT_WRITE);
> > +    vtpmdev->ring_ref = ring_ref;
> > +    if (vtpmdev->shr == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /*Create event channel */
> > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> vtpmdev->bedomid)) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +        return -1;
> > +    }
> > +
> > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > +                     vtpmdev->xendev.local_port);
> > +
> > +again:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > +                           vtpmdev->ring_ref)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > +                           vtpmdev->xendev.local_port)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    /* Publish protocol v2 feature */
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1))
> {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto again;
> > +        }
> > +    }
> > +    /* Tell vtpm backend that we are ready */
> > +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static void vtpm_backend_changed(struct XenDevice *xendev, const char
> *node)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    int be_state;
> > +
> > +    if (strcmp(node, "state") == 0) {
> > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > +        switch (be_state) {
> > +        case XenbusStateConnected:
> > +            /*TODO*/
> > +            break;
> > +        case XenbusStateClosing:
> > +        case XenbusStateClosed:
> > +            xenbus_switch_state(&vtpmdev->xendev,
> XenbusStateClosing);
> > +            break;
> > +        default:
> > +            break;
> > +        }
> > +    }
> > +}
> 
> This would probably end up in xen_backend.c
> 
> 
> > +static int vtpm_free(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    aio_poll(vtpm_aio_ctx, false);
> > +    qemu_bh_delete(vtpmdev->sr_bh);
> > +    if (vtpmdev->shr) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    }
> > +    xc_interface_close(vtpmdev->xen_xcs);
> > +    return 0;
> > +}
> > +
> > +static void vtpm_alloc(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    vtpm_aio_ctx = aio_context_new(NULL);
> > +    if (vtpm_aio_ctx == NULL) {
> > +        return;
> > +    }
> > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> vtpmdev);
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> > +}
> > +
> > +static void vtpm_event(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +}
> > +
> > +struct XenDevOps xen_vtpmdev_ops = {
> > +    .size             = sizeof(struct XenVtpmDev),
> > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > +                        DEVOPS_FLAG_STUBDOM_BE,
> > +    .event            = vtpm_event,
> > +    .free             = vtpm_free,
> > +    .alloc            = vtpm_alloc,
> > +    .initialise       = vtpm_initialise,
> > +    .backend_changed  = vtpm_backend_changed,
> > +    .recv             = vtpm_recv,
> > +    .send             = vtpm_send,
> 
> I don't think that recv and send should be part of the XenDevOps
> interface. This interface is supposed to be a generic interface to
> implement a Xen PV backend (or frontend maybe). recv and send are
> specific to the vtpm driver, so they should not be here.
> 
> 
> > +};
> > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> > index b2cb22b..5e7cfe5 100644
> > --- a/hw/xen/xen_backend.c
> > +++ b/hw/xen/xen_backend.c
> > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev,
> enum xenbus_state state)
> >      return 0;
> >  }
> >
> > +/*get stubdom backend*/
> > +static char *xen_stubdom_be(const char *type, int dom, int dev)
> > +{
> > +    char *val, *domu;
> > +    char path[XEN_BUFSIZE];
> > +    unsigned int len, ival;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, dom);
> > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > +             domu, type, dev);
> > +    g_free(domu);
> > +
> > +    val = xs_read(xenstore, 0, path, &len);
> > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > +        g_free(val);
> > +        return NULL;
> > +    }
> > +    g_free(val);
> > +
> > +    /*backend domu*/
> > +    domu = xs_get_domain_path(xenstore, ival);
> > +
> > +    return domu;
> > +}
> 
> This looks like a function to find the backend path. Instead of
> duplicating functionalities with xenstore_read_be_str, we should just
> make sure that xenstore_read_be_str works with backends other than dom0.
> 
> If we really do need a new function, that I don't think is the case, it
> should be as generic as possible, so it should be called something like
> xenstore_read_be_str and be in xen_frontend.c.
> 
> 
> >  /* ------------------------------------------------------------- */
> >
> >  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int
> dev)
> > @@ -273,6 +299,68 @@ static struct XenDevice
> *xen_be_get_xendev(const char *type, int dom, int dev,
> >  }
> >
> >  /*
> > + * get xen stubdom backend device, allocate a new one if it doesn't exist.
> > + */
> > +static struct XenDevice *xen_stubdom_be_get_xendev(const char *type,
> > +                         int dom, int dev, struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char *stub;
> > +
> > +    xendev = xen_be_find_xendev(type, dom, dev);
> > +    if (xendev) {
> > +        return xendev;
> > +    }
> > +
> > +    /* init new xendev */
> > +    xendev = g_malloc0(ops->size);
> > +    xendev->type  = type;
> > +    xendev->dom   = dom;
> > +    xendev->dev   = dev;
> > +    xendev->ops   = ops;
> > +
> > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> xendev->dev);
> > +        snprintf(xendev->be, sizeof(xendev->be),
> "%s/backend/%s/%d/%d",
> > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > +        g_free(stub);
> > +    }
> > +    snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> > +             xendev->type, xendev->dev);
> > +
> > +    xendev->debug      = debug;
> > +    xendev->local_port = -1;
> > +
> > +    xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
> > +    if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
> > +        xen_be_printf(NULL, 0, "can't open evtchn device\n");
> > +        g_free(xendev);
> > +        return NULL;
> > +    }
> > +    fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
> > +
> > +    if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
> > +        xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
> > +        if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
> > +            xen_be_printf(NULL, 0, "can't open gnttab device\n");
> > +            xc_evtchn_close(xendev->evtchndev);
> > +            g_free(xendev);
> > +            return NULL;
> > +        }
> > +    } else {
> > +        xendev->gnttabdev = XC_HANDLER_INITIAL_VALUE;
> > +    }
> > +
> > +    QTAILQ_INSERT_TAIL(&xendevs, xendev, next);
> > +
> > +    if (xendev->ops->alloc) {
> > +        xendev->ops->alloc(xendev);
> > +    }
> > +
> > +    return xendev;
> > +}
> 
> Same here: this should be called xen_fe_get_xendev and be in
> xen_frontend.c
> 
> Nothing should be called *_stubdom_*: we don't care about stubdoms in
> QEMU, only about frontends and backends.
> 
> 
> > +/*
> >   * release xen backend device.
> >   */
> >  static struct XenDevice *xen_be_del_xendev(int dom, int dev)
> > @@ -611,6 +699,47 @@ static int xenstore_scan(const char *type, int
> dom, struct XenDevOps *ops)
> >      return 0;
> >  }
> >
> > +static void stubdom_update_be(char *watch, char *type, int dom,
> > +                              struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE];
> > +    char *ptr, *bepath;
> > +    unsigned int len, dev;
> > +
> > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > +        return;
> > +    }
> > +
> > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > +    ptr = strstr(watch, path);
> > +    if (ptr == NULL) {
> > +        return;
> > +    }
> > +
> > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > +        strcpy(path, "");
> > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > +            dev = -1;
> > +        }
> > +    }
> > +
> > +    if (dev == -1) {
> > +        return;
> > +    }
> > +
> > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > +    if (xendev != NULL) {
> > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > +        if (bepath == NULL) {
> > +            xen_be_del_xendev(dom, dev);
> > +        } else {
> > +            free(bepath);
> > +            xen_be_backend_changed(xendev, path);
> > +        }
> > +    }
> > +}
> 
> ditto
> 
> 
> >  static void xenstore_update_be(char *watch, char *type, int dom,
> >                                 struct XenDevOps *ops)
> >  {
> > @@ -681,6 +810,10 @@ static void xenstore_update(void *unused)
> >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> >      }
> > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> PRIxPTR,
> > +               &type, &dom, &ops) == 3) {
> > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom,
> (void *)ops);
> > +    }
> >
> >  cleanup:
> >      free(vec);
> > @@ -732,11 +865,114 @@ err:
> >      return -1;
> >  }
> >
> > +static int stubdom_check(struct XenDevice *xendev, uint32_t domid,
> > +                         int handle)
> > +{
> > +    int rc = 0;
> > +
> > +    if (xendev->ops->init) {
> > +        rc = xendev->ops->init(xendev);
> > +    }
> > +
> > +    if (rc != 0) {
> > +        xen_be_printf(xendev, 0, "xendev %s init error\n",
> > +                     xendev->name);
> > +       goto err;
> > +    }
> > +
> > +    if (xendev->ops->initialise) {
> > +        rc = xendev->ops->initialise(xendev);
> > +    }
> > +
> > +    if (rc != 0) {
> > +        xen_be_printf(xendev, 0, "xendev %s initialise error\n",
> > +                     xendev->name);
> > +       goto err;
> > +    }
> > +
> > +    if (xendev->ops->connected) {
> > +        xendev->ops->connected(xendev);
> > +    }
> > +
> > +    return rc;
> > +
> > +err:
> > +    xen_be_del_xendev(domid, handle);
> > +    return -1;
> > +}
> 
> ditto
> 
> 
> > +static int xenstore_stubdom_scan(const char *type, uint32_t domid,
> > +                                 struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > +    char *domu;
> > +    unsigned int cdev, j;
> > +    char **dev = NULL;
> > +
> > +    /*stubom : /local/domain/ID */
> > +    domu = xs_get_domain_path(xenstore, domid);
> > +    snprintf(path, sizeof(path), "%s/device/%s",
> > +             domu, type);
> > +    free(domu);
> > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > +    if (dev == NULL) {
> > +        return 0;
> > +    }
> > +
> > +    for (j = 0; j < cdev; j++) {
> > +        xendev = xen_stubdom_be_get_xendev(type, domid,
> > +                                           atoi(dev[j]), ops);
> > +        if (xendev == NULL) {
> > +            xen_be_printf(xendev, 0, "xendev is NULL.\n");
> > +            continue;
> > +        }
> > +
> > +        /* simplify QEMU side, a thread is running in Xen stubdom,
> which will
> > +         * connect frontend when the frontend is initialised.
> > +         */
> > +        if (stubdom_check(xendev, domid, atoi(dev[j])) < 0) {
> > +            xen_be_printf(xendev, 0, "xendev stubdom_check
> error.\n");
> > +            continue;
> > +        }
> > +
> > +        /*setup watch*/
> > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > +                 type, domid, xendev->ops);
> > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > +            xen_be_printf(xendev, 0, "xs_watch failed.\n");
> > +            continue;
> > +        }
> > +    }
> > +
> > +    free(dev);
> > +    return 0;
> > +}
> 
> ditto
> 
> 
> > +int xen_fe_register(const char *type, struct XenDevOps *ops)
> > +{
> > +    return xenstore_stubdom_scan(type, xen_domid, ops);
> > +}
> > +
> >  int xen_be_register(const char *type, struct XenDevOps *ops)
> >  {
> >      return xenstore_scan(type, xen_domid, ops);
> >  }
> >
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom)
> > +{
> > +    xendev->local_port =
> xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > +
> remote_dom);
> > +    if (xendev->local_port == -1) {
> > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> > +        return -1;
> > +    }
> > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> xendev->local_port);
> > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > +                        xen_be_evtchn_event, NULL, xendev);
> > +    return 0;
> > +}
> > +
> >  int xen_be_bind_evtchn(struct XenDevice *xendev)
> >  {
> >      if (xendev->local_port != -1) {
> > @@ -770,6 +1006,42 @@ int xen_be_send_notify(struct XenDevice
> *xendev)
> >      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
> >  }
> >
> > +int xen_vtpm_send(unsigned char *buf, size_t count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->send) {
> > +        rc = xendev->ops->send(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> > +
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->recv) {
> > +        xendev->ops->recv(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> 
> I don't these we should have these two functions here, they don't belong
> to the QEMU internal Xen backend (or frontend) interface.
> 
> 
> >  /*
> >   * msg_level:
> >   *  0 == errors (stderr + logfile).
> > diff --git a/include/hw/xen/xen_backend.h
> b/include/hw/xen/xen_backend.h
> > index 3b4125e..f2d5489 100644
> > --- a/include/hw/xen/xen_backend.h
> > +++ b/include/hw/xen/xen_backend.h
> > @@ -15,6 +15,8 @@ struct XenDevice;
> >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> >  /* don't expect frontend doing correct state transitions (aka console
> quirk) */
> >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > +/*dev backend is stubdom*/
> > +#define DEVOPS_FLAG_STUBDOM_BE    4
> >
> >  struct XenDevOps {
> >      size_t    size;
> > @@ -26,6 +28,8 @@ struct XenDevOps {
> >      void      (*event)(struct XenDevice *xendev);
> >      void      (*disconnect)(struct XenDevice *xendev);
> >      int       (*free)(struct XenDevice *xendev);
> > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> count);
> > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> *count);
> >      void      (*backend_changed)(struct XenDevice *xendev, const
> char *node);
> >      void      (*frontend_changed)(struct XenDevice *xendev, const
> char *node);
> >  };
> > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> *xendev);
> >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char
> *fmt, ...)
> >      GCC_FMT_ATTR(3, 4);
> >
> > +/*Xen stubdom vtpm*/
> > +int xen_fe_register(const char *type, struct XenDevOps *ops);
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom);
> > +int xen_vtpm_send(unsigned char *buf, size_t count);
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> > +
> >  /* actual backend drivers */
> >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> */
> >  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c
> */
> >  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
> >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> */
> >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> */
> > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> xen_stubdom_vtpm.c*/
> >
> >  void xen_init_display(int domid);
> >
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 95612a4..fb43084 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void
> *logger, void *dombuild_logger,
> >      return xc_interface_open(logger, dombuild_logger, open_flags);
> >  }
> >
> > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > +                                           unsigned int open_flags)
> > +{
> > +    return xc_gntshr_open(logger, open_flags);
> > +}
> > +
> >  /* FIXME There is now way to have the xen fd */
> >  static inline int xc_fd(xc_interface *xen_xc)
> >  {
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 21f1cbb..854b8f7 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >      int i, rc;
> >      unsigned long ioreq_pfn;
> >      unsigned long bufioreq_evtchn;
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    unsigned long stubdom_vtpm = 0;
> > +#endif
> > +
> >      XenIOState *state;
> >
> >      state = g_malloc0(sizeof (XenIOState));
> > @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >          fprintf(stderr, "%s: xen backend core setup failed\n",
> __FUNCTION__);
> >          return -1;
> >      }
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    xc_get_hvm_param(xen_xc, xen_domid,
> HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> 
> HVM params are used for domain wide configuration, visible to the guest
> too.  I don't think that this parameter is actually supposed to be guest
> visible?
> If not, it should be passed to QEMU via command line or hmp/qmp.
> 
Thanks.
Maybe it does not make sense by registering it in this way. I will try to find out the
Other way to register via command line or hmp/qmp. 

> 
> > +    if (stubdom_vtpm) {
> > +        xen_fe_register("vtpm", &xen_vtpmdev_ops);
> > +    }
> > +#endif
> > +
> >      xen_be_register("console", &xen_console_ops);
> >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> >      xen_be_register("qdisk", &xen_blkdev_ops);
> > --
> > 1.8.3.2
> >

Agree with your comments. I will modify it carefully as your comments. 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:45:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:45:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHMQ-0006VR-AS; Tue, 25 Nov 2014 14:44:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XtHMP-0006V8-2F
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:44:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	2E/9D-07724-8E594745; Tue, 25 Nov 2014 14:44:56 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416926690!13756292!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10585 invoked from network); 25 Nov 2014 14:44:51 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-8.tower-31.messagelabs.com with SMTP;
	25 Nov 2014 14:44:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 25 Nov 2014 06:37:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,455,1413270000"; d="scan'208";a="628010069"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by fmsmga001.fm.intel.com with ESMTP; 25 Nov 2014 06:44:32 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 25 Nov 2014 22:44:30 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Tue, 25 Nov 2014 22:44:29 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend driver
Thread-Index: AQHQCAHoGXWQuRHWjU6e4Zjz5rVgr5xxY//A
Date: Tue, 25 Nov 2014 14:44:29 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E8417C4@SHSMSX101.ccr.corp.intel.com>
References: <1416802256-9928-1-git-send-email-quan.xu@intel.com>
	<alpine.DEB.2.02.1411241544410.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411241544410.2675@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
 frontend driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Tuesday, November 25, 2014 12:16 AM
> To: Xu, Quan
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> stefano.stabellini@eu.citrix.com
> Subject: Re: [v2 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend
> driver
> 
> On Sun, 23 Nov 2014, Quan Xu wrote:
> > This drvier transfers any request/repond between TPM xenstubdoms
> > driver and Xen vTPM stubdom, and facilitates communications between
> > Xen vTPM stubdom domain and vTPM xenstubdoms driver
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> 
> This patch needs a better description, see my past request:
> 
> http://marc.info/?l=xen-devel&m=141501570709022&w=2
> 
> 
> >  hw/tpm/Makefile.objs         |   1 +
> >  hw/tpm/xen_stubdom_vtpm.c    | 321
> +++++++++++++++++++++++++++++++++++++++++++
> >  hw/xen/xen_backend.c         | 272
> ++++++++++++++++++++++++++++++++++++
> >  include/hw/xen/xen_backend.h |  11 ++
> >  include/hw/xen/xen_common.h  |   6 +
> >  xen-hvm.c                    |  13 ++
> >  6 files changed, 624 insertions(+)
> >  create mode 100644 hw/tpm/xen_stubdom_vtpm.c
> >
> > diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs index
> > 99f5983..87efb01 100644
> > --- a/hw/tpm/Makefile.objs
> > +++ b/hw/tpm/Makefile.objs
> > @@ -1,2 +1,3 @@
> >  common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
> >  common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
> > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_stubdom_vtpm.o
> > diff --git a/hw/tpm/xen_stubdom_vtpm.c
> b/hw/tpm/xen_stubdom_vtpm.c new
> > file mode 100644 index 0000000..4fd6053
> > --- /dev/null
> > +++ b/hw/tpm/xen_stubdom_vtpm.c
> 
> I would just call it xen_vtpm_frontend.c
> 
> I don't think that the fact that the backend is probably run in a
> stubdom is relevant here. The only thing that matter is that this is a
> PV frontend.
> 
> 
> Also if this is the vtpm specific frontend, where is the file that
> introduces the generic frontend registration framework, as previously
> discussed?
> 
> http://marc.info/?l=xen-devel&m=141528935207946&w=2
> 
> I think we should have a hw/xen/xen_frontend.c file, introducing
> xen_fe_register etc, and a separate hw/tpm/xen_stubdom_vtpm.c with the
> vtpm specific stuff.
> 
> 
> > @@ -0,0 +1,321 @@
> > +/*
> > + * Connect to Xen vTPM stubdom domain
> > + *
> > + *  Copyright (c) 2014 Intel Corporation
> > + *  Authors:
> > + *    Quan Xu <quan.xu@intel.com>
> > + *
> > + * 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 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, see
> <http://www.gnu.org/licenses/>
> > + */
> > +
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <stdarg.h>
> > +#include <string.h>
> > +#include <unistd.h>
> > +#include <signal.h>
> > +#include <inttypes.h>
> > +#include <time.h>
> > +#include <fcntl.h>
> > +#include <errno.h>
> > +#include <sys/ioctl.h>
> > +#include <sys/types.h>
> > +#include <sys/stat.h>
> > +#include <sys/mman.h>
> > +#include <sys/uio.h>
> > +
> > +#include "hw/hw.h"
> > +#include "block/aio.h"
> > +#include "hw/xen/xen_backend.h"
> > +
> > +enum tpmif_state {
> > +    TPMIF_STATE_IDLE,        /* no contents / vTPM idle / cancel
> complete */
> > +    TPMIF_STATE_SUBMIT,      /* request ready / vTPM working */
> > +    TPMIF_STATE_FINISH,      /* response ready / vTPM idle */
> > +    TPMIF_STATE_CANCEL,      /* cancel requested / vTPM working */
> > +};
> > +
> > +static AioContext *vtpm_aio_ctx;
> > +
> > +enum status_bits {
> > +    VTPM_STATUS_RUNNING  = 0x1,
> > +    VTPM_STATUS_IDLE     = 0x2,
> > +    VTPM_STATUS_RESULT   = 0x4,
> > +    VTPM_STATUS_CANCELED = 0x8,
> > +};
> > +
> > +struct tpmif_shared_page {
> > +    uint32_t length;         /* request/response length in bytes */
> > +
> > +    uint8_t  state;           /* enum tpmif_state */
> > +    uint8_t  locality;        /* for the current request */
> > +    uint8_t  pad;             /* should be zero */
> > +
> > +    uint8_t  nr_extra_pages;  /* extra pages for long packets; may be
> zero */
> > +    uint32_t extra_pages[0]; /* grant IDs; length is actually
> nr_extra_pages */
> > +};
> > +
> > +struct XenVtpmDev {
> > +    struct XenDevice xendev;  /* must be first */
> > +    struct           tpmif_shared_page *shr;
> > +    xc_gntshr        *xen_xcs;
> > +    int              ring_ref;
> > +    int              bedomid;
> > +    QEMUBH           *sr_bh;
> > +};
> > +
> > +static uint8_t vtpm_status(struct XenVtpmDev *vtpmdev)
> > +{
> > +    switch (vtpmdev->shr->state) {
> > +    case TPMIF_STATE_IDLE:
> > +    case TPMIF_STATE_FINISH:
> > +        return VTPM_STATUS_IDLE;
> > +    case TPMIF_STATE_SUBMIT:
> > +    case TPMIF_STATE_CANCEL:
> > +        return VTPM_STATUS_RUNNING;
> > +    default:
> > +        return 0;
> > +    }
> > +}
> > +
> > +static int xenbus_switch_state(struct XenDevice *xendev, enum
> xenbus_state xbus)
> > +{
> > +    xs_transaction_t xbt = XBT_NULL;
> > +
> > +    if (xendev->fe_state == xbus) {
> > +        return 0;
> > +    }
> > +
> > +    xendev->fe_state = xbus;
> > +
> > +retry_transaction:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto retry_transaction;
> > +        }
> > +    }
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> 
> This would probably end up in xen_frontend.c
> 
> 
> > +static bool vtpm_aio_wait(AioContext *ctx)
> > +{
> > +    return aio_poll(ctx, true);
> > +}
> > +
> > +static void sr_bh_handler(void *opaque)
> > +{
> > +}
> > +
> > +static int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t
> *count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset;
> > +
> > +    if (shr->state == TPMIF_STATE_IDLE) {
> > +        return -ECANCELED;
> > +    }
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpm_aio_ctx);
> > +    }
> > +
> > +    offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +    memcpy(buf, offset + (uint8_t *)shr, shr->length);
> > +    *count = shr->length;
> > +
> > +    return 0;
> > +}
> > +
> > +static int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t
> count)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    struct tpmif_shared_page *shr = vtpmdev->shr;
> > +    unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpm_aio_ctx);
> > +    }
> > +
> > +    memcpy(offset + (uint8_t *)shr, buf, count);
> > +    shr->length = count;
> > +    barrier();
> > +    shr->state = TPMIF_STATE_SUBMIT;
> > +    xen_wmb();
> > +    xen_be_send_notify(&vtpmdev->xendev);
> > +
> > +    while (vtpm_status(vtpmdev) != VTPM_STATUS_IDLE) {
> > +        vtpm_aio_wait(vtpm_aio_ctx);
> > +    }
> > +
> > +    return count;
> > +}
> > +
> > +static int vtpm_initialise(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    xs_transaction_t xbt = XBT_NULL;
> > +    unsigned int ring_ref;
> > +
> > +    vtpmdev->xendev.fe = xenstore_read_be_str(&vtpmdev->xendev,
> "frontend");
> > +    if (vtpmdev->xendev.fe == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /* Get backend domid */
> > +    if (xenstore_read_fe_int(&vtpmdev->xendev, "backend-id",
> > +                             &vtpmdev->bedomid)) {
> > +        return -1;
> > +    }
> > +
> > +    /*alloc share page*/
> > +    vtpmdev->shr = xc_gntshr_share_pages(vtpmdev->xen_xcs,
> vtpmdev->bedomid, 1,
> > +                                         &ring_ref,
> PROT_READ|PROT_WRITE);
> > +    vtpmdev->ring_ref = ring_ref;
> > +    if (vtpmdev->shr == NULL) {
> > +        return -1;
> > +    }
> > +
> > +    /*Create event channel */
> > +    if (xen_be_alloc_unbound(&vtpmdev->xendev, 0,
> vtpmdev->bedomid)) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +        return -1;
> > +    }
> > +
> > +    xc_evtchn_unmask(vtpmdev->xendev.evtchndev,
> > +                     vtpmdev->xendev.local_port);
> > +
> > +again:
> > +    xbt = xs_transaction_start(xenstore);
> > +    if (xbt == XBT_NULL) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "ring-ref",
> > +                           vtpmdev->ring_ref)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "event-channel",
> > +                           vtpmdev->xendev.local_port)) {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    /* Publish protocol v2 feature */
> > +    if (xenstore_write_int(vtpmdev->xendev.fe, "feature-protocol-v2", 1))
> {
> > +        goto abort_transaction;
> > +    }
> > +
> > +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> > +        if (errno == EAGAIN) {
> > +            goto again;
> > +        }
> > +    }
> > +    /* Tell vtpm backend that we are ready */
> > +    xenbus_switch_state(&vtpmdev->xendev, XenbusStateInitialised);
> > +
> > +    return 0;
> > +
> > +abort_transaction:
> > +    xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    xs_transaction_end(xenstore, xbt, 1);
> > +    return -1;
> > +}
> > +
> > +static void vtpm_backend_changed(struct XenDevice *xendev, const char
> *node)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    int be_state;
> > +
> > +    if (strcmp(node, "state") == 0) {
> > +        xenstore_read_be_int(&vtpmdev->xendev, node, &be_state);
> > +        switch (be_state) {
> > +        case XenbusStateConnected:
> > +            /*TODO*/
> > +            break;
> > +        case XenbusStateClosing:
> > +        case XenbusStateClosed:
> > +            xenbus_switch_state(&vtpmdev->xendev,
> XenbusStateClosing);
> > +            break;
> > +        default:
> > +            break;
> > +        }
> > +    }
> > +}
> 
> This would probably end up in xen_backend.c
> 
> 
> > +static int vtpm_free(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +    aio_poll(vtpm_aio_ctx, false);
> > +    qemu_bh_delete(vtpmdev->sr_bh);
> > +    if (vtpmdev->shr) {
> > +        xc_gntshr_munmap(vtpmdev->xen_xcs, vtpmdev->shr, 1);
> > +    }
> > +    xc_interface_close(vtpmdev->xen_xcs);
> > +    return 0;
> > +}
> > +
> > +static void vtpm_alloc(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    vtpm_aio_ctx = aio_context_new(NULL);
> > +    if (vtpm_aio_ctx == NULL) {
> > +        return;
> > +    }
> > +    vtpmdev->sr_bh = aio_bh_new(vtpm_aio_ctx, sr_bh_handler,
> vtpmdev);
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +    vtpmdev->xen_xcs = xen_xc_gntshr_open(0, 0);
> > +}
> > +
> > +static void vtpm_event(struct XenDevice *xendev)
> > +{
> > +    struct XenVtpmDev *vtpmdev = container_of(xendev, struct
> XenVtpmDev,
> > +                                              xendev);
> > +
> > +    qemu_bh_schedule(vtpmdev->sr_bh);
> > +}
> > +
> > +struct XenDevOps xen_vtpmdev_ops = {
> > +    .size             = sizeof(struct XenVtpmDev),
> > +    .flags            = DEVOPS_FLAG_IGNORE_STATE |
> > +                        DEVOPS_FLAG_STUBDOM_BE,
> > +    .event            = vtpm_event,
> > +    .free             = vtpm_free,
> > +    .alloc            = vtpm_alloc,
> > +    .initialise       = vtpm_initialise,
> > +    .backend_changed  = vtpm_backend_changed,
> > +    .recv             = vtpm_recv,
> > +    .send             = vtpm_send,
> 
> I don't think that recv and send should be part of the XenDevOps
> interface. This interface is supposed to be a generic interface to
> implement a Xen PV backend (or frontend maybe). recv and send are
> specific to the vtpm driver, so they should not be here.
> 
> 
> > +};
> > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> > index b2cb22b..5e7cfe5 100644
> > --- a/hw/xen/xen_backend.c
> > +++ b/hw/xen/xen_backend.c
> > @@ -194,6 +194,32 @@ int xen_be_set_state(struct XenDevice *xendev,
> enum xenbus_state state)
> >      return 0;
> >  }
> >
> > +/*get stubdom backend*/
> > +static char *xen_stubdom_be(const char *type, int dom, int dev)
> > +{
> > +    char *val, *domu;
> > +    char path[XEN_BUFSIZE];
> > +    unsigned int len, ival;
> > +
> > +    /*front domu*/
> > +    domu = xs_get_domain_path(xenstore, dom);
> > +    snprintf(path, sizeof(path), "%s/device/%s/%d/backend-id",
> > +             domu, type, dev);
> > +    g_free(domu);
> > +
> > +    val = xs_read(xenstore, 0, path, &len);
> > +    if (!val || 1 != sscanf(val, "%d", &ival)) {
> > +        g_free(val);
> > +        return NULL;
> > +    }
> > +    g_free(val);
> > +
> > +    /*backend domu*/
> > +    domu = xs_get_domain_path(xenstore, ival);
> > +
> > +    return domu;
> > +}
> 
> This looks like a function to find the backend path. Instead of
> duplicating functionalities with xenstore_read_be_str, we should just
> make sure that xenstore_read_be_str works with backends other than dom0.
> 
> If we really do need a new function, that I don't think is the case, it
> should be as generic as possible, so it should be called something like
> xenstore_read_be_str and be in xen_frontend.c.
> 
> 
> >  /* ------------------------------------------------------------- */
> >
> >  struct XenDevice *xen_be_find_xendev(const char *type, int dom, int
> dev)
> > @@ -273,6 +299,68 @@ static struct XenDevice
> *xen_be_get_xendev(const char *type, int dom, int dev,
> >  }
> >
> >  /*
> > + * get xen stubdom backend device, allocate a new one if it doesn't exist.
> > + */
> > +static struct XenDevice *xen_stubdom_be_get_xendev(const char *type,
> > +                         int dom, int dev, struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char *stub;
> > +
> > +    xendev = xen_be_find_xendev(type, dom, dev);
> > +    if (xendev) {
> > +        return xendev;
> > +    }
> > +
> > +    /* init new xendev */
> > +    xendev = g_malloc0(ops->size);
> > +    xendev->type  = type;
> > +    xendev->dom   = dom;
> > +    xendev->dev   = dev;
> > +    xendev->ops   = ops;
> > +
> > +    if (ops->flags & DEVOPS_FLAG_STUBDOM_BE) {
> > +        stub = xen_stubdom_be(xendev->type, xendev->dom,
> xendev->dev);
> > +        snprintf(xendev->be, sizeof(xendev->be),
> "%s/backend/%s/%d/%d",
> > +                 stub, xendev->type, xendev->dom, xendev->dev);
> > +        g_free(stub);
> > +    }
> > +    snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> > +             xendev->type, xendev->dev);
> > +
> > +    xendev->debug      = debug;
> > +    xendev->local_port = -1;
> > +
> > +    xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
> > +    if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
> > +        xen_be_printf(NULL, 0, "can't open evtchn device\n");
> > +        g_free(xendev);
> > +        return NULL;
> > +    }
> > +    fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
> > +
> > +    if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
> > +        xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
> > +        if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
> > +            xen_be_printf(NULL, 0, "can't open gnttab device\n");
> > +            xc_evtchn_close(xendev->evtchndev);
> > +            g_free(xendev);
> > +            return NULL;
> > +        }
> > +    } else {
> > +        xendev->gnttabdev = XC_HANDLER_INITIAL_VALUE;
> > +    }
> > +
> > +    QTAILQ_INSERT_TAIL(&xendevs, xendev, next);
> > +
> > +    if (xendev->ops->alloc) {
> > +        xendev->ops->alloc(xendev);
> > +    }
> > +
> > +    return xendev;
> > +}
> 
> Same here: this should be called xen_fe_get_xendev and be in
> xen_frontend.c
> 
> Nothing should be called *_stubdom_*: we don't care about stubdoms in
> QEMU, only about frontends and backends.
> 
> 
> > +/*
> >   * release xen backend device.
> >   */
> >  static struct XenDevice *xen_be_del_xendev(int dom, int dev)
> > @@ -611,6 +699,47 @@ static int xenstore_scan(const char *type, int
> dom, struct XenDevOps *ops)
> >      return 0;
> >  }
> >
> > +static void stubdom_update_be(char *watch, char *type, int dom,
> > +                              struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE];
> > +    char *ptr, *bepath;
> > +    unsigned int len, dev;
> > +
> > +    if (!(ops->flags & DEVOPS_FLAG_STUBDOM_BE)) {
> > +        return;
> > +    }
> > +
> > +    len = snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
> > +    ptr = strstr(watch, path);
> > +    if (ptr == NULL) {
> > +        return;
> > +    }
> > +
> > +    if (sscanf(ptr+len, "/%u/%255s", &dev, path) != 2) {
> > +        strcpy(path, "");
> > +        if (sscanf(ptr+len, "/%u", &dev) != 1) {
> > +            dev = -1;
> > +        }
> > +    }
> > +
> > +    if (dev == -1) {
> > +        return;
> > +    }
> > +
> > +    xendev = xen_be_get_xendev(type, dom, dev, ops);
> > +    if (xendev != NULL) {
> > +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> > +        if (bepath == NULL) {
> > +            xen_be_del_xendev(dom, dev);
> > +        } else {
> > +            free(bepath);
> > +            xen_be_backend_changed(xendev, path);
> > +        }
> > +    }
> > +}
> 
> ditto
> 
> 
> >  static void xenstore_update_be(char *watch, char *type, int dom,
> >                                 struct XenDevOps *ops)
> >  {
> > @@ -681,6 +810,10 @@ static void xenstore_update(void *unused)
> >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> >      }
> > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%"
> PRIxPTR,
> > +               &type, &dom, &ops) == 3) {
> > +        stubdom_update_be(vec[XS_WATCH_PATH], (void *)type, dom,
> (void *)ops);
> > +    }
> >
> >  cleanup:
> >      free(vec);
> > @@ -732,11 +865,114 @@ err:
> >      return -1;
> >  }
> >
> > +static int stubdom_check(struct XenDevice *xendev, uint32_t domid,
> > +                         int handle)
> > +{
> > +    int rc = 0;
> > +
> > +    if (xendev->ops->init) {
> > +        rc = xendev->ops->init(xendev);
> > +    }
> > +
> > +    if (rc != 0) {
> > +        xen_be_printf(xendev, 0, "xendev %s init error\n",
> > +                     xendev->name);
> > +       goto err;
> > +    }
> > +
> > +    if (xendev->ops->initialise) {
> > +        rc = xendev->ops->initialise(xendev);
> > +    }
> > +
> > +    if (rc != 0) {
> > +        xen_be_printf(xendev, 0, "xendev %s initialise error\n",
> > +                     xendev->name);
> > +       goto err;
> > +    }
> > +
> > +    if (xendev->ops->connected) {
> > +        xendev->ops->connected(xendev);
> > +    }
> > +
> > +    return rc;
> > +
> > +err:
> > +    xen_be_del_xendev(domid, handle);
> > +    return -1;
> > +}
> 
> ditto
> 
> 
> > +static int xenstore_stubdom_scan(const char *type, uint32_t domid,
> > +                                 struct XenDevOps *ops)
> > +{
> > +    struct XenDevice *xendev;
> > +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> > +    char *domu;
> > +    unsigned int cdev, j;
> > +    char **dev = NULL;
> > +
> > +    /*stubom : /local/domain/ID */
> > +    domu = xs_get_domain_path(xenstore, domid);
> > +    snprintf(path, sizeof(path), "%s/device/%s",
> > +             domu, type);
> > +    free(domu);
> > +    dev = xs_directory(xenstore, 0, path, &cdev);
> > +    if (dev == NULL) {
> > +        return 0;
> > +    }
> > +
> > +    for (j = 0; j < cdev; j++) {
> > +        xendev = xen_stubdom_be_get_xendev(type, domid,
> > +                                           atoi(dev[j]), ops);
> > +        if (xendev == NULL) {
> > +            xen_be_printf(xendev, 0, "xendev is NULL.\n");
> > +            continue;
> > +        }
> > +
> > +        /* simplify QEMU side, a thread is running in Xen stubdom,
> which will
> > +         * connect frontend when the frontend is initialised.
> > +         */
> > +        if (stubdom_check(xendev, domid, atoi(dev[j])) < 0) {
> > +            xen_be_printf(xendev, 0, "xendev stubdom_check
> error.\n");
> > +            continue;
> > +        }
> > +
> > +        /*setup watch*/
> > +        snprintf(token, sizeof(token), "stub:%p:%d:%p",
> > +                 type, domid, xendev->ops);
> > +        if (!xs_watch(xenstore, xendev->be, token)) {
> > +            xen_be_printf(xendev, 0, "xs_watch failed.\n");
> > +            continue;
> > +        }
> > +    }
> > +
> > +    free(dev);
> > +    return 0;
> > +}
> 
> ditto
> 
> 
> > +int xen_fe_register(const char *type, struct XenDevOps *ops)
> > +{
> > +    return xenstore_stubdom_scan(type, xen_domid, ops);
> > +}
> > +
> >  int xen_be_register(const char *type, struct XenDevOps *ops)
> >  {
> >      return xenstore_scan(type, xen_domid, ops);
> >  }
> >
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom)
> > +{
> > +    xendev->local_port =
> xc_evtchn_bind_unbound_port(xendev->evtchndev,
> > +
> remote_dom);
> > +    if (xendev->local_port == -1) {
> > +        xen_be_printf(xendev, 0, "xc_evtchn_alloc_unbound failed\n");
> > +        return -1;
> > +    }
> > +    xen_be_printf(xendev, 2, "bind evtchn port %d\n",
> xendev->local_port);
> > +    qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> > +                        xen_be_evtchn_event, NULL, xendev);
> > +    return 0;
> > +}
> > +
> >  int xen_be_bind_evtchn(struct XenDevice *xendev)
> >  {
> >      if (xendev->local_port != -1) {
> > @@ -770,6 +1006,42 @@ int xen_be_send_notify(struct XenDevice
> *xendev)
> >      return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
> >  }
> >
> > +int xen_vtpm_send(unsigned char *buf, size_t count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->send) {
> > +        rc = xendev->ops->send(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> > +
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count)
> > +{
> > +    struct XenDevice *xendev;
> > +    int rc = -1;
> > +
> > +    xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +    if (xendev == NULL) {
> > +        xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +        return -1;
> > +    }
> > +
> > +    if (xendev->ops->recv) {
> > +        xendev->ops->recv(xendev, buf, count);
> > +    }
> > +
> > +    return rc;
> > +}
> 
> I don't these we should have these two functions here, they don't belong
> to the QEMU internal Xen backend (or frontend) interface.
> 
> 
> >  /*
> >   * msg_level:
> >   *  0 == errors (stderr + logfile).
> > diff --git a/include/hw/xen/xen_backend.h
> b/include/hw/xen/xen_backend.h
> > index 3b4125e..f2d5489 100644
> > --- a/include/hw/xen/xen_backend.h
> > +++ b/include/hw/xen/xen_backend.h
> > @@ -15,6 +15,8 @@ struct XenDevice;
> >  #define DEVOPS_FLAG_NEED_GNTDEV   1
> >  /* don't expect frontend doing correct state transitions (aka console
> quirk) */
> >  #define DEVOPS_FLAG_IGNORE_STATE  2
> > +/*dev backend is stubdom*/
> > +#define DEVOPS_FLAG_STUBDOM_BE    4
> >
> >  struct XenDevOps {
> >      size_t    size;
> > @@ -26,6 +28,8 @@ struct XenDevOps {
> >      void      (*event)(struct XenDevice *xendev);
> >      void      (*disconnect)(struct XenDevice *xendev);
> >      int       (*free)(struct XenDevice *xendev);
> > +    int       (*send)(struct XenDevice *xendev, uint8_t* buf, size_t
> count);
> > +    int       (*recv)(struct XenDevice *xendev, uint8_t* buf, size_t
> *count);
> >      void      (*backend_changed)(struct XenDevice *xendev, const
> char *node);
> >      void      (*frontend_changed)(struct XenDevice *xendev, const
> char *node);
> >  };
> > @@ -91,12 +95,19 @@ int xen_be_send_notify(struct XenDevice
> *xendev);
> >  void xen_be_printf(struct XenDevice *xendev, int msg_level, const char
> *fmt, ...)
> >      GCC_FMT_ATTR(3, 4);
> >
> > +/*Xen stubdom vtpm*/
> > +int xen_fe_register(const char *type, struct XenDevOps *ops);
> > +int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int
> remote_dom);
> > +int xen_vtpm_send(unsigned char *buf, size_t count);
> > +int xen_vtpm_recv(unsigned char *buf, size_t *count);
> > +
> >  /* actual backend drivers */
> >  extern struct XenDevOps xen_console_ops;      /* xen_console.c
> */
> >  extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.c
> */
> >  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
> >  extern struct XenDevOps xen_blkdev_ops;       /* xen_disk.c
> */
> >  extern struct XenDevOps xen_netdev_ops;       /* xen_nic.c
> */
> > +extern struct XenDevOps xen_vtpmdev_ops;      /*
> xen_stubdom_vtpm.c*/
> >
> >  void xen_init_display(int domid);
> >
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 95612a4..fb43084 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -130,6 +130,12 @@ static inline XenXC xen_xc_interface_open(void
> *logger, void *dombuild_logger,
> >      return xc_interface_open(logger, dombuild_logger, open_flags);
> >  }
> >
> > +static inline xc_gntshr *xen_xc_gntshr_open(void *logger,
> > +                                           unsigned int open_flags)
> > +{
> > +    return xc_gntshr_open(logger, open_flags);
> > +}
> > +
> >  /* FIXME There is now way to have the xen fd */
> >  static inline int xc_fd(xc_interface *xen_xc)
> >  {
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 21f1cbb..854b8f7 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -1067,6 +1067,11 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >      int i, rc;
> >      unsigned long ioreq_pfn;
> >      unsigned long bufioreq_evtchn;
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    unsigned long stubdom_vtpm = 0;
> > +#endif
> > +
> >      XenIOState *state;
> >
> >      state = g_malloc0(sizeof (XenIOState));
> > @@ -1169,6 +1174,14 @@ int xen_hvm_init(ram_addr_t
> *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
> >          fprintf(stderr, "%s: xen backend core setup failed\n",
> __FUNCTION__);
> >          return -1;
> >      }
> > +
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    xc_get_hvm_param(xen_xc, xen_domid,
> HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> 
> HVM params are used for domain wide configuration, visible to the guest
> too.  I don't think that this parameter is actually supposed to be guest
> visible?
> If not, it should be passed to QEMU via command line or hmp/qmp.
> 
Thanks.
Maybe it does not make sense by registering it in this way. I will try to find out the
Other way to register via command line or hmp/qmp. 

> 
> > +    if (stubdom_vtpm) {
> > +        xen_fe_register("vtpm", &xen_vtpmdev_ops);
> > +    }
> > +#endif
> > +
> >      xen_be_register("console", &xen_console_ops);
> >      xen_be_register("vkbd", &xen_kbdmouse_ops);
> >      xen_be_register("qdisk", &xen_blkdev_ops);
> > --
> > 1.8.3.2
> >

Agree with your comments. I will modify it carefully as your comments. 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:51:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14: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 1XtHSR-0006s8-Iv; Tue, 25 Nov 2014 14:51:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtHSQ-0006s3-12
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 14:51:10 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	C9/25-02699-D5794745; Tue, 25 Nov 2014 14:51:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416927068!14179741!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23236 invoked from network); 25 Nov 2014 14:51:08 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:51:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 14:51:07 +0000
Message-Id: <5474A568020000780004AB93@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 14:51:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	<1412687413-22818-4-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1412687413-22818-4-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 3/8] xen: introduce
	XEN_DOMCTL_set_recipient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.10.14 at 15:10, <vkuznets@redhat.com> wrote:
> New operation sets the 'recipient' domain which will recieve all
> memory pages from a particular domain when these pages are freed.



> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1152,6 +1152,33 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>      }
>      break;
>  
> +    case XEN_DOMCTL_set_recipient:
> +    {
> +        struct domain *recipient_dom;
> +
> +        if ( op->u.recipient.recipient == DOMID_INVALID )
> +        {
> +            if ( d->recipient )
> +            {
> +                put_domain(d->recipient);
> +            }

Please drop pointless braces like these and ...

> +            d->recipient = NULL;
> +            break;
> +        }
> +
> +        recipient_dom = get_domain_by_id(op->u.recipient.recipient);
> +        if ( recipient_dom == NULL )
> +        {
> +            ret = -ESRCH;
> +            break;
> +        }
> +        else
> +        {
> +            d->recipient = recipient_dom;
> +        }

... the pointless else-s/break-s like here.

> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1707,6 +1707,7 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>  {
>      struct domain *d = page_get_owner(pg);
>      unsigned int i;
> +    unsigned long mfn, gmfn;
>      bool_t drop_dom_ref;
>  
>      ASSERT(!in_irq());
> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>              scrub = 1;
>          }
>  
> -        if ( unlikely(scrub) )
> -            for ( i = 0; i < (1 << order); i++ )
> -                scrub_one_page(&pg[i]);
> +        if ( !d || !d->recipient || d->recipient->is_dying )
> +        {
> +            if ( unlikely(scrub) )
> +                for ( i = 0; i < (1 << order); i++ )
> +                    scrub_one_page(&pg[i]);
>  
> -        free_heap_pages(pg, order);
> +            free_heap_pages(pg, order);
> +        }
> +        else
> +        {
> +            mfn = page_to_mfn(pg);
> +            gmfn = mfn_to_gmfn(d, mfn);
> +
> +            page_set_owner(pg, NULL);
> +            assign_pages(d->recipient, pg, order, 0);

This can fail.

> +
> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
> +            {
> +                gdprintk(XENLOG_INFO, "Failed to add page to domain's physmap"
> +                         " mfn: %lx\n", mfn);

The current domain/vCPU don't matter here afaict, hence no need
for gdprintk(). The source and/or recipient domain do matter though,
hence printing either or both would seem desirable. The gMFN may
be relevant for diagnostic purposes too. Hence e.g.

                printk(XENLOG_G_INFO "Failed to add MFN %lx (GFN %lx) to Dom%d's physmap\n"
                       mfn, gmfn, d->recipient->domain_id);

What's worse though is that you don't guard against
XEN_DOMCTL_set_recipient zapping d->recipient. If that really is
necessary to be supported, some synchronization will be needed.

And finally - what's the intended protocol for the tool stack to
know that all pages got transferred (and hence the new domain
can be launched)?

> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -965,6 +965,23 @@ struct xen_domctl_vnuma {
>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
>  
> +/*
> + * XEN_DOMCTL_set_recipient - sets the 'recipient' domain which will recieve
> + * all the domain's memory after its death or when and memory page from
> + * domain's heap is being freed.

So this specifically allows for this to happen on a non-dying domain.
Why, i.e. what's the intended usage scenario? If not really needed,
please remove this and verify in the handling that the source domain
is dying.

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -366,6 +366,7 @@ struct domain
>      bool_t           is_privileged;
>      /* Which guest this guest has privileges on */
>      struct domain   *target;
> +    struct domain   *recipient;

Please add a brief comment similar to the one for "target".

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:51:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14: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 1XtHSR-0006s8-Iv; Tue, 25 Nov 2014 14:51:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtHSQ-0006s3-12
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 14:51:10 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	C9/25-02699-D5794745; Tue, 25 Nov 2014 14:51:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416927068!14179741!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23236 invoked from network); 25 Nov 2014 14:51:08 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:51:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 14:51:07 +0000
Message-Id: <5474A568020000780004AB93@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 14:51:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	<1412687413-22818-4-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1412687413-22818-4-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 3/8] xen: introduce
	XEN_DOMCTL_set_recipient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.10.14 at 15:10, <vkuznets@redhat.com> wrote:
> New operation sets the 'recipient' domain which will recieve all
> memory pages from a particular domain when these pages are freed.



> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1152,6 +1152,33 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>      }
>      break;
>  
> +    case XEN_DOMCTL_set_recipient:
> +    {
> +        struct domain *recipient_dom;
> +
> +        if ( op->u.recipient.recipient == DOMID_INVALID )
> +        {
> +            if ( d->recipient )
> +            {
> +                put_domain(d->recipient);
> +            }

Please drop pointless braces like these and ...

> +            d->recipient = NULL;
> +            break;
> +        }
> +
> +        recipient_dom = get_domain_by_id(op->u.recipient.recipient);
> +        if ( recipient_dom == NULL )
> +        {
> +            ret = -ESRCH;
> +            break;
> +        }
> +        else
> +        {
> +            d->recipient = recipient_dom;
> +        }

... the pointless else-s/break-s like here.

> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1707,6 +1707,7 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>  {
>      struct domain *d = page_get_owner(pg);
>      unsigned int i;
> +    unsigned long mfn, gmfn;
>      bool_t drop_dom_ref;
>  
>      ASSERT(!in_irq());
> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>              scrub = 1;
>          }
>  
> -        if ( unlikely(scrub) )
> -            for ( i = 0; i < (1 << order); i++ )
> -                scrub_one_page(&pg[i]);
> +        if ( !d || !d->recipient || d->recipient->is_dying )
> +        {
> +            if ( unlikely(scrub) )
> +                for ( i = 0; i < (1 << order); i++ )
> +                    scrub_one_page(&pg[i]);
>  
> -        free_heap_pages(pg, order);
> +            free_heap_pages(pg, order);
> +        }
> +        else
> +        {
> +            mfn = page_to_mfn(pg);
> +            gmfn = mfn_to_gmfn(d, mfn);
> +
> +            page_set_owner(pg, NULL);
> +            assign_pages(d->recipient, pg, order, 0);

This can fail.

> +
> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
> +            {
> +                gdprintk(XENLOG_INFO, "Failed to add page to domain's physmap"
> +                         " mfn: %lx\n", mfn);

The current domain/vCPU don't matter here afaict, hence no need
for gdprintk(). The source and/or recipient domain do matter though,
hence printing either or both would seem desirable. The gMFN may
be relevant for diagnostic purposes too. Hence e.g.

                printk(XENLOG_G_INFO "Failed to add MFN %lx (GFN %lx) to Dom%d's physmap\n"
                       mfn, gmfn, d->recipient->domain_id);

What's worse though is that you don't guard against
XEN_DOMCTL_set_recipient zapping d->recipient. If that really is
necessary to be supported, some synchronization will be needed.

And finally - what's the intended protocol for the tool stack to
know that all pages got transferred (and hence the new domain
can be launched)?

> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -965,6 +965,23 @@ struct xen_domctl_vnuma {
>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
>  
> +/*
> + * XEN_DOMCTL_set_recipient - sets the 'recipient' domain which will recieve
> + * all the domain's memory after its death or when and memory page from
> + * domain's heap is being freed.

So this specifically allows for this to happen on a non-dying domain.
Why, i.e. what's the intended usage scenario? If not really needed,
please remove this and verify in the handling that the source domain
is dying.

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -366,6 +366,7 @@ struct domain
>      bool_t           is_privileged;
>      /* Which guest this guest has privileges on */
>      struct domain   *target;
> +    struct domain   *recipient;

Please add a brief comment similar to the one for "target".

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:55:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:55:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHWI-00073F-7f; Tue, 25 Nov 2014 14:55:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtHWH-000739-PV
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:55:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	81/08-09842-D4894745; Tue, 25 Nov 2014 14:55:09 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416927307!7202203!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3145 invoked from network); 25 Nov 2014 14:55:08 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:55:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPEt0Ee026388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 14:55:00 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPEsxp1011487
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 14:55:00 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPEsxKI011473; Tue, 25 Nov 2014 14:54:59 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 06:54:59 -0800
Message-ID: <547498F2.70201@oracle.com>
Date: Tue, 25 Nov 2014 09:57:54 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>	
	<20141124104127.GF30053@zion.uk.xensource.com>	
	<20141124104703.GH30053@zion.uk.xensource.com>	
	<54735343.1020208@oracle.com>	
	<20141125103940.GC28315@zion.uk.xensource.com>	
	<20141125111522.GD28315@zion.uk.xensource.com>
	<1416915667.7176.39.camel@Abyss>
In-Reply-To: <1416915667.7176.39.camel@Abyss>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 06:41 AM, Dario Faggioli wrote:
> On Tue, 2014-11-25 at 11:15 +0000, Wei Liu wrote:
>> And here it is.
>>
>> Boris, can you give it a shot?
>>
>> ---8<---
>>  From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
>> From: Wei Liu <wei.liu2@citrix.com>
>> Date: Tue, 25 Nov 2014 10:59:47 +0000
>> Subject: [PATCH] libxl: allow copying between bitmaps of different sizes
>>
>> When parsing bitmap objects JSON parser will create libxl_bitmap map of the
>> smallest size needed.
>>
>> This can cause problems when saved image file specifies CPU affinity.  For
>> example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
>> specified, just a single byte will be allocated and libxl_bitmap->size will be
>> set to 1.
>>
>> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
>> since the destination bitmap is created for maximum number of CPUs.
>>
>> We could allocate that bitmap of the same size as the source, however, it is
>> later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
>> number of CPUs
>>
>> To fix this issue, introduce an internal function to allowing copying between
>> bitmaps of different sizes. Note that this function is only used in
>> libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
>> libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
>> placement logic comes into effect when no vcpu / node pinning is provided, so
>> it always operates on bitmap of the same sizes (that is, size of maximum
>> number of cpus /nodes).
>>
>> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Dario Faggioli <dario.faggioli@citrix.com>
>>
> If this end up being the approach, it can have the following:
>
> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:55:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:55:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHWI-00073F-7f; Tue, 25 Nov 2014 14:55:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtHWH-000739-PV
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:55:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	81/08-09842-D4894745; Tue, 25 Nov 2014 14:55:09 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1416927307!7202203!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3145 invoked from network); 25 Nov 2014 14:55:08 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:55:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPEt0Ee026388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 14:55:00 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPEsxp1011487
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 14:55:00 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPEsxKI011473; Tue, 25 Nov 2014 14:54:59 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 06:54:59 -0800
Message-ID: <547498F2.70201@oracle.com>
Date: Tue, 25 Nov 2014 09:57:54 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>, Wei Liu <wei.liu2@citrix.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>	
	<20141124104127.GF30053@zion.uk.xensource.com>	
	<20141124104703.GH30053@zion.uk.xensource.com>	
	<54735343.1020208@oracle.com>	
	<20141125103940.GC28315@zion.uk.xensource.com>	
	<20141125111522.GD28315@zion.uk.xensource.com>
	<1416915667.7176.39.camel@Abyss>
In-Reply-To: <1416915667.7176.39.camel@Abyss>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 06:41 AM, Dario Faggioli wrote:
> On Tue, 2014-11-25 at 11:15 +0000, Wei Liu wrote:
>> And here it is.
>>
>> Boris, can you give it a shot?
>>
>> ---8<---
>>  From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
>> From: Wei Liu <wei.liu2@citrix.com>
>> Date: Tue, 25 Nov 2014 10:59:47 +0000
>> Subject: [PATCH] libxl: allow copying between bitmaps of different sizes
>>
>> When parsing bitmap objects JSON parser will create libxl_bitmap map of the
>> smallest size needed.
>>
>> This can cause problems when saved image file specifies CPU affinity.  For
>> example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
>> specified, just a single byte will be allocated and libxl_bitmap->size will be
>> set to 1.
>>
>> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
>> since the destination bitmap is created for maximum number of CPUs.
>>
>> We could allocate that bitmap of the same size as the source, however, it is
>> later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
>> number of CPUs
>>
>> To fix this issue, introduce an internal function to allowing copying between
>> bitmaps of different sizes. Note that this function is only used in
>> libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
>> libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
>> placement logic comes into effect when no vcpu / node pinning is provided, so
>> it always operates on bitmap of the same sizes (that is, size of maximum
>> number of cpus /nodes).
>>
>> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Dario Faggioli <dario.faggioli@citrix.com>
>>
> If this end up being the approach, it can have the following:
>
> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:55:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14: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 1XtHWW-00075b-ML; Tue, 25 Nov 2014 14:55:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtHWV-00075K-FM
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:55:23 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	52/1C-28296-A5894745; Tue, 25 Nov 2014 14:55:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416927320!13759560!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3203 invoked from network); 25 Nov 2014 14:55:20 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:55:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 14:55:20 +0000
Message-Id: <5474A666020000780004AB9C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 14:55:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
	<54744FB2020000780004A935@mail.emea.novell.com>
	<54749466.1020907@oracle.com>
In-Reply-To: <54749466.1020907@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
 PVH 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 25.11.14 at 15:38, <boris.ostrovsky@oracle.com> wrote:
> On 11/25/2014 03:45 AM, Jan Beulich wrote:
>> @@ -1429,6 +1429,12 @@ int vlapic_init(struct vcpu *v)
>>   
>>       HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "%d", v->vcpu_id);
>>   
>> +    if ( is_pvh_vcpu(v) )
>> +    {
>> +        vlapic->hw.disabled = VLAPIC_HW_DISABLED;
> 
> 
> I did consider doing that but I thought that this flag is meant to be 
> set when the guest clears MSR_IA32_APICBASE_ENABLE to disable APIC and 
> therefore I'd be overloading it (the flag) in a way.

There's no overloading here - we're then simply treating all PVH
vCPU-s as having permanently hardware-disabled LAPICs (reflecting
current reality).

> Regardless, do you think that disabling VPMU for PVH is worth anyway?

That depends on what (bad) consequences not doing so has.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:55:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14: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 1XtHWW-00075b-ML; Tue, 25 Nov 2014 14:55:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtHWV-00075K-FM
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 14:55:23 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	52/1C-28296-A5894745; Tue, 25 Nov 2014 14:55:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416927320!13759560!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3203 invoked from network); 25 Nov 2014 14:55:20 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 14:55:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 14:55:20 +0000
Message-Id: <5474A666020000780004AB9C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 14:55:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
	<54744FB2020000780004A935@mail.emea.novell.com>
	<54749466.1020907@oracle.com>
In-Reply-To: <54749466.1020907@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
 PVH 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 25.11.14 at 15:38, <boris.ostrovsky@oracle.com> wrote:
> On 11/25/2014 03:45 AM, Jan Beulich wrote:
>> @@ -1429,6 +1429,12 @@ int vlapic_init(struct vcpu *v)
>>   
>>       HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "%d", v->vcpu_id);
>>   
>> +    if ( is_pvh_vcpu(v) )
>> +    {
>> +        vlapic->hw.disabled = VLAPIC_HW_DISABLED;
> 
> 
> I did consider doing that but I thought that this flag is meant to be 
> set when the guest clears MSR_IA32_APICBASE_ENABLE to disable APIC and 
> therefore I'd be overloading it (the flag) in a way.

There's no overloading here - we're then simply treating all PVH
vCPU-s as having permanently hardware-disabled LAPICs (reflecting
current reality).

> Regardless, do you think that disabling VPMU for PVH is worth anyway?

That depends on what (bad) consequences not doing so has.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:55:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHWg-00078P-59; Tue, 25 Nov 2014 14:55:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtHWe-00077j-D9
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:55:32 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	47/B3-25727-36894745; Tue, 25 Nov 2014 14:55:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416927330!13746175!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19542 invoked from network); 25 Nov 2014 14:55:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:55:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196576995"
Message-ID: <1416927328.32327.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 25 Nov 2014 14:55:28 +0000
In-Reply-To: <1416580290-4615-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1416580290-4615-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v3 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 14:31 +0000, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> Tested-by: Julien Grall <julien.grall@linaro.org>
> Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:55:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHWg-00078P-59; Tue, 25 Nov 2014 14:55:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtHWe-00077j-D9
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:55:32 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	47/B3-25727-36894745; Tue, 25 Nov 2014 14:55:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416927330!13746175!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19542 invoked from network); 25 Nov 2014 14:55:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:55:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196576995"
Message-ID: <1416927328.32327.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 25 Nov 2014 14:55:28 +0000
In-Reply-To: <1416580290-4615-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1416580290-4615-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v3 for-4.5] xen/arm: clear UIE on hypervisor
 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 14:31 +0000, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
> Tested-by: Julien Grall <julien.grall@linaro.org>
> Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:55:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHWv-0007CV-HR; Tue, 25 Nov 2014 14:55:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtHWv-0007CJ-1V
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 14:55:49 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	B1/08-14727-47894745; Tue, 25 Nov 2014 14:55:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416927345!9922562!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4426 invoked from network); 25 Nov 2014 14:55:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:55:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196577073"
Message-ID: <1416927342.32327.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 25 Nov 2014 14:55:42 +0000
In-Reply-To: <20141120202346.GF31889@laptop.dumpdata.com>
References: <1416504963-4830-1-git-send-email-julien.grall@linaro.org>
	<20141120202346.GF31889@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Julien Grall <julien.grall@linaro.org>,
	ian.jackson@eu.citrix.com, Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 15:23 -0500, Konrad Rzeszutek Wilk wrote:
> > ---
> >     Changes in v2:
> >         - Rework the commit message to explain the problem and the
> >         solution more clearly
> > 
> >     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
> >     time the script has been introduced).
> > 
> >     Developpers using this script won't ommitted to cc some maintainers, and it
> >     will avoid maintainers complaining about miss CC.
> > 
> >     The only drawbacks I can see is if the maintainers is referenced twice in
> >     the file MAINTAINERS with different email, the script won't notice it's
> >     duplicated and list 2 times. Though, for this one it could be fixed by
> >     modifying  the MAINTAINERS file. Is it worth for Xen 4.5? For know,
> >     it seems to only happen with Stefano.
> 
> I am OK with this going in Xen 4.5.

Acked + Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:55:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHWv-0007CV-HR; Tue, 25 Nov 2014 14:55:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtHWv-0007CJ-1V
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 14:55:49 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	B1/08-14727-47894745; Tue, 25 Nov 2014 14:55:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1416927345!9922562!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4426 invoked from network); 25 Nov 2014 14:55:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:55:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196577073"
Message-ID: <1416927342.32327.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 25 Nov 2014 14:55:42 +0000
In-Reply-To: <20141120202346.GF31889@laptop.dumpdata.com>
References: <1416504963-4830-1-git-send-email-julien.grall@linaro.org>
	<20141120202346.GF31889@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Julien Grall <julien.grall@linaro.org>,
	ian.jackson@eu.citrix.com, Don Slutz <dslutz@verizon.com>
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] scripts/get_maintainer.pl:
 Correctly CC the maintainers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 15:23 -0500, Konrad Rzeszutek Wilk wrote:
> > ---
> >     Changes in v2:
> >         - Rework the commit message to explain the problem and the
> >         solution more clearly
> > 
> >     I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
> >     time the script has been introduced).
> > 
> >     Developpers using this script won't ommitted to cc some maintainers, and it
> >     will avoid maintainers complaining about miss CC.
> > 
> >     The only drawbacks I can see is if the maintainers is referenced twice in
> >     the file MAINTAINERS with different email, the script won't notice it's
> >     duplicated and list 2 times. Though, for this one it could be fixed by
> >     modifying  the MAINTAINERS file. Is it worth for Xen 4.5? For know,
> >     it seems to only happen with Stefano.
> 
> I am OK with this going in Xen 4.5.

Acked + Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:56:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:56:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHXg-0007O0-1c; Tue, 25 Nov 2014 14:56:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHXe-0007Nh-Qt
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:56:34 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	C2/B9-14727-2A894745; Tue, 25 Nov 2014 14:56:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416927391!5692445!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29744 invoked from network); 25 Nov 2014 14:56:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:56:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196187036"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 09:43:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHKy-0003UI-L8;
	Tue, 25 Nov 2014 14:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Tue, 25 Nov 2014 14:43:22 +0000
Message-ID: <1416926603-12397-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, wency@cn.fujitsu.com, mst@redhat.com,
	jasowang@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH 3/4] move virtqueue_unmap_sg calls from
	virtqueue_fill to virtqueue_push
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Move the two virtqueue_unmap_sg calls from virtqueue_fill to
virtqueue_push: most virtio drivers simply call virtqueue_push so they
are unaffected. virtio-net calls virtqueue_fill directly, so we need to
make the two virtqueue_unmap_sg calls explicitely there.

Also replace the virtqueue_push call from virtio_net_handle_ctrl with an
open coded version it in place.

No functional changes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: jasowang@redhat.com
CC: wency@cn.fujitsu.com
CC: mst@redhat.com
CC: pbonzini@redhat.com
---
 hw/net/virtio-net.c |    7 ++++++-
 hw/virtio/virtio.c  |    5 ++---
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 2ac6ce5..5035313 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -803,7 +803,10 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
         s = iov_from_buf(elem.in_sg, elem.in_num, 0, &status, sizeof(status));
         assert(s == sizeof(status));
 
-        virtqueue_push(vq, &elem, sizeof(status));
+        virtqueue_unmap_sg(elem.in_sg, elem.in_num, 1, sizeof(status));
+        virtqueue_unmap_sg(elem.out_sg, elem.out_num, 0, UINT_MAX);
+        virtqueue_fill(vq, &elem, sizeof(status), 0);
+        virtqueue_flush(vq, 1);
         virtio_notify(vdev, vq);
     }
 }
@@ -1052,6 +1055,8 @@ static ssize_t virtio_net_receive(NetClientState *nc, const uint8_t *buf, size_t
         }
 
         /* signal other side */
+        virtqueue_unmap_sg(elem.in_sg, elem.in_num, 1, total);
+        virtqueue_unmap_sg(elem.out_sg, elem.out_num, 0, UINT_MAX);
         virtqueue_fill(q->rx_vq, &elem, total, i++);
     }
 
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 4af31d0..0a6583a 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -240,9 +240,6 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
 {
     trace_virtqueue_fill(vq, elem, len, idx);
 
-    virtqueue_unmap_sg(elem->in_sg, elem->in_num, 1, len);
-    virtqueue_unmap_sg(elem->out_sg, elem->out_num, 0, UINT_MAX);
-
     idx = (idx + vring_used_idx(vq)) % vq->vring.num;
 
     /* Get a pointer to the next entry in the used ring. */
@@ -267,6 +264,8 @@ void virtqueue_flush(VirtQueue *vq, unsigned int count)
 void virtqueue_push(VirtQueue *vq, const VirtQueueElement *elem,
                     unsigned int len)
 {
+    virtqueue_unmap_sg(elem->in_sg, elem->in_num, 1, len);
+    virtqueue_unmap_sg(elem->out_sg, elem->out_num, 0, UINT_MAX);
     virtqueue_fill(vq, elem, len, 0);
     virtqueue_flush(vq, 1);
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 14:56:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 14:56:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHXg-0007O0-1c; Tue, 25 Nov 2014 14:56:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHXe-0007Nh-Qt
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 14:56:34 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	C2/B9-14727-2A894745; Tue, 25 Nov 2014 14:56:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416927391!5692445!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29744 invoked from network); 25 Nov 2014 14:56:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 14:56:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196187036"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 09:43:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHKy-0003UI-L8;
	Tue, 25 Nov 2014 14:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <qemu-devel@nongnu.org>
Date: Tue, 25 Nov 2014 14:43:22 +0000
Message-ID: <1416926603-12397-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, wency@cn.fujitsu.com, mst@redhat.com,
	jasowang@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH 3/4] move virtqueue_unmap_sg calls from
	virtqueue_fill to virtqueue_push
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Move the two virtqueue_unmap_sg calls from virtqueue_fill to
virtqueue_push: most virtio drivers simply call virtqueue_push so they
are unaffected. virtio-net calls virtqueue_fill directly, so we need to
make the two virtqueue_unmap_sg calls explicitely there.

Also replace the virtqueue_push call from virtio_net_handle_ctrl with an
open coded version it in place.

No functional changes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: jasowang@redhat.com
CC: wency@cn.fujitsu.com
CC: mst@redhat.com
CC: pbonzini@redhat.com
---
 hw/net/virtio-net.c |    7 ++++++-
 hw/virtio/virtio.c  |    5 ++---
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 2ac6ce5..5035313 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -803,7 +803,10 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
         s = iov_from_buf(elem.in_sg, elem.in_num, 0, &status, sizeof(status));
         assert(s == sizeof(status));
 
-        virtqueue_push(vq, &elem, sizeof(status));
+        virtqueue_unmap_sg(elem.in_sg, elem.in_num, 1, sizeof(status));
+        virtqueue_unmap_sg(elem.out_sg, elem.out_num, 0, UINT_MAX);
+        virtqueue_fill(vq, &elem, sizeof(status), 0);
+        virtqueue_flush(vq, 1);
         virtio_notify(vdev, vq);
     }
 }
@@ -1052,6 +1055,8 @@ static ssize_t virtio_net_receive(NetClientState *nc, const uint8_t *buf, size_t
         }
 
         /* signal other side */
+        virtqueue_unmap_sg(elem.in_sg, elem.in_num, 1, total);
+        virtqueue_unmap_sg(elem.out_sg, elem.out_num, 0, UINT_MAX);
         virtqueue_fill(q->rx_vq, &elem, total, i++);
     }
 
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 4af31d0..0a6583a 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -240,9 +240,6 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
 {
     trace_virtqueue_fill(vq, elem, len, idx);
 
-    virtqueue_unmap_sg(elem->in_sg, elem->in_num, 1, len);
-    virtqueue_unmap_sg(elem->out_sg, elem->out_num, 0, UINT_MAX);
-
     idx = (idx + vring_used_idx(vq)) % vq->vring.num;
 
     /* Get a pointer to the next entry in the used ring. */
@@ -267,6 +264,8 @@ void virtqueue_flush(VirtQueue *vq, unsigned int count)
 void virtqueue_push(VirtQueue *vq, const VirtQueueElement *elem,
                     unsigned int len)
 {
+    virtqueue_unmap_sg(elem->in_sg, elem->in_num, 1, len);
+    virtqueue_unmap_sg(elem->out_sg, elem->out_num, 0, UINT_MAX);
     virtqueue_fill(vq, elem, len, 0);
     virtqueue_flush(vq, 1);
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:02:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:02:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHcv-0007mR-W5; Tue, 25 Nov 2014 15:02:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pranavkumar@linaro.org>) id 1XtHct-0007m9-V6
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:02:00 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	2A/81-11581-7E994745; Tue, 25 Nov 2014 15:01:59 +0000
X-Env-Sender: pranavkumar@linaro.org
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416927717!10395424!1
X-Originating-IP: [209.85.192.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15090 invoked from network); 25 Nov 2014 15:01:58 -0000
Received: from mail-qg0-f51.google.com (HELO mail-qg0-f51.google.com)
	(209.85.192.51)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:01:58 -0000
Received: by mail-qg0-f51.google.com with SMTP id l89so509452qgf.24
	for <xen-devel@lists.xen.org>; Tue, 25 Nov 2014 07:01:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=M1Akit7pwUa5OlRlhcQwkR9gaiAsffWXbB7mPqpduQU=;
	b=PeNXdBtjN6jtFuFYDZXAiDVZb9OWXgVFGJ0XGgAINNQmgd/lbLmn8tOcs0IDPIDLiP
	PqFZGT1Wga8LffxQnfZSCaJaYdwmR3M5vtdhV317UecwiuCxH+MfPXyKmaO4wD5MvMjn
	w+pLHRPFHJUJtu2xj8ofQt4Jn6DnqOJ1/d2kVsNGVlXoAgBSKATq+7jt4gfZzLTcCWt+
	lpOizbNELqwOyHUYlFwFWKxWi79I6Wka1MNZDO+2TcMnZl/NNkaoUpqcs77WTHD6t5fq
	VpJAw0+P6Yyv8QUfbSBQIOKZelQtrnlLtettrmCvAzdnx3sE/+3Z27eSSWY57NOn5S3K
	BbGA==
X-Gm-Message-State: ALoCoQmQlorqwqcGrgrJ1TueKki29+C7x7r+Twi/HxKT06EDq/TxZsrbmcdZhSmE4J0D4qhMLPRc
MIME-Version: 1.0
X-Received: by 10.229.240.138 with SMTP id la10mr37535527qcb.13.1416927716552; 
	Tue, 25 Nov 2014 07:01:56 -0800 (PST)
Received: by 10.140.106.166 with HTTP; Tue, 25 Nov 2014 07:01:56 -0800 (PST)
In-Reply-To: <1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
Date: Tue, 25 Nov 2014 20:31:56 +0530
Message-ID: <CAAHg+Hia=8Cm+MDJ4rTQxXR29PrKcj1qpZrD3774ekMAe5pV6A@mail.gmail.com>
From: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, xen-devel@lists.xen.org,
	Clark Laughlin <clark.laughlin@linaro.org>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 5/5] xen: arm: Support the other
	4 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 19 November 2014 at 20:58, Ian Campbell <ian.campbell@citrix.com> wrote:
> Currently we only establish specific mappings for pcie0, which is
> used on the Mustang platform. However at least McDivitt uses pcie3.
> So wire up all the others, based on whether the corresponding DT node
> is marked as available.
>
> This results in no change for Mustang.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: - Didn't constify dt node pointer -- dt_find_compatible_node needs a
>       non-const
>     - Print a message when ignoring an unknown bus
>     - Log with dt node full anme instead of CFG space address.
>     - Log at start of xgene_storm_pcie_specific_mapping instead of in the
>       caller after the fact.
> ---
>  xen/arch/arm/platforms/xgene-storm.c |   89 +++++++++++++++++++++++++++++-----
>  1 file changed, 76 insertions(+), 13 deletions(-)
>
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 8c27f24..0b3492d 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -78,35 +78,35 @@ static int map_one_spi(struct domain *d, const char *what,
>      return ret;
>  }
>
> -/*
> - * Xen does not currently support mapping MMIO regions and interrupt
> - * for bus child devices (referenced via the "ranges" and
> - * "interrupt-map" properties to domain 0). Instead for now map the
> - * necessary resources manually.
> - */
> -static int xgene_storm_specific_mapping(struct domain *d)
> +/* Creates MMIO mappings base..end as well as 4 SPIs from the given base. */
> +static int xgene_storm_pcie_specific_mapping(struct domain *d,
> +                                             const struct dt_device_node *node,
> +                                             paddr_t base, paddr_t end,
> +                                             int base_spi)
>  {
>      int ret;
>
> +    printk("Mapping additional regions for PCIe device %s\n",
> +           dt_node_full_name(node));
> +
>      /* Map the PCIe bus resources */
> -    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
> -                                        paddr_to_pfn(0x01000000000UL));
> +    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(base), paddr_to_pfn(end));
>      if ( ret )
>          goto err;
>
> -    ret = map_one_spi(d, "PCI#INTA", 0xc2, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTA", base_spi+0, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>
> -    ret = map_one_spi(d, "PCI#INTB", 0xc3, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTB", base_spi+1, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>
> -    ret = map_one_spi(d, "PCI#INTC", 0xc4, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTC", base_spi+2, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>
> -    ret = map_one_spi(d, "PCI#INTD", 0xc5, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTD", base_spi+3, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>
> @@ -115,6 +115,69 @@ err:
>      return ret;
>  }
>
> +/*
> + * Xen does not currently support mapping MMIO regions and interrupt
> + * for bus child devices (referenced via the "ranges" and
> + * "interrupt-map" properties to domain 0). Instead for now map the
> + * necessary resources manually.
> + */
> +static int xgene_storm_specific_mapping(struct domain *d)
> +{
> +    struct dt_device_node *node = NULL;
> +    int ret;
> +
> +    while ( (node = dt_find_compatible_node(node, "pci", "apm,xgene-pcie")) )
> +    {
> +        u64 addr;
> +
> +        /* Identify the bus via it's control register address */
> +        ret = dt_device_get_address(node, 0, &addr, NULL);
> +        if ( ret < 0 )
> +            return ret;
> +
> +        if ( !dt_device_is_available(node) )
> +            continue;
> +
> +       switch ( addr )
> +        {
> +        case 0x1f2b0000: /* PCIe0 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0e000000000UL, 0x10000000000UL, 0xc2);
> +            break;
> +        case 0x1f2c0000: /* PCIe1 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0d000000000UL, 0x0e000000000UL, 0xc8);
> +            break;
> +        case 0x1f2d0000: /* PCIe2 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x09000000000UL, 0x0a000000000UL, 0xce);
> +            break;
> +        case 0x1f500000: /* PCIe3 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0a000000000UL, 0x0c000000000UL, 0xd4);
> +            break;
> +        case 0x1f510000: /* PCIe4 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0c000000000UL, 0x0d000000000UL, 0xda);
> +            break;
> +
> +        default:
> +            printk("Ignoring unknown PCI bus %s\n", dt_node_full_name(node));
> +            continue;
> +        }
> +
> +        if ( ret < 0 )
> +            return ret;
> +    }
> +
> +    return 0;
> +}
> +
>  static void xgene_storm_reset(void)
>  {
>      void __iomem *addr;
> --
> 1.7.10.4
>

Patch looks good.
Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>

Thanks,
Pranav

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:02:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:02:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHcv-0007mR-W5; Tue, 25 Nov 2014 15:02:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pranavkumar@linaro.org>) id 1XtHct-0007m9-V6
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:02:00 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	2A/81-11581-7E994745; Tue, 25 Nov 2014 15:01:59 +0000
X-Env-Sender: pranavkumar@linaro.org
X-Msg-Ref: server-16.tower-206.messagelabs.com!1416927717!10395424!1
X-Originating-IP: [209.85.192.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15090 invoked from network); 25 Nov 2014 15:01:58 -0000
Received: from mail-qg0-f51.google.com (HELO mail-qg0-f51.google.com)
	(209.85.192.51)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:01:58 -0000
Received: by mail-qg0-f51.google.com with SMTP id l89so509452qgf.24
	for <xen-devel@lists.xen.org>; Tue, 25 Nov 2014 07:01:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=M1Akit7pwUa5OlRlhcQwkR9gaiAsffWXbB7mPqpduQU=;
	b=PeNXdBtjN6jtFuFYDZXAiDVZb9OWXgVFGJ0XGgAINNQmgd/lbLmn8tOcs0IDPIDLiP
	PqFZGT1Wga8LffxQnfZSCaJaYdwmR3M5vtdhV317UecwiuCxH+MfPXyKmaO4wD5MvMjn
	w+pLHRPFHJUJtu2xj8ofQt4Jn6DnqOJ1/d2kVsNGVlXoAgBSKATq+7jt4gfZzLTcCWt+
	lpOizbNELqwOyHUYlFwFWKxWi79I6Wka1MNZDO+2TcMnZl/NNkaoUpqcs77WTHD6t5fq
	VpJAw0+P6Yyv8QUfbSBQIOKZelQtrnlLtettrmCvAzdnx3sE/+3Z27eSSWY57NOn5S3K
	BbGA==
X-Gm-Message-State: ALoCoQmQlorqwqcGrgrJ1TueKki29+C7x7r+Twi/HxKT06EDq/TxZsrbmcdZhSmE4J0D4qhMLPRc
MIME-Version: 1.0
X-Received: by 10.229.240.138 with SMTP id la10mr37535527qcb.13.1416927716552; 
	Tue, 25 Nov 2014 07:01:56 -0800 (PST)
Received: by 10.140.106.166 with HTTP; Tue, 25 Nov 2014 07:01:56 -0800 (PST)
In-Reply-To: <1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
Date: Tue, 25 Nov 2014 20:31:56 +0530
Message-ID: <CAAHg+Hia=8Cm+MDJ4rTQxXR29PrKcj1qpZrD3774ekMAe5pV6A@mail.gmail.com>
From: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, xen-devel@lists.xen.org,
	Clark Laughlin <clark.laughlin@linaro.org>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 5/5] xen: arm: Support the other
	4 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 19 November 2014 at 20:58, Ian Campbell <ian.campbell@citrix.com> wrote:
> Currently we only establish specific mappings for pcie0, which is
> used on the Mustang platform. However at least McDivitt uses pcie3.
> So wire up all the others, based on whether the corresponding DT node
> is marked as available.
>
> This results in no change for Mustang.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: - Didn't constify dt node pointer -- dt_find_compatible_node needs a
>       non-const
>     - Print a message when ignoring an unknown bus
>     - Log with dt node full anme instead of CFG space address.
>     - Log at start of xgene_storm_pcie_specific_mapping instead of in the
>       caller after the fact.
> ---
>  xen/arch/arm/platforms/xgene-storm.c |   89 +++++++++++++++++++++++++++++-----
>  1 file changed, 76 insertions(+), 13 deletions(-)
>
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 8c27f24..0b3492d 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -78,35 +78,35 @@ static int map_one_spi(struct domain *d, const char *what,
>      return ret;
>  }
>
> -/*
> - * Xen does not currently support mapping MMIO regions and interrupt
> - * for bus child devices (referenced via the "ranges" and
> - * "interrupt-map" properties to domain 0). Instead for now map the
> - * necessary resources manually.
> - */
> -static int xgene_storm_specific_mapping(struct domain *d)
> +/* Creates MMIO mappings base..end as well as 4 SPIs from the given base. */
> +static int xgene_storm_pcie_specific_mapping(struct domain *d,
> +                                             const struct dt_device_node *node,
> +                                             paddr_t base, paddr_t end,
> +                                             int base_spi)
>  {
>      int ret;
>
> +    printk("Mapping additional regions for PCIe device %s\n",
> +           dt_node_full_name(node));
> +
>      /* Map the PCIe bus resources */
> -    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(0x0e000000000UL),
> -                                        paddr_to_pfn(0x01000000000UL));
> +    ret = map_one_mmio(d, "PCI MEMORY", paddr_to_pfn(base), paddr_to_pfn(end));
>      if ( ret )
>          goto err;
>
> -    ret = map_one_spi(d, "PCI#INTA", 0xc2, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTA", base_spi+0, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>
> -    ret = map_one_spi(d, "PCI#INTB", 0xc3, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTB", base_spi+1, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>
> -    ret = map_one_spi(d, "PCI#INTC", 0xc4, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTC", base_spi+2, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>
> -    ret = map_one_spi(d, "PCI#INTD", 0xc5, DT_IRQ_TYPE_LEVEL_HIGH);
> +    ret = map_one_spi(d, "PCI#INTD", base_spi+3, DT_IRQ_TYPE_LEVEL_HIGH);
>      if ( ret )
>          goto err;
>
> @@ -115,6 +115,69 @@ err:
>      return ret;
>  }
>
> +/*
> + * Xen does not currently support mapping MMIO regions and interrupt
> + * for bus child devices (referenced via the "ranges" and
> + * "interrupt-map" properties to domain 0). Instead for now map the
> + * necessary resources manually.
> + */
> +static int xgene_storm_specific_mapping(struct domain *d)
> +{
> +    struct dt_device_node *node = NULL;
> +    int ret;
> +
> +    while ( (node = dt_find_compatible_node(node, "pci", "apm,xgene-pcie")) )
> +    {
> +        u64 addr;
> +
> +        /* Identify the bus via it's control register address */
> +        ret = dt_device_get_address(node, 0, &addr, NULL);
> +        if ( ret < 0 )
> +            return ret;
> +
> +        if ( !dt_device_is_available(node) )
> +            continue;
> +
> +       switch ( addr )
> +        {
> +        case 0x1f2b0000: /* PCIe0 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0e000000000UL, 0x10000000000UL, 0xc2);
> +            break;
> +        case 0x1f2c0000: /* PCIe1 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0d000000000UL, 0x0e000000000UL, 0xc8);
> +            break;
> +        case 0x1f2d0000: /* PCIe2 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x09000000000UL, 0x0a000000000UL, 0xce);
> +            break;
> +        case 0x1f500000: /* PCIe3 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0a000000000UL, 0x0c000000000UL, 0xd4);
> +            break;
> +        case 0x1f510000: /* PCIe4 */
> +            ret = xgene_storm_pcie_specific_mapping(d,
> +                node,
> +                0x0c000000000UL, 0x0d000000000UL, 0xda);
> +            break;
> +
> +        default:
> +            printk("Ignoring unknown PCI bus %s\n", dt_node_full_name(node));
> +            continue;
> +        }
> +
> +        if ( ret < 0 )
> +            return ret;
> +    }
> +
> +    return 0;
> +}
> +
>  static void xgene_storm_reset(void)
>  {
>      void __iomem *addr;
> --
> 1.7.10.4
>

Patch looks good.
Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>

Thanks,
Pranav

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:06:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHh5-0007xg-Pw; Tue, 25 Nov 2014 15:06:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1XtHh4-0007xa-9l
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 15:06:18 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	AA/85-27785-9EA94745; Tue, 25 Nov 2014 15:06:17 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416927973!10126963!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20270 invoked from network); 25 Nov 2014 15:06:13 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:06:13 -0000
Received: by mail-la0-f43.google.com with SMTP id q1so710943lam.2
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Nov 2014 07:06:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=jKd7FsmTDFNbtecMrqfFclurXLJci42P9vXDACxlyAg=;
	b=AJh89tpOoBx/sgQzcWIGWr3o+V+5vQJuuRSnNHfTCIjzEpxt3wL51y1b/4pT8ou4fz
	xnNfMXNWbBzkbsKebzxfFL2ATa0aQ4bVO3R6T/M+4tOewICA+jg2/aqwa1QrfcWIUPy0
	gtnxK9yJz2+m1ZZ2I+yC4NdUnfdjKwrwlpEDxzIrMDmeoTdliRfT/wA9SiMzGKsREvmJ
	w++7zaXhpuChlFxQCvKDb4MnnET3r/F13vvQDQjD0lD4P/F62qlio4Ymib54OB2s3NQ6
	mgvt9sFkMOXkRTzBlpjQOF+Zomww0raNFdaAKhIneXujT+P+TMWlh0aiU7K078y85M+v
	ofQQ==
X-Gm-Message-State: ALoCoQks4TbxZtpGpZ5l8dmnyyceuDveeQ8375ZreI/74fNsr+rAYbYrAVctW1C1zNWZCDR8cxEN
X-Received: by 10.152.243.37 with SMTP id wv5mr28196963lac.10.1416927972880;
	Tue, 25 Nov 2014 07:06:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.150.135 with HTTP; Tue, 25 Nov 2014 07:05:52 -0800 (PST)
In-Reply-To: <1416926603-12397-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
	<1416926603-12397-1-git-send-email-stefano.stabellini@eu.citrix.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Tue, 25 Nov 2014 15:05:52 +0000
Message-ID: <CAFEAcA9Ycghd_vOsdzHjTFUbCGtBgdH7WqZ6imfvNt5HxgqF-g@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jason Wang <jasowang@redhat.com>,
	"xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] introduce
	virtqueue_unmap_sg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 November 2014 at 14:43, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> Introduce a function to unmap an sg previously mapped with
> virtqueue_map_sg.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: jasowang@redhat.com
> CC: wency@cn.fujitsu.com
> CC: mst@redhat.com
> CC: pbonzini@redhat.com
> ---
>  hw/virtio/virtio.c         |   22 ++++++++++++++++++++++
>  include/hw/virtio/virtio.h |    2 ++
>  2 files changed, 24 insertions(+)
>
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 3e4b70c..2621ae6 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -446,6 +446,28 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
>      }
>  }
>
> +void virtqueue_unmap_sg(const struct iovec *sg, size_t num_sg,
> +                        int is_write, unsigned int len)
> +{
> +    unsigned int i;
> +    unsigned int offset;
> +
> +    if (num_sg > VIRTQUEUE_MAX_SIZE) {
> +        error_report("virtio: unmap attempt out of bounds: %zd > %d",
> +                     num_sg, VIRTQUEUE_MAX_SIZE);
> +        exit(1);
> +    }
> +
> +    offset = 0;
> +    for (i = 0; i < num_sg; i++) {
> +        size_t size = MIN(len - offset, sg[i].iov_len);
> +
> +        cpu_physical_memory_unmap(sg[i].iov_base, sg[i].iov_len, is_write, size);
> +
> +        offset += size;
> +    }
> +}

It seems rather odd that "size" and the iov_len fields in
the iovec are size_t but 'len' and 'offset' are only
unsigned int...

thanks
-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:06:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHh5-0007xg-Pw; Tue, 25 Nov 2014 15:06:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1XtHh4-0007xa-9l
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 15:06:18 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	AA/85-27785-9EA94745; Tue, 25 Nov 2014 15:06:17 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416927973!10126963!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20270 invoked from network); 25 Nov 2014 15:06:13 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:06:13 -0000
Received: by mail-la0-f43.google.com with SMTP id q1so710943lam.2
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Nov 2014 07:06:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=jKd7FsmTDFNbtecMrqfFclurXLJci42P9vXDACxlyAg=;
	b=AJh89tpOoBx/sgQzcWIGWr3o+V+5vQJuuRSnNHfTCIjzEpxt3wL51y1b/4pT8ou4fz
	xnNfMXNWbBzkbsKebzxfFL2ATa0aQ4bVO3R6T/M+4tOewICA+jg2/aqwa1QrfcWIUPy0
	gtnxK9yJz2+m1ZZ2I+yC4NdUnfdjKwrwlpEDxzIrMDmeoTdliRfT/wA9SiMzGKsREvmJ
	w++7zaXhpuChlFxQCvKDb4MnnET3r/F13vvQDQjD0lD4P/F62qlio4Ymib54OB2s3NQ6
	mgvt9sFkMOXkRTzBlpjQOF+Zomww0raNFdaAKhIneXujT+P+TMWlh0aiU7K078y85M+v
	ofQQ==
X-Gm-Message-State: ALoCoQks4TbxZtpGpZ5l8dmnyyceuDveeQ8375ZreI/74fNsr+rAYbYrAVctW1C1zNWZCDR8cxEN
X-Received: by 10.152.243.37 with SMTP id wv5mr28196963lac.10.1416927972880;
	Tue, 25 Nov 2014 07:06:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.150.135 with HTTP; Tue, 25 Nov 2014 07:05:52 -0800 (PST)
In-Reply-To: <1416926603-12397-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
	<1416926603-12397-1-git-send-email-stefano.stabellini@eu.citrix.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Tue, 25 Nov 2014 15:05:52 +0000
Message-ID: <CAFEAcA9Ycghd_vOsdzHjTFUbCGtBgdH7WqZ6imfvNt5HxgqF-g@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jason Wang <jasowang@redhat.com>,
	"xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] introduce
	virtqueue_unmap_sg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 November 2014 at 14:43, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> Introduce a function to unmap an sg previously mapped with
> virtqueue_map_sg.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: jasowang@redhat.com
> CC: wency@cn.fujitsu.com
> CC: mst@redhat.com
> CC: pbonzini@redhat.com
> ---
>  hw/virtio/virtio.c         |   22 ++++++++++++++++++++++
>  include/hw/virtio/virtio.h |    2 ++
>  2 files changed, 24 insertions(+)
>
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 3e4b70c..2621ae6 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -446,6 +446,28 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
>      }
>  }
>
> +void virtqueue_unmap_sg(const struct iovec *sg, size_t num_sg,
> +                        int is_write, unsigned int len)
> +{
> +    unsigned int i;
> +    unsigned int offset;
> +
> +    if (num_sg > VIRTQUEUE_MAX_SIZE) {
> +        error_report("virtio: unmap attempt out of bounds: %zd > %d",
> +                     num_sg, VIRTQUEUE_MAX_SIZE);
> +        exit(1);
> +    }
> +
> +    offset = 0;
> +    for (i = 0; i < num_sg; i++) {
> +        size_t size = MIN(len - offset, sg[i].iov_len);
> +
> +        cpu_physical_memory_unmap(sg[i].iov_base, sg[i].iov_len, is_write, size);
> +
> +        offset += size;
> +    }
> +}

It seems rather odd that "size" and the iov_len fields in
the iovec are size_t but 'len' and 'offset' are only
unsigned int...

thanks
-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:09:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 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.xen.org>)
	id 1XtHjg-00084A-Bj; Tue, 25 Nov 2014 15:09:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtHje-000843-Rd
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:08:58 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	C6/67-02702-A8B94745; Tue, 25 Nov 2014 15:08:58 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416928136!14183948!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4071 invoked from network); 25 Nov 2014 15:08:57 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:08:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPF8kcn024308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 15:08:47 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPF8k5p005910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 15:08:46 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAPF8j4O007428; Tue, 25 Nov 2014 15:08:45 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 07:08:45 -0800
Message-ID: <54749C2B.4090303@oracle.com>
Date: Tue, 25 Nov 2014 10:11:39 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416870378-32481-2-git-send-email-boris.ostrovsky@oracle.com>
	<alpine.DEB.2.02.1411251205220.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411251205220.2675@kaball.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	david.vrabel@citrix.com, jun.nakajima@intel.com
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen/pci: Defer initialization of MSI
 ops on HVM guests until after x2APIC has been set up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 07:06 AM, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
>> If the hardware supports APIC virtualization we may decide not to use pirqs
>> and instead use APIC/x2APIC directly, meaning that we don't want to set
>> x86_msi.setup_msi_irqs and x86_msi.teardown_msi_irq to Xen-specific routines.
>> However, x2APIC is not set up by the time pci_xen_hvm_init() is called so we
>> need to postpone setting these ops until later, when we know which APIC mode
>> is used.
>>
>> (Note that currently x2APIC is never initialized on HVM guests. This may
>> change in the future)
> I take that this is safe because no MSIs can be received at this point
> (apic_post_init), right?


Yes. At the time apic_post_init() is called PCI has not been probed yet.

-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:09:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 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.xen.org>)
	id 1XtHjg-00084A-Bj; Tue, 25 Nov 2014 15:09:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtHje-000843-Rd
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:08:58 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	C6/67-02702-A8B94745; Tue, 25 Nov 2014 15:08:58 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1416928136!14183948!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4071 invoked from network); 25 Nov 2014 15:08:57 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:08:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPF8kcn024308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 15:08:47 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPF8k5p005910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 15:08:46 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAPF8j4O007428; Tue, 25 Nov 2014 15:08:45 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 07:08:45 -0800
Message-ID: <54749C2B.4090303@oracle.com>
Date: Tue, 25 Nov 2014 10:11:39 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416870378-32481-2-git-send-email-boris.ostrovsky@oracle.com>
	<alpine.DEB.2.02.1411251205220.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411251205220.2675@kaball.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	david.vrabel@citrix.com, jun.nakajima@intel.com
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen/pci: Defer initialization of MSI
 ops on HVM guests until after x2APIC has been set up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 07:06 AM, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
>> If the hardware supports APIC virtualization we may decide not to use pirqs
>> and instead use APIC/x2APIC directly, meaning that we don't want to set
>> x86_msi.setup_msi_irqs and x86_msi.teardown_msi_irq to Xen-specific routines.
>> However, x2APIC is not set up by the time pci_xen_hvm_init() is called so we
>> need to postpone setting these ops until later, when we know which APIC mode
>> is used.
>>
>> (Note that currently x2APIC is never initialized on HVM guests. This may
>> change in the future)
> I take that this is safe because no MSIs can be received at this point
> (apic_post_init), right?


Yes. At the time apic_post_init() is called PCI has not been probed yet.

-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:09:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15: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 1XtHkZ-00088e-Pb; Tue, 25 Nov 2014 15:09:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtHkX-00088R-Mf
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:09:53 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	39/FF-05632-0CB94745; Tue, 25 Nov 2014 15:09:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416928190!13764278!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13008 invoked from network); 25 Nov 2014 15:09:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:09:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196193954"
Message-ID: <1416927358.32327.37.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 25 Nov 2014 14:55:58 +0000
In-Reply-To: <CAFLBxZaLG8RGQ5Pce9TvczvJtg8t983X+stRNMD0VeYJgJ9VEw@mail.gmail.com>
References: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
	<CAFLBxZaLG8RGQ5Pce9TvczvJtg8t983X+stRNMD0VeYJgJ9VEw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for 4.5] xl: Return proper error codes for
 block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:06 +0000, George Dunlap wrote:
> On Wed, Nov 12, 2014 at 5:31 PM, George Dunlap
> <george.dunlap@eu.citrix.com> wrote:
> > Return proper error codes on failure so that scripts can tell whether
> > the command completed properly or not.
> 
> How about changing this to something like:
> 
> ---
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.
> 
> This is not a proper fix, since it fails to call
> libxl_device_disk_dispose() on the error path.  But a proper fix
> requires some refactoring, so given where we are in the release
> process, it's better to have a fix that is simple and obvious, and do
> the refactoring once the next development window opens up.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Looks good, I kept the single line title the same and replaced the body
with the above, which I think is what you intended.

Konrad acked taking this patch for 4.5 in a reply to v2, so I have
pushed.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:09:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15: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 1XtHkZ-00088e-Pb; Tue, 25 Nov 2014 15:09:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtHkX-00088R-Mf
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:09:53 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	39/FF-05632-0CB94745; Tue, 25 Nov 2014 15:09:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416928190!13764278!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13008 invoked from network); 25 Nov 2014 15:09:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:09:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196193954"
Message-ID: <1416927358.32327.37.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 25 Nov 2014 14:55:58 +0000
In-Reply-To: <CAFLBxZaLG8RGQ5Pce9TvczvJtg8t983X+stRNMD0VeYJgJ9VEw@mail.gmail.com>
References: <1415813493-25330-1-git-send-email-george.dunlap@eu.citrix.com>
	<CAFLBxZaLG8RGQ5Pce9TvczvJtg8t983X+stRNMD0VeYJgJ9VEw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for 4.5] xl: Return proper error codes for
 block-attach and block-detach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:06 +0000, George Dunlap wrote:
> On Wed, Nov 12, 2014 at 5:31 PM, George Dunlap
> <george.dunlap@eu.citrix.com> wrote:
> > Return proper error codes on failure so that scripts can tell whether
> > the command completed properly or not.
> 
> How about changing this to something like:
> 
> ---
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.
> 
> This is not a proper fix, since it fails to call
> libxl_device_disk_dispose() on the error path.  But a proper fix
> requires some refactoring, so given where we are in the release
> process, it's better to have a fix that is simple and obvious, and do
> the refactoring once the next development window opens up.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Looks good, I kept the single line title the same and replaced the body
with the above, which I think is what you intended.

Konrad acked taking this patch for 4.5 in a reply to v2, so I have
pushed.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:13:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHns-0008Nd-Dz; Tue, 25 Nov 2014 15:13:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHnr-0008NV-Fk
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:13:19 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	92/07-02954-E8C94745; Tue, 25 Nov 2014 15:13:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416928396!14742253!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9788 invoked from network); 25 Nov 2014 15:13:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:13:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196587022"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 10:12:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHms-00049F-KM;
	Tue, 25 Nov 2014 15:12:18 +0000
Date: Tue, 25 Nov 2014 15:12:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54749C2B.4090303@oracle.com>
Message-ID: <alpine.DEB.2.02.1411251511580.2675@kaball.uk.xensource.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416870378-32481-2-git-send-email-boris.ostrovsky@oracle.com>
	<alpine.DEB.2.02.1411251205220.2675@kaball.uk.xensource.com>
	<54749C2B.4090303@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	david.vrabel@citrix.com, jun.nakajima@intel.com
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen/pci: Defer initialization of MSI
 ops on HVM guests until after x2APIC has been set up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Boris Ostrovsky wrote:
> On 11/25/2014 07:06 AM, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
> > > If the hardware supports APIC virtualization we may decide not to use
> > > pirqs
> > > and instead use APIC/x2APIC directly, meaning that we don't want to set
> > > x86_msi.setup_msi_irqs and x86_msi.teardown_msi_irq to Xen-specific
> > > routines.
> > > However, x2APIC is not set up by the time pci_xen_hvm_init() is called so
> > > we
> > > need to postpone setting these ops until later, when we know which APIC
> > > mode
> > > is used.
> > > 
> > > (Note that currently x2APIC is never initialized on HVM guests. This may
> > > change in the future)
> > I take that this is safe because no MSIs can be received at this point
> > (apic_post_init), right?
> 
> 
> Yes. At the time apic_post_init() is called PCI has not been probed yet.

Please add that to the commit message.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:13:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHns-0008Nd-Dz; Tue, 25 Nov 2014 15:13:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtHnr-0008NV-Fk
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:13:19 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	92/07-02954-E8C94745; Tue, 25 Nov 2014 15:13:18 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1416928396!14742253!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9788 invoked from network); 25 Nov 2014 15:13:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:13:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196587022"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 10:12:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtHms-00049F-KM;
	Tue, 25 Nov 2014 15:12:18 +0000
Date: Tue, 25 Nov 2014 15:12:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
In-Reply-To: <54749C2B.4090303@oracle.com>
Message-ID: <alpine.DEB.2.02.1411251511580.2675@kaball.uk.xensource.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416870378-32481-2-git-send-email-boris.ostrovsky@oracle.com>
	<alpine.DEB.2.02.1411251205220.2675@kaball.uk.xensource.com>
	<54749C2B.4090303@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	david.vrabel@citrix.com, jun.nakajima@intel.com
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen/pci: Defer initialization of MSI
 ops on HVM guests until after x2APIC has been set up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Boris Ostrovsky wrote:
> On 11/25/2014 07:06 AM, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
> > > If the hardware supports APIC virtualization we may decide not to use
> > > pirqs
> > > and instead use APIC/x2APIC directly, meaning that we don't want to set
> > > x86_msi.setup_msi_irqs and x86_msi.teardown_msi_irq to Xen-specific
> > > routines.
> > > However, x2APIC is not set up by the time pci_xen_hvm_init() is called so
> > > we
> > > need to postpone setting these ops until later, when we know which APIC
> > > mode
> > > is used.
> > > 
> > > (Note that currently x2APIC is never initialized on HVM guests. This may
> > > change in the future)
> > I take that this is safe because no MSIs can be received at this point
> > (apic_post_init), right?
> 
> 
> Yes. At the time apic_post_init() is called PCI has not been probed yet.

Please add that to the commit message.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:17:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHrm-00006P-Fb; Tue, 25 Nov 2014 15:17:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtHrl-00006I-0A
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:17:21 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C9/60-02957-08D94745; Tue, 25 Nov 2014 15:17:20 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416928638!14764802!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14196 invoked from network); 25 Nov 2014 15:17:19 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:17:19 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPFGiTf003460
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 15:16:45 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFGeP7028939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 15:16:41 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAPFGdh0007472; Tue, 25 Nov 2014 15:16:39 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 07:16:38 -0800
Message-ID: <54749E05.9030505@oracle.com>
Date: Tue, 25 Nov 2014 10:19:33 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-10-git-send-email-boris.ostrovsky@oracle.com>
	<547488C9020000780004AA8C@mail.emea.novell.com>
In-Reply-To: <547488C9020000780004AA8C@mail.emea.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 09/21] x86/VPMU: Add public xenpmu.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 07:48 AM, Jan Beulich wrote:
>>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
>> --- a/xen/include/xlat.lst
>> +++ b/xen/include/xlat.lst
>> @@ -103,6 +103,10 @@
>>   !	vcpu_set_singleshot_timer	vcpu.h
>>   ?	xenoprof_init			xenoprof.h
>>   ?	xenoprof_passive		xenoprof.h
>> +?	pmu_intel_ctxt			arch-x86/pmu.h
>> +?	pmu_amd_ctxt			arch-x86/pmu.h
>> +?	pmu_cntr_pair			arch-x86/pmu.h
>> +?	pmu_regs			arch-x86/pmu.h
> If another revision turns out necessary, please get these additions
> sorted alphabetically.

I haven't gone through your comments yet but there will be another spin: 
I discovered regression in non-enlightened (VPMU-wise) kernels that must 
have crept in somewhere between revisions.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:17:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHrm-00006P-Fb; Tue, 25 Nov 2014 15:17:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtHrl-00006I-0A
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:17:21 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C9/60-02957-08D94745; Tue, 25 Nov 2014 15:17:20 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416928638!14764802!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14196 invoked from network); 25 Nov 2014 15:17:19 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:17:19 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPFGiTf003460
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 15:16:45 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFGeP7028939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 15:16:41 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAPFGdh0007472; Tue, 25 Nov 2014 15:16:39 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 07:16:38 -0800
Message-ID: <54749E05.9030505@oracle.com>
Date: Tue, 25 Nov 2014 10:19:33 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-10-git-send-email-boris.ostrovsky@oracle.com>
	<547488C9020000780004AA8C@mail.emea.novell.com>
In-Reply-To: <547488C9020000780004AA8C@mail.emea.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 09/21] x86/VPMU: Add public xenpmu.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 07:48 AM, Jan Beulich wrote:
>>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
>> --- a/xen/include/xlat.lst
>> +++ b/xen/include/xlat.lst
>> @@ -103,6 +103,10 @@
>>   !	vcpu_set_singleshot_timer	vcpu.h
>>   ?	xenoprof_init			xenoprof.h
>>   ?	xenoprof_passive		xenoprof.h
>> +?	pmu_intel_ctxt			arch-x86/pmu.h
>> +?	pmu_amd_ctxt			arch-x86/pmu.h
>> +?	pmu_cntr_pair			arch-x86/pmu.h
>> +?	pmu_regs			arch-x86/pmu.h
> If another revision turns out necessary, please get these additions
> sorted alphabetically.

I haven't gone through your comments yet but there will be another spin: 
I discovered regression in non-enlightened (VPMU-wise) kernels that must 
have crept in somewhere between revisions.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:25:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:25:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHzK-0000Iw-Db; Tue, 25 Nov 2014 15:25:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtHzG-0000Io-M2
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:25:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	71/D6-15461-25F94745; Tue, 25 Nov 2014 15:25:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416929102!15258136!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4989 invoked from network); 25 Nov 2014 15:25:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:25:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196200800"
Message-ID: <1416928025.32327.41.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Date: Tue, 25 Nov 2014 15:07:05 +0000
In-Reply-To: <CAAHg+Hia=8Cm+MDJ4rTQxXR29PrKcj1qpZrD3774ekMAe5pV6A@mail.gmail.com>
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
	<CAAHg+Hia=8Cm+MDJ4rTQxXR29PrKcj1qpZrD3774ekMAe5pV6A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, xen-devel@lists.xen.org,
	Clark Laughlin <clark.laughlin@linaro.org>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 5/5] xen: arm: Support the other
 4 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 20:31 +0530, Pranavkumar Sawargaonkar wrote:

> Patch looks good.
> Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>

Thanks to Julien and you for the review.

Konrad already indicated that he was OK with this for 4.5, so committed.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:25:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:25:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtHzK-0000Iw-Db; Tue, 25 Nov 2014 15:25:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtHzG-0000Io-M2
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:25:08 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	71/D6-15461-25F94745; Tue, 25 Nov 2014 15:25:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416929102!15258136!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4989 invoked from network); 25 Nov 2014 15:25:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:25:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196200800"
Message-ID: <1416928025.32327.41.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Date: Tue, 25 Nov 2014 15:07:05 +0000
In-Reply-To: <CAAHg+Hia=8Cm+MDJ4rTQxXR29PrKcj1qpZrD3774ekMAe5pV6A@mail.gmail.com>
References: <1416410868.29243.39.camel@citrix.com>
	<1416410895-20461-5-git-send-email-ian.campbell@citrix.com>
	<CAAHg+Hia=8Cm+MDJ4rTQxXR29PrKcj1qpZrD3774ekMAe5pV6A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, xen-devel@lists.xen.org,
	Clark Laughlin <clark.laughlin@linaro.org>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 5/5] xen: arm: Support the other
 4 PCI buses on Xgene
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 20:31 +0530, Pranavkumar Sawargaonkar wrote:

> Patch looks good.
> Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>

Thanks to Julien and you for the review.

Konrad already indicated that he was OK with this for 4.5, so committed.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:28:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15: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 1XtI2I-0000PW-Vx; Tue, 25 Nov 2014 15:28:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XtI2H-0000PO-BV
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 15:28:13 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	6A/BE-22819-C00A4745; Tue, 25 Nov 2014 15:28:12 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416929290!13258819!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27897 invoked from network); 25 Nov 2014 15:28:11 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:28:11 -0000
Received: by mail-wg0-f49.google.com with SMTP id x12so1163829wgg.22
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Nov 2014 07:28:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=0CSnDuSMV6xgZjr0sZ1TKwivooUrcMQkXP8KxRq/BFs=;
	b=W/OSjkMUGvAZ8//MiLwKKHeH+6lNKJj1+WZcuVrDQH7F+29LyNkcQgWxf9dR5BwEcT
	63M+E6rDvAU6iNU526yCOjKupOkkqUclrNfPagE70We71/c8cbgNeAM5A6X4sK5rGc9c
	JOyYjGI7jhVzLp1fQDIvFXQh9RGuRtPnYin+E9Jw+9Eaq+N64LZdGL/WD9ZyxjHkfan+
	MYOIBtpedQqIrwAelUFB76UC/8y2Hvxn9vh2yuT0+5uS7sS5f7aXZ6lo1/m0Lk58UnoU
	fe/NA9e4/hmY+N9qyTFgAowalhbWqFwspdQScmQQ0jWmTV83gKRF7Pp0tMP+4nekEhAl
	FmLQ==
X-Gm-Message-State: ALoCoQn97dZQb3nYbgYPraC10gs0SwNbHMPXKUzZmp3bXoqDEkMB4t1REQHcncG/voEmN0fbtTYu
X-Received: by 10.180.198.145 with SMTP id jc17mr32736169wic.67.1416929290576; 
	Tue, 25 Nov 2014 07:28:10 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	l10sm16893561wif.20.2014.11.25.07.28.08 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 25 Nov 2014 07:28:09 -0800 (PST)
Message-ID: <5474A020.40103@m2r.biz>
Date: Tue, 25 Nov 2014 16:28:32 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	qemu-devel@nongnu.org
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
Cc: xen-devel@lists.xensource.com, wei Liu <wei.liu2@citrix.com>,
	wency@cn.fujitsu.com, mst@redhat.com, jasowang@redhat.com,
	pbonzini@redhat.com
Subject: Re: [Xen-devel] [PATCH 0/4] virtio-net: do not leak cpu mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 25/11/2014 15:42, Stefano Stabellini ha scritto:
> Hi all,
> this patch series fixes a cpu mapping leak in virtio-net.
>
> The bug is caused by virtio_net_handle_ctrl: it maps the entire out_sg
> iov, but then modifies it and reduces it (iov_discard_front), and only
> unmap the reduced version of the iov.
>
> This causes a crash when running on Xen, but the behaviour is obviously
> incorrect without Xen too.
>
> The patch series fixes the issue by allowing virtio_net_handle_ctrl to
> unmap the original out_sg iov but still call virtqueue_fill and
> virtqueue_flush on the modified iov.
>
> The first three patches do not introduce any functional changes.

Thanks for these pathes, 1-2 years ago I tried to use virtio net and 
disks on xen unsuccessful and I was unable to solve it.
When I'll have time I'll retry.
About virtio disks can have problem similar to this or should be ok?
About the other patches posted in link below are all not applied and 
should be only rebased or they must be fully revisioned/modified?
http://wiki.xen.org/wiki/Virtio_On_Xen

Thanks for any reply and sorry for my bad english.

>
>
> Stefano Stabellini (4):
>        introduce virtqueue_unmap_sg
>        use virtqueue_unmap_sg in virtqueue_fill
>        move virtqueue_unmap_sg calls from virtqueue_fill to virtqueue_push
>        virtio-net: do not leak cpu mappings
>
>   hw/net/virtio-net.c        |    9 ++++++++-
>   hw/virtio/virtio.c         |   43 ++++++++++++++++++++++++-------------------
>   include/hw/virtio/virtio.h |    2 ++
>   3 files changed, 34 insertions(+), 20 deletions(-)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:28:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15: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 1XtI2I-0000PW-Vx; Tue, 25 Nov 2014 15:28:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XtI2H-0000PO-BV
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 15:28:13 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	6A/BE-22819-C00A4745; Tue, 25 Nov 2014 15:28:12 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416929290!13258819!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27897 invoked from network); 25 Nov 2014 15:28:11 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:28:11 -0000
Received: by mail-wg0-f49.google.com with SMTP id x12so1163829wgg.22
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Nov 2014 07:28:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=0CSnDuSMV6xgZjr0sZ1TKwivooUrcMQkXP8KxRq/BFs=;
	b=W/OSjkMUGvAZ8//MiLwKKHeH+6lNKJj1+WZcuVrDQH7F+29LyNkcQgWxf9dR5BwEcT
	63M+E6rDvAU6iNU526yCOjKupOkkqUclrNfPagE70We71/c8cbgNeAM5A6X4sK5rGc9c
	JOyYjGI7jhVzLp1fQDIvFXQh9RGuRtPnYin+E9Jw+9Eaq+N64LZdGL/WD9ZyxjHkfan+
	MYOIBtpedQqIrwAelUFB76UC/8y2Hvxn9vh2yuT0+5uS7sS5f7aXZ6lo1/m0Lk58UnoU
	fe/NA9e4/hmY+N9qyTFgAowalhbWqFwspdQScmQQ0jWmTV83gKRF7Pp0tMP+4nekEhAl
	FmLQ==
X-Gm-Message-State: ALoCoQn97dZQb3nYbgYPraC10gs0SwNbHMPXKUzZmp3bXoqDEkMB4t1REQHcncG/voEmN0fbtTYu
X-Received: by 10.180.198.145 with SMTP id jc17mr32736169wic.67.1416929290576; 
	Tue, 25 Nov 2014 07:28:10 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	l10sm16893561wif.20.2014.11.25.07.28.08 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 25 Nov 2014 07:28:09 -0800 (PST)
Message-ID: <5474A020.40103@m2r.biz>
Date: Tue, 25 Nov 2014 16:28:32 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	qemu-devel@nongnu.org
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
Cc: xen-devel@lists.xensource.com, wei Liu <wei.liu2@citrix.com>,
	wency@cn.fujitsu.com, mst@redhat.com, jasowang@redhat.com,
	pbonzini@redhat.com
Subject: Re: [Xen-devel] [PATCH 0/4] virtio-net: do not leak cpu mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 25/11/2014 15:42, Stefano Stabellini ha scritto:
> Hi all,
> this patch series fixes a cpu mapping leak in virtio-net.
>
> The bug is caused by virtio_net_handle_ctrl: it maps the entire out_sg
> iov, but then modifies it and reduces it (iov_discard_front), and only
> unmap the reduced version of the iov.
>
> This causes a crash when running on Xen, but the behaviour is obviously
> incorrect without Xen too.
>
> The patch series fixes the issue by allowing virtio_net_handle_ctrl to
> unmap the original out_sg iov but still call virtqueue_fill and
> virtqueue_flush on the modified iov.
>
> The first three patches do not introduce any functional changes.

Thanks for these pathes, 1-2 years ago I tried to use virtio net and 
disks on xen unsuccessful and I was unable to solve it.
When I'll have time I'll retry.
About virtio disks can have problem similar to this or should be ok?
About the other patches posted in link below are all not applied and 
should be only rebased or they must be fully revisioned/modified?
http://wiki.xen.org/wiki/Virtio_On_Xen

Thanks for any reply and sorry for my bad english.

>
>
> Stefano Stabellini (4):
>        introduce virtqueue_unmap_sg
>        use virtqueue_unmap_sg in virtqueue_fill
>        move virtqueue_unmap_sg calls from virtqueue_fill to virtqueue_push
>        virtio-net: do not leak cpu mappings
>
>   hw/net/virtio-net.c        |    9 ++++++++-
>   hw/virtio/virtio.c         |   43 ++++++++++++++++++++++++-------------------
>   include/hw/virtio/virtio.h |    2 ++
>   3 files changed, 34 insertions(+), 20 deletions(-)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:33:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:33:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtI7F-0000dG-Ol; Tue, 25 Nov 2014 15:33:21 +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 1XtI7E-0000dB-RV
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:33:21 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	F8/89-11581-041A4745; Tue, 25 Nov 2014 15:33:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416929596!5701468!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9803 invoked from network); 25 Nov 2014 15:33:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:33:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196204807"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 10:13:36 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XtHo8-0004A5-5o;
	Tue, 25 Nov 2014 15:13:36 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 25 Nov 2014 15:13:36 +0000
Message-ID: <1416928416-21329-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: allow copying between bitmaps of
	different sizes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 parsing bitmap objects JSON parser will create libxl_bitmap map of the
smallest size needed.

This can cause problems when saved image file specifies CPU affinity.  For
example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
specified, just a single byte will be allocated and libxl_bitmap->size will be
set to 1.

This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
since the destination bitmap is created for maximum number of CPUs.

We could allocate that bitmap of the same size as the source, however, it is
later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
number of CPUs

To fix this issue, introduce an internal function to allowing copying between
bitmaps of different sizes. Note that this function is only used in
libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invokes
libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
placement logic comes into effect when no vcpu / node pinning is provided, so
it always operates on bitmap of the same sizes (that is, size of maximum
number of cpus /nodes).

Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
---
This fixes a regression for 4.5. Can't think of obvious risk.
---
 tools/libxl/libxl.c          |    4 ++--
 tools/libxl/libxl_internal.h |   11 +++++++++++
 tools/libxl/libxl_utils.c    |   15 +++++++++++++++
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..1e9da10 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5320,7 +5320,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
+        libxl__bitmap_copy_best_effort(gc, &hard, cpumap_hard);
         flags = XEN_VCPUAFFINITY_HARD;
     }
     if (cpumap_soft) {
@@ -5328,7 +5328,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
+        libxl__bitmap_copy_best_effort(gc, &soft, cpumap_soft);
         flags |= XEN_VCPUAFFINITY_SOFT;
     }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..a38f695 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3617,6 +3617,17 @@ static inline void libxl__update_config_vtpm(libxl__gc *gc,
         libxl_device_##type##_copy(CTX, DA_p, (dev));           \
     })
 
+/* This function copies X bytes from source to destination bitmap,
+ * where X is the smaller of the two sizes.
+ *
+ * If destination's size is larger than source, the extra bytes are
+ * untouched.
+ *
+ * XXX This is introduced to fix a regression for 4.5. It shall
+ * be revisited in 4.6 time frame.
+ */
+void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
+                                    const libxl_bitmap *sptr);
 #endif
 
 /*
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 58df4f3..3e1ba17 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -614,6 +614,21 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
     memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
 }
 
+/* This function copies X bytes from source to destination bitmap,
+ * where X is the smaller of the two sizes.
+ *
+ * If destination's size is larger than source, the extra bytes are
+ * untouched.
+ */
+void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
+                                    const libxl_bitmap *sptr)
+{
+    int sz;
+
+    sz = dptr->size < sptr->size ? dptr->size : sptr->size;
+    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
+}
+
 void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
                              libxl_bitmap *dptr,
                              const libxl_bitmap *sptr)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:33:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:33:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtI7F-0000dG-Ol; Tue, 25 Nov 2014 15:33:21 +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 1XtI7E-0000dB-RV
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:33:21 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	F8/89-11581-041A4745; Tue, 25 Nov 2014 15:33:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416929596!5701468!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9803 invoked from network); 25 Nov 2014 15:33:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:33:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196204807"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 10:13:36 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XtHo8-0004A5-5o;
	Tue, 25 Nov 2014 15:13:36 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 25 Nov 2014 15:13:36 +0000
Message-ID: <1416928416-21329-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: allow copying between bitmaps of
	different sizes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 parsing bitmap objects JSON parser will create libxl_bitmap map of the
smallest size needed.

This can cause problems when saved image file specifies CPU affinity.  For
example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
specified, just a single byte will be allocated and libxl_bitmap->size will be
set to 1.

This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
since the destination bitmap is created for maximum number of CPUs.

We could allocate that bitmap of the same size as the source, however, it is
later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
number of CPUs

To fix this issue, introduce an internal function to allowing copying between
bitmaps of different sizes. Note that this function is only used in
libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invokes
libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
placement logic comes into effect when no vcpu / node pinning is provided, so
it always operates on bitmap of the same sizes (that is, size of maximum
number of cpus /nodes).

Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
---
This fixes a regression for 4.5. Can't think of obvious risk.
---
 tools/libxl/libxl.c          |    4 ++--
 tools/libxl/libxl_internal.h |   11 +++++++++++
 tools/libxl/libxl_utils.c    |   15 +++++++++++++++
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..1e9da10 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5320,7 +5320,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
+        libxl__bitmap_copy_best_effort(gc, &hard, cpumap_hard);
         flags = XEN_VCPUAFFINITY_HARD;
     }
     if (cpumap_soft) {
@@ -5328,7 +5328,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
         if (rc)
             goto out;
 
-        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
+        libxl__bitmap_copy_best_effort(gc, &soft, cpumap_soft);
         flags |= XEN_VCPUAFFINITY_SOFT;
     }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..a38f695 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3617,6 +3617,17 @@ static inline void libxl__update_config_vtpm(libxl__gc *gc,
         libxl_device_##type##_copy(CTX, DA_p, (dev));           \
     })
 
+/* This function copies X bytes from source to destination bitmap,
+ * where X is the smaller of the two sizes.
+ *
+ * If destination's size is larger than source, the extra bytes are
+ * untouched.
+ *
+ * XXX This is introduced to fix a regression for 4.5. It shall
+ * be revisited in 4.6 time frame.
+ */
+void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
+                                    const libxl_bitmap *sptr);
 #endif
 
 /*
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 58df4f3..3e1ba17 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -614,6 +614,21 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
     memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
 }
 
+/* This function copies X bytes from source to destination bitmap,
+ * where X is the smaller of the two sizes.
+ *
+ * If destination's size is larger than source, the extra bytes are
+ * untouched.
+ */
+void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
+                                    const libxl_bitmap *sptr)
+{
+    int sz;
+
+    sz = dptr->size < sptr->size ? dptr->size : sptr->size;
+    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
+}
+
 void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
                              libxl_bitmap *dptr,
                              const libxl_bitmap *sptr)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:41:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:41:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIFG-0000nX-Tg; Tue, 25 Nov 2014 15:41:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1XtIFF-0000nS-MR
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 15:41:37 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	0E/4B-23865-133A4745; Tue, 25 Nov 2014 15:41:37 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416930094!13793617!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30642 invoked from network); 25 Nov 2014 15:41:36 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:41:36 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPFfTkT017883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 25 Nov 2014 10:41:29 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAPFfPEx012951
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 10:41:27 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: "Jan Beulich" <JBeulich@suse.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	<1412687413-22818-4-git-send-email-vkuznets@redhat.com>
	<5474A568020000780004AB93@mail.emea.novell.com>
Date: Tue, 25 Nov 2014 16:41:25 +0100
In-Reply-To: <5474A568020000780004AB93@mail.emea.novell.com> (Jan Beulich's
	message of "Tue, 25 Nov 2014 14:51:04 +0000")
Message-ID: <8761e35lui.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 3/8] xen: introduce
	XEN_DOMCTL_set_recipient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Jan Beulich" <JBeulich@suse.com> writes:

Thanks for the review!

>>>> On 07.10.14 at 15:10, <vkuznets@redhat.com> wrote:
>> New operation sets the 'recipient' domain which will recieve all
>> memory pages from a particular domain when these pages are freed.
>
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -1152,6 +1152,33 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>      }
>>      break;
>>  
>> +    case XEN_DOMCTL_set_recipient:
>> +    {
>> +        struct domain *recipient_dom;
>> +
>> +        if ( op->u.recipient.recipient == DOMID_INVALID )
>> +        {
>> +            if ( d->recipient )
>> +            {
>> +                put_domain(d->recipient);
>> +            }
>
> Please drop pointless braces like these and ...
>
>> +            d->recipient = NULL;
>> +            break;
>> +        }
>> +
>> +        recipient_dom = get_domain_by_id(op->u.recipient.recipient);
>> +        if ( recipient_dom == NULL )
>> +        {
>> +            ret = -ESRCH;
>> +            break;
>> +        }
>> +        else
>> +        {
>> +            d->recipient = recipient_dom;
>> +        }
>
> ... the pointless else-s/break-s like here.
>
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -1707,6 +1707,7 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>>  {
>>      struct domain *d = page_get_owner(pg);
>>      unsigned int i;
>> +    unsigned long mfn, gmfn;
>>      bool_t drop_dom_ref;
>>  
>>      ASSERT(!in_irq());
>> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>>              scrub = 1;
>>          }
>>  
>> -        if ( unlikely(scrub) )
>> -            for ( i = 0; i < (1 << order); i++ )
>> -                scrub_one_page(&pg[i]);
>> +        if ( !d || !d->recipient || d->recipient->is_dying )
>> +        {
>> +            if ( unlikely(scrub) )
>> +                for ( i = 0; i < (1 << order); i++ )
>> +                    scrub_one_page(&pg[i]);
>>  
>> -        free_heap_pages(pg, order);
>> +            free_heap_pages(pg, order);
>> +        }
>> +        else
>> +        {
>> +            mfn = page_to_mfn(pg);
>> +            gmfn = mfn_to_gmfn(d, mfn);
>> +
>> +            page_set_owner(pg, NULL);
>> +            assign_pages(d->recipient, pg, order, 0);
>
> This can fail.

.. if the recipient is dying or we're over-allocating. Shouldn't happen
(if toolstack does its job right) but I'll add a check.

>
>> +
>> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
>> +            {
>> +                gdprintk(XENLOG_INFO, "Failed to add page to domain's physmap"
>> +                         " mfn: %lx\n", mfn);
>
> The current domain/vCPU don't matter here afaict, hence no need
> for gdprintk(). The source and/or recipient domain do matter though,
> hence printing either or both would seem desirable. The gMFN may
> be relevant for diagnostic purposes too. Hence e.g.
>
>                 printk(XENLOG_G_INFO "Failed to add MFN %lx (GFN %lx) to Dom%d's physmap\n"
>                        mfn, gmfn, d->recipient->domain_id);
>
> What's worse though is that you don't guard against
> XEN_DOMCTL_set_recipient zapping d->recipient. If that really is
> necessary to be supported, some synchronization will be needed.
>
> And finally - what's the intended protocol for the tool stack to
> know that all pages got transferred (and hence the new domain
> can be launched)?
>

(hope this answers both questions above)

Now the protocol is:
1) Toolstack queries for all page frames (with xc_get_pfn_type_batch())
for the old domain.
2) Toolstack issues XEN_DOMCTL_set_recipient with the recipient domain
3) Toolstack kills the source domain
4) Toolstack waits for awhile (loop keeps checking while we see new pages
arriving + some timeout).
5) Toolstack issues XEN_DOMCTL_set_recipient with DOMID_INVALID
resetting recipient.
6) Toolstack checks if all pages were transferred
7) If some pages are missing (e.g. source domain became zombie holding
something) request new empty pages instead.
8) Toolstack starts new domain

So we don't actually need XEN_DOMCTL_set_recipient to switch from one
recipient to the other, we just need a way to reset it.

>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -965,6 +965,23 @@ struct xen_domctl_vnuma {
>>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
>>  
>> +/*
>> + * XEN_DOMCTL_set_recipient - sets the 'recipient' domain which will recieve
>> + * all the domain's memory after its death or when and memory page from
>> + * domain's heap is being freed.
>
> So this specifically allows for this to happen on a non-dying domain.
> Why, i.e. what's the intended usage scenario? If not really needed,
> please remove this and verify in the handling that the source domain
> is dying.

Sorry if I didn't get this comment right. We need a way to tell which
domain will recieve memory and XEN_DOMCTL_set_recipient sets (and
resets) this target domain. We call it from toolstack before we start
killing old domain so it is not dying yet. We can't do it
hypervistor-side when our source domain exits doing SHUTDOWN_soft_reset
as there is no recipient domain created yet.

>From a general (hypervisor) point of view we don't actually care if the
domain is dying or not. We just want to recieve all freed pages from
this domain (so they go to some other domain instead of trash).

>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -366,6 +366,7 @@ struct domain
>>      bool_t           is_privileged;
>>      /* Which guest this guest has privileges on */
>>      struct domain   *target;
>> +    struct domain   *recipient;
>
> Please add a brief comment similar to the one for "target".
>

Thanks again,

-- 
  Vitaly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:41:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:41:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIFG-0000nX-Tg; Tue, 25 Nov 2014 15:41:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1XtIFF-0000nS-MR
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 15:41:37 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	0E/4B-23865-133A4745; Tue, 25 Nov 2014 15:41:37 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416930094!13793617!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30642 invoked from network); 25 Nov 2014 15:41:36 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:41:36 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPFfTkT017883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 25 Nov 2014 10:41:29 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAPFfPEx012951
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 10:41:27 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: "Jan Beulich" <JBeulich@suse.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	<1412687413-22818-4-git-send-email-vkuznets@redhat.com>
	<5474A568020000780004AB93@mail.emea.novell.com>
Date: Tue, 25 Nov 2014 16:41:25 +0100
In-Reply-To: <5474A568020000780004AB93@mail.emea.novell.com> (Jan Beulich's
	message of "Tue, 25 Nov 2014 14:51:04 +0000")
Message-ID: <8761e35lui.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 3/8] xen: introduce
	XEN_DOMCTL_set_recipient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Jan Beulich" <JBeulich@suse.com> writes:

Thanks for the review!

>>>> On 07.10.14 at 15:10, <vkuznets@redhat.com> wrote:
>> New operation sets the 'recipient' domain which will recieve all
>> memory pages from a particular domain when these pages are freed.
>
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -1152,6 +1152,33 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>      }
>>      break;
>>  
>> +    case XEN_DOMCTL_set_recipient:
>> +    {
>> +        struct domain *recipient_dom;
>> +
>> +        if ( op->u.recipient.recipient == DOMID_INVALID )
>> +        {
>> +            if ( d->recipient )
>> +            {
>> +                put_domain(d->recipient);
>> +            }
>
> Please drop pointless braces like these and ...
>
>> +            d->recipient = NULL;
>> +            break;
>> +        }
>> +
>> +        recipient_dom = get_domain_by_id(op->u.recipient.recipient);
>> +        if ( recipient_dom == NULL )
>> +        {
>> +            ret = -ESRCH;
>> +            break;
>> +        }
>> +        else
>> +        {
>> +            d->recipient = recipient_dom;
>> +        }
>
> ... the pointless else-s/break-s like here.
>
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -1707,6 +1707,7 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>>  {
>>      struct domain *d = page_get_owner(pg);
>>      unsigned int i;
>> +    unsigned long mfn, gmfn;
>>      bool_t drop_dom_ref;
>>  
>>      ASSERT(!in_irq());
>> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>>              scrub = 1;
>>          }
>>  
>> -        if ( unlikely(scrub) )
>> -            for ( i = 0; i < (1 << order); i++ )
>> -                scrub_one_page(&pg[i]);
>> +        if ( !d || !d->recipient || d->recipient->is_dying )
>> +        {
>> +            if ( unlikely(scrub) )
>> +                for ( i = 0; i < (1 << order); i++ )
>> +                    scrub_one_page(&pg[i]);
>>  
>> -        free_heap_pages(pg, order);
>> +            free_heap_pages(pg, order);
>> +        }
>> +        else
>> +        {
>> +            mfn = page_to_mfn(pg);
>> +            gmfn = mfn_to_gmfn(d, mfn);
>> +
>> +            page_set_owner(pg, NULL);
>> +            assign_pages(d->recipient, pg, order, 0);
>
> This can fail.

.. if the recipient is dying or we're over-allocating. Shouldn't happen
(if toolstack does its job right) but I'll add a check.

>
>> +
>> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
>> +            {
>> +                gdprintk(XENLOG_INFO, "Failed to add page to domain's physmap"
>> +                         " mfn: %lx\n", mfn);
>
> The current domain/vCPU don't matter here afaict, hence no need
> for gdprintk(). The source and/or recipient domain do matter though,
> hence printing either or both would seem desirable. The gMFN may
> be relevant for diagnostic purposes too. Hence e.g.
>
>                 printk(XENLOG_G_INFO "Failed to add MFN %lx (GFN %lx) to Dom%d's physmap\n"
>                        mfn, gmfn, d->recipient->domain_id);
>
> What's worse though is that you don't guard against
> XEN_DOMCTL_set_recipient zapping d->recipient. If that really is
> necessary to be supported, some synchronization will be needed.
>
> And finally - what's the intended protocol for the tool stack to
> know that all pages got transferred (and hence the new domain
> can be launched)?
>

(hope this answers both questions above)

Now the protocol is:
1) Toolstack queries for all page frames (with xc_get_pfn_type_batch())
for the old domain.
2) Toolstack issues XEN_DOMCTL_set_recipient with the recipient domain
3) Toolstack kills the source domain
4) Toolstack waits for awhile (loop keeps checking while we see new pages
arriving + some timeout).
5) Toolstack issues XEN_DOMCTL_set_recipient with DOMID_INVALID
resetting recipient.
6) Toolstack checks if all pages were transferred
7) If some pages are missing (e.g. source domain became zombie holding
something) request new empty pages instead.
8) Toolstack starts new domain

So we don't actually need XEN_DOMCTL_set_recipient to switch from one
recipient to the other, we just need a way to reset it.

>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -965,6 +965,23 @@ struct xen_domctl_vnuma {
>>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
>>  
>> +/*
>> + * XEN_DOMCTL_set_recipient - sets the 'recipient' domain which will recieve
>> + * all the domain's memory after its death or when and memory page from
>> + * domain's heap is being freed.
>
> So this specifically allows for this to happen on a non-dying domain.
> Why, i.e. what's the intended usage scenario? If not really needed,
> please remove this and verify in the handling that the source domain
> is dying.

Sorry if I didn't get this comment right. We need a way to tell which
domain will recieve memory and XEN_DOMCTL_set_recipient sets (and
resets) this target domain. We call it from toolstack before we start
killing old domain so it is not dying yet. We can't do it
hypervistor-side when our source domain exits doing SHUTDOWN_soft_reset
as there is no recipient domain created yet.

>From a general (hypervisor) point of view we don't actually care if the
domain is dying or not. We just want to recieve all freed pages from
this domain (so they go to some other domain instead of trash).

>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -366,6 +366,7 @@ struct domain
>>      bool_t           is_privileged;
>>      /* Which guest this guest has privileges on */
>>      struct domain   *target;
>> +    struct domain   *recipient;
>
> Please add a brief comment similar to the one for "target".
>

Thanks again,

-- 
  Vitaly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:42:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15: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 1XtIFz-0000se-B1; Tue, 25 Nov 2014 15:42:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtIFx-0000sT-CZ
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:42:21 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2A/86-09842-C53A4745; Tue, 25 Nov 2014 15:42:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416930138!15277907!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2046 invoked from network); 25 Nov 2014 15:42:20 -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;
	25 Nov 2014 15:42:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196209832"
Message-ID: <1416928910.16769.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 25 Nov 2014 15:21:50 +0000
In-Reply-To: <1416928416-21329-1-git-send-email-wei.liu2@citrix.com>
References: <1416928416-21329-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: allow copying between
 bitmaps of different sizes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 15:13 +0000, Wei Liu wrote:
> When parsing bitmap objects JSON parser will create libxl_bitmap map of the
> smallest size needed.
> 
> This can cause problems when saved image file specifies CPU affinity.  For
> example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
> specified, just a single byte will be allocated and libxl_bitmap->size will be
> set to 1.
> 
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> since the destination bitmap is created for maximum number of CPUs.
> 
> We could allocate that bitmap of the same size as the source, however, it is
> later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
> number of CPUs
> 
> To fix this issue, introduce an internal function to allowing copying between
> bitmaps of different sizes. Note that this function is only used in
> libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invokes
> libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
> placement logic comes into effect when no vcpu / node pinning is provided, so
> it always operates on bitmap of the same sizes (that is, size of maximum
> number of cpus /nodes).
> 
> Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:42:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15: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 1XtIFz-0000se-B1; Tue, 25 Nov 2014 15:42:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtIFx-0000sT-CZ
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:42:21 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2A/86-09842-C53A4745; Tue, 25 Nov 2014 15:42:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416930138!15277907!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2046 invoked from network); 25 Nov 2014 15:42:20 -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;
	25 Nov 2014 15:42:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196209832"
Message-ID: <1416928910.16769.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 25 Nov 2014 15:21:50 +0000
In-Reply-To: <1416928416-21329-1-git-send-email-wei.liu2@citrix.com>
References: <1416928416-21329-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: allow copying between
 bitmaps of different sizes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 15:13 +0000, Wei Liu wrote:
> When parsing bitmap objects JSON parser will create libxl_bitmap map of the
> smallest size needed.
> 
> This can cause problems when saved image file specifies CPU affinity.  For
> example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
> specified, just a single byte will be allocated and libxl_bitmap->size will be
> set to 1.
> 
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> since the destination bitmap is created for maximum number of CPUs.
> 
> We could allocate that bitmap of the same size as the source, however, it is
> later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
> number of CPUs
> 
> To fix this issue, introduce an internal function to allowing copying between
> bitmaps of different sizes. Note that this function is only used in
> libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invokes
> libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
> placement logic comes into effect when no vcpu / node pinning is provided, so
> it always operates on bitmap of the same sizes (that is, size of maximum
> number of cpus /nodes).
> 
> Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:43:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:43:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIHB-00011Q-Q0; Tue, 25 Nov 2014 15:43: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@citrix.com>) id 1XtIH9-00011C-GJ
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 15:43:35 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	2D/6C-19763-6A3A4745; Tue, 25 Nov 2014 15:43:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416930211!13311839!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30645 invoked from network); 25 Nov 2014 15:43:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:43:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196604213"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 10:43:29 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtIH3-0003GN-FI;
	Tue, 25 Nov 2014 15:43:29 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtIH3-00043f-4s;
	Tue, 25 Nov 2014 15:43:29 +0000
Date: Tue, 25 Nov 2014 15:43:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31844-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31844: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31844 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31844/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot            fail pass in 31817
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install      fail pass in 31817

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31817 never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 33063 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 Nov 25 15:43:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:43:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIHB-00011Q-Q0; Tue, 25 Nov 2014 15:43: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@citrix.com>) id 1XtIH9-00011C-GJ
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 15:43:35 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	2D/6C-19763-6A3A4745; Tue, 25 Nov 2014 15:43:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416930211!13311839!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30645 invoked from network); 25 Nov 2014 15:43:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:43:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196604213"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 10:43:29 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtIH3-0003GN-FI;
	Tue, 25 Nov 2014 15:43:29 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtIH3-00043f-4s;
	Tue, 25 Nov 2014 15:43:29 +0000
Date: Tue, 25 Nov 2014 15:43:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31844-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31844: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31844 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31844/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot            fail pass in 31817
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install      fail pass in 31817

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31817 never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 33063 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 Nov 25 15:49:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15: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 1XtIMm-0001Ey-Iy; Tue, 25 Nov 2014 15:49:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtIMl-0001Et-Bm
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 15:49:23 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	E3/E4-05632-205A4745; Tue, 25 Nov 2014 15:49:22 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416930558!13732357!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26314 invoked from network); 25 Nov 2014 15:49:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:49:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196214335"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 10:28:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtI2c-0004Ut-1C;
	Tue, 25 Nov 2014 15:28:34 +0000
Date: Tue, 25 Nov 2014 15:28:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Peter Maydell <peter.maydell@linaro.org>
In-Reply-To: <CAFEAcA9Ycghd_vOsdzHjTFUbCGtBgdH7WqZ6imfvNt5HxgqF-g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411251527510.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
	<1416926603-12397-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAFEAcA9Ycghd_vOsdzHjTFUbCGtBgdH7WqZ6imfvNt5HxgqF-g@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] introduce
	virtqueue_unmap_sg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Peter Maydell wrote:
> On 25 November 2014 at 14:43, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > Introduce a function to unmap an sg previously mapped with
> > virtqueue_map_sg.
> >
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: jasowang@redhat.com
> > CC: wency@cn.fujitsu.com
> > CC: mst@redhat.com
> > CC: pbonzini@redhat.com
> > ---
> >  hw/virtio/virtio.c         |   22 ++++++++++++++++++++++
> >  include/hw/virtio/virtio.h |    2 ++
> >  2 files changed, 24 insertions(+)
> >
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index 3e4b70c..2621ae6 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -446,6 +446,28 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
> >      }
> >  }
> >
> > +void virtqueue_unmap_sg(const struct iovec *sg, size_t num_sg,
> > +                        int is_write, unsigned int len)
> > +{
> > +    unsigned int i;
> > +    unsigned int offset;
> > +
> > +    if (num_sg > VIRTQUEUE_MAX_SIZE) {
> > +        error_report("virtio: unmap attempt out of bounds: %zd > %d",
> > +                     num_sg, VIRTQUEUE_MAX_SIZE);
> > +        exit(1);
> > +    }
> > +
> > +    offset = 0;
> > +    for (i = 0; i < num_sg; i++) {
> > +        size_t size = MIN(len - offset, sg[i].iov_len);
> > +
> > +        cpu_physical_memory_unmap(sg[i].iov_base, sg[i].iov_len, is_write, size);
> > +
> > +        offset += size;
> > +    }
> > +}
> 
> It seems rather odd that "size" and the iov_len fields in
> the iovec are size_t but 'len' and 'offset' are only
> unsigned int...

The code is taken from virtqueue_fill but that's a good point.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:49:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15: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 1XtIMm-0001Ey-Iy; Tue, 25 Nov 2014 15:49:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtIMl-0001Et-Bm
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 15:49:23 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	E3/E4-05632-205A4745; Tue, 25 Nov 2014 15:49:22 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416930558!13732357!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26314 invoked from network); 25 Nov 2014 15:49:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:49:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196214335"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 10:28:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtI2c-0004Ut-1C;
	Tue, 25 Nov 2014 15:28:34 +0000
Date: Tue, 25 Nov 2014 15:28:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Peter Maydell <peter.maydell@linaro.org>
In-Reply-To: <CAFEAcA9Ycghd_vOsdzHjTFUbCGtBgdH7WqZ6imfvNt5HxgqF-g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1411251527510.2675@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
	<1416926603-12397-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAFEAcA9Ycghd_vOsdzHjTFUbCGtBgdH7WqZ6imfvNt5HxgqF-g@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] introduce
	virtqueue_unmap_sg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Peter Maydell wrote:
> On 25 November 2014 at 14:43, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > Introduce a function to unmap an sg previously mapped with
> > virtqueue_map_sg.
> >
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: jasowang@redhat.com
> > CC: wency@cn.fujitsu.com
> > CC: mst@redhat.com
> > CC: pbonzini@redhat.com
> > ---
> >  hw/virtio/virtio.c         |   22 ++++++++++++++++++++++
> >  include/hw/virtio/virtio.h |    2 ++
> >  2 files changed, 24 insertions(+)
> >
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index 3e4b70c..2621ae6 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -446,6 +446,28 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
> >      }
> >  }
> >
> > +void virtqueue_unmap_sg(const struct iovec *sg, size_t num_sg,
> > +                        int is_write, unsigned int len)
> > +{
> > +    unsigned int i;
> > +    unsigned int offset;
> > +
> > +    if (num_sg > VIRTQUEUE_MAX_SIZE) {
> > +        error_report("virtio: unmap attempt out of bounds: %zd > %d",
> > +                     num_sg, VIRTQUEUE_MAX_SIZE);
> > +        exit(1);
> > +    }
> > +
> > +    offset = 0;
> > +    for (i = 0; i < num_sg; i++) {
> > +        size_t size = MIN(len - offset, sg[i].iov_len);
> > +
> > +        cpu_physical_memory_unmap(sg[i].iov_base, sg[i].iov_len, is_write, size);
> > +
> > +        offset += size;
> > +    }
> > +}
> 
> It seems rather odd that "size" and the iov_len fields in
> the iovec are size_t but 'len' and 'offset' are only
> unsigned int...

The code is taken from virtqueue_fill but that's a good point.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:50:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtINV-0001I6-4b; Tue, 25 Nov 2014 15:50:09 +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 1XtINT-0001Ht-AG
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 15:50:07 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	F1/15-27785-E25A4745; Tue, 25 Nov 2014 15:50:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416930604!11440516!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6200 invoked from network); 25 Nov 2014 15:50:05 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:50:05 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPFo2Fb019343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 15:50:03 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFo1N9011477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 15:50:01 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFo1fh011428; Tue, 25 Nov 2014 15:50:01 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 07:50:00 -0800
Date: Tue, 25 Nov 2014 10:49:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141125154958.GD29886@konrad-lan.dumpdata.com>
References: <547485D8020000780004AA76@mail.emea.novell.com>
	<54749C2B020000780004AB42@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54749C2B020000780004AB42@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] vNUMA: rename interface 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

On Tue, Nov 25, 2014 at 02:11:39PM +0000, Jan Beulich wrote:
> >>> On 25.11.14 at 13:36, <JBeulich@suse.com> wrote:
> > No-one (including me) paid attention during review that these
> > structures don't adhere to the naming requirements of the public
> > interface: Consistently use xen_ prefixes at least for all new
> > additions.
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Sorry, again forgot to Cc you (for 4.5): No functional change, but
> avoiding a later (incompatible) interface change.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


> 
> Jan
> 
> > --- a/tools/libxc/include/xenctrl.h
> > +++ b/tools/libxc/include/xenctrl.h
> > @@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface *xch
> >                          uint32_t nr_vnodes,
> >                          uint32_t nr_regions,
> >                          uint32_t nr_vcpus,
> > -                        vmemrange_t *vmemrange,
> > +                        xen_vmemrange_t *vmemrange,
> >                          unsigned int *vdistance,
> >                          unsigned int *vcpu_to_vnode,
> >                          unsigned int *vnode_to_pnode);
> > --- a/tools/libxc/xc_domain.c
> > +++ b/tools/libxc/xc_domain.c
> > @@ -2171,7 +2171,7 @@ int xc_domain_setvnuma(xc_interface *xch
> >                         uint32_t nr_vnodes,
> >                         uint32_t nr_vmemranges,
> >                         uint32_t nr_vcpus,
> > -                       vmemrange_t *vmemrange,
> > +                       xen_vmemrange_t *vmemrange,
> >                         unsigned int *vdistance,
> >                         unsigned int *vcpu_to_vnode,
> >                         unsigned int *vnode_to_pnode)
> > --- a/xen/common/domctl.c
> > +++ b/xen/common/domctl.c
> > @@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un
> >      vnuma->vdistance = xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);
> >      vnuma->vcpu_to_vnode = xmalloc_array(unsigned int, nr_vcpus);
> >      vnuma->vnode_to_pnode = xmalloc_array(unsigned int, nr_vnodes);
> > -    vnuma->vmemrange = xmalloc_array(vmemrange_t, nr_ranges);
> > +    vnuma->vmemrange = xmalloc_array(xen_vmemrange_t, nr_ranges);
> >  
> >      if ( vnuma->vdistance == NULL || vnuma->vmemrange == NULL ||
> >           vnuma->vcpu_to_vnode == NULL || vnuma->vnode_to_pnode == NULL )
> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -972,7 +972,7 @@ long do_memory_op(unsigned long cmd, XEN
> >  
> >      case XENMEM_get_vnumainfo:
> >      {
> > -        struct vnuma_topology_info topology;
> > +        struct xen_vnuma_topology_info topology;
> >          struct domain *d;
> >          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
> >          struct vnuma_info tmp;
> > @@ -1033,7 +1033,7 @@ long do_memory_op(unsigned long cmd, XEN
> >          read_unlock(&d->vnuma_rwlock);
> >  
> >          tmp.vdistance = xmalloc_array(unsigned int, dom_vnodes * 
> > dom_vnodes);
> > -        tmp.vmemrange = xmalloc_array(vmemrange_t, dom_vranges);
> > +        tmp.vmemrange = xmalloc_array(xen_vmemrange_t, dom_vranges);
> >          tmp.vcpu_to_vnode = xmalloc_array(unsigned int, dom_vcpus);
> >  
> >          if ( tmp.vdistance == NULL ||
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -980,7 +980,7 @@ struct xen_domctl_vnuma {
> >      /*
> >       * memory rages for each vNUMA node
> >       */
> > -    XEN_GUEST_HANDLE_64(vmemrange_t) vmemrange;
> > +    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
> >  };
> >  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_
> >  #define XENMEM_get_vnumainfo                26
> >  
> >  /* vNUMA node memory ranges */
> > -struct vmemrange {
> > +struct xen_vmemrange {
> >      uint64_t start, end;
> >      unsigned int flags;
> >      unsigned int nid;
> >  };
> > -
> > -typedef struct vmemrange vmemrange_t;
> > -DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
> > +typedef struct xen_vmemrange xen_vmemrange_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
> >  
> >  /*
> >   * vNUMA topology specifies vNUMA node number, distance table,
> > @@ -548,7 +547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
> >   * copied back to guest. Domain returns expected values of nr_vnodes,
> >   * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
> >   */
> > -struct vnuma_topology_info {
> > +struct xen_vnuma_topology_info {
> >      /* IN */
> >      domid_t domid;
> >      uint16_t pad;
> > @@ -566,12 +565,12 @@ struct vnuma_topology_info {
> >          uint64_t pad;
> >      } vcpu_to_vnode;
> >      union {
> > -        XEN_GUEST_HANDLE(vmemrange_t) h;
> > +        XEN_GUEST_HANDLE(xen_vmemrange_t) h;
> >          uint64_t pad;
> >      } vmemrange;
> >  };
> > -typedef struct vnuma_topology_info vnuma_topology_info_t;
> > -DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);
> > +typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
> >  
> >  /* Next available subop number is 27 */
> >  
> > --- a/xen/include/xen/domain.h
> > +++ b/xen/include/xen/domain.h
> > @@ -100,7 +100,7 @@ struct vnuma_info {
> >      unsigned int *vdistance;
> >      unsigned int *vcpu_to_vnode;
> >      unsigned int *vnode_to_pnode;
> > -    struct vmemrange *vmemrange;
> > +    struct xen_vmemrange *vmemrange;
> >  };
> >  
> >  void vnuma_destroy(struct vnuma_info *vnuma);
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:50:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtINV-0001I6-4b; Tue, 25 Nov 2014 15:50:09 +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 1XtINT-0001Ht-AG
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 15:50:07 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	F1/15-27785-E25A4745; Tue, 25 Nov 2014 15:50:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416930604!11440516!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6200 invoked from network); 25 Nov 2014 15:50:05 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:50:05 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPFo2Fb019343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 15:50:03 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFo1N9011477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 15:50:01 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFo1fh011428; Tue, 25 Nov 2014 15:50:01 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 07:50:00 -0800
Date: Tue, 25 Nov 2014 10:49:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141125154958.GD29886@konrad-lan.dumpdata.com>
References: <547485D8020000780004AA76@mail.emea.novell.com>
	<54749C2B020000780004AB42@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54749C2B020000780004AB42@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] vNUMA: rename interface 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

On Tue, Nov 25, 2014 at 02:11:39PM +0000, Jan Beulich wrote:
> >>> On 25.11.14 at 13:36, <JBeulich@suse.com> wrote:
> > No-one (including me) paid attention during review that these
> > structures don't adhere to the naming requirements of the public
> > interface: Consistently use xen_ prefixes at least for all new
> > additions.
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Sorry, again forgot to Cc you (for 4.5): No functional change, but
> avoiding a later (incompatible) interface change.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


> 
> Jan
> 
> > --- a/tools/libxc/include/xenctrl.h
> > +++ b/tools/libxc/include/xenctrl.h
> > @@ -1264,7 +1264,7 @@ int xc_domain_setvnuma(xc_interface *xch
> >                          uint32_t nr_vnodes,
> >                          uint32_t nr_regions,
> >                          uint32_t nr_vcpus,
> > -                        vmemrange_t *vmemrange,
> > +                        xen_vmemrange_t *vmemrange,
> >                          unsigned int *vdistance,
> >                          unsigned int *vcpu_to_vnode,
> >                          unsigned int *vnode_to_pnode);
> > --- a/tools/libxc/xc_domain.c
> > +++ b/tools/libxc/xc_domain.c
> > @@ -2171,7 +2171,7 @@ int xc_domain_setvnuma(xc_interface *xch
> >                         uint32_t nr_vnodes,
> >                         uint32_t nr_vmemranges,
> >                         uint32_t nr_vcpus,
> > -                       vmemrange_t *vmemrange,
> > +                       xen_vmemrange_t *vmemrange,
> >                         unsigned int *vdistance,
> >                         unsigned int *vcpu_to_vnode,
> >                         unsigned int *vnode_to_pnode)
> > --- a/xen/common/domctl.c
> > +++ b/xen/common/domctl.c
> > @@ -345,7 +345,7 @@ static struct vnuma_info *vnuma_alloc(un
> >      vnuma->vdistance = xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);
> >      vnuma->vcpu_to_vnode = xmalloc_array(unsigned int, nr_vcpus);
> >      vnuma->vnode_to_pnode = xmalloc_array(unsigned int, nr_vnodes);
> > -    vnuma->vmemrange = xmalloc_array(vmemrange_t, nr_ranges);
> > +    vnuma->vmemrange = xmalloc_array(xen_vmemrange_t, nr_ranges);
> >  
> >      if ( vnuma->vdistance == NULL || vnuma->vmemrange == NULL ||
> >           vnuma->vcpu_to_vnode == NULL || vnuma->vnode_to_pnode == NULL )
> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -972,7 +972,7 @@ long do_memory_op(unsigned long cmd, XEN
> >  
> >      case XENMEM_get_vnumainfo:
> >      {
> > -        struct vnuma_topology_info topology;
> > +        struct xen_vnuma_topology_info topology;
> >          struct domain *d;
> >          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
> >          struct vnuma_info tmp;
> > @@ -1033,7 +1033,7 @@ long do_memory_op(unsigned long cmd, XEN
> >          read_unlock(&d->vnuma_rwlock);
> >  
> >          tmp.vdistance = xmalloc_array(unsigned int, dom_vnodes * 
> > dom_vnodes);
> > -        tmp.vmemrange = xmalloc_array(vmemrange_t, dom_vranges);
> > +        tmp.vmemrange = xmalloc_array(xen_vmemrange_t, dom_vranges);
> >          tmp.vcpu_to_vnode = xmalloc_array(unsigned int, dom_vcpus);
> >  
> >          if ( tmp.vdistance == NULL ||
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -980,7 +980,7 @@ struct xen_domctl_vnuma {
> >      /*
> >       * memory rages for each vNUMA node
> >       */
> > -    XEN_GUEST_HANDLE_64(vmemrange_t) vmemrange;
> > +    XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
> >  };
> >  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -530,14 +530,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_
> >  #define XENMEM_get_vnumainfo                26
> >  
> >  /* vNUMA node memory ranges */
> > -struct vmemrange {
> > +struct xen_vmemrange {
> >      uint64_t start, end;
> >      unsigned int flags;
> >      unsigned int nid;
> >  };
> > -
> > -typedef struct vmemrange vmemrange_t;
> > -DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
> > +typedef struct xen_vmemrange xen_vmemrange_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
> >  
> >  /*
> >   * vNUMA topology specifies vNUMA node number, distance table,
> > @@ -548,7 +547,7 @@ DEFINE_XEN_GUEST_HANDLE(vmemrange_t);
> >   * copied back to guest. Domain returns expected values of nr_vnodes,
> >   * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
> >   */
> > -struct vnuma_topology_info {
> > +struct xen_vnuma_topology_info {
> >      /* IN */
> >      domid_t domid;
> >      uint16_t pad;
> > @@ -566,12 +565,12 @@ struct vnuma_topology_info {
> >          uint64_t pad;
> >      } vcpu_to_vnode;
> >      union {
> > -        XEN_GUEST_HANDLE(vmemrange_t) h;
> > +        XEN_GUEST_HANDLE(xen_vmemrange_t) h;
> >          uint64_t pad;
> >      } vmemrange;
> >  };
> > -typedef struct vnuma_topology_info vnuma_topology_info_t;
> > -DEFINE_XEN_GUEST_HANDLE(vnuma_topology_info_t);
> > +typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
> >  
> >  /* Next available subop number is 27 */
> >  
> > --- a/xen/include/xen/domain.h
> > +++ b/xen/include/xen/domain.h
> > @@ -100,7 +100,7 @@ struct vnuma_info {
> >      unsigned int *vdistance;
> >      unsigned int *vcpu_to_vnode;
> >      unsigned int *vnode_to_pnode;
> > -    struct vmemrange *vmemrange;
> > +    struct xen_vmemrange *vmemrange;
> >  };
> >  
> >  void vnuma_destroy(struct vnuma_info *vnuma);
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:51:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIP2-0001RE-Qv; Tue, 25 Nov 2014 15:51:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtIP1-0001Qv-MZ
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:51:43 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F9/34-07724-E85A4745; Tue, 25 Nov 2014 15:51:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416930699!13703430!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2671 invoked from network); 25 Nov 2014 15:51:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:51:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPFpXhN013519
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 15:51:34 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFpXkt014876
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 15:51:33 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFpWOm016960; Tue, 25 Nov 2014 15:51:32 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 07:51:32 -0800
Date: Tue, 25 Nov 2014 10:51:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141125155130.GE29886@konrad-lan.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
	<20141121170103.GA8314@laptop.dumpdata.com>
	<1416924781.32327.23.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416924781.32327.23.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: wei.liu2@citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 02:13:01PM +0000, Ian Campbell wrote:
> On Fri, 2014-11-21 at 12:01 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 20, 2014 at 03:28:30PM +0000, Ian Campbell wrote:
> > > On Wed, 2014-11-19 at 16:25 -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote:
> > > > > Hi Konrad, I have another release ack request:
> > > > > 
> > > > > Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > > > > > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > > > > > still some places in xenstore are not updated, including:
> > > > > > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> > > > > > This patch series updates /vm/<uuid>/name in xenstore,
> > > > > 
> > > > > This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
> > > > > bugfix which I think should go into Xen 4.5.
> > > > > 
> > > > > The risk WITHOUT this patch is that there are out-of-tree tools which
> > > > > look here for the domain name and will get confused after it is
> > > > > renamed.
> > > > 
> > > > When was this introduced? Did it exist with Xend?
> > > 
> > > Based on:
> > >  git grep domain\" RELEASE-4.4.0  tools/python/
> > >  git grep domain\' RELEASE-4.4.0 tools/python/
> > > it doesn't appear so, but someone with a xend install would be needed to
> > > confirm for sure.
> > > 
> > > Given that this has always been wrong for a libxl domain after migration
> > > it seems likely to me that noone is looking at this field.
> > 
> > And this is not a regression though.
> > 
> > What I am understanding is that we advertise to out-side toolstack
> > users for a couple of releases something which is misleading and wrong.
> 
> ...and also basically useless, there is really no reason to be looking
> for the domain's name under a subset of the backend nodes (only vkb, vfb
> and console have this key at all). None of the helper function which we
> provide do this.
> 
> Also these nodes are not advertised as supported either via
> docs/misc/xenstore-paths.markdown or xen/include/public/io/*.h.
> 
> > My fear is that there such toolstack users out there who will
> > get their pitchforks out when this shows up.
> > 
> > But perhaps there is a way to mitigate this. Is there another way
> > (and can it be in the commit description) to get the proper
> > domain name? I presume it is just looking at /local/domain/%d/name ?
> > 
> > As such could this be added:
> > 
> > "The proper way to get the domain name is to get it from
> > /local/domain/%d/name instead from this field."
> 
> The proper way is to use libxl_domid_to_name, not to go scrobbling
> around in xenstore. We could say this (or both) in the commit message
> though if it would help to reassure you.

That (both) would most certainly reassure me. Thank you!

> 
> Either way I think it really would be best to take this fix rather than
> worrying overly about the infinitesimal possibility that someone might
> be using this key.

Right, so with the reassurance text added on:
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 Nov 25 15:51:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIP2-0001RE-Qv; Tue, 25 Nov 2014 15:51:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtIP1-0001Qv-MZ
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:51:43 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F9/34-07724-E85A4745; Tue, 25 Nov 2014 15:51:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416930699!13703430!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2671 invoked from network); 25 Nov 2014 15:51:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:51:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPFpXhN013519
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 15:51:34 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFpXkt014876
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 15:51:33 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFpWOm016960; Tue, 25 Nov 2014 15:51:32 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 07:51:32 -0800
Date: Tue, 25 Nov 2014 10:51:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141125155130.GE29886@konrad-lan.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
	<20141121170103.GA8314@laptop.dumpdata.com>
	<1416924781.32327.23.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416924781.32327.23.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: wei.liu2@citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 02:13:01PM +0000, Ian Campbell wrote:
> On Fri, 2014-11-21 at 12:01 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 20, 2014 at 03:28:30PM +0000, Ian Campbell wrote:
> > > On Wed, 2014-11-19 at 16:25 -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote:
> > > > > Hi Konrad, I have another release ack request:
> > > > > 
> > > > > Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > > > > > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > > > > > still some places in xenstore are not updated, including:
> > > > > > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> > > > > > This patch series updates /vm/<uuid>/name in xenstore,
> > > > > 
> > > > > This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
> > > > > bugfix which I think should go into Xen 4.5.
> > > > > 
> > > > > The risk WITHOUT this patch is that there are out-of-tree tools which
> > > > > look here for the domain name and will get confused after it is
> > > > > renamed.
> > > > 
> > > > When was this introduced? Did it exist with Xend?
> > > 
> > > Based on:
> > >  git grep domain\" RELEASE-4.4.0  tools/python/
> > >  git grep domain\' RELEASE-4.4.0 tools/python/
> > > it doesn't appear so, but someone with a xend install would be needed to
> > > confirm for sure.
> > > 
> > > Given that this has always been wrong for a libxl domain after migration
> > > it seems likely to me that noone is looking at this field.
> > 
> > And this is not a regression though.
> > 
> > What I am understanding is that we advertise to out-side toolstack
> > users for a couple of releases something which is misleading and wrong.
> 
> ...and also basically useless, there is really no reason to be looking
> for the domain's name under a subset of the backend nodes (only vkb, vfb
> and console have this key at all). None of the helper function which we
> provide do this.
> 
> Also these nodes are not advertised as supported either via
> docs/misc/xenstore-paths.markdown or xen/include/public/io/*.h.
> 
> > My fear is that there such toolstack users out there who will
> > get their pitchforks out when this shows up.
> > 
> > But perhaps there is a way to mitigate this. Is there another way
> > (and can it be in the commit description) to get the proper
> > domain name? I presume it is just looking at /local/domain/%d/name ?
> > 
> > As such could this be added:
> > 
> > "The proper way to get the domain name is to get it from
> > /local/domain/%d/name instead from this field."
> 
> The proper way is to use libxl_domid_to_name, not to go scrobbling
> around in xenstore. We could say this (or both) in the commit message
> though if it would help to reassure you.

That (both) would most certainly reassure me. Thank you!

> 
> Either way I think it really would be best to take this fix rather than
> worrying overly about the infinitesimal possibility that someone might
> be using this key.

Right, so with the reassurance text added on:
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 Nov 25 15:54:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:54:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIRp-0001e9-DJ; Tue, 25 Nov 2014 15:54:37 +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 1XtIRo-0001e1-3e
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:54:36 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	DC/1F-02698-B36A4745; Tue, 25 Nov 2014 15:54:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416930872!11441745!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9033 invoked from network); 25 Nov 2014 15:54:34 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:54:34 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPFsPSa026507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 15:54:26 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFsOpm028773
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 15:54:25 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFsNoo021184; Tue, 25 Nov 2014 15:54:23 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 07:54:23 -0800
Date: Tue, 25 Nov 2014 10:54:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141125155421.GF29886@konrad-lan.dumpdata.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
	<20141125103940.GC28315@zion.uk.xensource.com>
	<20141125111522.GD28315@zion.uk.xensource.com>
	<1416915667.7176.39.camel@Abyss> <547498F2.70201@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547498F2.70201@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 09:57:54AM -0500, Boris Ostrovsky wrote:
> On 11/25/2014 06:41 AM, Dario Faggioli wrote:
> >On Tue, 2014-11-25 at 11:15 +0000, Wei Liu wrote:
> >>And here it is.
> >>
> >>Boris, can you give it a shot?
> >>
> >>---8<---
> >> From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
> >>From: Wei Liu <wei.liu2@citrix.com>
> >>Date: Tue, 25 Nov 2014 10:59:47 +0000
> >>Subject: [PATCH] libxl: allow copying between bitmaps of different sizes
> >>
> >>When parsing bitmap objects JSON parser will create libxl_bitmap map of the
> >>smallest size needed.
> >>
> >>This can cause problems when saved image file specifies CPU affinity.  For
> >>example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
> >>specified, just a single byte will be allocated and libxl_bitmap->size will be
> >>set to 1.
> >>
> >>This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> >>since the destination bitmap is created for maximum number of CPUs.
> >>
> >>We could allocate that bitmap of the same size as the source, however, it is
> >>later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
> >>number of CPUs
> >>
> >>To fix this issue, introduce an internal function to allowing copying between
> >>bitmaps of different sizes. Note that this function is only used in
> >>libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
> >>libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
> >>placement logic comes into effect when no vcpu / node pinning is provided, so
> >>it always operates on bitmap of the same sizes (that is, size of maximum
> >>number of cpus /nodes).
> >>
> >>Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> >>Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> >>Cc: Ian Campbell <ian.campbell@citrix.com>
> >>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >>Cc: Dario Faggioli <dario.faggioli@citrix.com>
> >>
> >If this end up being the approach, it can have the following:
> >
> >Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thank you!
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:54:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 15:54:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIRp-0001e9-DJ; Tue, 25 Nov 2014 15:54:37 +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 1XtIRo-0001e1-3e
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:54:36 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	DC/1F-02698-B36A4745; Tue, 25 Nov 2014 15:54:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416930872!11441745!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9033 invoked from network); 25 Nov 2014 15:54:34 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 15:54:34 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPFsPSa026507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 15:54:26 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFsOpm028773
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 15:54:25 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPFsNoo021184; Tue, 25 Nov 2014 15:54:23 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 07:54:23 -0800
Date: Tue, 25 Nov 2014 10:54:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141125155421.GF29886@konrad-lan.dumpdata.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
	<20141125103940.GC28315@zion.uk.xensource.com>
	<20141125111522.GD28315@zion.uk.xensource.com>
	<1416915667.7176.39.camel@Abyss> <547498F2.70201@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547498F2.70201@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 09:57:54AM -0500, Boris Ostrovsky wrote:
> On 11/25/2014 06:41 AM, Dario Faggioli wrote:
> >On Tue, 2014-11-25 at 11:15 +0000, Wei Liu wrote:
> >>And here it is.
> >>
> >>Boris, can you give it a shot?
> >>
> >>---8<---
> >> From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
> >>From: Wei Liu <wei.liu2@citrix.com>
> >>Date: Tue, 25 Nov 2014 10:59:47 +0000
> >>Subject: [PATCH] libxl: allow copying between bitmaps of different sizes
> >>
> >>When parsing bitmap objects JSON parser will create libxl_bitmap map of the
> >>smallest size needed.
> >>
> >>This can cause problems when saved image file specifies CPU affinity.  For
> >>example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
> >>specified, just a single byte will be allocated and libxl_bitmap->size will be
> >>set to 1.
> >>
> >>This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> >>since the destination bitmap is created for maximum number of CPUs.
> >>
> >>We could allocate that bitmap of the same size as the source, however, it is
> >>later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
> >>number of CPUs
> >>
> >>To fix this issue, introduce an internal function to allowing copying between
> >>bitmaps of different sizes. Note that this function is only used in
> >>libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
> >>libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
> >>placement logic comes into effect when no vcpu / node pinning is provided, so
> >>it always operates on bitmap of the same sizes (that is, size of maximum
> >>number of cpus /nodes).
> >>
> >>Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> >>Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> >>Cc: Ian Campbell <ian.campbell@citrix.com>
> >>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >>Cc: Dario Faggioli <dario.faggioli@citrix.com>
> >>
> >If this end up being the approach, it can have the following:
> >
> >Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thank you!
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:58:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 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.xen.org>)
	id 1XtIVs-0001pS-2u; Tue, 25 Nov 2014 15:58:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtIVq-0001pM-IP
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:58:46 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	24/31-07724-537A4745; Tue, 25 Nov 2014 15:58:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416931122!13705148!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2379 invoked from network); 25 Nov 2014 15:58:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:58:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196611950"
Message-ID: <1416931113.11944.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 25 Nov 2014 15:58:33 +0000
In-Reply-To: <20141125155130.GE29886@konrad-lan.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
	<20141121170103.GA8314@laptop.dumpdata.com>
	<1416924781.32327.23.camel@citrix.com>
	<20141125155130.GE29886@konrad-lan.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, wei.liu2@citrix.com, Chunyan
	Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
 updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 10:51 -0500, Konrad Rzeszutek Wilk wrote:
> Right, so with the reassurance text added on:
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks.

Chunyan, I propose to commit adding the following to the commit text of
"[PATCH 1/2 V3] remove domain field in xenstore backend dir":

        The correct way to obtain a domain's name is via
        libxl_domid_to_name(), or by reading
        from /local/domain/$DOMID/name for toolstacks not using libxl.
        
Does that sound OK to you?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 15:58:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 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.xen.org>)
	id 1XtIVs-0001pS-2u; Tue, 25 Nov 2014 15:58:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtIVq-0001pM-IP
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 15:58:46 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	24/31-07724-537A4745; Tue, 25 Nov 2014 15:58:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416931122!13705148!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2379 invoked from network); 25 Nov 2014 15:58:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 15:58:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196611950"
Message-ID: <1416931113.11944.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 25 Nov 2014 15:58:33 +0000
In-Reply-To: <20141125155130.GE29886@konrad-lan.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
	<20141121170103.GA8314@laptop.dumpdata.com>
	<1416924781.32327.23.camel@citrix.com>
	<20141125155130.GE29886@konrad-lan.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, wei.liu2@citrix.com, Chunyan
	Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
 updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 10:51 -0500, Konrad Rzeszutek Wilk wrote:
> Right, so with the reassurance text added on:
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks.

Chunyan, I propose to commit adding the following to the commit text of
"[PATCH 1/2 V3] remove domain field in xenstore backend dir":

        The correct way to obtain a domain's name is via
        libxl_domid_to_name(), or by reading
        from /local/domain/$DOMID/name for toolstacks not using libxl.
        
Does that sound OK to you?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:03:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16: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 1XtIan-0002OE-65; Tue, 25 Nov 2014 16:03:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtIam-0002O8-2F
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:03:52 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	33/A6-27623-768A4745; Tue, 25 Nov 2014 16:03:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416931428!13706510!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7747 invoked from network); 25 Nov 2014 16:03:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:03:50 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPG3iXI008738
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 16:03:44 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPG3hGk007485
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 16:03:43 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPG3h4N005460; Tue, 25 Nov 2014 16:03:43 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 08:03:42 -0800
Date: Tue, 25 Nov 2014 11:03:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141125160340.GH29886@konrad-lan.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
	<20141121170103.GA8314@laptop.dumpdata.com>
	<1416924781.32327.23.camel@citrix.com>
	<20141125155130.GE29886@konrad-lan.dumpdata.com>
	<1416931113.11944.7.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416931113.11944.7.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, wei.liu2@citrix.com,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 03:58:33PM +0000, Ian Campbell wrote:
> On Tue, 2014-11-25 at 10:51 -0500, Konrad Rzeszutek Wilk wrote:
> > Right, so with the reassurance text added on:
> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Thanks.
> 
> Chunyan, I propose to commit adding the following to the commit text of
> "[PATCH 1/2 V3] remove domain field in xenstore backend dir":
> 
>         The correct way to obtain a domain's name is via
>         libxl_domid_to_name(), or by reading
>         from /local/domain/$DOMID/name for toolstacks not using libxl.
>         
> Does that sound OK to you?

Yes.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:03:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16: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 1XtIah-0002Np-Pz; Tue, 25 Nov 2014 16:03:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtIag-0002Nk-QD
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:03:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	77/30-09842-268A4745; Tue, 25 Nov 2014 16:03:46 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416931424!15229180!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13063 invoked from network); 25 Nov 2014 16:03:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:03:45 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPG3bHs008500
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 16:03:38 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAPG3a6E002020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 16:03:37 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPG3aop005120; Tue, 25 Nov 2014 16:03:36 GMT
Received: from ovs104.us.oracle.com (/10.149.76.204)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 08:03:35 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, wei.liu2@citrix.com
Date: Tue, 25 Nov 2014 11:11:50 -0500
Message-Id: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH for-4.5] pygrub: Fix regression from c/s d1b93ea,
	attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

c/s d1b93ea causes substantial functional regressions in pygrub's ability to
parse bootloader configuration files.

c/s d1b93ea itself changed an an interface which previously used exclusively
integers, to using strings in the case of a grub configuration with explicit
default set, along with changing the code calling the interface to require a
string.  The default value for "default" remained as an integer.

As a result, any Extlinux or Lilo configuration (which drives this interface
exclusively with integers), or Grub configuration which doesn't explicitly
declare a default will die with an AttributeError when attempting to call
"self.cf.default.isdigit()" where "default" is an integer.

Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
which searches partitions for valid bootloader configurations, causing the
issue to be reported as "Unable to find partition containing kernel"

We should explicitly check type of "default" in image_index() and process it
appropriately.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---

Commit message is Andrew's with exception of the last sentense.

I only tested this with grub2.

-boris

 tools/pygrub/src/pygrub |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)
 mode change 100644 => 100755 tools/pygrub/src/pygrub

diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
old mode 100644
new mode 100755
index aa7e562..3ec52fd
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -457,7 +457,9 @@ class Grub:
         self.cf.parse(buf)
 
     def image_index(self):
-        if self.cf.default.isdigit():
+        if isinstance(self.cf.default, int):
+            sel = self.cf.default
+        elif self.cf.default.isdigit():
             sel = int(self.cf.default)
         else:
             # We don't fully support submenus. Look for the leaf value in
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:03:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16: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 1XtIah-0002Np-Pz; Tue, 25 Nov 2014 16:03:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtIag-0002Nk-QD
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:03:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	77/30-09842-268A4745; Tue, 25 Nov 2014 16:03:46 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416931424!15229180!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13063 invoked from network); 25 Nov 2014 16:03:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:03:45 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPG3bHs008500
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 16:03:38 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAPG3a6E002020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 16:03:37 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPG3aop005120; Tue, 25 Nov 2014 16:03:36 GMT
Received: from ovs104.us.oracle.com (/10.149.76.204)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 08:03:35 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, wei.liu2@citrix.com
Date: Tue, 25 Nov 2014 11:11:50 -0500
Message-Id: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH for-4.5] pygrub: Fix regression from c/s d1b93ea,
	attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

c/s d1b93ea causes substantial functional regressions in pygrub's ability to
parse bootloader configuration files.

c/s d1b93ea itself changed an an interface which previously used exclusively
integers, to using strings in the case of a grub configuration with explicit
default set, along with changing the code calling the interface to require a
string.  The default value for "default" remained as an integer.

As a result, any Extlinux or Lilo configuration (which drives this interface
exclusively with integers), or Grub configuration which doesn't explicitly
declare a default will die with an AttributeError when attempting to call
"self.cf.default.isdigit()" where "default" is an integer.

Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
which searches partitions for valid bootloader configurations, causing the
issue to be reported as "Unable to find partition containing kernel"

We should explicitly check type of "default" in image_index() and process it
appropriately.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---

Commit message is Andrew's with exception of the last sentense.

I only tested this with grub2.

-boris

 tools/pygrub/src/pygrub |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)
 mode change 100644 => 100755 tools/pygrub/src/pygrub

diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
old mode 100644
new mode 100755
index aa7e562..3ec52fd
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -457,7 +457,9 @@ class Grub:
         self.cf.parse(buf)
 
     def image_index(self):
-        if self.cf.default.isdigit():
+        if isinstance(self.cf.default, int):
+            sel = self.cf.default
+        elif self.cf.default.isdigit():
             sel = int(self.cf.default)
         else:
             # We don't fully support submenus. Look for the leaf value in
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:03:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16: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 1XtIan-0002OE-65; Tue, 25 Nov 2014 16:03:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtIam-0002O8-2F
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:03:52 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	33/A6-27623-768A4745; Tue, 25 Nov 2014 16:03:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416931428!13706510!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7747 invoked from network); 25 Nov 2014 16:03:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:03:50 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPG3iXI008738
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 16:03:44 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPG3hGk007485
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 16:03:43 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPG3h4N005460; Tue, 25 Nov 2014 16:03:43 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 08:03:42 -0800
Date: Tue, 25 Nov 2014 11:03:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141125160340.GH29886@konrad-lan.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
	<20141121170103.GA8314@laptop.dumpdata.com>
	<1416924781.32327.23.camel@citrix.com>
	<20141125155130.GE29886@konrad-lan.dumpdata.com>
	<1416931113.11944.7.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416931113.11944.7.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, wei.liu2@citrix.com,
	Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
	updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 03:58:33PM +0000, Ian Campbell wrote:
> On Tue, 2014-11-25 at 10:51 -0500, Konrad Rzeszutek Wilk wrote:
> > Right, so with the reassurance text added on:
> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Thanks.
> 
> Chunyan, I propose to commit adding the following to the commit text of
> "[PATCH 1/2 V3] remove domain field in xenstore backend dir":
> 
>         The correct way to obtain a domain's name is via
>         libxl_domid_to_name(), or by reading
>         from /local/domain/$DOMID/name for toolstacks not using libxl.
>         
> Does that sound OK to you?

Yes.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:04:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:04:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIbP-0002Xc-Jq; Tue, 25 Nov 2014 16:04:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XtIbO-0002XH-H7
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:04:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5C/F1-25276-D88A4745; Tue, 25 Nov 2014 16:04:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416931468!15284133!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,BODY_RANDOM_LONG,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18676 invoked from network); 25 Nov 2014 16:04:28 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:04:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416931468; l=2316;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=ZDGHEVBn6at+1xsxhGGUz5X0AV4=;
	b=YA8/9AfYkoV1vm/dzTOgALKi80zYp0NrVTuxmUBPolMm28oB2T5Y6+VqLhAeNMOyE4O
	ROlRhYO5cZnxsEso2lVb5kiXPvT4wwlb89NSL8aLHbWFSWT8FLMw/2ooEIZKtwdypoIT8
	Vpn3u/MlzzSQRhB5QHjLqwFfKFslaxQ/QME=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.13 AUTH) with ESMTPSA id 40022cqAPG4Ikot
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 25 Nov 2014 17:04:18 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 959CA50172; Tue, 25 Nov 2014 17:04:18 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Tue, 25 Nov 2014 17:04:09 +0100
Message-Id: <1416931449-30679-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH v2] INSTALL: correct EXTRA_CFLAGS 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>
MIME-Version: 1.0
Content-Type: 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 already documented configure patch was not applied.
Adjust documentation to describe existing behaviour.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---

resend due to lack of Cc: tags 

 INSTALL | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/INSTALL b/INSTALL
index 6bb9d23..656c90a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -128,13 +128,6 @@ original xenstored will be used. Valid names are xenstored and
 oxenstored.
   --with-xenstored=name
 
-Using additional CFLAGS to build tools running in dom0 is required when
-building distro packages. This is the option to pass things like
-RPM_OPT_FLAGS.
-  --with-extra-cflags-tools=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-traditional=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-upstream=EXTRA_CFLAGS
-
 Instead of starting the tools in dom0 with sysv runlevel scripts they
 can also be started by systemd. If this option is enabled xenstored will
 receive the communication socked directly from systemd. So starting it
@@ -241,6 +234,12 @@ QEMU_UPSTREAM_URL=
 QEMU_TRADITIONAL_URL=
 SEABIOS_UPSTREAM_URL=
 
+Using additional CFLAGS to build tools running in dom0 is required when
+building distro packages. This can be used to pass RPM_OPT_FLAGS.
+EXTRA_CFLAGS_XEN_TOOLS=
+EXTRA_CFLAGS_QEMU_TRADITIONAL=
+EXTRA_CFLAGS_QEMU_XEN=
+
 This variable can be used to use DIR/include and DIR/lib during build.
 This is the same as PREPEND_LIB and PREPEND_INCLUDES. APPEND_LIB and
 APPEND_INCLUDES= will be appended to the CFLAGS/LDFLAGS variable.
@@ -310,10 +309,10 @@ sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi
 %build
 export WGET=$(type -P false)
 export GIT=$(type -P false)
+export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
 %configure \
-        --with-extra-cflags-tools="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-traditional="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-upstream="$RPM_OPT_FLAGS" \
         --with-initddir=%{_initddir}
 unset CFLAGS CXXFLAGS FFLAGS LDFLAGS
 make

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:04:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:04:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIbP-0002Xc-Jq; Tue, 25 Nov 2014 16:04:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XtIbO-0002XH-H7
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:04:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5C/F1-25276-D88A4745; Tue, 25 Nov 2014 16:04:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416931468!15284133!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,BODY_RANDOM_LONG,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18676 invoked from network); 25 Nov 2014 16:04:28 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:04:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416931468; l=2316;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=ZDGHEVBn6at+1xsxhGGUz5X0AV4=;
	b=YA8/9AfYkoV1vm/dzTOgALKi80zYp0NrVTuxmUBPolMm28oB2T5Y6+VqLhAeNMOyE4O
	ROlRhYO5cZnxsEso2lVb5kiXPvT4wwlb89NSL8aLHbWFSWT8FLMw/2ooEIZKtwdypoIT8
	Vpn3u/MlzzSQRhB5QHjLqwFfKFslaxQ/QME=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.13 AUTH) with ESMTPSA id 40022cqAPG4Ikot
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 25 Nov 2014 17:04:18 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 959CA50172; Tue, 25 Nov 2014 17:04:18 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Tue, 25 Nov 2014 17:04:09 +0100
Message-Id: <1416931449-30679-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH v2] INSTALL: correct EXTRA_CFLAGS 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>
MIME-Version: 1.0
Content-Type: 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 already documented configure patch was not applied.
Adjust documentation to describe existing behaviour.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---

resend due to lack of Cc: tags 

 INSTALL | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/INSTALL b/INSTALL
index 6bb9d23..656c90a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -128,13 +128,6 @@ original xenstored will be used. Valid names are xenstored and
 oxenstored.
   --with-xenstored=name
 
-Using additional CFLAGS to build tools running in dom0 is required when
-building distro packages. This is the option to pass things like
-RPM_OPT_FLAGS.
-  --with-extra-cflags-tools=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-traditional=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-upstream=EXTRA_CFLAGS
-
 Instead of starting the tools in dom0 with sysv runlevel scripts they
 can also be started by systemd. If this option is enabled xenstored will
 receive the communication socked directly from systemd. So starting it
@@ -241,6 +234,12 @@ QEMU_UPSTREAM_URL=
 QEMU_TRADITIONAL_URL=
 SEABIOS_UPSTREAM_URL=
 
+Using additional CFLAGS to build tools running in dom0 is required when
+building distro packages. This can be used to pass RPM_OPT_FLAGS.
+EXTRA_CFLAGS_XEN_TOOLS=
+EXTRA_CFLAGS_QEMU_TRADITIONAL=
+EXTRA_CFLAGS_QEMU_XEN=
+
 This variable can be used to use DIR/include and DIR/lib during build.
 This is the same as PREPEND_LIB and PREPEND_INCLUDES. APPEND_LIB and
 APPEND_INCLUDES= will be appended to the CFLAGS/LDFLAGS variable.
@@ -310,10 +309,10 @@ sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi
 %build
 export WGET=$(type -P false)
 export GIT=$(type -P false)
+export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
 %configure \
-        --with-extra-cflags-tools="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-traditional="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-upstream="$RPM_OPT_FLAGS" \
         --with-initddir=%{_initddir}
 unset CFLAGS CXXFLAGS FFLAGS LDFLAGS
 make

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:10:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:10:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIhR-0002oz-GW; Tue, 25 Nov 2014 16:10:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtIhP-0002os-Ef
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 16:10:43 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	54/E1-11608-20AA4745; Tue, 25 Nov 2014 16:10:42 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416931841!13801177!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12868 invoked from network); 25 Nov 2014 16:10:42 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:10:42 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 5335CADE2;
	Tue, 25 Nov 2014 16:10:40 +0000 (UTC)
Message-ID: <5474AA00.8050500@suse.com>
Date: Tue, 25 Nov 2014 17:10:40 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546EFAE3.80404@suse.com>	
	<20141121135747.GB2886@laptop.dumpdata.com>
	<5473008C.4080604@suse.com> <1416823327.26329.25.camel@citrix.com>
In-Reply-To: <1416823327.26329.25.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 11:02 AM, Ian Campbell wrote:
> On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
>> On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
>>>> Hi,
>>>>
>>>> while testing my "linear p2m list" patches I saw the following
>>>> problem (even without my patches in place):
>>>>
>>>> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
>>>> disk image of a guest by attaching it to dom0:
>>>>
>>>> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
>>>> mount /dev/xvda2 /mnt
>>>> ...
>>>> umount /mnt
>>>> xl block-detach 0 xvda
>>
>> Did some more testing:
>> - Seems to occur only when attaching a block device to dom0
>
> That means a qdisk backed situation then, I think.
>
> Is your qemu up to date?
>
> http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=commit;h=abbbc2f09a53f8f9ee565356ab11a78af006e45e resulted in slightly different messages, but could be related?

Tried it with xen-unstable and newest qemu. Now I have another problem:

xl -vvv block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0: create: 
how=(nil) callback=(nil) poller=0xbac1d0
libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to add device
libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xbac0f0: 
complete, rc=-16
libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0: 
inprogress: poller=0xbac1d0, flags=ic
libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xbac0f0: destroy
libxl_device_disk_add failed.


rc=-16 means ERROR_JSON_CONFIG_EMPTY. Could it be that newest tools
won't let me attach a block device to dom0?

IMHO that's a severe regression!


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:10:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:10:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIhR-0002oz-GW; Tue, 25 Nov 2014 16:10:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtIhP-0002os-Ef
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 16:10:43 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	54/E1-11608-20AA4745; Tue, 25 Nov 2014 16:10:42 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1416931841!13801177!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12868 invoked from network); 25 Nov 2014 16:10:42 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:10:42 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 5335CADE2;
	Tue, 25 Nov 2014 16:10:40 +0000 (UTC)
Message-ID: <5474AA00.8050500@suse.com>
Date: Tue, 25 Nov 2014 17:10:40 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546EFAE3.80404@suse.com>	
	<20141121135747.GB2886@laptop.dumpdata.com>
	<5473008C.4080604@suse.com> <1416823327.26329.25.camel@citrix.com>
In-Reply-To: <1416823327.26329.25.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 11:02 AM, Ian Campbell wrote:
> On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
>> On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
>>>> Hi,
>>>>
>>>> while testing my "linear p2m list" patches I saw the following
>>>> problem (even without my patches in place):
>>>>
>>>> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
>>>> disk image of a guest by attaching it to dom0:
>>>>
>>>> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
>>>> mount /dev/xvda2 /mnt
>>>> ...
>>>> umount /mnt
>>>> xl block-detach 0 xvda
>>
>> Did some more testing:
>> - Seems to occur only when attaching a block device to dom0
>
> That means a qdisk backed situation then, I think.
>
> Is your qemu up to date?
>
> http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=commit;h=abbbc2f09a53f8f9ee565356ab11a78af006e45e resulted in slightly different messages, but could be related?

Tried it with xen-unstable and newest qemu. Now I have another problem:

xl -vvv block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0: create: 
how=(nil) callback=(nil) poller=0xbac1d0
libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to add device
libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xbac0f0: 
complete, rc=-16
libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0: 
inprogress: poller=0xbac1d0, flags=ic
libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xbac0f0: destroy
libxl_device_disk_add failed.


rc=-16 means ERROR_JSON_CONFIG_EMPTY. Could it be that newest tools
won't let me attach a block device to dom0?

IMHO that's a severe regression!


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:14:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIkd-00031X-9W; Tue, 25 Nov 2014 16:14:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtIkc-00031S-Cg
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:14:02 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	98/40-03148-9CAA4745; Tue, 25 Nov 2014 16:14:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416932039!14770833!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22394 invoked from network); 25 Nov 2014 16:14:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:14:00 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPGDlwk016681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 16:13:47 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGDjhD015857
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 16:13:45 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGDjeg021442; Tue, 25 Nov 2014 16:13:45 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 08:13:44 -0800
Date: Tue, 25 Nov 2014 11:13:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141125161342.GK29886@konrad-lan.dumpdata.com>
References: <1416931449-30679-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416931449-30679-1-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] INSTALL: correct EXTRA_CFLAGS 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, Nov 25, 2014 at 05:04:09PM +0100, Olaf Hering wrote:
> The already documented configure patch was not applied.
> Adjust documentation to describe existing behaviour.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> ---
> 
> resend due to lack of Cc: tags 
> 
>  INSTALL | 19 +++++++++----------
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/INSTALL b/INSTALL
> index 6bb9d23..656c90a 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -128,13 +128,6 @@ original xenstored will be used. Valid names are xenstored and
>  oxenstored.
>    --with-xenstored=name
>  
> -Using additional CFLAGS to build tools running in dom0 is required when
> -building distro packages. This is the option to pass things like
> -RPM_OPT_FLAGS.
> -  --with-extra-cflags-tools=EXTRA_CFLAGS
> -  --with-extra-cflags-qemu-traditional=EXTRA_CFLAGS
> -  --with-extra-cflags-qemu-upstream=EXTRA_CFLAGS
> -
>  Instead of starting the tools in dom0 with sysv runlevel scripts they
>  can also be started by systemd. If this option is enabled xenstored will
>  receive the communication socked directly from systemd. So starting it
> @@ -241,6 +234,12 @@ QEMU_UPSTREAM_URL=
>  QEMU_TRADITIONAL_URL=
>  SEABIOS_UPSTREAM_URL=
>  
> +Using additional CFLAGS to build tools running in dom0 is required when

Why the mention of 'buld tools running in dom0'? It sounds like it is
required to use dom0 to build tools?

Could you just say: ".. to build tools is required when.."

> +building distro packages. This can be used to pass RPM_OPT_FLAGS.
> +EXTRA_CFLAGS_XEN_TOOLS=
> +EXTRA_CFLAGS_QEMU_TRADITIONAL=
> +EXTRA_CFLAGS_QEMU_XEN=
> +
>  This variable can be used to use DIR/include and DIR/lib during build.
>  This is the same as PREPEND_LIB and PREPEND_INCLUDES. APPEND_LIB and
>  APPEND_INCLUDES= will be appended to the CFLAGS/LDFLAGS variable.
> @@ -310,10 +309,10 @@ sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi
>  %build
>  export WGET=$(type -P false)
>  export GIT=$(type -P false)
> +export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
> +export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
> +export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
>  %configure \
> -        --with-extra-cflags-tools="$RPM_OPT_FLAGS" \
> -        --with-extra-cflags-qemu-traditional="$RPM_OPT_FLAGS" \
> -        --with-extra-cflags-qemu-upstream="$RPM_OPT_FLAGS" \
>          --with-initddir=%{_initddir}
>  unset CFLAGS CXXFLAGS FFLAGS LDFLAGS
>  make
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 25 16:14:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIkd-00031X-9W; Tue, 25 Nov 2014 16:14:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtIkc-00031S-Cg
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:14:02 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	98/40-03148-9CAA4745; Tue, 25 Nov 2014 16:14:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416932039!14770833!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22394 invoked from network); 25 Nov 2014 16:14:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:14:00 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPGDlwk016681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 16:13:47 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGDjhD015857
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 16:13:45 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGDjeg021442; Tue, 25 Nov 2014 16:13:45 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 08:13:44 -0800
Date: Tue, 25 Nov 2014 11:13:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141125161342.GK29886@konrad-lan.dumpdata.com>
References: <1416931449-30679-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416931449-30679-1-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] INSTALL: correct EXTRA_CFLAGS 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, Nov 25, 2014 at 05:04:09PM +0100, Olaf Hering wrote:
> The already documented configure patch was not applied.
> Adjust documentation to describe existing behaviour.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> ---
> 
> resend due to lack of Cc: tags 
> 
>  INSTALL | 19 +++++++++----------
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/INSTALL b/INSTALL
> index 6bb9d23..656c90a 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -128,13 +128,6 @@ original xenstored will be used. Valid names are xenstored and
>  oxenstored.
>    --with-xenstored=name
>  
> -Using additional CFLAGS to build tools running in dom0 is required when
> -building distro packages. This is the option to pass things like
> -RPM_OPT_FLAGS.
> -  --with-extra-cflags-tools=EXTRA_CFLAGS
> -  --with-extra-cflags-qemu-traditional=EXTRA_CFLAGS
> -  --with-extra-cflags-qemu-upstream=EXTRA_CFLAGS
> -
>  Instead of starting the tools in dom0 with sysv runlevel scripts they
>  can also be started by systemd. If this option is enabled xenstored will
>  receive the communication socked directly from systemd. So starting it
> @@ -241,6 +234,12 @@ QEMU_UPSTREAM_URL=
>  QEMU_TRADITIONAL_URL=
>  SEABIOS_UPSTREAM_URL=
>  
> +Using additional CFLAGS to build tools running in dom0 is required when

Why the mention of 'buld tools running in dom0'? It sounds like it is
required to use dom0 to build tools?

Could you just say: ".. to build tools is required when.."

> +building distro packages. This can be used to pass RPM_OPT_FLAGS.
> +EXTRA_CFLAGS_XEN_TOOLS=
> +EXTRA_CFLAGS_QEMU_TRADITIONAL=
> +EXTRA_CFLAGS_QEMU_XEN=
> +
>  This variable can be used to use DIR/include and DIR/lib during build.
>  This is the same as PREPEND_LIB and PREPEND_INCLUDES. APPEND_LIB and
>  APPEND_INCLUDES= will be appended to the CFLAGS/LDFLAGS variable.
> @@ -310,10 +309,10 @@ sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi
>  %build
>  export WGET=$(type -P false)
>  export GIT=$(type -P false)
> +export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
> +export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
> +export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
>  %configure \
> -        --with-extra-cflags-tools="$RPM_OPT_FLAGS" \
> -        --with-extra-cflags-qemu-traditional="$RPM_OPT_FLAGS" \
> -        --with-extra-cflags-qemu-upstream="$RPM_OPT_FLAGS" \
>          --with-initddir=%{_initddir}
>  unset CFLAGS CXXFLAGS FFLAGS LDFLAGS
>  make
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 25 16:16:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIms-00038w-QO; Tue, 25 Nov 2014 16:16:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtImr-00038p-BX
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:16:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B6/94-15461-45BA4745; Tue, 25 Nov 2014 16:16:20 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416932178!15232616!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20709 invoked from network); 25 Nov 2014 16:16:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:16:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPGGH1r028597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 16:16:18 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGGGim002286
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 16:16:17 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGGGke026084; Tue, 25 Nov 2014 16:16:16 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 08:16:16 -0800
Message-ID: <5474ABFF.1030306@oracle.com>
Date: Tue, 25 Nov 2014 11:19:11 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
	<54744FB2020000780004A935@mail.emea.novell.com>
	<54749466.1020907@oracle.com>
	<5474A666020000780004AB9C@mail.emea.novell.com>
In-Reply-To: <5474A666020000780004AB9C@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
	PVH guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 09:55 AM, Jan Beulich wrote:
>
>> Regardless, do you think that disabling VPMU for PVH is worth anyway?
> That depends on what (bad) consequences not doing so has.

I haven't seen anything (besides VAPIC accesses) but I think it would be 
prudent to prevent any VPMU activity from happening. I can see, for 
example MSRs and APIC vector being written. All of which look benign on 
the first sight but who knows...

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:16:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIms-00038w-QO; Tue, 25 Nov 2014 16:16:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtImr-00038p-BX
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:16:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B6/94-15461-45BA4745; Tue, 25 Nov 2014 16:16:20 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1416932178!15232616!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20709 invoked from network); 25 Nov 2014 16:16:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:16:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPGGH1r028597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 16:16:18 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGGGim002286
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 16:16:17 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGGGke026084; Tue, 25 Nov 2014 16:16:16 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 08:16:16 -0800
Message-ID: <5474ABFF.1030306@oracle.com>
Date: Tue, 25 Nov 2014 11:19:11 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
	<54744FB2020000780004A935@mail.emea.novell.com>
	<54749466.1020907@oracle.com>
	<5474A666020000780004AB9C@mail.emea.novell.com>
In-Reply-To: <5474A666020000780004AB9C@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
	PVH guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 09:55 AM, Jan Beulich wrote:
>
>> Regardless, do you think that disabling VPMU for PVH is worth anyway?
> That depends on what (bad) consequences not doing so has.

I haven't seen anything (besides VAPIC accesses) but I think it would be 
prudent to prevent any VPMU activity from happening. I can see, for 
example MSRs and APIC vector being written. All of which look benign on 
the first sight but who knows...

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:17:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIoN-0003FF-96; Tue, 25 Nov 2014 16:17:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtIoL-0003F6-EH
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:17:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	13/19-25276-0BBA4745; Tue, 25 Nov 2014 16:17:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416932271!7960828!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28671 invoked from network); 25 Nov 2014 16:17:52 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:17:52 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPGHgRt030357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 16:17:43 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGHgO8018329
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 16:17:42 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGHfEc018301; Tue, 25 Nov 2014 16:17:41 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 08:17:41 -0800
Date: Tue, 25 Nov 2014 11:17:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141125161738.GB30673@konrad-lan.dumpdata.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	david.vrabel@citrix.com, jun.nakajima@intel.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v3 0/2] xen/pci: Use APIC for MSIs when APIC
 virtualization is supported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 06:06:16PM -0500, Boris Ostrovsky wrote:
> Changes in v3:
> * Explicitly include asm/apic.h in arch/x86/pci/xen.c for !CONFIG_SMP.
> 
> Changes in v2:
> * New version of cpuid.h file from Xen tree (with a couple of style adjustments)
> * Whitespace cleanup
> 
> Currently HVM guests handle MSI interrupts using pirqs/event channels, allowing
> us to not issue APIC accesses that result in somewhat expensive VMEXITs. When
> hardware supports APIC virtualization we don't need to use pirqs anymore
> since now guest's APIC accesses can be handled by the processor itself.
> 
> There are two patches in this series:
> 
> 1. Move setting of x86_msi ops to a later point. The reason for doing so is that
> we currently decide whether or not to use pirqs before kernel had a chance to
> see whether it should be using x2APIC instead of plain APIC. Since hardware may
> virtualize either or both of those two we can only make pirqs vs. APIC selection
> after kernel has settled down on which APIC version it will use. (Note that
> currently x2APIC is not used by HVM guests so technically this patch is not
> necessary. However, it probably makes sense to apply it now to avoid
> forgetting to do it when we enable x2APIC).
> 
> 2. Set x86_msi ops to use pirqs only when APIC virtualization is not available.
> The commit message describes performance improvements that this change brings.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Boris Ostrovsky (2):
>   xen/pci: Defer initialization of MSI ops on HVM guests until after
>     x2APIC has been set up
>   xen/pci: Use APIC directly when APIC virtualization is supported by
>     hardware
> 
>  arch/x86/include/asm/xen/cpuid.h | 91 ++++++++++++++++++++++++++++++++++++++++
>  arch/x86/pci/xen.c               | 25 ++++++++++-
>  2 files changed, 114 insertions(+), 2 deletions(-)
>  create mode 100644 arch/x86/include/asm/xen/cpuid.h
> 
> -- 
> 1.9.3
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:17:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIoN-0003FF-96; Tue, 25 Nov 2014 16:17:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtIoL-0003F6-EH
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:17:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	13/19-25276-0BBA4745; Tue, 25 Nov 2014 16:17:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416932271!7960828!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28671 invoked from network); 25 Nov 2014 16:17:52 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:17:52 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPGHgRt030357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 16:17:43 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGHgO8018329
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 16:17:42 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPGHfEc018301; Tue, 25 Nov 2014 16:17:41 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.54)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 08:17:41 -0800
Date: Tue, 25 Nov 2014 11:17:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141125161738.GB30673@konrad-lan.dumpdata.com>
References: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416870378-32481-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	david.vrabel@citrix.com, jun.nakajima@intel.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v3 0/2] xen/pci: Use APIC for MSIs when APIC
 virtualization is supported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Nov 24, 2014 at 06:06:16PM -0500, Boris Ostrovsky wrote:
> Changes in v3:
> * Explicitly include asm/apic.h in arch/x86/pci/xen.c for !CONFIG_SMP.
> 
> Changes in v2:
> * New version of cpuid.h file from Xen tree (with a couple of style adjustments)
> * Whitespace cleanup
> 
> Currently HVM guests handle MSI interrupts using pirqs/event channels, allowing
> us to not issue APIC accesses that result in somewhat expensive VMEXITs. When
> hardware supports APIC virtualization we don't need to use pirqs anymore
> since now guest's APIC accesses can be handled by the processor itself.
> 
> There are two patches in this series:
> 
> 1. Move setting of x86_msi ops to a later point. The reason for doing so is that
> we currently decide whether or not to use pirqs before kernel had a chance to
> see whether it should be using x2APIC instead of plain APIC. Since hardware may
> virtualize either or both of those two we can only make pirqs vs. APIC selection
> after kernel has settled down on which APIC version it will use. (Note that
> currently x2APIC is not used by HVM guests so technically this patch is not
> necessary. However, it probably makes sense to apply it now to avoid
> forgetting to do it when we enable x2APIC).
> 
> 2. Set x86_msi ops to use pirqs only when APIC virtualization is not available.
> The commit message describes performance improvements that this change brings.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Boris Ostrovsky (2):
>   xen/pci: Defer initialization of MSI ops on HVM guests until after
>     x2APIC has been set up
>   xen/pci: Use APIC directly when APIC virtualization is supported by
>     hardware
> 
>  arch/x86/include/asm/xen/cpuid.h | 91 ++++++++++++++++++++++++++++++++++++++++
>  arch/x86/pci/xen.c               | 25 ++++++++++-
>  2 files changed, 114 insertions(+), 2 deletions(-)
>  create mode 100644 arch/x86/include/asm/xen/cpuid.h
> 
> -- 
> 1.9.3
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:23:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:23:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtItp-0003Sa-56; Tue, 25 Nov 2014 16:23:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtItn-0003SU-4v
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:23:31 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	38/E5-28296-20DA4745; Tue, 25 Nov 2014 16:23:30 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416932607!13724909!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5246 invoked from network); 25 Nov 2014 16:23:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:23:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196234562"
Message-ID: <5474A863.60203@citrix.com>
Date: Tue, 25 Nov 2014 16:03:47 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>		
	<1416499238.14429.39.camel@citrix.com>
	<546E1206.5080403@citrix.com>	
	<1416500123.20161.3.camel@citrix.com>
	<546E1ABB.6090308@oracle.com>	 <546F3EDD.3020006@citrix.com>
	<1416924878.32327.25.camel@citrix.com>
In-Reply-To: <1416924878.32327.25.camel@citrix.com>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/11/14 14:14, Ian Campbell wrote:
> On Fri, 2014-11-21 at 13:32 +0000, Andrew Cooper wrote:
>> On 20/11/14 16:45, Boris Ostrovsky wrote:
>>> On 11/20/2014 11:15 AM, Ian Campbell wrote:
>>>> On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
>>>>> On 20/11/14 16:00, Ian Campbell wrote:
>>>>>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>>>>>>> c/s d1b93ea causes substantial functional regressions in pygrub's
>>>>>>> ability to
>>>>>>> parse bootloader configuration files.
>>>>>>>
>>>>>>> c/s d1b93ea itself changed an an interface which previously used
>>>>>>> exclusively
>>>>>>> integers, to using strings in the case of a grub configuration
>>>>>>> with explicit
>>>>>>> default set, along with changing the code calling the interface to
>>>>>>> require a
>>>>>>> string.  The default value for "default" remained as an integer.
>>>>>>>
>>>>>>> As a result, any Extlinux or Lilo configuration (which drives this
>>>>>>> interface
>>>>>>> exclusively with integers), or Grub configuration which doesn't
>>>>>>> explicitly
>>>>>>> declare a default will die with an AttributeError when attempting
>>>>>>> to call
>>>>>>> "self.cf.default.isdigit()" where "default" is an integer.
>>>>>>>
>>>>>>> Sadly, this AttributeError gets swallowed by the blanket ignore in
>>>>>>> the loop
>>>>>>> which searches partitions for valid bootloader configurations,
>>>>>>> causing the
>>>>>>> issue to be reported as "Unable to find partition containing kernel"
>>>>>>>
>>>>>>> This patch attempts to fix the issue by altering all parts of this
>>>>>>> interface
>>>>>>> to use strings, as opposed to integers.
>>>>>> Would it be less invasive at this point in the release to have the
>>>>>> place
>>>>>> where this stuff is used do isinstance(s, str) and isinstance(s, int)?
>>>>> It would be BaseString not str, but I am fairly sure the classes have
>>>>> altered through Py2's history.  I would not be any more confident with
>>>>> that as a solution as trying to correctly to start with.
>>>> Actually isinstance(s, basestring) is what the webpage I was looking at
>>>> said, but I cut-n-pasted the wrong thing.
>>>>
>>>> But regardless could it not do something like:
>>>>     if !isinstance(foo.cf.default, int):
>>> I think it would be the other way around, e.g. (not tested):
>>>
>>> diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
>>> index aa7e562..7250f45 100644
>>> --- a/tools/pygrub/src/pygrub
>>> +++ b/tools/pygrub/src/pygrub
>>> @@ -457,7 +457,9 @@ class Grub:
>>>          self.cf.parse(buf)
>>>
>>>      def image_index(self):
>>> -        if self.cf.default.isdigit():
>>> +        if isinstance(self.cf.default, int)
>>> +            sel = self.cf.default
>>> +        elif if self.cf.default.isdigit():
>>>              sel = int(self.cf.default)
>>>          else:
>>>              # We don't fully support submenus. Look for the leaf
>>> value in
>>>
>>> but yes, this looks less intrusive (assuming this the only place where
>>> we'd hit this error).
>>>
>> That does look plausibly like it would fix the issue.
> Is someone going to resubmit a patch along these lines then?
>
> Ian
>
>

Unless you are NAKing my original patch, no.

That is untested, and IMO only a gross hack around the complete type
brokenness introduced by d1b93ea.

I still firmly believe that my patch is the proper solution, which
brings all the types back in line.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:23:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:23:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtItp-0003Sa-56; Tue, 25 Nov 2014 16:23:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtItn-0003SU-4v
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:23:31 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	38/E5-28296-20DA4745; Tue, 25 Nov 2014 16:23:30 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416932607!13724909!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5246 invoked from network); 25 Nov 2014 16:23:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:23:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196234562"
Message-ID: <5474A863.60203@citrix.com>
Date: Tue, 25 Nov 2014 16:03:47 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416237586-17785-1-git-send-email-andrew.cooper3@citrix.com>		
	<1416499238.14429.39.camel@citrix.com>
	<546E1206.5080403@citrix.com>	
	<1416500123.20161.3.camel@citrix.com>
	<546E1ABB.6090308@oracle.com>	 <546F3EDD.3020006@citrix.com>
	<1416924878.32327.25.camel@citrix.com>
In-Reply-To: <1416924878.32327.25.camel@citrix.com>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/11/14 14:14, Ian Campbell wrote:
> On Fri, 2014-11-21 at 13:32 +0000, Andrew Cooper wrote:
>> On 20/11/14 16:45, Boris Ostrovsky wrote:
>>> On 11/20/2014 11:15 AM, Ian Campbell wrote:
>>>> On Thu, 2014-11-20 at 16:08 +0000, Andrew Cooper wrote:
>>>>> On 20/11/14 16:00, Ian Campbell wrote:
>>>>>> On Mon, 2014-11-17 at 15:19 +0000, Andrew Cooper wrote:
>>>>>>> c/s d1b93ea causes substantial functional regressions in pygrub's
>>>>>>> ability to
>>>>>>> parse bootloader configuration files.
>>>>>>>
>>>>>>> c/s d1b93ea itself changed an an interface which previously used
>>>>>>> exclusively
>>>>>>> integers, to using strings in the case of a grub configuration
>>>>>>> with explicit
>>>>>>> default set, along with changing the code calling the interface to
>>>>>>> require a
>>>>>>> string.  The default value for "default" remained as an integer.
>>>>>>>
>>>>>>> As a result, any Extlinux or Lilo configuration (which drives this
>>>>>>> interface
>>>>>>> exclusively with integers), or Grub configuration which doesn't
>>>>>>> explicitly
>>>>>>> declare a default will die with an AttributeError when attempting
>>>>>>> to call
>>>>>>> "self.cf.default.isdigit()" where "default" is an integer.
>>>>>>>
>>>>>>> Sadly, this AttributeError gets swallowed by the blanket ignore in
>>>>>>> the loop
>>>>>>> which searches partitions for valid bootloader configurations,
>>>>>>> causing the
>>>>>>> issue to be reported as "Unable to find partition containing kernel"
>>>>>>>
>>>>>>> This patch attempts to fix the issue by altering all parts of this
>>>>>>> interface
>>>>>>> to use strings, as opposed to integers.
>>>>>> Would it be less invasive at this point in the release to have the
>>>>>> place
>>>>>> where this stuff is used do isinstance(s, str) and isinstance(s, int)?
>>>>> It would be BaseString not str, but I am fairly sure the classes have
>>>>> altered through Py2's history.  I would not be any more confident with
>>>>> that as a solution as trying to correctly to start with.
>>>> Actually isinstance(s, basestring) is what the webpage I was looking at
>>>> said, but I cut-n-pasted the wrong thing.
>>>>
>>>> But regardless could it not do something like:
>>>>     if !isinstance(foo.cf.default, int):
>>> I think it would be the other way around, e.g. (not tested):
>>>
>>> diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
>>> index aa7e562..7250f45 100644
>>> --- a/tools/pygrub/src/pygrub
>>> +++ b/tools/pygrub/src/pygrub
>>> @@ -457,7 +457,9 @@ class Grub:
>>>          self.cf.parse(buf)
>>>
>>>      def image_index(self):
>>> -        if self.cf.default.isdigit():
>>> +        if isinstance(self.cf.default, int)
>>> +            sel = self.cf.default
>>> +        elif if self.cf.default.isdigit():
>>>              sel = int(self.cf.default)
>>>          else:
>>>              # We don't fully support submenus. Look for the leaf
>>> value in
>>>
>>> but yes, this looks less intrusive (assuming this the only place where
>>> we'd hit this error).
>>>
>> That does look plausibly like it would fix the issue.
> Is someone going to resubmit a patch along these lines then?
>
> Ian
>
>

Unless you are NAKing my original patch, no.

That is untested, and IMO only a gross hack around the complete type
brokenness introduced by d1b93ea.

I still firmly believe that my patch is the proper solution, which
brings all the types back in line.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:28:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:28:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIyB-0003ds-RG; Tue, 25 Nov 2014 16:28:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XtIyA-0003dm-Pv
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:28:03 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	3D/EB-02696-21EA4745; Tue, 25 Nov 2014 16:28:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416932881!14782891!1
X-Originating-IP: [81.169.146.220]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25065 invoked from network); 25 Nov 2014 16:28:01 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:28:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416932881; l=395;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=kA/Gk6Xc8hUKbbBc+/w/dkr2qEc=;
	b=MCRSPp2fjqxgyAfEGQ4BieVqWg+jTalbJ8t5CSKRe+oVOTjr611aZe8o6Pa2uqz9SyV
	Ud2rGLwxuTAdKq7Zs71oBPE6t2n/YkVgdAsZHWjQT1j0+W/FYicKpJM4oUdM7wUBG4TLw
	yCmPCY1nooRT2PGG9VEh9c8aUh7Wzz5yecg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.13 AUTH) with ESMTPSA id 307bd4qAPGRrjxz
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 25 Nov 2014 17:27:53 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 4485B50172; Tue, 25 Nov 2014 17:27:53 +0100 (CET)
Date: Tue, 25 Nov 2014 17:27:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141125162753.GA2551@aepfle.de>
References: <1416931449-30679-1-git-send-email-olaf@aepfle.de>
	<20141125161342.GK29886@konrad-lan.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141125161342.GK29886@konrad-lan.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] INSTALL: correct EXTRA_CFLAGS 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, Nov 25, Konrad Rzeszutek Wilk wrote:

> On Tue, Nov 25, 2014 at 05:04:09PM +0100, Olaf Hering wrote:
> > +Using additional CFLAGS to build tools running in dom0 is required when
> Why the mention of 'buld tools running in dom0'? It sounds like it is
> required to use dom0 to build tools?

Does it really read like dom0 is required?! But I can change it as you
suggest.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:28:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:28:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIyB-0003ds-RG; Tue, 25 Nov 2014 16:28:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XtIyA-0003dm-Pv
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:28:03 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	3D/EB-02696-21EA4745; Tue, 25 Nov 2014 16:28:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416932881!14782891!1
X-Originating-IP: [81.169.146.220]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25065 invoked from network); 25 Nov 2014 16:28:01 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:28:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416932881; l=395;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=kA/Gk6Xc8hUKbbBc+/w/dkr2qEc=;
	b=MCRSPp2fjqxgyAfEGQ4BieVqWg+jTalbJ8t5CSKRe+oVOTjr611aZe8o6Pa2uqz9SyV
	Ud2rGLwxuTAdKq7Zs71oBPE6t2n/YkVgdAsZHWjQT1j0+W/FYicKpJM4oUdM7wUBG4TLw
	yCmPCY1nooRT2PGG9VEh9c8aUh7Wzz5yecg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.13 AUTH) with ESMTPSA id 307bd4qAPGRrjxz
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 25 Nov 2014 17:27:53 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 4485B50172; Tue, 25 Nov 2014 17:27:53 +0100 (CET)
Date: Tue, 25 Nov 2014 17:27:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141125162753.GA2551@aepfle.de>
References: <1416931449-30679-1-git-send-email-olaf@aepfle.de>
	<20141125161342.GK29886@konrad-lan.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141125161342.GK29886@konrad-lan.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] INSTALL: correct EXTRA_CFLAGS 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, Nov 25, Konrad Rzeszutek Wilk wrote:

> On Tue, Nov 25, 2014 at 05:04:09PM +0100, Olaf Hering wrote:
> > +Using additional CFLAGS to build tools running in dom0 is required when
> Why the mention of 'buld tools running in dom0'? It sounds like it is
> required to use dom0 to build tools?

Does it really read like dom0 is required?! But I can change it as you
suggest.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:29:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIzI-0003iH-92; Tue, 25 Nov 2014 16:29:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtIzH-0003i8-5x
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:29:11 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	7E/31-02576-65EA4745; Tue, 25 Nov 2014 16:29:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416932946!14776223!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25712 invoked from network); 25 Nov 2014 16:29:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:29:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196238072"
Message-ID: <1416931747.11944.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Nov 2014 16:09:07 +0000
In-Reply-To: <21615.26807.571099.632254@mariner.uk.xensource.com>
References: <1416505070.26869.2.camel@citrix.com>
	<1416575824-15555-4-git-send-email-ian.campbell@citrix.com>
	<21615.26807.571099.632254@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/15] make-flight: Run a basic
 test on each arm platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 16:30 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v3 04/15] make-flight: Run a basic test on each arm platform"):
> > Unlike x86 there is enough variation in the ARM platforms that it is
> > worth having a basic test on each as part of a standard run. This
> > relies on each host having an appropriate platform-$platform host
> > flag.
> 
> Commit message rewrapped so I can quote it.
> 
> I have just noticed, looking at some of your actual patches in
> osstest.git, that `git log' has wrap damage in an 80-column xterm.
> 
> Would it be too much to ask you to go through this series and rewrap
> the commit messages ?

I'd previously experimented with ":set wm=10" in my .vimrc but I
disabled it because it caused all sorts of oddities. Googling it again
it seems like I may actually have wanted ":set tw=70" so I've added
that, lets see how I get on with it.

I've reflowed the commit messages for the patches in my branch with that
ready for v4.

> 
> Aside from that,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:29:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIzI-0003iH-92; Tue, 25 Nov 2014 16:29:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtIzH-0003i8-5x
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:29:11 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	7E/31-02576-65EA4745; Tue, 25 Nov 2014 16:29:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1416932946!14776223!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25712 invoked from network); 25 Nov 2014 16:29:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:29:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196238072"
Message-ID: <1416931747.11944.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Nov 2014 16:09:07 +0000
In-Reply-To: <21615.26807.571099.632254@mariner.uk.xensource.com>
References: <1416505070.26869.2.camel@citrix.com>
	<1416575824-15555-4-git-send-email-ian.campbell@citrix.com>
	<21615.26807.571099.632254@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/15] make-flight: Run a basic
 test on each arm platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-21 at 16:30 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v3 04/15] make-flight: Run a basic test on each arm platform"):
> > Unlike x86 there is enough variation in the ARM platforms that it is
> > worth having a basic test on each as part of a standard run. This
> > relies on each host having an appropriate platform-$platform host
> > flag.
> 
> Commit message rewrapped so I can quote it.
> 
> I have just noticed, looking at some of your actual patches in
> osstest.git, that `git log' has wrap damage in an 80-column xterm.
> 
> Would it be too much to ask you to go through this series and rewrap
> the commit messages ?

I'd previously experimented with ":set wm=10" in my .vimrc but I
disabled it because it caused all sorts of oddities. Googling it again
it seems like I may actually have wanted ":set tw=70" so I've added
that, lets see how I get on with it.

I've reflowed the commit messages for the patches in my branch with that
ready for v4.

> 
> Aside from that,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:29:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIzQ-0003jW-Kq; Tue, 25 Nov 2014 16:29:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtIzO-0003iy-Kr
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:29:18 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	4E/49-29352-D5EA4745; Tue, 25 Nov 2014 16:29:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416932955!13322248!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23413 invoked from network); 25 Nov 2014 16:29:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:29:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196629809"
Message-ID: <1416932950.11944.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>, <ian.jackson@eu.citrix.com>
Date: Tue, 25 Nov 2014 16:29:10 +0000
In-Reply-To: <1416932693.11944.15.camel@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120160307.GB31452@zion.uk.xensource.com>
	<1416932693.11944.15.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 16:24 +0000, Ian Campbell wrote:
> On Thu, 2014-11-20 at 16:03 +0000, Wei Liu wrote:
> > On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
> > > The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> > > is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> > > than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> > > up leaked.
> > > 
> > > The memory pool currently supports mmap'd buffers as well as a directly
> > > allocated buffers, however the try decode routines make use of realloc and do
> > > not fit well into this model. Introduce a concept of an external memory block
> > > to the memory pool and provide an interface to register such memory.
> > > 
> > > The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> > > mmap_ prefix since they are now also used for external memory blocks.
> > > 
> > > We are only seeing this now because the gzip decoder doesn't leak and it's only
> > > relatively recently that kernels in the wild have switched to better
> > > compression.
> > > 
> > > This is https://bugs.debian.org/767295
> > > 
> > > Reported by: Gedalya <gedalya@gedalya.net>
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Reviewed-by: Wei Liu <wei.liu2@citrix.com>
> 
> Thanks. Konrad release-acked on IRC so I've applied.

Ian: THis one should be backported I think.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:29:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtIzQ-0003jW-Kq; Tue, 25 Nov 2014 16:29:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtIzO-0003iy-Kr
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:29:18 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	4E/49-29352-D5EA4745; Tue, 25 Nov 2014 16:29:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416932955!13322248!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23413 invoked from network); 25 Nov 2014 16:29:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:29:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196629809"
Message-ID: <1416932950.11944.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>, <ian.jackson@eu.citrix.com>
Date: Tue, 25 Nov 2014 16:29:10 +0000
In-Reply-To: <1416932693.11944.15.camel@citrix.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120160307.GB31452@zion.uk.xensource.com>
	<1416932693.11944.15.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 16:24 +0000, Ian Campbell wrote:
> On Thu, 2014-11-20 at 16:03 +0000, Wei Liu wrote:
> > On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
> > > The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> > > is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> > > than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> > > up leaked.
> > > 
> > > The memory pool currently supports mmap'd buffers as well as a directly
> > > allocated buffers, however the try decode routines make use of realloc and do
> > > not fit well into this model. Introduce a concept of an external memory block
> > > to the memory pool and provide an interface to register such memory.
> > > 
> > > The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> > > mmap_ prefix since they are now also used for external memory blocks.
> > > 
> > > We are only seeing this now because the gzip decoder doesn't leak and it's only
> > > relatively recently that kernels in the wild have switched to better
> > > compression.
> > > 
> > > This is https://bugs.debian.org/767295
> > > 
> > > Reported by: Gedalya <gedalya@gedalya.net>
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Reviewed-by: Wei Liu <wei.liu2@citrix.com>
> 
> Thanks. Konrad release-acked on IRC so I've applied.

Ian: THis one should be backported I think.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:31:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJ13-0003vg-BA; Tue, 25 Nov 2014 16:31:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1XtJ12-0003vX-JD
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:31:00 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	F7/6F-02696-3CEA4745; Tue, 25 Nov 2014 16:30:59 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416933057!11451894!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25622 invoked from network); 25 Nov 2014 16:30:58 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:30:58 -0000
Received: from int-mx13.intmail.prod.int.phx2.redhat.com
	(int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPGUrth023999
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 25 Nov 2014 11:30:54 -0500
Received: from [10.3.113.9] ([10.3.113.9])
	by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAPGUrhU028882; Tue, 25 Nov 2014 11:30:53 -0500
Message-ID: <5474AEBD.2040308@redhat.com>
Date: Tue, 25 Nov 2014 09:30:53 -0700
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Xu, Quan" <quan.xu@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>	<54736893.6060802@redhat.com>
	<54736B69.1050408@redhat.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8416DC@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E8416DC@SHSMSX101.ccr.corp.intel.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Cc: "lcapitulino@redhat.com" <lcapitulino@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1927713717833047512=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============1927713717833047512==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="ItaGuq0GJeWrwrEfvWpsCjgxorvTumEhE"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ItaGuq0GJeWrwrEfvWpsCjgxorvTumEhE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/25/2014 06:51 AM, Xu, Quan wrote:
>>
>> Also, this message was not threaded properly; it appeared as a top-lev=
el
>> thread along with three other threads for its siblings, instead of all=
 four
>> patches being in-reply-to the 0/4 cover letter.
>>
> Thanks Eric.
>=20
> Should I:=20
>=20
> V2 is version number,=20
> 1. $git format-patch --subject-prefix=3Dv2 -ns --cover-letter master=20
>   Then, edit 0000-cover-letter.patch=20

Rather than '--subject-prefix=3Dv2', I prefer using '-v2'.  The important=

part is that you send the mails with 'git send-email' instead of doing
it by hand.  In fact, you can do 'git send-email --annotate -v2
--cover-letter master' and skip the format-patch altogether, if you are
okay saving your cover letter edits to the point where you are sending
the mails.

>=20
> 2. $git format-patch --subject-prefix=3Dv2 -4=20
>   Then, commit these 4 patch and 0000-cover-letter.patch

I'm not sure what you meant by commit.  You aren't adding the *.patch
files to a repository, but sending them as email.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--ItaGuq0GJeWrwrEfvWpsCjgxorvTumEhE
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
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg

iQEcBAEBCAAGBQJUdK69AAoJEKeha0olJ0Nq+VsH/0DJagKjDrQRxKAU6bPwt/cZ
mQCjOzWJW56akmNPgwL9XTWtDt63Fk1xRcxGEF+Ftiv0y2tRLN5xIlT+w3AujRr0
NFtP2xUYTcUKxFmIZhoGPt5L2hOfBUDs5Aw31VPcff49YZsSTGvtTdiU5WNN/QdN
SsW9NguZg6k3lquCnnJ31huiIDGKI/2J8wWB0kOR9CHZtCtYPJuYRm+Lxm/qTASI
visM57KegiMIhrZLrAyBzKKcGq6Vb0wBwyDWHQ+igw8nQR/t+kURy8gKQZsGVjIe
9pU/aUPUzQjsHWrGvz3Hhen8t3JKM+eekRZKGOZtmrlk2nmjYBz/Pl9tArokWpA=
=e+yB
-----END PGP SIGNATURE-----

--ItaGuq0GJeWrwrEfvWpsCjgxorvTumEhE--


--===============1927713717833047512==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1927713717833047512==--


From xen-devel-bounces@lists.xen.org Tue Nov 25 16:31:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJ13-0003vg-BA; Tue, 25 Nov 2014 16:31:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1XtJ12-0003vX-JD
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:31:00 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	F7/6F-02696-3CEA4745; Tue, 25 Nov 2014 16:30:59 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416933057!11451894!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25622 invoked from network); 25 Nov 2014 16:30:58 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:30:58 -0000
Received: from int-mx13.intmail.prod.int.phx2.redhat.com
	(int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPGUrth023999
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 25 Nov 2014 11:30:54 -0500
Received: from [10.3.113.9] ([10.3.113.9])
	by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAPGUrhU028882; Tue, 25 Nov 2014 11:30:53 -0500
Message-ID: <5474AEBD.2040308@redhat.com>
Date: Tue, 25 Nov 2014 09:30:53 -0700
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Xu, Quan" <quan.xu@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>	<54736893.6060802@redhat.com>
	<54736B69.1050408@redhat.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8416DC@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E8416DC@SHSMSX101.ccr.corp.intel.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Cc: "lcapitulino@redhat.com" <lcapitulino@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1927713717833047512=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============1927713717833047512==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="ItaGuq0GJeWrwrEfvWpsCjgxorvTumEhE"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ItaGuq0GJeWrwrEfvWpsCjgxorvTumEhE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/25/2014 06:51 AM, Xu, Quan wrote:
>>
>> Also, this message was not threaded properly; it appeared as a top-lev=
el
>> thread along with three other threads for its siblings, instead of all=
 four
>> patches being in-reply-to the 0/4 cover letter.
>>
> Thanks Eric.
>=20
> Should I:=20
>=20
> V2 is version number,=20
> 1. $git format-patch --subject-prefix=3Dv2 -ns --cover-letter master=20
>   Then, edit 0000-cover-letter.patch=20

Rather than '--subject-prefix=3Dv2', I prefer using '-v2'.  The important=

part is that you send the mails with 'git send-email' instead of doing
it by hand.  In fact, you can do 'git send-email --annotate -v2
--cover-letter master' and skip the format-patch altogether, if you are
okay saving your cover letter edits to the point where you are sending
the mails.

>=20
> 2. $git format-patch --subject-prefix=3Dv2 -4=20
>   Then, commit these 4 patch and 0000-cover-letter.patch

I'm not sure what you meant by commit.  You aren't adding the *.patch
files to a repository, but sending them as email.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--ItaGuq0GJeWrwrEfvWpsCjgxorvTumEhE
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
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg

iQEcBAEBCAAGBQJUdK69AAoJEKeha0olJ0Nq+VsH/0DJagKjDrQRxKAU6bPwt/cZ
mQCjOzWJW56akmNPgwL9XTWtDt63Fk1xRcxGEF+Ftiv0y2tRLN5xIlT+w3AujRr0
NFtP2xUYTcUKxFmIZhoGPt5L2hOfBUDs5Aw31VPcff49YZsSTGvtTdiU5WNN/QdN
SsW9NguZg6k3lquCnnJ31huiIDGKI/2J8wWB0kOR9CHZtCtYPJuYRm+Lxm/qTASI
visM57KegiMIhrZLrAyBzKKcGq6Vb0wBwyDWHQ+igw8nQR/t+kURy8gKQZsGVjIe
9pU/aUPUzQjsHWrGvz3Hhen8t3JKM+eekRZKGOZtmrlk2nmjYBz/Pl9tArokWpA=
=e+yB
-----END PGP SIGNATURE-----

--ItaGuq0GJeWrwrEfvWpsCjgxorvTumEhE--


--===============1927713717833047512==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1927713717833047512==--


From xen-devel-bounces@lists.xen.org Tue Nov 25 16:32:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:32:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJ2p-0004Ci-4D; Tue, 25 Nov 2014 16:32: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 1XtJ2n-0004CW-K4
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 16:32:49 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	55/2C-11581-03FA4745; Tue, 25 Nov 2014 16:32:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416933167!9178949!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16195 invoked from network); 25 Nov 2014 16:32:48 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2014 16:32:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 16:32:47 +0000
Message-Id: <5474BD3C020000780004AC91@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 16:32:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	<1412687413-22818-4-git-send-email-vkuznets@redhat.com>
	<5474A568020000780004AB93@mail.emea.novell.com><5474A568020000780004AB93@mail.emea.novell.com>
	(Jan Beulich's message of "Tue, 25 Nov 2014 14:51:04 +0000")
	<8761e35lui.fsf@vitty.brq.redhat.com>
In-Reply-To: <8761e35lui.fsf@vitty.brq.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 3/8] xen: introduce
	XEN_DOMCTL_set_recipient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:41, <vkuznets@redhat.com> wrote:
> "Jan Beulich" <JBeulich@suse.com> writes:
>>>>> On 07.10.14 at 15:10, <vkuznets@redhat.com> wrote:
>>> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>>>              scrub = 1;
>>>          }
>>>  
>>> -        if ( unlikely(scrub) )
>>> -            for ( i = 0; i < (1 << order); i++ )
>>> -                scrub_one_page(&pg[i]);
>>> +        if ( !d || !d->recipient || d->recipient->is_dying )
>>> +        {
>>> +            if ( unlikely(scrub) )
>>> +                for ( i = 0; i < (1 << order); i++ )
>>> +                    scrub_one_page(&pg[i]);
>>>  
>>> -        free_heap_pages(pg, order);
>>> +            free_heap_pages(pg, order);
>>> +        }
>>> +        else
>>> +        {
>>> +            mfn = page_to_mfn(pg);
>>> +            gmfn = mfn_to_gmfn(d, mfn);
>>> +
>>> +            page_set_owner(pg, NULL);
>>> +            assign_pages(d->recipient, pg, order, 0);
>>
>> This can fail.
> 
> .. if the recipient is dying or we're over-allocating. Shouldn't happen
> (if toolstack does its job right) but I'll add a check.

You must not rely on the tool stack doing things right (see XSA-77).

>> What's worse though is that you don't guard against
>> XEN_DOMCTL_set_recipient zapping d->recipient. If that really is
>> necessary to be supported, some synchronization will be needed.
>>
>> And finally - what's the intended protocol for the tool stack to
>> know that all pages got transferred (and hence the new domain
>> can be launched)?
>>
> 
> (hope this answers both questions above)
> 
> Now the protocol is:
> 1) Toolstack queries for all page frames (with xc_get_pfn_type_batch())
> for the old domain.
> 2) Toolstack issues XEN_DOMCTL_set_recipient with the recipient domain
> 3) Toolstack kills the source domain
> 4) Toolstack waits for awhile (loop keeps checking while we see new pages
> arriving + some timeout).
> 5) Toolstack issues XEN_DOMCTL_set_recipient with DOMID_INVALID
> resetting recipient.
> 6) Toolstack checks if all pages were transferred
> 7) If some pages are missing (e.g. source domain became zombie holding
> something) request new empty pages instead.
> 8) Toolstack starts new domain
> 
> So we don't actually need XEN_DOMCTL_set_recipient to switch from one
> recipient to the other, we just need a way to reset it.

No, this doesn't address either question. For the first one, you again
assume the tool stack behaves correctly, which is wrong nowadays.
And for the second you give a description, but that's not really a
dependable protocol. Nor do I really follow why resetting the recipient
is necessary. Can't the tools e.g. wait for the final death of the domain
if there's no other notification?

>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/include/public/domctl.h
>>> @@ -965,6 +965,23 @@ struct xen_domctl_vnuma {
>>>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
>>>  
>>> +/*
>>> + * XEN_DOMCTL_set_recipient - sets the 'recipient' domain which will recieve
>>> + * all the domain's memory after its death or when and memory page from
>>> + * domain's heap is being freed.
>>
>> So this specifically allows for this to happen on a non-dying domain.
>> Why, i.e. what's the intended usage scenario? If not really needed,
>> please remove this and verify in the handling that the source domain
>> is dying.
> 
> Sorry if I didn't get this comment right. We need a way to tell which
> domain will recieve memory and XEN_DOMCTL_set_recipient sets (and
> resets) this target domain. We call it from toolstack before we start
> killing old domain so it is not dying yet. We can't do it
> hypervistor-side when our source domain exits doing SHUTDOWN_soft_reset
> as there is no recipient domain created yet.
> 
> From a general (hypervisor) point of view we don't actually care if the
> domain is dying or not. We just want to recieve all freed pages from
> this domain (so they go to some other domain instead of trash).

We do care I think, primarily because we want a correct GMFN <->
MFN mapping. Seeing multiple pages for the same GMFN is for
example going to cause the whole process in its current form to fail.
And considering the need for such a correct mapping - is it always
the case that the mapping gets updated after a page got removed
from a guest? (I can see that the mapping doesn't change anymore
for a dying guest, but you explicitly say that you want/need this to
work before the guest is actually marked dying.)

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:32:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:32:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJ2p-0004Ci-4D; Tue, 25 Nov 2014 16:32: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 1XtJ2n-0004CW-K4
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 16:32:49 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	55/2C-11581-03FA4745; Tue, 25 Nov 2014 16:32:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1416933167!9178949!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16195 invoked from network); 25 Nov 2014 16:32:48 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2014 16:32:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 16:32:47 +0000
Message-Id: <5474BD3C020000780004AC91@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 16:32:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	<1412687413-22818-4-git-send-email-vkuznets@redhat.com>
	<5474A568020000780004AB93@mail.emea.novell.com><5474A568020000780004AB93@mail.emea.novell.com>
	(Jan Beulich's message of "Tue, 25 Nov 2014 14:51:04 +0000")
	<8761e35lui.fsf@vitty.brq.redhat.com>
In-Reply-To: <8761e35lui.fsf@vitty.brq.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 3/8] xen: introduce
	XEN_DOMCTL_set_recipient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 16:41, <vkuznets@redhat.com> wrote:
> "Jan Beulich" <JBeulich@suse.com> writes:
>>>>> On 07.10.14 at 15:10, <vkuznets@redhat.com> wrote:
>>> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>>>              scrub = 1;
>>>          }
>>>  
>>> -        if ( unlikely(scrub) )
>>> -            for ( i = 0; i < (1 << order); i++ )
>>> -                scrub_one_page(&pg[i]);
>>> +        if ( !d || !d->recipient || d->recipient->is_dying )
>>> +        {
>>> +            if ( unlikely(scrub) )
>>> +                for ( i = 0; i < (1 << order); i++ )
>>> +                    scrub_one_page(&pg[i]);
>>>  
>>> -        free_heap_pages(pg, order);
>>> +            free_heap_pages(pg, order);
>>> +        }
>>> +        else
>>> +        {
>>> +            mfn = page_to_mfn(pg);
>>> +            gmfn = mfn_to_gmfn(d, mfn);
>>> +
>>> +            page_set_owner(pg, NULL);
>>> +            assign_pages(d->recipient, pg, order, 0);
>>
>> This can fail.
> 
> .. if the recipient is dying or we're over-allocating. Shouldn't happen
> (if toolstack does its job right) but I'll add a check.

You must not rely on the tool stack doing things right (see XSA-77).

>> What's worse though is that you don't guard against
>> XEN_DOMCTL_set_recipient zapping d->recipient. If that really is
>> necessary to be supported, some synchronization will be needed.
>>
>> And finally - what's the intended protocol for the tool stack to
>> know that all pages got transferred (and hence the new domain
>> can be launched)?
>>
> 
> (hope this answers both questions above)
> 
> Now the protocol is:
> 1) Toolstack queries for all page frames (with xc_get_pfn_type_batch())
> for the old domain.
> 2) Toolstack issues XEN_DOMCTL_set_recipient with the recipient domain
> 3) Toolstack kills the source domain
> 4) Toolstack waits for awhile (loop keeps checking while we see new pages
> arriving + some timeout).
> 5) Toolstack issues XEN_DOMCTL_set_recipient with DOMID_INVALID
> resetting recipient.
> 6) Toolstack checks if all pages were transferred
> 7) If some pages are missing (e.g. source domain became zombie holding
> something) request new empty pages instead.
> 8) Toolstack starts new domain
> 
> So we don't actually need XEN_DOMCTL_set_recipient to switch from one
> recipient to the other, we just need a way to reset it.

No, this doesn't address either question. For the first one, you again
assume the tool stack behaves correctly, which is wrong nowadays.
And for the second you give a description, but that's not really a
dependable protocol. Nor do I really follow why resetting the recipient
is necessary. Can't the tools e.g. wait for the final death of the domain
if there's no other notification?

>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/include/public/domctl.h
>>> @@ -965,6 +965,23 @@ struct xen_domctl_vnuma {
>>>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
>>>  
>>> +/*
>>> + * XEN_DOMCTL_set_recipient - sets the 'recipient' domain which will recieve
>>> + * all the domain's memory after its death or when and memory page from
>>> + * domain's heap is being freed.
>>
>> So this specifically allows for this to happen on a non-dying domain.
>> Why, i.e. what's the intended usage scenario? If not really needed,
>> please remove this and verify in the handling that the source domain
>> is dying.
> 
> Sorry if I didn't get this comment right. We need a way to tell which
> domain will recieve memory and XEN_DOMCTL_set_recipient sets (and
> resets) this target domain. We call it from toolstack before we start
> killing old domain so it is not dying yet. We can't do it
> hypervistor-side when our source domain exits doing SHUTDOWN_soft_reset
> as there is no recipient domain created yet.
> 
> From a general (hypervisor) point of view we don't actually care if the
> domain is dying or not. We just want to recieve all freed pages from
> this domain (so they go to some other domain instead of trash).

We do care I think, primarily because we want a correct GMFN <->
MFN mapping. Seeing multiple pages for the same GMFN is for
example going to cause the whole process in its current form to fail.
And considering the need for such a correct mapping - is it always
the case that the mapping gets updated after a page got removed
from a guest? (I can see that the mapping doesn't change anymore
for a dying guest, but you explicitly say that you want/need this to
work before the guest is actually marked dying.)

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:40:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJ9l-0004PC-3m; Tue, 25 Nov 2014 16:40:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtJ9k-0004P2-81
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:40:00 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	5D/61-18267-FD0B4745; Tue, 25 Nov 2014 16:39:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416933598!13715581!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5340 invoked from network); 25 Nov 2014 16:39:59 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:39:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 16:39:58 +0000
Message-Id: <5474BEEA020000780004ACB1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 16:39:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
	<54744FB2020000780004A935@mail.emea.novell.com>
	<54749466.1020907@oracle.com>
	<5474A666020000780004AB9C@mail.emea.novell.com>
	<5474ABFF.1030306@oracle.com>
In-Reply-To: <5474ABFF.1030306@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
 PVH 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 25.11.14 at 17:19, <boris.ostrovsky@oracle.com> wrote:
> On 11/25/2014 09:55 AM, Jan Beulich wrote:
>>
>>> Regardless, do you think that disabling VPMU for PVH is worth anyway?
>> That depends on what (bad) consequences not doing so has.
> 
> I haven't seen anything (besides VAPIC accesses) but I think it would be 
> prudent to prevent any VPMU activity from happening. I can see, for 
> example MSRs and APIC vector being written. All of which look benign on 
> the first sight but who knows...

Yeah, it's not really a problem to put it in (if Konrad agrees; remember
that PVH is still experimental, and hence fixing bugs caused only by it
may be out of scope at this point - in any event I think that if your
patch is to go in, mine should too).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:40:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJ9l-0004PC-3m; Tue, 25 Nov 2014 16:40:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtJ9k-0004P2-81
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:40:00 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	5D/61-18267-FD0B4745; Tue, 25 Nov 2014 16:39:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1416933598!13715581!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5340 invoked from network); 25 Nov 2014 16:39:59 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:39:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 16:39:58 +0000
Message-Id: <5474BEEA020000780004ACB1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 16:39:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
	<54744FB2020000780004A935@mail.emea.novell.com>
	<54749466.1020907@oracle.com>
	<5474A666020000780004AB9C@mail.emea.novell.com>
	<5474ABFF.1030306@oracle.com>
In-Reply-To: <5474ABFF.1030306@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
 PVH 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 25.11.14 at 17:19, <boris.ostrovsky@oracle.com> wrote:
> On 11/25/2014 09:55 AM, Jan Beulich wrote:
>>
>>> Regardless, do you think that disabling VPMU for PVH is worth anyway?
>> That depends on what (bad) consequences not doing so has.
> 
> I haven't seen anything (besides VAPIC accesses) but I think it would be 
> prudent to prevent any VPMU activity from happening. I can see, for 
> example MSRs and APIC vector being written. All of which look benign on 
> the first sight but who knows...

Yeah, it's not really a problem to put it in (if Konrad agrees; remember
that PVH is still experimental, and hence fixing bugs caused only by it
may be out of scope at this point - in any event I think that if your
patch is to go in, mine should too).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:42:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJBy-0004VT-7V; Tue, 25 Nov 2014 16:42:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtJBw-0004V6-DE
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 16:42:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E2/93-09842-761B4745; Tue, 25 Nov 2014 16:42:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416933731!14922234!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9035 invoked from network); 25 Nov 2014 16:42: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;
	25 Nov 2014 16:42:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196244709"
Message-ID: <1416932286.11944.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <jgross@suse.com>
Date: Tue, 25 Nov 2014 16:18:06 +0000
In-Reply-To: <5474AA00.8050500@suse.com>
References: <546EFAE3.80404@suse.com>
	<20141121135747.GB2886@laptop.dumpdata.com> <5473008C.4080604@suse.com>
	<1416823327.26329.25.camel@citrix.com> <5474AA00.8050500@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-rc5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 17:10 +0100, Juergen Gross wrote:
> On 11/24/2014 11:02 AM, Ian Campbell wrote:
> > On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
> >> On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
> >>>> Hi,
> >>>>
> >>>> while testing my "linear p2m list" patches I saw the following
> >>>> problem (even without my patches in place):
> >>>>
> >>>> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
> >>>> disk image of a guest by attaching it to dom0:
> >>>>
> >>>> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
> >>>> mount /dev/xvda2 /mnt
> >>>> ...
> >>>> umount /mnt
> >>>> xl block-detach 0 xvda
> >>
> >> Did some more testing:
> >> - Seems to occur only when attaching a block device to dom0
> >
> > That means a qdisk backed situation then, I think.
> >
> > Is your qemu up to date?
> >
> > http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=commit;h=abbbc2f09a53f8f9ee565356ab11a78af006e45e resulted in slightly different messages, but could be related?
> 
> Tried it with xen-unstable and newest qemu. Now I have another problem:
> 
> xl -vvv block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
> libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0: create: 
> how=(nil) callback=(nil) poller=0xbac1d0
> libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to add device
> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xbac0f0: 
> complete, rc=-16
> libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0: 
> inprogress: poller=0xbac1d0, flags=ic
> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xbac0f0: destroy
> libxl_device_disk_add failed.
> 
> 
> rc=-16 means ERROR_JSON_CONFIG_EMPTY.

Have you updated your initscripts to run the xen-init-dom0 helper? This
replaced the manual xenstore-write stuff a little while back and added
some other init, including creating the necessary json description of
dom0.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:42:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJBy-0004VT-7V; Tue, 25 Nov 2014 16:42:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtJBw-0004V6-DE
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 16:42:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E2/93-09842-761B4745; Tue, 25 Nov 2014 16:42:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416933731!14922234!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9035 invoked from network); 25 Nov 2014 16:42: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;
	25 Nov 2014 16:42:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196244709"
Message-ID: <1416932286.11944.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <jgross@suse.com>
Date: Tue, 25 Nov 2014 16:18:06 +0000
In-Reply-To: <5474AA00.8050500@suse.com>
References: <546EFAE3.80404@suse.com>
	<20141121135747.GB2886@laptop.dumpdata.com> <5473008C.4080604@suse.com>
	<1416823327.26329.25.camel@citrix.com> <5474AA00.8050500@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-rc5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 17:10 +0100, Juergen Gross wrote:
> On 11/24/2014 11:02 AM, Ian Campbell wrote:
> > On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
> >> On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
> >>>> Hi,
> >>>>
> >>>> while testing my "linear p2m list" patches I saw the following
> >>>> problem (even without my patches in place):
> >>>>
> >>>> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
> >>>> disk image of a guest by attaching it to dom0:
> >>>>
> >>>> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
> >>>> mount /dev/xvda2 /mnt
> >>>> ...
> >>>> umount /mnt
> >>>> xl block-detach 0 xvda
> >>
> >> Did some more testing:
> >> - Seems to occur only when attaching a block device to dom0
> >
> > That means a qdisk backed situation then, I think.
> >
> > Is your qemu up to date?
> >
> > http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=commit;h=abbbc2f09a53f8f9ee565356ab11a78af006e45e resulted in slightly different messages, but could be related?
> 
> Tried it with xen-unstable and newest qemu. Now I have another problem:
> 
> xl -vvv block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
> libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0: create: 
> how=(nil) callback=(nil) poller=0xbac1d0
> libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to add device
> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xbac0f0: 
> complete, rc=-16
> libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0: 
> inprogress: poller=0xbac1d0, flags=ic
> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xbac0f0: destroy
> libxl_device_disk_add failed.
> 
> 
> rc=-16 means ERROR_JSON_CONFIG_EMPTY.

Have you updated your initscripts to run the xen-init-dom0 helper? This
replaced the manual xenstore-write stuff a little while back and added
some other init, including creating the necessary json description of
dom0.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:48:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:48:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJHx-0004kV-1E; Tue, 25 Nov 2014 16:48: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 1XtJHv-0004kQ-Mu
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:48:27 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	D9/81-01660-BD2B4745; Tue, 25 Nov 2014 16:48:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416934102!13296984!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3368 invoked from network); 25 Nov 2014 16:48:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:48:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196248635"
Message-ID: <1416932693.11944.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 25 Nov 2014 16:24:53 +0000
In-Reply-To: <20141120160307.GB31452@zion.uk.xensource.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120160307.GB31452@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:03 +0000, Wei Liu wrote:
> On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
> > The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> > is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> > than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> > up leaked.
> > 
> > The memory pool currently supports mmap'd buffers as well as a directly
> > allocated buffers, however the try decode routines make use of realloc and do
> > not fit well into this model. Introduce a concept of an external memory block
> > to the memory pool and provide an interface to register such memory.
> > 
> > The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> > mmap_ prefix since they are now also used for external memory blocks.
> > 
> > We are only seeing this now because the gzip decoder doesn't leak and it's only
> > relatively recently that kernels in the wild have switched to better
> > compression.
> > 
> > This is https://bugs.debian.org/767295
> > 
> > Reported by: Gedalya <gedalya@gedalya.net>
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Reviewed-by: Wei Liu <wei.liu2@citrix.com>

Thanks. Konrad release-acked on IRC so I've applied.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:48:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:48:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJHx-0004kV-1E; Tue, 25 Nov 2014 16:48: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 1XtJHv-0004kQ-Mu
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:48:27 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	D9/81-01660-BD2B4745; Tue, 25 Nov 2014 16:48:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416934102!13296984!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3368 invoked from network); 25 Nov 2014 16:48:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:48:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196248635"
Message-ID: <1416932693.11944.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 25 Nov 2014 16:24:53 +0000
In-Reply-To: <20141120160307.GB31452@zion.uk.xensource.com>
References: <1416498527-32441-1-git-send-email-ian.campbell@citrix.com>
	<20141120160307.GB31452@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] libxc: don't leak buffer
 containing the uncompressed PV kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 16:03 +0000, Wei Liu wrote:
> On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote:
> > The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> > is freed by xc_dom_release. However the various xc_try_*_decode routines (other
> > than the gzip one) just use plain malloc/realloc and therefore the buffer ends
> > up leaked.
> > 
> > The memory pool currently supports mmap'd buffers as well as a directly
> > allocated buffers, however the try decode routines make use of realloc and do
> > not fit well into this model. Introduce a concept of an external memory block
> > to the memory pool and provide an interface to register such memory.
> > 
> > The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
> > mmap_ prefix since they are now also used for external memory blocks.
> > 
> > We are only seeing this now because the gzip decoder doesn't leak and it's only
> > relatively recently that kernels in the wild have switched to better
> > compression.
> > 
> > This is https://bugs.debian.org/767295
> > 
> > Reported by: Gedalya <gedalya@gedalya.net>
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Reviewed-by: Wei Liu <wei.liu2@citrix.com>

Thanks. Konrad release-acked on IRC so I've applied.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:48:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16: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 1XtJIF-0004mD-Dw; Tue, 25 Nov 2014 16:48:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtJID-0004m0-Ov
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 16:48:45 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	7F/7B-28865-DE2B4745; Tue, 25 Nov 2014 16:48:45 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416934124!13297044!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5517 invoked from network); 25 Nov 2014 16:48:44 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:48:44 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DBE59ADC8;
	Tue, 25 Nov 2014 16:48:43 +0000 (UTC)
Message-ID: <5474B2EB.6090306@suse.com>
Date: Tue, 25 Nov 2014 17:48:43 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546EFAE3.80404@suse.com>		
	<20141121135747.GB2886@laptop.dumpdata.com>
	<5473008C.4080604@suse.com>	 <1416823327.26329.25.camel@citrix.com>
	<5474AA00.8050500@suse.com> <1416932286.11944.12.camel@citrix.com>
In-Reply-To: <1416932286.11944.12.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 05:18 PM, Ian Campbell wrote:
> On Tue, 2014-11-25 at 17:10 +0100, Juergen Gross wrote:
>> On 11/24/2014 11:02 AM, Ian Campbell wrote:
>>> On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
>>>> On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
>>>>>> Hi,
>>>>>>
>>>>>> while testing my "linear p2m list" patches I saw the following
>>>>>> problem (even without my patches in place):
>>>>>>
>>>>>> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
>>>>>> disk image of a guest by attaching it to dom0:
>>>>>>
>>>>>> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
>>>>>> mount /dev/xvda2 /mnt
>>>>>> ...
>>>>>> umount /mnt
>>>>>> xl block-detach 0 xvda
>>>>
>>>> Did some more testing:
>>>> - Seems to occur only when attaching a block device to dom0
>>>
>>> That means a qdisk backed situation then, I think.
>>>
>>> Is your qemu up to date?
>>>
>>> http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=commit;h=abbbc2f09a53f8f9ee565356ab11a78af006e45e resulted in slightly different messages, but could be related?
>>
>> Tried it with xen-unstable and newest qemu. Now I have another problem:
>>
>> xl -vvv block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
>> libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0: create:
>> how=(nil) callback=(nil) poller=0xbac1d0
>> libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to add device
>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xbac0f0:
>> complete, rc=-16
>> libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0:
>> inprogress: poller=0xbac1d0, flags=ic
>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xbac0f0: destroy
>> libxl_device_disk_add failed.
>>
>>
>> rc=-16 means ERROR_JSON_CONFIG_EMPTY.
>
> Have you updated your initscripts to run the xen-init-dom0 helper? This
> replaced the manual xenstore-write stuff a little while back and added
> some other init, including creating the necessary json description of
> dom0.

Bingo! Now it works.

Thanks,

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:48:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16: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 1XtJIF-0004mD-Dw; Tue, 25 Nov 2014 16:48:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtJID-0004m0-Ov
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 16:48:45 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	7F/7B-28865-DE2B4745; Tue, 25 Nov 2014 16:48:45 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416934124!13297044!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5517 invoked from network); 25 Nov 2014 16:48:44 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 16:48:44 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DBE59ADC8;
	Tue, 25 Nov 2014 16:48:43 +0000 (UTC)
Message-ID: <5474B2EB.6090306@suse.com>
Date: Tue, 25 Nov 2014 17:48:43 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546EFAE3.80404@suse.com>		
	<20141121135747.GB2886@laptop.dumpdata.com>
	<5473008C.4080604@suse.com>	 <1416823327.26329.25.camel@citrix.com>
	<5474AA00.8050500@suse.com> <1416932286.11944.12.camel@citrix.com>
In-Reply-To: <1416932286.11944.12.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 05:18 PM, Ian Campbell wrote:
> On Tue, 2014-11-25 at 17:10 +0100, Juergen Gross wrote:
>> On 11/24/2014 11:02 AM, Ian Campbell wrote:
>>> On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
>>>> On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
>>>>>> Hi,
>>>>>>
>>>>>> while testing my "linear p2m list" patches I saw the following
>>>>>> problem (even without my patches in place):
>>>>>>
>>>>>> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
>>>>>> disk image of a guest by attaching it to dom0:
>>>>>>
>>>>>> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
>>>>>> mount /dev/xvda2 /mnt
>>>>>> ...
>>>>>> umount /mnt
>>>>>> xl block-detach 0 xvda
>>>>
>>>> Did some more testing:
>>>> - Seems to occur only when attaching a block device to dom0
>>>
>>> That means a qdisk backed situation then, I think.
>>>
>>> Is your qemu up to date?
>>>
>>> http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=commit;h=abbbc2f09a53f8f9ee565356ab11a78af006e45e resulted in slightly different messages, but could be related?
>>
>> Tried it with xen-unstable and newest qemu. Now I have another problem:
>>
>> xl -vvv block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
>> libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0: create:
>> how=(nil) callback=(nil) poller=0xbac1d0
>> libxl: error: libxl.c:1897:device_addrm_aocomplete: unable to add device
>> libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xbac0f0:
>> complete, rc=-16
>> libxl: debug: libxl.c:4178:libxl_device_disk_add: ao 0xbac0f0:
>> inprogress: poller=0xbac1d0, flags=ic
>> libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xbac0f0: destroy
>> libxl_device_disk_add failed.
>>
>>
>> rc=-16 means ERROR_JSON_CONFIG_EMPTY.
>
> Have you updated your initscripts to run the xen-init-dom0 helper? This
> replaced the manual xenstore-write stuff a little while back and added
> some other init, including creating the necessary json description of
> dom0.

Bingo! Now it works.

Thanks,

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:49:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJIq-0004rb-Rf; Tue, 25 Nov 2014 16:49:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtJIp-0004rS-KN
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 16:49:23 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	A6/D6-18267-213B4745; Tue, 25 Nov 2014 16:49:22 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416934159!10040713!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11194 invoked from network); 25 Nov 2014 16:49:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:49:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196639811"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 11:49:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtJIe-0006E7-CQ;
	Tue, 25 Nov 2014 16:49:12 +0000
Date: Tue, 25 Nov 2014 16:49:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416925448.32327.27.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Ian Campbell wrote:
> On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > Account for the extra memory needed for the rom files of any emulated nics:
> > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > each them. Assume 256K each.
> 
> I suppose this will have to do for 4.5. Can we do something better in
> the future -- like figuring out a way for guests to have
> "not-really-RAM" allocations like this which are made by the toolstack
> and happen to be backed by RAM not count or something.
> 
> > 
> > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > assigned to a VM.
> 
> Are you also going to fix qemu to fail gracefully if it cannot deploy
> option roms? abort() seems a bit extreme.
> 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: Don Slutz <dslutz@verizon.com>
> > CC: hanyandong <hanyandong@iie.ac.cn>
> > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > CC: Wei Liu <wei.liu2@citrix.com>
> 
> You missed Ian J. I've added him.

Actually Wei suggested a better alternative: I could call
xc_domain_setmaxmem directly from QEMU. That makes much more sense.


> > 
> > ---
> > 
> > Changes in v2:
> > - remove double return statement;
> > - check for return errors;
> > - check for overflows.
> > ---
> >  tools/libxl/libxl.c          |   53 +++++++++++++++++++++++++++++++++++++-----
> >  tools/libxl/libxl_dom.c      |    8 +++++--
> >  tools/libxl/libxl_internal.h |    7 ++++++
> >  3 files changed, 60 insertions(+), 8 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index de23fec..2cdb768 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4527,13 +4527,40 @@ out:
> >  
> >  /******************************************************************************/
> >  
> > +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> > +{
> > +    int i, romsize, rc;
> > +    libxl_domain_config local_d_config;
> > +    libxl_ctx *ctx = libxl__gc_owner(gc);
> > +
> > +    if (d_config == NULL) {
> > +        libxl_domain_config_init(&local_d_config);
> > +        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
> > +        if (rc < 0)
> > +            return rc;
> > +        d_config = &local_d_config;
> > +    }
> 
> Perhaps we could store the answer to this function in XS when we build
> the domain and simply read it back and account for it in the places
> which use it?
> 
> Apart from being rather costly reparsing the json every time is going to
> behave a bit strangely if NICs are plugged/unplugged at runtime and
> ballooning is going on.
> 
> > +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> > +        return 0;
> > +
> > +    for (i = 0, romsize = 0;
> > +         i < d_config->num_nics && romsize < INT_MAX;
> 
> I don't think that romsize < INT_MAX is useful except in the case that
> romsize+= results in romsize == INT_MAX. If you actually overflow then
> romsize becomes negative which satisfies the condition (and in any case
> you are into undefined behaviour territory there anyhow, I think).
> 
> Given that INT_MAX is a boat load of ROMs I'd be inclined to just limit
> it to INT_MAX/2 or /4 or something.
> 
> Or you could do romsize < (INT_MAX - LIBXL_ROMSIZE_KB) I suppose.
> 
> > +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> > +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> > +                             + romsize);
> 
> Seems like we ought to have a helper to return the memory overheads,
> which would be the constant + the romsize starting from 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 Nov 25 16:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:49:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJIq-0004rb-Rf; Tue, 25 Nov 2014 16:49:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtJIp-0004rS-KN
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 16:49:23 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	A6/D6-18267-213B4745; Tue, 25 Nov 2014 16:49:22 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1416934159!10040713!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11194 invoked from network); 25 Nov 2014 16:49:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:49:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196639811"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 11:49:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtJIe-0006E7-CQ;
	Tue, 25 Nov 2014 16:49:12 +0000
Date: Tue, 25 Nov 2014 16:49:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416925448.32327.27.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Ian Campbell wrote:
> On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > Account for the extra memory needed for the rom files of any emulated nics:
> > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > each them. Assume 256K each.
> 
> I suppose this will have to do for 4.5. Can we do something better in
> the future -- like figuring out a way for guests to have
> "not-really-RAM" allocations like this which are made by the toolstack
> and happen to be backed by RAM not count or something.
> 
> > 
> > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > assigned to a VM.
> 
> Are you also going to fix qemu to fail gracefully if it cannot deploy
> option roms? abort() seems a bit extreme.
> 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: Don Slutz <dslutz@verizon.com>
> > CC: hanyandong <hanyandong@iie.ac.cn>
> > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > CC: Wei Liu <wei.liu2@citrix.com>
> 
> You missed Ian J. I've added him.

Actually Wei suggested a better alternative: I could call
xc_domain_setmaxmem directly from QEMU. That makes much more sense.


> > 
> > ---
> > 
> > Changes in v2:
> > - remove double return statement;
> > - check for return errors;
> > - check for overflows.
> > ---
> >  tools/libxl/libxl.c          |   53 +++++++++++++++++++++++++++++++++++++-----
> >  tools/libxl/libxl_dom.c      |    8 +++++--
> >  tools/libxl/libxl_internal.h |    7 ++++++
> >  3 files changed, 60 insertions(+), 8 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index de23fec..2cdb768 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4527,13 +4527,40 @@ out:
> >  
> >  /******************************************************************************/
> >  
> > +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> > +{
> > +    int i, romsize, rc;
> > +    libxl_domain_config local_d_config;
> > +    libxl_ctx *ctx = libxl__gc_owner(gc);
> > +
> > +    if (d_config == NULL) {
> > +        libxl_domain_config_init(&local_d_config);
> > +        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
> > +        if (rc < 0)
> > +            return rc;
> > +        d_config = &local_d_config;
> > +    }
> 
> Perhaps we could store the answer to this function in XS when we build
> the domain and simply read it back and account for it in the places
> which use it?
> 
> Apart from being rather costly reparsing the json every time is going to
> behave a bit strangely if NICs are plugged/unplugged at runtime and
> ballooning is going on.
> 
> > +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> > +        return 0;
> > +
> > +    for (i = 0, romsize = 0;
> > +         i < d_config->num_nics && romsize < INT_MAX;
> 
> I don't think that romsize < INT_MAX is useful except in the case that
> romsize+= results in romsize == INT_MAX. If you actually overflow then
> romsize becomes negative which satisfies the condition (and in any case
> you are into undefined behaviour territory there anyhow, I think).
> 
> Given that INT_MAX is a boat load of ROMs I'd be inclined to just limit
> it to INT_MAX/2 or /4 or something.
> 
> Or you could do romsize < (INT_MAX - LIBXL_ROMSIZE_KB) I suppose.
> 
> > +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> > +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> > +                             + romsize);
> 
> Seems like we ought to have a helper to return the memory overheads,
> which would be the constant + the romsize starting from 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 Nov 25 16:50:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:50:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJJl-00050f-Fw; Tue, 25 Nov 2014 16:50: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 1XtJJk-00050R-7C
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:50:20 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	83/12-03145-B43B4745; Tue, 25 Nov 2014 16:50:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416934214!14764920!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15209 invoked from network); 25 Nov 2014 16:50:18 -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;
	25 Nov 2014 16:50:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196249988"
Message-ID: <1416932847.11944.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Nov 2014 16:27:27 +0000
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 00/15] support for ARM32 arndale
 and cubietruck 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

On Thu, 2014-11-20 at 17:37 +0000, Ian Campbell wrote:
> The major blocker right now is that rerunning
> mg-debian-installer-update pulls in a newer kernel from backports.org
> which doesn't boot on the existing midway platform. I'm investigating
> that at the moment.

This investigation resulted in an upstream patch:
http://thread.gmane.org/gmane.linux.drivers.devicetree/100386
http://thread.gmane.org/gmane.linux.drivers.devicetree/100420

which I hope will go upstream shortly.

The underlying issue was a bogus size field in the header of the DT
which is burnt into these systems. When booting via the u-boot command
line this can be worked around with:
   fdt addr $fdt_addr
   fdt resize
which walks the FDT, recalculates the real size and updates the header.

Unfortunately there is no opportunity to do this when booting via PXE,
as we do for host install.

Given the lack of support from the, now-defunct, manufacture of these
systems I'm a bit reluctant to go poking around in the firmware to fixup
the embedded FDT in case I brick it.

I think the fix will go upstream shortly, then I can add it to the
Debian kernel, get it uploaded, wait for it to propagate into Jessie,
get it uploaded to bpo.

In principal I could build us a custom kernel deb to use here (it's
reasonably easy for me), but would you be happy with that? Perhaps
mg-update-debian-installer should be modified to look in some locally
constructed repo instead of at bpo? I'm wary of doing this, since it
just makes it harder for someone else to replicate things, plus it just
seems dodgy...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:50:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:50:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJJl-00050f-Fw; Tue, 25 Nov 2014 16:50: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 1XtJJk-00050R-7C
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:50:20 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	83/12-03145-B43B4745; Tue, 25 Nov 2014 16:50:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416934214!14764920!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15209 invoked from network); 25 Nov 2014 16:50:18 -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;
	25 Nov 2014 16:50:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196249988"
Message-ID: <1416932847.11944.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Nov 2014 16:27:27 +0000
In-Reply-To: <1416505070.26869.2.camel@citrix.com>
References: <1416505070.26869.2.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 00/15] support for ARM32 arndale
 and cubietruck 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

On Thu, 2014-11-20 at 17:37 +0000, Ian Campbell wrote:
> The major blocker right now is that rerunning
> mg-debian-installer-update pulls in a newer kernel from backports.org
> which doesn't boot on the existing midway platform. I'm investigating
> that at the moment.

This investigation resulted in an upstream patch:
http://thread.gmane.org/gmane.linux.drivers.devicetree/100386
http://thread.gmane.org/gmane.linux.drivers.devicetree/100420

which I hope will go upstream shortly.

The underlying issue was a bogus size field in the header of the DT
which is burnt into these systems. When booting via the u-boot command
line this can be worked around with:
   fdt addr $fdt_addr
   fdt resize
which walks the FDT, recalculates the real size and updates the header.

Unfortunately there is no opportunity to do this when booting via PXE,
as we do for host install.

Given the lack of support from the, now-defunct, manufacture of these
systems I'm a bit reluctant to go poking around in the firmware to fixup
the embedded FDT in case I brick it.

I think the fix will go upstream shortly, then I can add it to the
Debian kernel, get it uploaded, wait for it to propagate into Jessie,
get it uploaded to bpo.

In principal I could build us a custom kernel deb to use here (it's
reasonably easy for me), but would you be happy with that? Perhaps
mg-update-debian-installer should be modified to look in some locally
constructed repo instead of at bpo? I'm wary of doing this, since it
just makes it harder for someone else to replicate things, plus it just
seems dodgy...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:54:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJNo-0005MY-5o; Tue, 25 Nov 2014 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 <Andrew.Cooper3@citrix.com>) id 1XtJNm-0005MT-QI
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:54:31 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	88/E4-22819-644B4745; Tue, 25 Nov 2014 16:54:30 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416934468!13285169!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12117 invoked from network); 25 Nov 2014 16:54:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:54:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196642767"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 11:54:10 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtJNR-0006JA-SX; Tue, 25 Nov 2014 16:54:09 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Tue, 25 Nov 2014 16:54:09 +0000
Message-ID: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally crash
	guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

A failed vmentry is overwhelmingly likely to be caused by corrupt VMC[SB]
state.  As a result, injecting a fault and retrying the the vmentry is likely
to fail in the same way.

With this new logic, a guest will unconditionally be crashed if it has
suffered two repeated vmentry failures, even if it is in usermode.  This
prevents an infinite loop in Xen where attempting to injecting a #UD is not
sufficient to prevent the vmentry failure.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

This is RFC as there is still a niggle.  I tested this via a partial revert of
the XSA-110 fix but the result is quite chatty given a double VMCB dump and
domain crash.  However, I am not sure we want to make any vmentry failure
quite, as any vmentry failure constitues a Xen bug.

Konrad: A hypervisor infinite loop is quite bad, so I am requesting a release
ack for this in its eventual form.  An alternative would be to revert
28b4baacd5 wholesale, but most of it is good.
---
 xen/arch/x86/hvm/svm/svm.c     |   16 ++++++++++++----
 xen/arch/x86/hvm/vmx/vmx.c     |   19 +++++++++++++++----
 xen/include/asm-x86/hvm/vcpu.h |    3 +++
 3 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 9398690..c42ec6d 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -90,13 +90,17 @@ static bool_t amd_erratum383_found __read_mostly;
 static uint64_t osvw_length, osvw_status;
 static DEFINE_SPINLOCK(osvw_lock);
 
-/* Only crash the guest if the problem originates in kernel mode. */
+/*
+ * Only crash the guest if the problem originates in kernel mode, or we have
+ * had repeated vmentry failures.
+ */
 static void svm_crash_or_fault(struct vcpu *v)
 {
-    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
-        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
-    else
+    if ( (v->arch.hvm_vcpu.vmentry_failure_count > 1) ||
+         (vmcb_get_cpl(v->arch.hvm_svm.vmcb) == 0) )
         domain_crash(v->domain);
+    else
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
 }
 
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
@@ -2395,9 +2399,13 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 
     if ( unlikely(exit_reason == VMEXIT_INVALID) )
     {
+        v->arch.hvm_vcpu.vmentry_failure_count++;
+
         svm_vmcb_dump(__func__, vmcb);
         goto exit_and_crash;
     }
+    else
+        v->arch.hvm_vcpu.vmentry_failure_count = 0;
 
     perfc_incra(svmexits, exit_reason);
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2907afa..e50c8a3 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,16 +134,21 @@ static void vmx_vcpu_destroy(struct vcpu *v)
     passive_domain_destroy(v);
 }
 
-/* Only crash the guest if the problem originates in kernel mode. */
+/*
+ * Only crash the guest if the problem originates in kernel mode, or we have
+ * had repeated vmentry failures.
+ */
 static void vmx_crash_or_fault(struct vcpu *v)
 {
     struct segment_register ss;
 
     vmx_get_segment_register(v, x86_seg_ss, &ss);
-    if ( ss.attr.fields.dpl )
-        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
-    else
+
+    if ( (v->arch.hvm_vcpu.vmentry_failure_count > 1) ||
+         (ss.attr.fields.dpl == 0) )
         domain_crash(v->domain);
+    else
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
 }
 
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
@@ -2722,7 +2727,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
     }
 
     if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
+    {
+        v->arch.hvm_vcpu.vmentry_failure_count++;
+
         return vmx_failed_vmentry(exit_reason, regs);
+    }
+    else
+        v->arch.hvm_vcpu.vmentry_failure_count = 0;
 
     if ( v->arch.hvm_vmx.vmx_realmode )
     {
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..3a9d521 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -159,6 +159,9 @@ struct hvm_vcpu {
         struct arch_svm_struct svm;
     } u;
 
+    /* Number of repeated vmentry failures. */
+    unsigned int        vmentry_failure_count;
+
     struct tasklet      assert_evtchn_irq_tasklet;
 
     struct nestedvcpu   nvcpu;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 16:54:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 16:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJNo-0005MY-5o; Tue, 25 Nov 2014 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 <Andrew.Cooper3@citrix.com>) id 1XtJNm-0005MT-QI
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 16:54:31 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	88/E4-22819-644B4745; Tue, 25 Nov 2014 16:54:30 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416934468!13285169!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12117 invoked from network); 25 Nov 2014 16:54:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 16:54:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196642767"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 11:54:10 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtJNR-0006JA-SX; Tue, 25 Nov 2014 16:54:09 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Tue, 25 Nov 2014 16:54:09 +0000
Message-ID: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally crash
	guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

A failed vmentry is overwhelmingly likely to be caused by corrupt VMC[SB]
state.  As a result, injecting a fault and retrying the the vmentry is likely
to fail in the same way.

With this new logic, a guest will unconditionally be crashed if it has
suffered two repeated vmentry failures, even if it is in usermode.  This
prevents an infinite loop in Xen where attempting to injecting a #UD is not
sufficient to prevent the vmentry failure.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

This is RFC as there is still a niggle.  I tested this via a partial revert of
the XSA-110 fix but the result is quite chatty given a double VMCB dump and
domain crash.  However, I am not sure we want to make any vmentry failure
quite, as any vmentry failure constitues a Xen bug.

Konrad: A hypervisor infinite loop is quite bad, so I am requesting a release
ack for this in its eventual form.  An alternative would be to revert
28b4baacd5 wholesale, but most of it is good.
---
 xen/arch/x86/hvm/svm/svm.c     |   16 ++++++++++++----
 xen/arch/x86/hvm/vmx/vmx.c     |   19 +++++++++++++++----
 xen/include/asm-x86/hvm/vcpu.h |    3 +++
 3 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 9398690..c42ec6d 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -90,13 +90,17 @@ static bool_t amd_erratum383_found __read_mostly;
 static uint64_t osvw_length, osvw_status;
 static DEFINE_SPINLOCK(osvw_lock);
 
-/* Only crash the guest if the problem originates in kernel mode. */
+/*
+ * Only crash the guest if the problem originates in kernel mode, or we have
+ * had repeated vmentry failures.
+ */
 static void svm_crash_or_fault(struct vcpu *v)
 {
-    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
-        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
-    else
+    if ( (v->arch.hvm_vcpu.vmentry_failure_count > 1) ||
+         (vmcb_get_cpl(v->arch.hvm_svm.vmcb) == 0) )
         domain_crash(v->domain);
+    else
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
 }
 
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
@@ -2395,9 +2399,13 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 
     if ( unlikely(exit_reason == VMEXIT_INVALID) )
     {
+        v->arch.hvm_vcpu.vmentry_failure_count++;
+
         svm_vmcb_dump(__func__, vmcb);
         goto exit_and_crash;
     }
+    else
+        v->arch.hvm_vcpu.vmentry_failure_count = 0;
 
     perfc_incra(svmexits, exit_reason);
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2907afa..e50c8a3 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,16 +134,21 @@ static void vmx_vcpu_destroy(struct vcpu *v)
     passive_domain_destroy(v);
 }
 
-/* Only crash the guest if the problem originates in kernel mode. */
+/*
+ * Only crash the guest if the problem originates in kernel mode, or we have
+ * had repeated vmentry failures.
+ */
 static void vmx_crash_or_fault(struct vcpu *v)
 {
     struct segment_register ss;
 
     vmx_get_segment_register(v, x86_seg_ss, &ss);
-    if ( ss.attr.fields.dpl )
-        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
-    else
+
+    if ( (v->arch.hvm_vcpu.vmentry_failure_count > 1) ||
+         (ss.attr.fields.dpl == 0) )
         domain_crash(v->domain);
+    else
+        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
 }
 
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
@@ -2722,7 +2727,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
     }
 
     if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
+    {
+        v->arch.hvm_vcpu.vmentry_failure_count++;
+
         return vmx_failed_vmentry(exit_reason, regs);
+    }
+    else
+        v->arch.hvm_vcpu.vmentry_failure_count = 0;
 
     if ( v->arch.hvm_vmx.vmx_realmode )
     {
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..3a9d521 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -159,6 +159,9 @@ struct hvm_vcpu {
         struct arch_svm_struct svm;
     } u;
 
+    /* Number of repeated vmentry failures. */
+    unsigned int        vmentry_failure_count;
+
     struct tasklet      assert_evtchn_irq_tasklet;
 
     struct nestedvcpu   nvcpu;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:01:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJTv-0005Wn-16; Tue, 25 Nov 2014 17:00:51 +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 1XtJTt-0005Wi-3D
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 17:00:49 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	69/93-02697-0C5B4745; Tue, 25 Nov 2014 17:00:48 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416934846!13349049!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24651 invoked from network); 25 Nov 2014 17:00:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 17:00:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196645253"
Message-ID: <5474B547.6000200@citrix.com>
Date: Tue, 25 Nov 2014 16:58:47 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel <xen-devel@lists.xen.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/11/14 16:54, Andrew Cooper wrote:
> A failed vmentry is overwhelmingly likely to be caused by corrupt VMC[SB]
> state.  As a result, injecting a fault and retrying the the vmentry is likely
> to fail in the same way.
>
> With this new logic, a guest will unconditionally be crashed if it has
> suffered two repeated vmentry failures, even if it is in usermode.  This
> prevents an infinite loop in Xen where attempting to injecting a #UD is not
> sufficient to prevent the vmentry failure.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Tim Deegan <tim@xen.org>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> ---
>
> This is RFC as there is still a niggle.  I tested this via a partial revert of
> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
> domain crash.  However, I am not sure we want to make any vmentry failure
> quite, as any vmentry failure constitues a Xen bug.

Furthermore, my testing proves that the attempt to inject a #UD fault
does not rectify the vmentry failure caused by bad CS attributes (in
this case, L and D).

~Andrew

>
> Konrad: A hypervisor infinite loop is quite bad, so I am requesting a release
> ack for this in its eventual form.  An alternative would be to revert
> 28b4baacd5 wholesale, but most of it is good.
> ---
>  xen/arch/x86/hvm/svm/svm.c     |   16 ++++++++++++----
>  xen/arch/x86/hvm/vmx/vmx.c     |   19 +++++++++++++++----
>  xen/include/asm-x86/hvm/vcpu.h |    3 +++
>  3 files changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 9398690..c42ec6d 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -90,13 +90,17 @@ static bool_t amd_erratum383_found __read_mostly;
>  static uint64_t osvw_length, osvw_status;
>  static DEFINE_SPINLOCK(osvw_lock);
>  
> -/* Only crash the guest if the problem originates in kernel mode. */
> +/*
> + * Only crash the guest if the problem originates in kernel mode, or we have
> + * had repeated vmentry failures.
> + */
>  static void svm_crash_or_fault(struct vcpu *v)
>  {
> -    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
> -        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> -    else
> +    if ( (v->arch.hvm_vcpu.vmentry_failure_count > 1) ||
> +         (vmcb_get_cpl(v->arch.hvm_svm.vmcb) == 0) )
>          domain_crash(v->domain);
> +    else
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
>  }
>  
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
> @@ -2395,9 +2399,13 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>  
>      if ( unlikely(exit_reason == VMEXIT_INVALID) )
>      {
> +        v->arch.hvm_vcpu.vmentry_failure_count++;
> +
>          svm_vmcb_dump(__func__, vmcb);
>          goto exit_and_crash;
>      }
> +    else
> +        v->arch.hvm_vcpu.vmentry_failure_count = 0;
>  
>      perfc_incra(svmexits, exit_reason);
>  
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 2907afa..e50c8a3 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -134,16 +134,21 @@ static void vmx_vcpu_destroy(struct vcpu *v)
>      passive_domain_destroy(v);
>  }
>  
> -/* Only crash the guest if the problem originates in kernel mode. */
> +/*
> + * Only crash the guest if the problem originates in kernel mode, or we have
> + * had repeated vmentry failures.
> + */
>  static void vmx_crash_or_fault(struct vcpu *v)
>  {
>      struct segment_register ss;
>  
>      vmx_get_segment_register(v, x86_seg_ss, &ss);
> -    if ( ss.attr.fields.dpl )
> -        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> -    else
> +
> +    if ( (v->arch.hvm_vcpu.vmentry_failure_count > 1) ||
> +         (ss.attr.fields.dpl == 0) )
>          domain_crash(v->domain);
> +    else
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
>  }
>  
>  static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
> @@ -2722,7 +2727,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>      }
>  
>      if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
> +    {
> +        v->arch.hvm_vcpu.vmentry_failure_count++;
> +
>          return vmx_failed_vmentry(exit_reason, regs);
> +    }
> +    else
> +        v->arch.hvm_vcpu.vmentry_failure_count = 0;
>  
>      if ( v->arch.hvm_vmx.vmx_realmode )
>      {
> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
> index 01e0665..3a9d521 100644
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -159,6 +159,9 @@ struct hvm_vcpu {
>          struct arch_svm_struct svm;
>      } u;
>  
> +    /* Number of repeated vmentry failures. */
> +    unsigned int        vmentry_failure_count;
> +
>      struct tasklet      assert_evtchn_irq_tasklet;
>  
>      struct nestedvcpu   nvcpu;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:01:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJTv-0005Wn-16; Tue, 25 Nov 2014 17:00:51 +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 1XtJTt-0005Wi-3D
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 17:00:49 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	69/93-02697-0C5B4745; Tue, 25 Nov 2014 17:00:48 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416934846!13349049!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24651 invoked from network); 25 Nov 2014 17:00:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 17:00:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196645253"
Message-ID: <5474B547.6000200@citrix.com>
Date: Tue, 25 Nov 2014 16:58:47 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel <xen-devel@lists.xen.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/11/14 16:54, Andrew Cooper wrote:
> A failed vmentry is overwhelmingly likely to be caused by corrupt VMC[SB]
> state.  As a result, injecting a fault and retrying the the vmentry is likely
> to fail in the same way.
>
> With this new logic, a guest will unconditionally be crashed if it has
> suffered two repeated vmentry failures, even if it is in usermode.  This
> prevents an infinite loop in Xen where attempting to injecting a #UD is not
> sufficient to prevent the vmentry failure.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Tim Deegan <tim@xen.org>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> ---
>
> This is RFC as there is still a niggle.  I tested this via a partial revert of
> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
> domain crash.  However, I am not sure we want to make any vmentry failure
> quite, as any vmentry failure constitues a Xen bug.

Furthermore, my testing proves that the attempt to inject a #UD fault
does not rectify the vmentry failure caused by bad CS attributes (in
this case, L and D).

~Andrew

>
> Konrad: A hypervisor infinite loop is quite bad, so I am requesting a release
> ack for this in its eventual form.  An alternative would be to revert
> 28b4baacd5 wholesale, but most of it is good.
> ---
>  xen/arch/x86/hvm/svm/svm.c     |   16 ++++++++++++----
>  xen/arch/x86/hvm/vmx/vmx.c     |   19 +++++++++++++++----
>  xen/include/asm-x86/hvm/vcpu.h |    3 +++
>  3 files changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 9398690..c42ec6d 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -90,13 +90,17 @@ static bool_t amd_erratum383_found __read_mostly;
>  static uint64_t osvw_length, osvw_status;
>  static DEFINE_SPINLOCK(osvw_lock);
>  
> -/* Only crash the guest if the problem originates in kernel mode. */
> +/*
> + * Only crash the guest if the problem originates in kernel mode, or we have
> + * had repeated vmentry failures.
> + */
>  static void svm_crash_or_fault(struct vcpu *v)
>  {
> -    if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
> -        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> -    else
> +    if ( (v->arch.hvm_vcpu.vmentry_failure_count > 1) ||
> +         (vmcb_get_cpl(v->arch.hvm_svm.vmcb) == 0) )
>          domain_crash(v->domain);
> +    else
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
>  }
>  
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
> @@ -2395,9 +2399,13 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>  
>      if ( unlikely(exit_reason == VMEXIT_INVALID) )
>      {
> +        v->arch.hvm_vcpu.vmentry_failure_count++;
> +
>          svm_vmcb_dump(__func__, vmcb);
>          goto exit_and_crash;
>      }
> +    else
> +        v->arch.hvm_vcpu.vmentry_failure_count = 0;
>  
>      perfc_incra(svmexits, exit_reason);
>  
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 2907afa..e50c8a3 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -134,16 +134,21 @@ static void vmx_vcpu_destroy(struct vcpu *v)
>      passive_domain_destroy(v);
>  }
>  
> -/* Only crash the guest if the problem originates in kernel mode. */
> +/*
> + * Only crash the guest if the problem originates in kernel mode, or we have
> + * had repeated vmentry failures.
> + */
>  static void vmx_crash_or_fault(struct vcpu *v)
>  {
>      struct segment_register ss;
>  
>      vmx_get_segment_register(v, x86_seg_ss, &ss);
> -    if ( ss.attr.fields.dpl )
> -        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> -    else
> +
> +    if ( (v->arch.hvm_vcpu.vmentry_failure_count > 1) ||
> +         (ss.attr.fields.dpl == 0) )
>          domain_crash(v->domain);
> +    else
> +        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
>  }
>  
>  static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
> @@ -2722,7 +2727,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>      }
>  
>      if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
> +    {
> +        v->arch.hvm_vcpu.vmentry_failure_count++;
> +
>          return vmx_failed_vmentry(exit_reason, regs);
> +    }
> +    else
> +        v->arch.hvm_vcpu.vmentry_failure_count = 0;
>  
>      if ( v->arch.hvm_vmx.vmx_realmode )
>      {
> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
> index 01e0665..3a9d521 100644
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -159,6 +159,9 @@ struct hvm_vcpu {
>          struct arch_svm_struct svm;
>      } u;
>  
> +    /* Number of repeated vmentry failures. */
> +    unsigned int        vmentry_failure_count;
> +
>      struct tasklet      assert_evtchn_irq_tasklet;
>  
>      struct nestedvcpu   nvcpu;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:01:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:01:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJUV-0005Z2-DY; Tue, 25 Nov 2014 17:01:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtJUU-0005Yu-G5
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 17:01:26 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AE/C9-25276-5E5B4745; Tue, 25 Nov 2014 17:01:25 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416934885!15284172!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25523 invoked from network); 25 Nov 2014 17:01:25 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 17:01:25 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 08FC9AE05;
	Tue, 25 Nov 2014 17:01:25 +0000 (UTC)
Message-ID: <5474B5E4.9000908@suse.com>
Date: Tue, 25 Nov 2014 18:01:24 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546EFAE3.80404@suse.com>	
	<20141121135747.GB2886@laptop.dumpdata.com>
	<5473008C.4080604@suse.com> <1416823327.26329.25.camel@citrix.com>
In-Reply-To: <1416823327.26329.25.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 11:02 AM, Ian Campbell wrote:
> On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
>> On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
>>>> Hi,
>>>>
>>>> while testing my "linear p2m list" patches I saw the following
>>>> problem (even without my patches in place):
>>>>
>>>> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
>>>> disk image of a guest by attaching it to dom0:
>>>>
>>>> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
>>>> mount /dev/xvda2 /mnt
>>>> ...
>>>> umount /mnt
>>>> xl block-detach 0 xvda
>>
>> Did some more testing:
>> - Seems to occur only when attaching a block device to dom0
>
> That means a qdisk backed situation then, I think.
>
> Is your qemu up to date?
>
> http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=commit;h=abbbc2f09a53f8f9ee565356ab11a78af006e45e resulted in slightly different messages, but could be related?

Newest qemu and xen-unstable together with my dom0 kernel patch made
all issues go away at a first glance.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:01:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:01:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJUV-0005Z2-DY; Tue, 25 Nov 2014 17:01:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtJUU-0005Yu-G5
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 17:01:26 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AE/C9-25276-5E5B4745; Tue, 25 Nov 2014 17:01:25 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1416934885!15284172!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25523 invoked from network); 25 Nov 2014 17:01:25 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 17:01:25 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 08FC9AE05;
	Tue, 25 Nov 2014 17:01:25 +0000 (UTC)
Message-ID: <5474B5E4.9000908@suse.com>
Date: Tue, 25 Nov 2014 18:01:24 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546EFAE3.80404@suse.com>	
	<20141121135747.GB2886@laptop.dumpdata.com>
	<5473008C.4080604@suse.com> <1416823327.26329.25.camel@citrix.com>
In-Reply-To: <1416823327.26329.25.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Hypervisor error messages after xl block-detach
 with linux 3.18-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/24/2014 11:02 AM, Ian Campbell wrote:
> On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
>> On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
>>>> Hi,
>>>>
>>>> while testing my "linear p2m list" patches I saw the following
>>>> problem (even without my patches in place):
>>>>
>>>> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
>>>> disk image of a guest by attaching it to dom0:
>>>>
>>>> xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
>>>> mount /dev/xvda2 /mnt
>>>> ...
>>>> umount /mnt
>>>> xl block-detach 0 xvda
>>
>> Did some more testing:
>> - Seems to occur only when attaching a block device to dom0
>
> That means a qdisk backed situation then, I think.
>
> Is your qemu up to date?
>
> http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=commit;h=abbbc2f09a53f8f9ee565356ab11a78af006e45e resulted in slightly different messages, but could be related?

Newest qemu and xen-unstable together with my dom0 kernel patch made
all issues go away at a first glance.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:06:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17: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.xen.org>)
	id 1XtJZ2-0005rx-46; Tue, 25 Nov 2014 17:06:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtJZ0-0005rp-VD
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 17:06:07 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	F3/73-02712-EF6B4745; Tue, 25 Nov 2014 17:06:06 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416935163!14783202!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11429 invoked from network); 25 Nov 2014 17:06:05 -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;
	25 Nov 2014 17:06:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196649654"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 12:05:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtJYW-00079V-73;
	Tue, 25 Nov 2014 17:05:36 +0000
Date: Tue, 25 Nov 2014 17:05:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416934562.11944.22.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Ian Campbell wrote:
> On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > each them. Assume 256K each.
> > > 
> > > I suppose this will have to do for 4.5. Can we do something better in
> > > the future -- like figuring out a way for guests to have
> > > "not-really-RAM" allocations like this which are made by the toolstack
> > > and happen to be backed by RAM not count or something.
> > > 
> > > > 
> > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > assigned to a VM.
> > > 
> > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > option roms? abort() seems a bit extreme.
> > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > CC: Don Slutz <dslutz@verizon.com>
> > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > 
> > > You missed Ian J. I've added him.
> > 
> > Actually Wei suggested a better alternative: I could call
> > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> 
> xl mem-set would do it again, but not taking qemu's extras into account,
> unless you communicate the overhead somehow...

We could start reading the current maxmem and add to it in
libxl_set_memory_target. Or we could write the maxmem to xenstore and
read it back again.  Given that the allocations are only done by QEMU at
initialization time, I don't think we need to worry about concurrency
here.


> > 
> > > > 
> > > > ---
> > > > 
> > > > Changes in v2:
> > > > - remove double return statement;
> > > > - check for return errors;
> > > > - check for overflows.
> > > > ---
> > > >  tools/libxl/libxl.c          |   53 +++++++++++++++++++++++++++++++++++++-----
> > > >  tools/libxl/libxl_dom.c      |    8 +++++--
> > > >  tools/libxl/libxl_internal.h |    7 ++++++
> > > >  3 files changed, 60 insertions(+), 8 deletions(-)
> > > > 
> > > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > > index de23fec..2cdb768 100644
> > > > --- a/tools/libxl/libxl.c
> > > > +++ b/tools/libxl/libxl.c
> > > > @@ -4527,13 +4527,40 @@ out:
> > > >  
> > > >  /******************************************************************************/
> > > >  
> > > > +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> > > > +{
> > > > +    int i, romsize, rc;
> > > > +    libxl_domain_config local_d_config;
> > > > +    libxl_ctx *ctx = libxl__gc_owner(gc);
> > > > +
> > > > +    if (d_config == NULL) {
> > > > +        libxl_domain_config_init(&local_d_config);
> > > > +        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
> > > > +        if (rc < 0)
> > > > +            return rc;
> > > > +        d_config = &local_d_config;
> > > > +    }
> > > 
> > > Perhaps we could store the answer to this function in XS when we build
> > > the domain and simply read it back and account for it in the places
> > > which use it?
> > > 
> > > Apart from being rather costly reparsing the json every time is going to
> > > behave a bit strangely if NICs are plugged/unplugged at runtime and
> > > ballooning is going on.
> > > 
> > > > +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> > > > +        return 0;
> > > > +
> > > > +    for (i = 0, romsize = 0;
> > > > +         i < d_config->num_nics && romsize < INT_MAX;
> > > 
> > > I don't think that romsize < INT_MAX is useful except in the case that
> > > romsize+= results in romsize == INT_MAX. If you actually overflow then
> > > romsize becomes negative which satisfies the condition (and in any case
> > > you are into undefined behaviour territory there anyhow, I think).
> > > 
> > > Given that INT_MAX is a boat load of ROMs I'd be inclined to just limit
> > > it to INT_MAX/2 or /4 or something.
> > > 
> > > Or you could do romsize < (INT_MAX - LIBXL_ROMSIZE_KB) I suppose.
> > > 
> > > > +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> > > > +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> > > > +                             + romsize);
> > > 
> > > Seems like we ought to have a helper to return the memory overheads,
> > > which would be the constant + the romsize starting from 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 Nov 25 17:06:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17: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.xen.org>)
	id 1XtJZ2-0005rx-46; Tue, 25 Nov 2014 17:06:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtJZ0-0005rp-VD
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 17:06:07 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	F3/73-02712-EF6B4745; Tue, 25 Nov 2014 17:06:06 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1416935163!14783202!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11429 invoked from network); 25 Nov 2014 17:06:05 -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;
	25 Nov 2014 17:06:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196649654"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 12:05:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtJYW-00079V-73;
	Tue, 25 Nov 2014 17:05:36 +0000
Date: Tue, 25 Nov 2014 17:05:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416934562.11944.22.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Ian Campbell wrote:
> On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > each them. Assume 256K each.
> > > 
> > > I suppose this will have to do for 4.5. Can we do something better in
> > > the future -- like figuring out a way for guests to have
> > > "not-really-RAM" allocations like this which are made by the toolstack
> > > and happen to be backed by RAM not count or something.
> > > 
> > > > 
> > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > assigned to a VM.
> > > 
> > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > option roms? abort() seems a bit extreme.
> > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > CC: Don Slutz <dslutz@verizon.com>
> > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > 
> > > You missed Ian J. I've added him.
> > 
> > Actually Wei suggested a better alternative: I could call
> > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> 
> xl mem-set would do it again, but not taking qemu's extras into account,
> unless you communicate the overhead somehow...

We could start reading the current maxmem and add to it in
libxl_set_memory_target. Or we could write the maxmem to xenstore and
read it back again.  Given that the allocations are only done by QEMU at
initialization time, I don't think we need to worry about concurrency
here.


> > 
> > > > 
> > > > ---
> > > > 
> > > > Changes in v2:
> > > > - remove double return statement;
> > > > - check for return errors;
> > > > - check for overflows.
> > > > ---
> > > >  tools/libxl/libxl.c          |   53 +++++++++++++++++++++++++++++++++++++-----
> > > >  tools/libxl/libxl_dom.c      |    8 +++++--
> > > >  tools/libxl/libxl_internal.h |    7 ++++++
> > > >  3 files changed, 60 insertions(+), 8 deletions(-)
> > > > 
> > > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > > index de23fec..2cdb768 100644
> > > > --- a/tools/libxl/libxl.c
> > > > +++ b/tools/libxl/libxl.c
> > > > @@ -4527,13 +4527,40 @@ out:
> > > >  
> > > >  /******************************************************************************/
> > > >  
> > > > +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> > > > +{
> > > > +    int i, romsize, rc;
> > > > +    libxl_domain_config local_d_config;
> > > > +    libxl_ctx *ctx = libxl__gc_owner(gc);
> > > > +
> > > > +    if (d_config == NULL) {
> > > > +        libxl_domain_config_init(&local_d_config);
> > > > +        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
> > > > +        if (rc < 0)
> > > > +            return rc;
> > > > +        d_config = &local_d_config;
> > > > +    }
> > > 
> > > Perhaps we could store the answer to this function in XS when we build
> > > the domain and simply read it back and account for it in the places
> > > which use it?
> > > 
> > > Apart from being rather costly reparsing the json every time is going to
> > > behave a bit strangely if NICs are plugged/unplugged at runtime and
> > > ballooning is going on.
> > > 
> > > > +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> > > > +        return 0;
> > > > +
> > > > +    for (i = 0, romsize = 0;
> > > > +         i < d_config->num_nics && romsize < INT_MAX;
> > > 
> > > I don't think that romsize < INT_MAX is useful except in the case that
> > > romsize+= results in romsize == INT_MAX. If you actually overflow then
> > > romsize becomes negative which satisfies the condition (and in any case
> > > you are into undefined behaviour territory there anyhow, I think).
> > > 
> > > Given that INT_MAX is a boat load of ROMs I'd be inclined to just limit
> > > it to INT_MAX/2 or /4 or something.
> > > 
> > > Or you could do romsize < (INT_MAX - LIBXL_ROMSIZE_KB) I suppose.
> > > 
> > > > +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> > > > +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> > > > +                             + romsize);
> > > 
> > > Seems like we ought to have a helper to return the memory overheads,
> > > which would be the constant + the romsize starting from 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 Nov 25 17:11:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJdx-0005zz-Rv; Tue, 25 Nov 2014 17:11:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1XtJdw-0005zu-9V
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 17:11:12 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	FA/6C-14214-F28B4745; Tue, 25 Nov 2014 17:11:11 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416935468!13301549!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31921 invoked from network); 25 Nov 2014 17:11:10 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 17:11:10 -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 sAPHB2SZ005169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 25 Nov 2014 12:11:02 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAPHAwHB003748
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 12:10:59 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: "Jan Beulich" <JBeulich@suse.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	<1412687413-22818-4-git-send-email-vkuznets@redhat.com>
	<5474A568020000780004AB93@mail.emea.novell.com>
	<5474A568020000780004AB93@mail.emea.novell.com>
	<8761e35lui.fsf@vitty.brq.redhat.com>
	<5474BD3C020000780004AC91@mail.emea.novell.com>
Date: Tue, 25 Nov 2014 18:10:57 +0100
In-Reply-To: <5474BD3C020000780004AC91@mail.emea.novell.com> (Jan Beulich's
	message of "Tue, 25 Nov 2014 16:32:44 +0000")
Message-ID: <87h9xn19zy.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 3/8] xen: introduce
	XEN_DOMCTL_set_recipient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Jan Beulich" <JBeulich@suse.com> writes:

>>>> On 25.11.14 at 16:41, <vkuznets@redhat.com> wrote:
>> "Jan Beulich" <JBeulich@suse.com> writes:
>>>>>> On 07.10.14 at 15:10, <vkuznets@redhat.com> wrote:
>>>> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>>>>              scrub = 1;
>>>>          }
>>>>  
>>>> -        if ( unlikely(scrub) )
>>>> -            for ( i = 0; i < (1 << order); i++ )
>>>> -                scrub_one_page(&pg[i]);
>>>> +        if ( !d || !d->recipient || d->recipient->is_dying )
>>>> +        {
>>>> +            if ( unlikely(scrub) )
>>>> +                for ( i = 0; i < (1 << order); i++ )
>>>> +                    scrub_one_page(&pg[i]);
>>>>  
>>>> -        free_heap_pages(pg, order);
>>>> +            free_heap_pages(pg, order);
>>>> +        }
>>>> +        else
>>>> +        {
>>>> +            mfn = page_to_mfn(pg);
>>>> +            gmfn = mfn_to_gmfn(d, mfn);
>>>> +
>>>> +            page_set_owner(pg, NULL);
>>>> +            assign_pages(d->recipient, pg, order, 0);
>>>
>>> This can fail.
>> 
>> .. if the recipient is dying or we're over-allocating. Shouldn't happen
>> (if toolstack does its job right) but I'll add a check.
>
> You must not rely on the tool stack doing things right (see XSA-77).
>
>>> What's worse though is that you don't guard against
>>> XEN_DOMCTL_set_recipient zapping d->recipient. If that really is
>>> necessary to be supported, some synchronization will be needed.
>>>
>>> And finally - what's the intended protocol for the tool stack to
>>> know that all pages got transferred (and hence the new domain
>>> can be launched)?
>>>
>> 
>> (hope this answers both questions above)
>> 
>> Now the protocol is:
>> 1) Toolstack queries for all page frames (with xc_get_pfn_type_batch())
>> for the old domain.
>> 2) Toolstack issues XEN_DOMCTL_set_recipient with the recipient domain
>> 3) Toolstack kills the source domain
>> 4) Toolstack waits for awhile (loop keeps checking while we see new pages
>> arriving + some timeout).
>> 5) Toolstack issues XEN_DOMCTL_set_recipient with DOMID_INVALID
>> resetting recipient.
>> 6) Toolstack checks if all pages were transferred
>> 7) If some pages are missing (e.g. source domain became zombie holding
>> something) request new empty pages instead.
>> 8) Toolstack starts new domain
>> 
>> So we don't actually need XEN_DOMCTL_set_recipient to switch from one
>> recipient to the other, we just need a way to reset it.
>
> No, this doesn't address either question. For the first one, you again
> assume the tool stack behaves correctly, which is wrong nowadays.
> And for the second you give a description, but that's not really a
> dependable protocol. Nor do I really follow why resetting the recipient
> is necessary. Can't the tools e.g. wait for the final death of the domain
> if there's no other notification?

Yes, it's possible and should happen in all normal cases. However my
idea was that it's possible to start new domain even if the old one
fails to die holding several (presumably special) pages and we're fine
with replacing those with empty pages. In case we go for 'always wait
for the original domain to die' solution resetting
XEN_DOMCTL_set_recipient is not necessary (it is necessary in case we
don't as we can recieve a page after we already requested a new one
instead).

>
>>>> --- a/xen/include/public/domctl.h
>>>> +++ b/xen/include/public/domctl.h
>>>> @@ -965,6 +965,23 @@ struct xen_domctl_vnuma {
>>>>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>>>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
>>>>  
>>>> +/*
>>>> + * XEN_DOMCTL_set_recipient - sets the 'recipient' domain which will recieve
>>>> + * all the domain's memory after its death or when and memory page from
>>>> + * domain's heap is being freed.
>>>
>>> So this specifically allows for this to happen on a non-dying domain.
>>> Why, i.e. what's the intended usage scenario? If not really needed,
>>> please remove this and verify in the handling that the source domain
>>> is dying.
>> 
>> Sorry if I didn't get this comment right. We need a way to tell which
>> domain will recieve memory and XEN_DOMCTL_set_recipient sets (and
>> resets) this target domain. We call it from toolstack before we start
>> killing old domain so it is not dying yet. We can't do it
>> hypervistor-side when our source domain exits doing SHUTDOWN_soft_reset
>> as there is no recipient domain created yet.
>> 
>> From a general (hypervisor) point of view we don't actually care if the
>> domain is dying or not. We just want to recieve all freed pages from
>> this domain (so they go to some other domain instead of trash).
>
> We do care I think, primarily because we want a correct GMFN <->
> MFN mapping. Seeing multiple pages for the same GMFN is for
> example going to cause the whole process in its current form to fail.

Can adding a check that nothing is mapped to the GMFN before mapping new
MFN there be a solution?

> And considering the need for such a correct mapping - is it always
> the case that the mapping gets updated after a page got removed
> from a guest? (I can see that the mapping doesn't change anymore
> for a dying guest, but you explicitly say that you want/need this to
> work before the guest is actually marked dying.)

Actual reassignment here happens for a dying guest only as
XEN_DOMCTL_set_recipient does nothing. If you think it's safer to depend
on the fact that dying flag is always set we can couple
XEN_DOMCTL_set_recipient with XEN_DOMCTL_destroydomain in one call. It
is possible if we go for 'always wait for the original domain to die'
solution (so no reset is required).

>
> Jan

-- 
  Vitaly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:11:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJdx-0005zz-Rv; Tue, 25 Nov 2014 17:11:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1XtJdw-0005zu-9V
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 17:11:12 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	FA/6C-14214-F28B4745; Tue, 25 Nov 2014 17:11:11 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416935468!13301549!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31921 invoked from network); 25 Nov 2014 17:11:10 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 17:11:10 -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 sAPHB2SZ005169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 25 Nov 2014 12:11:02 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAPHAwHB003748
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 12:10:59 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: "Jan Beulich" <JBeulich@suse.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	<1412687413-22818-4-git-send-email-vkuznets@redhat.com>
	<5474A568020000780004AB93@mail.emea.novell.com>
	<5474A568020000780004AB93@mail.emea.novell.com>
	<8761e35lui.fsf@vitty.brq.redhat.com>
	<5474BD3C020000780004AC91@mail.emea.novell.com>
Date: Tue, 25 Nov 2014 18:10:57 +0100
In-Reply-To: <5474BD3C020000780004AC91@mail.emea.novell.com> (Jan Beulich's
	message of "Tue, 25 Nov 2014 16:32:44 +0000")
Message-ID: <87h9xn19zy.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 3/8] xen: introduce
	XEN_DOMCTL_set_recipient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Jan Beulich" <JBeulich@suse.com> writes:

>>>> On 25.11.14 at 16:41, <vkuznets@redhat.com> wrote:
>> "Jan Beulich" <JBeulich@suse.com> writes:
>>>>>> On 07.10.14 at 15:10, <vkuznets@redhat.com> wrote:
>>>> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>>>>              scrub = 1;
>>>>          }
>>>>  
>>>> -        if ( unlikely(scrub) )
>>>> -            for ( i = 0; i < (1 << order); i++ )
>>>> -                scrub_one_page(&pg[i]);
>>>> +        if ( !d || !d->recipient || d->recipient->is_dying )
>>>> +        {
>>>> +            if ( unlikely(scrub) )
>>>> +                for ( i = 0; i < (1 << order); i++ )
>>>> +                    scrub_one_page(&pg[i]);
>>>>  
>>>> -        free_heap_pages(pg, order);
>>>> +            free_heap_pages(pg, order);
>>>> +        }
>>>> +        else
>>>> +        {
>>>> +            mfn = page_to_mfn(pg);
>>>> +            gmfn = mfn_to_gmfn(d, mfn);
>>>> +
>>>> +            page_set_owner(pg, NULL);
>>>> +            assign_pages(d->recipient, pg, order, 0);
>>>
>>> This can fail.
>> 
>> .. if the recipient is dying or we're over-allocating. Shouldn't happen
>> (if toolstack does its job right) but I'll add a check.
>
> You must not rely on the tool stack doing things right (see XSA-77).
>
>>> What's worse though is that you don't guard against
>>> XEN_DOMCTL_set_recipient zapping d->recipient. If that really is
>>> necessary to be supported, some synchronization will be needed.
>>>
>>> And finally - what's the intended protocol for the tool stack to
>>> know that all pages got transferred (and hence the new domain
>>> can be launched)?
>>>
>> 
>> (hope this answers both questions above)
>> 
>> Now the protocol is:
>> 1) Toolstack queries for all page frames (with xc_get_pfn_type_batch())
>> for the old domain.
>> 2) Toolstack issues XEN_DOMCTL_set_recipient with the recipient domain
>> 3) Toolstack kills the source domain
>> 4) Toolstack waits for awhile (loop keeps checking while we see new pages
>> arriving + some timeout).
>> 5) Toolstack issues XEN_DOMCTL_set_recipient with DOMID_INVALID
>> resetting recipient.
>> 6) Toolstack checks if all pages were transferred
>> 7) If some pages are missing (e.g. source domain became zombie holding
>> something) request new empty pages instead.
>> 8) Toolstack starts new domain
>> 
>> So we don't actually need XEN_DOMCTL_set_recipient to switch from one
>> recipient to the other, we just need a way to reset it.
>
> No, this doesn't address either question. For the first one, you again
> assume the tool stack behaves correctly, which is wrong nowadays.
> And for the second you give a description, but that's not really a
> dependable protocol. Nor do I really follow why resetting the recipient
> is necessary. Can't the tools e.g. wait for the final death of the domain
> if there's no other notification?

Yes, it's possible and should happen in all normal cases. However my
idea was that it's possible to start new domain even if the old one
fails to die holding several (presumably special) pages and we're fine
with replacing those with empty pages. In case we go for 'always wait
for the original domain to die' solution resetting
XEN_DOMCTL_set_recipient is not necessary (it is necessary in case we
don't as we can recieve a page after we already requested a new one
instead).

>
>>>> --- a/xen/include/public/domctl.h
>>>> +++ b/xen/include/public/domctl.h
>>>> @@ -965,6 +965,23 @@ struct xen_domctl_vnuma {
>>>>  typedef struct xen_domctl_vnuma xen_domctl_vnuma_t;
>>>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vnuma_t);
>>>>  
>>>> +/*
>>>> + * XEN_DOMCTL_set_recipient - sets the 'recipient' domain which will recieve
>>>> + * all the domain's memory after its death or when and memory page from
>>>> + * domain's heap is being freed.
>>>
>>> So this specifically allows for this to happen on a non-dying domain.
>>> Why, i.e. what's the intended usage scenario? If not really needed,
>>> please remove this and verify in the handling that the source domain
>>> is dying.
>> 
>> Sorry if I didn't get this comment right. We need a way to tell which
>> domain will recieve memory and XEN_DOMCTL_set_recipient sets (and
>> resets) this target domain. We call it from toolstack before we start
>> killing old domain so it is not dying yet. We can't do it
>> hypervistor-side when our source domain exits doing SHUTDOWN_soft_reset
>> as there is no recipient domain created yet.
>> 
>> From a general (hypervisor) point of view we don't actually care if the
>> domain is dying or not. We just want to recieve all freed pages from
>> this domain (so they go to some other domain instead of trash).
>
> We do care I think, primarily because we want a correct GMFN <->
> MFN mapping. Seeing multiple pages for the same GMFN is for
> example going to cause the whole process in its current form to fail.

Can adding a check that nothing is mapped to the GMFN before mapping new
MFN there be a solution?

> And considering the need for such a correct mapping - is it always
> the case that the mapping gets updated after a page got removed
> from a guest? (I can see that the mapping doesn't change anymore
> for a dying guest, but you explicitly say that you want/need this to
> work before the guest is actually marked dying.)

Actual reassignment here happens for a dying guest only as
XEN_DOMCTL_set_recipient does nothing. If you think it's safer to depend
on the fact that dying flag is always set we can couple
XEN_DOMCTL_set_recipient with XEN_DOMCTL_destroydomain in one call. It
is possible if we go for 'always wait for the original domain to die'
solution (so no reset is required).

>
> Jan

-- 
  Vitaly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:14:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJhC-0006E3-Kh; Tue, 25 Nov 2014 17:14:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtJhA-0006Du-Te
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 17:14:33 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	B0/97-02697-8F8B4745; Tue, 25 Nov 2014 17:14:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416935670!13331499!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12812 invoked from network); 25 Nov 2014 17:14:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 17:14:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196651788"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 12:09:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtJc5-0007ML-9a;
	Tue, 25 Nov 2014 17:09:17 +0000
Date: Tue, 25 Nov 2014 17:09:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Message-ID: <20141125170917.GC2893@zion.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
	<5474A020.40103@m2r.biz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5474A020.40103@m2r.biz>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, wei Liu <wei.liu2@citrix.com>,
	wency@cn.fujitsu.com, mst@redhat.com, jasowang@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, pbonzini@redhat.com
Subject: Re: [Xen-devel] [PATCH 0/4] virtio-net: do not leak cpu mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 04:28:32PM +0100, Fabio Fantoni wrote:
> Il 25/11/2014 15:42, Stefano Stabellini ha scritto:
> >Hi all,
> >this patch series fixes a cpu mapping leak in virtio-net.
> >
> >The bug is caused by virtio_net_handle_ctrl: it maps the entire out_sg
> >iov, but then modifies it and reduces it (iov_discard_front), and only
> >unmap the reduced version of the iov.
> >
> >This causes a crash when running on Xen, but the behaviour is obviously
> >incorrect without Xen too.
> >
> >The patch series fixes the issue by allowing virtio_net_handle_ctrl to
> >unmap the original out_sg iov but still call virtqueue_fill and
> >virtqueue_flush on the modified iov.
> >
> >The first three patches do not introduce any functional changes.
> 
> Thanks for these pathes, 1-2 years ago I tried to use virtio net and disks
> on xen unsuccessful and I was unable to solve it.
> When I'll have time I'll retry.
> About virtio disks can have problem similar to this or should be ok?
> About the other patches posted in link below are all not applied and should
> be only rebased or they must be fully revisioned/modified?
> http://wiki.xen.org/wiki/Virtio_On_Xen
> 

Don't use patches on that page. They are outdated.

I think Stefano's patch series intends to fix issue for HVM guest, which
might well be what you're using.  Well, I would be very surprised if you
tell me you're using PV virtio! ;-)

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:14:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJhC-0006E3-Kh; Tue, 25 Nov 2014 17:14:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtJhA-0006Du-Te
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 17:14:33 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	B0/97-02697-8F8B4745; Tue, 25 Nov 2014 17:14:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1416935670!13331499!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12812 invoked from network); 25 Nov 2014 17:14:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 17:14:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196651788"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 12:09:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtJc5-0007ML-9a;
	Tue, 25 Nov 2014 17:09:17 +0000
Date: Tue, 25 Nov 2014 17:09:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Message-ID: <20141125170917.GC2893@zion.uk.xensource.com>
References: <alpine.DEB.2.02.1411251436080.2675@kaball.uk.xensource.com>
	<5474A020.40103@m2r.biz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5474A020.40103@m2r.biz>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, wei Liu <wei.liu2@citrix.com>,
	wency@cn.fujitsu.com, mst@redhat.com, jasowang@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, pbonzini@redhat.com
Subject: Re: [Xen-devel] [PATCH 0/4] virtio-net: do not leak cpu mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 04:28:32PM +0100, Fabio Fantoni wrote:
> Il 25/11/2014 15:42, Stefano Stabellini ha scritto:
> >Hi all,
> >this patch series fixes a cpu mapping leak in virtio-net.
> >
> >The bug is caused by virtio_net_handle_ctrl: it maps the entire out_sg
> >iov, but then modifies it and reduces it (iov_discard_front), and only
> >unmap the reduced version of the iov.
> >
> >This causes a crash when running on Xen, but the behaviour is obviously
> >incorrect without Xen too.
> >
> >The patch series fixes the issue by allowing virtio_net_handle_ctrl to
> >unmap the original out_sg iov but still call virtqueue_fill and
> >virtqueue_flush on the modified iov.
> >
> >The first three patches do not introduce any functional changes.
> 
> Thanks for these pathes, 1-2 years ago I tried to use virtio net and disks
> on xen unsuccessful and I was unable to solve it.
> When I'll have time I'll retry.
> About virtio disks can have problem similar to this or should be ok?
> About the other patches posted in link below are all not applied and should
> be only rebased or they must be fully revisioned/modified?
> http://wiki.xen.org/wiki/Virtio_On_Xen
> 

Don't use patches on that page. They are outdated.

I think Stefano's patch series intends to fix issue for HVM guest, which
might well be what you're using.  Well, I would be very surprised if you
tell me you're using PV virtio! ;-)

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:21:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17: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 1XtJnT-0006Ne-H6; Tue, 25 Nov 2014 17:21:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtJnR-0006NZ-M8
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 17:21:01 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	74/06-20609-D7AB4745; Tue, 25 Nov 2014 17:21:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416936059!14809990!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1877 invoked from network); 25 Nov 2014 17:21:00 -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;
	25 Nov 2014 17:21:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196267577"
Message-ID: <1416934562.11944.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 25 Nov 2014 16:56:02 +0000
In-Reply-To: <alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> On Tue, 25 Nov 2014, Ian Campbell wrote:
> > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > Account for the extra memory needed for the rom files of any emulated nics:
> > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > each them. Assume 256K each.
> > 
> > I suppose this will have to do for 4.5. Can we do something better in
> > the future -- like figuring out a way for guests to have
> > "not-really-RAM" allocations like this which are made by the toolstack
> > and happen to be backed by RAM not count or something.
> > 
> > > 
> > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > assigned to a VM.
> > 
> > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > option roms? abort() seems a bit extreme.
> > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > CC: Don Slutz <dslutz@verizon.com>
> > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > CC: Wei Liu <wei.liu2@citrix.com>
> > 
> > You missed Ian J. I've added him.
> 
> Actually Wei suggested a better alternative: I could call
> xc_domain_setmaxmem directly from QEMU. That makes much more sense.

xl mem-set would do it again, but not taking qemu's extras into account,
unless you communicate the overhead somehow...

> 
> 
> > > 
> > > ---
> > > 
> > > Changes in v2:
> > > - remove double return statement;
> > > - check for return errors;
> > > - check for overflows.
> > > ---
> > >  tools/libxl/libxl.c          |   53 +++++++++++++++++++++++++++++++++++++-----
> > >  tools/libxl/libxl_dom.c      |    8 +++++--
> > >  tools/libxl/libxl_internal.h |    7 ++++++
> > >  3 files changed, 60 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > index de23fec..2cdb768 100644
> > > --- a/tools/libxl/libxl.c
> > > +++ b/tools/libxl/libxl.c
> > > @@ -4527,13 +4527,40 @@ out:
> > >  
> > >  /******************************************************************************/
> > >  
> > > +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> > > +{
> > > +    int i, romsize, rc;
> > > +    libxl_domain_config local_d_config;
> > > +    libxl_ctx *ctx = libxl__gc_owner(gc);
> > > +
> > > +    if (d_config == NULL) {
> > > +        libxl_domain_config_init(&local_d_config);
> > > +        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
> > > +        if (rc < 0)
> > > +            return rc;
> > > +        d_config = &local_d_config;
> > > +    }
> > 
> > Perhaps we could store the answer to this function in XS when we build
> > the domain and simply read it back and account for it in the places
> > which use it?
> > 
> > Apart from being rather costly reparsing the json every time is going to
> > behave a bit strangely if NICs are plugged/unplugged at runtime and
> > ballooning is going on.
> > 
> > > +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> > > +        return 0;
> > > +
> > > +    for (i = 0, romsize = 0;
> > > +         i < d_config->num_nics && romsize < INT_MAX;
> > 
> > I don't think that romsize < INT_MAX is useful except in the case that
> > romsize+= results in romsize == INT_MAX. If you actually overflow then
> > romsize becomes negative which satisfies the condition (and in any case
> > you are into undefined behaviour territory there anyhow, I think).
> > 
> > Given that INT_MAX is a boat load of ROMs I'd be inclined to just limit
> > it to INT_MAX/2 or /4 or something.
> > 
> > Or you could do romsize < (INT_MAX - LIBXL_ROMSIZE_KB) I suppose.
> > 
> > > +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> > > +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> > > +                             + romsize);
> > 
> > Seems like we ought to have a helper to return the memory overheads,
> > which would be the constant + the romsize starting from 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 Nov 25 17:21:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17: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 1XtJnT-0006Ne-H6; Tue, 25 Nov 2014 17:21:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtJnR-0006NZ-M8
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 17:21:01 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	74/06-20609-D7AB4745; Tue, 25 Nov 2014 17:21:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416936059!14809990!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1877 invoked from network); 25 Nov 2014 17:21:00 -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;
	25 Nov 2014 17:21:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196267577"
Message-ID: <1416934562.11944.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 25 Nov 2014 16:56:02 +0000
In-Reply-To: <alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> On Tue, 25 Nov 2014, Ian Campbell wrote:
> > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > Account for the extra memory needed for the rom files of any emulated nics:
> > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > each them. Assume 256K each.
> > 
> > I suppose this will have to do for 4.5. Can we do something better in
> > the future -- like figuring out a way for guests to have
> > "not-really-RAM" allocations like this which are made by the toolstack
> > and happen to be backed by RAM not count or something.
> > 
> > > 
> > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > assigned to a VM.
> > 
> > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > option roms? abort() seems a bit extreme.
> > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > CC: Don Slutz <dslutz@verizon.com>
> > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > CC: Wei Liu <wei.liu2@citrix.com>
> > 
> > You missed Ian J. I've added him.
> 
> Actually Wei suggested a better alternative: I could call
> xc_domain_setmaxmem directly from QEMU. That makes much more sense.

xl mem-set would do it again, but not taking qemu's extras into account,
unless you communicate the overhead somehow...

> 
> 
> > > 
> > > ---
> > > 
> > > Changes in v2:
> > > - remove double return statement;
> > > - check for return errors;
> > > - check for overflows.
> > > ---
> > >  tools/libxl/libxl.c          |   53 +++++++++++++++++++++++++++++++++++++-----
> > >  tools/libxl/libxl_dom.c      |    8 +++++--
> > >  tools/libxl/libxl_internal.h |    7 ++++++
> > >  3 files changed, 60 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > index de23fec..2cdb768 100644
> > > --- a/tools/libxl/libxl.c
> > > +++ b/tools/libxl/libxl.c
> > > @@ -4527,13 +4527,40 @@ out:
> > >  
> > >  /******************************************************************************/
> > >  
> > > +int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> > > +{
> > > +    int i, romsize, rc;
> > > +    libxl_domain_config local_d_config;
> > > +    libxl_ctx *ctx = libxl__gc_owner(gc);
> > > +
> > > +    if (d_config == NULL) {
> > > +        libxl_domain_config_init(&local_d_config);
> > > +        rc = libxl_retrieve_domain_configuration(ctx, domid, &local_d_config);
> > > +        if (rc < 0)
> > > +            return rc;
> > > +        d_config = &local_d_config;
> > > +    }
> > 
> > Perhaps we could store the answer to this function in XS when we build
> > the domain and simply read it back and account for it in the places
> > which use it?
> > 
> > Apart from being rather costly reparsing the json every time is going to
> > behave a bit strangely if NICs are plugged/unplugged at runtime and
> > ballooning is going on.
> > 
> > > +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
> > > +        return 0;
> > > +
> > > +    for (i = 0, romsize = 0;
> > > +         i < d_config->num_nics && romsize < INT_MAX;
> > 
> > I don't think that romsize < INT_MAX is useful except in the case that
> > romsize+= results in romsize == INT_MAX. If you actually overflow then
> > romsize becomes negative which satisfies the condition (and in any case
> > you are into undefined behaviour territory there anyhow, I think).
> > 
> > Given that INT_MAX is a boat load of ROMs I'd be inclined to just limit
> > it to INT_MAX/2 or /4 or something.
> > 
> > Or you could do romsize < (INT_MAX - LIBXL_ROMSIZE_KB) I suppose.
> > 
> > > +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> > > +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> > > +                             + romsize);
> > 
> > Seems like we ought to have a helper to return the memory overheads,
> > which would be the constant + the romsize starting from 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 Nov 25 17:25:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 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.xen.org>)
	id 1XtJrq-0006bH-77; Tue, 25 Nov 2014 17:25:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtJrp-0006bB-6w
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 17:25:33 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	9C/35-17735-C8BB4745; Tue, 25 Nov 2014 17:25:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416936331!13786386!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4691 invoked from network); 25 Nov 2014 17:25:32 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 17:25:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 17:25:31 +0000
Message-Id: <5474C998020000780004AD1D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 17:25:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.11.14 at 17:54, <andrew.cooper3@citrix.com> wrote:
> This is RFC as there is still a niggle.  I tested this via a partial revert of
> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
> domain crash.  However, I am not sure we want to make any vmentry failure
> quite, as any vmentry failure constitues a Xen bug.

I think that double printing would be tolerable, but I've had yet
another idea: Couldn't we make the second exception a #DF,
thus having the guest killed via triple fault in the worst case at
the third recurring failure (via hvm_combine_hw_exceptions())?

Also your test results point out that we're delivering such an
exception with wrong context to the guest: Machine state should
match that before the results from the emulation got committed.
But doing so would be a pretty significant change for almost no
benefit.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:25:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 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.xen.org>)
	id 1XtJrq-0006bH-77; Tue, 25 Nov 2014 17:25:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtJrp-0006bB-6w
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 17:25:33 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	9C/35-17735-C8BB4745; Tue, 25 Nov 2014 17:25:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416936331!13786386!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4691 invoked from network); 25 Nov 2014 17:25:32 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 17:25:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 25 Nov 2014 17:25:31 +0000
Message-Id: <5474C998020000780004AD1D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 25 Nov 2014 17:25:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.11.14 at 17:54, <andrew.cooper3@citrix.com> wrote:
> This is RFC as there is still a niggle.  I tested this via a partial revert of
> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
> domain crash.  However, I am not sure we want to make any vmentry failure
> quite, as any vmentry failure constitues a Xen bug.

I think that double printing would be tolerable, but I've had yet
another idea: Couldn't we make the second exception a #DF,
thus having the guest killed via triple fault in the worst case at
the third recurring failure (via hvm_combine_hw_exceptions())?

Also your test results point out that we're delivering such an
exception with wrong context to the guest: Machine state should
match that before the results from the emulation got committed.
But doing so would be a pretty significant change for almost no
benefit.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:30:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJw2-0006jM-T2; Tue, 25 Nov 2014 17:29:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtJw1-0006jH-5a
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 17:29:53 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F7/0F-01660-09CB4745; Tue, 25 Nov 2014 17:29:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416936590!5726110!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2956 invoked from network); 25 Nov 2014 17:29:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 17:29:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196272699"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 12:04:25 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtJXM-000766-S2;
	Tue, 25 Nov 2014 17:04:24 +0000
Date: Tue, 25 Nov 2014 17:04:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141125170424.GB2893@zion.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416934562.11944.22.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 04:56:02PM +0000, Ian Campbell wrote:
> On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > each them. Assume 256K each.
> > > 
> > > I suppose this will have to do for 4.5. Can we do something better in
> > > the future -- like figuring out a way for guests to have
> > > "not-really-RAM" allocations like this which are made by the toolstack
> > > and happen to be backed by RAM not count or something.
> > > 
> > > > 
> > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > assigned to a VM.
> > > 
> > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > option roms? abort() seems a bit extreme.
> > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > CC: Don Slutz <dslutz@verizon.com>
> > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > 
> > > You missed Ian J. I've added him.
> > 
> > Actually Wei suggested a better alternative: I could call
> > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> 
> xl mem-set would do it again, but not taking qemu's extras into account,
> unless you communicate the overhead somehow...
> 

Use a xenstore key? Like /vm/$UUID/XXX.

The key can be written by QEMU (because it knows the extra ram used by
all ROMs) and read by libxl.

(Haven't followed this closely, just my two cents)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:30:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtJw2-0006jM-T2; Tue, 25 Nov 2014 17:29:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XtJw1-0006jH-5a
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 17:29:53 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F7/0F-01660-09CB4745; Tue, 25 Nov 2014 17:29:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416936590!5726110!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2956 invoked from network); 25 Nov 2014 17:29:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 17:29:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196272699"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 12:04:25 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtJXM-000766-S2;
	Tue, 25 Nov 2014 17:04:24 +0000
Date: Tue, 25 Nov 2014 17:04:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141125170424.GB2893@zion.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416934562.11944.22.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 04:56:02PM +0000, Ian Campbell wrote:
> On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > each them. Assume 256K each.
> > > 
> > > I suppose this will have to do for 4.5. Can we do something better in
> > > the future -- like figuring out a way for guests to have
> > > "not-really-RAM" allocations like this which are made by the toolstack
> > > and happen to be backed by RAM not count or something.
> > > 
> > > > 
> > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > assigned to a VM.
> > > 
> > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > option roms? abort() seems a bit extreme.
> > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > CC: Don Slutz <dslutz@verizon.com>
> > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > 
> > > You missed Ian J. I've added him.
> > 
> > Actually Wei suggested a better alternative: I could call
> > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> 
> xl mem-set would do it again, but not taking qemu's extras into account,
> unless you communicate the overhead somehow...
> 

Use a xenstore key? Like /vm/$UUID/XXX.

The key can be written by QEMU (because it knows the extra ram used by
all ROMs) and read by libxl.

(Haven't followed this closely, just my two cents)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:45:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17: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 1XtKAI-00074q-MG; Tue, 25 Nov 2014 17:44:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XtKAH-00074l-C9
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 17:44:37 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	FE/CF-17735-400C4745; Tue, 25 Nov 2014 17:44:36 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416937475!13789997!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26728 invoked from network); 25 Nov 2014 17:44:36 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 17:44:36 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so2287821wiv.14
	for <xen-devel@lists.xenproject.org>;
	Tue, 25 Nov 2014 09:44:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=FxnczJg1wL/qmC7vrJ0aGEF75ystyAdTH+TAoUWoL2g=;
	b=ALOvcrF6FylMQNzmotTjBEL+GKhZqgh69PRd9hVwvyF6YkBCskStxCPH93rHErVRYD
	qF5yXQUV1NSguE5IWUHaP+ETUbG1jcdtJowFvPhd+4KOzBsHKcey+aXHq6dA76JstdN7
	NU4lO+UusIn2aiCa9+bEci/I8nXuDKc05zqE/Dq7HsnIl2CmH8bUiOwgN5Msr5JR16Yl
	ZtYwXmR1P2N3BY/XvQgnyN1ndzEJKeUa56XBe6P53/db8mKJyMSDjz5FQqATCOcdsI/h
	we4JZM4mqqgeU5IVZxd11DHhgSqgGqr6BwtvlcjAdhZsTZvTOaha1hW5Jn16OiFu67lM
	UNvg==
X-Gm-Message-State: ALoCoQlTjbZjxG92icB7fuuACJQw9RfxWhxgwaKuzOiT7VxnOyIwh5MmYYyMruEdMKDY6d64EGyu
X-Received: by 10.180.95.74 with SMTP id di10mr34315443wib.54.1416937475601;
	Tue, 25 Nov 2014 09:44:35 -0800 (PST)
Received: from chilopoda.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id mw7sm3733874wib.14.2014.11.25.09.44.34
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 25 Nov 2014 09:44:34 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 25 Nov 2014 17:44:29 +0000
Message-Id: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
Cc: stefano.stabellini@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ARMv8 model may not disable correctly the timer interrupt when Xen
context switch to an idle vCPU. Therefore Xen may receive a spurious
timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
when trying to inject the interrupt with the following stack trace.

(XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
(XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
(XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
(XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
(XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
(XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
(XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
(XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
(XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
(XEN)    [<000000000022482c>] schedule+0x684/0x6d0
(XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
(XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
(XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
(XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
(XEN)    [<0000000000000001>] 0000000000000001

While we receive spurious virtual timer interrupt, this could be safely
ignore for the time being. A proper fix need to be found for Xen 4.6.

Signed-off-by: Julien Grall <julien.grall@linaro.org>

---

This patch is a bug fix candidate for Xen 4.5. Any ARMv8 model may
randomly crash when running Xen.

This patch don't inject the virtual timer interrupt if the current VCPU
is the idle one. Entering in this function with the idle VCPU is already
a bug itself. For now, I think this patch is the safest way to resolve
the problem.

Meanwhile, I'm investigating with ARM to see wheter the bug comes from
Xen or the model.
---
 xen/arch/arm/time.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index a6436f1..83c74cb 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -169,6 +169,14 @@ static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 
 static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
+    /*
+     * ARMv8 model may not disable correctly the timer interrupt when
+     * Xen context switch to an idle vCPU. Therefore Xen may receive
+     * timer interrupt.
+     */
+    if ( is_idle_vcpu(current) )
+        return;
+
     current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
     WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
     vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq);
-- 
2.1.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:45:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17: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 1XtKAI-00074q-MG; Tue, 25 Nov 2014 17:44:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XtKAH-00074l-C9
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 17:44:37 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	FE/CF-17735-400C4745; Tue, 25 Nov 2014 17:44:36 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416937475!13789997!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26728 invoked from network); 25 Nov 2014 17:44:36 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 17:44:36 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so2287821wiv.14
	for <xen-devel@lists.xenproject.org>;
	Tue, 25 Nov 2014 09:44:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=FxnczJg1wL/qmC7vrJ0aGEF75ystyAdTH+TAoUWoL2g=;
	b=ALOvcrF6FylMQNzmotTjBEL+GKhZqgh69PRd9hVwvyF6YkBCskStxCPH93rHErVRYD
	qF5yXQUV1NSguE5IWUHaP+ETUbG1jcdtJowFvPhd+4KOzBsHKcey+aXHq6dA76JstdN7
	NU4lO+UusIn2aiCa9+bEci/I8nXuDKc05zqE/Dq7HsnIl2CmH8bUiOwgN5Msr5JR16Yl
	ZtYwXmR1P2N3BY/XvQgnyN1ndzEJKeUa56XBe6P53/db8mKJyMSDjz5FQqATCOcdsI/h
	we4JZM4mqqgeU5IVZxd11DHhgSqgGqr6BwtvlcjAdhZsTZvTOaha1hW5Jn16OiFu67lM
	UNvg==
X-Gm-Message-State: ALoCoQlTjbZjxG92icB7fuuACJQw9RfxWhxgwaKuzOiT7VxnOyIwh5MmYYyMruEdMKDY6d64EGyu
X-Received: by 10.180.95.74 with SMTP id di10mr34315443wib.54.1416937475601;
	Tue, 25 Nov 2014 09:44:35 -0800 (PST)
Received: from chilopoda.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id mw7sm3733874wib.14.2014.11.25.09.44.34
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 25 Nov 2014 09:44:34 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 25 Nov 2014 17:44:29 +0000
Message-Id: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
Cc: stefano.stabellini@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ARMv8 model may not disable correctly the timer interrupt when Xen
context switch to an idle vCPU. Therefore Xen may receive a spurious
timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
when trying to inject the interrupt with the following stack trace.

(XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
(XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
(XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
(XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
(XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
(XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
(XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
(XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
(XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
(XEN)    [<000000000022482c>] schedule+0x684/0x6d0
(XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
(XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
(XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
(XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
(XEN)    [<0000000000000001>] 0000000000000001

While we receive spurious virtual timer interrupt, this could be safely
ignore for the time being. A proper fix need to be found for Xen 4.6.

Signed-off-by: Julien Grall <julien.grall@linaro.org>

---

This patch is a bug fix candidate for Xen 4.5. Any ARMv8 model may
randomly crash when running Xen.

This patch don't inject the virtual timer interrupt if the current VCPU
is the idle one. Entering in this function with the idle VCPU is already
a bug itself. For now, I think this patch is the safest way to resolve
the problem.

Meanwhile, I'm investigating with ARM to see wheter the bug comes from
Xen or the model.
---
 xen/arch/arm/time.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index a6436f1..83c74cb 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -169,6 +169,14 @@ static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 
 static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
+    /*
+     * ARMv8 model may not disable correctly the timer interrupt when
+     * Xen context switch to an idle vCPU. Therefore Xen may receive
+     * timer interrupt.
+     */
+    if ( is_idle_vcpu(current) )
+        return;
+
     current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
     WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
     vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq);
-- 
2.1.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:51:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17: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 1XtKHD-0007DY-LF; Tue, 25 Nov 2014 17:51:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtKHC-0007DA-4E
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 17:51:46 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	50/55-22737-1B1C4745; Tue, 25 Nov 2014 17:51:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416937903!13295348!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16783 invoked from network); 25 Nov 2014 17:51:44 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 17:51:44 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPHpZWb032686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 17:51:35 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAPHpYgu027912
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 17:51:34 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPHpXEK014671; Tue, 25 Nov 2014 17:51:33 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.57)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 09:51:33 -0800
Date: Tue, 25 Nov 2014 12:51:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141125175126.GA24065@konrad-lan.dumpdata.com>
References: <1416931449-30679-1-git-send-email-olaf@aepfle.de>
	<20141125161342.GK29886@konrad-lan.dumpdata.com>
	<20141125162753.GA2551@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141125162753.GA2551@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] INSTALL: correct EXTRA_CFLAGS 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, Nov 25, 2014 at 05:27:53PM +0100, Olaf Hering wrote:
> On Tue, Nov 25, Konrad Rzeszutek Wilk wrote:
> 
> > On Tue, Nov 25, 2014 at 05:04:09PM +0100, Olaf Hering wrote:
> > > +Using additional CFLAGS to build tools running in dom0 is required when
> > Why the mention of 'buld tools running in dom0'? It sounds like it is
> > required to use dom0 to build tools?
> 
> Does it really read like dom0 is required?! But I can change it as you

It did to me but I am not an native English speaker.

Perhaps what you meant was 'build tools which will run in dom0' ?

> suggest.
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:51:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17: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 1XtKHD-0007DY-LF; Tue, 25 Nov 2014 17:51:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtKHC-0007DA-4E
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 17:51:46 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	50/55-22737-1B1C4745; Tue, 25 Nov 2014 17:51:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1416937903!13295348!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16783 invoked from network); 25 Nov 2014 17:51:44 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 17:51:44 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPHpZWb032686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 17:51:35 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAPHpYgu027912
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 17:51:34 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPHpXEK014671; Tue, 25 Nov 2014 17:51:33 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.57)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 09:51:33 -0800
Date: Tue, 25 Nov 2014 12:51:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141125175126.GA24065@konrad-lan.dumpdata.com>
References: <1416931449-30679-1-git-send-email-olaf@aepfle.de>
	<20141125161342.GK29886@konrad-lan.dumpdata.com>
	<20141125162753.GA2551@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141125162753.GA2551@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] INSTALL: correct EXTRA_CFLAGS 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, Nov 25, 2014 at 05:27:53PM +0100, Olaf Hering wrote:
> On Tue, Nov 25, Konrad Rzeszutek Wilk wrote:
> 
> > On Tue, Nov 25, 2014 at 05:04:09PM +0100, Olaf Hering wrote:
> > > +Using additional CFLAGS to build tools running in dom0 is required when
> > Why the mention of 'buld tools running in dom0'? It sounds like it is
> > required to use dom0 to build tools?
> 
> Does it really read like dom0 is required?! But I can change it as you

It did to me but I am not an native English speaker.

Perhaps what you meant was 'build tools which will run in dom0' ?

> suggest.
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:54:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:54:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKJl-0007Ot-6g; Tue, 25 Nov 2014 17:54:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtKJj-0007Oo-If
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 17:54:23 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	D4/5E-03145-E42C4745; Tue, 25 Nov 2014 17:54:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416938061!14801831!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31711 invoked from network); 25 Nov 2014 17:54:22 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 17:54:22 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPHsJCR032293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 17:54:20 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPHsH6d024449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 17:54:18 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPHsHbr026601; Tue, 25 Nov 2014 17:54:17 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.57)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 09:54:17 -0800
Date: Tue, 25 Nov 2014 12:54:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141125175414.GB24065@konrad-lan.dumpdata.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
	<54744FB2020000780004A935@mail.emea.novell.com>
	<54749466.1020907@oracle.com>
	<5474A666020000780004AB9C@mail.emea.novell.com>
	<5474ABFF.1030306@oracle.com>
	<5474BEEA020000780004ACB1@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5474BEEA020000780004ACB1@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
	PVH 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, Nov 25, 2014 at 04:39:54PM +0000, Jan Beulich wrote:
> >>> On 25.11.14 at 17:19, <boris.ostrovsky@oracle.com> wrote:
> > On 11/25/2014 09:55 AM, Jan Beulich wrote:
> >>
> >>> Regardless, do you think that disabling VPMU for PVH is worth anyway?
> >> That depends on what (bad) consequences not doing so has.
> > 
> > I haven't seen anything (besides VAPIC accesses) but I think it would be 
> > prudent to prevent any VPMU activity from happening. I can see, for 
> > example MSRs and APIC vector being written. All of which look benign on 
> > the first sight but who knows...
> 
> Yeah, it's not really a problem to put it in (if Konrad agrees; remember
> that PVH is still experimental, and hence fixing bugs caused only by it
> may be out of scope at this point - in any event I think that if your
> patch is to go in, mine should too).

The beaty of experimental is that we can add it later in the cycle as
at worst they will regress something that is unbaked already.

>From that perspective the bar to put fixes for 'experimental' is lower
than normal code. The part that I am worried about is the common paths
and this potentially causing regressions on the those.

But the potential for that is low that I am OK with these patches
going in. 
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 17:54:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 17:54:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKJl-0007Ot-6g; Tue, 25 Nov 2014 17:54:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtKJj-0007Oo-If
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 17:54:23 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	D4/5E-03145-E42C4745; Tue, 25 Nov 2014 17:54:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1416938061!14801831!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31711 invoked from network); 25 Nov 2014 17:54:22 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 17:54:22 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPHsJCR032293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 17:54:20 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPHsH6d024449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 17:54:18 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPHsHbr026601; Tue, 25 Nov 2014 17:54:17 GMT
Received: from konrad-lan.dumpdata.com (/137.254.4.57)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 09:54:17 -0800
Date: Tue, 25 Nov 2014 12:54:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141125175414.GB24065@konrad-lan.dumpdata.com>
References: <1416858554-1817-1-git-send-email-boris.ostrovsky@oracle.com>
	<54744FB2020000780004A935@mail.emea.novell.com>
	<54749466.1020907@oracle.com>
	<5474A666020000780004AB9C@mail.emea.novell.com>
	<5474ABFF.1030306@oracle.com>
	<5474BEEA020000780004ACB1@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5474BEEA020000780004ACB1@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for
	PVH 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, Nov 25, 2014 at 04:39:54PM +0000, Jan Beulich wrote:
> >>> On 25.11.14 at 17:19, <boris.ostrovsky@oracle.com> wrote:
> > On 11/25/2014 09:55 AM, Jan Beulich wrote:
> >>
> >>> Regardless, do you think that disabling VPMU for PVH is worth anyway?
> >> That depends on what (bad) consequences not doing so has.
> > 
> > I haven't seen anything (besides VAPIC accesses) but I think it would be 
> > prudent to prevent any VPMU activity from happening. I can see, for 
> > example MSRs and APIC vector being written. All of which look benign on 
> > the first sight but who knows...
> 
> Yeah, it's not really a problem to put it in (if Konrad agrees; remember
> that PVH is still experimental, and hence fixing bugs caused only by it
> may be out of scope at this point - in any event I think that if your
> patch is to go in, mine should too).

The beaty of experimental is that we can add it later in the cycle as
at worst they will regress something that is unbaked already.

>From that perspective the bar to put fixes for 'experimental' is lower
than normal code. The part that I am worried about is the common paths
and this potentially causing regressions on the those.

But the potential for that is low that I am OK with these patches
going in. 
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:06:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 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 1XtKVP-0007mJ-JR; Tue, 25 Nov 2014 18:06:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtKVO-0007mE-Re
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 18:06:26 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	DF/77-14727-225C4745; Tue, 25 Nov 2014 18:06:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416938782!13290110!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26791 invoked from network); 25 Nov 2014 18:06:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 18:06:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196297077"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 12:45:55 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtKBX-0008F1-0h;
	Tue, 25 Nov 2014 17:45:55 +0000
Date: Tue, 25 Nov 2014 17:45:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] increase maxmem before calling
	xc_domain_populate_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

Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
the risk of running out of guest memory. This way we can also avoid
complex memory calculations in libxl at domain construction time.

This patch fixes an abort() when assigning more than 4 NICs to a VM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/xen-hvm.c b/xen-hvm.c
index 5c69a8d..38e08c3 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -218,6 +218,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     unsigned long nr_pfn;
     xen_pfn_t *pfn_list;
     int i;
+    xc_dominfo_t info;
 
     if (runstate_check(RUN_STATE_INMIGRATE)) {
         /* RAM already populated in Xen */
@@ -240,6 +241,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
         pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
     }
 
+    if (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) < 0) {
+        hw_error("xc_domain_getinfo failed");
+    }
+    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
+                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
+        hw_error("xc_domain_setmaxmem failed");
+    }
     if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) {
         hw_error("xen: failed to populate ram at " RAM_ADDR_FMT, ram_addr);
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:06:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 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 1XtKVP-0007mJ-JR; Tue, 25 Nov 2014 18:06:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtKVO-0007mE-Re
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 18:06:26 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	DF/77-14727-225C4745; Tue, 25 Nov 2014 18:06:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1416938782!13290110!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26791 invoked from network); 25 Nov 2014 18:06:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 18:06:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196297077"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 12:45:55 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtKBX-0008F1-0h;
	Tue, 25 Nov 2014 17:45:55 +0000
Date: Tue, 25 Nov 2014 17:45:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] increase maxmem before calling
	xc_domain_populate_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

Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
the risk of running out of guest memory. This way we can also avoid
complex memory calculations in libxl at domain construction time.

This patch fixes an abort() when assigning more than 4 NICs to a VM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/xen-hvm.c b/xen-hvm.c
index 5c69a8d..38e08c3 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -218,6 +218,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     unsigned long nr_pfn;
     xen_pfn_t *pfn_list;
     int i;
+    xc_dominfo_t info;
 
     if (runstate_check(RUN_STATE_INMIGRATE)) {
         /* RAM already populated in Xen */
@@ -240,6 +241,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
         pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
     }
 
+    if (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) < 0) {
+        hw_error("xc_domain_getinfo failed");
+    }
+    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
+                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
+        hw_error("xc_domain_setmaxmem failed");
+    }
     if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) {
         hw_error("xen: failed to populate ram at " RAM_ADDR_FMT, ram_addr);
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:07:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKWc-0007pt-1b; Tue, 25 Nov 2014 18:07:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XtKWb-0007pg-6r
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:07:41 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E5/2A-17694-C65C4745; Tue, 25 Nov 2014 18:07:40 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416938859!13794157!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22749 invoked from network); 25 Nov 2014 18:07:39 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-16.tower-31.messagelabs.com with SMTP;
	25 Nov 2014 18:07:39 -0000
X-TM-IMSS-Message-ID: <570d429400027a63@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 570d429400027a63 ;
	Tue, 25 Nov 2014 13:07:37 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAPI7Hu4006762; 
	Tue, 25 Nov 2014 13:07:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 25 Nov 2014 11:57:44 -0500
Message-Id: <1416934664-17630-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.9.3
Cc: andrew.cooper3@citrix.com, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH for-4.5] xsm/flask: add two missing domctls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Reported-by: Michael Young <m.a.young@durham.ac.uk>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c               | 2 ++
 xen/xsm/flask/policy/access_vectors | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0ba2ce9..d48463f 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -672,9 +672,11 @@ static int flask_domctl(struct domain *d, int cmd)
         return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
 
     case XEN_DOMCTL_set_ext_vcpucontext:
+    case XEN_DOMCTL_set_vcpu_msrs:
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT);
 
     case XEN_DOMCTL_get_ext_vcpucontext:
+    case XEN_DOMCTL_get_vcpu_msrs:
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT);
 
     case XEN_DOMCTL_setvcpuextstate:
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1cd451e..1da9f63 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -151,8 +151,10 @@ class domain
 # XEN_DOMCTL_sendtrigger
     trigger
 # XEN_DOMCTL_get_ext_vcpucontext
+# XEN_DOMCTL_set_vcpu_msrs
     getextvcpucontext
 # XEN_DOMCTL_set_ext_vcpucontext
+# XEN_DOMCTL_get_vcpu_msrs
     setextvcpucontext
 # XEN_DOMCTL_getvcpuextstate
     getvcpuextstate
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:07:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKWc-0007q2-Cw; Tue, 25 Nov 2014 18:07:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XtKWb-0007ph-AR
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:07:41 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	23/FE-28296-C65C4745; Tue, 25 Nov 2014 18:07:40 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416938859!13805311!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30589 invoked from network); 25 Nov 2014 18:07:39 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-8.tower-31.messagelabs.com with SMTP;
	25 Nov 2014 18:07:39 -0000
X-TM-IMSS-Message-ID: <570d430100027a64@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 570d430100027a64 ;
	Tue, 25 Nov 2014 13:07:37 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAPI7EDT006760; 
	Tue, 25 Nov 2014 13:07:27 -0500
Message-ID: <5474C476.3080203@tycho.nsa.gov>
Date: Tue, 25 Nov 2014 13:03:34 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: George Dunlap <dunlapg@umich.edu>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>	<20141124124143.GA11483@zion.uk.xensource.com>	<54732F8E.4060507@citrix.com>	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>	<547343F4.80509@citrix.com>	<alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>	<5473ABA2.6080901@tycho.nsa.gov>
	<CAFLBxZZFO+ms+TX4Gmchkb53CWL6EHeoGEcBKEgvMgx3AQaqvg@mail.gmail.com>
In-Reply-To: <CAFLBxZZFO+ms+TX4Gmchkb53CWL6EHeoGEcBKEgvMgx3AQaqvg@mail.gmail.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 05:07 AM, George Dunlap wrote:
> On Mon, Nov 24, 2014 at 10:05 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> I do. The error is
>>> (XEN) flask_domctl: Unknown op 72
>>>
>>> Incidentally, Flask is running in permissive mode.
>>>
>>>       Michael Young
>>>
>>
>> This means that the new domctl needs to be added to the switch statement
>> in flask/hooks.c.  This error is triggered in permissive mode because it
>> is a code error rather than a policy error (which is what permissive mode
>> is intended to debug).
>
> If that's the case, should we make that a BUG_ON()?  Or at least an
> ASSERT() (which will only bug when compiled with debug=y), followed by
> allow if in permissive mode, and deny if in enforcing mode?
>
> Having it default deny, even in permissive mode, breaks the "principle
> of least surprise", I think. :-)
>
>   -George
  
Either one of these will allow a guest to crash the hypervisor by requesting
an undefined domctl, which is not really a good idea.  Linux uses a flag in
the security policy which defines if unknown permissions are allowed or
denied; I will send a patch adding this to Xen's security server and using
it instead of -EPERM in the default case of the switch statements.

The patch adding this feature probably shouldn't be applied to 4.5, but I'll
send it anyway.  I will also send a separate patch adding the 2 domctls.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:07:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKWc-0007q2-Cw; Tue, 25 Nov 2014 18:07:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XtKWb-0007ph-AR
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:07:41 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	23/FE-28296-C65C4745; Tue, 25 Nov 2014 18:07:40 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416938859!13805311!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30589 invoked from network); 25 Nov 2014 18:07:39 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-8.tower-31.messagelabs.com with SMTP;
	25 Nov 2014 18:07:39 -0000
X-TM-IMSS-Message-ID: <570d430100027a64@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 570d430100027a64 ;
	Tue, 25 Nov 2014 13:07:37 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAPI7EDT006760; 
	Tue, 25 Nov 2014 13:07:27 -0500
Message-ID: <5474C476.3080203@tycho.nsa.gov>
Date: Tue, 25 Nov 2014 13:03:34 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: George Dunlap <dunlapg@umich.edu>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>	<20141124124143.GA11483@zion.uk.xensource.com>	<54732F8E.4060507@citrix.com>	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>	<547343F4.80509@citrix.com>	<alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>	<5473ABA2.6080901@tycho.nsa.gov>
	<CAFLBxZZFO+ms+TX4Gmchkb53CWL6EHeoGEcBKEgvMgx3AQaqvg@mail.gmail.com>
In-Reply-To: <CAFLBxZZFO+ms+TX4Gmchkb53CWL6EHeoGEcBKEgvMgx3AQaqvg@mail.gmail.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 05:07 AM, George Dunlap wrote:
> On Mon, Nov 24, 2014 at 10:05 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> I do. The error is
>>> (XEN) flask_domctl: Unknown op 72
>>>
>>> Incidentally, Flask is running in permissive mode.
>>>
>>>       Michael Young
>>>
>>
>> This means that the new domctl needs to be added to the switch statement
>> in flask/hooks.c.  This error is triggered in permissive mode because it
>> is a code error rather than a policy error (which is what permissive mode
>> is intended to debug).
>
> If that's the case, should we make that a BUG_ON()?  Or at least an
> ASSERT() (which will only bug when compiled with debug=y), followed by
> allow if in permissive mode, and deny if in enforcing mode?
>
> Having it default deny, even in permissive mode, breaks the "principle
> of least surprise", I think. :-)
>
>   -George
  
Either one of these will allow a guest to crash the hypervisor by requesting
an undefined domctl, which is not really a good idea.  Linux uses a flag in
the security policy which defines if unknown permissions are allowed or
denied; I will send a patch adding this to Xen's security server and using
it instead of -EPERM in the default case of the switch statements.

The patch adding this feature probably shouldn't be applied to 4.5, but I'll
send it anyway.  I will also send a separate patch adding the 2 domctls.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:07:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKWc-0007pt-1b; Tue, 25 Nov 2014 18:07:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XtKWb-0007pg-6r
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:07:41 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E5/2A-17694-C65C4745; Tue, 25 Nov 2014 18:07:40 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416938859!13794157!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22749 invoked from network); 25 Nov 2014 18:07:39 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-16.tower-31.messagelabs.com with SMTP;
	25 Nov 2014 18:07:39 -0000
X-TM-IMSS-Message-ID: <570d429400027a63@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 570d429400027a63 ;
	Tue, 25 Nov 2014 13:07:37 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAPI7Hu4006762; 
	Tue, 25 Nov 2014 13:07:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 25 Nov 2014 11:57:44 -0500
Message-Id: <1416934664-17630-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.9.3
Cc: andrew.cooper3@citrix.com, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH for-4.5] xsm/flask: add two missing domctls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Reported-by: Michael Young <m.a.young@durham.ac.uk>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c               | 2 ++
 xen/xsm/flask/policy/access_vectors | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0ba2ce9..d48463f 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -672,9 +672,11 @@ static int flask_domctl(struct domain *d, int cmd)
         return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
 
     case XEN_DOMCTL_set_ext_vcpucontext:
+    case XEN_DOMCTL_set_vcpu_msrs:
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT);
 
     case XEN_DOMCTL_get_ext_vcpucontext:
+    case XEN_DOMCTL_get_vcpu_msrs:
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT);
 
     case XEN_DOMCTL_setvcpuextstate:
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1cd451e..1da9f63 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -151,8 +151,10 @@ class domain
 # XEN_DOMCTL_sendtrigger
     trigger
 # XEN_DOMCTL_get_ext_vcpucontext
+# XEN_DOMCTL_set_vcpu_msrs
     getextvcpucontext
 # XEN_DOMCTL_set_ext_vcpucontext
+# XEN_DOMCTL_get_vcpu_msrs
     setextvcpucontext
 # XEN_DOMCTL_getvcpuextstate
     getvcpuextstate
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:09:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:09:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKYF-00082u-T5; Tue, 25 Nov 2014 18:09:23 +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 1XtKYE-00082i-Cd
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:09:22 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	03/71-14214-1D5C4745; Tue, 25 Nov 2014 18:09:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416938960!8026992!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14495 invoked from network); 25 Nov 2014 18:09:20 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-10.tower-206.messagelabs.com with SMTP;
	25 Nov 2014 18:09:20 -0000
X-TM-IMSS-Message-ID: <333ce9800002574b@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 333ce9800002574b ;
	Tue, 25 Nov 2014 13:09:05 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAPI8lLP006827; 
	Tue, 25 Nov 2014 13:08:57 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 25 Nov 2014 13:05:03 -0500
Message-Id: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.9.3
Cc: dunlapg@umich.edu, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xsm/flask: improve unknown permission 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>
MIME-Version: 1.0
Content-Type: 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 an unknown domctl, sysctl, or other operation is encountered in the
FLASK security server, use the allow_unknown bit in the security policy
(set by running checkpolicy -U allow) to decide if the permission should
be allowed or denied.  This allows new operations to be tested without
needing to immediately add security checks; however, it is not flexible
enough to avoid adding the actual permission checks.  An error message
is printed to the hypervisor console when this fallback is encountered.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c            | 40 ++++++++++++++++++++++++----------------
 xen/xsm/flask/include/security.h |  2 ++
 xen/xsm/flask/ss/policydb.c      |  1 +
 xen/xsm/flask/ss/policydb.h      |  6 ++++++
 xen/xsm/flask/ss/services.c      |  5 +++++
 5 files changed, 38 insertions(+), 16 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0ba2ce9..4c8a1d2 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -135,6 +135,19 @@ static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
     return 0;
 }
 
+static int avc_unknown_permission(const char* name, int id)
+{
+    /* A guest making an invalid hypercall can trigger this message, so it can't
+     * be an ASSERT or BUG_ON, but normally it is caused by a missing case in
+     * one of the switch statements below.
+     */
+    printk(XENLOG_G_ERR "FLASK: Unknown %s: %d.\n", name, id);
+    if ( !flask_enforcing || security_get_allow_unknown() )
+        return 0;
+    else
+        return -EPERM;
+}
+
 static int flask_domain_alloc_security(struct domain *d)
 {
     struct domain_security_struct *dsec;
@@ -270,7 +283,7 @@ static int flask_evtchn_send(struct domain *d, struct evtchn *chn)
         rc = 0;
         break;
     default:
-        rc = -EPERM;
+        rc = avc_unknown_permission("event channel state", chn->state);
     }
 
     return rc;
@@ -422,7 +435,7 @@ static int flask_console_io(struct domain *d, int cmd)
         perm = XEN__WRITECONSOLE;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("console_io", cmd);
     }
 
     return domain_has_xen(d, perm);
@@ -454,7 +467,7 @@ static int flask_profile(struct domain *d, int op)
         perm = XEN__PRIVPROFILE;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("xenoprof op", op);
     }
 
     return domain_has_xen(d, perm);
@@ -520,8 +533,7 @@ static int flask_domctl_scheduler_op(struct domain *d, int op)
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETSCHEDULER);
 
     default:
-        printk("flask_domctl_scheduler_op: Unknown op %d\n", op);
-        return -EPERM;
+        return avc_unknown_permission("domctl_scheduler_op", op);
     }
 }
 
@@ -536,8 +548,7 @@ static int flask_sysctl_scheduler_op(int op)
         return domain_has_xen(current->domain, XEN__GETSCHEDULER);
 
     default:
-        printk("flask_domctl_scheduler_op: Unknown op %d\n", op);
-        return -EPERM;
+        return avc_unknown_permission("sysctl_scheduler_op", op);
     }
 }
 
@@ -731,8 +742,7 @@ static int flask_domctl(struct domain *d, int cmd)
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
 
     default:
-        printk("flask_domctl: Unknown op %d\n", cmd);
-        return -EPERM;
+        return avc_unknown_permission("domctl", cmd);
     }
 }
 
@@ -790,8 +800,7 @@ static int flask_sysctl(int cmd)
                                     XEN2__PSR_CMT_OP, NULL);
 
     default:
-        printk("flask_sysctl: Unknown op %d\n", cmd);
-        return -EPERM;
+        return avc_unknown_permission("sysctl", cmd);
     }
 }
 
@@ -1078,7 +1087,7 @@ static inline int flask_page_offline(uint32_t cmd)
     case sysctl_query_page_offline:
         return flask_resource_use_core();
     default:
-        return -EPERM;
+        return avc_unknown_permission("page_offline", cmd);
     }
 }
 
@@ -1240,7 +1249,7 @@ static int flask_shadow_control(struct domain *d, uint32_t op)
         perm = SHADOW__LOGDIRTY;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("shadow_control", op);
     }
 
     return current_has_perm(d, SECCLASS_SHADOW, perm);
@@ -1344,7 +1353,7 @@ static int flask_apic(struct domain *d, int cmd)
         perm = XEN__WRITEAPIC;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("apic", cmd);
     }
 
     return domain_has_xen(d, perm);
@@ -1409,8 +1418,7 @@ static int flask_platform_op(uint32_t op)
                                     XEN2__RESOURCE_OP, NULL);
 
     default:
-        printk("flask_platform_op: Unknown op %d\n", op);
-        return -EPERM;
+        return avc_unknown_permission("platform_op", op);
     }
 }
 
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 348f018..a93f14a 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -71,6 +71,8 @@ int security_context_to_sid(char *scontext, u32 scontext_len, u32 *out_sid);
 
 int security_get_user_sids(u32 callsid, char *username, u32 **sids, u32 *nel);
 
+int security_get_allow_unknown(void);
+
 int security_irq_sid(int pirq, u32 *out_sid);
 
 int security_iomem_sid(unsigned long, u32 *out_sid);
diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index 50b2c78..b648f05 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -1802,6 +1802,7 @@ int policydb_read(struct policydb *p, void *fp)
             goto bad;
         }
     }
+    p->allow_unknown = !!(le32_to_cpu(buf[1]) & ALLOW_UNKNOWN);
 
     if ( p->policyvers >= POLICYDB_VERSION_POLCAP &&
          ebitmap_read(&p->policycaps, fp) != 0 )
diff --git a/xen/xsm/flask/ss/policydb.h b/xen/xsm/flask/ss/policydb.h
index b176300..aeaf69b 100644
--- a/xen/xsm/flask/ss/policydb.h
+++ b/xen/xsm/flask/ss/policydb.h
@@ -245,6 +245,8 @@ struct policydb {
 
     unsigned int policyvers;
 
+    unsigned int allow_unknown : 1;
+
     u16 target_type;
 };
 
@@ -260,6 +262,10 @@ extern int policydb_read(struct policydb *p, void *fp);
 
 #define POLICYDB_CONFIG_MLS    1
 
+/* the config flags related to unknown classes/perms are bits 2 and 3 */
+#define REJECT_UNKNOWN 0x00000002
+#define ALLOW_UNKNOWN  0x00000004
+
 #define OBJECT_R "object_r"
 #define OBJECT_R_VAL 1
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index f0e459a..9b18509 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1464,6 +1464,11 @@ err:
 
 }
 
+int security_get_allow_unknown(void)
+{
+    return policydb.allow_unknown;
+}
+
 /**
  * security_irq_sid - Obtain the SID for a physical irq.
  * @pirq: physical irq
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:09:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:09:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKYF-00082u-T5; Tue, 25 Nov 2014 18:09:23 +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 1XtKYE-00082i-Cd
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:09:22 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	03/71-14214-1D5C4745; Tue, 25 Nov 2014 18:09:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-206.messagelabs.com!1416938960!8026992!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14495 invoked from network); 25 Nov 2014 18:09:20 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-10.tower-206.messagelabs.com with SMTP;
	25 Nov 2014 18:09:20 -0000
X-TM-IMSS-Message-ID: <333ce9800002574b@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 333ce9800002574b ;
	Tue, 25 Nov 2014 13:09:05 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAPI8lLP006827; 
	Tue, 25 Nov 2014 13:08:57 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 25 Nov 2014 13:05:03 -0500
Message-Id: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.9.3
Cc: dunlapg@umich.edu, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xsm/flask: improve unknown permission 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>
MIME-Version: 1.0
Content-Type: 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 an unknown domctl, sysctl, or other operation is encountered in the
FLASK security server, use the allow_unknown bit in the security policy
(set by running checkpolicy -U allow) to decide if the permission should
be allowed or denied.  This allows new operations to be tested without
needing to immediately add security checks; however, it is not flexible
enough to avoid adding the actual permission checks.  An error message
is printed to the hypervisor console when this fallback is encountered.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c            | 40 ++++++++++++++++++++++++----------------
 xen/xsm/flask/include/security.h |  2 ++
 xen/xsm/flask/ss/policydb.c      |  1 +
 xen/xsm/flask/ss/policydb.h      |  6 ++++++
 xen/xsm/flask/ss/services.c      |  5 +++++
 5 files changed, 38 insertions(+), 16 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0ba2ce9..4c8a1d2 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -135,6 +135,19 @@ static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
     return 0;
 }
 
+static int avc_unknown_permission(const char* name, int id)
+{
+    /* A guest making an invalid hypercall can trigger this message, so it can't
+     * be an ASSERT or BUG_ON, but normally it is caused by a missing case in
+     * one of the switch statements below.
+     */
+    printk(XENLOG_G_ERR "FLASK: Unknown %s: %d.\n", name, id);
+    if ( !flask_enforcing || security_get_allow_unknown() )
+        return 0;
+    else
+        return -EPERM;
+}
+
 static int flask_domain_alloc_security(struct domain *d)
 {
     struct domain_security_struct *dsec;
@@ -270,7 +283,7 @@ static int flask_evtchn_send(struct domain *d, struct evtchn *chn)
         rc = 0;
         break;
     default:
-        rc = -EPERM;
+        rc = avc_unknown_permission("event channel state", chn->state);
     }
 
     return rc;
@@ -422,7 +435,7 @@ static int flask_console_io(struct domain *d, int cmd)
         perm = XEN__WRITECONSOLE;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("console_io", cmd);
     }
 
     return domain_has_xen(d, perm);
@@ -454,7 +467,7 @@ static int flask_profile(struct domain *d, int op)
         perm = XEN__PRIVPROFILE;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("xenoprof op", op);
     }
 
     return domain_has_xen(d, perm);
@@ -520,8 +533,7 @@ static int flask_domctl_scheduler_op(struct domain *d, int op)
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETSCHEDULER);
 
     default:
-        printk("flask_domctl_scheduler_op: Unknown op %d\n", op);
-        return -EPERM;
+        return avc_unknown_permission("domctl_scheduler_op", op);
     }
 }
 
@@ -536,8 +548,7 @@ static int flask_sysctl_scheduler_op(int op)
         return domain_has_xen(current->domain, XEN__GETSCHEDULER);
 
     default:
-        printk("flask_domctl_scheduler_op: Unknown op %d\n", op);
-        return -EPERM;
+        return avc_unknown_permission("sysctl_scheduler_op", op);
     }
 }
 
@@ -731,8 +742,7 @@ static int flask_domctl(struct domain *d, int cmd)
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CONFIGURE_DOMAIN);
 
     default:
-        printk("flask_domctl: Unknown op %d\n", cmd);
-        return -EPERM;
+        return avc_unknown_permission("domctl", cmd);
     }
 }
 
@@ -790,8 +800,7 @@ static int flask_sysctl(int cmd)
                                     XEN2__PSR_CMT_OP, NULL);
 
     default:
-        printk("flask_sysctl: Unknown op %d\n", cmd);
-        return -EPERM;
+        return avc_unknown_permission("sysctl", cmd);
     }
 }
 
@@ -1078,7 +1087,7 @@ static inline int flask_page_offline(uint32_t cmd)
     case sysctl_query_page_offline:
         return flask_resource_use_core();
     default:
-        return -EPERM;
+        return avc_unknown_permission("page_offline", cmd);
     }
 }
 
@@ -1240,7 +1249,7 @@ static int flask_shadow_control(struct domain *d, uint32_t op)
         perm = SHADOW__LOGDIRTY;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("shadow_control", op);
     }
 
     return current_has_perm(d, SECCLASS_SHADOW, perm);
@@ -1344,7 +1353,7 @@ static int flask_apic(struct domain *d, int cmd)
         perm = XEN__WRITEAPIC;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("apic", cmd);
     }
 
     return domain_has_xen(d, perm);
@@ -1409,8 +1418,7 @@ static int flask_platform_op(uint32_t op)
                                     XEN2__RESOURCE_OP, NULL);
 
     default:
-        printk("flask_platform_op: Unknown op %d\n", op);
-        return -EPERM;
+        return avc_unknown_permission("platform_op", op);
     }
 }
 
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 348f018..a93f14a 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -71,6 +71,8 @@ int security_context_to_sid(char *scontext, u32 scontext_len, u32 *out_sid);
 
 int security_get_user_sids(u32 callsid, char *username, u32 **sids, u32 *nel);
 
+int security_get_allow_unknown(void);
+
 int security_irq_sid(int pirq, u32 *out_sid);
 
 int security_iomem_sid(unsigned long, u32 *out_sid);
diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index 50b2c78..b648f05 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -1802,6 +1802,7 @@ int policydb_read(struct policydb *p, void *fp)
             goto bad;
         }
     }
+    p->allow_unknown = !!(le32_to_cpu(buf[1]) & ALLOW_UNKNOWN);
 
     if ( p->policyvers >= POLICYDB_VERSION_POLCAP &&
          ebitmap_read(&p->policycaps, fp) != 0 )
diff --git a/xen/xsm/flask/ss/policydb.h b/xen/xsm/flask/ss/policydb.h
index b176300..aeaf69b 100644
--- a/xen/xsm/flask/ss/policydb.h
+++ b/xen/xsm/flask/ss/policydb.h
@@ -245,6 +245,8 @@ struct policydb {
 
     unsigned int policyvers;
 
+    unsigned int allow_unknown : 1;
+
     u16 target_type;
 };
 
@@ -260,6 +262,10 @@ extern int policydb_read(struct policydb *p, void *fp);
 
 #define POLICYDB_CONFIG_MLS    1
 
+/* the config flags related to unknown classes/perms are bits 2 and 3 */
+#define REJECT_UNKNOWN 0x00000002
+#define ALLOW_UNKNOWN  0x00000004
+
 #define OBJECT_R "object_r"
 #define OBJECT_R_VAL 1
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index f0e459a..9b18509 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1464,6 +1464,11 @@ err:
 
 }
 
+int security_get_allow_unknown(void)
+{
+    return policydb.allow_unknown;
+}
+
 /**
  * security_irq_sid - Obtain the SID for a physical irq.
  * @pirq: physical irq
-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:10:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:10:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKZB-00089s-CP; Tue, 25 Nov 2014 18:10: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@citrix.com>) id 1XtKZA-00089e-Lh
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 18:10:20 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	35/72-28296-C06C4745; Tue, 25 Nov 2014 18:10:20 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416939017!9361405!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22347 invoked from network); 25 Nov 2014 18:10:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 18:10:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196680212"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 13:06:02 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtKJu-0008PT-R9;
	Tue, 25 Nov 2014 17:54:34 +0000
Date: Tue, 25 Nov 2014 17:54:30 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1411251745520.14135@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl_set_memory_target: retain the same maxmem
 offset on top of the current target
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In libxl_set_memory_target when setting the new maxmem, retain the same
offset on top of the current target. The offset includes memory
allocated by QEMU for rom files.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..8381c3e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4767,10 +4767,12 @@ retry_transaction:
                 "%s/memory/videoram", dompath));
     videoram = videoram_s ? atoi(videoram_s) : 0;
 
-    if (enforce) {
-        memorykb = new_target_memkb;
-        rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
-                LIBXL_MAXMEM_CONSTANT);
+    libxl_dominfo_init(&ptr);
+    xcinfo2xlinfo(ctx, &info, &ptr);
+
+    if (enforce && new_target_memkb > 0) {
+        memorykb = ptr.max_memkb - current_target_memkb + new_target_memkb;
+        rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb);
         if (rc != 0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
@@ -4800,8 +4802,6 @@ retry_transaction:
         goto out;
     }
 
-    libxl_dominfo_init(&ptr);
-    xcinfo2xlinfo(ctx, &info, &ptr);
     uuid = libxl__uuid2string(gc, ptr.uuid);
     libxl__xs_write(gc, t, libxl__sprintf(gc, "/vm/%s/memory", uuid),
             "%"PRIu32, new_target_memkb / 1024);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:10:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:10:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKZB-00089s-CP; Tue, 25 Nov 2014 18:10: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@citrix.com>) id 1XtKZA-00089e-Lh
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 18:10:20 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	35/72-28296-C06C4745; Tue, 25 Nov 2014 18:10:20 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416939017!9361405!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22347 invoked from network); 25 Nov 2014 18:10:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 18:10:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196680212"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Tue, 25 Nov 2014 13:06:02 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtKJu-0008PT-R9;
	Tue, 25 Nov 2014 17:54:34 +0000
Date: Tue, 25 Nov 2014 17:54:30 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1411251745520.14135@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl_set_memory_target: retain the same maxmem
 offset on top of the current target
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In libxl_set_memory_target when setting the new maxmem, retain the same
offset on top of the current target. The offset includes memory
allocated by QEMU for rom files.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..8381c3e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4767,10 +4767,12 @@ retry_transaction:
                 "%s/memory/videoram", dompath));
     videoram = videoram_s ? atoi(videoram_s) : 0;
 
-    if (enforce) {
-        memorykb = new_target_memkb;
-        rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
-                LIBXL_MAXMEM_CONSTANT);
+    libxl_dominfo_init(&ptr);
+    xcinfo2xlinfo(ctx, &info, &ptr);
+
+    if (enforce && new_target_memkb > 0) {
+        memorykb = ptr.max_memkb - current_target_memkb + new_target_memkb;
+        rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb);
         if (rc != 0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
@@ -4800,8 +4802,6 @@ retry_transaction:
         goto out;
     }
 
-    libxl_dominfo_init(&ptr);
-    xcinfo2xlinfo(ctx, &info, &ptr);
     uuid = libxl__uuid2string(gc, ptr.uuid);
     libxl__xs_write(gc, t, libxl__sprintf(gc, "/vm/%s/memory", uuid),
             "%"PRIu32, new_target_memkb / 1024);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:14:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:14:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKcp-0008Vb-9T; Tue, 25 Nov 2014 18:14:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtKcn-0008VV-BM
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:14:05 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	92/D5-25727-CE6C4745; Tue, 25 Nov 2014 18:14:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416939242!13806500!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32763 invoked from network); 25 Nov 2014 18:14:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 18:14:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196683303"
Message-ID: <5474C658.4030901@citrix.com>
Date: Tue, 25 Nov 2014 18:11:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
In-Reply-To: <5474C998020000780004AD1D@mail.emea.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/11/14 17:25, Jan Beulich wrote:
>>>> On 25.11.14 at 17:54, <andrew.cooper3@citrix.com> wrote:
>> This is RFC as there is still a niggle.  I tested this via a partial revert of
>> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
>> domain crash.  However, I am not sure we want to make any vmentry failure
>> quite, as any vmentry failure constitues a Xen bug.
> I think that double printing would be tolerable, but I've had yet
> another idea: Couldn't we make the second exception a #DF,
> thus having the guest killed via triple fault in the worst case at
> the third recurring failure (via hvm_combine_hw_exceptions())?

That still won't catch a large class of vmentry failures from bad host
state.  There needs to be some cutoff where we simply give up and crash
the domain.  In the end, this is just an exercise in how much we attempt
to recover in the case that we have already hit a hypervisor bug, and
can't be completely certain about any state.

Furthermore, guest userspace being able to exploit a Xen bug to result
in a triple fault is no better than an instant domain_crash(), from a
VMs point of view.  However, from a toolstacks point of view, it is even
worse, as malicious userspace could tie up toolstack resource in
domain_kill() and domain_create() (as a triple fault is modelled as a
clean reboot).

>
> Also your test results point out that we're delivering such an
> exception with wrong context to the guest: Machine state should
> match that before the results from the emulation got committed.
> But doing so would be a pretty significant change for almost no
> benefit.

Agreed, on both counts.

~Andrew



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:14:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:14:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKcp-0008Vb-9T; Tue, 25 Nov 2014 18:14:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtKcn-0008VV-BM
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:14:05 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	92/D5-25727-CE6C4745; Tue, 25 Nov 2014 18:14:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416939242!13806500!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32763 invoked from network); 25 Nov 2014 18:14:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 18:14:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196683303"
Message-ID: <5474C658.4030901@citrix.com>
Date: Tue, 25 Nov 2014 18:11:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
In-Reply-To: <5474C998020000780004AD1D@mail.emea.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/11/14 17:25, Jan Beulich wrote:
>>>> On 25.11.14 at 17:54, <andrew.cooper3@citrix.com> wrote:
>> This is RFC as there is still a niggle.  I tested this via a partial revert of
>> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
>> domain crash.  However, I am not sure we want to make any vmentry failure
>> quite, as any vmentry failure constitues a Xen bug.
> I think that double printing would be tolerable, but I've had yet
> another idea: Couldn't we make the second exception a #DF,
> thus having the guest killed via triple fault in the worst case at
> the third recurring failure (via hvm_combine_hw_exceptions())?

That still won't catch a large class of vmentry failures from bad host
state.  There needs to be some cutoff where we simply give up and crash
the domain.  In the end, this is just an exercise in how much we attempt
to recover in the case that we have already hit a hypervisor bug, and
can't be completely certain about any state.

Furthermore, guest userspace being able to exploit a Xen bug to result
in a triple fault is no better than an instant domain_crash(), from a
VMs point of view.  However, from a toolstacks point of view, it is even
worse, as malicious userspace could tie up toolstack resource in
domain_kill() and domain_create() (as a triple fault is modelled as a
clean reboot).

>
> Also your test results point out that we're delivering such an
> exception with wrong context to the guest: Machine state should
> match that before the results from the emulation got committed.
> But doing so would be a pretty significant change for almost no
> benefit.

Agreed, on both counts.

~Andrew



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:18:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18: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 1XtKgn-0000C2-Uy; Tue, 25 Nov 2014 18:18:13 +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 1XtKgm-0000Bx-Up
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:18:13 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	C5/7B-02712-4E7C4745; Tue, 25 Nov 2014 18:18:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416939490!10173183!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25727 invoked from network); 25 Nov 2014 18:18:11 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 18:18:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPIHm9r003629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 18:17:49 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPIHlMY022432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 18:17:48 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPIHlO5022421; Tue, 25 Nov 2014 18:17:47 GMT
Received: from laptop.dumpdata.com (/10.154.97.250)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 10:17:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D934B1196CB; Tue, 25 Nov 2014 13:17:46 -0500 (EST)
Date: Tue, 25 Nov 2014 13:17:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20141125181746.GB4005@laptop.dumpdata.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
	<547343F4.80509@citrix.com>
	<alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>
	<5473ABA2.6080901@tycho.nsa.gov>
	<CAFLBxZZFO+ms+TX4Gmchkb53CWL6EHeoGEcBKEgvMgx3AQaqvg@mail.gmail.com>
	<5474C476.3080203@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5474C476.3080203@tycho.nsa.gov>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <dunlapg@umich.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 01:03:34PM -0500, Daniel De Graaf wrote:
> On 11/25/2014 05:07 AM, George Dunlap wrote:
> >On Mon, Nov 24, 2014 at 10:05 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> >>>I do. The error is
> >>>(XEN) flask_domctl: Unknown op 72
> >>>
> >>>Incidentally, Flask is running in permissive mode.
> >>>
> >>>      Michael Young
> >>>
> >>
> >>This means that the new domctl needs to be added to the switch statement
> >>in flask/hooks.c.  This error is triggered in permissive mode because it
> >>is a code error rather than a policy error (which is what permissive mode
> >>is intended to debug).
> >
> >If that's the case, should we make that a BUG_ON()?  Or at least an
> >ASSERT() (which will only bug when compiled with debug=y), followed by
> >allow if in permissive mode, and deny if in enforcing mode?
> >
> >Having it default deny, even in permissive mode, breaks the "principle
> >of least surprise", I think. :-)
> >
> >  -George
> Either one of these will allow a guest to crash the hypervisor by requesting
> an undefined domctl, which is not really a good idea.  Linux uses a flag in
> the security policy which defines if unknown permissions are allowed or
> denied; I will send a patch adding this to Xen's security server and using
> it instead of -EPERM in the default case of the switch statements.

Thought I think that for the DEBUG case we want to still be boldly
told about it so we can fix it.
> 
> The patch adding this feature probably shouldn't be applied to 4.5, but I'll
> send it anyway.  I will also send a separate patch adding the 2 domctls.
> 
> -- 
> Daniel De Graaf
> National Security Agency
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 25 18:18:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18: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 1XtKgn-0000C2-Uy; Tue, 25 Nov 2014 18:18:13 +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 1XtKgm-0000Bx-Up
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:18:13 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	C5/7B-02712-4E7C4745; Tue, 25 Nov 2014 18:18:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1416939490!10173183!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25727 invoked from network); 25 Nov 2014 18:18:11 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 18:18:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPIHm9r003629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 18:17:49 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPIHlMY022432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 18:17:48 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPIHlO5022421; Tue, 25 Nov 2014 18:17:47 GMT
Received: from laptop.dumpdata.com (/10.154.97.250)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 10:17:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D934B1196CB; Tue, 25 Nov 2014 13:17:46 -0500 (EST)
Date: Tue, 25 Nov 2014 13:17:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20141125181746.GB4005@laptop.dumpdata.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<20141124124143.GA11483@zion.uk.xensource.com>
	<54732F8E.4060507@citrix.com>
	<alpine.GSO.2.00.1411241430180.1328@algedi.dur.ac.uk>
	<547343F4.80509@citrix.com>
	<alpine.DEB.2.00.1411242007460.17736@procyon.dur.ac.uk>
	<5473ABA2.6080901@tycho.nsa.gov>
	<CAFLBxZZFO+ms+TX4Gmchkb53CWL6EHeoGEcBKEgvMgx3AQaqvg@mail.gmail.com>
	<5474C476.3080203@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5474C476.3080203@tycho.nsa.gov>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <dunlapg@umich.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] (4.5-rc1) Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 01:03:34PM -0500, Daniel De Graaf wrote:
> On 11/25/2014 05:07 AM, George Dunlap wrote:
> >On Mon, Nov 24, 2014 at 10:05 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> >>>I do. The error is
> >>>(XEN) flask_domctl: Unknown op 72
> >>>
> >>>Incidentally, Flask is running in permissive mode.
> >>>
> >>>      Michael Young
> >>>
> >>
> >>This means that the new domctl needs to be added to the switch statement
> >>in flask/hooks.c.  This error is triggered in permissive mode because it
> >>is a code error rather than a policy error (which is what permissive mode
> >>is intended to debug).
> >
> >If that's the case, should we make that a BUG_ON()?  Or at least an
> >ASSERT() (which will only bug when compiled with debug=y), followed by
> >allow if in permissive mode, and deny if in enforcing mode?
> >
> >Having it default deny, even in permissive mode, breaks the "principle
> >of least surprise", I think. :-)
> >
> >  -George
> Either one of these will allow a guest to crash the hypervisor by requesting
> an undefined domctl, which is not really a good idea.  Linux uses a flag in
> the security policy which defines if unknown permissions are allowed or
> denied; I will send a patch adding this to Xen's security server and using
> it instead of -EPERM in the default case of the switch statements.

Thought I think that for the DEBUG case we want to still be boldly
told about it so we can fix it.
> 
> The patch adding this feature probably shouldn't be applied to 4.5, but I'll
> send it anyway.  I will also send a separate patch adding the 2 domctls.
> 
> -- 
> Daniel De Graaf
> National Security Agency
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 25 18:19:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18: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 1XtKhw-0000IO-Il; Tue, 25 Nov 2014 18:19:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtKhv-0000ID-CQ
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:19:23 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	21/55-25276-A28C4745; Tue, 25 Nov 2014 18:19:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416939558!15298561!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13538 invoked from network); 25 Nov 2014 18:19:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 18:19:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196686955"
Message-ID: <5474C819.5080303@citrix.com>
Date: Tue, 25 Nov 2014 18:19:05 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, <xen-devel@lists.xen.org>
References: <1416934664-17630-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1416934664-17630-1-git-send-email-dgdegra@tycho.nsa.gov>
X-DLP: MIA2
Cc: m.a.young@durham.ac.uk
Subject: Re: [Xen-devel] [PATCH for-4.5] xsm/flask: add two missing domctls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 16:57, Daniel De Graaf wrote:
> Reported-by: Michael Young <m.a.young@durham.ac.uk>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

CC'd Konrad, as this should be accepted into Xen-4.5.  Without it,
migration/suspend fails with -EPERM in the default case when XSM is
compiled into Xen.

Daniel: there are 4 hypercalls for getting/setting bits of PV VCPU state:

XEN_DOMCTL_{get,set}vcpucontext
XEN_DOMCTL_{get,set}_ext_vcpucontext
XEN_DOMCTL_{get,set}vcpuextstate
XEN_DOMCTL_{get,set}_vcpu_msrs

I see no reason for these to have separate access vectors; you typically
either need to use all of them, or none, but I presume it is too late to
coalesce the vectors in a backwards compatible way?

~Andrew

> ---
>  xen/xsm/flask/hooks.c               | 2 ++
>  xen/xsm/flask/policy/access_vectors | 2 ++
>  2 files changed, 4 insertions(+)
>
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 0ba2ce9..d48463f 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -672,9 +672,11 @@ static int flask_domctl(struct domain *d, int cmd)
>          return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
>  
>      case XEN_DOMCTL_set_ext_vcpucontext:
> +    case XEN_DOMCTL_set_vcpu_msrs:
>          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT);
>  
>      case XEN_DOMCTL_get_ext_vcpucontext:
> +    case XEN_DOMCTL_get_vcpu_msrs:
>          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT);
>  
>      case XEN_DOMCTL_setvcpuextstate:
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index 1cd451e..1da9f63 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -151,8 +151,10 @@ class domain
>  # XEN_DOMCTL_sendtrigger
>      trigger
>  # XEN_DOMCTL_get_ext_vcpucontext
> +# XEN_DOMCTL_set_vcpu_msrs
>      getextvcpucontext
>  # XEN_DOMCTL_set_ext_vcpucontext
> +# XEN_DOMCTL_get_vcpu_msrs
>      setextvcpucontext
>  # XEN_DOMCTL_getvcpuextstate
>      getvcpuextstate



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:19:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18: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 1XtKhw-0000IO-Il; Tue, 25 Nov 2014 18:19:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtKhv-0000ID-CQ
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:19:23 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	21/55-25276-A28C4745; Tue, 25 Nov 2014 18:19:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1416939558!15298561!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13538 invoked from network); 25 Nov 2014 18:19:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 18:19:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196686955"
Message-ID: <5474C819.5080303@citrix.com>
Date: Tue, 25 Nov 2014 18:19:05 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, <xen-devel@lists.xen.org>
References: <1416934664-17630-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1416934664-17630-1-git-send-email-dgdegra@tycho.nsa.gov>
X-DLP: MIA2
Cc: m.a.young@durham.ac.uk
Subject: Re: [Xen-devel] [PATCH for-4.5] xsm/flask: add two missing domctls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 16:57, Daniel De Graaf wrote:
> Reported-by: Michael Young <m.a.young@durham.ac.uk>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

CC'd Konrad, as this should be accepted into Xen-4.5.  Without it,
migration/suspend fails with -EPERM in the default case when XSM is
compiled into Xen.

Daniel: there are 4 hypercalls for getting/setting bits of PV VCPU state:

XEN_DOMCTL_{get,set}vcpucontext
XEN_DOMCTL_{get,set}_ext_vcpucontext
XEN_DOMCTL_{get,set}vcpuextstate
XEN_DOMCTL_{get,set}_vcpu_msrs

I see no reason for these to have separate access vectors; you typically
either need to use all of them, or none, but I presume it is too late to
coalesce the vectors in a backwards compatible way?

~Andrew

> ---
>  xen/xsm/flask/hooks.c               | 2 ++
>  xen/xsm/flask/policy/access_vectors | 2 ++
>  2 files changed, 4 insertions(+)
>
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 0ba2ce9..d48463f 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -672,9 +672,11 @@ static int flask_domctl(struct domain *d, int cmd)
>          return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
>  
>      case XEN_DOMCTL_set_ext_vcpucontext:
> +    case XEN_DOMCTL_set_vcpu_msrs:
>          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT);
>  
>      case XEN_DOMCTL_get_ext_vcpucontext:
> +    case XEN_DOMCTL_get_vcpu_msrs:
>          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT);
>  
>      case XEN_DOMCTL_setvcpuextstate:
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index 1cd451e..1da9f63 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -151,8 +151,10 @@ class domain
>  # XEN_DOMCTL_sendtrigger
>      trigger
>  # XEN_DOMCTL_get_ext_vcpucontext
> +# XEN_DOMCTL_set_vcpu_msrs
>      getextvcpucontext
>  # XEN_DOMCTL_set_ext_vcpucontext
> +# XEN_DOMCTL_get_vcpu_msrs
>      setextvcpucontext
>  # XEN_DOMCTL_getvcpuextstate
>      getvcpuextstate



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:21:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:21:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKk0-0000Qw-2u; Tue, 25 Nov 2014 18:21:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtKjy-0000Qr-Oq
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:21:30 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C7/22-09842-AA8C4745; Tue, 25 Nov 2014 18:21:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416939688!15285572!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12170 invoked from network); 25 Nov 2014 18:21:29 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 18:21:29 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPIL7HG004278
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 18:21:07 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPIL63q017859
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 18:21:07 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPIL64X004271; Tue, 25 Nov 2014 18:21:06 GMT
Received: from laptop.dumpdata.com (/10.154.97.250)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 10:21:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 16C071196EB; Tue, 25 Nov 2014 13:21:06 -0500 (EST)
Date: Tue, 25 Nov 2014 13:21:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141125182105.GA4171@laptop.dumpdata.com>
References: <1416934664-17630-1-git-send-email-dgdegra@tycho.nsa.gov>
	<5474C819.5080303@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5474C819.5080303@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, m.a.young@durham.ac.uk,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xsm/flask: add two missing domctls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 06:19:05PM +0000, Andrew Cooper wrote:
> On 25/11/14 16:57, Daniel De Graaf wrote:
> > Reported-by: Michael Young <m.a.young@durham.ac.uk>
> > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> CC'd Konrad, as this should be accepted into Xen-4.5.  Without it,
> migration/suspend fails with -EPERM in the default case when XSM is
> compiled into Xen.

Yup. Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Daniel: there are 4 hypercalls for getting/setting bits of PV VCPU state:
> 
> XEN_DOMCTL_{get,set}vcpucontext
> XEN_DOMCTL_{get,set}_ext_vcpucontext
> XEN_DOMCTL_{get,set}vcpuextstate
> XEN_DOMCTL_{get,set}_vcpu_msrs
> 
> I see no reason for these to have separate access vectors; you typically
> either need to use all of them, or none, but I presume it is too late to
> coalesce the vectors in a backwards compatible way?
> 
> ~Andrew
> 
> > ---
> >  xen/xsm/flask/hooks.c               | 2 ++
> >  xen/xsm/flask/policy/access_vectors | 2 ++
> >  2 files changed, 4 insertions(+)
> >
> > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> > index 0ba2ce9..d48463f 100644
> > --- a/xen/xsm/flask/hooks.c
> > +++ b/xen/xsm/flask/hooks.c
> > @@ -672,9 +672,11 @@ static int flask_domctl(struct domain *d, int cmd)
> >          return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
> >  
> >      case XEN_DOMCTL_set_ext_vcpucontext:
> > +    case XEN_DOMCTL_set_vcpu_msrs:
> >          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT);
> >  
> >      case XEN_DOMCTL_get_ext_vcpucontext:
> > +    case XEN_DOMCTL_get_vcpu_msrs:
> >          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT);
> >  
> >      case XEN_DOMCTL_setvcpuextstate:
> > diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> > index 1cd451e..1da9f63 100644
> > --- a/xen/xsm/flask/policy/access_vectors
> > +++ b/xen/xsm/flask/policy/access_vectors
> > @@ -151,8 +151,10 @@ class domain
> >  # XEN_DOMCTL_sendtrigger
> >      trigger
> >  # XEN_DOMCTL_get_ext_vcpucontext
> > +# XEN_DOMCTL_set_vcpu_msrs
> >      getextvcpucontext
> >  # XEN_DOMCTL_set_ext_vcpucontext
> > +# XEN_DOMCTL_get_vcpu_msrs
> >      setextvcpucontext
> >  # XEN_DOMCTL_getvcpuextstate
> >      getvcpuextstate
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:21:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:21:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKk0-0000Qw-2u; Tue, 25 Nov 2014 18:21:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtKjy-0000Qr-Oq
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 18:21:30 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C7/22-09842-AA8C4745; Tue, 25 Nov 2014 18:21:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416939688!15285572!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12170 invoked from network); 25 Nov 2014 18:21:29 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 18:21:29 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPIL7HG004278
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 18:21:07 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPIL63q017859
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 18:21:07 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPIL64X004271; Tue, 25 Nov 2014 18:21:06 GMT
Received: from laptop.dumpdata.com (/10.154.97.250)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 10:21:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 16C071196EB; Tue, 25 Nov 2014 13:21:06 -0500 (EST)
Date: Tue, 25 Nov 2014 13:21:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141125182105.GA4171@laptop.dumpdata.com>
References: <1416934664-17630-1-git-send-email-dgdegra@tycho.nsa.gov>
	<5474C819.5080303@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5474C819.5080303@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, m.a.young@durham.ac.uk,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xsm/flask: add two missing domctls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Nov 25, 2014 at 06:19:05PM +0000, Andrew Cooper wrote:
> On 25/11/14 16:57, Daniel De Graaf wrote:
> > Reported-by: Michael Young <m.a.young@durham.ac.uk>
> > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> CC'd Konrad, as this should be accepted into Xen-4.5.  Without it,
> migration/suspend fails with -EPERM in the default case when XSM is
> compiled into Xen.

Yup. Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Daniel: there are 4 hypercalls for getting/setting bits of PV VCPU state:
> 
> XEN_DOMCTL_{get,set}vcpucontext
> XEN_DOMCTL_{get,set}_ext_vcpucontext
> XEN_DOMCTL_{get,set}vcpuextstate
> XEN_DOMCTL_{get,set}_vcpu_msrs
> 
> I see no reason for these to have separate access vectors; you typically
> either need to use all of them, or none, but I presume it is too late to
> coalesce the vectors in a backwards compatible way?
> 
> ~Andrew
> 
> > ---
> >  xen/xsm/flask/hooks.c               | 2 ++
> >  xen/xsm/flask/policy/access_vectors | 2 ++
> >  2 files changed, 4 insertions(+)
> >
> > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> > index 0ba2ce9..d48463f 100644
> > --- a/xen/xsm/flask/hooks.c
> > +++ b/xen/xsm/flask/hooks.c
> > @@ -672,9 +672,11 @@ static int flask_domctl(struct domain *d, int cmd)
> >          return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
> >  
> >      case XEN_DOMCTL_set_ext_vcpucontext:
> > +    case XEN_DOMCTL_set_vcpu_msrs:
> >          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT);
> >  
> >      case XEN_DOMCTL_get_ext_vcpucontext:
> > +    case XEN_DOMCTL_get_vcpu_msrs:
> >          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT);
> >  
> >      case XEN_DOMCTL_setvcpuextstate:
> > diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> > index 1cd451e..1da9f63 100644
> > --- a/xen/xsm/flask/policy/access_vectors
> > +++ b/xen/xsm/flask/policy/access_vectors
> > @@ -151,8 +151,10 @@ class domain
> >  # XEN_DOMCTL_sendtrigger
> >      trigger
> >  # XEN_DOMCTL_get_ext_vcpucontext
> > +# XEN_DOMCTL_set_vcpu_msrs
> >      getextvcpucontext
> >  # XEN_DOMCTL_set_ext_vcpucontext
> > +# XEN_DOMCTL_get_vcpu_msrs
> >      setextvcpucontext
> >  # XEN_DOMCTL_getvcpuextstate
> >      getvcpuextstate
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:24:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKnD-0000pj-Gt; Tue, 25 Nov 2014 18:24:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtKnC-0000pX-Jv
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 18:24:50 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	1B/8C-08051-279C4745; Tue, 25 Nov 2014 18:24:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416939886!14783028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7012 invoked from network); 25 Nov 2014 18:24:49 -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;
	25 Nov 2014 18:24:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196689467"
Message-ID: <5474C96A.6090506@citrix.com>
Date: Tue, 25 Nov 2014 18:24:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<qemu-devel@nongnu.org>
References: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] increase maxmem before calling
	xc_domain_populate_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 25/11/14 17:45, Stefano Stabellini wrote:
> Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
> the risk of running out of guest memory. This way we can also avoid
> complex memory calculations in libxl at domain construction time.
>
> This patch fixes an abort() when assigning more than 4 NICs to a VM.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 5c69a8d..38e08c3 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -218,6 +218,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
>      unsigned long nr_pfn;
>      xen_pfn_t *pfn_list;
>      int i;
> +    xc_dominfo_t info;
>  
>      if (runstate_check(RUN_STATE_INMIGRATE)) {
>          /* RAM already populated in Xen */
> @@ -240,6 +241,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
>          pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
>      }
>  
> +    if (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) < 0) {

xc_domain_getinfo()'s interface is mad, and provides no guarantee that
it returns the information for the domain you requested.  It also won't
return -1 on error.  The correct error handing is:

(xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) || (info.domid !=
xen_domid)

~Andrew

> +        hw_error("xc_domain_getinfo failed");
> +    }
> +    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> +                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
> +        hw_error("xc_domain_setmaxmem failed");
> +    }
>      if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) {
>          hw_error("xen: failed to populate ram at " RAM_ADDR_FMT, ram_addr);
>      }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 25 18:24:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtKnD-0000pj-Gt; Tue, 25 Nov 2014 18:24:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtKnC-0000pX-Jv
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 18:24:50 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	1B/8C-08051-279C4745; Tue, 25 Nov 2014 18:24:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1416939886!14783028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7012 invoked from network); 25 Nov 2014 18:24:49 -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;
	25 Nov 2014 18:24:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="196689467"
Message-ID: <5474C96A.6090506@citrix.com>
Date: Tue, 25 Nov 2014 18:24:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<qemu-devel@nongnu.org>
References: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] increase maxmem before calling
	xc_domain_populate_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 25/11/14 17:45, Stefano Stabellini wrote:
> Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
> the risk of running out of guest memory. This way we can also avoid
> complex memory calculations in libxl at domain construction time.
>
> This patch fixes an abort() when assigning more than 4 NICs to a VM.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 5c69a8d..38e08c3 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -218,6 +218,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
>      unsigned long nr_pfn;
>      xen_pfn_t *pfn_list;
>      int i;
> +    xc_dominfo_t info;
>  
>      if (runstate_check(RUN_STATE_INMIGRATE)) {
>          /* RAM already populated in Xen */
> @@ -240,6 +241,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
>          pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
>      }
>  
> +    if (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) < 0) {

xc_domain_getinfo()'s interface is mad, and provides no guarantee that
it returns the information for the domain you requested.  It also won't
return -1 on error.  The correct error handing is:

(xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) || (info.domid !=
xen_domid)

~Andrew

> +        hw_error("xc_domain_getinfo failed");
> +    }
> +    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> +                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
> +        hw_error("xc_domain_setmaxmem failed");
> +    }
>      if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) {
>          hw_error("xen: failed to populate ram at " RAM_ADDR_FMT, ram_addr);
>      }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 25 18:39:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtL1W-0001hg-WB; Tue, 25 Nov 2014 18:39:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtL1V-0001ha-MX
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 18:39:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	72/D3-15461-9ECC4745; Tue, 25 Nov 2014 18:39:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416940774!7990541!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8875 invoked from network); 25 Nov 2014 18:39:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 18:39:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,457,1413244800"; d="scan'208";a="196319072"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 13:22:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtKlE-00042i-Km;
	Tue, 25 Nov 2014 18:22:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtKlE-0000eG-B9;
	Tue, 25 Nov 2014 18:22:48 +0000
Date: Tue, 25 Nov 2014 18:22:48 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31851-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31851: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31851 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31851/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0
baseline version:
 rumpuserxen          cdb4bff22f578ceb0731db509274133d99c1f4f5

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0
+ branch=rumpuserxen
+ revision=a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   cdb4bff..a2fc4f9  a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 18:39:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 18:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtL1W-0001hg-WB; Tue, 25 Nov 2014 18:39:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtL1V-0001ha-MX
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 18:39:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	72/D3-15461-9ECC4745; Tue, 25 Nov 2014 18:39:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1416940774!7990541!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8875 invoked from network); 25 Nov 2014 18:39:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 18:39:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,457,1413244800"; d="scan'208";a="196319072"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 13:22:49 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtKlE-00042i-Km;
	Tue, 25 Nov 2014 18:22:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtKlE-0000eG-B9;
	Tue, 25 Nov 2014 18:22:48 +0000
Date: Tue, 25 Nov 2014 18:22:48 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31851-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31851: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31851 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31851/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0
baseline version:
 rumpuserxen          cdb4bff22f578ceb0731db509274133d99c1f4f5

------------------------------------------------------------
People who touched revisions under test:
  Martin Lucina <martin@lucina.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0
+ branch=rumpuserxen
+ revision=a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   cdb4bff..a2fc4f9  a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 19:38:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 19: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 1XtLwC-0002g2-RX; Tue, 25 Nov 2014 19:38:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XtLwA-0002fx-RF
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 19:38:10 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	BB/FE-28865-1AAD4745; Tue, 25 Nov 2014 19:38:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416944288!13370318!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25363 invoked from network); 25 Nov 2014 19:38:09 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-7.tower-206.messagelabs.com with SMTP;
	25 Nov 2014 19:38:09 -0000
X-TM-IMSS-Message-ID: <575fdafe00028e53@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 575fdafe00028e53 ;
	Tue, 25 Nov 2014 14:37:50 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAPJbTaD013046; 
	Tue, 25 Nov 2014 14:37:40 -0500
Message-ID: <5474D99D.6080709@tycho.nsa.gov>
Date: Tue, 25 Nov 2014 14:33:49 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
References: <1416934664-17630-1-git-send-email-dgdegra@tycho.nsa.gov>
	<5474C819.5080303@citrix.com>
In-Reply-To: <5474C819.5080303@citrix.com>
Cc: m.a.young@durham.ac.uk
Subject: Re: [Xen-devel] [PATCH for-4.5] xsm/flask: add two missing domctls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 01:19 PM, Andrew Cooper wrote:
> On 25/11/14 16:57, Daniel De Graaf wrote:
>> Reported-by: Michael Young <m.a.young@durham.ac.uk>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
> CC'd Konrad, as this should be accepted into Xen-4.5.  Without it,
> migration/suspend fails with -EPERM in the default case when XSM is
> compiled into Xen.

Thanks, for some reason I blanked on the CC for the freeze exception.

> Daniel: there are 4 hypercalls for getting/setting bits of PV VCPU state:
>
> XEN_DOMCTL_{get,set}vcpucontext
> XEN_DOMCTL_{get,set}_ext_vcpucontext
> XEN_DOMCTL_{get,set}vcpuextstate
> XEN_DOMCTL_{get,set}_vcpu_msrs
>
> I see no reason for these to have separate access vectors; you typically
> either need to use all of them, or none, but I presume it is too late to
> coalesce the vectors in a backwards compatible way?
>
> ~Andrew

Because the security policy in Xen is kept inside the tree, it is
possible to change them in the future - though this is certainly a topic
for v4.6.  This will cause anyone who has defined their own security
policy to need to modify it, but this is already true when new
permissions are being defined, and it is easier to remove permissions
(just fix the policy compile error) than it is to add them (which either
requires thought on who needs to be allowed access to a permission or
testing to discover the AVC denials).  If a custom policy is using the
macros defined in xen.if, these changes will be applied transparently.

I agree combining these four domctls into a single pair of permissions
is useful (retaining the get/set split); I cannot think of any case
where someone might have a use for one type of CPU/register state and at
the same time cannot be trusted with the others.  This would also
simplify future additions of new types of CPU state.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 19:38:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 19: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 1XtLwC-0002g2-RX; Tue, 25 Nov 2014 19:38:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XtLwA-0002fx-RF
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 19:38:10 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	BB/FE-28865-1AAD4745; Tue, 25 Nov 2014 19:38:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416944288!13370318!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25363 invoked from network); 25 Nov 2014 19:38:09 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-7.tower-206.messagelabs.com with SMTP;
	25 Nov 2014 19:38:09 -0000
X-TM-IMSS-Message-ID: <575fdafe00028e53@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.242.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 575fdafe00028e53 ;
	Tue, 25 Nov 2014 14:37:50 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sAPJbTaD013046; 
	Tue, 25 Nov 2014 14:37:40 -0500
Message-ID: <5474D99D.6080709@tycho.nsa.gov>
Date: Tue, 25 Nov 2014 14:33:49 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
References: <1416934664-17630-1-git-send-email-dgdegra@tycho.nsa.gov>
	<5474C819.5080303@citrix.com>
In-Reply-To: <5474C819.5080303@citrix.com>
Cc: m.a.young@durham.ac.uk
Subject: Re: [Xen-devel] [PATCH for-4.5] xsm/flask: add two missing domctls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 01:19 PM, Andrew Cooper wrote:
> On 25/11/14 16:57, Daniel De Graaf wrote:
>> Reported-by: Michael Young <m.a.young@durham.ac.uk>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
> CC'd Konrad, as this should be accepted into Xen-4.5.  Without it,
> migration/suspend fails with -EPERM in the default case when XSM is
> compiled into Xen.

Thanks, for some reason I blanked on the CC for the freeze exception.

> Daniel: there are 4 hypercalls for getting/setting bits of PV VCPU state:
>
> XEN_DOMCTL_{get,set}vcpucontext
> XEN_DOMCTL_{get,set}_ext_vcpucontext
> XEN_DOMCTL_{get,set}vcpuextstate
> XEN_DOMCTL_{get,set}_vcpu_msrs
>
> I see no reason for these to have separate access vectors; you typically
> either need to use all of them, or none, but I presume it is too late to
> coalesce the vectors in a backwards compatible way?
>
> ~Andrew

Because the security policy in Xen is kept inside the tree, it is
possible to change them in the future - though this is certainly a topic
for v4.6.  This will cause anyone who has defined their own security
policy to need to modify it, but this is already true when new
permissions are being defined, and it is easier to remove permissions
(just fix the policy compile error) than it is to add them (which either
requires thought on who needs to be allowed access to a permission or
testing to discover the AVC denials).  If a custom policy is using the
macros defined in xen.if, these changes will be applied transparently.

I agree combining these four domctls into a single pair of permissions
is useful (retaining the get/set split); I cannot think of any case
where someone might have a use for one type of CPU/register state and at
the same time cannot be trusted with the others.  This would also
simplify future additions of new types of CPU state.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 19:46:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 19:46:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtM4R-0002wR-Sl; Tue, 25 Nov 2014 19:46:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtM4Q-0002wK-F2
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 19:46:42 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	24/3B-27623-1ACD4745; Tue, 25 Nov 2014 19:46:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416944798!13819826!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1323 invoked from network); 25 Nov 2014 19:46:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 19:46:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,457,1413244800"; d="scan'208";a="196730023"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 14:46:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtM4H-0004S7-Ut;
	Tue, 25 Nov 2014 19:46:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtM4H-0006To-Oe;
	Tue, 25 Nov 2014 19:46:33 +0000
Date: Tue, 25 Nov 2014 19:46:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31848-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31848: 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 31848 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31848/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu  5 xen-boot                    fail pass in 31820
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install       fail pass in 31729
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot        fail in 31820 pass in 31848
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10 fail in 31729 pass in 31848
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 31729 pass in 31848

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail like 31846-bisect

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop      fail in 31729 never pass

version targeted for testing:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a
baseline version:
 qemuu                0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51

------------------------------------------------------------
People who touched revisions under test:
  Don Slutz <dslutz@verizon.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=a230ec3101ddda868252c036ea960af2b2d6cd5a
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable a230ec3101ddda868252c036ea960af2b2d6cd5a
+ branch=qemu-upstream-unstable
+ revision=a230ec3101ddda868252c036ea960af2b2d6cd5a
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : 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
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git a230ec3101ddda868252c036ea960af2b2d6cd5a:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
   0c94ca5..a230ec3  a230ec3101ddda868252c036ea960af2b2d6cd5a -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 19:46:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 19:46:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtM4R-0002wR-Sl; Tue, 25 Nov 2014 19:46:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtM4Q-0002wK-F2
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 19:46:42 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	24/3B-27623-1ACD4745; Tue, 25 Nov 2014 19:46:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1416944798!13819826!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1323 invoked from network); 25 Nov 2014 19:46:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 19:46:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,457,1413244800"; d="scan'208";a="196730023"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 14:46:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtM4H-0004S7-Ut;
	Tue, 25 Nov 2014 19:46:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtM4H-0006To-Oe;
	Tue, 25 Nov 2014 19:46:33 +0000
Date: Tue, 25 Nov 2014 19:46:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31848-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 31848: 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 31848 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31848/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu  5 xen-boot                    fail pass in 31820
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install       fail pass in 31729
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot        fail in 31820 pass in 31848
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10 fail in 31729 pass in 31848
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 31729 pass in 31848

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail like 31846-bisect

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop      fail in 31729 never pass

version targeted for testing:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a
baseline version:
 qemuu                0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51

------------------------------------------------------------
People who touched revisions under test:
  Don Slutz <dslutz@verizon.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=a230ec3101ddda868252c036ea960af2b2d6cd5a
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable a230ec3101ddda868252c036ea960af2b2d6cd5a
+ branch=qemu-upstream-unstable
+ revision=a230ec3101ddda868252c036ea960af2b2d6cd5a
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : daily-cron.qemu-upstream-unstable
++ : 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
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git a230ec3101ddda868252c036ea960af2b2d6cd5a:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
   0c94ca5..a230ec3  a230ec3101ddda868252c036ea960af2b2d6cd5a -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 20:12:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 20:12:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtMSp-0003Q5-Ep; Tue, 25 Nov 2014 20:11:55 +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 1XtMSn-0003Q0-Gk
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 20:11:53 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	12/93-14727-882E4745; Tue, 25 Nov 2014 20:11:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416946309!13324343!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10239 invoked from network); 25 Nov 2014 20:11:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 20:11:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,457,1413244800"; d="scan'208";a="196370855"
Message-ID: <5474DE5A.2060000@citrix.com>
Date: Tue, 25 Nov 2014 19:54:02 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: [Xen-devel] [Planning for Xen-4.6] Migration 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

Hello,

The purpose of this email is to plan how to progress the migrationv2
series through to being merged.  I believe I have CC'd everyone with a
specific interest in this area, but apologies if I have missed anyone.

Migration v2 is in exclusive use in XenServer 6.5.  We primarily
developed migration v2 because we needed a 32bit -> 64bit toolstack
upgrade path.  The code has all the features XenServer previously
supported, and we consider it fully baked and without any known bugs,
including transparent legacy-to-v2 conversion on upgrade.

We did endeavour to get migration v2 into Xen 4.5, but regrettably this
did not happen.  A consequence of this, along with the code being in
XenServer 6.5, is that the wire format is now set in stone.  Luckily, it
has been explicitly designed to be easy to extend in a forward
compatible manor, so this is not a problem moving forward.

The expectation is that the migration v2 code will completely replace
the existing migration code, which will involve removing
xc_domain_save.c and xc_domain_restore.c, as well as assorted other
orphaned code in libxenctrl and libxenguest

There are 3 areas of concern which have been identified so far.

1) TMEM support

Migration v2 doesn't currently have any tmem migration support.  The
maintainers have been asked whether they actually expect legacy tmem
migration to work, but I have not heard any reply yet.  At the very
least, migration v2 tmem support would want some new thought put into
wire protocol.  I am hoping that, as TMEM is still tech preview and
still in the process of having XSA-15 fixed, working tmem migration v2
is not insisted as a prerequisite.

2) Remus/COLO support

Migration v2 doesn't currently have any Remus support.  There was a
draft series which added Remus support, and showed that it was
particularly simple to add Remus support to migration v2.  I integrated
several bugfixes as a side effect of that series, but the actual Remus
content needed a refresh.  This got delayed behind the Remus libxl
effort.  It is my hope that the Remus maintainers can refresh that
series and provide assistance while testing.

3) Libxl and xl support

Libxl and xl have as many problems as the libxc code did when it comes
to incompatible wire formats and layering violations.  In particular, it
is not possible to determine the bitness of the sending
libxl-saverestore-helper, meaning that legacy conversion requires active
administrator input, or at least a passive assumption that the bitness
is the same.

There is an xl/libxl part of the migration v2 series which attempts to
rectify this all in one go, as there is no alternative way of doing so. 
The libxl section of the series is certainly not yet complete, but
specific queries to the maintainers have thusfar gone unanswered.  On
the other hand, the series does basically WorkForMe, including
transparent legacy upgrade, suggesting that it is at least in an
appropriate ballpark.


*) Specific non-requirements:

There have been issues identified with dynamic (in a p2m sense) guests
and migration, which results in failed migration or image corruption. 
While these issues certainly want fixing, they are bugs which exist in
the legacy code.  As such, they are not prerequisites to fix before v2
can be accepted.


Anyway, it is my hope that this planning email can help get things on
track to start perusing active development again as soon as the 4.6 dev
window opens again, with the aim to get all the code merged as early as
possible in the dev window to allow as much testing as possible.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 20:12:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 20:12:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtMSp-0003Q5-Ep; Tue, 25 Nov 2014 20:11:55 +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 1XtMSn-0003Q0-Gk
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 20:11:53 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	12/93-14727-882E4745; Tue, 25 Nov 2014 20:11:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1416946309!13324343!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10239 invoked from network); 25 Nov 2014 20:11:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 20:11:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,457,1413244800"; d="scan'208";a="196370855"
Message-ID: <5474DE5A.2060000@citrix.com>
Date: Tue, 25 Nov 2014 19:54:02 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: [Xen-devel] [Planning for Xen-4.6] Migration 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

Hello,

The purpose of this email is to plan how to progress the migrationv2
series through to being merged.  I believe I have CC'd everyone with a
specific interest in this area, but apologies if I have missed anyone.

Migration v2 is in exclusive use in XenServer 6.5.  We primarily
developed migration v2 because we needed a 32bit -> 64bit toolstack
upgrade path.  The code has all the features XenServer previously
supported, and we consider it fully baked and without any known bugs,
including transparent legacy-to-v2 conversion on upgrade.

We did endeavour to get migration v2 into Xen 4.5, but regrettably this
did not happen.  A consequence of this, along with the code being in
XenServer 6.5, is that the wire format is now set in stone.  Luckily, it
has been explicitly designed to be easy to extend in a forward
compatible manor, so this is not a problem moving forward.

The expectation is that the migration v2 code will completely replace
the existing migration code, which will involve removing
xc_domain_save.c and xc_domain_restore.c, as well as assorted other
orphaned code in libxenctrl and libxenguest

There are 3 areas of concern which have been identified so far.

1) TMEM support

Migration v2 doesn't currently have any tmem migration support.  The
maintainers have been asked whether they actually expect legacy tmem
migration to work, but I have not heard any reply yet.  At the very
least, migration v2 tmem support would want some new thought put into
wire protocol.  I am hoping that, as TMEM is still tech preview and
still in the process of having XSA-15 fixed, working tmem migration v2
is not insisted as a prerequisite.

2) Remus/COLO support

Migration v2 doesn't currently have any Remus support.  There was a
draft series which added Remus support, and showed that it was
particularly simple to add Remus support to migration v2.  I integrated
several bugfixes as a side effect of that series, but the actual Remus
content needed a refresh.  This got delayed behind the Remus libxl
effort.  It is my hope that the Remus maintainers can refresh that
series and provide assistance while testing.

3) Libxl and xl support

Libxl and xl have as many problems as the libxc code did when it comes
to incompatible wire formats and layering violations.  In particular, it
is not possible to determine the bitness of the sending
libxl-saverestore-helper, meaning that legacy conversion requires active
administrator input, or at least a passive assumption that the bitness
is the same.

There is an xl/libxl part of the migration v2 series which attempts to
rectify this all in one go, as there is no alternative way of doing so. 
The libxl section of the series is certainly not yet complete, but
specific queries to the maintainers have thusfar gone unanswered.  On
the other hand, the series does basically WorkForMe, including
transparent legacy upgrade, suggesting that it is at least in an
appropriate ballpark.


*) Specific non-requirements:

There have been issues identified with dynamic (in a p2m sense) guests
and migration, which results in failed migration or image corruption. 
While these issues certainly want fixing, they are bugs which exist in
the legacy code.  As such, they are not prerequisites to fix before v2
can be accepted.


Anyway, it is my hope that this planning email can help get things on
track to start perusing active development again as soon as the 4.6 dev
window opens again, with the aim to get all the code merged as early as
possible in the dev window to allow as much testing as possible.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 20:20:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 20:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtMbL-0003eZ-FM; Tue, 25 Nov 2014 20:20:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtMbJ-0003eU-4B
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 20:20:41 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	0D/D0-02712-894E4745; Tue, 25 Nov 2014 20:20:40 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416946837!14821658!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19524 invoked from network); 25 Nov 2014 20:20:39 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 20:20:39 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPKKPKx026379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 20:20:26 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPKKP14026212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 20:20:25 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPKKPda023029; Tue, 25 Nov 2014 20:20:25 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 12:20:24 -0800
Message-ID: <5474E537.7010707@oracle.com>
Date: Tue, 25 Nov 2014 15:23:19 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xenproject.org>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	programme110@gmail.com, David Vrabel <david.vrabel@citrix.com>,
	davem@davemloft.net
Subject: [Xen-devel] Regression in netfilter code under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We have a regression due to (5195c14c8: netfilter: conntrack: fix race 
in __nf_conntrack_confirm against get_next_corpse). I have not been able 
to reproduce this on baremetal but dom0 crashes reliably after a few 
seconds of idle time. This doesn't appear to be dependent on Xen version 
--- I saw it on at least a 4.2 and unstable).

I don't know much about networking (and will be out for most of the rest 
of the week) so I wonder whether anyone has any ideas. The stack is below.


Thanks.
-boris

# 
[ 
54.901368] general protection fault: 0000 [#1] SMP
[   54.919324] Modules linked in: dm_multipath dm_mod xen_evtchn 
iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport 
libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod i915 fbcon 
tileblit font bitblit softcursor tpm_tis ahci libahci libata 
drm_kms_helper video scsi_mod e1000e wmi xen_blkfront xen_netfront 
fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd
[   54.996767] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
3.18.0-rc5upstream-00179-g8a84e01 #1
[   55.016730] Hardware name: LENOVO ThinkServer TS130/        , BIOS 
9HKT47AUS 01/10/2012
[   55.036873] task: ffff880037e48a10 ti: ffff880037e54000 task.ti: 
ffff880037e54000
[   55.057338] RIP: e030:[<ffffffff815ea29e>] [<ffffffff815ea29e>] 
nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
[   55.[   55.099069] RAX: dead000000200200 RBX: ffffe8ffffc89108 RCX: 
ffffffff81cc5820
[   55.119918] RDX: 0000000080000001 RSI: 0000000000000011 RDI: 
ffffe8ffffc89108
[   55.140768] RBP: ffff88003e283908 R08: 00000000c5f889ff R09: 
00000000a1a10f28
[   55.161785] R10: ffff880037e5f1b8 R11: 0000000000000001 R12: 
ffff880037e5f148
[   55.183005] R13: ffffffff815e6a6b R14: ffff88002bed8400 R15: 
ffff88002bb30000
[   55.204214] FS:  00007f668f694700(0000) GS[   55.225733] CS: e033 
DS: 002b ES: 002b CR0: 0000000080050033
[   55.247220] CR2: 00007f66c0a598eb CR3: 000000002bc39000 CR4: 
0000000000042660
[   55.268863] Stack:
[   55.290200]  ffff880037e5f148 ffffffff81c98080 ffff88003e283928 
ffffffff815eb59d
[   55.312068]  ffff88002bed8400 ffff88002bed8400 ffff88003e283938 
ffffffff815e689a
[   55.333849]  ffff88003e283958 ffffffff815a37a5 ffff88003e283968 
ffff88002bed8400
[   55.355449] Call Trace:
[   55.376552]  <IRQ>
[   55.376728]  [<ffffffff815eb59d>] destroy_conntrack+0x5d/0xc0
[   55.418187]  [<ffffffff815e689a>] nf_conntrack_destroy+0x1a/0x40
[   55.439349]  [<ffffffff815a37a5>] skb_release_head_state+0x85/0xd0
[   55.460468]  [<ffffffff815a5d61>] skb_release_all+0x11/0x30
[   55.481440]  [<ffffffff815a5dd1>] __kfree_skb+0x11/0xc0
[   55.502239]  [<ffffffff815a5f78>] kfree_skb+0x38/0xa0
[   55.522661]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
[   55.542811]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
[   55.562543]  [<ffffffff815e6a6b>] nf_hook_slow+0x10b/0x120
[   55.582100]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
[   55.601470]  [<ffffffff8170a02b>] ? _raw_spin_unlock_irqrestore+0[   
55.620900] [<ffffffff81604713>] ip_local_deliver+0x73/0x80
[   55.640154]  [<ffffffff81603dc9>] ip_rcv_finish+0x109/0x310
[   55.659244]  [<ffffffff8160439c>] ip_rcv+0x28c/0x3a0
[   55.678287]  [<ffffffff815b69ae>] 
__netif_receive_skb_core+0x58e/0x[   55.697287] [<ffffffff815b6b4d>] 
__netif_receive_skb+0x1d/0x70
[   55.715820]  [<ffffffff815b6d9e>] netif_receive_skb_internal+0x1e/0xb0
[   55.734442]  [<ffffffff815b6e47>] netif_receive_skb+0x17/0x70
[   55.752898]  [<ffffffff816c17e2>] br_handle_frame_finish+0x192/0x360
[   55.771709]  [<ffffffff816c156d>] br_handle_frame+0
[   55.790274]  [<ffffffff816c13f0>] ? br_handle_local_finish+0x40/0x40
[   55.808760]  [<ffffffff815b65f7>] __netif_receive_skb_core+0x1d7/0x710
[   55.827302]  [<ffffffff815b6b4d>] __netif_receive_skb+0x1d/0x70
[   55.845594]  [<ffffffff815b6d9e>] netif_receive_skb_internal+0x1e/0xb0
[   55.863836]  [<ffffffff815b7a38>] napi_gro_receive+0x118/0x1a0
[   55.881549]  [<ffffffff814c430f>] tg3_poll_work+0xe1f/0x1[   
55.898629]  [<ffffffff814d75c9>] tg3_poll+0x69/0x3c0
[   55.915010]  [<ffffffff815b7523>] net_rx_action+0x103/0x290
[   55.930840]  [<ffffffff810a7713>] __do_softirq+0xf3/0x2e0
[   55.946310]  [<ffffffff810a7a2d>] irq_exit+0xcd/0xe0
[   55.961399]  [<ffffffff8140d4c7>] xen_evtchn_do_upcall+0x37/0x50
766]  [<ffffffff8170c1fe>] xen_do_hypervisor_callback+0x1e/0x30
[   55.990802]  <EOI>
[   55.990977]  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
[   56.018897]  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
[   56.032815]  [<ffffffff810454b0>] ? xen_safe_halt+0x10/0x20
[   56.046583]  [<ffffffff81059e3a>] ? default_idle+0x1a/0xd0
[   56.060307]  [<ffffffff8105950a>] ? arch_cpu_idle+0xa/0x10
[   56.073920]  [<ffffffff810de483>] ? cpu_startup_entry+0x2d3/0[   
56.100421]  [<ffffffff8104c355>] ? cpu_bringup_and_idle+0x25/0x40
[   56.113427] Code: 98 08 08 00 00 0f b7 47 08 48 03 1c c5 a0 42 cc 81 
48 89 df e8 94 fc 11 00 49 8b 44 24 18 48 85 c0 74 2d 49[   
56.141507] RIP  [<ffffffff815ea29e>] 
nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
[   56.155425]  RSP <ffff88003e2838f8>
[   56.169234] ---[ end trace 4c64578e4c629cc4 ]---
[   56.182913] Kernel panic - not syncing: Fatal exception in interrupt
[   56.197026] Kernel Offset: 0x0 from 0xffffffff81000k  text console
(XEN) [2014-11-23 06:05:48] Domain 0 crashed: rebooting machine in 5 
seconds.
(XEN) [2014-11-23 06:05:53] Resetting with ACPI MEMORY or I/O RESET_REG.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 20:20:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 20:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtMbL-0003eZ-FM; Tue, 25 Nov 2014 20:20:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtMbJ-0003eU-4B
	for xen-devel@lists.xenproject.org; Tue, 25 Nov 2014 20:20:41 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	0D/D0-02712-894E4745; Tue, 25 Nov 2014 20:20:40 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1416946837!14821658!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19524 invoked from network); 25 Nov 2014 20:20:39 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 20:20:39 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAPKKPKx026379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Nov 2014 20:20:26 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPKKP14026212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 25 Nov 2014 20:20:25 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
	by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAPKKPda023029; Tue, 25 Nov 2014 20:20:25 GMT
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Nov 2014 12:20:24 -0800
Message-ID: <5474E537.7010707@oracle.com>
Date: Tue, 25 Nov 2014 15:23:19 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xenproject.org>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	programme110@gmail.com, David Vrabel <david.vrabel@citrix.com>,
	davem@davemloft.net
Subject: [Xen-devel] Regression in netfilter code under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We have a regression due to (5195c14c8: netfilter: conntrack: fix race 
in __nf_conntrack_confirm against get_next_corpse). I have not been able 
to reproduce this on baremetal but dom0 crashes reliably after a few 
seconds of idle time. This doesn't appear to be dependent on Xen version 
--- I saw it on at least a 4.2 and unstable).

I don't know much about networking (and will be out for most of the rest 
of the week) so I wonder whether anyone has any ideas. The stack is below.


Thanks.
-boris

# 
[ 
54.901368] general protection fault: 0000 [#1] SMP
[   54.919324] Modules linked in: dm_multipath dm_mod xen_evtchn 
iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport 
libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod i915 fbcon 
tileblit font bitblit softcursor tpm_tis ahci libahci libata 
drm_kms_helper video scsi_mod e1000e wmi xen_blkfront xen_netfront 
fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd
[   54.996767] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
3.18.0-rc5upstream-00179-g8a84e01 #1
[   55.016730] Hardware name: LENOVO ThinkServer TS130/        , BIOS 
9HKT47AUS 01/10/2012
[   55.036873] task: ffff880037e48a10 ti: ffff880037e54000 task.ti: 
ffff880037e54000
[   55.057338] RIP: e030:[<ffffffff815ea29e>] [<ffffffff815ea29e>] 
nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
[   55.[   55.099069] RAX: dead000000200200 RBX: ffffe8ffffc89108 RCX: 
ffffffff81cc5820
[   55.119918] RDX: 0000000080000001 RSI: 0000000000000011 RDI: 
ffffe8ffffc89108
[   55.140768] RBP: ffff88003e283908 R08: 00000000c5f889ff R09: 
00000000a1a10f28
[   55.161785] R10: ffff880037e5f1b8 R11: 0000000000000001 R12: 
ffff880037e5f148
[   55.183005] R13: ffffffff815e6a6b R14: ffff88002bed8400 R15: 
ffff88002bb30000
[   55.204214] FS:  00007f668f694700(0000) GS[   55.225733] CS: e033 
DS: 002b ES: 002b CR0: 0000000080050033
[   55.247220] CR2: 00007f66c0a598eb CR3: 000000002bc39000 CR4: 
0000000000042660
[   55.268863] Stack:
[   55.290200]  ffff880037e5f148 ffffffff81c98080 ffff88003e283928 
ffffffff815eb59d
[   55.312068]  ffff88002bed8400 ffff88002bed8400 ffff88003e283938 
ffffffff815e689a
[   55.333849]  ffff88003e283958 ffffffff815a37a5 ffff88003e283968 
ffff88002bed8400
[   55.355449] Call Trace:
[   55.376552]  <IRQ>
[   55.376728]  [<ffffffff815eb59d>] destroy_conntrack+0x5d/0xc0
[   55.418187]  [<ffffffff815e689a>] nf_conntrack_destroy+0x1a/0x40
[   55.439349]  [<ffffffff815a37a5>] skb_release_head_state+0x85/0xd0
[   55.460468]  [<ffffffff815a5d61>] skb_release_all+0x11/0x30
[   55.481440]  [<ffffffff815a5dd1>] __kfree_skb+0x11/0xc0
[   55.502239]  [<ffffffff815a5f78>] kfree_skb+0x38/0xa0
[   55.522661]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
[   55.542811]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
[   55.562543]  [<ffffffff815e6a6b>] nf_hook_slow+0x10b/0x120
[   55.582100]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
[   55.601470]  [<ffffffff8170a02b>] ? _raw_spin_unlock_irqrestore+0[   
55.620900] [<ffffffff81604713>] ip_local_deliver+0x73/0x80
[   55.640154]  [<ffffffff81603dc9>] ip_rcv_finish+0x109/0x310
[   55.659244]  [<ffffffff8160439c>] ip_rcv+0x28c/0x3a0
[   55.678287]  [<ffffffff815b69ae>] 
__netif_receive_skb_core+0x58e/0x[   55.697287] [<ffffffff815b6b4d>] 
__netif_receive_skb+0x1d/0x70
[   55.715820]  [<ffffffff815b6d9e>] netif_receive_skb_internal+0x1e/0xb0
[   55.734442]  [<ffffffff815b6e47>] netif_receive_skb+0x17/0x70
[   55.752898]  [<ffffffff816c17e2>] br_handle_frame_finish+0x192/0x360
[   55.771709]  [<ffffffff816c156d>] br_handle_frame+0
[   55.790274]  [<ffffffff816c13f0>] ? br_handle_local_finish+0x40/0x40
[   55.808760]  [<ffffffff815b65f7>] __netif_receive_skb_core+0x1d7/0x710
[   55.827302]  [<ffffffff815b6b4d>] __netif_receive_skb+0x1d/0x70
[   55.845594]  [<ffffffff815b6d9e>] netif_receive_skb_internal+0x1e/0xb0
[   55.863836]  [<ffffffff815b7a38>] napi_gro_receive+0x118/0x1a0
[   55.881549]  [<ffffffff814c430f>] tg3_poll_work+0xe1f/0x1[   
55.898629]  [<ffffffff814d75c9>] tg3_poll+0x69/0x3c0
[   55.915010]  [<ffffffff815b7523>] net_rx_action+0x103/0x290
[   55.930840]  [<ffffffff810a7713>] __do_softirq+0xf3/0x2e0
[   55.946310]  [<ffffffff810a7a2d>] irq_exit+0xcd/0xe0
[   55.961399]  [<ffffffff8140d4c7>] xen_evtchn_do_upcall+0x37/0x50
766]  [<ffffffff8170c1fe>] xen_do_hypervisor_callback+0x1e/0x30
[   55.990802]  <EOI>
[   55.990977]  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
[   56.018897]  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
[   56.032815]  [<ffffffff810454b0>] ? xen_safe_halt+0x10/0x20
[   56.046583]  [<ffffffff81059e3a>] ? default_idle+0x1a/0xd0
[   56.060307]  [<ffffffff8105950a>] ? arch_cpu_idle+0xa/0x10
[   56.073920]  [<ffffffff810de483>] ? cpu_startup_entry+0x2d3/0[   
56.100421]  [<ffffffff8104c355>] ? cpu_bringup_and_idle+0x25/0x40
[   56.113427] Code: 98 08 08 00 00 0f b7 47 08 48 03 1c c5 a0 42 cc 81 
48 89 df e8 94 fc 11 00 49 8b 44 24 18 48 85 c0 74 2d 49[   
56.141507] RIP  [<ffffffff815ea29e>] 
nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
[   56.155425]  RSP <ffff88003e2838f8>
[   56.169234] ---[ end trace 4c64578e4c629cc4 ]---
[   56.182913] Kernel panic - not syncing: Fatal exception in interrupt
[   56.197026] Kernel Offset: 0x0 from 0xffffffff81000k  text console
(XEN) [2014-11-23 06:05:48] Domain 0 crashed: rebooting machine in 5 
seconds.
(XEN) [2014-11-23 06:05:53] Resetting with ACPI MEMORY or I/O RESET_REG.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 22:00:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 22:00:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtO9C-0004uB-6c; Tue, 25 Nov 2014 21:59:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtO9B-0004u6-2X
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 21:59:45 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	38/96-25276-0DBF4745; Tue, 25 Nov 2014 21:59:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416952782!15346654!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22467 invoked from network); 25 Nov 2014 21:59:43 -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;
	25 Nov 2014 21:59:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,458,1413244800"; d="scan'208";a="196432833"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 16:48:48 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtNya-0005Ur-8t;
	Tue, 25 Nov 2014 21:48:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtNyZ-0004xQ-0s;
	Tue, 25 Nov 2014 21:48:47 +0000
Date: Tue, 25 Nov 2014 21:48:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31849-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31849: 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 31849 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31849/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-boot       fail pass in 31830
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot      fail in 31830 pass in 31849

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31601

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 seabios              9f505f715793d99235bd6b4afb2ca7b96ba5729b
baseline version:
 seabios              b0d42bd03225ad61e5421e12b57f633f84637328

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=seabios
+ revision=9f505f715793d99235bd6b4afb2ca7b96ba5729b
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push seabios 9f505f715793d99235bd6b4afb2ca7b96ba5729b
+ branch=seabios
+ revision=9f505f715793d99235bd6b4afb2ca7b96ba5729b
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.seabios
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.seabios
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree seabios
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/seabios
+ git push osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git 9f505f715793d99235bd6b4afb2ca7b96ba5729b:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   b0d42bd..9f505f7  9f505f715793d99235bd6b4afb2ca7b96ba5729b -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 22:00:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 22:00:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtO9C-0004uB-6c; Tue, 25 Nov 2014 21:59:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtO9B-0004u6-2X
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 21:59:45 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	38/96-25276-0DBF4745; Tue, 25 Nov 2014 21:59:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416952782!15346654!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22467 invoked from network); 25 Nov 2014 21:59:43 -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;
	25 Nov 2014 21:59:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,458,1413244800"; d="scan'208";a="196432833"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 16:48:48 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtNya-0005Ur-8t;
	Tue, 25 Nov 2014 21:48:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtNyZ-0004xQ-0s;
	Tue, 25 Nov 2014 21:48:47 +0000
Date: Tue, 25 Nov 2014 21:48:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31849-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31849: 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 31849 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31849/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-boot       fail pass in 31830
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot      fail in 31830 pass in 31849

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31601

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 seabios              9f505f715793d99235bd6b4afb2ca7b96ba5729b
baseline version:
 seabios              b0d42bd03225ad61e5421e12b57f633f84637328

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor <kevin@koconnor.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=seabios
+ revision=9f505f715793d99235bd6b4afb2ca7b96ba5729b
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push seabios 9f505f715793d99235bd6b4afb2ca7b96ba5729b
+ branch=seabios
+ revision=9f505f715793d99235bd6b4afb2ca7b96ba5729b
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.seabios
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.seabios
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree seabios
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/seabios
+ git push osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git 9f505f715793d99235bd6b4afb2ca7b96ba5729b:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   b0d42bd..9f505f7  9f505f715793d99235bd6b4afb2ca7b96ba5729b -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 22:17:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 22: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 1XtOPz-0005KG-RT; Tue, 25 Nov 2014 22:17:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XtOPy-0005KB-1m
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 22:17:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/83-25276-1EFF4745; Tue, 25 Nov 2014 22:17:05 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416953824!15349453!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5962 invoked from network); 25 Nov 2014 22:17:05 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 22:17:05 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAPMGnTs011974;
	Tue, 25 Nov 2014 22:16:53 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAPMGieg020361
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 22:16:44 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAPMGixP001709;
	Tue, 25 Nov 2014 22:16:44 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAPMGh8T001705; Tue, 25 Nov 2014 22:16:43 GMT
Date: Tue, 25 Nov 2014 22:16:43 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141125091539.GA17596@zion.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1411252205100.2827@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
	<20141124140939.GA14073@zion.uk.xensource.com>
	<alpine.GSO.2.00.1411250849030.1332@algedi.dur.ac.uk>
	<20141125091539.GA17596@zion.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAPMGnTs011974
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Tue, 25 Nov 2014, Wei Liu wrote:

> On Tue, Nov 25, 2014 at 08:52:00AM +0000, M A Young wrote:
> [...]
>>>
>>> And the said patch has been applied (3460eeb3fc2) so we're fine.
>>
>> However that doesn't fix my crash. I tried with it applied and still saw the
>> crash. I also tried 4.5-rc1 (without XSM to avoid my other issue) and that
>> crashed as well.
>>
>
> And the log is still the same? If the crash happens in different
> location it might be another bug.

Yes, it is the same crash. Going back to the dprintf command,
                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
                         csum_page(region_base + i * PAGE_SIZE),
                         csum_page(buf));
what does pagebuf->pfn_types[pfn] actually mean and how does it relate to 
the type= it matches. I suspect it should be something else, eg. 
pfn_type[pfn] which would give the page type corresponding to pfn.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 22:17:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 22: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 1XtOPz-0005KG-RT; Tue, 25 Nov 2014 22:17:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XtOPy-0005KB-1m
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 22:17:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/83-25276-1EFF4745; Tue, 25 Nov 2014 22:17:05 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416953824!15349453!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5962 invoked from network); 25 Nov 2014 22:17:05 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 22:17:05 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAPMGnTs011974;
	Tue, 25 Nov 2014 22:16:53 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAPMGieg020361
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Nov 2014 22:16:44 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAPMGixP001709;
	Tue, 25 Nov 2014 22:16:44 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAPMGh8T001705; Tue, 25 Nov 2014 22:16:43 GMT
Date: Tue, 25 Nov 2014 22:16:43 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141125091539.GA17596@zion.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1411252205100.2827@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
	<20141124140939.GA14073@zion.uk.xensource.com>
	<alpine.GSO.2.00.1411250849030.1332@algedi.dur.ac.uk>
	<20141125091539.GA17596@zion.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAPMGnTs011974
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Tue, 25 Nov 2014, Wei Liu wrote:

> On Tue, Nov 25, 2014 at 08:52:00AM +0000, M A Young wrote:
> [...]
>>>
>>> And the said patch has been applied (3460eeb3fc2) so we're fine.
>>
>> However that doesn't fix my crash. I tried with it applied and still saw the
>> crash. I also tried 4.5-rc1 (without XSM to avoid my other issue) and that
>> crashed as well.
>>
>
> And the log is still the same? If the crash happens in different
> location it might be another bug.

Yes, it is the same crash. Going back to the dprintf command,
                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
                         csum_page(region_base + i * PAGE_SIZE),
                         csum_page(buf));
what does pagebuf->pfn_types[pfn] actually mean and how does it relate to 
the type= it matches. I suspect it should be something else, eg. 
pfn_type[pfn] which would give the page type corresponding to pfn.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 22:33:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 22:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtOfS-0005eC-I7; Tue, 25 Nov 2014 22:33:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XtOfR-0005e5-GD
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 22:33:05 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BD/1D-25276-0A305745; Tue, 25 Nov 2014 22:33:04 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416954784!14979611!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31366 invoked from network); 25 Nov 2014 22:33:04 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 22:33:04 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-31-211-68.oxfd.adsl.virginm.net ([86.31.211.68]:50867
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XtOfL-00059p-Fr (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 25 Nov 2014 22:33:00 +0000
Message-ID: <5475039B.8010009@citrix.com>
Date: Tue, 25 Nov 2014 22:32:59 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>, Wei Liu <wei.liu2@citrix.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
	<20141124140939.GA14073@zion.uk.xensource.com>
	<alpine.GSO.2.00.1411250849030.1332@algedi.dur.ac.uk>
	<20141125091539.GA17596@zion.uk.xensource.com>
	<alpine.DEB.2.00.1411252205100.2827@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1411252205100.2827@procyon.dur.ac.uk>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/11/2014 22:16, M A Young wrote:
>
>
> On Tue, 25 Nov 2014, Wei Liu wrote:
>
>> On Tue, Nov 25, 2014 at 08:52:00AM +0000, M A Young wrote:
>> [...]
>>>>
>>>> And the said patch has been applied (3460eeb3fc2) so we're fine.
>>>
>>> However that doesn't fix my crash. I tried with it applied and still
>>> saw the
>>> crash. I also tried 4.5-rc1 (without XSM to avoid my other issue)
>>> and that
>>> crashed as well.
>>>
>>
>> And the log is still the same? If the crash happens in different
>> location it might be another bug.
>
> Yes, it is the same crash. Going back to the dprintf command,
>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>                         csum_page(region_base + i * PAGE_SIZE),
>                         csum_page(buf));
> what does pagebuf->pfn_types[pfn] actually mean and how does it relate
> to the type= it matches. I suspect it should be something else, eg.
> pfn_type[pfn] which would give the page type corresponding to pfn.
>
>     Michael Young

Eugh - this code is horrible.  (The migration v2 code is so much nicer).

"pagebuf->pfn_types[pfn]" is completely bogus in this context, and
should indeed be "pfn_type[pfn]" instead.  The pagebuf->pfn_types[]
array is up to 1024 entries long.

Having said that, it is my firm opinion that verify mode is useless for
anyone who isn't actively developing a migration stream (and even then,
less useful than it would appear to be).  I would skip the "--debug", as
I don't believe it will help you at all in tracking down your issue.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 22:33:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 22:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtOfS-0005eC-I7; Tue, 25 Nov 2014 22:33:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XtOfR-0005e5-GD
	for xen-devel@lists.xen.org; Tue, 25 Nov 2014 22:33:05 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BD/1D-25276-0A305745; Tue, 25 Nov 2014 22:33:04 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-3.tower-21.messagelabs.com!1416954784!14979611!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31366 invoked from network); 25 Nov 2014 22:33:04 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2014 22:33:04 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-31-211-68.oxfd.adsl.virginm.net ([86.31.211.68]:50867
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XtOfL-00059p-Fr (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 25 Nov 2014 22:33:00 +0000
Message-ID: <5475039B.8010009@citrix.com>
Date: Tue, 25 Nov 2014 22:32:59 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>, Wei Liu <wei.liu2@citrix.com>
References: <alpine.DEB.2.00.1411221847340.26346@procyon.dur.ac.uk>
	<alpine.DEB.2.00.1411232348480.16740@procyon.dur.ac.uk>
	<CAFLBxZanaadf3mSn2Po=bznw7DxZRs67AGj1xO4LRLw6tqx6Cg@mail.gmail.com>
	<54732EF5.5040607@citrix.com>
	<20141124140939.GA14073@zion.uk.xensource.com>
	<alpine.GSO.2.00.1411250849030.1332@algedi.dur.ac.uk>
	<20141125091539.GA17596@zion.uk.xensource.com>
	<alpine.DEB.2.00.1411252205100.2827@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1411252205100.2827@procyon.dur.ac.uk>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems using xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/11/2014 22:16, M A Young wrote:
>
>
> On Tue, 25 Nov 2014, Wei Liu wrote:
>
>> On Tue, Nov 25, 2014 at 08:52:00AM +0000, M A Young wrote:
>> [...]
>>>>
>>>> And the said patch has been applied (3460eeb3fc2) so we're fine.
>>>
>>> However that doesn't fix my crash. I tried with it applied and still
>>> saw the
>>> crash. I also tried 4.5-rc1 (without XSM to avoid my other issue)
>>> and that
>>> crashed as well.
>>>
>>
>> And the log is still the same? If the crash happens in different
>> location it might be another bug.
>
> Yes, it is the same crash. Going back to the dprintf command,
>                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
>                         "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
>                         csum_page(region_base + i * PAGE_SIZE),
>                         csum_page(buf));
> what does pagebuf->pfn_types[pfn] actually mean and how does it relate
> to the type= it matches. I suspect it should be something else, eg.
> pfn_type[pfn] which would give the page type corresponding to pfn.
>
>     Michael Young

Eugh - this code is horrible.  (The migration v2 code is so much nicer).

"pagebuf->pfn_types[pfn]" is completely bogus in this context, and
should indeed be "pfn_type[pfn]" instead.  The pagebuf->pfn_types[]
array is up to 1024 entries long.

Having said that, it is my firm opinion that verify mode is useless for
anyone who isn't actively developing a migration stream (and even then,
less useful than it would appear to be).  I would skip the "--debug", as
I don't believe it will help you at all in tracking down your issue.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Nov 25 23:31:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 23:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtPZ9-0006Cs-9g; Tue, 25 Nov 2014 23:30:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtPZ7-0006Cn-N5
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 23:30:37 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	EE/85-02696-D1115745; Tue, 25 Nov 2014 23:30:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416958234!14860688!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26920 invoked from network); 25 Nov 2014 23:30:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 23:30:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,459,1413244800"; d="scan'208";a="196810392"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 18:30:33 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtPZ2-0005yy-VY;
	Tue, 25 Nov 2014 23:30:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtPZ1-0004Ll-Nx;
	Tue, 25 Nov 2014 23:30:31 +0000
Date: Tue, 25 Nov 2014 23:30:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31852-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31852: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31852 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31852/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 31680

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              742d49fa170bf72ec1fee516fda9f6797b1124f9
baseline version:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad

------------------------------------------------------------
People who touched revisions under test:
  Anirban Chakraborty <abchak@juniper.net>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Giuseppe Scrivano <gscrivan@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nehal J Wani <nehaljw.kkd1@gmail.com>
  Pavel Hrdina <phrdina@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Tomoki Sekiyama <tomoki.sekiyama@hds.com>
  Yohan BELLEGUIC <yohan.belleguic@diateam.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 957 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 Nov 25 23:31:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Nov 2014 23:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtPZ9-0006Cs-9g; Tue, 25 Nov 2014 23:30:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtPZ7-0006Cn-N5
	for xen-devel@lists.xensource.com; Tue, 25 Nov 2014 23:30:37 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	EE/85-02696-D1115745; Tue, 25 Nov 2014 23:30:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1416958234!14860688!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26920 invoked from network); 25 Nov 2014 23:30:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2014 23:30:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,459,1413244800"; d="scan'208";a="196810392"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 18:30:33 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtPZ2-0005yy-VY;
	Tue, 25 Nov 2014 23:30:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtPZ1-0004Ll-Nx;
	Tue, 25 Nov 2014 23:30:31 +0000
Date: Tue, 25 Nov 2014 23:30:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31852-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31852: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31852 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31852/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 31680

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              742d49fa170bf72ec1fee516fda9f6797b1124f9
baseline version:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad

------------------------------------------------------------
People who touched revisions under test:
  Anirban Chakraborty <abchak@juniper.net>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Giuseppe Scrivano <gscrivan@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nehal J Wani <nehaljw.kkd1@gmail.com>
  Pavel Hrdina <phrdina@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Tomoki Sekiyama <tomoki.sekiyama@hds.com>
  Yohan BELLEGUIC <yohan.belleguic@diateam.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 957 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 Nov 26 00:30:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 00: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 1XtQUo-0007Ax-CK; Wed, 26 Nov 2014 00:30:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtQUm-0007As-NH
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 00:30:12 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	92/42-25547-31F15745; Wed, 26 Nov 2014 00:30:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416961809!13813313!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4633 invoked from network); 26 Nov 2014 00:30:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 00:30:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,459,1413244800"; d="scan'208";a="196825367"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 19:29:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtQUH-0006GZ-Rn;
	Wed, 26 Nov 2014 00:29:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtQUH-0006tC-GG;
	Wed, 26 Nov 2014 00:29:41 +0000
Date: Wed, 26 Nov 2014 00:29:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31850-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31850: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31850 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31850/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl           11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                5d01410fe4d92081f349b013a2e7a95429e4f2c9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
644 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27197 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 Nov 26 00:30:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 00: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 1XtQUo-0007Ax-CK; Wed, 26 Nov 2014 00:30:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtQUm-0007As-NH
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 00:30:12 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	92/42-25547-31F15745; Wed, 26 Nov 2014 00:30:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1416961809!13813313!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4633 invoked from network); 26 Nov 2014 00:30:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 00:30:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,459,1413244800"; d="scan'208";a="196825367"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Tue, 25 Nov 2014 19:29:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtQUH-0006GZ-Rn;
	Wed, 26 Nov 2014 00:29:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtQUH-0006tC-GG;
	Wed, 26 Nov 2014 00:29:41 +0000
Date: Wed, 26 Nov 2014 00:29:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31850-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31850: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31850 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31850/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl           11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                5d01410fe4d92081f349b013a2e7a95429e4f2c9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
644 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27197 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 Nov 26 00:34:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 00:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtQYb-0007LJ-1P; Wed, 26 Nov 2014 00:34:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waiman.long@hp.com>) id 1XtQYa-0007LA-2v
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 00:34:08 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D2/A4-02696-FFF15745; Wed, 26 Nov 2014 00:34:07 +0000
X-Env-Sender: waiman.long@hp.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416962045!14856416!1
X-Originating-IP: [15.217.128.51]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16001 invoked from network); 26 Nov 2014 00:34:06 -0000
Received: from g2t2352.austin.hp.com (HELO g2t2352.austin.hp.com)
	(15.217.128.51)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 00:34:06 -0000
Received: from g2t2360.austin.hp.com (g2t2360.austin.hp.com [16.197.8.247])
	by g2t2352.austin.hp.com (Postfix) with ESMTP id 5591B120;
	Wed, 26 Nov 2014 00:34:04 +0000 (UTC)
Received: from [10.152.32.22] (ospra1.fc.hp.com [16.79.38.118])
	by g2t2360.austin.hp.com (Postfix) with ESMTP id 5661264;
	Wed, 26 Nov 2014 00:33:59 +0000 (UTC)
Message-ID: <54751FF6.5050808@hp.com>
Date: Tue, 25 Nov 2014 19:33:58 -0500
From: Waiman Long <waiman.long@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1413483040-58399-1-git-send-email-Waiman.Long@hp.com>
	<1413483040-58399-10-git-send-email-Waiman.Long@hp.com>
	<20141024085437.GV21513@worktop.programming.kicks-ass.net>
	<544E830C.6070307@hp.com>
	<20141027180252.GC12989@laptop.dumpdata.com>
In-Reply-To: <20141027180252.GC12989@laptop.dumpdata.com>
Cc: linux-arch@vger.kernel.org,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	kvm@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Scott J Norton <scott.norton@hp.com>, x86@kernel.org,
	Paolo Bonzini <paolo.bonzini@gmail.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Douglas Hatch <doug.hatch@hp.com>
Subject: Re: [Xen-devel] [PATCH v12 09/11] pvqspinlock,
	x86: Add para-virtualization support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/27/2014 02:02 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 27, 2014 at 01:38:20PM -0400, Waiman Long wrote:
>>
>> My concern is that spin_unlock() can be called in many places, including
>> loadable kernel modules. Can the paravirt_patch_ident_32() function able to
>> patch all of them in reasonable time? How about a kernel module loaded later
>> at run time?
> It has too. When the modules are loaded the .paravirt symbols are exposed
> and the module loader patches that.
>
> And during bootup time (before modules are loaded) it also patches everything
> - when it only runs on one CPU.
>

I have been changing the patching code to patch the unlock call sites 
and it seems to be working now. However, when I manually inserted a 
kernel module using insmod and run the code in the newly inserted 
module, I got memory access violation as follows:

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<          (null)>]           (null)
PGD 18d62f3067 PUD 18d476f067 PMD 0
Oops: 0010 [#1] SMP
Modules linked in: locktest(OE) ebtable_nat ebtables xt_CHECKSUM 
iptable_mangle bridge autofs4 8021q garp stp llc ipt_REJECT 
nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT 
nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter 
ip6_tables ipv6 vhost_net macvtap macvlan vhost tun uinput ppdev 
parport_pc parport sg microcode pcspkr virtio_balloon 
snd_hda_codec_generic virtio_console snd_hda_intel snd_hda_controller 
snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd 
soundcore virtio_net i2c_piix4 i2c_core ext4(E) jbd2(E) mbcache(E) 
floppy(E) virtio_blk(E) sr_mod(E) cdrom(E) virtio_pci(E) virtio_ring(E) 
virtio(E) pata_acpi(E) ata_generic(E) ata_piix(E) dm_mirror(E) 
dm_region_hash(E) dm_log(E) dm_mod(E) [last unloaded: speedstep_lib]
CPU: 1 PID: 3907 Comm: run-locktest Tainted: G        W  OE  
3.17.0-pvqlock #3
Hardware name: Red Hat KVM, BIOS Bochs 01/01/2011
task: ffff8818cc5baf90 ti: ffff8818b7094000 task.ti: ffff8818b7094000
RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
RSP: 0018:ffff8818b7097db0  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000004c4b40 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8818d3f052c0
RBP: ffff8818b7097dd8 R08: 0000000080522014 R09: 0000000000000000
R10: 0000000000001000 R11: 0000000000000001 R12: 0000000000000001
R13: 0000000000000000 R14: 0000000000000001 R15: ffff8818b7097ea0
FS:  00007fb828ece700(0000) GS:ffff88193ec20000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000018cc7e9000 CR4: 00000000000006e0
Stack:
  ffffffffa06ff395 ffff8818d465e000 ffffffff8164bec0 0000000000000001
  0000000000000050 ffff8818b7097e18 ffffffffa06ff785 ffff8818b7097e38
  0000000000000246 0000000054755e3a 0000000039f8ba72 ffff8818c174f000
Call Trace:
  [<ffffffffa06ff395>] ? test_spinlock+0x65/0x90 [locktest]
  [<ffffffffa06ff785>] etime_show+0xd5/0x120 [locktest]
  [<ffffffff812a2dc6>] kobj_attr_show+0x16/0x20
  [<ffffffff8121a7fa>] sysfs_kf_seq_show+0xca/0x1b0
  [<ffffffff81218a13>] kernfs_seq_show+0x23/0x30
  [<ffffffff811c82db>] seq_read+0xbb/0x400
  [<ffffffff812197e5>] kernfs_fop_read+0x35/0x40
  [<ffffffff811a4223>] vfs_read+0xa3/0x110
  [<ffffffff811a47e6>] SyS_read+0x56/0xd0
  [<ffffffff810f3e16>] ? __audit_syscall_exit+0x216/0x2c0
  [<ffffffff815b3ca9>] system_call_fastpath+0x16/0x1b
Code:  Bad RIP value.
  RSP <ffff8818b7097db0>
CR2: 0000000000000000
---[ end trace 69d0e259c9ec632f ]---

It seems like call site patching isn't properly done or the kernel 
module that I built was missing some critical information necessary for 
the proper linking. Anyway, I will include the unlock call patching code 
as a separate patch as it seems there may be problem under certain 
circumstance.

BTW, the kernel panic problem that your team reported had been fixed. 
The fix will be in the next version of the patch.

-Longman

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 00:34:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 00:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtQYb-0007LJ-1P; Wed, 26 Nov 2014 00:34:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waiman.long@hp.com>) id 1XtQYa-0007LA-2v
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 00:34:08 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D2/A4-02696-FFF15745; Wed, 26 Nov 2014 00:34:07 +0000
X-Env-Sender: waiman.long@hp.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1416962045!14856416!1
X-Originating-IP: [15.217.128.51]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16001 invoked from network); 26 Nov 2014 00:34:06 -0000
Received: from g2t2352.austin.hp.com (HELO g2t2352.austin.hp.com)
	(15.217.128.51)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 00:34:06 -0000
Received: from g2t2360.austin.hp.com (g2t2360.austin.hp.com [16.197.8.247])
	by g2t2352.austin.hp.com (Postfix) with ESMTP id 5591B120;
	Wed, 26 Nov 2014 00:34:04 +0000 (UTC)
Received: from [10.152.32.22] (ospra1.fc.hp.com [16.79.38.118])
	by g2t2360.austin.hp.com (Postfix) with ESMTP id 5661264;
	Wed, 26 Nov 2014 00:33:59 +0000 (UTC)
Message-ID: <54751FF6.5050808@hp.com>
Date: Tue, 25 Nov 2014 19:33:58 -0500
From: Waiman Long <waiman.long@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1413483040-58399-1-git-send-email-Waiman.Long@hp.com>
	<1413483040-58399-10-git-send-email-Waiman.Long@hp.com>
	<20141024085437.GV21513@worktop.programming.kicks-ass.net>
	<544E830C.6070307@hp.com>
	<20141027180252.GC12989@laptop.dumpdata.com>
In-Reply-To: <20141027180252.GC12989@laptop.dumpdata.com>
Cc: linux-arch@vger.kernel.org,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	kvm@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Scott J Norton <scott.norton@hp.com>, x86@kernel.org,
	Paolo Bonzini <paolo.bonzini@gmail.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Douglas Hatch <doug.hatch@hp.com>
Subject: Re: [Xen-devel] [PATCH v12 09/11] pvqspinlock,
	x86: Add para-virtualization support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/27/2014 02:02 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 27, 2014 at 01:38:20PM -0400, Waiman Long wrote:
>>
>> My concern is that spin_unlock() can be called in many places, including
>> loadable kernel modules. Can the paravirt_patch_ident_32() function able to
>> patch all of them in reasonable time? How about a kernel module loaded later
>> at run time?
> It has too. When the modules are loaded the .paravirt symbols are exposed
> and the module loader patches that.
>
> And during bootup time (before modules are loaded) it also patches everything
> - when it only runs on one CPU.
>

I have been changing the patching code to patch the unlock call sites 
and it seems to be working now. However, when I manually inserted a 
kernel module using insmod and run the code in the newly inserted 
module, I got memory access violation as follows:

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<          (null)>]           (null)
PGD 18d62f3067 PUD 18d476f067 PMD 0
Oops: 0010 [#1] SMP
Modules linked in: locktest(OE) ebtable_nat ebtables xt_CHECKSUM 
iptable_mangle bridge autofs4 8021q garp stp llc ipt_REJECT 
nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT 
nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter 
ip6_tables ipv6 vhost_net macvtap macvlan vhost tun uinput ppdev 
parport_pc parport sg microcode pcspkr virtio_balloon 
snd_hda_codec_generic virtio_console snd_hda_intel snd_hda_controller 
snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd 
soundcore virtio_net i2c_piix4 i2c_core ext4(E) jbd2(E) mbcache(E) 
floppy(E) virtio_blk(E) sr_mod(E) cdrom(E) virtio_pci(E) virtio_ring(E) 
virtio(E) pata_acpi(E) ata_generic(E) ata_piix(E) dm_mirror(E) 
dm_region_hash(E) dm_log(E) dm_mod(E) [last unloaded: speedstep_lib]
CPU: 1 PID: 3907 Comm: run-locktest Tainted: G        W  OE  
3.17.0-pvqlock #3
Hardware name: Red Hat KVM, BIOS Bochs 01/01/2011
task: ffff8818cc5baf90 ti: ffff8818b7094000 task.ti: ffff8818b7094000
RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
RSP: 0018:ffff8818b7097db0  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000004c4b40 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8818d3f052c0
RBP: ffff8818b7097dd8 R08: 0000000080522014 R09: 0000000000000000
R10: 0000000000001000 R11: 0000000000000001 R12: 0000000000000001
R13: 0000000000000000 R14: 0000000000000001 R15: ffff8818b7097ea0
FS:  00007fb828ece700(0000) GS:ffff88193ec20000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000018cc7e9000 CR4: 00000000000006e0
Stack:
  ffffffffa06ff395 ffff8818d465e000 ffffffff8164bec0 0000000000000001
  0000000000000050 ffff8818b7097e18 ffffffffa06ff785 ffff8818b7097e38
  0000000000000246 0000000054755e3a 0000000039f8ba72 ffff8818c174f000
Call Trace:
  [<ffffffffa06ff395>] ? test_spinlock+0x65/0x90 [locktest]
  [<ffffffffa06ff785>] etime_show+0xd5/0x120 [locktest]
  [<ffffffff812a2dc6>] kobj_attr_show+0x16/0x20
  [<ffffffff8121a7fa>] sysfs_kf_seq_show+0xca/0x1b0
  [<ffffffff81218a13>] kernfs_seq_show+0x23/0x30
  [<ffffffff811c82db>] seq_read+0xbb/0x400
  [<ffffffff812197e5>] kernfs_fop_read+0x35/0x40
  [<ffffffff811a4223>] vfs_read+0xa3/0x110
  [<ffffffff811a47e6>] SyS_read+0x56/0xd0
  [<ffffffff810f3e16>] ? __audit_syscall_exit+0x216/0x2c0
  [<ffffffff815b3ca9>] system_call_fastpath+0x16/0x1b
Code:  Bad RIP value.
  RSP <ffff8818b7097db0>
CR2: 0000000000000000
---[ end trace 69d0e259c9ec632f ]---

It seems like call site patching isn't properly done or the kernel 
module that I built was missing some critical information necessary for 
the proper linking. Anyway, I will include the unlock call patching code 
as a separate patch as it seems there may be problem under certain 
circumstance.

BTW, the kernel panic problem that your team reported had been fixed. 
The fix will be in the next version of the patch.

-Longman

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 00:40:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 00:40:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtQeq-0007U4-S6; Wed, 26 Nov 2014 00:40:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1XtQep-0007Tz-Om
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 00:40:35 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	1F/00-28296-38125745; Wed, 26 Nov 2014 00:40:35 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416962433!9412071!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20939 invoked from network); 26 Nov 2014 00:40:34 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-31.messagelabs.com with SMTP;
	26 Nov 2014 00:40:34 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 25 Nov 2014 16:37:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,459,1413270000"; d="scan'208";a="643561946"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by orsmga002.jf.intel.com with ESMTP; 25 Nov 2014 16:40:29 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 26 Nov 2014 08:40:28 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Wed, 26 Nov 2014 08:40:27 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest
Thread-Index: AQHQAxh40OPG79GTNEGKmyo8ZLinmpxlrM6AgACVuECAADyIKIAAqAiwgAAKSACACWrfYP//6OiAgAGXWSA=
Date: Wed, 26 Nov 2014 00:40:27 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF1C3D@SHSMSX104.ccr.corp.intel.com>
References: <20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
	<20141119095440.GA1409@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF0EDB@SHSMSX104.ccr.corp.intel.com>
	<547449F3020000780004A924@mail.emea.novell.com>
In-Reply-To: <547449F3020000780004A924@mail.emea.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: Tim Deegan <tim@xen.org>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li,
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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

Jan Beulich wrote on 2014-11-25:
>>>> On 25.11.14 at 02:47, <yang.z.zhang@intel.com> wrote:
>> Tim Deegan wrote on 2014-11-19:
>>> At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
>>>> Tim Deegan wrote on 2014-11-18:
>>>>> In this case, the guest is entitled to _expect_ pagefaults on 1GB
>>>>> mappings if CPUID claims they are not supported.  That sounds
>>>>> like an unlikely thing for the guest to be relying on, but Xen
>>>>> itself does something similar for the SHOPT_FAST_FAULT_PATH (and
>>>>> now also for IOMMU entries for the deferred caching attribute updates).
>>>> 
>>>> Indeed. How about adding the software check (as Andrew mentioned)
>>>> firstly and leave the hardware problem (Actually, I don't think we
>>>> can solve it currently).
>>> 
>>> I don't think we should change the software path unless we can
>>> change the hardware behaviour too.  It's better to be consistent,
>>> and it saves us some cycles in the pt walker.
>> 
>> So if we don't need to add the software check, does this mean
>> current patch is ok?
> 
> No - Tim having confirmed that shadow mode doesn't support 1Gb pages,
> the feature clearly must not be made visible for shadow mode guest.

Indeed. Liang, Can you add the shadow mode check in the next version?

> 
> Jan


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 00:40:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 00:40:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtQeq-0007U4-S6; Wed, 26 Nov 2014 00:40:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1XtQep-0007Tz-Om
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 00:40:35 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	1F/00-28296-38125745; Wed, 26 Nov 2014 00:40:35 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1416962433!9412071!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20939 invoked from network); 26 Nov 2014 00:40:34 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-31.messagelabs.com with SMTP;
	26 Nov 2014 00:40:34 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 25 Nov 2014 16:37:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,459,1413270000"; d="scan'208";a="643561946"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by orsmga002.jf.intel.com with ESMTP; 25 Nov 2014 16:40:29 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 26 Nov 2014 08:40:28 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Wed, 26 Nov 2014 08:40:27 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest
Thread-Index: AQHQAxh40OPG79GTNEGKmyo8ZLinmpxlrM6AgACVuECAADyIKIAAqAiwgAAKSACACWrfYP//6OiAgAGXWSA=
Date: Wed, 26 Nov 2014 00:40:27 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF1C3D@SHSMSX104.ccr.corp.intel.com>
References: <20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
	<20141119095440.GA1409@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF0EDB@SHSMSX104.ccr.corp.intel.com>
	<547449F3020000780004A924@mail.emea.novell.com>
In-Reply-To: <547449F3020000780004A924@mail.emea.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: Tim Deegan <tim@xen.org>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, "Li,
	Liang Z" <liang.z.li@intel.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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

Jan Beulich wrote on 2014-11-25:
>>>> On 25.11.14 at 02:47, <yang.z.zhang@intel.com> wrote:
>> Tim Deegan wrote on 2014-11-19:
>>> At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
>>>> Tim Deegan wrote on 2014-11-18:
>>>>> In this case, the guest is entitled to _expect_ pagefaults on 1GB
>>>>> mappings if CPUID claims they are not supported.  That sounds
>>>>> like an unlikely thing for the guest to be relying on, but Xen
>>>>> itself does something similar for the SHOPT_FAST_FAULT_PATH (and
>>>>> now also for IOMMU entries for the deferred caching attribute updates).
>>>> 
>>>> Indeed. How about adding the software check (as Andrew mentioned)
>>>> firstly and leave the hardware problem (Actually, I don't think we
>>>> can solve it currently).
>>> 
>>> I don't think we should change the software path unless we can
>>> change the hardware behaviour too.  It's better to be consistent,
>>> and it saves us some cycles in the pt walker.
>> 
>> So if we don't need to add the software check, does this mean
>> current patch is ok?
> 
> No - Tim having confirmed that shadow mode doesn't support 1Gb pages,
> the feature clearly must not be made visible for shadow mode guest.

Indeed. Liang, Can you add the shadow mode check in the next version?

> 
> Jan


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 02:04:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 02:04:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtRxm-0004Qu-3u; Wed, 26 Nov 2014 02:04:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XtRxk-0004Qp-2a
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 02:04:12 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	46/E8-26740-B1535745; Wed, 26 Nov 2014 02:04:11 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416967449!13853201!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27689 invoked from network); 26 Nov 2014 02:04:10 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-16.tower-31.messagelabs.com with SMTP;
	26 Nov 2014 02:04:10 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 25 Nov 2014 18:01:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,459,1413270000"; d="scan'208";a="614103546"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by orsmga001.jf.intel.com with ESMTP; 25 Nov 2014 18:04:00 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 26 Nov 2014 10:03:59 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id
	14.03.0195.001; Wed, 26 Nov 2014 10:03:58 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Eric Blake <eblake@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
	Xen stubdom vTPM command line options
Thread-Index: AQHQCArFXtNvJVE17EuNR1tsww9REpxvgrqAgAHZizD//6flgIABJeTg
Date: Wed, 26 Nov 2014 02:03:58 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E841C4D@SHSMSX101.ccr.corp.intel.com>
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
	<54736893.6060802@redhat.com> <54736B69.1050408@redhat.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8416DC@SHSMSX101.ccr.corp.intel.com>
	<5474AEBD.2040308@redhat.com>
In-Reply-To: <5474AEBD.2040308@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "lcapitulino@redhat.com" <lcapitulino@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Eric Blake [mailto:eblake@redhat.com]
> Sent: Wednesday, November 26, 2014 12:31 AM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: xen-devel@lists.xen.org; armbru@redhat.com; lcapitulino@redhat.com
> Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
> Xen stubdom vTPM command line options
> 
> On 11/25/2014 06:51 AM, Xu, Quan wrote:
> >>
> >> Also, this message was not threaded properly; it appeared as a
> >> top-level thread along with three other threads for its siblings,
> >> instead of all four patches being in-reply-to the 0/4 cover letter.
> >>
> > Thanks Eric.
> >
> > Should I:
> >
> > V2 is version number,
> > 1. $git format-patch --subject-prefix=v2 -ns --cover-letter master
> >   Then, edit 0000-cover-letter.patch
> 
> Rather than '--subject-prefix=v2', I prefer using '-v2'.  The important part is
> that you send the mails with 'git send-email' instead of doing it by hand.  In
> fact, you can do 'git send-email --annotate -v2 --cover-letter master' and skip
> the format-patch altogether, if you are okay saving your cover letter edits to
> the point where you are sending the mails.
> 
Thanks Eric. 
> >
> > 2. $git format-patch --subject-prefix=v2 -4
> >   Then, commit these 4 patch and 0000-cover-letter.patch
> 
> I'm not sure what you meant by commit.  You aren't adding the *.patch files
> to a repository, but sending them as email.
> 
Yes, just but sending them as email.
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 02:04:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 02:04:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtRxm-0004Qu-3u; Wed, 26 Nov 2014 02:04:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1XtRxk-0004Qp-2a
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 02:04:12 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	46/E8-26740-B1535745; Wed, 26 Nov 2014 02:04:11 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1416967449!13853201!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27689 invoked from network); 26 Nov 2014 02:04:10 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-16.tower-31.messagelabs.com with SMTP;
	26 Nov 2014 02:04:10 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 25 Nov 2014 18:01:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,459,1413270000"; d="scan'208";a="614103546"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by orsmga001.jf.intel.com with ESMTP; 25 Nov 2014 18:04:00 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 26 Nov 2014 10:03:59 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id
	14.03.0195.001; Wed, 26 Nov 2014 10:03:58 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Eric Blake <eblake@redhat.com>, "qemu-devel@nongnu.org"
	<qemu-devel@nongnu.org>
Thread-Topic: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
	Xen stubdom vTPM command line options
Thread-Index: AQHQCArFXtNvJVE17EuNR1tsww9REpxvgrqAgAHZizD//6flgIABJeTg
Date: Wed, 26 Nov 2014 02:03:58 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E841C4D@SHSMSX101.ccr.corp.intel.com>
References: <1416802253-9891-1-git-send-email-quan.xu@intel.com>
	<54736893.6060802@redhat.com> <54736B69.1050408@redhat.com>
	<945CA011AD5F084CBEA3E851C0AB28890E8416DC@SHSMSX101.ccr.corp.intel.com>
	<5474AEBD.2040308@redhat.com>
In-Reply-To: <5474AEBD.2040308@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "lcapitulino@redhat.com" <lcapitulino@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
 Xen stubdom vTPM command line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Eric Blake [mailto:eblake@redhat.com]
> Sent: Wednesday, November 26, 2014 12:31 AM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: xen-devel@lists.xen.org; armbru@redhat.com; lcapitulino@redhat.com
> Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: Support for
> Xen stubdom vTPM command line options
> 
> On 11/25/2014 06:51 AM, Xu, Quan wrote:
> >>
> >> Also, this message was not threaded properly; it appeared as a
> >> top-level thread along with three other threads for its siblings,
> >> instead of all four patches being in-reply-to the 0/4 cover letter.
> >>
> > Thanks Eric.
> >
> > Should I:
> >
> > V2 is version number,
> > 1. $git format-patch --subject-prefix=v2 -ns --cover-letter master
> >   Then, edit 0000-cover-letter.patch
> 
> Rather than '--subject-prefix=v2', I prefer using '-v2'.  The important part is
> that you send the mails with 'git send-email' instead of doing it by hand.  In
> fact, you can do 'git send-email --annotate -v2 --cover-letter master' and skip
> the format-patch altogether, if you are okay saving your cover letter edits to
> the point where you are sending the mails.
> 
Thanks Eric. 
> >
> > 2. $git format-patch --subject-prefix=v2 -4
> >   Then, commit these 4 patch and 0000-cover-letter.patch
> 
> I'm not sure what you meant by commit.  You aren't adding the *.patch files
> to a repository, but sending them as email.
> 
Yes, just but sending them as email.
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 02:28:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 02:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtSLI-000548-Tr; Wed, 26 Nov 2014 02:28:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <seth.forshee@canonical.com>) id 1XtSLH-00053z-9U
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 02:28:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D7/15-15461-ECA35745; Wed, 26 Nov 2014 02:28:30 +0000
X-Env-Sender: seth.forshee@canonical.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416968909!15377996!1
X-Originating-IP: [209.85.214.179]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8797 invoked from network); 26 Nov 2014 02:28:30 -0000
Received: from mail-ob0-f179.google.com (HELO mail-ob0-f179.google.com)
	(209.85.214.179)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 02:28:30 -0000
Received: by mail-ob0-f179.google.com with SMTP id va2so1510707obc.24
	for <xen-devel@lists.xenproject.org>;
	Tue, 25 Nov 2014 18:28:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=EesqpaOSx2MFlNeF+HYZDFvvsHOHz6z4+tqR7C16XvE=;
	b=JP6TTg5HU6qTfKjwfDKpL0sVwdCHT7ebwx+9TLe8a961Xn/ztcgWhlVCE3xh8HKkaD
	CD6tF3u8fmgLO9ubZrLE3UNZdhSR9P8q3czLVa806OjuTSW7eamtnMNyFJUG1rlT2/h8
	H+kYB/UZwbch1rboWeNPj/n+9VTVOldGpeR3Pnh19S5RoeHw1fUvnaWW+aLriWLp18qy
	oAB0aehghnf0TKs+tMDHXM8NFQ+z9izOLJEr5bajhM7tl5tib/eFGFfEVVmHWgXC8Seh
	j5jDo3M/qJhNW3DGgdZePyhx8LCXv9NIOQOMFtEnc/bFQw45YS95/n7z+LPMExqbCMUE
	icpg==
X-Gm-Message-State: ALoCoQl3J37WSsrgDPehoHomL39dRcatR34kDQ9tIebNgNDUlLQtRtLP3uk6W6F7WFgAXg3c1yTL
X-Received: by 10.202.214.80 with SMTP id n77mr17742192oig.9.1416968908832;
	Tue, 25 Nov 2014 18:28:28 -0800 (PST)
Received: from localhost (199-87-125-144.dyn.kc.surewest.net. [199.87.125.144])
	by mx.google.com with ESMTPSA id l4sm1269960oib.11.2014.11.25.18.28.28
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 25 Nov 2014 18:28:28 -0800 (PST)
From: Seth Forshee <seth.forshee@canonical.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>
Date: Tue, 25 Nov 2014 20:28:24 -0600
Message-Id: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
X-Mailer: git-send-email 1.9.1
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Eric Dumazet <eric.dumazet@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Stefan Bader <stefan.bader@canonical.com>,
	Seth Forshee <seth.forshee@canonical.com>, xen-devel@lists.xenproject.org
Subject: [Xen-devel] [PATCH] xen-netfront: Remove BUGs on paged skb data
	which crosses a page boundary
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 BUGs can be erroneously triggered by frags which refer to
tail pages within a compound page. The data in these pages may
overrun the hardware page while still being contained within the
compound page, but since compound_order() evaluates to 0 for tail
pages the assertion fails. The code already iterates through
subsequent pages correctly in this scenario, so the BUGs are
unnecessary and can be removed.

Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
Cc: <stable@vger.kernel.org> # 3.7+
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
 drivers/net/xen-netfront.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index cca871346a0f..ece8d1804d13 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -496,9 +496,6 @@ static void xennet_make_frags(struct sk_buff *skb, struct netfront_queue *queue,
 		len = skb_frag_size(frag);
 		offset = frag->page_offset;
 
-		/* Data must not cross a page boundary. */
-		BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
-
 		/* Skip unused frames from start of page */
 		page += offset >> PAGE_SHIFT;
 		offset &= ~PAGE_MASK;
@@ -506,8 +503,6 @@ static void xennet_make_frags(struct sk_buff *skb, struct netfront_queue *queue,
 		while (len > 0) {
 			unsigned long bytes;
 
-			BUG_ON(offset >= PAGE_SIZE);
-
 			bytes = PAGE_SIZE - offset;
 			if (bytes > len)
 				bytes = len;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 02:28:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 02:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtSLI-000548-Tr; Wed, 26 Nov 2014 02:28:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <seth.forshee@canonical.com>) id 1XtSLH-00053z-9U
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 02:28:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D7/15-15461-ECA35745; Wed, 26 Nov 2014 02:28:30 +0000
X-Env-Sender: seth.forshee@canonical.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416968909!15377996!1
X-Originating-IP: [209.85.214.179]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8797 invoked from network); 26 Nov 2014 02:28:30 -0000
Received: from mail-ob0-f179.google.com (HELO mail-ob0-f179.google.com)
	(209.85.214.179)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 02:28:30 -0000
Received: by mail-ob0-f179.google.com with SMTP id va2so1510707obc.24
	for <xen-devel@lists.xenproject.org>;
	Tue, 25 Nov 2014 18:28:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=EesqpaOSx2MFlNeF+HYZDFvvsHOHz6z4+tqR7C16XvE=;
	b=JP6TTg5HU6qTfKjwfDKpL0sVwdCHT7ebwx+9TLe8a961Xn/ztcgWhlVCE3xh8HKkaD
	CD6tF3u8fmgLO9ubZrLE3UNZdhSR9P8q3czLVa806OjuTSW7eamtnMNyFJUG1rlT2/h8
	H+kYB/UZwbch1rboWeNPj/n+9VTVOldGpeR3Pnh19S5RoeHw1fUvnaWW+aLriWLp18qy
	oAB0aehghnf0TKs+tMDHXM8NFQ+z9izOLJEr5bajhM7tl5tib/eFGFfEVVmHWgXC8Seh
	j5jDo3M/qJhNW3DGgdZePyhx8LCXv9NIOQOMFtEnc/bFQw45YS95/n7z+LPMExqbCMUE
	icpg==
X-Gm-Message-State: ALoCoQl3J37WSsrgDPehoHomL39dRcatR34kDQ9tIebNgNDUlLQtRtLP3uk6W6F7WFgAXg3c1yTL
X-Received: by 10.202.214.80 with SMTP id n77mr17742192oig.9.1416968908832;
	Tue, 25 Nov 2014 18:28:28 -0800 (PST)
Received: from localhost (199-87-125-144.dyn.kc.surewest.net. [199.87.125.144])
	by mx.google.com with ESMTPSA id l4sm1269960oib.11.2014.11.25.18.28.28
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Tue, 25 Nov 2014 18:28:28 -0800 (PST)
From: Seth Forshee <seth.forshee@canonical.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>
Date: Tue, 25 Nov 2014 20:28:24 -0600
Message-Id: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
X-Mailer: git-send-email 1.9.1
Cc: Zoltan Kiss <zoltan.kiss@linaro.org>, Eric Dumazet <eric.dumazet@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Stefan Bader <stefan.bader@canonical.com>,
	Seth Forshee <seth.forshee@canonical.com>, xen-devel@lists.xenproject.org
Subject: [Xen-devel] [PATCH] xen-netfront: Remove BUGs on paged skb data
	which crosses a page boundary
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 BUGs can be erroneously triggered by frags which refer to
tail pages within a compound page. The data in these pages may
overrun the hardware page while still being contained within the
compound page, but since compound_order() evaluates to 0 for tail
pages the assertion fails. The code already iterates through
subsequent pages correctly in this scenario, so the BUGs are
unnecessary and can be removed.

Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
Cc: <stable@vger.kernel.org> # 3.7+
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
 drivers/net/xen-netfront.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index cca871346a0f..ece8d1804d13 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -496,9 +496,6 @@ static void xennet_make_frags(struct sk_buff *skb, struct netfront_queue *queue,
 		len = skb_frag_size(frag);
 		offset = frag->page_offset;
 
-		/* Data must not cross a page boundary. */
-		BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
-
 		/* Skip unused frames from start of page */
 		page += offset >> PAGE_SHIFT;
 		offset &= ~PAGE_MASK;
@@ -506,8 +503,6 @@ static void xennet_make_frags(struct sk_buff *skb, struct netfront_queue *queue,
 		while (len > 0) {
 			unsigned long bytes;
 
-			BUG_ON(offset >= PAGE_SIZE);
-
 			bytes = PAGE_SIZE - offset;
 			if (bytes > len)
 				bytes = len;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 05:24:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 05:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtV5Q-00076H-LZ; Wed, 26 Nov 2014 05:24:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasowang@redhat.com>) id 1XtV5P-00076C-NH
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 05:24:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A6/9F-15461-20465745; Wed, 26 Nov 2014 05:24:18 +0000
X-Env-Sender: jasowang@redhat.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416979456!15396166!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6163 invoked from network); 26 Nov 2014 05:24:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 05:24: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 sAQ5Nwgb027554
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 26 Nov 2014 00:23:58 -0500
Received: from [10.66.115.228] (vpn1-115-228.nay.redhat.com [10.66.115.228])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAQ5Npxa028637; Wed, 26 Nov 2014 00:23:52 -0500
Message-ID: <547563E6.2090505@redhat.com>
Date: Wed, 26 Nov 2014 13:23:50 +0800
From: Jason Wang <jasowang@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <547290D7.2020506@cn.fujitsu.com>
	<5472F1DA.4080508@m2r.biz>	<5472F980.6030208@cn.fujitsu.com>	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>	<54741ED7.2060500@redhat.com>
	<alpine.DEB.2.02.1411251249380.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411251249380.2675@kaball.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com, qemu-devel@nongnu.org,
	xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 09:53 PM, Stefano Stabellini wrote:
> On Tue, 25 Nov 2014, Jason Wang wrote:
>> On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
>>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>>>> CC'ing Paolo.
>>>>>
>>>>>
>>>>> Wen,
>>>>> thanks for the logs.
>>>>>
>>>>> I investigated a little bit and it seems to me that the bug occurs when
>>>>> QEMU tries to unmap only a portion of a memory region previously mapped.
>>>>> That doesn't work with xen-mapcache.
>>>>>
>>>>> See these logs for example:
>>>>>
>>>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
>>>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>>>> Sorry the logs don't quite match, it was supposed to be:
>>>>
>>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
>>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>>> It looks like the problem is caused by iov_discard_front, called by
>>> virtio_net_handle_ctrl. By changing iov_base after the sg has already
>>> been mapped (cpu_physical_memory_map), it causes a leak in the mapping
>>> because the corresponding cpu_physical_memory_unmap will only unmap a
>>> portion of the original sg.  On Xen the problem is worse because
>>> xen-mapcache aborts.
>>>
>>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>>> index 2ac6ce5..b2b5c2d 100644
>>> --- a/hw/net/virtio-net.c
>>> +++ b/hw/net/virtio-net.c
>>> @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>>>      struct iovec *iov;
>>>      unsigned int iov_cnt;
>>>  
>>> -    while (virtqueue_pop(vq, &elem)) {
>>> +    while (virtqueue_pop_nomap(vq, &elem)) {
>>>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
>>>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
>>>              error_report("virtio-net ctrl missing headers");
>>> @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>>>  
>>>          iov = elem.out_sg;
>>>          iov_cnt = elem.out_num;
>>> -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>>>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
>>> +
>>> +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
>>> +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
>>> +
>>> +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>> Does this really work?
> It seems to work here, as in it doesn't crash QEMU and I am able to boot
> a guest with network. I didn't try any MAC related commands.
>

It was because the guest (not a recent kernel?) never issue commands
through control vq.

We'd better hide the implementation details such as virtqueue_map_sg()
in virtio core instead of letting device call it directly.
>> The code in fact skips the location that contains
>> virtio_net_ctrl_hdr. And virtio_net_handle_mac() still calls
>> iov_discard_front().
>>
>> How about copy iov to a temp variable and use it in this function?
> That would only work if I moved the cpu_physical_memory_unmap call
> outside of virtqueue_fill, so that we can pass different iov to them.
> We need to unmap the same iov that was previously mapped by
> virtqueue_pop.
>

I mean something like following or just passing the offset of iov to
virtio_net_handle_*().

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 9b88775..fdb4edd 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -798,7 +798,7 @@ static void virtio_net_handle_ctrl(VirtIODevice
*vdev, VirtQueue *vq)
     virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
     VirtQueueElement elem;
     size_t s;
-    struct iovec *iov;
+    struct iovec *iov, *iov2;
     unsigned int iov_cnt;
 
     while (virtqueue_pop(vq, &elem)) {
@@ -808,8 +808,12 @@ static void virtio_net_handle_ctrl(VirtIODevice
*vdev, VirtQueue *vq)
             exit(1);
         }
 
-        iov = elem.out_sg;
         iov_cnt = elem.out_num;
+        s = sizeof(struct iovec) * elem.out_num;
+        iov = g_malloc(s);
+        memcpy(iov, elem.out_sg, s);
+        iov2 = iov;
+
         s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
         iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
         if (s != sizeof(ctrl)) {
@@ -833,6 +837,7 @@ static void virtio_net_handle_ctrl(VirtIODevice
*vdev, VirtQueue *vq)
 
         virtqueue_push(vq, &elem, sizeof(status));
         virtio_notify(vdev, vq);
+        g_free(iov2);
     }
 }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 05:24:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 05:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtV5Q-00076H-LZ; Wed, 26 Nov 2014 05:24:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasowang@redhat.com>) id 1XtV5P-00076C-NH
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 05:24:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A6/9F-15461-20465745; Wed, 26 Nov 2014 05:24:18 +0000
X-Env-Sender: jasowang@redhat.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416979456!15396166!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6163 invoked from network); 26 Nov 2014 05:24:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 05:24: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 sAQ5Nwgb027554
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 26 Nov 2014 00:23:58 -0500
Received: from [10.66.115.228] (vpn1-115-228.nay.redhat.com [10.66.115.228])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAQ5Npxa028637; Wed, 26 Nov 2014 00:23:52 -0500
Message-ID: <547563E6.2090505@redhat.com>
Date: Wed, 26 Nov 2014 13:23:50 +0800
From: Jason Wang <jasowang@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <547290D7.2020506@cn.fujitsu.com>
	<5472F1DA.4080508@m2r.biz>	<5472F980.6030208@cn.fujitsu.com>	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>	<54741ED7.2060500@redhat.com>
	<alpine.DEB.2.02.1411251249380.2675@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411251249380.2675@kaball.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com, qemu-devel@nongnu.org,
	xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 09:53 PM, Stefano Stabellini wrote:
> On Tue, 25 Nov 2014, Jason Wang wrote:
>> On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
>>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>>>> CC'ing Paolo.
>>>>>
>>>>>
>>>>> Wen,
>>>>> thanks for the logs.
>>>>>
>>>>> I investigated a little bit and it seems to me that the bug occurs when
>>>>> QEMU tries to unmap only a portion of a memory region previously mapped.
>>>>> That doesn't work with xen-mapcache.
>>>>>
>>>>> See these logs for example:
>>>>>
>>>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
>>>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>>>> Sorry the logs don't quite match, it was supposed to be:
>>>>
>>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
>>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>>> It looks like the problem is caused by iov_discard_front, called by
>>> virtio_net_handle_ctrl. By changing iov_base after the sg has already
>>> been mapped (cpu_physical_memory_map), it causes a leak in the mapping
>>> because the corresponding cpu_physical_memory_unmap will only unmap a
>>> portion of the original sg.  On Xen the problem is worse because
>>> xen-mapcache aborts.
>>>
>>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>>> index 2ac6ce5..b2b5c2d 100644
>>> --- a/hw/net/virtio-net.c
>>> +++ b/hw/net/virtio-net.c
>>> @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>>>      struct iovec *iov;
>>>      unsigned int iov_cnt;
>>>  
>>> -    while (virtqueue_pop(vq, &elem)) {
>>> +    while (virtqueue_pop_nomap(vq, &elem)) {
>>>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
>>>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
>>>              error_report("virtio-net ctrl missing headers");
>>> @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>>>  
>>>          iov = elem.out_sg;
>>>          iov_cnt = elem.out_num;
>>> -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>>>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
>>> +
>>> +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
>>> +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
>>> +
>>> +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>> Does this really work?
> It seems to work here, as in it doesn't crash QEMU and I am able to boot
> a guest with network. I didn't try any MAC related commands.
>

It was because the guest (not a recent kernel?) never issue commands
through control vq.

We'd better hide the implementation details such as virtqueue_map_sg()
in virtio core instead of letting device call it directly.
>> The code in fact skips the location that contains
>> virtio_net_ctrl_hdr. And virtio_net_handle_mac() still calls
>> iov_discard_front().
>>
>> How about copy iov to a temp variable and use it in this function?
> That would only work if I moved the cpu_physical_memory_unmap call
> outside of virtqueue_fill, so that we can pass different iov to them.
> We need to unmap the same iov that was previously mapped by
> virtqueue_pop.
>

I mean something like following or just passing the offset of iov to
virtio_net_handle_*().

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 9b88775..fdb4edd 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -798,7 +798,7 @@ static void virtio_net_handle_ctrl(VirtIODevice
*vdev, VirtQueue *vq)
     virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
     VirtQueueElement elem;
     size_t s;
-    struct iovec *iov;
+    struct iovec *iov, *iov2;
     unsigned int iov_cnt;
 
     while (virtqueue_pop(vq, &elem)) {
@@ -808,8 +808,12 @@ static void virtio_net_handle_ctrl(VirtIODevice
*vdev, VirtQueue *vq)
             exit(1);
         }
 
-        iov = elem.out_sg;
         iov_cnt = elem.out_num;
+        s = sizeof(struct iovec) * elem.out_num;
+        iov = g_malloc(s);
+        memcpy(iov, elem.out_sg, s);
+        iov2 = iov;
+
         s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
         iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
         if (s != sizeof(ctrl)) {
@@ -833,6 +837,7 @@ static void virtio_net_handle_ctrl(VirtIODevice
*vdev, VirtQueue *vq)
 
         virtqueue_push(vq, &elem, sizeof(status));
         virtio_notify(vdev, vq);
+        g_free(iov2);
     }
 }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 05:48:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 05:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtVSM-0007OW-0g; Wed, 26 Nov 2014 05:48:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtVSK-0007OR-4u
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 05:48:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B5/DF-09842-F8965745; Wed, 26 Nov 2014 05:47:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416980877!12600222!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24302 invoked from network); 26 Nov 2014 05:47:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 05:47:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,460,1413244800"; d="scan'208";a="196905141"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 00:47:55 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtVSE-0007oJ-UJ;
	Wed, 26 Nov 2014 05:47:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtVSE-0000cD-NK;
	Wed, 26 Nov 2014 05:47:54 +0000
Date: Wed, 26 Nov 2014 05:47:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31853-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31853: 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 31853 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31853/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31835

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  104072fc1c7e6ed117c70fa7f91ecc9946f8f654
baseline version:
 xen                  6913fa31fa898f45ecc3b00e2397b8ebc75c8df4

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=104072fc1c7e6ed117c70fa7f91ecc9946f8f654
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 104072fc1c7e6ed117c70fa7f91ecc9946f8f654
+ branch=xen-unstable
+ revision=104072fc1c7e6ed117c70fa7f91ecc9946f8f654
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 104072fc1c7e6ed117c70fa7f91ecc9946f8f654:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   6913fa3..104072f  104072fc1c7e6ed117c70fa7f91ecc9946f8f654 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 05:48:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 05:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtVSM-0007OW-0g; Wed, 26 Nov 2014 05:48:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtVSK-0007OR-4u
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 05:48:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B5/DF-09842-F8965745; Wed, 26 Nov 2014 05:47:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1416980877!12600222!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24302 invoked from network); 26 Nov 2014 05:47:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 05:47:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,460,1413244800"; d="scan'208";a="196905141"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 00:47:55 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtVSE-0007oJ-UJ;
	Wed, 26 Nov 2014 05:47:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtVSE-0000cD-NK;
	Wed, 26 Nov 2014 05:47:54 +0000
Date: Wed, 26 Nov 2014 05:47:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31853-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31853: 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 31853 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31853/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31835

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  104072fc1c7e6ed117c70fa7f91ecc9946f8f654
baseline version:
 xen                  6913fa31fa898f45ecc3b00e2397b8ebc75c8df4

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=104072fc1c7e6ed117c70fa7f91ecc9946f8f654
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 104072fc1c7e6ed117c70fa7f91ecc9946f8f654
+ branch=xen-unstable
+ revision=104072fc1c7e6ed117c70fa7f91ecc9946f8f654
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 104072fc1c7e6ed117c70fa7f91ecc9946f8f654:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   6913fa3..104072f  104072fc1c7e6ed117c70fa7f91ecc9946f8f654 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 06:19:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 06: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 1XtVwM-0007q5-EG; Wed, 26 Nov 2014 06:19:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtVwL-0007q0-CP
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 06:19:01 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	9F/BC-08051-3D075745; Wed, 26 Nov 2014 06:18:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416982737!11553705!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18566 invoked from network); 26 Nov 2014 06:18:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 06:18:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,460,1413244800"; d="scan'208";a="196911337"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 01:18:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtVwG-0007xd-7Z;
	Wed, 26 Nov 2014 06:18:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtVwG-0001nL-1F;
	Wed, 26 Nov 2014 06:18:56 +0000
Date: Wed, 26 Nov 2014 06:18:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31854-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31854: 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 31854 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31854/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-xl-credit2    9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin  9 guest-start             fail baseline untested
 test-amd64-i386-xl           11 guest-saverestore       fail baseline untested
 test-amd64-amd64-xl-sedf     12 guest-localmigrate      fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu 11 guest-saverestore       fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                a4cfa44aa26a44c4a1885034f97eb72f2ab3b94b
baseline version:
 linux                8a84e01e147f44111988f9d8ccd2eaa30215a0f2

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 06:19:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 06: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 1XtVwM-0007q5-EG; Wed, 26 Nov 2014 06:19:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtVwL-0007q0-CP
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 06:19:01 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	9F/BC-08051-3D075745; Wed, 26 Nov 2014 06:18:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416982737!11553705!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18566 invoked from network); 26 Nov 2014 06:18:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 06:18:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,460,1413244800"; d="scan'208";a="196911337"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 01:18:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtVwG-0007xd-7Z;
	Wed, 26 Nov 2014 06:18:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtVwG-0001nL-1F;
	Wed, 26 Nov 2014 06:18:56 +0000
Date: Wed, 26 Nov 2014 06:18:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31854-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31854: 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 31854 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31854/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-xl-credit2    9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin  9 guest-start             fail baseline untested
 test-amd64-i386-xl           11 guest-saverestore       fail baseline untested
 test-amd64-amd64-xl-sedf     12 guest-localmigrate      fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu 11 guest-saverestore       fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-pair        16 guest-start/debian      fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                a4cfa44aa26a44c4a1885034f97eb72f2ab3b94b
baseline version:
 linux                8a84e01e147f44111988f9d8ccd2eaa30215a0f2

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 07:22:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 07:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtWv3-00009Z-8y; Wed, 26 Nov 2014 07:21:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hanyandong@iie.ac.cn>) id 1XtWv1-00009S-LT
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 07:21:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4E/07-15461-68F75745; Wed, 26 Nov 2014 07:21:42 +0000
X-Env-Sender: hanyandong@iie.ac.cn
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416986500!15387387!1
X-Originating-IP: [159.226.251.21]
X-SpamReason: No, hits=1.0 required=7.0 tests=ratty_date: Non-RFC but 
	legit format in Wed, 26 Nov 2014 15:21:38 +0800 (GMT+08:00), HTML_10_20,
	HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28177 invoked from network); 26 Nov 2014 07:21:41 -0000
Received: from smtp21.cstnet.cn (HELO cstnet.cn) (159.226.251.21)
	by server-12.tower-21.messagelabs.com with SMTP;
	26 Nov 2014 07:21:41 -0000
Received: by ajax-webmail-app1 (Coremail) ; Wed, 26 Nov 2014 15:21:38 +0800
	(GMT+08:00)
Date: Wed, 26 Nov 2014 15:21:38 +0800 (GMT+08:00)
From: hanyandong <hanyandong@iie.ac.cn>
To: xen-devel@lists.xen.org
Message-ID: <1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn>
MIME-Version: 1.0
X-Originating-IP: [159.226.95.66]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT2.1.10 dev build
	20131120(24194.5778.5783) Copyright (c) 2002-2014 www.mailtech.cn
	cstnet
X-SendMailWithSms: false
X-CM-CTRLDATA: PVt/FGZvb3Rlcl9odG09NDAxOjEyJmZvb3Rlcl90eHQ9MzM4OjY=
X-CM-TRANSID: RgCowJD7z_SDf3VU2HHcAQ--.10179W
X-CM-SenderInfo: 5kdq5txqgr0wo6llvhldfou0/1tbiBgIABlNabEnHXAAAs1
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw
	CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI
	daVFxhVjvjDU=
Subject: [Xen-devel] About lost record of xentrace, how to avoid lost record?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3296936916625564775=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3296936916625564775==
Content-Type: multipart/alternative; 
	boundary="----=_Part_1005425_25389031.1416986498685"

------=_Part_1005425_25389031.1416986498685
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

hi all,
I found xentrace will lost record if there are too many  event to trace.
But every event is important to me, so I want to trace all of them, not lost one.
what  could I do to achieve this goal ?

If it need to modify the source code of xentrace, I will do it. But will anyone give me some instructions?



--
Best Regards,
yandong



------=_Part_1005425_25389031.1416986498685
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

hi all,<br>I found xentrace will lost record if there are too many&nbsp; event to trace.<br>But every event is important to me, so I want to trace all of them, not lost one.<br>what&nbsp; could I do to achieve this goal ?<br><br>If it need to modify the source code of xentrace, I will do it. But will anyone give me some instructions?<br><br><br><span><br>--<br>Best Regards,<div>yandong</div></span><br><br><br>
------=_Part_1005425_25389031.1416986498685--



--===============3296936916625564775==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3296936916625564775==--



From xen-devel-bounces@lists.xen.org Wed Nov 26 07:22:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 07:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtWv3-00009Z-8y; Wed, 26 Nov 2014 07:21:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hanyandong@iie.ac.cn>) id 1XtWv1-00009S-LT
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 07:21:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4E/07-15461-68F75745; Wed, 26 Nov 2014 07:21:42 +0000
X-Env-Sender: hanyandong@iie.ac.cn
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416986500!15387387!1
X-Originating-IP: [159.226.251.21]
X-SpamReason: No, hits=1.0 required=7.0 tests=ratty_date: Non-RFC but 
	legit format in Wed, 26 Nov 2014 15:21:38 +0800 (GMT+08:00), HTML_10_20,
	HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28177 invoked from network); 26 Nov 2014 07:21:41 -0000
Received: from smtp21.cstnet.cn (HELO cstnet.cn) (159.226.251.21)
	by server-12.tower-21.messagelabs.com with SMTP;
	26 Nov 2014 07:21:41 -0000
Received: by ajax-webmail-app1 (Coremail) ; Wed, 26 Nov 2014 15:21:38 +0800
	(GMT+08:00)
Date: Wed, 26 Nov 2014 15:21:38 +0800 (GMT+08:00)
From: hanyandong <hanyandong@iie.ac.cn>
To: xen-devel@lists.xen.org
Message-ID: <1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn>
MIME-Version: 1.0
X-Originating-IP: [159.226.95.66]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT2.1.10 dev build
	20131120(24194.5778.5783) Copyright (c) 2002-2014 www.mailtech.cn
	cstnet
X-SendMailWithSms: false
X-CM-CTRLDATA: PVt/FGZvb3Rlcl9odG09NDAxOjEyJmZvb3Rlcl90eHQ9MzM4OjY=
X-CM-TRANSID: RgCowJD7z_SDf3VU2HHcAQ--.10179W
X-CM-SenderInfo: 5kdq5txqgr0wo6llvhldfou0/1tbiBgIABlNabEnHXAAAs1
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw
	CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI
	daVFxhVjvjDU=
Subject: [Xen-devel] About lost record of xentrace, how to avoid lost record?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3296936916625564775=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3296936916625564775==
Content-Type: multipart/alternative; 
	boundary="----=_Part_1005425_25389031.1416986498685"

------=_Part_1005425_25389031.1416986498685
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

hi all,
I found xentrace will lost record if there are too many  event to trace.
But every event is important to me, so I want to trace all of them, not lost one.
what  could I do to achieve this goal ?

If it need to modify the source code of xentrace, I will do it. But will anyone give me some instructions?



--
Best Regards,
yandong



------=_Part_1005425_25389031.1416986498685
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

hi all,<br>I found xentrace will lost record if there are too many&nbsp; event to trace.<br>But every event is important to me, so I want to trace all of them, not lost one.<br>what&nbsp; could I do to achieve this goal ?<br><br>If it need to modify the source code of xentrace, I will do it. But will anyone give me some instructions?<br><br><br><span><br>--<br>Best Regards,<div>yandong</div></span><br><br><br>
------=_Part_1005425_25389031.1416986498685--



--===============3296936916625564775==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3296936916625564775==--



From xen-devel-bounces@lists.xen.org Wed Nov 26 08:09:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 08:09:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtXfK-000186-PX; Wed, 26 Nov 2014 08:09:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XtXfJ-000181-B0
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 08:09:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B6/8B-09842-CBA85745; Wed, 26 Nov 2014 08:09:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416989372!15332253!1
X-Originating-IP: [81.169.146.217]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25646 invoked from network); 26 Nov 2014 08:09:32 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 08:09:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416989371; l=665;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=LjufdXG8/qtLlKx8Xe9LaHaf3RQ=;
	b=ghtx9LwmHxmt+vPzDRB7XxBm0CqMUb6TI3abHSKx6BfckuI90roRR4ma7x+tAM2ClOk
	knhYfBqMlXAyQ0DsyoyWf5+tFZL/5H7o+oiDCxbnIaULmdrwt178YOi80JfRyXQ0HhXXB
	KsBmD6S37AFBmSlYdqOZ6EfjkkXzW9BKBcI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.13 AUTH) with ESMTPSA id 205ec0qAQ89DpNh
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 26 Nov 2014 09:09:13 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0E0AA50172; Wed, 26 Nov 2014 09:09:12 +0100 (CET)
Date: Wed, 26 Nov 2014 09:09:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141126080912.GA944@aepfle.de>
References: <5474DE5A.2060000@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5474DE5A.2060000@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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, Nov 25, Andrew Cooper wrote:

> The purpose of this email is to plan how to progress the migrationv2
> series through to being merged.  I believe I have CC'd everyone with a
> specific interest in this area, but apologies if I have missed anyone.

While you mow that lawn, did you guys think of handling downtime of the
migrated VM? I added some knobs to abort migration in a very libxc
specific way. What I would like to see is a simple user interface for
virsh/xl to control the downtime. See the thread "limit downtime during
life migration from xl/virsh":

http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 08:09:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 08:09:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtXfK-000186-PX; Wed, 26 Nov 2014 08:09:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XtXfJ-000181-B0
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 08:09:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B6/8B-09842-CBA85745; Wed, 26 Nov 2014 08:09:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1416989372!15332253!1
X-Originating-IP: [81.169.146.217]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25646 invoked from network); 26 Nov 2014 08:09:32 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 08:09:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416989371; l=665;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=LjufdXG8/qtLlKx8Xe9LaHaf3RQ=;
	b=ghtx9LwmHxmt+vPzDRB7XxBm0CqMUb6TI3abHSKx6BfckuI90roRR4ma7x+tAM2ClOk
	knhYfBqMlXAyQ0DsyoyWf5+tFZL/5H7o+oiDCxbnIaULmdrwt178YOi80JfRyXQ0HhXXB
	KsBmD6S37AFBmSlYdqOZ6EfjkkXzW9BKBcI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 35.13 AUTH) with ESMTPSA id 205ec0qAQ89DpNh
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 26 Nov 2014 09:09:13 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0E0AA50172; Wed, 26 Nov 2014 09:09:12 +0100 (CET)
Date: Wed, 26 Nov 2014 09:09:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141126080912.GA944@aepfle.de>
References: <5474DE5A.2060000@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5474DE5A.2060000@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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, Nov 25, Andrew Cooper wrote:

> The purpose of this email is to plan how to progress the migrationv2
> series through to being merged.  I believe I have CC'd everyone with a
> specific interest in this area, but apologies if I have missed anyone.

While you mow that lawn, did you guys think of handling downtime of the
migrated VM? I added some knobs to abort migration in a very libxc
specific way. What I would like to see is a simple user interface for
virsh/xl to control the downtime. See the thread "limit downtime during
life migration from xl/virsh":

http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 09:07:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 09:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtYZI-0001kW-AV; Wed, 26 Nov 2014 09:07:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@vmm.sh.intel.com>) id 1XtYZG-0001kR-Ku
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 09:07:22 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C7/6C-02696-A4895745; Wed, 26 Nov 2014 09:07:22 +0000
X-Env-Sender: robert.hu@vmm.sh.intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416992839!11593974!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31638 invoked from network); 26 Nov 2014 09:07:20 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-11.tower-27.messagelabs.com with SMTP;
	26 Nov 2014 09:07:20 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 26 Nov 2014 01:00:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="421667752"
Received: from unknown (HELO [10.239.36.23]) ([10.239.36.23])
	by FMSMGA003.fm.intel.com with ESMTP; 26 Nov 2014 00:57:29 -0800
Message-ID: <1416993315.30509.2.camel@rbt-linux-pc>
From: Robert Hu <robert.hu@vmm.sh.intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 26 Nov 2014 17:15:15 +0800
In-Reply-To: <1415958176.21321.18.camel@citrix.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
Organization: Intel OTC
X-Mailer: Evolution 3.8.5 (3.8.5-21.el7) 
Mime-Version: 1.0
Cc: "Hu, Robert" <robert.hu@intel.com>, Fabio Fantoni <fabio.fantoni@m2r.biz>,
	Wei Liu <wei.liu2@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: robert.hu@intel.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 09:42 +0000, Ian Campbell wrote:
> I've not seen an individual thread on this one, so replying here.
> 
> On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:
> 
> > > 6. Networking is unavailable after save&restore Windows guest
> > >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> > 
> > Should be the same problem I reported 1 year ago or more and still 
> > present, the workaround is use fixed mac address in domUs xl cfg :(
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
> 
> Wei, shouldn't your json migration thing have solved this? (this being
> the preservation of a vif's mac addr over migration?)
> 
> Robert, all reports of toolstack bugs should include a full set of logs.
> See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
> advice on reporting bugs as well as lists of specific things which
> should be included.
> 
> Ian.
> 
This issue went away in Xen 4.5 RC2.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 09:07:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 09:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtYZI-0001kW-AV; Wed, 26 Nov 2014 09:07:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@vmm.sh.intel.com>) id 1XtYZG-0001kR-Ku
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 09:07:22 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C7/6C-02696-A4895745; Wed, 26 Nov 2014 09:07:22 +0000
X-Env-Sender: robert.hu@vmm.sh.intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1416992839!11593974!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31638 invoked from network); 26 Nov 2014 09:07:20 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-11.tower-27.messagelabs.com with SMTP;
	26 Nov 2014 09:07:20 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 26 Nov 2014 01:00:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="421667752"
Received: from unknown (HELO [10.239.36.23]) ([10.239.36.23])
	by FMSMGA003.fm.intel.com with ESMTP; 26 Nov 2014 00:57:29 -0800
Message-ID: <1416993315.30509.2.camel@rbt-linux-pc>
From: Robert Hu <robert.hu@vmm.sh.intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 26 Nov 2014 17:15:15 +0800
In-Reply-To: <1415958176.21321.18.camel@citrix.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<54632F72.7020509@m2r.biz> <1415958176.21321.18.camel@citrix.com>
Organization: Intel OTC
X-Mailer: Evolution 3.8.5 (3.8.5-21.el7) 
Mime-Version: 1.0
Cc: "Hu, Robert" <robert.hu@intel.com>, Fabio Fantoni <fabio.fantoni@m2r.biz>,
	Wei Liu <wei.liu2@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: robert.hu@intel.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-14 at 09:42 +0000, Ian Campbell wrote:
> I've not seen an individual thread on this one, so replying here.
> 
> On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:
> 
> > > 6. Networking is unavailable after save&restore Windows guest
> > >    http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898
> > 
> > Should be the same problem I reported 1 year ago or more and still 
> > present, the workaround is use fixed mac address in domUs xl cfg :(
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html
> > http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html
> 
> Wei, shouldn't your json migration thing have solved this? (this being
> the preservation of a vif's mac addr over migration?)
> 
> Robert, all reports of toolstack bugs should include a full set of logs.
> See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for general
> advice on reporting bugs as well as lists of specific things which
> should be included.
> 
> Ian.
> 
This issue went away in Xen 4.5 RC2.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 09:32:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 09: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 1XtYxM-000268-G3; Wed, 26 Nov 2014 09:32: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 1XtYxL-000263-IW
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 09:32:15 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	6B/FA-29352-E1E95745; Wed, 26 Nov 2014 09:32:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416994332!13358047!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20936 invoked from network); 26 Nov 2014 09:32:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 09:32:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,461,1413244800"; d="scan'208";a="196702965"
Message-ID: <1416994330.11944.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 26 Nov 2014 09:32:10 +0000
In-Reply-To: <alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
	<alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 17:05 +0000, Stefano Stabellini wrote:
> On Tue, 25 Nov 2014, Ian Campbell wrote:
> > On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > > each them. Assume 256K each.
> > > > 
> > > > I suppose this will have to do for 4.5. Can we do something better in
> > > > the future -- like figuring out a way for guests to have
> > > > "not-really-RAM" allocations like this which are made by the toolstack
> > > > and happen to be backed by RAM not count or something.
> > > > 
> > > > > 
> > > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > > assigned to a VM.
> > > > 
> > > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > > option roms? abort() seems a bit extreme.
> > > > 
> > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > CC: Don Slutz <dslutz@verizon.com>
> > > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > > 
> > > > You missed Ian J. I've added him.
> > > 
> > > Actually Wei suggested a better alternative: I could call
> > > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> > 
> > xl mem-set would do it again, but not taking qemu's extras into account,
> > unless you communicate the overhead somehow...
> 
> We could start reading the current maxmem and add to it in
> libxl_set_memory_target. Or we could write the maxmem to xenstore and
> read it back again.  Given that the allocations are only done by QEMU at
> initialization time, I don't think we need to worry about concurrency
> here.

Might work, but it's a bit scary for 4.5, I would expect there to be
subtle knock on effects from this sort of thing :-/



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 09:32:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 09: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 1XtYxM-000268-G3; Wed, 26 Nov 2014 09:32: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 1XtYxL-000263-IW
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 09:32:15 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	6B/FA-29352-E1E95745; Wed, 26 Nov 2014 09:32:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1416994332!13358047!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20936 invoked from network); 26 Nov 2014 09:32:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 09:32:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,461,1413244800"; d="scan'208";a="196702965"
Message-ID: <1416994330.11944.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 26 Nov 2014 09:32:10 +0000
In-Reply-To: <alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
	<alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 17:05 +0000, Stefano Stabellini wrote:
> On Tue, 25 Nov 2014, Ian Campbell wrote:
> > On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > > each them. Assume 256K each.
> > > > 
> > > > I suppose this will have to do for 4.5. Can we do something better in
> > > > the future -- like figuring out a way for guests to have
> > > > "not-really-RAM" allocations like this which are made by the toolstack
> > > > and happen to be backed by RAM not count or something.
> > > > 
> > > > > 
> > > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > > assigned to a VM.
> > > > 
> > > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > > option roms? abort() seems a bit extreme.
> > > > 
> > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > CC: Don Slutz <dslutz@verizon.com>
> > > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > > 
> > > > You missed Ian J. I've added him.
> > > 
> > > Actually Wei suggested a better alternative: I could call
> > > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> > 
> > xl mem-set would do it again, but not taking qemu's extras into account,
> > unless you communicate the overhead somehow...
> 
> We could start reading the current maxmem and add to it in
> libxl_set_memory_target. Or we could write the maxmem to xenstore and
> read it back again.  Given that the allocations are only done by QEMU at
> initialization time, I don't think we need to worry about concurrency
> here.

Might work, but it's a bit scary for 4.5, I would expect there to be
subtle knock on effects from this sort of thing :-/



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 09:44:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 09:44:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtZ94-0002Iq-NY; Wed, 26 Nov 2014 09:44:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtZ93-0002Il-07
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 09:44:21 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	2B/77-28865-4F0A5745; Wed, 26 Nov 2014 09:44:20 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416995059!13414258!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2080 invoked from network); 26 Nov 2014 09:44:19 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 09:44:19 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 2941CAAF1;
	Wed, 26 Nov 2014 09:44:18 +0000 (UTC)
Message-ID: <5475A0F0.6060402@suse.com>
Date: Wed, 26 Nov 2014 10:44:16 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
References: <20141114213124.GB3344@redhat.com>	<CA+55aFx16ks_azU0eAcx+qZ5-o8Xo0zzP6aNjrskai8rqp+eMg@mail.gmail.com>	<20141115213405.GA31971@redhat.com>	<20141116014006.GA5016@redhat.com>	<CA+55aFwLH6zGf7O=o2+H0Z8=8nW4zwUbw3Q4bJGttHACv9g+FQ@mail.gmail.com>	<20141126002501.GA11752@redhat.com>	<CA+55aFy9c2FY2gDw14VU537QJoLHAbf+q_75VUwU33_HLz+F0w@mail.gmail.com>	<5475596A.9010301@suse.com>	<CA+55aFx1SiFBzmA=k9jHxi3cZE3Ei_+2NHepujgf86KEvkz8eQ@mail.gmail.com>	<54756424.6020409@suse.com>	<CA+55aFzVyTi_pR4y3=Z3y1bWkXbvgoJaykoyn0pUE7eTYgr+ZQ@mail.gmail.com>
	<CA+55aFzOSfdvgrkfiN=zZg4mSoot-tJQiVRh5ENW2-rzmLMy1w@mail.gmail.com>
In-Reply-To: <CA+55aFzOSfdvgrkfiN=zZg4mSoot-tJQiVRh5ENW2-rzmLMy1w@mail.gmail.com>
Content-Length: 8973
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Dave Jones <davej@redhat.com>
Subject: Re: [Xen-devel] frequent lockups in 3.18rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

T24gMTEvMjYvMjAxNCAwNzoyMSBBTSwgTGludXMgVG9ydmFsZHMgd3JvdGU6Cj4gT24gVHVlLCBO
b3YgMjUsIDIwMTQgYXQgOTo1MiBQTSwgTGludXMgVG9ydmFsZHMKPiA8dG9ydmFsZHNAbGludXgt
Zm91bmRhdGlvbi5vcmc+IHdyb3RlOgo+Pgo+PiBBbmQgbGVhdmUgaXQgcnVubmluZyBmb3IgYSB3
aGlsZSwgYW5kIHNlZSBpZiB0aGUgdHJhY2UgaXMgYWx3YXlzIHRoZQo+PiBzYW1lLCBvciBpZiB0
aGVyZSBhcmUgdmFyaWF0aW9ucyBvbiBpdC4uLgo+Cj4gQW11c2luZy4KPgo+IExvb2tpZSBoZXJl
Ogo+Cj4gICAgIGh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9hcmNoaXZlcy9odG1sL3hlbi1j
aGFuZ2Vsb2cvMjAwNS0wOC9tc2cwMDMxMC5odG1sCj4KPiBUaGF0J3MgZnJvbSAyMDA1Lgo+Cj4g
QW55d2F5LCBJIGRvbid0IHNlZSB3aHkgdGhlIGNyMyBpc3N1ZSBtYXR0ZXJzLCAqdW5sZXNzKiB0
aGVyZSBpcyBzb21lCj4gc2l0dWF0aW9uIHdoZXJlIHRoZSBzY2hlZHVsZXIgY2FuIHJ1biB3aXRo
IGludGVycnVwdHMgZW5hYmxlZC4gQW5kIHdoeQo+IHRoaXMgaXMgWGVuLXJlbGF0ZWQsIEkgaGF2
ZSBubyBpZGVhLgo+Cj4gVGhlIFhlbiBwYXRjaGVzIHNlZW0gdG8gaGF2ZSBsb3N0IHRoYXQKPgo+
ICAgLyogT24gWGVuIHRoZSBsaW5lIGJlbG93IGRvZXMgbm90IGFsd2F5cyB3b3JrLiBOZWVkcyBp
bnZlc3RpZ2F0aW5nISAqLwo+Cj4gbGluZSB3aGVuIGJhY2twb3J0aW5nIHRoZSAyLjYuMjkgcGF0
Y2hlcyB0byBYZW4uIEFuZCBjbGVhcmx5IG5vYm9keQo+IGludmVzdGlnYXRlZC4KPgo+IFNvIHBs
ZWFzZSBkbyBnZXQgbWUgYmFjay10cmFjZXMsIGFuZCB3ZSdsbCBpbnZlc3RpZ2F0ZS4gQmV0dGVy
IGxhdGUKPiB0aGFuIG5ldmVyLiBCdXQgaXQgZG9lcyBzb3VuZCBYZW4tc3BlY2lmaWMgLSBhbHRo
b3VnaCBpdCdzIHBvc3NpYmxlCj4gdGhhdCBYZW4ganVzdCB0cmlnZ2VycyBzb21lIHRpbWluZyAo
YW5kIGhhcyBhcHBhcmVudGx5IGJlZW4gYWJsZSB0bwo+IHRyaWdnZXIgaXQgc2luY2UgMjAwNSkg
dGhhdCBEYXZlSiBub3cgdHJpZ2dlcnMgb24gaGlzIG9uZSBtYWNoaW5lLgo+Cj4gU28gRGF2ZUos
IGV2ZW4gdGhvdWdoIHRoaXMgZG9lcyBhcHBlYXIgWGVuLWNlbnRyaWMgKFhlbnRyaWM/KSBhbmQK
PiB5b3UncmUgcnVubmluZyBvbiBiYXJlIGhhcmR3YXJlLCBtYXliZSB5b3UgY291bGQgZG8gdGhl
IHNhbWUgdGhpbmcgaW4KPiB0aGF0IHg4Ni02NCB2bWFsbG9jX2ZhdWx0KCkuIFRoZSB0aW1pbmcg
d2l0aCBKw7xyZ2VuIGlzIGtpbmQgb2YKPiBpbnRyaWd1aW5nIC0gaWYgMy4xOC1yYyBtYWRlIGl0
IGhhcHBlbiBtdWNoIG1vcmUgb2Z0ZW4gZm9yIGhpbSwgbWF5YmUKPiBpdCByZWFsbHkgaXMgdmVy
eSB0aW1pbmctc2Vuc2l0aXZlLCBhbmQgeW91IGFjdHVhbGx5IGFyZSBzZWVpbmcgYQo+IG5vbi1Y
ZW4gdmVyc2lvbiBvZiB0aGUgc2FtZSB0aGluZy4uLgoKVmVyeSBpbnRlcmVzdGluZzogSSd2ZSB1
cGRhdGVkIG15IHRlc3QtbWFjaGluZSB5ZXN0ZXJkYXkgdG8gdGhlIG5ld2VzdApYZW4gdmVyc2lv
biBhZnRlciBJJ3ZlIGdvdCByaWQgb2YgdGhlIGxvY2t1cHMgdG8gYXZvaWQgYW5vdGhlciBwcm9i
bGVtCkkgd2FzIHNlZWluZy4gV2l0aCB0aGlzIHZlcnNpb24gSSBkb24ndCBnZXQgdGhlIGxvY2t1
cHMgYW55IG1vcmUgZXZlbgp3aXRoIHRoZSB1bm1vZGlmaWVkIDMuMTgtcmMga2VybmVsLgoKRGln
Z2luZyBkZWVwZXIgSSBmb3VuZCBzb21ldGhpbmcgbWFraW5nIG1lIGJlbGlldmUgSSd2ZSBzZWVu
IGFub3RoZXIKaXNzdWUgdGhhbiBEYXZlIHdoaWNoIGp1c3QgbG9va2VkIHNpbWlsYXIgb24gdGhl
IHN1cmZhY2UuIDotKAoKTXkgWGVuIHByb2JsZW0gd2FzIHJlbGF0ZWQgdG8gYW4gZXJyb3IgaW4g
ZnJlZWluZyBncmFudCBwYWdlcyAocGFnZXMKbWFwcGVkIGluIGZyb20gYW5vdGhlciBkb21haW4p
LiBPbmUgZGV0YWlsIGluIHRoZSBoYW5kbGluZyBvZiBzdWNoCm1hcHBpbmdzIGlzIGludGVyZXN0
aW5nOiB0aGUgInByaXZhdGUiIG1lbWJlciBvZiB0aGUgcGFnZSBzdHJ1Y3R1cmUKaXMgdXNlZCB0
byBob2xkIHRoZSBtYWNoaW5lIGZyYW1lIG51bWJlciBvZiB0aGUgbWFwcGVkIG1lbW9yeSBwYWdl
LgpBbm90aGVyIHVzYWdlIG9mIHRoaXMgInByaXZhdGUiIG1lbWJlciBpcyBpbiB0aGUgcGdkIGhh
bmRsaW5nIG9mIFhlbgooc2VlIHhlbl9wZ2RfYWxsb2MoKSBhbmQgeGVuX2dldF91c2VyX3BnZCgp
KSB0byBob2xkIHRoZSBwZ2Qgb2YgdGhlCnVzZXIgYWRkcmVzcyBzcGFjZSAoa2VybmVsIGFuZCB1
c2VyIGFyZSBpbiBzZXBhcmF0ZSBhZGRyZXNzIHNwYWNlcyBvbgpYZW4pLiBTbyB3aXRoIGFuIGVy
cm9yIGluIHRoZSBncmFudCBwYWdlIGhhbmRsaW5nIEkgY291bGQgaW1hZ2luZSBhCnBnZCdzIHBy
aXZhdGUgbWVtYmVyIGNvdWxkIGJlIGNsb2JiZXJlZCBsZWFkaW5nIHRvIGVmZmVjdHMgbGlrZSB0
aGUgb25lCkkndmUgb2JzZXJ2ZWQuIEFuZCB0aGlzIGNvdWxkIGhhdmUgYmVlbiB0aGUgcHJvYmxl
bSBpbiAyMDA1LCB0b28uCgpBbmQgd2h5IGlzIG15IHBhdGNoIHdvcmtpbmc/IEkgdGhpbmsgaXQn
cyBqdXN0IGJlY2F1c2UgY3IzIGlzIGFsd2F5cwp3cml0dGVuIHdpdGggYSBwYWdlIGFsaWduZWQg
dmFsdWUgd2hpbGUgdGhlIGNsb2JiZXJlZCAicHJpdmF0ZSIgbWVtYmVyCm9mIHRoZSBYZW4gcGdk
IGlzIG5vdCBwYWdlIGFsaWduZWQgcmVzdWx0aW5nIGluIGEgZGlmZmVyZW50IHBvaW50ZXIuCkkn
bSBzdGlsbCB1c2luZyB0aGUgd3JvbmcgcGFnZSBmb3IgdGhlIHVzZXIncyBwZ2QsIGJ1dCB0aGlz
IHNlZW1zIG5vdAp0byBsZWFkIHRvIGZhdGFsIGVycm9ycyB3aGVuIG5lYXJseSBub3RoaW5nIGlz
IHJ1bm5pbmcgb24gdGhlIG1hY2hpbmUuCkkndmUgc2VlbiBYZW4gbWVzc2FnZXMgb2NjYXNpb25h
bGx5IGluZGljYXRpbmcgdGhlcmUgd2FzIHNvbWV0aGluZwp3cm9uZyB3aXRoIHRoZSBwYWdlIHRh
YmxlIGhhbmRsaW5nIG9mIHRoZSBrZXJuZWwgKHBhZ2VzIHVzZWQgYXMgcGFnZQp0YWJsZXMgbm90
IGtub3duIHRvIFhlbiBhcyBzdWNoKS4KCkkgaG9wZSB0aGlzIGFsbCBtYWtlcyBzZW5zZS4KCkFu
ZCBqdXN0IGZvciB0aGUgcmVjb3Jkczogd2l0aCB0aGUgYWN0dWFsIFhlbiB2ZXJzaW9uICh0d2Vh
a2VkIHRvCnNob3cgdGhlIGdyYW50IHBhZ2UgZXJyb3IgYWdhaW4pIEkgc2VlIGRpZmZlcmVudCBs
b2NrdXBzIHdpdGggdGhlCmZvbGxvd2luZyBiYWNrdHJhY2U6CgpbIDExMjIuMjU2MzA1XSBOTUkg
d2F0Y2hkb2c6IEJVRzogc29mdCBsb2NrdXAgLSBDUFUjOTQgc3R1Y2sgZm9yIDIzcyEgCltzeXN0
ZW1kLXVkZXZkOjExNzldClsgMTEyMi4zMDM0MjddIE1vZHVsZXMgbGlua2VkIGluOiB4ZW5fYmxr
ZnJvbnQgbXNyIGJyaWRnZSBzdHAgbGxjIAppc2NzaV9pYmZ0IGlwbWlfZGV2aW50ZiBubHNfdXRm
OCB4ODZfcGtnX3RlbXBfdGhlcm1hbCBpbnRlbF9wb3dlcmNsYW1wIApubHNfY3A0MzcgY29yZXRl
bXAgY3JjdDEwZGlmX3BjbG11bCB2ZmF0IGNyYzMyX3BjbG11bCBmYXQgY3JjMzJjX2ludGVsIApn
aGFzaF9jbG11bG5pX2ludGVsIHNuZF9wY20gYWVzbmlfaW50ZWwgYWVzX3g4Nl82NCBzbmRfdGlt
ZXIgbHJ3IApiZTJpc2NzaSBiZTJuZXQgZ2YxMjhtdWwgbGliaXNjc2kgc25kIGdsdWVfaGVscGVy
IGpveWRldiB2eGxhbiBzb3VuZGNvcmUgCnNjc2lfdHJhbnNwb3J0X2lzY3NpIGFibGtfaGVscGVy
IGlUQ09fd2R0IGl4Z2JlIGlnYiBtZGlvIGlwNl91ZHBfdHVubmVsIAppVENPX3ZlbmRvcl9zdXBw
b3J0IGVmaXZhcnMgZXZkZXYgaXNjc2lfYm9vdF9zeXNmcyB1ZHBfdHVubmVsIGNyeXB0ZCBkY2Eg
CnBjc3BrciBzYl9lZGFjIGUxMDAwZSBlZGFjX2NvcmUgbHBjX2ljaCBpMmNfaTgwMSBwdHAgbWZk
X2NvcmUgcHBzX2NvcmUgCnNocGNocCB0cG1faW5maW5lb24gaXBtaV9zaSB0cG1fdGlzIGlwbWlf
bXNnaGFuZGxlciB0cG0gYnV0dG9uIHhlbmZzIAp4ZW5fcHJpdmNtZCB4ZW5fYWNwaV9wcm9jZXNz
b3IgcHJvY2Vzc29yIHRoZXJtYWxfc3lzIHhlbl9wY2liYWNrIAp4ZW5fbmV0YmFjayB4ZW5fYmxr
YmFjayB4ZW5fZ250YWxsb2MgeGVuX2dudGRldiB4ZW5fZXZ0Y2huIGRtX21vZCAKZWZpdmFyZnMg
Y3JjMzJjX2dlbmVyaWMgYnRyZnMgeG9yIHJhaWQ2X3BxIGhpZF9nZW5lcmljClsgMTEyMi4zMDM0
NTBdICB1c2JoaWQgaGlkIHNkX21vZCBtZ2FnMjAwIGVoY2lfcGNpIGkyY19hbGdvX2JpdCBlaGNp
X2hjZCAKZHJtX2ttc19oZWxwZXIgdHRtIHVzYmNvcmUgZHJtIG1lZ2FyYWlkX3NhcyB1c2JfY29t
bW9uIHNnIHNjc2lfbW9kIGF1dG9mczQKWyAxMTIyLjMwMzQ1Nl0gQ1BVOiA5NCBQSUQ6IDExNzkg
Q29tbTogc3lzdGVtZC11ZGV2ZCBUYWludGVkOiBHIAogICAgIEwgMy4xOC4wLXJjNSsgIzMwNApb
IDExMjIuMzAzNDU4XSBIYXJkd2FyZSBuYW1lOiBGVUpJVFNVIFBSSU1FUVVFU1QgMjgwMEUvU0Is
IEJJT1MgClBSSU1FUVVFU1QgMjAwMCBTZXJpZXMgQklPUyBWZXJzaW9uIDAxLjU5IDA3LzI0LzIw
MTQKWyAxMTIyLjMwMzQ1OV0gdGFzazogZmZmZjg4MWYxN2I1NmNlMCB0aTogZmZmZjg4MWYwZmZm
MDAwMCB0YXNrLnRpOiAKZmZmZjg4MWYwZmZmMDAwMApbIDExMjIuMzAzNDYwXSBSSVA6IGUwMzA6
WzxmZmZmZmZmZjgxNGZjZjVlPl0gIFs8ZmZmZmZmZmY4MTRmY2Y1ZT5dIApfcmF3X3NwaW5fbG9j
aysweDFlLzB4MzAKWyAxMTIyLjMwMzQ2Ml0gUlNQOiBlMDJiOmZmZmY4ODFmMGZmZjNjZTggIEVG
TEFHUzogMDAwMDAyODIKWyAxMTIyLjMwMzQ2M10gUkFYOiAwMDAwMDAwMDAwMDBiYTQzIFJCWDog
MDAwMDNmZmZmZmZmZjAwMCBSQ1g6IAowMDAwMDAwMDAwMDAwMTkwClsgMTEyMi4zMDM0NjRdIFJE
WDogMDAwMDAwMDAwMDAwMDE5MCBSU0k6IDAwMDAwMDE5MGJhNDMwNjcgUkRJOiAKZmZmZmVhMDAw
MTU3YzM1MApbIDExMjIuMzAzNDY1XSBSQlA6IGZmZmY4ODAwMDAwMDBjNzAgUjA4OiAwMDAwMDAw
MDAwMDAwMDAwIFIwOTogCjAwMDAwMDAwMDAwMDAwMDAKWyAxMTIyLjMwMzQ2Nl0gUjEwOiAwMDAw
MDAwMDAwMDFiNjg4IFIxMTogZmZmZjg4MWZkZjI0YWQ4MCBSMTI6IApmZmZmZWEwMDAwMDAwMDAw
ClsgMTEyMi4zMDM0NjZdIFIxMzogZmZmZjg4MDA2MjM3Y2M3MCBSMTQ6IDAwMDAwMDAwMDAwMDAw
MDAgUjE1OiAKMDAwMDdmNzBmNDM4ZTAwMApbIDExMjIuMzAzNDcwXSBGUzogIDAwMDA3ZjcwZjVj
NDk4ODAoMDAwMCkgR1M6ZmZmZjg4MWY0YzVjMDAwMCgwMDAwKSAKa25sR1M6ZmZmZjg4MWY0YzVj
MDAwMApbIDExMjIuMzAzNDcxXSBDUzogIGUwMzMgRFM6IDAwMDAgRVM6IDAwMDAgQ1IwOiAwMDAw
MDAwMDgwMDUwMDMzClsgMTEyMi4zMDM0NzJdIENSMjogMDAwMDdmNzBmNWM2ODAwMCBDUjM6IDAw
MDAwMDFmMTExYjcwMDAgQ1I0OiAKMDAwMDAwMDAwMDA0MjY2MApbIDExMjIuMzAzNDczXSBTdGFj
azoKWyAxMTIyLjMwMzQ3NF0gIGZmZmZmZmZmODExNTU4NTAgZmZmZjg4MWZkZjI0YWQ4MCAwMDAw
N2Y3MGY0MzhmMDAwIApmZmZmODgxZjEzOGFlNWQ4ClsgMTEyMi4zMDM0NzZdICBmZmZmODgxZjA4
ZWFkNDAwIGZmZmY4ODFmMGZmZjNmZDggMDAwMDAwMDAwMDAwMDAwMCAKZmZmZjg4MWVmZjBjYmQw
OApbIDExMjIuMzAzNDc3XSAgZmZmZjg4MWYxOGI1N2QwOCBmZmZmZWEwMDAxNTdjMzIwIGZmZmZl
YTAwNmNjYzVlYzggCmZmZmY4ODFmMGZjMDA4MDAKWyAxMTIyLjMwMzQ3OV0gQ2FsbCBUcmFjZToK
WyAxMTIyLjMwMzQ4MV0gIFs8ZmZmZmZmZmY4MTE1NTg1MD5dID8gY29weV9wYWdlX3JhbmdlKzB4
NDYwLzB4YTEwClsgMTEyMi4zMDM0ODRdICBbPGZmZmZmZmZmODEwNWQ3Mjc+XSA/IGNvcHlfcHJv
Y2Vzcy5wYXJ0LjI3KzB4MTNlNy8weDFiMTAKWyAxMTIyLjMwMzQ4Nl0gIFs8ZmZmZmZmZmY4MTQz
NWY0MT5dID8gbmV0bGlua19pbnNlcnQrMHg5MS8weGIwClsgMTEyMi4zMDM0ODhdICBbPGZmZmZm
ZmZmODEzZjg1Yzk+XSA/IHJlbGVhc2Vfc29jaysweDE5LzB4MTYwClsgMTEyMi4zMDM0OTBdICBb
PGZmZmZmZmZmODEwNWRmZjg+XSA/IGRvX2ZvcmsrMHhjOC8weDMyMApbIDExMjIuMzAzNDkyXSAg
WzxmZmZmZmZmZjgxNGZkNzc5Pl0gPyBzdHViX2Nsb25lKzB4NjkvMHg5MApbIDExMjIuMzAzNDkz
XSAgWzxmZmZmZmZmZjgxNGZkNDJkPl0gPyBzeXN0ZW1fY2FsbF9mYXN0cGF0aCsweDE2LzB4MWIK
WyAxMTIyLjMwMzQ5NF0gQ29kZTogOTAgMGYgYjcgMTcgNjYgMzkgZDAgNzUgZjYgZWIgZTggNjYg
OTAgYjggMDAgMDAgMDEgCjAwIGYwIDBmIGMxIDA3IDg5IGMyIGMxIGVhIDEwIDY2IDM5IGMyIDg5
IGQxIDc1IDAxIGMzIDBmIGI3IDA3IDY2IDM5IGQwIAo3NCBmNyA8ZjM+IDkwIDBmIGI3IDA3IDY2
IDM5IGM4IDc1IGY2IGMzIDBmIDFmIDgwIDAwIDAwIDAwIDAwIDY1IDgxIDA0CgpCdXQgaWYgbXkg
YXNzdW1wdGlvbnMgYWJvdmUgYXJlIGNvcnJlY3QgdGhpcyBpcyBtZWFuaW5nbGVzcywgYXMgdXNp
bmcKYW4gYXJiaXRyYXJ5IG1lbW9yeSBwYWdlIGFzIHBnZCBtaWdodCByZXN1bHQgaW4gYW55dGhp
bmcuLi4KCgpKdWVyZ2VuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Nov 26 09:44:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 09:44:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtZ94-0002Iq-NY; Wed, 26 Nov 2014 09:44:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtZ93-0002Il-07
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 09:44:21 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	2B/77-28865-4F0A5745; Wed, 26 Nov 2014 09:44:20 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1416995059!13414258!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2080 invoked from network); 26 Nov 2014 09:44:19 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 09:44:19 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 2941CAAF1;
	Wed, 26 Nov 2014 09:44:18 +0000 (UTC)
Message-ID: <5475A0F0.6060402@suse.com>
Date: Wed, 26 Nov 2014 10:44:16 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
References: <20141114213124.GB3344@redhat.com>	<CA+55aFx16ks_azU0eAcx+qZ5-o8Xo0zzP6aNjrskai8rqp+eMg@mail.gmail.com>	<20141115213405.GA31971@redhat.com>	<20141116014006.GA5016@redhat.com>	<CA+55aFwLH6zGf7O=o2+H0Z8=8nW4zwUbw3Q4bJGttHACv9g+FQ@mail.gmail.com>	<20141126002501.GA11752@redhat.com>	<CA+55aFy9c2FY2gDw14VU537QJoLHAbf+q_75VUwU33_HLz+F0w@mail.gmail.com>	<5475596A.9010301@suse.com>	<CA+55aFx1SiFBzmA=k9jHxi3cZE3Ei_+2NHepujgf86KEvkz8eQ@mail.gmail.com>	<54756424.6020409@suse.com>	<CA+55aFzVyTi_pR4y3=Z3y1bWkXbvgoJaykoyn0pUE7eTYgr+ZQ@mail.gmail.com>
	<CA+55aFzOSfdvgrkfiN=zZg4mSoot-tJQiVRh5ENW2-rzmLMy1w@mail.gmail.com>
In-Reply-To: <CA+55aFzOSfdvgrkfiN=zZg4mSoot-tJQiVRh5ENW2-rzmLMy1w@mail.gmail.com>
Content-Length: 8973
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Dave Jones <davej@redhat.com>
Subject: Re: [Xen-devel] frequent lockups in 3.18rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

T24gMTEvMjYvMjAxNCAwNzoyMSBBTSwgTGludXMgVG9ydmFsZHMgd3JvdGU6Cj4gT24gVHVlLCBO
b3YgMjUsIDIwMTQgYXQgOTo1MiBQTSwgTGludXMgVG9ydmFsZHMKPiA8dG9ydmFsZHNAbGludXgt
Zm91bmRhdGlvbi5vcmc+IHdyb3RlOgo+Pgo+PiBBbmQgbGVhdmUgaXQgcnVubmluZyBmb3IgYSB3
aGlsZSwgYW5kIHNlZSBpZiB0aGUgdHJhY2UgaXMgYWx3YXlzIHRoZQo+PiBzYW1lLCBvciBpZiB0
aGVyZSBhcmUgdmFyaWF0aW9ucyBvbiBpdC4uLgo+Cj4gQW11c2luZy4KPgo+IExvb2tpZSBoZXJl
Ogo+Cj4gICAgIGh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9hcmNoaXZlcy9odG1sL3hlbi1j
aGFuZ2Vsb2cvMjAwNS0wOC9tc2cwMDMxMC5odG1sCj4KPiBUaGF0J3MgZnJvbSAyMDA1Lgo+Cj4g
QW55d2F5LCBJIGRvbid0IHNlZSB3aHkgdGhlIGNyMyBpc3N1ZSBtYXR0ZXJzLCAqdW5sZXNzKiB0
aGVyZSBpcyBzb21lCj4gc2l0dWF0aW9uIHdoZXJlIHRoZSBzY2hlZHVsZXIgY2FuIHJ1biB3aXRo
IGludGVycnVwdHMgZW5hYmxlZC4gQW5kIHdoeQo+IHRoaXMgaXMgWGVuLXJlbGF0ZWQsIEkgaGF2
ZSBubyBpZGVhLgo+Cj4gVGhlIFhlbiBwYXRjaGVzIHNlZW0gdG8gaGF2ZSBsb3N0IHRoYXQKPgo+
ICAgLyogT24gWGVuIHRoZSBsaW5lIGJlbG93IGRvZXMgbm90IGFsd2F5cyB3b3JrLiBOZWVkcyBp
bnZlc3RpZ2F0aW5nISAqLwo+Cj4gbGluZSB3aGVuIGJhY2twb3J0aW5nIHRoZSAyLjYuMjkgcGF0
Y2hlcyB0byBYZW4uIEFuZCBjbGVhcmx5IG5vYm9keQo+IGludmVzdGlnYXRlZC4KPgo+IFNvIHBs
ZWFzZSBkbyBnZXQgbWUgYmFjay10cmFjZXMsIGFuZCB3ZSdsbCBpbnZlc3RpZ2F0ZS4gQmV0dGVy
IGxhdGUKPiB0aGFuIG5ldmVyLiBCdXQgaXQgZG9lcyBzb3VuZCBYZW4tc3BlY2lmaWMgLSBhbHRo
b3VnaCBpdCdzIHBvc3NpYmxlCj4gdGhhdCBYZW4ganVzdCB0cmlnZ2VycyBzb21lIHRpbWluZyAo
YW5kIGhhcyBhcHBhcmVudGx5IGJlZW4gYWJsZSB0bwo+IHRyaWdnZXIgaXQgc2luY2UgMjAwNSkg
dGhhdCBEYXZlSiBub3cgdHJpZ2dlcnMgb24gaGlzIG9uZSBtYWNoaW5lLgo+Cj4gU28gRGF2ZUos
IGV2ZW4gdGhvdWdoIHRoaXMgZG9lcyBhcHBlYXIgWGVuLWNlbnRyaWMgKFhlbnRyaWM/KSBhbmQK
PiB5b3UncmUgcnVubmluZyBvbiBiYXJlIGhhcmR3YXJlLCBtYXliZSB5b3UgY291bGQgZG8gdGhl
IHNhbWUgdGhpbmcgaW4KPiB0aGF0IHg4Ni02NCB2bWFsbG9jX2ZhdWx0KCkuIFRoZSB0aW1pbmcg
d2l0aCBKw7xyZ2VuIGlzIGtpbmQgb2YKPiBpbnRyaWd1aW5nIC0gaWYgMy4xOC1yYyBtYWRlIGl0
IGhhcHBlbiBtdWNoIG1vcmUgb2Z0ZW4gZm9yIGhpbSwgbWF5YmUKPiBpdCByZWFsbHkgaXMgdmVy
eSB0aW1pbmctc2Vuc2l0aXZlLCBhbmQgeW91IGFjdHVhbGx5IGFyZSBzZWVpbmcgYQo+IG5vbi1Y
ZW4gdmVyc2lvbiBvZiB0aGUgc2FtZSB0aGluZy4uLgoKVmVyeSBpbnRlcmVzdGluZzogSSd2ZSB1
cGRhdGVkIG15IHRlc3QtbWFjaGluZSB5ZXN0ZXJkYXkgdG8gdGhlIG5ld2VzdApYZW4gdmVyc2lv
biBhZnRlciBJJ3ZlIGdvdCByaWQgb2YgdGhlIGxvY2t1cHMgdG8gYXZvaWQgYW5vdGhlciBwcm9i
bGVtCkkgd2FzIHNlZWluZy4gV2l0aCB0aGlzIHZlcnNpb24gSSBkb24ndCBnZXQgdGhlIGxvY2t1
cHMgYW55IG1vcmUgZXZlbgp3aXRoIHRoZSB1bm1vZGlmaWVkIDMuMTgtcmMga2VybmVsLgoKRGln
Z2luZyBkZWVwZXIgSSBmb3VuZCBzb21ldGhpbmcgbWFraW5nIG1lIGJlbGlldmUgSSd2ZSBzZWVu
IGFub3RoZXIKaXNzdWUgdGhhbiBEYXZlIHdoaWNoIGp1c3QgbG9va2VkIHNpbWlsYXIgb24gdGhl
IHN1cmZhY2UuIDotKAoKTXkgWGVuIHByb2JsZW0gd2FzIHJlbGF0ZWQgdG8gYW4gZXJyb3IgaW4g
ZnJlZWluZyBncmFudCBwYWdlcyAocGFnZXMKbWFwcGVkIGluIGZyb20gYW5vdGhlciBkb21haW4p
LiBPbmUgZGV0YWlsIGluIHRoZSBoYW5kbGluZyBvZiBzdWNoCm1hcHBpbmdzIGlzIGludGVyZXN0
aW5nOiB0aGUgInByaXZhdGUiIG1lbWJlciBvZiB0aGUgcGFnZSBzdHJ1Y3R1cmUKaXMgdXNlZCB0
byBob2xkIHRoZSBtYWNoaW5lIGZyYW1lIG51bWJlciBvZiB0aGUgbWFwcGVkIG1lbW9yeSBwYWdl
LgpBbm90aGVyIHVzYWdlIG9mIHRoaXMgInByaXZhdGUiIG1lbWJlciBpcyBpbiB0aGUgcGdkIGhh
bmRsaW5nIG9mIFhlbgooc2VlIHhlbl9wZ2RfYWxsb2MoKSBhbmQgeGVuX2dldF91c2VyX3BnZCgp
KSB0byBob2xkIHRoZSBwZ2Qgb2YgdGhlCnVzZXIgYWRkcmVzcyBzcGFjZSAoa2VybmVsIGFuZCB1
c2VyIGFyZSBpbiBzZXBhcmF0ZSBhZGRyZXNzIHNwYWNlcyBvbgpYZW4pLiBTbyB3aXRoIGFuIGVy
cm9yIGluIHRoZSBncmFudCBwYWdlIGhhbmRsaW5nIEkgY291bGQgaW1hZ2luZSBhCnBnZCdzIHBy
aXZhdGUgbWVtYmVyIGNvdWxkIGJlIGNsb2JiZXJlZCBsZWFkaW5nIHRvIGVmZmVjdHMgbGlrZSB0
aGUgb25lCkkndmUgb2JzZXJ2ZWQuIEFuZCB0aGlzIGNvdWxkIGhhdmUgYmVlbiB0aGUgcHJvYmxl
bSBpbiAyMDA1LCB0b28uCgpBbmQgd2h5IGlzIG15IHBhdGNoIHdvcmtpbmc/IEkgdGhpbmsgaXQn
cyBqdXN0IGJlY2F1c2UgY3IzIGlzIGFsd2F5cwp3cml0dGVuIHdpdGggYSBwYWdlIGFsaWduZWQg
dmFsdWUgd2hpbGUgdGhlIGNsb2JiZXJlZCAicHJpdmF0ZSIgbWVtYmVyCm9mIHRoZSBYZW4gcGdk
IGlzIG5vdCBwYWdlIGFsaWduZWQgcmVzdWx0aW5nIGluIGEgZGlmZmVyZW50IHBvaW50ZXIuCkkn
bSBzdGlsbCB1c2luZyB0aGUgd3JvbmcgcGFnZSBmb3IgdGhlIHVzZXIncyBwZ2QsIGJ1dCB0aGlz
IHNlZW1zIG5vdAp0byBsZWFkIHRvIGZhdGFsIGVycm9ycyB3aGVuIG5lYXJseSBub3RoaW5nIGlz
IHJ1bm5pbmcgb24gdGhlIG1hY2hpbmUuCkkndmUgc2VlbiBYZW4gbWVzc2FnZXMgb2NjYXNpb25h
bGx5IGluZGljYXRpbmcgdGhlcmUgd2FzIHNvbWV0aGluZwp3cm9uZyB3aXRoIHRoZSBwYWdlIHRh
YmxlIGhhbmRsaW5nIG9mIHRoZSBrZXJuZWwgKHBhZ2VzIHVzZWQgYXMgcGFnZQp0YWJsZXMgbm90
IGtub3duIHRvIFhlbiBhcyBzdWNoKS4KCkkgaG9wZSB0aGlzIGFsbCBtYWtlcyBzZW5zZS4KCkFu
ZCBqdXN0IGZvciB0aGUgcmVjb3Jkczogd2l0aCB0aGUgYWN0dWFsIFhlbiB2ZXJzaW9uICh0d2Vh
a2VkIHRvCnNob3cgdGhlIGdyYW50IHBhZ2UgZXJyb3IgYWdhaW4pIEkgc2VlIGRpZmZlcmVudCBs
b2NrdXBzIHdpdGggdGhlCmZvbGxvd2luZyBiYWNrdHJhY2U6CgpbIDExMjIuMjU2MzA1XSBOTUkg
d2F0Y2hkb2c6IEJVRzogc29mdCBsb2NrdXAgLSBDUFUjOTQgc3R1Y2sgZm9yIDIzcyEgCltzeXN0
ZW1kLXVkZXZkOjExNzldClsgMTEyMi4zMDM0MjddIE1vZHVsZXMgbGlua2VkIGluOiB4ZW5fYmxr
ZnJvbnQgbXNyIGJyaWRnZSBzdHAgbGxjIAppc2NzaV9pYmZ0IGlwbWlfZGV2aW50ZiBubHNfdXRm
OCB4ODZfcGtnX3RlbXBfdGhlcm1hbCBpbnRlbF9wb3dlcmNsYW1wIApubHNfY3A0MzcgY29yZXRl
bXAgY3JjdDEwZGlmX3BjbG11bCB2ZmF0IGNyYzMyX3BjbG11bCBmYXQgY3JjMzJjX2ludGVsIApn
aGFzaF9jbG11bG5pX2ludGVsIHNuZF9wY20gYWVzbmlfaW50ZWwgYWVzX3g4Nl82NCBzbmRfdGlt
ZXIgbHJ3IApiZTJpc2NzaSBiZTJuZXQgZ2YxMjhtdWwgbGliaXNjc2kgc25kIGdsdWVfaGVscGVy
IGpveWRldiB2eGxhbiBzb3VuZGNvcmUgCnNjc2lfdHJhbnNwb3J0X2lzY3NpIGFibGtfaGVscGVy
IGlUQ09fd2R0IGl4Z2JlIGlnYiBtZGlvIGlwNl91ZHBfdHVubmVsIAppVENPX3ZlbmRvcl9zdXBw
b3J0IGVmaXZhcnMgZXZkZXYgaXNjc2lfYm9vdF9zeXNmcyB1ZHBfdHVubmVsIGNyeXB0ZCBkY2Eg
CnBjc3BrciBzYl9lZGFjIGUxMDAwZSBlZGFjX2NvcmUgbHBjX2ljaCBpMmNfaTgwMSBwdHAgbWZk
X2NvcmUgcHBzX2NvcmUgCnNocGNocCB0cG1faW5maW5lb24gaXBtaV9zaSB0cG1fdGlzIGlwbWlf
bXNnaGFuZGxlciB0cG0gYnV0dG9uIHhlbmZzIAp4ZW5fcHJpdmNtZCB4ZW5fYWNwaV9wcm9jZXNz
b3IgcHJvY2Vzc29yIHRoZXJtYWxfc3lzIHhlbl9wY2liYWNrIAp4ZW5fbmV0YmFjayB4ZW5fYmxr
YmFjayB4ZW5fZ250YWxsb2MgeGVuX2dudGRldiB4ZW5fZXZ0Y2huIGRtX21vZCAKZWZpdmFyZnMg
Y3JjMzJjX2dlbmVyaWMgYnRyZnMgeG9yIHJhaWQ2X3BxIGhpZF9nZW5lcmljClsgMTEyMi4zMDM0
NTBdICB1c2JoaWQgaGlkIHNkX21vZCBtZ2FnMjAwIGVoY2lfcGNpIGkyY19hbGdvX2JpdCBlaGNp
X2hjZCAKZHJtX2ttc19oZWxwZXIgdHRtIHVzYmNvcmUgZHJtIG1lZ2FyYWlkX3NhcyB1c2JfY29t
bW9uIHNnIHNjc2lfbW9kIGF1dG9mczQKWyAxMTIyLjMwMzQ1Nl0gQ1BVOiA5NCBQSUQ6IDExNzkg
Q29tbTogc3lzdGVtZC11ZGV2ZCBUYWludGVkOiBHIAogICAgIEwgMy4xOC4wLXJjNSsgIzMwNApb
IDExMjIuMzAzNDU4XSBIYXJkd2FyZSBuYW1lOiBGVUpJVFNVIFBSSU1FUVVFU1QgMjgwMEUvU0Is
IEJJT1MgClBSSU1FUVVFU1QgMjAwMCBTZXJpZXMgQklPUyBWZXJzaW9uIDAxLjU5IDA3LzI0LzIw
MTQKWyAxMTIyLjMwMzQ1OV0gdGFzazogZmZmZjg4MWYxN2I1NmNlMCB0aTogZmZmZjg4MWYwZmZm
MDAwMCB0YXNrLnRpOiAKZmZmZjg4MWYwZmZmMDAwMApbIDExMjIuMzAzNDYwXSBSSVA6IGUwMzA6
WzxmZmZmZmZmZjgxNGZjZjVlPl0gIFs8ZmZmZmZmZmY4MTRmY2Y1ZT5dIApfcmF3X3NwaW5fbG9j
aysweDFlLzB4MzAKWyAxMTIyLjMwMzQ2Ml0gUlNQOiBlMDJiOmZmZmY4ODFmMGZmZjNjZTggIEVG
TEFHUzogMDAwMDAyODIKWyAxMTIyLjMwMzQ2M10gUkFYOiAwMDAwMDAwMDAwMDBiYTQzIFJCWDog
MDAwMDNmZmZmZmZmZjAwMCBSQ1g6IAowMDAwMDAwMDAwMDAwMTkwClsgMTEyMi4zMDM0NjRdIFJE
WDogMDAwMDAwMDAwMDAwMDE5MCBSU0k6IDAwMDAwMDE5MGJhNDMwNjcgUkRJOiAKZmZmZmVhMDAw
MTU3YzM1MApbIDExMjIuMzAzNDY1XSBSQlA6IGZmZmY4ODAwMDAwMDBjNzAgUjA4OiAwMDAwMDAw
MDAwMDAwMDAwIFIwOTogCjAwMDAwMDAwMDAwMDAwMDAKWyAxMTIyLjMwMzQ2Nl0gUjEwOiAwMDAw
MDAwMDAwMDFiNjg4IFIxMTogZmZmZjg4MWZkZjI0YWQ4MCBSMTI6IApmZmZmZWEwMDAwMDAwMDAw
ClsgMTEyMi4zMDM0NjZdIFIxMzogZmZmZjg4MDA2MjM3Y2M3MCBSMTQ6IDAwMDAwMDAwMDAwMDAw
MDAgUjE1OiAKMDAwMDdmNzBmNDM4ZTAwMApbIDExMjIuMzAzNDcwXSBGUzogIDAwMDA3ZjcwZjVj
NDk4ODAoMDAwMCkgR1M6ZmZmZjg4MWY0YzVjMDAwMCgwMDAwKSAKa25sR1M6ZmZmZjg4MWY0YzVj
MDAwMApbIDExMjIuMzAzNDcxXSBDUzogIGUwMzMgRFM6IDAwMDAgRVM6IDAwMDAgQ1IwOiAwMDAw
MDAwMDgwMDUwMDMzClsgMTEyMi4zMDM0NzJdIENSMjogMDAwMDdmNzBmNWM2ODAwMCBDUjM6IDAw
MDAwMDFmMTExYjcwMDAgQ1I0OiAKMDAwMDAwMDAwMDA0MjY2MApbIDExMjIuMzAzNDczXSBTdGFj
azoKWyAxMTIyLjMwMzQ3NF0gIGZmZmZmZmZmODExNTU4NTAgZmZmZjg4MWZkZjI0YWQ4MCAwMDAw
N2Y3MGY0MzhmMDAwIApmZmZmODgxZjEzOGFlNWQ4ClsgMTEyMi4zMDM0NzZdICBmZmZmODgxZjA4
ZWFkNDAwIGZmZmY4ODFmMGZmZjNmZDggMDAwMDAwMDAwMDAwMDAwMCAKZmZmZjg4MWVmZjBjYmQw
OApbIDExMjIuMzAzNDc3XSAgZmZmZjg4MWYxOGI1N2QwOCBmZmZmZWEwMDAxNTdjMzIwIGZmZmZl
YTAwNmNjYzVlYzggCmZmZmY4ODFmMGZjMDA4MDAKWyAxMTIyLjMwMzQ3OV0gQ2FsbCBUcmFjZToK
WyAxMTIyLjMwMzQ4MV0gIFs8ZmZmZmZmZmY4MTE1NTg1MD5dID8gY29weV9wYWdlX3JhbmdlKzB4
NDYwLzB4YTEwClsgMTEyMi4zMDM0ODRdICBbPGZmZmZmZmZmODEwNWQ3Mjc+XSA/IGNvcHlfcHJv
Y2Vzcy5wYXJ0LjI3KzB4MTNlNy8weDFiMTAKWyAxMTIyLjMwMzQ4Nl0gIFs8ZmZmZmZmZmY4MTQz
NWY0MT5dID8gbmV0bGlua19pbnNlcnQrMHg5MS8weGIwClsgMTEyMi4zMDM0ODhdICBbPGZmZmZm
ZmZmODEzZjg1Yzk+XSA/IHJlbGVhc2Vfc29jaysweDE5LzB4MTYwClsgMTEyMi4zMDM0OTBdICBb
PGZmZmZmZmZmODEwNWRmZjg+XSA/IGRvX2ZvcmsrMHhjOC8weDMyMApbIDExMjIuMzAzNDkyXSAg
WzxmZmZmZmZmZjgxNGZkNzc5Pl0gPyBzdHViX2Nsb25lKzB4NjkvMHg5MApbIDExMjIuMzAzNDkz
XSAgWzxmZmZmZmZmZjgxNGZkNDJkPl0gPyBzeXN0ZW1fY2FsbF9mYXN0cGF0aCsweDE2LzB4MWIK
WyAxMTIyLjMwMzQ5NF0gQ29kZTogOTAgMGYgYjcgMTcgNjYgMzkgZDAgNzUgZjYgZWIgZTggNjYg
OTAgYjggMDAgMDAgMDEgCjAwIGYwIDBmIGMxIDA3IDg5IGMyIGMxIGVhIDEwIDY2IDM5IGMyIDg5
IGQxIDc1IDAxIGMzIDBmIGI3IDA3IDY2IDM5IGQwIAo3NCBmNyA8ZjM+IDkwIDBmIGI3IDA3IDY2
IDM5IGM4IDc1IGY2IGMzIDBmIDFmIDgwIDAwIDAwIDAwIDAwIDY1IDgxIDA0CgpCdXQgaWYgbXkg
YXNzdW1wdGlvbnMgYWJvdmUgYXJlIGNvcnJlY3QgdGhpcyBpcyBtZWFuaW5nbGVzcywgYXMgdXNp
bmcKYW4gYXJiaXRyYXJ5IG1lbW9yeSBwYWdlIGFzIHBnZCBtaWdodCByZXN1bHQgaW4gYW55dGhp
bmcuLi4KCgpKdWVyZ2VuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Nov 26 09:45:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 09:45:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtZAA-0002OL-AR; Wed, 26 Nov 2014 09:45:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtZA8-0002OC-4P
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 09:45:28 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	88/0A-23865-731A5745; Wed, 26 Nov 2014 09:45:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416995125!13886610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24389 invoked from network); 26 Nov 2014 09:45:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 09:45:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,461,1413244800"; d="scan'208";a="196705424"
Message-ID: <1416995122.11944.29.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Wed, 26 Nov 2014 09:45:22 +0000
In-Reply-To: <5474E537.7010707@oracle.com>
References: <5474E537.7010707@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	programme110@gmail.com, David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>, davem@davemloft.net
Subject: Re: [Xen-devel] Regression in netfilter code under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 15:23 -0500, Boris Ostrovsky wrote:
> We have a regression due to (5195c14c8: netfilter: conntrack: fix race 
> in __nf_conntrack_confirm against get_next_corpse). I have not been able 
> to reproduce this on baremetal but dom0 crashes reliably after a few 
> seconds of idle time.

Are guests running when this happens? (IOW is netback possibly
involved).

>  This doesn't appear to be dependent on Xen version 
> --- I saw it on at least a 4.2 and unstable).
> 
> I don't know much about networking (and will be out for most of the rest 
> of the week) so I wonder whether anyone has any ideas. The stack is below.
> 
> 
> Thanks.
> -boris
> 
> # 
> [ 
> 54.901368] general protection fault: 0000 [#1] SMP
> [   54.919324] Modules linked in: dm_multipath dm_mod xen_evtchn 
> iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport 
> libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod i915 fbcon 
> tileblit font bitblit softcursor tpm_tis ahci libahci libata 
> drm_kms_helper video scsi_mod e1000e wmi xen_blkfront xen_netfront 
> fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd
> [   54.996767] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
> 3.18.0-rc5upstream-00179-g8a84e01 #1
> [   55.016730] Hardware name: LENOVO ThinkServer TS130/        , BIOS 
> 9HKT47AUS 01/10/2012
> [   55.036873] task: ffff880037e48a10 ti: ffff880037e54000 task.ti: 
> ffff880037e54000
> [   55.057338] RIP: e030:[<ffffffff815ea29e>] [<ffffffff815ea29e>] 
> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
> [   55.[   55.099069] RAX: dead000000200200 RBX: ffffe8ffffc89108 RCX: 
> ffffffff81cc5820
> [   55.119918] RDX: 0000000080000001 RSI: 0000000000000011 RDI: 
> ffffe8ffffc89108
> [   55.140768] RBP: ffff88003e283908 R08: 00000000c5f889ff R09: 
> 00000000a1a10f28
> [   55.161785] R10: ffff880037e5f1b8 R11: 0000000000000001 R12: 
> ffff880037e5f148
> [   55.183005] R13: ffffffff815e6a6b R14: ffff88002bed8400 R15: 
> ffff88002bb30000
> [   55.204214] FS:  00007f668f694700(0000) GS[   55.225733] CS: e033 
> DS: 002b ES: 002b CR0: 0000000080050033
> [   55.247220] CR2: 00007f66c0a598eb CR3: 000000002bc39000 CR4: 
> 0000000000042660
> [   55.268863] Stack:
> [   55.290200]  ffff880037e5f148 ffffffff81c98080 ffff88003e283928 
> ffffffff815eb59d
> [   55.312068]  ffff88002bed8400 ffff88002bed8400 ffff88003e283938 
> ffffffff815e689a
> [   55.333849]  ffff88003e283958 ffffffff815a37a5 ffff88003e283968 
> ffff88002bed8400
> [   55.355449] Call Trace:
> [   55.376552]  <IRQ>
> [   55.376728]  [<ffffffff815eb59d>] destroy_conntrack+0x5d/0xc0
> [   55.418187]  [<ffffffff815e689a>] nf_conntrack_destroy+0x1a/0x40
> [   55.439349]  [<ffffffff815a37a5>] skb_release_head_state+0x85/0xd0
> [   55.460468]  [<ffffffff815a5d61>] skb_release_all+0x11/0x30
> [   55.481440]  [<ffffffff815a5dd1>] __kfree_skb+0x11/0xc0
> [   55.502239]  [<ffffffff815a5f78>] kfree_skb+0x38/0xa0
> [   55.522661]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
> [   55.542811]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
> [   55.562543]  [<ffffffff815e6a6b>] nf_hook_slow+0x10b/0x120
> [   55.582100]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
> [   55.601470]  [<ffffffff8170a02b>] ? _raw_spin_unlock_irqrestore+0[   
> 55.620900] [<ffffffff81604713>] ip_local_deliver+0x73/0x80
> [   55.640154]  [<ffffffff81603dc9>] ip_rcv_finish+0x109/0x310
> [   55.659244]  [<ffffffff8160439c>] ip_rcv+0x28c/0x3a0
> [   55.678287]  [<ffffffff815b69ae>] 
> __netif_receive_skb_core+0x58e/0x[   55.697287] [<ffffffff815b6b4d>] 
> __netif_receive_skb+0x1d/0x70
> [   55.715820]  [<ffffffff815b6d9e>] netif_receive_skb_internal+0x1e/0xb0
> [   55.734442]  [<ffffffff815b6e47>] netif_receive_skb+0x17/0x70
> [   55.752898]  [<ffffffff816c17e2>] br_handle_frame_finish+0x192/0x360
> [   55.771709]  [<ffffffff816c156d>] br_handle_frame+0
> [   55.790274]  [<ffffffff816c13f0>] ? br_handle_local_finish+0x40/0x40
> [   55.808760]  [<ffffffff815b65f7>] __netif_receive_skb_core+0x1d7/0x710
> [   55.827302]  [<ffffffff815b6b4d>] __netif_receive_skb+0x1d/0x70
> [   55.845594]  [<ffffffff815b6d9e>] netif_receive_skb_internal+0x1e/0xb0
> [   55.863836]  [<ffffffff815b7a38>] napi_gro_receive+0x118/0x1a0
> [   55.881549]  [<ffffffff814c430f>] tg3_poll_work+0xe1f/0x1[   
> 55.898629]  [<ffffffff814d75c9>] tg3_poll+0x69/0x3c0
> [   55.915010]  [<ffffffff815b7523>] net_rx_action+0x103/0x290
> [   55.930840]  [<ffffffff810a7713>] __do_softirq+0xf3/0x2e0
> [   55.946310]  [<ffffffff810a7a2d>] irq_exit+0xcd/0xe0
> [   55.961399]  [<ffffffff8140d4c7>] xen_evtchn_do_upcall+0x37/0x50
> 766]  [<ffffffff8170c1fe>] xen_do_hypervisor_callback+0x1e/0x30
> [   55.990802]  <EOI>
> [   55.990977]  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [   56.018897]  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [   56.032815]  [<ffffffff810454b0>] ? xen_safe_halt+0x10/0x20
> [   56.046583]  [<ffffffff81059e3a>] ? default_idle+0x1a/0xd0
> [   56.060307]  [<ffffffff8105950a>] ? arch_cpu_idle+0xa/0x10
> [   56.073920]  [<ffffffff810de483>] ? cpu_startup_entry+0x2d3/0[   
> 56.100421]  [<ffffffff8104c355>] ? cpu_bringup_and_idle+0x25/0x40
> [   56.113427] Code: 98 08 08 00 00 0f b7 47 08 48 03 1c c5 a0 42 cc 81 
> 48 89 df e8 94 fc 11 00 49 8b 44 24 18 48 85 c0 74 2d 49[   
> 56.141507] RIP  [<ffffffff815ea29e>] 
> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
> [   56.155425]  RSP <ffff88003e2838f8>
> [   56.169234] ---[ end trace 4c64578e4c629cc4 ]---
> [   56.182913] Kernel panic - not syncing: Fatal exception in interrupt
> [   56.197026] Kernel Offset: 0x0 from 0xffffffff81000k  text console
> (XEN) [2014-11-23 06:05:48] Domain 0 crashed: rebooting machine in 5 
> seconds.
> (XEN) [2014-11-23 06:05:53] Resetting with ACPI MEMORY or I/O RESET_REG.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 09:45:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 09:45:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtZAA-0002OL-AR; Wed, 26 Nov 2014 09:45:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtZA8-0002OC-4P
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 09:45:28 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	88/0A-23865-731A5745; Wed, 26 Nov 2014 09:45:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1416995125!13886610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24389 invoked from network); 26 Nov 2014 09:45:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 09:45:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,461,1413244800"; d="scan'208";a="196705424"
Message-ID: <1416995122.11944.29.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Wed, 26 Nov 2014 09:45:22 +0000
In-Reply-To: <5474E537.7010707@oracle.com>
References: <5474E537.7010707@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	programme110@gmail.com, David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>, davem@davemloft.net
Subject: Re: [Xen-devel] Regression in netfilter code under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 15:23 -0500, Boris Ostrovsky wrote:
> We have a regression due to (5195c14c8: netfilter: conntrack: fix race 
> in __nf_conntrack_confirm against get_next_corpse). I have not been able 
> to reproduce this on baremetal but dom0 crashes reliably after a few 
> seconds of idle time.

Are guests running when this happens? (IOW is netback possibly
involved).

>  This doesn't appear to be dependent on Xen version 
> --- I saw it on at least a 4.2 and unstable).
> 
> I don't know much about networking (and will be out for most of the rest 
> of the week) so I wonder whether anyone has any ideas. The stack is below.
> 
> 
> Thanks.
> -boris
> 
> # 
> [ 
> 54.901368] general protection fault: 0000 [#1] SMP
> [   54.919324] Modules linked in: dm_multipath dm_mod xen_evtchn 
> iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport 
> libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod i915 fbcon 
> tileblit font bitblit softcursor tpm_tis ahci libahci libata 
> drm_kms_helper video scsi_mod e1000e wmi xen_blkfront xen_netfront 
> fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd
> [   54.996767] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
> 3.18.0-rc5upstream-00179-g8a84e01 #1
> [   55.016730] Hardware name: LENOVO ThinkServer TS130/        , BIOS 
> 9HKT47AUS 01/10/2012
> [   55.036873] task: ffff880037e48a10 ti: ffff880037e54000 task.ti: 
> ffff880037e54000
> [   55.057338] RIP: e030:[<ffffffff815ea29e>] [<ffffffff815ea29e>] 
> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
> [   55.[   55.099069] RAX: dead000000200200 RBX: ffffe8ffffc89108 RCX: 
> ffffffff81cc5820
> [   55.119918] RDX: 0000000080000001 RSI: 0000000000000011 RDI: 
> ffffe8ffffc89108
> [   55.140768] RBP: ffff88003e283908 R08: 00000000c5f889ff R09: 
> 00000000a1a10f28
> [   55.161785] R10: ffff880037e5f1b8 R11: 0000000000000001 R12: 
> ffff880037e5f148
> [   55.183005] R13: ffffffff815e6a6b R14: ffff88002bed8400 R15: 
> ffff88002bb30000
> [   55.204214] FS:  00007f668f694700(0000) GS[   55.225733] CS: e033 
> DS: 002b ES: 002b CR0: 0000000080050033
> [   55.247220] CR2: 00007f66c0a598eb CR3: 000000002bc39000 CR4: 
> 0000000000042660
> [   55.268863] Stack:
> [   55.290200]  ffff880037e5f148 ffffffff81c98080 ffff88003e283928 
> ffffffff815eb59d
> [   55.312068]  ffff88002bed8400 ffff88002bed8400 ffff88003e283938 
> ffffffff815e689a
> [   55.333849]  ffff88003e283958 ffffffff815a37a5 ffff88003e283968 
> ffff88002bed8400
> [   55.355449] Call Trace:
> [   55.376552]  <IRQ>
> [   55.376728]  [<ffffffff815eb59d>] destroy_conntrack+0x5d/0xc0
> [   55.418187]  [<ffffffff815e689a>] nf_conntrack_destroy+0x1a/0x40
> [   55.439349]  [<ffffffff815a37a5>] skb_release_head_state+0x85/0xd0
> [   55.460468]  [<ffffffff815a5d61>] skb_release_all+0x11/0x30
> [   55.481440]  [<ffffffff815a5dd1>] __kfree_skb+0x11/0xc0
> [   55.502239]  [<ffffffff815a5f78>] kfree_skb+0x38/0xa0
> [   55.522661]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
> [   55.542811]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
> [   55.562543]  [<ffffffff815e6a6b>] nf_hook_slow+0x10b/0x120
> [   55.582100]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
> [   55.601470]  [<ffffffff8170a02b>] ? _raw_spin_unlock_irqrestore+0[   
> 55.620900] [<ffffffff81604713>] ip_local_deliver+0x73/0x80
> [   55.640154]  [<ffffffff81603dc9>] ip_rcv_finish+0x109/0x310
> [   55.659244]  [<ffffffff8160439c>] ip_rcv+0x28c/0x3a0
> [   55.678287]  [<ffffffff815b69ae>] 
> __netif_receive_skb_core+0x58e/0x[   55.697287] [<ffffffff815b6b4d>] 
> __netif_receive_skb+0x1d/0x70
> [   55.715820]  [<ffffffff815b6d9e>] netif_receive_skb_internal+0x1e/0xb0
> [   55.734442]  [<ffffffff815b6e47>] netif_receive_skb+0x17/0x70
> [   55.752898]  [<ffffffff816c17e2>] br_handle_frame_finish+0x192/0x360
> [   55.771709]  [<ffffffff816c156d>] br_handle_frame+0
> [   55.790274]  [<ffffffff816c13f0>] ? br_handle_local_finish+0x40/0x40
> [   55.808760]  [<ffffffff815b65f7>] __netif_receive_skb_core+0x1d7/0x710
> [   55.827302]  [<ffffffff815b6b4d>] __netif_receive_skb+0x1d/0x70
> [   55.845594]  [<ffffffff815b6d9e>] netif_receive_skb_internal+0x1e/0xb0
> [   55.863836]  [<ffffffff815b7a38>] napi_gro_receive+0x118/0x1a0
> [   55.881549]  [<ffffffff814c430f>] tg3_poll_work+0xe1f/0x1[   
> 55.898629]  [<ffffffff814d75c9>] tg3_poll+0x69/0x3c0
> [   55.915010]  [<ffffffff815b7523>] net_rx_action+0x103/0x290
> [   55.930840]  [<ffffffff810a7713>] __do_softirq+0xf3/0x2e0
> [   55.946310]  [<ffffffff810a7a2d>] irq_exit+0xcd/0xe0
> [   55.961399]  [<ffffffff8140d4c7>] xen_evtchn_do_upcall+0x37/0x50
> 766]  [<ffffffff8170c1fe>] xen_do_hypervisor_callback+0x1e/0x30
> [   55.990802]  <EOI>
> [   55.990977]  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [   56.018897]  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [   56.032815]  [<ffffffff810454b0>] ? xen_safe_halt+0x10/0x20
> [   56.046583]  [<ffffffff81059e3a>] ? default_idle+0x1a/0xd0
> [   56.060307]  [<ffffffff8105950a>] ? arch_cpu_idle+0xa/0x10
> [   56.073920]  [<ffffffff810de483>] ? cpu_startup_entry+0x2d3/0[   
> 56.100421]  [<ffffffff8104c355>] ? cpu_bringup_and_idle+0x25/0x40
> [   56.113427] Code: 98 08 08 00 00 0f b7 47 08 48 03 1c c5 a0 42 cc 81 
> 48 89 df e8 94 fc 11 00 49 8b 44 24 18 48 85 c0 74 2d 49[   
> 56.141507] RIP  [<ffffffff815ea29e>] 
> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
> [   56.155425]  RSP <ffff88003e2838f8>
> [   56.169234] ---[ end trace 4c64578e4c629cc4 ]---
> [   56.182913] Kernel panic - not syncing: Fatal exception in interrupt
> [   56.197026] Kernel Offset: 0x0 from 0xffffffff81000k  text console
> (XEN) [2014-11-23 06:05:48] Domain 0 crashed: rebooting machine in 5 
> seconds.
> (XEN) [2014-11-23 06:05:53] Resetting with ACPI MEMORY or I/O RESET_REG.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 10:10:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 10:10:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtZY4-0002oo-Gt; Wed, 26 Nov 2014 10:10:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtZY3-0002oj-0O
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 10:10:11 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	64/53-29352-207A5745; Wed, 26 Nov 2014 10:10:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416996607!5793861!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27621 invoked from network); 26 Nov 2014 10:10:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 10:10:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,461,1413244800"; d="scan'208";a="196710551"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 05:10:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtZXx-0000fM-D0;
	Wed, 26 Nov 2014 10:10:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtZXx-0001U9-2n;
	Wed, 26 Nov 2014 10:10:05 +0000
Date: Wed, 26 Nov 2014 10:10:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31855-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31855: 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 31855 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31855/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31801

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                ca6028185d19d3f2bd331c15175c3ef5afc30c77
baseline version:
 qemuu                0e88f478508b566152c6681f4889ed9830a2c0a5

------------------------------------------------------------
People who touched revisions under test:
  Gonglei <arei.gonglei@huawei.com>
  Igor Mammedov <imammedo@redhat.com>
  Kevin Wolf <kwolf@redhat.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Michael S. Tsirkin <mst@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Richard Bilson <rbilson@qnx.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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-mainline
+ revision=ca6028185d19d3f2bd331c15175c3ef5afc30c77
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-mainline ca6028185d19d3f2bd331c15175c3ef5afc30c77
+ branch=qemu-mainline
+ revision=ca6028185d19d3f2bd331c15175c3ef5afc30c77
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ qemuubranch=qemu-mainline
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' xqemu-mainline = x ']'
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://git.qemu.org/qemu.git
++ : daily-cron.qemu-mainline
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-mainline
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-mainline
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-mainline
+ git push osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git ca6028185d19d3f2bd331c15175c3ef5afc30c77:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   0e88f47..ca60281  ca6028185d19d3f2bd331c15175c3ef5afc30c77 -> mainline/xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 10:10:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 10:10:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtZY4-0002oo-Gt; Wed, 26 Nov 2014 10:10:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtZY3-0002oj-0O
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 10:10:11 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	64/53-29352-207A5745; Wed, 26 Nov 2014 10:10:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1416996607!5793861!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27621 invoked from network); 26 Nov 2014 10:10:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 10:10:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,461,1413244800"; d="scan'208";a="196710551"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 05:10:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtZXx-0000fM-D0;
	Wed, 26 Nov 2014 10:10:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtZXx-0001U9-2n;
	Wed, 26 Nov 2014 10:10:05 +0000
Date: Wed, 26 Nov 2014 10:10:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31855-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31855: 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 31855 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31855/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31801

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                ca6028185d19d3f2bd331c15175c3ef5afc30c77
baseline version:
 qemuu                0e88f478508b566152c6681f4889ed9830a2c0a5

------------------------------------------------------------
People who touched revisions under test:
  Gonglei <arei.gonglei@huawei.com>
  Igor Mammedov <imammedo@redhat.com>
  Kevin Wolf <kwolf@redhat.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Michael S. Tsirkin <mst@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Richard Bilson <rbilson@qnx.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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-mainline
+ revision=ca6028185d19d3f2bd331c15175c3ef5afc30c77
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-mainline ca6028185d19d3f2bd331c15175c3ef5afc30c77
+ branch=qemu-mainline
+ revision=ca6028185d19d3f2bd331c15175c3ef5afc30c77
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ qemuubranch=qemu-mainline
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' xqemu-mainline = x ']'
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : daily-cron.qemu-mainline
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://git.qemu.org/qemu.git
++ : daily-cron.qemu-mainline
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.qemu-mainline
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree qemu-mainline
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-mainline
+ git push osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git ca6028185d19d3f2bd331c15175c3ef5afc30c77:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   0e88f47..ca60281  ca6028185d19d3f2bd331c15175c3ef5afc30c77 -> mainline/xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 10:53:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 10:53:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtaDz-0003Rq-C8; Wed, 26 Nov 2014 10:53:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtaDx-0003Rl-LY
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 10:53:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6A/CC-09842-821B5745; Wed, 26 Nov 2014 10:53:28 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416999207!15451161!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27551 invoked from network); 26 Nov 2014 10:53:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 10:53:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196967824"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 05:53:26 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtaDt-0004cR-Nq;
	Wed, 26 Nov 2014 10:53:25 +0000
Date: Wed, 26 Nov 2014 10:53:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jason Wang <jasowang@redhat.com>
In-Reply-To: <547563E6.2090505@redhat.com>
Message-ID: <alpine.DEB.2.02.1411261038020.14135@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
	<54741ED7.2060500@redhat.com>
	<alpine.DEB.2.02.1411251249380.2675@kaball.uk.xensource.com>
	<547563E6.2090505@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Nov 2014, Jason Wang wrote:
> On 11/25/2014 09:53 PM, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Jason Wang wrote:
> >> On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
> >>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> >>>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> >>>>> CC'ing Paolo.
> >>>>>
> >>>>>
> >>>>> Wen,
> >>>>> thanks for the logs.
> >>>>>
> >>>>> I investigated a little bit and it seems to me that the bug occurs when
> >>>>> QEMU tries to unmap only a portion of a memory region previously mapped.
> >>>>> That doesn't work with xen-mapcache.
> >>>>>
> >>>>> See these logs for example:
> >>>>>
> >>>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> >>>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> >>>> Sorry the logs don't quite match, it was supposed to be:
> >>>>
> >>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
> >>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> >>> It looks like the problem is caused by iov_discard_front, called by
> >>> virtio_net_handle_ctrl. By changing iov_base after the sg has already
> >>> been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> >>> because the corresponding cpu_physical_memory_unmap will only unmap a
> >>> portion of the original sg.  On Xen the problem is worse because
> >>> xen-mapcache aborts.
> >>>
> >>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> >>> index 2ac6ce5..b2b5c2d 100644
> >>> --- a/hw/net/virtio-net.c
> >>> +++ b/hw/net/virtio-net.c
> >>> @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >>>      struct iovec *iov;
> >>>      unsigned int iov_cnt;
> >>>  
> >>> -    while (virtqueue_pop(vq, &elem)) {
> >>> +    while (virtqueue_pop_nomap(vq, &elem)) {
> >>>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
> >>>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
> >>>              error_report("virtio-net ctrl missing headers");
> >>> @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >>>  
> >>>          iov = elem.out_sg;
> >>>          iov_cnt = elem.out_num;
> >>> -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> >>>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> >>> +
> >>> +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> >>> +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> >>> +
> >>> +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> >> Does this really work?
> > It seems to work here, as in it doesn't crash QEMU and I am able to boot
> > a guest with network. I didn't try any MAC related commands.
> >
> 
> It was because the guest (not a recent kernel?) never issue commands
> through control vq.
> 
> We'd better hide the implementation details such as virtqueue_map_sg()
> in virtio core instead of letting device call it directly.
> >> The code in fact skips the location that contains
> >> virtio_net_ctrl_hdr. And virtio_net_handle_mac() still calls
> >> iov_discard_front().
> >>
> >> How about copy iov to a temp variable and use it in this function?
> > That would only work if I moved the cpu_physical_memory_unmap call
> > outside of virtqueue_fill, so that we can pass different iov to them.
> > We need to unmap the same iov that was previously mapped by
> > virtqueue_pop.
> >
> 
> I mean something like following or just passing the offset of iov to
> virtio_net_handle_*().

Sorry, you are right, your patch works too. I tried something like this
yesterday but I was confused because even if a crash doesn't happen
anymore, virtio-net still doesn't work on Xen (it boots but the network
doesn't work properly within the guest).
But that seems to be a separate issue and it affects my series too.

A possible problem with this approach is that virtqueue_push is now
called passing the original iov, not the shortened one.

Are you sure that is OK?
If so we can drop my series and use this instead.


> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 9b88775..fdb4edd 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -798,7 +798,7 @@ static void virtio_net_handle_ctrl(VirtIODevice
> *vdev, VirtQueue *vq)
>      virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
>      VirtQueueElement elem;
>      size_t s;
> -    struct iovec *iov;
> +    struct iovec *iov, *iov2;
>      unsigned int iov_cnt;
>  
>      while (virtqueue_pop(vq, &elem)) {
> @@ -808,8 +808,12 @@ static void virtio_net_handle_ctrl(VirtIODevice
> *vdev, VirtQueue *vq)
>              exit(1);
>          }
>  
> -        iov = elem.out_sg;
>          iov_cnt = elem.out_num;
> +        s = sizeof(struct iovec) * elem.out_num;
> +        iov = g_malloc(s);
> +        memcpy(iov, elem.out_sg, s);
> +        iov2 = iov;
> +
>          s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
>          if (s != sizeof(ctrl)) {
> @@ -833,6 +837,7 @@ static void virtio_net_handle_ctrl(VirtIODevice
> *vdev, VirtQueue *vq)
>  
>          virtqueue_push(vq, &elem, sizeof(status));
>          virtio_notify(vdev, vq);
> +        g_free(iov2);
>      }
>  }
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 10:53:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 10:53:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtaDz-0003Rq-C8; Wed, 26 Nov 2014 10:53:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XtaDx-0003Rl-LY
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 10:53:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6A/CC-09842-821B5745; Wed, 26 Nov 2014 10:53:28 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1416999207!15451161!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27551 invoked from network); 26 Nov 2014 10:53:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 10:53:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196967824"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 05:53:26 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XtaDt-0004cR-Nq;
	Wed, 26 Nov 2014 10:53:25 +0000
Date: Wed, 26 Nov 2014 10:53:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jason Wang <jasowang@redhat.com>
In-Reply-To: <547563E6.2090505@redhat.com>
Message-ID: <alpine.DEB.2.02.1411261038020.14135@kaball.uk.xensource.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
	<54741ED7.2060500@redhat.com>
	<alpine.DEB.2.02.1411251249380.2675@kaball.uk.xensource.com>
	<547563E6.2090505@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Nov 2014, Jason Wang wrote:
> On 11/25/2014 09:53 PM, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Jason Wang wrote:
> >> On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
> >>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> >>>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> >>>>> CC'ing Paolo.
> >>>>>
> >>>>>
> >>>>> Wen,
> >>>>> thanks for the logs.
> >>>>>
> >>>>> I investigated a little bit and it seems to me that the bug occurs when
> >>>>> QEMU tries to unmap only a portion of a memory region previously mapped.
> >>>>> That doesn't work with xen-mapcache.
> >>>>>
> >>>>> See these logs for example:
> >>>>>
> >>>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
> >>>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> >>>> Sorry the logs don't quite match, it was supposed to be:
> >>>>
> >>>> DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
> >>>> DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
> >>> It looks like the problem is caused by iov_discard_front, called by
> >>> virtio_net_handle_ctrl. By changing iov_base after the sg has already
> >>> been mapped (cpu_physical_memory_map), it causes a leak in the mapping
> >>> because the corresponding cpu_physical_memory_unmap will only unmap a
> >>> portion of the original sg.  On Xen the problem is worse because
> >>> xen-mapcache aborts.
> >>>
> >>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> >>> index 2ac6ce5..b2b5c2d 100644
> >>> --- a/hw/net/virtio-net.c
> >>> +++ b/hw/net/virtio-net.c
> >>> @@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >>>      struct iovec *iov;
> >>>      unsigned int iov_cnt;
> >>>  
> >>> -    while (virtqueue_pop(vq, &elem)) {
> >>> +    while (virtqueue_pop_nomap(vq, &elem)) {
> >>>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
> >>>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
> >>>              error_report("virtio-net ctrl missing headers");
> >>> @@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >>>  
> >>>          iov = elem.out_sg;
> >>>          iov_cnt = elem.out_num;
> >>> -        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> >>>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
> >>> +
> >>> +        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
> >>> +        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
> >>> +
> >>> +        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> >> Does this really work?
> > It seems to work here, as in it doesn't crash QEMU and I am able to boot
> > a guest with network. I didn't try any MAC related commands.
> >
> 
> It was because the guest (not a recent kernel?) never issue commands
> through control vq.
> 
> We'd better hide the implementation details such as virtqueue_map_sg()
> in virtio core instead of letting device call it directly.
> >> The code in fact skips the location that contains
> >> virtio_net_ctrl_hdr. And virtio_net_handle_mac() still calls
> >> iov_discard_front().
> >>
> >> How about copy iov to a temp variable and use it in this function?
> > That would only work if I moved the cpu_physical_memory_unmap call
> > outside of virtqueue_fill, so that we can pass different iov to them.
> > We need to unmap the same iov that was previously mapped by
> > virtqueue_pop.
> >
> 
> I mean something like following or just passing the offset of iov to
> virtio_net_handle_*().

Sorry, you are right, your patch works too. I tried something like this
yesterday but I was confused because even if a crash doesn't happen
anymore, virtio-net still doesn't work on Xen (it boots but the network
doesn't work properly within the guest).
But that seems to be a separate issue and it affects my series too.

A possible problem with this approach is that virtqueue_push is now
called passing the original iov, not the shortened one.

Are you sure that is OK?
If so we can drop my series and use this instead.


> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 9b88775..fdb4edd 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -798,7 +798,7 @@ static void virtio_net_handle_ctrl(VirtIODevice
> *vdev, VirtQueue *vq)
>      virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
>      VirtQueueElement elem;
>      size_t s;
> -    struct iovec *iov;
> +    struct iovec *iov, *iov2;
>      unsigned int iov_cnt;
>  
>      while (virtqueue_pop(vq, &elem)) {
> @@ -808,8 +808,12 @@ static void virtio_net_handle_ctrl(VirtIODevice
> *vdev, VirtQueue *vq)
>              exit(1);
>          }
>  
> -        iov = elem.out_sg;
>          iov_cnt = elem.out_num;
> +        s = sizeof(struct iovec) * elem.out_num;
> +        iov = g_malloc(s);
> +        memcpy(iov, elem.out_sg, s);
> +        iov2 = iov;
> +
>          s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
>          if (s != sizeof(ctrl)) {
> @@ -833,6 +837,7 @@ static void virtio_net_handle_ctrl(VirtIODevice
> *vdev, VirtQueue *vq)
>  
>          virtqueue_push(vq, &elem, sizeof(status));
>          virtio_notify(vdev, vq);
> +        g_free(iov2);
>      }
>  }
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 10:53:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 10:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtaEF-0003Ta-SF; Wed, 26 Nov 2014 10:53:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtaEF-0003TO-F6
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 10:53:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8E/5D-09842-A31B5745; Wed, 26 Nov 2014 10:53:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416999225!15479411!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22670 invoked from network); 26 Nov 2014 10:53:46 -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;
	26 Nov 2014 10:53:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; 
	d="scan'208,217";a="196719723"
Message-ID: <5475B137.6010405@citrix.com>
Date: Wed, 26 Nov 2014 10:53:43 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: hanyandong <hanyandong@iie.ac.cn>, <xen-devel@lists.xen.org>
References: <1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn>
In-Reply-To: <1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn>
X-DLP: MIA1
Subject: Re: [Xen-devel] About lost record of xentrace,
 how to avoid lost record?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2863187930423110980=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2863187930423110980==
Content-Type: multipart/alternative;
	boundary="------------080107020306030505060501"

--------------080107020306030505060501
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit

On 26/11/14 07:21, hanyandong wrote:
> hi all,
> I found xentrace will lost record if there are too many  event to trace.
> But every event is important to me, so I want to trace all of them,
> not lost one.
> what  could I do to achieve this goal ?
>
> If it need to modify the source code of xentrace, I will do it. But
> will anyone give me some instructions?

xentrace --trace-buf-size=$NUM where $NUM defaults to 32.  Try making it
larger and see whether that helps.

~Andrew

--------------080107020306030505060501
Content-Type: text/html; charset="windows-1252"
Content-Length: 1080
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 26/11/14 07:21, hanyandong wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html;
        charset=3Dwindows-1252">
      hi all,<br>
      I found xentrace will lost record if there are too many=A0 event to
      trace.<br>
      But every event is important to me, so I want to trace all of
      them, not lost one.<br>
      what=A0 could I do to achieve this goal =3F<br>
      <br>
      If it need to modify the source code of xentrace, I will do it.
      But will anyone give me some instructions=3F<br>
    </blockquote>
    <br>
    xentrace --trace-buf-size=3D$NUM where $NUM defaults to 32.=A0 Try
    making it larger and see whether that helps.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------080107020306030505060501--


--===============2863187930423110980==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2863187930423110980==--


From xen-devel-bounces@lists.xen.org Wed Nov 26 10:53:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 10:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtaEF-0003Ta-SF; Wed, 26 Nov 2014 10:53:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtaEF-0003TO-F6
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 10:53:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8E/5D-09842-A31B5745; Wed, 26 Nov 2014 10:53:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1416999225!15479411!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22670 invoked from network); 26 Nov 2014 10:53:46 -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;
	26 Nov 2014 10:53:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; 
	d="scan'208,217";a="196719723"
Message-ID: <5475B137.6010405@citrix.com>
Date: Wed, 26 Nov 2014 10:53:43 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: hanyandong <hanyandong@iie.ac.cn>, <xen-devel@lists.xen.org>
References: <1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn>
In-Reply-To: <1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn>
X-DLP: MIA1
Subject: Re: [Xen-devel] About lost record of xentrace,
 how to avoid lost record?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2863187930423110980=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2863187930423110980==
Content-Type: multipart/alternative;
	boundary="------------080107020306030505060501"

--------------080107020306030505060501
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit

On 26/11/14 07:21, hanyandong wrote:
> hi all,
> I found xentrace will lost record if there are too many  event to trace.
> But every event is important to me, so I want to trace all of them,
> not lost one.
> what  could I do to achieve this goal ?
>
> If it need to modify the source code of xentrace, I will do it. But
> will anyone give me some instructions?

xentrace --trace-buf-size=$NUM where $NUM defaults to 32.  Try making it
larger and see whether that helps.

~Andrew

--------------080107020306030505060501
Content-Type: text/html; charset="windows-1252"
Content-Length: 1080
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 26/11/14 07:21, hanyandong wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html;
        charset=3Dwindows-1252">
      hi all,<br>
      I found xentrace will lost record if there are too many=A0 event to
      trace.<br>
      But every event is important to me, so I want to trace all of
      them, not lost one.<br>
      what=A0 could I do to achieve this goal =3F<br>
      <br>
      If it need to modify the source code of xentrace, I will do it.
      But will anyone give me some instructions=3F<br>
    </blockquote>
    <br>
    xentrace --trace-buf-size=3D$NUM where $NUM defaults to 32.=A0 Try
    making it larger and see whether that helps.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------080107020306030505060501--


--===============2863187930423110980==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2863187930423110980==--


From xen-devel-bounces@lists.xen.org Wed Nov 26 11:48:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 11:48:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtb4g-0004HS-Eh; Wed, 26 Nov 2014 11:47:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xtb4f-0004HN-Cm
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 11:47:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6B/51-25276-BEDB5745; Wed, 26 Nov 2014 11:47:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417002473!12018482!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31329 invoked from network); 26 Nov 2014 11:47:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 11:47:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196731031"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 06:47:52 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xtb4a-00018f-7R;
	Wed, 26 Nov 2014 11:47:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xtb4Z-0006Qb-Tz;
	Wed, 26 Nov 2014 11:47:51 +0000
Date: Wed, 26 Nov 2014 11:47:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31856-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31856: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31856 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31856/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 31844
 test-amd64-i386-pair          8 xen-boot/dst_host           fail pass in 31844
 test-amd64-i386-pair          7 xen-boot/src_host           fail pass in 31844
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install      fail pass in 31817
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot   fail in 31844 pass in 31856

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail blocked in 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail in 31844 blocked in 26303
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 31844 like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31817 never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 33063 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 Nov 26 11:48:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 11:48:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtb4g-0004HS-Eh; Wed, 26 Nov 2014 11:47:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xtb4f-0004HN-Cm
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 11:47:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6B/51-25276-BEDB5745; Wed, 26 Nov 2014 11:47:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417002473!12018482!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31329 invoked from network); 26 Nov 2014 11:47:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 11:47:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196731031"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 06:47:52 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xtb4a-00018f-7R;
	Wed, 26 Nov 2014 11:47:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xtb4Z-0006Qb-Tz;
	Wed, 26 Nov 2014 11:47:51 +0000
Date: Wed, 26 Nov 2014 11:47:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31856-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31856: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31856 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31856/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 31844
 test-amd64-i386-pair          8 xen-boot/dst_host           fail pass in 31844
 test-amd64-i386-pair          7 xen-boot/src_host           fail pass in 31844
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install      fail pass in 31817
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot   fail in 31844 pass in 31856

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail blocked in 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail in 31844 blocked in 26303
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 31844 like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31817 never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 33063 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 Nov 26 11:59:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 11: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 1XtbFt-0004Ub-LW; Wed, 26 Nov 2014 11:59:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtbFs-0004UW-4w
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 11:59:32 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B9/9C-31453-3A0C5745; Wed, 26 Nov 2014 11:59:31 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417003168!13387762!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9546 invoked from network); 26 Nov 2014 11:59:29 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Nov 2014 11:59:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQBxOi9006151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 11:59:24 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQBxMGF020805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 11:59:23 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQBxMdW014707; Wed, 26 Nov 2014 11:59:22 GMT
Received: from [192.168.4.100] (/24.41.5.236)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 03:59:22 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <1416995122.11944.29.camel@citrix.com>
References: <5474E537.7010707@oracle.com>
	<1416995122.11944.29.camel@citrix.com>
MIME-Version: 1.0
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Wed, 26 Nov 2014 06:59:17 -0500
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <1F1394CF-AEFA-4A55-97B5-0A1BCBBA5056@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	programme110@gmail.com, David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>, davem@davemloft.net
Subject: Re: [Xen-devel] Regression in netfilter code under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2990573173108248717=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2990573173108248717==
Content-Type: multipart/alternative; boundary="----Y1S5AIESM1BU41DWPZE6JBF7W3PDPV"
Content-Transfer-Encoding: 7bit

------Y1S5AIESM1BU41DWPZE6JBF7W3PDPV
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

No, this happens before guests are started=2E



On November 26, 2014 4:45:22 AM EST, Ian Campbell <Ian=2ECampbell@citrix=
=2Ecom> wrote:
>On Tue, 2014-11-25 at 15:23 -0500, Boris Ostrovsky wrote:
>> We have a regression due to (5195c14c8: netfilter: conntrack: fix
>race=20
>> in __nf_conntrack_confirm against get_next_corpse)=2E I have not been
>able=20
>> to reproduce this on baremetal but dom0 crashes reliably after a few=20
>> seconds of idle time=2E
>
>Are guests running when this happens? (IOW is netback possibly
>involved)=2E
>
>>  This doesn't appear to be dependent on Xen version=20
>> --- I saw it on at least a 4=2E2 and unstable)=2E
>>=20
>> I don't know much about networking (and will be out for most of the
>rest=20
>> of the week) so I wonder whether anyone has any ideas=2E The stack is
>below=2E
>>=20
>>=20
>> Thanks=2E
>> -boris
>>=20
>> # =07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07
>>
>=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07[=20
>> 54=2E901368] general protection fault: 0000 [#1] SMP
>> [   54=2E919324] Modules linked in: dm_multipath dm_mod xen_evtchn=20
>> iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport=07=20
>> libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod i915
>fbcon=20
>> tileblit font bitblit softcursor tpm_tis ahci libahci libata=20
>> drm_kms_helper video scsi_mod e1000e wmi xen_blkfront xen_netfront=20
>> fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd
>> [   54=2E996767] CPU: 1 PID: 0 Comm: swapper/1 Not tainted=20
>> 3=2E18=2E0-rc5upstream-00179-g8a84e01 #1
>> [   55=2E016730] Hardware name: LENOVO ThinkServer TS130/        , BIOS
>
>> 9HKT47AUS 01/10/2012
>> [   55=2E036873] task: ffff880037e48a10 ti: ffff880037e54000 task=2Eti:=
=20
>> ffff880037e54000
>> [   55=2E057338] RIP: e030:[<ffffffff815ea29e>] [<ffffffff815ea29e>]=20
>> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
>> [   55=2E=07[   55=2E099069] RAX: dead000000200200 RBX: ffffe8ffffc8910=
8
>RCX:=20
>> ffffffff81cc5820
>> [   55=2E119918] RDX: 0000000080000001 RSI: 0000000000000011 RDI:=20
>> ffffe8ffffc89108
>> [   55=2E140768] RBP: ffff88003e283908 R08: 00000000c5f889ff R09:=20
>> 00000000a1a10f28
>> [   55=2E161785] R10: ffff880037e5f1b8 R11: 0000000000000001 R12:=20
>> ffff880037e5f148
>> [   55=2E183005] R13: ffffffff815e6a6b R14: ffff88002bed8400 R15:=20
>> ffff88002bb30000
>> [   55=2E204214] FS:  00007f668f694700(0000) GS=07[   55=2E225733] CS: =
e033
>
>> DS: 002b ES: 002b CR0: 0000000080050033
>> [   55=2E247220] CR2: 00007f66c0a598eb CR3: 000000002bc39000 CR4:=20
>> 0000000000042660
>> [   55=2E268863] Stack:
>> [   55=2E290200]  ffff880037e5f148 ffffffff81c98080 ffff88003e283928=20
>> ffffffff815eb59d
>> [   55=2E312068]  ffff88002bed8400 ffff88002bed8400 ffff88003e283938=20
>> ffffffff815e689a
>> [   55=2E333849]  ffff88003e283958 ffffffff815a37a5 ffff88003e283968=20
>> ffff88002bed8400
>> [   55=2E355449] Call Trace:
>> [   55=2E376552]  <IRQ>
>> [   55=2E376728]  [<ffffffff815eb59d>] destroy_conntrack+0x5d/0xc0
>> [   55=2E418187]  [<ffffffff815e689a>] nf_conntrack_destroy+0x1a/0x40
>> [   55=2E439349]  [<ffffffff815a37a5>] skb_release_head_state+0x85/0xd0
>> [   55=2E460468]  [<ffffffff815a5d61>] skb_release_all+0x11/0x30
>> [   55=2E481440]  [<ffffffff815a5dd1>] __kfree_skb+0x11/0xc0
>> [   55=2E502239]  [<ffffffff815a5f78>] kfree_skb+0x38/0xa0
>> [   55=2E522661]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
>> [   55=2E542811]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
>> [   55=2E562543]  [<ffffffff815e6a6b>] nf_hook_slow+0x10b/0x120
>> [   55=2E582100]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
>> [   55=2E601470]  [<ffffffff8170a02b>] ?
>_raw_spin_unlock_irqrestore+0=07[  =20
>> 55=2E620900] [<ffffffff81604713>] ip_local_deliver+0x73/0x80
>> [   55=2E640154]  [<ffffffff81603dc9>] ip_rcv_finish+0x109/0x310
>> [   55=2E659244]  [<ffffffff8160439c>] ip_rcv+0x28c/0x3a0
>> [   55=2E678287]  [<ffffffff815b69ae>]=20
>> __netif_receive_skb_core+0x58e/0x=07[   55=2E697287] [<ffffffff815b6b4d=
>]
>
>> __netif_receive_skb+0x1d/0x70
>> [   55=2E715820]  [<ffffffff815b6d9e>]
>netif_receive_skb_internal+0x1e/0xb0
>> [   55=2E734442]  [<ffffffff815b6e47>] netif_receive_skb+0x17/0x70
>> [   55=2E752898]  [<ffffffff816c17e2>]
>br_handle_frame_finish+0x192/0x360
>> [   55=2E771709]  [<ffffffff816c156d>] br_handle_frame+0
>> =07=07=07[   55=2E790274]  [<ffffffff816c13f0>] ?
>br_handle_local_finish+0x40/0x40
>> [   55=2E808760]  [<ffffffff815b65f7>]
>__netif_receive_skb_core+0x1d7/0x710
>> [   55=2E827302]  [<ffffffff815b6b4d>] __netif_receive_skb+0x1d/0x70
>> [   55=2E845594]  [<ffffffff815b6d9e>]
>netif_receive_skb_internal+0x1e/0xb0
>> [   55=2E863836]  [<ffffffff815b7a38>] napi_gro_receive+0x118/0x1a0
>> [   55=2E881549]  [<ffffffff814c430f>] tg3_poll_work+0xe1f/0x1=07[  =20
>> 55=2E898629]  [<ffffffff814d75c9>] tg3_poll+0x69/0x3c0
>> [   55=2E915010]  [<ffffffff815b7523>] net_rx_action+0x103/0x290
>> [   55=2E930840]  [<ffffffff810a7713>] __do_softirq+0xf3/0x2e0
>> [   55=2E946310]  [<ffffffff810a7a2d>] irq_exit+0xcd/0xe0
>> [   55=2E961399]  [<ffffffff8140d4c7>] xen_evtchn_do_upcall+0x37/0x50
>> 766]  [<ffffffff8170c1fe>] xen_do_hypervisor_callback+0x1e/0x30
>> =07=07=07[   55=2E990802]  <EOI>
>> [   55=2E990977]  [<ffffffff810013aa>] ?
>xen_hypercall_sched_op+0xa/0x20
>> [   56=2E018897]  [<ffffffff810013aa>] ?
>xen_hypercall_sched_op+0xa/0x20
>> [   56=2E032815]  [<ffffffff810454b0>] ? xen_safe_halt+0x10/0x20
>> [   56=2E046583]  [<ffffffff81059e3a>] ? default_idle+0x1a/0xd0
>> [   56=2E060307]  [<ffffffff8105950a>] ? arch_cpu_idle+0xa/0x10
>> [   56=2E073920]  [<ffffffff810de483>] ? cpu_startup_entry+0x2d3/0=07[ =
 =20
>> 56=2E100421]  [<ffffffff8104c355>] ? cpu_bringup_and_idle+0x25/0x40
>> [   56=2E113427] Code: 98 08 08 00 00 0f b7 47 08 48 03 1c c5 a0 42 cc
>81=20
>> 48 89 df e8 94 fc 11 00 49 8b 44 24 18 48 85 c0 74 2d 49=07=07=07=07=07=
=07=07=07=07[  =20
>> 56=2E141507] RIP  [<ffffffff815ea29e>]=20
>> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
>> [   56=2E155425]  RSP <ffff88003e2838f8>
>> [   56=2E169234] ---[ end trace 4c64578e4c629cc4 ]---
>> [   56=2E182913] Kernel panic - not syncing: Fatal exception in
>interrupt
>> [   56=2E197026] Kernel Offset: 0x0 from 0xffffffff81000k  text console
>> (XEN) [2014-11-23 06:05:48] Domain 0 crashed: rebooting machine in 5=20
>> seconds=2E
>> (XEN) [2014-11-23 06:05:53] Resetting with ACPI MEMORY or I/O
>RESET_REG=2E
>>=20
>>=20
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists=2Exen=2Eorg
>> http://lists=2Exen=2Eorg/xen-devel



-boris@phone
------Y1S5AIESM1BU41DWPZE6JBF7W3PDPV
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4=2E0 Transitional//EN">
<html><head><meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Con=
tent-Type"></head>No, this happens before guests are started=2E<br>
<br>
<br><br><div class=3D"gmail_quote">On November 26, 2014 4:45:22 AM EST, Ia=
n Campbell &lt;Ian=2ECampbell@citrix=2Ecom&gt; wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px solid rg=
b(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On Tue, 2014-11-25 at 15:23 -0500, Boris Ostrovsky w=
rote:<br /><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=
=2E8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> We have a regr=
ession due to (5195c14c8: netfilter: conntrack: fix race <br /> in __nf_con=
ntrack_confirm against get_next_corpse)=2E I have not been able <br /> to r=
eproduce this on baremetal but dom0 crashes reliably after a few <br /> sec=
onds of idle time=2E<br /></blockquote><br />Are guests running when this h=
appens? (IOW is netback possibly<br />involved)=2E<br /><br /><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px=
 solid #729fcf; padding-left: 1ex;">  This doesn't appear to be dependent o=
n Xen version <br /> --- I saw it on at least a 4=2E2 and unstable)=2E<br /=
> <br /> I don't know much about networking (and will be out for most of th=
e rest <br /> of the week) so I wonder whether anyone has any ideas=2E The =
stack is below=2E<br /> <br /> <br /> Thanks=2E<br /> -boris<br /> <br /> #=
 =07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07<br /> =07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07[ <br /> 54=2E901368] general protection fault: 0000 [#1] SMP<br /> [   =
54=2E919324] Modules linked in: dm_multipath dm_mod xen_evtchn <br /> iscsi=
_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport=07 <br /> libcrc=
32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod i915 fbcon <br /> ti=
leblit font bitblit softcursor tpm_tis ahci libahci libata <br /> drm_kms_h=
elper video scsi_mod e1000e wmi xen_blkfront xen_netfront <br /> fb_sys_fop=
s sysimgblt sysfillrect syscopyarea xenfs xen_privcmd<br /> [   54=2E996767=
] CPU: 1 PID: 0 Comm: swapper/1 Not tainted <br /> 3=2E18=2E0-rc5upstream-0=
0179-g8a84e01 #1<br /> [   55=2E016730] Hardware name: LENOVO ThinkServer T=
S130/        , BIOS <br /> 9HKT47AUS 01/10/2012<br /> [   55=2E036873] task=
: ffff880037e48a10 ti: ffff880037e54000 task=2Eti: <br /> ffff880037e54000<=
br /> [   55=2E057338] RIP: e030:[&lt;ffffffff815ea29e&gt;] [&lt;ffffffff81=
5ea29e&gt;] <br /> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70<br />=
 [   55=2E=07[   55=2E099069] RAX: dead000000200200 RBX: ffffe8ffffc89108 R=
CX: <br /> ffffffff81cc5820<br /> [   55=2E119918] RDX: 0000000080000001 RS=
I: 0000000000000011 RDI: <br /> ffffe8ffffc89108<br /> [   55=2E140768] RBP=
: ffff88003e283908 R08: 00000000c5f889ff R09: <br /> 00000000a1a10f28<br />=
 [   55=2E161785] R10: ffff880037e5f1b8 R11: 0000000000000001 R12: <br /> f=
fff880037e5f148<br /> [   55=2E183005] R13: ffffffff815e6a6b R14: ffff88002=
bed8400 R15: <br /> ffff88002bb30000<br /> [   55=2E204214] FS:  00007f668f=
694700(0000) GS=07[   55=2E225733] CS: e033 <br /> DS: 002b ES: 002b CR0: 0=
000000080050033<br /> [   55=2E247220] CR2: 00007f66c0a598eb CR3: 000000002=
bc39000 CR4: <br /> 0000000000042660<br /> [   55=2E268863] Stack:<br /> [ =
  55=2E290200]  ffff880037e5f148 ffffffff81c98080 ffff88003e283928 <br /> f=
fffffff815eb59d<br /> [   55=2E312068]  ffff88002bed8400 ffff88002bed8400 f=
fff88003e283938 <br /> ffffffff815e689a<br /> [   55=2E333849]  ffff88003e2=
83958 ffffffff815a37a5 ffff88003e283968 <br /> ffff88002bed8400<br /> [   5=
5=2E355449] Call Trace:<br /> [   55=2E376552]  &lt;IRQ&gt;<br /> [   55=2E=
376728]  [&lt;ffffffff815eb59d&gt;] destroy_conntrack+0x5d/0xc0<br /> [   5=
5=2E418187]  [&lt;ffffffff815e689a&gt;] nf_conntrack_destroy+0x1a/0x40<br /=
> [   55=2E439349]  [&lt;ffffffff815a37a5&gt;] skb_release_head_state+0x85/=
0xd0<br /> [   55=2E460468]  [&lt;ffffffff815a5d61&gt;] skb_release_all+0x1=
1/0x30<br /> [   55=2E481440]  [&lt;ffffffff815a5dd1&gt;] __kfree_skb+0x11/=
0xc0<br /> [   55=2E502239]  [&lt;ffffffff815a5f78&gt;] kfree_skb+0x38/0xa0=
<br /> [   55=2E522661]  [&lt;ffffffff816044b0&gt;] ? ip_rcv+0x3a0/0x3a0<br=
 /> [   55=2E542811]  [&lt;ffffffff816044b0&gt;] ? ip_rcv+0x3a0/0x3a0<br />=
 [   55=2E562543]  [&lt;ffffffff815e6a6b&gt;] nf_hook_slow+0x10b/0x120<br /=
> [   55=2E582100]  [&lt;ffffffff816044b0&gt;] ? ip_rcv+0x3a0/0x3a0<br /> [=
   55=2E601470]  [&lt;ffffffff8170a02b&gt;] ? _raw_spin_unlock_irqrestore+0=
=07[   <br /> 55=2E620900] [&lt;ffffffff81604713&gt;] ip_local_deliver+0x73=
/0x80<br /> [   55=2E640154]  [&lt;ffffffff81603dc9&gt;] ip_rcv_finish+0x10=
9/0x310<br /> [   55=2E659244]  [&lt;ffffffff8160439c&gt;] ip_rcv+0x28c/0x3=
a0<br /> [   55=2E678287]  [&lt;ffffffff815b69ae&gt;] <br /> __netif_receiv=
e_skb_core+0x58e/0x=07[   55=2E697287] [&lt;ffffffff815b6b4d&gt;] <br /> __=
netif_receive_skb+0x1d/0x70<br /> [   55=2E715820]  [&lt;ffffffff815b6d9e&g=
t;] netif_receive_skb_internal+0x1e/0xb0<br /> [   55=2E734442]  [&lt;fffff=
fff815b6e47&gt;] netif_receive_skb+0x17/0x70<br /> [   55=2E752898]  [&lt;f=
fffffff816c17e2&gt;] br_handle_frame_finish+0x192/0x360<br /> [   55=2E7717=
09]  [&lt;ffffffff816c156d&gt;] br_handle_frame+0<br /> =07=07=07[   55=2E7=
90274]  [&lt;ffffffff816c13f0&gt;] ? br_handle_local_finish+0x40/0x40<br />=
 [   55=2E808760]  [&lt;ffffffff815b65f7&gt;] __netif_receive_skb_core+0x1d=
7/0x710<br /> [   55=2E827302]  [&lt;ffffffff815b6b4d&gt;] __netif_receive_=
skb+0x1d/0x70<br /> [   55=2E845594]  [&lt;ffffffff815b6d9e&gt;] netif_rece=
ive_skb_internal+0x1e/0xb0<br /> [   55=2E863836]  [&lt;ffffffff815b7a38&gt=
;] napi_gro_receive+0x118/0x1a0<br /> [   55=2E881549]  [&lt;ffffffff814c43=
0f&gt;] tg3_poll_work+0xe1f/0x1=07[   <br /> 55=2E898629]  [&lt;ffffffff814=
d75c9&gt;] tg3_poll+0x69/0x3c0<br /> [   55=2E915010]  [&lt;ffffffff815b752=
3&gt;] net_rx_action+0x103/0x290<br /> [   55=2E930840]  [&lt;ffffffff810a7=
713&gt;] __do_softirq+0xf3/0x2e0<br /> [   55=2E946310]  [&lt;ffffffff810a7=
a2d&gt;] irq_exit+0xcd/0xe0<br /> [   55=2E961399]  [&lt;ffffffff8140d4c7&g=
t;] xen_evtchn_do_upcall+0x37/0x50<br /> 766]  [&lt;ffffffff8170c1fe&gt;] x=
en_do_hypervisor_callback+0x1e/0x30<br /> =07=07=07[   55=2E990802]  &lt;EO=
I&gt;<br /> [   55=2E990977]  [&lt;ffffffff810013aa&gt;] ? xen_hypercall_sc=
hed_op+0xa/0x20<br /> [   56=2E018897]  [&lt;ffffffff810013aa&gt;] ? xen_hy=
percall_sched_op+0xa/0x20<br /> [   56=2E032815]  [&lt;ffffffff810454b0&gt;=
] ? xen_safe_halt+0x10/0x20<br /> [   56=2E046583]  [&lt;ffffffff81059e3a&g=
t;] ? default_idle+0x1a/0xd0<br /> [   56=2E060307]  [&lt;ffffffff8105950a&=
gt;] ? arch_cpu_idle+0xa/0x10<br /> [   56=2E073920]  [&lt;ffffffff810de483=
&gt;] ? cpu_startup_entry+0x2d3/0=07[   <br /> 56=2E100421]  [&lt;ffffffff8=
104c355&gt;] ? cpu_bringup_and_idle+0x25/0x40<br /> [   56=2E113427] Code: =
98 08 08 00 00 0f b7 47 08 48 03 1c c5 a0 42 cc 81 <br /> 48 89 df e8 94 fc=
 11 00 49 8b 44 24 18 48 85 c0 74 2d 49=07=07=07=07=07=07=07=07=07[   <br /=
> 56=2E141507] RIP  [&lt;ffffffff815ea29e&gt;] <br /> nf_ct_del_from_dying_=
or_unconfirmed_list+0x3e/0x70<br /> [   56=2E155425]  RSP &lt;ffff88003e283=
8f8&gt;<br /> [   56=2E169234] ---[ end trace 4c64578e4c629cc4 ]---<br /> [=
   56=2E182913] Kernel panic - not syncing: Fatal exception in interrupt<br=
 /> [   56=2E197026] Kernel Offset: 0x0 from 0xffffffff81000k  text console=
<br /> (XEN) [2014-11-23 06:05:48] Domain 0 crashed: rebooting machine in 5=
 <br /> seconds=2E<br /> (XEN) [2014-11-23 06:05:53] Resetting with ACPI ME=
MORY or I/O RESET_REG=2E<br /> <br /> <br /><hr /><br /> Xen-devel mailing =
list<br /> Xen-devel@lists=2Exen=2Eorg<br /> <a href=3D"http://lists=2Exen=
=2Eorg/xen-devel">http://lists=2Exen=2Eorg/xen-devel</a><br /></blockquote>=
<br /><br /></pre></blockquote></div><br>
<br>
<br>
-boris@phone</html>
------Y1S5AIESM1BU41DWPZE6JBF7W3PDPV--



--===============2990573173108248717==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2990573173108248717==--



From xen-devel-bounces@lists.xen.org Wed Nov 26 11:59:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 11: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 1XtbFt-0004Ub-LW; Wed, 26 Nov 2014 11:59:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtbFs-0004UW-4w
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 11:59:32 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	B9/9C-31453-3A0C5745; Wed, 26 Nov 2014 11:59:31 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417003168!13387762!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9546 invoked from network); 26 Nov 2014 11:59:29 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Nov 2014 11:59:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQBxOi9006151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 11:59:24 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQBxMGF020805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 11:59:23 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQBxMdW014707; Wed, 26 Nov 2014 11:59:22 GMT
Received: from [192.168.4.100] (/24.41.5.236)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 03:59:22 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <1416995122.11944.29.camel@citrix.com>
References: <5474E537.7010707@oracle.com>
	<1416995122.11944.29.camel@citrix.com>
MIME-Version: 1.0
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Wed, 26 Nov 2014 06:59:17 -0500
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <1F1394CF-AEFA-4A55-97B5-0A1BCBBA5056@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	programme110@gmail.com, David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>, davem@davemloft.net
Subject: Re: [Xen-devel] Regression in netfilter code under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2990573173108248717=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2990573173108248717==
Content-Type: multipart/alternative; boundary="----Y1S5AIESM1BU41DWPZE6JBF7W3PDPV"
Content-Transfer-Encoding: 7bit

------Y1S5AIESM1BU41DWPZE6JBF7W3PDPV
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

No, this happens before guests are started=2E



On November 26, 2014 4:45:22 AM EST, Ian Campbell <Ian=2ECampbell@citrix=
=2Ecom> wrote:
>On Tue, 2014-11-25 at 15:23 -0500, Boris Ostrovsky wrote:
>> We have a regression due to (5195c14c8: netfilter: conntrack: fix
>race=20
>> in __nf_conntrack_confirm against get_next_corpse)=2E I have not been
>able=20
>> to reproduce this on baremetal but dom0 crashes reliably after a few=20
>> seconds of idle time=2E
>
>Are guests running when this happens? (IOW is netback possibly
>involved)=2E
>
>>  This doesn't appear to be dependent on Xen version=20
>> --- I saw it on at least a 4=2E2 and unstable)=2E
>>=20
>> I don't know much about networking (and will be out for most of the
>rest=20
>> of the week) so I wonder whether anyone has any ideas=2E The stack is
>below=2E
>>=20
>>=20
>> Thanks=2E
>> -boris
>>=20
>> # =07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07
>>
>=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07[=20
>> 54=2E901368] general protection fault: 0000 [#1] SMP
>> [   54=2E919324] Modules linked in: dm_multipath dm_mod xen_evtchn=20
>> iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport=07=20
>> libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod i915
>fbcon=20
>> tileblit font bitblit softcursor tpm_tis ahci libahci libata=20
>> drm_kms_helper video scsi_mod e1000e wmi xen_blkfront xen_netfront=20
>> fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd
>> [   54=2E996767] CPU: 1 PID: 0 Comm: swapper/1 Not tainted=20
>> 3=2E18=2E0-rc5upstream-00179-g8a84e01 #1
>> [   55=2E016730] Hardware name: LENOVO ThinkServer TS130/        , BIOS
>
>> 9HKT47AUS 01/10/2012
>> [   55=2E036873] task: ffff880037e48a10 ti: ffff880037e54000 task=2Eti:=
=20
>> ffff880037e54000
>> [   55=2E057338] RIP: e030:[<ffffffff815ea29e>] [<ffffffff815ea29e>]=20
>> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
>> [   55=2E=07[   55=2E099069] RAX: dead000000200200 RBX: ffffe8ffffc8910=
8
>RCX:=20
>> ffffffff81cc5820
>> [   55=2E119918] RDX: 0000000080000001 RSI: 0000000000000011 RDI:=20
>> ffffe8ffffc89108
>> [   55=2E140768] RBP: ffff88003e283908 R08: 00000000c5f889ff R09:=20
>> 00000000a1a10f28
>> [   55=2E161785] R10: ffff880037e5f1b8 R11: 0000000000000001 R12:=20
>> ffff880037e5f148
>> [   55=2E183005] R13: ffffffff815e6a6b R14: ffff88002bed8400 R15:=20
>> ffff88002bb30000
>> [   55=2E204214] FS:  00007f668f694700(0000) GS=07[   55=2E225733] CS: =
e033
>
>> DS: 002b ES: 002b CR0: 0000000080050033
>> [   55=2E247220] CR2: 00007f66c0a598eb CR3: 000000002bc39000 CR4:=20
>> 0000000000042660
>> [   55=2E268863] Stack:
>> [   55=2E290200]  ffff880037e5f148 ffffffff81c98080 ffff88003e283928=20
>> ffffffff815eb59d
>> [   55=2E312068]  ffff88002bed8400 ffff88002bed8400 ffff88003e283938=20
>> ffffffff815e689a
>> [   55=2E333849]  ffff88003e283958 ffffffff815a37a5 ffff88003e283968=20
>> ffff88002bed8400
>> [   55=2E355449] Call Trace:
>> [   55=2E376552]  <IRQ>
>> [   55=2E376728]  [<ffffffff815eb59d>] destroy_conntrack+0x5d/0xc0
>> [   55=2E418187]  [<ffffffff815e689a>] nf_conntrack_destroy+0x1a/0x40
>> [   55=2E439349]  [<ffffffff815a37a5>] skb_release_head_state+0x85/0xd0
>> [   55=2E460468]  [<ffffffff815a5d61>] skb_release_all+0x11/0x30
>> [   55=2E481440]  [<ffffffff815a5dd1>] __kfree_skb+0x11/0xc0
>> [   55=2E502239]  [<ffffffff815a5f78>] kfree_skb+0x38/0xa0
>> [   55=2E522661]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
>> [   55=2E542811]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
>> [   55=2E562543]  [<ffffffff815e6a6b>] nf_hook_slow+0x10b/0x120
>> [   55=2E582100]  [<ffffffff816044b0>] ? ip_rcv+0x3a0/0x3a0
>> [   55=2E601470]  [<ffffffff8170a02b>] ?
>_raw_spin_unlock_irqrestore+0=07[  =20
>> 55=2E620900] [<ffffffff81604713>] ip_local_deliver+0x73/0x80
>> [   55=2E640154]  [<ffffffff81603dc9>] ip_rcv_finish+0x109/0x310
>> [   55=2E659244]  [<ffffffff8160439c>] ip_rcv+0x28c/0x3a0
>> [   55=2E678287]  [<ffffffff815b69ae>]=20
>> __netif_receive_skb_core+0x58e/0x=07[   55=2E697287] [<ffffffff815b6b4d=
>]
>
>> __netif_receive_skb+0x1d/0x70
>> [   55=2E715820]  [<ffffffff815b6d9e>]
>netif_receive_skb_internal+0x1e/0xb0
>> [   55=2E734442]  [<ffffffff815b6e47>] netif_receive_skb+0x17/0x70
>> [   55=2E752898]  [<ffffffff816c17e2>]
>br_handle_frame_finish+0x192/0x360
>> [   55=2E771709]  [<ffffffff816c156d>] br_handle_frame+0
>> =07=07=07[   55=2E790274]  [<ffffffff816c13f0>] ?
>br_handle_local_finish+0x40/0x40
>> [   55=2E808760]  [<ffffffff815b65f7>]
>__netif_receive_skb_core+0x1d7/0x710
>> [   55=2E827302]  [<ffffffff815b6b4d>] __netif_receive_skb+0x1d/0x70
>> [   55=2E845594]  [<ffffffff815b6d9e>]
>netif_receive_skb_internal+0x1e/0xb0
>> [   55=2E863836]  [<ffffffff815b7a38>] napi_gro_receive+0x118/0x1a0
>> [   55=2E881549]  [<ffffffff814c430f>] tg3_poll_work+0xe1f/0x1=07[  =20
>> 55=2E898629]  [<ffffffff814d75c9>] tg3_poll+0x69/0x3c0
>> [   55=2E915010]  [<ffffffff815b7523>] net_rx_action+0x103/0x290
>> [   55=2E930840]  [<ffffffff810a7713>] __do_softirq+0xf3/0x2e0
>> [   55=2E946310]  [<ffffffff810a7a2d>] irq_exit+0xcd/0xe0
>> [   55=2E961399]  [<ffffffff8140d4c7>] xen_evtchn_do_upcall+0x37/0x50
>> 766]  [<ffffffff8170c1fe>] xen_do_hypervisor_callback+0x1e/0x30
>> =07=07=07[   55=2E990802]  <EOI>
>> [   55=2E990977]  [<ffffffff810013aa>] ?
>xen_hypercall_sched_op+0xa/0x20
>> [   56=2E018897]  [<ffffffff810013aa>] ?
>xen_hypercall_sched_op+0xa/0x20
>> [   56=2E032815]  [<ffffffff810454b0>] ? xen_safe_halt+0x10/0x20
>> [   56=2E046583]  [<ffffffff81059e3a>] ? default_idle+0x1a/0xd0
>> [   56=2E060307]  [<ffffffff8105950a>] ? arch_cpu_idle+0xa/0x10
>> [   56=2E073920]  [<ffffffff810de483>] ? cpu_startup_entry+0x2d3/0=07[ =
 =20
>> 56=2E100421]  [<ffffffff8104c355>] ? cpu_bringup_and_idle+0x25/0x40
>> [   56=2E113427] Code: 98 08 08 00 00 0f b7 47 08 48 03 1c c5 a0 42 cc
>81=20
>> 48 89 df e8 94 fc 11 00 49 8b 44 24 18 48 85 c0 74 2d 49=07=07=07=07=07=
=07=07=07=07[  =20
>> 56=2E141507] RIP  [<ffffffff815ea29e>]=20
>> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
>> [   56=2E155425]  RSP <ffff88003e2838f8>
>> [   56=2E169234] ---[ end trace 4c64578e4c629cc4 ]---
>> [   56=2E182913] Kernel panic - not syncing: Fatal exception in
>interrupt
>> [   56=2E197026] Kernel Offset: 0x0 from 0xffffffff81000k  text console
>> (XEN) [2014-11-23 06:05:48] Domain 0 crashed: rebooting machine in 5=20
>> seconds=2E
>> (XEN) [2014-11-23 06:05:53] Resetting with ACPI MEMORY or I/O
>RESET_REG=2E
>>=20
>>=20
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists=2Exen=2Eorg
>> http://lists=2Exen=2Eorg/xen-devel



-boris@phone
------Y1S5AIESM1BU41DWPZE6JBF7W3PDPV
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4=2E0 Transitional//EN">
<html><head><meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Con=
tent-Type"></head>No, this happens before guests are started=2E<br>
<br>
<br><br><div class=3D"gmail_quote">On November 26, 2014 4:45:22 AM EST, Ia=
n Campbell &lt;Ian=2ECampbell@citrix=2Ecom&gt; wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px solid rg=
b(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On Tue, 2014-11-25 at 15:23 -0500, Boris Ostrovsky w=
rote:<br /><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=
=2E8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> We have a regr=
ession due to (5195c14c8: netfilter: conntrack: fix race <br /> in __nf_con=
ntrack_confirm against get_next_corpse)=2E I have not been able <br /> to r=
eproduce this on baremetal but dom0 crashes reliably after a few <br /> sec=
onds of idle time=2E<br /></blockquote><br />Are guests running when this h=
appens? (IOW is netback possibly<br />involved)=2E<br /><br /><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px=
 solid #729fcf; padding-left: 1ex;">  This doesn't appear to be dependent o=
n Xen version <br /> --- I saw it on at least a 4=2E2 and unstable)=2E<br /=
> <br /> I don't know much about networking (and will be out for most of th=
e rest <br /> of the week) so I wonder whether anyone has any ideas=2E The =
stack is below=2E<br /> <br /> <br /> Thanks=2E<br /> -boris<br /> <br /> #=
 =07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07<br /> =07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=07=
=07[ <br /> 54=2E901368] general protection fault: 0000 [#1] SMP<br /> [   =
54=2E919324] Modules linked in: dm_multipath dm_mod xen_evtchn <br /> iscsi=
_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport=07 <br /> libcrc=
32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod i915 fbcon <br /> ti=
leblit font bitblit softcursor tpm_tis ahci libahci libata <br /> drm_kms_h=
elper video scsi_mod e1000e wmi xen_blkfront xen_netfront <br /> fb_sys_fop=
s sysimgblt sysfillrect syscopyarea xenfs xen_privcmd<br /> [   54=2E996767=
] CPU: 1 PID: 0 Comm: swapper/1 Not tainted <br /> 3=2E18=2E0-rc5upstream-0=
0179-g8a84e01 #1<br /> [   55=2E016730] Hardware name: LENOVO ThinkServer T=
S130/        , BIOS <br /> 9HKT47AUS 01/10/2012<br /> [   55=2E036873] task=
: ffff880037e48a10 ti: ffff880037e54000 task=2Eti: <br /> ffff880037e54000<=
br /> [   55=2E057338] RIP: e030:[&lt;ffffffff815ea29e&gt;] [&lt;ffffffff81=
5ea29e&gt;] <br /> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70<br />=
 [   55=2E=07[   55=2E099069] RAX: dead000000200200 RBX: ffffe8ffffc89108 R=
CX: <br /> ffffffff81cc5820<br /> [   55=2E119918] RDX: 0000000080000001 RS=
I: 0000000000000011 RDI: <br /> ffffe8ffffc89108<br /> [   55=2E140768] RBP=
: ffff88003e283908 R08: 00000000c5f889ff R09: <br /> 00000000a1a10f28<br />=
 [   55=2E161785] R10: ffff880037e5f1b8 R11: 0000000000000001 R12: <br /> f=
fff880037e5f148<br /> [   55=2E183005] R13: ffffffff815e6a6b R14: ffff88002=
bed8400 R15: <br /> ffff88002bb30000<br /> [   55=2E204214] FS:  00007f668f=
694700(0000) GS=07[   55=2E225733] CS: e033 <br /> DS: 002b ES: 002b CR0: 0=
000000080050033<br /> [   55=2E247220] CR2: 00007f66c0a598eb CR3: 000000002=
bc39000 CR4: <br /> 0000000000042660<br /> [   55=2E268863] Stack:<br /> [ =
  55=2E290200]  ffff880037e5f148 ffffffff81c98080 ffff88003e283928 <br /> f=
fffffff815eb59d<br /> [   55=2E312068]  ffff88002bed8400 ffff88002bed8400 f=
fff88003e283938 <br /> ffffffff815e689a<br /> [   55=2E333849]  ffff88003e2=
83958 ffffffff815a37a5 ffff88003e283968 <br /> ffff88002bed8400<br /> [   5=
5=2E355449] Call Trace:<br /> [   55=2E376552]  &lt;IRQ&gt;<br /> [   55=2E=
376728]  [&lt;ffffffff815eb59d&gt;] destroy_conntrack+0x5d/0xc0<br /> [   5=
5=2E418187]  [&lt;ffffffff815e689a&gt;] nf_conntrack_destroy+0x1a/0x40<br /=
> [   55=2E439349]  [&lt;ffffffff815a37a5&gt;] skb_release_head_state+0x85/=
0xd0<br /> [   55=2E460468]  [&lt;ffffffff815a5d61&gt;] skb_release_all+0x1=
1/0x30<br /> [   55=2E481440]  [&lt;ffffffff815a5dd1&gt;] __kfree_skb+0x11/=
0xc0<br /> [   55=2E502239]  [&lt;ffffffff815a5f78&gt;] kfree_skb+0x38/0xa0=
<br /> [   55=2E522661]  [&lt;ffffffff816044b0&gt;] ? ip_rcv+0x3a0/0x3a0<br=
 /> [   55=2E542811]  [&lt;ffffffff816044b0&gt;] ? ip_rcv+0x3a0/0x3a0<br />=
 [   55=2E562543]  [&lt;ffffffff815e6a6b&gt;] nf_hook_slow+0x10b/0x120<br /=
> [   55=2E582100]  [&lt;ffffffff816044b0&gt;] ? ip_rcv+0x3a0/0x3a0<br /> [=
   55=2E601470]  [&lt;ffffffff8170a02b&gt;] ? _raw_spin_unlock_irqrestore+0=
=07[   <br /> 55=2E620900] [&lt;ffffffff81604713&gt;] ip_local_deliver+0x73=
/0x80<br /> [   55=2E640154]  [&lt;ffffffff81603dc9&gt;] ip_rcv_finish+0x10=
9/0x310<br /> [   55=2E659244]  [&lt;ffffffff8160439c&gt;] ip_rcv+0x28c/0x3=
a0<br /> [   55=2E678287]  [&lt;ffffffff815b69ae&gt;] <br /> __netif_receiv=
e_skb_core+0x58e/0x=07[   55=2E697287] [&lt;ffffffff815b6b4d&gt;] <br /> __=
netif_receive_skb+0x1d/0x70<br /> [   55=2E715820]  [&lt;ffffffff815b6d9e&g=
t;] netif_receive_skb_internal+0x1e/0xb0<br /> [   55=2E734442]  [&lt;fffff=
fff815b6e47&gt;] netif_receive_skb+0x17/0x70<br /> [   55=2E752898]  [&lt;f=
fffffff816c17e2&gt;] br_handle_frame_finish+0x192/0x360<br /> [   55=2E7717=
09]  [&lt;ffffffff816c156d&gt;] br_handle_frame+0<br /> =07=07=07[   55=2E7=
90274]  [&lt;ffffffff816c13f0&gt;] ? br_handle_local_finish+0x40/0x40<br />=
 [   55=2E808760]  [&lt;ffffffff815b65f7&gt;] __netif_receive_skb_core+0x1d=
7/0x710<br /> [   55=2E827302]  [&lt;ffffffff815b6b4d&gt;] __netif_receive_=
skb+0x1d/0x70<br /> [   55=2E845594]  [&lt;ffffffff815b6d9e&gt;] netif_rece=
ive_skb_internal+0x1e/0xb0<br /> [   55=2E863836]  [&lt;ffffffff815b7a38&gt=
;] napi_gro_receive+0x118/0x1a0<br /> [   55=2E881549]  [&lt;ffffffff814c43=
0f&gt;] tg3_poll_work+0xe1f/0x1=07[   <br /> 55=2E898629]  [&lt;ffffffff814=
d75c9&gt;] tg3_poll+0x69/0x3c0<br /> [   55=2E915010]  [&lt;ffffffff815b752=
3&gt;] net_rx_action+0x103/0x290<br /> [   55=2E930840]  [&lt;ffffffff810a7=
713&gt;] __do_softirq+0xf3/0x2e0<br /> [   55=2E946310]  [&lt;ffffffff810a7=
a2d&gt;] irq_exit+0xcd/0xe0<br /> [   55=2E961399]  [&lt;ffffffff8140d4c7&g=
t;] xen_evtchn_do_upcall+0x37/0x50<br /> 766]  [&lt;ffffffff8170c1fe&gt;] x=
en_do_hypervisor_callback+0x1e/0x30<br /> =07=07=07[   55=2E990802]  &lt;EO=
I&gt;<br /> [   55=2E990977]  [&lt;ffffffff810013aa&gt;] ? xen_hypercall_sc=
hed_op+0xa/0x20<br /> [   56=2E018897]  [&lt;ffffffff810013aa&gt;] ? xen_hy=
percall_sched_op+0xa/0x20<br /> [   56=2E032815]  [&lt;ffffffff810454b0&gt;=
] ? xen_safe_halt+0x10/0x20<br /> [   56=2E046583]  [&lt;ffffffff81059e3a&g=
t;] ? default_idle+0x1a/0xd0<br /> [   56=2E060307]  [&lt;ffffffff8105950a&=
gt;] ? arch_cpu_idle+0xa/0x10<br /> [   56=2E073920]  [&lt;ffffffff810de483=
&gt;] ? cpu_startup_entry+0x2d3/0=07[   <br /> 56=2E100421]  [&lt;ffffffff8=
104c355&gt;] ? cpu_bringup_and_idle+0x25/0x40<br /> [   56=2E113427] Code: =
98 08 08 00 00 0f b7 47 08 48 03 1c c5 a0 42 cc 81 <br /> 48 89 df e8 94 fc=
 11 00 49 8b 44 24 18 48 85 c0 74 2d 49=07=07=07=07=07=07=07=07=07[   <br /=
> 56=2E141507] RIP  [&lt;ffffffff815ea29e&gt;] <br /> nf_ct_del_from_dying_=
or_unconfirmed_list+0x3e/0x70<br /> [   56=2E155425]  RSP &lt;ffff88003e283=
8f8&gt;<br /> [   56=2E169234] ---[ end trace 4c64578e4c629cc4 ]---<br /> [=
   56=2E182913] Kernel panic - not syncing: Fatal exception in interrupt<br=
 /> [   56=2E197026] Kernel Offset: 0x0 from 0xffffffff81000k  text console=
<br /> (XEN) [2014-11-23 06:05:48] Domain 0 crashed: rebooting machine in 5=
 <br /> seconds=2E<br /> (XEN) [2014-11-23 06:05:53] Resetting with ACPI ME=
MORY or I/O RESET_REG=2E<br /> <br /> <br /><hr /><br /> Xen-devel mailing =
list<br /> Xen-devel@lists=2Exen=2Eorg<br /> <a href=3D"http://lists=2Exen=
=2Eorg/xen-devel">http://lists=2Exen=2Eorg/xen-devel</a><br /></blockquote>=
<br /><br /></pre></blockquote></div><br>
<br>
<br>
-boris@phone</html>
------Y1S5AIESM1BU41DWPZE6JBF7W3PDPV--



--===============2990573173108248717==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2990573173108248717==--



From xen-devel-bounces@lists.xen.org Wed Nov 26 12:00:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 12:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtbGZ-0004bu-0o; Wed, 26 Nov 2014 12:00:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtbGX-0004be-CB
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 12:00:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E4/8B-15461-CC0C5745; Wed, 26 Nov 2014 12:00:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417003210!15470402!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5799 invoked from network); 26 Nov 2014 12:00: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;
	26 Nov 2014 12:00:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196981674"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 07:00:08 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtbGS-0006PL-7k;
	Wed, 26 Nov 2014 12:00:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtbGR-0001qx-Un;
	Wed, 26 Nov 2014 12:00:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21621.49351.620871.196969@mariner.uk.xensource.com>
Date: Wed, 26 Nov 2014 12:00:07 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1416482864-7824-1-git-send-email-olaf@aepfle.de>
References: <1416482864-7824-1-git-send-email-olaf@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan
	Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] xen: use more fixed strings to build 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

Olaf Hering writes ("[PATCH v2] xen: use more fixed strings to build the hypervisor"):
> It should be possible to repeatedly build identical sources and get
> identical binaries, even on different hosts at different build times.
> This fails for xen.gz and xen.efi because current time and buildhost
> get included in the binaries.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 12:00:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 12:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtbGZ-0004bu-0o; Wed, 26 Nov 2014 12:00:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtbGX-0004be-CB
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 12:00:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E4/8B-15461-CC0C5745; Wed, 26 Nov 2014 12:00:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417003210!15470402!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5799 invoked from network); 26 Nov 2014 12:00: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;
	26 Nov 2014 12:00:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196981674"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 07:00:08 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtbGS-0006PL-7k;
	Wed, 26 Nov 2014 12:00:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtbGR-0001qx-Un;
	Wed, 26 Nov 2014 12:00:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21621.49351.620871.196969@mariner.uk.xensource.com>
Date: Wed, 26 Nov 2014 12:00:07 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1416482864-7824-1-git-send-email-olaf@aepfle.de>
References: <1416482864-7824-1-git-send-email-olaf@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan
	Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] xen: use more fixed strings to build 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

Olaf Hering writes ("[PATCH v2] xen: use more fixed strings to build the hypervisor"):
> It should be possible to repeatedly build identical sources and get
> identical binaries, even on different hosts at different build times.
> This fails for xen.gz and xen.efi because current time and buildhost
> get included in the binaries.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 12:15:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 12:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtbVR-0005AF-Sx; Wed, 26 Nov 2014 12:15:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtbVQ-0005AA-AR
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 12:15:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5E/89-15461-764C5745; Wed, 26 Nov 2014 12:15:35 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417004134!15438680!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13622 invoked from network); 26 Nov 2014 12:15:35 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 12:15:35 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 886AEAC7D
	for <xen-devel@lists.xensource.com>;
	Wed, 26 Nov 2014 12:15:34 +0000 (UTC)
Message-ID: <5475C466.6010605@suse.com>
Date: Wed, 26 Nov 2014 13:15:34 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I tried to enable kdump on my test-machine with actual xen-unstable
booting via EFI.

The kdump kernel is not being loaded.

I'm seeing the memory being reserved:

(XEN) EFI RAM map:
(XEN)  0000000000000000 - 00000000000a0000 (usable)
(XEN)  0000000000100000 - 000000004bc00000 (usable)
(XEN)  000000004bc00000 - 000000005bc00000 (reserved)
(XEN)  000000005bc00000 - 000000005bfec000 (usable)
(XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
(XEN)  000000005c000000 - 000000006a429000 (usable)
(XEN)  000000006a429000 - 000000006a42c000 (reserved)
(XEN)  000000006a42c000 - 000000006a7a2000 (usable)
(XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
(XEN)  000000006a7a8000 - 000000006a987000 (usable)
(XEN)  000000006a987000 - 000000006a98d000 (reserved)
(XEN)  000000006a98d000 - 000000006aa63000 (usable)
(XEN)  000000006aa63000 - 000000006aa73000 (reserved)
(XEN)  000000006aa73000 - 000000006ac60000 (usable)
(XEN)  000000006ac60000 - 000000006ac61000 (reserved)
(XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
(XEN)  000000006ac9b000 - 000000006acac000 (reserved)
(XEN)  000000006acac000 - 000000006acad000 (usable)
(XEN)  000000006acad000 - 000000006acae000 (reserved)
(XEN)  000000006acae000 - 000000007189c000 (usable)
(XEN)  000000007189c000 - 0000000071946000 (reserved)
(XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
(XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
(XEN)  0000000072db2000 - 0000000072edc000 (usable)
(XEN)  0000000080000000 - 0000000090000000 (reserved)
(XEN)  0000000100000000 - 0000002080000000 (usable)
(XEN) Kdump: 256MB (262144kB) at 0x206dff4000

I'd expect this area being visible in the efi or e820 map presented to
dom0, but I can't see anything:

[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000004bbfffff] usable
[    0.000000] Xen: [mem 0x000000004bc00000-0x000000005bbfffff] reserved
[    0.000000] Xen: [mem 0x000000005bc00000-0x000000005bfebfff] usable
[    0.000000] Xen: [mem 0x000000005bfec000-0x000000005bffffff] ACPI NVS
[    0.000000] Xen: [mem 0x000000005c000000-0x000000006a428fff] usable
[    0.000000] Xen: [mem 0x000000006a429000-0x000000006a42bfff] reserved
[    0.000000] Xen: [mem 0x000000006a42c000-0x000000006a7a1fff] usable
[    0.000000] Xen: [mem 0x000000006a7a2000-0x000000006a7a7fff] reserved
[    0.000000] Xen: [mem 0x000000006a7a8000-0x000000006a986fff] usable
[    0.000000] Xen: [mem 0x000000006a987000-0x000000006a98cfff] reserved
[    0.000000] Xen: [mem 0x000000006a98d000-0x000000006aa62fff] usable
[    0.000000] Xen: [mem 0x000000006aa63000-0x000000006aa72fff] reserved
[    0.000000] Xen: [mem 0x000000006aa73000-0x000000006ac5ffff] usable
[    0.000000] Xen: [mem 0x000000006ac60000-0x000000006ac60fff] reserved
[    0.000000] Xen: [mem 0x000000006ac61000-0x000000006ac9afff] ACPI data
[    0.000000] Xen: [mem 0x000000006ac9b000-0x000000006acabfff] reserved
[    0.000000] Xen: [mem 0x000000006acac000-0x000000006acacfff] usable
[    0.000000] Xen: [mem 0x000000006acad000-0x000000006acadfff] reserved
[    0.000000] Xen: [mem 0x000000006acae000-0x000000007189bfff] usable
[    0.000000] Xen: [mem 0x000000007189c000-0x0000000071945fff] reserved
[    0.000000] Xen: [mem 0x0000000071946000-0x0000000072d75fff] ACPI NVS
[    0.000000] Xen: [mem 0x0000000072d76000-0x0000000072db1fff] ACPI data
[    0.000000] Xen: [mem 0x0000000072db2000-0x0000000072edbfff] usable
[    0.000000] Xen: [mem 0x0000000080000000-0x000000008fffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fecc0000-0x00000000fecc0fff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000207fffffff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] movable_node option not supported
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] e820: user-defined physical RAM map:
[    0.000000] user: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] user: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] user: [mem 0x0000000000100000-0x000000004bbfffff] usable
[    0.000000] user: [mem 0x000000004bc00000-0x000000005bbfffff] reserved
[    0.000000] user: [mem 0x000000005bc00000-0x000000005bfebfff] usable
[    0.000000] user: [mem 0x000000005bfec000-0x000000005bffffff] ACPI NVS
[    0.000000] user: [mem 0x000000005c000000-0x000000006a428fff] usable
[    0.000000] user: [mem 0x000000006a429000-0x000000006a42bfff] reserved
[    0.000000] user: [mem 0x000000006a42c000-0x000000006a7a1fff] usable
[    0.000000] user: [mem 0x000000006a7a2000-0x000000006a7a7fff] reserved
[    0.000000] user: [mem 0x000000006a7a8000-0x000000006a986fff] usable
[    0.000000] user: [mem 0x000000006a987000-0x000000006a98cfff] reserved
[    0.000000] user: [mem 0x000000006a98d000-0x000000006aa62fff] usable
[    0.000000] user: [mem 0x000000006aa63000-0x000000006aa72fff] reserved
[    0.000000] user: [mem 0x000000006aa73000-0x000000006ac5ffff] usable
[    0.000000] user: [mem 0x000000006ac60000-0x000000006ac60fff] reserved
[    0.000000] user: [mem 0x000000006ac61000-0x000000006ac9afff] ACPI data
[    0.000000] user: [mem 0x000000006ac9b000-0x000000006acabfff] reserved
[    0.000000] user: [mem 0x000000006acac000-0x000000006acacfff] usable
[    0.000000] user: [mem 0x000000006acad000-0x000000006acadfff] reserved
[    0.000000] user: [mem 0x000000006acae000-0x000000007189bfff] usable
[    0.000000] user: [mem 0x000000007189c000-0x0000000071945fff] reserved
[    0.000000] user: [mem 0x0000000071946000-0x0000000072d75fff] ACPI NVS
[    0.000000] user: [mem 0x0000000072d76000-0x0000000072db1fff] ACPI data
[    0.000000] user: [mem 0x0000000072db2000-0x0000000072edbfff] usable
[    0.000000] user: [mem 0x0000000080000000-0x000000008fffffff] reserved
[    0.000000] user: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] user: [mem 0x00000000fecc0000-0x00000000fecc0fff] reserved
[    0.000000] user: [mem 0x00000000fee00000-0x00000000feefffff] reserved
[    0.000000] user: [mem 0x0000000100000000-0x000000207fffffff] usable
[    0.000000] efi: EFI v2.31 by FUJITSU LIMITED


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 12:15:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 12:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtbVR-0005AF-Sx; Wed, 26 Nov 2014 12:15:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtbVQ-0005AA-AR
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 12:15:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5E/89-15461-764C5745; Wed, 26 Nov 2014 12:15:35 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417004134!15438680!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13622 invoked from network); 26 Nov 2014 12:15:35 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 12:15:35 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 886AEAC7D
	for <xen-devel@lists.xensource.com>;
	Wed, 26 Nov 2014 12:15:34 +0000 (UTC)
Message-ID: <5475C466.6010605@suse.com>
Date: Wed, 26 Nov 2014 13:15:34 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I tried to enable kdump on my test-machine with actual xen-unstable
booting via EFI.

The kdump kernel is not being loaded.

I'm seeing the memory being reserved:

(XEN) EFI RAM map:
(XEN)  0000000000000000 - 00000000000a0000 (usable)
(XEN)  0000000000100000 - 000000004bc00000 (usable)
(XEN)  000000004bc00000 - 000000005bc00000 (reserved)
(XEN)  000000005bc00000 - 000000005bfec000 (usable)
(XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
(XEN)  000000005c000000 - 000000006a429000 (usable)
(XEN)  000000006a429000 - 000000006a42c000 (reserved)
(XEN)  000000006a42c000 - 000000006a7a2000 (usable)
(XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
(XEN)  000000006a7a8000 - 000000006a987000 (usable)
(XEN)  000000006a987000 - 000000006a98d000 (reserved)
(XEN)  000000006a98d000 - 000000006aa63000 (usable)
(XEN)  000000006aa63000 - 000000006aa73000 (reserved)
(XEN)  000000006aa73000 - 000000006ac60000 (usable)
(XEN)  000000006ac60000 - 000000006ac61000 (reserved)
(XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
(XEN)  000000006ac9b000 - 000000006acac000 (reserved)
(XEN)  000000006acac000 - 000000006acad000 (usable)
(XEN)  000000006acad000 - 000000006acae000 (reserved)
(XEN)  000000006acae000 - 000000007189c000 (usable)
(XEN)  000000007189c000 - 0000000071946000 (reserved)
(XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
(XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
(XEN)  0000000072db2000 - 0000000072edc000 (usable)
(XEN)  0000000080000000 - 0000000090000000 (reserved)
(XEN)  0000000100000000 - 0000002080000000 (usable)
(XEN) Kdump: 256MB (262144kB) at 0x206dff4000

I'd expect this area being visible in the efi or e820 map presented to
dom0, but I can't see anything:

[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000004bbfffff] usable
[    0.000000] Xen: [mem 0x000000004bc00000-0x000000005bbfffff] reserved
[    0.000000] Xen: [mem 0x000000005bc00000-0x000000005bfebfff] usable
[    0.000000] Xen: [mem 0x000000005bfec000-0x000000005bffffff] ACPI NVS
[    0.000000] Xen: [mem 0x000000005c000000-0x000000006a428fff] usable
[    0.000000] Xen: [mem 0x000000006a429000-0x000000006a42bfff] reserved
[    0.000000] Xen: [mem 0x000000006a42c000-0x000000006a7a1fff] usable
[    0.000000] Xen: [mem 0x000000006a7a2000-0x000000006a7a7fff] reserved
[    0.000000] Xen: [mem 0x000000006a7a8000-0x000000006a986fff] usable
[    0.000000] Xen: [mem 0x000000006a987000-0x000000006a98cfff] reserved
[    0.000000] Xen: [mem 0x000000006a98d000-0x000000006aa62fff] usable
[    0.000000] Xen: [mem 0x000000006aa63000-0x000000006aa72fff] reserved
[    0.000000] Xen: [mem 0x000000006aa73000-0x000000006ac5ffff] usable
[    0.000000] Xen: [mem 0x000000006ac60000-0x000000006ac60fff] reserved
[    0.000000] Xen: [mem 0x000000006ac61000-0x000000006ac9afff] ACPI data
[    0.000000] Xen: [mem 0x000000006ac9b000-0x000000006acabfff] reserved
[    0.000000] Xen: [mem 0x000000006acac000-0x000000006acacfff] usable
[    0.000000] Xen: [mem 0x000000006acad000-0x000000006acadfff] reserved
[    0.000000] Xen: [mem 0x000000006acae000-0x000000007189bfff] usable
[    0.000000] Xen: [mem 0x000000007189c000-0x0000000071945fff] reserved
[    0.000000] Xen: [mem 0x0000000071946000-0x0000000072d75fff] ACPI NVS
[    0.000000] Xen: [mem 0x0000000072d76000-0x0000000072db1fff] ACPI data
[    0.000000] Xen: [mem 0x0000000072db2000-0x0000000072edbfff] usable
[    0.000000] Xen: [mem 0x0000000080000000-0x000000008fffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fecc0000-0x00000000fecc0fff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000207fffffff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] movable_node option not supported
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] e820: user-defined physical RAM map:
[    0.000000] user: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] user: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] user: [mem 0x0000000000100000-0x000000004bbfffff] usable
[    0.000000] user: [mem 0x000000004bc00000-0x000000005bbfffff] reserved
[    0.000000] user: [mem 0x000000005bc00000-0x000000005bfebfff] usable
[    0.000000] user: [mem 0x000000005bfec000-0x000000005bffffff] ACPI NVS
[    0.000000] user: [mem 0x000000005c000000-0x000000006a428fff] usable
[    0.000000] user: [mem 0x000000006a429000-0x000000006a42bfff] reserved
[    0.000000] user: [mem 0x000000006a42c000-0x000000006a7a1fff] usable
[    0.000000] user: [mem 0x000000006a7a2000-0x000000006a7a7fff] reserved
[    0.000000] user: [mem 0x000000006a7a8000-0x000000006a986fff] usable
[    0.000000] user: [mem 0x000000006a987000-0x000000006a98cfff] reserved
[    0.000000] user: [mem 0x000000006a98d000-0x000000006aa62fff] usable
[    0.000000] user: [mem 0x000000006aa63000-0x000000006aa72fff] reserved
[    0.000000] user: [mem 0x000000006aa73000-0x000000006ac5ffff] usable
[    0.000000] user: [mem 0x000000006ac60000-0x000000006ac60fff] reserved
[    0.000000] user: [mem 0x000000006ac61000-0x000000006ac9afff] ACPI data
[    0.000000] user: [mem 0x000000006ac9b000-0x000000006acabfff] reserved
[    0.000000] user: [mem 0x000000006acac000-0x000000006acacfff] usable
[    0.000000] user: [mem 0x000000006acad000-0x000000006acadfff] reserved
[    0.000000] user: [mem 0x000000006acae000-0x000000007189bfff] usable
[    0.000000] user: [mem 0x000000007189c000-0x0000000071945fff] reserved
[    0.000000] user: [mem 0x0000000071946000-0x0000000072d75fff] ACPI NVS
[    0.000000] user: [mem 0x0000000072d76000-0x0000000072db1fff] ACPI data
[    0.000000] user: [mem 0x0000000072db2000-0x0000000072edbfff] usable
[    0.000000] user: [mem 0x0000000080000000-0x000000008fffffff] reserved
[    0.000000] user: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] user: [mem 0x00000000fecc0000-0x00000000fecc0fff] reserved
[    0.000000] user: [mem 0x00000000fee00000-0x00000000feefffff] reserved
[    0.000000] user: [mem 0x0000000100000000-0x000000207fffffff] usable
[    0.000000] efi: EFI v2.31 by FUJITSU LIMITED


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 12:42:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 12: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 1Xtbup-0005Vt-3w; Wed, 26 Nov 2014 12:41:51 +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 1Xtbum-0005VN-U2
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 12:41:49 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	D8/F2-14727-C8AC5745; Wed, 26 Nov 2014 12:41:48 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417005706!13415502!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29528 invoked from network); 26 Nov 2014 12:41:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 12:41:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196991299"
Message-ID: <5475CA7A.7050200@citrix.com>
Date: Wed, 26 Nov 2014 12:41:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <5475C466.6010605@suse.com>
In-Reply-To: <5475C466.6010605@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/11/14 12:15, Juergen Gross wrote:
> Hi,
>
> I tried to enable kdump on my test-machine with actual xen-unstable
> booting via EFI.
>
> The kdump kernel is not being loaded.
>
> I'm seeing the memory being reserved:
>
> (XEN) EFI RAM map:
> (XEN)  0000000000000000 - 00000000000a0000 (usable)
> (XEN)  0000000000100000 - 000000004bc00000 (usable)
> (XEN)  000000004bc00000 - 000000005bc00000 (reserved)
> (XEN)  000000005bc00000 - 000000005bfec000 (usable)
> (XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
> (XEN)  000000005c000000 - 000000006a429000 (usable)
> (XEN)  000000006a429000 - 000000006a42c000 (reserved)
> (XEN)  000000006a42c000 - 000000006a7a2000 (usable)
> (XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
> (XEN)  000000006a7a8000 - 000000006a987000 (usable)
> (XEN)  000000006a987000 - 000000006a98d000 (reserved)
> (XEN)  000000006a98d000 - 000000006aa63000 (usable)
> (XEN)  000000006aa63000 - 000000006aa73000 (reserved)
> (XEN)  000000006aa73000 - 000000006ac60000 (usable)
> (XEN)  000000006ac60000 - 000000006ac61000 (reserved)
> (XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
> (XEN)  000000006ac9b000 - 000000006acac000 (reserved)
> (XEN)  000000006acac000 - 000000006acad000 (usable)
> (XEN)  000000006acad000 - 000000006acae000 (reserved)
> (XEN)  000000006acae000 - 000000007189c000 (usable)
> (XEN)  000000007189c000 - 0000000071946000 (reserved)
> (XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
> (XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
> (XEN)  0000000072db2000 - 0000000072edc000 (usable)
> (XEN)  0000000080000000 - 0000000090000000 (reserved)
> (XEN)  0000000100000000 - 0000002080000000 (usable)
> (XEN) Kdump: 256MB (262144kB) at 0x206dff4000
>
> I'd expect this area being visible in the efi or e820 map presented to
> dom0, but I can't see anything:

This is expected.  The dom0 kernel now has nothing at all do with
loading crash kernel.  Loading happens via hypercalls straight from the
kexec utility.

You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
support, but it should JustWork.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 12:42:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 12: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 1Xtbup-0005Vt-3w; Wed, 26 Nov 2014 12:41:51 +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 1Xtbum-0005VN-U2
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 12:41:49 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	D8/F2-14727-C8AC5745; Wed, 26 Nov 2014 12:41:48 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417005706!13415502!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29528 invoked from network); 26 Nov 2014 12:41:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 12:41:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196991299"
Message-ID: <5475CA7A.7050200@citrix.com>
Date: Wed, 26 Nov 2014 12:41:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <5475C466.6010605@suse.com>
In-Reply-To: <5475C466.6010605@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/11/14 12:15, Juergen Gross wrote:
> Hi,
>
> I tried to enable kdump on my test-machine with actual xen-unstable
> booting via EFI.
>
> The kdump kernel is not being loaded.
>
> I'm seeing the memory being reserved:
>
> (XEN) EFI RAM map:
> (XEN)  0000000000000000 - 00000000000a0000 (usable)
> (XEN)  0000000000100000 - 000000004bc00000 (usable)
> (XEN)  000000004bc00000 - 000000005bc00000 (reserved)
> (XEN)  000000005bc00000 - 000000005bfec000 (usable)
> (XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
> (XEN)  000000005c000000 - 000000006a429000 (usable)
> (XEN)  000000006a429000 - 000000006a42c000 (reserved)
> (XEN)  000000006a42c000 - 000000006a7a2000 (usable)
> (XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
> (XEN)  000000006a7a8000 - 000000006a987000 (usable)
> (XEN)  000000006a987000 - 000000006a98d000 (reserved)
> (XEN)  000000006a98d000 - 000000006aa63000 (usable)
> (XEN)  000000006aa63000 - 000000006aa73000 (reserved)
> (XEN)  000000006aa73000 - 000000006ac60000 (usable)
> (XEN)  000000006ac60000 - 000000006ac61000 (reserved)
> (XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
> (XEN)  000000006ac9b000 - 000000006acac000 (reserved)
> (XEN)  000000006acac000 - 000000006acad000 (usable)
> (XEN)  000000006acad000 - 000000006acae000 (reserved)
> (XEN)  000000006acae000 - 000000007189c000 (usable)
> (XEN)  000000007189c000 - 0000000071946000 (reserved)
> (XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
> (XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
> (XEN)  0000000072db2000 - 0000000072edc000 (usable)
> (XEN)  0000000080000000 - 0000000090000000 (reserved)
> (XEN)  0000000100000000 - 0000002080000000 (usable)
> (XEN) Kdump: 256MB (262144kB) at 0x206dff4000
>
> I'd expect this area being visible in the efi or e820 map presented to
> dom0, but I can't see anything:

This is expected.  The dom0 kernel now has nothing at all do with
loading crash kernel.  Loading happens via hypercalls straight from the
kexec utility.

You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
support, but it should JustWork.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 12:52:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 12:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtc4h-0005n2-78; Wed, 26 Nov 2014 12:52:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xtc4g-0005mx-7s
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 12:52:02 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	C8/0D-19763-1FCC5745; Wed, 26 Nov 2014 12:52:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417006319!13404517!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20474 invoked from network); 26 Nov 2014 12:52:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 12:52:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196994054"
Message-ID: <1417006301.11944.47.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 26 Nov 2014 12:51:41 +0000
In-Reply-To: <20141125111522.GD28315@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
	<20141125103940.GC28315@zion.uk.xensource.com>
	<20141125111522.GD28315@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, Jim
	Fehlig <jfehlig@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 11:15 +0000, Wei Liu wrote:
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> since the destination bitmap is created for maximum number of CPUs.

FYI I'm also seeing this with libvirt (on ARM, but I don't think that
matters) when the guest XML uses:
        <vcpu placement='static' cpuset='0-7'>1</vcpu>
Results in:
        libvirtd: libxl_utils.c:612: libxl_bitmap_copy: Assertion `dptr->size == sptr->size' failed.
        
        Program received signal SIGABRT, Aborted.
        [Switching to Thread 0xb67f9420 (LWP 3881)]
        0xb6ab7f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        (gdb) bt
        #0  0xb6ab7f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        #1  0xb6ac5f8a in raise () from /lib/arm-linux-gnueabihf/libc.so.6
        #2  0xb6ac8428 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
        #3  0xb6ac101e in __assert_fail () from /lib/arm-linux-gnueabihf/libc.so.6
        #4  0xb16caeb4 in libxl_bitmap_copy (ctx=<optimized out>, dptr=<optimized out>, sptr=<optimized out>) at libxl_utils.c:612
        #5  0xb16af15c in libxl_set_vcpuaffinity (ctx=0x2, domid=3065494508, vcpuid=0, cpumap_hard=0xb67f8668, cpumap_soft=0x0) at libxl.c:5323
        #6  0xb17195ae in libxlDomainSetVcpuAffinities () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #7  0xb1719cf2 in libxlDomainStart () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #8  0xb171b7c2 in libxlDomainCreateXML () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #9  0xb6d28630 in virDomainCreateXML () from /opt/libvirt/lib/libvirt.so.0
        [...snip...]
        
libxlDomainSetVcpuAffinities does:
    libxl_bitmap map;
    [...]

        map.size = cpumaplen;
        map.map = cpumap;

        if (libxl_set_vcpuaffinity(priv->ctx, def->id, vcpu, &map) != 0) {

http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/libxl/libxl_domain.c;h=9c622910547ada174a3d787c76c8bb076c9a75c3;hb=HEAD#l1059

Applying this libxl patch fixes things.

I don't think we've explicitly outlawed looking "inside" a libxl_bitmap
in this way anywhere, so I think libvirtd is within its rights to do so,
but it does highlight that we need to be mindful within libxl that
people may not be using libxl_cpu_bitmap_alloc.

> 
> We could allocate that bitmap of the same size as the source, however, it is
> later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
> number of CPUs
> 
> To fix this issue, introduce an internal function to allowing copying between
> bitmaps of different sizes. Note that this function is only used in
> libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
> libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
> placement logic comes into effect when no vcpu / node pinning is provided, so
> it always operates on bitmap of the same sizes (that is, size of maximum
> number of cpus /nodes).
> 
> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Dario Faggioli <dario.faggioli@citrix.com>
> ---
> This fixes a regression for 4.5. Can't think of obvious risk.
> ---
>  tools/libxl/libxl.c          |    4 ++--
>  tools/libxl/libxl_internal.h |   11 +++++++++++
>  tools/libxl/libxl_utils.c    |   15 +++++++++++++++
>  3 files changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..1e9da10 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5320,7 +5320,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>          if (rc)
>              goto out;
>  
> -        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
> +        libxl__bitmap_copy_best_effort(gc, &hard, cpumap_hard);
>          flags = XEN_VCPUAFFINITY_HARD;
>      }
>      if (cpumap_soft) {
> @@ -5328,7 +5328,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>          if (rc)
>              goto out;
>  
> -        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
> +        libxl__bitmap_copy_best_effort(gc, &soft, cpumap_soft);
>          flags |= XEN_VCPUAFFINITY_SOFT;
>      }
>  
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4361421..a38f695 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -3617,6 +3617,17 @@ static inline void libxl__update_config_vtpm(libxl__gc *gc,
>          libxl_device_##type##_copy(CTX, DA_p, (dev));           \
>      })
>  
> +/* This function copies X bytes from source to destination bitmap,
> + * where X is the smaller of the two sizes.
> + *
> + * If destination's size is larger than source, the extra bytes are
> + * untouched.
> + *
> + * XXX This is introduced to fix a regression for 4.5. It shall
> + * be revisited in 4.6 time frame.
> + */
> +void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
> +                                    const libxl_bitmap *sptr);
>  #endif
>  
>  /*
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 58df4f3..3e1ba17 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -614,6 +614,21 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>      memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>  }
>  
> +/* This function copies X bytes from source to destination bitmap,
> + * where X is the smaller of the two sizes.
> + *
> + * If destination's size is larger than source, the extra bytes are
> + * untouched.
> + */
> +void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
> +                                    const libxl_bitmap *sptr)
> +{
> +    int sz;
> +
> +    sz = dptr->size < sptr->size ? dptr->size : sptr->size;
> +    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
> +}
> +
>  void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
>                               libxl_bitmap *dptr,
>                               const libxl_bitmap *sptr)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 12:52:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 12:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtc4h-0005n2-78; Wed, 26 Nov 2014 12:52:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xtc4g-0005mx-7s
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 12:52:02 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	C8/0D-19763-1FCC5745; Wed, 26 Nov 2014 12:52:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417006319!13404517!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20474 invoked from network); 26 Nov 2014 12:52:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 12:52:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196994054"
Message-ID: <1417006301.11944.47.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 26 Nov 2014 12:51:41 +0000
In-Reply-To: <20141125111522.GD28315@zion.uk.xensource.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
	<20141125103940.GC28315@zion.uk.xensource.com>
	<20141125111522.GD28315@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, Jim
	Fehlig <jfehlig@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 11:15 +0000, Wei Liu wrote:
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> since the destination bitmap is created for maximum number of CPUs.

FYI I'm also seeing this with libvirt (on ARM, but I don't think that
matters) when the guest XML uses:
        <vcpu placement='static' cpuset='0-7'>1</vcpu>
Results in:
        libvirtd: libxl_utils.c:612: libxl_bitmap_copy: Assertion `dptr->size == sptr->size' failed.
        
        Program received signal SIGABRT, Aborted.
        [Switching to Thread 0xb67f9420 (LWP 3881)]
        0xb6ab7f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        (gdb) bt
        #0  0xb6ab7f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        #1  0xb6ac5f8a in raise () from /lib/arm-linux-gnueabihf/libc.so.6
        #2  0xb6ac8428 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
        #3  0xb6ac101e in __assert_fail () from /lib/arm-linux-gnueabihf/libc.so.6
        #4  0xb16caeb4 in libxl_bitmap_copy (ctx=<optimized out>, dptr=<optimized out>, sptr=<optimized out>) at libxl_utils.c:612
        #5  0xb16af15c in libxl_set_vcpuaffinity (ctx=0x2, domid=3065494508, vcpuid=0, cpumap_hard=0xb67f8668, cpumap_soft=0x0) at libxl.c:5323
        #6  0xb17195ae in libxlDomainSetVcpuAffinities () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #7  0xb1719cf2 in libxlDomainStart () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #8  0xb171b7c2 in libxlDomainCreateXML () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #9  0xb6d28630 in virDomainCreateXML () from /opt/libvirt/lib/libvirt.so.0
        [...snip...]
        
libxlDomainSetVcpuAffinities does:
    libxl_bitmap map;
    [...]

        map.size = cpumaplen;
        map.map = cpumap;

        if (libxl_set_vcpuaffinity(priv->ctx, def->id, vcpu, &map) != 0) {

http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/libxl/libxl_domain.c;h=9c622910547ada174a3d787c76c8bb076c9a75c3;hb=HEAD#l1059

Applying this libxl patch fixes things.

I don't think we've explicitly outlawed looking "inside" a libxl_bitmap
in this way anywhere, so I think libvirtd is within its rights to do so,
but it does highlight that we need to be mindful within libxl that
people may not be using libxl_cpu_bitmap_alloc.

> 
> We could allocate that bitmap of the same size as the source, however, it is
> later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
> number of CPUs
> 
> To fix this issue, introduce an internal function to allowing copying between
> bitmaps of different sizes. Note that this function is only used in
> libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
> libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
> placement logic comes into effect when no vcpu / node pinning is provided, so
> it always operates on bitmap of the same sizes (that is, size of maximum
> number of cpus /nodes).
> 
> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Dario Faggioli <dario.faggioli@citrix.com>
> ---
> This fixes a regression for 4.5. Can't think of obvious risk.
> ---
>  tools/libxl/libxl.c          |    4 ++--
>  tools/libxl/libxl_internal.h |   11 +++++++++++
>  tools/libxl/libxl_utils.c    |   15 +++++++++++++++
>  3 files changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..1e9da10 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5320,7 +5320,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>          if (rc)
>              goto out;
>  
> -        libxl_bitmap_copy(ctx, &hard, cpumap_hard);
> +        libxl__bitmap_copy_best_effort(gc, &hard, cpumap_hard);
>          flags = XEN_VCPUAFFINITY_HARD;
>      }
>      if (cpumap_soft) {
> @@ -5328,7 +5328,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>          if (rc)
>              goto out;
>  
> -        libxl_bitmap_copy(ctx, &soft, cpumap_soft);
> +        libxl__bitmap_copy_best_effort(gc, &soft, cpumap_soft);
>          flags |= XEN_VCPUAFFINITY_SOFT;
>      }
>  
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4361421..a38f695 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -3617,6 +3617,17 @@ static inline void libxl__update_config_vtpm(libxl__gc *gc,
>          libxl_device_##type##_copy(CTX, DA_p, (dev));           \
>      })
>  
> +/* This function copies X bytes from source to destination bitmap,
> + * where X is the smaller of the two sizes.
> + *
> + * If destination's size is larger than source, the extra bytes are
> + * untouched.
> + *
> + * XXX This is introduced to fix a regression for 4.5. It shall
> + * be revisited in 4.6 time frame.
> + */
> +void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
> +                                    const libxl_bitmap *sptr);
>  #endif
>  
>  /*
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 58df4f3..3e1ba17 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -614,6 +614,21 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
>      memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>  }
>  
> +/* This function copies X bytes from source to destination bitmap,
> + * where X is the smaller of the two sizes.
> + *
> + * If destination's size is larger than source, the extra bytes are
> + * untouched.
> + */
> +void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
> +                                    const libxl_bitmap *sptr)
> +{
> +    int sz;
> +
> +    sz = dptr->size < sptr->size ? dptr->size : sptr->size;
> +    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
> +}
> +
>  void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
>                               libxl_bitmap *dptr,
>                               const libxl_bitmap *sptr)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 12:52:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 12:52:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtc5E-0005p8-KG; Wed, 26 Nov 2014 12:52:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xtc5C-0005ow-VT
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 12:52:35 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	C5/69-02699-21DC5745; Wed, 26 Nov 2014 12:52:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417006352!14964395!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13782 invoked from network); 26 Nov 2014 12:52:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 12:52:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196745960"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 07:52:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xtbsz-0007SS-DQ;
	Wed, 26 Nov 2014 12:39:57 +0000
Date: Wed, 26 Nov 2014 12:39:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416994330.11944.25.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411261239160.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com> 
	<alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
	<1416994330.11944.25.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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, 26 Nov 2014, Ian Campbell wrote:
> On Tue, 2014-11-25 at 17:05 +0000, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > > > each them. Assume 256K each.
> > > > > 
> > > > > I suppose this will have to do for 4.5. Can we do something better in
> > > > > the future -- like figuring out a way for guests to have
> > > > > "not-really-RAM" allocations like this which are made by the toolstack
> > > > > and happen to be backed by RAM not count or something.
> > > > > 
> > > > > > 
> > > > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > > > assigned to a VM.
> > > > > 
> > > > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > > > option roms? abort() seems a bit extreme.
> > > > > 
> > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > CC: Don Slutz <dslutz@verizon.com>
> > > > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > > > 
> > > > > You missed Ian J. I've added him.
> > > > 
> > > > Actually Wei suggested a better alternative: I could call
> > > > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> > > 
> > > xl mem-set would do it again, but not taking qemu's extras into account,
> > > unless you communicate the overhead somehow...
> > 
> > We could start reading the current maxmem and add to it in
> > libxl_set_memory_target. Or we could write the maxmem to xenstore and
> > read it back again.  Given that the allocations are only done by QEMU at
> > initialization time, I don't think we need to worry about concurrency
> > here.
> 
> Might work, but it's a bit scary for 4.5, I would expect there to be
> subtle knock on effects from this sort of thing :-/
 
Given that this is not a regression, we could wait for 4.6 to commit the
fix and then if it doesn't cause any unwanted side effects, we could
backport it?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 12:52:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 12:52:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtc5E-0005p8-KG; Wed, 26 Nov 2014 12:52:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xtc5C-0005ow-VT
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 12:52:35 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	C5/69-02699-21DC5745; Wed, 26 Nov 2014 12:52:34 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417006352!14964395!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13782 invoked from network); 26 Nov 2014 12:52:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 12:52:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196745960"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 07:52:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xtbsz-0007SS-DQ;
	Wed, 26 Nov 2014 12:39:57 +0000
Date: Wed, 26 Nov 2014 12:39:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1416994330.11944.25.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411261239160.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com> 
	<alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
	<1416994330.11944.25.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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, 26 Nov 2014, Ian Campbell wrote:
> On Tue, 2014-11-25 at 17:05 +0000, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > > > each them. Assume 256K each.
> > > > > 
> > > > > I suppose this will have to do for 4.5. Can we do something better in
> > > > > the future -- like figuring out a way for guests to have
> > > > > "not-really-RAM" allocations like this which are made by the toolstack
> > > > > and happen to be backed by RAM not count or something.
> > > > > 
> > > > > > 
> > > > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > > > assigned to a VM.
> > > > > 
> > > > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > > > option roms? abort() seems a bit extreme.
> > > > > 
> > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > CC: Don Slutz <dslutz@verizon.com>
> > > > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > > > 
> > > > > You missed Ian J. I've added him.
> > > > 
> > > > Actually Wei suggested a better alternative: I could call
> > > > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> > > 
> > > xl mem-set would do it again, but not taking qemu's extras into account,
> > > unless you communicate the overhead somehow...
> > 
> > We could start reading the current maxmem and add to it in
> > libxl_set_memory_target. Or we could write the maxmem to xenstore and
> > read it back again.  Given that the allocations are only done by QEMU at
> > initialization time, I don't think we need to worry about concurrency
> > here.
> 
> Might work, but it's a bit scary for 4.5, I would expect there to be
> subtle knock on effects from this sort of thing :-/
 
Given that this is not a regression, we could wait for 4.6 to commit the
fix and then if it doesn't cause any unwanted side effects, we could
backport it?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 13:04:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 13: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.xen.org>)
	id 1XtcGp-0006Bs-S4; Wed, 26 Nov 2014 13:04: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 1XtcGo-0006Bn-3p
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 13:04:34 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	56/09-24124-1EFC5745; Wed, 26 Nov 2014 13:04:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417007071!13408148!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28648 invoked from network); 26 Nov 2014 13:04:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 13:04:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196749591"
Message-ID: <1417007040.11944.50.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 26 Nov 2014 13:04:00 +0000
In-Reply-To: <alpine.DEB.2.02.1411261239160.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
	<alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
	<1416994330.11944.25.camel@citrix.com>
	<alpine.DEB.2.02.1411261239160.14135@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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, 2014-11-26 at 12:39 +0000, Stefano Stabellini wrote:
> On Wed, 26 Nov 2014, Ian Campbell wrote:
> > On Tue, 2014-11-25 at 17:05 +0000, Stefano Stabellini wrote:
> > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > > > > each them. Assume 256K each.
> > > > > > 
> > > > > > I suppose this will have to do for 4.5. Can we do something better in
> > > > > > the future -- like figuring out a way for guests to have
> > > > > > "not-really-RAM" allocations like this which are made by the toolstack
> > > > > > and happen to be backed by RAM not count or something.
> > > > > > 
> > > > > > > 
> > > > > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > > > > assigned to a VM.
> > > > > > 
> > > > > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > > > > option roms? abort() seems a bit extreme.
> > > > > > 
> > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > > CC: Don Slutz <dslutz@verizon.com>
> > > > > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > > > > 
> > > > > > You missed Ian J. I've added him.
> > > > > 
> > > > > Actually Wei suggested a better alternative: I could call
> > > > > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> > > > 
> > > > xl mem-set would do it again, but not taking qemu's extras into account,
> > > > unless you communicate the overhead somehow...
> > > 
> > > We could start reading the current maxmem and add to it in
> > > libxl_set_memory_target. Or we could write the maxmem to xenstore and
> > > read it back again.  Given that the allocations are only done by QEMU at
> > > initialization time, I don't think we need to worry about concurrency
> > > here.
> > 
> > Might work, but it's a bit scary for 4.5, I would expect there to be
> > subtle knock on effects from this sort of thing :-/
>  
> Given that this is not a regression, we could wait for 4.6 to commit the
> fix and then if it doesn't cause any unwanted side effects, we could
> backport it?

That's not a bad plan. Release noting "you can't create more than 4
emulated NICs" doesn't seem so bad to me.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 13:04:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 13: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.xen.org>)
	id 1XtcGp-0006Bs-S4; Wed, 26 Nov 2014 13:04: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 1XtcGo-0006Bn-3p
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 13:04:34 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	56/09-24124-1EFC5745; Wed, 26 Nov 2014 13:04:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417007071!13408148!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28648 invoked from network); 26 Nov 2014 13:04:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 13:04:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196749591"
Message-ID: <1417007040.11944.50.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 26 Nov 2014 13:04:00 +0000
In-Reply-To: <alpine.DEB.2.02.1411261239160.14135@kaball.uk.xensource.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
	<alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
	<1416994330.11944.25.camel@citrix.com>
	<alpine.DEB.2.02.1411261239160.14135@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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, 2014-11-26 at 12:39 +0000, Stefano Stabellini wrote:
> On Wed, 26 Nov 2014, Ian Campbell wrote:
> > On Tue, 2014-11-25 at 17:05 +0000, Stefano Stabellini wrote:
> > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > > > > each them. Assume 256K each.
> > > > > > 
> > > > > > I suppose this will have to do for 4.5. Can we do something better in
> > > > > > the future -- like figuring out a way for guests to have
> > > > > > "not-really-RAM" allocations like this which are made by the toolstack
> > > > > > and happen to be backed by RAM not count or something.
> > > > > > 
> > > > > > > 
> > > > > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > > > > assigned to a VM.
> > > > > > 
> > > > > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > > > > option roms? abort() seems a bit extreme.
> > > > > > 
> > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > > CC: Don Slutz <dslutz@verizon.com>
> > > > > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > > > > 
> > > > > > You missed Ian J. I've added him.
> > > > > 
> > > > > Actually Wei suggested a better alternative: I could call
> > > > > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> > > > 
> > > > xl mem-set would do it again, but not taking qemu's extras into account,
> > > > unless you communicate the overhead somehow...
> > > 
> > > We could start reading the current maxmem and add to it in
> > > libxl_set_memory_target. Or we could write the maxmem to xenstore and
> > > read it back again.  Given that the allocations are only done by QEMU at
> > > initialization time, I don't think we need to worry about concurrency
> > > here.
> > 
> > Might work, but it's a bit scary for 4.5, I would expect there to be
> > subtle knock on effects from this sort of thing :-/
>  
> Given that this is not a regression, we could wait for 4.6 to commit the
> fix and then if it doesn't cause any unwanted side effects, we could
> backport it?

That's not a bad plan. Release noting "you can't create more than 4
emulated NICs" doesn't seem so bad to me.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 13:18:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 13:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtcTs-0006Ru-BQ; Wed, 26 Nov 2014 13:18:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtcTr-0006Rp-OA
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 13:18:03 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	87/39-27623-A03D5745; Wed, 26 Nov 2014 13:18:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417007879!9570266!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21949 invoked from network); 26 Nov 2014 13:18:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 13:18:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197003745"
Message-ID: <5475D302.3010409@citrix.com>
Date: Wed, 26 Nov 2014 13:17:54 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <5474DE5A.2060000@citrix.com> <20141126080912.GA944@aepfle.de>
In-Reply-To: <20141126080912.GA944@aepfle.de>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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 26/11/14 08:09, Olaf Hering wrote:
> On Tue, Nov 25, Andrew Cooper wrote:
>
>> The purpose of this email is to plan how to progress the migrationv2
>> series through to being merged.  I believe I have CC'd everyone with a
>> specific interest in this area, but apologies if I have missed anyone.
> While you mow that lawn,

Lawns cease to be called lawns when they get this gnarly.  Paddock
perhaps? :)

> did you guys think of handling downtime of the
> migrated VM?

This again is in contradiction to the primary purpose of "Make something
which is no less functional than legacy migration".  Having said that,
migration downtime is an area will be looking into in XenServer,
although at the moment the bottlenecks are elsewhere in the system.

> I added some knobs to abort migration in a very libxc
> specific way. What I would like to see is a simple user interface for
> virsh/xl to control the downtime. See the thread "limit downtime during
> life migration from xl/virsh":
>
> http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html

The v2 code is substantially more efficient than the legacy code.  It
makes fewer hypercalls, it doesn't attempt to map frames its not
planning to send, or frames which it knows doesn't exist, it makes an
order of magnitude fewer syscalls as part of actually moving data.  Side
by side in otherwise identical situations, v2 is noticeably faster than
legacy.  A gut feel on small VMs during dev testing would be between 1/4
and 1/3rd faster, but we also have various measurements at a higher
level which show an improvement all round.  In particular, total time to
suspend a 128GB HVM guest is down by 60% when the *only* different in
the system is the algorithm used in libxenguest.

Also, the current knobs in migration v2 are different.  Legacy has max
iterations and max factor as knobs, (where max factor is frankly a
ludicrous parameter in my opinion), and replaced with a dirty threshold
in v2.  v2 currently has these values hard coded to 5 iterations and 50
(or fewer) dirty frames before pause.  This has proved to be better

It is certainly my hope going forward that different knobs can be
exposed.  One thing I think would be interesting is some proper
calculations of the delta in the dirty set, and offering a threshold
which chooses between "pause and complete" or "abort the migration and
complain that the VM is too active"

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 13:18:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 13:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtcTs-0006Ru-BQ; Wed, 26 Nov 2014 13:18:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtcTr-0006Rp-OA
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 13:18:03 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	87/39-27623-A03D5745; Wed, 26 Nov 2014 13:18:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417007879!9570266!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21949 invoked from network); 26 Nov 2014 13:18:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 13:18:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197003745"
Message-ID: <5475D302.3010409@citrix.com>
Date: Wed, 26 Nov 2014 13:17:54 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <5474DE5A.2060000@citrix.com> <20141126080912.GA944@aepfle.de>
In-Reply-To: <20141126080912.GA944@aepfle.de>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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 26/11/14 08:09, Olaf Hering wrote:
> On Tue, Nov 25, Andrew Cooper wrote:
>
>> The purpose of this email is to plan how to progress the migrationv2
>> series through to being merged.  I believe I have CC'd everyone with a
>> specific interest in this area, but apologies if I have missed anyone.
> While you mow that lawn,

Lawns cease to be called lawns when they get this gnarly.  Paddock
perhaps? :)

> did you guys think of handling downtime of the
> migrated VM?

This again is in contradiction to the primary purpose of "Make something
which is no less functional than legacy migration".  Having said that,
migration downtime is an area will be looking into in XenServer,
although at the moment the bottlenecks are elsewhere in the system.

> I added some knobs to abort migration in a very libxc
> specific way. What I would like to see is a simple user interface for
> virsh/xl to control the downtime. See the thread "limit downtime during
> life migration from xl/virsh":
>
> http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html

The v2 code is substantially more efficient than the legacy code.  It
makes fewer hypercalls, it doesn't attempt to map frames its not
planning to send, or frames which it knows doesn't exist, it makes an
order of magnitude fewer syscalls as part of actually moving data.  Side
by side in otherwise identical situations, v2 is noticeably faster than
legacy.  A gut feel on small VMs during dev testing would be between 1/4
and 1/3rd faster, but we also have various measurements at a higher
level which show an improvement all round.  In particular, total time to
suspend a 128GB HVM guest is down by 60% when the *only* different in
the system is the algorithm used in libxenguest.

Also, the current knobs in migration v2 are different.  Legacy has max
iterations and max factor as knobs, (where max factor is frankly a
ludicrous parameter in my opinion), and replaced with a dirty threshold
in v2.  v2 currently has these values hard coded to 5 iterations and 50
(or fewer) dirty frames before pause.  This has proved to be better

It is certainly my hope going forward that different knobs can be
exposed.  One thing I think would be interesting is some proper
calculations of the delta in the dirty set, and offering a threshold
which chooses between "pause and complete" or "abort the migration and
complain that the VM is too active"

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:02:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtdAJ-0007Fs-9v; Wed, 26 Nov 2014 14:01:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtdAH-0007Fn-PX
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 14:01:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EB/62-25276-15DD5745; Wed, 26 Nov 2014 14:01:53 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417010512!12745934!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14761 invoked from network); 26 Nov 2014 14:01:52 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:01:52 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 79E50ABE2;
	Wed, 26 Nov 2014 14:01:52 +0000 (UTC)
Message-ID: <5475DD4F.9060203@suse.com>
Date: Wed, 26 Nov 2014 15:01:51 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
In-Reply-To: <5475CA7A.7050200@citrix.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/26/2014 01:41 PM, Andrew Cooper wrote:
> On 26/11/14 12:15, Juergen Gross wrote:
>> Hi,
>>
>> I tried to enable kdump on my test-machine with actual xen-unstable
>> booting via EFI.
>>
>> The kdump kernel is not being loaded.
>>
>> I'm seeing the memory being reserved:
>>
>> (XEN) EFI RAM map:
>> (XEN)  0000000000000000 - 00000000000a0000 (usable)
>> (XEN)  0000000000100000 - 000000004bc00000 (usable)
>> (XEN)  000000004bc00000 - 000000005bc00000 (reserved)
>> (XEN)  000000005bc00000 - 000000005bfec000 (usable)
>> (XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
>> (XEN)  000000005c000000 - 000000006a429000 (usable)
>> (XEN)  000000006a429000 - 000000006a42c000 (reserved)
>> (XEN)  000000006a42c000 - 000000006a7a2000 (usable)
>> (XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
>> (XEN)  000000006a7a8000 - 000000006a987000 (usable)
>> (XEN)  000000006a987000 - 000000006a98d000 (reserved)
>> (XEN)  000000006a98d000 - 000000006aa63000 (usable)
>> (XEN)  000000006aa63000 - 000000006aa73000 (reserved)
>> (XEN)  000000006aa73000 - 000000006ac60000 (usable)
>> (XEN)  000000006ac60000 - 000000006ac61000 (reserved)
>> (XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
>> (XEN)  000000006ac9b000 - 000000006acac000 (reserved)
>> (XEN)  000000006acac000 - 000000006acad000 (usable)
>> (XEN)  000000006acad000 - 000000006acae000 (reserved)
>> (XEN)  000000006acae000 - 000000007189c000 (usable)
>> (XEN)  000000007189c000 - 0000000071946000 (reserved)
>> (XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
>> (XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
>> (XEN)  0000000072db2000 - 0000000072edc000 (usable)
>> (XEN)  0000000080000000 - 0000000090000000 (reserved)
>> (XEN)  0000000100000000 - 0000002080000000 (usable)
>> (XEN) Kdump: 256MB (262144kB) at 0x206dff4000
>>
>> I'd expect this area being visible in the efi or e820 map presented to
>> dom0, but I can't see anything:
>
> This is expected.  The dom0 kernel now has nothing at all do with
> loading crash kernel.  Loading happens via hypercalls straight from the
> kexec utility.
>
> You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
> support, but it should JustWork.

Should. I have kexec 2.0.5 with Xen support. Doesn't work:

Excerpt form strace:

"sysctl operation failed -- need to rebuild the user-space tool set?\n"

My personal translation: kexec is tightly coupled to the Xen version
(this one was built against Xen 4.4.1 AFAIK).

Perhaps we should add kexec to the tools directory?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:02:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtdAJ-0007Fs-9v; Wed, 26 Nov 2014 14:01:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtdAH-0007Fn-PX
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 14:01:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EB/62-25276-15DD5745; Wed, 26 Nov 2014 14:01:53 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417010512!12745934!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14761 invoked from network); 26 Nov 2014 14:01:52 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:01:52 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 79E50ABE2;
	Wed, 26 Nov 2014 14:01:52 +0000 (UTC)
Message-ID: <5475DD4F.9060203@suse.com>
Date: Wed, 26 Nov 2014 15:01:51 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
In-Reply-To: <5475CA7A.7050200@citrix.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/26/2014 01:41 PM, Andrew Cooper wrote:
> On 26/11/14 12:15, Juergen Gross wrote:
>> Hi,
>>
>> I tried to enable kdump on my test-machine with actual xen-unstable
>> booting via EFI.
>>
>> The kdump kernel is not being loaded.
>>
>> I'm seeing the memory being reserved:
>>
>> (XEN) EFI RAM map:
>> (XEN)  0000000000000000 - 00000000000a0000 (usable)
>> (XEN)  0000000000100000 - 000000004bc00000 (usable)
>> (XEN)  000000004bc00000 - 000000005bc00000 (reserved)
>> (XEN)  000000005bc00000 - 000000005bfec000 (usable)
>> (XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
>> (XEN)  000000005c000000 - 000000006a429000 (usable)
>> (XEN)  000000006a429000 - 000000006a42c000 (reserved)
>> (XEN)  000000006a42c000 - 000000006a7a2000 (usable)
>> (XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
>> (XEN)  000000006a7a8000 - 000000006a987000 (usable)
>> (XEN)  000000006a987000 - 000000006a98d000 (reserved)
>> (XEN)  000000006a98d000 - 000000006aa63000 (usable)
>> (XEN)  000000006aa63000 - 000000006aa73000 (reserved)
>> (XEN)  000000006aa73000 - 000000006ac60000 (usable)
>> (XEN)  000000006ac60000 - 000000006ac61000 (reserved)
>> (XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
>> (XEN)  000000006ac9b000 - 000000006acac000 (reserved)
>> (XEN)  000000006acac000 - 000000006acad000 (usable)
>> (XEN)  000000006acad000 - 000000006acae000 (reserved)
>> (XEN)  000000006acae000 - 000000007189c000 (usable)
>> (XEN)  000000007189c000 - 0000000071946000 (reserved)
>> (XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
>> (XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
>> (XEN)  0000000072db2000 - 0000000072edc000 (usable)
>> (XEN)  0000000080000000 - 0000000090000000 (reserved)
>> (XEN)  0000000100000000 - 0000002080000000 (usable)
>> (XEN) Kdump: 256MB (262144kB) at 0x206dff4000
>>
>> I'd expect this area being visible in the efi or e820 map presented to
>> dom0, but I can't see anything:
>
> This is expected.  The dom0 kernel now has nothing at all do with
> loading crash kernel.  Loading happens via hypercalls straight from the
> kexec utility.
>
> You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
> support, but it should JustWork.

Should. I have kexec 2.0.5 with Xen support. Doesn't work:

Excerpt form strace:

"sysctl operation failed -- need to rebuild the user-space tool set?\n"

My personal translation: kexec is tightly coupled to the Xen version
(this one was built against Xen 4.4.1 AFAIK).

Perhaps we should add kexec to the tools directory?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:27:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 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.xen.org>)
	id 1XtdYc-0007bq-Id; Wed, 26 Nov 2014 14:27:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtdYa-0007bl-GI
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 14:27:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	34/66-15461-333E5745; Wed, 26 Nov 2014 14:26:59 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417012017!15515889!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28327 invoked from network); 26 Nov 2014 14:26:59 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:26:59 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQEQm7u020695
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 14:26:49 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAQEQjXm014633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 14:26:46 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQEQjpP005337; Wed, 26 Nov 2014 14:26:45 GMT
Received: from [10.154.184.10] (/10.154.184.10)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 06:26:45 -0800
Message-ID: <5475E315.8050507@oracle.com>
Date: Wed, 26 Nov 2014 09:26:29 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
	<547493D4020000780004AAF3@mail.emea.novell.com>
In-Reply-To: <547493D4020000780004AAF3@mail.emea.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/25/2014 08:36 AM, Jan Beulich wrote:
>
>> +static long vpmu_sched_checkin(void *arg)
>> +{
>> +    int cpu = cpumask_next(smp_processor_id(), &cpu_online_map);
> unsigned int.
>
>> +    int ret;
>> +
>> +    /* Mode change shouldn't take more than a few (say, 5) seconds. */
>> +    if ( NOW() > vpmu_start_ctxt_switch + SECONDS(5) )
>> +    {
>> +        ret = -EBUSY;
>> +        goto fail;
>> +    }
> So what does this guard against? Holding xenpmu_mode_lock for
> 5 seconds is not a problem, plus I don't think you actually need a
> lock at all. Just using a global, atomically updated flag ought to be
> sufficient (the way you use the lock is really nothing else afaict).

I didn't put it here because of the lock. I just wanted to terminate 
this operation (mode change) if it takes unreasonable amount of time. 
And I thought 5 seconds would be unreasonable.


>
>> +{
>> +    int ret;
>> +
>> +    vpmu_start_ctxt_switch = NOW();
>> +
>> +    ret = continue_hypercall_on_cpu(cpumask_first(&cpu_online_map),
>> +                                    vpmu_sched_checkin, (void *)old_mode);
>> +    if ( ret )
>> +        vpmu_start_ctxt_switch = 0;
>> +
>> +    return ret;
>> +}
> I don't think it is guaranteed (independent of implementation details
> of continue_hypercall_on_cpu()) that this way you went through the
> context switch path once on each CPU if
> cpumask_first(&cpu_online_map) == smp_processor_id() here. In
> particular it looks like there being a problem calling vcpu_sleep_sync()
> in the tasklet handler when v == current (which would be the case
> if you started on the "correct" CPU and the tasklet softirq got
> handled before the scheduler one). I think you instead want to use
> cpumask_cycle() here and above, and finish the whole operation
> once you're back on the CPU you started on (the single-pCPU case
> may need some extra consideration).

So your concern is only because of initiating CPU? I can do a 
force_save() on it so I don't really need a context switch here. This 
will take care of single PCPU too.

>
> I realize that you simply follow what microcode_update() does, but
> I think we should rather correct that one than copy the latent issue
> it has elsewhere.
>
>> +long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
>> +{
>> +    int ret;
>> +    struct xen_pmu_params pmu_params;
>> +
>> +    ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
>> +    if ( ret )
>> +        return ret;
>> +
>> +    switch ( op )
>> +    {
>> +    case XENPMU_mode_set:
>> +    {
>> +        uint64_t old_mode;
> Irrespective of the earlier comments I don't see why this isn't just
> unsigned int (or typeof(vpmu_mode)).

This was because vpmu_force_context switch() takes uint64_t as an 
argument. Now that it will become unsigned long this should too, no? 
Yes, the compiler will promote it if it is an int but I thought this 
would look cleaner.


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:27:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 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.xen.org>)
	id 1XtdYe-0007c4-UR; Wed, 26 Nov 2014 14:27:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtdYd-0007bx-Uz
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 14:27:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6C/76-15461-733E5745; Wed, 26 Nov 2014 14:27:03 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417012020!8217701!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10839 invoked from network); 26 Nov 2014 14:27:02 -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;
	26 Nov 2014 14:27:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197032315"
Message-ID: <5475E311.6070501@citrix.com>
Date: Wed, 26 Nov 2014 14:26:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com>
In-Reply-To: <5475DD4F.9060203@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/11/14 14:01, Juergen Gross wrote:
> On 11/26/2014 01:41 PM, Andrew Cooper wrote:
>> On 26/11/14 12:15, Juergen Gross wrote:
>>> Hi,
>>>
>>> I tried to enable kdump on my test-machine with actual xen-unstable
>>> booting via EFI.
>>>
>>> The kdump kernel is not being loaded.
>>>
>>> I'm seeing the memory being reserved:
>>>
>>> (XEN) EFI RAM map:
>>> (XEN)  0000000000000000 - 00000000000a0000 (usable)
>>> (XEN)  0000000000100000 - 000000004bc00000 (usable)
>>> (XEN)  000000004bc00000 - 000000005bc00000 (reserved)
>>> (XEN)  000000005bc00000 - 000000005bfec000 (usable)
>>> (XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
>>> (XEN)  000000005c000000 - 000000006a429000 (usable)
>>> (XEN)  000000006a429000 - 000000006a42c000 (reserved)
>>> (XEN)  000000006a42c000 - 000000006a7a2000 (usable)
>>> (XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
>>> (XEN)  000000006a7a8000 - 000000006a987000 (usable)
>>> (XEN)  000000006a987000 - 000000006a98d000 (reserved)
>>> (XEN)  000000006a98d000 - 000000006aa63000 (usable)
>>> (XEN)  000000006aa63000 - 000000006aa73000 (reserved)
>>> (XEN)  000000006aa73000 - 000000006ac60000 (usable)
>>> (XEN)  000000006ac60000 - 000000006ac61000 (reserved)
>>> (XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
>>> (XEN)  000000006ac9b000 - 000000006acac000 (reserved)
>>> (XEN)  000000006acac000 - 000000006acad000 (usable)
>>> (XEN)  000000006acad000 - 000000006acae000 (reserved)
>>> (XEN)  000000006acae000 - 000000007189c000 (usable)
>>> (XEN)  000000007189c000 - 0000000071946000 (reserved)
>>> (XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
>>> (XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
>>> (XEN)  0000000072db2000 - 0000000072edc000 (usable)
>>> (XEN)  0000000080000000 - 0000000090000000 (reserved)
>>> (XEN)  0000000100000000 - 0000002080000000 (usable)
>>> (XEN) Kdump: 256MB (262144kB) at 0x206dff4000
>>>
>>> I'd expect this area being visible in the efi or e820 map presented to
>>> dom0, but I can't see anything:
>>
>> This is expected.  The dom0 kernel now has nothing at all do with
>> loading crash kernel.  Loading happens via hypercalls straight from the
>> kexec utility.
>>
>> You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
>> support, but it should JustWork.
>
> Should. I have kexec 2.0.5 with Xen support. Doesn't work:
>
> Excerpt form strace:
>
> "sysctl operation failed -- need to rebuild the user-space tool set?\n"
>
> My personal translation: kexec is tightly coupled to the Xen version
> (this one was built against Xen 4.4.1 AFAIK).

It uses libxc, so needs to be built from the same source.

>
> Perhaps we should add kexec to the tools directory?

The tools directory, and this willingness to fork other projects and
keep a local copy, is the primary driver behind this situation being as
dire as it is.

libxc (or some new alternative) should suck it up and gain some notion
of a stable API or ABI (like the rest of the world appears to be able to
manage), such that it is possible to compile with an older header and
use a newer .so at runtime.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:27:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 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.xen.org>)
	id 1XtdYc-0007bq-Id; Wed, 26 Nov 2014 14:27:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XtdYa-0007bl-GI
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 14:27:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	34/66-15461-333E5745; Wed, 26 Nov 2014 14:26:59 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417012017!15515889!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28327 invoked from network); 26 Nov 2014 14:26:59 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:26:59 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQEQm7u020695
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 14:26:49 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAQEQjXm014633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 14:26:46 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQEQjpP005337; Wed, 26 Nov 2014 14:26:45 GMT
Received: from [10.154.184.10] (/10.154.184.10)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 06:26:45 -0800
Message-ID: <5475E315.8050507@oracle.com>
Date: Wed, 26 Nov 2014 09:26:29 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
	<547493D4020000780004AAF3@mail.emea.novell.com>
In-Reply-To: <547493D4020000780004AAF3@mail.emea.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/25/2014 08:36 AM, Jan Beulich wrote:
>
>> +static long vpmu_sched_checkin(void *arg)
>> +{
>> +    int cpu = cpumask_next(smp_processor_id(), &cpu_online_map);
> unsigned int.
>
>> +    int ret;
>> +
>> +    /* Mode change shouldn't take more than a few (say, 5) seconds. */
>> +    if ( NOW() > vpmu_start_ctxt_switch + SECONDS(5) )
>> +    {
>> +        ret = -EBUSY;
>> +        goto fail;
>> +    }
> So what does this guard against? Holding xenpmu_mode_lock for
> 5 seconds is not a problem, plus I don't think you actually need a
> lock at all. Just using a global, atomically updated flag ought to be
> sufficient (the way you use the lock is really nothing else afaict).

I didn't put it here because of the lock. I just wanted to terminate 
this operation (mode change) if it takes unreasonable amount of time. 
And I thought 5 seconds would be unreasonable.


>
>> +{
>> +    int ret;
>> +
>> +    vpmu_start_ctxt_switch = NOW();
>> +
>> +    ret = continue_hypercall_on_cpu(cpumask_first(&cpu_online_map),
>> +                                    vpmu_sched_checkin, (void *)old_mode);
>> +    if ( ret )
>> +        vpmu_start_ctxt_switch = 0;
>> +
>> +    return ret;
>> +}
> I don't think it is guaranteed (independent of implementation details
> of continue_hypercall_on_cpu()) that this way you went through the
> context switch path once on each CPU if
> cpumask_first(&cpu_online_map) == smp_processor_id() here. In
> particular it looks like there being a problem calling vcpu_sleep_sync()
> in the tasklet handler when v == current (which would be the case
> if you started on the "correct" CPU and the tasklet softirq got
> handled before the scheduler one). I think you instead want to use
> cpumask_cycle() here and above, and finish the whole operation
> once you're back on the CPU you started on (the single-pCPU case
> may need some extra consideration).

So your concern is only because of initiating CPU? I can do a 
force_save() on it so I don't really need a context switch here. This 
will take care of single PCPU too.

>
> I realize that you simply follow what microcode_update() does, but
> I think we should rather correct that one than copy the latent issue
> it has elsewhere.
>
>> +long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
>> +{
>> +    int ret;
>> +    struct xen_pmu_params pmu_params;
>> +
>> +    ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
>> +    if ( ret )
>> +        return ret;
>> +
>> +    switch ( op )
>> +    {
>> +    case XENPMU_mode_set:
>> +    {
>> +        uint64_t old_mode;
> Irrespective of the earlier comments I don't see why this isn't just
> unsigned int (or typeof(vpmu_mode)).

This was because vpmu_force_context switch() takes uint64_t as an 
argument. Now that it will become unsigned long this should too, no? 
Yes, the compiler will promote it if it is an int but I thought this 
would look cleaner.


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:27:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 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.xen.org>)
	id 1XtdYe-0007c4-UR; Wed, 26 Nov 2014 14:27:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtdYd-0007bx-Uz
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 14:27:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6C/76-15461-733E5745; Wed, 26 Nov 2014 14:27:03 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417012020!8217701!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10839 invoked from network); 26 Nov 2014 14:27:02 -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;
	26 Nov 2014 14:27:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197032315"
Message-ID: <5475E311.6070501@citrix.com>
Date: Wed, 26 Nov 2014 14:26:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com>
In-Reply-To: <5475DD4F.9060203@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/11/14 14:01, Juergen Gross wrote:
> On 11/26/2014 01:41 PM, Andrew Cooper wrote:
>> On 26/11/14 12:15, Juergen Gross wrote:
>>> Hi,
>>>
>>> I tried to enable kdump on my test-machine with actual xen-unstable
>>> booting via EFI.
>>>
>>> The kdump kernel is not being loaded.
>>>
>>> I'm seeing the memory being reserved:
>>>
>>> (XEN) EFI RAM map:
>>> (XEN)  0000000000000000 - 00000000000a0000 (usable)
>>> (XEN)  0000000000100000 - 000000004bc00000 (usable)
>>> (XEN)  000000004bc00000 - 000000005bc00000 (reserved)
>>> (XEN)  000000005bc00000 - 000000005bfec000 (usable)
>>> (XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
>>> (XEN)  000000005c000000 - 000000006a429000 (usable)
>>> (XEN)  000000006a429000 - 000000006a42c000 (reserved)
>>> (XEN)  000000006a42c000 - 000000006a7a2000 (usable)
>>> (XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
>>> (XEN)  000000006a7a8000 - 000000006a987000 (usable)
>>> (XEN)  000000006a987000 - 000000006a98d000 (reserved)
>>> (XEN)  000000006a98d000 - 000000006aa63000 (usable)
>>> (XEN)  000000006aa63000 - 000000006aa73000 (reserved)
>>> (XEN)  000000006aa73000 - 000000006ac60000 (usable)
>>> (XEN)  000000006ac60000 - 000000006ac61000 (reserved)
>>> (XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
>>> (XEN)  000000006ac9b000 - 000000006acac000 (reserved)
>>> (XEN)  000000006acac000 - 000000006acad000 (usable)
>>> (XEN)  000000006acad000 - 000000006acae000 (reserved)
>>> (XEN)  000000006acae000 - 000000007189c000 (usable)
>>> (XEN)  000000007189c000 - 0000000071946000 (reserved)
>>> (XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
>>> (XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
>>> (XEN)  0000000072db2000 - 0000000072edc000 (usable)
>>> (XEN)  0000000080000000 - 0000000090000000 (reserved)
>>> (XEN)  0000000100000000 - 0000002080000000 (usable)
>>> (XEN) Kdump: 256MB (262144kB) at 0x206dff4000
>>>
>>> I'd expect this area being visible in the efi or e820 map presented to
>>> dom0, but I can't see anything:
>>
>> This is expected.  The dom0 kernel now has nothing at all do with
>> loading crash kernel.  Loading happens via hypercalls straight from the
>> kexec utility.
>>
>> You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
>> support, but it should JustWork.
>
> Should. I have kexec 2.0.5 with Xen support. Doesn't work:
>
> Excerpt form strace:
>
> "sysctl operation failed -- need to rebuild the user-space tool set?\n"
>
> My personal translation: kexec is tightly coupled to the Xen version
> (this one was built against Xen 4.4.1 AFAIK).

It uses libxc, so needs to be built from the same source.

>
> Perhaps we should add kexec to the tools directory?

The tools directory, and this willingness to fork other projects and
keep a local copy, is the primary driver behind this situation being as
dire as it is.

libxc (or some new alternative) should suck it up and gain some notion
of a stable API or ABI (like the rest of the world appears to be able to
manage), such that it is possible to compile with an older header and
use a newer .so at runtime.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:30:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14:30:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtdc4-0007p0-Hj; Wed, 26 Nov 2014 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 <konrad.wilk@oracle.com>) id 1Xtdc3-0007oq-7W
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 14:30:35 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	AF/05-29352-A04E5745; Wed, 26 Nov 2014 14:30:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417012232!13468787!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4313 invoked from network); 26 Nov 2014 14:30:33 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Nov 2014 14:30:33 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQEUUS8023284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 14:30:30 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAQEUTNY027117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 14:30:29 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQEUSh1017464; Wed, 26 Nov 2014 14:30:29 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 06:30:28 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EE552119AB5; Wed, 26 Nov 2014 09:30:27 -0500 (EST)
Date: Wed, 26 Nov 2014 09:30:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>, daniel.kiper@oracle.com
Message-ID: <20141126143027.GA8735@laptop.dumpdata.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5475DD4F.9060203@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
> On 11/26/2014 01:41 PM, Andrew Cooper wrote:
> >On 26/11/14 12:15, Juergen Gross wrote:
> >>Hi,
> >>
> >>I tried to enable kdump on my test-machine with actual xen-unstable
> >>booting via EFI.
> >>
> >>The kdump kernel is not being loaded.
> >>
> >>I'm seeing the memory being reserved:
> >>
> >>(XEN) EFI RAM map:
> >>(XEN)  0000000000000000 - 00000000000a0000 (usable)
> >>(XEN)  0000000000100000 - 000000004bc00000 (usable)
> >>(XEN)  000000004bc00000 - 000000005bc00000 (reserved)
> >>(XEN)  000000005bc00000 - 000000005bfec000 (usable)
> >>(XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
> >>(XEN)  000000005c000000 - 000000006a429000 (usable)
> >>(XEN)  000000006a429000 - 000000006a42c000 (reserved)
> >>(XEN)  000000006a42c000 - 000000006a7a2000 (usable)
> >>(XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
> >>(XEN)  000000006a7a8000 - 000000006a987000 (usable)
> >>(XEN)  000000006a987000 - 000000006a98d000 (reserved)
> >>(XEN)  000000006a98d000 - 000000006aa63000 (usable)
> >>(XEN)  000000006aa63000 - 000000006aa73000 (reserved)
> >>(XEN)  000000006aa73000 - 000000006ac60000 (usable)
> >>(XEN)  000000006ac60000 - 000000006ac61000 (reserved)
> >>(XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
> >>(XEN)  000000006ac9b000 - 000000006acac000 (reserved)
> >>(XEN)  000000006acac000 - 000000006acad000 (usable)
> >>(XEN)  000000006acad000 - 000000006acae000 (reserved)
> >>(XEN)  000000006acae000 - 000000007189c000 (usable)
> >>(XEN)  000000007189c000 - 0000000071946000 (reserved)
> >>(XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
> >>(XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
> >>(XEN)  0000000072db2000 - 0000000072edc000 (usable)
> >>(XEN)  0000000080000000 - 0000000090000000 (reserved)
> >>(XEN)  0000000100000000 - 0000002080000000 (usable)
> >>(XEN) Kdump: 256MB (262144kB) at 0x206dff4000
> >>
> >>I'd expect this area being visible in the efi or e820 map presented to
> >>dom0, but I can't see anything:
> >
> >This is expected.  The dom0 kernel now has nothing at all do with
> >loading crash kernel.  Loading happens via hypercalls straight from the
> >kexec utility.
> >
> >You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
> >support, but it should JustWork.
> 
> Should. I have kexec 2.0.5 with Xen support. Doesn't work:
> 
> Excerpt form strace:
> 
> "sysctl operation failed -- need to rebuild the user-space tool set?\n"
> 
> My personal translation: kexec is tightly coupled to the Xen version
> (this one was built against Xen 4.4.1 AFAIK).

Odd, the hypercall interface did not change in Xen 4.5 for kexec?

Perhaps it is making some other hypercalls that are tied in
to the version of Xen (like sysctl ones?).

I presume with recompiling it works?
> 
> Perhaps we should add kexec to the tools directory?

Gosh no.
> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 26 14:30:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14:30:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtdc4-0007p0-Hj; Wed, 26 Nov 2014 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 <konrad.wilk@oracle.com>) id 1Xtdc3-0007oq-7W
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 14:30:35 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	AF/05-29352-A04E5745; Wed, 26 Nov 2014 14:30:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417012232!13468787!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4313 invoked from network); 26 Nov 2014 14:30:33 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Nov 2014 14:30:33 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQEUUS8023284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 14:30:30 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAQEUTNY027117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 14:30:29 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQEUSh1017464; Wed, 26 Nov 2014 14:30:29 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 06:30:28 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EE552119AB5; Wed, 26 Nov 2014 09:30:27 -0500 (EST)
Date: Wed, 26 Nov 2014 09:30:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>, daniel.kiper@oracle.com
Message-ID: <20141126143027.GA8735@laptop.dumpdata.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5475DD4F.9060203@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
> On 11/26/2014 01:41 PM, Andrew Cooper wrote:
> >On 26/11/14 12:15, Juergen Gross wrote:
> >>Hi,
> >>
> >>I tried to enable kdump on my test-machine with actual xen-unstable
> >>booting via EFI.
> >>
> >>The kdump kernel is not being loaded.
> >>
> >>I'm seeing the memory being reserved:
> >>
> >>(XEN) EFI RAM map:
> >>(XEN)  0000000000000000 - 00000000000a0000 (usable)
> >>(XEN)  0000000000100000 - 000000004bc00000 (usable)
> >>(XEN)  000000004bc00000 - 000000005bc00000 (reserved)
> >>(XEN)  000000005bc00000 - 000000005bfec000 (usable)
> >>(XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
> >>(XEN)  000000005c000000 - 000000006a429000 (usable)
> >>(XEN)  000000006a429000 - 000000006a42c000 (reserved)
> >>(XEN)  000000006a42c000 - 000000006a7a2000 (usable)
> >>(XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
> >>(XEN)  000000006a7a8000 - 000000006a987000 (usable)
> >>(XEN)  000000006a987000 - 000000006a98d000 (reserved)
> >>(XEN)  000000006a98d000 - 000000006aa63000 (usable)
> >>(XEN)  000000006aa63000 - 000000006aa73000 (reserved)
> >>(XEN)  000000006aa73000 - 000000006ac60000 (usable)
> >>(XEN)  000000006ac60000 - 000000006ac61000 (reserved)
> >>(XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
> >>(XEN)  000000006ac9b000 - 000000006acac000 (reserved)
> >>(XEN)  000000006acac000 - 000000006acad000 (usable)
> >>(XEN)  000000006acad000 - 000000006acae000 (reserved)
> >>(XEN)  000000006acae000 - 000000007189c000 (usable)
> >>(XEN)  000000007189c000 - 0000000071946000 (reserved)
> >>(XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
> >>(XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
> >>(XEN)  0000000072db2000 - 0000000072edc000 (usable)
> >>(XEN)  0000000080000000 - 0000000090000000 (reserved)
> >>(XEN)  0000000100000000 - 0000002080000000 (usable)
> >>(XEN) Kdump: 256MB (262144kB) at 0x206dff4000
> >>
> >>I'd expect this area being visible in the efi or e820 map presented to
> >>dom0, but I can't see anything:
> >
> >This is expected.  The dom0 kernel now has nothing at all do with
> >loading crash kernel.  Loading happens via hypercalls straight from the
> >kexec utility.
> >
> >You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
> >support, but it should JustWork.
> 
> Should. I have kexec 2.0.5 with Xen support. Doesn't work:
> 
> Excerpt form strace:
> 
> "sysctl operation failed -- need to rebuild the user-space tool set?\n"
> 
> My personal translation: kexec is tightly coupled to the Xen version
> (this one was built against Xen 4.4.1 AFAIK).

Odd, the hypercall interface did not change in Xen 4.5 for kexec?

Perhaps it is making some other hypercalls that are tied in
to the version of Xen (like sysctl ones?).

I presume with recompiling it works?
> 
> Perhaps we should add kexec to the tools directory?

Gosh no.
> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 26 14:32:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14:32:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtddx-00081T-72; Wed, 26 Nov 2014 14:32:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xtddv-00081F-K0
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 14:32:31 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DB/A7-09842-E74E5745; Wed, 26 Nov 2014 14:32:30 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417012346!15517474!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4993 invoked from network); 26 Nov 2014 14:32:27 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:32:27 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQEWFGm025992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 14:32:16 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAQEWEXX004230
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 14:32:14 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQEWDcT026867; Wed, 26 Nov 2014 14:32:13 GMT
Received: from [10.154.184.10] (/10.154.184.10)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 06:32:13 -0800
Message-ID: <5475E46B.9000502@oracle.com>
Date: Wed, 26 Nov 2014 09:32:11 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
	<547496E0020000780004AB05@mail.emea.novell.com>
In-Reply-To: <547496E0020000780004AB05@mail.emea.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/25/2014 08:49 AM, Jan Beulich wrote:
>>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
>> @@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
>>       switch ( vendor )
>>       {
>>       case X86_VENDOR_AMD:
>> -        if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>> -            opt_vpmu_enabled = 0;
>> +        if ( svm_vpmu_initialise(v) != 0 )
>> +            vpmu_mode = XENPMU_MODE_OFF;
>>           break;
>>   
>>       case X86_VENDOR_INTEL:
>> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>> -            opt_vpmu_enabled = 0;
>> +        if ( vmx_vpmu_initialise(v) != 0 )
>> +            vpmu_mode = XENPMU_MODE_OFF;
>>           break;
> So this turns off the vPMU globally upon failure of initializing
> some random vCPU. Why is that? I see this was the case even
> before your entire series, but shouldn't this be fixed _before_
> enhancing the whole thing to support PV/PVH?

Yes, that's probably too strong. Do you want to fix this as an early 
patch (before PV(H)) support gets in? I'd rather do it in the patch that 
moves things into initcalls.

-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:32:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14:32:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtddx-00081T-72; Wed, 26 Nov 2014 14:32:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xtddv-00081F-K0
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 14:32:31 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DB/A7-09842-E74E5745; Wed, 26 Nov 2014 14:32:30 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417012346!15517474!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4993 invoked from network); 26 Nov 2014 14:32:27 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:32:27 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQEWFGm025992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 14:32:16 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAQEWEXX004230
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 14:32:14 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQEWDcT026867; Wed, 26 Nov 2014 14:32:13 GMT
Received: from [10.154.184.10] (/10.154.184.10)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 06:32:13 -0800
Message-ID: <5475E46B.9000502@oracle.com>
Date: Wed, 26 Nov 2014 09:32:11 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
	<547496E0020000780004AB05@mail.emea.novell.com>
In-Reply-To: <547496E0020000780004AB05@mail.emea.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/25/2014 08:49 AM, Jan Beulich wrote:
>>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
>> @@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
>>       switch ( vendor )
>>       {
>>       case X86_VENDOR_AMD:
>> -        if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>> -            opt_vpmu_enabled = 0;
>> +        if ( svm_vpmu_initialise(v) != 0 )
>> +            vpmu_mode = XENPMU_MODE_OFF;
>>           break;
>>   
>>       case X86_VENDOR_INTEL:
>> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>> -            opt_vpmu_enabled = 0;
>> +        if ( vmx_vpmu_initialise(v) != 0 )
>> +            vpmu_mode = XENPMU_MODE_OFF;
>>           break;
> So this turns off the vPMU globally upon failure of initializing
> some random vCPU. Why is that? I see this was the case even
> before your entire series, but shouldn't this be fixed _before_
> enhancing the whole thing to support PV/PVH?

Yes, that's probably too strong. Do you want to fix this as an early 
patch (before PV(H)) support gets in? I'd rather do it in the patch that 
moves things into initcalls.

-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:39:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14:39:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtdkg-0008FQ-7H; Wed, 26 Nov 2014 14:39:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xtdke-0008FL-8f
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 14:39:28 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	17/D8-02697-F16E5745; Wed, 26 Nov 2014 14:39:27 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417012765!13439400!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13051 invoked from network); 26 Nov 2014 14:39:26 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:39:26 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQEdHTD005900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 14:39:19 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQEdF8F022086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 14:39:16 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQEdEWA020291; Wed, 26 Nov 2014 14:39:14 GMT
Received: from [10.154.184.10] (/10.154.184.10)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 06:39:14 -0800
Message-ID: <5475E610.2020707@oracle.com>
Date: Wed, 26 Nov 2014 09:39:12 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-18-git-send-email-boris.ostrovsky@oracle.com>
	<5474A028020000780004AB58@mail.emea.novell.com>
In-Reply-To: <5474A028020000780004AB58@mail.emea.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 17/21] x86/VPMU: Handle PMU interrupts
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/25/2014 09:28 AM, Jan Beulich wrote:
>
>> +            else
>> +            {
>> +                struct segment_register seg;
>> +
>> +                hvm_get_segment_register(sampled, x86_seg_cs, &seg);
>> +                r->cs = seg.sel;
>> +                hvm_get_segment_register(sampled, x86_seg_ss, &seg);
>> +                r->ss = seg.sel;
>> +                if ( seg.attr.fields.dpl != 0 )
>> +                    *flags |= PMU_SAMPLE_USER;
> Is that how hardware treats it (CPL != 0 meaning user, rather
> than CPL == 3)?

You mean how *software* (e.g. Linux kernel) treats it? If yes, then for 
32-bit user_mode() checks for (CS == 3) and for 64-bit it's !!(CS & 3).

> Maybe you should surface CPL instead of a
> boolean flag?

Am I not already doing it by passing SS and CS to the guest?

-boris

>
> Anyway, with or without the adjustments (unless you go a 3rd
> way)
> Acked-by: Jan Beulich <jbeulich@suse.com>
>
> Jan
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:39:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14:39:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtdkg-0008FQ-7H; Wed, 26 Nov 2014 14:39:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Xtdke-0008FL-8f
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 14:39:28 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	17/D8-02697-F16E5745; Wed, 26 Nov 2014 14:39:27 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417012765!13439400!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13051 invoked from network); 26 Nov 2014 14:39:26 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:39:26 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQEdHTD005900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 14:39:19 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQEdF8F022086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 14:39:16 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQEdEWA020291; Wed, 26 Nov 2014 14:39:14 GMT
Received: from [10.154.184.10] (/10.154.184.10)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 06:39:14 -0800
Message-ID: <5475E610.2020707@oracle.com>
Date: Wed, 26 Nov 2014 09:39:12 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-18-git-send-email-boris.ostrovsky@oracle.com>
	<5474A028020000780004AB58@mail.emea.novell.com>
In-Reply-To: <5474A028020000780004AB58@mail.emea.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 17/21] x86/VPMU: Handle PMU interrupts
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/25/2014 09:28 AM, Jan Beulich wrote:
>
>> +            else
>> +            {
>> +                struct segment_register seg;
>> +
>> +                hvm_get_segment_register(sampled, x86_seg_cs, &seg);
>> +                r->cs = seg.sel;
>> +                hvm_get_segment_register(sampled, x86_seg_ss, &seg);
>> +                r->ss = seg.sel;
>> +                if ( seg.attr.fields.dpl != 0 )
>> +                    *flags |= PMU_SAMPLE_USER;
> Is that how hardware treats it (CPL != 0 meaning user, rather
> than CPL == 3)?

You mean how *software* (e.g. Linux kernel) treats it? If yes, then for 
32-bit user_mode() checks for (CS == 3) and for 64-bit it's !!(CS & 3).

> Maybe you should surface CPL instead of a
> boolean flag?

Am I not already doing it by passing SS and CS to the guest?

-boris

>
> Anyway, with or without the adjustments (unless you go a 3rd
> way)
> Acked-by: Jan Beulich <jbeulich@suse.com>
>
> Jan
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:41:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14:41:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtdmL-0008Kj-NI; Wed, 26 Nov 2014 14:41:13 +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 1XtdmK-0008Kd-Mb
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 14:41:12 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	96/02-20609-886E5745; Wed, 26 Nov 2014 14:41:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417012870!15022816!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19027 invoked from network); 26 Nov 2014 14:41:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:41:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQEejuE005488
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 14:40:46 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAQEei2M003582
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Nov 2014 14:40:44 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAQEehl9003512; Wed, 26 Nov 2014 14:40:44 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 06:40:43 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3FC70119ACA; Wed, 26 Nov 2014 09:40:41 -0500 (EST)
Date: Wed, 26 Nov 2014 09:40:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141126144040.GD8735@laptop.dumpdata.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
	<alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
	<1416994330.11944.25.camel@citrix.com>
	<alpine.DEB.2.02.1411261239160.14135@kaball.uk.xensource.com>
	<1417007040.11944.50.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417007040.11944.50.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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, Nov 26, 2014 at 01:04:00PM +0000, Ian Campbell wrote:
> On Wed, 2014-11-26 at 12:39 +0000, Stefano Stabellini wrote:
> > On Wed, 26 Nov 2014, Ian Campbell wrote:
> > > On Tue, 2014-11-25 at 17:05 +0000, Stefano Stabellini wrote:
> > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > > > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > > > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > > > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > > > > > each them. Assume 256K each.
> > > > > > > 
> > > > > > > I suppose this will have to do for 4.5. Can we do something better in
> > > > > > > the future -- like figuring out a way for guests to have
> > > > > > > "not-really-RAM" allocations like this which are made by the toolstack
> > > > > > > and happen to be backed by RAM not count or something.
> > > > > > > 
> > > > > > > > 
> > > > > > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > > > > > assigned to a VM.
> > > > > > > 
> > > > > > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > > > > > option roms? abort() seems a bit extreme.
> > > > > > > 
> > > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > > > CC: Don Slutz <dslutz@verizon.com>
> > > > > > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > > > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > > > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > > > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > > > > > 
> > > > > > > You missed Ian J. I've added him.
> > > > > > 
> > > > > > Actually Wei suggested a better alternative: I could call
> > > > > > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> > > > > 
> > > > > xl mem-set would do it again, but not taking qemu's extras into account,
> > > > > unless you communicate the overhead somehow...
> > > > 
> > > > We could start reading the current maxmem and add to it in
> > > > libxl_set_memory_target. Or we could write the maxmem to xenstore and
> > > > read it back again.  Given that the allocations are only done by QEMU at
> > > > initialization time, I don't think we need to worry about concurrency
> > > > here.
> > > 
> > > Might work, but it's a bit scary for 4.5, I would expect there to be
> > > subtle knock on effects from this sort of thing :-/
> >  
> > Given that this is not a regression, we could wait for 4.6 to commit the
> > fix and then if it doesn't cause any unwanted side effects, we could
> > backport it?
> 
> That's not a bad plan. Release noting "you can't create more than 4
> emulated NICs" doesn't seem so bad to me.

<wipes out the sweat from his forehead>

4.6 it is then!
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:41:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14:41:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtdmL-0008Kj-NI; Wed, 26 Nov 2014 14:41:13 +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 1XtdmK-0008Kd-Mb
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 14:41:12 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	96/02-20609-886E5745; Wed, 26 Nov 2014 14:41:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417012870!15022816!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19027 invoked from network); 26 Nov 2014 14:41:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:41:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQEejuE005488
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 14:40:46 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id
	sAQEei2M003582
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Nov 2014 14:40:44 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAQEehl9003512; Wed, 26 Nov 2014 14:40:44 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 06:40:43 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3FC70119ACA; Wed, 26 Nov 2014 09:40:41 -0500 (EST)
Date: Wed, 26 Nov 2014 09:40:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141126144040.GD8735@laptop.dumpdata.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
	<alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
	<1416994330.11944.25.camel@citrix.com>
	<alpine.DEB.2.02.1411261239160.14135@kaball.uk.xensource.com>
	<1417007040.11944.50.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417007040.11944.50.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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, Nov 26, 2014 at 01:04:00PM +0000, Ian Campbell wrote:
> On Wed, 2014-11-26 at 12:39 +0000, Stefano Stabellini wrote:
> > On Wed, 26 Nov 2014, Ian Campbell wrote:
> > > On Tue, 2014-11-25 at 17:05 +0000, Stefano Stabellini wrote:
> > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
> > > > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > > > On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
> > > > > > > > Account for the extra memory needed for the rom files of any emulated nics:
> > > > > > > > QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> > > > > > > > each them. Assume 256K each.
> > > > > > > 
> > > > > > > I suppose this will have to do for 4.5. Can we do something better in
> > > > > > > the future -- like figuring out a way for guests to have
> > > > > > > "not-really-RAM" allocations like this which are made by the toolstack
> > > > > > > and happen to be backed by RAM not count or something.
> > > > > > > 
> > > > > > > > 
> > > > > > > > This patch fixes a QEMU abort() when more than 4 emulated nics are
> > > > > > > > assigned to a VM.
> > > > > > > 
> > > > > > > Are you also going to fix qemu to fail gracefully if it cannot deploy
> > > > > > > option roms? abort() seems a bit extreme.
> > > > > > > 
> > > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > > > CC: Don Slutz <dslutz@verizon.com>
> > > > > > > > CC: hanyandong <hanyandong@iie.ac.cn>
> > > > > > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > > > > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > > > > > > CC: Wei Liu <wei.liu2@citrix.com>
> > > > > > > 
> > > > > > > You missed Ian J. I've added him.
> > > > > > 
> > > > > > Actually Wei suggested a better alternative: I could call
> > > > > > xc_domain_setmaxmem directly from QEMU. That makes much more sense.
> > > > > 
> > > > > xl mem-set would do it again, but not taking qemu's extras into account,
> > > > > unless you communicate the overhead somehow...
> > > > 
> > > > We could start reading the current maxmem and add to it in
> > > > libxl_set_memory_target. Or we could write the maxmem to xenstore and
> > > > read it back again.  Given that the allocations are only done by QEMU at
> > > > initialization time, I don't think we need to worry about concurrency
> > > > here.
> > > 
> > > Might work, but it's a bit scary for 4.5, I would expect there to be
> > > subtle knock on effects from this sort of thing :-/
> >  
> > Given that this is not a regression, we could wait for 4.6 to commit the
> > fix and then if it doesn't cause any unwanted side effects, we could
> > backport it?
> 
> That's not a bad plan. Release noting "you can't create more than 4
> emulated NICs" doesn't seem so bad to me.

<wipes out the sweat from his forehead>

4.6 it is then!
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:50:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14: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 1Xtduo-0000AD-Mm; Wed, 26 Nov 2014 14:49:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xtdun-0000A8-4s
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 14:49:57 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	85/A0-26858-498E5745; Wed, 26 Nov 2014 14:49:56 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417013395!11568439!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11832 invoked from network); 26 Nov 2014 14:49:55 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:49:55 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 5FBC2AC18;
	Wed, 26 Nov 2014 14:49:55 +0000 (UTC)
Message-ID: <5475E892.5060400@suse.com>
Date: Wed, 26 Nov 2014 15:49:54 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Daniel Kiper <daniel.kiper@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com>
	<20141126143027.GA8735@laptop.dumpdata.com>
In-Reply-To: <20141126143027.GA8735@laptop.dumpdata.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/26/2014 03:30 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
>> On 11/26/2014 01:41 PM, Andrew Cooper wrote:
>>> On 26/11/14 12:15, Juergen Gross wrote:
>>>> Hi,
>>>>
>>>> I tried to enable kdump on my test-machine with actual xen-unstable
>>>> booting via EFI.
>>>>
>>>> The kdump kernel is not being loaded.
>>>>
>>>> I'm seeing the memory being reserved:
>>>>
>>>> (XEN) EFI RAM map:
>>>> (XEN)  0000000000000000 - 00000000000a0000 (usable)
>>>> (XEN)  0000000000100000 - 000000004bc00000 (usable)
>>>> (XEN)  000000004bc00000 - 000000005bc00000 (reserved)
>>>> (XEN)  000000005bc00000 - 000000005bfec000 (usable)
>>>> (XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
>>>> (XEN)  000000005c000000 - 000000006a429000 (usable)
>>>> (XEN)  000000006a429000 - 000000006a42c000 (reserved)
>>>> (XEN)  000000006a42c000 - 000000006a7a2000 (usable)
>>>> (XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
>>>> (XEN)  000000006a7a8000 - 000000006a987000 (usable)
>>>> (XEN)  000000006a987000 - 000000006a98d000 (reserved)
>>>> (XEN)  000000006a98d000 - 000000006aa63000 (usable)
>>>> (XEN)  000000006aa63000 - 000000006aa73000 (reserved)
>>>> (XEN)  000000006aa73000 - 000000006ac60000 (usable)
>>>> (XEN)  000000006ac60000 - 000000006ac61000 (reserved)
>>>> (XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
>>>> (XEN)  000000006ac9b000 - 000000006acac000 (reserved)
>>>> (XEN)  000000006acac000 - 000000006acad000 (usable)
>>>> (XEN)  000000006acad000 - 000000006acae000 (reserved)
>>>> (XEN)  000000006acae000 - 000000007189c000 (usable)
>>>> (XEN)  000000007189c000 - 0000000071946000 (reserved)
>>>> (XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
>>>> (XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
>>>> (XEN)  0000000072db2000 - 0000000072edc000 (usable)
>>>> (XEN)  0000000080000000 - 0000000090000000 (reserved)
>>>> (XEN)  0000000100000000 - 0000002080000000 (usable)
>>>> (XEN) Kdump: 256MB (262144kB) at 0x206dff4000
>>>>
>>>> I'd expect this area being visible in the efi or e820 map presented to
>>>> dom0, but I can't see anything:
>>>
>>> This is expected.  The dom0 kernel now has nothing at all do with
>>> loading crash kernel.  Loading happens via hypercalls straight from the
>>> kexec utility.
>>>
>>> You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
>>> support, but it should JustWork.
>>
>> Should. I have kexec 2.0.5 with Xen support. Doesn't work:
>>
>> Excerpt form strace:
>>
>> "sysctl operation failed -- need to rebuild the user-space tool set?\n"
>>
>> My personal translation: kexec is tightly coupled to the Xen version
>> (this one was built against Xen 4.4.1 AFAIK).
>
> Odd, the hypercall interface did not change in Xen 4.5 for kexec?
>
> Perhaps it is making some other hypercalls that are tied in
> to the version of Xen (like sysctl ones?).

The error message above suggests that, yes. :-)

Grepping for xc_ in kexec sources finds e.g. xc_get_max_cpus() which
in turn calls xc_physinfo() doing a sysctl.

>
> I presume with recompiling it works?

Didn't check up to now, but I think it should.

>>
>> Perhaps we should add kexec to the tools directory?
>
> Gosh no.

Oops, did I forget the smiley? ;-)

I think we should look what kexec is really needing and put this in a
stable interface set (perhaps an own library?). This might require some
new sub functions of e.g. the KEXEC hypercall, but this is better than
making kexec depending on the Xen version.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:50:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 14: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 1Xtduo-0000AD-Mm; Wed, 26 Nov 2014 14:49:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xtdun-0000A8-4s
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 14:49:57 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	85/A0-26858-498E5745; Wed, 26 Nov 2014 14:49:56 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417013395!11568439!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11832 invoked from network); 26 Nov 2014 14:49:55 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:49:55 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 5FBC2AC18;
	Wed, 26 Nov 2014 14:49:55 +0000 (UTC)
Message-ID: <5475E892.5060400@suse.com>
Date: Wed, 26 Nov 2014 15:49:54 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Daniel Kiper <daniel.kiper@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com>
	<20141126143027.GA8735@laptop.dumpdata.com>
In-Reply-To: <20141126143027.GA8735@laptop.dumpdata.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/26/2014 03:30 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
>> On 11/26/2014 01:41 PM, Andrew Cooper wrote:
>>> On 26/11/14 12:15, Juergen Gross wrote:
>>>> Hi,
>>>>
>>>> I tried to enable kdump on my test-machine with actual xen-unstable
>>>> booting via EFI.
>>>>
>>>> The kdump kernel is not being loaded.
>>>>
>>>> I'm seeing the memory being reserved:
>>>>
>>>> (XEN) EFI RAM map:
>>>> (XEN)  0000000000000000 - 00000000000a0000 (usable)
>>>> (XEN)  0000000000100000 - 000000004bc00000 (usable)
>>>> (XEN)  000000004bc00000 - 000000005bc00000 (reserved)
>>>> (XEN)  000000005bc00000 - 000000005bfec000 (usable)
>>>> (XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
>>>> (XEN)  000000005c000000 - 000000006a429000 (usable)
>>>> (XEN)  000000006a429000 - 000000006a42c000 (reserved)
>>>> (XEN)  000000006a42c000 - 000000006a7a2000 (usable)
>>>> (XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
>>>> (XEN)  000000006a7a8000 - 000000006a987000 (usable)
>>>> (XEN)  000000006a987000 - 000000006a98d000 (reserved)
>>>> (XEN)  000000006a98d000 - 000000006aa63000 (usable)
>>>> (XEN)  000000006aa63000 - 000000006aa73000 (reserved)
>>>> (XEN)  000000006aa73000 - 000000006ac60000 (usable)
>>>> (XEN)  000000006ac60000 - 000000006ac61000 (reserved)
>>>> (XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
>>>> (XEN)  000000006ac9b000 - 000000006acac000 (reserved)
>>>> (XEN)  000000006acac000 - 000000006acad000 (usable)
>>>> (XEN)  000000006acad000 - 000000006acae000 (reserved)
>>>> (XEN)  000000006acae000 - 000000007189c000 (usable)
>>>> (XEN)  000000007189c000 - 0000000071946000 (reserved)
>>>> (XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
>>>> (XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
>>>> (XEN)  0000000072db2000 - 0000000072edc000 (usable)
>>>> (XEN)  0000000080000000 - 0000000090000000 (reserved)
>>>> (XEN)  0000000100000000 - 0000002080000000 (usable)
>>>> (XEN) Kdump: 256MB (262144kB) at 0x206dff4000
>>>>
>>>> I'd expect this area being visible in the efi or e820 map presented to
>>>> dom0, but I can't see anything:
>>>
>>> This is expected.  The dom0 kernel now has nothing at all do with
>>> loading crash kernel.  Loading happens via hypercalls straight from the
>>> kexec utility.
>>>
>>> You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
>>> support, but it should JustWork.
>>
>> Should. I have kexec 2.0.5 with Xen support. Doesn't work:
>>
>> Excerpt form strace:
>>
>> "sysctl operation failed -- need to rebuild the user-space tool set?\n"
>>
>> My personal translation: kexec is tightly coupled to the Xen version
>> (this one was built against Xen 4.4.1 AFAIK).
>
> Odd, the hypercall interface did not change in Xen 4.5 for kexec?
>
> Perhaps it is making some other hypercalls that are tied in
> to the version of Xen (like sysctl ones?).

The error message above suggests that, yes. :-)

Grepping for xc_ in kexec sources finds e.g. xc_get_max_cpus() which
in turn calls xc_physinfo() doing a sysctl.

>
> I presume with recompiling it works?

Didn't check up to now, but I think it should.

>>
>> Perhaps we should add kexec to the tools directory?
>
> Gosh no.

Oops, did I forget the smiley? ;-)

I think we should look what kexec is really needing and put this in a
stable interface set (perhaps an own library?). This might require some
new sub functions of e.g. the KEXEC hypercall, but this is better than
making kexec depending on the Xen version.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:53:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 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 1XtdyN-0000Nz-AI; Wed, 26 Nov 2014 14:53:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XtdyM-0000Nr-1n
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 14:53:38 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	EE/53-28865-179E5745; Wed, 26 Nov 2014 14:53:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417013616!13499563!1
X-Originating-IP: [81.169.146.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20673 invoked from network); 26 Nov 2014 14:53:36 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:53:36 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417013616; l=506;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=JVIJB/5lfv15TO+HicuyKFDACuM=;
	b=ZwiB/0aSZNueyh3SoWs/VYLFi21/QzuxRR46ISCHcbLKEeRfma5qh4R/Rn8jVqLStq/
	/1uBwaGWK+IzoVjIsWIoVp2CgA6axPyWtp4fCKf2/EMoD4vnuHS6QCkuegnCNQNgwejFd
	b0KP4NDAim4rlWKvUQQCDSk2kcxcuFh+/xE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.1 AUTH) with ESMTPSA id 601e1eqAQErV1hi
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 26 Nov 2014 15:53:31 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id EE30150172; Wed, 26 Nov 2014 15:53:30 +0100 (CET)
Date: Wed, 26 Nov 2014 15:53:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141126145330.GA3623@aepfle.de>
References: <5474DE5A.2060000@citrix.com> <20141126080912.GA944@aepfle.de>
	<5475D302.3010409@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5475D302.3010409@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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, Nov 26, Andrew Cooper wrote:

> It is certainly my hope going forward that different knobs can be
> exposed.  One thing I think would be interesting is some proper
> calculations of the delta in the dirty set, and offering a threshold
> which chooses between "pause and complete" or "abort the migration and
> complain that the VM is too active"

The "pause and complete" step is what causes unexpected time jumps in
the guest. Would be nice if that can be controlled with a knob.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 14:53:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 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 1XtdyN-0000Nz-AI; Wed, 26 Nov 2014 14:53:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XtdyM-0000Nr-1n
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 14:53:38 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	EE/53-28865-179E5745; Wed, 26 Nov 2014 14:53:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417013616!13499563!1
X-Originating-IP: [81.169.146.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20673 invoked from network); 26 Nov 2014 14:53:36 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 14:53:36 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417013616; l=506;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=JVIJB/5lfv15TO+HicuyKFDACuM=;
	b=ZwiB/0aSZNueyh3SoWs/VYLFi21/QzuxRR46ISCHcbLKEeRfma5qh4R/Rn8jVqLStq/
	/1uBwaGWK+IzoVjIsWIoVp2CgA6axPyWtp4fCKf2/EMoD4vnuHS6QCkuegnCNQNgwejFd
	b0KP4NDAim4rlWKvUQQCDSk2kcxcuFh+/xE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssDIZST8ulOSUJqstS8YMAWN1YEmXTnspMxV9Qxw==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1088:9901:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.1 AUTH) with ESMTPSA id 601e1eqAQErV1hi
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 26 Nov 2014 15:53:31 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id EE30150172; Wed, 26 Nov 2014 15:53:30 +0100 (CET)
Date: Wed, 26 Nov 2014 15:53:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141126145330.GA3623@aepfle.de>
References: <5474DE5A.2060000@citrix.com> <20141126080912.GA944@aepfle.de>
	<5475D302.3010409@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5475D302.3010409@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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, Nov 26, Andrew Cooper wrote:

> It is certainly my hope going forward that different knobs can be
> exposed.  One thing I think would be interesting is some proper
> calculations of the delta in the dirty set, and offering a threshold
> which chooses between "pause and complete" or "abort the migration and
> complain that the VM is too active"

The "pause and complete" step is what causes unexpected time jumps in
the guest. Would be nice if that can be controlled with a knob.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:10:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15: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 1XteDx-0000gk-RY; Wed, 26 Nov 2014 15:09:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XteDw-0000gf-Ab
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 15:09:44 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	FA/16-17694-73DE5745; Wed, 26 Nov 2014 15:09:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417014581!14040354!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1585 invoked from network); 26 Nov 2014 15:09:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 15:09:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197053162"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 10:09:41 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XteDs-00025T-KU; Wed, 26 Nov 2014 15:09:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Wed, 26 Nov 2014 15:09:40 +0000
Message-ID: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Zheng Li <zheng.li3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error in
	fd event handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This makes fields 0 and 1 true more often than they should be, resulting
problems when handling events.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Dave Scott <Dave.Scott@eu.citrix.com>
CC: Zheng Li <zheng.li3@citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

This was discovered with XenServers internal Coverity instance.  I have yet to
work out why the issue is not identified by the upstream coverity scanning.

Konrad: This is a bug in the default event handling used by oxenstored in 4.5,
as the default switched from select() to poll() in the 4.5 timeframe.  It
would appear that the negative side effects are limited to just logspam about
certain clients attempting invalid actions, but I can't rule out anything more
problematic.
---
 tools/ocaml/xenstored/select_stubs.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/ocaml/xenstored/select_stubs.c b/tools/ocaml/xenstored/select_stubs.c
index 4a8edb5..af72b84 100644
--- a/tools/ocaml/xenstored/select_stubs.c
+++ b/tools/ocaml/xenstored/select_stubs.c
@@ -56,8 +56,8 @@ CAMLprim value stub_select_on_poll(value fd_events, value timeo) {
 			events = Field(Field(fd_events, i), 1);
 
 			if (c_fds[i].revents & POLLNVAL) unix_error(EBADF, "select", Nothing);
-			Field(events, 0) = Val_bool(c_fds[i].events | POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
-			Field(events, 1) = Val_bool(c_fds[i].events | POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
+			Field(events, 0) = Val_bool(c_fds[i].events & POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
+			Field(events, 1) = Val_bool(c_fds[i].events & POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
 			Field(events, 2) = Val_bool(c_fds[i].revents & POLLPRI);
 
 		}
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:10:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15: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 1XteDx-0000gk-RY; Wed, 26 Nov 2014 15:09:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XteDw-0000gf-Ab
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 15:09:44 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	FA/16-17694-73DE5745; Wed, 26 Nov 2014 15:09:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417014581!14040354!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1585 invoked from network); 26 Nov 2014 15:09:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 15:09:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197053162"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 10:09:41 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XteDs-00025T-KU; Wed, 26 Nov 2014 15:09:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Wed, 26 Nov 2014 15:09:40 +0000
Message-ID: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Zheng Li <zheng.li3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error in
	fd event handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This makes fields 0 and 1 true more often than they should be, resulting
problems when handling events.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Dave Scott <Dave.Scott@eu.citrix.com>
CC: Zheng Li <zheng.li3@citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

This was discovered with XenServers internal Coverity instance.  I have yet to
work out why the issue is not identified by the upstream coverity scanning.

Konrad: This is a bug in the default event handling used by oxenstored in 4.5,
as the default switched from select() to poll() in the 4.5 timeframe.  It
would appear that the negative side effects are limited to just logspam about
certain clients attempting invalid actions, but I can't rule out anything more
problematic.
---
 tools/ocaml/xenstored/select_stubs.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/ocaml/xenstored/select_stubs.c b/tools/ocaml/xenstored/select_stubs.c
index 4a8edb5..af72b84 100644
--- a/tools/ocaml/xenstored/select_stubs.c
+++ b/tools/ocaml/xenstored/select_stubs.c
@@ -56,8 +56,8 @@ CAMLprim value stub_select_on_poll(value fd_events, value timeo) {
 			events = Field(Field(fd_events, i), 1);
 
 			if (c_fds[i].revents & POLLNVAL) unix_error(EBADF, "select", Nothing);
-			Field(events, 0) = Val_bool(c_fds[i].events | POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
-			Field(events, 1) = Val_bool(c_fds[i].events | POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
+			Field(events, 0) = Val_bool(c_fds[i].events & POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
+			Field(events, 1) = Val_bool(c_fds[i].events & POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
 			Field(events, 2) = Val_bool(c_fds[i].revents & POLLPRI);
 
 		}
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:38:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15:38:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtef6-00019k-8z; Wed, 26 Nov 2014 15:37:48 +0000
Resent-Date: Wed, 26 Nov 2014 15:37:48 +0000
Resent-Message-Id: <E1Xtef6-00019k-8z@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xtef4-00019f-Ni
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 15:37:46 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	6E/89-02702-AC3F5745; Wed, 26 Nov 2014 15:37:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417016264!15019799!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25067 invoked from network); 26 Nov 2014 15:37: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;
	26 Nov 2014 15:37:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197067034"
Message-ID: <1417005297.11944.43.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Jim Fehlig <jfehlig@suse.com>
Organization: Citrix Systems, Inc.
MIME-Version: 1.0
Resent-From: Ian Campbell <Ian.Campbell@citrix.com>
Resent-To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Jim Fehlig
	<jfehlig@suse.com>
Resent-Cc: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 26 Nov 2014 15:37:32 +0000
X-Mailer: Evolution 3.12.7-1 
X-DLP: MIA1
Subject: [Xen-devel] segv in osevent_release_nexus with libxl backend to
	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

Hi,

I'm seeing quite a few of these when shutting down domains:

        Program received signal SIGSEGV, Segmentation fault.
        [Switching to Thread 0xb47f9420 (LWP 3322)]
        0xb16d2f20 in osevent_release_nexus (gc=0xb47f88bc, nexi_idle=0x2a0968fc, nexus=0x0) at libxl_event.c:119
        119	libxl_event.c: No such file or directory.
        (gdb) bt
        #0  0xb16d2f20 in osevent_release_nexus (gc=0xb47f88bc, nexi_idle=0x2a0968fc, nexus=0x0) at libxl_event.c:119
        #1  0xb16d3a5c in osevent_hook_pre_release (nexus=0x2a096954, nexi_idle=<optimized out>, ev=0x2a096940, gc=0xb47f88bc) at libxl_event.c:149
        #2  libxl__ev_fd_deregister (gc=0xb47f88bc, ev=0x2a096940) at libxl_event.c:231
        #3  0xb16a47e0 in libxl_ctx_free (ctx=0x2a096888) at libxl.c:166
        #4  0xb171814e in libxlDomainObjPrivateDispose () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #5  0xb6c69176 in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0
        #6  0xb17181d2 in libxlDomainObjPrivateFree () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #7  0xb6c9c0da in virDomainObjDispose () from /opt/libvirt/lib/libvirt.so.0
        #8  0xb6c69176 in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0
        #9  0xb6c9ca26 in virDomainObjListRemove () from /opt/libvirt/lib/libvirt.so.0
        #10 0xb171c548 in libxlDomainDestroyFlags () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #11 0xb171c5fa in libxlDomainDestroy () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #12 0xb6d292f8 in virDomainDestroy () from /opt/libvirt/lib/libvirt.so.0
        #13 0x2a019d8a in remoteDispatchDomainDestroy ()
        #14 0x2a019cb8 in remoteDispatchDomainDestroyHelper ()
        #15 0x2a058392 in virNetServerProgramDispatchCall ()
        #16 0x2a057fde in virNetServerProgramDispatch ()
        #17 0x2a052814 in virNetServerProcessMsg ()
        #18 0x2a0528cc in virNetServerHandleJob ()
        #19 0xb6c82714 in virThreadPoolWorker () from /opt/libvirt/lib/libvirt.so.0
        #20 0xb6c82198 in virThreadHelper () from /opt/libvirt/lib/libvirt.so.0
        #21 0xb6b84ebc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
        #22 0xb6b34a38 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        #23 0xb6b34a38 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        Backtrace stopped: previous frame identical to this frame (corrupt stack?)
        
This is on ARM but I don't think this appears to be arch specific at
first glance. The bit from virObjectUnref->SEGV appears to be the same
each time, but the leadin can be different:
        (gdb) bt
        #0  0xb16d2f20 in osevent_release_nexus (gc=0xbefff51c, nexi_idle=0x2a09411c, nexus=0x0) at libxl_event.c:119
        #1  0xb16d3a5c in osevent_hook_pre_release (nexus=0x2a094174, nexi_idle=<optimized out>, ev=0x2a094160, gc=0xbefff51c) at libxl_event.c:149
        #2  libxl__ev_fd_deregister (gc=0xbefff51c, ev=0x2a094160) at libxl_event.c:231
        #3  0xb16a47e0 in libxl_ctx_free (ctx=0x2a0940a8) at libxl.c:166
        #4  0xb171814e in libxlDomainObjPrivateDispose () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #5  0xb6c69176 in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0
        #6  0xb1717696 in libxlDomainObjTimerEventHookInfoFree () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #7  0xb6c3eae4 in virEventPollCleanupTimeouts () from /opt/libvirt/lib/libvirt.so.0
        #8  0xb6c3f0f2 in virEventPollRunOnce () from /opt/libvirt/lib/libvirt.so.0
        #9  0xb6c3d2fc in virEventRunDefaultImpl () from /opt/libvirt/lib/libvirt.so.0
        #10 0x2a05495a in virNetServerRun ()
        #11 0x2a01297c in main ()
        
Perhaps that's just an artefact of the reference counting dropping to to
zero in a different order not really relevant.

I remember that a few releases ago we had some issues of this type, but
I thought they had all be resolved.

I'm running up to date versions of Xen:
        commit 28b4baacd599e8c10e6dac055f6a939bb730fb8a
        Author: Jan Beulich <jbeulich@suse.com>
        Date:   Tue Nov 25 10:08:57 2014 +0100
        
and of libvirt:
        commit 6c79469ccc3245b9572dcaabe8cd620ba3fabfad
        Author: Daniel P. Berrange <berrange@redhat.com>
        Date:   Tue Nov 18 17:53:51 2014 +0000

Any ideas?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:38:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15:38:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtef6-00019k-8z; Wed, 26 Nov 2014 15:37:48 +0000
Resent-Date: Wed, 26 Nov 2014 15:37:48 +0000
Resent-Message-Id: <E1Xtef6-00019k-8z@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xtef4-00019f-Ni
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 15:37:46 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	6E/89-02702-AC3F5745; Wed, 26 Nov 2014 15:37:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417016264!15019799!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25067 invoked from network); 26 Nov 2014 15:37: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;
	26 Nov 2014 15:37:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197067034"
Message-ID: <1417005297.11944.43.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Jim Fehlig <jfehlig@suse.com>
Organization: Citrix Systems, Inc.
MIME-Version: 1.0
Resent-From: Ian Campbell <Ian.Campbell@citrix.com>
Resent-To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Jim Fehlig
	<jfehlig@suse.com>
Resent-Cc: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 26 Nov 2014 15:37:32 +0000
X-Mailer: Evolution 3.12.7-1 
X-DLP: MIA1
Subject: [Xen-devel] segv in osevent_release_nexus with libxl backend to
	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

Hi,

I'm seeing quite a few of these when shutting down domains:

        Program received signal SIGSEGV, Segmentation fault.
        [Switching to Thread 0xb47f9420 (LWP 3322)]
        0xb16d2f20 in osevent_release_nexus (gc=0xb47f88bc, nexi_idle=0x2a0968fc, nexus=0x0) at libxl_event.c:119
        119	libxl_event.c: No such file or directory.
        (gdb) bt
        #0  0xb16d2f20 in osevent_release_nexus (gc=0xb47f88bc, nexi_idle=0x2a0968fc, nexus=0x0) at libxl_event.c:119
        #1  0xb16d3a5c in osevent_hook_pre_release (nexus=0x2a096954, nexi_idle=<optimized out>, ev=0x2a096940, gc=0xb47f88bc) at libxl_event.c:149
        #2  libxl__ev_fd_deregister (gc=0xb47f88bc, ev=0x2a096940) at libxl_event.c:231
        #3  0xb16a47e0 in libxl_ctx_free (ctx=0x2a096888) at libxl.c:166
        #4  0xb171814e in libxlDomainObjPrivateDispose () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #5  0xb6c69176 in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0
        #6  0xb17181d2 in libxlDomainObjPrivateFree () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #7  0xb6c9c0da in virDomainObjDispose () from /opt/libvirt/lib/libvirt.so.0
        #8  0xb6c69176 in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0
        #9  0xb6c9ca26 in virDomainObjListRemove () from /opt/libvirt/lib/libvirt.so.0
        #10 0xb171c548 in libxlDomainDestroyFlags () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #11 0xb171c5fa in libxlDomainDestroy () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #12 0xb6d292f8 in virDomainDestroy () from /opt/libvirt/lib/libvirt.so.0
        #13 0x2a019d8a in remoteDispatchDomainDestroy ()
        #14 0x2a019cb8 in remoteDispatchDomainDestroyHelper ()
        #15 0x2a058392 in virNetServerProgramDispatchCall ()
        #16 0x2a057fde in virNetServerProgramDispatch ()
        #17 0x2a052814 in virNetServerProcessMsg ()
        #18 0x2a0528cc in virNetServerHandleJob ()
        #19 0xb6c82714 in virThreadPoolWorker () from /opt/libvirt/lib/libvirt.so.0
        #20 0xb6c82198 in virThreadHelper () from /opt/libvirt/lib/libvirt.so.0
        #21 0xb6b84ebc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
        #22 0xb6b34a38 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        #23 0xb6b34a38 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        Backtrace stopped: previous frame identical to this frame (corrupt stack?)
        
This is on ARM but I don't think this appears to be arch specific at
first glance. The bit from virObjectUnref->SEGV appears to be the same
each time, but the leadin can be different:
        (gdb) bt
        #0  0xb16d2f20 in osevent_release_nexus (gc=0xbefff51c, nexi_idle=0x2a09411c, nexus=0x0) at libxl_event.c:119
        #1  0xb16d3a5c in osevent_hook_pre_release (nexus=0x2a094174, nexi_idle=<optimized out>, ev=0x2a094160, gc=0xbefff51c) at libxl_event.c:149
        #2  libxl__ev_fd_deregister (gc=0xbefff51c, ev=0x2a094160) at libxl_event.c:231
        #3  0xb16a47e0 in libxl_ctx_free (ctx=0x2a0940a8) at libxl.c:166
        #4  0xb171814e in libxlDomainObjPrivateDispose () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #5  0xb6c69176 in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0
        #6  0xb1717696 in libxlDomainObjTimerEventHookInfoFree () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #7  0xb6c3eae4 in virEventPollCleanupTimeouts () from /opt/libvirt/lib/libvirt.so.0
        #8  0xb6c3f0f2 in virEventPollRunOnce () from /opt/libvirt/lib/libvirt.so.0
        #9  0xb6c3d2fc in virEventRunDefaultImpl () from /opt/libvirt/lib/libvirt.so.0
        #10 0x2a05495a in virNetServerRun ()
        #11 0x2a01297c in main ()
        
Perhaps that's just an artefact of the reference counting dropping to to
zero in a different order not really relevant.

I remember that a few releases ago we had some issues of this type, but
I thought they had all be resolved.

I'm running up to date versions of Xen:
        commit 28b4baacd599e8c10e6dac055f6a939bb730fb8a
        Author: Jan Beulich <jbeulich@suse.com>
        Date:   Tue Nov 25 10:08:57 2014 +0100
        
and of libvirt:
        commit 6c79469ccc3245b9572dcaabe8cd620ba3fabfad
        Author: Daniel P. Berrange <berrange@redhat.com>
        Date:   Tue Nov 18 17:53:51 2014 +0000

Any ideas?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:38:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtefX-0001CR-Tq; Wed, 26 Nov 2014 15:38:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dev@zheng.li>) id 1XtefV-0001CG-Uu
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 15:38:14 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	26/0F-02696-5E3F5745; Wed, 26 Nov 2014 15:38:13 +0000
X-Env-Sender: dev@zheng.li
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417016290!15048165!1
X-Originating-IP: [194.14.179.111]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26355 invoked from network); 26 Nov 2014 15:38:11 -0000
Received: from svr.xenplanet.org (HELO svr.xenplanet.org) (194.14.179.111)
	by server-14.tower-27.messagelabs.com with SMTP;
	26 Nov 2014 15:38:11 -0000
Received: from zeta.local (unknown [185.25.64.249])
	by svr.xenplanet.org (Postfix) with ESMTPSA id 8A8C7680052;
	Wed, 26 Nov 2014 15:38:09 +0000 (UTC)
Message-ID: <5475F3DF.2070907@zheng.li>
Date: Wed, 26 Nov 2014 15:38:07 +0000
From: Zheng Li <dev@zheng.li>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:34.0) Gecko/20100101 Thunderbird/34.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Zheng Li <zheng.li3@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/11/2014 15:09, Andrew Cooper wrote:
> This makes fields 0 and 1 true more often than they should be, resulting
> problems when handling events.

Indeed, looks like a mistake I made when rewriting the logic terms lately. The result is POLLUP or POLLERR events being returned in more categories than we'd interest. Thanks for fixing this!

Acked-by: Zheng Li <dev@zheng.li>


Cheers,
Zheng


> ---
>
> This was discovered with XenServers internal Coverity instance.  I have yet to
> work out why the issue is not identified by the upstream coverity scanning.
>
> Konrad: This is a bug in the default event handling used by oxenstored in 4.5,
> as the default switched from select() to poll() in the 4.5 timeframe.  It
> would appear that the negative side effects are limited to just logspam about
> certain clients attempting invalid actions, but I can't rule out anything more
> problematic.
> ---
>   tools/ocaml/xenstored/select_stubs.c |    4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/ocaml/xenstored/select_stubs.c b/tools/ocaml/xenstored/select_stubs.c
> index 4a8edb5..af72b84 100644
> --- a/tools/ocaml/xenstored/select_stubs.c
> +++ b/tools/ocaml/xenstored/select_stubs.c
> @@ -56,8 +56,8 @@ CAMLprim value stub_select_on_poll(value fd_events, value timeo) {
>   			events = Field(Field(fd_events, i), 1);
>
>   			if (c_fds[i].revents & POLLNVAL) unix_error(EBADF, "select", Nothing);
> -			Field(events, 0) = Val_bool(c_fds[i].events | POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
> -			Field(events, 1) = Val_bool(c_fds[i].events | POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
> +			Field(events, 0) = Val_bool(c_fds[i].events & POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
> +			Field(events, 1) = Val_bool(c_fds[i].events & POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
>   			Field(events, 2) = Val_bool(c_fds[i].revents & POLLPRI);
>
>   		}
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:38:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtefX-0001CR-Tq; Wed, 26 Nov 2014 15:38:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dev@zheng.li>) id 1XtefV-0001CG-Uu
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 15:38:14 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	26/0F-02696-5E3F5745; Wed, 26 Nov 2014 15:38:13 +0000
X-Env-Sender: dev@zheng.li
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417016290!15048165!1
X-Originating-IP: [194.14.179.111]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26355 invoked from network); 26 Nov 2014 15:38:11 -0000
Received: from svr.xenplanet.org (HELO svr.xenplanet.org) (194.14.179.111)
	by server-14.tower-27.messagelabs.com with SMTP;
	26 Nov 2014 15:38:11 -0000
Received: from zeta.local (unknown [185.25.64.249])
	by svr.xenplanet.org (Postfix) with ESMTPSA id 8A8C7680052;
	Wed, 26 Nov 2014 15:38:09 +0000 (UTC)
Message-ID: <5475F3DF.2070907@zheng.li>
Date: Wed, 26 Nov 2014 15:38:07 +0000
From: Zheng Li <dev@zheng.li>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:34.0) Gecko/20100101 Thunderbird/34.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Zheng Li <zheng.li3@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/11/2014 15:09, Andrew Cooper wrote:
> This makes fields 0 and 1 true more often than they should be, resulting
> problems when handling events.

Indeed, looks like a mistake I made when rewriting the logic terms lately. The result is POLLUP or POLLERR events being returned in more categories than we'd interest. Thanks for fixing this!

Acked-by: Zheng Li <dev@zheng.li>


Cheers,
Zheng


> ---
>
> This was discovered with XenServers internal Coverity instance.  I have yet to
> work out why the issue is not identified by the upstream coverity scanning.
>
> Konrad: This is a bug in the default event handling used by oxenstored in 4.5,
> as the default switched from select() to poll() in the 4.5 timeframe.  It
> would appear that the negative side effects are limited to just logspam about
> certain clients attempting invalid actions, but I can't rule out anything more
> problematic.
> ---
>   tools/ocaml/xenstored/select_stubs.c |    4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/ocaml/xenstored/select_stubs.c b/tools/ocaml/xenstored/select_stubs.c
> index 4a8edb5..af72b84 100644
> --- a/tools/ocaml/xenstored/select_stubs.c
> +++ b/tools/ocaml/xenstored/select_stubs.c
> @@ -56,8 +56,8 @@ CAMLprim value stub_select_on_poll(value fd_events, value timeo) {
>   			events = Field(Field(fd_events, i), 1);
>
>   			if (c_fds[i].revents & POLLNVAL) unix_error(EBADF, "select", Nothing);
> -			Field(events, 0) = Val_bool(c_fds[i].events | POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
> -			Field(events, 1) = Val_bool(c_fds[i].events | POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
> +			Field(events, 0) = Val_bool(c_fds[i].events & POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
> +			Field(events, 1) = Val_bool(c_fds[i].events & POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
>   			Field(events, 2) = Val_bool(c_fds[i].revents & POLLPRI);
>
>   		}
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:39:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15:39:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtegw-0001Mf-GR; Wed, 26 Nov 2014 15:39:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xtegv-0001MU-6z
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 15:39:41 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	18/97-25276-C34F5745; Wed, 26 Nov 2014 15:39:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417016377!12774208!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3400 invoked from network); 26 Nov 2014 15:39:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 15:39:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197067754"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 10:39:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xtego-0002Wc-Hi;
	Wed, 26 Nov 2014 15:39:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xtegn-0003a8-UA;
	Wed, 26 Nov 2014 15:39:34 +0000
Date: Wed, 26 Nov 2014 15:39:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31857-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31857: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31857 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31857/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 31849

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 31849

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 seabios              b7f4a76a929ce4acd60e89aa273a8b208daa8233
baseline version:
 seabios              9f505f715793d99235bd6b4afb2ca7b96ba5729b

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 b7f4a76a929ce4acd60e89aa273a8b208daa8233
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Mon Nov 17 08:32:00 2014 +0100

    add scripts/tarball.sh
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:39:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15:39:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtegw-0001Mf-GR; Wed, 26 Nov 2014 15:39:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xtegv-0001MU-6z
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 15:39:41 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	18/97-25276-C34F5745; Wed, 26 Nov 2014 15:39:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417016377!12774208!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3400 invoked from network); 26 Nov 2014 15:39:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 15:39:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197067754"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 10:39:34 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xtego-0002Wc-Hi;
	Wed, 26 Nov 2014 15:39:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xtegn-0003a8-UA;
	Wed, 26 Nov 2014 15:39:34 +0000
Date: Wed, 26 Nov 2014 15:39:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31857-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31857: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31857 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31857/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 31849

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 31849

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 seabios              b7f4a76a929ce4acd60e89aa273a8b208daa8233
baseline version:
 seabios              9f505f715793d99235bd6b4afb2ca7b96ba5729b

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 b7f4a76a929ce4acd60e89aa273a8b208daa8233
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Mon Nov 17 08:32:00 2014 +0100

    add scripts/tarball.sh
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:40:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtehM-0001QD-Tj; Wed, 26 Nov 2014 15:40:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtehM-0001Q4-69
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 15:40:08 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	28/E7-17735-754F5745; Wed, 26 Nov 2014 15:40:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417016405!11582785!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31415 invoked from network); 26 Nov 2014 15:40:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 15:40:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197067909"
Message-ID: <1417016402.11944.60.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel
	<xen-devel@lists.xen.org>
Date: Wed, 26 Nov 2014 15:40:02 +0000
In-Reply-To: <21621.61406.151530.376288@mariner.uk.xensource.com>
References: <1417005297.11944.43.camel@citrix.com>
	<21621.61406.151530.376288@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>
Subject: Re: [Xen-devel] segv in osevent_release_nexus with libxl backend to
	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

(adding xen-devel which I forgot first time around)

On Wed, 2014-11-26 at 15:21 +0000, Ian Jackson wrote:
> Ian Campbell writes ("segv in osevent_release_nexus with libxl backend to libvirt"):
> > I'm seeing quite a few of these when shutting down domains:
> ...
> > This is on ARM but I don't think this appears to be arch specific at
> > first glance. The bit from virObjectUnref->SEGV appears to be the same
> > each time, but the leadin can be different:
> ...       
> > Perhaps that's just an artefact of the reference counting dropping to to
> > zero in a different order not really relevant.
> 
> Having looked at this, I think that this is because libxl_ctx_free is
> being reentered on the same ctx.
> 
> Below is a tiny patch to libxl which ought to crash on this earlier.
> Ian C, can you try it ?  If this catches anything it will probably
> show a path in libvirt where a libxl call is made without taking a ref
> on the vm object.

With this I am seeing:
        Program received signal SIGSEGV, Segmentation fault.
        0xb16d2fd8 in osevent_release_nexus (gc=0xbefff51c, nexi_idle=0x2a09701c, nexus=0x0) at libxl_event.c:119
        119	libxl_event.c: No such file or directory.
        (gdb) bt
        #0  0xb16d2fd8 in osevent_release_nexus (gc=0xbefff51c, nexi_idle=0x2a09701c, nexus=0x0) at libxl_event.c:119
        #1  0xb16d3b14 in osevent_hook_pre_release (nexus=0x2a097074, nexi_idle=<optimized out>, ev=0x2a097060, gc=0xbefff51c) at libxl_event.c:149
        #2  libxl__ev_fd_deregister (gc=0xbefff51c, ev=0x2a097060) at libxl_event.c:231
        #3  0xb16a4858 in libxl_ctx_free (ctx=0x2a096fa8) at libxl.c:168
        #4  0xb171814e in libxlDomainObjPrivateDispose () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #5  0xb6c69176 in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0
        #6  0xb1717696 in libxlDomainObjTimerEventHookInfoFree () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #7  0xb6c3eae4 in virEventPollCleanupTimeouts () from /opt/libvirt/lib/libvirt.so.0
        #8  0xb6c3f0f2 in virEventPollRunOnce () from /opt/libvirt/lib/libvirt.so.0
        #9  0xb6c3d2fc in virEventRunDefaultImpl () from /opt/libvirt/lib/libvirt.so.0
        #10 0x2a05495a in virNetServerRun ()
        #11 0x2a01297c in main ()
        

I don't think this is what you were hoping for :-/

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:40:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtehM-0001QD-Tj; Wed, 26 Nov 2014 15:40:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtehM-0001Q4-69
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 15:40:08 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	28/E7-17735-754F5745; Wed, 26 Nov 2014 15:40:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417016405!11582785!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31415 invoked from network); 26 Nov 2014 15:40:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 15:40:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="197067909"
Message-ID: <1417016402.11944.60.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel
	<xen-devel@lists.xen.org>
Date: Wed, 26 Nov 2014 15:40:02 +0000
In-Reply-To: <21621.61406.151530.376288@mariner.uk.xensource.com>
References: <1417005297.11944.43.camel@citrix.com>
	<21621.61406.151530.376288@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>
Subject: Re: [Xen-devel] segv in osevent_release_nexus with libxl backend to
	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

(adding xen-devel which I forgot first time around)

On Wed, 2014-11-26 at 15:21 +0000, Ian Jackson wrote:
> Ian Campbell writes ("segv in osevent_release_nexus with libxl backend to libvirt"):
> > I'm seeing quite a few of these when shutting down domains:
> ...
> > This is on ARM but I don't think this appears to be arch specific at
> > first glance. The bit from virObjectUnref->SEGV appears to be the same
> > each time, but the leadin can be different:
> ...       
> > Perhaps that's just an artefact of the reference counting dropping to to
> > zero in a different order not really relevant.
> 
> Having looked at this, I think that this is because libxl_ctx_free is
> being reentered on the same ctx.
> 
> Below is a tiny patch to libxl which ought to crash on this earlier.
> Ian C, can you try it ?  If this catches anything it will probably
> show a path in libvirt where a libxl call is made without taking a ref
> on the vm object.

With this I am seeing:
        Program received signal SIGSEGV, Segmentation fault.
        0xb16d2fd8 in osevent_release_nexus (gc=0xbefff51c, nexi_idle=0x2a09701c, nexus=0x0) at libxl_event.c:119
        119	libxl_event.c: No such file or directory.
        (gdb) bt
        #0  0xb16d2fd8 in osevent_release_nexus (gc=0xbefff51c, nexi_idle=0x2a09701c, nexus=0x0) at libxl_event.c:119
        #1  0xb16d3b14 in osevent_hook_pre_release (nexus=0x2a097074, nexi_idle=<optimized out>, ev=0x2a097060, gc=0xbefff51c) at libxl_event.c:149
        #2  libxl__ev_fd_deregister (gc=0xbefff51c, ev=0x2a097060) at libxl_event.c:231
        #3  0xb16a4858 in libxl_ctx_free (ctx=0x2a096fa8) at libxl.c:168
        #4  0xb171814e in libxlDomainObjPrivateDispose () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #5  0xb6c69176 in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0
        #6  0xb1717696 in libxlDomainObjTimerEventHookInfoFree () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #7  0xb6c3eae4 in virEventPollCleanupTimeouts () from /opt/libvirt/lib/libvirt.so.0
        #8  0xb6c3f0f2 in virEventPollRunOnce () from /opt/libvirt/lib/libvirt.so.0
        #9  0xb6c3d2fc in virEventRunDefaultImpl () from /opt/libvirt/lib/libvirt.so.0
        #10 0x2a05495a in virNetServerRun ()
        #11 0x2a01297c in main ()
        

I don't think this is what you were hoping for :-/

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:53:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xteu8-0001u8-Ec; Wed, 26 Nov 2014 15:53:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xteu7-0001sm-4f
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 15:53:19 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	77/FD-25276-E67F5745; Wed, 26 Nov 2014 15:53:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417017195!12777712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20087 invoked from network); 26 Nov 2014 15:53:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 15:53:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196824984"
Message-ID: <1417017154.11944.63.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 26 Nov 2014 15:52:34 +0000
In-Reply-To: <1417016402.11944.60.camel@citrix.com>
References: <1417005297.11944.43.camel@citrix.com>
	<21621.61406.151530.376288@mariner.uk.xensource.com>
	<1417016402.11944.60.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] segv in osevent_release_nexus with libxl backend to
 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, 2014-11-26 at 15:40 +0000, Ian Campbell wrote:
> (adding xen-devel which I forgot first time around)
> 
> On Wed, 2014-11-26 at 15:21 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("segv in osevent_release_nexus with libxl backend to libvirt"):
> > > I'm seeing quite a few of these when shutting down domains:
> > ...
> > > This is on ARM but I don't think this appears to be arch specific at
> > > first glance. The bit from virObjectUnref->SEGV appears to be the same
> > > each time, but the leadin can be different:
> > ...       
> > > Perhaps that's just an artefact of the reference counting dropping to to
> > > zero in a different order not really relevant.
> > 
> > Having looked at this, I think that this is because libxl_ctx_free is
> > being reentered on the same ctx.
> > 
> > Below is a tiny patch to libxl which ought to crash on this earlier.
> > Ian C, can you try it ?  If this catches anything it will probably
> > show a path in libvirt where a libxl call is made without taking a ref
> > on the vm object.
> 
> With this I am seeing:
>         Program received signal SIGSEGV, Segmentation fault.
>         0xb16d2fd8 in osevent_release_nexus (gc=0xbefff51c, nexi_idle=0x2a09701c, nexus=0x0) at libxl_event.c:119
>         119	libxl_event.c: No such file or directory.
>         (gdb) bt
>         #0  0xb16d2fd8 in osevent_release_nexus (gc=0xbefff51c, nexi_idle=0x2a09701c, nexus=0x0) at libxl_event.c:119
>         #1  0xb16d3b14 in osevent_hook_pre_release (nexus=0x2a097074, nexi_idle=<optimized out>, ev=0x2a097060, gc=0xbefff51c) at libxl_event.c:149
>         #2  libxl__ev_fd_deregister (gc=0xbefff51c, ev=0x2a097060) at libxl_event.c:231
>         #3  0xb16a4858 in libxl_ctx_free (ctx=0x2a096fa8) at libxl.c:168
>         #4  0xb171814e in libxlDomainObjPrivateDispose () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
>         #5  0xb6c69176 in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0
>         #6  0xb1717696 in libxlDomainObjTimerEventHookInfoFree () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
>         #7  0xb6c3eae4 in virEventPollCleanupTimeouts () from /opt/libvirt/lib/libvirt.so.0
>         #8  0xb6c3f0f2 in virEventPollRunOnce () from /opt/libvirt/lib/libvirt.so.0
>         #9  0xb6c3d2fc in virEventRunDefaultImpl () from /opt/libvirt/lib/libvirt.so.0
>         #10 0x2a05495a in virNetServerRun ()
>         #11 0x2a01297c in main ()
>         
> 
> I don't think this is what you were hoping for :-/

I don't know if this helps but on the 3 occasions I've just looked at
the ev passed to libxl__ev_fd_deregister contains an fd which
corresponds to a still open handle on /dev/xen/evtchn.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 15:53:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 15:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xteu8-0001u8-Ec; Wed, 26 Nov 2014 15:53:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xteu7-0001sm-4f
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 15:53:19 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	77/FD-25276-E67F5745; Wed, 26 Nov 2014 15:53:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417017195!12777712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20087 invoked from network); 26 Nov 2014 15:53:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 15:53:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="196824984"
Message-ID: <1417017154.11944.63.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 26 Nov 2014 15:52:34 +0000
In-Reply-To: <1417016402.11944.60.camel@citrix.com>
References: <1417005297.11944.43.camel@citrix.com>
	<21621.61406.151530.376288@mariner.uk.xensource.com>
	<1417016402.11944.60.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] segv in osevent_release_nexus with libxl backend to
 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, 2014-11-26 at 15:40 +0000, Ian Campbell wrote:
> (adding xen-devel which I forgot first time around)
> 
> On Wed, 2014-11-26 at 15:21 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("segv in osevent_release_nexus with libxl backend to libvirt"):
> > > I'm seeing quite a few of these when shutting down domains:
> > ...
> > > This is on ARM but I don't think this appears to be arch specific at
> > > first glance. The bit from virObjectUnref->SEGV appears to be the same
> > > each time, but the leadin can be different:
> > ...       
> > > Perhaps that's just an artefact of the reference counting dropping to to
> > > zero in a different order not really relevant.
> > 
> > Having looked at this, I think that this is because libxl_ctx_free is
> > being reentered on the same ctx.
> > 
> > Below is a tiny patch to libxl which ought to crash on this earlier.
> > Ian C, can you try it ?  If this catches anything it will probably
> > show a path in libvirt where a libxl call is made without taking a ref
> > on the vm object.
> 
> With this I am seeing:
>         Program received signal SIGSEGV, Segmentation fault.
>         0xb16d2fd8 in osevent_release_nexus (gc=0xbefff51c, nexi_idle=0x2a09701c, nexus=0x0) at libxl_event.c:119
>         119	libxl_event.c: No such file or directory.
>         (gdb) bt
>         #0  0xb16d2fd8 in osevent_release_nexus (gc=0xbefff51c, nexi_idle=0x2a09701c, nexus=0x0) at libxl_event.c:119
>         #1  0xb16d3b14 in osevent_hook_pre_release (nexus=0x2a097074, nexi_idle=<optimized out>, ev=0x2a097060, gc=0xbefff51c) at libxl_event.c:149
>         #2  libxl__ev_fd_deregister (gc=0xbefff51c, ev=0x2a097060) at libxl_event.c:231
>         #3  0xb16a4858 in libxl_ctx_free (ctx=0x2a096fa8) at libxl.c:168
>         #4  0xb171814e in libxlDomainObjPrivateDispose () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
>         #5  0xb6c69176 in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0
>         #6  0xb1717696 in libxlDomainObjTimerEventHookInfoFree () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
>         #7  0xb6c3eae4 in virEventPollCleanupTimeouts () from /opt/libvirt/lib/libvirt.so.0
>         #8  0xb6c3f0f2 in virEventPollRunOnce () from /opt/libvirt/lib/libvirt.so.0
>         #9  0xb6c3d2fc in virEventRunDefaultImpl () from /opt/libvirt/lib/libvirt.so.0
>         #10 0x2a05495a in virNetServerRun ()
>         #11 0x2a01297c in main ()
>         
> 
> I don't think this is what you were hoping for :-/

I don't know if this helps but on the 3 occasions I've just looked at
the ev passed to libxl__ev_fd_deregister contains an fd which
corresponds to a still open handle on /dev/xen/evtchn.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 16:40:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 16: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.xen.org>)
	id 1Xtfcx-00030g-AH; Wed, 26 Nov 2014 16:39:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xtfcw-00030b-A7
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 16:39:38 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E0/B2-27584-94206745; Wed, 26 Nov 2014 16:39:37 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417019976!8073258!1
X-Originating-IP: [209.85.215.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4481 invoked from network); 26 Nov 2014 16:39:37 -0000
Received: from mail-la0-f42.google.com (HELO mail-la0-f42.google.com)
	(209.85.215.42)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 16:39:37 -0000
Received: by mail-la0-f42.google.com with SMTP id s18so2816980lam.15
	for <xen-devel@lists.xenproject.org>;
	Wed, 26 Nov 2014 08:39:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=4OQXZOuGlkIpXYIuFdx6SmMDUev7ey/0Ptbr+XGHvaM=;
	b=NhxcAR7jMIJKttt7EdzhC1sDBDPhyB37rBomwMUyDguaQT7yNmcVUsFd8MChEpZTq7
	1mA9BznqhVtSmr+03hrZEQYVFK0pV96cYpCfg7k0pJh4X5q5Jpp7Tq9fWkQKpPgTFgBQ
	qUyiDGEO36w7xvaqSwUFWoDDhUOSUl71oRjU6MUhneaIbcrOtCyX7UeDi013IJUfilDy
	mo/ZGiZW539EfVtinHKVvyxET3FdgxDkMZh48um3QmHI1gpGl2Vter4slq4ZaQMv5HSa
	MTlN4dsBD6W4LfCTXg/z081GopukDgA3BE8qAtJZtiKuam1zFsUZiN+ZK24vEBH0Kxp3
	ZhcA==
X-Received: by 10.112.92.203 with SMTP id co11mr34594532lbb.79.1417019976368; 
	Wed, 26 Nov 2014 08:39:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.20.70 with HTTP; Wed, 26 Nov 2014 08:39:16 -0800 (PST)
In-Reply-To: <1408555596.16955.12.camel@hastur.hellion.org.uk>
References: <1408552838-4032-1-git-send-email-konrad.wilk@oracle.com>
	<1408552838-4032-2-git-send-email-konrad.wilk@oracle.com>
	<1408555132.16955.5.camel@hastur.hellion.org.uk>
	<20140820172029.GA5089@laptop.dumpdata.com>
	<1408555596.16955.12.camel@hastur.hellion.org.uk>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Wed, 26 Nov 2014 11:39:16 -0500
X-Google-Sender-Auth: jxw6Sc4rdLjyUywu7hhHdb1yX84
Message-ID: <CAB=NE6VS9hbk4nTRM7Gw_K6TChiEzDPoPGQ616EK68ASCN8BXQ@mail.gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: xen-devel@lists.xenproject.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen-pciback: Add MODULE_ALIAS for pciback.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Aug 20, 2014 at 1:26 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Wed, 2014-08-20 at 13:20 -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, Aug 20, 2014 at 06:18:52PM +0100, Ian Campbell wrote:
>> > On Wed, 2014-08-20 at 12:40 -0400, Konrad Rzeszutek Wilk wrote:
>> > > The rest of the Xen device drivers use an module alias
>> > > to load devices when they shop up in XenBus.
>> >
>> > "show".
>> > >
>> > >  MODULE_LICENSE("Dual BSD/GPL");
>> > >  MODULE_ALIAS("xen-backend:pci");
>> > > +MODULE_ALIAS("xen:pci");
>> >
>> > Isn't that xen-backend:pci already the right thing for a backend device?
>> > xen: is for frontends, I thought.
>>
>> Oh, you are right. Cool! Thanks!
>
> The patch turned out to be even more trivial than expected ;-)

Is this what we expected to be pending work for the item "device
hotplug (MODULE_ALIAS)" on the upstream TODO list?

http://wiki.xenproject.org/wiki/XenParavirtOps#Upstream_delta_details

This was simply to just auto load that driver when needed right?

Also as for actual PCI device hotplug support:

http://wiki.xen.org/wiki/Xen_PCI_Passthrough#Hotplug

I don't think we need a delta for that do we?

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 16:40:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 16: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.xen.org>)
	id 1Xtfcx-00030g-AH; Wed, 26 Nov 2014 16:39:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xtfcw-00030b-A7
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 16:39:38 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E0/B2-27584-94206745; Wed, 26 Nov 2014 16:39:37 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417019976!8073258!1
X-Originating-IP: [209.85.215.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4481 invoked from network); 26 Nov 2014 16:39:37 -0000
Received: from mail-la0-f42.google.com (HELO mail-la0-f42.google.com)
	(209.85.215.42)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 16:39:37 -0000
Received: by mail-la0-f42.google.com with SMTP id s18so2816980lam.15
	for <xen-devel@lists.xenproject.org>;
	Wed, 26 Nov 2014 08:39:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=4OQXZOuGlkIpXYIuFdx6SmMDUev7ey/0Ptbr+XGHvaM=;
	b=NhxcAR7jMIJKttt7EdzhC1sDBDPhyB37rBomwMUyDguaQT7yNmcVUsFd8MChEpZTq7
	1mA9BznqhVtSmr+03hrZEQYVFK0pV96cYpCfg7k0pJh4X5q5Jpp7Tq9fWkQKpPgTFgBQ
	qUyiDGEO36w7xvaqSwUFWoDDhUOSUl71oRjU6MUhneaIbcrOtCyX7UeDi013IJUfilDy
	mo/ZGiZW539EfVtinHKVvyxET3FdgxDkMZh48um3QmHI1gpGl2Vter4slq4ZaQMv5HSa
	MTlN4dsBD6W4LfCTXg/z081GopukDgA3BE8qAtJZtiKuam1zFsUZiN+ZK24vEBH0Kxp3
	ZhcA==
X-Received: by 10.112.92.203 with SMTP id co11mr34594532lbb.79.1417019976368; 
	Wed, 26 Nov 2014 08:39:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.20.70 with HTTP; Wed, 26 Nov 2014 08:39:16 -0800 (PST)
In-Reply-To: <1408555596.16955.12.camel@hastur.hellion.org.uk>
References: <1408552838-4032-1-git-send-email-konrad.wilk@oracle.com>
	<1408552838-4032-2-git-send-email-konrad.wilk@oracle.com>
	<1408555132.16955.5.camel@hastur.hellion.org.uk>
	<20140820172029.GA5089@laptop.dumpdata.com>
	<1408555596.16955.12.camel@hastur.hellion.org.uk>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Wed, 26 Nov 2014 11:39:16 -0500
X-Google-Sender-Auth: jxw6Sc4rdLjyUywu7hhHdb1yX84
Message-ID: <CAB=NE6VS9hbk4nTRM7Gw_K6TChiEzDPoPGQ616EK68ASCN8BXQ@mail.gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: xen-devel@lists.xenproject.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen-pciback: Add MODULE_ALIAS for pciback.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Aug 20, 2014 at 1:26 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Wed, 2014-08-20 at 13:20 -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, Aug 20, 2014 at 06:18:52PM +0100, Ian Campbell wrote:
>> > On Wed, 2014-08-20 at 12:40 -0400, Konrad Rzeszutek Wilk wrote:
>> > > The rest of the Xen device drivers use an module alias
>> > > to load devices when they shop up in XenBus.
>> >
>> > "show".
>> > >
>> > >  MODULE_LICENSE("Dual BSD/GPL");
>> > >  MODULE_ALIAS("xen-backend:pci");
>> > > +MODULE_ALIAS("xen:pci");
>> >
>> > Isn't that xen-backend:pci already the right thing for a backend device?
>> > xen: is for frontends, I thought.
>>
>> Oh, you are right. Cool! Thanks!
>
> The patch turned out to be even more trivial than expected ;-)

Is this what we expected to be pending work for the item "device
hotplug (MODULE_ALIAS)" on the upstream TODO list?

http://wiki.xenproject.org/wiki/XenParavirtOps#Upstream_delta_details

This was simply to just auto load that driver when needed right?

Also as for actual PCI device hotplug support:

http://wiki.xen.org/wiki/Xen_PCI_Passthrough#Hotplug

I don't think we need a delta for that do we?

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 16:45:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 16:45:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtfii-0003FW-5b; Wed, 26 Nov 2014 16:45: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 1Xtfig-0003FR-9w
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 16:45:34 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	5B/1C-22819-DA306745; Wed, 26 Nov 2014 16:45:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417020330!13472769!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12560 invoked from network); 26 Nov 2014 16:45:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 16:45:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="197096268"
Message-ID: <1417020283.11944.65.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Wed, 26 Nov 2014 16:44:43 +0000
In-Reply-To: <5474DE5A.2060000@citrix.com>
References: <5474DE5A.2060000@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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, 2014-11-25 at 19:54 +0000, Andrew Cooper wrote:
> There is an xl/libxl part of the migration v2 series which attempts to
> rectify this all in one go, as there is no alternative way of doing so. 
> The libxl section of the series is certainly not yet complete, but
> specific queries to the maintainers have thusfar gone unanswered.  On
> the other hand, the series does basically WorkForMe, including
> transparent legacy upgrade, suggesting that it is at least in an
> appropriate ballpark.

Is this, from "[PATCH 27/29] [VERY RFC] tools/libxl: Support restoring
legacy streams":

        This WorksForMe in the success case, but the error handling is certainly lacking.
        
        Specifically, the conversion scripts output fd can't be closed until the v2
        read loop has exited (cleanly or otherwise), without risking a close()/open()
        race silently replacing the fd behind the loops back.
        
        However, it can't be closed when the read loop exits, as the conversion script
        child might still be alive, and would prefer terminating cleaning than failing
        with a bad FD.
        
        Obviously, having one error handler block for the success/failure of the other
        side is a no-go, and would still involve a preselecting which was expected to
        exit first.
        
        Does anyone have any clever ideas of how to asynchronously collect the events
        "the conversion script has exited", "the save helper has exited" and "the v2
        read loop has finished" given the available infrastructure, to kick of a
        combined cleanup of all 3?

? I said then:
        
        This is probably one for Ian when he gets back, but a state machine
        which is cranked in response to the callbacks from the various
        completion events might be one way to approach this.
        
Prodding Ian again (by moving to the To: line...)

Was there any other questions? I've had a scrobble through the bit of v7
which 00/29 suggests might contain them, but that's the only one I saw.

Ian. 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 16:45:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 16:45:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtfii-0003FW-5b; Wed, 26 Nov 2014 16:45: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 1Xtfig-0003FR-9w
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 16:45:34 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	5B/1C-22819-DA306745; Wed, 26 Nov 2014 16:45:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417020330!13472769!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12560 invoked from network); 26 Nov 2014 16:45:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 16:45:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="197096268"
Message-ID: <1417020283.11944.65.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Wed, 26 Nov 2014 16:44:43 +0000
In-Reply-To: <5474DE5A.2060000@citrix.com>
References: <5474DE5A.2060000@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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, 2014-11-25 at 19:54 +0000, Andrew Cooper wrote:
> There is an xl/libxl part of the migration v2 series which attempts to
> rectify this all in one go, as there is no alternative way of doing so. 
> The libxl section of the series is certainly not yet complete, but
> specific queries to the maintainers have thusfar gone unanswered.  On
> the other hand, the series does basically WorkForMe, including
> transparent legacy upgrade, suggesting that it is at least in an
> appropriate ballpark.

Is this, from "[PATCH 27/29] [VERY RFC] tools/libxl: Support restoring
legacy streams":

        This WorksForMe in the success case, but the error handling is certainly lacking.
        
        Specifically, the conversion scripts output fd can't be closed until the v2
        read loop has exited (cleanly or otherwise), without risking a close()/open()
        race silently replacing the fd behind the loops back.
        
        However, it can't be closed when the read loop exits, as the conversion script
        child might still be alive, and would prefer terminating cleaning than failing
        with a bad FD.
        
        Obviously, having one error handler block for the success/failure of the other
        side is a no-go, and would still involve a preselecting which was expected to
        exit first.
        
        Does anyone have any clever ideas of how to asynchronously collect the events
        "the conversion script has exited", "the save helper has exited" and "the v2
        read loop has finished" given the available infrastructure, to kick of a
        combined cleanup of all 3?

? I said then:
        
        This is probably one for Ian when he gets back, but a state machine
        which is cranked in response to the callbacks from the various
        completion events might be one way to approach this.
        
Prodding Ian again (by moving to the To: line...)

Was there any other questions? I've had a scrobble through the bit of v7
which 00/29 suggests might contain them, but that's the only one I saw.

Ian. 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 16:50:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 16:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtfng-0003PN-C6; Wed, 26 Nov 2014 16:50:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xtfnf-0003PG-AC
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 16:50:43 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	39/CD-18267-2E406745; Wed, 26 Nov 2014 16:50:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417020640!14013790!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8753 invoked from network); 26 Nov 2014 16:50:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 16:50:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="197098438"
Message-ID: <1417020637.11944.67.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 26 Nov 2014 16:50:37 +0000
In-Reply-To: <5474DE5A.2060000@citrix.com>
References: <5474DE5A.2060000@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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, 2014-11-25 at 19:54 +0000, Andrew Cooper wrote:
> 3) Libxl and xl support
> 
> Libxl and xl have as many problems as the libxc code did when it comes
> to incompatible wire formats and layering violations.  In particular, it
> is not possible to determine the bitness of the sending
> libxl-saverestore-helper, meaning that legacy conversion requires active
> administrator input, or at least a passive assumption that the bitness
> is the same.

IOW when migrating legacy->new we have the same restriction as we do
today in the purely legacy world, which is that the two dom0's must
having match bit widths?

IMHO this is fine. It essentially means that for xl users there is some
delayed gratification wrt the promise of migration between non-alike
dom0s. The migration from 4.5(legacy)->4.6(v2) won't support such
migrations, but the next step from 4.6(v2)->4.7(v2) will.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 16:50:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 16:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtfng-0003PN-C6; Wed, 26 Nov 2014 16:50:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xtfnf-0003PG-AC
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 16:50:43 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	39/CD-18267-2E406745; Wed, 26 Nov 2014 16:50:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417020640!14013790!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8753 invoked from network); 26 Nov 2014 16:50:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 16:50:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="197098438"
Message-ID: <1417020637.11944.67.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 26 Nov 2014 16:50:37 +0000
In-Reply-To: <5474DE5A.2060000@citrix.com>
References: <5474DE5A.2060000@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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, 2014-11-25 at 19:54 +0000, Andrew Cooper wrote:
> 3) Libxl and xl support
> 
> Libxl and xl have as many problems as the libxc code did when it comes
> to incompatible wire formats and layering violations.  In particular, it
> is not possible to determine the bitness of the sending
> libxl-saverestore-helper, meaning that legacy conversion requires active
> administrator input, or at least a passive assumption that the bitness
> is the same.

IOW when migrating legacy->new we have the same restriction as we do
today in the purely legacy world, which is that the two dom0's must
having match bit widths?

IMHO this is fine. It essentially means that for xl users there is some
delayed gratification wrt the promise of migration between non-alike
dom0s. The migration from 4.5(legacy)->4.6(v2) won't support such
migrations, but the next step from 4.6(v2)->4.7(v2) will.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 16:53:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 16:53:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtfqR-0003cf-UU; Wed, 26 Nov 2014 16:53:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1XtfqQ-0003cY-4e
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 16:53:34 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	91/4B-14727-D8506745; Wed, 26 Nov 2014 16:53:33 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417020812!13478640!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21427 invoked from network); 26 Nov 2014 16:53:32 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 16:53:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 26 Nov 2014 16:53:32 +0000
Message-Id: <5476058A02000078000C2808@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 26 Nov 2014 16:53:30 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <andrew.cooper3@citrix.com>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
In-Reply-To: <5474C658.4030901@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Andrew Cooper <andrew.cooper3@citrix.com> 11/25/14 7:14 PM >>>
>On 25/11/14 17:25, Jan Beulich wrote:
>>>>> On 25.11.14 at 17:54, <andrew.cooper3@citrix.com> wrote:
>>> This is RFC as there is still a niggle.  I tested this via a partial revert of
>>> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
>>> domain crash.  However, I am not sure we want to make any vmentry failure
>>> quite, as any vmentry failure constitues a Xen bug.
>> I think that double printing would be tolerable, but I've had yet
>> another idea: Couldn't we make the second exception a #DF,
>> thus having the guest killed via triple fault in the worst case at
>> the third recurring failure (via hvm_combine_hw_exceptions())?
>
>That still won't catch a large class of vmentry failures from bad host
>state.  There needs to be some cutoff where we simply give up and crash
>the domain.  In the end, this is just an exercise in how much we attempt
>to recover in the case that we have already hit a hypervisor bug, and
>can't be completely certain about any state.
>
>Furthermore, guest userspace being able to exploit a Xen bug to result
>in a triple fault is no better than an instant domain_crash(), from a
>VMs point of view.  However, from a toolstacks point of view, it is even
>worse, as malicious userspace could tie up toolstack resource in
>domain_kill() and domain_create() (as a triple fault is modelled as a
>clean reboot).

Right - the more I think about it, the more I'm inclined to take your v1 patch...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 16:53:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 16:53:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtfqR-0003cf-UU; Wed, 26 Nov 2014 16:53:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1XtfqQ-0003cY-4e
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 16:53:34 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	91/4B-14727-D8506745; Wed, 26 Nov 2014 16:53:33 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417020812!13478640!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21427 invoked from network); 26 Nov 2014 16:53:32 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 16:53:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 26 Nov 2014 16:53:32 +0000
Message-Id: <5476058A02000078000C2808@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 26 Nov 2014 16:53:30 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <andrew.cooper3@citrix.com>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
In-Reply-To: <5474C658.4030901@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Andrew Cooper <andrew.cooper3@citrix.com> 11/25/14 7:14 PM >>>
>On 25/11/14 17:25, Jan Beulich wrote:
>>>>> On 25.11.14 at 17:54, <andrew.cooper3@citrix.com> wrote:
>>> This is RFC as there is still a niggle.  I tested this via a partial revert of
>>> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
>>> domain crash.  However, I am not sure we want to make any vmentry failure
>>> quite, as any vmentry failure constitues a Xen bug.
>> I think that double printing would be tolerable, but I've had yet
>> another idea: Couldn't we make the second exception a #DF,
>> thus having the guest killed via triple fault in the worst case at
>> the third recurring failure (via hvm_combine_hw_exceptions())?
>
>That still won't catch a large class of vmentry failures from bad host
>state.  There needs to be some cutoff where we simply give up and crash
>the domain.  In the end, this is just an exercise in how much we attempt
>to recover in the case that we have already hit a hypervisor bug, and
>can't be completely certain about any state.
>
>Furthermore, guest userspace being able to exploit a Xen bug to result
>in a triple fault is no better than an instant domain_crash(), from a
>VMs point of view.  However, from a toolstacks point of view, it is even
>worse, as malicious userspace could tie up toolstack resource in
>domain_kill() and domain_create() (as a triple fault is modelled as a
>clean reboot).

Right - the more I think about it, the more I'm inclined to take your v1 patch...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 16:55:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 16: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 1XtfsT-0003ir-En; Wed, 26 Nov 2014 16:55: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 1XtfsS-0003ij-0W
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 16:55:40 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	4A/E1-24859-B0606745; Wed, 26 Nov 2014 16:55:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417020937!14014785!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6520 invoked from network); 26 Nov 2014 16:55:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 16:55:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="197100427"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 11:55:35 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XtfsN-0004dF-JW;
	Wed, 26 Nov 2014 16:55:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 26 Nov 2014 16:55:35 +0000
Message-ID: <1417020935-2934-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Content-Length: 5265
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH for-4.6] libxl,
	hotplug/Linux: default to phy backend for raw format file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TW9kaWZ5IGxpYnhsIGFuZCBob3RwbHVnIHNjcmlwdCB0byBhbGxvdyByYXcgZm9ybWF0IGZpbGUg
dG8gdXNlIHBoeQpiYWNrZW5kLgoKVGhlIGJsb2NrIHNjcmlwdCBub3cgdGVzdHMgdGhlIHBhdGgg
YW5kIGRldGVybWluZSB0aGUgYWN0dWFsIHR5cGUgb2YKZmlsZSAoYmxvY2sgZGV2aWNlIG9yIHJl
Z3VsYXIgZmlsZSkgdGhlbiB1c2UgdGhlIGFjdHVhbCB0eXBlIHRvCmRldGVybWluZSB3aGljaCBi
cmFuY2ggdG8gcnVuLgoKV2l0aCB0aGVzZSBjaGFuZ2VzLCBwbHVzIHRoZSBjdXJyZW50IG9yZGVy
aW5nIG9mIGJhY2tlbmQgcHJlZmVyZW5jZSAocGh5Cj4gcWRpc2sgPiB0YXApLCB3ZSB3aWxsIHVz
ZSBwaHkgYmFja2VuZCBmb3IgcmF3IGZvcm1hdCBmaWxlIGJ5IGRlZmF1bHQuCgpTaWduZWQtb2Zm
LWJ5OiBXZWkgTGl1IDx3ZWkubGl1MkBjaXRyaXguY29tPgpDYzogSWFuIENhbXBiZWxsIDxpYW4u
Y2FtcGJlbGxAY2l0cml4LmNvbT4KQ2M6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFi
ZWxsaW5pQGV1LmNpdHJpeC5jb20+CkNjOiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0
cml4LmNvbT4KQ2M6IElhbiBKYWNrc29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgotLS0K
IHRvb2xzL2hvdHBsdWcvTGludXgvYmxvY2sgIHwgICAxNiArKysrKysrKystLS0tLS0tCiB0b29s
cy9saWJ4bC9saWJ4bC5jICAgICAgICB8ICAgIDYgKysrLS0tCiB0b29scy9saWJ4bC9saWJ4bF9k
ZXZpY2UuYyB8ICAgIDIgKysKIHRvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMgIHwgICAgNiArKyst
LS0KIDQgZmlsZXMgY2hhbmdlZCwgMTcgaW5zZXJ0aW9ucygrKSwgMTMgZGVsZXRpb25zKC0pCgpk
aWZmIC0tZ2l0IGEvdG9vbHMvaG90cGx1Zy9MaW51eC9ibG9jayBiL3Rvb2xzL2hvdHBsdWcvTGlu
dXgvYmxvY2sKaW5kZXggZGEyNmUyMi4uOGQyZWU5ZCAxMDA2NDQKLS0tIGEvdG9vbHMvaG90cGx1
Zy9MaW51eC9ibG9jaworKysgYi90b29scy9ob3RwbHVnL0xpbnV4L2Jsb2NrCkBAIC0yMDYsNiAr
MjA2LDEzIEBAIGFuZCBzbyBjYW5ub3QgYmUgbW91bnRlZCAke20yfSR7d2hlbn0uIgogCiAKIHQ9
JCh4ZW5zdG9yZV9yZWFkX2RlZmF1bHQgIiRYRU5CVVNfUEFUSC90eXBlIiAnTUlTU0lORycpCitw
PSQoeGVuc3RvcmVfcmVhZCAiJFhFTkJVU19QQVRIL3BhcmFtcyIpCittb2RlPSQoeGVuc3RvcmVf
cmVhZCAiJFhFTkJVU19QQVRIL21vZGUiKQoraWYgWyAtYiAiJHAiIF07IHRoZW4KKyAgICB0cnVl
dHlwZT0icGh5IgorZWxpZiBbIC1mICIkcCIgXTsgdGhlbgorICAgIHRydWV0eXBlPSJmaWxlIgor
ZmkKIAogY2FzZSAiJGNvbW1hbmQiIGluCiAgIGFkZCkKQEAgLTIxNywxNiArMjI0LDExIEBAIGNh
c2UgIiRjb21tYW5kIiBpbgogICAgICAgZXhpdCAwCiAgICAgZmkKIAotICAgIGlmIFsgLW4gIiR0
IiBdCi0gICAgdGhlbgotICAgICAgcD0kKHhlbnN0b3JlX3JlYWQgIiRYRU5CVVNfUEFUSC9wYXJh
bXMiKQotICAgICAgbW9kZT0kKHhlbnN0b3JlX3JlYWQgIiRYRU5CVVNfUEFUSC9tb2RlIikKLSAg
ICBmaQogICAgIEZST05URU5EX0lEPSQoeGVuc3RvcmVfcmVhZCAiJFhFTkJVU19QQVRIL2Zyb250
ZW5kLWlkIikKICAgICBGUk9OVEVORF9VVUlEPSQoeGVuc3RvcmVfcmVhZF9kZWZhdWx0IFwKICAg
ICAgICAgICAgICIvbG9jYWwvZG9tYWluLyRGUk9OVEVORF9JRC92bSIgJ3Vua25vd24nKQogCi0g
ICAgY2FzZSAkdCBpbiAKKyAgICBjYXNlICR0cnVldHlwZSBpbgogICAgICAgcGh5KQogICAgICAg
ICBkZXY9JChleHBhbmRfZGV2ICRwKQogCkBAIC0zMTksNyArMzIxLDcgQEAgbW91bnQgaXQgcmVh
ZC13cml0ZSBpbiBhIGd1ZXN0IGRvbWFpbi4iCiAgICAgOzsKIAogICByZW1vdmUpCi0gICAgY2Fz
ZSAkdCBpbiAKKyAgICBjYXNlICR0cnVldHlwZSBpbgogICAgICAgcGh5KQogCWV4aXQgMAogCTs7
CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bC5jIGIvdG9vbHMvbGlieGwvbGlieGwuYwpp
bmRleCBkZTIzZmVjLi43Y2UxYmM0IDEwMDY0NAotLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCisr
KyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMKQEAgLTIzOTIsOSArMjM5Miw5IEBAIHN0YXRpYyB2b2lk
IGRldmljZV9kaXNrX2FkZChsaWJ4bF9fZWdjICplZ2MsIHVpbnQzMl90IGRvbWlkLAogICAgICAg
ICAgICAgICAgIGlmICghZGlzay0+c2NyaXB0ICYmCiAgICAgICAgICAgICAgICAgICAgIGRpc2st
PmJhY2tlbmRfZG9taWQgPT0gTElCWExfVE9PTFNUQUNLX0RPTUlEKSB7CiAgICAgICAgICAgICAg
ICAgICAgIGludCBtYWpvciwgbWlub3I7Ci0gICAgICAgICAgICAgICAgICAgIGxpYnhsX19kZXZp
Y2VfcGh5c2Rpc2tfbWFqb3JfbWlub3IoZGV2LCAmbWFqb3IsICZtaW5vcik7Ci0gICAgICAgICAg
ICAgICAgICAgIGZsZXhhcnJheV9hcHBlbmRfcGFpcihiYWNrLCAicGh5c2ljYWwtZGV2aWNlIiwK
LSAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9fc3ByaW50ZihnYywgIiV4OiV4Iiwg
bWFqb3IsIG1pbm9yKSk7CisgICAgICAgICAgICAgICAgICAgIGlmICghbGlieGxfX2RldmljZV9w
aHlzZGlza19tYWpvcl9taW5vcihkZXYsICZtYWpvciwgJm1pbm9yKSkKKyAgICAgICAgICAgICAg
ICAgICAgICAgIGZsZXhhcnJheV9hcHBlbmRfcGFpcihiYWNrLCAicGh5c2ljYWwtZGV2aWNlIiwK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9fc3By
aW50ZihnYywgIiV4OiV4IiwgbWFqb3IsIG1pbm9yKSk7CiAgICAgICAgICAgICAgICAgfQogCiAg
ICAgICAgICAgICAgICAgYXNzZXJ0KGRldmljZS0+YmFja2VuZF9raW5kID09IExJQlhMX19ERVZJ
Q0VfS0lORF9WQkQpOwpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZGV2aWNlLmMgYi90
b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYwppbmRleCA0YjUxZGVkLi4wZjUwZDA0IDEwMDY0NAot
LS0gYS90b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYworKysgYi90b29scy9saWJ4bC9saWJ4bF9k
ZXZpY2UuYwpAQCAtMzMyLDYgKzMzMiw4IEBAIGludCBsaWJ4bF9fZGV2aWNlX3BoeXNkaXNrX21h
am9yX21pbm9yKGNvbnN0IGNoYXIgKnBoeXNwYXRoLCBpbnQgKm1ham9yLCBpbnQgKm1pCiAgICAg
c3RydWN0IHN0YXQgYnVmOwogICAgIGlmIChzdGF0KHBoeXNwYXRoLCAmYnVmKSA8IDApCiAgICAg
ICAgIHJldHVybiAtMTsKKyAgICBpZiAoIVNfSVNCTEsoYnVmLnN0X21vZGUpKQorICAgICAgICBy
ZXR1cm4gLTE7CiAgICAgKm1ham9yID0gbWFqb3IoYnVmLnN0X3JkZXYpOwogICAgICptaW5vciA9
IG1pbm9yKGJ1Zi5zdF9yZGV2KTsKICAgICByZXR1cm4gMDsKZGlmZiAtLWdpdCBhL3Rvb2xzL2xp
YnhsL2xpYnhsX2xpbnV4LmMgYi90b29scy9saWJ4bC9saWJ4bF9saW51eC5jCmluZGV4IGVhNWQ4
YzEuLmI1MTkzMGMgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKKysrIGIv
dG9vbHMvbGlieGwvbGlieGxfbGludXguYwpAQCAtMTksMTEgKzE5LDExIEBACiAgCiBpbnQgbGli
eGxfX3RyeV9waHlfYmFja2VuZChtb2RlX3Qgc3RfbW9kZSkKIHsKLSAgICBpZiAoIVNfSVNCTEso
c3RfbW9kZSkpIHsKLSAgICAgICAgcmV0dXJuIDA7CisgICAgaWYgKFNfSVNCTEsoc3RfbW9kZSkg
fHwgU19JU1JFRyhzdF9tb2RlKSkgeworICAgICAgICByZXR1cm4gMTsKICAgICB9CiAKLSAgICBy
ZXR1cm4gMTsKKyAgICByZXR1cm4gMDsKIH0KIAogI2RlZmluZSBFWFRfU0hJRlQgMjgKLS0gCjEu
Ny4xMC40CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Nov 26 16:55:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 16: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 1XtfsT-0003ir-En; Wed, 26 Nov 2014 16:55: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 1XtfsS-0003ij-0W
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 16:55:40 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	4A/E1-24859-B0606745; Wed, 26 Nov 2014 16:55:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417020937!14014785!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6520 invoked from network); 26 Nov 2014 16:55:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 16:55:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="197100427"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 11:55:35 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XtfsN-0004dF-JW;
	Wed, 26 Nov 2014 16:55:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 26 Nov 2014 16:55:35 +0000
Message-ID: <1417020935-2934-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Content-Length: 5265
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH for-4.6] libxl,
	hotplug/Linux: default to phy backend for raw format file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TW9kaWZ5IGxpYnhsIGFuZCBob3RwbHVnIHNjcmlwdCB0byBhbGxvdyByYXcgZm9ybWF0IGZpbGUg
dG8gdXNlIHBoeQpiYWNrZW5kLgoKVGhlIGJsb2NrIHNjcmlwdCBub3cgdGVzdHMgdGhlIHBhdGgg
YW5kIGRldGVybWluZSB0aGUgYWN0dWFsIHR5cGUgb2YKZmlsZSAoYmxvY2sgZGV2aWNlIG9yIHJl
Z3VsYXIgZmlsZSkgdGhlbiB1c2UgdGhlIGFjdHVhbCB0eXBlIHRvCmRldGVybWluZSB3aGljaCBi
cmFuY2ggdG8gcnVuLgoKV2l0aCB0aGVzZSBjaGFuZ2VzLCBwbHVzIHRoZSBjdXJyZW50IG9yZGVy
aW5nIG9mIGJhY2tlbmQgcHJlZmVyZW5jZSAocGh5Cj4gcWRpc2sgPiB0YXApLCB3ZSB3aWxsIHVz
ZSBwaHkgYmFja2VuZCBmb3IgcmF3IGZvcm1hdCBmaWxlIGJ5IGRlZmF1bHQuCgpTaWduZWQtb2Zm
LWJ5OiBXZWkgTGl1IDx3ZWkubGl1MkBjaXRyaXguY29tPgpDYzogSWFuIENhbXBiZWxsIDxpYW4u
Y2FtcGJlbGxAY2l0cml4LmNvbT4KQ2M6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFi
ZWxsaW5pQGV1LmNpdHJpeC5jb20+CkNjOiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0
cml4LmNvbT4KQ2M6IElhbiBKYWNrc29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgotLS0K
IHRvb2xzL2hvdHBsdWcvTGludXgvYmxvY2sgIHwgICAxNiArKysrKysrKystLS0tLS0tCiB0b29s
cy9saWJ4bC9saWJ4bC5jICAgICAgICB8ICAgIDYgKysrLS0tCiB0b29scy9saWJ4bC9saWJ4bF9k
ZXZpY2UuYyB8ICAgIDIgKysKIHRvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMgIHwgICAgNiArKyst
LS0KIDQgZmlsZXMgY2hhbmdlZCwgMTcgaW5zZXJ0aW9ucygrKSwgMTMgZGVsZXRpb25zKC0pCgpk
aWZmIC0tZ2l0IGEvdG9vbHMvaG90cGx1Zy9MaW51eC9ibG9jayBiL3Rvb2xzL2hvdHBsdWcvTGlu
dXgvYmxvY2sKaW5kZXggZGEyNmUyMi4uOGQyZWU5ZCAxMDA2NDQKLS0tIGEvdG9vbHMvaG90cGx1
Zy9MaW51eC9ibG9jaworKysgYi90b29scy9ob3RwbHVnL0xpbnV4L2Jsb2NrCkBAIC0yMDYsNiAr
MjA2LDEzIEBAIGFuZCBzbyBjYW5ub3QgYmUgbW91bnRlZCAke20yfSR7d2hlbn0uIgogCiAKIHQ9
JCh4ZW5zdG9yZV9yZWFkX2RlZmF1bHQgIiRYRU5CVVNfUEFUSC90eXBlIiAnTUlTU0lORycpCitw
PSQoeGVuc3RvcmVfcmVhZCAiJFhFTkJVU19QQVRIL3BhcmFtcyIpCittb2RlPSQoeGVuc3RvcmVf
cmVhZCAiJFhFTkJVU19QQVRIL21vZGUiKQoraWYgWyAtYiAiJHAiIF07IHRoZW4KKyAgICB0cnVl
dHlwZT0icGh5IgorZWxpZiBbIC1mICIkcCIgXTsgdGhlbgorICAgIHRydWV0eXBlPSJmaWxlIgor
ZmkKIAogY2FzZSAiJGNvbW1hbmQiIGluCiAgIGFkZCkKQEAgLTIxNywxNiArMjI0LDExIEBAIGNh
c2UgIiRjb21tYW5kIiBpbgogICAgICAgZXhpdCAwCiAgICAgZmkKIAotICAgIGlmIFsgLW4gIiR0
IiBdCi0gICAgdGhlbgotICAgICAgcD0kKHhlbnN0b3JlX3JlYWQgIiRYRU5CVVNfUEFUSC9wYXJh
bXMiKQotICAgICAgbW9kZT0kKHhlbnN0b3JlX3JlYWQgIiRYRU5CVVNfUEFUSC9tb2RlIikKLSAg
ICBmaQogICAgIEZST05URU5EX0lEPSQoeGVuc3RvcmVfcmVhZCAiJFhFTkJVU19QQVRIL2Zyb250
ZW5kLWlkIikKICAgICBGUk9OVEVORF9VVUlEPSQoeGVuc3RvcmVfcmVhZF9kZWZhdWx0IFwKICAg
ICAgICAgICAgICIvbG9jYWwvZG9tYWluLyRGUk9OVEVORF9JRC92bSIgJ3Vua25vd24nKQogCi0g
ICAgY2FzZSAkdCBpbiAKKyAgICBjYXNlICR0cnVldHlwZSBpbgogICAgICAgcGh5KQogICAgICAg
ICBkZXY9JChleHBhbmRfZGV2ICRwKQogCkBAIC0zMTksNyArMzIxLDcgQEAgbW91bnQgaXQgcmVh
ZC13cml0ZSBpbiBhIGd1ZXN0IGRvbWFpbi4iCiAgICAgOzsKIAogICByZW1vdmUpCi0gICAgY2Fz
ZSAkdCBpbiAKKyAgICBjYXNlICR0cnVldHlwZSBpbgogICAgICAgcGh5KQogCWV4aXQgMAogCTs7
CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bC5jIGIvdG9vbHMvbGlieGwvbGlieGwuYwpp
bmRleCBkZTIzZmVjLi43Y2UxYmM0IDEwMDY0NAotLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCisr
KyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMKQEAgLTIzOTIsOSArMjM5Miw5IEBAIHN0YXRpYyB2b2lk
IGRldmljZV9kaXNrX2FkZChsaWJ4bF9fZWdjICplZ2MsIHVpbnQzMl90IGRvbWlkLAogICAgICAg
ICAgICAgICAgIGlmICghZGlzay0+c2NyaXB0ICYmCiAgICAgICAgICAgICAgICAgICAgIGRpc2st
PmJhY2tlbmRfZG9taWQgPT0gTElCWExfVE9PTFNUQUNLX0RPTUlEKSB7CiAgICAgICAgICAgICAg
ICAgICAgIGludCBtYWpvciwgbWlub3I7Ci0gICAgICAgICAgICAgICAgICAgIGxpYnhsX19kZXZp
Y2VfcGh5c2Rpc2tfbWFqb3JfbWlub3IoZGV2LCAmbWFqb3IsICZtaW5vcik7Ci0gICAgICAgICAg
ICAgICAgICAgIGZsZXhhcnJheV9hcHBlbmRfcGFpcihiYWNrLCAicGh5c2ljYWwtZGV2aWNlIiwK
LSAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9fc3ByaW50ZihnYywgIiV4OiV4Iiwg
bWFqb3IsIG1pbm9yKSk7CisgICAgICAgICAgICAgICAgICAgIGlmICghbGlieGxfX2RldmljZV9w
aHlzZGlza19tYWpvcl9taW5vcihkZXYsICZtYWpvciwgJm1pbm9yKSkKKyAgICAgICAgICAgICAg
ICAgICAgICAgIGZsZXhhcnJheV9hcHBlbmRfcGFpcihiYWNrLCAicGh5c2ljYWwtZGV2aWNlIiwK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9fc3By
aW50ZihnYywgIiV4OiV4IiwgbWFqb3IsIG1pbm9yKSk7CiAgICAgICAgICAgICAgICAgfQogCiAg
ICAgICAgICAgICAgICAgYXNzZXJ0KGRldmljZS0+YmFja2VuZF9raW5kID09IExJQlhMX19ERVZJ
Q0VfS0lORF9WQkQpOwpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZGV2aWNlLmMgYi90
b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYwppbmRleCA0YjUxZGVkLi4wZjUwZDA0IDEwMDY0NAot
LS0gYS90b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYworKysgYi90b29scy9saWJ4bC9saWJ4bF9k
ZXZpY2UuYwpAQCAtMzMyLDYgKzMzMiw4IEBAIGludCBsaWJ4bF9fZGV2aWNlX3BoeXNkaXNrX21h
am9yX21pbm9yKGNvbnN0IGNoYXIgKnBoeXNwYXRoLCBpbnQgKm1ham9yLCBpbnQgKm1pCiAgICAg
c3RydWN0IHN0YXQgYnVmOwogICAgIGlmIChzdGF0KHBoeXNwYXRoLCAmYnVmKSA8IDApCiAgICAg
ICAgIHJldHVybiAtMTsKKyAgICBpZiAoIVNfSVNCTEsoYnVmLnN0X21vZGUpKQorICAgICAgICBy
ZXR1cm4gLTE7CiAgICAgKm1ham9yID0gbWFqb3IoYnVmLnN0X3JkZXYpOwogICAgICptaW5vciA9
IG1pbm9yKGJ1Zi5zdF9yZGV2KTsKICAgICByZXR1cm4gMDsKZGlmZiAtLWdpdCBhL3Rvb2xzL2xp
YnhsL2xpYnhsX2xpbnV4LmMgYi90b29scy9saWJ4bC9saWJ4bF9saW51eC5jCmluZGV4IGVhNWQ4
YzEuLmI1MTkzMGMgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKKysrIGIv
dG9vbHMvbGlieGwvbGlieGxfbGludXguYwpAQCAtMTksMTEgKzE5LDExIEBACiAgCiBpbnQgbGli
eGxfX3RyeV9waHlfYmFja2VuZChtb2RlX3Qgc3RfbW9kZSkKIHsKLSAgICBpZiAoIVNfSVNCTEso
c3RfbW9kZSkpIHsKLSAgICAgICAgcmV0dXJuIDA7CisgICAgaWYgKFNfSVNCTEsoc3RfbW9kZSkg
fHwgU19JU1JFRyhzdF9tb2RlKSkgeworICAgICAgICByZXR1cm4gMTsKICAgICB9CiAKLSAgICBy
ZXR1cm4gMTsKKyAgICByZXR1cm4gMDsKIH0KIAogI2RlZmluZSBFWFRfU0hJRlQgMjgKLS0gCjEu
Ny4xMC40CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:19:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:19:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtgF5-0004CB-Gv; Wed, 26 Nov 2014 17:19:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtgF4-0004C6-V1
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 17:19:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	11/5C-09842-68B06745; Wed, 26 Nov 2014 17:19:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417022340!15217385!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12028 invoked from network); 26 Nov 2014 17:19:01 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 17:19:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQHIu8S029543
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 17:18:57 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQHItWu003819
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 17:18:55 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQHIsgd027807; Wed, 26 Nov 2014 17:18:54 GMT
Message-Id: <201411261718.sAQHIsgd027807@aserz7022.oracle.com>
Received: from [IPv6:2607:fb90:2903:f7ec:49a4:cbd4:11c0:8e66] (/172.56.23.123)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 09:18:54 -0800
Date: Wed, 26 Nov 2014 12:18:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
MIME-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen-pciback: Add MODULE_ALIAS for pciback.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ck9uIE5vdiAyNiwgMjAxNCAxMTozOSBBTSwgIkx1aXMgUi4gUm9kcmlndWV6IiA8bWNncm9mQGRv
LW5vdC1wYW5pYy5jb20+IHdyb3RlOgo+Cj4gT24gV2VkLCBBdWcgMjAsIDIwMTQgYXQgMToyNiBQ
TSwgSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4gd3JvdGU6IAo+ID4gT24g
V2VkLCAyMDE0LTA4LTIwIGF0IDEzOjIwIC0wNDAwLCBLb25yYWQgUnplc3p1dGVrIFdpbGsgd3Jv
dGU6IAo+ID4+IE9uIFdlZCwgQXVnIDIwLCAyMDE0IGF0IDA2OjE4OjUyUE0gKzAxMDAsIElhbiBD
YW1wYmVsbCB3cm90ZTogCj4gPj4gPiBPbiBXZWQsIDIwMTQtMDgtMjAgYXQgMTI6NDAgLTA0MDAs
IEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZTogCj4gPj4gPiA+IFRoZSByZXN0IG9mIHRoZSBY
ZW4gZGV2aWNlIGRyaXZlcnMgdXNlIGFuIG1vZHVsZSBhbGlhcyAKPiA+PiA+ID4gdG8gbG9hZCBk
ZXZpY2VzIHdoZW4gdGhleSBzaG9wIHVwIGluIFhlbkJ1cy4gCj4gPj4gPiAKPiA+PiA+ICJzaG93
Ii4gCj4gPj4gPiA+IAo+ID4+ID4gPsKgIE1PRFVMRV9MSUNFTlNFKCJEdWFsIEJTRC9HUEwiKTsg
Cj4gPj4gPiA+wqAgTU9EVUxFX0FMSUFTKCJ4ZW4tYmFja2VuZDpwY2kiKTsgCj4gPj4gPiA+ICtN
T0RVTEVfQUxJQVMoInhlbjpwY2kiKTsgCj4gPj4gPiAKPiA+PiA+IElzbid0IHRoYXQgeGVuLWJh
Y2tlbmQ6cGNpIGFscmVhZHkgdGhlIHJpZ2h0IHRoaW5nIGZvciBhIGJhY2tlbmQgZGV2aWNlPyAK
PiA+PiA+IHhlbjogaXMgZm9yIGZyb250ZW5kcywgSSB0aG91Z2h0LiAKPiA+PiAKPiA+PiBPaCwg
eW91IGFyZSByaWdodC4gQ29vbCEgVGhhbmtzISAKPiA+IAo+ID4gVGhlIHBhdGNoIHR1cm5lZCBv
dXQgdG8gYmUgZXZlbiBtb3JlIHRyaXZpYWwgdGhhbiBleHBlY3RlZCA7LSkgCj4KPiBJcyB0aGlz
IHdoYXQgd2UgZXhwZWN0ZWQgdG8gYmUgcGVuZGluZyB3b3JrIGZvciB0aGUgaXRlbSAiZGV2aWNl
IAo+IGhvdHBsdWcgKE1PRFVMRV9BTElBUykiIG9uIHRoZSB1cHN0cmVhbSBUT0RPIGxpc3Q/IAo+
Cj4gaHR0cDovL3dpa2kueGVucHJvamVjdC5vcmcvd2lraS9YZW5QYXJhdmlydE9wcyNVcHN0cmVh
bV9kZWx0YV9kZXRhaWxzIAo+Cj4gVGhpcyB3YXMgc2ltcGx5IHRvIGp1c3QgYXV0byBsb2FkIHRo
YXQgZHJpdmVyIHdoZW4gbmVlZGVkIHJpZ2h0PyAKPgoKUmlnaHQgd2hpY2ggaXQgZG9lcyBub3cu
Cgo+IEFsc28gYXMgZm9yIGFjdHVhbCBQQ0kgZGV2aWNlIGhvdHBsdWcgc3VwcG9ydDogCj4KPiBo
dHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuX1BDSV9QYXNzdGhyb3VnaCNIb3RwbHVnIAo+Cj4g
SSBkb24ndCB0aGluayB3ZSBuZWVkIGEgZGVsdGEgZm9yIHRoYXQgZG8gd2U/IAoKTm9wZS4gVGhp
cyBvbmUgaXMgYWxsIGRvbmUuCj4KPiBMdWlzIApfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:19:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:19:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtgF5-0004CB-Gv; Wed, 26 Nov 2014 17:19:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XtgF4-0004C6-V1
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 17:19:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	11/5C-09842-68B06745; Wed, 26 Nov 2014 17:19:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417022340!15217385!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12028 invoked from network); 26 Nov 2014 17:19:01 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 17:19:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQHIu8S029543
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 17:18:57 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQHItWu003819
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 17:18:55 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQHIsgd027807; Wed, 26 Nov 2014 17:18:54 GMT
Message-Id: <201411261718.sAQHIsgd027807@aserz7022.oracle.com>
Received: from [IPv6:2607:fb90:2903:f7ec:49a4:cbd4:11c0:8e66] (/172.56.23.123)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 09:18:54 -0800
Date: Wed, 26 Nov 2014 12:18:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
MIME-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen-pciback: Add MODULE_ALIAS for pciback.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ck9uIE5vdiAyNiwgMjAxNCAxMTozOSBBTSwgIkx1aXMgUi4gUm9kcmlndWV6IiA8bWNncm9mQGRv
LW5vdC1wYW5pYy5jb20+IHdyb3RlOgo+Cj4gT24gV2VkLCBBdWcgMjAsIDIwMTQgYXQgMToyNiBQ
TSwgSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4gd3JvdGU6IAo+ID4gT24g
V2VkLCAyMDE0LTA4LTIwIGF0IDEzOjIwIC0wNDAwLCBLb25yYWQgUnplc3p1dGVrIFdpbGsgd3Jv
dGU6IAo+ID4+IE9uIFdlZCwgQXVnIDIwLCAyMDE0IGF0IDA2OjE4OjUyUE0gKzAxMDAsIElhbiBD
YW1wYmVsbCB3cm90ZTogCj4gPj4gPiBPbiBXZWQsIDIwMTQtMDgtMjAgYXQgMTI6NDAgLTA0MDAs
IEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZTogCj4gPj4gPiA+IFRoZSByZXN0IG9mIHRoZSBY
ZW4gZGV2aWNlIGRyaXZlcnMgdXNlIGFuIG1vZHVsZSBhbGlhcyAKPiA+PiA+ID4gdG8gbG9hZCBk
ZXZpY2VzIHdoZW4gdGhleSBzaG9wIHVwIGluIFhlbkJ1cy4gCj4gPj4gPiAKPiA+PiA+ICJzaG93
Ii4gCj4gPj4gPiA+IAo+ID4+ID4gPsKgIE1PRFVMRV9MSUNFTlNFKCJEdWFsIEJTRC9HUEwiKTsg
Cj4gPj4gPiA+wqAgTU9EVUxFX0FMSUFTKCJ4ZW4tYmFja2VuZDpwY2kiKTsgCj4gPj4gPiA+ICtN
T0RVTEVfQUxJQVMoInhlbjpwY2kiKTsgCj4gPj4gPiAKPiA+PiA+IElzbid0IHRoYXQgeGVuLWJh
Y2tlbmQ6cGNpIGFscmVhZHkgdGhlIHJpZ2h0IHRoaW5nIGZvciBhIGJhY2tlbmQgZGV2aWNlPyAK
PiA+PiA+IHhlbjogaXMgZm9yIGZyb250ZW5kcywgSSB0aG91Z2h0LiAKPiA+PiAKPiA+PiBPaCwg
eW91IGFyZSByaWdodC4gQ29vbCEgVGhhbmtzISAKPiA+IAo+ID4gVGhlIHBhdGNoIHR1cm5lZCBv
dXQgdG8gYmUgZXZlbiBtb3JlIHRyaXZpYWwgdGhhbiBleHBlY3RlZCA7LSkgCj4KPiBJcyB0aGlz
IHdoYXQgd2UgZXhwZWN0ZWQgdG8gYmUgcGVuZGluZyB3b3JrIGZvciB0aGUgaXRlbSAiZGV2aWNl
IAo+IGhvdHBsdWcgKE1PRFVMRV9BTElBUykiIG9uIHRoZSB1cHN0cmVhbSBUT0RPIGxpc3Q/IAo+
Cj4gaHR0cDovL3dpa2kueGVucHJvamVjdC5vcmcvd2lraS9YZW5QYXJhdmlydE9wcyNVcHN0cmVh
bV9kZWx0YV9kZXRhaWxzIAo+Cj4gVGhpcyB3YXMgc2ltcGx5IHRvIGp1c3QgYXV0byBsb2FkIHRo
YXQgZHJpdmVyIHdoZW4gbmVlZGVkIHJpZ2h0PyAKPgoKUmlnaHQgd2hpY2ggaXQgZG9lcyBub3cu
Cgo+IEFsc28gYXMgZm9yIGFjdHVhbCBQQ0kgZGV2aWNlIGhvdHBsdWcgc3VwcG9ydDogCj4KPiBo
dHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuX1BDSV9QYXNzdGhyb3VnaCNIb3RwbHVnIAo+Cj4g
SSBkb24ndCB0aGluayB3ZSBuZWVkIGEgZGVsdGEgZm9yIHRoYXQgZG8gd2U/IAoKTm9wZS4gVGhp
cyBvbmUgaXMgYWxsIGRvbmUuCj4KPiBMdWlzIApfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:23:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17: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 1XtgIz-0004Jb-68; Wed, 26 Nov 2014 17:23:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtgIy-0004JU-At
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:23:04 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	08/68-02576-77C06745; Wed, 26 Nov 2014 17:23:03 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417022581!9655051!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4103 invoked from network); 26 Nov 2014 17:23:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:23:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="196864437"
Message-ID: <54760C56.3050907@citrix.com>
Date: Wed, 26 Nov 2014 17:22:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
References: <5474DE5A.2060000@citrix.com>
	<1417020283.11944.65.camel@citrix.com>
In-Reply-To: <1417020283.11944.65.camel@citrix.com>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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 26/11/14 16:44, Ian Campbell wrote:
> On Tue, 2014-11-25 at 19:54 +0000, Andrew Cooper wrote:
>> There is an xl/libxl part of the migration v2 series which attempts to
>> rectify this all in one go, as there is no alternative way of doing so. 
>> The libxl section of the series is certainly not yet complete, but
>> specific queries to the maintainers have thusfar gone unanswered.  On
>> the other hand, the series does basically WorkForMe, including
>> transparent legacy upgrade, suggesting that it is at least in an
>> appropriate ballpark.
> Is this, from "[PATCH 27/29] [VERY RFC] tools/libxl: Support restoring
> legacy streams":
>
>         This WorksForMe in the success case, but the error handling is certainly lacking.
>         
>         Specifically, the conversion scripts output fd can't be closed until the v2
>         read loop has exited (cleanly or otherwise), without risking a close()/open()
>         race silently replacing the fd behind the loops back.
>         
>         However, it can't be closed when the read loop exits, as the conversion script
>         child might still be alive, and would prefer terminating cleaning than failing
>         with a bad FD.
>         
>         Obviously, having one error handler block for the success/failure of the other
>         side is a no-go, and would still involve a preselecting which was expected to
>         exit first.
>         
>         Does anyone have any clever ideas of how to asynchronously collect the events
>         "the conversion script has exited", "the save helper has exited" and "the v2
>         read loop has finished" given the available infrastructure, to kick of a
>         combined cleanup of all 3?
>
> ? I said then:
>         
>         This is probably one for Ian when he gets back, but a state machine
>         which is cranked in response to the callbacks from the various
>         completion events might be one way to approach this.
>         
> Prodding Ian again (by moving to the To: line...)
>
> Was there any other questions? I've had a scrobble through the bit of v7
> which 00/29 suggests might contain them, but that's the only one I saw.

I think that was the main one.  To the best of my understanding, there
is nowhere else in libxl which currently does multiple child management.

There were some other questions about the datacopier stuff, but that has
changed given the remus libxl changed.  I am happy for those to be
deferred by one iteration of the series and see what falls out in the wash.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:23:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17: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 1XtgIz-0004Jb-68; Wed, 26 Nov 2014 17:23:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtgIy-0004JU-At
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:23:04 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	08/68-02576-77C06745; Wed, 26 Nov 2014 17:23:03 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417022581!9655051!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4103 invoked from network); 26 Nov 2014 17:23:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:23:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="196864437"
Message-ID: <54760C56.3050907@citrix.com>
Date: Wed, 26 Nov 2014 17:22:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
References: <5474DE5A.2060000@citrix.com>
	<1417020283.11944.65.camel@citrix.com>
In-Reply-To: <1417020283.11944.65.camel@citrix.com>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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 26/11/14 16:44, Ian Campbell wrote:
> On Tue, 2014-11-25 at 19:54 +0000, Andrew Cooper wrote:
>> There is an xl/libxl part of the migration v2 series which attempts to
>> rectify this all in one go, as there is no alternative way of doing so. 
>> The libxl section of the series is certainly not yet complete, but
>> specific queries to the maintainers have thusfar gone unanswered.  On
>> the other hand, the series does basically WorkForMe, including
>> transparent legacy upgrade, suggesting that it is at least in an
>> appropriate ballpark.
> Is this, from "[PATCH 27/29] [VERY RFC] tools/libxl: Support restoring
> legacy streams":
>
>         This WorksForMe in the success case, but the error handling is certainly lacking.
>         
>         Specifically, the conversion scripts output fd can't be closed until the v2
>         read loop has exited (cleanly or otherwise), without risking a close()/open()
>         race silently replacing the fd behind the loops back.
>         
>         However, it can't be closed when the read loop exits, as the conversion script
>         child might still be alive, and would prefer terminating cleaning than failing
>         with a bad FD.
>         
>         Obviously, having one error handler block for the success/failure of the other
>         side is a no-go, and would still involve a preselecting which was expected to
>         exit first.
>         
>         Does anyone have any clever ideas of how to asynchronously collect the events
>         "the conversion script has exited", "the save helper has exited" and "the v2
>         read loop has finished" given the available infrastructure, to kick of a
>         combined cleanup of all 3?
>
> ? I said then:
>         
>         This is probably one for Ian when he gets back, but a state machine
>         which is cranked in response to the callbacks from the various
>         completion events might be one way to approach this.
>         
> Prodding Ian again (by moving to the To: line...)
>
> Was there any other questions? I've had a scrobble through the bit of v7
> which 00/29 suggests might contain them, but that's the only one I saw.

I think that was the main one.  To the best of my understanding, there
is nowhere else in libxl which currently does multiple child management.

There were some other questions about the datacopier stuff, but that has
changed given the remus libxl changed.  I am happy for those to be
deferred by one iteration of the series and see what falls out in the wash.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:28:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtgO1-0004a1-UA; Wed, 26 Nov 2014 17:28:17 +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 1XtgO0-0004Zw-RZ
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 17:28:16 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	66/70-20609-0BD06745; Wed, 26 Nov 2014 17:28:16 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417022894!15074939!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2457 invoked from network); 26 Nov 2014 17:28:14 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-14.tower-27.messagelabs.com with SMTP;
	26 Nov 2014 17:28:14 -0000
Received: from localhost (cpe-67-247-12-89.nyc.res.rr.com [67.247.12.89])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 099705822A7;
	Wed, 26 Nov 2014 09:28:12 -0800 (PST)
Date: Wed, 26 Nov 2014 12:28:12 -0500 (EST)
Message-Id: <20141126.122812.223757363894961994.davem@davemloft.net>
To: seth.forshee@canonical.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
References: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Wed, 26 Nov 2014 09:28:14 -0800 (PST)
Cc: zoltan.kiss@linaro.org, eric.dumazet@gmail.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Remove BUGs on paged skb data
 which crosses a page boundary
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Seth Forshee <seth.forshee@canonical.com>
Date: Tue, 25 Nov 2014 20:28:24 -0600

> These BUGs can be erroneously triggered by frags which refer to
> tail pages within a compound page. The data in these pages may
> overrun the hardware page while still being contained within the
> compound page, but since compound_order() evaluates to 0 for tail
> pages the assertion fails. The code already iterates through
> subsequent pages correctly in this scenario, so the BUGs are
> unnecessary and can be removed.
> 
> Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
> Cc: <stable@vger.kernel.org> # 3.7+
> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

Can I get some Xen developer reviews?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:28:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtgO1-0004a1-UA; Wed, 26 Nov 2014 17:28:17 +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 1XtgO0-0004Zw-RZ
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 17:28:16 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	66/70-20609-0BD06745; Wed, 26 Nov 2014 17:28:16 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417022894!15074939!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2457 invoked from network); 26 Nov 2014 17:28:14 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-14.tower-27.messagelabs.com with SMTP;
	26 Nov 2014 17:28:14 -0000
Received: from localhost (cpe-67-247-12-89.nyc.res.rr.com [67.247.12.89])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 099705822A7;
	Wed, 26 Nov 2014 09:28:12 -0800 (PST)
Date: Wed, 26 Nov 2014 12:28:12 -0500 (EST)
Message-Id: <20141126.122812.223757363894961994.davem@davemloft.net>
To: seth.forshee@canonical.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
References: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Wed, 26 Nov 2014 09:28:14 -0800 (PST)
Cc: zoltan.kiss@linaro.org, eric.dumazet@gmail.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Remove BUGs on paged skb data
 which crosses a page boundary
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Seth Forshee <seth.forshee@canonical.com>
Date: Tue, 25 Nov 2014 20:28:24 -0600

> These BUGs can be erroneously triggered by frags which refer to
> tail pages within a compound page. The data in these pages may
> overrun the hardware page while still being contained within the
> compound page, but since compound_order() evaluates to 0 for tail
> pages the assertion fails. The code already iterates through
> subsequent pages correctly in this scenario, so the BUGs are
> unnecessary and can be removed.
> 
> Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
> Cc: <stable@vger.kernel.org> # 3.7+
> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

Can I get some Xen developer reviews?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:33:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtgSY-0004ph-K3; Wed, 26 Nov 2014 17:32:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1XtgSW-0004pc-Fm
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:32:56 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	56/52-23865-7CE06745; Wed, 26 Nov 2014 17:32:55 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417023173!14073229!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12881 invoked from network); 26 Nov 2014 17:32:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:32:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="196868233"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 12:32:23 -0500
Message-ID: <54760EA5.1030407@citrix.com>
Date: Wed, 26 Nov 2014 18:32:21 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, <xen-devel@lists.xen.org>
References: <1417020935-2934-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417020935-2934-1-git-send-email-wei.liu2@citrix.com>
X-DLP: MIA1
Cc: 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 for-4.6] libxl,
 hotplug/Linux: default to phy backend for raw format file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 26/11/14 a les 17.55, Wei Liu ha escrit:
> Modify libxl and hotplug script to allow raw format file to use phy
> backend.
> 
> The block script now tests the path and determine the actual type of
> file (block device or regular file) then use the actual type to
> determine which branch to run.
> 
> With these changes, plus the current ordering of backend preference (phy
>> qdisk > tap), we will use phy backend for raw format file by default.

Maybe it's a stupid question, but I remember that last time this changed
was attempted it caused problems with local migration. Has this been fixed?

I'm asking because there's no comment of this in the commit message, and
the code doesn't seem to differ from the first try in 11a63a.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:33:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtgSY-0004ph-K3; Wed, 26 Nov 2014 17:32:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1XtgSW-0004pc-Fm
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:32:56 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	56/52-23865-7CE06745; Wed, 26 Nov 2014 17:32:55 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417023173!14073229!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12881 invoked from network); 26 Nov 2014 17:32:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:32:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="196868233"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 12:32:23 -0500
Message-ID: <54760EA5.1030407@citrix.com>
Date: Wed, 26 Nov 2014 18:32:21 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, <xen-devel@lists.xen.org>
References: <1417020935-2934-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417020935-2934-1-git-send-email-wei.liu2@citrix.com>
X-DLP: MIA1
Cc: 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 for-4.6] libxl,
 hotplug/Linux: default to phy backend for raw format file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 26/11/14 a les 17.55, Wei Liu ha escrit:
> Modify libxl and hotplug script to allow raw format file to use phy
> backend.
> 
> The block script now tests the path and determine the actual type of
> file (block device or regular file) then use the actual type to
> determine which branch to run.
> 
> With these changes, plus the current ordering of backend preference (phy
>> qdisk > tap), we will use phy backend for raw format file by default.

Maybe it's a stupid question, but I remember that last time this changed
was attempted it caused problems with local migration. Has this been fixed?

I'm asking because there's no comment of this in the commit message, and
the code doesn't seem to differ from the first try in 11a63a.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:38:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtgXX-0004xn-BL; Wed, 26 Nov 2014 17:38:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtgXW-0004xi-IY
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:38:06 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B3/72-22737-DFF06745; Wed, 26 Nov 2014 17:38:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417023483!13479464!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9930 invoked from network); 26 Nov 2014 17:38:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:38:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="196870493"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 12:38:01 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtgXR-0005O1-Du;
	Wed, 26 Nov 2014 17:38:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtgXR-0002Ry-5H;
	Wed, 26 Nov 2014 17:38:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21622.4088.777274.315050@mariner.uk.xensource.com>
Date: Wed, 26 Nov 2014 17:38:00 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417017154.11944.63.camel@citrix.com>
References: <1417005297.11944.43.camel@citrix.com>
	<21621.61406.151530.376288@mariner.uk.xensource.com>
	<1417016402.11944.60.camel@citrix.com>
	<1417017154.11944.63.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] segv in osevent_release_nexus with libxl backend to
 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] segv in osevent_release_nexus with libxl backend to libvirt"):
> I don't know if this helps but on the 3 occasions I've just looked at
> the ev passed to libxl__ev_fd_deregister contains an fd which
> corresponds to a still open handle on /dev/xen/evtchn.

I see what is going on, I think.  The rules in libxl_event.h about
when one can call libxl_event_register_callbacks are (a) impossibly
lax and (b) not implemented even as far as possible.  The crash is due
to the evtchn fd having been set up during libxl initialisation (while
hooks==0) and therefore not having a `nexus', but being deregistered
later.

AFAICT libvirt doesn't (I think) depend on anything which is
particularly difficult to implement.  It seems to call
libxl_event_register_callbacks in a relatively quiescent state.

I have prepared a set of patches which may help.  They are at
xenbits.xen.org:ext/xen.git#for-ijc.  They arrange that libxl's
innards only register interest when need it, and deregister again.
That way registering the hooks after initialisation actually works,
because when libxl_event_register_callbacks is called, nothing is
actually registered.

I haven't executed these patches _at all_.  (I'm at a conference and
that's not very convenient to do remotely with the connectivity I have
here.)  But they do compile.  If they don't work, or you don't feel
like testing them, let me know and I will debug them with xl before
asking you to try again.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:38:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtgXX-0004xn-BL; Wed, 26 Nov 2014 17:38:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtgXW-0004xi-IY
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:38:06 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B3/72-22737-DFF06745; Wed, 26 Nov 2014 17:38:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417023483!13479464!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9930 invoked from network); 26 Nov 2014 17:38:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:38:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="196870493"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 12:38:01 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtgXR-0005O1-Du;
	Wed, 26 Nov 2014 17:38:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtgXR-0002Ry-5H;
	Wed, 26 Nov 2014 17:38:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21622.4088.777274.315050@mariner.uk.xensource.com>
Date: Wed, 26 Nov 2014 17:38:00 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417017154.11944.63.camel@citrix.com>
References: <1417005297.11944.43.camel@citrix.com>
	<21621.61406.151530.376288@mariner.uk.xensource.com>
	<1417016402.11944.60.camel@citrix.com>
	<1417017154.11944.63.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] segv in osevent_release_nexus with libxl backend to
 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] segv in osevent_release_nexus with libxl backend to libvirt"):
> I don't know if this helps but on the 3 occasions I've just looked at
> the ev passed to libxl__ev_fd_deregister contains an fd which
> corresponds to a still open handle on /dev/xen/evtchn.

I see what is going on, I think.  The rules in libxl_event.h about
when one can call libxl_event_register_callbacks are (a) impossibly
lax and (b) not implemented even as far as possible.  The crash is due
to the evtchn fd having been set up during libxl initialisation (while
hooks==0) and therefore not having a `nexus', but being deregistered
later.

AFAICT libvirt doesn't (I think) depend on anything which is
particularly difficult to implement.  It seems to call
libxl_event_register_callbacks in a relatively quiescent state.

I have prepared a set of patches which may help.  They are at
xenbits.xen.org:ext/xen.git#for-ijc.  They arrange that libxl's
innards only register interest when need it, and deregister again.
That way registering the hooks after initialisation actually works,
because when libxl_event_register_callbacks is called, nothing is
actually registered.

I haven't executed these patches _at all_.  (I'm at a conference and
that's not very convenient to do remotely with the connectivity I have
here.)  But they do compile.  If they don't work, or you don't feel
like testing them, let me know and I will debug them with xl before
asking you to try again.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:39:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtgYh-00053c-UY; Wed, 26 Nov 2014 17:39:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtgYg-00053S-Ne
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:39:18 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	F1/A5-18267-64016745; Wed, 26 Nov 2014 17:39:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417023555!14060252!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10380 invoked from network); 26 Nov 2014 17:39:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:39:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="197117860"
Message-ID: <54761040.9060402@citrix.com>
Date: Wed, 26 Nov 2014 17:39:12 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5474DE5A.2060000@citrix.com>
	<1417020637.11944.67.camel@citrix.com>
In-Reply-To: <1417020637.11944.67.camel@citrix.com>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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 26/11/14 16:50, Ian Campbell wrote:
> On Tue, 2014-11-25 at 19:54 +0000, Andrew Cooper wrote:
>> 3) Libxl and xl support
>>
>> Libxl and xl have as many problems as the libxc code did when it comes
>> to incompatible wire formats and layering violations.  In particular, it
>> is not possible to determine the bitness of the sending
>> libxl-saverestore-helper, meaning that legacy conversion requires active
>> administrator input, or at least a passive assumption that the bitness
>> is the same.
> IOW when migrating legacy->new we have the same restriction as we do
> today in the purely legacy world, which is that the two dom0's must
> having match bit widths?

The legacy->new conversion removes bitness from the equation, but the
bitness of the legacy side is an input parameter to conversion.

For XenServer, this is easy, as all older versions of XenServer are
32bit.  This version, and future versions will use the new format, where
bitness is specifically irrelevant.

For xl, this is harder.  There exist both 32 and 64bit versions doing
legacy migration, and on the receiving side it is impossible to
determine, given only the incoming stream.

>
> IMHO this is fine. It essentially means that for xl users there is some
> delayed gratification wrt the promise of migration between non-alike
> dom0s. The migration from 4.5(legacy)->4.6(v2) won't support such
> migrations, but the next step from 4.6(v2)->4.7(v2) will.

Two options exist.

1) Assume that the sending bitness is the same as the receiving
bitness.  This is already the status quo, and will require that the two
dom0s are the same width.

2) Allow the administrator to specify the bitness of the sending side. 
In this case, xl 4.5(legacy)->4.6(v2) works even cross-bitness.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:39:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtgYh-00053c-UY; Wed, 26 Nov 2014 17:39:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtgYg-00053S-Ne
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:39:18 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	F1/A5-18267-64016745; Wed, 26 Nov 2014 17:39:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417023555!14060252!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10380 invoked from network); 26 Nov 2014 17:39:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:39:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="197117860"
Message-ID: <54761040.9060402@citrix.com>
Date: Wed, 26 Nov 2014 17:39:12 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5474DE5A.2060000@citrix.com>
	<1417020637.11944.67.camel@citrix.com>
In-Reply-To: <1417020637.11944.67.camel@citrix.com>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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 26/11/14 16:50, Ian Campbell wrote:
> On Tue, 2014-11-25 at 19:54 +0000, Andrew Cooper wrote:
>> 3) Libxl and xl support
>>
>> Libxl and xl have as many problems as the libxc code did when it comes
>> to incompatible wire formats and layering violations.  In particular, it
>> is not possible to determine the bitness of the sending
>> libxl-saverestore-helper, meaning that legacy conversion requires active
>> administrator input, or at least a passive assumption that the bitness
>> is the same.
> IOW when migrating legacy->new we have the same restriction as we do
> today in the purely legacy world, which is that the two dom0's must
> having match bit widths?

The legacy->new conversion removes bitness from the equation, but the
bitness of the legacy side is an input parameter to conversion.

For XenServer, this is easy, as all older versions of XenServer are
32bit.  This version, and future versions will use the new format, where
bitness is specifically irrelevant.

For xl, this is harder.  There exist both 32 and 64bit versions doing
legacy migration, and on the receiving side it is impossible to
determine, given only the incoming stream.

>
> IMHO this is fine. It essentially means that for xl users there is some
> delayed gratification wrt the promise of migration between non-alike
> dom0s. The migration from 4.5(legacy)->4.6(v2) won't support such
> migrations, but the next step from 4.6(v2)->4.7(v2) will.

Two options exist.

1) Assume that the sending bitness is the same as the receiving
bitness.  This is already the status quo, and will require that the two
dom0s are the same width.

2) Allow the administrator to specify the bitness of the sending side. 
In this case, xl 4.5(legacy)->4.6(v2) works even cross-bitness.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:44:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtgd7-0005Lw-Ko; Wed, 26 Nov 2014 17:43:53 +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 1Xtgd6-0005Lr-8q
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:43:52 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	1B/A2-14214-75116745; Wed, 26 Nov 2014 17:43:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417023829!13473468!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31456 invoked from network); 26 Nov 2014 17:43:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:43:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="196872284"
Message-ID: <54761124.60203@citrix.com>
Date: Wed, 26 Nov 2014 17:43:00 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
In-Reply-To: <5476058A02000078000C2808@mail.emea.novell.com>
X-DLP: MIA2
Cc: tim@xen.org, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/11/14 16:53, Jan Beulich wrote:
>>>> Andrew Cooper <andrew.cooper3@citrix.com> 11/25/14 7:14 PM >>>
>> On 25/11/14 17:25, Jan Beulich wrote:
>>>>>> On 25.11.14 at 17:54, <andrew.cooper3@citrix.com> wrote:
>>>> This is RFC as there is still a niggle.  I tested this via a partial revert of
>>>> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
>>>> domain crash.  However, I am not sure we want to make any vmentry failure
>>>> quite, as any vmentry failure constitues a Xen bug.
>>> I think that double printing would be tolerable, but I've had yet
>>> another idea: Couldn't we make the second exception a #DF,
>>> thus having the guest killed via triple fault in the worst case at
>>> the third recurring failure (via hvm_combine_hw_exceptions())?
>> That still won't catch a large class of vmentry failures from bad host
>> state.  There needs to be some cutoff where we simply give up and crash
>> the domain.  In the end, this is just an exercise in how much we attempt
>> to recover in the case that we have already hit a hypervisor bug, and
>> can't be completely certain about any state.
>>
>> Furthermore, guest userspace being able to exploit a Xen bug to result
>> in a triple fault is no better than an instant domain_crash(), from a
>> VMs point of view.  However, from a toolstacks point of view, it is even
>> worse, as malicious userspace could tie up toolstack resource in
>> domain_kill() and domain_create() (as a triple fault is modelled as a
>> clean reboot).
> Right - the more I think about it, the more I'm inclined to take your v1 patch...
>
> Jan
>

My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
identify a failed vmentry and lets it fall into the default case of the
vmexit handler.  As such, with v1, the infinite loop still affects AMD
hardware.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:44:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtgd7-0005Lw-Ko; Wed, 26 Nov 2014 17:43:53 +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 1Xtgd6-0005Lr-8q
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:43:52 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	1B/A2-14214-75116745; Wed, 26 Nov 2014 17:43:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417023829!13473468!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31456 invoked from network); 26 Nov 2014 17:43:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:43:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="196872284"
Message-ID: <54761124.60203@citrix.com>
Date: Wed, 26 Nov 2014 17:43:00 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
In-Reply-To: <5476058A02000078000C2808@mail.emea.novell.com>
X-DLP: MIA2
Cc: tim@xen.org, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/11/14 16:53, Jan Beulich wrote:
>>>> Andrew Cooper <andrew.cooper3@citrix.com> 11/25/14 7:14 PM >>>
>> On 25/11/14 17:25, Jan Beulich wrote:
>>>>>> On 25.11.14 at 17:54, <andrew.cooper3@citrix.com> wrote:
>>>> This is RFC as there is still a niggle.  I tested this via a partial revert of
>>>> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
>>>> domain crash.  However, I am not sure we want to make any vmentry failure
>>>> quite, as any vmentry failure constitues a Xen bug.
>>> I think that double printing would be tolerable, but I've had yet
>>> another idea: Couldn't we make the second exception a #DF,
>>> thus having the guest killed via triple fault in the worst case at
>>> the third recurring failure (via hvm_combine_hw_exceptions())?
>> That still won't catch a large class of vmentry failures from bad host
>> state.  There needs to be some cutoff where we simply give up and crash
>> the domain.  In the end, this is just an exercise in how much we attempt
>> to recover in the case that we have already hit a hypervisor bug, and
>> can't be completely certain about any state.
>>
>> Furthermore, guest userspace being able to exploit a Xen bug to result
>> in a triple fault is no better than an instant domain_crash(), from a
>> VMs point of view.  However, from a toolstacks point of view, it is even
>> worse, as malicious userspace could tie up toolstack resource in
>> domain_kill() and domain_create() (as a triple fault is modelled as a
>> clean reboot).
> Right - the more I think about it, the more I'm inclined to take your v1 patch...
>
> Jan
>

My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
identify a failed vmentry and lets it fall into the default case of the
vmexit handler.  As such, with v1, the infinite loop still affects AMD
hardware.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:44:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtgde-0005O3-1M; Wed, 26 Nov 2014 17:44:26 +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 1Xtgdd-0005Nt-F0
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:44:25 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	2E/96-25714-87116745; Wed, 26 Nov 2014 17:44:24 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417023862!9373285!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18272 invoked from network); 26 Nov 2014 17:44:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:44:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="197119760"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 12:44:21 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtgdZ-0005US-MZ;
	Wed, 26 Nov 2014 17:44:21 +0000
Date: Wed, 26 Nov 2014 17:44:21 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20141126174421.GA14481@zion.uk.xensource.com>
References: <1417020935-2934-1-git-send-email-wei.liu2@citrix.com>
	<54760EA5.1030407@citrix.com>
MIME-Version: 1.0
Content-Length: 1472
Content-Disposition: inline
In-Reply-To: <54760EA5.1030407@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.6] libxl,
 hotplug/Linux: default to phy backend for raw format file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 26, 2014 at 06:32:21PM +0100, Roger Pau Monn=E9 wrote:
> El 26/11/14 a les 17.55, Wei Liu ha escrit:
> > Modify libxl and hotplug script to allow raw format file to use phy
> > backend.
> > =

> > The block script now tests the path and determine the actual type of
> > file (block device or regular file) then use the actual type to
> > determine which branch to run.
> > =

> > With these changes, plus the current ordering of backend preference (phy
> >> qdisk > tap), we will use phy backend for raw format file by default.
> =

> Maybe it's a stupid question, but I remember that last time this changed
> was attempted it caused problems with local migration. Has this been fixe=
d?
> =

> I'm asking because there's no comment of this in the commit message, and
> the code doesn't seem to differ from the first try in 11a63a.
> =


Yes, it's fixed.

Actually I think the regression last time was not local migration but
another problem.

This patch is different from the last one, libxl won't write
"physical-device" if the file is regular file. I think last time the
hotplug script was not run correctly due to that problem.

This patch is tested with following setup:

1. Raw file and PV
2. Raw file and HVM
3. Block device and PV
4. Block device and HVM

Creation / destruction / local migration all worked.

Wei.

> Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 17:44:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 17:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtgde-0005O3-1M; Wed, 26 Nov 2014 17:44:26 +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 1Xtgdd-0005Nt-F0
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 17:44:25 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	2E/96-25714-87116745; Wed, 26 Nov 2014 17:44:24 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417023862!9373285!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18272 invoked from network); 26 Nov 2014 17:44:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 17:44:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="197119760"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 12:44:21 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XtgdZ-0005US-MZ;
	Wed, 26 Nov 2014 17:44:21 +0000
Date: Wed, 26 Nov 2014 17:44:21 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20141126174421.GA14481@zion.uk.xensource.com>
References: <1417020935-2934-1-git-send-email-wei.liu2@citrix.com>
	<54760EA5.1030407@citrix.com>
MIME-Version: 1.0
Content-Length: 1472
Content-Disposition: inline
In-Reply-To: <54760EA5.1030407@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.6] libxl,
 hotplug/Linux: default to phy backend for raw format file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 26, 2014 at 06:32:21PM +0100, Roger Pau Monn=E9 wrote:
> El 26/11/14 a les 17.55, Wei Liu ha escrit:
> > Modify libxl and hotplug script to allow raw format file to use phy
> > backend.
> > =

> > The block script now tests the path and determine the actual type of
> > file (block device or regular file) then use the actual type to
> > determine which branch to run.
> > =

> > With these changes, plus the current ordering of backend preference (phy
> >> qdisk > tap), we will use phy backend for raw format file by default.
> =

> Maybe it's a stupid question, but I remember that last time this changed
> was attempted it caused problems with local migration. Has this been fixe=
d?
> =

> I'm asking because there's no comment of this in the commit message, and
> the code doesn't seem to differ from the first try in 11a63a.
> =


Yes, it's fixed.

Actually I think the regression last time was not local migration but
another problem.

This patch is different from the last one, libxl won't write
"physical-device" if the file is regular file. I think last time the
hotplug script was not run correctly due to that problem.

This patch is tested with following setup:

1. Raw file and PV
2. Raw file and HVM
3. Block device and PV
4. Block device and HVM

Creation / destruction / local migration all worked.

Wei.

> Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 18:18:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 18:18:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XthA8-000656-V6; Wed, 26 Nov 2014 18:18:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XthA7-000651-KJ
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 18:17:59 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	1B/3E-02699-65916745; Wed, 26 Nov 2014 18:17:58 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417025877!10444880!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23168 invoked from network); 26 Nov 2014 18:17:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 18:17:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="196887398"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 13:17:55 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XthA3-00063I-1b;
	Wed, 26 Nov 2014 18:17:55 +0000
Date: Wed, 26 Nov 2014 18:17:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <5474C96A.6090506@citrix.com>
Message-ID: <alpine.DEB.2.02.1411261817330.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
	<5474C96A.6090506@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] increase maxmem before calling
 xc_domain_populate_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Andrew Cooper wrote:
> On 25/11/14 17:45, Stefano Stabellini wrote:
> > Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
> > the risk of running out of guest memory. This way we can also avoid
> > complex memory calculations in libxl at domain construction time.
> >
> > This patch fixes an abort() when assigning more than 4 NICs to a VM.
> >
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 5c69a8d..38e08c3 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -218,6 +218,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
> >      unsigned long nr_pfn;
> >      xen_pfn_t *pfn_list;
> >      int i;
> > +    xc_dominfo_t info;
> >  
> >      if (runstate_check(RUN_STATE_INMIGRATE)) {
> >          /* RAM already populated in Xen */
> > @@ -240,6 +241,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
> >          pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
> >      }
> >  
> > +    if (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) < 0) {
> 
> xc_domain_getinfo()'s interface is mad, and provides no guarantee that
> it returns the information for the domain you requested.  It also won't
> return -1 on error.  The correct error handing is:
> 
> (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) || (info.domid !=
> xen_domid)

It might be wiser to switch to xc_domain_getinfolist


> ~Andrew
> 
> > +        hw_error("xc_domain_getinfo failed");
> > +    }
> > +    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> > +                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
> > +        hw_error("xc_domain_setmaxmem failed");
> > +    }
> >      if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) {
> >          hw_error("xen: failed to populate ram at " RAM_ADDR_FMT, ram_addr);
> >      }
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Nov 26 18:18:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 18:18:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XthA8-000656-V6; Wed, 26 Nov 2014 18:18:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XthA7-000651-KJ
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 18:17:59 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	1B/3E-02699-65916745; Wed, 26 Nov 2014 18:17:58 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417025877!10444880!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23168 invoked from network); 26 Nov 2014 18:17:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 18:17:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="196887398"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Wed, 26 Nov 2014 13:17:55 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XthA3-00063I-1b;
	Wed, 26 Nov 2014 18:17:55 +0000
Date: Wed, 26 Nov 2014 18:17:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <5474C96A.6090506@citrix.com>
Message-ID: <alpine.DEB.2.02.1411261817330.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
	<5474C96A.6090506@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] increase maxmem before calling
 xc_domain_populate_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Nov 2014, Andrew Cooper wrote:
> On 25/11/14 17:45, Stefano Stabellini wrote:
> > Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
> > the risk of running out of guest memory. This way we can also avoid
> > complex memory calculations in libxl at domain construction time.
> >
> > This patch fixes an abort() when assigning more than 4 NICs to a VM.
> >
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 5c69a8d..38e08c3 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -218,6 +218,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
> >      unsigned long nr_pfn;
> >      xen_pfn_t *pfn_list;
> >      int i;
> > +    xc_dominfo_t info;
> >  
> >      if (runstate_check(RUN_STATE_INMIGRATE)) {
> >          /* RAM already populated in Xen */
> > @@ -240,6 +241,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
> >          pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
> >      }
> >  
> > +    if (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) < 0) {
> 
> xc_domain_getinfo()'s interface is mad, and provides no guarantee that
> it returns the information for the domain you requested.  It also won't
> return -1 on error.  The correct error handing is:
> 
> (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) || (info.domid !=
> xen_domid)

It might be wiser to switch to xc_domain_getinfolist


> ~Andrew
> 
> > +        hw_error("xc_domain_getinfo failed");
> > +    }
> > +    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> > +                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
> > +        hw_error("xc_domain_setmaxmem failed");
> > +    }
> >      if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) {
> >          hw_error("xen: failed to populate ram at " RAM_ADDR_FMT, ram_addr);
> >      }
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Nov 26 18:24:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 18:24:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XthGW-0006KV-Pe; Wed, 26 Nov 2014 18:24:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@citrix.com>) id 1XthGV-0006KQ-M7
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 18:24:35 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	4B/73-02698-3EA16745; Wed, 26 Nov 2014 18:24:35 +0000
X-Env-Sender: Dave.Scott@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417026274!15044770!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6500 invoked from network); 26 Nov 2014 18:24:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 18:24:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="27212323"
From: Dave Scott <Dave.Scott@citrix.com>
To: Zheng Li <dev@zheng.li>
Thread-Topic: [PATCH for-4.5] tools/oxenstored: Fix | vs & error in fd event
	handling
Thread-Index: AQHQCY7+MCUbGmecRkCFQqBESlOOyZxzKHYA
Date: Wed, 26 Nov 2014 18:24:11 +0000
Message-ID: <0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
In-Reply-To: <5475F3DF.2070907@zheng.li>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-ID: <266DD80991DC0E44B322C91F57E7DDD4@citrix.com>
MIME-Version: 1.0
X-DLP: AMS1
Cc: Dave Scott <Dave.Scott@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>, Ian
	Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event 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 26 Nov 2014, at 15:38, Zheng Li <dev@zheng.li> wrote:
> 
> On 26/11/2014 15:09, Andrew Cooper wrote:
>> This makes fields 0 and 1 true more often than they should be, resulting
>> problems when handling events.
> 
> Indeed, looks like a mistake I made when rewriting the logic terms lately. The result is POLLUP or POLLERR events being returned in more categories than we'd interest. Thanks for fixing this!
> 
> Acked-by: Zheng Li <dev@zheng.li>

This also looks fine to me

Acked-by: David Scott <dave.scott@citrix.com>

Cheers,
Dave

> 
> 
> Cheers,
> Zheng
> 
> 
>> ---
>> 
>> This was discovered with XenServers internal Coverity instance.  I have yet to
>> work out why the issue is not identified by the upstream coverity scanning.
>> 
>> Konrad: This is a bug in the default event handling used by oxenstored in 4.5,
>> as the default switched from select() to poll() in the 4.5 timeframe.  It
>> would appear that the negative side effects are limited to just logspam about
>> certain clients attempting invalid actions, but I can't rule out anything more
>> problematic.
>> ---
>>  tools/ocaml/xenstored/select_stubs.c |    4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/tools/ocaml/xenstored/select_stubs.c b/tools/ocaml/xenstored/select_stubs.c
>> index 4a8edb5..af72b84 100644
>> --- a/tools/ocaml/xenstored/select_stubs.c
>> +++ b/tools/ocaml/xenstored/select_stubs.c
>> @@ -56,8 +56,8 @@ CAMLprim value stub_select_on_poll(value fd_events, value timeo) {
>>  			events = Field(Field(fd_events, i), 1);
>> 
>>  			if (c_fds[i].revents & POLLNVAL) unix_error(EBADF, "select", Nothing);
>> -			Field(events, 0) = Val_bool(c_fds[i].events | POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
>> -			Field(events, 1) = Val_bool(c_fds[i].events | POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
>> +			Field(events, 0) = Val_bool(c_fds[i].events & POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
>> +			Field(events, 1) = Val_bool(c_fds[i].events & POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
>>  			Field(events, 2) = Val_bool(c_fds[i].revents & POLLPRI);
>> 
>>  		}
>> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 18:24:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 18:24:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XthGW-0006KV-Pe; Wed, 26 Nov 2014 18:24:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@citrix.com>) id 1XthGV-0006KQ-M7
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 18:24:35 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	4B/73-02698-3EA16745; Wed, 26 Nov 2014 18:24:35 +0000
X-Env-Sender: Dave.Scott@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417026274!15044770!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6500 invoked from network); 26 Nov 2014 18:24:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 18:24:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,463,1413244800"; d="scan'208";a="27212323"
From: Dave Scott <Dave.Scott@citrix.com>
To: Zheng Li <dev@zheng.li>
Thread-Topic: [PATCH for-4.5] tools/oxenstored: Fix | vs & error in fd event
	handling
Thread-Index: AQHQCY7+MCUbGmecRkCFQqBESlOOyZxzKHYA
Date: Wed, 26 Nov 2014 18:24:11 +0000
Message-ID: <0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
In-Reply-To: <5475F3DF.2070907@zheng.li>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-ID: <266DD80991DC0E44B322C91F57E7DDD4@citrix.com>
MIME-Version: 1.0
X-DLP: AMS1
Cc: Dave Scott <Dave.Scott@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>, Ian
	Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event 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 26 Nov 2014, at 15:38, Zheng Li <dev@zheng.li> wrote:
> 
> On 26/11/2014 15:09, Andrew Cooper wrote:
>> This makes fields 0 and 1 true more often than they should be, resulting
>> problems when handling events.
> 
> Indeed, looks like a mistake I made when rewriting the logic terms lately. The result is POLLUP or POLLERR events being returned in more categories than we'd interest. Thanks for fixing this!
> 
> Acked-by: Zheng Li <dev@zheng.li>

This also looks fine to me

Acked-by: David Scott <dave.scott@citrix.com>

Cheers,
Dave

> 
> 
> Cheers,
> Zheng
> 
> 
>> ---
>> 
>> This was discovered with XenServers internal Coverity instance.  I have yet to
>> work out why the issue is not identified by the upstream coverity scanning.
>> 
>> Konrad: This is a bug in the default event handling used by oxenstored in 4.5,
>> as the default switched from select() to poll() in the 4.5 timeframe.  It
>> would appear that the negative side effects are limited to just logspam about
>> certain clients attempting invalid actions, but I can't rule out anything more
>> problematic.
>> ---
>>  tools/ocaml/xenstored/select_stubs.c |    4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/tools/ocaml/xenstored/select_stubs.c b/tools/ocaml/xenstored/select_stubs.c
>> index 4a8edb5..af72b84 100644
>> --- a/tools/ocaml/xenstored/select_stubs.c
>> +++ b/tools/ocaml/xenstored/select_stubs.c
>> @@ -56,8 +56,8 @@ CAMLprim value stub_select_on_poll(value fd_events, value timeo) {
>>  			events = Field(Field(fd_events, i), 1);
>> 
>>  			if (c_fds[i].revents & POLLNVAL) unix_error(EBADF, "select", Nothing);
>> -			Field(events, 0) = Val_bool(c_fds[i].events | POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
>> -			Field(events, 1) = Val_bool(c_fds[i].events | POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
>> +			Field(events, 0) = Val_bool(c_fds[i].events & POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
>> +			Field(events, 1) = Val_bool(c_fds[i].events & POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
>>  			Field(events, 2) = Val_bool(c_fds[i].revents & POLLPRI);
>> 
>>  		}
>> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 18:42:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 18:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XthX7-0006bd-CW; Wed, 26 Nov 2014 18:41:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XthX5-0006bW-Fi
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 18:41:43 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	90/15-22777-6EE16745; Wed, 26 Nov 2014 18:41:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417027301!13495047!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11506 invoked from network); 26 Nov 2014 18:41:42 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 18:41:42 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQIfZvm010319
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 18:41:35 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQIfW36029678
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 18:41:33 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQIfV82017042; Wed, 26 Nov 2014 18:41:32 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 10:41:31 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E2085119EF8; Wed, 26 Nov 2014 13:41:30 -0500 (EST)
Date: Wed, 26 Nov 2014 13:41:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dave Scott <Dave.Scott@citrix.com>
Message-ID: <20141126184130.GB13384@laptop.dumpdata.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Zheng Li <dev@zheng.li>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 26, 2014 at 06:24:11PM +0000, Dave Scott wrote:
> 
> > On 26 Nov 2014, at 15:38, Zheng Li <dev@zheng.li> wrote:
> > 
> > On 26/11/2014 15:09, Andrew Cooper wrote:
> >> This makes fields 0 and 1 true more often than they should be, resulting
> >> problems when handling events.
> > 
> > Indeed, looks like a mistake I made when rewriting the logic terms lately. The result is POLLUP or POLLERR events being returned in more categories than we'd interest. Thanks for fixing this!
> > 
> > Acked-by: Zheng Li <dev@zheng.li>
> 
> This also looks fine to me
> 
> Acked-by: David Scott <dave.scott@citrix.com>

Would it be possible to get an Reviewed-by please?

Thank you.
> 
> Cheers,
> Dave
> 
> > 
> > 
> > Cheers,
> > Zheng
> > 
> > 
> >> ---
> >> 
> >> This was discovered with XenServers internal Coverity instance.  I have yet to
> >> work out why the issue is not identified by the upstream coverity scanning.
> >> 
> >> Konrad: This is a bug in the default event handling used by oxenstored in 4.5,
> >> as the default switched from select() to poll() in the 4.5 timeframe.  It
> >> would appear that the negative side effects are limited to just logspam about
> >> certain clients attempting invalid actions, but I can't rule out anything more
> >> problematic.
> >> ---
> >>  tools/ocaml/xenstored/select_stubs.c |    4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/tools/ocaml/xenstored/select_stubs.c b/tools/ocaml/xenstored/select_stubs.c
> >> index 4a8edb5..af72b84 100644
> >> --- a/tools/ocaml/xenstored/select_stubs.c
> >> +++ b/tools/ocaml/xenstored/select_stubs.c
> >> @@ -56,8 +56,8 @@ CAMLprim value stub_select_on_poll(value fd_events, value timeo) {
> >>  			events = Field(Field(fd_events, i), 1);
> >> 
> >>  			if (c_fds[i].revents & POLLNVAL) unix_error(EBADF, "select", Nothing);
> >> -			Field(events, 0) = Val_bool(c_fds[i].events | POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
> >> -			Field(events, 1) = Val_bool(c_fds[i].events | POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
> >> +			Field(events, 0) = Val_bool(c_fds[i].events & POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
> >> +			Field(events, 1) = Val_bool(c_fds[i].events & POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
> >>  			Field(events, 2) = Val_bool(c_fds[i].revents & POLLPRI);
> >> 
> >>  		}
> >> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 18:42:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 18:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XthX7-0006bd-CW; Wed, 26 Nov 2014 18:41:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XthX5-0006bW-Fi
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 18:41:43 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	90/15-22777-6EE16745; Wed, 26 Nov 2014 18:41:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417027301!13495047!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11506 invoked from network); 26 Nov 2014 18:41:42 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 18:41:42 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQIfZvm010319
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 18:41:35 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQIfW36029678
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 26 Nov 2014 18:41:33 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQIfV82017042; Wed, 26 Nov 2014 18:41:32 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 10:41:31 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E2085119EF8; Wed, 26 Nov 2014 13:41:30 -0500 (EST)
Date: Wed, 26 Nov 2014 13:41:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dave Scott <Dave.Scott@citrix.com>
Message-ID: <20141126184130.GB13384@laptop.dumpdata.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Zheng Li <dev@zheng.li>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 26, 2014 at 06:24:11PM +0000, Dave Scott wrote:
> 
> > On 26 Nov 2014, at 15:38, Zheng Li <dev@zheng.li> wrote:
> > 
> > On 26/11/2014 15:09, Andrew Cooper wrote:
> >> This makes fields 0 and 1 true more often than they should be, resulting
> >> problems when handling events.
> > 
> > Indeed, looks like a mistake I made when rewriting the logic terms lately. The result is POLLUP or POLLERR events being returned in more categories than we'd interest. Thanks for fixing this!
> > 
> > Acked-by: Zheng Li <dev@zheng.li>
> 
> This also looks fine to me
> 
> Acked-by: David Scott <dave.scott@citrix.com>

Would it be possible to get an Reviewed-by please?

Thank you.
> 
> Cheers,
> Dave
> 
> > 
> > 
> > Cheers,
> > Zheng
> > 
> > 
> >> ---
> >> 
> >> This was discovered with XenServers internal Coverity instance.  I have yet to
> >> work out why the issue is not identified by the upstream coverity scanning.
> >> 
> >> Konrad: This is a bug in the default event handling used by oxenstored in 4.5,
> >> as the default switched from select() to poll() in the 4.5 timeframe.  It
> >> would appear that the negative side effects are limited to just logspam about
> >> certain clients attempting invalid actions, but I can't rule out anything more
> >> problematic.
> >> ---
> >>  tools/ocaml/xenstored/select_stubs.c |    4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/tools/ocaml/xenstored/select_stubs.c b/tools/ocaml/xenstored/select_stubs.c
> >> index 4a8edb5..af72b84 100644
> >> --- a/tools/ocaml/xenstored/select_stubs.c
> >> +++ b/tools/ocaml/xenstored/select_stubs.c
> >> @@ -56,8 +56,8 @@ CAMLprim value stub_select_on_poll(value fd_events, value timeo) {
> >>  			events = Field(Field(fd_events, i), 1);
> >> 
> >>  			if (c_fds[i].revents & POLLNVAL) unix_error(EBADF, "select", Nothing);
> >> -			Field(events, 0) = Val_bool(c_fds[i].events | POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
> >> -			Field(events, 1) = Val_bool(c_fds[i].events | POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
> >> +			Field(events, 0) = Val_bool(c_fds[i].events & POLLIN  && c_fds[i].revents & (POLLIN |POLLHUP|POLLERR));
> >> +			Field(events, 1) = Val_bool(c_fds[i].events & POLLOUT && c_fds[i].revents & (POLLOUT|POLLHUP|POLLERR));
> >>  			Field(events, 2) = Val_bool(c_fds[i].revents & POLLPRI);
> >> 
> >>  		}
> >> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 19:03:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 19: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 1XthsF-00078M-BJ; Wed, 26 Nov 2014 19:03:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XthsE-00078H-HO
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 19:03:34 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	FF/1F-02954-50426745; Wed, 26 Nov 2014 19:03:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417028612!15085567!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27880 invoked from network); 26 Nov 2014 19:03:33 -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;
	26 Nov 2014 19:03:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="196906899"
Message-ID: <547623EE.2070303@citrix.com>
Date: Wed, 26 Nov 2014 19:03:10 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Dave Scott
	<Dave.Scott@citrix.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>	<5475F3DF.2070907@zheng.li>	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
In-Reply-To: <20141126184130.GB13384@laptop.dumpdata.com>
X-DLP: MIA1
Cc: Zheng Li <dev@zheng.li>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>, "Zheng Li
	\(3P\)" <zheng.li3@citrix.com>, Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event 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 26/11/14 18:41, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 26, 2014 at 06:24:11PM +0000, Dave Scott wrote:
>>> On 26 Nov 2014, at 15:38, Zheng Li <dev@zheng.li> wrote:
>>>
>>> On 26/11/2014 15:09, Andrew Cooper wrote:
>>>> This makes fields 0 and 1 true more often than they should be, resulting
>>>> problems when handling events.
>>> Indeed, looks like a mistake I made when rewriting the logic terms lately. The result is POLLUP or POLLERR events being returned in more categories than we'd interest. Thanks for fixing this!
>>>
>>> Acked-by: Zheng Li <dev@zheng.li>
>> This also looks fine to me
>>
>> Acked-by: David Scott <dave.scott@citrix.com>
> Would it be possible to get an Reviewed-by please?

Strictly speaking Zheng, not being a maintainer, can't ack the patch,
given what I believe to be Xens current rules for these things. 
However, as the author of the code and comment in this thread, his ack
can reasonably be considered equivalent to a  Reviewed-by:  I guess this
is just a matter of semantics.

Furthermore, as we all share an office, I have already been through this
process informally, and have confirmed the fix under my Xen-4.5 based
XenServer branch.  There appear to be 100% less "error -EINVAL" messages
in the logs.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 19:03:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 19: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 1XthsF-00078M-BJ; Wed, 26 Nov 2014 19:03:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XthsE-00078H-HO
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 19:03:34 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	FF/1F-02954-50426745; Wed, 26 Nov 2014 19:03:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417028612!15085567!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27880 invoked from network); 26 Nov 2014 19:03:33 -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;
	26 Nov 2014 19:03:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="196906899"
Message-ID: <547623EE.2070303@citrix.com>
Date: Wed, 26 Nov 2014 19:03:10 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Dave Scott
	<Dave.Scott@citrix.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>	<5475F3DF.2070907@zheng.li>	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
In-Reply-To: <20141126184130.GB13384@laptop.dumpdata.com>
X-DLP: MIA1
Cc: Zheng Li <dev@zheng.li>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>, "Zheng Li
	\(3P\)" <zheng.li3@citrix.com>, Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event 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 26/11/14 18:41, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 26, 2014 at 06:24:11PM +0000, Dave Scott wrote:
>>> On 26 Nov 2014, at 15:38, Zheng Li <dev@zheng.li> wrote:
>>>
>>> On 26/11/2014 15:09, Andrew Cooper wrote:
>>>> This makes fields 0 and 1 true more often than they should be, resulting
>>>> problems when handling events.
>>> Indeed, looks like a mistake I made when rewriting the logic terms lately. The result is POLLUP or POLLERR events being returned in more categories than we'd interest. Thanks for fixing this!
>>>
>>> Acked-by: Zheng Li <dev@zheng.li>
>> This also looks fine to me
>>
>> Acked-by: David Scott <dave.scott@citrix.com>
> Would it be possible to get an Reviewed-by please?

Strictly speaking Zheng, not being a maintainer, can't ack the patch,
given what I believe to be Xens current rules for these things. 
However, as the author of the code and comment in this thread, his ack
can reasonably be considered equivalent to a  Reviewed-by:  I guess this
is just a matter of semantics.

Furthermore, as we all share an office, I have already been through this
process informally, and have confirmed the fix under my Xen-4.5 based
XenServer branch.  There appear to be 100% less "error -EINVAL" messages
in the logs.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 19:38:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 19:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtiPo-0007gm-E7; Wed, 26 Nov 2014 19: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.Jackson@citrix.com>) id 1XtiPn-0007gh-4U
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 19:38:15 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	58/3C-17735-62C26745; Wed, 26 Nov 2014 19:38:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417030691!10346207!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4218 invoked from network); 26 Nov 2014 19:38:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 19:38:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="197166513"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 14:37:57 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtiPU-00043Q-V0;
	Wed, 26 Nov 2014 19:37:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtiPU-0005J3-OX;
	Wed, 26 Nov 2014 19:37:56 +0000
Date: Wed, 26 Nov 2014 19:37:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31860-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8832
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31860: 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: multipart/mixed; boundary="===============4223247566093880365=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4223247566093880365==
Content-Type: text/plain
Content-Length: 8573
Content-Transfer-Encoding: quoted-printable

flight 31860 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31860/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              7296e896c92c64ec5653095bcc2ed86b6a72a7d5
baseline version:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad

------------------------------------------------------------
People who touched revisions under test:
  Anirban Chakraborty <abchak@juniper.net>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  C=C3=A9dric Bosdonnat <cbosdonnat@suse.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Giuseppe Scrivano <gscrivan@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nehal J Wani <nehaljw.kkd1@gmail.com>
  Pavel Hrdina <phrdina@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Tomoki Sekiyama <tomoki.sekiyama@hds.com>
  Wang Rui <moon.wangrui@huawei.com>
  Yohan BELLEGUIC <yohan.belleguic@diateam.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3D7296e896c92c64ec5653095bcc2ed86b6a72a7d5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 7296e896c92c64ec5653095bcc2ed86b6a72a7d5
+ branch=3Dlibvirt
+ revision=3D7296e896c92c64ec5653095bcc2ed86b6a72a7d5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 7296e896c92c64ec5653095bcc2ed86b6a72a7d5:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   6c79469..7296e89  7296e896c92c64ec5653095bcc2ed86b6a72a7d5 -> xen-tested-master


--===============4223247566093880365==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4223247566093880365==--

From xen-devel-bounces@lists.xen.org Wed Nov 26 19:38:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 19:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtiPo-0007gm-E7; Wed, 26 Nov 2014 19: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.Jackson@citrix.com>) id 1XtiPn-0007gh-4U
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 19:38:15 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	58/3C-17735-62C26745; Wed, 26 Nov 2014 19:38:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417030691!10346207!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4218 invoked from network); 26 Nov 2014 19:38:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 19:38:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="197166513"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 14:37:57 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtiPU-00043Q-V0;
	Wed, 26 Nov 2014 19:37:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtiPU-0005J3-OX;
	Wed, 26 Nov 2014 19:37:56 +0000
Date: Wed, 26 Nov 2014 19:37:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31860-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8832
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31860: 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: multipart/mixed; boundary="===============4223247566093880365=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4223247566093880365==
Content-Type: text/plain
Content-Length: 8573
Content-Transfer-Encoding: quoted-printable

flight 31860 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31860/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              7296e896c92c64ec5653095bcc2ed86b6a72a7d5
baseline version:
 libvirt              6c79469ccc3245b9572dcaabe8cd620ba3fabfad

------------------------------------------------------------
People who touched revisions under test:
  Anirban Chakraborty <abchak@juniper.net>
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
  C=C3=A9dric Bosdonnat <cbosdonnat@suse.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Giuseppe Scrivano <gscrivan@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Nehal J Wani <nehaljw.kkd1@gmail.com>
  Pavel Hrdina <phrdina@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
  Tomoki Sekiyama <tomoki.sekiyama@hds.com>
  Wang Rui <moon.wangrui@huawei.com>
  Yohan BELLEGUIC <yohan.belleguic@diateam.net>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3D7296e896c92c64ec5653095bcc2ed86b6a72a7d5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x '!=3D' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=3D/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 7296e896c92c64ec5653095bcc2ed86b6a72a7d5
+ branch=3Dlibvirt
+ revision=3D7296e896c92c64ec5653095bcc2ed86b6a72a7d5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=3D/export/home/osstest/repos
++ repos_lock=3D/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=3D' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=3Dlibvirt
+ xenbranch=3Dxen-unstable
+ '[' xlibvirt =3D xlinux ']'
+ linuxbranch=3D
+ '[' x =3D x ']'
+ qemuubranch=3Dqemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=3Dtry]'
+++ local repo=3Dgit://git.sv.gnu.org/gnulib.git
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=3Dtry]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=3Dtry]'
+++ local repo=3Dhttps://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=3D[fetch=3Dtry]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=3Dgit://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=3D' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=3Dtry]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git =3D x ']'
++ '[' x =3D x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=3Dosstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=3Dosstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=3Dosstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=3Dosstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=3Dosstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=3Dosstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 7296e896c92c64ec5653095bcc2ed86b6a72a7d5:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   6c79469..7296e89  7296e896c92c64ec5653095bcc2ed86b6a72a7d5 -> xen-tested-master


--===============4223247566093880365==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4223247566093880365==--

From xen-devel-bounces@lists.xen.org Wed Nov 26 19:55:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 19: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 1Xtig4-0007zw-0U; Wed, 26 Nov 2014 19:55:04 +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 1Xtig3-0007zr-4v
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 19:55:03 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	76/86-14727-61036745; Wed, 26 Nov 2014 19:55:02 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417031701!13489071!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17817 invoked from network); 26 Nov 2014 19:55:02 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Nov 2014 19:55:02 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAQJsk9K014474;
	Wed, 26 Nov 2014 19:54:50 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAQJsfs3031870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Nov 2014 19:54:41 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAQJsfWp018386;
	Wed, 26 Nov 2014 19:54:41 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAQJseIe018382; Wed, 26 Nov 2014 19:54:40 GMT
Date: Wed, 26 Nov 2014 19:54:40 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; boundary="8323329-1251169062-1417030672=:18561"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAQJsk9K014474
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] fix segfault in xl migrate --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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1251169062-1417030672=:18561
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

If differences are found during the verification phase of xl migrate 
--debug then it is likely to crash with a segfault because the bogus
pagebuf->pfn_types[pfn] is used in a print statement instead of 
pfn_type[pfn] .

Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
--8323329-1251169062-1417030672=:18561
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xl.migrate.debug.crash.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xl.migrate.debug.crash.patch

eGwgbWlncmF0ZSAtLWRlYnVnIGNhbiBzZWdmYXVsdCBiZWNhdXNlIHBhZ2VidWYtPnBmbl90eXBl
c1twZm5dIGlzDQp1c2VkIGluIGEgcHJpbnQgc3RhdGVtZW50IGluc3RlYWQgb2YgcGZuX3R5cGVb
cGZuXSANCg0KLS0tIHhlbi00LjUuMC1yYzEvdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUu
Yy5vcmlnCTIwMTQtMTAtMjQgMTU6MjI6NDAuMDAwMDAwMDAwICswMTAwDQorKysgeGVuLTQuNS4w
LXJjMS90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCTIwMTQtMTEtMjUgMjE6MDE6MTYu
NjA0MDgxNDY3ICswMDAwDQpAQCAtMTQwNCw3ICsxNDA0LDcgQEANCiAgICAgICAgICAgICAgICAg
aW50IHY7DQogDQogICAgICAgICAgICAgICAgIERQUklOVEYoIioqKioqKioqKioqKioqIHBmbj0l
bHggdHlwZT0lbHggZ290Y3M9JTA4bHggIg0KLSAgICAgICAgICAgICAgICAgICAgICAgICJhY3R1
YWxjcz0lMDhseFxuIiwgcGZuLCBwYWdlYnVmLT5wZm5fdHlwZXNbcGZuXSwNCisgICAgICAgICAg
ICAgICAgICAgICAgICAiYWN0dWFsY3M9JTA4bHhcbiIsIHBmbiwgcGZuX3R5cGVbcGZuXSwNCiAg
ICAgICAgICAgICAgICAgICAgICAgICBjc3VtX3BhZ2UocmVnaW9uX2Jhc2UgKyBpICogUEFHRV9T
SVpFKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICBjc3VtX3BhZ2UoYnVmKSk7DQogDQo=

--8323329-1251169062-1417030672=:18561
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1251169062-1417030672=:18561--


From xen-devel-bounces@lists.xen.org Wed Nov 26 19:55:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 19: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 1Xtig4-0007zw-0U; Wed, 26 Nov 2014 19:55:04 +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 1Xtig3-0007zr-4v
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 19:55:03 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	76/86-14727-61036745; Wed, 26 Nov 2014 19:55:02 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417031701!13489071!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17817 invoked from network); 26 Nov 2014 19:55:02 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Nov 2014 19:55:02 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAQJsk9K014474;
	Wed, 26 Nov 2014 19:54:50 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAQJsfs3031870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Nov 2014 19:54:41 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAQJsfWp018386;
	Wed, 26 Nov 2014 19:54:41 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAQJseIe018382; Wed, 26 Nov 2014 19:54:40 GMT
Date: Wed, 26 Nov 2014 19:54:40 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; boundary="8323329-1251169062-1417030672=:18561"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAQJsk9K014474
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] fix segfault in xl migrate --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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1251169062-1417030672=:18561
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

If differences are found during the verification phase of xl migrate 
--debug then it is likely to crash with a segfault because the bogus
pagebuf->pfn_types[pfn] is used in a print statement instead of 
pfn_type[pfn] .

Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
--8323329-1251169062-1417030672=:18561
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xl.migrate.debug.crash.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xl.migrate.debug.crash.patch

eGwgbWlncmF0ZSAtLWRlYnVnIGNhbiBzZWdmYXVsdCBiZWNhdXNlIHBhZ2VidWYtPnBmbl90eXBl
c1twZm5dIGlzDQp1c2VkIGluIGEgcHJpbnQgc3RhdGVtZW50IGluc3RlYWQgb2YgcGZuX3R5cGVb
cGZuXSANCg0KLS0tIHhlbi00LjUuMC1yYzEvdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUu
Yy5vcmlnCTIwMTQtMTAtMjQgMTU6MjI6NDAuMDAwMDAwMDAwICswMTAwDQorKysgeGVuLTQuNS4w
LXJjMS90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCTIwMTQtMTEtMjUgMjE6MDE6MTYu
NjA0MDgxNDY3ICswMDAwDQpAQCAtMTQwNCw3ICsxNDA0LDcgQEANCiAgICAgICAgICAgICAgICAg
aW50IHY7DQogDQogICAgICAgICAgICAgICAgIERQUklOVEYoIioqKioqKioqKioqKioqIHBmbj0l
bHggdHlwZT0lbHggZ290Y3M9JTA4bHggIg0KLSAgICAgICAgICAgICAgICAgICAgICAgICJhY3R1
YWxjcz0lMDhseFxuIiwgcGZuLCBwYWdlYnVmLT5wZm5fdHlwZXNbcGZuXSwNCisgICAgICAgICAg
ICAgICAgICAgICAgICAiYWN0dWFsY3M9JTA4bHhcbiIsIHBmbiwgcGZuX3R5cGVbcGZuXSwNCiAg
ICAgICAgICAgICAgICAgICAgICAgICBjc3VtX3BhZ2UocmVnaW9uX2Jhc2UgKyBpICogUEFHRV9T
SVpFKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICBjc3VtX3BhZ2UoYnVmKSk7DQogDQo=

--8323329-1251169062-1417030672=:18561
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1251169062-1417030672=:18561--


From xen-devel-bounces@lists.xen.org Wed Nov 26 20:04:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20: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 1XtipM-0008OA-2d; Wed, 26 Nov 2014 20:04:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XtipL-0008O5-3P
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 20:04:39 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	84/43-23865-65236745; Wed, 26 Nov 2014 20:04:38 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417032277!10349494!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13122 invoked from network); 26 Nov 2014 20:04:37 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 26 Nov 2014 20:04:37 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:64536 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xtin7-0001Ha-BQ; Wed, 26 Nov 2014 21:02:21 +0100
Date: Wed, 26 Nov 2014 21:04:36 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <4610426124.20141126210436@eikelenboom.it>
To: stefano.stabellini@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] Xen-unstable: problems with qmp socket error in
	libxl_pci teardown path for HVM guest with 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,

While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
xl didn't show any problems on the commandline so i never drawed much attention 
to it, but /var/log/xen/xl-guest.log shows:

    Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
    Domain 19 has shut down, reason code 0 0x0
    Action for shutdown reason code 0 is destroy
    Domain 19 needs to be cleaned up: destroying the domain
    libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
    libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
    libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
    libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
    Done. Exiting now

So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 20:04:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20: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 1XtipM-0008OA-2d; Wed, 26 Nov 2014 20:04:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XtipL-0008O5-3P
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 20:04:39 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	84/43-23865-65236745; Wed, 26 Nov 2014 20:04:38 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417032277!10349494!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13122 invoked from network); 26 Nov 2014 20:04:37 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 26 Nov 2014 20:04:37 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:64536 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xtin7-0001Ha-BQ; Wed, 26 Nov 2014 21:02:21 +0100
Date: Wed, 26 Nov 2014 21:04:36 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <4610426124.20141126210436@eikelenboom.it>
To: stefano.stabellini@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] Xen-unstable: problems with qmp socket error in
	libxl_pci teardown path for HVM guest with 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,

While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
xl didn't show any problems on the commandline so i never drawed much attention 
to it, but /var/log/xen/xl-guest.log shows:

    Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
    Domain 19 has shut down, reason code 0 0x0
    Action for shutdown reason code 0 is destroy
    Domain 19 needs to be cleaned up: destroying the domain
    libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
    libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
    libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
    libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
    Done. Exiting now

So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 20:05:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20:05:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtiqM-0008Ri-Gg; Wed, 26 Nov 2014 20:05:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XtiqL-0008Rb-1F
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 20:05:41 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	2B/A9-01660-49236745; Wed, 26 Nov 2014 20:05:40 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417032338!5926297!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 364 invoked from network); 26 Nov 2014 20:05:39 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 20:05:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417032339; x=1448568339;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=stfehgN6aO0IKN0GGcmTdythICmiXuTO6TIchUpiK5E=;
	b=iwC9bj5GFaSh2r1aqEer8EppF3GH60+zsLiNkitnA0vzHkCQSKDDGaVX
	7BNVqGwUNfz3LCL569fl48kPKarGCE1Yr0u3Km+nqiyo47ue1nxvQQiyk
	PMIvLBQdyoXcdXVH0OwD87Q7IIr/2xD76/E1pft8ULl/JmrhEC0ZFQSWL o=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by fldsmtpe04.verizon.com with ESMTP; 26 Nov 2014 20:05:38 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="878784863"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.106.142])
	by fldsmtpi02.verizon.com with ESMTP; 26 Nov 2014 20:05:36 +0000
Message-ID: <54763290.4030104@terremark.com>
Date: Wed, 26 Nov 2014 15:05:36 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
	<alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
	<1416994330.11944.25.camel@citrix.com>
	<alpine.DEB.2.02.1411261239160.14135@kaball.uk.xensource.com>
	<1417007040.11944.50.camel@citrix.com>
	<20141126144040.GD8735@laptop.dumpdata.com>
In-Reply-To: <20141126144040.GD8735@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/26/14 09:40, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 26, 2014 at 01:04:00PM +0000, Ian Campbell wrote:
>> On Wed, 2014-11-26 at 12:39 +0000, Stefano Stabellini wrote:
>>> On Wed, 26 Nov 2014, Ian Campbell wrote:
>>>> On Tue, 2014-11-25 at 17:05 +0000, Stefano Stabellini wrote:
>>>>> On Tue, 25 Nov 2014, Ian Campbell wrote:
>>>>>> On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
>>>>>>> On Tue, 25 Nov 2014, Ian Campbell wrote:
>>>>>>>> On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
>>>>>>>>> Account for the extra memory needed for the rom files of any emulated nics:
>>>>>>>>> QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
>>>>>>>>> each them. Assume 256K each.
>>>>>>>> I suppose this will have to do for 4.5. Can we do something better in
>>>>>>>> the future -- like figuring out a way for guests to have
>>>>>>>> "not-really-RAM" allocations like this which are made by the toolstack
>>>>>>>> and happen to be backed by RAM not count or something.
>>>>>>>>
>>>>>>>>> This patch fixes a QEMU abort() when more than 4 emulated nics are
>>>>>>>>> assigned to a VM.
>>>>>>>> Are you also going to fix qemu to fail gracefully if it cannot deploy
>>>>>>>> option roms? abort() seems a bit extreme.
>>>>>>>>
>>>>>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>>>>>>> CC: Don Slutz <dslutz@verizon.com>
>>>>>>>>> CC: hanyandong <hanyandong@iie.ac.cn>
>>>>>>>>> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>>>>> CC: Ian Campbell <Ian.Campbell@citrix.com>
>>>>>>>>> CC: Wei Liu <wei.liu2@citrix.com>
>>>>>>>> You missed Ian J. I've added him.
>>>>>>> Actually Wei suggested a better alternative: I could call
>>>>>>> xc_domain_setmaxmem directly from QEMU. That makes much more sense.
>>>>>> xl mem-set would do it again, but not taking qemu's extras into account,
>>>>>> unless you communicate the overhead somehow...
>>>>> We could start reading the current maxmem and add to it in
>>>>> libxl_set_memory_target. Or we could write the maxmem to xenstore and
>>>>> read it back again.  Given that the allocations are only done by QEMU at
>>>>> initialization time, I don't think we need to worry about concurrency
>>>>> here.
>>>> Might work, but it's a bit scary for 4.5, I would expect there to be
>>>> subtle knock on effects from this sort of thing :-/
>>>   
>>> Given that this is not a regression, we could wait for 4.6 to commit the
>>> fix and then if it doesn't cause any unwanted side effects, we could
>>> backport it?
>> That's not a bad plan. Release noting "you can't create more than 4
>> emulated NICs" doesn't seem so bad to me.

The Release note needs to include that e1000 & rtl8139 have this 
restriction.
vmxnet3 does not (and cannot be used for PXE boot).

    -Don Slutz

> <wipes out the sweat from his forehead>
>
> 4.6 it is then!
>> Ian.
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 20:05:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20:05:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtiqM-0008Ri-Gg; Wed, 26 Nov 2014 20:05:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XtiqL-0008Rb-1F
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 20:05:41 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	2B/A9-01660-49236745; Wed, 26 Nov 2014 20:05:40 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417032338!5926297!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 364 invoked from network); 26 Nov 2014 20:05:39 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 20:05:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417032339; x=1448568339;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=stfehgN6aO0IKN0GGcmTdythICmiXuTO6TIchUpiK5E=;
	b=iwC9bj5GFaSh2r1aqEer8EppF3GH60+zsLiNkitnA0vzHkCQSKDDGaVX
	7BNVqGwUNfz3LCL569fl48kPKarGCE1Yr0u3Km+nqiyo47ue1nxvQQiyk
	PMIvLBQdyoXcdXVH0OwD87Q7IIr/2xD76/E1pft8ULl/JmrhEC0ZFQSWL o=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by fldsmtpe04.verizon.com with ESMTP; 26 Nov 2014 20:05:38 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="878784863"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.106.142])
	by fldsmtpi02.verizon.com with ESMTP; 26 Nov 2014 20:05:36 +0000
Message-ID: <54763290.4030104@terremark.com>
Date: Wed, 26 Nov 2014 15:05:36 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1416925448.32327.27.camel@citrix.com>
	<alpine.DEB.2.02.1411251648280.14135@kaball.uk.xensource.com>
	<1416934562.11944.22.camel@citrix.com>
	<alpine.DEB.2.02.1411251658310.14135@kaball.uk.xensource.com>
	<1416994330.11944.25.camel@citrix.com>
	<alpine.DEB.2.02.1411261239160.14135@kaball.uk.xensource.com>
	<1417007040.11944.50.camel@citrix.com>
	<20141126144040.GD8735@laptop.dumpdata.com>
In-Reply-To: <20141126144040.GD8735@laptop.dumpdata.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/26/14 09:40, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 26, 2014 at 01:04:00PM +0000, Ian Campbell wrote:
>> On Wed, 2014-11-26 at 12:39 +0000, Stefano Stabellini wrote:
>>> On Wed, 26 Nov 2014, Ian Campbell wrote:
>>>> On Tue, 2014-11-25 at 17:05 +0000, Stefano Stabellini wrote:
>>>>> On Tue, 25 Nov 2014, Ian Campbell wrote:
>>>>>> On Tue, 2014-11-25 at 16:49 +0000, Stefano Stabellini wrote:
>>>>>>> On Tue, 25 Nov 2014, Ian Campbell wrote:
>>>>>>>> On Tue, 2014-11-25 at 12:43 +0000, Stefano Stabellini wrote:
>>>>>>>>> Account for the extra memory needed for the rom files of any emulated nics:
>>>>>>>>> QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
>>>>>>>>> each them. Assume 256K each.
>>>>>>>> I suppose this will have to do for 4.5. Can we do something better in
>>>>>>>> the future -- like figuring out a way for guests to have
>>>>>>>> "not-really-RAM" allocations like this which are made by the toolstack
>>>>>>>> and happen to be backed by RAM not count or something.
>>>>>>>>
>>>>>>>>> This patch fixes a QEMU abort() when more than 4 emulated nics are
>>>>>>>>> assigned to a VM.
>>>>>>>> Are you also going to fix qemu to fail gracefully if it cannot deploy
>>>>>>>> option roms? abort() seems a bit extreme.
>>>>>>>>
>>>>>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>>>>>>> CC: Don Slutz <dslutz@verizon.com>
>>>>>>>>> CC: hanyandong <hanyandong@iie.ac.cn>
>>>>>>>>> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>>>>> CC: Ian Campbell <Ian.Campbell@citrix.com>
>>>>>>>>> CC: Wei Liu <wei.liu2@citrix.com>
>>>>>>>> You missed Ian J. I've added him.
>>>>>>> Actually Wei suggested a better alternative: I could call
>>>>>>> xc_domain_setmaxmem directly from QEMU. That makes much more sense.
>>>>>> xl mem-set would do it again, but not taking qemu's extras into account,
>>>>>> unless you communicate the overhead somehow...
>>>>> We could start reading the current maxmem and add to it in
>>>>> libxl_set_memory_target. Or we could write the maxmem to xenstore and
>>>>> read it back again.  Given that the allocations are only done by QEMU at
>>>>> initialization time, I don't think we need to worry about concurrency
>>>>> here.
>>>> Might work, but it's a bit scary for 4.5, I would expect there to be
>>>> subtle knock on effects from this sort of thing :-/
>>>   
>>> Given that this is not a regression, we could wait for 4.6 to commit the
>>> fix and then if it doesn't cause any unwanted side effects, we could
>>> backport it?
>> That's not a bad plan. Release noting "you can't create more than 4
>> emulated NICs" doesn't seem so bad to me.

The Release note needs to include that e1000 & rtl8139 have this 
restriction.
vmxnet3 does not (and cannot be used for PXE boot).

    -Don Slutz

> <wipes out the sweat from his forehead>
>
> 4.6 it is then!
>> Ian.
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 20:08:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtism-000096-2G; Wed, 26 Nov 2014 20:08:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dev@zheng.li>) id 1Xtisk-000090-Jo
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 20:08:10 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	9D/A3-02702-A2336745; Wed, 26 Nov 2014 20:08:10 +0000
X-Env-Sender: dev@zheng.li
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417032489!10459091!1
X-Originating-IP: [194.14.179.111]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1990 invoked from network); 26 Nov 2014 20:08:09 -0000
Received: from svr.xenplanet.org (HELO svr.xenplanet.org) (194.14.179.111)
	by server-5.tower-27.messagelabs.com with SMTP;
	26 Nov 2014 20:08:09 -0000
Received: from zeta.local (cpc24-cmbg15-2-0-cust108.5-4.cable.virginm.net
	[86.27.181.109])
	by svr.xenplanet.org (Postfix) with ESMTPSA id C3314680052;
	Wed, 26 Nov 2014 20:08:07 +0000 (UTC)
Message-ID: <54763326.7050705@zheng.li>
Date: Wed, 26 Nov 2014 20:08:06 +0000
From: Zheng Li <dev@zheng.li>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:34.0) Gecko/20100101 Thunderbird/34.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Dave Scott <Dave.Scott@citrix.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>	<5475F3DF.2070907@zheng.li>	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
	<547623EE.2070303@citrix.com>
In-Reply-To: <547623EE.2070303@citrix.com>
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/11/2014 19:03, Andrew Cooper wrote:
> Strictly speaking Zheng, not being a maintainer, can't ack the patch,
> given what I believe to be Xens current rules for these things.
> However, as the author of the code and comment in this thread, his ack
> can reasonably be considered equivalent to a  Reviewed-by:  I guess this
> is just a matter of semantics.
>
> Furthermore, as we all share an office, I have already been through this
> process informally, and have confirmed the fix under my Xen-4.5 based
> XenServer branch.  There appear to be 100% less "error -EINVAL" messages
> in the logs.
>

Agreed. I was a bit confused by the "XXX-by" semantics. As Andy mentioned, he already went through the patch with me offline, so here is the line if more appropriate:

Reviewed-by: Zheng Li <dev@zheng.li>

Thanks,
Zheng


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 20:08:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtism-000096-2G; Wed, 26 Nov 2014 20:08:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dev@zheng.li>) id 1Xtisk-000090-Jo
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 20:08:10 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	9D/A3-02702-A2336745; Wed, 26 Nov 2014 20:08:10 +0000
X-Env-Sender: dev@zheng.li
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417032489!10459091!1
X-Originating-IP: [194.14.179.111]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1990 invoked from network); 26 Nov 2014 20:08:09 -0000
Received: from svr.xenplanet.org (HELO svr.xenplanet.org) (194.14.179.111)
	by server-5.tower-27.messagelabs.com with SMTP;
	26 Nov 2014 20:08:09 -0000
Received: from zeta.local (cpc24-cmbg15-2-0-cust108.5-4.cable.virginm.net
	[86.27.181.109])
	by svr.xenplanet.org (Postfix) with ESMTPSA id C3314680052;
	Wed, 26 Nov 2014 20:08:07 +0000 (UTC)
Message-ID: <54763326.7050705@zheng.li>
Date: Wed, 26 Nov 2014 20:08:06 +0000
From: Zheng Li <dev@zheng.li>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:34.0) Gecko/20100101 Thunderbird/34.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Dave Scott <Dave.Scott@citrix.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>	<5475F3DF.2070907@zheng.li>	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
	<547623EE.2070303@citrix.com>
In-Reply-To: <547623EE.2070303@citrix.com>
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/11/2014 19:03, Andrew Cooper wrote:
> Strictly speaking Zheng, not being a maintainer, can't ack the patch,
> given what I believe to be Xens current rules for these things.
> However, as the author of the code and comment in this thread, his ack
> can reasonably be considered equivalent to a  Reviewed-by:  I guess this
> is just a matter of semantics.
>
> Furthermore, as we all share an office, I have already been through this
> process informally, and have confirmed the fix under my Xen-4.5 based
> XenServer branch.  There appear to be 100% less "error -EINVAL" messages
> in the logs.
>

Agreed. I was a bit confused by the "XXX-by" semantics. As Andy mentioned, he already went through the patch with me offline, so here is the line if more appropriate:

Reviewed-by: Zheng Li <dev@zheng.li>

Thanks,
Zheng


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 20:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtj1X-0000SM-3q; Wed, 26 Nov 2014 20:17:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xtj1V-0000SH-PD
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 20:17:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9B/41-15461-94536745; Wed, 26 Nov 2014 20:17:13 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417033031!12138932!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23142 invoked from network); 26 Nov 2014 20:17:12 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 20:17:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417033032; x=1448569032;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=xCUibkBnpmYBQS62lYvZrhipfEnw0MNpPMmney1BkYU=;
	b=llcOm3sggmBeqD34TfGyQBb5jFORRBN+/ja3S51ci4BvXBsWkVZ9J1l4
	8s6gttXogYPLIVdY+Pd30iLfgDzHu6NnhN8nSP306TdSLB4T8TvxSYm1r
	Ps+ZlfPlLBKkhrBRZBo4hEA/353x4kJOkvj5rSqONYHosMtszaF+tCR1e k=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 26 Nov 2014 20:17:10 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="880313358"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.106.142])
	by fldsmtpi03.verizon.com with ESMTP; 26 Nov 2014 20:17:09 +0000
Message-ID: <54763544.9070207@terremark.com>
Date: Wed, 26 Nov 2014 15:17:08 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/14 07:43, Stefano Stabellini wrote:
> Account for the extra memory needed for the rom files of any emulated nics:
> QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> each them. Assume 256K each.

I have seen that this is no longer planned for 4.5, but I do think that 
libxl will
still be changed for this.

so

>   int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
>   {
>       GC_INIT(ctx);
>       char *mem, *endptr;
>       uint32_t memorykb;
>       char *dompath = libxl__xs_get_dompath(gc, domid);
> -    int rc = 1;
> +    int rc = 1, romsize;
>   
>       mem = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/memory/target", dompath));
>       if (!mem) {
> @@ -4550,11 +4577,18 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
>           goto out;
>       }
> -    rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + LIBXL_MAXMEM_CONSTANT);
> +    rc = libxl__get_rom_memory_kb(gc, domid, NULL);
> +    if (rc < 0)
> +        goto out;
> +    romsize = rc;
> +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> +                             + romsize);

Keeping LIBXL_MAXMEM_CONSTANT is wrong.  Should be dropped.

>       if (rc != 0) {
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                   "xc_domain_setmaxmem domid=%d memkb=%d failed "
> -                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
> +                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT +
> +                romsize, rc);
>           goto out;
>       }
>   

And here.

> @@ -4683,7 +4717,7 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
>           int32_t target_memkb, int relative, int enforce)
>   {
>       GC_INIT(ctx);
> -    int rc = 1, abort_transaction = 0;
> +    int rc = 1, abort_transaction = 0, romsize;
>       uint32_t memorykb = 0, videoram = 0;
>       uint32_t current_target_memkb = 0, new_target_memkb = 0;
>       uint32_t current_max_memkb = 0;
> @@ -4769,12 +4803,19 @@ retry_transaction:
>   
>       if (enforce) {
>           memorykb = new_target_memkb;
> +        rc = libxl__get_rom_memory_kb(gc, domid, NULL);
> +        if (rc < 0) {
> +            abort_transaction = 1;
> +            goto out;
> +        }
> +        romsize = rc;
>           rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
> -                LIBXL_MAXMEM_CONSTANT);
> +                LIBXL_MAXMEM_CONSTANT + romsize);

And here.

>           if (rc != 0) {
>               LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                       "xc_domain_setmaxmem domid=%d memkb=%d failed "
> -                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
> +                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT +
> +                    romsize, rc);
>               abort_transaction = 1;
>               goto out;
>           }
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 74ea84b..733f4c7 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -305,7 +305,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>       libxl_domain_build_info *const info = &d_config->b_info;
>       libxl_ctx *ctx = libxl__gc_owner(gc);
>       char *xs_domid, *con_domid;
> -    int rc;
> +    int rc, romsize;
>   
>       if (xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus) != 0) {
>           LOG(ERROR, "Couldn't set max vcpu count");
> @@ -405,8 +405,12 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>           }
>       }
>   
> +	rc = libxl__get_rom_memory_kb(gc, domid, d_config);
> +	if (rc < 0)
> +		return rc;
> +	romsize = rc;
>       if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> -        LIBXL_MAXMEM_CONSTANT) < 0) {
> +        LIBXL_MAXMEM_CONSTANT + romsize) < 0) {
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't set max memory");
>           return ERROR_FAIL;
>       }
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4361421..33826ea 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -90,6 +90,7 @@
>   #define LIBXL_XENCONSOLE_LIMIT 1048576
>   #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
>   #define LIBXL_MAXMEM_CONSTANT 1024
> +#define LIBXL_ROMSIZE_KB 256
>   #define LIBXL_PV_EXTRA_MEMORY 1024
>   #define LIBXL_HVM_EXTRA_MEMORY 2048

This should be "romsize" + 1024 as far as I know.

>   #define LIBXL_MIN_DOM0_MEM (128*1024)
> @@ -1023,6 +1024,12 @@ _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
>   _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
>                                             uint32_t domid, const char *cmd);
>   
> +/* Returns the amount of extra mem required to allocate roms or an libxl
> + * error code on error.
> + * The *d_config parameter is optional.
> + */
> +_hidden int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
> +
>   /* from xl_device */
>   _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
>   _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);

     -Don Slutz

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 20:17:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtj1X-0000SM-3q; Wed, 26 Nov 2014 20:17:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xtj1V-0000SH-PD
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 20:17:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9B/41-15461-94536745; Wed, 26 Nov 2014 20:17:13 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417033031!12138932!1
X-Originating-IP: [140.108.26.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQwLjEwOC4yNi4xNDMgPT4gMjYwNTMz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23142 invoked from network); 26 Nov 2014 20:17:12 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 20:17:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417033032; x=1448569032;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=xCUibkBnpmYBQS62lYvZrhipfEnw0MNpPMmney1BkYU=;
	b=llcOm3sggmBeqD34TfGyQBb5jFORRBN+/ja3S51ci4BvXBsWkVZ9J1l4
	8s6gttXogYPLIVdY+Pd30iLfgDzHu6NnhN8nSP306TdSLB4T8TvxSYm1r
	Ps+ZlfPlLBKkhrBRZBo4hEA/353x4kJOkvj5rSqONYHosMtszaF+tCR1e k=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 26 Nov 2014 20:17:10 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="880313358"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.106.142])
	by fldsmtpi03.verizon.com with ESMTP; 26 Nov 2014 20:17:09 +0000
Message-ID: <54763544.9070207@terremark.com>
Date: Wed, 26 Nov 2014 15:17:08 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1416919412-10104-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>,
	hanyandong <hanyandong@iie.ac.cn>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5] libxl: account for romfile 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/14 07:43, Stefano Stabellini wrote:
> Account for the extra memory needed for the rom files of any emulated nics:
> QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
> each them. Assume 256K each.

I have seen that this is no longer planned for 4.5, but I do think that 
libxl will
still be changed for this.

so

>   int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
>   {
>       GC_INIT(ctx);
>       char *mem, *endptr;
>       uint32_t memorykb;
>       char *dompath = libxl__xs_get_dompath(gc, domid);
> -    int rc = 1;
> +    int rc = 1, romsize;
>   
>       mem = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/memory/target", dompath));
>       if (!mem) {
> @@ -4550,11 +4577,18 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be greater than or or equal to memory_dynamic_max\n");
>           goto out;
>       }
> -    rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + LIBXL_MAXMEM_CONSTANT);
> +    rc = libxl__get_rom_memory_kb(gc, domid, NULL);
> +    if (rc < 0)
> +        goto out;
> +    romsize = rc;
> +    rc = xc_domain_setmaxmem(ctx->xch, domid,
> +                             max_memkb + LIBXL_MAXMEM_CONSTANT
> +                             + romsize);

Keeping LIBXL_MAXMEM_CONSTANT is wrong.  Should be dropped.

>       if (rc != 0) {
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                   "xc_domain_setmaxmem domid=%d memkb=%d failed "
> -                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
> +                "rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT +
> +                romsize, rc);
>           goto out;
>       }
>   

And here.

> @@ -4683,7 +4717,7 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
>           int32_t target_memkb, int relative, int enforce)
>   {
>       GC_INIT(ctx);
> -    int rc = 1, abort_transaction = 0;
> +    int rc = 1, abort_transaction = 0, romsize;
>       uint32_t memorykb = 0, videoram = 0;
>       uint32_t current_target_memkb = 0, new_target_memkb = 0;
>       uint32_t current_max_memkb = 0;
> @@ -4769,12 +4803,19 @@ retry_transaction:
>   
>       if (enforce) {
>           memorykb = new_target_memkb;
> +        rc = libxl__get_rom_memory_kb(gc, domid, NULL);
> +        if (rc < 0) {
> +            abort_transaction = 1;
> +            goto out;
> +        }
> +        romsize = rc;
>           rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
> -                LIBXL_MAXMEM_CONSTANT);
> +                LIBXL_MAXMEM_CONSTANT + romsize);

And here.

>           if (rc != 0) {
>               LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                       "xc_domain_setmaxmem domid=%d memkb=%d failed "
> -                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
> +                    "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT +
> +                    romsize, rc);
>               abort_transaction = 1;
>               goto out;
>           }
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 74ea84b..733f4c7 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -305,7 +305,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>       libxl_domain_build_info *const info = &d_config->b_info;
>       libxl_ctx *ctx = libxl__gc_owner(gc);
>       char *xs_domid, *con_domid;
> -    int rc;
> +    int rc, romsize;
>   
>       if (xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus) != 0) {
>           LOG(ERROR, "Couldn't set max vcpu count");
> @@ -405,8 +405,12 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>           }
>       }
>   
> +	rc = libxl__get_rom_memory_kb(gc, domid, d_config);
> +	if (rc < 0)
> +		return rc;
> +	romsize = rc;
>       if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> -        LIBXL_MAXMEM_CONSTANT) < 0) {
> +        LIBXL_MAXMEM_CONSTANT + romsize) < 0) {
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't set max memory");
>           return ERROR_FAIL;
>       }
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4361421..33826ea 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -90,6 +90,7 @@
>   #define LIBXL_XENCONSOLE_LIMIT 1048576
>   #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
>   #define LIBXL_MAXMEM_CONSTANT 1024
> +#define LIBXL_ROMSIZE_KB 256
>   #define LIBXL_PV_EXTRA_MEMORY 1024
>   #define LIBXL_HVM_EXTRA_MEMORY 2048

This should be "romsize" + 1024 as far as I know.

>   #define LIBXL_MIN_DOM0_MEM (128*1024)
> @@ -1023,6 +1024,12 @@ _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
>   _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
>                                             uint32_t domid, const char *cmd);
>   
> +/* Returns the amount of extra mem required to allocate roms or an libxl
> + * error code on error.
> + * The *d_config parameter is optional.
> + */
> +_hidden int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
> +
>   /* from xl_device */
>   _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
>   _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);

     -Don Slutz

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 20:39:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20:39:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtjMe-0000sp-Gn; Wed, 26 Nov 2014 20:39:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtjMd-0000sk-5b
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 20:39:03 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	3C/B6-09284-66A36745; Wed, 26 Nov 2014 20:39:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417034340!9665073!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3529 invoked from network); 26 Nov 2014 20:39:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 20:39:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="197187339"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 15:38:58 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtjMY-0004LZ-MK;
	Wed, 26 Nov 2014 20:38:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtjMY-0006yS-AE;
	Wed, 26 Nov 2014 20:38:58 +0000
Date: Wed, 26 Nov 2014 20:38:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31858-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31858: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31858 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31858/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl           11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                5d01410fe4d92081f349b013a2e7a95429e4f2c9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
644 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27197 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 Nov 26 20:39:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20:39:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtjMe-0000sp-Gn; Wed, 26 Nov 2014 20:39:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtjMd-0000sk-5b
	for xen-devel@lists.xensource.com; Wed, 26 Nov 2014 20:39:03 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	3C/B6-09284-66A36745; Wed, 26 Nov 2014 20:39:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417034340!9665073!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3529 invoked from network); 26 Nov 2014 20:39:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 20:39:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="197187339"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 15:38:58 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtjMY-0004LZ-MK;
	Wed, 26 Nov 2014 20:38:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtjMY-0006yS-AE;
	Wed, 26 Nov 2014 20:38:58 +0000
Date: Wed, 26 Nov 2014 20:38:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31858-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31858: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31858 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31858/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl           11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                5d01410fe4d92081f349b013a2e7a95429e4f2c9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
644 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 27197 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 Nov 26 20:45:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20:45:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtjSU-00018b-AZ; Wed, 26 Nov 2014 20:45:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@citrix.com>) id 1XtjSS-00018W-TM
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 20:45:05 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	F9/1E-05632-0DB36745; Wed, 26 Nov 2014 20:45:04 +0000
X-Env-Sender: Dave.Scott@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417034703!13953977!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20964 invoked from network); 26 Nov 2014 20:45:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 20:45:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="27216667"
From: Dave Scott <Dave.Scott@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
	in fd event handling
Thread-Index: AQHQCY7+MCUbGmecRkCFQqBESlOOyZxzKHYAgAAE2ACAACJogA==
Date: Wed, 26 Nov 2014 20:44:41 +0000
Message-ID: <370F66B9-E96D-4BE2-9E08-132CCBD28E42@citrix.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
In-Reply-To: <20141126184130.GB13384@laptop.dumpdata.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-ID: <613502D3D05C6D47B889A2E077608566@citrix.com>
MIME-Version: 1.0
X-DLP: AMS1
Cc: Zheng Li <dev@zheng.li>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQo+IE9uIDI2IE5vdiAyMDE0LCBhdCAxODo0MSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25y
YWQud2lsa0BvcmFjbGUuY29tPiB3cm90ZToNCj4gDQo+IE9uIFdlZCwgTm92IDI2LCAyMDE0IGF0
IDA2OjI0OjExUE0gKzAwMDAsIERhdmUgU2NvdHQgd3JvdGU6DQo+PiANCj4+PiBPbiAyNiBOb3Yg
MjAxNCwgYXQgMTU6MzgsIFpoZW5nIExpIDxkZXZAemhlbmcubGk+IHdyb3RlOg0KPj4+IA0KPj4+
IE9uIDI2LzExLzIwMTQgMTU6MDksIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+Pj4+IFRoaXMgbWFr
ZXMgZmllbGRzIDAgYW5kIDEgdHJ1ZSBtb3JlIG9mdGVuIHRoYW4gdGhleSBzaG91bGQgYmUsIHJl
c3VsdGluZw0KPj4+PiBwcm9ibGVtcyB3aGVuIGhhbmRsaW5nIGV2ZW50cy4NCj4+PiANCj4+PiBJ
bmRlZWQsIGxvb2tzIGxpa2UgYSBtaXN0YWtlIEkgbWFkZSB3aGVuIHJld3JpdGluZyB0aGUgbG9n
aWMgdGVybXMgbGF0ZWx5LiBUaGUgcmVzdWx0IGlzIFBPTExVUCBvciBQT0xMRVJSIGV2ZW50cyBi
ZWluZyByZXR1cm5lZCBpbiBtb3JlIGNhdGVnb3JpZXMgdGhhbiB3ZSdkIGludGVyZXN0LiBUaGFu
a3MgZm9yIGZpeGluZyB0aGlzIQ0KPj4+IA0KPj4+IEFja2VkLWJ5OiBaaGVuZyBMaSA8ZGV2QHpo
ZW5nLmxpPg0KPj4gDQo+PiBUaGlzIGFsc28gbG9va3MgZmluZSB0byBtZQ0KPj4gDQo+PiBBY2tl
ZC1ieTogRGF2aWQgU2NvdHQgPGRhdmUuc2NvdHRAY2l0cml4LmNvbT4NCj4gDQo+IFdvdWxkIGl0
IGJlIHBvc3NpYmxlIHRvIGdldCBhbiBSZXZpZXdlZC1ieSBwbGVhc2U/DQoNCknigJlsbCBjZXJ0
YWlubHkgb2ZmZXINCg0KUmV2aWV3ZWQtYnk6IERhdmlkIFNjb3R0IDxkYXZlLnNjb3R0QGNpdHJp
eC5jb20+DQoNCkNoZWVycywNCkRhdmUNCg0KPiANCj4gVGhhbmsgeW91Lg0KPj4gDQo+PiBDaGVl
cnMsDQo+PiBEYXZlDQo+PiANCj4+PiANCj4+PiANCj4+PiBDaGVlcnMsDQo+Pj4gWmhlbmcNCj4+
PiANCj4+PiANCj4+Pj4gLS0tDQo+Pj4+IA0KPj4+PiBUaGlzIHdhcyBkaXNjb3ZlcmVkIHdpdGgg
WGVuU2VydmVycyBpbnRlcm5hbCBDb3Zlcml0eSBpbnN0YW5jZS4gIEkgaGF2ZSB5ZXQgdG8NCj4+
Pj4gd29yayBvdXQgd2h5IHRoZSBpc3N1ZSBpcyBub3QgaWRlbnRpZmllZCBieSB0aGUgdXBzdHJl
YW0gY292ZXJpdHkgc2Nhbm5pbmcuDQo+Pj4+IA0KPj4+PiBLb25yYWQ6IFRoaXMgaXMgYSBidWcg
aW4gdGhlIGRlZmF1bHQgZXZlbnQgaGFuZGxpbmcgdXNlZCBieSBveGVuc3RvcmVkIGluIDQuNSwN
Cj4+Pj4gYXMgdGhlIGRlZmF1bHQgc3dpdGNoZWQgZnJvbSBzZWxlY3QoKSB0byBwb2xsKCkgaW4g
dGhlIDQuNSB0aW1lZnJhbWUuICBJdA0KPj4+PiB3b3VsZCBhcHBlYXIgdGhhdCB0aGUgbmVnYXRp
dmUgc2lkZSBlZmZlY3RzIGFyZSBsaW1pdGVkIHRvIGp1c3QgbG9nc3BhbSBhYm91dA0KPj4+PiBj
ZXJ0YWluIGNsaWVudHMgYXR0ZW1wdGluZyBpbnZhbGlkIGFjdGlvbnMsIGJ1dCBJIGNhbid0IHJ1
bGUgb3V0IGFueXRoaW5nIG1vcmUNCj4+Pj4gcHJvYmxlbWF0aWMuDQo+Pj4+IC0tLQ0KPj4+PiB0
b29scy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJzLmMgfCAgICA0ICsrLS0NCj4+Pj4gMSBm
aWxlIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4+Pj4gDQo+Pj4+
IGRpZmYgLS1naXQgYS90b29scy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJzLmMgYi90b29s
cy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJzLmMNCj4+Pj4gaW5kZXggNGE4ZWRiNS4uYWY3
MmI4NCAxMDA2NDQNCj4+Pj4gLS0tIGEvdG9vbHMvb2NhbWwveGVuc3RvcmVkL3NlbGVjdF9zdHVi
cy5jDQo+Pj4+ICsrKyBiL3Rvb2xzL29jYW1sL3hlbnN0b3JlZC9zZWxlY3Rfc3R1YnMuYw0KPj4+
PiBAQCAtNTYsOCArNTYsOCBAQCBDQU1McHJpbSB2YWx1ZSBzdHViX3NlbGVjdF9vbl9wb2xsKHZh
bHVlIGZkX2V2ZW50cywgdmFsdWUgdGltZW8pIHsNCj4+Pj4gCQkJZXZlbnRzID0gRmllbGQoRmll
bGQoZmRfZXZlbnRzLCBpKSwgMSk7DQo+Pj4+IA0KPj4+PiAJCQlpZiAoY19mZHNbaV0ucmV2ZW50
cyAmIFBPTExOVkFMKSB1bml4X2Vycm9yKEVCQURGLCAic2VsZWN0IiwgTm90aGluZyk7DQo+Pj4+
IC0JCQlGaWVsZChldmVudHMsIDApID0gVmFsX2Jvb2woY19mZHNbaV0uZXZlbnRzIHwgUE9MTElO
ICAmJiBjX2Zkc1tpXS5yZXZlbnRzICYgKFBPTExJTiB8UE9MTEhVUHxQT0xMRVJSKSk7DQo+Pj4+
IC0JCQlGaWVsZChldmVudHMsIDEpID0gVmFsX2Jvb2woY19mZHNbaV0uZXZlbnRzIHwgUE9MTE9V
VCAmJiBjX2Zkc1tpXS5yZXZlbnRzICYgKFBPTExPVVR8UE9MTEhVUHxQT0xMRVJSKSk7DQo+Pj4+
ICsJCQlGaWVsZChldmVudHMsIDApID0gVmFsX2Jvb2woY19mZHNbaV0uZXZlbnRzICYgUE9MTElO
ICAmJiBjX2Zkc1tpXS5yZXZlbnRzICYgKFBPTExJTiB8UE9MTEhVUHxQT0xMRVJSKSk7DQo+Pj4+
ICsJCQlGaWVsZChldmVudHMsIDEpID0gVmFsX2Jvb2woY19mZHNbaV0uZXZlbnRzICYgUE9MTE9V
VCAmJiBjX2Zkc1tpXS5yZXZlbnRzICYgKFBPTExPVVR8UE9MTEhVUHxQT0xMRVJSKSk7DQo+Pj4+
IAkJCUZpZWxkKGV2ZW50cywgMikgPSBWYWxfYm9vbChjX2Zkc1tpXS5yZXZlbnRzICYgUE9MTFBS
SSk7DQo+Pj4+IA0KPj4+PiAJCX0NCj4+Pj4gDQo+PiANCj4gDQo+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QN
Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcNCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Nov 26 20:45:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20:45:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtjSU-00018b-AZ; Wed, 26 Nov 2014 20:45:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@citrix.com>) id 1XtjSS-00018W-TM
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 20:45:05 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	F9/1E-05632-0DB36745; Wed, 26 Nov 2014 20:45:04 +0000
X-Env-Sender: Dave.Scott@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417034703!13953977!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20964 invoked from network); 26 Nov 2014 20:45:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 20:45:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="27216667"
From: Dave Scott <Dave.Scott@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
	in fd event handling
Thread-Index: AQHQCY7+MCUbGmecRkCFQqBESlOOyZxzKHYAgAAE2ACAACJogA==
Date: Wed, 26 Nov 2014 20:44:41 +0000
Message-ID: <370F66B9-E96D-4BE2-9E08-132CCBD28E42@citrix.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
In-Reply-To: <20141126184130.GB13384@laptop.dumpdata.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-ID: <613502D3D05C6D47B889A2E077608566@citrix.com>
MIME-Version: 1.0
X-DLP: AMS1
Cc: Zheng Li <dev@zheng.li>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQo+IE9uIDI2IE5vdiAyMDE0LCBhdCAxODo0MSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25y
YWQud2lsa0BvcmFjbGUuY29tPiB3cm90ZToNCj4gDQo+IE9uIFdlZCwgTm92IDI2LCAyMDE0IGF0
IDA2OjI0OjExUE0gKzAwMDAsIERhdmUgU2NvdHQgd3JvdGU6DQo+PiANCj4+PiBPbiAyNiBOb3Yg
MjAxNCwgYXQgMTU6MzgsIFpoZW5nIExpIDxkZXZAemhlbmcubGk+IHdyb3RlOg0KPj4+IA0KPj4+
IE9uIDI2LzExLzIwMTQgMTU6MDksIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+Pj4+IFRoaXMgbWFr
ZXMgZmllbGRzIDAgYW5kIDEgdHJ1ZSBtb3JlIG9mdGVuIHRoYW4gdGhleSBzaG91bGQgYmUsIHJl
c3VsdGluZw0KPj4+PiBwcm9ibGVtcyB3aGVuIGhhbmRsaW5nIGV2ZW50cy4NCj4+PiANCj4+PiBJ
bmRlZWQsIGxvb2tzIGxpa2UgYSBtaXN0YWtlIEkgbWFkZSB3aGVuIHJld3JpdGluZyB0aGUgbG9n
aWMgdGVybXMgbGF0ZWx5LiBUaGUgcmVzdWx0IGlzIFBPTExVUCBvciBQT0xMRVJSIGV2ZW50cyBi
ZWluZyByZXR1cm5lZCBpbiBtb3JlIGNhdGVnb3JpZXMgdGhhbiB3ZSdkIGludGVyZXN0LiBUaGFu
a3MgZm9yIGZpeGluZyB0aGlzIQ0KPj4+IA0KPj4+IEFja2VkLWJ5OiBaaGVuZyBMaSA8ZGV2QHpo
ZW5nLmxpPg0KPj4gDQo+PiBUaGlzIGFsc28gbG9va3MgZmluZSB0byBtZQ0KPj4gDQo+PiBBY2tl
ZC1ieTogRGF2aWQgU2NvdHQgPGRhdmUuc2NvdHRAY2l0cml4LmNvbT4NCj4gDQo+IFdvdWxkIGl0
IGJlIHBvc3NpYmxlIHRvIGdldCBhbiBSZXZpZXdlZC1ieSBwbGVhc2U/DQoNCknigJlsbCBjZXJ0
YWlubHkgb2ZmZXINCg0KUmV2aWV3ZWQtYnk6IERhdmlkIFNjb3R0IDxkYXZlLnNjb3R0QGNpdHJp
eC5jb20+DQoNCkNoZWVycywNCkRhdmUNCg0KPiANCj4gVGhhbmsgeW91Lg0KPj4gDQo+PiBDaGVl
cnMsDQo+PiBEYXZlDQo+PiANCj4+PiANCj4+PiANCj4+PiBDaGVlcnMsDQo+Pj4gWmhlbmcNCj4+
PiANCj4+PiANCj4+Pj4gLS0tDQo+Pj4+IA0KPj4+PiBUaGlzIHdhcyBkaXNjb3ZlcmVkIHdpdGgg
WGVuU2VydmVycyBpbnRlcm5hbCBDb3Zlcml0eSBpbnN0YW5jZS4gIEkgaGF2ZSB5ZXQgdG8NCj4+
Pj4gd29yayBvdXQgd2h5IHRoZSBpc3N1ZSBpcyBub3QgaWRlbnRpZmllZCBieSB0aGUgdXBzdHJl
YW0gY292ZXJpdHkgc2Nhbm5pbmcuDQo+Pj4+IA0KPj4+PiBLb25yYWQ6IFRoaXMgaXMgYSBidWcg
aW4gdGhlIGRlZmF1bHQgZXZlbnQgaGFuZGxpbmcgdXNlZCBieSBveGVuc3RvcmVkIGluIDQuNSwN
Cj4+Pj4gYXMgdGhlIGRlZmF1bHQgc3dpdGNoZWQgZnJvbSBzZWxlY3QoKSB0byBwb2xsKCkgaW4g
dGhlIDQuNSB0aW1lZnJhbWUuICBJdA0KPj4+PiB3b3VsZCBhcHBlYXIgdGhhdCB0aGUgbmVnYXRp
dmUgc2lkZSBlZmZlY3RzIGFyZSBsaW1pdGVkIHRvIGp1c3QgbG9nc3BhbSBhYm91dA0KPj4+PiBj
ZXJ0YWluIGNsaWVudHMgYXR0ZW1wdGluZyBpbnZhbGlkIGFjdGlvbnMsIGJ1dCBJIGNhbid0IHJ1
bGUgb3V0IGFueXRoaW5nIG1vcmUNCj4+Pj4gcHJvYmxlbWF0aWMuDQo+Pj4+IC0tLQ0KPj4+PiB0
b29scy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJzLmMgfCAgICA0ICsrLS0NCj4+Pj4gMSBm
aWxlIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4+Pj4gDQo+Pj4+
IGRpZmYgLS1naXQgYS90b29scy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJzLmMgYi90b29s
cy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJzLmMNCj4+Pj4gaW5kZXggNGE4ZWRiNS4uYWY3
MmI4NCAxMDA2NDQNCj4+Pj4gLS0tIGEvdG9vbHMvb2NhbWwveGVuc3RvcmVkL3NlbGVjdF9zdHVi
cy5jDQo+Pj4+ICsrKyBiL3Rvb2xzL29jYW1sL3hlbnN0b3JlZC9zZWxlY3Rfc3R1YnMuYw0KPj4+
PiBAQCAtNTYsOCArNTYsOCBAQCBDQU1McHJpbSB2YWx1ZSBzdHViX3NlbGVjdF9vbl9wb2xsKHZh
bHVlIGZkX2V2ZW50cywgdmFsdWUgdGltZW8pIHsNCj4+Pj4gCQkJZXZlbnRzID0gRmllbGQoRmll
bGQoZmRfZXZlbnRzLCBpKSwgMSk7DQo+Pj4+IA0KPj4+PiAJCQlpZiAoY19mZHNbaV0ucmV2ZW50
cyAmIFBPTExOVkFMKSB1bml4X2Vycm9yKEVCQURGLCAic2VsZWN0IiwgTm90aGluZyk7DQo+Pj4+
IC0JCQlGaWVsZChldmVudHMsIDApID0gVmFsX2Jvb2woY19mZHNbaV0uZXZlbnRzIHwgUE9MTElO
ICAmJiBjX2Zkc1tpXS5yZXZlbnRzICYgKFBPTExJTiB8UE9MTEhVUHxQT0xMRVJSKSk7DQo+Pj4+
IC0JCQlGaWVsZChldmVudHMsIDEpID0gVmFsX2Jvb2woY19mZHNbaV0uZXZlbnRzIHwgUE9MTE9V
VCAmJiBjX2Zkc1tpXS5yZXZlbnRzICYgKFBPTExPVVR8UE9MTEhVUHxQT0xMRVJSKSk7DQo+Pj4+
ICsJCQlGaWVsZChldmVudHMsIDApID0gVmFsX2Jvb2woY19mZHNbaV0uZXZlbnRzICYgUE9MTElO
ICAmJiBjX2Zkc1tpXS5yZXZlbnRzICYgKFBPTExJTiB8UE9MTEhVUHxQT0xMRVJSKSk7DQo+Pj4+
ICsJCQlGaWVsZChldmVudHMsIDEpID0gVmFsX2Jvb2woY19mZHNbaV0uZXZlbnRzICYgUE9MTE9V
VCAmJiBjX2Zkc1tpXS5yZXZlbnRzICYgKFBPTExPVVR8UE9MTEhVUHxQT0xMRVJSKSk7DQo+Pj4+
IAkJCUZpZWxkKGV2ZW50cywgMikgPSBWYWxfYm9vbChjX2Zkc1tpXS5yZXZlbnRzICYgUE9MTFBS
SSk7DQo+Pj4+IA0KPj4+PiAJCX0NCj4+Pj4gDQo+PiANCj4gDQo+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QN
Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcNCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Nov 26 20:52:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20: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.xen.org>)
	id 1XtjZX-0001OI-7D; Wed, 26 Nov 2014 20:52:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XtjZV-0001OD-Kp
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 20:52:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	31/79-25276-58D36745; Wed, 26 Nov 2014 20:52:21 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417035140!15605357!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11011 invoked from network); 26 Nov 2014 20:52:20 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 20:52:20 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAQKq75t025413;
	Wed, 26 Nov 2014 20:52:11 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAQKq0UZ012201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Nov 2014 20:52:00 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAQKpxM3017452;
	Wed, 26 Nov 2014 20:51:59 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAQKpxNK017448; Wed, 26 Nov 2014 20:51:59 GMT
Date: Wed, 26 Nov 2014 20:51:59 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-2010612164-1417035119=:18257"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAQKq75t025413
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] fix migration failure with xl migrate --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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-2010612164-1417035119=:18257
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

Migrations with xl migrate --debug will fail because debugging information 
from the receiving process is written to the stdout channel. This channel 
is also used for status messages so the migration will fail as the sending 
process receives an unexpected message. This patch moves the debugging 
information to the stderr channel.

Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
--8323329-2010612164-1417035119=:18257
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xl.migrate.debug.fail.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xl.migrate.debug.fail.patch

VXNlIHN0ZGVyciBmb3IgZGVidWdnaW5nIG1lc3NhZ2VzIGZvciB4bCBtaWdy
YXRlIC0tZGVidWcgYXMgc3Rkb3V0IGlzIHVzZWQNCmZvciBzdGF0dXMgbWVz
c2FnZXMuDQoNCi0tLSB4ZW4tNC41LjAtcmMxL3Rvb2xzL2xpYnhsL3hsX2Nt
ZGltcGwuYy5vcmlnCTIwMTQtMTAtMjQgMTU6MjI6NDAuMDAwMDAwMDAwICsw
MTAwDQorKysgeGVuLTQuNS4wLXJjMS90b29scy9saWJ4bC94bF9jbWRpbXBs
LmMJMjAxNC0xMS0yNSAyMDoyOTowNi43MjM4NTY0MzMgKzAwMDANCkBAIC0z
ODMsNyArMzgzLDcgQEANCiAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4
bF9kb21haW5fY29uZmlnICpkX2NvbmZpZykNCiB7DQogICAgIGlmIChvdXRw
dXRfZm9ybWF0ID09IE9VVFBVVF9GT1JNQVRfU1hQKQ0KLSAgICAgICAgcmV0
dXJuIHByaW50Zl9pbmZvX3NleHAoZG9taWQsIGRfY29uZmlnKTsNCisgICAg
ICAgIHJldHVybiBwcmludGZfaW5mb19zZXhwKGRvbWlkLCBkX2NvbmZpZywg
c3RkZXJyKTsNCiANCiAgICAgY29uc3QgY2hhciAqYnVmOw0KICAgICBsaWJ4
bF95YWpsX2xlbmd0aCBsZW4gPSAwOw0KQEAgLTQwNCw3ICs0MDQsNyBAQA0K
ICAgICBpZiAocyAhPSB5YWpsX2dlbl9zdGF0dXNfb2spDQogICAgICAgICBn
b3RvIG91dDsNCiANCi0gICAgcHV0cyhidWYpOw0KKyAgICBmcHV0cyhidWYs
c3RkZXJyKTsNCiANCiBvdXQ6DQogICAgIHlhamxfZ2VuX2ZyZWUoaGFuZCk7
DQpAQCAtNDEzLDcgKzQxMyw3IEBADQogICAgICAgICBmcHJpbnRmKHN0ZGVy
ciwNCiAgICAgICAgICAgICAgICAgInVuYWJsZSB0byBmb3JtYXQgZG9tYWlu
IGNvbmZpZyBhcyBKU09OIChZQUpMOiVkKVxuIiwgcyk7DQogDQotICAgIGlm
IChmZXJyb3Ioc3Rkb3V0KSB8fCBmZmx1c2goc3Rkb3V0KSkgeyBwZXJyb3Io
InN0ZG91dCIpOyBleGl0KC0xKTsgfQ0KKyAgICBpZiAoZmVycm9yKHN0ZGVy
cikgfHwgZmZsdXNoKHN0ZGVycikpIHsgcGVycm9yKCJzdGRlcnIiKTsgZXhp
dCgtMSk7IH0NCiB9DQogDQogc3RhdGljIGludCBkb19kYWVtb25pemUoY2hh
ciAqbmFtZSkNCkBAIC0yNDIzLDcgKzI0MjMsNyBAQA0KICAgICB9DQogDQog
ICAgIGlmICghZG9tX2luZm8tPnF1aWV0KQ0KLSAgICAgICAgcHJpbnRmKCJQ
YXJzaW5nIGNvbmZpZyBmcm9tICVzXG4iLCBjb25maWdfc291cmNlKTsNCisg
ICAgICAgIGZwcmludGYoc3RkZXJyLCAiUGFyc2luZyBjb25maWcgZnJvbSAl
c1xuIiwgY29uZmlnX3NvdXJjZSk7DQogDQogICAgIGlmIChjb25maWdfaW5f
anNvbikgew0KICAgICAgICAgbGlieGxfZG9tYWluX2NvbmZpZ19mcm9tX2pz
b24oY3R4LCAmZF9jb25maWcsDQpAQCAtMzQwMyw3ICszNDAzLDcgQEANCiAg
ICAgICAgIGlmIChkZWZhdWx0X291dHB1dF9mb3JtYXQgPT0gT1VUUFVUX0ZP
Uk1BVF9KU09OKQ0KICAgICAgICAgICAgIHMgPSBwcmludGZfaW5mb19vbmVf
anNvbihoYW5kLCBpbmZvW2ldLmRvbWlkLCAmZF9jb25maWcpOw0KICAgICAg
ICAgZWxzZQ0KLSAgICAgICAgICAgIHByaW50Zl9pbmZvX3NleHAoaW5mb1tp
XS5kb21pZCwgJmRfY29uZmlnKTsNCisgICAgICAgICAgICBwcmludGZfaW5m
b19zZXhwKGluZm9baV0uZG9taWQsICZkX2NvbmZpZywgc3Rkb3V0KTsNCiAg
ICAgICAgIGxpYnhsX2RvbWFpbl9jb25maWdfZGlzcG9zZSgmZF9jb25maWcp
Ow0KICAgICAgICAgaWYgKHMgIT0geWFqbF9nZW5fc3RhdHVzX29rKQ0KICAg
ICAgICAgICAgIGdvdG8gb3V0Ow0KLS0tIHhlbi00LjUuMC1yYzEvdG9vbHMv
bGlieGwveGxfc3hwLmMub3JpZwkyMDE0LTEwLTI0IDE1OjIyOjQwLjAwMDAw
MDAwMCArMDEwMA0KKysrIHhlbi00LjUuMC1yYzEvdG9vbHMvbGlieGwveGxf
c3hwLmMJMjAxNC0xMS0yNSAyMDoyNzoyMS45MTEwMzY3MTMgKzAwMDANCkBA
IC0zMCw3ICszMCw3IEBADQogLyogSW4gZ2VuZXJhbCB5b3Ugc2hvdWxkIG5v
dCBhZGQgbmV3IG91dHB1dCB0byB0aGlzIGZ1bmN0aW9uIHNpbmNlIGl0DQog
ICogaXMgaW50ZW5kZWQgb25seSBmb3IgbGVnYWN5IHVzZS4NCiAgKi8NCi12
b2lkIHByaW50Zl9pbmZvX3NleHAoaW50IGRvbWlkLCBsaWJ4bF9kb21haW5f
Y29uZmlnICpkX2NvbmZpZykNCit2b2lkIHByaW50Zl9pbmZvX3NleHAoaW50
IGRvbWlkLCBsaWJ4bF9kb21haW5fY29uZmlnICpkX2NvbmZpZywgRklMRSAq
ZmgpDQogew0KICAgICBpbnQgaTsNCiAgICAgbGlieGxfZG9taW5mbyBpbmZv
Ow0KQEAgLTM4LDE5NSArMzgsMTk1IEBADQogICAgIGxpYnhsX2RvbWFpbl9j
cmVhdGVfaW5mbyAqY19pbmZvID0gJmRfY29uZmlnLT5jX2luZm87DQogICAg
IGxpYnhsX2RvbWFpbl9idWlsZF9pbmZvICpiX2luZm8gPSAmZF9jb25maWct
PmJfaW5mbzsNCiANCi0gICAgcHJpbnRmKCIoZG9tYWluXG5cdChkb21pZCAl
ZClcbiIsIGRvbWlkKTsNCi0gICAgcHJpbnRmKCJcdChjcmVhdGVfaW5mbylc
biIpOw0KLSAgICBwcmludGYoIlx0KGh2bSAlZClcbiIsIGNfaW5mby0+dHlw
ZSA9PSBMSUJYTF9ET01BSU5fVFlQRV9IVk0pOw0KLSAgICBwcmludGYoIlx0
KGhhcCAlcylcbiIsIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGNfaW5mby0+
aGFwKSk7DQotICAgIHByaW50ZigiXHQob29zICVzKVxuIiwgbGlieGxfZGVm
Ym9vbF90b19zdHJpbmcoY19pbmZvLT5vb3MpKTsNCi0gICAgcHJpbnRmKCJc
dChzc2lkcmVmICVkKVxuIiwgY19pbmZvLT5zc2lkcmVmKTsNCi0gICAgcHJp
bnRmKCJcdChuYW1lICVzKVxuIiwgY19pbmZvLT5uYW1lKTsNCisgICAgZnBy
aW50ZihmaCwgIihkb21haW5cblx0KGRvbWlkICVkKVxuIiwgZG9taWQpOw0K
KyAgICBmcHJpbnRmKGZoLCAiXHQoY3JlYXRlX2luZm8pXG4iKTsNCisgICAg
ZnByaW50ZihmaCwgIlx0KGh2bSAlZClcbiIsIGNfaW5mby0+dHlwZSA9PSBM
SUJYTF9ET01BSU5fVFlQRV9IVk0pOw0KKyAgICBmcHJpbnRmKGZoLCAiXHQo
aGFwICVzKVxuIiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoY19pbmZvLT5o
YXApKTsNCisgICAgZnByaW50ZihmaCwgIlx0KG9vcyAlcylcbiIsIGxpYnhs
X2RlZmJvb2xfdG9fc3RyaW5nKGNfaW5mby0+b29zKSk7DQorICAgIGZwcmlu
dGYoZmgsICJcdChzc2lkcmVmICVkKVxuIiwgY19pbmZvLT5zc2lkcmVmKTsN
CisgICAgZnByaW50ZihmaCwgIlx0KG5hbWUgJXMpXG4iLCBjX2luZm8tPm5h
bWUpOw0KIA0KICAgICAvKiByZXRyaWV2ZSB0aGUgVVVJRCBmcm9tIGRvbWlu
Zm8sIHNpbmNlIGl0IGlzIHByb2JhYmx5IGdlbmVyYXRlZA0KICAgICAgKiBk
dXJpbmcgcGFyc2luZyBhbmQgdGh1cyBkb2VzIG5vdCBtYXRjaCB0aGUgcmVh
bCBvbmUNCiAgICAgICovDQogICAgIGlmIChsaWJ4bF9kb21haW5faW5mbyhj
dHgsICZpbmZvLCBkb21pZCkgPT0gMCkgew0KLSAgICAgICAgcHJpbnRmKCJc
dCh1dWlkICIgTElCWExfVVVJRF9GTVQgIilcbiIsIExJQlhMX1VVSURfQllU
RVMoaW5mby51dWlkKSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHQodXVp
ZCAiIExJQlhMX1VVSURfRk1UICIpXG4iLCBMSUJYTF9VVUlEX0JZVEVTKGlu
Zm8udXVpZCkpOw0KICAgICB9IGVsc2Ugew0KLSAgICAgICAgcHJpbnRmKCJc
dCh1dWlkIDx1bmtub3duPilcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwg
Ilx0KHV1aWQgPHVua25vd24+KVxuIik7DQogICAgIH0NCiAgICAgaWYgKGNf
aW5mby0+cG9vbF9uYW1lKQ0KLSAgICAgICAgcHJpbnRmKCJcdChjcHVwb29s
ICVzKVxuIiwgY19pbmZvLT5wb29sX25hbWUpOw0KKyAgICAgICAgZnByaW50
ZihmaCwgIlx0KGNwdXBvb2wgJXMpXG4iLCBjX2luZm8tPnBvb2xfbmFtZSk7
DQogICAgIGlmIChjX2luZm8tPnhzZGF0YSkNCi0gICAgICAgIHByaW50Zigi
XHQoeHNkYXRhIGNvbnRhaW5zIGRhdGEpXG4iKTsNCisgICAgICAgIGZwcmlu
dGYoZmgsICJcdCh4c2RhdGEgY29udGFpbnMgZGF0YSlcbiIpOw0KICAgICBl
bHNlDQotICAgICAgICBwcmludGYoIlx0KHhzZGF0YSAobnVsbCkpXG4iKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdCh4c2RhdGEgKG51bGwpKVxuIik7
DQogICAgIGlmIChjX2luZm8tPnBsYXRmb3JtZGF0YSkNCi0gICAgICAgIHBy
aW50ZigiXHQocGxhdGZvcm1kYXRhIGNvbnRhaW5zIGRhdGEpXG4iKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdChwbGF0Zm9ybWRhdGEgY29udGFpbnMg
ZGF0YSlcbiIpOw0KICAgICBlbHNlDQotICAgICAgICBwcmludGYoIlx0KHBs
YXRmb3JtZGF0YSAobnVsbCkpXG4iKTsNCisgICAgICAgIGZwcmludGYoZmgs
ICJcdChwbGF0Zm9ybWRhdGEgKG51bGwpKVxuIik7DQogDQogDQotICAgIHBy
aW50ZigiXHQoYnVpbGRfaW5mbylcbiIpOw0KLSAgICBwcmludGYoIlx0KG1h
eF92Y3B1cyAlZClcbiIsIGJfaW5mby0+bWF4X3ZjcHVzKTsNCi0gICAgcHJp
bnRmKCJcdCh0c2NfbW9kZSAlcylcbiIsIGxpYnhsX3RzY19tb2RlX3RvX3N0
cmluZyhiX2luZm8tPnRzY19tb2RlKSk7DQotICAgIHByaW50ZigiXHQobWF4
X21lbWtiICUiUFJJZDY0IilcbiIsIGJfaW5mby0+bWF4X21lbWtiKTsNCi0g
ICAgcHJpbnRmKCJcdCh0YXJnZXRfbWVta2IgJSJQUklkNjQiKVxuIiwgYl9p
bmZvLT50YXJnZXRfbWVta2IpOw0KLSAgICBwcmludGYoIlx0KG5vbWlncmF0
ZSAlcylcbiIsDQorICAgIGZwcmludGYoZmgsICJcdChidWlsZF9pbmZvKVxu
Iik7DQorICAgIGZwcmludGYoZmgsICJcdChtYXhfdmNwdXMgJWQpXG4iLCBi
X2luZm8tPm1heF92Y3B1cyk7DQorICAgIGZwcmludGYoZmgsICJcdCh0c2Nf
bW9kZSAlcylcbiIsIGxpYnhsX3RzY19tb2RlX3RvX3N0cmluZyhiX2luZm8t
PnRzY19tb2RlKSk7DQorICAgIGZwcmludGYoZmgsICJcdChtYXhfbWVta2Ig
JSJQUklkNjQiKVxuIiwgYl9pbmZvLT5tYXhfbWVta2IpOw0KKyAgICBmcHJp
bnRmKGZoLCAiXHQodGFyZ2V0X21lbWtiICUiUFJJZDY0IilcbiIsIGJfaW5m
by0+dGFyZ2V0X21lbWtiKTsNCisgICAgZnByaW50ZihmaCwgIlx0KG5vbWln
cmF0ZSAlcylcbiIsDQogICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0
cmluZyhiX2luZm8tPmRpc2FibGVfbWlncmF0ZSkpOw0KIA0KICAgICBpZiAo
Y19pbmZvLT50eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX1BWICYmIGJfaW5m
by0+dS5wdi5ib290bG9hZGVyKSB7DQotICAgICAgICBwcmludGYoIlx0KGJv
b3Rsb2FkZXIgJXMpXG4iLCBiX2luZm8tPnUucHYuYm9vdGxvYWRlcik7DQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHQoYm9vdGxvYWRlciAlcylcbiIsIGJf
aW5mby0+dS5wdi5ib290bG9hZGVyKTsNCiAgICAgICAgIGlmIChiX2luZm8t
PnUucHYuYm9vdGxvYWRlcl9hcmdzKSB7DQotICAgICAgICAgICAgcHJpbnRm
KCJcdChib290bG9hZGVyX2FyZ3MiKTsNCisgICAgICAgICAgICBmcHJpbnRm
KGZoLCAiXHQoYm9vdGxvYWRlcl9hcmdzIik7DQogICAgICAgICAgICAgZm9y
IChpPTA7IGJfaW5mby0+dS5wdi5ib290bG9hZGVyX2FyZ3NbaV07IGkrKykN
Ci0gICAgICAgICAgICAgICAgcHJpbnRmKCIgJXMiLCBiX2luZm8tPnUucHYu
Ym9vdGxvYWRlcl9hcmdzW2ldKTsNCi0gICAgICAgICAgICBwcmludGYoIilc
biIpOw0KKyAgICAgICAgICAgICAgICBmcHJpbnRmKGZoLCAiICVzIiwgYl9p
bmZvLT51LnB2LmJvb3Rsb2FkZXJfYXJnc1tpXSk7DQorICAgICAgICAgICAg
ZnByaW50ZihmaCwgIilcbiIpOw0KICAgICAgICAgfQ0KICAgICB9DQogDQot
ICAgIHByaW50ZigiXHQoaW1hZ2VcbiIpOw0KKyAgICBmcHJpbnRmKGZoLCAi
XHQoaW1hZ2VcbiIpOw0KICAgICBzd2l0Y2ggKGNfaW5mby0+dHlwZSkgew0K
ICAgICBjYXNlIExJQlhMX0RPTUFJTl9UWVBFX0hWTToNCi0gICAgICAgIHBy
aW50ZigiXHRcdChodm1cbiIpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQo
ZmlybXdhcmUgJXMpXG4iLCBiX2luZm8tPnUuaHZtLmZpcm13YXJlKTsNCi0g
ICAgICAgIHByaW50ZigiXHRcdFx0KHZpZGVvX21lbWtiICUiUFJJZDY0Iilc
biIsIGJfaW5mby0+dmlkZW9fbWVta2IpOw0KLSAgICAgICAgcHJpbnRmKCJc
dFx0XHQoc2hhZG93X21lbWtiICUiUFJJZDY0IilcbiIsIGJfaW5mby0+c2hh
ZG93X21lbWtiKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHBhZSAlcylc
biIsIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0ucGFl
KSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChhcGljICVzKVxuIiwNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0KGh2bVxuIik7DQorICAgICAgICBm
cHJpbnRmKGZoLCAiXHRcdFx0KGZpcm13YXJlICVzKVxuIiwgYl9pbmZvLT51
Lmh2bS5maXJtd2FyZSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0
KHZpZGVvX21lbWtiICUiUFJJZDY0IilcbiIsIGJfaW5mby0+dmlkZW9fbWVt
a2IpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzaGFkb3dfbWVt
a2IgJSJQUklkNjQiKVxuIiwgYl9pbmZvLT5zaGFkb3dfbWVta2IpOw0KKyAg
ICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChwYWUgJXMpXG4iLCBsaWJ4bF9k
ZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnBhZSkpOw0KKyAgICAg
ICAgZnByaW50ZihmaCwgIlx0XHRcdChhcGljICVzKVxuIiwNCiAgICAgICAg
ICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZt
LmFwaWMpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGFjcGkgJXMpXG4i
LA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChhY3BpICVzKVxuIiwN
CiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2lu
Zm8tPnUuaHZtLmFjcGkpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KG54
ICVzKVxuIiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2
bS5ueCkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodmlyaWRpYW4gJXMp
XG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChueCAlcylcbiIs
IGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0ubngpKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQodmlyaWRpYW4gJXMpXG4i
LA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJf
aW5mby0+dS5odm0udmlyaWRpYW4pKTsNCi0gICAgICAgIHByaW50ZigiXHRc
dFx0KGhwZXQgJXMpXG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRc
dChocGV0ICVzKVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29s
X3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLmhwZXQpKTsNCi0gICAgICAgIHBy
aW50ZigiXHRcdFx0KHZwdF9hbGlnbiAlcylcbiIsDQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHRcdFx0KHZwdF9hbGlnbiAlcylcbiIsDQogICAgICAgICAg
ICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS52
cHRfYWxpZ24pKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHRpbWVyX21v
ZGUgJXMpXG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh0aW1l
cl9tb2RlICVzKVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF90aW1lcl9t
b2RlX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnRpbWVyX21vZGUpKTsNCi0g
ICAgICAgIHByaW50ZigiXHRcdFx0KG5lc3RlZGh2bSAlcylcbiIsDQorICAg
ICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KG5lc3RlZGh2bSAlcylcbiIsDQog
ICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZv
LT51Lmh2bS5uZXN0ZWRfaHZtKSk7DQotICAgICAgICBwcmludGYoIlx0XHRc
dChzdGR2Z2EgJXMpXG4iLCBiX2luZm8tPnUuaHZtLnZnYS5raW5kID09DQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHN0ZHZnYSAlcylcbiIsIGJf
aW5mby0+dS5odm0udmdhLmtpbmQgPT0NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9T
VEQgPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IlRydWUiIDogIkZhbHNlIik7DQotICAgICAgICBwcmludGYoIlx0XHRcdCh2
bmMgJXMpXG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh2bmMg
JXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3Ry
aW5nKGJfaW5mby0+dS5odm0udm5jLmVuYWJsZSkpOw0KLSAgICAgICAgcHJp
bnRmKCJcdFx0XHQodm5jbGlzdGVuICVzKVxuIiwgYl9pbmZvLT51Lmh2bS52
bmMubGlzdGVuKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHZuY2Rpc3Bs
YXkgJWQpXG4iLCBiX2luZm8tPnUuaHZtLnZuYy5kaXNwbGF5KTsNCi0gICAg
ICAgIHByaW50ZigiXHRcdFx0KHZuY3VudXNlZCAlcylcbiIsDQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHRcdFx0KHZuY2xpc3RlbiAlcylcbiIsIGJfaW5m
by0+dS5odm0udm5jLmxpc3Rlbik7DQorICAgICAgICBmcHJpbnRmKGZoLCAi
XHRcdFx0KHZuY2Rpc3BsYXkgJWQpXG4iLCBiX2luZm8tPnUuaHZtLnZuYy5k
aXNwbGF5KTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQodm5jdW51
c2VkICVzKVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3Rv
X3N0cmluZyhiX2luZm8tPnUuaHZtLnZuYy5maW5kdW51c2VkKSk7DQotICAg
ICAgICBwcmludGYoIlx0XHRcdChrZXltYXAgJXMpXG4iLCBiX2luZm8tPnUu
aHZtLmtleW1hcCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChzZGwgJXMp
XG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChrZXltYXAgJXMp
XG4iLCBiX2luZm8tPnUuaHZtLmtleW1hcCk7DQorICAgICAgICBmcHJpbnRm
KGZoLCAiXHRcdFx0KHNkbCAlcylcbiIsDQogICAgICAgICAgICAgICAgbGli
eGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS5zZGwuZW5hYmxl
KSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChvcGVuZ2wgJXMpXG4iLA0K
KyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChvcGVuZ2wgJXMpXG4iLA0K
ICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5m
by0+dS5odm0uc2RsLm9wZW5nbCkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0
XHQobm9ncmFwaGljICVzKVxuIiwNCisgICAgICAgIGZwcmludGYoZmgsICJc
dFx0XHQobm9ncmFwaGljICVzKVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4
bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLm5vZ3JhcGhpYykp
Ow0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoc3BpY2UgJXMpXG4iLA0KKyAg
ICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzcGljZSAlcylcbiIsDQogICAg
ICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51
Lmh2bS5zcGljZS5lbmFibGUpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0
KHNwaWNlcG9ydCAlZClcbiIsIGJfaW5mby0+dS5odm0uc3BpY2UucG9ydCk7
DQotICAgICAgICBwcmludGYoIlx0XHRcdChzcGljZXRsc19wb3J0ICVkKVxu
IiwgYl9pbmZvLT51Lmh2bS5zcGljZS50bHNfcG9ydCk7DQotICAgICAgICBw
cmludGYoIlx0XHRcdChzcGljZWhvc3QgJXMpXG4iLCBiX2luZm8tPnUuaHZt
LnNwaWNlLmhvc3QpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoc3BpY2Vk
aXNhYmxlX3RpY2tldGluZyAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZo
LCAiXHRcdFx0KHNwaWNlcG9ydCAlZClcbiIsIGJfaW5mby0+dS5odm0uc3Bp
Y2UucG9ydCk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHNwaWNl
dGxzX3BvcnQgJWQpXG4iLCBiX2luZm8tPnUuaHZtLnNwaWNlLnRsc19wb3J0
KTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoc3BpY2Vob3N0ICVz
KVxuIiwgYl9pbmZvLT51Lmh2bS5zcGljZS5ob3N0KTsNCisgICAgICAgIGZw
cmludGYoZmgsICJcdFx0XHQoc3BpY2VkaXNhYmxlX3RpY2tldGluZyAlcylc
biIsDQogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmco
Yl9pbmZvLT51Lmh2bS5zcGljZS5kaXNhYmxlX3RpY2tldGluZykpOw0KLSAg
ICAgICAgcHJpbnRmKCJcdFx0XHQoc3BpY2VhZ2VudF9tb3VzZSAlcylcbiIs
DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHNwaWNlYWdlbnRfbW91
c2UgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9f
c3RyaW5nKGJfaW5mby0+dS5odm0uc3BpY2UuYWdlbnRfbW91c2UpKTsNCiAN
Ci0gICAgICAgIHByaW50ZigiXHRcdFx0KGRldmljZV9tb2RlbCAlcylcbiIs
IGJfaW5mby0+ZGV2aWNlX21vZGVsID8gOiAiZGVmYXVsdCIpOw0KLSAgICAg
ICAgcHJpbnRmKCJcdFx0XHQoZ2Z4X3Bhc3N0aHJ1ICVzKVxuIiwNCisgICAg
ICAgIGZwcmludGYoZmgsICJcdFx0XHQoZGV2aWNlX21vZGVsICVzKVxuIiwg
Yl9pbmZvLT5kZXZpY2VfbW9kZWwgPyA6ICJkZWZhdWx0Iik7DQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHRcdFx0KGdmeF9wYXNzdGhydSAlcylcbiIsDQog
ICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZv
LT51Lmh2bS5nZnhfcGFzc3RocnUpKTsNCi0gICAgICAgIHByaW50ZigiXHRc
dFx0KHNlcmlhbCAlcylcbiIsIGJfaW5mby0+dS5odm0uc2VyaWFsKTsNCi0g
ICAgICAgIHByaW50ZigiXHRcdFx0KGJvb3QgJXMpXG4iLCBiX2luZm8tPnUu
aHZtLmJvb3QpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodXNiICVzKVxu
IiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS51c2Ip
KTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHVzYmRldmljZSAlcylcbiIs
IGJfaW5mby0+dS5odm0udXNiZGV2aWNlKTsNCi0gICAgICAgIHByaW50Zigi
XHRcdClcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzZXJp
YWwgJXMpXG4iLCBiX2luZm8tPnUuaHZtLnNlcmlhbCk7DQorICAgICAgICBm
cHJpbnRmKGZoLCAiXHRcdFx0KGJvb3QgJXMpXG4iLCBiX2luZm8tPnUuaHZt
LmJvb3QpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh1c2IgJXMp
XG4iLCBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnVz
YikpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh1c2JkZXZpY2Ug
JXMpXG4iLCBiX2luZm8tPnUuaHZtLnVzYmRldmljZSk7DQorICAgICAgICBm
cHJpbnRmKGZoLCAiXHRcdClcbiIpOw0KICAgICAgICAgYnJlYWs7DQogICAg
IGNhc2UgTElCWExfRE9NQUlOX1RZUEVfUFY6DQotICAgICAgICBwcmludGYo
Ilx0XHQobGludXggJWQpXG4iLCAwKTsNCi0gICAgICAgIHByaW50ZigiXHRc
dFx0KGtlcm5lbCAlcylcbiIsIGJfaW5mby0+a2VybmVsKTsNCi0gICAgICAg
IHByaW50ZigiXHRcdFx0KGNtZGxpbmUgJXMpXG4iLCBiX2luZm8tPmNtZGxp
bmUpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQocmFtZGlzayAlcylcbiIs
IGJfaW5mby0+cmFtZGlzayk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChl
ODIwX2hvc3QgJXMpXG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQo
bGludXggJWQpXG4iLCAwKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0
XHQoa2VybmVsICVzKVxuIiwgYl9pbmZvLT5rZXJuZWwpOw0KKyAgICAgICAg
ZnByaW50ZihmaCwgIlx0XHRcdChjbWRsaW5lICVzKVxuIiwgYl9pbmZvLT5j
bWRsaW5lKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQocmFtZGlz
ayAlcylcbiIsIGJfaW5mby0+cmFtZGlzayk7DQorICAgICAgICBmcHJpbnRm
KGZoLCAiXHRcdFx0KGU4MjBfaG9zdCAlcylcbiIsDQogICAgICAgICAgICAg
ICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51LnB2LmU4MjBf
aG9zdCkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0KVxuIik7DQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHRcdClcbiIpOw0KICAgICAgICAgYnJlYWs7DQog
ICAgIGRlZmF1bHQ6DQogICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIlVua25v
d24gZG9tYWluIHR5cGUgJWRcbiIsIGNfaW5mby0+dHlwZSk7DQogICAgICAg
ICBleGl0KDEpOw0KICAgICB9DQotICAgIHByaW50ZigiXHQpXG4iKTsNCisg
ICAgZnByaW50ZihmaCwgIlx0KVxuIik7DQogDQogICAgIGZvciAoaSA9IDA7
IGkgPCBkX2NvbmZpZy0+bnVtX2Rpc2tzOyBpKyspIHsNCi0gICAgICAgIHBy
aW50ZigiXHQoZGV2aWNlXG4iKTsNCi0gICAgICAgIHByaW50ZigiXHRcdCh0
YXBcbiIpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoYmFja2VuZF9kb21p
ZCAlZClcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS5iYWNrZW5kX2RvbWlkKTsN
Ci0gICAgICAgIHByaW50ZigiXHRcdFx0KGZyb250ZW5kX2RvbWlkICVkKVxu
IiwgZG9taWQpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQocGh5c3BhdGgg
JXMpXG4iLCBkX2NvbmZpZy0+ZGlza3NbaV0ucGRldl9wYXRoKTsNCi0gICAg
ICAgIHByaW50ZigiXHRcdFx0KHBoeXN0eXBlICVkKVxuIiwgZF9jb25maWct
PmRpc2tzW2ldLmJhY2tlbmQpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQo
dmlydHBhdGggJXMpXG4iLCBkX2NvbmZpZy0+ZGlza3NbaV0udmRldik7DQot
ICAgICAgICBwcmludGYoIlx0XHRcdCh1bnBsdWdnYWJsZSAlZClcbiIsIGRf
Y29uZmlnLT5kaXNrc1tpXS5yZW1vdmFibGUpOw0KLSAgICAgICAgcHJpbnRm
KCJcdFx0XHQocmVhZHdyaXRlICVkKVxuIiwgZF9jb25maWctPmRpc2tzW2ld
LnJlYWR3cml0ZSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChpc19jZHJv
bSAlZClcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS5pc19jZHJvbSk7DQotICAg
ICAgICBwcmludGYoIlx0XHQpXG4iKTsNCi0gICAgICAgIHByaW50ZigiXHQp
XG4iKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdChkZXZpY2VcbiIpOw0K
KyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQodGFwXG4iKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdFx0XHQoYmFja2VuZF9kb21pZCAlZClcbiIsIGRf
Y29uZmlnLT5kaXNrc1tpXS5iYWNrZW5kX2RvbWlkKTsNCisgICAgICAgIGZw
cmludGYoZmgsICJcdFx0XHQoZnJvbnRlbmRfZG9taWQgJWQpXG4iLCBkb21p
ZCk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHBoeXNwYXRoICVz
KVxuIiwgZF9jb25maWctPmRpc2tzW2ldLnBkZXZfcGF0aCk7DQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHRcdFx0KHBoeXN0eXBlICVkKVxuIiwgZF9jb25m
aWctPmRpc2tzW2ldLmJhY2tlbmQpOw0KKyAgICAgICAgZnByaW50ZihmaCwg
Ilx0XHRcdCh2aXJ0cGF0aCAlcylcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS52
ZGV2KTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQodW5wbHVnZ2Fi
bGUgJWQpXG4iLCBkX2NvbmZpZy0+ZGlza3NbaV0ucmVtb3ZhYmxlKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQocmVhZHdyaXRlICVkKVxuIiwg
ZF9jb25maWctPmRpc2tzW2ldLnJlYWR3cml0ZSk7DQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHRcdFx0KGlzX2Nkcm9tICVkKVxuIiwgZF9jb25maWctPmRp
c2tzW2ldLmlzX2Nkcm9tKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0
KVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHQpXG4iKTsNCiAgICAg
fQ0KIA0KICAgICBmb3IgKGkgPSAwOyBpIDwgZF9jb25maWctPm51bV9uaWNz
OyBpKyspIHsNCi0gICAgICAgIHByaW50ZigiXHQoZGV2aWNlXG4iKTsNCi0g
ICAgICAgIHByaW50ZigiXHRcdCh2aWZcbiIpOw0KKyAgICAgICAgZnByaW50
ZihmaCwgIlx0KGRldmljZVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAi
XHRcdCh2aWZcbiIpOw0KICAgICAgICAgaWYgKGRfY29uZmlnLT5uaWNzW2ld
LmlmbmFtZSkNCi0gICAgICAgICAgICBwcmludGYoIlx0XHRcdCh2aWZuYW1l
ICVzKVxuIiwgZF9jb25maWctPm5pY3NbaV0uaWZuYW1lKTsNCi0gICAgICAg
IHByaW50ZigiXHRcdFx0KGJhY2tlbmRfZG9taWQgJWQpXG4iLCBkX2NvbmZp
Zy0+bmljc1tpXS5iYWNrZW5kX2RvbWlkKTsNCi0gICAgICAgIHByaW50Zigi
XHRcdFx0KGZyb250ZW5kX2RvbWlkICVkKVxuIiwgZG9taWQpOw0KLSAgICAg
ICAgcHJpbnRmKCJcdFx0XHQoZGV2aWQgJWQpXG4iLCBkX2NvbmZpZy0+bmlj
c1tpXS5kZXZpZCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChtdHUgJWQp
XG4iLCBkX2NvbmZpZy0+bmljc1tpXS5tdHUpOw0KLSAgICAgICAgcHJpbnRm
KCJcdFx0XHQobW9kZWwgJXMpXG4iLCBkX2NvbmZpZy0+bmljc1tpXS5tb2Rl
bCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChtYWMgJTAyeCUwMnglMDJ4
JTAyeCUwMnglMDJ4KVxuIiwNCisgICAgICAgICAgICBmcHJpbnRmKGZoLCAi
XHRcdFx0KHZpZm5hbWUgJXMpXG4iLCBkX2NvbmZpZy0+bmljc1tpXS5pZm5h
bWUpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChiYWNrZW5kX2Rv
bWlkICVkKVxuIiwgZF9jb25maWctPm5pY3NbaV0uYmFja2VuZF9kb21pZCk7
DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGZyb250ZW5kX2RvbWlk
ICVkKVxuIiwgZG9taWQpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRc
dChkZXZpZCAlZClcbiIsIGRfY29uZmlnLT5uaWNzW2ldLmRldmlkKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQobXR1ICVkKVxuIiwgZF9jb25m
aWctPm5pY3NbaV0ubXR1KTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0
XHQobW9kZWwgJXMpXG4iLCBkX2NvbmZpZy0+bmljc1tpXS5tb2RlbCk7DQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KG1hYyAlMDJ4JTAyeCUwMngl
MDJ4JTAyeCUwMngpXG4iLA0KICAgICAgICAgICAgICAgIGRfY29uZmlnLT5u
aWNzW2ldLm1hY1swXSwgZF9jb25maWctPm5pY3NbaV0ubWFjWzFdLA0KICAg
ICAgICAgICAgICAgIGRfY29uZmlnLT5uaWNzW2ldLm1hY1syXSwgZF9jb25m
aWctPm5pY3NbaV0ubWFjWzNdLA0KICAgICAgICAgICAgICAgIGRfY29uZmln
LT5uaWNzW2ldLm1hY1s0XSwgZF9jb25maWctPm5pY3NbaV0ubWFjWzVdKTsN
Ci0gICAgICAgIHByaW50ZigiXHRcdClcbiIpOw0KLSAgICAgICAgcHJpbnRm
KCJcdClcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQpXG4iKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdClcbiIpOw0KICAgICB9DQogDQog
ICAgIGZvciAoaSA9IDA7IGkgPCBkX2NvbmZpZy0+bnVtX3BjaWRldnM7IGkr
Kykgew0KLSAgICAgICAgcHJpbnRmKCJcdChkZXZpY2VcbiIpOw0KLSAgICAg
ICAgcHJpbnRmKCJcdFx0KHBjaVxuIik7DQotICAgICAgICBwcmludGYoIlx0
XHRcdChwY2kgZGV2ICUwNHg6JTAyeDolMDJ4LiUwMXhAJTAyeClcbiIsDQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHQoZGV2aWNlXG4iKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdFx0KHBjaVxuIik7DQorICAgICAgICBmcHJpbnRm
KGZoLCAiXHRcdFx0KHBjaSBkZXYgJTA0eDolMDJ4OiUwMnguJTAxeEAlMDJ4
KVxuIiwNCiAgICAgICAgICAgICAgICBkX2NvbmZpZy0+cGNpZGV2c1tpXS5k
b21haW4sIGRfY29uZmlnLT5wY2lkZXZzW2ldLmJ1cywNCiAgICAgICAgICAg
ICAgICBkX2NvbmZpZy0+cGNpZGV2c1tpXS5kZXYsIGRfY29uZmlnLT5wY2lk
ZXZzW2ldLmZ1bmMsDQogICAgICAgICAgICAgICAgZF9jb25maWctPnBjaWRl
dnNbaV0udmRldmZuKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KG9wdHMg
bXNpdHJhbnNsYXRlICVkIHBvd2VyX21nbXQgJWQpXG4iLA0KKyAgICAgICAg
ZnByaW50ZihmaCwgIlx0XHRcdChvcHRzIG1zaXRyYW5zbGF0ZSAlZCBwb3dl
cl9tZ210ICVkKVxuIiwNCiAgICAgICAgICAgICAgICBkX2NvbmZpZy0+cGNp
ZGV2c1tpXS5tc2l0cmFuc2xhdGUsDQogICAgICAgICAgICAgICAgZF9jb25m
aWctPnBjaWRldnNbaV0ucG93ZXJfbWdtdCk7DQotICAgICAgICBwcmludGYo
Ilx0XHQpXG4iKTsNCi0gICAgICAgIHByaW50ZigiXHQpXG4iKTsNCisgICAg
ICAgIGZwcmludGYoZmgsICJcdFx0KVxuIik7DQorICAgICAgICBmcHJpbnRm
KGZoLCAiXHQpXG4iKTsNCiAgICAgfQ0KIA0KICAgICBmb3IgKGkgPSAwOyBp
IDwgZF9jb25maWctPm51bV92ZmJzOyBpKyspIHsNCi0gICAgICAgIHByaW50
ZigiXHQoZGV2aWNlXG4iKTsNCi0gICAgICAgIHByaW50ZigiXHRcdCh2ZmJc
biIpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoYmFja2VuZF9kb21pZCAl
ZClcbiIsIGRfY29uZmlnLT52ZmJzW2ldLmJhY2tlbmRfZG9taWQpOw0KLSAg
ICAgICAgcHJpbnRmKCJcdFx0XHQoZnJvbnRlbmRfZG9taWQgJWQpXG4iLCBk
b21pZCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChkZXZpZCAlZClcbiIs
IGRfY29uZmlnLT52ZmJzW2ldLmRldmlkKTsNCi0gICAgICAgIHByaW50Zigi
XHRcdFx0KHZuYyAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHQo
ZGV2aWNlXG4iKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0KHZmYlxu
Iik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGJhY2tlbmRfZG9t
aWQgJWQpXG4iLCBkX2NvbmZpZy0+dmZic1tpXS5iYWNrZW5kX2RvbWlkKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoZnJvbnRlbmRfZG9taWQg
JWQpXG4iLCBkb21pZCk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0
KGRldmlkICVkKVxuIiwgZF9jb25maWctPnZmYnNbaV0uZGV2aWQpOw0KKyAg
ICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh2bmMgJXMpXG4iLA0KICAgICAg
ICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGRfY29uZmlnLT52
ZmJzW2ldLnZuYy5lbmFibGUpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0
KHZuY2xpc3RlbiAlcylcbiIsIGRfY29uZmlnLT52ZmJzW2ldLnZuYy5saXN0
ZW4pOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodm5jZGlzcGxheSAlZClc
biIsIGRfY29uZmlnLT52ZmJzW2ldLnZuYy5kaXNwbGF5KTsNCi0gICAgICAg
IHByaW50ZigiXHRcdFx0KHZuY3VudXNlZCAlcylcbiIsDQorICAgICAgICBm
cHJpbnRmKGZoLCAiXHRcdFx0KHZuY2xpc3RlbiAlcylcbiIsIGRfY29uZmln
LT52ZmJzW2ldLnZuYy5saXN0ZW4pOw0KKyAgICAgICAgZnByaW50ZihmaCwg
Ilx0XHRcdCh2bmNkaXNwbGF5ICVkKVxuIiwgZF9jb25maWctPnZmYnNbaV0u
dm5jLmRpc3BsYXkpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh2
bmN1bnVzZWQgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJv
b2xfdG9fc3RyaW5nKGRfY29uZmlnLT52ZmJzW2ldLnZuYy5maW5kdW51c2Vk
KSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChrZXltYXAgJXMpXG4iLCBk
X2NvbmZpZy0+dmZic1tpXS5rZXltYXApOw0KLSAgICAgICAgcHJpbnRmKCJc
dFx0XHQoc2RsICVzKVxuIiwNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0
XHQoa2V5bWFwICVzKVxuIiwgZF9jb25maWctPnZmYnNbaV0ua2V5bWFwKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoc2RsICVzKVxuIiwNCiAg
ICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhkX2NvbmZp
Zy0+dmZic1tpXS5zZGwuZW5hYmxlKSk7DQotICAgICAgICBwcmludGYoIlx0
XHRcdChvcGVuZ2wgJXMpXG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0
XHRcdChvcGVuZ2wgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2Rl
ZmJvb2xfdG9fc3RyaW5nKGRfY29uZmlnLT52ZmJzW2ldLnNkbC5vcGVuZ2wp
KTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGRpc3BsYXkgJXMpXG4iLCBk
X2NvbmZpZy0+dmZic1tpXS5zZGwuZGlzcGxheSk7DQotICAgICAgICBwcmlu
dGYoIlx0XHRcdCh4YXV0aG9yaXR5ICVzKVxuIiwgZF9jb25maWctPnZmYnNb
aV0uc2RsLnhhdXRob3JpdHkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0KVxu
Iik7DQotICAgICAgICBwcmludGYoIlx0KVxuIik7DQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHRcdFx0KGRpc3BsYXkgJXMpXG4iLCBkX2NvbmZpZy0+dmZi
c1tpXS5zZGwuZGlzcGxheSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRc
dFx0KHhhdXRob3JpdHkgJXMpXG4iLCBkX2NvbmZpZy0+dmZic1tpXS5zZGwu
eGF1dGhvcml0eSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdClcbiIp
Ow0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0KVxuIik7DQogICAgIH0NCi0g
ICAgcHJpbnRmKCIpXG4iKTsNCisgICAgZnByaW50ZihmaCwgIilcbiIpOw0K
IH0NCiANCiANCi0tLSB4ZW4tNC41LjAtcmMxL3Rvb2xzL2xpYnhsL3hsLmgu
b3JpZwkyMDE0LTEwLTI0IDE1OjIyOjQwLjAwMDAwMDAwMCArMDEwMA0KKysr
IHhlbi00LjUuMC1yYzEvdG9vbHMvbGlieGwveGwuaAkyMDE0LTExLTI1IDIw
OjU2OjIwLjU5MjI3MjkzOSArMDAwMA0KQEAgLTE4Niw3ICsxODYsNyBAQA0K
IH07DQogZXh0ZXJuIGVudW0gb3V0cHV0X2Zvcm1hdCBkZWZhdWx0X291dHB1
dF9mb3JtYXQ7DQogDQotZXh0ZXJuIHZvaWQgcHJpbnRmX2luZm9fc2V4cChp
bnQgZG9taWQsIGxpYnhsX2RvbWFpbl9jb25maWcgKmRfY29uZmlnKTsNCitl
eHRlcm4gdm9pZCBwcmludGZfaW5mb19zZXhwKGludCBkb21pZCwgbGlieGxf
ZG9tYWluX2NvbmZpZyAqZF9jb25maWcsIEZJTEUgKmZoKTsNCiANCiAjZGVm
aW5lIFhMX0dMT0JBTF9DT05GSUcgWEVOX0NPTkZJR19ESVIgIi94bC5jb25m
Ig0KICNkZWZpbmUgWExfTE9DS19GSUxFIFhFTl9MT0NLX0RJUiAiL3hsIg0K

--8323329-2010612164-1417035119=:18257
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-2010612164-1417035119=:18257--


From xen-devel-bounces@lists.xen.org Wed Nov 26 20:52:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 20: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.xen.org>)
	id 1XtjZX-0001OI-7D; Wed, 26 Nov 2014 20:52:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XtjZV-0001OD-Kp
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 20:52:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	31/79-25276-58D36745; Wed, 26 Nov 2014 20:52:21 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417035140!15605357!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11011 invoked from network); 26 Nov 2014 20:52:20 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 20:52:20 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAQKq75t025413;
	Wed, 26 Nov 2014 20:52:11 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAQKq0UZ012201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Nov 2014 20:52:00 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAQKpxM3017452;
	Wed, 26 Nov 2014 20:51:59 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAQKpxNK017448; Wed, 26 Nov 2014 20:51:59 GMT
Date: Wed, 26 Nov 2014 20:51:59 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-2010612164-1417035119=:18257"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAQKq75t025413
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] fix migration failure with xl migrate --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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-2010612164-1417035119=:18257
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

Migrations with xl migrate --debug will fail because debugging information 
from the receiving process is written to the stdout channel. This channel 
is also used for status messages so the migration will fail as the sending 
process receives an unexpected message. This patch moves the debugging 
information to the stderr channel.

Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
--8323329-2010612164-1417035119=:18257
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xl.migrate.debug.fail.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xl.migrate.debug.fail.patch

VXNlIHN0ZGVyciBmb3IgZGVidWdnaW5nIG1lc3NhZ2VzIGZvciB4bCBtaWdy
YXRlIC0tZGVidWcgYXMgc3Rkb3V0IGlzIHVzZWQNCmZvciBzdGF0dXMgbWVz
c2FnZXMuDQoNCi0tLSB4ZW4tNC41LjAtcmMxL3Rvb2xzL2xpYnhsL3hsX2Nt
ZGltcGwuYy5vcmlnCTIwMTQtMTAtMjQgMTU6MjI6NDAuMDAwMDAwMDAwICsw
MTAwDQorKysgeGVuLTQuNS4wLXJjMS90b29scy9saWJ4bC94bF9jbWRpbXBs
LmMJMjAxNC0xMS0yNSAyMDoyOTowNi43MjM4NTY0MzMgKzAwMDANCkBAIC0z
ODMsNyArMzgzLDcgQEANCiAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4
bF9kb21haW5fY29uZmlnICpkX2NvbmZpZykNCiB7DQogICAgIGlmIChvdXRw
dXRfZm9ybWF0ID09IE9VVFBVVF9GT1JNQVRfU1hQKQ0KLSAgICAgICAgcmV0
dXJuIHByaW50Zl9pbmZvX3NleHAoZG9taWQsIGRfY29uZmlnKTsNCisgICAg
ICAgIHJldHVybiBwcmludGZfaW5mb19zZXhwKGRvbWlkLCBkX2NvbmZpZywg
c3RkZXJyKTsNCiANCiAgICAgY29uc3QgY2hhciAqYnVmOw0KICAgICBsaWJ4
bF95YWpsX2xlbmd0aCBsZW4gPSAwOw0KQEAgLTQwNCw3ICs0MDQsNyBAQA0K
ICAgICBpZiAocyAhPSB5YWpsX2dlbl9zdGF0dXNfb2spDQogICAgICAgICBn
b3RvIG91dDsNCiANCi0gICAgcHV0cyhidWYpOw0KKyAgICBmcHV0cyhidWYs
c3RkZXJyKTsNCiANCiBvdXQ6DQogICAgIHlhamxfZ2VuX2ZyZWUoaGFuZCk7
DQpAQCAtNDEzLDcgKzQxMyw3IEBADQogICAgICAgICBmcHJpbnRmKHN0ZGVy
ciwNCiAgICAgICAgICAgICAgICAgInVuYWJsZSB0byBmb3JtYXQgZG9tYWlu
IGNvbmZpZyBhcyBKU09OIChZQUpMOiVkKVxuIiwgcyk7DQogDQotICAgIGlm
IChmZXJyb3Ioc3Rkb3V0KSB8fCBmZmx1c2goc3Rkb3V0KSkgeyBwZXJyb3Io
InN0ZG91dCIpOyBleGl0KC0xKTsgfQ0KKyAgICBpZiAoZmVycm9yKHN0ZGVy
cikgfHwgZmZsdXNoKHN0ZGVycikpIHsgcGVycm9yKCJzdGRlcnIiKTsgZXhp
dCgtMSk7IH0NCiB9DQogDQogc3RhdGljIGludCBkb19kYWVtb25pemUoY2hh
ciAqbmFtZSkNCkBAIC0yNDIzLDcgKzI0MjMsNyBAQA0KICAgICB9DQogDQog
ICAgIGlmICghZG9tX2luZm8tPnF1aWV0KQ0KLSAgICAgICAgcHJpbnRmKCJQ
YXJzaW5nIGNvbmZpZyBmcm9tICVzXG4iLCBjb25maWdfc291cmNlKTsNCisg
ICAgICAgIGZwcmludGYoc3RkZXJyLCAiUGFyc2luZyBjb25maWcgZnJvbSAl
c1xuIiwgY29uZmlnX3NvdXJjZSk7DQogDQogICAgIGlmIChjb25maWdfaW5f
anNvbikgew0KICAgICAgICAgbGlieGxfZG9tYWluX2NvbmZpZ19mcm9tX2pz
b24oY3R4LCAmZF9jb25maWcsDQpAQCAtMzQwMyw3ICszNDAzLDcgQEANCiAg
ICAgICAgIGlmIChkZWZhdWx0X291dHB1dF9mb3JtYXQgPT0gT1VUUFVUX0ZP
Uk1BVF9KU09OKQ0KICAgICAgICAgICAgIHMgPSBwcmludGZfaW5mb19vbmVf
anNvbihoYW5kLCBpbmZvW2ldLmRvbWlkLCAmZF9jb25maWcpOw0KICAgICAg
ICAgZWxzZQ0KLSAgICAgICAgICAgIHByaW50Zl9pbmZvX3NleHAoaW5mb1tp
XS5kb21pZCwgJmRfY29uZmlnKTsNCisgICAgICAgICAgICBwcmludGZfaW5m
b19zZXhwKGluZm9baV0uZG9taWQsICZkX2NvbmZpZywgc3Rkb3V0KTsNCiAg
ICAgICAgIGxpYnhsX2RvbWFpbl9jb25maWdfZGlzcG9zZSgmZF9jb25maWcp
Ow0KICAgICAgICAgaWYgKHMgIT0geWFqbF9nZW5fc3RhdHVzX29rKQ0KICAg
ICAgICAgICAgIGdvdG8gb3V0Ow0KLS0tIHhlbi00LjUuMC1yYzEvdG9vbHMv
bGlieGwveGxfc3hwLmMub3JpZwkyMDE0LTEwLTI0IDE1OjIyOjQwLjAwMDAw
MDAwMCArMDEwMA0KKysrIHhlbi00LjUuMC1yYzEvdG9vbHMvbGlieGwveGxf
c3hwLmMJMjAxNC0xMS0yNSAyMDoyNzoyMS45MTEwMzY3MTMgKzAwMDANCkBA
IC0zMCw3ICszMCw3IEBADQogLyogSW4gZ2VuZXJhbCB5b3Ugc2hvdWxkIG5v
dCBhZGQgbmV3IG91dHB1dCB0byB0aGlzIGZ1bmN0aW9uIHNpbmNlIGl0DQog
ICogaXMgaW50ZW5kZWQgb25seSBmb3IgbGVnYWN5IHVzZS4NCiAgKi8NCi12
b2lkIHByaW50Zl9pbmZvX3NleHAoaW50IGRvbWlkLCBsaWJ4bF9kb21haW5f
Y29uZmlnICpkX2NvbmZpZykNCit2b2lkIHByaW50Zl9pbmZvX3NleHAoaW50
IGRvbWlkLCBsaWJ4bF9kb21haW5fY29uZmlnICpkX2NvbmZpZywgRklMRSAq
ZmgpDQogew0KICAgICBpbnQgaTsNCiAgICAgbGlieGxfZG9taW5mbyBpbmZv
Ow0KQEAgLTM4LDE5NSArMzgsMTk1IEBADQogICAgIGxpYnhsX2RvbWFpbl9j
cmVhdGVfaW5mbyAqY19pbmZvID0gJmRfY29uZmlnLT5jX2luZm87DQogICAg
IGxpYnhsX2RvbWFpbl9idWlsZF9pbmZvICpiX2luZm8gPSAmZF9jb25maWct
PmJfaW5mbzsNCiANCi0gICAgcHJpbnRmKCIoZG9tYWluXG5cdChkb21pZCAl
ZClcbiIsIGRvbWlkKTsNCi0gICAgcHJpbnRmKCJcdChjcmVhdGVfaW5mbylc
biIpOw0KLSAgICBwcmludGYoIlx0KGh2bSAlZClcbiIsIGNfaW5mby0+dHlw
ZSA9PSBMSUJYTF9ET01BSU5fVFlQRV9IVk0pOw0KLSAgICBwcmludGYoIlx0
KGhhcCAlcylcbiIsIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGNfaW5mby0+
aGFwKSk7DQotICAgIHByaW50ZigiXHQob29zICVzKVxuIiwgbGlieGxfZGVm
Ym9vbF90b19zdHJpbmcoY19pbmZvLT5vb3MpKTsNCi0gICAgcHJpbnRmKCJc
dChzc2lkcmVmICVkKVxuIiwgY19pbmZvLT5zc2lkcmVmKTsNCi0gICAgcHJp
bnRmKCJcdChuYW1lICVzKVxuIiwgY19pbmZvLT5uYW1lKTsNCisgICAgZnBy
aW50ZihmaCwgIihkb21haW5cblx0KGRvbWlkICVkKVxuIiwgZG9taWQpOw0K
KyAgICBmcHJpbnRmKGZoLCAiXHQoY3JlYXRlX2luZm8pXG4iKTsNCisgICAg
ZnByaW50ZihmaCwgIlx0KGh2bSAlZClcbiIsIGNfaW5mby0+dHlwZSA9PSBM
SUJYTF9ET01BSU5fVFlQRV9IVk0pOw0KKyAgICBmcHJpbnRmKGZoLCAiXHQo
aGFwICVzKVxuIiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoY19pbmZvLT5o
YXApKTsNCisgICAgZnByaW50ZihmaCwgIlx0KG9vcyAlcylcbiIsIGxpYnhs
X2RlZmJvb2xfdG9fc3RyaW5nKGNfaW5mby0+b29zKSk7DQorICAgIGZwcmlu
dGYoZmgsICJcdChzc2lkcmVmICVkKVxuIiwgY19pbmZvLT5zc2lkcmVmKTsN
CisgICAgZnByaW50ZihmaCwgIlx0KG5hbWUgJXMpXG4iLCBjX2luZm8tPm5h
bWUpOw0KIA0KICAgICAvKiByZXRyaWV2ZSB0aGUgVVVJRCBmcm9tIGRvbWlu
Zm8sIHNpbmNlIGl0IGlzIHByb2JhYmx5IGdlbmVyYXRlZA0KICAgICAgKiBk
dXJpbmcgcGFyc2luZyBhbmQgdGh1cyBkb2VzIG5vdCBtYXRjaCB0aGUgcmVh
bCBvbmUNCiAgICAgICovDQogICAgIGlmIChsaWJ4bF9kb21haW5faW5mbyhj
dHgsICZpbmZvLCBkb21pZCkgPT0gMCkgew0KLSAgICAgICAgcHJpbnRmKCJc
dCh1dWlkICIgTElCWExfVVVJRF9GTVQgIilcbiIsIExJQlhMX1VVSURfQllU
RVMoaW5mby51dWlkKSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHQodXVp
ZCAiIExJQlhMX1VVSURfRk1UICIpXG4iLCBMSUJYTF9VVUlEX0JZVEVTKGlu
Zm8udXVpZCkpOw0KICAgICB9IGVsc2Ugew0KLSAgICAgICAgcHJpbnRmKCJc
dCh1dWlkIDx1bmtub3duPilcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwg
Ilx0KHV1aWQgPHVua25vd24+KVxuIik7DQogICAgIH0NCiAgICAgaWYgKGNf
aW5mby0+cG9vbF9uYW1lKQ0KLSAgICAgICAgcHJpbnRmKCJcdChjcHVwb29s
ICVzKVxuIiwgY19pbmZvLT5wb29sX25hbWUpOw0KKyAgICAgICAgZnByaW50
ZihmaCwgIlx0KGNwdXBvb2wgJXMpXG4iLCBjX2luZm8tPnBvb2xfbmFtZSk7
DQogICAgIGlmIChjX2luZm8tPnhzZGF0YSkNCi0gICAgICAgIHByaW50Zigi
XHQoeHNkYXRhIGNvbnRhaW5zIGRhdGEpXG4iKTsNCisgICAgICAgIGZwcmlu
dGYoZmgsICJcdCh4c2RhdGEgY29udGFpbnMgZGF0YSlcbiIpOw0KICAgICBl
bHNlDQotICAgICAgICBwcmludGYoIlx0KHhzZGF0YSAobnVsbCkpXG4iKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdCh4c2RhdGEgKG51bGwpKVxuIik7
DQogICAgIGlmIChjX2luZm8tPnBsYXRmb3JtZGF0YSkNCi0gICAgICAgIHBy
aW50ZigiXHQocGxhdGZvcm1kYXRhIGNvbnRhaW5zIGRhdGEpXG4iKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdChwbGF0Zm9ybWRhdGEgY29udGFpbnMg
ZGF0YSlcbiIpOw0KICAgICBlbHNlDQotICAgICAgICBwcmludGYoIlx0KHBs
YXRmb3JtZGF0YSAobnVsbCkpXG4iKTsNCisgICAgICAgIGZwcmludGYoZmgs
ICJcdChwbGF0Zm9ybWRhdGEgKG51bGwpKVxuIik7DQogDQogDQotICAgIHBy
aW50ZigiXHQoYnVpbGRfaW5mbylcbiIpOw0KLSAgICBwcmludGYoIlx0KG1h
eF92Y3B1cyAlZClcbiIsIGJfaW5mby0+bWF4X3ZjcHVzKTsNCi0gICAgcHJp
bnRmKCJcdCh0c2NfbW9kZSAlcylcbiIsIGxpYnhsX3RzY19tb2RlX3RvX3N0
cmluZyhiX2luZm8tPnRzY19tb2RlKSk7DQotICAgIHByaW50ZigiXHQobWF4
X21lbWtiICUiUFJJZDY0IilcbiIsIGJfaW5mby0+bWF4X21lbWtiKTsNCi0g
ICAgcHJpbnRmKCJcdCh0YXJnZXRfbWVta2IgJSJQUklkNjQiKVxuIiwgYl9p
bmZvLT50YXJnZXRfbWVta2IpOw0KLSAgICBwcmludGYoIlx0KG5vbWlncmF0
ZSAlcylcbiIsDQorICAgIGZwcmludGYoZmgsICJcdChidWlsZF9pbmZvKVxu
Iik7DQorICAgIGZwcmludGYoZmgsICJcdChtYXhfdmNwdXMgJWQpXG4iLCBi
X2luZm8tPm1heF92Y3B1cyk7DQorICAgIGZwcmludGYoZmgsICJcdCh0c2Nf
bW9kZSAlcylcbiIsIGxpYnhsX3RzY19tb2RlX3RvX3N0cmluZyhiX2luZm8t
PnRzY19tb2RlKSk7DQorICAgIGZwcmludGYoZmgsICJcdChtYXhfbWVta2Ig
JSJQUklkNjQiKVxuIiwgYl9pbmZvLT5tYXhfbWVta2IpOw0KKyAgICBmcHJp
bnRmKGZoLCAiXHQodGFyZ2V0X21lbWtiICUiUFJJZDY0IilcbiIsIGJfaW5m
by0+dGFyZ2V0X21lbWtiKTsNCisgICAgZnByaW50ZihmaCwgIlx0KG5vbWln
cmF0ZSAlcylcbiIsDQogICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0
cmluZyhiX2luZm8tPmRpc2FibGVfbWlncmF0ZSkpOw0KIA0KICAgICBpZiAo
Y19pbmZvLT50eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX1BWICYmIGJfaW5m
by0+dS5wdi5ib290bG9hZGVyKSB7DQotICAgICAgICBwcmludGYoIlx0KGJv
b3Rsb2FkZXIgJXMpXG4iLCBiX2luZm8tPnUucHYuYm9vdGxvYWRlcik7DQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHQoYm9vdGxvYWRlciAlcylcbiIsIGJf
aW5mby0+dS5wdi5ib290bG9hZGVyKTsNCiAgICAgICAgIGlmIChiX2luZm8t
PnUucHYuYm9vdGxvYWRlcl9hcmdzKSB7DQotICAgICAgICAgICAgcHJpbnRm
KCJcdChib290bG9hZGVyX2FyZ3MiKTsNCisgICAgICAgICAgICBmcHJpbnRm
KGZoLCAiXHQoYm9vdGxvYWRlcl9hcmdzIik7DQogICAgICAgICAgICAgZm9y
IChpPTA7IGJfaW5mby0+dS5wdi5ib290bG9hZGVyX2FyZ3NbaV07IGkrKykN
Ci0gICAgICAgICAgICAgICAgcHJpbnRmKCIgJXMiLCBiX2luZm8tPnUucHYu
Ym9vdGxvYWRlcl9hcmdzW2ldKTsNCi0gICAgICAgICAgICBwcmludGYoIilc
biIpOw0KKyAgICAgICAgICAgICAgICBmcHJpbnRmKGZoLCAiICVzIiwgYl9p
bmZvLT51LnB2LmJvb3Rsb2FkZXJfYXJnc1tpXSk7DQorICAgICAgICAgICAg
ZnByaW50ZihmaCwgIilcbiIpOw0KICAgICAgICAgfQ0KICAgICB9DQogDQot
ICAgIHByaW50ZigiXHQoaW1hZ2VcbiIpOw0KKyAgICBmcHJpbnRmKGZoLCAi
XHQoaW1hZ2VcbiIpOw0KICAgICBzd2l0Y2ggKGNfaW5mby0+dHlwZSkgew0K
ICAgICBjYXNlIExJQlhMX0RPTUFJTl9UWVBFX0hWTToNCi0gICAgICAgIHBy
aW50ZigiXHRcdChodm1cbiIpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQo
ZmlybXdhcmUgJXMpXG4iLCBiX2luZm8tPnUuaHZtLmZpcm13YXJlKTsNCi0g
ICAgICAgIHByaW50ZigiXHRcdFx0KHZpZGVvX21lbWtiICUiUFJJZDY0Iilc
biIsIGJfaW5mby0+dmlkZW9fbWVta2IpOw0KLSAgICAgICAgcHJpbnRmKCJc
dFx0XHQoc2hhZG93X21lbWtiICUiUFJJZDY0IilcbiIsIGJfaW5mby0+c2hh
ZG93X21lbWtiKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHBhZSAlcylc
biIsIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0ucGFl
KSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChhcGljICVzKVxuIiwNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0KGh2bVxuIik7DQorICAgICAgICBm
cHJpbnRmKGZoLCAiXHRcdFx0KGZpcm13YXJlICVzKVxuIiwgYl9pbmZvLT51
Lmh2bS5maXJtd2FyZSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0
KHZpZGVvX21lbWtiICUiUFJJZDY0IilcbiIsIGJfaW5mby0+dmlkZW9fbWVt
a2IpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzaGFkb3dfbWVt
a2IgJSJQUklkNjQiKVxuIiwgYl9pbmZvLT5zaGFkb3dfbWVta2IpOw0KKyAg
ICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChwYWUgJXMpXG4iLCBsaWJ4bF9k
ZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnBhZSkpOw0KKyAgICAg
ICAgZnByaW50ZihmaCwgIlx0XHRcdChhcGljICVzKVxuIiwNCiAgICAgICAg
ICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZt
LmFwaWMpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGFjcGkgJXMpXG4i
LA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChhY3BpICVzKVxuIiwN
CiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2lu
Zm8tPnUuaHZtLmFjcGkpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KG54
ICVzKVxuIiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2
bS5ueCkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodmlyaWRpYW4gJXMp
XG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChueCAlcylcbiIs
IGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0ubngpKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQodmlyaWRpYW4gJXMpXG4i
LA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJf
aW5mby0+dS5odm0udmlyaWRpYW4pKTsNCi0gICAgICAgIHByaW50ZigiXHRc
dFx0KGhwZXQgJXMpXG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRc
dChocGV0ICVzKVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29s
X3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLmhwZXQpKTsNCi0gICAgICAgIHBy
aW50ZigiXHRcdFx0KHZwdF9hbGlnbiAlcylcbiIsDQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHRcdFx0KHZwdF9hbGlnbiAlcylcbiIsDQogICAgICAgICAg
ICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS52
cHRfYWxpZ24pKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHRpbWVyX21v
ZGUgJXMpXG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh0aW1l
cl9tb2RlICVzKVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF90aW1lcl9t
b2RlX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnRpbWVyX21vZGUpKTsNCi0g
ICAgICAgIHByaW50ZigiXHRcdFx0KG5lc3RlZGh2bSAlcylcbiIsDQorICAg
ICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KG5lc3RlZGh2bSAlcylcbiIsDQog
ICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZv
LT51Lmh2bS5uZXN0ZWRfaHZtKSk7DQotICAgICAgICBwcmludGYoIlx0XHRc
dChzdGR2Z2EgJXMpXG4iLCBiX2luZm8tPnUuaHZtLnZnYS5raW5kID09DQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHN0ZHZnYSAlcylcbiIsIGJf
aW5mby0+dS5odm0udmdhLmtpbmQgPT0NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9T
VEQgPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IlRydWUiIDogIkZhbHNlIik7DQotICAgICAgICBwcmludGYoIlx0XHRcdCh2
bmMgJXMpXG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh2bmMg
JXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3Ry
aW5nKGJfaW5mby0+dS5odm0udm5jLmVuYWJsZSkpOw0KLSAgICAgICAgcHJp
bnRmKCJcdFx0XHQodm5jbGlzdGVuICVzKVxuIiwgYl9pbmZvLT51Lmh2bS52
bmMubGlzdGVuKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHZuY2Rpc3Bs
YXkgJWQpXG4iLCBiX2luZm8tPnUuaHZtLnZuYy5kaXNwbGF5KTsNCi0gICAg
ICAgIHByaW50ZigiXHRcdFx0KHZuY3VudXNlZCAlcylcbiIsDQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHRcdFx0KHZuY2xpc3RlbiAlcylcbiIsIGJfaW5m
by0+dS5odm0udm5jLmxpc3Rlbik7DQorICAgICAgICBmcHJpbnRmKGZoLCAi
XHRcdFx0KHZuY2Rpc3BsYXkgJWQpXG4iLCBiX2luZm8tPnUuaHZtLnZuYy5k
aXNwbGF5KTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQodm5jdW51
c2VkICVzKVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3Rv
X3N0cmluZyhiX2luZm8tPnUuaHZtLnZuYy5maW5kdW51c2VkKSk7DQotICAg
ICAgICBwcmludGYoIlx0XHRcdChrZXltYXAgJXMpXG4iLCBiX2luZm8tPnUu
aHZtLmtleW1hcCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChzZGwgJXMp
XG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChrZXltYXAgJXMp
XG4iLCBiX2luZm8tPnUuaHZtLmtleW1hcCk7DQorICAgICAgICBmcHJpbnRm
KGZoLCAiXHRcdFx0KHNkbCAlcylcbiIsDQogICAgICAgICAgICAgICAgbGli
eGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS5zZGwuZW5hYmxl
KSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChvcGVuZ2wgJXMpXG4iLA0K
KyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChvcGVuZ2wgJXMpXG4iLA0K
ICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5m
by0+dS5odm0uc2RsLm9wZW5nbCkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0
XHQobm9ncmFwaGljICVzKVxuIiwNCisgICAgICAgIGZwcmludGYoZmgsICJc
dFx0XHQobm9ncmFwaGljICVzKVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4
bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLm5vZ3JhcGhpYykp
Ow0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoc3BpY2UgJXMpXG4iLA0KKyAg
ICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzcGljZSAlcylcbiIsDQogICAg
ICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51
Lmh2bS5zcGljZS5lbmFibGUpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0
KHNwaWNlcG9ydCAlZClcbiIsIGJfaW5mby0+dS5odm0uc3BpY2UucG9ydCk7
DQotICAgICAgICBwcmludGYoIlx0XHRcdChzcGljZXRsc19wb3J0ICVkKVxu
IiwgYl9pbmZvLT51Lmh2bS5zcGljZS50bHNfcG9ydCk7DQotICAgICAgICBw
cmludGYoIlx0XHRcdChzcGljZWhvc3QgJXMpXG4iLCBiX2luZm8tPnUuaHZt
LnNwaWNlLmhvc3QpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoc3BpY2Vk
aXNhYmxlX3RpY2tldGluZyAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZo
LCAiXHRcdFx0KHNwaWNlcG9ydCAlZClcbiIsIGJfaW5mby0+dS5odm0uc3Bp
Y2UucG9ydCk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHNwaWNl
dGxzX3BvcnQgJWQpXG4iLCBiX2luZm8tPnUuaHZtLnNwaWNlLnRsc19wb3J0
KTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoc3BpY2Vob3N0ICVz
KVxuIiwgYl9pbmZvLT51Lmh2bS5zcGljZS5ob3N0KTsNCisgICAgICAgIGZw
cmludGYoZmgsICJcdFx0XHQoc3BpY2VkaXNhYmxlX3RpY2tldGluZyAlcylc
biIsDQogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmco
Yl9pbmZvLT51Lmh2bS5zcGljZS5kaXNhYmxlX3RpY2tldGluZykpOw0KLSAg
ICAgICAgcHJpbnRmKCJcdFx0XHQoc3BpY2VhZ2VudF9tb3VzZSAlcylcbiIs
DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHNwaWNlYWdlbnRfbW91
c2UgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9f
c3RyaW5nKGJfaW5mby0+dS5odm0uc3BpY2UuYWdlbnRfbW91c2UpKTsNCiAN
Ci0gICAgICAgIHByaW50ZigiXHRcdFx0KGRldmljZV9tb2RlbCAlcylcbiIs
IGJfaW5mby0+ZGV2aWNlX21vZGVsID8gOiAiZGVmYXVsdCIpOw0KLSAgICAg
ICAgcHJpbnRmKCJcdFx0XHQoZ2Z4X3Bhc3N0aHJ1ICVzKVxuIiwNCisgICAg
ICAgIGZwcmludGYoZmgsICJcdFx0XHQoZGV2aWNlX21vZGVsICVzKVxuIiwg
Yl9pbmZvLT5kZXZpY2VfbW9kZWwgPyA6ICJkZWZhdWx0Iik7DQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHRcdFx0KGdmeF9wYXNzdGhydSAlcylcbiIsDQog
ICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZv
LT51Lmh2bS5nZnhfcGFzc3RocnUpKTsNCi0gICAgICAgIHByaW50ZigiXHRc
dFx0KHNlcmlhbCAlcylcbiIsIGJfaW5mby0+dS5odm0uc2VyaWFsKTsNCi0g
ICAgICAgIHByaW50ZigiXHRcdFx0KGJvb3QgJXMpXG4iLCBiX2luZm8tPnUu
aHZtLmJvb3QpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodXNiICVzKVxu
IiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS51c2Ip
KTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHVzYmRldmljZSAlcylcbiIs
IGJfaW5mby0+dS5odm0udXNiZGV2aWNlKTsNCi0gICAgICAgIHByaW50Zigi
XHRcdClcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzZXJp
YWwgJXMpXG4iLCBiX2luZm8tPnUuaHZtLnNlcmlhbCk7DQorICAgICAgICBm
cHJpbnRmKGZoLCAiXHRcdFx0KGJvb3QgJXMpXG4iLCBiX2luZm8tPnUuaHZt
LmJvb3QpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh1c2IgJXMp
XG4iLCBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnVz
YikpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh1c2JkZXZpY2Ug
JXMpXG4iLCBiX2luZm8tPnUuaHZtLnVzYmRldmljZSk7DQorICAgICAgICBm
cHJpbnRmKGZoLCAiXHRcdClcbiIpOw0KICAgICAgICAgYnJlYWs7DQogICAg
IGNhc2UgTElCWExfRE9NQUlOX1RZUEVfUFY6DQotICAgICAgICBwcmludGYo
Ilx0XHQobGludXggJWQpXG4iLCAwKTsNCi0gICAgICAgIHByaW50ZigiXHRc
dFx0KGtlcm5lbCAlcylcbiIsIGJfaW5mby0+a2VybmVsKTsNCi0gICAgICAg
IHByaW50ZigiXHRcdFx0KGNtZGxpbmUgJXMpXG4iLCBiX2luZm8tPmNtZGxp
bmUpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQocmFtZGlzayAlcylcbiIs
IGJfaW5mby0+cmFtZGlzayk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChl
ODIwX2hvc3QgJXMpXG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQo
bGludXggJWQpXG4iLCAwKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0
XHQoa2VybmVsICVzKVxuIiwgYl9pbmZvLT5rZXJuZWwpOw0KKyAgICAgICAg
ZnByaW50ZihmaCwgIlx0XHRcdChjbWRsaW5lICVzKVxuIiwgYl9pbmZvLT5j
bWRsaW5lKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQocmFtZGlz
ayAlcylcbiIsIGJfaW5mby0+cmFtZGlzayk7DQorICAgICAgICBmcHJpbnRm
KGZoLCAiXHRcdFx0KGU4MjBfaG9zdCAlcylcbiIsDQogICAgICAgICAgICAg
ICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51LnB2LmU4MjBf
aG9zdCkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0KVxuIik7DQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHRcdClcbiIpOw0KICAgICAgICAgYnJlYWs7DQog
ICAgIGRlZmF1bHQ6DQogICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIlVua25v
d24gZG9tYWluIHR5cGUgJWRcbiIsIGNfaW5mby0+dHlwZSk7DQogICAgICAg
ICBleGl0KDEpOw0KICAgICB9DQotICAgIHByaW50ZigiXHQpXG4iKTsNCisg
ICAgZnByaW50ZihmaCwgIlx0KVxuIik7DQogDQogICAgIGZvciAoaSA9IDA7
IGkgPCBkX2NvbmZpZy0+bnVtX2Rpc2tzOyBpKyspIHsNCi0gICAgICAgIHBy
aW50ZigiXHQoZGV2aWNlXG4iKTsNCi0gICAgICAgIHByaW50ZigiXHRcdCh0
YXBcbiIpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoYmFja2VuZF9kb21p
ZCAlZClcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS5iYWNrZW5kX2RvbWlkKTsN
Ci0gICAgICAgIHByaW50ZigiXHRcdFx0KGZyb250ZW5kX2RvbWlkICVkKVxu
IiwgZG9taWQpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQocGh5c3BhdGgg
JXMpXG4iLCBkX2NvbmZpZy0+ZGlza3NbaV0ucGRldl9wYXRoKTsNCi0gICAg
ICAgIHByaW50ZigiXHRcdFx0KHBoeXN0eXBlICVkKVxuIiwgZF9jb25maWct
PmRpc2tzW2ldLmJhY2tlbmQpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQo
dmlydHBhdGggJXMpXG4iLCBkX2NvbmZpZy0+ZGlza3NbaV0udmRldik7DQot
ICAgICAgICBwcmludGYoIlx0XHRcdCh1bnBsdWdnYWJsZSAlZClcbiIsIGRf
Y29uZmlnLT5kaXNrc1tpXS5yZW1vdmFibGUpOw0KLSAgICAgICAgcHJpbnRm
KCJcdFx0XHQocmVhZHdyaXRlICVkKVxuIiwgZF9jb25maWctPmRpc2tzW2ld
LnJlYWR3cml0ZSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChpc19jZHJv
bSAlZClcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS5pc19jZHJvbSk7DQotICAg
ICAgICBwcmludGYoIlx0XHQpXG4iKTsNCi0gICAgICAgIHByaW50ZigiXHQp
XG4iKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdChkZXZpY2VcbiIpOw0K
KyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQodGFwXG4iKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdFx0XHQoYmFja2VuZF9kb21pZCAlZClcbiIsIGRf
Y29uZmlnLT5kaXNrc1tpXS5iYWNrZW5kX2RvbWlkKTsNCisgICAgICAgIGZw
cmludGYoZmgsICJcdFx0XHQoZnJvbnRlbmRfZG9taWQgJWQpXG4iLCBkb21p
ZCk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHBoeXNwYXRoICVz
KVxuIiwgZF9jb25maWctPmRpc2tzW2ldLnBkZXZfcGF0aCk7DQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHRcdFx0KHBoeXN0eXBlICVkKVxuIiwgZF9jb25m
aWctPmRpc2tzW2ldLmJhY2tlbmQpOw0KKyAgICAgICAgZnByaW50ZihmaCwg
Ilx0XHRcdCh2aXJ0cGF0aCAlcylcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS52
ZGV2KTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQodW5wbHVnZ2Fi
bGUgJWQpXG4iLCBkX2NvbmZpZy0+ZGlza3NbaV0ucmVtb3ZhYmxlKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQocmVhZHdyaXRlICVkKVxuIiwg
ZF9jb25maWctPmRpc2tzW2ldLnJlYWR3cml0ZSk7DQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHRcdFx0KGlzX2Nkcm9tICVkKVxuIiwgZF9jb25maWctPmRp
c2tzW2ldLmlzX2Nkcm9tKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0
KVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHQpXG4iKTsNCiAgICAg
fQ0KIA0KICAgICBmb3IgKGkgPSAwOyBpIDwgZF9jb25maWctPm51bV9uaWNz
OyBpKyspIHsNCi0gICAgICAgIHByaW50ZigiXHQoZGV2aWNlXG4iKTsNCi0g
ICAgICAgIHByaW50ZigiXHRcdCh2aWZcbiIpOw0KKyAgICAgICAgZnByaW50
ZihmaCwgIlx0KGRldmljZVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAi
XHRcdCh2aWZcbiIpOw0KICAgICAgICAgaWYgKGRfY29uZmlnLT5uaWNzW2ld
LmlmbmFtZSkNCi0gICAgICAgICAgICBwcmludGYoIlx0XHRcdCh2aWZuYW1l
ICVzKVxuIiwgZF9jb25maWctPm5pY3NbaV0uaWZuYW1lKTsNCi0gICAgICAg
IHByaW50ZigiXHRcdFx0KGJhY2tlbmRfZG9taWQgJWQpXG4iLCBkX2NvbmZp
Zy0+bmljc1tpXS5iYWNrZW5kX2RvbWlkKTsNCi0gICAgICAgIHByaW50Zigi
XHRcdFx0KGZyb250ZW5kX2RvbWlkICVkKVxuIiwgZG9taWQpOw0KLSAgICAg
ICAgcHJpbnRmKCJcdFx0XHQoZGV2aWQgJWQpXG4iLCBkX2NvbmZpZy0+bmlj
c1tpXS5kZXZpZCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChtdHUgJWQp
XG4iLCBkX2NvbmZpZy0+bmljc1tpXS5tdHUpOw0KLSAgICAgICAgcHJpbnRm
KCJcdFx0XHQobW9kZWwgJXMpXG4iLCBkX2NvbmZpZy0+bmljc1tpXS5tb2Rl
bCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChtYWMgJTAyeCUwMnglMDJ4
JTAyeCUwMnglMDJ4KVxuIiwNCisgICAgICAgICAgICBmcHJpbnRmKGZoLCAi
XHRcdFx0KHZpZm5hbWUgJXMpXG4iLCBkX2NvbmZpZy0+bmljc1tpXS5pZm5h
bWUpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChiYWNrZW5kX2Rv
bWlkICVkKVxuIiwgZF9jb25maWctPm5pY3NbaV0uYmFja2VuZF9kb21pZCk7
DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGZyb250ZW5kX2RvbWlk
ICVkKVxuIiwgZG9taWQpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRc
dChkZXZpZCAlZClcbiIsIGRfY29uZmlnLT5uaWNzW2ldLmRldmlkKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQobXR1ICVkKVxuIiwgZF9jb25m
aWctPm5pY3NbaV0ubXR1KTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0
XHQobW9kZWwgJXMpXG4iLCBkX2NvbmZpZy0+bmljc1tpXS5tb2RlbCk7DQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KG1hYyAlMDJ4JTAyeCUwMngl
MDJ4JTAyeCUwMngpXG4iLA0KICAgICAgICAgICAgICAgIGRfY29uZmlnLT5u
aWNzW2ldLm1hY1swXSwgZF9jb25maWctPm5pY3NbaV0ubWFjWzFdLA0KICAg
ICAgICAgICAgICAgIGRfY29uZmlnLT5uaWNzW2ldLm1hY1syXSwgZF9jb25m
aWctPm5pY3NbaV0ubWFjWzNdLA0KICAgICAgICAgICAgICAgIGRfY29uZmln
LT5uaWNzW2ldLm1hY1s0XSwgZF9jb25maWctPm5pY3NbaV0ubWFjWzVdKTsN
Ci0gICAgICAgIHByaW50ZigiXHRcdClcbiIpOw0KLSAgICAgICAgcHJpbnRm
KCJcdClcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQpXG4iKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdClcbiIpOw0KICAgICB9DQogDQog
ICAgIGZvciAoaSA9IDA7IGkgPCBkX2NvbmZpZy0+bnVtX3BjaWRldnM7IGkr
Kykgew0KLSAgICAgICAgcHJpbnRmKCJcdChkZXZpY2VcbiIpOw0KLSAgICAg
ICAgcHJpbnRmKCJcdFx0KHBjaVxuIik7DQotICAgICAgICBwcmludGYoIlx0
XHRcdChwY2kgZGV2ICUwNHg6JTAyeDolMDJ4LiUwMXhAJTAyeClcbiIsDQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHQoZGV2aWNlXG4iKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdFx0KHBjaVxuIik7DQorICAgICAgICBmcHJpbnRm
KGZoLCAiXHRcdFx0KHBjaSBkZXYgJTA0eDolMDJ4OiUwMnguJTAxeEAlMDJ4
KVxuIiwNCiAgICAgICAgICAgICAgICBkX2NvbmZpZy0+cGNpZGV2c1tpXS5k
b21haW4sIGRfY29uZmlnLT5wY2lkZXZzW2ldLmJ1cywNCiAgICAgICAgICAg
ICAgICBkX2NvbmZpZy0+cGNpZGV2c1tpXS5kZXYsIGRfY29uZmlnLT5wY2lk
ZXZzW2ldLmZ1bmMsDQogICAgICAgICAgICAgICAgZF9jb25maWctPnBjaWRl
dnNbaV0udmRldmZuKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KG9wdHMg
bXNpdHJhbnNsYXRlICVkIHBvd2VyX21nbXQgJWQpXG4iLA0KKyAgICAgICAg
ZnByaW50ZihmaCwgIlx0XHRcdChvcHRzIG1zaXRyYW5zbGF0ZSAlZCBwb3dl
cl9tZ210ICVkKVxuIiwNCiAgICAgICAgICAgICAgICBkX2NvbmZpZy0+cGNp
ZGV2c1tpXS5tc2l0cmFuc2xhdGUsDQogICAgICAgICAgICAgICAgZF9jb25m
aWctPnBjaWRldnNbaV0ucG93ZXJfbWdtdCk7DQotICAgICAgICBwcmludGYo
Ilx0XHQpXG4iKTsNCi0gICAgICAgIHByaW50ZigiXHQpXG4iKTsNCisgICAg
ICAgIGZwcmludGYoZmgsICJcdFx0KVxuIik7DQorICAgICAgICBmcHJpbnRm
KGZoLCAiXHQpXG4iKTsNCiAgICAgfQ0KIA0KICAgICBmb3IgKGkgPSAwOyBp
IDwgZF9jb25maWctPm51bV92ZmJzOyBpKyspIHsNCi0gICAgICAgIHByaW50
ZigiXHQoZGV2aWNlXG4iKTsNCi0gICAgICAgIHByaW50ZigiXHRcdCh2ZmJc
biIpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoYmFja2VuZF9kb21pZCAl
ZClcbiIsIGRfY29uZmlnLT52ZmJzW2ldLmJhY2tlbmRfZG9taWQpOw0KLSAg
ICAgICAgcHJpbnRmKCJcdFx0XHQoZnJvbnRlbmRfZG9taWQgJWQpXG4iLCBk
b21pZCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChkZXZpZCAlZClcbiIs
IGRfY29uZmlnLT52ZmJzW2ldLmRldmlkKTsNCi0gICAgICAgIHByaW50Zigi
XHRcdFx0KHZuYyAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHQo
ZGV2aWNlXG4iKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0KHZmYlxu
Iik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGJhY2tlbmRfZG9t
aWQgJWQpXG4iLCBkX2NvbmZpZy0+dmZic1tpXS5iYWNrZW5kX2RvbWlkKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoZnJvbnRlbmRfZG9taWQg
JWQpXG4iLCBkb21pZCk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0
KGRldmlkICVkKVxuIiwgZF9jb25maWctPnZmYnNbaV0uZGV2aWQpOw0KKyAg
ICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh2bmMgJXMpXG4iLA0KICAgICAg
ICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGRfY29uZmlnLT52
ZmJzW2ldLnZuYy5lbmFibGUpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0
KHZuY2xpc3RlbiAlcylcbiIsIGRfY29uZmlnLT52ZmJzW2ldLnZuYy5saXN0
ZW4pOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodm5jZGlzcGxheSAlZClc
biIsIGRfY29uZmlnLT52ZmJzW2ldLnZuYy5kaXNwbGF5KTsNCi0gICAgICAg
IHByaW50ZigiXHRcdFx0KHZuY3VudXNlZCAlcylcbiIsDQorICAgICAgICBm
cHJpbnRmKGZoLCAiXHRcdFx0KHZuY2xpc3RlbiAlcylcbiIsIGRfY29uZmln
LT52ZmJzW2ldLnZuYy5saXN0ZW4pOw0KKyAgICAgICAgZnByaW50ZihmaCwg
Ilx0XHRcdCh2bmNkaXNwbGF5ICVkKVxuIiwgZF9jb25maWctPnZmYnNbaV0u
dm5jLmRpc3BsYXkpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh2
bmN1bnVzZWQgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJv
b2xfdG9fc3RyaW5nKGRfY29uZmlnLT52ZmJzW2ldLnZuYy5maW5kdW51c2Vk
KSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChrZXltYXAgJXMpXG4iLCBk
X2NvbmZpZy0+dmZic1tpXS5rZXltYXApOw0KLSAgICAgICAgcHJpbnRmKCJc
dFx0XHQoc2RsICVzKVxuIiwNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0
XHQoa2V5bWFwICVzKVxuIiwgZF9jb25maWctPnZmYnNbaV0ua2V5bWFwKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoc2RsICVzKVxuIiwNCiAg
ICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhkX2NvbmZp
Zy0+dmZic1tpXS5zZGwuZW5hYmxlKSk7DQotICAgICAgICBwcmludGYoIlx0
XHRcdChvcGVuZ2wgJXMpXG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0
XHRcdChvcGVuZ2wgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2Rl
ZmJvb2xfdG9fc3RyaW5nKGRfY29uZmlnLT52ZmJzW2ldLnNkbC5vcGVuZ2wp
KTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGRpc3BsYXkgJXMpXG4iLCBk
X2NvbmZpZy0+dmZic1tpXS5zZGwuZGlzcGxheSk7DQotICAgICAgICBwcmlu
dGYoIlx0XHRcdCh4YXV0aG9yaXR5ICVzKVxuIiwgZF9jb25maWctPnZmYnNb
aV0uc2RsLnhhdXRob3JpdHkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0KVxu
Iik7DQotICAgICAgICBwcmludGYoIlx0KVxuIik7DQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHRcdFx0KGRpc3BsYXkgJXMpXG4iLCBkX2NvbmZpZy0+dmZi
c1tpXS5zZGwuZGlzcGxheSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRc
dFx0KHhhdXRob3JpdHkgJXMpXG4iLCBkX2NvbmZpZy0+dmZic1tpXS5zZGwu
eGF1dGhvcml0eSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdClcbiIp
Ow0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0KVxuIik7DQogICAgIH0NCi0g
ICAgcHJpbnRmKCIpXG4iKTsNCisgICAgZnByaW50ZihmaCwgIilcbiIpOw0K
IH0NCiANCiANCi0tLSB4ZW4tNC41LjAtcmMxL3Rvb2xzL2xpYnhsL3hsLmgu
b3JpZwkyMDE0LTEwLTI0IDE1OjIyOjQwLjAwMDAwMDAwMCArMDEwMA0KKysr
IHhlbi00LjUuMC1yYzEvdG9vbHMvbGlieGwveGwuaAkyMDE0LTExLTI1IDIw
OjU2OjIwLjU5MjI3MjkzOSArMDAwMA0KQEAgLTE4Niw3ICsxODYsNyBAQA0K
IH07DQogZXh0ZXJuIGVudW0gb3V0cHV0X2Zvcm1hdCBkZWZhdWx0X291dHB1
dF9mb3JtYXQ7DQogDQotZXh0ZXJuIHZvaWQgcHJpbnRmX2luZm9fc2V4cChp
bnQgZG9taWQsIGxpYnhsX2RvbWFpbl9jb25maWcgKmRfY29uZmlnKTsNCitl
eHRlcm4gdm9pZCBwcmludGZfaW5mb19zZXhwKGludCBkb21pZCwgbGlieGxf
ZG9tYWluX2NvbmZpZyAqZF9jb25maWcsIEZJTEUgKmZoKTsNCiANCiAjZGVm
aW5lIFhMX0dMT0JBTF9DT05GSUcgWEVOX0NPTkZJR19ESVIgIi94bC5jb25m
Ig0KICNkZWZpbmUgWExfTE9DS19GSUxFIFhFTl9MT0NLX0RJUiAiL3hsIg0K

--8323329-2010612164-1417035119=:18257
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-2010612164-1417035119=:18257--


From xen-devel-bounces@lists.xen.org Wed Nov 26 21:10:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 21: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 1XtjqS-0001v2-Mf; Wed, 26 Nov 2014 21:09: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 1XtjqR-0001uw-8Z
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 21:09:51 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	2E/61-27584-E9146745; Wed, 26 Nov 2014 21:09:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417036188!10161793!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17519 invoked from network); 26 Nov 2014 21:09:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Nov 2014 21:09:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQL9i9l032443
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 21:09:45 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQL9gWd020849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Nov 2014 21:09:43 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAQL9flO028136; Wed, 26 Nov 2014 21:09:42 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 13:09:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5675D11A067; Wed, 26 Nov 2014 16:09:40 -0500 (EST)
Date: Wed, 26 Nov 2014 16:09:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dave Scott <Dave.Scott@citrix.com>
Message-ID: <20141126210940.GA15328@laptop.dumpdata.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
	<370F66B9-E96D-4BE2-9E08-132CCBD28E42@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <370F66B9-E96D-4BE2-9E08-132CCBD28E42@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Zheng Li <dev@zheng.li>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCBOb3YgMjYsIDIwMTQgYXQgMDg6NDQ6NDFQTSArMDAwMCwgRGF2ZSBTY290dCB3cm90
ZToKPiAKPiA+IE9uIDI2IE5vdiAyMDE0LCBhdCAxODo0MSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxr
IDxrb25yYWQud2lsa0BvcmFjbGUuY29tPiB3cm90ZToKPiA+IAo+ID4gT24gV2VkLCBOb3YgMjYs
IDIwMTQgYXQgMDY6MjQ6MTFQTSArMDAwMCwgRGF2ZSBTY290dCB3cm90ZToKPiA+PiAKPiA+Pj4g
T24gMjYgTm92IDIwMTQsIGF0IDE1OjM4LCBaaGVuZyBMaSA8ZGV2QHpoZW5nLmxpPiB3cm90ZToK
PiA+Pj4gCj4gPj4+IE9uIDI2LzExLzIwMTQgMTU6MDksIEFuZHJldyBDb29wZXIgd3JvdGU6Cj4g
Pj4+PiBUaGlzIG1ha2VzIGZpZWxkcyAwIGFuZCAxIHRydWUgbW9yZSBvZnRlbiB0aGFuIHRoZXkg
c2hvdWxkIGJlLCByZXN1bHRpbmcKPiA+Pj4+IHByb2JsZW1zIHdoZW4gaGFuZGxpbmcgZXZlbnRz
Lgo+ID4+PiAKPiA+Pj4gSW5kZWVkLCBsb29rcyBsaWtlIGEgbWlzdGFrZSBJIG1hZGUgd2hlbiBy
ZXdyaXRpbmcgdGhlIGxvZ2ljIHRlcm1zIGxhdGVseS4gVGhlIHJlc3VsdCBpcyBQT0xMVVAgb3Ig
UE9MTEVSUiBldmVudHMgYmVpbmcgcmV0dXJuZWQgaW4gbW9yZSBjYXRlZ29yaWVzIHRoYW4gd2Un
ZCBpbnRlcmVzdC4gVGhhbmtzIGZvciBmaXhpbmcgdGhpcyEKPiA+Pj4gCj4gPj4+IEFja2VkLWJ5
OiBaaGVuZyBMaSA8ZGV2QHpoZW5nLmxpPgo+ID4+IAo+ID4+IFRoaXMgYWxzbyBsb29rcyBmaW5l
IHRvIG1lCj4gPj4gCj4gPj4gQWNrZWQtYnk6IERhdmlkIFNjb3R0IDxkYXZlLnNjb3R0QGNpdHJp
eC5jb20+Cj4gPiAKPiA+IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGdldCBhbiBSZXZpZXdlZC1i
eSBwbGVhc2U/Cj4gCj4gSeKAmWxsIGNlcnRhaW5seSBvZmZlcgo+IAo+IFJldmlld2VkLWJ5OiBE
YXZpZCBTY290dCA8ZGF2ZS5zY290dEBjaXRyaXguY29tPgoKT0ssIFJlbGVhc2UtQWNrZWQtYnk6
IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KClRoYW5rIHlv
dS4KPiAKPiBDaGVlcnMsCj4gRGF2ZQo+IAo+ID4gCj4gPiBUaGFuayB5b3UuCj4gPj4gCj4gPj4g
Q2hlZXJzLAo+ID4+IERhdmUKPiA+PiAKPiA+Pj4gCj4gPj4+IAo+ID4+PiBDaGVlcnMsCj4gPj4+
IFpoZW5nCj4gPj4+IAo+ID4+PiAKPiA+Pj4+IC0tLQo+ID4+Pj4gCj4gPj4+PiBUaGlzIHdhcyBk
aXNjb3ZlcmVkIHdpdGggWGVuU2VydmVycyBpbnRlcm5hbCBDb3Zlcml0eSBpbnN0YW5jZS4gIEkg
aGF2ZSB5ZXQgdG8KPiA+Pj4+IHdvcmsgb3V0IHdoeSB0aGUgaXNzdWUgaXMgbm90IGlkZW50aWZp
ZWQgYnkgdGhlIHVwc3RyZWFtIGNvdmVyaXR5IHNjYW5uaW5nLgo+ID4+Pj4gCj4gPj4+PiBLb25y
YWQ6IFRoaXMgaXMgYSBidWcgaW4gdGhlIGRlZmF1bHQgZXZlbnQgaGFuZGxpbmcgdXNlZCBieSBv
eGVuc3RvcmVkIGluIDQuNSwKPiA+Pj4+IGFzIHRoZSBkZWZhdWx0IHN3aXRjaGVkIGZyb20gc2Vs
ZWN0KCkgdG8gcG9sbCgpIGluIHRoZSA0LjUgdGltZWZyYW1lLiAgSXQKPiA+Pj4+IHdvdWxkIGFw
cGVhciB0aGF0IHRoZSBuZWdhdGl2ZSBzaWRlIGVmZmVjdHMgYXJlIGxpbWl0ZWQgdG8ganVzdCBs
b2dzcGFtIGFib3V0Cj4gPj4+PiBjZXJ0YWluIGNsaWVudHMgYXR0ZW1wdGluZyBpbnZhbGlkIGFj
dGlvbnMsIGJ1dCBJIGNhbid0IHJ1bGUgb3V0IGFueXRoaW5nIG1vcmUKPiA+Pj4+IHByb2JsZW1h
dGljLgo+ID4+Pj4gLS0tCj4gPj4+PiB0b29scy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJz
LmMgfCAgICA0ICsrLS0KPiA+Pj4+IDEgZmlsZSBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDIg
ZGVsZXRpb25zKC0pCj4gPj4+PiAKPiA+Pj4+IGRpZmYgLS1naXQgYS90b29scy9vY2FtbC94ZW5z
dG9yZWQvc2VsZWN0X3N0dWJzLmMgYi90b29scy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJz
LmMKPiA+Pj4+IGluZGV4IDRhOGVkYjUuLmFmNzJiODQgMTAwNjQ0Cj4gPj4+PiAtLS0gYS90b29s
cy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJzLmMKPiA+Pj4+ICsrKyBiL3Rvb2xzL29jYW1s
L3hlbnN0b3JlZC9zZWxlY3Rfc3R1YnMuYwo+ID4+Pj4gQEAgLTU2LDggKzU2LDggQEAgQ0FNTHBy
aW0gdmFsdWUgc3R1Yl9zZWxlY3Rfb25fcG9sbCh2YWx1ZSBmZF9ldmVudHMsIHZhbHVlIHRpbWVv
KSB7Cj4gPj4+PiAJCQlldmVudHMgPSBGaWVsZChGaWVsZChmZF9ldmVudHMsIGkpLCAxKTsKPiA+
Pj4+IAo+ID4+Pj4gCQkJaWYgKGNfZmRzW2ldLnJldmVudHMgJiBQT0xMTlZBTCkgdW5peF9lcnJv
cihFQkFERiwgInNlbGVjdCIsIE5vdGhpbmcpOwo+ID4+Pj4gLQkJCUZpZWxkKGV2ZW50cywgMCkg
PSBWYWxfYm9vbChjX2Zkc1tpXS5ldmVudHMgfCBQT0xMSU4gICYmIGNfZmRzW2ldLnJldmVudHMg
JiAoUE9MTElOIHxQT0xMSFVQfFBPTExFUlIpKTsKPiA+Pj4+IC0JCQlGaWVsZChldmVudHMsIDEp
ID0gVmFsX2Jvb2woY19mZHNbaV0uZXZlbnRzIHwgUE9MTE9VVCAmJiBjX2Zkc1tpXS5yZXZlbnRz
ICYgKFBPTExPVVR8UE9MTEhVUHxQT0xMRVJSKSk7Cj4gPj4+PiArCQkJRmllbGQoZXZlbnRzLCAw
KSA9IFZhbF9ib29sKGNfZmRzW2ldLmV2ZW50cyAmIFBPTExJTiAgJiYgY19mZHNbaV0ucmV2ZW50
cyAmIChQT0xMSU4gfFBPTExIVVB8UE9MTEVSUikpOwo+ID4+Pj4gKwkJCUZpZWxkKGV2ZW50cywg
MSkgPSBWYWxfYm9vbChjX2Zkc1tpXS5ldmVudHMgJiBQT0xMT1VUICYmIGNfZmRzW2ldLnJldmVu
dHMgJiAoUE9MTE9VVHxQT0xMSFVQfFBPTExFUlIpKTsKPiA+Pj4+IAkJCUZpZWxkKGV2ZW50cywg
MikgPSBWYWxfYm9vbChjX2Zkc1tpXS5yZXZlbnRzICYgUE9MTFBSSSk7Cj4gPj4+PiAKPiA+Pj4+
IAkJfQo+ID4+Pj4gCj4gPj4gCj4gPiAKPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fCj4gPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gPiBYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwo+ID4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCj4gCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Nov 26 21:10:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 21: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 1XtjqS-0001v2-Mf; Wed, 26 Nov 2014 21:09: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 1XtjqR-0001uw-8Z
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 21:09:51 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	2E/61-27584-E9146745; Wed, 26 Nov 2014 21:09:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417036188!10161793!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17519 invoked from network); 26 Nov 2014 21:09:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Nov 2014 21:09:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAQL9i9l032443
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Nov 2014 21:09:45 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAQL9gWd020849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Nov 2014 21:09:43 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sAQL9flO028136; Wed, 26 Nov 2014 21:09:42 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 13:09:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5675D11A067; Wed, 26 Nov 2014 16:09:40 -0500 (EST)
Date: Wed, 26 Nov 2014 16:09:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dave Scott <Dave.Scott@citrix.com>
Message-ID: <20141126210940.GA15328@laptop.dumpdata.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
	<370F66B9-E96D-4BE2-9E08-132CCBD28E42@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <370F66B9-E96D-4BE2-9E08-132CCBD28E42@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Zheng Li <dev@zheng.li>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCBOb3YgMjYsIDIwMTQgYXQgMDg6NDQ6NDFQTSArMDAwMCwgRGF2ZSBTY290dCB3cm90
ZToKPiAKPiA+IE9uIDI2IE5vdiAyMDE0LCBhdCAxODo0MSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxr
IDxrb25yYWQud2lsa0BvcmFjbGUuY29tPiB3cm90ZToKPiA+IAo+ID4gT24gV2VkLCBOb3YgMjYs
IDIwMTQgYXQgMDY6MjQ6MTFQTSArMDAwMCwgRGF2ZSBTY290dCB3cm90ZToKPiA+PiAKPiA+Pj4g
T24gMjYgTm92IDIwMTQsIGF0IDE1OjM4LCBaaGVuZyBMaSA8ZGV2QHpoZW5nLmxpPiB3cm90ZToK
PiA+Pj4gCj4gPj4+IE9uIDI2LzExLzIwMTQgMTU6MDksIEFuZHJldyBDb29wZXIgd3JvdGU6Cj4g
Pj4+PiBUaGlzIG1ha2VzIGZpZWxkcyAwIGFuZCAxIHRydWUgbW9yZSBvZnRlbiB0aGFuIHRoZXkg
c2hvdWxkIGJlLCByZXN1bHRpbmcKPiA+Pj4+IHByb2JsZW1zIHdoZW4gaGFuZGxpbmcgZXZlbnRz
Lgo+ID4+PiAKPiA+Pj4gSW5kZWVkLCBsb29rcyBsaWtlIGEgbWlzdGFrZSBJIG1hZGUgd2hlbiBy
ZXdyaXRpbmcgdGhlIGxvZ2ljIHRlcm1zIGxhdGVseS4gVGhlIHJlc3VsdCBpcyBQT0xMVVAgb3Ig
UE9MTEVSUiBldmVudHMgYmVpbmcgcmV0dXJuZWQgaW4gbW9yZSBjYXRlZ29yaWVzIHRoYW4gd2Un
ZCBpbnRlcmVzdC4gVGhhbmtzIGZvciBmaXhpbmcgdGhpcyEKPiA+Pj4gCj4gPj4+IEFja2VkLWJ5
OiBaaGVuZyBMaSA8ZGV2QHpoZW5nLmxpPgo+ID4+IAo+ID4+IFRoaXMgYWxzbyBsb29rcyBmaW5l
IHRvIG1lCj4gPj4gCj4gPj4gQWNrZWQtYnk6IERhdmlkIFNjb3R0IDxkYXZlLnNjb3R0QGNpdHJp
eC5jb20+Cj4gPiAKPiA+IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGdldCBhbiBSZXZpZXdlZC1i
eSBwbGVhc2U/Cj4gCj4gSeKAmWxsIGNlcnRhaW5seSBvZmZlcgo+IAo+IFJldmlld2VkLWJ5OiBE
YXZpZCBTY290dCA8ZGF2ZS5zY290dEBjaXRyaXguY29tPgoKT0ssIFJlbGVhc2UtQWNrZWQtYnk6
IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KClRoYW5rIHlv
dS4KPiAKPiBDaGVlcnMsCj4gRGF2ZQo+IAo+ID4gCj4gPiBUaGFuayB5b3UuCj4gPj4gCj4gPj4g
Q2hlZXJzLAo+ID4+IERhdmUKPiA+PiAKPiA+Pj4gCj4gPj4+IAo+ID4+PiBDaGVlcnMsCj4gPj4+
IFpoZW5nCj4gPj4+IAo+ID4+PiAKPiA+Pj4+IC0tLQo+ID4+Pj4gCj4gPj4+PiBUaGlzIHdhcyBk
aXNjb3ZlcmVkIHdpdGggWGVuU2VydmVycyBpbnRlcm5hbCBDb3Zlcml0eSBpbnN0YW5jZS4gIEkg
aGF2ZSB5ZXQgdG8KPiA+Pj4+IHdvcmsgb3V0IHdoeSB0aGUgaXNzdWUgaXMgbm90IGlkZW50aWZp
ZWQgYnkgdGhlIHVwc3RyZWFtIGNvdmVyaXR5IHNjYW5uaW5nLgo+ID4+Pj4gCj4gPj4+PiBLb25y
YWQ6IFRoaXMgaXMgYSBidWcgaW4gdGhlIGRlZmF1bHQgZXZlbnQgaGFuZGxpbmcgdXNlZCBieSBv
eGVuc3RvcmVkIGluIDQuNSwKPiA+Pj4+IGFzIHRoZSBkZWZhdWx0IHN3aXRjaGVkIGZyb20gc2Vs
ZWN0KCkgdG8gcG9sbCgpIGluIHRoZSA0LjUgdGltZWZyYW1lLiAgSXQKPiA+Pj4+IHdvdWxkIGFw
cGVhciB0aGF0IHRoZSBuZWdhdGl2ZSBzaWRlIGVmZmVjdHMgYXJlIGxpbWl0ZWQgdG8ganVzdCBs
b2dzcGFtIGFib3V0Cj4gPj4+PiBjZXJ0YWluIGNsaWVudHMgYXR0ZW1wdGluZyBpbnZhbGlkIGFj
dGlvbnMsIGJ1dCBJIGNhbid0IHJ1bGUgb3V0IGFueXRoaW5nIG1vcmUKPiA+Pj4+IHByb2JsZW1h
dGljLgo+ID4+Pj4gLS0tCj4gPj4+PiB0b29scy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJz
LmMgfCAgICA0ICsrLS0KPiA+Pj4+IDEgZmlsZSBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDIg
ZGVsZXRpb25zKC0pCj4gPj4+PiAKPiA+Pj4+IGRpZmYgLS1naXQgYS90b29scy9vY2FtbC94ZW5z
dG9yZWQvc2VsZWN0X3N0dWJzLmMgYi90b29scy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJz
LmMKPiA+Pj4+IGluZGV4IDRhOGVkYjUuLmFmNzJiODQgMTAwNjQ0Cj4gPj4+PiAtLS0gYS90b29s
cy9vY2FtbC94ZW5zdG9yZWQvc2VsZWN0X3N0dWJzLmMKPiA+Pj4+ICsrKyBiL3Rvb2xzL29jYW1s
L3hlbnN0b3JlZC9zZWxlY3Rfc3R1YnMuYwo+ID4+Pj4gQEAgLTU2LDggKzU2LDggQEAgQ0FNTHBy
aW0gdmFsdWUgc3R1Yl9zZWxlY3Rfb25fcG9sbCh2YWx1ZSBmZF9ldmVudHMsIHZhbHVlIHRpbWVv
KSB7Cj4gPj4+PiAJCQlldmVudHMgPSBGaWVsZChGaWVsZChmZF9ldmVudHMsIGkpLCAxKTsKPiA+
Pj4+IAo+ID4+Pj4gCQkJaWYgKGNfZmRzW2ldLnJldmVudHMgJiBQT0xMTlZBTCkgdW5peF9lcnJv
cihFQkFERiwgInNlbGVjdCIsIE5vdGhpbmcpOwo+ID4+Pj4gLQkJCUZpZWxkKGV2ZW50cywgMCkg
PSBWYWxfYm9vbChjX2Zkc1tpXS5ldmVudHMgfCBQT0xMSU4gICYmIGNfZmRzW2ldLnJldmVudHMg
JiAoUE9MTElOIHxQT0xMSFVQfFBPTExFUlIpKTsKPiA+Pj4+IC0JCQlGaWVsZChldmVudHMsIDEp
ID0gVmFsX2Jvb2woY19mZHNbaV0uZXZlbnRzIHwgUE9MTE9VVCAmJiBjX2Zkc1tpXS5yZXZlbnRz
ICYgKFBPTExPVVR8UE9MTEhVUHxQT0xMRVJSKSk7Cj4gPj4+PiArCQkJRmllbGQoZXZlbnRzLCAw
KSA9IFZhbF9ib29sKGNfZmRzW2ldLmV2ZW50cyAmIFBPTExJTiAgJiYgY19mZHNbaV0ucmV2ZW50
cyAmIChQT0xMSU4gfFBPTExIVVB8UE9MTEVSUikpOwo+ID4+Pj4gKwkJCUZpZWxkKGV2ZW50cywg
MSkgPSBWYWxfYm9vbChjX2Zkc1tpXS5ldmVudHMgJiBQT0xMT1VUICYmIGNfZmRzW2ldLnJldmVu
dHMgJiAoUE9MTE9VVHxQT0xMSFVQfFBPTExFUlIpKTsKPiA+Pj4+IAkJCUZpZWxkKGV2ZW50cywg
MikgPSBWYWxfYm9vbChjX2Zkc1tpXS5yZXZlbnRzICYgUE9MTFBSSSk7Cj4gPj4+PiAKPiA+Pj4+
IAkJfQo+ID4+Pj4gCj4gPj4gCj4gPiAKPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fCj4gPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gPiBYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwo+ID4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCj4gCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Nov 26 21:18:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 21:18:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtjyK-0002Ec-LA; Wed, 26 Nov 2014 21:18:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XtjyJ-0002EX-42
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 21:17:59 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	BC/24-14214-68346745; Wed, 26 Nov 2014 21:17:58 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417036677!5932901!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18148 invoked from network); 26 Nov 2014 21:17:57 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 21:17:57 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-31-211-68.oxfd.adsl.virginm.net ([86.31.211.68]:56742
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XtjyG-0005Sx-FX (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Wed, 26 Nov 2014 21:17:57 +0000
Message-ID: <54764384.5010008@citrix.com>
Date: Wed, 26 Nov 2014 21:17:56 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>, xen-devel@lists.xen.org
References: <alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] fix migration failure with xl migrate
	--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="===============3959838990604110159=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============3959838990604110159==
Content-Type: multipart/alternative;
 boundary="------------090107030203060309010900"

This is a multi-part message in MIME format.
--------------090107030203060309010900
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 26/11/2014 20:51, M A Young wrote:
> Migrations with xl migrate --debug will fail because debugging
> information from the receiving process is written to the stdout
> channel. This channel is also used for status messages so the
> migration will fail as the sending process receives an unexpected
> message. This patch moves the debugging information to the stderr
> channel.
>
> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>

Ah yes - that will do.

The whole info/error/debug handling here is a mess.  Amongst other
issues, it is not possible to distinguish whether libxc logging messages
are coming from the sending or receiving side, without judging the
context from the text itself.

>
> Use stderr for debugging messages for xl migrate --debug as stdout is used
> for status messages.
>
> --- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig	2014-10-24 15:22:40.000000000 +0100
> +++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c	2014-11-25 20:29:06.723856433 +0000
> @@ -383,7 +383,7 @@

Sadly, changing printf_info() like this has an unintended knock-on
effect to create_domain() (xl create, migrate-recevive, restore) and xl
config-update.  I think you might have to pass FILE pointers all the way
through.

>                          libxl_domain_config *d_config)
>  {
>      if (output_format == OUTPUT_FORMAT_SXP)
> -        return printf_info_sexp(domid, d_config);
> +        return printf_info_sexp(domid, d_config, stderr);
>  
>      const char *buf;
>      libxl_yajl_length len = 0;
> @@ -404,7 +404,7 @@
>      if (s != yajl_gen_status_ok)
>          goto out;
>  
> -    puts(buf);
> +    fputs(buf,stderr);

puts() and fputs() are not quite synonymous.  puts() will
unconditionally add an extra newline to stdout.  It is unclear whether
the string from yajl_gen_get_buf() comes with a trailing newline or
not.  If the output looks ok, it probably is fine.

~Andrew

--------------090107030203060309010900
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 26/11/2014 20:51, M A Young wrote:<br>
    </div>
    <blockquote
      cite="mid:alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk"
      type="cite">
      <div class="moz-text-flowed" style="font-family: -moz-fixed;
        font-size: 14px;" lang="x-western">Migrations with xl migrate
        --debug will fail because debugging information from the
        receiving process is written to the stdout channel. This channel
        is also used for status messages so the migration will fail as
        the sending process receives an unexpected message. This patch
        moves the debugging information to the stderr channel.
        <br>
        <br>
        Signed-off-by: Michael Young <a moz-do-not-send="true"
          class="moz-txt-link-rfc2396E"
          href="mailto:m.a.young@durham.ac.uk">&lt;m.a.young@durham.ac.uk&gt;</a><br>
      </div>
    </blockquote>
    <br>
    Ah yes - that will do.<br>
    <br>
    The whole info/error/debug handling here is a mess.&nbsp; Amongst other
    issues, it is not possible to distinguish whether libxc logging
    messages are coming from the sending or receiving side, without
    judging the context from the text itself.<br>
    <br>
    <blockquote
      cite="mid:alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk"
      type="cite"><br>
      <pre wrap="">Use stderr for debugging messages for xl migrate --debug as stdout is used
for status messages.

--- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig	2014-10-24 15:22:40.000000000 +0100
+++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c	2014-11-25 20:29:06.723856433 +0000
@@ -383,7 +383,7 @@</pre>
    </blockquote>
    <br>
    Sadly, changing printf_info() like this has an unintended knock-on
    effect to create_domain() (xl create, migrate-recevive, restore) and
    xl config-update.&nbsp; I think you might have to pass FILE pointers all
    the way through.<br>
    <br>
    <blockquote
      cite="mid:alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk"
      type="cite">
      <pre wrap="">
                         libxl_domain_config *d_config)
 {
     if (output_format == OUTPUT_FORMAT_SXP)
-        return printf_info_sexp(domid, d_config);
+        return printf_info_sexp(domid, d_config, stderr);
 
     const char *buf;
     libxl_yajl_length len = 0;
@@ -404,7 +404,7 @@
     if (s != yajl_gen_status_ok)
         goto out;
 
-    puts(buf);
+    fputs(buf,stderr);</pre>
    </blockquote>
    <br>
    puts() and fputs() are not quite synonymous.&nbsp; puts() will
    unconditionally add an extra newline to stdout.&nbsp; It is unclear
    whether the string from yajl_gen_get_buf() comes with a trailing
    newline or not.&nbsp; If the output looks ok, it probably is fine.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------090107030203060309010900--


--===============3959838990604110159==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3959838990604110159==--


From xen-devel-bounces@lists.xen.org Wed Nov 26 21:18:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 21:18:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtjyK-0002Ec-LA; Wed, 26 Nov 2014 21:18:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XtjyJ-0002EX-42
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 21:17:59 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	BC/24-14214-68346745; Wed, 26 Nov 2014 21:17:58 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417036677!5932901!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18148 invoked from network); 26 Nov 2014 21:17:57 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 21:17:57 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-31-211-68.oxfd.adsl.virginm.net ([86.31.211.68]:56742
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XtjyG-0005Sx-FX (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Wed, 26 Nov 2014 21:17:57 +0000
Message-ID: <54764384.5010008@citrix.com>
Date: Wed, 26 Nov 2014 21:17:56 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>, xen-devel@lists.xen.org
References: <alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] fix migration failure with xl migrate
	--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="===============3959838990604110159=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============3959838990604110159==
Content-Type: multipart/alternative;
 boundary="------------090107030203060309010900"

This is a multi-part message in MIME format.
--------------090107030203060309010900
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 26/11/2014 20:51, M A Young wrote:
> Migrations with xl migrate --debug will fail because debugging
> information from the receiving process is written to the stdout
> channel. This channel is also used for status messages so the
> migration will fail as the sending process receives an unexpected
> message. This patch moves the debugging information to the stderr
> channel.
>
> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>

Ah yes - that will do.

The whole info/error/debug handling here is a mess.  Amongst other
issues, it is not possible to distinguish whether libxc logging messages
are coming from the sending or receiving side, without judging the
context from the text itself.

>
> Use stderr for debugging messages for xl migrate --debug as stdout is used
> for status messages.
>
> --- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig	2014-10-24 15:22:40.000000000 +0100
> +++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c	2014-11-25 20:29:06.723856433 +0000
> @@ -383,7 +383,7 @@

Sadly, changing printf_info() like this has an unintended knock-on
effect to create_domain() (xl create, migrate-recevive, restore) and xl
config-update.  I think you might have to pass FILE pointers all the way
through.

>                          libxl_domain_config *d_config)
>  {
>      if (output_format == OUTPUT_FORMAT_SXP)
> -        return printf_info_sexp(domid, d_config);
> +        return printf_info_sexp(domid, d_config, stderr);
>  
>      const char *buf;
>      libxl_yajl_length len = 0;
> @@ -404,7 +404,7 @@
>      if (s != yajl_gen_status_ok)
>          goto out;
>  
> -    puts(buf);
> +    fputs(buf,stderr);

puts() and fputs() are not quite synonymous.  puts() will
unconditionally add an extra newline to stdout.  It is unclear whether
the string from yajl_gen_get_buf() comes with a trailing newline or
not.  If the output looks ok, it probably is fine.

~Andrew

--------------090107030203060309010900
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 26/11/2014 20:51, M A Young wrote:<br>
    </div>
    <blockquote
      cite="mid:alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk"
      type="cite">
      <div class="moz-text-flowed" style="font-family: -moz-fixed;
        font-size: 14px;" lang="x-western">Migrations with xl migrate
        --debug will fail because debugging information from the
        receiving process is written to the stdout channel. This channel
        is also used for status messages so the migration will fail as
        the sending process receives an unexpected message. This patch
        moves the debugging information to the stderr channel.
        <br>
        <br>
        Signed-off-by: Michael Young <a moz-do-not-send="true"
          class="moz-txt-link-rfc2396E"
          href="mailto:m.a.young@durham.ac.uk">&lt;m.a.young@durham.ac.uk&gt;</a><br>
      </div>
    </blockquote>
    <br>
    Ah yes - that will do.<br>
    <br>
    The whole info/error/debug handling here is a mess.&nbsp; Amongst other
    issues, it is not possible to distinguish whether libxc logging
    messages are coming from the sending or receiving side, without
    judging the context from the text itself.<br>
    <br>
    <blockquote
      cite="mid:alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk"
      type="cite"><br>
      <pre wrap="">Use stderr for debugging messages for xl migrate --debug as stdout is used
for status messages.

--- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig	2014-10-24 15:22:40.000000000 +0100
+++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c	2014-11-25 20:29:06.723856433 +0000
@@ -383,7 +383,7 @@</pre>
    </blockquote>
    <br>
    Sadly, changing printf_info() like this has an unintended knock-on
    effect to create_domain() (xl create, migrate-recevive, restore) and
    xl config-update.&nbsp; I think you might have to pass FILE pointers all
    the way through.<br>
    <br>
    <blockquote
      cite="mid:alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk"
      type="cite">
      <pre wrap="">
                         libxl_domain_config *d_config)
 {
     if (output_format == OUTPUT_FORMAT_SXP)
-        return printf_info_sexp(domid, d_config);
+        return printf_info_sexp(domid, d_config, stderr);
 
     const char *buf;
     libxl_yajl_length len = 0;
@@ -404,7 +404,7 @@
     if (s != yajl_gen_status_ok)
         goto out;
 
-    puts(buf);
+    fputs(buf,stderr);</pre>
    </blockquote>
    <br>
    puts() and fputs() are not quite synonymous.&nbsp; puts() will
    unconditionally add an extra newline to stdout.&nbsp; It is unclear
    whether the string from yajl_gen_get_buf() comes with a trailing
    newline or not.&nbsp; If the output looks ok, it probably is fine.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------090107030203060309010900--


--===============3959838990604110159==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3959838990604110159==--


From xen-devel-bounces@lists.xen.org Wed Nov 26 21:19:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 21: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 1XtjzP-0002In-3M; Wed, 26 Nov 2014 21:19:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XtjzO-0002If-0A
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 21:19:06 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	57/1F-02576-9C346745; Wed, 26 Nov 2014 21:19:05 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417036744!15103281!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2018 invoked from network); 26 Nov 2014 21:19:04 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 21:19:04 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-31-211-68.oxfd.adsl.virginm.net ([86.31.211.68]:56774
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XtjzM-0006fE-EF (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Wed, 26 Nov 2014 21:19:04 +0000
Message-ID: <547643C8.5000806@citrix.com>
Date: Wed, 26 Nov 2014 21:19:04 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>, xen-devel@lists.xen.org
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] fix segfault in xl migrate --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="===============6197980008294630126=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6197980008294630126==
Content-Type: multipart/alternative;
 boundary="------------020307050008070504090507"

This is a multi-part message in MIME format.
--------------020307050008070504090507
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26/11/2014 19:54, M A Young wrote:
> If differences are found during the verification phase of xl migrate
> --debug then it is likely to crash with a segfault because the bogus
> pagebuf->pfn_types[pfn] is used in a print statement instead of
> pfn_type[pfn] .
>
> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
>
>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> xl migrate --debug can segfault because pagebuf->pfn_types[pfn] is
> used in a print statement instead of pfn_type[pfn] 
>
> --- xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c.orig	2014-10-24 15:22:40.000000000 +0100
> +++ xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c	2014-11-25 21:01:16.604081467 +0000
> @@ -1404,7 +1404,7 @@
>                  int v;
>  
>                  DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
> -                        "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
> +                        "actualcs=%08lx\n", pfn, pfn_type[pfn],
>                          csum_page(region_base + i * PAGE_SIZE),
>                          csum_page(buf));
>  


--------------020307050008070504090507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 26/11/2014 19:54, M A Young wrote:<br>
    </div>
    <blockquote
      cite="mid:alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk"
      type="cite">
      <div class="moz-text-flowed" style="font-family: -moz-fixed;
        font-size: 14px;" lang="x-western">If differences are found
        during the verification phase of xl migrate --debug then it is
        likely to crash with a segfault because the bogus
        <br>
        pagebuf-&gt;pfn_types[pfn] is used in a print statement instead
        of pfn_type[pfn] .
        <br>
        <br>
        Signed-off-by: Michael Young <a moz-do-not-send="true"
          class="moz-txt-link-rfc2396E"
          href="mailto:m.a.young@durham.ac.uk">&lt;m.a.young@durham.ac.uk&gt;</a><br>
      </div>
      <br>
      <br>
    </blockquote>
    <br>
    Reviewed-by: Andrew Cooper <a class="moz-txt-link-rfc2396E" href="mailto:andrew.cooper3@citrix.com">&lt;andrew.cooper3@citrix.com&gt;</a><br>
    <br>
    <blockquote
      cite="mid:alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk"
      type="cite">
      <div class="moz-text-plain" wrap="true" graphical-quote="true"
        style="font-family: -moz-fixed; font-size: 14px;"
        lang="x-western">
        <pre wrap="">xl migrate --debug can segfault because pagebuf-&gt;pfn_types[pfn] is
used in a print statement instead of pfn_type[pfn] 

--- xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c.orig	2014-10-24 15:22:40.000000000 +0100
+++ xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c	2014-11-25 21:01:16.604081467 +0000
@@ -1404,7 +1404,7 @@
                 int v;
 
                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
-                        "actualcs=%08lx\n", pfn, pagebuf-&gt;pfn_types[pfn],
+                        "actualcs=%08lx\n", pfn, pfn_type[pfn],
                         csum_page(region_base + i * PAGE_SIZE),
                         csum_page(buf));
 
</pre>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------020307050008070504090507--


--===============6197980008294630126==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6197980008294630126==--


From xen-devel-bounces@lists.xen.org Wed Nov 26 21:19:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 21: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 1XtjzP-0002In-3M; Wed, 26 Nov 2014 21:19:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XtjzO-0002If-0A
	for xen-devel@lists.xen.org; Wed, 26 Nov 2014 21:19:06 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	57/1F-02576-9C346745; Wed, 26 Nov 2014 21:19:05 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417036744!15103281!1
X-Originating-IP: [131.111.8.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2018 invoked from network); 26 Nov 2014 21:19:04 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2014 21:19:04 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-31-211-68.oxfd.adsl.virginm.net ([86.31.211.68]:56774
	helo=[192.168.1.193])
	by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1XtjzM-0006fE-EF (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Wed, 26 Nov 2014 21:19:04 +0000
Message-ID: <547643C8.5000806@citrix.com>
Date: Wed, 26 Nov 2014 21:19:04 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>, xen-devel@lists.xen.org
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] fix segfault in xl migrate --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="===============6197980008294630126=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6197980008294630126==
Content-Type: multipart/alternative;
 boundary="------------020307050008070504090507"

This is a multi-part message in MIME format.
--------------020307050008070504090507
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26/11/2014 19:54, M A Young wrote:
> If differences are found during the verification phase of xl migrate
> --debug then it is likely to crash with a segfault because the bogus
> pagebuf->pfn_types[pfn] is used in a print statement instead of
> pfn_type[pfn] .
>
> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
>
>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> xl migrate --debug can segfault because pagebuf->pfn_types[pfn] is
> used in a print statement instead of pfn_type[pfn] 
>
> --- xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c.orig	2014-10-24 15:22:40.000000000 +0100
> +++ xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c	2014-11-25 21:01:16.604081467 +0000
> @@ -1404,7 +1404,7 @@
>                  int v;
>  
>                  DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
> -                        "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
> +                        "actualcs=%08lx\n", pfn, pfn_type[pfn],
>                          csum_page(region_base + i * PAGE_SIZE),
>                          csum_page(buf));
>  


--------------020307050008070504090507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 26/11/2014 19:54, M A Young wrote:<br>
    </div>
    <blockquote
      cite="mid:alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk"
      type="cite">
      <div class="moz-text-flowed" style="font-family: -moz-fixed;
        font-size: 14px;" lang="x-western">If differences are found
        during the verification phase of xl migrate --debug then it is
        likely to crash with a segfault because the bogus
        <br>
        pagebuf-&gt;pfn_types[pfn] is used in a print statement instead
        of pfn_type[pfn] .
        <br>
        <br>
        Signed-off-by: Michael Young <a moz-do-not-send="true"
          class="moz-txt-link-rfc2396E"
          href="mailto:m.a.young@durham.ac.uk">&lt;m.a.young@durham.ac.uk&gt;</a><br>
      </div>
      <br>
      <br>
    </blockquote>
    <br>
    Reviewed-by: Andrew Cooper <a class="moz-txt-link-rfc2396E" href="mailto:andrew.cooper3@citrix.com">&lt;andrew.cooper3@citrix.com&gt;</a><br>
    <br>
    <blockquote
      cite="mid:alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk"
      type="cite">
      <div class="moz-text-plain" wrap="true" graphical-quote="true"
        style="font-family: -moz-fixed; font-size: 14px;"
        lang="x-western">
        <pre wrap="">xl migrate --debug can segfault because pagebuf-&gt;pfn_types[pfn] is
used in a print statement instead of pfn_type[pfn] 

--- xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c.orig	2014-10-24 15:22:40.000000000 +0100
+++ xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c	2014-11-25 21:01:16.604081467 +0000
@@ -1404,7 +1404,7 @@
                 int v;
 
                 DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
-                        "actualcs=%08lx\n", pfn, pagebuf-&gt;pfn_types[pfn],
+                        "actualcs=%08lx\n", pfn, pfn_type[pfn],
                         csum_page(region_base + i * PAGE_SIZE),
                         csum_page(buf));
 
</pre>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------020307050008070504090507--


--===============6197980008294630126==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6197980008294630126==--


From xen-devel-bounces@lists.xen.org Wed Nov 26 22:27:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 22:27:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtl3I-0003Uz-FL; Wed, 26 Nov 2014 22:27:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xtl3G-0003Uu-6V
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 22:27:10 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	3B/69-02697-DB356745; Wed, 26 Nov 2014 22:27:09 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417040825!13565962!1
X-Originating-IP: [209.85.220.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22778 invoked from network); 26 Nov 2014 22:27:06 -0000
Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com)
	(209.85.220.44)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 22:27:06 -0000
Received: by mail-pa0-f44.google.com with SMTP id et14so3688266pad.17
	for <xen-devel@lists.xenproject.org>;
	Wed, 26 Nov 2014 14:27:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:from:to:cc:subject:date:message-id;
	bh=4P6ugfyNgWXBQr9yoPaoj4+FGjDUpm9ElKCouqYiJCE=;
	b=a0PyO+tO9hK3TZe7gWcIycvG8/9VkP7AaLsnFEXMQ/21cWpi80yCmdAwyHAB184n8R
	YLvI0f25EyWm9uIf0KBBZeRjwMFi5fdiebPz9/AQKukRVQNM2qaj2adoAkWE/Jt8Qhi/
	0mxDOqh8vehsiy4WfL1beMB8vKaFxy1siNO57E4g+RMPYs7Wzn8hWeX7dWHhMIJv6K+0
	1GjoQFRppidwZjIT2/xSXjHeuIL4QhmqXT+mmCgf94AlVpiJxpCz9XmTWgEFTBypLY1r
	BE9qtz1zMxxWSQwvFdbkfL0ihdCneoODYEepwSer06HC/fyK9dlwOM2YM8WO8X03METo
	82FA==
X-Received: by 10.66.146.135 with SMTP id tc7mr58536878pab.155.1417040825167; 
	Wed, 26 Nov 2014 14:27:05 -0800 (PST)
Received: from mcgrof@gmail.com (c-98-234-145-61.hsd1.ca.comcast.net.
	[98.234.145.61]) by mx.google.com with ESMTPSA id
	cm10sm5263513pad.46.2014.11.26.14.27.01 for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 26 Nov 2014 14:27:03 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Wed, 26 Nov 2014 14:27:00 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org
Date: Wed, 26 Nov 2014 14:26:45 -0800
Message-Id: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
Cc: Juergen Gross <JGross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Jan Beulich <JBeulich@suse.com>,
	Borislav Petkov <bp@suse.de>, Olaf Hering <ohering@suse.de>
Subject: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
	hypercall when non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Some folks had reported that some xen hypercalls take a long time
to complete when issued from the userspace private ioctl mechanism,
this can happen for instance with some hypercalls that have many
sub-operations, this can happen for instance on hypercalls that use
multi-call feature whereby Xen lets one hypercall batch out a series
of other hypercalls on the hypervisor. At times such hypercalls can
even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
120 seconds), this a non-issue issue on preemptible kernels though as
the kernel may deschedule such long running tasks. Xen for instance
supports multicalls to be preempted as well, this is what Xen calls
continuation (see xen commit 42217cbc5b which introduced this [0]).
On systems without CONFIG_PREEMPT though -- a kernel with voluntary
or no preemption -- a long running hypercall will not be descheduled
until the hypercall is complete and the ioctl returns to user space.

To help with this David had originally implemented support for use
of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
solution never went upstream though and upon review to help refactor
this I've concluded that usage of preempt_schedule_irq() would be
a bit abussive of existing APIs -- for a few reasons:

0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels

1) we want try to consider solutions that might work for other
   hypervisors for this same problem, and identify it its an issue
   even present on other hypervisors or if this is a self
   inflicted architectural issue caused by use of multicalls

2) there is no documentation or profiling of the exact hypercalls
   that were causing these issues, nor do we have any context
   to help evaluate this any further

I at least checked with kvm folks and it seems hypercall preemption
is not needed there. We can survey other hypervisors...

If 'something like preemption' is needed then CONFIG_PREEMPT
should just be enabled and encouraged, it seems we want to
encourage CONFIG_PREEMPT on xen, specially when multicalls are
used. In the meantime this tries to address a solution to help
xen on non CONFIG_PREEMPT kernels.

One option tested and evaluated was to put private hypercalls in
process context, however this would introduce complexities such
originating hypercalls from different contexts. Current xen
hypercall callback handlers would need to be changed per architecture,
for instance, we'd also incur the cost of switching states from
user / kernel (this cost is also present if preempt_schedule_irq()
is used). There may be other issues which could be introduced with
this strategy as well. The simplest *shared* alternative is instead
to just explicitly schedule() at the end of a private hypercall on non
preempt kernels. This forces our private hypercall call mechanism
to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
more context switch but keeps the private hypercall context intact.

[0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
[1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch

Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <JGross@suse.com>
Cc: Olaf Hering <ohering@suse.de>
Cc: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/xen/privcmd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 569a13b..e29edba 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
 			   hypercall.arg[0], hypercall.arg[1],
 			   hypercall.arg[2], hypercall.arg[3],
 			   hypercall.arg[4]);
+#ifndef CONFIG_PREEMPT
+	schedule();
+#endif
 
 	return ret;
 }
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Nov 26 22:27:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Nov 2014 22:27:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtl3I-0003Uz-FL; Wed, 26 Nov 2014 22:27:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xtl3G-0003Uu-6V
	for xen-devel@lists.xenproject.org; Wed, 26 Nov 2014 22:27:10 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	3B/69-02697-DB356745; Wed, 26 Nov 2014 22:27:09 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417040825!13565962!1
X-Originating-IP: [209.85.220.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22778 invoked from network); 26 Nov 2014 22:27:06 -0000
Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com)
	(209.85.220.44)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2014 22:27:06 -0000
Received: by mail-pa0-f44.google.com with SMTP id et14so3688266pad.17
	for <xen-devel@lists.xenproject.org>;
	Wed, 26 Nov 2014 14:27:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:from:to:cc:subject:date:message-id;
	bh=4P6ugfyNgWXBQr9yoPaoj4+FGjDUpm9ElKCouqYiJCE=;
	b=a0PyO+tO9hK3TZe7gWcIycvG8/9VkP7AaLsnFEXMQ/21cWpi80yCmdAwyHAB184n8R
	YLvI0f25EyWm9uIf0KBBZeRjwMFi5fdiebPz9/AQKukRVQNM2qaj2adoAkWE/Jt8Qhi/
	0mxDOqh8vehsiy4WfL1beMB8vKaFxy1siNO57E4g+RMPYs7Wzn8hWeX7dWHhMIJv6K+0
	1GjoQFRppidwZjIT2/xSXjHeuIL4QhmqXT+mmCgf94AlVpiJxpCz9XmTWgEFTBypLY1r
	BE9qtz1zMxxWSQwvFdbkfL0ihdCneoODYEepwSer06HC/fyK9dlwOM2YM8WO8X03METo
	82FA==
X-Received: by 10.66.146.135 with SMTP id tc7mr58536878pab.155.1417040825167; 
	Wed, 26 Nov 2014 14:27:05 -0800 (PST)
Received: from mcgrof@gmail.com (c-98-234-145-61.hsd1.ca.comcast.net.
	[98.234.145.61]) by mx.google.com with ESMTPSA id
	cm10sm5263513pad.46.2014.11.26.14.27.01 for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 26 Nov 2014 14:27:03 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Wed, 26 Nov 2014 14:27:00 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org
Date: Wed, 26 Nov 2014 14:26:45 -0800
Message-Id: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
Cc: Juergen Gross <JGross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Jan Beulich <JBeulich@suse.com>,
	Borislav Petkov <bp@suse.de>, Olaf Hering <ohering@suse.de>
Subject: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
	hypercall when non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Some folks had reported that some xen hypercalls take a long time
to complete when issued from the userspace private ioctl mechanism,
this can happen for instance with some hypercalls that have many
sub-operations, this can happen for instance on hypercalls that use
multi-call feature whereby Xen lets one hypercall batch out a series
of other hypercalls on the hypervisor. At times such hypercalls can
even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
120 seconds), this a non-issue issue on preemptible kernels though as
the kernel may deschedule such long running tasks. Xen for instance
supports multicalls to be preempted as well, this is what Xen calls
continuation (see xen commit 42217cbc5b which introduced this [0]).
On systems without CONFIG_PREEMPT though -- a kernel with voluntary
or no preemption -- a long running hypercall will not be descheduled
until the hypercall is complete and the ioctl returns to user space.

To help with this David had originally implemented support for use
of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
solution never went upstream though and upon review to help refactor
this I've concluded that usage of preempt_schedule_irq() would be
a bit abussive of existing APIs -- for a few reasons:

0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels

1) we want try to consider solutions that might work for other
   hypervisors for this same problem, and identify it its an issue
   even present on other hypervisors or if this is a self
   inflicted architectural issue caused by use of multicalls

2) there is no documentation or profiling of the exact hypercalls
   that were causing these issues, nor do we have any context
   to help evaluate this any further

I at least checked with kvm folks and it seems hypercall preemption
is not needed there. We can survey other hypervisors...

If 'something like preemption' is needed then CONFIG_PREEMPT
should just be enabled and encouraged, it seems we want to
encourage CONFIG_PREEMPT on xen, specially when multicalls are
used. In the meantime this tries to address a solution to help
xen on non CONFIG_PREEMPT kernels.

One option tested and evaluated was to put private hypercalls in
process context, however this would introduce complexities such
originating hypercalls from different contexts. Current xen
hypercall callback handlers would need to be changed per architecture,
for instance, we'd also incur the cost of switching states from
user / kernel (this cost is also present if preempt_schedule_irq()
is used). There may be other issues which could be introduced with
this strategy as well. The simplest *shared* alternative is instead
to just explicitly schedule() at the end of a private hypercall on non
preempt kernels. This forces our private hypercall call mechanism
to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
more context switch but keeps the private hypercall context intact.

[0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
[1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch

Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <JGross@suse.com>
Cc: Olaf Hering <ohering@suse.de>
Cc: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/xen/privcmd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 569a13b..e29edba 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
 			   hypercall.arg[0], hypercall.arg[1],
 			   hypercall.arg[2], hypercall.arg[3],
 			   hypercall.arg[4]);
+#ifndef CONFIG_PREEMPT
+	schedule();
+#endif
 
 	return ret;
 }
-- 
2.1.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 00:20:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 00: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.xen.org>)
	id 1XtmoP-0005fi-CP; Thu, 27 Nov 2014 00:19:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1XtmoJ-0005fd-Ms
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 00:19:51 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	FF/1A-02957-62E66745; Thu, 27 Nov 2014 00:19:50 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417047588!14536028!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8010 invoked from network); 27 Nov 2014 00:19:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 00:19:50 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAR0Ji3f003226
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Nov 2014 00:19:45 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAR0JhiP004853
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 27 Nov 2014 00:19:44 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAR0Jhik004847; Thu, 27 Nov 2014 00:19:43 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 16:19:42 -0800
Date: Thu, 27 Nov 2014 01:19:38 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141127001938.GJ28040@olila.local.net-space.pl>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com>
	<20141126143027.GA8735@laptop.dumpdata.com>
	<5475E892.5060400@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5475E892.5060400@suse.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 26, 2014 at 03:49:54PM +0100, Juergen Gross wrote:
> On 11/26/2014 03:30 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
> >>On 11/26/2014 01:41 PM, Andrew Cooper wrote:
> >>>On 26/11/14 12:15, Juergen Gross wrote:
> >>>>Hi,
> >>>>
> >>>>I tried to enable kdump on my test-machine with actual xen-unstable
> >>>>booting via EFI.
> >>>>
> >>>>The kdump kernel is not being loaded.
> >>>>
> >>>>I'm seeing the memory being reserved:
> >>>>
> >>>>(XEN) EFI RAM map:
> >>>>(XEN)  0000000000000000 - 00000000000a0000 (usable)
> >>>>(XEN)  0000000000100000 - 000000004bc00000 (usable)
> >>>>(XEN)  000000004bc00000 - 000000005bc00000 (reserved)
> >>>>(XEN)  000000005bc00000 - 000000005bfec000 (usable)
> >>>>(XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
> >>>>(XEN)  000000005c000000 - 000000006a429000 (usable)
> >>>>(XEN)  000000006a429000 - 000000006a42c000 (reserved)
> >>>>(XEN)  000000006a42c000 - 000000006a7a2000 (usable)
> >>>>(XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
> >>>>(XEN)  000000006a7a8000 - 000000006a987000 (usable)
> >>>>(XEN)  000000006a987000 - 000000006a98d000 (reserved)
> >>>>(XEN)  000000006a98d000 - 000000006aa63000 (usable)
> >>>>(XEN)  000000006aa63000 - 000000006aa73000 (reserved)
> >>>>(XEN)  000000006aa73000 - 000000006ac60000 (usable)
> >>>>(XEN)  000000006ac60000 - 000000006ac61000 (reserved)
> >>>>(XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
> >>>>(XEN)  000000006ac9b000 - 000000006acac000 (reserved)
> >>>>(XEN)  000000006acac000 - 000000006acad000 (usable)
> >>>>(XEN)  000000006acad000 - 000000006acae000 (reserved)
> >>>>(XEN)  000000006acae000 - 000000007189c000 (usable)
> >>>>(XEN)  000000007189c000 - 0000000071946000 (reserved)
> >>>>(XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
> >>>>(XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
> >>>>(XEN)  0000000072db2000 - 0000000072edc000 (usable)
> >>>>(XEN)  0000000080000000 - 0000000090000000 (reserved)
> >>>>(XEN)  0000000100000000 - 0000002080000000 (usable)
> >>>>(XEN) Kdump: 256MB (262144kB) at 0x206dff4000
> >>>>
> >>>>I'd expect this area being visible in the efi or e820 map presented to
> >>>>dom0, but I can't see anything:
> >>>
> >>>This is expected.  The dom0 kernel now has nothing at all do with
> >>>loading crash kernel.  Loading happens via hypercalls straight from the
> >>>kexec utility.
> >>>
> >>>You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
> >>>support, but it should JustWork.
> >>
> >>Should. I have kexec 2.0.5 with Xen support. Doesn't work:
> >>
> >>Excerpt form strace:
> >>
> >>"sysctl operation failed -- need to rebuild the user-space tool set?\n"
> >>
> >>My personal translation: kexec is tightly coupled to the Xen version
> >>(this one was built against Xen 4.4.1 AFAIK).
> >
> >Odd, the hypercall interface did not change in Xen 4.5 for kexec?
> >
> >Perhaps it is making some other hypercalls that are tied in
> >to the version of Xen (like sysctl ones?).
>
> The error message above suggests that, yes. :-)
>
> Grepping for xc_ in kexec sources finds e.g. xc_get_max_cpus() which
> in turn calls xc_physinfo() doing a sysctl.
>
> >
> >I presume with recompiling it works?
>
> Didn't check up to now, but I think it should.

Are you sure that kexec-tools configure script discovered
Xen headers and development libraries? Please check that.
"ldd kexec" is your friend.

Do not forget to use kexec-tools version 2.0.5 or newer.

> >>
> >>Perhaps we should add kexec to the tools directory?
> >
> >Gosh no.
>
> Oops, did I forget the smiley? ;-)
>
> I think we should look what kexec is really needing and put this in a
> stable interface set (perhaps an own library?). This might require some

David did the work.

> new sub functions of e.g. the KEXEC hypercall, but this is better than
> making kexec depending on the Xen version.

Maybe we need some things which are specific for EFI platforms. I am
going to investigate that after finishing EFI + multiboot2 work.
Probably it will happen at the beginning of next year.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 00:20:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 00: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.xen.org>)
	id 1XtmoP-0005fi-CP; Thu, 27 Nov 2014 00:19:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1XtmoJ-0005fd-Ms
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 00:19:51 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	FF/1A-02957-62E66745; Thu, 27 Nov 2014 00:19:50 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417047588!14536028!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8010 invoked from network); 27 Nov 2014 00:19:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 00:19:50 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAR0Ji3f003226
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Nov 2014 00:19:45 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAR0JhiP004853
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 27 Nov 2014 00:19:44 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])
	by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAR0Jhik004847; Thu, 27 Nov 2014 00:19:43 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Nov 2014 16:19:42 -0800
Date: Thu, 27 Nov 2014 01:19:38 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141127001938.GJ28040@olila.local.net-space.pl>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com>
	<20141126143027.GA8735@laptop.dumpdata.com>
	<5475E892.5060400@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5475E892.5060400@suse.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 26, 2014 at 03:49:54PM +0100, Juergen Gross wrote:
> On 11/26/2014 03:30 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
> >>On 11/26/2014 01:41 PM, Andrew Cooper wrote:
> >>>On 26/11/14 12:15, Juergen Gross wrote:
> >>>>Hi,
> >>>>
> >>>>I tried to enable kdump on my test-machine with actual xen-unstable
> >>>>booting via EFI.
> >>>>
> >>>>The kdump kernel is not being loaded.
> >>>>
> >>>>I'm seeing the memory being reserved:
> >>>>
> >>>>(XEN) EFI RAM map:
> >>>>(XEN)  0000000000000000 - 00000000000a0000 (usable)
> >>>>(XEN)  0000000000100000 - 000000004bc00000 (usable)
> >>>>(XEN)  000000004bc00000 - 000000005bc00000 (reserved)
> >>>>(XEN)  000000005bc00000 - 000000005bfec000 (usable)
> >>>>(XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
> >>>>(XEN)  000000005c000000 - 000000006a429000 (usable)
> >>>>(XEN)  000000006a429000 - 000000006a42c000 (reserved)
> >>>>(XEN)  000000006a42c000 - 000000006a7a2000 (usable)
> >>>>(XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
> >>>>(XEN)  000000006a7a8000 - 000000006a987000 (usable)
> >>>>(XEN)  000000006a987000 - 000000006a98d000 (reserved)
> >>>>(XEN)  000000006a98d000 - 000000006aa63000 (usable)
> >>>>(XEN)  000000006aa63000 - 000000006aa73000 (reserved)
> >>>>(XEN)  000000006aa73000 - 000000006ac60000 (usable)
> >>>>(XEN)  000000006ac60000 - 000000006ac61000 (reserved)
> >>>>(XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
> >>>>(XEN)  000000006ac9b000 - 000000006acac000 (reserved)
> >>>>(XEN)  000000006acac000 - 000000006acad000 (usable)
> >>>>(XEN)  000000006acad000 - 000000006acae000 (reserved)
> >>>>(XEN)  000000006acae000 - 000000007189c000 (usable)
> >>>>(XEN)  000000007189c000 - 0000000071946000 (reserved)
> >>>>(XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
> >>>>(XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
> >>>>(XEN)  0000000072db2000 - 0000000072edc000 (usable)
> >>>>(XEN)  0000000080000000 - 0000000090000000 (reserved)
> >>>>(XEN)  0000000100000000 - 0000002080000000 (usable)
> >>>>(XEN) Kdump: 256MB (262144kB) at 0x206dff4000
> >>>>
> >>>>I'd expect this area being visible in the efi or e820 map presented to
> >>>>dom0, but I can't see anything:
> >>>
> >>>This is expected.  The dom0 kernel now has nothing at all do with
> >>>loading crash kernel.  Loading happens via hypercalls straight from the
> >>>kexec utility.
> >>>
> >>>You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
> >>>support, but it should JustWork.
> >>
> >>Should. I have kexec 2.0.5 with Xen support. Doesn't work:
> >>
> >>Excerpt form strace:
> >>
> >>"sysctl operation failed -- need to rebuild the user-space tool set?\n"
> >>
> >>My personal translation: kexec is tightly coupled to the Xen version
> >>(this one was built against Xen 4.4.1 AFAIK).
> >
> >Odd, the hypercall interface did not change in Xen 4.5 for kexec?
> >
> >Perhaps it is making some other hypercalls that are tied in
> >to the version of Xen (like sysctl ones?).
>
> The error message above suggests that, yes. :-)
>
> Grepping for xc_ in kexec sources finds e.g. xc_get_max_cpus() which
> in turn calls xc_physinfo() doing a sysctl.
>
> >
> >I presume with recompiling it works?
>
> Didn't check up to now, but I think it should.

Are you sure that kexec-tools configure script discovered
Xen headers and development libraries? Please check that.
"ldd kexec" is your friend.

Do not forget to use kexec-tools version 2.0.5 or newer.

> >>
> >>Perhaps we should add kexec to the tools directory?
> >
> >Gosh no.
>
> Oops, did I forget the smiley? ;-)
>
> I think we should look what kexec is really needing and put this in a
> stable interface set (perhaps an own library?). This might require some

David did the work.

> new sub functions of e.g. the KEXEC hypercall, but this is better than
> making kexec depending on the Xen version.

Maybe we need some things which are specific for EFI platforms. I am
going to investigate that after finishing EFI + multiboot2 work.
Probably it will happen at the beginning of next year.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 02:17:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 02:17:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtodj-0003Rf-KQ; Thu, 27 Nov 2014 02:17:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xtodh-0003Ra-28
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 02:17:01 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	1D/29-02696-C9986745; Thu, 27 Nov 2014 02:17:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417054617!15126926!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24449 invoked from network); 27 Nov 2014 02:16:58 -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;
	27 Nov 2014 02:16:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,466,1413244800"; d="scan'208";a="197036805"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 21:16:55 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xtodb-0005yJ-7w;
	Thu, 27 Nov 2014 02:16:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xtoda-0001iX-QC;
	Thu, 27 Nov 2014 02:16:54 +0000
Date: Thu, 27 Nov 2014 02:16:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31861-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31861: 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 31861 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31861/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail REGR. vs. 31853
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)   broken REGR. vs. 31853

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 31853
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31853

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  d85728a3c5e112383e99fc23825fd238a4fb8c63
baseline version:
 xen                  104072fc1c7e6ed117c70fa7f91ecc9946f8f654

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <julien.grall@linaro.org>
  Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           broken  
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-qemut-winxpsp3 host-install(3)

Not pushing.

------------------------------------------------------------
commit d85728a3c5e112383e99fc23825fd238a4fb8c63
Merge: 8f4023d 13f72e9
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 25 16:24:19 2014 +0000

    Merge branch 'staging' of ssh://xenbits.xen.org/home/xen/git/xen into staging

commit 13f72e92a32380e94cb0c86725a1b38a6d191461
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 17:21:52 2014 +0100

    vNUMA: rename interface structures
    
    No-one (including me) paid attention during review that these
    structures don't adhere to the naming requirements of the public
    interface: Consistently use xen_ prefixes at least for all new
    additions.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 8f4023dd7d77de7b2c1af77e86637202a33f948a
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Thu Nov 20 15:48:47 2014 +0000

    libxc: don't leak buffer containing the uncompressed PV kernel
    
    The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
    is freed by xc_dom_release. However the various xc_try_*_decode routines (other
    than the gzip one) just use plain malloc/realloc and therefore the buffer ends
    up leaked.
    
    The memory pool currently supports mmap'd buffers as well as a directly
    allocated buffers, however the try decode routines make use of realloc and do
    not fit well into this model. Introduce a concept of an external memory block
    to the memory pool and provide an interface to register such memory.
    
    The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
    mmap_ prefix since they are now also used for external memory blocks.
    
    We are only seeing this now because the gzip decoder doesn't leak and it's only
    relatively recently that kernels in the wild have switched to better
    compression.
    
    This is https://bugs.debian.org/767295
    
    Reported by: Gedalya <gedalya@gedalya.net>
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: Wei Liu <wei.liu2@citrix.com>

commit d17405f8153f7419db680a183f10129410feca05
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed Nov 19 15:28:15 2014 +0000

    xen: arm: Support the other 4 PCI buses on Xgene
    
    Currently we only establish specific mappings for pcie0, which is
    used on the Mustang platform. However at least McDivitt uses pcie3.
    So wire up all the others, based on whether the corresponding DT node
    is marked as available.
    
    This results in no change for Mustang.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>

commit 31180f87e4f7f63e3bca029b4a60978f57eb0331
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Fri Nov 21 14:31:30 2014 +0000

    xen/arm: clear UIE on hypervisor entry
    
    UIE being set can cause maintenance interrupts to occur when Xen writes
    to one or more LR registers. The effect is a busy loop around the
    interrupt handler in Xen
    (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
    Tested-by: Julien Grall <julien.grall@linaro.org>
    Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 8342b121cd57f4bebedc7ab4be69922b07afefa5
Author: Julien Grall <julien.grall@linaro.org>
Date:   Thu Nov 20 17:36:03 2014 +0000

    scripts/get_maintainer.pl: Correctly CC the maintainers
    
    The current script is setting $email_remove_duplicates to 1 by default, on
    complex patch (see [1]), this will result to ommitting randomly some
    maintainers.
    
    This is because, the script will:
        1) Get the list of maintainers of the file (incidentally all the
           maintainers in "THE REST" role are added). If the email address already
           exists in the global list, skip it. => The role will be lost
        2) Filter the list to remove the entry with "THE REST" role
    
    So if a maintainers is marked with "THE REST" role on the first file and
    actually be an x86 maintainers on the script, the script will only retain
    the "THE REST" role. During the filtering step, this maintainers will
    therefore be dropped.
    
    This patch fixes this by setting $email_remove_duplicates to 0 by default.
    The new behavior of the script will be:
        1) Append the list of maintainers for every file
        2) Filter the list to remove the entry with "THE REST" role
        3) Remove duplicated email address
    
    Example:
    
    Patch: https://patches.linaro.org/41083/
    
    Before the patch:
    
    Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Ian Jackson <ian.jackson@eu.citrix.com>
    Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Ian Campbell <ian.campbell@citrix.com>
    Wei Liu <wei.liu2@citrix.com>
    George Dunlap <george.dunlap@eu.citrix.com>
    xen-devel@lists.xen.org
    
    After the patch:
    
    Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Ian Jackson <ian.jackson@eu.citrix.com>
    Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Ian Campbell <ian.campbell@citrix.com>
    Wei Liu <wei.liu2@citrix.com>
    Stefano Stabellini <stefano.stabellini@citrix.com>
    Tim Deegan <tim@xen.org>
    Keir Fraser <keir@xen.org>
    Jan Beulich <jbeulich@suse.com>
    George Dunlap <george.dunlap@eu.citrix.com>
    xen-devel@lists.xen.org
    
    [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    CC: Don Slutz <dslutz@verizon.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 47c6e7f28ddc27f194c7c4902ea3163ba582b582
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Wed Nov 12 17:31:33 2014 +0000

    xl: Return proper error codes for block-attach and block-detach
    
    Return proper error codes on failure so that scripts can tell whether
    the command completed properly or not.
    
    This is not a proper fix, since it fails to call
    libxl_device_disk_dispose() on the error path.  But a proper fix
    requires some refactoring, so given where we are in the release
    process, it's better to have a fix that is simple and obvious, and do
    the refactoring once the next development window opens up.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 28b4baacd599e8c10e6dac055f6a939bb730fb8a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:08:57 2014 +0100

    x86/HVM: don't crash guest upon problems occurring in user mode
    
    This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
    exit occurred in guest kernel mode") to a few more cases, including the
    failed VM entry one that XSA-110 was needed to be issued for.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 1516b33961028ba4f6e70c0da464e9ed0a190760
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:08:04 2014 +0100

    x86: don't ignore foreigndom input on various MMUEXT ops
    
    Instead properly fail requests that shouldn't be issued on foreign
    domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
    operation to work that way.
    
    In the course of doing this the need to always clear "okay" even when
    wanting an error code other than -EINVAL became unwieldy, so the
    respective logic is being adjusted at once, together with a little
    other related cleanup.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit dc419f0a3752032ab00124dc55609d9231e53128
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:07:09 2014 +0100

    x86: tighten page table owner checking in do_mmu_update()
    
    MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
    a bad page table domain being specified.
    
    Also pt_owner can't be NULL when reaching the "out" label, so the
    respective check can be dropped.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 0aabd10525326edfe5098c2ec5bfe05db7732c32
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:05:29 2014 +0100

    x86/cpuidle: don't count C1 multiple times
    
    Commit 4ca6f9f0 ("x86/cpuidle: publish new states only after fully
    initializing them") resulted in the state counter to be incremented
    for C1 despite that using a fixed table entry (and the statically
    initialized counter value already accounting for it and C0).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 02:17:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 02:17:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtodj-0003Rf-KQ; Thu, 27 Nov 2014 02:17:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xtodh-0003Ra-28
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 02:17:01 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	1D/29-02696-C9986745; Thu, 27 Nov 2014 02:17:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417054617!15126926!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24449 invoked from network); 27 Nov 2014 02:16:58 -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;
	27 Nov 2014 02:16:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,466,1413244800"; d="scan'208";a="197036805"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 21:16:55 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xtodb-0005yJ-7w;
	Thu, 27 Nov 2014 02:16:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xtoda-0001iX-QC;
	Thu, 27 Nov 2014 02:16:54 +0000
Date: Thu, 27 Nov 2014 02:16:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31861-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31861: 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 31861 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31861/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail REGR. vs. 31853
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)   broken REGR. vs. 31853

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 31853
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31853

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  d85728a3c5e112383e99fc23825fd238a4fb8c63
baseline version:
 xen                  104072fc1c7e6ed117c70fa7f91ecc9946f8f654

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <julien.grall@linaro.org>
  Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           broken  
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-qemut-winxpsp3 host-install(3)

Not pushing.

------------------------------------------------------------
commit d85728a3c5e112383e99fc23825fd238a4fb8c63
Merge: 8f4023d 13f72e9
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 25 16:24:19 2014 +0000

    Merge branch 'staging' of ssh://xenbits.xen.org/home/xen/git/xen into staging

commit 13f72e92a32380e94cb0c86725a1b38a6d191461
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 17:21:52 2014 +0100

    vNUMA: rename interface structures
    
    No-one (including me) paid attention during review that these
    structures don't adhere to the naming requirements of the public
    interface: Consistently use xen_ prefixes at least for all new
    additions.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 8f4023dd7d77de7b2c1af77e86637202a33f948a
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Thu Nov 20 15:48:47 2014 +0000

    libxc: don't leak buffer containing the uncompressed PV kernel
    
    The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
    is freed by xc_dom_release. However the various xc_try_*_decode routines (other
    than the gzip one) just use plain malloc/realloc and therefore the buffer ends
    up leaked.
    
    The memory pool currently supports mmap'd buffers as well as a directly
    allocated buffers, however the try decode routines make use of realloc and do
    not fit well into this model. Introduce a concept of an external memory block
    to the memory pool and provide an interface to register such memory.
    
    The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
    mmap_ prefix since they are now also used for external memory blocks.
    
    We are only seeing this now because the gzip decoder doesn't leak and it's only
    relatively recently that kernels in the wild have switched to better
    compression.
    
    This is https://bugs.debian.org/767295
    
    Reported by: Gedalya <gedalya@gedalya.net>
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: Wei Liu <wei.liu2@citrix.com>

commit d17405f8153f7419db680a183f10129410feca05
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed Nov 19 15:28:15 2014 +0000

    xen: arm: Support the other 4 PCI buses on Xgene
    
    Currently we only establish specific mappings for pcie0, which is
    used on the Mustang platform. However at least McDivitt uses pcie3.
    So wire up all the others, based on whether the corresponding DT node
    is marked as available.
    
    This results in no change for Mustang.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>

commit 31180f87e4f7f63e3bca029b4a60978f57eb0331
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Fri Nov 21 14:31:30 2014 +0000

    xen/arm: clear UIE on hypervisor entry
    
    UIE being set can cause maintenance interrupts to occur when Xen writes
    to one or more LR registers. The effect is a busy loop around the
    interrupt handler in Xen
    (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
    Tested-by: Julien Grall <julien.grall@linaro.org>
    Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 8342b121cd57f4bebedc7ab4be69922b07afefa5
Author: Julien Grall <julien.grall@linaro.org>
Date:   Thu Nov 20 17:36:03 2014 +0000

    scripts/get_maintainer.pl: Correctly CC the maintainers
    
    The current script is setting $email_remove_duplicates to 1 by default, on
    complex patch (see [1]), this will result to ommitting randomly some
    maintainers.
    
    This is because, the script will:
        1) Get the list of maintainers of the file (incidentally all the
           maintainers in "THE REST" role are added). If the email address already
           exists in the global list, skip it. => The role will be lost
        2) Filter the list to remove the entry with "THE REST" role
    
    So if a maintainers is marked with "THE REST" role on the first file and
    actually be an x86 maintainers on the script, the script will only retain
    the "THE REST" role. During the filtering step, this maintainers will
    therefore be dropped.
    
    This patch fixes this by setting $email_remove_duplicates to 0 by default.
    The new behavior of the script will be:
        1) Append the list of maintainers for every file
        2) Filter the list to remove the entry with "THE REST" role
        3) Remove duplicated email address
    
    Example:
    
    Patch: https://patches.linaro.org/41083/
    
    Before the patch:
    
    Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Ian Jackson <ian.jackson@eu.citrix.com>
    Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Ian Campbell <ian.campbell@citrix.com>
    Wei Liu <wei.liu2@citrix.com>
    George Dunlap <george.dunlap@eu.citrix.com>
    xen-devel@lists.xen.org
    
    After the patch:
    
    Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Ian Jackson <ian.jackson@eu.citrix.com>
    Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Ian Campbell <ian.campbell@citrix.com>
    Wei Liu <wei.liu2@citrix.com>
    Stefano Stabellini <stefano.stabellini@citrix.com>
    Tim Deegan <tim@xen.org>
    Keir Fraser <keir@xen.org>
    Jan Beulich <jbeulich@suse.com>
    George Dunlap <george.dunlap@eu.citrix.com>
    xen-devel@lists.xen.org
    
    [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    CC: Don Slutz <dslutz@verizon.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 47c6e7f28ddc27f194c7c4902ea3163ba582b582
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Wed Nov 12 17:31:33 2014 +0000

    xl: Return proper error codes for block-attach and block-detach
    
    Return proper error codes on failure so that scripts can tell whether
    the command completed properly or not.
    
    This is not a proper fix, since it fails to call
    libxl_device_disk_dispose() on the error path.  But a proper fix
    requires some refactoring, so given where we are in the release
    process, it's better to have a fix that is simple and obvious, and do
    the refactoring once the next development window opens up.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 28b4baacd599e8c10e6dac055f6a939bb730fb8a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:08:57 2014 +0100

    x86/HVM: don't crash guest upon problems occurring in user mode
    
    This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
    exit occurred in guest kernel mode") to a few more cases, including the
    failed VM entry one that XSA-110 was needed to be issued for.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 1516b33961028ba4f6e70c0da464e9ed0a190760
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:08:04 2014 +0100

    x86: don't ignore foreigndom input on various MMUEXT ops
    
    Instead properly fail requests that shouldn't be issued on foreign
    domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
    operation to work that way.
    
    In the course of doing this the need to always clear "okay" even when
    wanting an error code other than -EINVAL became unwieldy, so the
    respective logic is being adjusted at once, together with a little
    other related cleanup.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit dc419f0a3752032ab00124dc55609d9231e53128
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:07:09 2014 +0100

    x86: tighten page table owner checking in do_mmu_update()
    
    MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
    a bad page table domain being specified.
    
    Also pt_owner can't be NULL when reaching the "out" label, so the
    respective check can be dropped.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 0aabd10525326edfe5098c2ec5bfe05db7732c32
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:05:29 2014 +0100

    x86/cpuidle: don't count C1 multiple times
    
    Commit 4ca6f9f0 ("x86/cpuidle: publish new states only after fully
    initializing them") resulted in the state counter to be incremented
    for C1 despite that using a fixed table entry (and the statically
    initialized counter value already accounting for it and C0).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 02:42:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 02:42:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtp25-0003z7-Kp; Thu, 27 Nov 2014 02:42:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xtp24-0003vy-JA
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 02:42:12 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	78/D6-02702-38F86745; Thu, 27 Nov 2014 02:42:11 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417056129!15132023!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4924 invoked from network); 27 Nov 2014 02:42:10 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 02:42:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417056130; x=1448592130;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=d1IyvM3Cs4MBwS7dyLmVjcvUsx0fuM7UzoPQk6dNC6c=;
	b=aOJ4TAq7DiAtDSlf6iHT+8/zcXvY5sqqG9iJbFqdiYwnPXLTEcr6JJxD
	S2BYmZgp10Zut2fiyumc9XvEiDSmC/GYp5C7nOdG1NmGqLRTNA/G/77+H
	Upj/dVLPa2um53JM3mcBLAA/N4vBNtrm7hltovYZm9eBa4NWAFUA23uku c=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 27 Nov 2014 02:42:08 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,466,1413244800"; d="scan'208";a="915466498"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.106.142])
	by fldsmtpi01.verizon.com with ESMTP; 27 Nov 2014 02:42:07 +0000
Message-ID: <54768F7F.2030602@terremark.com>
Date: Wed, 26 Nov 2014 21:42:07 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
	<5474C96A.6090506@citrix.com>
	<alpine.DEB.2.02.1411261817330.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411261817330.14135@kaball.uk.xensource.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] increase maxmem before calling
 xc_domain_populate_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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/26/14 13:17, Stefano Stabellini wrote:
> On Tue, 25 Nov 2014, Andrew Cooper wrote:
>> On 25/11/14 17:45, Stefano Stabellini wrote:
>>> Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
>>> the risk of running out of guest memory. This way we can also avoid
>>> complex memory calculations in libxl at domain construction time.
>>>
>>> This patch fixes an abort() when assigning more than 4 NICs to a VM.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>
>>> diff --git a/xen-hvm.c b/xen-hvm.c
>>> index 5c69a8d..38e08c3 100644
>>> --- a/xen-hvm.c
>>> +++ b/xen-hvm.c
>>> @@ -218,6 +218,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
>>>       unsigned long nr_pfn;
>>>       xen_pfn_t *pfn_list;
>>>       int i;
>>> +    xc_dominfo_t info;
>>>   
>>>       if (runstate_check(RUN_STATE_INMIGRATE)) {
>>>           /* RAM already populated in Xen */
>>> @@ -240,6 +241,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
>>>           pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
>>>       }
>>>   
>>> +    if (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) < 0) {
>> xc_domain_getinfo()'s interface is mad, and provides no guarantee that
>> it returns the information for the domain you requested.  It also won't
>> return -1 on error.  The correct error handing is:
>>
>> (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) || (info.domid !=
>> xen_domid)
> It might be wiser to switch to xc_domain_getinfolist

Either needs the same tests, since both return an vector of info.

>
>> ~Andrew
>>
>>> +        hw_error("xc_domain_getinfo failed");
>>> +    }
>>> +    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
>>> +                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {

There are two big issues and 1 minor one with this.
1) You will allocate the videoram again.
2) You will never use the 1 MB already allocated for option ROMs.

And the minor one is that you can increase maxmem more then is needed.


Here is a better if:

-    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
-                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
+    max_pages = info.max_memkb * 1024 / XC_PAGE_SIZE;
+    free_pages = max_pages - info.nr_pages;
+    need_pages = nr_pfn - free_pages;
+    if ((free_pages < nr_pfn) &&
+       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
+                            (need_pages * XC_PAGE_SIZE / 1024)) < 0)) {


My testing shows a free 32 pages that I am not sure where they come 
from.  But
the code about is passing my 8 nics of e1000.


    -Don Slutz


>>> +        hw_error("xc_domain_setmaxmem failed");
>>> +    }
>>>       if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) {
>>>           hw_error("xen: failed to populate ram at " RAM_ADDR_FMT, ram_addr);
>>>       }
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/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 Nov 27 02:42:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 02:42:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtp25-0003z7-Kp; Thu, 27 Nov 2014 02:42:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xtp24-0003vy-JA
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 02:42:12 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	78/D6-02702-38F86745; Thu, 27 Nov 2014 02:42:11 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417056129!15132023!1
X-Originating-IP: [199.249.25.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk5LjI0OS4yNS4yMDcgPT4gMjk3MjAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4924 invoked from network); 27 Nov 2014 02:42:10 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 02:42:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417056130; x=1448592130;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=d1IyvM3Cs4MBwS7dyLmVjcvUsx0fuM7UzoPQk6dNC6c=;
	b=aOJ4TAq7DiAtDSlf6iHT+8/zcXvY5sqqG9iJbFqdiYwnPXLTEcr6JJxD
	S2BYmZgp10Zut2fiyumc9XvEiDSmC/GYp5C7nOdG1NmGqLRTNA/G/77+H
	Upj/dVLPa2um53JM3mcBLAA/N4vBNtrm7hltovYZm9eBa4NWAFUA23uku c=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 27 Nov 2014 02:42:08 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,466,1413244800"; d="scan'208";a="915466498"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.106.142])
	by fldsmtpi01.verizon.com with ESMTP; 27 Nov 2014 02:42:07 +0000
Message-ID: <54768F7F.2030602@terremark.com>
Date: Wed, 26 Nov 2014 21:42:07 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
	<5474C96A.6090506@citrix.com>
	<alpine.DEB.2.02.1411261817330.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411261817330.14135@kaball.uk.xensource.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] increase maxmem before calling
 xc_domain_populate_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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/26/14 13:17, Stefano Stabellini wrote:
> On Tue, 25 Nov 2014, Andrew Cooper wrote:
>> On 25/11/14 17:45, Stefano Stabellini wrote:
>>> Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
>>> the risk of running out of guest memory. This way we can also avoid
>>> complex memory calculations in libxl at domain construction time.
>>>
>>> This patch fixes an abort() when assigning more than 4 NICs to a VM.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>
>>> diff --git a/xen-hvm.c b/xen-hvm.c
>>> index 5c69a8d..38e08c3 100644
>>> --- a/xen-hvm.c
>>> +++ b/xen-hvm.c
>>> @@ -218,6 +218,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
>>>       unsigned long nr_pfn;
>>>       xen_pfn_t *pfn_list;
>>>       int i;
>>> +    xc_dominfo_t info;
>>>   
>>>       if (runstate_check(RUN_STATE_INMIGRATE)) {
>>>           /* RAM already populated in Xen */
>>> @@ -240,6 +241,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
>>>           pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
>>>       }
>>>   
>>> +    if (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) < 0) {
>> xc_domain_getinfo()'s interface is mad, and provides no guarantee that
>> it returns the information for the domain you requested.  It also won't
>> return -1 on error.  The correct error handing is:
>>
>> (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) || (info.domid !=
>> xen_domid)
> It might be wiser to switch to xc_domain_getinfolist

Either needs the same tests, since both return an vector of info.

>
>> ~Andrew
>>
>>> +        hw_error("xc_domain_getinfo failed");
>>> +    }
>>> +    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
>>> +                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {

There are two big issues and 1 minor one with this.
1) You will allocate the videoram again.
2) You will never use the 1 MB already allocated for option ROMs.

And the minor one is that you can increase maxmem more then is needed.


Here is a better if:

-    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
-                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
+    max_pages = info.max_memkb * 1024 / XC_PAGE_SIZE;
+    free_pages = max_pages - info.nr_pages;
+    need_pages = nr_pfn - free_pages;
+    if ((free_pages < nr_pfn) &&
+       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
+                            (need_pages * XC_PAGE_SIZE / 1024)) < 0)) {


My testing shows a free 32 pages that I am not sure where they come 
from.  But
the code about is passing my 8 nics of e1000.


    -Don Slutz


>>> +        hw_error("xc_domain_setmaxmem failed");
>>> +    }
>>>       if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) {
>>>           hw_error("xen: failed to populate ram at " RAM_ADDR_FMT, ram_addr);
>>>       }
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/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 Nov 27 03:47:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 03: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 1Xtq2U-00050B-Qq; Thu, 27 Nov 2014 03:46:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xtq2T-000506-Nd
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 03:46:41 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	32/02-05632-0AE96745; Thu, 27 Nov 2014 03:46:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417059997!13994594!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26654 invoked from network); 27 Nov 2014 03:46:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 03:46:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,466,1413244800"; d="scan'208";a="197306759"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 22:46:35 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xtq2N-0006Ov-0n;
	Thu, 27 Nov 2014 03:46:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xtq2M-0000zi-RV;
	Thu, 27 Nov 2014 03:46:34 +0000
Date: Thu, 27 Nov 2014 03:46:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31862-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31862: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31862 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31862/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl           11 guest-saverestore       fail baseline untested
 test-amd64-i386-xl-credit2    3 host-install(3)       broken baseline untested
 test-amd64-amd64-xl-sedf     12 guest-localmigrate      fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3) broken baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin 12 guest-localmigrate      fail baseline untested
 test-armhf-armhf-xl          12 guest-start.2           fail baseline untested
 test-amd64-amd64-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-rumpuserxen-i386  3 host-install(3)   broken baseline untested
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)    broken baseline untested
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3) broken baseline untested
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)  broken baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                7cc2ecdb63cfae062aeadc7c575a02b6e9cc4dbb
baseline version:
 linux                5d01410fe4d92081f349b013a2e7a95429e4f2c9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 03:47:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 03: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 1Xtq2U-00050B-Qq; Thu, 27 Nov 2014 03:46:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xtq2T-000506-Nd
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 03:46:41 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	32/02-05632-0AE96745; Thu, 27 Nov 2014 03:46:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417059997!13994594!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26654 invoked from network); 27 Nov 2014 03:46:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 03:46:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,466,1413244800"; d="scan'208";a="197306759"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Wed, 26 Nov 2014 22:46:35 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xtq2N-0006Ov-0n;
	Thu, 27 Nov 2014 03:46:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xtq2M-0000zi-RV;
	Thu, 27 Nov 2014 03:46:34 +0000
Date: Thu, 27 Nov 2014 03:46:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31862-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31862: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31862 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31862/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl           11 guest-saverestore       fail baseline untested
 test-amd64-i386-xl-credit2    3 host-install(3)       broken baseline untested
 test-amd64-amd64-xl-sedf     12 guest-localmigrate      fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3) broken baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin 12 guest-localmigrate      fail baseline untested
 test-armhf-armhf-xl          12 guest-start.2           fail baseline untested
 test-amd64-amd64-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-rumpuserxen-i386  3 host-install(3)   broken baseline untested
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)    broken baseline untested
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3) broken baseline untested
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)  broken baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                7cc2ecdb63cfae062aeadc7c575a02b6e9cc4dbb
baseline version:
 linux                5d01410fe4d92081f349b013a2e7a95429e4f2c9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 03:54:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 03:54:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtq9T-0005IG-V6; Thu, 27 Nov 2014 03:53:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <seth.forshee@canonical.com>) id 1Xtq9S-0005IB-Sy
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 03:53:54 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	60/57-09842-250A6745; Thu, 27 Nov 2014 03:53:54 +0000
X-Env-Sender: seth.forshee@canonical.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417060432!15660554!1
X-Originating-IP: [209.85.214.180]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2829 invoked from network); 27 Nov 2014 03:53:53 -0000
Received: from mail-ob0-f180.google.com (HELO mail-ob0-f180.google.com)
	(209.85.214.180)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 03:53:53 -0000
Received: by mail-ob0-f180.google.com with SMTP id wp4so3138715obc.25
	for <xen-devel@lists.xenproject.org>;
	Wed, 26 Nov 2014 19:53:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=PJGOCgkcZaDJwFtZUMbzp/XiY2fZIIulmWWPgM/Uh6E=;
	b=SlcSQREnZAU/ONYfTx2o+RRtNl36K5zB2nsjthJTHKhQpKl4rZZUGxAWjyMQIK340S
	Z3UnPibjOZ/OJhO3ny9iolDW0Iq7QyFhb2veI/9kFo9ZO/89vShm67sUfvMl8uGfaMkm
	/dpw6x33t57m+pginrsDqnPipqbdsQzNSxGcXGqxi7TkURpaurGgv0l5fZ9zyIQMqIWV
	2LgKpa547RYe2IBJFH9+vQnr8y2UHLb15i0XINorVXxtdoANCOFkOjwGLDtFpYraPZnr
	u/5CGaWui8YaxpXEa7SfeDessHv56byig6equt+bgmBA39HBTisjzdk9++ZwFrOMcDYb
	w+sQ==
X-Gm-Message-State: ALoCoQlQ4v2fceaMGhRkN9J1mdnibrBZWV/288ME9OqxxTGOOOzZRpJYV2GN9eNtUCep0yXVxWI8
X-Received: by 10.60.132.7 with SMTP id oq7mr21815554oeb.61.1417060432223;
	Wed, 26 Nov 2014 19:53:52 -0800 (PST)
Received: from localhost ([2602:306:8312:b1b0:7809:72a4:22fe:f043])
	by mx.google.com with ESMTPSA id a1sm2652260oem.10.2014.11.26.19.53.51
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 26 Nov 2014 19:53:51 -0800 (PST)
Date: Wed, 26 Nov 2014 21:53:50 -0600
From: Seth Forshee <seth.forshee@canonical.com>
To: David Miller <davem@davemloft.net>
Message-ID: <20141127035350.GA10833@ubuntu-mba51>
References: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
	<20141126.122812.223757363894961994.davem@davemloft.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141126.122812.223757363894961994.davem@davemloft.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: zoltan.kiss@linaro.org, eric.dumazet@gmail.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Remove BUGs on paged skb data
 which crosses a page boundary
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 26, 2014 at 12:28:12PM -0500, David Miller wrote:
> From: Seth Forshee <seth.forshee@canonical.com>
> Date: Tue, 25 Nov 2014 20:28:24 -0600
> 
> > These BUGs can be erroneously triggered by frags which refer to
> > tail pages within a compound page. The data in these pages may
> > overrun the hardware page while still being contained within the
> > compound page, but since compound_order() evaluates to 0 for tail
> > pages the assertion fails. The code already iterates through
> > subsequent pages correctly in this scenario, so the BUGs are
> > unnecessary and can be removed.
> > 
> > Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
> > Cc: <stable@vger.kernel.org> # 3.7+
> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> 
> Can I get some Xen developer reviews?

Fwiw this issue was discussed previously and this was the recommended
fix.

 http://article.gmane.org/gmane.linux.kernel/1825381

Since then I got some feedback from a tester that he didn't see any
problems with the BUGs removed (actually replaced with a WARN so I know
that he actually saw the condition which triggered the BUG).

Thanks,
Seth

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 03:54:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 03:54:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtq9T-0005IG-V6; Thu, 27 Nov 2014 03:53:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <seth.forshee@canonical.com>) id 1Xtq9S-0005IB-Sy
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 03:53:54 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	60/57-09842-250A6745; Thu, 27 Nov 2014 03:53:54 +0000
X-Env-Sender: seth.forshee@canonical.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417060432!15660554!1
X-Originating-IP: [209.85.214.180]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2829 invoked from network); 27 Nov 2014 03:53:53 -0000
Received: from mail-ob0-f180.google.com (HELO mail-ob0-f180.google.com)
	(209.85.214.180)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 03:53:53 -0000
Received: by mail-ob0-f180.google.com with SMTP id wp4so3138715obc.25
	for <xen-devel@lists.xenproject.org>;
	Wed, 26 Nov 2014 19:53:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=PJGOCgkcZaDJwFtZUMbzp/XiY2fZIIulmWWPgM/Uh6E=;
	b=SlcSQREnZAU/ONYfTx2o+RRtNl36K5zB2nsjthJTHKhQpKl4rZZUGxAWjyMQIK340S
	Z3UnPibjOZ/OJhO3ny9iolDW0Iq7QyFhb2veI/9kFo9ZO/89vShm67sUfvMl8uGfaMkm
	/dpw6x33t57m+pginrsDqnPipqbdsQzNSxGcXGqxi7TkURpaurGgv0l5fZ9zyIQMqIWV
	2LgKpa547RYe2IBJFH9+vQnr8y2UHLb15i0XINorVXxtdoANCOFkOjwGLDtFpYraPZnr
	u/5CGaWui8YaxpXEa7SfeDessHv56byig6equt+bgmBA39HBTisjzdk9++ZwFrOMcDYb
	w+sQ==
X-Gm-Message-State: ALoCoQlQ4v2fceaMGhRkN9J1mdnibrBZWV/288ME9OqxxTGOOOzZRpJYV2GN9eNtUCep0yXVxWI8
X-Received: by 10.60.132.7 with SMTP id oq7mr21815554oeb.61.1417060432223;
	Wed, 26 Nov 2014 19:53:52 -0800 (PST)
Received: from localhost ([2602:306:8312:b1b0:7809:72a4:22fe:f043])
	by mx.google.com with ESMTPSA id a1sm2652260oem.10.2014.11.26.19.53.51
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 26 Nov 2014 19:53:51 -0800 (PST)
Date: Wed, 26 Nov 2014 21:53:50 -0600
From: Seth Forshee <seth.forshee@canonical.com>
To: David Miller <davem@davemloft.net>
Message-ID: <20141127035350.GA10833@ubuntu-mba51>
References: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
	<20141126.122812.223757363894961994.davem@davemloft.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141126.122812.223757363894961994.davem@davemloft.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: zoltan.kiss@linaro.org, eric.dumazet@gmail.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Remove BUGs on paged skb data
 which crosses a page boundary
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Nov 26, 2014 at 12:28:12PM -0500, David Miller wrote:
> From: Seth Forshee <seth.forshee@canonical.com>
> Date: Tue, 25 Nov 2014 20:28:24 -0600
> 
> > These BUGs can be erroneously triggered by frags which refer to
> > tail pages within a compound page. The data in these pages may
> > overrun the hardware page while still being contained within the
> > compound page, but since compound_order() evaluates to 0 for tail
> > pages the assertion fails. The code already iterates through
> > subsequent pages correctly in this scenario, so the BUGs are
> > unnecessary and can be removed.
> > 
> > Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
> > Cc: <stable@vger.kernel.org> # 3.7+
> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> 
> Can I get some Xen developer reviews?

Fwiw this issue was discussed previously and this was the recommended
fix.

 http://article.gmane.org/gmane.linux.kernel/1825381

Since then I got some feedback from a tester that he didn't see any
problems with the BUGs removed (actually replaced with a WARN so I know
that he actually saw the condition which triggered the BUG).

Thanks,
Seth

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 05:02:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 05:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtrDE-0006ho-Bv; Thu, 27 Nov 2014 05:01:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasowang@redhat.com>) id 1XtrDD-0006hU-Jo
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 05:01:51 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	11/EC-02696-E30B6745; Thu, 27 Nov 2014 05:01:50 +0000
X-Env-Sender: jasowang@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417064508!15123908!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27948 invoked from network); 27 Nov 2014 05:01:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 05:01:50 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAR51ZUr027253
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 27 Nov 2014 00:01:35 -0500
Received: from localhost.localdomain (dhcp-14-236.nay.redhat.com
	[10.66.14.236])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAR51TDw004142; Thu, 27 Nov 2014 00:01:31 -0500
Message-ID: <5476B029.4070009@redhat.com>
Date: Thu, 27 Nov 2014 13:01:29 +0800
From: Jason Wang <jasowang@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
	<54741ED7.2060500@redhat.com>
	<alpine.DEB.2.02.1411251249380.2675@kaball.uk.xensource.com>
	<547563E6.2090505@redhat.com>
	<alpine.DEB.2.02.1411261038020.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411261038020.14135@kaball.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com, qemu-devel@nongnu.org,
	xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 11/26/2014 06:53 PM, Stefano Stabellini wrote:
> On Wed, 26 Nov 2014, Jason Wang wrote:
>> >On 11/25/2014 09:53 PM, Stefano Stabellini wrote:
>>> > >On Tue, 25 Nov 2014, Jason Wang wrote:
>>>> > >>On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
>>>>> > >>>On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>>>>> > >>>>On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>>>>>> > >>>>>CC'ing Paolo.
>>>>>>> > >>>>>
>>>>>>> > >>>>>
>>>>>>> > >>>>>Wen,
>>>>>>> > >>>>>thanks for the logs.
>>>>>>> > >>>>>
>>>>>>> > >>>>>I investigated a little bit and it seems to me that the bug occurs when
>>>>>>> > >>>>>QEMU tries to unmap only a portion of a memory region previously mapped.
>>>>>>> > >>>>>That doesn't work with xen-mapcache.
>>>>>>> > >>>>>
>>>>>>> > >>>>>See these logs for example:
>>>>>>> > >>>>>
>>>>>>> > >>>>>DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
>>>>>>> > >>>>>DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>>>>>> > >>>>Sorry the logs don't quite match, it was supposed to be:
>>>>>> > >>>>
>>>>>> > >>>>DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
>>>>>> > >>>>DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>>>>> > >>>It looks like the problem is caused by iov_discard_front, called by
>>>>> > >>>virtio_net_handle_ctrl. By changing iov_base after the sg has already
>>>>> > >>>been mapped (cpu_physical_memory_map), it causes a leak in the mapping
>>>>> > >>>because the corresponding cpu_physical_memory_unmap will only unmap a
>>>>> > >>>portion of the original sg.  On Xen the problem is worse because
>>>>> > >>>xen-mapcache aborts.
>>>>> > >>>
>>>>> > >>>diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>>>>> > >>>index 2ac6ce5..b2b5c2d 100644
>>>>> > >>>--- a/hw/net/virtio-net.c
>>>>> > >>>+++ b/hw/net/virtio-net.c
>>>>> > >>>@@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>>>>> > >>>      struct iovec *iov;
>>>>> > >>>      unsigned int iov_cnt;
>>>>> > >>>
>>>>> > >>>-    while (virtqueue_pop(vq, &elem)) {
>>>>> > >>>+    while (virtqueue_pop_nomap(vq, &elem)) {
>>>>> > >>>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
>>>>> > >>>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
>>>>> > >>>              error_report("virtio-net ctrl missing headers");
>>>>> > >>>@@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>>>>> > >>>
>>>>> > >>>          iov = elem.out_sg;
>>>>> > >>>          iov_cnt = elem.out_num;
>>>>> > >>>-        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>>>>> > >>>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
>>>>> > >>>+
>>>>> > >>>+        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
>>>>> > >>>+        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
>>>>> > >>>+
>>>>> > >>>+        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>>>> > >>Does this really work?
>>> > >It seems to work here, as in it doesn't crash QEMU and I am able to boot
>>> > >a guest with network. I didn't try any MAC related commands.
>>> > >
>> >
>> >It was because the guest (not a recent kernel?) never issue commands
>> >through control vq.
>> >
>> >We'd better hide the implementation details such as virtqueue_map_sg()
>> >in virtio core instead of letting device call it directly.
>>>> > >>The code in fact skips the location that contains
>>>> > >>virtio_net_ctrl_hdr. And virtio_net_handle_mac() still calls
>>>> > >>iov_discard_front().
>>>> > >>
>>>> > >>How about copy iov to a temp variable and use it in this function?
>>> > >That would only work if I moved the cpu_physical_memory_unmap call
>>> > >outside of virtqueue_fill, so that we can pass different iov to them.
>>> > >We need to unmap the same iov that was previously mapped by
>>> > >virtqueue_pop.
>>> > >
>> >
>> >I mean something like following or just passing the offset of iov to
>> >virtio_net_handle_*().
> Sorry, you are right, your patch works too. I tried something like this
> yesterday but I was confused because even if a crash doesn't happen
> anymore, virtio-net still doesn't work on Xen (it boots but the network
> doesn't work properly within the guest).
> But that seems to be a separate issue and it affects my series too.
>
> A possible problem with this approach is that virtqueue_push is now
> called passing the original iov, not the shortened one.
>
> Are you sure that is OK?

It's ok, except for unmapping, virtqueue_push does not care iov at all.
> If so we can drop my series and use this instead.
>

I will submit a formal patch for this.

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 05:02:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 05:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtrDE-0006ho-Bv; Thu, 27 Nov 2014 05:01:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasowang@redhat.com>) id 1XtrDD-0006hU-Jo
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 05:01:51 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	11/EC-02696-E30B6745; Thu, 27 Nov 2014 05:01:50 +0000
X-Env-Sender: jasowang@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417064508!15123908!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27948 invoked from network); 27 Nov 2014 05:01:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 05:01:50 -0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAR51ZUr027253
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 27 Nov 2014 00:01:35 -0500
Received: from localhost.localdomain (dhcp-14-236.nay.redhat.com
	[10.66.14.236])
	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sAR51TDw004142; Thu, 27 Nov 2014 00:01:31 -0500
Message-ID: <5476B029.4070009@redhat.com>
Date: Thu, 27 Nov 2014 13:01:29 +0800
From: Jason Wang <jasowang@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <547290D7.2020506@cn.fujitsu.com> <5472F1DA.4080508@m2r.biz>
	<5472F980.6030208@cn.fujitsu.com>
	<alpine.DEB.2.02.1411241511220.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241731350.2675@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1411241816040.2675@kaball.uk.xensource.com>
	<54741ED7.2060500@redhat.com>
	<alpine.DEB.2.02.1411251249380.2675@kaball.uk.xensource.com>
	<547563E6.2090505@redhat.com>
	<alpine.DEB.2.02.1411261038020.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411261038020.14135@kaball.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: Wen Congyang <wency@cn.fujitsu.com>, mst@redhat.com, qemu-devel@nongnu.org,
	xen devel <xen-devel@lists.xen.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>, aliguori@amazon.com,
	anthony PERARD <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] virtio leaks cpu mappings,
 was: qemu crash with virtio on Xen domUs (backtrace included)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 11/26/2014 06:53 PM, Stefano Stabellini wrote:
> On Wed, 26 Nov 2014, Jason Wang wrote:
>> >On 11/25/2014 09:53 PM, Stefano Stabellini wrote:
>>> > >On Tue, 25 Nov 2014, Jason Wang wrote:
>>>> > >>On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
>>>>> > >>>On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>>>>> > >>>>On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>>>>>>> > >>>>>CC'ing Paolo.
>>>>>>> > >>>>>
>>>>>>> > >>>>>
>>>>>>> > >>>>>Wen,
>>>>>>> > >>>>>thanks for the logs.
>>>>>>> > >>>>>
>>>>>>> > >>>>>I investigated a little bit and it seems to me that the bug occurs when
>>>>>>> > >>>>>QEMU tries to unmap only a portion of a memory region previously mapped.
>>>>>>> > >>>>>That doesn't work with xen-mapcache.
>>>>>>> > >>>>>
>>>>>>> > >>>>>See these logs for example:
>>>>>>> > >>>>>
>>>>>>> > >>>>>DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb68 len=0xa
>>>>>>> > >>>>>DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>>>>>> > >>>>Sorry the logs don't quite match, it was supposed to be:
>>>>>> > >>>>
>>>>>> > >>>>DEBUG address_space_map phys_addr=78ed8b44 vaddr=7fab50afbb64 len=0xa
>>>>>> > >>>>DEBUG address_space_unmap vaddr=7fab50afbb68 len=0x6
>>>>> > >>>It looks like the problem is caused by iov_discard_front, called by
>>>>> > >>>virtio_net_handle_ctrl. By changing iov_base after the sg has already
>>>>> > >>>been mapped (cpu_physical_memory_map), it causes a leak in the mapping
>>>>> > >>>because the corresponding cpu_physical_memory_unmap will only unmap a
>>>>> > >>>portion of the original sg.  On Xen the problem is worse because
>>>>> > >>>xen-mapcache aborts.
>>>>> > >>>
>>>>> > >>>diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>>>>> > >>>index 2ac6ce5..b2b5c2d 100644
>>>>> > >>>--- a/hw/net/virtio-net.c
>>>>> > >>>+++ b/hw/net/virtio-net.c
>>>>> > >>>@@ -775,7 +775,7 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>>>>> > >>>      struct iovec *iov;
>>>>> > >>>      unsigned int iov_cnt;
>>>>> > >>>
>>>>> > >>>-    while (virtqueue_pop(vq, &elem)) {
>>>>> > >>>+    while (virtqueue_pop_nomap(vq, &elem)) {
>>>>> > >>>          if (iov_size(elem.in_sg, elem.in_num) < sizeof(status) ||
>>>>> > >>>              iov_size(elem.out_sg, elem.out_num) < sizeof(ctrl)) {
>>>>> > >>>              error_report("virtio-net ctrl missing headers");
>>>>> > >>>@@ -784,8 +784,12 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>>>>> > >>>
>>>>> > >>>          iov = elem.out_sg;
>>>>> > >>>          iov_cnt = elem.out_num;
>>>>> > >>>-        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>>>>> > >>>          iov_discard_front(&iov, &iov_cnt, sizeof(ctrl));
>>>>> > >>>+
>>>>> > >>>+        virtqueue_map_sg(elem.in_sg, elem.in_addr, elem.in_num, 1);
>>>>> > >>>+        virtqueue_map_sg(elem.out_sg, elem.out_addr, elem.out_num, 0);
>>>>> > >>>+
>>>>> > >>>+        s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
>>>> > >>Does this really work?
>>> > >It seems to work here, as in it doesn't crash QEMU and I am able to boot
>>> > >a guest with network. I didn't try any MAC related commands.
>>> > >
>> >
>> >It was because the guest (not a recent kernel?) never issue commands
>> >through control vq.
>> >
>> >We'd better hide the implementation details such as virtqueue_map_sg()
>> >in virtio core instead of letting device call it directly.
>>>> > >>The code in fact skips the location that contains
>>>> > >>virtio_net_ctrl_hdr. And virtio_net_handle_mac() still calls
>>>> > >>iov_discard_front().
>>>> > >>
>>>> > >>How about copy iov to a temp variable and use it in this function?
>>> > >That would only work if I moved the cpu_physical_memory_unmap call
>>> > >outside of virtqueue_fill, so that we can pass different iov to them.
>>> > >We need to unmap the same iov that was previously mapped by
>>> > >virtqueue_pop.
>>> > >
>> >
>> >I mean something like following or just passing the offset of iov to
>> >virtio_net_handle_*().
> Sorry, you are right, your patch works too. I tried something like this
> yesterday but I was confused because even if a crash doesn't happen
> anymore, virtio-net still doesn't work on Xen (it boots but the network
> doesn't work properly within the guest).
> But that seems to be a separate issue and it affects my series too.
>
> A possible problem with this approach is that virtqueue_push is now
> called passing the original iov, not the shortened one.
>
> Are you sure that is OK?

It's ok, except for unmapping, virtqueue_push does not care iov at all.
> If so we can drop my series and use this instead.
>

I will submit a formal patch for this.

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 05:29:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 05:29:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtrdp-0007Bx-Sm; Thu, 27 Nov 2014 05:29:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xtrdn-0007Bs-Lw
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 05:29:20 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C2/7A-22737-EA6B6745; Thu, 27 Nov 2014 05:29:18 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417066155!13596058!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17349 invoked from network); 27 Nov 2014 05:29:16 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 05:29:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1417066153; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=UIHXYYPV27Ixix/yNZKAu5Dy8qA74M9KELzcJNhfZ8I=;
	b=4vnfMS67LuZkZ19Bv34ePL9I7g12vB5NiPSKD3kBpa9QO1f/RFCkvn3sROgaZQPl7Au4oBSn2jBGUO/BWK38NznW7U5VgGYgnZGcYpYpHyGhq5v90g1QVq8ub0opfYyQMPvpf3rTO9et/Lou07enLsoeJf20iAaac0Kv+B5Np1U=
Received: from [10.0.0.112] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Wed, 26 Nov 2014 21:29:12 -0800
	id 000000000003048D.5476B6A9.000071E3
Message-ID: <5476B6A8.4060706@ihonk.com>
Date: Wed, 26 Nov 2014 21:29:12 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
	<54746F59020000780004A9E9@mail.emea.novell.com>
In-Reply-To: <54746F59020000780004A9E9@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 03:00 AM, Jan Beulich wrote:
> Okay, so it's not really the mwait-idle driver causing the regression,
> but it is C-state related. Hence we're now down to seeing whether all
> or just the deeper C states are affected, i.e. I now need to ask you
> to play with "max_cstate=". For that you'll have to remember that the
> option's effect differs between the ACPI and the MWAIT idle drivers.
> In the spirit of bisection I'd suggest using "max_cstate=2" first no
> matter which of the two scenarios you pick. If that still hangs,
> "max_cstate=1" obviously is the only other thing to try. Should that
> not hang (and you left out "mwait-idle=0"), trying "max_cstate=3"
> in that same scenario would be the other case to check.
>
> No need for 'd' and 'a' output for the time being, but 'c' output would
> be much appreciated for all cases where you observe hangs.
>

Okay, working through that now. I tried max_cstate=2 and got no hangs, 
whether with or without mwait-idle=0. However, I was puzzled by this:

(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:             C0
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[12219860] method[  FFH] 
duration[1190961948551]
(XEN)     C2:   type[C1] latency[010] usage[10205554] method[  FFH] 
duration[2015393965907]
(XEN)     C3:   type[C2] latency[020] usage[50926286] method[  FFH] 
duration[30527997858148]
(XEN)    *C0:   usage[73351700] duration[9974627547595]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
(XEN) CC3[28794734145697] CC6[0] CC7[0]
(XEN) ==cpu1==
(XEN) active state:             C3
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[10699950] method[  FFH] 
duration[1141422044112]
(XEN)     C2:   type[C1] latency[010] usage[06382904] method[  FFH] 
duration[1329739264322]
(XEN)    *C3:   type[C2] latency[020] usage[44630764] method[  FFH] 
duration[31676618425954]
(XEN)     C0:   usage[61713618] duration[9561201640320]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
(XEN) CC3[30066495105056] CC6[0] CC7[0]
(XEN) ==cpu2==
(XEN) active state:             C3
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[10829791] method[  FFH] 
duration[1145244102917]
(XEN)     C2:   type[C1] latency[010] usage[06392468] method[  FFH] 
duration[1330830147023]
(XEN)    *C3:   type[C2] latency[020] usage[44705668] method[  FFH] 
duration[31741190985486]
(XEN)     C0:   usage[61927927] duration[9491716216846]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
(XEN) CC3[30117696095715] CC6[0] CC7[0]
(XEN) ==cpu3==
(XEN) active state:             C3
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[10692336] method[  FFH] 
duration[1144876437514]
(XEN)     C2:   type[C1] latency[010] usage[06394051] method[  FFH] 
duration[1333961503379]
(XEN)    *C3:   type[C2] latency[020] usage[44744178] method[  FFH] 
duration[31803488799434]
(XEN)     C0:   usage[61830565] duration[9426654792908]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
(XEN) CC3[30191557548300] CC6[0] CC7[0]
(XEN) ==cpu4==
(XEN) active state:             C3
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[10746634] method[  FFH] 
duration[1144044534459]
(XEN)     C2:   type[C1] latency[010] usage[06444054] method[  FFH] 
duration[1340637424913]
(XEN)    *C3:   type[C2] latency[020] usage[44690901] method[  FFH] 
duration[31663207165902]
(XEN)     C0:   usage[61881589] duration[9561092487876]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
(XEN) CC3[30049235012919] CC6[0] CC7[0]
(XEN) ==cpu5==
(XEN) active state:             C3
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[10694684] method[  FFH] 
duration[1140625901110]
(XEN)     C2:   type[C1] latency[010] usage[06461563] method[  FFH] 
duration[1342115502967]
(XEN)    *C3:   type[C2] latency[020] usage[44834522] method[  FFH] 
duration[31719560664023]
(XEN)     C0:   usage[61990769] duration[9506679619986]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]

Why would some of the cores be in C3 even though they list max_cstate as C2?

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 05:29:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 05:29:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtrdp-0007Bx-Sm; Thu, 27 Nov 2014 05:29:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1Xtrdn-0007Bs-Lw
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 05:29:20 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C2/7A-22737-EA6B6745; Thu, 27 Nov 2014 05:29:18 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417066155!13596058!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17349 invoked from network); 27 Nov 2014 05:29:16 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 05:29:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1417066153; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=UIHXYYPV27Ixix/yNZKAu5Dy8qA74M9KELzcJNhfZ8I=;
	b=4vnfMS67LuZkZ19Bv34ePL9I7g12vB5NiPSKD3kBpa9QO1f/RFCkvn3sROgaZQPl7Au4oBSn2jBGUO/BWK38NznW7U5VgGYgnZGcYpYpHyGhq5v90g1QVq8ub0opfYyQMPvpf3rTO9et/Lou07enLsoeJf20iAaac0Kv+B5Np1U=
Received: from [10.0.0.112] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Wed, 26 Nov 2014 21:29:12 -0800
	id 000000000003048D.5476B6A9.000071E3
Message-ID: <5476B6A8.4060706@ihonk.com>
Date: Wed, 26 Nov 2014 21:29:12 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
	<54746F59020000780004A9E9@mail.emea.novell.com>
In-Reply-To: <54746F59020000780004A9E9@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/25/2014 03:00 AM, Jan Beulich wrote:
> Okay, so it's not really the mwait-idle driver causing the regression,
> but it is C-state related. Hence we're now down to seeing whether all
> or just the deeper C states are affected, i.e. I now need to ask you
> to play with "max_cstate=". For that you'll have to remember that the
> option's effect differs between the ACPI and the MWAIT idle drivers.
> In the spirit of bisection I'd suggest using "max_cstate=2" first no
> matter which of the two scenarios you pick. If that still hangs,
> "max_cstate=1" obviously is the only other thing to try. Should that
> not hang (and you left out "mwait-idle=0"), trying "max_cstate=3"
> in that same scenario would be the other case to check.
>
> No need for 'd' and 'a' output for the time being, but 'c' output would
> be much appreciated for all cases where you observe hangs.
>

Okay, working through that now. I tried max_cstate=2 and got no hangs, 
whether with or without mwait-idle=0. However, I was puzzled by this:

(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:             C0
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[12219860] method[  FFH] 
duration[1190961948551]
(XEN)     C2:   type[C1] latency[010] usage[10205554] method[  FFH] 
duration[2015393965907]
(XEN)     C3:   type[C2] latency[020] usage[50926286] method[  FFH] 
duration[30527997858148]
(XEN)    *C0:   usage[73351700] duration[9974627547595]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
(XEN) CC3[28794734145697] CC6[0] CC7[0]
(XEN) ==cpu1==
(XEN) active state:             C3
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[10699950] method[  FFH] 
duration[1141422044112]
(XEN)     C2:   type[C1] latency[010] usage[06382904] method[  FFH] 
duration[1329739264322]
(XEN)    *C3:   type[C2] latency[020] usage[44630764] method[  FFH] 
duration[31676618425954]
(XEN)     C0:   usage[61713618] duration[9561201640320]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
(XEN) CC3[30066495105056] CC6[0] CC7[0]
(XEN) ==cpu2==
(XEN) active state:             C3
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[10829791] method[  FFH] 
duration[1145244102917]
(XEN)     C2:   type[C1] latency[010] usage[06392468] method[  FFH] 
duration[1330830147023]
(XEN)    *C3:   type[C2] latency[020] usage[44705668] method[  FFH] 
duration[31741190985486]
(XEN)     C0:   usage[61927927] duration[9491716216846]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
(XEN) CC3[30117696095715] CC6[0] CC7[0]
(XEN) ==cpu3==
(XEN) active state:             C3
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[10692336] method[  FFH] 
duration[1144876437514]
(XEN)     C2:   type[C1] latency[010] usage[06394051] method[  FFH] 
duration[1333961503379]
(XEN)    *C3:   type[C2] latency[020] usage[44744178] method[  FFH] 
duration[31803488799434]
(XEN)     C0:   usage[61830565] duration[9426654792908]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
(XEN) CC3[30191557548300] CC6[0] CC7[0]
(XEN) ==cpu4==
(XEN) active state:             C3
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[10746634] method[  FFH] 
duration[1144044534459]
(XEN)     C2:   type[C1] latency[010] usage[06444054] method[  FFH] 
duration[1340637424913]
(XEN)    *C3:   type[C2] latency[020] usage[44690901] method[  FFH] 
duration[31663207165902]
(XEN)     C0:   usage[61881589] duration[9561092487876]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
(XEN) CC3[30049235012919] CC6[0] CC7[0]
(XEN) ==cpu5==
(XEN) active state:             C3
(XEN) max_cstate:               C2
(XEN) states:
(XEN)     C1:   type[C1] latency[003] usage[10694684] method[  FFH] 
duration[1140625901110]
(XEN)     C2:   type[C1] latency[010] usage[06461563] method[  FFH] 
duration[1342115502967]
(XEN)    *C3:   type[C2] latency[020] usage[44834522] method[  FFH] 
duration[31719560664023]
(XEN)     C0:   usage[61990769] duration[9506679619986]
(XEN) max=0 pwr=0 urg=0 nxt=0
(XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]

Why would some of the cores be in C3 even though they list max_cstate as C2?

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 05:40:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 05:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtroa-0007Sx-4a; Thu, 27 Nov 2014 05:40:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtroZ-0007Ss-GS
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 05:40:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E8/60-09842-A49B6745; Thu, 27 Nov 2014 05:40:26 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417066825!15298734!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5374 invoked from network); 27 Nov 2014 05:40:26 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 05:40:26 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4C856AC54;
	Thu, 27 Nov 2014 05:40:25 +0000 (UTC)
Message-ID: <5476B947.9040201@suse.com>
Date: Thu, 27 Nov 2014 06:40:23 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Daniel Kiper <daniel.kiper@oracle.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com>
	<20141126143027.GA8735@laptop.dumpdata.com>
	<5475E892.5060400@suse.com>
	<20141127001938.GJ28040@olila.local.net-space.pl>
In-Reply-To: <20141127001938.GJ28040@olila.local.net-space.pl>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/27/2014 01:19 AM, Daniel Kiper wrote:
> On Wed, Nov 26, 2014 at 03:49:54PM +0100, Juergen Gross wrote:
>> On 11/26/2014 03:30 PM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
>>>> On 11/26/2014 01:41 PM, Andrew Cooper wrote:
>>>>> On 26/11/14 12:15, Juergen Gross wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I tried to enable kdump on my test-machine with actual xen-unstable
>>>>>> booting via EFI.
>>>>>>
>>>>>> The kdump kernel is not being loaded.
>>>>>>
>>>>>> I'm seeing the memory being reserved:
>>>>>>
>>>>>> (XEN) EFI RAM map:
>>>>>> (XEN)  0000000000000000 - 00000000000a0000 (usable)
>>>>>> (XEN)  0000000000100000 - 000000004bc00000 (usable)
>>>>>> (XEN)  000000004bc00000 - 000000005bc00000 (reserved)
>>>>>> (XEN)  000000005bc00000 - 000000005bfec000 (usable)
>>>>>> (XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
>>>>>> (XEN)  000000005c000000 - 000000006a429000 (usable)
>>>>>> (XEN)  000000006a429000 - 000000006a42c000 (reserved)
>>>>>> (XEN)  000000006a42c000 - 000000006a7a2000 (usable)
>>>>>> (XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
>>>>>> (XEN)  000000006a7a8000 - 000000006a987000 (usable)
>>>>>> (XEN)  000000006a987000 - 000000006a98d000 (reserved)
>>>>>> (XEN)  000000006a98d000 - 000000006aa63000 (usable)
>>>>>> (XEN)  000000006aa63000 - 000000006aa73000 (reserved)
>>>>>> (XEN)  000000006aa73000 - 000000006ac60000 (usable)
>>>>>> (XEN)  000000006ac60000 - 000000006ac61000 (reserved)
>>>>>> (XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
>>>>>> (XEN)  000000006ac9b000 - 000000006acac000 (reserved)
>>>>>> (XEN)  000000006acac000 - 000000006acad000 (usable)
>>>>>> (XEN)  000000006acad000 - 000000006acae000 (reserved)
>>>>>> (XEN)  000000006acae000 - 000000007189c000 (usable)
>>>>>> (XEN)  000000007189c000 - 0000000071946000 (reserved)
>>>>>> (XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
>>>>>> (XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
>>>>>> (XEN)  0000000072db2000 - 0000000072edc000 (usable)
>>>>>> (XEN)  0000000080000000 - 0000000090000000 (reserved)
>>>>>> (XEN)  0000000100000000 - 0000002080000000 (usable)
>>>>>> (XEN) Kdump: 256MB (262144kB) at 0x206dff4000
>>>>>>
>>>>>> I'd expect this area being visible in the efi or e820 map presented to
>>>>>> dom0, but I can't see anything:
>>>>>
>>>>> This is expected.  The dom0 kernel now has nothing at all do with
>>>>> loading crash kernel.  Loading happens via hypercalls straight from the
>>>>> kexec utility.
>>>>>
>>>>> You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
>>>>> support, but it should JustWork.
>>>>
>>>> Should. I have kexec 2.0.5 with Xen support. Doesn't work:
>>>>
>>>> Excerpt form strace:
>>>>
>>>> "sysctl operation failed -- need to rebuild the user-space tool set?\n"
>>>>
>>>> My personal translation: kexec is tightly coupled to the Xen version
>>>> (this one was built against Xen 4.4.1 AFAIK).
>>>
>>> Odd, the hypercall interface did not change in Xen 4.5 for kexec?
>>>
>>> Perhaps it is making some other hypercalls that are tied in
>>> to the version of Xen (like sysctl ones?).
>>
>> The error message above suggests that, yes. :-)
>>
>> Grepping for xc_ in kexec sources finds e.g. xc_get_max_cpus() which
>> in turn calls xc_physinfo() doing a sysctl.
>>
>>>
>>> I presume with recompiling it works?
>>
>> Didn't check up to now, but I think it should.
>
> Are you sure that kexec-tools configure script discovered
> Xen headers and development libraries? Please check that.
> "ldd kexec" is your friend.

Aah, here is the problem: The kexec installed on my test system has been
linked statically with libxenctrl to be usable on non-Xen systems, too.

The proper solution, however, would have been to check for running on
Xen dynamically and then load the current library via dlopen().

For now I'll just rebuild kexec.

I put above on my todo list. As I expect to modify kexec in the future
for support of the linear mapped p2m list I'll do the dlopen() stuff
then.

>
> Do not forget to use kexec-tools version 2.0.5 or newer.
>
>>>>
>>>> Perhaps we should add kexec to the tools directory?
>>>
>>> Gosh no.
>>
>> Oops, did I forget the smiley? ;-)
>>
>> I think we should look what kexec is really needing and put this in a
>> stable interface set (perhaps an own library?). This might require some
>
> David did the work.

Okay.

>
>> new sub functions of e.g. the KEXEC hypercall, but this is better than
>> making kexec depending on the Xen version.
>
> Maybe we need some things which are specific for EFI platforms. I am
> going to investigate that after finishing EFI + multiboot2 work.
> Probably it will happen at the beginning of next year.

I'll come back to you when I'm going to change kexec.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 05:40:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 05:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtroa-0007Sx-4a; Thu, 27 Nov 2014 05:40:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XtroZ-0007Ss-GS
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 05:40:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E8/60-09842-A49B6745; Thu, 27 Nov 2014 05:40:26 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417066825!15298734!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5374 invoked from network); 27 Nov 2014 05:40:26 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 05:40:26 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4C856AC54;
	Thu, 27 Nov 2014 05:40:25 +0000 (UTC)
Message-ID: <5476B947.9040201@suse.com>
Date: Thu, 27 Nov 2014 06:40:23 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Daniel Kiper <daniel.kiper@oracle.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com>
	<20141126143027.GA8735@laptop.dumpdata.com>
	<5475E892.5060400@suse.com>
	<20141127001938.GJ28040@olila.local.net-space.pl>
In-Reply-To: <20141127001938.GJ28040@olila.local.net-space.pl>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/27/2014 01:19 AM, Daniel Kiper wrote:
> On Wed, Nov 26, 2014 at 03:49:54PM +0100, Juergen Gross wrote:
>> On 11/26/2014 03:30 PM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
>>>> On 11/26/2014 01:41 PM, Andrew Cooper wrote:
>>>>> On 26/11/14 12:15, Juergen Gross wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I tried to enable kdump on my test-machine with actual xen-unstable
>>>>>> booting via EFI.
>>>>>>
>>>>>> The kdump kernel is not being loaded.
>>>>>>
>>>>>> I'm seeing the memory being reserved:
>>>>>>
>>>>>> (XEN) EFI RAM map:
>>>>>> (XEN)  0000000000000000 - 00000000000a0000 (usable)
>>>>>> (XEN)  0000000000100000 - 000000004bc00000 (usable)
>>>>>> (XEN)  000000004bc00000 - 000000005bc00000 (reserved)
>>>>>> (XEN)  000000005bc00000 - 000000005bfec000 (usable)
>>>>>> (XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
>>>>>> (XEN)  000000005c000000 - 000000006a429000 (usable)
>>>>>> (XEN)  000000006a429000 - 000000006a42c000 (reserved)
>>>>>> (XEN)  000000006a42c000 - 000000006a7a2000 (usable)
>>>>>> (XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
>>>>>> (XEN)  000000006a7a8000 - 000000006a987000 (usable)
>>>>>> (XEN)  000000006a987000 - 000000006a98d000 (reserved)
>>>>>> (XEN)  000000006a98d000 - 000000006aa63000 (usable)
>>>>>> (XEN)  000000006aa63000 - 000000006aa73000 (reserved)
>>>>>> (XEN)  000000006aa73000 - 000000006ac60000 (usable)
>>>>>> (XEN)  000000006ac60000 - 000000006ac61000 (reserved)
>>>>>> (XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
>>>>>> (XEN)  000000006ac9b000 - 000000006acac000 (reserved)
>>>>>> (XEN)  000000006acac000 - 000000006acad000 (usable)
>>>>>> (XEN)  000000006acad000 - 000000006acae000 (reserved)
>>>>>> (XEN)  000000006acae000 - 000000007189c000 (usable)
>>>>>> (XEN)  000000007189c000 - 0000000071946000 (reserved)
>>>>>> (XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
>>>>>> (XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
>>>>>> (XEN)  0000000072db2000 - 0000000072edc000 (usable)
>>>>>> (XEN)  0000000080000000 - 0000000090000000 (reserved)
>>>>>> (XEN)  0000000100000000 - 0000002080000000 (usable)
>>>>>> (XEN) Kdump: 256MB (262144kB) at 0x206dff4000
>>>>>>
>>>>>> I'd expect this area being visible in the efi or e820 map presented to
>>>>>> dom0, but I can't see anything:
>>>>>
>>>>> This is expected.  The dom0 kernel now has nothing at all do with
>>>>> loading crash kernel.  Loading happens via hypercalls straight from the
>>>>> kexec utility.
>>>>>
>>>>> You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
>>>>> support, but it should JustWork.
>>>>
>>>> Should. I have kexec 2.0.5 with Xen support. Doesn't work:
>>>>
>>>> Excerpt form strace:
>>>>
>>>> "sysctl operation failed -- need to rebuild the user-space tool set?\n"
>>>>
>>>> My personal translation: kexec is tightly coupled to the Xen version
>>>> (this one was built against Xen 4.4.1 AFAIK).
>>>
>>> Odd, the hypercall interface did not change in Xen 4.5 for kexec?
>>>
>>> Perhaps it is making some other hypercalls that are tied in
>>> to the version of Xen (like sysctl ones?).
>>
>> The error message above suggests that, yes. :-)
>>
>> Grepping for xc_ in kexec sources finds e.g. xc_get_max_cpus() which
>> in turn calls xc_physinfo() doing a sysctl.
>>
>>>
>>> I presume with recompiling it works?
>>
>> Didn't check up to now, but I think it should.
>
> Are you sure that kexec-tools configure script discovered
> Xen headers and development libraries? Please check that.
> "ldd kexec" is your friend.

Aah, here is the problem: The kexec installed on my test system has been
linked statically with libxenctrl to be usable on non-Xen systems, too.

The proper solution, however, would have been to check for running on
Xen dynamically and then load the current library via dlopen().

For now I'll just rebuild kexec.

I put above on my todo list. As I expect to modify kexec in the future
for support of the linear mapped p2m list I'll do the dlopen() stuff
then.

>
> Do not forget to use kexec-tools version 2.0.5 or newer.
>
>>>>
>>>> Perhaps we should add kexec to the tools directory?
>>>
>>> Gosh no.
>>
>> Oops, did I forget the smiley? ;-)
>>
>> I think we should look what kexec is really needing and put this in a
>> stable interface set (perhaps an own library?). This might require some
>
> David did the work.

Okay.

>
>> new sub functions of e.g. the KEXEC hypercall, but this is better than
>> making kexec depending on the Xen version.
>
> Maybe we need some things which are specific for EFI platforms. I am
> going to investigate that after finishing EFI + multiboot2 work.
> Probably it will happen at the beginning of next year.

I'll come back to you when I'm going to change kexec.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 06:37:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 06:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtsgw-00006c-2N; Thu, 27 Nov 2014 06:36:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xtsgu-00006X-6v
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 06:36:36 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	74/23-14214-376C6745; Thu, 27 Nov 2014 06:36:35 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417070194!13577887!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15867 invoked from network); 27 Nov 2014 06:36:34 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 06:36:34 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 426AAAAF1;
	Thu, 27 Nov 2014 06:36:33 +0000 (UTC)
Message-ID: <5476C66F.5040308@suse.com>
Date: Thu, 27 Nov 2014 07:36:31 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>, 
	david.vrabel@citrix.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
In-Reply-To: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Jan Beulich <JBeulich@suse.com>,
	Borislav Petkov <bp@suse.de>, Olaf Hering <ohering@suse.de>
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
 hypercall when non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Some folks had reported that some xen hypercalls take a long time
> to complete when issued from the userspace private ioctl mechanism,
> this can happen for instance with some hypercalls that have many
> sub-operations, this can happen for instance on hypercalls that use
> multi-call feature whereby Xen lets one hypercall batch out a series
> of other hypercalls on the hypervisor. At times such hypercalls can
> even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
> 120 seconds), this a non-issue issue on preemptible kernels though as
> the kernel may deschedule such long running tasks. Xen for instance
> supports multicalls to be preempted as well, this is what Xen calls
> continuation (see xen commit 42217cbc5b which introduced this [0]).
> On systems without CONFIG_PREEMPT though -- a kernel with voluntary
> or no preemption -- a long running hypercall will not be descheduled
> until the hypercall is complete and the ioctl returns to user space.
>
> To help with this David had originally implemented support for use
> of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
> solution never went upstream though and upon review to help refactor
> this I've concluded that usage of preempt_schedule_irq() would be
> a bit abussive of existing APIs -- for a few reasons:
>
> 0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels
>
> 1) we want try to consider solutions that might work for other
>     hypervisors for this same problem, and identify it its an issue
>     even present on other hypervisors or if this is a self
>     inflicted architectural issue caused by use of multicalls
>
> 2) there is no documentation or profiling of the exact hypercalls
>     that were causing these issues, nor do we have any context
>     to help evaluate this any further
>
> I at least checked with kvm folks and it seems hypercall preemption
> is not needed there. We can survey other hypervisors...
>
> If 'something like preemption' is needed then CONFIG_PREEMPT
> should just be enabled and encouraged, it seems we want to
> encourage CONFIG_PREEMPT on xen, specially when multicalls are
> used. In the meantime this tries to address a solution to help
> xen on non CONFIG_PREEMPT kernels.
>
> One option tested and evaluated was to put private hypercalls in
> process context, however this would introduce complexities such
> originating hypercalls from different contexts. Current xen
> hypercall callback handlers would need to be changed per architecture,
> for instance, we'd also incur the cost of switching states from
> user / kernel (this cost is also present if preempt_schedule_irq()
> is used). There may be other issues which could be introduced with
> this strategy as well. The simplest *shared* alternative is instead
> to just explicitly schedule() at the end of a private hypercall on non
> preempt kernels. This forces our private hypercall call mechanism
> to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
> more context switch but keeps the private hypercall context intact.
>
> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
> [1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
>
> Cc: Davidlohr Bueso <dbueso@suse.de>
> Cc: Joerg Roedel <jroedel@suse.de>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Juergen Gross <JGross@suse.com>
> Cc: Olaf Hering <ohering@suse.de>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>   drivers/xen/privcmd.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 569a13b..e29edba 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
>   			   hypercall.arg[0], hypercall.arg[1],
>   			   hypercall.arg[2], hypercall.arg[3],
>   			   hypercall.arg[4]);
> +#ifndef CONFIG_PREEMPT
> +	schedule();
> +#endif
>
>   	return ret;
>   }
>

Sorry, I don't think this will solve anything. You're calling schedule()
right after the long running hypercall just nanoseconds before returning
to the user.

I suppose you were mislead by the "int 0x82" in [0]. This is the
hypercall from the kernel into the hypervisor, e.g. inside of
privcmd_call().


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 06:37:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 06:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtsgw-00006c-2N; Thu, 27 Nov 2014 06:36:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xtsgu-00006X-6v
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 06:36:36 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	74/23-14214-376C6745; Thu, 27 Nov 2014 06:36:35 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417070194!13577887!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15867 invoked from network); 27 Nov 2014 06:36:34 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 06:36:34 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 426AAAAF1;
	Thu, 27 Nov 2014 06:36:33 +0000 (UTC)
Message-ID: <5476C66F.5040308@suse.com>
Date: Thu, 27 Nov 2014 07:36:31 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>, 
	david.vrabel@citrix.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
In-Reply-To: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Jan Beulich <JBeulich@suse.com>,
	Borislav Petkov <bp@suse.de>, Olaf Hering <ohering@suse.de>
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
 hypercall when non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Some folks had reported that some xen hypercalls take a long time
> to complete when issued from the userspace private ioctl mechanism,
> this can happen for instance with some hypercalls that have many
> sub-operations, this can happen for instance on hypercalls that use
> multi-call feature whereby Xen lets one hypercall batch out a series
> of other hypercalls on the hypervisor. At times such hypercalls can
> even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
> 120 seconds), this a non-issue issue on preemptible kernels though as
> the kernel may deschedule such long running tasks. Xen for instance
> supports multicalls to be preempted as well, this is what Xen calls
> continuation (see xen commit 42217cbc5b which introduced this [0]).
> On systems without CONFIG_PREEMPT though -- a kernel with voluntary
> or no preemption -- a long running hypercall will not be descheduled
> until the hypercall is complete and the ioctl returns to user space.
>
> To help with this David had originally implemented support for use
> of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
> solution never went upstream though and upon review to help refactor
> this I've concluded that usage of preempt_schedule_irq() would be
> a bit abussive of existing APIs -- for a few reasons:
>
> 0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels
>
> 1) we want try to consider solutions that might work for other
>     hypervisors for this same problem, and identify it its an issue
>     even present on other hypervisors or if this is a self
>     inflicted architectural issue caused by use of multicalls
>
> 2) there is no documentation or profiling of the exact hypercalls
>     that were causing these issues, nor do we have any context
>     to help evaluate this any further
>
> I at least checked with kvm folks and it seems hypercall preemption
> is not needed there. We can survey other hypervisors...
>
> If 'something like preemption' is needed then CONFIG_PREEMPT
> should just be enabled and encouraged, it seems we want to
> encourage CONFIG_PREEMPT on xen, specially when multicalls are
> used. In the meantime this tries to address a solution to help
> xen on non CONFIG_PREEMPT kernels.
>
> One option tested and evaluated was to put private hypercalls in
> process context, however this would introduce complexities such
> originating hypercalls from different contexts. Current xen
> hypercall callback handlers would need to be changed per architecture,
> for instance, we'd also incur the cost of switching states from
> user / kernel (this cost is also present if preempt_schedule_irq()
> is used). There may be other issues which could be introduced with
> this strategy as well. The simplest *shared* alternative is instead
> to just explicitly schedule() at the end of a private hypercall on non
> preempt kernels. This forces our private hypercall call mechanism
> to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
> more context switch but keeps the private hypercall context intact.
>
> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
> [1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
>
> Cc: Davidlohr Bueso <dbueso@suse.de>
> Cc: Joerg Roedel <jroedel@suse.de>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Juergen Gross <JGross@suse.com>
> Cc: Olaf Hering <ohering@suse.de>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>   drivers/xen/privcmd.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 569a13b..e29edba 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
>   			   hypercall.arg[0], hypercall.arg[1],
>   			   hypercall.arg[2], hypercall.arg[3],
>   			   hypercall.arg[4]);
> +#ifndef CONFIG_PREEMPT
> +	schedule();
> +#endif
>
>   	return ret;
>   }
>

Sorry, I don't think this will solve anything. You're calling schedule()
right after the long running hypercall just nanoseconds before returning
to the user.

I suppose you were mislead by the "int 0x82" in [0]. This is the
hypercall from the kernel into the hypervisor, e.g. inside of
privcmd_call().


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:35:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:35:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtuXE-0002hd-RG; Thu, 27 Nov 2014 08:34:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yanghy@cn.fujitsu.com>) id 1XtuXD-0002hW-TG
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:34:44 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	52/1B-02697-322E6745; Thu, 27 Nov 2014 08:34:43 +0000
X-Env-Sender: yanghy@cn.fujitsu.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417077279!13623927!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13860 invoked from network); 27 Nov 2014 08:34:41 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-7.tower-206.messagelabs.com with SMTP;
	27 Nov 2014 08:34:41 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="44070248"
Received: from localhost (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 27 Nov 2014 16:31:23 +0800
Received: from G08CNEXCHPEKD01.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAR8YJ44003095;
	Thu, 27 Nov 2014 16:34:19 +0800
Received: from [10.167.226.223] (10.167.226.223) by
	G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Thu, 27 Nov 2014 16:34:45 +0800
Message-ID: <5476E1F0.5000804@cn.fujitsu.com>
Date: Thu, 27 Nov 2014 16:33:52 +0800
From: Hongyang Yang <yanghy@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel List
	<xen-devel@lists.xen.org>
References: <5474DE5A.2060000@citrix.com>
In-Reply-To: <5474DE5A.2060000@citrix.com>
X-Originating-IP: [10.167.226.223]
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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-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

CgrlnKggMTEvMjYvMjAxNCAwMzo1NCBBTSwgQW5kcmV3IENvb3BlciDlhpnpgZM6Cj4gSGVsbG8s
Cj4KPiBUaGUgcHVycG9zZSBvZiB0aGlzIGVtYWlsIGlzIHRvIHBsYW4gaG93IHRvIHByb2dyZXNz
IHRoZSBtaWdyYXRpb252Mgo+IHNlcmllcyB0aHJvdWdoIHRvIGJlaW5nIG1lcmdlZC4gIEkgYmVs
aWV2ZSBJIGhhdmUgQ0MnZCBldmVyeW9uZSB3aXRoIGEKPiBzcGVjaWZpYyBpbnRlcmVzdCBpbiB0
aGlzIGFyZWEsIGJ1dCBhcG9sb2dpZXMgaWYgSSBoYXZlIG1pc3NlZCBhbnlvbmUuCj4KPiBNaWdy
YXRpb24gdjIgaXMgaW4gZXhjbHVzaXZlIHVzZSBpbiBYZW5TZXJ2ZXIgNi41LiAgV2UgcHJpbWFy
aWx5Cj4gZGV2ZWxvcGVkIG1pZ3JhdGlvbiB2MiBiZWNhdXNlIHdlIG5lZWRlZCBhIDMyYml0IC0+
IDY0Yml0IHRvb2xzdGFjawo+IHVwZ3JhZGUgcGF0aC4gIFRoZSBjb2RlIGhhcyBhbGwgdGhlIGZl
YXR1cmVzIFhlblNlcnZlciBwcmV2aW91c2x5Cj4gc3VwcG9ydGVkLCBhbmQgd2UgY29uc2lkZXIg
aXQgZnVsbHkgYmFrZWQgYW5kIHdpdGhvdXQgYW55IGtub3duIGJ1Z3MsCj4gaW5jbHVkaW5nIHRy
YW5zcGFyZW50IGxlZ2FjeS10by12MiBjb252ZXJzaW9uIG9uIHVwZ3JhZGUuCj4KPiBXZSBkaWQg
ZW5kZWF2b3VyIHRvIGdldCBtaWdyYXRpb24gdjIgaW50byBYZW4gNC41LCBidXQgcmVncmV0dGFi
bHkgdGhpcwo+IGRpZCBub3QgaGFwcGVuLiAgQSBjb25zZXF1ZW5jZSBvZiB0aGlzLCBhbG9uZyB3
aXRoIHRoZSBjb2RlIGJlaW5nIGluCj4gWGVuU2VydmVyIDYuNSwgaXMgdGhhdCB0aGUgd2lyZSBm
b3JtYXQgaXMgbm93IHNldCBpbiBzdG9uZS4gIEx1Y2tpbHksIGl0Cj4gaGFzIGJlZW4gZXhwbGlj
aXRseSBkZXNpZ25lZCB0byBiZSBlYXN5IHRvIGV4dGVuZCBpbiBhIGZvcndhcmQKPiBjb21wYXRp
YmxlIG1hbm9yLCBzbyB0aGlzIGlzIG5vdCBhIHByb2JsZW0gbW92aW5nIGZvcndhcmQuCj4KPiBU
aGUgZXhwZWN0YXRpb24gaXMgdGhhdCB0aGUgbWlncmF0aW9uIHYyIGNvZGUgd2lsbCBjb21wbGV0
ZWx5IHJlcGxhY2UKPiB0aGUgZXhpc3RpbmcgbWlncmF0aW9uIGNvZGUsIHdoaWNoIHdpbGwgaW52
b2x2ZSByZW1vdmluZwo+IHhjX2RvbWFpbl9zYXZlLmMgYW5kIHhjX2RvbWFpbl9yZXN0b3JlLmMs
IGFzIHdlbGwgYXMgYXNzb3J0ZWQgb3RoZXIKPiBvcnBoYW5lZCBjb2RlIGluIGxpYnhlbmN0cmwg
YW5kIGxpYnhlbmd1ZXN0Cj4KPiBUaGVyZSBhcmUgMyBhcmVhcyBvZiBjb25jZXJuIHdoaWNoIGhh
dmUgYmVlbiBpZGVudGlmaWVkIHNvIGZhci4KPgo+IDEpIFRNRU0gc3VwcG9ydAo+Cj4gTWlncmF0
aW9uIHYyIGRvZXNuJ3QgY3VycmVudGx5IGhhdmUgYW55IHRtZW0gbWlncmF0aW9uIHN1cHBvcnQu
ICBUaGUKPiBtYWludGFpbmVycyBoYXZlIGJlZW4gYXNrZWQgd2hldGhlciB0aGV5IGFjdHVhbGx5
IGV4cGVjdCBsZWdhY3kgdG1lbQo+IG1pZ3JhdGlvbiB0byB3b3JrLCBidXQgSSBoYXZlIG5vdCBo
ZWFyZCBhbnkgcmVwbHkgeWV0LiAgQXQgdGhlIHZlcnkKPiBsZWFzdCwgbWlncmF0aW9uIHYyIHRt
ZW0gc3VwcG9ydCB3b3VsZCB3YW50IHNvbWUgbmV3IHRob3VnaHQgcHV0IGludG8KPiB3aXJlIHBy
b3RvY29sLiAgSSBhbSBob3BpbmcgdGhhdCwgYXMgVE1FTSBpcyBzdGlsbCB0ZWNoIHByZXZpZXcg
YW5kCj4gc3RpbGwgaW4gdGhlIHByb2Nlc3Mgb2YgaGF2aW5nIFhTQS0xNSBmaXhlZCwgd29ya2lu
ZyB0bWVtIG1pZ3JhdGlvbiB2Mgo+IGlzIG5vdCBpbnNpc3RlZCBhcyBhIHByZXJlcXVpc2l0ZS4K
Pgo+IDIpIFJlbXVzL0NPTE8gc3VwcG9ydAo+Cj4gTWlncmF0aW9uIHYyIGRvZXNuJ3QgY3VycmVu
dGx5IGhhdmUgYW55IFJlbXVzIHN1cHBvcnQuICBUaGVyZSB3YXMgYQo+IGRyYWZ0IHNlcmllcyB3
aGljaCBhZGRlZCBSZW11cyBzdXBwb3J0LCBhbmQgc2hvd2VkIHRoYXQgaXQgd2FzCj4gcGFydGlj
dWxhcmx5IHNpbXBsZSB0byBhZGQgUmVtdXMgc3VwcG9ydCB0byBtaWdyYXRpb24gdjIuICBJIGlu
dGVncmF0ZWQKPiBzZXZlcmFsIGJ1Z2ZpeGVzIGFzIGEgc2lkZSBlZmZlY3Qgb2YgdGhhdCBzZXJp
ZXMsIGJ1dCB0aGUgYWN0dWFsIFJlbXVzCj4gY29udGVudCBuZWVkZWQgYSByZWZyZXNoLiAgVGhp
cyBnb3QgZGVsYXllZCBiZWhpbmQgdGhlIFJlbXVzIGxpYnhsCj4gZWZmb3J0LiAgSXQgaXMgbXkg
aG9wZSB0aGF0IHRoZSBSZW11cyBtYWludGFpbmVycyBjYW4gcmVmcmVzaCB0aGF0Cj4gc2VyaWVz
IGFuZCBwcm92aWRlIGFzc2lzdGFuY2Ugd2hpbGUgdGVzdGluZy4KClN1cmUsIEknbSBwbGFubmlu
ZyB0byByZWZyZXNoIHRoZSBwYXRjaGVzIGFzIHNvb24gYXMgWGVuIDQuNiBtZXJnZSB3aW5kb3cK
b3BlbmVkLiBBbmQgYWxzbyBnb2luZyB0byBzdGFydCB0aGUgd29yayBvbiBsaWJ4bCBzaWRlIGJl
Y2F1c2UgbGlieGwgcGFydApvZiBtaWdyYXRpb24gdjIgaGFzIGFscmVhZHkgZG9uZShhbHRob3Vn
aCBub3QgZnVsbGx5IGZpbmlzaGVkPykuIEFuZCB3ZQpob3BlIENPTE8gc3VwcG9ydCB3aWxsIGdv
IGludG8gWGVuIDQuNiBhbHNvLgoKPgo+IDMpIExpYnhsIGFuZCB4bCBzdXBwb3J0Cj4KPiBMaWJ4
bCBhbmQgeGwgaGF2ZSBhcyBtYW55IHByb2JsZW1zIGFzIHRoZSBsaWJ4YyBjb2RlIGRpZCB3aGVu
IGl0IGNvbWVzCj4gdG8gaW5jb21wYXRpYmxlIHdpcmUgZm9ybWF0cyBhbmQgbGF5ZXJpbmcgdmlv
bGF0aW9ucy4gIEluIHBhcnRpY3VsYXIsIGl0Cj4gaXMgbm90IHBvc3NpYmxlIHRvIGRldGVybWlu
ZSB0aGUgYml0bmVzcyBvZiB0aGUgc2VuZGluZwo+IGxpYnhsLXNhdmVyZXN0b3JlLWhlbHBlciwg
bWVhbmluZyB0aGF0IGxlZ2FjeSBjb252ZXJzaW9uIHJlcXVpcmVzIGFjdGl2ZQo+IGFkbWluaXN0
cmF0b3IgaW5wdXQsIG9yIGF0IGxlYXN0IGEgcGFzc2l2ZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGJp
dG5lc3MKPiBpcyB0aGUgc2FtZS4KPgo+IFRoZXJlIGlzIGFuIHhsL2xpYnhsIHBhcnQgb2YgdGhl
IG1pZ3JhdGlvbiB2MiBzZXJpZXMgd2hpY2ggYXR0ZW1wdHMgdG8KPiByZWN0aWZ5IHRoaXMgYWxs
IGluIG9uZSBnbywgYXMgdGhlcmUgaXMgbm8gYWx0ZXJuYXRpdmUgd2F5IG9mIGRvaW5nIHNvLgo+
IFRoZSBsaWJ4bCBzZWN0aW9uIG9mIHRoZSBzZXJpZXMgaXMgY2VydGFpbmx5IG5vdCB5ZXQgY29t
cGxldGUsIGJ1dAo+IHNwZWNpZmljIHF1ZXJpZXMgdG8gdGhlIG1haW50YWluZXJzIGhhdmUgdGh1
c2ZhciBnb25lIHVuYW5zd2VyZWQuICBPbgo+IHRoZSBvdGhlciBoYW5kLCB0aGUgc2VyaWVzIGRv
ZXMgYmFzaWNhbGx5IFdvcmtGb3JNZSwgaW5jbHVkaW5nCj4gdHJhbnNwYXJlbnQgbGVnYWN5IHVw
Z3JhZGUsIHN1Z2dlc3RpbmcgdGhhdCBpdCBpcyBhdCBsZWFzdCBpbiBhbgo+IGFwcHJvcHJpYXRl
IGJhbGxwYXJrLgo+Cj4KPiAqKSBTcGVjaWZpYyBub24tcmVxdWlyZW1lbnRzOgo+Cj4gVGhlcmUg
aGF2ZSBiZWVuIGlzc3VlcyBpZGVudGlmaWVkIHdpdGggZHluYW1pYyAoaW4gYSBwMm0gc2Vuc2Up
IGd1ZXN0cwo+IGFuZCBtaWdyYXRpb24sIHdoaWNoIHJlc3VsdHMgaW4gZmFpbGVkIG1pZ3JhdGlv
biBvciBpbWFnZSBjb3JydXB0aW9uLgo+IFdoaWxlIHRoZXNlIGlzc3VlcyBjZXJ0YWlubHkgd2Fu
dCBmaXhpbmcsIHRoZXkgYXJlIGJ1Z3Mgd2hpY2ggZXhpc3QgaW4KPiB0aGUgbGVnYWN5IGNvZGUu
ICBBcyBzdWNoLCB0aGV5IGFyZSBub3QgcHJlcmVxdWlzaXRlcyB0byBmaXggYmVmb3JlIHYyCj4g
Y2FuIGJlIGFjY2VwdGVkLgo+Cj4KPiBBbnl3YXksIGl0IGlzIG15IGhvcGUgdGhhdCB0aGlzIHBs
YW5uaW5nIGVtYWlsIGNhbiBoZWxwIGdldCB0aGluZ3Mgb24KPiB0cmFjayB0byBzdGFydCBwZXJ1
c2luZyBhY3RpdmUgZGV2ZWxvcG1lbnQgYWdhaW4gYXMgc29vbiBhcyB0aGUgNC42IGRldgo+IHdp
bmRvdyBvcGVucyBhZ2Fpbiwgd2l0aCB0aGUgYWltIHRvIGdldCBhbGwgdGhlIGNvZGUgbWVyZ2Vk
IGFzIGVhcmx5IGFzCj4gcG9zc2libGUgaW4gdGhlIGRldiB3aW5kb3cgdG8gYWxsb3cgYXMgbXVj
aCB0ZXN0aW5nIGFzIHBvc3NpYmxlLgo+Cj4gfkFuZHJldwo+Cj4gLgo+CgotLSAKVGhhbmtzLApZ
YW5nLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:35:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:35:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtuXE-0002hd-RG; Thu, 27 Nov 2014 08:34:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yanghy@cn.fujitsu.com>) id 1XtuXD-0002hW-TG
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:34:44 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	52/1B-02697-322E6745; Thu, 27 Nov 2014 08:34:43 +0000
X-Env-Sender: yanghy@cn.fujitsu.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417077279!13623927!1
X-Originating-IP: [59.151.112.132]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13860 invoked from network); 27 Nov 2014 08:34:41 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-7.tower-206.messagelabs.com with SMTP;
	27 Nov 2014 08:34:41 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="44070248"
Received: from localhost (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 27 Nov 2014 16:31:23 +0800
Received: from G08CNEXCHPEKD01.g08.fujitsu.local (localhost.localdomain
	[127.0.0.1])
	by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id sAR8YJ44003095;
	Thu, 27 Nov 2014 16:34:19 +0800
Received: from [10.167.226.223] (10.167.226.223) by
	G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP
	Server id 14.3.181.6; Thu, 27 Nov 2014 16:34:45 +0800
Message-ID: <5476E1F0.5000804@cn.fujitsu.com>
Date: Thu, 27 Nov 2014 16:33:52 +0800
From: Hongyang Yang <yanghy@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel List
	<xen-devel@lists.xen.org>
References: <5474DE5A.2060000@citrix.com>
In-Reply-To: <5474DE5A.2060000@citrix.com>
X-Originating-IP: [10.167.226.223]
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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-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

CgrlnKggMTEvMjYvMjAxNCAwMzo1NCBBTSwgQW5kcmV3IENvb3BlciDlhpnpgZM6Cj4gSGVsbG8s
Cj4KPiBUaGUgcHVycG9zZSBvZiB0aGlzIGVtYWlsIGlzIHRvIHBsYW4gaG93IHRvIHByb2dyZXNz
IHRoZSBtaWdyYXRpb252Mgo+IHNlcmllcyB0aHJvdWdoIHRvIGJlaW5nIG1lcmdlZC4gIEkgYmVs
aWV2ZSBJIGhhdmUgQ0MnZCBldmVyeW9uZSB3aXRoIGEKPiBzcGVjaWZpYyBpbnRlcmVzdCBpbiB0
aGlzIGFyZWEsIGJ1dCBhcG9sb2dpZXMgaWYgSSBoYXZlIG1pc3NlZCBhbnlvbmUuCj4KPiBNaWdy
YXRpb24gdjIgaXMgaW4gZXhjbHVzaXZlIHVzZSBpbiBYZW5TZXJ2ZXIgNi41LiAgV2UgcHJpbWFy
aWx5Cj4gZGV2ZWxvcGVkIG1pZ3JhdGlvbiB2MiBiZWNhdXNlIHdlIG5lZWRlZCBhIDMyYml0IC0+
IDY0Yml0IHRvb2xzdGFjawo+IHVwZ3JhZGUgcGF0aC4gIFRoZSBjb2RlIGhhcyBhbGwgdGhlIGZl
YXR1cmVzIFhlblNlcnZlciBwcmV2aW91c2x5Cj4gc3VwcG9ydGVkLCBhbmQgd2UgY29uc2lkZXIg
aXQgZnVsbHkgYmFrZWQgYW5kIHdpdGhvdXQgYW55IGtub3duIGJ1Z3MsCj4gaW5jbHVkaW5nIHRy
YW5zcGFyZW50IGxlZ2FjeS10by12MiBjb252ZXJzaW9uIG9uIHVwZ3JhZGUuCj4KPiBXZSBkaWQg
ZW5kZWF2b3VyIHRvIGdldCBtaWdyYXRpb24gdjIgaW50byBYZW4gNC41LCBidXQgcmVncmV0dGFi
bHkgdGhpcwo+IGRpZCBub3QgaGFwcGVuLiAgQSBjb25zZXF1ZW5jZSBvZiB0aGlzLCBhbG9uZyB3
aXRoIHRoZSBjb2RlIGJlaW5nIGluCj4gWGVuU2VydmVyIDYuNSwgaXMgdGhhdCB0aGUgd2lyZSBm
b3JtYXQgaXMgbm93IHNldCBpbiBzdG9uZS4gIEx1Y2tpbHksIGl0Cj4gaGFzIGJlZW4gZXhwbGlj
aXRseSBkZXNpZ25lZCB0byBiZSBlYXN5IHRvIGV4dGVuZCBpbiBhIGZvcndhcmQKPiBjb21wYXRp
YmxlIG1hbm9yLCBzbyB0aGlzIGlzIG5vdCBhIHByb2JsZW0gbW92aW5nIGZvcndhcmQuCj4KPiBU
aGUgZXhwZWN0YXRpb24gaXMgdGhhdCB0aGUgbWlncmF0aW9uIHYyIGNvZGUgd2lsbCBjb21wbGV0
ZWx5IHJlcGxhY2UKPiB0aGUgZXhpc3RpbmcgbWlncmF0aW9uIGNvZGUsIHdoaWNoIHdpbGwgaW52
b2x2ZSByZW1vdmluZwo+IHhjX2RvbWFpbl9zYXZlLmMgYW5kIHhjX2RvbWFpbl9yZXN0b3JlLmMs
IGFzIHdlbGwgYXMgYXNzb3J0ZWQgb3RoZXIKPiBvcnBoYW5lZCBjb2RlIGluIGxpYnhlbmN0cmwg
YW5kIGxpYnhlbmd1ZXN0Cj4KPiBUaGVyZSBhcmUgMyBhcmVhcyBvZiBjb25jZXJuIHdoaWNoIGhh
dmUgYmVlbiBpZGVudGlmaWVkIHNvIGZhci4KPgo+IDEpIFRNRU0gc3VwcG9ydAo+Cj4gTWlncmF0
aW9uIHYyIGRvZXNuJ3QgY3VycmVudGx5IGhhdmUgYW55IHRtZW0gbWlncmF0aW9uIHN1cHBvcnQu
ICBUaGUKPiBtYWludGFpbmVycyBoYXZlIGJlZW4gYXNrZWQgd2hldGhlciB0aGV5IGFjdHVhbGx5
IGV4cGVjdCBsZWdhY3kgdG1lbQo+IG1pZ3JhdGlvbiB0byB3b3JrLCBidXQgSSBoYXZlIG5vdCBo
ZWFyZCBhbnkgcmVwbHkgeWV0LiAgQXQgdGhlIHZlcnkKPiBsZWFzdCwgbWlncmF0aW9uIHYyIHRt
ZW0gc3VwcG9ydCB3b3VsZCB3YW50IHNvbWUgbmV3IHRob3VnaHQgcHV0IGludG8KPiB3aXJlIHBy
b3RvY29sLiAgSSBhbSBob3BpbmcgdGhhdCwgYXMgVE1FTSBpcyBzdGlsbCB0ZWNoIHByZXZpZXcg
YW5kCj4gc3RpbGwgaW4gdGhlIHByb2Nlc3Mgb2YgaGF2aW5nIFhTQS0xNSBmaXhlZCwgd29ya2lu
ZyB0bWVtIG1pZ3JhdGlvbiB2Mgo+IGlzIG5vdCBpbnNpc3RlZCBhcyBhIHByZXJlcXVpc2l0ZS4K
Pgo+IDIpIFJlbXVzL0NPTE8gc3VwcG9ydAo+Cj4gTWlncmF0aW9uIHYyIGRvZXNuJ3QgY3VycmVu
dGx5IGhhdmUgYW55IFJlbXVzIHN1cHBvcnQuICBUaGVyZSB3YXMgYQo+IGRyYWZ0IHNlcmllcyB3
aGljaCBhZGRlZCBSZW11cyBzdXBwb3J0LCBhbmQgc2hvd2VkIHRoYXQgaXQgd2FzCj4gcGFydGlj
dWxhcmx5IHNpbXBsZSB0byBhZGQgUmVtdXMgc3VwcG9ydCB0byBtaWdyYXRpb24gdjIuICBJIGlu
dGVncmF0ZWQKPiBzZXZlcmFsIGJ1Z2ZpeGVzIGFzIGEgc2lkZSBlZmZlY3Qgb2YgdGhhdCBzZXJp
ZXMsIGJ1dCB0aGUgYWN0dWFsIFJlbXVzCj4gY29udGVudCBuZWVkZWQgYSByZWZyZXNoLiAgVGhp
cyBnb3QgZGVsYXllZCBiZWhpbmQgdGhlIFJlbXVzIGxpYnhsCj4gZWZmb3J0LiAgSXQgaXMgbXkg
aG9wZSB0aGF0IHRoZSBSZW11cyBtYWludGFpbmVycyBjYW4gcmVmcmVzaCB0aGF0Cj4gc2VyaWVz
IGFuZCBwcm92aWRlIGFzc2lzdGFuY2Ugd2hpbGUgdGVzdGluZy4KClN1cmUsIEknbSBwbGFubmlu
ZyB0byByZWZyZXNoIHRoZSBwYXRjaGVzIGFzIHNvb24gYXMgWGVuIDQuNiBtZXJnZSB3aW5kb3cK
b3BlbmVkLiBBbmQgYWxzbyBnb2luZyB0byBzdGFydCB0aGUgd29yayBvbiBsaWJ4bCBzaWRlIGJl
Y2F1c2UgbGlieGwgcGFydApvZiBtaWdyYXRpb24gdjIgaGFzIGFscmVhZHkgZG9uZShhbHRob3Vn
aCBub3QgZnVsbGx5IGZpbmlzaGVkPykuIEFuZCB3ZQpob3BlIENPTE8gc3VwcG9ydCB3aWxsIGdv
IGludG8gWGVuIDQuNiBhbHNvLgoKPgo+IDMpIExpYnhsIGFuZCB4bCBzdXBwb3J0Cj4KPiBMaWJ4
bCBhbmQgeGwgaGF2ZSBhcyBtYW55IHByb2JsZW1zIGFzIHRoZSBsaWJ4YyBjb2RlIGRpZCB3aGVu
IGl0IGNvbWVzCj4gdG8gaW5jb21wYXRpYmxlIHdpcmUgZm9ybWF0cyBhbmQgbGF5ZXJpbmcgdmlv
bGF0aW9ucy4gIEluIHBhcnRpY3VsYXIsIGl0Cj4gaXMgbm90IHBvc3NpYmxlIHRvIGRldGVybWlu
ZSB0aGUgYml0bmVzcyBvZiB0aGUgc2VuZGluZwo+IGxpYnhsLXNhdmVyZXN0b3JlLWhlbHBlciwg
bWVhbmluZyB0aGF0IGxlZ2FjeSBjb252ZXJzaW9uIHJlcXVpcmVzIGFjdGl2ZQo+IGFkbWluaXN0
cmF0b3IgaW5wdXQsIG9yIGF0IGxlYXN0IGEgcGFzc2l2ZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGJp
dG5lc3MKPiBpcyB0aGUgc2FtZS4KPgo+IFRoZXJlIGlzIGFuIHhsL2xpYnhsIHBhcnQgb2YgdGhl
IG1pZ3JhdGlvbiB2MiBzZXJpZXMgd2hpY2ggYXR0ZW1wdHMgdG8KPiByZWN0aWZ5IHRoaXMgYWxs
IGluIG9uZSBnbywgYXMgdGhlcmUgaXMgbm8gYWx0ZXJuYXRpdmUgd2F5IG9mIGRvaW5nIHNvLgo+
IFRoZSBsaWJ4bCBzZWN0aW9uIG9mIHRoZSBzZXJpZXMgaXMgY2VydGFpbmx5IG5vdCB5ZXQgY29t
cGxldGUsIGJ1dAo+IHNwZWNpZmljIHF1ZXJpZXMgdG8gdGhlIG1haW50YWluZXJzIGhhdmUgdGh1
c2ZhciBnb25lIHVuYW5zd2VyZWQuICBPbgo+IHRoZSBvdGhlciBoYW5kLCB0aGUgc2VyaWVzIGRv
ZXMgYmFzaWNhbGx5IFdvcmtGb3JNZSwgaW5jbHVkaW5nCj4gdHJhbnNwYXJlbnQgbGVnYWN5IHVw
Z3JhZGUsIHN1Z2dlc3RpbmcgdGhhdCBpdCBpcyBhdCBsZWFzdCBpbiBhbgo+IGFwcHJvcHJpYXRl
IGJhbGxwYXJrLgo+Cj4KPiAqKSBTcGVjaWZpYyBub24tcmVxdWlyZW1lbnRzOgo+Cj4gVGhlcmUg
aGF2ZSBiZWVuIGlzc3VlcyBpZGVudGlmaWVkIHdpdGggZHluYW1pYyAoaW4gYSBwMm0gc2Vuc2Up
IGd1ZXN0cwo+IGFuZCBtaWdyYXRpb24sIHdoaWNoIHJlc3VsdHMgaW4gZmFpbGVkIG1pZ3JhdGlv
biBvciBpbWFnZSBjb3JydXB0aW9uLgo+IFdoaWxlIHRoZXNlIGlzc3VlcyBjZXJ0YWlubHkgd2Fu
dCBmaXhpbmcsIHRoZXkgYXJlIGJ1Z3Mgd2hpY2ggZXhpc3QgaW4KPiB0aGUgbGVnYWN5IGNvZGUu
ICBBcyBzdWNoLCB0aGV5IGFyZSBub3QgcHJlcmVxdWlzaXRlcyB0byBmaXggYmVmb3JlIHYyCj4g
Y2FuIGJlIGFjY2VwdGVkLgo+Cj4KPiBBbnl3YXksIGl0IGlzIG15IGhvcGUgdGhhdCB0aGlzIHBs
YW5uaW5nIGVtYWlsIGNhbiBoZWxwIGdldCB0aGluZ3Mgb24KPiB0cmFjayB0byBzdGFydCBwZXJ1
c2luZyBhY3RpdmUgZGV2ZWxvcG1lbnQgYWdhaW4gYXMgc29vbiBhcyB0aGUgNC42IGRldgo+IHdp
bmRvdyBvcGVucyBhZ2Fpbiwgd2l0aCB0aGUgYWltIHRvIGdldCBhbGwgdGhlIGNvZGUgbWVyZ2Vk
IGFzIGVhcmx5IGFzCj4gcG9zc2libGUgaW4gdGhlIGRldiB3aW5kb3cgdG8gYWxsb3cgYXMgbXVj
aCB0ZXN0aW5nIGFzIHBvc3NpYmxlLgo+Cj4gfkFuZHJldwo+Cj4gLgo+CgotLSAKVGhhbmtzLApZ
YW5nLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:42:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08: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 1XtueX-0002yF-OY; Thu, 27 Nov 2014 08:42:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtueW-0002yA-Rz
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:42:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3B/0F-25276-8E3E6745; Thu, 27 Nov 2014 08:42:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417077734!12905506!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24604 invoked from network); 27 Nov 2014 08:42:14 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 08:42:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 08:42:14 +0000
Message-Id: <5476F1F5020000780004B0BC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 08:42:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
In-Reply-To: <54761124.60203@citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part5C6973F5.1__="
Cc: tim@xen.org, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part5C6973F5.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
> My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
> identify a failed vmentry and lets it fall into the default case of the
> vmexit handler.  As such, with v1, the infinite loop still affects AMD
> hardware.

Right; I should have said "something along the lines of v1". An SVM
part is needed, but that should probably extend beyond what you
proposed in v2: There are a number of "goto exit_and_crash"
statements ahead of where you place your addition. I think they
all need to be treated similarly.

I therefore think we should revert the VMX part of 28b4baacd5
and make SVM behavior consistent with what results for VMX:
Crash the guest unconditionally on VMEXIT_INVALID, without
looking for recurring VM entry failures. See below/attached.

Jan

x86/HVM: prevent infinite VM entry retries

This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
guest upon problems occurring in user mode") and gets SVM in line with
the resulting VMX behavior. This is because Andrew validly says

"A failed vmentry is overwhelmingly likely to be caused by corrupt
 VMC[SB] state.  As a result, injecting a fault and retrying the the
 vmentry is likely to fail in the same way."

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2338,6 +2338,7 @@ void svm_vmexit_handler(struct cpu_user_
         struct nestedvcpu *nv =3D &vcpu_nestedhvm(v);
         struct vmcb_struct *ns_vmcb =3D nv->nv_vvmcx;
         uint64_t exitinfo1, exitinfo2;
+        bool_t crash =3D 0;
=20
         paging_update_nestedmode(v);
=20
@@ -2371,13 +2372,16 @@ void svm_vmexit_handler(struct cpu_user_
                 goto out;
             case NESTEDHVM_VMEXIT_FATALERROR:
                 gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() =
error\n");
-                goto exit_and_crash;
-
+                crash =3D 1;
+                break;
             default:
                 BUG();
             case NESTEDHVM_VMEXIT_ERROR:
                 break;
             }
+            if ( crash )
+                break;
+            /* fall through */
         case NESTEDHVM_VMEXIT_ERROR:
             gdprintk(XENLOG_ERR,
                 "nestedsvm_check_intercepts() returned NESTEDHVM_VMEXIT_ER=
ROR\n");
@@ -2385,18 +2389,25 @@ void svm_vmexit_handler(struct cpu_user_
         case NESTEDHVM_VMEXIT_FATALERROR:
             gdprintk(XENLOG_ERR,
                 "unexpected nestedsvm_check_intercepts() error\n");
-            goto exit_and_crash;
+            crash =3D 1;
+            break;
         default:
             gdprintk(XENLOG_INFO, "nestedsvm_check_intercepts() returned =
%i\n",
                 nsret);
-            goto exit_and_crash;
+            crash =3D 1;
+            break;
         }
+
+        if ( unlikely(crash) && exit_reason !=3D VMEXIT_INVALID )
+            goto exit_and_crash;
     }
=20
     if ( unlikely(exit_reason =3D=3D VMEXIT_INVALID) )
     {
+        gdprintk(XENLOG_ERR, "invalid VMCB state:\n");
         svm_vmcb_dump(__func__, vmcb);
-        goto exit_and_crash;
+        domain_crash(v->domain);
+        return;
     }
=20
     perfc_incra(svmexits, exit_reason);
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,18 +134,6 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
=20
-/* Only crash the guest if the problem originates in kernel mode. */
-static void vmx_crash_or_fault(struct vcpu *v)
-{
-    struct segment_register ss;
-
-    vmx_get_segment_register(v, x86_seg_ss, &ss);
-    if ( ss.attr.fields.dpl )
-        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
-    else
-        domain_crash(v->domain);
-}
-
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
=20
 static const u32 msr_index[] =3D
@@ -2520,7 +2508,7 @@ static void vmx_failed_vmentry(unsigned=20
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
=20
-    vmx_crash_or_fault(curr);
+    domain_crash(curr->domain);
 }
=20
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3173,8 +3161,19 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason=
);
-        vmx_crash_or_fault(v);
+        {
+            struct segment_register ss;
+
+            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
+                     exit_reason);
+
+            vmx_get_segment_register(v, x86_seg_ss, &ss);
+            if ( ss.attr.fields.dpl )
+                hvm_inject_hw_exception(TRAP_invalid_op,
+                                        HVM_DELIVER_NO_ERROR_CODE);
+            else
+                domain_crash(v->domain);
+        }
         break;
     }
=20



--=__Part5C6973F5.1__=
Content-Type: text/plain; name="x86-HVM-prevent-infinite-VMentry-loop.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-prevent-infinite-VMentry-loop.patch"

x86/HVM: prevent infinite VM entry retries=0A=0AThis reverts the VMX side =
of commit 28b4baac ("x86/HVM: don't crash=0Aguest upon problems occurring =
in user mode") and gets SVM in line with=0Athe resulting VMX behavior. =
This is because Andrew validly says=0A=0A"A failed vmentry is overwhelmingl=
y likely to be caused by corrupt=0A VMC[SB] state.  As a result, injecting =
a fault and retrying the the=0A vmentry is likely to fail in the same =
way."=0A=0AReported-by: Andrew Cooper <andrew.cooper3@citrix.com>=0ASigned-=
off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/svm/svm=
.c=0A+++ b/xen/arch/x86/hvm/svm/svm.c=0A@@ -2338,6 +2338,7 @@ void =
svm_vmexit_handler(struct cpu_user_=0A         struct nestedvcpu *nv =3D =
&vcpu_nestedhvm(v);=0A         struct vmcb_struct *ns_vmcb =3D nv->nv_vvmcx=
;=0A         uint64_t exitinfo1, exitinfo2;=0A+        bool_t crash =3D =
0;=0A =0A         paging_update_nestedmode(v);=0A =0A@@ -2371,13 +2372,16 =
@@ void svm_vmexit_handler(struct cpu_user_=0A                 goto =
out;=0A             case NESTEDHVM_VMEXIT_FATALERROR:=0A                 =
gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() error\n");=0A-         =
       goto exit_and_crash;=0A-=0A+                crash =3D 1;=0A+        =
        break;=0A             default:=0A                 BUG();=0A        =
     case NESTEDHVM_VMEXIT_ERROR:=0A                 break;=0A             =
}=0A+            if ( crash )=0A+                break;=0A+            /* =
fall through */=0A         case NESTEDHVM_VMEXIT_ERROR:=0A             =
gdprintk(XENLOG_ERR,=0A                 "nestedsvm_check_intercepts() =
returned NESTEDHVM_VMEXIT_ERROR\n");=0A@@ -2385,18 +2389,25 @@ void =
svm_vmexit_handler(struct cpu_user_=0A         case NESTEDHVM_VMEXIT_FATALE=
RROR:=0A             gdprintk(XENLOG_ERR,=0A                 "unexpected =
nestedsvm_check_intercepts() error\n");=0A-            goto exit_and_crash;=
=0A+            crash =3D 1;=0A+            break;=0A         default:=0A  =
           gdprintk(XENLOG_INFO, "nestedsvm_check_intercepts() returned =
%i\n",=0A                 nsret);=0A-            goto exit_and_crash;=0A+  =
          crash =3D 1;=0A+            break;=0A         }=0A+=0A+        =
if ( unlikely(crash) && exit_reason !=3D VMEXIT_INVALID )=0A+            =
goto exit_and_crash;=0A     }=0A =0A     if ( unlikely(exit_reason =3D=3D =
VMEXIT_INVALID) )=0A     {=0A+        gdprintk(XENLOG_ERR, "invalid VMCB =
state:\n");=0A         svm_vmcb_dump(__func__, vmcb);=0A-        goto =
exit_and_crash;=0A+        domain_crash(v->domain);=0A+        return;=0A  =
   }=0A =0A     perfc_incra(svmexits, exit_reason);=0A--- a/xen/arch/x86/hv=
m/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ -134,18 +134,6 @@ =
static void vmx_vcpu_destroy(struct vcpu=0A     passive_domain_destroy(v);=
=0A }=0A =0A-/* Only crash the guest if the problem originates in kernel =
mode. */=0A-static void vmx_crash_or_fault(struct vcpu *v)=0A-{=0A-    =
struct segment_register ss;=0A-=0A-    vmx_get_segment_register(v, =
x86_seg_ss, &ss);=0A-    if ( ss.attr.fields.dpl )=0A-        hvm_inject_hw=
_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);=0A-    else=0A-    =
    domain_crash(v->domain);=0A-}=0A-=0A static DEFINE_PER_CPU(struct =
vmx_msr_state, host_msr_state);=0A =0A static const u32 msr_index[] =
=3D=0A@@ -2520,7 +2508,7 @@ static void vmx_failed_vmentry(unsigned =0A    =
 vmcs_dump_vcpu(curr);=0A     printk("*************************************=
*\n");=0A =0A-    vmx_crash_or_fault(curr);=0A+    domain_crash(curr->domai=
n);=0A }=0A =0A void vmx_enter_realmode(struct cpu_user_regs *regs)=0A@@ =
-3173,8 +3161,19 @@ void vmx_vmexit_handler(struct cpu_user_=0A     /* =
fall through */=0A     default:=0A     exit_and_crash:=0A-        =
gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);=0A-   =
     vmx_crash_or_fault(v);=0A+        {=0A+            struct segment_regi=
ster ss;=0A+=0A+            gdprintk(XENLOG_WARNING, "Bad vmexit (reason =
%#lx)\n",=0A+                     exit_reason);=0A+=0A+            =
vmx_get_segment_register(v, x86_seg_ss, &ss);=0A+            if ( =
ss.attr.fields.dpl )=0A+                hvm_inject_hw_exception(TRAP_invali=
d_op,=0A+                                        HVM_DELIVER_NO_ERROR_CODE)=
;=0A+            else=0A+                domain_crash(v->domain);=0A+      =
  }=0A         break;=0A     }=0A =0A
--=__Part5C6973F5.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

--=__Part5C6973F5.1__=--


From xen-devel-bounces@lists.xen.org Thu Nov 27 08:42:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08: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 1XtueX-0002yF-OY; Thu, 27 Nov 2014 08:42:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtueW-0002yA-Rz
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:42:17 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3B/0F-25276-8E3E6745; Thu, 27 Nov 2014 08:42:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417077734!12905506!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24604 invoked from network); 27 Nov 2014 08:42:14 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 08:42:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 08:42:14 +0000
Message-Id: <5476F1F5020000780004B0BC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 08:42:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
In-Reply-To: <54761124.60203@citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part5C6973F5.1__="
Cc: tim@xen.org, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part5C6973F5.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
> My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
> identify a failed vmentry and lets it fall into the default case of the
> vmexit handler.  As such, with v1, the infinite loop still affects AMD
> hardware.

Right; I should have said "something along the lines of v1". An SVM
part is needed, but that should probably extend beyond what you
proposed in v2: There are a number of "goto exit_and_crash"
statements ahead of where you place your addition. I think they
all need to be treated similarly.

I therefore think we should revert the VMX part of 28b4baacd5
and make SVM behavior consistent with what results for VMX:
Crash the guest unconditionally on VMEXIT_INVALID, without
looking for recurring VM entry failures. See below/attached.

Jan

x86/HVM: prevent infinite VM entry retries

This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
guest upon problems occurring in user mode") and gets SVM in line with
the resulting VMX behavior. This is because Andrew validly says

"A failed vmentry is overwhelmingly likely to be caused by corrupt
 VMC[SB] state.  As a result, injecting a fault and retrying the the
 vmentry is likely to fail in the same way."

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2338,6 +2338,7 @@ void svm_vmexit_handler(struct cpu_user_
         struct nestedvcpu *nv =3D &vcpu_nestedhvm(v);
         struct vmcb_struct *ns_vmcb =3D nv->nv_vvmcx;
         uint64_t exitinfo1, exitinfo2;
+        bool_t crash =3D 0;
=20
         paging_update_nestedmode(v);
=20
@@ -2371,13 +2372,16 @@ void svm_vmexit_handler(struct cpu_user_
                 goto out;
             case NESTEDHVM_VMEXIT_FATALERROR:
                 gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() =
error\n");
-                goto exit_and_crash;
-
+                crash =3D 1;
+                break;
             default:
                 BUG();
             case NESTEDHVM_VMEXIT_ERROR:
                 break;
             }
+            if ( crash )
+                break;
+            /* fall through */
         case NESTEDHVM_VMEXIT_ERROR:
             gdprintk(XENLOG_ERR,
                 "nestedsvm_check_intercepts() returned NESTEDHVM_VMEXIT_ER=
ROR\n");
@@ -2385,18 +2389,25 @@ void svm_vmexit_handler(struct cpu_user_
         case NESTEDHVM_VMEXIT_FATALERROR:
             gdprintk(XENLOG_ERR,
                 "unexpected nestedsvm_check_intercepts() error\n");
-            goto exit_and_crash;
+            crash =3D 1;
+            break;
         default:
             gdprintk(XENLOG_INFO, "nestedsvm_check_intercepts() returned =
%i\n",
                 nsret);
-            goto exit_and_crash;
+            crash =3D 1;
+            break;
         }
+
+        if ( unlikely(crash) && exit_reason !=3D VMEXIT_INVALID )
+            goto exit_and_crash;
     }
=20
     if ( unlikely(exit_reason =3D=3D VMEXIT_INVALID) )
     {
+        gdprintk(XENLOG_ERR, "invalid VMCB state:\n");
         svm_vmcb_dump(__func__, vmcb);
-        goto exit_and_crash;
+        domain_crash(v->domain);
+        return;
     }
=20
     perfc_incra(svmexits, exit_reason);
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,18 +134,6 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
=20
-/* Only crash the guest if the problem originates in kernel mode. */
-static void vmx_crash_or_fault(struct vcpu *v)
-{
-    struct segment_register ss;
-
-    vmx_get_segment_register(v, x86_seg_ss, &ss);
-    if ( ss.attr.fields.dpl )
-        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
-    else
-        domain_crash(v->domain);
-}
-
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
=20
 static const u32 msr_index[] =3D
@@ -2520,7 +2508,7 @@ static void vmx_failed_vmentry(unsigned=20
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
=20
-    vmx_crash_or_fault(curr);
+    domain_crash(curr->domain);
 }
=20
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3173,8 +3161,19 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason=
);
-        vmx_crash_or_fault(v);
+        {
+            struct segment_register ss;
+
+            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
+                     exit_reason);
+
+            vmx_get_segment_register(v, x86_seg_ss, &ss);
+            if ( ss.attr.fields.dpl )
+                hvm_inject_hw_exception(TRAP_invalid_op,
+                                        HVM_DELIVER_NO_ERROR_CODE);
+            else
+                domain_crash(v->domain);
+        }
         break;
     }
=20



--=__Part5C6973F5.1__=
Content-Type: text/plain; name="x86-HVM-prevent-infinite-VMentry-loop.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-prevent-infinite-VMentry-loop.patch"

x86/HVM: prevent infinite VM entry retries=0A=0AThis reverts the VMX side =
of commit 28b4baac ("x86/HVM: don't crash=0Aguest upon problems occurring =
in user mode") and gets SVM in line with=0Athe resulting VMX behavior. =
This is because Andrew validly says=0A=0A"A failed vmentry is overwhelmingl=
y likely to be caused by corrupt=0A VMC[SB] state.  As a result, injecting =
a fault and retrying the the=0A vmentry is likely to fail in the same =
way."=0A=0AReported-by: Andrew Cooper <andrew.cooper3@citrix.com>=0ASigned-=
off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/svm/svm=
.c=0A+++ b/xen/arch/x86/hvm/svm/svm.c=0A@@ -2338,6 +2338,7 @@ void =
svm_vmexit_handler(struct cpu_user_=0A         struct nestedvcpu *nv =3D =
&vcpu_nestedhvm(v);=0A         struct vmcb_struct *ns_vmcb =3D nv->nv_vvmcx=
;=0A         uint64_t exitinfo1, exitinfo2;=0A+        bool_t crash =3D =
0;=0A =0A         paging_update_nestedmode(v);=0A =0A@@ -2371,13 +2372,16 =
@@ void svm_vmexit_handler(struct cpu_user_=0A                 goto =
out;=0A             case NESTEDHVM_VMEXIT_FATALERROR:=0A                 =
gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() error\n");=0A-         =
       goto exit_and_crash;=0A-=0A+                crash =3D 1;=0A+        =
        break;=0A             default:=0A                 BUG();=0A        =
     case NESTEDHVM_VMEXIT_ERROR:=0A                 break;=0A             =
}=0A+            if ( crash )=0A+                break;=0A+            /* =
fall through */=0A         case NESTEDHVM_VMEXIT_ERROR:=0A             =
gdprintk(XENLOG_ERR,=0A                 "nestedsvm_check_intercepts() =
returned NESTEDHVM_VMEXIT_ERROR\n");=0A@@ -2385,18 +2389,25 @@ void =
svm_vmexit_handler(struct cpu_user_=0A         case NESTEDHVM_VMEXIT_FATALE=
RROR:=0A             gdprintk(XENLOG_ERR,=0A                 "unexpected =
nestedsvm_check_intercepts() error\n");=0A-            goto exit_and_crash;=
=0A+            crash =3D 1;=0A+            break;=0A         default:=0A  =
           gdprintk(XENLOG_INFO, "nestedsvm_check_intercepts() returned =
%i\n",=0A                 nsret);=0A-            goto exit_and_crash;=0A+  =
          crash =3D 1;=0A+            break;=0A         }=0A+=0A+        =
if ( unlikely(crash) && exit_reason !=3D VMEXIT_INVALID )=0A+            =
goto exit_and_crash;=0A     }=0A =0A     if ( unlikely(exit_reason =3D=3D =
VMEXIT_INVALID) )=0A     {=0A+        gdprintk(XENLOG_ERR, "invalid VMCB =
state:\n");=0A         svm_vmcb_dump(__func__, vmcb);=0A-        goto =
exit_and_crash;=0A+        domain_crash(v->domain);=0A+        return;=0A  =
   }=0A =0A     perfc_incra(svmexits, exit_reason);=0A--- a/xen/arch/x86/hv=
m/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ -134,18 +134,6 @@ =
static void vmx_vcpu_destroy(struct vcpu=0A     passive_domain_destroy(v);=
=0A }=0A =0A-/* Only crash the guest if the problem originates in kernel =
mode. */=0A-static void vmx_crash_or_fault(struct vcpu *v)=0A-{=0A-    =
struct segment_register ss;=0A-=0A-    vmx_get_segment_register(v, =
x86_seg_ss, &ss);=0A-    if ( ss.attr.fields.dpl )=0A-        hvm_inject_hw=
_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);=0A-    else=0A-    =
    domain_crash(v->domain);=0A-}=0A-=0A static DEFINE_PER_CPU(struct =
vmx_msr_state, host_msr_state);=0A =0A static const u32 msr_index[] =
=3D=0A@@ -2520,7 +2508,7 @@ static void vmx_failed_vmentry(unsigned =0A    =
 vmcs_dump_vcpu(curr);=0A     printk("*************************************=
*\n");=0A =0A-    vmx_crash_or_fault(curr);=0A+    domain_crash(curr->domai=
n);=0A }=0A =0A void vmx_enter_realmode(struct cpu_user_regs *regs)=0A@@ =
-3173,8 +3161,19 @@ void vmx_vmexit_handler(struct cpu_user_=0A     /* =
fall through */=0A     default:=0A     exit_and_crash:=0A-        =
gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);=0A-   =
     vmx_crash_or_fault(v);=0A+        {=0A+            struct segment_regi=
ster ss;=0A+=0A+            gdprintk(XENLOG_WARNING, "Bad vmexit (reason =
%#lx)\n",=0A+                     exit_reason);=0A+=0A+            =
vmx_get_segment_register(v, x86_seg_ss, &ss);=0A+            if ( =
ss.attr.fields.dpl )=0A+                hvm_inject_hw_exception(TRAP_invali=
d_op,=0A+                                        HVM_DELIVER_NO_ERROR_CODE)=
;=0A+            else=0A+                domain_crash(v->domain);=0A+      =
  }=0A         break;=0A     }=0A =0A
--=__Part5C6973F5.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

--=__Part5C6973F5.1__=--


From xen-devel-bounces@lists.xen.org Thu Nov 27 08:46:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:46:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtuiq-000364-ET; Thu, 27 Nov 2014 08:46:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xtuio-00035u-Mu
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:46:42 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	91/80-28865-2F4E6745; Thu, 27 Nov 2014 08:46:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417078000!13626708!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17541 invoked from network); 27 Nov 2014 08:46:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 08:46:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197108631"
Message-ID: <1417077996.2372.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 27 Nov 2014 08:46:36 +0000
In-Reply-To: <54761040.9060402@citrix.com>
References: <5474DE5A.2060000@citrix.com>
	<1417020637.11944.67.camel@citrix.com> <54761040.9060402@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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, 2014-11-26 at 17:39 +0000, Andrew Cooper wrote:
> > IMHO this is fine. It essentially means that for xl users there is some
> > delayed gratification wrt the promise of migration between non-alike
> > dom0s. The migration from 4.5(legacy)->4.6(v2) won't support such
> > migrations, but the next step from 4.6(v2)->4.7(v2) will.
> 
> Two options exist.
> 
> 1) Assume that the sending bitness is the same as the receiving
> bitness.  This is already the status quo, and will require that the two
> dom0s are the same width.

As I said above I think this is absolutely acceptable as a transitional
step.

> 2) Allow the administrator to specify the bitness of the sending side. 
> In this case, xl 4.5(legacy)->4.6(v2) works even cross-bitness.

If this is trivial to plumb in and you are motivated to do so then this
seems like a reasonable enough "stretch goal".

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:46:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:46:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtuiq-000364-ET; Thu, 27 Nov 2014 08:46:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xtuio-00035u-Mu
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:46:42 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	91/80-28865-2F4E6745; Thu, 27 Nov 2014 08:46:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417078000!13626708!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17541 invoked from network); 27 Nov 2014 08:46:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 08:46:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197108631"
Message-ID: <1417077996.2372.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 27 Nov 2014 08:46:36 +0000
In-Reply-To: <54761040.9060402@citrix.com>
References: <5474DE5A.2060000@citrix.com>
	<1417020637.11944.67.camel@citrix.com> <54761040.9060402@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] [Planning for Xen-4.6] Migration 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, 2014-11-26 at 17:39 +0000, Andrew Cooper wrote:
> > IMHO this is fine. It essentially means that for xl users there is some
> > delayed gratification wrt the promise of migration between non-alike
> > dom0s. The migration from 4.5(legacy)->4.6(v2) won't support such
> > migrations, but the next step from 4.6(v2)->4.7(v2) will.
> 
> Two options exist.
> 
> 1) Assume that the sending bitness is the same as the receiving
> bitness.  This is already the status quo, and will require that the two
> dom0s are the same width.

As I said above I think this is absolutely acceptable as a transitional
step.

> 2) Allow the administrator to specify the bitness of the sending side. 
> In this case, xl 4.5(legacy)->4.6(v2) works even cross-bitness.

If this is trivial to plumb in and you are motivated to do so then this
seems like a reasonable enough "stretch goal".

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:49:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:49:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtulr-0003Cz-0Y; Thu, 27 Nov 2014 08:49:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xtulp-0003Cr-1D
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 08:49:49 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	93/2C-26858-CA5E6745; Thu, 27 Nov 2014 08:49:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417078187!9752169!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2301 invoked from network); 27 Nov 2014 08:49:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 08:49:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 08:49:47 +0000
Message-Id: <5476F3BB020000780004B0D1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 08:49:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	<1412687413-22818-4-git-send-email-vkuznets@redhat.com>
	<5474A568020000780004AB93@mail.emea.novell.com>
	<5474A568020000780004AB93@mail.emea.novell.com>
	<8761e35lui.fsf@vitty.brq.redhat.com>
	<5474BD3C020000780004AC91@mail.emea.novell.com><5474BD3C020000780004AC91@mail.emea.novell.com>
	(Jan Beulich's message of "Tue, 25 Nov 2014 16:32:44 +0000")
	<87h9xn19zy.fsf@vitty.brq.redhat.com>
In-Reply-To: <87h9xn19zy.fsf@vitty.brq.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 3/8] xen: introduce
	XEN_DOMCTL_set_recipient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 18:10, <vkuznets@redhat.com> wrote:
> "Jan Beulich" <JBeulich@suse.com> writes:
> 
>>>>> On 25.11.14 at 16:41, <vkuznets@redhat.com> wrote:
>>> "Jan Beulich" <JBeulich@suse.com> writes:
>>>>>>> On 07.10.14 at 15:10, <vkuznets@redhat.com> wrote:
>>>>> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg, 
> unsigned int order)
>>>>>              scrub = 1;
>>>>>          }
>>>>>  
>>>>> -        if ( unlikely(scrub) )
>>>>> -            for ( i = 0; i < (1 << order); i++ )
>>>>> -                scrub_one_page(&pg[i]);
>>>>> +        if ( !d || !d->recipient || d->recipient->is_dying )
>>>>> +        {
>>>>> +            if ( unlikely(scrub) )
>>>>> +                for ( i = 0; i < (1 << order); i++ )
>>>>> +                    scrub_one_page(&pg[i]);
>>>>>  
>>>>> -        free_heap_pages(pg, order);
>>>>> +            free_heap_pages(pg, order);
>>>>> +        }
>>>>> +        else
>>>>> +        {
>>>>> +            mfn = page_to_mfn(pg);
>>>>> +            gmfn = mfn_to_gmfn(d, mfn);
>>>>> +
>>>>> +            page_set_owner(pg, NULL);
>>>>> +            assign_pages(d->recipient, pg, order, 0);
>>>>
>>>> This can fail.
>>> 
>>> .. if the recipient is dying or we're over-allocating. Shouldn't happen
>>> (if toolstack does its job right) but I'll add a check.
>>
>> You must not rely on the tool stack doing things right (see XSA-77).
>>
>>>> What's worse though is that you don't guard against
>>>> XEN_DOMCTL_set_recipient zapping d->recipient. If that really is
>>>> necessary to be supported, some synchronization will be needed.
>>>>
>>>> And finally - what's the intended protocol for the tool stack to
>>>> know that all pages got transferred (and hence the new domain
>>>> can be launched)?
>>>>
>>> 
>>> (hope this answers both questions above)
>>> 
>>> Now the protocol is:
>>> 1) Toolstack queries for all page frames (with xc_get_pfn_type_batch())
>>> for the old domain.
>>> 2) Toolstack issues XEN_DOMCTL_set_recipient with the recipient domain
>>> 3) Toolstack kills the source domain
>>> 4) Toolstack waits for awhile (loop keeps checking while we see new pages
>>> arriving + some timeout).
>>> 5) Toolstack issues XEN_DOMCTL_set_recipient with DOMID_INVALID
>>> resetting recipient.
>>> 6) Toolstack checks if all pages were transferred
>>> 7) If some pages are missing (e.g. source domain became zombie holding
>>> something) request new empty pages instead.
>>> 8) Toolstack starts new domain
>>> 
>>> So we don't actually need XEN_DOMCTL_set_recipient to switch from one
>>> recipient to the other, we just need a way to reset it.
>>
>> No, this doesn't address either question. For the first one, you again
>> assume the tool stack behaves correctly, which is wrong nowadays.
>> And for the second you give a description, but that's not really a
>> dependable protocol. Nor do I really follow why resetting the recipient
>> is necessary. Can't the tools e.g. wait for the final death of the domain
>> if there's no other notification?
> 
> Yes, it's possible and should happen in all normal cases. However my
> idea was that it's possible to start new domain even if the old one
> fails to die holding several (presumably special) pages and we're fine
> with replacing those with empty pages. In case we go for 'always wait
> for the original domain to die' solution resetting
> XEN_DOMCTL_set_recipient is not necessary (it is necessary in case we
> don't as we can recieve a page after we already requested a new one
> instead).

I think this "always wait" is imo the only reasonable solution: How
would replacing some pages with empty ones fit the kexec/kdump
purposes? However, it may not be necessary to wait for the
domain to completely disappear, it may be sufficient to wait for
its d->tot_pages to become zero.

>>> From a general (hypervisor) point of view we don't actually care if the
>>> domain is dying or not. We just want to recieve all freed pages from
>>> this domain (so they go to some other domain instead of trash).
>>
>> We do care I think, primarily because we want a correct GMFN <->
>> MFN mapping. Seeing multiple pages for the same GMFN is for
>> example going to cause the whole process in its current form to fail.
> 
> Can adding a check that nothing is mapped to the GMFN before mapping new
> MFN there be a solution?

Not checking for this is presumably the better approach - the new
domain would get what the old one had last at a given GMFN. What
it may not get are pages that intermediately got moved around.
But again, all that is relevant only if the old domain can still alter its
memory layout while the transfer is already in progress, which (as
said before) I think should be avoided.

>> And considering the need for such a correct mapping - is it always
>> the case that the mapping gets updated after a page got removed
>> from a guest? (I can see that the mapping doesn't change anymore
>> for a dying guest, but you explicitly say that you want/need this to
>> work before the guest is actually marked dying.)
> 
> Actual reassignment here happens for a dying guest only as
> XEN_DOMCTL_set_recipient does nothing. If you think it's safer to depend
> on the fact that dying flag is always set we can couple
> XEN_DOMCTL_set_recipient with XEN_DOMCTL_destroydomain in one call. It
> is possible if we go for 'always wait for the original domain to die'
> solution (so no reset is required).

I indeed think that's the safer and more correct route.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:49:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:49:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtulr-0003Cz-0Y; Thu, 27 Nov 2014 08:49:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xtulp-0003Cr-1D
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 08:49:49 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	93/2C-26858-CA5E6745; Thu, 27 Nov 2014 08:49:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417078187!9752169!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2301 invoked from network); 27 Nov 2014 08:49:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 08:49:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 08:49:47 +0000
Message-Id: <5476F3BB020000780004B0D1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 08:49:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1412687413-22818-1-git-send-email-vkuznets@redhat.com>
	<1412687413-22818-4-git-send-email-vkuznets@redhat.com>
	<5474A568020000780004AB93@mail.emea.novell.com>
	<5474A568020000780004AB93@mail.emea.novell.com>
	<8761e35lui.fsf@vitty.brq.redhat.com>
	<5474BD3C020000780004AC91@mail.emea.novell.com><5474BD3C020000780004AC91@mail.emea.novell.com>
	(Jan Beulich's message of "Tue, 25 Nov 2014 16:32:44 +0000")
	<87h9xn19zy.fsf@vitty.brq.redhat.com>
In-Reply-To: <87h9xn19zy.fsf@vitty.brq.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFCv3 3/8] xen: introduce
	XEN_DOMCTL_set_recipient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 18:10, <vkuznets@redhat.com> wrote:
> "Jan Beulich" <JBeulich@suse.com> writes:
> 
>>>>> On 25.11.14 at 16:41, <vkuznets@redhat.com> wrote:
>>> "Jan Beulich" <JBeulich@suse.com> writes:
>>>>>>> On 07.10.14 at 15:10, <vkuznets@redhat.com> wrote:
>>>>> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg, 
> unsigned int order)
>>>>>              scrub = 1;
>>>>>          }
>>>>>  
>>>>> -        if ( unlikely(scrub) )
>>>>> -            for ( i = 0; i < (1 << order); i++ )
>>>>> -                scrub_one_page(&pg[i]);
>>>>> +        if ( !d || !d->recipient || d->recipient->is_dying )
>>>>> +        {
>>>>> +            if ( unlikely(scrub) )
>>>>> +                for ( i = 0; i < (1 << order); i++ )
>>>>> +                    scrub_one_page(&pg[i]);
>>>>>  
>>>>> -        free_heap_pages(pg, order);
>>>>> +            free_heap_pages(pg, order);
>>>>> +        }
>>>>> +        else
>>>>> +        {
>>>>> +            mfn = page_to_mfn(pg);
>>>>> +            gmfn = mfn_to_gmfn(d, mfn);
>>>>> +
>>>>> +            page_set_owner(pg, NULL);
>>>>> +            assign_pages(d->recipient, pg, order, 0);
>>>>
>>>> This can fail.
>>> 
>>> .. if the recipient is dying or we're over-allocating. Shouldn't happen
>>> (if toolstack does its job right) but I'll add a check.
>>
>> You must not rely on the tool stack doing things right (see XSA-77).
>>
>>>> What's worse though is that you don't guard against
>>>> XEN_DOMCTL_set_recipient zapping d->recipient. If that really is
>>>> necessary to be supported, some synchronization will be needed.
>>>>
>>>> And finally - what's the intended protocol for the tool stack to
>>>> know that all pages got transferred (and hence the new domain
>>>> can be launched)?
>>>>
>>> 
>>> (hope this answers both questions above)
>>> 
>>> Now the protocol is:
>>> 1) Toolstack queries for all page frames (with xc_get_pfn_type_batch())
>>> for the old domain.
>>> 2) Toolstack issues XEN_DOMCTL_set_recipient with the recipient domain
>>> 3) Toolstack kills the source domain
>>> 4) Toolstack waits for awhile (loop keeps checking while we see new pages
>>> arriving + some timeout).
>>> 5) Toolstack issues XEN_DOMCTL_set_recipient with DOMID_INVALID
>>> resetting recipient.
>>> 6) Toolstack checks if all pages were transferred
>>> 7) If some pages are missing (e.g. source domain became zombie holding
>>> something) request new empty pages instead.
>>> 8) Toolstack starts new domain
>>> 
>>> So we don't actually need XEN_DOMCTL_set_recipient to switch from one
>>> recipient to the other, we just need a way to reset it.
>>
>> No, this doesn't address either question. For the first one, you again
>> assume the tool stack behaves correctly, which is wrong nowadays.
>> And for the second you give a description, but that's not really a
>> dependable protocol. Nor do I really follow why resetting the recipient
>> is necessary. Can't the tools e.g. wait for the final death of the domain
>> if there's no other notification?
> 
> Yes, it's possible and should happen in all normal cases. However my
> idea was that it's possible to start new domain even if the old one
> fails to die holding several (presumably special) pages and we're fine
> with replacing those with empty pages. In case we go for 'always wait
> for the original domain to die' solution resetting
> XEN_DOMCTL_set_recipient is not necessary (it is necessary in case we
> don't as we can recieve a page after we already requested a new one
> instead).

I think this "always wait" is imo the only reasonable solution: How
would replacing some pages with empty ones fit the kexec/kdump
purposes? However, it may not be necessary to wait for the
domain to completely disappear, it may be sufficient to wait for
its d->tot_pages to become zero.

>>> From a general (hypervisor) point of view we don't actually care if the
>>> domain is dying or not. We just want to recieve all freed pages from
>>> this domain (so they go to some other domain instead of trash).
>>
>> We do care I think, primarily because we want a correct GMFN <->
>> MFN mapping. Seeing multiple pages for the same GMFN is for
>> example going to cause the whole process in its current form to fail.
> 
> Can adding a check that nothing is mapped to the GMFN before mapping new
> MFN there be a solution?

Not checking for this is presumably the better approach - the new
domain would get what the old one had last at a given GMFN. What
it may not get are pages that intermediately got moved around.
But again, all that is relevant only if the old domain can still alter its
memory layout while the transfer is already in progress, which (as
said before) I think should be avoided.

>> And considering the need for such a correct mapping - is it always
>> the case that the mapping gets updated after a page got removed
>> from a guest? (I can see that the mapping doesn't change anymore
>> for a dying guest, but you explicitly say that you want/need this to
>> work before the guest is actually marked dying.)
> 
> Actual reassignment here happens for a dying guest only as
> XEN_DOMCTL_set_recipient does nothing. If you think it's safer to depend
> on the fact that dying flag is always set we can couple
> XEN_DOMCTL_set_recipient with XEN_DOMCTL_destroydomain in one call. It
> is possible if we go for 'always wait for the original domain to die'
> solution (so no reset is required).

I indeed think that's the safer and more correct route.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:55:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xture-0003XB-El; Thu, 27 Nov 2014 08:55:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xturc-0003Wv-ON
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:55:48 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	B9/04-02699-417E6745; Thu, 27 Nov 2014 08:55:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417078546!15174405!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16071 invoked from network); 27 Nov 2014 08:55:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 08:55:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197110324"
Message-ID: <1417078543.2372.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 27 Nov 2014 08:55:43 +0000
In-Reply-To: <547623EE.2070303@citrix.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
	<547623EE.2070303@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Dave Scott <Dave.Scott@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Zheng Li <dev@zheng.li>, Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-26 at 19:03 +0000, Andrew Cooper wrote:
> On 26/11/14 18:41, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 26, 2014 at 06:24:11PM +0000, Dave Scott wrote:
> >>> On 26 Nov 2014, at 15:38, Zheng Li <dev@zheng.li> wrote:
> >>>
> >>> On 26/11/2014 15:09, Andrew Cooper wrote:
> >>>> This makes fields 0 and 1 true more often than they should be, resulting
> >>>> problems when handling events.
> >>> Indeed, looks like a mistake I made when rewriting the logic terms lately. The result is POLLUP or POLLERR events being returned in more categories than we'd interest. Thanks for fixing this!
> >>>
> >>> Acked-by: Zheng Li <dev@zheng.li>
> >> This also looks fine to me
> >>
> >> Acked-by: David Scott <dave.scott@citrix.com>
> > Would it be possible to get an Reviewed-by please?
> 
> Strictly speaking Zheng, not being a maintainer, can't ack the patch,
> given what I believe to be Xens current rules for these things. 
> However, as the author of the code and comment in this thread, his ack
> can reasonably be considered equivalent to a  Reviewed-by:  I guess this
> is just a matter of semantics.

In theory/According to
https://www.kernel.org/doc/Documentation/SubmittingPatches Reviewed-by
"indicates that the patch has been reviewed and found
acceptable according to the Reviewer's Statement:

	Reviewer's statement of oversight

	By offering my Reviewed-by: tag, I state that:

 	 (a) I have carried out a technical review of this patch to
	     evaluate its appropriateness and readiness for inclusion into
	     the mainline kernel.

	 (b) Any problems, concerns, or questions relating to the patch
	     have been communicated back to the submitter.  I am satisfied
	     with the submitter's response to my comments.

	 (c) While there may be things that could be improved with this
	     submission, I believe that it is, at this time, (1) a
	     worthwhile modification to the kernel, and (2) free of known
	     issues which would argue against its inclusion.

	 (d) While I have reviewed the patch and believe it to be sound, I
	     do not (unless explicitly stated elsewhere) make any
	     warranties or guarantees that it will achieve its stated
	     purpose or function properly in any given situation.

Whereas Acked-by is just an indication of no-objections or fine-by-me
from the maintainer or possibly a previous reviewer indicating that
their previous concerns have been removed.

That said when they come from someone relevant to the code at hand (as
e.g. Zheng is here) personally I mostly treat them the same (and I
pretty much always say Acked-by not Reviewed-by because my fingers just
do that by default). I think there are others in the project who do
treat them as distinct.

All in all I think it's safe to say that the XenProject neither
implements any distinction in a very strict way in practice nor has a
very consistent view on the differences between them. Personally I don't
think the distinction really matters a great deal and we have more than
enough rules and process as it is without getting too worked up about
Acked vs Reviewed by.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:55:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtura-0003Wj-Ud; Thu, 27 Nov 2014 08:55:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XturZ-0003We-Ss
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:55:45 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	37/1B-27584-117E6745; Thu, 27 Nov 2014 08:55:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417078544!8295527!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12341 invoked from network); 27 Nov 2014 08:55:44 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 08:55:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 08:55:43 +0000
Message-Id: <5476F51F020000780004B0DF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 08:55:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
	<547493D4020000780004AAF3@mail.emea.novell.com>
	<5475E315.8050507@oracle.com>
In-Reply-To: <5475E315.8050507@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.11.14 at 15:26, <boris.ostrovsky@oracle.com> wrote:

> On 11/25/2014 08:36 AM, Jan Beulich wrote:
>>
>>> +static long vpmu_sched_checkin(void *arg)
>>> +{
>>> +    int cpu = cpumask_next(smp_processor_id(), &cpu_online_map);
>> unsigned int.
>>
>>> +    int ret;
>>> +
>>> +    /* Mode change shouldn't take more than a few (say, 5) seconds. */
>>> +    if ( NOW() > vpmu_start_ctxt_switch + SECONDS(5) )
>>> +    {
>>> +        ret = -EBUSY;
>>> +        goto fail;
>>> +    }
>> So what does this guard against? Holding xenpmu_mode_lock for
>> 5 seconds is not a problem, plus I don't think you actually need a
>> lock at all. Just using a global, atomically updated flag ought to be
>> sufficient (the way you use the lock is really nothing else afaict).
> 
> I didn't put it here because of the lock. I just wanted to terminate 
> this operation (mode change) if it takes unreasonable amount of time. 
> And I thought 5 seconds would be unreasonable.

But the question you need to ask yourself is _why_ it could be
taking that long. Since all you do is repeatedly scheduling a
tasklet, it taking arbitrarily long can only be the effect of (a) a
huge system (extremely many CPUs) or (b) a hypervisor bug.
Neither of which is a reason for an arbitrary timeout like you put
in.

>>> +{
>>> +    int ret;
>>> +
>>> +    vpmu_start_ctxt_switch = NOW();
>>> +
>>> +    ret = continue_hypercall_on_cpu(cpumask_first(&cpu_online_map),
>>> +                                    vpmu_sched_checkin, (void *)old_mode);
>>> +    if ( ret )
>>> +        vpmu_start_ctxt_switch = 0;
>>> +
>>> +    return ret;
>>> +}
>> I don't think it is guaranteed (independent of implementation details
>> of continue_hypercall_on_cpu()) that this way you went through the
>> context switch path once on each CPU if
>> cpumask_first(&cpu_online_map) == smp_processor_id() here. In
>> particular it looks like there being a problem calling vcpu_sleep_sync()
>> in the tasklet handler when v == current (which would be the case
>> if you started on the "correct" CPU and the tasklet softirq got
>> handled before the scheduler one). I think you instead want to use
>> cpumask_cycle() here and above, and finish the whole operation
>> once you're back on the CPU you started on (the single-pCPU case
>> may need some extra consideration).
> 
> So your concern is only because of initiating CPU? I can do a 
> force_save() on it so I don't really need a context switch here. This 
> will take care of single PCPU too.

Good.

>> I realize that you simply follow what microcode_update() does, but
>> I think we should rather correct that one than copy the latent issue
>> it has elsewhere.
>>
>>> +long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
>>> +{
>>> +    int ret;
>>> +    struct xen_pmu_params pmu_params;
>>> +
>>> +    ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
>>> +    if ( ret )
>>> +        return ret;
>>> +
>>> +    switch ( op )
>>> +    {
>>> +    case XENPMU_mode_set:
>>> +    {
>>> +        uint64_t old_mode;
>> Irrespective of the earlier comments I don't see why this isn't just
>> unsigned int (or typeof(vpmu_mode)).
> 
> This was because vpmu_force_context switch() takes uint64_t as an 
> argument. Now that it will become unsigned long this should too, no? 
> Yes, the compiler will promote it if it is an int but I thought this 
> would look cleaner.

Imo "cleaner" is when the variable is typed according to the value(s)
it is to hold, not according to the parameter types of functions it's
going to be passed to. And with operations on 32-bit types
(statistically) producing slightly smaller code, one could also argue
for using the smaller of the maximum width data source and the
maximum width consumer.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:55:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xture-0003XB-El; Thu, 27 Nov 2014 08:55:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xturc-0003Wv-ON
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:55:48 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	B9/04-02699-417E6745; Thu, 27 Nov 2014 08:55:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417078546!15174405!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16071 invoked from network); 27 Nov 2014 08:55:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 08:55:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197110324"
Message-ID: <1417078543.2372.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 27 Nov 2014 08:55:43 +0000
In-Reply-To: <547623EE.2070303@citrix.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
	<547623EE.2070303@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Dave Scott <Dave.Scott@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Zheng Li <dev@zheng.li>, Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-26 at 19:03 +0000, Andrew Cooper wrote:
> On 26/11/14 18:41, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 26, 2014 at 06:24:11PM +0000, Dave Scott wrote:
> >>> On 26 Nov 2014, at 15:38, Zheng Li <dev@zheng.li> wrote:
> >>>
> >>> On 26/11/2014 15:09, Andrew Cooper wrote:
> >>>> This makes fields 0 and 1 true more often than they should be, resulting
> >>>> problems when handling events.
> >>> Indeed, looks like a mistake I made when rewriting the logic terms lately. The result is POLLUP or POLLERR events being returned in more categories than we'd interest. Thanks for fixing this!
> >>>
> >>> Acked-by: Zheng Li <dev@zheng.li>
> >> This also looks fine to me
> >>
> >> Acked-by: David Scott <dave.scott@citrix.com>
> > Would it be possible to get an Reviewed-by please?
> 
> Strictly speaking Zheng, not being a maintainer, can't ack the patch,
> given what I believe to be Xens current rules for these things. 
> However, as the author of the code and comment in this thread, his ack
> can reasonably be considered equivalent to a  Reviewed-by:  I guess this
> is just a matter of semantics.

In theory/According to
https://www.kernel.org/doc/Documentation/SubmittingPatches Reviewed-by
"indicates that the patch has been reviewed and found
acceptable according to the Reviewer's Statement:

	Reviewer's statement of oversight

	By offering my Reviewed-by: tag, I state that:

 	 (a) I have carried out a technical review of this patch to
	     evaluate its appropriateness and readiness for inclusion into
	     the mainline kernel.

	 (b) Any problems, concerns, or questions relating to the patch
	     have been communicated back to the submitter.  I am satisfied
	     with the submitter's response to my comments.

	 (c) While there may be things that could be improved with this
	     submission, I believe that it is, at this time, (1) a
	     worthwhile modification to the kernel, and (2) free of known
	     issues which would argue against its inclusion.

	 (d) While I have reviewed the patch and believe it to be sound, I
	     do not (unless explicitly stated elsewhere) make any
	     warranties or guarantees that it will achieve its stated
	     purpose or function properly in any given situation.

Whereas Acked-by is just an indication of no-objections or fine-by-me
from the maintainer or possibly a previous reviewer indicating that
their previous concerns have been removed.

That said when they come from someone relevant to the code at hand (as
e.g. Zheng is here) personally I mostly treat them the same (and I
pretty much always say Acked-by not Reviewed-by because my fingers just
do that by default). I think there are others in the project who do
treat them as distinct.

All in all I think it's safe to say that the XenProject neither
implements any distinction in a very strict way in practice nor has a
very consistent view on the differences between them. Personally I don't
think the distinction really matters a great deal and we have more than
enough rules and process as it is without getting too worked up about
Acked vs Reviewed by.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:55:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtura-0003Wj-Ud; Thu, 27 Nov 2014 08:55:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XturZ-0003We-Ss
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:55:45 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	37/1B-27584-117E6745; Thu, 27 Nov 2014 08:55:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417078544!8295527!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12341 invoked from network); 27 Nov 2014 08:55:44 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 08:55:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 08:55:43 +0000
Message-Id: <5476F51F020000780004B0DF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 08:55:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
	<547493D4020000780004AAF3@mail.emea.novell.com>
	<5475E315.8050507@oracle.com>
In-Reply-To: <5475E315.8050507@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.11.14 at 15:26, <boris.ostrovsky@oracle.com> wrote:

> On 11/25/2014 08:36 AM, Jan Beulich wrote:
>>
>>> +static long vpmu_sched_checkin(void *arg)
>>> +{
>>> +    int cpu = cpumask_next(smp_processor_id(), &cpu_online_map);
>> unsigned int.
>>
>>> +    int ret;
>>> +
>>> +    /* Mode change shouldn't take more than a few (say, 5) seconds. */
>>> +    if ( NOW() > vpmu_start_ctxt_switch + SECONDS(5) )
>>> +    {
>>> +        ret = -EBUSY;
>>> +        goto fail;
>>> +    }
>> So what does this guard against? Holding xenpmu_mode_lock for
>> 5 seconds is not a problem, plus I don't think you actually need a
>> lock at all. Just using a global, atomically updated flag ought to be
>> sufficient (the way you use the lock is really nothing else afaict).
> 
> I didn't put it here because of the lock. I just wanted to terminate 
> this operation (mode change) if it takes unreasonable amount of time. 
> And I thought 5 seconds would be unreasonable.

But the question you need to ask yourself is _why_ it could be
taking that long. Since all you do is repeatedly scheduling a
tasklet, it taking arbitrarily long can only be the effect of (a) a
huge system (extremely many CPUs) or (b) a hypervisor bug.
Neither of which is a reason for an arbitrary timeout like you put
in.

>>> +{
>>> +    int ret;
>>> +
>>> +    vpmu_start_ctxt_switch = NOW();
>>> +
>>> +    ret = continue_hypercall_on_cpu(cpumask_first(&cpu_online_map),
>>> +                                    vpmu_sched_checkin, (void *)old_mode);
>>> +    if ( ret )
>>> +        vpmu_start_ctxt_switch = 0;
>>> +
>>> +    return ret;
>>> +}
>> I don't think it is guaranteed (independent of implementation details
>> of continue_hypercall_on_cpu()) that this way you went through the
>> context switch path once on each CPU if
>> cpumask_first(&cpu_online_map) == smp_processor_id() here. In
>> particular it looks like there being a problem calling vcpu_sleep_sync()
>> in the tasklet handler when v == current (which would be the case
>> if you started on the "correct" CPU and the tasklet softirq got
>> handled before the scheduler one). I think you instead want to use
>> cpumask_cycle() here and above, and finish the whole operation
>> once you're back on the CPU you started on (the single-pCPU case
>> may need some extra consideration).
> 
> So your concern is only because of initiating CPU? I can do a 
> force_save() on it so I don't really need a context switch here. This 
> will take care of single PCPU too.

Good.

>> I realize that you simply follow what microcode_update() does, but
>> I think we should rather correct that one than copy the latent issue
>> it has elsewhere.
>>
>>> +long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
>>> +{
>>> +    int ret;
>>> +    struct xen_pmu_params pmu_params;
>>> +
>>> +    ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
>>> +    if ( ret )
>>> +        return ret;
>>> +
>>> +    switch ( op )
>>> +    {
>>> +    case XENPMU_mode_set:
>>> +    {
>>> +        uint64_t old_mode;
>> Irrespective of the earlier comments I don't see why this isn't just
>> unsigned int (or typeof(vpmu_mode)).
> 
> This was because vpmu_force_context switch() takes uint64_t as an 
> argument. Now that it will become unsigned long this should too, no? 
> Yes, the compiler will promote it if it is an int but I thought this 
> would look cleaner.

Imo "cleaner" is when the variable is typed according to the value(s)
it is to hold, not according to the parameter types of functions it's
going to be passed to. And with operations on 32-bit types
(statistically) producing slightly smaller code, one could also argue
for using the smaller of the maximum width data source and the
maximum width consumer.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:57:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtutB-0003gv-Tr; Thu, 27 Nov 2014 08:57:25 +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 1XtutA-0003gf-1b
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:57:24 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	CE/8C-02699-377E6745; Thu, 27 Nov 2014 08:57:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417078642!15196124!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2860 invoked from network); 27 Nov 2014 08:57:22 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 08:57:22 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 08:57:22 +0000
Message-Id: <5476F580020000780004B0E2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 08:57:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
	<547496E0020000780004AB05@mail.emea.novell.com>
	<5475E46B.9000502@oracle.com>
In-Reply-To: <5475E46B.9000502@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.11.14 at 15:32, <boris.ostrovsky@oracle.com> wrote:

> On 11/25/2014 08:49 AM, Jan Beulich wrote:
>>>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
>>> @@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
>>>       switch ( vendor )
>>>       {
>>>       case X86_VENDOR_AMD:
>>> -        if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>>> -            opt_vpmu_enabled = 0;
>>> +        if ( svm_vpmu_initialise(v) != 0 )
>>> +            vpmu_mode = XENPMU_MODE_OFF;
>>>           break;
>>>   
>>>       case X86_VENDOR_INTEL:
>>> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>>> -            opt_vpmu_enabled = 0;
>>> +        if ( vmx_vpmu_initialise(v) != 0 )
>>> +            vpmu_mode = XENPMU_MODE_OFF;
>>>           break;
>> So this turns off the vPMU globally upon failure of initializing
>> some random vCPU. Why is that? I see this was the case even
>> before your entire series, but shouldn't this be fixed _before_
>> enhancing the whole thing to support PV/PVH?
> 
> Yes, that's probably too strong. Do you want to fix this as an early 
> patch (before PV(H)) support gets in? I'd rather do it in the patch that 
> moves things into initcalls.

Yes, I think this should be fixed in a prereq patch, thus allowing it
to be easily backported if so desired.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:57:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtutB-0003gv-Tr; Thu, 27 Nov 2014 08:57:25 +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 1XtutA-0003gf-1b
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:57:24 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	CE/8C-02699-377E6745; Thu, 27 Nov 2014 08:57:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417078642!15196124!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2860 invoked from network); 27 Nov 2014 08:57:22 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 08:57:22 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 08:57:22 +0000
Message-Id: <5476F580020000780004B0E2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 08:57:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-12-git-send-email-boris.ostrovsky@oracle.com>
	<547496E0020000780004AB05@mail.emea.novell.com>
	<5475E46B.9000502@oracle.com>
In-Reply-To: <5475E46B.9000502@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting
 PMU mode and flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.11.14 at 15:32, <boris.ostrovsky@oracle.com> wrote:

> On 11/25/2014 08:49 AM, Jan Beulich wrote:
>>>>> On 17.11.14 at 00:07, <boris.ostrovsky@oracle.com> wrote:
>>> @@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
>>>       switch ( vendor )
>>>       {
>>>       case X86_VENDOR_AMD:
>>> -        if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>>> -            opt_vpmu_enabled = 0;
>>> +        if ( svm_vpmu_initialise(v) != 0 )
>>> +            vpmu_mode = XENPMU_MODE_OFF;
>>>           break;
>>>   
>>>       case X86_VENDOR_INTEL:
>>> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>>> -            opt_vpmu_enabled = 0;
>>> +        if ( vmx_vpmu_initialise(v) != 0 )
>>> +            vpmu_mode = XENPMU_MODE_OFF;
>>>           break;
>> So this turns off the vPMU globally upon failure of initializing
>> some random vCPU. Why is that? I see this was the case even
>> before your entire series, but shouldn't this be fixed _before_
>> enhancing the whole thing to support PV/PVH?
> 
> Yes, that's probably too strong. Do you want to fix this as an early 
> patch (before PV(H)) support gets in? I'd rather do it in the patch that 
> moves things into initcalls.

Yes, I think this should be fixed in a prereq patch, thus allowing it
to be easily backported if so desired.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:59:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtuvB-0003qw-En; Thu, 27 Nov 2014 08:59:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtuvA-0003qp-5b
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:59:28 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	41/0C-22737-FE7E6745; Thu, 27 Nov 2014 08:59:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417078766!10231747!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18994 invoked from network); 27 Nov 2014 08:59:26 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 08:59:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 08:59:26 +0000
Message-Id: <5476F5FE020000780004B0E5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 08:59:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-18-git-send-email-boris.ostrovsky@oracle.com>
	<5474A028020000780004AB58@mail.emea.novell.com>
	<5475E610.2020707@oracle.com>
In-Reply-To: <5475E610.2020707@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 17/21] x86/VPMU: Handle PMU interrupts
 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 26.11.14 at 15:39, <boris.ostrovsky@oracle.com> wrote:

> On 11/25/2014 09:28 AM, Jan Beulich wrote:
>>
>>> +            else
>>> +            {
>>> +                struct segment_register seg;
>>> +
>>> +                hvm_get_segment_register(sampled, x86_seg_cs, &seg);
>>> +                r->cs = seg.sel;
>>> +                hvm_get_segment_register(sampled, x86_seg_ss, &seg);
>>> +                r->ss = seg.sel;
>>> +                if ( seg.attr.fields.dpl != 0 )
>>> +                    *flags |= PMU_SAMPLE_USER;
>> Is that how hardware treats it (CPL != 0 meaning user, rather
>> than CPL == 3)?
> 
> You mean how *software* (e.g. Linux kernel) treats it? If yes, then for 
> 32-bit user_mode() checks for (CS == 3) and for 64-bit it's !!(CS & 3).

No, I meant hardware. There CPL qualified PMU aspects, and it was
those I had in mind to use as reference here.

>> Maybe you should surface CPL instead of a
>> boolean flag?
> 
> Am I not already doing it by passing SS and CS to the guest?

No, neither SS.RPL nor CS.RPL formally represent CPL.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 08:59:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 08:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtuvB-0003qw-En; Thu, 27 Nov 2014 08:59:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtuvA-0003qp-5b
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 08:59:28 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	41/0C-22737-FE7E6745; Thu, 27 Nov 2014 08:59:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417078766!10231747!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18994 invoked from network); 27 Nov 2014 08:59:26 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 08:59:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 08:59:26 +0000
Message-Id: <5476F5FE020000780004B0E5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 08:59:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1416179271-1221-1-git-send-email-boris.ostrovsky@oracle.com>
	<1416179271-1221-18-git-send-email-boris.ostrovsky@oracle.com>
	<5474A028020000780004AB58@mail.emea.novell.com>
	<5475E610.2020707@oracle.com>
In-Reply-To: <5475E610.2020707@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tim@xen.org,
	dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v15 17/21] x86/VPMU: Handle PMU interrupts
 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 26.11.14 at 15:39, <boris.ostrovsky@oracle.com> wrote:

> On 11/25/2014 09:28 AM, Jan Beulich wrote:
>>
>>> +            else
>>> +            {
>>> +                struct segment_register seg;
>>> +
>>> +                hvm_get_segment_register(sampled, x86_seg_cs, &seg);
>>> +                r->cs = seg.sel;
>>> +                hvm_get_segment_register(sampled, x86_seg_ss, &seg);
>>> +                r->ss = seg.sel;
>>> +                if ( seg.attr.fields.dpl != 0 )
>>> +                    *flags |= PMU_SAMPLE_USER;
>> Is that how hardware treats it (CPL != 0 meaning user, rather
>> than CPL == 3)?
> 
> You mean how *software* (e.g. Linux kernel) treats it? If yes, then for 
> 32-bit user_mode() checks for (CS == 3) and for 64-bit it's !!(CS & 3).

No, I meant hardware. There CPL qualified PMU aspects, and it was
those I had in mind to use as reference here.

>> Maybe you should surface CPL instead of a
>> boolean flag?
> 
> Am I not already doing it by passing SS and CS to the guest?

No, neither SS.RPL nor CS.RPL formally represent CPL.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 09:27:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 09: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 1XtvLd-0004Xo-1M; Thu, 27 Nov 2014 09:26:49 +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 1XtvLb-0004Xj-4q
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 09:26:47 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	37/22-02953-65EE6745; Thu, 27 Nov 2014 09:26:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417080405!15195453!1
X-Originating-IP: [81.169.146.219]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18733 invoked from network); 27 Nov 2014 09:26:45 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.219)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 09:26:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417080405; l=2342;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=rLlk6ycfLOuXN6GDJY7kNxC3g5U=;
	b=b5t4sB4fAUxrwRl+Nxmrq+HrCYjswRdEs/gxYtiAfWYFK+QmpPXKDS6Sb1zCg3Y7ARr
	A5v88PY1BpUbcd96X/+E85xaKsUJdJ3DkhOJ0VfwmW3fYC3GnNVJ6luGuf6fE2H5gE0nP
	yNTPNuGz1cdpKilzGtqwqO74Ce/GJWtA9Sg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssV99SEpOlQD22BhqGB3P3iaBLrl+V5meZTl30+w==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:10ca:da01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.1 AUTH) with ESMTPSA id 004292qAR9QgEqc
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 27 Nov 2014 10:26:42 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id EFD0950172; Thu, 27 Nov 2014 10:26:41 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Thu, 27 Nov 2014 10:26:26 +0100
Message-Id: <1417080386-6662-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3] INSTALL: correct EXTRA_CFLAGS 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>
MIME-Version: 1.0
Content-Type: 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 already documented configure patch was not applied.
Adjust documentation to describe existing behaviour.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
v3: reword as suggested by Konrad, trim Cc list
v2: resend due to lack of Cc: tags

 INSTALL | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/INSTALL b/INSTALL
index 6bb9d23..0bc67ea 100644
--- a/INSTALL
+++ b/INSTALL
@@ -128,13 +128,6 @@ original xenstored will be used. Valid names are xenstored and
 oxenstored.
   --with-xenstored=name
 
-Using additional CFLAGS to build tools running in dom0 is required when
-building distro packages. This is the option to pass things like
-RPM_OPT_FLAGS.
-  --with-extra-cflags-tools=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-traditional=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-upstream=EXTRA_CFLAGS
-
 Instead of starting the tools in dom0 with sysv runlevel scripts they
 can also be started by systemd. If this option is enabled xenstored will
 receive the communication socked directly from systemd. So starting it
@@ -241,6 +234,13 @@ QEMU_UPSTREAM_URL=
 QEMU_TRADITIONAL_URL=
 SEABIOS_UPSTREAM_URL=
 
+Using additional CFLAGS to build tools which will run in dom0 is
+required when building distro packages. These variables can be used to
+pass RPM_OPT_FLAGS.
+EXTRA_CFLAGS_XEN_TOOLS=
+EXTRA_CFLAGS_QEMU_TRADITIONAL=
+EXTRA_CFLAGS_QEMU_XEN=
+
 This variable can be used to use DIR/include and DIR/lib during build.
 This is the same as PREPEND_LIB and PREPEND_INCLUDES. APPEND_LIB and
 APPEND_INCLUDES= will be appended to the CFLAGS/LDFLAGS variable.
@@ -310,10 +310,10 @@ sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi
 %build
 export WGET=$(type -P false)
 export GIT=$(type -P false)
+export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
 %configure \
-        --with-extra-cflags-tools="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-traditional="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-upstream="$RPM_OPT_FLAGS" \
         --with-initddir=%{_initddir}
 unset CFLAGS CXXFLAGS FFLAGS LDFLAGS
 make

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 09:27:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 09: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 1XtvLd-0004Xo-1M; Thu, 27 Nov 2014 09:26:49 +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 1XtvLb-0004Xj-4q
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 09:26:47 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	37/22-02953-65EE6745; Thu, 27 Nov 2014 09:26:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417080405!15195453!1
X-Originating-IP: [81.169.146.219]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18733 invoked from network); 27 Nov 2014 09:26:45 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.219)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 09:26:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417080405; l=2342;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=rLlk6ycfLOuXN6GDJY7kNxC3g5U=;
	b=b5t4sB4fAUxrwRl+Nxmrq+HrCYjswRdEs/gxYtiAfWYFK+QmpPXKDS6Sb1zCg3Y7ARr
	A5v88PY1BpUbcd96X/+E85xaKsUJdJ3DkhOJ0VfwmW3fYC3GnNVJ6luGuf6fE2H5gE0nP
	yNTPNuGz1cdpKilzGtqwqO74Ce/GJWtA9Sg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssV99SEpOlQD22BhqGB3P3iaBLrl+V5meZTl30+w==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:10ca:da01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.1 AUTH) with ESMTPSA id 004292qAR9QgEqc
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 27 Nov 2014 10:26:42 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id EFD0950172; Thu, 27 Nov 2014 10:26:41 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Thu, 27 Nov 2014 10:26:26 +0100
Message-Id: <1417080386-6662-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3] INSTALL: correct EXTRA_CFLAGS 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>
MIME-Version: 1.0
Content-Type: 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 already documented configure patch was not applied.
Adjust documentation to describe existing behaviour.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
v3: reword as suggested by Konrad, trim Cc list
v2: resend due to lack of Cc: tags

 INSTALL | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/INSTALL b/INSTALL
index 6bb9d23..0bc67ea 100644
--- a/INSTALL
+++ b/INSTALL
@@ -128,13 +128,6 @@ original xenstored will be used. Valid names are xenstored and
 oxenstored.
   --with-xenstored=name
 
-Using additional CFLAGS to build tools running in dom0 is required when
-building distro packages. This is the option to pass things like
-RPM_OPT_FLAGS.
-  --with-extra-cflags-tools=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-traditional=EXTRA_CFLAGS
-  --with-extra-cflags-qemu-upstream=EXTRA_CFLAGS
-
 Instead of starting the tools in dom0 with sysv runlevel scripts they
 can also be started by systemd. If this option is enabled xenstored will
 receive the communication socked directly from systemd. So starting it
@@ -241,6 +234,13 @@ QEMU_UPSTREAM_URL=
 QEMU_TRADITIONAL_URL=
 SEABIOS_UPSTREAM_URL=
 
+Using additional CFLAGS to build tools which will run in dom0 is
+required when building distro packages. These variables can be used to
+pass RPM_OPT_FLAGS.
+EXTRA_CFLAGS_XEN_TOOLS=
+EXTRA_CFLAGS_QEMU_TRADITIONAL=
+EXTRA_CFLAGS_QEMU_XEN=
+
 This variable can be used to use DIR/include and DIR/lib during build.
 This is the same as PREPEND_LIB and PREPEND_INCLUDES. APPEND_LIB and
 APPEND_INCLUDES= will be appended to the CFLAGS/LDFLAGS variable.
@@ -310,10 +310,10 @@ sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi
 %build
 export WGET=$(type -P false)
 export GIT=$(type -P false)
+export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
+export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
 %configure \
-        --with-extra-cflags-tools="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-traditional="$RPM_OPT_FLAGS" \
-        --with-extra-cflags-qemu-upstream="$RPM_OPT_FLAGS" \
         --with-initddir=%{_initddir}
 unset CFLAGS CXXFLAGS FFLAGS LDFLAGS
 make

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 09:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 09:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtvMX-0004bF-FM; Thu, 27 Nov 2014 09:27:45 +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 1XtvMV-0004ax-LS
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 09:27:43 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	24/9C-02696-E8EE6745; Thu, 27 Nov 2014 09:27:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417080462!15210553!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7418 invoked from network); 27 Nov 2014 09:27:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 09:27:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 09:27:41 +0000
Message-Id: <5476FC9C020000780004B11D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 09:27:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>,
	"Donald D Dugger" <donald.d.dugger@intel.com>,
	"Jun Nakajima" <jun.nakajima@intel.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
	<54746F59020000780004A9E9@mail.emea.novell.com>
	<5476B6A8.4060706@ihonk.com>
In-Reply-To: <5476B6A8.4060706@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 06:29, <sflist@ihonk.com> wrote:
> On 11/25/2014 03:00 AM, Jan Beulich wrote:
>> Okay, so it's not really the mwait-idle driver causing the regression,
>> but it is C-state related. Hence we're now down to seeing whether all
>> or just the deeper C states are affected, i.e. I now need to ask you
>> to play with "max_cstate=". For that you'll have to remember that the
>> option's effect differs between the ACPI and the MWAIT idle drivers.
>> In the spirit of bisection I'd suggest using "max_cstate=2" first no
>> matter which of the two scenarios you pick. If that still hangs,
>> "max_cstate=1" obviously is the only other thing to try. Should that
>> not hang (and you left out "mwait-idle=0"), trying "max_cstate=3"
>> in that same scenario would be the other case to check.
>>
>> No need for 'd' and 'a' output for the time being, but 'c' output would
>> be much appreciated for all cases where you observe hangs.
>>
> 
> Okay, working through that now. I tried max_cstate=2 and got no hangs, 
> whether with or without mwait-idle=0. However, I was puzzled by this:
> 
> (XEN) 'c' pressed -> printing ACPI Cx structures
> (XEN) ==cpu0==
> (XEN) active state:             C0
> (XEN) max_cstate:               C2
> (XEN) states:
> (XEN)     C1:   type[C1] latency[003] usage[12219860] method[  FFH] 
> duration[1190961948551]
> (XEN)     C2:   type[C1] latency[010] usage[10205554] method[  FFH] 
> duration[2015393965907]
> (XEN)     C3:   type[C2] latency[020] usage[50926286] method[  FFH] 
> duration[30527997858148]
> (XEN)    *C0:   usage[73351700] duration[9974627547595]
> (XEN) max=0 pwr=0 urg=0 nxt=0
> (XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
> (XEN) CC3[28794734145697] CC6[0] CC7[0]
> (XEN) ==cpu1==
> (XEN) active state:             C3
> (XEN) max_cstate:               C2
> (XEN) states:
> (XEN)     C1:   type[C1] latency[003] usage[10699950] method[  FFH] 
> duration[1141422044112]
> (XEN)     C2:   type[C1] latency[010] usage[06382904] method[  FFH] 
> duration[1329739264322]
> (XEN)    *C3:   type[C2] latency[020] usage[44630764] method[  FFH] 
> duration[31676618425954]
> (XEN)     C0:   usage[61713618] duration[9561201640320]
> (XEN) max=0 pwr=0 urg=0 nxt=0
> (XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
> (XEN) CC3[30066495105056] CC6[0] CC7[0]
>[...]
> 
> Why would some of the cores be in C3 even though they list max_cstate as C2?

This was precisely the reason why I told you that the numbering
differs (and is confusing and has nothing to do with actual C state
numbers): What max_cstate refers to in the mwait-idle driver is
what above is listed as type[Cx], i.e. the state at index 1 is C1, at
2 we've got C1E, and at 3 we've got C2. And those still aren't in
line with the numbering the CPU documentation uses, it's rather
kind of meant to refer to the ACPI numbering (but probably also
not fully matching up).

So max_cstate=2 working suggests a problem with what the CPU
calls C6, which presumably isn't all that surprising considering the
many errata (BD35, BD38, BD40, BD59, BD87, and BD104). Not
sure how to proceed from here - I suppose you already made
sure you run with the latest available BIOS. And with 6 errata
documented it's not all that unlikely that there's a 7th one with
MONITOR/MWAIT behavior. The commit you bisected to (and
which you had verified to be the culprit by just forcing
arch_skip_send_event_check() to always return false) could be
reasonably assumed to be broken only when MWAIT use for all
C states didn't work.

Don, Jun - is there anything known but not yet publicly
documented for Family 6 Model 44 Xeons?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 09:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 09:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtvMX-0004bF-FM; Thu, 27 Nov 2014 09:27:45 +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 1XtvMV-0004ax-LS
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 09:27:43 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	24/9C-02696-E8EE6745; Thu, 27 Nov 2014 09:27:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417080462!15210553!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7418 invoked from network); 27 Nov 2014 09:27:42 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 09:27:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 09:27:41 +0000
Message-Id: <5476FC9C020000780004B11D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 09:27:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steve Freitas" <sflist@ihonk.com>,
	"Donald D Dugger" <donald.d.dugger@intel.com>,
	"Jun Nakajima" <jun.nakajima@intel.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
	<54746F59020000780004A9E9@mail.emea.novell.com>
	<5476B6A8.4060706@ihonk.com>
In-Reply-To: <5476B6A8.4060706@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 06:29, <sflist@ihonk.com> wrote:
> On 11/25/2014 03:00 AM, Jan Beulich wrote:
>> Okay, so it's not really the mwait-idle driver causing the regression,
>> but it is C-state related. Hence we're now down to seeing whether all
>> or just the deeper C states are affected, i.e. I now need to ask you
>> to play with "max_cstate=". For that you'll have to remember that the
>> option's effect differs between the ACPI and the MWAIT idle drivers.
>> In the spirit of bisection I'd suggest using "max_cstate=2" first no
>> matter which of the two scenarios you pick. If that still hangs,
>> "max_cstate=1" obviously is the only other thing to try. Should that
>> not hang (and you left out "mwait-idle=0"), trying "max_cstate=3"
>> in that same scenario would be the other case to check.
>>
>> No need for 'd' and 'a' output for the time being, but 'c' output would
>> be much appreciated for all cases where you observe hangs.
>>
> 
> Okay, working through that now. I tried max_cstate=2 and got no hangs, 
> whether with or without mwait-idle=0. However, I was puzzled by this:
> 
> (XEN) 'c' pressed -> printing ACPI Cx structures
> (XEN) ==cpu0==
> (XEN) active state:             C0
> (XEN) max_cstate:               C2
> (XEN) states:
> (XEN)     C1:   type[C1] latency[003] usage[12219860] method[  FFH] 
> duration[1190961948551]
> (XEN)     C2:   type[C1] latency[010] usage[10205554] method[  FFH] 
> duration[2015393965907]
> (XEN)     C3:   type[C2] latency[020] usage[50926286] method[  FFH] 
> duration[30527997858148]
> (XEN)    *C0:   usage[73351700] duration[9974627547595]
> (XEN) max=0 pwr=0 urg=0 nxt=0
> (XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
> (XEN) CC3[28794734145697] CC6[0] CC7[0]
> (XEN) ==cpu1==
> (XEN) active state:             C3
> (XEN) max_cstate:               C2
> (XEN) states:
> (XEN)     C1:   type[C1] latency[003] usage[10699950] method[  FFH] 
> duration[1141422044112]
> (XEN)     C2:   type[C1] latency[010] usage[06382904] method[  FFH] 
> duration[1329739264322]
> (XEN)    *C3:   type[C2] latency[020] usage[44630764] method[  FFH] 
> duration[31676618425954]
> (XEN)     C0:   usage[61713618] duration[9561201640320]
> (XEN) max=0 pwr=0 urg=0 nxt=0
> (XEN) PC2[0] PC3[8589642315848] PC6[0] PC7[0]
> (XEN) CC3[30066495105056] CC6[0] CC7[0]
>[...]
> 
> Why would some of the cores be in C3 even though they list max_cstate as C2?

This was precisely the reason why I told you that the numbering
differs (and is confusing and has nothing to do with actual C state
numbers): What max_cstate refers to in the mwait-idle driver is
what above is listed as type[Cx], i.e. the state at index 1 is C1, at
2 we've got C1E, and at 3 we've got C2. And those still aren't in
line with the numbering the CPU documentation uses, it's rather
kind of meant to refer to the ACPI numbering (but probably also
not fully matching up).

So max_cstate=2 working suggests a problem with what the CPU
calls C6, which presumably isn't all that surprising considering the
many errata (BD35, BD38, BD40, BD59, BD87, and BD104). Not
sure how to proceed from here - I suppose you already made
sure you run with the latest available BIOS. And with 6 errata
documented it's not all that unlikely that there's a 7th one with
MONITOR/MWAIT behavior. The commit you bisected to (and
which you had verified to be the culprit by just forcing
arch_skip_send_event_check() to always return false) could be
reasonably assumed to be broken only when MWAIT use for all
C states didn't work.

Don, Jun - is there anything known but not yet publicly
documented for Family 6 Model 44 Xeons?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 09:50:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 09:50:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtvi8-00059P-KK; Thu, 27 Nov 2014 09:50:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xtvi7-00059K-1h
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 09:50:03 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	86/A1-24859-AC3F6745; Thu, 27 Nov 2014 09:50:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417081800!14190088!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15767 invoked from network); 27 Nov 2014 09:50:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 09:50:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197122809"
Message-ID: <1417081768.11944.70.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 27 Nov 2014 09:49:28 +0000
In-Reply-To: <5475E311.6070501@citrix.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com> <5475E311.6070501@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-26 at 14:26 +0000, Andrew Cooper wrote:
> libxc (or some new alternative) should suck it up and gain some notion
> of a stable API or ABI (like the rest of the world appears to be able to
> manage), such that it is possible to compile with an older header and
> use a newer .so at runtime.

Retrofitting a stable API/ABI to the melting pot which is libxc simply
isn't going to work in practice.

IMO the most likely to succeed approach would be to split off the bits
of libxc which 3rd party's can/should/need to rely on into one of more
libraries, probably by functional area.

So far I'm aware of plans (or at least desires) to do that for:

      * Interfaces used by device-models/qemu.
      * The bits which are useful inside a guest (i.e. the
        various /dev/xen/* related helpers).

So it sounds like libxenkexec should be added to that list.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 09:50:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 09:50:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtvi8-00059P-KK; Thu, 27 Nov 2014 09:50:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xtvi7-00059K-1h
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 09:50:03 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	86/A1-24859-AC3F6745; Thu, 27 Nov 2014 09:50:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417081800!14190088!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15767 invoked from network); 27 Nov 2014 09:50:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 09:50:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197122809"
Message-ID: <1417081768.11944.70.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 27 Nov 2014 09:49:28 +0000
In-Reply-To: <5475E311.6070501@citrix.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com> <5475E311.6070501@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-11-26 at 14:26 +0000, Andrew Cooper wrote:
> libxc (or some new alternative) should suck it up and gain some notion
> of a stable API or ABI (like the rest of the world appears to be able to
> manage), such that it is possible to compile with an older header and
> use a newer .so at runtime.

Retrofitting a stable API/ABI to the melting pot which is libxc simply
isn't going to work in practice.

IMO the most likely to succeed approach would be to split off the bits
of libxc which 3rd party's can/should/need to rely on into one of more
libraries, probably by functional area.

So far I'm aware of plans (or at least desires) to do that for:

      * Interfaces used by device-models/qemu.
      * The bits which are useful inside a guest (i.e. the
        various /dev/xen/* related helpers).

So it sounds like libxenkexec should be added to that list.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:22:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:22:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwDX-00063S-Iq; Thu, 27 Nov 2014 10:22:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtwDW-00063N-AZ
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 10:22:30 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	93/91-01660-56BF6745; Thu, 27 Nov 2014 10:22:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417083747!13585284!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7767 invoked from network); 27 Nov 2014 10:22:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 10:22:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197389683"
Message-ID: <1417083745.12784.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 27 Nov 2014 10:22:25 +0000
In-Reply-To: <21622.4088.777274.315050@mariner.uk.xensource.com>
References: <1417005297.11944.43.camel@citrix.com>
	<21621.61406.151530.376288@mariner.uk.xensource.com>
	<1417016402.11944.60.camel@citrix.com>
	<1417017154.11944.63.camel@citrix.com>
	<21622.4088.777274.315050@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] segv in osevent_release_nexus with libxl backend to
 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, 2014-11-26 at 17:38 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] segv in osevent_release_nexus with libxl backend to libvirt"):
> > I don't know if this helps but on the 3 occasions I've just looked at
> > the ev passed to libxl__ev_fd_deregister contains an fd which
> > corresponds to a still open handle on /dev/xen/evtchn.
> 
> I see what is going on, I think.  The rules in libxl_event.h about
> when one can call libxl_event_register_callbacks are (a) impossibly
> lax and (b) not implemented even as far as possible.  The crash is due
> to the evtchn fd having been set up during libxl initialisation (while
> hooks==0) and therefore not having a `nexus', but being deregistered
> later.
> 
> AFAICT libvirt doesn't (I think) depend on anything which is
> particularly difficult to implement.  It seems to call
> libxl_event_register_callbacks in a relatively quiescent state.
> 
> I have prepared a set of patches which may help.  They are at
> xenbits.xen.org:ext/xen.git#for-ijc.

AKA git://xenbits.xen.org/people/iwj/xen.git for those of us without
your shell account ;-)

I tried this but on destroy with libvirt I get:
        libvirtd: libxl.c:168: libxl_ctx_free: Assertion `!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd)' failed.
        
        Program received signal SIGABRT, Aborted.
        [Switching to Thread 0xb57f9420 (LWP 7188)]
        0xb6ab7f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        (gdb) bt
        #0  0xb6ab7f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        #1  0xb6ac5f8a in raise () from /lib/arm-linux-gnueabihf/libc.so.6
        #2  0xb6ac8428 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
        #3  0xb6ac101e in __assert_fail ()
           from /lib/arm-linux-gnueabihf/libc.so.6
        #4  0xb16a48f4 in libxl_ctx_free (ctx=0xb6b7bbec) at libxl.c:168
        #5  0xb171814e in libxlDomainObjPrivateDispose ()
           from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #6  0xb6c69176 in virObjectUnref ()
           from /opt/libvirt/lib/libvirt.so.0
        #7  0xb17181d2 in libxlDomainObjPrivateFree ()
           from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #8  0xb6c9c0da in virDomainObjDispose ()
           from /opt/libvirt/lib/libvirt.so.0
        #9  0xb6c69176 in virObjectUnref ()
           from /opt/libvirt/lib/libvirt.so.0
        #10 0xb6c9ca26 in virDomainObjListRemove ()
           from /opt/libvirt/lib/libvirt.so.0
        #11 0xb171c548 in libxlDomainDestroyFlags ()

and similarly on create with xl I see:

        xl: libxl.c:168: libxl_ctx_free: Assertion `!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd)' failed.
        
        Program received signal SIGABRT, Aborted.
        0xb6e10f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        (gdb) bt
        #0  0xb6e10f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        #1  0xb6e1ef8a in raise () from /lib/arm-linux-gnueabihf/libc.so.6
        #2  0xb6e21428 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
        #3  0xb6e1a01e in __assert_fail () from /lib/arm-linux-gnueabihf/libc.so.6
        #4  0xb6f628f4 in libxl_ctx_free (ctx=0xb6ed4bec) at libxl.c:168
        #5  0x0000daa0 in xl_ctx_free () at xl.c:283
        #6  0xb6e22426 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        #7  0xb6e10cfe in __libc_start_main () from /lib/arm-linux-gnueabihf/libc.so.6
        #8  0x0000da26 in _start ()
        
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:22:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:22:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwDX-00063S-Iq; Thu, 27 Nov 2014 10:22:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtwDW-00063N-AZ
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 10:22:30 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	93/91-01660-56BF6745; Thu, 27 Nov 2014 10:22:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417083747!13585284!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7767 invoked from network); 27 Nov 2014 10:22:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 10:22:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197389683"
Message-ID: <1417083745.12784.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 27 Nov 2014 10:22:25 +0000
In-Reply-To: <21622.4088.777274.315050@mariner.uk.xensource.com>
References: <1417005297.11944.43.camel@citrix.com>
	<21621.61406.151530.376288@mariner.uk.xensource.com>
	<1417016402.11944.60.camel@citrix.com>
	<1417017154.11944.63.camel@citrix.com>
	<21622.4088.777274.315050@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] segv in osevent_release_nexus with libxl backend to
 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, 2014-11-26 at 17:38 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] segv in osevent_release_nexus with libxl backend to libvirt"):
> > I don't know if this helps but on the 3 occasions I've just looked at
> > the ev passed to libxl__ev_fd_deregister contains an fd which
> > corresponds to a still open handle on /dev/xen/evtchn.
> 
> I see what is going on, I think.  The rules in libxl_event.h about
> when one can call libxl_event_register_callbacks are (a) impossibly
> lax and (b) not implemented even as far as possible.  The crash is due
> to the evtchn fd having been set up during libxl initialisation (while
> hooks==0) and therefore not having a `nexus', but being deregistered
> later.
> 
> AFAICT libvirt doesn't (I think) depend on anything which is
> particularly difficult to implement.  It seems to call
> libxl_event_register_callbacks in a relatively quiescent state.
> 
> I have prepared a set of patches which may help.  They are at
> xenbits.xen.org:ext/xen.git#for-ijc.

AKA git://xenbits.xen.org/people/iwj/xen.git for those of us without
your shell account ;-)

I tried this but on destroy with libvirt I get:
        libvirtd: libxl.c:168: libxl_ctx_free: Assertion `!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd)' failed.
        
        Program received signal SIGABRT, Aborted.
        [Switching to Thread 0xb57f9420 (LWP 7188)]
        0xb6ab7f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        (gdb) bt
        #0  0xb6ab7f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        #1  0xb6ac5f8a in raise () from /lib/arm-linux-gnueabihf/libc.so.6
        #2  0xb6ac8428 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
        #3  0xb6ac101e in __assert_fail ()
           from /lib/arm-linux-gnueabihf/libc.so.6
        #4  0xb16a48f4 in libxl_ctx_free (ctx=0xb6b7bbec) at libxl.c:168
        #5  0xb171814e in libxlDomainObjPrivateDispose ()
           from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #6  0xb6c69176 in virObjectUnref ()
           from /opt/libvirt/lib/libvirt.so.0
        #7  0xb17181d2 in libxlDomainObjPrivateFree ()
           from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
        #8  0xb6c9c0da in virDomainObjDispose ()
           from /opt/libvirt/lib/libvirt.so.0
        #9  0xb6c69176 in virObjectUnref ()
           from /opt/libvirt/lib/libvirt.so.0
        #10 0xb6c9ca26 in virDomainObjListRemove ()
           from /opt/libvirt/lib/libvirt.so.0
        #11 0xb171c548 in libxlDomainDestroyFlags ()

and similarly on create with xl I see:

        xl: libxl.c:168: libxl_ctx_free: Assertion `!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd)' failed.
        
        Program received signal SIGABRT, Aborted.
        0xb6e10f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        (gdb) bt
        #0  0xb6e10f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        #1  0xb6e1ef8a in raise () from /lib/arm-linux-gnueabihf/libc.so.6
        #2  0xb6e21428 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
        #3  0xb6e1a01e in __assert_fail () from /lib/arm-linux-gnueabihf/libc.so.6
        #4  0xb6f628f4 in libxl_ctx_free (ctx=0xb6ed4bec) at libxl.c:168
        #5  0x0000daa0 in xl_ctx_free () at xl.c:283
        #6  0xb6e22426 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
        #7  0xb6e10cfe in __libc_start_main () from /lib/arm-linux-gnueabihf/libc.so.6
        #8  0x0000da26 in _start ()
        
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:23:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:23:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwEa-00069n-33; Thu, 27 Nov 2014 10:23:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XtwEY-00069Y-0U
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 10:23:34 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CB/A2-25276-5ABF6745; Thu, 27 Nov 2014 10:23:33 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417083811!15669133!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31533 invoked from network); 27 Nov 2014 10:23:32 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-4.tower-21.messagelabs.com with SMTP;
	27 Nov 2014 10:23:32 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sARANOTe012899;
	Thu, 27 Nov 2014 04:23:25 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sARANOnS012898;
	Thu, 27 Nov 2014 04:23:24 -0600
Date: Thu, 27 Nov 2014 04:23:24 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201411271023.sARANOnS012898@wind.enjellic.com>
In-Reply-To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
	"Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind." (Nov
	24, 1:28pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Thu, 27 Nov 2014 04:23:25 -0600 (CST)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Nov 24,  1:28pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:

> Hello,

Hi, hope the week is going well for everyone.

> > >> As I was walking out the door I remembered I had been delinquent
> > >> with information.  The dom0 kernel is 32-bit 3.14.22 straight from
> > >> kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.
> > 
> > > Wow, quite an old thread :)
> > >  
> > > So you're still seeing the same problem with recent Xen/Linux
> > > versions.. 
> > 
> > Yes, the perils of platforming for 7 year field deployments... :-)
> > 
> > I can certainly build up a toolchain against the HEAD of XEN git and
> > the most recent release of the kernel if everyone feels that would be
> > beneficial.
> > 
> > > This might be a stupid question, but here goes anyway: Do you have
> > > serial console set up? And all the debug/verbose options specified
> > > for Xen and Linux?
> > 
> > The platform in question doesn't have any serial ports, at least not
> > surfaced.  We will need to do a bit of wiring if we need to go in that
> > direction.

> You mentioned it's Intel Q77 chipset based motherboard..  which
> means it should have Intel AMT functionality, which provides SOL
> (Serial-over-LAN), which you can use as a serial console for Xen.
>
> There are tools (at least amtterm) that you can use on another box
> to connect to the AMT SOL remotely..

So we wired up serial console connectivity to the test box and
repeated the VGA device binding with loglvl=all.  We lost the box
immediately without anything being written to the logs.

So we went hunting.

Interestingly the problem appears to be secondary to a BIOS
configuration option.  This may be specific to this platform but we
wanted to get it documented in the thread in case anyone else runs
into this.

The DQ77KB BIOS we are using has an option for 'IGD flat panel
display'.  The default option is LVDS, setting this to 'disabled'
clears the problem.

I haven't run down where things go wrong in pci_stub but I assume it
does something to the hardware which causes a problem when the video
controller is reset and then shutdown.

> > Now that I have the machine in a harness in the lab I will stick a
> > '#define DEBUG 1' in the top of drivers/xen/xen-pciback/pci_stub.c
> > since that is where the action seems to be going on.
> > 
> > The platform is headed for a measured computing environment so I
> > thought there may be some type of conflict with tboot holding a
> > reference to the VGA driver but I verified the issue in a straight
> > hypervisor boot.
> > 
> > I see that Tiejun Chen from Intel is sorting out issues with respect
> > to the need to export the ISA bridge into the device emulator in order
> > to support passthrough on these IGD devices.  I bound the 00:1f.0 ISA
> > bridge device to pciback and that worked but it did not change the
> > behavior of the regression.  When the 00:02.0 device is bound to
> > pciback the display is cleared and the machine dies in its tracks.

> Yeah, Tiejun is working on upstreaming the IGD passthru patches to
> Qemu-upstream.
>
> Qemu-dm-traditional already has (most of) the IGD passthru patches. 
> 
> Hope that helps,

So we are obviously working with qemu-dm-traditional and with the
IGD/LVDS BIOS configuration issue fixed the adapater passthrough is
working and Windows7 is coming up and detecting the IGD as a standard
VGA display adapter.  Additional invocations of the VM after the first
one result in failed passthrough with a garbled display.

I spent an afternoon wandering through the mailing lists and found
what I think are the two patches which are needed to map the 00:1f.0
ISA bridge device into the guest.  From the discussions surrounding
those patches it appears as if the Windows HD driver needs addresses
managed by that bridge to recognize the IGD device.

I will get those patches wired into qemu-dm-traditional and tested in
between whisky, wine, turkey and napping today.... :-)

I'm hoping that this positively impacts the ability to execute
multiple sessions.  I will report back the results so we have all of
this in the mailing list record.

> -- Pasi

Thanks for offering the pointers, have a good day.

Greg

}-- End of excerpt from Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Immortality is an adequate definition of high availability for me."
                                -- Gregory F. Pfister


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:23:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:23:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwEa-00069n-33; Thu, 27 Nov 2014 10:23:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XtwEY-00069Y-0U
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 10:23:34 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CB/A2-25276-5ABF6745; Thu, 27 Nov 2014 10:23:33 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417083811!15669133!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31533 invoked from network); 27 Nov 2014 10:23:32 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-4.tower-21.messagelabs.com with SMTP;
	27 Nov 2014 10:23:32 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sARANOTe012899;
	Thu, 27 Nov 2014 04:23:25 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sARANOnS012898;
	Thu, 27 Nov 2014 04:23:24 -0600
Date: Thu, 27 Nov 2014 04:23:24 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201411271023.sARANOnS012898@wind.enjellic.com>
In-Reply-To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
	"Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind." (Nov
	24, 1:28pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Thu, 27 Nov 2014 04:23:25 -0600 (CST)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Nov 24,  1:28pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:

> Hello,

Hi, hope the week is going well for everyone.

> > >> As I was walking out the door I remembered I had been delinquent
> > >> with information.  The dom0 kernel is 32-bit 3.14.22 straight from
> > >> kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.
> > 
> > > Wow, quite an old thread :)
> > >  
> > > So you're still seeing the same problem with recent Xen/Linux
> > > versions.. 
> > 
> > Yes, the perils of platforming for 7 year field deployments... :-)
> > 
> > I can certainly build up a toolchain against the HEAD of XEN git and
> > the most recent release of the kernel if everyone feels that would be
> > beneficial.
> > 
> > > This might be a stupid question, but here goes anyway: Do you have
> > > serial console set up? And all the debug/verbose options specified
> > > for Xen and Linux?
> > 
> > The platform in question doesn't have any serial ports, at least not
> > surfaced.  We will need to do a bit of wiring if we need to go in that
> > direction.

> You mentioned it's Intel Q77 chipset based motherboard..  which
> means it should have Intel AMT functionality, which provides SOL
> (Serial-over-LAN), which you can use as a serial console for Xen.
>
> There are tools (at least amtterm) that you can use on another box
> to connect to the AMT SOL remotely..

So we wired up serial console connectivity to the test box and
repeated the VGA device binding with loglvl=all.  We lost the box
immediately without anything being written to the logs.

So we went hunting.

Interestingly the problem appears to be secondary to a BIOS
configuration option.  This may be specific to this platform but we
wanted to get it documented in the thread in case anyone else runs
into this.

The DQ77KB BIOS we are using has an option for 'IGD flat panel
display'.  The default option is LVDS, setting this to 'disabled'
clears the problem.

I haven't run down where things go wrong in pci_stub but I assume it
does something to the hardware which causes a problem when the video
controller is reset and then shutdown.

> > Now that I have the machine in a harness in the lab I will stick a
> > '#define DEBUG 1' in the top of drivers/xen/xen-pciback/pci_stub.c
> > since that is where the action seems to be going on.
> > 
> > The platform is headed for a measured computing environment so I
> > thought there may be some type of conflict with tboot holding a
> > reference to the VGA driver but I verified the issue in a straight
> > hypervisor boot.
> > 
> > I see that Tiejun Chen from Intel is sorting out issues with respect
> > to the need to export the ISA bridge into the device emulator in order
> > to support passthrough on these IGD devices.  I bound the 00:1f.0 ISA
> > bridge device to pciback and that worked but it did not change the
> > behavior of the regression.  When the 00:02.0 device is bound to
> > pciback the display is cleared and the machine dies in its tracks.

> Yeah, Tiejun is working on upstreaming the IGD passthru patches to
> Qemu-upstream.
>
> Qemu-dm-traditional already has (most of) the IGD passthru patches. 
> 
> Hope that helps,

So we are obviously working with qemu-dm-traditional and with the
IGD/LVDS BIOS configuration issue fixed the adapater passthrough is
working and Windows7 is coming up and detecting the IGD as a standard
VGA display adapter.  Additional invocations of the VM after the first
one result in failed passthrough with a garbled display.

I spent an afternoon wandering through the mailing lists and found
what I think are the two patches which are needed to map the 00:1f.0
ISA bridge device into the guest.  From the discussions surrounding
those patches it appears as if the Windows HD driver needs addresses
managed by that bridge to recognize the IGD device.

I will get those patches wired into qemu-dm-traditional and tested in
between whisky, wine, turkey and napping today.... :-)

I'm hoping that this positively impacts the ability to execute
multiple sessions.  I will report back the results so we have all of
this in the mailing list record.

> -- Pasi

Thanks for offering the pointers, have a good day.

Greg

}-- End of excerpt from Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Immortality is an adequate definition of high availability for me."
                                -- Gregory F. Pfister


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:27:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwI2-0006Kw-Od; Thu, 27 Nov 2014 10:27:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XtwI1-0006Ko-NR
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 10:27:09 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	DF/7E-29352-D7CF6745; Thu, 27 Nov 2014 10:27:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417084028!13630587!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19561 invoked from network); 27 Nov 2014 10:27:08 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 10:27:08 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XtwHi-00046J-UE; Thu, 27 Nov 2014 10:26:50 +0000
Date: Thu, 27 Nov 2014 11:26:50 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141127102650.GA13234@deinos.phlegethon.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5476F1F5020000780004B0BC@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
> >>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
> > My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
> > identify a failed vmentry and lets it fall into the default case of the
> > vmexit handler.  As such, with v1, the infinite loop still affects AMD
> > hardware.
> 
> Right; I should have said "something along the lines of v1". An SVM
> part is needed, but that should probably extend beyond what you
> proposed in v2: There are a number of "goto exit_and_crash"
> statements ahead of where you place your addition. I think they
> all need to be treated similarly.
> 
> I therefore think we should revert the VMX part of 28b4baacd5
> and make SVM behavior consistent with what results for VMX:
> Crash the guest unconditionally on VMEXIT_INVALID, without
> looking for recurring VM entry failures. See below/attached.
> 
> Jan
> 
> x86/HVM: prevent infinite VM entry retries
> 
> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
> guest upon problems occurring in user mode") and gets SVM in line with
> the resulting VMX behavior. This is because Andrew validly says
> 
> "A failed vmentry is overwhelmingly likely to be caused by corrupt
>  VMC[SB] state.  As a result, injecting a fault and retrying the the
>  vmentry is likely to fail in the same way."
> 
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Looking at the SVM side, AFAICT you're trying to filter out
VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
think it's fine just to always crash on nested-SVM failures: we know
the guest wasn't in user mode because it successfully executed VMRUN.
And looking at it, the other users of that label are for unexpected
debugging exits, which can't be caused by the guest userspace either.

So how about this for the SVM side, reverting to crashing for
everything except new, unsupported exit types?

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 8aca6e6..8d28578 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2675,16 +2675,18 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
         break;
 
     default:
-    exit_and_crash:
         gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", "
                  "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
                  exit_reason, 
                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
-        if ( vmcb_get_cpl(vmcb) )
+        if ( vmcb_get_cpl(vmcb) ) {
             hvm_inject_hw_exception(TRAP_invalid_op,
                                     HVM_DELIVER_NO_ERROR_CODE);
-        else
-            domain_crash(v->domain);
+            break;
+        }
+        /* else fall through */
+    exit_and_crash:
+        domain_crash(v->domain);
         break;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:27:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwI2-0006Kw-Od; Thu, 27 Nov 2014 10:27:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XtwI1-0006Ko-NR
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 10:27:09 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	DF/7E-29352-D7CF6745; Thu, 27 Nov 2014 10:27:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417084028!13630587!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19561 invoked from network); 27 Nov 2014 10:27:08 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 10:27:08 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XtwHi-00046J-UE; Thu, 27 Nov 2014 10:26:50 +0000
Date: Thu, 27 Nov 2014 11:26:50 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141127102650.GA13234@deinos.phlegethon.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5476F1F5020000780004B0BC@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
> >>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
> > My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
> > identify a failed vmentry and lets it fall into the default case of the
> > vmexit handler.  As such, with v1, the infinite loop still affects AMD
> > hardware.
> 
> Right; I should have said "something along the lines of v1". An SVM
> part is needed, but that should probably extend beyond what you
> proposed in v2: There are a number of "goto exit_and_crash"
> statements ahead of where you place your addition. I think they
> all need to be treated similarly.
> 
> I therefore think we should revert the VMX part of 28b4baacd5
> and make SVM behavior consistent with what results for VMX:
> Crash the guest unconditionally on VMEXIT_INVALID, without
> looking for recurring VM entry failures. See below/attached.
> 
> Jan
> 
> x86/HVM: prevent infinite VM entry retries
> 
> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
> guest upon problems occurring in user mode") and gets SVM in line with
> the resulting VMX behavior. This is because Andrew validly says
> 
> "A failed vmentry is overwhelmingly likely to be caused by corrupt
>  VMC[SB] state.  As a result, injecting a fault and retrying the the
>  vmentry is likely to fail in the same way."
> 
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Looking at the SVM side, AFAICT you're trying to filter out
VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
think it's fine just to always crash on nested-SVM failures: we know
the guest wasn't in user mode because it successfully executed VMRUN.
And looking at it, the other users of that label are for unexpected
debugging exits, which can't be caused by the guest userspace either.

So how about this for the SVM side, reverting to crashing for
everything except new, unsupported exit types?

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 8aca6e6..8d28578 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2675,16 +2675,18 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
         break;
 
     default:
-    exit_and_crash:
         gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", "
                  "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
                  exit_reason, 
                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
-        if ( vmcb_get_cpl(vmcb) )
+        if ( vmcb_get_cpl(vmcb) ) {
             hvm_inject_hw_exception(TRAP_invalid_op,
                                     HVM_DELIVER_NO_ERROR_CODE);
-        else
-            domain_crash(v->domain);
+            break;
+        }
+        /* else fall through */
+    exit_and_crash:
+        domain_crash(v->domain);
         break;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:40:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:40:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwVB-0006dn-54; Thu, 27 Nov 2014 10:40: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 1XtwV9-0006dg-Vc
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 10:40:44 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	2B/69-11581-BAFF6745; Thu, 27 Nov 2014 10:40:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417084841!13595667!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21862 invoked from network); 27 Nov 2014 10:40:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 10:40:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197394238"
Message-ID: <1417084837.12784.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Thu, 27 Nov 2014 10:40:37 +0000
In-Reply-To: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
 Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 17:44 +0000, Julien Grall wrote:
> ARMv8 model may not disable correctly the timer interrupt when Xen

"correct disable"

> context switch to an idle vCPU. Therefore Xen may receive a spurious

"context switches" and s/spurious/unexpected/ (since spurious has a
specific meaning in the h/w which does not match what is happening here)

> timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
> when trying to inject the interrupt with the following stack trace.
> 
> (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
> (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
> (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
> (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
> (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
> (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
> (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
> (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
> (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
> (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
> (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
> (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
> (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
> (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
> (XEN)    [<0000000000000001>] 0000000000000001
> 
> While we receive spurious virtual timer interrupt, this could be safely
> ignore for the time being. A proper fix need to be found for Xen 4.6.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although I wonder if we should log, perhaps rate limited or only once.

Also, I've some grammar nits (above and below) which I can fix on commit
if there is no resend...

> 
> ---
> 
> This patch is a bug fix candidate for Xen 4.5. Any ARMv8 model may
> randomly crash when running Xen.

CCing Konrad.

> This patch don't inject the virtual timer interrupt if the current VCPU
> is the idle one. Entering in this function with the idle VCPU is already
> a bug itself. For now, I think this patch is the safest way to resolve
> the problem.
> 
> Meanwhile, I'm investigating with ARM to see wheter the bug comes from
> Xen or the model.
> ---
>  xen/arch/arm/time.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index a6436f1..83c74cb 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -169,6 +169,14 @@ static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
>  
>  static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
>  {
> +    /*
> +     * ARMv8 model may not disable correctly the timer interrupt when

"correctly disable"

> +     * Xen context switch to an idle vCPU. Therefore Xen may receive

"context switches" and "may receive an unexpected timer interrupt"

> +     * timer interrupt.
> +     */
> +    if ( is_idle_vcpu(current) )
> +        return;
> +
>      current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
>      WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
>      vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:40:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:40:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwVB-0006dn-54; Thu, 27 Nov 2014 10:40: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 1XtwV9-0006dg-Vc
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 10:40:44 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	2B/69-11581-BAFF6745; Thu, 27 Nov 2014 10:40:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417084841!13595667!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21862 invoked from network); 27 Nov 2014 10:40:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 10:40:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197394238"
Message-ID: <1417084837.12784.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Thu, 27 Nov 2014 10:40:37 +0000
In-Reply-To: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
 Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 17:44 +0000, Julien Grall wrote:
> ARMv8 model may not disable correctly the timer interrupt when Xen

"correct disable"

> context switch to an idle vCPU. Therefore Xen may receive a spurious

"context switches" and s/spurious/unexpected/ (since spurious has a
specific meaning in the h/w which does not match what is happening here)

> timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
> when trying to inject the interrupt with the following stack trace.
> 
> (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
> (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
> (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
> (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
> (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
> (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
> (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
> (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
> (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
> (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
> (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
> (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
> (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
> (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
> (XEN)    [<0000000000000001>] 0000000000000001
> 
> While we receive spurious virtual timer interrupt, this could be safely
> ignore for the time being. A proper fix need to be found for Xen 4.6.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although I wonder if we should log, perhaps rate limited or only once.

Also, I've some grammar nits (above and below) which I can fix on commit
if there is no resend...

> 
> ---
> 
> This patch is a bug fix candidate for Xen 4.5. Any ARMv8 model may
> randomly crash when running Xen.

CCing Konrad.

> This patch don't inject the virtual timer interrupt if the current VCPU
> is the idle one. Entering in this function with the idle VCPU is already
> a bug itself. For now, I think this patch is the safest way to resolve
> the problem.
> 
> Meanwhile, I'm investigating with ARM to see wheter the bug comes from
> Xen or the model.
> ---
>  xen/arch/arm/time.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index a6436f1..83c74cb 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -169,6 +169,14 @@ static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
>  
>  static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
>  {
> +    /*
> +     * ARMv8 model may not disable correctly the timer interrupt when

"correctly disable"

> +     * Xen context switch to an idle vCPU. Therefore Xen may receive

"context switches" and "may receive an unexpected timer interrupt"

> +     * timer interrupt.
> +     */
> +    if ( is_idle_vcpu(current) )
> +        return;
> +
>      current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
>      WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
>      vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:42:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwX4-0006sm-Kz; Thu, 27 Nov 2014 10:42:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtwX2-0006sg-Ov
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 10:42:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0C/18-25276-02007745; Thu, 27 Nov 2014 10:42:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417084959!15741024!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2169 invoked from network); 27 Nov 2014 10:42:39 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 10:42:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 10:42:39 +0000
Message-Id: <54770E2F020000780004B199@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 10:42:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dunlapg@umich.edu, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xsm/flask: improve unknown permission
 handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.11.14 at 19:05, <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -135,6 +135,19 @@ static int get_irq_sid(int irq, u32 *sid, struct 
> avc_audit_data *ad)
>      return 0;
>  }
>  
> +static int avc_unknown_permission(const char* name, int id)

const char *name

> +{
> +    /* A guest making an invalid hypercall can trigger this message, so it can't
> +     * be an ASSERT or BUG_ON, but normally it is caused by a missing case in
> +     * one of the switch statements below.
> +     */
> +    printk(XENLOG_G_ERR "FLASK: Unknown %s: %d.\n", name, id);

I think this ought to be XENLOG_G_WARNING when not returning
an error. E.g. switch printing and return code determination, use
the return code to select the correct log level, and return after
logging the message.

Jan

> +    if ( !flask_enforcing || security_get_allow_unknown() )
> +        return 0;
> +    else
> +        return -EPERM;
> +}
> +
>  static int flask_domain_alloc_security(struct domain *d)
>  {
>      struct domain_security_struct *dsec;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:42:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwX4-0006sm-Kz; Thu, 27 Nov 2014 10:42:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtwX2-0006sg-Ov
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 10:42:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0C/18-25276-02007745; Thu, 27 Nov 2014 10:42:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417084959!15741024!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2169 invoked from network); 27 Nov 2014 10:42:39 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 10:42:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 10:42:39 +0000
Message-Id: <54770E2F020000780004B199@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 10:42:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dunlapg@umich.edu, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xsm/flask: improve unknown permission
 handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.11.14 at 19:05, <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -135,6 +135,19 @@ static int get_irq_sid(int irq, u32 *sid, struct 
> avc_audit_data *ad)
>      return 0;
>  }
>  
> +static int avc_unknown_permission(const char* name, int id)

const char *name

> +{
> +    /* A guest making an invalid hypercall can trigger this message, so it can't
> +     * be an ASSERT or BUG_ON, but normally it is caused by a missing case in
> +     * one of the switch statements below.
> +     */
> +    printk(XENLOG_G_ERR "FLASK: Unknown %s: %d.\n", name, id);

I think this ought to be XENLOG_G_WARNING when not returning
an error. E.g. switch printing and return code determination, use
the return code to select the correct log level, and return after
logging the message.

Jan

> +    if ( !flask_enforcing || security_get_allow_unknown() )
> +        return 0;
> +    else
> +        return -EPERM;
> +}
> +
>  static int flask_domain_alloc_security(struct domain *d)
>  {
>      struct domain_security_struct *dsec;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:48:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:48:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtwce-00073B-ER; Thu, 27 Nov 2014 10:48:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xtwcd-000736-Pr
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 10:48:28 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	51/A5-25547-B7107745; Thu, 27 Nov 2014 10:48:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417085305!14265199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25150 invoked from network); 27 Nov 2014 10:48:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 10:48:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197396180"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 05:48:24 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xtwca-0007pR-5e;
	Thu, 27 Nov 2014 10:48:24 +0000
Date: Thu, 27 Nov 2014 10:48:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Don Slutz <dslutz@verizon.com>
In-Reply-To: <54768F7F.2030602@terremark.com>
Message-ID: <alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
	<5474C96A.6090506@citrix.com>
	<alpine.DEB.2.02.1411261817330.14135@kaball.uk.xensource.com>
	<54768F7F.2030602@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] increase maxmem before calling
 xc_domain_populate_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Nov 2014, Don Slutz wrote:
> On 11/26/14 13:17, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Andrew Cooper wrote:
> > > On 25/11/14 17:45, Stefano Stabellini wrote:
> > > > Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
> > > > the risk of running out of guest memory. This way we can also avoid
> > > > complex memory calculations in libxl at domain construction time.
> > > > 
> > > > This patch fixes an abort() when assigning more than 4 NICs to a VM.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > 
> > > > diff --git a/xen-hvm.c b/xen-hvm.c
> > > > index 5c69a8d..38e08c3 100644
> > > > --- a/xen-hvm.c
> > > > +++ b/xen-hvm.c
> > > > @@ -218,6 +218,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
> > > > size, MemoryRegion *mr)
> > > >       unsigned long nr_pfn;
> > > >       xen_pfn_t *pfn_list;
> > > >       int i;
> > > > +    xc_dominfo_t info;
> > > >         if (runstate_check(RUN_STATE_INMIGRATE)) {
> > > >           /* RAM already populated in Xen */
> > > > @@ -240,6 +241,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
> > > > size, MemoryRegion *mr)
> > > >           pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
> > > >       }
> > > >   +    if (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) < 0) {
> > > xc_domain_getinfo()'s interface is mad, and provides no guarantee that
> > > it returns the information for the domain you requested.  It also won't
> > > return -1 on error.  The correct error handing is:
> > > 
> > > (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) || (info.domid !=
> > > xen_domid)
> > It might be wiser to switch to xc_domain_getinfolist
> 
> Either needs the same tests, since both return an vector of info.

Right


> > > ~Andrew
> > > 
> > > > +        hw_error("xc_domain_getinfo failed");
> > > > +    }
> > > > +    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> > > > +                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
> 
> There are two big issues and 1 minor one with this.
> 1) You will allocate the videoram again.
> 2) You will never use the 1 MB already allocated for option ROMs.
>
> And the minor one is that you can increase maxmem more then is needed.

I don't understand: are you aware that setmaxmem doesn't allocate any
memory, just raises the maximum amount of memory allowed for the domain
to have?

But you are right that we would raise the limit more than it could be,
specifically the videoram would get accounted for twice and we wouldn't
need LIBXL_MAXMEM_CONSTANT. I guess we would have to write a patch for
that.



> Here is a better if:
> 
> -    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> -                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
> +    max_pages = info.max_memkb * 1024 / XC_PAGE_SIZE;
> +    free_pages = max_pages - info.nr_pages;
> +    need_pages = nr_pfn - free_pages;
> +    if ((free_pages < nr_pfn) &&
> +       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> +                            (need_pages * XC_PAGE_SIZE / 1024)) < 0)) {

That's an interesting idea, but I am not sure if it is safe in all
configurations.

It could make QEMU work better with older libxl and avoid increasing
maxmem more than necessary.
On the other hand I guess it could break things when PoD is used, or in
general when the user purposely sets maxmem on the vm config file.


> My testing shows a free 32 pages that I am not sure where they come from.  But
> the code about is passing my 8 nics of e1000.

I think that raising maxmem a bit higher than necessary is not too bad.
If we really care about it, we could lower the limit after QEMU's
initialization is completed.


>    -Don Slutz
> 
> 
> > > > +        hw_error("xc_domain_setmaxmem failed");
> > > > +    }
> > > >       if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0,
> > > > 0, pfn_list)) {
> > > >           hw_error("xen: failed to populate ram at " RAM_ADDR_FMT,
> > > > ram_addr);
> > > >       }
> > > > 
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org
> > > > http://lists.xen.org/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 Nov 27 10:48:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:48:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtwce-00073B-ER; Thu, 27 Nov 2014 10:48:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xtwcd-000736-Pr
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 10:48:28 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	51/A5-25547-B7107745; Thu, 27 Nov 2014 10:48:27 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417085305!14265199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25150 invoked from network); 27 Nov 2014 10:48:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 10:48:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197396180"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 05:48:24 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xtwca-0007pR-5e;
	Thu, 27 Nov 2014 10:48:24 +0000
Date: Thu, 27 Nov 2014 10:48:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Don Slutz <dslutz@verizon.com>
In-Reply-To: <54768F7F.2030602@terremark.com>
Message-ID: <alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251742280.14135@kaball.uk.xensource.com>
	<5474C96A.6090506@citrix.com>
	<alpine.DEB.2.02.1411261817330.14135@kaball.uk.xensource.com>
	<54768F7F.2030602@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] increase maxmem before calling
 xc_domain_populate_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Nov 2014, Don Slutz wrote:
> On 11/26/14 13:17, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Andrew Cooper wrote:
> > > On 25/11/14 17:45, Stefano Stabellini wrote:
> > > > Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
> > > > the risk of running out of guest memory. This way we can also avoid
> > > > complex memory calculations in libxl at domain construction time.
> > > > 
> > > > This patch fixes an abort() when assigning more than 4 NICs to a VM.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > 
> > > > diff --git a/xen-hvm.c b/xen-hvm.c
> > > > index 5c69a8d..38e08c3 100644
> > > > --- a/xen-hvm.c
> > > > +++ b/xen-hvm.c
> > > > @@ -218,6 +218,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
> > > > size, MemoryRegion *mr)
> > > >       unsigned long nr_pfn;
> > > >       xen_pfn_t *pfn_list;
> > > >       int i;
> > > > +    xc_dominfo_t info;
> > > >         if (runstate_check(RUN_STATE_INMIGRATE)) {
> > > >           /* RAM already populated in Xen */
> > > > @@ -240,6 +241,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
> > > > size, MemoryRegion *mr)
> > > >           pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
> > > >       }
> > > >   +    if (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) < 0) {
> > > xc_domain_getinfo()'s interface is mad, and provides no guarantee that
> > > it returns the information for the domain you requested.  It also won't
> > > return -1 on error.  The correct error handing is:
> > > 
> > > (xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) || (info.domid !=
> > > xen_domid)
> > It might be wiser to switch to xc_domain_getinfolist
> 
> Either needs the same tests, since both return an vector of info.

Right


> > > ~Andrew
> > > 
> > > > +        hw_error("xc_domain_getinfo failed");
> > > > +    }
> > > > +    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> > > > +                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
> 
> There are two big issues and 1 minor one with this.
> 1) You will allocate the videoram again.
> 2) You will never use the 1 MB already allocated for option ROMs.
>
> And the minor one is that you can increase maxmem more then is needed.

I don't understand: are you aware that setmaxmem doesn't allocate any
memory, just raises the maximum amount of memory allowed for the domain
to have?

But you are right that we would raise the limit more than it could be,
specifically the videoram would get accounted for twice and we wouldn't
need LIBXL_MAXMEM_CONSTANT. I guess we would have to write a patch for
that.



> Here is a better if:
> 
> -    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> -                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
> +    max_pages = info.max_memkb * 1024 / XC_PAGE_SIZE;
> +    free_pages = max_pages - info.nr_pages;
> +    need_pages = nr_pfn - free_pages;
> +    if ((free_pages < nr_pfn) &&
> +       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> +                            (need_pages * XC_PAGE_SIZE / 1024)) < 0)) {

That's an interesting idea, but I am not sure if it is safe in all
configurations.

It could make QEMU work better with older libxl and avoid increasing
maxmem more than necessary.
On the other hand I guess it could break things when PoD is used, or in
general when the user purposely sets maxmem on the vm config file.


> My testing shows a free 32 pages that I am not sure where they come from.  But
> the code about is passing my 8 nics of e1000.

I think that raising maxmem a bit higher than necessary is not too bad.
If we really care about it, we could lower the limit after QEMU's
initialization is completed.


>    -Don Slutz
> 
> 
> > > > +        hw_error("xc_domain_setmaxmem failed");
> > > > +    }
> > > >       if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0,
> > > > 0, pfn_list)) {
> > > >           hw_error("xen: failed to populate ram at " RAM_ADDR_FMT,
> > > > ram_addr);
> > > >       }
> > > > 
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org
> > > > http://lists.xen.org/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 Nov 27 10:51:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtwfp-0007Br-6l; Thu, 27 Nov 2014 10:51:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1Xtwfn-0007Bi-Rj
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 10:51:43 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	3D/A2-09284-F3207745; Thu, 27 Nov 2014 10:51:43 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417085502!11760791!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23003 invoked from network); 27 Nov 2014 10:51:42 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 10:51:42 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=bKrgGxJg6SDMQFBgmWOOZAZK28oP5zsOSYlZa7tM9L6KRFKOa+bW1KE/jnvQ5wOu/3HEifQxjcyCqLV2l5GrfE971ZBXQYpC2ZLvpE667jsejIusTyKXKhEL3YOj88N/yHzf76cwEc+B1Q7xybBJxEzwdsbaRAuOXHPHFT+ASJYBo4fc6xuLhFY9G7U+OlhMiUDGrpTNIjjDfEnojw+cOLWt63ho7kbWLrY81YOweiSgzymbkBloUgkINTuAGi9MX0nY2BhQJsAMKl9XBK3XEwDI/gLOLKRg/ajoVHXdq7c6KqFM6ahy5acsDh3kZXD/p6z2aMHczTgTVuvWyZ5Imw==;
	h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=
	message-id:date:from:mime-version:to:subject:content-type
	:content-transfer-encoding; s=default; bh=vAzsG0R0auj056eO59cEir
	mADX4=; b=J0jW5KQ889vMm33lag7meoQkcTqvKKFDTrtmMteX7HhN78nUVRGSx3
	0Cg8dZOX7CRvhx/1RTsa0g3L7Ybg0aiFL9ur5yVVQKJVAP01G3ESRWQul+H7Y2w1
	mfDFezQMPIU5rKSQnD8bcF/0vbGrDenmcCxgxvfUSEZVnfZwGYbYSn4zNRWlvWAq
	tQUPzqmbnlat9GlxehUF1Z3SpomxofldkoJ/lp8T5ed7kUoeg4Z4mtoNYjLH/jdg
	i2f1FVw0Mbx0owBd0i3YcVYBSAGpi7C5PmcqPxXT+lnTKGACQJ/WQRaov/tZ3CIU
	amFPjcOIIOtBLowVeE3v2aXS1wCL4zWg==
Received: (qmail 15132 invoked from network); 27 Nov 2014 12:51:40 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	27 Nov 2014 12:51:40 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 7400A803D5
	for <xen-devel@lists.xen.org>; Thu, 27 Nov 2014 12:51:40 +0200 (EET)
Received: (qmail 22055 invoked from network); 27 Nov 2014 12:51:40 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by smtp03.buh.bitdefender.org with SMTP; 27 Nov 2014 12:51:40 +0200
Message-ID: <54770242.9000709@bitdefender.com>
Date: Thu, 27 Nov 2014 12:51:46 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.57977
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 373685,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_NO_LINK_NMD;
	NN_LEGIT_BITDEFENDER; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled], URL:
	[Enabled], RTDA: [Enabled, Hit: No, Details: v2.0.9; Id:
	2m1ghdn.197mem219.6qcnp], total: 0(775)
X-BitDefender-CF-Stamp: none
Subject: [Xen-devel] Xenstore.h clarifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 know that xc_interface_open() can be safely called several times from
the same process, and that several processes can each have a bunch of
xc_interface handles open, and that I shouldn't use an xc_interface
inherited from the parent in a child process, because xenctrl.h says so.

Is it safe to assume that the same restrictions / conventions apply to
xs_handles obtained via xs_open()? Xenstore.h is not explicit. Looking
at the code, it would seem safe to assume that it can be used in a
similar manner, but it would be nice to have this confirmed if possible.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:51:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtwg1-0007I2-Is; Thu, 27 Nov 2014 10:51:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xtwg0-0007Hm-3b
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 10:51:56 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F1/06-03145-B4207745; Thu, 27 Nov 2014 10:51:55 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417085510!14636940!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18658 invoked from network); 27 Nov 2014 10:51:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 10:51:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197396906"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 05:51:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xtwft-0007v2-4i;
	Thu, 27 Nov 2014 10:51:49 +0000
Date: Thu, 27 Nov 2014 10:51:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417084837.12784.5.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411271049130.14135@kaball.uk.xensource.com>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<1417084837.12784.5.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, tim@xen.org,
	Julien Grall <julien.grall@linaro.org>, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
 Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 27 Nov 2014, Ian Campbell wrote:
> On Tue, 2014-11-25 at 17:44 +0000, Julien Grall wrote:
> > ARMv8 model may not disable correctly the timer interrupt when Xen
> 
> "correct disable"
> 
> > context switch to an idle vCPU. Therefore Xen may receive a spurious
> 
> "context switches" and s/spurious/unexpected/ (since spurious has a
> specific meaning in the h/w which does not match what is happening here)
> 
> > timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
> > when trying to inject the interrupt with the following stack trace.
> > 
> > (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
> > (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
> > (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
> > (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
> > (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
> > (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
> > (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
> > (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
> > (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
> > (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
> > (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
> > (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
> > (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
> > (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
> > (XEN)    [<0000000000000001>] 0000000000000001
> > 
> > While we receive spurious virtual timer interrupt, this could be safely
> > ignore for the time being. A proper fix need to be found for Xen 4.6.
> > 
> > Signed-off-by: Julien Grall <julien.grall@linaro.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Although I wonder if we should log, perhaps rate limited or only once.
> 
> Also, I've some grammar nits (above and below) which I can fix on commit
> if there is no resend...
> 
> > 
> > ---
> > 
> > This patch is a bug fix candidate for Xen 4.5. Any ARMv8 model may
> > randomly crash when running Xen.
> 
> CCing Konrad.
> 
> > This patch don't inject the virtual timer interrupt if the current VCPU
> > is the idle one. Entering in this function with the idle VCPU is already
> > a bug itself. For now, I think this patch is the safest way to resolve
> > the problem.
> > 
> > Meanwhile, I'm investigating with ARM to see wheter the bug comes from
> > Xen or the model.

It is worth noting that there are no bad side effects of this change:
the vtimer_interrupt is always supposed to be received on non-idle
domains. As Julien wrote, the fact that we are receiving a
vtimer_interrupt in the idle_domain is a bug, one that probably comes
from the ARM model not emulating hardware correctly.


> >  xen/arch/arm/time.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> > index a6436f1..83c74cb 100644
> > --- a/xen/arch/arm/time.c
> > +++ b/xen/arch/arm/time.c
> > @@ -169,6 +169,14 @@ static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> >  
> >  static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> >  {
> > +    /*
> > +     * ARMv8 model may not disable correctly the timer interrupt when
> 
> "correctly disable"
> 
> > +     * Xen context switch to an idle vCPU. Therefore Xen may receive
> 
> "context switches" and "may receive an unexpected timer interrupt"
> 
> > +     * timer interrupt.
> > +     */
> > +    if ( is_idle_vcpu(current) )
> > +        return;
> > +
> >      current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
> >      WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
> >      vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq);
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:51:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtwfp-0007Br-6l; Thu, 27 Nov 2014 10:51:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1Xtwfn-0007Bi-Rj
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 10:51:43 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	3D/A2-09284-F3207745; Thu, 27 Nov 2014 10:51:43 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417085502!11760791!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23003 invoked from network); 27 Nov 2014 10:51:42 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 10:51:42 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=bKrgGxJg6SDMQFBgmWOOZAZK28oP5zsOSYlZa7tM9L6KRFKOa+bW1KE/jnvQ5wOu/3HEifQxjcyCqLV2l5GrfE971ZBXQYpC2ZLvpE667jsejIusTyKXKhEL3YOj88N/yHzf76cwEc+B1Q7xybBJxEzwdsbaRAuOXHPHFT+ASJYBo4fc6xuLhFY9G7U+OlhMiUDGrpTNIjjDfEnojw+cOLWt63ho7kbWLrY81YOweiSgzymbkBloUgkINTuAGi9MX0nY2BhQJsAMKl9XBK3XEwDI/gLOLKRg/ajoVHXdq7c6KqFM6ahy5acsDh3kZXD/p6z2aMHczTgTVuvWyZ5Imw==;
	h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=
	message-id:date:from:mime-version:to:subject:content-type
	:content-transfer-encoding; s=default; bh=vAzsG0R0auj056eO59cEir
	mADX4=; b=J0jW5KQ889vMm33lag7meoQkcTqvKKFDTrtmMteX7HhN78nUVRGSx3
	0Cg8dZOX7CRvhx/1RTsa0g3L7Ybg0aiFL9ur5yVVQKJVAP01G3ESRWQul+H7Y2w1
	mfDFezQMPIU5rKSQnD8bcF/0vbGrDenmcCxgxvfUSEZVnfZwGYbYSn4zNRWlvWAq
	tQUPzqmbnlat9GlxehUF1Z3SpomxofldkoJ/lp8T5ed7kUoeg4Z4mtoNYjLH/jdg
	i2f1FVw0Mbx0owBd0i3YcVYBSAGpi7C5PmcqPxXT+lnTKGACQJ/WQRaov/tZ3CIU
	amFPjcOIIOtBLowVeE3v2aXS1wCL4zWg==
Received: (qmail 15132 invoked from network); 27 Nov 2014 12:51:40 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	27 Nov 2014 12:51:40 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 7400A803D5
	for <xen-devel@lists.xen.org>; Thu, 27 Nov 2014 12:51:40 +0200 (EET)
Received: (qmail 22055 invoked from network); 27 Nov 2014 12:51:40 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by smtp03.buh.bitdefender.org with SMTP; 27 Nov 2014 12:51:40 +0200
Message-ID: <54770242.9000709@bitdefender.com>
Date: Thu, 27 Nov 2014 12:51:46 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.57977
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 373685,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_NO_LINK_NMD;
	NN_LEGIT_BITDEFENDER; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled], URL:
	[Enabled], RTDA: [Enabled, Hit: No, Details: v2.0.9; Id:
	2m1ghdn.197mem219.6qcnp], total: 0(775)
X-BitDefender-CF-Stamp: none
Subject: [Xen-devel] Xenstore.h clarifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 know that xc_interface_open() can be safely called several times from
the same process, and that several processes can each have a bunch of
xc_interface handles open, and that I shouldn't use an xc_interface
inherited from the parent in a child process, because xenctrl.h says so.

Is it safe to assume that the same restrictions / conventions apply to
xs_handles obtained via xs_open()? Xenstore.h is not explicit. Looking
at the code, it would seem safe to assume that it can be used in a
similar manner, but it would be nice to have this confirmed if possible.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 10:51:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 10:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtwg1-0007I2-Is; Thu, 27 Nov 2014 10:51:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xtwg0-0007Hm-3b
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 10:51:56 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F1/06-03145-B4207745; Thu, 27 Nov 2014 10:51:55 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417085510!14636940!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18658 invoked from network); 27 Nov 2014 10:51:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 10:51:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197396906"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 05:51:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xtwft-0007v2-4i;
	Thu, 27 Nov 2014 10:51:49 +0000
Date: Thu, 27 Nov 2014 10:51:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417084837.12784.5.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1411271049130.14135@kaball.uk.xensource.com>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<1417084837.12784.5.camel@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, tim@xen.org,
	Julien Grall <julien.grall@linaro.org>, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
 Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 27 Nov 2014, Ian Campbell wrote:
> On Tue, 2014-11-25 at 17:44 +0000, Julien Grall wrote:
> > ARMv8 model may not disable correctly the timer interrupt when Xen
> 
> "correct disable"
> 
> > context switch to an idle vCPU. Therefore Xen may receive a spurious
> 
> "context switches" and s/spurious/unexpected/ (since spurious has a
> specific meaning in the h/w which does not match what is happening here)
> 
> > timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
> > when trying to inject the interrupt with the following stack trace.
> > 
> > (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
> > (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
> > (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
> > (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
> > (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
> > (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
> > (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
> > (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
> > (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
> > (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
> > (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
> > (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
> > (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
> > (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
> > (XEN)    [<0000000000000001>] 0000000000000001
> > 
> > While we receive spurious virtual timer interrupt, this could be safely
> > ignore for the time being. A proper fix need to be found for Xen 4.6.
> > 
> > Signed-off-by: Julien Grall <julien.grall@linaro.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Although I wonder if we should log, perhaps rate limited or only once.
> 
> Also, I've some grammar nits (above and below) which I can fix on commit
> if there is no resend...
> 
> > 
> > ---
> > 
> > This patch is a bug fix candidate for Xen 4.5. Any ARMv8 model may
> > randomly crash when running Xen.
> 
> CCing Konrad.
> 
> > This patch don't inject the virtual timer interrupt if the current VCPU
> > is the idle one. Entering in this function with the idle VCPU is already
> > a bug itself. For now, I think this patch is the safest way to resolve
> > the problem.
> > 
> > Meanwhile, I'm investigating with ARM to see wheter the bug comes from
> > Xen or the model.

It is worth noting that there are no bad side effects of this change:
the vtimer_interrupt is always supposed to be received on non-idle
domains. As Julien wrote, the fact that we are receiving a
vtimer_interrupt in the idle_domain is a bug, one that probably comes
from the ARM model not emulating hardware correctly.


> >  xen/arch/arm/time.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> > index a6436f1..83c74cb 100644
> > --- a/xen/arch/arm/time.c
> > +++ b/xen/arch/arm/time.c
> > @@ -169,6 +169,14 @@ static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> >  
> >  static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> >  {
> > +    /*
> > +     * ARMv8 model may not disable correctly the timer interrupt when
> 
> "correctly disable"
> 
> > +     * Xen context switch to an idle vCPU. Therefore Xen may receive
> 
> "context switches" and "may receive an unexpected timer interrupt"
> 
> > +     * timer interrupt.
> > +     */
> > +    if ( is_idle_vcpu(current) )
> > +        return;
> > +
> >      current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
> >      WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
> >      vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq);
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:06:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:06:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwtV-0007pi-7l; Thu, 27 Nov 2014 11:05:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtwtT-0007pb-Lj
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 11:05:51 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	80/28-08051-F8507745; Thu, 27 Nov 2014 11:05:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417086349!15203025!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11328 invoked from network); 27 Nov 2014 11:05:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 11:05:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197400173"
Message-ID: <54770582.80207@citrix.com>
Date: Thu, 27 Nov 2014 11:05:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>	
	<5475DD4F.9060203@suse.com> <5475E311.6070501@citrix.com>
	<1417081768.11944.70.camel@citrix.com>
In-Reply-To: <1417081768.11944.70.camel@citrix.com>
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/11/14 09:49, Ian Campbell wrote:
> On Wed, 2014-11-26 at 14:26 +0000, Andrew Cooper wrote:
>> libxc (or some new alternative) should suck it up and gain some notion
>> of a stable API or ABI (like the rest of the world appears to be able to
>> manage), such that it is possible to compile with an older header and
>> use a newer .so at runtime.
> Retrofitting a stable API/ABI to the melting pot which is libxc simply
> isn't going to work in practice.
>
> IMO the most likely to succeed approach would be to split off the bits
> of libxc which 3rd party's can/should/need to rely on into one of more
> libraries, probably by functional area.
>
> So far I'm aware of plans (or at least desires) to do that for:
>
>       * Interfaces used by device-models/qemu.
>       * The bits which are useful inside a guest (i.e. the
>         various /dev/xen/* related helpers).
>
> So it sounds like libxenkexec should be added to that list.
>
> Ian.
>

Agreed.

For a domU, I think we need libxenevt, libxengnt and libxenstore with
stable API and ABIs.  This in turn will permit libvchan to work without
needing libxenctrl.

For dom0, each of the libraries is going to need basic hypercall
functionality.  It might be worth considering making libxenbasic (name
looking for improvement) which is more along the lines of a privcmd
driver, providing do_hypercall() and bounce buffering.  libxenctrl and
others can then avoid reimplementing the wheel many times.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:06:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:06:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwtV-0007pi-7l; Thu, 27 Nov 2014 11:05:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtwtT-0007pb-Lj
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 11:05:51 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	80/28-08051-F8507745; Thu, 27 Nov 2014 11:05:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417086349!15203025!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11328 invoked from network); 27 Nov 2014 11:05:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 11:05:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197400173"
Message-ID: <54770582.80207@citrix.com>
Date: Thu, 27 Nov 2014 11:05:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>	
	<5475DD4F.9060203@suse.com> <5475E311.6070501@citrix.com>
	<1417081768.11944.70.camel@citrix.com>
In-Reply-To: <1417081768.11944.70.camel@citrix.com>
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/11/14 09:49, Ian Campbell wrote:
> On Wed, 2014-11-26 at 14:26 +0000, Andrew Cooper wrote:
>> libxc (or some new alternative) should suck it up and gain some notion
>> of a stable API or ABI (like the rest of the world appears to be able to
>> manage), such that it is possible to compile with an older header and
>> use a newer .so at runtime.
> Retrofitting a stable API/ABI to the melting pot which is libxc simply
> isn't going to work in practice.
>
> IMO the most likely to succeed approach would be to split off the bits
> of libxc which 3rd party's can/should/need to rely on into one of more
> libraries, probably by functional area.
>
> So far I'm aware of plans (or at least desires) to do that for:
>
>       * Interfaces used by device-models/qemu.
>       * The bits which are useful inside a guest (i.e. the
>         various /dev/xen/* related helpers).
>
> So it sounds like libxenkexec should be added to that list.
>
> Ian.
>

Agreed.

For a domU, I think we need libxenevt, libxengnt and libxenstore with
stable API and ABIs.  This in turn will permit libvchan to work without
needing libxenctrl.

For dom0, each of the libraries is going to need basic hypercall
functionality.  It might be worth considering making libxenbasic (name
looking for improvement) which is more along the lines of a privcmd
driver, providing do_hypercall() and bounce buffering.  libxenctrl and
others can then avoid reimplementing the wheel many times.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:06:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:06:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtwu6-0007tj-Kh; Thu, 27 Nov 2014 11:06:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xtwu5-0007tO-3r
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:06:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6D/94-25276-4B507745; Thu, 27 Nov 2014 11:06:28 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417086386!11465696!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5600 invoked from network); 27 Nov 2014 11:06:27 -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;
	27 Nov 2014 11:06:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197141359"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 06:06:09 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1Xtwtl-0008E8-4G; Thu, 27 Nov 2014 11:06:09 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 27 Nov 2014 11:06:08 +0000
Message-ID: <1417086368-5912-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH for-4.5] docs/commandline: Refresh document for
	4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

* Add options whose code has been committed (without a patch to this file).
* Remove options which have been deleted (without a patch to this file).
* Tweak some formatting for consistency.
* Nuke some trailing whitespace.

I believe this document now identifies the exact set of command line options
accepted by Xen, for both x86 and ARM architectures.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

Konrad: A release ack please.  It would be nice if the command line
documentation was correct for 4.5.
---
 docs/misc/xen-command-line.markdown |   79 ++++++++++++++++++++++++-----------
 1 file changed, 55 insertions(+), 24 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 2b7d29c..0866df2 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -159,6 +159,15 @@ to boot on systems with the following errata:
   triggerable Denial of Service. Override only if you trust all of
   your PV guests.
 
+### apicv
+> `= <boolean>`
+
+> Default: `true`
+
+Permit Xen to use APIC Virtualisation Extensions.  This is an optimisation
+available as part of VT-x, and allows hardware to take care of the guests APIC
+handling, rather than requiring emulation in Xen.
+
 ### apic\_verbosity
 > `= verbose | debug`
 
@@ -173,6 +182,15 @@ Permit Xen to use "Always Running APIC Timer" support on compatible hardware
 in combination with cpuidle.  This option is only expected to be useful for
 developers wishing Xen to fall back to older timing methods on newer hardware.
 
+### asid
+> `= <boolean>`
+
+> Default: `true`
+
+Permit Xen to use Address Space Identifiers.  This is an optimisation which
+tags the TLB entries with an ID per vcpu.  This allows for guest TLB flushes
+to be performed without the overhead of a complete TLB flush.
+
 ### ats
 > `= <boolean>`
 
@@ -209,7 +227,7 @@ Scrub free RAM during boot.  This is a safety feature to prevent
 accidentally leaking sensitive VM data into other VMs if Xen crashes
 and reboots.
 
-### `bootscrub_chunk`
+### bootscrub\_chunk
 > `= <size>`
 
 > Default: `128M`
@@ -219,11 +237,6 @@ and not running softirqs. Reduce this if softirqs are not being run frequently
 enough. Setting this to a high value may cause boot failure, particularly if
 the NMI watchdog is also enabled.
 
-### cachesize
-> `= <size>`
-
-If set, override Xen's calculation of the level 2 cache line size.
-
 ### clocksource
 > `= pit | hpet | acpi`
 
@@ -328,7 +341,7 @@ into the console ring buffer.
 ### conswitch
 > `= <switch char>[x]`
 
-> Default `conswitch=a`
+> Default: `conswitch=a`
 
 Specify which character should be used to switch serial input between
 Xen and dom0.  The required sequence is CTRL-&lt;switch char&gt; three
@@ -340,6 +353,11 @@ including omission, causes Xen to automatically switch to the dom0
 console during dom0 boot.  Use `conswitch=ax` to keep the default switch
 character, but for xen to keep the console.
 
+### core\_parking
+> `= power | performance`
+
+> Default: `power`
+
 ### cpu\_type
 > `= arch_perfmon`
 
@@ -403,7 +421,7 @@ description of the other respective options above.
 ### cpuinfo
 > `= <boolean>`
 
-### crashinfo_maxaddr
+### crashinfo\_maxaddr
 > `= <size>`
 
 > Default: `4G`
@@ -531,6 +549,14 @@ Pin dom0 vcpus to their respective pcpus
 
 Flag that makes a 64bit dom0 boot in PVH mode. No 32bit support at present.
 
+### dtuart (ARM)
+> `= path [,options]`
+
+> Default: `""`
+
+Specify the full path in the device tree for the UART.  If the path doesn't
+start with `/`, it is assumed to be an alias.  The options are device specific.
+
 ### e820-mtrr-clip
 > `= <boolean>`
 
@@ -675,6 +701,13 @@ intended to be used when domain 0 is a stub domain which builds a disaggregated
 system including a hardware domain with the specified domain ID.  This option is
 supported only when compiled with XSM\_ENABLE=y on x86.
 
+### hest\_disable
+> ` = <boolean>`
+
+> Default: `false`
+
+Control Xens use of the APEI Hardware Error Source Table, should one be found.
+
 ### hpetbroadcast
 > `= <boolean>`
 
@@ -881,6 +914,14 @@ which data structures should be deliberately allocated in low memory,
 so the crash kernel may find find them.  Should be used in combination
 with **crashinfo_maxaddr**.
 
+### low\_mem\_virq\_limit
+> `= <size>`
+
+> Default: `64M`
+
+Specify the threshold below which Xen will inform dom0 that the quantity of
+free memory is getting low.  Specifying `0` will disable this notification.
+
 ### max\_cstate
 > `= <integer>`
 
@@ -958,9 +999,6 @@ Because responsibility for APIC setup is shared between Xen and the
 domain 0 kernel this option is automatically propagated to the domain
 0 command line.
 
-### nofxsr
-> `= <boolean>`
-
 ### noirqbalance
 > `= <boolean>`
 
@@ -990,11 +1028,6 @@ Do not automatically reboot after an error.  This is useful for
 catching debug output.  Defaults to automatically reboot after 5
 seconds.
 
-### noserialnumber
-> `= <boolean>`
-
-Disable CPU serial number reporting.
-
 ### nosmp
 > `= <boolean>`
 
@@ -1007,15 +1040,16 @@ Defaults to booting secondary processors.
 ### numa
 > `= on | off | fake=<integer> | noacpi`
 
-Default: `on`
+> Default: `on`
 
 ### pci
 > `= {no-}serr | {no-}perr`
 
+> Default: Signaling left as set by firmware.
+
 Disable signaling of SERR (system errors) and/or PERR (parity errors)
 on all PCI devices.
 
-Default: Signaling left as set by firmware.
 
 ### pci-phantom
 > `=[<seg>:]<bus>:<device>,<stride>`
@@ -1056,7 +1090,7 @@ The following resources are available:
 ### reboot
 > `= t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]`
 
-Default: `0`
+> Default: `0`
 
 Specify the host reboot method.
 
@@ -1187,9 +1221,6 @@ pages) must also be specified via the tbuf\_size parameter.
 ### tmem\_dedup
 > `= <boolean>`
 
-### tmem\_lock
-> `= <integer>`
-
 ### tmem\_shared\_auth
 > `= <boolean>`
 
@@ -1281,8 +1312,8 @@ flushes on VM entry and exit, increasing performance.
 
 Switch on the virtualized performance monitoring unit for HVM guests.
 
-If the current cpu isn't supported a message like  
-'VPMU: Initialization failed. ...'  
+If the current cpu isn't supported a message like
+'VPMU: Initialization failed. ...'
 is printed on the hypervisor serial log.
 
 For some Intel Nehalem processors a quirk handling exist for an unknown
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:06:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:06:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtwu6-0007tj-Kh; Thu, 27 Nov 2014 11:06:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xtwu5-0007tO-3r
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:06:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6D/94-25276-4B507745; Thu, 27 Nov 2014 11:06:28 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417086386!11465696!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5600 invoked from network); 27 Nov 2014 11:06:27 -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;
	27 Nov 2014 11:06:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="197141359"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 06:06:09 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1Xtwtl-0008E8-4G; Thu, 27 Nov 2014 11:06:09 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 27 Nov 2014 11:06:08 +0000
Message-ID: <1417086368-5912-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH for-4.5] docs/commandline: Refresh document for
	4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

* Add options whose code has been committed (without a patch to this file).
* Remove options which have been deleted (without a patch to this file).
* Tweak some formatting for consistency.
* Nuke some trailing whitespace.

I believe this document now identifies the exact set of command line options
accepted by Xen, for both x86 and ARM architectures.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---

Konrad: A release ack please.  It would be nice if the command line
documentation was correct for 4.5.
---
 docs/misc/xen-command-line.markdown |   79 ++++++++++++++++++++++++-----------
 1 file changed, 55 insertions(+), 24 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 2b7d29c..0866df2 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -159,6 +159,15 @@ to boot on systems with the following errata:
   triggerable Denial of Service. Override only if you trust all of
   your PV guests.
 
+### apicv
+> `= <boolean>`
+
+> Default: `true`
+
+Permit Xen to use APIC Virtualisation Extensions.  This is an optimisation
+available as part of VT-x, and allows hardware to take care of the guests APIC
+handling, rather than requiring emulation in Xen.
+
 ### apic\_verbosity
 > `= verbose | debug`
 
@@ -173,6 +182,15 @@ Permit Xen to use "Always Running APIC Timer" support on compatible hardware
 in combination with cpuidle.  This option is only expected to be useful for
 developers wishing Xen to fall back to older timing methods on newer hardware.
 
+### asid
+> `= <boolean>`
+
+> Default: `true`
+
+Permit Xen to use Address Space Identifiers.  This is an optimisation which
+tags the TLB entries with an ID per vcpu.  This allows for guest TLB flushes
+to be performed without the overhead of a complete TLB flush.
+
 ### ats
 > `= <boolean>`
 
@@ -209,7 +227,7 @@ Scrub free RAM during boot.  This is a safety feature to prevent
 accidentally leaking sensitive VM data into other VMs if Xen crashes
 and reboots.
 
-### `bootscrub_chunk`
+### bootscrub\_chunk
 > `= <size>`
 
 > Default: `128M`
@@ -219,11 +237,6 @@ and not running softirqs. Reduce this if softirqs are not being run frequently
 enough. Setting this to a high value may cause boot failure, particularly if
 the NMI watchdog is also enabled.
 
-### cachesize
-> `= <size>`
-
-If set, override Xen's calculation of the level 2 cache line size.
-
 ### clocksource
 > `= pit | hpet | acpi`
 
@@ -328,7 +341,7 @@ into the console ring buffer.
 ### conswitch
 > `= <switch char>[x]`
 
-> Default `conswitch=a`
+> Default: `conswitch=a`
 
 Specify which character should be used to switch serial input between
 Xen and dom0.  The required sequence is CTRL-&lt;switch char&gt; three
@@ -340,6 +353,11 @@ including omission, causes Xen to automatically switch to the dom0
 console during dom0 boot.  Use `conswitch=ax` to keep the default switch
 character, but for xen to keep the console.
 
+### core\_parking
+> `= power | performance`
+
+> Default: `power`
+
 ### cpu\_type
 > `= arch_perfmon`
 
@@ -403,7 +421,7 @@ description of the other respective options above.
 ### cpuinfo
 > `= <boolean>`
 
-### crashinfo_maxaddr
+### crashinfo\_maxaddr
 > `= <size>`
 
 > Default: `4G`
@@ -531,6 +549,14 @@ Pin dom0 vcpus to their respective pcpus
 
 Flag that makes a 64bit dom0 boot in PVH mode. No 32bit support at present.
 
+### dtuart (ARM)
+> `= path [,options]`
+
+> Default: `""`
+
+Specify the full path in the device tree for the UART.  If the path doesn't
+start with `/`, it is assumed to be an alias.  The options are device specific.
+
 ### e820-mtrr-clip
 > `= <boolean>`
 
@@ -675,6 +701,13 @@ intended to be used when domain 0 is a stub domain which builds a disaggregated
 system including a hardware domain with the specified domain ID.  This option is
 supported only when compiled with XSM\_ENABLE=y on x86.
 
+### hest\_disable
+> ` = <boolean>`
+
+> Default: `false`
+
+Control Xens use of the APEI Hardware Error Source Table, should one be found.
+
 ### hpetbroadcast
 > `= <boolean>`
 
@@ -881,6 +914,14 @@ which data structures should be deliberately allocated in low memory,
 so the crash kernel may find find them.  Should be used in combination
 with **crashinfo_maxaddr**.
 
+### low\_mem\_virq\_limit
+> `= <size>`
+
+> Default: `64M`
+
+Specify the threshold below which Xen will inform dom0 that the quantity of
+free memory is getting low.  Specifying `0` will disable this notification.
+
 ### max\_cstate
 > `= <integer>`
 
@@ -958,9 +999,6 @@ Because responsibility for APIC setup is shared between Xen and the
 domain 0 kernel this option is automatically propagated to the domain
 0 command line.
 
-### nofxsr
-> `= <boolean>`
-
 ### noirqbalance
 > `= <boolean>`
 
@@ -990,11 +1028,6 @@ Do not automatically reboot after an error.  This is useful for
 catching debug output.  Defaults to automatically reboot after 5
 seconds.
 
-### noserialnumber
-> `= <boolean>`
-
-Disable CPU serial number reporting.
-
 ### nosmp
 > `= <boolean>`
 
@@ -1007,15 +1040,16 @@ Defaults to booting secondary processors.
 ### numa
 > `= on | off | fake=<integer> | noacpi`
 
-Default: `on`
+> Default: `on`
 
 ### pci
 > `= {no-}serr | {no-}perr`
 
+> Default: Signaling left as set by firmware.
+
 Disable signaling of SERR (system errors) and/or PERR (parity errors)
 on all PCI devices.
 
-Default: Signaling left as set by firmware.
 
 ### pci-phantom
 > `=[<seg>:]<bus>:<device>,<stride>`
@@ -1056,7 +1090,7 @@ The following resources are available:
 ### reboot
 > `= t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]`
 
-Default: `0`
+> Default: `0`
 
 Specify the host reboot method.
 
@@ -1187,9 +1221,6 @@ pages) must also be specified via the tbuf\_size parameter.
 ### tmem\_dedup
 > `= <boolean>`
 
-### tmem\_lock
-> `= <integer>`
-
 ### tmem\_shared\_auth
 > `= <boolean>`
 
@@ -1281,8 +1312,8 @@ flushes on VM entry and exit, increasing performance.
 
 Switch on the virtualized performance monitoring unit for HVM guests.
 
-If the current cpu isn't supported a message like  
-'VPMU: Initialization failed. ...'  
+If the current cpu isn't supported a message like
+'VPMU: Initialization failed. ...'
 is printed on the hypervisor serial log.
 
 For some Intel Nehalem processors a quirk handling exist for an unknown
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:12:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwzW-0008JA-Ec; Thu, 27 Nov 2014 11:12:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XtwzU-0008J4-E6
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:12:04 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	F2/C7-20609-30707745; Thu, 27 Nov 2014 11:12:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417086722!9807374!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24584 invoked from network); 27 Nov 2014 11:12:02 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 27 Nov 2014 11:12:02 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:51098 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xtwx0-0002jk-Cq; Thu, 27 Nov 2014 12:09:30 +0100
Date: Thu, 27 Nov 2014 12:11:48 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1658300290.20141127121148@eikelenboom.it>
To: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
In-Reply-To: <201411271023.sARANOnS012898@wind.enjellic.com>
References: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> "Re:
	[Xen-devel] Q77 IGD instantly crashes on xen-pciback bind."
	(Nov 24, 1:28pm) <201411271023.sARANOnS012898@wind.enjellic.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------04D1D80951745AACE"
Cc: greg@enjellic.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------04D1D80951745AACE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Thursday, November 27, 2014, 11:23:24 AM, you wrote:

> On Nov 24,  1:28pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:

>> Hello,

> Hi, hope the week is going well for everyone.

>> > >> As I was walking out the door I remembered I had been delinquent
>> > >> with information.  The dom0 kernel is 32-bit 3.14.22 straight from
>> > >> kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.
>> > 
>> > > Wow, quite an old thread :)
>> > >  
>> > > So you're still seeing the same problem with recent Xen/Linux
>> > > versions.. 
>> > 
>> > Yes, the perils of platforming for 7 year field deployments... :-)
>> > 
>> > I can certainly build up a toolchain against the HEAD of XEN git and
>> > the most recent release of the kernel if everyone feels that would be
>> > beneficial.
>> > 
>> > > This might be a stupid question, but here goes anyway: Do you have
>> > > serial console set up? And all the debug/verbose options specified
>> > > for Xen and Linux?
>> > 
>> > The platform in question doesn't have any serial ports, at least not
>> > surfaced.  We will need to do a bit of wiring if we need to go in that
>> > direction.

>> You mentioned it's Intel Q77 chipset based motherboard..  which
>> means it should have Intel AMT functionality, which provides SOL
>> (Serial-over-LAN), which you can use as a serial console for Xen.
>>
>> There are tools (at least amtterm) that you can use on another box
>> to connect to the AMT SOL remotely..

> So we wired up serial console connectivity to the test box and
> repeated the VGA device binding with loglvl=all.  We lost the box
> immediately without anything being written to the logs.

> So we went hunting.

> Interestingly the problem appears to be secondary to a BIOS
> configuration option.  This may be specific to this platform but we
> wanted to get it documented in the thread in case anyone else runs
> into this.

> The DQ77KB BIOS we are using has an option for 'IGD flat panel
> display'.  The default option is LVDS, setting this to 'disabled'
> clears the problem.

> I haven't run down where things go wrong in pci_stub but I assume it
> does something to the hardware which causes a problem when the video
> controller is reset and then shutdown.

>> > Now that I have the machine in a harness in the lab I will stick a
>> > '#define DEBUG 1' in the top of drivers/xen/xen-pciback/pci_stub.c
>> > since that is where the action seems to be going on.
>> > 
>> > The platform is headed for a measured computing environment so I
>> > thought there may be some type of conflict with tboot holding a
>> > reference to the VGA driver but I verified the issue in a straight
>> > hypervisor boot.
>> > 
>> > I see that Tiejun Chen from Intel is sorting out issues with respect
>> > to the need to export the ISA bridge into the device emulator in order
>> > to support passthrough on these IGD devices.  I bound the 00:1f.0 ISA
>> > bridge device to pciback and that worked but it did not change the
>> > behavior of the regression.  When the 00:02.0 device is bound to
>> > pciback the display is cleared and the machine dies in its tracks.

>> Yeah, Tiejun is working on upstreaming the IGD passthru patches to
>> Qemu-upstream.
>>
>> Qemu-dm-traditional already has (most of) the IGD passthru patches. 
>> 
>> Hope that helps,

> So we are obviously working with qemu-dm-traditional and with the
> IGD/LVDS BIOS configuration issue fixed the adapater passthrough is
> working and Windows7 is coming up and detecting the IGD as a standard
> VGA display adapter.  Additional invocations of the VM after the first
> one result in failed passthrough with a garbled display.

This is probably due to the current lack of slot/bus reset in xen-pciback,
Konrad has a preliminary kernel patch for xen-pciback that does this.
I have attached the patch, though it has some rough edges in the design :-)
 
I'm currently running with his 3.19 xen-pciback patches series + the preliminary
patch for slot/bus reset and rebooting a guest with vga/pci passthrough now
works. (i'm running with a radeon card, passed through as a secondary card
to the emulated qemu one, in a linux guest using qemu-xen, so i can't help
you with your other questions and problems).

--
Sander

> I spent an afternoon wandering through the mailing lists and found
> what I think are the two patches which are needed to map the 00:1f.0
> ISA bridge device into the guest.  From the discussions surrounding
> those patches it appears as if the Windows HD driver needs addresses
> managed by that bridge to recognize the IGD device.

> I will get those patches wired into qemu-dm-traditional and tested in
> between whisky, wine, turkey and napping today.... :-)

> I'm hoping that this positively impacts the ability to execute
> multiple sessions.  I will report back the results so we have all of
> this in the mailing list record.

>> -- Pasi

> Thanks for offering the pointers, have a good day.

> Greg

> }-- End of excerpt from Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=

> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: greg@enjellic.com
> ------------------------------------------------------------------------------
> "Immortality is an adequate definition of high availability for me."
>                                 -- Gregory F. Pfister



------------04D1D80951745AACE
Content-Type: application/octet-stream;
 name="0001-xen-pciback-Implement-PCI-reset-slot-or-bus-with-do_.patch"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="0001-xen-pciback-Implement-PCI-reset-slot-or-bus-with-do_.patch"

RnJvbSBmYTI2MjM2MmQ5MjRkYTlmNjNiMDczOWM0NzBiZDFhNjdjMzZiZmFlIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53
aWxrQG9yYWNsZS5jb20+CkRhdGU6IFR1ZSwgOCBKdWwgMjAxNCAxMToyMjo0NSAtMDQwMApT
dWJqZWN0OiBbUEFUQ0hdIHhlbi9wY2liYWNrOiBJbXBsZW1lbnQgUENJIHJlc2V0IHNsb3Qg
b3IgYnVzIHdpdGggJ2RvX2ZscicKIFN5c0ZTIGF0dHJpYnV0ZQoKVGhlIGxpZmUtY3ljbGUg
b2YgYSBQQ0kgZGV2aWNlIGluIFhlbiBwY2liYWNrIGlzIGNvbXBsZXgKYW5kIGlzIGNvbnN0
cmFpbmVkIGJ5IHRoZSBQQ0kgZ2VuZXJpYyBsb2NraW5nIG1lY2hhbmlzbS4KCkl0IHN0YXJ0
cyB3aXRoIHRoZSBkZXZpY2UgYmVpbmcgYmluZGVkIHRvIHVzIC0gZm9yIHdoaWNoCndlIGRv
IGEgZGV2aWNlIGZ1bmN0aW9uIHJlc2V0IChhbmQgZG9uZSB2aWEgU3lzRlMKc28gdGhlIFBD
SSBsb2NrIGlzIGhlbGQpCgpJZiB0aGUgZGV2aWNlIGlzIHVuYmluZGVkIGZyb20gdXMgLSB3
ZSBhbHNvIGRvIGEgZnVuY3Rpb24KcmVzZXQgKGFsc28gZG9uZSB2aWEgU3lzRlMgc28gdGhl
IFBDSSBsb2NrIGlzIGhlbGQpLgoKSWYgdGhlIGRldmljZSBpcyB1bi1hc3NpZ25lZCBmcm9t
IGEgZ3Vlc3QgLSB3ZSBkbyBhIGZ1bmN0aW9uCnJlc2V0IChubyBQQ0kgbG9jaykuCgpBbGwg
b24gdGhlIGluZGl2aWR1YWwgUENJIGZ1bmN0aW9uIGxldmVsIChzbyBidXM6ZGV2aWNlOmZ1
bmN0aW9uKS4KClVuZm9ydHVuYXRseSBhIGZ1bmN0aW9uIHJlc2V0IGlzIG5vdCBhZGVxdWF0
ZSBmb3IgY2VydGFpbgpQQ0llIGRldmljZXMuIFRoZSByZXNldCBmb3IgYW4gaW5kaXZpZHVh
bCBQQ0kgZnVuY3Rpb24gIm1lYW5zCmRldmljZSBtdXN0IHN1cHBvcnQgRkxSIChQQ0llIG9y
IEFGKSwgUE0gcmVzZXQgb24gRDNob3QtPkQwCmRldmljZSBzcGVjaWZpYyByZXNldCwgb3Ig
YmUgYSBzaW5nbGV0b24gZGV2aWNlIG9uIGEgYnVzCmEgc2Vjb25kYXJ5IGJ1cyByZXNldC4g
IEZMUiBkb2VzIG5vdCBoYXZlIHdpZGVzcHJlYWQgc3VwcG9ydCwKcmVzZXQgaXMgbm90IHZl
cnkgcmVsaWFibGUsIGFuZCBidXMgdG9wb2xvZ3kgaXMgZGljdGF0ZWQgYnkgdGhlCmFuZCBk
ZXZpY2UgZGVzaWduLiAgV2UgbmVlZCB0byBwcm92aWRlIGEgbWVhbnMgZm9yIGEgdXNlciB0
bwphIGJ1cyByZXNldCBpbiBjYXNlcyB3aGVyZSB0aGUgZXhpc3RpbmcgbWVjaGFuaXNtcyBh
cmUgbm90CiBvciBub3QgcmVsaWFibGUuICIgKEFkYW0gV2lsbGlhbXNvbiwgJ3ZmaW8tcGNp
OiBQQ0kgaG90IHJlc2V0CmludGVyZmFjZScgY29tbWl0IDhiMjdlZTYwYmZkNmJiYjg0ZDJk
ZjI4ZmE3MDZjNWM1MDgxMDY2Y2EpLgoKQXMgc3VjaCB0byBkbyBhIHNsb3Qgb3IgYSBidXMg
cmVzZXQgaXMgd2UgbmVlZCBhbm90aGVyIG1lY2hhbmlzbS4KVGhpcyBpcyBub3QgZXhwb3Nl
ZCBTeXNGUyBhcyB0aGVyZSBpcyBubyBnb29kIHdheSBvZiBleHBvc2luZwphIGJ1cyB0b3Bv
bG9neSB0aGVyZS4KClRoaXMgaXMgZHVlIHRvIHRoZSBjb21wbGV4aXR5IC0gd2UgTVVTVCBr
bm93IHRoYXQgdGhlIGRpZmZlcmVudApmdW5jdGlvbnMgb2ZmIGEgUENJZSBkZXZpY2UgYXJl
IG5vdCBpbiB1c2UgYnkgb3RoZXIgZHJpdmVycywgb3IKaWYgdGhleSBhcmUgaW4gdXNlIChz
YXkgb25lIG9mIHRoZW0gaXMgYXNzaWduZWQgdG8gYSBndWVzdAphbmQgdGhlIG90aGVyIGlz
IGlkbGUpIC0gaXQgaXMgc3RpbGwgT0sgdG8gcmVzZXQgdGhlIHNsb3QKKGFzc3VtaW5nIGJv
dGggb2YgdGhlbSBhcmUgb3duZWQgYnkgWGVuIHBjaWJhY2spLgoKVGhpcyBwYXRjaCBkb2Vz
IHRoYXQgYnkgZG9pbmcgYW4gc2xvdCBvciBidXMgcmVzZXQgKGlmCnNsb3Qgbm90IHN1cHBv
cnRlZCkgaWYgYWxsIG9mIHRoZSBmdW5jdGlvbnMgb2YgYSBQQ0llCmRldmljZSBiZWxvbmcg
dG8gWGVuIFBDSWJhY2suIFdlIGRvIG5vdCBjYXJlIGlmIHRoZSBkZXZpY2UgaXMKaW4tdXNl
IGFzIHdlIGRlcGVuZCBvbiB0aGUgdG9vbHN0YWNrIHRvIGJlIGF3YXJlIG9mIHRoaXMgLQpo
b3dldmVyIGlmIGl0IGlzIHdlIHdpbGwgV0FSTiB0aGUgdXNlci4KCkR1ZSB0byB0aGUgY29t
cGxleGl0eSB3aXRoIHRoZSBQQ0kgbG9jayB3ZSBjYW5ub3QgZG8KdGhlIHJlc2V0IHdoZW4g
YSBkZXZpY2UgaXMgYmluZGVkICgnZWNobyAkQkRGID4gYmluZCcpCm9yIHdoZW4gdW5iaW5k
ZWQgKCdlY2hvICRCREYgPiB1bmJpbmQnKSBhcyB0aGUgcGNpX1tzbG90fGJ1c11fcmVzZXQK
YWxzbyB0YWtlIHRoZSBzYW1lIGxvY2sgcmVzdWx0aW5nIGluIGEgZGVhZC1sb2NrLgoKUHV0
dGluZyB0aGUgcmVzZXQgZnVuY3Rpb24gaW4gYSB3b3JrcXVldWUgb3IgdGhyZWFkCndvbid0
IHdvcmsgZWl0aGVyIC0gYXMgd2UgaGF2ZSB0byBkbyB0aGUgcmVzZXQgZnVuY3Rpb24Kb3V0
c2lkZSB0aGUgJ3VuYmluZCcgY29udGV4dCAoaXQgaG9sZHMgdGhlIFBDSSBsb2NrKS4KQnV0
IG9uY2UgeW91ICd1bmJpbmQnIGEgZGV2aWNlIHRoZSBkZXZpY2UgaXMgbm8gbG9uZ2VyCnVu
ZGVyIHRoZSBvd25lcnNoaXAgb2YgWGVuIHBjaWJhY2sgYW5kIHRoZSBwY2lfc2V0X2RydmRh
dGEKaGFzIGJlZW4gcmVzZXQgc28gd2UgY2Fubm90IHVzZSBhIHRocmVhZCBmb3IgdGhpcy4K
Ckluc3RlYWQgb2YgZG9pbmcgYWxsIHRoaXMgY29tcGxleCBkYW5jZSwgd2UgZGVwZW5kIG9u
IHRoZSB0b29sc3RhY2sKZG9pbmcgdGhlIHJpZ2h0IHRoaW5nLiBBcyBzdWNoIGltcGxlbWVu
dCB0aGUgJ2RvX2ZscicgU3lzRlMgYXR0cmlidXRlCndoaWNoICd4bCcgdXNlcyB3aGVuIGEg
ZGV2aWNlIGlzIGRldGFjaGVkIG9yIGF0dGFjaGVkIGZyb20vdG8gYSBndWVzdC4KSXQgYnlw
YXNzZXMgdGhlIG5lZWQgdG8gd29ycnkgYWJvdXQgdGhlIFBDSSBsb2NrLgoKVG8gbm90IGlu
YWR2ZXJ0bHkgZG8gYSBidXMgcmVzZXQgdGhhdCB3b3VsZCBhZmZlY3QgZGV2aWNlcyB0aGF0
CmFyZSBpbiB1c2UgYnkgb3RoZXIgZHJpdmVycyAob3RoZXIgdGhhbiBYZW4gcGNpYmFjaykg
cHJpb3IKdG8gdGhlIHJlc2V0IHdlIGNoZWNrIHRoYXQgYWxsIG9mIHRoZSBkZXZpY2VzIHVu
ZGVyIHRoZSBicmlkZ2UKYXJlIG93bmVkIGJ5IFhlbiBwY2liYWNrLiBJZiB0aGV5IGFyZSBu
b3Qgd2UgZG8gbm90IGRvCnRoZSBidXMgKG9yIHNsb3QpIHJlc2V0LgoKV2UgYWxzbyB3YXJu
IHRoZSB1c2VyIGlmIHRoZSBkZXZpY2UgaXMgaW4gdXNlIC0gYnV0IHN0aWxsCmNvbnRpbnVl
IHdpdGggdGhlIHJlc2V0LiBUaGlzIHNob3VsZCBub3QgaGFwcGVuIGFzIHRoZSB0b29sc3Rh
Y2sKYWxzbyBkb2VzIHRoZSBjaGVjay4KClNpZ25lZC1vZmYtYnk6IEtvbnJhZCBSemVzenV0
ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KLS0tCiBEb2N1bWVudGF0aW9uL0FC
SS90ZXN0aW5nL3N5c2ZzLWRyaXZlci1wY2liYWNrIHwgIDEyICsrKwogZHJpdmVycy94ZW4v
eGVuLXBjaWJhY2svcGNpX3N0dWIuYyAgICAgICAgICAgICB8IDEzOSArKysrKysrKysrKysr
KysrKysrKy0tLS0tCiAyIGZpbGVzIGNoYW5nZWQsIDEyNCBpbnNlcnRpb25zKCspLCAyNyBk
ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL0FCSS90ZXN0aW5nL3N5
c2ZzLWRyaXZlci1wY2liYWNrIGIvRG9jdW1lbnRhdGlvbi9BQkkvdGVzdGluZy9zeXNmcy1k
cml2ZXItcGNpYmFjawppbmRleCA2YTczM2JmLi44OWRjZjcxIDEwMDY0NAotLS0gYS9Eb2N1
bWVudGF0aW9uL0FCSS90ZXN0aW5nL3N5c2ZzLWRyaXZlci1wY2liYWNrCisrKyBiL0RvY3Vt
ZW50YXRpb24vQUJJL3Rlc3Rpbmcvc3lzZnMtZHJpdmVyLXBjaWJhY2sKQEAgLTExLDMgKzEx
LDE1IEBAIERlc2NyaXB0aW9uOgogICAgICAgICAgICAgICAgICNlY2hvIDAwOjE5LjAtRTA6
MjpGRiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaWJhY2svcXVpcmtzCiAgICAgICAgICAg
ICAgICAgd2lsbCBhbGxvdyB0aGUgZ3Vlc3QgdG8gcmVhZCBhbmQgd3JpdGUgdG8gdGhlIGNv
bmZpZ3VyYXRpb24KICAgICAgICAgICAgICAgICByZWdpc3RlciAweDBFLgorCisKK1doYXQ6
ICAgICAgICAgICAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2liYWNrL2RvX2ZscgorRGF0ZTog
ICAgICAgICAgCURlY2VtYmVyIDIwMTQKK0tlcm5lbFZlcnNpb246ICAzLjE5CitDb250YWN0
OiAgICAgICAgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCitEZXNjcmlwdGlvbjoK
KyAgICAgICAgICAgICAgICBBbiBvcHRpb24gdG8gc2xvdCBvciBidXMgcmVzZXQgYW4gUENJ
IGRldmljZSBvd25lZCBieQorICAgICAgICAgICAgICAgIFhlbiBQQ0kgYmFja2VuZC4gV3Jp
dGluZyBhIHN0cmluZyBvZiBEREREOkJCOkRELkYgd2lsbCBjYXVzZQorICAgICAgICAgICAg
ICAgIHRoZSBkcml2ZXIgdG8gcGVyZm9ybSBhbiBzbG90IG9yIGJ1cyByZXNldCBpZiB0aGUg
ZGV2aWNlCisgICAgICAgICAgICAgICAgc3VwcG9ydHMuIEl0IGFsc28gY2hlY2tzIHRvIG1h
a2Ugc3VyZSB0aGF0IGFsbCBvZiB0aGUgZGV2aWNlcworICAgICAgICAgICAgICAgIHVuZGVy
IHRoZSBicmlkZ2UgYXJlIG93bmVkIGJ5IFhlbiBQQ0kgYmFja2VuZC4KZGlmZiAtLWdpdCBh
L2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaV9zdHViLmMgYi9kcml2ZXJzL3hlbi94ZW4t
cGNpYmFjay9wY2lfc3R1Yi5jCmluZGV4IGZmMjdlZmEuLjAzMmYxN2E4IDEwMDY0NAotLS0g
YS9kcml2ZXJzL3hlbi94ZW4tcGNpYmFjay9wY2lfc3R1Yi5jCisrKyBiL2RyaXZlcnMveGVu
L3hlbi1wY2liYWNrL3BjaV9zdHViLmMKQEAgLTEwMCwxNCArMTAwLDkgQEAgc3RhdGljIHZv
aWQgcGNpc3R1Yl9kZXZpY2VfcmVsZWFzZShzdHJ1Y3Qga3JlZiAqa3JlZikKIAogCXhlbl91
bnJlZ2lzdGVyX2RldmljZV9kb21haW5fb3duZXIoZGV2KTsKIAotCS8qIENhbGwgdGhlIHJl
c2V0IGZ1bmN0aW9uIHdoaWNoIGRvZXMgbm90IHRha2UgbG9jayBhcyB0aGlzCi0JICogaXMg
Y2FsbGVkIGZyb20gInVuYmluZCIgd2hpY2ggdGFrZXMgYSBkZXZpY2VfbG9jayBtdXRleC4K
LQkgKi8KLQlfX3BjaV9yZXNldF9mdW5jdGlvbl9sb2NrZWQoZGV2KTsKKwkvKiBSZXNldCBp
cyBkb25lIGJ5IHRoZSB0b29sc3RhY2sgYnkgdXNpbmcgJ2RvX2Zscicgb24gdGhlIFN5c0ZT
LiAqLwogCWlmIChwY2lfbG9hZF9hbmRfZnJlZV9zYXZlZF9zdGF0ZShkZXYsICZkZXZfZGF0
YS0+cGNpX3NhdmVkX3N0YXRlKSkKIAkJZGV2X2luZm8oJmRldi0+ZGV2LCAiQ291bGQgbm90
IHJlbG9hZCBQQ0kgc3RhdGVcbiIpOwotCWVsc2UKLQkJcGNpX3Jlc3RvcmVfc3RhdGUoZGV2
KTsKIAogCWlmIChkZXYtPm1zaXhfY2FwKSB7CiAJCXN0cnVjdCBwaHlzZGV2X3BjaV9kZXZp
Y2UgcHBkZXYgPSB7CkBAIC0xMjMsOSArMTE4LDYgQEAgc3RhdGljIHZvaWQgcGNpc3R1Yl9k
ZXZpY2VfcmVsZWFzZShzdHJ1Y3Qga3JlZiAqa3JlZikKIAkJCQkgZXJyKTsKIAl9CiAKLQkv
KiBEaXNhYmxlIHRoZSBkZXZpY2UgKi8KLQl4ZW5fcGNpYmtfcmVzZXRfZGV2aWNlKGRldik7
Ci0KIAlrZnJlZShkZXZfZGF0YSk7CiAJcGNpX3NldF9kcnZkYXRhKGRldiwgTlVMTCk7CiAK
QEAgLTI0Miw2ICsyMzQsODYgQEAgc3RydWN0IHBjaV9kZXYgKnBjaXN0dWJfZ2V0X3BjaV9k
ZXYoc3RydWN0IHhlbl9wY2lia19kZXZpY2UgKnBkZXYsCiAJcmV0dXJuIGZvdW5kX2RldjsK
IH0KIAorc3RydWN0IHdyYXBwZXJfYXJncyB7CisJc3RydWN0IHBjaV9kZXYgKmRldjsKKwlp
bnQgaW5fdXNlOworfTsKKworc3RhdGljIGludCBwY2lzdHViX3BjaV93YWxrX3dyYXBwZXIo
c3RydWN0IHBjaV9kZXYgKmRldiwgdm9pZCAqZGF0YSkKK3sKKwlzdHJ1Y3QgcGNpc3R1Yl9k
ZXZpY2UgKnBzZGV2LCAqZm91bmRfcHNkZXYgPSBOVUxMOworCXN0cnVjdCB3cmFwcGVyX2Fy
Z3MgKmFyZyA9IGRhdGE7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKworCXNwaW5fbG9ja19p
cnFzYXZlKCZwY2lzdHViX2RldmljZXNfbG9jaywgZmxhZ3MpOworCWxpc3RfZm9yX2VhY2hf
ZW50cnkocHNkZXYsICZwY2lzdHViX2RldmljZXMsIGRldl9saXN0KSB7CisJCWlmIChwc2Rl
di0+ZGV2ID09IGRldikgeworCQkJZm91bmRfcHNkZXYgPSBwc2RldjsKKwkJCWlmIChwc2Rl
di0+cGRldikKKwkJCQlhcmctPmluX3VzZSsrOworCQkJYnJlYWs7CisJCX0KKwl9CisJc3Bp
bl91bmxvY2tfaXJxcmVzdG9yZSgmcGNpc3R1Yl9kZXZpY2VzX2xvY2ssIGZsYWdzKTsKKwlk
ZXZfZGJnKCZkZXYtPmRldiwgIiVzXG4iLCBmb3VuZF9wc2RldiA/ICJPSyIgOiAibm90IG93
bmVkIGJ5IHVzISIpOworCisJaWYgKCFmb3VuZF9wc2RldikKKwkJYXJnLT5kZXYgPSBkZXY7
CisJcmV0dXJuIGZvdW5kX3BzZGV2ID8gMCA6IDE7Cit9CisKK3N0YXRpYyBpbnQgcGNpc3R1
Yl9yZXNldF9wY2lfZGV2KHN0cnVjdCBwY2lfZGV2ICpkZXYpCit7CisJc3RydWN0IHdyYXBw
ZXJfYXJncyBhcmcgPSB7IC5kZXYgPSBOVUxMLCAuaW5fdXNlID0gMCB9OworCWJvb2wgc2xv
dCA9IGZhbHNlLCBidXMgPSBmYWxzZTsKKwlpbnQgcmM7CisKKwlpZiAoIWRldikKKwkJcmV0
dXJuIC1FSU5WQUw7CisKKwlpZiAoIXBjaV9wcm9iZV9yZXNldF9zbG90KGRldi0+c2xvdCkp
CisJCXNsb3QgPSB0cnVlOworCWVsc2UgaWYgKCFwY2lfcHJvYmVfcmVzZXRfYnVzKGRldi0+
YnVzKSkgeworCQkvKiBXZSB3b24ndCBhdHRlbXB0IHRvIHJlc2V0IGEgcm9vdCBicmlkZ2Uu
ICovCisJCWlmICghcGNpX2lzX3Jvb3RfYnVzKGRldi0+YnVzKSkKKwkJCWJ1cyA9IHRydWU7
CisJfQorCWRldl9kYmcoJmRldi0+ZGV2LCAicmVzZXR0aW5nIChGTFIsIEQzLCAlcyAlcykg
dGhlIGRldmljZVxuIiwKKwkJc2xvdCA/ICJzbG90IiA6ICIiLCBidXMgPyAiYnVzIiA6ICIi
KTsKKworCXBjaV93YWxrX2J1cyhkZXYtPmJ1cywgcGNpc3R1Yl9wY2lfd2Fsa193cmFwcGVy
LCAmYXJnKTsKKworCWlmIChhcmcuaW5fdXNlKQorCQlkZXZfZXJyKCZkZXYtPmRldiwgImlz
IGluIHVzZSFcbiIpOworCisJLyoKKwkgKiBUYWtlcyB0aGUgUENJIGxvY2suIE9LIHRvIGRv
IGl0IGFzIHdlIGFyZSBuZXZlciBjYWxsZWQKKwkgKiBmcm9tICd1bmJpbmQnIHN0YXRlIGFu
ZCBkb24ndCBkZWFkbG9jay4KKwkgKi8KKwlpZiAoIXBjaV9sb2FkX3NhdmVkX3N0YXRlKGRl
diwgZGV2X2RhdGEtPnBjaV9zYXZlZF9zdGF0ZSkpCisJCXBjaV9yZXN0b3JlX3N0YXRlKGRl
dik7CisKKwlwY2lfcmVzZXRfZnVuY3Rpb24oZGV2KTsKKworCS8qIFRoaXMgZGlzYWJsZXMg
dGhlIGRldmljZS4gKi8KKwl4ZW5fcGNpYmtfcmVzZXRfZGV2aWNlKGRldik7CisKKwkvKiBB
bmQgY2xlYW51cCB1cCBvdXIgZW11bGF0ZWQgZmllbGRzLiAqLworCXhlbl9wY2lia19jb25m
aWdfcmVzZXRfZGV2KGRldik7CisKKwlpZiAoIWJ1cyAmJiAhc2xvdCkKKwkJcmV0dXJuIDA7
CisKKwkvKiBBbGwgc2xvdHMgb3IgZGV2aWNlcyB1bmRlciB0aGUgYnVzIHNob3VsZCBiZSBw
YXJ0IG9mIHBjaXN0dWIhICovCisJaWYgKGFyZy5kZXYpIHsKKwkJZGV2X2VycigmZGV2LT5k
ZXYsICJkZXBlbmRzIG9uOiAlcyFcbiIsIHBjaV9uYW1lKGFyZy5kZXYpKTsKKwkJcmV0dXJu
IC1FQlVTWTsKKwl9CisJcmMgPSBzbG90ID8gcGNpX3RyeV9yZXNldF9zbG90KGRldi0+c2xv
dCk6IHBjaV90cnlfcmVzZXRfYnVzKGRldi0+YnVzKTsKKworCXJldHVybiByYzsKK30KKwog
LyoKICAqIENhbGxlZCB3aGVuOgogICogIC0gWGVuQnVzIHN0YXRlIGhhcyBiZWVuIHJlY29u
ZmlndXJlIChwY2kgdW5wbHVnKS4gU2VlIHhlbl9wY2lia19yZW1vdmVfZGV2aWNlCkBAIC0y
NzcsMjUgKzM0OSwxMCBAQCB2b2lkIHBjaXN0dWJfcHV0X3BjaV9kZXYoc3RydWN0IHBjaV9k
ZXYgKmRldikKIAkqIHBjaXN0dWIgYW5kIHhlbl9wY2liayB3aGVuIEFFUiBpcyBpbiBwcm9j
ZXNzaW5nCiAJKi8KIAlkb3duX3dyaXRlKCZwY2lzdHViX3NlbSk7Ci0JLyogQ2xlYW51cCBv
dXIgZGV2aWNlCi0JICogKHNvIGl0J3MgcmVhZHkgZm9yIHRoZSBuZXh0IGRvbWFpbikKKwkv
KiBDbGVhbnVwIG91ciBkZXZpY2UgKHNvIGl0J3MgcmVhZHkgZm9yIHRoZSBuZXh0IGRvbWFp
bikKKwkgKiBUaGF0IGlzIHRoZSBqb2Igb2YgdGhlIHRvb2xzdGFjayB3aGljaCBoYXMgdG8g
Y2FsbCAnZG9fZmxyJyBiZWZvcmUKKwkgKiBwcm92aWRpbmcgdGhlIFBDSSBkZXZpY2UgdG8g
YSBndWVzdCAoc2VlIHBjaXN0dWJfZG9fZmxyKS4KIAkgKi8KLQlkZXZpY2VfbG9ja19hc3Nl
cnQoJmRldi0+ZGV2KTsKLQlkZXZfZGF0YSA9IHBjaV9nZXRfZHJ2ZGF0YShkZXYpOwotCXJl
dCA9IHBjaV9sb2FkX3NhdmVkX3N0YXRlKGRldiwgZGV2X2RhdGEtPnBjaV9zYXZlZF9zdGF0
ZSk7Ci0JaWYgKHJldCA8IDApCi0JCWRldl93YXJuKCZkZXYtPmRldiwgIkNvdWxkIG5vdCBy
ZWxvYWQgUENJIHN0YXRlXG4iKTsKLQllbHNlIHsKLQkJX19wY2lfcmVzZXRfZnVuY3Rpb25f
bG9ja2VkKGRldik7Ci0JCS8qCi0JCSAqIFRoZSB1c3VhbCBzZXF1ZW5jZSBpcyBwY2lfc2F2
ZV9zdGF0ZSAmIHBjaV9yZXN0b3JlX3N0YXRlCi0JCSAqIGJ1dCB0aGUgZ3Vlc3QgbWlnaHQg
aGF2ZSBtZXNzZWQgdGhlIGNvbmZpZ3VyYXRpb24gc3BhY2UgdXAuCi0JCSAqIFVzZSB0aGUg
aW5pdGlhbCB2ZXJzaW9uICh3aGVuIGRldmljZSB3YXMgYm91bmQgdG8gdXMpLgotCQkgKi8K
LQkJcGNpX3Jlc3RvcmVfc3RhdGUoZGV2KTsKLQl9Ci0JLyogVGhpcyBkaXNhYmxlcyB0aGUg
ZGV2aWNlLiAqLwotCXhlbl9wY2lia19yZXNldF9kZXZpY2UoZGV2KTsKIAogCS8qIEFuZCBj
bGVhbnVwIHVwIG91ciBlbXVsYXRlZCBmaWVsZHMuICovCiAJeGVuX3BjaWJrX2NvbmZpZ19y
ZXNldF9kZXYoZGV2KTsKQEAgLTEzODksNiArMTQ0NiwyOSBAQCBzdGF0aWMgc3NpemVfdCBw
ZXJtaXNzaXZlX3Nob3coc3RydWN0IGRldmljZV9kcml2ZXIgKmRydiwgY2hhciAqYnVmKQog
c3RhdGljIERSSVZFUl9BVFRSKHBlcm1pc3NpdmUsIFNfSVJVU1IgfCBTX0lXVVNSLCBwZXJt
aXNzaXZlX3Nob3csCiAJCSAgIHBlcm1pc3NpdmVfYWRkKTsKIAorc3RhdGljIHNzaXplX3Qg
cGNpc3R1Yl9kb19mbHIoc3RydWN0IGRldmljZV9kcml2ZXIgKmRydiwgY29uc3QgY2hhciAq
YnVmLAorCQkJCXNpemVfdCBjb3VudCkKK3sKKwlpbnQgZG9tYWluLCBidXMsIHNsb3QsIGZ1
bmM7CisJaW50IGVycjsKKwlzdHJ1Y3QgcGNpc3R1Yl9kZXZpY2UgKnBzZGV2OworCisJZXJy
ID0gc3RyX3RvX3Nsb3QoYnVmLCAmZG9tYWluLCAmYnVzLCAmc2xvdCwgJmZ1bmMpOworCWlm
IChlcnIpCisJCWdvdG8gb3V0OworCisJcHNkZXYgPSBwY2lzdHViX2RldmljZV9maW5kKGRv
bWFpbiwgYnVzLCBzbG90LCBmdW5jKTsKKwlpZiAocHNkZXYpIHsKKwkJZXJyID0gcGNpc3R1
Yl9yZXNldF9wY2lfZGV2KHBzZGV2LT5kZXYpOworCQlwY2lzdHViX2RldmljZV9wdXQocHNk
ZXYpOworCX0gZWxzZQorCQllcnIgPSAtRU5PREVWOworb3V0OgorCWlmICghZXJyKQorCQll
cnIgPSBjb3VudDsKKwlyZXR1cm4gZXJyOworfQorc3RhdGljIERSSVZFUl9BVFRSKGRvX2Zs
ciwgU19JV1VTUiwgTlVMTCwgcGNpc3R1Yl9kb19mbHIpOwogc3RhdGljIHZvaWQgcGNpc3R1
Yl9leGl0KHZvaWQpCiB7CiAJZHJpdmVyX3JlbW92ZV9maWxlKCZ4ZW5fcGNpYmtfcGNpX2Ry
aXZlci5kcml2ZXIsICZkcml2ZXJfYXR0cl9uZXdfc2xvdCk7CkBAIC0xNDAyLDYgKzE0ODIs
OCBAQCBzdGF0aWMgdm9pZCBwY2lzdHViX2V4aXQodm9pZCkKIAkJCSAgICZkcml2ZXJfYXR0
cl9pcnFfaGFuZGxlcnMpOwogCWRyaXZlcl9yZW1vdmVfZmlsZSgmeGVuX3BjaWJrX3BjaV9k
cml2ZXIuZHJpdmVyLAogCQkJICAgJmRyaXZlcl9hdHRyX2lycV9oYW5kbGVyX3N0YXRlKTsK
Kwlkcml2ZXJfcmVtb3ZlX2ZpbGUoJnhlbl9wY2lia19wY2lfZHJpdmVyLmRyaXZlciwKKwkJ
CSAgICZkcml2ZXJfYXR0cl9kb19mbHIpOwogCXBjaV91bnJlZ2lzdGVyX2RyaXZlcigmeGVu
X3BjaWJrX3BjaV9kcml2ZXIpOwogfQogCkBAIC0xNDk1LDYgKzE1NzcsOSBAQCBzdGF0aWMg
aW50IF9faW5pdCBwY2lzdHViX2luaXQodm9pZCkKIAlpZiAoIWVycikKIAkJZXJyID0gZHJp
dmVyX2NyZWF0ZV9maWxlKCZ4ZW5fcGNpYmtfcGNpX2RyaXZlci5kcml2ZXIsCiAJCQkJCSZk
cml2ZXJfYXR0cl9pcnFfaGFuZGxlcl9zdGF0ZSk7CisJaWYgKCFlcnIpCisJCWVyciA9IGRy
aXZlcl9jcmVhdGVfZmlsZSgmeGVuX3BjaWJrX3BjaV9kcml2ZXIuZHJpdmVyLAorCQkJCQkm
ZHJpdmVyX2F0dHJfZG9fZmxyKTsKIAlpZiAoZXJyKQogCQlwY2lzdHViX2V4aXQoKTsKIAot
LSAKMS45LjMKCg==
------------04D1D80951745AACE
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------04D1D80951745AACE--



From xen-devel-bounces@lists.xen.org Thu Nov 27 11:12:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtwzW-0008JA-Ec; Thu, 27 Nov 2014 11:12:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XtwzU-0008J4-E6
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:12:04 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	F2/C7-20609-30707745; Thu, 27 Nov 2014 11:12:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417086722!9807374!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24584 invoked from network); 27 Nov 2014 11:12:02 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 27 Nov 2014 11:12:02 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:51098 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Xtwx0-0002jk-Cq; Thu, 27 Nov 2014 12:09:30 +0100
Date: Thu, 27 Nov 2014 12:11:48 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1658300290.20141127121148@eikelenboom.it>
To: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
In-Reply-To: <201411271023.sARANOnS012898@wind.enjellic.com>
References: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> "Re:
	[Xen-devel] Q77 IGD instantly crashes on xen-pciback bind."
	(Nov 24, 1:28pm) <201411271023.sARANOnS012898@wind.enjellic.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------04D1D80951745AACE"
Cc: greg@enjellic.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------04D1D80951745AACE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Thursday, November 27, 2014, 11:23:24 AM, you wrote:

> On Nov 24,  1:28pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:

>> Hello,

> Hi, hope the week is going well for everyone.

>> > >> As I was walking out the door I remembered I had been delinquent
>> > >> with information.  The dom0 kernel is 32-bit 3.14.22 straight from
>> > >> kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources.
>> > 
>> > > Wow, quite an old thread :)
>> > >  
>> > > So you're still seeing the same problem with recent Xen/Linux
>> > > versions.. 
>> > 
>> > Yes, the perils of platforming for 7 year field deployments... :-)
>> > 
>> > I can certainly build up a toolchain against the HEAD of XEN git and
>> > the most recent release of the kernel if everyone feels that would be
>> > beneficial.
>> > 
>> > > This might be a stupid question, but here goes anyway: Do you have
>> > > serial console set up? And all the debug/verbose options specified
>> > > for Xen and Linux?
>> > 
>> > The platform in question doesn't have any serial ports, at least not
>> > surfaced.  We will need to do a bit of wiring if we need to go in that
>> > direction.

>> You mentioned it's Intel Q77 chipset based motherboard..  which
>> means it should have Intel AMT functionality, which provides SOL
>> (Serial-over-LAN), which you can use as a serial console for Xen.
>>
>> There are tools (at least amtterm) that you can use on another box
>> to connect to the AMT SOL remotely..

> So we wired up serial console connectivity to the test box and
> repeated the VGA device binding with loglvl=all.  We lost the box
> immediately without anything being written to the logs.

> So we went hunting.

> Interestingly the problem appears to be secondary to a BIOS
> configuration option.  This may be specific to this platform but we
> wanted to get it documented in the thread in case anyone else runs
> into this.

> The DQ77KB BIOS we are using has an option for 'IGD flat panel
> display'.  The default option is LVDS, setting this to 'disabled'
> clears the problem.

> I haven't run down where things go wrong in pci_stub but I assume it
> does something to the hardware which causes a problem when the video
> controller is reset and then shutdown.

>> > Now that I have the machine in a harness in the lab I will stick a
>> > '#define DEBUG 1' in the top of drivers/xen/xen-pciback/pci_stub.c
>> > since that is where the action seems to be going on.
>> > 
>> > The platform is headed for a measured computing environment so I
>> > thought there may be some type of conflict with tboot holding a
>> > reference to the VGA driver but I verified the issue in a straight
>> > hypervisor boot.
>> > 
>> > I see that Tiejun Chen from Intel is sorting out issues with respect
>> > to the need to export the ISA bridge into the device emulator in order
>> > to support passthrough on these IGD devices.  I bound the 00:1f.0 ISA
>> > bridge device to pciback and that worked but it did not change the
>> > behavior of the regression.  When the 00:02.0 device is bound to
>> > pciback the display is cleared and the machine dies in its tracks.

>> Yeah, Tiejun is working on upstreaming the IGD passthru patches to
>> Qemu-upstream.
>>
>> Qemu-dm-traditional already has (most of) the IGD passthru patches. 
>> 
>> Hope that helps,

> So we are obviously working with qemu-dm-traditional and with the
> IGD/LVDS BIOS configuration issue fixed the adapater passthrough is
> working and Windows7 is coming up and detecting the IGD as a standard
> VGA display adapter.  Additional invocations of the VM after the first
> one result in failed passthrough with a garbled display.

This is probably due to the current lack of slot/bus reset in xen-pciback,
Konrad has a preliminary kernel patch for xen-pciback that does this.
I have attached the patch, though it has some rough edges in the design :-)
 
I'm currently running with his 3.19 xen-pciback patches series + the preliminary
patch for slot/bus reset and rebooting a guest with vga/pci passthrough now
works. (i'm running with a radeon card, passed through as a secondary card
to the emulated qemu one, in a linux guest using qemu-xen, so i can't help
you with your other questions and problems).

--
Sander

> I spent an afternoon wandering through the mailing lists and found
> what I think are the two patches which are needed to map the 00:1f.0
> ISA bridge device into the guest.  From the discussions surrounding
> those patches it appears as if the Windows HD driver needs addresses
> managed by that bridge to recognize the IGD device.

> I will get those patches wired into qemu-dm-traditional and tested in
> between whisky, wine, turkey and napping today.... :-)

> I'm hoping that this positively impacts the ability to execute
> multiple sessions.  I will report back the results so we have all of
> this in the mailing list record.

>> -- Pasi

> Thanks for offering the pointers, have a good day.

> Greg

> }-- End of excerpt from Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=

> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: greg@enjellic.com
> ------------------------------------------------------------------------------
> "Immortality is an adequate definition of high availability for me."
>                                 -- Gregory F. Pfister



------------04D1D80951745AACE
Content-Type: application/octet-stream;
 name="0001-xen-pciback-Implement-PCI-reset-slot-or-bus-with-do_.patch"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="0001-xen-pciback-Implement-PCI-reset-slot-or-bus-with-do_.patch"

RnJvbSBmYTI2MjM2MmQ5MjRkYTlmNjNiMDczOWM0NzBiZDFhNjdjMzZiZmFlIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53
aWxrQG9yYWNsZS5jb20+CkRhdGU6IFR1ZSwgOCBKdWwgMjAxNCAxMToyMjo0NSAtMDQwMApT
dWJqZWN0OiBbUEFUQ0hdIHhlbi9wY2liYWNrOiBJbXBsZW1lbnQgUENJIHJlc2V0IHNsb3Qg
b3IgYnVzIHdpdGggJ2RvX2ZscicKIFN5c0ZTIGF0dHJpYnV0ZQoKVGhlIGxpZmUtY3ljbGUg
b2YgYSBQQ0kgZGV2aWNlIGluIFhlbiBwY2liYWNrIGlzIGNvbXBsZXgKYW5kIGlzIGNvbnN0
cmFpbmVkIGJ5IHRoZSBQQ0kgZ2VuZXJpYyBsb2NraW5nIG1lY2hhbmlzbS4KCkl0IHN0YXJ0
cyB3aXRoIHRoZSBkZXZpY2UgYmVpbmcgYmluZGVkIHRvIHVzIC0gZm9yIHdoaWNoCndlIGRv
IGEgZGV2aWNlIGZ1bmN0aW9uIHJlc2V0IChhbmQgZG9uZSB2aWEgU3lzRlMKc28gdGhlIFBD
SSBsb2NrIGlzIGhlbGQpCgpJZiB0aGUgZGV2aWNlIGlzIHVuYmluZGVkIGZyb20gdXMgLSB3
ZSBhbHNvIGRvIGEgZnVuY3Rpb24KcmVzZXQgKGFsc28gZG9uZSB2aWEgU3lzRlMgc28gdGhl
IFBDSSBsb2NrIGlzIGhlbGQpLgoKSWYgdGhlIGRldmljZSBpcyB1bi1hc3NpZ25lZCBmcm9t
IGEgZ3Vlc3QgLSB3ZSBkbyBhIGZ1bmN0aW9uCnJlc2V0IChubyBQQ0kgbG9jaykuCgpBbGwg
b24gdGhlIGluZGl2aWR1YWwgUENJIGZ1bmN0aW9uIGxldmVsIChzbyBidXM6ZGV2aWNlOmZ1
bmN0aW9uKS4KClVuZm9ydHVuYXRseSBhIGZ1bmN0aW9uIHJlc2V0IGlzIG5vdCBhZGVxdWF0
ZSBmb3IgY2VydGFpbgpQQ0llIGRldmljZXMuIFRoZSByZXNldCBmb3IgYW4gaW5kaXZpZHVh
bCBQQ0kgZnVuY3Rpb24gIm1lYW5zCmRldmljZSBtdXN0IHN1cHBvcnQgRkxSIChQQ0llIG9y
IEFGKSwgUE0gcmVzZXQgb24gRDNob3QtPkQwCmRldmljZSBzcGVjaWZpYyByZXNldCwgb3Ig
YmUgYSBzaW5nbGV0b24gZGV2aWNlIG9uIGEgYnVzCmEgc2Vjb25kYXJ5IGJ1cyByZXNldC4g
IEZMUiBkb2VzIG5vdCBoYXZlIHdpZGVzcHJlYWQgc3VwcG9ydCwKcmVzZXQgaXMgbm90IHZl
cnkgcmVsaWFibGUsIGFuZCBidXMgdG9wb2xvZ3kgaXMgZGljdGF0ZWQgYnkgdGhlCmFuZCBk
ZXZpY2UgZGVzaWduLiAgV2UgbmVlZCB0byBwcm92aWRlIGEgbWVhbnMgZm9yIGEgdXNlciB0
bwphIGJ1cyByZXNldCBpbiBjYXNlcyB3aGVyZSB0aGUgZXhpc3RpbmcgbWVjaGFuaXNtcyBh
cmUgbm90CiBvciBub3QgcmVsaWFibGUuICIgKEFkYW0gV2lsbGlhbXNvbiwgJ3ZmaW8tcGNp
OiBQQ0kgaG90IHJlc2V0CmludGVyZmFjZScgY29tbWl0IDhiMjdlZTYwYmZkNmJiYjg0ZDJk
ZjI4ZmE3MDZjNWM1MDgxMDY2Y2EpLgoKQXMgc3VjaCB0byBkbyBhIHNsb3Qgb3IgYSBidXMg
cmVzZXQgaXMgd2UgbmVlZCBhbm90aGVyIG1lY2hhbmlzbS4KVGhpcyBpcyBub3QgZXhwb3Nl
ZCBTeXNGUyBhcyB0aGVyZSBpcyBubyBnb29kIHdheSBvZiBleHBvc2luZwphIGJ1cyB0b3Bv
bG9neSB0aGVyZS4KClRoaXMgaXMgZHVlIHRvIHRoZSBjb21wbGV4aXR5IC0gd2UgTVVTVCBr
bm93IHRoYXQgdGhlIGRpZmZlcmVudApmdW5jdGlvbnMgb2ZmIGEgUENJZSBkZXZpY2UgYXJl
IG5vdCBpbiB1c2UgYnkgb3RoZXIgZHJpdmVycywgb3IKaWYgdGhleSBhcmUgaW4gdXNlIChz
YXkgb25lIG9mIHRoZW0gaXMgYXNzaWduZWQgdG8gYSBndWVzdAphbmQgdGhlIG90aGVyIGlz
IGlkbGUpIC0gaXQgaXMgc3RpbGwgT0sgdG8gcmVzZXQgdGhlIHNsb3QKKGFzc3VtaW5nIGJv
dGggb2YgdGhlbSBhcmUgb3duZWQgYnkgWGVuIHBjaWJhY2spLgoKVGhpcyBwYXRjaCBkb2Vz
IHRoYXQgYnkgZG9pbmcgYW4gc2xvdCBvciBidXMgcmVzZXQgKGlmCnNsb3Qgbm90IHN1cHBv
cnRlZCkgaWYgYWxsIG9mIHRoZSBmdW5jdGlvbnMgb2YgYSBQQ0llCmRldmljZSBiZWxvbmcg
dG8gWGVuIFBDSWJhY2suIFdlIGRvIG5vdCBjYXJlIGlmIHRoZSBkZXZpY2UgaXMKaW4tdXNl
IGFzIHdlIGRlcGVuZCBvbiB0aGUgdG9vbHN0YWNrIHRvIGJlIGF3YXJlIG9mIHRoaXMgLQpo
b3dldmVyIGlmIGl0IGlzIHdlIHdpbGwgV0FSTiB0aGUgdXNlci4KCkR1ZSB0byB0aGUgY29t
cGxleGl0eSB3aXRoIHRoZSBQQ0kgbG9jayB3ZSBjYW5ub3QgZG8KdGhlIHJlc2V0IHdoZW4g
YSBkZXZpY2UgaXMgYmluZGVkICgnZWNobyAkQkRGID4gYmluZCcpCm9yIHdoZW4gdW5iaW5k
ZWQgKCdlY2hvICRCREYgPiB1bmJpbmQnKSBhcyB0aGUgcGNpX1tzbG90fGJ1c11fcmVzZXQK
YWxzbyB0YWtlIHRoZSBzYW1lIGxvY2sgcmVzdWx0aW5nIGluIGEgZGVhZC1sb2NrLgoKUHV0
dGluZyB0aGUgcmVzZXQgZnVuY3Rpb24gaW4gYSB3b3JrcXVldWUgb3IgdGhyZWFkCndvbid0
IHdvcmsgZWl0aGVyIC0gYXMgd2UgaGF2ZSB0byBkbyB0aGUgcmVzZXQgZnVuY3Rpb24Kb3V0
c2lkZSB0aGUgJ3VuYmluZCcgY29udGV4dCAoaXQgaG9sZHMgdGhlIFBDSSBsb2NrKS4KQnV0
IG9uY2UgeW91ICd1bmJpbmQnIGEgZGV2aWNlIHRoZSBkZXZpY2UgaXMgbm8gbG9uZ2VyCnVu
ZGVyIHRoZSBvd25lcnNoaXAgb2YgWGVuIHBjaWJhY2sgYW5kIHRoZSBwY2lfc2V0X2RydmRh
dGEKaGFzIGJlZW4gcmVzZXQgc28gd2UgY2Fubm90IHVzZSBhIHRocmVhZCBmb3IgdGhpcy4K
Ckluc3RlYWQgb2YgZG9pbmcgYWxsIHRoaXMgY29tcGxleCBkYW5jZSwgd2UgZGVwZW5kIG9u
IHRoZSB0b29sc3RhY2sKZG9pbmcgdGhlIHJpZ2h0IHRoaW5nLiBBcyBzdWNoIGltcGxlbWVu
dCB0aGUgJ2RvX2ZscicgU3lzRlMgYXR0cmlidXRlCndoaWNoICd4bCcgdXNlcyB3aGVuIGEg
ZGV2aWNlIGlzIGRldGFjaGVkIG9yIGF0dGFjaGVkIGZyb20vdG8gYSBndWVzdC4KSXQgYnlw
YXNzZXMgdGhlIG5lZWQgdG8gd29ycnkgYWJvdXQgdGhlIFBDSSBsb2NrLgoKVG8gbm90IGlu
YWR2ZXJ0bHkgZG8gYSBidXMgcmVzZXQgdGhhdCB3b3VsZCBhZmZlY3QgZGV2aWNlcyB0aGF0
CmFyZSBpbiB1c2UgYnkgb3RoZXIgZHJpdmVycyAob3RoZXIgdGhhbiBYZW4gcGNpYmFjaykg
cHJpb3IKdG8gdGhlIHJlc2V0IHdlIGNoZWNrIHRoYXQgYWxsIG9mIHRoZSBkZXZpY2VzIHVu
ZGVyIHRoZSBicmlkZ2UKYXJlIG93bmVkIGJ5IFhlbiBwY2liYWNrLiBJZiB0aGV5IGFyZSBu
b3Qgd2UgZG8gbm90IGRvCnRoZSBidXMgKG9yIHNsb3QpIHJlc2V0LgoKV2UgYWxzbyB3YXJu
IHRoZSB1c2VyIGlmIHRoZSBkZXZpY2UgaXMgaW4gdXNlIC0gYnV0IHN0aWxsCmNvbnRpbnVl
IHdpdGggdGhlIHJlc2V0LiBUaGlzIHNob3VsZCBub3QgaGFwcGVuIGFzIHRoZSB0b29sc3Rh
Y2sKYWxzbyBkb2VzIHRoZSBjaGVjay4KClNpZ25lZC1vZmYtYnk6IEtvbnJhZCBSemVzenV0
ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KLS0tCiBEb2N1bWVudGF0aW9uL0FC
SS90ZXN0aW5nL3N5c2ZzLWRyaXZlci1wY2liYWNrIHwgIDEyICsrKwogZHJpdmVycy94ZW4v
eGVuLXBjaWJhY2svcGNpX3N0dWIuYyAgICAgICAgICAgICB8IDEzOSArKysrKysrKysrKysr
KysrKysrKy0tLS0tCiAyIGZpbGVzIGNoYW5nZWQsIDEyNCBpbnNlcnRpb25zKCspLCAyNyBk
ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL0FCSS90ZXN0aW5nL3N5
c2ZzLWRyaXZlci1wY2liYWNrIGIvRG9jdW1lbnRhdGlvbi9BQkkvdGVzdGluZy9zeXNmcy1k
cml2ZXItcGNpYmFjawppbmRleCA2YTczM2JmLi44OWRjZjcxIDEwMDY0NAotLS0gYS9Eb2N1
bWVudGF0aW9uL0FCSS90ZXN0aW5nL3N5c2ZzLWRyaXZlci1wY2liYWNrCisrKyBiL0RvY3Vt
ZW50YXRpb24vQUJJL3Rlc3Rpbmcvc3lzZnMtZHJpdmVyLXBjaWJhY2sKQEAgLTExLDMgKzEx
LDE1IEBAIERlc2NyaXB0aW9uOgogICAgICAgICAgICAgICAgICNlY2hvIDAwOjE5LjAtRTA6
MjpGRiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaWJhY2svcXVpcmtzCiAgICAgICAgICAg
ICAgICAgd2lsbCBhbGxvdyB0aGUgZ3Vlc3QgdG8gcmVhZCBhbmQgd3JpdGUgdG8gdGhlIGNv
bmZpZ3VyYXRpb24KICAgICAgICAgICAgICAgICByZWdpc3RlciAweDBFLgorCisKK1doYXQ6
ICAgICAgICAgICAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2liYWNrL2RvX2ZscgorRGF0ZTog
ICAgICAgICAgCURlY2VtYmVyIDIwMTQKK0tlcm5lbFZlcnNpb246ICAzLjE5CitDb250YWN0
OiAgICAgICAgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCitEZXNjcmlwdGlvbjoK
KyAgICAgICAgICAgICAgICBBbiBvcHRpb24gdG8gc2xvdCBvciBidXMgcmVzZXQgYW4gUENJ
IGRldmljZSBvd25lZCBieQorICAgICAgICAgICAgICAgIFhlbiBQQ0kgYmFja2VuZC4gV3Jp
dGluZyBhIHN0cmluZyBvZiBEREREOkJCOkRELkYgd2lsbCBjYXVzZQorICAgICAgICAgICAg
ICAgIHRoZSBkcml2ZXIgdG8gcGVyZm9ybSBhbiBzbG90IG9yIGJ1cyByZXNldCBpZiB0aGUg
ZGV2aWNlCisgICAgICAgICAgICAgICAgc3VwcG9ydHMuIEl0IGFsc28gY2hlY2tzIHRvIG1h
a2Ugc3VyZSB0aGF0IGFsbCBvZiB0aGUgZGV2aWNlcworICAgICAgICAgICAgICAgIHVuZGVy
IHRoZSBicmlkZ2UgYXJlIG93bmVkIGJ5IFhlbiBQQ0kgYmFja2VuZC4KZGlmZiAtLWdpdCBh
L2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaV9zdHViLmMgYi9kcml2ZXJzL3hlbi94ZW4t
cGNpYmFjay9wY2lfc3R1Yi5jCmluZGV4IGZmMjdlZmEuLjAzMmYxN2E4IDEwMDY0NAotLS0g
YS9kcml2ZXJzL3hlbi94ZW4tcGNpYmFjay9wY2lfc3R1Yi5jCisrKyBiL2RyaXZlcnMveGVu
L3hlbi1wY2liYWNrL3BjaV9zdHViLmMKQEAgLTEwMCwxNCArMTAwLDkgQEAgc3RhdGljIHZv
aWQgcGNpc3R1Yl9kZXZpY2VfcmVsZWFzZShzdHJ1Y3Qga3JlZiAqa3JlZikKIAogCXhlbl91
bnJlZ2lzdGVyX2RldmljZV9kb21haW5fb3duZXIoZGV2KTsKIAotCS8qIENhbGwgdGhlIHJl
c2V0IGZ1bmN0aW9uIHdoaWNoIGRvZXMgbm90IHRha2UgbG9jayBhcyB0aGlzCi0JICogaXMg
Y2FsbGVkIGZyb20gInVuYmluZCIgd2hpY2ggdGFrZXMgYSBkZXZpY2VfbG9jayBtdXRleC4K
LQkgKi8KLQlfX3BjaV9yZXNldF9mdW5jdGlvbl9sb2NrZWQoZGV2KTsKKwkvKiBSZXNldCBp
cyBkb25lIGJ5IHRoZSB0b29sc3RhY2sgYnkgdXNpbmcgJ2RvX2Zscicgb24gdGhlIFN5c0ZT
LiAqLwogCWlmIChwY2lfbG9hZF9hbmRfZnJlZV9zYXZlZF9zdGF0ZShkZXYsICZkZXZfZGF0
YS0+cGNpX3NhdmVkX3N0YXRlKSkKIAkJZGV2X2luZm8oJmRldi0+ZGV2LCAiQ291bGQgbm90
IHJlbG9hZCBQQ0kgc3RhdGVcbiIpOwotCWVsc2UKLQkJcGNpX3Jlc3RvcmVfc3RhdGUoZGV2
KTsKIAogCWlmIChkZXYtPm1zaXhfY2FwKSB7CiAJCXN0cnVjdCBwaHlzZGV2X3BjaV9kZXZp
Y2UgcHBkZXYgPSB7CkBAIC0xMjMsOSArMTE4LDYgQEAgc3RhdGljIHZvaWQgcGNpc3R1Yl9k
ZXZpY2VfcmVsZWFzZShzdHJ1Y3Qga3JlZiAqa3JlZikKIAkJCQkgZXJyKTsKIAl9CiAKLQkv
KiBEaXNhYmxlIHRoZSBkZXZpY2UgKi8KLQl4ZW5fcGNpYmtfcmVzZXRfZGV2aWNlKGRldik7
Ci0KIAlrZnJlZShkZXZfZGF0YSk7CiAJcGNpX3NldF9kcnZkYXRhKGRldiwgTlVMTCk7CiAK
QEAgLTI0Miw2ICsyMzQsODYgQEAgc3RydWN0IHBjaV9kZXYgKnBjaXN0dWJfZ2V0X3BjaV9k
ZXYoc3RydWN0IHhlbl9wY2lia19kZXZpY2UgKnBkZXYsCiAJcmV0dXJuIGZvdW5kX2RldjsK
IH0KIAorc3RydWN0IHdyYXBwZXJfYXJncyB7CisJc3RydWN0IHBjaV9kZXYgKmRldjsKKwlp
bnQgaW5fdXNlOworfTsKKworc3RhdGljIGludCBwY2lzdHViX3BjaV93YWxrX3dyYXBwZXIo
c3RydWN0IHBjaV9kZXYgKmRldiwgdm9pZCAqZGF0YSkKK3sKKwlzdHJ1Y3QgcGNpc3R1Yl9k
ZXZpY2UgKnBzZGV2LCAqZm91bmRfcHNkZXYgPSBOVUxMOworCXN0cnVjdCB3cmFwcGVyX2Fy
Z3MgKmFyZyA9IGRhdGE7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKworCXNwaW5fbG9ja19p
cnFzYXZlKCZwY2lzdHViX2RldmljZXNfbG9jaywgZmxhZ3MpOworCWxpc3RfZm9yX2VhY2hf
ZW50cnkocHNkZXYsICZwY2lzdHViX2RldmljZXMsIGRldl9saXN0KSB7CisJCWlmIChwc2Rl
di0+ZGV2ID09IGRldikgeworCQkJZm91bmRfcHNkZXYgPSBwc2RldjsKKwkJCWlmIChwc2Rl
di0+cGRldikKKwkJCQlhcmctPmluX3VzZSsrOworCQkJYnJlYWs7CisJCX0KKwl9CisJc3Bp
bl91bmxvY2tfaXJxcmVzdG9yZSgmcGNpc3R1Yl9kZXZpY2VzX2xvY2ssIGZsYWdzKTsKKwlk
ZXZfZGJnKCZkZXYtPmRldiwgIiVzXG4iLCBmb3VuZF9wc2RldiA/ICJPSyIgOiAibm90IG93
bmVkIGJ5IHVzISIpOworCisJaWYgKCFmb3VuZF9wc2RldikKKwkJYXJnLT5kZXYgPSBkZXY7
CisJcmV0dXJuIGZvdW5kX3BzZGV2ID8gMCA6IDE7Cit9CisKK3N0YXRpYyBpbnQgcGNpc3R1
Yl9yZXNldF9wY2lfZGV2KHN0cnVjdCBwY2lfZGV2ICpkZXYpCit7CisJc3RydWN0IHdyYXBw
ZXJfYXJncyBhcmcgPSB7IC5kZXYgPSBOVUxMLCAuaW5fdXNlID0gMCB9OworCWJvb2wgc2xv
dCA9IGZhbHNlLCBidXMgPSBmYWxzZTsKKwlpbnQgcmM7CisKKwlpZiAoIWRldikKKwkJcmV0
dXJuIC1FSU5WQUw7CisKKwlpZiAoIXBjaV9wcm9iZV9yZXNldF9zbG90KGRldi0+c2xvdCkp
CisJCXNsb3QgPSB0cnVlOworCWVsc2UgaWYgKCFwY2lfcHJvYmVfcmVzZXRfYnVzKGRldi0+
YnVzKSkgeworCQkvKiBXZSB3b24ndCBhdHRlbXB0IHRvIHJlc2V0IGEgcm9vdCBicmlkZ2Uu
ICovCisJCWlmICghcGNpX2lzX3Jvb3RfYnVzKGRldi0+YnVzKSkKKwkJCWJ1cyA9IHRydWU7
CisJfQorCWRldl9kYmcoJmRldi0+ZGV2LCAicmVzZXR0aW5nIChGTFIsIEQzLCAlcyAlcykg
dGhlIGRldmljZVxuIiwKKwkJc2xvdCA/ICJzbG90IiA6ICIiLCBidXMgPyAiYnVzIiA6ICIi
KTsKKworCXBjaV93YWxrX2J1cyhkZXYtPmJ1cywgcGNpc3R1Yl9wY2lfd2Fsa193cmFwcGVy
LCAmYXJnKTsKKworCWlmIChhcmcuaW5fdXNlKQorCQlkZXZfZXJyKCZkZXYtPmRldiwgImlz
IGluIHVzZSFcbiIpOworCisJLyoKKwkgKiBUYWtlcyB0aGUgUENJIGxvY2suIE9LIHRvIGRv
IGl0IGFzIHdlIGFyZSBuZXZlciBjYWxsZWQKKwkgKiBmcm9tICd1bmJpbmQnIHN0YXRlIGFu
ZCBkb24ndCBkZWFkbG9jay4KKwkgKi8KKwlpZiAoIXBjaV9sb2FkX3NhdmVkX3N0YXRlKGRl
diwgZGV2X2RhdGEtPnBjaV9zYXZlZF9zdGF0ZSkpCisJCXBjaV9yZXN0b3JlX3N0YXRlKGRl
dik7CisKKwlwY2lfcmVzZXRfZnVuY3Rpb24oZGV2KTsKKworCS8qIFRoaXMgZGlzYWJsZXMg
dGhlIGRldmljZS4gKi8KKwl4ZW5fcGNpYmtfcmVzZXRfZGV2aWNlKGRldik7CisKKwkvKiBB
bmQgY2xlYW51cCB1cCBvdXIgZW11bGF0ZWQgZmllbGRzLiAqLworCXhlbl9wY2lia19jb25m
aWdfcmVzZXRfZGV2KGRldik7CisKKwlpZiAoIWJ1cyAmJiAhc2xvdCkKKwkJcmV0dXJuIDA7
CisKKwkvKiBBbGwgc2xvdHMgb3IgZGV2aWNlcyB1bmRlciB0aGUgYnVzIHNob3VsZCBiZSBw
YXJ0IG9mIHBjaXN0dWIhICovCisJaWYgKGFyZy5kZXYpIHsKKwkJZGV2X2VycigmZGV2LT5k
ZXYsICJkZXBlbmRzIG9uOiAlcyFcbiIsIHBjaV9uYW1lKGFyZy5kZXYpKTsKKwkJcmV0dXJu
IC1FQlVTWTsKKwl9CisJcmMgPSBzbG90ID8gcGNpX3RyeV9yZXNldF9zbG90KGRldi0+c2xv
dCk6IHBjaV90cnlfcmVzZXRfYnVzKGRldi0+YnVzKTsKKworCXJldHVybiByYzsKK30KKwog
LyoKICAqIENhbGxlZCB3aGVuOgogICogIC0gWGVuQnVzIHN0YXRlIGhhcyBiZWVuIHJlY29u
ZmlndXJlIChwY2kgdW5wbHVnKS4gU2VlIHhlbl9wY2lia19yZW1vdmVfZGV2aWNlCkBAIC0y
NzcsMjUgKzM0OSwxMCBAQCB2b2lkIHBjaXN0dWJfcHV0X3BjaV9kZXYoc3RydWN0IHBjaV9k
ZXYgKmRldikKIAkqIHBjaXN0dWIgYW5kIHhlbl9wY2liayB3aGVuIEFFUiBpcyBpbiBwcm9j
ZXNzaW5nCiAJKi8KIAlkb3duX3dyaXRlKCZwY2lzdHViX3NlbSk7Ci0JLyogQ2xlYW51cCBv
dXIgZGV2aWNlCi0JICogKHNvIGl0J3MgcmVhZHkgZm9yIHRoZSBuZXh0IGRvbWFpbikKKwkv
KiBDbGVhbnVwIG91ciBkZXZpY2UgKHNvIGl0J3MgcmVhZHkgZm9yIHRoZSBuZXh0IGRvbWFp
bikKKwkgKiBUaGF0IGlzIHRoZSBqb2Igb2YgdGhlIHRvb2xzdGFjayB3aGljaCBoYXMgdG8g
Y2FsbCAnZG9fZmxyJyBiZWZvcmUKKwkgKiBwcm92aWRpbmcgdGhlIFBDSSBkZXZpY2UgdG8g
YSBndWVzdCAoc2VlIHBjaXN0dWJfZG9fZmxyKS4KIAkgKi8KLQlkZXZpY2VfbG9ja19hc3Nl
cnQoJmRldi0+ZGV2KTsKLQlkZXZfZGF0YSA9IHBjaV9nZXRfZHJ2ZGF0YShkZXYpOwotCXJl
dCA9IHBjaV9sb2FkX3NhdmVkX3N0YXRlKGRldiwgZGV2X2RhdGEtPnBjaV9zYXZlZF9zdGF0
ZSk7Ci0JaWYgKHJldCA8IDApCi0JCWRldl93YXJuKCZkZXYtPmRldiwgIkNvdWxkIG5vdCBy
ZWxvYWQgUENJIHN0YXRlXG4iKTsKLQllbHNlIHsKLQkJX19wY2lfcmVzZXRfZnVuY3Rpb25f
bG9ja2VkKGRldik7Ci0JCS8qCi0JCSAqIFRoZSB1c3VhbCBzZXF1ZW5jZSBpcyBwY2lfc2F2
ZV9zdGF0ZSAmIHBjaV9yZXN0b3JlX3N0YXRlCi0JCSAqIGJ1dCB0aGUgZ3Vlc3QgbWlnaHQg
aGF2ZSBtZXNzZWQgdGhlIGNvbmZpZ3VyYXRpb24gc3BhY2UgdXAuCi0JCSAqIFVzZSB0aGUg
aW5pdGlhbCB2ZXJzaW9uICh3aGVuIGRldmljZSB3YXMgYm91bmQgdG8gdXMpLgotCQkgKi8K
LQkJcGNpX3Jlc3RvcmVfc3RhdGUoZGV2KTsKLQl9Ci0JLyogVGhpcyBkaXNhYmxlcyB0aGUg
ZGV2aWNlLiAqLwotCXhlbl9wY2lia19yZXNldF9kZXZpY2UoZGV2KTsKIAogCS8qIEFuZCBj
bGVhbnVwIHVwIG91ciBlbXVsYXRlZCBmaWVsZHMuICovCiAJeGVuX3BjaWJrX2NvbmZpZ19y
ZXNldF9kZXYoZGV2KTsKQEAgLTEzODksNiArMTQ0NiwyOSBAQCBzdGF0aWMgc3NpemVfdCBw
ZXJtaXNzaXZlX3Nob3coc3RydWN0IGRldmljZV9kcml2ZXIgKmRydiwgY2hhciAqYnVmKQog
c3RhdGljIERSSVZFUl9BVFRSKHBlcm1pc3NpdmUsIFNfSVJVU1IgfCBTX0lXVVNSLCBwZXJt
aXNzaXZlX3Nob3csCiAJCSAgIHBlcm1pc3NpdmVfYWRkKTsKIAorc3RhdGljIHNzaXplX3Qg
cGNpc3R1Yl9kb19mbHIoc3RydWN0IGRldmljZV9kcml2ZXIgKmRydiwgY29uc3QgY2hhciAq
YnVmLAorCQkJCXNpemVfdCBjb3VudCkKK3sKKwlpbnQgZG9tYWluLCBidXMsIHNsb3QsIGZ1
bmM7CisJaW50IGVycjsKKwlzdHJ1Y3QgcGNpc3R1Yl9kZXZpY2UgKnBzZGV2OworCisJZXJy
ID0gc3RyX3RvX3Nsb3QoYnVmLCAmZG9tYWluLCAmYnVzLCAmc2xvdCwgJmZ1bmMpOworCWlm
IChlcnIpCisJCWdvdG8gb3V0OworCisJcHNkZXYgPSBwY2lzdHViX2RldmljZV9maW5kKGRv
bWFpbiwgYnVzLCBzbG90LCBmdW5jKTsKKwlpZiAocHNkZXYpIHsKKwkJZXJyID0gcGNpc3R1
Yl9yZXNldF9wY2lfZGV2KHBzZGV2LT5kZXYpOworCQlwY2lzdHViX2RldmljZV9wdXQocHNk
ZXYpOworCX0gZWxzZQorCQllcnIgPSAtRU5PREVWOworb3V0OgorCWlmICghZXJyKQorCQll
cnIgPSBjb3VudDsKKwlyZXR1cm4gZXJyOworfQorc3RhdGljIERSSVZFUl9BVFRSKGRvX2Zs
ciwgU19JV1VTUiwgTlVMTCwgcGNpc3R1Yl9kb19mbHIpOwogc3RhdGljIHZvaWQgcGNpc3R1
Yl9leGl0KHZvaWQpCiB7CiAJZHJpdmVyX3JlbW92ZV9maWxlKCZ4ZW5fcGNpYmtfcGNpX2Ry
aXZlci5kcml2ZXIsICZkcml2ZXJfYXR0cl9uZXdfc2xvdCk7CkBAIC0xNDAyLDYgKzE0ODIs
OCBAQCBzdGF0aWMgdm9pZCBwY2lzdHViX2V4aXQodm9pZCkKIAkJCSAgICZkcml2ZXJfYXR0
cl9pcnFfaGFuZGxlcnMpOwogCWRyaXZlcl9yZW1vdmVfZmlsZSgmeGVuX3BjaWJrX3BjaV9k
cml2ZXIuZHJpdmVyLAogCQkJICAgJmRyaXZlcl9hdHRyX2lycV9oYW5kbGVyX3N0YXRlKTsK
Kwlkcml2ZXJfcmVtb3ZlX2ZpbGUoJnhlbl9wY2lia19wY2lfZHJpdmVyLmRyaXZlciwKKwkJ
CSAgICZkcml2ZXJfYXR0cl9kb19mbHIpOwogCXBjaV91bnJlZ2lzdGVyX2RyaXZlcigmeGVu
X3BjaWJrX3BjaV9kcml2ZXIpOwogfQogCkBAIC0xNDk1LDYgKzE1NzcsOSBAQCBzdGF0aWMg
aW50IF9faW5pdCBwY2lzdHViX2luaXQodm9pZCkKIAlpZiAoIWVycikKIAkJZXJyID0gZHJp
dmVyX2NyZWF0ZV9maWxlKCZ4ZW5fcGNpYmtfcGNpX2RyaXZlci5kcml2ZXIsCiAJCQkJCSZk
cml2ZXJfYXR0cl9pcnFfaGFuZGxlcl9zdGF0ZSk7CisJaWYgKCFlcnIpCisJCWVyciA9IGRy
aXZlcl9jcmVhdGVfZmlsZSgmeGVuX3BjaWJrX3BjaV9kcml2ZXIuZHJpdmVyLAorCQkJCQkm
ZHJpdmVyX2F0dHJfZG9fZmxyKTsKIAlpZiAoZXJyKQogCQlwY2lzdHViX2V4aXQoKTsKIAot
LSAKMS45LjMKCg==
------------04D1D80951745AACE
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------04D1D80951745AACE--



From xen-devel-bounces@lists.xen.org Thu Nov 27 11:17:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtx4C-0008TV-Bx; Thu, 27 Nov 2014 11:16:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xtx4B-0008TP-7X
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:16:55 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	89/68-25276-62807745; Thu, 27 Nov 2014 11:16:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417087014!11794247!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4175 invoked from network); 27 Nov 2014 11:16:54 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 11:16:54 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 11:16:53 +0000
Message-Id: <54771636020000780004B1DC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 11:16:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
	<20141127102650.GA13234@deinos.phlegethon.org>
In-Reply-To: <20141127102650.GA13234@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.11.14 at 11:26, <tim@xen.org> wrote:
> At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
>> >>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
>> > My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
>> > identify a failed vmentry and lets it fall into the default case of the
>> > vmexit handler.  As such, with v1, the infinite loop still affects AMD
>> > hardware.
>> 
>> Right; I should have said "something along the lines of v1". An SVM
>> part is needed, but that should probably extend beyond what you
>> proposed in v2: There are a number of "goto exit_and_crash"
>> statements ahead of where you place your addition. I think they
>> all need to be treated similarly.
>> 
>> I therefore think we should revert the VMX part of 28b4baacd5
>> and make SVM behavior consistent with what results for VMX:
>> Crash the guest unconditionally on VMEXIT_INVALID, without
>> looking for recurring VM entry failures. See below/attached.
>> 
>> Jan
>> 
>> x86/HVM: prevent infinite VM entry retries
>> 
>> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
>> guest upon problems occurring in user mode") and gets SVM in line with
>> the resulting VMX behavior. This is because Andrew validly says
>> 
>> "A failed vmentry is overwhelmingly likely to be caused by corrupt
>>  VMC[SB] state.  As a result, injecting a fault and retrying the the
>>  vmentry is likely to fail in the same way."
>> 
>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Looking at the SVM side, AFAICT you're trying to filter out
> VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
> think it's fine just to always crash on nested-SVM failures: we know
> the guest wasn't in user mode because it successfully executed VMRUN.
> And looking at it, the other users of that label are for unexpected
> debugging exits, which can't be caused by the guest userspace either.
> 
> So how about this for the SVM side, reverting to crashing for
> everything except new, unsupported exit types?

Generally a good idea, but there are two paths to exit_and_crash
(for VMEXIT_EXCEPTION_DB and VMEXIT_EXCEPTION_BP) which I
think would better crash only conditionally.

> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2675,16 +2675,18 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>          break;
>  
>      default:
> -    exit_and_crash:
>          gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", 
> "
>                   "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
>                   exit_reason, 
>                   (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
> -        if ( vmcb_get_cpl(vmcb) )
> +        if ( vmcb_get_cpl(vmcb) ) {
>              hvm_inject_hw_exception(TRAP_invalid_op,
>                                      HVM_DELIVER_NO_ERROR_CODE);
> -        else
> -            domain_crash(v->domain);
> +            break;
> +        }
> +        /* else fall through */
> +    exit_and_crash:
> +        domain_crash(v->domain);
>          break;
>      }

Additionally this re-arrangement would make some domain_crash()
invocations "silent" (i.e. no other accompanying message), but that's
of course easy to fix.

And finally, if doing it that way we might better remove the
exit_and_crash label altogether and call domain_crash() directly
in the places we mean it to be called.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:17:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtx4C-0008TV-Bx; Thu, 27 Nov 2014 11:16:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xtx4B-0008TP-7X
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:16:55 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	89/68-25276-62807745; Thu, 27 Nov 2014 11:16:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417087014!11794247!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4175 invoked from network); 27 Nov 2014 11:16:54 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 11:16:54 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 11:16:53 +0000
Message-Id: <54771636020000780004B1DC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 11:16:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
	<20141127102650.GA13234@deinos.phlegethon.org>
In-Reply-To: <20141127102650.GA13234@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.11.14 at 11:26, <tim@xen.org> wrote:
> At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
>> >>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
>> > My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
>> > identify a failed vmentry and lets it fall into the default case of the
>> > vmexit handler.  As such, with v1, the infinite loop still affects AMD
>> > hardware.
>> 
>> Right; I should have said "something along the lines of v1". An SVM
>> part is needed, but that should probably extend beyond what you
>> proposed in v2: There are a number of "goto exit_and_crash"
>> statements ahead of where you place your addition. I think they
>> all need to be treated similarly.
>> 
>> I therefore think we should revert the VMX part of 28b4baacd5
>> and make SVM behavior consistent with what results for VMX:
>> Crash the guest unconditionally on VMEXIT_INVALID, without
>> looking for recurring VM entry failures. See below/attached.
>> 
>> Jan
>> 
>> x86/HVM: prevent infinite VM entry retries
>> 
>> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
>> guest upon problems occurring in user mode") and gets SVM in line with
>> the resulting VMX behavior. This is because Andrew validly says
>> 
>> "A failed vmentry is overwhelmingly likely to be caused by corrupt
>>  VMC[SB] state.  As a result, injecting a fault and retrying the the
>>  vmentry is likely to fail in the same way."
>> 
>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Looking at the SVM side, AFAICT you're trying to filter out
> VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
> think it's fine just to always crash on nested-SVM failures: we know
> the guest wasn't in user mode because it successfully executed VMRUN.
> And looking at it, the other users of that label are for unexpected
> debugging exits, which can't be caused by the guest userspace either.
> 
> So how about this for the SVM side, reverting to crashing for
> everything except new, unsupported exit types?

Generally a good idea, but there are two paths to exit_and_crash
(for VMEXIT_EXCEPTION_DB and VMEXIT_EXCEPTION_BP) which I
think would better crash only conditionally.

> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2675,16 +2675,18 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>          break;
>  
>      default:
> -    exit_and_crash:
>          gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", 
> "
>                   "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
>                   exit_reason, 
>                   (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
> -        if ( vmcb_get_cpl(vmcb) )
> +        if ( vmcb_get_cpl(vmcb) ) {
>              hvm_inject_hw_exception(TRAP_invalid_op,
>                                      HVM_DELIVER_NO_ERROR_CODE);
> -        else
> -            domain_crash(v->domain);
> +            break;
> +        }
> +        /* else fall through */
> +    exit_and_crash:
> +        domain_crash(v->domain);
>          break;
>      }

Additionally this re-arrangement would make some domain_crash()
invocations "silent" (i.e. no other accompanying message), but that's
of course easy to fix.

And finally, if doing it that way we might better remove the
exit_and_crash label altogether and call domain_crash() directly
in the places we mean it to be called.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:20:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtx7d-00009f-0k; Thu, 27 Nov 2014 11:20:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xtx7b-00009Y-H5
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:20:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8D/CF-09842-AF807745; Thu, 27 Nov 2014 11:20:26 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417087222!11758501!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26891 invoked from network); 27 Nov 2014 11:20:25 -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;
	27 Nov 2014 11:20:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197403409"
Message-ID: <547708F3.5090502@citrix.com>
Date: Thu, 27 Nov 2014 11:20:19 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
	<20141127102650.GA13234@deinos.phlegethon.org>
	<54771636020000780004B1DC@mail.emea.novell.com>
In-Reply-To: <54771636020000780004B1DC@mail.emea.novell.com>
X-DLP: MIA1
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/11/14 11:16, Jan Beulich wrote:
>>>> On 27.11.14 at 11:26, <tim@xen.org> wrote:
>> At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
>>>>>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
>>>> My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
>>>> identify a failed vmentry and lets it fall into the default case of the
>>>> vmexit handler.  As such, with v1, the infinite loop still affects AMD
>>>> hardware.
>>> Right; I should have said "something along the lines of v1". An SVM
>>> part is needed, but that should probably extend beyond what you
>>> proposed in v2: There are a number of "goto exit_and_crash"
>>> statements ahead of where you place your addition. I think they
>>> all need to be treated similarly.
>>>
>>> I therefore think we should revert the VMX part of 28b4baacd5
>>> and make SVM behavior consistent with what results for VMX:
>>> Crash the guest unconditionally on VMEXIT_INVALID, without
>>> looking for recurring VM entry failures. See below/attached.
>>>
>>> Jan
>>>
>>> x86/HVM: prevent infinite VM entry retries
>>>
>>> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
>>> guest upon problems occurring in user mode") and gets SVM in line with
>>> the resulting VMX behavior. This is because Andrew validly says
>>>
>>> "A failed vmentry is overwhelmingly likely to be caused by corrupt
>>>  VMC[SB] state.  As a result, injecting a fault and retrying the the
>>>  vmentry is likely to fail in the same way."
>>>
>>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Looking at the SVM side, AFAICT you're trying to filter out
>> VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
>> think it's fine just to always crash on nested-SVM failures: we know
>> the guest wasn't in user mode because it successfully executed VMRUN.
>> And looking at it, the other users of that label are for unexpected
>> debugging exits, which can't be caused by the guest userspace either.
>>
>> So how about this for the SVM side, reverting to crashing for
>> everything except new, unsupported exit types?
> Generally a good idea, but there are two paths to exit_and_crash
> (for VMEXIT_EXCEPTION_DB and VMEXIT_EXCEPTION_BP) which I
> think would better crash only conditionally.

I would agree - these two should only be conditional crashes. If the
intercepts are enabled, userspace is perfectly capable of generating the
conditions behind the back of the kernel.

~Andrew

>
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -2675,16 +2675,18 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>>          break;
>>  
>>      default:
>> -    exit_and_crash:
>>          gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", 
>> "
>>                   "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
>>                   exit_reason, 
>>                   (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
>> -        if ( vmcb_get_cpl(vmcb) )
>> +        if ( vmcb_get_cpl(vmcb) ) {
>>              hvm_inject_hw_exception(TRAP_invalid_op,
>>                                      HVM_DELIVER_NO_ERROR_CODE);
>> -        else
>> -            domain_crash(v->domain);
>> +            break;
>> +        }
>> +        /* else fall through */
>> +    exit_and_crash:
>> +        domain_crash(v->domain);
>>          break;
>>      }
> Additionally this re-arrangement would make some domain_crash()
> invocations "silent" (i.e. no other accompanying message), but that's
> of course easy to fix.
>
> And finally, if doing it that way we might better remove the
> exit_and_crash label altogether and call domain_crash() directly
> in the places we mean it to be called.
>
> Jan
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:20:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtx7d-00009f-0k; Thu, 27 Nov 2014 11:20:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xtx7b-00009Y-H5
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:20:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8D/CF-09842-AF807745; Thu, 27 Nov 2014 11:20:26 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417087222!11758501!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26891 invoked from network); 27 Nov 2014 11:20:25 -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;
	27 Nov 2014 11:20:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197403409"
Message-ID: <547708F3.5090502@citrix.com>
Date: Thu, 27 Nov 2014 11:20:19 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
	<20141127102650.GA13234@deinos.phlegethon.org>
	<54771636020000780004B1DC@mail.emea.novell.com>
In-Reply-To: <54771636020000780004B1DC@mail.emea.novell.com>
X-DLP: MIA1
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/11/14 11:16, Jan Beulich wrote:
>>>> On 27.11.14 at 11:26, <tim@xen.org> wrote:
>> At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
>>>>>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
>>>> My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
>>>> identify a failed vmentry and lets it fall into the default case of the
>>>> vmexit handler.  As such, with v1, the infinite loop still affects AMD
>>>> hardware.
>>> Right; I should have said "something along the lines of v1". An SVM
>>> part is needed, but that should probably extend beyond what you
>>> proposed in v2: There are a number of "goto exit_and_crash"
>>> statements ahead of where you place your addition. I think they
>>> all need to be treated similarly.
>>>
>>> I therefore think we should revert the VMX part of 28b4baacd5
>>> and make SVM behavior consistent with what results for VMX:
>>> Crash the guest unconditionally on VMEXIT_INVALID, without
>>> looking for recurring VM entry failures. See below/attached.
>>>
>>> Jan
>>>
>>> x86/HVM: prevent infinite VM entry retries
>>>
>>> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
>>> guest upon problems occurring in user mode") and gets SVM in line with
>>> the resulting VMX behavior. This is because Andrew validly says
>>>
>>> "A failed vmentry is overwhelmingly likely to be caused by corrupt
>>>  VMC[SB] state.  As a result, injecting a fault and retrying the the
>>>  vmentry is likely to fail in the same way."
>>>
>>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Looking at the SVM side, AFAICT you're trying to filter out
>> VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
>> think it's fine just to always crash on nested-SVM failures: we know
>> the guest wasn't in user mode because it successfully executed VMRUN.
>> And looking at it, the other users of that label are for unexpected
>> debugging exits, which can't be caused by the guest userspace either.
>>
>> So how about this for the SVM side, reverting to crashing for
>> everything except new, unsupported exit types?
> Generally a good idea, but there are two paths to exit_and_crash
> (for VMEXIT_EXCEPTION_DB and VMEXIT_EXCEPTION_BP) which I
> think would better crash only conditionally.

I would agree - these two should only be conditional crashes. If the
intercepts are enabled, userspace is perfectly capable of generating the
conditions behind the back of the kernel.

~Andrew

>
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -2675,16 +2675,18 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>>          break;
>>  
>>      default:
>> -    exit_and_crash:
>>          gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", 
>> "
>>                   "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
>>                   exit_reason, 
>>                   (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
>> -        if ( vmcb_get_cpl(vmcb) )
>> +        if ( vmcb_get_cpl(vmcb) ) {
>>              hvm_inject_hw_exception(TRAP_invalid_op,
>>                                      HVM_DELIVER_NO_ERROR_CODE);
>> -        else
>> -            domain_crash(v->domain);
>> +            break;
>> +        }
>> +        /* else fall through */
>> +    exit_and_crash:
>> +        domain_crash(v->domain);
>>          break;
>>      }
> Additionally this re-arrangement would make some domain_crash()
> invocations "silent" (i.e. no other accompanying message), but that's
> of course easy to fix.
>
> And finally, if doing it that way we might better remove the
> exit_and_crash label altogether and call domain_crash() directly
> in the places we mean it to be called.
>
> Jan
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:30:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxGm-0000TW-4Z; Thu, 27 Nov 2014 11:29:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XtxGk-0000TR-08
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:29:54 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	42/59-20609-13B07745; Thu, 27 Nov 2014 11:29:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417087792!15233715!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22070 invoked from network); 27 Nov 2014 11:29:52 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 11:29:52 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XtxGS-00058V-6x; Thu, 27 Nov 2014 11:29:36 +0000
Date: Thu, 27 Nov 2014 12:29:36 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141127112936.GB13234@deinos.phlegethon.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
	<20141127102650.GA13234@deinos.phlegethon.org>
	<54771636020000780004B1DC@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54771636020000780004B1DC@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:16 +0000 on 27 Nov (1417083414), Jan Beulich wrote:
> >>> On 27.11.14 at 11:26, <tim@xen.org> wrote:
> > At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
> >> >>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
> >> > My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
> >> > identify a failed vmentry and lets it fall into the default case of the
> >> > vmexit handler.  As such, with v1, the infinite loop still affects AMD
> >> > hardware.
> >> 
> >> Right; I should have said "something along the lines of v1". An SVM
> >> part is needed, but that should probably extend beyond what you
> >> proposed in v2: There are a number of "goto exit_and_crash"
> >> statements ahead of where you place your addition. I think they
> >> all need to be treated similarly.
> >> 
> >> I therefore think we should revert the VMX part of 28b4baacd5
> >> and make SVM behavior consistent with what results for VMX:
> >> Crash the guest unconditionally on VMEXIT_INVALID, without
> >> looking for recurring VM entry failures. See below/attached.
> >> 
> >> Jan
> >> 
> >> x86/HVM: prevent infinite VM entry retries
> >> 
> >> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
> >> guest upon problems occurring in user mode") and gets SVM in line with
> >> the resulting VMX behavior. This is because Andrew validly says
> >> 
> >> "A failed vmentry is overwhelmingly likely to be caused by corrupt
> >>  VMC[SB] state.  As a result, injecting a fault and retrying the the
> >>  vmentry is likely to fail in the same way."
> >> 
> >> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > Looking at the SVM side, AFAICT you're trying to filter out
> > VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
> > think it's fine just to always crash on nested-SVM failures: we know
> > the guest wasn't in user mode because it successfully executed VMRUN.
> > And looking at it, the other users of that label are for unexpected
> > debugging exits, which can't be caused by the guest userspace either.
> > 
> > So how about this for the SVM side, reverting to crashing for
> > everything except new, unsupported exit types?
> 
> Generally a good idea, but there are two paths to exit_and_crash
> (for VMEXIT_EXCEPTION_DB and VMEXIT_EXCEPTION_BP) which I
> think would better crash only conditionally.

Those are catching Xen bugs -- we don't (or at least shouldn't) enable
those exit types when the debugger is not attached.  I think that,
like with the p2m ENOMEM case, turning them into #UD is not really
helpful.  But if you prefer, those could be made into 'goto default'
to preserve the current behaviour, which would also retain the
debugging output.

> And finally, if doing it that way we might better remove the
> exit_and_crash label altogether and call domain_crash() directly
> in the places we mean it to be called.

Indeed.  How's this, then?

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 8aca6e6..213fd6e 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2362,7 +2362,8 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
                 goto out;
             case NESTEDHVM_VMEXIT_FATALERROR:
                 gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() error\n");
-                goto exit_and_crash;
+                domain_crash(v->domain);
+                goto out;
 
             default:
                 BUG();
@@ -2376,18 +2377,21 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
         case NESTEDHVM_VMEXIT_FATALERROR:
             gdprintk(XENLOG_ERR,
                 "unexpected nestedsvm_check_intercepts() error\n");
-            goto exit_and_crash;
+            domain_crash(v->domain);
+            goto out;
         default:
             gdprintk(XENLOG_INFO, "nestedsvm_check_intercepts() returned %i\n",
                 nsret);
-            goto exit_and_crash;
+            domain_crash(v->domain);
+            goto out;
         }
     }
 
     if ( unlikely(exit_reason == VMEXIT_INVALID) )
     {
         svm_vmcb_dump(__func__, vmcb);
-        goto exit_and_crash;
+        domain_crash(v->domain);
+        goto out;
     }
 
     perfc_incra(svmexits, exit_reason);
@@ -2422,13 +2426,13 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 
     case VMEXIT_EXCEPTION_DB:
         if ( !v->domain->debugger_attached )
-            goto exit_and_crash;
+            goto unexpected_exit_type;
         domain_pause_for_debugger();
         break;
 
     case VMEXIT_EXCEPTION_BP:
         if ( !v->domain->debugger_attached )
-            goto exit_and_crash;
+            goto unexpected_exit_type;
         /* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. */
         if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
             break;
@@ -2675,7 +2679,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
         break;
 
     default:
-    exit_and_crash:
+    unexpected_exit_type:
         gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", "
                  "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
                  exit_reason, 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:30:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxGm-0000TW-4Z; Thu, 27 Nov 2014 11:29:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XtxGk-0000TR-08
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:29:54 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	42/59-20609-13B07745; Thu, 27 Nov 2014 11:29:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417087792!15233715!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22070 invoked from network); 27 Nov 2014 11:29:52 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 11:29:52 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XtxGS-00058V-6x; Thu, 27 Nov 2014 11:29:36 +0000
Date: Thu, 27 Nov 2014 12:29:36 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141127112936.GB13234@deinos.phlegethon.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
	<20141127102650.GA13234@deinos.phlegethon.org>
	<54771636020000780004B1DC@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54771636020000780004B1DC@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:16 +0000 on 27 Nov (1417083414), Jan Beulich wrote:
> >>> On 27.11.14 at 11:26, <tim@xen.org> wrote:
> > At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
> >> >>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
> >> > My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
> >> > identify a failed vmentry and lets it fall into the default case of the
> >> > vmexit handler.  As such, with v1, the infinite loop still affects AMD
> >> > hardware.
> >> 
> >> Right; I should have said "something along the lines of v1". An SVM
> >> part is needed, but that should probably extend beyond what you
> >> proposed in v2: There are a number of "goto exit_and_crash"
> >> statements ahead of where you place your addition. I think they
> >> all need to be treated similarly.
> >> 
> >> I therefore think we should revert the VMX part of 28b4baacd5
> >> and make SVM behavior consistent with what results for VMX:
> >> Crash the guest unconditionally on VMEXIT_INVALID, without
> >> looking for recurring VM entry failures. See below/attached.
> >> 
> >> Jan
> >> 
> >> x86/HVM: prevent infinite VM entry retries
> >> 
> >> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
> >> guest upon problems occurring in user mode") and gets SVM in line with
> >> the resulting VMX behavior. This is because Andrew validly says
> >> 
> >> "A failed vmentry is overwhelmingly likely to be caused by corrupt
> >>  VMC[SB] state.  As a result, injecting a fault and retrying the the
> >>  vmentry is likely to fail in the same way."
> >> 
> >> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > Looking at the SVM side, AFAICT you're trying to filter out
> > VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
> > think it's fine just to always crash on nested-SVM failures: we know
> > the guest wasn't in user mode because it successfully executed VMRUN.
> > And looking at it, the other users of that label are for unexpected
> > debugging exits, which can't be caused by the guest userspace either.
> > 
> > So how about this for the SVM side, reverting to crashing for
> > everything except new, unsupported exit types?
> 
> Generally a good idea, but there are two paths to exit_and_crash
> (for VMEXIT_EXCEPTION_DB and VMEXIT_EXCEPTION_BP) which I
> think would better crash only conditionally.

Those are catching Xen bugs -- we don't (or at least shouldn't) enable
those exit types when the debugger is not attached.  I think that,
like with the p2m ENOMEM case, turning them into #UD is not really
helpful.  But if you prefer, those could be made into 'goto default'
to preserve the current behaviour, which would also retain the
debugging output.

> And finally, if doing it that way we might better remove the
> exit_and_crash label altogether and call domain_crash() directly
> in the places we mean it to be called.

Indeed.  How's this, then?

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 8aca6e6..213fd6e 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2362,7 +2362,8 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
                 goto out;
             case NESTEDHVM_VMEXIT_FATALERROR:
                 gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() error\n");
-                goto exit_and_crash;
+                domain_crash(v->domain);
+                goto out;
 
             default:
                 BUG();
@@ -2376,18 +2377,21 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
         case NESTEDHVM_VMEXIT_FATALERROR:
             gdprintk(XENLOG_ERR,
                 "unexpected nestedsvm_check_intercepts() error\n");
-            goto exit_and_crash;
+            domain_crash(v->domain);
+            goto out;
         default:
             gdprintk(XENLOG_INFO, "nestedsvm_check_intercepts() returned %i\n",
                 nsret);
-            goto exit_and_crash;
+            domain_crash(v->domain);
+            goto out;
         }
     }
 
     if ( unlikely(exit_reason == VMEXIT_INVALID) )
     {
         svm_vmcb_dump(__func__, vmcb);
-        goto exit_and_crash;
+        domain_crash(v->domain);
+        goto out;
     }
 
     perfc_incra(svmexits, exit_reason);
@@ -2422,13 +2426,13 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 
     case VMEXIT_EXCEPTION_DB:
         if ( !v->domain->debugger_attached )
-            goto exit_and_crash;
+            goto unexpected_exit_type;
         domain_pause_for_debugger();
         break;
 
     case VMEXIT_EXCEPTION_BP:
         if ( !v->domain->debugger_attached )
-            goto exit_and_crash;
+            goto unexpected_exit_type;
         /* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. */
         if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
             break;
@@ -2675,7 +2679,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
         break;
 
     default:
-    exit_and_crash:
+    unexpected_exit_type:
         gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", "
                  "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
                  exit_reason, 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:32:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxJY-0000k8-Mj; Thu, 27 Nov 2014 11:32: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 1XtxJX-0000k0-Ln
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 11:32:47 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A7/99-26652-EDB07745; Thu, 27 Nov 2014 11:32:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417087965!13653721!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5617 invoked from network); 27 Nov 2014 11:32:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 11:32:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197406554"
Message-ID: <1417087963.12784.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 27 Nov 2014 11:32:43 +0000
In-Reply-To: <54770582.80207@citrix.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com> <5475E311.6070501@citrix.com>
	<1417081768.11944.70.camel@citrix.com> <54770582.80207@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 11:05 +0000, Andrew Cooper wrote:
> On 27/11/14 09:49, Ian Campbell wrote:
> > On Wed, 2014-11-26 at 14:26 +0000, Andrew Cooper wrote:
> >> libxc (or some new alternative) should suck it up and gain some notion
> >> of a stable API or ABI (like the rest of the world appears to be able to
> >> manage), such that it is possible to compile with an older header and
> >> use a newer .so at runtime.
> > Retrofitting a stable API/ABI to the melting pot which is libxc simply
> > isn't going to work in practice.
> >
> > IMO the most likely to succeed approach would be to split off the bits
> > of libxc which 3rd party's can/should/need to rely on into one of more
> > libraries, probably by functional area.
> >
> > So far I'm aware of plans (or at least desires) to do that for:
> >
> >       * Interfaces used by device-models/qemu.
> >       * The bits which are useful inside a guest (i.e. the
> >         various /dev/xen/* related helpers).
> >
> > So it sounds like libxenkexec should be added to that list.
> >
> > Ian.
> >
> 
> Agreed.
> 
> For a domU, I think we need libxenevt, libxengnt and libxenstore with
> stable API and ABIs.  This in turn will permit libvchan to work without
> needing libxenctrl.
>
> For dom0, each of the libraries is going to need basic hypercall
> functionality.  It might be worth considering making libxenbasic (name
> looking for improvement) which is more along the lines of a privcmd
> driver, providing do_hypercall() and bounce buffering.

> libxenctrl and
> others can then avoid reimplementing the wheel many times.

NB that if such a library contains the h/call wrappers for any
non-stable hypercall interface (I'm not sure if that was what you were
suggesting or not) then it would itself remain ABI/API unstable.

But anyway there's nothing stopping libxen* using interfaces exposed by
an unstable libxenctrl or libxenbasic and remaining interface stable
themselves, so you can avoid reimplementing the wheel that way.

Those libraries just need to do the impedance matching and link the
correct SONAME for the unstable library, the linker will take care of
the rest.

I don't think it is going to be realistic in practice to support keeping
the exact same libxenfoo.so.N binary working across multiple releases,
but rather each release will provide its own libxenfoo.so.N with the
same N and supporting the same ABI, such that it can just be swapped in
under the feet of the application.

The alternative is to do dlopen stuff on the unstable backend library,
which is going to be a nightmare, from the test matrix PoV if nothing
else.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:32:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxJY-0000k8-Mj; Thu, 27 Nov 2014 11:32: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 1XtxJX-0000k0-Ln
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 11:32:47 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A7/99-26652-EDB07745; Thu, 27 Nov 2014 11:32:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417087965!13653721!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5617 invoked from network); 27 Nov 2014 11:32:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 11:32:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197406554"
Message-ID: <1417087963.12784.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 27 Nov 2014 11:32:43 +0000
In-Reply-To: <54770582.80207@citrix.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>
	<5475DD4F.9060203@suse.com> <5475E311.6070501@citrix.com>
	<1417081768.11944.70.camel@citrix.com> <54770582.80207@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 11:05 +0000, Andrew Cooper wrote:
> On 27/11/14 09:49, Ian Campbell wrote:
> > On Wed, 2014-11-26 at 14:26 +0000, Andrew Cooper wrote:
> >> libxc (or some new alternative) should suck it up and gain some notion
> >> of a stable API or ABI (like the rest of the world appears to be able to
> >> manage), such that it is possible to compile with an older header and
> >> use a newer .so at runtime.
> > Retrofitting a stable API/ABI to the melting pot which is libxc simply
> > isn't going to work in practice.
> >
> > IMO the most likely to succeed approach would be to split off the bits
> > of libxc which 3rd party's can/should/need to rely on into one of more
> > libraries, probably by functional area.
> >
> > So far I'm aware of plans (or at least desires) to do that for:
> >
> >       * Interfaces used by device-models/qemu.
> >       * The bits which are useful inside a guest (i.e. the
> >         various /dev/xen/* related helpers).
> >
> > So it sounds like libxenkexec should be added to that list.
> >
> > Ian.
> >
> 
> Agreed.
> 
> For a domU, I think we need libxenevt, libxengnt and libxenstore with
> stable API and ABIs.  This in turn will permit libvchan to work without
> needing libxenctrl.
>
> For dom0, each of the libraries is going to need basic hypercall
> functionality.  It might be worth considering making libxenbasic (name
> looking for improvement) which is more along the lines of a privcmd
> driver, providing do_hypercall() and bounce buffering.

> libxenctrl and
> others can then avoid reimplementing the wheel many times.

NB that if such a library contains the h/call wrappers for any
non-stable hypercall interface (I'm not sure if that was what you were
suggesting or not) then it would itself remain ABI/API unstable.

But anyway there's nothing stopping libxen* using interfaces exposed by
an unstable libxenctrl or libxenbasic and remaining interface stable
themselves, so you can avoid reimplementing the wheel that way.

Those libraries just need to do the impedance matching and link the
correct SONAME for the unstable library, the linker will take care of
the rest.

I don't think it is going to be realistic in practice to support keeping
the exact same libxenfoo.so.N binary working across multiple releases,
but rather each release will provide its own libxenfoo.so.N with the
same N and supporting the same ABI, such that it can just be swapped in
under the feet of the application.

The alternative is to do dlopen stuff on the unstable backend library,
which is going to be a nightmare, from the test matrix PoV if nothing
else.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:38:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxOp-0000tp-F1; Thu, 27 Nov 2014 11:38:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtxOo-0000tk-1r
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:38:14 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	B8/BA-05632-52D07745; Thu, 27 Nov 2014 11:38:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417088292!14188898!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21568 invoked from network); 27 Nov 2014 11:38:12 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 11:38:12 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 11:38:12 +0000
Message-Id: <54771B33020000780004B1FF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 11:38:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
	<20141127102650.GA13234@deinos.phlegethon.org>
	<54771636020000780004B1DC@mail.emea.novell.com>
	<20141127112936.GB13234@deinos.phlegethon.org>
In-Reply-To: <20141127112936.GB13234@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.11.14 at 12:29, <tim@xen.org> wrote:
> At 11:16 +0000 on 27 Nov (1417083414), Jan Beulich wrote:
>> >>> On 27.11.14 at 11:26, <tim@xen.org> wrote:
>> > At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
>> >> >>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
>> >> > My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
>> >> > identify a failed vmentry and lets it fall into the default case of the
>> >> > vmexit handler.  As such, with v1, the infinite loop still affects AMD
>> >> > hardware.
>> >> 
>> >> Right; I should have said "something along the lines of v1". An SVM
>> >> part is needed, but that should probably extend beyond what you
>> >> proposed in v2: There are a number of "goto exit_and_crash"
>> >> statements ahead of where you place your addition. I think they
>> >> all need to be treated similarly.
>> >> 
>> >> I therefore think we should revert the VMX part of 28b4baacd5
>> >> and make SVM behavior consistent with what results for VMX:
>> >> Crash the guest unconditionally on VMEXIT_INVALID, without
>> >> looking for recurring VM entry failures. See below/attached.
>> >> 
>> >> Jan
>> >> 
>> >> x86/HVM: prevent infinite VM entry retries
>> >> 
>> >> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
>> >> guest upon problems occurring in user mode") and gets SVM in line with
>> >> the resulting VMX behavior. This is because Andrew validly says
>> >> 
>> >> "A failed vmentry is overwhelmingly likely to be caused by corrupt
>> >>  VMC[SB] state.  As a result, injecting a fault and retrying the the
>> >>  vmentry is likely to fail in the same way."
>> >> 
>> >> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> > 
>> > Looking at the SVM side, AFAICT you're trying to filter out
>> > VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
>> > think it's fine just to always crash on nested-SVM failures: we know
>> > the guest wasn't in user mode because it successfully executed VMRUN.
>> > And looking at it, the other users of that label are for unexpected
>> > debugging exits, which can't be caused by the guest userspace either.
>> > 
>> > So how about this for the SVM side, reverting to crashing for
>> > everything except new, unsupported exit types?
>> 
>> Generally a good idea, but there are two paths to exit_and_crash
>> (for VMEXIT_EXCEPTION_DB and VMEXIT_EXCEPTION_BP) which I
>> think would better crash only conditionally.
> 
> Those are catching Xen bugs -- we don't (or at least shouldn't) enable
> those exit types when the debugger is not attached.  I think that,
> like with the p2m ENOMEM case, turning them into #UD is not really
> helpful.  But if you prefer, those could be made into 'goto default'
> to preserve the current behaviour, which would also retain the
> debugging output.
> 
>> And finally, if doing it that way we might better remove the
>> exit_and_crash label altogether and call domain_crash() directly
>> in the places we mean it to be called.
> 
> Indeed.  How's this, then?

Looks good - if you don't mind I'll replace the SVM part of the earlier
patch with this, add your S-o-b alongside mine, and send again for
final review.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:38:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxOp-0000tp-F1; Thu, 27 Nov 2014 11:38:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtxOo-0000tk-1r
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:38:14 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	B8/BA-05632-52D07745; Thu, 27 Nov 2014 11:38:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417088292!14188898!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21568 invoked from network); 27 Nov 2014 11:38:12 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 11:38:12 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 11:38:12 +0000
Message-Id: <54771B33020000780004B1FF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 11:38:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
	<20141127102650.GA13234@deinos.phlegethon.org>
	<54771636020000780004B1DC@mail.emea.novell.com>
	<20141127112936.GB13234@deinos.phlegethon.org>
In-Reply-To: <20141127112936.GB13234@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.11.14 at 12:29, <tim@xen.org> wrote:
> At 11:16 +0000 on 27 Nov (1417083414), Jan Beulich wrote:
>> >>> On 27.11.14 at 11:26, <tim@xen.org> wrote:
>> > At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
>> >> >>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
>> >> > My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
>> >> > identify a failed vmentry and lets it fall into the default case of the
>> >> > vmexit handler.  As such, with v1, the infinite loop still affects AMD
>> >> > hardware.
>> >> 
>> >> Right; I should have said "something along the lines of v1". An SVM
>> >> part is needed, but that should probably extend beyond what you
>> >> proposed in v2: There are a number of "goto exit_and_crash"
>> >> statements ahead of where you place your addition. I think they
>> >> all need to be treated similarly.
>> >> 
>> >> I therefore think we should revert the VMX part of 28b4baacd5
>> >> and make SVM behavior consistent with what results for VMX:
>> >> Crash the guest unconditionally on VMEXIT_INVALID, without
>> >> looking for recurring VM entry failures. See below/attached.
>> >> 
>> >> Jan
>> >> 
>> >> x86/HVM: prevent infinite VM entry retries
>> >> 
>> >> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
>> >> guest upon problems occurring in user mode") and gets SVM in line with
>> >> the resulting VMX behavior. This is because Andrew validly says
>> >> 
>> >> "A failed vmentry is overwhelmingly likely to be caused by corrupt
>> >>  VMC[SB] state.  As a result, injecting a fault and retrying the the
>> >>  vmentry is likely to fail in the same way."
>> >> 
>> >> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> > 
>> > Looking at the SVM side, AFAICT you're trying to filter out
>> > VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
>> > think it's fine just to always crash on nested-SVM failures: we know
>> > the guest wasn't in user mode because it successfully executed VMRUN.
>> > And looking at it, the other users of that label are for unexpected
>> > debugging exits, which can't be caused by the guest userspace either.
>> > 
>> > So how about this for the SVM side, reverting to crashing for
>> > everything except new, unsupported exit types?
>> 
>> Generally a good idea, but there are two paths to exit_and_crash
>> (for VMEXIT_EXCEPTION_DB and VMEXIT_EXCEPTION_BP) which I
>> think would better crash only conditionally.
> 
> Those are catching Xen bugs -- we don't (or at least shouldn't) enable
> those exit types when the debugger is not attached.  I think that,
> like with the p2m ENOMEM case, turning them into #UD is not really
> helpful.  But if you prefer, those could be made into 'goto default'
> to preserve the current behaviour, which would also retain the
> debugging output.
> 
>> And finally, if doing it that way we might better remove the
>> exit_and_crash label altogether and call domain_crash() directly
>> in the places we mean it to be called.
> 
> Indeed.  How's this, then?

Looks good - if you don't mind I'll replace the SVM part of the earlier
patch with this, add your S-o-b alongside mine, and send again for
final review.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:40:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11: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.xen.org>)
	id 1XtxR0-00011Y-43; Thu, 27 Nov 2014 11:40:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XtxQy-00011T-JK
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:40:28 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	FF/28-02696-CAD07745; Thu, 27 Nov 2014 11:40:28 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417088425!15252532!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25598 invoked from network); 27 Nov 2014 11:40:27 -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;
	27 Nov 2014 11:40:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197408227"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 06:40:24 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XtxQu-0000TY-3x	for
	xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:40:24 +0000
Message-ID: <54770D8D.1090107@eu.citrix.com>
Date: Thu, 27 Nov 2014 11:39:57 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-DLP: MIA2
Subject: [Xen-devel] [COVERITY ACCESS] Request for access to Coverity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I agree to the conditions in the XenProject Coverity contribution
guidelines [1].

I'm a developer working for Citrix Systems UK, Ltd.  I've been active
in the Xen community since 2006; I was release coordinator for the 4.3
and 4.4 releases, and I am currently maintainer of the Xen scheduling
subsystem.

I would like access primarily to be able to write and speak
intelligently about Xen and Coverity in blog postings and conference
talks.  I figure it would be easier to go through the stats and
history myself, rather than trying to get some other developer to do
it for me.  (Although of course once I have access I'll probably end
up doing some work looking at scans anyway.)

[1] http://xenproject.org/help/contribution-guidelines.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUdw2HAAoJELIVx6fHhBvtZcEH/RPj3Sj74oVcCWe44/bwgCX+
9UPZBnYLPfm4QLP9CNuKqRAdvBAm6ZUDrV22raBP9BRycGxN+jMLaZ0GAEK8NtuX
jI723Xry5xxw5HoGl+yGq3gBXk09sLV0ftvJo4HwbsbkIhXDmETsjlnPOCAzJL4V
zxfHoKgWJjeoZMR1qVH5iBTwFykpSMKLRFanmIVu6C+j6byYu/mWeo+kzS4eZwUQ
m4nDBk90frd0BOSagnfxxXhjDX5Us4CA8vW+BLe34/io7kSmWuxAQmwoJX3T1tt4
KBy7vhkUx7lZBPswATb/tJxhTiH7PCbkQXPtTlI7ciKQfgFM4AZU+WCS8PsKNqo=
=ACeq
-----END PGP SIGNATURE-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:40:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11: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.xen.org>)
	id 1XtxR0-00011Y-43; Thu, 27 Nov 2014 11:40:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XtxQy-00011T-JK
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:40:28 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	FF/28-02696-CAD07745; Thu, 27 Nov 2014 11:40:28 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417088425!15252532!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25598 invoked from network); 27 Nov 2014 11:40:27 -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;
	27 Nov 2014 11:40:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197408227"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 06:40:24 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XtxQu-0000TY-3x	for
	xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:40:24 +0000
Message-ID: <54770D8D.1090107@eu.citrix.com>
Date: Thu, 27 Nov 2014 11:39:57 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-DLP: MIA2
Subject: [Xen-devel] [COVERITY ACCESS] Request for access to Coverity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I agree to the conditions in the XenProject Coverity contribution
guidelines [1].

I'm a developer working for Citrix Systems UK, Ltd.  I've been active
in the Xen community since 2006; I was release coordinator for the 4.3
and 4.4 releases, and I am currently maintainer of the Xen scheduling
subsystem.

I would like access primarily to be able to write and speak
intelligently about Xen and Coverity in blog postings and conference
talks.  I figure it would be easier to go through the stats and
history myself, rather than trying to get some other developer to do
it for me.  (Although of course once I have access I'll probably end
up doing some work looking at scans anyway.)

[1] http://xenproject.org/help/contribution-guidelines.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUdw2HAAoJELIVx6fHhBvtZcEH/RPj3Sj74oVcCWe44/bwgCX+
9UPZBnYLPfm4QLP9CNuKqRAdvBAm6ZUDrV22raBP9BRycGxN+jMLaZ0GAEK8NtuX
jI723Xry5xxw5HoGl+yGq3gBXk09sLV0ftvJo4HwbsbkIhXDmETsjlnPOCAzJL4V
zxfHoKgWJjeoZMR1qVH5iBTwFykpSMKLRFanmIVu6C+j6byYu/mWeo+kzS4eZwUQ
m4nDBk90frd0BOSagnfxxXhjDX5Us4CA8vW+BLe34/io7kSmWuxAQmwoJX3T1tt4
KBy7vhkUx7lZBPswATb/tJxhTiH7PCbkQXPtTlI7ciKQfgFM4AZU+WCS8PsKNqo=
=ACeq
-----END PGP SIGNATURE-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:44:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:44:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxV5-0001M0-PW; Thu, 27 Nov 2014 11:44: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 1XtxV5-0001Lt-8A
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:44:43 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	C9/3C-19763-AAE07745; Thu, 27 Nov 2014 11:44:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417088680!13653001!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17222 invoked from network); 27 Nov 2014 11:44:40 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 11:44:40 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XtxUm-0005OQ-Ak; Thu, 27 Nov 2014 11:44:24 +0000
Date: Thu, 27 Nov 2014 12:44:24 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141127114424.GA13236@deinos.phlegethon.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
	<20141127102650.GA13234@deinos.phlegethon.org>
	<54771636020000780004B1DC@mail.emea.novell.com>
	<20141127112936.GB13234@deinos.phlegethon.org>
	<54771B33020000780004B1FF@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54771B33020000780004B1FF@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:38 +0000 on 27 Nov (1417084691), Jan Beulich wrote:
> >>> On 27.11.14 at 12:29, <tim@xen.org> wrote:
> > At 11:16 +0000 on 27 Nov (1417083414), Jan Beulich wrote:
> >> >>> On 27.11.14 at 11:26, <tim@xen.org> wrote:
> >> > At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
> >> >> >>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
> >> >> > My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
> >> >> > identify a failed vmentry and lets it fall into the default case of the
> >> >> > vmexit handler.  As such, with v1, the infinite loop still affects AMD
> >> >> > hardware.
> >> >> 
> >> >> Right; I should have said "something along the lines of v1". An SVM
> >> >> part is needed, but that should probably extend beyond what you
> >> >> proposed in v2: There are a number of "goto exit_and_crash"
> >> >> statements ahead of where you place your addition. I think they
> >> >> all need to be treated similarly.
> >> >> 
> >> >> I therefore think we should revert the VMX part of 28b4baacd5
> >> >> and make SVM behavior consistent with what results for VMX:
> >> >> Crash the guest unconditionally on VMEXIT_INVALID, without
> >> >> looking for recurring VM entry failures. See below/attached.
> >> >> 
> >> >> Jan
> >> >> 
> >> >> x86/HVM: prevent infinite VM entry retries
> >> >> 
> >> >> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
> >> >> guest upon problems occurring in user mode") and gets SVM in line with
> >> >> the resulting VMX behavior. This is because Andrew validly says
> >> >> 
> >> >> "A failed vmentry is overwhelmingly likely to be caused by corrupt
> >> >>  VMC[SB] state.  As a result, injecting a fault and retrying the the
> >> >>  vmentry is likely to fail in the same way."
> >> >> 
> >> >> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> > 
> >> > Looking at the SVM side, AFAICT you're trying to filter out
> >> > VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
> >> > think it's fine just to always crash on nested-SVM failures: we know
> >> > the guest wasn't in user mode because it successfully executed VMRUN.
> >> > And looking at it, the other users of that label are for unexpected
> >> > debugging exits, which can't be caused by the guest userspace either.
> >> > 
> >> > So how about this for the SVM side, reverting to crashing for
> >> > everything except new, unsupported exit types?
> >> 
> >> Generally a good idea, but there are two paths to exit_and_crash
> >> (for VMEXIT_EXCEPTION_DB and VMEXIT_EXCEPTION_BP) which I
> >> think would better crash only conditionally.
> > 
> > Those are catching Xen bugs -- we don't (or at least shouldn't) enable
> > those exit types when the debugger is not attached.  I think that,
> > like with the p2m ENOMEM case, turning them into #UD is not really
> > helpful.  But if you prefer, those could be made into 'goto default'
> > to preserve the current behaviour, which would also retain the
> > debugging output.
> > 
> >> And finally, if doing it that way we might better remove the
> >> exit_and_crash label altogether and call domain_crash() directly
> >> in the places we mean it to be called.
> > 
> > Indeed.  How's this, then?
> 
> Looks good - if you don't mind I'll replace the SVM part of the earlier
> patch with this, add your S-o-b alongside mine, and send again for
> final review.

Sure, that sounds great.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:44:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:44:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxV5-0001M0-PW; Thu, 27 Nov 2014 11:44: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 1XtxV5-0001Lt-8A
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:44:43 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	C9/3C-19763-AAE07745; Thu, 27 Nov 2014 11:44:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417088680!13653001!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17222 invoked from network); 27 Nov 2014 11:44:40 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 11:44:40 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XtxUm-0005OQ-Ak; Thu, 27 Nov 2014 11:44:24 +0000
Date: Thu, 27 Nov 2014 12:44:24 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141127114424.GA13236@deinos.phlegethon.org>
References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com>
	<5474C998020000780004AD1D@mail.emea.novell.com>
	<5474C658.4030901@citrix.com>
	<5476058A02000078000C2808@mail.emea.novell.com>
	<54761124.60203@citrix.com>
	<5476F1F5020000780004B0BC@mail.emea.novell.com>
	<20141127102650.GA13234@deinos.phlegethon.org>
	<54771636020000780004B1DC@mail.emea.novell.com>
	<20141127112936.GB13234@deinos.phlegethon.org>
	<54771B33020000780004B1FF@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54771B33020000780004B1FF@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally
 crash guests on repeated vmentry failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:38 +0000 on 27 Nov (1417084691), Jan Beulich wrote:
> >>> On 27.11.14 at 12:29, <tim@xen.org> wrote:
> > At 11:16 +0000 on 27 Nov (1417083414), Jan Beulich wrote:
> >> >>> On 27.11.14 at 11:26, <tim@xen.org> wrote:
> >> > At 08:42 +0000 on 27 Nov (1417074133), Jan Beulich wrote:
> >> >> >>> On 26.11.14 at 18:43, <andrew.cooper3@citrix.com> wrote:
> >> >> > My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
> >> >> > identify a failed vmentry and lets it fall into the default case of the
> >> >> > vmexit handler.  As such, with v1, the infinite loop still affects AMD
> >> >> > hardware.
> >> >> 
> >> >> Right; I should have said "something along the lines of v1". An SVM
> >> >> part is needed, but that should probably extend beyond what you
> >> >> proposed in v2: There are a number of "goto exit_and_crash"
> >> >> statements ahead of where you place your addition. I think they
> >> >> all need to be treated similarly.
> >> >> 
> >> >> I therefore think we should revert the VMX part of 28b4baacd5
> >> >> and make SVM behavior consistent with what results for VMX:
> >> >> Crash the guest unconditionally on VMEXIT_INVALID, without
> >> >> looking for recurring VM entry failures. See below/attached.
> >> >> 
> >> >> Jan
> >> >> 
> >> >> x86/HVM: prevent infinite VM entry retries
> >> >> 
> >> >> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
> >> >> guest upon problems occurring in user mode") and gets SVM in line with
> >> >> the resulting VMX behavior. This is because Andrew validly says
> >> >> 
> >> >> "A failed vmentry is overwhelmingly likely to be caused by corrupt
> >> >>  VMC[SB] state.  As a result, injecting a fault and retrying the the
> >> >>  vmentry is likely to fail in the same way."
> >> >> 
> >> >> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> > 
> >> > Looking at the SVM side, AFAICT you're trying to filter out
> >> > VMEXIT_INVALID exits that couldn't be handled by nested SVM, but I
> >> > think it's fine just to always crash on nested-SVM failures: we know
> >> > the guest wasn't in user mode because it successfully executed VMRUN.
> >> > And looking at it, the other users of that label are for unexpected
> >> > debugging exits, which can't be caused by the guest userspace either.
> >> > 
> >> > So how about this for the SVM side, reverting to crashing for
> >> > everything except new, unsupported exit types?
> >> 
> >> Generally a good idea, but there are two paths to exit_and_crash
> >> (for VMEXIT_EXCEPTION_DB and VMEXIT_EXCEPTION_BP) which I
> >> think would better crash only conditionally.
> > 
> > Those are catching Xen bugs -- we don't (or at least shouldn't) enable
> > those exit types when the debugger is not attached.  I think that,
> > like with the p2m ENOMEM case, turning them into #UD is not really
> > helpful.  But if you prefer, those could be made into 'goto default'
> > to preserve the current behaviour, which would also retain the
> > debugging output.
> > 
> >> And finally, if doing it that way we might better remove the
> >> exit_and_crash label altogether and call domain_crash() directly
> >> in the places we mean it to be called.
> > 
> > Indeed.  How's this, then?
> 
> Looks good - if you don't mind I'll replace the SVM part of the earlier
> patch with this, add your S-o-b alongside mine, and send again for
> final review.

Sure, that sounds great.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:47:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11: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 1XtxXY-0001Ss-Bk; Thu, 27 Nov 2014 11:47:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtxXW-0001Si-U7
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:47:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1B/EF-25276-24F07745; Thu, 27 Nov 2014 11:47:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417088832!11766223!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14603 invoked from network); 27 Nov 2014 11:47:13 -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;
	27 Nov 2014 11:47:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197409917"
Message-ID: <1417088830.12784.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 27 Nov 2014 11:47:10 +0000
In-Reply-To: <54770D8D.1090107@eu.citrix.com>
References: <54770D8D.1090107@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [COVERITY ACCESS] Request for access to Coverity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 11:39 +0000, George Dunlap wrote:
> I agree to the conditions in the XenProject Coverity contribution
> guidelines [1].
> 
> I'm a developer working for Citrix Systems UK, Ltd.  I've been active
> in the Xen community since 2006; I was release coordinator for the 4.3
> and 4.4 releases, and I am currently maintainer of the Xen scheduling
> subsystem.
> 
> I would like access primarily to be able to write and speak
> intelligently about Xen and Coverity in blog postings and conference
> talks.  I figure it would be easier to go through the stats and
> history myself, rather than trying to get some other developer to do
> it for me.  (Although of course once I have access I'll probably end
> up doing some work looking at scans anyway.)

+1.

> 
> [1] http://xenproject.org/help/contribution-guidelines.html
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:47:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11: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 1XtxXY-0001Ss-Bk; Thu, 27 Nov 2014 11:47:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XtxXW-0001Si-U7
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:47:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1B/EF-25276-24F07745; Thu, 27 Nov 2014 11:47:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417088832!11766223!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14603 invoked from network); 27 Nov 2014 11:47:13 -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;
	27 Nov 2014 11:47:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197409917"
Message-ID: <1417088830.12784.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 27 Nov 2014 11:47:10 +0000
In-Reply-To: <54770D8D.1090107@eu.citrix.com>
References: <54770D8D.1090107@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [COVERITY ACCESS] Request for access to Coverity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 11:39 +0000, George Dunlap wrote:
> I agree to the conditions in the XenProject Coverity contribution
> guidelines [1].
> 
> I'm a developer working for Citrix Systems UK, Ltd.  I've been active
> in the Xen community since 2006; I was release coordinator for the 4.3
> and 4.4 releases, and I am currently maintainer of the Xen scheduling
> subsystem.
> 
> I would like access primarily to be able to write and speak
> intelligently about Xen and Coverity in blog postings and conference
> talks.  I figure it would be easier to go through the stats and
> history myself, rather than trying to get some other developer to do
> it for me.  (Although of course once I have access I'll probably end
> up doing some work looking at scans anyway.)

+1.

> 
> [1] http://xenproject.org/help/contribution-guidelines.html
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:51:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxbV-0001cU-0W; Thu, 27 Nov 2014 11:51:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtxbT-0001cO-Qp
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 11:51:19 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	BC/C6-25547-63017745; Thu, 27 Nov 2014 11:51:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417089077!14097191!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18534 invoked from network); 27 Nov 2014 11:51:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 11:51:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197410719"
Message-ID: <54771033.605@citrix.com>
Date: Thu, 27 Nov 2014 11:51:15 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>		
	<5475DD4F.9060203@suse.com> <5475E311.6070501@citrix.com>	
	<1417081768.11944.70.camel@citrix.com> <54770582.80207@citrix.com>
	<1417087963.12784.11.camel@citrix.com>
In-Reply-To: <1417087963.12784.11.camel@citrix.com>
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/11/14 11:32, Ian Campbell wrote:
> On Thu, 2014-11-27 at 11:05 +0000, Andrew Cooper wrote:
>> On 27/11/14 09:49, Ian Campbell wrote:
>>> On Wed, 2014-11-26 at 14:26 +0000, Andrew Cooper wrote:
>>>> libxc (or some new alternative) should suck it up and gain some notion
>>>> of a stable API or ABI (like the rest of the world appears to be able to
>>>> manage), such that it is possible to compile with an older header and
>>>> use a newer .so at runtime.
>>> Retrofitting a stable API/ABI to the melting pot which is libxc simply
>>> isn't going to work in practice.
>>>
>>> IMO the most likely to succeed approach would be to split off the bits
>>> of libxc which 3rd party's can/should/need to rely on into one of more
>>> libraries, probably by functional area.
>>>
>>> So far I'm aware of plans (or at least desires) to do that for:
>>>
>>>       * Interfaces used by device-models/qemu.
>>>       * The bits which are useful inside a guest (i.e. the
>>>         various /dev/xen/* related helpers).
>>>
>>> So it sounds like libxenkexec should be added to that list.
>>>
>>> Ian.
>>>
>> Agreed.
>>
>> For a domU, I think we need libxenevt, libxengnt and libxenstore with
>> stable API and ABIs.  This in turn will permit libvchan to work without
>> needing libxenctrl.
>>
>> For dom0, each of the libraries is going to need basic hypercall
>> functionality.  It might be worth considering making libxenbasic (name
>> looking for improvement) which is more along the lines of a privcmd
>> driver, providing do_hypercall() and bounce buffering.
>> libxenctrl and
>> others can then avoid reimplementing the wheel many times.
> NB that if such a library contains the h/call wrappers for any
> non-stable hypercall interface (I'm not sure if that was what you were
> suggesting or not) then it would itself remain ABI/API unstable.

I was suggesting do_hypercall() and specifically not things like
do_domctl().  do_hypercall() is a think wrapper around ioctl(), which
will be stable going forwards.  This allows a consumer to use stable
hypercalls and keep stability.

libxenctrl/libxenguest can implement do_domctl() in terms of
do_hypercall(), and gain the inherent instability that comes with this.

However, I think all of these are design decisions to be considered by
whomever tackles this chunk of work :)

>
> But anyway there's nothing stopping libxen* using interfaces exposed by
> an unstable libxenctrl or libxenbasic and remaining interface stable
> themselves, so you can avoid reimplementing the wheel that way.

libxenctrl, being an explicit unstable API and ABI cannot reasonably be
used by something claiming to provide a stable ABI, without libxenctrl
changing its stance on what is considered stable and what is not.  I
suppose the advantage of this is that it can be sorted with some paperwork.

>
> Those libraries just need to do the impedance matching and link the
> correct SONAME for the unstable library, the linker will take care of
> the rest.
>
> I don't think it is going to be realistic in practice to support keeping
> the exact same libxenfoo.so.N binary working across multiple releases,
> but rather each release will provide its own libxenfoo.so.N with the
> same N and supporting the same ABI, such that it can just be swapped in
> under the feet of the application.

I believe that this covers our intentions, and appears to be the common
way of doing things.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:51:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxbV-0001cU-0W; Thu, 27 Nov 2014 11:51:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtxbT-0001cO-Qp
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 11:51:19 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	BC/C6-25547-63017745; Thu, 27 Nov 2014 11:51:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417089077!14097191!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18534 invoked from network); 27 Nov 2014 11:51:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 11:51:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197410719"
Message-ID: <54771033.605@citrix.com>
Date: Thu, 27 Nov 2014 11:51:15 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com>		
	<5475DD4F.9060203@suse.com> <5475E311.6070501@citrix.com>	
	<1417081768.11944.70.camel@citrix.com> <54770582.80207@citrix.com>
	<1417087963.12784.11.camel@citrix.com>
In-Reply-To: <1417087963.12784.11.camel@citrix.com>
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kdump with xen-unstable on efi machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/11/14 11:32, Ian Campbell wrote:
> On Thu, 2014-11-27 at 11:05 +0000, Andrew Cooper wrote:
>> On 27/11/14 09:49, Ian Campbell wrote:
>>> On Wed, 2014-11-26 at 14:26 +0000, Andrew Cooper wrote:
>>>> libxc (or some new alternative) should suck it up and gain some notion
>>>> of a stable API or ABI (like the rest of the world appears to be able to
>>>> manage), such that it is possible to compile with an older header and
>>>> use a newer .so at runtime.
>>> Retrofitting a stable API/ABI to the melting pot which is libxc simply
>>> isn't going to work in practice.
>>>
>>> IMO the most likely to succeed approach would be to split off the bits
>>> of libxc which 3rd party's can/should/need to rely on into one of more
>>> libraries, probably by functional area.
>>>
>>> So far I'm aware of plans (or at least desires) to do that for:
>>>
>>>       * Interfaces used by device-models/qemu.
>>>       * The bits which are useful inside a guest (i.e. the
>>>         various /dev/xen/* related helpers).
>>>
>>> So it sounds like libxenkexec should be added to that list.
>>>
>>> Ian.
>>>
>> Agreed.
>>
>> For a domU, I think we need libxenevt, libxengnt and libxenstore with
>> stable API and ABIs.  This in turn will permit libvchan to work without
>> needing libxenctrl.
>>
>> For dom0, each of the libraries is going to need basic hypercall
>> functionality.  It might be worth considering making libxenbasic (name
>> looking for improvement) which is more along the lines of a privcmd
>> driver, providing do_hypercall() and bounce buffering.
>> libxenctrl and
>> others can then avoid reimplementing the wheel many times.
> NB that if such a library contains the h/call wrappers for any
> non-stable hypercall interface (I'm not sure if that was what you were
> suggesting or not) then it would itself remain ABI/API unstable.

I was suggesting do_hypercall() and specifically not things like
do_domctl().  do_hypercall() is a think wrapper around ioctl(), which
will be stable going forwards.  This allows a consumer to use stable
hypercalls and keep stability.

libxenctrl/libxenguest can implement do_domctl() in terms of
do_hypercall(), and gain the inherent instability that comes with this.

However, I think all of these are design decisions to be considered by
whomever tackles this chunk of work :)

>
> But anyway there's nothing stopping libxen* using interfaces exposed by
> an unstable libxenctrl or libxenbasic and remaining interface stable
> themselves, so you can avoid reimplementing the wheel that way.

libxenctrl, being an explicit unstable API and ABI cannot reasonably be
used by something claiming to provide a stable ABI, without libxenctrl
changing its stance on what is considered stable and what is not.  I
suppose the advantage of this is that it can be sorted with some paperwork.

>
> Those libraries just need to do the impedance matching and link the
> correct SONAME for the unstable library, the linker will take care of
> the rest.
>
> I don't think it is going to be realistic in practice to support keeping
> the exact same libxenfoo.so.N binary working across multiple releases,
> but rather each release will provide its own libxenfoo.so.N with the
> same N and supporting the same ABI, such that it can just be swapped in
> under the feet of the application.

I believe that this covers our intentions, and appears to be the common
way of doing things.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:53:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:53:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtxda-0001t2-Gs; Thu, 27 Nov 2014 11:53:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtxdY-0001sx-FS
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:53:28 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	39/1A-27584-7B017745; Thu, 27 Nov 2014 11:53:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417089205!13680081!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12387 invoked from network); 27 Nov 2014 11:53:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 11:53:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197411183"
Message-ID: <547710B4.3090600@citrix.com>
Date: Thu, 27 Nov 2014 11:53:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <54770D8D.1090107@eu.citrix.com>
In-Reply-To: <54770D8D.1090107@eu.citrix.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [COVERITY ACCESS] Request for access to Coverity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 11:39, George Dunlap wrote:
> I agree to the conditions in the XenProject Coverity contribution
> guidelines [1].
>
> I'm a developer working for Citrix Systems UK, Ltd.  I've been active
> in the Xen community since 2006; I was release coordinator for the 4.3
> and 4.4 releases, and I am currently maintainer of the Xen scheduling
> subsystem.
>
> I would like access primarily to be able to write and speak
> intelligently about Xen and Coverity in blog postings and conference
> talks.  I figure it would be easier to go through the stats and
> history myself, rather than trying to get some other developer to do
> it for me.  (Although of course once I have access I'll probably end
> up doing some work looking at scans anyway.)
>
> [1] http://xenproject.org/help/contribution-guidelines.html

+1

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:53:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:53:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtxda-0001t2-Gs; Thu, 27 Nov 2014 11:53:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtxdY-0001sx-FS
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:53:28 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	39/1A-27584-7B017745; Thu, 27 Nov 2014 11:53:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417089205!13680081!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12387 invoked from network); 27 Nov 2014 11:53:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 11:53:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197411183"
Message-ID: <547710B4.3090600@citrix.com>
Date: Thu, 27 Nov 2014 11:53:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <54770D8D.1090107@eu.citrix.com>
In-Reply-To: <54770D8D.1090107@eu.citrix.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [COVERITY ACCESS] Request for access to Coverity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 11:39, George Dunlap wrote:
> I agree to the conditions in the XenProject Coverity contribution
> guidelines [1].
>
> I'm a developer working for Citrix Systems UK, Ltd.  I've been active
> in the Xen community since 2006; I was release coordinator for the 4.3
> and 4.4 releases, and I am currently maintainer of the Xen scheduling
> subsystem.
>
> I would like access primarily to be able to write and speak
> intelligently about Xen and Coverity in blog postings and conference
> talks.  I figure it would be easier to go through the stats and
> history myself, rather than trying to get some other developer to do
> it for me.  (Although of course once I have access I'll probably end
> up doing some work looking at scans anyway.)
>
> [1] http://xenproject.org/help/contribution-guidelines.html

+1

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:59:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:59:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxjB-00023M-9H; Thu, 27 Nov 2014 11:59:17 +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 1XtxjA-00023H-NT
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:59:16 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	BC/48-22737-41217745; Thu, 27 Nov 2014 11:59:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417089555!13660949!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6811 invoked from network); 27 Nov 2014 11:59:15 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 11:59:15 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xtxiu-0005bn-Dm; Thu, 27 Nov 2014 11:59:00 +0000
Date: Thu, 27 Nov 2014 12:59:00 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141127115900.GB13236@deinos.phlegethon.org>
References: <54770D8D.1090107@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54770D8D.1090107@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [COVERITY ACCESS] Request for access to Coverity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:39 +0000 on 27 Nov (1417084797), George Dunlap wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> I agree to the conditions in the XenProject Coverity contribution
> guidelines [1].
> 
> I'm a developer working for Citrix Systems UK, Ltd.  I've been active
> in the Xen community since 2006; I was release coordinator for the 4.3
> and 4.4 releases, and I am currently maintainer of the Xen scheduling
> subsystem.
> 
> I would like access primarily to be able to write and speak
> intelligently about Xen and Coverity in blog postings and conference
> talks.  I figure it would be easier to go through the stats and
> history myself, rather than trying to get some other developer to do
> it for me.  (Although of course once I have access I'll probably end
> up doing some work looking at scans anyway.)

+1

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 11:59:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 11:59:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxjB-00023M-9H; Thu, 27 Nov 2014 11:59:17 +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 1XtxjA-00023H-NT
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 11:59:16 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	BC/48-22737-41217745; Thu, 27 Nov 2014 11:59:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417089555!13660949!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6811 invoked from network); 27 Nov 2014 11:59:15 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 11:59:15 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xtxiu-0005bn-Dm; Thu, 27 Nov 2014 11:59:00 +0000
Date: Thu, 27 Nov 2014 12:59:00 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141127115900.GB13236@deinos.phlegethon.org>
References: <54770D8D.1090107@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54770D8D.1090107@eu.citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [COVERITY ACCESS] Request for access to Coverity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:39 +0000 on 27 Nov (1417084797), George Dunlap wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> I agree to the conditions in the XenProject Coverity contribution
> guidelines [1].
> 
> I'm a developer working for Citrix Systems UK, Ltd.  I've been active
> in the Xen community since 2006; I was release coordinator for the 4.3
> and 4.4 releases, and I am currently maintainer of the Xen scheduling
> subsystem.
> 
> I would like access primarily to be able to write and speak
> intelligently about Xen and Coverity in blog postings and conference
> talks.  I figure it would be easier to go through the stats and
> history myself, rather than trying to get some other developer to do
> it for me.  (Although of course once I have access I'll probably end
> up doing some work looking at scans anyway.)

+1

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:06:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxqI-0002Ws-Hd; Thu, 27 Nov 2014 12:06:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XtxqG-0002WR-DF; Thu, 27 Nov 2014 12:06:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	86/CE-09842-BC317745; Thu, 27 Nov 2014 12:06:35 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417089993!11772121!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4188 invoked from network); 27 Nov 2014 12:06:34 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Nov 2014 12:06:34 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xtxq3-0003UD-Jb; Thu, 27 Nov 2014 12:06:23 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xtxq3-0008Rw-1V; Thu, 27 Nov 2014 12:06:23 +0000
Date: Thu, 27 Nov 2014 12:06:23 +0000
Message-Id: <E1Xtxq3-0008Rw-1V@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 111 (CVE-2014-8866) - Excessive
 checking in compatibility mode hypercall argument translation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2014-8866 / XSA-111
                              version 3

   Excessive checking in compatibility mode hypercall argument translation

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

The hypercall argument translation needed for 32-bit guests running on
64-bit hypervisors performs checks on the final register state.  These
checks cover all registers potentially holding hypercall arguments,
not just the ones actually doing so for the hypercall being processed,
since the code was originally intended for use only by PV guests.

While this is not a problem for PV guests (as they can't enter 64-bit
mode and hence can't alter the high halves of any of the registers),
the subsequent reuse of the same functionality for HVM guests exposed
those checks to values (specifically, unexpected values for the high
halves of registers not holding hypercall arguments) controlled by
guest software.

IMPACT
======

A buggy or malicious HVM guest can crash the host.

VULNERABLE SYSTEMS
==================

Xen 3.3 and onward are vulnerable.

Only x86 systems are vulnerable.  ARM systems are not vulnerable.

MITIGATION
==========

Running only PV guests will avoid this issue.

There is no mitigation available for HVM guests on any version of Xen
so far released by xenproject.org.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa111-unstable.patch        xen-unstable, Xen 4.4.x
xsa111-4.3.patch             Xen 4.3.x
xsa111-4.2.patch             Xen 4.2.x

$ sha256sum xsa111*.patch
f6e1bf166ebed6235802e4e42853430d2f5b456c1837908a4f7ed6d4d150e4b4  xsa111-4.2.patch
e9b03a4443a40142cc5c21848dc9589770620dde8924344c4a00028c4dace9f2  xsa111-4.3.patch
3c418f065cd452c225af34c3cccf9bdbc37efb6c6a5fc5940fd83ad8620510d3  xsa111.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUdwoTAAoJEIP+FMlX6CvZ/jIH/01d45vOe9bUokjixu+sv93n
FPxm2XC9IZEAuDU4h4RXAkzI0L4vuCAnJq0Rr3quizukQ/oqtPPdbYGC/VgQ15LU
0XE3J2U8BbwsweEDIADinJZ76UvvIWtT4/llQT2WCI/g7nRiW7lZAUkhR9nXL2gg
pw48QIdBkgEGZO7JlWEmrA60OwFcAAdG66/IWNjWbUPrscr/DLG0gimrqqAtG9lY
jTpDrOgC+xARbES9iRBt0IU4duMUiCjwy+y8jeq/Ka5d6QIrcaeTO9Y3d6jf2CCE
Z7TC22OGO4XMg6j+abceao3geS29ezsDQttSh7rGjwqMaNqJbIiitKIq4svAtS4=
=Gtqx
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa111-4.2.patch"
Content-Disposition: attachment; filename="xsa111-4.2.patch"
Content-Transfer-Encoding: base64

eDg2OiBsaW1pdCBjaGVja3MgaW4gaHlwZXJjYWxsX3hsYXRfY29udGludWF0
aW9uKCkgdG8gYWN0dWFsIGFyZ3VtZW50cwoKSFZNL1BWSCBndWVzdHMgY2Fu
IG90aGVyd2lzZSB0cmlnZ2VyIHRoZSBmaW5hbCBCVUdfT04oKSBpbiB0aGF0
CmZ1bmN0aW9uIGJ5IGVudGVyaW5nIDY0LWJpdCBtb2RlLCBzZXR0aW5nIHRo
ZSBoaWdoIGhhbHZlcyBvZiBhZmZlY3RlZApyZWdpc3RlcnMgdG8gbm9uLXpl
cm8gdmFsdWVzLCBsZWF2aW5nIDY0LWJpdCBtb2RlLCBhbmQgaXNzdWluZyBh
Cmh5cGVyY2FsbCB0aGF0IG1pZ2h0IGdldCBwcmVlbXB0ZWQgYW5kIGhlbmNl
IGJlY29tZSBzdWJqZWN0IHRvCmNvbnRpbnVhdGlvbiBhcmd1bWVudCB0cmFu
c2xhdGlvbiAoSFlQRVJWSVNPUl9tZW1vcnlfb3AgYmVpbmcgdGhlIG9ubHkK
b25lIHBvc3NpYmxlIGZvciBIVk0sIFBWSCBhbHNvIGhhdmluZyB0aGUgb3B0
aW9uIG9mIHVzaW5nCkhZUEVSVklTT1JfbW11ZXh0X29wKS4gVGhpcyBpc3N1
ZSBnb3QgaW50cm9kdWNlZCB3aGVuIEhWTSBjb2RlIHdhcwpzd2l0Y2hlZCB0
byB1c2UgY29tcGF0X21lbW9yeV9vcCgpIC0gbmVpdGhlciB0aGF0IG5vcgpo
eXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24oKSB3ZXJlIG9yaWdpbmFsbHkg
aW50ZW5kZWQgdG8gYmUgdXNlZCBieQpvdGhlciB0aGFuIFBWIGd1ZXN0cyAo
d2hpY2ggY2FuJ3QgZW50ZXIgNjQtYml0IG1vZGUgYW5kIGhlbmNlIGhhdmUg
bm8Kd2F5IHRvIGFsdGVyIHRoZSBoaWdoIGhhbHZlcyBvZiA2NC1iaXQgcmVn
aXN0ZXJzKS4KClRoaXMgaXMgWFNBLTExMS4KClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2aWV3ZWQtYnk6IFRp
bSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoKLS0tIGEveGVuL2FyY2gveDg2L2Rv
bWFpbi5jCisrKyBiL3hlbi9hcmNoL3g4Ni9kb21haW4uYwpAQCAtMTkyMSw3
ICsxOTIxLDggQEAgdW5zaWduZWQgbG9uZyBoeXBlcmNhbGxfY3JlYXRlX2Nv
bnRpbnVhdAogfQogCiAjaWZkZWYgQ09ORklHX0NPTVBBVAotaW50IGh5cGVy
Y2FsbF94bGF0X2NvbnRpbnVhdGlvbih1bnNpZ25lZCBpbnQgKmlkLCB1bnNp
Z25lZCBpbnQgbWFzaywgLi4uKQoraW50IGh5cGVyY2FsbF94bGF0X2NvbnRp
bnVhdGlvbih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBpbnQgbnIsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCBt
YXNrLCAuLi4pCiB7CiAgICAgaW50IHJjID0gMDsKICAgICBzdHJ1Y3QgbWNf
c3RhdGUgKm1jcyA9ICZjdXJyZW50LT5tY19zdGF0ZTsKQEAgLTE5MzAsNyAr
MTkzMSwxMCBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVu
c2lnbmVkCiAgICAgdW5zaWduZWQgbG9uZyBudmFsID0gMDsKICAgICB2YV9s
aXN0IGFyZ3M7CiAKLSAgICBCVUdfT04oaWQgJiYgKmlkID4gNSk7CisgICAg
QVNTRVJUKG5yIDw9IEFSUkFZX1NJWkUobWNzLT5jYWxsLmFyZ3MpKTsKKyAg
ICBBU1NFUlQoIShtYXNrID4+IG5yKSk7CisKKyAgICBCVUdfT04oaWQgJiYg
KmlkID49IG5yKTsKICAgICBCVUdfT04oaWQgJiYgKG1hc2sgJiAoMVUgPDwg
KmlkKSkpOwogCiAgICAgdmFfc3RhcnQoYXJncywgbWFzayk7CkBAIC0xOTM5
LDcgKzE5NDMsNyBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9u
KHVuc2lnbmVkCiAgICAgewogICAgICAgICBpZiAoICF0ZXN0X2JpdChfTUNT
Rl9jYWxsX3ByZWVtcHRlZCwgJm1jcy0+ZmxhZ3MpICkKICAgICAgICAgICAg
IHJldHVybiAwOwotICAgICAgICBmb3IgKCBpID0gMDsgaSA8IDY7ICsraSwg
bWFzayA+Pj0gMSApCisgICAgICAgIGZvciAoIGkgPSAwOyBpIDwgbnI7ICsr
aSwgbWFzayA+Pj0gMSApCiAgICAgICAgIHsKICAgICAgICAgICAgIGlmICgg
bWFzayAmIDEgKQogICAgICAgICAgICAgewpAQCAtMTk2Nyw3ICsxOTcxLDcg
QEAgaW50IGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlvbih1bnNpZ25lZAog
ICAgIGVsc2UKICAgICB7CiAgICAgICAgIHJlZ3MgPSBndWVzdF9jcHVfdXNl
cl9yZWdzKCk7Ci0gICAgICAgIGZvciAoIGkgPSAwOyBpIDwgNjsgKytpLCBt
YXNrID4+PSAxICkKKyAgICAgICAgZm9yICggaSA9IDA7IGkgPCBucjsgKytp
LCBtYXNrID4+PSAxICkKICAgICAgICAgewogICAgICAgICAgICAgdW5zaWdu
ZWQgbG9uZyAqcmVnOwogCi0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvY29t
cGF0L21tLmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvbW0u
YwpAQCAtNzgsNyArNzgsNyBAQCBpbnQgY29tcGF0X2FyY2hfbWVtb3J5X29w
KGludCBvcCwgWEVOX0dVCiAgICAgICAgIH0KIAogICAgICAgICBpZiAoIHJj
ID09IF9fSFlQRVJWSVNPUl9tZW1vcnlfb3AgKQotICAgICAgICAgICAgaHlw
ZXJjYWxsX3hsYXRfY29udGludWF0aW9uKE5VTEwsIDB4MiwgbmF0LCBhcmcp
OworICAgICAgICAgICAgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKE5V
TEwsIDIsIDB4MiwgbmF0LCBhcmcpOwogCiAgICAgICAgIGJyZWFrOwogICAg
IH0KQEAgLTE0NCw3ICsxNDQsNyBAQCBpbnQgY29tcGF0X2FyY2hfbWVtb3J5
X29wKGludCBvcCwgWEVOX0dVCiAgICAgICAgICAgICBicmVhazsKIAogICAg
ICAgICBpZiAoIHJjID09IF9fSFlQRVJWSVNPUl9tZW1vcnlfb3AgKQotICAg
ICAgICAgICAgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKE5VTEwsIDB4
MiwgbmF0LCBhcmcpOworICAgICAgICAgICAgaHlwZXJjYWxsX3hsYXRfY29u
dGludWF0aW9uKE5VTEwsIDIsIDB4MiwgbmF0LCBhcmcpOwogCiAgICAgICAg
IFhMQVRfcG9kX3RhcmdldCgmY21wLCBuYXQpOwogCkBAIC0zNzksNyArMzc5
LDcgQEAgaW50IGNvbXBhdF9tbXVleHRfb3AoWEVOX0dVRVNUX0hBTkRMRSht
bQogICAgICAgICAgICAgICAgIGxlZnQgPSAxOwogICAgICAgICAgICAgICAg
IGlmICggYXJnMSAhPSBNTVVfVVBEQVRFX1BSRUVNUFRFRCApCiAgICAgICAg
ICAgICAgICAgewotICAgICAgICAgICAgICAgICAgICBCVUdfT04oIWh5cGVy
Y2FsbF94bGF0X2NvbnRpbnVhdGlvbigmbGVmdCwgMHgwMSwgbmF0X29wcywK
KyAgICAgICAgICAgICAgICAgICAgQlVHX09OKCFoeXBlcmNhbGxfeGxhdF9j
b250aW51YXRpb24oJmxlZnQsIDQsIDB4MDEsIG5hdF9vcHMsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNtcF91b3BzKSk7CiAgICAgICAgICAgICAgICAgICAgIGlmICggIXRl
c3RfYml0KF9NQ1NGX2luX211bHRpY2FsbCwgJm1jcy0+ZmxhZ3MpICkKICAg
ICAgICAgICAgICAgICAgICAgICAgIHJlZ3MtPl9lY3ggKz0gY291bnQgLSBp
OwpAQCAtMzg3LDcgKzM4Nyw3IEBAIGludCBjb21wYXRfbW11ZXh0X29wKFhF
Tl9HVUVTVF9IQU5ETEUobW0KICAgICAgICAgICAgICAgICAgICAgICAgIG1j
cy0+Y29tcGF0X2NhbGwuYXJnc1sxXSArPSBjb3VudCAtIGk7CiAgICAgICAg
ICAgICAgICAgfQogICAgICAgICAgICAgICAgIGVsc2UKLSAgICAgICAgICAg
ICAgICAgICAgQlVHX09OKGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlvbigm
bGVmdCwgMCkpOworICAgICAgICAgICAgICAgICAgICBCVUdfT04oaHlwZXJj
YWxsX3hsYXRfY29udGludWF0aW9uKCZsZWZ0LCA0LCAwKSk7CiAgICAgICAg
ICAgICAgICAgQlVHX09OKGxlZnQgIT0gYXJnMSk7CiAgICAgICAgICAgICB9
CiAgICAgICAgICAgICBlbHNlCi0tLSBhL3hlbi9jb21tb24vY29tcGF0L21l
bW9yeS5jCisrKyBiL3hlbi9jb21tb24vY29tcGF0L21lbW9yeS5jCkBAIC0y
MDgsNyArMjA4LDcgQEAgaW50IGNvbXBhdF9tZW1vcnlfb3AodW5zaWduZWQg
aW50IGNtZCwgWAogICAgICAgICAgICAgYnJlYWs7CiAKICAgICAgICAgY21k
ID0gMDsKLSAgICAgICAgaWYgKCBoeXBlcmNhbGxfeGxhdF9jb250aW51YXRp
b24oJmNtZCwgMHgwMiwgbmF0LmhuZCwgY29tcGF0KSApCisgICAgICAgIGlm
ICggaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKCZjbWQsIDIsIDB4MDIs
IG5hdC5obmQsIGNvbXBhdCkgKQogICAgICAgICB7CiAgICAgICAgICAgICBC
VUdfT04ocmMgIT0gX19IWVBFUlZJU09SX21lbW9yeV9vcCk7CiAgICAgICAg
ICAgICBCVUdfT04oKGNtZCAmIE1FTU9QX0NNRF9NQVNLKSAhPSBvcCk7Ci0t
LSBhL3hlbi9pbmNsdWRlL3hlbi9jb21wYXQuaAorKysgYi94ZW4vaW5jbHVk
ZS94ZW4vY29tcGF0LmgKQEAgLTE5Miw2ICsxOTIsOCBAQCBzdGF0aWMgaW5s
aW5lIGludCBuYW1lKGsgeGVuXyAjIyBuICp4LCBrCiAgKiBUaGlzIG9wdGlv
biBpcyB1c2VmdWwgZm9yIGV4dHJhY3RpbmcgdGhlICJvcCIgYXJndW1lbnQg
b3Igc2ltaWxhciBmcm9tIHRoZQogICogaHlwZXJjYWxsIHRvIGVuYWJsZSBm
dXJ0aGVyIHhsYXQgcHJvY2Vzc2luZy4KICAqCisgKiBucjogVG90YWwgbnVt
YmVyIG9mIGFyZ3VtZW50cyB0aGUgaHlwZXJjYWxsIGhhcy4KKyAqCiAgKiBt
YXNrOiBTcGVjaWZpZXMgd2hpY2ggb2YgdGhlIGh5cGVyY2FsbCBhcmd1bWVu
dHMgcmVxdWlyZSBjb21wYXQgdHJhbnNsYXRpb24uCiAgKiBiaXQgMCBpbmRp
Y2F0ZXMgdGhhdCB0aGUgMCd0aCBhcmd1bWVudCByZXF1aXJlcyB0cmFuc2xh
dGlvbiwgYml0IDEgaW5kaWNhdGVzCiAgKiB0aGF0IHRoZSBmaXJzdCBhcmd1
bWVudCByZXF1aXJlcyB0cmFuc2xhdGlvbiBhbmQgc28gb24uIE5hdGl2ZSBh
bmQgY29tcGF0CkBAIC0yMTEsNyArMjEzLDggQEAgc3RhdGljIGlubGluZSBp
bnQgbmFtZShrIHhlbl8gIyMgbiAqeCwgawogICoKICAqIFJldHVybjogTnVt
YmVyIG9mIGFyZ3VtZW50cyB3aGljaCB3ZXJlIGFjdHVhbGx5IHRyYW5zbGF0
ZWQuCiAgKi8KLWludCBoeXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24odW5z
aWduZWQgaW50ICppZCwgdW5zaWduZWQgaW50IG1hc2ssIC4uLik7CitpbnQg
aHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVkIGludCAqaWQs
IHVuc2lnbmVkIGludCBuciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdW5zaWduZWQgaW50IG1hc2ssIC4uLik7CiAKIC8qIEluLXBsYWNl
IHRyYW5zbGF0aW9uIGZ1bmN0b25zOiAqLwogc3RydWN0IHN0YXJ0X2luZm87
Cg==

--=separator
Content-Type: application/octet-stream; name="xsa111-4.3.patch"
Content-Disposition: attachment; filename="xsa111-4.3.patch"
Content-Transfer-Encoding: base64

eDg2OiBsaW1pdCBjaGVja3MgaW4gaHlwZXJjYWxsX3hsYXRfY29udGludWF0
aW9uKCkgdG8gYWN0dWFsIGFyZ3VtZW50cwoKSFZNL1BWSCBndWVzdHMgY2Fu
IG90aGVyd2lzZSB0cmlnZ2VyIHRoZSBmaW5hbCBCVUdfT04oKSBpbiB0aGF0
CmZ1bmN0aW9uIGJ5IGVudGVyaW5nIDY0LWJpdCBtb2RlLCBzZXR0aW5nIHRo
ZSBoaWdoIGhhbHZlcyBvZiBhZmZlY3RlZApyZWdpc3RlcnMgdG8gbm9uLXpl
cm8gdmFsdWVzLCBsZWF2aW5nIDY0LWJpdCBtb2RlLCBhbmQgaXNzdWluZyBh
Cmh5cGVyY2FsbCB0aGF0IG1pZ2h0IGdldCBwcmVlbXB0ZWQgYW5kIGhlbmNl
IGJlY29tZSBzdWJqZWN0IHRvCmNvbnRpbnVhdGlvbiBhcmd1bWVudCB0cmFu
c2xhdGlvbiAoSFlQRVJWSVNPUl9tZW1vcnlfb3AgYmVpbmcgdGhlIG9ubHkK
b25lIHBvc3NpYmxlIGZvciBIVk0sIFBWSCBhbHNvIGhhdmluZyB0aGUgb3B0
aW9uIG9mIHVzaW5nCkhZUEVSVklTT1JfbW11ZXh0X29wKS4gVGhpcyBpc3N1
ZSBnb3QgaW50cm9kdWNlZCB3aGVuIEhWTSBjb2RlIHdhcwpzd2l0Y2hlZCB0
byB1c2UgY29tcGF0X21lbW9yeV9vcCgpIC0gbmVpdGhlciB0aGF0IG5vcgpo
eXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24oKSB3ZXJlIG9yaWdpbmFsbHkg
aW50ZW5kZWQgdG8gYmUgdXNlZCBieQpvdGhlciB0aGFuIFBWIGd1ZXN0cyAo
d2hpY2ggY2FuJ3QgZW50ZXIgNjQtYml0IG1vZGUgYW5kIGhlbmNlIGhhdmUg
bm8Kd2F5IHRvIGFsdGVyIHRoZSBoaWdoIGhhbHZlcyBvZiA2NC1iaXQgcmVn
aXN0ZXJzKS4KClRoaXMgaXMgWFNBLTExMS4KClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2aWV3ZWQtYnk6IFRp
bSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoKLS0tIGEveGVuL2FyY2gveDg2L2Rv
bWFpbi5jCisrKyBiL3hlbi9hcmNoL3g4Ni9kb21haW4uYwpAQCAtMTY1Myw3
ICsxNjUzLDggQEAgdW5zaWduZWQgbG9uZyBoeXBlcmNhbGxfY3JlYXRlX2Nv
bnRpbnVhdAogICAgIHJldHVybiBvcDsKIH0KIAotaW50IGh5cGVyY2FsbF94
bGF0X2NvbnRpbnVhdGlvbih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBp
bnQgbWFzaywgLi4uKQoraW50IGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlv
bih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBpbnQgbnIsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCBtYXNrLCAu
Li4pCiB7CiAgICAgaW50IHJjID0gMDsKICAgICBzdHJ1Y3QgbWNfc3RhdGUg
Km1jcyA9ICZjdXJyZW50LT5tY19zdGF0ZTsKQEAgLTE2NjIsNyArMTY2Mywx
MCBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVk
CiAgICAgdW5zaWduZWQgbG9uZyBudmFsID0gMDsKICAgICB2YV9saXN0IGFy
Z3M7CiAKLSAgICBCVUdfT04oaWQgJiYgKmlkID4gNSk7CisgICAgQVNTRVJU
KG5yIDw9IEFSUkFZX1NJWkUobWNzLT5jYWxsLmFyZ3MpKTsKKyAgICBBU1NF
UlQoIShtYXNrID4+IG5yKSk7CisKKyAgICBCVUdfT04oaWQgJiYgKmlkID49
IG5yKTsKICAgICBCVUdfT04oaWQgJiYgKG1hc2sgJiAoMVUgPDwgKmlkKSkp
OwogCiAgICAgdmFfc3RhcnQoYXJncywgbWFzayk7CkBAIC0xNjcxLDcgKzE2
NzUsNyBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2ln
bmVkCiAgICAgewogICAgICAgICBpZiAoICF0ZXN0X2JpdChfTUNTRl9jYWxs
X3ByZWVtcHRlZCwgJm1jcy0+ZmxhZ3MpICkKICAgICAgICAgICAgIHJldHVy
biAwOwotICAgICAgICBmb3IgKCBpID0gMDsgaSA8IDY7ICsraSwgbWFzayA+
Pj0gMSApCisgICAgICAgIGZvciAoIGkgPSAwOyBpIDwgbnI7ICsraSwgbWFz
ayA+Pj0gMSApCiAgICAgICAgIHsKICAgICAgICAgICAgIGlmICggbWFzayAm
IDEgKQogICAgICAgICAgICAgewpAQCAtMTY5OSw3ICsxNzAzLDcgQEAgaW50
IGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlvbih1bnNpZ25lZAogICAgIGVs
c2UKICAgICB7CiAgICAgICAgIHJlZ3MgPSBndWVzdF9jcHVfdXNlcl9yZWdz
KCk7Ci0gICAgICAgIGZvciAoIGkgPSAwOyBpIDwgNjsgKytpLCBtYXNrID4+
PSAxICkKKyAgICAgICAgZm9yICggaSA9IDA7IGkgPCBucjsgKytpLCBtYXNr
ID4+PSAxICkKICAgICAgICAgewogICAgICAgICAgICAgdW5zaWduZWQgbG9u
ZyAqcmVnOwogCi0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L21t
LmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvbW0uYwpAQCAt
NzgsNyArNzgsNyBAQCBpbnQgY29tcGF0X2FyY2hfbWVtb3J5X29wKGludCBv
cCwgWEVOX0dVCiAgICAgICAgIH0KIAogICAgICAgICBpZiAoIHJjID09IF9f
SFlQRVJWSVNPUl9tZW1vcnlfb3AgKQotICAgICAgICAgICAgaHlwZXJjYWxs
X3hsYXRfY29udGludWF0aW9uKE5VTEwsIDB4MiwgbmF0LCBhcmcpOworICAg
ICAgICAgICAgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKE5VTEwsIDIs
IDB4MiwgbmF0LCBhcmcpOwogCiAgICAgICAgIGJyZWFrOwogICAgIH0KQEAg
LTE0NCw3ICsxNDQsNyBAQCBpbnQgY29tcGF0X2FyY2hfbWVtb3J5X29wKGlu
dCBvcCwgWEVOX0dVCiAgICAgICAgICAgICBicmVhazsKIAogICAgICAgICBp
ZiAoIHJjID09IF9fSFlQRVJWSVNPUl9tZW1vcnlfb3AgKQotICAgICAgICAg
ICAgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKE5VTEwsIDB4MiwgbmF0
LCBhcmcpOworICAgICAgICAgICAgaHlwZXJjYWxsX3hsYXRfY29udGludWF0
aW9uKE5VTEwsIDIsIDB4MiwgbmF0LCBhcmcpOwogCiAgICAgICAgIFhMQVRf
cG9kX3RhcmdldCgmY21wLCBuYXQpOwogCkBAIC0zNzksNyArMzc5LDcgQEAg
aW50IGNvbXBhdF9tbXVleHRfb3AoWEVOX0dVRVNUX0hBTkRMRV9QQQogICAg
ICAgICAgICAgICAgIGxlZnQgPSAxOwogICAgICAgICAgICAgICAgIGlmICgg
YXJnMSAhPSBNTVVfVVBEQVRFX1BSRUVNUFRFRCApCiAgICAgICAgICAgICAg
ICAgewotICAgICAgICAgICAgICAgICAgICBCVUdfT04oIWh5cGVyY2FsbF94
bGF0X2NvbnRpbnVhdGlvbigmbGVmdCwgMHgwMSwgbmF0X29wcywKKyAgICAg
ICAgICAgICAgICAgICAgQlVHX09OKCFoeXBlcmNhbGxfeGxhdF9jb250aW51
YXRpb24oJmxlZnQsIDQsIDB4MDEsIG5hdF9vcHMsCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNt
cF91b3BzKSk7CiAgICAgICAgICAgICAgICAgICAgIGlmICggIXRlc3RfYml0
KF9NQ1NGX2luX211bHRpY2FsbCwgJm1jcy0+ZmxhZ3MpICkKICAgICAgICAg
ICAgICAgICAgICAgICAgIHJlZ3MtPl9lY3ggKz0gY291bnQgLSBpOwpAQCAt
Mzg3LDcgKzM4Nyw3IEBAIGludCBjb21wYXRfbW11ZXh0X29wKFhFTl9HVUVT
VF9IQU5ETEVfUEEKICAgICAgICAgICAgICAgICAgICAgICAgIG1jcy0+Y29t
cGF0X2NhbGwuYXJnc1sxXSArPSBjb3VudCAtIGk7CiAgICAgICAgICAgICAg
ICAgfQogICAgICAgICAgICAgICAgIGVsc2UKLSAgICAgICAgICAgICAgICAg
ICAgQlVHX09OKGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlvbigmbGVmdCwg
MCkpOworICAgICAgICAgICAgICAgICAgICBCVUdfT04oaHlwZXJjYWxsX3hs
YXRfY29udGludWF0aW9uKCZsZWZ0LCA0LCAwKSk7CiAgICAgICAgICAgICAg
ICAgQlVHX09OKGxlZnQgIT0gYXJnMSk7CiAgICAgICAgICAgICB9CiAgICAg
ICAgICAgICBlbHNlCi0tLSBhL3hlbi9jb21tb24vY29tcGF0L21lbW9yeS5j
CisrKyBiL3hlbi9jb21tb24vY29tcGF0L21lbW9yeS5jCkBAIC0yMDgsNyAr
MjA4LDcgQEAgaW50IGNvbXBhdF9tZW1vcnlfb3AodW5zaWduZWQgaW50IGNt
ZCwgWAogICAgICAgICAgICAgYnJlYWs7CiAKICAgICAgICAgY21kID0gMDsK
LSAgICAgICAgaWYgKCBoeXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24oJmNt
ZCwgMHgwMiwgbmF0LmhuZCwgY29tcGF0KSApCisgICAgICAgIGlmICggaHlw
ZXJjYWxsX3hsYXRfY29udGludWF0aW9uKCZjbWQsIDIsIDB4MDIsIG5hdC5o
bmQsIGNvbXBhdCkgKQogICAgICAgICB7CiAgICAgICAgICAgICBCVUdfT04o
cmMgIT0gX19IWVBFUlZJU09SX21lbW9yeV9vcCk7CiAgICAgICAgICAgICBC
VUdfT04oKGNtZCAmIE1FTU9QX0NNRF9NQVNLKSAhPSBvcCk7Ci0tLSBhL3hl
bi9pbmNsdWRlL3hlbi9jb21wYXQuaAorKysgYi94ZW4vaW5jbHVkZS94ZW4v
Y29tcGF0LmgKQEAgLTE5NSw2ICsxOTUsOCBAQCBzdGF0aWMgaW5saW5lIGlu
dCBuYW1lKGsgeGVuXyAjIyBuICp4LCBrCiAgKiBUaGlzIG9wdGlvbiBpcyB1
c2VmdWwgZm9yIGV4dHJhY3RpbmcgdGhlICJvcCIgYXJndW1lbnQgb3Igc2lt
aWxhciBmcm9tIHRoZQogICogaHlwZXJjYWxsIHRvIGVuYWJsZSBmdXJ0aGVy
IHhsYXQgcHJvY2Vzc2luZy4KICAqCisgKiBucjogVG90YWwgbnVtYmVyIG9m
IGFyZ3VtZW50cyB0aGUgaHlwZXJjYWxsIGhhcy4KKyAqCiAgKiBtYXNrOiBT
cGVjaWZpZXMgd2hpY2ggb2YgdGhlIGh5cGVyY2FsbCBhcmd1bWVudHMgcmVx
dWlyZSBjb21wYXQgdHJhbnNsYXRpb24uCiAgKiBiaXQgMCBpbmRpY2F0ZXMg
dGhhdCB0aGUgMCd0aCBhcmd1bWVudCByZXF1aXJlcyB0cmFuc2xhdGlvbiwg
Yml0IDEgaW5kaWNhdGVzCiAgKiB0aGF0IHRoZSBmaXJzdCBhcmd1bWVudCBy
ZXF1aXJlcyB0cmFuc2xhdGlvbiBhbmQgc28gb24uIE5hdGl2ZSBhbmQgY29t
cGF0CkBAIC0yMTQsNyArMjE2LDggQEAgc3RhdGljIGlubGluZSBpbnQgbmFt
ZShrIHhlbl8gIyMgbiAqeCwgawogICoKICAqIFJldHVybjogTnVtYmVyIG9m
IGFyZ3VtZW50cyB3aGljaCB3ZXJlIGFjdHVhbGx5IHRyYW5zbGF0ZWQuCiAg
Ki8KLWludCBoeXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24odW5zaWduZWQg
aW50ICppZCwgdW5zaWduZWQgaW50IG1hc2ssIC4uLik7CitpbnQgaHlwZXJj
YWxsX3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVkIGludCAqaWQsIHVuc2ln
bmVkIGludCBuciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
dW5zaWduZWQgaW50IG1hc2ssIC4uLik7CiAKIC8qIEluLXBsYWNlIHRyYW5z
bGF0aW9uIGZ1bmN0b25zOiAqLwogc3RydWN0IHN0YXJ0X2luZm87Cg==

--=separator
Content-Type: application/octet-stream; name="xsa111.patch"
Content-Disposition: attachment; filename="xsa111.patch"
Content-Transfer-Encoding: base64

eDg2OiBsaW1pdCBjaGVja3MgaW4gaHlwZXJjYWxsX3hsYXRfY29udGludWF0
aW9uKCkgdG8gYWN0dWFsIGFyZ3VtZW50cwoKSFZNL1BWSCBndWVzdHMgY2Fu
IG90aGVyd2lzZSB0cmlnZ2VyIHRoZSBmaW5hbCBCVUdfT04oKSBpbiB0aGF0
CmZ1bmN0aW9uIGJ5IGVudGVyaW5nIDY0LWJpdCBtb2RlLCBzZXR0aW5nIHRo
ZSBoaWdoIGhhbHZlcyBvZiBhZmZlY3RlZApyZWdpc3RlcnMgdG8gbm9uLXpl
cm8gdmFsdWVzLCBsZWF2aW5nIDY0LWJpdCBtb2RlLCBhbmQgaXNzdWluZyBh
Cmh5cGVyY2FsbCB0aGF0IG1pZ2h0IGdldCBwcmVlbXB0ZWQgYW5kIGhlbmNl
IGJlY29tZSBzdWJqZWN0IHRvCmNvbnRpbnVhdGlvbiBhcmd1bWVudCB0cmFu
c2xhdGlvbiAoSFlQRVJWSVNPUl9tZW1vcnlfb3AgYmVpbmcgdGhlIG9ubHkK
b25lIHBvc3NpYmxlIGZvciBIVk0sIFBWSCBhbHNvIGhhdmluZyB0aGUgb3B0
aW9uIG9mIHVzaW5nCkhZUEVSVklTT1JfbW11ZXh0X29wKS4gVGhpcyBpc3N1
ZSBnb3QgaW50cm9kdWNlZCB3aGVuIEhWTSBjb2RlIHdhcwpzd2l0Y2hlZCB0
byB1c2UgY29tcGF0X21lbW9yeV9vcCgpIC0gbmVpdGhlciB0aGF0IG5vcgpo
eXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24oKSB3ZXJlIG9yaWdpbmFsbHkg
aW50ZW5kZWQgdG8gYmUgdXNlZCBieQpvdGhlciB0aGFuIFBWIGd1ZXN0cyAo
d2hpY2ggY2FuJ3QgZW50ZXIgNjQtYml0IG1vZGUgYW5kIGhlbmNlIGhhdmUg
bm8Kd2F5IHRvIGFsdGVyIHRoZSBoaWdoIGhhbHZlcyBvZiA2NC1iaXQgcmVn
aXN0ZXJzKS4KClRoaXMgaXMgWFNBLTExMS4KClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2aWV3ZWQtYnk6IFRp
bSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoKLS0tIGEveGVuL2FyY2gveDg2L2Rv
bWFpbi5jCisrKyBiL3hlbi9hcmNoL3g4Ni9kb21haW4uYwpAQCAtMTc1MCw3
ICsxNzUwLDggQEAgdW5zaWduZWQgbG9uZyBoeXBlcmNhbGxfY3JlYXRlX2Nv
bnRpbnVhdAogICAgIHJldHVybiBvcDsKIH0KIAotaW50IGh5cGVyY2FsbF94
bGF0X2NvbnRpbnVhdGlvbih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBp
bnQgbWFzaywgLi4uKQoraW50IGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlv
bih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBpbnQgbnIsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCBtYXNrLCAu
Li4pCiB7CiAgICAgaW50IHJjID0gMDsKICAgICBzdHJ1Y3QgbWNfc3RhdGUg
Km1jcyA9ICZjdXJyZW50LT5tY19zdGF0ZTsKQEAgLTE3NTksNyArMTc2MCwx
MCBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVk
CiAgICAgdW5zaWduZWQgbG9uZyBudmFsID0gMDsKICAgICB2YV9saXN0IGFy
Z3M7CiAKLSAgICBCVUdfT04oaWQgJiYgKmlkID4gNSk7CisgICAgQVNTRVJU
KG5yIDw9IEFSUkFZX1NJWkUobWNzLT5jYWxsLmFyZ3MpKTsKKyAgICBBU1NF
UlQoIShtYXNrID4+IG5yKSk7CisKKyAgICBCVUdfT04oaWQgJiYgKmlkID49
IG5yKTsKICAgICBCVUdfT04oaWQgJiYgKG1hc2sgJiAoMVUgPDwgKmlkKSkp
OwogCiAgICAgdmFfc3RhcnQoYXJncywgbWFzayk7CkBAIC0xNzcyLDcgKzE3
NzYsNyBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2ln
bmVkCiAgICAgICAgICAgICByZXR1cm4gMDsKICAgICAgICAgfQogCi0gICAg
ICAgIGZvciAoIGkgPSAwOyBpIDwgNjsgKytpLCBtYXNrID4+PSAxICkKKyAg
ICAgICAgZm9yICggaSA9IDA7IGkgPCBucjsgKytpLCBtYXNrID4+PSAxICkK
ICAgICAgICAgewogICAgICAgICAgICAgaWYgKCBtYXNrICYgMSApCiAgICAg
ICAgICAgICB7CkBAIC0xODAwLDcgKzE4MDQsNyBAQCBpbnQgaHlwZXJjYWxs
X3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVkCiAgICAgZWxzZQogICAgIHsK
ICAgICAgICAgcmVncyA9IGd1ZXN0X2NwdV91c2VyX3JlZ3MoKTsKLSAgICAg
ICAgZm9yICggaSA9IDA7IGkgPCA2OyArK2ksIG1hc2sgPj49IDEgKQorICAg
ICAgICBmb3IgKCBpID0gMDsgaSA8IG5yOyArK2ksIG1hc2sgPj49IDEgKQog
ICAgICAgICB7CiAgICAgICAgICAgICB1bnNpZ25lZCBsb25nICpyZWc7CiAK
LS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvbW0uYworKysgYi94
ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9tbS5jCkBAIC0xMTgsNyArMTE4
LDcgQEAgaW50IGNvbXBhdF9hcmNoX21lbW9yeV9vcCh1bnNpZ25lZCBsb25n
IAogICAgICAgICAgICAgYnJlYWs7CiAKICAgICAgICAgaWYgKCByYyA9PSBf
X0hZUEVSVklTT1JfbWVtb3J5X29wICkKLSAgICAgICAgICAgIGh5cGVyY2Fs
bF94bGF0X2NvbnRpbnVhdGlvbihOVUxMLCAweDIsIG5hdCwgYXJnKTsKKyAg
ICAgICAgICAgIGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlvbihOVUxMLCAy
LCAweDIsIG5hdCwgYXJnKTsKIAogICAgICAgICBYTEFUX3BvZF90YXJnZXQo
JmNtcCwgbmF0KTsKIApAQCAtMzU0LDcgKzM1NCw3IEBAIGludCBjb21wYXRf
bW11ZXh0X29wKFhFTl9HVUVTVF9IQU5ETEVfUEEKICAgICAgICAgICAgICAg
ICBsZWZ0ID0gMTsKICAgICAgICAgICAgICAgICBpZiAoIGFyZzEgIT0gTU1V
X1VQREFURV9QUkVFTVBURUQgKQogICAgICAgICAgICAgICAgIHsKLSAgICAg
ICAgICAgICAgICAgICAgQlVHX09OKCFoeXBlcmNhbGxfeGxhdF9jb250aW51
YXRpb24oJmxlZnQsIDB4MDEsIG5hdF9vcHMsCisgICAgICAgICAgICAgICAg
ICAgIEJVR19PTighaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKCZsZWZ0
LCA0LCAweDAxLCBuYXRfb3BzLAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbXBfdW9wcykpOwog
ICAgICAgICAgICAgICAgICAgICBpZiAoICF0ZXN0X2JpdChfTUNTRl9pbl9t
dWx0aWNhbGwsICZtY3MtPmZsYWdzKSApCiAgICAgICAgICAgICAgICAgICAg
ICAgICByZWdzLT5fZWN4ICs9IGNvdW50IC0gaTsKQEAgLTM2Miw3ICszNjIs
NyBAQCBpbnQgY29tcGF0X21tdWV4dF9vcChYRU5fR1VFU1RfSEFORExFX1BB
CiAgICAgICAgICAgICAgICAgICAgICAgICBtY3MtPmNvbXBhdF9jYWxsLmFy
Z3NbMV0gKz0gY291bnQgLSBpOwogICAgICAgICAgICAgICAgIH0KICAgICAg
ICAgICAgICAgICBlbHNlCi0gICAgICAgICAgICAgICAgICAgIEJVR19PTiho
eXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24oJmxlZnQsIDApKTsKKyAgICAg
ICAgICAgICAgICAgICAgQlVHX09OKGh5cGVyY2FsbF94bGF0X2NvbnRpbnVh
dGlvbigmbGVmdCwgNCwgMCkpOwogICAgICAgICAgICAgICAgIEJVR19PTihs
ZWZ0ICE9IGFyZzEpOwogICAgICAgICAgICAgfQogICAgICAgICAgICAgZWxz
ZQotLS0gYS94ZW4vY29tbW9uL2NvbXBhdC9tZW1vcnkuYworKysgYi94ZW4v
Y29tbW9uL2NvbXBhdC9tZW1vcnkuYwpAQCAtMjgyLDcgKzI4Miw3IEBAIGlu
dCBjb21wYXRfbWVtb3J5X29wKHVuc2lnbmVkIGludCBjbWQsIFgKICAgICAg
ICAgICAgIGJyZWFrOwogCiAgICAgICAgIGNtZCA9IDA7Ci0gICAgICAgIGlm
ICggaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKCZjbWQsIDB4MDIsIG5h
dC5obmQsIGNvbXBhdCkgKQorICAgICAgICBpZiAoIGh5cGVyY2FsbF94bGF0
X2NvbnRpbnVhdGlvbigmY21kLCAyLCAweDAyLCBuYXQuaG5kLCBjb21wYXQp
ICkKICAgICAgICAgewogICAgICAgICAgICAgQlVHX09OKHJjICE9IF9fSFlQ
RVJWSVNPUl9tZW1vcnlfb3ApOwogICAgICAgICAgICAgQlVHX09OKChjbWQg
JiBNRU1PUF9DTURfTUFTSykgIT0gb3ApOwotLS0gYS94ZW4vaW5jbHVkZS94
ZW4vY29tcGF0LmgKKysrIGIveGVuL2luY2x1ZGUveGVuL2NvbXBhdC5oCkBA
IC0xOTUsNiArMTk1LDggQEAgc3RhdGljIGlubGluZSBpbnQgbmFtZShrIHhl
bl8gIyMgbiAqeCwgawogICogVGhpcyBvcHRpb24gaXMgdXNlZnVsIGZvciBl
eHRyYWN0aW5nIHRoZSAib3AiIGFyZ3VtZW50IG9yIHNpbWlsYXIgZnJvbSB0
aGUKICAqIGh5cGVyY2FsbCB0byBlbmFibGUgZnVydGhlciB4bGF0IHByb2Nl
c3NpbmcuCiAgKgorICogbnI6IFRvdGFsIG51bWJlciBvZiBhcmd1bWVudHMg
dGhlIGh5cGVyY2FsbCBoYXMuCisgKgogICogbWFzazogU3BlY2lmaWVzIHdo
aWNoIG9mIHRoZSBoeXBlcmNhbGwgYXJndW1lbnRzIHJlcXVpcmUgY29tcGF0
IHRyYW5zbGF0aW9uLgogICogYml0IDAgaW5kaWNhdGVzIHRoYXQgdGhlIDAn
dGggYXJndW1lbnQgcmVxdWlyZXMgdHJhbnNsYXRpb24sIGJpdCAxIGluZGlj
YXRlcwogICogdGhhdCB0aGUgZmlyc3QgYXJndW1lbnQgcmVxdWlyZXMgdHJh
bnNsYXRpb24gYW5kIHNvIG9uLiBOYXRpdmUgYW5kIGNvbXBhdApAQCAtMjE0
LDcgKzIxNiw4IEBAIHN0YXRpYyBpbmxpbmUgaW50IG5hbWUoayB4ZW5fICMj
IG4gKngsIGsKICAqCiAgKiBSZXR1cm46IE51bWJlciBvZiBhcmd1bWVudHMg
d2hpY2ggd2VyZSBhY3R1YWxseSB0cmFuc2xhdGVkLgogICovCi1pbnQgaHlw
ZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVkIGludCAqaWQsIHVu
c2lnbmVkIGludCBtYXNrLCAuLi4pOworaW50IGh5cGVyY2FsbF94bGF0X2Nv
bnRpbnVhdGlvbih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBpbnQgbnIs
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGlu
dCBtYXNrLCAuLi4pOwogCiAvKiBJbi1wbGFjZSB0cmFuc2xhdGlvbiBmdW5j
dG9uczogKi8KIHN0cnVjdCBzdGFydF9pbmZvOwo=

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Thu Nov 27 12:06:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtxqI-0002Ws-Hd; Thu, 27 Nov 2014 12:06:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XtxqG-0002WR-DF; Thu, 27 Nov 2014 12:06:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	86/CE-09842-BC317745; Thu, 27 Nov 2014 12:06:35 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417089993!11772121!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4188 invoked from network); 27 Nov 2014 12:06:34 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Nov 2014 12:06:34 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xtxq3-0003UD-Jb; Thu, 27 Nov 2014 12:06:23 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xtxq3-0008Rw-1V; Thu, 27 Nov 2014 12:06:23 +0000
Date: Thu, 27 Nov 2014 12:06:23 +0000
Message-Id: <E1Xtxq3-0008Rw-1V@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 111 (CVE-2014-8866) - Excessive
 checking in compatibility mode hypercall argument translation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2014-8866 / XSA-111
                              version 3

   Excessive checking in compatibility mode hypercall argument translation

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

The hypercall argument translation needed for 32-bit guests running on
64-bit hypervisors performs checks on the final register state.  These
checks cover all registers potentially holding hypercall arguments,
not just the ones actually doing so for the hypercall being processed,
since the code was originally intended for use only by PV guests.

While this is not a problem for PV guests (as they can't enter 64-bit
mode and hence can't alter the high halves of any of the registers),
the subsequent reuse of the same functionality for HVM guests exposed
those checks to values (specifically, unexpected values for the high
halves of registers not holding hypercall arguments) controlled by
guest software.

IMPACT
======

A buggy or malicious HVM guest can crash the host.

VULNERABLE SYSTEMS
==================

Xen 3.3 and onward are vulnerable.

Only x86 systems are vulnerable.  ARM systems are not vulnerable.

MITIGATION
==========

Running only PV guests will avoid this issue.

There is no mitigation available for HVM guests on any version of Xen
so far released by xenproject.org.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa111-unstable.patch        xen-unstable, Xen 4.4.x
xsa111-4.3.patch             Xen 4.3.x
xsa111-4.2.patch             Xen 4.2.x

$ sha256sum xsa111*.patch
f6e1bf166ebed6235802e4e42853430d2f5b456c1837908a4f7ed6d4d150e4b4  xsa111-4.2.patch
e9b03a4443a40142cc5c21848dc9589770620dde8924344c4a00028c4dace9f2  xsa111-4.3.patch
3c418f065cd452c225af34c3cccf9bdbc37efb6c6a5fc5940fd83ad8620510d3  xsa111.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUdwoTAAoJEIP+FMlX6CvZ/jIH/01d45vOe9bUokjixu+sv93n
FPxm2XC9IZEAuDU4h4RXAkzI0L4vuCAnJq0Rr3quizukQ/oqtPPdbYGC/VgQ15LU
0XE3J2U8BbwsweEDIADinJZ76UvvIWtT4/llQT2WCI/g7nRiW7lZAUkhR9nXL2gg
pw48QIdBkgEGZO7JlWEmrA60OwFcAAdG66/IWNjWbUPrscr/DLG0gimrqqAtG9lY
jTpDrOgC+xARbES9iRBt0IU4duMUiCjwy+y8jeq/Ka5d6QIrcaeTO9Y3d6jf2CCE
Z7TC22OGO4XMg6j+abceao3geS29ezsDQttSh7rGjwqMaNqJbIiitKIq4svAtS4=
=Gtqx
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa111-4.2.patch"
Content-Disposition: attachment; filename="xsa111-4.2.patch"
Content-Transfer-Encoding: base64

eDg2OiBsaW1pdCBjaGVja3MgaW4gaHlwZXJjYWxsX3hsYXRfY29udGludWF0
aW9uKCkgdG8gYWN0dWFsIGFyZ3VtZW50cwoKSFZNL1BWSCBndWVzdHMgY2Fu
IG90aGVyd2lzZSB0cmlnZ2VyIHRoZSBmaW5hbCBCVUdfT04oKSBpbiB0aGF0
CmZ1bmN0aW9uIGJ5IGVudGVyaW5nIDY0LWJpdCBtb2RlLCBzZXR0aW5nIHRo
ZSBoaWdoIGhhbHZlcyBvZiBhZmZlY3RlZApyZWdpc3RlcnMgdG8gbm9uLXpl
cm8gdmFsdWVzLCBsZWF2aW5nIDY0LWJpdCBtb2RlLCBhbmQgaXNzdWluZyBh
Cmh5cGVyY2FsbCB0aGF0IG1pZ2h0IGdldCBwcmVlbXB0ZWQgYW5kIGhlbmNl
IGJlY29tZSBzdWJqZWN0IHRvCmNvbnRpbnVhdGlvbiBhcmd1bWVudCB0cmFu
c2xhdGlvbiAoSFlQRVJWSVNPUl9tZW1vcnlfb3AgYmVpbmcgdGhlIG9ubHkK
b25lIHBvc3NpYmxlIGZvciBIVk0sIFBWSCBhbHNvIGhhdmluZyB0aGUgb3B0
aW9uIG9mIHVzaW5nCkhZUEVSVklTT1JfbW11ZXh0X29wKS4gVGhpcyBpc3N1
ZSBnb3QgaW50cm9kdWNlZCB3aGVuIEhWTSBjb2RlIHdhcwpzd2l0Y2hlZCB0
byB1c2UgY29tcGF0X21lbW9yeV9vcCgpIC0gbmVpdGhlciB0aGF0IG5vcgpo
eXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24oKSB3ZXJlIG9yaWdpbmFsbHkg
aW50ZW5kZWQgdG8gYmUgdXNlZCBieQpvdGhlciB0aGFuIFBWIGd1ZXN0cyAo
d2hpY2ggY2FuJ3QgZW50ZXIgNjQtYml0IG1vZGUgYW5kIGhlbmNlIGhhdmUg
bm8Kd2F5IHRvIGFsdGVyIHRoZSBoaWdoIGhhbHZlcyBvZiA2NC1iaXQgcmVn
aXN0ZXJzKS4KClRoaXMgaXMgWFNBLTExMS4KClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2aWV3ZWQtYnk6IFRp
bSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoKLS0tIGEveGVuL2FyY2gveDg2L2Rv
bWFpbi5jCisrKyBiL3hlbi9hcmNoL3g4Ni9kb21haW4uYwpAQCAtMTkyMSw3
ICsxOTIxLDggQEAgdW5zaWduZWQgbG9uZyBoeXBlcmNhbGxfY3JlYXRlX2Nv
bnRpbnVhdAogfQogCiAjaWZkZWYgQ09ORklHX0NPTVBBVAotaW50IGh5cGVy
Y2FsbF94bGF0X2NvbnRpbnVhdGlvbih1bnNpZ25lZCBpbnQgKmlkLCB1bnNp
Z25lZCBpbnQgbWFzaywgLi4uKQoraW50IGh5cGVyY2FsbF94bGF0X2NvbnRp
bnVhdGlvbih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBpbnQgbnIsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCBt
YXNrLCAuLi4pCiB7CiAgICAgaW50IHJjID0gMDsKICAgICBzdHJ1Y3QgbWNf
c3RhdGUgKm1jcyA9ICZjdXJyZW50LT5tY19zdGF0ZTsKQEAgLTE5MzAsNyAr
MTkzMSwxMCBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVu
c2lnbmVkCiAgICAgdW5zaWduZWQgbG9uZyBudmFsID0gMDsKICAgICB2YV9s
aXN0IGFyZ3M7CiAKLSAgICBCVUdfT04oaWQgJiYgKmlkID4gNSk7CisgICAg
QVNTRVJUKG5yIDw9IEFSUkFZX1NJWkUobWNzLT5jYWxsLmFyZ3MpKTsKKyAg
ICBBU1NFUlQoIShtYXNrID4+IG5yKSk7CisKKyAgICBCVUdfT04oaWQgJiYg
KmlkID49IG5yKTsKICAgICBCVUdfT04oaWQgJiYgKG1hc2sgJiAoMVUgPDwg
KmlkKSkpOwogCiAgICAgdmFfc3RhcnQoYXJncywgbWFzayk7CkBAIC0xOTM5
LDcgKzE5NDMsNyBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9u
KHVuc2lnbmVkCiAgICAgewogICAgICAgICBpZiAoICF0ZXN0X2JpdChfTUNT
Rl9jYWxsX3ByZWVtcHRlZCwgJm1jcy0+ZmxhZ3MpICkKICAgICAgICAgICAg
IHJldHVybiAwOwotICAgICAgICBmb3IgKCBpID0gMDsgaSA8IDY7ICsraSwg
bWFzayA+Pj0gMSApCisgICAgICAgIGZvciAoIGkgPSAwOyBpIDwgbnI7ICsr
aSwgbWFzayA+Pj0gMSApCiAgICAgICAgIHsKICAgICAgICAgICAgIGlmICgg
bWFzayAmIDEgKQogICAgICAgICAgICAgewpAQCAtMTk2Nyw3ICsxOTcxLDcg
QEAgaW50IGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlvbih1bnNpZ25lZAog
ICAgIGVsc2UKICAgICB7CiAgICAgICAgIHJlZ3MgPSBndWVzdF9jcHVfdXNl
cl9yZWdzKCk7Ci0gICAgICAgIGZvciAoIGkgPSAwOyBpIDwgNjsgKytpLCBt
YXNrID4+PSAxICkKKyAgICAgICAgZm9yICggaSA9IDA7IGkgPCBucjsgKytp
LCBtYXNrID4+PSAxICkKICAgICAgICAgewogICAgICAgICAgICAgdW5zaWdu
ZWQgbG9uZyAqcmVnOwogCi0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvY29t
cGF0L21tLmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvbW0u
YwpAQCAtNzgsNyArNzgsNyBAQCBpbnQgY29tcGF0X2FyY2hfbWVtb3J5X29w
KGludCBvcCwgWEVOX0dVCiAgICAgICAgIH0KIAogICAgICAgICBpZiAoIHJj
ID09IF9fSFlQRVJWSVNPUl9tZW1vcnlfb3AgKQotICAgICAgICAgICAgaHlw
ZXJjYWxsX3hsYXRfY29udGludWF0aW9uKE5VTEwsIDB4MiwgbmF0LCBhcmcp
OworICAgICAgICAgICAgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKE5V
TEwsIDIsIDB4MiwgbmF0LCBhcmcpOwogCiAgICAgICAgIGJyZWFrOwogICAg
IH0KQEAgLTE0NCw3ICsxNDQsNyBAQCBpbnQgY29tcGF0X2FyY2hfbWVtb3J5
X29wKGludCBvcCwgWEVOX0dVCiAgICAgICAgICAgICBicmVhazsKIAogICAg
ICAgICBpZiAoIHJjID09IF9fSFlQRVJWSVNPUl9tZW1vcnlfb3AgKQotICAg
ICAgICAgICAgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKE5VTEwsIDB4
MiwgbmF0LCBhcmcpOworICAgICAgICAgICAgaHlwZXJjYWxsX3hsYXRfY29u
dGludWF0aW9uKE5VTEwsIDIsIDB4MiwgbmF0LCBhcmcpOwogCiAgICAgICAg
IFhMQVRfcG9kX3RhcmdldCgmY21wLCBuYXQpOwogCkBAIC0zNzksNyArMzc5
LDcgQEAgaW50IGNvbXBhdF9tbXVleHRfb3AoWEVOX0dVRVNUX0hBTkRMRSht
bQogICAgICAgICAgICAgICAgIGxlZnQgPSAxOwogICAgICAgICAgICAgICAg
IGlmICggYXJnMSAhPSBNTVVfVVBEQVRFX1BSRUVNUFRFRCApCiAgICAgICAg
ICAgICAgICAgewotICAgICAgICAgICAgICAgICAgICBCVUdfT04oIWh5cGVy
Y2FsbF94bGF0X2NvbnRpbnVhdGlvbigmbGVmdCwgMHgwMSwgbmF0X29wcywK
KyAgICAgICAgICAgICAgICAgICAgQlVHX09OKCFoeXBlcmNhbGxfeGxhdF9j
b250aW51YXRpb24oJmxlZnQsIDQsIDB4MDEsIG5hdF9vcHMsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNtcF91b3BzKSk7CiAgICAgICAgICAgICAgICAgICAgIGlmICggIXRl
c3RfYml0KF9NQ1NGX2luX211bHRpY2FsbCwgJm1jcy0+ZmxhZ3MpICkKICAg
ICAgICAgICAgICAgICAgICAgICAgIHJlZ3MtPl9lY3ggKz0gY291bnQgLSBp
OwpAQCAtMzg3LDcgKzM4Nyw3IEBAIGludCBjb21wYXRfbW11ZXh0X29wKFhF
Tl9HVUVTVF9IQU5ETEUobW0KICAgICAgICAgICAgICAgICAgICAgICAgIG1j
cy0+Y29tcGF0X2NhbGwuYXJnc1sxXSArPSBjb3VudCAtIGk7CiAgICAgICAg
ICAgICAgICAgfQogICAgICAgICAgICAgICAgIGVsc2UKLSAgICAgICAgICAg
ICAgICAgICAgQlVHX09OKGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlvbigm
bGVmdCwgMCkpOworICAgICAgICAgICAgICAgICAgICBCVUdfT04oaHlwZXJj
YWxsX3hsYXRfY29udGludWF0aW9uKCZsZWZ0LCA0LCAwKSk7CiAgICAgICAg
ICAgICAgICAgQlVHX09OKGxlZnQgIT0gYXJnMSk7CiAgICAgICAgICAgICB9
CiAgICAgICAgICAgICBlbHNlCi0tLSBhL3hlbi9jb21tb24vY29tcGF0L21l
bW9yeS5jCisrKyBiL3hlbi9jb21tb24vY29tcGF0L21lbW9yeS5jCkBAIC0y
MDgsNyArMjA4LDcgQEAgaW50IGNvbXBhdF9tZW1vcnlfb3AodW5zaWduZWQg
aW50IGNtZCwgWAogICAgICAgICAgICAgYnJlYWs7CiAKICAgICAgICAgY21k
ID0gMDsKLSAgICAgICAgaWYgKCBoeXBlcmNhbGxfeGxhdF9jb250aW51YXRp
b24oJmNtZCwgMHgwMiwgbmF0LmhuZCwgY29tcGF0KSApCisgICAgICAgIGlm
ICggaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKCZjbWQsIDIsIDB4MDIs
IG5hdC5obmQsIGNvbXBhdCkgKQogICAgICAgICB7CiAgICAgICAgICAgICBC
VUdfT04ocmMgIT0gX19IWVBFUlZJU09SX21lbW9yeV9vcCk7CiAgICAgICAg
ICAgICBCVUdfT04oKGNtZCAmIE1FTU9QX0NNRF9NQVNLKSAhPSBvcCk7Ci0t
LSBhL3hlbi9pbmNsdWRlL3hlbi9jb21wYXQuaAorKysgYi94ZW4vaW5jbHVk
ZS94ZW4vY29tcGF0LmgKQEAgLTE5Miw2ICsxOTIsOCBAQCBzdGF0aWMgaW5s
aW5lIGludCBuYW1lKGsgeGVuXyAjIyBuICp4LCBrCiAgKiBUaGlzIG9wdGlv
biBpcyB1c2VmdWwgZm9yIGV4dHJhY3RpbmcgdGhlICJvcCIgYXJndW1lbnQg
b3Igc2ltaWxhciBmcm9tIHRoZQogICogaHlwZXJjYWxsIHRvIGVuYWJsZSBm
dXJ0aGVyIHhsYXQgcHJvY2Vzc2luZy4KICAqCisgKiBucjogVG90YWwgbnVt
YmVyIG9mIGFyZ3VtZW50cyB0aGUgaHlwZXJjYWxsIGhhcy4KKyAqCiAgKiBt
YXNrOiBTcGVjaWZpZXMgd2hpY2ggb2YgdGhlIGh5cGVyY2FsbCBhcmd1bWVu
dHMgcmVxdWlyZSBjb21wYXQgdHJhbnNsYXRpb24uCiAgKiBiaXQgMCBpbmRp
Y2F0ZXMgdGhhdCB0aGUgMCd0aCBhcmd1bWVudCByZXF1aXJlcyB0cmFuc2xh
dGlvbiwgYml0IDEgaW5kaWNhdGVzCiAgKiB0aGF0IHRoZSBmaXJzdCBhcmd1
bWVudCByZXF1aXJlcyB0cmFuc2xhdGlvbiBhbmQgc28gb24uIE5hdGl2ZSBh
bmQgY29tcGF0CkBAIC0yMTEsNyArMjEzLDggQEAgc3RhdGljIGlubGluZSBp
bnQgbmFtZShrIHhlbl8gIyMgbiAqeCwgawogICoKICAqIFJldHVybjogTnVt
YmVyIG9mIGFyZ3VtZW50cyB3aGljaCB3ZXJlIGFjdHVhbGx5IHRyYW5zbGF0
ZWQuCiAgKi8KLWludCBoeXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24odW5z
aWduZWQgaW50ICppZCwgdW5zaWduZWQgaW50IG1hc2ssIC4uLik7CitpbnQg
aHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVkIGludCAqaWQs
IHVuc2lnbmVkIGludCBuciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdW5zaWduZWQgaW50IG1hc2ssIC4uLik7CiAKIC8qIEluLXBsYWNl
IHRyYW5zbGF0aW9uIGZ1bmN0b25zOiAqLwogc3RydWN0IHN0YXJ0X2luZm87
Cg==

--=separator
Content-Type: application/octet-stream; name="xsa111-4.3.patch"
Content-Disposition: attachment; filename="xsa111-4.3.patch"
Content-Transfer-Encoding: base64

eDg2OiBsaW1pdCBjaGVja3MgaW4gaHlwZXJjYWxsX3hsYXRfY29udGludWF0
aW9uKCkgdG8gYWN0dWFsIGFyZ3VtZW50cwoKSFZNL1BWSCBndWVzdHMgY2Fu
IG90aGVyd2lzZSB0cmlnZ2VyIHRoZSBmaW5hbCBCVUdfT04oKSBpbiB0aGF0
CmZ1bmN0aW9uIGJ5IGVudGVyaW5nIDY0LWJpdCBtb2RlLCBzZXR0aW5nIHRo
ZSBoaWdoIGhhbHZlcyBvZiBhZmZlY3RlZApyZWdpc3RlcnMgdG8gbm9uLXpl
cm8gdmFsdWVzLCBsZWF2aW5nIDY0LWJpdCBtb2RlLCBhbmQgaXNzdWluZyBh
Cmh5cGVyY2FsbCB0aGF0IG1pZ2h0IGdldCBwcmVlbXB0ZWQgYW5kIGhlbmNl
IGJlY29tZSBzdWJqZWN0IHRvCmNvbnRpbnVhdGlvbiBhcmd1bWVudCB0cmFu
c2xhdGlvbiAoSFlQRVJWSVNPUl9tZW1vcnlfb3AgYmVpbmcgdGhlIG9ubHkK
b25lIHBvc3NpYmxlIGZvciBIVk0sIFBWSCBhbHNvIGhhdmluZyB0aGUgb3B0
aW9uIG9mIHVzaW5nCkhZUEVSVklTT1JfbW11ZXh0X29wKS4gVGhpcyBpc3N1
ZSBnb3QgaW50cm9kdWNlZCB3aGVuIEhWTSBjb2RlIHdhcwpzd2l0Y2hlZCB0
byB1c2UgY29tcGF0X21lbW9yeV9vcCgpIC0gbmVpdGhlciB0aGF0IG5vcgpo
eXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24oKSB3ZXJlIG9yaWdpbmFsbHkg
aW50ZW5kZWQgdG8gYmUgdXNlZCBieQpvdGhlciB0aGFuIFBWIGd1ZXN0cyAo
d2hpY2ggY2FuJ3QgZW50ZXIgNjQtYml0IG1vZGUgYW5kIGhlbmNlIGhhdmUg
bm8Kd2F5IHRvIGFsdGVyIHRoZSBoaWdoIGhhbHZlcyBvZiA2NC1iaXQgcmVn
aXN0ZXJzKS4KClRoaXMgaXMgWFNBLTExMS4KClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2aWV3ZWQtYnk6IFRp
bSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoKLS0tIGEveGVuL2FyY2gveDg2L2Rv
bWFpbi5jCisrKyBiL3hlbi9hcmNoL3g4Ni9kb21haW4uYwpAQCAtMTY1Myw3
ICsxNjUzLDggQEAgdW5zaWduZWQgbG9uZyBoeXBlcmNhbGxfY3JlYXRlX2Nv
bnRpbnVhdAogICAgIHJldHVybiBvcDsKIH0KIAotaW50IGh5cGVyY2FsbF94
bGF0X2NvbnRpbnVhdGlvbih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBp
bnQgbWFzaywgLi4uKQoraW50IGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlv
bih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBpbnQgbnIsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCBtYXNrLCAu
Li4pCiB7CiAgICAgaW50IHJjID0gMDsKICAgICBzdHJ1Y3QgbWNfc3RhdGUg
Km1jcyA9ICZjdXJyZW50LT5tY19zdGF0ZTsKQEAgLTE2NjIsNyArMTY2Mywx
MCBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVk
CiAgICAgdW5zaWduZWQgbG9uZyBudmFsID0gMDsKICAgICB2YV9saXN0IGFy
Z3M7CiAKLSAgICBCVUdfT04oaWQgJiYgKmlkID4gNSk7CisgICAgQVNTRVJU
KG5yIDw9IEFSUkFZX1NJWkUobWNzLT5jYWxsLmFyZ3MpKTsKKyAgICBBU1NF
UlQoIShtYXNrID4+IG5yKSk7CisKKyAgICBCVUdfT04oaWQgJiYgKmlkID49
IG5yKTsKICAgICBCVUdfT04oaWQgJiYgKG1hc2sgJiAoMVUgPDwgKmlkKSkp
OwogCiAgICAgdmFfc3RhcnQoYXJncywgbWFzayk7CkBAIC0xNjcxLDcgKzE2
NzUsNyBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2ln
bmVkCiAgICAgewogICAgICAgICBpZiAoICF0ZXN0X2JpdChfTUNTRl9jYWxs
X3ByZWVtcHRlZCwgJm1jcy0+ZmxhZ3MpICkKICAgICAgICAgICAgIHJldHVy
biAwOwotICAgICAgICBmb3IgKCBpID0gMDsgaSA8IDY7ICsraSwgbWFzayA+
Pj0gMSApCisgICAgICAgIGZvciAoIGkgPSAwOyBpIDwgbnI7ICsraSwgbWFz
ayA+Pj0gMSApCiAgICAgICAgIHsKICAgICAgICAgICAgIGlmICggbWFzayAm
IDEgKQogICAgICAgICAgICAgewpAQCAtMTY5OSw3ICsxNzAzLDcgQEAgaW50
IGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlvbih1bnNpZ25lZAogICAgIGVs
c2UKICAgICB7CiAgICAgICAgIHJlZ3MgPSBndWVzdF9jcHVfdXNlcl9yZWdz
KCk7Ci0gICAgICAgIGZvciAoIGkgPSAwOyBpIDwgNjsgKytpLCBtYXNrID4+
PSAxICkKKyAgICAgICAgZm9yICggaSA9IDA7IGkgPCBucjsgKytpLCBtYXNr
ID4+PSAxICkKICAgICAgICAgewogICAgICAgICAgICAgdW5zaWduZWQgbG9u
ZyAqcmVnOwogCi0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L21t
LmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvbW0uYwpAQCAt
NzgsNyArNzgsNyBAQCBpbnQgY29tcGF0X2FyY2hfbWVtb3J5X29wKGludCBv
cCwgWEVOX0dVCiAgICAgICAgIH0KIAogICAgICAgICBpZiAoIHJjID09IF9f
SFlQRVJWSVNPUl9tZW1vcnlfb3AgKQotICAgICAgICAgICAgaHlwZXJjYWxs
X3hsYXRfY29udGludWF0aW9uKE5VTEwsIDB4MiwgbmF0LCBhcmcpOworICAg
ICAgICAgICAgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKE5VTEwsIDIs
IDB4MiwgbmF0LCBhcmcpOwogCiAgICAgICAgIGJyZWFrOwogICAgIH0KQEAg
LTE0NCw3ICsxNDQsNyBAQCBpbnQgY29tcGF0X2FyY2hfbWVtb3J5X29wKGlu
dCBvcCwgWEVOX0dVCiAgICAgICAgICAgICBicmVhazsKIAogICAgICAgICBp
ZiAoIHJjID09IF9fSFlQRVJWSVNPUl9tZW1vcnlfb3AgKQotICAgICAgICAg
ICAgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKE5VTEwsIDB4MiwgbmF0
LCBhcmcpOworICAgICAgICAgICAgaHlwZXJjYWxsX3hsYXRfY29udGludWF0
aW9uKE5VTEwsIDIsIDB4MiwgbmF0LCBhcmcpOwogCiAgICAgICAgIFhMQVRf
cG9kX3RhcmdldCgmY21wLCBuYXQpOwogCkBAIC0zNzksNyArMzc5LDcgQEAg
aW50IGNvbXBhdF9tbXVleHRfb3AoWEVOX0dVRVNUX0hBTkRMRV9QQQogICAg
ICAgICAgICAgICAgIGxlZnQgPSAxOwogICAgICAgICAgICAgICAgIGlmICgg
YXJnMSAhPSBNTVVfVVBEQVRFX1BSRUVNUFRFRCApCiAgICAgICAgICAgICAg
ICAgewotICAgICAgICAgICAgICAgICAgICBCVUdfT04oIWh5cGVyY2FsbF94
bGF0X2NvbnRpbnVhdGlvbigmbGVmdCwgMHgwMSwgbmF0X29wcywKKyAgICAg
ICAgICAgICAgICAgICAgQlVHX09OKCFoeXBlcmNhbGxfeGxhdF9jb250aW51
YXRpb24oJmxlZnQsIDQsIDB4MDEsIG5hdF9vcHMsCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNt
cF91b3BzKSk7CiAgICAgICAgICAgICAgICAgICAgIGlmICggIXRlc3RfYml0
KF9NQ1NGX2luX211bHRpY2FsbCwgJm1jcy0+ZmxhZ3MpICkKICAgICAgICAg
ICAgICAgICAgICAgICAgIHJlZ3MtPl9lY3ggKz0gY291bnQgLSBpOwpAQCAt
Mzg3LDcgKzM4Nyw3IEBAIGludCBjb21wYXRfbW11ZXh0X29wKFhFTl9HVUVT
VF9IQU5ETEVfUEEKICAgICAgICAgICAgICAgICAgICAgICAgIG1jcy0+Y29t
cGF0X2NhbGwuYXJnc1sxXSArPSBjb3VudCAtIGk7CiAgICAgICAgICAgICAg
ICAgfQogICAgICAgICAgICAgICAgIGVsc2UKLSAgICAgICAgICAgICAgICAg
ICAgQlVHX09OKGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlvbigmbGVmdCwg
MCkpOworICAgICAgICAgICAgICAgICAgICBCVUdfT04oaHlwZXJjYWxsX3hs
YXRfY29udGludWF0aW9uKCZsZWZ0LCA0LCAwKSk7CiAgICAgICAgICAgICAg
ICAgQlVHX09OKGxlZnQgIT0gYXJnMSk7CiAgICAgICAgICAgICB9CiAgICAg
ICAgICAgICBlbHNlCi0tLSBhL3hlbi9jb21tb24vY29tcGF0L21lbW9yeS5j
CisrKyBiL3hlbi9jb21tb24vY29tcGF0L21lbW9yeS5jCkBAIC0yMDgsNyAr
MjA4LDcgQEAgaW50IGNvbXBhdF9tZW1vcnlfb3AodW5zaWduZWQgaW50IGNt
ZCwgWAogICAgICAgICAgICAgYnJlYWs7CiAKICAgICAgICAgY21kID0gMDsK
LSAgICAgICAgaWYgKCBoeXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24oJmNt
ZCwgMHgwMiwgbmF0LmhuZCwgY29tcGF0KSApCisgICAgICAgIGlmICggaHlw
ZXJjYWxsX3hsYXRfY29udGludWF0aW9uKCZjbWQsIDIsIDB4MDIsIG5hdC5o
bmQsIGNvbXBhdCkgKQogICAgICAgICB7CiAgICAgICAgICAgICBCVUdfT04o
cmMgIT0gX19IWVBFUlZJU09SX21lbW9yeV9vcCk7CiAgICAgICAgICAgICBC
VUdfT04oKGNtZCAmIE1FTU9QX0NNRF9NQVNLKSAhPSBvcCk7Ci0tLSBhL3hl
bi9pbmNsdWRlL3hlbi9jb21wYXQuaAorKysgYi94ZW4vaW5jbHVkZS94ZW4v
Y29tcGF0LmgKQEAgLTE5NSw2ICsxOTUsOCBAQCBzdGF0aWMgaW5saW5lIGlu
dCBuYW1lKGsgeGVuXyAjIyBuICp4LCBrCiAgKiBUaGlzIG9wdGlvbiBpcyB1
c2VmdWwgZm9yIGV4dHJhY3RpbmcgdGhlICJvcCIgYXJndW1lbnQgb3Igc2lt
aWxhciBmcm9tIHRoZQogICogaHlwZXJjYWxsIHRvIGVuYWJsZSBmdXJ0aGVy
IHhsYXQgcHJvY2Vzc2luZy4KICAqCisgKiBucjogVG90YWwgbnVtYmVyIG9m
IGFyZ3VtZW50cyB0aGUgaHlwZXJjYWxsIGhhcy4KKyAqCiAgKiBtYXNrOiBT
cGVjaWZpZXMgd2hpY2ggb2YgdGhlIGh5cGVyY2FsbCBhcmd1bWVudHMgcmVx
dWlyZSBjb21wYXQgdHJhbnNsYXRpb24uCiAgKiBiaXQgMCBpbmRpY2F0ZXMg
dGhhdCB0aGUgMCd0aCBhcmd1bWVudCByZXF1aXJlcyB0cmFuc2xhdGlvbiwg
Yml0IDEgaW5kaWNhdGVzCiAgKiB0aGF0IHRoZSBmaXJzdCBhcmd1bWVudCBy
ZXF1aXJlcyB0cmFuc2xhdGlvbiBhbmQgc28gb24uIE5hdGl2ZSBhbmQgY29t
cGF0CkBAIC0yMTQsNyArMjE2LDggQEAgc3RhdGljIGlubGluZSBpbnQgbmFt
ZShrIHhlbl8gIyMgbiAqeCwgawogICoKICAqIFJldHVybjogTnVtYmVyIG9m
IGFyZ3VtZW50cyB3aGljaCB3ZXJlIGFjdHVhbGx5IHRyYW5zbGF0ZWQuCiAg
Ki8KLWludCBoeXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24odW5zaWduZWQg
aW50ICppZCwgdW5zaWduZWQgaW50IG1hc2ssIC4uLik7CitpbnQgaHlwZXJj
YWxsX3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVkIGludCAqaWQsIHVuc2ln
bmVkIGludCBuciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
dW5zaWduZWQgaW50IG1hc2ssIC4uLik7CiAKIC8qIEluLXBsYWNlIHRyYW5z
bGF0aW9uIGZ1bmN0b25zOiAqLwogc3RydWN0IHN0YXJ0X2luZm87Cg==

--=separator
Content-Type: application/octet-stream; name="xsa111.patch"
Content-Disposition: attachment; filename="xsa111.patch"
Content-Transfer-Encoding: base64

eDg2OiBsaW1pdCBjaGVja3MgaW4gaHlwZXJjYWxsX3hsYXRfY29udGludWF0
aW9uKCkgdG8gYWN0dWFsIGFyZ3VtZW50cwoKSFZNL1BWSCBndWVzdHMgY2Fu
IG90aGVyd2lzZSB0cmlnZ2VyIHRoZSBmaW5hbCBCVUdfT04oKSBpbiB0aGF0
CmZ1bmN0aW9uIGJ5IGVudGVyaW5nIDY0LWJpdCBtb2RlLCBzZXR0aW5nIHRo
ZSBoaWdoIGhhbHZlcyBvZiBhZmZlY3RlZApyZWdpc3RlcnMgdG8gbm9uLXpl
cm8gdmFsdWVzLCBsZWF2aW5nIDY0LWJpdCBtb2RlLCBhbmQgaXNzdWluZyBh
Cmh5cGVyY2FsbCB0aGF0IG1pZ2h0IGdldCBwcmVlbXB0ZWQgYW5kIGhlbmNl
IGJlY29tZSBzdWJqZWN0IHRvCmNvbnRpbnVhdGlvbiBhcmd1bWVudCB0cmFu
c2xhdGlvbiAoSFlQRVJWSVNPUl9tZW1vcnlfb3AgYmVpbmcgdGhlIG9ubHkK
b25lIHBvc3NpYmxlIGZvciBIVk0sIFBWSCBhbHNvIGhhdmluZyB0aGUgb3B0
aW9uIG9mIHVzaW5nCkhZUEVSVklTT1JfbW11ZXh0X29wKS4gVGhpcyBpc3N1
ZSBnb3QgaW50cm9kdWNlZCB3aGVuIEhWTSBjb2RlIHdhcwpzd2l0Y2hlZCB0
byB1c2UgY29tcGF0X21lbW9yeV9vcCgpIC0gbmVpdGhlciB0aGF0IG5vcgpo
eXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24oKSB3ZXJlIG9yaWdpbmFsbHkg
aW50ZW5kZWQgdG8gYmUgdXNlZCBieQpvdGhlciB0aGFuIFBWIGd1ZXN0cyAo
d2hpY2ggY2FuJ3QgZW50ZXIgNjQtYml0IG1vZGUgYW5kIGhlbmNlIGhhdmUg
bm8Kd2F5IHRvIGFsdGVyIHRoZSBoaWdoIGhhbHZlcyBvZiA2NC1iaXQgcmVn
aXN0ZXJzKS4KClRoaXMgaXMgWFNBLTExMS4KClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2aWV3ZWQtYnk6IFRp
bSBEZWVnYW4gPHRpbUB4ZW4ub3JnPgoKLS0tIGEveGVuL2FyY2gveDg2L2Rv
bWFpbi5jCisrKyBiL3hlbi9hcmNoL3g4Ni9kb21haW4uYwpAQCAtMTc1MCw3
ICsxNzUwLDggQEAgdW5zaWduZWQgbG9uZyBoeXBlcmNhbGxfY3JlYXRlX2Nv
bnRpbnVhdAogICAgIHJldHVybiBvcDsKIH0KIAotaW50IGh5cGVyY2FsbF94
bGF0X2NvbnRpbnVhdGlvbih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBp
bnQgbWFzaywgLi4uKQoraW50IGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlv
bih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBpbnQgbnIsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCBtYXNrLCAu
Li4pCiB7CiAgICAgaW50IHJjID0gMDsKICAgICBzdHJ1Y3QgbWNfc3RhdGUg
Km1jcyA9ICZjdXJyZW50LT5tY19zdGF0ZTsKQEAgLTE3NTksNyArMTc2MCwx
MCBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVk
CiAgICAgdW5zaWduZWQgbG9uZyBudmFsID0gMDsKICAgICB2YV9saXN0IGFy
Z3M7CiAKLSAgICBCVUdfT04oaWQgJiYgKmlkID4gNSk7CisgICAgQVNTRVJU
KG5yIDw9IEFSUkFZX1NJWkUobWNzLT5jYWxsLmFyZ3MpKTsKKyAgICBBU1NF
UlQoIShtYXNrID4+IG5yKSk7CisKKyAgICBCVUdfT04oaWQgJiYgKmlkID49
IG5yKTsKICAgICBCVUdfT04oaWQgJiYgKG1hc2sgJiAoMVUgPDwgKmlkKSkp
OwogCiAgICAgdmFfc3RhcnQoYXJncywgbWFzayk7CkBAIC0xNzcyLDcgKzE3
NzYsNyBAQCBpbnQgaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2ln
bmVkCiAgICAgICAgICAgICByZXR1cm4gMDsKICAgICAgICAgfQogCi0gICAg
ICAgIGZvciAoIGkgPSAwOyBpIDwgNjsgKytpLCBtYXNrID4+PSAxICkKKyAg
ICAgICAgZm9yICggaSA9IDA7IGkgPCBucjsgKytpLCBtYXNrID4+PSAxICkK
ICAgICAgICAgewogICAgICAgICAgICAgaWYgKCBtYXNrICYgMSApCiAgICAg
ICAgICAgICB7CkBAIC0xODAwLDcgKzE4MDQsNyBAQCBpbnQgaHlwZXJjYWxs
X3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVkCiAgICAgZWxzZQogICAgIHsK
ICAgICAgICAgcmVncyA9IGd1ZXN0X2NwdV91c2VyX3JlZ3MoKTsKLSAgICAg
ICAgZm9yICggaSA9IDA7IGkgPCA2OyArK2ksIG1hc2sgPj49IDEgKQorICAg
ICAgICBmb3IgKCBpID0gMDsgaSA8IG5yOyArK2ksIG1hc2sgPj49IDEgKQog
ICAgICAgICB7CiAgICAgICAgICAgICB1bnNpZ25lZCBsb25nICpyZWc7CiAK
LS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvbW0uYworKysgYi94
ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9tbS5jCkBAIC0xMTgsNyArMTE4
LDcgQEAgaW50IGNvbXBhdF9hcmNoX21lbW9yeV9vcCh1bnNpZ25lZCBsb25n
IAogICAgICAgICAgICAgYnJlYWs7CiAKICAgICAgICAgaWYgKCByYyA9PSBf
X0hZUEVSVklTT1JfbWVtb3J5X29wICkKLSAgICAgICAgICAgIGh5cGVyY2Fs
bF94bGF0X2NvbnRpbnVhdGlvbihOVUxMLCAweDIsIG5hdCwgYXJnKTsKKyAg
ICAgICAgICAgIGh5cGVyY2FsbF94bGF0X2NvbnRpbnVhdGlvbihOVUxMLCAy
LCAweDIsIG5hdCwgYXJnKTsKIAogICAgICAgICBYTEFUX3BvZF90YXJnZXQo
JmNtcCwgbmF0KTsKIApAQCAtMzU0LDcgKzM1NCw3IEBAIGludCBjb21wYXRf
bW11ZXh0X29wKFhFTl9HVUVTVF9IQU5ETEVfUEEKICAgICAgICAgICAgICAg
ICBsZWZ0ID0gMTsKICAgICAgICAgICAgICAgICBpZiAoIGFyZzEgIT0gTU1V
X1VQREFURV9QUkVFTVBURUQgKQogICAgICAgICAgICAgICAgIHsKLSAgICAg
ICAgICAgICAgICAgICAgQlVHX09OKCFoeXBlcmNhbGxfeGxhdF9jb250aW51
YXRpb24oJmxlZnQsIDB4MDEsIG5hdF9vcHMsCisgICAgICAgICAgICAgICAg
ICAgIEJVR19PTighaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKCZsZWZ0
LCA0LCAweDAxLCBuYXRfb3BzLAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbXBfdW9wcykpOwog
ICAgICAgICAgICAgICAgICAgICBpZiAoICF0ZXN0X2JpdChfTUNTRl9pbl9t
dWx0aWNhbGwsICZtY3MtPmZsYWdzKSApCiAgICAgICAgICAgICAgICAgICAg
ICAgICByZWdzLT5fZWN4ICs9IGNvdW50IC0gaTsKQEAgLTM2Miw3ICszNjIs
NyBAQCBpbnQgY29tcGF0X21tdWV4dF9vcChYRU5fR1VFU1RfSEFORExFX1BB
CiAgICAgICAgICAgICAgICAgICAgICAgICBtY3MtPmNvbXBhdF9jYWxsLmFy
Z3NbMV0gKz0gY291bnQgLSBpOwogICAgICAgICAgICAgICAgIH0KICAgICAg
ICAgICAgICAgICBlbHNlCi0gICAgICAgICAgICAgICAgICAgIEJVR19PTiho
eXBlcmNhbGxfeGxhdF9jb250aW51YXRpb24oJmxlZnQsIDApKTsKKyAgICAg
ICAgICAgICAgICAgICAgQlVHX09OKGh5cGVyY2FsbF94bGF0X2NvbnRpbnVh
dGlvbigmbGVmdCwgNCwgMCkpOwogICAgICAgICAgICAgICAgIEJVR19PTihs
ZWZ0ICE9IGFyZzEpOwogICAgICAgICAgICAgfQogICAgICAgICAgICAgZWxz
ZQotLS0gYS94ZW4vY29tbW9uL2NvbXBhdC9tZW1vcnkuYworKysgYi94ZW4v
Y29tbW9uL2NvbXBhdC9tZW1vcnkuYwpAQCAtMjgyLDcgKzI4Miw3IEBAIGlu
dCBjb21wYXRfbWVtb3J5X29wKHVuc2lnbmVkIGludCBjbWQsIFgKICAgICAg
ICAgICAgIGJyZWFrOwogCiAgICAgICAgIGNtZCA9IDA7Ci0gICAgICAgIGlm
ICggaHlwZXJjYWxsX3hsYXRfY29udGludWF0aW9uKCZjbWQsIDB4MDIsIG5h
dC5obmQsIGNvbXBhdCkgKQorICAgICAgICBpZiAoIGh5cGVyY2FsbF94bGF0
X2NvbnRpbnVhdGlvbigmY21kLCAyLCAweDAyLCBuYXQuaG5kLCBjb21wYXQp
ICkKICAgICAgICAgewogICAgICAgICAgICAgQlVHX09OKHJjICE9IF9fSFlQ
RVJWSVNPUl9tZW1vcnlfb3ApOwogICAgICAgICAgICAgQlVHX09OKChjbWQg
JiBNRU1PUF9DTURfTUFTSykgIT0gb3ApOwotLS0gYS94ZW4vaW5jbHVkZS94
ZW4vY29tcGF0LmgKKysrIGIveGVuL2luY2x1ZGUveGVuL2NvbXBhdC5oCkBA
IC0xOTUsNiArMTk1LDggQEAgc3RhdGljIGlubGluZSBpbnQgbmFtZShrIHhl
bl8gIyMgbiAqeCwgawogICogVGhpcyBvcHRpb24gaXMgdXNlZnVsIGZvciBl
eHRyYWN0aW5nIHRoZSAib3AiIGFyZ3VtZW50IG9yIHNpbWlsYXIgZnJvbSB0
aGUKICAqIGh5cGVyY2FsbCB0byBlbmFibGUgZnVydGhlciB4bGF0IHByb2Nl
c3NpbmcuCiAgKgorICogbnI6IFRvdGFsIG51bWJlciBvZiBhcmd1bWVudHMg
dGhlIGh5cGVyY2FsbCBoYXMuCisgKgogICogbWFzazogU3BlY2lmaWVzIHdo
aWNoIG9mIHRoZSBoeXBlcmNhbGwgYXJndW1lbnRzIHJlcXVpcmUgY29tcGF0
IHRyYW5zbGF0aW9uLgogICogYml0IDAgaW5kaWNhdGVzIHRoYXQgdGhlIDAn
dGggYXJndW1lbnQgcmVxdWlyZXMgdHJhbnNsYXRpb24sIGJpdCAxIGluZGlj
YXRlcwogICogdGhhdCB0aGUgZmlyc3QgYXJndW1lbnQgcmVxdWlyZXMgdHJh
bnNsYXRpb24gYW5kIHNvIG9uLiBOYXRpdmUgYW5kIGNvbXBhdApAQCAtMjE0
LDcgKzIxNiw4IEBAIHN0YXRpYyBpbmxpbmUgaW50IG5hbWUoayB4ZW5fICMj
IG4gKngsIGsKICAqCiAgKiBSZXR1cm46IE51bWJlciBvZiBhcmd1bWVudHMg
d2hpY2ggd2VyZSBhY3R1YWxseSB0cmFuc2xhdGVkLgogICovCi1pbnQgaHlw
ZXJjYWxsX3hsYXRfY29udGludWF0aW9uKHVuc2lnbmVkIGludCAqaWQsIHVu
c2lnbmVkIGludCBtYXNrLCAuLi4pOworaW50IGh5cGVyY2FsbF94bGF0X2Nv
bnRpbnVhdGlvbih1bnNpZ25lZCBpbnQgKmlkLCB1bnNpZ25lZCBpbnQgbnIs
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGlu
dCBtYXNrLCAuLi4pOwogCiAvKiBJbi1wbGFjZSB0cmFuc2xhdGlvbiBmdW5j
dG9uczogKi8KIHN0cnVjdCBzdGFydF9pbmZvOwo=

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Thu Nov 27 12:09:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12:09:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtxse-0002nM-DV; Thu, 27 Nov 2014 12:09:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xtxsc-0002mo-Sz; Thu, 27 Nov 2014 12:09:03 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	C5/08-31453-D5417745; Thu, 27 Nov 2014 12:09:01 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417090139!10757292!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32394 invoked from network); 27 Nov 2014 12:09:00 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Nov 2014 12:09:00 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XtxsT-0003WD-CG; Thu, 27 Nov 2014 12:08:53 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XtxsT-0000TV-4i; Thu, 27 Nov 2014 12:08:53 +0000
Date: Thu, 27 Nov 2014 12:08:53 +0000
Message-Id: <E1XtxsT-0000TV-4i@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 112 (CVE-2014-8867) -
 Insufficient bounding of "REP MOVS" to MMIO emulated inside 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2014-8867 / XSA-112
                              version 5

  Insufficient bounding of "REP MOVS" to MMIO emulated inside the hypervisor

UPDATES IN VERSION 5
====================

Public release.

ISSUE DESCRIPTION
=================

Acceleration support for the "REP MOVS" instruction, when the first
iteration accesses memory mapped I/O emulated internally in the
hypervisor, incorrectly assumes that the whole range accessed is
handled by the same hypervisor sub-component.

IMPACT
======

A buggy or malicious HVM guest can crash the host.

VULNERABLE SYSTEMS
==================

Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
Older versions have not been inspected.  ARM systems are not vulnerable.

MITIGATION
==========

Running only PV guests will avoid this issue.

There is no mitigation available for HVM guests.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa112-unstable.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x
xsa112-4.2.patch             Xen 4.2.x

$ sha256sum xsa112*.patch
cf01a1acd258e7cbb3586e543ba3668c1ee7fb05cba19b8b5369a3e101a2288f  xsa112-4.2.patch
cc39a4cdcb52929ed36ab696807d2405aa552177a6f029d8a1a52041ca1ed519  xsa112.patch
$

We have been told that this patch is not sufficient on Xen 3.3.x and
earlier without also backporting b1b6362f (git commit id).

Note that while we are happy to share information we receive about
earlier Xen versions, the earliest Xen branch for which the Xen
Project offers security support is 4.2.x.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUdwoNAAoJEIP+FMlX6CvZfekIAMBq3ynRyuyqvukMhSBaFj2O
SBX747HJPKRmoODGZGe9EJ0pAJhckQ00RaKFulxSLzFeu4Oi6M3GrvNCvST0sR54
bLTmeNeBOhLef4ylDqAWOSY4C7AJW/jC1ngtSy3wd6zuwFD0bzPYb7nk94PD32ie
9LYTt+FSkoo/3j3IviCqNVXTlMmhmdjP0U3+xXgxQZ9y47zTT8gsX4KoplC/i1Wq
uhla/ZYI+Ro/ejYVHsKDDhfA1mgAGDoOLhmNEBLHPzTyGs4VOSaXzX7wce8JWpBi
oXdnN5HW80mmkZ6qI42/bnvpSHTqm+QVFD0v1Uz0cSrBYJGq6LULBAmaJHGldDA=
=8eF1
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa112-4.2.patch"
Content-Disposition: attachment; filename="xsa112-4.2.patch"
Content-Transfer-Encoding: base64

eDg2L0hWTTogY29uZmluZSBpbnRlcm5hbGx5IGhhbmRsZWQgTU1JTyB0byBz
b2xpdGFyeSByZWdpb25zCgpXaGlsZSBpdCBpcyBnZW5lcmFsbHkgd3Jvbmcg
dG8gY3Jvc3MgcmVnaW9uIGJvdW5kYXJpZXMgd2hlbiBkZWFsaW5nCndpdGgg
TU1JTyBhY2Nlc3NlcyBvZiByZXBlYXRlZCBzdHJpbmcgaW5zdHJ1Y3Rpb25z
IChjdXJyZW50bHkgb25seQpNT1ZTKSBhcyB0aGF0IHdvdWxkIGRvIHRoaW5n
cyBhIGd1ZXN0IGRvZXNuJ3QgZXhwZWN0IChsZWF2aW5nIGFzaWRlCnRoYXQg
bm9uZSBvZiB0aGVzZSByZWdpb25zIHdvdWxkIG5vcm1hbGx5IGJlIGFjY2Vz
c2VkIHdpdGggcmVwZWF0ZWQKc3RyaW5nIGluc3RydWN0aW9ucyBpbiB0aGUg
Zmlyc3QgcGxhY2UpLCB0aGlzIGlzIGV2ZW4gbW9yZSBvZiBhIHByb2JsZW0K
Zm9yIGFsbCB2aXJ0dWFsIE1TSS1YIHBhZ2UgYWNjZXNzZXMgKGJvdGggbXNp
eHRibF97cmVhZCx3cml0ZX0oKSBjYW4gYmUKbWFkZSBkZXJlZmVyZW5jZSBO
VUxMICJlbnRyeSIgcG9pbnRlcnMgdGhpcyB3YXkpIGFzIHdlbGwgYXMgdW5k
ZXJzaXplZAooMS0gb3IgMi1ieXRlKSBMQVBJQyB3cml0ZXMgKGNhdXNpbmcg
dmxhcGljX3JlYWRfYWxpZ25lZCgpIHRvIGFjY2VzcwpzcGFjZSBiZXlvbmQg
dGhlIG9uZSBtZW1vcnkgcGFnZSBzZXQgdXAgZm9yIGhvbGRpbmcgTEFQSUMg
cmVnaXN0ZXIKdmFsdWVzKS4KClNpbmNlIHRob3NlIGZ1bmN0aW9ucyB2YWxp
ZGx5IGFzc3VtZSB0byBiZSBjYWxsZWQgb25seSB3aXRoIGFkZHJlc3Nlcwp0
aGVpciByZXNwZWN0aXZlIGNoZWNraW5nIGZ1bmN0aW9ucyBpbmRpY2F0ZWQg
dG8gYmUgb2theSwgaXQgaXMgZ2VuZXJpYwpjb2RlIHRoYXQgbmVlZHMgdG8g
YmUgZml4ZWQgdG8gY2xpcCB0aGUgcmVwZXRpdGlvbiBjb3VudC4KClRvIGJl
IG9uIHRoZSBzYWZlIHNpZGUgKGFuZCBjb25zaXN0ZW50KSwgYWxzbyBkbyB0
aGUgc2FtZSBmb3IgYnVmZmVyZWQKSS9PIGludGVyY2VwdHMsIGV2ZW4gaWYg
dGhlaXIgb25seSBjbGllbnQgKHN0ZHZnYSkgZG9lc24ndCBwdXQgdGhlCmh5
cGVydmlzb3IgYXQgcmlzayAoaS5lLiAib25seSIgZ3Vlc3QgbWlzYmVoYXZp
b3Igd291bGQgcmVzdWx0KS4KClRoaXMgaXMgQ1ZFLTIwMTQtODg2NyAvIFhT
QS0xMTIuCgpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA
c3VzZS5jb20+ClJldmlld2VkLWJ5OiBUaW0gRGVlZ2FuIDx0aW1AeGVuLm9y
Zz4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vaW50ZXJjZXB0LmMKKysrIGIv
eGVuL2FyY2gveDg2L2h2bS9pbnRlcmNlcHQuYwpAQCAtMTMxLDExICsxMzEs
MjQgQEAgaW50IGh2bV9tbWlvX2ludGVyY2VwdChpb3JlcV90ICpwKQogICAg
IGludCBpOwogCiAgICAgZm9yICggaSA9IDA7IGkgPCBIVk1fTU1JT19IQU5E
TEVSX05SOyBpKysgKQotICAgICAgICBpZiAoIGh2bV9tbWlvX2hhbmRsZXJz
W2ldLT5jaGVja19oYW5kbGVyKHYsIHAtPmFkZHIpICkKKyAgICB7CisgICAg
ICAgIGh2bV9tbWlvX2NoZWNrX3QgY2hlY2tfaGFuZGxlciA9CisgICAgICAg
ICAgICBodm1fbW1pb19oYW5kbGVyc1tpXS0+Y2hlY2tfaGFuZGxlcjsKKwor
ICAgICAgICBpZiAoIGNoZWNrX2hhbmRsZXIodiwgcC0+YWRkcikgKQorICAg
ICAgICB7CisgICAgICAgICAgICBpZiAoIHVubGlrZWx5KHAtPmNvdW50ID4g
MSkgJiYKKyAgICAgICAgICAgICAgICAgIWNoZWNrX2hhbmRsZXIodiwgdW5s
aWtlbHkocC0+ZGYpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgID8gcC0+YWRkciAtIChwLT5jb3VudCAtIDFMTCkgKiBwLT5zaXplCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDogcC0+YWRkciAr
IChwLT5jb3VudCAtIDFMTCkgKiBwLT5zaXplKSApCisgICAgICAgICAgICAg
ICAgcC0+Y291bnQgPSAxOworCiAgICAgICAgICAgICByZXR1cm4gaHZtX21t
aW9fYWNjZXNzKAogICAgICAgICAgICAgICAgIHYsIHAsCiAgICAgICAgICAg
ICAgICAgaHZtX21taW9faGFuZGxlcnNbaV0tPnJlYWRfaGFuZGxlciwKICAg
ICAgICAgICAgICAgICBodm1fbW1pb19oYW5kbGVyc1tpXS0+d3JpdGVfaGFu
ZGxlcik7CisgICAgICAgIH0KKyAgICB9CiAKICAgICByZXR1cm4gWDg2RU1V
TF9VTkhBTkRMRUFCTEU7CiB9CkBAIC0yNDMsNiArMjU2LDEzIEBAIGludCBo
dm1faW9faW50ZXJjZXB0KGlvcmVxX3QgKnAsIGludCB0eXAKICAgICAgICAg
ICAgIGlmICggdHlwZSA9PSBIVk1fUE9SVElPICkKICAgICAgICAgICAgICAg
ICByZXR1cm4gcHJvY2Vzc19wb3J0aW9faW50ZXJjZXB0KAogICAgICAgICAg
ICAgICAgICAgICBoYW5kbGVyLT5oZGxfbGlzdFtpXS5hY3Rpb24ucG9ydGlv
LCBwKTsKKworICAgICAgICAgICAgaWYgKCB1bmxpa2VseShwLT5jb3VudCA+
IDEpICYmCisgICAgICAgICAgICAgICAgICh1bmxpa2VseShwLT5kZikKKyAg
ICAgICAgICAgICAgICAgID8gcC0+YWRkciAtIChwLT5jb3VudCAtIDFMTCkg
KiBwLT5zaXplIDwgYWRkcgorICAgICAgICAgICAgICAgICAgOiBwLT5hZGRy
ICsgcC0+Y291bnQgKiAxTEwgKiBwLT5zaXplIC0gMSA+PSBhZGRyICsgc2l6
ZSkgKQorICAgICAgICAgICAgICAgIHAtPmNvdW50ID0gMTsKKwogICAgICAg
ICAgICAgcmV0dXJuIGhhbmRsZXItPmhkbF9saXN0W2ldLmFjdGlvbi5tbWlv
KHApOwogICAgICAgICB9CiAgICAgfQotLS0gYS94ZW4vYXJjaC94ODYvaHZt
L3Ztc2kuYworKysgYi94ZW4vYXJjaC94ODYvaHZtL3Ztc2kuYwpAQCAtMjM2
LDYgKzIzNiw4IEBAIHN0YXRpYyBpbnQgbXNpeHRibF9yZWFkKAogICAgIHJj
dV9yZWFkX2xvY2soJm1zaXh0YmxfcmN1X2xvY2spOwogCiAgICAgZW50cnkg
PSBtc2l4dGJsX2ZpbmRfZW50cnkodiwgYWRkcmVzcyk7CisgICAgaWYgKCAh
ZW50cnkgKQorICAgICAgICBnb3RvIG91dDsKICAgICBvZmZzZXQgPSBhZGRy
ZXNzICYgKFBDSV9NU0lYX0VOVFJZX1NJWkUgLSAxKTsKIAogICAgIGlmICgg
b2Zmc2V0ICE9IFBDSV9NU0lYX0VOVFJZX1ZFQ1RPUl9DVFJMX09GRlNFVCAp
CkBAIC0yNzgsNiArMjgwLDggQEAgc3RhdGljIGludCBtc2l4dGJsX3dyaXRl
KHN0cnVjdCB2Y3B1ICp2LAogICAgIHJjdV9yZWFkX2xvY2soJm1zaXh0Ymxf
cmN1X2xvY2spOwogCiAgICAgZW50cnkgPSBtc2l4dGJsX2ZpbmRfZW50cnko
diwgYWRkcmVzcyk7CisgICAgaWYgKCAhZW50cnkgKQorICAgICAgICBnb3Rv
IG91dDsKICAgICBucl9lbnRyeSA9IChhZGRyZXNzIC0gZW50cnktPmd0YWJs
ZSkgLyBQQ0lfTVNJWF9FTlRSWV9TSVpFOwogCiAgICAgb2Zmc2V0ID0gYWRk
cmVzcyAmIChQQ0lfTVNJWF9FTlRSWV9TSVpFIC0gMSk7Cg==

--=separator
Content-Type: application/octet-stream; name="xsa112.patch"
Content-Disposition: attachment; filename="xsa112.patch"
Content-Transfer-Encoding: base64

eDg2L0hWTTogY29uZmluZSBpbnRlcm5hbGx5IGhhbmRsZWQgTU1JTyB0byBz
b2xpdGFyeSByZWdpb25zCgpXaGlsZSBpdCBpcyBnZW5lcmFsbHkgd3Jvbmcg
dG8gY3Jvc3MgcmVnaW9uIGJvdW5kYXJpZXMgd2hlbiBkZWFsaW5nCndpdGgg
TU1JTyBhY2Nlc3NlcyBvZiByZXBlYXRlZCBzdHJpbmcgaW5zdHJ1Y3Rpb25z
IChjdXJyZW50bHkgb25seQpNT1ZTKSBhcyB0aGF0IHdvdWxkIGRvIHRoaW5n
cyBhIGd1ZXN0IGRvZXNuJ3QgZXhwZWN0IChsZWF2aW5nIGFzaWRlCnRoYXQg
bm9uZSBvZiB0aGVzZSByZWdpb25zIHdvdWxkIG5vcm1hbGx5IGJlIGFjY2Vz
c2VkIHdpdGggcmVwZWF0ZWQKc3RyaW5nIGluc3RydWN0aW9ucyBpbiB0aGUg
Zmlyc3QgcGxhY2UpLCB0aGlzIGlzIGV2ZW4gbW9yZSBvZiBhIHByb2JsZW0K
Zm9yIGFsbCB2aXJ0dWFsIE1TSS1YIHBhZ2UgYWNjZXNzZXMgKGJvdGggbXNp
eHRibF97cmVhZCx3cml0ZX0oKSBjYW4gYmUKbWFkZSBkZXJlZmVyZW5jZSBO
VUxMICJlbnRyeSIgcG9pbnRlcnMgdGhpcyB3YXkpIGFzIHdlbGwgYXMgdW5k
ZXJzaXplZAooMS0gb3IgMi1ieXRlKSBMQVBJQyB3cml0ZXMgKGNhdXNpbmcg
dmxhcGljX3JlYWRfYWxpZ25lZCgpIHRvIGFjY2VzcwpzcGFjZSBiZXlvbmQg
dGhlIG9uZSBtZW1vcnkgcGFnZSBzZXQgdXAgZm9yIGhvbGRpbmcgTEFQSUMg
cmVnaXN0ZXIKdmFsdWVzKS4KClNpbmNlIHRob3NlIGZ1bmN0aW9ucyB2YWxp
ZGx5IGFzc3VtZSB0byBiZSBjYWxsZWQgb25seSB3aXRoIGFkZHJlc3Nlcwp0
aGVpciByZXNwZWN0aXZlIGNoZWNraW5nIGZ1bmN0aW9ucyBpbmRpY2F0ZWQg
dG8gYmUgb2theSwgaXQgaXMgZ2VuZXJpYwpjb2RlIHRoYXQgbmVlZHMgdG8g
YmUgZml4ZWQgdG8gY2xpcCB0aGUgcmVwZXRpdGlvbiBjb3VudC4KClRvIGJl
IG9uIHRoZSBzYWZlIHNpZGUgKGFuZCBjb25zaXN0ZW50KSwgYWxzbyBkbyB0
aGUgc2FtZSBmb3IgYnVmZmVyZWQKSS9PIGludGVyY2VwdHMsIGV2ZW4gaWYg
dGhlaXIgb25seSBjbGllbnQgKHN0ZHZnYSkgZG9lc24ndCBwdXQgdGhlCmh5
cGVydmlzb3IgYXQgcmlzayAoaS5lLiAib25seSIgZ3Vlc3QgbWlzYmVoYXZp
b3Igd291bGQgcmVzdWx0KS4KClRoaXMgaXMgQ1ZFLTIwMTQtODg2NyAvIFhT
QS0xMTIuCgpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA
c3VzZS5jb20+ClJldmlld2VkLWJ5OiBUaW0gRGVlZ2FuIDx0aW1AeGVuLm9y
Zz4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vaW50ZXJjZXB0LmMKKysrIGIv
eGVuL2FyY2gveDg2L2h2bS9pbnRlcmNlcHQuYwpAQCAtMTgxLDExICsxODEs
MjQgQEAgaW50IGh2bV9tbWlvX2ludGVyY2VwdChpb3JlcV90ICpwKQogICAg
IGludCBpOwogCiAgICAgZm9yICggaSA9IDA7IGkgPCBIVk1fTU1JT19IQU5E
TEVSX05SOyBpKysgKQotICAgICAgICBpZiAoIGh2bV9tbWlvX2hhbmRsZXJz
W2ldLT5jaGVja19oYW5kbGVyKHYsIHAtPmFkZHIpICkKKyAgICB7CisgICAg
ICAgIGh2bV9tbWlvX2NoZWNrX3QgY2hlY2tfaGFuZGxlciA9CisgICAgICAg
ICAgICBodm1fbW1pb19oYW5kbGVyc1tpXS0+Y2hlY2tfaGFuZGxlcjsKKwor
ICAgICAgICBpZiAoIGNoZWNrX2hhbmRsZXIodiwgcC0+YWRkcikgKQorICAg
ICAgICB7CisgICAgICAgICAgICBpZiAoIHVubGlrZWx5KHAtPmNvdW50ID4g
MSkgJiYKKyAgICAgICAgICAgICAgICAgIWNoZWNrX2hhbmRsZXIodiwgdW5s
aWtlbHkocC0+ZGYpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgID8gcC0+YWRkciAtIChwLT5jb3VudCAtIDFMKSAqIHAtPnNpemUKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOiBwLT5hZGRyICsg
KHAtPmNvdW50IC0gMUwpICogcC0+c2l6ZSkgKQorICAgICAgICAgICAgICAg
IHAtPmNvdW50ID0gMTsKKwogICAgICAgICAgICAgcmV0dXJuIGh2bV9tbWlv
X2FjY2VzcygKICAgICAgICAgICAgICAgICB2LCBwLAogICAgICAgICAgICAg
ICAgIGh2bV9tbWlvX2hhbmRsZXJzW2ldLT5yZWFkX2hhbmRsZXIsCiAgICAg
ICAgICAgICAgICAgaHZtX21taW9faGFuZGxlcnNbaV0tPndyaXRlX2hhbmRs
ZXIpOworICAgICAgICB9CisgICAgfQogCiAgICAgcmV0dXJuIFg4NkVNVUxf
VU5IQU5ETEVBQkxFOwogfQpAQCAtMzQyLDYgKzM1NSwxMyBAQCBpbnQgaHZt
X2lvX2ludGVyY2VwdChpb3JlcV90ICpwLCBpbnQgdHlwCiAgICAgICAgICAg
ICBpZiAoIHR5cGUgPT0gSFZNX1BPUlRJTyApCiAgICAgICAgICAgICAgICAg
cmV0dXJuIHByb2Nlc3NfcG9ydGlvX2ludGVyY2VwdCgKICAgICAgICAgICAg
ICAgICAgICAgaGFuZGxlci0+aGRsX2xpc3RbaV0uYWN0aW9uLnBvcnRpbywg
cCk7CisKKyAgICAgICAgICAgIGlmICggdW5saWtlbHkocC0+Y291bnQgPiAx
KSAmJgorICAgICAgICAgICAgICAgICAodW5saWtlbHkocC0+ZGYpCisgICAg
ICAgICAgICAgICAgICA/IHAtPmFkZHIgLSAocC0+Y291bnQgLSAxTCkgKiBw
LT5zaXplIDwgYWRkcgorICAgICAgICAgICAgICAgICAgOiBwLT5hZGRyICsg
cC0+Y291bnQgKiAxTCAqIHAtPnNpemUgLSAxID49IGFkZHIgKyBzaXplKSAp
CisgICAgICAgICAgICAgICAgcC0+Y291bnQgPSAxOworCiAgICAgICAgICAg
ICByZXR1cm4gaGFuZGxlci0+aGRsX2xpc3RbaV0uYWN0aW9uLm1taW8ocCk7
CiAgICAgICAgIH0KICAgICB9Ci0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdm1z
aS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9odm0vdm1zaS5jCkBAIC0yMjYsNiAr
MjI2LDggQEAgc3RhdGljIGludCBtc2l4dGJsX3JlYWQoCiAgICAgcmN1X3Jl
YWRfbG9jaygmbXNpeHRibF9yY3VfbG9jayk7CiAKICAgICBlbnRyeSA9IG1z
aXh0YmxfZmluZF9lbnRyeSh2LCBhZGRyZXNzKTsKKyAgICBpZiAoICFlbnRy
eSApCisgICAgICAgIGdvdG8gb3V0OwogICAgIG9mZnNldCA9IGFkZHJlc3Mg
JiAoUENJX01TSVhfRU5UUllfU0laRSAtIDEpOwogCiAgICAgaWYgKCBvZmZz
ZXQgIT0gUENJX01TSVhfRU5UUllfVkVDVE9SX0NUUkxfT0ZGU0VUICkKQEAg
LTI2OCw2ICsyNzAsOCBAQCBzdGF0aWMgaW50IG1zaXh0Ymxfd3JpdGUoc3Ry
dWN0IHZjcHUgKnYsCiAgICAgcmN1X3JlYWRfbG9jaygmbXNpeHRibF9yY3Vf
bG9jayk7CiAKICAgICBlbnRyeSA9IG1zaXh0YmxfZmluZF9lbnRyeSh2LCBh
ZGRyZXNzKTsKKyAgICBpZiAoICFlbnRyeSApCisgICAgICAgIGdvdG8gb3V0
OwogICAgIG5yX2VudHJ5ID0gKGFkZHJlc3MgLSBlbnRyeS0+Z3RhYmxlKSAv
IFBDSV9NU0lYX0VOVFJZX1NJWkU7CiAKICAgICBvZmZzZXQgPSBhZGRyZXNz
ICYgKFBDSV9NU0lYX0VOVFJZX1NJWkUgLSAxKTsK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Thu Nov 27 12:09:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12:09:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xtxse-0002nM-DV; Thu, 27 Nov 2014 12:09:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xtxsc-0002mo-Sz; Thu, 27 Nov 2014 12:09:03 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	C5/08-31453-D5417745; Thu, 27 Nov 2014 12:09:01 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417090139!10757292!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32394 invoked from network); 27 Nov 2014 12:09:00 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Nov 2014 12:09:00 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XtxsT-0003WD-CG; Thu, 27 Nov 2014 12:08:53 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1XtxsT-0000TV-4i; Thu, 27 Nov 2014 12:08:53 +0000
Date: Thu, 27 Nov 2014 12:08:53 +0000
Message-Id: <E1XtxsT-0000TV-4i@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 112 (CVE-2014-8867) -
 Insufficient bounding of "REP MOVS" to MMIO emulated inside 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2014-8867 / XSA-112
                              version 5

  Insufficient bounding of "REP MOVS" to MMIO emulated inside the hypervisor

UPDATES IN VERSION 5
====================

Public release.

ISSUE DESCRIPTION
=================

Acceleration support for the "REP MOVS" instruction, when the first
iteration accesses memory mapped I/O emulated internally in the
hypervisor, incorrectly assumes that the whole range accessed is
handled by the same hypervisor sub-component.

IMPACT
======

A buggy or malicious HVM guest can crash the host.

VULNERABLE SYSTEMS
==================

Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
Older versions have not been inspected.  ARM systems are not vulnerable.

MITIGATION
==========

Running only PV guests will avoid this issue.

There is no mitigation available for HVM guests.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa112-unstable.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x
xsa112-4.2.patch             Xen 4.2.x

$ sha256sum xsa112*.patch
cf01a1acd258e7cbb3586e543ba3668c1ee7fb05cba19b8b5369a3e101a2288f  xsa112-4.2.patch
cc39a4cdcb52929ed36ab696807d2405aa552177a6f029d8a1a52041ca1ed519  xsa112.patch
$

We have been told that this patch is not sufficient on Xen 3.3.x and
earlier without also backporting b1b6362f (git commit id).

Note that while we are happy to share information we receive about
earlier Xen versions, the earliest Xen branch for which the Xen
Project offers security support is 4.2.x.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUdwoNAAoJEIP+FMlX6CvZfekIAMBq3ynRyuyqvukMhSBaFj2O
SBX747HJPKRmoODGZGe9EJ0pAJhckQ00RaKFulxSLzFeu4Oi6M3GrvNCvST0sR54
bLTmeNeBOhLef4ylDqAWOSY4C7AJW/jC1ngtSy3wd6zuwFD0bzPYb7nk94PD32ie
9LYTt+FSkoo/3j3IviCqNVXTlMmhmdjP0U3+xXgxQZ9y47zTT8gsX4KoplC/i1Wq
uhla/ZYI+Ro/ejYVHsKDDhfA1mgAGDoOLhmNEBLHPzTyGs4VOSaXzX7wce8JWpBi
oXdnN5HW80mmkZ6qI42/bnvpSHTqm+QVFD0v1Uz0cSrBYJGq6LULBAmaJHGldDA=
=8eF1
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa112-4.2.patch"
Content-Disposition: attachment; filename="xsa112-4.2.patch"
Content-Transfer-Encoding: base64

eDg2L0hWTTogY29uZmluZSBpbnRlcm5hbGx5IGhhbmRsZWQgTU1JTyB0byBz
b2xpdGFyeSByZWdpb25zCgpXaGlsZSBpdCBpcyBnZW5lcmFsbHkgd3Jvbmcg
dG8gY3Jvc3MgcmVnaW9uIGJvdW5kYXJpZXMgd2hlbiBkZWFsaW5nCndpdGgg
TU1JTyBhY2Nlc3NlcyBvZiByZXBlYXRlZCBzdHJpbmcgaW5zdHJ1Y3Rpb25z
IChjdXJyZW50bHkgb25seQpNT1ZTKSBhcyB0aGF0IHdvdWxkIGRvIHRoaW5n
cyBhIGd1ZXN0IGRvZXNuJ3QgZXhwZWN0IChsZWF2aW5nIGFzaWRlCnRoYXQg
bm9uZSBvZiB0aGVzZSByZWdpb25zIHdvdWxkIG5vcm1hbGx5IGJlIGFjY2Vz
c2VkIHdpdGggcmVwZWF0ZWQKc3RyaW5nIGluc3RydWN0aW9ucyBpbiB0aGUg
Zmlyc3QgcGxhY2UpLCB0aGlzIGlzIGV2ZW4gbW9yZSBvZiBhIHByb2JsZW0K
Zm9yIGFsbCB2aXJ0dWFsIE1TSS1YIHBhZ2UgYWNjZXNzZXMgKGJvdGggbXNp
eHRibF97cmVhZCx3cml0ZX0oKSBjYW4gYmUKbWFkZSBkZXJlZmVyZW5jZSBO
VUxMICJlbnRyeSIgcG9pbnRlcnMgdGhpcyB3YXkpIGFzIHdlbGwgYXMgdW5k
ZXJzaXplZAooMS0gb3IgMi1ieXRlKSBMQVBJQyB3cml0ZXMgKGNhdXNpbmcg
dmxhcGljX3JlYWRfYWxpZ25lZCgpIHRvIGFjY2VzcwpzcGFjZSBiZXlvbmQg
dGhlIG9uZSBtZW1vcnkgcGFnZSBzZXQgdXAgZm9yIGhvbGRpbmcgTEFQSUMg
cmVnaXN0ZXIKdmFsdWVzKS4KClNpbmNlIHRob3NlIGZ1bmN0aW9ucyB2YWxp
ZGx5IGFzc3VtZSB0byBiZSBjYWxsZWQgb25seSB3aXRoIGFkZHJlc3Nlcwp0
aGVpciByZXNwZWN0aXZlIGNoZWNraW5nIGZ1bmN0aW9ucyBpbmRpY2F0ZWQg
dG8gYmUgb2theSwgaXQgaXMgZ2VuZXJpYwpjb2RlIHRoYXQgbmVlZHMgdG8g
YmUgZml4ZWQgdG8gY2xpcCB0aGUgcmVwZXRpdGlvbiBjb3VudC4KClRvIGJl
IG9uIHRoZSBzYWZlIHNpZGUgKGFuZCBjb25zaXN0ZW50KSwgYWxzbyBkbyB0
aGUgc2FtZSBmb3IgYnVmZmVyZWQKSS9PIGludGVyY2VwdHMsIGV2ZW4gaWYg
dGhlaXIgb25seSBjbGllbnQgKHN0ZHZnYSkgZG9lc24ndCBwdXQgdGhlCmh5
cGVydmlzb3IgYXQgcmlzayAoaS5lLiAib25seSIgZ3Vlc3QgbWlzYmVoYXZp
b3Igd291bGQgcmVzdWx0KS4KClRoaXMgaXMgQ1ZFLTIwMTQtODg2NyAvIFhT
QS0xMTIuCgpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA
c3VzZS5jb20+ClJldmlld2VkLWJ5OiBUaW0gRGVlZ2FuIDx0aW1AeGVuLm9y
Zz4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vaW50ZXJjZXB0LmMKKysrIGIv
eGVuL2FyY2gveDg2L2h2bS9pbnRlcmNlcHQuYwpAQCAtMTMxLDExICsxMzEs
MjQgQEAgaW50IGh2bV9tbWlvX2ludGVyY2VwdChpb3JlcV90ICpwKQogICAg
IGludCBpOwogCiAgICAgZm9yICggaSA9IDA7IGkgPCBIVk1fTU1JT19IQU5E
TEVSX05SOyBpKysgKQotICAgICAgICBpZiAoIGh2bV9tbWlvX2hhbmRsZXJz
W2ldLT5jaGVja19oYW5kbGVyKHYsIHAtPmFkZHIpICkKKyAgICB7CisgICAg
ICAgIGh2bV9tbWlvX2NoZWNrX3QgY2hlY2tfaGFuZGxlciA9CisgICAgICAg
ICAgICBodm1fbW1pb19oYW5kbGVyc1tpXS0+Y2hlY2tfaGFuZGxlcjsKKwor
ICAgICAgICBpZiAoIGNoZWNrX2hhbmRsZXIodiwgcC0+YWRkcikgKQorICAg
ICAgICB7CisgICAgICAgICAgICBpZiAoIHVubGlrZWx5KHAtPmNvdW50ID4g
MSkgJiYKKyAgICAgICAgICAgICAgICAgIWNoZWNrX2hhbmRsZXIodiwgdW5s
aWtlbHkocC0+ZGYpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgID8gcC0+YWRkciAtIChwLT5jb3VudCAtIDFMTCkgKiBwLT5zaXplCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDogcC0+YWRkciAr
IChwLT5jb3VudCAtIDFMTCkgKiBwLT5zaXplKSApCisgICAgICAgICAgICAg
ICAgcC0+Y291bnQgPSAxOworCiAgICAgICAgICAgICByZXR1cm4gaHZtX21t
aW9fYWNjZXNzKAogICAgICAgICAgICAgICAgIHYsIHAsCiAgICAgICAgICAg
ICAgICAgaHZtX21taW9faGFuZGxlcnNbaV0tPnJlYWRfaGFuZGxlciwKICAg
ICAgICAgICAgICAgICBodm1fbW1pb19oYW5kbGVyc1tpXS0+d3JpdGVfaGFu
ZGxlcik7CisgICAgICAgIH0KKyAgICB9CiAKICAgICByZXR1cm4gWDg2RU1V
TF9VTkhBTkRMRUFCTEU7CiB9CkBAIC0yNDMsNiArMjU2LDEzIEBAIGludCBo
dm1faW9faW50ZXJjZXB0KGlvcmVxX3QgKnAsIGludCB0eXAKICAgICAgICAg
ICAgIGlmICggdHlwZSA9PSBIVk1fUE9SVElPICkKICAgICAgICAgICAgICAg
ICByZXR1cm4gcHJvY2Vzc19wb3J0aW9faW50ZXJjZXB0KAogICAgICAgICAg
ICAgICAgICAgICBoYW5kbGVyLT5oZGxfbGlzdFtpXS5hY3Rpb24ucG9ydGlv
LCBwKTsKKworICAgICAgICAgICAgaWYgKCB1bmxpa2VseShwLT5jb3VudCA+
IDEpICYmCisgICAgICAgICAgICAgICAgICh1bmxpa2VseShwLT5kZikKKyAg
ICAgICAgICAgICAgICAgID8gcC0+YWRkciAtIChwLT5jb3VudCAtIDFMTCkg
KiBwLT5zaXplIDwgYWRkcgorICAgICAgICAgICAgICAgICAgOiBwLT5hZGRy
ICsgcC0+Y291bnQgKiAxTEwgKiBwLT5zaXplIC0gMSA+PSBhZGRyICsgc2l6
ZSkgKQorICAgICAgICAgICAgICAgIHAtPmNvdW50ID0gMTsKKwogICAgICAg
ICAgICAgcmV0dXJuIGhhbmRsZXItPmhkbF9saXN0W2ldLmFjdGlvbi5tbWlv
KHApOwogICAgICAgICB9CiAgICAgfQotLS0gYS94ZW4vYXJjaC94ODYvaHZt
L3Ztc2kuYworKysgYi94ZW4vYXJjaC94ODYvaHZtL3Ztc2kuYwpAQCAtMjM2
LDYgKzIzNiw4IEBAIHN0YXRpYyBpbnQgbXNpeHRibF9yZWFkKAogICAgIHJj
dV9yZWFkX2xvY2soJm1zaXh0YmxfcmN1X2xvY2spOwogCiAgICAgZW50cnkg
PSBtc2l4dGJsX2ZpbmRfZW50cnkodiwgYWRkcmVzcyk7CisgICAgaWYgKCAh
ZW50cnkgKQorICAgICAgICBnb3RvIG91dDsKICAgICBvZmZzZXQgPSBhZGRy
ZXNzICYgKFBDSV9NU0lYX0VOVFJZX1NJWkUgLSAxKTsKIAogICAgIGlmICgg
b2Zmc2V0ICE9IFBDSV9NU0lYX0VOVFJZX1ZFQ1RPUl9DVFJMX09GRlNFVCAp
CkBAIC0yNzgsNiArMjgwLDggQEAgc3RhdGljIGludCBtc2l4dGJsX3dyaXRl
KHN0cnVjdCB2Y3B1ICp2LAogICAgIHJjdV9yZWFkX2xvY2soJm1zaXh0Ymxf
cmN1X2xvY2spOwogCiAgICAgZW50cnkgPSBtc2l4dGJsX2ZpbmRfZW50cnko
diwgYWRkcmVzcyk7CisgICAgaWYgKCAhZW50cnkgKQorICAgICAgICBnb3Rv
IG91dDsKICAgICBucl9lbnRyeSA9IChhZGRyZXNzIC0gZW50cnktPmd0YWJs
ZSkgLyBQQ0lfTVNJWF9FTlRSWV9TSVpFOwogCiAgICAgb2Zmc2V0ID0gYWRk
cmVzcyAmIChQQ0lfTVNJWF9FTlRSWV9TSVpFIC0gMSk7Cg==

--=separator
Content-Type: application/octet-stream; name="xsa112.patch"
Content-Disposition: attachment; filename="xsa112.patch"
Content-Transfer-Encoding: base64

eDg2L0hWTTogY29uZmluZSBpbnRlcm5hbGx5IGhhbmRsZWQgTU1JTyB0byBz
b2xpdGFyeSByZWdpb25zCgpXaGlsZSBpdCBpcyBnZW5lcmFsbHkgd3Jvbmcg
dG8gY3Jvc3MgcmVnaW9uIGJvdW5kYXJpZXMgd2hlbiBkZWFsaW5nCndpdGgg
TU1JTyBhY2Nlc3NlcyBvZiByZXBlYXRlZCBzdHJpbmcgaW5zdHJ1Y3Rpb25z
IChjdXJyZW50bHkgb25seQpNT1ZTKSBhcyB0aGF0IHdvdWxkIGRvIHRoaW5n
cyBhIGd1ZXN0IGRvZXNuJ3QgZXhwZWN0IChsZWF2aW5nIGFzaWRlCnRoYXQg
bm9uZSBvZiB0aGVzZSByZWdpb25zIHdvdWxkIG5vcm1hbGx5IGJlIGFjY2Vz
c2VkIHdpdGggcmVwZWF0ZWQKc3RyaW5nIGluc3RydWN0aW9ucyBpbiB0aGUg
Zmlyc3QgcGxhY2UpLCB0aGlzIGlzIGV2ZW4gbW9yZSBvZiBhIHByb2JsZW0K
Zm9yIGFsbCB2aXJ0dWFsIE1TSS1YIHBhZ2UgYWNjZXNzZXMgKGJvdGggbXNp
eHRibF97cmVhZCx3cml0ZX0oKSBjYW4gYmUKbWFkZSBkZXJlZmVyZW5jZSBO
VUxMICJlbnRyeSIgcG9pbnRlcnMgdGhpcyB3YXkpIGFzIHdlbGwgYXMgdW5k
ZXJzaXplZAooMS0gb3IgMi1ieXRlKSBMQVBJQyB3cml0ZXMgKGNhdXNpbmcg
dmxhcGljX3JlYWRfYWxpZ25lZCgpIHRvIGFjY2VzcwpzcGFjZSBiZXlvbmQg
dGhlIG9uZSBtZW1vcnkgcGFnZSBzZXQgdXAgZm9yIGhvbGRpbmcgTEFQSUMg
cmVnaXN0ZXIKdmFsdWVzKS4KClNpbmNlIHRob3NlIGZ1bmN0aW9ucyB2YWxp
ZGx5IGFzc3VtZSB0byBiZSBjYWxsZWQgb25seSB3aXRoIGFkZHJlc3Nlcwp0
aGVpciByZXNwZWN0aXZlIGNoZWNraW5nIGZ1bmN0aW9ucyBpbmRpY2F0ZWQg
dG8gYmUgb2theSwgaXQgaXMgZ2VuZXJpYwpjb2RlIHRoYXQgbmVlZHMgdG8g
YmUgZml4ZWQgdG8gY2xpcCB0aGUgcmVwZXRpdGlvbiBjb3VudC4KClRvIGJl
IG9uIHRoZSBzYWZlIHNpZGUgKGFuZCBjb25zaXN0ZW50KSwgYWxzbyBkbyB0
aGUgc2FtZSBmb3IgYnVmZmVyZWQKSS9PIGludGVyY2VwdHMsIGV2ZW4gaWYg
dGhlaXIgb25seSBjbGllbnQgKHN0ZHZnYSkgZG9lc24ndCBwdXQgdGhlCmh5
cGVydmlzb3IgYXQgcmlzayAoaS5lLiAib25seSIgZ3Vlc3QgbWlzYmVoYXZp
b3Igd291bGQgcmVzdWx0KS4KClRoaXMgaXMgQ1ZFLTIwMTQtODg2NyAvIFhT
QS0xMTIuCgpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA
c3VzZS5jb20+ClJldmlld2VkLWJ5OiBUaW0gRGVlZ2FuIDx0aW1AeGVuLm9y
Zz4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vaW50ZXJjZXB0LmMKKysrIGIv
eGVuL2FyY2gveDg2L2h2bS9pbnRlcmNlcHQuYwpAQCAtMTgxLDExICsxODEs
MjQgQEAgaW50IGh2bV9tbWlvX2ludGVyY2VwdChpb3JlcV90ICpwKQogICAg
IGludCBpOwogCiAgICAgZm9yICggaSA9IDA7IGkgPCBIVk1fTU1JT19IQU5E
TEVSX05SOyBpKysgKQotICAgICAgICBpZiAoIGh2bV9tbWlvX2hhbmRsZXJz
W2ldLT5jaGVja19oYW5kbGVyKHYsIHAtPmFkZHIpICkKKyAgICB7CisgICAg
ICAgIGh2bV9tbWlvX2NoZWNrX3QgY2hlY2tfaGFuZGxlciA9CisgICAgICAg
ICAgICBodm1fbW1pb19oYW5kbGVyc1tpXS0+Y2hlY2tfaGFuZGxlcjsKKwor
ICAgICAgICBpZiAoIGNoZWNrX2hhbmRsZXIodiwgcC0+YWRkcikgKQorICAg
ICAgICB7CisgICAgICAgICAgICBpZiAoIHVubGlrZWx5KHAtPmNvdW50ID4g
MSkgJiYKKyAgICAgICAgICAgICAgICAgIWNoZWNrX2hhbmRsZXIodiwgdW5s
aWtlbHkocC0+ZGYpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgID8gcC0+YWRkciAtIChwLT5jb3VudCAtIDFMKSAqIHAtPnNpemUKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOiBwLT5hZGRyICsg
KHAtPmNvdW50IC0gMUwpICogcC0+c2l6ZSkgKQorICAgICAgICAgICAgICAg
IHAtPmNvdW50ID0gMTsKKwogICAgICAgICAgICAgcmV0dXJuIGh2bV9tbWlv
X2FjY2VzcygKICAgICAgICAgICAgICAgICB2LCBwLAogICAgICAgICAgICAg
ICAgIGh2bV9tbWlvX2hhbmRsZXJzW2ldLT5yZWFkX2hhbmRsZXIsCiAgICAg
ICAgICAgICAgICAgaHZtX21taW9faGFuZGxlcnNbaV0tPndyaXRlX2hhbmRs
ZXIpOworICAgICAgICB9CisgICAgfQogCiAgICAgcmV0dXJuIFg4NkVNVUxf
VU5IQU5ETEVBQkxFOwogfQpAQCAtMzQyLDYgKzM1NSwxMyBAQCBpbnQgaHZt
X2lvX2ludGVyY2VwdChpb3JlcV90ICpwLCBpbnQgdHlwCiAgICAgICAgICAg
ICBpZiAoIHR5cGUgPT0gSFZNX1BPUlRJTyApCiAgICAgICAgICAgICAgICAg
cmV0dXJuIHByb2Nlc3NfcG9ydGlvX2ludGVyY2VwdCgKICAgICAgICAgICAg
ICAgICAgICAgaGFuZGxlci0+aGRsX2xpc3RbaV0uYWN0aW9uLnBvcnRpbywg
cCk7CisKKyAgICAgICAgICAgIGlmICggdW5saWtlbHkocC0+Y291bnQgPiAx
KSAmJgorICAgICAgICAgICAgICAgICAodW5saWtlbHkocC0+ZGYpCisgICAg
ICAgICAgICAgICAgICA/IHAtPmFkZHIgLSAocC0+Y291bnQgLSAxTCkgKiBw
LT5zaXplIDwgYWRkcgorICAgICAgICAgICAgICAgICAgOiBwLT5hZGRyICsg
cC0+Y291bnQgKiAxTCAqIHAtPnNpemUgLSAxID49IGFkZHIgKyBzaXplKSAp
CisgICAgICAgICAgICAgICAgcC0+Y291bnQgPSAxOworCiAgICAgICAgICAg
ICByZXR1cm4gaGFuZGxlci0+aGRsX2xpc3RbaV0uYWN0aW9uLm1taW8ocCk7
CiAgICAgICAgIH0KICAgICB9Ci0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdm1z
aS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9odm0vdm1zaS5jCkBAIC0yMjYsNiAr
MjI2LDggQEAgc3RhdGljIGludCBtc2l4dGJsX3JlYWQoCiAgICAgcmN1X3Jl
YWRfbG9jaygmbXNpeHRibF9yY3VfbG9jayk7CiAKICAgICBlbnRyeSA9IG1z
aXh0YmxfZmluZF9lbnRyeSh2LCBhZGRyZXNzKTsKKyAgICBpZiAoICFlbnRy
eSApCisgICAgICAgIGdvdG8gb3V0OwogICAgIG9mZnNldCA9IGFkZHJlc3Mg
JiAoUENJX01TSVhfRU5UUllfU0laRSAtIDEpOwogCiAgICAgaWYgKCBvZmZz
ZXQgIT0gUENJX01TSVhfRU5UUllfVkVDVE9SX0NUUkxfT0ZGU0VUICkKQEAg
LTI2OCw2ICsyNzAsOCBAQCBzdGF0aWMgaW50IG1zaXh0Ymxfd3JpdGUoc3Ry
dWN0IHZjcHUgKnYsCiAgICAgcmN1X3JlYWRfbG9jaygmbXNpeHRibF9yY3Vf
bG9jayk7CiAKICAgICBlbnRyeSA9IG1zaXh0YmxfZmluZF9lbnRyeSh2LCBh
ZGRyZXNzKTsKKyAgICBpZiAoICFlbnRyeSApCisgICAgICAgIGdvdG8gb3V0
OwogICAgIG5yX2VudHJ5ID0gKGFkZHJlc3MgLSBlbnRyeS0+Z3RhYmxlKSAv
IFBDSV9NU0lYX0VOVFJZX1NJWkU7CiAKICAgICBvZmZzZXQgPSBhZGRyZXNz
ICYgKFBDSV9NU0lYX0VOVFJZX1NJWkUgLSAxKTsK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Thu Nov 27 12:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1XtyHQ-0004wW-LC; Thu, 27 Nov 2014 12:34:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtyHP-0004wR-0R
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 12:34:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3B/26-09842-E5A17745; Thu, 27 Nov 2014 12:34:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417091676!4533175!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13810 invoked from network); 27 Nov 2014 12:34:37 -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;
	27 Nov 2014 12:34:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197162228"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 07:34:35 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtyHL-0001ro-DP; Thu, 27 Nov 2014 12:34:35 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 27 Nov 2014 12:34:31 +0000
Message-ID: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>
Subject: [Xen-devel] [PATCH for-4.5 0/3] Coverity fixes for python lowlevel
	libraries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 were initially flagged by the XenServer coverity scanning.  It turns out
that they were being found by the upstream scan, but had been grouped with
Xend and listed as ignored, hiding them from the output.  I have adjusted the
scan filters to not ignore the lowlevel libraries, and identified the
appropriate scan CIDs in the patches

While Xend is certainly dead and gone, XenServer at the very least still has
consumers of these python libraries.

Konrad: I am requesting a release ack for this.  All 5 issues are bugs with
the handling of error cases, rather than with the basic functionality
provided.  With these changes, Coverity is of the opinion that the python
libraries are perfect (0 issues), and I feel this is a worthy position to be
in for 4.5

Andrew Cooper (3):
  python/xc: Fix multiple issues in pyflask_context_to_sid()
  python/xc: Fix multiple issues in pyxc_readconsolering()
  python/xs: Correct the indirection of the NULL xshandle() check

 tools/python/xen/lowlevel/xc/xc.c |   34 +++++++++-------------------------
 tools/python/xen/lowlevel/xs/xs.c |    2 +-
 2 files changed, 10 insertions(+), 26 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1XtyHp-0004yI-1L; Thu, 27 Nov 2014 12:35:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtyHn-0004y4-Ps
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 12:35:03 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	4F/BA-19763-77A17745; Thu, 27 Nov 2014 12:35:03 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417091700!8239244!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10878 invoked from network); 27 Nov 2014 12:35:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 12:35:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197421290"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 07:34:37 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtyHM-0001ro-Vl; Thu, 27 Nov 2014 12:34:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 27 Nov 2014 12:34:32 +0000
Message-ID: <1417091674-8163-2-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 1/3] python/xc: Fix multiple issues in
	pyflask_context_to_sid()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 error handling from a failed memory allocation should return
PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and continuing
to the memcpy() below, with the dest pointer being NULL.

Furthermore, the context string is simply an input parameter to the hypercall,
and is not mutated anywhere along the way.  The error handling elsewhere in
the function can be simplified by not duplicating it to start with.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-IDs: 1055305 1055721
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Xen Coverity Team <coverity@xen.org>
---
 tools/python/xen/lowlevel/xc/xc.c |   21 +++------------------
 1 file changed, 3 insertions(+), 18 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index d95d459..c70b388 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -2126,8 +2126,6 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
 {
     xc_interface *xc_handle;
     char *ctx;
-    char *buf;
-    uint32_t len;
     uint32_t sid;
     int ret;
 
@@ -2137,28 +2135,15 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
                                       &ctx) )
         return NULL;
 
-    len = strlen(ctx);
-
-    buf = malloc(len);
-    if (!buf) {
-        errno = -ENOMEM;
-        PyErr_SetFromErrno(xc_error_obj);
-    }
-    
-    memcpy(buf, ctx, len);
-    
     xc_handle = xc_interface_open(0,0,0);
     if (!xc_handle) {
-        free(buf);
         return PyErr_SetFromErrno(xc_error_obj);
     }
-    
-    ret = xc_flask_context_to_sid(xc_handle, buf, len, &sid);
-        
+
+    ret = xc_flask_context_to_sid(xc_handle, ctx, strlen(ctx), &sid);
+
     xc_interface_close(xc_handle);
 
-    free(buf);
-    
     if ( ret != 0 ) {
         errno = -ret;
         return PyErr_SetFromErrno(xc_error_obj);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1XtyHq-0004z3-QU; Thu, 27 Nov 2014 12:35:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtyHp-0004yG-Eb
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 12:35:05 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	E4/C3-22777-87A17745; Thu, 27 Nov 2014 12:35:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417091700!8239244!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11114 invoked from network); 27 Nov 2014 12:35:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 12:35:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197421292"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 07:34:38 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtyHN-0001ro-Mz; Thu, 27 Nov 2014 12:34:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 27 Nov 2014 12:34:34 +0000
Message-ID: <1417091674-8163-4-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 3/3] python/xs: Correct the indirection
	of the NULL xshandle() 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

The code now now matches its comment, and will actually catch the case of a
bad xs handle.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-ID: 1055948
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Xen Coverity Team <coverity@xen.org>
---
 tools/python/xen/lowlevel/xs/xs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/python/xen/lowlevel/xs/xs.c b/tools/python/xen/lowlevel/xs/xs.c
index 84e1711..ec364bb 100644
--- a/tools/python/xen/lowlevel/xs/xs.c
+++ b/tools/python/xen/lowlevel/xs/xs.c
@@ -816,7 +816,7 @@ static int parse_transaction_path(XsHandle *self, PyObject *args,
 
     *xh = xshandle(self);
 
-    if (!xh)
+    if (!*xh)
         return 0;
 
     if (!PyArg_ParseTuple(args, "ss", &thstr, path))
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1XtyHQ-0004wW-LC; Thu, 27 Nov 2014 12:34:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtyHP-0004wR-0R
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 12:34:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3B/26-09842-E5A17745; Thu, 27 Nov 2014 12:34:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417091676!4533175!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13810 invoked from network); 27 Nov 2014 12:34:37 -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;
	27 Nov 2014 12:34:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197162228"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 07:34:35 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtyHL-0001ro-DP; Thu, 27 Nov 2014 12:34:35 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 27 Nov 2014 12:34:31 +0000
Message-ID: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>
Subject: [Xen-devel] [PATCH for-4.5 0/3] Coverity fixes for python lowlevel
	libraries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 were initially flagged by the XenServer coverity scanning.  It turns out
that they were being found by the upstream scan, but had been grouped with
Xend and listed as ignored, hiding them from the output.  I have adjusted the
scan filters to not ignore the lowlevel libraries, and identified the
appropriate scan CIDs in the patches

While Xend is certainly dead and gone, XenServer at the very least still has
consumers of these python libraries.

Konrad: I am requesting a release ack for this.  All 5 issues are bugs with
the handling of error cases, rather than with the basic functionality
provided.  With these changes, Coverity is of the opinion that the python
libraries are perfect (0 issues), and I feel this is a worthy position to be
in for 4.5

Andrew Cooper (3):
  python/xc: Fix multiple issues in pyflask_context_to_sid()
  python/xc: Fix multiple issues in pyxc_readconsolering()
  python/xs: Correct the indirection of the NULL xshandle() check

 tools/python/xen/lowlevel/xc/xc.c |   34 +++++++++-------------------------
 tools/python/xen/lowlevel/xs/xs.c |    2 +-
 2 files changed, 10 insertions(+), 26 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1XtyHq-0004ym-DS; Thu, 27 Nov 2014 12:35:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtyHo-0004yA-Kl
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 12:35:04 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	04/CA-19763-77A17745; Thu, 27 Nov 2014 12:35:03 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417091700!8239244!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10993 invoked from network); 27 Nov 2014 12:35:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 12:35:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197421291"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 07:34:38 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtyHN-0001ro-LB; Thu, 27 Nov 2014 12:34:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 27 Nov 2014 12:34:33 +0000
Message-ID: <1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 2/3] python/xc: Fix multiple issues in
	pyxc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Don't leak a 16k allocation if PyArg_ParseTupleAndKeywords() or the first
xc_readconsolering() fail.  It is trivial to run throught the processes memory
by repeatedly passing junk parameters to this function.

In the case that the call to xc_readconsolering() in the while loop fails,
reinstate str before breaking out, and passing a spurious pointer to free().

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-IDs: 1054984 1055906
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Xen Coverity Team <coverity@xen.org>
---
 tools/python/xen/lowlevel/xc/xc.c |   13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index c70b388..2aa0dc7 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1089,7 +1089,7 @@ static PyObject *pyxc_readconsolering(XcObject *self,
 {
     unsigned int clear = 0, index = 0, incremental = 0;
     unsigned int count = 16384 + 1, size = count;
-    char        *str = malloc(size), *ptr;
+    char        *str, *ptr;
     PyObject    *obj;
     int          ret;
 
@@ -1097,15 +1097,17 @@ static PyObject *pyxc_readconsolering(XcObject *self,
 
     if ( !PyArg_ParseTupleAndKeywords(args, kwds, "|iii", kwd_list,
                                       &clear, &index, &incremental) ||
-         !str )
+         !(str = malloc(size)) )
         return NULL;
 
     ret = xc_readconsolering(self->xc_handle, str, &count, clear,
                              incremental, &index);
-    if ( ret < 0 )
+    if ( ret < 0 ) {
+        free(str);
         return pyxc_error_to_exception(self->xc_handle);
+    }
 
-    while ( !incremental && count == size )
+    while ( !incremental && count == size && ret >= 0 )
     {
         size += count - 1;
         if ( size < count )
@@ -1119,9 +1121,6 @@ static PyObject *pyxc_readconsolering(XcObject *self,
         count = size - count;
         ret = xc_readconsolering(self->xc_handle, str, &count, clear,
                                  1, &index);
-        if ( ret < 0 )
-            break;
-
         count += str - ptr;
         str = ptr;
     }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1XtyHp-0004yI-1L; Thu, 27 Nov 2014 12:35:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtyHn-0004y4-Ps
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 12:35:03 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	4F/BA-19763-77A17745; Thu, 27 Nov 2014 12:35:03 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417091700!8239244!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10878 invoked from network); 27 Nov 2014 12:35:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 12:35:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197421290"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 07:34:37 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtyHM-0001ro-Vl; Thu, 27 Nov 2014 12:34:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 27 Nov 2014 12:34:32 +0000
Message-ID: <1417091674-8163-2-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 1/3] python/xc: Fix multiple issues in
	pyflask_context_to_sid()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 error handling from a failed memory allocation should return
PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and continuing
to the memcpy() below, with the dest pointer being NULL.

Furthermore, the context string is simply an input parameter to the hypercall,
and is not mutated anywhere along the way.  The error handling elsewhere in
the function can be simplified by not duplicating it to start with.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-IDs: 1055305 1055721
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Xen Coverity Team <coverity@xen.org>
---
 tools/python/xen/lowlevel/xc/xc.c |   21 +++------------------
 1 file changed, 3 insertions(+), 18 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index d95d459..c70b388 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -2126,8 +2126,6 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
 {
     xc_interface *xc_handle;
     char *ctx;
-    char *buf;
-    uint32_t len;
     uint32_t sid;
     int ret;
 
@@ -2137,28 +2135,15 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
                                       &ctx) )
         return NULL;
 
-    len = strlen(ctx);
-
-    buf = malloc(len);
-    if (!buf) {
-        errno = -ENOMEM;
-        PyErr_SetFromErrno(xc_error_obj);
-    }
-    
-    memcpy(buf, ctx, len);
-    
     xc_handle = xc_interface_open(0,0,0);
     if (!xc_handle) {
-        free(buf);
         return PyErr_SetFromErrno(xc_error_obj);
     }
-    
-    ret = xc_flask_context_to_sid(xc_handle, buf, len, &sid);
-        
+
+    ret = xc_flask_context_to_sid(xc_handle, ctx, strlen(ctx), &sid);
+
     xc_interface_close(xc_handle);
 
-    free(buf);
-    
     if ( ret != 0 ) {
         errno = -ret;
         return PyErr_SetFromErrno(xc_error_obj);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1XtyHq-0004z3-QU; Thu, 27 Nov 2014 12:35:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtyHp-0004yG-Eb
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 12:35:05 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	E4/C3-22777-87A17745; Thu, 27 Nov 2014 12:35:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417091700!8239244!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11114 invoked from network); 27 Nov 2014 12:35:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 12:35:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197421292"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 07:34:38 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtyHN-0001ro-Mz; Thu, 27 Nov 2014 12:34:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 27 Nov 2014 12:34:34 +0000
Message-ID: <1417091674-8163-4-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 3/3] python/xs: Correct the indirection
	of the NULL xshandle() 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

The code now now matches its comment, and will actually catch the case of a
bad xs handle.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-ID: 1055948
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Xen Coverity Team <coverity@xen.org>
---
 tools/python/xen/lowlevel/xs/xs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/python/xen/lowlevel/xs/xs.c b/tools/python/xen/lowlevel/xs/xs.c
index 84e1711..ec364bb 100644
--- a/tools/python/xen/lowlevel/xs/xs.c
+++ b/tools/python/xen/lowlevel/xs/xs.c
@@ -816,7 +816,7 @@ static int parse_transaction_path(XsHandle *self, PyObject *args,
 
     *xh = xshandle(self);
 
-    if (!xh)
+    if (!*xh)
         return 0;
 
     if (!PyArg_ParseTuple(args, "ss", &thstr, path))
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1XtyHq-0004ym-DS; Thu, 27 Nov 2014 12:35:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtyHo-0004yA-Kl
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 12:35:04 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	04/CA-19763-77A17745; Thu, 27 Nov 2014 12:35:03 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417091700!8239244!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10993 invoked from network); 27 Nov 2014 12:35:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 12:35:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197421291"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 07:34:38 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18]
	helo=andrewcoop.uk.xensource.com.)	by ukmail1.uk.xensource.com with
	esmtp (Exim 4.69)	(envelope-from <andrew.cooper3@citrix.com>)	id
	1XtyHN-0001ro-LB; Thu, 27 Nov 2014 12:34:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 27 Nov 2014 12:34:33 +0000
Message-ID: <1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 2/3] python/xc: Fix multiple issues in
	pyxc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Don't leak a 16k allocation if PyArg_ParseTupleAndKeywords() or the first
xc_readconsolering() fail.  It is trivial to run throught the processes memory
by repeatedly passing junk parameters to this function.

In the case that the call to xc_readconsolering() in the while loop fails,
reinstate str before breaking out, and passing a spurious pointer to free().

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-IDs: 1054984 1055906
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Xen Coverity Team <coverity@xen.org>
---
 tools/python/xen/lowlevel/xc/xc.c |   13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index c70b388..2aa0dc7 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1089,7 +1089,7 @@ static PyObject *pyxc_readconsolering(XcObject *self,
 {
     unsigned int clear = 0, index = 0, incremental = 0;
     unsigned int count = 16384 + 1, size = count;
-    char        *str = malloc(size), *ptr;
+    char        *str, *ptr;
     PyObject    *obj;
     int          ret;
 
@@ -1097,15 +1097,17 @@ static PyObject *pyxc_readconsolering(XcObject *self,
 
     if ( !PyArg_ParseTupleAndKeywords(args, kwds, "|iii", kwd_list,
                                       &clear, &index, &incremental) ||
-         !str )
+         !(str = malloc(size)) )
         return NULL;
 
     ret = xc_readconsolering(self->xc_handle, str, &count, clear,
                              incremental, &index);
-    if ( ret < 0 )
+    if ( ret < 0 ) {
+        free(str);
         return pyxc_error_to_exception(self->xc_handle);
+    }
 
-    while ( !incremental && count == size )
+    while ( !incremental && count == size && ret >= 0 )
     {
         size += count - 1;
         if ( size < count )
@@ -1119,9 +1121,6 @@ static PyObject *pyxc_readconsolering(XcObject *self,
         count = size - count;
         ret = xc_readconsolering(self->xc_handle, str, &count, clear,
                                  1, &index);
-        if ( ret < 0 )
-            break;
-
         count += str - ptr;
         str = ptr;
     }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:40:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12:40:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtyMd-0005aZ-Kc; Thu, 27 Nov 2014 12:40:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtyMb-0005aQ-KZ
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 12:40:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E5/17-15461-1AB17745; Thu, 27 Nov 2014 12:40:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417092000!11493332!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21882 invoked from network); 27 Nov 2014 12:40:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 12:40:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 12:39:59 +0000
Message-Id: <547729AF020000780004B2A7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 12:39:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDFEAF18F.1__="
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH] x86/HVM: prevent infinite VM entry retries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartDFEAF18F.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
guest upon problems occurring in user mode") and gets SVM in line with
the resulting VMX behavior. This is because Andrew validly says

"A failed vmentry is overwhelmingly likely to be caused by corrupt
 VMC[SB] state.  As a result, injecting a fault and retrying the the
 vmentry is likely to fail in the same way."

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Tim Deegan <tim@xen.org>
---
v2: Replace SVM change by what Tim suggested.

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2371,8 +2371,8 @@ void svm_vmexit_handler(struct cpu_user_
                 goto out;
             case NESTEDHVM_VMEXIT_FATALERROR:
                 gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() =
error\n");
-                goto exit_and_crash;
-
+                domain_crash(v->domain);
+                goto out;
             default:
                 BUG();
             case NESTEDHVM_VMEXIT_ERROR:
@@ -2385,18 +2385,21 @@ void svm_vmexit_handler(struct cpu_user_
         case NESTEDHVM_VMEXIT_FATALERROR:
             gdprintk(XENLOG_ERR,
                 "unexpected nestedsvm_check_intercepts() error\n");
-            goto exit_and_crash;
+            domain_crash(v->domain);
+            goto out;
         default:
             gdprintk(XENLOG_INFO, "nestedsvm_check_intercepts() returned =
%i\n",
                 nsret);
-            goto exit_and_crash;
+            domain_crash(v->domain);
+            goto out;
         }
     }
=20
     if ( unlikely(exit_reason =3D=3D VMEXIT_INVALID) )
     {
         svm_vmcb_dump(__func__, vmcb);
-        goto exit_and_crash;
+        domain_crash(v->domain);
+        goto out;
     }
=20
     perfc_incra(svmexits, exit_reason);
@@ -2431,13 +2434,13 @@ void svm_vmexit_handler(struct cpu_user_
=20
     case VMEXIT_EXCEPTION_DB:
         if ( !v->domain->debugger_attached )
-            goto exit_and_crash;
+            goto unexpected_exit_type;
         domain_pause_for_debugger();
         break;
=20
     case VMEXIT_EXCEPTION_BP:
         if ( !v->domain->debugger_attached )
-            goto exit_and_crash;
+            goto unexpected_exit_type;
         /* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update =
RIP. */
         if ( (inst_len =3D __get_instruction_length(v, INSTR_INT3)) =
=3D=3D 0 )
             break;
@@ -2684,7 +2687,7 @@ void svm_vmexit_handler(struct cpu_user_
         break;
=20
     default:
-    exit_and_crash:
+    unexpected_exit_type:
         gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason =3D =
%#"PRIx64", "
                  "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",
                  exit_reason,=20
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,18 +134,6 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
=20
-/* Only crash the guest if the problem originates in kernel mode. */
-static void vmx_crash_or_fault(struct vcpu *v)
-{
-    struct segment_register ss;
-
-    vmx_get_segment_register(v, x86_seg_ss, &ss);
-    if ( ss.attr.fields.dpl )
-        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
-    else
-        domain_crash(v->domain);
-}
-
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
=20
 static const u32 msr_index[] =3D
@@ -2520,7 +2508,7 @@ static void vmx_failed_vmentry(unsigned=20
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
=20
-    vmx_crash_or_fault(curr);
+    domain_crash(curr->domain);
 }
=20
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3173,8 +3161,19 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason=
);
-        vmx_crash_or_fault(v);
+        {
+            struct segment_register ss;
+
+            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
+                     exit_reason);
+
+            vmx_get_segment_register(v, x86_seg_ss, &ss);
+            if ( ss.attr.fields.dpl )
+                hvm_inject_hw_exception(TRAP_invalid_op,
+                                        HVM_DELIVER_NO_ERROR_CODE);
+            else
+                domain_crash(v->domain);
+        }
         break;
     }
=20



--=__PartDFEAF18F.1__=
Content-Type: text/plain; name="x86-HVM-prevent-infinite-VMentry-loop.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-prevent-infinite-VMentry-loop.patch"

x86/HVM: prevent infinite VM entry retries=0A=0AThis reverts the VMX side =
of commit 28b4baac ("x86/HVM: don't crash=0Aguest upon problems occurring =
in user mode") and gets SVM in line with=0Athe resulting VMX behavior. =
This is because Andrew validly says=0A=0A"A failed vmentry is overwhelmingl=
y likely to be caused by corrupt=0A VMC[SB] state.  As a result, injecting =
a fault and retrying the the=0A vmentry is likely to fail in the same =
way."=0A=0AReported-by: Andrew Cooper <andrew.cooper3@citrix.com>=0ASigned-=
off-by: Jan Beulich <jbeulich@suse.com>=0ASigned-off-by: Tim Deegan =
<tim@xen.org>=0A---=0Av2: Replace SVM change by what Tim suggested.=0A=0A--=
- a/xen/arch/x86/hvm/svm/svm.c=0A+++ b/xen/arch/x86/hvm/svm/svm.c=0A@@ =
-2371,8 +2371,8 @@ void svm_vmexit_handler(struct cpu_user_=0A             =
    goto out;=0A             case NESTEDHVM_VMEXIT_FATALERROR:=0A          =
       gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() error\n");=0A-  =
              goto exit_and_crash;=0A-=0A+                domain_crash(v->d=
omain);=0A+                goto out;=0A             default:=0A            =
     BUG();=0A             case NESTEDHVM_VMEXIT_ERROR:=0A@@ -2385,18 =
+2385,21 @@ void svm_vmexit_handler(struct cpu_user_=0A         case =
NESTEDHVM_VMEXIT_FATALERROR:=0A             gdprintk(XENLOG_ERR,=0A        =
         "unexpected nestedsvm_check_intercepts() error\n");=0A-           =
 goto exit_and_crash;=0A+            domain_crash(v->domain);=0A+          =
  goto out;=0A         default:=0A             gdprintk(XENLOG_INFO, =
"nestedsvm_check_intercepts() returned %i\n",=0A                 nsret);=0A=
-            goto exit_and_crash;=0A+            domain_crash(v->domain);=
=0A+            goto out;=0A         }=0A     }=0A =0A     if ( unlikely(ex=
it_reason =3D=3D VMEXIT_INVALID) )=0A     {=0A         svm_vmcb_dump(__func=
__, vmcb);=0A-        goto exit_and_crash;=0A+        domain_crash(v->domai=
n);=0A+        goto out;=0A     }=0A =0A     perfc_incra(svmexits, =
exit_reason);=0A@@ -2431,13 +2434,13 @@ void svm_vmexit_handler(struct =
cpu_user_=0A =0A     case VMEXIT_EXCEPTION_DB:=0A         if ( !v->domain->=
debugger_attached )=0A-            goto exit_and_crash;=0A+            =
goto unexpected_exit_type;=0A         domain_pause_for_debugger();=0A      =
   break;=0A =0A     case VMEXIT_EXCEPTION_BP:=0A         if ( !v->domain->=
debugger_attached )=0A-            goto exit_and_crash;=0A+            =
goto unexpected_exit_type;=0A         /* AMD Vol2, 15.11: INT3, INTO, =
BOUND intercepts do not update RIP. */=0A         if ( (inst_len =3D =
__get_instruction_length(v, INSTR_INT3)) =3D=3D 0 )=0A             =
break;=0A@@ -2684,7 +2687,7 @@ void svm_vmexit_handler(struct cpu_user_=0A =
        break;=0A =0A     default:=0A-    exit_and_crash:=0A+    unexpected=
_exit_type:=0A         gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit =
reason =3D %#"PRIx64", "=0A                  "exitinfo1 =3D %#"PRIx64", =
exitinfo2 =3D %#"PRIx64"\n",=0A                  exit_reason, =0A--- =
a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ =
-134,18 +134,6 @@ static void vmx_vcpu_destroy(struct vcpu=0A     =
passive_domain_destroy(v);=0A }=0A =0A-/* Only crash the guest if the =
problem originates in kernel mode. */=0A-static void vmx_crash_or_fault(str=
uct vcpu *v)=0A-{=0A-    struct segment_register ss;=0A-=0A-    vmx_get_seg=
ment_register(v, x86_seg_ss, &ss);=0A-    if ( ss.attr.fields.dpl )=0A-    =
    hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);=0A=
-    else=0A-        domain_crash(v->domain);=0A-}=0A-=0A static DEFINE_PER=
_CPU(struct vmx_msr_state, host_msr_state);=0A =0A static const u32 =
msr_index[] =3D=0A@@ -2520,7 +2508,7 @@ static void vmx_failed_vmentry(unsi=
gned =0A     vmcs_dump_vcpu(curr);=0A     printk("*************************=
*************\n");=0A =0A-    vmx_crash_or_fault(curr);=0A+    domain_crash=
(curr->domain);=0A }=0A =0A void vmx_enter_realmode(struct cpu_user_regs =
*regs)=0A@@ -3173,8 +3161,19 @@ void vmx_vmexit_handler(struct cpu_user_=0A=
     /* fall through */=0A     default:=0A     exit_and_crash:=0A-        =
gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);=0A-   =
     vmx_crash_or_fault(v);=0A+        {=0A+            struct segment_regi=
ster ss;=0A+=0A+            gdprintk(XENLOG_WARNING, "Bad vmexit (reason =
%#lx)\n",=0A+                     exit_reason);=0A+=0A+            =
vmx_get_segment_register(v, x86_seg_ss, &ss);=0A+            if ( =
ss.attr.fields.dpl )=0A+                hvm_inject_hw_exception(TRAP_invali=
d_op,=0A+                                        HVM_DELIVER_NO_ERROR_CODE)=
;=0A+            else=0A+                domain_crash(v->domain);=0A+      =
  }=0A         break;=0A     }=0A =0A
--=__PartDFEAF18F.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

--=__PartDFEAF18F.1__=--


From xen-devel-bounces@lists.xen.org Thu Nov 27 12:40:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12:40:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtyMd-0005aZ-Kc; Thu, 27 Nov 2014 12:40:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtyMb-0005aQ-KZ
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 12:40:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E5/17-15461-1AB17745; Thu, 27 Nov 2014 12:40:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417092000!11493332!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21882 invoked from network); 27 Nov 2014 12:40:00 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 12:40:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 12:39:59 +0000
Message-Id: <547729AF020000780004B2A7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 12:39:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDFEAF18F.1__="
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH] x86/HVM: prevent infinite VM entry retries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartDFEAF18F.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
guest upon problems occurring in user mode") and gets SVM in line with
the resulting VMX behavior. This is because Andrew validly says

"A failed vmentry is overwhelmingly likely to be caused by corrupt
 VMC[SB] state.  As a result, injecting a fault and retrying the the
 vmentry is likely to fail in the same way."

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Tim Deegan <tim@xen.org>
---
v2: Replace SVM change by what Tim suggested.

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2371,8 +2371,8 @@ void svm_vmexit_handler(struct cpu_user_
                 goto out;
             case NESTEDHVM_VMEXIT_FATALERROR:
                 gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() =
error\n");
-                goto exit_and_crash;
-
+                domain_crash(v->domain);
+                goto out;
             default:
                 BUG();
             case NESTEDHVM_VMEXIT_ERROR:
@@ -2385,18 +2385,21 @@ void svm_vmexit_handler(struct cpu_user_
         case NESTEDHVM_VMEXIT_FATALERROR:
             gdprintk(XENLOG_ERR,
                 "unexpected nestedsvm_check_intercepts() error\n");
-            goto exit_and_crash;
+            domain_crash(v->domain);
+            goto out;
         default:
             gdprintk(XENLOG_INFO, "nestedsvm_check_intercepts() returned =
%i\n",
                 nsret);
-            goto exit_and_crash;
+            domain_crash(v->domain);
+            goto out;
         }
     }
=20
     if ( unlikely(exit_reason =3D=3D VMEXIT_INVALID) )
     {
         svm_vmcb_dump(__func__, vmcb);
-        goto exit_and_crash;
+        domain_crash(v->domain);
+        goto out;
     }
=20
     perfc_incra(svmexits, exit_reason);
@@ -2431,13 +2434,13 @@ void svm_vmexit_handler(struct cpu_user_
=20
     case VMEXIT_EXCEPTION_DB:
         if ( !v->domain->debugger_attached )
-            goto exit_and_crash;
+            goto unexpected_exit_type;
         domain_pause_for_debugger();
         break;
=20
     case VMEXIT_EXCEPTION_BP:
         if ( !v->domain->debugger_attached )
-            goto exit_and_crash;
+            goto unexpected_exit_type;
         /* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update =
RIP. */
         if ( (inst_len =3D __get_instruction_length(v, INSTR_INT3)) =
=3D=3D 0 )
             break;
@@ -2684,7 +2687,7 @@ void svm_vmexit_handler(struct cpu_user_
         break;
=20
     default:
-    exit_and_crash:
+    unexpected_exit_type:
         gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason =3D =
%#"PRIx64", "
                  "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",
                  exit_reason,=20
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -134,18 +134,6 @@ static void vmx_vcpu_destroy(struct vcpu
     passive_domain_destroy(v);
 }
=20
-/* Only crash the guest if the problem originates in kernel mode. */
-static void vmx_crash_or_fault(struct vcpu *v)
-{
-    struct segment_register ss;
-
-    vmx_get_segment_register(v, x86_seg_ss, &ss);
-    if ( ss.attr.fields.dpl )
-        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE=
);
-    else
-        domain_crash(v->domain);
-}
-
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
=20
 static const u32 msr_index[] =3D
@@ -2520,7 +2508,7 @@ static void vmx_failed_vmentry(unsigned=20
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
=20
-    vmx_crash_or_fault(curr);
+    domain_crash(curr->domain);
 }
=20
 void vmx_enter_realmode(struct cpu_user_regs *regs)
@@ -3173,8 +3161,19 @@ void vmx_vmexit_handler(struct cpu_user_
     /* fall through */
     default:
     exit_and_crash:
-        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason=
);
-        vmx_crash_or_fault(v);
+        {
+            struct segment_register ss;
+
+            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
+                     exit_reason);
+
+            vmx_get_segment_register(v, x86_seg_ss, &ss);
+            if ( ss.attr.fields.dpl )
+                hvm_inject_hw_exception(TRAP_invalid_op,
+                                        HVM_DELIVER_NO_ERROR_CODE);
+            else
+                domain_crash(v->domain);
+        }
         break;
     }
=20



--=__PartDFEAF18F.1__=
Content-Type: text/plain; name="x86-HVM-prevent-infinite-VMentry-loop.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-prevent-infinite-VMentry-loop.patch"

x86/HVM: prevent infinite VM entry retries=0A=0AThis reverts the VMX side =
of commit 28b4baac ("x86/HVM: don't crash=0Aguest upon problems occurring =
in user mode") and gets SVM in line with=0Athe resulting VMX behavior. =
This is because Andrew validly says=0A=0A"A failed vmentry is overwhelmingl=
y likely to be caused by corrupt=0A VMC[SB] state.  As a result, injecting =
a fault and retrying the the=0A vmentry is likely to fail in the same =
way."=0A=0AReported-by: Andrew Cooper <andrew.cooper3@citrix.com>=0ASigned-=
off-by: Jan Beulich <jbeulich@suse.com>=0ASigned-off-by: Tim Deegan =
<tim@xen.org>=0A---=0Av2: Replace SVM change by what Tim suggested.=0A=0A--=
- a/xen/arch/x86/hvm/svm/svm.c=0A+++ b/xen/arch/x86/hvm/svm/svm.c=0A@@ =
-2371,8 +2371,8 @@ void svm_vmexit_handler(struct cpu_user_=0A             =
    goto out;=0A             case NESTEDHVM_VMEXIT_FATALERROR:=0A          =
       gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() error\n");=0A-  =
              goto exit_and_crash;=0A-=0A+                domain_crash(v->d=
omain);=0A+                goto out;=0A             default:=0A            =
     BUG();=0A             case NESTEDHVM_VMEXIT_ERROR:=0A@@ -2385,18 =
+2385,21 @@ void svm_vmexit_handler(struct cpu_user_=0A         case =
NESTEDHVM_VMEXIT_FATALERROR:=0A             gdprintk(XENLOG_ERR,=0A        =
         "unexpected nestedsvm_check_intercepts() error\n");=0A-           =
 goto exit_and_crash;=0A+            domain_crash(v->domain);=0A+          =
  goto out;=0A         default:=0A             gdprintk(XENLOG_INFO, =
"nestedsvm_check_intercepts() returned %i\n",=0A                 nsret);=0A=
-            goto exit_and_crash;=0A+            domain_crash(v->domain);=
=0A+            goto out;=0A         }=0A     }=0A =0A     if ( unlikely(ex=
it_reason =3D=3D VMEXIT_INVALID) )=0A     {=0A         svm_vmcb_dump(__func=
__, vmcb);=0A-        goto exit_and_crash;=0A+        domain_crash(v->domai=
n);=0A+        goto out;=0A     }=0A =0A     perfc_incra(svmexits, =
exit_reason);=0A@@ -2431,13 +2434,13 @@ void svm_vmexit_handler(struct =
cpu_user_=0A =0A     case VMEXIT_EXCEPTION_DB:=0A         if ( !v->domain->=
debugger_attached )=0A-            goto exit_and_crash;=0A+            =
goto unexpected_exit_type;=0A         domain_pause_for_debugger();=0A      =
   break;=0A =0A     case VMEXIT_EXCEPTION_BP:=0A         if ( !v->domain->=
debugger_attached )=0A-            goto exit_and_crash;=0A+            =
goto unexpected_exit_type;=0A         /* AMD Vol2, 15.11: INT3, INTO, =
BOUND intercepts do not update RIP. */=0A         if ( (inst_len =3D =
__get_instruction_length(v, INSTR_INT3)) =3D=3D 0 )=0A             =
break;=0A@@ -2684,7 +2687,7 @@ void svm_vmexit_handler(struct cpu_user_=0A =
        break;=0A =0A     default:=0A-    exit_and_crash:=0A+    unexpected=
_exit_type:=0A         gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit =
reason =3D %#"PRIx64", "=0A                  "exitinfo1 =3D %#"PRIx64", =
exitinfo2 =3D %#"PRIx64"\n",=0A                  exit_reason, =0A--- =
a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ =
-134,18 +134,6 @@ static void vmx_vcpu_destroy(struct vcpu=0A     =
passive_domain_destroy(v);=0A }=0A =0A-/* Only crash the guest if the =
problem originates in kernel mode. */=0A-static void vmx_crash_or_fault(str=
uct vcpu *v)=0A-{=0A-    struct segment_register ss;=0A-=0A-    vmx_get_seg=
ment_register(v, x86_seg_ss, &ss);=0A-    if ( ss.attr.fields.dpl )=0A-    =
    hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);=0A=
-    else=0A-        domain_crash(v->domain);=0A-}=0A-=0A static DEFINE_PER=
_CPU(struct vmx_msr_state, host_msr_state);=0A =0A static const u32 =
msr_index[] =3D=0A@@ -2520,7 +2508,7 @@ static void vmx_failed_vmentry(unsi=
gned =0A     vmcs_dump_vcpu(curr);=0A     printk("*************************=
*************\n");=0A =0A-    vmx_crash_or_fault(curr);=0A+    domain_crash=
(curr->domain);=0A }=0A =0A void vmx_enter_realmode(struct cpu_user_regs =
*regs)=0A@@ -3173,8 +3161,19 @@ void vmx_vmexit_handler(struct cpu_user_=0A=
     /* fall through */=0A     default:=0A     exit_and_crash:=0A-        =
gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);=0A-   =
     vmx_crash_or_fault(v);=0A+        {=0A+            struct segment_regi=
ster ss;=0A+=0A+            gdprintk(XENLOG_WARNING, "Bad vmexit (reason =
%#lx)\n",=0A+                     exit_reason);=0A+=0A+            =
vmx_get_segment_register(v, x86_seg_ss, &ss);=0A+            if ( =
ss.attr.fields.dpl )=0A+                hvm_inject_hw_exception(TRAP_invali=
d_op,=0A+                                        HVM_DELIVER_NO_ERROR_CODE)=
;=0A+            else=0A+                domain_crash(v->domain);=0A+      =
  }=0A         break;=0A     }=0A =0A
--=__PartDFEAF18F.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

--=__PartDFEAF18F.1__=--


From xen-devel-bounces@lists.xen.org Thu Nov 27 12:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1XtySW-0005vb-IC; Thu, 27 Nov 2014 12:46:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtySV-0005vT-EZ
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 12:46:07 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	70/4D-20609-E0D17745; Thu, 27 Nov 2014 12:46:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417092364!14670797!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9109 invoked from network); 27 Nov 2014 12:46:06 -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;
	27 Nov 2014 12:46:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197164997"
Message-ID: <54771D0A.2010901@citrix.com>
Date: Thu, 27 Nov 2014 12:46:02 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <547729AF020000780004B2A7@mail.emea.novell.com>
In-Reply-To: <547729AF020000780004B2A7@mail.emea.novell.com>
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/HVM: prevent infinite VM entry retries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 12:39, Jan Beulich wrote:
> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
> guest upon problems occurring in user mode") and gets SVM in line with
> the resulting VMX behavior. This is because Andrew validly says
>
> "A failed vmentry is overwhelmingly likely to be caused by corrupt
>  VMC[SB] state.  As a result, injecting a fault and retrying the the
>  vmentry is likely to fail in the same way."
>
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Tim Deegan <tim@xen.org>
> ---
> v2: Replace SVM change by what Tim suggested.
>
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2371,8 +2371,8 @@ void svm_vmexit_handler(struct cpu_user_
>                  goto out;
>              case NESTEDHVM_VMEXIT_FATALERROR:
>                  gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() error\n");
> -                goto exit_and_crash;
> -
> +                domain_crash(v->domain);
> +                goto out;
>              default:
>                  BUG();
>              case NESTEDHVM_VMEXIT_ERROR:
> @@ -2385,18 +2385,21 @@ void svm_vmexit_handler(struct cpu_user_
>          case NESTEDHVM_VMEXIT_FATALERROR:
>              gdprintk(XENLOG_ERR,
>                  "unexpected nestedsvm_check_intercepts() error\n");
> -            goto exit_and_crash;
> +            domain_crash(v->domain);
> +            goto out;
>          default:
>              gdprintk(XENLOG_INFO, "nestedsvm_check_intercepts() returned %i\n",
>                  nsret);
> -            goto exit_and_crash;
> +            domain_crash(v->domain);
> +            goto out;
>          }
>      }
>  
>      if ( unlikely(exit_reason == VMEXIT_INVALID) )
>      {

I think it would be good to retain the printk here from previous
versions of the patch, specifically identifies the below vmcb dump as
caused by a failed vmentry.  As it stands, it is a vmcb dump with no
other context.

Either way, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

>          svm_vmcb_dump(__func__, vmcb);
> -        goto exit_and_crash;
> +        domain_crash(v->domain);
> +        goto out;
>      }
>  
>      perfc_incra(svmexits, exit_reason);
> @@ -2431,13 +2434,13 @@ void svm_vmexit_handler(struct cpu_user_
>  
>      case VMEXIT_EXCEPTION_DB:
>          if ( !v->domain->debugger_attached )
> -            goto exit_and_crash;
> +            goto unexpected_exit_type;
>          domain_pause_for_debugger();
>          break;
>  
>      case VMEXIT_EXCEPTION_BP:
>          if ( !v->domain->debugger_attached )
> -            goto exit_and_crash;
> +            goto unexpected_exit_type;
>          /* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. */
>          if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
>              break;
> @@ -2684,7 +2687,7 @@ void svm_vmexit_handler(struct cpu_user_
>          break;
>  
>      default:
> -    exit_and_crash:
> +    unexpected_exit_type:
>          gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", "
>                   "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
>                   exit_reason, 
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -134,18 +134,6 @@ static void vmx_vcpu_destroy(struct vcpu
>      passive_domain_destroy(v);
>  }
>  
> -/* Only crash the guest if the problem originates in kernel mode. */
> -static void vmx_crash_or_fault(struct vcpu *v)
> -{
> -    struct segment_register ss;
> -
> -    vmx_get_segment_register(v, x86_seg_ss, &ss);
> -    if ( ss.attr.fields.dpl )
> -        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> -    else
> -        domain_crash(v->domain);
> -}
> -
>  static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
>  
>  static const u32 msr_index[] =
> @@ -2520,7 +2508,7 @@ static void vmx_failed_vmentry(unsigned 
>      vmcs_dump_vcpu(curr);
>      printk("**************************************\n");
>  
> -    vmx_crash_or_fault(curr);
> +    domain_crash(curr->domain);
>  }
>  
>  void vmx_enter_realmode(struct cpu_user_regs *regs)
> @@ -3173,8 +3161,19 @@ void vmx_vmexit_handler(struct cpu_user_
>      /* fall through */
>      default:
>      exit_and_crash:
> -        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);
> -        vmx_crash_or_fault(v);
> +        {
> +            struct segment_register ss;
> +
> +            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
> +                     exit_reason);
> +
> +            vmx_get_segment_register(v, x86_seg_ss, &ss);
> +            if ( ss.attr.fields.dpl )
> +                hvm_inject_hw_exception(TRAP_invalid_op,
> +                                        HVM_DELIVER_NO_ERROR_CODE);
> +            else
> +                domain_crash(v->domain);
> +        }
>          break;
>      }
>  
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1XtySW-0005vb-IC; Thu, 27 Nov 2014 12:46:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XtySV-0005vT-EZ
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 12:46:07 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	70/4D-20609-E0D17745; Thu, 27 Nov 2014 12:46:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417092364!14670797!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9109 invoked from network); 27 Nov 2014 12:46:06 -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;
	27 Nov 2014 12:46:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197164997"
Message-ID: <54771D0A.2010901@citrix.com>
Date: Thu, 27 Nov 2014 12:46:02 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <547729AF020000780004B2A7@mail.emea.novell.com>
In-Reply-To: <547729AF020000780004B2A7@mail.emea.novell.com>
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/HVM: prevent infinite VM entry retries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 12:39, Jan Beulich wrote:
> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
> guest upon problems occurring in user mode") and gets SVM in line with
> the resulting VMX behavior. This is because Andrew validly says
>
> "A failed vmentry is overwhelmingly likely to be caused by corrupt
>  VMC[SB] state.  As a result, injecting a fault and retrying the the
>  vmentry is likely to fail in the same way."
>
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Tim Deegan <tim@xen.org>
> ---
> v2: Replace SVM change by what Tim suggested.
>
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2371,8 +2371,8 @@ void svm_vmexit_handler(struct cpu_user_
>                  goto out;
>              case NESTEDHVM_VMEXIT_FATALERROR:
>                  gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() error\n");
> -                goto exit_and_crash;
> -
> +                domain_crash(v->domain);
> +                goto out;
>              default:
>                  BUG();
>              case NESTEDHVM_VMEXIT_ERROR:
> @@ -2385,18 +2385,21 @@ void svm_vmexit_handler(struct cpu_user_
>          case NESTEDHVM_VMEXIT_FATALERROR:
>              gdprintk(XENLOG_ERR,
>                  "unexpected nestedsvm_check_intercepts() error\n");
> -            goto exit_and_crash;
> +            domain_crash(v->domain);
> +            goto out;
>          default:
>              gdprintk(XENLOG_INFO, "nestedsvm_check_intercepts() returned %i\n",
>                  nsret);
> -            goto exit_and_crash;
> +            domain_crash(v->domain);
> +            goto out;
>          }
>      }
>  
>      if ( unlikely(exit_reason == VMEXIT_INVALID) )
>      {

I think it would be good to retain the printk here from previous
versions of the patch, specifically identifies the below vmcb dump as
caused by a failed vmentry.  As it stands, it is a vmcb dump with no
other context.

Either way, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

>          svm_vmcb_dump(__func__, vmcb);
> -        goto exit_and_crash;
> +        domain_crash(v->domain);
> +        goto out;
>      }
>  
>      perfc_incra(svmexits, exit_reason);
> @@ -2431,13 +2434,13 @@ void svm_vmexit_handler(struct cpu_user_
>  
>      case VMEXIT_EXCEPTION_DB:
>          if ( !v->domain->debugger_attached )
> -            goto exit_and_crash;
> +            goto unexpected_exit_type;
>          domain_pause_for_debugger();
>          break;
>  
>      case VMEXIT_EXCEPTION_BP:
>          if ( !v->domain->debugger_attached )
> -            goto exit_and_crash;
> +            goto unexpected_exit_type;
>          /* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. */
>          if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
>              break;
> @@ -2684,7 +2687,7 @@ void svm_vmexit_handler(struct cpu_user_
>          break;
>  
>      default:
> -    exit_and_crash:
> +    unexpected_exit_type:
>          gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", "
>                   "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
>                   exit_reason, 
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -134,18 +134,6 @@ static void vmx_vcpu_destroy(struct vcpu
>      passive_domain_destroy(v);
>  }
>  
> -/* Only crash the guest if the problem originates in kernel mode. */
> -static void vmx_crash_or_fault(struct vcpu *v)
> -{
> -    struct segment_register ss;
> -
> -    vmx_get_segment_register(v, x86_seg_ss, &ss);
> -    if ( ss.attr.fields.dpl )
> -        hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> -    else
> -        domain_crash(v->domain);
> -}
> -
>  static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
>  
>  static const u32 msr_index[] =
> @@ -2520,7 +2508,7 @@ static void vmx_failed_vmentry(unsigned 
>      vmcs_dump_vcpu(curr);
>      printk("**************************************\n");
>  
> -    vmx_crash_or_fault(curr);
> +    domain_crash(curr->domain);
>  }
>  
>  void vmx_enter_realmode(struct cpu_user_regs *regs)
> @@ -3173,8 +3161,19 @@ void vmx_vmexit_handler(struct cpu_user_
>      /* fall through */
>      default:
>      exit_and_crash:
> -        gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);
> -        vmx_crash_or_fault(v);
> +        {
> +            struct segment_register ss;
> +
> +            gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
> +                     exit_reason);
> +
> +            vmx_get_segment_register(v, x86_seg_ss, &ss);
> +            if ( ss.attr.fields.dpl )
> +                hvm_inject_hw_exception(TRAP_invalid_op,
> +                                        HVM_DELIVER_NO_ERROR_CODE);
> +            else
> +                domain_crash(v->domain);
> +        }
>          break;
>      }
>  
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:46:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtySi-0005xO-4A; Thu, 27 Nov 2014 12:46:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XtySg-0005wm-98
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 12:46:18 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	AA/1D-22737-91D17745; Thu, 27 Nov 2014 12:46:17 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417092377!8242106!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32207 invoked from network); 27 Nov 2014 12:46:17 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 12:46:17 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so6371730wgh.17
	for <xen-devel@lists.xenproject.org>;
	Thu, 27 Nov 2014 04:46:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=pXKTpWYmTzaBKxdFhU1DTWQTJjsgSHve5WXOrTL6QmA=;
	b=e5TqLXER99VWtOJUfRRGDXE1gDhKdzQDcvzDy8vf5GsZdjz0csg6svmCwBQDcuT+zd
	k87u8JQLUFcEWvN8+2ojytGxNDwzsJWWKr7DnwVD1IIcC87GvXHBl3faB7zSAl+VyPgx
	UWpr3h27jCZ8SleXXO84TgjDxDqAArbXwWkG+5LHCBauZ5LG7NOYoPsG6OFxT9VLebM3
	HEQ78C70uWNzkqlGiRydOdsWmRcS1a6AgT+T5rixK86d6LZfymMYPZ63t0/ZG6wkFdAI
	eo1dlMYT6U5IFBT3Mkz5LPPuq2Tko5JMXukNFhBJQ8an9OvU5sje0vGRY65HhTpzSAzd
	PkIQ==
X-Gm-Message-State: ALoCoQlbppPIfkzToEflH9p7k5JkglHpAPb5C2iiz87J/Bfk/u9jl5zfNW3yFJXxrYDLH0uTTRr0
X-Received: by 10.194.193.38 with SMTP id hl6mr13677611wjc.38.1417092376819;
	Thu, 27 Nov 2014 04:46:16 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	hz9sm10576786wjb.17.2014.11.27.04.46.15 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 27 Nov 2014 04:46:16 -0800 (PST)
Message-ID: <54771D16.4090607@linaro.org>
Date: Thu, 27 Nov 2014 12:46:14 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<1417084837.12784.5.camel@citrix.com>
	<alpine.DEB.2.02.1411271049130.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411271049130.14135@kaball.uk.xensource.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
 Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On 27/11/14 10:51, Stefano Stabellini wrote:
> On Thu, 27 Nov 2014, Ian Campbell wrote:
>> On Tue, 2014-11-25 at 17:44 +0000, Julien Grall wrote:
>>> ARMv8 model may not disable correctly the timer interrupt when Xen
>>
>> "correct disable"
>>
>>> context switch to an idle vCPU. Therefore Xen may receive a spurious
>>
>> "context switches" and s/spurious/unexpected/ (since spurious has a
>> specific meaning in the h/w which does not match what is happening here)
>>
>>> timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
>>> when trying to inject the interrupt with the following stack trace.
>>>
>>> (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
>>> (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
>>> (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
>>> (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
>>> (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
>>> (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
>>> (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
>>> (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
>>> (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
>>> (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
>>> (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
>>> (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
>>> (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
>>> (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
>>> (XEN)    [<0000000000000001>] 0000000000000001
>>>
>>> While we receive spurious virtual timer interrupt, this could be safely
>>> ignore for the time being. A proper fix need to be found for Xen 4.6.
>>>
>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>
>> Although I wonder if we should log, perhaps rate limited or only once.
>>
>> Also, I've some grammar nits (above and below) which I can fix on commit
>> if there is no resend...
>>
>>>
>>> ---
>>>
>>> This patch is a bug fix candidate for Xen 4.5. Any ARMv8 model may
>>> randomly crash when running Xen.
>>
>> CCing Konrad.
>>
>>> This patch don't inject the virtual timer interrupt if the current VCPU
>>> is the idle one. Entering in this function with the idle VCPU is already
>>> a bug itself. For now, I think this patch is the safest way to resolve
>>> the problem.
>>>
>>> Meanwhile, I'm investigating with ARM to see wheter the bug comes from
>>> Xen or the model.
> 
> It is worth noting that there are no bad side effects of this change:
> the vtimer_interrupt is always supposed to be received on non-idle
> domains. As Julien wrote, the fact that we are receiving a
> vtimer_interrupt in the idle_domain is a bug, one that probably comes
> from the ARM model not emulating hardware correctly.

ARM says:

"The v8A ARM ARM says that the signal output will be disabled if , so
the signal will be set to 0.
However, how this is treated by the GIC depends on its configuration."

So I'm not so sure it's a model bug.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:46:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtySi-0005xO-4A; Thu, 27 Nov 2014 12:46:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XtySg-0005wm-98
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 12:46:18 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	AA/1D-22737-91D17745; Thu, 27 Nov 2014 12:46:17 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417092377!8242106!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32207 invoked from network); 27 Nov 2014 12:46:17 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 12:46:17 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so6371730wgh.17
	for <xen-devel@lists.xenproject.org>;
	Thu, 27 Nov 2014 04:46:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=pXKTpWYmTzaBKxdFhU1DTWQTJjsgSHve5WXOrTL6QmA=;
	b=e5TqLXER99VWtOJUfRRGDXE1gDhKdzQDcvzDy8vf5GsZdjz0csg6svmCwBQDcuT+zd
	k87u8JQLUFcEWvN8+2ojytGxNDwzsJWWKr7DnwVD1IIcC87GvXHBl3faB7zSAl+VyPgx
	UWpr3h27jCZ8SleXXO84TgjDxDqAArbXwWkG+5LHCBauZ5LG7NOYoPsG6OFxT9VLebM3
	HEQ78C70uWNzkqlGiRydOdsWmRcS1a6AgT+T5rixK86d6LZfymMYPZ63t0/ZG6wkFdAI
	eo1dlMYT6U5IFBT3Mkz5LPPuq2Tko5JMXukNFhBJQ8an9OvU5sje0vGRY65HhTpzSAzd
	PkIQ==
X-Gm-Message-State: ALoCoQlbppPIfkzToEflH9p7k5JkglHpAPb5C2iiz87J/Bfk/u9jl5zfNW3yFJXxrYDLH0uTTRr0
X-Received: by 10.194.193.38 with SMTP id hl6mr13677611wjc.38.1417092376819;
	Thu, 27 Nov 2014 04:46:16 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	hz9sm10576786wjb.17.2014.11.27.04.46.15 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 27 Nov 2014 04:46:16 -0800 (PST)
Message-ID: <54771D16.4090607@linaro.org>
Date: Thu, 27 Nov 2014 12:46:14 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<1417084837.12784.5.camel@citrix.com>
	<alpine.DEB.2.02.1411271049130.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411271049130.14135@kaball.uk.xensource.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
 Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On 27/11/14 10:51, Stefano Stabellini wrote:
> On Thu, 27 Nov 2014, Ian Campbell wrote:
>> On Tue, 2014-11-25 at 17:44 +0000, Julien Grall wrote:
>>> ARMv8 model may not disable correctly the timer interrupt when Xen
>>
>> "correct disable"
>>
>>> context switch to an idle vCPU. Therefore Xen may receive a spurious
>>
>> "context switches" and s/spurious/unexpected/ (since spurious has a
>> specific meaning in the h/w which does not match what is happening here)
>>
>>> timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
>>> when trying to inject the interrupt with the following stack trace.
>>>
>>> (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
>>> (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
>>> (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
>>> (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
>>> (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
>>> (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
>>> (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
>>> (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
>>> (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
>>> (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
>>> (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
>>> (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
>>> (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
>>> (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
>>> (XEN)    [<0000000000000001>] 0000000000000001
>>>
>>> While we receive spurious virtual timer interrupt, this could be safely
>>> ignore for the time being. A proper fix need to be found for Xen 4.6.
>>>
>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>
>> Although I wonder if we should log, perhaps rate limited or only once.
>>
>> Also, I've some grammar nits (above and below) which I can fix on commit
>> if there is no resend...
>>
>>>
>>> ---
>>>
>>> This patch is a bug fix candidate for Xen 4.5. Any ARMv8 model may
>>> randomly crash when running Xen.
>>
>> CCing Konrad.
>>
>>> This patch don't inject the virtual timer interrupt if the current VCPU
>>> is the idle one. Entering in this function with the idle VCPU is already
>>> a bug itself. For now, I think this patch is the safest way to resolve
>>> the problem.
>>>
>>> Meanwhile, I'm investigating with ARM to see wheter the bug comes from
>>> Xen or the model.
> 
> It is worth noting that there are no bad side effects of this change:
> the vtimer_interrupt is always supposed to be received on non-idle
> domains. As Julien wrote, the fact that we are receiving a
> vtimer_interrupt in the idle_domain is a bug, one that probably comes
> from the ARM model not emulating hardware correctly.

ARM says:

"The v8A ARM ARM says that the signal output will be disabled if , so
the signal will be set to 0.
However, how this is treated by the GIC depends on its configuration."

So I'm not so sure it's a model bug.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:49:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtyVV-0006CP-My; Thu, 27 Nov 2014 12:49:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XtyVU-0006CC-9q
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 12:49:12 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	00/1E-01660-7CD17745; Thu, 27 Nov 2014 12:49:11 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417092549!8242813!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22833 invoked from network); 27 Nov 2014 12:49:10 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 12:49:10 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so6272047wgh.26
	for <xen-devel@lists.xenproject.org>;
	Thu, 27 Nov 2014 04:49:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=0Z5sgdLT+dUAQnKiFC+QJNs5BZu9Gwly6AP2k7uRl68=;
	b=F/btXaLYwr4JfOY35rKrd5mlmGbohXQqXbyBWB28jPdMKWtD/G8eLUNuamGEwwic7I
	yktNK76v3o3EulymmWoOHqR1+KUQNweJY92MT6yJqH+6b5dAmFLep8lP5Pn7Jep/ihlp
	bGGGPQHNLRAyi2joZtVTj7JdtC6hJ6Ln2OWACeU6wkfepjCx36JdbBCiLzhAqgZMQKVO
	nOoAgrWCqT9gIHVFL0OzvjeknzC+LRt8mAHlsaVwUD7xCI/1ZYX9FdG3b//jZwmJpHQi
	Xpn2IZ50gQNbnHUhUtg81Ig7ggXyc3hapkcQqYZ76DVXr5N55v5wn7ez9whYnxFMZol1
	GFqA==
X-Gm-Message-State: ALoCoQm6TbkAfgs8PqSWLAR6C9m/r40t/eDti8O4xcrJUuXL25OuPvyl+zI7Twr0nQI197FSYZFy
X-Received: by 10.180.78.73 with SMTP id z9mr50052475wiw.52.1417092549749;
	Thu, 27 Nov 2014 04:49:09 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	nj9sm11318875wic.10.2014.11.27.04.49.07 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 27 Nov 2014 04:49:08 -0800 (PST)
Message-ID: <54771DC2.2060902@linaro.org>
Date: Thu, 27 Nov 2014 12:49:06 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<1417084837.12784.5.camel@citrix.com>
In-Reply-To: <1417084837.12784.5.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
 Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 27/11/14 10:40, Ian Campbell wrote:
> On Tue, 2014-11-25 at 17:44 +0000, Julien Grall wrote:
>> ARMv8 model may not disable correctly the timer interrupt when Xen
> 
> "correct disable"
> 
>> context switch to an idle vCPU. Therefore Xen may receive a spurious
> 
> "context switches" and s/spurious/unexpected/ (since spurious has a
> specific meaning in the h/w which does not match what is happening here)
> 
>> timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
>> when trying to inject the interrupt with the following stack trace.
>>
>> (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
>> (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
>> (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
>> (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
>> (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
>> (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
>> (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
>> (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
>> (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
>> (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
>> (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
>> (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
>> (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
>> (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
>> (XEN)    [<0000000000000001>] 0000000000000001
>>
>> While we receive spurious virtual timer interrupt, this could be safely
>> ignore for the time being. A proper fix need to be found for Xen 4.6.
>>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Although I wonder if we should log, perhaps rate limited or only once.

I don't think the printk is necessary, receiving this unexpected
interrupt is harmless from the perspective that the guest will still
work when the vCPU will run again.

> Also, I've some grammar nits (above and below) which I can fix on commit
> if there is no resend...

Thanks.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:49:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtyVV-0006CP-My; Thu, 27 Nov 2014 12:49:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XtyVU-0006CC-9q
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 12:49:12 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	00/1E-01660-7CD17745; Thu, 27 Nov 2014 12:49:11 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417092549!8242813!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22833 invoked from network); 27 Nov 2014 12:49:10 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 12:49:10 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so6272047wgh.26
	for <xen-devel@lists.xenproject.org>;
	Thu, 27 Nov 2014 04:49:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=0Z5sgdLT+dUAQnKiFC+QJNs5BZu9Gwly6AP2k7uRl68=;
	b=F/btXaLYwr4JfOY35rKrd5mlmGbohXQqXbyBWB28jPdMKWtD/G8eLUNuamGEwwic7I
	yktNK76v3o3EulymmWoOHqR1+KUQNweJY92MT6yJqH+6b5dAmFLep8lP5Pn7Jep/ihlp
	bGGGPQHNLRAyi2joZtVTj7JdtC6hJ6Ln2OWACeU6wkfepjCx36JdbBCiLzhAqgZMQKVO
	nOoAgrWCqT9gIHVFL0OzvjeknzC+LRt8mAHlsaVwUD7xCI/1ZYX9FdG3b//jZwmJpHQi
	Xpn2IZ50gQNbnHUhUtg81Ig7ggXyc3hapkcQqYZ76DVXr5N55v5wn7ez9whYnxFMZol1
	GFqA==
X-Gm-Message-State: ALoCoQm6TbkAfgs8PqSWLAR6C9m/r40t/eDti8O4xcrJUuXL25OuPvyl+zI7Twr0nQI197FSYZFy
X-Received: by 10.180.78.73 with SMTP id z9mr50052475wiw.52.1417092549749;
	Thu, 27 Nov 2014 04:49:09 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	nj9sm11318875wic.10.2014.11.27.04.49.07 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 27 Nov 2014 04:49:08 -0800 (PST)
Message-ID: <54771DC2.2060902@linaro.org>
Date: Thu, 27 Nov 2014 12:49:06 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<1417084837.12784.5.camel@citrix.com>
In-Reply-To: <1417084837.12784.5.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
 Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 27/11/14 10:40, Ian Campbell wrote:
> On Tue, 2014-11-25 at 17:44 +0000, Julien Grall wrote:
>> ARMv8 model may not disable correctly the timer interrupt when Xen
> 
> "correct disable"
> 
>> context switch to an idle vCPU. Therefore Xen may receive a spurious
> 
> "context switches" and s/spurious/unexpected/ (since spurious has a
> specific meaning in the h/w which does not match what is happening here)
> 
>> timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
>> when trying to inject the interrupt with the following stack trace.
>>
>> (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
>> (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
>> (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
>> (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
>> (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
>> (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
>> (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
>> (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
>> (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
>> (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
>> (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
>> (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
>> (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
>> (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
>> (XEN)    [<0000000000000001>] 0000000000000001
>>
>> While we receive spurious virtual timer interrupt, this could be safely
>> ignore for the time being. A proper fix need to be found for Xen 4.6.
>>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Although I wonder if we should log, perhaps rate limited or only once.

I don't think the printk is necessary, receiving this unexpected
interrupt is harmless from the perspective that the guest will still
work when the vCPU will run again.

> Also, I've some grammar nits (above and below) which I can fix on commit
> if there is no resend...

Thanks.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:58:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1Xtye4-0006ZF-O9; Thu, 27 Nov 2014 12:58:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xtye3-0006ZA-Tc
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 12:58:04 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	A4/AD-02953-BDF17745; Thu, 27 Nov 2014 12:58:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417093082!10619732!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24095 invoked from network); 27 Nov 2014 12:58:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 12:58:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 12:58:02 +0000
Message-Id: <54772DE9020000780004B2DF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 12:58:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <547729AF020000780004B2A7@mail.emea.novell.com>
	<54771D0A.2010901@citrix.com>
In-Reply-To: <54771D0A.2010901@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/HVM: prevent infinite VM entry retries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 13:46, <andrew.cooper3@citrix.com> wrote:
> On 27/11/14 12:39, Jan Beulich wrote:
>>      if ( unlikely(exit_reason == VMEXIT_INVALID) )
>>      {
> 
> I think it would be good to retain the printk here from previous
> versions of the patch, specifically identifies the below vmcb dump as
> caused by a failed vmentry.  As it stands, it is a vmcb dump with no
> other context.
> 
> Either way, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

I meant to do so and then forgot. Added to the to be committed
version.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 12:58:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 12: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 1Xtye4-0006ZF-O9; Thu, 27 Nov 2014 12:58:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xtye3-0006ZA-Tc
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 12:58:04 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	A4/AD-02953-BDF17745; Thu, 27 Nov 2014 12:58:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417093082!10619732!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24095 invoked from network); 27 Nov 2014 12:58:02 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 12:58:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 12:58:02 +0000
Message-Id: <54772DE9020000780004B2DF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 12:58:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <547729AF020000780004B2A7@mail.emea.novell.com>
	<54771D0A.2010901@citrix.com>
In-Reply-To: <54771D0A.2010901@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/HVM: prevent infinite VM entry retries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 13:46, <andrew.cooper3@citrix.com> wrote:
> On 27/11/14 12:39, Jan Beulich wrote:
>>      if ( unlikely(exit_reason == VMEXIT_INVALID) )
>>      {
> 
> I think it would be good to retain the printk here from previous
> versions of the patch, specifically identifies the below vmcb dump as
> caused by a failed vmentry.  As it stands, it is a vmcb dump with no
> other context.
> 
> Either way, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

I meant to do so and then forgot. Added to the to be committed
version.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 13:06:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 13: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 1Xtym5-0006vT-Mh; Thu, 27 Nov 2014 13:06:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xtym4-0006vO-Dh
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 13:06:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A4/53-09842-BC127745; Thu, 27 Nov 2014 13:06:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417093577!11854286!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27471 invoked from network); 27 Nov 2014 13:06:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 13:06:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197170115"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 08:06:15 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xtylz-0000h5-1j;
	Thu, 27 Nov 2014 13:06:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xtyly-0006S1-Lm;
	Thu, 27 Nov 2014 13:06:14 +0000
Date: Thu, 27 Nov 2014 13:06:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31874-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31874: trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31874 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31874/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           3 host-install(3)         broken REGR. vs. 31860
 build-armhf-pvops             3 host-install(3)         broken REGR. vs. 31860
 build-i386-pvops              3 host-install(3)         broken REGR. vs. 31860

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              f37627ee72e40d54d1c3d4da95ebdf2caec9b47a
baseline version:
 libvirt              7296e896c92c64ec5653095bcc2ed86b6a72a7d5

------------------------------------------------------------
People who touched revisions under test:
  Jiri Denemark <jdenemar@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          broken  
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf-libvirt host-install(3)
broken-step build-armhf-pvops host-install(3)
broken-step build-i386-pvops host-install(3)

Not pushing.

------------------------------------------------------------
commit f37627ee72e40d54d1c3d4da95ebdf2caec9b47a
Author: Jiri Denemark <jdenemar@redhat.com>
Date:   Mon Nov 24 17:37:13 2014 +0100

    util: Avoid calling closedir(NULL)
    
    Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 13:06:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 13: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 1Xtym5-0006vT-Mh; Thu, 27 Nov 2014 13:06:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xtym4-0006vO-Dh
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 13:06:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A4/53-09842-BC127745; Thu, 27 Nov 2014 13:06:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417093577!11854286!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27471 invoked from network); 27 Nov 2014 13:06:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 13:06:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197170115"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 08:06:15 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xtylz-0000h5-1j;
	Thu, 27 Nov 2014 13:06:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xtyly-0006S1-Lm;
	Thu, 27 Nov 2014 13:06:14 +0000
Date: Thu, 27 Nov 2014 13:06:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31874-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31874: trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31874 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31874/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           3 host-install(3)         broken REGR. vs. 31860
 build-armhf-pvops             3 host-install(3)         broken REGR. vs. 31860
 build-i386-pvops              3 host-install(3)         broken REGR. vs. 31860

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              f37627ee72e40d54d1c3d4da95ebdf2caec9b47a
baseline version:
 libvirt              7296e896c92c64ec5653095bcc2ed86b6a72a7d5

------------------------------------------------------------
People who touched revisions under test:
  Jiri Denemark <jdenemar@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          broken  
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf-libvirt host-install(3)
broken-step build-armhf-pvops host-install(3)
broken-step build-i386-pvops host-install(3)

Not pushing.

------------------------------------------------------------
commit f37627ee72e40d54d1c3d4da95ebdf2caec9b47a
Author: Jiri Denemark <jdenemar@redhat.com>
Date:   Mon Nov 24 17:37:13 2014 +0100

    util: Avoid calling closedir(NULL)
    
    Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 13:06:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 13:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtymS-0006xN-2s; Thu, 27 Nov 2014 13:06:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtymQ-0006xB-3m
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 13:06:42 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	06/57-27584-1E127745; Thu, 27 Nov 2014 13:06:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417093600!13642893!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5826 invoked from network); 27 Nov 2014 13:06:41 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 13:06:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 13:06:40 +0000
Message-Id: <54772FF1020000780004B302@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 13:06:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1417086368-5912-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1417086368-5912-1-git-send-email-andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] docs/commandline: Refresh document
	for 4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.11.14 at 12:06, <andrew.cooper3@citrix.com> wrote:
> Konrad: A release ack please.  It would be nice if the command line
> documentation was correct for 4.5.

Honestly, unless really controversial, I don't think release acks are
really needed for purely documentation changes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 13:06:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 13:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtymS-0006xN-2s; Thu, 27 Nov 2014 13:06:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XtymQ-0006xB-3m
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 13:06:42 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	06/57-27584-1E127745; Thu, 27 Nov 2014 13:06:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417093600!13642893!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5826 invoked from network); 27 Nov 2014 13:06:41 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 13:06:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 13:06:40 +0000
Message-Id: <54772FF1020000780004B302@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 13:06:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1417086368-5912-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1417086368-5912-1-git-send-email-andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] docs/commandline: Refresh document
	for 4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.11.14 at 12:06, <andrew.cooper3@citrix.com> wrote:
> Konrad: A release ack please.  It would be nice if the command line
> documentation was correct for 4.5.

Honestly, unless really controversial, I don't think release acks are
really needed for purely documentation changes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 14:14:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 14:14:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtzpL-0000OO-6U; Thu, 27 Nov 2014 14:13:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtzpK-0000OJ-6i
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 14:13:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D1/93-09842-99137745; Thu, 27 Nov 2014 14:13:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417097623!11869263!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23470 invoked from network); 27 Nov 2014 14:13:44 -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;
	27 Nov 2014 14:13:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197186419"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 09:13:39 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtzpC-000126-Gs;
	Thu, 27 Nov 2014 14:13:38 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtzpC-0002yq-AA;
	Thu, 27 Nov 2014 14:13:38 +0000
Date: Thu, 27 Nov 2014 14:13:38 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31875-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31875: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31875 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31875/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   3 host-install(3)         broken REGR. vs. 31851

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 build-amd64-rumpuserxen       1 build-check(1)               blocked  n/a

version targeted for testing:
 rumpuserxen          6dac8499151377c6e5eb57b5bf1fff7b62776ca5
baseline version:
 rumpuserxen          a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0

------------------------------------------------------------
People who touched revisions under test:
  Antti Kantee <pooka@iki.fi>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      blocked 
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit 6dac8499151377c6e5eb57b5bf1fff7b62776ca5
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 16 13:07:32 2014 +0000

    Add "ifconfig destroy" support
    
    compile-tested only

commit b3652debb5981dcf54578df906a8c5d223e103bf
Author: Antti Kantee <pooka@iki.fi>
Date:   Wed Nov 26 15:24:49 2014 +0000

    add missing warnx() %s parameter

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 14:14:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 14:14:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XtzpL-0000OO-6U; Thu, 27 Nov 2014 14:13:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XtzpK-0000OJ-6i
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 14:13:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D1/93-09842-99137745; Thu, 27 Nov 2014 14:13:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417097623!11869263!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23470 invoked from network); 27 Nov 2014 14:13:44 -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;
	27 Nov 2014 14:13:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197186419"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 09:13:39 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XtzpC-000126-Gs;
	Thu, 27 Nov 2014 14:13:38 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XtzpC-0002yq-AA;
	Thu, 27 Nov 2014 14:13:38 +0000
Date: Thu, 27 Nov 2014 14:13:38 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31875-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31875: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31875 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31875/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   3 host-install(3)         broken REGR. vs. 31851

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 build-amd64-rumpuserxen       1 build-check(1)               blocked  n/a

version targeted for testing:
 rumpuserxen          6dac8499151377c6e5eb57b5bf1fff7b62776ca5
baseline version:
 rumpuserxen          a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0

------------------------------------------------------------
People who touched revisions under test:
  Antti Kantee <pooka@iki.fi>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      blocked 
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit 6dac8499151377c6e5eb57b5bf1fff7b62776ca5
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 16 13:07:32 2014 +0000

    Add "ifconfig destroy" support
    
    compile-tested only

commit b3652debb5981dcf54578df906a8c5d223e103bf
Author: Antti Kantee <pooka@iki.fi>
Date:   Wed Nov 26 15:24:49 2014 +0000

    add missing warnx() %s parameter

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 14:33:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 14:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu08G-00010G-0A; Thu, 27 Nov 2014 14:33:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu08E-00010B-4G
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 14:33:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BE/F9-25276-D2637745; Thu, 27 Nov 2014 14:33:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417098795!11813528!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4375 invoked from network); 27 Nov 2014 14:33:16 -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;
	27 Nov 2014 14:33:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197452406"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 09:33:14 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu08A-00018R-6m;
	Thu, 27 Nov 2014 14:33:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu08A-0007OB-0E;
	Thu, 27 Nov 2014 14:33:14 +0000
Date: Thu, 27 Nov 2014 14:33:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31867-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31867: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31867 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31867/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    3 host-install(3)         broken REGR. vs. 31849
 test-amd64-i386-pair         7 xen-boot/src_host fail in 31857 REGR. vs. 31849

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)     broken pass in 31857
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)     broken pass in 31857
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)         broken pass in 31857
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 31857
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 31857
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)           broken pass in 31857
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 31857
 test-amd64-amd64-libvirt      3 host-install(3)           broken pass in 31857
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)        broken pass in 31857
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 31857
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3)   broken pass in 31857
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken pass in 31857
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 31857
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 31857

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 31857 REGR. vs. 31849

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start           fail in 31857 never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 31857 never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31857 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31857 never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop       fail in 31857 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31857 never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop      fail in 31857 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 31857 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31857 never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop            fail in 31857 never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 31857 never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop       fail in 31857 never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail in 31857 never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 31857 never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop            fail in 31857 never pass

version targeted for testing:
 seabios              b7f4a76a929ce4acd60e89aa273a8b208daa8233
baseline version:
 seabios              9f505f715793d99235bd6b4afb2ca7b96ba5729b

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   broken  
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         broken  
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     broken  
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           broken  
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-i386 host-install(3)
broken-step test-amd64-amd64-xl-qemut-winxpsp3 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-winxpsp3 host-install(3)
broken-step test-amd64-amd64-xl-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-sedf host-install(3)
broken-step test-amd64-amd64-xl host-install(3)
broken-step test-amd64-amd64-xl-winxpsp3 host-install(3)
broken-step test-amd64-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-amd64-libvirt host-install(3)
broken-step test-amd64-amd64-xl-pcipt-intel host-install(3)
broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-pair host-install/src_host(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)

Not pushing.

------------------------------------------------------------
commit b7f4a76a929ce4acd60e89aa273a8b208daa8233
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Mon Nov 17 08:32:00 2014 +0100

    add scripts/tarball.sh
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 14:33:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 14:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu08G-00010G-0A; Thu, 27 Nov 2014 14:33:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu08E-00010B-4G
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 14:33:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BE/F9-25276-D2637745; Thu, 27 Nov 2014 14:33:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417098795!11813528!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4375 invoked from network); 27 Nov 2014 14:33:16 -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;
	27 Nov 2014 14:33:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197452406"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 09:33:14 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu08A-00018R-6m;
	Thu, 27 Nov 2014 14:33:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu08A-0007OB-0E;
	Thu, 27 Nov 2014 14:33:14 +0000
Date: Thu, 27 Nov 2014 14:33:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31867-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31867: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31867 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31867/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    3 host-install(3)         broken REGR. vs. 31849
 test-amd64-i386-pair         7 xen-boot/src_host fail in 31857 REGR. vs. 31849

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)     broken pass in 31857
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)     broken pass in 31857
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)         broken pass in 31857
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 31857
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 31857
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)           broken pass in 31857
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 31857
 test-amd64-amd64-libvirt      3 host-install(3)           broken pass in 31857
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)        broken pass in 31857
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 31857
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3)   broken pass in 31857
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken pass in 31857
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 31857
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 31857

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 31857 REGR. vs. 31849

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start           fail in 31857 never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 31857 never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31857 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31857 never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop       fail in 31857 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31857 never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop      fail in 31857 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 31857 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31857 never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop            fail in 31857 never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 31857 never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop       fail in 31857 never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail in 31857 never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 31857 never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop            fail in 31857 never pass

version targeted for testing:
 seabios              b7f4a76a929ce4acd60e89aa273a8b208daa8233
baseline version:
 seabios              9f505f715793d99235bd6b4afb2ca7b96ba5729b

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   broken  
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         broken  
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     broken  
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           broken  
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-i386 host-install(3)
broken-step test-amd64-amd64-xl-qemut-winxpsp3 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-winxpsp3 host-install(3)
broken-step test-amd64-amd64-xl-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-sedf host-install(3)
broken-step test-amd64-amd64-xl host-install(3)
broken-step test-amd64-amd64-xl-winxpsp3 host-install(3)
broken-step test-amd64-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-amd64-libvirt host-install(3)
broken-step test-amd64-amd64-xl-pcipt-intel host-install(3)
broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-pair host-install/src_host(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)

Not pushing.

------------------------------------------------------------
commit b7f4a76a929ce4acd60e89aa273a8b208daa8233
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Mon Nov 17 08:32:00 2014 +0100

    add scripts/tarball.sh
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 14:38:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 14:38:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0Cl-00019v-S1; Thu, 27 Nov 2014 14:37:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu0Ck-00019q-JB
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 14:37:58 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	FC/3B-24859-54737745; Thu, 27 Nov 2014 14:37:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417099075!14201325!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6177 invoked from network); 27 Nov 2014 14:37:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 14:37:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197193303"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 09:37:54 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu0Cg-00019h-Gb;
	Thu, 27 Nov 2014 14:37:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu0Cg-0002We-A8;
	Thu, 27 Nov 2014 14:37:54 +0000
Date: Thu, 27 Nov 2014 14:37:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31863-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31863: 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 31863 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31863/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  7 debian-install            fail REGR. vs. 31855
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 31855
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)  broken REGR. vs. 31855
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 31855
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 31855
 test-amd64-amd64-libvirt      3 host-install(3)         broken REGR. vs. 31855
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31855
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 31855
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 31855
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 31855
 test-amd64-i386-xl-winxpsp3   3 host-install(3)         broken REGR. vs. 31855
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)    broken REGR. vs. 31855

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  8 debian-fixup              fail REGR. vs. 31855
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 31855
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31855

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 qemuu                2528043f1f299e0e88cb026f1ca7c40bbb4e1f80
baseline version:
 qemuu                ca6028185d19d3f2bd331c15175c3ef5afc30c77

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Markus Armbruster <armbru@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     broken  
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  broken  


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-qemut-win7-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-amd64-libvirt host-install(3)
broken-step test-amd64-amd64-xl-pcipt-intel host-install(3)
broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-xl-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-i386-xl-winxpsp3 host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3 host-install(3)

Not pushing.

------------------------------------------------------------
commit 2528043f1f299e0e88cb026f1ca7c40bbb4e1f80
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Nov 25 18:23:54 2014 +0000

    Update version for v2.2.0-rc3 release
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit df5b2adb7398d71016ee469f71e52075ed95e04e
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue Nov 25 14:54:17 2014 +0100

    input: move input-send-event into experimental namespace
    
    Ongoing discussions on how we are going to specify the console,
    so tag the command as experiental so we can refine things in
    the 2.3 development cycle.
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Message-id: 1416923657-10614-1-git-send-email-armbru@redhat.com
    [Spell out "not a stable API", and x- the QAPI schema, too]
    Signed-off-by: Markus Armbruster <armbru@redhat.com>
    Reviewed-by: Amos Kong <akong@redhat.com>
    Reviewed-by: Eric Blake <eblake@redhat.com>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 14:38:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 14:38:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0Cl-00019v-S1; Thu, 27 Nov 2014 14:37:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu0Ck-00019q-JB
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 14:37:58 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	FC/3B-24859-54737745; Thu, 27 Nov 2014 14:37:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417099075!14201325!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6177 invoked from network); 27 Nov 2014 14:37:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 14:37:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197193303"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 09:37:54 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu0Cg-00019h-Gb;
	Thu, 27 Nov 2014 14:37:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu0Cg-0002We-A8;
	Thu, 27 Nov 2014 14:37:54 +0000
Date: Thu, 27 Nov 2014 14:37:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31863-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31863: 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 31863 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31863/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  7 debian-install            fail REGR. vs. 31855
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 31855
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)  broken REGR. vs. 31855
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 31855
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 31855
 test-amd64-amd64-libvirt      3 host-install(3)         broken REGR. vs. 31855
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31855
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 31855
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 31855
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 31855
 test-amd64-i386-xl-winxpsp3   3 host-install(3)         broken REGR. vs. 31855
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)    broken REGR. vs. 31855

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  8 debian-fixup              fail REGR. vs. 31855
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 31855
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31855

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass

version targeted for testing:
 qemuu                2528043f1f299e0e88cb026f1ca7c40bbb4e1f80
baseline version:
 qemuu                ca6028185d19d3f2bd331c15175c3ef5afc30c77

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Markus Armbruster <armbru@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     broken  
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  broken  


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-qemut-win7-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-amd64-libvirt host-install(3)
broken-step test-amd64-amd64-xl-pcipt-intel host-install(3)
broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-xl-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-i386-xl-winxpsp3 host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3 host-install(3)

Not pushing.

------------------------------------------------------------
commit 2528043f1f299e0e88cb026f1ca7c40bbb4e1f80
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Nov 25 18:23:54 2014 +0000

    Update version for v2.2.0-rc3 release
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit df5b2adb7398d71016ee469f71e52075ed95e04e
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue Nov 25 14:54:17 2014 +0100

    input: move input-send-event into experimental namespace
    
    Ongoing discussions on how we are going to specify the console,
    so tag the command as experiental so we can refine things in
    the 2.3 development cycle.
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Message-id: 1416923657-10614-1-git-send-email-armbru@redhat.com
    [Spell out "not a stable API", and x- the QAPI schema, too]
    Signed-off-by: Markus Armbruster <armbru@redhat.com>
    Reviewed-by: Amos Kong <akong@redhat.com>
    Reviewed-by: Eric Blake <eblake@redhat.com>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 14:50:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 14:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0On-0001V7-4O; Thu, 27 Nov 2014 14:50:25 +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 1Xu0Ol-0001V2-DJ
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 14:50:23 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	A0/E3-22737-E2A37745; Thu, 27 Nov 2014 14:50:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417099820!13705812!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26261 invoked from network); 27 Nov 2014 14:50:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 14:50:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAREoDSd013876
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Nov 2014 14:50:14 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAREoBsw007840
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 27 Nov 2014 14:50:12 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAREoA2D017552; Thu, 27 Nov 2014 14:50:10 GMT
Message-Id: <201411271450.sAREoA2D017552@userz7021.oracle.com>
Received: from [IPv6:2607:fb90:2903:f7ec:49a4:cbd4:11c0:8e66] (/172.56.22.218)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 27 Nov 2014 06:50:10 -0800
Date: Thu, 27 Nov 2014 09:50:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
MIME-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	andrew.cooper3@citrix.com, Tim Deegan <tim@xen.org>,
	Xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] docs/commandline: Refresh document
	for 4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ck9uIE5vdiAyNywgMjAxNCA4OjA2IEFNLCBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5jb20+
IHdyb3RlOgo+Cj4gPj4+IE9uIDI3LjExLjE0IGF0IDEyOjA2LCA8YW5kcmV3LmNvb3BlcjNAY2l0
cml4LmNvbT4gd3JvdGU6IAo+ID4gS29ucmFkOiBBIHJlbGVhc2UgYWNrIHBsZWFzZS7CoCBJdCB3
b3VsZCBiZSBuaWNlIGlmIHRoZSBjb21tYW5kIGxpbmUgCj4gPiBkb2N1bWVudGF0aW9uIHdhcyBj
b3JyZWN0IGZvciA0LjUuIAo+Cj4gSG9uZXN0bHksIHVubGVzcyByZWFsbHkgY29udHJvdmVyc2lh
bCwgSSBkb24ndCB0aGluayByZWxlYXNlIGFja3MgYXJlIAo+IHJlYWxseSBuZWVkZWQgZm9yIHB1
cmVseSBkb2N1bWVudGF0aW9uIGNoYW5nZXMuIAoKPG5vZHM+CiAKPgo+IEphbiAKPgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 27 14:50:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 14:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0On-0001V7-4O; Thu, 27 Nov 2014 14:50:25 +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 1Xu0Ol-0001V2-DJ
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 14:50:23 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	A0/E3-22737-E2A37745; Thu, 27 Nov 2014 14:50:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417099820!13705812!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26261 invoked from network); 27 Nov 2014 14:50:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 14:50:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sAREoDSd013876
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Nov 2014 14:50:14 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAREoBsw007840
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 27 Nov 2014 14:50:12 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sAREoA2D017552; Thu, 27 Nov 2014 14:50:10 GMT
Message-Id: <201411271450.sAREoA2D017552@userz7021.oracle.com>
Received: from [IPv6:2607:fb90:2903:f7ec:49a4:cbd4:11c0:8e66] (/172.56.22.218)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 27 Nov 2014 06:50:10 -0800
Date: Thu, 27 Nov 2014 09:50:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
MIME-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	andrew.cooper3@citrix.com, Tim Deegan <tim@xen.org>,
	Xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] docs/commandline: Refresh document
	for 4.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ck9uIE5vdiAyNywgMjAxNCA4OjA2IEFNLCBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5jb20+
IHdyb3RlOgo+Cj4gPj4+IE9uIDI3LjExLjE0IGF0IDEyOjA2LCA8YW5kcmV3LmNvb3BlcjNAY2l0
cml4LmNvbT4gd3JvdGU6IAo+ID4gS29ucmFkOiBBIHJlbGVhc2UgYWNrIHBsZWFzZS7CoCBJdCB3
b3VsZCBiZSBuaWNlIGlmIHRoZSBjb21tYW5kIGxpbmUgCj4gPiBkb2N1bWVudGF0aW9uIHdhcyBj
b3JyZWN0IGZvciA0LjUuIAo+Cj4gSG9uZXN0bHksIHVubGVzcyByZWFsbHkgY29udHJvdmVyc2lh
bCwgSSBkb24ndCB0aGluayByZWxlYXNlIGFja3MgYXJlIAo+IHJlYWxseSBuZWVkZWQgZm9yIHB1
cmVseSBkb2N1bWVudGF0aW9uIGNoYW5nZXMuIAoKPG5vZHM+CiAKPgo+IEphbiAKPgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:00:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:00:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0Yj-0001rZ-7S; Thu, 27 Nov 2014 15:00:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xu0Yh-0001rU-Eo
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:00:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CD/41-15461-69C37745; Thu, 27 Nov 2014 15:00:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417100438!11855653!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3093 invoked from network); 27 Nov 2014 15:00:38 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 15:00:38 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xu0YJ-0008Ye-Av; Thu, 27 Nov 2014 15:00:15 +0000
Date: Thu, 27 Nov 2014 16:00:15 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141127150015.GC13236@deinos.phlegethon.org>
References: <546E32BB.8090909@citrix.com>
	<546F25700200007800049AB4@smtp.nue.novell.com>
	<546F19FF.5070706@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F19FF.5070706@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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

At 10:54 +0000 on 21 Nov (1416563695), Andrew Cooper wrote:
> On 21/11/14 10:43, Jan Beulich wrote:
> >>>> On 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
> >> Should the guest change the p2m structure during live migration, the
> >> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> >> resulting in bogus cross-referencing.  Should the guest change an entry
> >> in the p2m, the p2m frame itself will be resent as it would be marked as
> >> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> >> probably stale on the receiving side.
> > MMU_MACHPHYS_UPDATE processing marks the page being changed
> > as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
> > callers thereof) should do so too?
> >
> > Jan
> >
> 
> This is certainly needed to fix HVM ballooning and live migration
> issues

Agreed.  We should be marking HVM frames dirty when they have any p2m
update that changes the mapping.  Maybe in paging_write_p2m_entry() or
the various implementation-specific versions.

>, although now you point it out, it applies just as much to PV
> guests as HVM guests.
> 
> I believe this might allow the toolstack to avoid keeping a second copy
> of the p2m.

I don't think so. :(  Because the toolstack is reading the guest's own
p2m, there is still a race where:

 - guest calls physmap_add_page, as part of which Xen marks the pfn dirty;
 - toolstack reads + cleans the dirty bitmap;
 - toolstack reads the guest p2m and DTRT for this pfn;
 - guest updates its p2m with the result of the physmap_add_page call.

After that, if the guest doesn't dirty that pfn again it won't be
fixed up.

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 Nov 27 15:00:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:00:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0Yj-0001rZ-7S; Thu, 27 Nov 2014 15:00:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xu0Yh-0001rU-Eo
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:00:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CD/41-15461-69C37745; Thu, 27 Nov 2014 15:00:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417100438!11855653!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3093 invoked from network); 27 Nov 2014 15:00:38 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 15:00:38 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xu0YJ-0008Ye-Av; Thu, 27 Nov 2014 15:00:15 +0000
Date: Thu, 27 Nov 2014 16:00:15 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141127150015.GC13236@deinos.phlegethon.org>
References: <546E32BB.8090909@citrix.com>
	<546F25700200007800049AB4@smtp.nue.novell.com>
	<546F19FF.5070706@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F19FF.5070706@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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

At 10:54 +0000 on 21 Nov (1416563695), Andrew Cooper wrote:
> On 21/11/14 10:43, Jan Beulich wrote:
> >>>> On 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
> >> Should the guest change the p2m structure during live migration, the
> >> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> >> resulting in bogus cross-referencing.  Should the guest change an entry
> >> in the p2m, the p2m frame itself will be resent as it would be marked as
> >> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> >> probably stale on the receiving side.
> > MMU_MACHPHYS_UPDATE processing marks the page being changed
> > as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
> > callers thereof) should do so too?
> >
> > Jan
> >
> 
> This is certainly needed to fix HVM ballooning and live migration
> issues

Agreed.  We should be marking HVM frames dirty when they have any p2m
update that changes the mapping.  Maybe in paging_write_p2m_entry() or
the various implementation-specific versions.

>, although now you point it out, it applies just as much to PV
> guests as HVM guests.
> 
> I believe this might allow the toolstack to avoid keeping a second copy
> of the p2m.

I don't think so. :(  Because the toolstack is reading the guest's own
p2m, there is still a race where:

 - guest calls physmap_add_page, as part of which Xen marks the pfn dirty;
 - toolstack reads + cleans the dirty bitmap;
 - toolstack reads the guest p2m and DTRT for this pfn;
 - guest updates its p2m with the result of the physmap_add_page call.

After that, if the guest doesn't dirty that pfn again it won't be
fixed up.

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 Nov 27 15:01:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:01:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0Z3-0001tF-KT; Thu, 27 Nov 2014 15:01:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xu0Z3-0001t7-1u
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:01:01 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	7F/C5-27584-CAC37745; Thu, 27 Nov 2014 15:01:00 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417100455!13708452!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3375 invoked from network); 27 Nov 2014 15:00:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 15:00:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197198294"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 10:00:42 -0500
Message-ID: <54773C98.8010002@citrix.com>
Date: Thu, 27 Nov 2014 16:00:40 +0100
From: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1417020935-2934-1-git-send-email-wei.liu2@citrix.com>
	<54760EA5.1030407@citrix.com>
	<20141126174421.GA14481@zion.uk.xensource.com>
In-Reply-To: <20141126174421.GA14481@zion.uk.xensource.com>
Content-Length: 1445
X-DLP: MIA2
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.6] libxl,
 hotplug/Linux: default to phy backend for raw format file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 26/11/14 a les 18.44, Wei Liu ha escrit:
> On Wed, Nov 26, 2014 at 06:32:21PM +0100, Roger Pau Monn=E9 wrote:
>> El 26/11/14 a les 17.55, Wei Liu ha escrit:
>>> Modify libxl and hotplug script to allow raw format file to use phy
>>> backend.
>>>
>>> The block script now tests the path and determine the actual type of
>>> file (block device or regular file) then use the actual type to
>>> determine which branch to run.
>>>
>>> With these changes, plus the current ordering of backend preference (phy
>>>> qdisk > tap), we will use phy backend for raw format file by default.
>>
>> Maybe it's a stupid question, but I remember that last time this changed
>> was attempted it caused problems with local migration. Has this been fix=
ed?
>>
>> I'm asking because there's no comment of this in the commit message, and
>> the code doesn't seem to differ from the first try in 11a63a.
>>
> =

> Yes, it's fixed.
> =

> Actually I think the regression last time was not local migration but
> another problem.
> =

> This patch is different from the last one, libxl won't write
> "physical-device" if the file is regular file. I think last time the
> hotplug script was not run correctly due to that problem.

IMHO it would be good to add that to the commit message.

Acked-by: Roger Pau Monn=E9 <roger.pau@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:01:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:01:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0Z3-0001tF-KT; Thu, 27 Nov 2014 15:01:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xu0Z3-0001t7-1u
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:01:01 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	7F/C5-27584-CAC37745; Thu, 27 Nov 2014 15:01:00 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417100455!13708452!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3375 invoked from network); 27 Nov 2014 15:00:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 15:00:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="197198294"
Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 10:00:42 -0500
Message-ID: <54773C98.8010002@citrix.com>
Date: Thu, 27 Nov 2014 16:00:40 +0100
From: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1417020935-2934-1-git-send-email-wei.liu2@citrix.com>
	<54760EA5.1030407@citrix.com>
	<20141126174421.GA14481@zion.uk.xensource.com>
In-Reply-To: <20141126174421.GA14481@zion.uk.xensource.com>
Content-Length: 1445
X-DLP: MIA2
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.6] libxl,
 hotplug/Linux: default to phy backend for raw format file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 26/11/14 a les 18.44, Wei Liu ha escrit:
> On Wed, Nov 26, 2014 at 06:32:21PM +0100, Roger Pau Monn=E9 wrote:
>> El 26/11/14 a les 17.55, Wei Liu ha escrit:
>>> Modify libxl and hotplug script to allow raw format file to use phy
>>> backend.
>>>
>>> The block script now tests the path and determine the actual type of
>>> file (block device or regular file) then use the actual type to
>>> determine which branch to run.
>>>
>>> With these changes, plus the current ordering of backend preference (phy
>>>> qdisk > tap), we will use phy backend for raw format file by default.
>>
>> Maybe it's a stupid question, but I remember that last time this changed
>> was attempted it caused problems with local migration. Has this been fix=
ed?
>>
>> I'm asking because there's no comment of this in the commit message, and
>> the code doesn't seem to differ from the first try in 11a63a.
>>
> =

> Yes, it's fixed.
> =

> Actually I think the regression last time was not local migration but
> another problem.
> =

> This patch is different from the last one, libxl won't write
> "physical-device" if the file is regular file. I think last time the
> hotplug script was not run correctly due to that problem.

IMHO it would be good to add that to the commit message.

Acked-by: Roger Pau Monn=E9 <roger.pau@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:12:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15: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 1Xu0jr-0002Wj-Rs; Thu, 27 Nov 2014 15:12:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xu0jq-0002We-8e
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:12:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	78/3C-25276-94F37745; Thu, 27 Nov 2014 15:12:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417101127!11889328!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31790 invoked from network); 27 Nov 2014 15:12:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 15:12:09 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sARFC3OP005063
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Nov 2014 15:12:04 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sARFC1VE017926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Nov 2014 15:12:02 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sARFC11l001276; Thu, 27 Nov 2014 15:12:01 GMT
Message-Id: <201411271512.sARFC11l001276@userz7022.oracle.com>
Received: from [IPv6:2607:fb90:2903:f7ec:49a4:cbd4:11c0:8e66] (/172.56.22.218)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 27 Nov 2014 07:12:00 -0800
Date: Thu, 27 Nov 2014 10:11:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tim Deegan <tim@xen.org>
MIME-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [COVERITY ACCESS] Request for access to Coverity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ck9uIE5vdiAyNywgMjAxNCA2OjU5IEFNLCBUaW0gRGVlZ2FuIDx0aW1AeGVuLm9yZz4gd3JvdGU6
Cj4KPiBBdCAxMTozOSArMDAwMCBvbiAyNyBOb3YgKDE0MTcwODQ3OTcpLCBHZW9yZ2UgRHVubGFw
IHdyb3RlOiAKPiA+IC0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0gCj4gPiBIYXNo
OiBTSEE1MTIgCj4gPiAKPiA+IEkgYWdyZWUgdG8gdGhlIGNvbmRpdGlvbnMgaW4gdGhlIFhlblBy
b2plY3QgQ292ZXJpdHkgY29udHJpYnV0aW9uIAo+ID4gZ3VpZGVsaW5lcyBbMV0uIAo+ID4gCj4g
PiBJJ20gYSBkZXZlbG9wZXIgd29ya2luZyBmb3IgQ2l0cml4IFN5c3RlbXMgVUssIEx0ZC7CoCBJ
J3ZlIGJlZW4gYWN0aXZlIAo+ID4gaW4gdGhlIFhlbiBjb21tdW5pdHkgc2luY2UgMjAwNjsgSSB3
YXMgcmVsZWFzZSBjb29yZGluYXRvciBmb3IgdGhlIDQuMyAKPiA+IGFuZCA0LjQgcmVsZWFzZXMs
IGFuZCBJIGFtIGN1cnJlbnRseSBtYWludGFpbmVyIG9mIHRoZSBYZW4gc2NoZWR1bGluZyAKPiA+
IHN1YnN5c3RlbS4gCj4gPiAKPiA+IEkgd291bGQgbGlrZSBhY2Nlc3MgcHJpbWFyaWx5IHRvIGJl
IGFibGUgdG8gd3JpdGUgYW5kIHNwZWFrIAo+ID4gaW50ZWxsaWdlbnRseSBhYm91dCBYZW4gYW5k
IENvdmVyaXR5IGluIGJsb2cgcG9zdGluZ3MgYW5kIGNvbmZlcmVuY2UgCj4gPiB0YWxrcy7CoCBJ
IGZpZ3VyZSBpdCB3b3VsZCBiZSBlYXNpZXIgdG8gZ28gdGhyb3VnaCB0aGUgc3RhdHMgYW5kIAo+
ID4gaGlzdG9yeSBteXNlbGYsIHJhdGhlciB0aGFuIHRyeWluZyB0byBnZXQgc29tZSBvdGhlciBk
ZXZlbG9wZXIgdG8gZG8gCj4gPiBpdCBmb3IgbWUuwqAgKEFsdGhvdWdoIG9mIGNvdXJzZSBvbmNl
IEkgaGF2ZSBhY2Nlc3MgSSdsbCBwcm9iYWJseSBlbmQgCj4gPiB1cCBkb2luZyBzb21lIHdvcmsg
bG9va2luZyBhdCBzY2FucyBhbnl3YXkuKSAKPgo+ICsxIAoKKzEgdG9vLgo+Cj4gVGltLiAKPgo+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIAo+IFhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QgCj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcgCj4gaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsIApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:12:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15: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 1Xu0jr-0002Wj-Rs; Thu, 27 Nov 2014 15:12:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xu0jq-0002We-8e
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:12:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	78/3C-25276-94F37745; Thu, 27 Nov 2014 15:12:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417101127!11889328!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31790 invoked from network); 27 Nov 2014 15:12:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 15:12:09 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sARFC3OP005063
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Nov 2014 15:12:04 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sARFC1VE017926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Nov 2014 15:12:02 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])
	by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id
	sARFC11l001276; Thu, 27 Nov 2014 15:12:01 GMT
Message-Id: <201411271512.sARFC11l001276@userz7022.oracle.com>
Received: from [IPv6:2607:fb90:2903:f7ec:49a4:cbd4:11c0:8e66] (/172.56.22.218)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 27 Nov 2014 07:12:00 -0800
Date: Thu, 27 Nov 2014 10:11:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tim Deegan <tim@xen.org>
MIME-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [COVERITY ACCESS] Request for access to Coverity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ck9uIE5vdiAyNywgMjAxNCA2OjU5IEFNLCBUaW0gRGVlZ2FuIDx0aW1AeGVuLm9yZz4gd3JvdGU6
Cj4KPiBBdCAxMTozOSArMDAwMCBvbiAyNyBOb3YgKDE0MTcwODQ3OTcpLCBHZW9yZ2UgRHVubGFw
IHdyb3RlOiAKPiA+IC0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0gCj4gPiBIYXNo
OiBTSEE1MTIgCj4gPiAKPiA+IEkgYWdyZWUgdG8gdGhlIGNvbmRpdGlvbnMgaW4gdGhlIFhlblBy
b2plY3QgQ292ZXJpdHkgY29udHJpYnV0aW9uIAo+ID4gZ3VpZGVsaW5lcyBbMV0uIAo+ID4gCj4g
PiBJJ20gYSBkZXZlbG9wZXIgd29ya2luZyBmb3IgQ2l0cml4IFN5c3RlbXMgVUssIEx0ZC7CoCBJ
J3ZlIGJlZW4gYWN0aXZlIAo+ID4gaW4gdGhlIFhlbiBjb21tdW5pdHkgc2luY2UgMjAwNjsgSSB3
YXMgcmVsZWFzZSBjb29yZGluYXRvciBmb3IgdGhlIDQuMyAKPiA+IGFuZCA0LjQgcmVsZWFzZXMs
IGFuZCBJIGFtIGN1cnJlbnRseSBtYWludGFpbmVyIG9mIHRoZSBYZW4gc2NoZWR1bGluZyAKPiA+
IHN1YnN5c3RlbS4gCj4gPiAKPiA+IEkgd291bGQgbGlrZSBhY2Nlc3MgcHJpbWFyaWx5IHRvIGJl
IGFibGUgdG8gd3JpdGUgYW5kIHNwZWFrIAo+ID4gaW50ZWxsaWdlbnRseSBhYm91dCBYZW4gYW5k
IENvdmVyaXR5IGluIGJsb2cgcG9zdGluZ3MgYW5kIGNvbmZlcmVuY2UgCj4gPiB0YWxrcy7CoCBJ
IGZpZ3VyZSBpdCB3b3VsZCBiZSBlYXNpZXIgdG8gZ28gdGhyb3VnaCB0aGUgc3RhdHMgYW5kIAo+
ID4gaGlzdG9yeSBteXNlbGYsIHJhdGhlciB0aGFuIHRyeWluZyB0byBnZXQgc29tZSBvdGhlciBk
ZXZlbG9wZXIgdG8gZG8gCj4gPiBpdCBmb3IgbWUuwqAgKEFsdGhvdWdoIG9mIGNvdXJzZSBvbmNl
IEkgaGF2ZSBhY2Nlc3MgSSdsbCBwcm9iYWJseSBlbmQgCj4gPiB1cCBkb2luZyBzb21lIHdvcmsg
bG9va2luZyBhdCBzY2FucyBhbnl3YXkuKSAKPgo+ICsxIAoKKzEgdG9vLgo+Cj4gVGltLiAKPgo+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIAo+IFhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QgCj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcgCj4gaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsIApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:15:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:15:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0mg-0002cb-Di; Thu, 27 Nov 2014 15:15:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xu0mf-0002cS-7w
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:15:05 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FA/21-25276-8FF37745; Thu, 27 Nov 2014 15:15:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417101303!4577946!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31771 invoked from network); 27 Nov 2014 15:15:03 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 15:15:03 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xu0mL-0008oR-JF; Thu, 27 Nov 2014 15:14:47 +0000
Date: Thu, 27 Nov 2014 16:14:45 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141127151445.GD13236@deinos.phlegethon.org>
References: <546E32BB.8090909@citrix.com> <546ED07B.3030208@suse.com>
	<546F14BF.5030705@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F14BF.5030705@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Juergen Gross <jgross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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

At 10:32 +0000 on 21 Nov (1416562351), Andrew Cooper wrote:
> On 21/11/14 05:41, Juergen Gross wrote:
> > On 11/20/2014 07:28 PM, Andrew Cooper wrote:
> >> Hello,
> >>
> >> Tim, David and I were discussing this over lunch.  This email is a
> >> (hopefully accurate) account of our findings, and potential solutions.
> >> (If I have messed up, please shout.)
> >>
> >> Currently, correct live migration of PV domains relies on the toolstack
> >> (which has a live mapping of the guests p2m) not observing stale values
> >> when the guest updates its p2m, and the race condition between a p2m
> >> update and an m2p update.  Realistically, this means no updates to the
> >> p2m at all, due to several potential race conditions.  Should any race
> >> conditions happen (e.g. ballooning while live migrating), the effects
> >> could be anything from an aborted migration to VM memory corruption.
> >>
> >> It should be noted that migrationv2 does not fix any of this.  It alters
> >> the way in which some race conditions might be observed.  During
> >> development of migrationv2, there was an explicit non-requirement of
> >> fixing the existing Ballooning+LiveMigration issues we were aware,
> >> although at the time, we were not aware of this specific set of issues.
> >> Our goal was to simply make migrationv2 work in the same circumstances
> >> as previously, but with a bitness-agnostic wire format and
> >> forward-extensible protocol.
> >>
> >>
> >> As far as these issues are concerned, there are two distinct p2m
> >> modifications which we care about:
> >> 1) p2m structure changes (rearranging the layout of the p2m)
> >> 2) p2m content changes (altering entries in the p2m)
> >>
> >> There is no possible way for the toolstack to prevent a domain from
> >> altering its p2m.  At the moment, ballooning typically only occurs when
> >> requested by the toolstack, but the underlying operations
> >> (increase/decrease_reservation, mem_exchange, etc) can be used by the
> >> guest at any point.  This includes Wei's guest memory fragmentation
> >> changes.  Changes to the content of the p2m also occur for grant map and
> >> unmap operations.
> >>
> >>
> >> Currently in PV guests, the p2m is implemented using a 3-level tree,
> >> with its root in the guests shared_info page.  It provides a hard VM
> >> memory limit of 4TB for 32bit PV guests (which is far higher than the
> >> 128GB limit from the compat p2m mappings), or 512GB for 64bit PV guests.
> >>
> >> Juergen has a proposed new p2m interface using a virtual linear
> >> mapping.  This is conceptually similar to the previous implementation
> >> (which is fine from the toolstacks point of view), but far less
> >> complicated from the guests point of view, and removes the memory limits
> >> imposed by the p2m structure.
> >>
> >> The new virtual linear mapping suffers from the same interaction issues
> >> as the old 3-level tree did, but the introduction of the new interface
> >> affords us an opportunity to make all API modifications at once to
> >> reduce churn.
> >>
> >>
> >> During live migration, the toolstack maps the guests p2m into a linear
> >> mapping in the toolstacks virtual address space.  This is done once at
> >> the start of migration, and never subsequently altered.  During live
> >> migration, the p2m is cross-verified with the m2p, and frames are sent
> >> using pfns as a reference, as they will be located in different frames
> >> on the receiving side.
> >>
> >> Should the guest change the p2m structure during live migration, the
> >> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> >> resulting in bogus cross-referencing.  Should the guest change an entry
> >> in the p2m, the p2m frame itself will be resent as it would be marked as
> >> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> >> probably stale on the receiving side.
> >>
> >>
> >> Another factor which needs to be taken into account is Remus/COLO, which
> >> run the domains under live migration conditions for the duration of
> >> their lifetime.
> >>
> >> During the live part of migration, the toolstack already has to be able
> >> to tolerate failures to normalise the pagetables, which result as a
> >> consequent of the pagetables being in active.  These failures are fatal
> >> on the final iteration after the guest has been paused, but the same
> >> logic could be extended to p2m/m2p issues, if needed.
> >>
> >>
> >> There are several potential solutions to these problems.
> >>
> >> 1) Freeze the guests p2m during live migrate
> >>
> >> This is the simplest sounding option, but is quite problematic from the
> >> point of view of the guest.  It is essentially a shared spinlock between
> >> the toolstack and the guest kernel.  It would prevent any grant
> >> map/unmap operations from occurring, and might interact badly with
> >> certain p2m updated in the guest which would previously be expected to
> >> unconditionally succeed.
> >>
> >> Pros) (Can't think of any)
> >> Cons) Not easy to implement (even conceptually), requires invasive guest
> >> changes, will cripple Remus/COLO
> >>
> >>
> >> 2) Deep p2m dirty tracking
> >>
> >> In the case that a p2m frame is discovered dirty in the logdirty bitmap,
> >> we can be certain that a write has occurred to it, and in the common
> >> case, means that the mapping has changed.  The toolstack could maintain
> >> a non-live copy of the p2m which is updated as new frames are sent.
> >> When a dirty p2m frame is found, the live and non-live copies can be
> >> consulted to find which pfn mappings have changed, and locally mark all
> >> the altered pfns for retransmit.
> >>
> >> Pros) No guest changes required
> >> Cons) Toolstack needs to keep an additional copy of the guests p2m on
> >> the sending side
> >>
> >> 3) Eagerly check for p2m structure changes.
> >>
> >> p2m structure changes are rare after boot, but not impossible.  Each
> >> iteration of live migration, the toolstack can check for dirty
> >> higher-level p2m frames in the dirty bitmap.  In the case that a
> >> structure update occurs, the toolstack can use information it already
> >> has to calculate a subset of pfns affected by the update, and mark them
> >> for resending.  (This can currently be done to the frame granularity
> >> given the p2m frame lit, but in combination with 2), could result in
> >> fewer pfns needing resending.)
> >>
> >> Pros) No guest changes required.
> >> Cons) Moderately high toolstack overhead,  Possibility to resend far
> >> more pfns than strictly required.
> >>
> >> 4) Request p2m structure change updates from the guest
> >>
> >> The guest could provide a "p2m generation count" to allow the toolstack
> >> to evaluate whether the structure had changed.  This would allow the
> >> live part of migration to periodically re-evaluate whether it should
> >> remap the p2m to avoid stale mappings.
> >>
> >> Pros) Easy to implement alongside the virtual linear mapping support.
> >> Easy for toolstack and guest
> >> Cons) Only works with new virtual linear guests.
> >>
> >>
> >> Proposed solution:  A combination of 2, 3 and 4.
> >>
> >> For legacy 3-level p2m guests, the toolstack can detect p2m structure
> >> updates by tracking the p2m top and mid levels in the logdirty bitmap,
> >> and invalidating the modified subset of pfns.  It has to eagerly check
> >> the p2m frame list list mfn entry in the shared info to see whether the
> >> guest has swapped onto a completely new p2m.
> >>
> >> For a virtual linear map, the intermediate levels are not available to
> >> track, but we can require that the guest increment p2m generation clock
> >> in the shared info.  When the structure changes, the toolstack can remap
> >> the p2m and calculate the altered subset of pfns, and mark for resend.
> >>
> >> The toolstack must also track changes in the p2m itself, and compare to
> >> a local copy showing the mapping at the time at which the pfn was last
> >> sent.  This can be used to work out which p2m mappings have changed, and
> >> also be used to confirm whether the pfns on the receiving side are stale
> >> or not.
> >>
> >> I believe this covered all cases and race conditions.  In the case that
> >> the p2m is updated before the m2p, the p2m frame will be marked dirty in
> >> the bitmap, and discoverable on the next iteration.  At that point, if
> >> the p2m and m2p are inconsistent, the pfn will be deferred until the
> >> final iteration.  If not, the frame is sent and everything is all ok.
> >> In the case that the p2m is updated after the m2p, the p2m/m2p will be
> >> consistent when the dirty bitmap is acted on.
> >>
> >>
> >> Thoughts? (for anyone who has made it this far :)  I think I have
> >> covered everything.)
> >
> > Sounds okay.
> >
> > Two remarks regarding the virtual linear map:
> > - The intermediate levels could be tracked, as they are memory pages as
> >   well. It is not practical to do so, however, as there might be lots of
> >   changes not related to the p2m.
> 
> The intermediate levels are just pagetables, are they not? Or is there a
> separate tracking structure?

They are just pagetables, but the toolstack needs to filter out
unrelated changes (esp. in the higher-level pagetables).  That will
require keeping copies of the pagetables that map the p2m, but that
should be OK -- much cheaper than keeping copies of the p2m contents!

> > - The generation count is being checked by the tools in a lazy manner.
> >   This will require an increment of the count by the guest only after
> >   changing the structure of the p2m map, I think.
> 
> On further consideration, I think this needs to be a lockless
> producer/consumer interface, with increment once at start, and once
> again at the end.  The toolstack needs some ability to confirm that it
> has got a consistent mapping of the virtual p2m, as it cant practically
> detect updates via the logdirty bitmap.

I think it probably _can_ just use the log-dirty bitmap to track
changes, but having a double increment would save the tools from
reading garbage even if they have a live mapping of the guest p2m
(e.g. by making every p2m read a read-epoch/read-p2m/read-epoch triple).

OTOH if we want to support older guests we'll have to handle reading
garbage anyway, so maybe we should save ourselves all this mechanism
in the linear map case.

> It also occurs to me that the toolstack code needs to gain some use of
> ACCESS_ONCE() when reading the live p2m.

Good idea.  And document (if not already done) that the guest should
use atomic writes. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:15:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:15:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0mg-0002cb-Di; Thu, 27 Nov 2014 15:15:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xu0mf-0002cS-7w
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:15:05 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FA/21-25276-8FF37745; Thu, 27 Nov 2014 15:15:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417101303!4577946!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31771 invoked from network); 27 Nov 2014 15:15:03 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 15:15:03 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xu0mL-0008oR-JF; Thu, 27 Nov 2014 15:14:47 +0000
Date: Thu, 27 Nov 2014 16:14:45 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141127151445.GD13236@deinos.phlegethon.org>
References: <546E32BB.8090909@citrix.com> <546ED07B.3030208@suse.com>
	<546F14BF.5030705@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <546F14BF.5030705@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Juergen Gross <jgross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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

At 10:32 +0000 on 21 Nov (1416562351), Andrew Cooper wrote:
> On 21/11/14 05:41, Juergen Gross wrote:
> > On 11/20/2014 07:28 PM, Andrew Cooper wrote:
> >> Hello,
> >>
> >> Tim, David and I were discussing this over lunch.  This email is a
> >> (hopefully accurate) account of our findings, and potential solutions.
> >> (If I have messed up, please shout.)
> >>
> >> Currently, correct live migration of PV domains relies on the toolstack
> >> (which has a live mapping of the guests p2m) not observing stale values
> >> when the guest updates its p2m, and the race condition between a p2m
> >> update and an m2p update.  Realistically, this means no updates to the
> >> p2m at all, due to several potential race conditions.  Should any race
> >> conditions happen (e.g. ballooning while live migrating), the effects
> >> could be anything from an aborted migration to VM memory corruption.
> >>
> >> It should be noted that migrationv2 does not fix any of this.  It alters
> >> the way in which some race conditions might be observed.  During
> >> development of migrationv2, there was an explicit non-requirement of
> >> fixing the existing Ballooning+LiveMigration issues we were aware,
> >> although at the time, we were not aware of this specific set of issues.
> >> Our goal was to simply make migrationv2 work in the same circumstances
> >> as previously, but with a bitness-agnostic wire format and
> >> forward-extensible protocol.
> >>
> >>
> >> As far as these issues are concerned, there are two distinct p2m
> >> modifications which we care about:
> >> 1) p2m structure changes (rearranging the layout of the p2m)
> >> 2) p2m content changes (altering entries in the p2m)
> >>
> >> There is no possible way for the toolstack to prevent a domain from
> >> altering its p2m.  At the moment, ballooning typically only occurs when
> >> requested by the toolstack, but the underlying operations
> >> (increase/decrease_reservation, mem_exchange, etc) can be used by the
> >> guest at any point.  This includes Wei's guest memory fragmentation
> >> changes.  Changes to the content of the p2m also occur for grant map and
> >> unmap operations.
> >>
> >>
> >> Currently in PV guests, the p2m is implemented using a 3-level tree,
> >> with its root in the guests shared_info page.  It provides a hard VM
> >> memory limit of 4TB for 32bit PV guests (which is far higher than the
> >> 128GB limit from the compat p2m mappings), or 512GB for 64bit PV guests.
> >>
> >> Juergen has a proposed new p2m interface using a virtual linear
> >> mapping.  This is conceptually similar to the previous implementation
> >> (which is fine from the toolstacks point of view), but far less
> >> complicated from the guests point of view, and removes the memory limits
> >> imposed by the p2m structure.
> >>
> >> The new virtual linear mapping suffers from the same interaction issues
> >> as the old 3-level tree did, but the introduction of the new interface
> >> affords us an opportunity to make all API modifications at once to
> >> reduce churn.
> >>
> >>
> >> During live migration, the toolstack maps the guests p2m into a linear
> >> mapping in the toolstacks virtual address space.  This is done once at
> >> the start of migration, and never subsequently altered.  During live
> >> migration, the p2m is cross-verified with the m2p, and frames are sent
> >> using pfns as a reference, as they will be located in different frames
> >> on the receiving side.
> >>
> >> Should the guest change the p2m structure during live migration, the
> >> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> >> resulting in bogus cross-referencing.  Should the guest change an entry
> >> in the p2m, the p2m frame itself will be resent as it would be marked as
> >> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> >> probably stale on the receiving side.
> >>
> >>
> >> Another factor which needs to be taken into account is Remus/COLO, which
> >> run the domains under live migration conditions for the duration of
> >> their lifetime.
> >>
> >> During the live part of migration, the toolstack already has to be able
> >> to tolerate failures to normalise the pagetables, which result as a
> >> consequent of the pagetables being in active.  These failures are fatal
> >> on the final iteration after the guest has been paused, but the same
> >> logic could be extended to p2m/m2p issues, if needed.
> >>
> >>
> >> There are several potential solutions to these problems.
> >>
> >> 1) Freeze the guests p2m during live migrate
> >>
> >> This is the simplest sounding option, but is quite problematic from the
> >> point of view of the guest.  It is essentially a shared spinlock between
> >> the toolstack and the guest kernel.  It would prevent any grant
> >> map/unmap operations from occurring, and might interact badly with
> >> certain p2m updated in the guest which would previously be expected to
> >> unconditionally succeed.
> >>
> >> Pros) (Can't think of any)
> >> Cons) Not easy to implement (even conceptually), requires invasive guest
> >> changes, will cripple Remus/COLO
> >>
> >>
> >> 2) Deep p2m dirty tracking
> >>
> >> In the case that a p2m frame is discovered dirty in the logdirty bitmap,
> >> we can be certain that a write has occurred to it, and in the common
> >> case, means that the mapping has changed.  The toolstack could maintain
> >> a non-live copy of the p2m which is updated as new frames are sent.
> >> When a dirty p2m frame is found, the live and non-live copies can be
> >> consulted to find which pfn mappings have changed, and locally mark all
> >> the altered pfns for retransmit.
> >>
> >> Pros) No guest changes required
> >> Cons) Toolstack needs to keep an additional copy of the guests p2m on
> >> the sending side
> >>
> >> 3) Eagerly check for p2m structure changes.
> >>
> >> p2m structure changes are rare after boot, but not impossible.  Each
> >> iteration of live migration, the toolstack can check for dirty
> >> higher-level p2m frames in the dirty bitmap.  In the case that a
> >> structure update occurs, the toolstack can use information it already
> >> has to calculate a subset of pfns affected by the update, and mark them
> >> for resending.  (This can currently be done to the frame granularity
> >> given the p2m frame lit, but in combination with 2), could result in
> >> fewer pfns needing resending.)
> >>
> >> Pros) No guest changes required.
> >> Cons) Moderately high toolstack overhead,  Possibility to resend far
> >> more pfns than strictly required.
> >>
> >> 4) Request p2m structure change updates from the guest
> >>
> >> The guest could provide a "p2m generation count" to allow the toolstack
> >> to evaluate whether the structure had changed.  This would allow the
> >> live part of migration to periodically re-evaluate whether it should
> >> remap the p2m to avoid stale mappings.
> >>
> >> Pros) Easy to implement alongside the virtual linear mapping support.
> >> Easy for toolstack and guest
> >> Cons) Only works with new virtual linear guests.
> >>
> >>
> >> Proposed solution:  A combination of 2, 3 and 4.
> >>
> >> For legacy 3-level p2m guests, the toolstack can detect p2m structure
> >> updates by tracking the p2m top and mid levels in the logdirty bitmap,
> >> and invalidating the modified subset of pfns.  It has to eagerly check
> >> the p2m frame list list mfn entry in the shared info to see whether the
> >> guest has swapped onto a completely new p2m.
> >>
> >> For a virtual linear map, the intermediate levels are not available to
> >> track, but we can require that the guest increment p2m generation clock
> >> in the shared info.  When the structure changes, the toolstack can remap
> >> the p2m and calculate the altered subset of pfns, and mark for resend.
> >>
> >> The toolstack must also track changes in the p2m itself, and compare to
> >> a local copy showing the mapping at the time at which the pfn was last
> >> sent.  This can be used to work out which p2m mappings have changed, and
> >> also be used to confirm whether the pfns on the receiving side are stale
> >> or not.
> >>
> >> I believe this covered all cases and race conditions.  In the case that
> >> the p2m is updated before the m2p, the p2m frame will be marked dirty in
> >> the bitmap, and discoverable on the next iteration.  At that point, if
> >> the p2m and m2p are inconsistent, the pfn will be deferred until the
> >> final iteration.  If not, the frame is sent and everything is all ok.
> >> In the case that the p2m is updated after the m2p, the p2m/m2p will be
> >> consistent when the dirty bitmap is acted on.
> >>
> >>
> >> Thoughts? (for anyone who has made it this far :)  I think I have
> >> covered everything.)
> >
> > Sounds okay.
> >
> > Two remarks regarding the virtual linear map:
> > - The intermediate levels could be tracked, as they are memory pages as
> >   well. It is not practical to do so, however, as there might be lots of
> >   changes not related to the p2m.
> 
> The intermediate levels are just pagetables, are they not? Or is there a
> separate tracking structure?

They are just pagetables, but the toolstack needs to filter out
unrelated changes (esp. in the higher-level pagetables).  That will
require keeping copies of the pagetables that map the p2m, but that
should be OK -- much cheaper than keeping copies of the p2m contents!

> > - The generation count is being checked by the tools in a lazy manner.
> >   This will require an increment of the count by the guest only after
> >   changing the structure of the p2m map, I think.
> 
> On further consideration, I think this needs to be a lockless
> producer/consumer interface, with increment once at start, and once
> again at the end.  The toolstack needs some ability to confirm that it
> has got a consistent mapping of the virtual p2m, as it cant practically
> detect updates via the logdirty bitmap.

I think it probably _can_ just use the log-dirty bitmap to track
changes, but having a double increment would save the tools from
reading garbage even if they have a live mapping of the guest p2m
(e.g. by making every p2m read a read-epoch/read-p2m/read-epoch triple).

OTOH if we want to support older guests we'll have to handle reading
garbage anyway, so maybe we should save ourselves all this mechanism
in the linear map case.

> It also occurs to me that the toolstack code needs to gain some use of
> ACCESS_ONCE() when reading the live p2m.

Good idea.  And document (if not already done) that the guest should
use atomic writes. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:17:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:17:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0oV-0002lV-3C; Thu, 27 Nov 2014 15:16:59 +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 1Xu0oT-0002lO-Td
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:16:58 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	A0/F0-14727-96047745; Thu, 27 Nov 2014 15:16:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417101415!13683550!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4007 invoked from network); 27 Nov 2014 15:16:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 15:16:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,470,1413244800"; d="scan'208";a="197203254"
Message-ID: <54774064.4040106@citrix.com>
Date: Thu, 27 Nov 2014 15:16:52 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <546E32BB.8090909@citrix.com>	<546F25700200007800049AB4@smtp.nue.novell.com>	<546F19FF.5070706@citrix.com>
	<20141127150015.GC13236@deinos.phlegethon.org>
In-Reply-To: <20141127150015.GC13236@deinos.phlegethon.org>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 27/11/14 15:00, Tim Deegan wrote:
> At 10:54 +0000 on 21 Nov (1416563695), Andrew Cooper wrote:
>> On 21/11/14 10:43, Jan Beulich wrote:
>>>>>> On 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
>>>> Should the guest change the p2m structure during live migration, the
>>>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
>>>> resulting in bogus cross-referencing.  Should the guest change an entry
>>>> in the p2m, the p2m frame itself will be resent as it would be marked as
>>>> dirty in the logdirty bitmap, but the target pfn will remain unsent and
>>>> probably stale on the receiving side.
>>> MMU_MACHPHYS_UPDATE processing marks the page being changed
>>> as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
>>> callers thereof) should do so too?
>>>
>>> Jan
>>>
>> This is certainly needed to fix HVM ballooning and live migration
>> issues
> Agreed.  We should be marking HVM frames dirty when they have any p2m
> update that changes the mapping.  Maybe in paging_write_p2m_entry() or
> the various implementation-specific versions.
>
>> , although now you point it out, it applies just as much to PV
>> guests as HVM guests.
>>
>> I believe this might allow the toolstack to avoid keeping a second copy
>> of the p2m.
> I don't think so. :(  Because the toolstack is reading the guest's own
> p2m, there is still a race where:
>
>  - guest calls physmap_add_page, as part of which Xen marks the pfn dirty;
>  - toolstack reads + cleans the dirty bitmap;
>  - toolstack reads the guest p2m and DTRT for this pfn;
>  - guest updates its p2m with the result of the physmap_add_page call.
>
> After that, if the guest doesn't dirty that pfn again it won't be
> fixed up.

It will (I think).

In the above scenario, step 3 will (certainly in v2) fail the p2m/m2p
consistency check.  This error is currently fatal, but need to be made
nonfatal during the live part, and mark the pfn as deferred.

The deferred scheme is currently used to track pagetables which are
found to be in an inconsistent state, and causes them to be reconsidered
after pause.  As implemented in v2, the deferred bitmap is or'd into the
final dirty bitmap from Xen, before the last sweep through dirty pages.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:17:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:17:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0oV-0002lV-3C; Thu, 27 Nov 2014 15:16:59 +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 1Xu0oT-0002lO-Td
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:16:58 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	A0/F0-14727-96047745; Thu, 27 Nov 2014 15:16:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417101415!13683550!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4007 invoked from network); 27 Nov 2014 15:16:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 15:16:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,470,1413244800"; d="scan'208";a="197203254"
Message-ID: <54774064.4040106@citrix.com>
Date: Thu, 27 Nov 2014 15:16:52 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <546E32BB.8090909@citrix.com>	<546F25700200007800049AB4@smtp.nue.novell.com>	<546F19FF.5070706@citrix.com>
	<20141127150015.GC13236@deinos.phlegethon.org>
In-Reply-To: <20141127150015.GC13236@deinos.phlegethon.org>
X-DLP: MIA2
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 27/11/14 15:00, Tim Deegan wrote:
> At 10:54 +0000 on 21 Nov (1416563695), Andrew Cooper wrote:
>> On 21/11/14 10:43, Jan Beulich wrote:
>>>>>> On 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
>>>> Should the guest change the p2m structure during live migration, the
>>>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
>>>> resulting in bogus cross-referencing.  Should the guest change an entry
>>>> in the p2m, the p2m frame itself will be resent as it would be marked as
>>>> dirty in the logdirty bitmap, but the target pfn will remain unsent and
>>>> probably stale on the receiving side.
>>> MMU_MACHPHYS_UPDATE processing marks the page being changed
>>> as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
>>> callers thereof) should do so too?
>>>
>>> Jan
>>>
>> This is certainly needed to fix HVM ballooning and live migration
>> issues
> Agreed.  We should be marking HVM frames dirty when they have any p2m
> update that changes the mapping.  Maybe in paging_write_p2m_entry() or
> the various implementation-specific versions.
>
>> , although now you point it out, it applies just as much to PV
>> guests as HVM guests.
>>
>> I believe this might allow the toolstack to avoid keeping a second copy
>> of the p2m.
> I don't think so. :(  Because the toolstack is reading the guest's own
> p2m, there is still a race where:
>
>  - guest calls physmap_add_page, as part of which Xen marks the pfn dirty;
>  - toolstack reads + cleans the dirty bitmap;
>  - toolstack reads the guest p2m and DTRT for this pfn;
>  - guest updates its p2m with the result of the physmap_add_page call.
>
> After that, if the guest doesn't dirty that pfn again it won't be
> fixed up.

It will (I think).

In the above scenario, step 3 will (certainly in v2) fail the p2m/m2p
consistency check.  This error is currently fatal, but need to be made
nonfatal during the live part, and mark the pfn as deferred.

The deferred scheme is currently used to track pagetables which are
found to be in an inconsistent state, and causes them to be reconsidered
after pause.  As implemented in v2, the deferred bitmap is or'd into the
final dirty bitmap from Xen, before the last sweep through dirty pages.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:18:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:18:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0pO-0002r4-Hi; Thu, 27 Nov 2014 15:17:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xu0pN-0002qv-Pt
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:17:53 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	1B/97-02957-1A047745; Thu, 27 Nov 2014 15:17:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417101468!15286561!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16507 invoked from network); 27 Nov 2014 15:17:49 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 15:17:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sARFHgYp015186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Nov 2014 15:17:43 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sARFHde2029236
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 27 Nov 2014 15:17:40 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sARFHdBY001984; Thu, 27 Nov 2014 15:17:39 GMT
Received: from [IPv6:2607:fb90:2903:f7ec:49a4:cbd4:11c0:8e66] (/172.56.22.218)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 27 Nov 2014 07:17:38 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <1417080386-6662-1-git-send-email-olaf@aepfle.de>
References: <1417080386-6662-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 27 Nov 2014 10:17:32 -0500
To: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Message-ID: <5A6CF3C5-F945-4169-AF21-4C2737CA5D17@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] INSTALL: correct EXTRA_CFLAGS 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 November 27, 2014 4:26:26 AM EST, Olaf Hering <olaf@aepfle.de> wrote:
>The already documented configure patch was not applied.
>Adjust documentation to describe existing behaviour.
>
>Signed-off-by: Olaf Hering <olaf@aepfle.de>
>Cc: Ian Campbell <ian.campbell@citrix.com>
>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Reviewed-by: me.

Don't need an release ack for it.

>---
>v3: reword as suggested by Konrad, trim Cc list
>v2: resend due to lack of Cc: tags
>
> INSTALL | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
>diff --git a/INSTALL b/INSTALL
>index 6bb9d23..0bc67ea 100644
>--- a/INSTALL
>+++ b/INSTALL
>@@ -128,13 +128,6 @@ original xenstored will be used. Valid names are
>xenstored and
> oxenstored.
>   --with-xenstored=name
> 
>-Using additional CFLAGS to build tools running in dom0 is required
>when
>-building distro packages. This is the option to pass things like
>-RPM_OPT_FLAGS.
>-  --with-extra-cflags-tools=EXTRA_CFLAGS
>-  --with-extra-cflags-qemu-traditional=EXTRA_CFLAGS
>-  --with-extra-cflags-qemu-upstream=EXTRA_CFLAGS
>-
> Instead of starting the tools in dom0 with sysv runlevel scripts they
>can also be started by systemd. If this option is enabled xenstored
>will
> receive the communication socked directly from systemd. So starting it
>@@ -241,6 +234,13 @@ QEMU_UPSTREAM_URL=
> QEMU_TRADITIONAL_URL=
> SEABIOS_UPSTREAM_URL=
> 
>+Using additional CFLAGS to build tools which will run in dom0 is
>+required when building distro packages. These variables can be used to
>+pass RPM_OPT_FLAGS.
>+EXTRA_CFLAGS_XEN_TOOLS=
>+EXTRA_CFLAGS_QEMU_TRADITIONAL=
>+EXTRA_CFLAGS_QEMU_XEN=
>+
> This variable can be used to use DIR/include and DIR/lib during build.
> This is the same as PREPEND_LIB and PREPEND_INCLUDES. APPEND_LIB and
> APPEND_INCLUDES= will be appended to the CFLAGS/LDFLAGS variable.
>@@ -310,10 +310,10 @@ sudo make install BOOT_DIR=/ood/path/boot
>EFI_DIR=/odd/path/efi
> %build
> export WGET=$(type -P false)
> export GIT=$(type -P false)
>+export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
>+export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
>+export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
> %configure \
>-        --with-extra-cflags-tools="$RPM_OPT_FLAGS" \
>-        --with-extra-cflags-qemu-traditional="$RPM_OPT_FLAGS" \
>-        --with-extra-cflags-qemu-upstream="$RPM_OPT_FLAGS" \
>         --with-initddir=%{_initddir}
> unset CFLAGS CXXFLAGS FFLAGS LDFLAGS
> make



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:18:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:18:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0pO-0002r4-Hi; Thu, 27 Nov 2014 15:17:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xu0pN-0002qv-Pt
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:17:53 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	1B/97-02957-1A047745; Thu, 27 Nov 2014 15:17:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417101468!15286561!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16507 invoked from network); 27 Nov 2014 15:17:49 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 15:17:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with
	ESMTP id sARFHgYp015186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Nov 2014 15:17:43 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sARFHde2029236
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 27 Nov 2014 15:17:40 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])
	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	sARFHdBY001984; Thu, 27 Nov 2014 15:17:39 GMT
Received: from [IPv6:2607:fb90:2903:f7ec:49a4:cbd4:11c0:8e66] (/172.56.22.218)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 27 Nov 2014 07:17:38 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <1417080386-6662-1-git-send-email-olaf@aepfle.de>
References: <1417080386-6662-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 27 Nov 2014 10:17:32 -0500
To: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Message-ID: <5A6CF3C5-F945-4169-AF21-4C2737CA5D17@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] INSTALL: correct EXTRA_CFLAGS 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 November 27, 2014 4:26:26 AM EST, Olaf Hering <olaf@aepfle.de> wrote:
>The already documented configure patch was not applied.
>Adjust documentation to describe existing behaviour.
>
>Signed-off-by: Olaf Hering <olaf@aepfle.de>
>Cc: Ian Campbell <ian.campbell@citrix.com>
>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Reviewed-by: me.

Don't need an release ack for it.

>---
>v3: reword as suggested by Konrad, trim Cc list
>v2: resend due to lack of Cc: tags
>
> INSTALL | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
>diff --git a/INSTALL b/INSTALL
>index 6bb9d23..0bc67ea 100644
>--- a/INSTALL
>+++ b/INSTALL
>@@ -128,13 +128,6 @@ original xenstored will be used. Valid names are
>xenstored and
> oxenstored.
>   --with-xenstored=name
> 
>-Using additional CFLAGS to build tools running in dom0 is required
>when
>-building distro packages. This is the option to pass things like
>-RPM_OPT_FLAGS.
>-  --with-extra-cflags-tools=EXTRA_CFLAGS
>-  --with-extra-cflags-qemu-traditional=EXTRA_CFLAGS
>-  --with-extra-cflags-qemu-upstream=EXTRA_CFLAGS
>-
> Instead of starting the tools in dom0 with sysv runlevel scripts they
>can also be started by systemd. If this option is enabled xenstored
>will
> receive the communication socked directly from systemd. So starting it
>@@ -241,6 +234,13 @@ QEMU_UPSTREAM_URL=
> QEMU_TRADITIONAL_URL=
> SEABIOS_UPSTREAM_URL=
> 
>+Using additional CFLAGS to build tools which will run in dom0 is
>+required when building distro packages. These variables can be used to
>+pass RPM_OPT_FLAGS.
>+EXTRA_CFLAGS_XEN_TOOLS=
>+EXTRA_CFLAGS_QEMU_TRADITIONAL=
>+EXTRA_CFLAGS_QEMU_XEN=
>+
> This variable can be used to use DIR/include and DIR/lib during build.
> This is the same as PREPEND_LIB and PREPEND_INCLUDES. APPEND_LIB and
> APPEND_INCLUDES= will be appended to the CFLAGS/LDFLAGS variable.
>@@ -310,10 +310,10 @@ sudo make install BOOT_DIR=/ood/path/boot
>EFI_DIR=/odd/path/efi
> %build
> export WGET=$(type -P false)
> export GIT=$(type -P false)
>+export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
>+export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
>+export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
> %configure \
>-        --with-extra-cflags-tools="$RPM_OPT_FLAGS" \
>-        --with-extra-cflags-qemu-traditional="$RPM_OPT_FLAGS" \
>-        --with-extra-cflags-qemu-upstream="$RPM_OPT_FLAGS" \
>         --with-initddir=%{_initddir}
> unset CFLAGS CXXFLAGS FFLAGS LDFLAGS
> make



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:24:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:24:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0v9-0003Dt-At; Thu, 27 Nov 2014 15:23:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xu0v8-0003Do-0j
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:23:50 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	96/12-17694-50247745; Thu, 27 Nov 2014 15:23:49 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417101828!14302677!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21931 invoked from network); 27 Nov 2014 15:23:48 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 15:23:48 -0000
Received: by mail-wi0-f182.google.com with SMTP id h11so8643055wiw.9
	for <xen-devel@lists.xen.org>; Thu, 27 Nov 2014 07:23:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=FQvaOEO/Yq2PcACcauOlh2GydURb5Fr4GiVsEUM2XNU=;
	b=k7d48lmJTO7m/X2Bq/k0QeBUoH+iBrRq0WoV0NwytEtBHY/3G9Cj+0eWWVYHmJnFlb
	5pOI2juDDXn7pnmRVSzj23nHCWJ08jLqGXF1V46H3g7OCjsTDgLUYnvEEnd2lyaSM8vF
	t6Xy31i+luKePU+4wb0DjpWk84L2K9c3wNNknEtXkZTiL2xb7w37rhD7/6XcdyemtLzU
	ibP/iGqQjJBn0Nca7futEAHuHsQCAMohsi5v98M8jn3OHItHYFEkdgpStaY3GFxanTg0
	Dbsai+xUWdezbyv+AlkyanUvPEsotHMc/EXtuzIxUKzFXNb+72+b4gwi8f/zeIB4h7+r
	C2bw==
MIME-Version: 1.0
X-Received: by 10.180.98.135 with SMTP id ei7mr10369756wib.11.1417101828562;
	Thu, 27 Nov 2014 07:23:48 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Thu, 27 Nov 2014 07:23:48 -0800 (PST)
In-Reply-To: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
Date: Thu, 27 Nov 2014 15:23:48 +0000
X-Google-Sender-Auth: S7nxjF3XUgbDpIUyXeClJXOwL5o
Message-ID: <CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xsm/flask: improve unknown permission
	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, Nov 25, 2014 at 6:05 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> When an unknown domctl, sysctl, or other operation is encountered in the
> FLASK security server, use the allow_unknown bit in the security policy
> (set by running checkpolicy -U allow) to decide if the permission should
> be allowed or denied.  This allows new operations to be tested without
> needing to immediately add security checks; however, it is not flexible
> enough to avoid adding the actual permission checks.  An error message
> is printed to the hypervisor console when this fallback is encountered.

Thanks -- I do think as Konrad said however, that when building with
debug=y, we want the failure to be more obvious.  A crash is probably
the best thing.

I guess we want something like the following after the printk in
avc_unknown_permission()?

#ifndef NDEBUG
    BUG();
#endif

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:24:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:24:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu0v9-0003Dt-At; Thu, 27 Nov 2014 15:23:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Xu0v8-0003Do-0j
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:23:50 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	96/12-17694-50247745; Thu, 27 Nov 2014 15:23:49 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417101828!14302677!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21931 invoked from network); 27 Nov 2014 15:23:48 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 15:23:48 -0000
Received: by mail-wi0-f182.google.com with SMTP id h11so8643055wiw.9
	for <xen-devel@lists.xen.org>; Thu, 27 Nov 2014 07:23:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=FQvaOEO/Yq2PcACcauOlh2GydURb5Fr4GiVsEUM2XNU=;
	b=k7d48lmJTO7m/X2Bq/k0QeBUoH+iBrRq0WoV0NwytEtBHY/3G9Cj+0eWWVYHmJnFlb
	5pOI2juDDXn7pnmRVSzj23nHCWJ08jLqGXF1V46H3g7OCjsTDgLUYnvEEnd2lyaSM8vF
	t6Xy31i+luKePU+4wb0DjpWk84L2K9c3wNNknEtXkZTiL2xb7w37rhD7/6XcdyemtLzU
	ibP/iGqQjJBn0Nca7futEAHuHsQCAMohsi5v98M8jn3OHItHYFEkdgpStaY3GFxanTg0
	Dbsai+xUWdezbyv+AlkyanUvPEsotHMc/EXtuzIxUKzFXNb+72+b4gwi8f/zeIB4h7+r
	C2bw==
MIME-Version: 1.0
X-Received: by 10.180.98.135 with SMTP id ei7mr10369756wib.11.1417101828562;
	Thu, 27 Nov 2014 07:23:48 -0800 (PST)
Received: by 10.194.80.227 with HTTP; Thu, 27 Nov 2014 07:23:48 -0800 (PST)
In-Reply-To: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
Date: Thu, 27 Nov 2014 15:23:48 +0000
X-Google-Sender-Auth: S7nxjF3XUgbDpIUyXeClJXOwL5o
Message-ID: <CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xsm/flask: improve unknown permission
	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, Nov 25, 2014 at 6:05 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> When an unknown domctl, sysctl, or other operation is encountered in the
> FLASK security server, use the allow_unknown bit in the security policy
> (set by running checkpolicy -U allow) to decide if the permission should
> be allowed or denied.  This allows new operations to be tested without
> needing to immediately add security checks; however, it is not flexible
> enough to avoid adding the actual permission checks.  An error message
> is printed to the hypervisor console when this fallback is encountered.

Thanks -- I do think as Konrad said however, that when building with
debug=y, we want the failure to be more obvious.  A crash is probably
the best thing.

I guess we want something like the following after the printk in
avc_unknown_permission()?

#ifndef NDEBUG
    BUG();
#endif

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:29:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:29:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu101-0003Ok-1A; Thu, 27 Nov 2014 15:28:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xu0zy-0003Of-Ut
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:28:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AD/01-09842-23347745; Thu, 27 Nov 2014 15:28:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417102129!11909109!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30953 invoked from network); 27 Nov 2014 15:28:49 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 15:28:49 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xu0zg-00092U-9C; Thu, 27 Nov 2014 15:28:32 +0000
Date: Thu, 27 Nov 2014 16:28:32 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141127152832.GC13234@deinos.phlegethon.org>
References: <546E32BB.8090909@citrix.com>
	<546F25700200007800049AB4@smtp.nue.novell.com>
	<546F19FF.5070706@citrix.com>
	<20141127150015.GC13236@deinos.phlegethon.org>
	<54774064.4040106@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54774064.4040106@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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

At 15:16 +0000 on 27 Nov (1417097812), Andrew Cooper wrote:
> On 27/11/14 15:00, Tim Deegan wrote:
> > At 10:54 +0000 on 21 Nov (1416563695), Andrew Cooper wrote:
> >> On 21/11/14 10:43, Jan Beulich wrote:
> >>>>>> On 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
> >>>> Should the guest change the p2m structure during live migration, the
> >>>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> >>>> resulting in bogus cross-referencing.  Should the guest change an entry
> >>>> in the p2m, the p2m frame itself will be resent as it would be marked as
> >>>> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> >>>> probably stale on the receiving side.
> >>> MMU_MACHPHYS_UPDATE processing marks the page being changed
> >>> as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
> >>> callers thereof) should do so too?
> >>>
> >>> Jan
> >>>
> >> This is certainly needed to fix HVM ballooning and live migration
> >> issues
> > Agreed.  We should be marking HVM frames dirty when they have any p2m
> > update that changes the mapping.  Maybe in paging_write_p2m_entry() or
> > the various implementation-specific versions.
> >
> >> , although now you point it out, it applies just as much to PV
> >> guests as HVM guests.
> >>
> >> I believe this might allow the toolstack to avoid keeping a second copy
> >> of the p2m.
> > I don't think so. :(  Because the toolstack is reading the guest's own
> > p2m, there is still a race where:
> >
> >  - guest calls physmap_add_page, as part of which Xen marks the pfn dirty;
> >  - toolstack reads + cleans the dirty bitmap;
> >  - toolstack reads the guest p2m and DTRT for this pfn;
> >  - guest updates its p2m with the result of the physmap_add_page call.
> >
> > After that, if the guest doesn't dirty that pfn again it won't be
> > fixed up.
> 
> It will (I think).
> 
> In the above scenario, step 3 will (certainly in v2) fail the p2m/m2p
> consistency check.  This error is currently fatal, but need to be made
> nonfatal during the live part, and mark the pfn as deferred.

That doesn't work if the guest is mapping a new entry: the guest p2m
will show the pfn as unallocated, which is fine.

There's a similar race if the guest wants to move a frame from one pfn
to another, unless you mandate that the guest must do the m2p update
after all p2m updates.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:29:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:29:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu101-0003Ok-1A; Thu, 27 Nov 2014 15:28:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xu0zy-0003Of-Ut
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:28:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AD/01-09842-23347745; Thu, 27 Nov 2014 15:28:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417102129!11909109!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30953 invoked from network); 27 Nov 2014 15:28:49 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 15:28:49 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xu0zg-00092U-9C; Thu, 27 Nov 2014 15:28:32 +0000
Date: Thu, 27 Nov 2014 16:28:32 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141127152832.GC13234@deinos.phlegethon.org>
References: <546E32BB.8090909@citrix.com>
	<546F25700200007800049AB4@smtp.nue.novell.com>
	<546F19FF.5070706@citrix.com>
	<20141127150015.GC13236@deinos.phlegethon.org>
	<54774064.4040106@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54774064.4040106@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
	SAEximRunCond expanded to false
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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

At 15:16 +0000 on 27 Nov (1417097812), Andrew Cooper wrote:
> On 27/11/14 15:00, Tim Deegan wrote:
> > At 10:54 +0000 on 21 Nov (1416563695), Andrew Cooper wrote:
> >> On 21/11/14 10:43, Jan Beulich wrote:
> >>>>>> On 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
> >>>> Should the guest change the p2m structure during live migration, the
> >>>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> >>>> resulting in bogus cross-referencing.  Should the guest change an entry
> >>>> in the p2m, the p2m frame itself will be resent as it would be marked as
> >>>> dirty in the logdirty bitmap, but the target pfn will remain unsent and
> >>>> probably stale on the receiving side.
> >>> MMU_MACHPHYS_UPDATE processing marks the page being changed
> >>> as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
> >>> callers thereof) should do so too?
> >>>
> >>> Jan
> >>>
> >> This is certainly needed to fix HVM ballooning and live migration
> >> issues
> > Agreed.  We should be marking HVM frames dirty when they have any p2m
> > update that changes the mapping.  Maybe in paging_write_p2m_entry() or
> > the various implementation-specific versions.
> >
> >> , although now you point it out, it applies just as much to PV
> >> guests as HVM guests.
> >>
> >> I believe this might allow the toolstack to avoid keeping a second copy
> >> of the p2m.
> > I don't think so. :(  Because the toolstack is reading the guest's own
> > p2m, there is still a race where:
> >
> >  - guest calls physmap_add_page, as part of which Xen marks the pfn dirty;
> >  - toolstack reads + cleans the dirty bitmap;
> >  - toolstack reads the guest p2m and DTRT for this pfn;
> >  - guest updates its p2m with the result of the physmap_add_page call.
> >
> > After that, if the guest doesn't dirty that pfn again it won't be
> > fixed up.
> 
> It will (I think).
> 
> In the above scenario, step 3 will (certainly in v2) fail the p2m/m2p
> consistency check.  This error is currently fatal, but need to be made
> nonfatal during the live part, and mark the pfn as deferred.

That doesn't work if the guest is mapping a new entry: the guest p2m
will show the pfn as unallocated, which is fine.

There's a similar race if the guest wants to move a frame from one pfn
to another, unless you mandate that the guest must do the m2p update
after all p2m updates.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:34:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:34:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu14u-0003jh-Oj; Thu, 27 Nov 2014 15:33:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xu14t-0003jc-AP
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:33:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EE/B9-09842-26447745; Thu, 27 Nov 2014 15:33:54 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417102432!11829773!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23114 invoked from network); 27 Nov 2014 15:33:54 -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;
	27 Nov 2014 15:33:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,470,1413244800"; d="scan'208";a="197468706"
Message-ID: <5477445E.4040803@citrix.com>
Date: Thu, 27 Nov 2014 15:33:50 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>, Daniel De Graaf
	<dgdegra@tycho.nsa.gov>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
	<CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>
In-Reply-To: <CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xsm/flask: improve unknown permission
	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 27/11/14 15:23, George Dunlap wrote:
> On Tue, Nov 25, 2014 at 6:05 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> When an unknown domctl, sysctl, or other operation is encountered in the
>> FLASK security server, use the allow_unknown bit in the security policy
>> (set by running checkpolicy -U allow) to decide if the permission should
>> be allowed or denied.  This allows new operations to be tested without
>> needing to immediately add security checks; however, it is not flexible
>> enough to avoid adding the actual permission checks.  An error message
>> is printed to the hypervisor console when this fallback is encountered.
> Thanks -- I do think as Konrad said however, that when building with
> debug=y, we want the failure to be more obvious.  A crash is probably
> the best thing.
>
> I guess we want something like the following after the printk in
> avc_unknown_permission()?
>
> #ifndef NDEBUG
>     BUG();
> #endif

ASSERT(!"Flask default policy error");

provides rather more information in the panic message, and avoids the
#ifdefs.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:34:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:34:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu14u-0003jh-Oj; Thu, 27 Nov 2014 15:33:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xu14t-0003jc-AP
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:33:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EE/B9-09842-26447745; Thu, 27 Nov 2014 15:33:54 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417102432!11829773!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23114 invoked from network); 27 Nov 2014 15:33:54 -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;
	27 Nov 2014 15:33:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,470,1413244800"; d="scan'208";a="197468706"
Message-ID: <5477445E.4040803@citrix.com>
Date: Thu, 27 Nov 2014 15:33:50 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>, Daniel De Graaf
	<dgdegra@tycho.nsa.gov>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
	<CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>
In-Reply-To: <CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xsm/flask: improve unknown permission
	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 27/11/14 15:23, George Dunlap wrote:
> On Tue, Nov 25, 2014 at 6:05 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> When an unknown domctl, sysctl, or other operation is encountered in the
>> FLASK security server, use the allow_unknown bit in the security policy
>> (set by running checkpolicy -U allow) to decide if the permission should
>> be allowed or denied.  This allows new operations to be tested without
>> needing to immediately add security checks; however, it is not flexible
>> enough to avoid adding the actual permission checks.  An error message
>> is printed to the hypervisor console when this fallback is encountered.
> Thanks -- I do think as Konrad said however, that when building with
> debug=y, we want the failure to be more obvious.  A crash is probably
> the best thing.
>
> I guess we want something like the following after the printk in
> avc_unknown_permission()?
>
> #ifndef NDEBUG
>     BUG();
> #endif

ASSERT(!"Flask default policy error");

provides rather more information in the panic message, and avoids the
#ifdefs.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:41:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:41:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu1C2-0003sC-LQ; Thu, 27 Nov 2014 15:41:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xu1C1-0003s7-8R
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:41:17 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	1B/1D-24859-C1647745; Thu, 27 Nov 2014 15:41:16 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417102874!14217197!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17355 invoked from network); 27 Nov 2014 15:41:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 15:41:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,470,1413244800"; d="scan'208";a="197209200"
Message-ID: <54774617.2010809@citrix.com>
Date: Thu, 27 Nov 2014 15:41:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <546E32BB.8090909@citrix.com>
	<546F25700200007800049AB4@smtp.nue.novell.com>
	<546F19FF.5070706@citrix.com>
	<20141127150015.GC13236@deinos.phlegethon.org>
	<54774064.4040106@citrix.com>
	<20141127152832.GC13234@deinos.phlegethon.org>
In-Reply-To: <20141127152832.GC13234@deinos.phlegethon.org>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 27/11/14 15:28, Tim Deegan wrote:
> At 15:16 +0000 on 27 Nov (1417097812), Andrew Cooper wrote:
>> On 27/11/14 15:00, Tim Deegan wrote:
>>> At 10:54 +0000 on 21 Nov (1416563695), Andrew Cooper wrote:
>>>> On 21/11/14 10:43, Jan Beulich wrote:
>>>>>>>> On 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
>>>>>> Should the guest change the p2m structure during live migration, the
>>>>>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
>>>>>> resulting in bogus cross-referencing.  Should the guest change an entry
>>>>>> in the p2m, the p2m frame itself will be resent as it would be marked as
>>>>>> dirty in the logdirty bitmap, but the target pfn will remain unsent and
>>>>>> probably stale on the receiving side.
>>>>> MMU_MACHPHYS_UPDATE processing marks the page being changed
>>>>> as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
>>>>> callers thereof) should do so too?
>>>>>
>>>>> Jan
>>>>>
>>>> This is certainly needed to fix HVM ballooning and live migration
>>>> issues
>>> Agreed.  We should be marking HVM frames dirty when they have any p2m
>>> update that changes the mapping.  Maybe in paging_write_p2m_entry() or
>>> the various implementation-specific versions.
>>>
>>>> , although now you point it out, it applies just as much to PV
>>>> guests as HVM guests.
>>>>
>>>> I believe this might allow the toolstack to avoid keeping a second copy
>>>> of the p2m.
>>> I don't think so. :(  Because the toolstack is reading the guest's own
>>> p2m, there is still a race where:
>>>
>>>  - guest calls physmap_add_page, as part of which Xen marks the pfn dirty;
>>>  - toolstack reads + cleans the dirty bitmap;
>>>  - toolstack reads the guest p2m and DTRT for this pfn;
>>>  - guest updates its p2m with the result of the physmap_add_page call.
>>>
>>> After that, if the guest doesn't dirty that pfn again it won't be
>>> fixed up.
>> It will (I think).
>>
>> In the above scenario, step 3 will (certainly in v2) fail the p2m/m2p
>> consistency check.  This error is currently fatal, but need to be made
>> nonfatal during the live part, and mark the pfn as deferred.
> That doesn't work if the guest is mapping a new entry: the guest p2m
> will show the pfn as unallocated, which is fine.

Hmm - so it will.

>
> There's a similar race if the guest wants to move a frame from one pfn
> to another, unless you mandate that the guest must do the m2p update
> after all p2m updates.

We certainly can't retroactively enforce that, and thusfar are in a
position to provide this safety to older PV guests.

It looks like we absolutely do need a second copy of the guests p2m. 
While unfortunate, I suspect admins will begrudgingly accept extra
memory usage in preference to potential VM memory corruption on migrate.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 15:41:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 15:41:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu1C2-0003sC-LQ; Thu, 27 Nov 2014 15:41:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xu1C1-0003s7-8R
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 15:41:17 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	1B/1D-24859-C1647745; Thu, 27 Nov 2014 15:41:16 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417102874!14217197!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17355 invoked from network); 27 Nov 2014 15:41:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 15:41:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,470,1413244800"; d="scan'208";a="197209200"
Message-ID: <54774617.2010809@citrix.com>
Date: Thu, 27 Nov 2014 15:41:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <546E32BB.8090909@citrix.com>
	<546F25700200007800049AB4@smtp.nue.novell.com>
	<546F19FF.5070706@citrix.com>
	<20141127150015.GC13236@deinos.phlegethon.org>
	<54774064.4040106@citrix.com>
	<20141127152832.GC13234@deinos.phlegethon.org>
In-Reply-To: <20141127152832.GC13234@deinos.phlegethon.org>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [Xen-devel] Buggy interaction of live migration and p2m 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 27/11/14 15:28, Tim Deegan wrote:
> At 15:16 +0000 on 27 Nov (1417097812), Andrew Cooper wrote:
>> On 27/11/14 15:00, Tim Deegan wrote:
>>> At 10:54 +0000 on 21 Nov (1416563695), Andrew Cooper wrote:
>>>> On 21/11/14 10:43, Jan Beulich wrote:
>>>>>>>> On 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
>>>>>> Should the guest change the p2m structure during live migration, the
>>>>>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
>>>>>> resulting in bogus cross-referencing.  Should the guest change an entry
>>>>>> in the p2m, the p2m frame itself will be resent as it would be marked as
>>>>>> dirty in the logdirty bitmap, but the target pfn will remain unsent and
>>>>>> probably stale on the receiving side.
>>>>> MMU_MACHPHYS_UPDATE processing marks the page being changed
>>>>> as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
>>>>> callers thereof) should do so too?
>>>>>
>>>>> Jan
>>>>>
>>>> This is certainly needed to fix HVM ballooning and live migration
>>>> issues
>>> Agreed.  We should be marking HVM frames dirty when they have any p2m
>>> update that changes the mapping.  Maybe in paging_write_p2m_entry() or
>>> the various implementation-specific versions.
>>>
>>>> , although now you point it out, it applies just as much to PV
>>>> guests as HVM guests.
>>>>
>>>> I believe this might allow the toolstack to avoid keeping a second copy
>>>> of the p2m.
>>> I don't think so. :(  Because the toolstack is reading the guest's own
>>> p2m, there is still a race where:
>>>
>>>  - guest calls physmap_add_page, as part of which Xen marks the pfn dirty;
>>>  - toolstack reads + cleans the dirty bitmap;
>>>  - toolstack reads the guest p2m and DTRT for this pfn;
>>>  - guest updates its p2m with the result of the physmap_add_page call.
>>>
>>> After that, if the guest doesn't dirty that pfn again it won't be
>>> fixed up.
>> It will (I think).
>>
>> In the above scenario, step 3 will (certainly in v2) fail the p2m/m2p
>> consistency check.  This error is currently fatal, but need to be made
>> nonfatal during the live part, and mark the pfn as deferred.
> That doesn't work if the guest is mapping a new entry: the guest p2m
> will show the pfn as unallocated, which is fine.

Hmm - so it will.

>
> There's a similar race if the guest wants to move a frame from one pfn
> to another, unless you mandate that the guest must do the m2p update
> after all p2m updates.

We certainly can't retroactively enforce that, and thusfar are in a
position to provide this safety to older PV guests.

It looks like we absolutely do need a second copy of the guests p2m. 
While unfortunate, I suspect admins will begrudgingly accept extra
memory usage in preference to potential VM memory corruption on migrate.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 16:00:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 16:00:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu1UR-0004jZ-Te; Thu, 27 Nov 2014 16:00:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1Xu1UQ-0004jU-CI
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 16:00:18 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	33/27-17694-19A47745; Thu, 27 Nov 2014 16:00:17 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417104012!14262312!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28357 invoked from network); 27 Nov 2014 16:00:12 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 16:00:12 -0000
Received: by mail-wi0-f178.google.com with SMTP id hi2so8763918wib.11
	for <xen-devel@lists.xen.org>; Thu, 27 Nov 2014 08:00:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=6ll0pnxendmdyGdi4ZtMdY1qRKMdGb6DEZufyCgudyw=;
	b=UDZB9hcqIRkWzY2BmKmFLqCoPbWBAUWvNHKYbOB+MY9oi4yhVp2OR+IdM+qLm/faNQ
	zvJjvIoQjjTi7Rj1wyxcjzrVASde03/lQVWz666s3Df9SMoSw6rH71ACvVzu1JN41sGf
	qlMo+rwVYRHlmIcyWQxBzGN+oCEr1fUQKhh6ncJ7/D0RIFtSn//G5xLQepcpnEsNQX5t
	UZ4yqoeYPumFZjcgwh5x8zo6tY/8Rsx396IrgvAIuMIfrHGMfzF/8oI4CVa9gJx/Im2v
	GhTUpa7+upTbKBbAE+p7EE/4GcOQ78kQNbRHhjQ7Tn1A0GDzgZdVxKj7WXQhqs1YCj7m
	9Q6g==
X-Gm-Message-State: ALoCoQk6cgCdVnFVtsGQ1QngR+ps+AOfLJ7DfWPMImQ3VV9h5oqqKX7ny4PdLj0QYXSZ9DNxk/Xn
X-Received: by 10.180.72.33 with SMTP id a1mr51530836wiv.18.1417104012198;
	Thu, 27 Nov 2014 08:00:12 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	r10sm25831969wiy.13.2014.11.27.08.00.10 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 27 Nov 2014 08:00:11 -0800 (PST)
Message-ID: <54774AA8.7070907@m2r.biz>
Date: Thu, 27 Nov 2014 17:00:40 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Xen.org security team" <security@xen.org>, xen-devel@lists.xen.org, 
	xen-users@lists.xen.org
References: <E1XtxsT-0000TV-4i@xenbits.xen.org>
In-Reply-To: <E1XtxsT-0000TV-4i@xenbits.xen.org>
Cc: jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen Security Advisory 112 (CVE-2014-8867) -
 Insufficient bounding of "REP MOVS" to MMIO emulated inside 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: multipart/mixed; boundary="===============4098168859055349311=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4098168859055349311==
Content-Type: multipart/alternative;
 boundary="------------080409050505080702040502"

This is a multi-part message in MIME format.
--------------080409050505080702040502
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Il 27/11/2014 13:08, Xen.org security team ha scritto:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>              Xen Security Advisory CVE-2014-8867 / XSA-112
>                                version 5
>
>    Insufficient bounding of "REP MOVS" to MMIO emulated inside the hypervisor
>
> UPDATES IN VERSION 5
> ====================
>
> Public release.
>
> ISSUE DESCRIPTION
> =================
>
> Acceleration support for the "REP MOVS" instruction, when the first
> iteration accesses memory mapped I/O emulated internally in the
> hypervisor, incorrectly assumes that the whole range accessed is
> handled by the same hypervisor sub-component.
>
> IMPACT
> ======
>
> A buggy or malicious HVM guest can crash the host.

Sorry for the probably stupid question.
Can an hvm domU make crash the host with this issue or similar without 
show nothing on dom0 logs and also nothing visible on screen? (kernel 
panic or similar)
Recently for 2 times I had one xen 4.4.1 hosts with some hvm domUs 
(windows) crashed: both dom0 and domUs inaccessible and also nothing 
visible on monitor connected to host.
For what I remember all other times of problems I had dom0 and/or domUs 
inaccesible but always at least kernel panic with calltrace visible on 
monitor.
In these cases I had nothing visible and nothing in dom0 logs but only 
particular thing was a windows 2003 R2 domUs "damaged" (I suppose cause 
of problem), can be the cause of host crash with this or similar issue 
or not?

Thanks for any reply and sorry for my bad english.

> VULNERABLE SYSTEMS
> ==================
>
> Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
> Older versions have not been inspected.  ARM systems are not vulnerable.
>
> MITIGATION
> ==========
>
> Running only PV guests will avoid this issue.
>
> There is no mitigation available for HVM guests.
>
> CREDITS
> =======
>
> This issue was discovered by Jan Beulich of SUSE.
>
> RESOLUTION
> ==========
>
> Applying the appropriate attached patch resolves this issue.
>
> xsa112-unstable.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x
> xsa112-4.2.patch             Xen 4.2.x
>
> $ sha256sum xsa112*.patch
> cf01a1acd258e7cbb3586e543ba3668c1ee7fb05cba19b8b5369a3e101a2288f  xsa112-4.2.patch
> cc39a4cdcb52929ed36ab696807d2405aa552177a6f029d8a1a52041ca1ed519  xsa112.patch
> $
>
> We have been told that this patch is not sufficient on Xen 3.3.x and
> earlier without also backporting b1b6362f (git commit id).
>
> Note that while we are happy to share information we receive about
> earlier Xen versions, the earliest Xen branch for which the Xen
> Project offers security support is 4.2.x.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQEcBAEBAgAGBQJUdwoNAAoJEIP+FMlX6CvZfekIAMBq3ynRyuyqvukMhSBaFj2O
> SBX747HJPKRmoODGZGe9EJ0pAJhckQ00RaKFulxSLzFeu4Oi6M3GrvNCvST0sR54
> bLTmeNeBOhLef4ylDqAWOSY4C7AJW/jC1ngtSy3wd6zuwFD0bzPYb7nk94PD32ie
> 9LYTt+FSkoo/3j3IviCqNVXTlMmhmdjP0U3+xXgxQZ9y47zTT8gsX4KoplC/i1Wq
> uhla/ZYI+Ro/ejYVHsKDDhfA1mgAGDoOLhmNEBLHPzTyGs4VOSaXzX7wce8JWpBi
> oXdnN5HW80mmkZ6qI42/bnvpSHTqm+QVFD0v1Uz0cSrBYJGq6LULBAmaJHGldDA=
> =8eF1
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------080409050505080702040502
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Il 27/11/2014 13:08, Xen.org security
      team ha scritto:<br>
    </div>
    <blockquote cite="mid:E1XtxsT-0000TV-4i@xenbits.xen.org" type="cite">
      <pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2014-8867 / XSA-112
                              version 5

  Insufficient bounding of "REP MOVS" to MMIO emulated inside the hypervisor

UPDATES IN VERSION 5
====================

Public release.

ISSUE DESCRIPTION
=================

Acceleration support for the "REP MOVS" instruction, when the first
iteration accesses memory mapped I/O emulated internally in the
hypervisor, incorrectly assumes that the whole range accessed is
handled by the same hypervisor sub-component.

IMPACT
======

A buggy or malicious HVM guest can crash the host.</pre>
    </blockquote>
    <br>
    Sorry for the probably stupid question.<br>
    Can an hvm domU make crash the host with this issue or similar
    without show nothing on dom0 logs and also nothing visible on
    screen? (kernel panic or similar)<br>
    Recently for 2 times I had one xen 4.4.1 hosts with some hvm domUs
    (windows) crashed: both dom0 and domUs inaccessible and also nothing
    visible on monitor connected to host.<br>
    For what I remember all other times of problems I had dom0 and/or
    domUs inaccesible but always at least kernel panic with calltrace
    visible on monitor.<br>
    In these cases I had nothing visible and nothing in dom0 logs but
    only particular thing was a windows 2003 R2 domUs "damaged" (I
    suppose cause of problem), can be the cause of host crash with this
    or similar issue or not?<br>
    <br>
    Thanks for any reply and sorry for my bad english.<br>
    <br>
    <blockquote cite="mid:E1XtxsT-0000TV-4i@xenbits.xen.org" type="cite">
      <pre wrap="">
VULNERABLE SYSTEMS
==================

Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
Older versions have not been inspected.  ARM systems are not vulnerable.

MITIGATION
==========

Running only PV guests will avoid this issue.

There is no mitigation available for HVM guests.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa112-unstable.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x
xsa112-4.2.patch             Xen 4.2.x

$ sha256sum xsa112*.patch
cf01a1acd258e7cbb3586e543ba3668c1ee7fb05cba19b8b5369a3e101a2288f  xsa112-4.2.patch
cc39a4cdcb52929ed36ab696807d2405aa552177a6f029d8a1a52041ca1ed519  xsa112.patch
$

We have been told that this patch is not sufficient on Xen 3.3.x and
earlier without also backporting b1b6362f (git commit id).

Note that while we are happy to share information we receive about
earlier Xen versions, the earliest Xen branch for which the Xen
Project offers security support is 4.2.x.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUdwoNAAoJEIP+FMlX6CvZfekIAMBq3ynRyuyqvukMhSBaFj2O
SBX747HJPKRmoODGZGe9EJ0pAJhckQ00RaKFulxSLzFeu4Oi6M3GrvNCvST0sR54
bLTmeNeBOhLef4ylDqAWOSY4C7AJW/jC1ngtSy3wd6zuwFD0bzPYb7nk94PD32ie
9LYTt+FSkoo/3j3IviCqNVXTlMmhmdjP0U3+xXgxQZ9y47zTT8gsX4KoplC/i1Wq
uhla/ZYI+Ro/ejYVHsKDDhfA1mgAGDoOLhmNEBLHPzTyGs4VOSaXzX7wce8JWpBi
oXdnN5HW80mmkZ6qI42/bnvpSHTqm+QVFD0v1Uz0cSrBYJGq6LULBAmaJHGldDA=
=8eF1
-----END PGP SIGNATURE-----
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------080409050505080702040502--


--===============4098168859055349311==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4098168859055349311==--


From xen-devel-bounces@lists.xen.org Thu Nov 27 16:00:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 16:00:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu1UR-0004jZ-Te; Thu, 27 Nov 2014 16:00:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1Xu1UQ-0004jU-CI
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 16:00:18 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	33/27-17694-19A47745; Thu, 27 Nov 2014 16:00:17 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417104012!14262312!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28357 invoked from network); 27 Nov 2014 16:00:12 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 16:00:12 -0000
Received: by mail-wi0-f178.google.com with SMTP id hi2so8763918wib.11
	for <xen-devel@lists.xen.org>; Thu, 27 Nov 2014 08:00:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=6ll0pnxendmdyGdi4ZtMdY1qRKMdGb6DEZufyCgudyw=;
	b=UDZB9hcqIRkWzY2BmKmFLqCoPbWBAUWvNHKYbOB+MY9oi4yhVp2OR+IdM+qLm/faNQ
	zvJjvIoQjjTi7Rj1wyxcjzrVASde03/lQVWz666s3Df9SMoSw6rH71ACvVzu1JN41sGf
	qlMo+rwVYRHlmIcyWQxBzGN+oCEr1fUQKhh6ncJ7/D0RIFtSn//G5xLQepcpnEsNQX5t
	UZ4yqoeYPumFZjcgwh5x8zo6tY/8Rsx396IrgvAIuMIfrHGMfzF/8oI4CVa9gJx/Im2v
	GhTUpa7+upTbKBbAE+p7EE/4GcOQ78kQNbRHhjQ7Tn1A0GDzgZdVxKj7WXQhqs1YCj7m
	9Q6g==
X-Gm-Message-State: ALoCoQk6cgCdVnFVtsGQ1QngR+ps+AOfLJ7DfWPMImQ3VV9h5oqqKX7ny4PdLj0QYXSZ9DNxk/Xn
X-Received: by 10.180.72.33 with SMTP id a1mr51530836wiv.18.1417104012198;
	Thu, 27 Nov 2014 08:00:12 -0800 (PST)
Received: from [192.168.1.15] (ip-73-126.sn2.eutelia.it. [83.211.73.126])
	by mx.google.com with ESMTPSA id
	r10sm25831969wiy.13.2014.11.27.08.00.10 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 27 Nov 2014 08:00:11 -0800 (PST)
Message-ID: <54774AA8.7070907@m2r.biz>
Date: Thu, 27 Nov 2014 17:00:40 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Xen.org security team" <security@xen.org>, xen-devel@lists.xen.org, 
	xen-users@lists.xen.org
References: <E1XtxsT-0000TV-4i@xenbits.xen.org>
In-Reply-To: <E1XtxsT-0000TV-4i@xenbits.xen.org>
Cc: jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen Security Advisory 112 (CVE-2014-8867) -
 Insufficient bounding of "REP MOVS" to MMIO emulated inside 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: multipart/mixed; boundary="===============4098168859055349311=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4098168859055349311==
Content-Type: multipart/alternative;
 boundary="------------080409050505080702040502"

This is a multi-part message in MIME format.
--------------080409050505080702040502
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Il 27/11/2014 13:08, Xen.org security team ha scritto:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>              Xen Security Advisory CVE-2014-8867 / XSA-112
>                                version 5
>
>    Insufficient bounding of "REP MOVS" to MMIO emulated inside the hypervisor
>
> UPDATES IN VERSION 5
> ====================
>
> Public release.
>
> ISSUE DESCRIPTION
> =================
>
> Acceleration support for the "REP MOVS" instruction, when the first
> iteration accesses memory mapped I/O emulated internally in the
> hypervisor, incorrectly assumes that the whole range accessed is
> handled by the same hypervisor sub-component.
>
> IMPACT
> ======
>
> A buggy or malicious HVM guest can crash the host.

Sorry for the probably stupid question.
Can an hvm domU make crash the host with this issue or similar without 
show nothing on dom0 logs and also nothing visible on screen? (kernel 
panic or similar)
Recently for 2 times I had one xen 4.4.1 hosts with some hvm domUs 
(windows) crashed: both dom0 and domUs inaccessible and also nothing 
visible on monitor connected to host.
For what I remember all other times of problems I had dom0 and/or domUs 
inaccesible but always at least kernel panic with calltrace visible on 
monitor.
In these cases I had nothing visible and nothing in dom0 logs but only 
particular thing was a windows 2003 R2 domUs "damaged" (I suppose cause 
of problem), can be the cause of host crash with this or similar issue 
or not?

Thanks for any reply and sorry for my bad english.

> VULNERABLE SYSTEMS
> ==================
>
> Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
> Older versions have not been inspected.  ARM systems are not vulnerable.
>
> MITIGATION
> ==========
>
> Running only PV guests will avoid this issue.
>
> There is no mitigation available for HVM guests.
>
> CREDITS
> =======
>
> This issue was discovered by Jan Beulich of SUSE.
>
> RESOLUTION
> ==========
>
> Applying the appropriate attached patch resolves this issue.
>
> xsa112-unstable.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x
> xsa112-4.2.patch             Xen 4.2.x
>
> $ sha256sum xsa112*.patch
> cf01a1acd258e7cbb3586e543ba3668c1ee7fb05cba19b8b5369a3e101a2288f  xsa112-4.2.patch
> cc39a4cdcb52929ed36ab696807d2405aa552177a6f029d8a1a52041ca1ed519  xsa112.patch
> $
>
> We have been told that this patch is not sufficient on Xen 3.3.x and
> earlier without also backporting b1b6362f (git commit id).
>
> Note that while we are happy to share information we receive about
> earlier Xen versions, the earliest Xen branch for which the Xen
> Project offers security support is 4.2.x.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQEcBAEBAgAGBQJUdwoNAAoJEIP+FMlX6CvZfekIAMBq3ynRyuyqvukMhSBaFj2O
> SBX747HJPKRmoODGZGe9EJ0pAJhckQ00RaKFulxSLzFeu4Oi6M3GrvNCvST0sR54
> bLTmeNeBOhLef4ylDqAWOSY4C7AJW/jC1ngtSy3wd6zuwFD0bzPYb7nk94PD32ie
> 9LYTt+FSkoo/3j3IviCqNVXTlMmhmdjP0U3+xXgxQZ9y47zTT8gsX4KoplC/i1Wq
> uhla/ZYI+Ro/ejYVHsKDDhfA1mgAGDoOLhmNEBLHPzTyGs4VOSaXzX7wce8JWpBi
> oXdnN5HW80mmkZ6qI42/bnvpSHTqm+QVFD0v1Uz0cSrBYJGq6LULBAmaJHGldDA=
> =8eF1
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------080409050505080702040502
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Il 27/11/2014 13:08, Xen.org security
      team ha scritto:<br>
    </div>
    <blockquote cite="mid:E1XtxsT-0000TV-4i@xenbits.xen.org" type="cite">
      <pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2014-8867 / XSA-112
                              version 5

  Insufficient bounding of "REP MOVS" to MMIO emulated inside the hypervisor

UPDATES IN VERSION 5
====================

Public release.

ISSUE DESCRIPTION
=================

Acceleration support for the "REP MOVS" instruction, when the first
iteration accesses memory mapped I/O emulated internally in the
hypervisor, incorrectly assumes that the whole range accessed is
handled by the same hypervisor sub-component.

IMPACT
======

A buggy or malicious HVM guest can crash the host.</pre>
    </blockquote>
    <br>
    Sorry for the probably stupid question.<br>
    Can an hvm domU make crash the host with this issue or similar
    without show nothing on dom0 logs and also nothing visible on
    screen? (kernel panic or similar)<br>
    Recently for 2 times I had one xen 4.4.1 hosts with some hvm domUs
    (windows) crashed: both dom0 and domUs inaccessible and also nothing
    visible on monitor connected to host.<br>
    For what I remember all other times of problems I had dom0 and/or
    domUs inaccesible but always at least kernel panic with calltrace
    visible on monitor.<br>
    In these cases I had nothing visible and nothing in dom0 logs but
    only particular thing was a windows 2003 R2 domUs "damaged" (I
    suppose cause of problem), can be the cause of host crash with this
    or similar issue or not?<br>
    <br>
    Thanks for any reply and sorry for my bad english.<br>
    <br>
    <blockquote cite="mid:E1XtxsT-0000TV-4i@xenbits.xen.org" type="cite">
      <pre wrap="">
VULNERABLE SYSTEMS
==================

Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
Older versions have not been inspected.  ARM systems are not vulnerable.

MITIGATION
==========

Running only PV guests will avoid this issue.

There is no mitigation available for HVM guests.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa112-unstable.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x
xsa112-4.2.patch             Xen 4.2.x

$ sha256sum xsa112*.patch
cf01a1acd258e7cbb3586e543ba3668c1ee7fb05cba19b8b5369a3e101a2288f  xsa112-4.2.patch
cc39a4cdcb52929ed36ab696807d2405aa552177a6f029d8a1a52041ca1ed519  xsa112.patch
$

We have been told that this patch is not sufficient on Xen 3.3.x and
earlier without also backporting b1b6362f (git commit id).

Note that while we are happy to share information we receive about
earlier Xen versions, the earliest Xen branch for which the Xen
Project offers security support is 4.2.x.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUdwoNAAoJEIP+FMlX6CvZfekIAMBq3ynRyuyqvukMhSBaFj2O
SBX747HJPKRmoODGZGe9EJ0pAJhckQ00RaKFulxSLzFeu4Oi6M3GrvNCvST0sR54
bLTmeNeBOhLef4ylDqAWOSY4C7AJW/jC1ngtSy3wd6zuwFD0bzPYb7nk94PD32ie
9LYTt+FSkoo/3j3IviCqNVXTlMmhmdjP0U3+xXgxQZ9y47zTT8gsX4KoplC/i1Wq
uhla/ZYI+Ro/ejYVHsKDDhfA1mgAGDoOLhmNEBLHPzTyGs4VOSaXzX7wce8JWpBi
oXdnN5HW80mmkZ6qI42/bnvpSHTqm+QVFD0v1Uz0cSrBYJGq6LULBAmaJHGldDA=
=8eF1
-----END PGP SIGNATURE-----
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------080409050505080702040502--


--===============4098168859055349311==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4098168859055349311==--


From xen-devel-bounces@lists.xen.org Thu Nov 27 16:57:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 16:57:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu2Nk-0006PN-C2; Thu, 27 Nov 2014 16:57: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@citrix.com>) id 1Xu2Ni-0006PI-Cw
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 16:57:26 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	4C/41-25714-5F757745; Thu, 27 Nov 2014 16:57:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417107442!13755769!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20692 invoked from network); 27 Nov 2014 16:57:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 16:57:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,470,1413244800"; d="scan'208";a="197488955"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 11:57:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu2Nd-0001pE-21;
	Thu, 27 Nov 2014 16:57:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu2Nc-0002BO-Oh;
	Thu, 27 Nov 2014 16:57:20 +0000
Date: Thu, 27 Nov 2014 16:57:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31864-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31864: 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 31864 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31864/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 31856 REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3   3 host-install(3)           broken pass in 31856
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)         broken pass in 31856
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3)   broken pass in 31856
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)         broken pass in 31856
 test-amd64-i386-libvirt       3 host-install(3)           broken pass in 31856
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 31856
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)    broken pass in 31856
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)     broken pass in 31856
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)     broken pass in 31856
 test-amd64-amd64-libvirt      3 host-install(3)           broken pass in 31856
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 31856
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken pass in 31856
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)     broken pass in 31856
 test-amd64-i386-freebsd10-amd64  3 host-install(3)        broken pass in 31856
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 31856
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 31856
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3)   broken pass in 31856
 test-amd64-i386-freebsd10-i386  3 host-install(3)         broken pass in 31856
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 31856
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 31856
 test-amd64-i386-xl            3 host-install(3)           broken pass in 31856
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)        broken pass in 31856
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 31856
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 31856
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3)   broken pass in 31856
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)     broken pass in 31856
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)    broken pass in 31856
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)      broken pass in 31856
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 31856
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 31856
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31856 pass in 31844
 test-amd64-i386-pair          8 xen-boot/dst_host  fail in 31856 pass in 31864
 test-amd64-i386-pair          7 xen-boot/src_host  fail in 31856 pass in 31864
 test-amd64-i386-xl-qemuu-win7-amd64 7 windows-install fail in 31856 pass in 31817
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot   fail in 31844 pass in 31856

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)        broken like 26303
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken blocked in 26303
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken blocked in 26303
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3)  broken blocked in 26303
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken blocked in 26303
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  3 host-install(3)  broken like 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail in 31856 blocked in 26303
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail in 31844 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop            fail in 31856 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31856 never pass
 test-amd64-i386-libvirt       9 guest-start           fail in 31856 never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 31856 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 31856 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31856 never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 31856 never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 31856 never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31856 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31856 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31856 never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail in 31856 never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop       fail in 31856 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31817 never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          broken  
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemut-rhel6hvm-amd                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     broken  
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     broken  
 test-amd64-i386-freebsd10-amd64                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         broken  
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-rumpuserxen-amd64                           broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         broken  
 test-amd64-i386-xl-qemut-win7-amd64                          broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-amd64-libvirt                                     broken  
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-xl-qemut-winxpsp3                           broken  
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-amd64-i386-xl-qemuu-winxpsp3                            broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  broken  


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-winxpsp3 host-install(3)
broken-step test-amd64-i386-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-amd64-xl-win7-amd64 host-install(3)
broken-step test-amd64-i386-libvirt host-install(3)
broken-step test-amd64-i386-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-xl-qemut-win7-amd64 host-install(3)
broken-step test-amd64-i386-xl-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-winxpsp3 host-install(3)
broken-step test-amd64-amd64-libvirt host-install(3)
broken-step test-amd64-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-freebsd10-amd64 host-install(3)
broken-step test-amd64-i386-xl-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-sedf host-install(3)
broken-step test-amd64-amd64-xl-qemut-win7-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-amd64-xl host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-xl-pcipt-intel host-install(3)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-rumpuserxen-amd64 host-install(3)
broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel host-install(3)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemut-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-amd64-xl-qemut-winxpsp3 host-install(3)
broken-step test-amd64-i386-xl-qemuu-win7-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3 host-install(3)
broken-step test-amd64-amd64-pair host-install/src_host(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)

Not pushing.

(No revision log; it would be 33063 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 16:57:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 16:57:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu2Nk-0006PN-C2; Thu, 27 Nov 2014 16:57: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@citrix.com>) id 1Xu2Ni-0006PI-Cw
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 16:57:26 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	4C/41-25714-5F757745; Thu, 27 Nov 2014 16:57:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417107442!13755769!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20692 invoked from network); 27 Nov 2014 16:57:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 16:57:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,470,1413244800"; d="scan'208";a="197488955"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 11:57:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu2Nd-0001pE-21;
	Thu, 27 Nov 2014 16:57:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu2Nc-0002BO-Oh;
	Thu, 27 Nov 2014 16:57:20 +0000
Date: Thu, 27 Nov 2014 16:57:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31864-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31864: 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 31864 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31864/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 31856 REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3   3 host-install(3)           broken pass in 31856
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)         broken pass in 31856
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3)   broken pass in 31856
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)         broken pass in 31856
 test-amd64-i386-libvirt       3 host-install(3)           broken pass in 31856
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 31856
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)    broken pass in 31856
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)     broken pass in 31856
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)     broken pass in 31856
 test-amd64-amd64-libvirt      3 host-install(3)           broken pass in 31856
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 31856
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken pass in 31856
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)     broken pass in 31856
 test-amd64-i386-freebsd10-amd64  3 host-install(3)        broken pass in 31856
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 31856
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 31856
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3)   broken pass in 31856
 test-amd64-i386-freebsd10-i386  3 host-install(3)         broken pass in 31856
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 31856
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 31856
 test-amd64-i386-xl            3 host-install(3)           broken pass in 31856
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)        broken pass in 31856
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 31856
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 31856
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3)   broken pass in 31856
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)     broken pass in 31856
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)    broken pass in 31856
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)      broken pass in 31856
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 31856
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 31856
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31856 pass in 31844
 test-amd64-i386-pair          8 xen-boot/dst_host  fail in 31856 pass in 31864
 test-amd64-i386-pair          7 xen-boot/src_host  fail in 31856 pass in 31864
 test-amd64-i386-xl-qemuu-win7-amd64 7 windows-install fail in 31856 pass in 31817
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot   fail in 31844 pass in 31856

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)        broken like 26303
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken blocked in 26303
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken blocked in 26303
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3)  broken blocked in 26303
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken blocked in 26303
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  3 host-install(3)  broken like 26303
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail in 31856 blocked in 26303
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail in 31844 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop            fail in 31856 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31856 never pass
 test-amd64-i386-libvirt       9 guest-start           fail in 31856 never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 31856 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 31856 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31856 never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 31856 never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 31856 never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31856 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31856 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31856 never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail in 31856 never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop       fail in 31856 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 31817 never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          broken  
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemut-rhel6hvm-amd                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     broken  
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     broken  
 test-amd64-i386-freebsd10-amd64                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         broken  
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-rumpuserxen-amd64                           broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         broken  
 test-amd64-i386-xl-qemut-win7-amd64                          broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-amd64-libvirt                                     broken  
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-xl-qemut-winxpsp3                           broken  
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-amd64-i386-xl-qemuu-winxpsp3                            broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  broken  


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-winxpsp3 host-install(3)
broken-step test-amd64-i386-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-amd64-xl-win7-amd64 host-install(3)
broken-step test-amd64-i386-libvirt host-install(3)
broken-step test-amd64-i386-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-xl-qemut-win7-amd64 host-install(3)
broken-step test-amd64-i386-xl-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-winxpsp3 host-install(3)
broken-step test-amd64-amd64-libvirt host-install(3)
broken-step test-amd64-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-freebsd10-amd64 host-install(3)
broken-step test-amd64-i386-xl-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-sedf host-install(3)
broken-step test-amd64-amd64-xl-qemut-win7-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-amd64-xl host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-xl-pcipt-intel host-install(3)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-rumpuserxen-amd64 host-install(3)
broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel host-install(3)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemut-winxpsp3-vcpus1 host-install(3)
broken-step test-amd64-amd64-xl-qemut-winxpsp3 host-install(3)
broken-step test-amd64-i386-xl-qemuu-win7-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3 host-install(3)
broken-step test-amd64-amd64-pair host-install/src_host(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)

Not pushing.

(No revision log; it would be 33063 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu3OP-0008DN-Eq; Thu, 27 Nov 2014 18:02:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xu3ON-0008DI-1u
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 18:02:11 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	EA/2A-24124-22767745; Thu, 27 Nov 2014 18:02:10 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417111329!13744712!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9851 invoked from network); 27 Nov 2014 18:02:09 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:02:09 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so7118802wgg.29
	for <xen-devel@lists.xenproject.org>;
	Thu, 27 Nov 2014 10:02:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=vgP4Lcdpa/u4FR56JTOfU2vouH0rzvDXLWHYyA9IuJo=;
	b=SP4DDa0KKKoUQNHeVx4DNrjuwicN2USE0Iygk6yWerpebL8odysIrQfKl5V6v0qXMe
	+Ra2UYiPWnvypVP4vWMFMewDJ6ug+j2JM6bGHesTLMgB5xkmKsdDRLO+IJybzyV6miRA
	2ZchSl+gHUiZhNAbGB/wKCpGPPT8AZNyPAqIhE2TbYDoXD9upULRuSqxpwD36ViDQ2y/
	DEvtOQOe09ybL0afr813e4z+HRj/QYM7xPYVLieLSwhdHL1s3dKfvRU6ZFPlf+9fK11o
	7HScd43p/qyc+szH2rs075r38K4kaWEdH9ethpLlMIT35bwPoLs2pOZuk3Vwnp/Lpoi5
	FpzQ==
X-Gm-Message-State: ALoCoQkuAdW3H2JqHh+VRUi2CBXluTZXvfUgjcmxI7bdm6DTq/gNLiHXvhzvditkFHvZuvs6bR6x
X-Received: by 10.180.104.197 with SMTP id gg5mr15741249wib.7.1417111328552;
	Thu, 27 Nov 2014 10:02:08 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	el6sm26220446wib.23.2014.11.27.10.02.07 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 27 Nov 2014 10:02:07 -0800 (PST)
Message-ID: <5477671C.4010500@linaro.org>
Date: Thu, 27 Nov 2014 18:02:04 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xenproject.org
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 25/11/14 17:44, Julien Grall wrote:
> ARMv8 model may not disable correctly the timer interrupt when Xen
> context switch to an idle vCPU. Therefore Xen may receive a spurious
> timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
> when trying to inject the interrupt with the following stack trace.
> 
> (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
> (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
> (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
> (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
> (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
> (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
> (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
> (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
> (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
> (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
> (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
> (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
> (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
> (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
> (XEN)    [<0000000000000001>] 0000000000000001
> 
> While we receive spurious virtual timer interrupt, this could be safely
> ignore for the time being. A proper fix need to be found for Xen 4.6.

Thanks to ARM, they found the root of the problem. When the timer
interrupt is edge-triggered, disabling the timer output signal, the
state of the interrupt won't change in the GIC.

I propose to reword the commit message into:

xen/arm: Handle platforms with edge-triggered virtual timer

Some platforms (such as the ARMv8 model) uses edge-triggered interrupt
for the virtual timer. Even if the timer output signal is masked in the
context switch, the GIC will keep track that of any raised interrupt
while the IRQs has been disabled. As soon as the IRQs are re-enabled,
the virtual interrupt timer will be injected to Xen.

The interrupt handler doesn't except to the receive the IRQ and will
crash if an idle vCPU is running:

(XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
(XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
(XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
(XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
(XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
(XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
(XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
(XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
(XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
(XEN)    [<000000000022482c>] schedule+0x684/0x6d0
(XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
(XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
(XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
(XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
(XEN)    [<0000000000000001>] 0000000000000001

The proper solution would be context/switching the virtual interrupt
state at the GIC level. This would also avoid masking the output signal
and requires specific handling in the guest OS.

Sadly, this solution require some refactoring which would miss the Xen
4.5 release.

For now implement a temporary solution which ignore the interrupt when
the idle VCPU is running.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:02:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu3OP-0008DN-Eq; Thu, 27 Nov 2014 18:02:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Xu3ON-0008DI-1u
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 18:02:11 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	EA/2A-24124-22767745; Thu, 27 Nov 2014 18:02:10 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417111329!13744712!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9851 invoked from network); 27 Nov 2014 18:02:09 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:02:09 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so7118802wgg.29
	for <xen-devel@lists.xenproject.org>;
	Thu, 27 Nov 2014 10:02:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=vgP4Lcdpa/u4FR56JTOfU2vouH0rzvDXLWHYyA9IuJo=;
	b=SP4DDa0KKKoUQNHeVx4DNrjuwicN2USE0Iygk6yWerpebL8odysIrQfKl5V6v0qXMe
	+Ra2UYiPWnvypVP4vWMFMewDJ6ug+j2JM6bGHesTLMgB5xkmKsdDRLO+IJybzyV6miRA
	2ZchSl+gHUiZhNAbGB/wKCpGPPT8AZNyPAqIhE2TbYDoXD9upULRuSqxpwD36ViDQ2y/
	DEvtOQOe09ybL0afr813e4z+HRj/QYM7xPYVLieLSwhdHL1s3dKfvRU6ZFPlf+9fK11o
	7HScd43p/qyc+szH2rs075r38K4kaWEdH9ethpLlMIT35bwPoLs2pOZuk3Vwnp/Lpoi5
	FpzQ==
X-Gm-Message-State: ALoCoQkuAdW3H2JqHh+VRUi2CBXluTZXvfUgjcmxI7bdm6DTq/gNLiHXvhzvditkFHvZuvs6bR6x
X-Received: by 10.180.104.197 with SMTP id gg5mr15741249wib.7.1417111328552;
	Thu, 27 Nov 2014 10:02:08 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	el6sm26220446wib.23.2014.11.27.10.02.07 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 27 Nov 2014 10:02:07 -0800 (PST)
Message-ID: <5477671C.4010500@linaro.org>
Date: Thu, 27 Nov 2014 18:02:04 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xenproject.org
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 25/11/14 17:44, Julien Grall wrote:
> ARMv8 model may not disable correctly the timer interrupt when Xen
> context switch to an idle vCPU. Therefore Xen may receive a spurious
> timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
> when trying to inject the interrupt with the following stack trace.
> 
> (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
> (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
> (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
> (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
> (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
> (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
> (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
> (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
> (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
> (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
> (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
> (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
> (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
> (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
> (XEN)    [<0000000000000001>] 0000000000000001
> 
> While we receive spurious virtual timer interrupt, this could be safely
> ignore for the time being. A proper fix need to be found for Xen 4.6.

Thanks to ARM, they found the root of the problem. When the timer
interrupt is edge-triggered, disabling the timer output signal, the
state of the interrupt won't change in the GIC.

I propose to reword the commit message into:

xen/arm: Handle platforms with edge-triggered virtual timer

Some platforms (such as the ARMv8 model) uses edge-triggered interrupt
for the virtual timer. Even if the timer output signal is masked in the
context switch, the GIC will keep track that of any raised interrupt
while the IRQs has been disabled. As soon as the IRQs are re-enabled,
the virtual interrupt timer will be injected to Xen.

The interrupt handler doesn't except to the receive the IRQ and will
crash if an idle vCPU is running:

(XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
(XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
(XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
(XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
(XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
(XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
(XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
(XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
(XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
(XEN)    [<000000000022482c>] schedule+0x684/0x6d0
(XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
(XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
(XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
(XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
(XEN)    [<0000000000000001>] 0000000000000001

The proper solution would be context/switching the virtual interrupt
state at the GIC level. This would also avoid masking the output signal
and requires specific handling in the guest OS.

Sadly, this solution require some refactoring which would miss the Xen
4.5 release.

For now implement a temporary solution which ignore the interrupt when
the idle VCPU is running.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:15:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18:15:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu3ao-00007l-OC; Thu, 27 Nov 2014 18:15:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xu3an-00007g-72
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:15:01 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	1F/6E-02954-42A67745; Thu, 27 Nov 2014 18:15:00 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417112098!15327416!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29457 invoked from network); 27 Nov 2014 18:14:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:14:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197244029"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:14:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xu3aj-00086W-7U;
	Thu, 27 Nov 2014 18:14:57 +0000
Date: Thu, 27 Nov 2014 18:14:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1404714875-24362-2-git-send-email-cyliu@suse.com>
Message-ID: <alpine.DEB.2.02.1411271809430.14135@kaball.uk.xensource.com>
References: <1404714875-24362-1-git-send-email-cyliu@suse.com>
	<1404714875-24362-2-git-send-email-cyliu@suse.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	qemu-devel@nongnu.org, Anthony.Perard@citrix.com
Subject: [Xen-devel] [for 4.5] missing chunk in
 11dffa2359e8a2629490c14c029c7c7c777b3e47
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 7 Jul 2014, Chunyan Liu wrote:
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index addacdb..4f1cbd2 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -479,6 +485,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          int ioemu_nics = 0;
>  
> +        if (b_info->kernel)
> +            flexarray_vappend(dm_args, "-kernel", b_info->kernel, NULL);
> +
> +        if (b_info->ramdisk)
> +            flexarray_vappend(dm_args, "-initrd", b_info->ramdisk, NULL);
> +
> +        if (b_info->cmdline)
> +            flexarray_vappend(dm_args, "-append", b_info->cmdline, NULL);
> +
>          if (b_info->u.hvm.serial) {
>              flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
>          }

This chunk of the patch was never applied to xen-unstable (commit
11dffa2359e8a2629490c14c029c7c7c777b3e47), see
http://marc.info/?l=qemu-devel&m=140471493425353&w=2.
The feature is broken at the moment.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:15:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18:15:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu3ao-00007l-OC; Thu, 27 Nov 2014 18:15:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xu3an-00007g-72
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:15:01 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	1F/6E-02954-42A67745; Thu, 27 Nov 2014 18:15:00 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417112098!15327416!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29457 invoked from network); 27 Nov 2014 18:14:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:14:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197244029"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:14:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1Xu3aj-00086W-7U;
	Thu, 27 Nov 2014 18:14:57 +0000
Date: Thu, 27 Nov 2014 18:14:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1404714875-24362-2-git-send-email-cyliu@suse.com>
Message-ID: <alpine.DEB.2.02.1411271809430.14135@kaball.uk.xensource.com>
References: <1404714875-24362-1-git-send-email-cyliu@suse.com>
	<1404714875-24362-2-git-send-email-cyliu@suse.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	qemu-devel@nongnu.org, Anthony.Perard@citrix.com
Subject: [Xen-devel] [for 4.5] missing chunk in
 11dffa2359e8a2629490c14c029c7c7c777b3e47
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 7 Jul 2014, Chunyan Liu wrote:
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index addacdb..4f1cbd2 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -479,6 +485,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          int ioemu_nics = 0;
>  
> +        if (b_info->kernel)
> +            flexarray_vappend(dm_args, "-kernel", b_info->kernel, NULL);
> +
> +        if (b_info->ramdisk)
> +            flexarray_vappend(dm_args, "-initrd", b_info->ramdisk, NULL);
> +
> +        if (b_info->cmdline)
> +            flexarray_vappend(dm_args, "-append", b_info->cmdline, NULL);
> +
>          if (b_info->u.hvm.serial) {
>              flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
>          }

This chunk of the patch was never applied to xen-unstable (commit
11dffa2359e8a2629490c14c029c7c7c777b3e47), see
http://marc.info/?l=qemu-devel&m=140471493425353&w=2.
The feature is broken at the moment.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:22:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu3hR-0000Ns-LV; Thu, 27 Nov 2014 18:21:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3hQ-0000Kw-5x
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:21:52 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	CF/C7-26858-FBB67745; Thu, 27 Nov 2014 18:21:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417112509!14194214!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17767 invoked from network); 27 Nov 2014 18:21:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:21:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197504652"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 13:21:48 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3hL-0002ES-RK;
	Thu, 27 Nov 2014 18:21:47 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3hJ-0003rT-HR;
	Thu, 27 Nov 2014 18:21:45 +0000
Date: Thu, 27 Nov 2014 18:21:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31871-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31871: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31871 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31871/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt      3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3)   broken REGR. vs. 31241
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31241
 build-i386                    3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 build-i386-rumpuserxen        1 build-check(1)               blocked  n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a

version targeted for testing:
 linux                b914c5b2130239fd378d1a719ab3c53f0c782be9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
653 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   broken  
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       blocked 
 test-amd64-amd64-xl                                          broken  
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         broken  
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     broken  
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-libvirt host-install(3)
broken-step test-amd64-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-rumpuserxen-amd64 host-install(3)
broken-step test-amd64-amd64-xl host-install(3)
broken-step test-amd64-amd64-xl-sedf host-install(3)
broken-step test-amd64-amd64-xl-pcipt-intel host-install(3)
broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step build-i386 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-winxpsp3 host-install(3)

Not pushing.

(No revision log; it would be 27684 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:22:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu3hR-0000Ns-LV; Thu, 27 Nov 2014 18:21:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3hQ-0000Kw-5x
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:21:52 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	CF/C7-26858-FBB67745; Thu, 27 Nov 2014 18:21:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417112509!14194214!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17767 invoked from network); 27 Nov 2014 18:21:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:21:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197504652"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 13:21:48 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3hL-0002ES-RK;
	Thu, 27 Nov 2014 18:21:47 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3hJ-0003rT-HR;
	Thu, 27 Nov 2014 18:21:45 +0000
Date: Thu, 27 Nov 2014 18:21:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31871-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31871: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31871 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31871/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt      3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3)   broken REGR. vs. 31241
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31241
 build-i386                    3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 31241

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 build-i386-rumpuserxen        1 build-check(1)               blocked  n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)               blocked n/a

version targeted for testing:
 linux                b914c5b2130239fd378d1a719ab3c53f0c782be9
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
653 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   broken  
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       blocked 
 test-amd64-amd64-xl                                          broken  
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    broken  
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         broken  
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 
 test-amd64-amd64-rumpuserxen-amd64                           broken  
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-amd64-libvirt                                     broken  
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-amd64-i386-xl-qemuu-winxpsp3                            blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-libvirt host-install(3)
broken-step test-amd64-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-rumpuserxen-amd64 host-install(3)
broken-step test-amd64-amd64-xl host-install(3)
broken-step test-amd64-amd64-xl-sedf host-install(3)
broken-step test-amd64-amd64-xl-pcipt-intel host-install(3)
broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step build-i386 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-winxpsp3 host-install(3)

Not pushing.

(No revision log; it would be 27684 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nY-0000gM-Ic; Thu, 27 Nov 2014 18:28:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nX-0000fY-3z
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:11 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	2A/9E-02957-A3D67745; Thu, 27 Nov 2014 18:28:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417112884!15289546!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2096 invoked from network); 27 Nov 2014 18:28:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:28:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197246010"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:08 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008K9-Fj;
	Thu, 27 Nov 2014 18:28:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008LQ-6n;
	Thu, 27 Nov 2014 18:28:03 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:47 +0000
Message-ID: <1417112870-31894-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/6] libxl: events: Deregister, don't just modify,
	sigchld pipe fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We want to have no fd events registered when we are idle.  This
implies that we must be able to deregister our interest in the sigchld
self-pipe fd, not just modify to request no events.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/libxl_fork.c |    9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index fa15095..144208a 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -372,15 +372,8 @@ static void sigchld_user_remove(libxl_ctx *ctx) /* idempotent */
 
 void libxl__sigchld_notneeded(libxl__gc *gc) /* non-reentrant, idempotent */
 {
-    int rc;
-
     sigchld_user_remove(CTX);
-
-    if (libxl__ev_fd_isregistered(&CTX->sigchld_selfpipe_efd)) {
-        rc = libxl__ev_fd_modify(gc, &CTX->sigchld_selfpipe_efd, 0);
-        if (rc)
-            libxl__ev_fd_deregister(gc, &CTX->sigchld_selfpipe_efd);
-    }
+    libxl__ev_fd_deregister(gc, &CTX->sigchld_selfpipe_efd);
 }
 
 int libxl__sigchld_needed(libxl__gc *gc) /* non-reentrant, idempotent */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nU-0000et-QB; Thu, 27 Nov 2014 18:28:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nT-0000eP-DW
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:07 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	86/4B-02699-63D67745; Thu, 27 Nov 2014 18:28:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417112884!15289546!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1836 invoked from network); 27 Nov 2014 18:28:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:28:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197246006"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:04 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008KF-Td;
	Thu, 27 Nov 2014 18:28:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008Lc-Md;
	Thu, 27 Nov 2014 18:28:03 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:49 +0000
Message-ID: <1417112870-31894-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 5/6] libxl: events: Deregister evtchn fd when
	not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We want to have no fd events registered when we are idle.
In this patch, deal with the evtchn fd:

 * Defer setup of the evtchn handle to the first use.
 * Defer registration of the evtchn fd; register as needed on use.
 * When cancelling an evtchn wait, or when wait setup fails, check
   whether there are now no evtchn waits and if so deregister the fd.
 * On libxl teardown, the evtchn fd should therefore be unregistered.
   assert that this is the case.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    4 +---
 tools/libxl/libxl_event.c    |   27 +++++++++++++++++++--------
 tools/libxl/libxl_internal.h |    1 +
 3 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 785253d..e0db4eb 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -118,8 +118,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
         rc = ERROR_FAIL; goto out;
     }
 
-    rc = libxl__ctx_evtchn_init(gc);
-
     *pctx = ctx;
     return 0;
 
@@ -166,7 +164,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
     assert(!libxl__ev_fd_isregistered(&ctx->watch_efd));
-    libxl__ev_fd_deregister(gc, &ctx->evtchn_efd);
+    assert(!libxl__ev_fd_isregistered(&ctx->evtchn_efd));
     assert(!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd));
 
     /* Now there should be no more events requested from the application: */
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index da0a20e..716f318 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -721,7 +721,7 @@ static void evtchn_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
 
 int libxl__ctx_evtchn_init(libxl__gc *gc) {
     xc_evtchn *xce;
-    int rc, fd;
+    int rc;
 
     if (CTX->xce)
         return 0;
@@ -733,14 +733,10 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
         goto out;
     }
 
-    fd = xc_evtchn_fd(xce);
-    assert(fd >= 0);
+    CTX->evtchn_fd = xc_evtchn_fd(xce);
+    assert(CTX->evtchn_fd >= 0);
 
-    rc = libxl_fd_set_nonblock(CTX, fd, 1);
-    if (rc) goto out;
-
-    rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd,
-                               evtchn_fd_callback, fd, POLLIN);
+    rc = libxl_fd_set_nonblock(CTX, CTX->evtchn_fd, 1);
     if (rc) goto out;
 
     CTX->xce = xce;
@@ -751,6 +747,12 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
     return rc;
 }
 
+static void evtchn_check_fd_deregister(libxl__gc *gc)
+{
+    if (CTX->xce && LIBXL_LIST_EMPTY(&CTX->evtchns_waiting))
+        libxl__ev_fd_deregister(gc, &CTX->evtchn_efd);
+}
+
 int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
 {
     int r, rc;
@@ -758,6 +760,13 @@ int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
     DBG("ev_evtchn=%p port=%d wait (was waiting=%d)",
         evev, evev->port, evev->waiting);
 
+    rc = libxl__ctx_evtchn_init(gc);
+    if (rc) goto out;
+
+    rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd,
+                               evtchn_fd_callback, CTX->evtchn_fd, POLLIN);
+    if (rc) goto out;
+
     if (evev->waiting)
         return 0;
 
@@ -773,6 +782,7 @@ int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
     return 0;
 
  out:
+    evtchn_check_fd_deregister(gc);
     return rc;
 }
 
@@ -786,6 +796,7 @@ void libxl__ev_evtchn_cancel(libxl__gc *gc, libxl__ev_evtchn *evev)
 
     evev->waiting = 0;
     LIBXL_LIST_REMOVE(evev, entry);
+    evtchn_check_fd_deregister(gc);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 728fe2c..481fbd5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -359,6 +359,7 @@ struct libxl__ctx {
 
     xc_evtchn *xce; /* waiting must be done only with libxl__ev_evtchn* */
     LIBXL_LIST_HEAD(, libxl__ev_evtchn) evtchns_waiting;
+    int evtchn_fd;
     libxl__ev_fd evtchn_efd;
 
     LIBXL_TAILQ_HEAD(libxl__evgen_domain_death_list, libxl_evgen_domain_death)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nX-0000fh-6E; Thu, 27 Nov 2014 18:28:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nW-0000f9-3b
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:10 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	60/9E-02953-93D67745; Thu, 27 Nov 2014 18:28:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417112883!15351545!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30430 invoked from network); 27 Nov 2014 18:28:05 -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;
	27 Nov 2014 18:28:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197505805"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:04 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nQ-0008KI-3h;
	Thu, 27 Nov 2014 18:28:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008Lh-T1;
	Thu, 27 Nov 2014 18:28:03 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:50 +0000
Message-ID: <1417112870-31894-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 6/6] libxl: events: Document and enforce actual
	callbacks restriction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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_event_register_callbacks cannot reasonably be called while libxl
is busy (has outstanding operations and/or enabled events).

This is because the previous spec implied (although not entirely
clearly) that event hooks would not be called for existing fd and
timeout interests.  There is thus no way to reliably ensure that libxl
would get told about fds and timeouts which it became interested in
beforehand.

So there have to be no such fds or timeouts, which means that the
callbacks must only be registered or changed when the ctx is idle.

Document this restriction, and enforce it with a pair of asserts.

(It would be nicer, perhaps, to say that the application may not call
libxl_osevent_register_hooks other than right after creating the ctx.
But there are existing callers, including libvirt, who do it later -
even after doing major operations such as domain creation.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c |    2 ++
 tools/libxl/libxl_event.h |    6 ++----
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 716f318..45f0871 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1217,6 +1217,8 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
 {
     GC_INIT(ctx);
     CTX_LOCK;
+    assert(LIBXL_LIST_EMPTY(&ctx->efds));
+    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
     ctx->osevent_hooks = hooks;
     ctx->osevent_user = user;
     CTX_UNLOCK;
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index b5db83c..3c6fcfe 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -124,10 +124,8 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
    * different parameters, as the application likes; the most recent
    * call determines the libxl behaviour.  However it is NOT safe to
    * call _register_callbacks concurrently with, or reentrantly from,
-   * any other libxl function.
-   *
-   * Calls to _register_callbacks do not affect events which have
-   * already occurred.
+   * any other libxl function, nor while any event-generation
+   * facilities are enabled.
    */
 
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nY-0000ga-Vh; Thu, 27 Nov 2014 18:28:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nX-0000fq-MZ
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:11 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	7D/2E-03145-B3D67745; Thu, 27 Nov 2014 18:28:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417112884!15289546!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2161 invoked from network); 27 Nov 2014 18:28:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:28:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197246011"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:09 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008KC-NA;
	Thu, 27 Nov 2014 18:28:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008LX-F3;
	Thu, 27 Nov 2014 18:28:03 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:48 +0000
Message-ID: <1417112870-31894-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/6] libxl: events: Tear down SIGCHLD machinery
	on ctx 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

We want to have no fd events registered when we are idle.
Also, we should put back the default SIGCHLD handler.  So:

 * In libxl_ctx_free, use libxl_childproc_setmode to set the mode to
   the default, which is libxl_sigchld_owner_libxl (ie `libxl owns
   SIGCHLD only when it has active children').

   But of course there are no active children at libxl teardown so
   this results in libxl__sigchld_notneeded: the ctx loses its
   interest in SIGCHLD (unsetting the SIGCHLD handler if we were the
   last ctx) and deregisters the per-ctx selfpipe fd.

 * assert that this is the case: ie that we are no longer interested
   in the selfpipe.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 12a1013..785253d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -162,11 +162,12 @@ int libxl_ctx_free(libxl_ctx *ctx)
     while ((eject = LIBXL_LIST_FIRST(&CTX->disk_eject_evgens)))
         libxl__evdisable_disk_eject(gc, eject);
 
+    libxl_childproc_setmode(CTX,0,0);
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
     assert(!libxl__ev_fd_isregistered(&ctx->watch_efd));
     libxl__ev_fd_deregister(gc, &ctx->evtchn_efd);
-    libxl__ev_fd_deregister(gc, &ctx->sigchld_selfpipe_efd);
+    assert(!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd));
 
     /* Now there should be no more events requested from the application: */
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nY-0000gM-Ic; Thu, 27 Nov 2014 18:28:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nX-0000fY-3z
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:11 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	2A/9E-02957-A3D67745; Thu, 27 Nov 2014 18:28:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417112884!15289546!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2096 invoked from network); 27 Nov 2014 18:28:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:28:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197246010"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:08 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008K9-Fj;
	Thu, 27 Nov 2014 18:28:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008LQ-6n;
	Thu, 27 Nov 2014 18:28:03 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:47 +0000
Message-ID: <1417112870-31894-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/6] libxl: events: Deregister, don't just modify,
	sigchld pipe fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We want to have no fd events registered when we are idle.  This
implies that we must be able to deregister our interest in the sigchld
self-pipe fd, not just modify to request no events.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/libxl_fork.c |    9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index fa15095..144208a 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -372,15 +372,8 @@ static void sigchld_user_remove(libxl_ctx *ctx) /* idempotent */
 
 void libxl__sigchld_notneeded(libxl__gc *gc) /* non-reentrant, idempotent */
 {
-    int rc;
-
     sigchld_user_remove(CTX);
-
-    if (libxl__ev_fd_isregistered(&CTX->sigchld_selfpipe_efd)) {
-        rc = libxl__ev_fd_modify(gc, &CTX->sigchld_selfpipe_efd, 0);
-        if (rc)
-            libxl__ev_fd_deregister(gc, &CTX->sigchld_selfpipe_efd);
-    }
+    libxl__ev_fd_deregister(gc, &CTX->sigchld_selfpipe_efd);
 }
 
 int libxl__sigchld_needed(libxl__gc *gc) /* non-reentrant, idempotent */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nU-0000et-QB; Thu, 27 Nov 2014 18:28:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nT-0000eP-DW
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:07 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	86/4B-02699-63D67745; Thu, 27 Nov 2014 18:28:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417112884!15289546!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1836 invoked from network); 27 Nov 2014 18:28:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:28:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197246006"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:04 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008KF-Td;
	Thu, 27 Nov 2014 18:28:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008Lc-Md;
	Thu, 27 Nov 2014 18:28:03 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:49 +0000
Message-ID: <1417112870-31894-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 5/6] libxl: events: Deregister evtchn fd when
	not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We want to have no fd events registered when we are idle.
In this patch, deal with the evtchn fd:

 * Defer setup of the evtchn handle to the first use.
 * Defer registration of the evtchn fd; register as needed on use.
 * When cancelling an evtchn wait, or when wait setup fails, check
   whether there are now no evtchn waits and if so deregister the fd.
 * On libxl teardown, the evtchn fd should therefore be unregistered.
   assert that this is the case.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    4 +---
 tools/libxl/libxl_event.c    |   27 +++++++++++++++++++--------
 tools/libxl/libxl_internal.h |    1 +
 3 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 785253d..e0db4eb 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -118,8 +118,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
         rc = ERROR_FAIL; goto out;
     }
 
-    rc = libxl__ctx_evtchn_init(gc);
-
     *pctx = ctx;
     return 0;
 
@@ -166,7 +164,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
     assert(!libxl__ev_fd_isregistered(&ctx->watch_efd));
-    libxl__ev_fd_deregister(gc, &ctx->evtchn_efd);
+    assert(!libxl__ev_fd_isregistered(&ctx->evtchn_efd));
     assert(!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd));
 
     /* Now there should be no more events requested from the application: */
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index da0a20e..716f318 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -721,7 +721,7 @@ static void evtchn_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
 
 int libxl__ctx_evtchn_init(libxl__gc *gc) {
     xc_evtchn *xce;
-    int rc, fd;
+    int rc;
 
     if (CTX->xce)
         return 0;
@@ -733,14 +733,10 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
         goto out;
     }
 
-    fd = xc_evtchn_fd(xce);
-    assert(fd >= 0);
+    CTX->evtchn_fd = xc_evtchn_fd(xce);
+    assert(CTX->evtchn_fd >= 0);
 
-    rc = libxl_fd_set_nonblock(CTX, fd, 1);
-    if (rc) goto out;
-
-    rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd,
-                               evtchn_fd_callback, fd, POLLIN);
+    rc = libxl_fd_set_nonblock(CTX, CTX->evtchn_fd, 1);
     if (rc) goto out;
 
     CTX->xce = xce;
@@ -751,6 +747,12 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
     return rc;
 }
 
+static void evtchn_check_fd_deregister(libxl__gc *gc)
+{
+    if (CTX->xce && LIBXL_LIST_EMPTY(&CTX->evtchns_waiting))
+        libxl__ev_fd_deregister(gc, &CTX->evtchn_efd);
+}
+
 int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
 {
     int r, rc;
@@ -758,6 +760,13 @@ int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
     DBG("ev_evtchn=%p port=%d wait (was waiting=%d)",
         evev, evev->port, evev->waiting);
 
+    rc = libxl__ctx_evtchn_init(gc);
+    if (rc) goto out;
+
+    rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd,
+                               evtchn_fd_callback, CTX->evtchn_fd, POLLIN);
+    if (rc) goto out;
+
     if (evev->waiting)
         return 0;
 
@@ -773,6 +782,7 @@ int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
     return 0;
 
  out:
+    evtchn_check_fd_deregister(gc);
     return rc;
 }
 
@@ -786,6 +796,7 @@ void libxl__ev_evtchn_cancel(libxl__gc *gc, libxl__ev_evtchn *evev)
 
     evev->waiting = 0;
     LIBXL_LIST_REMOVE(evev, entry);
+    evtchn_check_fd_deregister(gc);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 728fe2c..481fbd5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -359,6 +359,7 @@ struct libxl__ctx {
 
     xc_evtchn *xce; /* waiting must be done only with libxl__ev_evtchn* */
     LIBXL_LIST_HEAD(, libxl__ev_evtchn) evtchns_waiting;
+    int evtchn_fd;
     libxl__ev_fd evtchn_efd;
 
     LIBXL_TAILQ_HEAD(libxl__evgen_domain_death_list, libxl_evgen_domain_death)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nU-0000eZ-3h; Thu, 27 Nov 2014 18:28:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nS-0000eA-Ia
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:06 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	55/7C-02702-53D67745; Thu, 27 Nov 2014 18:28:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417112883!15351545!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30396 invoked from network); 27 Nov 2014 18:28:05 -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;
	27 Nov 2014 18:28:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197505802"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:03 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nO-0008K3-UQ;
	Thu, 27 Nov 2014 18:28:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nO-0008LD-GZ;
	Thu, 27 Nov 2014 18:28:02 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:45 +0000
Message-ID: <1417112870-31894-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/6] libxl: events: Assert that libxl_ctx_free
	is not called from a 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>
Content-Type: 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-one in their right mind would do this, and if they did everything
would definitely collapse.  Arrange that if this happens, we crash
ASAP.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..c111f27 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -148,6 +148,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
 {
     if (!ctx) return 0;
 
+    assert(!ctx->osevent_in_hook);
+
     int i;
     GC_INIT(ctx);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nS-0000eG-O6; Thu, 27 Nov 2014 18:28:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nR-0000e5-UQ
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:06 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	60/55-02576-53D67745; Thu, 27 Nov 2014 18:28:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417112883!15351545!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30338 invoked from network); 27 Nov 2014 18:28:04 -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;
	27 Nov 2014 18:28:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197505800"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:02 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nO-0008K0-Hs;
	Thu, 27 Nov 2014 18:28:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nO-0008LA-4E;
	Thu, 27 Nov 2014 18:28:02 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:44 +0000
Message-ID: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417083745.12784.1.camel@citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 0/6] libxl: events: Tear down fd
	interests when idle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If libxl_event_register_callbacks is called with nonzero hooks while
any part of libxl has any fd interests registered internally, then:

 * There is no way for libxl to notify the application that it wants
   to be told about these fds, because the spec in the doc comment
   says that the new hooks are not called for existing interests.

 * When libxl becomes no longer interested, it will try to find the
   nexus for the deregistration hook.  But such a nexus is only set up
   with nonzero hooks, so libxl will dereference NULL.

 * Specifically, since 66bff9fd492f, libxl would unconditionally
   become interested in its event channel fd during setup.  So if the
   application sets nontrivial hooks it will always crash in
   libxl_ctx_free.  (This case reported as a bug by Ian Campbell.)

To fix this, it would be nice to simply forbid `late' registration of
event hooks.  But this would be an incompatible API changel.  And
indeed libvirt already registers event hooks after using the ctx to
create a domain (!)

So instead we add the minimum workable restriction: hooks can (only)
be registered when libxl is idle.

To do this we need to:
 * Defer registration of fds until they are needed.
 * Deregister fds again as they become idle.
There is no need to do anything about timeouts because an idle libxl
already never has any timeouts.

In this series I add defensive assertions.  This is a good idea
because violations of the rules typically produce crashes anyway, but
distant from the cause.


This series should be included in Xen 4.5:

The evtchn fd issue is new in 4.5 - that is, we have a regression
since 4.4.  It causes libvirt to segfault.

But even in 4.4 there are potential bugs, with symptoms such as the
libxl watch fd not being properly registered, so that operations are
unreasonably delayed, or crashes on ctx teardown.  So after these
patches make it into 4.5 master the relevant subset should probably be
backported.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nU-0000ek-Eo; Thu, 27 Nov 2014 18:28:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nS-0000eB-N2
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:06 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	75/4B-02699-63D67745; Thu, 27 Nov 2014 18:28:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417112884!15289546!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1806 invoked from network); 27 Nov 2014 18:28:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:28:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197246003"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:03 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008K6-7J;
	Thu, 27 Nov 2014 18:28:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nO-0008LJ-Tq;
	Thu, 27 Nov 2014 18:28:02 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:46 +0000
Message-ID: <1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/6] libxl: events: Deregister xenstore watch fd
	when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We want to have no fd events registered when we are idle.
In this patch, deal with the xenstore watch fd:

* Track the total number of active watches.
* When deregistering a watch, or when watch registration fails, check
  whether there are now no watches and if so deregister the fd.
* On libxl teardown, the watch fd should therefore be unregistered.
  assert that this is the case.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    2 +-
 tools/libxl/libxl_event.c    |   11 +++++++++++
 tools/libxl/libxl_internal.h |    2 +-
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index c111f27..12a1013 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -164,7 +164,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
-    libxl__ev_fd_deregister(gc, &ctx->watch_efd);
+    assert(!libxl__ev_fd_isregistered(&ctx->watch_efd));
     libxl__ev_fd_deregister(gc, &ctx->evtchn_efd);
     libxl__ev_fd_deregister(gc, &ctx->sigchld_selfpipe_efd);
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 22b1227..da0a20e 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -524,6 +524,13 @@ static char *watch_token(libxl__gc *gc, int slotnum, uint32_t counterval)
     return libxl__sprintf(gc, "%d/%"PRIx32, slotnum, counterval);
 }
 
+static void watches_check_fd_deregister(libxl__gc *gc)
+{
+    assert(CTX->nwatches>=0);
+    if (!CTX->nwatches)
+        libxl__ev_fd_deregister(gc, &CTX->watch_efd);
+}
+
 int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
                                libxl__ev_xswatch_callback *func,
                                const char *path /* copied */)
@@ -579,6 +586,7 @@ int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
     w->slotnum = slotnum;
     w->path = path_copy;
     w->callback = func;
+    CTX->nwatches++;
     libxl__set_watch_slot_contents(use, w);
 
     CTX_UNLOCK;
@@ -590,6 +598,7 @@ int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
     if (use)
         LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
     free(path_copy);
+    watches_check_fd_deregister(gc);
     CTX_UNLOCK;
     return rc;
 }
@@ -614,6 +623,8 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
         libxl__ev_watch_slot *slot = &CTX->watch_slots[w->slotnum];
         LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, slot, empty);
         w->slotnum = -1;
+        CTX->nwatches--;
+        watches_check_fd_deregister(gc);
     } else {
         LOG(DEBUG, "watch w=%p: deregister unregistered", w);
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..728fe2c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -352,7 +352,7 @@ struct libxl__ctx {
     LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
 
     libxl__ev_watch_slot *watch_slots;
-    int watch_nslots;
+    int watch_nslots, nwatches;
     LIBXL_SLIST_HEAD(, libxl__ev_watch_slot) watch_freeslots;
     uint32_t watch_counter; /* helps disambiguate slot reuse */
     libxl__ev_fd watch_efd;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nX-0000fh-6E; Thu, 27 Nov 2014 18:28:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nW-0000f9-3b
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:10 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	60/9E-02953-93D67745; Thu, 27 Nov 2014 18:28:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417112883!15351545!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30430 invoked from network); 27 Nov 2014 18:28:05 -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;
	27 Nov 2014 18:28:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197505805"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:04 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nQ-0008KI-3h;
	Thu, 27 Nov 2014 18:28:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008Lh-T1;
	Thu, 27 Nov 2014 18:28:03 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:50 +0000
Message-ID: <1417112870-31894-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 6/6] libxl: events: Document and enforce actual
	callbacks restriction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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_event_register_callbacks cannot reasonably be called while libxl
is busy (has outstanding operations and/or enabled events).

This is because the previous spec implied (although not entirely
clearly) that event hooks would not be called for existing fd and
timeout interests.  There is thus no way to reliably ensure that libxl
would get told about fds and timeouts which it became interested in
beforehand.

So there have to be no such fds or timeouts, which means that the
callbacks must only be registered or changed when the ctx is idle.

Document this restriction, and enforce it with a pair of asserts.

(It would be nicer, perhaps, to say that the application may not call
libxl_osevent_register_hooks other than right after creating the ctx.
But there are existing callers, including libvirt, who do it later -
even after doing major operations such as domain creation.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c |    2 ++
 tools/libxl/libxl_event.h |    6 ++----
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 716f318..45f0871 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1217,6 +1217,8 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
 {
     GC_INIT(ctx);
     CTX_LOCK;
+    assert(LIBXL_LIST_EMPTY(&ctx->efds));
+    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
     ctx->osevent_hooks = hooks;
     ctx->osevent_user = user;
     CTX_UNLOCK;
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index b5db83c..3c6fcfe 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -124,10 +124,8 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
    * different parameters, as the application likes; the most recent
    * call determines the libxl behaviour.  However it is NOT safe to
    * call _register_callbacks concurrently with, or reentrantly from,
-   * any other libxl function.
-   *
-   * Calls to _register_callbacks do not affect events which have
-   * already occurred.
+   * any other libxl function, nor while any event-generation
+   * facilities are enabled.
    */
 
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nY-0000ga-Vh; Thu, 27 Nov 2014 18:28:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nX-0000fq-MZ
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:11 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	7D/2E-03145-B3D67745; Thu, 27 Nov 2014 18:28:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417112884!15289546!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2161 invoked from network); 27 Nov 2014 18:28:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:28:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197246011"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:09 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008KC-NA;
	Thu, 27 Nov 2014 18:28:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008LX-F3;
	Thu, 27 Nov 2014 18:28:03 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:48 +0000
Message-ID: <1417112870-31894-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/6] libxl: events: Tear down SIGCHLD machinery
	on ctx 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

We want to have no fd events registered when we are idle.
Also, we should put back the default SIGCHLD handler.  So:

 * In libxl_ctx_free, use libxl_childproc_setmode to set the mode to
   the default, which is libxl_sigchld_owner_libxl (ie `libxl owns
   SIGCHLD only when it has active children').

   But of course there are no active children at libxl teardown so
   this results in libxl__sigchld_notneeded: the ctx loses its
   interest in SIGCHLD (unsetting the SIGCHLD handler if we were the
   last ctx) and deregisters the per-ctx selfpipe fd.

 * assert that this is the case: ie that we are no longer interested
   in the selfpipe.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 12a1013..785253d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -162,11 +162,12 @@ int libxl_ctx_free(libxl_ctx *ctx)
     while ((eject = LIBXL_LIST_FIRST(&CTX->disk_eject_evgens)))
         libxl__evdisable_disk_eject(gc, eject);
 
+    libxl_childproc_setmode(CTX,0,0);
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
     assert(!libxl__ev_fd_isregistered(&ctx->watch_efd));
     libxl__ev_fd_deregister(gc, &ctx->evtchn_efd);
-    libxl__ev_fd_deregister(gc, &ctx->sigchld_selfpipe_efd);
+    assert(!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd));
 
     /* Now there should be no more events requested from the application: */
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nS-0000eG-O6; Thu, 27 Nov 2014 18:28:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nR-0000e5-UQ
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:06 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	60/55-02576-53D67745; Thu, 27 Nov 2014 18:28:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417112883!15351545!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30338 invoked from network); 27 Nov 2014 18:28:04 -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;
	27 Nov 2014 18:28:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197505800"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:02 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nO-0008K0-Hs;
	Thu, 27 Nov 2014 18:28:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nO-0008LA-4E;
	Thu, 27 Nov 2014 18:28:02 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:44 +0000
Message-ID: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417083745.12784.1.camel@citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 0/6] libxl: events: Tear down fd
	interests when idle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If libxl_event_register_callbacks is called with nonzero hooks while
any part of libxl has any fd interests registered internally, then:

 * There is no way for libxl to notify the application that it wants
   to be told about these fds, because the spec in the doc comment
   says that the new hooks are not called for existing interests.

 * When libxl becomes no longer interested, it will try to find the
   nexus for the deregistration hook.  But such a nexus is only set up
   with nonzero hooks, so libxl will dereference NULL.

 * Specifically, since 66bff9fd492f, libxl would unconditionally
   become interested in its event channel fd during setup.  So if the
   application sets nontrivial hooks it will always crash in
   libxl_ctx_free.  (This case reported as a bug by Ian Campbell.)

To fix this, it would be nice to simply forbid `late' registration of
event hooks.  But this would be an incompatible API changel.  And
indeed libvirt already registers event hooks after using the ctx to
create a domain (!)

So instead we add the minimum workable restriction: hooks can (only)
be registered when libxl is idle.

To do this we need to:
 * Defer registration of fds until they are needed.
 * Deregister fds again as they become idle.
There is no need to do anything about timeouts because an idle libxl
already never has any timeouts.

In this series I add defensive assertions.  This is a good idea
because violations of the rules typically produce crashes anyway, but
distant from the cause.


This series should be included in Xen 4.5:

The evtchn fd issue is new in 4.5 - that is, we have a regression
since 4.4.  It causes libvirt to segfault.

But even in 4.4 there are potential bugs, with symptoms such as the
libxl watch fd not being properly registered, so that operations are
unreasonably delayed, or crashes on ctx teardown.  So after these
patches make it into 4.5 master the relevant subset should probably be
backported.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nU-0000eZ-3h; Thu, 27 Nov 2014 18:28:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nS-0000eA-Ia
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:06 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	55/7C-02702-53D67745; Thu, 27 Nov 2014 18:28:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417112883!15351545!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30396 invoked from network); 27 Nov 2014 18:28:05 -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;
	27 Nov 2014 18:28:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197505802"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:03 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nO-0008K3-UQ;
	Thu, 27 Nov 2014 18:28:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nO-0008LD-GZ;
	Thu, 27 Nov 2014 18:28:02 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:45 +0000
Message-ID: <1417112870-31894-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/6] libxl: events: Assert that libxl_ctx_free
	is not called from a 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>
Content-Type: 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-one in their right mind would do this, and if they did everything
would definitely collapse.  Arrange that if this happens, we crash
ASAP.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..c111f27 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -148,6 +148,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
 {
     if (!ctx) return 0;
 
+    assert(!ctx->osevent_in_hook);
+
     int i;
     GC_INIT(ctx);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:28:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 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 1Xu3nU-0000ek-Eo; Thu, 27 Nov 2014 18:28:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3nS-0000eB-N2
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:28:06 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	75/4B-02699-63D67745; Thu, 27 Nov 2014 18:28:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417112884!15289546!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1806 invoked from network); 27 Nov 2014 18:28:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:28:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197246003"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:28:03 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3nP-0008K6-7J;
	Thu, 27 Nov 2014 18:28:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3nO-0008LJ-Tq;
	Thu, 27 Nov 2014 18:28:02 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 27 Nov 2014 18:27:46 +0000
Message-ID: <1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/6] libxl: events: Deregister xenstore watch fd
	when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We want to have no fd events registered when we are idle.
In this patch, deal with the xenstore watch fd:

* Track the total number of active watches.
* When deregistering a watch, or when watch registration fails, check
  whether there are now no watches and if so deregister the fd.
* On libxl teardown, the watch fd should therefore be unregistered.
  assert that this is the case.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    2 +-
 tools/libxl/libxl_event.c    |   11 +++++++++++
 tools/libxl/libxl_internal.h |    2 +-
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index c111f27..12a1013 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -164,7 +164,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
-    libxl__ev_fd_deregister(gc, &ctx->watch_efd);
+    assert(!libxl__ev_fd_isregistered(&ctx->watch_efd));
     libxl__ev_fd_deregister(gc, &ctx->evtchn_efd);
     libxl__ev_fd_deregister(gc, &ctx->sigchld_selfpipe_efd);
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 22b1227..da0a20e 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -524,6 +524,13 @@ static char *watch_token(libxl__gc *gc, int slotnum, uint32_t counterval)
     return libxl__sprintf(gc, "%d/%"PRIx32, slotnum, counterval);
 }
 
+static void watches_check_fd_deregister(libxl__gc *gc)
+{
+    assert(CTX->nwatches>=0);
+    if (!CTX->nwatches)
+        libxl__ev_fd_deregister(gc, &CTX->watch_efd);
+}
+
 int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
                                libxl__ev_xswatch_callback *func,
                                const char *path /* copied */)
@@ -579,6 +586,7 @@ int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
     w->slotnum = slotnum;
     w->path = path_copy;
     w->callback = func;
+    CTX->nwatches++;
     libxl__set_watch_slot_contents(use, w);
 
     CTX_UNLOCK;
@@ -590,6 +598,7 @@ int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
     if (use)
         LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
     free(path_copy);
+    watches_check_fd_deregister(gc);
     CTX_UNLOCK;
     return rc;
 }
@@ -614,6 +623,8 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
         libxl__ev_watch_slot *slot = &CTX->watch_slots[w->slotnum];
         LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, slot, empty);
         w->slotnum = -1;
+        CTX->nwatches--;
+        watches_check_fd_deregister(gc);
     } else {
         LOG(DEBUG, "watch w=%p: deregister unregistered", w);
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..728fe2c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -352,7 +352,7 @@ struct libxl__ctx {
     LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
 
     libxl__ev_watch_slot *watch_slots;
-    int watch_nslots;
+    int watch_nslots, nwatches;
     LIBXL_SLIST_HEAD(, libxl__ev_watch_slot) watch_freeslots;
     uint32_t watch_counter; /* helps disambiguate slot reuse */
     libxl__ev_fd watch_efd;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:30:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu3pU-0001Hd-Mq; Thu, 27 Nov 2014 18:30:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3pT-0001HX-TL
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:30:12 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	13/FC-26652-3BD67745; Thu, 27 Nov 2014 18:30:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417113009!13747986!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31635 invoked from network); 27 Nov 2014 18:30:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:30:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197246239"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:30:08 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3pP-0008MU-Ut;
	Thu, 27 Nov 2014 18:30:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3pP-0008Mo-C9;
	Thu, 27 Nov 2014 18:30:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21623.28078.547671.792678@mariner.uk.xensource.com>
Date: Thu, 27 Nov 2014 18:30:06 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 0/6] libxl: events: Tear down fd
	interests when idle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad: here is a set of fixes for libxl which ought IMO to be in 4.5.
See below, or the rest of the thread, for details.  It's broken up
into 6 tiny patches for ease of review.

Ian Jackson writes ("[PATCH for-4.5 0/6] libxl: events: Tear down fd interests when idle"):
> If libxl_event_register_callbacks is called with nonzero hooks while
> any part of libxl has any fd interests registered internally, then:
> 
>  * There is no way for libxl to notify the application that it wants
>    to be told about these fds, because the spec in the doc comment
>    says that the new hooks are not called for existing interests.
> 
>  * When libxl becomes no longer interested, it will try to find the
>    nexus for the deregistration hook.  But such a nexus is only set up
>    with nonzero hooks, so libxl will dereference NULL.
> 
>  * Specifically, since 66bff9fd492f, libxl would unconditionally
>    become interested in its event channel fd during setup.  So if the
>    application sets nontrivial hooks it will always crash in
>    libxl_ctx_free.  (This case reported as a bug by Ian Campbell.)
> 
> To fix this, it would be nice to simply forbid `late' registration of
> event hooks.  But this would be an incompatible API changel.  And
> indeed libvirt already registers event hooks after using the ctx to
> create a domain (!)
> 
> So instead we add the minimum workable restriction: hooks can (only)
> be registered when libxl is idle.
> 
> To do this we need to:
>  * Defer registration of fds until they are needed.
>  * Deregister fds again as they become idle.
> There is no need to do anything about timeouts because an idle libxl
> already never has any timeouts.
> 
> In this series I add defensive assertions.  This is a good idea
> because violations of the rules typically produce crashes anyway, but
> distant from the cause.
> 
> 
> This series should be included in Xen 4.5:
> 
> The evtchn fd issue is new in 4.5 - that is, we have a regression
> since 4.4.  It causes libvirt to segfault.
> 
> But even in 4.4 there are potential bugs, with symptoms such as the
> libxl watch fd not being properly registered, so that operations are
> unreasonably delayed, or crashes on ctx teardown.  So after these
> patches make it into 4.5 master the relevant subset should probably be
> backported.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:30:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu3pU-0001Hd-Mq; Thu, 27 Nov 2014 18:30:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu3pT-0001HX-TL
	for xen-devel@lists.xensource.com; Thu, 27 Nov 2014 18:30:12 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	13/FC-26652-3BD67745; Thu, 27 Nov 2014 18:30:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417113009!13747986!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31635 invoked from network); 27 Nov 2014 18:30:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:30:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197246239"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Thu, 27 Nov 2014 13:30:08 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu3pP-0008MU-Ut;
	Thu, 27 Nov 2014 18:30:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu3pP-0008Mo-C9;
	Thu, 27 Nov 2014 18:30:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21623.28078.547671.792678@mariner.uk.xensource.com>
Date: Thu, 27 Nov 2014 18:30:06 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5 0/6] libxl: events: Tear down fd
	interests when idle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad: here is a set of fixes for libxl which ought IMO to be in 4.5.
See below, or the rest of the thread, for details.  It's broken up
into 6 tiny patches for ease of review.

Ian Jackson writes ("[PATCH for-4.5 0/6] libxl: events: Tear down fd interests when idle"):
> If libxl_event_register_callbacks is called with nonzero hooks while
> any part of libxl has any fd interests registered internally, then:
> 
>  * There is no way for libxl to notify the application that it wants
>    to be told about these fds, because the spec in the doc comment
>    says that the new hooks are not called for existing interests.
> 
>  * When libxl becomes no longer interested, it will try to find the
>    nexus for the deregistration hook.  But such a nexus is only set up
>    with nonzero hooks, so libxl will dereference NULL.
> 
>  * Specifically, since 66bff9fd492f, libxl would unconditionally
>    become interested in its event channel fd during setup.  So if the
>    application sets nontrivial hooks it will always crash in
>    libxl_ctx_free.  (This case reported as a bug by Ian Campbell.)
> 
> To fix this, it would be nice to simply forbid `late' registration of
> event hooks.  But this would be an incompatible API changel.  And
> indeed libvirt already registers event hooks after using the ctx to
> create a domain (!)
> 
> So instead we add the minimum workable restriction: hooks can (only)
> be registered when libxl is idle.
> 
> To do this we need to:
>  * Defer registration of fds until they are needed.
>  * Deregister fds again as they become idle.
> There is no need to do anything about timeouts because an idle libxl
> already never has any timeouts.
> 
> In this series I add defensive assertions.  This is a good idea
> because violations of the rules typically produce crashes anyway, but
> distant from the cause.
> 
> 
> This series should be included in Xen 4.5:
> 
> The evtchn fd issue is new in 4.5 - that is, we have a regression
> since 4.4.  It causes libvirt to segfault.
> 
> But even in 4.4 there are potential bugs, with symptoms such as the
> libxl watch fd not being properly registered, so that operations are
> unreasonably delayed, or crashes on ctx teardown.  So after these
> patches make it into 4.5 master the relevant subset should probably be
> backported.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:36:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu3vQ-0001u7-IZ; Thu, 27 Nov 2014 18:36:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1Xu3vP-0001u2-8A
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 18:36:19 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	32/F5-02696-22F67745; Thu, 27 Nov 2014 18:36:18 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417113377!15317672!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27392 invoked from network); 27 Nov 2014 18:36:17 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 18:36:17 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DEA3BACFC;
	Thu, 27 Nov 2014 18:36:16 +0000 (UTC)
Date: Thu, 27 Nov 2014 19:36:16 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141127183616.GV25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5476C66F.5040308@suse.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: x86@kernel.org, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	Joerg Roedel <jroedel@suse.de>, david.vrabel@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
	hypercall when	non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>
>> Some folks had reported that some xen hypercalls take a long time
>> to complete when issued from the userspace private ioctl mechanism,
>> this can happen for instance with some hypercalls that have many
>> sub-operations, this can happen for instance on hypercalls that use
>> multi-call feature whereby Xen lets one hypercall batch out a series
>> of other hypercalls on the hypervisor. At times such hypercalls can
>> even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
>> 120 seconds), this a non-issue issue on preemptible kernels though as
>> the kernel may deschedule such long running tasks. Xen for instance
>> supports multicalls to be preempted as well, this is what Xen calls
>> continuation (see xen commit 42217cbc5b which introduced this [0]).
>> On systems without CONFIG_PREEMPT though -- a kernel with voluntary
>> or no preemption -- a long running hypercall will not be descheduled
>> until the hypercall is complete and the ioctl returns to user space.
>>
>> To help with this David had originally implemented support for use
>> of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
>> solution never went upstream though and upon review to help refactor
>> this I've concluded that usage of preempt_schedule_irq() would be
>> a bit abussive of existing APIs -- for a few reasons:
>>
>> 0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels
>>
>> 1) we want try to consider solutions that might work for other
>>     hypervisors for this same problem, and identify it its an issue
>>     even present on other hypervisors or if this is a self
>>     inflicted architectural issue caused by use of multicalls
>>
>> 2) there is no documentation or profiling of the exact hypercalls
>>     that were causing these issues, nor do we have any context
>>     to help evaluate this any further
>>
>> I at least checked with kvm folks and it seems hypercall preemption
>> is not needed there. We can survey other hypervisors...
>>
>> If 'something like preemption' is needed then CONFIG_PREEMPT
>> should just be enabled and encouraged, it seems we want to
>> encourage CONFIG_PREEMPT on xen, specially when multicalls are
>> used. In the meantime this tries to address a solution to help
>> xen on non CONFIG_PREEMPT kernels.
>>
>> One option tested and evaluated was to put private hypercalls in
>> process context, however this would introduce complexities such
>> originating hypercalls from different contexts. Current xen
>> hypercall callback handlers would need to be changed per architecture,
>> for instance, we'd also incur the cost of switching states from
>> user / kernel (this cost is also present if preempt_schedule_irq()
>> is used). There may be other issues which could be introduced with
>> this strategy as well. The simplest *shared* alternative is instead
>> to just explicitly schedule() at the end of a private hypercall on non
>> preempt kernels. This forces our private hypercall call mechanism
>> to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
>> more context switch but keeps the private hypercall context intact.
>>
>> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
>> [1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
>>
>> Cc: Davidlohr Bueso <dbueso@suse.de>
>> Cc: Joerg Roedel <jroedel@suse.de>
>> Cc: Borislav Petkov <bp@suse.de>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Cc: Jan Beulich <JBeulich@suse.com>
>> Cc: Juergen Gross <JGross@suse.com>
>> Cc: Olaf Hering <ohering@suse.de>
>> Cc: David Vrabel <david.vrabel@citrix.com>
>> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
>> ---
>>   drivers/xen/privcmd.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>> index 569a13b..e29edba 100644
>> --- a/drivers/xen/privcmd.c
>> +++ b/drivers/xen/privcmd.c
>> @@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
>>   			   hypercall.arg[0], hypercall.arg[1],
>>   			   hypercall.arg[2], hypercall.arg[3],
>>   			   hypercall.arg[4]);
>> +#ifndef CONFIG_PREEMPT
>> +	schedule();
>> +#endif
>>
>>   	return ret;
>>   }
>>
>
> Sorry, I don't think this will solve anything. You're calling schedule()
> right after the long running hypercall just nanoseconds before returning
> to the user.

Yeah, well that is what [1] tried as well only it tried using
preempt_schedule_irq() on the hypercall callback...

> I suppose you were mislead by the "int 0x82" in [0]. This is the
> hypercall from the kernel into the hypervisor, e.g. inside of
> privcmd_call().

Nope, you have to consider what was done in [1], I was trying to
do something similar but less complex that didn't involve mucking
with the callbacks but also not abusing APIs.

I'm afraid we don't have much leg room.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:36:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu3vQ-0001u7-IZ; Thu, 27 Nov 2014 18:36:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1Xu3vP-0001u2-8A
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 18:36:19 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	32/F5-02696-22F67745; Thu, 27 Nov 2014 18:36:18 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417113377!15317672!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27392 invoked from network); 27 Nov 2014 18:36:17 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2014 18:36:17 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DEA3BACFC;
	Thu, 27 Nov 2014 18:36:16 +0000 (UTC)
Date: Thu, 27 Nov 2014 19:36:16 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141127183616.GV25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5476C66F.5040308@suse.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: x86@kernel.org, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	Joerg Roedel <jroedel@suse.de>, david.vrabel@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
	hypercall when	non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>
>> Some folks had reported that some xen hypercalls take a long time
>> to complete when issued from the userspace private ioctl mechanism,
>> this can happen for instance with some hypercalls that have many
>> sub-operations, this can happen for instance on hypercalls that use
>> multi-call feature whereby Xen lets one hypercall batch out a series
>> of other hypercalls on the hypervisor. At times such hypercalls can
>> even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
>> 120 seconds), this a non-issue issue on preemptible kernels though as
>> the kernel may deschedule such long running tasks. Xen for instance
>> supports multicalls to be preempted as well, this is what Xen calls
>> continuation (see xen commit 42217cbc5b which introduced this [0]).
>> On systems without CONFIG_PREEMPT though -- a kernel with voluntary
>> or no preemption -- a long running hypercall will not be descheduled
>> until the hypercall is complete and the ioctl returns to user space.
>>
>> To help with this David had originally implemented support for use
>> of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
>> solution never went upstream though and upon review to help refactor
>> this I've concluded that usage of preempt_schedule_irq() would be
>> a bit abussive of existing APIs -- for a few reasons:
>>
>> 0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels
>>
>> 1) we want try to consider solutions that might work for other
>>     hypervisors for this same problem, and identify it its an issue
>>     even present on other hypervisors or if this is a self
>>     inflicted architectural issue caused by use of multicalls
>>
>> 2) there is no documentation or profiling of the exact hypercalls
>>     that were causing these issues, nor do we have any context
>>     to help evaluate this any further
>>
>> I at least checked with kvm folks and it seems hypercall preemption
>> is not needed there. We can survey other hypervisors...
>>
>> If 'something like preemption' is needed then CONFIG_PREEMPT
>> should just be enabled and encouraged, it seems we want to
>> encourage CONFIG_PREEMPT on xen, specially when multicalls are
>> used. In the meantime this tries to address a solution to help
>> xen on non CONFIG_PREEMPT kernels.
>>
>> One option tested and evaluated was to put private hypercalls in
>> process context, however this would introduce complexities such
>> originating hypercalls from different contexts. Current xen
>> hypercall callback handlers would need to be changed per architecture,
>> for instance, we'd also incur the cost of switching states from
>> user / kernel (this cost is also present if preempt_schedule_irq()
>> is used). There may be other issues which could be introduced with
>> this strategy as well. The simplest *shared* alternative is instead
>> to just explicitly schedule() at the end of a private hypercall on non
>> preempt kernels. This forces our private hypercall call mechanism
>> to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
>> more context switch but keeps the private hypercall context intact.
>>
>> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
>> [1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
>>
>> Cc: Davidlohr Bueso <dbueso@suse.de>
>> Cc: Joerg Roedel <jroedel@suse.de>
>> Cc: Borislav Petkov <bp@suse.de>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Cc: Jan Beulich <JBeulich@suse.com>
>> Cc: Juergen Gross <JGross@suse.com>
>> Cc: Olaf Hering <ohering@suse.de>
>> Cc: David Vrabel <david.vrabel@citrix.com>
>> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
>> ---
>>   drivers/xen/privcmd.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>> index 569a13b..e29edba 100644
>> --- a/drivers/xen/privcmd.c
>> +++ b/drivers/xen/privcmd.c
>> @@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
>>   			   hypercall.arg[0], hypercall.arg[1],
>>   			   hypercall.arg[2], hypercall.arg[3],
>>   			   hypercall.arg[4]);
>> +#ifndef CONFIG_PREEMPT
>> +	schedule();
>> +#endif
>>
>>   	return ret;
>>   }
>>
>
> Sorry, I don't think this will solve anything. You're calling schedule()
> right after the long running hypercall just nanoseconds before returning
> to the user.

Yeah, well that is what [1] tried as well only it tried using
preempt_schedule_irq() on the hypercall callback...

> I suppose you were mislead by the "int 0x82" in [0]. This is the
> hypercall from the kernel into the hypervisor, e.g. inside of
> privcmd_call().

Nope, you have to consider what was done in [1], I was trying to
do something similar but less complex that didn't involve mucking
with the callbacks but also not abusing APIs.

I'm afraid we don't have much leg room.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:47:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18: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 1Xu45i-0002Ga-Ms; Thu, 27 Nov 2014 18:46:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xu45g-0002GV-K2
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 18:46:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4A/4E-15461-F9177745; Thu, 27 Nov 2014 18:46:55 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417114015!11952416!1
X-Originating-IP: [209.85.217.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32709 invoked from network); 27 Nov 2014 18:46:55 -0000
Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com)
	(209.85.217.174)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:46:55 -0000
Received: by mail-lb0-f174.google.com with SMTP id w7so4495591lbi.5
	for <xen-devel@lists.xenproject.org>;
	Thu, 27 Nov 2014 10:46:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=5V5y8iyMCyDROPDqIFW06fcpI3grkYpCUfvEuTdAfOI=;
	b=sjBaGdAiC+x12KPKc7axI6Ct6TymHoGHqU3iwccBJUuuqpo+Foi/aBwr5DLAd1E+O1
	9H6OKerd/vh+MKwoVLRlTN4HVTVJaG83oHWZKANaGtJcfA4ttl5b9ZuofqF3z/yYe7qv
	GeBq+r93oCsG8dD1FO4ynqJG7rIS4rDrEQygUI7iHk94e3wATM1byGOgWO4E39rn0vFH
	7Cqnjh44KBazgt+ObVaWfrmhSQQHoYongZmUhPDIiRrd+7GIgjdUB/MR5/u3WOCaWrLS
	f8XI1FFnJPjRl7rLn+eC02oBtia4jdXQkvZvz+2PCaLaGK0esG9Z4YTjU4J7BPC5I6/8
	pxLw==
X-Received: by 10.153.8.137 with SMTP id dk9mr23808180lad.82.1417114014749;
	Thu, 27 Nov 2014 10:46:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.20.70 with HTTP; Thu, 27 Nov 2014 10:46:34 -0800 (PST)
In-Reply-To: <20141127183616.GV25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Thu, 27 Nov 2014 13:46:34 -0500
X-Google-Sender-Auth: EUNe-5SzN7_b565HIMtdBmMTRMU
Message-ID: <CAB=NE6Xt3QhuKvUm-+-iD4pThsmLZ7oq1nnQbL0Hcw8Q0fpEqw@mail.gmail.com>
To: Juergen Gross <jgross@suse.com>
Cc: x86@kernel.org, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@suse.de>, Joerg Roedel <jroedel@suse.de>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
	hypercall when non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 27, 2014 at 1:36 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> I'm afraid we don't have much leg room.

Let me be clear, I still think putting some hypercalls in process
context *might help* but because of notes 1) and 2) I highlighted I
think this is the best we can do, with more information we should be
able to consider weighing pros / cons with actual metrics from
alternatives, without more information we're just shooting in the dark
and the last thing I want is to see APIs abused or setting precedents.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:47:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18: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 1Xu45i-0002Ga-Ms; Thu, 27 Nov 2014 18:46:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xu45g-0002GV-K2
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 18:46:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4A/4E-15461-F9177745; Thu, 27 Nov 2014 18:46:55 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417114015!11952416!1
X-Originating-IP: [209.85.217.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32709 invoked from network); 27 Nov 2014 18:46:55 -0000
Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com)
	(209.85.217.174)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:46:55 -0000
Received: by mail-lb0-f174.google.com with SMTP id w7so4495591lbi.5
	for <xen-devel@lists.xenproject.org>;
	Thu, 27 Nov 2014 10:46:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=5V5y8iyMCyDROPDqIFW06fcpI3grkYpCUfvEuTdAfOI=;
	b=sjBaGdAiC+x12KPKc7axI6Ct6TymHoGHqU3iwccBJUuuqpo+Foi/aBwr5DLAd1E+O1
	9H6OKerd/vh+MKwoVLRlTN4HVTVJaG83oHWZKANaGtJcfA4ttl5b9ZuofqF3z/yYe7qv
	GeBq+r93oCsG8dD1FO4ynqJG7rIS4rDrEQygUI7iHk94e3wATM1byGOgWO4E39rn0vFH
	7Cqnjh44KBazgt+ObVaWfrmhSQQHoYongZmUhPDIiRrd+7GIgjdUB/MR5/u3WOCaWrLS
	f8XI1FFnJPjRl7rLn+eC02oBtia4jdXQkvZvz+2PCaLaGK0esG9Z4YTjU4J7BPC5I6/8
	pxLw==
X-Received: by 10.153.8.137 with SMTP id dk9mr23808180lad.82.1417114014749;
	Thu, 27 Nov 2014 10:46:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.20.70 with HTTP; Thu, 27 Nov 2014 10:46:34 -0800 (PST)
In-Reply-To: <20141127183616.GV25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Thu, 27 Nov 2014 13:46:34 -0500
X-Google-Sender-Auth: EUNe-5SzN7_b565HIMtdBmMTRMU
Message-ID: <CAB=NE6Xt3QhuKvUm-+-iD4pThsmLZ7oq1nnQbL0Hcw8Q0fpEqw@mail.gmail.com>
To: Juergen Gross <jgross@suse.com>
Cc: x86@kernel.org, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@suse.de>, Joerg Roedel <jroedel@suse.de>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
	hypercall when non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 27, 2014 at 1:36 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> I'm afraid we don't have much leg room.

Let me be clear, I still think putting some hypercalls in process
context *might help* but because of notes 1) and 2) I highlighted I
think this is the best we can do, with more information we should be
able to consider weighing pros / cons with actual metrics from
alternatives, without more information we're just shooting in the dark
and the last thing I want is to see APIs abused or setting precedents.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:50:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18: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 1Xu49G-0002NI-B6; Thu, 27 Nov 2014 18:50:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xu49F-0002NC-NS
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 18:50:37 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	8D/6D-03148-C7277745; Thu, 27 Nov 2014 18:50:36 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417114235!15338873!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9231 invoked from network); 27 Nov 2014 18:50:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:50:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197249162"
Message-ID: <54777277.5040401@citrix.com>
Date: Thu, 27 Nov 2014 18:50:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: "Luis R. Rodriguez" <mcgrof@suse.com>, Juergen Gross <jgross@suse.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>	<5476C66F.5040308@suse.com>
	<20141127183616.GV25677@wotan.suse.de>
In-Reply-To: <20141127183616.GV25677@wotan.suse.de>
X-DLP: MIA1
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>, x86@kernel.org,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Borislav Petkov <bp@suse.de>, Olaf Hering <ohering@suse.de>,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
 hypercall when	non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 18:36, Luis R. Rodriguez wrote:
> On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
>> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>
>>> Some folks had reported that some xen hypercalls take a long time
>>> to complete when issued from the userspace private ioctl mechanism,
>>> this can happen for instance with some hypercalls that have many
>>> sub-operations, this can happen for instance on hypercalls that use
>>> multi-call feature whereby Xen lets one hypercall batch out a series
>>> of other hypercalls on the hypervisor. At times such hypercalls can
>>> even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
>>> 120 seconds), this a non-issue issue on preemptible kernels though as
>>> the kernel may deschedule such long running tasks. Xen for instance
>>> supports multicalls to be preempted as well, this is what Xen calls
>>> continuation (see xen commit 42217cbc5b which introduced this [0]).
>>> On systems without CONFIG_PREEMPT though -- a kernel with voluntary
>>> or no preemption -- a long running hypercall will not be descheduled
>>> until the hypercall is complete and the ioctl returns to user space.
>>>
>>> To help with this David had originally implemented support for use
>>> of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
>>> solution never went upstream though and upon review to help refactor
>>> this I've concluded that usage of preempt_schedule_irq() would be
>>> a bit abussive of existing APIs -- for a few reasons:
>>>
>>> 0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels
>>>
>>> 1) we want try to consider solutions that might work for other
>>>     hypervisors for this same problem, and identify it its an issue
>>>     even present on other hypervisors or if this is a self
>>>     inflicted architectural issue caused by use of multicalls
>>>
>>> 2) there is no documentation or profiling of the exact hypercalls
>>>     that were causing these issues, nor do we have any context
>>>     to help evaluate this any further
>>>
>>> I at least checked with kvm folks and it seems hypercall preemption
>>> is not needed there. We can survey other hypervisors...
>>>
>>> If 'something like preemption' is needed then CONFIG_PREEMPT
>>> should just be enabled and encouraged, it seems we want to
>>> encourage CONFIG_PREEMPT on xen, specially when multicalls are
>>> used. In the meantime this tries to address a solution to help
>>> xen on non CONFIG_PREEMPT kernels.
>>>
>>> One option tested and evaluated was to put private hypercalls in
>>> process context, however this would introduce complexities such
>>> originating hypercalls from different contexts. Current xen
>>> hypercall callback handlers would need to be changed per architecture,
>>> for instance, we'd also incur the cost of switching states from
>>> user / kernel (this cost is also present if preempt_schedule_irq()
>>> is used). There may be other issues which could be introduced with
>>> this strategy as well. The simplest *shared* alternative is instead
>>> to just explicitly schedule() at the end of a private hypercall on non
>>> preempt kernels. This forces our private hypercall call mechanism
>>> to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
>>> more context switch but keeps the private hypercall context intact.
>>>
>>> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
>>> [1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
>>>
>>> Cc: Davidlohr Bueso <dbueso@suse.de>
>>> Cc: Joerg Roedel <jroedel@suse.de>
>>> Cc: Borislav Petkov <bp@suse.de>
>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Cc: Jan Beulich <JBeulich@suse.com>
>>> Cc: Juergen Gross <JGross@suse.com>
>>> Cc: Olaf Hering <ohering@suse.de>
>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
>>> ---
>>>   drivers/xen/privcmd.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>> index 569a13b..e29edba 100644
>>> --- a/drivers/xen/privcmd.c
>>> +++ b/drivers/xen/privcmd.c
>>> @@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
>>>   			   hypercall.arg[0], hypercall.arg[1],
>>>   			   hypercall.arg[2], hypercall.arg[3],
>>>   			   hypercall.arg[4]);
>>> +#ifndef CONFIG_PREEMPT
>>> +	schedule();
>>> +#endif
>>>
>>>   	return ret;
>>>   }
>>>
>> Sorry, I don't think this will solve anything. You're calling schedule()
>> right after the long running hypercall just nanoseconds before returning
>> to the user.
> Yeah, well that is what [1] tried as well only it tried using
> preempt_schedule_irq() on the hypercall callback...
>
>> I suppose you were mislead by the "int 0x82" in [0]. This is the
>> hypercall from the kernel into the hypervisor, e.g. inside of
>> privcmd_call().
> Nope, you have to consider what was done in [1], I was trying to
> do something similar but less complex that didn't involve mucking
> with the callbacks but also not abusing APIs.
>
> I'm afraid we don't have much leg room.

XenServer uses

https://github.com/xenserver/linux-3.x.pg/blob/master/master/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch

to deal with these issues.  That patch is based on 3.10.

I can remember whether this has been submitted upstream before (and
there were outstanding issues), or whether it fell at an inconvenient
time with our development cycles.

David: do you recall?

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 18:50:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 18: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 1Xu49G-0002NI-B6; Thu, 27 Nov 2014 18:50:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xu49F-0002NC-NS
	for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 18:50:37 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	8D/6D-03148-C7277745; Thu, 27 Nov 2014 18:50:36 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417114235!15338873!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9231 invoked from network); 27 Nov 2014 18:50:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2014 18:50:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208";a="197249162"
Message-ID: <54777277.5040401@citrix.com>
Date: Thu, 27 Nov 2014 18:50:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: "Luis R. Rodriguez" <mcgrof@suse.com>, Juergen Gross <jgross@suse.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>	<5476C66F.5040308@suse.com>
	<20141127183616.GV25677@wotan.suse.de>
In-Reply-To: <20141127183616.GV25677@wotan.suse.de>
X-DLP: MIA1
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>, x86@kernel.org,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Borislav Petkov <bp@suse.de>, Olaf Hering <ohering@suse.de>,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
 hypercall when	non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 18:36, Luis R. Rodriguez wrote:
> On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
>> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>
>>> Some folks had reported that some xen hypercalls take a long time
>>> to complete when issued from the userspace private ioctl mechanism,
>>> this can happen for instance with some hypercalls that have many
>>> sub-operations, this can happen for instance on hypercalls that use
>>> multi-call feature whereby Xen lets one hypercall batch out a series
>>> of other hypercalls on the hypervisor. At times such hypercalls can
>>> even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
>>> 120 seconds), this a non-issue issue on preemptible kernels though as
>>> the kernel may deschedule such long running tasks. Xen for instance
>>> supports multicalls to be preempted as well, this is what Xen calls
>>> continuation (see xen commit 42217cbc5b which introduced this [0]).
>>> On systems without CONFIG_PREEMPT though -- a kernel with voluntary
>>> or no preemption -- a long running hypercall will not be descheduled
>>> until the hypercall is complete and the ioctl returns to user space.
>>>
>>> To help with this David had originally implemented support for use
>>> of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
>>> solution never went upstream though and upon review to help refactor
>>> this I've concluded that usage of preempt_schedule_irq() would be
>>> a bit abussive of existing APIs -- for a few reasons:
>>>
>>> 0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels
>>>
>>> 1) we want try to consider solutions that might work for other
>>>     hypervisors for this same problem, and identify it its an issue
>>>     even present on other hypervisors or if this is a self
>>>     inflicted architectural issue caused by use of multicalls
>>>
>>> 2) there is no documentation or profiling of the exact hypercalls
>>>     that were causing these issues, nor do we have any context
>>>     to help evaluate this any further
>>>
>>> I at least checked with kvm folks and it seems hypercall preemption
>>> is not needed there. We can survey other hypervisors...
>>>
>>> If 'something like preemption' is needed then CONFIG_PREEMPT
>>> should just be enabled and encouraged, it seems we want to
>>> encourage CONFIG_PREEMPT on xen, specially when multicalls are
>>> used. In the meantime this tries to address a solution to help
>>> xen on non CONFIG_PREEMPT kernels.
>>>
>>> One option tested and evaluated was to put private hypercalls in
>>> process context, however this would introduce complexities such
>>> originating hypercalls from different contexts. Current xen
>>> hypercall callback handlers would need to be changed per architecture,
>>> for instance, we'd also incur the cost of switching states from
>>> user / kernel (this cost is also present if preempt_schedule_irq()
>>> is used). There may be other issues which could be introduced with
>>> this strategy as well. The simplest *shared* alternative is instead
>>> to just explicitly schedule() at the end of a private hypercall on non
>>> preempt kernels. This forces our private hypercall call mechanism
>>> to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
>>> more context switch but keeps the private hypercall context intact.
>>>
>>> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
>>> [1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
>>>
>>> Cc: Davidlohr Bueso <dbueso@suse.de>
>>> Cc: Joerg Roedel <jroedel@suse.de>
>>> Cc: Borislav Petkov <bp@suse.de>
>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Cc: Jan Beulich <JBeulich@suse.com>
>>> Cc: Juergen Gross <JGross@suse.com>
>>> Cc: Olaf Hering <ohering@suse.de>
>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
>>> ---
>>>   drivers/xen/privcmd.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>> index 569a13b..e29edba 100644
>>> --- a/drivers/xen/privcmd.c
>>> +++ b/drivers/xen/privcmd.c
>>> @@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
>>>   			   hypercall.arg[0], hypercall.arg[1],
>>>   			   hypercall.arg[2], hypercall.arg[3],
>>>   			   hypercall.arg[4]);
>>> +#ifndef CONFIG_PREEMPT
>>> +	schedule();
>>> +#endif
>>>
>>>   	return ret;
>>>   }
>>>
>> Sorry, I don't think this will solve anything. You're calling schedule()
>> right after the long running hypercall just nanoseconds before returning
>> to the user.
> Yeah, well that is what [1] tried as well only it tried using
> preempt_schedule_irq() on the hypercall callback...
>
>> I suppose you were mislead by the "int 0x82" in [0]. This is the
>> hypercall from the kernel into the hypervisor, e.g. inside of
>> privcmd_call().
> Nope, you have to consider what was done in [1], I was trying to
> do something similar but less complex that didn't involve mucking
> with the callbacks but also not abusing APIs.
>
> I'm afraid we don't have much leg room.

XenServer uses

https://github.com/xenserver/linux-3.x.pg/blob/master/master/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch

to deal with these issues.  That patch is based on 3.10.

I can remember whether this has been submitted upstream before (and
there were outstanding issues), or whether it fell at an inconvenient
time with our development cycles.

David: do you recall?

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Nov 27 23:40:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 23: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 1Xu8fY-0001ij-5G; Thu, 27 Nov 2014 23:40: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 1Xu8fW-0001ie-Io
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 23:40:14 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	AF/6B-26652-D56B7745; Thu, 27 Nov 2014 23:40:13 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417131612!10867871!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9776 invoked from network); 27 Nov 2014 23:40:13 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 23:40:13 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sARNdrRn022634;
	Thu, 27 Nov 2014 23:39:57 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sARNdlcU015324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Nov 2014 23:39:47 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sARNdldb030308;
	Thu, 27 Nov 2014 23:39:47 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sARNdlEX030305; Thu, 27 Nov 2014 23:39:47 GMT
Date: Thu, 27 Nov 2014 23:39:47 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <54764384.5010008@citrix.com>
Message-ID: <alpine.DEB.2.00.1411272336520.5756@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk>
	<54764384.5010008@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-598819085-1417131587=:5756"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sARNdrRn022634
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix migration failure with xl migrate
 --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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-598819085-1417131587=:5756
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Wed, 26 Nov 2014, Andrew Cooper wrote:

> On 26/11/2014 20:51, M A Young wrote:
> 
> --- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig	2014-10-24 15:22:40.000000000
>  +0100
> +++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c	2014-11-25 20:29:06.723856433 +000
> 0
> @@ -383,7 +383,7 @@
> 
> 
> Sadly, changing printf_info() like this has an unintended knock-on effect to
> create_domain() (xl create, migrate-recevive, restore) and xl
> config-update.  I think you might have to pass FILE pointers all the way
> through.

Yes, I had missed the second use of printf_info() . I will post a revised 
patch shortly.

> -    puts(buf);
> +    fputs(buf,stderr);
> 
> 
> puts() and fputs() are not quite synonymous.  puts() will unconditionally
> add an extra newline to stdout.  It is unclear whether the string from
> yajl_gen_get_buf() comes with a trailing newline or not.  If the output
> looks ok, it probably is fine.

It looked okay in my testing.

 	Michael Young
--8323329-598819085-1417131587=:5756
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-598819085-1417131587=:5756--


From xen-devel-bounces@lists.xen.org Thu Nov 27 23:40:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Nov 2014 23: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 1Xu8fY-0001ij-5G; Thu, 27 Nov 2014 23:40: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 1Xu8fW-0001ie-Io
	for xen-devel@lists.xen.org; Thu, 27 Nov 2014 23:40:14 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	AF/6B-26652-D56B7745; Thu, 27 Nov 2014 23:40:13 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417131612!10867871!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9776 invoked from network); 27 Nov 2014 23:40:13 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2014 23:40:13 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sARNdrRn022634;
	Thu, 27 Nov 2014 23:39:57 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sARNdlcU015324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Nov 2014 23:39:47 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sARNdldb030308;
	Thu, 27 Nov 2014 23:39:47 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sARNdlEX030305; Thu, 27 Nov 2014 23:39:47 GMT
Date: Thu, 27 Nov 2014 23:39:47 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <54764384.5010008@citrix.com>
Message-ID: <alpine.DEB.2.00.1411272336520.5756@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411262044580.18257@procyon.dur.ac.uk>
	<54764384.5010008@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-598819085-1417131587=:5756"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sARNdrRn022634
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix migration failure with xl migrate
 --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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-598819085-1417131587=:5756
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Wed, 26 Nov 2014, Andrew Cooper wrote:

> On 26/11/2014 20:51, M A Young wrote:
> 
> --- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig	2014-10-24 15:22:40.000000000
>  +0100
> +++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c	2014-11-25 20:29:06.723856433 +000
> 0
> @@ -383,7 +383,7 @@
> 
> 
> Sadly, changing printf_info() like this has an unintended knock-on effect to
> create_domain() (xl create, migrate-recevive, restore) and xl
> config-update.  I think you might have to pass FILE pointers all the way
> through.

Yes, I had missed the second use of printf_info() . I will post a revised 
patch shortly.

> -    puts(buf);
> +    fputs(buf,stderr);
> 
> 
> puts() and fputs() are not quite synonymous.  puts() will unconditionally
> add an extra newline to stdout.  It is unclear whether the string from
> yajl_gen_get_buf() comes with a trailing newline or not.  If the output
> looks ok, it probably is fine.

It looked okay in my testing.

 	Michael Young
--8323329-598819085-1417131587=:5756
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-598819085-1417131587=:5756--


From xen-devel-bounces@lists.xen.org Fri Nov 28 00:07:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 00: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 1Xu95V-0002zN-OZ; Fri, 28 Nov 2014 00:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu95U-0002zI-2C
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 00:07:04 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	19/43-25727-7ACB7745; Fri, 28 Nov 2014 00:07:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417133220!11916757!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9927 invoked from network); 28 Nov 2014 00:07:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 00:07:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,473,1413244800"; d="scan'208";a="197293926"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 19:06:51 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu95H-0003tD-3b;
	Fri, 28 Nov 2014 00:06:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu95G-0008Af-Tu;
	Fri, 28 Nov 2014 00:06:50 +0000
Date: Fri, 28 Nov 2014 00:06:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31873-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31873: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31873 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31873/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops             3 host-install(3)         broken REGR. vs. 31853
 build-armhf                   3 host-install(3)         broken REGR. vs. 31853
 build-i386-oldkern            3 host-install(3)         broken REGR. vs. 31853

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-i386  5 xen-boot                  fail pass in 31861
 test-amd64-amd64-xl-sedf-pin  5 xen-boot           fail in 31861 pass in 31873
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail in 31861 pass in 31873
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 31861 pass in 31873

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31853

Tests which did not succeed, but are not blocking:
 build-armhf-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-armhf-armhf-libvirt      9 guest-start           fail in 31861 never pass
 test-armhf-armhf-xl          10 migrate-support-check fail in 31861 never pass

version targeted for testing:
 xen                  d85728a3c5e112383e99fc23825fd238a4fb8c63
baseline version:
 xen                  104072fc1c7e6ed117c70fa7f91ecc9946f8f654

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <julien.grall@linaro.org>
  Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  broken  
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          blocked 
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf-pvops host-install(3)
broken-step build-armhf host-install(3)
broken-step build-i386-oldkern host-install(3)

Not pushing.

------------------------------------------------------------
commit d85728a3c5e112383e99fc23825fd238a4fb8c63
Merge: 8f4023d 13f72e9
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 25 16:24:19 2014 +0000

    Merge branch 'staging' of ssh://xenbits.xen.org/home/xen/git/xen into staging

commit 13f72e92a32380e94cb0c86725a1b38a6d191461
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 17:21:52 2014 +0100

    vNUMA: rename interface structures
    
    No-one (including me) paid attention during review that these
    structures don't adhere to the naming requirements of the public
    interface: Consistently use xen_ prefixes at least for all new
    additions.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 8f4023dd7d77de7b2c1af77e86637202a33f948a
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Thu Nov 20 15:48:47 2014 +0000

    libxc: don't leak buffer containing the uncompressed PV kernel
    
    The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
    is freed by xc_dom_release. However the various xc_try_*_decode routines (other
    than the gzip one) just use plain malloc/realloc and therefore the buffer ends
    up leaked.
    
    The memory pool currently supports mmap'd buffers as well as a directly
    allocated buffers, however the try decode routines make use of realloc and do
    not fit well into this model. Introduce a concept of an external memory block
    to the memory pool and provide an interface to register such memory.
    
    The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
    mmap_ prefix since they are now also used for external memory blocks.
    
    We are only seeing this now because the gzip decoder doesn't leak and it's only
    relatively recently that kernels in the wild have switched to better
    compression.
    
    This is https://bugs.debian.org/767295
    
    Reported by: Gedalya <gedalya@gedalya.net>
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: Wei Liu <wei.liu2@citrix.com>

commit d17405f8153f7419db680a183f10129410feca05
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed Nov 19 15:28:15 2014 +0000

    xen: arm: Support the other 4 PCI buses on Xgene
    
    Currently we only establish specific mappings for pcie0, which is
    used on the Mustang platform. However at least McDivitt uses pcie3.
    So wire up all the others, based on whether the corresponding DT node
    is marked as available.
    
    This results in no change for Mustang.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>

commit 31180f87e4f7f63e3bca029b4a60978f57eb0331
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Fri Nov 21 14:31:30 2014 +0000

    xen/arm: clear UIE on hypervisor entry
    
    UIE being set can cause maintenance interrupts to occur when Xen writes
    to one or more LR registers. The effect is a busy loop around the
    interrupt handler in Xen
    (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
    Tested-by: Julien Grall <julien.grall@linaro.org>
    Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 8342b121cd57f4bebedc7ab4be69922b07afefa5
Author: Julien Grall <julien.grall@linaro.org>
Date:   Thu Nov 20 17:36:03 2014 +0000

    scripts/get_maintainer.pl: Correctly CC the maintainers
    
    The current script is setting $email_remove_duplicates to 1 by default, on
    complex patch (see [1]), this will result to ommitting randomly some
    maintainers.
    
    This is because, the script will:
        1) Get the list of maintainers of the file (incidentally all the
           maintainers in "THE REST" role are added). If the email address already
           exists in the global list, skip it. => The role will be lost
        2) Filter the list to remove the entry with "THE REST" role
    
    So if a maintainers is marked with "THE REST" role on the first file and
    actually be an x86 maintainers on the script, the script will only retain
    the "THE REST" role. During the filtering step, this maintainers will
    therefore be dropped.
    
    This patch fixes this by setting $email_remove_duplicates to 0 by default.
    The new behavior of the script will be:
        1) Append the list of maintainers for every file
        2) Filter the list to remove the entry with "THE REST" role
        3) Remove duplicated email address
    
    Example:
    
    Patch: https://patches.linaro.org/41083/
    
    Before the patch:
    
    Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Ian Jackson <ian.jackson@eu.citrix.com>
    Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Ian Campbell <ian.campbell@citrix.com>
    Wei Liu <wei.liu2@citrix.com>
    George Dunlap <george.dunlap@eu.citrix.com>
    xen-devel@lists.xen.org
    
    After the patch:
    
    Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Ian Jackson <ian.jackson@eu.citrix.com>
    Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Ian Campbell <ian.campbell@citrix.com>
    Wei Liu <wei.liu2@citrix.com>
    Stefano Stabellini <stefano.stabellini@citrix.com>
    Tim Deegan <tim@xen.org>
    Keir Fraser <keir@xen.org>
    Jan Beulich <jbeulich@suse.com>
    George Dunlap <george.dunlap@eu.citrix.com>
    xen-devel@lists.xen.org
    
    [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    CC: Don Slutz <dslutz@verizon.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 47c6e7f28ddc27f194c7c4902ea3163ba582b582
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Wed Nov 12 17:31:33 2014 +0000

    xl: Return proper error codes for block-attach and block-detach
    
    Return proper error codes on failure so that scripts can tell whether
    the command completed properly or not.
    
    This is not a proper fix, since it fails to call
    libxl_device_disk_dispose() on the error path.  But a proper fix
    requires some refactoring, so given where we are in the release
    process, it's better to have a fix that is simple and obvious, and do
    the refactoring once the next development window opens up.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 28b4baacd599e8c10e6dac055f6a939bb730fb8a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:08:57 2014 +0100

    x86/HVM: don't crash guest upon problems occurring in user mode
    
    This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
    exit occurred in guest kernel mode") to a few more cases, including the
    failed VM entry one that XSA-110 was needed to be issued for.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 1516b33961028ba4f6e70c0da464e9ed0a190760
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:08:04 2014 +0100

    x86: don't ignore foreigndom input on various MMUEXT ops
    
    Instead properly fail requests that shouldn't be issued on foreign
    domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
    operation to work that way.
    
    In the course of doing this the need to always clear "okay" even when
    wanting an error code other than -EINVAL became unwieldy, so the
    respective logic is being adjusted at once, together with a little
    other related cleanup.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit dc419f0a3752032ab00124dc55609d9231e53128
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:07:09 2014 +0100

    x86: tighten page table owner checking in do_mmu_update()
    
    MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
    a bad page table domain being specified.
    
    Also pt_owner can't be NULL when reaching the "out" label, so the
    respective check can be dropped.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 0aabd10525326edfe5098c2ec5bfe05db7732c32
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:05:29 2014 +0100

    x86/cpuidle: don't count C1 multiple times
    
    Commit 4ca6f9f0 ("x86/cpuidle: publish new states only after fully
    initializing them") resulted in the state counter to be incremented
    for C1 despite that using a fixed table entry (and the statically
    initialized counter value already accounting for it and C0).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 00:07:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 00: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 1Xu95V-0002zN-OZ; Fri, 28 Nov 2014 00:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xu95U-0002zI-2C
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 00:07:04 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	19/43-25727-7ACB7745; Fri, 28 Nov 2014 00:07:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417133220!11916757!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9927 invoked from network); 28 Nov 2014 00:07:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 00:07:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,473,1413244800"; d="scan'208";a="197293926"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 19:06:51 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xu95H-0003tD-3b;
	Fri, 28 Nov 2014 00:06:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xu95G-0008Af-Tu;
	Fri, 28 Nov 2014 00:06:50 +0000
Date: Fri, 28 Nov 2014 00:06:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31873-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31873: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31873 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31873/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops             3 host-install(3)         broken REGR. vs. 31853
 build-armhf                   3 host-install(3)         broken REGR. vs. 31853
 build-i386-oldkern            3 host-install(3)         broken REGR. vs. 31853

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-i386  5 xen-boot                  fail pass in 31861
 test-amd64-amd64-xl-sedf-pin  5 xen-boot           fail in 31861 pass in 31873
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail in 31861 pass in 31873
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 31861 pass in 31873

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31853

Tests which did not succeed, but are not blocking:
 build-armhf-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-armhf-armhf-libvirt      9 guest-start           fail in 31861 never pass
 test-armhf-armhf-xl          10 migrate-support-check fail in 31861 never pass

version targeted for testing:
 xen                  d85728a3c5e112383e99fc23825fd238a4fb8c63
baseline version:
 xen                  104072fc1c7e6ed117c70fa7f91ecc9946f8f654

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <julien.grall@linaro.org>
  Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  broken  
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          blocked 
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf-pvops host-install(3)
broken-step build-armhf host-install(3)
broken-step build-i386-oldkern host-install(3)

Not pushing.

------------------------------------------------------------
commit d85728a3c5e112383e99fc23825fd238a4fb8c63
Merge: 8f4023d 13f72e9
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 25 16:24:19 2014 +0000

    Merge branch 'staging' of ssh://xenbits.xen.org/home/xen/git/xen into staging

commit 13f72e92a32380e94cb0c86725a1b38a6d191461
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 17:21:52 2014 +0100

    vNUMA: rename interface structures
    
    No-one (including me) paid attention during review that these
    structures don't adhere to the naming requirements of the public
    interface: Consistently use xen_ prefixes at least for all new
    additions.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 8f4023dd7d77de7b2c1af77e86637202a33f948a
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Thu Nov 20 15:48:47 2014 +0000

    libxc: don't leak buffer containing the uncompressed PV kernel
    
    The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
    is freed by xc_dom_release. However the various xc_try_*_decode routines (other
    than the gzip one) just use plain malloc/realloc and therefore the buffer ends
    up leaked.
    
    The memory pool currently supports mmap'd buffers as well as a directly
    allocated buffers, however the try decode routines make use of realloc and do
    not fit well into this model. Introduce a concept of an external memory block
    to the memory pool and provide an interface to register such memory.
    
    The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
    mmap_ prefix since they are now also used for external memory blocks.
    
    We are only seeing this now because the gzip decoder doesn't leak and it's only
    relatively recently that kernels in the wild have switched to better
    compression.
    
    This is https://bugs.debian.org/767295
    
    Reported by: Gedalya <gedalya@gedalya.net>
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: Wei Liu <wei.liu2@citrix.com>

commit d17405f8153f7419db680a183f10129410feca05
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed Nov 19 15:28:15 2014 +0000

    xen: arm: Support the other 4 PCI buses on Xgene
    
    Currently we only establish specific mappings for pcie0, which is
    used on the Mustang platform. However at least McDivitt uses pcie3.
    So wire up all the others, based on whether the corresponding DT node
    is marked as available.
    
    This results in no change for Mustang.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>

commit 31180f87e4f7f63e3bca029b4a60978f57eb0331
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Fri Nov 21 14:31:30 2014 +0000

    xen/arm: clear UIE on hypervisor entry
    
    UIE being set can cause maintenance interrupts to occur when Xen writes
    to one or more LR registers. The effect is a busy loop around the
    interrupt handler in Xen
    (http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Reported-and-Tested-by: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
    Tested-by: Julien Grall <julien.grall@linaro.org>
    Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 8342b121cd57f4bebedc7ab4be69922b07afefa5
Author: Julien Grall <julien.grall@linaro.org>
Date:   Thu Nov 20 17:36:03 2014 +0000

    scripts/get_maintainer.pl: Correctly CC the maintainers
    
    The current script is setting $email_remove_duplicates to 1 by default, on
    complex patch (see [1]), this will result to ommitting randomly some
    maintainers.
    
    This is because, the script will:
        1) Get the list of maintainers of the file (incidentally all the
           maintainers in "THE REST" role are added). If the email address already
           exists in the global list, skip it. => The role will be lost
        2) Filter the list to remove the entry with "THE REST" role
    
    So if a maintainers is marked with "THE REST" role on the first file and
    actually be an x86 maintainers on the script, the script will only retain
    the "THE REST" role. During the filtering step, this maintainers will
    therefore be dropped.
    
    This patch fixes this by setting $email_remove_duplicates to 0 by default.
    The new behavior of the script will be:
        1) Append the list of maintainers for every file
        2) Filter the list to remove the entry with "THE REST" role
        3) Remove duplicated email address
    
    Example:
    
    Patch: https://patches.linaro.org/41083/
    
    Before the patch:
    
    Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Ian Jackson <ian.jackson@eu.citrix.com>
    Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Ian Campbell <ian.campbell@citrix.com>
    Wei Liu <wei.liu2@citrix.com>
    George Dunlap <george.dunlap@eu.citrix.com>
    xen-devel@lists.xen.org
    
    After the patch:
    
    Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Ian Jackson <ian.jackson@eu.citrix.com>
    Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Ian Campbell <ian.campbell@citrix.com>
    Wei Liu <wei.liu2@citrix.com>
    Stefano Stabellini <stefano.stabellini@citrix.com>
    Tim Deegan <tim@xen.org>
    Keir Fraser <keir@xen.org>
    Jan Beulich <jbeulich@suse.com>
    George Dunlap <george.dunlap@eu.citrix.com>
    xen-devel@lists.xen.org
    
    [1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    CC: Don Slutz <dslutz@verizon.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 47c6e7f28ddc27f194c7c4902ea3163ba582b582
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Wed Nov 12 17:31:33 2014 +0000

    xl: Return proper error codes for block-attach and block-detach
    
    Return proper error codes on failure so that scripts can tell whether
    the command completed properly or not.
    
    This is not a proper fix, since it fails to call
    libxl_device_disk_dispose() on the error path.  But a proper fix
    requires some refactoring, so given where we are in the release
    process, it's better to have a fix that is simple and obvious, and do
    the refactoring once the next development window opens up.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 28b4baacd599e8c10e6dac055f6a939bb730fb8a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:08:57 2014 +0100

    x86/HVM: don't crash guest upon problems occurring in user mode
    
    This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
    exit occurred in guest kernel mode") to a few more cases, including the
    failed VM entry one that XSA-110 was needed to be issued for.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 1516b33961028ba4f6e70c0da464e9ed0a190760
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:08:04 2014 +0100

    x86: don't ignore foreigndom input on various MMUEXT ops
    
    Instead properly fail requests that shouldn't be issued on foreign
    domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
    operation to work that way.
    
    In the course of doing this the need to always clear "okay" even when
    wanting an error code other than -EINVAL became unwieldy, so the
    respective logic is being adjusted at once, together with a little
    other related cleanup.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit dc419f0a3752032ab00124dc55609d9231e53128
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:07:09 2014 +0100

    x86: tighten page table owner checking in do_mmu_update()
    
    MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
    a bad page table domain being specified.
    
    Also pt_owner can't be NULL when reaching the "out" label, so the
    respective check can be dropped.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 0aabd10525326edfe5098c2ec5bfe05db7732c32
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Nov 25 10:05:29 2014 +0100

    x86/cpuidle: don't count C1 multiple times
    
    Commit 4ca6f9f0 ("x86/cpuidle: publish new states only after fully
    initializing them") resulted in the state counter to be incremented
    for C1 despite that using a fixed table entry (and the statically
    initialized counter value already accounting for it and C0).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 00:29:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 00:29:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu9Qz-0003cH-Tu; Fri, 28 Nov 2014 00:29:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Xu9Qy-0003cC-HF
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 00:29:16 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	0A/8D-08051-BD1C7745; Fri, 28 Nov 2014 00:29:15 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417134554!15352396!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16709 invoked from network); 28 Nov 2014 00:29:15 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 00:29:15 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAS0T12H023981;
	Fri, 28 Nov 2014 00:29:05 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAS0Stil002238
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Nov 2014 00:28:55 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAS0Stwr032233;
	Fri, 28 Nov 2014 00:28:55 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAS0Ssrm032229; Fri, 28 Nov 2014 00:28:54 GMT
Date: Fri, 28 Nov 2014 00:28:54 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1411272342370.5756@procyon.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: sAS0T12H023981
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] fix migration failure with xl migrate --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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Migrations with xl migrate --debug will fail because debugging information 
from the receiving process is written to the stdout channel. This channel 
is also used for status messages so the migration will fail as the sending 
process receives an unexpected message. This patch moves the debugging 
information to the stderr channel.

Version 2 moves some output back to stdout that was accidentally moved 
to stderr in the first version.

Signed-off-by: Michael Young <m.a.young@durham.ac.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 00:29:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 00:29:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu9Qz-0003cH-Tu; Fri, 28 Nov 2014 00:29:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Xu9Qy-0003cC-HF
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 00:29:16 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	0A/8D-08051-BD1C7745; Fri, 28 Nov 2014 00:29:15 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417134554!15352396!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjI2NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16709 invoked from network); 28 Nov 2014 00:29:15 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 00:29:15 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAS0T12H023981;
	Fri, 28 Nov 2014 00:29:05 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAS0Stil002238
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Nov 2014 00:28:55 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sAS0Stwr032233;
	Fri, 28 Nov 2014 00:28:55 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sAS0Ssrm032229; Fri, 28 Nov 2014 00:28:54 GMT
Date: Fri, 28 Nov 2014 00:28:54 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1411272342370.5756@procyon.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: sAS0T12H023981
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] fix migration failure with xl migrate --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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Migrations with xl migrate --debug will fail because debugging information 
from the receiving process is written to the stdout channel. This channel 
is also used for status messages so the migration will fail as the sending 
process receives an unexpected message. This patch moves the debugging 
information to the stderr channel.

Version 2 moves some output back to stdout that was accidentally moved 
to stderr in the first version.

Signed-off-by: Michael Young <m.a.young@durham.ac.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 00:35:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 00:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu9Wa-0003kO-MJ; Fri, 28 Nov 2014 00:35:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1Xu9Wa-0003kJ-4n
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 00:35:04 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	FA/89-02954-733C7745; Fri, 28 Nov 2014 00:35:03 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417134902!15363543!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20297 invoked from network); 28 Nov 2014 00:35:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-27.messagelabs.com with SMTP;
	28 Nov 2014 00:35:02 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 16:35:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,473,1413270000"; d="scan'208";a="644764213"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga002.jf.intel.com with ESMTP; 27 Nov 2014 16:34:52 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 28 Nov 2014 08:34:48 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Fri, 28 Nov 2014 08:34:47 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest
Thread-Index: AQHQAibKSJCUiIzlL0KE7E6vZSUFyJxkbtEAgAAMxwCAAAGJgIAAAuCAgAAFkwCAAAbqgIABGgmAgAAIK4CAABAgAIAALiSAgAANqQCAAKtegIAAjUQAgAjl04CAAG30gIABEbOAgAOo0pA=
Date: Fri, 28 Nov 2014 00:34:46 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E44FB66@shsmsx102.ccr.corp.intel.com>
References: <20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
	<20141119095440.GA1409@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF0EDB@SHSMSX104.ccr.corp.intel.com>
	<547449F3020000780004A924@mail.emea.novell.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF1C3D@SHSMSX104.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF1C3D@SHSMSX104.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: Tim Deegan <tim@xen.org>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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

>>> patch is ok?
>> 
>> No - Tim having confirmed that shadow mode doesn't support 1Gb pages, 
> the feature clearly must not be made visible for shadow mode guest.

>Indeed. Liang, Can you add the shadow mode check in the next version?

Ok , I will do it and resend the patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 00:35:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 00:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xu9Wa-0003kO-MJ; Fri, 28 Nov 2014 00:35:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1Xu9Wa-0003kJ-4n
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 00:35:04 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	FA/89-02954-733C7745; Fri, 28 Nov 2014 00:35:03 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417134902!15363543!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20297 invoked from network); 28 Nov 2014 00:35:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-27.messagelabs.com with SMTP;
	28 Nov 2014 00:35:02 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 16:35:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,473,1413270000"; d="scan'208";a="644764213"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga002.jf.intel.com with ESMTP; 27 Nov 2014 16:34:52 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 28 Nov 2014 08:34:48 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id
	14.03.0195.001; Fri, 28 Nov 2014 08:34:47 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest
Thread-Index: AQHQAibKSJCUiIzlL0KE7E6vZSUFyJxkbtEAgAAMxwCAAAGJgIAAAuCAgAAFkwCAAAbqgIABGgmAgAAIK4CAABAgAIAALiSAgAANqQCAAKtegIAAjUQAgAjl04CAAG30gIABEbOAgAOo0pA=
Date: Fri, 28 Nov 2014 00:34:46 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E44FB66@shsmsx102.ccr.corp.intel.com>
References: <20141117163017.GA29684@deinos.phlegethon.org>
	<546A2503.4000302@citrix.com>
	<20141117170032.GB29684@deinos.phlegethon.org>
	<546A2F7D.8050507@citrix.com>
	<20141118101443.GA13651@deinos.phlegethon.org>
	<546B22ED.5020507@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABEC9DC@SHSMSX104.ccr.corp.intel.com>
	<1416320809.17982.14.camel@citrix.com>
	<20141118151542.GB13651@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABED24D@SHSMSX104.ccr.corp.intel.com>
	<20141119095440.GA1409@deinos.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF0EDB@SHSMSX104.ccr.corp.intel.com>
	<547449F3020000780004A924@mail.emea.novell.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF1C3D@SHSMSX104.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF1C3D@SHSMSX104.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: Tim Deegan <tim@xen.org>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to
 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

>>> patch is ok?
>> 
>> No - Tim having confirmed that shadow mode doesn't support 1Gb pages, 
> the feature clearly must not be made visible for shadow mode guest.

>Indeed. Liang, Can you add the shadow mode check in the next version?

Ok , I will do it and resend the patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 01:18:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 01:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuABv-0000dO-8I; Fri, 28 Nov 2014 01:17:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuABu-0000dJ-1J
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 01:17:46 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	81/09-27785-93DC7745; Fri, 28 Nov 2014 01:17:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417137463!15340712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6211 invoked from network); 28 Nov 2014 01:17:44 -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;
	28 Nov 2014 01:17:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,473,1413244800"; d="scan'208";a="197304011"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 20:17:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuABp-0004F7-L1;
	Fri, 28 Nov 2014 01:17:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuABp-0007RA-2T;
	Fri, 28 Nov 2014 01:17:41 +0000
Date: Fri, 28 Nov 2014 01:17:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31877-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31877: 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 31877 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31877/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl            9 guest-start             fail baseline untested
 test-amd64-i386-xl-credit2   11 guest-saverestore       fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     12 guest-localmigrate      fail baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10  fail baseline untested
 test-armhf-armhf-xl          11 guest-stop              fail baseline untested
 test-amd64-amd64-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                cb81e95415997a4885e5a211a87a46fadad12109
baseline version:
 linux                5d01410fe4d92081f349b013a2e7a95429e4f2c9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 01:18:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 01:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuABv-0000dO-8I; Fri, 28 Nov 2014 01:17:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuABu-0000dJ-1J
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 01:17:46 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	81/09-27785-93DC7745; Fri, 28 Nov 2014 01:17:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417137463!15340712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6211 invoked from network); 28 Nov 2014 01:17:44 -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;
	28 Nov 2014 01:17:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,473,1413244800"; d="scan'208";a="197304011"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 20:17:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuABp-0004F7-L1;
	Fri, 28 Nov 2014 01:17:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuABp-0007RA-2T;
	Fri, 28 Nov 2014 01:17:41 +0000
Date: Fri, 28 Nov 2014 01:17:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31877-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31877: 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 31877 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31877/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl            9 guest-start             fail baseline untested
 test-amd64-i386-xl-credit2   11 guest-saverestore       fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     12 guest-localmigrate      fail baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10  fail baseline untested
 test-armhf-armhf-xl          11 guest-stop              fail baseline untested
 test-amd64-amd64-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-pair         16 guest-start/debian      fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                cb81e95415997a4885e5a211a87a46fadad12109
baseline version:
 linux                5d01410fe4d92081f349b013a2e7a95429e4f2c9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 01:52:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 01:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuAjG-0001jP-C1; Fri, 28 Nov 2014 01:52: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@citrix.com>) id 1XuAjE-0001jK-Qf
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 01:52:13 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	29/5B-03145-C45D7745; Fri, 28 Nov 2014 01:52:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417139530!15373022!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7159 invoked from network); 28 Nov 2014 01:52:11 -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;
	28 Nov 2014 01:52:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,473,1413244800"; d="scan'208";a="197576805"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 20:52:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuAjA-0004PI-7n;
	Fri, 28 Nov 2014 01:52:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuAjA-0004Q1-16;
	Fri, 28 Nov 2014 01:52:08 +0000
Date: Fri, 28 Nov 2014 01:52:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31881-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31881: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31881 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31881/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt      3 host-install(3)         broken REGR. vs. 31778
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 31778
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 31778
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 31778
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)  broken REGR. vs. 31778
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 31778
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 31778
 test-i386-i386-xl-qemut-winxpsp3  5 xen-boot              fail REGR. vs. 31778

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair   17 guest-migrate/src_host/dst_host fail blocked in 31778
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31778

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3e5c06aeea1ff91c3f2247baae372936b67cf411
baseline version:
 xen                  dc37cab1d0f567639f52cad654068a7e56652e2e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     broken  
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-libvirt host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-xl-qemuu-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-win7-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit 3e5c06aeea1ff91c3f2247baae372936b67cf411
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:18:14 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 7d80d71da3369ddfed5ec4cb822194cfd0faf23e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:17:32 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 01:52:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 01:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuAjG-0001jP-C1; Fri, 28 Nov 2014 01:52: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@citrix.com>) id 1XuAjE-0001jK-Qf
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 01:52:13 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	29/5B-03145-C45D7745; Fri, 28 Nov 2014 01:52:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417139530!15373022!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7159 invoked from network); 28 Nov 2014 01:52:11 -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;
	28 Nov 2014 01:52:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,473,1413244800"; d="scan'208";a="197576805"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Thu, 27 Nov 2014 20:52:08 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuAjA-0004PI-7n;
	Fri, 28 Nov 2014 01:52:08 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuAjA-0004Q1-16;
	Fri, 28 Nov 2014 01:52:08 +0000
Date: Fri, 28 Nov 2014 01:52:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31881-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31881: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31881 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31881/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt      3 host-install(3)         broken REGR. vs. 31778
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 31778
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 31778
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 31778
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)  broken REGR. vs. 31778
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 31778
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 31778
 test-i386-i386-xl-qemut-winxpsp3  5 xen-boot              fail REGR. vs. 31778

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair   17 guest-migrate/src_host/dst_host fail blocked in 31778
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31778

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3e5c06aeea1ff91c3f2247baae372936b67cf411
baseline version:
 xen                  dc37cab1d0f567639f52cad654068a7e56652e2e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     broken  
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-libvirt host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-xl-qemuu-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-win7-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit 3e5c06aeea1ff91c3f2247baae372936b67cf411
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:18:14 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 7d80d71da3369ddfed5ec4cb822194cfd0faf23e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:17:32 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 02:30:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 02:30:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuBJY-0002xy-UM; Fri, 28 Nov 2014 02:29:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@gmail.com>) id 1XuBJX-0002xr-TQ
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 02:29:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2F/86-15461-71ED7745; Fri, 28 Nov 2014 02:29:43 +0000
X-Env-Sender: zhangleiqiang@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417141781!8536878!1
X-Originating-IP: [209.85.220.48]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG,
	MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11479 invoked from network); 28 Nov 2014 02:29:42 -0000
Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com)
	(209.85.220.48)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 02:29:42 -0000
Received: by mail-pa0-f48.google.com with SMTP id rd3so5888650pab.21
	for <xen-devel@lists.xen.org>; Thu, 27 Nov 2014 18:29:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:content-transfer-encoding:mime-version:date
	:subject:message-id:to;
	bh=Qq4HMlcNwz4xZ0MaIubTmXZoxPjC3RjD6ZS0JCE5ejg=;
	b=QmRY6U6HWb4RWQJshH7kDAwXUkTp1GHXNCYBVoyYv+MhYFK87ylKMk26qSW9w5Es8/
	kXwzwY83sYKyCL/lYMuWf7LgnH8TshpbWEx6gXhpQI4loF3q+44D5qqTS2ksbXekUbUQ
	tp5669U8+EIu0ErUQ665Nk7fu40GX/lknbMuOFuD7Pf8mcepag3QSyQhRjgyVJYxjHtp
	ktytBhEhYpGBCQOK0RSbvV/jJY0UjxXSe981rzOTQmOo6wt6uaMSSCOPNVt33+o12lGD
	b32FqJjtWzTgfkU61UvSIb5Sjym11VDT6ePDWk8oYCEsV/4AeV6T2cQIqwR0J8pbe20Z
	0xPw==
X-Received: by 10.67.5.131 with SMTP id cm3mr2070995pad.104.1417141780664;
	Thu, 27 Nov 2014 18:29:40 -0800 (PST)
Received: from [10.62.6.220] ([36.45.0.14])
	by mx.google.com with ESMTPSA id od9sm8210070pbb.96.2014.11.27.18.29.38
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 27 Nov 2014 18:29:39 -0800 (PST)
From: zhangleiqiang <zhangleiqiang@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 28 Nov 2014 10:29:34 +0800
Message-Id: <B2F7CCAC-D433-4EB9-8E3A-53948151C58B@gmail.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Mailer: iPhone Mail (12B411)
Subject: [Xen-devel] Question about network performance difference between
	dom0 and 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="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CiBJIGhhdmUgZG9uZSBzb21lIG5ldHdvcmsgcGVyZm9ybWFuY2UgdGVzdGluZyB1bmRlciBYRU4s
IGFuZCBmb3VuZCB0aGUgcmVzdWx0IHdoaWNoIGlzIHNvbWVob3cgc3RyYW5nZToKCiAgIFdoZW4g
dGVzdGluZyBiZXR3ZWVuIEhvc3RzIChTZW5kZXIgYW5kIHJlY2VpdmVyIHNlcnZlcnMgYXJlIGJv
dGggYm9vdGluZyBmcm9tIGtlcm5lbC1kZWZhdWx0KSwgcnVubmluZyBvbmx5IG9uZSBuZXRwZXJm
IHByb2Nlc3Mgd2lsbCBiZSBlbm91Z2ggdG8gcmVhY2ggdGhlIHVwcGVyIGxpbWl0IG9mIE5JQy4g
SG93ZXZlciwgd2hlbiB0ZXN0aW5nIGJldHdlZW4gRG9tMHMgKFNlbmRlciBhbmQgcmVjZWl2ZXIg
c2VydmVycyBhcmUgYm90aCBib290aW5nIGZyb20ga2VybmVsLXhlbiksIHdlIG11c3QgcnVuIG1v
cmUgY291bnQgb2YgbmV0cGVyZiBwcm9jZXNzIHRvIHJlYWNoIHRoZSB1cHBlciBsaW1pdCBvZiBO
SUMsIHJ1bm5pbmcgb25seSBvbmUgbmV0cGVyZiBwcm9jZXNzIHRoZSB0aHJvdWdob3V0IHdhcyBs
b3cuIFRoZSByZXN1bHRzIHVzaW5nIG9uZSBuZXRwZXJmIHByb2Nlc3MgYXJlIGFzIGZvbGxvd3M6
CgogICAgICAgICBUQ1AgNTEyICAgIFRDUCAxNDYwICAgICBUQ1AgNDA5NiAgICBUQ1AgODUwMApI
b3N0czogICAgOTEzNC4yNCAgICA5NDQ0Ljg0ICA5NDQ4LjA1ICAgICAgOTQ0Ny41OCAgICAoTWJz
KQpEb20wczogICAgMjA2My45ICAgIDMwMTguOTUgICAgIDY1NjEuMjkgICAgICAgICA1MDA4LjE3
ICAgIChNYnMpCgogIFRoZSBxdWVzdGlvbiBpcyB3aHkgb25lIG5ldHBlcmYgcHJvY2VzcyBjYW5u
b3QgcmVhY2ggdGhlIG1heCB0aHJvdWdob3V0IG9mIE5JQyB1bmRlciBEb20wID8gSSBrbm93IHRo
YXQgRG9tMCB3aWxsIGhhdmUgZXh0cmEgb3ZlcmhlYWQgd2hlbiBoYW5kbGluZyBpbnRlcnJ1cHQg
d2hpY2ggbXVzdCBiZSBoYW5kbGVkIGJ5IGh5cGVydmlzb3IgZmlyc3QsIGJ1dCBJIHRoaW5rIGl0
IGlzIG5vdCB0aGUgcmVhc29uIGZvciBpdC4KCiAgVGhlIHRlc3RpbmcgZW52aXJvbm1lbnQgZGV0
YWlscyBhcmUgYXMgZm9sbG93czoKCiAgIDEuIEhhcmR3YXJlCiAgICAgICBhLiBDUFU6IEludGVs
KFIpIFhlb24oUikgQ1BVIEU1NjQ1IEAgMi40MEdIeiwgMiBDUFUgNiBDb3JlcyB3aXRoIEh5cGVy
IFRocmVhZCBlbmFibGVkCiAgICAgICBiLiBOSUM6IEludGVsIENvcnBvcmF0aW9uIDgyNTk5RUIg
MTAtR2lnYWJpdCBTRkkvU0ZQKyBOZXR3b3JrIENvbm5lY3Rpb24gKHJldiAwMSkKICAgMi4gU29m
d2FyZToKICAgICAgIGEuIEhvc3RPUzogU1VTRSBTTEVTIDExIFNQMyAoS2VybmVsIDMuMC43NikK
ICAgICAgIGIuIE5JQyBEcml2ZXI6IElYR0JFIDMuMjEuMiAKICAgICAgIGMuIE9WUzogMi4xLjMK
ICAgICAgIGQuIE1UVTogMTYwMAogICAgICAgZS4gRG9tMKO6NlU2RwogICAzLiBOZXR3b3JraW5n
IEVudmlyb25tZW50OgogICAgICAgYS4gQWxsIG5ldHdvcmsgZmxvd3MgYXJlIHRyYW5zbWl0L3Jl
Y2VpdmUgdGhyb3VnaCBPVlMKICAgICAgIGIuIFNlbmRlciBzZXJ2ZXIgYW5kIHJlY2VpdmVyIHNl
cnZlciBhcmUgY29ubmVjdGVkIGRpcmVjdGx5IGJldHdlZW4gMTBHRSBOSUMKICAgNC4gVGVzdGlu
ZyBUb29sczoKICAgICAgIGEuIFNlbmRlcjogbmV0cGVyZgogICAgICAgYi4gUmVjZWl2ZXI6IG5l
dHNlcnZlcgoKCi0tLS0tLS0tLS0KemhhbmdsZWlxaWFuZyAoVHJ1bXApCgpCZXN0IFJlZ2FyZHMK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Nov 28 02:30:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 02:30:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuBJY-0002xy-UM; Fri, 28 Nov 2014 02:29:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@gmail.com>) id 1XuBJX-0002xr-TQ
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 02:29:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2F/86-15461-71ED7745; Fri, 28 Nov 2014 02:29:43 +0000
X-Env-Sender: zhangleiqiang@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417141781!8536878!1
X-Originating-IP: [209.85.220.48]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG,
	MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11479 invoked from network); 28 Nov 2014 02:29:42 -0000
Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com)
	(209.85.220.48)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 02:29:42 -0000
Received: by mail-pa0-f48.google.com with SMTP id rd3so5888650pab.21
	for <xen-devel@lists.xen.org>; Thu, 27 Nov 2014 18:29:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:content-transfer-encoding:mime-version:date
	:subject:message-id:to;
	bh=Qq4HMlcNwz4xZ0MaIubTmXZoxPjC3RjD6ZS0JCE5ejg=;
	b=QmRY6U6HWb4RWQJshH7kDAwXUkTp1GHXNCYBVoyYv+MhYFK87ylKMk26qSW9w5Es8/
	kXwzwY83sYKyCL/lYMuWf7LgnH8TshpbWEx6gXhpQI4loF3q+44D5qqTS2ksbXekUbUQ
	tp5669U8+EIu0ErUQ665Nk7fu40GX/lknbMuOFuD7Pf8mcepag3QSyQhRjgyVJYxjHtp
	ktytBhEhYpGBCQOK0RSbvV/jJY0UjxXSe981rzOTQmOo6wt6uaMSSCOPNVt33+o12lGD
	b32FqJjtWzTgfkU61UvSIb5Sjym11VDT6ePDWk8oYCEsV/4AeV6T2cQIqwR0J8pbe20Z
	0xPw==
X-Received: by 10.67.5.131 with SMTP id cm3mr2070995pad.104.1417141780664;
	Thu, 27 Nov 2014 18:29:40 -0800 (PST)
Received: from [10.62.6.220] ([36.45.0.14])
	by mx.google.com with ESMTPSA id od9sm8210070pbb.96.2014.11.27.18.29.38
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 27 Nov 2014 18:29:39 -0800 (PST)
From: zhangleiqiang <zhangleiqiang@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 28 Nov 2014 10:29:34 +0800
Message-Id: <B2F7CCAC-D433-4EB9-8E3A-53948151C58B@gmail.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Mailer: iPhone Mail (12B411)
Subject: [Xen-devel] Question about network performance difference between
	dom0 and 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="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CiBJIGhhdmUgZG9uZSBzb21lIG5ldHdvcmsgcGVyZm9ybWFuY2UgdGVzdGluZyB1bmRlciBYRU4s
IGFuZCBmb3VuZCB0aGUgcmVzdWx0IHdoaWNoIGlzIHNvbWVob3cgc3RyYW5nZToKCiAgIFdoZW4g
dGVzdGluZyBiZXR3ZWVuIEhvc3RzIChTZW5kZXIgYW5kIHJlY2VpdmVyIHNlcnZlcnMgYXJlIGJv
dGggYm9vdGluZyBmcm9tIGtlcm5lbC1kZWZhdWx0KSwgcnVubmluZyBvbmx5IG9uZSBuZXRwZXJm
IHByb2Nlc3Mgd2lsbCBiZSBlbm91Z2ggdG8gcmVhY2ggdGhlIHVwcGVyIGxpbWl0IG9mIE5JQy4g
SG93ZXZlciwgd2hlbiB0ZXN0aW5nIGJldHdlZW4gRG9tMHMgKFNlbmRlciBhbmQgcmVjZWl2ZXIg
c2VydmVycyBhcmUgYm90aCBib290aW5nIGZyb20ga2VybmVsLXhlbiksIHdlIG11c3QgcnVuIG1v
cmUgY291bnQgb2YgbmV0cGVyZiBwcm9jZXNzIHRvIHJlYWNoIHRoZSB1cHBlciBsaW1pdCBvZiBO
SUMsIHJ1bm5pbmcgb25seSBvbmUgbmV0cGVyZiBwcm9jZXNzIHRoZSB0aHJvdWdob3V0IHdhcyBs
b3cuIFRoZSByZXN1bHRzIHVzaW5nIG9uZSBuZXRwZXJmIHByb2Nlc3MgYXJlIGFzIGZvbGxvd3M6
CgogICAgICAgICBUQ1AgNTEyICAgIFRDUCAxNDYwICAgICBUQ1AgNDA5NiAgICBUQ1AgODUwMApI
b3N0czogICAgOTEzNC4yNCAgICA5NDQ0Ljg0ICA5NDQ4LjA1ICAgICAgOTQ0Ny41OCAgICAoTWJz
KQpEb20wczogICAgMjA2My45ICAgIDMwMTguOTUgICAgIDY1NjEuMjkgICAgICAgICA1MDA4LjE3
ICAgIChNYnMpCgogIFRoZSBxdWVzdGlvbiBpcyB3aHkgb25lIG5ldHBlcmYgcHJvY2VzcyBjYW5u
b3QgcmVhY2ggdGhlIG1heCB0aHJvdWdob3V0IG9mIE5JQyB1bmRlciBEb20wID8gSSBrbm93IHRo
YXQgRG9tMCB3aWxsIGhhdmUgZXh0cmEgb3ZlcmhlYWQgd2hlbiBoYW5kbGluZyBpbnRlcnJ1cHQg
d2hpY2ggbXVzdCBiZSBoYW5kbGVkIGJ5IGh5cGVydmlzb3IgZmlyc3QsIGJ1dCBJIHRoaW5rIGl0
IGlzIG5vdCB0aGUgcmVhc29uIGZvciBpdC4KCiAgVGhlIHRlc3RpbmcgZW52aXJvbm1lbnQgZGV0
YWlscyBhcmUgYXMgZm9sbG93czoKCiAgIDEuIEhhcmR3YXJlCiAgICAgICBhLiBDUFU6IEludGVs
KFIpIFhlb24oUikgQ1BVIEU1NjQ1IEAgMi40MEdIeiwgMiBDUFUgNiBDb3JlcyB3aXRoIEh5cGVy
IFRocmVhZCBlbmFibGVkCiAgICAgICBiLiBOSUM6IEludGVsIENvcnBvcmF0aW9uIDgyNTk5RUIg
MTAtR2lnYWJpdCBTRkkvU0ZQKyBOZXR3b3JrIENvbm5lY3Rpb24gKHJldiAwMSkKICAgMi4gU29m
d2FyZToKICAgICAgIGEuIEhvc3RPUzogU1VTRSBTTEVTIDExIFNQMyAoS2VybmVsIDMuMC43NikK
ICAgICAgIGIuIE5JQyBEcml2ZXI6IElYR0JFIDMuMjEuMiAKICAgICAgIGMuIE9WUzogMi4xLjMK
ICAgICAgIGQuIE1UVTogMTYwMAogICAgICAgZS4gRG9tMKO6NlU2RwogICAzLiBOZXR3b3JraW5n
IEVudmlyb25tZW50OgogICAgICAgYS4gQWxsIG5ldHdvcmsgZmxvd3MgYXJlIHRyYW5zbWl0L3Jl
Y2VpdmUgdGhyb3VnaCBPVlMKICAgICAgIGIuIFNlbmRlciBzZXJ2ZXIgYW5kIHJlY2VpdmVyIHNl
cnZlciBhcmUgY29ubmVjdGVkIGRpcmVjdGx5IGJldHdlZW4gMTBHRSBOSUMKICAgNC4gVGVzdGlu
ZyBUb29sczoKICAgICAgIGEuIFNlbmRlcjogbmV0cGVyZgogICAgICAgYi4gUmVjZWl2ZXI6IG5l
dHNlcnZlcgoKCi0tLS0tLS0tLS0KemhhbmdsZWlxaWFuZyAoVHJ1bXApCgpCZXN0IFJlZ2FyZHMK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Nov 28 03:35:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 03:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuCKw-0004o0-9u; Fri, 28 Nov 2014 03:35:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liangx.z.li@intel.com>) id 1XuCKv-0004nv-3c
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 03:35:13 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	89/7D-25714-07DE7745; Fri, 28 Nov 2014 03:35:12 +0000
X-Env-Sender: liangx.z.li@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417145711!13749945!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11795 invoked from network); 28 Nov 2014 03:35:11 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-206.messagelabs.com with SMTP;
	28 Nov 2014 03:35:11 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 27 Nov 2014 19:32:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,474,1413270000"; d="scan'208";a="615275391"
Received: from lil.sh.intel.com (HELO localhost) ([10.239.36.68])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 19:35:07 -0800
From: Liang Li <liang.z.li@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 11:28:40 +0800
Message-Id: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Liang Li <liang.z.li@intel.com>, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, andrew.cooper3@citrix.com, yang.z.zhang@intel.com
Subject: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to 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>
MIME-Version: 1.0
Content-Type: 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 hardware support the 1GB pages, expose the feature to guest by
default. Users don't have to use a 'cpuid= ' option in config fil
e to turn it on.

Signed-off-by: Liang Li <liang.z.li@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
---
 tools/libxc/xc_cpuid_x86.c | 3 +++
 xen/arch/x86/hvm/hvm.c     | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index a18b1ff..c97f91a 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -109,6 +109,7 @@ static void amd_xc_cpuid_policy(
         regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */
                     bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_MP) |
                     bitmaskof(X86_FEATURE_MMXEXT) |
@@ -192,6 +193,7 @@ static void intel_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_ABM));
         regs[3] &= (bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_RDTSCP));
         break;
@@ -386,6 +388,7 @@ static void xc_cpuid_hvm_policy(
             clear_bit(X86_FEATURE_LM, regs[3]);
             clear_bit(X86_FEATURE_NX, regs[3]);
             clear_bit(X86_FEATURE_PSE36, regs[3]);
+            clear_bit(X86_FEATURE_PAGE1GB, regs[3]);
         }
         break;
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..c825618 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4287,7 +4287,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
              !host_tsc_is_safe() )
             *edx &= ~cpufeat_mask(X86_FEATURE_RDTSCP);
         /* Hide 1GB-superpage feature if we can't emulate it. */
-        if (!hvm_pse1gb_supported(d))
+        if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
             *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);
         /* Only provide PSE36 when guest runs in 32bit PAE or in long mode */
         if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 03:35:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 03:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuCKw-0004o0-9u; Fri, 28 Nov 2014 03:35:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liangx.z.li@intel.com>) id 1XuCKv-0004nv-3c
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 03:35:13 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	89/7D-25714-07DE7745; Fri, 28 Nov 2014 03:35:12 +0000
X-Env-Sender: liangx.z.li@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417145711!13749945!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11795 invoked from network); 28 Nov 2014 03:35:11 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-206.messagelabs.com with SMTP;
	28 Nov 2014 03:35:11 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 27 Nov 2014 19:32:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,474,1413270000"; d="scan'208";a="615275391"
Received: from lil.sh.intel.com (HELO localhost) ([10.239.36.68])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 19:35:07 -0800
From: Liang Li <liang.z.li@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 11:28:40 +0800
Message-Id: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Liang Li <liang.z.li@intel.com>, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, andrew.cooper3@citrix.com, yang.z.zhang@intel.com
Subject: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to 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>
MIME-Version: 1.0
Content-Type: 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 hardware support the 1GB pages, expose the feature to guest by
default. Users don't have to use a 'cpuid= ' option in config fil
e to turn it on.

Signed-off-by: Liang Li <liang.z.li@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
---
 tools/libxc/xc_cpuid_x86.c | 3 +++
 xen/arch/x86/hvm/hvm.c     | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index a18b1ff..c97f91a 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -109,6 +109,7 @@ static void amd_xc_cpuid_policy(
         regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */
                     bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_MP) |
                     bitmaskof(X86_FEATURE_MMXEXT) |
@@ -192,6 +193,7 @@ static void intel_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_ABM));
         regs[3] &= (bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_RDTSCP));
         break;
@@ -386,6 +388,7 @@ static void xc_cpuid_hvm_policy(
             clear_bit(X86_FEATURE_LM, regs[3]);
             clear_bit(X86_FEATURE_NX, regs[3]);
             clear_bit(X86_FEATURE_PSE36, regs[3]);
+            clear_bit(X86_FEATURE_PAGE1GB, regs[3]);
         }
         break;
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..c825618 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4287,7 +4287,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
              !host_tsc_is_safe() )
             *edx &= ~cpufeat_mask(X86_FEATURE_RDTSCP);
         /* Hide 1GB-superpage feature if we can't emulate it. */
-        if (!hvm_pse1gb_supported(d))
+        if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
             *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);
         /* Only provide PSE36 when guest runs in 32bit PAE or in long mode */
         if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 04:49:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 04:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuDUj-0007KK-CJ; Fri, 28 Nov 2014 04:49:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuDUh-0007KF-IH
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 04:49:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AC/0B-09842-2DEF7745; Fri, 28 Nov 2014 04:49:22 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417150161!11993708!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 516 invoked from network); 28 Nov 2014 04:49:21 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 04:49:21 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8682DAB43;
	Fri, 28 Nov 2014 04:49:20 +0000 (UTC)
Message-ID: <5477FECF.2060404@suse.com>
Date: Fri, 28 Nov 2014 05:49:19 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	"Luis R. Rodriguez" <mcgrof@suse.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>	<5476C66F.5040308@suse.com>
	<20141127183616.GV25677@wotan.suse.de>
	<54777277.5040401@citrix.com>
In-Reply-To: <54777277.5040401@citrix.com>
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>, x86@kernel.org,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Borislav Petkov <bp@suse.de>, Olaf Hering <ohering@suse.de>,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
 hypercall when	non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/27/2014 07:50 PM, Andrew Cooper wrote:
> On 27/11/14 18:36, Luis R. Rodriguez wrote:
>> On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
>>> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
>>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>>
>>>> Some folks had reported that some xen hypercalls take a long time
>>>> to complete when issued from the userspace private ioctl mechanism,
>>>> this can happen for instance with some hypercalls that have many
>>>> sub-operations, this can happen for instance on hypercalls that use
>>>> multi-call feature whereby Xen lets one hypercall batch out a series
>>>> of other hypercalls on the hypervisor. At times such hypercalls can
>>>> even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
>>>> 120 seconds), this a non-issue issue on preemptible kernels though as
>>>> the kernel may deschedule such long running tasks. Xen for instance
>>>> supports multicalls to be preempted as well, this is what Xen calls
>>>> continuation (see xen commit 42217cbc5b which introduced this [0]).
>>>> On systems without CONFIG_PREEMPT though -- a kernel with voluntary
>>>> or no preemption -- a long running hypercall will not be descheduled
>>>> until the hypercall is complete and the ioctl returns to user space.
>>>>
>>>> To help with this David had originally implemented support for use
>>>> of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
>>>> solution never went upstream though and upon review to help refactor
>>>> this I've concluded that usage of preempt_schedule_irq() would be
>>>> a bit abussive of existing APIs -- for a few reasons:
>>>>
>>>> 0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels
>>>>
>>>> 1) we want try to consider solutions that might work for other
>>>>      hypervisors for this same problem, and identify it its an issue
>>>>      even present on other hypervisors or if this is a self
>>>>      inflicted architectural issue caused by use of multicalls
>>>>
>>>> 2) there is no documentation or profiling of the exact hypercalls
>>>>      that were causing these issues, nor do we have any context
>>>>      to help evaluate this any further
>>>>
>>>> I at least checked with kvm folks and it seems hypercall preemption
>>>> is not needed there. We can survey other hypervisors...
>>>>
>>>> If 'something like preemption' is needed then CONFIG_PREEMPT
>>>> should just be enabled and encouraged, it seems we want to
>>>> encourage CONFIG_PREEMPT on xen, specially when multicalls are
>>>> used. In the meantime this tries to address a solution to help
>>>> xen on non CONFIG_PREEMPT kernels.
>>>>
>>>> One option tested and evaluated was to put private hypercalls in
>>>> process context, however this would introduce complexities such
>>>> originating hypercalls from different contexts. Current xen
>>>> hypercall callback handlers would need to be changed per architecture,
>>>> for instance, we'd also incur the cost of switching states from
>>>> user / kernel (this cost is also present if preempt_schedule_irq()
>>>> is used). There may be other issues which could be introduced with
>>>> this strategy as well. The simplest *shared* alternative is instead
>>>> to just explicitly schedule() at the end of a private hypercall on non
>>>> preempt kernels. This forces our private hypercall call mechanism
>>>> to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
>>>> more context switch but keeps the private hypercall context intact.
>>>>
>>>> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
>>>> [1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
>>>>
>>>> Cc: Davidlohr Bueso <dbueso@suse.de>
>>>> Cc: Joerg Roedel <jroedel@suse.de>
>>>> Cc: Borislav Petkov <bp@suse.de>
>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>> Cc: Jan Beulich <JBeulich@suse.com>
>>>> Cc: Juergen Gross <JGross@suse.com>
>>>> Cc: Olaf Hering <ohering@suse.de>
>>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>>> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
>>>> ---
>>>>    drivers/xen/privcmd.c | 3 +++
>>>>    1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>>> index 569a13b..e29edba 100644
>>>> --- a/drivers/xen/privcmd.c
>>>> +++ b/drivers/xen/privcmd.c
>>>> @@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
>>>>    			   hypercall.arg[0], hypercall.arg[1],
>>>>    			   hypercall.arg[2], hypercall.arg[3],
>>>>    			   hypercall.arg[4]);
>>>> +#ifndef CONFIG_PREEMPT
>>>> +	schedule();
>>>> +#endif
>>>>
>>>>    	return ret;
>>>>    }
>>>>
>>> Sorry, I don't think this will solve anything. You're calling schedule()
>>> right after the long running hypercall just nanoseconds before returning
>>> to the user.
>> Yeah, well that is what [1] tried as well only it tried using
>> preempt_schedule_irq() on the hypercall callback...
>>
>>> I suppose you were mislead by the "int 0x82" in [0]. This is the
>>> hypercall from the kernel into the hypervisor, e.g. inside of
>>> privcmd_call().
>> Nope, you have to consider what was done in [1], I was trying to
>> do something similar but less complex that didn't involve mucking
>> with the callbacks but also not abusing APIs.
>>
>> I'm afraid we don't have much leg room.
>
> XenServer uses
>
> https://github.com/xenserver/linux-3.x.pg/blob/master/master/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
>
> to deal with these issues.  That patch is based on 3.10.

Clever. :-)

>
> I can remember whether this has been submitted upstream before (and
> there were outstanding issues), or whether it fell at an inconvenient
> time with our development cycles.

I found

http://lists.xen.org/archives/html/xen-devel/2014-02/msg02540.html

and nothing else.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 04:49:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 04:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuDUj-0007KK-CJ; Fri, 28 Nov 2014 04:49:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuDUh-0007KF-IH
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 04:49:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AC/0B-09842-2DEF7745; Fri, 28 Nov 2014 04:49:22 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417150161!11993708!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 516 invoked from network); 28 Nov 2014 04:49:21 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 04:49:21 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8682DAB43;
	Fri, 28 Nov 2014 04:49:20 +0000 (UTC)
Message-ID: <5477FECF.2060404@suse.com>
Date: Fri, 28 Nov 2014 05:49:19 +0100
From: Juergen Gross <jgross@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	"Luis R. Rodriguez" <mcgrof@suse.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>	<5476C66F.5040308@suse.com>
	<20141127183616.GV25677@wotan.suse.de>
	<54777277.5040401@citrix.com>
In-Reply-To: <54777277.5040401@citrix.com>
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>, x86@kernel.org,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Borislav Petkov <bp@suse.de>, Olaf Hering <ohering@suse.de>,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private
 hypercall when	non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/27/2014 07:50 PM, Andrew Cooper wrote:
> On 27/11/14 18:36, Luis R. Rodriguez wrote:
>> On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
>>> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
>>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>>
>>>> Some folks had reported that some xen hypercalls take a long time
>>>> to complete when issued from the userspace private ioctl mechanism,
>>>> this can happen for instance with some hypercalls that have many
>>>> sub-operations, this can happen for instance on hypercalls that use
>>>> multi-call feature whereby Xen lets one hypercall batch out a series
>>>> of other hypercalls on the hypervisor. At times such hypercalls can
>>>> even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
>>>> 120 seconds), this a non-issue issue on preemptible kernels though as
>>>> the kernel may deschedule such long running tasks. Xen for instance
>>>> supports multicalls to be preempted as well, this is what Xen calls
>>>> continuation (see xen commit 42217cbc5b which introduced this [0]).
>>>> On systems without CONFIG_PREEMPT though -- a kernel with voluntary
>>>> or no preemption -- a long running hypercall will not be descheduled
>>>> until the hypercall is complete and the ioctl returns to user space.
>>>>
>>>> To help with this David had originally implemented support for use
>>>> of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
>>>> solution never went upstream though and upon review to help refactor
>>>> this I've concluded that usage of preempt_schedule_irq() would be
>>>> a bit abussive of existing APIs -- for a few reasons:
>>>>
>>>> 0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels
>>>>
>>>> 1) we want try to consider solutions that might work for other
>>>>      hypervisors for this same problem, and identify it its an issue
>>>>      even present on other hypervisors or if this is a self
>>>>      inflicted architectural issue caused by use of multicalls
>>>>
>>>> 2) there is no documentation or profiling of the exact hypercalls
>>>>      that were causing these issues, nor do we have any context
>>>>      to help evaluate this any further
>>>>
>>>> I at least checked with kvm folks and it seems hypercall preemption
>>>> is not needed there. We can survey other hypervisors...
>>>>
>>>> If 'something like preemption' is needed then CONFIG_PREEMPT
>>>> should just be enabled and encouraged, it seems we want to
>>>> encourage CONFIG_PREEMPT on xen, specially when multicalls are
>>>> used. In the meantime this tries to address a solution to help
>>>> xen on non CONFIG_PREEMPT kernels.
>>>>
>>>> One option tested and evaluated was to put private hypercalls in
>>>> process context, however this would introduce complexities such
>>>> originating hypercalls from different contexts. Current xen
>>>> hypercall callback handlers would need to be changed per architecture,
>>>> for instance, we'd also incur the cost of switching states from
>>>> user / kernel (this cost is also present if preempt_schedule_irq()
>>>> is used). There may be other issues which could be introduced with
>>>> this strategy as well. The simplest *shared* alternative is instead
>>>> to just explicitly schedule() at the end of a private hypercall on non
>>>> preempt kernels. This forces our private hypercall call mechanism
>>>> to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
>>>> more context switch but keeps the private hypercall context intact.
>>>>
>>>> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
>>>> [1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
>>>>
>>>> Cc: Davidlohr Bueso <dbueso@suse.de>
>>>> Cc: Joerg Roedel <jroedel@suse.de>
>>>> Cc: Borislav Petkov <bp@suse.de>
>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>> Cc: Jan Beulich <JBeulich@suse.com>
>>>> Cc: Juergen Gross <JGross@suse.com>
>>>> Cc: Olaf Hering <ohering@suse.de>
>>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>>> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
>>>> ---
>>>>    drivers/xen/privcmd.c | 3 +++
>>>>    1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>>> index 569a13b..e29edba 100644
>>>> --- a/drivers/xen/privcmd.c
>>>> +++ b/drivers/xen/privcmd.c
>>>> @@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
>>>>    			   hypercall.arg[0], hypercall.arg[1],
>>>>    			   hypercall.arg[2], hypercall.arg[3],
>>>>    			   hypercall.arg[4]);
>>>> +#ifndef CONFIG_PREEMPT
>>>> +	schedule();
>>>> +#endif
>>>>
>>>>    	return ret;
>>>>    }
>>>>
>>> Sorry, I don't think this will solve anything. You're calling schedule()
>>> right after the long running hypercall just nanoseconds before returning
>>> to the user.
>> Yeah, well that is what [1] tried as well only it tried using
>> preempt_schedule_irq() on the hypercall callback...
>>
>>> I suppose you were mislead by the "int 0x82" in [0]. This is the
>>> hypercall from the kernel into the hypervisor, e.g. inside of
>>> privcmd_call().
>> Nope, you have to consider what was done in [1], I was trying to
>> do something similar but less complex that didn't involve mucking
>> with the callbacks but also not abusing APIs.
>>
>> I'm afraid we don't have much leg room.
>
> XenServer uses
>
> https://github.com/xenserver/linux-3.x.pg/blob/master/master/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
>
> to deal with these issues.  That patch is based on 3.10.

Clever. :-)

>
> I can remember whether this has been submitted upstream before (and
> there were outstanding issues), or whether it fell at an inconvenient
> time with our development cycles.

I found

http://lists.xen.org/archives/html/xen-devel/2014-02/msg02540.html

and nothing else.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 05:56:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 05: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 1XuEWy-0000vf-PO; Fri, 28 Nov 2014 05:55:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XuEWx-0000va-QE
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 05:55:47 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C9/30-02957-36E08745; Fri, 28 Nov 2014 05:55:47 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417154144!15394726!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3130 invoked from network); 28 Nov 2014 05:55:46 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 05:55:46 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Thu, 27 Nov 2014 22:55:32 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 13:55:22 +0800
Message-Id: <1417154122-23669-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: Chunyan Liu <cyliu@suse.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] missing chunk of HVM direct kernel boot 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Found by Stefano, this chunk of the patch was never applied to
xen-unstable (commit 11dffa2359e8a2629490c14c029c7c7c777b3e47),
see http://marc.info/?l=qemu-devel&m=140471493425353&w=2.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 tools/libxl/libxl_dm.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..b25b574 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -527,6 +527,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_nics = 0;
 
+        if (b_info->kernel)
+            flexarray_vappend(dm_args, "-kernel", b_info->kernel, NULL);
+
+        if (b_info->ramdisk)
+            flexarray_vappend(dm_args, "-initrd", b_info->ramdisk, NULL);
+
+        if (b_info->cmdline)
+            flexarray_vappend(dm_args, "-append", b_info->cmdline, NULL);
+
         if (b_info->u.hvm.serial || b_info->u.hvm.serial_list) {
             if ( b_info->u.hvm.serial && b_info->u.hvm.serial_list )
             {
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 05:56:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 05: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 1XuEWy-0000vf-PO; Fri, 28 Nov 2014 05:55:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XuEWx-0000va-QE
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 05:55:47 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C9/30-02957-36E08745; Fri, 28 Nov 2014 05:55:47 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417154144!15394726!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3130 invoked from network); 28 Nov 2014 05:55:46 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 05:55:46 -0000
Received: from linux-tt8j.lab.bej.apac.novell.com
	(prv-ext-foundry1int.gns.novell.com [137.65.251.240])
	by prv3-mh.provo.novell.com with ESMTP (TLS encrypted);
	Thu, 27 Nov 2014 22:55:32 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 13:55:22 +0800
Message-Id: <1417154122-23669-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: Chunyan Liu <cyliu@suse.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] missing chunk of HVM direct kernel boot 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Found by Stefano, this chunk of the patch was never applied to
xen-unstable (commit 11dffa2359e8a2629490c14c029c7c7c777b3e47),
see http://marc.info/?l=qemu-devel&m=140471493425353&w=2.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 tools/libxl/libxl_dm.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..b25b574 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -527,6 +527,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_nics = 0;
 
+        if (b_info->kernel)
+            flexarray_vappend(dm_args, "-kernel", b_info->kernel, NULL);
+
+        if (b_info->ramdisk)
+            flexarray_vappend(dm_args, "-initrd", b_info->ramdisk, NULL);
+
+        if (b_info->cmdline)
+            flexarray_vappend(dm_args, "-append", b_info->cmdline, NULL);
+
         if (b_info->u.hvm.serial || b_info->u.hvm.serial_list) {
             if ( b_info->u.hvm.serial && b_info->u.hvm.serial_list )
             {
-- 
1.8.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 06:03:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 06:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuEek-0001M8-OL; Fri, 28 Nov 2014 06:03:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XuEej-0001M2-Ec
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 06:03:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3C/7D-09842-44018745; Fri, 28 Nov 2014 06:03:48 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417154626!11973026!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22980 invoked from network); 28 Nov 2014 06:03:48 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 06:03:48 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 23:03:46 -0700
Message-Id: <5478AAEE0200006600040C4B@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 23:03:42 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <1404714875-24362-1-git-send-email-cyliu@suse.com>
	<1404714875-24362-2-git-send-email-cyliu@suse.com>
	<alpine.DEB.2.02.1411271809430.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411271809430.14135@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian.Jackson@eu.citrix.com, qemu-devel@nongnu.org, Anthony.Perard@citrix.com
Subject: Re: [Xen-devel] [for 4.5] missing chunk in
 11dffa2359e8a2629490c14c029c7c7c777b3e47
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 11/28/2014 at 02:14 AM, in message
<alpine.DEB.2.02.1411271809430.14135@kaball.uk.xensource.com>, Stefano
Stabellini <stefano.stabellini@eu.citrix.com> wrote: 
> On Mon, 7 Jul 2014, Chunyan Liu wrote: 
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c 
> > index addacdb..4f1cbd2 100644 
> > --- a/tools/libxl/libxl_dm.c 
> > +++ b/tools/libxl/libxl_dm.c 
> > @@ -479,6 +485,15 @@ static char **  
> libxl__build_device_model_args_new(libxl__gc *gc, 
> >      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) { 
> >          int ioemu_nics = 0; 
> >   
> > +        if (b_info->kernel) 
> > +            flexarray_vappend(dm_args, "-kernel", b_info->kernel, NULL); 
> > + 
> > +        if (b_info->ramdisk) 
> > +            flexarray_vappend(dm_args, "-initrd", b_info->ramdisk, NULL); 
> > + 
> > +        if (b_info->cmdline) 
> > +            flexarray_vappend(dm_args, "-append", b_info->cmdline, NULL); 
> > + 
> >          if (b_info->u.hvm.serial) { 
> >              flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial,  
> NULL); 
> >          } 
>  
> This chunk of the patch was never applied to xen-unstable (commit 
> 11dffa2359e8a2629490c14c029c7c7c777b3e47), see 
> http://marc.info/?l=qemu-devel&m=140471493425353&w=2. 
> The feature is broken at the moment. 
>  

Thanks very much. Didn't notice that. Resend the missing part of patch.

>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 06:03:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 06:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuEek-0001M8-OL; Fri, 28 Nov 2014 06:03:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1XuEej-0001M2-Ec
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 06:03:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3C/7D-09842-44018745; Fri, 28 Nov 2014 06:03:48 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417154626!11973026!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22980 invoked from network); 28 Nov 2014 06:03:48 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 06:03:48 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Thu, 27 Nov 2014 23:03:46 -0700
Message-Id: <5478AAEE0200006600040C4B@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 27 Nov 2014 23:03:42 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <1404714875-24362-1-git-send-email-cyliu@suse.com>
	<1404714875-24362-2-git-send-email-cyliu@suse.com>
	<alpine.DEB.2.02.1411271809430.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411271809430.14135@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian.Jackson@eu.citrix.com, qemu-devel@nongnu.org, Anthony.Perard@citrix.com
Subject: Re: [Xen-devel] [for 4.5] missing chunk in
 11dffa2359e8a2629490c14c029c7c7c777b3e47
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 11/28/2014 at 02:14 AM, in message
<alpine.DEB.2.02.1411271809430.14135@kaball.uk.xensource.com>, Stefano
Stabellini <stefano.stabellini@eu.citrix.com> wrote: 
> On Mon, 7 Jul 2014, Chunyan Liu wrote: 
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c 
> > index addacdb..4f1cbd2 100644 
> > --- a/tools/libxl/libxl_dm.c 
> > +++ b/tools/libxl/libxl_dm.c 
> > @@ -479,6 +485,15 @@ static char **  
> libxl__build_device_model_args_new(libxl__gc *gc, 
> >      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) { 
> >          int ioemu_nics = 0; 
> >   
> > +        if (b_info->kernel) 
> > +            flexarray_vappend(dm_args, "-kernel", b_info->kernel, NULL); 
> > + 
> > +        if (b_info->ramdisk) 
> > +            flexarray_vappend(dm_args, "-initrd", b_info->ramdisk, NULL); 
> > + 
> > +        if (b_info->cmdline) 
> > +            flexarray_vappend(dm_args, "-append", b_info->cmdline, NULL); 
> > + 
> >          if (b_info->u.hvm.serial) { 
> >              flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial,  
> NULL); 
> >          } 
>  
> This chunk of the patch was never applied to xen-unstable (commit 
> 11dffa2359e8a2629490c14c029c7c7c777b3e47), see 
> http://marc.info/?l=qemu-devel&m=140471493425353&w=2. 
> The feature is broken at the moment. 
>  

Thanks very much. Didn't notice that. Resend the missing part of patch.

>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 06:43:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 06:43:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuFGu-0002Uu-98; Fri, 28 Nov 2014 06:43:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuFGs-0002Up-O3
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 06:43:14 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	4F/59-01660-18918745; Fri, 28 Nov 2014 06:43:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417156991!9662374!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25771 invoked from network); 28 Nov 2014 06:43:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 06:43:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,474,1413244800"; d="scan'208";a="197629176"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 01:43:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuFGn-0005q6-L4;
	Fri, 28 Nov 2014 06:43:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuFGn-0003GC-EW;
	Fri, 28 Nov 2014 06:43:09 +0000
Date: Fri, 28 Nov 2014 06:43:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31883-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31883: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31883 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31883/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 31811
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31811
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 31811
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 31811

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a
baseline version:
 xen                  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 host-install(3)

Not pushing.

------------------------------------------------------------
commit e0921ec746410f0a07eb3767e95e5eda25d4934a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:15:27 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 5e687e7da367827344db3965b8a5f5f761a8431a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:14:15 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 06:43:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 06:43:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuFGu-0002Uu-98; Fri, 28 Nov 2014 06:43:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuFGs-0002Up-O3
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 06:43:14 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	4F/59-01660-18918745; Fri, 28 Nov 2014 06:43:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417156991!9662374!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25771 invoked from network); 28 Nov 2014 06:43:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 06:43:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,474,1413244800"; d="scan'208";a="197629176"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 01:43:10 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuFGn-0005q6-L4;
	Fri, 28 Nov 2014 06:43:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuFGn-0003GC-EW;
	Fri, 28 Nov 2014 06:43:09 +0000
Date: Fri, 28 Nov 2014 06:43:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31883-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31883: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31883 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31883/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 31811
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31811
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 31811
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 31811

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a
baseline version:
 xen                  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 host-install(3)

Not pushing.

------------------------------------------------------------
commit e0921ec746410f0a07eb3767e95e5eda25d4934a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:15:27 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 5e687e7da367827344db3965b8a5f5f761a8431a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:14:15 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 07:46:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 07:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGFM-0004N6-2i; Fri, 28 Nov 2014 07:45:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XuGFK-0004Mz-NW
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 07:45:42 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	A1/D2-19763-52828745; Fri, 28 Nov 2014 07:45:41 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417160740!13811894!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32253 invoked from network); 28 Nov 2014 07:45:41 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-206.messagelabs.com with SMTP;
	28 Nov 2014 07:45:41 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 23:45:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="615347952"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 23:45:37 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:45:23 +0800
Message-Id: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	robert.hu@intel.com, longtaox.pang@intel.com, di.zheng@intel.com
Subject: [Xen-devel] [OSSTEST PATCH 0/4] Introduction of the patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 updated these patchs about adding Nested test job into OSSTest.
Nested virtualization is the function of running a hypervisor inside a virtual machine.
The hypervisor that runs on the real hardware is called a level 0 or L0; 
The hypervisor that runs as a guest inside L0 is called level 1 or L1; 
A guest that running inside the L1 hypervisor is called a level 2 or L2.

For running nested test job, we should run build-amd64 job and build-amd64-hvm job first. 
During the testing, it will install L1 guest VM inside L0, 
the L1 guest should build xen and HVM Dom0 kernel and then boot into xen kernel. 
Next, begin to install L2 guest VM inside L1. 
After that, make sure ping L2 is successfully

----------------------------------------------------------------
root (4):
      Add nested testcase of preparing and installing L1 guest
      Building XEN and HVM Dom0 kernel for L1 guest VM
      Add nested test case of installing L2 guest VM
      Insert nested test job name and runvars into standalone database

 Osstest/Debian.pm                 |   25 ++-
 Osstest/TestSupport.pm            |   31 +++-
 make-flight                       |   19 ++
 mfi-common                        |    8 +
 sg-run-job                        |    8 +
 ts-debian-install                 |  166 +++++++++++++----
 ts-nested-L1-debian-install-part1 |  202 ++++++++++++++++++++
 ts-nested-L1-debian-install-part2 |  364 +++++++++++++++++++++++++++++++++++++
 8 files changed, 773 insertions(+), 50 deletions(-)
 create mode 100755 ts-nested-L1-debian-install-part1
 create mode 100755 ts-nested-L1-debian-install-part2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 07:46:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 07:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGFS-0004OV-QU; Fri, 28 Nov 2014 07:45:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XuGFQ-0004Nx-PP
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 07:45:48 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	05/1E-02953-C2828745; Fri, 28 Nov 2014 07:45:48 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417160746!15432851!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29944 invoked from network); 28 Nov 2014 07:45:47 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-27.messagelabs.com with SMTP;
	28 Nov 2014 07:45:47 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 23:45:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="615347983"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 23:45:44 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:45:27 +0800
Message-Id: <1417160727-3100-5-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	robert.hu@intel.com, longtaox.pang@intel.com, di.zheng@intel.com
Subject: [Xen-devel] [OSSTEST PATCH 4/4] Insert nested test job name and
	runvars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "longtao.pang" <longtaox.pang@intel.com>

This patch is used for inserting nested test job name and runvars into 
standalone.db database after execute command './standalone-reset'.

---
 make-flight |   19 +++++++++++++++++++
 mfi-common  |    8 ++++++++
 2 files changed, 27 insertions(+)

diff --git a/make-flight b/make-flight
index 9963a46..fe64237 100755
--- a/make-flight
+++ b/make-flight
@@ -197,6 +197,24 @@ do_hvm_win7_x64_tests () {
             all_hostflags=$most_hostflags,hvm
 }
 
+do_hvm_debian_nested_tests () {
+  if [ $xenarch != amd64 ]; then
+    return
+  fi
+  if [ $dom0arch != amd64 ]; then
+    return
+  fi
+
+  job_create_test test-$xenarch$kern-$dom0arch-nested test-nested xl \
+           $xenarch $dom0arch \
+            nested_image=debian-7.6.0-amd64-DVD-1.iso \
+           bios=seabios \
+           kernbuildjob=build-amd64-hvm \
+           kernkind=hvm \
+           device_model_version=qemu-xen \
+            all_hostflags=$most_hostflags,hvm
+}
+
 do_hvm_debian_test_one () {
   testname=$1
   bios=$2
@@ -364,6 +382,7 @@ test_matrix_do_one () {
 
   fi
 
+  do_hvm_debian_nested_tests
   do_passthrough_tests
 }
 
diff --git a/mfi-common b/mfi-common
index 5c4f5d5..0cc0101 100644
--- a/mfi-common
+++ b/mfi-common
@@ -166,6 +166,14 @@ create_build_jobs () {
                 revision_qemu=$REVISION_QEMU                                 \
                 revision_qemuu=$REVISION_QEMU_UPSTREAM
     fi
+    ./cs-job-create $flight build-$arch-hvm build-kern                       \
+                arch=$arch kconfighow=xen-enable-xen-config                  \
+                $RUNVARS $BUILD_RUNVARS $BUILD_LINUX_RUNVARS $arch_runvars   \
+                $suite_runvars                                               \
+                host_hostflags=$build_hostflags                              \
+                revision_linux=HEAD                                          \
+                tree_linux=git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git                                                             \
+                ${TREEVCS_LINUX:+treevcs_linux=}${TREEVCS_LINUX}
 
     ./cs-job-create $flight build-$arch-pvops build-kern                     \
                 arch=$arch kconfighow=xen-enable-xen-config                  \
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 07:46:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 07:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGFP-0004Nd-QZ; Fri, 28 Nov 2014 07:45:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XuGFN-0004NE-Kw
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 07:45:45 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	D8/7D-02707-82828745; Fri, 28 Nov 2014 07:45:44 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417160740!13811894!2
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 920 invoked from network); 28 Nov 2014 07:45:42 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-206.messagelabs.com with SMTP;
	28 Nov 2014 07:45:42 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 23:45:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="615347959"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 23:45:39 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:45:24 +0800
Message-Id: <1417160727-3100-2-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	robert.hu@intel.com, longtaox.pang@intel.com, di.zheng@intel.com
Subject: [Xen-devel] [OSSTEST PATCH 1/4] Add nested testcase of preparing
	and installing L1 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "longtao.pang" <longtaox.pang@intel.com>

This patch is used for preparing and installing L1 guest VM inside L0 system 
on testhost machine.

---
 Osstest/Debian.pm                 |   25 +++--
 Osstest/TestSupport.pm            |   31 +++++-
 sg-run-job                        |    5 +
 ts-nested-L1-debian-install-part1 |  202 +++++++++++++++++++++++++++++++++++++
 4 files changed, 249 insertions(+), 14 deletions(-)
 create mode 100755 ts-nested-L1-debian-install-part1

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8f80eb4..68da2cb 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1,5 +1,6 @@
 # This is part of "osstest", an automated testing framework for Xen.
 # Copyright (C) 2009-2013 Citrix Inc.
+# Copyright (C) 2014 Intel Inc.
 # 
 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU Affero General Public License as published by
@@ -286,15 +287,18 @@ sub setupboot_grub2 ($$$) {
     
         my $count= 0;
         my $entry;
+	my $submenu;
         while (<$f>) {
             next if m/^\s*\#/ || !m/\S/;
             if (m/^\s*\}\s*$/) {
-                die unless $entry;
+                die unless $entry || $submenu;
+	    	if(!defined $entry && defined $submenu){
+		  logm("Met end of a submenu starting from $submenu->{StartLine}.Our want kern is $want_kernver");
+		  $submenu=undef;
+		  next;
+		}
                 my (@missing) =
-                    grep { !defined $entry->{$_} } 
-		        (defined $xenhopt
-			 ? qw(Title Hv KernDom0 KernVer)
-			 : qw(Title Hv KernOnly KernVer));
+		grep { !defined $entry->{$_} }  (defined $xenhopt ? qw(Title Hv KernDom0 KernVer) : qw(Title Hv KernOnly KernVer));
 		if (@missing) {
 		    logm("(skipping entry at $entry->{StartLine};".
 			 " no @missing)");
@@ -317,21 +321,24 @@ sub setupboot_grub2 ($$$) {
                 $entry= { Title => $1, StartLine => $., Number => $count };
                 $count++;
             }
-            if (m/^\s*multiboot\s*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
+	    if(m/^submenu\s+[\'\"](.*)[\'\"].*\{\s*$/){
+		$submenu={ StartLine =>$.};
+	    }
+	    if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
                 die unless $entry;
                 $entry->{Hv}= $1;
             }
-            if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
+	    if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
                 die unless $entry;
                 $entry->{KernOnly}= $1;
                 $entry->{KernVer}= $2;
             }
-            if (m/^\s*module\s*\/(vmlinu[xz]-(\S+))/) {
+	    if (m/^\s*module\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
                 die unless $entry;
                 $entry->{KernDom0}= $1;
                 $entry->{KernVer}= $2;
             }
-            if (m/^\s*module\s*\/(initrd\S+)/) {
+	    if (m/^\s*module\s*(?:\/boot)*\/(initrd\S+)/) {
                 $entry->{Initrd}= $1;
             }
         }
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 45ceee9..21955b8 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -55,8 +55,9 @@ BEGIN {
                       target_putfilecontents_stash
 		      target_putfilecontents_root_stash
                       target_put_guest_image target_editfile
-                      target_editfile_root target_file_exists
-                      target_run_apt
+		      target_editfile_root target_file_exists 
+		      target_file_exists_root
+		      target_run_apt
                       target_install_packages target_install_packages_norec
                       target_jobdir target_extract_jobdistpath_subdir
                       target_extract_jobdistpath target_guest_lv_name
@@ -67,7 +68,7 @@ BEGIN {
                       selecthost get_hostflags get_host_property
                       get_host_native_linux_console
                       power_state power_cycle power_cycle_time
-                      serial_fetch_logs
+                      serial_fetch_logs select_ether
                       propname_massage
          
                       get_stashed open_unique_stashfile compress_stashed
@@ -109,6 +110,7 @@ BEGIN {
                       iso_gen_flags_basic
                       iso_copy_content_from_image
                       guest_editconfig_nocd
+		      guest_editconfig_cd
                       );
     %EXPORT_TAGS = ( );
 
@@ -481,6 +483,14 @@ sub target_file_exists ($$) {
     die "$rfile $out ?";
 }
 
+sub target_file_exists_root ($$) {
+    my ($ho,$rfile) = @_;
+    my $out= target_cmd_output_root($ho, "if test -e $rfile; then echo y; fi");
+    return 1 if $out =~ m/^y$/;
+    return 0 if $out !~ m/\S/;
+    die "$rfile $out ?";
+}
+
 sub teditfileex {
     my $user= shift @_;
     my $code= pop @_;
@@ -716,6 +726,7 @@ sub power_cycle_time ($) {
 sub power_cycle ($) {
     my ($ho) = @_;
     $mjobdb->host_check_allocated($ho);
+    $mjobdb->xen_check_installed($ho);
     die "refusing to set power state for host $ho->{Name}".
 	" possibly shared with other jobs\n"
 	if $ho->{SharedMaybeOthers};
@@ -921,7 +932,7 @@ sub compress_stashed($) {
 sub host_reboot ($) {
     my ($ho) = @_;
     target_reboot($ho);
-    poll_loop(40,2, 'reboot-confirm-booted', sub {
+    poll_loop(200,2, 'reboot-confirm-booted', sub {
         my $output;
         if (!eval {
             $output= target_cmd_output($ho, <<END, 40);
@@ -1449,7 +1460,7 @@ sub prepareguest_part_xencfg ($$$$$) {
     my $xencfg= <<END;
 name        = '$gho->{Name}'
 memory = ${ram_mb}
-vif         = [ 'type=ioemu,mac=$gho->{Ether}' ]
+vif         = [ 'type=ioemu,model=e1000,mac=$gho->{Ether}' ]
 #
 on_poweroff = 'destroy'
 on_reboot   = '$onreboot'
@@ -2047,4 +2058,14 @@ sub guest_editconfig_nocd ($$) {
     });
 }
 
+sub guest_editconfig_cd ($) {
+    my ($gho) = @_;
+    guest_editconfig($gho->{Host}, $gho, sub {
+        if (m/^\s*boot\s*= '\s*d\s*c\s*'/) {
+            s/dc/cd/;
+        }
+        s/^on_reboot.*/on_reboot='restart'/;
+    });
+}
+
 1;
diff --git a/sg-run-job b/sg-run-job
index 2cf810a..cd8b468 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -288,6 +288,11 @@ proc run-job/test-pair {} {
 #    run-ts . remus-failover ts-remus-check         src_host dst_host + debian
 }
 
+proc need-hosts/test-nested {} {return host}
+proc run-job/test-nested {} {
+    run-ts . = ts-nested-L1-debian-install-part1
+}
+
 proc test-guest-migr {g} {
     if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
 
diff --git a/ts-nested-L1-debian-install-part1 b/ts-nested-L1-debian-install-part1
new file mode 100755
index 0000000..9649b76
--- /dev/null
+++ b/ts-nested-L1-debian-install-part1
@@ -0,0 +1,202 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 Citrix Inc.
+# Copyright (C) 2014 Intel Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::Debian;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our $stage=0;
+if (@ARGV && $ARGV[0] =~ m/^--stage(\d+)$/) { $stage=$1; shift @ARGV; }
+
+defined($r{bios}) or die "Need to define which bios to use";
+
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+$gn ||= 'nested';
+
+our $ho= selecthost($whhost);
+
+# guest memory size will be set based on host free memory, see below
+our $ram_mb;
+our $disk_mb= 100000;
+
+our $guesthost= "$gn.l1.osstest";
+our $gho;
+
+our $toolstack= toolstack()->{Command};
+
+
+sub preseed () {
+
+    my $preseed_file = preseed_base('wheezy','',());
+    my $authkeys = join('\\n', split(/\n/, authorized_keys()));
+
+    $preseed_file .= (<<END);
+d-i netcfg/get_hostname string $gn
+
+d-i partman-auto/disk string /dev/xvda
+d-i partman-auto/method string  regular
+
+d-i partman-auto/expert_recipe string \\
+        boot-root :: \\
+                512 50 512 vfat \\
+                        \$primary{ } \$bootable{ } \\
+                        method{ efi } format{ } \\
+                        use_filesystem{ } filesystem{ vfat } \\
+                        mountpoint{ /boot/efi } \\
+                . \\
+                95000 50 95000 ext4 \\
+                        method{ format } format{ } \\
+                        use_filesystem{ } filesystem{ ext4 } \\
+                        mountpoint{ / } \\
+                . \\
+                512 30 100% linux-swap \\
+                        method{ swap } format{ } \\
+                .
+
+d-i apt-setup/cdrom/set-first boolean false
+
+d-i preseed/late_command string \\
+        in-target mkdir -p /boot/efi/EFI/boot; \\
+        in-target cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx64.efi ;\\
+        in-target mkdir -p /root/.ssh; \\
+        in-target sh -c "echo -e '$authkeys'> /root/.ssh/authorized_keys";
+END
+    return $preseed_file;
+}
+
+sub grub_cfg () {
+
+    return <<"END";
+set default="0"
+set timeout=5
+
+menuentry 'debian guest auto Install' {
+    linux /install.amd/vmlinuz console=vga console=ttyS0,115200n8 preseed/file=/preseed.cfg
+    initrd /install.amd/initrd.gz
+}
+END
+}
+
+sub isolinux_cfg () {
+    return <<"END";
+    default autoinstall
+    prompt 0
+    timeout 0
+
+    label autoinstall
+        kernel /install.amd/vmlinuz
+        append video=vesa:ywrap,mtrr vga=788 console=ttyS0,115200n8 preseed/file=/preseed.cfg initrd=/install.amd/initrd.gz
+END
+}
+
+sub prepare_initrd ($$$) {
+    my ($initrddir,$newiso,$preseed_file_path) = @_;
+    return <<"END";
+      rm -rf $initrddir
+      mkdir $initrddir
+      cd $initrddir
+      gzip -d < $newiso/install.amd/initrd.gz | cpio --extract --make-directories --no-absolute-filename
+      cp $preseed_file_path preseed.cfg
+      find . | cpio -H newc --create | gzip -9 > $newiso/install.amd/initrd.gz
+      cd -
+      rm -rf $initrddir
+      cd $newiso
+      md5sum `find -L -type f -print0 | xargs -0` > md5sum.txt
+      cd -
+END
+}
+
+our $emptyiso= "/root/$flight.$job.$gn-empty.iso";
+
+sub prep () {
+    target_install_packages_norec($ho, qw(lvm2 rsync genisoimage ethtool));
+
+    my $isotimeout= 600;
+
+    $gho= prepareguest($ho, $gn, $guesthost, 22,
+                       $disk_mb + 1,
+                       200);
+    my $base = "/root/$flight.$job.$gn-";
+    my $newiso= $base . "newiso";
+    my $emptydir= $base . "empty-dir";
+    my $initrddir= $base . "initrd-dir";
+    my $preseed_file_path = $base . "preseed";
+
+    my @isogen_extra = qw(-eltorito-alt-boot
+                          -b boot/grub/efi.img
+                          -no-emul-boot
+                          -r);
+    my @isogen_opts = (iso_gen_flags_basic(), @isogen_extra);
+
+    iso_create_empty($ho, $emptyiso, $emptydir);
+
+    target_putfilecontents_root_stash($ho, 10, preseed(),
+                                      $preseed_file_path);
+
+    more_prepareguest_hvm($ho,$gho, $ram_mb, $disk_mb,
+                          OnReboot => 'preserve',
+                          Bios => $r{bios},
+  			  DefVcpus => 4,
+  			  ExtraConfig => '#nestedhvm=1',
+                          PostImageHook => sub {
+        my $cmds = iso_copy_content_from_image($gho, $newiso);
+        $cmds .= prepare_initrd($initrddir,$newiso,$preseed_file_path);
+        target_cmd_root($ho, $cmds, $isotimeout);
+        target_putfilecontents_root_stash($ho, 10, grub_cfg(),
+                                          "$newiso/debian/boot/grub/grub.cfg");
+
+        target_putfilecontents_root_stash($ho, 10, isolinux_cfg(),
+                                          "$newiso/isolinux/isolinux.cfg");
+
+        iso_create_genisoimage($ho, $gho->{Rimage}, $newiso, $isotimeout, @isogen_opts);
+    });
+}
+
+# If host has >8G free memory, create a guest with 4G memory to catch
+# any error that triggers cross 4G boundary
+my $host_freemem_mb = host_get_free_memory($ho, $toolstack);
+my $ram_minslop = 100;
+my $ram_lots = 5000;
+if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
+    $ram_mb = $ram_lots;
+} else {
+    $ram_mb = 2048;
+}
+logm("Host has $host_freemem_mb MB free memory, setting guest memory size to $ram_mb MB");
+
+if (!$stage) {
+    prep();
+    guest_create($gho,$toolstack);
+} else {
+    $gho= selectguest($gn,$gho);
+}
+if ($stage<2) {
+    guest_await_reboot($ho,$gho,2000);
+    guest_destroy($ho,$gho);
+}
+
+guest_editconfig_cd($gho);
+guest_create($gho,$toolstack);
+guest_await_dhcp_tcp($gho,300);
+guest_check_up($gho);
+target_cmd_root($gho, "mkdir -p /home/osstest/.ssh && cp /root/.ssh/authorized_keys /home/osstest/.ssh/");
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 07:46:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 07:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGFO-0004NN-EW; Fri, 28 Nov 2014 07:45:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XuGFN-0004ND-6T
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 07:45:45 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	7D/95-02954-82828745; Fri, 28 Nov 2014 07:45:44 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417160741!15417748!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8695 invoked from network); 28 Nov 2014 07:45:43 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-27.messagelabs.com with SMTP;
	28 Nov 2014 07:45:43 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 23:45:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="615347969"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 23:45:41 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:45:25 +0800
Message-Id: <1417160727-3100-3-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	robert.hu@intel.com, longtaox.pang@intel.com, di.zheng@intel.com
Subject: [Xen-devel] [OSSTEST PATCH 2/4] Building XEN and HVM Dom0 kernel
	for L1 guest VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "longtao.pang" <longtaox.pang@intel.com>

This patch is used for building XEN and HVM Dom0 kernel for L1 guest VM, 
and then reboot L1 guest into xen kernel.

---
 sg-run-job                        |    1 +
 ts-nested-L1-debian-install-part2 |  364 +++++++++++++++++++++++++++++++++++++
 2 files changed, 365 insertions(+)
 create mode 100755 ts-nested-L1-debian-install-part2

diff --git a/sg-run-job b/sg-run-job
index cd8b468..a4c0de1 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -291,6 +291,7 @@ proc run-job/test-pair {} {
 proc need-hosts/test-nested {} {return host}
 proc run-job/test-nested {} {
     run-ts . = ts-nested-L1-debian-install-part1
+    run-ts . = ts-nested-L1-debian-install-part2
 }
 
 proc test-guest-migr {g} {
diff --git a/ts-nested-L1-debian-install-part2 b/ts-nested-L1-debian-install-part2
new file mode 100755
index 0000000..2f52edc
--- /dev/null
+++ b/ts-nested-L1-debian-install-part2
@@ -0,0 +1,364 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 Citrix Inc.
+# Copyright (C) 2014 Intel Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::Debian;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost,$gn)= @ARGV;
+$whhost ||= 'host';
+$gn ||= 'nested';
+
+our $ho= selecthost($whhost);
+our $gho;
+our $nested_L2;
+
+my %distpath;
+sub guest_packages () {
+    target_install_packages($gho,
+                            qw(bridge-utils vncsnapshot libaio1 libpixman-1-0
+                               libsdl1.2debian libglib2.0-0 liblzma5 vim));
+    target_install_packages($gho,
+			    $ho->{Suite} =~ /squeeze/ ? "libyajl1" : "libyajl2");	#we always let L1 same as L0
+    if ($ho->{Suite} !~ m/lenny|squeeze/) {
+        target_install_packages($gho, 'libfdt1');
+    }
+    if ($r{arch} eq 'i386') {
+	target_install_packages($gho, 'libc6-xen');
+    }
+    target_install_packages($gho, @{toolstack()->{ExtraPackages}})
+        if toolstack()->{ExtraPackages};
+}
+
+sub guest_extract () {
+    my @parts = ('', 'kern', 'xen');
+    push @parts, 'libvirt' if $r{toolstack} eq "libvirt";
+
+    foreach my $part (@parts) {
+        target_extract_jobdistpath($gho, $part, "path_${part}dist",
+				   $r{"${part}buildjob"}, \%distpath);
+    }
+    target_cmd_root($gho, '/sbin/ldconfig');
+}
+
+sub guest_adjustconfig () {
+    target_editfile_root($gho, "/etc/xen/xend-config.sxp",
+			 "xend-config.sxp", sub {
+	my (@domains) = (qw(localhost localhost.localdomain),
+			 ".".$c{DnsDomain}, ".".$c{TestHostDomain});
+	logm("relocation domains: @domains");
+	foreach (@domains) {
+	    s/\./\\$&/g;
+	    s/^/^/g;
+	    s/$/\$/g;
+	    s/^\^(\\\.)/.\*$1/;
+	}
+	$_= join ' ', @domains;
+	s/[\'\\]/\\$&/g;
+	my $extra= "(xend-relocation-hosts-allow '$_')";
+	logm("relocation setting: $extra");
+	$extra .= "\n";
+        while (<EI>) {
+	    s/^\s*\(xend-relocation-hosts-allow/#$&/;
+	    print EO or die $!;
+	    if (m/^\#\(xend-relocation-hosts-allow/) {
+		print EO $extra or die $!;
+		$extra= '';
+	    }
+	}
+	print EO $extra or die $!;
+    }) if toolstack()->{Name} eq "xend";
+
+    my $trace_config_file;
+    foreach my $try (qw(/etc/default/xencommons
+                        /etc/sysconfig/xencommons
+                        /etc/default/xend
+                        /etc/sysconfig/xend)) {
+        next unless target_file_exists_root($gho, $try);
+        $trace_config_file= $try;
+        last;
+    }
+    die unless defined $trace_config_file;
+
+    target_editfile_root($gho, $trace_config_file, sub {
+        my $prnow;
+        $prnow= sub {
+            print EO "XENCONSOLED_TRACE=guest\n" or die $!;
+            $prnow= sub { };
+        };
+        while (<EI>) {
+            print EO or die $! unless m/^XENCONSOLED_TRACE/;
+            $prnow->() if m/^#XENCONSOLED_TRACE/;
+        }
+        print EO "\n" or die $!;
+        $prnow->();
+    });
+
+    target_cmd_root($gho, 'mkdir -p /var/log/xen/console');
+
+}
+
+=begin
+sub guest_setupboot () {
+    my $xenhopt= "conswitch=x watchdog";
+
+    my $cons= get_host_property($gho, 'XenSerialConsole', 'com1');
+
+    if ( $cons eq "com1" ) {
+	$xenhopt .= " com1=$c{Baud},8n1 console=com1,vga gdb=com1";
+    } elsif ( $cons eq "dtuart" ) {
+	$xenhopt .= " console=dtuart";
+	my $dtuart= get_host_property($gho, 'XenDTUARTPath', undef);
+	$xenhopt .= " dtuart=$dtuart" if $dtuart;
+    } else {
+	logm("No Xen console device defined for L1 Xen");
+    }
+    if (toolstack()->{Dom0MemFixed}) {
+        $xenhopt .= " dom0_mem=1G,max:1G";
+    }
+    my $append= $r{xen_boot_append};
+    $xenhopt .= " $append" if defined $append;
+    $append = get_host_property($gho, 'xen-commandline-append', undef);
+    $xenhopt .= " $append" if defined $append;
+    my @hooks;
+                host_get_pcipassthrough_devs($ho);
+                logm("pci passthrough: hiding in dom0: $hide");
+                $$kopt .= $hide;
+            }
+        };
+    }
+
+    my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
+    debian_boot_setup($gho, $want_kernver, $xenhopt, \%distpath);
+
+    logm("ready to boot L1 Xen");
+}
+=end
+=cut
+
+sub setupboot_L1_grub ($$$) {
+    my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
+    my $bl= { };
+    my $rmenu= '/boot/grub/grub.cfg';
+    my $kernkey= (defined $xenhopt ? 'KernDom0' : 'KernOnly');
+    my $parsemenu= sub {
+        my $f= bl_getmenu_open($ho, $rmenu, "$stash/$ho->{Name}--grub.cfg.1");
+    
+        my $count= 0;
+        my $entry;
+	my $submenu;
+        while (<$f>) {
+            next if m/^\s*\#/ || !m/\S/;
+            if (m/^\s*\}\s*$/) {
+                die unless $entry || $submenu;
+		if(!defined $entry && defined $submenu){
+		    logm("Met end of a submenu starting from $submenu->{StartLine}. Our want kern is $want_kernver");
+		    $submenu=undef;
+		    next;
+		}
+                my (@missing) =
+                    grep { !defined $entry->{$_} }  (defined $xenhopt ? qw(Title Hv KernDom0 KernVer) : qw(Title Hv KernOnly KernVer));
+		if (@missing) {
+		    logm("(skipping entry at $entry->{StartLine};".
+			 " no @missing)");
+		} elsif (defined $want_kernver &&
+			 $entry->{KernVer} ne $want_kernver) {
+		    logm("(skipping entry at $entry->{StartLine};".
+			 " kernel $entry->{KernVer}, not $want_kernver)");
+		} else {
+		    # yes!
+		    last;
+		}
+                $entry= undef;
+                next;
+            }
+            if (m/^function.*\{/) {
+                $entry= { StartLine => $. };
+            }
+            if (m/^menuentry\s+[\'\"](.*)[\'\"].*\{\s*$/) {
+                die $entry->{StartLine} if $entry;
+                $entry= { Title => $1, StartLine => $., Number => $count };
+                $count++;
+            }
+			if(m/^submenu\s+[\'\"](.*)[\'\"].*\{\s*$/){
+				$submenu={ StartLine =>$.};
+			}
+            if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\S+)/) {
+                die unless $entry;
+                $entry->{Hv}= $1;
+            }
+            if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
+                die unless $entry;
+                $entry->{KernOnly}= $1;
+                $entry->{KernVer}= $2;
+            }
+            if (m/^\s*module\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
+                die unless $entry;
+                $entry->{KernDom0}= $1;
+                $entry->{KernVer}= $2;
+            }
+            if (m/^\s*module\s*(?:\/boot)*\/(initrd\S+)/) {
+                $entry->{Initrd}= $1;
+            }
+        }
+        die 'grub 2 bootloader entry not found' unless $entry;
+
+        die unless $entry->{Title};
+
+        logm("boot check: grub2, found $entry->{Title}");
+
+	die unless $entry->{$kernkey};
+	if (defined $xenhopt) {
+	    die unless $entry->{Hv};
+	}
+
+        return $entry;
+    };
+
+
+    $bl->{UpdateConfig}= sub {
+	my ( $ho ) = @_;
+	target_cmd_root($ho, "update-grub");
+    };
+
+    $bl->{GetBootKern}= sub { return $parsemenu->()->{$kernkey}; };
+
+    $bl->{PreFinalUpdate}= sub {
+        my $entry= $parsemenu->();
+        
+        target_editfile_root($ho, '/etc/default/grub', sub {
+            my %k;
+            while (<::EI>) {
+                next if m/^GRUB_DEFAULT/;
+                print ::EO;
+            }
+            print ::EO <<END or die $!;
+
+GRUB_DEFAULT=$entry->{Number}
+END
+        });
+    };
+
+    return $bl;
+}
+
+our $initscripts_nobridge;
+sub guest_setupinitd () {
+    my $ts= toolstack();
+    my $xencommons= '/etc/init.d/xencommons';
+    my $have_xencommons=
+        !!target_cmd_output_root($gho, <<END);
+   if test -f $xencommons && ! grep 'FOR USE WITH LIBXL' $xencommons >/dev/null
+   then
+   echo y
+   fi
+END
+    $initscripts_nobridge= !defined($ts->{OldDaemonInitd}) || $have_xencommons;
+    logm("init.d scripts ".
+         ($initscripts_nobridge
+          ? 'do not mess with bridge, doing it in interfaces(5)'
+          : '_do_ mess with bridge, letting them handle it'));
+    my $cmd= '';
+    my $updatercd= sub {
+        my ($script,$start) = @_;
+        $cmd .= "\n    update-rc.d $script start $start 2 .";
+    };
+    if ($initscripts_nobridge) {
+        my $script= $have_xencommons ? 'xencommons' : 'xenlightdaemons';
+        $updatercd->($script,92);
+        my $pri= 93;
+        foreach my $d (@{ $ts->{NewDaemons} }) {
+            $updatercd->("$d",$pri);
+            $pri++;
+        }
+    } else {
+        my $initd= $ts->{OldDaemonInitd};
+        $updatercd->($initd,93) if defined $initd;
+        $updatercd->('xenbridge',38) if $ts->{OldSeparateBridgeInitd};
+    }
+    target_cmd_root($gho, $cmd);
+}
+
+sub bl_getmenu_open ($$$) {
+    my ($ho, $rmenu, $lmenu) = @_;
+    target_getfile($ho, 60, $rmenu, $lmenu);
+    my $f= new IO::File $lmenu, 'r' or die "$lmenu $?";
+    return $f;
+}
+
+sub setup_l1_bridge($)
+{
+    my ($ho)=@_;
+    my $bridge_port;
+    my $route_output=target_cmd_output_root($ho,"route -n");
+    foreach my $line (split /\n/, $route_output){
+        if($line =~ m/^\s*(?:(?:0\.0\.0\.0)|default).*\s(\w+)\s*$/ai){
+            $bridge_port=$1;
+            logm("get L1 bridge phy port $bridge_port");
+            last;
+        }
+    }
+        die "cannot find L1 port for xenbr0 bridge" if !defined $bridge_port;
+
+    target_editfile_root($ho, "/etc/network/interfaces",
+                         "etc-network-interfaces",
+                        sub {
+                            while(<EI>){
+                                s/^\s*iface\s*$bridge_port\s*inet.*dhcp\s*$/iface $bridge_port inet manual\nauto xenbr0\niface xenbr0 inet dhcp\n\tbridge_ports $bridge_port\n/;
+                                s/^\s*auto\s*$bridge_port/#auto\t$bridge_port/;
+                                print EO;
+                            }
+                         });
+    target_cmd_root($ho,"brctl addbr xenbr0; brctl addif xenbr0 $bridge_port; init 6");
+}
+
+
+$gho= selectguest($gn,$ho);
+store_runvar("$gho->{Guest}_kernkind",$r{'kernkind'});
+$gho->{Suite}=$ho->{Suite};
+
+guest_check_ip($gho);
+guest_packages();
+guest_extract();
+guest_adjustconfig();
+my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
+my $bootloader;
+$bootloader=setupboot_L1_grub($gho, $want_kernver, "");
+
+
+target_cmd_root($gho,
+                    "update-initramfs -k $want_kernver -c ||".
+                    " update-initramfs -k $want_kernver -u",
+                    200);
+$bootloader->{UpdateConfig}($gho); #so that /boot/grub/grub.cfg have new kernel and xen
+$bootloader->{PreFinalUpdate}();	#update /etc/default/grub, by setting default entry we want
+
+guest_setupinitd ();
+$bootloader->{UpdateConfig}($gho);	#use the default entry, apply it to /boot/grub/grub.cfg
+guest_editconfig($gho->{Host}, $gho, sub {
+        s/#nestedhvm/nestedhvm/;
+    });
+target_cmd_root($gho,"sync");
+setup_l1_bridge($gho);		#after setup L1 bridge, it will reboot for network settiings to take effect
+logm("ready to reboot L1 Xen");
+guest_await($gho, target_var($gho,'boot_timeout'));
+guest_check_up($gho);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 07:46:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 07:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGFQ-0004Ny-Ck; Fri, 28 Nov 2014 07:45:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XuGFP-0004NS-3y
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 07:45:47 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	3E/5D-02696-A2828745; Fri, 28 Nov 2014 07:45:46 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417160741!15417748!2
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8751 invoked from network); 28 Nov 2014 07:45:44 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-27.messagelabs.com with SMTP;
	28 Nov 2014 07:45:44 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 23:45:44 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="615347976"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 23:45:42 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:45:26 +0800
Message-Id: <1417160727-3100-4-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	robert.hu@intel.com, longtaox.pang@intel.com, di.zheng@intel.com
Subject: [Xen-devel] [OSSTEST PATCH 3/4] Add nested test case of installing
	L2 guest VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "longtao.pang" <longtaox.pang@intel.com>

This patch is used for installing L2 guest VM inside L1 guest VM.

---
 sg-run-job        |    2 +
 ts-debian-install |  166 +++++++++++++++++++++++++++++++++++++++++------------
 2 files changed, 132 insertions(+), 36 deletions(-)

diff --git a/sg-run-job b/sg-run-job
index a4c0de1..7c0c6ca 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -292,6 +292,8 @@ proc need-hosts/test-nested {} {return host}
 proc run-job/test-nested {} {
     run-ts . = ts-nested-L1-debian-install-part1
     run-ts . = ts-nested-L1-debian-install-part2
+    run-ts . = ts-debian-install + host + nested + amd64 + nested_L2
+    run-ts . = ts-guest-destroy + host nested
 }
 
 proc test-guest-migr {g} {
diff --git a/ts-debian-install b/ts-debian-install
index 58ea743..2ca54e8 100755
--- a/ts-debian-install
+++ b/ts-debian-install
@@ -22,41 +22,61 @@ use Osstest::TestSupport;
 
 tsreadconfig();
 
-our ($whhost,$gn) = @ARGV;
-$whhost ||= 'host';
-$gn ||= 'debian';
+our ($whhost,$gn,$arch,$nested_L2) = @ARGV;
+$nested_L2 ||= '';
 
-our $ho= selecthost($whhost);
+if($nested_L2 eq 'nested_L2') {
+    my $L1_IP = &get_VM_IP($r{'nested_ether'});
+    $whhost = "host=$L1_IP";
+    $gn ||= 'nested';
+    $arch ||= 'amd64';
+} else {
+    $whhost ||= 'host';
+    $gn ||= 'debian';	
+}
 
+our $ho= selecthost($whhost);
 our $ram_mb=    512;
 our $swap_mb=  1000;
 our $disk_mb= 10000;
-
 our $guesthost= "$gn.guest.osstest";
 our $gho;
+our $L2_MAC = select_ether($ho,"L2_ether");
 
 sub prep () {
     target_install_packages_norec($ho, qw(lvm2 xen-tools));
-
-    $gho= prepareguest($ho, $gn, $guesthost, 22,
-                       $swap_mb + $disk_mb + 2,
-                       40);
-    target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
+    unless($nested_L2 eq 'nested_L2') {
+	$gho= prepareguest($ho, $gn, $guesthost, 22,
+        	           $swap_mb + $disk_mb + 2,
+                	   40);
+	target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
+    }
 }
 
 sub ginstall () {
-    my $arch= $r{"$gho->{Guest}_arch"};
+    my $gsuite;
+    my $kernpath;
+    my $initrd;
+    my $kernver;
+    if($nested_L2 eq 'nested_L2'){
+        my $suite= "$c{DebianSuite}";
+        $gsuite= defined($suite) ? "--dist=$suite" : '';
+        $kernver ||= target_cmd_output_root($ho, 'uname -r');
+        $kernpath = "/boot/vmlinuz-$kernver";
+        $initrd ||= "/boot/initrd.img-$kernver";
+    } else {
+        my $arch= $r{"$gho->{Guest}_arch"};
+        $gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
+        $kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
+        $initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
+        if (!$kernpath) {
+	    $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
+            $kernver ||= target_cmd_output($ho, 'uname -r');
+	    $kernpath = "/boot/vmlinuz-$kernver";
+	    $initrd ||= "/boot/initrd.img-$kernver";
+        } 
+    } 
     my $archarg= defined($arch) ? "--arch $arch" : '';
-    my $gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
-
-    my $kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
-    my $initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
-    if (!$kernpath) {
-	my $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
-	$kernver ||= target_cmd_output($ho, 'uname -r');
-	$kernpath = "/boot/vmlinuz-$kernver";
-	$initrd ||= "/boot/initrd.img-$kernver";
-    }
     if (!$initrd) {
 	$initrd = $kernpath;
 	$initrd =~ s,/vmlinuz-,/initrd.img-, or die "$initrd ?";
@@ -76,23 +96,97 @@ sub ginstall () {
             fi
 END
     }
-    target_cmd_root($ho, <<END, 2000);
-        xen-create-image \\
-            --dhcp --mac $gho->{Ether} \\
-            --memory ${ram_mb}Mb --swap ${swap_mb}Mb \\
-            --dist $gsuite \\
-            --mirror http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
-            --hostname $gho->{Name} \\
-            --lvm $gho->{Vg} --force \\
-            --kernel $kernpath \\
-            --genpass 0 --password xenroot \\
-            $initrd_opt \\
-            $archarg
+    if($nested_L2 eq 'nested_L2') {
+        target_cmd_root($ho, <<END, 2000);
+            xen-create-image \\
+                --dhcp --mac=$L2_MAC \\
+                --size=${disk_mb}Mb --memory=${ram_mb}Mb --swap=${swap_mb}Mb \\
+                --mirror=http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
+                --hostname $guesthost \\
+                --dir=/testnested \\
+                --kernel=$kernpath \\
+                --genpass 0 --password xenroot \\
+                $initrd_opt \\
+                $gsuite \\
+                $archarg
+END
+    } else {
+        target_cmd_root($ho, <<END, 2000);
+            xen-create-image \\
+                --dhcp --mac $gho->{Ether} \\
+                --memory ${ram_mb}Mb --swap ${swap_mb}Mb \\
+                --dist $gsuite \\
+                --mirror http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
+                --hostname $gho->{Name} \\
+                --lvm $gho->{Vg} --force \\
+                --kernel $kernpath \\
+                --genpass 0 --password xenroot \\
+                $initrd_opt \\
+                $archarg
 END
-    my $cfg_xend= "/etc/xen/$gho->{Name}.cfg";
-    store_runvar("$gho->{Guest}_cfgpath", $cfg_xend);
-    store_runvar("$gho->{Guest}_swap_lv", "$gho->{Name}-swap");
+        my $cfg_xend= "/etc/xen/$gho->{Name}.cfg";
+        store_runvar("$gho->{Guest}_cfgpath", $cfg_xend);
+        store_runvar("$gho->{Guest}_swap_lv", "$gho->{Name}-swap");
+    }
+}
+
+sub start () {
+    my $cfg_xend= "/etc/xen/$guesthost.cfg";
+    my $cmd= toolstack()->{Command}." create ".$cfg_xend;
+    target_cmd_root($ho, $cmd, 30);
+    my $domains = target_cmd_output_root($ho, toolstack()->{Command}." list");
+    logm("guest state is\n$domains");
+}
+
+sub get_VM_IP {
+    my $IP;
+    my $leases;
+    my $dhcpf = $c{HostProp_DhcpWatchMethod};
+    my @meth = split /\s+/, $dhcpf;
+    if ($dhcpf =~ m,/,) {
+    $leases= new IO::File $meth[2], 'r';
+        if (!defined $leases) { return "open $meth[2]: $!"; }
+    } else {
+        $leases= new IO::Socket::INET(PeerAddr => $meth[2]);
+    }
+    while (<$leases>) {
+        my @lines = <$leases>;
+        my @newlines = reverse(@lines);
+        for(my $i=0;$i<@newlines;$i++) {
+            next if($newlines[$i] !~ /$_[0]/);
+            for($i;$i<@newlines;$i++) {
+                next if ($newlines[$i] !~ /^lease\s+(\d+\.\d+\.\d+\.\d+)\s*/);
+                $IP = $1;
+                return $IP;
+                }
+        last;
+        }
+    }
+}
+
+sub check_VM_up {
+    my ($g_ip) = @_;
+    my $ping_out = `ping -c 5 $g_ip 2>&1`;
+    if($ping_out =~ m/5 received/) {
+        logm("$guesthost is up and ping is OK!");
+    } else {
+        logm("Failed to boot up $guesthost");
+    }
+}
+
+sub stop_guest {
+    logm("shutdown L2 guest!");
+    target_cmd_root($ho,toolstack()->{Command}." shutdown -w ".$guesthost,100);
 }
 
 prep();
 ginstall();
+if($nested_L2 eq 'nested_L2') { 
+    start();
+    logm("waiting for 15's to boot up L2 guest!");
+    sleep(15);
+    my $L2_IP = get_VM_IP("$L2_MAC");
+    logm("L2 guest's IP is $L2_IP and try to ping it!");
+    check_VM_up($L2_IP);
+    stop_guest();
+}
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 07:46:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 07:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGFO-0004NN-EW; Fri, 28 Nov 2014 07:45:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XuGFN-0004ND-6T
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 07:45:45 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	7D/95-02954-82828745; Fri, 28 Nov 2014 07:45:44 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417160741!15417748!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8695 invoked from network); 28 Nov 2014 07:45:43 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-27.messagelabs.com with SMTP;
	28 Nov 2014 07:45:43 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 23:45:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="615347969"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 23:45:41 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:45:25 +0800
Message-Id: <1417160727-3100-3-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	robert.hu@intel.com, longtaox.pang@intel.com, di.zheng@intel.com
Subject: [Xen-devel] [OSSTEST PATCH 2/4] Building XEN and HVM Dom0 kernel
	for L1 guest VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "longtao.pang" <longtaox.pang@intel.com>

This patch is used for building XEN and HVM Dom0 kernel for L1 guest VM, 
and then reboot L1 guest into xen kernel.

---
 sg-run-job                        |    1 +
 ts-nested-L1-debian-install-part2 |  364 +++++++++++++++++++++++++++++++++++++
 2 files changed, 365 insertions(+)
 create mode 100755 ts-nested-L1-debian-install-part2

diff --git a/sg-run-job b/sg-run-job
index cd8b468..a4c0de1 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -291,6 +291,7 @@ proc run-job/test-pair {} {
 proc need-hosts/test-nested {} {return host}
 proc run-job/test-nested {} {
     run-ts . = ts-nested-L1-debian-install-part1
+    run-ts . = ts-nested-L1-debian-install-part2
 }
 
 proc test-guest-migr {g} {
diff --git a/ts-nested-L1-debian-install-part2 b/ts-nested-L1-debian-install-part2
new file mode 100755
index 0000000..2f52edc
--- /dev/null
+++ b/ts-nested-L1-debian-install-part2
@@ -0,0 +1,364 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 Citrix Inc.
+# Copyright (C) 2014 Intel Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::Debian;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost,$gn)= @ARGV;
+$whhost ||= 'host';
+$gn ||= 'nested';
+
+our $ho= selecthost($whhost);
+our $gho;
+our $nested_L2;
+
+my %distpath;
+sub guest_packages () {
+    target_install_packages($gho,
+                            qw(bridge-utils vncsnapshot libaio1 libpixman-1-0
+                               libsdl1.2debian libglib2.0-0 liblzma5 vim));
+    target_install_packages($gho,
+			    $ho->{Suite} =~ /squeeze/ ? "libyajl1" : "libyajl2");	#we always let L1 same as L0
+    if ($ho->{Suite} !~ m/lenny|squeeze/) {
+        target_install_packages($gho, 'libfdt1');
+    }
+    if ($r{arch} eq 'i386') {
+	target_install_packages($gho, 'libc6-xen');
+    }
+    target_install_packages($gho, @{toolstack()->{ExtraPackages}})
+        if toolstack()->{ExtraPackages};
+}
+
+sub guest_extract () {
+    my @parts = ('', 'kern', 'xen');
+    push @parts, 'libvirt' if $r{toolstack} eq "libvirt";
+
+    foreach my $part (@parts) {
+        target_extract_jobdistpath($gho, $part, "path_${part}dist",
+				   $r{"${part}buildjob"}, \%distpath);
+    }
+    target_cmd_root($gho, '/sbin/ldconfig');
+}
+
+sub guest_adjustconfig () {
+    target_editfile_root($gho, "/etc/xen/xend-config.sxp",
+			 "xend-config.sxp", sub {
+	my (@domains) = (qw(localhost localhost.localdomain),
+			 ".".$c{DnsDomain}, ".".$c{TestHostDomain});
+	logm("relocation domains: @domains");
+	foreach (@domains) {
+	    s/\./\\$&/g;
+	    s/^/^/g;
+	    s/$/\$/g;
+	    s/^\^(\\\.)/.\*$1/;
+	}
+	$_= join ' ', @domains;
+	s/[\'\\]/\\$&/g;
+	my $extra= "(xend-relocation-hosts-allow '$_')";
+	logm("relocation setting: $extra");
+	$extra .= "\n";
+        while (<EI>) {
+	    s/^\s*\(xend-relocation-hosts-allow/#$&/;
+	    print EO or die $!;
+	    if (m/^\#\(xend-relocation-hosts-allow/) {
+		print EO $extra or die $!;
+		$extra= '';
+	    }
+	}
+	print EO $extra or die $!;
+    }) if toolstack()->{Name} eq "xend";
+
+    my $trace_config_file;
+    foreach my $try (qw(/etc/default/xencommons
+                        /etc/sysconfig/xencommons
+                        /etc/default/xend
+                        /etc/sysconfig/xend)) {
+        next unless target_file_exists_root($gho, $try);
+        $trace_config_file= $try;
+        last;
+    }
+    die unless defined $trace_config_file;
+
+    target_editfile_root($gho, $trace_config_file, sub {
+        my $prnow;
+        $prnow= sub {
+            print EO "XENCONSOLED_TRACE=guest\n" or die $!;
+            $prnow= sub { };
+        };
+        while (<EI>) {
+            print EO or die $! unless m/^XENCONSOLED_TRACE/;
+            $prnow->() if m/^#XENCONSOLED_TRACE/;
+        }
+        print EO "\n" or die $!;
+        $prnow->();
+    });
+
+    target_cmd_root($gho, 'mkdir -p /var/log/xen/console');
+
+}
+
+=begin
+sub guest_setupboot () {
+    my $xenhopt= "conswitch=x watchdog";
+
+    my $cons= get_host_property($gho, 'XenSerialConsole', 'com1');
+
+    if ( $cons eq "com1" ) {
+	$xenhopt .= " com1=$c{Baud},8n1 console=com1,vga gdb=com1";
+    } elsif ( $cons eq "dtuart" ) {
+	$xenhopt .= " console=dtuart";
+	my $dtuart= get_host_property($gho, 'XenDTUARTPath', undef);
+	$xenhopt .= " dtuart=$dtuart" if $dtuart;
+    } else {
+	logm("No Xen console device defined for L1 Xen");
+    }
+    if (toolstack()->{Dom0MemFixed}) {
+        $xenhopt .= " dom0_mem=1G,max:1G";
+    }
+    my $append= $r{xen_boot_append};
+    $xenhopt .= " $append" if defined $append;
+    $append = get_host_property($gho, 'xen-commandline-append', undef);
+    $xenhopt .= " $append" if defined $append;
+    my @hooks;
+                host_get_pcipassthrough_devs($ho);
+                logm("pci passthrough: hiding in dom0: $hide");
+                $$kopt .= $hide;
+            }
+        };
+    }
+
+    my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
+    debian_boot_setup($gho, $want_kernver, $xenhopt, \%distpath);
+
+    logm("ready to boot L1 Xen");
+}
+=end
+=cut
+
+sub setupboot_L1_grub ($$$) {
+    my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
+    my $bl= { };
+    my $rmenu= '/boot/grub/grub.cfg';
+    my $kernkey= (defined $xenhopt ? 'KernDom0' : 'KernOnly');
+    my $parsemenu= sub {
+        my $f= bl_getmenu_open($ho, $rmenu, "$stash/$ho->{Name}--grub.cfg.1");
+    
+        my $count= 0;
+        my $entry;
+	my $submenu;
+        while (<$f>) {
+            next if m/^\s*\#/ || !m/\S/;
+            if (m/^\s*\}\s*$/) {
+                die unless $entry || $submenu;
+		if(!defined $entry && defined $submenu){
+		    logm("Met end of a submenu starting from $submenu->{StartLine}. Our want kern is $want_kernver");
+		    $submenu=undef;
+		    next;
+		}
+                my (@missing) =
+                    grep { !defined $entry->{$_} }  (defined $xenhopt ? qw(Title Hv KernDom0 KernVer) : qw(Title Hv KernOnly KernVer));
+		if (@missing) {
+		    logm("(skipping entry at $entry->{StartLine};".
+			 " no @missing)");
+		} elsif (defined $want_kernver &&
+			 $entry->{KernVer} ne $want_kernver) {
+		    logm("(skipping entry at $entry->{StartLine};".
+			 " kernel $entry->{KernVer}, not $want_kernver)");
+		} else {
+		    # yes!
+		    last;
+		}
+                $entry= undef;
+                next;
+            }
+            if (m/^function.*\{/) {
+                $entry= { StartLine => $. };
+            }
+            if (m/^menuentry\s+[\'\"](.*)[\'\"].*\{\s*$/) {
+                die $entry->{StartLine} if $entry;
+                $entry= { Title => $1, StartLine => $., Number => $count };
+                $count++;
+            }
+			if(m/^submenu\s+[\'\"](.*)[\'\"].*\{\s*$/){
+				$submenu={ StartLine =>$.};
+			}
+            if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\S+)/) {
+                die unless $entry;
+                $entry->{Hv}= $1;
+            }
+            if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
+                die unless $entry;
+                $entry->{KernOnly}= $1;
+                $entry->{KernVer}= $2;
+            }
+            if (m/^\s*module\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
+                die unless $entry;
+                $entry->{KernDom0}= $1;
+                $entry->{KernVer}= $2;
+            }
+            if (m/^\s*module\s*(?:\/boot)*\/(initrd\S+)/) {
+                $entry->{Initrd}= $1;
+            }
+        }
+        die 'grub 2 bootloader entry not found' unless $entry;
+
+        die unless $entry->{Title};
+
+        logm("boot check: grub2, found $entry->{Title}");
+
+	die unless $entry->{$kernkey};
+	if (defined $xenhopt) {
+	    die unless $entry->{Hv};
+	}
+
+        return $entry;
+    };
+
+
+    $bl->{UpdateConfig}= sub {
+	my ( $ho ) = @_;
+	target_cmd_root($ho, "update-grub");
+    };
+
+    $bl->{GetBootKern}= sub { return $parsemenu->()->{$kernkey}; };
+
+    $bl->{PreFinalUpdate}= sub {
+        my $entry= $parsemenu->();
+        
+        target_editfile_root($ho, '/etc/default/grub', sub {
+            my %k;
+            while (<::EI>) {
+                next if m/^GRUB_DEFAULT/;
+                print ::EO;
+            }
+            print ::EO <<END or die $!;
+
+GRUB_DEFAULT=$entry->{Number}
+END
+        });
+    };
+
+    return $bl;
+}
+
+our $initscripts_nobridge;
+sub guest_setupinitd () {
+    my $ts= toolstack();
+    my $xencommons= '/etc/init.d/xencommons';
+    my $have_xencommons=
+        !!target_cmd_output_root($gho, <<END);
+   if test -f $xencommons && ! grep 'FOR USE WITH LIBXL' $xencommons >/dev/null
+   then
+   echo y
+   fi
+END
+    $initscripts_nobridge= !defined($ts->{OldDaemonInitd}) || $have_xencommons;
+    logm("init.d scripts ".
+         ($initscripts_nobridge
+          ? 'do not mess with bridge, doing it in interfaces(5)'
+          : '_do_ mess with bridge, letting them handle it'));
+    my $cmd= '';
+    my $updatercd= sub {
+        my ($script,$start) = @_;
+        $cmd .= "\n    update-rc.d $script start $start 2 .";
+    };
+    if ($initscripts_nobridge) {
+        my $script= $have_xencommons ? 'xencommons' : 'xenlightdaemons';
+        $updatercd->($script,92);
+        my $pri= 93;
+        foreach my $d (@{ $ts->{NewDaemons} }) {
+            $updatercd->("$d",$pri);
+            $pri++;
+        }
+    } else {
+        my $initd= $ts->{OldDaemonInitd};
+        $updatercd->($initd,93) if defined $initd;
+        $updatercd->('xenbridge',38) if $ts->{OldSeparateBridgeInitd};
+    }
+    target_cmd_root($gho, $cmd);
+}
+
+sub bl_getmenu_open ($$$) {
+    my ($ho, $rmenu, $lmenu) = @_;
+    target_getfile($ho, 60, $rmenu, $lmenu);
+    my $f= new IO::File $lmenu, 'r' or die "$lmenu $?";
+    return $f;
+}
+
+sub setup_l1_bridge($)
+{
+    my ($ho)=@_;
+    my $bridge_port;
+    my $route_output=target_cmd_output_root($ho,"route -n");
+    foreach my $line (split /\n/, $route_output){
+        if($line =~ m/^\s*(?:(?:0\.0\.0\.0)|default).*\s(\w+)\s*$/ai){
+            $bridge_port=$1;
+            logm("get L1 bridge phy port $bridge_port");
+            last;
+        }
+    }
+        die "cannot find L1 port for xenbr0 bridge" if !defined $bridge_port;
+
+    target_editfile_root($ho, "/etc/network/interfaces",
+                         "etc-network-interfaces",
+                        sub {
+                            while(<EI>){
+                                s/^\s*iface\s*$bridge_port\s*inet.*dhcp\s*$/iface $bridge_port inet manual\nauto xenbr0\niface xenbr0 inet dhcp\n\tbridge_ports $bridge_port\n/;
+                                s/^\s*auto\s*$bridge_port/#auto\t$bridge_port/;
+                                print EO;
+                            }
+                         });
+    target_cmd_root($ho,"brctl addbr xenbr0; brctl addif xenbr0 $bridge_port; init 6");
+}
+
+
+$gho= selectguest($gn,$ho);
+store_runvar("$gho->{Guest}_kernkind",$r{'kernkind'});
+$gho->{Suite}=$ho->{Suite};
+
+guest_check_ip($gho);
+guest_packages();
+guest_extract();
+guest_adjustconfig();
+my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
+my $bootloader;
+$bootloader=setupboot_L1_grub($gho, $want_kernver, "");
+
+
+target_cmd_root($gho,
+                    "update-initramfs -k $want_kernver -c ||".
+                    " update-initramfs -k $want_kernver -u",
+                    200);
+$bootloader->{UpdateConfig}($gho); #so that /boot/grub/grub.cfg have new kernel and xen
+$bootloader->{PreFinalUpdate}();	#update /etc/default/grub, by setting default entry we want
+
+guest_setupinitd ();
+$bootloader->{UpdateConfig}($gho);	#use the default entry, apply it to /boot/grub/grub.cfg
+guest_editconfig($gho->{Host}, $gho, sub {
+        s/#nestedhvm/nestedhvm/;
+    });
+target_cmd_root($gho,"sync");
+setup_l1_bridge($gho);		#after setup L1 bridge, it will reboot for network settiings to take effect
+logm("ready to reboot L1 Xen");
+guest_await($gho, target_var($gho,'boot_timeout'));
+guest_check_up($gho);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 07:46:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 07:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGFQ-0004Ny-Ck; Fri, 28 Nov 2014 07:45:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XuGFP-0004NS-3y
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 07:45:47 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	3E/5D-02696-A2828745; Fri, 28 Nov 2014 07:45:46 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417160741!15417748!2
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8751 invoked from network); 28 Nov 2014 07:45:44 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-27.messagelabs.com with SMTP;
	28 Nov 2014 07:45:44 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 23:45:44 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="615347976"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 23:45:42 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:45:26 +0800
Message-Id: <1417160727-3100-4-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	robert.hu@intel.com, longtaox.pang@intel.com, di.zheng@intel.com
Subject: [Xen-devel] [OSSTEST PATCH 3/4] Add nested test case of installing
	L2 guest VM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "longtao.pang" <longtaox.pang@intel.com>

This patch is used for installing L2 guest VM inside L1 guest VM.

---
 sg-run-job        |    2 +
 ts-debian-install |  166 +++++++++++++++++++++++++++++++++++++++++------------
 2 files changed, 132 insertions(+), 36 deletions(-)

diff --git a/sg-run-job b/sg-run-job
index a4c0de1..7c0c6ca 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -292,6 +292,8 @@ proc need-hosts/test-nested {} {return host}
 proc run-job/test-nested {} {
     run-ts . = ts-nested-L1-debian-install-part1
     run-ts . = ts-nested-L1-debian-install-part2
+    run-ts . = ts-debian-install + host + nested + amd64 + nested_L2
+    run-ts . = ts-guest-destroy + host nested
 }
 
 proc test-guest-migr {g} {
diff --git a/ts-debian-install b/ts-debian-install
index 58ea743..2ca54e8 100755
--- a/ts-debian-install
+++ b/ts-debian-install
@@ -22,41 +22,61 @@ use Osstest::TestSupport;
 
 tsreadconfig();
 
-our ($whhost,$gn) = @ARGV;
-$whhost ||= 'host';
-$gn ||= 'debian';
+our ($whhost,$gn,$arch,$nested_L2) = @ARGV;
+$nested_L2 ||= '';
 
-our $ho= selecthost($whhost);
+if($nested_L2 eq 'nested_L2') {
+    my $L1_IP = &get_VM_IP($r{'nested_ether'});
+    $whhost = "host=$L1_IP";
+    $gn ||= 'nested';
+    $arch ||= 'amd64';
+} else {
+    $whhost ||= 'host';
+    $gn ||= 'debian';	
+}
 
+our $ho= selecthost($whhost);
 our $ram_mb=    512;
 our $swap_mb=  1000;
 our $disk_mb= 10000;
-
 our $guesthost= "$gn.guest.osstest";
 our $gho;
+our $L2_MAC = select_ether($ho,"L2_ether");
 
 sub prep () {
     target_install_packages_norec($ho, qw(lvm2 xen-tools));
-
-    $gho= prepareguest($ho, $gn, $guesthost, 22,
-                       $swap_mb + $disk_mb + 2,
-                       40);
-    target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
+    unless($nested_L2 eq 'nested_L2') {
+	$gho= prepareguest($ho, $gn, $guesthost, 22,
+        	           $swap_mb + $disk_mb + 2,
+                	   40);
+	target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
+    }
 }
 
 sub ginstall () {
-    my $arch= $r{"$gho->{Guest}_arch"};
+    my $gsuite;
+    my $kernpath;
+    my $initrd;
+    my $kernver;
+    if($nested_L2 eq 'nested_L2'){
+        my $suite= "$c{DebianSuite}";
+        $gsuite= defined($suite) ? "--dist=$suite" : '';
+        $kernver ||= target_cmd_output_root($ho, 'uname -r');
+        $kernpath = "/boot/vmlinuz-$kernver";
+        $initrd ||= "/boot/initrd.img-$kernver";
+    } else {
+        my $arch= $r{"$gho->{Guest}_arch"};
+        $gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
+        $kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
+        $initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
+        if (!$kernpath) {
+	    $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
+            $kernver ||= target_cmd_output($ho, 'uname -r');
+	    $kernpath = "/boot/vmlinuz-$kernver";
+	    $initrd ||= "/boot/initrd.img-$kernver";
+        } 
+    } 
     my $archarg= defined($arch) ? "--arch $arch" : '';
-    my $gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
-
-    my $kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
-    my $initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
-    if (!$kernpath) {
-	my $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
-	$kernver ||= target_cmd_output($ho, 'uname -r');
-	$kernpath = "/boot/vmlinuz-$kernver";
-	$initrd ||= "/boot/initrd.img-$kernver";
-    }
     if (!$initrd) {
 	$initrd = $kernpath;
 	$initrd =~ s,/vmlinuz-,/initrd.img-, or die "$initrd ?";
@@ -76,23 +96,97 @@ sub ginstall () {
             fi
 END
     }
-    target_cmd_root($ho, <<END, 2000);
-        xen-create-image \\
-            --dhcp --mac $gho->{Ether} \\
-            --memory ${ram_mb}Mb --swap ${swap_mb}Mb \\
-            --dist $gsuite \\
-            --mirror http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
-            --hostname $gho->{Name} \\
-            --lvm $gho->{Vg} --force \\
-            --kernel $kernpath \\
-            --genpass 0 --password xenroot \\
-            $initrd_opt \\
-            $archarg
+    if($nested_L2 eq 'nested_L2') {
+        target_cmd_root($ho, <<END, 2000);
+            xen-create-image \\
+                --dhcp --mac=$L2_MAC \\
+                --size=${disk_mb}Mb --memory=${ram_mb}Mb --swap=${swap_mb}Mb \\
+                --mirror=http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
+                --hostname $guesthost \\
+                --dir=/testnested \\
+                --kernel=$kernpath \\
+                --genpass 0 --password xenroot \\
+                $initrd_opt \\
+                $gsuite \\
+                $archarg
+END
+    } else {
+        target_cmd_root($ho, <<END, 2000);
+            xen-create-image \\
+                --dhcp --mac $gho->{Ether} \\
+                --memory ${ram_mb}Mb --swap ${swap_mb}Mb \\
+                --dist $gsuite \\
+                --mirror http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
+                --hostname $gho->{Name} \\
+                --lvm $gho->{Vg} --force \\
+                --kernel $kernpath \\
+                --genpass 0 --password xenroot \\
+                $initrd_opt \\
+                $archarg
 END
-    my $cfg_xend= "/etc/xen/$gho->{Name}.cfg";
-    store_runvar("$gho->{Guest}_cfgpath", $cfg_xend);
-    store_runvar("$gho->{Guest}_swap_lv", "$gho->{Name}-swap");
+        my $cfg_xend= "/etc/xen/$gho->{Name}.cfg";
+        store_runvar("$gho->{Guest}_cfgpath", $cfg_xend);
+        store_runvar("$gho->{Guest}_swap_lv", "$gho->{Name}-swap");
+    }
+}
+
+sub start () {
+    my $cfg_xend= "/etc/xen/$guesthost.cfg";
+    my $cmd= toolstack()->{Command}." create ".$cfg_xend;
+    target_cmd_root($ho, $cmd, 30);
+    my $domains = target_cmd_output_root($ho, toolstack()->{Command}." list");
+    logm("guest state is\n$domains");
+}
+
+sub get_VM_IP {
+    my $IP;
+    my $leases;
+    my $dhcpf = $c{HostProp_DhcpWatchMethod};
+    my @meth = split /\s+/, $dhcpf;
+    if ($dhcpf =~ m,/,) {
+    $leases= new IO::File $meth[2], 'r';
+        if (!defined $leases) { return "open $meth[2]: $!"; }
+    } else {
+        $leases= new IO::Socket::INET(PeerAddr => $meth[2]);
+    }
+    while (<$leases>) {
+        my @lines = <$leases>;
+        my @newlines = reverse(@lines);
+        for(my $i=0;$i<@newlines;$i++) {
+            next if($newlines[$i] !~ /$_[0]/);
+            for($i;$i<@newlines;$i++) {
+                next if ($newlines[$i] !~ /^lease\s+(\d+\.\d+\.\d+\.\d+)\s*/);
+                $IP = $1;
+                return $IP;
+                }
+        last;
+        }
+    }
+}
+
+sub check_VM_up {
+    my ($g_ip) = @_;
+    my $ping_out = `ping -c 5 $g_ip 2>&1`;
+    if($ping_out =~ m/5 received/) {
+        logm("$guesthost is up and ping is OK!");
+    } else {
+        logm("Failed to boot up $guesthost");
+    }
+}
+
+sub stop_guest {
+    logm("shutdown L2 guest!");
+    target_cmd_root($ho,toolstack()->{Command}." shutdown -w ".$guesthost,100);
 }
 
 prep();
 ginstall();
+if($nested_L2 eq 'nested_L2') { 
+    start();
+    logm("waiting for 15's to boot up L2 guest!");
+    sleep(15);
+    my $L2_IP = get_VM_IP("$L2_MAC");
+    logm("L2 guest's IP is $L2_IP and try to ping it!");
+    check_VM_up($L2_IP);
+    stop_guest();
+}
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 07:46:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 07:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGFP-0004Nd-QZ; Fri, 28 Nov 2014 07:45:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XuGFN-0004NE-Kw
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 07:45:45 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	D8/7D-02707-82828745; Fri, 28 Nov 2014 07:45:44 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417160740!13811894!2
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 920 invoked from network); 28 Nov 2014 07:45:42 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-206.messagelabs.com with SMTP;
	28 Nov 2014 07:45:42 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 23:45:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="615347959"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 23:45:39 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:45:24 +0800
Message-Id: <1417160727-3100-2-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	robert.hu@intel.com, longtaox.pang@intel.com, di.zheng@intel.com
Subject: [Xen-devel] [OSSTEST PATCH 1/4] Add nested testcase of preparing
	and installing L1 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "longtao.pang" <longtaox.pang@intel.com>

This patch is used for preparing and installing L1 guest VM inside L0 system 
on testhost machine.

---
 Osstest/Debian.pm                 |   25 +++--
 Osstest/TestSupport.pm            |   31 +++++-
 sg-run-job                        |    5 +
 ts-nested-L1-debian-install-part1 |  202 +++++++++++++++++++++++++++++++++++++
 4 files changed, 249 insertions(+), 14 deletions(-)
 create mode 100755 ts-nested-L1-debian-install-part1

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8f80eb4..68da2cb 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1,5 +1,6 @@
 # This is part of "osstest", an automated testing framework for Xen.
 # Copyright (C) 2009-2013 Citrix Inc.
+# Copyright (C) 2014 Intel Inc.
 # 
 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU Affero General Public License as published by
@@ -286,15 +287,18 @@ sub setupboot_grub2 ($$$) {
     
         my $count= 0;
         my $entry;
+	my $submenu;
         while (<$f>) {
             next if m/^\s*\#/ || !m/\S/;
             if (m/^\s*\}\s*$/) {
-                die unless $entry;
+                die unless $entry || $submenu;
+	    	if(!defined $entry && defined $submenu){
+		  logm("Met end of a submenu starting from $submenu->{StartLine}.Our want kern is $want_kernver");
+		  $submenu=undef;
+		  next;
+		}
                 my (@missing) =
-                    grep { !defined $entry->{$_} } 
-		        (defined $xenhopt
-			 ? qw(Title Hv KernDom0 KernVer)
-			 : qw(Title Hv KernOnly KernVer));
+		grep { !defined $entry->{$_} }  (defined $xenhopt ? qw(Title Hv KernDom0 KernVer) : qw(Title Hv KernOnly KernVer));
 		if (@missing) {
 		    logm("(skipping entry at $entry->{StartLine};".
 			 " no @missing)");
@@ -317,21 +321,24 @@ sub setupboot_grub2 ($$$) {
                 $entry= { Title => $1, StartLine => $., Number => $count };
                 $count++;
             }
-            if (m/^\s*multiboot\s*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
+	    if(m/^submenu\s+[\'\"](.*)[\'\"].*\{\s*$/){
+		$submenu={ StartLine =>$.};
+	    }
+	    if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
                 die unless $entry;
                 $entry->{Hv}= $1;
             }
-            if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
+	    if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
                 die unless $entry;
                 $entry->{KernOnly}= $1;
                 $entry->{KernVer}= $2;
             }
-            if (m/^\s*module\s*\/(vmlinu[xz]-(\S+))/) {
+	    if (m/^\s*module\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
                 die unless $entry;
                 $entry->{KernDom0}= $1;
                 $entry->{KernVer}= $2;
             }
-            if (m/^\s*module\s*\/(initrd\S+)/) {
+	    if (m/^\s*module\s*(?:\/boot)*\/(initrd\S+)/) {
                 $entry->{Initrd}= $1;
             }
         }
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 45ceee9..21955b8 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -55,8 +55,9 @@ BEGIN {
                       target_putfilecontents_stash
 		      target_putfilecontents_root_stash
                       target_put_guest_image target_editfile
-                      target_editfile_root target_file_exists
-                      target_run_apt
+		      target_editfile_root target_file_exists 
+		      target_file_exists_root
+		      target_run_apt
                       target_install_packages target_install_packages_norec
                       target_jobdir target_extract_jobdistpath_subdir
                       target_extract_jobdistpath target_guest_lv_name
@@ -67,7 +68,7 @@ BEGIN {
                       selecthost get_hostflags get_host_property
                       get_host_native_linux_console
                       power_state power_cycle power_cycle_time
-                      serial_fetch_logs
+                      serial_fetch_logs select_ether
                       propname_massage
          
                       get_stashed open_unique_stashfile compress_stashed
@@ -109,6 +110,7 @@ BEGIN {
                       iso_gen_flags_basic
                       iso_copy_content_from_image
                       guest_editconfig_nocd
+		      guest_editconfig_cd
                       );
     %EXPORT_TAGS = ( );
 
@@ -481,6 +483,14 @@ sub target_file_exists ($$) {
     die "$rfile $out ?";
 }
 
+sub target_file_exists_root ($$) {
+    my ($ho,$rfile) = @_;
+    my $out= target_cmd_output_root($ho, "if test -e $rfile; then echo y; fi");
+    return 1 if $out =~ m/^y$/;
+    return 0 if $out !~ m/\S/;
+    die "$rfile $out ?";
+}
+
 sub teditfileex {
     my $user= shift @_;
     my $code= pop @_;
@@ -716,6 +726,7 @@ sub power_cycle_time ($) {
 sub power_cycle ($) {
     my ($ho) = @_;
     $mjobdb->host_check_allocated($ho);
+    $mjobdb->xen_check_installed($ho);
     die "refusing to set power state for host $ho->{Name}".
 	" possibly shared with other jobs\n"
 	if $ho->{SharedMaybeOthers};
@@ -921,7 +932,7 @@ sub compress_stashed($) {
 sub host_reboot ($) {
     my ($ho) = @_;
     target_reboot($ho);
-    poll_loop(40,2, 'reboot-confirm-booted', sub {
+    poll_loop(200,2, 'reboot-confirm-booted', sub {
         my $output;
         if (!eval {
             $output= target_cmd_output($ho, <<END, 40);
@@ -1449,7 +1460,7 @@ sub prepareguest_part_xencfg ($$$$$) {
     my $xencfg= <<END;
 name        = '$gho->{Name}'
 memory = ${ram_mb}
-vif         = [ 'type=ioemu,mac=$gho->{Ether}' ]
+vif         = [ 'type=ioemu,model=e1000,mac=$gho->{Ether}' ]
 #
 on_poweroff = 'destroy'
 on_reboot   = '$onreboot'
@@ -2047,4 +2058,14 @@ sub guest_editconfig_nocd ($$) {
     });
 }
 
+sub guest_editconfig_cd ($) {
+    my ($gho) = @_;
+    guest_editconfig($gho->{Host}, $gho, sub {
+        if (m/^\s*boot\s*= '\s*d\s*c\s*'/) {
+            s/dc/cd/;
+        }
+        s/^on_reboot.*/on_reboot='restart'/;
+    });
+}
+
 1;
diff --git a/sg-run-job b/sg-run-job
index 2cf810a..cd8b468 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -288,6 +288,11 @@ proc run-job/test-pair {} {
 #    run-ts . remus-failover ts-remus-check         src_host dst_host + debian
 }
 
+proc need-hosts/test-nested {} {return host}
+proc run-job/test-nested {} {
+    run-ts . = ts-nested-L1-debian-install-part1
+}
+
 proc test-guest-migr {g} {
     if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
 
diff --git a/ts-nested-L1-debian-install-part1 b/ts-nested-L1-debian-install-part1
new file mode 100755
index 0000000..9649b76
--- /dev/null
+++ b/ts-nested-L1-debian-install-part1
@@ -0,0 +1,202 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 Citrix Inc.
+# Copyright (C) 2014 Intel Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::Debian;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our $stage=0;
+if (@ARGV && $ARGV[0] =~ m/^--stage(\d+)$/) { $stage=$1; shift @ARGV; }
+
+defined($r{bios}) or die "Need to define which bios to use";
+
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+$gn ||= 'nested';
+
+our $ho= selecthost($whhost);
+
+# guest memory size will be set based on host free memory, see below
+our $ram_mb;
+our $disk_mb= 100000;
+
+our $guesthost= "$gn.l1.osstest";
+our $gho;
+
+our $toolstack= toolstack()->{Command};
+
+
+sub preseed () {
+
+    my $preseed_file = preseed_base('wheezy','',());
+    my $authkeys = join('\\n', split(/\n/, authorized_keys()));
+
+    $preseed_file .= (<<END);
+d-i netcfg/get_hostname string $gn
+
+d-i partman-auto/disk string /dev/xvda
+d-i partman-auto/method string  regular
+
+d-i partman-auto/expert_recipe string \\
+        boot-root :: \\
+                512 50 512 vfat \\
+                        \$primary{ } \$bootable{ } \\
+                        method{ efi } format{ } \\
+                        use_filesystem{ } filesystem{ vfat } \\
+                        mountpoint{ /boot/efi } \\
+                . \\
+                95000 50 95000 ext4 \\
+                        method{ format } format{ } \\
+                        use_filesystem{ } filesystem{ ext4 } \\
+                        mountpoint{ / } \\
+                . \\
+                512 30 100% linux-swap \\
+                        method{ swap } format{ } \\
+                .
+
+d-i apt-setup/cdrom/set-first boolean false
+
+d-i preseed/late_command string \\
+        in-target mkdir -p /boot/efi/EFI/boot; \\
+        in-target cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx64.efi ;\\
+        in-target mkdir -p /root/.ssh; \\
+        in-target sh -c "echo -e '$authkeys'> /root/.ssh/authorized_keys";
+END
+    return $preseed_file;
+}
+
+sub grub_cfg () {
+
+    return <<"END";
+set default="0"
+set timeout=5
+
+menuentry 'debian guest auto Install' {
+    linux /install.amd/vmlinuz console=vga console=ttyS0,115200n8 preseed/file=/preseed.cfg
+    initrd /install.amd/initrd.gz
+}
+END
+}
+
+sub isolinux_cfg () {
+    return <<"END";
+    default autoinstall
+    prompt 0
+    timeout 0
+
+    label autoinstall
+        kernel /install.amd/vmlinuz
+        append video=vesa:ywrap,mtrr vga=788 console=ttyS0,115200n8 preseed/file=/preseed.cfg initrd=/install.amd/initrd.gz
+END
+}
+
+sub prepare_initrd ($$$) {
+    my ($initrddir,$newiso,$preseed_file_path) = @_;
+    return <<"END";
+      rm -rf $initrddir
+      mkdir $initrddir
+      cd $initrddir
+      gzip -d < $newiso/install.amd/initrd.gz | cpio --extract --make-directories --no-absolute-filename
+      cp $preseed_file_path preseed.cfg
+      find . | cpio -H newc --create | gzip -9 > $newiso/install.amd/initrd.gz
+      cd -
+      rm -rf $initrddir
+      cd $newiso
+      md5sum `find -L -type f -print0 | xargs -0` > md5sum.txt
+      cd -
+END
+}
+
+our $emptyiso= "/root/$flight.$job.$gn-empty.iso";
+
+sub prep () {
+    target_install_packages_norec($ho, qw(lvm2 rsync genisoimage ethtool));
+
+    my $isotimeout= 600;
+
+    $gho= prepareguest($ho, $gn, $guesthost, 22,
+                       $disk_mb + 1,
+                       200);
+    my $base = "/root/$flight.$job.$gn-";
+    my $newiso= $base . "newiso";
+    my $emptydir= $base . "empty-dir";
+    my $initrddir= $base . "initrd-dir";
+    my $preseed_file_path = $base . "preseed";
+
+    my @isogen_extra = qw(-eltorito-alt-boot
+                          -b boot/grub/efi.img
+                          -no-emul-boot
+                          -r);
+    my @isogen_opts = (iso_gen_flags_basic(), @isogen_extra);
+
+    iso_create_empty($ho, $emptyiso, $emptydir);
+
+    target_putfilecontents_root_stash($ho, 10, preseed(),
+                                      $preseed_file_path);
+
+    more_prepareguest_hvm($ho,$gho, $ram_mb, $disk_mb,
+                          OnReboot => 'preserve',
+                          Bios => $r{bios},
+  			  DefVcpus => 4,
+  			  ExtraConfig => '#nestedhvm=1',
+                          PostImageHook => sub {
+        my $cmds = iso_copy_content_from_image($gho, $newiso);
+        $cmds .= prepare_initrd($initrddir,$newiso,$preseed_file_path);
+        target_cmd_root($ho, $cmds, $isotimeout);
+        target_putfilecontents_root_stash($ho, 10, grub_cfg(),
+                                          "$newiso/debian/boot/grub/grub.cfg");
+
+        target_putfilecontents_root_stash($ho, 10, isolinux_cfg(),
+                                          "$newiso/isolinux/isolinux.cfg");
+
+        iso_create_genisoimage($ho, $gho->{Rimage}, $newiso, $isotimeout, @isogen_opts);
+    });
+}
+
+# If host has >8G free memory, create a guest with 4G memory to catch
+# any error that triggers cross 4G boundary
+my $host_freemem_mb = host_get_free_memory($ho, $toolstack);
+my $ram_minslop = 100;
+my $ram_lots = 5000;
+if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
+    $ram_mb = $ram_lots;
+} else {
+    $ram_mb = 2048;
+}
+logm("Host has $host_freemem_mb MB free memory, setting guest memory size to $ram_mb MB");
+
+if (!$stage) {
+    prep();
+    guest_create($gho,$toolstack);
+} else {
+    $gho= selectguest($gn,$gho);
+}
+if ($stage<2) {
+    guest_await_reboot($ho,$gho,2000);
+    guest_destroy($ho,$gho);
+}
+
+guest_editconfig_cd($gho);
+guest_create($gho,$toolstack);
+guest_await_dhcp_tcp($gho,300);
+guest_check_up($gho);
+target_cmd_root($gho, "mkdir -p /home/osstest/.ssh && cp /root/.ssh/authorized_keys /home/osstest/.ssh/");
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 07:46:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 07:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGFM-0004N6-2i; Fri, 28 Nov 2014 07:45:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XuGFK-0004Mz-NW
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 07:45:42 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	A1/D2-19763-52828745; Fri, 28 Nov 2014 07:45:41 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417160740!13811894!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32253 invoked from network); 28 Nov 2014 07:45:41 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-206.messagelabs.com with SMTP;
	28 Nov 2014 07:45:41 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 23:45:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="615347952"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 23:45:37 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:45:23 +0800
Message-Id: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	robert.hu@intel.com, longtaox.pang@intel.com, di.zheng@intel.com
Subject: [Xen-devel] [OSSTEST PATCH 0/4] Introduction of the patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 updated these patchs about adding Nested test job into OSSTest.
Nested virtualization is the function of running a hypervisor inside a virtual machine.
The hypervisor that runs on the real hardware is called a level 0 or L0; 
The hypervisor that runs as a guest inside L0 is called level 1 or L1; 
A guest that running inside the L1 hypervisor is called a level 2 or L2.

For running nested test job, we should run build-amd64 job and build-amd64-hvm job first. 
During the testing, it will install L1 guest VM inside L0, 
the L1 guest should build xen and HVM Dom0 kernel and then boot into xen kernel. 
Next, begin to install L2 guest VM inside L1. 
After that, make sure ping L2 is successfully

----------------------------------------------------------------
root (4):
      Add nested testcase of preparing and installing L1 guest
      Building XEN and HVM Dom0 kernel for L1 guest VM
      Add nested test case of installing L2 guest VM
      Insert nested test job name and runvars into standalone database

 Osstest/Debian.pm                 |   25 ++-
 Osstest/TestSupport.pm            |   31 +++-
 make-flight                       |   19 ++
 mfi-common                        |    8 +
 sg-run-job                        |    8 +
 ts-debian-install                 |  166 +++++++++++++----
 ts-nested-L1-debian-install-part1 |  202 ++++++++++++++++++++
 ts-nested-L1-debian-install-part2 |  364 +++++++++++++++++++++++++++++++++++++
 8 files changed, 773 insertions(+), 50 deletions(-)
 create mode 100755 ts-nested-L1-debian-install-part1
 create mode 100755 ts-nested-L1-debian-install-part2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 07:46:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 07:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGFS-0004OV-QU; Fri, 28 Nov 2014 07:45:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XuGFQ-0004Nx-PP
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 07:45:48 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	05/1E-02953-C2828745; Fri, 28 Nov 2014 07:45:48 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417160746!15432851!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29944 invoked from network); 28 Nov 2014 07:45:47 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-27.messagelabs.com with SMTP;
	28 Nov 2014 07:45:47 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Nov 2014 23:45:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="615347983"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga001.jf.intel.com with ESMTP; 27 Nov 2014 23:45:44 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:45:27 +0800
Message-Id: <1417160727-3100-5-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	robert.hu@intel.com, longtaox.pang@intel.com, di.zheng@intel.com
Subject: [Xen-devel] [OSSTEST PATCH 4/4] Insert nested test job name and
	runvars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "longtao.pang" <longtaox.pang@intel.com>

This patch is used for inserting nested test job name and runvars into 
standalone.db database after execute command './standalone-reset'.

---
 make-flight |   19 +++++++++++++++++++
 mfi-common  |    8 ++++++++
 2 files changed, 27 insertions(+)

diff --git a/make-flight b/make-flight
index 9963a46..fe64237 100755
--- a/make-flight
+++ b/make-flight
@@ -197,6 +197,24 @@ do_hvm_win7_x64_tests () {
             all_hostflags=$most_hostflags,hvm
 }
 
+do_hvm_debian_nested_tests () {
+  if [ $xenarch != amd64 ]; then
+    return
+  fi
+  if [ $dom0arch != amd64 ]; then
+    return
+  fi
+
+  job_create_test test-$xenarch$kern-$dom0arch-nested test-nested xl \
+           $xenarch $dom0arch \
+            nested_image=debian-7.6.0-amd64-DVD-1.iso \
+           bios=seabios \
+           kernbuildjob=build-amd64-hvm \
+           kernkind=hvm \
+           device_model_version=qemu-xen \
+            all_hostflags=$most_hostflags,hvm
+}
+
 do_hvm_debian_test_one () {
   testname=$1
   bios=$2
@@ -364,6 +382,7 @@ test_matrix_do_one () {
 
   fi
 
+  do_hvm_debian_nested_tests
   do_passthrough_tests
 }
 
diff --git a/mfi-common b/mfi-common
index 5c4f5d5..0cc0101 100644
--- a/mfi-common
+++ b/mfi-common
@@ -166,6 +166,14 @@ create_build_jobs () {
                 revision_qemu=$REVISION_QEMU                                 \
                 revision_qemuu=$REVISION_QEMU_UPSTREAM
     fi
+    ./cs-job-create $flight build-$arch-hvm build-kern                       \
+                arch=$arch kconfighow=xen-enable-xen-config                  \
+                $RUNVARS $BUILD_RUNVARS $BUILD_LINUX_RUNVARS $arch_runvars   \
+                $suite_runvars                                               \
+                host_hostflags=$build_hostflags                              \
+                revision_linux=HEAD                                          \
+                tree_linux=git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git                                                             \
+                ${TREEVCS_LINUX:+treevcs_linux=}${TREEVCS_LINUX}
 
     ./cs-job-create $flight build-$arch-pvops build-kern                     \
                 arch=$arch kconfighow=xen-enable-xen-config                  \
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 08:25:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 08: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.xen.org>)
	id 1XuGrP-0006Xf-Hd; Fri, 28 Nov 2014 08:25:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XuGrN-0006Xa-2F
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 08:25:01 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	C5/24-14727-C5138745; Fri, 28 Nov 2014 08:25:00 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417163098!8511757!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29675 invoked from network); 28 Nov 2014 08:24:59 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2014 08:24:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1417163098; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=s/owDicjnlohuBPzCvS5qAR2JqA5mM9mgfKkkOkaPXU=;
	b=LRmkzrWOQ99cn1zHS+X3AaaCyeMe21+XUgrBQmoBtMOY77YvkWu3lj6aShjl4vi8vEvZsqV5k0GPiUhYsI1xUQBYQe1unm65OFLUTePrKdcVMv58w7GYFP4aVXdkAtuDyNQ9c7Znr3d4dNfzimzpGVlVoqB9dcdTQMA8HuNxzUo=
Received: from [10.0.0.112] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Fri, 28 Nov 2014 00:24:57 -0800
	id 00000000000304BA.54783159.00007192
Message-ID: <54783158.3050601@ihonk.com>
Date: Fri, 28 Nov 2014 00:24:56 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
	<54746F59020000780004A9E9@mail.emea.novell.com>
	<5476B6A8.4060706@ihonk.com>
	<5476FC9C020000780004B11D@mail.emea.novell.com>
In-Reply-To: <5476FC9C020000780004B11D@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/27/2014 01:27 AM, Jan Beulich wrote:
> This was precisely the reason why I told you that the numbering
> differs (and is confusing and has nothing to do with actual C state
> numbers): What max_cstate refers to in the mwait-idle driver is
> what above is listed as type[Cx], i.e. the state at index 1 is C1, at
> 2 we've got C1E, and at 3 we've got C2. And those still aren't in
> line with the numbering the CPU documentation uses, it's rather
> kind of meant to refer to the ACPI numbering (but probably also
> not fully matching up).

Ah, thanks for the explanation.

> So max_cstate=2 working suggests a problem with what the CPU
> calls C6, which presumably isn't all that surprising considering the
> many errata (BD35, BD38, BD40, BD59, BD87, and BD104). Not
> sure how to proceed from here - I suppose you already made
> sure you run with the latest available BIOS.

Yes, latest available BIOS.

> And with 6 errata
> documented it's not all that unlikely that there's a 7th one with
> MONITOR/MWAIT behavior. The commit you bisected to (and
> which you had verified to be the culprit by just forcing
> arch_skip_send_event_check() to always return false) could be
> reasonably assumed to be broken only when MWAIT use for all
> C states didn't work.

Now I did get a hang with max_cstate=3 and mwait-idle=0. May I assume 
that mwait-idle=0 means that ACPI is responsible for the throttling?

Thanks again for all your help!

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 08:25:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 08: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.xen.org>)
	id 1XuGrP-0006Xf-Hd; Fri, 28 Nov 2014 08:25:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XuGrN-0006Xa-2F
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 08:25:01 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	C5/24-14727-C5138745; Fri, 28 Nov 2014 08:25:00 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417163098!8511757!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29675 invoked from network); 28 Nov 2014 08:24:59 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2014 08:24:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1417163098; h=Received :
	Message-ID : Date : From : User-Agent : MIME-Version : To : CC :
	Subject : References : In-Reply-To : Content-Type :
	Content-Transfer-Encoding;
	bh=s/owDicjnlohuBPzCvS5qAR2JqA5mM9mgfKkkOkaPXU=;
	b=LRmkzrWOQ99cn1zHS+X3AaaCyeMe21+XUgrBQmoBtMOY77YvkWu3lj6aShjl4vi8vEvZsqV5k0GPiUhYsI1xUQBYQe1unm65OFLUTePrKdcVMv58w7GYFP4aVXdkAtuDyNQ9c7Znr3d4dNfzimzpGVlVoqB9dcdTQMA8HuNxzUo=
Received: from [10.0.0.112] ([::ffff:174.65.75.5])
	(AUTH: PLAIN steve@newportit.com, TLS: TLSv1/SSLv3, 128bits, AES128-SHA)
	by wapdot.org with ESMTPSA; Fri, 28 Nov 2014 00:24:57 -0800
	id 00000000000304BA.54783159.00007192
Message-ID: <54783158.3050601@ihonk.com>
Date: Fri, 28 Nov 2014 00:24:56 -0800
From: Steve Freitas <sflist@ihonk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
	<54746F59020000780004A9E9@mail.emea.novell.com>
	<5476B6A8.4060706@ihonk.com>
	<5476FC9C020000780004B11D@mail.emea.novell.com>
In-Reply-To: <5476FC9C020000780004B11D@mail.emea.novell.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/27/2014 01:27 AM, Jan Beulich wrote:
> This was precisely the reason why I told you that the numbering
> differs (and is confusing and has nothing to do with actual C state
> numbers): What max_cstate refers to in the mwait-idle driver is
> what above is listed as type[Cx], i.e. the state at index 1 is C1, at
> 2 we've got C1E, and at 3 we've got C2. And those still aren't in
> line with the numbering the CPU documentation uses, it's rather
> kind of meant to refer to the ACPI numbering (but probably also
> not fully matching up).

Ah, thanks for the explanation.

> So max_cstate=2 working suggests a problem with what the CPU
> calls C6, which presumably isn't all that surprising considering the
> many errata (BD35, BD38, BD40, BD59, BD87, and BD104). Not
> sure how to proceed from here - I suppose you already made
> sure you run with the latest available BIOS.

Yes, latest available BIOS.

> And with 6 errata
> documented it's not all that unlikely that there's a 7th one with
> MONITOR/MWAIT behavior. The commit you bisected to (and
> which you had verified to be the culprit by just forcing
> arch_skip_send_event_check() to always return false) could be
> reasonably assumed to be broken only when MWAIT use for all
> C states didn't work.

Now I did get a hang with max_cstate=3 and mwait-idle=0. May I assume 
that mwait-idle=0 means that ACPI is responsible for the throttling?

Thanks again for all your help!

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 08:27:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 08:27:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGtb-0006cw-2Q; Fri, 28 Nov 2014 08:27:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuGtZ-0006cq-Kn
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 08:27:17 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	E9/CD-22819-2E138745; Fri, 28 Nov 2014 08:27:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417163232!13820702!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23090 invoked from network); 28 Nov 2014 08:27:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 08:27:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208";a="197378263"
Message-ID: <1417163231.2372.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Fri, 28 Nov 2014 08:27:11 +0000
In-Reply-To: <alpine.DEB.2.00.1411272342370.5756@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411272342370.5756@procyon.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] fix migration failure with xl migrate
	--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 Fri, 2014-11-28 at 00:28 +0000, M A Young wrote:
> Migrations with xl migrate --debug will fail because debugging information 
> from the receiving process is written to the stdout channel. This channel 
> is also used for status messages so the migration will fail as the sending 
> process receives an unexpected message. This patch moves the debugging 
> information to the stderr channel.
> 
> Version 2 moves some output back to stdout that was accidentally moved 
> to stderr in the first version.
> 
> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>

I think you've forgotten the attachment.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 08:27:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 08:27:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGtb-0006cw-2Q; Fri, 28 Nov 2014 08:27:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuGtZ-0006cq-Kn
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 08:27:17 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	E9/CD-22819-2E138745; Fri, 28 Nov 2014 08:27:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417163232!13820702!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23090 invoked from network); 28 Nov 2014 08:27:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 08:27:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208";a="197378263"
Message-ID: <1417163231.2372.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Fri, 28 Nov 2014 08:27:11 +0000
In-Reply-To: <alpine.DEB.2.00.1411272342370.5756@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411272342370.5756@procyon.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] fix migration failure with xl migrate
	--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 Fri, 2014-11-28 at 00:28 +0000, M A Young wrote:
> Migrations with xl migrate --debug will fail because debugging information 
> from the receiving process is written to the stdout channel. This channel 
> is also used for status messages so the migration will fail as the sending 
> process receives an unexpected message. This patch moves the debugging 
> information to the stderr channel.
> 
> Version 2 moves some output back to stdout that was accidentally moved 
> to stderr in the first version.
> 
> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>

I think you've forgotten the attachment.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 08:29:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 08: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 1XuGvS-0006ja-IN; Fri, 28 Nov 2014 08:29:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XuGvR-0006jV-Ef
	for Xen-devel@lists.xen.org; Fri, 28 Nov 2014 08:29:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	92/93-25276-85238745; Fri, 28 Nov 2014 08:29:12 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417163350!12028099!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1031 invoked from network); 28 Nov 2014 08:29:11 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-7.tower-21.messagelabs.com with SMTP;
	28 Nov 2014 08:29:11 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 28 Nov 2014 00:21:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="422575789"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by FMSMGA003.fm.intel.com with ESMTP; 28 Nov 2014 00:19:11 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:59:12 +0800
Message-Id: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	tim@xen.org, donald.d.dugger@intel.com, Paul.Durrant@citrix.com,
	zhiyuan.lv@intel.com, JBeulich@suse.com, yang.z.zhang@intel.com
Subject: [Xen-devel] [PATCH v4] x86: add p2m_mmio_write_dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

XenGT (Intel Graphics Virtualization technology, please refer to
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-
xengt) driver runs inside Dom0 as a virtual graphics device model,
and needs to trap and emulate the guest's write operations to some
specific memory pages, like memory pages used by guest graphics
driver as PPGTT(per-process graphics translation table). We agreed
to add a new p2m type "p2m_mmio_write_dm" to trap the write operation
on these graphic page tables.

Handling of this new p2m type are similar with existing p2m_ram_ro
in most condition checks, with only difference on final policy of
emulation vs. drop. For p2m_mmio_write_dm type pages, writes will
go to the device model via ioreq-server.

Previously, the conclusion in our v3 patch review is to provide a
more generalized HVMOP_map_io_range_to_ioreq_server hypercall, by
seperating rangesets inside a ioreq server to read-protected/write-
protected/both-prtected. Yet, after offline discussion with Paul,
we believe a more simplified solution may suffice. We can keep the
existing HVMOP_map_io_range_to_ioreq_server hypercall, and let the
user decide whether or not a p2m type change is necessary, because
in most cases the emulator will already use the p2m_mmio_dm type.

Changes from v3:
 - Use the existing HVMOP_map_io_range_to_ioreq_server hypercall
   to add write protected range.
 - Modify the HVMOP_set_mem_type hypercall to support the new p2m
   type for this range

Changes from v2:
 - Remove excute attribute of the new p2m type p2m_mmio_write_dm
 - Use existing rangeset for keeping the write protection page range
   instead of introducing hash table.
 - Some code style fix.

Changes from v1:
 - Changes the new p2m type name from p2m_ram_wp to p2m_mmio_write_dm.
   This means that we treat the pages as a special mmio range instead
   of ram.
 - Move macros to c file since only this file is using them.
 - Address various comments from Jan.

Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: Wei Ye <wei.ye@intel.com>
---
 xen/arch/x86/hvm/hvm.c          | 13 ++++++++++---
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/include/asm-x86/p2m.h       |  1 +
 xen/include/public/hvm/hvm_op.h |  1 +
 5 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..5f806e8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2838,7 +2838,8 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
      * to the mmio handler.
      */
     if ( (p2mt == p2m_mmio_dm) || 
-         (npfec.write_access && (p2mt == p2m_ram_ro)) )
+         (npfec.write_access &&
+		((p2mt == p2m_ram_ro) || (p2mt == p2m_mmio_write_dm))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -5922,6 +5923,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
                 a.mem_type =  HVMMEM_ram_rw;
             else if ( p2m_is_grant(t) )
                 a.mem_type =  HVMMEM_ram_rw;
+            else if ( t == p2m_mmio_write_dm )
+                a.mem_type = HVMMEM_mmio_write_dm;
             else
                 a.mem_type =  HVMMEM_mmio_dm;
             rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
@@ -5941,7 +5944,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
         static const p2m_type_t memtype[] = {
             [HVMMEM_ram_rw]  = p2m_ram_rw,
             [HVMMEM_ram_ro]  = p2m_ram_ro,
-            [HVMMEM_mmio_dm] = p2m_mmio_dm
+            [HVMMEM_mmio_dm] = p2m_mmio_dm,
+            [HVMMEM_mmio_write_dm] = p2m_mmio_write_dm
         };
 
         if ( copy_from_guest(&a, arg, 1) )
@@ -5987,14 +5991,17 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
                 rc = -EAGAIN;
                 goto param_fail4;
             }
+
             if ( !p2m_is_ram(t) &&
-                 (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) )
+                 (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
+                 t != p2m_mmio_write_dm )
             {
                 put_gfn(d, pfn);
                 goto param_fail4;
             }
 
             rc = p2m_change_type_one(d, pfn, t, memtype[a.hvmmem_type]);
+
             put_gfn(d, pfn);
             if ( rc )
                 goto param_fail4;
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 15c6e83..e21a92d 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -136,6 +136,7 @@ static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_acces
             entry->x = 0;
             break;
         case p2m_grant_map_ro:
+        case p2m_mmio_write_dm:
             entry->r = 1;
             entry->w = entry->x = 0;
             break;
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index e48b63a..26fb18d 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -94,6 +94,7 @@ static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
     default:
         return flags | _PAGE_NX_BIT;
     case p2m_grant_map_ro:
+    case p2m_mmio_write_dm:
         return flags | P2M_BASE_FLAGS | _PAGE_NX_BIT;
     case p2m_ram_ro:
     case p2m_ram_logdirty:
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..a7a45af 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -72,6 +72,7 @@ typedef enum {
     p2m_ram_shared = 12,          /* Shared or sharable memory */
     p2m_ram_broken = 13,          /* Broken page, access cause domain crash */
     p2m_map_foreign  = 14,        /* ram pages from foreign domain */
+    p2m_mmio_write_dm = 15,       /* Read-only; writes go to the device model */
 } p2m_type_t;
 
 /* Modifiers to the query */
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index eeb0a60..a4e5345 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -81,6 +81,7 @@ typedef enum {
     HVMMEM_ram_rw,             /* Normal read/write guest RAM */
     HVMMEM_ram_ro,             /* Read-only; writes are discarded */
     HVMMEM_mmio_dm,            /* Reads and write go to the device model */
+    HVMMEM_mmio_write_dm       /* Read-only; writes go to the device model */
 } hvmmem_type_t;
 
 /* Following tools-only interfaces may change in future. */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 08:29:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 08: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 1XuGvS-0006ja-IN; Fri, 28 Nov 2014 08:29:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XuGvR-0006jV-Ef
	for Xen-devel@lists.xen.org; Fri, 28 Nov 2014 08:29:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	92/93-25276-85238745; Fri, 28 Nov 2014 08:29:12 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417163350!12028099!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1031 invoked from network); 28 Nov 2014 08:29:11 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-7.tower-21.messagelabs.com with SMTP;
	28 Nov 2014 08:29:11 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 28 Nov 2014 00:21:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="422575789"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by FMSMGA003.fm.intel.com with ESMTP; 28 Nov 2014 00:19:11 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 15:59:12 +0800
Message-Id: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	tim@xen.org, donald.d.dugger@intel.com, Paul.Durrant@citrix.com,
	zhiyuan.lv@intel.com, JBeulich@suse.com, yang.z.zhang@intel.com
Subject: [Xen-devel] [PATCH v4] x86: add p2m_mmio_write_dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

XenGT (Intel Graphics Virtualization technology, please refer to
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-
xengt) driver runs inside Dom0 as a virtual graphics device model,
and needs to trap and emulate the guest's write operations to some
specific memory pages, like memory pages used by guest graphics
driver as PPGTT(per-process graphics translation table). We agreed
to add a new p2m type "p2m_mmio_write_dm" to trap the write operation
on these graphic page tables.

Handling of this new p2m type are similar with existing p2m_ram_ro
in most condition checks, with only difference on final policy of
emulation vs. drop. For p2m_mmio_write_dm type pages, writes will
go to the device model via ioreq-server.

Previously, the conclusion in our v3 patch review is to provide a
more generalized HVMOP_map_io_range_to_ioreq_server hypercall, by
seperating rangesets inside a ioreq server to read-protected/write-
protected/both-prtected. Yet, after offline discussion with Paul,
we believe a more simplified solution may suffice. We can keep the
existing HVMOP_map_io_range_to_ioreq_server hypercall, and let the
user decide whether or not a p2m type change is necessary, because
in most cases the emulator will already use the p2m_mmio_dm type.

Changes from v3:
 - Use the existing HVMOP_map_io_range_to_ioreq_server hypercall
   to add write protected range.
 - Modify the HVMOP_set_mem_type hypercall to support the new p2m
   type for this range

Changes from v2:
 - Remove excute attribute of the new p2m type p2m_mmio_write_dm
 - Use existing rangeset for keeping the write protection page range
   instead of introducing hash table.
 - Some code style fix.

Changes from v1:
 - Changes the new p2m type name from p2m_ram_wp to p2m_mmio_write_dm.
   This means that we treat the pages as a special mmio range instead
   of ram.
 - Move macros to c file since only this file is using them.
 - Address various comments from Jan.

Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: Wei Ye <wei.ye@intel.com>
---
 xen/arch/x86/hvm/hvm.c          | 13 ++++++++++---
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/include/asm-x86/p2m.h       |  1 +
 xen/include/public/hvm/hvm_op.h |  1 +
 5 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..5f806e8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2838,7 +2838,8 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
      * to the mmio handler.
      */
     if ( (p2mt == p2m_mmio_dm) || 
-         (npfec.write_access && (p2mt == p2m_ram_ro)) )
+         (npfec.write_access &&
+		((p2mt == p2m_ram_ro) || (p2mt == p2m_mmio_write_dm))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -5922,6 +5923,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
                 a.mem_type =  HVMMEM_ram_rw;
             else if ( p2m_is_grant(t) )
                 a.mem_type =  HVMMEM_ram_rw;
+            else if ( t == p2m_mmio_write_dm )
+                a.mem_type = HVMMEM_mmio_write_dm;
             else
                 a.mem_type =  HVMMEM_mmio_dm;
             rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
@@ -5941,7 +5944,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
         static const p2m_type_t memtype[] = {
             [HVMMEM_ram_rw]  = p2m_ram_rw,
             [HVMMEM_ram_ro]  = p2m_ram_ro,
-            [HVMMEM_mmio_dm] = p2m_mmio_dm
+            [HVMMEM_mmio_dm] = p2m_mmio_dm,
+            [HVMMEM_mmio_write_dm] = p2m_mmio_write_dm
         };
 
         if ( copy_from_guest(&a, arg, 1) )
@@ -5987,14 +5991,17 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
                 rc = -EAGAIN;
                 goto param_fail4;
             }
+
             if ( !p2m_is_ram(t) &&
-                 (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) )
+                 (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
+                 t != p2m_mmio_write_dm )
             {
                 put_gfn(d, pfn);
                 goto param_fail4;
             }
 
             rc = p2m_change_type_one(d, pfn, t, memtype[a.hvmmem_type]);
+
             put_gfn(d, pfn);
             if ( rc )
                 goto param_fail4;
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 15c6e83..e21a92d 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -136,6 +136,7 @@ static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_acces
             entry->x = 0;
             break;
         case p2m_grant_map_ro:
+        case p2m_mmio_write_dm:
             entry->r = 1;
             entry->w = entry->x = 0;
             break;
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index e48b63a..26fb18d 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -94,6 +94,7 @@ static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
     default:
         return flags | _PAGE_NX_BIT;
     case p2m_grant_map_ro:
+    case p2m_mmio_write_dm:
         return flags | P2M_BASE_FLAGS | _PAGE_NX_BIT;
     case p2m_ram_ro:
     case p2m_ram_logdirty:
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..a7a45af 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -72,6 +72,7 @@ typedef enum {
     p2m_ram_shared = 12,          /* Shared or sharable memory */
     p2m_ram_broken = 13,          /* Broken page, access cause domain crash */
     p2m_map_foreign  = 14,        /* ram pages from foreign domain */
+    p2m_mmio_write_dm = 15,       /* Read-only; writes go to the device model */
 } p2m_type_t;
 
 /* Modifiers to the query */
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index eeb0a60..a4e5345 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -81,6 +81,7 @@ typedef enum {
     HVMMEM_ram_rw,             /* Normal read/write guest RAM */
     HVMMEM_ram_ro,             /* Read-only; writes are discarded */
     HVMMEM_mmio_dm,            /* Reads and write go to the device model */
+    HVMMEM_mmio_write_dm       /* Read-only; writes go to the device model */
 } hvmmem_type_t;
 
 /* Following tools-only interfaces may change in future. */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 08:32:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 08:32:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGyl-00075q-Rv; Fri, 28 Nov 2014 08:32:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XuGyk-00075i-Rr
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 08:32:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6D/E8-25276-62338745; Fri, 28 Nov 2014 08:32:38 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417163557!11990168!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6722 invoked from network); 28 Nov 2014 08:32:37 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 08:32:37 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAS8WJF9024915;
	Fri, 28 Nov 2014 08:32:24 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAS8W90i005844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Nov 2014 08:32:09 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.5+Sun/8.11.1) with ESMTP id sAS8W9xo001367;
	Fri, 28 Nov 2014 08:32:09 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.5+Sun/8.14.5/Submit) with ESMTP id
	sAS8W9eT001364; Fri, 28 Nov 2014 08:32:09 GMT
Date: Fri, 28 Nov 2014 08:32:09 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417163231.2372.10.camel@citrix.com>
Message-ID: <alpine.GSO.2.00.1411280830170.1345@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411272342370.5756@procyon.dur.ac.uk>
	<1417163231.2372.10.camel@citrix.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-351212254-1417163529=:1345"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAS8WJF9024915
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] fix migration failure with xl migrate
	--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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-351212254-1417163529=:1345
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 28 Nov 2014, Ian Campbell wrote:

> On Fri, 2014-11-28 at 00:28 +0000, M A Young wrote:
>> Migrations with xl migrate --debug will fail because debugging information
>> from the receiving process is written to the stdout channel. This channel
>> is also used for status messages so the migration will fail as the sending
>> process receives an unexpected message. This patch moves the debugging
>> information to the stderr channel.
>>
>> Version 2 moves some output back to stdout that was accidentally moved
>> to stderr in the first version.
>>
>> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
>
> I think you've forgotten the attachment.

Yes, I did. Here it is.
---559023410-351212254-1417163529=:1345
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xl.migrate.debug.fail.patch
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.GSO.2.00.1411280832090.1345@algedi.dur.ac.uk>
Content-Description: 
Content-Disposition: attachment; filename=xl.migrate.debug.fail.patch

VXNlIHN0ZGVyciBmb3IgZGVidWdnaW5nIG1lc3NhZ2VzIGZvciB4bCBtaWdy
YXRlIC0tZGVidWcgYXMgc3Rkb3V0IGlzIHVzZWQNCmZvciBzdGF0dXMgbWVz
c2FnZXMuDQoNCi0tLSB4ZW4tNC41LjAtcmMxL3Rvb2xzL2xpYnhsL3hsX2Nt
ZGltcGwuYy5vcmlnCTIwMTQtMTAtMjQgMTU6MjI6NDAuMDAwMDAwMDAwICsw
MTAwDQorKysgeGVuLTQuNS4wLXJjMS90b29scy9saWJ4bC94bF9jbWRpbXBs
LmMJMjAxNC0xMS0yNiAyMjo0MTo0MS42OTcwNDMzMjEgKzAwMDANCkBAIC0z
ODAsMTAgKzM4MCwxMCBAQA0KIH0NCiBzdGF0aWMgdm9pZCBwcmludGZfaW5m
byhlbnVtIG91dHB1dF9mb3JtYXQgb3V0cHV0X2Zvcm1hdCwNCiAgICAgICAg
ICAgICAgICAgICAgICAgICBpbnQgZG9taWQsDQotICAgICAgICAgICAgICAg
ICAgICAgICAgbGlieGxfZG9tYWluX2NvbmZpZyAqZF9jb25maWcpDQorICAg
ICAgICAgICAgICAgICAgICAgICAgbGlieGxfZG9tYWluX2NvbmZpZyAqZF9j
b25maWcsIEZJTEUgKmZoKQ0KIHsNCiAgICAgaWYgKG91dHB1dF9mb3JtYXQg
PT0gT1VUUFVUX0ZPUk1BVF9TWFApDQotICAgICAgICByZXR1cm4gcHJpbnRm
X2luZm9fc2V4cChkb21pZCwgZF9jb25maWcpOw0KKyAgICAgICAgcmV0dXJu
IHByaW50Zl9pbmZvX3NleHAoZG9taWQsIGRfY29uZmlnLCBmaCk7DQogDQog
ICAgIGNvbnN0IGNoYXIgKmJ1ZjsNCiAgICAgbGlieGxfeWFqbF9sZW5ndGgg
bGVuID0gMDsNCkBAIC00MDQsNyArNDA0LDcgQEANCiAgICAgaWYgKHMgIT0g
eWFqbF9nZW5fc3RhdHVzX29rKQ0KICAgICAgICAgZ290byBvdXQ7DQogDQot
ICAgIHB1dHMoYnVmKTsNCisgICAgZnB1dHMoYnVmLCBmaCk7DQogDQogb3V0
Og0KICAgICB5YWpsX2dlbl9mcmVlKGhhbmQpOw0KQEAgLTQxMyw3ICs0MTMs
MTMgQEANCiAgICAgICAgIGZwcmludGYoc3RkZXJyLA0KICAgICAgICAgICAg
ICAgICAidW5hYmxlIHRvIGZvcm1hdCBkb21haW4gY29uZmlnIGFzIEpTT04g
KFlBSkw6JWQpXG4iLCBzKTsNCiANCi0gICAgaWYgKGZlcnJvcihzdGRvdXQp
IHx8IGZmbHVzaChzdGRvdXQpKSB7IHBlcnJvcigic3Rkb3V0Iik7IGV4aXQo
LTEpOyB9DQorICAgIGlmIChmZXJyb3IoZmgpIHx8IGZmbHVzaChmaCkpIHsN
CisgICAgICAgIGlmIChmaCA9PSBzdGRvdXQpDQorICAgICAgICAgICAgcGVy
cm9yKCJzdGRvdXQiKTsNCisgICAgICAgIGVsc2UNCisgICAgICAgICAgICBw
ZXJyb3IoInN0ZGVyciIpOw0KKyAgICAgICAgZXhpdCgtMSk7DQorICAgIH0N
CiB9DQogDQogc3RhdGljIGludCBkb19kYWVtb25pemUoY2hhciAqbmFtZSkN
CkBAIC0yNDIzLDcgKzI0MjksNyBAQA0KICAgICB9DQogDQogICAgIGlmICgh
ZG9tX2luZm8tPnF1aWV0KQ0KLSAgICAgICAgcHJpbnRmKCJQYXJzaW5nIGNv
bmZpZyBmcm9tICVzXG4iLCBjb25maWdfc291cmNlKTsNCisgICAgICAgIGZw
cmludGYoc3RkZXJyLCAiUGFyc2luZyBjb25maWcgZnJvbSAlc1xuIiwgY29u
ZmlnX3NvdXJjZSk7DQogDQogICAgIGlmIChjb25maWdfaW5fanNvbikgew0K
ICAgICAgICAgbGlieGxfZG9tYWluX2NvbmZpZ19mcm9tX2pzb24oY3R4LCAm
ZF9jb25maWcsDQpAQCAtMjQ1MSw3ICsyNDU3LDcgQEANCiAgICAgfQ0KIA0K
ICAgICBpZiAoZGVidWcgfHwgZG9tX2luZm8tPmRyeXJ1bikNCi0gICAgICAg
IHByaW50Zl9pbmZvKGRlZmF1bHRfb3V0cHV0X2Zvcm1hdCwgLTEsICZkX2Nv
bmZpZyk7DQorICAgICAgICBwcmludGZfaW5mbyhkZWZhdWx0X291dHB1dF9m
b3JtYXQsIC0xLCAmZF9jb25maWcsIHN0ZGVycik7DQogDQogICAgIHJldCA9
IDA7DQogICAgIGlmIChkb21faW5mby0+ZHJ5cnVuKQ0KQEAgLTM0MDMsNyAr
MzQwOSw3IEBADQogICAgICAgICBpZiAoZGVmYXVsdF9vdXRwdXRfZm9ybWF0
ID09IE9VVFBVVF9GT1JNQVRfSlNPTikNCiAgICAgICAgICAgICBzID0gcHJp
bnRmX2luZm9fb25lX2pzb24oaGFuZCwgaW5mb1tpXS5kb21pZCwgJmRfY29u
ZmlnKTsNCiAgICAgICAgIGVsc2UNCi0gICAgICAgICAgICBwcmludGZfaW5m
b19zZXhwKGluZm9baV0uZG9taWQsICZkX2NvbmZpZyk7DQorICAgICAgICAg
ICAgcHJpbnRmX2luZm9fc2V4cChpbmZvW2ldLmRvbWlkLCAmZF9jb25maWcs
IHN0ZG91dCk7DQogICAgICAgICBsaWJ4bF9kb21haW5fY29uZmlnX2Rpc3Bv
c2UoJmRfY29uZmlnKTsNCiAgICAgICAgIGlmIChzICE9IHlhamxfZ2VuX3N0
YXR1c19vaykNCiAgICAgICAgICAgICBnb3RvIG91dDsNCkBAIC00NzI1LDcg
KzQ3MzEsNyBAQA0KICAgICBwYXJzZV9jb25maWdfZGF0YShmaWxlbmFtZSwg
Y29uZmlnX2RhdGEsIGNvbmZpZ19sZW4sICZkX2NvbmZpZyk7DQogDQogICAg
IGlmIChkZWJ1ZyB8fCBkcnlydW5fb25seSkNCi0gICAgICAgIHByaW50Zl9p
bmZvKGRlZmF1bHRfb3V0cHV0X2Zvcm1hdCwgLTEsICZkX2NvbmZpZyk7DQor
ICAgICAgICBwcmludGZfaW5mbyhkZWZhdWx0X291dHB1dF9mb3JtYXQsIC0x
LCAmZF9jb25maWcsIHN0ZG91dCk7DQogDQogICAgIGlmICghZHJ5cnVuX29u
bHkpIHsNCiAgICAgICAgIGZwcmludGYoc3RkZXJyLCAic2V0dGluZyBkb20l
ZCBjb25maWd1cmF0aW9uXG4iLCBkb21pZCk7DQotLS0geGVuLTQuNS4wLXJj
MS90b29scy9saWJ4bC94bF9zeHAuYy5vcmlnCTIwMTQtMTAtMjQgMTU6MjI6
NDAuMDAwMDAwMDAwICswMTAwDQorKysgeGVuLTQuNS4wLXJjMS90b29scy9s
aWJ4bC94bF9zeHAuYwkyMDE0LTExLTI2IDIyOjMwOjU4LjQxNjM5NDA4MiAr
MDAwMA0KQEAgLTMwLDcgKzMwLDcgQEANCiAvKiBJbiBnZW5lcmFsIHlvdSBz
aG91bGQgbm90IGFkZCBuZXcgb3V0cHV0IHRvIHRoaXMgZnVuY3Rpb24gc2lu
Y2UgaXQNCiAgKiBpcyBpbnRlbmRlZCBvbmx5IGZvciBsZWdhY3kgdXNlLg0K
ICAqLw0KLXZvaWQgcHJpbnRmX2luZm9fc2V4cChpbnQgZG9taWQsIGxpYnhs
X2RvbWFpbl9jb25maWcgKmRfY29uZmlnKQ0KK3ZvaWQgcHJpbnRmX2luZm9f
c2V4cChpbnQgZG9taWQsIGxpYnhsX2RvbWFpbl9jb25maWcgKmRfY29uZmln
LCBGSUxFICpmaCkNCiB7DQogICAgIGludCBpOw0KICAgICBsaWJ4bF9kb21p
bmZvIGluZm87DQpAQCAtMzgsMTk1ICszOCwxOTUgQEANCiAgICAgbGlieGxf
ZG9tYWluX2NyZWF0ZV9pbmZvICpjX2luZm8gPSAmZF9jb25maWctPmNfaW5m
bzsNCiAgICAgbGlieGxfZG9tYWluX2J1aWxkX2luZm8gKmJfaW5mbyA9ICZk
X2NvbmZpZy0+Yl9pbmZvOw0KIA0KLSAgICBwcmludGYoIihkb21haW5cblx0
KGRvbWlkICVkKVxuIiwgZG9taWQpOw0KLSAgICBwcmludGYoIlx0KGNyZWF0
ZV9pbmZvKVxuIik7DQotICAgIHByaW50ZigiXHQoaHZtICVkKVxuIiwgY19p
bmZvLT50eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX0hWTSk7DQotICAgIHBy
aW50ZigiXHQoaGFwICVzKVxuIiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmco
Y19pbmZvLT5oYXApKTsNCi0gICAgcHJpbnRmKCJcdChvb3MgJXMpXG4iLCBs
aWJ4bF9kZWZib29sX3RvX3N0cmluZyhjX2luZm8tPm9vcykpOw0KLSAgICBw
cmludGYoIlx0KHNzaWRyZWYgJWQpXG4iLCBjX2luZm8tPnNzaWRyZWYpOw0K
LSAgICBwcmludGYoIlx0KG5hbWUgJXMpXG4iLCBjX2luZm8tPm5hbWUpOw0K
KyAgICBmcHJpbnRmKGZoLCAiKGRvbWFpblxuXHQoZG9taWQgJWQpXG4iLCBk
b21pZCk7DQorICAgIGZwcmludGYoZmgsICJcdChjcmVhdGVfaW5mbylcbiIp
Ow0KKyAgICBmcHJpbnRmKGZoLCAiXHQoaHZtICVkKVxuIiwgY19pbmZvLT50
eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX0hWTSk7DQorICAgIGZwcmludGYo
ZmgsICJcdChoYXAgJXMpXG4iLCBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhj
X2luZm8tPmhhcCkpOw0KKyAgICBmcHJpbnRmKGZoLCAiXHQob29zICVzKVxu
IiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoY19pbmZvLT5vb3MpKTsNCisg
ICAgZnByaW50ZihmaCwgIlx0KHNzaWRyZWYgJWQpXG4iLCBjX2luZm8tPnNz
aWRyZWYpOw0KKyAgICBmcHJpbnRmKGZoLCAiXHQobmFtZSAlcylcbiIsIGNf
aW5mby0+bmFtZSk7DQogDQogICAgIC8qIHJldHJpZXZlIHRoZSBVVUlEIGZy
b20gZG9taW5mbywgc2luY2UgaXQgaXMgcHJvYmFibHkgZ2VuZXJhdGVkDQog
ICAgICAqIGR1cmluZyBwYXJzaW5nIGFuZCB0aHVzIGRvZXMgbm90IG1hdGNo
IHRoZSByZWFsIG9uZQ0KICAgICAgKi8NCiAgICAgaWYgKGxpYnhsX2RvbWFp
bl9pbmZvKGN0eCwgJmluZm8sIGRvbWlkKSA9PSAwKSB7DQotICAgICAgICBw
cmludGYoIlx0KHV1aWQgIiBMSUJYTF9VVUlEX0ZNVCAiKVxuIiwgTElCWExf
VVVJRF9CWVRFUyhpbmZvLnV1aWQpKTsNCisgICAgICAgIGZwcmludGYoZmgs
ICJcdCh1dWlkICIgTElCWExfVVVJRF9GTVQgIilcbiIsIExJQlhMX1VVSURf
QllURVMoaW5mby51dWlkKSk7DQogICAgIH0gZWxzZSB7DQotICAgICAgICBw
cmludGYoIlx0KHV1aWQgPHVua25vd24+KVxuIik7DQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHQodXVpZCA8dW5rbm93bj4pXG4iKTsNCiAgICAgfQ0KICAg
ICBpZiAoY19pbmZvLT5wb29sX25hbWUpDQotICAgICAgICBwcmludGYoIlx0
KGNwdXBvb2wgJXMpXG4iLCBjX2luZm8tPnBvb2xfbmFtZSk7DQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHQoY3B1cG9vbCAlcylcbiIsIGNfaW5mby0+cG9v
bF9uYW1lKTsNCiAgICAgaWYgKGNfaW5mby0+eHNkYXRhKQ0KLSAgICAgICAg
cHJpbnRmKCJcdCh4c2RhdGEgY29udGFpbnMgZGF0YSlcbiIpOw0KKyAgICAg
ICAgZnByaW50ZihmaCwgIlx0KHhzZGF0YSBjb250YWlucyBkYXRhKVxuIik7
DQogICAgIGVsc2UNCi0gICAgICAgIHByaW50ZigiXHQoeHNkYXRhIChudWxs
KSlcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0KHhzZGF0YSAobnVs
bCkpXG4iKTsNCiAgICAgaWYgKGNfaW5mby0+cGxhdGZvcm1kYXRhKQ0KLSAg
ICAgICAgcHJpbnRmKCJcdChwbGF0Zm9ybWRhdGEgY29udGFpbnMgZGF0YSlc
biIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0KHBsYXRmb3JtZGF0YSBj
b250YWlucyBkYXRhKVxuIik7DQogICAgIGVsc2UNCi0gICAgICAgIHByaW50
ZigiXHQocGxhdGZvcm1kYXRhIChudWxsKSlcbiIpOw0KKyAgICAgICAgZnBy
aW50ZihmaCwgIlx0KHBsYXRmb3JtZGF0YSAobnVsbCkpXG4iKTsNCiANCiAN
Ci0gICAgcHJpbnRmKCJcdChidWlsZF9pbmZvKVxuIik7DQotICAgIHByaW50
ZigiXHQobWF4X3ZjcHVzICVkKVxuIiwgYl9pbmZvLT5tYXhfdmNwdXMpOw0K
LSAgICBwcmludGYoIlx0KHRzY19tb2RlICVzKVxuIiwgbGlieGxfdHNjX21v
ZGVfdG9fc3RyaW5nKGJfaW5mby0+dHNjX21vZGUpKTsNCi0gICAgcHJpbnRm
KCJcdChtYXhfbWVta2IgJSJQUklkNjQiKVxuIiwgYl9pbmZvLT5tYXhfbWVt
a2IpOw0KLSAgICBwcmludGYoIlx0KHRhcmdldF9tZW1rYiAlIlBSSWQ2NCIp
XG4iLCBiX2luZm8tPnRhcmdldF9tZW1rYik7DQotICAgIHByaW50ZigiXHQo
bm9taWdyYXRlICVzKVxuIiwNCisgICAgZnByaW50ZihmaCwgIlx0KGJ1aWxk
X2luZm8pXG4iKTsNCisgICAgZnByaW50ZihmaCwgIlx0KG1heF92Y3B1cyAl
ZClcbiIsIGJfaW5mby0+bWF4X3ZjcHVzKTsNCisgICAgZnByaW50ZihmaCwg
Ilx0KHRzY19tb2RlICVzKVxuIiwgbGlieGxfdHNjX21vZGVfdG9fc3RyaW5n
KGJfaW5mby0+dHNjX21vZGUpKTsNCisgICAgZnByaW50ZihmaCwgIlx0KG1h
eF9tZW1rYiAlIlBSSWQ2NCIpXG4iLCBiX2luZm8tPm1heF9tZW1rYik7DQor
ICAgIGZwcmludGYoZmgsICJcdCh0YXJnZXRfbWVta2IgJSJQUklkNjQiKVxu
IiwgYl9pbmZvLT50YXJnZXRfbWVta2IpOw0KKyAgICBmcHJpbnRmKGZoLCAi
XHQobm9taWdyYXRlICVzKVxuIiwNCiAgICAgICAgICAgIGxpYnhsX2RlZmJv
b2xfdG9fc3RyaW5nKGJfaW5mby0+ZGlzYWJsZV9taWdyYXRlKSk7DQogDQog
ICAgIGlmIChjX2luZm8tPnR5cGUgPT0gTElCWExfRE9NQUlOX1RZUEVfUFYg
JiYgYl9pbmZvLT51LnB2LmJvb3Rsb2FkZXIpIHsNCi0gICAgICAgIHByaW50
ZigiXHQoYm9vdGxvYWRlciAlcylcbiIsIGJfaW5mby0+dS5wdi5ib290bG9h
ZGVyKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdChib290bG9hZGVyICVz
KVxuIiwgYl9pbmZvLT51LnB2LmJvb3Rsb2FkZXIpOw0KICAgICAgICAgaWYg
KGJfaW5mby0+dS5wdi5ib290bG9hZGVyX2FyZ3MpIHsNCi0gICAgICAgICAg
ICBwcmludGYoIlx0KGJvb3Rsb2FkZXJfYXJncyIpOw0KKyAgICAgICAgICAg
IGZwcmludGYoZmgsICJcdChib290bG9hZGVyX2FyZ3MiKTsNCiAgICAgICAg
ICAgICBmb3IgKGk9MDsgYl9pbmZvLT51LnB2LmJvb3Rsb2FkZXJfYXJnc1tp
XTsgaSsrKQ0KLSAgICAgICAgICAgICAgICBwcmludGYoIiAlcyIsIGJfaW5m
by0+dS5wdi5ib290bG9hZGVyX2FyZ3NbaV0pOw0KLSAgICAgICAgICAgIHBy
aW50ZigiKVxuIik7DQorICAgICAgICAgICAgICAgIGZwcmludGYoZmgsICIg
JXMiLCBiX2luZm8tPnUucHYuYm9vdGxvYWRlcl9hcmdzW2ldKTsNCisgICAg
ICAgICAgICBmcHJpbnRmKGZoLCAiKVxuIik7DQogICAgICAgICB9DQogICAg
IH0NCiANCi0gICAgcHJpbnRmKCJcdChpbWFnZVxuIik7DQorICAgIGZwcmlu
dGYoZmgsICJcdChpbWFnZVxuIik7DQogICAgIHN3aXRjaCAoY19pbmZvLT50
eXBlKSB7DQogICAgIGNhc2UgTElCWExfRE9NQUlOX1RZUEVfSFZNOg0KLSAg
ICAgICAgcHJpbnRmKCJcdFx0KGh2bVxuIik7DQotICAgICAgICBwcmludGYo
Ilx0XHRcdChmaXJtd2FyZSAlcylcbiIsIGJfaW5mby0+dS5odm0uZmlybXdh
cmUpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodmlkZW9fbWVta2IgJSJQ
UklkNjQiKVxuIiwgYl9pbmZvLT52aWRlb19tZW1rYik7DQotICAgICAgICBw
cmludGYoIlx0XHRcdChzaGFkb3dfbWVta2IgJSJQUklkNjQiKVxuIiwgYl9p
bmZvLT5zaGFkb3dfbWVta2IpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQo
cGFlICVzKVxuIiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51
Lmh2bS5wYWUpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGFwaWMgJXMp
XG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQoaHZtXG4iKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoZmlybXdhcmUgJXMpXG4iLCBi
X2luZm8tPnUuaHZtLmZpcm13YXJlKTsNCisgICAgICAgIGZwcmludGYoZmgs
ICJcdFx0XHQodmlkZW9fbWVta2IgJSJQUklkNjQiKVxuIiwgYl9pbmZvLT52
aWRlb19tZW1rYik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHNo
YWRvd19tZW1rYiAlIlBSSWQ2NCIpXG4iLCBiX2luZm8tPnNoYWRvd19tZW1r
Yik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHBhZSAlcylcbiIs
IGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0ucGFlKSk7
DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGFwaWMgJXMpXG4iLA0K
ICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5m
by0+dS5odm0uYXBpYykpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoYWNw
aSAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGFjcGkg
JXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3Ry
aW5nKGJfaW5mby0+dS5odm0uYWNwaSkpOw0KLSAgICAgICAgcHJpbnRmKCJc
dFx0XHQobnggJXMpXG4iLCBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2lu
Zm8tPnUuaHZtLm54KSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdCh2aXJp
ZGlhbiAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KG54
ICVzKVxuIiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2
bS5ueCkpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh2aXJpZGlh
biAlcylcbiIsDQogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19z
dHJpbmcoYl9pbmZvLT51Lmh2bS52aXJpZGlhbikpOw0KLSAgICAgICAgcHJp
bnRmKCJcdFx0XHQoaHBldCAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZo
LCAiXHRcdFx0KGhwZXQgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhs
X2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0uaHBldCkpOw0KLSAg
ICAgICAgcHJpbnRmKCJcdFx0XHQodnB0X2FsaWduICVzKVxuIiwNCisgICAg
ICAgIGZwcmludGYoZmgsICJcdFx0XHQodnB0X2FsaWduICVzKVxuIiwNCiAg
ICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8t
PnUuaHZtLnZwdF9hbGlnbikpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQo
dGltZXJfbW9kZSAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRc
dFx0KHRpbWVyX21vZGUgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhs
X3RpbWVyX21vZGVfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0udGltZXJfbW9k
ZSkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQobmVzdGVkaHZtICVzKVxu
IiwNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQobmVzdGVkaHZtICVz
KVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmlu
ZyhiX2luZm8tPnUuaHZtLm5lc3RlZF9odm0pKTsNCi0gICAgICAgIHByaW50
ZigiXHRcdFx0KHN0ZHZnYSAlcylcbiIsIGJfaW5mby0+dS5odm0udmdhLmtp
bmQgPT0NCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoc3RkdmdhICVz
KVxuIiwgYl9pbmZvLT51Lmh2bS52Z2Eua2luZCA9PQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgTElCWExfVkdBX0lOVEVSRkFD
RV9UWVBFX1NURCA/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAiVHJ1ZSIgOiAiRmFsc2UiKTsNCi0gICAgICAgIHByaW50Zigi
XHRcdFx0KHZuYyAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRc
dFx0KHZuYyAlcylcbiIsDQogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9v
bF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS52bmMuZW5hYmxlKSk7DQotICAg
ICAgICBwcmludGYoIlx0XHRcdCh2bmNsaXN0ZW4gJXMpXG4iLCBiX2luZm8t
PnUuaHZtLnZuYy5saXN0ZW4pOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQo
dm5jZGlzcGxheSAlZClcbiIsIGJfaW5mby0+dS5odm0udm5jLmRpc3BsYXkp
Ow0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodm5jdW51c2VkICVzKVxuIiwN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQodm5jbGlzdGVuICVzKVxu
IiwgYl9pbmZvLT51Lmh2bS52bmMubGlzdGVuKTsNCisgICAgICAgIGZwcmlu
dGYoZmgsICJcdFx0XHQodm5jZGlzcGxheSAlZClcbiIsIGJfaW5mby0+dS5o
dm0udm5jLmRpc3BsYXkpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRc
dCh2bmN1bnVzZWQgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2Rl
ZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0udm5jLmZpbmR1bnVzZWQp
KTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGtleW1hcCAlcylcbiIsIGJf
aW5mby0+dS5odm0ua2V5bWFwKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0
KHNkbCAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGtl
eW1hcCAlcylcbiIsIGJfaW5mby0+dS5odm0ua2V5bWFwKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdFx0XHQoc2RsICVzKVxuIiwNCiAgICAgICAgICAg
ICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnNk
bC5lbmFibGUpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KG9wZW5nbCAl
cylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KG9wZW5nbCAl
cylcbiIsDQogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJp
bmcoYl9pbmZvLT51Lmh2bS5zZGwub3BlbmdsKSk7DQotICAgICAgICBwcmlu
dGYoIlx0XHRcdChub2dyYXBoaWMgJXMpXG4iLA0KKyAgICAgICAgZnByaW50
ZihmaCwgIlx0XHRcdChub2dyYXBoaWMgJXMpXG4iLA0KICAgICAgICAgICAg
ICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0ubm9n
cmFwaGljKSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChzcGljZSAlcylc
biIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHNwaWNlICVzKVxu
IiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhi
X2luZm8tPnUuaHZtLnNwaWNlLmVuYWJsZSkpOw0KLSAgICAgICAgcHJpbnRm
KCJcdFx0XHQoc3BpY2Vwb3J0ICVkKVxuIiwgYl9pbmZvLT51Lmh2bS5zcGlj
ZS5wb3J0KTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHNwaWNldGxzX3Bv
cnQgJWQpXG4iLCBiX2luZm8tPnUuaHZtLnNwaWNlLnRsc19wb3J0KTsNCi0g
ICAgICAgIHByaW50ZigiXHRcdFx0KHNwaWNlaG9zdCAlcylcbiIsIGJfaW5m
by0+dS5odm0uc3BpY2UuaG9zdCk7DQotICAgICAgICBwcmludGYoIlx0XHRc
dChzcGljZWRpc2FibGVfdGlja2V0aW5nICVzKVxuIiwNCisgICAgICAgIGZw
cmludGYoZmgsICJcdFx0XHQoc3BpY2Vwb3J0ICVkKVxuIiwgYl9pbmZvLT51
Lmh2bS5zcGljZS5wb3J0KTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0
XHQoc3BpY2V0bHNfcG9ydCAlZClcbiIsIGJfaW5mby0+dS5odm0uc3BpY2Uu
dGxzX3BvcnQpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzcGlj
ZWhvc3QgJXMpXG4iLCBiX2luZm8tPnUuaHZtLnNwaWNlLmhvc3QpOw0KKyAg
ICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzcGljZWRpc2FibGVfdGlja2V0
aW5nICVzKVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3Rv
X3N0cmluZyhiX2luZm8tPnUuaHZtLnNwaWNlLmRpc2FibGVfdGlja2V0aW5n
KSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChzcGljZWFnZW50X21vdXNl
ICVzKVxuIiwNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoc3BpY2Vh
Z2VudF9tb3VzZSAlcylcbiIsDQogICAgICAgICAgICAgICAgbGlieGxfZGVm
Ym9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS5zcGljZS5hZ2VudF9tb3Vz
ZSkpOw0KIA0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoZGV2aWNlX21vZGVs
ICVzKVxuIiwgYl9pbmZvLT5kZXZpY2VfbW9kZWwgPyA6ICJkZWZhdWx0Iik7
DQotICAgICAgICBwcmludGYoIlx0XHRcdChnZnhfcGFzc3RocnUgJXMpXG4i
LA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChkZXZpY2VfbW9kZWwg
JXMpXG4iLCBiX2luZm8tPmRldmljZV9tb2RlbCA/IDogImRlZmF1bHQiKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoZ2Z4X3Bhc3N0aHJ1ICVz
KVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmlu
ZyhiX2luZm8tPnUuaHZtLmdmeF9wYXNzdGhydSkpOw0KLSAgICAgICAgcHJp
bnRmKCJcdFx0XHQoc2VyaWFsICVzKVxuIiwgYl9pbmZvLT51Lmh2bS5zZXJp
YWwpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoYm9vdCAlcylcbiIsIGJf
aW5mby0+dS5odm0uYm9vdCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdCh1
c2IgJXMpXG4iLCBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUu
aHZtLnVzYikpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodXNiZGV2aWNl
ICVzKVxuIiwgYl9pbmZvLT51Lmh2bS51c2JkZXZpY2UpOw0KLSAgICAgICAg
cHJpbnRmKCJcdFx0KVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRc
dFx0KHNlcmlhbCAlcylcbiIsIGJfaW5mby0+dS5odm0uc2VyaWFsKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoYm9vdCAlcylcbiIsIGJfaW5m
by0+dS5odm0uYm9vdCk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0
KHVzYiAlcylcbiIsIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+
dS5odm0udXNiKSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHVz
YmRldmljZSAlcylcbiIsIGJfaW5mby0+dS5odm0udXNiZGV2aWNlKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0KVxuIik7DQogICAgICAgICBicmVh
azsNCiAgICAgY2FzZSBMSUJYTF9ET01BSU5fVFlQRV9QVjoNCi0gICAgICAg
IHByaW50ZigiXHRcdChsaW51eCAlZClcbiIsIDApOw0KLSAgICAgICAgcHJp
bnRmKCJcdFx0XHQoa2VybmVsICVzKVxuIiwgYl9pbmZvLT5rZXJuZWwpOw0K
LSAgICAgICAgcHJpbnRmKCJcdFx0XHQoY21kbGluZSAlcylcbiIsIGJfaW5m
by0+Y21kbGluZSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChyYW1kaXNr
ICVzKVxuIiwgYl9pbmZvLT5yYW1kaXNrKTsNCi0gICAgICAgIHByaW50Zigi
XHRcdFx0KGU4MjBfaG9zdCAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZo
LCAiXHRcdChsaW51eCAlZClcbiIsIDApOw0KKyAgICAgICAgZnByaW50Zihm
aCwgIlx0XHRcdChrZXJuZWwgJXMpXG4iLCBiX2luZm8tPmtlcm5lbCk7DQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGNtZGxpbmUgJXMpXG4iLCBi
X2luZm8tPmNtZGxpbmUpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRc
dChyYW1kaXNrICVzKVxuIiwgYl9pbmZvLT5yYW1kaXNrKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdFx0XHQoZTgyMF9ob3N0ICVzKVxuIiwNCiAgICAg
ICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUu
cHYuZTgyMF9ob3N0KSk7DQotICAgICAgICBwcmludGYoIlx0XHQpXG4iKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0KVxuIik7DQogICAgICAgICBi
cmVhazsNCiAgICAgZGVmYXVsdDoNCiAgICAgICAgIGZwcmludGYoc3RkZXJy
LCAiVW5rbm93biBkb21haW4gdHlwZSAlZFxuIiwgY19pbmZvLT50eXBlKTsN
CiAgICAgICAgIGV4aXQoMSk7DQogICAgIH0NCi0gICAgcHJpbnRmKCJcdClc
biIpOw0KKyAgICBmcHJpbnRmKGZoLCAiXHQpXG4iKTsNCiANCiAgICAgZm9y
IChpID0gMDsgaSA8IGRfY29uZmlnLT5udW1fZGlza3M7IGkrKykgew0KLSAg
ICAgICAgcHJpbnRmKCJcdChkZXZpY2VcbiIpOw0KLSAgICAgICAgcHJpbnRm
KCJcdFx0KHRhcFxuIik7DQotICAgICAgICBwcmludGYoIlx0XHRcdChiYWNr
ZW5kX2RvbWlkICVkKVxuIiwgZF9jb25maWctPmRpc2tzW2ldLmJhY2tlbmRf
ZG9taWQpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoZnJvbnRlbmRfZG9t
aWQgJWQpXG4iLCBkb21pZCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChw
aHlzcGF0aCAlcylcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS5wZGV2X3BhdGgp
Ow0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQocGh5c3R5cGUgJWQpXG4iLCBk
X2NvbmZpZy0+ZGlza3NbaV0uYmFja2VuZCk7DQotICAgICAgICBwcmludGYo
Ilx0XHRcdCh2aXJ0cGF0aCAlcylcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS52
ZGV2KTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHVucGx1Z2dhYmxlICVk
KVxuIiwgZF9jb25maWctPmRpc2tzW2ldLnJlbW92YWJsZSk7DQotICAgICAg
ICBwcmludGYoIlx0XHRcdChyZWFkd3JpdGUgJWQpXG4iLCBkX2NvbmZpZy0+
ZGlza3NbaV0ucmVhZHdyaXRlKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0
KGlzX2Nkcm9tICVkKVxuIiwgZF9jb25maWctPmRpc2tzW2ldLmlzX2Nkcm9t
KTsNCi0gICAgICAgIHByaW50ZigiXHRcdClcbiIpOw0KLSAgICAgICAgcHJp
bnRmKCJcdClcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0KGRldmlj
ZVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdCh0YXBcbiIpOw0K
KyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChiYWNrZW5kX2RvbWlkICVk
KVxuIiwgZF9jb25maWctPmRpc2tzW2ldLmJhY2tlbmRfZG9taWQpOw0KKyAg
ICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChmcm9udGVuZF9kb21pZCAlZClc
biIsIGRvbWlkKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQocGh5
c3BhdGggJXMpXG4iLCBkX2NvbmZpZy0+ZGlza3NbaV0ucGRldl9wYXRoKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQocGh5c3R5cGUgJWQpXG4i
LCBkX2NvbmZpZy0+ZGlza3NbaV0uYmFja2VuZCk7DQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHRcdFx0KHZpcnRwYXRoICVzKVxuIiwgZF9jb25maWctPmRp
c2tzW2ldLnZkZXYpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh1
bnBsdWdnYWJsZSAlZClcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS5yZW1vdmFi
bGUpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChyZWFkd3JpdGUg
JWQpXG4iLCBkX2NvbmZpZy0+ZGlza3NbaV0ucmVhZHdyaXRlKTsNCisgICAg
ICAgIGZwcmludGYoZmgsICJcdFx0XHQoaXNfY2Ryb20gJWQpXG4iLCBkX2Nv
bmZpZy0+ZGlza3NbaV0uaXNfY2Ryb20pOw0KKyAgICAgICAgZnByaW50Zihm
aCwgIlx0XHQpXG4iKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdClcbiIp
Ow0KICAgICB9DQogDQogICAgIGZvciAoaSA9IDA7IGkgPCBkX2NvbmZpZy0+
bnVtX25pY3M7IGkrKykgew0KLSAgICAgICAgcHJpbnRmKCJcdChkZXZpY2Vc
biIpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0KHZpZlxuIik7DQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHQoZGV2aWNlXG4iKTsNCisgICAgICAgIGZwcmlu
dGYoZmgsICJcdFx0KHZpZlxuIik7DQogICAgICAgICBpZiAoZF9jb25maWct
Pm5pY3NbaV0uaWZuYW1lKQ0KLSAgICAgICAgICAgIHByaW50ZigiXHRcdFx0
KHZpZm5hbWUgJXMpXG4iLCBkX2NvbmZpZy0+bmljc1tpXS5pZm5hbWUpOw0K
LSAgICAgICAgcHJpbnRmKCJcdFx0XHQoYmFja2VuZF9kb21pZCAlZClcbiIs
IGRfY29uZmlnLT5uaWNzW2ldLmJhY2tlbmRfZG9taWQpOw0KLSAgICAgICAg
cHJpbnRmKCJcdFx0XHQoZnJvbnRlbmRfZG9taWQgJWQpXG4iLCBkb21pZCk7
DQotICAgICAgICBwcmludGYoIlx0XHRcdChkZXZpZCAlZClcbiIsIGRfY29u
ZmlnLT5uaWNzW2ldLmRldmlkKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0
KG10dSAlZClcbiIsIGRfY29uZmlnLT5uaWNzW2ldLm10dSk7DQotICAgICAg
ICBwcmludGYoIlx0XHRcdChtb2RlbCAlcylcbiIsIGRfY29uZmlnLT5uaWNz
W2ldLm1vZGVsKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KG1hYyAlMDJ4
JTAyeCUwMnglMDJ4JTAyeCUwMngpXG4iLA0KKyAgICAgICAgICAgIGZwcmlu
dGYoZmgsICJcdFx0XHQodmlmbmFtZSAlcylcbiIsIGRfY29uZmlnLT5uaWNz
W2ldLmlmbmFtZSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGJh
Y2tlbmRfZG9taWQgJWQpXG4iLCBkX2NvbmZpZy0+bmljc1tpXS5iYWNrZW5k
X2RvbWlkKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoZnJvbnRl
bmRfZG9taWQgJWQpXG4iLCBkb21pZCk7DQorICAgICAgICBmcHJpbnRmKGZo
LCAiXHRcdFx0KGRldmlkICVkKVxuIiwgZF9jb25maWctPm5pY3NbaV0uZGV2
aWQpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChtdHUgJWQpXG4i
LCBkX2NvbmZpZy0+bmljc1tpXS5tdHUpOw0KKyAgICAgICAgZnByaW50Zihm
aCwgIlx0XHRcdChtb2RlbCAlcylcbiIsIGRfY29uZmlnLT5uaWNzW2ldLm1v
ZGVsKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQobWFjICUwMngl
MDJ4JTAyeCUwMnglMDJ4JTAyeClcbiIsDQogICAgICAgICAgICAgICAgZF9j
b25maWctPm5pY3NbaV0ubWFjWzBdLCBkX2NvbmZpZy0+bmljc1tpXS5tYWNb
MV0sDQogICAgICAgICAgICAgICAgZF9jb25maWctPm5pY3NbaV0ubWFjWzJd
LCBkX2NvbmZpZy0+bmljc1tpXS5tYWNbM10sDQogICAgICAgICAgICAgICAg
ZF9jb25maWctPm5pY3NbaV0ubWFjWzRdLCBkX2NvbmZpZy0+bmljc1tpXS5t
YWNbNV0pOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0KVxuIik7DQotICAgICAg
ICBwcmludGYoIlx0KVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRc
dClcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0KVxuIik7DQogICAg
IH0NCiANCiAgICAgZm9yIChpID0gMDsgaSA8IGRfY29uZmlnLT5udW1fcGNp
ZGV2czsgaSsrKSB7DQotICAgICAgICBwcmludGYoIlx0KGRldmljZVxuIik7
DQotICAgICAgICBwcmludGYoIlx0XHQocGNpXG4iKTsNCi0gICAgICAgIHBy
aW50ZigiXHRcdFx0KHBjaSBkZXYgJTA0eDolMDJ4OiUwMnguJTAxeEAlMDJ4
KVxuIiwNCisgICAgICAgIGZwcmludGYoZmgsICJcdChkZXZpY2VcbiIpOw0K
KyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQocGNpXG4iKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdFx0XHQocGNpIGRldiAlMDR4OiUwMng6JTAyeC4l
MDF4QCUwMngpXG4iLA0KICAgICAgICAgICAgICAgIGRfY29uZmlnLT5wY2lk
ZXZzW2ldLmRvbWFpbiwgZF9jb25maWctPnBjaWRldnNbaV0uYnVzLA0KICAg
ICAgICAgICAgICAgIGRfY29uZmlnLT5wY2lkZXZzW2ldLmRldiwgZF9jb25m
aWctPnBjaWRldnNbaV0uZnVuYywNCiAgICAgICAgICAgICAgICBkX2NvbmZp
Zy0+cGNpZGV2c1tpXS52ZGV2Zm4pOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0
XHQob3B0cyBtc2l0cmFuc2xhdGUgJWQgcG93ZXJfbWdtdCAlZClcbiIsDQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KG9wdHMgbXNpdHJhbnNsYXRl
ICVkIHBvd2VyX21nbXQgJWQpXG4iLA0KICAgICAgICAgICAgICAgIGRfY29u
ZmlnLT5wY2lkZXZzW2ldLm1zaXRyYW5zbGF0ZSwNCiAgICAgICAgICAgICAg
ICBkX2NvbmZpZy0+cGNpZGV2c1tpXS5wb3dlcl9tZ210KTsNCi0gICAgICAg
IHByaW50ZigiXHRcdClcbiIpOw0KLSAgICAgICAgcHJpbnRmKCJcdClcbiIp
Ow0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQpXG4iKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdClcbiIpOw0KICAgICB9DQogDQogICAgIGZvciAo
aSA9IDA7IGkgPCBkX2NvbmZpZy0+bnVtX3ZmYnM7IGkrKykgew0KLSAgICAg
ICAgcHJpbnRmKCJcdChkZXZpY2VcbiIpOw0KLSAgICAgICAgcHJpbnRmKCJc
dFx0KHZmYlxuIik7DQotICAgICAgICBwcmludGYoIlx0XHRcdChiYWNrZW5k
X2RvbWlkICVkKVxuIiwgZF9jb25maWctPnZmYnNbaV0uYmFja2VuZF9kb21p
ZCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChmcm9udGVuZF9kb21pZCAl
ZClcbiIsIGRvbWlkKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGRldmlk
ICVkKVxuIiwgZF9jb25maWctPnZmYnNbaV0uZGV2aWQpOw0KLSAgICAgICAg
cHJpbnRmKCJcdFx0XHQodm5jICVzKVxuIiwNCisgICAgICAgIGZwcmludGYo
ZmgsICJcdChkZXZpY2VcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0
XHQodmZiXG4iKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoYmFj
a2VuZF9kb21pZCAlZClcbiIsIGRfY29uZmlnLT52ZmJzW2ldLmJhY2tlbmRf
ZG9taWQpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChmcm9udGVu
ZF9kb21pZCAlZClcbiIsIGRvbWlkKTsNCisgICAgICAgIGZwcmludGYoZmgs
ICJcdFx0XHQoZGV2aWQgJWQpXG4iLCBkX2NvbmZpZy0+dmZic1tpXS5kZXZp
ZCk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHZuYyAlcylcbiIs
DQogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoZF9j
b25maWctPnZmYnNbaV0udm5jLmVuYWJsZSkpOw0KLSAgICAgICAgcHJpbnRm
KCJcdFx0XHQodm5jbGlzdGVuICVzKVxuIiwgZF9jb25maWctPnZmYnNbaV0u
dm5jLmxpc3Rlbik7DQotICAgICAgICBwcmludGYoIlx0XHRcdCh2bmNkaXNw
bGF5ICVkKVxuIiwgZF9jb25maWctPnZmYnNbaV0udm5jLmRpc3BsYXkpOw0K
LSAgICAgICAgcHJpbnRmKCJcdFx0XHQodm5jdW51c2VkICVzKVxuIiwNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQodm5jbGlzdGVuICVzKVxuIiwg
ZF9jb25maWctPnZmYnNbaV0udm5jLmxpc3Rlbik7DQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHRcdFx0KHZuY2Rpc3BsYXkgJWQpXG4iLCBkX2NvbmZpZy0+
dmZic1tpXS52bmMuZGlzcGxheSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAi
XHRcdFx0KHZuY3VudXNlZCAlcylcbiIsDQogICAgICAgICAgICAgICAgbGli
eGxfZGVmYm9vbF90b19zdHJpbmcoZF9jb25maWctPnZmYnNbaV0udm5jLmZp
bmR1bnVzZWQpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGtleW1hcCAl
cylcbiIsIGRfY29uZmlnLT52ZmJzW2ldLmtleW1hcCk7DQotICAgICAgICBw
cmludGYoIlx0XHRcdChzZGwgJXMpXG4iLA0KKyAgICAgICAgZnByaW50Zihm
aCwgIlx0XHRcdChrZXltYXAgJXMpXG4iLCBkX2NvbmZpZy0+dmZic1tpXS5r
ZXltYXApOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzZGwgJXMp
XG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5n
KGRfY29uZmlnLT52ZmJzW2ldLnNkbC5lbmFibGUpKTsNCi0gICAgICAgIHBy
aW50ZigiXHRcdFx0KG9wZW5nbCAlcylcbiIsDQorICAgICAgICBmcHJpbnRm
KGZoLCAiXHRcdFx0KG9wZW5nbCAlcylcbiIsDQogICAgICAgICAgICAgICAg
bGlieGxfZGVmYm9vbF90b19zdHJpbmcoZF9jb25maWctPnZmYnNbaV0uc2Rs
Lm9wZW5nbCkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoZGlzcGxheSAl
cylcbiIsIGRfY29uZmlnLT52ZmJzW2ldLnNkbC5kaXNwbGF5KTsNCi0gICAg
ICAgIHByaW50ZigiXHRcdFx0KHhhdXRob3JpdHkgJXMpXG4iLCBkX2NvbmZp
Zy0+dmZic1tpXS5zZGwueGF1dGhvcml0eSk7DQotICAgICAgICBwcmludGYo
Ilx0XHQpXG4iKTsNCi0gICAgICAgIHByaW50ZigiXHQpXG4iKTsNCisgICAg
ICAgIGZwcmludGYoZmgsICJcdFx0XHQoZGlzcGxheSAlcylcbiIsIGRfY29u
ZmlnLT52ZmJzW2ldLnNkbC5kaXNwbGF5KTsNCisgICAgICAgIGZwcmludGYo
ZmgsICJcdFx0XHQoeGF1dGhvcml0eSAlcylcbiIsIGRfY29uZmlnLT52ZmJz
W2ldLnNkbC54YXV0aG9yaXR5KTsNCisgICAgICAgIGZwcmludGYoZmgsICJc
dFx0KVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHQpXG4iKTsNCiAg
ICAgfQ0KLSAgICBwcmludGYoIilcbiIpOw0KKyAgICBmcHJpbnRmKGZoLCAi
KVxuIik7DQogfQ0KIA0KIA0KLS0tIHhlbi00LjUuMC1yYzEvdG9vbHMvbGli
eGwveGwuaC5vcmlnCTIwMTQtMTAtMjQgMTU6MjI6NDAuMDAwMDAwMDAwICsw
MTAwDQorKysgeGVuLTQuNS4wLXJjMS90b29scy9saWJ4bC94bC5oCTIwMTQt
MTEtMjYgMjI6MzA6NTguNDE2Mzk0MDgyICswMDAwDQpAQCAtMTg2LDcgKzE4
Niw3IEBADQogfTsNCiBleHRlcm4gZW51bSBvdXRwdXRfZm9ybWF0IGRlZmF1
bHRfb3V0cHV0X2Zvcm1hdDsNCiANCi1leHRlcm4gdm9pZCBwcmludGZfaW5m
b19zZXhwKGludCBkb21pZCwgbGlieGxfZG9tYWluX2NvbmZpZyAqZF9jb25m
aWcpOw0KK2V4dGVybiB2b2lkIHByaW50Zl9pbmZvX3NleHAoaW50IGRvbWlk
LCBsaWJ4bF9kb21haW5fY29uZmlnICpkX2NvbmZpZywgRklMRSAqZmgpOw0K
IA0KICNkZWZpbmUgWExfR0xPQkFMX0NPTkZJRyBYRU5fQ09ORklHX0RJUiAi
L3hsLmNvbmYiDQogI2RlZmluZSBYTF9MT0NLX0ZJTEUgWEVOX0xPQ0tfRElS
ICIveGwiDQo=

---559023410-351212254-1417163529=:1345
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

---559023410-351212254-1417163529=:1345--


From xen-devel-bounces@lists.xen.org Fri Nov 28 08:32:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 08:32:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuGyl-00075q-Rv; Fri, 28 Nov 2014 08:32:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1XuGyk-00075i-Rr
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 08:32:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6D/E8-25276-62338745; Fri, 28 Nov 2014 08:32:38 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417163557!11990168!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5ODA1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6722 invoked from network); 28 Nov 2014 08:32:37 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 08:32:37 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAS8WJF9024915;
	Fri, 28 Nov 2014 08:32:24 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sAS8W90i005844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Nov 2014 08:32:09 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.5+Sun/8.11.1) with ESMTP id sAS8W9xo001367;
	Fri, 28 Nov 2014 08:32:09 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.5+Sun/8.14.5/Submit) with ESMTP id
	sAS8W9eT001364; Fri, 28 Nov 2014 08:32:09 GMT
Date: Fri, 28 Nov 2014 08:32:09 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417163231.2372.10.camel@citrix.com>
Message-ID: <alpine.GSO.2.00.1411280830170.1345@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411272342370.5756@procyon.dur.ac.uk>
	<1417163231.2372.10.camel@citrix.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-351212254-1417163529=:1345"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sAS8WJF9024915
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] fix migration failure with xl migrate
	--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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-351212254-1417163529=:1345
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 28 Nov 2014, Ian Campbell wrote:

> On Fri, 2014-11-28 at 00:28 +0000, M A Young wrote:
>> Migrations with xl migrate --debug will fail because debugging information
>> from the receiving process is written to the stdout channel. This channel
>> is also used for status messages so the migration will fail as the sending
>> process receives an unexpected message. This patch moves the debugging
>> information to the stderr channel.
>>
>> Version 2 moves some output back to stdout that was accidentally moved
>> to stderr in the first version.
>>
>> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
>
> I think you've forgotten the attachment.

Yes, I did. Here it is.
---559023410-351212254-1417163529=:1345
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xl.migrate.debug.fail.patch
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.GSO.2.00.1411280832090.1345@algedi.dur.ac.uk>
Content-Description: 
Content-Disposition: attachment; filename=xl.migrate.debug.fail.patch

VXNlIHN0ZGVyciBmb3IgZGVidWdnaW5nIG1lc3NhZ2VzIGZvciB4bCBtaWdy
YXRlIC0tZGVidWcgYXMgc3Rkb3V0IGlzIHVzZWQNCmZvciBzdGF0dXMgbWVz
c2FnZXMuDQoNCi0tLSB4ZW4tNC41LjAtcmMxL3Rvb2xzL2xpYnhsL3hsX2Nt
ZGltcGwuYy5vcmlnCTIwMTQtMTAtMjQgMTU6MjI6NDAuMDAwMDAwMDAwICsw
MTAwDQorKysgeGVuLTQuNS4wLXJjMS90b29scy9saWJ4bC94bF9jbWRpbXBs
LmMJMjAxNC0xMS0yNiAyMjo0MTo0MS42OTcwNDMzMjEgKzAwMDANCkBAIC0z
ODAsMTAgKzM4MCwxMCBAQA0KIH0NCiBzdGF0aWMgdm9pZCBwcmludGZfaW5m
byhlbnVtIG91dHB1dF9mb3JtYXQgb3V0cHV0X2Zvcm1hdCwNCiAgICAgICAg
ICAgICAgICAgICAgICAgICBpbnQgZG9taWQsDQotICAgICAgICAgICAgICAg
ICAgICAgICAgbGlieGxfZG9tYWluX2NvbmZpZyAqZF9jb25maWcpDQorICAg
ICAgICAgICAgICAgICAgICAgICAgbGlieGxfZG9tYWluX2NvbmZpZyAqZF9j
b25maWcsIEZJTEUgKmZoKQ0KIHsNCiAgICAgaWYgKG91dHB1dF9mb3JtYXQg
PT0gT1VUUFVUX0ZPUk1BVF9TWFApDQotICAgICAgICByZXR1cm4gcHJpbnRm
X2luZm9fc2V4cChkb21pZCwgZF9jb25maWcpOw0KKyAgICAgICAgcmV0dXJu
IHByaW50Zl9pbmZvX3NleHAoZG9taWQsIGRfY29uZmlnLCBmaCk7DQogDQog
ICAgIGNvbnN0IGNoYXIgKmJ1ZjsNCiAgICAgbGlieGxfeWFqbF9sZW5ndGgg
bGVuID0gMDsNCkBAIC00MDQsNyArNDA0LDcgQEANCiAgICAgaWYgKHMgIT0g
eWFqbF9nZW5fc3RhdHVzX29rKQ0KICAgICAgICAgZ290byBvdXQ7DQogDQot
ICAgIHB1dHMoYnVmKTsNCisgICAgZnB1dHMoYnVmLCBmaCk7DQogDQogb3V0
Og0KICAgICB5YWpsX2dlbl9mcmVlKGhhbmQpOw0KQEAgLTQxMyw3ICs0MTMs
MTMgQEANCiAgICAgICAgIGZwcmludGYoc3RkZXJyLA0KICAgICAgICAgICAg
ICAgICAidW5hYmxlIHRvIGZvcm1hdCBkb21haW4gY29uZmlnIGFzIEpTT04g
KFlBSkw6JWQpXG4iLCBzKTsNCiANCi0gICAgaWYgKGZlcnJvcihzdGRvdXQp
IHx8IGZmbHVzaChzdGRvdXQpKSB7IHBlcnJvcigic3Rkb3V0Iik7IGV4aXQo
LTEpOyB9DQorICAgIGlmIChmZXJyb3IoZmgpIHx8IGZmbHVzaChmaCkpIHsN
CisgICAgICAgIGlmIChmaCA9PSBzdGRvdXQpDQorICAgICAgICAgICAgcGVy
cm9yKCJzdGRvdXQiKTsNCisgICAgICAgIGVsc2UNCisgICAgICAgICAgICBw
ZXJyb3IoInN0ZGVyciIpOw0KKyAgICAgICAgZXhpdCgtMSk7DQorICAgIH0N
CiB9DQogDQogc3RhdGljIGludCBkb19kYWVtb25pemUoY2hhciAqbmFtZSkN
CkBAIC0yNDIzLDcgKzI0MjksNyBAQA0KICAgICB9DQogDQogICAgIGlmICgh
ZG9tX2luZm8tPnF1aWV0KQ0KLSAgICAgICAgcHJpbnRmKCJQYXJzaW5nIGNv
bmZpZyBmcm9tICVzXG4iLCBjb25maWdfc291cmNlKTsNCisgICAgICAgIGZw
cmludGYoc3RkZXJyLCAiUGFyc2luZyBjb25maWcgZnJvbSAlc1xuIiwgY29u
ZmlnX3NvdXJjZSk7DQogDQogICAgIGlmIChjb25maWdfaW5fanNvbikgew0K
ICAgICAgICAgbGlieGxfZG9tYWluX2NvbmZpZ19mcm9tX2pzb24oY3R4LCAm
ZF9jb25maWcsDQpAQCAtMjQ1MSw3ICsyNDU3LDcgQEANCiAgICAgfQ0KIA0K
ICAgICBpZiAoZGVidWcgfHwgZG9tX2luZm8tPmRyeXJ1bikNCi0gICAgICAg
IHByaW50Zl9pbmZvKGRlZmF1bHRfb3V0cHV0X2Zvcm1hdCwgLTEsICZkX2Nv
bmZpZyk7DQorICAgICAgICBwcmludGZfaW5mbyhkZWZhdWx0X291dHB1dF9m
b3JtYXQsIC0xLCAmZF9jb25maWcsIHN0ZGVycik7DQogDQogICAgIHJldCA9
IDA7DQogICAgIGlmIChkb21faW5mby0+ZHJ5cnVuKQ0KQEAgLTM0MDMsNyAr
MzQwOSw3IEBADQogICAgICAgICBpZiAoZGVmYXVsdF9vdXRwdXRfZm9ybWF0
ID09IE9VVFBVVF9GT1JNQVRfSlNPTikNCiAgICAgICAgICAgICBzID0gcHJp
bnRmX2luZm9fb25lX2pzb24oaGFuZCwgaW5mb1tpXS5kb21pZCwgJmRfY29u
ZmlnKTsNCiAgICAgICAgIGVsc2UNCi0gICAgICAgICAgICBwcmludGZfaW5m
b19zZXhwKGluZm9baV0uZG9taWQsICZkX2NvbmZpZyk7DQorICAgICAgICAg
ICAgcHJpbnRmX2luZm9fc2V4cChpbmZvW2ldLmRvbWlkLCAmZF9jb25maWcs
IHN0ZG91dCk7DQogICAgICAgICBsaWJ4bF9kb21haW5fY29uZmlnX2Rpc3Bv
c2UoJmRfY29uZmlnKTsNCiAgICAgICAgIGlmIChzICE9IHlhamxfZ2VuX3N0
YXR1c19vaykNCiAgICAgICAgICAgICBnb3RvIG91dDsNCkBAIC00NzI1LDcg
KzQ3MzEsNyBAQA0KICAgICBwYXJzZV9jb25maWdfZGF0YShmaWxlbmFtZSwg
Y29uZmlnX2RhdGEsIGNvbmZpZ19sZW4sICZkX2NvbmZpZyk7DQogDQogICAg
IGlmIChkZWJ1ZyB8fCBkcnlydW5fb25seSkNCi0gICAgICAgIHByaW50Zl9p
bmZvKGRlZmF1bHRfb3V0cHV0X2Zvcm1hdCwgLTEsICZkX2NvbmZpZyk7DQor
ICAgICAgICBwcmludGZfaW5mbyhkZWZhdWx0X291dHB1dF9mb3JtYXQsIC0x
LCAmZF9jb25maWcsIHN0ZG91dCk7DQogDQogICAgIGlmICghZHJ5cnVuX29u
bHkpIHsNCiAgICAgICAgIGZwcmludGYoc3RkZXJyLCAic2V0dGluZyBkb20l
ZCBjb25maWd1cmF0aW9uXG4iLCBkb21pZCk7DQotLS0geGVuLTQuNS4wLXJj
MS90b29scy9saWJ4bC94bF9zeHAuYy5vcmlnCTIwMTQtMTAtMjQgMTU6MjI6
NDAuMDAwMDAwMDAwICswMTAwDQorKysgeGVuLTQuNS4wLXJjMS90b29scy9s
aWJ4bC94bF9zeHAuYwkyMDE0LTExLTI2IDIyOjMwOjU4LjQxNjM5NDA4MiAr
MDAwMA0KQEAgLTMwLDcgKzMwLDcgQEANCiAvKiBJbiBnZW5lcmFsIHlvdSBz
aG91bGQgbm90IGFkZCBuZXcgb3V0cHV0IHRvIHRoaXMgZnVuY3Rpb24gc2lu
Y2UgaXQNCiAgKiBpcyBpbnRlbmRlZCBvbmx5IGZvciBsZWdhY3kgdXNlLg0K
ICAqLw0KLXZvaWQgcHJpbnRmX2luZm9fc2V4cChpbnQgZG9taWQsIGxpYnhs
X2RvbWFpbl9jb25maWcgKmRfY29uZmlnKQ0KK3ZvaWQgcHJpbnRmX2luZm9f
c2V4cChpbnQgZG9taWQsIGxpYnhsX2RvbWFpbl9jb25maWcgKmRfY29uZmln
LCBGSUxFICpmaCkNCiB7DQogICAgIGludCBpOw0KICAgICBsaWJ4bF9kb21p
bmZvIGluZm87DQpAQCAtMzgsMTk1ICszOCwxOTUgQEANCiAgICAgbGlieGxf
ZG9tYWluX2NyZWF0ZV9pbmZvICpjX2luZm8gPSAmZF9jb25maWctPmNfaW5m
bzsNCiAgICAgbGlieGxfZG9tYWluX2J1aWxkX2luZm8gKmJfaW5mbyA9ICZk
X2NvbmZpZy0+Yl9pbmZvOw0KIA0KLSAgICBwcmludGYoIihkb21haW5cblx0
KGRvbWlkICVkKVxuIiwgZG9taWQpOw0KLSAgICBwcmludGYoIlx0KGNyZWF0
ZV9pbmZvKVxuIik7DQotICAgIHByaW50ZigiXHQoaHZtICVkKVxuIiwgY19p
bmZvLT50eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX0hWTSk7DQotICAgIHBy
aW50ZigiXHQoaGFwICVzKVxuIiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmco
Y19pbmZvLT5oYXApKTsNCi0gICAgcHJpbnRmKCJcdChvb3MgJXMpXG4iLCBs
aWJ4bF9kZWZib29sX3RvX3N0cmluZyhjX2luZm8tPm9vcykpOw0KLSAgICBw
cmludGYoIlx0KHNzaWRyZWYgJWQpXG4iLCBjX2luZm8tPnNzaWRyZWYpOw0K
LSAgICBwcmludGYoIlx0KG5hbWUgJXMpXG4iLCBjX2luZm8tPm5hbWUpOw0K
KyAgICBmcHJpbnRmKGZoLCAiKGRvbWFpblxuXHQoZG9taWQgJWQpXG4iLCBk
b21pZCk7DQorICAgIGZwcmludGYoZmgsICJcdChjcmVhdGVfaW5mbylcbiIp
Ow0KKyAgICBmcHJpbnRmKGZoLCAiXHQoaHZtICVkKVxuIiwgY19pbmZvLT50
eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX0hWTSk7DQorICAgIGZwcmludGYo
ZmgsICJcdChoYXAgJXMpXG4iLCBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhj
X2luZm8tPmhhcCkpOw0KKyAgICBmcHJpbnRmKGZoLCAiXHQob29zICVzKVxu
IiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoY19pbmZvLT5vb3MpKTsNCisg
ICAgZnByaW50ZihmaCwgIlx0KHNzaWRyZWYgJWQpXG4iLCBjX2luZm8tPnNz
aWRyZWYpOw0KKyAgICBmcHJpbnRmKGZoLCAiXHQobmFtZSAlcylcbiIsIGNf
aW5mby0+bmFtZSk7DQogDQogICAgIC8qIHJldHJpZXZlIHRoZSBVVUlEIGZy
b20gZG9taW5mbywgc2luY2UgaXQgaXMgcHJvYmFibHkgZ2VuZXJhdGVkDQog
ICAgICAqIGR1cmluZyBwYXJzaW5nIGFuZCB0aHVzIGRvZXMgbm90IG1hdGNo
IHRoZSByZWFsIG9uZQ0KICAgICAgKi8NCiAgICAgaWYgKGxpYnhsX2RvbWFp
bl9pbmZvKGN0eCwgJmluZm8sIGRvbWlkKSA9PSAwKSB7DQotICAgICAgICBw
cmludGYoIlx0KHV1aWQgIiBMSUJYTF9VVUlEX0ZNVCAiKVxuIiwgTElCWExf
VVVJRF9CWVRFUyhpbmZvLnV1aWQpKTsNCisgICAgICAgIGZwcmludGYoZmgs
ICJcdCh1dWlkICIgTElCWExfVVVJRF9GTVQgIilcbiIsIExJQlhMX1VVSURf
QllURVMoaW5mby51dWlkKSk7DQogICAgIH0gZWxzZSB7DQotICAgICAgICBw
cmludGYoIlx0KHV1aWQgPHVua25vd24+KVxuIik7DQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHQodXVpZCA8dW5rbm93bj4pXG4iKTsNCiAgICAgfQ0KICAg
ICBpZiAoY19pbmZvLT5wb29sX25hbWUpDQotICAgICAgICBwcmludGYoIlx0
KGNwdXBvb2wgJXMpXG4iLCBjX2luZm8tPnBvb2xfbmFtZSk7DQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHQoY3B1cG9vbCAlcylcbiIsIGNfaW5mby0+cG9v
bF9uYW1lKTsNCiAgICAgaWYgKGNfaW5mby0+eHNkYXRhKQ0KLSAgICAgICAg
cHJpbnRmKCJcdCh4c2RhdGEgY29udGFpbnMgZGF0YSlcbiIpOw0KKyAgICAg
ICAgZnByaW50ZihmaCwgIlx0KHhzZGF0YSBjb250YWlucyBkYXRhKVxuIik7
DQogICAgIGVsc2UNCi0gICAgICAgIHByaW50ZigiXHQoeHNkYXRhIChudWxs
KSlcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0KHhzZGF0YSAobnVs
bCkpXG4iKTsNCiAgICAgaWYgKGNfaW5mby0+cGxhdGZvcm1kYXRhKQ0KLSAg
ICAgICAgcHJpbnRmKCJcdChwbGF0Zm9ybWRhdGEgY29udGFpbnMgZGF0YSlc
biIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0KHBsYXRmb3JtZGF0YSBj
b250YWlucyBkYXRhKVxuIik7DQogICAgIGVsc2UNCi0gICAgICAgIHByaW50
ZigiXHQocGxhdGZvcm1kYXRhIChudWxsKSlcbiIpOw0KKyAgICAgICAgZnBy
aW50ZihmaCwgIlx0KHBsYXRmb3JtZGF0YSAobnVsbCkpXG4iKTsNCiANCiAN
Ci0gICAgcHJpbnRmKCJcdChidWlsZF9pbmZvKVxuIik7DQotICAgIHByaW50
ZigiXHQobWF4X3ZjcHVzICVkKVxuIiwgYl9pbmZvLT5tYXhfdmNwdXMpOw0K
LSAgICBwcmludGYoIlx0KHRzY19tb2RlICVzKVxuIiwgbGlieGxfdHNjX21v
ZGVfdG9fc3RyaW5nKGJfaW5mby0+dHNjX21vZGUpKTsNCi0gICAgcHJpbnRm
KCJcdChtYXhfbWVta2IgJSJQUklkNjQiKVxuIiwgYl9pbmZvLT5tYXhfbWVt
a2IpOw0KLSAgICBwcmludGYoIlx0KHRhcmdldF9tZW1rYiAlIlBSSWQ2NCIp
XG4iLCBiX2luZm8tPnRhcmdldF9tZW1rYik7DQotICAgIHByaW50ZigiXHQo
bm9taWdyYXRlICVzKVxuIiwNCisgICAgZnByaW50ZihmaCwgIlx0KGJ1aWxk
X2luZm8pXG4iKTsNCisgICAgZnByaW50ZihmaCwgIlx0KG1heF92Y3B1cyAl
ZClcbiIsIGJfaW5mby0+bWF4X3ZjcHVzKTsNCisgICAgZnByaW50ZihmaCwg
Ilx0KHRzY19tb2RlICVzKVxuIiwgbGlieGxfdHNjX21vZGVfdG9fc3RyaW5n
KGJfaW5mby0+dHNjX21vZGUpKTsNCisgICAgZnByaW50ZihmaCwgIlx0KG1h
eF9tZW1rYiAlIlBSSWQ2NCIpXG4iLCBiX2luZm8tPm1heF9tZW1rYik7DQor
ICAgIGZwcmludGYoZmgsICJcdCh0YXJnZXRfbWVta2IgJSJQUklkNjQiKVxu
IiwgYl9pbmZvLT50YXJnZXRfbWVta2IpOw0KKyAgICBmcHJpbnRmKGZoLCAi
XHQobm9taWdyYXRlICVzKVxuIiwNCiAgICAgICAgICAgIGxpYnhsX2RlZmJv
b2xfdG9fc3RyaW5nKGJfaW5mby0+ZGlzYWJsZV9taWdyYXRlKSk7DQogDQog
ICAgIGlmIChjX2luZm8tPnR5cGUgPT0gTElCWExfRE9NQUlOX1RZUEVfUFYg
JiYgYl9pbmZvLT51LnB2LmJvb3Rsb2FkZXIpIHsNCi0gICAgICAgIHByaW50
ZigiXHQoYm9vdGxvYWRlciAlcylcbiIsIGJfaW5mby0+dS5wdi5ib290bG9h
ZGVyKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdChib290bG9hZGVyICVz
KVxuIiwgYl9pbmZvLT51LnB2LmJvb3Rsb2FkZXIpOw0KICAgICAgICAgaWYg
KGJfaW5mby0+dS5wdi5ib290bG9hZGVyX2FyZ3MpIHsNCi0gICAgICAgICAg
ICBwcmludGYoIlx0KGJvb3Rsb2FkZXJfYXJncyIpOw0KKyAgICAgICAgICAg
IGZwcmludGYoZmgsICJcdChib290bG9hZGVyX2FyZ3MiKTsNCiAgICAgICAg
ICAgICBmb3IgKGk9MDsgYl9pbmZvLT51LnB2LmJvb3Rsb2FkZXJfYXJnc1tp
XTsgaSsrKQ0KLSAgICAgICAgICAgICAgICBwcmludGYoIiAlcyIsIGJfaW5m
by0+dS5wdi5ib290bG9hZGVyX2FyZ3NbaV0pOw0KLSAgICAgICAgICAgIHBy
aW50ZigiKVxuIik7DQorICAgICAgICAgICAgICAgIGZwcmludGYoZmgsICIg
JXMiLCBiX2luZm8tPnUucHYuYm9vdGxvYWRlcl9hcmdzW2ldKTsNCisgICAg
ICAgICAgICBmcHJpbnRmKGZoLCAiKVxuIik7DQogICAgICAgICB9DQogICAg
IH0NCiANCi0gICAgcHJpbnRmKCJcdChpbWFnZVxuIik7DQorICAgIGZwcmlu
dGYoZmgsICJcdChpbWFnZVxuIik7DQogICAgIHN3aXRjaCAoY19pbmZvLT50
eXBlKSB7DQogICAgIGNhc2UgTElCWExfRE9NQUlOX1RZUEVfSFZNOg0KLSAg
ICAgICAgcHJpbnRmKCJcdFx0KGh2bVxuIik7DQotICAgICAgICBwcmludGYo
Ilx0XHRcdChmaXJtd2FyZSAlcylcbiIsIGJfaW5mby0+dS5odm0uZmlybXdh
cmUpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodmlkZW9fbWVta2IgJSJQ
UklkNjQiKVxuIiwgYl9pbmZvLT52aWRlb19tZW1rYik7DQotICAgICAgICBw
cmludGYoIlx0XHRcdChzaGFkb3dfbWVta2IgJSJQUklkNjQiKVxuIiwgYl9p
bmZvLT5zaGFkb3dfbWVta2IpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQo
cGFlICVzKVxuIiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51
Lmh2bS5wYWUpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGFwaWMgJXMp
XG4iLA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQoaHZtXG4iKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoZmlybXdhcmUgJXMpXG4iLCBi
X2luZm8tPnUuaHZtLmZpcm13YXJlKTsNCisgICAgICAgIGZwcmludGYoZmgs
ICJcdFx0XHQodmlkZW9fbWVta2IgJSJQUklkNjQiKVxuIiwgYl9pbmZvLT52
aWRlb19tZW1rYik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHNo
YWRvd19tZW1rYiAlIlBSSWQ2NCIpXG4iLCBiX2luZm8tPnNoYWRvd19tZW1r
Yik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHBhZSAlcylcbiIs
IGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0ucGFlKSk7
DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGFwaWMgJXMpXG4iLA0K
ICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5m
by0+dS5odm0uYXBpYykpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoYWNw
aSAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGFjcGkg
JXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3Ry
aW5nKGJfaW5mby0+dS5odm0uYWNwaSkpOw0KLSAgICAgICAgcHJpbnRmKCJc
dFx0XHQobnggJXMpXG4iLCBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2lu
Zm8tPnUuaHZtLm54KSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdCh2aXJp
ZGlhbiAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KG54
ICVzKVxuIiwgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2
bS5ueCkpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh2aXJpZGlh
biAlcylcbiIsDQogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19z
dHJpbmcoYl9pbmZvLT51Lmh2bS52aXJpZGlhbikpOw0KLSAgICAgICAgcHJp
bnRmKCJcdFx0XHQoaHBldCAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZo
LCAiXHRcdFx0KGhwZXQgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhs
X2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0uaHBldCkpOw0KLSAg
ICAgICAgcHJpbnRmKCJcdFx0XHQodnB0X2FsaWduICVzKVxuIiwNCisgICAg
ICAgIGZwcmludGYoZmgsICJcdFx0XHQodnB0X2FsaWduICVzKVxuIiwNCiAg
ICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8t
PnUuaHZtLnZwdF9hbGlnbikpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQo
dGltZXJfbW9kZSAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRc
dFx0KHRpbWVyX21vZGUgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhs
X3RpbWVyX21vZGVfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0udGltZXJfbW9k
ZSkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQobmVzdGVkaHZtICVzKVxu
IiwNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQobmVzdGVkaHZtICVz
KVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmlu
ZyhiX2luZm8tPnUuaHZtLm5lc3RlZF9odm0pKTsNCi0gICAgICAgIHByaW50
ZigiXHRcdFx0KHN0ZHZnYSAlcylcbiIsIGJfaW5mby0+dS5odm0udmdhLmtp
bmQgPT0NCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoc3RkdmdhICVz
KVxuIiwgYl9pbmZvLT51Lmh2bS52Z2Eua2luZCA9PQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgTElCWExfVkdBX0lOVEVSRkFD
RV9UWVBFX1NURCA/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAiVHJ1ZSIgOiAiRmFsc2UiKTsNCi0gICAgICAgIHByaW50Zigi
XHRcdFx0KHZuYyAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRc
dFx0KHZuYyAlcylcbiIsDQogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9v
bF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS52bmMuZW5hYmxlKSk7DQotICAg
ICAgICBwcmludGYoIlx0XHRcdCh2bmNsaXN0ZW4gJXMpXG4iLCBiX2luZm8t
PnUuaHZtLnZuYy5saXN0ZW4pOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQo
dm5jZGlzcGxheSAlZClcbiIsIGJfaW5mby0+dS5odm0udm5jLmRpc3BsYXkp
Ow0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodm5jdW51c2VkICVzKVxuIiwN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQodm5jbGlzdGVuICVzKVxu
IiwgYl9pbmZvLT51Lmh2bS52bmMubGlzdGVuKTsNCisgICAgICAgIGZwcmlu
dGYoZmgsICJcdFx0XHQodm5jZGlzcGxheSAlZClcbiIsIGJfaW5mby0+dS5o
dm0udm5jLmRpc3BsYXkpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRc
dCh2bmN1bnVzZWQgJXMpXG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2Rl
ZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0udm5jLmZpbmR1bnVzZWQp
KTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGtleW1hcCAlcylcbiIsIGJf
aW5mby0+dS5odm0ua2V5bWFwKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0
KHNkbCAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGtl
eW1hcCAlcylcbiIsIGJfaW5mby0+dS5odm0ua2V5bWFwKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdFx0XHQoc2RsICVzKVxuIiwNCiAgICAgICAgICAg
ICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnNk
bC5lbmFibGUpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KG9wZW5nbCAl
cylcbiIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KG9wZW5nbCAl
cylcbiIsDQogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJp
bmcoYl9pbmZvLT51Lmh2bS5zZGwub3BlbmdsKSk7DQotICAgICAgICBwcmlu
dGYoIlx0XHRcdChub2dyYXBoaWMgJXMpXG4iLA0KKyAgICAgICAgZnByaW50
ZihmaCwgIlx0XHRcdChub2dyYXBoaWMgJXMpXG4iLA0KICAgICAgICAgICAg
ICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0ubm9n
cmFwaGljKSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChzcGljZSAlcylc
biIsDQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHNwaWNlICVzKVxu
IiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhi
X2luZm8tPnUuaHZtLnNwaWNlLmVuYWJsZSkpOw0KLSAgICAgICAgcHJpbnRm
KCJcdFx0XHQoc3BpY2Vwb3J0ICVkKVxuIiwgYl9pbmZvLT51Lmh2bS5zcGlj
ZS5wb3J0KTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHNwaWNldGxzX3Bv
cnQgJWQpXG4iLCBiX2luZm8tPnUuaHZtLnNwaWNlLnRsc19wb3J0KTsNCi0g
ICAgICAgIHByaW50ZigiXHRcdFx0KHNwaWNlaG9zdCAlcylcbiIsIGJfaW5m
by0+dS5odm0uc3BpY2UuaG9zdCk7DQotICAgICAgICBwcmludGYoIlx0XHRc
dChzcGljZWRpc2FibGVfdGlja2V0aW5nICVzKVxuIiwNCisgICAgICAgIGZw
cmludGYoZmgsICJcdFx0XHQoc3BpY2Vwb3J0ICVkKVxuIiwgYl9pbmZvLT51
Lmh2bS5zcGljZS5wb3J0KTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0
XHQoc3BpY2V0bHNfcG9ydCAlZClcbiIsIGJfaW5mby0+dS5odm0uc3BpY2Uu
dGxzX3BvcnQpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzcGlj
ZWhvc3QgJXMpXG4iLCBiX2luZm8tPnUuaHZtLnNwaWNlLmhvc3QpOw0KKyAg
ICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzcGljZWRpc2FibGVfdGlja2V0
aW5nICVzKVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3Rv
X3N0cmluZyhiX2luZm8tPnUuaHZtLnNwaWNlLmRpc2FibGVfdGlja2V0aW5n
KSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChzcGljZWFnZW50X21vdXNl
ICVzKVxuIiwNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoc3BpY2Vh
Z2VudF9tb3VzZSAlcylcbiIsDQogICAgICAgICAgICAgICAgbGlieGxfZGVm
Ym9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS5zcGljZS5hZ2VudF9tb3Vz
ZSkpOw0KIA0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoZGV2aWNlX21vZGVs
ICVzKVxuIiwgYl9pbmZvLT5kZXZpY2VfbW9kZWwgPyA6ICJkZWZhdWx0Iik7
DQotICAgICAgICBwcmludGYoIlx0XHRcdChnZnhfcGFzc3RocnUgJXMpXG4i
LA0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChkZXZpY2VfbW9kZWwg
JXMpXG4iLCBiX2luZm8tPmRldmljZV9tb2RlbCA/IDogImRlZmF1bHQiKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoZ2Z4X3Bhc3N0aHJ1ICVz
KVxuIiwNCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmlu
ZyhiX2luZm8tPnUuaHZtLmdmeF9wYXNzdGhydSkpOw0KLSAgICAgICAgcHJp
bnRmKCJcdFx0XHQoc2VyaWFsICVzKVxuIiwgYl9pbmZvLT51Lmh2bS5zZXJp
YWwpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoYm9vdCAlcylcbiIsIGJf
aW5mby0+dS5odm0uYm9vdCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdCh1
c2IgJXMpXG4iLCBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUu
aHZtLnVzYikpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQodXNiZGV2aWNl
ICVzKVxuIiwgYl9pbmZvLT51Lmh2bS51c2JkZXZpY2UpOw0KLSAgICAgICAg
cHJpbnRmKCJcdFx0KVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRc
dFx0KHNlcmlhbCAlcylcbiIsIGJfaW5mby0+dS5odm0uc2VyaWFsKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoYm9vdCAlcylcbiIsIGJfaW5m
by0+dS5odm0uYm9vdCk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0
KHVzYiAlcylcbiIsIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+
dS5odm0udXNiKSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHVz
YmRldmljZSAlcylcbiIsIGJfaW5mby0+dS5odm0udXNiZGV2aWNlKTsNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0KVxuIik7DQogICAgICAgICBicmVh
azsNCiAgICAgY2FzZSBMSUJYTF9ET01BSU5fVFlQRV9QVjoNCi0gICAgICAg
IHByaW50ZigiXHRcdChsaW51eCAlZClcbiIsIDApOw0KLSAgICAgICAgcHJp
bnRmKCJcdFx0XHQoa2VybmVsICVzKVxuIiwgYl9pbmZvLT5rZXJuZWwpOw0K
LSAgICAgICAgcHJpbnRmKCJcdFx0XHQoY21kbGluZSAlcylcbiIsIGJfaW5m
by0+Y21kbGluZSk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChyYW1kaXNr
ICVzKVxuIiwgYl9pbmZvLT5yYW1kaXNrKTsNCi0gICAgICAgIHByaW50Zigi
XHRcdFx0KGU4MjBfaG9zdCAlcylcbiIsDQorICAgICAgICBmcHJpbnRmKGZo
LCAiXHRcdChsaW51eCAlZClcbiIsIDApOw0KKyAgICAgICAgZnByaW50Zihm
aCwgIlx0XHRcdChrZXJuZWwgJXMpXG4iLCBiX2luZm8tPmtlcm5lbCk7DQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGNtZGxpbmUgJXMpXG4iLCBi
X2luZm8tPmNtZGxpbmUpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRc
dChyYW1kaXNrICVzKVxuIiwgYl9pbmZvLT5yYW1kaXNrKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdFx0XHQoZTgyMF9ob3N0ICVzKVxuIiwNCiAgICAg
ICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUu
cHYuZTgyMF9ob3N0KSk7DQotICAgICAgICBwcmludGYoIlx0XHQpXG4iKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0KVxuIik7DQogICAgICAgICBi
cmVhazsNCiAgICAgZGVmYXVsdDoNCiAgICAgICAgIGZwcmludGYoc3RkZXJy
LCAiVW5rbm93biBkb21haW4gdHlwZSAlZFxuIiwgY19pbmZvLT50eXBlKTsN
CiAgICAgICAgIGV4aXQoMSk7DQogICAgIH0NCi0gICAgcHJpbnRmKCJcdClc
biIpOw0KKyAgICBmcHJpbnRmKGZoLCAiXHQpXG4iKTsNCiANCiAgICAgZm9y
IChpID0gMDsgaSA8IGRfY29uZmlnLT5udW1fZGlza3M7IGkrKykgew0KLSAg
ICAgICAgcHJpbnRmKCJcdChkZXZpY2VcbiIpOw0KLSAgICAgICAgcHJpbnRm
KCJcdFx0KHRhcFxuIik7DQotICAgICAgICBwcmludGYoIlx0XHRcdChiYWNr
ZW5kX2RvbWlkICVkKVxuIiwgZF9jb25maWctPmRpc2tzW2ldLmJhY2tlbmRf
ZG9taWQpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoZnJvbnRlbmRfZG9t
aWQgJWQpXG4iLCBkb21pZCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChw
aHlzcGF0aCAlcylcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS5wZGV2X3BhdGgp
Ow0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQocGh5c3R5cGUgJWQpXG4iLCBk
X2NvbmZpZy0+ZGlza3NbaV0uYmFja2VuZCk7DQotICAgICAgICBwcmludGYo
Ilx0XHRcdCh2aXJ0cGF0aCAlcylcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS52
ZGV2KTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KHVucGx1Z2dhYmxlICVk
KVxuIiwgZF9jb25maWctPmRpc2tzW2ldLnJlbW92YWJsZSk7DQotICAgICAg
ICBwcmludGYoIlx0XHRcdChyZWFkd3JpdGUgJWQpXG4iLCBkX2NvbmZpZy0+
ZGlza3NbaV0ucmVhZHdyaXRlKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0
KGlzX2Nkcm9tICVkKVxuIiwgZF9jb25maWctPmRpc2tzW2ldLmlzX2Nkcm9t
KTsNCi0gICAgICAgIHByaW50ZigiXHRcdClcbiIpOw0KLSAgICAgICAgcHJp
bnRmKCJcdClcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0KGRldmlj
ZVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdCh0YXBcbiIpOw0K
KyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChiYWNrZW5kX2RvbWlkICVk
KVxuIiwgZF9jb25maWctPmRpc2tzW2ldLmJhY2tlbmRfZG9taWQpOw0KKyAg
ICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChmcm9udGVuZF9kb21pZCAlZClc
biIsIGRvbWlkKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQocGh5
c3BhdGggJXMpXG4iLCBkX2NvbmZpZy0+ZGlza3NbaV0ucGRldl9wYXRoKTsN
CisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQocGh5c3R5cGUgJWQpXG4i
LCBkX2NvbmZpZy0+ZGlza3NbaV0uYmFja2VuZCk7DQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHRcdFx0KHZpcnRwYXRoICVzKVxuIiwgZF9jb25maWctPmRp
c2tzW2ldLnZkZXYpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdCh1
bnBsdWdnYWJsZSAlZClcbiIsIGRfY29uZmlnLT5kaXNrc1tpXS5yZW1vdmFi
bGUpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChyZWFkd3JpdGUg
JWQpXG4iLCBkX2NvbmZpZy0+ZGlza3NbaV0ucmVhZHdyaXRlKTsNCisgICAg
ICAgIGZwcmludGYoZmgsICJcdFx0XHQoaXNfY2Ryb20gJWQpXG4iLCBkX2Nv
bmZpZy0+ZGlza3NbaV0uaXNfY2Ryb20pOw0KKyAgICAgICAgZnByaW50Zihm
aCwgIlx0XHQpXG4iKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdClcbiIp
Ow0KICAgICB9DQogDQogICAgIGZvciAoaSA9IDA7IGkgPCBkX2NvbmZpZy0+
bnVtX25pY3M7IGkrKykgew0KLSAgICAgICAgcHJpbnRmKCJcdChkZXZpY2Vc
biIpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0KHZpZlxuIik7DQorICAgICAg
ICBmcHJpbnRmKGZoLCAiXHQoZGV2aWNlXG4iKTsNCisgICAgICAgIGZwcmlu
dGYoZmgsICJcdFx0KHZpZlxuIik7DQogICAgICAgICBpZiAoZF9jb25maWct
Pm5pY3NbaV0uaWZuYW1lKQ0KLSAgICAgICAgICAgIHByaW50ZigiXHRcdFx0
KHZpZm5hbWUgJXMpXG4iLCBkX2NvbmZpZy0+bmljc1tpXS5pZm5hbWUpOw0K
LSAgICAgICAgcHJpbnRmKCJcdFx0XHQoYmFja2VuZF9kb21pZCAlZClcbiIs
IGRfY29uZmlnLT5uaWNzW2ldLmJhY2tlbmRfZG9taWQpOw0KLSAgICAgICAg
cHJpbnRmKCJcdFx0XHQoZnJvbnRlbmRfZG9taWQgJWQpXG4iLCBkb21pZCk7
DQotICAgICAgICBwcmludGYoIlx0XHRcdChkZXZpZCAlZClcbiIsIGRfY29u
ZmlnLT5uaWNzW2ldLmRldmlkKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0
KG10dSAlZClcbiIsIGRfY29uZmlnLT5uaWNzW2ldLm10dSk7DQotICAgICAg
ICBwcmludGYoIlx0XHRcdChtb2RlbCAlcylcbiIsIGRfY29uZmlnLT5uaWNz
W2ldLm1vZGVsKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KG1hYyAlMDJ4
JTAyeCUwMnglMDJ4JTAyeCUwMngpXG4iLA0KKyAgICAgICAgICAgIGZwcmlu
dGYoZmgsICJcdFx0XHQodmlmbmFtZSAlcylcbiIsIGRfY29uZmlnLT5uaWNz
W2ldLmlmbmFtZSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KGJh
Y2tlbmRfZG9taWQgJWQpXG4iLCBkX2NvbmZpZy0+bmljc1tpXS5iYWNrZW5k
X2RvbWlkKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoZnJvbnRl
bmRfZG9taWQgJWQpXG4iLCBkb21pZCk7DQorICAgICAgICBmcHJpbnRmKGZo
LCAiXHRcdFx0KGRldmlkICVkKVxuIiwgZF9jb25maWctPm5pY3NbaV0uZGV2
aWQpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChtdHUgJWQpXG4i
LCBkX2NvbmZpZy0+bmljc1tpXS5tdHUpOw0KKyAgICAgICAgZnByaW50Zihm
aCwgIlx0XHRcdChtb2RlbCAlcylcbiIsIGRfY29uZmlnLT5uaWNzW2ldLm1v
ZGVsKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQobWFjICUwMngl
MDJ4JTAyeCUwMnglMDJ4JTAyeClcbiIsDQogICAgICAgICAgICAgICAgZF9j
b25maWctPm5pY3NbaV0ubWFjWzBdLCBkX2NvbmZpZy0+bmljc1tpXS5tYWNb
MV0sDQogICAgICAgICAgICAgICAgZF9jb25maWctPm5pY3NbaV0ubWFjWzJd
LCBkX2NvbmZpZy0+bmljc1tpXS5tYWNbM10sDQogICAgICAgICAgICAgICAg
ZF9jb25maWctPm5pY3NbaV0ubWFjWzRdLCBkX2NvbmZpZy0+bmljc1tpXS5t
YWNbNV0pOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0KVxuIik7DQotICAgICAg
ICBwcmludGYoIlx0KVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRc
dClcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0KVxuIik7DQogICAg
IH0NCiANCiAgICAgZm9yIChpID0gMDsgaSA8IGRfY29uZmlnLT5udW1fcGNp
ZGV2czsgaSsrKSB7DQotICAgICAgICBwcmludGYoIlx0KGRldmljZVxuIik7
DQotICAgICAgICBwcmludGYoIlx0XHQocGNpXG4iKTsNCi0gICAgICAgIHBy
aW50ZigiXHRcdFx0KHBjaSBkZXYgJTA0eDolMDJ4OiUwMnguJTAxeEAlMDJ4
KVxuIiwNCisgICAgICAgIGZwcmludGYoZmgsICJcdChkZXZpY2VcbiIpOw0K
KyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQocGNpXG4iKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdFx0XHQocGNpIGRldiAlMDR4OiUwMng6JTAyeC4l
MDF4QCUwMngpXG4iLA0KICAgICAgICAgICAgICAgIGRfY29uZmlnLT5wY2lk
ZXZzW2ldLmRvbWFpbiwgZF9jb25maWctPnBjaWRldnNbaV0uYnVzLA0KICAg
ICAgICAgICAgICAgIGRfY29uZmlnLT5wY2lkZXZzW2ldLmRldiwgZF9jb25m
aWctPnBjaWRldnNbaV0uZnVuYywNCiAgICAgICAgICAgICAgICBkX2NvbmZp
Zy0+cGNpZGV2c1tpXS52ZGV2Zm4pOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0
XHQob3B0cyBtc2l0cmFuc2xhdGUgJWQgcG93ZXJfbWdtdCAlZClcbiIsDQor
ICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KG9wdHMgbXNpdHJhbnNsYXRl
ICVkIHBvd2VyX21nbXQgJWQpXG4iLA0KICAgICAgICAgICAgICAgIGRfY29u
ZmlnLT5wY2lkZXZzW2ldLm1zaXRyYW5zbGF0ZSwNCiAgICAgICAgICAgICAg
ICBkX2NvbmZpZy0+cGNpZGV2c1tpXS5wb3dlcl9tZ210KTsNCi0gICAgICAg
IHByaW50ZigiXHRcdClcbiIpOw0KLSAgICAgICAgcHJpbnRmKCJcdClcbiIp
Ow0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHQpXG4iKTsNCisgICAgICAg
IGZwcmludGYoZmgsICJcdClcbiIpOw0KICAgICB9DQogDQogICAgIGZvciAo
aSA9IDA7IGkgPCBkX2NvbmZpZy0+bnVtX3ZmYnM7IGkrKykgew0KLSAgICAg
ICAgcHJpbnRmKCJcdChkZXZpY2VcbiIpOw0KLSAgICAgICAgcHJpbnRmKCJc
dFx0KHZmYlxuIik7DQotICAgICAgICBwcmludGYoIlx0XHRcdChiYWNrZW5k
X2RvbWlkICVkKVxuIiwgZF9jb25maWctPnZmYnNbaV0uYmFja2VuZF9kb21p
ZCk7DQotICAgICAgICBwcmludGYoIlx0XHRcdChmcm9udGVuZF9kb21pZCAl
ZClcbiIsIGRvbWlkKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGRldmlk
ICVkKVxuIiwgZF9jb25maWctPnZmYnNbaV0uZGV2aWQpOw0KLSAgICAgICAg
cHJpbnRmKCJcdFx0XHQodm5jICVzKVxuIiwNCisgICAgICAgIGZwcmludGYo
ZmgsICJcdChkZXZpY2VcbiIpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0
XHQodmZiXG4iKTsNCisgICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQoYmFj
a2VuZF9kb21pZCAlZClcbiIsIGRfY29uZmlnLT52ZmJzW2ldLmJhY2tlbmRf
ZG9taWQpOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChmcm9udGVu
ZF9kb21pZCAlZClcbiIsIGRvbWlkKTsNCisgICAgICAgIGZwcmludGYoZmgs
ICJcdFx0XHQoZGV2aWQgJWQpXG4iLCBkX2NvbmZpZy0+dmZic1tpXS5kZXZp
ZCk7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHRcdFx0KHZuYyAlcylcbiIs
DQogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoZF9j
b25maWctPnZmYnNbaV0udm5jLmVuYWJsZSkpOw0KLSAgICAgICAgcHJpbnRm
KCJcdFx0XHQodm5jbGlzdGVuICVzKVxuIiwgZF9jb25maWctPnZmYnNbaV0u
dm5jLmxpc3Rlbik7DQotICAgICAgICBwcmludGYoIlx0XHRcdCh2bmNkaXNw
bGF5ICVkKVxuIiwgZF9jb25maWctPnZmYnNbaV0udm5jLmRpc3BsYXkpOw0K
LSAgICAgICAgcHJpbnRmKCJcdFx0XHQodm5jdW51c2VkICVzKVxuIiwNCisg
ICAgICAgIGZwcmludGYoZmgsICJcdFx0XHQodm5jbGlzdGVuICVzKVxuIiwg
ZF9jb25maWctPnZmYnNbaV0udm5jLmxpc3Rlbik7DQorICAgICAgICBmcHJp
bnRmKGZoLCAiXHRcdFx0KHZuY2Rpc3BsYXkgJWQpXG4iLCBkX2NvbmZpZy0+
dmZic1tpXS52bmMuZGlzcGxheSk7DQorICAgICAgICBmcHJpbnRmKGZoLCAi
XHRcdFx0KHZuY3VudXNlZCAlcylcbiIsDQogICAgICAgICAgICAgICAgbGli
eGxfZGVmYm9vbF90b19zdHJpbmcoZF9jb25maWctPnZmYnNbaV0udm5jLmZp
bmR1bnVzZWQpKTsNCi0gICAgICAgIHByaW50ZigiXHRcdFx0KGtleW1hcCAl
cylcbiIsIGRfY29uZmlnLT52ZmJzW2ldLmtleW1hcCk7DQotICAgICAgICBw
cmludGYoIlx0XHRcdChzZGwgJXMpXG4iLA0KKyAgICAgICAgZnByaW50Zihm
aCwgIlx0XHRcdChrZXltYXAgJXMpXG4iLCBkX2NvbmZpZy0+dmZic1tpXS5r
ZXltYXApOw0KKyAgICAgICAgZnByaW50ZihmaCwgIlx0XHRcdChzZGwgJXMp
XG4iLA0KICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5n
KGRfY29uZmlnLT52ZmJzW2ldLnNkbC5lbmFibGUpKTsNCi0gICAgICAgIHBy
aW50ZigiXHRcdFx0KG9wZW5nbCAlcylcbiIsDQorICAgICAgICBmcHJpbnRm
KGZoLCAiXHRcdFx0KG9wZW5nbCAlcylcbiIsDQogICAgICAgICAgICAgICAg
bGlieGxfZGVmYm9vbF90b19zdHJpbmcoZF9jb25maWctPnZmYnNbaV0uc2Rs
Lm9wZW5nbCkpOw0KLSAgICAgICAgcHJpbnRmKCJcdFx0XHQoZGlzcGxheSAl
cylcbiIsIGRfY29uZmlnLT52ZmJzW2ldLnNkbC5kaXNwbGF5KTsNCi0gICAg
ICAgIHByaW50ZigiXHRcdFx0KHhhdXRob3JpdHkgJXMpXG4iLCBkX2NvbmZp
Zy0+dmZic1tpXS5zZGwueGF1dGhvcml0eSk7DQotICAgICAgICBwcmludGYo
Ilx0XHQpXG4iKTsNCi0gICAgICAgIHByaW50ZigiXHQpXG4iKTsNCisgICAg
ICAgIGZwcmludGYoZmgsICJcdFx0XHQoZGlzcGxheSAlcylcbiIsIGRfY29u
ZmlnLT52ZmJzW2ldLnNkbC5kaXNwbGF5KTsNCisgICAgICAgIGZwcmludGYo
ZmgsICJcdFx0XHQoeGF1dGhvcml0eSAlcylcbiIsIGRfY29uZmlnLT52ZmJz
W2ldLnNkbC54YXV0aG9yaXR5KTsNCisgICAgICAgIGZwcmludGYoZmgsICJc
dFx0KVxuIik7DQorICAgICAgICBmcHJpbnRmKGZoLCAiXHQpXG4iKTsNCiAg
ICAgfQ0KLSAgICBwcmludGYoIilcbiIpOw0KKyAgICBmcHJpbnRmKGZoLCAi
KVxuIik7DQogfQ0KIA0KIA0KLS0tIHhlbi00LjUuMC1yYzEvdG9vbHMvbGli
eGwveGwuaC5vcmlnCTIwMTQtMTAtMjQgMTU6MjI6NDAuMDAwMDAwMDAwICsw
MTAwDQorKysgeGVuLTQuNS4wLXJjMS90b29scy9saWJ4bC94bC5oCTIwMTQt
MTEtMjYgMjI6MzA6NTguNDE2Mzk0MDgyICswMDAwDQpAQCAtMTg2LDcgKzE4
Niw3IEBADQogfTsNCiBleHRlcm4gZW51bSBvdXRwdXRfZm9ybWF0IGRlZmF1
bHRfb3V0cHV0X2Zvcm1hdDsNCiANCi1leHRlcm4gdm9pZCBwcmludGZfaW5m
b19zZXhwKGludCBkb21pZCwgbGlieGxfZG9tYWluX2NvbmZpZyAqZF9jb25m
aWcpOw0KK2V4dGVybiB2b2lkIHByaW50Zl9pbmZvX3NleHAoaW50IGRvbWlk
LCBsaWJ4bF9kb21haW5fY29uZmlnICpkX2NvbmZpZywgRklMRSAqZmgpOw0K
IA0KICNkZWZpbmUgWExfR0xPQkFMX0NPTkZJRyBYRU5fQ09ORklHX0RJUiAi
L3hsLmNvbmYiDQogI2RlZmluZSBYTF9MT0NLX0ZJTEUgWEVOX0xPQ0tfRElS
ICIveGwiDQo=

---559023410-351212254-1417163529=:1345
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

---559023410-351212254-1417163529=:1345--


From xen-devel-bounces@lists.xen.org Fri Nov 28 08:50:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 08:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuHG2-0007tk-N9; Fri, 28 Nov 2014 08:50:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuHG1-0007tf-60
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 08:50:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A2/13-09842-45738745; Fri, 28 Nov 2014 08:50:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417164627!11994075!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16069 invoked from network); 28 Nov 2014 08:50:27 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 08:50:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 08:50:27 +0000
Message-Id: <54784563020000780004B547@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 08:50:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jun Nakajima" <jun.nakajima@intel.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
	<54746F59020000780004A9E9@mail.emea.novell.com>
	<5476B6A8.4060706@ihonk.com>
	<5476FC9C020000780004B11D@mail.emea.novell.com>
	<54783158.3050601@ihonk.com>
In-Reply-To: <54783158.3050601@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Steve Freitas <sflist@ihonk.com>, Don Slutz <dslutz@verizon.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 09:24, <sflist@ihonk.com> wrote:
>> And with 6 errata
>> documented it's not all that unlikely that there's a 7th one with
>> MONITOR/MWAIT behavior. The commit you bisected to (and
>> which you had verified to be the culprit by just forcing
>> arch_skip_send_event_check() to always return false) could be
>> reasonably assumed to be broken only when MWAIT use for all
>> C states didn't work.
> 
> Now I did get a hang with max_cstate=3 and mwait-idle=0.

According to the data you provided earlier, max_cstate=3 is
identical to not using that option at all when you also use
mwait-idle=0. It would make a difference only when not using
that latter option (and I specifically pointed this out in earlier
replies).

> May I assume 
> that mwait-idle=0 means that ACPI is responsible for the throttling?

ACPI is providing the data to do C state management in that case,
but it's still Xen doing things.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 08:50:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 08:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuHG2-0007tk-N9; Fri, 28 Nov 2014 08:50:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuHG1-0007tf-60
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 08:50:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A2/13-09842-45738745; Fri, 28 Nov 2014 08:50:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417164627!11994075!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16069 invoked from network); 28 Nov 2014 08:50:27 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 08:50:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 08:50:27 +0000
Message-Id: <54784563020000780004B547@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 08:50:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jun Nakajima" <jun.nakajima@intel.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
	<54746F59020000780004A9E9@mail.emea.novell.com>
	<5476B6A8.4060706@ihonk.com>
	<5476FC9C020000780004B11D@mail.emea.novell.com>
	<54783158.3050601@ihonk.com>
In-Reply-To: <54783158.3050601@ihonk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Steve Freitas <sflist@ihonk.com>, Don Slutz <dslutz@verizon.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.11.14 at 09:24, <sflist@ihonk.com> wrote:
>> And with 6 errata
>> documented it's not all that unlikely that there's a 7th one with
>> MONITOR/MWAIT behavior. The commit you bisected to (and
>> which you had verified to be the culprit by just forcing
>> arch_skip_send_event_check() to always return false) could be
>> reasonably assumed to be broken only when MWAIT use for all
>> C states didn't work.
> 
> Now I did get a hang with max_cstate=3 and mwait-idle=0.

According to the data you provided earlier, max_cstate=3 is
identical to not using that option at all when you also use
mwait-idle=0. It would make a difference only when not using
that latter option (and I specifically pointed this out in earlier
replies).

> May I assume 
> that mwait-idle=0 means that ACPI is responsible for the throttling?

ACPI is providing the data to do C state management in that case,
but it's still Xen doing things.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:08:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuHWs-0000Jg-3V; Fri, 28 Nov 2014 09:07:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuHWr-0000Ja-2E
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 09:07:53 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	31/F1-17735-86B38745; Fri, 28 Nov 2014 09:07:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417165670!14399344!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12613 invoked from network); 28 Nov 2014 09:07:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 09:07:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208";a="197664115"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 04:07:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuHWd-0006XK-Pv;
	Fri, 28 Nov 2014 09:07:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuHWd-0007qT-JO;
	Fri, 28 Nov 2014 09:07:39 +0000
Date: Fri, 28 Nov 2014 09:07:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31882-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31882: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31882 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31882/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31781

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 31781

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  a39f202031d7f1d8d9e14b8c3d7d11c812db253e
baseline version:
 xen                  7679aeb444ed3bc4de0f473c16c47eab7d2f9d33

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-sedf-pin host-install(3)

Not pushing.

------------------------------------------------------------
commit a39f202031d7f1d8d9e14b8c3d7d11c812db253e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:11:57 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: c5397354b998d030b021810b8202de93b9526818
    master date: 2014-11-27 14:01:40 +0100

commit 98c78711764082171b3fa189793c6db904f65ebc
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:10:52 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: 0ad715304b04739fd2fc9517ce8671d3947c7621
    master date: 2014-11-27 14:00:23 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:08:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuHWs-0000Jg-3V; Fri, 28 Nov 2014 09:07:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuHWr-0000Ja-2E
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 09:07:53 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	31/F1-17735-86B38745; Fri, 28 Nov 2014 09:07:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417165670!14399344!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12613 invoked from network); 28 Nov 2014 09:07:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 09:07:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208";a="197664115"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 04:07:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuHWd-0006XK-Pv;
	Fri, 28 Nov 2014 09:07:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuHWd-0007qT-JO;
	Fri, 28 Nov 2014 09:07:39 +0000
Date: Fri, 28 Nov 2014 09:07:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31882-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31882: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31882 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31882/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31781

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 31781

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  a39f202031d7f1d8d9e14b8c3d7d11c812db253e
baseline version:
 xen                  7679aeb444ed3bc4de0f473c16c47eab7d2f9d33

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-amd64-xl-sedf-pin host-install(3)

Not pushing.

------------------------------------------------------------
commit a39f202031d7f1d8d9e14b8c3d7d11c812db253e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:11:57 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: c5397354b998d030b021810b8202de93b9526818
    master date: 2014-11-27 14:01:40 +0100

commit 98c78711764082171b3fa189793c6db904f65ebc
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:10:52 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: 0ad715304b04739fd2fc9517ce8671d3947c7621
    master date: 2014-11-27 14:00:23 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:16:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09: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 1XuHf4-0000xL-CT; Fri, 28 Nov 2014 09:16:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuHf3-0000x9-35
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 09:16:21 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	C8/9C-17958-46D38745; Fri, 28 Nov 2014 09:16:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417166179!14402029!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23141 invoked from network); 28 Nov 2014 09:16:19 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 09:16:19 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 09:16:19 +0000
Message-Id: <54784B72020000780004B565@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 09:16:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liang Li" <liang.z.li@intel.com>
References: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
In-Reply-To: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to 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 28.11.14 at 04:28, <liang.z.li@intel.com> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4287,7 +4287,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
>               !host_tsc_is_safe() )
>              *edx &= ~cpufeat_mask(X86_FEATURE_RDTSCP);
>          /* Hide 1GB-superpage feature if we can't emulate it. */
> -        if (!hvm_pse1gb_supported(d))
> +        if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
>              *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);

With

#define hvm_pse1gb_supported(d) \
    (cpu_has_page1gb && paging_mode_hap(d))

the change above is pointless. While, considering this, comments on
v2 may have been misleading, you should have simply updated the
patch description instead to clarify why the v2 change was okay
even for the shadow mode case.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:16:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09: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 1XuHf4-0000xL-CT; Fri, 28 Nov 2014 09:16:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuHf3-0000x9-35
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 09:16:21 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	C8/9C-17958-46D38745; Fri, 28 Nov 2014 09:16:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417166179!14402029!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23141 invoked from network); 28 Nov 2014 09:16:19 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 09:16:19 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 09:16:19 +0000
Message-Id: <54784B72020000780004B565@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 09:16:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liang Li" <liang.z.li@intel.com>
References: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
In-Reply-To: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to 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 28.11.14 at 04:28, <liang.z.li@intel.com> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4287,7 +4287,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
>               !host_tsc_is_safe() )
>              *edx &= ~cpufeat_mask(X86_FEATURE_RDTSCP);
>          /* Hide 1GB-superpage feature if we can't emulate it. */
> -        if (!hvm_pse1gb_supported(d))
> +        if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
>              *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);

With

#define hvm_pse1gb_supported(d) \
    (cpu_has_page1gb && paging_mode_hap(d))

the change above is pointless. While, considering this, comments on
v2 may have been misleading, you should have simply updated the
patch description instead to clarify why the v2 change was okay
even for the shadow mode case.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:24:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09:24:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuHmY-0001dc-Cd; Fri, 28 Nov 2014 09:24:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuHmW-0001dV-MS
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 09:24:04 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5E/07-09842-43F38745; Fri, 28 Nov 2014 09:24:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417166643!12004204!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12255 invoked from network); 28 Nov 2014 09:24:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 09:24:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 09:24:03 +0000
Message-Id: <54784D44020000780004B576@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 09:24:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-31882-mainreport@xen.org>
In-Reply-To: <osstest-31882-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [xen-4.4-testing test] 31882: regressions -
 trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.11.14 at 10:07, <Ian.Jackson@eu.citrix.com> wrote:
> flight 31882 xen-4.4-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31882/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31781

Wasn't the swiotlb problem supposed to be dealt with by now?
swiotlb=65536 looks to be in place here, yet that still appears to
not be big enough...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:24:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09:24:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuHmY-0001dc-Cd; Fri, 28 Nov 2014 09:24:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuHmW-0001dV-MS
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 09:24:04 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5E/07-09842-43F38745; Fri, 28 Nov 2014 09:24:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417166643!12004204!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12255 invoked from network); 28 Nov 2014 09:24:03 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 09:24:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 09:24:03 +0000
Message-Id: <54784D44020000780004B576@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 09:24:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-31882-mainreport@xen.org>
In-Reply-To: <osstest-31882-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [xen-4.4-testing test] 31882: regressions -
 trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.11.14 at 10:07, <Ian.Jackson@eu.citrix.com> wrote:
> flight 31882 xen-4.4-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31882/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31781

Wasn't the swiotlb problem supposed to be dealt with by now?
swiotlb=65536 looks to be in place here, yet that still appears to
not be big enough...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:44:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09: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 1XuI6G-0002jJ-IS; Fri, 28 Nov 2014 09:44:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XuI6F-0002jD-Gq
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 09:44:28 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	D3/04-02576-AF348745; Fri, 28 Nov 2014 09:44:26 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417167864!15460113!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7107 invoked from network); 28 Nov 2014 09:44:26 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 09:44:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1417167864; h=Received :
	Content-Type : Mime-Version : Subject : From : X-Mailer : In-Reply-To :
	Date : Cc : Content-Transfer-Encoding : Message-Id : References : To;
	bh=hfhro8ZCsKDIJLAd/ko9zJloE3EtvoZ3ASBXZsDHa7s=;
	b=UbgG3mPJOsNGgGgXMkvq5fMRCaIW5ryGHHM0C7KwgO5NOe2GEWLC3s+T6usczCSrHqYfFB9g/kuTmSGnZRNZG9+WawYWpKF51+Gs55XFkN1h7EjZtV0pIIH39Lnm5+I9TgsBiUK8COXoJEsYKJ80XUqwS5HCCU17OdIWPx4FSwU=
Received: from [10.0.0.195] ([::ffff:174.65.75.5])
	(AUTH: PLAIN sflist@ihonk.com, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by wapdot.org with ESMTPSA; Fri, 28 Nov 2014 01:44:23 -0800
	id 0000000000030436.547843F7.00000446
Mime-Version: 1.0 (1.0)
From: Steve Freitas <sflist@ihonk.com>
X-Mailer: iPhone Mail (12B435)
In-Reply-To: <54784563020000780004B547@mail.emea.novell.com>
Date: Fri, 28 Nov 2014 01:44:21 -0800
Message-Id: <7798614F-6FF1-48C3-969F-EFD8BDA059D6@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
	<54746F59020000780004A9E9@mail.emea.novell.com>
	<5476B6A8.4060706@ihonk.com>
	<5476FC9C020000780004B11D@mail.emea.novell.com>
	<54783158.3050601@ihonk.com>
	<54784563020000780004B547@mail.emea.novell.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Don Slutz <dslutz@verizon.com>, Donald D Dugger <donald.d.dugger@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Nov 28, 2014, at 00:50, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 28.11.14 at 09:24, <sflist@ihonk.com> wrote:
>>> And with 6 errata
>>> documented it's not all that unlikely that there's a 7th one with
>>> MONITOR/MWAIT behavior. The commit you bisected to (and
>>> which you had verified to be the culprit by just forcing
>>> arch_skip_send_event_check() to always return false) could be
>>> reasonably assumed to be broken only when MWAIT use for all
>>> C states didn't work.
>> 
>> Now I did get a hang with max_cstate=3 and mwait-idle=0.
> 
> According to the data you provided earlier, max_cstate=3 is
> identical to not using that option at all when you also use
> mwait-idle=0. It would make a difference only when not using
> that latter option (and I specifically pointed this out in earlier
> replies).
> 

Apologies for asking you to repeat yourself. Most of this stuff is over my head -- the only time I was this far down the rabbit hole was on an 8051.  Thanks for your patience. :-)

Steve


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:44:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09: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 1XuI6G-0002jJ-IS; Fri, 28 Nov 2014 09:44:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sflist@ihonk.com>) id 1XuI6F-0002jD-Gq
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 09:44:28 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	D3/04-02576-AF348745; Fri, 28 Nov 2014 09:44:26 +0000
X-Env-Sender: sflist@ihonk.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417167864!15460113!1
X-Originating-IP: [74.50.55.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7107 invoked from network); 28 Nov 2014 09:44:26 -0000
Received: from mail.newportit.com (HELO wapdot.org) (74.50.55.245)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 09:44:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ihonk.com;
	i=@ihonk.com; q=dns/txt; s=pentamerous; t=1417167864; h=Received :
	Content-Type : Mime-Version : Subject : From : X-Mailer : In-Reply-To :
	Date : Cc : Content-Transfer-Encoding : Message-Id : References : To;
	bh=hfhro8ZCsKDIJLAd/ko9zJloE3EtvoZ3ASBXZsDHa7s=;
	b=UbgG3mPJOsNGgGgXMkvq5fMRCaIW5ryGHHM0C7KwgO5NOe2GEWLC3s+T6usczCSrHqYfFB9g/kuTmSGnZRNZG9+WawYWpKF51+Gs55XFkN1h7EjZtV0pIIH39Lnm5+I9TgsBiUK8COXoJEsYKJ80XUqwS5HCCU17OdIWPx4FSwU=
Received: from [10.0.0.195] ([::ffff:174.65.75.5])
	(AUTH: PLAIN sflist@ihonk.com, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by wapdot.org with ESMTPSA; Fri, 28 Nov 2014 01:44:23 -0800
	id 0000000000030436.547843F7.00000446
Mime-Version: 1.0 (1.0)
From: Steve Freitas <sflist@ihonk.com>
X-Mailer: iPhone Mail (12B435)
In-Reply-To: <54784563020000780004B547@mail.emea.novell.com>
Date: Fri, 28 Nov 2014 01:44:21 -0800
Message-Id: <7798614F-6FF1-48C3-969F-EFD8BDA059D6@ihonk.com>
References: <5457F79B.2020300@ihonk.com> <20141104082012.GY12451@reaktio.net>
	<5458B55C0200007800044B33@mail.emea.novell.com>
	<5460716A.7090905@ihonk.com>
	<54608A8B0200007800045E58@mail.emea.novell.com>
	<54611A86.4000200@ihonk.com>
	<5461D15C02000078000464D7@mail.emea.novell.com>
	<546A4AD4.3030002@ihonk.com>
	<546B094C0200007800048A5C@mail.emea.novell.com>
	<546D429A.5020906@ihonk.com>
	<546DAD6502000078000492FD@mail.emea.novell.com>
	<546E4A17.5040902@ihonk.com>
	<546F091F0200007800049A1C@smtp.nue.novell.com>
	<54713848.3020401@ihonk.com>
	<5472FE31020000780004A2D5@mail.emea.novell.com>
	<7637FB2C-D2F9-4F5A-B71F-6C444C7F1B71@ihonk.com>
	<54732768020000780004A48C@mail.emea.novell.com>
	<5473AE78.5070505@ihonk.com>
	<547448D7020000780004A919@mail.emea.novell.com>
	<54744E29.8060703@ihonk.com>
	<54746F59020000780004A9E9@mail.emea.novell.com>
	<5476B6A8.4060706@ihonk.com>
	<5476FC9C020000780004B11D@mail.emea.novell.com>
	<54783158.3050601@ihonk.com>
	<54784563020000780004B547@mail.emea.novell.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Don Slutz <dslutz@verizon.com>, Donald D Dugger <donald.d.dugger@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Nov 28, 2014, at 00:50, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 28.11.14 at 09:24, <sflist@ihonk.com> wrote:
>>> And with 6 errata
>>> documented it's not all that unlikely that there's a 7th one with
>>> MONITOR/MWAIT behavior. The commit you bisected to (and
>>> which you had verified to be the culprit by just forcing
>>> arch_skip_send_event_check() to always return false) could be
>>> reasonably assumed to be broken only when MWAIT use for all
>>> C states didn't work.
>> 
>> Now I did get a hang with max_cstate=3 and mwait-idle=0.
> 
> According to the data you provided earlier, max_cstate=3 is
> identical to not using that option at all when you also use
> mwait-idle=0. It would make a difference only when not using
> that latter option (and I specifically pointed this out in earlier
> replies).
> 

Apologies for asking you to repeat yourself. Most of this stuff is over my head -- the only time I was this far down the rabbit hole was on an 8051.  Thanks for your patience. :-)

Steve


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:58:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09: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 1XuIJ8-0003P9-3S; Fri, 28 Nov 2014 09:57:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuIJ6-0003P2-E0
	for Xen-devel@lists.xen.org; Fri, 28 Nov 2014 09:57:44 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	A5/ED-25727-71748745; Fri, 28 Nov 2014 09:57:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417168660!14414575!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29438 invoked from network); 28 Nov 2014 09:57:41 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 09:57:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 09:57:40 +0000
Message-Id: <54785525020000780004B588@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 09:57:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yu Zhang" <yu.c.zhang@linux.intel.com>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
In-Reply-To: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, donald.d.dugger@intel.com,
	Xen-devel@lists.xen.org, Paul.Durrant@citrix.com,
	zhiyuan.lv@intel.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v4] x86: add p2m_mmio_write_dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.11.14 at 08:59, <yu.c.zhang@linux.intel.com> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2838,7 +2838,8 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
>       * to the mmio handler.
>       */
>      if ( (p2mt == p2m_mmio_dm) || 
> -         (npfec.write_access && (p2mt == p2m_ram_ro)) )
> +         (npfec.write_access &&
> +		((p2mt == p2m_ram_ro) || (p2mt == p2m_mmio_write_dm))) )

Why are you corrupting indentation here?

Furthermore the code you modify here suggests that p2m_ram_ro
already has the needed semantics - writes get passed to the DM.
None of the other changes you make, and none of the other uses
of p2m_ram_ro appear to be in conflict with your intentions, so
you'd really need to explain better why you need the new type.

> @@ -5922,6 +5923,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>                  a.mem_type =  HVMMEM_ram_rw;
>              else if ( p2m_is_grant(t) )
>                  a.mem_type =  HVMMEM_ram_rw;
> +            else if ( t == p2m_mmio_write_dm )
> +                a.mem_type = HVMMEM_mmio_write_dm;
>              else
>                  a.mem_type =  HVMMEM_mmio_dm;
>              rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
> @@ -5941,7 +5944,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>          static const p2m_type_t memtype[] = {
>              [HVMMEM_ram_rw]  = p2m_ram_rw,
>              [HVMMEM_ram_ro]  = p2m_ram_ro,
> -            [HVMMEM_mmio_dm] = p2m_mmio_dm
> +            [HVMMEM_mmio_dm] = p2m_mmio_dm,
> +            [HVMMEM_mmio_write_dm] = p2m_mmio_write_dm
>          };
>  
>          if ( copy_from_guest(&a, arg, 1) )
> @@ -5987,14 +5991,17 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>                  rc = -EAGAIN;
>                  goto param_fail4;
>              }
> +

Stray addition of a blank line?

>              if ( !p2m_is_ram(t) &&
> -                 (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) )
> +                 (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
> +                 t != p2m_mmio_write_dm )

Do you really want to permit e.g. transitions between mmio_dm and
mmio_write_dm? We should be as restrictive as possible here to not
open up paths to security problems.

>              {
>                  put_gfn(d, pfn);
>                  goto param_fail4;
>              }
>  
>              rc = p2m_change_type_one(d, pfn, t, memtype[a.hvmmem_type]);
> +
>              put_gfn(d, pfn);
>              if ( rc )
>                  goto param_fail4;

Another stray newline addition.

> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -72,6 +72,7 @@ typedef enum {
>      p2m_ram_shared = 12,          /* Shared or sharable memory */
>      p2m_ram_broken = 13,          /* Broken page, access cause domain crash */
>      p2m_map_foreign  = 14,        /* ram pages from foreign domain */
> +    p2m_mmio_write_dm = 15,       /* Read-only; writes go to the device model */
>  } p2m_type_t;
>  
>  /* Modifiers to the query */
> 

If the new type is really needed, shouldn't this get added to
P2M_RO_TYPES?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:58:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09: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 1XuIJ8-0003P9-3S; Fri, 28 Nov 2014 09:57:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuIJ6-0003P2-E0
	for Xen-devel@lists.xen.org; Fri, 28 Nov 2014 09:57:44 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	A5/ED-25727-71748745; Fri, 28 Nov 2014 09:57:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417168660!14414575!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29438 invoked from network); 28 Nov 2014 09:57:41 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 09:57:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 09:57:40 +0000
Message-Id: <54785525020000780004B588@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 09:57:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yu Zhang" <yu.c.zhang@linux.intel.com>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
In-Reply-To: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, donald.d.dugger@intel.com,
	Xen-devel@lists.xen.org, Paul.Durrant@citrix.com,
	zhiyuan.lv@intel.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v4] x86: add p2m_mmio_write_dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.11.14 at 08:59, <yu.c.zhang@linux.intel.com> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2838,7 +2838,8 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
>       * to the mmio handler.
>       */
>      if ( (p2mt == p2m_mmio_dm) || 
> -         (npfec.write_access && (p2mt == p2m_ram_ro)) )
> +         (npfec.write_access &&
> +		((p2mt == p2m_ram_ro) || (p2mt == p2m_mmio_write_dm))) )

Why are you corrupting indentation here?

Furthermore the code you modify here suggests that p2m_ram_ro
already has the needed semantics - writes get passed to the DM.
None of the other changes you make, and none of the other uses
of p2m_ram_ro appear to be in conflict with your intentions, so
you'd really need to explain better why you need the new type.

> @@ -5922,6 +5923,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>                  a.mem_type =  HVMMEM_ram_rw;
>              else if ( p2m_is_grant(t) )
>                  a.mem_type =  HVMMEM_ram_rw;
> +            else if ( t == p2m_mmio_write_dm )
> +                a.mem_type = HVMMEM_mmio_write_dm;
>              else
>                  a.mem_type =  HVMMEM_mmio_dm;
>              rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
> @@ -5941,7 +5944,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>          static const p2m_type_t memtype[] = {
>              [HVMMEM_ram_rw]  = p2m_ram_rw,
>              [HVMMEM_ram_ro]  = p2m_ram_ro,
> -            [HVMMEM_mmio_dm] = p2m_mmio_dm
> +            [HVMMEM_mmio_dm] = p2m_mmio_dm,
> +            [HVMMEM_mmio_write_dm] = p2m_mmio_write_dm
>          };
>  
>          if ( copy_from_guest(&a, arg, 1) )
> @@ -5987,14 +5991,17 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>                  rc = -EAGAIN;
>                  goto param_fail4;
>              }
> +

Stray addition of a blank line?

>              if ( !p2m_is_ram(t) &&
> -                 (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) )
> +                 (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
> +                 t != p2m_mmio_write_dm )

Do you really want to permit e.g. transitions between mmio_dm and
mmio_write_dm? We should be as restrictive as possible here to not
open up paths to security problems.

>              {
>                  put_gfn(d, pfn);
>                  goto param_fail4;
>              }
>  
>              rc = p2m_change_type_one(d, pfn, t, memtype[a.hvmmem_type]);
> +
>              put_gfn(d, pfn);
>              if ( rc )
>                  goto param_fail4;

Another stray newline addition.

> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -72,6 +72,7 @@ typedef enum {
>      p2m_ram_shared = 12,          /* Shared or sharable memory */
>      p2m_ram_broken = 13,          /* Broken page, access cause domain crash */
>      p2m_map_foreign  = 14,        /* ram pages from foreign domain */
> +    p2m_mmio_write_dm = 15,       /* Read-only; writes go to the device model */
>  } p2m_type_t;
>  
>  /* Modifiers to the query */
> 

If the new type is really needed, shouldn't this get added to
P2M_RO_TYPES?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09: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 1XuIJm-0003SK-Me; Fri, 28 Nov 2014 09:58:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuIJk-0003S6-JF
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 09:58:24 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	D5/34-02712-F3748745; Fri, 28 Nov 2014 09:58:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417168701!15450817!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29606 invoked from network); 28 Nov 2014 09:58:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 09:58:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208";a="197400775"
Message-ID: <1417168681.19852.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Razvan Cojocaru <rcojocaru@bitdefender.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 09:58:01 +0000
In-Reply-To: <54770242.9000709@bitdefender.com>
References: <54770242.9000709@bitdefender.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xenstore.h clarifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 12:51 +0200, Razvan Cojocaru wrote:

It's a good idea to CC the relevant maintainers if you want their input.

> Hello,
> 
> I know that xc_interface_open() can be safely called several times from
> the same process, and that several processes can each have a bunch of
> xc_interface handles open, and that I shouldn't use an xc_interface
> inherited from the parent in a child process, because xenctrl.h says so.
> 
> Is it safe to assume that the same restrictions / conventions apply to
> xs_handles obtained via xs_open()? Xenstore.h is not explicit. Looking
> at the code, it would seem safe to assume that it can be used in a
> similar manner, but it would be nice to have this confirmed if possible.

I think there's a pretty good chance that the same applies to xenstore
connections made over the device/shared-ring interface.

I'm not really sure about the semantics of a Unix domain socket after a
fork, but I don't expect both parent and child could sanely make use of
it.

So I think the answer is:

      * Connections made with xs_open(0) (which might be shared page or
        socket based) are only guaranteed to work in the parent after
        fork.
      * Connections made with xs_open(XS_OPEN_SOCKETONLY) will be usable
        in either the parent or the child after fork, but not both.
      * xs_daemon_open*() and xs_domain_open() are deprecated synonyms
        for xs_open(0)
      * XS_OPEN_READONLY has not bearing on any of this.

Ian, does that seem right?

Razvan, assuming Ian concurs with the above (or corrects it) then could
you knock up a patch to document the result please.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 09:58:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 09: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 1XuIJm-0003SK-Me; Fri, 28 Nov 2014 09:58:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuIJk-0003S6-JF
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 09:58:24 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	D5/34-02712-F3748745; Fri, 28 Nov 2014 09:58:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417168701!15450817!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29606 invoked from network); 28 Nov 2014 09:58:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 09:58:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208";a="197400775"
Message-ID: <1417168681.19852.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Razvan Cojocaru <rcojocaru@bitdefender.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 09:58:01 +0000
In-Reply-To: <54770242.9000709@bitdefender.com>
References: <54770242.9000709@bitdefender.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xenstore.h clarifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 12:51 +0200, Razvan Cojocaru wrote:

It's a good idea to CC the relevant maintainers if you want their input.

> Hello,
> 
> I know that xc_interface_open() can be safely called several times from
> the same process, and that several processes can each have a bunch of
> xc_interface handles open, and that I shouldn't use an xc_interface
> inherited from the parent in a child process, because xenctrl.h says so.
> 
> Is it safe to assume that the same restrictions / conventions apply to
> xs_handles obtained via xs_open()? Xenstore.h is not explicit. Looking
> at the code, it would seem safe to assume that it can be used in a
> similar manner, but it would be nice to have this confirmed if possible.

I think there's a pretty good chance that the same applies to xenstore
connections made over the device/shared-ring interface.

I'm not really sure about the semantics of a Unix domain socket after a
fork, but I don't expect both parent and child could sanely make use of
it.

So I think the answer is:

      * Connections made with xs_open(0) (which might be shared page or
        socket based) are only guaranteed to work in the parent after
        fork.
      * Connections made with xs_open(XS_OPEN_SOCKETONLY) will be usable
        in either the parent or the child after fork, but not both.
      * xs_daemon_open*() and xs_domain_open() are deprecated synonyms
        for xs_open(0)
      * XS_OPEN_READONLY has not bearing on any of this.

Ian, does that seem right?

Razvan, assuming Ian concurs with the above (or corrects it) then could
you knock up a patch to document the result please.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:18:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:18:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIcl-0004Ti-2Q; Fri, 28 Nov 2014 10:18:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XuIcj-0004Ta-L0
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:18:01 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	05/07-07724-8DB48745; Fri, 28 Nov 2014 10:18:00 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417169877!14438263!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24507 invoked from network); 28 Nov 2014 10:17:58 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:17:58 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=H/bRl5gRPMb6KyD6RY84pvxPtO7Hdz6lKhGudZ/Ssz8XQkHFofaK+ysS2fBRfuRza5yheyhWcAiCi6ZVyguUMeWPeg9wSCcG42DyKhG6w3W/638C/0RZR/q8zcyuB0ahjNbTD0DV2b3/hnhQPzDuyGXDmC4DaU1vj3e+Ou8VCpSsGRVQTx0xBu75s1jumARwHqX7l0m0D+sW5ReL1fvO6sW+pLKApvGNnojRItReaNF4ylHZaxfe3y5CqUn4X97g1Km/xkxqbrORFzkRu/ZxUG9iuHve1muxdRgHhFJyj2Hbg1iIteb1i3wSNMG1CuAld5H4v1CKM8X9jQkjZKFuag==;
	h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=
	message-id:date:from:mime-version:to:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding; s=default;
	bh=cpJQHluLD6RFCO8O6SX/aJNm4Yg=; b=L7MWNLxYxtomyhcM3nrju+qa1gyk
	F8WxI5PVyj8hR3LwaInfRtOxZF1KRDsrdGpgx05I4hntBuF3MtE4q6h4sSxHMVme
	pm/4aKoxQg2Q8LSS7RBf7MJp4iuntzsUFS+0VOY9/vZUVUKdlQ90JKa6veTZ75K/
	VBWxQpMZIG0z+LnCdjDgOBXeMAnVmO8qrWOGrET2JJLJfj6rC1ignIJvpxKKJCAQ
	cap4TuCIPqDszb4o7C5sLke9Gqk9ppmM9MjdgvtpWcKVzgeJpg4sCaAfc/6j+zSc
	mY5B0ZECed8+wQ+P1QNkxt53W7o7wjto3ktEnfWqSt1/LVCXYpd/Z9z6ZA==
Received: (qmail 12057 invoked from network); 28 Nov 2014 12:17:57 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	28 Nov 2014 12:17:57 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 024B5803DF
	for <xen-devel@lists.xen.org>; Fri, 28 Nov 2014 12:17:57 +0200 (EET)
Received: (qmail 10247 invoked from network); 28 Nov 2014 12:17:57 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by smtp03.buh.bitdefender.org with SMTP; 28 Nov 2014 12:17:52 +0200
Message-ID: <54784BD8.20007@bitdefender.com>
Date: Fri, 28 Nov 2014 12:18:00 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <54770242.9000709@bitdefender.com>
	<1417168681.19852.2.camel@citrix.com>
In-Reply-To: <1417168681.19852.2.camel@citrix.com>
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.57990
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 373728,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_LEGIT_VALID_REPLY;
	NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS], SGN:
	[Enabled], URL: [Enabled], RTDA: [Enabled, Hit: No, Details: Error:
	onPost(110)(28)], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xenstore.h clarifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/28/2014 11:58 AM, Ian Campbell wrote:
> On Thu, 2014-11-27 at 12:51 +0200, Razvan Cojocaru wrote:
> 
> It's a good idea to CC the relevant maintainers if you want their input.
> 
>> Hello,
>>
>> I know that xc_interface_open() can be safely called several times from
>> the same process, and that several processes can each have a bunch of
>> xc_interface handles open, and that I shouldn't use an xc_interface
>> inherited from the parent in a child process, because xenctrl.h says so.
>>
>> Is it safe to assume that the same restrictions / conventions apply to
>> xs_handles obtained via xs_open()? Xenstore.h is not explicit. Looking
>> at the code, it would seem safe to assume that it can be used in a
>> similar manner, but it would be nice to have this confirmed if possible.
> 
> I think there's a pretty good chance that the same applies to xenstore
> connections made over the device/shared-ring interface.
> 
> I'm not really sure about the semantics of a Unix domain socket after a
> fork, but I don't expect both parent and child could sanely make use of
> it.
> 
> So I think the answer is:
> 
>       * Connections made with xs_open(0) (which might be shared page or
>         socket based) are only guaranteed to work in the parent after
>         fork.
>       * Connections made with xs_open(XS_OPEN_SOCKETONLY) will be usable
>         in either the parent or the child after fork, but not both.
>       * xs_daemon_open*() and xs_domain_open() are deprecated synonyms
>         for xs_open(0)
>       * XS_OPEN_READONLY has not bearing on any of this.
> 
> Ian, does that seem right?
> 
> Razvan, assuming Ian concurs with the above (or corrects it) then could
> you knock up a patch to document the result please.

Sure, I'll document whatever gets confirmed.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:18:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:18:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIcl-0004Ti-2Q; Fri, 28 Nov 2014 10:18:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XuIcj-0004Ta-L0
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:18:01 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	05/07-07724-8DB48745; Fri, 28 Nov 2014 10:18:00 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417169877!14438263!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24507 invoked from network); 28 Nov 2014 10:17:58 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:17:58 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=H/bRl5gRPMb6KyD6RY84pvxPtO7Hdz6lKhGudZ/Ssz8XQkHFofaK+ysS2fBRfuRza5yheyhWcAiCi6ZVyguUMeWPeg9wSCcG42DyKhG6w3W/638C/0RZR/q8zcyuB0ahjNbTD0DV2b3/hnhQPzDuyGXDmC4DaU1vj3e+Ou8VCpSsGRVQTx0xBu75s1jumARwHqX7l0m0D+sW5ReL1fvO6sW+pLKApvGNnojRItReaNF4ylHZaxfe3y5CqUn4X97g1Km/xkxqbrORFzkRu/ZxUG9iuHve1muxdRgHhFJyj2Hbg1iIteb1i3wSNMG1CuAld5H4v1CKM8X9jQkjZKFuag==;
	h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=
	message-id:date:from:mime-version:to:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding; s=default;
	bh=cpJQHluLD6RFCO8O6SX/aJNm4Yg=; b=L7MWNLxYxtomyhcM3nrju+qa1gyk
	F8WxI5PVyj8hR3LwaInfRtOxZF1KRDsrdGpgx05I4hntBuF3MtE4q6h4sSxHMVme
	pm/4aKoxQg2Q8LSS7RBf7MJp4iuntzsUFS+0VOY9/vZUVUKdlQ90JKa6veTZ75K/
	VBWxQpMZIG0z+LnCdjDgOBXeMAnVmO8qrWOGrET2JJLJfj6rC1ignIJvpxKKJCAQ
	cap4TuCIPqDszb4o7C5sLke9Gqk9ppmM9MjdgvtpWcKVzgeJpg4sCaAfc/6j+zSc
	mY5B0ZECed8+wQ+P1QNkxt53W7o7wjto3ktEnfWqSt1/LVCXYpd/Z9z6ZA==
Received: (qmail 12057 invoked from network); 28 Nov 2014 12:17:57 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	28 Nov 2014 12:17:57 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 024B5803DF
	for <xen-devel@lists.xen.org>; Fri, 28 Nov 2014 12:17:57 +0200 (EET)
Received: (qmail 10247 invoked from network); 28 Nov 2014 12:17:57 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by smtp03.buh.bitdefender.org with SMTP; 28 Nov 2014 12:17:52 +0200
Message-ID: <54784BD8.20007@bitdefender.com>
Date: Fri, 28 Nov 2014 12:18:00 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <54770242.9000709@bitdefender.com>
	<1417168681.19852.2.camel@citrix.com>
In-Reply-To: <1417168681.19852.2.camel@citrix.com>
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.57990
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 373728,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_LEGIT_VALID_REPLY;
	NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS], SGN:
	[Enabled], URL: [Enabled], RTDA: [Enabled, Hit: No, Details: Error:
	onPost(110)(28)], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xenstore.h clarifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/28/2014 11:58 AM, Ian Campbell wrote:
> On Thu, 2014-11-27 at 12:51 +0200, Razvan Cojocaru wrote:
> 
> It's a good idea to CC the relevant maintainers if you want their input.
> 
>> Hello,
>>
>> I know that xc_interface_open() can be safely called several times from
>> the same process, and that several processes can each have a bunch of
>> xc_interface handles open, and that I shouldn't use an xc_interface
>> inherited from the parent in a child process, because xenctrl.h says so.
>>
>> Is it safe to assume that the same restrictions / conventions apply to
>> xs_handles obtained via xs_open()? Xenstore.h is not explicit. Looking
>> at the code, it would seem safe to assume that it can be used in a
>> similar manner, but it would be nice to have this confirmed if possible.
> 
> I think there's a pretty good chance that the same applies to xenstore
> connections made over the device/shared-ring interface.
> 
> I'm not really sure about the semantics of a Unix domain socket after a
> fork, but I don't expect both parent and child could sanely make use of
> it.
> 
> So I think the answer is:
> 
>       * Connections made with xs_open(0) (which might be shared page or
>         socket based) are only guaranteed to work in the parent after
>         fork.
>       * Connections made with xs_open(XS_OPEN_SOCKETONLY) will be usable
>         in either the parent or the child after fork, but not both.
>       * xs_daemon_open*() and xs_domain_open() are deprecated synonyms
>         for xs_open(0)
>       * XS_OPEN_READONLY has not bearing on any of this.
> 
> Ian, does that seem right?
> 
> Razvan, assuming Ian concurs with the above (or corrects it) then could
> you knock up a patch to document the result please.

Sure, I'll document whatever gets confirmed.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:23:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIhh-0004tm-Ql; Fri, 28 Nov 2014 10:23:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuIhf-0004te-Vj
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:23:08 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	01/AA-23865-B0D48745; Fri, 28 Nov 2014 10:23:07 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417170185!10044313!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32375 invoked from network); 28 Nov 2014 10:23:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 10:23:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208";a="197683339"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 05:22:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuIhR-0000BA-Nn;
	Fri, 28 Nov 2014 10:22:53 +0000
Date: Fri, 28 Nov 2014 10:22:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1417154122-23669-1-git-send-email-cyliu@suse.com>
Message-ID: <alpine.DEB.2.02.1411281022060.14135@kaball.uk.xensource.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] missing chunk of HVM direct kernel boot
	patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 28 Nov 2014, Chunyan Liu wrote:
> Found by Stefano, this chunk of the patch was never applied to
> xen-unstable (commit 11dffa2359e8a2629490c14c029c7c7c777b3e47),
> see http://marc.info/?l=qemu-devel&m=140471493425353&w=2.
> 
> Signed-off-by: Chunyan Liu <cyliu@suse.com>

I think it should be in 4.5: at the moment the feature is broken and
only half-applied to the tree.

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  tools/libxl/libxl_dm.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 3e191c3..b25b574 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -527,6 +527,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          int ioemu_nics = 0;
>  
> +        if (b_info->kernel)
> +            flexarray_vappend(dm_args, "-kernel", b_info->kernel, NULL);
> +
> +        if (b_info->ramdisk)
> +            flexarray_vappend(dm_args, "-initrd", b_info->ramdisk, NULL);
> +
> +        if (b_info->cmdline)
> +            flexarray_vappend(dm_args, "-append", b_info->cmdline, NULL);
> +
>          if (b_info->u.hvm.serial || b_info->u.hvm.serial_list) {
>              if ( b_info->u.hvm.serial && b_info->u.hvm.serial_list )
>              {
> -- 
> 1.8.4.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:23:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIhh-0004tm-Ql; Fri, 28 Nov 2014 10:23:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuIhf-0004te-Vj
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:23:08 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	01/AA-23865-B0D48745; Fri, 28 Nov 2014 10:23:07 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417170185!10044313!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32375 invoked from network); 28 Nov 2014 10:23:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 10:23:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208";a="197683339"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 05:22:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuIhR-0000BA-Nn;
	Fri, 28 Nov 2014 10:22:53 +0000
Date: Fri, 28 Nov 2014 10:22:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Chunyan Liu <cyliu@suse.com>
In-Reply-To: <1417154122-23669-1-git-send-email-cyliu@suse.com>
Message-ID: <alpine.DEB.2.02.1411281022060.14135@kaball.uk.xensource.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] missing chunk of HVM direct kernel boot
	patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 28 Nov 2014, Chunyan Liu wrote:
> Found by Stefano, this chunk of the patch was never applied to
> xen-unstable (commit 11dffa2359e8a2629490c14c029c7c7c777b3e47),
> see http://marc.info/?l=qemu-devel&m=140471493425353&w=2.
> 
> Signed-off-by: Chunyan Liu <cyliu@suse.com>

I think it should be in 4.5: at the moment the feature is broken and
only half-applied to the tree.

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  tools/libxl/libxl_dm.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 3e191c3..b25b574 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -527,6 +527,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          int ioemu_nics = 0;
>  
> +        if (b_info->kernel)
> +            flexarray_vappend(dm_args, "-kernel", b_info->kernel, NULL);
> +
> +        if (b_info->ramdisk)
> +            flexarray_vappend(dm_args, "-initrd", b_info->ramdisk, NULL);
> +
> +        if (b_info->cmdline)
> +            flexarray_vappend(dm_args, "-append", b_info->cmdline, NULL);
> +
>          if (b_info->u.hvm.serial || b_info->u.hvm.serial_list) {
>              if ( b_info->u.hvm.serial && b_info->u.hvm.serial_list )
>              {
> -- 
> 1.8.4.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:27:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:27:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIlg-00055B-I3; Fri, 28 Nov 2014 10:27:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XuIlf-000556-Gr
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:27:15 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	AC/A8-27785-20E48745; Fri, 28 Nov 2014 10:27:14 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417170434!11675829!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8980 invoked from network); 28 Nov 2014 10:27:14 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 10:27:14 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so8405809wgh.6
	for <xen-devel@lists.xen.org>; Fri, 28 Nov 2014 02:27:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=eLLVyHln7Q4X8Mf1OwvOne0G8x3a74CNJTDH32Frs9o=;
	b=RJ9Pqim5qLBgmwClIFvB+LuDWUGP6Fg5y0y8gc1IcXW1Vs7bl6yS42oqQQmwGjtO56
	HhpxgsQ5JvfA8OYII6iivwPEFuyUNIgZ2c+cEMBdFTkYAqhvZMjO6CzGbraqVOOBQTOi
	uHw//r+CWEhtE++86WJ74E2Ff26W5g3RkSQWcJ+xIHGtyM5PmFKzEiO51kdEQhhlI57L
	1F82XaxSH26EnzpEIfLVL4vWTFgpfVLUMfW4//Q8ToVyjZnumuiRtg9546OfqKdceMyJ
	pIMz42hge/uwQ7cBMDITQQcbleVRTmwPNS0ozbypSYzZnmE/gk4lsZ++fl6TyCl33+12
	ALRA==
X-Gm-Message-State: ALoCoQmtztpsQrpUjhVWGOAD5LRsv7561ZyacffU6c0/Yd52+faiYN6NUBOG8G/oUqscZ2rwDpQ6
X-Received: by 10.195.11.38 with SMTP id ef6mr40236469wjd.68.1417170433877;
	Fri, 28 Nov 2014 02:27:13 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	dg7sm15298842wib.24.2014.11.28.02.27.12 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 28 Nov 2014 02:27:13 -0800 (PST)
Message-ID: <54784E02.2090605@linaro.org>
Date: Fri, 28 Nov 2014 10:27:14 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: zhangleiqiang <zhangleiqiang@gmail.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <B2F7CCAC-D433-4EB9-8E3A-53948151C58B@gmail.com>
In-Reply-To: <B2F7CCAC-D433-4EB9-8E3A-53948151C58B@gmail.com>
Content-Length: 3202
Subject: Re: [Xen-devel] Question about network performance difference
 between dom0 and 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-Transfer-Encoding: base64
Content-Type: text/plain; charset="gbk"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGksCgpJIHdvdWxkIGNoZWNrIHdoZXRoZXIgR1JPIGlzIGVuYWJsZWQgdW5kZXIgRG9tMCBvciBu
b3QgKGV0aHRvb2wgLWsgCmV0aFgpLiBDb21wYXJpbmcgdG9wIGR1cmluZyB0ZXN0IChlc3BlY2lh
bGx5IHRoYXQgd2hpY2ggY29udGV4dCB1c2UgaG93IAptYW55IHBlcmNlbnRhZ2UpLCBhbmQgdGhl
IG51bWJlciBvZiBpbnRlcnJ1cHRzIHBlciBzZWNvbmQgKGdyZXAgZXRoIAovcHJvYy9pbnRlcnJ1
cHRzKSB3b3VsZCBiZSBpbnRlcmVzdGluZyB0b28uCgpSZWdhcmRzLAoKWm9sdGFuCgpPbiAyOC8x
MS8xNCAwMjoyOSwgemhhbmdsZWlxaWFuZyB3cm90ZToKPgo+ICAgSSBoYXZlIGRvbmUgc29tZSBu
ZXR3b3JrIHBlcmZvcm1hbmNlIHRlc3RpbmcgdW5kZXIgWEVOLCBhbmQgZm91bmQgdGhlIHJlc3Vs
dCB3aGljaCBpcyBzb21laG93IHN0cmFuZ2U6Cj4KPiAgICAgV2hlbiB0ZXN0aW5nIGJldHdlZW4g
SG9zdHMgKFNlbmRlciBhbmQgcmVjZWl2ZXIgc2VydmVycyBhcmUgYm90aCBib290aW5nIGZyb20g
a2VybmVsLWRlZmF1bHQpLCBydW5uaW5nIG9ubHkgb25lIG5ldHBlcmYgcHJvY2VzcyB3aWxsIGJl
IGVub3VnaCB0byByZWFjaCB0aGUgdXBwZXIgbGltaXQgb2YgTklDLiBIb3dldmVyLCB3aGVuIHRl
c3RpbmcgYmV0d2VlbiBEb20wcyAoU2VuZGVyIGFuZCByZWNlaXZlciBzZXJ2ZXJzIGFyZSBib3Ro
IGJvb3RpbmcgZnJvbSBrZXJuZWwteGVuKSwgd2UgbXVzdCBydW4gbW9yZSBjb3VudCBvZiBuZXRw
ZXJmIHByb2Nlc3MgdG8gcmVhY2ggdGhlIHVwcGVyIGxpbWl0IG9mIE5JQywgcnVubmluZyBvbmx5
IG9uZSBuZXRwZXJmIHByb2Nlc3MgdGhlIHRocm91Z2hvdXQgd2FzIGxvdy4gVGhlIHJlc3VsdHMg
dXNpbmcgb25lIG5ldHBlcmYgcHJvY2VzcyBhcmUgYXMgZm9sbG93czoKPgo+ICAgICAgICAgICBU
Q1AgNTEyICAgIFRDUCAxNDYwICAgICBUQ1AgNDA5NiAgICBUQ1AgODUwMAo+IEhvc3RzOiAgICA5
MTM0LjI0ICAgIDk0NDQuODQgIDk0NDguMDUgICAgICA5NDQ3LjU4ICAgIChNYnMpCj4gRG9tMHM6
ICAgIDIwNjMuOSAgICAzMDE4Ljk1ICAgICA2NTYxLjI5ICAgICAgICAgNTAwOC4xNyAgICAoTWJz
KQo+Cj4gICAgVGhlIHF1ZXN0aW9uIGlzIHdoeSBvbmUgbmV0cGVyZiBwcm9jZXNzIGNhbm5vdCBy
ZWFjaCB0aGUgbWF4IHRocm91Z2hvdXQgb2YgTklDIHVuZGVyIERvbTAgPyBJIGtub3cgdGhhdCBE
b20wIHdpbGwgaGF2ZSBleHRyYSBvdmVyaGVhZCB3aGVuIGhhbmRsaW5nIGludGVycnVwdCB3aGlj
aCBtdXN0IGJlIGhhbmRsZWQgYnkgaHlwZXJ2aXNvciBmaXJzdCwgYnV0IEkgdGhpbmsgaXQgaXMg
bm90IHRoZSByZWFzb24gZm9yIGl0Lgo+Cj4gICAgVGhlIHRlc3RpbmcgZW52aXJvbm1lbnQgZGV0
YWlscyBhcmUgYXMgZm9sbG93czoKPgo+ICAgICAxLiBIYXJkd2FyZQo+ICAgICAgICAgYS4gQ1BV
OiBJbnRlbChSKSBYZW9uKFIpIENQVSBFNTY0NSBAIDIuNDBHSHosIDIgQ1BVIDYgQ29yZXMgd2l0
aCBIeXBlciBUaHJlYWQgZW5hYmxlZAo+ICAgICAgICAgYi4gTklDOiBJbnRlbCBDb3Jwb3JhdGlv
biA4MjU5OUVCIDEwLUdpZ2FiaXQgU0ZJL1NGUCsgTmV0d29yayBDb25uZWN0aW9uIChyZXYgMDEp
Cj4gICAgIDIuIFNvZndhcmU6Cj4gICAgICAgICBhLiBIb3N0T1M6IFNVU0UgU0xFUyAxMSBTUDMg
KEtlcm5lbCAzLjAuNzYpCj4gICAgICAgICBiLiBOSUMgRHJpdmVyOiBJWEdCRSAzLjIxLjIKPiAg
ICAgICAgIGMuIE9WUzogMi4xLjMKPiAgICAgICAgIGQuIE1UVTogMTYwMAo+ICAgICAgICAgZS4g
RG9tMKO6NlU2Rwo+ICAgICAzLiBOZXR3b3JraW5nIEVudmlyb25tZW50Ogo+ICAgICAgICAgYS4g
QWxsIG5ldHdvcmsgZmxvd3MgYXJlIHRyYW5zbWl0L3JlY2VpdmUgdGhyb3VnaCBPVlMKPiAgICAg
ICAgIGIuIFNlbmRlciBzZXJ2ZXIgYW5kIHJlY2VpdmVyIHNlcnZlciBhcmUgY29ubmVjdGVkIGRp
cmVjdGx5IGJldHdlZW4gMTBHRSBOSUMKPiAgICAgNC4gVGVzdGluZyBUb29sczoKPiAgICAgICAg
IGEuIFNlbmRlcjogbmV0cGVyZgo+ICAgICAgICAgYi4gUmVjZWl2ZXI6IG5ldHNlcnZlcgo+Cj4K
PiAtLS0tLS0tLS0tCj4gemhhbmdsZWlxaWFuZyAoVHJ1bXApCj4KPiBCZXN0IFJlZ2FyZHMKPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:27:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:27:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIlg-00055B-I3; Fri, 28 Nov 2014 10:27:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XuIlf-000556-Gr
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:27:15 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	AC/A8-27785-20E48745; Fri, 28 Nov 2014 10:27:14 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417170434!11675829!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8980 invoked from network); 28 Nov 2014 10:27:14 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 10:27:14 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so8405809wgh.6
	for <xen-devel@lists.xen.org>; Fri, 28 Nov 2014 02:27:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=eLLVyHln7Q4X8Mf1OwvOne0G8x3a74CNJTDH32Frs9o=;
	b=RJ9Pqim5qLBgmwClIFvB+LuDWUGP6Fg5y0y8gc1IcXW1Vs7bl6yS42oqQQmwGjtO56
	HhpxgsQ5JvfA8OYII6iivwPEFuyUNIgZ2c+cEMBdFTkYAqhvZMjO6CzGbraqVOOBQTOi
	uHw//r+CWEhtE++86WJ74E2Ff26W5g3RkSQWcJ+xIHGtyM5PmFKzEiO51kdEQhhlI57L
	1F82XaxSH26EnzpEIfLVL4vWTFgpfVLUMfW4//Q8ToVyjZnumuiRtg9546OfqKdceMyJ
	pIMz42hge/uwQ7cBMDITQQcbleVRTmwPNS0ozbypSYzZnmE/gk4lsZ++fl6TyCl33+12
	ALRA==
X-Gm-Message-State: ALoCoQmtztpsQrpUjhVWGOAD5LRsv7561ZyacffU6c0/Yd52+faiYN6NUBOG8G/oUqscZ2rwDpQ6
X-Received: by 10.195.11.38 with SMTP id ef6mr40236469wjd.68.1417170433877;
	Fri, 28 Nov 2014 02:27:13 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	dg7sm15298842wib.24.2014.11.28.02.27.12 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 28 Nov 2014 02:27:13 -0800 (PST)
Message-ID: <54784E02.2090605@linaro.org>
Date: Fri, 28 Nov 2014 10:27:14 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: zhangleiqiang <zhangleiqiang@gmail.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <B2F7CCAC-D433-4EB9-8E3A-53948151C58B@gmail.com>
In-Reply-To: <B2F7CCAC-D433-4EB9-8E3A-53948151C58B@gmail.com>
Content-Length: 3202
Subject: Re: [Xen-devel] Question about network performance difference
 between dom0 and 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-Transfer-Encoding: base64
Content-Type: text/plain; charset="gbk"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGksCgpJIHdvdWxkIGNoZWNrIHdoZXRoZXIgR1JPIGlzIGVuYWJsZWQgdW5kZXIgRG9tMCBvciBu
b3QgKGV0aHRvb2wgLWsgCmV0aFgpLiBDb21wYXJpbmcgdG9wIGR1cmluZyB0ZXN0IChlc3BlY2lh
bGx5IHRoYXQgd2hpY2ggY29udGV4dCB1c2UgaG93IAptYW55IHBlcmNlbnRhZ2UpLCBhbmQgdGhl
IG51bWJlciBvZiBpbnRlcnJ1cHRzIHBlciBzZWNvbmQgKGdyZXAgZXRoIAovcHJvYy9pbnRlcnJ1
cHRzKSB3b3VsZCBiZSBpbnRlcmVzdGluZyB0b28uCgpSZWdhcmRzLAoKWm9sdGFuCgpPbiAyOC8x
MS8xNCAwMjoyOSwgemhhbmdsZWlxaWFuZyB3cm90ZToKPgo+ICAgSSBoYXZlIGRvbmUgc29tZSBu
ZXR3b3JrIHBlcmZvcm1hbmNlIHRlc3RpbmcgdW5kZXIgWEVOLCBhbmQgZm91bmQgdGhlIHJlc3Vs
dCB3aGljaCBpcyBzb21laG93IHN0cmFuZ2U6Cj4KPiAgICAgV2hlbiB0ZXN0aW5nIGJldHdlZW4g
SG9zdHMgKFNlbmRlciBhbmQgcmVjZWl2ZXIgc2VydmVycyBhcmUgYm90aCBib290aW5nIGZyb20g
a2VybmVsLWRlZmF1bHQpLCBydW5uaW5nIG9ubHkgb25lIG5ldHBlcmYgcHJvY2VzcyB3aWxsIGJl
IGVub3VnaCB0byByZWFjaCB0aGUgdXBwZXIgbGltaXQgb2YgTklDLiBIb3dldmVyLCB3aGVuIHRl
c3RpbmcgYmV0d2VlbiBEb20wcyAoU2VuZGVyIGFuZCByZWNlaXZlciBzZXJ2ZXJzIGFyZSBib3Ro
IGJvb3RpbmcgZnJvbSBrZXJuZWwteGVuKSwgd2UgbXVzdCBydW4gbW9yZSBjb3VudCBvZiBuZXRw
ZXJmIHByb2Nlc3MgdG8gcmVhY2ggdGhlIHVwcGVyIGxpbWl0IG9mIE5JQywgcnVubmluZyBvbmx5
IG9uZSBuZXRwZXJmIHByb2Nlc3MgdGhlIHRocm91Z2hvdXQgd2FzIGxvdy4gVGhlIHJlc3VsdHMg
dXNpbmcgb25lIG5ldHBlcmYgcHJvY2VzcyBhcmUgYXMgZm9sbG93czoKPgo+ICAgICAgICAgICBU
Q1AgNTEyICAgIFRDUCAxNDYwICAgICBUQ1AgNDA5NiAgICBUQ1AgODUwMAo+IEhvc3RzOiAgICA5
MTM0LjI0ICAgIDk0NDQuODQgIDk0NDguMDUgICAgICA5NDQ3LjU4ICAgIChNYnMpCj4gRG9tMHM6
ICAgIDIwNjMuOSAgICAzMDE4Ljk1ICAgICA2NTYxLjI5ICAgICAgICAgNTAwOC4xNyAgICAoTWJz
KQo+Cj4gICAgVGhlIHF1ZXN0aW9uIGlzIHdoeSBvbmUgbmV0cGVyZiBwcm9jZXNzIGNhbm5vdCBy
ZWFjaCB0aGUgbWF4IHRocm91Z2hvdXQgb2YgTklDIHVuZGVyIERvbTAgPyBJIGtub3cgdGhhdCBE
b20wIHdpbGwgaGF2ZSBleHRyYSBvdmVyaGVhZCB3aGVuIGhhbmRsaW5nIGludGVycnVwdCB3aGlj
aCBtdXN0IGJlIGhhbmRsZWQgYnkgaHlwZXJ2aXNvciBmaXJzdCwgYnV0IEkgdGhpbmsgaXQgaXMg
bm90IHRoZSByZWFzb24gZm9yIGl0Lgo+Cj4gICAgVGhlIHRlc3RpbmcgZW52aXJvbm1lbnQgZGV0
YWlscyBhcmUgYXMgZm9sbG93czoKPgo+ICAgICAxLiBIYXJkd2FyZQo+ICAgICAgICAgYS4gQ1BV
OiBJbnRlbChSKSBYZW9uKFIpIENQVSBFNTY0NSBAIDIuNDBHSHosIDIgQ1BVIDYgQ29yZXMgd2l0
aCBIeXBlciBUaHJlYWQgZW5hYmxlZAo+ICAgICAgICAgYi4gTklDOiBJbnRlbCBDb3Jwb3JhdGlv
biA4MjU5OUVCIDEwLUdpZ2FiaXQgU0ZJL1NGUCsgTmV0d29yayBDb25uZWN0aW9uIChyZXYgMDEp
Cj4gICAgIDIuIFNvZndhcmU6Cj4gICAgICAgICBhLiBIb3N0T1M6IFNVU0UgU0xFUyAxMSBTUDMg
KEtlcm5lbCAzLjAuNzYpCj4gICAgICAgICBiLiBOSUMgRHJpdmVyOiBJWEdCRSAzLjIxLjIKPiAg
ICAgICAgIGMuIE9WUzogMi4xLjMKPiAgICAgICAgIGQuIE1UVTogMTYwMAo+ICAgICAgICAgZS4g
RG9tMKO6NlU2Rwo+ICAgICAzLiBOZXR3b3JraW5nIEVudmlyb25tZW50Ogo+ICAgICAgICAgYS4g
QWxsIG5ldHdvcmsgZmxvd3MgYXJlIHRyYW5zbWl0L3JlY2VpdmUgdGhyb3VnaCBPVlMKPiAgICAg
ICAgIGIuIFNlbmRlciBzZXJ2ZXIgYW5kIHJlY2VpdmVyIHNlcnZlciBhcmUgY29ubmVjdGVkIGRp
cmVjdGx5IGJldHdlZW4gMTBHRSBOSUMKPiAgICAgNC4gVGVzdGluZyBUb29sczoKPiAgICAgICAg
IGEuIFNlbmRlcjogbmV0cGVyZgo+ICAgICAgICAgYi4gUmVjZWl2ZXI6IG5ldHNlcnZlcgo+Cj4K
PiAtLS0tLS0tLS0tCj4gemhhbmdsZWlxaWFuZyAoVHJ1bXApCj4KPiBCZXN0IFJlZ2FyZHMKPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:29:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 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 1XuInq-0005Ca-4D; Fri, 28 Nov 2014 10:29:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1XuIno-0005CS-Kj
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:29:28 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	AA/17-08051-88E48745; Fri, 28 Nov 2014 10:29:28 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417170566!11688851!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18799 invoked from network); 28 Nov 2014 10:29:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-27.messagelabs.com with SMTP;
	28 Nov 2014 10:29:27 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 28 Nov 2014 02:29:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="639491211"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by fmsmga002.fm.intel.com with ESMTP; 28 Nov 2014 02:29:23 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 28 Nov 2014 18:29:16 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.110]) with mapi id
	14.03.0195.001; Fri, 28 Nov 2014 18:29:15 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [v3] libxc: Expose the 1GB pages cpuid flag to guest
Thread-Index: AQHQCrxbw7TLTqonVkWDWwhRSDImbpx1PFoAgACUmGA=
Date: Fri, 28 Nov 2014 10:29:14 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
References: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
	<54784B72020000780004B565@mail.emea.novell.com>
In-Reply-To: <54784B72020000780004B565@mail.emea.novell.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "tim@xen.org" <tim@xen.org>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> -        if (!hvm_pse1gb_supported(d))
>> +        if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
>>              *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);
>
>With
>
>#define hvm_pse1gb_supported(d) \
>    (cpu_has_page1gb && paging_mode_hap(d))

>the change above is pointless. While, considering this, comments on
>v2 may have been misleading, you should have simply updated the patch description instead to clarify why the v2 change was okay even for the shadow mode case.

I checked the code and found that for a normal guest can only be in hap mode or shadow mode before I sending the patch, but I am not share if it's true for dom0. 

Liang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:29:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 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 1XuInq-0005Ca-4D; Fri, 28 Nov 2014 10:29:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1XuIno-0005CS-Kj
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:29:28 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	AA/17-08051-88E48745; Fri, 28 Nov 2014 10:29:28 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417170566!11688851!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18799 invoked from network); 28 Nov 2014 10:29:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-27.messagelabs.com with SMTP;
	28 Nov 2014 10:29:27 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 28 Nov 2014 02:29:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="639491211"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by fmsmga002.fm.intel.com with ESMTP; 28 Nov 2014 02:29:23 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 28 Nov 2014 18:29:16 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.110]) with mapi id
	14.03.0195.001; Fri, 28 Nov 2014 18:29:15 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [v3] libxc: Expose the 1GB pages cpuid flag to guest
Thread-Index: AQHQCrxbw7TLTqonVkWDWwhRSDImbpx1PFoAgACUmGA=
Date: Fri, 28 Nov 2014 10:29:14 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
References: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
	<54784B72020000780004B565@mail.emea.novell.com>
In-Reply-To: <54784B72020000780004B565@mail.emea.novell.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "tim@xen.org" <tim@xen.org>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> -        if (!hvm_pse1gb_supported(d))
>> +        if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
>>              *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);
>
>With
>
>#define hvm_pse1gb_supported(d) \
>    (cpu_has_page1gb && paging_mode_hap(d))

>the change above is pointless. While, considering this, comments on
>v2 may have been misleading, you should have simply updated the patch description instead to clarify why the v2 change was okay even for the shadow mode case.

I checked the code and found that for a normal guest can only be in hap mode or shadow mode before I sending the patch, but I am not share if it's true for dom0. 

Liang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:32:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIqh-0005QE-Og; Fri, 28 Nov 2014 10:32:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XuIqf-0005Pq-Tp
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:32:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0D/5A-09842-93F48745; Fri, 28 Nov 2014 10:32:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417170743!12084279!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31012 invoked from network); 28 Nov 2014 10:32:24 -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;
	28 Nov 2014 10:32:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208";a="197409418"
Message-ID: <54784F34.2000900@citrix.com>
Date: Fri, 28 Nov 2014 10:32:20 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: "Li, Liang Z" <liang.z.li@intel.com>, Jan Beulich <JBeulich@suse.com>
References: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
	<54784B72020000780004B565@mail.emea.novell.com>
	<F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
X-DLP: MIA1
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to 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 28/11/14 10:29, Li, Liang Z wrote:
>>> -        if (!hvm_pse1gb_supported(d))
>>> +        if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
>>>              *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);
>> With
>>
>> #define hvm_pse1gb_supported(d) \
>>    (cpu_has_page1gb && paging_mode_hap(d))
>> the change above is pointless. While, considering this, comments on
>> v2 may have been misleading, you should have simply updated the patch description instead to clarify why the v2 change was okay even for the shadow mode case.
> I checked the code and found that for a normal guest can only be in hap mode or shadow mode before I sending the patch, but I am not share if it's true for dom0. 
>
> Liang

Dom0 may either be PV (in which case neither hap nor shadow, and cant
use 1GB pages anyway), or experimentally PVH which is currently
restricted to hap.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:32:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIqh-0005QE-Og; Fri, 28 Nov 2014 10:32:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XuIqf-0005Pq-Tp
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:32:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0D/5A-09842-93F48745; Fri, 28 Nov 2014 10:32:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417170743!12084279!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31012 invoked from network); 28 Nov 2014 10:32:24 -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;
	28 Nov 2014 10:32:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208";a="197409418"
Message-ID: <54784F34.2000900@citrix.com>
Date: Fri, 28 Nov 2014 10:32:20 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: "Li, Liang Z" <liang.z.li@intel.com>, Jan Beulich <JBeulich@suse.com>
References: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
	<54784B72020000780004B565@mail.emea.novell.com>
	<F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
X-DLP: MIA1
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to 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 28/11/14 10:29, Li, Liang Z wrote:
>>> -        if (!hvm_pse1gb_supported(d))
>>> +        if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
>>>              *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);
>> With
>>
>> #define hvm_pse1gb_supported(d) \
>>    (cpu_has_page1gb && paging_mode_hap(d))
>> the change above is pointless. While, considering this, comments on
>> v2 may have been misleading, you should have simply updated the patch description instead to clarify why the v2 change was okay even for the shadow mode case.
> I checked the code and found that for a normal guest can only be in hap mode or shadow mode before I sending the patch, but I am not share if it's true for dom0. 
>
> Liang

Dom0 may either be PV (in which case neither hap nor shadow, and cant
use 1GB pages anyway), or experimentally PVH which is currently
restricted to hap.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:38:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIwe-0005mF-IN; Fri, 28 Nov 2014 10:38:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1XuIwd-0005mA-2A
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:38:35 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	DA/69-22777-AA058745; Fri, 28 Nov 2014 10:38:34 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417171113!10952517!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7172 invoked from network); 28 Nov 2014 10:38:33 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-16.tower-206.messagelabs.com with SMTP;
	28 Nov 2014 10:38:33 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 28 Nov 2014 02:35:23 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="644957326"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by orsmga002.jf.intel.com with ESMTP; 28 Nov 2014 02:38:29 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 28 Nov 2014 18:38:20 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Fri, 28 Nov 2014 18:38:18 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [v3] libxc: Expose the 1GB pages cpuid flag to guest
Thread-Index: AQHQCrxbw7TLTqonVkWDWwhRSDImbpx1PFoAgACUmGD//4CmAIAAhoXg
Date: Fri, 28 Nov 2014 10:38:18 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E44FCDF@shsmsx102.ccr.corp.intel.com>
References: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
	<54784B72020000780004B565@mail.emea.novell.com>
	<F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
	<54784F34.2000900@citrix.com>
In-Reply-To: <54784F34.2000900@citrix.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: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to 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

>>>    (cpu_has_page1gb && paging_mode_hap(d)) the change above is 
>>> pointless. While, considering this, comments on
>>> v2 may have been misleading, you should have simply updated the patch description instead to clarify why the v2 change was okay even for the shadow mode case.
>> I checked the code and found that for a normal guest can only be in hap mode or shadow mode before I sending the patch, but I am not share if it's true for dom0. 
>>
>> Liang
>
> Dom0 may either be PV (in which case neither hap nor shadow, and cant use 1GB pages anyway), or experimentally PVH which is currently restricted to hap.
>
>~Andrew

Thanks for clarification.  I will resend the v2 patch.

Liang




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:38:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIwe-0005mF-IN; Fri, 28 Nov 2014 10:38:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.z.li@intel.com>) id 1XuIwd-0005mA-2A
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:38:35 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	DA/69-22777-AA058745; Fri, 28 Nov 2014 10:38:34 +0000
X-Env-Sender: liang.z.li@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417171113!10952517!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7172 invoked from network); 28 Nov 2014 10:38:33 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-16.tower-206.messagelabs.com with SMTP;
	28 Nov 2014 10:38:33 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 28 Nov 2014 02:35:23 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,475,1413270000"; d="scan'208";a="644957326"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by orsmga002.jf.intel.com with ESMTP; 28 Nov 2014 02:38:29 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 28 Nov 2014 18:38:20 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by
	SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id
	14.03.0195.001; Fri, 28 Nov 2014 18:38:18 +0800
From: "Li, Liang Z" <liang.z.li@intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [v3] libxc: Expose the 1GB pages cpuid flag to guest
Thread-Index: AQHQCrxbw7TLTqonVkWDWwhRSDImbpx1PFoAgACUmGD//4CmAIAAhoXg
Date: Fri, 28 Nov 2014 10:38:18 +0000
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E44FCDF@shsmsx102.ccr.corp.intel.com>
References: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
	<54784B72020000780004B565@mail.emea.novell.com>
	<F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
	<54784F34.2000900@citrix.com>
In-Reply-To: <54784F34.2000900@citrix.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: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to 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

>>>    (cpu_has_page1gb && paging_mode_hap(d)) the change above is 
>>> pointless. While, considering this, comments on
>>> v2 may have been misleading, you should have simply updated the patch description instead to clarify why the v2 change was okay even for the shadow mode case.
>> I checked the code and found that for a normal guest can only be in hap mode or shadow mode before I sending the patch, but I am not share if it's true for dom0. 
>>
>> Liang
>
> Dom0 may either be PV (in which case neither hap nor shadow, and cant use 1GB pages anyway), or experimentally PVH which is currently restricted to hap.
>
>~Andrew

Thanks for clarification.  I will resend the v2 patch.

Liang




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:39:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:39:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIxR-0005rA-6N; Fri, 28 Nov 2014 10:39:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuIxP-0005qx-Hh
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:39:23 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	D2/B5-26740-AD058745; Fri, 28 Nov 2014 10:39:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417171162!10048779!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4957 invoked from network); 28 Nov 2014 10:39:22 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:39:22 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 10:39:21 +0000
Message-Id: <54785EEA020000780004B5C7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 10:39:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liang Z Li" <liang.z.li@intel.com>
References: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
	<54784B72020000780004B565@mail.emea.novell.com>
	<F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "tim@xen.org" <tim@xen.org>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to 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 28.11.14 at 11:29, <liang.z.li@intel.com> wrote:
>> > -        if (!hvm_pse1gb_supported(d))
>>> +        if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
>>>              *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);
>>
>>With
>>
>>#define hvm_pse1gb_supported(d) \
>>    (cpu_has_page1gb && paging_mode_hap(d))
> 
>>the change above is pointless. While, considering this, comments on
>>v2 may have been misleading, you should have simply updated the patch 
> description instead to clarify why the v2 change was okay even for the shadow 
> mode case.
> 
> I checked the code and found that for a normal guest can only be in hap mode 
> or shadow mode before I sending the patch, but I am not share if it's true 
> for dom0. 

The CPUID code in libxc doesn't apply to Dom0 at all, and CPUID
handling is also special cased in the hypervisor for Dom0. Plus
finally Dom0 only possibly being PV or PVH, PVH requiring HAP
and PV generally not allowing large pages anyway, your concern
is unnecessary.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:39:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:39:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuIxR-0005rA-6N; Fri, 28 Nov 2014 10:39:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuIxP-0005qx-Hh
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:39:23 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	D2/B5-26740-AD058745; Fri, 28 Nov 2014 10:39:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417171162!10048779!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4957 invoked from network); 28 Nov 2014 10:39:22 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:39:22 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 10:39:21 +0000
Message-Id: <54785EEA020000780004B5C7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 10:39:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liang Z Li" <liang.z.li@intel.com>
References: <1417145320-9158-1-git-send-email-liang.z.li@intel.com>
	<54784B72020000780004B565@mail.emea.novell.com>
	<F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E44FCBD@shsmsx102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "tim@xen.org" <tim@xen.org>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [v3] libxc: Expose the 1GB pages cpuid flag to 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 28.11.14 at 11:29, <liang.z.li@intel.com> wrote:
>> > -        if (!hvm_pse1gb_supported(d))
>>> +        if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
>>>              *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);
>>
>>With
>>
>>#define hvm_pse1gb_supported(d) \
>>    (cpu_has_page1gb && paging_mode_hap(d))
> 
>>the change above is pointless. While, considering this, comments on
>>v2 may have been misleading, you should have simply updated the patch 
> description instead to clarify why the v2 change was okay even for the shadow 
> mode case.
> 
> I checked the code and found that for a normal guest can only be in hap mode 
> or shadow mode before I sending the patch, but I am not share if it's true 
> for dom0. 

The CPUID code in libxc doesn't apply to Dom0 at all, and CPUID
handling is also special cased in the hypervisor for Dom0. Plus
finally Dom0 only possibly being PV or PVH, PVH requiring HAP
and PV generally not allowing large pages anyway, your concern
is unnecessary.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBj-0006W7-JN; Fri, 28 Nov 2014 10:54:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBh-0006U8-L9
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:09 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	2C/79-26652-05458745; Fri, 28 Nov 2014 10:54:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417172048!13860211!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5924 invoked from network); 28 Nov 2014 10:54:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2014 10:54:08 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 22D8AADCD;
	Fri, 28 Nov 2014 10:54:08 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:59 +0100
Message-Id: <1417172039-8627-11-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 10/10] xen: Speed up set_phys_to_machine() by
	using read-only mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of checking at each call of set_phys_to_machine() whether a
new p2m page has to be allocated due to writing an entry in a large
invalid or identity area, just map those areas read only and react
to a page fault on write by allocating the new page.

This change will make the common path with no allocation much
faster as it only requires a single write of the new mfn instead
of walking the address translation tables and checking for the
special cases.

Suggested-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 7d84473..8b5db51 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -70,6 +70,7 @@
 
 #include <asm/cache.h>
 #include <asm/setup.h>
+#include <asm/uaccess.h>
 
 #include <asm/xen/page.h>
 #include <asm/xen/hypercall.h>
@@ -316,9 +317,9 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
 	for (i = 0; i < PTRS_PER_PTE; i++) {
 		set_pte(p2m_missing_pte + i,
-			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
+			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL_RO));
 		set_pte(p2m_identity_pte + i,
-			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
+			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL_RO));
 	}
 
 	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
@@ -365,7 +366,7 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 				p2m_missing : p2m_identity;
 			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
 			set_pte(ptep,
-				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL_RO));
 			continue;
 		}
 
@@ -624,6 +625,9 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
+	if (likely(!__put_user(mfn, xen_p2m_addr + pfn)))
+		return true;
+
 	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
 	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
@@ -633,9 +637,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
 		return mfn == IDENTITY_FRAME(pfn);
 
-	xen_p2m_addr[pfn] = mfn;
-
-	return true;
+	return false;
 }
 
 bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBh-0006U5-3j; Fri, 28 Nov 2014 10:54:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBf-0006Ra-Cp
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:07 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	44/38-11581-E4458745; Fri, 28 Nov 2014 10:54:06 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417172045!9720089!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14161 invoked from network); 28 Nov 2014 10:54:05 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2014 10:54:05 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 00C0AAD9F;
	Fri, 28 Nov 2014 10:54:05 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:53 +0100
Message-Id: <1417172039-8627-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 04/10] xen: Delay remapping memory of
	pv-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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Early in the boot process the memory layout of a pv-domain is changed
to match the E820 map (either the host one for Dom0 or the Xen one)
regarding placement of RAM and PCI holes. This requires removing memory
pages initially located at positions not suitable for RAM and adding
them later at higher addresses where no restrictions apply.

To be able to operate on the hypervisor supported p2m list until a
virtual mapped linear p2m list can be constructed, remapping must
be delayed until virtual memory management is initialized, as the
initial p2m list can't be extended unlimited at physical memory
initialization time due to it's fixed structure.

A further advantage is the reduction in complexity and code volume as
we don't have to be careful regarding memory restrictions during p2m
updates.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/xen/page.h |   1 -
 arch/x86/xen/mmu.c              |   4 +
 arch/x86/xen/p2m.c              |  94 ----------
 arch/x86/xen/setup.c            | 369 ++++++++++++++++++----------------------
 arch/x86/xen/xen-ops.h          |   1 +
 5 files changed, 172 insertions(+), 297 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 6c16451..b475297 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -44,7 +44,6 @@ extern unsigned long  machine_to_phys_nr;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
-extern bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 					     unsigned long pfn_e);
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b995b871..601914d 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1225,6 +1225,10 @@ static void __init xen_pagetable_init(void)
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
+	/* Remap memory freed due to conflicts with E820 map */
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_remap_memory();
+
 	xen_setup_shared_info();
 	xen_post_allocator_init();
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index fa53dc2..24cd9d1 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -662,100 +662,6 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 	return true;
 }
 
-/*
- * Skim over the P2M tree looking at pages that are either filled with
- * INVALID_P2M_ENTRY or with 1:1 PFNs. If found, re-use that page and
- * replace the P2M leaf with a p2m_missing or p2m_identity.
- * Stick the old page in the new P2M tree location.
- */
-static bool __init early_can_reuse_p2m_middle(unsigned long set_pfn)
-{
-	unsigned topidx;
-	unsigned mididx;
-	unsigned ident_pfns;
-	unsigned inv_pfns;
-	unsigned long *p2m;
-	unsigned idx;
-	unsigned long pfn;
-
-	/* We only look when this entails a P2M middle layer */
-	if (p2m_index(set_pfn))
-		return false;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
-		topidx = p2m_top_index(pfn);
-
-		if (!p2m_top[topidx])
-			continue;
-
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
-
-		mididx = p2m_mid_index(pfn);
-		p2m = p2m_top[topidx][mididx];
-		if (!p2m)
-			continue;
-
-		if ((p2m == p2m_missing) || (p2m == p2m_identity))
-			continue;
-
-		if ((unsigned long)p2m == INVALID_P2M_ENTRY)
-			continue;
-
-		ident_pfns = 0;
-		inv_pfns = 0;
-		for (idx = 0; idx < P2M_PER_PAGE; idx++) {
-			/* IDENTITY_PFNs are 1:1 */
-			if (p2m[idx] == IDENTITY_FRAME(pfn + idx))
-				ident_pfns++;
-			else if (p2m[idx] == INVALID_P2M_ENTRY)
-				inv_pfns++;
-			else
-				break;
-		}
-		if ((ident_pfns == P2M_PER_PAGE) || (inv_pfns == P2M_PER_PAGE))
-			goto found;
-	}
-	return false;
-found:
-	/* Found one, replace old with p2m_identity or p2m_missing */
-	p2m_top[topidx][mididx] = (ident_pfns ? p2m_identity : p2m_missing);
-
-	/* Reset where we want to stick the old page in. */
-	topidx = p2m_top_index(set_pfn);
-	mididx = p2m_mid_index(set_pfn);
-
-	/* This shouldn't happen */
-	if (WARN_ON(p2m_top[topidx] == p2m_mid_missing))
-		early_alloc_p2m_middle(set_pfn);
-
-	if (WARN_ON(p2m_top[topidx][mididx] != p2m_missing))
-		return false;
-
-	p2m_init(p2m);
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn)
-{
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
-		if (!early_alloc_p2m_middle(pfn))
-			return false;
-
-		if (early_can_reuse_p2m_middle(pfn))
-			return __set_phys_to_machine(pfn, mfn);
-
-		if (!early_alloc_p2m(pfn, false /* boundary crossover OK!*/))
-			return false;
-
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
-	}
-
-	return true;
-}
-
 static void __init early_split_p2m(unsigned long pfn)
 {
 	unsigned long mididx, idx;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 29834b3..e0b6912f 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -30,6 +30,7 @@
 #include "xen-ops.h"
 #include "vdso.h"
 #include "p2m.h"
+#include "mmu.h"
 
 /* These are code, but not functions.  Defined in entry.S */
 extern const char xen_hypervisor_callback[];
@@ -47,8 +48,19 @@ struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 /* Number of pages released from the initial allocation. */
 unsigned long xen_released_pages;
 
-/* Buffer used to remap identity mapped pages */
-unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
+/*
+ * Buffer used to remap identity mapped pages. We only need the virtual space.
+ * The physical page behind this address is remapped as needed to different
+ * buffer pages.
+ */
+#define REMAP_SIZE	(P2M_PER_PAGE - 3)
+static struct {
+	unsigned long	next_area_mfn;
+	unsigned long	target_pfn;
+	unsigned long	size;
+	unsigned long	mfns[REMAP_SIZE];
+} xen_remap_buf __initdata __aligned(PAGE_SIZE);
+static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 /* 
  * The maximum amount of extra memory compared to the base size.  The
@@ -98,63 +110,6 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 	}
 }
 
-static unsigned long __init xen_do_chunk(unsigned long start,
-					 unsigned long end, bool release)
-{
-	struct xen_memory_reservation reservation = {
-		.address_bits = 0,
-		.extent_order = 0,
-		.domid        = DOMID_SELF
-	};
-	unsigned long len = 0;
-	unsigned long pfn;
-	int ret;
-
-	for (pfn = start; pfn < end; pfn++) {
-		unsigned long frame;
-		unsigned long mfn = pfn_to_mfn(pfn);
-
-		if (release) {
-			/* Make sure pfn exists to start with */
-			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
-				continue;
-			frame = mfn;
-		} else {
-			if (mfn != INVALID_P2M_ENTRY)
-				continue;
-			frame = pfn;
-		}
-		set_xen_guest_handle(reservation.extent_start, &frame);
-		reservation.nr_extents = 1;
-
-		ret = HYPERVISOR_memory_op(release ? XENMEM_decrease_reservation : XENMEM_populate_physmap,
-					   &reservation);
-		WARN(ret != 1, "Failed to %s pfn %lx err=%d\n",
-		     release ? "release" : "populate", pfn, ret);
-
-		if (ret == 1) {
-			if (!early_set_phys_to_machine(pfn, release ? INVALID_P2M_ENTRY : frame)) {
-				if (release)
-					break;
-				set_xen_guest_handle(reservation.extent_start, &frame);
-				reservation.nr_extents = 1;
-				ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
-							   &reservation);
-				break;
-			}
-			len++;
-		} else
-			break;
-	}
-	if (len)
-		printk(KERN_INFO "%s %lx-%lx pfn range: %lu pages %s\n",
-		       release ? "Freeing" : "Populating",
-		       start, end, len,
-		       release ? "freed" : "added");
-
-	return len;
-}
-
 /*
  * Finds the next RAM pfn available in the E820 map after min_pfn.
  * This function updates min_pfn with the pfn found and returns
@@ -198,26 +153,62 @@ static unsigned long __init xen_find_pfn_range(
 	return done;
 }
 
+static int __init xen_free_mfn(unsigned long mfn)
+{
+	struct xen_memory_reservation reservation = {
+		.address_bits = 0,
+		.extent_order = 0,
+		.domid        = DOMID_SELF
+	};
+
+	set_xen_guest_handle(reservation.extent_start, &mfn);
+	reservation.nr_extents = 1;
+
+	return HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation);
+}
+
 /*
- * This releases a chunk of memory and then does the identity map. It's used as
+ * This releases a chunk of memory and then does the identity map. It's used
  * as a fallback if the remapping fails.
  */
 static void __init xen_set_identity_and_release_chunk(unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long *identity,
 	unsigned long *released)
 {
+	unsigned long len = 0;
+	unsigned long pfn, end;
+	int ret;
+
 	WARN_ON(start_pfn > end_pfn);
 
+	end = min(end_pfn, nr_pages);
+	for (pfn = start_pfn; pfn < end; pfn++) {
+		unsigned long mfn = pfn_to_mfn(pfn);
+
+		/* Make sure pfn exists to start with */
+		if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+			continue;
+
+		ret = xen_free_mfn(mfn);
+		WARN(ret != 1, "Failed to release pfn %lx err=%d\n", pfn, ret);
+
+		if (ret == 1) {
+			if (!__set_phys_to_machine(pfn, INVALID_P2M_ENTRY))
+				break;
+			len++;
+		} else
+			break;
+	}
+
 	/* Need to release pages first */
-	*released += xen_do_chunk(start_pfn, min(end_pfn, nr_pages), true);
+	*released += len;
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
 /*
- * Helper function to update both the p2m and m2p tables.
+ * Helper function to update the p2m and m2p tables and kernel mapping.
  */
-static unsigned long __init xen_update_mem_tables(unsigned long pfn,
-						  unsigned long mfn)
+static void __init xen_update_mem_tables(unsigned long pfn, unsigned long mfn)
 {
 	struct mmu_update update = {
 		.ptr = ((unsigned long long)mfn << PAGE_SHIFT) | MMU_MACHPHYS_UPDATE,
@@ -225,161 +216,91 @@ static unsigned long __init xen_update_mem_tables(unsigned long pfn,
 	};
 
 	/* Update p2m */
-	if (!early_set_phys_to_machine(pfn, mfn)) {
+	if (!set_phys_to_machine(pfn, mfn)) {
 		WARN(1, "Failed to set p2m mapping for pfn=%ld mfn=%ld\n",
 		     pfn, mfn);
-		return false;
+		BUG();
 	}
 
 	/* Update m2p */
 	if (HYPERVISOR_mmu_update(&update, 1, NULL, DOMID_SELF) < 0) {
 		WARN(1, "Failed to set m2p mapping for mfn=%ld pfn=%ld\n",
 		     mfn, pfn);
-		return false;
+		BUG();
 	}
 
-	return true;
+	/* Update kernel mapping, but not for highmem. */
+	if ((pfn << PAGE_SHIFT) >= __pa(high_memory))
+		return;
+
+	if (HYPERVISOR_update_va_mapping((unsigned long)__va(pfn << PAGE_SHIFT),
+					 mfn_pte(mfn, PAGE_KERNEL), 0)) {
+		WARN(1, "Failed to update kernel mapping for mfn=%ld pfn=%ld\n",
+		      mfn, pfn);
+		BUG();
+	}
 }
 
 /*
  * This function updates the p2m and m2p tables with an identity map from
- * start_pfn to start_pfn+size and remaps the underlying RAM of the original
- * allocation at remap_pfn. It must do so carefully in P2M_PER_PAGE sized blocks
- * to not exhaust the reserved brk space. Doing it in properly aligned blocks
- * ensures we only allocate the minimum required leaf pages in the p2m table. It
- * copies the existing mfns from the p2m table under the 1:1 map, overwrites
- * them with the identity map and then updates the p2m and m2p tables with the
- * remapped memory.
+ * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the
+ * original allocation at remap_pfn. The information needed for remapping is
+ * saved in the memory itself to avoid the need for allocating buffers. The
+ * complete remap information is contained in a list of MFNs each containing
+ * up to REMAP_SIZE MFNs and the start target PFN for doing the remap.
+ * This enables us to preserve the original mfn sequence while doing the
+ * remapping at a time when the memory management is capable of allocating
+ * virtual and physical memory in arbitrary amounts, see 'xen_remap_memory' and
+ * its callers.
  */
-static unsigned long __init xen_do_set_identity_and_remap_chunk(
+static void __init xen_do_set_identity_and_remap_chunk(
         unsigned long start_pfn, unsigned long size, unsigned long remap_pfn)
 {
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn;
 	unsigned long ident_pfn_iter, remap_pfn_iter;
-	unsigned long ident_start_pfn_align, remap_start_pfn_align;
-	unsigned long ident_end_pfn_align, remap_end_pfn_align;
-	unsigned long ident_boundary_pfn, remap_boundary_pfn;
-	unsigned long ident_cnt = 0;
-	unsigned long remap_cnt = 0;
+	unsigned long ident_end_pfn = start_pfn + size;
 	unsigned long left = size;
-	unsigned long mod;
-	int i;
+	unsigned long ident_cnt = 0;
+	unsigned int i, chunk;
 
 	WARN_ON(size == 0);
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/*
-	 * Determine the proper alignment to remap memory in P2M_PER_PAGE sized
-	 * blocks. We need to keep track of both the existing pfn mapping and
-	 * the new pfn remapping.
-	 */
-	mod = start_pfn % P2M_PER_PAGE;
-	ident_start_pfn_align =
-		mod ? (start_pfn - mod + P2M_PER_PAGE) : start_pfn;
-	mod = remap_pfn % P2M_PER_PAGE;
-	remap_start_pfn_align =
-		mod ? (remap_pfn - mod + P2M_PER_PAGE) : remap_pfn;
-	mod = (start_pfn + size) % P2M_PER_PAGE;
-	ident_end_pfn_align = start_pfn + size - mod;
-	mod = (remap_pfn + size) % P2M_PER_PAGE;
-	remap_end_pfn_align = remap_pfn + size - mod;
-
-	/* Iterate over each p2m leaf node in each range */
-	for (ident_pfn_iter = ident_start_pfn_align, remap_pfn_iter = remap_start_pfn_align;
-	     ident_pfn_iter < ident_end_pfn_align && remap_pfn_iter < remap_end_pfn_align;
-	     ident_pfn_iter += P2M_PER_PAGE, remap_pfn_iter += P2M_PER_PAGE) {
-		/* Check we aren't past the end */
-		BUG_ON(ident_pfn_iter + P2M_PER_PAGE > start_pfn + size);
-		BUG_ON(remap_pfn_iter + P2M_PER_PAGE > remap_pfn + size);
-
-		/* Save p2m mappings */
-		for (i = 0; i < P2M_PER_PAGE; i++)
-			xen_remap_buf[i] = pfn_to_mfn(ident_pfn_iter + i);
-
-		/* Set identity map which will free a p2m leaf */
-		ident_cnt += set_phys_range_identity(ident_pfn_iter,
-			ident_pfn_iter + P2M_PER_PAGE);
-
-#ifdef DEBUG
-		/* Helps verify a p2m leaf has been freed */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned int pfn = ident_pfn_iter + i;
-			BUG_ON(pfn_to_mfn(pfn) != pfn);
-		}
-#endif
-		/* Now remap memory */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned long mfn = xen_remap_buf[i];
-
-			/* This will use the p2m leaf freed above */
-			if (!xen_update_mem_tables(remap_pfn_iter + i, mfn)) {
-				WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-					remap_pfn_iter + i, mfn);
-				return 0;
-			}
-
-			remap_cnt++;
-		}
+	/* Don't use memory until remapped */
+	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
 
-		left -= P2M_PER_PAGE;
-	}
-
-	/* Max boundary space possible */
-	BUG_ON(left > (P2M_PER_PAGE - 1) * 2);
+	mfn_save = virt_to_mfn(buf);
 
-	/* Now handle the boundary conditions */
-	ident_boundary_pfn = start_pfn;
-	remap_boundary_pfn = remap_pfn;
-	for (i = 0; i < left; i++) {
-		unsigned long mfn;
+	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
+	     ident_pfn_iter < ident_end_pfn;
+	     ident_pfn_iter += REMAP_SIZE, remap_pfn_iter += REMAP_SIZE) {
+		chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE;
 
-		/* These two checks move from the start to end boundaries */
-		if (ident_boundary_pfn == ident_start_pfn_align)
-			ident_boundary_pfn = ident_pfn_iter;
-		if (remap_boundary_pfn == remap_start_pfn_align)
-			remap_boundary_pfn = remap_pfn_iter;
+		/* Map first pfn to xen_remap_buf */
+		mfn = pfn_to_mfn(ident_pfn_iter);
+		set_pte_mfn(buf, mfn, PAGE_KERNEL);
 
-		/* Check we aren't past the end */
-		BUG_ON(ident_boundary_pfn >= start_pfn + size);
-		BUG_ON(remap_boundary_pfn >= remap_pfn + size);
+		/* Save mapping information in page */
+		xen_remap_buf.next_area_mfn = xen_remap_mfn;
+		xen_remap_buf.target_pfn = remap_pfn_iter;
+		xen_remap_buf.size = chunk;
+		for (i = 0; i < chunk; i++)
+			xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i);
 
-		mfn = pfn_to_mfn(ident_boundary_pfn);
+		/* Put remap buf into list. */
+		xen_remap_mfn = mfn;
 
-		if (!xen_update_mem_tables(remap_boundary_pfn, mfn)) {
-			WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-				remap_pfn_iter + i, mfn);
-			return 0;
-		}
-		remap_cnt++;
-
-		ident_boundary_pfn++;
-		remap_boundary_pfn++;
-	}
+		/* Set identity map */
+		ident_cnt += set_phys_range_identity(ident_pfn_iter,
+			ident_pfn_iter + chunk);
 
-	/* Finish up the identity map */
-	if (ident_start_pfn_align >= ident_end_pfn_align) {
-		/*
-                 * In this case we have an identity range which does not span an
-                 * aligned block so everything needs to be identity mapped here.
-                 * If we didn't check this we might remap too many pages since
-                 * the align boundaries are not meaningful in this case.
-	         */
-		ident_cnt += set_phys_range_identity(start_pfn,
-			start_pfn + size);
-	} else {
-		/* Remapped above so check each end of the chunk */
-		if (start_pfn < ident_start_pfn_align)
-			ident_cnt += set_phys_range_identity(start_pfn,
-				ident_start_pfn_align);
-		if (start_pfn + size > ident_pfn_iter)
-			ident_cnt += set_phys_range_identity(ident_pfn_iter,
-				start_pfn + size);
+		left -= chunk;
 	}
 
-	BUG_ON(ident_cnt != size);
-	BUG_ON(remap_cnt != size);
-
-	return size;
+	/* Restore old xen_remap_buf mapping */
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 }
 
 /*
@@ -396,8 +317,7 @@ static unsigned long __init xen_do_set_identity_and_remap_chunk(
 static unsigned long __init xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
-	unsigned long *identity, unsigned long *remapped,
-	unsigned long *released)
+	unsigned long *identity, unsigned long *released)
 {
 	unsigned long pfn;
 	unsigned long i = 0;
@@ -431,19 +351,12 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 		if (size > remap_range_size)
 			size = remap_range_size;
 
-		if (!xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn)) {
-			WARN(1, "Failed to remap 1:1 memory cur_pfn=%ld size=%ld remap_pfn=%ld\n",
-				cur_pfn, size, remap_pfn);
-			xen_set_identity_and_release_chunk(cur_pfn,
-				cur_pfn + left, nr_pages, identity, released);
-			break;
-		}
+		xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn);
 
 		/* Update variables to reflect new mappings. */
 		i += size;
 		remap_pfn += size;
 		*identity += size;
-		*remapped += size;
 	}
 
 	/*
@@ -464,7 +377,6 @@ static unsigned long __init xen_set_identity_and_remap(
 {
 	phys_addr_t start = 0;
 	unsigned long identity = 0;
-	unsigned long remapped = 0;
 	unsigned long last_pfn = nr_pages;
 	const struct e820entry *entry;
 	unsigned long num_released = 0;
@@ -494,8 +406,7 @@ static unsigned long __init xen_set_identity_and_remap(
 				last_pfn = xen_set_identity_and_remap_chunk(
 						list, map_size, start_pfn,
 						end_pfn, nr_pages, last_pfn,
-						&identity, &remapped,
-						&num_released);
+						&identity, &num_released);
 			start = end;
 		}
 	}
@@ -503,12 +414,65 @@ static unsigned long __init xen_set_identity_and_remap(
 	*released = num_released;
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
-	pr_info("Remapped %ld page(s), last_pfn=%ld\n", remapped,
-		last_pfn);
 	pr_info("Released %ld page(s)\n", num_released);
 
 	return last_pfn;
 }
+
+/*
+ * Remap the memory prepared in xen_do_set_identity_and_remap_chunk().
+ * The remap information (which mfn remap to which pfn) is contained in the
+ * to be remapped memory itself in a linked list anchored at xen_remap_mfn.
+ * This scheme allows to remap the different chunks in arbitrary order while
+ * the resulting mapping will be independant from the order.
+ */
+void __init xen_remap_memory(void)
+{
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn, pfn;
+	unsigned long remapped = 0;
+	unsigned int i;
+	unsigned long pfn_s = ~0UL;
+	unsigned long len = 0;
+
+	mfn_save = virt_to_mfn(buf);
+
+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
+		/* Map the remap information */
+		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
+
+		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
+
+		pfn = xen_remap_buf.target_pfn;
+		for (i = 0; i < xen_remap_buf.size; i++) {
+			mfn = xen_remap_buf.mfns[i];
+			xen_update_mem_tables(pfn, mfn);
+			remapped++;
+			pfn++;
+		}
+		if (pfn_s == ~0UL || pfn == pfn_s) {
+			pfn_s = xen_remap_buf.target_pfn;
+			len += xen_remap_buf.size;
+		} else if (pfn_s + len == xen_remap_buf.target_pfn) {
+			len += xen_remap_buf.size;
+		} else {
+			memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+			pfn_s = xen_remap_buf.target_pfn;
+			len = xen_remap_buf.size;
+		}
+
+		mfn = xen_remap_mfn;
+		xen_remap_mfn = xen_remap_buf.next_area_mfn;
+	}
+
+	if (pfn_s != ~0UL && len)
+		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
+
+	pr_info("Remapped %ld page(s)\n", remapped);
+}
+
 static unsigned long __init xen_get_max_pages(void)
 {
 	unsigned long max_pages = MAX_DOMAIN_PAGES;
@@ -616,7 +580,8 @@ char * __init xen_memory_setup(void)
 		extra_pages += max_pages - max_pfn;
 
 	/*
-	 * Set identity map on non-RAM pages and remap the underlying RAM.
+	 * Set identity map on non-RAM pages and prepare remapping the
+	 * underlying RAM.
 	 */
 	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
 					      &xen_released_pages);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 28c7e0b..5b72a06 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,6 +35,7 @@ void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
 void __init xen_arch_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBf-0006T4-K6; Fri, 28 Nov 2014 10:54:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBd-0006Qj-Td
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:06 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	56/8F-22819-D4458745; Fri, 28 Nov 2014 10:54:05 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417172044!13884107!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30708 invoked from network); 28 Nov 2014 10:54:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:04 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9A9B4AC54;
	Fri, 28 Nov 2014 10:54:03 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:49 +0100
Message-Id: <1417172039-8627-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 00/10] xen: Switch to virtual mapped linear
	p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paravirtualized kernels running on Xen use a three level tree for
translation of guest specific physical addresses to machine global
addresses. This p2m tree is used for construction of page table
entries, so the p2m tree walk is performance critical.

By using a linear virtual mapped p2m list accesses to p2m elements
can be sped up while even simplifying code. To achieve this goal
some p2m related initializations have to be performed later in the
boot process, as the final p2m list can be set up only after basic
memory management functions are available.

Changes in V4:
- carved out style corrections into new patch 1 as requested by David Vrabel
- minor modification in patch 5 (former patch 3) as suggested by David Vrabel
- carved out change of page allocation scheme from p2m.c into own patch as
  requested by Konrad Wilk, corrected for 32 bit as requested by Andrew Cooper
- added several comments
- simplified error handling in patch 4 (former patch 2)

Changes in V3:
- Carved out (new) patch 1 to make pure code movement more obvious
  as requested by David Vrabel
- New patch 6 introducing __pfn_to_mfn() (taken from patch 7) as
  requested by David Vrabel
- New patch 8 to speed up set_phys_to_machine() as suggested by
  David Vrabel

Changes in V2:
- splitted patch 2 in 4 smaller ones as requested by David Vrabel
- added highmem check when remapping kernel memory as requested by
  David Vrabel


Juergen Gross (10):
  xen: fix some style issues in p2m.c
  xen: Make functions static
  xen: use common page allocation function in p2m.c
  xen: Delay remapping memory of pv-domain
  xen: Delay m2p_override initialization
  xen: Delay invalidating extra memory
  x86: Introduce function to get pmd entry pointer
  xen: Hide get_phys_to_machine() to be able to tune common path
  xen: switch to linear virtual mapped sparse p2m list
  xen: Speed up set_phys_to_machine() by using read-only mappings

 arch/x86/include/asm/pgtable_types.h |    1 +
 arch/x86/include/asm/xen/page.h      |   48 +-
 arch/x86/mm/pageattr.c               |   20 +
 arch/x86/xen/mmu.c                   |   38 +-
 arch/x86/xen/p2m.c                   | 1320 ++++++++++++++--------------------
 arch/x86/xen/setup.c                 |  443 ++++++------
 arch/x86/xen/xen-ops.h               |    6 +-
 7 files changed, 838 insertions(+), 1038 deletions(-)

-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBk-0006WN-0k; Fri, 28 Nov 2014 10:54:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBj-0006VJ-2U
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:11 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	69/48-25714-25458745; Fri, 28 Nov 2014 10:54:10 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417172048!13815357!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22699 invoked from network); 28 Nov 2014 10:54:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:08 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0E7E2ADC6;
	Fri, 28 Nov 2014 10:54:07 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:58 +0100
Message-Id: <1417172039-8627-10-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 09/10] xen: switch to linear virtual mapped
	sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At start of the day the Xen hypervisor presents a contiguous mfn list
to a pv-domain. In order to support sparse memory this mfn list is
accessed via a three level p2m tree built early in the boot process.
Whenever the system needs the mfn associated with a pfn this tree is
used to find the mfn.

Instead of using a software walked tree for accessing a specific mfn
list entry this patch is creating a virtual address area for the
entire possible mfn list including memory holes. The holes are
covered by mapping a pre-defined  page consisting only of "invalid
mfn" entries. Access to a mfn entry is possible by just using the
virtual base address of the mfn list and the pfn as index into that
list. This speeds up the (hot) path of determining the mfn of a
pfn.

Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
showed following improvements:

Elapsed time: 32:50 ->  32:35
System:       18:07 ->  17:47
User:        104:00 -> 103:30

Tested with following configurations:
- 64 bit dom0, 8GB RAM
- 64 bit dom0, 128 GB RAM, PCI-area above 4 GB
- 32 bit domU, 512 MB, 8 GB, 43 GB (more wouldn't work even without
                                    the patch)
- 32 bit domU, ballooning up and down
- 32 bit domU, save and restore
- 32 bit domU with PCI passthrough
- 64 bit domU, 8 GB, 2049 MB, 5000 MB
- 64 bit domU, ballooning up and down
- 64 bit domU, save and restore
- 64 bit domU with PCI passthrough

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |  20 +-
 arch/x86/xen/mmu.c              |  34 +-
 arch/x86/xen/p2m.c              | 735 +++++++++++++++++-----------------------
 arch/x86/xen/xen-ops.h          |   2 +-
 4 files changed, 347 insertions(+), 444 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 410a6ec..f5d5de4 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -65,13 +65,25 @@ extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
  *   bits (identity or foreign) are set.
  * - __pfn_to_mfn() returns the found entry of the p2m table. A possibly set
  *   identity or foreign indicator will be still set. __pfn_to_mfn() is
- *   encapsulating get_phys_to_machine().
- * - get_phys_to_machine() is to be called by __pfn_to_mfn() only to allow
- *   for future optimizations.
+ *   encapsulating get_phys_to_machine() which is called in special cases only.
+ * - get_phys_to_machine() is to be called by __pfn_to_mfn() only in special
+ *   cases needing an extended handling.
  */
 static inline unsigned long __pfn_to_mfn(unsigned long pfn)
 {
-	return get_phys_to_machine(pfn);
+	unsigned long mfn;
+
+	if (pfn < xen_p2m_size)
+		mfn = xen_p2m_addr[pfn];
+	else if (unlikely(pfn < xen_max_p2m_pfn))
+		return get_phys_to_machine(pfn);
+	else
+		return IDENTITY_FRAME(pfn);
+
+	if (unlikely(mfn == INVALID_P2M_ENTRY))
+		return get_phys_to_machine(pfn);
+
+	return mfn;
 }
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 3e3f8f8..6ab6150 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1158,20 +1158,16 @@ static void __init xen_cleanhighmap(unsigned long vaddr,
 	 * instead of somewhere later and be confusing. */
 	xen_mc_flush();
 }
-static void __init xen_pagetable_p2m_copy(void)
+
+static void __init xen_pagetable_p2m_free(void)
 {
 	unsigned long size;
 	unsigned long addr;
-	unsigned long new_mfn_list;
-
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return;
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 
-	new_mfn_list = xen_revector_p2m_tree();
 	/* No memory or already called. */
-	if (!new_mfn_list || new_mfn_list == xen_start_info->mfn_list)
+	if ((unsigned long)xen_p2m_addr == xen_start_info->mfn_list)
 		return;
 
 	/* using __ka address and sticking INVALID_P2M_ENTRY! */
@@ -1189,8 +1185,6 @@ static void __init xen_pagetable_p2m_copy(void)
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 	memblock_free(__pa(xen_start_info->mfn_list), size);
-	/* And revector! Bye bye old array */
-	xen_start_info->mfn_list = new_mfn_list;
 
 	/* At this stage, cleanup_highmap has already cleaned __ka space
 	 * from _brk_limit way up to the max_pfn_mapped (which is the end of
@@ -1214,14 +1208,26 @@ static void __init xen_pagetable_p2m_copy(void)
 }
 #endif
 
-static void __init xen_pagetable_init(void)
+static void __init xen_pagetable_p2m_setup(void)
 {
-	paging_init();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	xen_vmalloc_p2m_tree();
+
 #ifdef CONFIG_X86_64
-	xen_pagetable_p2m_copy();
-#else
-	xen_revector_p2m_tree();
+	xen_pagetable_p2m_free();
 #endif
+	/* And revector! Bye bye old array */
+	xen_start_info->mfn_list = (unsigned long)xen_p2m_addr;
+}
+
+static void __init xen_pagetable_init(void)
+{
+	paging_init();
+
+	xen_pagetable_p2m_setup();
+
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8c3d8fb..7d84473 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -3,21 +3,22 @@
  * guests themselves, but it must also access and update the p2m array
  * during suspend/resume when all the pages are reallocated.
  *
- * The p2m table is logically a flat array, but we implement it as a
- * three-level tree to allow the address space to be sparse.
+ * The logical flat p2m table is mapped to a linear kernel memory area.
+ * For accesses by Xen a three-level tree linked via mfns only is set up to
+ * allow the address space to be sparse.
  *
- *                               Xen
- *                                |
- *     p2m_top              p2m_top_mfn
- *       /  \                   /   \
- * p2m_mid p2m_mid	p2m_mid_mfn p2m_mid_mfn
- *    / \      / \         /           /
- *  p2m p2m p2m p2m p2m p2m p2m ...
+ *               Xen
+ *                |
+ *          p2m_top_mfn
+ *              /   \
+ * p2m_mid_mfn p2m_mid_mfn
+ *         /           /
+ *  p2m p2m p2m ...
  *
  * The p2m_mid_mfn pages are mapped by p2m_top_mfn_p.
  *
- * The p2m_top and p2m_top_mfn levels are limited to 1 page, so the
- * maximum representable pseudo-physical address space is:
+ * The p2m_top_mfn level is limited to 1 page, so the maximum representable
+ * pseudo-physical address space is:
  *  P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * P2M_PER_PAGE pages
  *
  * P2M_PER_PAGE depends on the architecture, as a mfn is always
@@ -30,6 +31,9 @@
  * leaf entries, or for the top  root, or middle one, for which there is a void
  * entry, we assume it is  "missing". So (for example)
  *  pfn_to_mfn(0x90909090)=INVALID_P2M_ENTRY.
+ * We have a dedicated page p2m_missing with all entries being
+ * INVALID_P2M_ENTRY. This page may be referenced multiple times in the p2m
+ * list/tree in case there are multiple areas with P2M_PER_PAGE invalid pfns.
  *
  * We also have the possibility of setting 1-1 mappings on certain regions, so
  * that:
@@ -39,122 +43,20 @@
  * PCI BARs, or ACPI spaces), we can create mappings easily because we
  * get the PFN value to match the MFN.
  *
- * For this to work efficiently we have one new page p2m_identity and
- * allocate (via reserved_brk) any other pages we need to cover the sides
- * (1GB or 4MB boundary violations). All entries in p2m_identity are set to
- * INVALID_P2M_ENTRY type (Xen toolstack only recognizes that and MFNs,
- * no other fancy value).
+ * For this to work efficiently we have one new page p2m_identity. All entries
+ * in p2m_identity are set to INVALID_P2M_ENTRY type (Xen toolstack only
+ * recognizes that and MFNs, no other fancy value).
  *
  * On lookup we spot that the entry points to p2m_identity and return the
  * identity value instead of dereferencing and returning INVALID_P2M_ENTRY.
  * If the entry points to an allocated page, we just proceed as before and
- * return the PFN.  If the PFN has IDENTITY_FRAME_BIT set we unmask that in
+ * return the PFN. If the PFN has IDENTITY_FRAME_BIT set we unmask that in
  * appropriate functions (pfn_to_mfn).
  *
  * The reason for having the IDENTITY_FRAME_BIT instead of just returning the
  * PFN is that we could find ourselves where pfn_to_mfn(pfn)==pfn for a
  * non-identity pfn. To protect ourselves against we elect to set (and get) the
  * IDENTITY_FRAME_BIT on all identity mapped PFNs.
- *
- * This simplistic diagram is used to explain the more subtle piece of code.
- * There is also a digram of the P2M at the end that can help.
- * Imagine your E820 looking as so:
- *
- *                    1GB                                           2GB    4GB
- * /-------------------+---------\/----\         /----------\    /---+-----\
- * | System RAM        | Sys RAM ||ACPI|         | reserved |    | Sys RAM |
- * \-------------------+---------/\----/         \----------/    \---+-----/
- *                               ^- 1029MB                       ^- 2001MB
- *
- * [1029MB = 263424 (0x40500), 2001MB = 512256 (0x7D100),
- *  2048MB = 524288 (0x80000)]
- *
- * And dom0_mem=max:3GB,1GB is passed in to the guest, meaning memory past 1GB
- * is actually not present (would have to kick the balloon driver to put it in).
- *
- * When we are told to set the PFNs for identity mapping (see patch: "xen/setup:
- * Set identity mapping for non-RAM E820 and E820 gaps.") we pass in the start
- * of the PFN and the end PFN (263424 and 512256 respectively). The first step
- * is to reserve_brk a top leaf page if the p2m[1] is missing. The top leaf page
- * covers 512^2 of page estate (1GB) and in case the start or end PFN is not
- * aligned on 512^2*PAGE_SIZE (1GB) we reserve_brk new middle and leaf pages as
- * required to split any existing p2m_mid_missing middle pages.
- *
- * With the E820 example above, 263424 is not 1GB aligned so we allocate a
- * reserve_brk page which will cover the PFNs estate from 0x40000 to 0x80000.
- * Each entry in the allocate page is "missing" (points to p2m_missing).
- *
- * Next stage is to determine if we need to do a more granular boundary check
- * on the 4MB (or 2MB depending on architecture) off the start and end pfn's.
- * We check if the start pfn and end pfn violate that boundary check, and if
- * so reserve_brk a (p2m[x][y]) leaf page. This way we have a much finer
- * granularity of setting which PFNs are missing and which ones are identity.
- * In our example 263424 and 512256 both fail the check so we reserve_brk two
- * pages. Populate them with INVALID_P2M_ENTRY (so they both have "missing"
- * values) and assign them to p2m[1][2] and p2m[1][488] respectively.
- *
- * At this point we would at minimum reserve_brk one page, but could be up to
- * three. Each call to set_phys_range_identity has at maximum a three page
- * cost. If we were to query the P2M at this stage, all those entries from
- * start PFN through end PFN (so 1029MB -> 2001MB) would return
- * INVALID_P2M_ENTRY ("missing").
- *
- * The next step is to walk from the start pfn to the end pfn setting
- * the IDENTITY_FRAME_BIT on each PFN. This is done in set_phys_range_identity.
- * If we find that the middle entry is pointing to p2m_missing we can swap it
- * over to p2m_identity - this way covering 4MB (or 2MB) PFN space (and
- * similarly swapping p2m_mid_missing for p2m_mid_identity for larger regions).
- * At this point we do not need to worry about boundary aligment (so no need to
- * reserve_brk a middle page, figure out which PFNs are "missing" and which
- * ones are identity), as that has been done earlier.  If we find that the
- * middle leaf is not occupied by p2m_identity or p2m_missing, we dereference
- * that page (which covers 512 PFNs) and set the appropriate PFN with
- * IDENTITY_FRAME_BIT. In our example 263424 and 512256 end up there, and we
- * set from p2m[1][2][256->511] and p2m[1][488][0->256] with
- * IDENTITY_FRAME_BIT set.
- *
- * All other regions that are void (or not filled) either point to p2m_missing
- * (considered missing) or have the default value of INVALID_P2M_ENTRY (also
- * considered missing). In our case, p2m[1][2][0->255] and p2m[1][488][257->511]
- * contain the INVALID_P2M_ENTRY value and are considered "missing."
- *
- * Finally, the region beyond the end of of the E820 (4 GB in this example)
- * is set to be identity (in case there are MMIO regions placed here).
- *
- * This is what the p2m ends up looking (for the E820 above) with this
- * fabulous drawing:
- *
- *    p2m         /--------------\
- *  /-----\       | &mfn_list[0],|                           /-----------------\
- *  |  0  |------>| &mfn_list[1],|    /---------------\      | ~0, ~0, ..      |
- *  |-----|       |  ..., ~0, ~0 |    | ~0, ~0, [x]---+----->| IDENTITY [@256] |
- *  |  1  |---\   \--------------/    | [p2m_identity]+\     | IDENTITY [@257] |
- *  |-----|    \                      | [p2m_identity]+\\    | ....            |
- *  |  2  |--\  \-------------------->|  ...          | \\   \----------------/
- *  |-----|   \                       \---------------/  \\
- *  |  3  |-\  \                                          \\  p2m_identity [1]
- *  |-----|  \  \-------------------->/---------------\   /-----------------\
- *  | ..  |\  |                       | [p2m_identity]+-->| ~0, ~0, ~0, ... |
- *  \-----/ | |                       | [p2m_identity]+-->| ..., ~0         |
- *          | |                       | ....          |   \-----------------/
- *          | |                       +-[x], ~0, ~0.. +\
- *          | |                       \---------------/ \
- *          | |                                          \-> /---------------\
- *          | V  p2m_mid_missing       p2m_missing           | IDENTITY[@0]  |
- *          | /-----------------\     /------------\         | IDENTITY[@256]|
- *          | | [p2m_missing]   +---->| ~0, ~0, ...|         | ~0, ~0, ....  |
- *          | | [p2m_missing]   +---->| ..., ~0    |         \---------------/
- *          | | ...             |     \------------/
- *          | \-----------------/
- *          |
- *          |     p2m_mid_identity
- *          |   /-----------------\
- *          \-->| [p2m_identity]  +---->[1]
- *              | [p2m_identity]  +---->[1]
- *              | ...             |
- *              \-----------------/
- *
- * where ~0 is INVALID_P2M_ENTRY. IDENTITY is (PFN | IDENTITY_BIT)
  */
 
 #include <linux/init.h>
@@ -179,6 +81,8 @@
 #include "multicalls.h"
 #include "xen-ops.h"
 
+#define PMDS_PER_MID_PAGE	(P2M_MID_PER_PAGE / PTRS_PER_PTE)
+
 static void __init m2p_override_init(void);
 
 unsigned long *xen_p2m_addr __read_mostly;
@@ -188,22 +92,15 @@ EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
 EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
+static DEFINE_SPINLOCK(p2m_update_lock);
+
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
 static unsigned long **p2m_top_mfn_p;
-
-/* Placeholders for holes in the address space */
-static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long **, p2m_top, P2M_TOP_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long, p2m_identity, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
-
-RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
-
-static int use_brk = 1;
+static unsigned long *p2m_missing;
+static unsigned long *p2m_identity;
+static pte_t *p2m_missing_pte;
+static pte_t *p2m_identity_pte;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
@@ -221,14 +118,6 @@ static inline unsigned p2m_index(unsigned long pfn)
 	return pfn % P2M_PER_PAGE;
 }
 
-static void p2m_top_init(unsigned long ***top)
-{
-	unsigned i;
-
-	for (i = 0; i < P2M_TOP_PER_PAGE; i++)
-		top[i] = p2m_mid_missing;
-}
-
 static void p2m_top_mfn_init(unsigned long *top)
 {
 	unsigned i;
@@ -245,35 +134,32 @@ static void p2m_top_mfn_p_init(unsigned long **top)
 		top[i] = p2m_mid_missing_mfn;
 }
 
-static void p2m_mid_init(unsigned long **mid, unsigned long *leaf)
+static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
 {
 	unsigned i;
 
 	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = leaf;
+		mid[i] = virt_to_mfn(leaf);
 }
 
-static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
+static void p2m_init(unsigned long *p2m)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = virt_to_mfn(leaf);
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = INVALID_P2M_ENTRY;
 }
 
-static void p2m_init(unsigned long *p2m)
+static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		p2m[i] = INVALID_P2M_ENTRY;
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = IDENTITY_FRAME(pfn + i);
 }
 
 static void * __ref alloc_p2m_page(void)
 {
-	if (unlikely(use_brk))
-		return extend_brk(PAGE_SIZE, PAGE_SIZE);
-
 	if (unlikely(!slab_is_available()))
 		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
 
@@ -299,7 +185,10 @@ static void free_p2m_page(void *p)
  */
 void __ref xen_build_mfn_list_list(void)
 {
-	unsigned long pfn;
+	unsigned long pfn, mfn;
+	pte_t *ptep;
+	unsigned int level, topidx, mididx;
+	unsigned long *mid_mfn_p;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
@@ -319,20 +208,23 @@ void __ref xen_build_mfn_list_list(void)
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 	}
 
-	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned long **mid;
-		unsigned long *mid_mfn_p;
+	for (pfn = 0; pfn < xen_max_p2m_pfn && pfn < MAX_P2M_PFN;
+	     pfn += P2M_PER_PAGE) {
+		topidx = p2m_top_index(pfn);
+		mididx = p2m_mid_index(pfn);
 
-		mid = p2m_top[topidx];
 		mid_mfn_p = p2m_top_mfn_p[topidx];
+		ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn),
+				      &level);
+		BUG_ON(!ptep || level != PG_LEVEL_4K);
+		mfn = pte_mfn(*ptep);
+		ptep = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
 		/* Don't bother allocating any mfn mid levels if
 		 * they're just missing, just update the stored mfn,
 		 * since all could have changed over a migrate.
 		 */
-		if (mid == p2m_mid_missing) {
+		if (ptep == p2m_missing_pte || ptep == p2m_identity_pte) {
 			BUG_ON(mididx);
 			BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
 			p2m_top_mfn[topidx] = virt_to_mfn(p2m_mid_missing_mfn);
@@ -341,11 +233,6 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		if (mid_mfn_p == p2m_mid_missing_mfn) {
-			/*
-			 * XXX boot-time only!  We should never find
-			 * missing parts of the mfn tree after
-			 * runtime.
-			 */
 			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
@@ -353,7 +240,7 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
-		mid_mfn_p[mididx] = virt_to_mfn(mid[mididx]);
+		mid_mfn_p[mididx] = mfn;
 	}
 }
 
@@ -372,154 +259,153 @@ void xen_setup_mfn_list_list(void)
 /* Set up p2m_top to point to the domain-builder provided p2m pages */
 void __init xen_build_dynamic_phys_to_machine(void)
 {
-	unsigned long *mfn_list;
-	unsigned long max_pfn;
 	unsigned long pfn;
 
 	 if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
 	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
-	mfn_list = (unsigned long *)xen_start_info->mfn_list;
-	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
-	xen_max_p2m_pfn = max_pfn;
-	xen_p2m_size = max_pfn;
+	xen_p2m_size = ALIGN(xen_start_info->nr_pages, P2M_PER_PAGE);
 
-	p2m_missing = alloc_p2m_page();
-	p2m_init(p2m_missing);
-	p2m_identity = alloc_p2m_page();
-	p2m_init(p2m_identity);
+	for (pfn = xen_start_info->nr_pages; pfn < xen_p2m_size; pfn++)
+		xen_p2m_addr[pfn] = INVALID_P2M_ENTRY;
 
-	p2m_mid_missing = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_identity, p2m_identity);
+	xen_max_p2m_pfn = xen_p2m_size;
+}
 
-	p2m_top = alloc_p2m_page();
-	p2m_top_init(p2m_top);
+#define P2M_TYPE_IDENTITY	0
+#define P2M_TYPE_MISSING	1
+#define P2M_TYPE_PFN		2
+#define P2M_TYPE_UNKNOWN	3
 
-	/*
-	 * The domain builder gives us a pre-constructed p2m array in
-	 * mfn_list for all the pages initially given to us, so we just
-	 * need to graft that into our tree structure.
-	 */
-	for (pfn = 0; pfn < max_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
+static int xen_p2m_elem_type(unsigned long pfn)
+{
+	unsigned long mfn;
 
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = alloc_p2m_page();
-			p2m_mid_init(mid, p2m_missing);
+	if (pfn >= xen_p2m_size)
+		return P2M_TYPE_IDENTITY;
 
-			p2m_top[topidx] = mid;
-		}
+	mfn = xen_p2m_addr[pfn];
 
-		/*
-		 * As long as the mfn_list has enough entries to completely
-		 * fill a p2m page, pointing into the array is ok. But if
-		 * not the entries beyond the last pfn will be undefined.
-		 */
-		if (unlikely(pfn + P2M_PER_PAGE > max_pfn)) {
-			unsigned long p2midx;
+	if (mfn == INVALID_P2M_ENTRY)
+		return P2M_TYPE_MISSING;
 
-			p2midx = max_pfn % P2M_PER_PAGE;
-			for ( ; p2midx < P2M_PER_PAGE; p2midx++)
-				mfn_list[pfn + p2midx] = INVALID_P2M_ENTRY;
-		}
-		p2m_top[topidx][mididx] = &mfn_list[pfn];
-	}
+	if (mfn & IDENTITY_FRAME_BIT)
+		return P2M_TYPE_IDENTITY;
+
+	return P2M_TYPE_PFN;
 }
-#ifdef CONFIG_X86_64
-unsigned long __init xen_revector_p2m_tree(void)
+
+static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 {
-	unsigned long va_start;
-	unsigned long va_end;
+	unsigned int i, chunk;
 	unsigned long pfn;
-	unsigned long pfn_free = 0;
-	unsigned long *mfn_list = NULL;
-	unsigned long size;
-
-	use_brk = 0;
-	va_start = xen_start_info->mfn_list;
-	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
-	 * so make sure it is rounded up to that */
-	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
-	va_end = va_start + size;
-
-	/* If we were revectored already, don't do it again. */
-	if (va_start <= __START_KERNEL_map && va_start >= __PAGE_OFFSET)
-		return 0;
-
-	mfn_list = alloc_bootmem_align(size, PAGE_SIZE);
-	if (!mfn_list) {
-		pr_warn("Could not allocate space for a new P2M tree!\n");
-		return xen_start_info->mfn_list;
-	}
-	/* Fill it out with INVALID_P2M_ENTRY value */
-	memset(mfn_list, 0xFF, size);
+	unsigned long *mfns;
+	pte_t *ptep;
+	pmd_t *pmdp;
+	int type;
 
-	for (pfn = 0; pfn < ALIGN(MAX_DOMAIN_PAGES, P2M_PER_PAGE); pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx;
-		unsigned long *mid_p;
-
-		if (!p2m_top[topidx])
-			continue;
+	p2m_missing = alloc_p2m_page();
+	p2m_init(p2m_missing);
+	p2m_identity = alloc_p2m_page();
+	p2m_init(p2m_identity);
 
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
+	p2m_missing_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_missing_pte) >> PAGE_SHIFT);
+	p2m_identity_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
+	for (i = 0; i < PTRS_PER_PTE; i++) {
+		set_pte(p2m_missing_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
+		set_pte(p2m_identity_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
+	}
 
-		mididx = p2m_mid_index(pfn);
-		mid_p = p2m_top[topidx][mididx];
-		if (!mid_p)
-			continue;
-		if ((mid_p == p2m_missing) || (mid_p == p2m_identity))
+	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
+		/*
+		 * Try to map missing/identity PMDs or p2m-pages if possible.
+		 * We have to respect the structure of the mfn_list_list
+		 * which will be built just afterwards.
+		 * Chunk size to test is one p2m page if we are in the middle
+		 * of a mfn_list_list mid page and the complete mid page area
+		 * if we are at index 0 of the mid page. Please note that a
+		 * mid page might cover more than one PMD, e.g. on 32 bit PAE
+		 * kernels.
+		 */
+		chunk = (pfn & (P2M_PER_PAGE * P2M_MID_PER_PAGE - 1)) ?
+			P2M_PER_PAGE : P2M_PER_PAGE * P2M_MID_PER_PAGE;
+
+		type = xen_p2m_elem_type(pfn);
+		i = 0;
+		if (type != P2M_TYPE_PFN)
+			for (i = 1; i < chunk; i++)
+				if (xen_p2m_elem_type(pfn + i) != type)
+					break;
+		if (i < chunk)
+			/* Reset to minimal chunk size. */
+			chunk = P2M_PER_PAGE;
+
+		if (type == P2M_TYPE_PFN || i < chunk) {
+			/* Use initial p2m page contents. */
+#ifdef CONFIG_X86_64
+			mfns = alloc_p2m_page();
+			copy_page(mfns, xen_p2m_addr + pfn);
+#else
+			mfns = xen_p2m_addr + pfn;
+#endif
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		if ((unsigned long)mid_p == INVALID_P2M_ENTRY)
+		if (chunk == P2M_PER_PAGE) {
+			/* Map complete missing or identity p2m-page. */
+			mfns = (type == P2M_TYPE_MISSING) ?
+				p2m_missing : p2m_identity;
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		/* The old va. Rebase it on mfn_list */
-		if (mid_p >= (unsigned long *)va_start && mid_p <= (unsigned long *)va_end) {
-			unsigned long *new;
+		/* Complete missing or identity PMD(s) can be mapped. */
+		ptep = (type == P2M_TYPE_MISSING) ?
+			p2m_missing_pte : p2m_identity_pte;
+		for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+			pmdp = populate_extra_pmd(
+				(unsigned long)(p2m + pfn + i * PTRS_PER_PTE));
+			set_pmd(pmdp, __pmd(__pa(ptep) | _KERNPG_TABLE));
+		}
+	}
+}
 
-			if (pfn_free  > (size / sizeof(unsigned long))) {
-				WARN(1, "Only allocated for %ld pages, but we want %ld!\n",
-				     size / sizeof(unsigned long), pfn_free);
-				return 0;
-			}
-			new = &mfn_list[pfn_free];
+void __init xen_vmalloc_p2m_tree(void)
+{
+	static struct vm_struct vm;
 
-			copy_page(new, mid_p);
-			p2m_top[topidx][mididx] = &mfn_list[pfn_free];
+	vm.flags = VM_ALLOC;
+	vm.size = ALIGN(sizeof(unsigned long) * xen_max_p2m_pfn,
+			PMD_SIZE * PMDS_PER_MID_PAGE);
+	vm_area_register_early(&vm, PMD_SIZE * PMDS_PER_MID_PAGE);
+	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);
 
-			pfn_free += P2M_PER_PAGE;
+	xen_max_p2m_pfn = vm.size / sizeof(unsigned long);
 
-		}
-		/* This should be the leafs allocated for identity from _brk. */
-	}
+	xen_rebuild_p2m_list(vm.addr);
 
+	xen_p2m_addr = vm.addr;
 	xen_p2m_size = xen_max_p2m_pfn;
-	xen_p2m_addr = mfn_list;
 
 	xen_inv_extra_mem();
 
 	m2p_override_init();
-	return (unsigned long)mfn_list;
 }
-#else
-unsigned long __init xen_revector_p2m_tree(void)
-{
-	use_brk = 0;
-	xen_p2m_size = xen_max_p2m_pfn;
-	xen_inv_extra_mem();
-	m2p_override_init();
-	return 0;
-}
-#endif
+
 unsigned long get_phys_to_machine(unsigned long pfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	if (unlikely(pfn >= xen_p2m_size)) {
 		if (pfn < xen_max_p2m_pfn)
@@ -528,23 +414,83 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 		return IDENTITY_FRAME(pfn);
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
 	/*
 	 * The INVALID_P2M_ENTRY is filled in both p2m_*identity
 	 * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
 	 * would be wrong.
 	 */
-	if (p2m_top[topidx][mididx] == p2m_identity)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
 		return IDENTITY_FRAME(pfn);
 
-	return p2m_top[topidx][mididx][idx];
+	return xen_p2m_addr[pfn];
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
 /*
+ * Allocate new pmd(s). It is checked whether the old pmd is still in place.
+ * If not, nothing is changed. This is okay as the only reason for allocating
+ * a new pmd is to replace p2m_missing_pte or p2m_identity_pte by a individual
+ * pmd. In case of PAE/x86-32 there are multiple pmds to allocate!
+ */
+static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t *ptep, pte_t *pte_pg)
+{
+	pte_t *ptechk;
+	pte_t *pteret = ptep;
+	pte_t *pte_newpg[PMDS_PER_MID_PAGE];
+	pmd_t *pmdp;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long vaddr;
+	int i;
+
+	/* Do all allocations first to bail out in error case. */
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		pte_newpg[i] = alloc_p2m_page();
+		if (!pte_newpg[i]) {
+			for (i--; i >= 0; i--)
+				free_p2m_page(pte_newpg[i]);
+
+			return NULL;
+		}
+	}
+
+	vaddr = addr & ~(PMD_SIZE * PMDS_PER_MID_PAGE - 1);
+
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		copy_page(pte_newpg[i], pte_pg);
+		paravirt_alloc_pte(&init_mm, __pa(pte_newpg[i]) >> PAGE_SHIFT);
+
+		pmdp = lookup_pmd_address(vaddr);
+		BUG_ON(!pmdp);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		ptechk = lookup_address(vaddr, &level);
+		if (ptechk == pte_pg) {
+			set_pmd(pmdp,
+				__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+			if (vaddr == (addr & ~(PMD_SIZE - 1)))
+				pteret = pte_offset_kernel(pmdp, addr);
+			pte_newpg[i] = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
+
+		if (pte_newpg[i]) {
+			paravirt_release_pte(__pa(pte_newpg[i]) >> PAGE_SHIFT);
+			free_p2m_page(pte_newpg[i]);
+		}
+
+		vaddr += PMD_SIZE;
+	}
+
+	return pteret;
+}
+
+/*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
  * parallel mfn tree is kept in sync.  We may race with other cpus, so
@@ -554,58 +500,62 @@ EXPORT_SYMBOL_GPL(get_phys_to_machine);
 static bool alloc_p2m(unsigned long pfn)
 {
 	unsigned topidx, mididx;
-	unsigned long ***top_p, **mid;
 	unsigned long *top_mfn_p, *mid_mfn;
-	unsigned long *p2m_orig;
+	pte_t *ptep, *pte_pg;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long addr = (unsigned long)(xen_p2m_addr + pfn);
+	unsigned long p2m_pfn;
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
 
-	top_p = &p2m_top[topidx];
-	mid = ACCESS_ONCE(*top_p);
+	ptep = lookup_address(addr, &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
+	pte_pg = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
-	if (mid == p2m_mid_missing) {
-		/* Mid level is missing, allocate a new one */
-		mid = alloc_p2m_page();
-		if (!mid)
+	if (pte_pg == p2m_missing_pte || pte_pg == p2m_identity_pte) {
+		/* PMD level is missing, allocate a new one */
+		ptep = alloc_p2m_pmd(addr, ptep, pte_pg);
+		if (!ptep)
 			return false;
-
-		p2m_mid_init(mid, p2m_missing);
-
-		if (cmpxchg(top_p, p2m_mid_missing, mid) != p2m_mid_missing)
-			free_p2m_page(mid);
 	}
 
-	top_mfn_p = &p2m_top_mfn[topidx];
-	mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
+	if (p2m_top_mfn) {
+		top_mfn_p = &p2m_top_mfn[topidx];
+		mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
 
-	BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
+		BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
 
-	if (mid_mfn == p2m_mid_missing_mfn) {
-		/* Separately check the mid mfn level */
-		unsigned long missing_mfn;
-		unsigned long mid_mfn_mfn;
-		unsigned long old_mfn;
+		if (mid_mfn == p2m_mid_missing_mfn) {
+			/* Separately check the mid mfn level */
+			unsigned long missing_mfn;
+			unsigned long mid_mfn_mfn;
+			unsigned long old_mfn;
 
-		mid_mfn = alloc_p2m_page();
-		if (!mid_mfn)
-			return false;
+			mid_mfn = alloc_p2m_page();
+			if (!mid_mfn)
+				return false;
 
-		p2m_mid_mfn_init(mid_mfn, p2m_missing);
+			p2m_mid_mfn_init(mid_mfn, p2m_missing);
 
-		missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
-		mid_mfn_mfn = virt_to_mfn(mid_mfn);
-		old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
-		if (old_mfn != missing_mfn) {
-			free_p2m_page(mid_mfn);
-			mid_mfn = mfn_to_virt(old_mfn);
-		} else {
-			p2m_top_mfn_p[topidx] = mid_mfn;
+			missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
+			mid_mfn_mfn = virt_to_mfn(mid_mfn);
+			old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
+			if (old_mfn != missing_mfn) {
+				free_p2m_page(mid_mfn);
+				mid_mfn = mfn_to_virt(old_mfn);
+			} else {
+				p2m_top_mfn_p[topidx] = mid_mfn;
+			}
 		}
+	} else {
+		mid_mfn = NULL;
 	}
 
-	p2m_orig = ACCESS_ONCE(p2m_top[topidx][mididx]);
-	if (p2m_orig == p2m_identity || p2m_orig == p2m_missing) {
+	p2m_pfn = pte_pfn(ACCESS_ONCE(*ptep));
+	if (p2m_pfn == PFN_DOWN(__pa(p2m_identity)) ||
+	    p2m_pfn == PFN_DOWN(__pa(p2m_missing))) {
 		/* p2m leaf page is missing */
 		unsigned long *p2m;
 
@@ -613,12 +563,25 @@ static bool alloc_p2m(unsigned long pfn)
 		if (!p2m)
 			return false;
 
-		p2m_init(p2m);
+		if (p2m_pfn == PFN_DOWN(__pa(p2m_missing)))
+			p2m_init(p2m);
+		else
+			p2m_init_identity(p2m, pfn);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		if (pte_pfn(*ptep) == p2m_pfn) {
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(p2m)), PAGE_KERNEL));
+			if (mid_mfn)
+				mid_mfn[mididx] = virt_to_mfn(p2m);
+			p2m = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
 
-		if (cmpxchg(&mid[mididx], p2m_orig, p2m) != p2m_orig)
+		if (p2m)
 			free_p2m_page(p2m);
-		else
-			mid_mfn[mididx] = virt_to_mfn(p2m);
 	}
 
 	return true;
@@ -647,10 +610,10 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	return pfn - pfn_s;
 }
 
-/* Try to install p2m mapping; fail if intermediate bits missing */
 bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	/* don't track P2M changes in autotranslate guests */
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -661,55 +624,27 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* For sparse holes were the p2m leaf has real PFN along with
-	 * PCI holes, stick in the PFN as the MFN value.
-	 *
-	 * set_phys_range_identity() will have allocated new middle
-	 * and leaf pages as required so an existing p2m_mid_missing
-	 * or p2m_missing mean that whole range will be identity so
-	 * these can be switched to p2m_mid_identity or p2m_identity.
-	 */
-	if (mfn != INVALID_P2M_ENTRY && (mfn & IDENTITY_FRAME_BIT)) {
-		if (p2m_top[topidx] == p2m_mid_identity)
-			return true;
-
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx], p2m_mid_missing,
-					p2m_mid_identity) != p2m_mid_missing);
-			return true;
-		}
-
-		if (p2m_top[topidx][mididx] == p2m_identity)
-			return true;
-
-		/* Swap over from MISSING to IDENTITY if needed. */
-		if (p2m_top[topidx][mididx] == p2m_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx][mididx], p2m_missing,
-				p2m_identity) != p2m_missing);
-			return true;
-		}
-	}
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
-	if (p2m_top[topidx][mididx] == p2m_missing)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_missing)))
 		return mfn == INVALID_P2M_ENTRY;
 
-	p2m_top[topidx][mididx][idx] = mfn;
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
+		return mfn == IDENTITY_FRAME(pfn);
+
+	xen_p2m_addr[pfn] = mfn;
 
 	return true;
 }
 
 bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
+	if (unlikely(!__set_phys_to_machine(pfn, mfn))) {
 		if (!alloc_p2m(pfn))
 			return false;
 
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
+		return __set_phys_to_machine(pfn, mfn);
 	}
 
 	return true;
@@ -1035,79 +970,29 @@ EXPORT_SYMBOL_GPL(m2p_find_override_pfn);
 #include "debugfs.h"
 static int p2m_dump_show(struct seq_file *m, void *v)
 {
-	static const char * const level_name[] = { "top", "middle",
-						"entry", "abnormal", "error"};
-#define TYPE_IDENTITY 0
-#define TYPE_MISSING 1
-#define TYPE_PFN 2
-#define TYPE_UNKNOWN 3
 	static const char * const type_name[] = {
-				[TYPE_IDENTITY] = "identity",
-				[TYPE_MISSING] = "missing",
-				[TYPE_PFN] = "pfn",
-				[TYPE_UNKNOWN] = "abnormal"};
-	unsigned long pfn, prev_pfn_type = 0, prev_pfn_level = 0;
-	unsigned int uninitialized_var(prev_level);
-	unsigned int uninitialized_var(prev_type);
-
-	if (!p2m_top)
-		return 0;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn++) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned idx = p2m_index(pfn);
-		unsigned lvl, type;
-
-		lvl = 4;
-		type = TYPE_UNKNOWN;
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			lvl = 0; type = TYPE_MISSING;
-		} else if (p2m_top[topidx] == NULL) {
-			lvl = 0; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == NULL) {
-			lvl = 1; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == p2m_identity) {
-			lvl = 1; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx] == p2m_missing) {
-			lvl = 1; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == 0) {
-			lvl = 2; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx][idx] == IDENTITY_FRAME(pfn)) {
-			lvl = 2; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx][idx] == INVALID_P2M_ENTRY) {
-			lvl = 2; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == pfn) {
-			lvl = 2; type = TYPE_PFN;
-		} else if (p2m_top[topidx][mididx][idx] != pfn) {
-			lvl = 2; type = TYPE_PFN;
-		}
-		if (pfn == 0) {
-			prev_level = lvl;
+				[P2M_TYPE_IDENTITY] = "identity",
+				[P2M_TYPE_MISSING] = "missing",
+				[P2M_TYPE_PFN] = "pfn",
+				[P2M_TYPE_UNKNOWN] = "abnormal"};
+	unsigned long pfn, first_pfn;
+	int type, prev_type;
+
+	prev_type = xen_p2m_elem_type(0);
+	first_pfn = 0;
+
+	for (pfn = 0; pfn < xen_p2m_size; pfn++) {
+		type = xen_p2m_elem_type(pfn);
+		if (type != prev_type) {
+			seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+				   type_name[prev_type]);
 			prev_type = type;
-		}
-		if (pfn == MAX_DOMAIN_PAGES-1) {
-			lvl = 3;
-			type = TYPE_UNKNOWN;
-		}
-		if (prev_type != type) {
-			seq_printf(m, " [0x%lx->0x%lx] %s\n",
-				prev_pfn_type, pfn, type_name[prev_type]);
-			prev_pfn_type = pfn;
-			prev_type = type;
-		}
-		if (prev_level != lvl) {
-			seq_printf(m, " [0x%lx->0x%lx] level %s\n",
-				prev_pfn_level, pfn, level_name[prev_level]);
-			prev_pfn_level = pfn;
-			prev_level = lvl;
+			first_pfn = pfn;
 		}
 	}
+	seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+		   type_name[prev_type]);
 	return 0;
-#undef TYPE_IDENTITY
-#undef TYPE_MISSING
-#undef TYPE_PFN
-#undef TYPE_UNKNOWN
 }
 
 static int p2m_dump_open(struct inode *inode, struct file *filp)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 02b0b0f..f92921f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -49,7 +49,7 @@ void xen_hvm_init_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-unsigned long __init xen_revector_p2m_tree(void);
+void __init xen_vmalloc_p2m_tree(void);
 
 void xen_init_irq_ops(void);
 void xen_setup_timer(int cpu);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBf-0006TR-VX; Fri, 28 Nov 2014 10:54:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBd-0006Qi-Tg
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:06 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	0E/E6-22737-D4458745; Fri, 28 Nov 2014 10:54:05 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417172044!13822277!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23503 invoked from network); 28 Nov 2014 10:54:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:04 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id F3162AC7E;
	Fri, 28 Nov 2014 10:54:03 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:50 +0100
Message-Id: <1417172039-8627-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 1/9] xen: fix some style issues in p2m.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>
MIME-Version: 1.0
Content-Type: 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 source arch/x86/xen/p2m.c has some coding style issues. Fix them.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/p2m.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 9201a38..73d354a 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -922,7 +922,7 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 			continue;
 
 		if (map_ops[i].flags & GNTMAP_contains_pte) {
-			pte = (pte_t *) (mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
+			pte = (pte_t *)(mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
 				(map_ops[i].host_addr & ~PAGE_MASK));
 			mfn = pte_mfn(*pte);
 		} else {
@@ -970,7 +970,7 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 		address = (unsigned long)__va(pfn << PAGE_SHIFT);
 		ptep = lookup_address(address, &level);
 		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-					"m2p_add_override: pfn %lx not mapped", pfn))
+			 "m2p_add_override: pfn %lx not mapped", pfn))
 			return -EINVAL;
 	}
 
@@ -1072,7 +1072,7 @@ int m2p_remove_override(struct page *page,
 		ptep = lookup_address(address, &level);
 
 		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-					"m2p_remove_override: pfn %lx not mapped", pfn))
+			 "m2p_remove_override: pfn %lx not mapped", pfn))
 			return -EINVAL;
 	}
 
@@ -1102,9 +1102,8 @@ int m2p_remove_override(struct page *page,
 			 * hypercall actually returned an error.
 			 */
 			if (kmap_op->handle == GNTST_general_error) {
-				printk(KERN_WARNING "m2p_remove_override: "
-						"pfn %lx mfn %lx, failed to modify kernel mappings",
-						pfn, mfn);
+				pr_warn("m2p_remove_override: pfn %lx mfn %lx, failed to modify kernel mappings",
+					pfn, mfn);
 				put_balloon_scratch_page();
 				return -1;
 			}
@@ -1112,14 +1111,14 @@ int m2p_remove_override(struct page *page,
 			xen_mc_batch();
 
 			mcs = __xen_mc_entry(
-					sizeof(struct gnttab_unmap_and_replace));
+				sizeof(struct gnttab_unmap_and_replace));
 			unmap_op = mcs.args;
 			unmap_op->host_addr = kmap_op->host_addr;
 			unmap_op->new_addr = scratch_page_address;
 			unmap_op->handle = kmap_op->handle;
 
 			MULTI_grant_table_op(mcs.mc,
-					GNTTABOP_unmap_and_replace, unmap_op, 1);
+				GNTTABOP_unmap_and_replace, unmap_op, 1);
 
 			mcs = __xen_mc_entry(0);
 			MULTI_update_va_mapping(mcs.mc, scratch_page_address,
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBg-0006Tx-On; Fri, 28 Nov 2014 10:54:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBe-0006Qt-T6
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	18/CF-15461-E4458745; Fri, 28 Nov 2014 10:54:06 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417172045!12067758!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24551 invoked from network); 28 Nov 2014 10:54:05 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:05 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 587E3ADB0;
	Fri, 28 Nov 2014 10:54:05 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:54 +0100
Message-Id: <1417172039-8627-6-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 05/10] xen: Delay m2p_override initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 m2p overrides are used to be able to find the local pfn for a
foreign mfn mapped into the domain. They are used by driver backends
having to access frontend data.

As this functionality isn't used in early boot it makes no sense to
initialize the m2p override functions very early. It can be done
later without doing any harm, removing the need for allocating memory
via extend_brk().

While at it make some m2p override functions static as they are only
used internally.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 24cd9d1..8676f35 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -428,8 +428,6 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		}
 		p2m_top[topidx][mididx] = &mfn_list[pfn];
 	}
-
-	m2p_override_init();
 }
 #ifdef CONFIG_X86_64
 unsigned long __init xen_revector_p2m_tree(void)
@@ -500,13 +498,15 @@ unsigned long __init xen_revector_p2m_tree(void)
 		}
 		/* This should be the leafs allocated for identity from _brk. */
 	}
-	return (unsigned long)mfn_list;
 
+	m2p_override_init();
+	return (unsigned long)mfn_list;
 }
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	m2p_override_init();
 	return 0;
 }
 #endif
@@ -796,15 +796,16 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 #define M2P_OVERRIDE_HASH_SHIFT	10
 #define M2P_OVERRIDE_HASH	(1 << M2P_OVERRIDE_HASH_SHIFT)
 
-static RESERVE_BRK_ARRAY(struct list_head, m2p_overrides, M2P_OVERRIDE_HASH);
+static struct list_head *m2p_overrides;
 static DEFINE_SPINLOCK(m2p_override_lock);
 
 static void __init m2p_override_init(void)
 {
 	unsigned i;
 
-	m2p_overrides = extend_brk(sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
-				   sizeof(unsigned long));
+	m2p_overrides = alloc_bootmem_align(
+				sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
+				sizeof(unsigned long));
 
 	for (i = 0; i < M2P_OVERRIDE_HASH; i++)
 		INIT_LIST_HEAD(&m2p_overrides[i]);
@@ -932,10 +933,14 @@ EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
 static struct page *m2p_find_override(unsigned long mfn)
 {
 	unsigned long flags;
-	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
+	struct list_head *bucket;
 	struct page *p, *ret;
 
+	if (unlikely(!m2p_overrides))
+		return NULL;
+
 	ret = NULL;
+	bucket = &m2p_overrides[mfn_hash(mfn)];
 
 	spin_lock_irqsave(&m2p_override_lock, flags);
 
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBh-0006U5-3j; Fri, 28 Nov 2014 10:54:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBf-0006Ra-Cp
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:07 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	44/38-11581-E4458745; Fri, 28 Nov 2014 10:54:06 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417172045!9720089!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14161 invoked from network); 28 Nov 2014 10:54:05 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2014 10:54:05 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 00C0AAD9F;
	Fri, 28 Nov 2014 10:54:05 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:53 +0100
Message-Id: <1417172039-8627-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 04/10] xen: Delay remapping memory of
	pv-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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Early in the boot process the memory layout of a pv-domain is changed
to match the E820 map (either the host one for Dom0 or the Xen one)
regarding placement of RAM and PCI holes. This requires removing memory
pages initially located at positions not suitable for RAM and adding
them later at higher addresses where no restrictions apply.

To be able to operate on the hypervisor supported p2m list until a
virtual mapped linear p2m list can be constructed, remapping must
be delayed until virtual memory management is initialized, as the
initial p2m list can't be extended unlimited at physical memory
initialization time due to it's fixed structure.

A further advantage is the reduction in complexity and code volume as
we don't have to be careful regarding memory restrictions during p2m
updates.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/xen/page.h |   1 -
 arch/x86/xen/mmu.c              |   4 +
 arch/x86/xen/p2m.c              |  94 ----------
 arch/x86/xen/setup.c            | 369 ++++++++++++++++++----------------------
 arch/x86/xen/xen-ops.h          |   1 +
 5 files changed, 172 insertions(+), 297 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 6c16451..b475297 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -44,7 +44,6 @@ extern unsigned long  machine_to_phys_nr;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
-extern bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 					     unsigned long pfn_e);
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b995b871..601914d 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1225,6 +1225,10 @@ static void __init xen_pagetable_init(void)
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
+	/* Remap memory freed due to conflicts with E820 map */
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_remap_memory();
+
 	xen_setup_shared_info();
 	xen_post_allocator_init();
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index fa53dc2..24cd9d1 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -662,100 +662,6 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 	return true;
 }
 
-/*
- * Skim over the P2M tree looking at pages that are either filled with
- * INVALID_P2M_ENTRY or with 1:1 PFNs. If found, re-use that page and
- * replace the P2M leaf with a p2m_missing or p2m_identity.
- * Stick the old page in the new P2M tree location.
- */
-static bool __init early_can_reuse_p2m_middle(unsigned long set_pfn)
-{
-	unsigned topidx;
-	unsigned mididx;
-	unsigned ident_pfns;
-	unsigned inv_pfns;
-	unsigned long *p2m;
-	unsigned idx;
-	unsigned long pfn;
-
-	/* We only look when this entails a P2M middle layer */
-	if (p2m_index(set_pfn))
-		return false;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
-		topidx = p2m_top_index(pfn);
-
-		if (!p2m_top[topidx])
-			continue;
-
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
-
-		mididx = p2m_mid_index(pfn);
-		p2m = p2m_top[topidx][mididx];
-		if (!p2m)
-			continue;
-
-		if ((p2m == p2m_missing) || (p2m == p2m_identity))
-			continue;
-
-		if ((unsigned long)p2m == INVALID_P2M_ENTRY)
-			continue;
-
-		ident_pfns = 0;
-		inv_pfns = 0;
-		for (idx = 0; idx < P2M_PER_PAGE; idx++) {
-			/* IDENTITY_PFNs are 1:1 */
-			if (p2m[idx] == IDENTITY_FRAME(pfn + idx))
-				ident_pfns++;
-			else if (p2m[idx] == INVALID_P2M_ENTRY)
-				inv_pfns++;
-			else
-				break;
-		}
-		if ((ident_pfns == P2M_PER_PAGE) || (inv_pfns == P2M_PER_PAGE))
-			goto found;
-	}
-	return false;
-found:
-	/* Found one, replace old with p2m_identity or p2m_missing */
-	p2m_top[topidx][mididx] = (ident_pfns ? p2m_identity : p2m_missing);
-
-	/* Reset where we want to stick the old page in. */
-	topidx = p2m_top_index(set_pfn);
-	mididx = p2m_mid_index(set_pfn);
-
-	/* This shouldn't happen */
-	if (WARN_ON(p2m_top[topidx] == p2m_mid_missing))
-		early_alloc_p2m_middle(set_pfn);
-
-	if (WARN_ON(p2m_top[topidx][mididx] != p2m_missing))
-		return false;
-
-	p2m_init(p2m);
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn)
-{
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
-		if (!early_alloc_p2m_middle(pfn))
-			return false;
-
-		if (early_can_reuse_p2m_middle(pfn))
-			return __set_phys_to_machine(pfn, mfn);
-
-		if (!early_alloc_p2m(pfn, false /* boundary crossover OK!*/))
-			return false;
-
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
-	}
-
-	return true;
-}
-
 static void __init early_split_p2m(unsigned long pfn)
 {
 	unsigned long mididx, idx;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 29834b3..e0b6912f 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -30,6 +30,7 @@
 #include "xen-ops.h"
 #include "vdso.h"
 #include "p2m.h"
+#include "mmu.h"
 
 /* These are code, but not functions.  Defined in entry.S */
 extern const char xen_hypervisor_callback[];
@@ -47,8 +48,19 @@ struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 /* Number of pages released from the initial allocation. */
 unsigned long xen_released_pages;
 
-/* Buffer used to remap identity mapped pages */
-unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
+/*
+ * Buffer used to remap identity mapped pages. We only need the virtual space.
+ * The physical page behind this address is remapped as needed to different
+ * buffer pages.
+ */
+#define REMAP_SIZE	(P2M_PER_PAGE - 3)
+static struct {
+	unsigned long	next_area_mfn;
+	unsigned long	target_pfn;
+	unsigned long	size;
+	unsigned long	mfns[REMAP_SIZE];
+} xen_remap_buf __initdata __aligned(PAGE_SIZE);
+static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 /* 
  * The maximum amount of extra memory compared to the base size.  The
@@ -98,63 +110,6 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 	}
 }
 
-static unsigned long __init xen_do_chunk(unsigned long start,
-					 unsigned long end, bool release)
-{
-	struct xen_memory_reservation reservation = {
-		.address_bits = 0,
-		.extent_order = 0,
-		.domid        = DOMID_SELF
-	};
-	unsigned long len = 0;
-	unsigned long pfn;
-	int ret;
-
-	for (pfn = start; pfn < end; pfn++) {
-		unsigned long frame;
-		unsigned long mfn = pfn_to_mfn(pfn);
-
-		if (release) {
-			/* Make sure pfn exists to start with */
-			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
-				continue;
-			frame = mfn;
-		} else {
-			if (mfn != INVALID_P2M_ENTRY)
-				continue;
-			frame = pfn;
-		}
-		set_xen_guest_handle(reservation.extent_start, &frame);
-		reservation.nr_extents = 1;
-
-		ret = HYPERVISOR_memory_op(release ? XENMEM_decrease_reservation : XENMEM_populate_physmap,
-					   &reservation);
-		WARN(ret != 1, "Failed to %s pfn %lx err=%d\n",
-		     release ? "release" : "populate", pfn, ret);
-
-		if (ret == 1) {
-			if (!early_set_phys_to_machine(pfn, release ? INVALID_P2M_ENTRY : frame)) {
-				if (release)
-					break;
-				set_xen_guest_handle(reservation.extent_start, &frame);
-				reservation.nr_extents = 1;
-				ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
-							   &reservation);
-				break;
-			}
-			len++;
-		} else
-			break;
-	}
-	if (len)
-		printk(KERN_INFO "%s %lx-%lx pfn range: %lu pages %s\n",
-		       release ? "Freeing" : "Populating",
-		       start, end, len,
-		       release ? "freed" : "added");
-
-	return len;
-}
-
 /*
  * Finds the next RAM pfn available in the E820 map after min_pfn.
  * This function updates min_pfn with the pfn found and returns
@@ -198,26 +153,62 @@ static unsigned long __init xen_find_pfn_range(
 	return done;
 }
 
+static int __init xen_free_mfn(unsigned long mfn)
+{
+	struct xen_memory_reservation reservation = {
+		.address_bits = 0,
+		.extent_order = 0,
+		.domid        = DOMID_SELF
+	};
+
+	set_xen_guest_handle(reservation.extent_start, &mfn);
+	reservation.nr_extents = 1;
+
+	return HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation);
+}
+
 /*
- * This releases a chunk of memory and then does the identity map. It's used as
+ * This releases a chunk of memory and then does the identity map. It's used
  * as a fallback if the remapping fails.
  */
 static void __init xen_set_identity_and_release_chunk(unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long *identity,
 	unsigned long *released)
 {
+	unsigned long len = 0;
+	unsigned long pfn, end;
+	int ret;
+
 	WARN_ON(start_pfn > end_pfn);
 
+	end = min(end_pfn, nr_pages);
+	for (pfn = start_pfn; pfn < end; pfn++) {
+		unsigned long mfn = pfn_to_mfn(pfn);
+
+		/* Make sure pfn exists to start with */
+		if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+			continue;
+
+		ret = xen_free_mfn(mfn);
+		WARN(ret != 1, "Failed to release pfn %lx err=%d\n", pfn, ret);
+
+		if (ret == 1) {
+			if (!__set_phys_to_machine(pfn, INVALID_P2M_ENTRY))
+				break;
+			len++;
+		} else
+			break;
+	}
+
 	/* Need to release pages first */
-	*released += xen_do_chunk(start_pfn, min(end_pfn, nr_pages), true);
+	*released += len;
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
 /*
- * Helper function to update both the p2m and m2p tables.
+ * Helper function to update the p2m and m2p tables and kernel mapping.
  */
-static unsigned long __init xen_update_mem_tables(unsigned long pfn,
-						  unsigned long mfn)
+static void __init xen_update_mem_tables(unsigned long pfn, unsigned long mfn)
 {
 	struct mmu_update update = {
 		.ptr = ((unsigned long long)mfn << PAGE_SHIFT) | MMU_MACHPHYS_UPDATE,
@@ -225,161 +216,91 @@ static unsigned long __init xen_update_mem_tables(unsigned long pfn,
 	};
 
 	/* Update p2m */
-	if (!early_set_phys_to_machine(pfn, mfn)) {
+	if (!set_phys_to_machine(pfn, mfn)) {
 		WARN(1, "Failed to set p2m mapping for pfn=%ld mfn=%ld\n",
 		     pfn, mfn);
-		return false;
+		BUG();
 	}
 
 	/* Update m2p */
 	if (HYPERVISOR_mmu_update(&update, 1, NULL, DOMID_SELF) < 0) {
 		WARN(1, "Failed to set m2p mapping for mfn=%ld pfn=%ld\n",
 		     mfn, pfn);
-		return false;
+		BUG();
 	}
 
-	return true;
+	/* Update kernel mapping, but not for highmem. */
+	if ((pfn << PAGE_SHIFT) >= __pa(high_memory))
+		return;
+
+	if (HYPERVISOR_update_va_mapping((unsigned long)__va(pfn << PAGE_SHIFT),
+					 mfn_pte(mfn, PAGE_KERNEL), 0)) {
+		WARN(1, "Failed to update kernel mapping for mfn=%ld pfn=%ld\n",
+		      mfn, pfn);
+		BUG();
+	}
 }
 
 /*
  * This function updates the p2m and m2p tables with an identity map from
- * start_pfn to start_pfn+size and remaps the underlying RAM of the original
- * allocation at remap_pfn. It must do so carefully in P2M_PER_PAGE sized blocks
- * to not exhaust the reserved brk space. Doing it in properly aligned blocks
- * ensures we only allocate the minimum required leaf pages in the p2m table. It
- * copies the existing mfns from the p2m table under the 1:1 map, overwrites
- * them with the identity map and then updates the p2m and m2p tables with the
- * remapped memory.
+ * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the
+ * original allocation at remap_pfn. The information needed for remapping is
+ * saved in the memory itself to avoid the need for allocating buffers. The
+ * complete remap information is contained in a list of MFNs each containing
+ * up to REMAP_SIZE MFNs and the start target PFN for doing the remap.
+ * This enables us to preserve the original mfn sequence while doing the
+ * remapping at a time when the memory management is capable of allocating
+ * virtual and physical memory in arbitrary amounts, see 'xen_remap_memory' and
+ * its callers.
  */
-static unsigned long __init xen_do_set_identity_and_remap_chunk(
+static void __init xen_do_set_identity_and_remap_chunk(
         unsigned long start_pfn, unsigned long size, unsigned long remap_pfn)
 {
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn;
 	unsigned long ident_pfn_iter, remap_pfn_iter;
-	unsigned long ident_start_pfn_align, remap_start_pfn_align;
-	unsigned long ident_end_pfn_align, remap_end_pfn_align;
-	unsigned long ident_boundary_pfn, remap_boundary_pfn;
-	unsigned long ident_cnt = 0;
-	unsigned long remap_cnt = 0;
+	unsigned long ident_end_pfn = start_pfn + size;
 	unsigned long left = size;
-	unsigned long mod;
-	int i;
+	unsigned long ident_cnt = 0;
+	unsigned int i, chunk;
 
 	WARN_ON(size == 0);
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/*
-	 * Determine the proper alignment to remap memory in P2M_PER_PAGE sized
-	 * blocks. We need to keep track of both the existing pfn mapping and
-	 * the new pfn remapping.
-	 */
-	mod = start_pfn % P2M_PER_PAGE;
-	ident_start_pfn_align =
-		mod ? (start_pfn - mod + P2M_PER_PAGE) : start_pfn;
-	mod = remap_pfn % P2M_PER_PAGE;
-	remap_start_pfn_align =
-		mod ? (remap_pfn - mod + P2M_PER_PAGE) : remap_pfn;
-	mod = (start_pfn + size) % P2M_PER_PAGE;
-	ident_end_pfn_align = start_pfn + size - mod;
-	mod = (remap_pfn + size) % P2M_PER_PAGE;
-	remap_end_pfn_align = remap_pfn + size - mod;
-
-	/* Iterate over each p2m leaf node in each range */
-	for (ident_pfn_iter = ident_start_pfn_align, remap_pfn_iter = remap_start_pfn_align;
-	     ident_pfn_iter < ident_end_pfn_align && remap_pfn_iter < remap_end_pfn_align;
-	     ident_pfn_iter += P2M_PER_PAGE, remap_pfn_iter += P2M_PER_PAGE) {
-		/* Check we aren't past the end */
-		BUG_ON(ident_pfn_iter + P2M_PER_PAGE > start_pfn + size);
-		BUG_ON(remap_pfn_iter + P2M_PER_PAGE > remap_pfn + size);
-
-		/* Save p2m mappings */
-		for (i = 0; i < P2M_PER_PAGE; i++)
-			xen_remap_buf[i] = pfn_to_mfn(ident_pfn_iter + i);
-
-		/* Set identity map which will free a p2m leaf */
-		ident_cnt += set_phys_range_identity(ident_pfn_iter,
-			ident_pfn_iter + P2M_PER_PAGE);
-
-#ifdef DEBUG
-		/* Helps verify a p2m leaf has been freed */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned int pfn = ident_pfn_iter + i;
-			BUG_ON(pfn_to_mfn(pfn) != pfn);
-		}
-#endif
-		/* Now remap memory */
-		for (i = 0; i < P2M_PER_PAGE; i++) {
-			unsigned long mfn = xen_remap_buf[i];
-
-			/* This will use the p2m leaf freed above */
-			if (!xen_update_mem_tables(remap_pfn_iter + i, mfn)) {
-				WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-					remap_pfn_iter + i, mfn);
-				return 0;
-			}
-
-			remap_cnt++;
-		}
+	/* Don't use memory until remapped */
+	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
 
-		left -= P2M_PER_PAGE;
-	}
-
-	/* Max boundary space possible */
-	BUG_ON(left > (P2M_PER_PAGE - 1) * 2);
+	mfn_save = virt_to_mfn(buf);
 
-	/* Now handle the boundary conditions */
-	ident_boundary_pfn = start_pfn;
-	remap_boundary_pfn = remap_pfn;
-	for (i = 0; i < left; i++) {
-		unsigned long mfn;
+	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
+	     ident_pfn_iter < ident_end_pfn;
+	     ident_pfn_iter += REMAP_SIZE, remap_pfn_iter += REMAP_SIZE) {
+		chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE;
 
-		/* These two checks move from the start to end boundaries */
-		if (ident_boundary_pfn == ident_start_pfn_align)
-			ident_boundary_pfn = ident_pfn_iter;
-		if (remap_boundary_pfn == remap_start_pfn_align)
-			remap_boundary_pfn = remap_pfn_iter;
+		/* Map first pfn to xen_remap_buf */
+		mfn = pfn_to_mfn(ident_pfn_iter);
+		set_pte_mfn(buf, mfn, PAGE_KERNEL);
 
-		/* Check we aren't past the end */
-		BUG_ON(ident_boundary_pfn >= start_pfn + size);
-		BUG_ON(remap_boundary_pfn >= remap_pfn + size);
+		/* Save mapping information in page */
+		xen_remap_buf.next_area_mfn = xen_remap_mfn;
+		xen_remap_buf.target_pfn = remap_pfn_iter;
+		xen_remap_buf.size = chunk;
+		for (i = 0; i < chunk; i++)
+			xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i);
 
-		mfn = pfn_to_mfn(ident_boundary_pfn);
+		/* Put remap buf into list. */
+		xen_remap_mfn = mfn;
 
-		if (!xen_update_mem_tables(remap_boundary_pfn, mfn)) {
-			WARN(1, "Failed to update mem mapping for pfn=%ld mfn=%ld\n",
-				remap_pfn_iter + i, mfn);
-			return 0;
-		}
-		remap_cnt++;
-
-		ident_boundary_pfn++;
-		remap_boundary_pfn++;
-	}
+		/* Set identity map */
+		ident_cnt += set_phys_range_identity(ident_pfn_iter,
+			ident_pfn_iter + chunk);
 
-	/* Finish up the identity map */
-	if (ident_start_pfn_align >= ident_end_pfn_align) {
-		/*
-                 * In this case we have an identity range which does not span an
-                 * aligned block so everything needs to be identity mapped here.
-                 * If we didn't check this we might remap too many pages since
-                 * the align boundaries are not meaningful in this case.
-	         */
-		ident_cnt += set_phys_range_identity(start_pfn,
-			start_pfn + size);
-	} else {
-		/* Remapped above so check each end of the chunk */
-		if (start_pfn < ident_start_pfn_align)
-			ident_cnt += set_phys_range_identity(start_pfn,
-				ident_start_pfn_align);
-		if (start_pfn + size > ident_pfn_iter)
-			ident_cnt += set_phys_range_identity(ident_pfn_iter,
-				start_pfn + size);
+		left -= chunk;
 	}
 
-	BUG_ON(ident_cnt != size);
-	BUG_ON(remap_cnt != size);
-
-	return size;
+	/* Restore old xen_remap_buf mapping */
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 }
 
 /*
@@ -396,8 +317,7 @@ static unsigned long __init xen_do_set_identity_and_remap_chunk(
 static unsigned long __init xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
-	unsigned long *identity, unsigned long *remapped,
-	unsigned long *released)
+	unsigned long *identity, unsigned long *released)
 {
 	unsigned long pfn;
 	unsigned long i = 0;
@@ -431,19 +351,12 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 		if (size > remap_range_size)
 			size = remap_range_size;
 
-		if (!xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn)) {
-			WARN(1, "Failed to remap 1:1 memory cur_pfn=%ld size=%ld remap_pfn=%ld\n",
-				cur_pfn, size, remap_pfn);
-			xen_set_identity_and_release_chunk(cur_pfn,
-				cur_pfn + left, nr_pages, identity, released);
-			break;
-		}
+		xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn);
 
 		/* Update variables to reflect new mappings. */
 		i += size;
 		remap_pfn += size;
 		*identity += size;
-		*remapped += size;
 	}
 
 	/*
@@ -464,7 +377,6 @@ static unsigned long __init xen_set_identity_and_remap(
 {
 	phys_addr_t start = 0;
 	unsigned long identity = 0;
-	unsigned long remapped = 0;
 	unsigned long last_pfn = nr_pages;
 	const struct e820entry *entry;
 	unsigned long num_released = 0;
@@ -494,8 +406,7 @@ static unsigned long __init xen_set_identity_and_remap(
 				last_pfn = xen_set_identity_and_remap_chunk(
 						list, map_size, start_pfn,
 						end_pfn, nr_pages, last_pfn,
-						&identity, &remapped,
-						&num_released);
+						&identity, &num_released);
 			start = end;
 		}
 	}
@@ -503,12 +414,65 @@ static unsigned long __init xen_set_identity_and_remap(
 	*released = num_released;
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
-	pr_info("Remapped %ld page(s), last_pfn=%ld\n", remapped,
-		last_pfn);
 	pr_info("Released %ld page(s)\n", num_released);
 
 	return last_pfn;
 }
+
+/*
+ * Remap the memory prepared in xen_do_set_identity_and_remap_chunk().
+ * The remap information (which mfn remap to which pfn) is contained in the
+ * to be remapped memory itself in a linked list anchored at xen_remap_mfn.
+ * This scheme allows to remap the different chunks in arbitrary order while
+ * the resulting mapping will be independant from the order.
+ */
+void __init xen_remap_memory(void)
+{
+	unsigned long buf = (unsigned long)&xen_remap_buf;
+	unsigned long mfn_save, mfn, pfn;
+	unsigned long remapped = 0;
+	unsigned int i;
+	unsigned long pfn_s = ~0UL;
+	unsigned long len = 0;
+
+	mfn_save = virt_to_mfn(buf);
+
+	while (xen_remap_mfn != INVALID_P2M_ENTRY) {
+		/* Map the remap information */
+		set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
+
+		BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
+
+		pfn = xen_remap_buf.target_pfn;
+		for (i = 0; i < xen_remap_buf.size; i++) {
+			mfn = xen_remap_buf.mfns[i];
+			xen_update_mem_tables(pfn, mfn);
+			remapped++;
+			pfn++;
+		}
+		if (pfn_s == ~0UL || pfn == pfn_s) {
+			pfn_s = xen_remap_buf.target_pfn;
+			len += xen_remap_buf.size;
+		} else if (pfn_s + len == xen_remap_buf.target_pfn) {
+			len += xen_remap_buf.size;
+		} else {
+			memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+			pfn_s = xen_remap_buf.target_pfn;
+			len = xen_remap_buf.size;
+		}
+
+		mfn = xen_remap_mfn;
+		xen_remap_mfn = xen_remap_buf.next_area_mfn;
+	}
+
+	if (pfn_s != ~0UL && len)
+		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+
+	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
+
+	pr_info("Remapped %ld page(s)\n", remapped);
+}
+
 static unsigned long __init xen_get_max_pages(void)
 {
 	unsigned long max_pages = MAX_DOMAIN_PAGES;
@@ -616,7 +580,8 @@ char * __init xen_memory_setup(void)
 		extra_pages += max_pages - max_pfn;
 
 	/*
-	 * Set identity map on non-RAM pages and remap the underlying RAM.
+	 * Set identity map on non-RAM pages and prepare remapping the
+	 * underlying RAM.
 	 */
 	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
 					      &xen_released_pages);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 28c7e0b..5b72a06 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,6 +35,7 @@ void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
 void __init xen_arch_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBk-0006WN-0k; Fri, 28 Nov 2014 10:54:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBj-0006VJ-2U
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:11 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	69/48-25714-25458745; Fri, 28 Nov 2014 10:54:10 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417172048!13815357!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22699 invoked from network); 28 Nov 2014 10:54:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:08 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0E7E2ADC6;
	Fri, 28 Nov 2014 10:54:07 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:58 +0100
Message-Id: <1417172039-8627-10-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 09/10] xen: switch to linear virtual mapped
	sparse p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At start of the day the Xen hypervisor presents a contiguous mfn list
to a pv-domain. In order to support sparse memory this mfn list is
accessed via a three level p2m tree built early in the boot process.
Whenever the system needs the mfn associated with a pfn this tree is
used to find the mfn.

Instead of using a software walked tree for accessing a specific mfn
list entry this patch is creating a virtual address area for the
entire possible mfn list including memory holes. The holes are
covered by mapping a pre-defined  page consisting only of "invalid
mfn" entries. Access to a mfn entry is possible by just using the
virtual base address of the mfn list and the pfn as index into that
list. This speeds up the (hot) path of determining the mfn of a
pfn.

Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
showed following improvements:

Elapsed time: 32:50 ->  32:35
System:       18:07 ->  17:47
User:        104:00 -> 103:30

Tested with following configurations:
- 64 bit dom0, 8GB RAM
- 64 bit dom0, 128 GB RAM, PCI-area above 4 GB
- 32 bit domU, 512 MB, 8 GB, 43 GB (more wouldn't work even without
                                    the patch)
- 32 bit domU, ballooning up and down
- 32 bit domU, save and restore
- 32 bit domU with PCI passthrough
- 64 bit domU, 8 GB, 2049 MB, 5000 MB
- 64 bit domU, ballooning up and down
- 64 bit domU, save and restore
- 64 bit domU with PCI passthrough

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |  20 +-
 arch/x86/xen/mmu.c              |  34 +-
 arch/x86/xen/p2m.c              | 735 +++++++++++++++++-----------------------
 arch/x86/xen/xen-ops.h          |   2 +-
 4 files changed, 347 insertions(+), 444 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 410a6ec..f5d5de4 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -65,13 +65,25 @@ extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
  *   bits (identity or foreign) are set.
  * - __pfn_to_mfn() returns the found entry of the p2m table. A possibly set
  *   identity or foreign indicator will be still set. __pfn_to_mfn() is
- *   encapsulating get_phys_to_machine().
- * - get_phys_to_machine() is to be called by __pfn_to_mfn() only to allow
- *   for future optimizations.
+ *   encapsulating get_phys_to_machine() which is called in special cases only.
+ * - get_phys_to_machine() is to be called by __pfn_to_mfn() only in special
+ *   cases needing an extended handling.
  */
 static inline unsigned long __pfn_to_mfn(unsigned long pfn)
 {
-	return get_phys_to_machine(pfn);
+	unsigned long mfn;
+
+	if (pfn < xen_p2m_size)
+		mfn = xen_p2m_addr[pfn];
+	else if (unlikely(pfn < xen_max_p2m_pfn))
+		return get_phys_to_machine(pfn);
+	else
+		return IDENTITY_FRAME(pfn);
+
+	if (unlikely(mfn == INVALID_P2M_ENTRY))
+		return get_phys_to_machine(pfn);
+
+	return mfn;
 }
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 3e3f8f8..6ab6150 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1158,20 +1158,16 @@ static void __init xen_cleanhighmap(unsigned long vaddr,
 	 * instead of somewhere later and be confusing. */
 	xen_mc_flush();
 }
-static void __init xen_pagetable_p2m_copy(void)
+
+static void __init xen_pagetable_p2m_free(void)
 {
 	unsigned long size;
 	unsigned long addr;
-	unsigned long new_mfn_list;
-
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return;
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 
-	new_mfn_list = xen_revector_p2m_tree();
 	/* No memory or already called. */
-	if (!new_mfn_list || new_mfn_list == xen_start_info->mfn_list)
+	if ((unsigned long)xen_p2m_addr == xen_start_info->mfn_list)
 		return;
 
 	/* using __ka address and sticking INVALID_P2M_ENTRY! */
@@ -1189,8 +1185,6 @@ static void __init xen_pagetable_p2m_copy(void)
 
 	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
 	memblock_free(__pa(xen_start_info->mfn_list), size);
-	/* And revector! Bye bye old array */
-	xen_start_info->mfn_list = new_mfn_list;
 
 	/* At this stage, cleanup_highmap has already cleaned __ka space
 	 * from _brk_limit way up to the max_pfn_mapped (which is the end of
@@ -1214,14 +1208,26 @@ static void __init xen_pagetable_p2m_copy(void)
 }
 #endif
 
-static void __init xen_pagetable_init(void)
+static void __init xen_pagetable_p2m_setup(void)
 {
-	paging_init();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	xen_vmalloc_p2m_tree();
+
 #ifdef CONFIG_X86_64
-	xen_pagetable_p2m_copy();
-#else
-	xen_revector_p2m_tree();
+	xen_pagetable_p2m_free();
 #endif
+	/* And revector! Bye bye old array */
+	xen_start_info->mfn_list = (unsigned long)xen_p2m_addr;
+}
+
+static void __init xen_pagetable_init(void)
+{
+	paging_init();
+
+	xen_pagetable_p2m_setup();
+
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8c3d8fb..7d84473 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -3,21 +3,22 @@
  * guests themselves, but it must also access and update the p2m array
  * during suspend/resume when all the pages are reallocated.
  *
- * The p2m table is logically a flat array, but we implement it as a
- * three-level tree to allow the address space to be sparse.
+ * The logical flat p2m table is mapped to a linear kernel memory area.
+ * For accesses by Xen a three-level tree linked via mfns only is set up to
+ * allow the address space to be sparse.
  *
- *                               Xen
- *                                |
- *     p2m_top              p2m_top_mfn
- *       /  \                   /   \
- * p2m_mid p2m_mid	p2m_mid_mfn p2m_mid_mfn
- *    / \      / \         /           /
- *  p2m p2m p2m p2m p2m p2m p2m ...
+ *               Xen
+ *                |
+ *          p2m_top_mfn
+ *              /   \
+ * p2m_mid_mfn p2m_mid_mfn
+ *         /           /
+ *  p2m p2m p2m ...
  *
  * The p2m_mid_mfn pages are mapped by p2m_top_mfn_p.
  *
- * The p2m_top and p2m_top_mfn levels are limited to 1 page, so the
- * maximum representable pseudo-physical address space is:
+ * The p2m_top_mfn level is limited to 1 page, so the maximum representable
+ * pseudo-physical address space is:
  *  P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * P2M_PER_PAGE pages
  *
  * P2M_PER_PAGE depends on the architecture, as a mfn is always
@@ -30,6 +31,9 @@
  * leaf entries, or for the top  root, or middle one, for which there is a void
  * entry, we assume it is  "missing". So (for example)
  *  pfn_to_mfn(0x90909090)=INVALID_P2M_ENTRY.
+ * We have a dedicated page p2m_missing with all entries being
+ * INVALID_P2M_ENTRY. This page may be referenced multiple times in the p2m
+ * list/tree in case there are multiple areas with P2M_PER_PAGE invalid pfns.
  *
  * We also have the possibility of setting 1-1 mappings on certain regions, so
  * that:
@@ -39,122 +43,20 @@
  * PCI BARs, or ACPI spaces), we can create mappings easily because we
  * get the PFN value to match the MFN.
  *
- * For this to work efficiently we have one new page p2m_identity and
- * allocate (via reserved_brk) any other pages we need to cover the sides
- * (1GB or 4MB boundary violations). All entries in p2m_identity are set to
- * INVALID_P2M_ENTRY type (Xen toolstack only recognizes that and MFNs,
- * no other fancy value).
+ * For this to work efficiently we have one new page p2m_identity. All entries
+ * in p2m_identity are set to INVALID_P2M_ENTRY type (Xen toolstack only
+ * recognizes that and MFNs, no other fancy value).
  *
  * On lookup we spot that the entry points to p2m_identity and return the
  * identity value instead of dereferencing and returning INVALID_P2M_ENTRY.
  * If the entry points to an allocated page, we just proceed as before and
- * return the PFN.  If the PFN has IDENTITY_FRAME_BIT set we unmask that in
+ * return the PFN. If the PFN has IDENTITY_FRAME_BIT set we unmask that in
  * appropriate functions (pfn_to_mfn).
  *
  * The reason for having the IDENTITY_FRAME_BIT instead of just returning the
  * PFN is that we could find ourselves where pfn_to_mfn(pfn)==pfn for a
  * non-identity pfn. To protect ourselves against we elect to set (and get) the
  * IDENTITY_FRAME_BIT on all identity mapped PFNs.
- *
- * This simplistic diagram is used to explain the more subtle piece of code.
- * There is also a digram of the P2M at the end that can help.
- * Imagine your E820 looking as so:
- *
- *                    1GB                                           2GB    4GB
- * /-------------------+---------\/----\         /----------\    /---+-----\
- * | System RAM        | Sys RAM ||ACPI|         | reserved |    | Sys RAM |
- * \-------------------+---------/\----/         \----------/    \---+-----/
- *                               ^- 1029MB                       ^- 2001MB
- *
- * [1029MB = 263424 (0x40500), 2001MB = 512256 (0x7D100),
- *  2048MB = 524288 (0x80000)]
- *
- * And dom0_mem=max:3GB,1GB is passed in to the guest, meaning memory past 1GB
- * is actually not present (would have to kick the balloon driver to put it in).
- *
- * When we are told to set the PFNs for identity mapping (see patch: "xen/setup:
- * Set identity mapping for non-RAM E820 and E820 gaps.") we pass in the start
- * of the PFN and the end PFN (263424 and 512256 respectively). The first step
- * is to reserve_brk a top leaf page if the p2m[1] is missing. The top leaf page
- * covers 512^2 of page estate (1GB) and in case the start or end PFN is not
- * aligned on 512^2*PAGE_SIZE (1GB) we reserve_brk new middle and leaf pages as
- * required to split any existing p2m_mid_missing middle pages.
- *
- * With the E820 example above, 263424 is not 1GB aligned so we allocate a
- * reserve_brk page which will cover the PFNs estate from 0x40000 to 0x80000.
- * Each entry in the allocate page is "missing" (points to p2m_missing).
- *
- * Next stage is to determine if we need to do a more granular boundary check
- * on the 4MB (or 2MB depending on architecture) off the start and end pfn's.
- * We check if the start pfn and end pfn violate that boundary check, and if
- * so reserve_brk a (p2m[x][y]) leaf page. This way we have a much finer
- * granularity of setting which PFNs are missing and which ones are identity.
- * In our example 263424 and 512256 both fail the check so we reserve_brk two
- * pages. Populate them with INVALID_P2M_ENTRY (so they both have "missing"
- * values) and assign them to p2m[1][2] and p2m[1][488] respectively.
- *
- * At this point we would at minimum reserve_brk one page, but could be up to
- * three. Each call to set_phys_range_identity has at maximum a three page
- * cost. If we were to query the P2M at this stage, all those entries from
- * start PFN through end PFN (so 1029MB -> 2001MB) would return
- * INVALID_P2M_ENTRY ("missing").
- *
- * The next step is to walk from the start pfn to the end pfn setting
- * the IDENTITY_FRAME_BIT on each PFN. This is done in set_phys_range_identity.
- * If we find that the middle entry is pointing to p2m_missing we can swap it
- * over to p2m_identity - this way covering 4MB (or 2MB) PFN space (and
- * similarly swapping p2m_mid_missing for p2m_mid_identity for larger regions).
- * At this point we do not need to worry about boundary aligment (so no need to
- * reserve_brk a middle page, figure out which PFNs are "missing" and which
- * ones are identity), as that has been done earlier.  If we find that the
- * middle leaf is not occupied by p2m_identity or p2m_missing, we dereference
- * that page (which covers 512 PFNs) and set the appropriate PFN with
- * IDENTITY_FRAME_BIT. In our example 263424 and 512256 end up there, and we
- * set from p2m[1][2][256->511] and p2m[1][488][0->256] with
- * IDENTITY_FRAME_BIT set.
- *
- * All other regions that are void (or not filled) either point to p2m_missing
- * (considered missing) or have the default value of INVALID_P2M_ENTRY (also
- * considered missing). In our case, p2m[1][2][0->255] and p2m[1][488][257->511]
- * contain the INVALID_P2M_ENTRY value and are considered "missing."
- *
- * Finally, the region beyond the end of of the E820 (4 GB in this example)
- * is set to be identity (in case there are MMIO regions placed here).
- *
- * This is what the p2m ends up looking (for the E820 above) with this
- * fabulous drawing:
- *
- *    p2m         /--------------\
- *  /-----\       | &mfn_list[0],|                           /-----------------\
- *  |  0  |------>| &mfn_list[1],|    /---------------\      | ~0, ~0, ..      |
- *  |-----|       |  ..., ~0, ~0 |    | ~0, ~0, [x]---+----->| IDENTITY [@256] |
- *  |  1  |---\   \--------------/    | [p2m_identity]+\     | IDENTITY [@257] |
- *  |-----|    \                      | [p2m_identity]+\\    | ....            |
- *  |  2  |--\  \-------------------->|  ...          | \\   \----------------/
- *  |-----|   \                       \---------------/  \\
- *  |  3  |-\  \                                          \\  p2m_identity [1]
- *  |-----|  \  \-------------------->/---------------\   /-----------------\
- *  | ..  |\  |                       | [p2m_identity]+-->| ~0, ~0, ~0, ... |
- *  \-----/ | |                       | [p2m_identity]+-->| ..., ~0         |
- *          | |                       | ....          |   \-----------------/
- *          | |                       +-[x], ~0, ~0.. +\
- *          | |                       \---------------/ \
- *          | |                                          \-> /---------------\
- *          | V  p2m_mid_missing       p2m_missing           | IDENTITY[@0]  |
- *          | /-----------------\     /------------\         | IDENTITY[@256]|
- *          | | [p2m_missing]   +---->| ~0, ~0, ...|         | ~0, ~0, ....  |
- *          | | [p2m_missing]   +---->| ..., ~0    |         \---------------/
- *          | | ...             |     \------------/
- *          | \-----------------/
- *          |
- *          |     p2m_mid_identity
- *          |   /-----------------\
- *          \-->| [p2m_identity]  +---->[1]
- *              | [p2m_identity]  +---->[1]
- *              | ...             |
- *              \-----------------/
- *
- * where ~0 is INVALID_P2M_ENTRY. IDENTITY is (PFN | IDENTITY_BIT)
  */
 
 #include <linux/init.h>
@@ -179,6 +81,8 @@
 #include "multicalls.h"
 #include "xen-ops.h"
 
+#define PMDS_PER_MID_PAGE	(P2M_MID_PER_PAGE / PTRS_PER_PTE)
+
 static void __init m2p_override_init(void);
 
 unsigned long *xen_p2m_addr __read_mostly;
@@ -188,22 +92,15 @@ EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
 EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
+static DEFINE_SPINLOCK(p2m_update_lock);
+
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
 static unsigned long **p2m_top_mfn_p;
-
-/* Placeholders for holes in the address space */
-static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long **, p2m_top, P2M_TOP_PER_PAGE);
-
-static RESERVE_BRK_ARRAY(unsigned long, p2m_identity, P2M_PER_PAGE);
-static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
-
-RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
-
-static int use_brk = 1;
+static unsigned long *p2m_missing;
+static unsigned long *p2m_identity;
+static pte_t *p2m_missing_pte;
+static pte_t *p2m_identity_pte;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
@@ -221,14 +118,6 @@ static inline unsigned p2m_index(unsigned long pfn)
 	return pfn % P2M_PER_PAGE;
 }
 
-static void p2m_top_init(unsigned long ***top)
-{
-	unsigned i;
-
-	for (i = 0; i < P2M_TOP_PER_PAGE; i++)
-		top[i] = p2m_mid_missing;
-}
-
 static void p2m_top_mfn_init(unsigned long *top)
 {
 	unsigned i;
@@ -245,35 +134,32 @@ static void p2m_top_mfn_p_init(unsigned long **top)
 		top[i] = p2m_mid_missing_mfn;
 }
 
-static void p2m_mid_init(unsigned long **mid, unsigned long *leaf)
+static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
 {
 	unsigned i;
 
 	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = leaf;
+		mid[i] = virt_to_mfn(leaf);
 }
 
-static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
+static void p2m_init(unsigned long *p2m)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		mid[i] = virt_to_mfn(leaf);
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = INVALID_P2M_ENTRY;
 }
 
-static void p2m_init(unsigned long *p2m)
+static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 {
 	unsigned i;
 
-	for (i = 0; i < P2M_MID_PER_PAGE; i++)
-		p2m[i] = INVALID_P2M_ENTRY;
+	for (i = 0; i < P2M_PER_PAGE; i++)
+		p2m[i] = IDENTITY_FRAME(pfn + i);
 }
 
 static void * __ref alloc_p2m_page(void)
 {
-	if (unlikely(use_brk))
-		return extend_brk(PAGE_SIZE, PAGE_SIZE);
-
 	if (unlikely(!slab_is_available()))
 		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
 
@@ -299,7 +185,10 @@ static void free_p2m_page(void *p)
  */
 void __ref xen_build_mfn_list_list(void)
 {
-	unsigned long pfn;
+	unsigned long pfn, mfn;
+	pte_t *ptep;
+	unsigned int level, topidx, mididx;
+	unsigned long *mid_mfn_p;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
@@ -319,20 +208,23 @@ void __ref xen_build_mfn_list_list(void)
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 	}
 
-	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned long **mid;
-		unsigned long *mid_mfn_p;
+	for (pfn = 0; pfn < xen_max_p2m_pfn && pfn < MAX_P2M_PFN;
+	     pfn += P2M_PER_PAGE) {
+		topidx = p2m_top_index(pfn);
+		mididx = p2m_mid_index(pfn);
 
-		mid = p2m_top[topidx];
 		mid_mfn_p = p2m_top_mfn_p[topidx];
+		ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn),
+				      &level);
+		BUG_ON(!ptep || level != PG_LEVEL_4K);
+		mfn = pte_mfn(*ptep);
+		ptep = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
 		/* Don't bother allocating any mfn mid levels if
 		 * they're just missing, just update the stored mfn,
 		 * since all could have changed over a migrate.
 		 */
-		if (mid == p2m_mid_missing) {
+		if (ptep == p2m_missing_pte || ptep == p2m_identity_pte) {
 			BUG_ON(mididx);
 			BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
 			p2m_top_mfn[topidx] = virt_to_mfn(p2m_mid_missing_mfn);
@@ -341,11 +233,6 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		if (mid_mfn_p == p2m_mid_missing_mfn) {
-			/*
-			 * XXX boot-time only!  We should never find
-			 * missing parts of the mfn tree after
-			 * runtime.
-			 */
 			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
@@ -353,7 +240,7 @@ void __ref xen_build_mfn_list_list(void)
 		}
 
 		p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
-		mid_mfn_p[mididx] = virt_to_mfn(mid[mididx]);
+		mid_mfn_p[mididx] = mfn;
 	}
 }
 
@@ -372,154 +259,153 @@ void xen_setup_mfn_list_list(void)
 /* Set up p2m_top to point to the domain-builder provided p2m pages */
 void __init xen_build_dynamic_phys_to_machine(void)
 {
-	unsigned long *mfn_list;
-	unsigned long max_pfn;
 	unsigned long pfn;
 
 	 if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
 	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
-	mfn_list = (unsigned long *)xen_start_info->mfn_list;
-	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
-	xen_max_p2m_pfn = max_pfn;
-	xen_p2m_size = max_pfn;
+	xen_p2m_size = ALIGN(xen_start_info->nr_pages, P2M_PER_PAGE);
 
-	p2m_missing = alloc_p2m_page();
-	p2m_init(p2m_missing);
-	p2m_identity = alloc_p2m_page();
-	p2m_init(p2m_identity);
+	for (pfn = xen_start_info->nr_pages; pfn < xen_p2m_size; pfn++)
+		xen_p2m_addr[pfn] = INVALID_P2M_ENTRY;
 
-	p2m_mid_missing = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = alloc_p2m_page();
-	p2m_mid_init(p2m_mid_identity, p2m_identity);
+	xen_max_p2m_pfn = xen_p2m_size;
+}
 
-	p2m_top = alloc_p2m_page();
-	p2m_top_init(p2m_top);
+#define P2M_TYPE_IDENTITY	0
+#define P2M_TYPE_MISSING	1
+#define P2M_TYPE_PFN		2
+#define P2M_TYPE_UNKNOWN	3
 
-	/*
-	 * The domain builder gives us a pre-constructed p2m array in
-	 * mfn_list for all the pages initially given to us, so we just
-	 * need to graft that into our tree structure.
-	 */
-	for (pfn = 0; pfn < max_pfn; pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
+static int xen_p2m_elem_type(unsigned long pfn)
+{
+	unsigned long mfn;
 
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = alloc_p2m_page();
-			p2m_mid_init(mid, p2m_missing);
+	if (pfn >= xen_p2m_size)
+		return P2M_TYPE_IDENTITY;
 
-			p2m_top[topidx] = mid;
-		}
+	mfn = xen_p2m_addr[pfn];
 
-		/*
-		 * As long as the mfn_list has enough entries to completely
-		 * fill a p2m page, pointing into the array is ok. But if
-		 * not the entries beyond the last pfn will be undefined.
-		 */
-		if (unlikely(pfn + P2M_PER_PAGE > max_pfn)) {
-			unsigned long p2midx;
+	if (mfn == INVALID_P2M_ENTRY)
+		return P2M_TYPE_MISSING;
 
-			p2midx = max_pfn % P2M_PER_PAGE;
-			for ( ; p2midx < P2M_PER_PAGE; p2midx++)
-				mfn_list[pfn + p2midx] = INVALID_P2M_ENTRY;
-		}
-		p2m_top[topidx][mididx] = &mfn_list[pfn];
-	}
+	if (mfn & IDENTITY_FRAME_BIT)
+		return P2M_TYPE_IDENTITY;
+
+	return P2M_TYPE_PFN;
 }
-#ifdef CONFIG_X86_64
-unsigned long __init xen_revector_p2m_tree(void)
+
+static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 {
-	unsigned long va_start;
-	unsigned long va_end;
+	unsigned int i, chunk;
 	unsigned long pfn;
-	unsigned long pfn_free = 0;
-	unsigned long *mfn_list = NULL;
-	unsigned long size;
-
-	use_brk = 0;
-	va_start = xen_start_info->mfn_list;
-	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
-	 * so make sure it is rounded up to that */
-	size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
-	va_end = va_start + size;
-
-	/* If we were revectored already, don't do it again. */
-	if (va_start <= __START_KERNEL_map && va_start >= __PAGE_OFFSET)
-		return 0;
-
-	mfn_list = alloc_bootmem_align(size, PAGE_SIZE);
-	if (!mfn_list) {
-		pr_warn("Could not allocate space for a new P2M tree!\n");
-		return xen_start_info->mfn_list;
-	}
-	/* Fill it out with INVALID_P2M_ENTRY value */
-	memset(mfn_list, 0xFF, size);
+	unsigned long *mfns;
+	pte_t *ptep;
+	pmd_t *pmdp;
+	int type;
 
-	for (pfn = 0; pfn < ALIGN(MAX_DOMAIN_PAGES, P2M_PER_PAGE); pfn += P2M_PER_PAGE) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx;
-		unsigned long *mid_p;
-
-		if (!p2m_top[topidx])
-			continue;
+	p2m_missing = alloc_p2m_page();
+	p2m_init(p2m_missing);
+	p2m_identity = alloc_p2m_page();
+	p2m_init(p2m_identity);
 
-		if (p2m_top[topidx] == p2m_mid_missing)
-			continue;
+	p2m_missing_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_missing_pte) >> PAGE_SHIFT);
+	p2m_identity_pte = alloc_p2m_page();
+	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
+	for (i = 0; i < PTRS_PER_PTE; i++) {
+		set_pte(p2m_missing_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
+		set_pte(p2m_identity_pte + i,
+			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
+	}
 
-		mididx = p2m_mid_index(pfn);
-		mid_p = p2m_top[topidx][mididx];
-		if (!mid_p)
-			continue;
-		if ((mid_p == p2m_missing) || (mid_p == p2m_identity))
+	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
+		/*
+		 * Try to map missing/identity PMDs or p2m-pages if possible.
+		 * We have to respect the structure of the mfn_list_list
+		 * which will be built just afterwards.
+		 * Chunk size to test is one p2m page if we are in the middle
+		 * of a mfn_list_list mid page and the complete mid page area
+		 * if we are at index 0 of the mid page. Please note that a
+		 * mid page might cover more than one PMD, e.g. on 32 bit PAE
+		 * kernels.
+		 */
+		chunk = (pfn & (P2M_PER_PAGE * P2M_MID_PER_PAGE - 1)) ?
+			P2M_PER_PAGE : P2M_PER_PAGE * P2M_MID_PER_PAGE;
+
+		type = xen_p2m_elem_type(pfn);
+		i = 0;
+		if (type != P2M_TYPE_PFN)
+			for (i = 1; i < chunk; i++)
+				if (xen_p2m_elem_type(pfn + i) != type)
+					break;
+		if (i < chunk)
+			/* Reset to minimal chunk size. */
+			chunk = P2M_PER_PAGE;
+
+		if (type == P2M_TYPE_PFN || i < chunk) {
+			/* Use initial p2m page contents. */
+#ifdef CONFIG_X86_64
+			mfns = alloc_p2m_page();
+			copy_page(mfns, xen_p2m_addr + pfn);
+#else
+			mfns = xen_p2m_addr + pfn;
+#endif
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		if ((unsigned long)mid_p == INVALID_P2M_ENTRY)
+		if (chunk == P2M_PER_PAGE) {
+			/* Map complete missing or identity p2m-page. */
+			mfns = (type == P2M_TYPE_MISSING) ?
+				p2m_missing : p2m_identity;
+			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
 			continue;
+		}
 
-		/* The old va. Rebase it on mfn_list */
-		if (mid_p >= (unsigned long *)va_start && mid_p <= (unsigned long *)va_end) {
-			unsigned long *new;
+		/* Complete missing or identity PMD(s) can be mapped. */
+		ptep = (type == P2M_TYPE_MISSING) ?
+			p2m_missing_pte : p2m_identity_pte;
+		for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+			pmdp = populate_extra_pmd(
+				(unsigned long)(p2m + pfn + i * PTRS_PER_PTE));
+			set_pmd(pmdp, __pmd(__pa(ptep) | _KERNPG_TABLE));
+		}
+	}
+}
 
-			if (pfn_free  > (size / sizeof(unsigned long))) {
-				WARN(1, "Only allocated for %ld pages, but we want %ld!\n",
-				     size / sizeof(unsigned long), pfn_free);
-				return 0;
-			}
-			new = &mfn_list[pfn_free];
+void __init xen_vmalloc_p2m_tree(void)
+{
+	static struct vm_struct vm;
 
-			copy_page(new, mid_p);
-			p2m_top[topidx][mididx] = &mfn_list[pfn_free];
+	vm.flags = VM_ALLOC;
+	vm.size = ALIGN(sizeof(unsigned long) * xen_max_p2m_pfn,
+			PMD_SIZE * PMDS_PER_MID_PAGE);
+	vm_area_register_early(&vm, PMD_SIZE * PMDS_PER_MID_PAGE);
+	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);
 
-			pfn_free += P2M_PER_PAGE;
+	xen_max_p2m_pfn = vm.size / sizeof(unsigned long);
 
-		}
-		/* This should be the leafs allocated for identity from _brk. */
-	}
+	xen_rebuild_p2m_list(vm.addr);
 
+	xen_p2m_addr = vm.addr;
 	xen_p2m_size = xen_max_p2m_pfn;
-	xen_p2m_addr = mfn_list;
 
 	xen_inv_extra_mem();
 
 	m2p_override_init();
-	return (unsigned long)mfn_list;
 }
-#else
-unsigned long __init xen_revector_p2m_tree(void)
-{
-	use_brk = 0;
-	xen_p2m_size = xen_max_p2m_pfn;
-	xen_inv_extra_mem();
-	m2p_override_init();
-	return 0;
-}
-#endif
+
 unsigned long get_phys_to_machine(unsigned long pfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	if (unlikely(pfn >= xen_p2m_size)) {
 		if (pfn < xen_max_p2m_pfn)
@@ -528,23 +414,83 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 		return IDENTITY_FRAME(pfn);
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
 	/*
 	 * The INVALID_P2M_ENTRY is filled in both p2m_*identity
 	 * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
 	 * would be wrong.
 	 */
-	if (p2m_top[topidx][mididx] == p2m_identity)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
 		return IDENTITY_FRAME(pfn);
 
-	return p2m_top[topidx][mididx][idx];
+	return xen_p2m_addr[pfn];
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
 /*
+ * Allocate new pmd(s). It is checked whether the old pmd is still in place.
+ * If not, nothing is changed. This is okay as the only reason for allocating
+ * a new pmd is to replace p2m_missing_pte or p2m_identity_pte by a individual
+ * pmd. In case of PAE/x86-32 there are multiple pmds to allocate!
+ */
+static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t *ptep, pte_t *pte_pg)
+{
+	pte_t *ptechk;
+	pte_t *pteret = ptep;
+	pte_t *pte_newpg[PMDS_PER_MID_PAGE];
+	pmd_t *pmdp;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long vaddr;
+	int i;
+
+	/* Do all allocations first to bail out in error case. */
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		pte_newpg[i] = alloc_p2m_page();
+		if (!pte_newpg[i]) {
+			for (i--; i >= 0; i--)
+				free_p2m_page(pte_newpg[i]);
+
+			return NULL;
+		}
+	}
+
+	vaddr = addr & ~(PMD_SIZE * PMDS_PER_MID_PAGE - 1);
+
+	for (i = 0; i < PMDS_PER_MID_PAGE; i++) {
+		copy_page(pte_newpg[i], pte_pg);
+		paravirt_alloc_pte(&init_mm, __pa(pte_newpg[i]) >> PAGE_SHIFT);
+
+		pmdp = lookup_pmd_address(vaddr);
+		BUG_ON(!pmdp);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		ptechk = lookup_address(vaddr, &level);
+		if (ptechk == pte_pg) {
+			set_pmd(pmdp,
+				__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+			if (vaddr == (addr & ~(PMD_SIZE - 1)))
+				pteret = pte_offset_kernel(pmdp, addr);
+			pte_newpg[i] = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
+
+		if (pte_newpg[i]) {
+			paravirt_release_pte(__pa(pte_newpg[i]) >> PAGE_SHIFT);
+			free_p2m_page(pte_newpg[i]);
+		}
+
+		vaddr += PMD_SIZE;
+	}
+
+	return pteret;
+}
+
+/*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
  * parallel mfn tree is kept in sync.  We may race with other cpus, so
@@ -554,58 +500,62 @@ EXPORT_SYMBOL_GPL(get_phys_to_machine);
 static bool alloc_p2m(unsigned long pfn)
 {
 	unsigned topidx, mididx;
-	unsigned long ***top_p, **mid;
 	unsigned long *top_mfn_p, *mid_mfn;
-	unsigned long *p2m_orig;
+	pte_t *ptep, *pte_pg;
+	unsigned int level;
+	unsigned long flags;
+	unsigned long addr = (unsigned long)(xen_p2m_addr + pfn);
+	unsigned long p2m_pfn;
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
 
-	top_p = &p2m_top[topidx];
-	mid = ACCESS_ONCE(*top_p);
+	ptep = lookup_address(addr, &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
+	pte_pg = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
 
-	if (mid == p2m_mid_missing) {
-		/* Mid level is missing, allocate a new one */
-		mid = alloc_p2m_page();
-		if (!mid)
+	if (pte_pg == p2m_missing_pte || pte_pg == p2m_identity_pte) {
+		/* PMD level is missing, allocate a new one */
+		ptep = alloc_p2m_pmd(addr, ptep, pte_pg);
+		if (!ptep)
 			return false;
-
-		p2m_mid_init(mid, p2m_missing);
-
-		if (cmpxchg(top_p, p2m_mid_missing, mid) != p2m_mid_missing)
-			free_p2m_page(mid);
 	}
 
-	top_mfn_p = &p2m_top_mfn[topidx];
-	mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
+	if (p2m_top_mfn) {
+		top_mfn_p = &p2m_top_mfn[topidx];
+		mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
 
-	BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
+		BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
 
-	if (mid_mfn == p2m_mid_missing_mfn) {
-		/* Separately check the mid mfn level */
-		unsigned long missing_mfn;
-		unsigned long mid_mfn_mfn;
-		unsigned long old_mfn;
+		if (mid_mfn == p2m_mid_missing_mfn) {
+			/* Separately check the mid mfn level */
+			unsigned long missing_mfn;
+			unsigned long mid_mfn_mfn;
+			unsigned long old_mfn;
 
-		mid_mfn = alloc_p2m_page();
-		if (!mid_mfn)
-			return false;
+			mid_mfn = alloc_p2m_page();
+			if (!mid_mfn)
+				return false;
 
-		p2m_mid_mfn_init(mid_mfn, p2m_missing);
+			p2m_mid_mfn_init(mid_mfn, p2m_missing);
 
-		missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
-		mid_mfn_mfn = virt_to_mfn(mid_mfn);
-		old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
-		if (old_mfn != missing_mfn) {
-			free_p2m_page(mid_mfn);
-			mid_mfn = mfn_to_virt(old_mfn);
-		} else {
-			p2m_top_mfn_p[topidx] = mid_mfn;
+			missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
+			mid_mfn_mfn = virt_to_mfn(mid_mfn);
+			old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
+			if (old_mfn != missing_mfn) {
+				free_p2m_page(mid_mfn);
+				mid_mfn = mfn_to_virt(old_mfn);
+			} else {
+				p2m_top_mfn_p[topidx] = mid_mfn;
+			}
 		}
+	} else {
+		mid_mfn = NULL;
 	}
 
-	p2m_orig = ACCESS_ONCE(p2m_top[topidx][mididx]);
-	if (p2m_orig == p2m_identity || p2m_orig == p2m_missing) {
+	p2m_pfn = pte_pfn(ACCESS_ONCE(*ptep));
+	if (p2m_pfn == PFN_DOWN(__pa(p2m_identity)) ||
+	    p2m_pfn == PFN_DOWN(__pa(p2m_missing))) {
 		/* p2m leaf page is missing */
 		unsigned long *p2m;
 
@@ -613,12 +563,25 @@ static bool alloc_p2m(unsigned long pfn)
 		if (!p2m)
 			return false;
 
-		p2m_init(p2m);
+		if (p2m_pfn == PFN_DOWN(__pa(p2m_missing)))
+			p2m_init(p2m);
+		else
+			p2m_init_identity(p2m, pfn);
+
+		spin_lock_irqsave(&p2m_update_lock, flags);
+
+		if (pte_pfn(*ptep) == p2m_pfn) {
+			set_pte(ptep,
+				pfn_pte(PFN_DOWN(__pa(p2m)), PAGE_KERNEL));
+			if (mid_mfn)
+				mid_mfn[mididx] = virt_to_mfn(p2m);
+			p2m = NULL;
+		}
+
+		spin_unlock_irqrestore(&p2m_update_lock, flags);
 
-		if (cmpxchg(&mid[mididx], p2m_orig, p2m) != p2m_orig)
+		if (p2m)
 			free_p2m_page(p2m);
-		else
-			mid_mfn[mididx] = virt_to_mfn(p2m);
 	}
 
 	return true;
@@ -647,10 +610,10 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	return pfn - pfn_s;
 }
 
-/* Try to install p2m mapping; fail if intermediate bits missing */
 bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	unsigned topidx, mididx, idx;
+	pte_t *ptep;
+	unsigned int level;
 
 	/* don't track P2M changes in autotranslate guests */
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -661,55 +624,27 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* For sparse holes were the p2m leaf has real PFN along with
-	 * PCI holes, stick in the PFN as the MFN value.
-	 *
-	 * set_phys_range_identity() will have allocated new middle
-	 * and leaf pages as required so an existing p2m_mid_missing
-	 * or p2m_missing mean that whole range will be identity so
-	 * these can be switched to p2m_mid_identity or p2m_identity.
-	 */
-	if (mfn != INVALID_P2M_ENTRY && (mfn & IDENTITY_FRAME_BIT)) {
-		if (p2m_top[topidx] == p2m_mid_identity)
-			return true;
-
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx], p2m_mid_missing,
-					p2m_mid_identity) != p2m_mid_missing);
-			return true;
-		}
-
-		if (p2m_top[topidx][mididx] == p2m_identity)
-			return true;
-
-		/* Swap over from MISSING to IDENTITY if needed. */
-		if (p2m_top[topidx][mididx] == p2m_missing) {
-			WARN_ON(cmpxchg(&p2m_top[topidx][mididx], p2m_missing,
-				p2m_identity) != p2m_missing);
-			return true;
-		}
-	}
+	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
-	if (p2m_top[topidx][mididx] == p2m_missing)
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_missing)))
 		return mfn == INVALID_P2M_ENTRY;
 
-	p2m_top[topidx][mididx][idx] = mfn;
+	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
+		return mfn == IDENTITY_FRAME(pfn);
+
+	xen_p2m_addr[pfn] = mfn;
 
 	return true;
 }
 
 bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
+	if (unlikely(!__set_phys_to_machine(pfn, mfn))) {
 		if (!alloc_p2m(pfn))
 			return false;
 
-		if (!__set_phys_to_machine(pfn, mfn))
-			return false;
+		return __set_phys_to_machine(pfn, mfn);
 	}
 
 	return true;
@@ -1035,79 +970,29 @@ EXPORT_SYMBOL_GPL(m2p_find_override_pfn);
 #include "debugfs.h"
 static int p2m_dump_show(struct seq_file *m, void *v)
 {
-	static const char * const level_name[] = { "top", "middle",
-						"entry", "abnormal", "error"};
-#define TYPE_IDENTITY 0
-#define TYPE_MISSING 1
-#define TYPE_PFN 2
-#define TYPE_UNKNOWN 3
 	static const char * const type_name[] = {
-				[TYPE_IDENTITY] = "identity",
-				[TYPE_MISSING] = "missing",
-				[TYPE_PFN] = "pfn",
-				[TYPE_UNKNOWN] = "abnormal"};
-	unsigned long pfn, prev_pfn_type = 0, prev_pfn_level = 0;
-	unsigned int uninitialized_var(prev_level);
-	unsigned int uninitialized_var(prev_type);
-
-	if (!p2m_top)
-		return 0;
-
-	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn++) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-		unsigned idx = p2m_index(pfn);
-		unsigned lvl, type;
-
-		lvl = 4;
-		type = TYPE_UNKNOWN;
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			lvl = 0; type = TYPE_MISSING;
-		} else if (p2m_top[topidx] == NULL) {
-			lvl = 0; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == NULL) {
-			lvl = 1; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx] == p2m_identity) {
-			lvl = 1; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx] == p2m_missing) {
-			lvl = 1; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == 0) {
-			lvl = 2; type = TYPE_UNKNOWN;
-		} else if (p2m_top[topidx][mididx][idx] == IDENTITY_FRAME(pfn)) {
-			lvl = 2; type = TYPE_IDENTITY;
-		} else if (p2m_top[topidx][mididx][idx] == INVALID_P2M_ENTRY) {
-			lvl = 2; type = TYPE_MISSING;
-		} else if (p2m_top[topidx][mididx][idx] == pfn) {
-			lvl = 2; type = TYPE_PFN;
-		} else if (p2m_top[topidx][mididx][idx] != pfn) {
-			lvl = 2; type = TYPE_PFN;
-		}
-		if (pfn == 0) {
-			prev_level = lvl;
+				[P2M_TYPE_IDENTITY] = "identity",
+				[P2M_TYPE_MISSING] = "missing",
+				[P2M_TYPE_PFN] = "pfn",
+				[P2M_TYPE_UNKNOWN] = "abnormal"};
+	unsigned long pfn, first_pfn;
+	int type, prev_type;
+
+	prev_type = xen_p2m_elem_type(0);
+	first_pfn = 0;
+
+	for (pfn = 0; pfn < xen_p2m_size; pfn++) {
+		type = xen_p2m_elem_type(pfn);
+		if (type != prev_type) {
+			seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+				   type_name[prev_type]);
 			prev_type = type;
-		}
-		if (pfn == MAX_DOMAIN_PAGES-1) {
-			lvl = 3;
-			type = TYPE_UNKNOWN;
-		}
-		if (prev_type != type) {
-			seq_printf(m, " [0x%lx->0x%lx] %s\n",
-				prev_pfn_type, pfn, type_name[prev_type]);
-			prev_pfn_type = pfn;
-			prev_type = type;
-		}
-		if (prev_level != lvl) {
-			seq_printf(m, " [0x%lx->0x%lx] level %s\n",
-				prev_pfn_level, pfn, level_name[prev_level]);
-			prev_pfn_level = pfn;
-			prev_level = lvl;
+			first_pfn = pfn;
 		}
 	}
+	seq_printf(m, " [0x%lx->0x%lx] %s\n", first_pfn, pfn,
+		   type_name[prev_type]);
 	return 0;
-#undef TYPE_IDENTITY
-#undef TYPE_MISSING
-#undef TYPE_PFN
-#undef TYPE_UNKNOWN
 }
 
 static int p2m_dump_open(struct inode *inode, struct file *filp)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 02b0b0f..f92921f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -49,7 +49,7 @@ void xen_hvm_init_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-unsigned long __init xen_revector_p2m_tree(void);
+void __init xen_vmalloc_p2m_tree(void);
 
 void xen_init_irq_ops(void);
 void xen_setup_timer(int cpu);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBf-0006T4-K6; Fri, 28 Nov 2014 10:54:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBd-0006Qj-Td
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:06 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	56/8F-22819-D4458745; Fri, 28 Nov 2014 10:54:05 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417172044!13884107!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30708 invoked from network); 28 Nov 2014 10:54:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:04 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9A9B4AC54;
	Fri, 28 Nov 2014 10:54:03 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:49 +0100
Message-Id: <1417172039-8627-1-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 00/10] xen: Switch to virtual mapped linear
	p2m list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paravirtualized kernels running on Xen use a three level tree for
translation of guest specific physical addresses to machine global
addresses. This p2m tree is used for construction of page table
entries, so the p2m tree walk is performance critical.

By using a linear virtual mapped p2m list accesses to p2m elements
can be sped up while even simplifying code. To achieve this goal
some p2m related initializations have to be performed later in the
boot process, as the final p2m list can be set up only after basic
memory management functions are available.

Changes in V4:
- carved out style corrections into new patch 1 as requested by David Vrabel
- minor modification in patch 5 (former patch 3) as suggested by David Vrabel
- carved out change of page allocation scheme from p2m.c into own patch as
  requested by Konrad Wilk, corrected for 32 bit as requested by Andrew Cooper
- added several comments
- simplified error handling in patch 4 (former patch 2)

Changes in V3:
- Carved out (new) patch 1 to make pure code movement more obvious
  as requested by David Vrabel
- New patch 6 introducing __pfn_to_mfn() (taken from patch 7) as
  requested by David Vrabel
- New patch 8 to speed up set_phys_to_machine() as suggested by
  David Vrabel

Changes in V2:
- splitted patch 2 in 4 smaller ones as requested by David Vrabel
- added highmem check when remapping kernel memory as requested by
  David Vrabel


Juergen Gross (10):
  xen: fix some style issues in p2m.c
  xen: Make functions static
  xen: use common page allocation function in p2m.c
  xen: Delay remapping memory of pv-domain
  xen: Delay m2p_override initialization
  xen: Delay invalidating extra memory
  x86: Introduce function to get pmd entry pointer
  xen: Hide get_phys_to_machine() to be able to tune common path
  xen: switch to linear virtual mapped sparse p2m list
  xen: Speed up set_phys_to_machine() by using read-only mappings

 arch/x86/include/asm/pgtable_types.h |    1 +
 arch/x86/include/asm/xen/page.h      |   48 +-
 arch/x86/mm/pageattr.c               |   20 +
 arch/x86/xen/mmu.c                   |   38 +-
 arch/x86/xen/p2m.c                   | 1320 ++++++++++++++--------------------
 arch/x86/xen/setup.c                 |  443 ++++++------
 arch/x86/xen/xen-ops.h               |    6 +-
 7 files changed, 838 insertions(+), 1038 deletions(-)

-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBf-0006TR-VX; Fri, 28 Nov 2014 10:54:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBd-0006Qi-Tg
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:06 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	0E/E6-22737-D4458745; Fri, 28 Nov 2014 10:54:05 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417172044!13822277!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23503 invoked from network); 28 Nov 2014 10:54:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:04 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id F3162AC7E;
	Fri, 28 Nov 2014 10:54:03 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:50 +0100
Message-Id: <1417172039-8627-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 1/9] xen: fix some style issues in p2m.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>
MIME-Version: 1.0
Content-Type: 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 source arch/x86/xen/p2m.c has some coding style issues. Fix them.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/p2m.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 9201a38..73d354a 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -922,7 +922,7 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 			continue;
 
 		if (map_ops[i].flags & GNTMAP_contains_pte) {
-			pte = (pte_t *) (mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
+			pte = (pte_t *)(mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
 				(map_ops[i].host_addr & ~PAGE_MASK));
 			mfn = pte_mfn(*pte);
 		} else {
@@ -970,7 +970,7 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 		address = (unsigned long)__va(pfn << PAGE_SHIFT);
 		ptep = lookup_address(address, &level);
 		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-					"m2p_add_override: pfn %lx not mapped", pfn))
+			 "m2p_add_override: pfn %lx not mapped", pfn))
 			return -EINVAL;
 	}
 
@@ -1072,7 +1072,7 @@ int m2p_remove_override(struct page *page,
 		ptep = lookup_address(address, &level);
 
 		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-					"m2p_remove_override: pfn %lx not mapped", pfn))
+			 "m2p_remove_override: pfn %lx not mapped", pfn))
 			return -EINVAL;
 	}
 
@@ -1102,9 +1102,8 @@ int m2p_remove_override(struct page *page,
 			 * hypercall actually returned an error.
 			 */
 			if (kmap_op->handle == GNTST_general_error) {
-				printk(KERN_WARNING "m2p_remove_override: "
-						"pfn %lx mfn %lx, failed to modify kernel mappings",
-						pfn, mfn);
+				pr_warn("m2p_remove_override: pfn %lx mfn %lx, failed to modify kernel mappings",
+					pfn, mfn);
 				put_balloon_scratch_page();
 				return -1;
 			}
@@ -1112,14 +1111,14 @@ int m2p_remove_override(struct page *page,
 			xen_mc_batch();
 
 			mcs = __xen_mc_entry(
-					sizeof(struct gnttab_unmap_and_replace));
+				sizeof(struct gnttab_unmap_and_replace));
 			unmap_op = mcs.args;
 			unmap_op->host_addr = kmap_op->host_addr;
 			unmap_op->new_addr = scratch_page_address;
 			unmap_op->handle = kmap_op->handle;
 
 			MULTI_grant_table_op(mcs.mc,
-					GNTTABOP_unmap_and_replace, unmap_op, 1);
+				GNTTABOP_unmap_and_replace, unmap_op, 1);
 
 			mcs = __xen_mc_entry(0);
 			MULTI_update_va_mapping(mcs.mc, scratch_page_address,
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBj-0006W7-JN; Fri, 28 Nov 2014 10:54:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBh-0006U8-L9
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:09 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	2C/79-26652-05458745; Fri, 28 Nov 2014 10:54:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417172048!13860211!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5924 invoked from network); 28 Nov 2014 10:54:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2014 10:54:08 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 22D8AADCD;
	Fri, 28 Nov 2014 10:54:08 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:59 +0100
Message-Id: <1417172039-8627-11-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 10/10] xen: Speed up set_phys_to_machine() by
	using read-only mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Instead of checking at each call of set_phys_to_machine() whether a
new p2m page has to be allocated due to writing an entry in a large
invalid or identity area, just map those areas read only and react
to a page fault on write by allocating the new page.

This change will make the common path with no allocation much
faster as it only requires a single write of the new mfn instead
of walking the address translation tables and checking for the
special cases.

Suggested-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 7d84473..8b5db51 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -70,6 +70,7 @@
 
 #include <asm/cache.h>
 #include <asm/setup.h>
+#include <asm/uaccess.h>
 
 #include <asm/xen/page.h>
 #include <asm/xen/hypercall.h>
@@ -316,9 +317,9 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 	paravirt_alloc_pte(&init_mm, __pa(p2m_identity_pte) >> PAGE_SHIFT);
 	for (i = 0; i < PTRS_PER_PTE; i++) {
 		set_pte(p2m_missing_pte + i,
-			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL));
+			pfn_pte(PFN_DOWN(__pa(p2m_missing)), PAGE_KERNEL_RO));
 		set_pte(p2m_identity_pte + i,
-			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL));
+			pfn_pte(PFN_DOWN(__pa(p2m_identity)), PAGE_KERNEL_RO));
 	}
 
 	for (pfn = 0; pfn < xen_max_p2m_pfn; pfn += chunk) {
@@ -365,7 +366,7 @@ static void __init xen_rebuild_p2m_list(unsigned long *p2m)
 				p2m_missing : p2m_identity;
 			ptep = populate_extra_pte((unsigned long)(p2m + pfn));
 			set_pte(ptep,
-				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL));
+				pfn_pte(PFN_DOWN(__pa(mfns)), PAGE_KERNEL_RO));
 			continue;
 		}
 
@@ -624,6 +625,9 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
+	if (likely(!__put_user(mfn, xen_p2m_addr + pfn)))
+		return true;
+
 	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
 	BUG_ON(!ptep || level != PG_LEVEL_4K);
 
@@ -633,9 +637,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
 		return mfn == IDENTITY_FRAME(pfn);
 
-	xen_p2m_addr[pfn] = mfn;
-
-	return true;
+	return false;
 }
 
 bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBg-0006Tx-On; Fri, 28 Nov 2014 10:54:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBe-0006Qt-T6
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	18/CF-15461-E4458745; Fri, 28 Nov 2014 10:54:06 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417172045!12067758!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24551 invoked from network); 28 Nov 2014 10:54:05 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:05 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 587E3ADB0;
	Fri, 28 Nov 2014 10:54:05 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:54 +0100
Message-Id: <1417172039-8627-6-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 05/10] xen: Delay m2p_override initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 m2p overrides are used to be able to find the local pfn for a
foreign mfn mapped into the domain. They are used by driver backends
having to access frontend data.

As this functionality isn't used in early boot it makes no sense to
initialize the m2p override functions very early. It can be done
later without doing any harm, removing the need for allocating memory
via extend_brk().

While at it make some m2p override functions static as they are only
used internally.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 24cd9d1..8676f35 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -428,8 +428,6 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		}
 		p2m_top[topidx][mididx] = &mfn_list[pfn];
 	}
-
-	m2p_override_init();
 }
 #ifdef CONFIG_X86_64
 unsigned long __init xen_revector_p2m_tree(void)
@@ -500,13 +498,15 @@ unsigned long __init xen_revector_p2m_tree(void)
 		}
 		/* This should be the leafs allocated for identity from _brk. */
 	}
-	return (unsigned long)mfn_list;
 
+	m2p_override_init();
+	return (unsigned long)mfn_list;
 }
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	m2p_override_init();
 	return 0;
 }
 #endif
@@ -796,15 +796,16 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 #define M2P_OVERRIDE_HASH_SHIFT	10
 #define M2P_OVERRIDE_HASH	(1 << M2P_OVERRIDE_HASH_SHIFT)
 
-static RESERVE_BRK_ARRAY(struct list_head, m2p_overrides, M2P_OVERRIDE_HASH);
+static struct list_head *m2p_overrides;
 static DEFINE_SPINLOCK(m2p_override_lock);
 
 static void __init m2p_override_init(void)
 {
 	unsigned i;
 
-	m2p_overrides = extend_brk(sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
-				   sizeof(unsigned long));
+	m2p_overrides = alloc_bootmem_align(
+				sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
+				sizeof(unsigned long));
 
 	for (i = 0; i < M2P_OVERRIDE_HASH; i++)
 		INIT_LIST_HEAD(&m2p_overrides[i]);
@@ -932,10 +933,14 @@ EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
 static struct page *m2p_find_override(unsigned long mfn)
 {
 	unsigned long flags;
-	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
+	struct list_head *bucket;
 	struct page *p, *ret;
 
+	if (unlikely(!m2p_overrides))
+		return NULL;
+
 	ret = NULL;
+	bucket = &m2p_overrides[mfn_hash(mfn)];
 
 	spin_lock_irqsave(&m2p_override_lock, flags);
 
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBj-0006Vp-5X; Fri, 28 Nov 2014 10:54:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBh-0006U1-B1
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:09 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	D6/AF-22819-05458745; Fri, 28 Nov 2014 10:54:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417172045!13863537!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4861 invoked from network); 28 Nov 2014 10:54:06 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:06 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CBDC6ADB9;
	Fri, 28 Nov 2014 10:54:05 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:55 +0100
Message-Id: <1417172039-8627-7-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 06/10] xen: Delay invalidating extra memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When the physical memory configuration is initialized the p2m entries
for not pouplated memory pages are set to "invalid". As those pages
are beyond the hypervisor built p2m list the p2m tree has to be
extended.

This patch delays processing the extra memory related p2m entries
during the boot process until some more basic memory management
functions are callable. This removes the need to create new p2m
entries until virtual memory management is available.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/xen/page.h |   3 +
 arch/x86/xen/p2m.c              | 128 ++++++++--------------------------------
 arch/x86/xen/setup.c            |  98 ++++++++++++++++++++++--------
 arch/x86/xen/xen-ops.h          |   3 +-
 4 files changed, 103 insertions(+), 129 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index b475297..28fa795 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -41,6 +41,9 @@ typedef struct xpaddr {
 
 extern unsigned long *machine_to_phys_mapping;
 extern unsigned long  machine_to_phys_nr;
+extern unsigned long *xen_p2m_addr;
+extern unsigned long  xen_p2m_size;
+extern unsigned long  xen_max_p2m_pfn;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8676f35..eddec40 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -181,7 +181,12 @@
 
 static void __init m2p_override_init(void);
 
+unsigned long *xen_p2m_addr __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_addr);
+unsigned long xen_p2m_size __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
+EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
@@ -198,13 +203,6 @@ static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
 
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
 
-/* For each I/O range remapped we may lose up to two leaf pages for the boundary
- * violations and three mid pages to cover up to 3GB. With
- * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
- * remapped region.
- */
-RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
-
 static int use_brk = 1;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
@@ -381,9 +379,11 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	 if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
+	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
 	mfn_list = (unsigned long *)xen_start_info->mfn_list;
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
+	xen_p2m_size = max_pfn;
 
 	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
@@ -499,6 +499,11 @@ unsigned long __init xen_revector_p2m_tree(void)
 		/* This should be the leafs allocated for identity from _brk. */
 	}
 
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_p2m_addr = mfn_list;
+
+	xen_inv_extra_mem();
+
 	m2p_override_init();
 	return (unsigned long)mfn_list;
 }
@@ -506,6 +511,8 @@ unsigned long __init xen_revector_p2m_tree(void)
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_inv_extra_mem();
 	m2p_override_init();
 	return 0;
 }
@@ -514,8 +521,12 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(pfn >= MAX_P2M_PFN))
+	if (unlikely(pfn >= xen_p2m_size)) {
+		if (pfn < xen_max_p2m_pfn)
+			return xen_chk_extra_mem(pfn);
+
 		return IDENTITY_FRAME(pfn);
+	}
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
@@ -613,78 +624,12 @@ static bool alloc_p2m(unsigned long pfn)
 	return true;
 }
 
-static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
-{
-	unsigned topidx, mididx, idx;
-	unsigned long *p2m;
-
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* Pfff.. No boundary cross-over, lets get out. */
-	if (!idx && check_boundary)
-		return false;
-
-	WARN(p2m_top[topidx][mididx] == p2m_identity,
-		"P2M[%d][%d] == IDENTITY, should be MISSING (or alloced)!\n",
-		topidx, mididx);
-
-	/*
-	 * Could be done by xen_build_dynamic_phys_to_machine..
-	 */
-	if (p2m_top[topidx][mididx] != p2m_missing)
-		return false;
-
-	/* Boundary cross-over for the edges: */
-	p2m = alloc_p2m_page();
-
-	p2m_init(p2m);
-
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-
-static bool __init early_alloc_p2m_middle(unsigned long pfn)
-{
-	unsigned topidx = p2m_top_index(pfn);
-	unsigned long **mid;
-
-	mid = p2m_top[topidx];
-	if (mid == p2m_mid_missing) {
-		mid = alloc_p2m_page();
-
-		p2m_mid_init(mid, p2m_missing);
-
-		p2m_top[topidx] = mid;
-	}
-	return true;
-}
-
-static void __init early_split_p2m(unsigned long pfn)
-{
-	unsigned long mididx, idx;
-
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/*
-	 * Allocate new middle and leaf pages if this pfn lies in the
-	 * middle of one.
-	 */
-	if (mididx || idx)
-		early_alloc_p2m_middle(pfn);
-	if (idx)
-		early_alloc_p2m(pfn, false);
-}
-
 unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 				      unsigned long pfn_e)
 {
 	unsigned long pfn;
 
-	if (unlikely(pfn_s >= MAX_P2M_PFN))
+	if (unlikely(pfn_s >= xen_p2m_size))
 		return 0;
 
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -693,34 +638,11 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	if (pfn_s > pfn_e)
 		return 0;
 
-	if (pfn_e > MAX_P2M_PFN)
-		pfn_e = MAX_P2M_PFN;
-
-	early_split_p2m(pfn_s);
-	early_split_p2m(pfn_e);
-
-	for (pfn = pfn_s; pfn < pfn_e;) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-
-		if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
-			break;
-		pfn++;
-
-		/*
-		 * If the PFN was set to a middle or leaf identity
-		 * page the remainder must also be identity, so skip
-		 * ahead to the next middle or leaf entry.
-		 */
-		if (p2m_top[topidx] == p2m_mid_identity)
-			pfn = ALIGN(pfn, P2M_MID_PER_PAGE * P2M_PER_PAGE);
-		else if (p2m_top[topidx][mididx] == p2m_identity)
-			pfn = ALIGN(pfn, P2M_PER_PAGE);
-	}
+	if (pfn_e > xen_p2m_size)
+		pfn_e = xen_p2m_size;
 
-	WARN((pfn - pfn_s) != (pfn_e - pfn_s),
-		"Identity mapping failed. We are %ld short of 1-1 mappings!\n",
-		(pfn_e - pfn_s) - (pfn - pfn_s));
+	for (pfn = pfn_s; pfn < pfn_e; pfn++)
+		xen_p2m_addr[pfn] = IDENTITY_FRAME(pfn);
 
 	return pfn - pfn_s;
 }
@@ -734,7 +656,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
 		return true;
 
-	if (unlikely(pfn >= MAX_P2M_PFN)) {
+	if (unlikely(pfn >= xen_p2m_size)) {
 		BUG_ON(mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index e0b6912f..12cd199 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -76,7 +76,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 static void __init xen_add_extra_mem(u64 start, u64 size)
 {
-	unsigned long pfn;
 	int i;
 
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
@@ -96,17 +95,75 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
 
 	memblock_reserve(start, size);
+}
 
-	xen_max_p2m_pfn = PFN_DOWN(start + size);
-	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
-		unsigned long mfn = pfn_to_mfn(pfn);
+static void __init xen_del_extra_mem(u64 start, u64 size)
+{
+	int i;
+	u64 start_r, size_r;
 
-		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
-			continue;
-		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
-			  pfn, mfn);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		start_r = xen_extra_mem[i].start;
+		size_r = xen_extra_mem[i].size;
+
+		/* Start of region. */
+		if (start_r == start) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].start += size;
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* End of region. */
+		if (start_r + size_r == start + size) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* Mid of region. */
+		if (start > start_r && start < start_r + size_r) {
+			BUG_ON(start + size > start_r + size_r);
+			xen_extra_mem[i].size = start - start_r;
+			/* Calling memblock_reserve() again is okay. */
+			xen_add_extra_mem(start + size, start_r + size_r -
+					  (start + size));
+			break;
+		}
+	}
+	memblock_free(start, size);
+}
+
+/*
+ * Called during boot before the p2m list can take entries beyond the
+ * hypervisor supplied p2m list. Entries in extra mem are to be regarded as
+ * invalid.
+ */
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
+{
+	int i;
+	unsigned long addr = PFN_PHYS(pfn);
 
-		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		if (addr >= xen_extra_mem[i].start &&
+		    addr < xen_extra_mem[i].start + xen_extra_mem[i].size)
+			return INVALID_P2M_ENTRY;
+	}
+
+	return IDENTITY_FRAME(pfn);
+}
+
+/*
+ * Mark all pfns of extra mem as invalid in p2m list.
+ */
+void __init xen_inv_extra_mem(void)
+{
+	unsigned long pfn, pfn_s, pfn_e;
+	int i;
+
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		pfn_s = PFN_DOWN(xen_extra_mem[i].start);
+		pfn_e = PFN_UP(xen_extra_mem[i].start + xen_extra_mem[i].size);
+		for (pfn = pfn_s; pfn < pfn_e; pfn++)
+			set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 	}
 }
 
@@ -268,9 +325,6 @@ static void __init xen_do_set_identity_and_remap_chunk(
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/* Don't use memory until remapped */
-	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
-
 	mfn_save = virt_to_mfn(buf);
 
 	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
@@ -314,7 +368,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
  * pages. In the case of an error the underlying memory is simply released back
  * to Xen and not remapped.
  */
-static unsigned long __init xen_set_identity_and_remap_chunk(
+static unsigned long xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
 	unsigned long *identity, unsigned long *released)
@@ -371,7 +425,7 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 	return remap_pfn;
 }
 
-static unsigned long __init xen_set_identity_and_remap(
+static void __init xen_set_identity_and_remap(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages,
 	unsigned long *released)
 {
@@ -415,8 +469,6 @@ static unsigned long __init xen_set_identity_and_remap(
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
 	pr_info("Released %ld page(s)\n", num_released);
-
-	return last_pfn;
 }
 
 /*
@@ -456,7 +508,7 @@ void __init xen_remap_memory(void)
 		} else if (pfn_s + len == xen_remap_buf.target_pfn) {
 			len += xen_remap_buf.size;
 		} else {
-			memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+			xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
 			pfn_s = xen_remap_buf.target_pfn;
 			len = xen_remap_buf.size;
 		}
@@ -466,7 +518,7 @@ void __init xen_remap_memory(void)
 	}
 
 	if (pfn_s != ~0UL && len)
-		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+		xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
 
 	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 
@@ -533,7 +585,6 @@ char * __init xen_memory_setup(void)
 	int rc;
 	struct xen_memory_map memmap;
 	unsigned long max_pages;
-	unsigned long last_pfn = 0;
 	unsigned long extra_pages = 0;
 	int i;
 	int op;
@@ -583,15 +634,11 @@ char * __init xen_memory_setup(void)
 	 * Set identity map on non-RAM pages and prepare remapping the
 	 * underlying RAM.
 	 */
-	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
-					      &xen_released_pages);
+	xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
+				   &xen_released_pages);
 
 	extra_pages += xen_released_pages;
 
-	if (last_pfn > max_pfn) {
-		max_pfn = min(MAX_DOMAIN_PAGES, last_pfn);
-		mem_end = PFN_PHYS(max_pfn);
-	}
 	/*
 	 * Clamp the amount of extra memory to a EXTRA_MEM_RATIO
 	 * factor the base size.  On non-highmem systems, the base
@@ -618,6 +665,7 @@ char * __init xen_memory_setup(void)
 				size = min(size, (u64)extra_pages * PAGE_SIZE);
 				extra_pages -= size / PAGE_SIZE;
 				xen_add_extra_mem(addr, size);
+				xen_max_p2m_pfn = PFN_DOWN(addr + size);
 			} else
 				type = E820_UNUSABLE;
 		}
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 5b72a06..02b0b0f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -29,12 +29,13 @@ void xen_build_mfn_list_list(void);
 void xen_setup_machphys_mapping(void);
 void xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn);
 void xen_reserve_top(void);
-extern unsigned long xen_max_p2m_pfn;
 
 void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn);
+void __init xen_inv_extra_mem(void);
 void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBj-0006Vp-5X; Fri, 28 Nov 2014 10:54:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBh-0006U1-B1
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:09 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	D6/AF-22819-05458745; Fri, 28 Nov 2014 10:54:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417172045!13863537!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4861 invoked from network); 28 Nov 2014 10:54:06 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:06 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CBDC6ADB9;
	Fri, 28 Nov 2014 10:54:05 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:55 +0100
Message-Id: <1417172039-8627-7-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 06/10] xen: Delay invalidating extra memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When the physical memory configuration is initialized the p2m entries
for not pouplated memory pages are set to "invalid". As those pages
are beyond the hypervisor built p2m list the p2m tree has to be
extended.

This patch delays processing the extra memory related p2m entries
during the boot process until some more basic memory management
functions are callable. This removes the need to create new p2m
entries until virtual memory management is available.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/xen/page.h |   3 +
 arch/x86/xen/p2m.c              | 128 ++++++++--------------------------------
 arch/x86/xen/setup.c            |  98 ++++++++++++++++++++++--------
 arch/x86/xen/xen-ops.h          |   3 +-
 4 files changed, 103 insertions(+), 129 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index b475297..28fa795 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -41,6 +41,9 @@ typedef struct xpaddr {
 
 extern unsigned long *machine_to_phys_mapping;
 extern unsigned long  machine_to_phys_nr;
+extern unsigned long *xen_p2m_addr;
+extern unsigned long  xen_p2m_size;
+extern unsigned long  xen_max_p2m_pfn;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8676f35..eddec40 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -181,7 +181,12 @@
 
 static void __init m2p_override_init(void);
 
+unsigned long *xen_p2m_addr __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_addr);
+unsigned long xen_p2m_size __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
+EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
@@ -198,13 +203,6 @@ static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_identity, P2M_MID_PER_PAGE);
 
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER_PAGE)));
 
-/* For each I/O range remapped we may lose up to two leaf pages for the boundary
- * violations and three mid pages to cover up to 3GB. With
- * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
- * remapped region.
- */
-RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
-
 static int use_brk = 1;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
@@ -381,9 +379,11 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	 if (xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
+	xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
 	mfn_list = (unsigned long *)xen_start_info->mfn_list;
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
+	xen_p2m_size = max_pfn;
 
 	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
@@ -499,6 +499,11 @@ unsigned long __init xen_revector_p2m_tree(void)
 		/* This should be the leafs allocated for identity from _brk. */
 	}
 
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_p2m_addr = mfn_list;
+
+	xen_inv_extra_mem();
+
 	m2p_override_init();
 	return (unsigned long)mfn_list;
 }
@@ -506,6 +511,8 @@ unsigned long __init xen_revector_p2m_tree(void)
 unsigned long __init xen_revector_p2m_tree(void)
 {
 	use_brk = 0;
+	xen_p2m_size = xen_max_p2m_pfn;
+	xen_inv_extra_mem();
 	m2p_override_init();
 	return 0;
 }
@@ -514,8 +521,12 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(pfn >= MAX_P2M_PFN))
+	if (unlikely(pfn >= xen_p2m_size)) {
+		if (pfn < xen_max_p2m_pfn)
+			return xen_chk_extra_mem(pfn);
+
 		return IDENTITY_FRAME(pfn);
+	}
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
@@ -613,78 +624,12 @@ static bool alloc_p2m(unsigned long pfn)
 	return true;
 }
 
-static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
-{
-	unsigned topidx, mididx, idx;
-	unsigned long *p2m;
-
-	topidx = p2m_top_index(pfn);
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/* Pfff.. No boundary cross-over, lets get out. */
-	if (!idx && check_boundary)
-		return false;
-
-	WARN(p2m_top[topidx][mididx] == p2m_identity,
-		"P2M[%d][%d] == IDENTITY, should be MISSING (or alloced)!\n",
-		topidx, mididx);
-
-	/*
-	 * Could be done by xen_build_dynamic_phys_to_machine..
-	 */
-	if (p2m_top[topidx][mididx] != p2m_missing)
-		return false;
-
-	/* Boundary cross-over for the edges: */
-	p2m = alloc_p2m_page();
-
-	p2m_init(p2m);
-
-	p2m_top[topidx][mididx] = p2m;
-
-	return true;
-}
-
-static bool __init early_alloc_p2m_middle(unsigned long pfn)
-{
-	unsigned topidx = p2m_top_index(pfn);
-	unsigned long **mid;
-
-	mid = p2m_top[topidx];
-	if (mid == p2m_mid_missing) {
-		mid = alloc_p2m_page();
-
-		p2m_mid_init(mid, p2m_missing);
-
-		p2m_top[topidx] = mid;
-	}
-	return true;
-}
-
-static void __init early_split_p2m(unsigned long pfn)
-{
-	unsigned long mididx, idx;
-
-	mididx = p2m_mid_index(pfn);
-	idx = p2m_index(pfn);
-
-	/*
-	 * Allocate new middle and leaf pages if this pfn lies in the
-	 * middle of one.
-	 */
-	if (mididx || idx)
-		early_alloc_p2m_middle(pfn);
-	if (idx)
-		early_alloc_p2m(pfn, false);
-}
-
 unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 				      unsigned long pfn_e)
 {
 	unsigned long pfn;
 
-	if (unlikely(pfn_s >= MAX_P2M_PFN))
+	if (unlikely(pfn_s >= xen_p2m_size))
 		return 0;
 
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -693,34 +638,11 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 	if (pfn_s > pfn_e)
 		return 0;
 
-	if (pfn_e > MAX_P2M_PFN)
-		pfn_e = MAX_P2M_PFN;
-
-	early_split_p2m(pfn_s);
-	early_split_p2m(pfn_e);
-
-	for (pfn = pfn_s; pfn < pfn_e;) {
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned mididx = p2m_mid_index(pfn);
-
-		if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
-			break;
-		pfn++;
-
-		/*
-		 * If the PFN was set to a middle or leaf identity
-		 * page the remainder must also be identity, so skip
-		 * ahead to the next middle or leaf entry.
-		 */
-		if (p2m_top[topidx] == p2m_mid_identity)
-			pfn = ALIGN(pfn, P2M_MID_PER_PAGE * P2M_PER_PAGE);
-		else if (p2m_top[topidx][mididx] == p2m_identity)
-			pfn = ALIGN(pfn, P2M_PER_PAGE);
-	}
+	if (pfn_e > xen_p2m_size)
+		pfn_e = xen_p2m_size;
 
-	WARN((pfn - pfn_s) != (pfn_e - pfn_s),
-		"Identity mapping failed. We are %ld short of 1-1 mappings!\n",
-		(pfn_e - pfn_s) - (pfn - pfn_s));
+	for (pfn = pfn_s; pfn < pfn_e; pfn++)
+		xen_p2m_addr[pfn] = IDENTITY_FRAME(pfn);
 
 	return pfn - pfn_s;
 }
@@ -734,7 +656,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
 		return true;
 
-	if (unlikely(pfn >= MAX_P2M_PFN)) {
+	if (unlikely(pfn >= xen_p2m_size)) {
 		BUG_ON(mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index e0b6912f..12cd199 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -76,7 +76,6 @@ static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
 static void __init xen_add_extra_mem(u64 start, u64 size)
 {
-	unsigned long pfn;
 	int i;
 
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
@@ -96,17 +95,75 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
 
 	memblock_reserve(start, size);
+}
 
-	xen_max_p2m_pfn = PFN_DOWN(start + size);
-	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
-		unsigned long mfn = pfn_to_mfn(pfn);
+static void __init xen_del_extra_mem(u64 start, u64 size)
+{
+	int i;
+	u64 start_r, size_r;
 
-		if (WARN_ONCE(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
-			continue;
-		WARN_ONCE(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
-			  pfn, mfn);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		start_r = xen_extra_mem[i].start;
+		size_r = xen_extra_mem[i].size;
+
+		/* Start of region. */
+		if (start_r == start) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].start += size;
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* End of region. */
+		if (start_r + size_r == start + size) {
+			BUG_ON(size > size_r);
+			xen_extra_mem[i].size -= size;
+			break;
+		}
+		/* Mid of region. */
+		if (start > start_r && start < start_r + size_r) {
+			BUG_ON(start + size > start_r + size_r);
+			xen_extra_mem[i].size = start - start_r;
+			/* Calling memblock_reserve() again is okay. */
+			xen_add_extra_mem(start + size, start_r + size_r -
+					  (start + size));
+			break;
+		}
+	}
+	memblock_free(start, size);
+}
+
+/*
+ * Called during boot before the p2m list can take entries beyond the
+ * hypervisor supplied p2m list. Entries in extra mem are to be regarded as
+ * invalid.
+ */
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
+{
+	int i;
+	unsigned long addr = PFN_PHYS(pfn);
 
-		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		if (addr >= xen_extra_mem[i].start &&
+		    addr < xen_extra_mem[i].start + xen_extra_mem[i].size)
+			return INVALID_P2M_ENTRY;
+	}
+
+	return IDENTITY_FRAME(pfn);
+}
+
+/*
+ * Mark all pfns of extra mem as invalid in p2m list.
+ */
+void __init xen_inv_extra_mem(void)
+{
+	unsigned long pfn, pfn_s, pfn_e;
+	int i;
+
+	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+		pfn_s = PFN_DOWN(xen_extra_mem[i].start);
+		pfn_e = PFN_UP(xen_extra_mem[i].start + xen_extra_mem[i].size);
+		for (pfn = pfn_s; pfn < pfn_e; pfn++)
+			set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 	}
 }
 
@@ -268,9 +325,6 @@ static void __init xen_do_set_identity_and_remap_chunk(
 
 	BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
 
-	/* Don't use memory until remapped */
-	memblock_reserve(PFN_PHYS(remap_pfn), PFN_PHYS(size));
-
 	mfn_save = virt_to_mfn(buf);
 
 	for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
@@ -314,7 +368,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
  * pages. In the case of an error the underlying memory is simply released back
  * to Xen and not remapped.
  */
-static unsigned long __init xen_set_identity_and_remap_chunk(
+static unsigned long xen_set_identity_and_remap_chunk(
         const struct e820entry *list, size_t map_size, unsigned long start_pfn,
 	unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
 	unsigned long *identity, unsigned long *released)
@@ -371,7 +425,7 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
 	return remap_pfn;
 }
 
-static unsigned long __init xen_set_identity_and_remap(
+static void __init xen_set_identity_and_remap(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages,
 	unsigned long *released)
 {
@@ -415,8 +469,6 @@ static unsigned long __init xen_set_identity_and_remap(
 
 	pr_info("Set %ld page(s) to 1-1 mapping\n", identity);
 	pr_info("Released %ld page(s)\n", num_released);
-
-	return last_pfn;
 }
 
 /*
@@ -456,7 +508,7 @@ void __init xen_remap_memory(void)
 		} else if (pfn_s + len == xen_remap_buf.target_pfn) {
 			len += xen_remap_buf.size;
 		} else {
-			memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+			xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
 			pfn_s = xen_remap_buf.target_pfn;
 			len = xen_remap_buf.size;
 		}
@@ -466,7 +518,7 @@ void __init xen_remap_memory(void)
 	}
 
 	if (pfn_s != ~0UL && len)
-		memblock_free(PFN_PHYS(pfn_s), PFN_PHYS(len));
+		xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
 
 	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 
@@ -533,7 +585,6 @@ char * __init xen_memory_setup(void)
 	int rc;
 	struct xen_memory_map memmap;
 	unsigned long max_pages;
-	unsigned long last_pfn = 0;
 	unsigned long extra_pages = 0;
 	int i;
 	int op;
@@ -583,15 +634,11 @@ char * __init xen_memory_setup(void)
 	 * Set identity map on non-RAM pages and prepare remapping the
 	 * underlying RAM.
 	 */
-	last_pfn = xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
-					      &xen_released_pages);
+	xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn,
+				   &xen_released_pages);
 
 	extra_pages += xen_released_pages;
 
-	if (last_pfn > max_pfn) {
-		max_pfn = min(MAX_DOMAIN_PAGES, last_pfn);
-		mem_end = PFN_PHYS(max_pfn);
-	}
 	/*
 	 * Clamp the amount of extra memory to a EXTRA_MEM_RATIO
 	 * factor the base size.  On non-highmem systems, the base
@@ -618,6 +665,7 @@ char * __init xen_memory_setup(void)
 				size = min(size, (u64)extra_pages * PAGE_SIZE);
 				extra_pages -= size / PAGE_SIZE;
 				xen_add_extra_mem(addr, size);
+				xen_max_p2m_pfn = PFN_DOWN(addr + size);
 			} else
 				type = E820_UNUSABLE;
 		}
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 5b72a06..02b0b0f 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -29,12 +29,13 @@ void xen_build_mfn_list_list(void);
 void xen_setup_machphys_mapping(void);
 void xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn);
 void xen_reserve_top(void);
-extern unsigned long xen_max_p2m_pfn;
 
 void xen_mm_pin_all(void);
 void xen_mm_unpin_all(void);
 void xen_set_pat(u64);
 
+unsigned long __ref xen_chk_extra_mem(unsigned long pfn);
+void __init xen_inv_extra_mem(void);
 void __init xen_remap_memory(void);
 char * __init xen_memory_setup(void);
 char * xen_auto_xlated_memory_setup(void);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10: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 1XuJBi-0006VU-Nk; Fri, 28 Nov 2014 10:54:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBh-0006Tw-6N
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F2/52-25276-05458745; Fri, 28 Nov 2014 10:54:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417172044!12090746!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25331 invoked from network); 28 Nov 2014 10:54:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:04 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9EB34AD8D;
	Fri, 28 Nov 2014 10:54:04 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:52 +0100
Message-Id: <1417172039-8627-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 03/10] xen: use common page allocation
	function in p2m.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>
MIME-Version: 1.0
Content-Type: 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 arch/x86/xen/p2m.c three different allocation functions for
obtaining a memory page are used: extend_brk(), alloc_bootmem_align()
or __get_free_page().  Which of those functions is used depends on the
progress of the boot process of the system.

Introduce a common allocation routine selecting the to be called
allocation routine dynamically based on the boot progress. This allows
moving initialization steps without having to care about changing
allocation calls.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/mmu.c |  2 ++
 arch/x86/xen/p2m.c | 57 +++++++++++++++++++++++++++++++++---------------------
 2 files changed, 37 insertions(+), 22 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a8a1a3d..b995b871 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1219,6 +1219,8 @@ static void __init xen_pagetable_init(void)
 	paging_init();
 #ifdef CONFIG_X86_64
 	xen_pagetable_p2m_copy();
+#else
+	xen_revector_p2m_tree();
 #endif
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 2d8b908..fa53dc2 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -164,6 +164,7 @@
 #include <linux/sched.h>
 #include <linux/seq_file.h>
 #include <linux/bootmem.h>
+#include <linux/slab.h>
 
 #include <asm/cache.h>
 #include <asm/setup.h>
@@ -204,6 +205,8 @@ RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER
  */
 RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
+static int use_brk = 1;
+
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
 	BUG_ON(pfn >= MAX_P2M_PFN);
@@ -268,6 +271,24 @@ static void p2m_init(unsigned long *p2m)
 		p2m[i] = INVALID_P2M_ENTRY;
 }
 
+static void * __ref alloc_p2m_page(void)
+{
+	if (unlikely(use_brk))
+		return extend_brk(PAGE_SIZE, PAGE_SIZE);
+
+	if (unlikely(!slab_is_available()))
+		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+
+	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+/* Only to be called in case of a race for a page just allocated! */
+static void free_p2m_page(void *p)
+{
+	BUG_ON(!slab_is_available());
+	free_page((unsigned long)p);
+}
+
 /*
  * Build the parallel p2m_top_mfn and p2m_mid_mfn structures
  *
@@ -287,13 +308,13 @@ void __ref xen_build_mfn_list_list(void)
 
 	/* Pre-initialize p2m_top_mfn to be completely missing */
 	if (p2m_top_mfn == NULL) {
-		p2m_mid_missing_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_mid_missing_mfn = alloc_p2m_page();
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 
-		p2m_top_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn_p = alloc_p2m_page();
 		p2m_top_mfn_p_init(p2m_top_mfn_p);
 
-		p2m_top_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn = alloc_p2m_page();
 		p2m_top_mfn_init(p2m_top_mfn);
 	} else {
 		/* Reinitialise, mfn's all change after migration */
@@ -327,7 +348,7 @@ void __ref xen_build_mfn_list_list(void)
 			 * missing parts of the mfn tree after
 			 * runtime.
 			 */
-			mid_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
 			p2m_top_mfn_p[topidx] = mid_mfn_p;
@@ -364,17 +385,17 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
 
-	p2m_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
-	p2m_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_identity = alloc_p2m_page();
 	p2m_init(p2m_identity);
 
-	p2m_mid_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_missing = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_identity = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_identity, p2m_identity);
 
-	p2m_top = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_top = alloc_p2m_page();
 	p2m_top_init(p2m_top);
 
 	/*
@@ -387,7 +408,7 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		unsigned mididx = p2m_mid_index(pfn);
 
 		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+			unsigned long **mid = alloc_p2m_page();
 			p2m_mid_init(mid, p2m_missing);
 
 			p2m_top[topidx] = mid;
@@ -420,6 +441,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 	unsigned long *mfn_list = NULL;
 	unsigned long size;
 
+	use_brk = 0;
 	va_start = xen_start_info->mfn_list;
 	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
 	 * so make sure it is rounded up to that */
@@ -484,6 +506,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
+	use_brk = 0;
 	return 0;
 }
 #endif
@@ -510,16 +533,6 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
-static void *alloc_p2m_page(void)
-{
-	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
-}
-
-static void free_p2m_page(void *p)
-{
-	free_page((unsigned long)p);
-}
-
 /*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
@@ -624,7 +637,7 @@ static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
 		return false;
 
 	/* Boundary cross-over for the edges: */
-	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m = alloc_p2m_page();
 
 	p2m_init(p2m);
 
@@ -640,7 +653,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 
 	mid = p2m_top[topidx];
 	if (mid == p2m_mid_missing) {
-		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+		mid = alloc_p2m_page();
 
 		p2m_mid_init(mid, p2m_missing);
 
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10: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 1XuJBi-0006VU-Nk; Fri, 28 Nov 2014 10:54:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBh-0006Tw-6N
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F2/52-25276-05458745; Fri, 28 Nov 2014 10:54:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417172044!12090746!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25331 invoked from network); 28 Nov 2014 10:54:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:04 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9EB34AD8D;
	Fri, 28 Nov 2014 10:54:04 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:52 +0100
Message-Id: <1417172039-8627-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 03/10] xen: use common page allocation
	function in p2m.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>
MIME-Version: 1.0
Content-Type: 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 arch/x86/xen/p2m.c three different allocation functions for
obtaining a memory page are used: extend_brk(), alloc_bootmem_align()
or __get_free_page().  Which of those functions is used depends on the
progress of the boot process of the system.

Introduce a common allocation routine selecting the to be called
allocation routine dynamically based on the boot progress. This allows
moving initialization steps without having to care about changing
allocation calls.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/mmu.c |  2 ++
 arch/x86/xen/p2m.c | 57 +++++++++++++++++++++++++++++++++---------------------
 2 files changed, 37 insertions(+), 22 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a8a1a3d..b995b871 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1219,6 +1219,8 @@ static void __init xen_pagetable_init(void)
 	paging_init();
 #ifdef CONFIG_X86_64
 	xen_pagetable_p2m_copy();
+#else
+	xen_revector_p2m_tree();
 #endif
 	/* Allocate and initialize top and mid mfn levels for p2m structure */
 	xen_build_mfn_list_list();
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 2d8b908..fa53dc2 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -164,6 +164,7 @@
 #include <linux/sched.h>
 #include <linux/seq_file.h>
 #include <linux/bootmem.h>
+#include <linux/slab.h>
 
 #include <asm/cache.h>
 #include <asm/setup.h>
@@ -204,6 +205,8 @@ RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * P2M_MID_PER
  */
 RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
+static int use_brk = 1;
+
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
 	BUG_ON(pfn >= MAX_P2M_PFN);
@@ -268,6 +271,24 @@ static void p2m_init(unsigned long *p2m)
 		p2m[i] = INVALID_P2M_ENTRY;
 }
 
+static void * __ref alloc_p2m_page(void)
+{
+	if (unlikely(use_brk))
+		return extend_brk(PAGE_SIZE, PAGE_SIZE);
+
+	if (unlikely(!slab_is_available()))
+		return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+
+	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+/* Only to be called in case of a race for a page just allocated! */
+static void free_p2m_page(void *p)
+{
+	BUG_ON(!slab_is_available());
+	free_page((unsigned long)p);
+}
+
 /*
  * Build the parallel p2m_top_mfn and p2m_mid_mfn structures
  *
@@ -287,13 +308,13 @@ void __ref xen_build_mfn_list_list(void)
 
 	/* Pre-initialize p2m_top_mfn to be completely missing */
 	if (p2m_top_mfn == NULL) {
-		p2m_mid_missing_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_mid_missing_mfn = alloc_p2m_page();
 		p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 
-		p2m_top_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn_p = alloc_p2m_page();
 		p2m_top_mfn_p_init(p2m_top_mfn_p);
 
-		p2m_top_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+		p2m_top_mfn = alloc_p2m_page();
 		p2m_top_mfn_init(p2m_top_mfn);
 	} else {
 		/* Reinitialise, mfn's all change after migration */
@@ -327,7 +348,7 @@ void __ref xen_build_mfn_list_list(void)
 			 * missing parts of the mfn tree after
 			 * runtime.
 			 */
-			mid_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+			mid_mfn_p = alloc_p2m_page();
 			p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
 			p2m_top_mfn_p[topidx] = mid_mfn_p;
@@ -364,17 +385,17 @@ void __init xen_build_dynamic_phys_to_machine(void)
 	max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
 	xen_max_p2m_pfn = max_pfn;
 
-	p2m_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_missing = alloc_p2m_page();
 	p2m_init(p2m_missing);
-	p2m_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_identity = alloc_p2m_page();
 	p2m_init(p2m_identity);
 
-	p2m_mid_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_missing = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_missing, p2m_missing);
-	p2m_mid_identity = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_mid_identity = alloc_p2m_page();
 	p2m_mid_init(p2m_mid_identity, p2m_identity);
 
-	p2m_top = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m_top = alloc_p2m_page();
 	p2m_top_init(p2m_top);
 
 	/*
@@ -387,7 +408,7 @@ void __init xen_build_dynamic_phys_to_machine(void)
 		unsigned mididx = p2m_mid_index(pfn);
 
 		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+			unsigned long **mid = alloc_p2m_page();
 			p2m_mid_init(mid, p2m_missing);
 
 			p2m_top[topidx] = mid;
@@ -420,6 +441,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 	unsigned long *mfn_list = NULL;
 	unsigned long size;
 
+	use_brk = 0;
 	va_start = xen_start_info->mfn_list;
 	/*We copy in increments of P2M_PER_PAGE * sizeof(unsigned long),
 	 * so make sure it is rounded up to that */
@@ -484,6 +506,7 @@ unsigned long __init xen_revector_p2m_tree(void)
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
+	use_brk = 0;
 	return 0;
 }
 #endif
@@ -510,16 +533,6 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 }
 EXPORT_SYMBOL_GPL(get_phys_to_machine);
 
-static void *alloc_p2m_page(void)
-{
-	return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
-}
-
-static void free_p2m_page(void *p)
-{
-	free_page((unsigned long)p);
-}
-
 /*
  * Fully allocate the p2m structure for a given pfn.  We need to check
  * that both the top and mid levels are allocated, and make sure the
@@ -624,7 +637,7 @@ static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
 		return false;
 
 	/* Boundary cross-over for the edges: */
-	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
+	p2m = alloc_p2m_page();
 
 	p2m_init(p2m);
 
@@ -640,7 +653,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 
 	mid = p2m_top[topidx];
 	if (mid == p2m_mid_missing) {
-		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+		mid = alloc_p2m_page();
 
 		p2m_mid_init(mid, p2m_missing);
 
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBh-0006Uf-Nc; Fri, 28 Nov 2014 10:54:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBf-0006Sm-Vf
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:08 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	77/4B-17958-F4458745; Fri, 28 Nov 2014 10:54:07 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417172046!10740714!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6108 invoked from network); 28 Nov 2014 10:54:06 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:06 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 35309ADBC;
	Fri, 28 Nov 2014 10:54:06 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:56 +0100
Message-Id: <1417172039-8627-8-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 07/10] x86: Introduce function to get pmd
	entry pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduces lookup_pmd_address() to get the address of the pmd entry
related to a virtual address in the current address space. This
function is needed for support of a virtual mapped sparse p2m list
in xen pv domains, as we need the address of the pmd entry, not the
one of the pte in that case.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/pgtable_types.h |  1 +
 arch/x86/mm/pageattr.c               | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0778964..d83f5e7 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -396,6 +396,7 @@ static inline void update_page_count(int level, unsigned long pages) { }
 extern pte_t *lookup_address(unsigned long address, unsigned int *level);
 extern pte_t *lookup_address_in_pgd(pgd_t *pgd, unsigned long address,
 				    unsigned int *level);
+extern pmd_t *lookup_pmd_address(unsigned long address);
 extern phys_addr_t slow_virt_to_phys(void *__address);
 extern int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
 				   unsigned numpages, unsigned long page_flags);
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 36de293..1298108 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -384,6 +384,26 @@ static pte_t *_lookup_address_cpa(struct cpa_data *cpa, unsigned long address,
 }
 
 /*
+ * Lookup the PMD entry for a virtual address. Return a pointer to the entry
+ * or NULL if not present.
+ */
+pmd_t *lookup_pmd_address(unsigned long address)
+{
+	pgd_t *pgd;
+	pud_t *pud;
+
+	pgd = pgd_offset_k(address);
+	if (pgd_none(*pgd))
+		return NULL;
+
+	pud = pud_offset(pgd, address);
+	if (pud_none(*pud) || pud_large(*pud) || !pud_present(*pud))
+		return NULL;
+
+	return pmd_offset(pud, address);
+}
+
+/*
  * This is necessary because __pa() does not work on some
  * kinds of memory, like vmalloc() or the alloc_remap()
  * areas on 32-bit NUMA systems.  The percpu areas can
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBh-0006Uf-Nc; Fri, 28 Nov 2014 10:54:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBf-0006Sm-Vf
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:08 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	77/4B-17958-F4458745; Fri, 28 Nov 2014 10:54:07 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417172046!10740714!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6108 invoked from network); 28 Nov 2014 10:54:06 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:06 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 35309ADBC;
	Fri, 28 Nov 2014 10:54:06 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:56 +0100
Message-Id: <1417172039-8627-8-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 07/10] x86: Introduce function to get pmd
	entry pointer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduces lookup_pmd_address() to get the address of the pmd entry
related to a virtual address in the current address space. This
function is needed for support of a virtual mapped sparse p2m list
in xen pv domains, as we need the address of the pmd entry, not the
one of the pte in that case.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/pgtable_types.h |  1 +
 arch/x86/mm/pageattr.c               | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0778964..d83f5e7 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -396,6 +396,7 @@ static inline void update_page_count(int level, unsigned long pages) { }
 extern pte_t *lookup_address(unsigned long address, unsigned int *level);
 extern pte_t *lookup_address_in_pgd(pgd_t *pgd, unsigned long address,
 				    unsigned int *level);
+extern pmd_t *lookup_pmd_address(unsigned long address);
 extern phys_addr_t slow_virt_to_phys(void *__address);
 extern int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
 				   unsigned numpages, unsigned long page_flags);
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 36de293..1298108 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -384,6 +384,26 @@ static pte_t *_lookup_address_cpa(struct cpa_data *cpa, unsigned long address,
 }
 
 /*
+ * Lookup the PMD entry for a virtual address. Return a pointer to the entry
+ * or NULL if not present.
+ */
+pmd_t *lookup_pmd_address(unsigned long address)
+{
+	pgd_t *pgd;
+	pud_t *pud;
+
+	pgd = pgd_offset_k(address);
+	if (pgd_none(*pgd))
+		return NULL;
+
+	pud = pud_offset(pgd, address);
+	if (pud_none(*pud) || pud_large(*pud) || !pud_present(*pud))
+		return NULL;
+
+	return pmd_offset(pud, address);
+}
+
+/*
  * This is necessary because __pa() does not work on some
  * kinds of memory, like vmalloc() or the alloc_remap()
  * areas on 32-bit NUMA systems.  The percpu areas can
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBi-0006Uw-5F; Fri, 28 Nov 2014 10:54:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBg-0006TL-9z
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	14/F5-09842-F4458745; Fri, 28 Nov 2014 10:54:07 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417172046!12070570!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4101 invoked from network); 28 Nov 2014 10:54:07 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:07 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9D0D5ADBE;
	Fri, 28 Nov 2014 10:54:06 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:57 +0100
Message-Id: <1417172039-8627-9-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 08/10] xen: Hide get_phys_to_machine() to be
	able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 get_phys_to_machine() is always called when the mfn for a pfn
is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
to be able to avoid calling get_phys_to_machine() when possible as
soon as the switch to a linear mapped p2m list has been done.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/xen/page.h | 26 ++++++++++++++++++++------
 arch/x86/xen/mmu.c              |  2 +-
 arch/x86/xen/p2m.c              |  6 +++---
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 28fa795..410a6ec 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -59,6 +59,21 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct page **pages, unsigned int count);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
+/*
+ * When to use pfn_to_mfn(), __pfn_to_mfn() or get_phys_to_machine():
+ * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. No indicator
+ *   bits (identity or foreign) are set.
+ * - __pfn_to_mfn() returns the found entry of the p2m table. A possibly set
+ *   identity or foreign indicator will be still set. __pfn_to_mfn() is
+ *   encapsulating get_phys_to_machine().
+ * - get_phys_to_machine() is to be called by __pfn_to_mfn() only to allow
+ *   for future optimizations.
+ */
+static inline unsigned long __pfn_to_mfn(unsigned long pfn)
+{
+	return get_phys_to_machine(pfn);
+}
+
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
 {
 	unsigned long mfn;
@@ -66,7 +81,7 @@ static inline unsigned long pfn_to_mfn(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return pfn;
 
-	mfn = get_phys_to_machine(pfn);
+	mfn = __pfn_to_mfn(pfn);
 
 	if (mfn != INVALID_P2M_ENTRY)
 		mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
@@ -79,7 +94,7 @@ static inline int phys_to_machine_mapping_valid(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return 1;
 
-	return get_phys_to_machine(pfn) != INVALID_P2M_ENTRY;
+	return __pfn_to_mfn(pfn) != INVALID_P2M_ENTRY;
 }
 
 static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
@@ -113,7 +128,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) != mfn) {
+	if (__pfn_to_mfn(pfn) != mfn) {
 		/*
 		 * If this appears to be a foreign mfn (because the pfn
 		 * doesn't map back to the mfn), then check the local override
@@ -129,8 +144,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 	 * entry doesn't map back to the mfn and m2p_override doesn't have a
 	 * valid entry for it.
 	 */
-	if (pfn == ~0 &&
-			get_phys_to_machine(mfn) == IDENTITY_FRAME(mfn))
+	if (pfn == ~0 && __pfn_to_mfn(mfn) == IDENTITY_FRAME(mfn))
 		pfn = mfn;
 
 	return pfn;
@@ -176,7 +190,7 @@ static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn(mfn);
-	if (get_phys_to_machine(pfn) != mfn)
+	if (__pfn_to_mfn(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
 }
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 601914d..3e3f8f8 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -387,7 +387,7 @@ static pteval_t pte_pfn_to_mfn(pteval_t val)
 		unsigned long mfn;
 
 		if (!xen_feature(XENFEAT_auto_translated_physmap))
-			mfn = get_phys_to_machine(pfn);
+			mfn = __pfn_to_mfn(pfn);
 		else
 			mfn = pfn;
 		/*
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index eddec40..8c3d8fb 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -787,7 +787,7 @@ static int m2p_add_override(unsigned long mfn, struct page *page,
 	 * because mfn_to_pfn (that ends up being called by GUPF) will
 	 * return the backend pfn rather than the frontend pfn. */
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == mfn)
+	if (__pfn_to_mfn(pfn) == mfn)
 		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
 
 	return 0;
@@ -967,7 +967,7 @@ static int m2p_remove_override(struct page *page,
 	 * pfn again. */
 	mfn &= ~FOREIGN_FRAME_BIT;
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
+	if (__pfn_to_mfn(pfn) == FOREIGN_FRAME(mfn) &&
 			m2p_find_override(mfn) == NULL)
 		set_phys_to_machine(pfn, mfn);
 
@@ -992,7 +992,7 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 	}
 
 	for (i = 0; i < count; i++) {
-		unsigned long mfn = get_phys_to_machine(page_to_pfn(pages[i]));
+		unsigned long mfn = __pfn_to_mfn(page_to_pfn(pages[i]));
 		unsigned long pfn = page_to_pfn(pages[i]);
 
 		if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBi-0006Uw-5F; Fri, 28 Nov 2014 10:54:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBg-0006TL-9z
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	14/F5-09842-F4458745; Fri, 28 Nov 2014 10:54:07 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417172046!12070570!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4101 invoked from network); 28 Nov 2014 10:54:07 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:07 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9D0D5ADBE;
	Fri, 28 Nov 2014 10:54:06 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:57 +0100
Message-Id: <1417172039-8627-9-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 08/10] xen: Hide get_phys_to_machine() to be
	able to tune common path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 get_phys_to_machine() is always called when the mfn for a pfn
is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
to be able to avoid calling get_phys_to_machine() when possible as
soon as the switch to a linear mapped p2m list has been done.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/xen/page.h | 26 ++++++++++++++++++++------
 arch/x86/xen/mmu.c              |  2 +-
 arch/x86/xen/p2m.c              |  6 +++---
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 28fa795..410a6ec 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -59,6 +59,21 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct page **pages, unsigned int count);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
+/*
+ * When to use pfn_to_mfn(), __pfn_to_mfn() or get_phys_to_machine():
+ * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. No indicator
+ *   bits (identity or foreign) are set.
+ * - __pfn_to_mfn() returns the found entry of the p2m table. A possibly set
+ *   identity or foreign indicator will be still set. __pfn_to_mfn() is
+ *   encapsulating get_phys_to_machine().
+ * - get_phys_to_machine() is to be called by __pfn_to_mfn() only to allow
+ *   for future optimizations.
+ */
+static inline unsigned long __pfn_to_mfn(unsigned long pfn)
+{
+	return get_phys_to_machine(pfn);
+}
+
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
 {
 	unsigned long mfn;
@@ -66,7 +81,7 @@ static inline unsigned long pfn_to_mfn(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return pfn;
 
-	mfn = get_phys_to_machine(pfn);
+	mfn = __pfn_to_mfn(pfn);
 
 	if (mfn != INVALID_P2M_ENTRY)
 		mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
@@ -79,7 +94,7 @@ static inline int phys_to_machine_mapping_valid(unsigned long pfn)
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return 1;
 
-	return get_phys_to_machine(pfn) != INVALID_P2M_ENTRY;
+	return __pfn_to_mfn(pfn) != INVALID_P2M_ENTRY;
 }
 
 static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
@@ -113,7 +128,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) != mfn) {
+	if (__pfn_to_mfn(pfn) != mfn) {
 		/*
 		 * If this appears to be a foreign mfn (because the pfn
 		 * doesn't map back to the mfn), then check the local override
@@ -129,8 +144,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 	 * entry doesn't map back to the mfn and m2p_override doesn't have a
 	 * valid entry for it.
 	 */
-	if (pfn == ~0 &&
-			get_phys_to_machine(mfn) == IDENTITY_FRAME(mfn))
+	if (pfn == ~0 && __pfn_to_mfn(mfn) == IDENTITY_FRAME(mfn))
 		pfn = mfn;
 
 	return pfn;
@@ -176,7 +190,7 @@ static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 		return mfn;
 
 	pfn = mfn_to_pfn(mfn);
-	if (get_phys_to_machine(pfn) != mfn)
+	if (__pfn_to_mfn(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
 }
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 601914d..3e3f8f8 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -387,7 +387,7 @@ static pteval_t pte_pfn_to_mfn(pteval_t val)
 		unsigned long mfn;
 
 		if (!xen_feature(XENFEAT_auto_translated_physmap))
-			mfn = get_phys_to_machine(pfn);
+			mfn = __pfn_to_mfn(pfn);
 		else
 			mfn = pfn;
 		/*
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index eddec40..8c3d8fb 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -787,7 +787,7 @@ static int m2p_add_override(unsigned long mfn, struct page *page,
 	 * because mfn_to_pfn (that ends up being called by GUPF) will
 	 * return the backend pfn rather than the frontend pfn. */
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == mfn)
+	if (__pfn_to_mfn(pfn) == mfn)
 		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
 
 	return 0;
@@ -967,7 +967,7 @@ static int m2p_remove_override(struct page *page,
 	 * pfn again. */
 	mfn &= ~FOREIGN_FRAME_BIT;
 	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
+	if (__pfn_to_mfn(pfn) == FOREIGN_FRAME(mfn) &&
 			m2p_find_override(mfn) == NULL)
 		set_phys_to_machine(pfn, mfn);
 
@@ -992,7 +992,7 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 	}
 
 	for (i = 0; i < count; i++) {
-		unsigned long mfn = get_phys_to_machine(page_to_pfn(pages[i]));
+		unsigned long mfn = __pfn_to_mfn(page_to_pfn(pages[i]));
 		unsigned long pfn = page_to_pfn(pages[i]);
 
 		if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBg-0006Tl-C3; Fri, 28 Nov 2014 10:54:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBe-0006Qs-If
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:06 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	BA/BD-03145-D4458745; Fri, 28 Nov 2014 10:54:05 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417172044!11696361!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9071 invoked from network); 28 Nov 2014 10:54:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:04 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 43D4DACDE;
	Fri, 28 Nov 2014 10:54:04 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:51 +0100
Message-Id: <1417172039-8627-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 2/9] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some functions in arch/x86/xen/p2m.c are used locally only. Make them
static. Rearrange the functions in p2m.c to avoid forward declarations.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |   6 -
 arch/x86/xen/p2m.c              | 346 ++++++++++++++++++++--------------------
 2 files changed, 172 insertions(+), 180 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c949923..6c16451 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -52,15 +52,9 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 				   struct gnttab_map_grant_ref *kmap_ops,
 				   struct page **pages, unsigned int count);
-extern int m2p_add_override(unsigned long mfn, struct page *page,
-			    struct gnttab_map_grant_ref *kmap_op);
 extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct gnttab_map_grant_ref *kmap_ops,
 				     struct page **pages, unsigned int count);
-extern int m2p_remove_override(struct page *page,
-			       struct gnttab_map_grant_ref *kmap_op,
-			       unsigned long mfn);
-extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 73d354a..2d8b908 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -896,6 +896,61 @@ static unsigned long mfn_hash(unsigned long mfn)
 	return hash_long(mfn, M2P_OVERRIDE_HASH_SHIFT);
 }
 
+/* Add an MFN override for a particular page */
+static int m2p_add_override(unsigned long mfn, struct page *page,
+			    struct gnttab_map_grant_ref *kmap_op)
+{
+	unsigned long flags;
+	unsigned long pfn;
+	unsigned long uninitialized_var(address);
+	unsigned level;
+	pte_t *ptep = NULL;
+
+	pfn = page_to_pfn(page);
+	if (!PageHighMem(page)) {
+		address = (unsigned long)__va(pfn << PAGE_SHIFT);
+		ptep = lookup_address(address, &level);
+		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
+			 "m2p_add_override: pfn %lx not mapped", pfn))
+			return -EINVAL;
+	}
+
+	if (kmap_op != NULL) {
+		if (!PageHighMem(page)) {
+			struct multicall_space mcs =
+				xen_mc_entry(sizeof(*kmap_op));
+
+			MULTI_grant_table_op(mcs.mc,
+					GNTTABOP_map_grant_ref, kmap_op, 1);
+
+			xen_mc_issue(PARAVIRT_LAZY_MMU);
+		}
+	}
+	spin_lock_irqsave(&m2p_override_lock, flags);
+	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	/* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in
+	 * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other
+	 * pfn so that the following mfn_to_pfn(mfn) calls will return the
+	 * pfn from the m2p_override (the backend pfn) instead.
+	 * We need to do this because the pages shared by the frontend
+	 * (xen-blkfront) can be already locked (lock_page, called by
+	 * do_read_cache_page); when the userspace backend tries to use them
+	 * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
+	 * do_blockdev_direct_IO is going to try to lock the same pages
+	 * again resulting in a deadlock.
+	 * As a side effect get_user_pages_fast might not be safe on the
+	 * frontend pages while they are being shared with the backend,
+	 * because mfn_to_pfn (that ends up being called by GUPF) will
+	 * return the backend pfn rather than the frontend pfn. */
+	pfn = mfn_to_pfn_no_overrides(mfn);
+	if (get_phys_to_machine(pfn) == mfn)
+		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
+
+	return 0;
+}
+
 int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 			    struct gnttab_map_grant_ref *kmap_ops,
 			    struct page **pages, unsigned int count)
@@ -955,61 +1010,123 @@ out:
 }
 EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
 
-/* Add an MFN override for a particular page */
-int m2p_add_override(unsigned long mfn, struct page *page,
-		struct gnttab_map_grant_ref *kmap_op)
-{
-	unsigned long flags;
-	unsigned long pfn;
-	unsigned long uninitialized_var(address);
-	unsigned level;
-	pte_t *ptep = NULL;
-
-	pfn = page_to_pfn(page);
-	if (!PageHighMem(page)) {
-		address = (unsigned long)__va(pfn << PAGE_SHIFT);
-		ptep = lookup_address(address, &level);
-		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-			 "m2p_add_override: pfn %lx not mapped", pfn))
-			return -EINVAL;
-	}
-
-	if (kmap_op != NULL) {
-		if (!PageHighMem(page)) {
-			struct multicall_space mcs =
-				xen_mc_entry(sizeof(*kmap_op));
-
-			MULTI_grant_table_op(mcs.mc,
-					GNTTABOP_map_grant_ref, kmap_op, 1);
-
-			xen_mc_issue(PARAVIRT_LAZY_MMU);
-		}
-	}
-	spin_lock_irqsave(&m2p_override_lock, flags);
-	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	/* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in
-	 * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other
-	 * pfn so that the following mfn_to_pfn(mfn) calls will return the
-	 * pfn from the m2p_override (the backend pfn) instead.
-	 * We need to do this because the pages shared by the frontend
-	 * (xen-blkfront) can be already locked (lock_page, called by
-	 * do_read_cache_page); when the userspace backend tries to use them
-	 * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
-	 * do_blockdev_direct_IO is going to try to lock the same pages
-	 * again resulting in a deadlock.
-	 * As a side effect get_user_pages_fast might not be safe on the
-	 * frontend pages while they are being shared with the backend,
-	 * because mfn_to_pfn (that ends up being called by GUPF) will
-	 * return the backend pfn rather than the frontend pfn. */
-	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == mfn)
-		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(m2p_add_override);
+static struct page *m2p_find_override(unsigned long mfn)
+{
+	unsigned long flags;
+	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
+	struct page *p, *ret;
+
+	ret = NULL;
+
+	spin_lock_irqsave(&m2p_override_lock, flags);
+
+	list_for_each_entry(p, bucket, lru) {
+		if (page_private(p) == mfn) {
+			ret = p;
+			break;
+		}
+	}
+
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	return ret;
+}
+
+static int m2p_remove_override(struct page *page,
+			       struct gnttab_map_grant_ref *kmap_op,
+			       unsigned long mfn)
+{
+	unsigned long flags;
+	unsigned long pfn;
+	unsigned long uninitialized_var(address);
+	unsigned level;
+	pte_t *ptep = NULL;
+
+	pfn = page_to_pfn(page);
+
+	if (!PageHighMem(page)) {
+		address = (unsigned long)__va(pfn << PAGE_SHIFT);
+		ptep = lookup_address(address, &level);
+
+		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
+			 "m2p_remove_override: pfn %lx not mapped", pfn))
+			return -EINVAL;
+	}
+
+	spin_lock_irqsave(&m2p_override_lock, flags);
+	list_del(&page->lru);
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	if (kmap_op != NULL) {
+		if (!PageHighMem(page)) {
+			struct multicall_space mcs;
+			struct gnttab_unmap_and_replace *unmap_op;
+			struct page *scratch_page = get_balloon_scratch_page();
+			unsigned long scratch_page_address = (unsigned long)
+				__va(page_to_pfn(scratch_page) << PAGE_SHIFT);
+
+			/*
+			 * It might be that we queued all the m2p grant table
+			 * hypercalls in a multicall, then m2p_remove_override
+			 * get called before the multicall has actually been
+			 * issued. In this case handle is going to -1 because
+			 * it hasn't been modified yet.
+			 */
+			if (kmap_op->handle == -1)
+				xen_mc_flush();
+			/*
+			 * Now if kmap_op->handle is negative it means that the
+			 * hypercall actually returned an error.
+			 */
+			if (kmap_op->handle == GNTST_general_error) {
+				pr_warn("m2p_remove_override: pfn %lx mfn %lx, failed to modify kernel mappings",
+					pfn, mfn);
+				put_balloon_scratch_page();
+				return -1;
+			}
+
+			xen_mc_batch();
+
+			mcs = __xen_mc_entry(
+				sizeof(struct gnttab_unmap_and_replace));
+			unmap_op = mcs.args;
+			unmap_op->host_addr = kmap_op->host_addr;
+			unmap_op->new_addr = scratch_page_address;
+			unmap_op->handle = kmap_op->handle;
+
+			MULTI_grant_table_op(mcs.mc,
+				GNTTABOP_unmap_and_replace, unmap_op, 1);
+
+			mcs = __xen_mc_entry(0);
+			MULTI_update_va_mapping(mcs.mc, scratch_page_address,
+					pfn_pte(page_to_pfn(scratch_page),
+					PAGE_KERNEL_RO), 0);
+
+			xen_mc_issue(PARAVIRT_LAZY_MMU);
+
+			kmap_op->host_addr = 0;
+			put_balloon_scratch_page();
+		}
+	}
+
+	/* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present
+	 * somewhere in this domain, even before being added to the
+	 * m2p_override (see comment above in m2p_add_override).
+	 * If there are no other entries in the m2p_override corresponding
+	 * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for
+	 * the original pfn (the one shared by the frontend): the backend
+	 * cannot do any IO on this page anymore because it has been
+	 * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of
+	 * the original pfn causes mfn_to_pfn(mfn) to return the frontend
+	 * pfn again. */
+	mfn &= ~FOREIGN_FRAME_BIT;
+	pfn = mfn_to_pfn_no_overrides(mfn);
+	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
+			m2p_find_override(mfn) == NULL)
+		set_phys_to_machine(pfn, mfn);
+
+	return 0;
+}
 
 int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 			      struct gnttab_map_grant_ref *kmap_ops,
@@ -1055,125 +1172,6 @@ out:
 }
 EXPORT_SYMBOL_GPL(clear_foreign_p2m_mapping);
 
-int m2p_remove_override(struct page *page,
-			struct gnttab_map_grant_ref *kmap_op,
-			unsigned long mfn)
-{
-	unsigned long flags;
-	unsigned long pfn;
-	unsigned long uninitialized_var(address);
-	unsigned level;
-	pte_t *ptep = NULL;
-
-	pfn = page_to_pfn(page);
-
-	if (!PageHighMem(page)) {
-		address = (unsigned long)__va(pfn << PAGE_SHIFT);
-		ptep = lookup_address(address, &level);
-
-		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-			 "m2p_remove_override: pfn %lx not mapped", pfn))
-			return -EINVAL;
-	}
-
-	spin_lock_irqsave(&m2p_override_lock, flags);
-	list_del(&page->lru);
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	if (kmap_op != NULL) {
-		if (!PageHighMem(page)) {
-			struct multicall_space mcs;
-			struct gnttab_unmap_and_replace *unmap_op;
-			struct page *scratch_page = get_balloon_scratch_page();
-			unsigned long scratch_page_address = (unsigned long)
-				__va(page_to_pfn(scratch_page) << PAGE_SHIFT);
-
-			/*
-			 * It might be that we queued all the m2p grant table
-			 * hypercalls in a multicall, then m2p_remove_override
-			 * get called before the multicall has actually been
-			 * issued. In this case handle is going to -1 because
-			 * it hasn't been modified yet.
-			 */
-			if (kmap_op->handle == -1)
-				xen_mc_flush();
-			/*
-			 * Now if kmap_op->handle is negative it means that the
-			 * hypercall actually returned an error.
-			 */
-			if (kmap_op->handle == GNTST_general_error) {
-				pr_warn("m2p_remove_override: pfn %lx mfn %lx, failed to modify kernel mappings",
-					pfn, mfn);
-				put_balloon_scratch_page();
-				return -1;
-			}
-
-			xen_mc_batch();
-
-			mcs = __xen_mc_entry(
-				sizeof(struct gnttab_unmap_and_replace));
-			unmap_op = mcs.args;
-			unmap_op->host_addr = kmap_op->host_addr;
-			unmap_op->new_addr = scratch_page_address;
-			unmap_op->handle = kmap_op->handle;
-
-			MULTI_grant_table_op(mcs.mc,
-				GNTTABOP_unmap_and_replace, unmap_op, 1);
-
-			mcs = __xen_mc_entry(0);
-			MULTI_update_va_mapping(mcs.mc, scratch_page_address,
-					pfn_pte(page_to_pfn(scratch_page),
-					PAGE_KERNEL_RO), 0);
-
-			xen_mc_issue(PARAVIRT_LAZY_MMU);
-
-			kmap_op->host_addr = 0;
-			put_balloon_scratch_page();
-		}
-	}
-
-	/* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present
-	 * somewhere in this domain, even before being added to the
-	 * m2p_override (see comment above in m2p_add_override).
-	 * If there are no other entries in the m2p_override corresponding
-	 * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for
-	 * the original pfn (the one shared by the frontend): the backend
-	 * cannot do any IO on this page anymore because it has been
-	 * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of
-	 * the original pfn causes mfn_to_pfn(mfn) to return the frontend
-	 * pfn again. */
-	mfn &= ~FOREIGN_FRAME_BIT;
-	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
-			m2p_find_override(mfn) == NULL)
-		set_phys_to_machine(pfn, mfn);
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(m2p_remove_override);
-
-struct page *m2p_find_override(unsigned long mfn)
-{
-	unsigned long flags;
-	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
-	struct page *p, *ret;
-
-	ret = NULL;
-
-	spin_lock_irqsave(&m2p_override_lock, flags);
-
-	list_for_each_entry(p, bucket, lru) {
-		if (page_private(p) == mfn) {
-			ret = p;
-			break;
-		}
-	}
-
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	return ret;
-}
-
 unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
 {
 	struct page *p = m2p_find_override(mfn);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:54:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJBg-0006Tl-C3; Fri, 28 Nov 2014 10:54:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XuJBe-0006Qs-If
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 10:54:06 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	BA/BD-03145-D4458745; Fri, 28 Nov 2014 10:54:05 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417172044!11696361!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9071 invoked from network); 28 Nov 2014 10:54:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 10:54:04 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 43D4DACDE;
	Fri, 28 Nov 2014 10:54:04 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, andrew.cooper3@citrix.com
Date: Fri, 28 Nov 2014 11:53:51 +0100
Message-Id: <1417172039-8627-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH V4 2/9] xen: Make functions static
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some functions in arch/x86/xen/p2m.c are used locally only. Make them
static. Rearrange the functions in p2m.c to avoid forward declarations.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h |   6 -
 arch/x86/xen/p2m.c              | 346 ++++++++++++++++++++--------------------
 2 files changed, 172 insertions(+), 180 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c949923..6c16451 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -52,15 +52,9 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 				   struct gnttab_map_grant_ref *kmap_ops,
 				   struct page **pages, unsigned int count);
-extern int m2p_add_override(unsigned long mfn, struct page *page,
-			    struct gnttab_map_grant_ref *kmap_op);
 extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 				     struct gnttab_map_grant_ref *kmap_ops,
 				     struct page **pages, unsigned int count);
-extern int m2p_remove_override(struct page *page,
-			       struct gnttab_map_grant_ref *kmap_op,
-			       unsigned long mfn);
-extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 73d354a..2d8b908 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -896,6 +896,61 @@ static unsigned long mfn_hash(unsigned long mfn)
 	return hash_long(mfn, M2P_OVERRIDE_HASH_SHIFT);
 }
 
+/* Add an MFN override for a particular page */
+static int m2p_add_override(unsigned long mfn, struct page *page,
+			    struct gnttab_map_grant_ref *kmap_op)
+{
+	unsigned long flags;
+	unsigned long pfn;
+	unsigned long uninitialized_var(address);
+	unsigned level;
+	pte_t *ptep = NULL;
+
+	pfn = page_to_pfn(page);
+	if (!PageHighMem(page)) {
+		address = (unsigned long)__va(pfn << PAGE_SHIFT);
+		ptep = lookup_address(address, &level);
+		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
+			 "m2p_add_override: pfn %lx not mapped", pfn))
+			return -EINVAL;
+	}
+
+	if (kmap_op != NULL) {
+		if (!PageHighMem(page)) {
+			struct multicall_space mcs =
+				xen_mc_entry(sizeof(*kmap_op));
+
+			MULTI_grant_table_op(mcs.mc,
+					GNTTABOP_map_grant_ref, kmap_op, 1);
+
+			xen_mc_issue(PARAVIRT_LAZY_MMU);
+		}
+	}
+	spin_lock_irqsave(&m2p_override_lock, flags);
+	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	/* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in
+	 * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other
+	 * pfn so that the following mfn_to_pfn(mfn) calls will return the
+	 * pfn from the m2p_override (the backend pfn) instead.
+	 * We need to do this because the pages shared by the frontend
+	 * (xen-blkfront) can be already locked (lock_page, called by
+	 * do_read_cache_page); when the userspace backend tries to use them
+	 * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
+	 * do_blockdev_direct_IO is going to try to lock the same pages
+	 * again resulting in a deadlock.
+	 * As a side effect get_user_pages_fast might not be safe on the
+	 * frontend pages while they are being shared with the backend,
+	 * because mfn_to_pfn (that ends up being called by GUPF) will
+	 * return the backend pfn rather than the frontend pfn. */
+	pfn = mfn_to_pfn_no_overrides(mfn);
+	if (get_phys_to_machine(pfn) == mfn)
+		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
+
+	return 0;
+}
+
 int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
 			    struct gnttab_map_grant_ref *kmap_ops,
 			    struct page **pages, unsigned int count)
@@ -955,61 +1010,123 @@ out:
 }
 EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
 
-/* Add an MFN override for a particular page */
-int m2p_add_override(unsigned long mfn, struct page *page,
-		struct gnttab_map_grant_ref *kmap_op)
-{
-	unsigned long flags;
-	unsigned long pfn;
-	unsigned long uninitialized_var(address);
-	unsigned level;
-	pte_t *ptep = NULL;
-
-	pfn = page_to_pfn(page);
-	if (!PageHighMem(page)) {
-		address = (unsigned long)__va(pfn << PAGE_SHIFT);
-		ptep = lookup_address(address, &level);
-		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-			 "m2p_add_override: pfn %lx not mapped", pfn))
-			return -EINVAL;
-	}
-
-	if (kmap_op != NULL) {
-		if (!PageHighMem(page)) {
-			struct multicall_space mcs =
-				xen_mc_entry(sizeof(*kmap_op));
-
-			MULTI_grant_table_op(mcs.mc,
-					GNTTABOP_map_grant_ref, kmap_op, 1);
-
-			xen_mc_issue(PARAVIRT_LAZY_MMU);
-		}
-	}
-	spin_lock_irqsave(&m2p_override_lock, flags);
-	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	/* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in
-	 * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other
-	 * pfn so that the following mfn_to_pfn(mfn) calls will return the
-	 * pfn from the m2p_override (the backend pfn) instead.
-	 * We need to do this because the pages shared by the frontend
-	 * (xen-blkfront) can be already locked (lock_page, called by
-	 * do_read_cache_page); when the userspace backend tries to use them
-	 * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
-	 * do_blockdev_direct_IO is going to try to lock the same pages
-	 * again resulting in a deadlock.
-	 * As a side effect get_user_pages_fast might not be safe on the
-	 * frontend pages while they are being shared with the backend,
-	 * because mfn_to_pfn (that ends up being called by GUPF) will
-	 * return the backend pfn rather than the frontend pfn. */
-	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == mfn)
-		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(m2p_add_override);
+static struct page *m2p_find_override(unsigned long mfn)
+{
+	unsigned long flags;
+	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
+	struct page *p, *ret;
+
+	ret = NULL;
+
+	spin_lock_irqsave(&m2p_override_lock, flags);
+
+	list_for_each_entry(p, bucket, lru) {
+		if (page_private(p) == mfn) {
+			ret = p;
+			break;
+		}
+	}
+
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	return ret;
+}
+
+static int m2p_remove_override(struct page *page,
+			       struct gnttab_map_grant_ref *kmap_op,
+			       unsigned long mfn)
+{
+	unsigned long flags;
+	unsigned long pfn;
+	unsigned long uninitialized_var(address);
+	unsigned level;
+	pte_t *ptep = NULL;
+
+	pfn = page_to_pfn(page);
+
+	if (!PageHighMem(page)) {
+		address = (unsigned long)__va(pfn << PAGE_SHIFT);
+		ptep = lookup_address(address, &level);
+
+		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
+			 "m2p_remove_override: pfn %lx not mapped", pfn))
+			return -EINVAL;
+	}
+
+	spin_lock_irqsave(&m2p_override_lock, flags);
+	list_del(&page->lru);
+	spin_unlock_irqrestore(&m2p_override_lock, flags);
+
+	if (kmap_op != NULL) {
+		if (!PageHighMem(page)) {
+			struct multicall_space mcs;
+			struct gnttab_unmap_and_replace *unmap_op;
+			struct page *scratch_page = get_balloon_scratch_page();
+			unsigned long scratch_page_address = (unsigned long)
+				__va(page_to_pfn(scratch_page) << PAGE_SHIFT);
+
+			/*
+			 * It might be that we queued all the m2p grant table
+			 * hypercalls in a multicall, then m2p_remove_override
+			 * get called before the multicall has actually been
+			 * issued. In this case handle is going to -1 because
+			 * it hasn't been modified yet.
+			 */
+			if (kmap_op->handle == -1)
+				xen_mc_flush();
+			/*
+			 * Now if kmap_op->handle is negative it means that the
+			 * hypercall actually returned an error.
+			 */
+			if (kmap_op->handle == GNTST_general_error) {
+				pr_warn("m2p_remove_override: pfn %lx mfn %lx, failed to modify kernel mappings",
+					pfn, mfn);
+				put_balloon_scratch_page();
+				return -1;
+			}
+
+			xen_mc_batch();
+
+			mcs = __xen_mc_entry(
+				sizeof(struct gnttab_unmap_and_replace));
+			unmap_op = mcs.args;
+			unmap_op->host_addr = kmap_op->host_addr;
+			unmap_op->new_addr = scratch_page_address;
+			unmap_op->handle = kmap_op->handle;
+
+			MULTI_grant_table_op(mcs.mc,
+				GNTTABOP_unmap_and_replace, unmap_op, 1);
+
+			mcs = __xen_mc_entry(0);
+			MULTI_update_va_mapping(mcs.mc, scratch_page_address,
+					pfn_pte(page_to_pfn(scratch_page),
+					PAGE_KERNEL_RO), 0);
+
+			xen_mc_issue(PARAVIRT_LAZY_MMU);
+
+			kmap_op->host_addr = 0;
+			put_balloon_scratch_page();
+		}
+	}
+
+	/* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present
+	 * somewhere in this domain, even before being added to the
+	 * m2p_override (see comment above in m2p_add_override).
+	 * If there are no other entries in the m2p_override corresponding
+	 * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for
+	 * the original pfn (the one shared by the frontend): the backend
+	 * cannot do any IO on this page anymore because it has been
+	 * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of
+	 * the original pfn causes mfn_to_pfn(mfn) to return the frontend
+	 * pfn again. */
+	mfn &= ~FOREIGN_FRAME_BIT;
+	pfn = mfn_to_pfn_no_overrides(mfn);
+	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
+			m2p_find_override(mfn) == NULL)
+		set_phys_to_machine(pfn, mfn);
+
+	return 0;
+}
 
 int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 			      struct gnttab_map_grant_ref *kmap_ops,
@@ -1055,125 +1172,6 @@ out:
 }
 EXPORT_SYMBOL_GPL(clear_foreign_p2m_mapping);
 
-int m2p_remove_override(struct page *page,
-			struct gnttab_map_grant_ref *kmap_op,
-			unsigned long mfn)
-{
-	unsigned long flags;
-	unsigned long pfn;
-	unsigned long uninitialized_var(address);
-	unsigned level;
-	pte_t *ptep = NULL;
-
-	pfn = page_to_pfn(page);
-
-	if (!PageHighMem(page)) {
-		address = (unsigned long)__va(pfn << PAGE_SHIFT);
-		ptep = lookup_address(address, &level);
-
-		if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-			 "m2p_remove_override: pfn %lx not mapped", pfn))
-			return -EINVAL;
-	}
-
-	spin_lock_irqsave(&m2p_override_lock, flags);
-	list_del(&page->lru);
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	if (kmap_op != NULL) {
-		if (!PageHighMem(page)) {
-			struct multicall_space mcs;
-			struct gnttab_unmap_and_replace *unmap_op;
-			struct page *scratch_page = get_balloon_scratch_page();
-			unsigned long scratch_page_address = (unsigned long)
-				__va(page_to_pfn(scratch_page) << PAGE_SHIFT);
-
-			/*
-			 * It might be that we queued all the m2p grant table
-			 * hypercalls in a multicall, then m2p_remove_override
-			 * get called before the multicall has actually been
-			 * issued. In this case handle is going to -1 because
-			 * it hasn't been modified yet.
-			 */
-			if (kmap_op->handle == -1)
-				xen_mc_flush();
-			/*
-			 * Now if kmap_op->handle is negative it means that the
-			 * hypercall actually returned an error.
-			 */
-			if (kmap_op->handle == GNTST_general_error) {
-				pr_warn("m2p_remove_override: pfn %lx mfn %lx, failed to modify kernel mappings",
-					pfn, mfn);
-				put_balloon_scratch_page();
-				return -1;
-			}
-
-			xen_mc_batch();
-
-			mcs = __xen_mc_entry(
-				sizeof(struct gnttab_unmap_and_replace));
-			unmap_op = mcs.args;
-			unmap_op->host_addr = kmap_op->host_addr;
-			unmap_op->new_addr = scratch_page_address;
-			unmap_op->handle = kmap_op->handle;
-
-			MULTI_grant_table_op(mcs.mc,
-				GNTTABOP_unmap_and_replace, unmap_op, 1);
-
-			mcs = __xen_mc_entry(0);
-			MULTI_update_va_mapping(mcs.mc, scratch_page_address,
-					pfn_pte(page_to_pfn(scratch_page),
-					PAGE_KERNEL_RO), 0);
-
-			xen_mc_issue(PARAVIRT_LAZY_MMU);
-
-			kmap_op->host_addr = 0;
-			put_balloon_scratch_page();
-		}
-	}
-
-	/* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present
-	 * somewhere in this domain, even before being added to the
-	 * m2p_override (see comment above in m2p_add_override).
-	 * If there are no other entries in the m2p_override corresponding
-	 * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for
-	 * the original pfn (the one shared by the frontend): the backend
-	 * cannot do any IO on this page anymore because it has been
-	 * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of
-	 * the original pfn causes mfn_to_pfn(mfn) to return the frontend
-	 * pfn again. */
-	mfn &= ~FOREIGN_FRAME_BIT;
-	pfn = mfn_to_pfn_no_overrides(mfn);
-	if (get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
-			m2p_find_override(mfn) == NULL)
-		set_phys_to_machine(pfn, mfn);
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(m2p_remove_override);
-
-struct page *m2p_find_override(unsigned long mfn)
-{
-	unsigned long flags;
-	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
-	struct page *p, *ret;
-
-	ret = NULL;
-
-	spin_lock_irqsave(&m2p_override_lock, flags);
-
-	list_for_each_entry(p, bucket, lru) {
-		if (page_private(p) == mfn) {
-			ret = p;
-			break;
-		}
-	}
-
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
-	return ret;
-}
-
 unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn)
 {
 	struct page *p = m2p_find_override(mfn);
-- 
2.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:58:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJG2-00084B-6L; Fri, 28 Nov 2014 10:58:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liangx.z.li@intel.com>) id 1XuJG1-00083y-3h
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:58:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D3/BA-25276-C5558745; Fri, 28 Nov 2014 10:58:36 +0000
X-Env-Sender: liangx.z.li@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417172315!12033493!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25763 invoked from network); 28 Nov 2014 10:58:35 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-21.messagelabs.com with SMTP;
	28 Nov 2014 10:58:35 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 28 Nov 2014 02:56:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,476,1413270000"; d="scan'208";a="644965149"
Received: from lil.sh.intel.com (HELO localhost) ([10.239.36.68])
	by orsmga002.jf.intel.com with ESMTP; 28 Nov 2014 02:58:30 -0800
From: Liang Li <liang.z.li@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 18:52:05 +0800
Message-Id: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Liang Li <liang.z.li@intel.com>, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, andrew.cooper3@citrix.com, yang.z.zhang@intel.com
Subject: [Xen-devel] [v4] libxc: Expose the 1GB pages cpuid flag to 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>
MIME-Version: 1.0
Content-Type: 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 hardware support the 1GB pages, expose the feature to guest by
default. Users don't have to use a 'cpuid= ' option in config fil
e to turn it on.

If guest use shadow mode, the 1GB pages feature will be hidden from
guest, this is done in the function hvm_cpuid(). So the change is
okay for shadow mode case.

Signed-off-by: Liang Li <liang.z.li@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
---
 tools/libxc/xc_cpuid_x86.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index a18b1ff..c97f91a 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -109,6 +109,7 @@ static void amd_xc_cpuid_policy(
         regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */
                     bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_MP) |
                     bitmaskof(X86_FEATURE_MMXEXT) |
@@ -192,6 +193,7 @@ static void intel_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_ABM));
         regs[3] &= (bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_RDTSCP));
         break;
@@ -386,6 +388,7 @@ static void xc_cpuid_hvm_policy(
             clear_bit(X86_FEATURE_LM, regs[3]);
             clear_bit(X86_FEATURE_NX, regs[3]);
             clear_bit(X86_FEATURE_PSE36, regs[3]);
+            clear_bit(X86_FEATURE_PAGE1GB, regs[3]);
         }
         break;
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 10:58:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 10:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJG2-00084B-6L; Fri, 28 Nov 2014 10:58:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liangx.z.li@intel.com>) id 1XuJG1-00083y-3h
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 10:58:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D3/BA-25276-C5558745; Fri, 28 Nov 2014 10:58:36 +0000
X-Env-Sender: liangx.z.li@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417172315!12033493!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25763 invoked from network); 28 Nov 2014 10:58:35 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-21.messagelabs.com with SMTP;
	28 Nov 2014 10:58:35 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 28 Nov 2014 02:56:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,476,1413270000"; d="scan'208";a="644965149"
Received: from lil.sh.intel.com (HELO localhost) ([10.239.36.68])
	by orsmga002.jf.intel.com with ESMTP; 28 Nov 2014 02:58:30 -0800
From: Liang Li <liang.z.li@intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 28 Nov 2014 18:52:05 +0800
Message-Id: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	Liang Li <liang.z.li@intel.com>, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, andrew.cooper3@citrix.com, yang.z.zhang@intel.com
Subject: [Xen-devel] [v4] libxc: Expose the 1GB pages cpuid flag to 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>
MIME-Version: 1.0
Content-Type: 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 hardware support the 1GB pages, expose the feature to guest by
default. Users don't have to use a 'cpuid= ' option in config fil
e to turn it on.

If guest use shadow mode, the 1GB pages feature will be hidden from
guest, this is done in the function hvm_cpuid(). So the change is
okay for shadow mode case.

Signed-off-by: Liang Li <liang.z.li@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
---
 tools/libxc/xc_cpuid_x86.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index a18b1ff..c97f91a 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -109,6 +109,7 @@ static void amd_xc_cpuid_policy(
         regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */
                     bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_MP) |
                     bitmaskof(X86_FEATURE_MMXEXT) |
@@ -192,6 +193,7 @@ static void intel_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_ABM));
         regs[3] &= (bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_RDTSCP));
         break;
@@ -386,6 +388,7 @@ static void xc_cpuid_hvm_policy(
             clear_bit(X86_FEATURE_LM, regs[3]);
             clear_bit(X86_FEATURE_NX, regs[3]);
             clear_bit(X86_FEATURE_PSE36, regs[3]);
+            clear_bit(X86_FEATURE_PAGE1GB, regs[3]);
         }
         break;
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:07:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11: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 1XuJOO-0000Ap-5L; Fri, 28 Nov 2014 11:07: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 1XuJOL-0000Ak-WC
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:07:14 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	F7/21-31453-16758745; Fri, 28 Nov 2014 11:07:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417172831!13824030!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17409 invoked from network); 28 Nov 2014 11:07:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:07:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197694478"
Message-ID: <1417172829.19852.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 28 Nov 2014 11:07:09 +0000
In-Reply-To: <1411550049.1781.152.camel@kazak.uk.xensource.com>
References: <1411417398-19194-1-git-send-email-dgdegra@tycho.nsa.gov>
	<20140923090148.GA20691@zion.uk.xensource.com>
	<20140923093753.GB20691@zion.uk.xensource.com>
	<1411486209.1781.67.camel@kazak.uk.xensource.com>
	<5421DAD1.1000700@tycho.nsa.gov>
	<1411550049.1781.152.camel@kazak.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] flask/policy: Updates for example
 XSM policy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-09-24 at 10:14 +0100, Ian Campbell wrote:
> On Tue, 2014-09-23 at 16:40 -0400, Daniel De Graaf wrote:
> > On 09/23/2014 11:30 AM, Ian Campbell wrote:
> > > On Tue, 2014-09-23 at 10:37 +0100, Wei Liu wrote:
> > >> On Tue, Sep 23, 2014 at 10:01:48AM +0100, Wei Liu wrote:
> > >>> On Mon, Sep 22, 2014 at 04:23:18PM -0400, Daniel De Graaf wrote:
> > >>>> The example XSM policy was missing permission for dom0_t to migrate
> > >>>> domains with label domU_t; add these permissions.
> > >
> > > Daniel, would you prefer to iterate until a full batch of fixes or shall
> > > I apply and expect "More updates for example XSM policy" later on?
> > >
> > 
> > I would prefer to iterate and apply the full set.
> 
> Ack.

I've just spotted this in my queue, did this full set ever happen? I
don't see it in tree of in my queue folder. Maybe the issue went away
some other way?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:07:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11: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 1XuJOO-0000Ap-5L; Fri, 28 Nov 2014 11:07: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 1XuJOL-0000Ak-WC
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:07:14 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	F7/21-31453-16758745; Fri, 28 Nov 2014 11:07:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417172831!13824030!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17409 invoked from network); 28 Nov 2014 11:07:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:07:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197694478"
Message-ID: <1417172829.19852.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 28 Nov 2014 11:07:09 +0000
In-Reply-To: <1411550049.1781.152.camel@kazak.uk.xensource.com>
References: <1411417398-19194-1-git-send-email-dgdegra@tycho.nsa.gov>
	<20140923090148.GA20691@zion.uk.xensource.com>
	<20140923093753.GB20691@zion.uk.xensource.com>
	<1411486209.1781.67.camel@kazak.uk.xensource.com>
	<5421DAD1.1000700@tycho.nsa.gov>
	<1411550049.1781.152.camel@kazak.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] flask/policy: Updates for example
 XSM policy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-09-24 at 10:14 +0100, Ian Campbell wrote:
> On Tue, 2014-09-23 at 16:40 -0400, Daniel De Graaf wrote:
> > On 09/23/2014 11:30 AM, Ian Campbell wrote:
> > > On Tue, 2014-09-23 at 10:37 +0100, Wei Liu wrote:
> > >> On Tue, Sep 23, 2014 at 10:01:48AM +0100, Wei Liu wrote:
> > >>> On Mon, Sep 22, 2014 at 04:23:18PM -0400, Daniel De Graaf wrote:
> > >>>> The example XSM policy was missing permission for dom0_t to migrate
> > >>>> domains with label domU_t; add these permissions.
> > >
> > > Daniel, would you prefer to iterate until a full batch of fixes or shall
> > > I apply and expect "More updates for example XSM policy" later on?
> > >
> > 
> > I would prefer to iterate and apply the full set.
> 
> Ack.

I've just spotted this in my queue, did this full set ever happen? I
don't see it in tree of in my queue folder. Maybe the issue went away
some other way?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:31:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJlh-0000lt-KT; Fri, 28 Nov 2014 11:31:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuJlg-0000lo-9n
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:31:20 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	66/76-14727-70D58745; Fri, 28 Nov 2014 11:31:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417174278!9730566!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22509 invoked from network); 28 Nov 2014 11:31:19 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2014 11:31:19 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 11:31:18 +0000
Message-Id: <54786B17020000780004B632@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 11:31:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liang Li" <liang.z.li@intel.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
In-Reply-To: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v4] libxc: Expose the 1GB pages cpuid flag to 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 28.11.14 at 11:52, <liang.z.li@intel.com> wrote:
> If hardware support the 1GB pages, expose the feature to guest by
> default. Users don't have to use a 'cpuid= ' option in config fil
> e to turn it on.
> 
> If guest use shadow mode, the 1GB pages feature will be hidden from
> guest, this is done in the function hvm_cpuid(). So the change is
> okay for shadow mode case.
> 
> Signed-off-by: Liang Li <liang.z.li@intel.com>
> Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:31:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJlr-0000mO-0K; Fri, 28 Nov 2014 11:31:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuJlp-0000mF-GF
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:31:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	16/B3-09842-01D58745; Fri, 28 Nov 2014 11:31:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417174286!12099816!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19830 invoked from network); 28 Nov 2014 11:31:28 -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;
	28 Nov 2014 11:31:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197700273"
Message-ID: <1417174284.23604.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 11:31:24 +0000
In-Reply-To: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 11:11 -0500, Boris Ostrovsky wrote:
> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> parse bootloader configuration files.
> 
> c/s d1b93ea itself changed an an interface which previously used exclusively
> integers, to using strings in the case of a grub configuration with explicit
> default set, along with changing the code calling the interface to require a
> string.  The default value for "default" remained as an integer.
> 
> As a result, any Extlinux or Lilo configuration (which drives this interface
> exclusively with integers), or Grub configuration which doesn't explicitly
> declare a default will die with an AttributeError when attempting to call
> "self.cf.default.isdigit()" where "default" is an integer.
> 
> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
> which searches partitions for valid bootloader configurations, causing the
> issue to be reported as "Unable to find partition containing kernel"
> 
> We should explicitly check type of "default" in image_index() and process it
> appropriately.
> 
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

In general I would prefer the first line of the commit message to be a
short description of the actual functional change and not a reference to
fixing some other commit, which is basically meaningless to anyone
reading the log even now, nevermind in six months. I think I'm going to
start picking up on this more frequently from now on.

CCing Konrad for RM input. I'm much less worried about corner cases etc
wrt the freeze etc than I was with the larger fix proposed earlier.

> ---
> 
> Commit message is Andrew's with exception of the last sentense.
> 
> I only tested this with grub2.
> 
> -boris
> 
>  tools/pygrub/src/pygrub |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>  mode change 100644 => 100755 tools/pygrub/src/pygrub
> 
> diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> old mode 100644
> new mode 100755
> index aa7e562..3ec52fd
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -457,7 +457,9 @@ class Grub:
>          self.cf.parse(buf)
>  
>      def image_index(self):
> -        if self.cf.default.isdigit():
> +        if isinstance(self.cf.default, int):
> +            sel = self.cf.default
> +        elif self.cf.default.isdigit():
>              sel = int(self.cf.default)
>          else:
>              # We don't fully support submenus. Look for the leaf value in



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:31:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJlh-0000lt-KT; Fri, 28 Nov 2014 11:31:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuJlg-0000lo-9n
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:31:20 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	66/76-14727-70D58745; Fri, 28 Nov 2014 11:31:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417174278!9730566!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22509 invoked from network); 28 Nov 2014 11:31:19 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2014 11:31:19 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 11:31:18 +0000
Message-Id: <54786B17020000780004B632@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 11:31:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liang Li" <liang.z.li@intel.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
In-Reply-To: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v4] libxc: Expose the 1GB pages cpuid flag to 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 28.11.14 at 11:52, <liang.z.li@intel.com> wrote:
> If hardware support the 1GB pages, expose the feature to guest by
> default. Users don't have to use a 'cpuid= ' option in config fil
> e to turn it on.
> 
> If guest use shadow mode, the 1GB pages feature will be hidden from
> guest, this is done in the function hvm_cpuid(). So the change is
> okay for shadow mode case.
> 
> Signed-off-by: Liang Li <liang.z.li@intel.com>
> Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:31:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJlr-0000mO-0K; Fri, 28 Nov 2014 11:31:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuJlp-0000mF-GF
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:31:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	16/B3-09842-01D58745; Fri, 28 Nov 2014 11:31:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417174286!12099816!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19830 invoked from network); 28 Nov 2014 11:31:28 -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;
	28 Nov 2014 11:31:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197700273"
Message-ID: <1417174284.23604.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 11:31:24 +0000
In-Reply-To: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] pygrub: Fix regression from c/s
 d1b93ea, attempt 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 11:11 -0500, Boris Ostrovsky wrote:
> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> parse bootloader configuration files.
> 
> c/s d1b93ea itself changed an an interface which previously used exclusively
> integers, to using strings in the case of a grub configuration with explicit
> default set, along with changing the code calling the interface to require a
> string.  The default value for "default" remained as an integer.
> 
> As a result, any Extlinux or Lilo configuration (which drives this interface
> exclusively with integers), or Grub configuration which doesn't explicitly
> declare a default will die with an AttributeError when attempting to call
> "self.cf.default.isdigit()" where "default" is an integer.
> 
> Sadly, this AttributeError gets swallowed by the blanket ignore in the loop
> which searches partitions for valid bootloader configurations, causing the
> issue to be reported as "Unable to find partition containing kernel"
> 
> We should explicitly check type of "default" in image_index() and process it
> appropriately.
> 
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

In general I would prefer the first line of the commit message to be a
short description of the actual functional change and not a reference to
fixing some other commit, which is basically meaningless to anyone
reading the log even now, nevermind in six months. I think I'm going to
start picking up on this more frequently from now on.

CCing Konrad for RM input. I'm much less worried about corner cases etc
wrt the freeze etc than I was with the larger fix proposed earlier.

> ---
> 
> Commit message is Andrew's with exception of the last sentense.
> 
> I only tested this with grub2.
> 
> -boris
> 
>  tools/pygrub/src/pygrub |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>  mode change 100644 => 100755 tools/pygrub/src/pygrub
> 
> diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> old mode 100644
> new mode 100755
> index aa7e562..3ec52fd
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -457,7 +457,9 @@ class Grub:
>          self.cf.parse(buf)
>  
>      def image_index(self):
> -        if self.cf.default.isdigit():
> +        if isinstance(self.cf.default, int):
> +            sel = self.cf.default
> +        elif self.cf.default.isdigit():
>              sel = int(self.cf.default)
>          else:
>              # We don't fully support submenus. Look for the leaf value in



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:32:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:32:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJmQ-0000yl-DT; Fri, 28 Nov 2014 11:32:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuJmO-0000xa-LU
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:32:04 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	1D/F4-03148-43D58745; Fri, 28 Nov 2014 11:32:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417174322!11736610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25804 invoked from network); 28 Nov 2014 11:32:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:32:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197423808"
Message-ID: <1417174320.23604.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 28 Nov 2014 11:32:00 +0000
In-Reply-To: <1417091674-8163-4-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-4-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 3/3] python/xs: Correct the
 indirection of the NULL xshandle() 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 Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:
> The code now now matches its comment, and will actually catch the case of a
> bad xs handle.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Coverity-ID: 1055948
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Xen Coverity Team <coverity@xen.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/python/xen/lowlevel/xs/xs.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/python/xen/lowlevel/xs/xs.c b/tools/python/xen/lowlevel/xs/xs.c
> index 84e1711..ec364bb 100644
> --- a/tools/python/xen/lowlevel/xs/xs.c
> +++ b/tools/python/xen/lowlevel/xs/xs.c
> @@ -816,7 +816,7 @@ static int parse_transaction_path(XsHandle *self, PyObject *args,
>  
>      *xh = xshandle(self);
>  
> -    if (!xh)
> +    if (!*xh)
>          return 0;
>  
>      if (!PyArg_ParseTuple(args, "ss", &thstr, path))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:32:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:32:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJmQ-0000yl-DT; Fri, 28 Nov 2014 11:32:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuJmO-0000xa-LU
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:32:04 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	1D/F4-03148-43D58745; Fri, 28 Nov 2014 11:32:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417174322!11736610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25804 invoked from network); 28 Nov 2014 11:32:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:32:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197423808"
Message-ID: <1417174320.23604.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 28 Nov 2014 11:32:00 +0000
In-Reply-To: <1417091674-8163-4-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-4-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 3/3] python/xs: Correct the
 indirection of the NULL xshandle() 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 Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:
> The code now now matches its comment, and will actually catch the case of a
> bad xs handle.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Coverity-ID: 1055948
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Xen Coverity Team <coverity@xen.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/python/xen/lowlevel/xs/xs.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/python/xen/lowlevel/xs/xs.c b/tools/python/xen/lowlevel/xs/xs.c
> index 84e1711..ec364bb 100644
> --- a/tools/python/xen/lowlevel/xs/xs.c
> +++ b/tools/python/xen/lowlevel/xs/xs.c
> @@ -816,7 +816,7 @@ static int parse_transaction_path(XsHandle *self, PyObject *args,
>  
>      *xh = xshandle(self);
>  
> -    if (!xh)
> +    if (!*xh)
>          return 0;
>  
>      if (!PyArg_ParseTuple(args, "ss", &thstr, path))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:36:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:36:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJqv-0001TC-4k; Fri, 28 Nov 2014 11:36:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XuJqt-0001T5-Mi
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:36:43 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	BB/80-25727-B4E58745; Fri, 28 Nov 2014 11:36:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417174600!12035213!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19517 invoked from network); 28 Nov 2014 11:36:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:36:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197424710"
Message-ID: <54785E46.4080107@citrix.com>
Date: Fri, 28 Nov 2014 11:36:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I have finally worked out why XenServer is having issues with its legacy
windows drivers and Xen-4.5.

XenServer needs to support hvm ops with an indicies of 0x102 and 0x103
to prevent our legacy windows drivers from BSODing on boot.  (These
problems will disappear when we can drop Windows XP/Server 2k3 support,
but that time is not now.)

The root cause of the breakage is c/s e8b87b57b "x86/HVM: fix preemption
handling in do_hvm_op() (try 2)", and in particular the HVMOP_op_mask,
which turns the above hypercalls into HVMOP_set_{pci_intx,isa_irq}_level
hypercalls.


>From my point of view, I can work around this with the knowledge that
HVMOP_set_{pci_intx,isa_irq}_level hypercalls are not eligible for
pre-emption.

However, it occurs to me that HVMOP_op_mask absolutely must live in the
public header files, as it is guest visible, and forms part of the ABI.

Consider a userspace task which falls into a continuation, is preempted
and paused by the guest kernel, the entire VM migrated, and the task
unpaused later.  If HVMOP_op_mask has changed in that time, the
continuation will become erroneous.

In particular, all hypercall continuation strategies we use *must* be
forward compatible when moving to newer versions of Xen, because Xen
cannot possibly guarantee that a continuation which starts will finish
on the same hypervisor.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:36:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:36:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJqv-0001TC-4k; Fri, 28 Nov 2014 11:36:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XuJqt-0001T5-Mi
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:36:43 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	BB/80-25727-B4E58745; Fri, 28 Nov 2014 11:36:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417174600!12035213!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19517 invoked from network); 28 Nov 2014 11:36:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:36:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197424710"
Message-ID: <54785E46.4080107@citrix.com>
Date: Fri, 28 Nov 2014 11:36:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I have finally worked out why XenServer is having issues with its legacy
windows drivers and Xen-4.5.

XenServer needs to support hvm ops with an indicies of 0x102 and 0x103
to prevent our legacy windows drivers from BSODing on boot.  (These
problems will disappear when we can drop Windows XP/Server 2k3 support,
but that time is not now.)

The root cause of the breakage is c/s e8b87b57b "x86/HVM: fix preemption
handling in do_hvm_op() (try 2)", and in particular the HVMOP_op_mask,
which turns the above hypercalls into HVMOP_set_{pci_intx,isa_irq}_level
hypercalls.


>From my point of view, I can work around this with the knowledge that
HVMOP_set_{pci_intx,isa_irq}_level hypercalls are not eligible for
pre-emption.

However, it occurs to me that HVMOP_op_mask absolutely must live in the
public header files, as it is guest visible, and forms part of the ABI.

Consider a userspace task which falls into a continuation, is preempted
and paused by the guest kernel, the entire VM migrated, and the task
unpaused later.  If HVMOP_op_mask has changed in that time, the
continuation will become erroneous.

In particular, all hypercall continuation strategies we use *must* be
forward compatible when moving to newer versions of Xen, because Xen
cannot possibly guarantee that a continuation which starts will finish
on the same hypervisor.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:37:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11: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 1XuJrG-0001VF-HE; Fri, 28 Nov 2014 11:37:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuJrE-0001V2-Ty
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:37:05 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	06/9F-15461-06E58745; Fri, 28 Nov 2014 11:37:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417174622!4042146!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27725 invoked from network); 28 Nov 2014 11:37:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:37:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197701609"
Message-ID: <1417174620.23604.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 28 Nov 2014 11:37:00 +0000
In-Reply-To: <1417091674-8163-2-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-2-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 1/3] python/xc: Fix multiple issues
 in pyflask_context_to_sid()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:
> The error handling from a failed memory allocation should return
> PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and continuing
> to the memcpy() below, with the dest pointer being NULL.
> 
> Furthermore, the context string is simply an input parameter to the hypercall,
> and is not mutated anywhere along the way.  The error handling elsewhere in
> the function can be simplified by not duplicating it to start with.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Coverity-IDs: 1055305 1055721
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Xen Coverity Team <coverity@xen.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

This would have been far more obviously correct for 4.5 if you had stuck
to fixing the issue in the first paragraph.

> ---
>  tools/python/xen/lowlevel/xc/xc.c |   21 +++------------------
>  1 file changed, 3 insertions(+), 18 deletions(-)
> 
> diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
> index d95d459..c70b388 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -2126,8 +2126,6 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
>  {
>      xc_interface *xc_handle;
>      char *ctx;
> -    char *buf;
> -    uint32_t len;
>      uint32_t sid;
>      int ret;
>  
> @@ -2137,28 +2135,15 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
>                                        &ctx) )
>          return NULL;
>  
> -    len = strlen(ctx);
> -
> -    buf = malloc(len);
> -    if (!buf) {
> -        errno = -ENOMEM;
> -        PyErr_SetFromErrno(xc_error_obj);
> -    }
> -    
> -    memcpy(buf, ctx, len);
> -    
>      xc_handle = xc_interface_open(0,0,0);
>      if (!xc_handle) {
> -        free(buf);
>          return PyErr_SetFromErrno(xc_error_obj);
>      }
> -    
> -    ret = xc_flask_context_to_sid(xc_handle, buf, len, &sid);
> -        
> +
> +    ret = xc_flask_context_to_sid(xc_handle, ctx, strlen(ctx), &sid);
> +
>      xc_interface_close(xc_handle);
>  
> -    free(buf);
> -    
>      if ( ret != 0 ) {
>          errno = -ret;
>          return PyErr_SetFromErrno(xc_error_obj);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:37:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11: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 1XuJrG-0001VF-HE; Fri, 28 Nov 2014 11:37:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuJrE-0001V2-Ty
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:37:05 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	06/9F-15461-06E58745; Fri, 28 Nov 2014 11:37:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417174622!4042146!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27725 invoked from network); 28 Nov 2014 11:37:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:37:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197701609"
Message-ID: <1417174620.23604.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 28 Nov 2014 11:37:00 +0000
In-Reply-To: <1417091674-8163-2-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-2-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 1/3] python/xc: Fix multiple issues
 in pyflask_context_to_sid()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:
> The error handling from a failed memory allocation should return
> PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and continuing
> to the memcpy() below, with the dest pointer being NULL.
> 
> Furthermore, the context string is simply an input parameter to the hypercall,
> and is not mutated anywhere along the way.  The error handling elsewhere in
> the function can be simplified by not duplicating it to start with.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Coverity-IDs: 1055305 1055721
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Xen Coverity Team <coverity@xen.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

This would have been far more obviously correct for 4.5 if you had stuck
to fixing the issue in the first paragraph.

> ---
>  tools/python/xen/lowlevel/xc/xc.c |   21 +++------------------
>  1 file changed, 3 insertions(+), 18 deletions(-)
> 
> diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
> index d95d459..c70b388 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -2126,8 +2126,6 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
>  {
>      xc_interface *xc_handle;
>      char *ctx;
> -    char *buf;
> -    uint32_t len;
>      uint32_t sid;
>      int ret;
>  
> @@ -2137,28 +2135,15 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
>                                        &ctx) )
>          return NULL;
>  
> -    len = strlen(ctx);
> -
> -    buf = malloc(len);
> -    if (!buf) {
> -        errno = -ENOMEM;
> -        PyErr_SetFromErrno(xc_error_obj);
> -    }
> -    
> -    memcpy(buf, ctx, len);
> -    
>      xc_handle = xc_interface_open(0,0,0);
>      if (!xc_handle) {
> -        free(buf);
>          return PyErr_SetFromErrno(xc_error_obj);
>      }
> -    
> -    ret = xc_flask_context_to_sid(xc_handle, buf, len, &sid);
> -        
> +
> +    ret = xc_flask_context_to_sid(xc_handle, ctx, strlen(ctx), &sid);
> +
>      xc_interface_close(xc_handle);
>  
> -    free(buf);
> -    
>      if ( ret != 0 ) {
>          errno = -ret;
>          return PyErr_SetFromErrno(xc_error_obj);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:37:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJrd-0001Yd-U3; Fri, 28 Nov 2014 11:37:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuJrc-0001YQ-0M
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:37:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8E/44-25276-77E58745; Fri, 28 Nov 2014 11:37:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417174645!12081134!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7897 invoked from network); 28 Nov 2014 11:37:26 -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;
	28 Nov 2014 11:37:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197425003"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 06:37:24 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuJrY-00024C-Fq;
	Fri, 28 Nov 2014 11:37:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuJrX-0001kB-2H;
	Fri, 28 Nov 2014 11:37:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.24178.579263.449346@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 11:37:22 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417168681.19852.2.camel@citrix.com>
References: <54770242.9000709@bitdefender.com>
	<1417168681.19852.2.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xenstore.h clarifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Xenstore.h clarifications"):
> I think there's a pretty good chance that the same applies to xenstore
> connections made over the device/shared-ring interface.

Yes.

> I'm not really sure about the semantics of a Unix domain socket after a
> fork, but I don't expect both parent and child could sanely make use of
> it.

>From the kernel's point of view everything is fine but of course the
protocol running through the socket would be quite messed up.  For
xenstore, while in theory you could take turns somehow, I don't think
suggesting that is sensible.

> So I think the answer is:
> 
>       * Connections made with xs_open(0) (which might be shared page or
>         socket based) are only guaranteed to work in the parent after
>         fork.
>       * Connections made with xs_open(XS_OPEN_SOCKETONLY) will be usable
>         in either the parent or the child after fork, but not both.
>       * xs_daemon_open*() and xs_domain_open() are deprecated synonyms
>         for xs_open(0)
>       * XS_OPEN_READONLY has not bearing on any of this.
> 
> Ian, does that seem right?

Exactly, yes.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:37:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJrd-0001Yd-U3; Fri, 28 Nov 2014 11:37:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuJrc-0001YQ-0M
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:37:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8E/44-25276-77E58745; Fri, 28 Nov 2014 11:37:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417174645!12081134!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7897 invoked from network); 28 Nov 2014 11:37:26 -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;
	28 Nov 2014 11:37:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197425003"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 06:37:24 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuJrY-00024C-Fq;
	Fri, 28 Nov 2014 11:37:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuJrX-0001kB-2H;
	Fri, 28 Nov 2014 11:37:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.24178.579263.449346@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 11:37:22 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417168681.19852.2.camel@citrix.com>
References: <54770242.9000709@bitdefender.com>
	<1417168681.19852.2.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xenstore.h clarifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Xenstore.h clarifications"):
> I think there's a pretty good chance that the same applies to xenstore
> connections made over the device/shared-ring interface.

Yes.

> I'm not really sure about the semantics of a Unix domain socket after a
> fork, but I don't expect both parent and child could sanely make use of
> it.

>From the kernel's point of view everything is fine but of course the
protocol running through the socket would be quite messed up.  For
xenstore, while in theory you could take turns somehow, I don't think
suggesting that is sensible.

> So I think the answer is:
> 
>       * Connections made with xs_open(0) (which might be shared page or
>         socket based) are only guaranteed to work in the parent after
>         fork.
>       * Connections made with xs_open(XS_OPEN_SOCKETONLY) will be usable
>         in either the parent or the child after fork, but not both.
>       * xs_daemon_open*() and xs_domain_open() are deprecated synonyms
>         for xs_open(0)
>       * XS_OPEN_READONLY has not bearing on any of this.
> 
> Ian, does that seem right?

Exactly, yes.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:38:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJt3-0001km-Lw; Fri, 28 Nov 2014 11:38:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuJt2-0001kX-7K
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:38:56 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	93/36-27785-FCE58745; Fri, 28 Nov 2014 11:38:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417174730!11738559!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20284 invoked from network); 28 Nov 2014 11:38:54 -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 Nov 2014 11:38:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197701993"
Message-ID: <1417174732.23604.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 28 Nov 2014 11:38:52 +0000
In-Reply-To: <1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 2/3] python/xc: Fix multiple issues
 in pyxc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:
> Don't leak a 16k allocation if PyArg_ParseTupleAndKeywords() or the first
> xc_readconsolering() fail.  It is trivial to run throught the processes memory
> by repeatedly passing junk parameters to this function.
> 
> In the case that the call to xc_readconsolering() in the while loop fails,
> reinstate str before breaking out, and passing a spurious pointer to free().
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Coverity-IDs: 1054984 1055906
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Xen Coverity Team <coverity@xen.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/python/xen/lowlevel/xc/xc.c |   13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
> index c70b388..2aa0dc7 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -1089,7 +1089,7 @@ static PyObject *pyxc_readconsolering(XcObject *self,
>  {
>      unsigned int clear = 0, index = 0, incremental = 0;
>      unsigned int count = 16384 + 1, size = count;
> -    char        *str = malloc(size), *ptr;
> +    char        *str, *ptr;
>      PyObject    *obj;
>      int          ret;
>  
> @@ -1097,15 +1097,17 @@ static PyObject *pyxc_readconsolering(XcObject *self,
>  
>      if ( !PyArg_ParseTupleAndKeywords(args, kwds, "|iii", kwd_list,
>                                        &clear, &index, &incremental) ||
> -         !str )
> +         !(str = malloc(size)) )
>          return NULL;
>  
>      ret = xc_readconsolering(self->xc_handle, str, &count, clear,
>                               incremental, &index);
> -    if ( ret < 0 )
> +    if ( ret < 0 ) {
> +        free(str);
>          return pyxc_error_to_exception(self->xc_handle);
> +    }
>  
> -    while ( !incremental && count == size )
> +    while ( !incremental && count == size && ret >= 0 )
>      {
>          size += count - 1;
>          if ( size < count )
> @@ -1119,9 +1121,6 @@ static PyObject *pyxc_readconsolering(XcObject *self,
>          count = size - count;
>          ret = xc_readconsolering(self->xc_handle, str, &count, clear,
>                                   1, &index);
> -        if ( ret < 0 )
> -            break;
> -
>          count += str - ptr;
>          str = ptr;
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:38:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuJt3-0001km-Lw; Fri, 28 Nov 2014 11:38:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuJt2-0001kX-7K
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:38:56 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	93/36-27785-FCE58745; Fri, 28 Nov 2014 11:38:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417174730!11738559!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20284 invoked from network); 28 Nov 2014 11:38:54 -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 Nov 2014 11:38:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197701993"
Message-ID: <1417174732.23604.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 28 Nov 2014 11:38:52 +0000
In-Reply-To: <1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 2/3] python/xc: Fix multiple issues
 in pyxc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:
> Don't leak a 16k allocation if PyArg_ParseTupleAndKeywords() or the first
> xc_readconsolering() fail.  It is trivial to run throught the processes memory
> by repeatedly passing junk parameters to this function.
> 
> In the case that the call to xc_readconsolering() in the while loop fails,
> reinstate str before breaking out, and passing a spurious pointer to free().
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Coverity-IDs: 1054984 1055906
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Xen Coverity Team <coverity@xen.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/python/xen/lowlevel/xc/xc.c |   13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
> index c70b388..2aa0dc7 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -1089,7 +1089,7 @@ static PyObject *pyxc_readconsolering(XcObject *self,
>  {
>      unsigned int clear = 0, index = 0, incremental = 0;
>      unsigned int count = 16384 + 1, size = count;
> -    char        *str = malloc(size), *ptr;
> +    char        *str, *ptr;
>      PyObject    *obj;
>      int          ret;
>  
> @@ -1097,15 +1097,17 @@ static PyObject *pyxc_readconsolering(XcObject *self,
>  
>      if ( !PyArg_ParseTupleAndKeywords(args, kwds, "|iii", kwd_list,
>                                        &clear, &index, &incremental) ||
> -         !str )
> +         !(str = malloc(size)) )
>          return NULL;
>  
>      ret = xc_readconsolering(self->xc_handle, str, &count, clear,
>                               incremental, &index);
> -    if ( ret < 0 )
> +    if ( ret < 0 ) {
> +        free(str);
>          return pyxc_error_to_exception(self->xc_handle);
> +    }
>  
> -    while ( !incremental && count == size )
> +    while ( !incremental && count == size && ret >= 0 )
>      {
>          size += count - 1;
>          if ( size < count )
> @@ -1119,9 +1121,6 @@ static PyObject *pyxc_readconsolering(XcObject *self,
>          count = size - count;
>          ret = xc_readconsolering(self->xc_handle, str, &count, clear,
>                                   1, &index);
> -        if ( ret < 0 )
> -            break;
> -
>          count += str - ptr;
>          str = ptr;
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:47:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK17-0002Cc-LY; Fri, 28 Nov 2014 11:47:17 +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 1XuK16-0002CX-68
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:47:16 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E3/69-27584-3C068745; Fri, 28 Nov 2014 11:47:15 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417175233!13844936!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26862 invoked from network); 28 Nov 2014 11:47:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:47:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197704004"
Message-ID: <547860BF.1000400@citrix.com>
Date: Fri, 28 Nov 2014 11:47:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>	
	<1417091674-8163-2-git-send-email-andrew.cooper3@citrix.com>
	<1417174620.23604.12.camel@citrix.com>
In-Reply-To: <1417174620.23604.12.camel@citrix.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 1/3] python/xc: Fix multiple issues
	in pyflask_context_to_sid()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 11:37, Ian Campbell wrote:
> On Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:
>> The error handling from a failed memory allocation should return
>> PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and continuing
>> to the memcpy() below, with the dest pointer being NULL.
>>
>> Furthermore, the context string is simply an input parameter to the hypercall,
>> and is not mutated anywhere along the way.  The error handling elsewhere in
>> the function can be simplified by not duplicating it to start with.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Coverity-IDs: 1055305 1055721
>> CC: Ian Campbell <Ian.Campbell@citrix.com>
>> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Xen Coverity Team <coverity@xen.org>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> This would have been far more obviously correct for 4.5 if you had stuck
> to fixing the issue in the first paragraph.

Hmm - I appear to have missed a detail in the description.  One of the
CIDs is to do with putting a string in a new buffer without a NUL
terminator, and passing it as a char* into xc_flask_context_to_sid; the
issue being that anyone expecting things like strlen() to work will be
in for a nasty shock.

One solution to this was strdup(), but as the duplication was
unnecessary anyway, it was easier just to drop it all.

~Andrew

>
>> ---
>>  tools/python/xen/lowlevel/xc/xc.c |   21 +++------------------
>>  1 file changed, 3 insertions(+), 18 deletions(-)
>>
>> diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
>> index d95d459..c70b388 100644
>> --- a/tools/python/xen/lowlevel/xc/xc.c
>> +++ b/tools/python/xen/lowlevel/xc/xc.c
>> @@ -2126,8 +2126,6 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
>>  {
>>      xc_interface *xc_handle;
>>      char *ctx;
>> -    char *buf;
>> -    uint32_t len;
>>      uint32_t sid;
>>      int ret;
>>  
>> @@ -2137,28 +2135,15 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
>>                                        &ctx) )
>>          return NULL;
>>  
>> -    len = strlen(ctx);
>> -
>> -    buf = malloc(len);
>> -    if (!buf) {
>> -        errno = -ENOMEM;
>> -        PyErr_SetFromErrno(xc_error_obj);
>> -    }
>> -    
>> -    memcpy(buf, ctx, len);
>> -    
>>      xc_handle = xc_interface_open(0,0,0);
>>      if (!xc_handle) {
>> -        free(buf);
>>          return PyErr_SetFromErrno(xc_error_obj);
>>      }
>> -    
>> -    ret = xc_flask_context_to_sid(xc_handle, buf, len, &sid);
>> -        
>> +
>> +    ret = xc_flask_context_to_sid(xc_handle, ctx, strlen(ctx), &sid);
>> +
>>      xc_interface_close(xc_handle);
>>  
>> -    free(buf);
>> -    
>>      if ( ret != 0 ) {
>>          errno = -ret;
>>          return PyErr_SetFromErrno(xc_error_obj);
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:47:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK17-0002Cc-LY; Fri, 28 Nov 2014 11:47:17 +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 1XuK16-0002CX-68
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:47:16 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E3/69-27584-3C068745; Fri, 28 Nov 2014 11:47:15 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417175233!13844936!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26862 invoked from network); 28 Nov 2014 11:47:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:47:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197704004"
Message-ID: <547860BF.1000400@citrix.com>
Date: Fri, 28 Nov 2014 11:47:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>	
	<1417091674-8163-2-git-send-email-andrew.cooper3@citrix.com>
	<1417174620.23604.12.camel@citrix.com>
In-Reply-To: <1417174620.23604.12.camel@citrix.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 1/3] python/xc: Fix multiple issues
	in pyflask_context_to_sid()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/11/14 11:37, Ian Campbell wrote:
> On Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:
>> The error handling from a failed memory allocation should return
>> PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and continuing
>> to the memcpy() below, with the dest pointer being NULL.
>>
>> Furthermore, the context string is simply an input parameter to the hypercall,
>> and is not mutated anywhere along the way.  The error handling elsewhere in
>> the function can be simplified by not duplicating it to start with.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Coverity-IDs: 1055305 1055721
>> CC: Ian Campbell <Ian.Campbell@citrix.com>
>> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Xen Coverity Team <coverity@xen.org>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> This would have been far more obviously correct for 4.5 if you had stuck
> to fixing the issue in the first paragraph.

Hmm - I appear to have missed a detail in the description.  One of the
CIDs is to do with putting a string in a new buffer without a NUL
terminator, and passing it as a char* into xc_flask_context_to_sid; the
issue being that anyone expecting things like strlen() to work will be
in for a nasty shock.

One solution to this was strdup(), but as the duplication was
unnecessary anyway, it was easier just to drop it all.

~Andrew

>
>> ---
>>  tools/python/xen/lowlevel/xc/xc.c |   21 +++------------------
>>  1 file changed, 3 insertions(+), 18 deletions(-)
>>
>> diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
>> index d95d459..c70b388 100644
>> --- a/tools/python/xen/lowlevel/xc/xc.c
>> +++ b/tools/python/xen/lowlevel/xc/xc.c
>> @@ -2126,8 +2126,6 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
>>  {
>>      xc_interface *xc_handle;
>>      char *ctx;
>> -    char *buf;
>> -    uint32_t len;
>>      uint32_t sid;
>>      int ret;
>>  
>> @@ -2137,28 +2135,15 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
>>                                        &ctx) )
>>          return NULL;
>>  
>> -    len = strlen(ctx);
>> -
>> -    buf = malloc(len);
>> -    if (!buf) {
>> -        errno = -ENOMEM;
>> -        PyErr_SetFromErrno(xc_error_obj);
>> -    }
>> -    
>> -    memcpy(buf, ctx, len);
>> -    
>>      xc_handle = xc_interface_open(0,0,0);
>>      if (!xc_handle) {
>> -        free(buf);
>>          return PyErr_SetFromErrno(xc_error_obj);
>>      }
>> -    
>> -    ret = xc_flask_context_to_sid(xc_handle, buf, len, &sid);
>> -        
>> +
>> +    ret = xc_flask_context_to_sid(xc_handle, ctx, strlen(ctx), &sid);
>> +
>>      xc_interface_close(xc_handle);
>>  
>> -    free(buf);
>> -    
>>      if ( ret != 0 ) {
>>          errno = -ret;
>>          return PyErr_SetFromErrno(xc_error_obj);
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:48:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:48:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK1z-0002Fj-2j; Fri, 28 Nov 2014 11:48:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuK1w-0002FX-Ux
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 11:48:09 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	58/7D-18267-8F068745; Fri, 28 Nov 2014 11:48:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417175285!14526552!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21586 invoked from network); 28 Nov 2014 11:48:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:48:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197704076"
Message-ID: <1417175252.23604.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 28 Nov 2014 11:47:32 +0000
In-Reply-To: <5477671C.4010500@linaro.org>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<5477671C.4010500@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:02 +0000, Julien Grall wrote:
> state at the GIC level. This would also avoid masking the output signal
> and requires specific handling in the guest OS.

"which requires"?

It doesn't seem quite right to me otherwise, since context switching the
virq state *removes* the need to have the guest do anything other than
what it would do on native.

Assuming this is what you meant I propose (fixing some grammar etc as I
go):

xen/arm: Handle platforms with edge-triggered virtual timer

Some platforms (such as the ARMv8 model) use an edge-triggered interrupt
for the virtual timer. Even if the timer output signal is masked in the
context switch, the GIC will keep track that of any interrupts raised
while IRQs are disabled. As soon as IRQs are re-enabled, the virtual
interrupt timer will be injected to Xen.

If an idle vVCPU was scheduled next then the interrupt handler doesn't
expect to the receive the IRQ and will crash:

(XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
(XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
(XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
(XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
(XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
(XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
(XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
(XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
(XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
(XEN)    [<000000000022482c>] schedule+0x684/0x6d0
(XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
(XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
(XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
(XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
(XEN)    [<0000000000000001>] 0000000000000001

The proper solution is to context switch the virtual interrupt state at
the GIC level. This would also avoid masking the output signal which
requires specific handling in the guest OS and more complex code in Xen
to deal with EOIs, and so is desirable for that reason too. 

Sadly, this solution requires some refactoring which would not be
suitable for a freeze exception for the Xen 4.5 release.

For now implement a temporary solution which ignores the virtual timer
interrupt when the idle VCPU is running.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:48:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:48:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK1z-0002Fj-2j; Fri, 28 Nov 2014 11:48:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuK1w-0002FX-Ux
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 11:48:09 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	58/7D-18267-8F068745; Fri, 28 Nov 2014 11:48:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417175285!14526552!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21586 invoked from network); 28 Nov 2014 11:48:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:48:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197704076"
Message-ID: <1417175252.23604.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 28 Nov 2014 11:47:32 +0000
In-Reply-To: <5477671C.4010500@linaro.org>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<5477671C.4010500@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:02 +0000, Julien Grall wrote:
> state at the GIC level. This would also avoid masking the output signal
> and requires specific handling in the guest OS.

"which requires"?

It doesn't seem quite right to me otherwise, since context switching the
virq state *removes* the need to have the guest do anything other than
what it would do on native.

Assuming this is what you meant I propose (fixing some grammar etc as I
go):

xen/arm: Handle platforms with edge-triggered virtual timer

Some platforms (such as the ARMv8 model) use an edge-triggered interrupt
for the virtual timer. Even if the timer output signal is masked in the
context switch, the GIC will keep track that of any interrupts raised
while IRQs are disabled. As soon as IRQs are re-enabled, the virtual
interrupt timer will be injected to Xen.

If an idle vVCPU was scheduled next then the interrupt handler doesn't
expect to the receive the IRQ and will crash:

(XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
(XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
(XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
(XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
(XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
(XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
(XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
(XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
(XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
(XEN)    [<000000000022482c>] schedule+0x684/0x6d0
(XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
(XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
(XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
(XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
(XEN)    [<0000000000000001>] 0000000000000001

The proper solution is to context switch the virtual interrupt state at
the GIC level. This would also avoid masking the output signal which
requires specific handling in the guest OS and more complex code in Xen
to deal with EOIs, and so is desirable for that reason too. 

Sadly, this solution requires some refactoring which would not be
suitable for a freeze exception for the Xen 4.5 release.

For now implement a temporary solution which ignores the virtual timer
interrupt when the idle VCPU is running.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:49:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:49:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK3g-0002NZ-JR; Fri, 28 Nov 2014 11:49:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuK3f-0002NT-I3
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:49:55 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	F4/9B-27785-26168745; Fri, 28 Nov 2014 11:49:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417175390!11733897!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6202 invoked from network); 28 Nov 2014 11:49:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:49:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197704438"
Message-ID: <1417175391.23604.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 11:49:51 +0000
In-Reply-To: <alpine.GSO.2.00.1411280830170.1345@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411272342370.5756@procyon.dur.ac.uk>
	<1417163231.2372.10.camel@citrix.com>
	<alpine.GSO.2.00.1411280830170.1345@algedi.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] fix migration failure with xl migrate
	--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 Fri, 2014-11-28 at 08:32 +0000, M A Young wrote:
> On Fri, 28 Nov 2014, Ian Campbell wrote:
> 
> > On Fri, 2014-11-28 at 00:28 +0000, M A Young wrote:
> >> Migrations with xl migrate --debug will fail because debugging information
> >> from the receiving process is written to the stdout channel. This channel
> >> is also used for status messages so the migration will fail as the sending
> >> process receives an unexpected message. This patch moves the debugging
> >> information to the stderr channel.
> >>
> >> Version 2 moves some output back to stdout that was accidentally moved
> >> to stderr in the first version.
> >>
> >> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
> >
> > I think you've forgotten the attachment.
> 
> Yes, I did. Here it is.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

It's pretty big but a large chunk is pretty mechanical. Were you
intending this for 4.5? (Konrad CCd).

> Use stderr for debugging messages for xl migrate --debug as stdout is used
> for status messages.
> 
> --- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig 2014-10-24 15:22:40.000000000 +0100
> +++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c      2014-11-26 22:41:41.697043321 +0000
> @@ -380,10 +380,10 @@
>  }
>  static void printf_info(enum output_format output_format,
>                          int domid,
> -                        libxl_domain_config *d_config)
> +                        libxl_domain_config *d_config, FILE *fh)
>  {
>      if (output_format == OUTPUT_FORMAT_SXP)
> -        return printf_info_sexp(domid, d_config);
> +        return printf_info_sexp(domid, d_config, fh);
>  
>      const char *buf;
>      libxl_yajl_length len = 0;
> @@ -404,7 +404,7 @@
>      if (s != yajl_gen_status_ok)
>          goto out;
>  
> -    puts(buf);
> +    fputs(buf, fh);
>  
>  out:
>      yajl_gen_free(hand);
> @@ -413,7 +413,13 @@
>          fprintf(stderr,
>                  "unable to format domain config as JSON (YAJL:%d)\n", s);
>  
> -    if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
> +    if (ferror(fh) || fflush(fh)) {
> +        if (fh == stdout)
> +            perror("stdout");
> +        else
> +            perror("stderr");
> +        exit(-1);
> +    }
>  }
>  
>  static int do_daemonize(char *name)
> @@ -2423,7 +2429,7 @@
>      }
>  
>      if (!dom_info->quiet)
> -        printf("Parsing config from %s\n", config_source);
> +        fprintf(stderr, "Parsing config from %s\n", config_source);
>  
>      if (config_in_json) {
>          libxl_domain_config_from_json(ctx, &d_config,
> @@ -2451,7 +2457,7 @@
>      }
>  
>      if (debug || dom_info->dryrun)
> -        printf_info(default_output_format, -1, &d_config);
> +        printf_info(default_output_format, -1, &d_config, stderr);
>  
>      ret = 0;
>      if (dom_info->dryrun)
> @@ -3403,7 +3409,7 @@
>          if (default_output_format == OUTPUT_FORMAT_JSON)
>              s = printf_info_one_json(hand, info[i].domid, &d_config);
>          else
> -            printf_info_sexp(info[i].domid, &d_config);
> +            printf_info_sexp(info[i].domid, &d_config, stdout);
>          libxl_domain_config_dispose(&d_config);
>          if (s != yajl_gen_status_ok)
>              goto out;
> @@ -4725,7 +4731,7 @@
>      parse_config_data(filename, config_data, config_len, &d_config);
>  
>      if (debug || dryrun_only)
> -        printf_info(default_output_format, -1, &d_config);
> +        printf_info(default_output_format, -1, &d_config, stdout);
>  
>      if (!dryrun_only) {
>          fprintf(stderr, "setting dom%d configuration\n", domid);
> --- xen-4.5.0-rc1/tools/libxl/xl_sxp.c.orig     2014-10-24 15:22:40.000000000 +0100
> +++ xen-4.5.0-rc1/tools/libxl/xl_sxp.c  2014-11-26 22:30:58.416394082 +0000
> @@ -30,7 +30,7 @@
>  /* 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)
> +void printf_info_sexp(int domid, libxl_domain_config *d_config, FILE *fh)
>  {
>      int i;
>      libxl_dominfo info;
> @@ -38,195 +38,195 @@
>      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 %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);
> +    fprintf(fh, "(domain\n\t(domid %d)\n", domid);
> +    fprintf(fh, "\t(create_info)\n");
> +    fprintf(fh, "\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
> +    fprintf(fh, "\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
> +    fprintf(fh, "\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
> +    fprintf(fh, "\t(ssidref %d)\n", c_info->ssidref);
> +    fprintf(fh, "\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));
> +        fprintf(fh, "\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
>      } else {
> -        printf("\t(uuid <unknown>)\n");
> +        fprintf(fh, "\t(uuid <unknown>)\n");
>      }
>      if (c_info->pool_name)
> -        printf("\t(cpupool %s)\n", c_info->pool_name);
> +        fprintf(fh, "\t(cpupool %s)\n", c_info->pool_name);
>      if (c_info->xsdata)
> -        printf("\t(xsdata contains data)\n");
> +        fprintf(fh, "\t(xsdata contains data)\n");
>      else
> -        printf("\t(xsdata (null))\n");
> +        fprintf(fh, "\t(xsdata (null))\n");
>      if (c_info->platformdata)
> -        printf("\t(platformdata contains data)\n");
> +        fprintf(fh, "\t(platformdata contains data)\n");
>      else
> -        printf("\t(platformdata (null))\n");
> +        fprintf(fh, "\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 %"PRId64")\n", b_info->max_memkb);
> -    printf("\t(target_memkb %"PRId64")\n", b_info->target_memkb);
> -    printf("\t(nomigrate %s)\n",
> +    fprintf(fh, "\t(build_info)\n");
> +    fprintf(fh, "\t(max_vcpus %d)\n", b_info->max_vcpus);
> +    fprintf(fh, "\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
> +    fprintf(fh, "\t(max_memkb %"PRId64")\n", b_info->max_memkb);
> +    fprintf(fh, "\t(target_memkb %"PRId64")\n", b_info->target_memkb);
> +    fprintf(fh, "\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) {
> -        printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
> +        fprintf(fh, "\t(bootloader %s)\n", b_info->u.pv.bootloader);
>          if (b_info->u.pv.bootloader_args) {
> -            printf("\t(bootloader_args");
> +            fprintf(fh, "\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");
> +                fprintf(fh, " %s", b_info->u.pv.bootloader_args[i]);
> +            fprintf(fh, ")\n");
>          }
>      }
>  
> -    printf("\t(image\n");
> +    fprintf(fh, "\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 %"PRId64")\n", b_info->video_memkb);
> -        printf("\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
> -        printf("\t\t\t(pae %s)\n", libxl_defbool_to_string(b_info->u.hvm.pae));
> -        printf("\t\t\t(apic %s)\n",
> +        fprintf(fh, "\t\t(hvm\n");
> +        fprintf(fh, "\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
> +        fprintf(fh, "\t\t\t(video_memkb %"PRId64")\n", b_info->video_memkb);
> +        fprintf(fh, "\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
> +        fprintf(fh, "\t\t\t(pae %s)\n", libxl_defbool_to_string(b_info->u.hvm.pae));
> +        fprintf(fh, "\t\t\t(apic %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.apic));
> -        printf("\t\t\t(acpi %s)\n",
> +        fprintf(fh, "\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",
> +        fprintf(fh, "\t\t\t(nx %s)\n", libxl_defbool_to_string(b_info->u.hvm.nx));
> +        fprintf(fh, "\t\t\t(viridian %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.viridian));
> -        printf("\t\t\t(hpet %s)\n",
> +        fprintf(fh, "\t\t\t(hpet %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.hpet));
> -        printf("\t\t\t(vpt_align %s)\n",
> +        fprintf(fh, "\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",
> +        fprintf(fh, "\t\t\t(timer_mode %s)\n",
>                 libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
> -        printf("\t\t\t(nestedhvm %s)\n",
> +        fprintf(fh, "\t\t\t(nestedhvm %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
> -        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.kind ==
> +        fprintf(fh, "\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.kind ==
>                                        LIBXL_VGA_INTERFACE_TYPE_STD ?
>                                        "True" : "False");
> -        printf("\t\t\t(vnc %s)\n",
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
> +        fprintf(fh, "\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
> +        fprintf(fh, "\t\t\t(sdl %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.sdl.enable));
> -        printf("\t\t\t(opengl %s)\n",
> +        fprintf(fh, "\t\t\t(opengl %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.sdl.opengl));
> -        printf("\t\t\t(nographic %s)\n",
> +        fprintf(fh, "\t\t\t(nographic %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.nographic));
> -        printf("\t\t\t(spice %s)\n",
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
> +        fprintf(fh, "\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
> +        fprintf(fh, "\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
> +        fprintf(fh, "\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",
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
> +        fprintf(fh, "\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));
> -        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
> -        printf("\t\t)\n");
> +        fprintf(fh, "\t\t\t(serial %s)\n", b_info->u.hvm.serial);
> +        fprintf(fh, "\t\t\t(boot %s)\n", b_info->u.hvm.boot);
> +        fprintf(fh, "\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
> +        fprintf(fh, "\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
> +        fprintf(fh, "\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->kernel);
> -        printf("\t\t\t(cmdline %s)\n", b_info->cmdline);
> -        printf("\t\t\t(ramdisk %s)\n", b_info->ramdisk);
> -        printf("\t\t\t(e820_host %s)\n",
> +        fprintf(fh, "\t\t(linux %d)\n", 0);
> +        fprintf(fh, "\t\t\t(kernel %s)\n", b_info->kernel);
> +        fprintf(fh, "\t\t\t(cmdline %s)\n", b_info->cmdline);
> +        fprintf(fh, "\t\t\t(ramdisk %s)\n", b_info->ramdisk);
> +        fprintf(fh, "\t\t\t(e820_host %s)\n",
>                 libxl_defbool_to_string(b_info->u.pv.e820_host));
> -        printf("\t\t)\n");
> +        fprintf(fh, "\t\t)\n");
>          break;
>      default:
>          fprintf(stderr, "Unknown domain type %d\n", c_info->type);
>          exit(1);
>      }
> -    printf("\t)\n");
> +    fprintf(fh, "\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");
> +        fprintf(fh, "\t(device\n");
> +        fprintf(fh, "\t\t(tap\n");
> +        fprintf(fh, "\t\t\t(backend_domid %d)\n", d_config->disks[i].backend_domid);
> +        fprintf(fh, "\t\t\t(frontend_domid %d)\n", domid);
> +        fprintf(fh, "\t\t\t(physpath %s)\n", d_config->disks[i].pdev_path);
> +        fprintf(fh, "\t\t\t(phystype %d)\n", d_config->disks[i].backend);
> +        fprintf(fh, "\t\t\t(virtpath %s)\n", d_config->disks[i].vdev);
> +        fprintf(fh, "\t\t\t(unpluggable %d)\n", d_config->disks[i].removable);
> +        fprintf(fh, "\t\t\t(readwrite %d)\n", d_config->disks[i].readwrite);
> +        fprintf(fh, "\t\t\t(is_cdrom %d)\n", d_config->disks[i].is_cdrom);
> +        fprintf(fh, "\t\t)\n");
> +        fprintf(fh, "\t)\n");
>      }
>  
>      for (i = 0; i < d_config->num_nics; i++) {
> -        printf("\t(device\n");
> -        printf("\t\t(vif\n");
> +        fprintf(fh, "\t(device\n");
> +        fprintf(fh, "\t\t(vif\n");
>          if (d_config->nics[i].ifname)
> -            printf("\t\t\t(vifname %s)\n", d_config->nics[i].ifname);
> -        printf("\t\t\t(backend_domid %d)\n", d_config->nics[i].backend_domid);
> -        printf("\t\t\t(frontend_domid %d)\n", domid);
> -        printf("\t\t\t(devid %d)\n", d_config->nics[i].devid);
> -        printf("\t\t\t(mtu %d)\n", d_config->nics[i].mtu);
> -        printf("\t\t\t(model %s)\n", d_config->nics[i].model);
> -        printf("\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
> +            fprintf(fh, "\t\t\t(vifname %s)\n", d_config->nics[i].ifname);
> +        fprintf(fh, "\t\t\t(backend_domid %d)\n", d_config->nics[i].backend_domid);
> +        fprintf(fh, "\t\t\t(frontend_domid %d)\n", domid);
> +        fprintf(fh, "\t\t\t(devid %d)\n", d_config->nics[i].devid);
> +        fprintf(fh, "\t\t\t(mtu %d)\n", d_config->nics[i].mtu);
> +        fprintf(fh, "\t\t\t(model %s)\n", d_config->nics[i].model);
> +        fprintf(fh, "\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
>                 d_config->nics[i].mac[0], d_config->nics[i].mac[1],
>                 d_config->nics[i].mac[2], d_config->nics[i].mac[3],
>                 d_config->nics[i].mac[4], d_config->nics[i].mac[5]);
> -        printf("\t\t)\n");
> -        printf("\t)\n");
> +        fprintf(fh, "\t\t)\n");
> +        fprintf(fh, "\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",
> +        fprintf(fh, "\t(device\n");
> +        fprintf(fh, "\t\t(pci\n");
> +        fprintf(fh, "\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",
> +        fprintf(fh, "\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");
> +        fprintf(fh, "\t\t)\n");
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t(device\n");
> +        fprintf(fh, "\t\t(vfb\n");
> +        fprintf(fh, "\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
> +        fprintf(fh, "\t\t\t(frontend_domid %d)\n", domid);
> +        fprintf(fh, "\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
> +        fprintf(fh, "\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
> +        fprintf(fh, "\t\t\t(sdl %s)\n",
>                 libxl_defbool_to_string(d_config->vfbs[i].sdl.enable));
> -        printf("\t\t\t(opengl %s)\n",
> +        fprintf(fh, "\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");
> -        printf("\t)\n");
> +        fprintf(fh, "\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
> +        fprintf(fh, "\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
> +        fprintf(fh, "\t\t)\n");
> +        fprintf(fh, "\t)\n");
>      }
> -    printf(")\n");
> +    fprintf(fh, ")\n");
>  }
>  
>  
> --- xen-4.5.0-rc1/tools/libxl/xl.h.orig 2014-10-24 15:22:40.000000000 +0100
> +++ xen-4.5.0-rc1/tools/libxl/xl.h      2014-11-26 22:30:58.416394082 +0000
> @@ -186,7 +186,7 @@
>  };
>  extern enum output_format default_output_format;
>  
> -extern void printf_info_sexp(int domid, libxl_domain_config *d_config);
> +extern void printf_info_sexp(int domid, libxl_domain_config *d_config, FILE *fh);
>  
>  #define XL_GLOBAL_CONFIG XEN_CONFIG_DIR "/xl.conf"
>  #define XL_LOCK_FILE XEN_LOCK_DIR "/xl"



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:49:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:49:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK3g-0002NZ-JR; Fri, 28 Nov 2014 11:49:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuK3f-0002NT-I3
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:49:55 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	F4/9B-27785-26168745; Fri, 28 Nov 2014 11:49:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417175390!11733897!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6202 invoked from network); 28 Nov 2014 11:49:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:49:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197704438"
Message-ID: <1417175391.23604.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 11:49:51 +0000
In-Reply-To: <alpine.GSO.2.00.1411280830170.1345@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1411272342370.5756@procyon.dur.ac.uk>
	<1417163231.2372.10.camel@citrix.com>
	<alpine.GSO.2.00.1411280830170.1345@algedi.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] fix migration failure with xl migrate
	--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 Fri, 2014-11-28 at 08:32 +0000, M A Young wrote:
> On Fri, 28 Nov 2014, Ian Campbell wrote:
> 
> > On Fri, 2014-11-28 at 00:28 +0000, M A Young wrote:
> >> Migrations with xl migrate --debug will fail because debugging information
> >> from the receiving process is written to the stdout channel. This channel
> >> is also used for status messages so the migration will fail as the sending
> >> process receives an unexpected message. This patch moves the debugging
> >> information to the stderr channel.
> >>
> >> Version 2 moves some output back to stdout that was accidentally moved
> >> to stderr in the first version.
> >>
> >> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
> >
> > I think you've forgotten the attachment.
> 
> Yes, I did. Here it is.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

It's pretty big but a large chunk is pretty mechanical. Were you
intending this for 4.5? (Konrad CCd).

> Use stderr for debugging messages for xl migrate --debug as stdout is used
> for status messages.
> 
> --- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig 2014-10-24 15:22:40.000000000 +0100
> +++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c      2014-11-26 22:41:41.697043321 +0000
> @@ -380,10 +380,10 @@
>  }
>  static void printf_info(enum output_format output_format,
>                          int domid,
> -                        libxl_domain_config *d_config)
> +                        libxl_domain_config *d_config, FILE *fh)
>  {
>      if (output_format == OUTPUT_FORMAT_SXP)
> -        return printf_info_sexp(domid, d_config);
> +        return printf_info_sexp(domid, d_config, fh);
>  
>      const char *buf;
>      libxl_yajl_length len = 0;
> @@ -404,7 +404,7 @@
>      if (s != yajl_gen_status_ok)
>          goto out;
>  
> -    puts(buf);
> +    fputs(buf, fh);
>  
>  out:
>      yajl_gen_free(hand);
> @@ -413,7 +413,13 @@
>          fprintf(stderr,
>                  "unable to format domain config as JSON (YAJL:%d)\n", s);
>  
> -    if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
> +    if (ferror(fh) || fflush(fh)) {
> +        if (fh == stdout)
> +            perror("stdout");
> +        else
> +            perror("stderr");
> +        exit(-1);
> +    }
>  }
>  
>  static int do_daemonize(char *name)
> @@ -2423,7 +2429,7 @@
>      }
>  
>      if (!dom_info->quiet)
> -        printf("Parsing config from %s\n", config_source);
> +        fprintf(stderr, "Parsing config from %s\n", config_source);
>  
>      if (config_in_json) {
>          libxl_domain_config_from_json(ctx, &d_config,
> @@ -2451,7 +2457,7 @@
>      }
>  
>      if (debug || dom_info->dryrun)
> -        printf_info(default_output_format, -1, &d_config);
> +        printf_info(default_output_format, -1, &d_config, stderr);
>  
>      ret = 0;
>      if (dom_info->dryrun)
> @@ -3403,7 +3409,7 @@
>          if (default_output_format == OUTPUT_FORMAT_JSON)
>              s = printf_info_one_json(hand, info[i].domid, &d_config);
>          else
> -            printf_info_sexp(info[i].domid, &d_config);
> +            printf_info_sexp(info[i].domid, &d_config, stdout);
>          libxl_domain_config_dispose(&d_config);
>          if (s != yajl_gen_status_ok)
>              goto out;
> @@ -4725,7 +4731,7 @@
>      parse_config_data(filename, config_data, config_len, &d_config);
>  
>      if (debug || dryrun_only)
> -        printf_info(default_output_format, -1, &d_config);
> +        printf_info(default_output_format, -1, &d_config, stdout);
>  
>      if (!dryrun_only) {
>          fprintf(stderr, "setting dom%d configuration\n", domid);
> --- xen-4.5.0-rc1/tools/libxl/xl_sxp.c.orig     2014-10-24 15:22:40.000000000 +0100
> +++ xen-4.5.0-rc1/tools/libxl/xl_sxp.c  2014-11-26 22:30:58.416394082 +0000
> @@ -30,7 +30,7 @@
>  /* 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)
> +void printf_info_sexp(int domid, libxl_domain_config *d_config, FILE *fh)
>  {
>      int i;
>      libxl_dominfo info;
> @@ -38,195 +38,195 @@
>      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 %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);
> +    fprintf(fh, "(domain\n\t(domid %d)\n", domid);
> +    fprintf(fh, "\t(create_info)\n");
> +    fprintf(fh, "\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
> +    fprintf(fh, "\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
> +    fprintf(fh, "\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
> +    fprintf(fh, "\t(ssidref %d)\n", c_info->ssidref);
> +    fprintf(fh, "\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));
> +        fprintf(fh, "\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
>      } else {
> -        printf("\t(uuid <unknown>)\n");
> +        fprintf(fh, "\t(uuid <unknown>)\n");
>      }
>      if (c_info->pool_name)
> -        printf("\t(cpupool %s)\n", c_info->pool_name);
> +        fprintf(fh, "\t(cpupool %s)\n", c_info->pool_name);
>      if (c_info->xsdata)
> -        printf("\t(xsdata contains data)\n");
> +        fprintf(fh, "\t(xsdata contains data)\n");
>      else
> -        printf("\t(xsdata (null))\n");
> +        fprintf(fh, "\t(xsdata (null))\n");
>      if (c_info->platformdata)
> -        printf("\t(platformdata contains data)\n");
> +        fprintf(fh, "\t(platformdata contains data)\n");
>      else
> -        printf("\t(platformdata (null))\n");
> +        fprintf(fh, "\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 %"PRId64")\n", b_info->max_memkb);
> -    printf("\t(target_memkb %"PRId64")\n", b_info->target_memkb);
> -    printf("\t(nomigrate %s)\n",
> +    fprintf(fh, "\t(build_info)\n");
> +    fprintf(fh, "\t(max_vcpus %d)\n", b_info->max_vcpus);
> +    fprintf(fh, "\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
> +    fprintf(fh, "\t(max_memkb %"PRId64")\n", b_info->max_memkb);
> +    fprintf(fh, "\t(target_memkb %"PRId64")\n", b_info->target_memkb);
> +    fprintf(fh, "\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) {
> -        printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
> +        fprintf(fh, "\t(bootloader %s)\n", b_info->u.pv.bootloader);
>          if (b_info->u.pv.bootloader_args) {
> -            printf("\t(bootloader_args");
> +            fprintf(fh, "\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");
> +                fprintf(fh, " %s", b_info->u.pv.bootloader_args[i]);
> +            fprintf(fh, ")\n");
>          }
>      }
>  
> -    printf("\t(image\n");
> +    fprintf(fh, "\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 %"PRId64")\n", b_info->video_memkb);
> -        printf("\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
> -        printf("\t\t\t(pae %s)\n", libxl_defbool_to_string(b_info->u.hvm.pae));
> -        printf("\t\t\t(apic %s)\n",
> +        fprintf(fh, "\t\t(hvm\n");
> +        fprintf(fh, "\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
> +        fprintf(fh, "\t\t\t(video_memkb %"PRId64")\n", b_info->video_memkb);
> +        fprintf(fh, "\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
> +        fprintf(fh, "\t\t\t(pae %s)\n", libxl_defbool_to_string(b_info->u.hvm.pae));
> +        fprintf(fh, "\t\t\t(apic %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.apic));
> -        printf("\t\t\t(acpi %s)\n",
> +        fprintf(fh, "\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",
> +        fprintf(fh, "\t\t\t(nx %s)\n", libxl_defbool_to_string(b_info->u.hvm.nx));
> +        fprintf(fh, "\t\t\t(viridian %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.viridian));
> -        printf("\t\t\t(hpet %s)\n",
> +        fprintf(fh, "\t\t\t(hpet %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.hpet));
> -        printf("\t\t\t(vpt_align %s)\n",
> +        fprintf(fh, "\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",
> +        fprintf(fh, "\t\t\t(timer_mode %s)\n",
>                 libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
> -        printf("\t\t\t(nestedhvm %s)\n",
> +        fprintf(fh, "\t\t\t(nestedhvm %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
> -        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.kind ==
> +        fprintf(fh, "\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.kind ==
>                                        LIBXL_VGA_INTERFACE_TYPE_STD ?
>                                        "True" : "False");
> -        printf("\t\t\t(vnc %s)\n",
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
> +        fprintf(fh, "\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
> +        fprintf(fh, "\t\t\t(sdl %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.sdl.enable));
> -        printf("\t\t\t(opengl %s)\n",
> +        fprintf(fh, "\t\t\t(opengl %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.sdl.opengl));
> -        printf("\t\t\t(nographic %s)\n",
> +        fprintf(fh, "\t\t\t(nographic %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.nographic));
> -        printf("\t\t\t(spice %s)\n",
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
> +        fprintf(fh, "\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
> +        fprintf(fh, "\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
> +        fprintf(fh, "\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",
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
> +        fprintf(fh, "\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));
> -        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
> -        printf("\t\t)\n");
> +        fprintf(fh, "\t\t\t(serial %s)\n", b_info->u.hvm.serial);
> +        fprintf(fh, "\t\t\t(boot %s)\n", b_info->u.hvm.boot);
> +        fprintf(fh, "\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
> +        fprintf(fh, "\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
> +        fprintf(fh, "\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->kernel);
> -        printf("\t\t\t(cmdline %s)\n", b_info->cmdline);
> -        printf("\t\t\t(ramdisk %s)\n", b_info->ramdisk);
> -        printf("\t\t\t(e820_host %s)\n",
> +        fprintf(fh, "\t\t(linux %d)\n", 0);
> +        fprintf(fh, "\t\t\t(kernel %s)\n", b_info->kernel);
> +        fprintf(fh, "\t\t\t(cmdline %s)\n", b_info->cmdline);
> +        fprintf(fh, "\t\t\t(ramdisk %s)\n", b_info->ramdisk);
> +        fprintf(fh, "\t\t\t(e820_host %s)\n",
>                 libxl_defbool_to_string(b_info->u.pv.e820_host));
> -        printf("\t\t)\n");
> +        fprintf(fh, "\t\t)\n");
>          break;
>      default:
>          fprintf(stderr, "Unknown domain type %d\n", c_info->type);
>          exit(1);
>      }
> -    printf("\t)\n");
> +    fprintf(fh, "\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");
> +        fprintf(fh, "\t(device\n");
> +        fprintf(fh, "\t\t(tap\n");
> +        fprintf(fh, "\t\t\t(backend_domid %d)\n", d_config->disks[i].backend_domid);
> +        fprintf(fh, "\t\t\t(frontend_domid %d)\n", domid);
> +        fprintf(fh, "\t\t\t(physpath %s)\n", d_config->disks[i].pdev_path);
> +        fprintf(fh, "\t\t\t(phystype %d)\n", d_config->disks[i].backend);
> +        fprintf(fh, "\t\t\t(virtpath %s)\n", d_config->disks[i].vdev);
> +        fprintf(fh, "\t\t\t(unpluggable %d)\n", d_config->disks[i].removable);
> +        fprintf(fh, "\t\t\t(readwrite %d)\n", d_config->disks[i].readwrite);
> +        fprintf(fh, "\t\t\t(is_cdrom %d)\n", d_config->disks[i].is_cdrom);
> +        fprintf(fh, "\t\t)\n");
> +        fprintf(fh, "\t)\n");
>      }
>  
>      for (i = 0; i < d_config->num_nics; i++) {
> -        printf("\t(device\n");
> -        printf("\t\t(vif\n");
> +        fprintf(fh, "\t(device\n");
> +        fprintf(fh, "\t\t(vif\n");
>          if (d_config->nics[i].ifname)
> -            printf("\t\t\t(vifname %s)\n", d_config->nics[i].ifname);
> -        printf("\t\t\t(backend_domid %d)\n", d_config->nics[i].backend_domid);
> -        printf("\t\t\t(frontend_domid %d)\n", domid);
> -        printf("\t\t\t(devid %d)\n", d_config->nics[i].devid);
> -        printf("\t\t\t(mtu %d)\n", d_config->nics[i].mtu);
> -        printf("\t\t\t(model %s)\n", d_config->nics[i].model);
> -        printf("\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
> +            fprintf(fh, "\t\t\t(vifname %s)\n", d_config->nics[i].ifname);
> +        fprintf(fh, "\t\t\t(backend_domid %d)\n", d_config->nics[i].backend_domid);
> +        fprintf(fh, "\t\t\t(frontend_domid %d)\n", domid);
> +        fprintf(fh, "\t\t\t(devid %d)\n", d_config->nics[i].devid);
> +        fprintf(fh, "\t\t\t(mtu %d)\n", d_config->nics[i].mtu);
> +        fprintf(fh, "\t\t\t(model %s)\n", d_config->nics[i].model);
> +        fprintf(fh, "\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
>                 d_config->nics[i].mac[0], d_config->nics[i].mac[1],
>                 d_config->nics[i].mac[2], d_config->nics[i].mac[3],
>                 d_config->nics[i].mac[4], d_config->nics[i].mac[5]);
> -        printf("\t\t)\n");
> -        printf("\t)\n");
> +        fprintf(fh, "\t\t)\n");
> +        fprintf(fh, "\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",
> +        fprintf(fh, "\t(device\n");
> +        fprintf(fh, "\t\t(pci\n");
> +        fprintf(fh, "\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",
> +        fprintf(fh, "\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");
> +        fprintf(fh, "\t\t)\n");
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t(device\n");
> +        fprintf(fh, "\t\t(vfb\n");
> +        fprintf(fh, "\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
> +        fprintf(fh, "\t\t\t(frontend_domid %d)\n", domid);
> +        fprintf(fh, "\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
> +        fprintf(fh, "\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
> +        fprintf(fh, "\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 %s)\n",
> +        fprintf(fh, "\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
> +        fprintf(fh, "\t\t\t(sdl %s)\n",
>                 libxl_defbool_to_string(d_config->vfbs[i].sdl.enable));
> -        printf("\t\t\t(opengl %s)\n",
> +        fprintf(fh, "\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");
> -        printf("\t)\n");
> +        fprintf(fh, "\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
> +        fprintf(fh, "\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
> +        fprintf(fh, "\t\t)\n");
> +        fprintf(fh, "\t)\n");
>      }
> -    printf(")\n");
> +    fprintf(fh, ")\n");
>  }
>  
>  
> --- xen-4.5.0-rc1/tools/libxl/xl.h.orig 2014-10-24 15:22:40.000000000 +0100
> +++ xen-4.5.0-rc1/tools/libxl/xl.h      2014-11-26 22:30:58.416394082 +0000
> @@ -186,7 +186,7 @@
>  };
>  extern enum output_format default_output_format;
>  
> -extern void printf_info_sexp(int domid, libxl_domain_config *d_config);
> +extern void printf_info_sexp(int domid, libxl_domain_config *d_config, FILE *fh);
>  
>  #define XL_GLOBAL_CONFIG XEN_CONFIG_DIR "/xl.conf"
>  #define XL_LOCK_FILE XEN_LOCK_DIR "/xl"



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:50:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:50:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK4Y-0002UQ-8Q; Fri, 28 Nov 2014 11:50:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuK4W-0002U2-MM
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:50:48 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	1D/1D-27785-89168745; Fri, 28 Nov 2014 11:50:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417175446!11739353!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5656 invoked from network); 28 Nov 2014 11:50:47 -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 Nov 2014 11:50:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197427761"
Message-ID: <1417175443.23604.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Liang Li <liang.z.li@intel.com>
Date: Fri, 28 Nov 2014 11:50:43 +0000
In-Reply-To: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	JBeulich@suse.com, andrew.cooper3@citrix.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v4] libxc: Expose the 1GB pages cpuid flag to 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 Fri, 2014-11-28 at 18:52 +0800, Liang Li wrote:
> If hardware support the 1GB pages, expose the feature to guest by
> default. Users don't have to use a 'cpuid= ' option in config fil
> e to turn it on.
> 
> If guest use shadow mode, the 1GB pages feature will be hidden from
> guest, this is done in the function hvm_cpuid(). So the change is
> okay for shadow mode case.
> 
> Signed-off-by: Liang Li <liang.z.li@intel.com>
> Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>

FTR although this is strictly speaking a toolstack patch I think the
main ack required should be from the x86 hypervisor guys...

> ---
>  tools/libxc/xc_cpuid_x86.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> index a18b1ff..c97f91a 100644
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -109,6 +109,7 @@ static void amd_xc_cpuid_policy(
>          regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */
>                      bitmaskof(X86_FEATURE_NX) |
>                      bitmaskof(X86_FEATURE_LM) |
> +                    bitmaskof(X86_FEATURE_PAGE1GB) |
>                      bitmaskof(X86_FEATURE_SYSCALL) |
>                      bitmaskof(X86_FEATURE_MP) |
>                      bitmaskof(X86_FEATURE_MMXEXT) |
> @@ -192,6 +193,7 @@ static void intel_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_ABM));
>          regs[3] &= (bitmaskof(X86_FEATURE_NX) |
>                      bitmaskof(X86_FEATURE_LM) |
> +                    bitmaskof(X86_FEATURE_PAGE1GB) |
>                      bitmaskof(X86_FEATURE_SYSCALL) |
>                      bitmaskof(X86_FEATURE_RDTSCP));
>          break;
> @@ -386,6 +388,7 @@ static void xc_cpuid_hvm_policy(
>              clear_bit(X86_FEATURE_LM, regs[3]);
>              clear_bit(X86_FEATURE_NX, regs[3]);
>              clear_bit(X86_FEATURE_PSE36, regs[3]);
> +            clear_bit(X86_FEATURE_PAGE1GB, regs[3]);
>          }
>          break;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:50:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:50:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK4Y-0002UQ-8Q; Fri, 28 Nov 2014 11:50:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuK4W-0002U2-MM
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:50:48 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	1D/1D-27785-89168745; Fri, 28 Nov 2014 11:50:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417175446!11739353!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5656 invoked from network); 28 Nov 2014 11:50:47 -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 Nov 2014 11:50:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197427761"
Message-ID: <1417175443.23604.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Liang Li <liang.z.li@intel.com>
Date: Fri, 28 Nov 2014 11:50:43 +0000
In-Reply-To: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	JBeulich@suse.com, andrew.cooper3@citrix.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v4] libxc: Expose the 1GB pages cpuid flag to 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 Fri, 2014-11-28 at 18:52 +0800, Liang Li wrote:
> If hardware support the 1GB pages, expose the feature to guest by
> default. Users don't have to use a 'cpuid= ' option in config fil
> e to turn it on.
> 
> If guest use shadow mode, the 1GB pages feature will be hidden from
> guest, this is done in the function hvm_cpuid(). So the change is
> okay for shadow mode case.
> 
> Signed-off-by: Liang Li <liang.z.li@intel.com>
> Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>

FTR although this is strictly speaking a toolstack patch I think the
main ack required should be from the x86 hypervisor guys...

> ---
>  tools/libxc/xc_cpuid_x86.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> index a18b1ff..c97f91a 100644
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -109,6 +109,7 @@ static void amd_xc_cpuid_policy(
>          regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */
>                      bitmaskof(X86_FEATURE_NX) |
>                      bitmaskof(X86_FEATURE_LM) |
> +                    bitmaskof(X86_FEATURE_PAGE1GB) |
>                      bitmaskof(X86_FEATURE_SYSCALL) |
>                      bitmaskof(X86_FEATURE_MP) |
>                      bitmaskof(X86_FEATURE_MMXEXT) |
> @@ -192,6 +193,7 @@ static void intel_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_ABM));
>          regs[3] &= (bitmaskof(X86_FEATURE_NX) |
>                      bitmaskof(X86_FEATURE_LM) |
> +                    bitmaskof(X86_FEATURE_PAGE1GB) |
>                      bitmaskof(X86_FEATURE_SYSCALL) |
>                      bitmaskof(X86_FEATURE_RDTSCP));
>          break;
> @@ -386,6 +388,7 @@ static void xc_cpuid_hvm_policy(
>              clear_bit(X86_FEATURE_LM, regs[3]);
>              clear_bit(X86_FEATURE_NX, regs[3]);
>              clear_bit(X86_FEATURE_PSE36, regs[3]);
> +            clear_bit(X86_FEATURE_PAGE1GB, regs[3]);
>          }
>          break;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:55:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK90-0002uZ-VI; Fri, 28 Nov 2014 11:55:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuK8z-0002uK-1r
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 11:55:25 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	2A/D5-17735-CA268745; Fri, 28 Nov 2014 11:55:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417175722!14467211!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31977 invoked from network); 28 Nov 2014 11:55:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:55:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197705545"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 06:53:30 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuK78-0002eW-LW;
	Fri, 28 Nov 2014 11:53:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuK78-0001mZ-8j;
	Fri, 28 Nov 2014 11:53:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.25145.827135.614216@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 11:53:29 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <54784D44020000780004B576@mail.emea.novell.com>
References: <osstest-31882-mainreport@xen.org>
	<54784D44020000780004B576@mail.emea.novell.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [xen-4.4-testing test] 31882: regressions -
 trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] [xen-4.4-testing test] 31882: regressions - trouble: blocked/broken/fail/pass"):
> On 28.11.14 at 10:07, <Ian.Jackson@eu.citrix.com> wrote:
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31781
> 
> Wasn't the swiotlb problem supposed to be dealt with by now?
> swiotlb=65536 looks to be in place here, yet that still appears to
> not be big enough...

That was just an attempted workaround, which we knew might or might
not work.  David Vrabel posted some patches to lmkl which are supposed
to properly fix it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:55:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK91-0002ug-Au; Fri, 28 Nov 2014 11:55:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuK90-0002uU-8s
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:55:26 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	C9/1C-02698-CA268745; Fri, 28 Nov 2014 11:55:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417175721!11712065!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1761 invoked from network); 28 Nov 2014 11:55:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:55:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197705541"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 06:52:27 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuK67-0002dR-1O;
	Fri, 28 Nov 2014 11:52:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuK66-0001mJ-Hh;
	Fri, 28 Nov 2014 11:52:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.25082.6881.622482@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 11:52:26 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417175391.23604.17.camel@citrix.com>
References: <alpine.DEB.2.00.1411272342370.5756@procyon.dur.ac.uk>
	<1417163231.2372.10.camel@citrix.com>
	<alpine.GSO.2.00.1411280830170.1345@algedi.dur.ac.uk>
	<1417175391.23604.17.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH v2] fix migration failure with xl migrate
	--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: [PATCH v2] fix migration failure with xl migrate --debug"):
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks for reviewing it :-).

> It's pretty big but a large chunk is pretty mechanical. Were you
> intending this for 4.5? (Konrad CCd).

I think (based on reading the thread but not the code) that this ought
to be in 4.5.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:55:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK90-0002uZ-VI; Fri, 28 Nov 2014 11:55:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuK8z-0002uK-1r
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 11:55:25 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	2A/D5-17735-CA268745; Fri, 28 Nov 2014 11:55:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417175722!14467211!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31977 invoked from network); 28 Nov 2014 11:55:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:55:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197705545"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 06:53:30 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuK78-0002eW-LW;
	Fri, 28 Nov 2014 11:53:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuK78-0001mZ-8j;
	Fri, 28 Nov 2014 11:53:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.25145.827135.614216@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 11:53:29 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <54784D44020000780004B576@mail.emea.novell.com>
References: <osstest-31882-mainreport@xen.org>
	<54784D44020000780004B576@mail.emea.novell.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [xen-4.4-testing test] 31882: regressions -
 trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] [xen-4.4-testing test] 31882: regressions - trouble: blocked/broken/fail/pass"):
> On 28.11.14 at 10:07, <Ian.Jackson@eu.citrix.com> wrote:
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31781
> 
> Wasn't the swiotlb problem supposed to be dealt with by now?
> swiotlb=65536 looks to be in place here, yet that still appears to
> not be big enough...

That was just an attempted workaround, which we knew might or might
not work.  David Vrabel posted some patches to lmkl which are supposed
to properly fix it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 11:55:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 11:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuK91-0002ug-Au; Fri, 28 Nov 2014 11:55:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuK90-0002uU-8s
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 11:55:26 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	C9/1C-02698-CA268745; Fri, 28 Nov 2014 11:55:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417175721!11712065!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1761 invoked from network); 28 Nov 2014 11:55:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 11:55:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197705541"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 06:52:27 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuK67-0002dR-1O;
	Fri, 28 Nov 2014 11:52:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuK66-0001mJ-Hh;
	Fri, 28 Nov 2014 11:52:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.25082.6881.622482@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 11:52:26 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417175391.23604.17.camel@citrix.com>
References: <alpine.DEB.2.00.1411272342370.5756@procyon.dur.ac.uk>
	<1417163231.2372.10.camel@citrix.com>
	<alpine.GSO.2.00.1411280830170.1345@algedi.dur.ac.uk>
	<1417175391.23604.17.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH v2] fix migration failure with xl migrate
	--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: [PATCH v2] fix migration failure with xl migrate --debug"):
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks for reviewing it :-).

> It's pretty big but a large chunk is pretty mechanical. Were you
> intending this for 4.5? (Konrad CCd).

I think (based on reading the thread but not the code) that this ought
to be in 4.5.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:01:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKEv-0003Gz-1Z; Fri, 28 Nov 2014 12:01: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 1XuKEt-0003Go-Pi
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:01:31 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	3E/1A-19763-B1468745; Fri, 28 Nov 2014 12:01:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417176087!13833725!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19639 invoked from network); 28 Nov 2014 12:01:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:01:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197707169"
Message-ID: <1417176083.23604.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:01:23 +0000
In-Reply-To: <1417154122-23669-1-git-send-email-cyliu@suse.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] missing chunk of HVM direct kernel boot
	patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 13:55 +0800, Chunyan Liu wrote:
> Found by Stefano, this chunk of the patch was never applied to
> xen-unstable (commit 11dffa2359e8a2629490c14c029c7c7c777b3e47),
> see http://marc.info/?l=qemu-devel&m=140471493425353&w=2.

How strange, "git am" usually makes it pretty difficult to miss hunks.
Sorry about this.

> Signed-off-by: Chunyan Liu <cyliu@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I'm afraid that despite the circumstances this still needs a release ack
from Konrad. Obviously the upside is fixing a partially implemented
feature, but I'm not sure what the downsides are.

Has this been tested with stubdoms, including when this feature is not
used? My biggest concern is that because this function is also used to
build the command line for the stubdom and the stubdom is PV and hence
has at least a ->kernel setting then this new code might break that use
case, by adding these options when they are not wanted. This path is all
a bit tangled so I'm not 100% sure if those fields are actually set or
not.

> ---
>  tools/libxl/libxl_dm.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 3e191c3..b25b574 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -527,6 +527,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          int ioemu_nics = 0;
>  
> +        if (b_info->kernel)
> +            flexarray_vappend(dm_args, "-kernel", b_info->kernel, NULL);
> +
> +        if (b_info->ramdisk)
> +            flexarray_vappend(dm_args, "-initrd", b_info->ramdisk, NULL);
> +
> +        if (b_info->cmdline)
> +            flexarray_vappend(dm_args, "-append", b_info->cmdline, NULL);
> +
>          if (b_info->u.hvm.serial || b_info->u.hvm.serial_list) {
>              if ( b_info->u.hvm.serial && b_info->u.hvm.serial_list )
>              {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:01:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKEv-0003Gz-1Z; Fri, 28 Nov 2014 12:01: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 1XuKEt-0003Go-Pi
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:01:31 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	3E/1A-19763-B1468745; Fri, 28 Nov 2014 12:01:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417176087!13833725!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19639 invoked from network); 28 Nov 2014 12:01:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:01:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197707169"
Message-ID: <1417176083.23604.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:01:23 +0000
In-Reply-To: <1417154122-23669-1-git-send-email-cyliu@suse.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] missing chunk of HVM direct kernel boot
	patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 13:55 +0800, Chunyan Liu wrote:
> Found by Stefano, this chunk of the patch was never applied to
> xen-unstable (commit 11dffa2359e8a2629490c14c029c7c7c777b3e47),
> see http://marc.info/?l=qemu-devel&m=140471493425353&w=2.

How strange, "git am" usually makes it pretty difficult to miss hunks.
Sorry about this.

> Signed-off-by: Chunyan Liu <cyliu@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I'm afraid that despite the circumstances this still needs a release ack
from Konrad. Obviously the upside is fixing a partially implemented
feature, but I'm not sure what the downsides are.

Has this been tested with stubdoms, including when this feature is not
used? My biggest concern is that because this function is also used to
build the command line for the stubdom and the stubdom is PV and hence
has at least a ->kernel setting then this new code might break that use
case, by adding these options when they are not wanted. This path is all
a bit tangled so I'm not 100% sure if those fields are actually set or
not.

> ---
>  tools/libxl/libxl_dm.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 3e191c3..b25b574 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -527,6 +527,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          int ioemu_nics = 0;
>  
> +        if (b_info->kernel)
> +            flexarray_vappend(dm_args, "-kernel", b_info->kernel, NULL);
> +
> +        if (b_info->ramdisk)
> +            flexarray_vappend(dm_args, "-initrd", b_info->ramdisk, NULL);
> +
> +        if (b_info->cmdline)
> +            flexarray_vappend(dm_args, "-append", b_info->cmdline, NULL);
> +
>          if (b_info->u.hvm.serial || b_info->u.hvm.serial_list) {
>              if ( b_info->u.hvm.serial && b_info->u.hvm.serial_list )
>              {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:07:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKKU-0003dJ-R1; Fri, 28 Nov 2014 12:07:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKKT-0003dE-6k
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:07:17 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	23/E4-02957-47568745; Fri, 28 Nov 2014 12:07:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417176434!6321417!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30108 invoked from network); 28 Nov 2014 12:07:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:07:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197708902"
Message-ID: <1417176432.23604.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 28 Nov 2014 12:07:12 +0000
In-Reply-To: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 0/3] Coverity fixes for python
	lowlevel libraries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:

> While Xend is certainly dead and gone, XenServer at the very least still has
> consumers of these python libraries.

AIUI XS mainly uses the xs.c stuff, with the xc.c stuff being mainly
debug utilities.

This is important because while the xs.c is simple and obviously correct
the xc.c patches are a little more involved.

> 
> Konrad: I am requesting a release ack for this.  All 5 issues are bugs with
> the handling of error cases, rather than with the basic functionality
> provided.  With these changes, Coverity is of the opinion that the python
> libraries are perfect (0 issues), and I feel this is a worthy position to be
> in for 4.5
> 
> Andrew Cooper (3):
>   python/xc: Fix multiple issues in pyflask_context_to_sid()
>   python/xc: Fix multiple issues in pyxc_readconsolering()
>   python/xs: Correct the indirection of the NULL xshandle() check
> 
>  tools/python/xen/lowlevel/xc/xc.c |   34 +++++++++-------------------------
>  tools/python/xen/lowlevel/xs/xs.c |    2 +-
>  2 files changed, 10 insertions(+), 26 deletions(-)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:07:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKKU-0003dJ-R1; Fri, 28 Nov 2014 12:07:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKKT-0003dE-6k
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:07:17 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	23/E4-02957-47568745; Fri, 28 Nov 2014 12:07:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417176434!6321417!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30108 invoked from network); 28 Nov 2014 12:07:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:07:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197708902"
Message-ID: <1417176432.23604.23.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 28 Nov 2014 12:07:12 +0000
In-Reply-To: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 0/3] Coverity fixes for python
	lowlevel libraries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:

> While Xend is certainly dead and gone, XenServer at the very least still has
> consumers of these python libraries.

AIUI XS mainly uses the xs.c stuff, with the xc.c stuff being mainly
debug utilities.

This is important because while the xs.c is simple and obviously correct
the xc.c patches are a little more involved.

> 
> Konrad: I am requesting a release ack for this.  All 5 issues are bugs with
> the handling of error cases, rather than with the basic functionality
> provided.  With these changes, Coverity is of the opinion that the python
> libraries are perfect (0 issues), and I feel this is a worthy position to be
> in for 4.5
> 
> Andrew Cooper (3):
>   python/xc: Fix multiple issues in pyflask_context_to_sid()
>   python/xc: Fix multiple issues in pyxc_readconsolering()
>   python/xs: Correct the indirection of the NULL xshandle() check
> 
>  tools/python/xen/lowlevel/xc/xc.c |   34 +++++++++-------------------------
>  tools/python/xen/lowlevel/xs/xs.c |    2 +-
>  2 files changed, 10 insertions(+), 26 deletions(-)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:09:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKMv-0003iz-Bf; Fri, 28 Nov 2014 12:09:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKMt-0003it-UJ
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:09:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	42/69-15461-A0668745; Fri, 28 Nov 2014 12:09:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417176584!12028289!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15309 invoked from network); 28 Nov 2014 12:09:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:09:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197432083"
Message-ID: <1417176581.23604.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:09:41 +0000
In-Reply-To: <547643C8.5000806@citrix.com>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Wei Liu <wei.liu2@citrix.com>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] fix segfault in xl migrate --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, 2014-11-26 at 21:19 +0000, Andrew Cooper wrote:
> On 26/11/2014 19:54, M A Young wrote:
> 
> > If differences are found during the verification phase of xl migrate
> > --debug then it is likely to crash with a segfault because the
> > bogus 
> > pagebuf->pfn_types[pfn] is used in a print statement instead of
> > pfn_type[pfn] . 
> > 
> > Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
> > 
> > 
> > 
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Needs a release ack if this is to be for 4.5, Konrad CCd.

On the one hand this fixes an issue which is only present if you enable
debug/verify mode, so it's not that critical. On the other hand it only
touches code which is used if you enable debug/verify mode, so it's not
that risky.

I'm inclined towards the apply it for 4.5 end of the scale...

> 
> > xl migrate --debug can segfault because pagebuf->pfn_types[pfn] is
> > used in a print statement instead of pfn_type[pfn] 
> > 
> > --- xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c.orig	2014-10-24 15:22:40.000000000 +0100
> > +++ xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c	2014-11-25 21:01:16.604081467 +0000
> > @@ -1404,7 +1404,7 @@
> >                  int v;
> >  
> >                  DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
> > -                        "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
> > +                        "actualcs=%08lx\n", pfn, pfn_type[pfn],
> >                          csum_page(region_base + i * PAGE_SIZE),
> >                          csum_page(buf));
> >  
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:09:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKMv-0003iz-Bf; Fri, 28 Nov 2014 12:09:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKMt-0003it-UJ
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:09:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	42/69-15461-A0668745; Fri, 28 Nov 2014 12:09:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417176584!12028289!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15309 invoked from network); 28 Nov 2014 12:09:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:09:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197432083"
Message-ID: <1417176581.23604.25.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:09:41 +0000
In-Reply-To: <547643C8.5000806@citrix.com>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Wei Liu <wei.liu2@citrix.com>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] fix segfault in xl migrate --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, 2014-11-26 at 21:19 +0000, Andrew Cooper wrote:
> On 26/11/2014 19:54, M A Young wrote:
> 
> > If differences are found during the verification phase of xl migrate
> > --debug then it is likely to crash with a segfault because the
> > bogus 
> > pagebuf->pfn_types[pfn] is used in a print statement instead of
> > pfn_type[pfn] . 
> > 
> > Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
> > 
> > 
> > 
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Needs a release ack if this is to be for 4.5, Konrad CCd.

On the one hand this fixes an issue which is only present if you enable
debug/verify mode, so it's not that critical. On the other hand it only
touches code which is used if you enable debug/verify mode, so it's not
that risky.

I'm inclined towards the apply it for 4.5 end of the scale...

> 
> > xl migrate --debug can segfault because pagebuf->pfn_types[pfn] is
> > used in a print statement instead of pfn_type[pfn] 
> > 
> > --- xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c.orig	2014-10-24 15:22:40.000000000 +0100
> > +++ xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c	2014-11-25 21:01:16.604081467 +0000
> > @@ -1404,7 +1404,7 @@
> >                  int v;
> >  
> >                  DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
> > -                        "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
> > +                        "actualcs=%08lx\n", pfn, pfn_type[pfn],
> >                          csum_page(region_base + i * PAGE_SIZE),
> >                          csum_page(buf));
> >  
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:10:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 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 1XuKNl-0003n2-PR; Fri, 28 Nov 2014 12:10:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKNk-0003mv-LK
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:10:40 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	A7/07-03145-F3668745; Fri, 28 Nov 2014 12:10:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417176638!11739402!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27190 invoked from network); 28 Nov 2014 12:10:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:10:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197709652"
Message-ID: <1417176635.23604.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:10:35 +0000
In-Reply-To: <20141125155421.GF29886@konrad-lan.dumpdata.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
	<20141125103940.GC28315@zion.uk.xensource.com>
	<20141125111522.GD28315@zion.uk.xensource.com>
	<1416915667.7176.39.camel@Abyss> <547498F2.70201@oracle.com>
	<20141125155421.GF29886@konrad-lan.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, stefano.stabellini@eu.citrix.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 10:54 -0500, Konrad Rzeszutek Wilk wrote:
> > >>Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > >>Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > >>Cc: Ian Campbell <ian.campbell@citrix.com>
> > >>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > >>Cc: Dario Faggioli <dario.faggioli@citrix.com>
> > >>
> > >If this end up being the approach, it can have the following:
> > >
> > >Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
> > 
> > Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked +Applied.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:10:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 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 1XuKNl-0003n2-PR; Fri, 28 Nov 2014 12:10:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKNk-0003mv-LK
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:10:40 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	A7/07-03145-F3668745; Fri, 28 Nov 2014 12:10:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417176638!11739402!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27190 invoked from network); 28 Nov 2014 12:10:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:10:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197709652"
Message-ID: <1417176635.23604.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:10:35 +0000
In-Reply-To: <20141125155421.GF29886@konrad-lan.dumpdata.com>
References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141124104127.GF30053@zion.uk.xensource.com>
	<20141124104703.GH30053@zion.uk.xensource.com>
	<54735343.1020208@oracle.com>
	<20141125103940.GC28315@zion.uk.xensource.com>
	<20141125111522.GD28315@zion.uk.xensource.com>
	<1416915667.7176.39.camel@Abyss> <547498F2.70201@oracle.com>
	<20141125155421.GF29886@konrad-lan.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, stefano.stabellini@eu.citrix.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller
 bitmap into a larger one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 10:54 -0500, Konrad Rzeszutek Wilk wrote:
> > >>Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > >>Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > >>Cc: Ian Campbell <ian.campbell@citrix.com>
> > >>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > >>Cc: Dario Faggioli <dario.faggioli@citrix.com>
> > >>
> > >If this end up being the approach, it can have the following:
> > >
> > >Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
> > 
> > Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked +Applied.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:11:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKOA-0003qc-5f; Fri, 28 Nov 2014 12:11:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKO8-0003qB-N6
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:11:04 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	93/3F-18267-75668745; Fri, 28 Nov 2014 12:11:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417176662!10077559!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2968 invoked from network); 28 Nov 2014 12:11:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:11:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197432348"
Message-ID: <1417176659.23604.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:10:59 +0000
In-Reply-To: <5A6CF3C5-F945-4169-AF21-4C2737CA5D17@oracle.com>
References: <1417080386-6662-1-git-send-email-olaf@aepfle.de>
	<5A6CF3C5-F945-4169-AF21-4C2737CA5D17@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Olaf Hering <olaf@aepfle.de>, Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] INSTALL: correct EXTRA_CFLAGS handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 10:17 -0500, Konrad Rzeszutek Wilk wrote:
> On November 27, 2014 4:26:26 AM EST, Olaf Hering <olaf@aepfle.de> wrote:
> >The already documented configure patch was not applied.
> >Adjust documentation to describe existing behaviour.
> >
> >Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >Cc: Ian Campbell <ian.campbell@citrix.com>
> >Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Reviewed-by: me.
> 
> Don't need an release ack for it.

Applied.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:11:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKOA-0003qc-5f; Fri, 28 Nov 2014 12:11:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKO8-0003qB-N6
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:11:04 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	93/3F-18267-75668745; Fri, 28 Nov 2014 12:11:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417176662!10077559!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2968 invoked from network); 28 Nov 2014 12:11:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:11:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197432348"
Message-ID: <1417176659.23604.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:10:59 +0000
In-Reply-To: <5A6CF3C5-F945-4169-AF21-4C2737CA5D17@oracle.com>
References: <1417080386-6662-1-git-send-email-olaf@aepfle.de>
	<5A6CF3C5-F945-4169-AF21-4C2737CA5D17@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Olaf Hering <olaf@aepfle.de>, Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] INSTALL: correct EXTRA_CFLAGS handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 10:17 -0500, Konrad Rzeszutek Wilk wrote:
> On November 27, 2014 4:26:26 AM EST, Olaf Hering <olaf@aepfle.de> wrote:
> >The already documented configure patch was not applied.
> >Adjust documentation to describe existing behaviour.
> >
> >Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >Cc: Ian Campbell <ian.campbell@citrix.com>
> >Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Reviewed-by: me.
> 
> Don't need an release ack for it.

Applied.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:11:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKOc-0003vv-LR; Fri, 28 Nov 2014 12:11:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKOa-0003vd-Uj
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:11:33 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	F0/A0-03148-47668745; Fri, 28 Nov 2014 12:11:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417176690!11739678!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2010 invoked from network); 28 Nov 2014 12:11:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:11:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197709815"
Message-ID: <1417176688.23604.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:11:28 +0000
In-Reply-To: <20141126210940.GA15328@laptop.dumpdata.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
	<370F66B9-E96D-4BE2-9E08-132CCBD28E42@citrix.com>
	<20141126210940.GA15328@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
Content-Length: 1735
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Dave Scott <Dave.Scott@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Zheng Li <dev@zheng.li>, Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>, Ian
	Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDE0LTExLTI2IGF0IDE2OjA5IC0wNTAwLCBLb25yYWQgUnplc3p1dGVrIFdpbGsg
d3JvdGU6Cj4gT24gV2VkLCBOb3YgMjYsIDIwMTQgYXQgMDg6NDQ6NDFQTSArMDAwMCwgRGF2ZSBT
Y290dCB3cm90ZToKPiA+IAo+ID4gPiBPbiAyNiBOb3YgMjAxNCwgYXQgMTg6NDEsIEtvbnJhZCBS
emVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4gd3JvdGU6Cj4gPiA+IAo+ID4g
PiBPbiBXZWQsIE5vdiAyNiwgMjAxNCBhdCAwNjoyNDoxMVBNICswMDAwLCBEYXZlIFNjb3R0IHdy
b3RlOgo+ID4gPj4gCj4gPiA+Pj4gT24gMjYgTm92IDIwMTQsIGF0IDE1OjM4LCBaaGVuZyBMaSA8
ZGV2QHpoZW5nLmxpPiB3cm90ZToKPiA+ID4+PiAKPiA+ID4+PiBPbiAyNi8xMS8yMDE0IDE1OjA5
LCBBbmRyZXcgQ29vcGVyIHdyb3RlOgo+ID4gPj4+PiBUaGlzIG1ha2VzIGZpZWxkcyAwIGFuZCAx
IHRydWUgbW9yZSBvZnRlbiB0aGFuIHRoZXkgc2hvdWxkIGJlLCByZXN1bHRpbmcKPiA+ID4+Pj4g
cHJvYmxlbXMgd2hlbiBoYW5kbGluZyBldmVudHMuCj4gPiA+Pj4gCj4gPiA+Pj4gSW5kZWVkLCBs
b29rcyBsaWtlIGEgbWlzdGFrZSBJIG1hZGUgd2hlbiByZXdyaXRpbmcgdGhlIGxvZ2ljIHRlcm1z
IGxhdGVseS4gVGhlIHJlc3VsdCBpcyBQT0xMVVAgb3IgUE9MTEVSUiBldmVudHMgYmVpbmcgcmV0
dXJuZWQgaW4gbW9yZSBjYXRlZ29yaWVzIHRoYW4gd2UnZCBpbnRlcmVzdC4gVGhhbmtzIGZvciBm
aXhpbmcgdGhpcyEKPiA+ID4+PiAKPiA+ID4+PiBBY2tlZC1ieTogWmhlbmcgTGkgPGRldkB6aGVu
Zy5saT4KPiA+ID4+IAo+ID4gPj4gVGhpcyBhbHNvIGxvb2tzIGZpbmUgdG8gbWUKPiA+ID4+IAo+
ID4gPj4gQWNrZWQtYnk6IERhdmlkIFNjb3R0IDxkYXZlLnNjb3R0QGNpdHJpeC5jb20+Cj4gPiA+
IAo+ID4gPiBXb3VsZCBpdCBiZSBwb3NzaWJsZSB0byBnZXQgYW4gUmV2aWV3ZWQtYnkgcGxlYXNl
Pwo+ID4gCj4gPiBJ4oCZbGwgY2VydGFpbmx5IG9mZmVyCj4gPiAKPiA+IFJldmlld2VkLWJ5OiBE
YXZpZCBTY290dCA8ZGF2ZS5zY290dEBjaXRyaXguY29tPgo+IAo+IE9LLCBSZWxlYXNlLUFja2Vk
LWJ5OiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CgpBcHBs
aWVkLCB0aGFua3MuCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:11:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKOc-0003vv-LR; Fri, 28 Nov 2014 12:11:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKOa-0003vd-Uj
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:11:33 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	F0/A0-03148-47668745; Fri, 28 Nov 2014 12:11:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417176690!11739678!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2010 invoked from network); 28 Nov 2014 12:11:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:11:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197709815"
Message-ID: <1417176688.23604.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:11:28 +0000
In-Reply-To: <20141126210940.GA15328@laptop.dumpdata.com>
References: <1417014580-27611-1-git-send-email-andrew.cooper3@citrix.com>
	<5475F3DF.2070907@zheng.li>
	<0CD34053-C7C1-423B-9D00-E455B7099968@citrix.com>
	<20141126184130.GB13384@laptop.dumpdata.com>
	<370F66B9-E96D-4BE2-9E08-132CCBD28E42@citrix.com>
	<20141126210940.GA15328@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
Content-Length: 1735
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Dave Scott <Dave.Scott@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Zheng Li <dev@zheng.li>, Xen-devel <xen-devel@lists.xen.org>,
	"Zheng Li \(3P\)" <zheng.li3@citrix.com>, Ian
	Jackson <Ian.Jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] tools/oxenstored: Fix | vs & error
 in fd event 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDE0LTExLTI2IGF0IDE2OjA5IC0wNTAwLCBLb25yYWQgUnplc3p1dGVrIFdpbGsg
d3JvdGU6Cj4gT24gV2VkLCBOb3YgMjYsIDIwMTQgYXQgMDg6NDQ6NDFQTSArMDAwMCwgRGF2ZSBT
Y290dCB3cm90ZToKPiA+IAo+ID4gPiBPbiAyNiBOb3YgMjAxNCwgYXQgMTg6NDEsIEtvbnJhZCBS
emVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4gd3JvdGU6Cj4gPiA+IAo+ID4g
PiBPbiBXZWQsIE5vdiAyNiwgMjAxNCBhdCAwNjoyNDoxMVBNICswMDAwLCBEYXZlIFNjb3R0IHdy
b3RlOgo+ID4gPj4gCj4gPiA+Pj4gT24gMjYgTm92IDIwMTQsIGF0IDE1OjM4LCBaaGVuZyBMaSA8
ZGV2QHpoZW5nLmxpPiB3cm90ZToKPiA+ID4+PiAKPiA+ID4+PiBPbiAyNi8xMS8yMDE0IDE1OjA5
LCBBbmRyZXcgQ29vcGVyIHdyb3RlOgo+ID4gPj4+PiBUaGlzIG1ha2VzIGZpZWxkcyAwIGFuZCAx
IHRydWUgbW9yZSBvZnRlbiB0aGFuIHRoZXkgc2hvdWxkIGJlLCByZXN1bHRpbmcKPiA+ID4+Pj4g
cHJvYmxlbXMgd2hlbiBoYW5kbGluZyBldmVudHMuCj4gPiA+Pj4gCj4gPiA+Pj4gSW5kZWVkLCBs
b29rcyBsaWtlIGEgbWlzdGFrZSBJIG1hZGUgd2hlbiByZXdyaXRpbmcgdGhlIGxvZ2ljIHRlcm1z
IGxhdGVseS4gVGhlIHJlc3VsdCBpcyBQT0xMVVAgb3IgUE9MTEVSUiBldmVudHMgYmVpbmcgcmV0
dXJuZWQgaW4gbW9yZSBjYXRlZ29yaWVzIHRoYW4gd2UnZCBpbnRlcmVzdC4gVGhhbmtzIGZvciBm
aXhpbmcgdGhpcyEKPiA+ID4+PiAKPiA+ID4+PiBBY2tlZC1ieTogWmhlbmcgTGkgPGRldkB6aGVu
Zy5saT4KPiA+ID4+IAo+ID4gPj4gVGhpcyBhbHNvIGxvb2tzIGZpbmUgdG8gbWUKPiA+ID4+IAo+
ID4gPj4gQWNrZWQtYnk6IERhdmlkIFNjb3R0IDxkYXZlLnNjb3R0QGNpdHJpeC5jb20+Cj4gPiA+
IAo+ID4gPiBXb3VsZCBpdCBiZSBwb3NzaWJsZSB0byBnZXQgYW4gUmV2aWV3ZWQtYnkgcGxlYXNl
Pwo+ID4gCj4gPiBJ4oCZbGwgY2VydGFpbmx5IG9mZmVyCj4gPiAKPiA+IFJldmlld2VkLWJ5OiBE
YXZpZCBTY290dCA8ZGF2ZS5zY290dEBjaXRyaXguY29tPgo+IAo+IE9LLCBSZWxlYXNlLUFja2Vk
LWJ5OiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CgpBcHBs
aWVkLCB0aGFua3MuCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:12:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12: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 1XuKP2-00044A-49; Fri, 28 Nov 2014 12:12: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 1XuKP0-00043U-WC
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:11:59 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	36/0C-25714-E8668745; Fri, 28 Nov 2014 12:11:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417176716!6277529!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5687 invoked from network); 28 Nov 2014 12:11:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:11:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197432482"
Message-ID: <1417176713.23604.29.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:11:53 +0000
In-Reply-To: <20141125160340.GH29886@konrad-lan.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
	<20141121170103.GA8314@laptop.dumpdata.com>
	<1416924781.32327.23.camel@citrix.com>
	<20141125155130.GE29886@konrad-lan.dumpdata.com>
	<1416931113.11944.7.camel@citrix.com>
	<20141125160340.GH29886@konrad-lan.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>, Chunyan
	Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
 updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 11:03 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 25, 2014 at 03:58:33PM +0000, Ian Campbell wrote:
> > On Tue, 2014-11-25 at 10:51 -0500, Konrad Rzeszutek Wilk wrote:
> > > Right, so with the reassurance text added on:
> > > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > Thanks.
> > 
> > Chunyan, I propose to commit adding the following to the commit text of
> > "[PATCH 1/2 V3] remove domain field in xenstore backend dir":
> > 
> >         The correct way to obtain a domain's name is via
> >         libxl_domid_to_name(), or by reading
> >         from /local/domain/$DOMID/name for toolstacks not using libxl.
> >         
> > Does that sound OK to you?
> 
> Yes.

Thanks, that was really a question for Chunyan, but rather than wait any
longer I've applied with that change.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:12:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12: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 1XuKP2-00044A-49; Fri, 28 Nov 2014 12:12: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 1XuKP0-00043U-WC
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:11:59 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	36/0C-25714-E8668745; Fri, 28 Nov 2014 12:11:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417176716!6277529!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5687 invoked from network); 28 Nov 2014 12:11:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:11:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197432482"
Message-ID: <1417176713.23604.29.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:11:53 +0000
In-Reply-To: <20141125160340.GH29886@konrad-lan.dumpdata.com>
References: <1416378851-32236-1-git-send-email-cyliu@suse.com>
	<21612.32360.328456.516321@mariner.uk.xensource.com>
	<20141119212505.GJ20440@laptop.dumpdata.com>
	<1416497310.14429.20.camel@citrix.com>
	<20141121170103.GA8314@laptop.dumpdata.com>
	<1416924781.32327.23.camel@citrix.com>
	<20141125155130.GE29886@konrad-lan.dumpdata.com>
	<1416931113.11944.7.camel@citrix.com>
	<20141125160340.GH29886@konrad-lan.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>, Chunyan
	Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2 V3] fix rename: xenstore not fully
 updated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 11:03 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 25, 2014 at 03:58:33PM +0000, Ian Campbell wrote:
> > On Tue, 2014-11-25 at 10:51 -0500, Konrad Rzeszutek Wilk wrote:
> > > Right, so with the reassurance text added on:
> > > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > Thanks.
> > 
> > Chunyan, I propose to commit adding the following to the commit text of
> > "[PATCH 1/2 V3] remove domain field in xenstore backend dir":
> > 
> >         The correct way to obtain a domain's name is via
> >         libxl_domid_to_name(), or by reading
> >         from /local/domain/$DOMID/name for toolstacks not using libxl.
> >         
> > Does that sound OK to you?
> 
> Yes.

Thanks, that was really a question for Chunyan, but rather than wait any
longer I've applied with that change.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:12:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 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 1XuKPW-0004Eq-UC; Fri, 28 Nov 2014 12:12:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKPV-0004EJ-1X
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:12:29 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	1D/D1-26652-CA668745; Fri, 28 Nov 2014 12:12:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417176745!13841612!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32511 invoked from network); 28 Nov 2014 12:12:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:12:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197710202"
Message-ID: <1417176743.23604.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:12:23 +0000
In-Reply-To: <20141120194431.GB25423@laptop.dumpdata.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
	<20141119210845.GF20440@laptop.dumpdata.com>
	<20141119212434.GB27349@zion.uk.xensource.com>
	<1416497391.14429.23.camel@citrix.com>
	<20141120154817.GA31452@zion.uk.xensource.com>
	<20141120194431.GB25423@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Zhigang
	Wang <zhigang.x.wang@oracle.com>, Wei Liu <wei.liu2@citrix.com>,
	ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 14:44 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 20, 2014 at 03:48:17PM +0000, Wei Liu wrote:
> > On Thu, Nov 20, 2014 at 03:29:51PM +0000, Ian Campbell wrote:
> > > On Wed, 2014-11-19 at 21:24 +0000, Wei Liu wrote:
> > > > On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > > On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > > > > > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > > > > > And it will cause the xenstore 'memory/targe' calculation wrong:
> > > > > > 
> > > > > >     memory/target = info->target_memkb - info->video_memkb
> > > > > 
> > > > > CC-ing the maintainers.
> > > > > 
> > > > > Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?
> > > > > 
> > > > 
> > > > I don't think this is a regression, it has been broken for quite a
> > > > while.
> > > 
> > > I think so to.
> > > 
> > > On the other hand its a pretty clear bug to use video_memkb == -1 and
> > > we've seen that it causes real issues. The fix is also fairly obvious.
> > > I'm inclined towards suggesting we fix this in 4.5.
> > > 
> > 
> > I concur.
> 
> Lets do it then. RElease-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

APplied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:12:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 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 1XuKPW-0004Eq-UC; Fri, 28 Nov 2014 12:12:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKPV-0004EJ-1X
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:12:29 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	1D/D1-26652-CA668745; Fri, 28 Nov 2014 12:12:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417176745!13841612!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32511 invoked from network); 28 Nov 2014 12:12:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:12:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197710202"
Message-ID: <1417176743.23604.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 28 Nov 2014 12:12:23 +0000
In-Reply-To: <20141120194431.GB25423@laptop.dumpdata.com>
References: <1416302762.17982.1.camel@citrix.com>
	<1416344228-24164-1-git-send-email-zhigang.x.wang@oracle.com>
	<20141119210845.GF20440@laptop.dumpdata.com>
	<20141119212434.GB27349@zion.uk.xensource.com>
	<1416497391.14429.23.camel@citrix.com>
	<20141120154817.GA31452@zion.uk.xensource.com>
	<20141120194431.GB25423@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Zhigang
	Wang <zhigang.x.wang@oracle.com>, Wei Liu <wei.liu2@citrix.com>,
	ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] set pv guest default video_memkb to 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-20 at 14:44 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 20, 2014 at 03:48:17PM +0000, Wei Liu wrote:
> > On Thu, Nov 20, 2014 at 03:29:51PM +0000, Ian Campbell wrote:
> > > On Wed, 2014-11-19 at 21:24 +0000, Wei Liu wrote:
> > > > On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > > On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > > > > > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > > > > > And it will cause the xenstore 'memory/targe' calculation wrong:
> > > > > > 
> > > > > >     memory/target = info->target_memkb - info->video_memkb
> > > > > 
> > > > > CC-ing the maintainers.
> > > > > 
> > > > > Is this an regression as compared to Xen 4.4 or is this also in Xen 4.4?
> > > > > 
> > > > 
> > > > I don't think this is a regression, it has been broken for quite a
> > > > while.
> > > 
> > > I think so to.
> > > 
> > > On the other hand its a pretty clear bug to use video_memkb == -1 and
> > > we've seen that it causes real issues. The fix is also fairly obvious.
> > > I'm inclined towards suggesting we fix this in 4.5.
> > > 
> > 
> > I concur.
> 
> Lets do it then. RElease-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

APplied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:15:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:15:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKS6-0004Y9-GV; Fri, 28 Nov 2014 12:15:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKS5-0004Y0-Iu
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:15:09 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	AF/94-25727-C4768745; Fri, 28 Nov 2014 12:15:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417176906!14435491!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11001 invoked from network); 28 Nov 2014 12:15:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:15:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197710780"
Message-ID: <1417176904.23604.32.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 28 Nov 2014 12:15:04 +0000
In-Reply-To: <547860BF.1000400@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-2-git-send-email-andrew.cooper3@citrix.com>
	<1417174620.23604.12.camel@citrix.com> <547860BF.1000400@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 1/3] python/xc: Fix multiple issues
 in pyflask_context_to_sid()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 11:47 +0000, Andrew Cooper wrote:
> On 28/11/14 11:37, Ian Campbell wrote:
> > On Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:
> >> The error handling from a failed memory allocation should return
> >> PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and continuing
> >> to the memcpy() below, with the dest pointer being NULL.
> >>
> >> Furthermore, the context string is simply an input parameter to the hypercall,
> >> and is not mutated anywhere along the way.  The error handling elsewhere in
> >> the function can be simplified by not duplicating it to start with.
> >>
> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >> Coverity-IDs: 1055305 1055721
> >> CC: Ian Campbell <Ian.Campbell@citrix.com>
> >> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> >> CC: Wei Liu <wei.liu2@citrix.com>
> >> CC: Xen Coverity Team <coverity@xen.org>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >
> > This would have been far more obviously correct for 4.5 if you had stuck
> > to fixing the issue in the first paragraph.
> 
> Hmm - I appear to have missed a detail in the description.  One of the
> CIDs is to do with putting a string in a new buffer without a NUL
> terminator, and passing it as a char* into xc_flask_context_to_sid; the
> issue being that anyone expecting things like strlen() to work will be
> in for a nasty shock.

ISTR a discussion of this interface in Julien's device-tree passthrough
thing a while back and some sort of conclusion that the hypervisor was
supposed to use the len field and not rely on the NULL.

I'm not sure that necessarily invalidates what you are saying, since
even given that throwing a NULL on the end would be friendly to libxc
consumers if nothing else.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:15:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:15:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKS6-0004Y9-GV; Fri, 28 Nov 2014 12:15:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKS5-0004Y0-Iu
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:15:09 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	AF/94-25727-C4768745; Fri, 28 Nov 2014 12:15:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417176906!14435491!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11001 invoked from network); 28 Nov 2014 12:15:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:15:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197710780"
Message-ID: <1417176904.23604.32.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 28 Nov 2014 12:15:04 +0000
In-Reply-To: <547860BF.1000400@citrix.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-2-git-send-email-andrew.cooper3@citrix.com>
	<1417174620.23604.12.camel@citrix.com> <547860BF.1000400@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH for-4.5 1/3] python/xc: Fix multiple issues
 in pyflask_context_to_sid()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 11:47 +0000, Andrew Cooper wrote:
> On 28/11/14 11:37, Ian Campbell wrote:
> > On Thu, 2014-11-27 at 12:34 +0000, Andrew Cooper wrote:
> >> The error handling from a failed memory allocation should return
> >> PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and continuing
> >> to the memcpy() below, with the dest pointer being NULL.
> >>
> >> Furthermore, the context string is simply an input parameter to the hypercall,
> >> and is not mutated anywhere along the way.  The error handling elsewhere in
> >> the function can be simplified by not duplicating it to start with.
> >>
> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >> Coverity-IDs: 1055305 1055721
> >> CC: Ian Campbell <Ian.Campbell@citrix.com>
> >> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> >> CC: Wei Liu <wei.liu2@citrix.com>
> >> CC: Xen Coverity Team <coverity@xen.org>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >
> > This would have been far more obviously correct for 4.5 if you had stuck
> > to fixing the issue in the first paragraph.
> 
> Hmm - I appear to have missed a detail in the description.  One of the
> CIDs is to do with putting a string in a new buffer without a NUL
> terminator, and passing it as a char* into xc_flask_context_to_sid; the
> issue being that anyone expecting things like strlen() to work will be
> in for a nasty shock.

ISTR a discussion of this interface in Julien's device-tree passthrough
thing a while back and some sort of conclusion that the hypervisor was
supposed to use the len field and not rely on the NULL.

I'm not sure that necessarily invalidates what you are saying, since
even given that throwing a NULL on the end would be friendly to libxc
consumers if nothing else.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:26:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12: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 1XuKcw-00050A-Rz; Fri, 28 Nov 2014 12:26: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@citrix.com>) id 1XuKcv-000505-Sa
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:26:21 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	5E/9E-22737-DE968745; Fri, 28 Nov 2014 12:26:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417177579!9744953!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30230 invoked from network); 28 Nov 2014 12:26:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:26:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197713167"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 07:26:18 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuKcs-0003Zv-1W;
	Fri, 28 Nov 2014 12:26:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuKcr-0001rZ-Ef;
	Fri, 28 Nov 2014 12:26:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.27112.826272.933990@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 12:26:16 +0000
To: longtao.pang <longtaox.pang@intel.com>
In-Reply-To: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: robert.hu@intel.com, wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	di.zheng@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/4] Introduction of the patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

longtao.pang writes ("[OSSTEST PATCH 0/4] Introduction of the patches."):
> We updated these patchs about adding Nested test job into OSSTest.

Thanks for your contribution.

Having some testing of nested HVM would be good.

But I'm not convinced that these patches take the right approach to
achieving that.  There seems to be a great deal of duplication of
code.  I think we should have a conversation about what moving parts
are necessary for nested HVM testing.

I would guess that you could reuse ts-debian-hvm-install for the
initial install of the L1 guest, and then ts-xen-install to install
Xen on it.  Finally, you could run some other ts-* scripts to install
your L2 guests.  I think you would probably find that there are only
some small changes needed to make those existing scripts flexible
enough.

And I don't understand why you need to rebuild anything.  Surely the
already-built hypervisor and tools ought to work just as well in the
L1 guest ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:26:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12: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 1XuKcw-00050A-Rz; Fri, 28 Nov 2014 12:26: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@citrix.com>) id 1XuKcv-000505-Sa
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:26:21 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	5E/9E-22737-DE968745; Fri, 28 Nov 2014 12:26:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417177579!9744953!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30230 invoked from network); 28 Nov 2014 12:26:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:26:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197713167"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 07:26:18 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuKcs-0003Zv-1W;
	Fri, 28 Nov 2014 12:26:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuKcr-0001rZ-Ef;
	Fri, 28 Nov 2014 12:26:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.27112.826272.933990@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 12:26:16 +0000
To: longtao.pang <longtaox.pang@intel.com>
In-Reply-To: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: robert.hu@intel.com, wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	di.zheng@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/4] Introduction of the patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

longtao.pang writes ("[OSSTEST PATCH 0/4] Introduction of the patches."):
> We updated these patchs about adding Nested test job into OSSTest.

Thanks for your contribution.

Having some testing of nested HVM would be good.

But I'm not convinced that these patches take the right approach to
achieving that.  There seems to be a great deal of duplication of
code.  I think we should have a conversation about what moving parts
are necessary for nested HVM testing.

I would guess that you could reuse ts-debian-hvm-install for the
initial install of the L1 guest, and then ts-xen-install to install
Xen on it.  Finally, you could run some other ts-* scripts to install
your L2 guests.  I think you would probably find that there are only
some small changes needed to make those existing scripts flexible
enough.

And I don't understand why you need to rebuild anything.  Surely the
already-built hypervisor and tools ought to work just as well in the
L1 guest ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:27:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKdf-000531-9J; Fri, 28 Nov 2014 12:27:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XuKdd-00052o-Lt
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:27:05 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	6A/4A-27785-91A68745; Fri, 28 Nov 2014 12:27:05 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417177623!8407218!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20053 invoked from network); 28 Nov 2014 12:27:04 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 12:27:04 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=0KU4X0w1yzK9cfRmUGGE4x2stHaJd/KtysOaYujt3kkeHQKWZt5/KPXuMM5OWDrF/uMnOlQxv+R6apby9wL7IZobt/GBppxZ3C9Nig51uko3/QY8VjBfK58qkK9IJcnj6JpegMIUrMxaQf837a5b5LIBLkH2NNigtt0kpT3JpO6AL3SY68j2ZT6eQMGmlIf/iBzs8DKqntMGcK2bEtBbFdp247ChyFiNEbAC60k1cKLJ0Iqaykdap/xNht4c7W4Ey2XOtY5naHcNt0ywdLB2ikWied6i4RQxKq0C0ipYCZ/DSx+CozANPm06M7wVnrdEF163LoPUtsfxFJ3Ow7wT9g==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=from:to
	:cc:subject:date:message-id; s=default; bh=GVw5tx1nHKV2OTh/AGkeC
	3Qzzy4=; b=EiIwPpPbBYDCbnVX/O8odv9NWfMeYD/j5q+NN+H9Ob99vmc3T+j8p
	3iMVceE9EAVpll7pkZjOEs+PAhDJtJcBtV+Ocw6WB9ZOZiofF27+28Gb9qPPpJF0
	jQFg2BnNJY8Jd8n/UBJ6R0gmgXpUXH4vK0Z1R3X7XONZz6++N4PZzab6/MaOUP4q
	Qvvyl26lx5DRSo/r0X/t9VaWqHM6gvhvnrhIXiUR1Hpti7TAtN4lXnd+AZWPnCo1
	pR1YK5M+E5yY/2/LLOpFvYwaFkiPeddUsRu46o977XLKNck0OB/WBwA8mmJSRpVL
	NwbtrZ543sQtwr2a2Pvq3J4rkEQhg34/g==
Received: (qmail 10902 invoked from network); 28 Nov 2014 14:27:02 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	28 Nov 2014 14:27:02 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 675EA803DF
	for <xen-devel@lists.xenproject.org>;
	Fri, 28 Nov 2014 14:27:02 +0200 (EET)
Received: (qmail 27648 invoked from network); 28 Nov 2014 14:27:02 +0200
Received: from xen.dsd.ro (HELO xen.dsd.bitdefender.biz)
	(rcojocaru@bitdefender.com@10.10.14.109)
	by smtp02.buh.bitdefender.net with AES256-SHA encrypted SMTP;
	28 Nov 2014 14:27:02 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: xen-devel@lists.xenproject.org
Date: Fri, 28 Nov 2014 14:26:48 +0200
Message-Id: <1417177608-6705-1-git-send-email-rcojocaru@bitdefender.com>
X-Mailer: git-send-email 1.7.9.5
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.57992
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 373737,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_NO_CONTENT_TYPE;
	NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS;
	NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled], URL: [Enabled], RTDA:
	[Enabled, Hit: No, Details: v2.0.9; Id: 2m1ghdn.197r0b706.ltsp],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] xenstore: Clarify xs_open() semantics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 to the xs_open() comments in xenstore.h. The text has been
taken almost verbatim from a xen-devel email by Ian Campbell,
and confirmed as accurate by Ian Jackson.

Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Suggested-off-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/xenstore/include/xenstore.h |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/tools/xenstore/include/xenstore.h b/tools/xenstore/include/xenstore.h
index fdf5e76..b4b113e 100644
--- a/tools/xenstore/include/xenstore.h
+++ b/tools/xenstore/include/xenstore.h
@@ -59,10 +59,20 @@ typedef uint32_t xs_transaction_t;
 /* On failure, these routines set errno. */
 
 /* Open a connection to the xs daemon.
- * Attempts to make a connection over the socket interface, 
+ * Attempts to make a connection over the socket interface,
  * and if it fails, then over the  xenbus interface.
  * Mode 0 specifies read-write access, XS_OPEN_READONLY for
  * read-only access.
+ *
+ * * Connections made with xs_open(0) (which might be shared page or
+ *   socket based) are only guaranteed to work in the parent after
+ *   fork.
+ * * Connections made with xs_open(XS_OPEN_SOCKETONLY) will be usable
+ *   in either the parent or the child after fork, but not both.
+ * * xs_daemon_open*() and xs_domain_open() are deprecated synonyms
+ *   for xs_open(0).
+ * * XS_OPEN_READONLY has no bearing on any of this.
+ *
  * Returns a handle or NULL.
  */
 struct xs_handle *xs_open(unsigned long flags);
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:27:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKdf-000531-9J; Fri, 28 Nov 2014 12:27:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XuKdd-00052o-Lt
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:27:05 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	6A/4A-27785-91A68745; Fri, 28 Nov 2014 12:27:05 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417177623!8407218!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20053 invoked from network); 28 Nov 2014 12:27:04 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 12:27:04 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=0KU4X0w1yzK9cfRmUGGE4x2stHaJd/KtysOaYujt3kkeHQKWZt5/KPXuMM5OWDrF/uMnOlQxv+R6apby9wL7IZobt/GBppxZ3C9Nig51uko3/QY8VjBfK58qkK9IJcnj6JpegMIUrMxaQf837a5b5LIBLkH2NNigtt0kpT3JpO6AL3SY68j2ZT6eQMGmlIf/iBzs8DKqntMGcK2bEtBbFdp247ChyFiNEbAC60k1cKLJ0Iqaykdap/xNht4c7W4Ey2XOtY5naHcNt0ywdLB2ikWied6i4RQxKq0C0ipYCZ/DSx+CozANPm06M7wVnrdEF163LoPUtsfxFJ3Ow7wT9g==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=from:to
	:cc:subject:date:message-id; s=default; bh=GVw5tx1nHKV2OTh/AGkeC
	3Qzzy4=; b=EiIwPpPbBYDCbnVX/O8odv9NWfMeYD/j5q+NN+H9Ob99vmc3T+j8p
	3iMVceE9EAVpll7pkZjOEs+PAhDJtJcBtV+Ocw6WB9ZOZiofF27+28Gb9qPPpJF0
	jQFg2BnNJY8Jd8n/UBJ6R0gmgXpUXH4vK0Z1R3X7XONZz6++N4PZzab6/MaOUP4q
	Qvvyl26lx5DRSo/r0X/t9VaWqHM6gvhvnrhIXiUR1Hpti7TAtN4lXnd+AZWPnCo1
	pR1YK5M+E5yY/2/LLOpFvYwaFkiPeddUsRu46o977XLKNck0OB/WBwA8mmJSRpVL
	NwbtrZ543sQtwr2a2Pvq3J4rkEQhg34/g==
Received: (qmail 10902 invoked from network); 28 Nov 2014 14:27:02 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	28 Nov 2014 14:27:02 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 675EA803DF
	for <xen-devel@lists.xenproject.org>;
	Fri, 28 Nov 2014 14:27:02 +0200 (EET)
Received: (qmail 27648 invoked from network); 28 Nov 2014 14:27:02 +0200
Received: from xen.dsd.ro (HELO xen.dsd.bitdefender.biz)
	(rcojocaru@bitdefender.com@10.10.14.109)
	by smtp02.buh.bitdefender.net with AES256-SHA encrypted SMTP;
	28 Nov 2014 14:27:02 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: xen-devel@lists.xenproject.org
Date: Fri, 28 Nov 2014 14:26:48 +0200
Message-Id: <1417177608-6705-1-git-send-email-rcojocaru@bitdefender.com>
X-Mailer: git-send-email 1.7.9.5
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.57992
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 373737,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_NO_CONTENT_TYPE;
	NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS;
	NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled], URL: [Enabled], RTDA:
	[Enabled, Hit: No, Details: v2.0.9; Id: 2m1ghdn.197r0b706.ltsp],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] xenstore: Clarify xs_open() semantics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 to the xs_open() comments in xenstore.h. The text has been
taken almost verbatim from a xen-devel email by Ian Campbell,
and confirmed as accurate by Ian Jackson.

Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Suggested-off-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/xenstore/include/xenstore.h |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/tools/xenstore/include/xenstore.h b/tools/xenstore/include/xenstore.h
index fdf5e76..b4b113e 100644
--- a/tools/xenstore/include/xenstore.h
+++ b/tools/xenstore/include/xenstore.h
@@ -59,10 +59,20 @@ typedef uint32_t xs_transaction_t;
 /* On failure, these routines set errno. */
 
 /* Open a connection to the xs daemon.
- * Attempts to make a connection over the socket interface, 
+ * Attempts to make a connection over the socket interface,
  * and if it fails, then over the  xenbus interface.
  * Mode 0 specifies read-write access, XS_OPEN_READONLY for
  * read-only access.
+ *
+ * * Connections made with xs_open(0) (which might be shared page or
+ *   socket based) are only guaranteed to work in the parent after
+ *   fork.
+ * * Connections made with xs_open(XS_OPEN_SOCKETONLY) will be usable
+ *   in either the parent or the child after fork, but not both.
+ * * xs_daemon_open*() and xs_domain_open() are deprecated synonyms
+ *   for xs_open(0).
+ * * XS_OPEN_READONLY has no bearing on any of this.
+ *
  * Returns a handle or NULL.
  */
 struct xs_handle *xs_open(unsigned long flags);
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:31:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKi4-0005Ip-0S; Fri, 28 Nov 2014 12:31:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuKi3-0005Ik-HE
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:31:39 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	15/48-18267-A2B68745; Fri, 28 Nov 2014 12:31:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417177897!14478348!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19063 invoked from network); 28 Nov 2014 12:31:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:31:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197436312"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 07:31:36 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuKhz-0003h5-P0;
	Fri, 28 Nov 2014 12:31:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuKhz-0001sO-B1;
	Fri, 28 Nov 2014 12:31:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.27430.789784.210615@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 12:31:34 +0000
To: Razvan Cojocaru <rcojocaru@bitdefender.com>
In-Reply-To: <1417177608-6705-1-git-send-email-rcojocaru@bitdefender.com>
References: <1417177608-6705-1-git-send-email-rcojocaru@bitdefender.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, wei.liu2@citrix.com,
	ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] xenstore: Clarify xs_open() semantics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Razvan Cojocaru writes ("[PATCH] xenstore: Clarify xs_open() semantics"):
> Added to the xs_open() comments in xenstore.h. The text has been
> taken almost verbatim from a xen-devel email by Ian Campbell,
> and confirmed as accurate by Ian Jackson.
> 
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
> Suggested-off-by: Ian Campbell <Ian.Campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:31:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKi4-0005Ip-0S; Fri, 28 Nov 2014 12:31:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuKi3-0005Ik-HE
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:31:39 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	15/48-18267-A2B68745; Fri, 28 Nov 2014 12:31:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417177897!14478348!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19063 invoked from network); 28 Nov 2014 12:31:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:31:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197436312"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 07:31:36 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuKhz-0003h5-P0;
	Fri, 28 Nov 2014 12:31:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuKhz-0001sO-B1;
	Fri, 28 Nov 2014 12:31:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.27430.789784.210615@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 12:31:34 +0000
To: Razvan Cojocaru <rcojocaru@bitdefender.com>
In-Reply-To: <1417177608-6705-1-git-send-email-rcojocaru@bitdefender.com>
References: <1417177608-6705-1-git-send-email-rcojocaru@bitdefender.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, wei.liu2@citrix.com,
	ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] xenstore: Clarify xs_open() semantics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Razvan Cojocaru writes ("[PATCH] xenstore: Clarify xs_open() semantics"):
> Added to the xs_open() comments in xenstore.h. The text has been
> taken almost verbatim from a xen-devel email by Ian Campbell,
> and confirmed as accurate by Ian Jackson.
> 
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
> Suggested-off-by: Ian Campbell <Ian.Campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:33:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKjN-0005ZA-G3; Fri, 28 Nov 2014 12:33:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKjM-0005Z2-5P
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:33:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0F/93-09842-B7B68745; Fri, 28 Nov 2014 12:32:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417177977!12060793!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12760 invoked from network); 28 Nov 2014 12:32:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:32:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197436901"
Message-ID: <1417177975.23604.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 28 Nov 2014 12:32:55 +0000
In-Reply-To: <5477671C.4010500@linaro.org>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<5477671C.4010500@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:02 +0000, Julien Grall wrote:
> I propose to reword the commit message into:

You'll want to change the code comment too I think.

> 
> xen/arm: Handle platforms with edge-triggered virtual timer
> 
> Some platforms (such as the ARMv8 model) uses edge-triggered interrupt
> for the virtual timer. Even if the timer output signal is masked in the
> context switch, the GIC will keep track that of any raised interrupt
> while the IRQs has been disabled. As soon as the IRQs are re-enabled,
> the virtual interrupt timer will be injected to Xen.
> 
> The interrupt handler doesn't except to the receive the IRQ and will
> crash if an idle vCPU is running:
> 
> (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
> (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
> (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
> (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
> (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
> (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
> (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
> (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
> (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
> (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
> (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
> (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
> (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
> (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
> (XEN)    [<0000000000000001>] 0000000000000001
> 
> The proper solution would be context/switching the virtual interrupt
> state at the GIC level. This would also avoid masking the output signal
> and requires specific handling in the guest OS.
> 
> Sadly, this solution require some refactoring which would miss the Xen
> 4.5 release.
> 
> For now implement a temporary solution which ignore the interrupt when
> the idle VCPU is running.
> 
> Regards,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:33:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKjN-0005ZA-G3; Fri, 28 Nov 2014 12:33:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKjM-0005Z2-5P
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:33:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0F/93-09842-B7B68745; Fri, 28 Nov 2014 12:32:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417177977!12060793!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12760 invoked from network); 28 Nov 2014 12:32:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:32:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197436901"
Message-ID: <1417177975.23604.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 28 Nov 2014 12:32:55 +0000
In-Reply-To: <5477671C.4010500@linaro.org>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<5477671C.4010500@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:02 +0000, Julien Grall wrote:
> I propose to reword the commit message into:

You'll want to change the code comment too I think.

> 
> xen/arm: Handle platforms with edge-triggered virtual timer
> 
> Some platforms (such as the ARMv8 model) uses edge-triggered interrupt
> for the virtual timer. Even if the timer output signal is masked in the
> context switch, the GIC will keep track that of any raised interrupt
> while the IRQs has been disabled. As soon as the IRQs are re-enabled,
> the virtual interrupt timer will be injected to Xen.
> 
> The interrupt handler doesn't except to the receive the IRQ and will
> crash if an idle vCPU is running:
> 
> (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
> (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
> (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
> (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
> (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
> (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
> (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
> (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
> (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
> (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
> (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
> (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
> (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
> (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
> (XEN)    [<0000000000000001>] 0000000000000001
> 
> The proper solution would be context/switching the virtual interrupt
> state at the GIC level. This would also avoid masking the output signal
> and requires specific handling in the guest OS.
> 
> Sadly, this solution require some refactoring which would miss the Xen
> 4.5 release.
> 
> For now implement a temporary solution which ignore the interrupt when
> the idle VCPU is running.
> 
> Regards,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:42:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKsJ-0005nC-HD; Fri, 28 Nov 2014 12:42:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKsI-0005n7-8u
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 12:42:14 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	79/48-16982-5AD68745; Fri, 28 Nov 2014 12:42:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417178531!14424944!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2935 invoked from network); 28 Nov 2014 12:42:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:42:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197716254"
Message-ID: <1417178529.23604.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 12:42:09 +0000
In-Reply-To: <1417112870-31894-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/6] libxl: events: Assert that
 libxl_ctx_free is not called from a 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> No-one in their right mind would do this, and if they did everything
> would definitely collapse.  Arrange that if this happens, we crash
> ASAP.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..c111f27 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -148,6 +148,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
>  {
>      if (!ctx) return 0;
>  
> +    assert(!ctx->osevent_in_hook);
> +
>      int i;
>      GC_INIT(ctx);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:42:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKsJ-0005nC-HD; Fri, 28 Nov 2014 12:42:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKsI-0005n7-8u
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 12:42:14 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	79/48-16982-5AD68745; Fri, 28 Nov 2014 12:42:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417178531!14424944!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2935 invoked from network); 28 Nov 2014 12:42:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:42:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197716254"
Message-ID: <1417178529.23604.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 12:42:09 +0000
In-Reply-To: <1417112870-31894-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/6] libxl: events: Assert that
 libxl_ctx_free is not called from a 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> No-one in their right mind would do this, and if they did everything
> would definitely collapse.  Arrange that if this happens, we crash
> ASAP.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..c111f27 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -148,6 +148,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
>  {
>      if (!ctx) return 0;
>  
> +    assert(!ctx->osevent_in_hook);
> +
>      int i;
>      GC_INIT(ctx);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:45:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKux-00061j-2H; Fri, 28 Nov 2014 12:44:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuKuu-00061e-Tj
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 12:44:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5E/88-25276-84E68745; Fri, 28 Nov 2014 12:44:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417178693!4060890!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25999 invoked from network); 28 Nov 2014 12:44:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:44:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197716706"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 07:44:52 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuKuq-0007a1-9D;
	Fri, 28 Nov 2014 12:44:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuKup-0004X0-U0;
	Fri, 28 Nov 2014 12:44:51 +0000
Date: Fri, 28 Nov 2014 12:44:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31885-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31885: 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 31885 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31885/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install              fail pass in 31857
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot        fail in 31857 pass in 31885
 test-amd64-i386-pair          7 xen-boot/src_host  fail in 31857 pass in 31885

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31849

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 seabios              b7f4a76a929ce4acd60e89aa273a8b208daa8233
baseline version:
 seabios              9f505f715793d99235bd6b4afb2ca7b96ba5729b

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=seabios
+ revision=b7f4a76a929ce4acd60e89aa273a8b208daa8233
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push seabios b7f4a76a929ce4acd60e89aa273a8b208daa8233
+ branch=seabios
+ revision=b7f4a76a929ce4acd60e89aa273a8b208daa8233
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.seabios
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.seabios
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree seabios
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/seabios
+ git push osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git b7f4a76a929ce4acd60e89aa273a8b208daa8233:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   9f505f7..b7f4a76  b7f4a76a929ce4acd60e89aa273a8b208daa8233 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:45:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKux-00061j-2H; Fri, 28 Nov 2014 12:44:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuKuu-00061e-Tj
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 12:44:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5E/88-25276-84E68745; Fri, 28 Nov 2014 12:44:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417178693!4060890!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25999 invoked from network); 28 Nov 2014 12:44:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:44:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197716706"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 07:44:52 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuKuq-0007a1-9D;
	Fri, 28 Nov 2014 12:44:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuKup-0004X0-U0;
	Fri, 28 Nov 2014 12:44:51 +0000
Date: Fri, 28 Nov 2014 12:44:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31885-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [seabios test] 31885: 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 31885 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31885/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install              fail pass in 31857
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot        fail in 31857 pass in 31885
 test-amd64-i386-pair          7 xen-boot/src_host  fail in 31857 pass in 31885

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31849

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 seabios              b7f4a76a929ce4acd60e89aa273a8b208daa8233
baseline version:
 seabios              9f505f715793d99235bd6b4afb2ca7b96ba5729b

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=seabios
+ revision=b7f4a76a929ce4acd60e89aa273a8b208daa8233
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push seabios b7f4a76a929ce4acd60e89aa273a8b208daa8233
+ branch=seabios
+ revision=b7f4a76a929ce4acd60e89aa273a8b208daa8233
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : daily-cron.seabios
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.seabios
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.seabios
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree seabios
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/seabios
+ git push osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git b7f4a76a929ce4acd60e89aa273a8b208daa8233:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   9f505f7..b7f4a76  b7f4a76a929ce4acd60e89aa273a8b208daa8233 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:49:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:49:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKyo-0006Eb-84; Fri, 28 Nov 2014 12:48:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKym-0006ER-W7
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 12:48:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	D5/31-07724-83F68745; Fri, 28 Nov 2014 12:48:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417178934!14483284!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30534 invoked from network); 28 Nov 2014 12:48:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:48:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197717744"
Message-ID: <1417178932.23604.38.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 12:48:52 +0000
In-Reply-To: <1417112870-31894-4-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3/6] libxl: events: Deregister,
 don't just modify, sigchld pipe fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> We want to have no fd events registered when we are idle.  This
> implies that we must be able to deregister our interest in the sigchld
> self-pipe fd, not just modify to request no events.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I think in principal there is now some redundant code in
libxl__sigchld_needed which calls modify to set POLLIN if the fd is not
registered. I think it's redundant because now the fd is registered iff
it is looking for POLLIN.

> ---
>  tools/libxl/libxl_fork.c |    9 +--------
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
> index fa15095..144208a 100644
> --- a/tools/libxl/libxl_fork.c
> +++ b/tools/libxl/libxl_fork.c
> @@ -372,15 +372,8 @@ static void sigchld_user_remove(libxl_ctx *ctx) /* idempotent */
>  
>  void libxl__sigchld_notneeded(libxl__gc *gc) /* non-reentrant, idempotent */
>  {
> -    int rc;
> -
>      sigchld_user_remove(CTX);
> -
> -    if (libxl__ev_fd_isregistered(&CTX->sigchld_selfpipe_efd)) {
> -        rc = libxl__ev_fd_modify(gc, &CTX->sigchld_selfpipe_efd, 0);
> -        if (rc)
> -            libxl__ev_fd_deregister(gc, &CTX->sigchld_selfpipe_efd);
> -    }
> +    libxl__ev_fd_deregister(gc, &CTX->sigchld_selfpipe_efd);
>  }
>  
>  int libxl__sigchld_needed(libxl__gc *gc) /* non-reentrant, idempotent */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:49:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:49:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKyj-0006EB-Sf; Fri, 28 Nov 2014 12:48:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XuKyi-0006E6-RX
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:48:52 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	77/47-02696-43F68745; Fri, 28 Nov 2014 12:48:52 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417178931!6331738!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14502 invoked from network); 28 Nov 2014 12:48:51 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:48:51 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so11128507wid.6
	for <xen-devel@lists.xenproject.org>;
	Fri, 28 Nov 2014 04:48:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=DrBIGmcmQnQ3XFuPCo+/1B1FktBM5OjTeU4fEwi9j84=;
	b=XPzgPlmPUQ6Kf4wXz1gAxDkhrKqcoTAF78Kp61Bzk8bxPffU1U7bD9f9B8h0Z2rHVQ
	3geWPlZiQrfvfSSXUwBBZ04WULAhQeogEXLUAgfwCAl7hLh1ZuXJLacGhJftRjRv/+1m
	pynRxzQoC2ZyZTs22I9SogeHzS+J69XDurfQTphh7f6KANkELOvpv8BC4K2WLEF3JktW
	iDdfv15SNXb7998NxLLmnyCiUhj35yIXoipfGrNoEQauaKHybZbMDREelSz9VrZBJ3El
	zSWhGlKLiQgNd/EaeROroMz4hr+UzsQZmH3q6QdK6+T/a15ApdtmXOKzgLjzkUB9VtRF
	3EIg==
X-Gm-Message-State: ALoCoQn8KkB5MTmbdJjs2yuhWd5Z2ufiZ5pGsXlrKGxUSyjzAikiVqDNKtOSx90olHKQK1IyUd6w
X-Received: by 10.194.243.164 with SMTP id wz4mr69960711wjc.129.1417178931068; 
	Fri, 28 Nov 2014 04:48:51 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	js5sm28889563wid.11.2014.11.28.04.48.49 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 28 Nov 2014 04:48:50 -0800 (PST)
Message-ID: <54786F2E.5070501@linaro.org>
Date: Fri, 28 Nov 2014 12:48:46 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>	
	<5477671C.4010500@linaro.org>
	<1417175252.23604.15.camel@citrix.com>
In-Reply-To: <1417175252.23604.15.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 28/11/14 11:47, Ian Campbell wrote:
> On Thu, 2014-11-27 at 18:02 +0000, Julien Grall wrote:
>> state at the GIC level. This would also avoid masking the output signal
>> and requires specific handling in the guest OS.
> 
> "which requires"?
> 
> It doesn't seem quite right to me otherwise, since context switching the
> virq state *removes* the need to have the guest do anything other than
> what it would do on native.

I though the "avoid" would apply for both "masking" and "requires".

> Assuming this is what you meant I propose (fixing some grammar etc as I
> go):


Thanks for the correction, I will use this version. Shall I put your
signed-off-by?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:49:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:49:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKyo-0006Eb-84; Fri, 28 Nov 2014 12:48:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuKym-0006ER-W7
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 12:48:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	D5/31-07724-83F68745; Fri, 28 Nov 2014 12:48:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417178934!14483284!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30534 invoked from network); 28 Nov 2014 12:48:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:48:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197717744"
Message-ID: <1417178932.23604.38.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 12:48:52 +0000
In-Reply-To: <1417112870-31894-4-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3/6] libxl: events: Deregister,
 don't just modify, sigchld pipe fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> We want to have no fd events registered when we are idle.  This
> implies that we must be able to deregister our interest in the sigchld
> self-pipe fd, not just modify to request no events.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I think in principal there is now some redundant code in
libxl__sigchld_needed which calls modify to set POLLIN if the fd is not
registered. I think it's redundant because now the fd is registered iff
it is looking for POLLIN.

> ---
>  tools/libxl/libxl_fork.c |    9 +--------
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
> index fa15095..144208a 100644
> --- a/tools/libxl/libxl_fork.c
> +++ b/tools/libxl/libxl_fork.c
> @@ -372,15 +372,8 @@ static void sigchld_user_remove(libxl_ctx *ctx) /* idempotent */
>  
>  void libxl__sigchld_notneeded(libxl__gc *gc) /* non-reentrant, idempotent */
>  {
> -    int rc;
> -
>      sigchld_user_remove(CTX);
> -
> -    if (libxl__ev_fd_isregistered(&CTX->sigchld_selfpipe_efd)) {
> -        rc = libxl__ev_fd_modify(gc, &CTX->sigchld_selfpipe_efd, 0);
> -        if (rc)
> -            libxl__ev_fd_deregister(gc, &CTX->sigchld_selfpipe_efd);
> -    }
> +    libxl__ev_fd_deregister(gc, &CTX->sigchld_selfpipe_efd);
>  }
>  
>  int libxl__sigchld_needed(libxl__gc *gc) /* non-reentrant, idempotent */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:49:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:49:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKyj-0006EB-Sf; Fri, 28 Nov 2014 12:48:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XuKyi-0006E6-RX
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:48:52 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	77/47-02696-43F68745; Fri, 28 Nov 2014 12:48:52 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417178931!6331738!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14502 invoked from network); 28 Nov 2014 12:48:51 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:48:51 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so11128507wid.6
	for <xen-devel@lists.xenproject.org>;
	Fri, 28 Nov 2014 04:48:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=DrBIGmcmQnQ3XFuPCo+/1B1FktBM5OjTeU4fEwi9j84=;
	b=XPzgPlmPUQ6Kf4wXz1gAxDkhrKqcoTAF78Kp61Bzk8bxPffU1U7bD9f9B8h0Z2rHVQ
	3geWPlZiQrfvfSSXUwBBZ04WULAhQeogEXLUAgfwCAl7hLh1ZuXJLacGhJftRjRv/+1m
	pynRxzQoC2ZyZTs22I9SogeHzS+J69XDurfQTphh7f6KANkELOvpv8BC4K2WLEF3JktW
	iDdfv15SNXb7998NxLLmnyCiUhj35yIXoipfGrNoEQauaKHybZbMDREelSz9VrZBJ3El
	zSWhGlKLiQgNd/EaeROroMz4hr+UzsQZmH3q6QdK6+T/a15ApdtmXOKzgLjzkUB9VtRF
	3EIg==
X-Gm-Message-State: ALoCoQn8KkB5MTmbdJjs2yuhWd5Z2ufiZ5pGsXlrKGxUSyjzAikiVqDNKtOSx90olHKQK1IyUd6w
X-Received: by 10.194.243.164 with SMTP id wz4mr69960711wjc.129.1417178931068; 
	Fri, 28 Nov 2014 04:48:51 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	js5sm28889563wid.11.2014.11.28.04.48.49 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 28 Nov 2014 04:48:50 -0800 (PST)
Message-ID: <54786F2E.5070501@linaro.org>
Date: Fri, 28 Nov 2014 12:48:46 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>	
	<5477671C.4010500@linaro.org>
	<1417175252.23604.15.camel@citrix.com>
In-Reply-To: <1417175252.23604.15.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 28/11/14 11:47, Ian Campbell wrote:
> On Thu, 2014-11-27 at 18:02 +0000, Julien Grall wrote:
>> state at the GIC level. This would also avoid masking the output signal
>> and requires specific handling in the guest OS.
> 
> "which requires"?
> 
> It doesn't seem quite right to me otherwise, since context switching the
> virq state *removes* the need to have the guest do anything other than
> what it would do on native.

I though the "avoid" would apply for both "masking" and "requires".

> Assuming this is what you meant I propose (fixing some grammar etc as I
> go):


Thanks for the correction, I will use this version. Shall I put your
signed-off-by?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:49:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKzM-0006KC-L5; Fri, 28 Nov 2014 12:49:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XuKzL-0006Js-Ad
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:49:31 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	4C/AE-28865-A5F68745; Fri, 28 Nov 2014 12:49:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417178970!13845798!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16104 invoked from network); 28 Nov 2014 12:49:30 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:49:30 -0000
Received: by mail-wi0-f182.google.com with SMTP id h11so11105856wiw.9
	for <xen-devel@lists.xenproject.org>;
	Fri, 28 Nov 2014 04:49:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=7uCqSdwK2HC1nOMEuQuBF3iLX6/jt82C3cmo0W383MM=;
	b=LHfieDJ7QMwpL18TC9eAHevfPwXcA928T5E7xeAPNuMOOW/Mxun4fZAoXhwl0aLWlT
	dStiAexDIR0hV2ZLOViJKt7wJE5+VlZv/7459BQ8sLlfrqTX3vB/H3Iy3V1BJX7fcA+h
	qdFP+wpL+gwQjUUK9N4Q9HWnKTMJ7sYORNbncVQTUTg7rCm0zcRkg0oDEcr54NVbrDlt
	8EZCuUfrUG3wxVXwlTF0obtu8sYKFjmFFRx7XjCXvy6HzGz4u3hTFXO79NjGOE33pI2s
	C0f0kmxSpq8U7J7+StHW19Jj248S4I7akIzsrfn5OUtSZC5YGnmcBOfq0sZbm0HBV+PI
	E02g==
X-Gm-Message-State: ALoCoQmSXhwsyFHs5wIjdxicMjiIZ9Pc+tpfTtvPT/xXeKjh++uCVWxG3VtzDmbUygXO5DejZyGh
X-Received: by 10.180.182.199 with SMTP id eg7mr59780206wic.17.1417178969850; 
	Fri, 28 Nov 2014 04:49:29 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ga1sm15818446wib.1.2014.11.28.04.49.28
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 28 Nov 2014 04:49:29 -0800 (PST)
Message-ID: <54786F55.1040602@linaro.org>
Date: Fri, 28 Nov 2014 12:49:25 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>	
	<5477671C.4010500@linaro.org>
	<1417177975.23604.34.camel@citrix.com>
In-Reply-To: <1417177975.23604.34.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 28/11/14 12:32, Ian Campbell wrote:
> On Thu, 2014-11-27 at 18:02 +0000, Julien Grall wrote:
>> I propose to reword the commit message into:
> 
> You'll want to change the code comment too I think.

It was my plan. I will send a new version during the day.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:49:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuKzM-0006KC-L5; Fri, 28 Nov 2014 12:49:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XuKzL-0006Js-Ad
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 12:49:31 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	4C/AE-28865-A5F68745; Fri, 28 Nov 2014 12:49:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417178970!13845798!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16104 invoked from network); 28 Nov 2014 12:49:30 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:49:30 -0000
Received: by mail-wi0-f182.google.com with SMTP id h11so11105856wiw.9
	for <xen-devel@lists.xenproject.org>;
	Fri, 28 Nov 2014 04:49:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=7uCqSdwK2HC1nOMEuQuBF3iLX6/jt82C3cmo0W383MM=;
	b=LHfieDJ7QMwpL18TC9eAHevfPwXcA928T5E7xeAPNuMOOW/Mxun4fZAoXhwl0aLWlT
	dStiAexDIR0hV2ZLOViJKt7wJE5+VlZv/7459BQ8sLlfrqTX3vB/H3Iy3V1BJX7fcA+h
	qdFP+wpL+gwQjUUK9N4Q9HWnKTMJ7sYORNbncVQTUTg7rCm0zcRkg0oDEcr54NVbrDlt
	8EZCuUfrUG3wxVXwlTF0obtu8sYKFjmFFRx7XjCXvy6HzGz4u3hTFXO79NjGOE33pI2s
	C0f0kmxSpq8U7J7+StHW19Jj248S4I7akIzsrfn5OUtSZC5YGnmcBOfq0sZbm0HBV+PI
	E02g==
X-Gm-Message-State: ALoCoQmSXhwsyFHs5wIjdxicMjiIZ9Pc+tpfTtvPT/xXeKjh++uCVWxG3VtzDmbUygXO5DejZyGh
X-Received: by 10.180.182.199 with SMTP id eg7mr59780206wic.17.1417178969850; 
	Fri, 28 Nov 2014 04:49:29 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ga1sm15818446wib.1.2014.11.28.04.49.28
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 28 Nov 2014 04:49:29 -0800 (PST)
Message-ID: <54786F55.1040602@linaro.org>
Date: Fri, 28 Nov 2014 12:49:25 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>	
	<5477671C.4010500@linaro.org>
	<1417177975.23604.34.camel@citrix.com>
In-Reply-To: <1417177975.23604.34.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

On 28/11/14 12:32, Ian Campbell wrote:
> On Thu, 2014-11-27 at 18:02 +0000, Julien Grall wrote:
>> I propose to reword the commit message into:
> 
> You'll want to change the code comment too I think.

It was my plan. I will send a new version during the day.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:51:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:51:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuL0w-0006WA-52; Fri, 28 Nov 2014 12:51:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XuL0u-0006W1-Ry
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:51:09 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	05/9F-18267-CBF68745; Fri, 28 Nov 2014 12:51:08 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417179066!14483934!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14889 invoked from network); 28 Nov 2014 12:51:07 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 12:51:07 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=tGDxnaSrC4UfhbAZoxlvfX7xtB+Ep4Bdl0JVm7HRmX3fHFnYdbklhuKq03qh5Vp8ycZdZP8qS7nrEFhVtweZ+ylZklioJcOZBPP+E6dFQiIG7MSlWYv1BI2LGruEee7Nu5XjykqYZU6jVCkIpv9DBK9GvUdZl92+AC85fMPgwdNABxYpP1TuwNtC9cqh1T6jIH88RsRAUDOet8scdTiF+w0uKGNeuVMzDNSvTrdeu6Xb62jKDPBseGW0BEx3u4l5Z+Ggp5cCvHICKDOQLTVC6RoyXsPfIdScDTNgqKGVO9nG012sGg0I7WDvs73Tdfy2F5R58iR5jfSlf7EI5iVCSQ==;
	h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=
	message-id:date:from:mime-version:to:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding; s=default;
	bh=BqM/EQ8vHvsM/coT7x3YydkWnoI=; b=duf61tltoRCBNuTipMtZK8PdgD3G
	ZbTTfWDGus6ohLMUhk2EltCjwtGaa1HCbmZDykKbofAZQpfg77pmtF/76/bqiLKm
	/RE+ERzpxTTXW6LjOUe9dw1KzMerH1wI9VBdNImWMru2gEKFrnr1+6m5ZdUZ/sQc
	V+PUHqu+XNCb8vtpIBB8I1QWHhk3bRTzvpt95fgTtyeDp47grJUHTOm6SHIr8kgK
	BK/gVUj1ELVTwLpLARtb3R/8MRbNWhxhdu7SZNsaqinwP9/I2vwG19xoBSjAtGft
	AGaNPVtzUFE0VgFNo8cKwlEwY6umXrVU4Orsc/mSjOuu2HWibqy0RjLDHw==
Received: (qmail 16879 invoked from network); 28 Nov 2014 14:51:06 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	28 Nov 2014 14:51:06 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id CC44C803F4
	for <xen-devel@lists.xen.org>; Fri, 28 Nov 2014 14:51:05 +0200 (EET)
Received: (qmail 13044 invoked from network); 28 Nov 2014 14:51:05 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by smtp03.buh.bitdefender.org with SMTP; 28 Nov 2014 14:51:05 +0200
Message-ID: <54786FC1.6090200@bitdefender.com>
Date: Fri, 28 Nov 2014 14:51:13 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Tamas K Lengyel <tamas.lengyel@zentific.com>, 
 xen-devel@lists.xen.org
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<1415806309-5206-8-git-send-email-tamas.lengyel@zentific.com>
In-Reply-To: <1415806309-5206-8-git-send-email-tamas.lengyel@zentific.com>
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.57992
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 373738,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_LEGIT_VALID_REPLY;
	NN_LEGIT_SUMM_400_WORDS; NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER;
	NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled],
	URL: [Enabled], RTDA: [Enabled, Hit: No, Details: v2.0.9; Id:
	2m1ghdo.197r0c28b.r674], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org,
	jun.nakajima@intel.com, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 7/7] tools/tests: Remove superfluous and
 incomplete spinlock from xen-access
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 05:31 PM, Tamas K Lengyel wrote:
> The spin-lock implementation in the xen-access test program is implemented
> in a fashion that is actually incomplete. The x86 assembly that guarantees that
> the lock is held by only one thread lacks the "lock;" instruction.
> 
> However, the spin-lock is not actually necessary in xen-access as it is not
> multithreaded. The presence of the faulty implementation of the lock in a non-
> mulithreaded environment is unnecessarily complicated for developers who are
> trying to follow this code as a guide in implementing their own applications.
> Thus, removing it from the code improves the clarity on the behavior of the
> system.
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
> ---
>  tools/tests/xen-access/xen-access.c | 68 ++++---------------------------------
>  1 file changed, 6 insertions(+), 62 deletions(-)
> 
> diff --git a/tools/tests/xen-access/xen-access.c b/tools/tests/xen-access/xen-access.c
> index 3538323..428c459 100644
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -45,56 +45,6 @@
>  #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
>  #define PERROR(a, b...) fprintf(stderr, a ": %s\n", ## b, strerror(errno))
>  
> -/* Spinlock and mem event definitions */
> -
> -#define SPIN_LOCK_UNLOCKED 0
> -
> -#define ADDR (*(volatile long *) addr)
> -/**
> - * test_and_set_bit - Set a bit and return its old value
> - * @nr: Bit to set
> - * @addr: Address to count from
> - *
> - * This operation is atomic and cannot be reordered.
> - * It also implies a memory barrier.
> - */
> -static inline int test_and_set_bit(int nr, volatile void *addr)
> -{
> -    int oldbit;
> -
> -    asm volatile (
> -        "btsl %2,%1\n\tsbbl %0,%0"
> -        : "=r" (oldbit), "=m" (ADDR)
> -        : "Ir" (nr), "m" (ADDR) : "memory");
> -    return oldbit;
> -}
> -
> -typedef int spinlock_t;
> -
> -static inline void spin_lock(spinlock_t *lock)
> -{
> -    while ( test_and_set_bit(1, lock) );
> -}
> -
> -static inline void spin_lock_init(spinlock_t *lock)
> -{
> -    *lock = SPIN_LOCK_UNLOCKED;
> -}
> -
> -static inline void spin_unlock(spinlock_t *lock)
> -{
> -    *lock = SPIN_LOCK_UNLOCKED;
> -}
> -
> -static inline int spin_trylock(spinlock_t *lock)
> -{
> -    return !test_and_set_bit(1, lock);
> -}
> -
> -#define vm_event_ring_lock_init(_m)  spin_lock_init(&(_m)->ring_lock)
> -#define vm_event_ring_lock(_m)       spin_lock(&(_m)->ring_lock)
> -#define vm_event_ring_unlock(_m)     spin_unlock(&(_m)->ring_lock)
> -
>  typedef struct vm_event {
>      domid_t domain_id;
>      xc_evtchn *xce_handle;
> @@ -102,7 +52,6 @@ typedef struct vm_event {
>      vm_event_back_ring_t back_ring;
>      uint32_t evtchn_port;
>      void *ring_page;
> -    spinlock_t ring_lock;
>  } vm_event_t;
>  
>  typedef struct xenaccess {
> @@ -241,9 +190,6 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
>      /* Set domain id */
>      xenaccess->vm_event.domain_id = domain_id;
>  
> -    /* Initialise lock */
> -    vm_event_ring_lock_init(&xenaccess->vm_event);
> -
>      /* Enable mem_access */
>      xenaccess->vm_event.ring_page =
>              xc_mem_access_enable(xenaccess->xc_handle,
> @@ -320,13 +266,14 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
>      return NULL;
>  }
>  
> +/*
> + * Note that this function is not thread safe.
> + */
>  int get_request(vm_event_t *vm_event, vm_event_request_t *req)
>  {
>      vm_event_back_ring_t *back_ring;
>      RING_IDX req_cons;
>  
> -    vm_event_ring_lock(vm_event);
> -
>      back_ring = &vm_event->back_ring;
>      req_cons = back_ring->req_cons;
>  
> @@ -338,18 +285,17 @@ int get_request(vm_event_t *vm_event, vm_event_request_t *req)
>      back_ring->req_cons = req_cons;
>      back_ring->sring->req_event = req_cons + 1;
>  
> -    vm_event_ring_unlock(vm_event);
> -
>      return 0;
>  }
>  
> +/*
> + * Note that this function is not thread safe.
> + */
>  static int put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
>  {
>      vm_event_back_ring_t *back_ring;
>      RING_IDX rsp_prod;
>  
> -    vm_event_ring_lock(vm_event);
> -
>      back_ring = &vm_event->back_ring;
>      rsp_prod = back_ring->rsp_prod_pvt;
>  
> @@ -361,8 +307,6 @@ static int put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
>      back_ring->rsp_prod_pvt = rsp_prod;
>      RING_PUSH_RESPONSES(back_ring);
>  
> -    vm_event_ring_unlock(vm_event);
> -
>      return 0;
>  }

I've just now noticed that get_request() and put_response() only ever
return 0, so it makes no sense to check the return values later on, and
they should basically either be modified to be void functions or some
error checking should be added (not sure what that could be).


Regards,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:51:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:51:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuL0w-0006WA-52; Fri, 28 Nov 2014 12:51:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rcojocaru@bitdefender.com>) id 1XuL0u-0006W1-Ry
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 12:51:09 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	05/9F-18267-CBF68745; Fri, 28 Nov 2014 12:51:08 +0000
X-Env-Sender: rcojocaru@bitdefender.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417179066!14483934!1
X-Originating-IP: [91.199.104.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14889 invoked from network); 28 Nov 2014 12:51:07 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 12:51:07 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=tGDxnaSrC4UfhbAZoxlvfX7xtB+Ep4Bdl0JVm7HRmX3fHFnYdbklhuKq03qh5Vp8ycZdZP8qS7nrEFhVtweZ+ylZklioJcOZBPP+E6dFQiIG7MSlWYv1BI2LGruEee7Nu5XjykqYZU6jVCkIpv9DBK9GvUdZl92+AC85fMPgwdNABxYpP1TuwNtC9cqh1T6jIH88RsRAUDOet8scdTiF+w0uKGNeuVMzDNSvTrdeu6Xb62jKDPBseGW0BEx3u4l5Z+Ggp5cCvHICKDOQLTVC6RoyXsPfIdScDTNgqKGVO9nG012sGg0I7WDvs73Tdfy2F5R58iR5jfSlf7EI5iVCSQ==;
	h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bitdefender.com; h=
	message-id:date:from:mime-version:to:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding; s=default;
	bh=BqM/EQ8vHvsM/coT7x3YydkWnoI=; b=duf61tltoRCBNuTipMtZK8PdgD3G
	ZbTTfWDGus6ohLMUhk2EltCjwtGaa1HCbmZDykKbofAZQpfg77pmtF/76/bqiLKm
	/RE+ERzpxTTXW6LjOUe9dw1KzMerH1wI9VBdNImWMru2gEKFrnr1+6m5ZdUZ/sQc
	V+PUHqu+XNCb8vtpIBB8I1QWHhk3bRTzvpt95fgTtyeDp47grJUHTOm6SHIr8kgK
	BK/gVUj1ELVTwLpLARtb3R/8MRbNWhxhdu7SZNsaqinwP9/I2vwG19xoBSjAtGft
	AGaNPVtzUFE0VgFNo8cKwlEwY6umXrVU4Orsc/mSjOuu2HWibqy0RjLDHw==
Received: (qmail 16879 invoked from network); 28 Nov 2014 14:51:06 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	28 Nov 2014 14:51:06 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id CC44C803F4
	for <xen-devel@lists.xen.org>; Fri, 28 Nov 2014 14:51:05 +0200 (EET)
Received: (qmail 13044 invoked from network); 28 Nov 2014 14:51:05 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by smtp03.buh.bitdefender.org with SMTP; 28 Nov 2014 14:51:05 +0200
Message-ID: <54786FC1.6090200@bitdefender.com>
Date: Fri, 28 Nov 2014 14:51:13 +0200
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Tamas K Lengyel <tamas.lengyel@zentific.com>, 
 xen-devel@lists.xen.org
References: <1415806309-5206-1-git-send-email-tamas.lengyel@zentific.com>
	<1415806309-5206-8-git-send-email-tamas.lengyel@zentific.com>
In-Reply-To: <1415806309-5206-8-git-send-email-tamas.lengyel@zentific.com>
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.57992
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 373738,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_LEGIT_VALID_REPLY;
	NN_LEGIT_SUMM_400_WORDS; NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER;
	NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled],
	URL: [Enabled], RTDA: [Enabled, Hit: No, Details: v2.0.9; Id:
	2m1ghdo.197r0c28b.r674], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, andres@lagarcavilla.org,
	jun.nakajima@intel.com, rshriram@cs.ubc.ca,
	dgdegra@tycho.nsa.gov, yanghy@cn.fujitsu.com
Subject: Re: [Xen-devel] [PATCH RFC 7/7] tools/tests: Remove superfluous and
 incomplete spinlock from xen-access
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/2014 05:31 PM, Tamas K Lengyel wrote:
> The spin-lock implementation in the xen-access test program is implemented
> in a fashion that is actually incomplete. The x86 assembly that guarantees that
> the lock is held by only one thread lacks the "lock;" instruction.
> 
> However, the spin-lock is not actually necessary in xen-access as it is not
> multithreaded. The presence of the faulty implementation of the lock in a non-
> mulithreaded environment is unnecessarily complicated for developers who are
> trying to follow this code as a guide in implementing their own applications.
> Thus, removing it from the code improves the clarity on the behavior of the
> system.
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
> ---
>  tools/tests/xen-access/xen-access.c | 68 ++++---------------------------------
>  1 file changed, 6 insertions(+), 62 deletions(-)
> 
> diff --git a/tools/tests/xen-access/xen-access.c b/tools/tests/xen-access/xen-access.c
> index 3538323..428c459 100644
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -45,56 +45,6 @@
>  #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
>  #define PERROR(a, b...) fprintf(stderr, a ": %s\n", ## b, strerror(errno))
>  
> -/* Spinlock and mem event definitions */
> -
> -#define SPIN_LOCK_UNLOCKED 0
> -
> -#define ADDR (*(volatile long *) addr)
> -/**
> - * test_and_set_bit - Set a bit and return its old value
> - * @nr: Bit to set
> - * @addr: Address to count from
> - *
> - * This operation is atomic and cannot be reordered.
> - * It also implies a memory barrier.
> - */
> -static inline int test_and_set_bit(int nr, volatile void *addr)
> -{
> -    int oldbit;
> -
> -    asm volatile (
> -        "btsl %2,%1\n\tsbbl %0,%0"
> -        : "=r" (oldbit), "=m" (ADDR)
> -        : "Ir" (nr), "m" (ADDR) : "memory");
> -    return oldbit;
> -}
> -
> -typedef int spinlock_t;
> -
> -static inline void spin_lock(spinlock_t *lock)
> -{
> -    while ( test_and_set_bit(1, lock) );
> -}
> -
> -static inline void spin_lock_init(spinlock_t *lock)
> -{
> -    *lock = SPIN_LOCK_UNLOCKED;
> -}
> -
> -static inline void spin_unlock(spinlock_t *lock)
> -{
> -    *lock = SPIN_LOCK_UNLOCKED;
> -}
> -
> -static inline int spin_trylock(spinlock_t *lock)
> -{
> -    return !test_and_set_bit(1, lock);
> -}
> -
> -#define vm_event_ring_lock_init(_m)  spin_lock_init(&(_m)->ring_lock)
> -#define vm_event_ring_lock(_m)       spin_lock(&(_m)->ring_lock)
> -#define vm_event_ring_unlock(_m)     spin_unlock(&(_m)->ring_lock)
> -
>  typedef struct vm_event {
>      domid_t domain_id;
>      xc_evtchn *xce_handle;
> @@ -102,7 +52,6 @@ typedef struct vm_event {
>      vm_event_back_ring_t back_ring;
>      uint32_t evtchn_port;
>      void *ring_page;
> -    spinlock_t ring_lock;
>  } vm_event_t;
>  
>  typedef struct xenaccess {
> @@ -241,9 +190,6 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
>      /* Set domain id */
>      xenaccess->vm_event.domain_id = domain_id;
>  
> -    /* Initialise lock */
> -    vm_event_ring_lock_init(&xenaccess->vm_event);
> -
>      /* Enable mem_access */
>      xenaccess->vm_event.ring_page =
>              xc_mem_access_enable(xenaccess->xc_handle,
> @@ -320,13 +266,14 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
>      return NULL;
>  }
>  
> +/*
> + * Note that this function is not thread safe.
> + */
>  int get_request(vm_event_t *vm_event, vm_event_request_t *req)
>  {
>      vm_event_back_ring_t *back_ring;
>      RING_IDX req_cons;
>  
> -    vm_event_ring_lock(vm_event);
> -
>      back_ring = &vm_event->back_ring;
>      req_cons = back_ring->req_cons;
>  
> @@ -338,18 +285,17 @@ int get_request(vm_event_t *vm_event, vm_event_request_t *req)
>      back_ring->req_cons = req_cons;
>      back_ring->sring->req_event = req_cons + 1;
>  
> -    vm_event_ring_unlock(vm_event);
> -
>      return 0;
>  }
>  
> +/*
> + * Note that this function is not thread safe.
> + */
>  static int put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
>  {
>      vm_event_back_ring_t *back_ring;
>      RING_IDX rsp_prod;
>  
> -    vm_event_ring_lock(vm_event);
> -
>      back_ring = &vm_event->back_ring;
>      rsp_prod = back_ring->rsp_prod_pvt;
>  
> @@ -361,8 +307,6 @@ static int put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
>      back_ring->rsp_prod_pvt = rsp_prod;
>      RING_PUSH_RESPONSES(back_ring);
>  
> -    vm_event_ring_unlock(vm_event);
> -
>      return 0;
>  }

I've just now noticed that get_request() and put_response() only ever
return 0, so it makes no sense to check the return values later on, and
they should basically either be modified to be void functions or some
error checking should be added (not sure what that could be).


Regards,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:51:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuL16-0006Y0-I1; Fri, 28 Nov 2014 12:51:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuL15-0006Xb-Fi
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 12:51:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	09/FE-15461-6CF68745; Fri, 28 Nov 2014 12:51:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417179076!12092432!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17480 invoked from network); 28 Nov 2014 12:51:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:51:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197440768"
Message-ID: <1417179074.23604.39.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 12:51:14 +0000
In-Reply-To: <1417112870-31894-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4/6] libxl: events: Tear down SIGCHLD
 machinery on ctx 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, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> We want to have no fd events registered when we are idle.
> Also, we should put back the default SIGCHLD handler.  So:
> 
>  * In libxl_ctx_free, use libxl_childproc_setmode to set the mode to
>    the default, which is libxl_sigchld_owner_libxl (ie `libxl owns
>    SIGCHLD only when it has active children').
> 
>    But of course there are no active children at libxl teardown so
>    this results in libxl__sigchld_notneeded: the ctx loses its
>    interest in SIGCHLD (unsetting the SIGCHLD handler if we were the
>    last ctx) and deregisters the per-ctx selfpipe fd.
> 
>  * assert that this is the case: ie that we are no longer interested
>    in the selfpipe.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 12a1013..785253d 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -162,11 +162,12 @@ int libxl_ctx_free(libxl_ctx *ctx)
>      while ((eject = LIBXL_LIST_FIRST(&CTX->disk_eject_evgens)))
>          libxl__evdisable_disk_eject(gc, eject);
>  
> +    libxl_childproc_setmode(CTX,0,0);
>      for (i = 0; i < ctx->watch_nslots; i++)
>          assert(!libxl__watch_slot_contents(gc, i));
>      assert(!libxl__ev_fd_isregistered(&ctx->watch_efd));
>      libxl__ev_fd_deregister(gc, &ctx->evtchn_efd);
> -    libxl__ev_fd_deregister(gc, &ctx->sigchld_selfpipe_efd);
> +    assert(!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd));
>  
>      /* Now there should be no more events requested from the application: */
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 12:51:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 12:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuL16-0006Y0-I1; Fri, 28 Nov 2014 12:51:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuL15-0006Xb-Fi
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 12:51:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	09/FE-15461-6CF68745; Fri, 28 Nov 2014 12:51:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417179076!12092432!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17480 invoked from network); 28 Nov 2014 12:51:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 12:51:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197440768"
Message-ID: <1417179074.23604.39.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 12:51:14 +0000
In-Reply-To: <1417112870-31894-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4/6] libxl: events: Tear down SIGCHLD
 machinery on ctx 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, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> We want to have no fd events registered when we are idle.
> Also, we should put back the default SIGCHLD handler.  So:
> 
>  * In libxl_ctx_free, use libxl_childproc_setmode to set the mode to
>    the default, which is libxl_sigchld_owner_libxl (ie `libxl owns
>    SIGCHLD only when it has active children').
> 
>    But of course there are no active children at libxl teardown so
>    this results in libxl__sigchld_notneeded: the ctx loses its
>    interest in SIGCHLD (unsetting the SIGCHLD handler if we were the
>    last ctx) and deregisters the per-ctx selfpipe fd.
> 
>  * assert that this is the case: ie that we are no longer interested
>    in the selfpipe.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 12a1013..785253d 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -162,11 +162,12 @@ int libxl_ctx_free(libxl_ctx *ctx)
>      while ((eject = LIBXL_LIST_FIRST(&CTX->disk_eject_evgens)))
>          libxl__evdisable_disk_eject(gc, eject);
>  
> +    libxl_childproc_setmode(CTX,0,0);
>      for (i = 0; i < ctx->watch_nslots; i++)
>          assert(!libxl__watch_slot_contents(gc, i));
>      assert(!libxl__ev_fd_isregistered(&ctx->watch_efd));
>      libxl__ev_fd_deregister(gc, &ctx->evtchn_efd);
> -    libxl__ev_fd_deregister(gc, &ctx->sigchld_selfpipe_efd);
> +    assert(!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd));
>  
>      /* Now there should be no more events requested from the application: */
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:04:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:04:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLDh-0007GU-T2; Fri, 28 Nov 2014 13:04:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLDg-0007GP-Ls
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 13:04:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	20/68-09842-4D278745; Fri, 28 Nov 2014 13:04:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417179858!12107917!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3966 invoked from network); 28 Nov 2014 13:04:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:04:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197444502"
Message-ID: <1417179851.23604.41.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 13:04:11 +0000
In-Reply-To: <1417112870-31894-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: events: Deregister evtchn fd
	when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> We want to have no fd events registered when we are idle.
> In this patch, deal with the evtchn fd:
> 
>  * Defer setup of the evtchn handle to the first use.
>  * Defer registration of the evtchn fd; register as needed on use.
>  * When cancelling an evtchn wait, or when wait setup fails, check
>    whether there are now no evtchn waits and if so deregister the fd.
>  * On libxl teardown, the evtchn fd should therefore be unregistered.
>    assert that this is the case.

Is there no locking required when registering/deregistering? Since there
are list manipulations in most of these places I presume it already
exists, but I thought I should check.

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c          |    4 +---
>  tools/libxl/libxl_event.c    |   27 +++++++++++++++++++--------
>  tools/libxl/libxl_internal.h |    1 +
>  3 files changed, 21 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 785253d..e0db4eb 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -118,8 +118,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>          rc = ERROR_FAIL; goto out;
>      }
>  
> -    rc = libxl__ctx_evtchn_init(gc);
> -
>      *pctx = ctx;
>      return 0;
>  
> @@ -166,7 +164,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
>      for (i = 0; i < ctx->watch_nslots; i++)
>          assert(!libxl__watch_slot_contents(gc, i));
>      assert(!libxl__ev_fd_isregistered(&ctx->watch_efd));
> -    libxl__ev_fd_deregister(gc, &ctx->evtchn_efd);
> +    assert(!libxl__ev_fd_isregistered(&ctx->evtchn_efd));
>      assert(!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd));
>  
>      /* Now there should be no more events requested from the application: */
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index da0a20e..716f318 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -721,7 +721,7 @@ static void evtchn_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
>  
>  int libxl__ctx_evtchn_init(libxl__gc *gc) {
>      xc_evtchn *xce;
> -    int rc, fd;
> +    int rc;
>  
>      if (CTX->xce)
>          return 0;
> @@ -733,14 +733,10 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
>          goto out;
>      }
>  
> -    fd = xc_evtchn_fd(xce);
> -    assert(fd >= 0);
> +    CTX->evtchn_fd = xc_evtchn_fd(xce);
> +    assert(CTX->evtchn_fd >= 0);

Given that you can always retrieve this no demand with xc_evtchn_fd(xce)
and that it is cheap do you need to stash it in the ctx?

> -    rc = libxl_fd_set_nonblock(CTX, fd, 1);
> -    if (rc) goto out;
> -
> -    rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd,
> -                               evtchn_fd_callback, fd, POLLIN);
> +    rc = libxl_fd_set_nonblock(CTX, CTX->evtchn_fd, 1);
>      if (rc) goto out;
>  
>      CTX->xce = xce;
> @@ -751,6 +747,12 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
>      return rc;
>  }
>  
> +static void evtchn_check_fd_deregister(libxl__gc *gc)
> +{
> +    if (CTX->xce && LIBXL_LIST_EMPTY(&CTX->evtchns_waiting))
> +        libxl__ev_fd_deregister(gc, &CTX->evtchn_efd);
> +}
> +
>  int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
>  {
>      int r, rc;
> @@ -758,6 +760,13 @@ int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
>      DBG("ev_evtchn=%p port=%d wait (was waiting=%d)",
>          evev, evev->port, evev->waiting);
>  
> +    rc = libxl__ctx_evtchn_init(gc);
> +    if (rc) goto out;
> +
> +    rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd,
> +                               evtchn_fd_callback, CTX->evtchn_fd, POLLIN);
> +    if (rc) goto out;

Do you not need to do this only if evtchns_waiting is currently empty or
the efd is idle?

> +
>      if (evev->waiting)
>          return 0;

If you hit this you leave the stuff above done. Which may or may not 
matter depending on the answer above.


Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:04:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:04:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLDh-0007GU-T2; Fri, 28 Nov 2014 13:04:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLDg-0007GP-Ls
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 13:04:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	20/68-09842-4D278745; Fri, 28 Nov 2014 13:04:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417179858!12107917!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3966 invoked from network); 28 Nov 2014 13:04:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:04:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197444502"
Message-ID: <1417179851.23604.41.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 13:04:11 +0000
In-Reply-To: <1417112870-31894-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: events: Deregister evtchn fd
	when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> We want to have no fd events registered when we are idle.
> In this patch, deal with the evtchn fd:
> 
>  * Defer setup of the evtchn handle to the first use.
>  * Defer registration of the evtchn fd; register as needed on use.
>  * When cancelling an evtchn wait, or when wait setup fails, check
>    whether there are now no evtchn waits and if so deregister the fd.
>  * On libxl teardown, the evtchn fd should therefore be unregistered.
>    assert that this is the case.

Is there no locking required when registering/deregistering? Since there
are list manipulations in most of these places I presume it already
exists, but I thought I should check.

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c          |    4 +---
>  tools/libxl/libxl_event.c    |   27 +++++++++++++++++++--------
>  tools/libxl/libxl_internal.h |    1 +
>  3 files changed, 21 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 785253d..e0db4eb 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -118,8 +118,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>          rc = ERROR_FAIL; goto out;
>      }
>  
> -    rc = libxl__ctx_evtchn_init(gc);
> -
>      *pctx = ctx;
>      return 0;
>  
> @@ -166,7 +164,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
>      for (i = 0; i < ctx->watch_nslots; i++)
>          assert(!libxl__watch_slot_contents(gc, i));
>      assert(!libxl__ev_fd_isregistered(&ctx->watch_efd));
> -    libxl__ev_fd_deregister(gc, &ctx->evtchn_efd);
> +    assert(!libxl__ev_fd_isregistered(&ctx->evtchn_efd));
>      assert(!libxl__ev_fd_isregistered(&ctx->sigchld_selfpipe_efd));
>  
>      /* Now there should be no more events requested from the application: */
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index da0a20e..716f318 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -721,7 +721,7 @@ static void evtchn_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
>  
>  int libxl__ctx_evtchn_init(libxl__gc *gc) {
>      xc_evtchn *xce;
> -    int rc, fd;
> +    int rc;
>  
>      if (CTX->xce)
>          return 0;
> @@ -733,14 +733,10 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
>          goto out;
>      }
>  
> -    fd = xc_evtchn_fd(xce);
> -    assert(fd >= 0);
> +    CTX->evtchn_fd = xc_evtchn_fd(xce);
> +    assert(CTX->evtchn_fd >= 0);

Given that you can always retrieve this no demand with xc_evtchn_fd(xce)
and that it is cheap do you need to stash it in the ctx?

> -    rc = libxl_fd_set_nonblock(CTX, fd, 1);
> -    if (rc) goto out;
> -
> -    rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd,
> -                               evtchn_fd_callback, fd, POLLIN);
> +    rc = libxl_fd_set_nonblock(CTX, CTX->evtchn_fd, 1);
>      if (rc) goto out;
>  
>      CTX->xce = xce;
> @@ -751,6 +747,12 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
>      return rc;
>  }
>  
> +static void evtchn_check_fd_deregister(libxl__gc *gc)
> +{
> +    if (CTX->xce && LIBXL_LIST_EMPTY(&CTX->evtchns_waiting))
> +        libxl__ev_fd_deregister(gc, &CTX->evtchn_efd);
> +}
> +
>  int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
>  {
>      int r, rc;
> @@ -758,6 +760,13 @@ int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
>      DBG("ev_evtchn=%p port=%d wait (was waiting=%d)",
>          evev, evev->port, evev->waiting);
>  
> +    rc = libxl__ctx_evtchn_init(gc);
> +    if (rc) goto out;
> +
> +    rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd,
> +                               evtchn_fd_callback, CTX->evtchn_fd, POLLIN);
> +    if (rc) goto out;

Do you not need to do this only if evtchns_waiting is currently empty or
the efd is idle?

> +
>      if (evev->waiting)
>          return 0;

If you hit this you leave the stuff above done. Which may or may not 
matter depending on the answer above.


Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:05:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:05:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLEM-0007JZ-Ey; Fri, 28 Nov 2014 13:05:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLEK-0007JL-9K
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 13:05:00 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	75/BC-02696-BF278745; Fri, 28 Nov 2014 13:04:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417179897!6336250!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17961 invoked from network); 28 Nov 2014 13:04:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:04:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197722480"
Message-ID: <1417179896.23604.42.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 13:04:56 +0000
In-Reply-To: <1417112870-31894-7-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-7-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 6/6] libxl: events: Document and enforce
 actual callbacks restriction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> libxl_event_register_callbacks cannot reasonably be called while libxl
> is busy (has outstanding operations and/or enabled events).
> 
> This is because the previous spec implied (although not entirely
> clearly) that event hooks would not be called for existing fd and
> timeout interests.  There is thus no way to reliably ensure that libxl
> would get told about fds and timeouts which it became interested in
> beforehand.
> 
> So there have to be no such fds or timeouts, which means that the
> callbacks must only be registered or changed when the ctx is idle.
> 
> Document this restriction, and enforce it with a pair of asserts.
> 
> (It would be nicer, perhaps, to say that the application may not call
> libxl_osevent_register_hooks other than right after creating the ctx.
> But there are existing callers, including libvirt, who do it later -
> even after doing major operations such as domain creation.)
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:05:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:05:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLEM-0007JZ-Ey; Fri, 28 Nov 2014 13:05:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLEK-0007JL-9K
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 13:05:00 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	75/BC-02696-BF278745; Fri, 28 Nov 2014 13:04:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417179897!6336250!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17961 invoked from network); 28 Nov 2014 13:04:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:04:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197722480"
Message-ID: <1417179896.23604.42.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 13:04:56 +0000
In-Reply-To: <1417112870-31894-7-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-7-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 6/6] libxl: events: Document and enforce
 actual callbacks restriction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> libxl_event_register_callbacks cannot reasonably be called while libxl
> is busy (has outstanding operations and/or enabled events).
> 
> This is because the previous spec implied (although not entirely
> clearly) that event hooks would not be called for existing fd and
> timeout interests.  There is thus no way to reliably ensure that libxl
> would get told about fds and timeouts which it became interested in
> beforehand.
> 
> So there have to be no such fds or timeouts, which means that the
> callbacks must only be registered or changed when the ctx is idle.
> 
> Document this restriction, and enforce it with a pair of asserts.
> 
> (It would be nicer, perhaps, to say that the application may not call
> libxl_osevent_register_hooks other than right after creating the ctx.
> But there are existing callers, including libvirt, who do it later -
> even after doing major operations such as domain creation.)
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:05:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13: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 1XuLF2-0007Ou-SF; Fri, 28 Nov 2014 13:05:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLF1-0007Oa-DC
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 13:05:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FA/8A-09842-62378745; Fri, 28 Nov 2014 13:05:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417179941!12079913!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32464 invoked from network); 28 Nov 2014 13:05:42 -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;
	28 Nov 2014 13:05:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197722687"
Message-ID: <1417179939.23604.43.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 13:05:39 +0000
In-Reply-To: <21623.28078.547671.792678@mariner.uk.xensource.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<21623.28078.547671.792678@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH for-4.5 0/6] libxl: events: Tear down fd
 interests when idle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:30 +0000, Ian Jackson wrote:
> Konrad: here is a set of fixes for libxl which ought IMO to be in 4.5.
> See below, or the rest of the thread, for details.  It's broken up
> into 6 tiny patches for ease of review.

I tested an identical version of this series, just without the commit
logs, with libvirt on ARM. So in addition to my various acks:
 
Tested-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:05:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13: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 1XuLF2-0007Ou-SF; Fri, 28 Nov 2014 13:05:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLF1-0007Oa-DC
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 13:05:43 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FA/8A-09842-62378745; Fri, 28 Nov 2014 13:05:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417179941!12079913!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32464 invoked from network); 28 Nov 2014 13:05:42 -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;
	28 Nov 2014 13:05:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197722687"
Message-ID: <1417179939.23604.43.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 13:05:39 +0000
In-Reply-To: <21623.28078.547671.792678@mariner.uk.xensource.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<21623.28078.547671.792678@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH for-4.5 0/6] libxl: events: Tear down fd
 interests when idle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:30 +0000, Ian Jackson wrote:
> Konrad: here is a set of fixes for libxl which ought IMO to be in 4.5.
> See below, or the rest of the thread, for details.  It's broken up
> into 6 tiny patches for ease of review.

I tested an identical version of this series, just without the commit
logs, with libvirt on ARM. So in addition to my various acks:
 
Tested-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:06:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:06:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLGE-0007Xf-AD; Fri, 28 Nov 2014 13:06:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLGD-0007XS-Gg
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 13:06:57 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	CD/A2-29352-07378745; Fri, 28 Nov 2014 13:06:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417180014!13869304!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2609 invoked from network); 28 Nov 2014 13:06:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:06:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197445266"
Message-ID: <1417180012.23604.44.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 13:06:52 +0000
In-Reply-To: <1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: events: Deregister xenstore
 watch fd when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> * On libxl teardown, the watch fd should therefore be unregistered.
>   assert that this is the case.

A bunch of the patches in this series basically assume that the ctx is
idle when it is freed, i.e. it requires everything to be explicitly
cancelled rather than implicitly doing so on free.

I think this is a fine restriction, but it probably ought to be written
down.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:06:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:06:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLGE-0007Xf-AD; Fri, 28 Nov 2014 13:06:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLGD-0007XS-Gg
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 13:06:57 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	CD/A2-29352-07378745; Fri, 28 Nov 2014 13:06:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417180014!13869304!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2609 invoked from network); 28 Nov 2014 13:06:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:06:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197445266"
Message-ID: <1417180012.23604.44.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 13:06:52 +0000
In-Reply-To: <1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: events: Deregister xenstore
 watch fd when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> * On libxl teardown, the watch fd should therefore be unregistered.
>   assert that this is the case.

A bunch of the patches in this series basically assume that the ctx is
idle when it is freed, i.e. it requires everything to be explicitly
cancelled rather than implicitly doing so on free.

I think this is a fine restriction, but it probably ought to be written
down.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:07:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLGl-0007cV-Ne; Fri, 28 Nov 2014 13:07:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuLGk-0007cB-6n
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 13:07:30 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	DB/A6-02698-19378745; Fri, 28 Nov 2014 13:07:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417180048!8417908!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25353 invoked from network); 28 Nov 2014 13:07:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 13:07:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 13:07:28 +0000
Message-Id: <5478819F020000780004B70D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 13:07:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <54785E46.4080107@citrix.com>
In-Reply-To: <54785E46.4080107@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.11.14 at 12:36, <andrew.cooper3@citrix.com> wrote:
> However, it occurs to me that HVMOP_op_mask absolutely must live in the
> public header files, as it is guest visible, and forms part of the ABI.
> 
> Consider a userspace task which falls into a continuation, is preempted
> and paused by the guest kernel, the entire VM migrated, and the task
> unpaused later.  If HVMOP_op_mask has changed in that time, the
> continuation will become erroneous.
> 
> In particular, all hypercall continuation strategies we use *must* be
> forward compatible when moving to newer versions of Xen, because Xen
> cannot possibly guarantee that a continuation which starts will finish
> on the same hypervisor.

Hmm, I see the issue, but surfacing such implementation details
would not only be unfortunate, but eventually prevent us from
making future changes. Just recall the mem-op case where we had
to widen the continuation encoding mask at some point. Hence while
I can't immediately see a way to avoid the situation you describe
(and it doesn't even take a user space task in a preemptible kernel),
I think we should allow ourselves a little more time to find possible
solutions other than locking down these masks (really they don't
need to be exposed in the public headers, but we would need
them to not change if no other solution can be found).

One thing to note is that the _introduction_ of such a mask (as
has happened for hvm-op between 4.4 and 4.5) is not a problem
as long as the respective bits all being zero has no special
meaning. What I considered for mem-op a while ago though (and
then forgot again) was to refuse non-zero start_extent values
for any operations not making use of that mechanism. The same
would of course be applicable to gnttab-op and hvm-op.

What might additionally make this not that urgent an issue for 4.5
is that only XSM_DM_PRIV guarded operations are affected, and
I suppose a stubdom gets re-created on the target host (rather
than migrated) when its client migrates.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:07:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLGl-0007cV-Ne; Fri, 28 Nov 2014 13:07:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuLGk-0007cB-6n
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 13:07:30 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	DB/A6-02698-19378745; Fri, 28 Nov 2014 13:07:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417180048!8417908!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25353 invoked from network); 28 Nov 2014 13:07:28 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 13:07:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 13:07:28 +0000
Message-Id: <5478819F020000780004B70D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 13:07:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <54785E46.4080107@citrix.com>
In-Reply-To: <54785E46.4080107@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.11.14 at 12:36, <andrew.cooper3@citrix.com> wrote:
> However, it occurs to me that HVMOP_op_mask absolutely must live in the
> public header files, as it is guest visible, and forms part of the ABI.
> 
> Consider a userspace task which falls into a continuation, is preempted
> and paused by the guest kernel, the entire VM migrated, and the task
> unpaused later.  If HVMOP_op_mask has changed in that time, the
> continuation will become erroneous.
> 
> In particular, all hypercall continuation strategies we use *must* be
> forward compatible when moving to newer versions of Xen, because Xen
> cannot possibly guarantee that a continuation which starts will finish
> on the same hypervisor.

Hmm, I see the issue, but surfacing such implementation details
would not only be unfortunate, but eventually prevent us from
making future changes. Just recall the mem-op case where we had
to widen the continuation encoding mask at some point. Hence while
I can't immediately see a way to avoid the situation you describe
(and it doesn't even take a user space task in a preemptible kernel),
I think we should allow ourselves a little more time to find possible
solutions other than locking down these masks (really they don't
need to be exposed in the public headers, but we would need
them to not change if no other solution can be found).

One thing to note is that the _introduction_ of such a mask (as
has happened for hvm-op between 4.4 and 4.5) is not a problem
as long as the respective bits all being zero has no special
meaning. What I considered for mem-op a while ago though (and
then forgot again) was to refuse non-zero start_extent values
for any operations not making use of that mechanism. The same
would of course be applicable to gnttab-op and hvm-op.

What might additionally make this not that urgent an issue for 4.5
is that only XSM_DM_PRIV guarded operations are affected, and
I suppose a stubdom gets re-created on the target host (rather
than migrated) when its client migrates.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:10:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:10:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLJO-0007t0-9B; Fri, 28 Nov 2014 13:10:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLJN-0007so-1N
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 13:10:13 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	67/32-09842-43478745; Fri, 28 Nov 2014 13:10:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417180209!12129374!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24493 invoked from network); 28 Nov 2014 13:10:10 -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;
	28 Nov 2014 13:10:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197446107"
Message-ID: <1417180207.23604.46.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 28 Nov 2014 13:10:07 +0000
In-Reply-To: <54786F2E.5070501@linaro.org>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<5477671C.4010500@linaro.org> <1417175252.23604.15.camel@citrix.com>
	<54786F2E.5070501@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 12:48 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 28/11/14 11:47, Ian Campbell wrote:
> > On Thu, 2014-11-27 at 18:02 +0000, Julien Grall wrote:
> >> state at the GIC level. This would also avoid masking the output signal
> >> and requires specific handling in the guest OS.
> > 
> > "which requires"?
> > 
> > It doesn't seem quite right to me otherwise, since context switching the
> > virq state *removes* the need to have the guest do anything other than
> > what it would do on native.
> 
> I though the "avoid" would apply for both "masking" and "requires".

I think it reads with the avoid binding tightly to the masking only.

Possibly s/requires/requiring/ would have also corrected the meaning to
what you intended, although I would have changed the "and" to "or" as
well to make it less ambiguous.

> > Assuming this is what you meant I propose (fixing some grammar etc as I
> > go):
> 
> 
> Thanks for the correction, I will use this version. Shall I put your
> signed-off-by?

I don't think that's needed, its was pretty small.

(i.e. I wouldn't have added my S-o-b if I did it on commit).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:10:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:10:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLJO-0007t0-9B; Fri, 28 Nov 2014 13:10:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLJN-0007so-1N
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 13:10:13 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	67/32-09842-43478745; Fri, 28 Nov 2014 13:10:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417180209!12129374!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24493 invoked from network); 28 Nov 2014 13:10:10 -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;
	28 Nov 2014 13:10:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197446107"
Message-ID: <1417180207.23604.46.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 28 Nov 2014 13:10:07 +0000
In-Reply-To: <54786F2E.5070501@linaro.org>
References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org>
	<5477671C.4010500@linaro.org> <1417175252.23604.15.camel@citrix.com>
	<54786F2E.5070501@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8
	Model
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 12:48 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 28/11/14 11:47, Ian Campbell wrote:
> > On Thu, 2014-11-27 at 18:02 +0000, Julien Grall wrote:
> >> state at the GIC level. This would also avoid masking the output signal
> >> and requires specific handling in the guest OS.
> > 
> > "which requires"?
> > 
> > It doesn't seem quite right to me otherwise, since context switching the
> > virq state *removes* the need to have the guest do anything other than
> > what it would do on native.
> 
> I though the "avoid" would apply for both "masking" and "requires".

I think it reads with the avoid binding tightly to the masking only.

Possibly s/requires/requiring/ would have also corrected the meaning to
what you intended, although I would have changed the "and" to "or" as
well to make it less ambiguous.

> > Assuming this is what you meant I propose (fixing some grammar etc as I
> > go):
> 
> 
> Thanks for the correction, I will use this version. Shall I put your
> signed-off-by?

I don't think that's needed, its was pretty small.

(i.e. I wouldn't have added my S-o-b if I did it on commit).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:11:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLKh-0007zc-O6; Fri, 28 Nov 2014 13:11:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLKg-0007zS-5H
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 13:11:34 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	28/37-18267-58478745; Fri, 28 Nov 2014 13:11:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417180291!14526962!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6513 invoked from network); 28 Nov 2014 13:11:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:11:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197446416"
Message-ID: <1417180289.23604.47.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 28 Nov 2014 13:11:29 +0000
In-Reply-To: <5478819F020000780004B70D@mail.emea.novell.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 13:07 +0000, Jan Beulich wrote:
> I suppose a stubdom gets re-created on the target host (rather
> than migrated) when its client migrates.

Correct.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:11:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLKh-0007zc-O6; Fri, 28 Nov 2014 13:11:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuLKg-0007zS-5H
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 13:11:34 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	28/37-18267-58478745; Fri, 28 Nov 2014 13:11:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417180291!14526962!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6513 invoked from network); 28 Nov 2014 13:11:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:11:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208";a="197446416"
Message-ID: <1417180289.23604.47.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 28 Nov 2014 13:11:29 +0000
In-Reply-To: <5478819F020000780004B70D@mail.emea.novell.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 13:07 +0000, Jan Beulich wrote:
> I suppose a stubdom gets re-created on the target host (rather
> than migrated) when its client migrates.

Correct.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:20:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLSu-0008NR-ND; Fri, 28 Nov 2014 13:20: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 1XuLSt-0008NM-Fe
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 13:20:03 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	D1/20-01660-28678745; Fri, 28 Nov 2014 13:20:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417180799!13901579!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4397 invoked from network); 28 Nov 2014 13:20:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:20:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197726612"
Message-ID: <1417180797.23604.48.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 13:19:57 +0000
In-Reply-To: <1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: events: Deregister xenstore
 watch fd when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> We want to have no fd events registered when we are idle.
> In this patch, deal with the xenstore watch fd:
> 
> * Track the total number of active watches.
> * When deregistering a watch, or when watch registration fails, check
>   whether there are now no watches and if so deregister the fd.
> * On libxl teardown, the watch fd should therefore be unregistered.
>   assert that this is the case.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:20:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuLSu-0008NR-ND; Fri, 28 Nov 2014 13:20: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 1XuLSt-0008NM-Fe
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 13:20:03 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	D1/20-01660-28678745; Fri, 28 Nov 2014 13:20:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417180799!13901579!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4397 invoked from network); 28 Nov 2014 13:20:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:20:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197726612"
Message-ID: <1417180797.23604.48.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 13:19:57 +0000
In-Reply-To: <1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: events: Deregister xenstore
 watch fd when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> We want to have no fd events registered when we are idle.
> In this patch, deal with the xenstore watch fd:
> 
> * Track the total number of active watches.
> * When deregistering a watch, or when watch registration fails, check
>   whether there are now no watches and if so deregister the fd.
> * On libxl teardown, the watch fd should therefore be unregistered.
>   assert that this is the case.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:56:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuM1O-0000ri-OL; Fri, 28 Nov 2014 13:55:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XuM1N-0000rd-Gz
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 13:55:41 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	AD/75-03148-CDE78745; Fri, 28 Nov 2014 13:55:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417182938!11767416!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10973 invoked from network); 28 Nov 2014 13:55:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:55:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197734605"
Message-ID: <54787ED8.2010508@citrix.com>
Date: Fri, 28 Nov 2014 13:55:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
In-Reply-To: <5478819F020000780004B70D@mail.emea.novell.com>
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/11/14 13:07, Jan Beulich wrote:
>>>> On 28.11.14 at 12:36, <andrew.cooper3@citrix.com> wrote:
>> However, it occurs to me that HVMOP_op_mask absolutely must live in the
>> public header files, as it is guest visible, and forms part of the ABI.
>>
>> Consider a userspace task which falls into a continuation, is preempted
>> and paused by the guest kernel, the entire VM migrated, and the task
>> unpaused later.  If HVMOP_op_mask has changed in that time, the
>> continuation will become erroneous.
>>
>> In particular, all hypercall continuation strategies we use *must* be
>> forward compatible when moving to newer versions of Xen, because Xen
>> cannot possibly guarantee that a continuation which starts will finish
>> on the same hypervisor.
> Hmm, I see the issue, but surfacing such implementation details
> would not only be unfortunate, but eventually prevent us from
> making future changes. Just recall the mem-op case where we had
> to widen the continuation encoding mask at some point. Hence while
> I can't immediately see a way to avoid the situation you describe
> (and it doesn't even take a user space task in a preemptible kernel),
> I think we should allow ourselves a little more time to find possible
> solutions other than locking down these masks (really they don't
> need to be exposed in the public headers, but we would need
> them to not change if no other solution can be found).

It is certainly unfortunate, but I don't see that we have any choice. 
The implementation details of continuations have already slipped into
the ABI.

>
> One thing to note is that the _introduction_ of such a mask (as
> has happened for hvm-op between 4.4 and 4.5) is not a problem
> as long as the respective bits all being zero has no special
> meaning. What I considered for mem-op a while ago though (and
> then forgot again) was to refuse non-zero start_extent values
> for any operations not making use of that mechanism. The same
> would of course be applicable to gnttab-op and hvm-op.
>
> What might additionally make this not that urgent an issue for 4.5
> is that only XSM_DM_PRIV guarded operations are affected, and
> I suppose a stubdom gets re-created on the target host (rather
> than migrated) when its client migrates.

The problem is with continuations which reuse the upper bits of the
input register, not with this HVMOP_op_mask specifically; the
HVMOP_op_mask simply adds to an existing problem.  This is something
which needs considering urgently because, as you identify above, we have
already suffered an accidental ABI breakage with the mem-op widening.

32bit HVM guests reliably form a continuation on every single iteration
of a continuable hypercall (e.g. decrease reservation, which is the base
of my XSA-111 PoC), making it trivial to construct a migrateable HVM
domain which exposes the issue.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 13:56:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 13:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuM1O-0000ri-OL; Fri, 28 Nov 2014 13:55:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XuM1N-0000rd-Gz
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 13:55:41 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	AD/75-03148-CDE78745; Fri, 28 Nov 2014 13:55:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417182938!11767416!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10973 invoked from network); 28 Nov 2014 13:55:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 13:55:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197734605"
Message-ID: <54787ED8.2010508@citrix.com>
Date: Fri, 28 Nov 2014 13:55:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
In-Reply-To: <5478819F020000780004B70D@mail.emea.novell.com>
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/11/14 13:07, Jan Beulich wrote:
>>>> On 28.11.14 at 12:36, <andrew.cooper3@citrix.com> wrote:
>> However, it occurs to me that HVMOP_op_mask absolutely must live in the
>> public header files, as it is guest visible, and forms part of the ABI.
>>
>> Consider a userspace task which falls into a continuation, is preempted
>> and paused by the guest kernel, the entire VM migrated, and the task
>> unpaused later.  If HVMOP_op_mask has changed in that time, the
>> continuation will become erroneous.
>>
>> In particular, all hypercall continuation strategies we use *must* be
>> forward compatible when moving to newer versions of Xen, because Xen
>> cannot possibly guarantee that a continuation which starts will finish
>> on the same hypervisor.
> Hmm, I see the issue, but surfacing such implementation details
> would not only be unfortunate, but eventually prevent us from
> making future changes. Just recall the mem-op case where we had
> to widen the continuation encoding mask at some point. Hence while
> I can't immediately see a way to avoid the situation you describe
> (and it doesn't even take a user space task in a preemptible kernel),
> I think we should allow ourselves a little more time to find possible
> solutions other than locking down these masks (really they don't
> need to be exposed in the public headers, but we would need
> them to not change if no other solution can be found).

It is certainly unfortunate, but I don't see that we have any choice. 
The implementation details of continuations have already slipped into
the ABI.

>
> One thing to note is that the _introduction_ of such a mask (as
> has happened for hvm-op between 4.4 and 4.5) is not a problem
> as long as the respective bits all being zero has no special
> meaning. What I considered for mem-op a while ago though (and
> then forgot again) was to refuse non-zero start_extent values
> for any operations not making use of that mechanism. The same
> would of course be applicable to gnttab-op and hvm-op.
>
> What might additionally make this not that urgent an issue for 4.5
> is that only XSM_DM_PRIV guarded operations are affected, and
> I suppose a stubdom gets re-created on the target host (rather
> than migrated) when its client migrates.

The problem is with continuations which reuse the upper bits of the
input register, not with this HVMOP_op_mask specifically; the
HVMOP_op_mask simply adds to an existing problem.  This is something
which needs considering urgently because, as you identify above, we have
already suffered an accidental ABI breakage with the mem-op widening.

32bit HVM guests reliably form a continuation on every single iteration
of a continuable hypercall (e.g. decrease reservation, which is the base
of my XSA-111 PoC), making it trivial to construct a migrateable HVM
domain which exposes the issue.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:00:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 14:00:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuM6O-00016V-PG; Fri, 28 Nov 2014 14:00:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrew@fubar.geek.nz>) id 1XuM4m-0000yM-Fu
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 13:59:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B3/48-15461-FAF78745; Fri, 28 Nov 2014 13:59:11 +0000
X-Env-Sender: andrew@fubar.geek.nz
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417183141!12122335!1
X-Originating-IP: [199.48.134.198]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22035 invoked from network); 28 Nov 2014 13:59:02 -0000
Received: from nibbler.fubar.geek.nz (HELO nibbler.fubar.geek.nz)
	(199.48.134.198) by server-7.tower-21.messagelabs.com with SMTP;
	28 Nov 2014 13:59:02 -0000
Received: from bender.lan (97e078e7.skybroadband.com [151.224.120.231])
	by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id CC3FE7328F;
	Fri, 28 Nov 2014 13:57:42 +0000 (UTC)
Date: Fri, 28 Nov 2014 13:57:37 +0000
From: Andrew Turner <andrew@fubar.geek.nz>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141128135737.23a71643@bender.lan>
In-Reply-To: <54726138.3090003@linaro.org>
References: <54726138.3090003@linaro.org>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 28 Nov 2014 14:00:51 +0000
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	freebsd-xen@freebsd.org, freebsd-arm@freebsd.org,
	Denis Schneider <v1ne2go@gmail.com>, gibbs@freebsd.org,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [RFC v2] Add support for Xen ARM guest on FreeBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 23 Nov 2014 22:35:36 +0000
Julien Grall <julien.grall@linaro.org> wrote:
> Hello all,
> 
> At the beginning of the year, I have sent a first RFC to add support
> for FreeBSD on Xen ARM [1].
...
> Major changes in this new version:
>   	* Add Device Tree support via Linux Boot ABI
> 	* Add zImage support
> 	* Netfront support
> 	* Blkfront fixes
> 	* DOM0 support (separate branch see below)
> 
> The former item is very hackish. I was wondering if there is another
> way to do it? Or maybe we should support FreeBSD Bootloader in ARM
> guest?

I think using the loader is the correct way to handle booting in Xen. It
allows us to relocate the dtb as required. It look like a zImage then
use the Xen console to interact with the user.

> 
> The patch series is divided in X parts:
> 	* #1 - #14: Clean up and bug fixes for Xen. They can be
> applied without the rest of the series
>          * #15 - #19: Update Xen interface to 4.4 and fix
> compilation. It's required for ARM.
>          * #20 - #26: Update Xen code to support ARM
>          * #27 - #33: Rework the event channel code for supporting
> ARM. I will work with Royger to come with a common interface with x86
>          * #34 - #36: Add support for ARM in Xen code
>          * #37 - #46: ARM bug fixes and new features. Some of thoses 
> patches (#37 - #40) could be applied without the rest of the series
>          * #47 - #48: Add Xen ARM platform

I have committed patches 30 and 40 as they look good. I'm not familiar
with the code to review 37 or 38, however from my quick look at 38 I
appears _bus_dmamap_load_buffer does take in to account buflen and
dmat->maxsegsz when setting sgsize just not dmat->alignment.

...
> 
> TODO:
> 	* Add SMP/PSCI support in FreeBSD. Could be useful other
> platform too

Adding PSCI support is on my TODO lost for arm64, however I don't
expect to get on ti in until early next year.

> 	* Only FreeBSD to load anywhere. Currently there is a 2M
> alignment which require a patch in Xen.

If you use the loader this will be fixed as the loader can load the
kernel at the correct alignment.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:00:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 14:00:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuM6O-00016V-PG; Fri, 28 Nov 2014 14:00:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrew@fubar.geek.nz>) id 1XuM4m-0000yM-Fu
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 13:59:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B3/48-15461-FAF78745; Fri, 28 Nov 2014 13:59:11 +0000
X-Env-Sender: andrew@fubar.geek.nz
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417183141!12122335!1
X-Originating-IP: [199.48.134.198]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22035 invoked from network); 28 Nov 2014 13:59:02 -0000
Received: from nibbler.fubar.geek.nz (HELO nibbler.fubar.geek.nz)
	(199.48.134.198) by server-7.tower-21.messagelabs.com with SMTP;
	28 Nov 2014 13:59:02 -0000
Received: from bender.lan (97e078e7.skybroadband.com [151.224.120.231])
	by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id CC3FE7328F;
	Fri, 28 Nov 2014 13:57:42 +0000 (UTC)
Date: Fri, 28 Nov 2014 13:57:37 +0000
From: Andrew Turner <andrew@fubar.geek.nz>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141128135737.23a71643@bender.lan>
In-Reply-To: <54726138.3090003@linaro.org>
References: <54726138.3090003@linaro.org>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 28 Nov 2014 14:00:51 +0000
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	freebsd-xen@freebsd.org, freebsd-arm@freebsd.org,
	Denis Schneider <v1ne2go@gmail.com>, gibbs@freebsd.org,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [RFC v2] Add support for Xen ARM guest on FreeBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 23 Nov 2014 22:35:36 +0000
Julien Grall <julien.grall@linaro.org> wrote:
> Hello all,
> 
> At the beginning of the year, I have sent a first RFC to add support
> for FreeBSD on Xen ARM [1].
...
> Major changes in this new version:
>   	* Add Device Tree support via Linux Boot ABI
> 	* Add zImage support
> 	* Netfront support
> 	* Blkfront fixes
> 	* DOM0 support (separate branch see below)
> 
> The former item is very hackish. I was wondering if there is another
> way to do it? Or maybe we should support FreeBSD Bootloader in ARM
> guest?

I think using the loader is the correct way to handle booting in Xen. It
allows us to relocate the dtb as required. It look like a zImage then
use the Xen console to interact with the user.

> 
> The patch series is divided in X parts:
> 	* #1 - #14: Clean up and bug fixes for Xen. They can be
> applied without the rest of the series
>          * #15 - #19: Update Xen interface to 4.4 and fix
> compilation. It's required for ARM.
>          * #20 - #26: Update Xen code to support ARM
>          * #27 - #33: Rework the event channel code for supporting
> ARM. I will work with Royger to come with a common interface with x86
>          * #34 - #36: Add support for ARM in Xen code
>          * #37 - #46: ARM bug fixes and new features. Some of thoses 
> patches (#37 - #40) could be applied without the rest of the series
>          * #47 - #48: Add Xen ARM platform

I have committed patches 30 and 40 as they look good. I'm not familiar
with the code to review 37 or 38, however from my quick look at 38 I
appears _bus_dmamap_load_buffer does take in to account buflen and
dmat->maxsegsz when setting sgsize just not dmat->alignment.

...
> 
> TODO:
> 	* Add SMP/PSCI support in FreeBSD. Could be useful other
> platform too

Adding PSCI support is on my TODO lost for arm64, however I don't
expect to get on ti in until early next year.

> 	* Only FreeBSD to load anywhere. Currently there is a 2M
> alignment which require a patch in Xen.

If you use the loader this will be fixed as the loader can load the
kernel at the correct alignment.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:42:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 14:42:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuMke-00027s-JC; Fri, 28 Nov 2014 14:42:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuMkd-00027n-Hg
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 14:42:27 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	35/4C-09284-2D988745; Fri, 28 Nov 2014 14:42:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417185744!14575559!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32758 invoked from network); 28 Nov 2014 14:42:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 14:42:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197467956"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 09:42:24 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuMkZ-0006b7-S6;
	Fri, 28 Nov 2014 14:42:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuMkZ-0002OP-Gb;
	Fri, 28 Nov 2014 14:42:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.35279.122692.298650@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 14:42:23 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417178932.23604.38.camel@citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-4-git-send-email-ian.jackson@eu.citrix.com>
	<1417178932.23604.38.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3/6] libxl: events: Deregister,
 don't just modify, sigchld pipe fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 3/6] libxl: events: Deregister, don't just modify, sigchld pipe fd"):
> On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > We want to have no fd events registered when we are idle.  This
> > implies that we must be able to deregister our interest in the sigchld
> > self-pipe fd, not just modify to request no events.
> > 
> > Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I think in principal there is now some redundant code in
> libxl__sigchld_needed which calls modify to set POLLIN if the fd is not
> registered. I think it's redundant because now the fd is registered iff
> it is looking for POLLIN.

You're right.  (Although you mean `calls modify if the fd /is/
registered'.)

I wonder if it would be better to leave tidying that up until
post-4.5, in case we are wrong.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:42:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 14:42:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuMke-00027s-JC; Fri, 28 Nov 2014 14:42:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuMkd-00027n-Hg
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 14:42:27 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	35/4C-09284-2D988745; Fri, 28 Nov 2014 14:42:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417185744!14575559!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32758 invoked from network); 28 Nov 2014 14:42:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 14:42:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197467956"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 09:42:24 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuMkZ-0006b7-S6;
	Fri, 28 Nov 2014 14:42:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuMkZ-0002OP-Gb;
	Fri, 28 Nov 2014 14:42:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.35279.122692.298650@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 14:42:23 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417178932.23604.38.camel@citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-4-git-send-email-ian.jackson@eu.citrix.com>
	<1417178932.23604.38.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3/6] libxl: events: Deregister,
 don't just modify, sigchld pipe fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 3/6] libxl: events: Deregister, don't just modify, sigchld pipe fd"):
> On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > We want to have no fd events registered when we are idle.  This
> > implies that we must be able to deregister our interest in the sigchld
> > self-pipe fd, not just modify to request no events.
> > 
> > Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I think in principal there is now some redundant code in
> libxl__sigchld_needed which calls modify to set POLLIN if the fd is not
> registered. I think it's redundant because now the fd is registered iff
> it is looking for POLLIN.

You're right.  (Although you mean `calls modify if the fd /is/
registered'.)

I wonder if it would be better to leave tidying that up until
post-4.5, in case we are wrong.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:45:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 14:45:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuMn7-0002DY-SC; Fri, 28 Nov 2014 14:45:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuMn6-0002DT-E4
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 14:45:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1E/96-09842-B6A88745; Fri, 28 Nov 2014 14:44:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417185898!12153778!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7881 invoked from network); 28 Nov 2014 14: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;
	28 Nov 2014 14:44:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197747266"
Message-ID: <1417185896.23604.52.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 14:44:56 +0000
In-Reply-To: <21624.35279.122692.298650@mariner.uk.xensource.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-4-git-send-email-ian.jackson@eu.citrix.com>
	<1417178932.23604.38.camel@citrix.com>
	<21624.35279.122692.298650@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3/6] libxl: events: Deregister,
 don't just modify, sigchld pipe fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 14:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 3/6] libxl: events: Deregister, don't just modify, sigchld pipe fd"):
> > On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > > We want to have no fd events registered when we are idle.  This
> > > implies that we must be able to deregister our interest in the sigchld
> > > self-pipe fd, not just modify to request no events.
> > > 
> > > Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > I think in principal there is now some redundant code in
> > libxl__sigchld_needed which calls modify to set POLLIN if the fd is not
> > registered. I think it's redundant because now the fd is registered iff
> > it is looking for POLLIN.
> 
> You're right.  (Although you mean `calls modify if the fd /is/
> registered'.)

Indeed.

> I wonder if it would be better to leave tidying that up until
> post-4.5, in case we are wrong.

Sure.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:45:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 14:45:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuMn7-0002DY-SC; Fri, 28 Nov 2014 14:45:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuMn6-0002DT-E4
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 14:45:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1E/96-09842-B6A88745; Fri, 28 Nov 2014 14:44:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417185898!12153778!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7881 invoked from network); 28 Nov 2014 14: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;
	28 Nov 2014 14:44:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197747266"
Message-ID: <1417185896.23604.52.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 14:44:56 +0000
In-Reply-To: <21624.35279.122692.298650@mariner.uk.xensource.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-4-git-send-email-ian.jackson@eu.citrix.com>
	<1417178932.23604.38.camel@citrix.com>
	<21624.35279.122692.298650@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3/6] libxl: events: Deregister,
 don't just modify, sigchld pipe fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 14:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 3/6] libxl: events: Deregister, don't just modify, sigchld pipe fd"):
> > On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > > We want to have no fd events registered when we are idle.  This
> > > implies that we must be able to deregister our interest in the sigchld
> > > self-pipe fd, not just modify to request no events.
> > > 
> > > Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > I think in principal there is now some redundant code in
> > libxl__sigchld_needed which calls modify to set POLLIN if the fd is not
> > registered. I think it's redundant because now the fd is registered iff
> > it is looking for POLLIN.
> 
> You're right.  (Although you mean `calls modify if the fd /is/
> registered'.)

Indeed.

> I wonder if it would be better to leave tidying that up until
> post-4.5, in case we are wrong.

Sure.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:47:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 14: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 1XuMpd-0002Rr-ES; Fri, 28 Nov 2014 14:47:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuMpc-0002QN-9p
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 14:47:36 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	19/BA-02702-70B88745; Fri, 28 Nov 2014 14:47:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417186053!11788776!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5651 invoked from network); 28 Nov 2014 14:47:35 -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 Nov 2014 14:47:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197747971"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 09:47:32 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuMpY-0006ju-BM;
	Fri, 28 Nov 2014 14:47:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuMpX-0002PS-W0;
	Fri, 28 Nov 2014 14:47:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.35587.721780.498045@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 14:47:31 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417179851.23604.41.camel@citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-6-git-send-email-ian.jackson@eu.citrix.com>
	<1417179851.23604.41.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: events: Deregister evtchn fd
	when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 5/6] libxl: events: Deregister evtchn fd when not needed"):
> On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > We want to have no fd events registered when we are idle.
> > In this patch, deal with the evtchn fd:
> > 
> >  * Defer setup of the evtchn handle to the first use.
> >  * Defer registration of the evtchn fd; register as needed on use.
> >  * When cancelling an evtchn wait, or when wait setup fails, check
> >    whether there are now no evtchn waits and if so deregister the fd.
> >  * On libxl teardown, the evtchn fd should therefore be unregistered.
> >    assert that this is the case.
> 
> Is there no locking required when registering/deregistering? Since there
> are list manipulations in most of these places I presume it already
> exists, but I thought I should check.

libxl__ev_evtchn_* is always called with the ctx lock held.

However, that they don't take the lock is contrary to the rules stated
for libxl__ev_* in the doc comment.  That should be fixed for 4.6.

libxl__ev_fd_* already take and release the lock to protect their own
data structures etc.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:47:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 14: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 1XuMpd-0002Rr-ES; Fri, 28 Nov 2014 14:47:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuMpc-0002QN-9p
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 14:47:36 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	19/BA-02702-70B88745; Fri, 28 Nov 2014 14:47:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417186053!11788776!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5651 invoked from network); 28 Nov 2014 14:47:35 -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 Nov 2014 14:47:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197747971"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 09:47:32 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuMpY-0006ju-BM;
	Fri, 28 Nov 2014 14:47:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuMpX-0002PS-W0;
	Fri, 28 Nov 2014 14:47:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.35587.721780.498045@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 14:47:31 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417179851.23604.41.camel@citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-6-git-send-email-ian.jackson@eu.citrix.com>
	<1417179851.23604.41.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: events: Deregister evtchn fd
	when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 5/6] libxl: events: Deregister evtchn fd when not needed"):
> On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > We want to have no fd events registered when we are idle.
> > In this patch, deal with the evtchn fd:
> > 
> >  * Defer setup of the evtchn handle to the first use.
> >  * Defer registration of the evtchn fd; register as needed on use.
> >  * When cancelling an evtchn wait, or when wait setup fails, check
> >    whether there are now no evtchn waits and if so deregister the fd.
> >  * On libxl teardown, the evtchn fd should therefore be unregistered.
> >    assert that this is the case.
> 
> Is there no locking required when registering/deregistering? Since there
> are list manipulations in most of these places I presume it already
> exists, but I thought I should check.

libxl__ev_evtchn_* is always called with the ctx lock held.

However, that they don't take the lock is contrary to the rules stated
for libxl__ev_* in the doc comment.  That should be fixed for 4.6.

libxl__ev_fd_* already take and release the lock to protect their own
data structures etc.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:52:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 14:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuMuT-0002mg-6R; Fri, 28 Nov 2014 14:52:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuMuR-0002mb-LN
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 14:52:35 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	D7/45-14214-33C88745; Fri, 28 Nov 2014 14:52:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417186352!6315728!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9847 invoked from network); 28 Nov 2014 14:52:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 14:52:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197470379"
Message-ID: <1417186350.23604.54.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 14:52:30 +0000
In-Reply-To: <21624.35587.721780.498045@mariner.uk.xensource.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-6-git-send-email-ian.jackson@eu.citrix.com>
	<1417179851.23604.41.camel@citrix.com>
	<21624.35587.721780.498045@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: events: Deregister evtchn fd
	when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 14:47 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 5/6] libxl: events: Deregister evtchn fd when not needed"):
> > On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > > We want to have no fd events registered when we are idle.
> > > In this patch, deal with the evtchn fd:
> > > 
> > >  * Defer setup of the evtchn handle to the first use.
> > >  * Defer registration of the evtchn fd; register as needed on use.
> > >  * When cancelling an evtchn wait, or when wait setup fails, check
> > >    whether there are now no evtchn waits and if so deregister the fd.
> > >  * On libxl teardown, the evtchn fd should therefore be unregistered.
> > >    assert that this is the case.
> > 
> > Is there no locking required when registering/deregistering? Since there
> > are list manipulations in most of these places I presume it already
> > exists, but I thought I should check.
> 
> libxl__ev_evtchn_* is always called with the ctx lock held.

For the most part this is implicit due to the caller being in an ao
callback, right?

> However, that they don't take the lock is contrary to the rules stated
> for libxl__ev_* in the doc comment.  That should be fixed for 4.6.

OK.

> libxl__ev_fd_* already take and release the lock to protect their own
> data structures etc.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:52:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 14:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuMuT-0002mg-6R; Fri, 28 Nov 2014 14:52:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuMuR-0002mb-LN
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 14:52:35 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	D7/45-14214-33C88745; Fri, 28 Nov 2014 14:52:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417186352!6315728!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9847 invoked from network); 28 Nov 2014 14:52:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 14:52:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197470379"
Message-ID: <1417186350.23604.54.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 14:52:30 +0000
In-Reply-To: <21624.35587.721780.498045@mariner.uk.xensource.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-6-git-send-email-ian.jackson@eu.citrix.com>
	<1417179851.23604.41.camel@citrix.com>
	<21624.35587.721780.498045@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: events: Deregister evtchn fd
	when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 14:47 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 5/6] libxl: events: Deregister evtchn fd when not needed"):
> > On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > > We want to have no fd events registered when we are idle.
> > > In this patch, deal with the evtchn fd:
> > > 
> > >  * Defer setup of the evtchn handle to the first use.
> > >  * Defer registration of the evtchn fd; register as needed on use.
> > >  * When cancelling an evtchn wait, or when wait setup fails, check
> > >    whether there are now no evtchn waits and if so deregister the fd.
> > >  * On libxl teardown, the evtchn fd should therefore be unregistered.
> > >    assert that this is the case.
> > 
> > Is there no locking required when registering/deregistering? Since there
> > are list manipulations in most of these places I presume it already
> > exists, but I thought I should check.
> 
> libxl__ev_evtchn_* is always called with the ctx lock held.

For the most part this is implicit due to the caller being in an ao
callback, right?

> However, that they don't take the lock is contrary to the rules stated
> for libxl__ev_* in the doc comment.  That should be fixed for 4.6.

OK.

> libxl__ev_fd_* already take and release the lock to protect their own
> data structures etc.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:56:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 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 1XuMxv-0002uH-PQ; Fri, 28 Nov 2014 14:56:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuMxv-0002uC-Dz
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 14:56:11 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	0A/E8-17735-A0D88745; Fri, 28 Nov 2014 14:56:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417186568!10120865!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29739 invoked from network); 28 Nov 2014 14:56:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 14:56:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197471149"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 09:56:08 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuMxr-0006wr-KI;
	Fri, 28 Nov 2014 14:56:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuMxq-0002Qo-GI;
	Fri, 28 Nov 2014 14:56:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.36102.93368.357206@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 14:56:06 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417180012.23604.44.camel@citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
	<1417180012.23604.44.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: events: Deregister xenstore
 watch fd when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 2/6] libxl: events: Deregister xenstore watch fd when not needed"):
> On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > * On libxl teardown, the watch fd should therefore be unregistered.
> >   assert that this is the case.
> 
> A bunch of the patches in this series basically assume that the ctx is
> idle when it is freed, i.e. it requires everything to be explicitly
> cancelled rather than implicitly doing so on free.

libxl_ctx_free explicitly disables all the application-requested event
generators.  (free_disable_deaths and libxl__evdisable_disk_eject.)

Destroying the ctx during the execution of an asynchronous operation
is forbidden by this text in libxl.h (near line 813):
  * *ao_how does not need to remain valid after the initiating function
  * returns. All other parameters must remain valid for the lifetime of
  * the asynchronous operation, unless otherwise specified.
That implies that the ctx must remain valid during the ao, so it may
not be destroyed beforehand.

Those are the two ways that, even without any threads inside libxl, a
ctx can be other than idle.

It should be obvious to the application programmer that destroying the
ctx when there are other threads inside libxl is not going to work.
Indeed a programmer who tries to destroy the ctx when they have
threads which might be inside libxl cannot ensure that the ctx is
valid even on entry to libxl.

> I think this is a fine restriction, but it probably ought to be written
> down.

Does the above demonstrate that the existing restrictions are
documented ?  I'd rather avoid writing the restrictions twice if it
can be avoided - these docs are long enough as they are.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 14:56:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 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 1XuMxv-0002uH-PQ; Fri, 28 Nov 2014 14:56:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuMxv-0002uC-Dz
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 14:56:11 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	0A/E8-17735-A0D88745; Fri, 28 Nov 2014 14:56:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417186568!10120865!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29739 invoked from network); 28 Nov 2014 14:56:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 14:56:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197471149"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 09:56:08 -0500
Received: from mariner.uk.xensource.com ([10.80.2.22])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuMxr-0006wr-KI;
	Fri, 28 Nov 2014 14:56:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuMxq-0002Qo-GI;
	Fri, 28 Nov 2014 14:56:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21624.36102.93368.357206@mariner.uk.xensource.com>
Date: Fri, 28 Nov 2014 14:56:06 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417180012.23604.44.camel@citrix.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
	<1417180012.23604.44.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: events: Deregister xenstore
 watch fd when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 2/6] libxl: events: Deregister xenstore watch fd when not needed"):
> On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > * On libxl teardown, the watch fd should therefore be unregistered.
> >   assert that this is the case.
> 
> A bunch of the patches in this series basically assume that the ctx is
> idle when it is freed, i.e. it requires everything to be explicitly
> cancelled rather than implicitly doing so on free.

libxl_ctx_free explicitly disables all the application-requested event
generators.  (free_disable_deaths and libxl__evdisable_disk_eject.)

Destroying the ctx during the execution of an asynchronous operation
is forbidden by this text in libxl.h (near line 813):
  * *ao_how does not need to remain valid after the initiating function
  * returns. All other parameters must remain valid for the lifetime of
  * the asynchronous operation, unless otherwise specified.
That implies that the ctx must remain valid during the ao, so it may
not be destroyed beforehand.

Those are the two ways that, even without any threads inside libxl, a
ctx can be other than idle.

It should be obvious to the application programmer that destroying the
ctx when there are other threads inside libxl is not going to work.
Indeed a programmer who tries to destroy the ctx when they have
threads which might be inside libxl cannot ensure that the ctx is
valid even on entry to libxl.

> I think this is a fine restriction, but it probably ought to be written
> down.

Does the above demonstrate that the existing restrictions are
documented ?  I'd rather avoid writing the restrictions twice if it
can be avoided - these docs are long enough as they are.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:01:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15: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 1XuN2Z-00034j-HT; Fri, 28 Nov 2014 15:00:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuN2Y-00034e-1k
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 15:00:58 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	31/DA-08051-92E88745; Fri, 28 Nov 2014 15:00:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417186855!11785576!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18609 invoked from network); 28 Nov 2014 15:00:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:00:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197472384"
Message-ID: <1417186853.23604.56.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 15:00:53 +0000
In-Reply-To: <21624.36102.93368.357206@mariner.uk.xensource.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
	<1417180012.23604.44.camel@citrix.com>
	<21624.36102.93368.357206@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: events: Deregister xenstore
 watch fd when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 14:56 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 2/6] libxl: events: Deregister xenstore watch fd when not needed"):
> > On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > > * On libxl teardown, the watch fd should therefore be unregistered.
> > >   assert that this is the case.
> > 
> > A bunch of the patches in this series basically assume that the ctx is
> > idle when it is freed, i.e. it requires everything to be explicitly
> > cancelled rather than implicitly doing so on free.
> 
> libxl_ctx_free explicitly disables all the application-requested event
> generators.  (free_disable_deaths and libxl__evdisable_disk_eject.)

So it does, I was looking for that before commenting but didn't see
those calls for what they were, despite the comment right there...

> Destroying the ctx during the execution of an asynchronous operation
> is forbidden by this text in libxl.h (near line 813):
>   * *ao_how does not need to remain valid after the initiating function
>   * returns. All other parameters must remain valid for the lifetime of
>   * the asynchronous operation, unless otherwise specified.
> That implies that the ctx must remain valid during the ao, so it may
> not be destroyed beforehand.
> 
> Those are the two ways that, even without any threads inside libxl, a
> ctx can be other than idle.
> 
> It should be obvious to the application programmer that destroying the
> ctx when there are other threads inside libxl is not going to work.
> Indeed a programmer who tries to destroy the ctx when they have
> threads which might be inside libxl cannot ensure that the ctx is
> valid even on entry to libxl.
> 
> > I think this is a fine restriction, but it probably ought to be written
> > down.
> 
> Does the above demonstrate that the existing restrictions are
> documented ?

Yes.

>   I'd rather avoid writing the restrictions twice if it
> can be avoided - these docs are long enough as they are.

Indeed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:01:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15: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 1XuN2Z-00034j-HT; Fri, 28 Nov 2014 15:00:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuN2Y-00034e-1k
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 15:00:58 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	31/DA-08051-92E88745; Fri, 28 Nov 2014 15:00:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417186855!11785576!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18609 invoked from network); 28 Nov 2014 15:00:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:00:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197472384"
Message-ID: <1417186853.23604.56.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 28 Nov 2014 15:00:53 +0000
In-Reply-To: <21624.36102.93368.357206@mariner.uk.xensource.com>
References: <1417083745.12784.1.camel@citrix.com>
	<1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1417112870-31894-3-git-send-email-ian.jackson@eu.citrix.com>
	<1417180012.23604.44.camel@citrix.com>
	<21624.36102.93368.357206@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: events: Deregister xenstore
 watch fd when not needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 14:56 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 2/6] libxl: events: Deregister xenstore watch fd when not needed"):
> > On Thu, 2014-11-27 at 18:27 +0000, Ian Jackson wrote:
> > > * On libxl teardown, the watch fd should therefore be unregistered.
> > >   assert that this is the case.
> > 
> > A bunch of the patches in this series basically assume that the ctx is
> > idle when it is freed, i.e. it requires everything to be explicitly
> > cancelled rather than implicitly doing so on free.
> 
> libxl_ctx_free explicitly disables all the application-requested event
> generators.  (free_disable_deaths and libxl__evdisable_disk_eject.)

So it does, I was looking for that before commenting but didn't see
those calls for what they were, despite the comment right there...

> Destroying the ctx during the execution of an asynchronous operation
> is forbidden by this text in libxl.h (near line 813):
>   * *ao_how does not need to remain valid after the initiating function
>   * returns. All other parameters must remain valid for the lifetime of
>   * the asynchronous operation, unless otherwise specified.
> That implies that the ctx must remain valid during the ao, so it may
> not be destroyed beforehand.
> 
> Those are the two ways that, even without any threads inside libxl, a
> ctx can be other than idle.
> 
> It should be obvious to the application programmer that destroying the
> ctx when there are other threads inside libxl is not going to work.
> Indeed a programmer who tries to destroy the ctx when they have
> threads which might be inside libxl cannot ensure that the ctx is
> valid even on entry to libxl.
> 
> > I think this is a fine restriction, but it probably ought to be written
> > down.
> 
> Does the above demonstrate that the existing restrictions are
> documented ?

Yes.

>   I'd rather avoid writing the restrictions twice if it
> can be avoided - these docs are long enough as they are.

Indeed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:09:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:09:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNAY-0003Nj-Gf; Fri, 28 Nov 2014 15:09:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuNAX-0003Ne-Bq
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 15:09:13 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	F1/86-02954-81098745; Fri, 28 Nov 2014 15:09:12 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417187350!11787875!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30567 invoked from network); 28 Nov 2014 15:09:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:09:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197474812"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 10:08:59 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuNAI-0007AP-Rv;
	Fri, 28 Nov 2014 15:08:58 +0000
Date: Fri, 28 Nov 2014 15:08:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <4610426124.20141126210436@eikelenboom.it>
Message-ID: <alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, stefano.stabellini@eu.citrix.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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

create ^
title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
thanks

On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> Hi,
> 
> While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> xl didn't show any problems on the commandline so i never drawed much attention 
> to it, but /var/log/xen/xl-guest.log shows:
> 
>     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
>     Domain 19 has shut down, reason code 0 0x0
>     Action for shutdown reason code 0 is destroy
>     Domain 19 needs to be cleaned up: destroying the domain
>     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
>     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
>     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
>     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
>     Done. Exiting now
> 
> So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> 
> --
> Sander
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:09:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:09:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNAY-0003Nj-Gf; Fri, 28 Nov 2014 15:09:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuNAX-0003Ne-Bq
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 15:09:13 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	F1/86-02954-81098745; Fri, 28 Nov 2014 15:09:12 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417187350!11787875!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30567 invoked from network); 28 Nov 2014 15:09:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:09:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197474812"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 10:08:59 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuNAI-0007AP-Rv;
	Fri, 28 Nov 2014 15:08:58 +0000
Date: Fri, 28 Nov 2014 15:08:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <4610426124.20141126210436@eikelenboom.it>
Message-ID: <alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, stefano.stabellini@eu.citrix.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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

create ^
title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
thanks

On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> Hi,
> 
> While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> xl didn't show any problems on the commandline so i never drawed much attention 
> to it, but /var/log/xen/xl-guest.log shows:
> 
>     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
>     Domain 19 has shut down, reason code 0 0x0
>     Action for shutdown reason code 0 is destroy
>     Domain 19 needs to be cleaned up: destroying the domain
>     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
>     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
>     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
>     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
>     Done. Exiting now
> 
> So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> 
> --
> Sander
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:17:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 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.xen.org>)
	id 1XuNIM-0003gf-Eb; Fri, 28 Nov 2014 15:17:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XuNIK-0003ga-Fa
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 15:17:16 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	75/B4-24124-BF198745; Fri, 28 Nov 2014 15:17:15 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417187833!8617071!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28549 invoked from network); 28 Nov 2014 15:17:13 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:17:13 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so18905043wiw.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 28 Nov 2014 07:17:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=dDT2vOfidqMn0RqB5kxr64cB5WGVf5fo+RilUCbOx8g=;
	b=BUAoeIiCG7DxFqf8FdMl8z3/RX10++z0Box+nfQMaJvH0rQLL3KAcJRPmwRpjd8+O3
	48GJwLkp3O/xwA4VhTh7PlfJCTWUXi4BmNG34CI/gm0FLSnH/7Mvh75z4SQW6L4wInWT
	XG9g4YjLuJLQ5wpgKVlKwd1i22mG/XV7SgKpk9mMybZH+JoS2GSTsofzsqRS0Z1JP2bR
	g9kMYmEHYaLktdgDTft2EugDBoy67qU3IbWQDY9vBXEFGFyriFtt1KRuPsMiPAtiwQMC
	VlsRGDICqMT7XPLjEGZPMIr+g8sQTOUBvWr4a/xlkH0NIZVsbHE8QApsAj+CuSL1i6t8
	IS8g==
X-Gm-Message-State: ALoCoQldv+5tuahFiYyB4z+2RyiaGsZUMMTjNvIJ8I1/6DLA11/rUvQ5AOqIf7PCmyT3WXLUx2QA
X-Received: by 10.180.80.133 with SMTP id r5mr60733815wix.20.1417187833102;
	Fri, 28 Nov 2014 07:17:13 -0800 (PST)
Received: from chilopoda.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id d2sm15387726wjs.32.2014.11.28.07.17.11
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 28 Nov 2014 07:17:12 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 28 Nov 2014 15:17:06 +0000
Message-Id: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
Cc: stefano.stabellini@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] xen/arm: Handle platforms with edge-triggered
	virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some platforms (such as Xgene and ARMv8 models) use an edge-triggered interrupt
for the virtual timer. Even if the timer output signal is masked in the
context switch, the GIC will keep track that of any interrupts raised
while IRQs are disabled. As soon as IRQs are re-enabled, the virtual
interrupt timer will be injected to Xen.

If an idle vVCPU was scheduled next then the interrupt handler doesn't
expect to the receive the IRQ and will crash:

(XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
(XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
(XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
(XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
(XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
(XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
(XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
(XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
(XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
(XEN)    [<000000000022482c>] schedule+0x684/0x6d0
(XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
(XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
(XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
(XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
(XEN)    [<0000000000000001>] 0000000000000001

The proper solution is to context switch the virtual interrupt state at
the GIC level. This would also avoid masking the output signal which
requires specific handling in the guest OS and more complex code in Xen
to deal with EOIs, and so is desirable for that reason too.

Sadly, this solution requires some refactoring which would not be
suitable for a freeze exception for the Xen 4.5 release.

For now implement a temporary solution which ignores the virtual timer
interrupt when the idle VCPU is running.

Signed-off-by: Julien Grall <julien.grall@linaro.org>

---

Changes in v2:
    - Reword the commit message and comment in the code to explain the
    real bug. Based on Ian's reword.
    - Use unlikely

This patch is a bug fix candidate for Xen 4.5 and backport for Xen 4.4.
It affects at least Xgene platform and ARMv8 models where Xen may
randomly crash.

This patch don't inject the virtual timer interrupt if the current VCPU
is the idle one. For now, I think this patch is the safest way to resolve
the problem.

I will work on a proper solution for Xen 4.6.
---
 xen/arch/arm/time.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index a6436f1..471d7a9 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -169,6 +169,19 @@ static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 
 static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
+    /*
+     * Edge-triggered interrupt can be used for the virtual timer. Even
+     * if the timer output signal is masked in the context switch, the
+     * GIC will keep track that of any interrupts raised while IRQS as
+     * disabled. As soon as IRQs are re-enabled, the virtual interrupt
+     * will be injected to Xen.
+     *
+     * If an IDLE vCPU was scheduled next then we should ignore the
+     * interrupt.
+     */
+    if ( unlikely(is_idle_vcpu(current)) )
+        return;
+
     current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
     WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
     vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq);
-- 
2.1.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:17:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 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.xen.org>)
	id 1XuNIM-0003gf-Eb; Fri, 28 Nov 2014 15:17:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XuNIK-0003ga-Fa
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 15:17:16 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	75/B4-24124-BF198745; Fri, 28 Nov 2014 15:17:15 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417187833!8617071!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28549 invoked from network); 28 Nov 2014 15:17:13 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:17:13 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so18905043wiw.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 28 Nov 2014 07:17:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id;
	bh=dDT2vOfidqMn0RqB5kxr64cB5WGVf5fo+RilUCbOx8g=;
	b=BUAoeIiCG7DxFqf8FdMl8z3/RX10++z0Box+nfQMaJvH0rQLL3KAcJRPmwRpjd8+O3
	48GJwLkp3O/xwA4VhTh7PlfJCTWUXi4BmNG34CI/gm0FLSnH/7Mvh75z4SQW6L4wInWT
	XG9g4YjLuJLQ5wpgKVlKwd1i22mG/XV7SgKpk9mMybZH+JoS2GSTsofzsqRS0Z1JP2bR
	g9kMYmEHYaLktdgDTft2EugDBoy67qU3IbWQDY9vBXEFGFyriFtt1KRuPsMiPAtiwQMC
	VlsRGDICqMT7XPLjEGZPMIr+g8sQTOUBvWr4a/xlkH0NIZVsbHE8QApsAj+CuSL1i6t8
	IS8g==
X-Gm-Message-State: ALoCoQldv+5tuahFiYyB4z+2RyiaGsZUMMTjNvIJ8I1/6DLA11/rUvQ5AOqIf7PCmyT3WXLUx2QA
X-Received: by 10.180.80.133 with SMTP id r5mr60733815wix.20.1417187833102;
	Fri, 28 Nov 2014 07:17:13 -0800 (PST)
Received: from chilopoda.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id d2sm15387726wjs.32.2014.11.28.07.17.11
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 28 Nov 2014 07:17:12 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 28 Nov 2014 15:17:06 +0000
Message-Id: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
Cc: stefano.stabellini@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] xen/arm: Handle platforms with edge-triggered
	virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some platforms (such as Xgene and ARMv8 models) use an edge-triggered interrupt
for the virtual timer. Even if the timer output signal is masked in the
context switch, the GIC will keep track that of any interrupts raised
while IRQs are disabled. As soon as IRQs are re-enabled, the virtual
interrupt timer will be injected to Xen.

If an idle vVCPU was scheduled next then the interrupt handler doesn't
expect to the receive the IRQ and will crash:

(XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
(XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
(XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
(XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
(XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
(XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
(XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
(XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
(XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
(XEN)    [<000000000022482c>] schedule+0x684/0x6d0
(XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
(XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
(XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
(XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
(XEN)    [<0000000000000001>] 0000000000000001

The proper solution is to context switch the virtual interrupt state at
the GIC level. This would also avoid masking the output signal which
requires specific handling in the guest OS and more complex code in Xen
to deal with EOIs, and so is desirable for that reason too.

Sadly, this solution requires some refactoring which would not be
suitable for a freeze exception for the Xen 4.5 release.

For now implement a temporary solution which ignores the virtual timer
interrupt when the idle VCPU is running.

Signed-off-by: Julien Grall <julien.grall@linaro.org>

---

Changes in v2:
    - Reword the commit message and comment in the code to explain the
    real bug. Based on Ian's reword.
    - Use unlikely

This patch is a bug fix candidate for Xen 4.5 and backport for Xen 4.4.
It affects at least Xgene platform and ARMv8 models where Xen may
randomly crash.

This patch don't inject the virtual timer interrupt if the current VCPU
is the idle one. For now, I think this patch is the safest way to resolve
the problem.

I will work on a proper solution for Xen 4.6.
---
 xen/arch/arm/time.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index a6436f1..471d7a9 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -169,6 +169,19 @@ static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 
 static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
+    /*
+     * Edge-triggered interrupt can be used for the virtual timer. Even
+     * if the timer output signal is masked in the context switch, the
+     * GIC will keep track that of any interrupts raised while IRQS as
+     * disabled. As soon as IRQs are re-enabled, the virtual interrupt
+     * will be injected to Xen.
+     *
+     * If an IDLE vCPU was scheduled next then we should ignore the
+     * interrupt.
+     */
+    if ( unlikely(is_idle_vcpu(current)) )
+        return;
+
     current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
     WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
     vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq);
-- 
2.1.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:18:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNJY-0003mM-1m; Fri, 28 Nov 2014 15:18:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuNJW-0003mC-I3
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 15:18:30 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8B/E0-09842-54298745; Fri, 28 Nov 2014 15:18:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417187909!12103487!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31397 invoked from network); 28 Nov 2014 15:18:29 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 15:18:29 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 15:18:29 +0000
Message-Id: <5478A056020000780004B7CE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 15:18:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
In-Reply-To: <54787ED8.2010508@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.11.14 at 14:55, <andrew.cooper3@citrix.com> wrote:
> The problem is with continuations which reuse the upper bits of the
> input register, not with this HVMOP_op_mask specifically; the
> HVMOP_op_mask simply adds to an existing problem.  This is something
> which needs considering urgently because, as you identify above, we have
> already suffered an accidental ABI breakage with the mem-op widening.

Since we can't retroactively fix the mem-op widening, I still don't see
what's urgent here: As long as we don't change any of these masks,
nothing bad is going to happen. Of course one thing to consider with
this aspect in mind is whether to change the hvm-op or gnttab-op
masks again _before_ 4.5 goes out, based on whether we feel they're
wide enough for the (un)foreseeable future.

> 32bit HVM guests reliably form a continuation on every single iteration
> of a continuable hypercall (e.g. decrease reservation, which is the base
> of my XSA-111 PoC), making it trivial to construct a migrateable HVM
> domain which exposes the issue.

Hmm, I can't offhand see why that would be, but what you write
reads like you determined the reason? I ask because an unavoidable
use of continuations is certainly nice for making sure those code paths
get tested, but would be quite desirable to get eliminated at least for
non-debug builds.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:18:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNJY-0003mM-1m; Fri, 28 Nov 2014 15:18:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XuNJW-0003mC-I3
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 15:18:30 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8B/E0-09842-54298745; Fri, 28 Nov 2014 15:18:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417187909!12103487!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31397 invoked from network); 28 Nov 2014 15:18:29 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 15:18:29 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 28 Nov 2014 15:18:29 +0000
Message-Id: <5478A056020000780004B7CE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 28 Nov 2014 15:18:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
In-Reply-To: <54787ED8.2010508@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.11.14 at 14:55, <andrew.cooper3@citrix.com> wrote:
> The problem is with continuations which reuse the upper bits of the
> input register, not with this HVMOP_op_mask specifically; the
> HVMOP_op_mask simply adds to an existing problem.  This is something
> which needs considering urgently because, as you identify above, we have
> already suffered an accidental ABI breakage with the mem-op widening.

Since we can't retroactively fix the mem-op widening, I still don't see
what's urgent here: As long as we don't change any of these masks,
nothing bad is going to happen. Of course one thing to consider with
this aspect in mind is whether to change the hvm-op or gnttab-op
masks again _before_ 4.5 goes out, based on whether we feel they're
wide enough for the (un)foreseeable future.

> 32bit HVM guests reliably form a continuation on every single iteration
> of a continuable hypercall (e.g. decrease reservation, which is the base
> of my XSA-111 PoC), making it trivial to construct a migrateable HVM
> domain which exposes the issue.

Hmm, I can't offhand see why that would be, but what you write
reads like you determined the reason? I ask because an unavoidable
use of continuations is certainly nice for making sure those code paths
get tested, but would be quite desirable to get eliminated at least for
non-debug builds.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:19:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:19:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNKN-0003sJ-Fy; Fri, 28 Nov 2014 15:19:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1XuNKM-0003s7-Is
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 15:19:22 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	6C/52-07724-97298745; Fri, 28 Nov 2014 15:19:21 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417187961!14522659!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21113 invoked from network); 28 Nov 2014 15:19:21 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-2.tower-31.messagelabs.com with SMTP;
	28 Nov 2014 15:19:21 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 7E376163FF9
	for <xen-devel@lists.xensource.com>;
	Fri, 28 Nov 2014 15:19:20 +0000 (GMT)
X-Virus-Scanned: amavisd-new at overnetdata.com
Received: from zimbra.overnetdata.com ([127.0.0.1])
	by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id AERBHCmlRnQt for <xen-devel@lists.xensource.com>;
	Fri, 28 Nov 2014 15:19:11 +0000 (GMT)
Received: from [10.0.2.15] (unknown [192.168.1.62])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id B3F74163F96
	for <xen-devel@lists.xensource.com>;
	Fri, 28 Nov 2014 15:19:11 +0000 (GMT)
Message-ID: <5478926A.80503@overnetdata.com>
Date: Fri, 28 Nov 2014 15:19:06 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] PV DomU running linux 3.17.3 causing xen-netback fatal
	error in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
3.17.3 running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.

Shortly after the upgrade we started to lose network connectivity to the
DomU a few times a day that required a reboot to fix. We see nothing in
the xen logs or xl dmesg, but when we looked at the dmesg output we saw
the following output for the two incidents we investigated in detail:

[69332.026586] vif vif-4-0 vif4.0: txreq.offset: 85e, size: 4002, end: 6144
[69332.026607] vif vif-4-0 vif4.0: fatal error; disabling device
[69332.031069] br-default: port 2(vif4.0) entered disabled state


[824365.530740] vif vif-9-0 vif9.0: txreq.offset: a5e, size: 4002, end: 6656
[824365.530748] vif vif-9-0 vif9.0: fatal error; disabling device
[824365.531191] br-default: port 2(vif9.0) entered disabled state

We have a very similar setup running on another machine with a 3.17.3
DomU, 3.17.3 Dom0 and Xen 4.4.0 but we can't reproduce the issue on this
machine. This is a test system rather than a production system so has a
different workload and fewer CPUs.

The piece of code that outputs the error is in
drivers/net/xen-netback/netback.c.

The DomU has 4000MB of RAM and 8 CPUs.

Any ideas?

Thanks,

Anthony.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:19:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:19:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNKN-0003sJ-Fy; Fri, 28 Nov 2014 15:19:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1XuNKM-0003s7-Is
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 15:19:22 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	6C/52-07724-97298745; Fri, 28 Nov 2014 15:19:21 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417187961!14522659!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21113 invoked from network); 28 Nov 2014 15:19:21 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-2.tower-31.messagelabs.com with SMTP;
	28 Nov 2014 15:19:21 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 7E376163FF9
	for <xen-devel@lists.xensource.com>;
	Fri, 28 Nov 2014 15:19:20 +0000 (GMT)
X-Virus-Scanned: amavisd-new at overnetdata.com
Received: from zimbra.overnetdata.com ([127.0.0.1])
	by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id AERBHCmlRnQt for <xen-devel@lists.xensource.com>;
	Fri, 28 Nov 2014 15:19:11 +0000 (GMT)
Received: from [10.0.2.15] (unknown [192.168.1.62])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id B3F74163F96
	for <xen-devel@lists.xensource.com>;
	Fri, 28 Nov 2014 15:19:11 +0000 (GMT)
Message-ID: <5478926A.80503@overnetdata.com>
Date: Fri, 28 Nov 2014 15:19:06 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] PV DomU running linux 3.17.3 causing xen-netback fatal
	error in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
3.17.3 running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.

Shortly after the upgrade we started to lose network connectivity to the
DomU a few times a day that required a reboot to fix. We see nothing in
the xen logs or xl dmesg, but when we looked at the dmesg output we saw
the following output for the two incidents we investigated in detail:

[69332.026586] vif vif-4-0 vif4.0: txreq.offset: 85e, size: 4002, end: 6144
[69332.026607] vif vif-4-0 vif4.0: fatal error; disabling device
[69332.031069] br-default: port 2(vif4.0) entered disabled state


[824365.530740] vif vif-9-0 vif9.0: txreq.offset: a5e, size: 4002, end: 6656
[824365.530748] vif vif-9-0 vif9.0: fatal error; disabling device
[824365.531191] br-default: port 2(vif9.0) entered disabled state

We have a very similar setup running on another machine with a 3.17.3
DomU, 3.17.3 Dom0 and Xen 4.4.0 but we can't reproduce the issue on this
machine. This is a test system rather than a production system so has a
different workload and fewer CPUs.

The piece of code that outputs the error is in
drivers/net/xen-netback/netback.c.

The DomU has 4000MB of RAM and 8 CPUs.

Any ideas?

Thanks,

Anthony.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:23:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNOF-0004GI-4g; Fri, 28 Nov 2014 15:23:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuNOD-0004GD-4j
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 15:23:21 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	EE/A8-07724-86398745; Fri, 28 Nov 2014 15:23:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417188198!14548005!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2876 invoked from network); 28 Nov 2014 15:23:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:23:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197478784"
Message-ID: <1417188196.23604.60.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony Wright <anthony@overnetdata.com>
Date: Fri, 28 Nov 2014 15:23:16 +0000
In-Reply-To: <5478926A.80503@overnetdata.com>
References: <5478926A.80503@overnetdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PV DomU running linux 3.17.3 causing xen-netback
 fatal error in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 15:19 +0000, Anthony Wright wrote:
> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
> 3.17.3

Is this a Debian kernel? In which case you might be seeing
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767261 , this will be
fixed in the next upload of the kernel, test binaries with the fixes are
referenced in the bug log.

Even if not Debian then you'll probably want the same set of backports.

Ian.

>  running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.
> 
> Shortly after the upgrade we started to lose network connectivity to the
> DomU a few times a day that required a reboot to fix. We see nothing in
> the xen logs or xl dmesg, but when we looked at the dmesg output we saw
> the following output for the two incidents we investigated in detail:
> 
> [69332.026586] vif vif-4-0 vif4.0: txreq.offset: 85e, size: 4002, end: 6144
> [69332.026607] vif vif-4-0 vif4.0: fatal error; disabling device
> [69332.031069] br-default: port 2(vif4.0) entered disabled state
> 
> 
> [824365.530740] vif vif-9-0 vif9.0: txreq.offset: a5e, size: 4002, end: 6656
> [824365.530748] vif vif-9-0 vif9.0: fatal error; disabling device
> [824365.531191] br-default: port 2(vif9.0) entered disabled state
> 
> We have a very similar setup running on another machine with a 3.17.3
> DomU, 3.17.3 Dom0 and Xen 4.4.0 but we can't reproduce the issue on this
> machine. This is a test system rather than a production system so has a
> different workload and fewer CPUs.
> 
> The piece of code that outputs the error is in
> drivers/net/xen-netback/netback.c.
> 
> The DomU has 4000MB of RAM and 8 CPUs.
> 
> Any ideas?
> 
> Thanks,
> 
> Anthony.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 28 15:23:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNOJ-0004Gn-H2; Fri, 28 Nov 2014 15:23:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XuNOI-0004GY-P5
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 15:23:26 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C8/05-25276-E6398745; Fri, 28 Nov 2014 15:23:26 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417188205!12143189!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20476 invoked from network); 28 Nov 2014 15:23:25 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:23:25 -0000
Received: by mail-wi0-f182.google.com with SMTP id h11so11552723wiw.3
	for <xen-devel@lists.xenproject.org>;
	Fri, 28 Nov 2014 07:23:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=6xjSFTsTT2MUofOS+5Ers3T9VOANjeTl1lUa6WwxV5M=;
	b=a/P6JDW5Yu9IATPkgYo6BrkFRfAaWCyj8wW9jvPOX0dO9wxfiGFDVT3co0MtkjPqaz
	s0f5T6zmMIB7ETMiHhDPcVsUvPPG9oVYbuyaIQIR2tNxq2n9kuHldBvdZfoGmuEqQuXm
	3/q37taEKK8ceNFIDDfo7skp6JMF7HSkhh0G18XjdMsHmjlav1Y6c9yZdtEorSuaGa1O
	sVacl+uABqSZgFRTK7DfNalMP1Q0eoRYQiiCrk7CCHmL3uCV1qTSikt2iS0d1jOiX76v
	HJgXKFEH55nGwgks0L5Jdg5E+4isUeXd/8nMCGTwm1SCH6RkeKuBZzImc/09B4TimGKI
	vYjw==
X-Gm-Message-State: ALoCoQmghMh3yf1gHAORZI+7s2RgQMIay3nlDJD2VSrVXGAHWH62aVHpel5SK5cun7QcMI0wDAjM
X-Received: by 10.194.87.34 with SMTP id u2mr70256228wjz.42.1417188205379;
	Fri, 28 Nov 2014 07:23:25 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	fo12sm29942597wic.19.2014.11.28.07.23.23 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 28 Nov 2014 07:23:24 -0800 (PST)
Message-ID: <54789369.4020405@linaro.org>
Date: Fri, 28 Nov 2014 15:23:21 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xenproject.org
References: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] xen/arm: Handle platforms with
 edge-triggered virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I forgot to add "for 4.5" in the commit title.

On 28/11/14 15:17, Julien Grall wrote:
 > This patch is a bug fix candidate for Xen 4.5 and backport for Xen 4.4.
> It affects at least Xgene platform and ARMv8 models where Xen may
> randomly crash.

Thinking a bit more to this. I believe it's possible for a guest to
crash the host if the next timer deadline is short enough and it execute
a yield. Might be unlikely ...

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:23:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNOF-0004GI-4g; Fri, 28 Nov 2014 15:23:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuNOD-0004GD-4j
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 15:23:21 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	EE/A8-07724-86398745; Fri, 28 Nov 2014 15:23:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417188198!14548005!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2876 invoked from network); 28 Nov 2014 15:23:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:23:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197478784"
Message-ID: <1417188196.23604.60.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony Wright <anthony@overnetdata.com>
Date: Fri, 28 Nov 2014 15:23:16 +0000
In-Reply-To: <5478926A.80503@overnetdata.com>
References: <5478926A.80503@overnetdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PV DomU running linux 3.17.3 causing xen-netback
 fatal error in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-11-28 at 15:19 +0000, Anthony Wright wrote:
> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
> 3.17.3

Is this a Debian kernel? In which case you might be seeing
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767261 , this will be
fixed in the next upload of the kernel, test binaries with the fixes are
referenced in the bug log.

Even if not Debian then you'll probably want the same set of backports.

Ian.

>  running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.
> 
> Shortly after the upgrade we started to lose network connectivity to the
> DomU a few times a day that required a reboot to fix. We see nothing in
> the xen logs or xl dmesg, but when we looked at the dmesg output we saw
> the following output for the two incidents we investigated in detail:
> 
> [69332.026586] vif vif-4-0 vif4.0: txreq.offset: 85e, size: 4002, end: 6144
> [69332.026607] vif vif-4-0 vif4.0: fatal error; disabling device
> [69332.031069] br-default: port 2(vif4.0) entered disabled state
> 
> 
> [824365.530740] vif vif-9-0 vif9.0: txreq.offset: a5e, size: 4002, end: 6656
> [824365.530748] vif vif-9-0 vif9.0: fatal error; disabling device
> [824365.531191] br-default: port 2(vif9.0) entered disabled state
> 
> We have a very similar setup running on another machine with a 3.17.3
> DomU, 3.17.3 Dom0 and Xen 4.4.0 but we can't reproduce the issue on this
> machine. This is a test system rather than a production system so has a
> different workload and fewer CPUs.
> 
> The piece of code that outputs the error is in
> drivers/net/xen-netback/netback.c.
> 
> The DomU has 4000MB of RAM and 8 CPUs.
> 
> Any ideas?
> 
> Thanks,
> 
> Anthony.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Nov 28 15:23:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNOJ-0004Gn-H2; Fri, 28 Nov 2014 15:23:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XuNOI-0004GY-P5
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 15:23:26 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C8/05-25276-E6398745; Fri, 28 Nov 2014 15:23:26 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417188205!12143189!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20476 invoked from network); 28 Nov 2014 15:23:25 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:23:25 -0000
Received: by mail-wi0-f182.google.com with SMTP id h11so11552723wiw.3
	for <xen-devel@lists.xenproject.org>;
	Fri, 28 Nov 2014 07:23:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=6xjSFTsTT2MUofOS+5Ers3T9VOANjeTl1lUa6WwxV5M=;
	b=a/P6JDW5Yu9IATPkgYo6BrkFRfAaWCyj8wW9jvPOX0dO9wxfiGFDVT3co0MtkjPqaz
	s0f5T6zmMIB7ETMiHhDPcVsUvPPG9oVYbuyaIQIR2tNxq2n9kuHldBvdZfoGmuEqQuXm
	3/q37taEKK8ceNFIDDfo7skp6JMF7HSkhh0G18XjdMsHmjlav1Y6c9yZdtEorSuaGa1O
	sVacl+uABqSZgFRTK7DfNalMP1Q0eoRYQiiCrk7CCHmL3uCV1qTSikt2iS0d1jOiX76v
	HJgXKFEH55nGwgks0L5Jdg5E+4isUeXd/8nMCGTwm1SCH6RkeKuBZzImc/09B4TimGKI
	vYjw==
X-Gm-Message-State: ALoCoQmghMh3yf1gHAORZI+7s2RgQMIay3nlDJD2VSrVXGAHWH62aVHpel5SK5cun7QcMI0wDAjM
X-Received: by 10.194.87.34 with SMTP id u2mr70256228wjz.42.1417188205379;
	Fri, 28 Nov 2014 07:23:25 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	fo12sm29942597wic.19.2014.11.28.07.23.23 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 28 Nov 2014 07:23:24 -0800 (PST)
Message-ID: <54789369.4020405@linaro.org>
Date: Fri, 28 Nov 2014 15:23:21 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: xen-devel@lists.xenproject.org
References: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] xen/arm: Handle platforms with
 edge-triggered virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I forgot to add "for 4.5" in the commit title.

On 28/11/14 15:17, Julien Grall wrote:
 > This patch is a bug fix candidate for Xen 4.5 and backport for Xen 4.4.
> It affects at least Xgene platform and ARMv8 models where Xen may
> randomly crash.

Thinking a bit more to this. I believe it's possible for a guest to
crash the host if the next timer deadline is short enough and it execute
a yield. Might be unlikely ...

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:44:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:44:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNiO-0004tw-EG; Fri, 28 Nov 2014 15:44:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuNiM-0004tr-I6
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 15:44:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	16/C2-25276-94898745; Fri, 28 Nov 2014 15:44:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417189448!8703975!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22267 invoked from network); 28 Nov 2014 15:44:09 -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;
	28 Nov 2014 15:44:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197483399"
Message-ID: <1417189409.23604.62.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 28 Nov 2014 15:43:29 +0000
In-Reply-To: <5474B784020000660007D9AA@soto.provo.novell.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
	<5462343C020000660007880A@soto.provo.novell.com>
	<546490D40200006600079701@soto.provo.novell.com>
	<1415878862.21321.9.camel@citrix.com>
	<5474B784020000660007D9AA@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, George Dunlap <dunlapg@umich.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 02:08 -0700, Chun Yan Liu wrote:
> Hi, Ian,
> 
> According to previous discussion, snapshot delete and revert are
> inclined to be done by high level application itself, won't supply a
> libxl API.

I thought you had explained a scenario where the toolstack needed to be
at least aware of delete, specifically when you are deleting a snapshot
from the middle of an active chain. 

Maybe that's not "snapshot delete API in libxl" though, but rather a
notification API which the toolstack can use to tell libxl something is
going on.

>  I'm wondering snapshot create need a new common API?
> In fact its main work is save domain and take disk snapshot, xl can
> do it too. 

I don't believe xl can take a disk snapshot of an active disk, it
doesn't have the machinery to deal with that sort of thing, nor should
it, this is exactly the sort of thing which libxl is provided to deal
with.

Also, libxl is driving the migration/memory snapshot, and I think the
disk snapshot fundamentally needs to be involved in that process, not
done separately by the toolstack.

> I just write down an overview of the snapshot work (see below).
> The problem is: do we need to export API? What kind of API?
> In updating Bamvor's code, I think xl can do all the work, libvirt can
> do the work too even without libxl's help.
> 
> Of course, there are some thing if put in libxl, it will be easier to
> use, like the domain snapshot info structure, gentype.py will
> directly generate useful init/dispose/to_json/from_json functions.
> Or the disk snapshot part can be extracted and placed in libxl or libxlu.
> 
> Any suggestions about which part is better to be extracted as libxl
> API or better not?
> 
> Thanks,
> Chunyan
> 
> ------------------------------------------------------------------------------------------------------
> libxl domain snapshot overview

Just to be 100% clear: This is an overview of a domain snapshot
architecture for a toolstack which uses libxl. A bunch of the things
described here belong to the toolstack and not to libxl itself.

I've tried to read with that in mind but a complete document should
mention this and be careful to be clear about the distinction where it
matters.

> 0. Glossary
[...]
> * not support disk-only snapshot [1].
>                                        
> [1]
>  This is different from "libvirt".
>  To xl, it only concerns active domains, and even when domain
>  is paused, there is no data flush to disk operation. So, take
>  a disk-only snapshot and then resume, it is as if the guest
>  had crashed. For this reason, disk-only snapshot is meaningless
>  to xl. Should not support.
> 
>  To libvirt, it has active domains and inactive domains, for
>  the active domains, as "xl", it's meaning less to take disk-only
>  snapshot, but for inactive domains, disk-only snapshot is valid.
>  Should support.

Do you mean to say here that disk-only snapshots are not supported in
some toolstacks, or in no toolstack? Or are you just saying that libxl
doesn't need to support them because they only apply to inactive
domains?

In either case it seems to me like your footnote is saying that you *do*
want to support disk-only snapshots, at least in some stacks and/or
configurations.

I think you probably mean to say that disk-only snapshots of *active*
domains are not supported. Whereas disk-only snapshots of inactive
domains may or may not be depending on the toolstack.

> 
> 2. Requirements
> 
> General Requirements:
> * ability to save/restore domain memory
> * ability to create/delete/apply disk snapshot [2]
> * ability to parse user config file
> * ability to save/load/update domain snapshot metadata (or called
>   domain snapshot info, the metadata at least includes:
>   snapshot name, create time, description, memory state file,
>   disk snapshot info, parent (in snapshot chain), current (is
>   currently applied))
> 
> [2] Disk snapshot requirements:
> * external tools: qemu-img, lvcreate, vhd-util, etc.
> * For a basic goal, we support 'raw' and 'qcow2' backend types only.
>   Then only requires qemu:
>     use libxl qmp command (better) or "qemu-img"

You should leave these implementation details for a later section, in
this context they just invite quibbling about whether things belong in
libxl etc and whether qmp commands are "better".

The rest looks ok, but without the remainder of the design described in
terms of the concepts given here it's hard to comment further.

I'd suggest putting this all into one coherent document (not 3 as
before) which starts by describing the terminology (section 0 in your
mail which I'm replying to now), then gives an overview of the
architecture (the rest of that mail), then describe which components
(libxl, toolstack, etc) implement each bit of the architecture, then
describe the libxl API which makes this possible (covered in previous
mails I think).

I think you have most of the words either here or from the other mails,
they just need putting together into a single thing and going through to
make sure that they use the same terminology and describe the same
things etc.

Please take a look at
http://xenbits.xen.org/people/dvrabel/event-channels-H.pdf or
http://lists.xen.org/archives/html/xen-devel/2014-10/msg03235.html for
examples of the sort of cohesive document I mean.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:44:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:44:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNiO-0004tw-EG; Fri, 28 Nov 2014 15:44:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XuNiM-0004tr-I6
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 15:44:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	16/C2-25276-94898745; Fri, 28 Nov 2014 15:44:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417189448!8703975!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22267 invoked from network); 28 Nov 2014 15:44:09 -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;
	28 Nov 2014 15:44:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197483399"
Message-ID: <1417189409.23604.62.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 28 Nov 2014 15:43:29 +0000
In-Reply-To: <5474B784020000660007D9AA@soto.provo.novell.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<CAFLBxZZVqZxUouciujSTP-GJsUOquofUK6dy1K2rNXuEEb4Ekw@mail.gmail.com>
	<5462343C020000660007880A@soto.provo.novell.com>
	<546490D40200006600079701@soto.provo.novell.com>
	<1415878862.21321.9.camel@citrix.com>
	<5474B784020000660007D9AA@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@citrix.com>, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, George Dunlap <dunlapg@umich.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-11-25 at 02:08 -0700, Chun Yan Liu wrote:
> Hi, Ian,
> 
> According to previous discussion, snapshot delete and revert are
> inclined to be done by high level application itself, won't supply a
> libxl API.

I thought you had explained a scenario where the toolstack needed to be
at least aware of delete, specifically when you are deleting a snapshot
from the middle of an active chain. 

Maybe that's not "snapshot delete API in libxl" though, but rather a
notification API which the toolstack can use to tell libxl something is
going on.

>  I'm wondering snapshot create need a new common API?
> In fact its main work is save domain and take disk snapshot, xl can
> do it too. 

I don't believe xl can take a disk snapshot of an active disk, it
doesn't have the machinery to deal with that sort of thing, nor should
it, this is exactly the sort of thing which libxl is provided to deal
with.

Also, libxl is driving the migration/memory snapshot, and I think the
disk snapshot fundamentally needs to be involved in that process, not
done separately by the toolstack.

> I just write down an overview of the snapshot work (see below).
> The problem is: do we need to export API? What kind of API?
> In updating Bamvor's code, I think xl can do all the work, libvirt can
> do the work too even without libxl's help.
> 
> Of course, there are some thing if put in libxl, it will be easier to
> use, like the domain snapshot info structure, gentype.py will
> directly generate useful init/dispose/to_json/from_json functions.
> Or the disk snapshot part can be extracted and placed in libxl or libxlu.
> 
> Any suggestions about which part is better to be extracted as libxl
> API or better not?
> 
> Thanks,
> Chunyan
> 
> ------------------------------------------------------------------------------------------------------
> libxl domain snapshot overview

Just to be 100% clear: This is an overview of a domain snapshot
architecture for a toolstack which uses libxl. A bunch of the things
described here belong to the toolstack and not to libxl itself.

I've tried to read with that in mind but a complete document should
mention this and be careful to be clear about the distinction where it
matters.

> 0. Glossary
[...]
> * not support disk-only snapshot [1].
>                                        
> [1]
>  This is different from "libvirt".
>  To xl, it only concerns active domains, and even when domain
>  is paused, there is no data flush to disk operation. So, take
>  a disk-only snapshot and then resume, it is as if the guest
>  had crashed. For this reason, disk-only snapshot is meaningless
>  to xl. Should not support.
> 
>  To libvirt, it has active domains and inactive domains, for
>  the active domains, as "xl", it's meaning less to take disk-only
>  snapshot, but for inactive domains, disk-only snapshot is valid.
>  Should support.

Do you mean to say here that disk-only snapshots are not supported in
some toolstacks, or in no toolstack? Or are you just saying that libxl
doesn't need to support them because they only apply to inactive
domains?

In either case it seems to me like your footnote is saying that you *do*
want to support disk-only snapshots, at least in some stacks and/or
configurations.

I think you probably mean to say that disk-only snapshots of *active*
domains are not supported. Whereas disk-only snapshots of inactive
domains may or may not be depending on the toolstack.

> 
> 2. Requirements
> 
> General Requirements:
> * ability to save/restore domain memory
> * ability to create/delete/apply disk snapshot [2]
> * ability to parse user config file
> * ability to save/load/update domain snapshot metadata (or called
>   domain snapshot info, the metadata at least includes:
>   snapshot name, create time, description, memory state file,
>   disk snapshot info, parent (in snapshot chain), current (is
>   currently applied))
> 
> [2] Disk snapshot requirements:
> * external tools: qemu-img, lvcreate, vhd-util, etc.
> * For a basic goal, we support 'raw' and 'qcow2' backend types only.
>   Then only requires qemu:
>     use libxl qmp command (better) or "qemu-img"

You should leave these implementation details for a later section, in
this context they just invite quibbling about whether things belong in
libxl etc and whether qmp commands are "better".

The rest looks ok, but without the remainder of the design described in
terms of the concepts given here it's hard to comment further.

I'd suggest putting this all into one coherent document (not 3 as
before) which starts by describing the terminology (section 0 in your
mail which I'm replying to now), then gives an overview of the
architecture (the rest of that mail), then describe which components
(libxl, toolstack, etc) implement each bit of the architecture, then
describe the libxl API which makes this possible (covered in previous
mails I think).

I think you have most of the words either here or from the other mails,
they just need putting together into a single thing and going through to
make sure that they use the same terminology and describe the same
things etc.

Please take a look at
http://xenbits.xen.org/people/dvrabel/event-channels-H.pdf or
http://lists.xen.org/archives/html/xen-devel/2014-10/msg03235.html for
examples of the sort of cohesive document I mean.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:46:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15: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 1XuNkz-0004zZ-W4; Fri, 28 Nov 2014 15:46:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XuNkx-0004zU-Vz
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 15:46:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5A/86-25276-BE898745; Fri, 28 Nov 2014 15:46:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417189609!12166515!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22631 invoked from network); 28 Nov 2014 15:46:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:46:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197484056"
Message-ID: <547898E7.30400@citrix.com>
Date: Fri, 28 Nov 2014 15:46:47 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54785E46.4080107@citrix.com>	<5478819F020000780004B70D@mail.emea.novell.com>	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
In-Reply-To: <5478A056020000780004B7CE@mail.emea.novell.com>
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/11/14 15:18, Jan Beulich wrote:
>>>> On 28.11.14 at 14:55, <andrew.cooper3@citrix.com> wrote:
>> The problem is with continuations which reuse the upper bits of the
>> input register, not with this HVMOP_op_mask specifically; the
>> HVMOP_op_mask simply adds to an existing problem.  This is something
>> which needs considering urgently because, as you identify above, we have
>> already suffered an accidental ABI breakage with the mem-op widening.
> Since we can't retroactively fix the mem-op widening, I still don't see
> what's urgent here: As long as we don't change any of these masks,
> nothing bad is going to happen. Of course one thing to consider with
> this aspect in mind is whether to change the hvm-op or gnttab-op
> masks again _before_ 4.5 goes out, based on whether we feel they're
> wide enough for the (un)foreseeable future.

By urgent, I mean exactly this, while we have the ability to tweak the
masks.

>
>> 32bit HVM guests reliably form a continuation on every single iteration
>> of a continuable hypercall (e.g. decrease reservation, which is the base
>> of my XSA-111 PoC), making it trivial to construct a migrateable HVM
>> domain which exposes the issue.
> Hmm, I can't offhand see why that would be, but what you write
> reads like you determined the reason?

I have never identified why, but it is reliable.  c/s 79de2d31f1 proves
that some preemption condition is true for 32bit HVM guests by the time
the hypercall handler is called.  It is unreliable with 64bit HVM
guests, suggesting that the compat translation layer may be the root
cause of the issue.

> I ask because an unavoidable
> use of continuations is certainly nice for making sure those code paths
> get tested, but would be quite desirable to get eliminated at least for
> non-debug builds.

While the preemption code is necessary to avoid spending ludicrous
quantities of time synchronously in Xen, it is currently having the
worst possible effect it could have on the system, by causing 32bit HVM
guests to undergo a vmentry/vmexit and double compat translation for
each iteration.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:46:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15: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 1XuNkz-0004zZ-W4; Fri, 28 Nov 2014 15:46:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XuNkx-0004zU-Vz
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 15:46:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5A/86-25276-BE898745; Fri, 28 Nov 2014 15:46:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417189609!12166515!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22631 invoked from network); 28 Nov 2014 15:46:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 15:46:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197484056"
Message-ID: <547898E7.30400@citrix.com>
Date: Fri, 28 Nov 2014 15:46:47 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54785E46.4080107@citrix.com>	<5478819F020000780004B70D@mail.emea.novell.com>	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
In-Reply-To: <5478A056020000780004B7CE@mail.emea.novell.com>
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.5 HVMOP ABI issues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/11/14 15:18, Jan Beulich wrote:
>>>> On 28.11.14 at 14:55, <andrew.cooper3@citrix.com> wrote:
>> The problem is with continuations which reuse the upper bits of the
>> input register, not with this HVMOP_op_mask specifically; the
>> HVMOP_op_mask simply adds to an existing problem.  This is something
>> which needs considering urgently because, as you identify above, we have
>> already suffered an accidental ABI breakage with the mem-op widening.
> Since we can't retroactively fix the mem-op widening, I still don't see
> what's urgent here: As long as we don't change any of these masks,
> nothing bad is going to happen. Of course one thing to consider with
> this aspect in mind is whether to change the hvm-op or gnttab-op
> masks again _before_ 4.5 goes out, based on whether we feel they're
> wide enough for the (un)foreseeable future.

By urgent, I mean exactly this, while we have the ability to tweak the
masks.

>
>> 32bit HVM guests reliably form a continuation on every single iteration
>> of a continuable hypercall (e.g. decrease reservation, which is the base
>> of my XSA-111 PoC), making it trivial to construct a migrateable HVM
>> domain which exposes the issue.
> Hmm, I can't offhand see why that would be, but what you write
> reads like you determined the reason?

I have never identified why, but it is reliable.  c/s 79de2d31f1 proves
that some preemption condition is true for 32bit HVM guests by the time
the hypercall handler is called.  It is unreliable with 64bit HVM
guests, suggesting that the compat translation layer may be the root
cause of the issue.

> I ask because an unavoidable
> use of continuations is certainly nice for making sure those code paths
> get tested, but would be quite desirable to get eliminated at least for
> non-debug builds.

While the preemption code is necessary to avoid spending ludicrous
quantities of time synchronously in Xen, it is currently having the
worst possible effect it could have on the system, by causing 32bit HVM
guests to undergo a vmentry/vmexit and double compat translation for
each iteration.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:47:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNm0-00054n-Dk; Fri, 28 Nov 2014 15:47:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XuNly-00054d-65
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 15:47:54 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EB/E7-25276-92998745; Fri, 28 Nov 2014 15:47:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417189672!12148724!1
X-Originating-IP: [81.169.146.178]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE3OCA9PiAzNTU5NA==\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE3OCA9PiAzNTU5NA==\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19030 invoked from network); 28 Nov 2014 15:47:53 -0000
Received: from mo4-p04-ob.smtp.rzone.de (HELO mo4-p04-ob.smtp.rzone.de)
	(81.169.146.178)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 15:47:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417189672; l=609;
	s=domk; d=aepfle.de;
	h=Content-Disposition:Content-Type:MIME-Version:Subject:To:From:Date;
	bh=wq/pTshITtIOmudUEVqO5mSoDOw=;
	b=ca+hV+71PEERXPFt6F4ayskbZCp/ronz/9yWWoc9bjO1REkTfrE9GUKQNUdA2sJSKgP
	lLM40tR5Ryy2lF1ZjwGimaRXA2PlfkWyJ6KCx+p72d6sOxdUhhUBuojeTQ62rw358fPRA
	InnsNotLfIl8TF5RmxbrwDfC3EXnUk0gpqU=
X-RZG-CLASS-ID: mo04
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ6Kk/f+6nd1zmz6skk
Received: from probook.fritz.box ([82.113.98.204])
	by smtp.strato.de (RZmta 36.2 SBL|AUTH)
	with ESMTPSA id Y01370qASFlo2JO
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 28 Nov 2014 16:47:50 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 94D7F50153; Fri, 28 Nov 2014 16:47:49 +0100 (CET)
Date: Fri, 28 Nov 2014 16:47:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: qemu-devel@nongnu.org, xen-devel@lists.xen.org
Message-ID: <20141128154749.GA6749@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Subject: [Xen-devel] get a handle for the tap device to shut it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Xen does a shutdown of the emulated PCI network device in
pci_unplug_nics. But this just disables the PCI device. The tap device
for a given emulated card remains active because nothing closes the
file descriptor. 

The cmdline for qemu contains something like "-device
rtl8139,id=nic0,netdev=net0,mac=00:16:3e:28:f1:ee -netdev
type=tap,id=net0,ifname=vif1.0-emu,script=no,downscript=no".

I wonder if the missing disable of the tap device is intentional, or
just an oversight, or if its just to complicated to get from a
"PCIDevice *" to the other end and call the ->cleanup function.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 15:47:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 15:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuNm0-00054n-Dk; Fri, 28 Nov 2014 15:47:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XuNly-00054d-65
	for xen-devel@lists.xen.org; Fri, 28 Nov 2014 15:47:54 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EB/E7-25276-92998745; Fri, 28 Nov 2014 15:47:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417189672!12148724!1
X-Originating-IP: [81.169.146.178]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE3OCA9PiAzNTU5NA==\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE3OCA9PiAzNTU5NA==\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19030 invoked from network); 28 Nov 2014 15:47:53 -0000
Received: from mo4-p04-ob.smtp.rzone.de (HELO mo4-p04-ob.smtp.rzone.de)
	(81.169.146.178)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 15:47:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417189672; l=609;
	s=domk; d=aepfle.de;
	h=Content-Disposition:Content-Type:MIME-Version:Subject:To:From:Date;
	bh=wq/pTshITtIOmudUEVqO5mSoDOw=;
	b=ca+hV+71PEERXPFt6F4ayskbZCp/ronz/9yWWoc9bjO1REkTfrE9GUKQNUdA2sJSKgP
	lLM40tR5Ryy2lF1ZjwGimaRXA2PlfkWyJ6KCx+p72d6sOxdUhhUBuojeTQ62rw358fPRA
	InnsNotLfIl8TF5RmxbrwDfC3EXnUk0gpqU=
X-RZG-CLASS-ID: mo04
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ6Kk/f+6nd1zmz6skk
Received: from probook.fritz.box ([82.113.98.204])
	by smtp.strato.de (RZmta 36.2 SBL|AUTH)
	with ESMTPSA id Y01370qASFlo2JO
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 28 Nov 2014 16:47:50 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 94D7F50153; Fri, 28 Nov 2014 16:47:49 +0100 (CET)
Date: Fri, 28 Nov 2014 16:47:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: qemu-devel@nongnu.org, xen-devel@lists.xen.org
Message-ID: <20141128154749.GA6749@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Subject: [Xen-devel] get a handle for the tap device to shut it down
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Xen does a shutdown of the emulated PCI network device in
pci_unplug_nics. But this just disables the PCI device. The tap device
for a given emulated card remains active because nothing closes the
file descriptor. 

The cmdline for qemu contains something like "-device
rtl8139,id=nic0,netdev=net0,mac=00:16:3e:28:f1:ee -netdev
type=tap,id=net0,ifname=vif1.0-emu,script=no,downscript=no".

I wonder if the missing disable of the tap device is intentional, or
just an oversight, or if its just to complicated to get from a
"PCIDevice *" to the other end and call the ->cleanup function.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 16:35:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 16:35:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuOVP-0006sn-AV; Fri, 28 Nov 2014 16:34:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1XuOVO-0006si-I7
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 16:34:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/81-15461-924A8745; Fri, 28 Nov 2014 16:34:49 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417192489!12158743!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23767 invoked from network); 28 Nov 2014 16:34:49 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-10.tower-21.messagelabs.com with SMTP;
	28 Nov 2014 16:34:49 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id A19CD164D2D;
	Fri, 28 Nov 2014 16:34:48 +0000 (GMT)
X-Virus-Scanned: amavisd-new at overnetdata.com
Received: from zimbra.overnetdata.com ([127.0.0.1])
	by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id ZFoN5iMacZUe; Fri, 28 Nov 2014 16:34:40 +0000 (GMT)
Received: from [10.0.2.15] (unknown [192.168.1.62])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 595B4164D28;
	Fri, 28 Nov 2014 16:34:40 +0000 (GMT)
Message-ID: <5478A41F.2030905@overnetdata.com>
Date: Fri, 28 Nov 2014 16:34:39 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5478926A.80503@overnetdata.com>
	<1417188196.23604.60.camel@citrix.com>
In-Reply-To: <1417188196.23604.60.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PV DomU running linux 3.17.3 causing xen-netback
 fatal error in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/11/2014 15:23, Ian Campbell wrote:
> On Fri, 2014-11-28 at 15:19 +0000, Anthony Wright wrote:
>> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
>> 3.17.3
> Is this a Debian kernel? In which case you might be seeing
It's a stock kernel from kernel.org, we have a custom system with no
relation to Debian.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767261 , this will be
> fixed in the next upload of the kernel, test binaries with the fixes are
> referenced in the bug log.
The error messages we're seeing are different from those reported, both
the Dom0 and DomU continue to run correctly and the vif doesn't degrade
slowly it fails the test in netback.c below which disables the interface:

    /* No crossing a page as the payload mustn't fragment. */
    if (unlikely((txreq.offset + txreq.size) > PAGE_SIZE)) {
        netdev_err(queue->vif->dev,
            "txreq.offset: %x, size: %u, end: %lu\n",
            txreq.offset, txreq.size,
            (txreq.offset&~PAGE_MASK) + txreq.size);
        xenvif_fatal_tx_err(queue->vif);
        break;
    }
> Even if not Debian then you'll probably want the same set of backports.
I'm happy to apply the backports if you think it's likely to fix the
problem despite the different symptoms, but from what I can see it looks
like a different problem.

thanks,

Anthony
> Ian.
>>  running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.
>>
>> Shortly after the upgrade we started to lose network connectivity to the
>> DomU a few times a day that required a reboot to fix. We see nothing in
>> the xen logs or xl dmesg, but when we looked at the dmesg output we saw
>> the following output for the two incidents we investigated in detail:
>>
>> [69332.026586] vif vif-4-0 vif4.0: txreq.offset: 85e, size: 4002, end: 6144
>> [69332.026607] vif vif-4-0 vif4.0: fatal error; disabling device
>> [69332.031069] br-default: port 2(vif4.0) entered disabled state
>>
>>
>> [824365.530740] vif vif-9-0 vif9.0: txreq.offset: a5e, size: 4002, end: 6656
>> [824365.530748] vif vif-9-0 vif9.0: fatal error; disabling device
>> [824365.531191] br-default: port 2(vif9.0) entered disabled state
>>
>> We have a very similar setup running on another machine with a 3.17.3
>> DomU, 3.17.3 Dom0 and Xen 4.4.0 but we can't reproduce the issue on this
>> machine. This is a test system rather than a production system so has a
>> different workload and fewer CPUs.
>>
>> The piece of code that outputs the error is in
>> drivers/net/xen-netback/netback.c.
>>
>> The DomU has 4000MB of RAM and 8 CPUs.
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Anthony.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Nov 28 16:35:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 16:35:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuOVP-0006sn-AV; Fri, 28 Nov 2014 16:34:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1XuOVO-0006si-I7
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 16:34:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E3/81-15461-924A8745; Fri, 28 Nov 2014 16:34:49 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417192489!12158743!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23767 invoked from network); 28 Nov 2014 16:34:49 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-10.tower-21.messagelabs.com with SMTP;
	28 Nov 2014 16:34:49 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id A19CD164D2D;
	Fri, 28 Nov 2014 16:34:48 +0000 (GMT)
X-Virus-Scanned: amavisd-new at overnetdata.com
Received: from zimbra.overnetdata.com ([127.0.0.1])
	by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id ZFoN5iMacZUe; Fri, 28 Nov 2014 16:34:40 +0000 (GMT)
Received: from [10.0.2.15] (unknown [192.168.1.62])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 595B4164D28;
	Fri, 28 Nov 2014 16:34:40 +0000 (GMT)
Message-ID: <5478A41F.2030905@overnetdata.com>
Date: Fri, 28 Nov 2014 16:34:39 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5478926A.80503@overnetdata.com>
	<1417188196.23604.60.camel@citrix.com>
In-Reply-To: <1417188196.23604.60.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PV DomU running linux 3.17.3 causing xen-netback
 fatal error in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/11/2014 15:23, Ian Campbell wrote:
> On Fri, 2014-11-28 at 15:19 +0000, Anthony Wright wrote:
>> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
>> 3.17.3
> Is this a Debian kernel? In which case you might be seeing
It's a stock kernel from kernel.org, we have a custom system with no
relation to Debian.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767261 , this will be
> fixed in the next upload of the kernel, test binaries with the fixes are
> referenced in the bug log.
The error messages we're seeing are different from those reported, both
the Dom0 and DomU continue to run correctly and the vif doesn't degrade
slowly it fails the test in netback.c below which disables the interface:

    /* No crossing a page as the payload mustn't fragment. */
    if (unlikely((txreq.offset + txreq.size) > PAGE_SIZE)) {
        netdev_err(queue->vif->dev,
            "txreq.offset: %x, size: %u, end: %lu\n",
            txreq.offset, txreq.size,
            (txreq.offset&~PAGE_MASK) + txreq.size);
        xenvif_fatal_tx_err(queue->vif);
        break;
    }
> Even if not Debian then you'll probably want the same set of backports.
I'm happy to apply the backports if you think it's likely to fix the
problem despite the different symptoms, but from what I can see it looks
like a different problem.

thanks,

Anthony
> Ian.
>>  running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.
>>
>> Shortly after the upgrade we started to lose network connectivity to the
>> DomU a few times a day that required a reboot to fix. We see nothing in
>> the xen logs or xl dmesg, but when we looked at the dmesg output we saw
>> the following output for the two incidents we investigated in detail:
>>
>> [69332.026586] vif vif-4-0 vif4.0: txreq.offset: 85e, size: 4002, end: 6144
>> [69332.026607] vif vif-4-0 vif4.0: fatal error; disabling device
>> [69332.031069] br-default: port 2(vif4.0) entered disabled state
>>
>>
>> [824365.530740] vif vif-9-0 vif9.0: txreq.offset: a5e, size: 4002, end: 6656
>> [824365.530748] vif vif-9-0 vif9.0: fatal error; disabling device
>> [824365.531191] br-default: port 2(vif9.0) entered disabled state
>>
>> We have a very similar setup running on another machine with a 3.17.3
>> DomU, 3.17.3 Dom0 and Xen 4.4.0 but we can't reproduce the issue on this
>> machine. This is a test system rather than a production system so has a
>> different workload and fewer CPUs.
>>
>> The piece of code that outputs the error is in
>> drivers/net/xen-netback/netback.c.
>>
>> The DomU has 4000MB of RAM and 8 CPUs.
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Anthony.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Nov 28 16:49:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 16:49:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuOjl-0007KY-9T; Fri, 28 Nov 2014 16:49:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XuOjj-0007KK-FM
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 16:49:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	72/F3-15461-2A7A8745; Fri, 28 Nov 2014 16:49:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417193377!12122679!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10168 invoked from network); 28 Nov 2014 16:49:38 -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;
	28 Nov 2014 16:49:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197498258"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 11:49:36 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XuOjf-0000qv-PC;
	Fri, 28 Nov 2014 16:49:35 +0000
Date: Fri, 28 Nov 2014 16:49:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141128164935.GA17910@zion.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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 Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
> create ^
> title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
> thanks
> 
> On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> > Hi,
> > 
> > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> > xl didn't show any problems on the commandline so i never drawed much attention 
> > to it, but /var/log/xen/xl-guest.log shows:
> > 
> >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
> >     Domain 19 has shut down, reason code 0 0x0
> >     Action for shutdown reason code 0 is destroy
> >     Domain 19 needs to be cleaned up: destroying the domain
> >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
> >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
> >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
> >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
> >     Done. Exiting now
> > 
> > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> > 
> > --

It's worth checking whether the device model exits too early, i.e., did
it crash? What's in the DM log?

Wei.

> > Sander
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 16:49:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 16:49:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuOjl-0007KY-9T; Fri, 28 Nov 2014 16:49:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XuOjj-0007KK-FM
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 16:49:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	72/F3-15461-2A7A8745; Fri, 28 Nov 2014 16:49:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417193377!12122679!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10168 invoked from network); 28 Nov 2014 16:49:38 -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;
	28 Nov 2014 16:49:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197498258"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 11:49:36 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XuOjf-0000qv-PC;
	Fri, 28 Nov 2014 16:49:35 +0000
Date: Fri, 28 Nov 2014 16:49:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141128164935.GA17910@zion.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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 Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
> create ^
> title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
> thanks
> 
> On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> > Hi,
> > 
> > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> > xl didn't show any problems on the commandline so i never drawed much attention 
> > to it, but /var/log/xen/xl-guest.log shows:
> > 
> >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
> >     Domain 19 has shut down, reason code 0 0x0
> >     Action for shutdown reason code 0 is destroy
> >     Domain 19 needs to be cleaned up: destroying the domain
> >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
> >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
> >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
> >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
> >     Done. Exiting now
> > 
> > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> > 
> > --

It's worth checking whether the device model exits too early, i.e., did
it crash? What's in the DM log?

Wei.

> > Sander
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 16:53:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 16:53:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuOnq-0007aD-6d; Fri, 28 Nov 2014 16:53:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuOno-0007Zv-R7
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 16:53:52 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	41/28-02712-0A8A8745; Fri, 28 Nov 2014 16:53:52 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417193630!11813945!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16970 invoked from network); 28 Nov 2014 16:53:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 16:53:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197778368"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 11:53:16 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuOnE-0000yO-8D;
	Fri, 28 Nov 2014 16:53:16 +0000
Date: Fri, 28 Nov 2014 16:53:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH for-4.5] reset PCI devices on force removal even
 when QEMU returns error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On do_pci_remove when QEMU returns error, we just bail out early without
resetting the device. On domain shutdown we are racing with QEMU exiting
and most often QEMU closes the QMP connection before executing the
requested command.

In these cases if force=1, it makes sense to go ahead with rest of the
PCI device removal, that includes resetting the device and calling
xc_deassign_device. Otherwise we risk not resetting the device properly
on domain shutdown.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 316643c..0ac0b93 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1243,7 +1245,7 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
             rc = ERROR_INVAL;
             goto out_fail;
         }
-        if (rc) {
+        if (rc && !force) {
             rc = ERROR_FAIL;
             goto out_fail;
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 16:53:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 16:53:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuOnq-0007aD-6d; Fri, 28 Nov 2014 16:53:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuOno-0007Zv-R7
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 16:53:52 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	41/28-02712-0A8A8745; Fri, 28 Nov 2014 16:53:52 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417193630!11813945!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16970 invoked from network); 28 Nov 2014 16:53:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 16:53:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197778368"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 11:53:16 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuOnE-0000yO-8D;
	Fri, 28 Nov 2014 16:53:16 +0000
Date: Fri, 28 Nov 2014 16:53:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH for-4.5] reset PCI devices on force removal even
 when QEMU returns error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On do_pci_remove when QEMU returns error, we just bail out early without
resetting the device. On domain shutdown we are racing with QEMU exiting
and most often QEMU closes the QMP connection before executing the
requested command.

In these cases if force=1, it makes sense to go ahead with rest of the
PCI device removal, that includes resetting the device and calling
xc_deassign_device. Otherwise we risk not resetting the device properly
on domain shutdown.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 316643c..0ac0b93 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1243,7 +1245,7 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
             rc = ERROR_INVAL;
             goto out_fail;
         }
-        if (rc) {
+        if (rc && !force) {
             rc = ERROR_FAIL;
             goto out_fail;
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 16:54:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 16: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.xen.org>)
	id 1XuOoS-0007ev-Je; Fri, 28 Nov 2014 16:54:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuOoQ-0007ee-VH
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 16:54:31 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	6B/69-03145-6C8A8745; Fri, 28 Nov 2014 16:54:30 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417193668!6387798!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18689 invoked from network); 28 Nov 2014 16:54:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 16:54:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197778687"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 11:54:27 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuOoN-0000zK-0i;
	Fri, 28 Nov 2014 16:54:27 +0000
Date: Fri, 28 Nov 2014 16:54:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141128164935.GA17910@zion.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
	<20141128164935.GA17910@zion.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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 Fri, 28 Nov 2014, Wei Liu wrote:
> On Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
> > create ^
> > title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
> > thanks
> > 
> > On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> > > Hi,
> > > 
> > > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> > > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> > > xl didn't show any problems on the commandline so i never drawed much attention 
> > > to it, but /var/log/xen/xl-guest.log shows:
> > > 
> > >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
> > >     Domain 19 has shut down, reason code 0 0x0
> > >     Action for shutdown reason code 0 is destroy
> > >     Domain 19 needs to be cleaned up: destroying the domain
> > >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
> > >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
> > >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
> > >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
> > >     Done. Exiting now
> > > 
> > > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> > > 
> > > --
> 
> It's worth checking whether the device model exits too early, i.e., did
> it crash? What's in the DM log?

Firstly I was thinking that if force=1 it makes sense to continue even
when QEMU returns error, see:

http://marc.info/?i=alpine.DEB.2.02.1411281648500.14135%40kaball.uk.xensource.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 16:54:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 16: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.xen.org>)
	id 1XuOoS-0007ev-Je; Fri, 28 Nov 2014 16:54:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuOoQ-0007ee-VH
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 16:54:31 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	6B/69-03145-6C8A8745; Fri, 28 Nov 2014 16:54:30 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417193668!6387798!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18689 invoked from network); 28 Nov 2014 16:54:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 16:54:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197778687"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 11:54:27 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuOoN-0000zK-0i;
	Fri, 28 Nov 2014 16:54:27 +0000
Date: Fri, 28 Nov 2014 16:54:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141128164935.GA17910@zion.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
	<20141128164935.GA17910@zion.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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 Fri, 28 Nov 2014, Wei Liu wrote:
> On Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
> > create ^
> > title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
> > thanks
> > 
> > On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> > > Hi,
> > > 
> > > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> > > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> > > xl didn't show any problems on the commandline so i never drawed much attention 
> > > to it, but /var/log/xen/xl-guest.log shows:
> > > 
> > >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
> > >     Domain 19 has shut down, reason code 0 0x0
> > >     Action for shutdown reason code 0 is destroy
> > >     Domain 19 needs to be cleaned up: destroying the domain
> > >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
> > >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
> > >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
> > >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
> > >     Done. Exiting now
> > > 
> > > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> > > 
> > > --
> 
> It's worth checking whether the device model exits too early, i.e., did
> it crash? What's in the DM log?

Firstly I was thinking that if force=1 it makes sense to continue even
when QEMU returns error, see:

http://marc.info/?i=alpine.DEB.2.02.1411281648500.14135%40kaball.uk.xensource.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 16:59:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 16:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuOtN-000831-Hs; Fri, 28 Nov 2014 16:59:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuOtM-00082w-6M
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 16:59:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	75/E1-09842-7F9A8745; Fri, 28 Nov 2014 16:59:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417193973!12124921!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32133 invoked from network); 28 Nov 2014 16:59:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 16:59:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197500453"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 11:59:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuOtH-0000Ms-1E;
	Fri, 28 Nov 2014 16:59:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuOtG-0005Gx-OX;
	Fri, 28 Nov 2014 16:59:30 +0000
Date: Fri, 28 Nov 2014 16:59:30 +0000
Message-ID: <E1XuOtG-0005Gx-OX@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [linux-linus bisection] complete
	test-amd64-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-credit2
test guest-saverestore

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  c6c9161d064d30e78904f3affe5184487493e0fc
  Bug not present: 8b2ed21e846c63d8f1bdee0d8df0645721a604a1


  commit c6c9161d064d30e78904f3affe5184487493e0fc
  Merge: 8b2ed21 b5e212a
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Nov 21 15:46:17 2014 -0800
  
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
      
      Pull x86 fixes from Thomas Gleixner:
       "Misc fixes:
         - gold linker build fix
         - noxsave command line parsing fix
         - bugfix for NX setup
         - microcode resume path bug fix
         - _TIF_NOHZ versus TIF_NOHZ bugfix as discussed in the mysterious
           lockup thread"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
        x86, kaslr: Handle Gold linker for finding bss/brk
        x86, mm: Set NX across entire PMD at boot
        x86, microcode: Update BSPs microcode on resume
        x86: Require exact match for 'noxsave' command line option
  
  commit b5e212a3051b65e426a513901d9c7001681c7215
  Author: Andy Lutomirski <luto@amacapital.net>
  Date:   Wed Nov 19 13:56:19 2014 -0800
  
      x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
      
      TIF_NOHZ is 19 (i.e. _TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME |
      _TIF_SINGLESTEP), not (1<<19).
      
      This code is involved in Dave's trinity lockup, but I don't see why
      it would cause any of the problems he's seeing, except inadvertently
      by causing a different path through entry_64.S's syscall handling.
      
      Signed-off-by: Andy Lutomirski <luto@amacapital.net>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.luto@amacapital.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Nov 17 16:16:04 2014 -0800
  
      x86, kaslr: Handle Gold linker for finding bss/brk
      
      When building with the Gold linker, the .bss and .brk areas of vmlinux
      are shown as consecutive instead of having the same file offset. Allow
      for either state, as long as things add up correctly.
      
      Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
      Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Link: http://lkml.kernel.org/r/20141118001604.GA25045@www.outflux.net
      Cc: stable@vger.kernel.org
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keescook@chromium.org>
  Date:   Fri Nov 14 11:47:37 2014 -0800
  
      x86, mm: Set NX across entire PMD at boot
      
      When setting up permissions on kernel memory at boot, the end of the
      PMD that was split from bss remained executable. It should be NX like
      the rest. This performs a PMD alignment instead of a PAGE alignment to
      get the correct span of memory.
      
      Before:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
      0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
      0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      After:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
              We really should unmap the reminder along with the holes
              caused by init,initdata etc. but thats a different issue ]
      
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <bp@suse.de>
  Date:   Tue Nov 18 10:46:57 2014 +0100
  
      x86, microcode: Update BSPs microcode on resume
      
      In the situation when we apply early microcode but do *not* apply late
      microcode, we fail to update the BSP's microcode on resume because we
      haven't initialized the uci->mc microcode pointer. So, in order to
      alleviate that, we go and dig out the stashed microcode patch during
      early boot. It is basically the same thing that is done on the APs early
      during boot so do that too here.
      
      Tested-by: alex.schnaidt@gmail.com
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: Borislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.hansen@linux.intel.com>
  Date:   Tue Nov 11 14:01:33 2014 -0800
  
      x86: Require exact match for 'noxsave' command line option
      
      We have some very similarly named command-line options:
      
      arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
      
      __setup() is designed to match options that take arguments, like
      "foo=bar" where you would have:
      
      	__setup("foo", x86_foo_func...);
      
      The problem is that "noxsave" actually _matches_ "noxsaves" in
      the same way that "foo" matches "foo=bar".  If you boot an old
      kernel that does not know about "noxsaves" with "noxsaves" on the
      command line, it will interpret the argument as "noxsave", which
      is not what you want at all.
      
      This makes the "noxsave" handler only return success when it finds
      an *exact* match.
      
      [ tglx: We really need to make __setup() more robust. ]
      
      Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: x86@kernel.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.linux-linus.test-amd64-i386-xl-credit2.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31858 fail [host=rice-weevil] / 31766 [host=lace-bug] 31683 [host=gall-mite] 31665 [host=bush-cricket] 31564 [host=lace-bug] 31530 [host=moss-bug] 31507 ok.
Failure / basis pass flights: 31858 / 31507
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 git://xenbits.xen.org/xen.git
Latest 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Basis pass 206c5f60a3d902bc4b56dab2de3e88de5eb06108 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#206c5f60a3d902bc4b56dab2de3e88de5eb06108-5d01410fe4d92081f349b013a2e7a95429e4f2c9 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#ca78cc83650b535d7e24baeaea32947be0141534-a230ec3101ddda868252c036ea960af2b2d6cd5a git://xenbits.xen.org/xen.git#e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2-6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 108292 nodes in revision graph
Searching for test results:
 31471 [host=itch-mite]
 31484 [host=bush-cricket]
 31507 pass 206c5f60a3d902bc4b56dab2de3e88de5eb06108 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31530 [host=moss-bug]
 31564 [host=lace-bug]
 31683 [host=gall-mite]
 31665 [host=bush-cricket]
 31766 [host=lace-bug]
 31894 fail 4fc82c0a766cf1d0bc098fb42d00b5292dde65f7 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31907 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31859 pass 206c5f60a3d902bc4b56dab2de3e88de5eb06108 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31880 pass 0c228e833c88e3aa029250f5db77d5968c5ce5b5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31865 fail irrelevant
 31868 pass irrelevant
 31869 fail irrelevant
 31896 pass 00b4d9a14125f1e51874def2b9de6092e007412d c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 09ff8eadec09233b905f79579900006fb17dd55f
 31858 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31908 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31870 fail irrelevant
 31884 fail 9a7e4f5633f0c733820091cc9c643cc0c257c349 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31887 fail 08685897b3586aad622cb48fe1fb07bc19bb78f5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31850 fail irrelevant
 31898 pass 00b4d9a14125f1e51874def2b9de6092e007412d c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31909 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31888 pass b0ab3f190e7331a83b397a0e772cbc01bf18201f c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 934e7baa6c12d19cfaf24e8f8e27d6c6a8b8c5e4
 31879 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31891 pass 5ae93760cbedda64eab0a7012cc3785c32399641 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 abbbc2f09a53f8f9ee565356ab11a78af006e45e 902dfd33da08169f08a593a4ef2c45d825cca8c8
 31901 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 4e1d1d097423aaeb2fb2f19ac4691bb326bd62d8
 31893 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 405254bbb2fdbfa8a428fd144ea7585812af9e8a
 31910 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31903 pass a64bb02f4a62a604d8dd62decb559b9c6adfb40c c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31905 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31911 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Searching for interesting versions
 Result found: flight 31507 (pass), for basis pass
 Result found: flight 31858 (fail), for basis failure
 Repro found: flight 31859 (pass), for basis pass
 Repro found: flight 31879 (fail), for basis failure
 0 revisions at 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
No revisions left to test, checking graph state.
 Result found: flight 31905 (pass), for last pass
 Result found: flight 31907 (fail), for first failure
 Repro found: flight 31908 (pass), for last pass
 Repro found: flight 31909 (fail), for first failure
 Repro found: flight 31910 (pass), for last pass
 Repro found: flight 31911 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  c6c9161d064d30e78904f3affe5184487493e0fc
  Bug not present: 8b2ed21e846c63d8f1bdee0d8df0645721a604a1

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit c6c9161d064d30e78904f3affe5184487493e0fc
  Merge: 8b2ed21 b5e212a
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Nov 21 15:46:17 2014 -0800
  
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
      
      Pull x86 fixes from Thomas Gleixner:
       "Misc fixes:
         - gold linker build fix
         - noxsave command line parsing fix
         - bugfix for NX setup
         - microcode resume path bug fix
         - _TIF_NOHZ versus TIF_NOHZ bugfix as discussed in the mysterious
           lockup thread"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
        x86, kaslr: Handle Gold linker for finding bss/brk
        x86, mm: Set NX across entire PMD at boot
        x86, microcode: Update BSPs microcode on resume
        x86: Require exact match for 'noxsave' command line option
  
  commit b5e212a3051b65e426a513901d9c7001681c7215
  Author: Andy Lutomirski <luto@amacapital.net>
  Date:   Wed Nov 19 13:56:19 2014 -0800
  
      x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
      
      TIF_NOHZ is 19 (i.e. _TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME |
      _TIF_SINGLESTEP), not (1<<19).
      
      This code is involved in Dave's trinity lockup, but I don't see why
      it would cause any of the problems he's seeing, except inadvertently
      by causing a different path through entry_64.S's syscall handling.
      
      Signed-off-by: Andy Lutomirski <luto@amacapital.net>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.luto@amacapital.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Nov 17 16:16:04 2014 -0800
  
      x86, kaslr: Handle Gold linker for finding bss/brk
      
      When building with the Gold linker, the .bss and .brk areas of vmlinux
      are shown as consecutive instead of having the same file offset. Allow
      for either state, as long as things add up correctly.
      
      Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
      Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Link: http://lkml.kernel.org/r/20141118001604.GA25045@www.outflux.net
      Cc: stable@vger.kernel.org
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keescook@chromium.org>
  Date:   Fri Nov 14 11:47:37 2014 -0800
  
      x86, mm: Set NX across entire PMD at boot
      
      When setting up permissions on kernel memory at boot, the end of the
      PMD that was split from bss remained executable. It should be NX like
      the rest. This performs a PMD alignment instead of a PAGE alignment to
      get the correct span of memory.
      
      Before:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
      0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
      0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      After:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
              We really should unmap the reminder along with the holes
              caused by init,initdata etc. but thats a different issue ]
      
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <bp@suse.de>
  Date:   Tue Nov 18 10:46:57 2014 +0100
  
      x86, microcode: Update BSPs microcode on resume
      
      In the situation when we apply early microcode but do *not* apply late
      microcode, we fail to update the BSP's microcode on resume because we
      haven't initialized the uci->mc microcode pointer. So, in order to
      alleviate that, we go and dig out the stashed microcode patch during
      early boot. It is basically the same thing that is done on the APs early
      during boot so do that too here.
      
      Tested-by: alex.schnaidt@gmail.com
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: Borislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.hansen@linux.intel.com>
  Date:   Tue Nov 11 14:01:33 2014 -0800
  
      x86: Require exact match for 'noxsave' command line option
      
      We have some very similarly named command-line options:
      
      arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
      
      __setup() is designed to match options that take arguments, like
      "foo=bar" where you would have:
      
      	__setup("foo", x86_foo_func...);
      
      The problem is that "noxsave" actually _matches_ "noxsaves" in
      the same way that "foo" matches "foo=bar".  If you boot an old
      kernel that does not know about "noxsaves" with "noxsaves" on the
      command line, it will interpret the argument as "noxsave", which
      is not what you want at all.
      
      This makes the "noxsave" handler only return success when it finds
      an *exact* match.
      
      [ tglx: We really need to make __setup() more robust. ]
      
      Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: x86@kernel.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Revision graph left in /home/xc_osstest/results/bisect.linux-linus.test-amd64-i386-xl-credit2.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
31911: tolerable ALL FAIL

flight 31911 linux-linus real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31911/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-credit2   11 guest-saverestore       fail baseline untested


jobs:
 test-amd64-i386-xl-credit2                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 16:59:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 16:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuOtN-000831-Hs; Fri, 28 Nov 2014 16:59:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuOtM-00082w-6M
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 16:59:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	75/E1-09842-7F9A8745; Fri, 28 Nov 2014 16:59:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417193973!12124921!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32133 invoked from network); 28 Nov 2014 16:59:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 16:59:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197500453"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 11:59:31 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuOtH-0000Ms-1E;
	Fri, 28 Nov 2014 16:59:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuOtG-0005Gx-OX;
	Fri, 28 Nov 2014 16:59:30 +0000
Date: Fri, 28 Nov 2014 16:59:30 +0000
Message-ID: <E1XuOtG-0005Gx-OX@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [linux-linus bisection] complete
	test-amd64-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-credit2
test guest-saverestore

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  c6c9161d064d30e78904f3affe5184487493e0fc
  Bug not present: 8b2ed21e846c63d8f1bdee0d8df0645721a604a1


  commit c6c9161d064d30e78904f3affe5184487493e0fc
  Merge: 8b2ed21 b5e212a
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Nov 21 15:46:17 2014 -0800
  
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
      
      Pull x86 fixes from Thomas Gleixner:
       "Misc fixes:
         - gold linker build fix
         - noxsave command line parsing fix
         - bugfix for NX setup
         - microcode resume path bug fix
         - _TIF_NOHZ versus TIF_NOHZ bugfix as discussed in the mysterious
           lockup thread"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
        x86, kaslr: Handle Gold linker for finding bss/brk
        x86, mm: Set NX across entire PMD at boot
        x86, microcode: Update BSPs microcode on resume
        x86: Require exact match for 'noxsave' command line option
  
  commit b5e212a3051b65e426a513901d9c7001681c7215
  Author: Andy Lutomirski <luto@amacapital.net>
  Date:   Wed Nov 19 13:56:19 2014 -0800
  
      x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
      
      TIF_NOHZ is 19 (i.e. _TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME |
      _TIF_SINGLESTEP), not (1<<19).
      
      This code is involved in Dave's trinity lockup, but I don't see why
      it would cause any of the problems he's seeing, except inadvertently
      by causing a different path through entry_64.S's syscall handling.
      
      Signed-off-by: Andy Lutomirski <luto@amacapital.net>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.luto@amacapital.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Nov 17 16:16:04 2014 -0800
  
      x86, kaslr: Handle Gold linker for finding bss/brk
      
      When building with the Gold linker, the .bss and .brk areas of vmlinux
      are shown as consecutive instead of having the same file offset. Allow
      for either state, as long as things add up correctly.
      
      Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
      Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Link: http://lkml.kernel.org/r/20141118001604.GA25045@www.outflux.net
      Cc: stable@vger.kernel.org
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keescook@chromium.org>
  Date:   Fri Nov 14 11:47:37 2014 -0800
  
      x86, mm: Set NX across entire PMD at boot
      
      When setting up permissions on kernel memory at boot, the end of the
      PMD that was split from bss remained executable. It should be NX like
      the rest. This performs a PMD alignment instead of a PAGE alignment to
      get the correct span of memory.
      
      Before:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
      0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
      0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      After:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
              We really should unmap the reminder along with the holes
              caused by init,initdata etc. but thats a different issue ]
      
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <bp@suse.de>
  Date:   Tue Nov 18 10:46:57 2014 +0100
  
      x86, microcode: Update BSPs microcode on resume
      
      In the situation when we apply early microcode but do *not* apply late
      microcode, we fail to update the BSP's microcode on resume because we
      haven't initialized the uci->mc microcode pointer. So, in order to
      alleviate that, we go and dig out the stashed microcode patch during
      early boot. It is basically the same thing that is done on the APs early
      during boot so do that too here.
      
      Tested-by: alex.schnaidt@gmail.com
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: Borislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.hansen@linux.intel.com>
  Date:   Tue Nov 11 14:01:33 2014 -0800
  
      x86: Require exact match for 'noxsave' command line option
      
      We have some very similarly named command-line options:
      
      arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
      
      __setup() is designed to match options that take arguments, like
      "foo=bar" where you would have:
      
      	__setup("foo", x86_foo_func...);
      
      The problem is that "noxsave" actually _matches_ "noxsaves" in
      the same way that "foo" matches "foo=bar".  If you boot an old
      kernel that does not know about "noxsaves" with "noxsaves" on the
      command line, it will interpret the argument as "noxsave", which
      is not what you want at all.
      
      This makes the "noxsave" handler only return success when it finds
      an *exact* match.
      
      [ tglx: We really need to make __setup() more robust. ]
      
      Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: x86@kernel.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.linux-linus.test-amd64-i386-xl-credit2.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31858 fail [host=rice-weevil] / 31766 [host=lace-bug] 31683 [host=gall-mite] 31665 [host=bush-cricket] 31564 [host=lace-bug] 31530 [host=moss-bug] 31507 ok.
Failure / basis pass flights: 31858 / 31507
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 git://xenbits.xen.org/xen.git
Latest 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Basis pass 206c5f60a3d902bc4b56dab2de3e88de5eb06108 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#206c5f60a3d902bc4b56dab2de3e88de5eb06108-5d01410fe4d92081f349b013a2e7a95429e4f2c9 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#ca78cc83650b535d7e24baeaea32947be0141534-a230ec3101ddda868252c036ea960af2b2d6cd5a git://xenbits.xen.org/xen.git#e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2-6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 108292 nodes in revision graph
Searching for test results:
 31471 [host=itch-mite]
 31484 [host=bush-cricket]
 31507 pass 206c5f60a3d902bc4b56dab2de3e88de5eb06108 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31530 [host=moss-bug]
 31564 [host=lace-bug]
 31683 [host=gall-mite]
 31665 [host=bush-cricket]
 31766 [host=lace-bug]
 31894 fail 4fc82c0a766cf1d0bc098fb42d00b5292dde65f7 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31907 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31859 pass 206c5f60a3d902bc4b56dab2de3e88de5eb06108 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31880 pass 0c228e833c88e3aa029250f5db77d5968c5ce5b5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31865 fail irrelevant
 31868 pass irrelevant
 31869 fail irrelevant
 31896 pass 00b4d9a14125f1e51874def2b9de6092e007412d c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 09ff8eadec09233b905f79579900006fb17dd55f
 31858 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31908 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31870 fail irrelevant
 31884 fail 9a7e4f5633f0c733820091cc9c643cc0c257c349 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31887 fail 08685897b3586aad622cb48fe1fb07bc19bb78f5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31850 fail irrelevant
 31898 pass 00b4d9a14125f1e51874def2b9de6092e007412d c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31909 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31888 pass b0ab3f190e7331a83b397a0e772cbc01bf18201f c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 934e7baa6c12d19cfaf24e8f8e27d6c6a8b8c5e4
 31879 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31891 pass 5ae93760cbedda64eab0a7012cc3785c32399641 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 abbbc2f09a53f8f9ee565356ab11a78af006e45e 902dfd33da08169f08a593a4ef2c45d825cca8c8
 31901 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 4e1d1d097423aaeb2fb2f19ac4691bb326bd62d8
 31893 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 405254bbb2fdbfa8a428fd144ea7585812af9e8a
 31910 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31903 pass a64bb02f4a62a604d8dd62decb559b9c6adfb40c c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31905 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31911 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Searching for interesting versions
 Result found: flight 31507 (pass), for basis pass
 Result found: flight 31858 (fail), for basis failure
 Repro found: flight 31859 (pass), for basis pass
 Repro found: flight 31879 (fail), for basis failure
 0 revisions at 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
No revisions left to test, checking graph state.
 Result found: flight 31905 (pass), for last pass
 Result found: flight 31907 (fail), for first failure
 Repro found: flight 31908 (pass), for last pass
 Repro found: flight 31909 (fail), for first failure
 Repro found: flight 31910 (pass), for last pass
 Repro found: flight 31911 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  c6c9161d064d30e78904f3affe5184487493e0fc
  Bug not present: 8b2ed21e846c63d8f1bdee0d8df0645721a604a1

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit c6c9161d064d30e78904f3affe5184487493e0fc
  Merge: 8b2ed21 b5e212a
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Nov 21 15:46:17 2014 -0800
  
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
      
      Pull x86 fixes from Thomas Gleixner:
       "Misc fixes:
         - gold linker build fix
         - noxsave command line parsing fix
         - bugfix for NX setup
         - microcode resume path bug fix
         - _TIF_NOHZ versus TIF_NOHZ bugfix as discussed in the mysterious
           lockup thread"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
        x86, kaslr: Handle Gold linker for finding bss/brk
        x86, mm: Set NX across entire PMD at boot
        x86, microcode: Update BSPs microcode on resume
        x86: Require exact match for 'noxsave' command line option
  
  commit b5e212a3051b65e426a513901d9c7001681c7215
  Author: Andy Lutomirski <luto@amacapital.net>
  Date:   Wed Nov 19 13:56:19 2014 -0800
  
      x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
      
      TIF_NOHZ is 19 (i.e. _TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME |
      _TIF_SINGLESTEP), not (1<<19).
      
      This code is involved in Dave's trinity lockup, but I don't see why
      it would cause any of the problems he's seeing, except inadvertently
      by causing a different path through entry_64.S's syscall handling.
      
      Signed-off-by: Andy Lutomirski <luto@amacapital.net>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.luto@amacapital.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Nov 17 16:16:04 2014 -0800
  
      x86, kaslr: Handle Gold linker for finding bss/brk
      
      When building with the Gold linker, the .bss and .brk areas of vmlinux
      are shown as consecutive instead of having the same file offset. Allow
      for either state, as long as things add up correctly.
      
      Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
      Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Link: http://lkml.kernel.org/r/20141118001604.GA25045@www.outflux.net
      Cc: stable@vger.kernel.org
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keescook@chromium.org>
  Date:   Fri Nov 14 11:47:37 2014 -0800
  
      x86, mm: Set NX across entire PMD at boot
      
      When setting up permissions on kernel memory at boot, the end of the
      PMD that was split from bss remained executable. It should be NX like
      the rest. This performs a PMD alignment instead of a PAGE alignment to
      get the correct span of memory.
      
      Before:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
      0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
      0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      After:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
              We really should unmap the reminder along with the holes
              caused by init,initdata etc. but thats a different issue ]
      
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <bp@suse.de>
  Date:   Tue Nov 18 10:46:57 2014 +0100
  
      x86, microcode: Update BSPs microcode on resume
      
      In the situation when we apply early microcode but do *not* apply late
      microcode, we fail to update the BSP's microcode on resume because we
      haven't initialized the uci->mc microcode pointer. So, in order to
      alleviate that, we go and dig out the stashed microcode patch during
      early boot. It is basically the same thing that is done on the APs early
      during boot so do that too here.
      
      Tested-by: alex.schnaidt@gmail.com
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: Borislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.hansen@linux.intel.com>
  Date:   Tue Nov 11 14:01:33 2014 -0800
  
      x86: Require exact match for 'noxsave' command line option
      
      We have some very similarly named command-line options:
      
      arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
      
      __setup() is designed to match options that take arguments, like
      "foo=bar" where you would have:
      
      	__setup("foo", x86_foo_func...);
      
      The problem is that "noxsave" actually _matches_ "noxsaves" in
      the same way that "foo" matches "foo=bar".  If you boot an old
      kernel that does not know about "noxsaves" with "noxsaves" on the
      command line, it will interpret the argument as "noxsave", which
      is not what you want at all.
      
      This makes the "noxsave" handler only return success when it finds
      an *exact* match.
      
      [ tglx: We really need to make __setup() more robust. ]
      
      Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: x86@kernel.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Revision graph left in /home/xc_osstest/results/bisect.linux-linus.test-amd64-i386-xl-credit2.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
31911: tolerable ALL FAIL

flight 31911 linux-linus real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31911/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-credit2   11 guest-saverestore       fail baseline untested


jobs:
 test-amd64-i386-xl-credit2                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 17:01:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 17:01:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuOv4-0008C9-95; Fri, 28 Nov 2014 17:01:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XuOv2-0008Bs-GU
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 17:01:20 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	E5/0C-02698-F5AA8745; Fri, 28 Nov 2014 17:01:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417194077!11788003!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10278 invoked from network); 28 Nov 2014 17:01:19 -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;
	28 Nov 2014 17:01:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197500890"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 12:01:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XuOuy-00016v-TH;
	Fri, 28 Nov 2014 17:01:16 +0000
Date: Fri, 28 Nov 2014 17:01:16 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141128170116.GB17910@zion.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
	<20141128164935.GA17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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 Fri, Nov 28, 2014 at 04:54:19PM +0000, Stefano Stabellini wrote:
> On Fri, 28 Nov 2014, Wei Liu wrote:
> > On Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
> > > create ^
> > > title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
> > > thanks
> > > 
> > > On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> > > > Hi,
> > > > 
> > > > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> > > > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> > > > xl didn't show any problems on the commandline so i never drawed much attention 
> > > > to it, but /var/log/xen/xl-guest.log shows:
> > > > 
> > > >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
> > > >     Domain 19 has shut down, reason code 0 0x0
> > > >     Action for shutdown reason code 0 is destroy
> > > >     Domain 19 needs to be cleaned up: destroying the domain
> > > >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
> > > >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
> > > >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
> > > >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
> > > >     Done. Exiting now
> > > > 
> > > > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> > > > 
> > > > --
> > 
> > It's worth checking whether the device model exits too early, i.e., did
> > it crash? What's in the DM log?
> 
> Firstly I was thinking that if force=1 it makes sense to continue even
> when QEMU returns error, see:
> 
> http://marc.info/?i=alpine.DEB.2.02.1411281648500.14135%40kaball.uk.xensource.com

In normal case DM is not destroyed until PCI device is removed. So I
think the real issue is DM crashed.

libxl.c:
1571     if (libxl__device_pci_destroy_all(gc, domid) < 0)
1572         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
1573     rc = xc_domain_pause(ctx->xch, domid);
1574     if (rc < 0) {
1575         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
1576     }
1577     if (dm_present) {
1578         if (libxl__destroy_device_model(gc, domid) < 0)
1579             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
1580
1581         libxl__qmp_cleanup(gc, domid);
1582     }

The patch you posted covers up the real issue.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 17:01:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 17:01:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuOv4-0008C9-95; Fri, 28 Nov 2014 17:01:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XuOv2-0008Bs-GU
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 17:01:20 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	E5/0C-02698-F5AA8745; Fri, 28 Nov 2014 17:01:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417194077!11788003!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10278 invoked from network); 28 Nov 2014 17:01:19 -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;
	28 Nov 2014 17:01:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197500890"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 12:01:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XuOuy-00016v-TH;
	Fri, 28 Nov 2014 17:01:16 +0000
Date: Fri, 28 Nov 2014 17:01:16 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141128170116.GB17910@zion.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
	<20141128164935.GA17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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 Fri, Nov 28, 2014 at 04:54:19PM +0000, Stefano Stabellini wrote:
> On Fri, 28 Nov 2014, Wei Liu wrote:
> > On Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
> > > create ^
> > > title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
> > > thanks
> > > 
> > > On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> > > > Hi,
> > > > 
> > > > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> > > > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> > > > xl didn't show any problems on the commandline so i never drawed much attention 
> > > > to it, but /var/log/xen/xl-guest.log shows:
> > > > 
> > > >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
> > > >     Domain 19 has shut down, reason code 0 0x0
> > > >     Action for shutdown reason code 0 is destroy
> > > >     Domain 19 needs to be cleaned up: destroying the domain
> > > >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
> > > >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
> > > >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
> > > >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
> > > >     Done. Exiting now
> > > > 
> > > > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> > > > 
> > > > --
> > 
> > It's worth checking whether the device model exits too early, i.e., did
> > it crash? What's in the DM log?
> 
> Firstly I was thinking that if force=1 it makes sense to continue even
> when QEMU returns error, see:
> 
> http://marc.info/?i=alpine.DEB.2.02.1411281648500.14135%40kaball.uk.xensource.com

In normal case DM is not destroyed until PCI device is removed. So I
think the real issue is DM crashed.

libxl.c:
1571     if (libxl__device_pci_destroy_all(gc, domid) < 0)
1572         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
1573     rc = xc_domain_pause(ctx->xch, domid);
1574     if (rc < 0) {
1575         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
1576     }
1577     if (dm_present) {
1578         if (libxl__destroy_device_model(gc, domid) < 0)
1579             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
1580
1581         libxl__qmp_cleanup(gc, domid);
1582     }

The patch you posted covers up the real issue.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 17:10:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 17:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuP3U-00009c-D3; Fri, 28 Nov 2014 17:10:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuP3T-00009X-0S
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 17:10:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FC/EF-09842-A6CA8745; Fri, 28 Nov 2014 17:10:02 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417194600!12138412!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3616 invoked from network); 28 Nov 2014 17:10:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 17:10:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197502975"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 12:09:59 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuP3P-0001GW-Fr;
	Fri, 28 Nov 2014 17:09:59 +0000
Date: Fri, 28 Nov 2014 17:09:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141128170116.GB17910@zion.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411281705050.14135@kaball.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
	<20141128164935.GA17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
	<20141128170116.GB17910@zion.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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 Fri, 28 Nov 2014, Wei Liu wrote:
> On Fri, Nov 28, 2014 at 04:54:19PM +0000, Stefano Stabellini wrote:
> > On Fri, 28 Nov 2014, Wei Liu wrote:
> > > On Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
> > > > create ^
> > > > title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
> > > > thanks
> > > > 
> > > > On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> > > > > Hi,
> > > > > 
> > > > > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> > > > > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> > > > > xl didn't show any problems on the commandline so i never drawed much attention 
> > > > > to it, but /var/log/xen/xl-guest.log shows:
> > > > > 
> > > > >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
> > > > >     Domain 19 has shut down, reason code 0 0x0
> > > > >     Action for shutdown reason code 0 is destroy
> > > > >     Domain 19 needs to be cleaned up: destroying the domain
> > > > >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
> > > > >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
> > > > >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
> > > > >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
> > > > >     Done. Exiting now
> > > > > 
> > > > > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> > > > > 
> > > > > --
> > > 
> > > It's worth checking whether the device model exits too early, i.e., did
> > > it crash? What's in the DM log?
> > 
> > Firstly I was thinking that if force=1 it makes sense to continue even
> > when QEMU returns error, see:
> > 
> > http://marc.info/?i=alpine.DEB.2.02.1411281648500.14135%40kaball.uk.xensource.com
> 
> In normal case DM is not destroyed until PCI device is removed. So I
> think the real issue is DM crashed.

I don't think it crashed: QEMU detects that domain shutdown has been
called and exits.
See:

static void main_loop(void)
{
    bool nonblocking;
    int last_io = 0;
#ifdef CONFIG_PROFILER
    int64_t ti;
#endif
    do {

[...]

    } while (!main_loop_should_exit());
}


main_loop_should_exit returns true when qemu_shutdown_requested().


> libxl.c:
> 1571     if (libxl__device_pci_destroy_all(gc, domid) < 0)
> 1572         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
> 1573     rc = xc_domain_pause(ctx->xch, domid);
> 1574     if (rc < 0) {
> 1575         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
> 1576     }
> 1577     if (dm_present) {
> 1578         if (libxl__destroy_device_model(gc, domid) < 0)
> 1579             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
> 1580
> 1581         libxl__qmp_cleanup(gc, domid);
> 1582     }
> 
> The patch you posted covers up the real issue.

That is true, but I think the patch is correct regardless of the issue.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 17:10:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 17:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuP3U-00009c-D3; Fri, 28 Nov 2014 17:10:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuP3T-00009X-0S
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 17:10:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FC/EF-09842-A6CA8745; Fri, 28 Nov 2014 17:10:02 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417194600!12138412!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3616 invoked from network); 28 Nov 2014 17:10:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 17:10:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="197502975"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 12:09:59 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuP3P-0001GW-Fr;
	Fri, 28 Nov 2014 17:09:59 +0000
Date: Fri, 28 Nov 2014 17:09:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141128170116.GB17910@zion.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1411281705050.14135@kaball.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
	<20141128164935.GA17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
	<20141128170116.GB17910@zion.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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 Fri, 28 Nov 2014, Wei Liu wrote:
> On Fri, Nov 28, 2014 at 04:54:19PM +0000, Stefano Stabellini wrote:
> > On Fri, 28 Nov 2014, Wei Liu wrote:
> > > On Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
> > > > create ^
> > > > title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
> > > > thanks
> > > > 
> > > > On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> > > > > Hi,
> > > > > 
> > > > > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> > > > > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> > > > > xl didn't show any problems on the commandline so i never drawed much attention 
> > > > > to it, but /var/log/xen/xl-guest.log shows:
> > > > > 
> > > > >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
> > > > >     Domain 19 has shut down, reason code 0 0x0
> > > > >     Action for shutdown reason code 0 is destroy
> > > > >     Domain 19 needs to be cleaned up: destroying the domain
> > > > >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
> > > > >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
> > > > >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
> > > > >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
> > > > >     Done. Exiting now
> > > > > 
> > > > > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> > > > > 
> > > > > --
> > > 
> > > It's worth checking whether the device model exits too early, i.e., did
> > > it crash? What's in the DM log?
> > 
> > Firstly I was thinking that if force=1 it makes sense to continue even
> > when QEMU returns error, see:
> > 
> > http://marc.info/?i=alpine.DEB.2.02.1411281648500.14135%40kaball.uk.xensource.com
> 
> In normal case DM is not destroyed until PCI device is removed. So I
> think the real issue is DM crashed.

I don't think it crashed: QEMU detects that domain shutdown has been
called and exits.
See:

static void main_loop(void)
{
    bool nonblocking;
    int last_io = 0;
#ifdef CONFIG_PROFILER
    int64_t ti;
#endif
    do {

[...]

    } while (!main_loop_should_exit());
}


main_loop_should_exit returns true when qemu_shutdown_requested().


> libxl.c:
> 1571     if (libxl__device_pci_destroy_all(gc, domid) < 0)
> 1572         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
> 1573     rc = xc_domain_pause(ctx->xch, domid);
> 1574     if (rc < 0) {
> 1575         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
> 1576     }
> 1577     if (dm_present) {
> 1578         if (libxl__destroy_device_model(gc, domid) < 0)
> 1579             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
> 1580
> 1581         libxl__qmp_cleanup(gc, domid);
> 1582     }
> 
> The patch you posted covers up the real issue.

That is true, but I think the patch is correct regardless of the issue.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 17:40:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 17: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 1XuPWg-0000u6-VI; Fri, 28 Nov 2014 17:40:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XuPWf-0000u1-CY
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 17:40:13 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	22/0C-25727-C73B8745; Fri, 28 Nov 2014 17:40:12 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417196412!12124078!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24544 invoked from network); 28 Nov 2014 17:40:12 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 28 Nov 2014 17:40:12 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54481 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XuPUB-0006RV-PP; Fri, 28 Nov 2014 18:37:39 +0100
Date: Fri, 28 Nov 2014 18:40:04 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1868834068.20141128184004@eikelenboom.it>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411281705050.14135@kaball.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
	<20141128164935.GA17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
	<20141128170116.GB17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281705050.14135@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
	libxl_pci teardown path for HVM guest with 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


Friday, November 28, 2014, 6:09:52 PM, you wrote:

> On Fri, 28 Nov 2014, Wei Liu wrote:
>> On Fri, Nov 28, 2014 at 04:54:19PM +0000, Stefano Stabellini wrote:
>> > On Fri, 28 Nov 2014, Wei Liu wrote:
>> > > On Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
>> > > > create ^
>> > > > title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
>> > > > thanks
>> > > > 
>> > > > On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
>> > > > > Hi,
>> > > > > 
>> > > > > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
>> > > > > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
>> > > > > xl didn't show any problems on the commandline so i never drawed much attention 
>> > > > > to it, but /var/log/xen/xl-guest.log shows:
>> > > > > 
>> > > > >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
>> > > > >     Domain 19 has shut down, reason code 0 0x0
>> > > > >     Action for shutdown reason code 0 is destroy
>> > > > >     Domain 19 needs to be cleaned up: destroying the domain
>> > > > >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
>> > > > >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
>> > > > >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
>> > > > >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
>> > > > >     Done. Exiting now
>> > > > > 
>> > > > > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
>> > > > > 
>> > > > > --
>> > > 
>> > > It's worth checking whether the device model exits too early, i.e., did
>> > > it crash? What's in the DM log?
>> > 
>> > Firstly I was thinking that if force=1 it makes sense to continue even
>> > when QEMU returns error, see:
>> > 
>> > http://marc.info/?i=alpine.DEB.2.02.1411281648500.14135%40kaball.uk.xensource.com
>> 
>> In normal case DM is not destroyed until PCI device is removed. So I
>> think the real issue is DM crashed.

> I don't think it crashed: QEMU detects that domain shutdown has been
> called and exits.
> See:

> static void main_loop(void)
> {
>     bool nonblocking;
>     int last_io = 0;
> #ifdef CONFIG_PROFILER
>     int64_t ti;
> #endif
>     do {

> [...]

>     } while (!main_loop_should_exit());
> }


> main_loop_should_exit returns true when qemu_shutdown_requested().


>> libxl.c:
>> 1571     if (libxl__device_pci_destroy_all(gc, domid) < 0)
>> 1572         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
>> 1573     rc = xc_domain_pause(ctx->xch, domid);
>> 1574     if (rc < 0) {
>> 1575         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
>> 1576     }
>> 1577     if (dm_present) {
>> 1578         if (libxl__destroy_device_model(gc, domid) < 0)
>> 1579             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
>> 1580
>> 1581         libxl__qmp_cleanup(gc, domid);
>> 1582     }
>> 
>> The patch you posted covers up the real issue.

> That is true, but I think the patch is correct regardless of the issue.

Hmm how about qemu's "-no-shutdown" option ?
>From the manpage:
-no-shutdown
    Don't exit QEMU on guest shutdown, but instead only stop the emulation. This allows for instance switching to monitor to commit changes to the disk image. 

with:
device_model_args_hvm = [ '-no-shutdown' ]

I get:

/var/log/xen/xl-tv.log:

Waiting for domain tv (domid 18) to die [pid 18587]
Domain 18 has shut down, reason code 0 0x0
Action for shutdown reason code 0 is destroy
Domain 18 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1299:do_pci_remove: xc_domain_irq_permission irq=40: Invalid argument
libxl: error: libxl_pci.c:1012:libxl__device_pci_reset: ?!?!? Me here
Done. Exiting now

/var/log/xen/qemu-dm-tv.log:

char device redirected to /dev/pts/21 (label serial0)
VNC server running on `127.0.0.1:5901'
xen be: vkbd-0: initialise() failed
xen be: vkbd-0: initialise() failed
xen be: vkbd-0: initialise() failed
Issued domain 18 poweroff
qemu: terminating on signal 1 from pid 18587


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 17:40:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 17: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 1XuPWg-0000u6-VI; Fri, 28 Nov 2014 17:40:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XuPWf-0000u1-CY
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 17:40:13 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	22/0C-25727-C73B8745; Fri, 28 Nov 2014 17:40:12 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417196412!12124078!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24544 invoked from network); 28 Nov 2014 17:40:12 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 28 Nov 2014 17:40:12 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:54481 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XuPUB-0006RV-PP; Fri, 28 Nov 2014 18:37:39 +0100
Date: Fri, 28 Nov 2014 18:40:04 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1868834068.20141128184004@eikelenboom.it>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411281705050.14135@kaball.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
	<20141128164935.GA17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
	<20141128170116.GB17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281705050.14135@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
	libxl_pci teardown path for HVM guest with 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


Friday, November 28, 2014, 6:09:52 PM, you wrote:

> On Fri, 28 Nov 2014, Wei Liu wrote:
>> On Fri, Nov 28, 2014 at 04:54:19PM +0000, Stefano Stabellini wrote:
>> > On Fri, 28 Nov 2014, Wei Liu wrote:
>> > > On Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
>> > > > create ^
>> > > > title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
>> > > > thanks
>> > > > 
>> > > > On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
>> > > > > Hi,
>> > > > > 
>> > > > > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
>> > > > > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
>> > > > > xl didn't show any problems on the commandline so i never drawed much attention 
>> > > > > to it, but /var/log/xen/xl-guest.log shows:
>> > > > > 
>> > > > >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
>> > > > >     Domain 19 has shut down, reason code 0 0x0
>> > > > >     Action for shutdown reason code 0 is destroy
>> > > > >     Domain 19 needs to be cleaned up: destroying the domain
>> > > > >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
>> > > > >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
>> > > > >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
>> > > > >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
>> > > > >     Done. Exiting now
>> > > > > 
>> > > > > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
>> > > > > 
>> > > > > --
>> > > 
>> > > It's worth checking whether the device model exits too early, i.e., did
>> > > it crash? What's in the DM log?
>> > 
>> > Firstly I was thinking that if force=1 it makes sense to continue even
>> > when QEMU returns error, see:
>> > 
>> > http://marc.info/?i=alpine.DEB.2.02.1411281648500.14135%40kaball.uk.xensource.com
>> 
>> In normal case DM is not destroyed until PCI device is removed. So I
>> think the real issue is DM crashed.

> I don't think it crashed: QEMU detects that domain shutdown has been
> called and exits.
> See:

> static void main_loop(void)
> {
>     bool nonblocking;
>     int last_io = 0;
> #ifdef CONFIG_PROFILER
>     int64_t ti;
> #endif
>     do {

> [...]

>     } while (!main_loop_should_exit());
> }


> main_loop_should_exit returns true when qemu_shutdown_requested().


>> libxl.c:
>> 1571     if (libxl__device_pci_destroy_all(gc, domid) < 0)
>> 1572         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
>> 1573     rc = xc_domain_pause(ctx->xch, domid);
>> 1574     if (rc < 0) {
>> 1575         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
>> 1576     }
>> 1577     if (dm_present) {
>> 1578         if (libxl__destroy_device_model(gc, domid) < 0)
>> 1579             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
>> 1580
>> 1581         libxl__qmp_cleanup(gc, domid);
>> 1582     }
>> 
>> The patch you posted covers up the real issue.

> That is true, but I think the patch is correct regardless of the issue.

Hmm how about qemu's "-no-shutdown" option ?
>From the manpage:
-no-shutdown
    Don't exit QEMU on guest shutdown, but instead only stop the emulation. This allows for instance switching to monitor to commit changes to the disk image. 

with:
device_model_args_hvm = [ '-no-shutdown' ]

I get:

/var/log/xen/xl-tv.log:

Waiting for domain tv (domid 18) to die [pid 18587]
Domain 18 has shut down, reason code 0 0x0
Action for shutdown reason code 0 is destroy
Domain 18 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1299:do_pci_remove: xc_domain_irq_permission irq=40: Invalid argument
libxl: error: libxl_pci.c:1012:libxl__device_pci_reset: ?!?!? Me here
Done. Exiting now

/var/log/xen/qemu-dm-tv.log:

char device redirected to /dev/pts/21 (label serial0)
VNC server running on `127.0.0.1:5901'
xen be: vkbd-0: initialise() failed
xen be: vkbd-0: initialise() failed
xen be: vkbd-0: initialise() failed
Issued domain 18 poweroff
qemu: terminating on signal 1 from pid 18587


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 17:50:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 17: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 1XuPgU-0001Eo-6Q; Fri, 28 Nov 2014 17:50: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@citrix.com>) id 1XuPgS-0001Ej-Ux
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 17:50:21 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	DB/D1-24124-CD5B8745; Fri, 28 Nov 2014 17:50:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417197017!10579048!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22251 invoked from network); 28 Nov 2014 17:50:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 17:50:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,478,1413244800"; d="scan'208";a="197510828"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 12:50:16 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuPgN-0000cR-Ow;
	Fri, 28 Nov 2014 17:50:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuPgN-0005a2-GR;
	Fri, 28 Nov 2014 17:50:15 +0000
Date: Fri, 28 Nov 2014 17:50:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31886-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31886: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31886 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31886/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 31855

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31855

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                490309fcfbed9fa1ed357541f609975016a34628
baseline version:
 qemuu                ca6028185d19d3f2bd331c15175c3ef5afc30c77

------------------------------------------------------------
People who touched revisions under test:
  Christian Borntraeger <borntraeger@de.ibm.com>
  Don Slutz <dslutz@verizon.com>
  Eric Blake <eblake@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Markus Armbruster <armbru@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 490309fcfbed9fa1ed357541f609975016a34628
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Nov 25 18:21:45 2014 +0000

    qemu-timer: Avoid overflows when converting timeout to struct timespec
    
    In qemu_poll_ns(), when we convert an int64_t nanosecond timeout into
    a struct timespec, we may accidentally run into overflow problems if
    the timeout is very long. This happens because the tv_sec field is a
    time_t, which is signed, so we might end up setting it to a negative
    value by mistake. This will result in what was intended to be a
    near-infinite timeout turning into an instantaneous timeout, and we'll
    busy loop. Cap the maximum timeout at INT32_MAX seconds (about 68 years)
    to avoid this problem.
    
    This specifically manifested on ARM hosts as an extreme slowdown on
    guest shutdown (when the guest reprogrammed the PL031 RTC to not
    generate alarms using a very long timeout) but could happen on other
    hosts and guests too.
    
    Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Fam Zheng <famz@redhat.com>
    Message-id: 1416939705-1272-1-git-send-email-peter.maydell@linaro.org

commit 3ef4ebcc5c0360629bb05f49d9b961774247d6ca
Merge: 2528043 dc622de
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Nov 26 12:18:00 2014 +0000

    Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
    
    The final 2.2 patches from me.
    
    # gpg: Signature made Wed 26 Nov 2014 11:12:25 GMT using RSA key ID 78C7AE83
    # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
    # gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>"
    # gpg: WARNING: This key is not certified with sufficiently trusted signatures!
    # gpg:          It is not certain that the signature belongs to the owner.
    # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
    #      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83
    
    * remotes/bonzini/tags/for-upstream:
      s390x/kvm: Fix compile error
      fw_cfg: fix boot order bug when dynamically modified via QOM
      -machine vmport=auto: Fix handling of VMWare ioport emulation for xen
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit dc622deb2d49aac6afa485f9025be8fed440ef3d
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Wed Nov 26 11:07:24 2014 +0100

    s390x/kvm: Fix compile error
    
    commit a2b257d6212a "memory: expose alignment used for allocating RAM
    as MemoryRegion API" triggered a compile error on KVM/s390x.
    
    Fix the prototype and the implementation of legacy_s390_alloc.
    
    Cc: Igor Mammedov <imammedo@redhat.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit f3b3766899fc0a79a175a5d29d0ff427327cd34a
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Tue Nov 25 12:38:19 2014 +0800

    fw_cfg: fix boot order bug when dynamically modified via QOM
    
    When we dynamically modify boot order, the length of
    boot order will be changed, but we don't update
    s->files->f[i].size with new length. This casuse
    seabios read a wrong vale of qemu cfg file about
    bootorder.
    
    Cc: Gerd Hoffmann <kraxel@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit d1048bef9df0aacde9a54bf9b5b97a6e10950d8c
Author: Don Slutz <dslutz@verizon.com>
Date:   Fri Nov 21 11:18:52 2014 -0500

    -machine vmport=auto: Fix handling of VMWare ioport emulation for xen
    
    c/s 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
    
    or
    
    c/s b154537ad07598377ebf98252fb7d2aff127983b
    
    moved the testing of xen_enabled() from pc_init1() to
    pc_machine_initfn().
    
    xen_enabled() does not return the correct value in
    pc_machine_initfn().
    
    Changed vmport from a bool to an enum.  Added the value "auto" to do
    the old way.  Move check of xen_enabled() back to pc_init1().
    
    Acked-by: Eric Blake <eblake@redhat.com>
    Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
    Signed-off-by: Don Slutz <dslutz@verizon.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 2528043f1f299e0e88cb026f1ca7c40bbb4e1f80
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Nov 25 18:23:54 2014 +0000

    Update version for v2.2.0-rc3 release
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit df5b2adb7398d71016ee469f71e52075ed95e04e
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue Nov 25 14:54:17 2014 +0100

    input: move input-send-event into experimental namespace
    
    Ongoing discussions on how we are going to specify the console,
    so tag the command as experiental so we can refine things in
    the 2.3 development cycle.
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Message-id: 1416923657-10614-1-git-send-email-armbru@redhat.com
    [Spell out "not a stable API", and x- the QAPI schema, too]
    Signed-off-by: Markus Armbruster <armbru@redhat.com>
    Reviewed-by: Amos Kong <akong@redhat.com>
    Reviewed-by: Eric Blake <eblake@redhat.com>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 17:50:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 17: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 1XuPgU-0001Eo-6Q; Fri, 28 Nov 2014 17:50: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@citrix.com>) id 1XuPgS-0001Ej-Ux
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 17:50:21 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	DB/D1-24124-CD5B8745; Fri, 28 Nov 2014 17:50:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417197017!10579048!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22251 invoked from network); 28 Nov 2014 17:50:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 17:50:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,478,1413244800"; d="scan'208";a="197510828"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 12:50:16 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuPgN-0000cR-Ow;
	Fri, 28 Nov 2014 17:50:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuPgN-0005a2-GR;
	Fri, 28 Nov 2014 17:50:15 +0000
Date: Fri, 28 Nov 2014 17:50:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31886-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31886: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31886 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31886/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 31855

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31855

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                490309fcfbed9fa1ed357541f609975016a34628
baseline version:
 qemuu                ca6028185d19d3f2bd331c15175c3ef5afc30c77

------------------------------------------------------------
People who touched revisions under test:
  Christian Borntraeger <borntraeger@de.ibm.com>
  Don Slutz <dslutz@verizon.com>
  Eric Blake <eblake@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Markus Armbruster <armbru@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 490309fcfbed9fa1ed357541f609975016a34628
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Nov 25 18:21:45 2014 +0000

    qemu-timer: Avoid overflows when converting timeout to struct timespec
    
    In qemu_poll_ns(), when we convert an int64_t nanosecond timeout into
    a struct timespec, we may accidentally run into overflow problems if
    the timeout is very long. This happens because the tv_sec field is a
    time_t, which is signed, so we might end up setting it to a negative
    value by mistake. This will result in what was intended to be a
    near-infinite timeout turning into an instantaneous timeout, and we'll
    busy loop. Cap the maximum timeout at INT32_MAX seconds (about 68 years)
    to avoid this problem.
    
    This specifically manifested on ARM hosts as an extreme slowdown on
    guest shutdown (when the guest reprogrammed the PL031 RTC to not
    generate alarms using a very long timeout) but could happen on other
    hosts and guests too.
    
    Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Fam Zheng <famz@redhat.com>
    Message-id: 1416939705-1272-1-git-send-email-peter.maydell@linaro.org

commit 3ef4ebcc5c0360629bb05f49d9b961774247d6ca
Merge: 2528043 dc622de
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Nov 26 12:18:00 2014 +0000

    Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
    
    The final 2.2 patches from me.
    
    # gpg: Signature made Wed 26 Nov 2014 11:12:25 GMT using RSA key ID 78C7AE83
    # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
    # gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>"
    # gpg: WARNING: This key is not certified with sufficiently trusted signatures!
    # gpg:          It is not certain that the signature belongs to the owner.
    # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
    #      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83
    
    * remotes/bonzini/tags/for-upstream:
      s390x/kvm: Fix compile error
      fw_cfg: fix boot order bug when dynamically modified via QOM
      -machine vmport=auto: Fix handling of VMWare ioport emulation for xen
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit dc622deb2d49aac6afa485f9025be8fed440ef3d
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Wed Nov 26 11:07:24 2014 +0100

    s390x/kvm: Fix compile error
    
    commit a2b257d6212a "memory: expose alignment used for allocating RAM
    as MemoryRegion API" triggered a compile error on KVM/s390x.
    
    Fix the prototype and the implementation of legacy_s390_alloc.
    
    Cc: Igor Mammedov <imammedo@redhat.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit f3b3766899fc0a79a175a5d29d0ff427327cd34a
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Tue Nov 25 12:38:19 2014 +0800

    fw_cfg: fix boot order bug when dynamically modified via QOM
    
    When we dynamically modify boot order, the length of
    boot order will be changed, but we don't update
    s->files->f[i].size with new length. This casuse
    seabios read a wrong vale of qemu cfg file about
    bootorder.
    
    Cc: Gerd Hoffmann <kraxel@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit d1048bef9df0aacde9a54bf9b5b97a6e10950d8c
Author: Don Slutz <dslutz@verizon.com>
Date:   Fri Nov 21 11:18:52 2014 -0500

    -machine vmport=auto: Fix handling of VMWare ioport emulation for xen
    
    c/s 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
    
    or
    
    c/s b154537ad07598377ebf98252fb7d2aff127983b
    
    moved the testing of xen_enabled() from pc_init1() to
    pc_machine_initfn().
    
    xen_enabled() does not return the correct value in
    pc_machine_initfn().
    
    Changed vmport from a bool to an enum.  Added the value "auto" to do
    the old way.  Move check of xen_enabled() back to pc_init1().
    
    Acked-by: Eric Blake <eblake@redhat.com>
    Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
    Signed-off-by: Don Slutz <dslutz@verizon.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 2528043f1f299e0e88cb026f1ca7c40bbb4e1f80
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Nov 25 18:23:54 2014 +0000

    Update version for v2.2.0-rc3 release
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit df5b2adb7398d71016ee469f71e52075ed95e04e
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue Nov 25 14:54:17 2014 +0100

    input: move input-send-event into experimental namespace
    
    Ongoing discussions on how we are going to specify the console,
    so tag the command as experiental so we can refine things in
    the 2.3 development cycle.
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Message-id: 1416923657-10614-1-git-send-email-armbru@redhat.com
    [Spell out "not a stable API", and x- the QAPI schema, too]
    Signed-off-by: Markus Armbruster <armbru@redhat.com>
    Reviewed-by: Amos Kong <akong@redhat.com>
    Reviewed-by: Eric Blake <eblake@redhat.com>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 19:01:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 19:01:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuQmf-0002us-Ts; Fri, 28 Nov 2014 19:00:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuQme-0002un-6R
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 19:00:48 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	51/B2-27623-F56C8745; Fri, 28 Nov 2014 19:00:47 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417201244!14561938!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27196 invoked from network); 28 Nov 2014 19:00:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 19:00:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,478,1413244800"; d="scan'208";a="197525331"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 14:00:39 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuQmV-0003cz-FC;
	Fri, 28 Nov 2014 19:00:39 +0000
Date: Fri, 28 Nov 2014 19:00:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <1868834068.20141128184004@eikelenboom.it>
Message-ID: <alpine.DEB.2.02.1411281858210.14135@kaball.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
	<20141128164935.GA17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
	<20141128170116.GB17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281705050.14135@kaball.uk.xensource.com>
	<1868834068.20141128184004@eikelenboom.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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 Fri, 28 Nov 2014, Sander Eikelenboom wrote:
> Friday, November 28, 2014, 6:09:52 PM, you wrote:
> 
> > On Fri, 28 Nov 2014, Wei Liu wrote:
> >> On Fri, Nov 28, 2014 at 04:54:19PM +0000, Stefano Stabellini wrote:
> >> > On Fri, 28 Nov 2014, Wei Liu wrote:
> >> > > On Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
> >> > > > create ^
> >> > > > title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
> >> > > > thanks
> >> > > > 
> >> > > > On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> >> > > > > Hi,
> >> > > > > 
> >> > > > > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> >> > > > > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> >> > > > > xl didn't show any problems on the commandline so i never drawed much attention 
> >> > > > > to it, but /var/log/xen/xl-guest.log shows:
> >> > > > > 
> >> > > > >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
> >> > > > >     Domain 19 has shut down, reason code 0 0x0
> >> > > > >     Action for shutdown reason code 0 is destroy
> >> > > > >     Domain 19 needs to be cleaned up: destroying the domain
> >> > > > >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
> >> > > > >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
> >> > > > >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
> >> > > > >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
> >> > > > >     Done. Exiting now
> >> > > > > 
> >> > > > > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> >> > > > > 
> >> > > > > --
> >> > > 
> >> > > It's worth checking whether the device model exits too early, i.e., did
> >> > > it crash? What's in the DM log?
> >> > 
> >> > Firstly I was thinking that if force=1 it makes sense to continue even
> >> > when QEMU returns error, see:
> >> > 
> >> > http://marc.info/?i=alpine.DEB.2.02.1411281648500.14135%40kaball.uk.xensource.com
> >> 
> >> In normal case DM is not destroyed until PCI device is removed. So I
> >> think the real issue is DM crashed.
> 
> > I don't think it crashed: QEMU detects that domain shutdown has been
> > called and exits.
> > See:
> 
> > static void main_loop(void)
> > {
> >     bool nonblocking;
> >     int last_io = 0;
> > #ifdef CONFIG_PROFILER
> >     int64_t ti;
> > #endif
> >     do {
> 
> > [...]
> 
> >     } while (!main_loop_should_exit());
> > }
> 
> 
> > main_loop_should_exit returns true when qemu_shutdown_requested().
> 
> 
> >> libxl.c:
> >> 1571     if (libxl__device_pci_destroy_all(gc, domid) < 0)
> >> 1572         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
> >> 1573     rc = xc_domain_pause(ctx->xch, domid);
> >> 1574     if (rc < 0) {
> >> 1575         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
> >> 1576     }
> >> 1577     if (dm_present) {
> >> 1578         if (libxl__destroy_device_model(gc, domid) < 0)
> >> 1579             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
> >> 1580
> >> 1581         libxl__qmp_cleanup(gc, domid);
> >> 1582     }
> >> 
> >> The patch you posted covers up the real issue.
> 
> > That is true, but I think the patch is correct regardless of the issue.
> 
> Hmm how about qemu's "-no-shutdown" option ?
> >From the manpage:
> -no-shutdown
>     Don't exit QEMU on guest shutdown, but instead only stop the emulation. This allows for instance switching to monitor to commit changes to the disk image. 
> 
> with:
> device_model_args_hvm = [ '-no-shutdown' ]
> 
> I get:
> 
> /var/log/xen/xl-tv.log:
> 
> Waiting for domain tv (domid 18) to die [pid 18587]
> Domain 18 has shut down, reason code 0 0x0
> Action for shutdown reason code 0 is destroy
> Domain 18 needs to be cleaned up: destroying the domain
> libxl: error: libxl_pci.c:1299:do_pci_remove: xc_domain_irq_permission irq=40: Invalid argument

Thanks for testing! The suggestion might be a good idea, but I am not
sure whether it is suitable given the stage of the release cycle. I
would wait until 4.6 before making that change.

Regarding the xc_domain_irq_permission error, it is just a matter of
calling xc_physdev_unmap_pirq after xc_domain_irq_permission:


diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 316643c..904d255 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1288,14 +1290,14 @@ skip1:
             goto out;
         }
         if ((fscanf(f, "%u", &irq) == 1) && irq) {
-            rc = xc_physdev_unmap_pirq(ctx->xch, domid, irq);
-            if (rc < 0) {
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_physdev_unmap_pirq irq=%d", irq);
-            }
             rc = xc_domain_irq_permission(ctx->xch, domid, irq, 0);
             if (rc < 0) {
                 LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_domain_irq_permission irq=%d", irq);
             }
+            rc = xc_physdev_unmap_pirq(ctx->xch, domid, irq);
+            if (rc < 0) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_physdev_unmap_pirq irq=%d", irq);
+            }
         }
         fclose(f);
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 19:01:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 19:01:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuQmf-0002us-Ts; Fri, 28 Nov 2014 19:00:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XuQme-0002un-6R
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 19:00:48 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	51/B2-27623-F56C8745; Fri, 28 Nov 2014 19:00:47 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417201244!14561938!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27196 invoked from network); 28 Nov 2014 19:00:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 19:00:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,478,1413244800"; d="scan'208";a="197525331"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Fri, 28 Nov 2014 14:00:39 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XuQmV-0003cz-FC;
	Fri, 28 Nov 2014 19:00:39 +0000
Date: Fri, 28 Nov 2014 19:00:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <1868834068.20141128184004@eikelenboom.it>
Message-ID: <alpine.DEB.2.02.1411281858210.14135@kaball.uk.xensource.com>
References: <4610426124.20141126210436@eikelenboom.it>
	<alpine.DEB.2.02.1411281507510.14135@kaball.uk.xensource.com>
	<20141128164935.GA17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281653240.14135@kaball.uk.xensource.com>
	<20141128170116.GB17910@zion.uk.xensource.com>
	<alpine.DEB.2.02.1411281705050.14135@kaball.uk.xensource.com>
	<1868834068.20141128184004@eikelenboom.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: problems with qmp socket error in
 libxl_pci teardown path for HVM guest with 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 Fri, 28 Nov 2014, Sander Eikelenboom wrote:
> Friday, November 28, 2014, 6:09:52 PM, you wrote:
> 
> > On Fri, 28 Nov 2014, Wei Liu wrote:
> >> On Fri, Nov 28, 2014 at 04:54:19PM +0000, Stefano Stabellini wrote:
> >> > On Fri, 28 Nov 2014, Wei Liu wrote:
> >> > > On Fri, Nov 28, 2014 at 03:08:51PM +0000, Stefano Stabellini wrote:
> >> > > > create ^
> >> > > > title it QMP connection problems prevent libxl from calling libxl__device_pci_reset on domain shutdown
> >> > > > thanks
> >> > > > 
> >> > > > On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> >> > > > > Hi,
> >> > > > > 
> >> > > > > While testing a patch for Konrad i was wondering why "libxl_pci.c: libxl__device_pci_reset()"
> >> > > > > doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci passthrough.
> >> > > > > xl didn't show any problems on the commandline so i never drawed much attention 
> >> > > > > to it, but /var/log/xen/xl-guest.log shows:
> >> > > > > 
> >> > > > >     Waiting for domain xbmc13sid (domid 19) to die [pid 20450]
> >> > > > >     Domain 19 has shut down, reason code 0 0x0
> >> > > > >     Action for shutdown reason code 0 is destroy
> >> > > > >     Domain 19 needs to be cleaned up: destroying the domain
> >> > > > >     libxl: error: libxl_qmp.c:443:qmp_next: Socket read error: Connection reset by peer
> >> > > > >     libxl: error: libxl_qmp.c:701:libxl__qmp_initialize: Failed to connect to QMP
> >> > > > >     libxl: error: libxl_pci.c:1242:do_pci_remove: libxl__qmp_pci_del: Connection reset by peer
> >> > > > >     libxl: error: libxl_dm.c:1575:kill_device_model: Device Model already exited
> >> > > > >     Done. Exiting now
> >> > > > > 
> >> > > > > So it doesn't even get to calling  "libxl_pci.c: libxl__device_pci_reset()".
> >> > > > > 
> >> > > > > --
> >> > > 
> >> > > It's worth checking whether the device model exits too early, i.e., did
> >> > > it crash? What's in the DM log?
> >> > 
> >> > Firstly I was thinking that if force=1 it makes sense to continue even
> >> > when QEMU returns error, see:
> >> > 
> >> > http://marc.info/?i=alpine.DEB.2.02.1411281648500.14135%40kaball.uk.xensource.com
> >> 
> >> In normal case DM is not destroyed until PCI device is removed. So I
> >> think the real issue is DM crashed.
> 
> > I don't think it crashed: QEMU detects that domain shutdown has been
> > called and exits.
> > See:
> 
> > static void main_loop(void)
> > {
> >     bool nonblocking;
> >     int last_io = 0;
> > #ifdef CONFIG_PROFILER
> >     int64_t ti;
> > #endif
> >     do {
> 
> > [...]
> 
> >     } while (!main_loop_should_exit());
> > }
> 
> 
> > main_loop_should_exit returns true when qemu_shutdown_requested().
> 
> 
> >> libxl.c:
> >> 1571     if (libxl__device_pci_destroy_all(gc, domid) < 0)
> >> 1572         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
> >> 1573     rc = xc_domain_pause(ctx->xch, domid);
> >> 1574     if (rc < 0) {
> >> 1575         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
> >> 1576     }
> >> 1577     if (dm_present) {
> >> 1578         if (libxl__destroy_device_model(gc, domid) < 0)
> >> 1579             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
> >> 1580
> >> 1581         libxl__qmp_cleanup(gc, domid);
> >> 1582     }
> >> 
> >> The patch you posted covers up the real issue.
> 
> > That is true, but I think the patch is correct regardless of the issue.
> 
> Hmm how about qemu's "-no-shutdown" option ?
> >From the manpage:
> -no-shutdown
>     Don't exit QEMU on guest shutdown, but instead only stop the emulation. This allows for instance switching to monitor to commit changes to the disk image. 
> 
> with:
> device_model_args_hvm = [ '-no-shutdown' ]
> 
> I get:
> 
> /var/log/xen/xl-tv.log:
> 
> Waiting for domain tv (domid 18) to die [pid 18587]
> Domain 18 has shut down, reason code 0 0x0
> Action for shutdown reason code 0 is destroy
> Domain 18 needs to be cleaned up: destroying the domain
> libxl: error: libxl_pci.c:1299:do_pci_remove: xc_domain_irq_permission irq=40: Invalid argument

Thanks for testing! The suggestion might be a good idea, but I am not
sure whether it is suitable given the stage of the release cycle. I
would wait until 4.6 before making that change.

Regarding the xc_domain_irq_permission error, it is just a matter of
calling xc_physdev_unmap_pirq after xc_domain_irq_permission:


diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 316643c..904d255 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1288,14 +1290,14 @@ skip1:
             goto out;
         }
         if ((fscanf(f, "%u", &irq) == 1) && irq) {
-            rc = xc_physdev_unmap_pirq(ctx->xch, domid, irq);
-            if (rc < 0) {
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_physdev_unmap_pirq irq=%d", irq);
-            }
             rc = xc_domain_irq_permission(ctx->xch, domid, irq, 0);
             if (rc < 0) {
                 LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_domain_irq_permission irq=%d", irq);
             }
+            rc = xc_physdev_unmap_pirq(ctx->xch, domid, irq);
+            if (rc < 0) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_physdev_unmap_pirq irq=%d", irq);
+            }
         }
         fclose(f);
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 21:51:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 21:51:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuTRT-0006YL-0G; Fri, 28 Nov 2014 21:51:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XuTRR-0006YG-4p
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 21:51:05 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	C4/D8-26858-84EE8745; Fri, 28 Nov 2014 21:51:04 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417211463!14642547!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18788 invoked from network); 28 Nov 2014 21:51:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 21:51:03 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3F411ABCA;
	Fri, 28 Nov 2014 21:51:02 +0000 (UTC)
Date: Fri, 28 Nov 2014 22:51:01 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141128215101.GW25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<54777277.5040401@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54777277.5040401@citrix.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Juergen Gross <jgross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Borislav Petkov <bp@suse.de>, Olaf Hering <ohering@suse.de>,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after
	private	hypercall when non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 27, 2014 at 06:50:31PM +0000, Andrew Cooper wrote:
> On 27/11/14 18:36, Luis R. Rodriguez wrote:
> > On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
> >> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
> >>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >>>
> >>> Some folks had reported that some xen hypercalls take a long time
> >>> to complete when issued from the userspace private ioctl mechanism,
> >>> this can happen for instance with some hypercalls that have many
> >>> sub-operations, this can happen for instance on hypercalls that use
> >>> multi-call feature whereby Xen lets one hypercall batch out a series
> >>> of other hypercalls on the hypervisor. At times such hypercalls can
> >>> even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
> >>> 120 seconds), this a non-issue issue on preemptible kernels though as
> >>> the kernel may deschedule such long running tasks. Xen for instance
> >>> supports multicalls to be preempted as well, this is what Xen calls
> >>> continuation (see xen commit 42217cbc5b which introduced this [0]).
> >>> On systems without CONFIG_PREEMPT though -- a kernel with voluntary
> >>> or no preemption -- a long running hypercall will not be descheduled
> >>> until the hypercall is complete and the ioctl returns to user space.
> >>>
> >>> To help with this David had originally implemented support for use
> >>> of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
> >>> solution never went upstream though and upon review to help refactor
> >>> this I've concluded that usage of preempt_schedule_irq() would be
> >>> a bit abussive of existing APIs -- for a few reasons:
> >>>
> >>> 0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels
> >>>
> >>> 1) we want try to consider solutions that might work for other
> >>>     hypervisors for this same problem, and identify it its an issue
> >>>     even present on other hypervisors or if this is a self
> >>>     inflicted architectural issue caused by use of multicalls
> >>>
> >>> 2) there is no documentation or profiling of the exact hypercalls
> >>>     that were causing these issues, nor do we have any context
> >>>     to help evaluate this any further
> >>>
> >>> I at least checked with kvm folks and it seems hypercall preemption
> >>> is not needed there. We can survey other hypervisors...
> >>>
> >>> If 'something like preemption' is needed then CONFIG_PREEMPT
> >>> should just be enabled and encouraged, it seems we want to
> >>> encourage CONFIG_PREEMPT on xen, specially when multicalls are
> >>> used. In the meantime this tries to address a solution to help
> >>> xen on non CONFIG_PREEMPT kernels.
> >>>
> >>> One option tested and evaluated was to put private hypercalls in
> >>> process context, however this would introduce complexities such
> >>> originating hypercalls from different contexts. Current xen
> >>> hypercall callback handlers would need to be changed per architecture,
> >>> for instance, we'd also incur the cost of switching states from
> >>> user / kernel (this cost is also present if preempt_schedule_irq()
> >>> is used). There may be other issues which could be introduced with
> >>> this strategy as well. The simplest *shared* alternative is instead
> >>> to just explicitly schedule() at the end of a private hypercall on non
> >>> preempt kernels. This forces our private hypercall call mechanism
> >>> to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
> >>> more context switch but keeps the private hypercall context intact.
> >>>
> >>> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
> >>> [1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
> >>>
> >>> Cc: Davidlohr Bueso <dbueso@suse.de>
> >>> Cc: Joerg Roedel <jroedel@suse.de>
> >>> Cc: Borislav Petkov <bp@suse.de>
> >>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>> Cc: Jan Beulich <JBeulich@suse.com>
> >>> Cc: Juergen Gross <JGross@suse.com>
> >>> Cc: Olaf Hering <ohering@suse.de>
> >>> Cc: David Vrabel <david.vrabel@citrix.com>
> >>> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> >>> ---
> >>>   drivers/xen/privcmd.c | 3 +++
> >>>   1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> >>> index 569a13b..e29edba 100644
> >>> --- a/drivers/xen/privcmd.c
> >>> +++ b/drivers/xen/privcmd.c
> >>> @@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
> >>>   			   hypercall.arg[0], hypercall.arg[1],
> >>>   			   hypercall.arg[2], hypercall.arg[3],
> >>>   			   hypercall.arg[4]);
> >>> +#ifndef CONFIG_PREEMPT
> >>> +	schedule();
> >>> +#endif
> >>>
> >>>   	return ret;
> >>>   }
> >>>
> >> Sorry, I don't think this will solve anything. You're calling schedule()
> >> right after the long running hypercall just nanoseconds before returning
> >> to the user.
> > Yeah, well that is what [1] tried as well only it tried using
> > preempt_schedule_irq() on the hypercall callback...
> >
> >> I suppose you were mislead by the "int 0x82" in [0]. This is the
> >> hypercall from the kernel into the hypervisor, e.g. inside of
> >> privcmd_call().
> > Nope, you have to consider what was done in [1], I was trying to
> > do something similar but less complex that didn't involve mucking
> > with the callbacks but also not abusing APIs.
> >
> > I'm afraid we don't have much leg room.
> 
> XenServer uses
> 
> https://github.com/xenserver/linux-3.x.pg/blob/master/master/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
> 
> to deal with these issues.  That patch is based on 3.10.
> 
> I can remember whether this has been submitted upstream before (and
> there were outstanding issues), or whether it fell at an inconvenient
> time with our development cycles.
> 
> David: do you recall?

This was precicely the patch I reviewed in [1].

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 21:51:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 21:51:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuTRT-0006YL-0G; Fri, 28 Nov 2014 21:51:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XuTRR-0006YG-4p
	for xen-devel@lists.xenproject.org; Fri, 28 Nov 2014 21:51:05 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	C4/D8-26858-84EE8745; Fri, 28 Nov 2014 21:51:04 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417211463!14642547!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18788 invoked from network); 28 Nov 2014 21:51:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2014 21:51:03 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3F411ABCA;
	Fri, 28 Nov 2014 21:51:02 +0000 (UTC)
Date: Fri, 28 Nov 2014 22:51:01 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141128215101.GW25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<54777277.5040401@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54777277.5040401@citrix.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Juergen Gross <jgross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	david.vrabel@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Borislav Petkov <bp@suse.de>, Olaf Hering <ohering@suse.de>,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after
	private	hypercall when non CONFIG_PREEMPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Nov 27, 2014 at 06:50:31PM +0000, Andrew Cooper wrote:
> On 27/11/14 18:36, Luis R. Rodriguez wrote:
> > On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
> >> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
> >>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >>>
> >>> Some folks had reported that some xen hypercalls take a long time
> >>> to complete when issued from the userspace private ioctl mechanism,
> >>> this can happen for instance with some hypercalls that have many
> >>> sub-operations, this can happen for instance on hypercalls that use
> >>> multi-call feature whereby Xen lets one hypercall batch out a series
> >>> of other hypercalls on the hypervisor. At times such hypercalls can
> >>> even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
> >>> 120 seconds), this a non-issue issue on preemptible kernels though as
> >>> the kernel may deschedule such long running tasks. Xen for instance
> >>> supports multicalls to be preempted as well, this is what Xen calls
> >>> continuation (see xen commit 42217cbc5b which introduced this [0]).
> >>> On systems without CONFIG_PREEMPT though -- a kernel with voluntary
> >>> or no preemption -- a long running hypercall will not be descheduled
> >>> until the hypercall is complete and the ioctl returns to user space.
> >>>
> >>> To help with this David had originally implemented support for use
> >>> of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
> >>> solution never went upstream though and upon review to help refactor
> >>> this I've concluded that usage of preempt_schedule_irq() would be
> >>> a bit abussive of existing APIs -- for a few reasons:
> >>>
> >>> 0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels
> >>>
> >>> 1) we want try to consider solutions that might work for other
> >>>     hypervisors for this same problem, and identify it its an issue
> >>>     even present on other hypervisors or if this is a self
> >>>     inflicted architectural issue caused by use of multicalls
> >>>
> >>> 2) there is no documentation or profiling of the exact hypercalls
> >>>     that were causing these issues, nor do we have any context
> >>>     to help evaluate this any further
> >>>
> >>> I at least checked with kvm folks and it seems hypercall preemption
> >>> is not needed there. We can survey other hypervisors...
> >>>
> >>> If 'something like preemption' is needed then CONFIG_PREEMPT
> >>> should just be enabled and encouraged, it seems we want to
> >>> encourage CONFIG_PREEMPT on xen, specially when multicalls are
> >>> used. In the meantime this tries to address a solution to help
> >>> xen on non CONFIG_PREEMPT kernels.
> >>>
> >>> One option tested and evaluated was to put private hypercalls in
> >>> process context, however this would introduce complexities such
> >>> originating hypercalls from different contexts. Current xen
> >>> hypercall callback handlers would need to be changed per architecture,
> >>> for instance, we'd also incur the cost of switching states from
> >>> user / kernel (this cost is also present if preempt_schedule_irq()
> >>> is used). There may be other issues which could be introduced with
> >>> this strategy as well. The simplest *shared* alternative is instead
> >>> to just explicitly schedule() at the end of a private hypercall on non
> >>> preempt kernels. This forces our private hypercall call mechanism
> >>> to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
> >>> more context switch but keeps the private hypercall context intact.
> >>>
> >>> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
> >>> [1] http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
> >>>
> >>> Cc: Davidlohr Bueso <dbueso@suse.de>
> >>> Cc: Joerg Roedel <jroedel@suse.de>
> >>> Cc: Borislav Petkov <bp@suse.de>
> >>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>> Cc: Jan Beulich <JBeulich@suse.com>
> >>> Cc: Juergen Gross <JGross@suse.com>
> >>> Cc: Olaf Hering <ohering@suse.de>
> >>> Cc: David Vrabel <david.vrabel@citrix.com>
> >>> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> >>> ---
> >>>   drivers/xen/privcmd.c | 3 +++
> >>>   1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> >>> index 569a13b..e29edba 100644
> >>> --- a/drivers/xen/privcmd.c
> >>> +++ b/drivers/xen/privcmd.c
> >>> @@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
> >>>   			   hypercall.arg[0], hypercall.arg[1],
> >>>   			   hypercall.arg[2], hypercall.arg[3],
> >>>   			   hypercall.arg[4]);
> >>> +#ifndef CONFIG_PREEMPT
> >>> +	schedule();
> >>> +#endif
> >>>
> >>>   	return ret;
> >>>   }
> >>>
> >> Sorry, I don't think this will solve anything. You're calling schedule()
> >> right after the long running hypercall just nanoseconds before returning
> >> to the user.
> > Yeah, well that is what [1] tried as well only it tried using
> > preempt_schedule_irq() on the hypercall callback...
> >
> >> I suppose you were mislead by the "int 0x82" in [0]. This is the
> >> hypercall from the kernel into the hypervisor, e.g. inside of
> >> privcmd_call().
> > Nope, you have to consider what was done in [1], I was trying to
> > do something similar but less complex that didn't involve mucking
> > with the callbacks but also not abusing APIs.
> >
> > I'm afraid we don't have much leg room.
> 
> XenServer uses
> 
> https://github.com/xenserver/linux-3.x.pg/blob/master/master/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
> 
> to deal with these issues.  That patch is based on 3.10.
> 
> I can remember whether this has been submitted upstream before (and
> there were outstanding issues), or whether it fell at an inconvenient
> time with our development cycles.
> 
> David: do you recall?

This was precicely the patch I reviewed in [1].

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 22:46:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 22:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuUIP-0007ts-Bg; Fri, 28 Nov 2014 22:45: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@citrix.com>) id 1XuUIN-0007tn-4E
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 22:45:47 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	A0/AE-01660-A1BF8745; Fri, 28 Nov 2014 22:45:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417214744!10602975!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28266 invoked from network); 28 Nov 2014 22:45:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 22:45:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,479,1413244800"; d="scan'208";a="197841983"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 17:45:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuUII-00022P-7o;
	Fri, 28 Nov 2014 22:45:42 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuUIH-000062-MP;
	Fri, 28 Nov 2014 22:45:41 +0000
Date: Fri, 28 Nov 2014 22:45:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31889-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31889: 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 31889 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31889/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl           3 host-install(3)           broken pass in 31864
 test-amd64-i386-xl-winxpsp3   3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-libvirt       3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-xl-qemut-win7-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-libvirt      3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-freebsd10-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-win7-amd64  3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl           3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl            3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 31864 pass in 31889
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 31864 pass in 31889

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 31864 like 26303
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 31864 blocked in 26303
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 31864 blocked in 26303
 test-amd64-amd64-rumpuserxen-amd64 3 host-install(3) broken in 31864 blocked in 26303
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 31864 blocked in 26303
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 31864 blocked in 26303
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 31864 like 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-xl           5 xen-boot              fail in 31864 never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-armhf-armhf-xl host-install(3)

Not pushing.

(No revision log; it would be 33063 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Nov 28 22:46:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Nov 2014 22:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XuUIP-0007ts-Bg; Fri, 28 Nov 2014 22:45: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@citrix.com>) id 1XuUIN-0007tn-4E
	for xen-devel@lists.xensource.com; Fri, 28 Nov 2014 22:45:47 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	A0/AE-01660-A1BF8745; Fri, 28 Nov 2014 22:45:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417214744!10602975!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28266 invoked from network); 28 Nov 2014 22:45:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2014 22:45:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,479,1413244800"; d="scan'208";a="197841983"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 17:45:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuUII-00022P-7o;
	Fri, 28 Nov 2014 22:45:42 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuUIH-000062-MP;
	Fri, 28 Nov 2014 22:45:41 +0000
Date: Fri, 28 Nov 2014 22:45:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31889-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31889: 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 31889 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31889/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl           3 host-install(3)           broken pass in 31864
 test-amd64-i386-xl-winxpsp3   3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-libvirt       3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-xl-qemut-win7-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-libvirt      3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-freebsd10-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-win7-amd64  3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl           3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl            3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 31864 pass in 31889
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken in 31864 pass in 31889
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 31864 pass in 31889
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 31864 pass in 31889

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 31864 like 26303
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 31864 blocked in 26303
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 31864 blocked in 26303
 test-amd64-amd64-rumpuserxen-amd64 3 host-install(3) broken in 31864 blocked in 26303
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 31864 blocked in 26303
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 31864 blocked in 26303
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 31864 like 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-xl           5 xen-boot              fail in 31864 never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-armhf-armhf-xl host-install(3)

Not pushing.

(No revision log; it would be 33063 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 Nov 29 02:01:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 02: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 1XuXLC-0008BZ-WD; Sat, 29 Nov 2014 02:00:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XuXLB-0008BU-2l
	for xen-devel@lists.xen.org; Sat, 29 Nov 2014 02:00:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DC/71-09842-4D829745; Sat, 29 Nov 2014 02:00:52 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417226450!12180834!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19466 invoked from network); 29 Nov 2014 02:00:51 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-4.tower-21.messagelabs.com with SMTP;
	29 Nov 2014 02:00:51 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sAT20gUk024860;
	Fri, 28 Nov 2014 20:00:42 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sAT20e64024859;
	Fri, 28 Nov 2014 20:00:40 -0600
Date: Fri, 28 Nov 2014 20:00:40 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201411290200.sAT20e64024859@wind.enjellic.com>
In-Reply-To: Sander Eikelenboom <linux@eikelenboom.it>
	"Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind." (Nov
	27, 12:11pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Sander Eikelenboom <linux@eikelenboom.it>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Fri, 28 Nov 2014 20:00:42 -0600 (CST)
Cc: greg@enjellic.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Nov 27, 12:11pm, Sander Eikelenboom wrote:
} Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.

Hi, hope the week has gone well for everyone.

> > So we are obviously working with qemu-dm-traditional and with the
> > IGD/LVDS BIOS configuration issue fixed the adapater passthrough is
> > working and Windows7 is coming up and detecting the IGD as a standard
> > VGA display adapter.  Additional invocations of the VM after the first
> > one result in failed passthrough with a garbled display.

> This is probably due to the current lack of slot/bus reset in
> xen-pciback, Konrad has a preliminary kernel patch for xen-pciback
> that does this.  I have attached the patch, though it has some rough
> edges in the design :-)
>
> I'm currently running with his 3.19 xen-pciback patches series + the
> preliminary patch for slot/bus reset and rebooting a guest with
> vga/pci passthrough now works. (i'm running with a radeon card,
> passed through as a secondary card to the emulated qemu one, in a
> linux guest using qemu-xen, so i can't help you with your other
> questions and problems).

Thanks for taking the time for respond and forward along the patch.

I back ported the do_flr patch into the 3.14.x kernel and spent some
time working with it.  I thought it might be useful to others to
document what we ran into.

First of all the issue with the unsuccessful boot of Windows after the
first invocation doesn't appear to have anything to do with resetting
the card.  This was fixed by installing the most recent version of the
Intel HD drivers in the Windows guest.

If IGD passthrough is done without the HD drivers Windows 7 appears to
use its standard VGA driver which seems to be able to initialize and
run the IGD device but does not appear to shutdown the device in a
manner in which it can be re-started.  After the first invocation of
the guest is shutdown the screen goes to a solid color.  Subsequent
invocations result in the flashing multi-color screens which others
have documented.

With the HD drivers installed IGD passthrough works fine through
multiple invocations of a guest with the stock xen-pciback in 3.14.x.
We ran 40-50 repetitive Windows guest invocations and every one was
completely deterministic.

That being said we ran into an issue which we wanted to bounce off the
list in the context of this thread.

One of the things we were not able to do was to successfuly re-start
the IGD display for dom0.  After spending a lot of time going through
Konrad's reset code it appears the IGD devices in the Q77 and Q87
chipset implementations we are looking at are not advertising reset
functions which can be used.

It appears that the IGD devices are advertising that they need a
Device Specific Initialization (DSI) sequence in order to be enabled
or powered up, if we interpret the output of lscpi properly, ie:

---------------------------------------------------------------------------
00:02.0 VGA compatible controller: Intel Corporation Device 0152 (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Intel Corporation Device 2036
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
        Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at f000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Mask- 64bit- Count=1/1 Enable-
                Address: 00000000  Data: 0000
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a4] PCIe advanced features <?>
---------------------------------------------------------------------------

The ATI adapters which we have a lot of passthrough experience with
are FLR capable and can be re-enabled after passthrough by writing a
'1' to the enable pseudo-file in the /sys/bus/pci/devices/BDF
directory.  The IGD adapters seem to fail to respond to a request to
be re-enabled.

We would certainly be interested in any suggestions the collective may
have with respect to how to get the adapter turned back on and/or
implement a reset.

> Sander

Have a good weekend.

Greg

}-- End of excerpt from Sander Eikelenboom

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Laugh now but you won't be laughing when we find you laying on the
 side of the road dead."
                                -- Betty Wettstein
                                   At the Lake

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 02:01:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 02: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 1XuXLC-0008BZ-WD; Sat, 29 Nov 2014 02:00:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XuXLB-0008BU-2l
	for xen-devel@lists.xen.org; Sat, 29 Nov 2014 02:00:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DC/71-09842-4D829745; Sat, 29 Nov 2014 02:00:52 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417226450!12180834!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19466 invoked from network); 29 Nov 2014 02:00:51 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-4.tower-21.messagelabs.com with SMTP;
	29 Nov 2014 02:00:51 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sAT20gUk024860;
	Fri, 28 Nov 2014 20:00:42 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sAT20e64024859;
	Fri, 28 Nov 2014 20:00:40 -0600
Date: Fri, 28 Nov 2014 20:00:40 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201411290200.sAT20e64024859@wind.enjellic.com>
In-Reply-To: Sander Eikelenboom <linux@eikelenboom.it>
	"Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind." (Nov
	27, 12:11pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Sander Eikelenboom <linux@eikelenboom.it>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Fri, 28 Nov 2014 20:00:42 -0600 (CST)
Cc: greg@enjellic.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Nov 27, 12:11pm, Sander Eikelenboom wrote:
} Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.

Hi, hope the week has gone well for everyone.

> > So we are obviously working with qemu-dm-traditional and with the
> > IGD/LVDS BIOS configuration issue fixed the adapater passthrough is
> > working and Windows7 is coming up and detecting the IGD as a standard
> > VGA display adapter.  Additional invocations of the VM after the first
> > one result in failed passthrough with a garbled display.

> This is probably due to the current lack of slot/bus reset in
> xen-pciback, Konrad has a preliminary kernel patch for xen-pciback
> that does this.  I have attached the patch, though it has some rough
> edges in the design :-)
>
> I'm currently running with his 3.19 xen-pciback patches series + the
> preliminary patch for slot/bus reset and rebooting a guest with
> vga/pci passthrough now works. (i'm running with a radeon card,
> passed through as a secondary card to the emulated qemu one, in a
> linux guest using qemu-xen, so i can't help you with your other
> questions and problems).

Thanks for taking the time for respond and forward along the patch.

I back ported the do_flr patch into the 3.14.x kernel and spent some
time working with it.  I thought it might be useful to others to
document what we ran into.

First of all the issue with the unsuccessful boot of Windows after the
first invocation doesn't appear to have anything to do with resetting
the card.  This was fixed by installing the most recent version of the
Intel HD drivers in the Windows guest.

If IGD passthrough is done without the HD drivers Windows 7 appears to
use its standard VGA driver which seems to be able to initialize and
run the IGD device but does not appear to shutdown the device in a
manner in which it can be re-started.  After the first invocation of
the guest is shutdown the screen goes to a solid color.  Subsequent
invocations result in the flashing multi-color screens which others
have documented.

With the HD drivers installed IGD passthrough works fine through
multiple invocations of a guest with the stock xen-pciback in 3.14.x.
We ran 40-50 repetitive Windows guest invocations and every one was
completely deterministic.

That being said we ran into an issue which we wanted to bounce off the
list in the context of this thread.

One of the things we were not able to do was to successfuly re-start
the IGD display for dom0.  After spending a lot of time going through
Konrad's reset code it appears the IGD devices in the Q77 and Q87
chipset implementations we are looking at are not advertising reset
functions which can be used.

It appears that the IGD devices are advertising that they need a
Device Specific Initialization (DSI) sequence in order to be enabled
or powered up, if we interpret the output of lscpi properly, ie:

---------------------------------------------------------------------------
00:02.0 VGA compatible controller: Intel Corporation Device 0152 (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Intel Corporation Device 2036
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
        Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at f000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Mask- 64bit- Count=1/1 Enable-
                Address: 00000000  Data: 0000
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a4] PCIe advanced features <?>
---------------------------------------------------------------------------

The ATI adapters which we have a lot of passthrough experience with
are FLR capable and can be re-enabled after passthrough by writing a
'1' to the enable pseudo-file in the /sys/bus/pci/devices/BDF
directory.  The IGD adapters seem to fail to respond to a request to
be re-enabled.

We would certainly be interested in any suggestions the collective may
have with respect to how to get the adapter turned back on and/or
implement a reset.

> Sander

Have a good weekend.

Greg

}-- End of excerpt from Sander Eikelenboom

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Laugh now but you won't be laughing when we find you laying on the
 side of the road dead."
                                -- Betty Wettstein
                                   At the Lake

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 04:45:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 04: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 1XuZtx-0003Aq-Ox; Sat, 29 Nov 2014 04:44:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuZtw-0003Al-8C
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 04:44:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D3/A8-25276-74F49745; Sat, 29 Nov 2014 04:44:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417236293!12249452!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30598 invoked from network); 29 Nov 2014 04:44:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 04:44:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,481,1413244800"; d="scan'208";a="197606995"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 23:44:51 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuZtr-0003mI-JB;
	Sat, 29 Nov 2014 04:44:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuZtq-0007lp-OU;
	Sat, 29 Nov 2014 04:44:50 +0000
Date: Sat, 29 Nov 2014 04:44:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31890-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31890: 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 31890 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31890/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-i386-xl           11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-armhf-armhf-xl           3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                3314bf6ba2ac8f1a2dd0d55a980835a258f1a45d
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
654 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          broken  
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-armhf-armhf-xl host-install(3)

Not pushing.

(No revision log; it would be 27893 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 Nov 29 04:45:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 04: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 1XuZtx-0003Aq-Ox; Sat, 29 Nov 2014 04:44:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuZtw-0003Al-8C
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 04:44:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D3/A8-25276-74F49745; Sat, 29 Nov 2014 04:44:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417236293!12249452!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30598 invoked from network); 29 Nov 2014 04:44:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 04:44:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,481,1413244800"; d="scan'208";a="197606995"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Fri, 28 Nov 2014 23:44:51 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuZtr-0003mI-JB;
	Sat, 29 Nov 2014 04:44:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuZtq-0007lp-OU;
	Sat, 29 Nov 2014 04:44:50 +0000
Date: Sat, 29 Nov 2014 04:44:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31890-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31890: 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 31890 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31890/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-i386-xl           11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-armhf-armhf-xl           3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                3314bf6ba2ac8f1a2dd0d55a980835a258f1a45d
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
654 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          broken  
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-armhf-armhf-xl host-install(3)

Not pushing.

(No revision log; it would be 27893 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 Nov 29 05:57:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 05: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 1Xub1r-0004q6-No; Sat, 29 Nov 2014 05:57:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xub1q-0004q1-70
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 05:57:10 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	CE/B8-14727-53069745; Sat, 29 Nov 2014 05:57:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417240627!14022205!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24999 invoked from network); 29 Nov 2014 05:57:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 05:57:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,481,1413244800"; d="scan'208";a="197898702"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 00:57:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xub1k-00047u-VF;
	Sat, 29 Nov 2014 05:57:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xub1k-0005lB-5F;
	Sat, 29 Nov 2014 05:57:04 +0000
Date: Sat, 29 Nov 2014 05:57:04 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31900-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31900: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31900 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31900/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          6dac8499151377c6e5eb57b5bf1fff7b62776ca5
baseline version:
 rumpuserxen          a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0

------------------------------------------------------------
People who touched revisions under test:
  Antti Kantee <pooka@iki.fi>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=6dac8499151377c6e5eb57b5bf1fff7b62776ca5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen 6dac8499151377c6e5eb57b5bf1fff7b62776ca5
+ branch=rumpuserxen
+ revision=6dac8499151377c6e5eb57b5bf1fff7b62776ca5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git 6dac8499151377c6e5eb57b5bf1fff7b62776ca5:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   a2fc4f9..6dac849  6dac8499151377c6e5eb57b5bf1fff7b62776ca5 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 05:57:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 05: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 1Xub1r-0004q6-No; Sat, 29 Nov 2014 05:57:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xub1q-0004q1-70
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 05:57:10 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	CE/B8-14727-53069745; Sat, 29 Nov 2014 05:57:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417240627!14022205!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24999 invoked from network); 29 Nov 2014 05:57:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 05:57:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,481,1413244800"; d="scan'208";a="197898702"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 00:57:05 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xub1k-00047u-VF;
	Sat, 29 Nov 2014 05:57:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xub1k-0005lB-5F;
	Sat, 29 Nov 2014 05:57:04 +0000
Date: Sat, 29 Nov 2014 05:57:04 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31900-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [rumpuserxen test] 31900: all pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31900 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31900/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          6dac8499151377c6e5eb57b5bf1fff7b62776ca5
baseline version:
 rumpuserxen          a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0

------------------------------------------------------------
People who touched revisions under test:
  Antti Kantee <pooka@iki.fi>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-i386-rumpuserxen-i386                             pass    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=6dac8499151377c6e5eb57b5bf1fff7b62776ca5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen 6dac8499151377c6e5eb57b5bf1fff7b62776ca5
+ branch=rumpuserxen
+ revision=6dac8499151377c6e5eb57b5bf1fff7b62776ca5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : daily-cron.rumpuserxen
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.rumpuserxen
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.rumpuserxen
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree rumpuserxen
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/rumpuserxen
+ git push osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git 6dac8499151377c6e5eb57b5bf1fff7b62776ca5:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   a2fc4f9..6dac849  6dac8499151377c6e5eb57b5bf1fff7b62776ca5 -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 07:59:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 07:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xucvy-0007Vg-E8; Sat, 29 Nov 2014 07:59: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@citrix.com>) id 1Xucvw-0007Vb-Fd
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 07:59:12 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	EC/B9-20609-FCC79745; Sat, 29 Nov 2014 07:59:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417247949!11851720!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17720 invoked from network); 29 Nov 2014 07:59:10 -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;
	29 Nov 2014 07:59:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,482,1413244800"; d="scan'208";a="197914632"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 02:59:07 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xucvq-0004ke-Ls;
	Sat, 29 Nov 2014 07:59:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xucvq-0002Lk-CW;
	Sat, 29 Nov 2014 07:59:06 +0000
Date: Sat, 29 Nov 2014 07:59:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31899-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31899: trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31899 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31899/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops             3 host-install(3)         broken REGR. vs. 31860

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              04c383ea7a991325ab6d2894b4f5bbdbbeb8fdd9
baseline version:
 libvirt              7296e896c92c64ec5653095bcc2ed86b6a72a7d5

------------------------------------------------------------
People who touched revisions under test:
  Jiri Denemark <jdenemar@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf-pvops host-install(3)

Not pushing.

------------------------------------------------------------
commit 04c383ea7a991325ab6d2894b4f5bbdbbeb8fdd9
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Wed Nov 26 11:55:59 2014 +0100

    tests: fix documentation for mocking methods
    
    It looks like it was copy-pasted, so in case anyone wonders what some of
    those methods do without looking at them, and for the sake of
    completeness, fix them.
    
    Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

commit 6d5ba6b18537833b875cda25745247df18fe38b4
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Wed Nov 26 09:25:43 2014 +0100

    Revert "ip link needs 'name' in 3.16 to create the veth pair"
    
    This reverts commit 433b427ff853ab72d32573d415e6ec569b77c7cb.
    
    The patch was added in order to overcome a bug in iproute2 and since it
    was properly identified as a bug, particularly in openSUSE 13.2, and it
    is being worked on [1], the best solution for libvirt seems to be to
    keep the old behaviour.
    
    [1] https://bugzilla.novell.com/show_bug.cgi?id=907093

commit dabb23e6d95dc7d81e7fb2a3f6c942167f4c45af
Author: Jiri Denemark <jdenemar@redhat.com>
Date:   Wed Nov 26 16:24:27 2014 +0100

    network: Fix upgrade from libvirt older than 1.2.4
    
    Starting from libvirt-1.2.4, network state XML files moved to another
    directory (see commit b9e95491) and libvirt automatically migrates the
    network state files to a new location. However, the code used
    dirent.d_type which is not supported by all filesystems. Thus, when
    libvirt was upgraded on a host which used such filesystem, network state
    XMLs were not properly moved and running networks disappeared from
    libvirt.
    
    This patch falls back to lstat() whenever dirent.d_type is DT_UNKNOWN to
    fix this issue.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1167145
    Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

commit f37627ee72e40d54d1c3d4da95ebdf2caec9b47a
Author: Jiri Denemark <jdenemar@redhat.com>
Date:   Mon Nov 24 17:37:13 2014 +0100

    util: Avoid calling closedir(NULL)
    
    Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 07:59:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 07:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xucvy-0007Vg-E8; Sat, 29 Nov 2014 07:59: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@citrix.com>) id 1Xucvw-0007Vb-Fd
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 07:59:12 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	EC/B9-20609-FCC79745; Sat, 29 Nov 2014 07:59:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417247949!11851720!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17720 invoked from network); 29 Nov 2014 07:59:10 -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;
	29 Nov 2014 07:59:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,482,1413244800"; d="scan'208";a="197914632"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 02:59:07 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xucvq-0004ke-Ls;
	Sat, 29 Nov 2014 07:59:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xucvq-0002Lk-CW;
	Sat, 29 Nov 2014 07:59:06 +0000
Date: Sat, 29 Nov 2014 07:59:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31899-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31899: trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31899 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31899/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops             3 host-install(3)         broken REGR. vs. 31860

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              04c383ea7a991325ab6d2894b4f5bbdbbeb8fdd9
baseline version:
 libvirt              7296e896c92c64ec5653095bcc2ed86b6a72a7d5

------------------------------------------------------------
People who touched revisions under test:
  Jiri Denemark <jdenemar@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step build-armhf-pvops host-install(3)

Not pushing.

------------------------------------------------------------
commit 04c383ea7a991325ab6d2894b4f5bbdbbeb8fdd9
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Wed Nov 26 11:55:59 2014 +0100

    tests: fix documentation for mocking methods
    
    It looks like it was copy-pasted, so in case anyone wonders what some of
    those methods do without looking at them, and for the sake of
    completeness, fix them.
    
    Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

commit 6d5ba6b18537833b875cda25745247df18fe38b4
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Wed Nov 26 09:25:43 2014 +0100

    Revert "ip link needs 'name' in 3.16 to create the veth pair"
    
    This reverts commit 433b427ff853ab72d32573d415e6ec569b77c7cb.
    
    The patch was added in order to overcome a bug in iproute2 and since it
    was properly identified as a bug, particularly in openSUSE 13.2, and it
    is being worked on [1], the best solution for libvirt seems to be to
    keep the old behaviour.
    
    [1] https://bugzilla.novell.com/show_bug.cgi?id=907093

commit dabb23e6d95dc7d81e7fb2a3f6c942167f4c45af
Author: Jiri Denemark <jdenemar@redhat.com>
Date:   Wed Nov 26 16:24:27 2014 +0100

    network: Fix upgrade from libvirt older than 1.2.4
    
    Starting from libvirt-1.2.4, network state XML files moved to another
    directory (see commit b9e95491) and libvirt automatically migrates the
    network state files to a new location. However, the code used
    dirent.d_type which is not supported by all filesystems. Thus, when
    libvirt was upgraded on a host which used such filesystem, network state
    XMLs were not properly moved and running networks disappeared from
    libvirt.
    
    This patch falls back to lstat() whenever dirent.d_type is DT_UNKNOWN to
    fix this issue.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1167145
    Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

commit f37627ee72e40d54d1c3d4da95ebdf2caec9b47a
Author: Jiri Denemark <jdenemar@redhat.com>
Date:   Mon Nov 24 17:37:13 2014 +0100

    util: Avoid calling closedir(NULL)
    
    Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 10:22:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 10:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xuf9t-0002PY-Hl; Sat, 29 Nov 2014 10:21:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xuf9s-0002PR-Jn
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 10:21:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B1/DF-15461-73E99745; Sat, 29 Nov 2014 10:21:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417256502!12259159!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21944 invoked from network); 29 Nov 2014 10:21:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 10:21:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,483,1413244800"; d="scan'208";a="197935037"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 05:21:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xuf9n-0005RH-Sd;
	Sat, 29 Nov 2014 10:21:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xuf9n-000708-NV;
	Sat, 29 Nov 2014 10:21:39 +0000
Date: Sat, 29 Nov 2014 10:21:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31895-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31895: 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 31895 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31895/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 31853
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 31853

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31853

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  c30ba28538134e29f7f8274a74b44058a04c4a68
baseline version:
 xen                  104072fc1c7e6ed117c70fa7f91ecc9946f8f654

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <julien.grall@linaro.org>
  Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-rhel6hvm-intel host-install(3)

Not pushing.

(No revision log; it would be 353 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 Nov 29 10:22:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 10:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xuf9t-0002PY-Hl; Sat, 29 Nov 2014 10:21:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xuf9s-0002PR-Jn
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 10:21:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B1/DF-15461-73E99745; Sat, 29 Nov 2014 10:21:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417256502!12259159!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21944 invoked from network); 29 Nov 2014 10:21:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 10:21:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,483,1413244800"; d="scan'208";a="197935037"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 05:21:40 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xuf9n-0005RH-Sd;
	Sat, 29 Nov 2014 10:21:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xuf9n-000708-NV;
	Sat, 29 Nov 2014 10:21:39 +0000
Date: Sat, 29 Nov 2014 10:21:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31895-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31895: 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 31895 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31895/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 31853
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 31853

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31853

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  c30ba28538134e29f7f8274a74b44058a04c4a68
baseline version:
 xen                  104072fc1c7e6ed117c70fa7f91ecc9946f8f654

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <julien.grall@linaro.org>
  Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-step test-amd64-i386-rhel6hvm-intel host-install(3)

Not pushing.

(No revision log; it would be 353 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 Nov 29 11:10:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 11: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 1XufuM-0003XQ-JK; Sat, 29 Nov 2014 11:09:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1XufuK-0003XL-UL
	for xen-devel@lists.xen.org; Sat, 29 Nov 2014 11:09:45 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	21/03-14727-879A9745; Sat, 29 Nov 2014 11:09:44 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417259381!14018647!1
X-Originating-IP: [62.142.5.109]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTA5ID0+IDk1MjIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2739 invoked from network); 29 Nov 2014 11:09:42 -0000
Received: from emh03.mail.saunalahti.fi (HELO emh03.mail.saunalahti.fi)
	(62.142.5.109)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2014 11:09:42 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 8C50318878E;
	Sat, 29 Nov 2014 13:09:40 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5544936C01F; Sat, 29 Nov 2014 13:09:40 +0200 (EET)
Date: Sat, 29 Nov 2014 13:09:40 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: greg@enjellic.com
Message-ID: <20141129110940.GW12451@reaktio.net>
References: <linux@eikelenboom.it>
	<201411290200.sAT20e64024859@wind.enjellic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201411290200.sAT20e64024859@wind.enjellic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 28, 2014 at 08:00:40PM -0600, Dr. Greg Wettstein wrote:
> On Nov 27, 12:11pm, Sander Eikelenboom wrote:
> } Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
> 
> Hi, hope the week has gone well for everyone.
>

Hello, hopefully your weekend is going well.

 
> > > So we are obviously working with qemu-dm-traditional and with the
> > > IGD/LVDS BIOS configuration issue fixed the adapater passthrough is
> > > working and Windows7 is coming up and detecting the IGD as a standard
> > > VGA display adapter.  Additional invocations of the VM after the first
> > > one result in failed passthrough with a garbled display.
> 
> > This is probably due to the current lack of slot/bus reset in
> > xen-pciback, Konrad has a preliminary kernel patch for xen-pciback
> > that does this.  I have attached the patch, though it has some rough
> > edges in the design :-)
> >
> > I'm currently running with his 3.19 xen-pciback patches series + the
> > preliminary patch for slot/bus reset and rebooting a guest with
> > vga/pci passthrough now works. (i'm running with a radeon card,
> > passed through as a secondary card to the emulated qemu one, in a
> > linux guest using qemu-xen, so i can't help you with your other
> > questions and problems).
> 
> Thanks for taking the time for respond and forward along the patch.
> 
> I back ported the do_flr patch into the 3.14.x kernel and spent some
> time working with it.  I thought it might be useful to others to
> document what we ran into.
> 
> First of all the issue with the unsuccessful boot of Windows after the
> first invocation doesn't appear to have anything to do with resetting
> the card.  This was fixed by installing the most recent version of the
> Intel HD drivers in the Windows guest.
> 
> If IGD passthrough is done without the HD drivers Windows 7 appears to
> use its standard VGA driver which seems to be able to initialize and
> run the IGD device but does not appear to shutdown the device in a
> manner in which it can be re-started.  After the first invocation of
> the guest is shutdown the screen goes to a solid color.  Subsequent
> invocations result in the flashing multi-color screens which others
> have documented.
> 
> With the HD drivers installed IGD passthrough works fine through
> multiple invocations of a guest with the stock xen-pciback in 3.14.x.
> We ran 40-50 repetitive Windows guest invocations and every one was
> completely deterministic.
>

It would be nice if you could let us know the exact Intel IGD Windows driver version
that worked well for you? It might be a good reference for others aswell.


Thanks,
 
-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 11:10:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 11: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 1XufuM-0003XQ-JK; Sat, 29 Nov 2014 11:09:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1XufuK-0003XL-UL
	for xen-devel@lists.xen.org; Sat, 29 Nov 2014 11:09:45 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	21/03-14727-879A9745; Sat, 29 Nov 2014 11:09:44 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417259381!14018647!1
X-Originating-IP: [62.142.5.109]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTA5ID0+IDk1MjIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2739 invoked from network); 29 Nov 2014 11:09:42 -0000
Received: from emh03.mail.saunalahti.fi (HELO emh03.mail.saunalahti.fi)
	(62.142.5.109)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2014 11:09:42 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 8C50318878E;
	Sat, 29 Nov 2014 13:09:40 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5544936C01F; Sat, 29 Nov 2014 13:09:40 +0200 (EET)
Date: Sat, 29 Nov 2014 13:09:40 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: greg@enjellic.com
Message-ID: <20141129110940.GW12451@reaktio.net>
References: <linux@eikelenboom.it>
	<201411290200.sAT20e64024859@wind.enjellic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201411290200.sAT20e64024859@wind.enjellic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Nov 28, 2014 at 08:00:40PM -0600, Dr. Greg Wettstein wrote:
> On Nov 27, 12:11pm, Sander Eikelenboom wrote:
> } Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
> 
> Hi, hope the week has gone well for everyone.
>

Hello, hopefully your weekend is going well.

 
> > > So we are obviously working with qemu-dm-traditional and with the
> > > IGD/LVDS BIOS configuration issue fixed the adapater passthrough is
> > > working and Windows7 is coming up and detecting the IGD as a standard
> > > VGA display adapter.  Additional invocations of the VM after the first
> > > one result in failed passthrough with a garbled display.
> 
> > This is probably due to the current lack of slot/bus reset in
> > xen-pciback, Konrad has a preliminary kernel patch for xen-pciback
> > that does this.  I have attached the patch, though it has some rough
> > edges in the design :-)
> >
> > I'm currently running with his 3.19 xen-pciback patches series + the
> > preliminary patch for slot/bus reset and rebooting a guest with
> > vga/pci passthrough now works. (i'm running with a radeon card,
> > passed through as a secondary card to the emulated qemu one, in a
> > linux guest using qemu-xen, so i can't help you with your other
> > questions and problems).
> 
> Thanks for taking the time for respond and forward along the patch.
> 
> I back ported the do_flr patch into the 3.14.x kernel and spent some
> time working with it.  I thought it might be useful to others to
> document what we ran into.
> 
> First of all the issue with the unsuccessful boot of Windows after the
> first invocation doesn't appear to have anything to do with resetting
> the card.  This was fixed by installing the most recent version of the
> Intel HD drivers in the Windows guest.
> 
> If IGD passthrough is done without the HD drivers Windows 7 appears to
> use its standard VGA driver which seems to be able to initialize and
> run the IGD device but does not appear to shutdown the device in a
> manner in which it can be re-started.  After the first invocation of
> the guest is shutdown the screen goes to a solid color.  Subsequent
> invocations result in the flashing multi-color screens which others
> have documented.
> 
> With the HD drivers installed IGD passthrough works fine through
> multiple invocations of a guest with the stock xen-pciback in 3.14.x.
> We ran 40-50 repetitive Windows guest invocations and every one was
> completely deterministic.
>

It would be nice if you could let us know the exact Intel IGD Windows driver version
that worked well for you? It might be a good reference for others aswell.


Thanks,
 
-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 11:31:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 11:31:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XugFC-00042o-Gx; Sat, 29 Nov 2014 11:31:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XugFB-00042j-IK
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 11:31:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9D/89-15461-48EA9745; Sat, 29 Nov 2014 11:31:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417260674!12267206!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17541 invoked from network); 29 Nov 2014 11:31:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 11:31:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,483,1413244800"; d="scan'208";a="197945503"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 06:30:54 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XugEo-0005lx-02;
	Sat, 29 Nov 2014 11:30:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XugEn-0006Or-P9;
	Sat, 29 Nov 2014 11:30:53 +0000
Date: Sat, 29 Nov 2014 11:30:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31897-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31897: 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 31897 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31897/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10      fail pass in 31881
 test-amd64-amd64-libvirt      3 host-install(3)  broken in 31881 pass in 31897
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 31881 pass in 31897
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 31881 pass in 31897
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot   fail in 31881 pass in 31897
 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken in 31881 pass in 31897
 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 31881 pass in 31897
 test-amd64-amd64-xl-win7-amd64  5 xen-boot         fail in 31881 pass in 31897
 test-i386-i386-xl-qemut-winxpsp3  5 xen-boot       fail in 31881 pass in 31897

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair   17 guest-migrate/src_host/dst_host fail blocked in 31778
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31778

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3e5c06aeea1ff91c3f2247baae372936b67cf411
baseline version:
 xen                  dc37cab1d0f567639f52cad654068a7e56652e2e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.2-testing
+ revision=3e5c06aeea1ff91c3f2247baae372936b67cf411
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 3e5c06aeea1ff91c3f2247baae372936b67cf411
+ branch=xen-4.2-testing
+ revision=3e5c06aeea1ff91c3f2247baae372936b67cf411
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.2-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.2-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.2-testing
+ xenversion=xen-4.2
+ xenversion=4.2
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 3e5c06aeea1ff91c3f2247baae372936b67cf411:stable-4.2
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   dc37cab..3e5c06a  3e5c06aeea1ff91c3f2247baae372936b67cf411 -> stable-4.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 11:31:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 11:31:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XugFC-00042o-Gx; Sat, 29 Nov 2014 11:31:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XugFB-00042j-IK
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 11:31:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9D/89-15461-48EA9745; Sat, 29 Nov 2014 11:31:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417260674!12267206!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17541 invoked from network); 29 Nov 2014 11:31:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 11:31:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,483,1413244800"; d="scan'208";a="197945503"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 06:30:54 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XugEo-0005lx-02;
	Sat, 29 Nov 2014 11:30:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XugEn-0006Or-P9;
	Sat, 29 Nov 2014 11:30:53 +0000
Date: Sat, 29 Nov 2014 11:30:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31897-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 31897: 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 31897 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31897/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10      fail pass in 31881
 test-amd64-amd64-libvirt      3 host-install(3)  broken in 31881 pass in 31897
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 31881 pass in 31897
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 31881 pass in 31897
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot   fail in 31881 pass in 31897
 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken in 31881 pass in 31897
 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 31881 pass in 31897
 test-amd64-amd64-xl-win7-amd64  5 xen-boot         fail in 31881 pass in 31897
 test-i386-i386-xl-qemut-winxpsp3  5 xen-boot       fail in 31881 pass in 31897

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair   17 guest-migrate/src_host/dst_host fail blocked in 31778
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31778

Tests which did not succeed, but are not blocking:
 test-i386-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-i386-i386-libvirt        9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 build-amd64-rumpuserxen       5 rumpuserxen-build            fail   never pass
 build-i386-rumpuserxen        5 rumpuserxen-build            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3e5c06aeea1ff91c3f2247baae372936b67cf411
baseline version:
 xen                  dc37cab1d0f567639f52cad654068a7e56652e2e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-i386-i386-rumpuserxen-i386                              blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-i386-i386-libvirt                                       fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.2-testing
+ revision=3e5c06aeea1ff91c3f2247baae372936b67cf411
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 3e5c06aeea1ff91c3f2247baae372936b67cf411
+ branch=xen-4.2-testing
+ revision=3e5c06aeea1ff91c3f2247baae372936b67cf411
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.2-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.2-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.2-testing
+ xenversion=xen-4.2
+ xenversion=4.2
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 3e5c06aeea1ff91c3f2247baae372936b67cf411:stable-4.2
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   dc37cab..3e5c06a  3e5c06aeea1ff91c3f2247baae372936b67cf411 -> stable-4.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 13:20:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 13: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 1XuhwN-0006Sm-Vk; Sat, 29 Nov 2014 13:19:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuhwL-0006Sh-Rj
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 13:19:58 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	E2/84-02712-CF7C9745; Sat, 29 Nov 2014 13:19:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417267194!7268065!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29681 invoked from network); 29 Nov 2014 13:19:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 13:19:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,483,1413244800"; d="scan'208";a="197671515"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 08:19:52 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuhwG-0006IP-8U;
	Sat, 29 Nov 2014 13:19:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuhwF-0000Fv-Uq;
	Sat, 29 Nov 2014 13:19:51 +0000
Date: Sat, 29 Nov 2014 13:19:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31902-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31902: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31902 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31902/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31811
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 31811

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a
baseline version:
 xen                  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 e0921ec746410f0a07eb3767e95e5eda25d4934a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:15:27 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 5e687e7da367827344db3965b8a5f5f761a8431a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:14:15 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 13:20:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 13: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 1XuhwN-0006Sm-Vk; Sat, 29 Nov 2014 13:19:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XuhwL-0006Sh-Rj
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 13:19:58 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	E2/84-02712-CF7C9745; Sat, 29 Nov 2014 13:19:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417267194!7268065!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29681 invoked from network); 29 Nov 2014 13:19:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 13:19:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,483,1413244800"; d="scan'208";a="197671515"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 08:19:52 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XuhwG-0006IP-8U;
	Sat, 29 Nov 2014 13:19:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XuhwF-0000Fv-Uq;
	Sat, 29 Nov 2014 13:19:51 +0000
Date: Sat, 29 Nov 2014 13:19:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31902-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31902: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31902 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31902/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31811
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 31811

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a
baseline version:
 xen                  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 e0921ec746410f0a07eb3767e95e5eda25d4934a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:15:27 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 5e687e7da367827344db3965b8a5f5f761a8431a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:14:15 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 16:42:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 16: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 1Xul5S-0002Tk-Pn; Sat, 29 Nov 2014 16:41:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xul5Q-0002Tf-KO
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 16:41:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	26/E8-25276-B37F9745; Sat, 29 Nov 2014 16:41:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417279289!12281797!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20542 invoked from network); 29 Nov 2014 16:41:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 16:41:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,483,1413244800"; d="scan'208";a="197696345"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 11:41:27 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xul5L-0007GX-Jp;
	Sat, 29 Nov 2014 16:41:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xul5L-0006Mu-Dg;
	Sat, 29 Nov 2014 16:41:27 +0000
Date: Sat, 29 Nov 2014 16:41:27 +0000
Message-ID: <E1Xul5L-0006Mu-Dg@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl
test guest-saverestore

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  c6c9161d064d30e78904f3affe5184487493e0fc
  Bug not present: 8b2ed21e846c63d8f1bdee0d8df0645721a604a1


  commit c6c9161d064d30e78904f3affe5184487493e0fc
  Merge: 8b2ed21 b5e212a
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Nov 21 15:46:17 2014 -0800
  
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
      
      Pull x86 fixes from Thomas Gleixner:
       "Misc fixes:
         - gold linker build fix
         - noxsave command line parsing fix
         - bugfix for NX setup
         - microcode resume path bug fix
         - _TIF_NOHZ versus TIF_NOHZ bugfix as discussed in the mysterious
           lockup thread"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
        x86, kaslr: Handle Gold linker for finding bss/brk
        x86, mm: Set NX across entire PMD at boot
        x86, microcode: Update BSPs microcode on resume
        x86: Require exact match for 'noxsave' command line option
  
  commit b5e212a3051b65e426a513901d9c7001681c7215
  Author: Andy Lutomirski <luto@amacapital.net>
  Date:   Wed Nov 19 13:56:19 2014 -0800
  
      x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
      
      TIF_NOHZ is 19 (i.e. _TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME |
      _TIF_SINGLESTEP), not (1<<19).
      
      This code is involved in Dave's trinity lockup, but I don't see why
      it would cause any of the problems he's seeing, except inadvertently
      by causing a different path through entry_64.S's syscall handling.
      
      Signed-off-by: Andy Lutomirski <luto@amacapital.net>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.luto@amacapital.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Nov 17 16:16:04 2014 -0800
  
      x86, kaslr: Handle Gold linker for finding bss/brk
      
      When building with the Gold linker, the .bss and .brk areas of vmlinux
      are shown as consecutive instead of having the same file offset. Allow
      for either state, as long as things add up correctly.
      
      Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
      Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Link: http://lkml.kernel.org/r/20141118001604.GA25045@www.outflux.net
      Cc: stable@vger.kernel.org
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keescook@chromium.org>
  Date:   Fri Nov 14 11:47:37 2014 -0800
  
      x86, mm: Set NX across entire PMD at boot
      
      When setting up permissions on kernel memory at boot, the end of the
      PMD that was split from bss remained executable. It should be NX like
      the rest. This performs a PMD alignment instead of a PAGE alignment to
      get the correct span of memory.
      
      Before:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
      0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
      0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      After:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
              We really should unmap the reminder along with the holes
              caused by init,initdata etc. but thats a different issue ]
      
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <bp@suse.de>
  Date:   Tue Nov 18 10:46:57 2014 +0100
  
      x86, microcode: Update BSPs microcode on resume
      
      In the situation when we apply early microcode but do *not* apply late
      microcode, we fail to update the BSP's microcode on resume because we
      haven't initialized the uci->mc microcode pointer. So, in order to
      alleviate that, we go and dig out the stashed microcode patch during
      early boot. It is basically the same thing that is done on the APs early
      during boot so do that too here.
      
      Tested-by: alex.schnaidt@gmail.com
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: Borislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.hansen@linux.intel.com>
  Date:   Tue Nov 11 14:01:33 2014 -0800
  
      x86: Require exact match for 'noxsave' command line option
      
      We have some very similarly named command-line options:
      
      arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
      
      __setup() is designed to match options that take arguments, like
      "foo=bar" where you would have:
      
      	__setup("foo", x86_foo_func...);
      
      The problem is that "noxsave" actually _matches_ "noxsaves" in
      the same way that "foo" matches "foo=bar".  If you boot an old
      kernel that does not know about "noxsaves" with "noxsaves" on the
      command line, it will interpret the argument as "noxsave", which
      is not what you want at all.
      
      This makes the "noxsave" handler only return success when it finds
      an *exact* match.
      
      [ tglx: We really need to make __setup() more robust. ]
      
      Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: x86@kernel.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.linux-linus.test-amd64-i386-xl.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31858 fail [host=rice-weevil] / 31766 [host=field-cricket] 31683 [host=gall-mite] 31665 ok.
Failure / basis pass flights: 31858 / 31665
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 git://xenbits.xen.org/xen.git
Latest 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Basis pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#fc14f9c1272f62c3e8d01300f52467c0d9af50f9-5d01410fe4d92081f349b013a2e7a95429e4f2c9 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51-a230ec3101ddda868252c036ea960af2b2d6cd5a git://xenbits.xen.org/xen.git#e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2-6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 382257 nodes in revision graph
Searching for test results:
 31683 [host=gall-mite]
 31665 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31766 [host=field-cricket]
 31858 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31850 fail irrelevant
 31914 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31920 pass 788ec2fc2ca295a2d929986e95231214ecd8d142 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31937 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31929 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31918 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31923 fail e6a588d086a75dc20afb8ffbcbe23a50d4a1ca37 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31919 fail 9a7e4f5633f0c733820091cc9c643cc0c257c349 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31926 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 0f25d1b324b7922094c9e1bde78d7df01d57dadc
 31924 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 dbdd03d0ad4ad93f1db50341fac56a514c726552
 31927 pass a64bb02f4a62a604d8dd62decb559b9c6adfb40c c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31930 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31936 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31933 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31938 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Searching for interesting versions
 Result found: flight 31665 (pass), for basis pass
 Result found: flight 31858 (fail), for basis failure
 Repro found: flight 31914 (pass), for basis pass
 Repro found: flight 31918 (fail), for basis failure
 0 revisions at 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
No revisions left to test, checking graph state.
 Result found: flight 31929 (pass), for last pass
 Result found: flight 31930 (fail), for first failure
 Repro found: flight 31933 (pass), for last pass
 Repro found: flight 31936 (fail), for first failure
 Repro found: flight 31937 (pass), for last pass
 Repro found: flight 31938 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  c6c9161d064d30e78904f3affe5184487493e0fc
  Bug not present: 8b2ed21e846c63d8f1bdee0d8df0645721a604a1

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit c6c9161d064d30e78904f3affe5184487493e0fc
  Merge: 8b2ed21 b5e212a
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Nov 21 15:46:17 2014 -0800
  
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
      
      Pull x86 fixes from Thomas Gleixner:
       "Misc fixes:
         - gold linker build fix
         - noxsave command line parsing fix
         - bugfix for NX setup
         - microcode resume path bug fix
         - _TIF_NOHZ versus TIF_NOHZ bugfix as discussed in the mysterious
           lockup thread"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
        x86, kaslr: Handle Gold linker for finding bss/brk
        x86, mm: Set NX across entire PMD at boot
        x86, microcode: Update BSPs microcode on resume
        x86: Require exact match for 'noxsave' command line option
  
  commit b5e212a3051b65e426a513901d9c7001681c7215
  Author: Andy Lutomirski <luto@amacapital.net>
  Date:   Wed Nov 19 13:56:19 2014 -0800
  
      x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
      
      TIF_NOHZ is 19 (i.e. _TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME |
      _TIF_SINGLESTEP), not (1<<19).
      
      This code is involved in Dave's trinity lockup, but I don't see why
      it would cause any of the problems he's seeing, except inadvertently
      by causing a different path through entry_64.S's syscall handling.
      
      Signed-off-by: Andy Lutomirski <luto@amacapital.net>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.luto@amacapital.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Nov 17 16:16:04 2014 -0800
  
      x86, kaslr: Handle Gold linker for finding bss/brk
      
      When building with the Gold linker, the .bss and .brk areas of vmlinux
      are shown as consecutive instead of having the same file offset. Allow
      for either state, as long as things add up correctly.
      
      Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
      Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Link: http://lkml.kernel.org/r/20141118001604.GA25045@www.outflux.net
      Cc: stable@vger.kernel.org
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keescook@chromium.org>
  Date:   Fri Nov 14 11:47:37 2014 -0800
  
      x86, mm: Set NX across entire PMD at boot
      
      When setting up permissions on kernel memory at boot, the end of the
      PMD that was split from bss remained executable. It should be NX like
      the rest. This performs a PMD alignment instead of a PAGE alignment to
      get the correct span of memory.
      
      Before:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
      0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
      0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      After:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
              We really should unmap the reminder along with the holes
              caused by init,initdata etc. but thats a different issue ]
      
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <bp@suse.de>
  Date:   Tue Nov 18 10:46:57 2014 +0100
  
      x86, microcode: Update BSPs microcode on resume
      
      In the situation when we apply early microcode but do *not* apply late
      microcode, we fail to update the BSP's microcode on resume because we
      haven't initialized the uci->mc microcode pointer. So, in order to
      alleviate that, we go and dig out the stashed microcode patch during
      early boot. It is basically the same thing that is done on the APs early
      during boot so do that too here.
      
      Tested-by: alex.schnaidt@gmail.com
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: Borislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.hansen@linux.intel.com>
  Date:   Tue Nov 11 14:01:33 2014 -0800
  
      x86: Require exact match for 'noxsave' command line option
      
      We have some very similarly named command-line options:
      
      arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
      
      __setup() is designed to match options that take arguments, like
      "foo=bar" where you would have:
      
      	__setup("foo", x86_foo_func...);
      
      The problem is that "noxsave" actually _matches_ "noxsaves" in
      the same way that "foo" matches "foo=bar".  If you boot an old
      kernel that does not know about "noxsaves" with "noxsaves" on the
      command line, it will interpret the argument as "noxsave", which
      is not what you want at all.
      
      This makes the "noxsave" handler only return success when it finds
      an *exact* match.
      
      [ tglx: We really need to make __setup() more robust. ]
      
      Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: x86@kernel.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Revision graph left in /home/xc_osstest/results/bisect.linux-linus.test-amd64-i386-xl.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
31938: tolerable ALL FAIL

flight 31938 linux-linus real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31938/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl           11 guest-saverestore       fail baseline untested


jobs:
 test-amd64-i386-xl                                           fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Nov 29 16:42:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 16: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 1Xul5S-0002Tk-Pn; Sat, 29 Nov 2014 16:41:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xul5Q-0002Tf-KO
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 16:41:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	26/E8-25276-B37F9745; Sat, 29 Nov 2014 16:41:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417279289!12281797!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20542 invoked from network); 29 Nov 2014 16:41:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 16:41:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,483,1413244800"; d="scan'208";a="197696345"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 11:41:27 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xul5L-0007GX-Jp;
	Sat, 29 Nov 2014 16:41:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xul5L-0006Mu-Dg;
	Sat, 29 Nov 2014 16:41:27 +0000
Date: Sat, 29 Nov 2014 16:41:27 +0000
Message-ID: <E1Xul5L-0006Mu-Dg@osstest.cam.xci-test.com>
To: <xen-devel@lists.xensource.com>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl
test guest-saverestore

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  c6c9161d064d30e78904f3affe5184487493e0fc
  Bug not present: 8b2ed21e846c63d8f1bdee0d8df0645721a604a1


  commit c6c9161d064d30e78904f3affe5184487493e0fc
  Merge: 8b2ed21 b5e212a
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Nov 21 15:46:17 2014 -0800
  
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
      
      Pull x86 fixes from Thomas Gleixner:
       "Misc fixes:
         - gold linker build fix
         - noxsave command line parsing fix
         - bugfix for NX setup
         - microcode resume path bug fix
         - _TIF_NOHZ versus TIF_NOHZ bugfix as discussed in the mysterious
           lockup thread"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
        x86, kaslr: Handle Gold linker for finding bss/brk
        x86, mm: Set NX across entire PMD at boot
        x86, microcode: Update BSPs microcode on resume
        x86: Require exact match for 'noxsave' command line option
  
  commit b5e212a3051b65e426a513901d9c7001681c7215
  Author: Andy Lutomirski <luto@amacapital.net>
  Date:   Wed Nov 19 13:56:19 2014 -0800
  
      x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
      
      TIF_NOHZ is 19 (i.e. _TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME |
      _TIF_SINGLESTEP), not (1<<19).
      
      This code is involved in Dave's trinity lockup, but I don't see why
      it would cause any of the problems he's seeing, except inadvertently
      by causing a different path through entry_64.S's syscall handling.
      
      Signed-off-by: Andy Lutomirski <luto@amacapital.net>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.luto@amacapital.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Nov 17 16:16:04 2014 -0800
  
      x86, kaslr: Handle Gold linker for finding bss/brk
      
      When building with the Gold linker, the .bss and .brk areas of vmlinux
      are shown as consecutive instead of having the same file offset. Allow
      for either state, as long as things add up correctly.
      
      Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
      Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Link: http://lkml.kernel.org/r/20141118001604.GA25045@www.outflux.net
      Cc: stable@vger.kernel.org
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keescook@chromium.org>
  Date:   Fri Nov 14 11:47:37 2014 -0800
  
      x86, mm: Set NX across entire PMD at boot
      
      When setting up permissions on kernel memory at boot, the end of the
      PMD that was split from bss remained executable. It should be NX like
      the rest. This performs a PMD alignment instead of a PAGE alignment to
      get the correct span of memory.
      
      Before:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
      0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
      0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      After:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
              We really should unmap the reminder along with the holes
              caused by init,initdata etc. but thats a different issue ]
      
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <bp@suse.de>
  Date:   Tue Nov 18 10:46:57 2014 +0100
  
      x86, microcode: Update BSPs microcode on resume
      
      In the situation when we apply early microcode but do *not* apply late
      microcode, we fail to update the BSP's microcode on resume because we
      haven't initialized the uci->mc microcode pointer. So, in order to
      alleviate that, we go and dig out the stashed microcode patch during
      early boot. It is basically the same thing that is done on the APs early
      during boot so do that too here.
      
      Tested-by: alex.schnaidt@gmail.com
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: Borislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.hansen@linux.intel.com>
  Date:   Tue Nov 11 14:01:33 2014 -0800
  
      x86: Require exact match for 'noxsave' command line option
      
      We have some very similarly named command-line options:
      
      arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
      
      __setup() is designed to match options that take arguments, like
      "foo=bar" where you would have:
      
      	__setup("foo", x86_foo_func...);
      
      The problem is that "noxsave" actually _matches_ "noxsaves" in
      the same way that "foo" matches "foo=bar".  If you boot an old
      kernel that does not know about "noxsaves" with "noxsaves" on the
      command line, it will interpret the argument as "noxsave", which
      is not what you want at all.
      
      This makes the "noxsave" handler only return success when it finds
      an *exact* match.
      
      [ tglx: We really need to make __setup() more robust. ]
      
      Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: x86@kernel.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.linux-linus.test-amd64-i386-xl.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31858 fail [host=rice-weevil] / 31766 [host=field-cricket] 31683 [host=gall-mite] 31665 ok.
Failure / basis pass flights: 31858 / 31665
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 git://xenbits.xen.org/xen.git
Latest 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Basis pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#fc14f9c1272f62c3e8d01300f52467c0d9af50f9-5d01410fe4d92081f349b013a2e7a95429e4f2c9 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51-a230ec3101ddda868252c036ea960af2b2d6cd5a git://xenbits.xen.org/xen.git#e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2-6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 382257 nodes in revision graph
Searching for test results:
 31683 [host=gall-mite]
 31665 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31766 [host=field-cricket]
 31858 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31850 fail irrelevant
 31914 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31920 pass 788ec2fc2ca295a2d929986e95231214ecd8d142 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31937 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31929 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31918 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31923 fail e6a588d086a75dc20afb8ffbcbe23a50d4a1ca37 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31919 fail 9a7e4f5633f0c733820091cc9c643cc0c257c349 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31926 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 0f25d1b324b7922094c9e1bde78d7df01d57dadc
 31924 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 dbdd03d0ad4ad93f1db50341fac56a514c726552
 31927 pass a64bb02f4a62a604d8dd62decb559b9c6adfb40c c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31930 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31936 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31933 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31938 fail c6c9161d064d30e78904f3affe5184487493e0fc c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Searching for interesting versions
 Result found: flight 31665 (pass), for basis pass
 Result found: flight 31858 (fail), for basis failure
 Repro found: flight 31914 (pass), for basis pass
 Repro found: flight 31918 (fail), for basis failure
 0 revisions at 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
No revisions left to test, checking graph state.
 Result found: flight 31929 (pass), for last pass
 Result found: flight 31930 (fail), for first failure
 Repro found: flight 31933 (pass), for last pass
 Repro found: flight 31936 (fail), for first failure
 Repro found: flight 31937 (pass), for last pass
 Repro found: flight 31938 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  c6c9161d064d30e78904f3affe5184487493e0fc
  Bug not present: 8b2ed21e846c63d8f1bdee0d8df0645721a604a1

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit c6c9161d064d30e78904f3affe5184487493e0fc
  Merge: 8b2ed21 b5e212a
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Nov 21 15:46:17 2014 -0800
  
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
      
      Pull x86 fixes from Thomas Gleixner:
       "Misc fixes:
         - gold linker build fix
         - noxsave command line parsing fix
         - bugfix for NX setup
         - microcode resume path bug fix
         - _TIF_NOHZ versus TIF_NOHZ bugfix as discussed in the mysterious
           lockup thread"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
        x86, kaslr: Handle Gold linker for finding bss/brk
        x86, mm: Set NX across entire PMD at boot
        x86, microcode: Update BSPs microcode on resume
        x86: Require exact match for 'noxsave' command line option
  
  commit b5e212a3051b65e426a513901d9c7001681c7215
  Author: Andy Lutomirski <luto@amacapital.net>
  Date:   Wed Nov 19 13:56:19 2014 -0800
  
      x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
      
      TIF_NOHZ is 19 (i.e. _TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME |
      _TIF_SINGLESTEP), not (1<<19).
      
      This code is involved in Dave's trinity lockup, but I don't see why
      it would cause any of the problems he's seeing, except inadvertently
      by causing a different path through entry_64.S's syscall handling.
      
      Signed-off-by: Andy Lutomirski <luto@amacapital.net>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.luto@amacapital.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keescook@chromium.org>
  Date:   Mon Nov 17 16:16:04 2014 -0800
  
      x86, kaslr: Handle Gold linker for finding bss/brk
      
      When building with the Gold linker, the .bss and .brk areas of vmlinux
      are shown as consecutive instead of having the same file offset. Allow
      for either state, as long as things add up correctly.
      
      Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
      Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Link: http://lkml.kernel.org/r/20141118001604.GA25045@www.outflux.net
      Cc: stable@vger.kernel.org
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keescook@chromium.org>
  Date:   Fri Nov 14 11:47:37 2014 -0800
  
      x86, mm: Set NX across entire PMD at boot
      
      When setting up permissions on kernel memory at boot, the end of the
      PMD that was split from bss remained executable. It should be NX like
      the rest. This performs a PMD alignment instead of a PAGE alignment to
      get the correct span of memory.
      
      Before:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
      0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
      0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      After:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
              We really should unmap the reminder along with the holes
              caused by init,initdata etc. but thats a different issue ]
      
      Signed-off-by: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <bp@suse.de>
  Date:   Tue Nov 18 10:46:57 2014 +0100
  
      x86, microcode: Update BSPs microcode on resume
      
      In the situation when we apply early microcode but do *not* apply late
      microcode, we fail to update the BSP's microcode on resume because we
      haven't initialized the uci->mc microcode pointer. So, in order to
      alleviate that, we go and dig out the stashed microcode patch during
      early boot. It is basically the same thing that is done on the APs early
      during boot so do that too here.
      
      Tested-by: alex.schnaidt@gmail.com
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: Borislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.hansen@linux.intel.com>
  Date:   Tue Nov 11 14:01:33 2014 -0800
  
      x86: Require exact match for 'noxsave' command line option
      
      We have some very similarly named command-line options:
      
      arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
      
      __setup() is designed to match options that take arguments, like
      "foo=bar" where you would have:
      
      	__setup("foo", x86_foo_func...);
      
      The problem is that "noxsave" actually _matches_ "noxsaves" in
      the same way that "foo" matches "foo=bar".  If you boot an old
      kernel that does not know about "noxsaves" with "noxsaves" on the
      command line, it will interpret the argument as "noxsave", which
      is not what you want at all.
      
      This makes the "noxsave" handler only return success when it finds
      an *exact* match.
      
      [ tglx: We really need to make __setup() more robust. ]
      
      Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: x86@kernel.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Revision graph left in /home/xc_osstest/results/bisect.linux-linus.test-amd64-i386-xl.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
31938: tolerable ALL FAIL

flight 31938 linux-linus real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31938/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl           11 guest-saverestore       fail baseline untested


jobs:
 test-amd64-i386-xl                                           fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Nov 29 18:59:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 18: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 1XunEF-0005xZ-Rh; Sat, 29 Nov 2014 18:58:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XunEE-0005xU-99
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 18:58:46 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	F7/20-02696-5671A745; Sat, 29 Nov 2014 18:58:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417287523!11902308!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11186 invoked from network); 29 Nov 2014 18:58:44 -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;
	29 Nov 2014 18:58:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,484,1413244800"; d="scan'208";a="198007994"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 13:58:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XunE9-0007vS-Qf;
	Sat, 29 Nov 2014 18:58:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XunE9-0006Cl-Ke;
	Sat, 29 Nov 2014 18:58:41 +0000
Date: Sat, 29 Nov 2014 18:58:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31904-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31904: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31904 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31904/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31781

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 guest-localmigrate.2 fail pass in 31882
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 31882 pass in 31904

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  a39f202031d7f1d8d9e14b8c3d7d11c812db253e
baseline version:
 xen                  7679aeb444ed3bc4de0f473c16c47eab7d2f9d33

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 a39f202031d7f1d8d9e14b8c3d7d11c812db253e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:11:57 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: c5397354b998d030b021810b8202de93b9526818
    master date: 2014-11-27 14:01:40 +0100

commit 98c78711764082171b3fa189793c6db904f65ebc
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:10:52 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: 0ad715304b04739fd2fc9517ce8671d3947c7621
    master date: 2014-11-27 14:00:23 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 18:59:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 18: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 1XunEF-0005xZ-Rh; Sat, 29 Nov 2014 18:58:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XunEE-0005xU-99
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 18:58:46 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	F7/20-02696-5671A745; Sat, 29 Nov 2014 18:58:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417287523!11902308!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11186 invoked from network); 29 Nov 2014 18:58:44 -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;
	29 Nov 2014 18:58:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,484,1413244800"; d="scan'208";a="198007994"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 13:58:42 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XunE9-0007vS-Qf;
	Sat, 29 Nov 2014 18:58:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XunE9-0006Cl-Ke;
	Sat, 29 Nov 2014 18:58:41 +0000
Date: Sat, 29 Nov 2014 18:58:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31904-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.4-testing test] 31904: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31904 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31904/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31781

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 guest-localmigrate.2 fail pass in 31882
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 31882 pass in 31904

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  a39f202031d7f1d8d9e14b8c3d7d11c812db253e
baseline version:
 xen                  7679aeb444ed3bc4de0f473c16c47eab7d2f9d33

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 a39f202031d7f1d8d9e14b8c3d7d11c812db253e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:11:57 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: c5397354b998d030b021810b8202de93b9526818
    master date: 2014-11-27 14:01:40 +0100

commit 98c78711764082171b3fa189793c6db904f65ebc
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:10:52 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: 0ad715304b04739fd2fc9517ce8671d3947c7621
    master date: 2014-11-27 14:00:23 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 19:29:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 19:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XunhJ-0006jZ-TR; Sat, 29 Nov 2014 19:28:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XunhI-0006jU-Al
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 19:28:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	17/FC-15461-F6E1A745; Sat, 29 Nov 2014 19:28:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417289325!8862107!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31885 invoked from network); 29 Nov 2014 19:28:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 19:28:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,484,1413244800"; d="scan'208";a="198012514"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 14:28:44 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XunhD-00084j-Mh;
	Sat, 29 Nov 2014 19:28:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XunhD-0007kP-GU;
	Sat, 29 Nov 2014 19:28:43 +0000
Date: Sat, 29 Nov 2014 19:28:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31906-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31906: 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 31906 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31906/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt       5 xen-boot                fail baseline untested
 test-amd64-i386-xl            5 xen-boot                fail baseline untested
 test-amd64-i386-xl-credit2    5 xen-boot                fail baseline untested
 test-amd64-i386-xl-multivcpu  5 xen-boot                fail baseline untested
 test-amd64-amd64-libvirt      5 xen-boot                fail baseline untested
 test-amd64-amd64-xl           5 xen-boot                fail baseline untested
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot          fail baseline untested
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-armhf-armhf-libvirt      5 xen-boot                fail baseline untested
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot          fail baseline untested
 test-amd64-i386-freebsd10-amd64  5 xen-boot             fail baseline untested
 test-amd64-i386-freebsd10-i386  5 xen-boot              fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot        fail baseline untested
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot         fail baseline untested
 test-armhf-armhf-xl           5 xen-boot                fail baseline untested
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot           fail baseline untested
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot    fail baseline untested
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot        fail baseline untested
 test-amd64-i386-rhel6hvm-intel  5 xen-boot              fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot         fail baseline untested
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot    fail baseline untested
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot    fail baseline untested
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot         fail baseline untested
 test-amd64-amd64-pair         8 xen-boot/dst_host       fail baseline untested
 test-amd64-amd64-pair         7 xen-boot/src_host       fail baseline untested
 test-amd64-amd64-xl-win7-amd64  5 xen-boot              fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot        fail baseline untested
 test-amd64-i386-xl-winxpsp3   5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot        fail baseline untested
 test-amd64-i386-xl-win7-amd64  5 xen-boot               fail baseline untested
 test-amd64-i386-rumpuserxen-i386  5 xen-boot            fail baseline untested
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-boot   fail baseline untested
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot             fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot          fail baseline untested
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot   fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot    fail baseline untested
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot        fail baseline untested
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot          fail baseline untested
 test-amd64-i386-pair          8 xen-boot/dst_host       fail baseline untested
 test-amd64-i386-pair          7 xen-boot/src_host       fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot           fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot          fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot          fail baseline untested
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                fail baseline untested

version targeted for testing:
 linux                29340b8ee0b4def844aa8d6b09babcede80993d2
baseline version:
 linux                b914c5b2130239fd378d1a719ab3c53f0c782be9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 19:29:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 19:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XunhJ-0006jZ-TR; Sat, 29 Nov 2014 19:28:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XunhI-0006jU-Al
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 19:28:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	17/FC-15461-F6E1A745; Sat, 29 Nov 2014 19:28:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417289325!8862107!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31885 invoked from network); 29 Nov 2014 19:28:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 19:28:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,484,1413244800"; d="scan'208";a="198012514"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 14:28:44 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XunhD-00084j-Mh;
	Sat, 29 Nov 2014 19:28:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XunhD-0007kP-GU;
	Sat, 29 Nov 2014 19:28:43 +0000
Date: Sat, 29 Nov 2014 19:28:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31906-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-next test] 31906: 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 31906 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31906/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt       5 xen-boot                fail baseline untested
 test-amd64-i386-xl            5 xen-boot                fail baseline untested
 test-amd64-i386-xl-credit2    5 xen-boot                fail baseline untested
 test-amd64-i386-xl-multivcpu  5 xen-boot                fail baseline untested
 test-amd64-amd64-libvirt      5 xen-boot                fail baseline untested
 test-amd64-amd64-xl           5 xen-boot                fail baseline untested
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot          fail baseline untested
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-armhf-armhf-libvirt      5 xen-boot                fail baseline untested
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot          fail baseline untested
 test-amd64-i386-freebsd10-amd64  5 xen-boot             fail baseline untested
 test-amd64-i386-freebsd10-i386  5 xen-boot              fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot        fail baseline untested
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot         fail baseline untested
 test-armhf-armhf-xl           5 xen-boot                fail baseline untested
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot           fail baseline untested
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot    fail baseline untested
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot        fail baseline untested
 test-amd64-i386-rhel6hvm-intel  5 xen-boot              fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot         fail baseline untested
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot    fail baseline untested
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot    fail baseline untested
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot         fail baseline untested
 test-amd64-amd64-pair         8 xen-boot/dst_host       fail baseline untested
 test-amd64-amd64-pair         7 xen-boot/src_host       fail baseline untested
 test-amd64-amd64-xl-win7-amd64  5 xen-boot              fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot        fail baseline untested
 test-amd64-i386-xl-winxpsp3   5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot        fail baseline untested
 test-amd64-i386-xl-win7-amd64  5 xen-boot               fail baseline untested
 test-amd64-i386-rumpuserxen-i386  5 xen-boot            fail baseline untested
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-boot   fail baseline untested
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot             fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot          fail baseline untested
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot   fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot    fail baseline untested
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot        fail baseline untested
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot          fail baseline untested
 test-amd64-i386-pair          8 xen-boot/dst_host       fail baseline untested
 test-amd64-i386-pair          7 xen-boot/src_host       fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot           fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot          fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot          fail baseline untested
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                fail baseline untested

version targeted for testing:
 linux                29340b8ee0b4def844aa8d6b09babcede80993d2
baseline version:
 linux                b914c5b2130239fd378d1a719ab3c53f0c782be9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          fail    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 23:47:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 23: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 1Xuriy-00039K-70; Sat, 29 Nov 2014 23:46: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@citrix.com>) id 1Xurix-00039F-0G
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 23:46:47 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	AF/ED-24124-6EA5A745; Sat, 29 Nov 2014 23:46:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417304803!8748873!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32647 invoked from network); 29 Nov 2014 23:46:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 23:46:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,485,1413244800"; d="scan'208";a="197749478"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 18:46:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xurir-0000tP-M5;
	Sat, 29 Nov 2014 23:46:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xurir-0006Cg-G7;
	Sat, 29 Nov 2014 23:46:41 +0000
Date: Sat, 29 Nov 2014 23:46:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31916-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31916: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31916 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31916/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt      4 xen-install               fail REGR. vs. 31855
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 31855

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31855

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                db12451decf7dfe0f083564183e135f2095228b9
baseline version:
 qemuu                ca6028185d19d3f2bd331c15175c3ef5afc30c77

------------------------------------------------------------
People who touched revisions under test:
  Christian Borntraeger <borntraeger@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  Don Slutz <dslutz@verizon.com>
  Eric Blake <eblake@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Jason Wang <jasowang@redhat.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Markus Armbruster <armbru@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 db12451decf7dfe0f083564183e135f2095228b9
Author: David Gibson <david@gibson.dropbear.id.au>
Date:   Thu Nov 27 16:48:10 2014 +1100

    Fix for crash after migration in virtio-rng on bi-endian targets
    
    VirtIO devices now remember which endianness they're operating in in order
    to support targets which may have guests of either endianness, such as
    powerpc.  This endianness state is transferred in a subsection of the
    virtio device's information.
    
    With virtio-rng this can lead to an abort after a loadvm hitting the
    assert() in virtio_is_big_endian().  This can be reproduced by doing a
    migrate and load from file on a bi-endian target with a virtio-rng device.
    The actual guest state isn't particularly important to triggering this.
    
    The cause is that virtio_rng_load_device() calls virtio_rng_process() which
    accesses the ring and thus needs the endianness.  However,
    virtio_rng_process() is called via virtio_load() before it loads the
    subsections.  Essentially the ->load callback in VirtioDeviceClass should
    only be used for actually reading the device state from the stream, not for
    post-load re-initialization.
    
    This patch fixes the bug by moving the virtio_rng_process() after the call
    to virtio_load().  Better yet would be to convert virtio to use vmsd and
    have the virtio_rng_process() as a post_load callback, but that's a bigger
    project for another day.
    
    This is bugfix, and should be considered for the 2.2 branch.
    
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
    Reviewed-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
    Message-id: 1417067290-20715-1-git-send-email-david@gibson.dropbear.id.au
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 771b6ed37e3aa188a7485560b949a41c6cf174dc
Author: Jason Wang <jasowang@redhat.com>
Date:   Thu Nov 27 18:04:03 2014 +0800

    virtio-net: fix unmap leak
    
    virtio_net_handle_ctrl() and other functions that process control vq
    request call iov_discard_front() which will shorten the iov. This will
    lead unmapping in virtqueue_push() leaks mapping.
    
    Fixes this by keeping the original iov untouched and using a temp variable
    in those functions.
    
    Cc: Wen Congyang <wency@cn.fujitsu.com>
    Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Reviewed-by: Fam Zheng <famz@redhat.com>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Message-id: 1417082643-23907-1-git-send-email-jasowang@redhat.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 4cae4d5acaea23f3def84c8dc67ef5106323e5cb
Author: Marcel Apfelbaum <marcel.a@redhat.com>
Date:   Wed Nov 26 13:50:01 2014 +0200

    hmp: fix regression of HMP device_del auto-completion
    
    The commits:
     - 6a1fa9f5 (monitor: add del completion for peripheral device)
     - 66e56b13 (qdev: add qdev_build_hotpluggable_device_list helper)
    
    cause a QEMU crash when trying to use HMP device_del auto-completion.
    It can be easily reproduced by:
        <qemu-bin> -enable-kvm  ~/images/fedora.qcow2 -monitor stdio -device virtio-net-pci,id=vnet
    
        (qemu) device_del
        /home/mapfelba/git/upstream/qemu/hw/core/qdev.c:941:qdev_build_hotpluggable_device_list: Object 0x7f6ce04e4fe0 is not an instance of type device
        Aborted (core dumped)
    
    The root cause is qdev_build_hotpluggable_device_list going recursively over
    all peripherals and their children assuming all are devices. It doesn't work
    since PCI devices have at least on child which is a memory region (bus master).
    
    Solved by observing that all devices appear as direct children of
    /machine/peripheral container. No need of going recursively
    over all the children.
    
    Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
    Reported-by: Gal Hammer <ghammer@redhat.com>
    Reviewed-by: Igor Mammedov <imammedo@redhat.com>
    Message-id: 1417002601-20799-1-git-send-email-marcel.a@redhat.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 490309fcfbed9fa1ed357541f609975016a34628
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Nov 25 18:21:45 2014 +0000

    qemu-timer: Avoid overflows when converting timeout to struct timespec
    
    In qemu_poll_ns(), when we convert an int64_t nanosecond timeout into
    a struct timespec, we may accidentally run into overflow problems if
    the timeout is very long. This happens because the tv_sec field is a
    time_t, which is signed, so we might end up setting it to a negative
    value by mistake. This will result in what was intended to be a
    near-infinite timeout turning into an instantaneous timeout, and we'll
    busy loop. Cap the maximum timeout at INT32_MAX seconds (about 68 years)
    to avoid this problem.
    
    This specifically manifested on ARM hosts as an extreme slowdown on
    guest shutdown (when the guest reprogrammed the PL031 RTC to not
    generate alarms using a very long timeout) but could happen on other
    hosts and guests too.
    
    Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Fam Zheng <famz@redhat.com>
    Message-id: 1416939705-1272-1-git-send-email-peter.maydell@linaro.org

commit 3ef4ebcc5c0360629bb05f49d9b961774247d6ca
Merge: 2528043 dc622de
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Nov 26 12:18:00 2014 +0000

    Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
    
    The final 2.2 patches from me.
    
    # gpg: Signature made Wed 26 Nov 2014 11:12:25 GMT using RSA key ID 78C7AE83
    # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
    # gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>"
    # gpg: WARNING: This key is not certified with sufficiently trusted signatures!
    # gpg:          It is not certain that the signature belongs to the owner.
    # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
    #      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83
    
    * remotes/bonzini/tags/for-upstream:
      s390x/kvm: Fix compile error
      fw_cfg: fix boot order bug when dynamically modified via QOM
      -machine vmport=auto: Fix handling of VMWare ioport emulation for xen
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit dc622deb2d49aac6afa485f9025be8fed440ef3d
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Wed Nov 26 11:07:24 2014 +0100

    s390x/kvm: Fix compile error
    
    commit a2b257d6212a "memory: expose alignment used for allocating RAM
    as MemoryRegion API" triggered a compile error on KVM/s390x.
    
    Fix the prototype and the implementation of legacy_s390_alloc.
    
    Cc: Igor Mammedov <imammedo@redhat.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit f3b3766899fc0a79a175a5d29d0ff427327cd34a
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Tue Nov 25 12:38:19 2014 +0800

    fw_cfg: fix boot order bug when dynamically modified via QOM
    
    When we dynamically modify boot order, the length of
    boot order will be changed, but we don't update
    s->files->f[i].size with new length. This casuse
    seabios read a wrong vale of qemu cfg file about
    bootorder.
    
    Cc: Gerd Hoffmann <kraxel@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit d1048bef9df0aacde9a54bf9b5b97a6e10950d8c
Author: Don Slutz <dslutz@verizon.com>
Date:   Fri Nov 21 11:18:52 2014 -0500

    -machine vmport=auto: Fix handling of VMWare ioport emulation for xen
    
    c/s 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
    
    or
    
    c/s b154537ad07598377ebf98252fb7d2aff127983b
    
    moved the testing of xen_enabled() from pc_init1() to
    pc_machine_initfn().
    
    xen_enabled() does not return the correct value in
    pc_machine_initfn().
    
    Changed vmport from a bool to an enum.  Added the value "auto" to do
    the old way.  Move check of xen_enabled() back to pc_init1().
    
    Acked-by: Eric Blake <eblake@redhat.com>
    Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
    Signed-off-by: Don Slutz <dslutz@verizon.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 2528043f1f299e0e88cb026f1ca7c40bbb4e1f80
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Nov 25 18:23:54 2014 +0000

    Update version for v2.2.0-rc3 release
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit df5b2adb7398d71016ee469f71e52075ed95e04e
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue Nov 25 14:54:17 2014 +0100

    input: move input-send-event into experimental namespace
    
    Ongoing discussions on how we are going to specify the console,
    so tag the command as experiental so we can refine things in
    the 2.3 development cycle.
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Message-id: 1416923657-10614-1-git-send-email-armbru@redhat.com
    [Spell out "not a stable API", and x- the QAPI schema, too]
    Signed-off-by: Markus Armbruster <armbru@redhat.com>
    Reviewed-by: Amos Kong <akong@redhat.com>
    Reviewed-by: Eric Blake <eblake@redhat.com>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Nov 29 23:47:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Nov 2014 23: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 1Xuriy-00039K-70; Sat, 29 Nov 2014 23:46: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@citrix.com>) id 1Xurix-00039F-0G
	for xen-devel@lists.xensource.com; Sat, 29 Nov 2014 23:46:47 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	AF/ED-24124-6EA5A745; Sat, 29 Nov 2014 23:46:46 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417304803!8748873!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32647 invoked from network); 29 Nov 2014 23:46:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2014 23:46:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,485,1413244800"; d="scan'208";a="197749478"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 18:46:41 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xurir-0000tP-M5;
	Sat, 29 Nov 2014 23:46:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xurir-0006Cg-G7;
	Sat, 29 Nov 2014 23:46:41 +0000
Date: Sat, 29 Nov 2014 23:46:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31916-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 31916: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31916 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31916/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt      4 xen-install               fail REGR. vs. 31855
 test-armhf-armhf-xl           9 guest-start               fail REGR. vs. 31855

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31855

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                db12451decf7dfe0f083564183e135f2095228b9
baseline version:
 qemuu                ca6028185d19d3f2bd331c15175c3ef5afc30c77

------------------------------------------------------------
People who touched revisions under test:
  Christian Borntraeger <borntraeger@de.ibm.com>
  David Gibson <david@gibson.dropbear.id.au>
  Don Slutz <dslutz@verizon.com>
  Eric Blake <eblake@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Jason Wang <jasowang@redhat.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Markus Armbruster <armbru@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 db12451decf7dfe0f083564183e135f2095228b9
Author: David Gibson <david@gibson.dropbear.id.au>
Date:   Thu Nov 27 16:48:10 2014 +1100

    Fix for crash after migration in virtio-rng on bi-endian targets
    
    VirtIO devices now remember which endianness they're operating in in order
    to support targets which may have guests of either endianness, such as
    powerpc.  This endianness state is transferred in a subsection of the
    virtio device's information.
    
    With virtio-rng this can lead to an abort after a loadvm hitting the
    assert() in virtio_is_big_endian().  This can be reproduced by doing a
    migrate and load from file on a bi-endian target with a virtio-rng device.
    The actual guest state isn't particularly important to triggering this.
    
    The cause is that virtio_rng_load_device() calls virtio_rng_process() which
    accesses the ring and thus needs the endianness.  However,
    virtio_rng_process() is called via virtio_load() before it loads the
    subsections.  Essentially the ->load callback in VirtioDeviceClass should
    only be used for actually reading the device state from the stream, not for
    post-load re-initialization.
    
    This patch fixes the bug by moving the virtio_rng_process() after the call
    to virtio_load().  Better yet would be to convert virtio to use vmsd and
    have the virtio_rng_process() as a post_load callback, but that's a bigger
    project for another day.
    
    This is bugfix, and should be considered for the 2.2 branch.
    
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
    Reviewed-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
    Message-id: 1417067290-20715-1-git-send-email-david@gibson.dropbear.id.au
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 771b6ed37e3aa188a7485560b949a41c6cf174dc
Author: Jason Wang <jasowang@redhat.com>
Date:   Thu Nov 27 18:04:03 2014 +0800

    virtio-net: fix unmap leak
    
    virtio_net_handle_ctrl() and other functions that process control vq
    request call iov_discard_front() which will shorten the iov. This will
    lead unmapping in virtqueue_push() leaks mapping.
    
    Fixes this by keeping the original iov untouched and using a temp variable
    in those functions.
    
    Cc: Wen Congyang <wency@cn.fujitsu.com>
    Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Reviewed-by: Fam Zheng <famz@redhat.com>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Message-id: 1417082643-23907-1-git-send-email-jasowang@redhat.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 4cae4d5acaea23f3def84c8dc67ef5106323e5cb
Author: Marcel Apfelbaum <marcel.a@redhat.com>
Date:   Wed Nov 26 13:50:01 2014 +0200

    hmp: fix regression of HMP device_del auto-completion
    
    The commits:
     - 6a1fa9f5 (monitor: add del completion for peripheral device)
     - 66e56b13 (qdev: add qdev_build_hotpluggable_device_list helper)
    
    cause a QEMU crash when trying to use HMP device_del auto-completion.
    It can be easily reproduced by:
        <qemu-bin> -enable-kvm  ~/images/fedora.qcow2 -monitor stdio -device virtio-net-pci,id=vnet
    
        (qemu) device_del
        /home/mapfelba/git/upstream/qemu/hw/core/qdev.c:941:qdev_build_hotpluggable_device_list: Object 0x7f6ce04e4fe0 is not an instance of type device
        Aborted (core dumped)
    
    The root cause is qdev_build_hotpluggable_device_list going recursively over
    all peripherals and their children assuming all are devices. It doesn't work
    since PCI devices have at least on child which is a memory region (bus master).
    
    Solved by observing that all devices appear as direct children of
    /machine/peripheral container. No need of going recursively
    over all the children.
    
    Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
    Reported-by: Gal Hammer <ghammer@redhat.com>
    Reviewed-by: Igor Mammedov <imammedo@redhat.com>
    Message-id: 1417002601-20799-1-git-send-email-marcel.a@redhat.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 490309fcfbed9fa1ed357541f609975016a34628
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Nov 25 18:21:45 2014 +0000

    qemu-timer: Avoid overflows when converting timeout to struct timespec
    
    In qemu_poll_ns(), when we convert an int64_t nanosecond timeout into
    a struct timespec, we may accidentally run into overflow problems if
    the timeout is very long. This happens because the tv_sec field is a
    time_t, which is signed, so we might end up setting it to a negative
    value by mistake. This will result in what was intended to be a
    near-infinite timeout turning into an instantaneous timeout, and we'll
    busy loop. Cap the maximum timeout at INT32_MAX seconds (about 68 years)
    to avoid this problem.
    
    This specifically manifested on ARM hosts as an extreme slowdown on
    guest shutdown (when the guest reprogrammed the PL031 RTC to not
    generate alarms using a very long timeout) but could happen on other
    hosts and guests too.
    
    Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Fam Zheng <famz@redhat.com>
    Message-id: 1416939705-1272-1-git-send-email-peter.maydell@linaro.org

commit 3ef4ebcc5c0360629bb05f49d9b961774247d6ca
Merge: 2528043 dc622de
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Nov 26 12:18:00 2014 +0000

    Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
    
    The final 2.2 patches from me.
    
    # gpg: Signature made Wed 26 Nov 2014 11:12:25 GMT using RSA key ID 78C7AE83
    # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
    # gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>"
    # gpg: WARNING: This key is not certified with sufficiently trusted signatures!
    # gpg:          It is not certain that the signature belongs to the owner.
    # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
    #      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83
    
    * remotes/bonzini/tags/for-upstream:
      s390x/kvm: Fix compile error
      fw_cfg: fix boot order bug when dynamically modified via QOM
      -machine vmport=auto: Fix handling of VMWare ioport emulation for xen
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit dc622deb2d49aac6afa485f9025be8fed440ef3d
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Wed Nov 26 11:07:24 2014 +0100

    s390x/kvm: Fix compile error
    
    commit a2b257d6212a "memory: expose alignment used for allocating RAM
    as MemoryRegion API" triggered a compile error on KVM/s390x.
    
    Fix the prototype and the implementation of legacy_s390_alloc.
    
    Cc: Igor Mammedov <imammedo@redhat.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit f3b3766899fc0a79a175a5d29d0ff427327cd34a
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Tue Nov 25 12:38:19 2014 +0800

    fw_cfg: fix boot order bug when dynamically modified via QOM
    
    When we dynamically modify boot order, the length of
    boot order will be changed, but we don't update
    s->files->f[i].size with new length. This casuse
    seabios read a wrong vale of qemu cfg file about
    bootorder.
    
    Cc: Gerd Hoffmann <kraxel@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit d1048bef9df0aacde9a54bf9b5b97a6e10950d8c
Author: Don Slutz <dslutz@verizon.com>
Date:   Fri Nov 21 11:18:52 2014 -0500

    -machine vmport=auto: Fix handling of VMWare ioport emulation for xen
    
    c/s 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
    
    or
    
    c/s b154537ad07598377ebf98252fb7d2aff127983b
    
    moved the testing of xen_enabled() from pc_init1() to
    pc_machine_initfn().
    
    xen_enabled() does not return the correct value in
    pc_machine_initfn().
    
    Changed vmport from a bool to an enum.  Added the value "auto" to do
    the old way.  Move check of xen_enabled() back to pc_init1().
    
    Acked-by: Eric Blake <eblake@redhat.com>
    Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
    Signed-off-by: Don Slutz <dslutz@verizon.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 2528043f1f299e0e88cb026f1ca7c40bbb4e1f80
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Nov 25 18:23:54 2014 +0000

    Update version for v2.2.0-rc3 release
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit df5b2adb7398d71016ee469f71e52075ed95e04e
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue Nov 25 14:54:17 2014 +0100

    input: move input-send-event into experimental namespace
    
    Ongoing discussions on how we are going to specify the console,
    so tag the command as experiental so we can refine things in
    the 2.3 development cycle.
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Message-id: 1416923657-10614-1-git-send-email-armbru@redhat.com
    [Spell out "not a stable API", and x- the QAPI schema, too]
    Signed-off-by: Markus Armbruster <armbru@redhat.com>
    Reviewed-by: Amos Kong <akong@redhat.com>
    Reviewed-by: Eric Blake <eblake@redhat.com>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 00:30:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 00:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XusOy-0003u4-4U; Sun, 30 Nov 2014 00:30:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jtweaver@hawaii.edu>) id 1XusOx-0003tz-BY
	for xen-devel@lists.xen.org; Sun, 30 Nov 2014 00:30:11 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	96/6D-14727-2156A745; Sun, 30 Nov 2014 00:30:10 +0000
X-Env-Sender: jtweaver@hawaii.edu
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417307408!14026499!1
X-Originating-IP: [209.85.220.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22210 invoked from network); 30 Nov 2014 00:30:10 -0000
Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com)
	(209.85.220.44)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 00:30:09 -0000
Received: by mail-pa0-f44.google.com with SMTP id et14so8766795pad.17
	for <xen-devel@lists.xen.org>; Sat, 29 Nov 2014 16:30:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version
	:content-type:content-transfer-encoding;
	bh=CvTpVwBIQs8kj+7lD3oUhUyxbN6obLPgan884zHQL/I=;
	b=nIz3cs6vTQK7WnqC8bnufqZlNfHKJMZ6NYiVs6cc4g3a9wbGDMe6rhXvITvNOYBqPn
	XzgOUI/zo3ya1jgDJT3aGANMKF35rnT70jyKq8tBGl29tUOxjlZ/WR0M0cWRUX2kYFQO
	wvv0hue5wnuPpS5NdPoicihmH1hMQ4gNMWMk3pwfVrN6zHSt+MLcXtWTTrauaea3cTDL
	MFStHBWQNKlISEWG5QRxXFlHuE6igPyK9AkKM/6oLXNez0SCOt8xe4Xjc8oFMiD8W+TO
	aLu0cs14t3/VGoDJ/UF2JVUBzXfJvkUVyGAX2mlCAZDe3/Ntb3TRgHfgVVYtITJrW9J/
	QK3A==
X-Gm-Message-State: ALoCoQkK+HdXTeqw+FzgGWcOP0XtufOytc2tvubWCmulXlNMVKZGUHZlsB/Q5o3NdxfmiSxaFmqK
X-Received: by 10.66.155.2 with SMTP id vs2mr85798929pab.135.1417307408329;
	Sat, 29 Nov 2014 16:30:08 -0800 (PST)
Received: from localhost.localdomain (cpe-72-130-152-21.hawaii.res.rr.com.
	[72.130.152.21])
	by mx.google.com with ESMTPSA id ty7sm7289151pac.1.2014.11.29.16.30.06
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 29 Nov 2014 16:30:07 -0800 (PST)
From: "Justin T. Weaver" <jtweaver@hawaii.edu>
To: xen-devel@lists.xen.org
Date: Sat, 29 Nov 2014 14:33:24 -1000
Message-Id: <1417307606-2950-1-git-send-email-jtweaver@hawaii.edu>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Content-Length:1419
Cc: george.dunlap@eu.citrix.com, dario.faggioli@citrix.com, henric@hawaii.edu
Subject: [Xen-devel] [PATCH 0/2] Credit2: introduce per-vcpu hard and soft
	affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8sCgpUaGUgY3JlZGl0MiBzY2hlZHVsZXIgY3VycmVudGx5IGlnbm9yZXMgcGVyLXZjcHUg
aGFyZCBhbmQgc29mdCBhZmZpbml0eQptYXNrcy4KClRoZSBmaXJzdCBwYXRjaCB1cGRhdGVzIHRo
ZSBzY2hlZHVsZXIgdG8gZW5zdXJlIHRoYXQgdmNwdXMgb25seSBydW4Kb24gcGNwdXMgb24gd2hp
Y2ggdGhleSBhcmUgYWxsb3dlZCB0byBydW4gKGhhcmQgYWZmaW5pdHkpLgoKVGhlIHNlY29uZCBw
YXRjaCB1cGRhdGVzIHRoZSBzY2hlZHVsZXIgdG8gbWFrZSBtb3JlIGluZm9ybWVkIHJ1biBxdWV1
ZQphc3NpZ25tZW50IGRlY2lzaW9ucyBieSBjb25zaWRlcmluZyB3aGljaCBwY3B1cyB0aGF0IHZj
cHVzIHByZWZlciB0bwpydW4gb24gKHNvZnQgYWZmaW5pdHkpLgoKSSB0ZXN0ZWQgdGhpcyBzZXJp
ZXMgb24gYSBOVU1BIG1hY2hpbmUgd2l0aCBEYXJpbyBGYWdnaW9saSdzICJmaXgKcGVyLXNvY2tl
dCBydW5xdWV1ZSBzZXR1cCIgcGF0Y2ggc2VyaWVzIGFwcGxpZWQuIFdpdGhvdXQgaXQsIHRoZSBj
cmVkaXQyCnNjaGVkdWxlciBvbmx5IGNyZWF0ZXMgb25lIHJ1biBxdWV1ZSwgcmVnYXJkbGVzcyBv
ZiB0aGUgdHlwZSBvZiBtYWNoaW5lLgoKLS0tCltQQVRDSCAxLzJdIHNjaGVkOiBjcmVkaXQyOiBy
ZXNwZWN0IHBlci12Y3B1IGhhcmQgYWZmaW5pdHkKW1BBVENIIDIvMl0gc2NoZWQ6IGNyZWRpdDI6
IGNvbnNpZGVyIHBlci12Y3B1IHNvZnQgYWZmaW5pdHkKCiB4ZW4vY29tbW9uL3NjaGVkX2NyZWRp
dDIuYyB8ICA0MTkgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0K
IDEgZmlsZSBjaGFuZ2VkLCAzODggaW5zZXJ0aW9ucygrKSwgMzEgZGVsZXRpb25zKC0pCgotLS0K
Ckp1c3RpbiBXZWF2ZXIsIE1hc3RlcnMgY2FuZGlkYXRlClVuaXZlcnNpdHkgb2YgSGF3YWnKu2kg
YXQgTcSBbm9hCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Sun Nov 30 00:30:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 00:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XusOy-0003u4-4U; Sun, 30 Nov 2014 00:30:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jtweaver@hawaii.edu>) id 1XusOx-0003tz-BY
	for xen-devel@lists.xen.org; Sun, 30 Nov 2014 00:30:11 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	96/6D-14727-2156A745; Sun, 30 Nov 2014 00:30:10 +0000
X-Env-Sender: jtweaver@hawaii.edu
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417307408!14026499!1
X-Originating-IP: [209.85.220.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22210 invoked from network); 30 Nov 2014 00:30:10 -0000
Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com)
	(209.85.220.44)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 00:30:09 -0000
Received: by mail-pa0-f44.google.com with SMTP id et14so8766795pad.17
	for <xen-devel@lists.xen.org>; Sat, 29 Nov 2014 16:30:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version
	:content-type:content-transfer-encoding;
	bh=CvTpVwBIQs8kj+7lD3oUhUyxbN6obLPgan884zHQL/I=;
	b=nIz3cs6vTQK7WnqC8bnufqZlNfHKJMZ6NYiVs6cc4g3a9wbGDMe6rhXvITvNOYBqPn
	XzgOUI/zo3ya1jgDJT3aGANMKF35rnT70jyKq8tBGl29tUOxjlZ/WR0M0cWRUX2kYFQO
	wvv0hue5wnuPpS5NdPoicihmH1hMQ4gNMWMk3pwfVrN6zHSt+MLcXtWTTrauaea3cTDL
	MFStHBWQNKlISEWG5QRxXFlHuE6igPyK9AkKM/6oLXNez0SCOt8xe4Xjc8oFMiD8W+TO
	aLu0cs14t3/VGoDJ/UF2JVUBzXfJvkUVyGAX2mlCAZDe3/Ntb3TRgHfgVVYtITJrW9J/
	QK3A==
X-Gm-Message-State: ALoCoQkK+HdXTeqw+FzgGWcOP0XtufOytc2tvubWCmulXlNMVKZGUHZlsB/Q5o3NdxfmiSxaFmqK
X-Received: by 10.66.155.2 with SMTP id vs2mr85798929pab.135.1417307408329;
	Sat, 29 Nov 2014 16:30:08 -0800 (PST)
Received: from localhost.localdomain (cpe-72-130-152-21.hawaii.res.rr.com.
	[72.130.152.21])
	by mx.google.com with ESMTPSA id ty7sm7289151pac.1.2014.11.29.16.30.06
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 29 Nov 2014 16:30:07 -0800 (PST)
From: "Justin T. Weaver" <jtweaver@hawaii.edu>
To: xen-devel@lists.xen.org
Date: Sat, 29 Nov 2014 14:33:24 -1000
Message-Id: <1417307606-2950-1-git-send-email-jtweaver@hawaii.edu>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Content-Length:1419
Cc: george.dunlap@eu.citrix.com, dario.faggioli@citrix.com, henric@hawaii.edu
Subject: [Xen-devel] [PATCH 0/2] Credit2: introduce per-vcpu hard and soft
	affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8sCgpUaGUgY3JlZGl0MiBzY2hlZHVsZXIgY3VycmVudGx5IGlnbm9yZXMgcGVyLXZjcHUg
aGFyZCBhbmQgc29mdCBhZmZpbml0eQptYXNrcy4KClRoZSBmaXJzdCBwYXRjaCB1cGRhdGVzIHRo
ZSBzY2hlZHVsZXIgdG8gZW5zdXJlIHRoYXQgdmNwdXMgb25seSBydW4Kb24gcGNwdXMgb24gd2hp
Y2ggdGhleSBhcmUgYWxsb3dlZCB0byBydW4gKGhhcmQgYWZmaW5pdHkpLgoKVGhlIHNlY29uZCBw
YXRjaCB1cGRhdGVzIHRoZSBzY2hlZHVsZXIgdG8gbWFrZSBtb3JlIGluZm9ybWVkIHJ1biBxdWV1
ZQphc3NpZ25tZW50IGRlY2lzaW9ucyBieSBjb25zaWRlcmluZyB3aGljaCBwY3B1cyB0aGF0IHZj
cHVzIHByZWZlciB0bwpydW4gb24gKHNvZnQgYWZmaW5pdHkpLgoKSSB0ZXN0ZWQgdGhpcyBzZXJp
ZXMgb24gYSBOVU1BIG1hY2hpbmUgd2l0aCBEYXJpbyBGYWdnaW9saSdzICJmaXgKcGVyLXNvY2tl
dCBydW5xdWV1ZSBzZXR1cCIgcGF0Y2ggc2VyaWVzIGFwcGxpZWQuIFdpdGhvdXQgaXQsIHRoZSBj
cmVkaXQyCnNjaGVkdWxlciBvbmx5IGNyZWF0ZXMgb25lIHJ1biBxdWV1ZSwgcmVnYXJkbGVzcyBv
ZiB0aGUgdHlwZSBvZiBtYWNoaW5lLgoKLS0tCltQQVRDSCAxLzJdIHNjaGVkOiBjcmVkaXQyOiBy
ZXNwZWN0IHBlci12Y3B1IGhhcmQgYWZmaW5pdHkKW1BBVENIIDIvMl0gc2NoZWQ6IGNyZWRpdDI6
IGNvbnNpZGVyIHBlci12Y3B1IHNvZnQgYWZmaW5pdHkKCiB4ZW4vY29tbW9uL3NjaGVkX2NyZWRp
dDIuYyB8ICA0MTkgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0K
IDEgZmlsZSBjaGFuZ2VkLCAzODggaW5zZXJ0aW9ucygrKSwgMzEgZGVsZXRpb25zKC0pCgotLS0K
Ckp1c3RpbiBXZWF2ZXIsIE1hc3RlcnMgY2FuZGlkYXRlClVuaXZlcnNpdHkgb2YgSGF3YWnKu2kg
YXQgTcSBbm9hCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Sun Nov 30 00:30:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 00: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 1XusPK-0003vJ-Hp; Sun, 30 Nov 2014 00:30:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jtweaver@hawaii.edu>) id 1XusPJ-0003v4-8N
	for xen-devel@lists.xen.org; Sun, 30 Nov 2014 00:30:33 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	30/43-25276-8256A745; Sun, 30 Nov 2014 00:30:32 +0000
X-Env-Sender: jtweaver@hawaii.edu
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417307429!12296311!1
X-Originating-IP: [209.85.220.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26466 invoked from network); 30 Nov 2014 00:30:31 -0000
Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com)
	(209.85.220.50)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 00:30:31 -0000
Received: by mail-pa0-f50.google.com with SMTP id bj1so8754601pad.37
	for <xen-devel@lists.xen.org>; Sat, 29 Nov 2014 16:30:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=j8Td40EySKPxbk4hFuM54r6HhQ1GzhoYQJ9QdX3PnCM=;
	b=MU17/xljhkHjVZialo/YG5ysu6NF5BMn3+7WlqS8QwzFxZNcU5tAr3eGXd0IxGeHe1
	STMEBiTZC2M3kGudm1sMUX9zq1Mg/139ZZbDvGrFlo1BE5Z4lNEVTuQN2+RdHRQKBOoZ
	n8G/aYCWJdaKwNcehUMexF1OT6hoTO2yVi2Hq5nRjS5OFYJLCZ2zb2HflsjATQriwHr3
	kI570DPvXOci8KQUO+mvjuXEunsBm6C5C82z2/nVAu2P5k7LbyteYOraB9aLExe2pkjF
	PrNFA2XVYXpWRIvcauwGS/IsRue+n7Ju+3QvdihzOcIL4QvVkB7ZUWKbGcbL5/VJy697
	UXVg==
X-Gm-Message-State: ALoCoQlz7cBHYu6HbwWHUTgRL/WolzPu9/vRtJKH22dIyCIWJ5P1L+uHv1xnzaIvdAS7B9D+lpUL
X-Received: by 10.66.118.201 with SMTP id ko9mr87403949pab.46.1417307429590;
	Sat, 29 Nov 2014 16:30:29 -0800 (PST)
Received: from localhost.localdomain (cpe-72-130-152-21.hawaii.res.rr.com.
	[72.130.152.21])
	by mx.google.com with ESMTPSA id ty7sm7289151pac.1.2014.11.29.16.30.27
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 29 Nov 2014 16:30:28 -0800 (PST)
From: "Justin T. Weaver" <jtweaver@hawaii.edu>
To: xen-devel@lists.xen.org
Date: Sat, 29 Nov 2014 14:33:25 -1000
Message-Id: <1417307606-2950-2-git-send-email-jtweaver@hawaii.edu>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417307606-2950-1-git-send-email-jtweaver@hawaii.edu>
References: <1417307606-2950-1-git-send-email-jtweaver@hawaii.edu>
Cc: george.dunlap@eu.citrix.com, dario.faggioli@citrix.com,
	"Justin T. Weaver" <jtweaver@hawaii.edu>, henric@hawaii.edu
Subject: [Xen-devel] [PATCH 1/2] sched: credit2: respect per-vcpu hard
	affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 making sure that vcpus only run on the pcpu(s) they are allowed to
run on based on their hard affinity cpu masks.

Signed-off-by: Justin T. Weaver <jtweaver@hawaii.edu>
---
 xen/common/sched_credit2.c |  199 +++++++++++++++++++++++++++++++++++++-------
 1 file changed, 171 insertions(+), 28 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 1bcd6c0..90e9cdf 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -501,8 +501,9 @@ runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *
         goto tickle;
     }
     
-    /* Get a mask of idle, but not tickled */
+    /* Get a mask of idle, but not tickled, that new is allowed to run on. */
     cpumask_andnot(&mask, &rqd->idle, &rqd->tickled);
+    cpumask_and(&mask, &mask, new->vcpu->cpu_hard_affinity);
     
     /* If it's not empty, choose one */
     i = cpumask_cycle(cpu, &mask);
@@ -513,9 +514,11 @@ runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *
     }
 
     /* Otherwise, look for the non-idle cpu with the lowest credit,
-     * skipping cpus which have been tickled but not scheduled yet */
+     * skipping cpus which have been tickled but not scheduled yet,
+     * that new is allowed to run on. */
     cpumask_andnot(&mask, &rqd->active, &rqd->idle);
     cpumask_andnot(&mask, &mask, &rqd->tickled);
+    cpumask_and(&mask, &mask, new->vcpu->cpu_hard_affinity);
 
     for_each_cpu(i, &mask)
     {
@@ -1038,6 +1041,7 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
     int i, min_rqi = -1, new_cpu;
     struct csched2_vcpu *svc = CSCHED2_VCPU(vc);
     s_time_t min_avgload;
+    cpumask_t temp_mask;
 
     BUG_ON(cpumask_empty(&prv->active_queues));
 
@@ -1053,7 +1057,7 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
      *
      * Since one of the runqueue locks is already held, we can't
      * just grab the prv lock.  Instead, we'll have to trylock, and
-     * do something else reasonable if we fail.
+     * return a safe cpu.
      */
 
     if ( !spin_trylock(&prv->lock) )
@@ -1063,9 +1067,23 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
             d2printk("%pv -\n", svc->vcpu);
             clear_bit(__CSFLAG_runq_migrate_request, &svc->flags);
         }
-        /* Leave it where it is for now.  When we actually pay attention
-         * to affinity we'll have to figure something out... */
-        return vc->processor;
+
+        /* Check vc's hard affinity mask with the run queue's active mask. */
+        cpumask_and(&temp_mask, vc->cpu_hard_affinity, &svc->rqd->active);
+        if ( cpumask_empty(&temp_mask) )
+        {
+            /* Can't be assigned to current runqueue; return a safe pcpu. */
+            cpumask_and(&temp_mask, vc->cpu_hard_affinity,
+                cpupool_online_cpumask(vc->domain->cpupool));
+            return cpumask_any(&temp_mask);
+        }
+        else
+            if ( cpumask_test_cpu(vc->processor, &temp_mask) )
+                /* Leave it where it is. */
+                return vc->processor;
+            else
+                /* Same runq, different cpu; affinity must have changed. */
+                return cpumask_any(&temp_mask);
     }
 
     /* First check to see if we're here because someone else suggested a place
@@ -1081,13 +1099,17 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
         else
         {
             d2printk("%pv +\n", svc->vcpu);
-            new_cpu = cpumask_cycle(vc->processor, &svc->migrate_rqd->active);
-            goto out_up;
+            cpumask_and(&temp_mask, vc->cpu_hard_affinity,
+                &svc->migrate_rqd->active);
+            if ( !cpumask_empty(&temp_mask) )
+            {
+                new_cpu = cpumask_any(&temp_mask);
+                goto out_up;
+            }
+            /* Fall-through to normal cpu pick */
         }
     }
 
-    /* FIXME: Pay attention to cpu affinity */                                                                                      
-
     min_avgload = MAX_LOAD;
 
     /* Find the runqueue with the lowest instantaneous load */
@@ -1099,17 +1121,26 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
         rqd = prv->rqd + i;
 
         /* If checking a different runqueue, grab the lock,
-         * read the avg, and then release the lock.
+         * check hard affinity, read the avg, and then release the lock.
          *
          * If on our own runqueue, don't grab or release the lock;
          * but subtract our own load from the runqueue load to simulate
          * impartiality */
         if ( rqd == svc->rqd )
         {
+            cpumask_and(&temp_mask, vc->cpu_hard_affinity, &rqd->active);
+            if ( cpumask_empty(&temp_mask) )
+                continue;
             rqd_avgload = rqd->b_avgload - svc->avgload;
         }
         else if ( spin_trylock(&rqd->lock) )
         {
+            cpumask_and(&temp_mask, vc->cpu_hard_affinity, &rqd->active);
+            if ( cpumask_empty(&temp_mask) )
+            {
+                spin_unlock(&rqd->lock);
+                continue;
+            }
             rqd_avgload = rqd->b_avgload;
             spin_unlock(&rqd->lock);
         }
@@ -1123,12 +1154,30 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
         }
     }
 
-    /* We didn't find anyone (most likely because of spinlock contention); leave it where it is */
     if ( min_rqi == -1 )
-        new_cpu = vc->processor;
+    {
+        /* No runqs found (most likely because of spinlock contention). */
+        cpumask_and(&temp_mask, vc->cpu_hard_affinity, &svc->rqd->active);
+        if ( cpumask_empty(&temp_mask) )
+        {
+            /* Can't be assigned to current runqueue; return a safe pcpu. */
+            cpumask_and(&temp_mask, vc->cpu_hard_affinity,
+                cpupool_online_cpumask(vc->domain->cpupool));
+            new_cpu = cpumask_any(&temp_mask);
+        }
+        else
+            if ( cpumask_test_cpu(vc->processor, &temp_mask) )
+                /* Leave it where it is. */
+                new_cpu = vc->processor;
+            else
+                /* Same runq, different cpu; affinity must have changed. */
+                new_cpu = cpumask_any(&temp_mask);
+    }
     else
     {
-        new_cpu = cpumask_cycle(vc->processor, &prv->rqd[min_rqi].active);
+        cpumask_and(&temp_mask, vc->cpu_hard_affinity,
+            &prv->rqd[min_rqi].active);
+        new_cpu = cpumask_any(&temp_mask);
         BUG_ON(new_cpu >= nr_cpu_ids);
     }
 
@@ -1197,22 +1246,40 @@ static void migrate(const struct scheduler *ops,
     }
     else
     {
-        int on_runq=0;
-        /* It's not running; just move it */
+        /* It's not running; move it if it's on a different runq than trqd. */
+        bool_t on_runq = 0;
+        cpumask_t temp_mask;
+
         d2printk("%pv %d-%d i\n", svc->vcpu, svc->rqd->id, trqd->id);
+
+        /* Re-assign vcpu's processor, if necessary. */
+        cpumask_and(&temp_mask, svc->vcpu->cpu_hard_affinity, &trqd->active);
+        svc->vcpu->processor = cpumask_any(&temp_mask);
+        if ( !cpumask_test_cpu(svc->vcpu->processor, &temp_mask) )
+            svc->vcpu->processor = cpumask_any(&temp_mask);
+
         if ( __vcpu_on_runq(svc) )
+            on_runq = 1;
+
+        /* If the runqs are different, move svc to trqd. */
+        if ( svc->rqd != trqd )
         {
-            __runq_remove(svc);
-            update_load(ops, svc->rqd, svc, -1, now);
-            on_runq=1;
+            if ( on_runq )
+            {
+                __runq_remove(svc);
+                update_load(ops, svc->rqd, svc, -1, now);
+            }
+            __runq_deassign(svc);
+            __runq_assign(svc, trqd);
+            if ( on_runq )
+            {
+                update_load(ops, svc->rqd, svc, 1, now);
+                runq_insert(ops, svc->vcpu->processor, svc);
+            }
         }
-        __runq_deassign(svc);
-        svc->vcpu->processor = cpumask_any(&trqd->active);
-        __runq_assign(svc, trqd);
+
         if ( on_runq )
         {
-            update_load(ops, svc->rqd, svc, 1, now);
-            runq_insert(ops, svc->vcpu->processor, svc);
             runq_tickle(ops, svc->vcpu->processor, svc, now);
         }
     }
@@ -1224,6 +1291,7 @@ static void balance_load(const struct scheduler *ops, int cpu, s_time_t now)
     struct csched2_private *prv = CSCHED2_PRIV(ops);
     int i, max_delta_rqi = -1;
     struct list_head *push_iter, *pull_iter;
+    cpumask_t temp_mask;
 
     balance_state_t st = { .best_push_svc = NULL, .best_pull_svc = NULL };
     
@@ -1250,6 +1318,11 @@ retry:
     for_each_cpu(i, &prv->active_queues)
     {
         s_time_t delta;
+        /* true if there are no vcpus to push due to hard affinity */
+        bool_t ha_no_push = 1;
+        /* true if there are no vcpus to pull due to hard affinity */
+        bool_t ha_no_pull = 1;
+        struct list_head *iter;
         
         st.orqd = prv->rqd + i;
 
@@ -1257,6 +1330,47 @@ retry:
              || !spin_trylock(&st.orqd->lock) )
             continue;
 
+        /*
+         * If due to hard affinity there are no vcpus that can be
+         * pulled or pushed, move to the next runq in the loop.
+         */
+
+        /* See if there are any vcpus that can be pushed from lrqd to orqd. */
+        list_for_each( iter, &st.lrqd->svc )
+        {
+            struct csched2_vcpu * svc =
+                list_entry(iter, struct csched2_vcpu, rqd_elem);
+            cpumask_and(&temp_mask, svc->vcpu->cpu_hard_affinity,
+                &st.orqd->active);
+            if (!cpumask_empty(&temp_mask))
+            {
+                /* vcpu can be pushed from lrqd to ordq. */
+                ha_no_push = 0;
+                break;
+            }
+        }
+
+        /* See if there are any vcpus that can be pulled from orqd to lrqd. */
+        list_for_each( iter, &st.orqd->svc )
+        {
+            struct csched2_vcpu * svc =
+                list_entry(iter, struct csched2_vcpu, rqd_elem);
+            cpumask_and(&temp_mask, svc->vcpu->cpu_hard_affinity,
+                &st.lrqd->active);
+            if (!cpumask_empty(&temp_mask))
+            {
+                /* vcpu can be pulled from orqd to lrdq. */
+                ha_no_pull = 0;
+                break;
+            }
+        }
+
+        if ( ha_no_push && ha_no_pull )
+        {
+            spin_unlock(&st.orqd->lock);
+            continue;
+        }
+
         __update_runq_load(ops, st.orqd, 0, now);
     
         delta = st.lrqd->b_avgload - st.orqd->b_avgload;
@@ -1330,6 +1444,12 @@ retry:
         if ( test_bit(__CSFLAG_runq_migrate_request, &push_svc->flags) )
             continue;
 
+        /* Skip if it can't run on the destination runq. */
+        cpumask_and(&temp_mask, push_svc->vcpu->cpu_hard_affinity,
+            &st.orqd->active);
+        if ( cpumask_empty(&temp_mask) )
+            continue;
+
         list_for_each( pull_iter, &st.orqd->svc )
         {
             struct csched2_vcpu * pull_svc = list_entry(pull_iter, struct csched2_vcpu, rqd_elem);
@@ -1338,11 +1458,17 @@ retry:
             {
                 __update_svc_load(ops, pull_svc, 0, now);
             }
-        
+
             /* Skip this one if it's already been flagged to migrate */
             if ( test_bit(__CSFLAG_runq_migrate_request, &pull_svc->flags) )
                 continue;
 
+            /* Skip if it can't run on the destination runq. */
+            cpumask_and(&temp_mask, pull_svc->vcpu->cpu_hard_affinity,
+                &st.lrqd->active);
+            if ( cpumask_empty(&temp_mask) )
+                continue;
+
             consider(&st, push_svc, pull_svc);
         }
 
@@ -1355,11 +1481,17 @@ retry:
     list_for_each( pull_iter, &st.orqd->svc )
     {
         struct csched2_vcpu * pull_svc = list_entry(pull_iter, struct csched2_vcpu, rqd_elem);
-        
+
         /* Skip this one if it's already been flagged to migrate */
         if ( test_bit(__CSFLAG_runq_migrate_request, &pull_svc->flags) )
             continue;
 
+        /* Skip if it can't run on the destination runq. */
+        cpumask_and(&temp_mask, pull_svc->vcpu->cpu_hard_affinity,
+            &st.lrqd->active);
+        if ( cpumask_empty(&temp_mask) )
+            continue;
+
         /* Consider pull only */
         consider(&st, NULL, pull_svc);
     }
@@ -1399,8 +1531,12 @@ csched2_vcpu_migrate(
 
     trqd = RQD(ops, new_cpu);
 
-    if ( trqd != svc->rqd )
-        migrate(ops, svc, trqd, NOW());
+    /*
+     * Call migrate even if svc->rqd == trqd; there may have been an
+     * affinity change that requires a call to runq_tickle for a new
+     * processor within the same run queue.
+     */
+    migrate(ops, svc, trqd, NOW());
 }
 
 static int
@@ -1610,6 +1746,13 @@ runq_candidate(struct csched2_runqueue_data *rqd,
     {
         struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu, runq_elem);
 
+        /*
+         * If vcpu is not allowed to run on this processor due to
+         * hard affinity, continue to the next vcpu on the queue.
+         */
+        if ( !cpumask_test_cpu(cpu, svc->vcpu->cpu_hard_affinity) )
+            continue;
+
         /* If this is on a different processor, don't pull it unless
          * its credit is at least CSCHED2_MIGRATE_RESIST higher. */
         if ( svc->vcpu->processor != cpu
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 00:30:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 00: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 1XusPK-0003vJ-Hp; Sun, 30 Nov 2014 00:30:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jtweaver@hawaii.edu>) id 1XusPJ-0003v4-8N
	for xen-devel@lists.xen.org; Sun, 30 Nov 2014 00:30:33 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	30/43-25276-8256A745; Sun, 30 Nov 2014 00:30:32 +0000
X-Env-Sender: jtweaver@hawaii.edu
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417307429!12296311!1
X-Originating-IP: [209.85.220.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26466 invoked from network); 30 Nov 2014 00:30:31 -0000
Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com)
	(209.85.220.50)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 00:30:31 -0000
Received: by mail-pa0-f50.google.com with SMTP id bj1so8754601pad.37
	for <xen-devel@lists.xen.org>; Sat, 29 Nov 2014 16:30:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=j8Td40EySKPxbk4hFuM54r6HhQ1GzhoYQJ9QdX3PnCM=;
	b=MU17/xljhkHjVZialo/YG5ysu6NF5BMn3+7WlqS8QwzFxZNcU5tAr3eGXd0IxGeHe1
	STMEBiTZC2M3kGudm1sMUX9zq1Mg/139ZZbDvGrFlo1BE5Z4lNEVTuQN2+RdHRQKBOoZ
	n8G/aYCWJdaKwNcehUMexF1OT6hoTO2yVi2Hq5nRjS5OFYJLCZ2zb2HflsjATQriwHr3
	kI570DPvXOci8KQUO+mvjuXEunsBm6C5C82z2/nVAu2P5k7LbyteYOraB9aLExe2pkjF
	PrNFA2XVYXpWRIvcauwGS/IsRue+n7Ju+3QvdihzOcIL4QvVkB7ZUWKbGcbL5/VJy697
	UXVg==
X-Gm-Message-State: ALoCoQlz7cBHYu6HbwWHUTgRL/WolzPu9/vRtJKH22dIyCIWJ5P1L+uHv1xnzaIvdAS7B9D+lpUL
X-Received: by 10.66.118.201 with SMTP id ko9mr87403949pab.46.1417307429590;
	Sat, 29 Nov 2014 16:30:29 -0800 (PST)
Received: from localhost.localdomain (cpe-72-130-152-21.hawaii.res.rr.com.
	[72.130.152.21])
	by mx.google.com with ESMTPSA id ty7sm7289151pac.1.2014.11.29.16.30.27
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 29 Nov 2014 16:30:28 -0800 (PST)
From: "Justin T. Weaver" <jtweaver@hawaii.edu>
To: xen-devel@lists.xen.org
Date: Sat, 29 Nov 2014 14:33:25 -1000
Message-Id: <1417307606-2950-2-git-send-email-jtweaver@hawaii.edu>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417307606-2950-1-git-send-email-jtweaver@hawaii.edu>
References: <1417307606-2950-1-git-send-email-jtweaver@hawaii.edu>
Cc: george.dunlap@eu.citrix.com, dario.faggioli@citrix.com,
	"Justin T. Weaver" <jtweaver@hawaii.edu>, henric@hawaii.edu
Subject: [Xen-devel] [PATCH 1/2] sched: credit2: respect per-vcpu hard
	affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 making sure that vcpus only run on the pcpu(s) they are allowed to
run on based on their hard affinity cpu masks.

Signed-off-by: Justin T. Weaver <jtweaver@hawaii.edu>
---
 xen/common/sched_credit2.c |  199 +++++++++++++++++++++++++++++++++++++-------
 1 file changed, 171 insertions(+), 28 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 1bcd6c0..90e9cdf 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -501,8 +501,9 @@ runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *
         goto tickle;
     }
     
-    /* Get a mask of idle, but not tickled */
+    /* Get a mask of idle, but not tickled, that new is allowed to run on. */
     cpumask_andnot(&mask, &rqd->idle, &rqd->tickled);
+    cpumask_and(&mask, &mask, new->vcpu->cpu_hard_affinity);
     
     /* If it's not empty, choose one */
     i = cpumask_cycle(cpu, &mask);
@@ -513,9 +514,11 @@ runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *
     }
 
     /* Otherwise, look for the non-idle cpu with the lowest credit,
-     * skipping cpus which have been tickled but not scheduled yet */
+     * skipping cpus which have been tickled but not scheduled yet,
+     * that new is allowed to run on. */
     cpumask_andnot(&mask, &rqd->active, &rqd->idle);
     cpumask_andnot(&mask, &mask, &rqd->tickled);
+    cpumask_and(&mask, &mask, new->vcpu->cpu_hard_affinity);
 
     for_each_cpu(i, &mask)
     {
@@ -1038,6 +1041,7 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
     int i, min_rqi = -1, new_cpu;
     struct csched2_vcpu *svc = CSCHED2_VCPU(vc);
     s_time_t min_avgload;
+    cpumask_t temp_mask;
 
     BUG_ON(cpumask_empty(&prv->active_queues));
 
@@ -1053,7 +1057,7 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
      *
      * Since one of the runqueue locks is already held, we can't
      * just grab the prv lock.  Instead, we'll have to trylock, and
-     * do something else reasonable if we fail.
+     * return a safe cpu.
      */
 
     if ( !spin_trylock(&prv->lock) )
@@ -1063,9 +1067,23 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
             d2printk("%pv -\n", svc->vcpu);
             clear_bit(__CSFLAG_runq_migrate_request, &svc->flags);
         }
-        /* Leave it where it is for now.  When we actually pay attention
-         * to affinity we'll have to figure something out... */
-        return vc->processor;
+
+        /* Check vc's hard affinity mask with the run queue's active mask. */
+        cpumask_and(&temp_mask, vc->cpu_hard_affinity, &svc->rqd->active);
+        if ( cpumask_empty(&temp_mask) )
+        {
+            /* Can't be assigned to current runqueue; return a safe pcpu. */
+            cpumask_and(&temp_mask, vc->cpu_hard_affinity,
+                cpupool_online_cpumask(vc->domain->cpupool));
+            return cpumask_any(&temp_mask);
+        }
+        else
+            if ( cpumask_test_cpu(vc->processor, &temp_mask) )
+                /* Leave it where it is. */
+                return vc->processor;
+            else
+                /* Same runq, different cpu; affinity must have changed. */
+                return cpumask_any(&temp_mask);
     }
 
     /* First check to see if we're here because someone else suggested a place
@@ -1081,13 +1099,17 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
         else
         {
             d2printk("%pv +\n", svc->vcpu);
-            new_cpu = cpumask_cycle(vc->processor, &svc->migrate_rqd->active);
-            goto out_up;
+            cpumask_and(&temp_mask, vc->cpu_hard_affinity,
+                &svc->migrate_rqd->active);
+            if ( !cpumask_empty(&temp_mask) )
+            {
+                new_cpu = cpumask_any(&temp_mask);
+                goto out_up;
+            }
+            /* Fall-through to normal cpu pick */
         }
     }
 
-    /* FIXME: Pay attention to cpu affinity */                                                                                      
-
     min_avgload = MAX_LOAD;
 
     /* Find the runqueue with the lowest instantaneous load */
@@ -1099,17 +1121,26 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
         rqd = prv->rqd + i;
 
         /* If checking a different runqueue, grab the lock,
-         * read the avg, and then release the lock.
+         * check hard affinity, read the avg, and then release the lock.
          *
          * If on our own runqueue, don't grab or release the lock;
          * but subtract our own load from the runqueue load to simulate
          * impartiality */
         if ( rqd == svc->rqd )
         {
+            cpumask_and(&temp_mask, vc->cpu_hard_affinity, &rqd->active);
+            if ( cpumask_empty(&temp_mask) )
+                continue;
             rqd_avgload = rqd->b_avgload - svc->avgload;
         }
         else if ( spin_trylock(&rqd->lock) )
         {
+            cpumask_and(&temp_mask, vc->cpu_hard_affinity, &rqd->active);
+            if ( cpumask_empty(&temp_mask) )
+            {
+                spin_unlock(&rqd->lock);
+                continue;
+            }
             rqd_avgload = rqd->b_avgload;
             spin_unlock(&rqd->lock);
         }
@@ -1123,12 +1154,30 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
         }
     }
 
-    /* We didn't find anyone (most likely because of spinlock contention); leave it where it is */
     if ( min_rqi == -1 )
-        new_cpu = vc->processor;
+    {
+        /* No runqs found (most likely because of spinlock contention). */
+        cpumask_and(&temp_mask, vc->cpu_hard_affinity, &svc->rqd->active);
+        if ( cpumask_empty(&temp_mask) )
+        {
+            /* Can't be assigned to current runqueue; return a safe pcpu. */
+            cpumask_and(&temp_mask, vc->cpu_hard_affinity,
+                cpupool_online_cpumask(vc->domain->cpupool));
+            new_cpu = cpumask_any(&temp_mask);
+        }
+        else
+            if ( cpumask_test_cpu(vc->processor, &temp_mask) )
+                /* Leave it where it is. */
+                new_cpu = vc->processor;
+            else
+                /* Same runq, different cpu; affinity must have changed. */
+                new_cpu = cpumask_any(&temp_mask);
+    }
     else
     {
-        new_cpu = cpumask_cycle(vc->processor, &prv->rqd[min_rqi].active);
+        cpumask_and(&temp_mask, vc->cpu_hard_affinity,
+            &prv->rqd[min_rqi].active);
+        new_cpu = cpumask_any(&temp_mask);
         BUG_ON(new_cpu >= nr_cpu_ids);
     }
 
@@ -1197,22 +1246,40 @@ static void migrate(const struct scheduler *ops,
     }
     else
     {
-        int on_runq=0;
-        /* It's not running; just move it */
+        /* It's not running; move it if it's on a different runq than trqd. */
+        bool_t on_runq = 0;
+        cpumask_t temp_mask;
+
         d2printk("%pv %d-%d i\n", svc->vcpu, svc->rqd->id, trqd->id);
+
+        /* Re-assign vcpu's processor, if necessary. */
+        cpumask_and(&temp_mask, svc->vcpu->cpu_hard_affinity, &trqd->active);
+        svc->vcpu->processor = cpumask_any(&temp_mask);
+        if ( !cpumask_test_cpu(svc->vcpu->processor, &temp_mask) )
+            svc->vcpu->processor = cpumask_any(&temp_mask);
+
         if ( __vcpu_on_runq(svc) )
+            on_runq = 1;
+
+        /* If the runqs are different, move svc to trqd. */
+        if ( svc->rqd != trqd )
         {
-            __runq_remove(svc);
-            update_load(ops, svc->rqd, svc, -1, now);
-            on_runq=1;
+            if ( on_runq )
+            {
+                __runq_remove(svc);
+                update_load(ops, svc->rqd, svc, -1, now);
+            }
+            __runq_deassign(svc);
+            __runq_assign(svc, trqd);
+            if ( on_runq )
+            {
+                update_load(ops, svc->rqd, svc, 1, now);
+                runq_insert(ops, svc->vcpu->processor, svc);
+            }
         }
-        __runq_deassign(svc);
-        svc->vcpu->processor = cpumask_any(&trqd->active);
-        __runq_assign(svc, trqd);
+
         if ( on_runq )
         {
-            update_load(ops, svc->rqd, svc, 1, now);
-            runq_insert(ops, svc->vcpu->processor, svc);
             runq_tickle(ops, svc->vcpu->processor, svc, now);
         }
     }
@@ -1224,6 +1291,7 @@ static void balance_load(const struct scheduler *ops, int cpu, s_time_t now)
     struct csched2_private *prv = CSCHED2_PRIV(ops);
     int i, max_delta_rqi = -1;
     struct list_head *push_iter, *pull_iter;
+    cpumask_t temp_mask;
 
     balance_state_t st = { .best_push_svc = NULL, .best_pull_svc = NULL };
     
@@ -1250,6 +1318,11 @@ retry:
     for_each_cpu(i, &prv->active_queues)
     {
         s_time_t delta;
+        /* true if there are no vcpus to push due to hard affinity */
+        bool_t ha_no_push = 1;
+        /* true if there are no vcpus to pull due to hard affinity */
+        bool_t ha_no_pull = 1;
+        struct list_head *iter;
         
         st.orqd = prv->rqd + i;
 
@@ -1257,6 +1330,47 @@ retry:
              || !spin_trylock(&st.orqd->lock) )
             continue;
 
+        /*
+         * If due to hard affinity there are no vcpus that can be
+         * pulled or pushed, move to the next runq in the loop.
+         */
+
+        /* See if there are any vcpus that can be pushed from lrqd to orqd. */
+        list_for_each( iter, &st.lrqd->svc )
+        {
+            struct csched2_vcpu * svc =
+                list_entry(iter, struct csched2_vcpu, rqd_elem);
+            cpumask_and(&temp_mask, svc->vcpu->cpu_hard_affinity,
+                &st.orqd->active);
+            if (!cpumask_empty(&temp_mask))
+            {
+                /* vcpu can be pushed from lrqd to ordq. */
+                ha_no_push = 0;
+                break;
+            }
+        }
+
+        /* See if there are any vcpus that can be pulled from orqd to lrqd. */
+        list_for_each( iter, &st.orqd->svc )
+        {
+            struct csched2_vcpu * svc =
+                list_entry(iter, struct csched2_vcpu, rqd_elem);
+            cpumask_and(&temp_mask, svc->vcpu->cpu_hard_affinity,
+                &st.lrqd->active);
+            if (!cpumask_empty(&temp_mask))
+            {
+                /* vcpu can be pulled from orqd to lrdq. */
+                ha_no_pull = 0;
+                break;
+            }
+        }
+
+        if ( ha_no_push && ha_no_pull )
+        {
+            spin_unlock(&st.orqd->lock);
+            continue;
+        }
+
         __update_runq_load(ops, st.orqd, 0, now);
     
         delta = st.lrqd->b_avgload - st.orqd->b_avgload;
@@ -1330,6 +1444,12 @@ retry:
         if ( test_bit(__CSFLAG_runq_migrate_request, &push_svc->flags) )
             continue;
 
+        /* Skip if it can't run on the destination runq. */
+        cpumask_and(&temp_mask, push_svc->vcpu->cpu_hard_affinity,
+            &st.orqd->active);
+        if ( cpumask_empty(&temp_mask) )
+            continue;
+
         list_for_each( pull_iter, &st.orqd->svc )
         {
             struct csched2_vcpu * pull_svc = list_entry(pull_iter, struct csched2_vcpu, rqd_elem);
@@ -1338,11 +1458,17 @@ retry:
             {
                 __update_svc_load(ops, pull_svc, 0, now);
             }
-        
+
             /* Skip this one if it's already been flagged to migrate */
             if ( test_bit(__CSFLAG_runq_migrate_request, &pull_svc->flags) )
                 continue;
 
+            /* Skip if it can't run on the destination runq. */
+            cpumask_and(&temp_mask, pull_svc->vcpu->cpu_hard_affinity,
+                &st.lrqd->active);
+            if ( cpumask_empty(&temp_mask) )
+                continue;
+
             consider(&st, push_svc, pull_svc);
         }
 
@@ -1355,11 +1481,17 @@ retry:
     list_for_each( pull_iter, &st.orqd->svc )
     {
         struct csched2_vcpu * pull_svc = list_entry(pull_iter, struct csched2_vcpu, rqd_elem);
-        
+
         /* Skip this one if it's already been flagged to migrate */
         if ( test_bit(__CSFLAG_runq_migrate_request, &pull_svc->flags) )
             continue;
 
+        /* Skip if it can't run on the destination runq. */
+        cpumask_and(&temp_mask, pull_svc->vcpu->cpu_hard_affinity,
+            &st.lrqd->active);
+        if ( cpumask_empty(&temp_mask) )
+            continue;
+
         /* Consider pull only */
         consider(&st, NULL, pull_svc);
     }
@@ -1399,8 +1531,12 @@ csched2_vcpu_migrate(
 
     trqd = RQD(ops, new_cpu);
 
-    if ( trqd != svc->rqd )
-        migrate(ops, svc, trqd, NOW());
+    /*
+     * Call migrate even if svc->rqd == trqd; there may have been an
+     * affinity change that requires a call to runq_tickle for a new
+     * processor within the same run queue.
+     */
+    migrate(ops, svc, trqd, NOW());
 }
 
 static int
@@ -1610,6 +1746,13 @@ runq_candidate(struct csched2_runqueue_data *rqd,
     {
         struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu, runq_elem);
 
+        /*
+         * If vcpu is not allowed to run on this processor due to
+         * hard affinity, continue to the next vcpu on the queue.
+         */
+        if ( !cpumask_test_cpu(cpu, svc->vcpu->cpu_hard_affinity) )
+            continue;
+
         /* If this is on a different processor, don't pull it unless
          * its credit is at least CSCHED2_MIGRATE_RESIST higher. */
         if ( svc->vcpu->processor != cpu
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 00:30:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 00:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XusPW-0003xu-V6; Sun, 30 Nov 2014 00:30:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jtweaver@hawaii.edu>) id 1XusPV-0003xf-8R
	for xen-devel@lists.xen.org; Sun, 30 Nov 2014 00:30:45 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	67/B1-27785-4356A745; Sun, 30 Nov 2014 00:30:44 +0000
X-Env-Sender: jtweaver@hawaii.edu
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417307441!11968436!1
X-Originating-IP: [209.85.220.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 911 invoked from network); 30 Nov 2014 00:30:42 -0000
Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com)
	(209.85.220.41)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 00:30:42 -0000
Received: by mail-pa0-f41.google.com with SMTP id rd3so8822863pab.0
	for <xen-devel@lists.xen.org>; Sat, 29 Nov 2014 16:30:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=2CGMNJLagTk0H05LVk4Hbc6SMg5zsThDy1QXiRQ1ph4=;
	b=FdokCgNM+O42Qw7UErZlf56dlBqF7AqlDVcZETnppmwxOtBiMcRgGyCZQYcPsi7yNS
	cGHCJY1inubc/m017Lx89wnGPSGT5d2dFTIK60XnSVfhZ5WMwmPvwBSorbt+qRsUaBwp
	ybgzu2pXgr2ouu4bLw8YJlnqsrKbmXI1DGbEOLdkzYaHjSVx5m5fOrw+9pRjV5WK/Ls3
	kIdUTn18XyxCuvwa/xtcOC1REQ5pBd4GN/Dm2y5h+uqvxGUsL3JPffrAi6mfiij9qpot
	bgFzr/XlDFH3+N9uTTmEWCuEVDYF/JQW/uMBHrFUfofHADSEgR9O0P3FSxkHQDv/XP3c
	VDyg==
X-Gm-Message-State: ALoCoQlriUaugrsDe+mkhi1b2ekNq2MkGcx+jfANNoDaAanRCNROEDN30Wz6V5Z5eHg6hUbtxCjP
X-Received: by 10.70.48.166 with SMTP id m6mr88467804pdn.22.1417307441083;
	Sat, 29 Nov 2014 16:30:41 -0800 (PST)
Received: from localhost.localdomain (cpe-72-130-152-21.hawaii.res.rr.com.
	[72.130.152.21])
	by mx.google.com with ESMTPSA id ty7sm7289151pac.1.2014.11.29.16.30.38
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 29 Nov 2014 16:30:40 -0800 (PST)
From: "Justin T. Weaver" <jtweaver@hawaii.edu>
To: xen-devel@lists.xen.org
Date: Sat, 29 Nov 2014 14:33:26 -1000
Message-Id: <1417307606-2950-3-git-send-email-jtweaver@hawaii.edu>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417307606-2950-1-git-send-email-jtweaver@hawaii.edu>
References: <1417307606-2950-1-git-send-email-jtweaver@hawaii.edu>
Cc: george.dunlap@eu.citrix.com, dario.faggioli@citrix.com,
	"Justin T. Weaver" <jtweaver@hawaii.edu>, henric@hawaii.edu
Subject: [Xen-devel] [PATCH 2/2] sched: credit2: consider per-vcpu soft
	affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 deciding which run queue to assign each vcpu to.

There are two main changes in functionality that this patch introduces.

First, in function runq_tickle, it tries to find idle pcpus in other run
queues that the vcpu would prefer to run on (soft affinity) or can run on
(hard affinity), in that order.

Second, in function balance_load, if moving a vcpu with soft affinity from
one run queue to another means moving it away from its soft affinity to hard
affinity only, then that move is not considered for load balancing.

Signed-off-by: Justin T. Weaver <jtweaver@hawaii.edu>
---
 xen/common/sched_credit2.c |  222 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 218 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 90e9cdf..ad867f2 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -127,6 +127,15 @@
 #define CSCHED2_CREDIT_RESET         0
 /* Max timer: Maximum time a guest can be run for. */
 #define CSCHED2_MAX_TIMER            MILLISECS(2)
+/* Two step balancing logic; consider soft affinity first. */
+#define CSCHED2_BALANCE_SOFT_AFFINITY 0
+#define CSCHED2_BALANCE_HARD_AFFINITY 1
+/* vcpu runq migration away from vcpu's soft affinity. */
+#define CSCHED2_MIGRATE_SOFT_TO_HARD 0
+/* vcpu runq migration to vcpu's soft affinity. */
+#define CSCHED2_MIGRATE_HARD_TO_SOFT 1
+/* vcpu runq migration soft to soft or vcpu has no soft affinity. */
+#define CSCHED2_MIGRATE_ANY_TO_ANY   2
 
 
 #define CSCHED2_IDLE_CREDIT                 (-(1<<30))
@@ -176,6 +185,8 @@ integer_param("sched_credit2_migrate_resist", opt_migrate_resist);
 #define c2r(_ops, _cpu)     (CSCHED2_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
 #define RQD(_ops, _cpu)     (&CSCHED2_PRIV(_ops)->rqd[c2r(_ops, _cpu)])
+#define for_each_csched2_balance_step(step) \
+    for ( (step) = 0; (step) <= CSCHED2_BALANCE_HARD_AFFINITY; (step)++ )
 
 /*
  * Shifts for load average.
@@ -268,6 +279,35 @@ struct csched2_dom {
     uint16_t nr_vcpus;
 };
 
+/*
+ * A vcpu has meaningful soft affinity if...
+ * - its soft affinity mask is not full, and
+ * - the passed in mask (usually its hard affinity mask) intersects
+ *   with its soft affinity mask
+ */
+static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
+                                           const cpumask_t *mask)
+{
+    if ( cpumask_full(vc->cpu_soft_affinity) ||
+        !cpumask_intersects(vc->cpu_soft_affinity, mask) )
+        return 0;
+
+    return 1;
+}
+
+static void
+csched2_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
+{
+    if ( step == CSCHED2_BALANCE_SOFT_AFFINITY )
+    {
+        cpumask_and(mask, vc->cpu_soft_affinity, vc->cpu_hard_affinity);
+
+        if ( unlikely(cpumask_empty(mask)) )
+            cpumask_copy(mask, vc->cpu_hard_affinity);
+    }
+    else /* step == CSCHED2_BALANCE_HARD_AFFINITY */
+        cpumask_copy(mask, vc->cpu_hard_affinity);
+}
 
 /*
  * Time-to-credit, credit-to-time.
@@ -474,6 +514,9 @@ __runq_remove(struct csched2_vcpu *svc)
 }
 
 void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_vcpu *, s_time_t);
+static void __runq_deassign(struct csched2_vcpu *svc);
+static void __runq_assign(struct csched2_vcpu *svc,
+                          struct csched2_runqueue_data *rqd);
 
 /* Check to see if the item on the runqueue is higher priority than what's
  * currently running; if so, wake up the processor */
@@ -485,6 +528,9 @@ runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *
     struct csched2_runqueue_data *rqd = RQD(ops, cpu);
     cpumask_t mask;
     struct csched2_vcpu * cur;
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
+    int balance_step = CSCHED2_BALANCE_SOFT_AFFINITY;
+    bool_t prv_lock_held = 0;
 
     d2printk("rqt %pv curr %pv\n", new->vcpu, current);
 
@@ -513,6 +559,68 @@ runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *
         goto tickle;
     }
 
+    /* Look for idle cpus in other runqs; consider soft affinity first. */
+    for_each_csched2_balance_step( balance_step )
+    {
+        cpumask_t balance_mask;
+
+        /* Skip the soft affinity balance step if new doesn't have any. */
+        if ( balance_step == CSCHED2_BALANCE_SOFT_AFFINITY &&
+            !__vcpu_has_soft_affinity(
+                new->vcpu, new->vcpu->cpu_hard_affinity) )
+            continue;
+
+        /* Skip this step if can't get a lock on the credit2 private data. */
+        if ( !prv_lock_held || !spin_trylock(&prv->lock) )
+            continue;
+        prv_lock_held = 1;
+
+        csched2_balance_cpumask(new->vcpu, balance_step, &balance_mask);
+
+        for_each_cpu(i, &prv->active_queues)
+        {
+            struct csched2_runqueue_data *temp_rqd;
+
+            temp_rqd = prv->rqd + i;
+
+            if ( temp_rqd == rqd || !spin_trylock(&temp_rqd->lock) )
+                continue;
+
+            /* Find idle cpus in the balance mask that are not tickled. */
+            cpumask_andnot(&mask, &temp_rqd->idle, &temp_rqd->tickled);
+            cpumask_and(&mask, &mask, &balance_mask);
+
+            if ( !cpumask_empty(&mask) )
+            {
+                /* Found an idle cpu on another run queue; move new. */
+                s_time_t now = 0;
+
+                ipid = cpumask_any(&mask);
+                new->vcpu->processor = ipid;
+                __runq_remove(new);
+                now = NOW();
+                update_load(ops, rqd, new, -1, now);
+                __runq_deassign(new);
+                __runq_assign(new, temp_rqd);
+                update_load(ops, temp_rqd, new, 1, now);
+                runq_insert(ops, ipid, new);
+                cpumask_set_cpu(ipid, &temp_rqd->tickled);
+                cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
+
+                spin_unlock(&temp_rqd->lock);
+                spin_unlock(&prv->lock);
+                return;
+            }
+            else
+                /* No suitable idlers found in runq temp_rqd. */
+                spin_unlock(&temp_rqd->lock);
+        }
+
+        if ( prv_lock_held && balance_step == CSCHED2_BALANCE_HARD_AFFINITY )
+            /* No suitable other-runq idlers found; unlock private data. */
+            spin_unlock(&prv->lock);
+    }
+
     /* Otherwise, look for the non-idle cpu with the lowest credit,
      * skipping cpus which have been tickled but not scheduled yet,
      * that new is allowed to run on. */
@@ -1039,12 +1147,22 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
 {
     struct csched2_private *prv = CSCHED2_PRIV(ops);
     int i, min_rqi = -1, new_cpu;
+    int max_soft_cpus = 0, max_soft_cpus_rqi = -1;
+    bool_t consider_soft_affinity = 0;
     struct csched2_vcpu *svc = CSCHED2_VCPU(vc);
     s_time_t min_avgload;
-    cpumask_t temp_mask;
+    cpumask_t temp_mask, vc_soft_affinity;
 
     BUG_ON(cpumask_empty(&prv->active_queues));
 
+    /* Consider soft affinity in the cpu descision? */
+    if ( __vcpu_has_soft_affinity(vc, vc->cpu_hard_affinity) )
+    {
+        consider_soft_affinity = 1;
+        cpumask_and(&vc_soft_affinity, vc->cpu_soft_affinity,
+            vc->cpu_hard_affinity);
+    }
+
     /* Locking:
      * - vc->processor is already locked
      * - Need to grab prv lock to make sure active runqueues don't
@@ -1075,6 +1193,13 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
             /* Can't be assigned to current runqueue; return a safe pcpu. */
             cpumask_and(&temp_mask, vc->cpu_hard_affinity,
                 cpupool_online_cpumask(vc->domain->cpupool));
+            if ( consider_soft_affinity )
+            {
+                cpumask_t safe_soft_mask;
+                cpumask_and(&safe_soft_mask, &vc_soft_affinity, &temp_mask);
+                if ( !cpumask_empty(&safe_soft_mask) )
+                    cpumask_copy(&temp_mask, &safe_soft_mask);
+            }
             return cpumask_any(&temp_mask);
         }
         else
@@ -1112,11 +1237,15 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
 
     min_avgload = MAX_LOAD;
 
-    /* Find the runqueue with the lowest instantaneous load */
+    /*
+     * Find the run queue with the most cpus in vc's soft affniity, or the
+     * the lowest instantaneous load if not considering soft affinity.
+     */
     for_each_cpu(i, &prv->active_queues)
     {
         struct csched2_runqueue_data *rqd;
         s_time_t rqd_avgload;
+        int rqd_soft_cpus = 0;
 
         rqd = prv->rqd + i;
 
@@ -1131,6 +1260,11 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
             cpumask_and(&temp_mask, vc->cpu_hard_affinity, &rqd->active);
             if ( cpumask_empty(&temp_mask) )
                 continue;
+            if ( consider_soft_affinity )
+            {
+                cpumask_and(&temp_mask, &vc_soft_affinity, &rqd->active);
+                rqd_soft_cpus = cpumask_weight(&temp_mask);
+            }
             rqd_avgload = rqd->b_avgload - svc->avgload;
         }
         else if ( spin_trylock(&rqd->lock) )
@@ -1141,6 +1275,11 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
                 spin_unlock(&rqd->lock);
                 continue;
             }
+            if ( consider_soft_affinity )
+            {
+                cpumask_and(&temp_mask, &vc_soft_affinity, &rqd->active);
+                rqd_soft_cpus = cpumask_weight(&temp_mask);
+            }
             rqd_avgload = rqd->b_avgload;
             spin_unlock(&rqd->lock);
         }
@@ -1152,9 +1291,14 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
             min_avgload = rqd_avgload;
             min_rqi=i;
         }
+        if ( consider_soft_affinity && rqd_soft_cpus > max_soft_cpus )
+        {
+            max_soft_cpus = rqd_soft_cpus;
+            max_soft_cpus_rqi = i;
+        }
     }
 
-    if ( min_rqi == -1 )
+    if ( min_rqi == -1 && max_soft_cpus_rqi == -1 )
     {
         /* No runqs found (most likely because of spinlock contention). */
         cpumask_and(&temp_mask, vc->cpu_hard_affinity, &svc->rqd->active);
@@ -1163,6 +1307,13 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
             /* Can't be assigned to current runqueue; return a safe pcpu. */
             cpumask_and(&temp_mask, vc->cpu_hard_affinity,
                 cpupool_online_cpumask(vc->domain->cpupool));
+            if ( consider_soft_affinity )
+            {
+                cpumask_t safe_soft_mask;
+                cpumask_and(&safe_soft_mask, &vc_soft_affinity, &temp_mask);
+                if ( !cpumask_empty(&safe_soft_mask) )
+                    cpumask_copy(&temp_mask, &safe_soft_mask);
+            }
             new_cpu = cpumask_any(&temp_mask);
         }
         else
@@ -1173,8 +1324,16 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
                 /* Same runq, different cpu; affinity must have changed. */
                 new_cpu = cpumask_any(&temp_mask);
     }
+    else if ( max_soft_cpus_rqi != -1 )
+    {
+        /* Prefer soft affinity here over minimizing run queue load. */
+        cpumask_and(&temp_mask, &vc_soft_affinity,
+            &prv->rqd[max_soft_cpus_rqi].active);
+        new_cpu = cpumask_any(&temp_mask);
+    }
     else
     {
+        /* vc does not have soft affinity; use the rq that minimizes load. */
         cpumask_and(&temp_mask, vc->cpu_hard_affinity,
             &prv->rqd[min_rqi].active);
         new_cpu = cpumask_any(&temp_mask);
@@ -1197,6 +1356,46 @@ typedef struct {
     struct csched2_runqueue_data *orqd;                  
 } balance_state_t;
 
+static int classify_vcpu_migration(const struct vcpu *vc,
+    const struct csched2_runqueue_data *src_rqd,
+    const struct csched2_runqueue_data *dst_rqd)
+{
+    cpumask_t soft_mask, temp_mask;
+
+    /*
+     * Must already hold the locks on src_rqd and dst_rqd.
+     * Function assumes vc has at least hard affinity with one or more
+     * pcpus in both the source and destination run queues.
+     */
+
+    /* Does vcpu not have soft affinity? */
+    if ( !__vcpu_has_soft_affinity(vc, vc->cpu_hard_affinity) )
+        return CSCHED2_MIGRATE_ANY_TO_ANY;
+    else
+        cpumask_and(&soft_mask, vc->cpu_soft_affinity, vc->cpu_hard_affinity);
+
+    /* Does vcpu have soft affinity with pcpu(s) in the source runq? */
+    cpumask_and(&temp_mask, &soft_mask, &src_rqd->active);
+    if ( !cpumask_empty(&temp_mask) )
+    {
+        /* ... and soft affinity with the destination runq? */
+        cpumask_and(&temp_mask, &soft_mask, &dst_rqd->active);
+        if ( !cpumask_empty(&temp_mask) )
+            return CSCHED2_MIGRATE_ANY_TO_ANY;
+        else
+            return CSCHED2_MIGRATE_SOFT_TO_HARD;
+    }
+    else
+    {
+        /* Does vcpu only have soft affinity with the destination runq? */
+        cpumask_and(&temp_mask, &soft_mask, &dst_rqd->active);
+        if ( !cpumask_empty(&temp_mask) )
+            return CSCHED2_MIGRATE_HARD_TO_SOFT;
+        else
+            return CSCHED2_MIGRATE_ANY_TO_ANY;
+    }
+}
+
 static void consider(balance_state_t *st, 
                      struct csched2_vcpu *push_svc,
                      struct csched2_vcpu *pull_svc)
@@ -1294,7 +1493,7 @@ static void balance_load(const struct scheduler *ops, int cpu, s_time_t now)
     cpumask_t temp_mask;
 
     balance_state_t st = { .best_push_svc = NULL, .best_pull_svc = NULL };
-    
+
     /*
      * Basic algorithm: Push, pull, or swap.
      * - Find the runqueue with the furthest load distance
@@ -1450,6 +1649,11 @@ retry:
         if ( cpumask_empty(&temp_mask) )
             continue;
 
+        /* Skip if result is moving vcpu away from its soft affinity. */
+        if ( classify_vcpu_migration(push_svc->vcpu, st.lrqd, st.orqd) ==
+            CSCHED2_MIGRATE_SOFT_TO_HARD )
+            continue;
+
         list_for_each( pull_iter, &st.orqd->svc )
         {
             struct csched2_vcpu * pull_svc = list_entry(pull_iter, struct csched2_vcpu, rqd_elem);
@@ -1469,6 +1673,11 @@ retry:
             if ( cpumask_empty(&temp_mask) )
                 continue;
 
+            /* Skip if result is moving vcpu away from its soft affinity. */
+            if ( classify_vcpu_migration(pull_svc->vcpu, st.orqd, st.lrqd) ==
+                CSCHED2_MIGRATE_SOFT_TO_HARD )
+                continue;
+
             consider(&st, push_svc, pull_svc);
         }
 
@@ -1492,6 +1701,11 @@ retry:
         if ( cpumask_empty(&temp_mask) )
             continue;
 
+        /* Skip if result is moving vcpu away from its soft affinity. */
+        if ( classify_vcpu_migration(pull_svc->vcpu, st.orqd, st.lrqd) ==
+            CSCHED2_MIGRATE_SOFT_TO_HARD )
+            continue;
+
         /* Consider pull only */
         consider(&st, NULL, pull_svc);
     }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 00:30:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 00:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XusPW-0003xu-V6; Sun, 30 Nov 2014 00:30:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jtweaver@hawaii.edu>) id 1XusPV-0003xf-8R
	for xen-devel@lists.xen.org; Sun, 30 Nov 2014 00:30:45 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	67/B1-27785-4356A745; Sun, 30 Nov 2014 00:30:44 +0000
X-Env-Sender: jtweaver@hawaii.edu
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417307441!11968436!1
X-Originating-IP: [209.85.220.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 911 invoked from network); 30 Nov 2014 00:30:42 -0000
Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com)
	(209.85.220.41)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 00:30:42 -0000
Received: by mail-pa0-f41.google.com with SMTP id rd3so8822863pab.0
	for <xen-devel@lists.xen.org>; Sat, 29 Nov 2014 16:30:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=2CGMNJLagTk0H05LVk4Hbc6SMg5zsThDy1QXiRQ1ph4=;
	b=FdokCgNM+O42Qw7UErZlf56dlBqF7AqlDVcZETnppmwxOtBiMcRgGyCZQYcPsi7yNS
	cGHCJY1inubc/m017Lx89wnGPSGT5d2dFTIK60XnSVfhZ5WMwmPvwBSorbt+qRsUaBwp
	ybgzu2pXgr2ouu4bLw8YJlnqsrKbmXI1DGbEOLdkzYaHjSVx5m5fOrw+9pRjV5WK/Ls3
	kIdUTn18XyxCuvwa/xtcOC1REQ5pBd4GN/Dm2y5h+uqvxGUsL3JPffrAi6mfiij9qpot
	bgFzr/XlDFH3+N9uTTmEWCuEVDYF/JQW/uMBHrFUfofHADSEgR9O0P3FSxkHQDv/XP3c
	VDyg==
X-Gm-Message-State: ALoCoQlriUaugrsDe+mkhi1b2ekNq2MkGcx+jfANNoDaAanRCNROEDN30Wz6V5Z5eHg6hUbtxCjP
X-Received: by 10.70.48.166 with SMTP id m6mr88467804pdn.22.1417307441083;
	Sat, 29 Nov 2014 16:30:41 -0800 (PST)
Received: from localhost.localdomain (cpe-72-130-152-21.hawaii.res.rr.com.
	[72.130.152.21])
	by mx.google.com with ESMTPSA id ty7sm7289151pac.1.2014.11.29.16.30.38
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 29 Nov 2014 16:30:40 -0800 (PST)
From: "Justin T. Weaver" <jtweaver@hawaii.edu>
To: xen-devel@lists.xen.org
Date: Sat, 29 Nov 2014 14:33:26 -1000
Message-Id: <1417307606-2950-3-git-send-email-jtweaver@hawaii.edu>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417307606-2950-1-git-send-email-jtweaver@hawaii.edu>
References: <1417307606-2950-1-git-send-email-jtweaver@hawaii.edu>
Cc: george.dunlap@eu.citrix.com, dario.faggioli@citrix.com,
	"Justin T. Weaver" <jtweaver@hawaii.edu>, henric@hawaii.edu
Subject: [Xen-devel] [PATCH 2/2] sched: credit2: consider per-vcpu soft
	affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 deciding which run queue to assign each vcpu to.

There are two main changes in functionality that this patch introduces.

First, in function runq_tickle, it tries to find idle pcpus in other run
queues that the vcpu would prefer to run on (soft affinity) or can run on
(hard affinity), in that order.

Second, in function balance_load, if moving a vcpu with soft affinity from
one run queue to another means moving it away from its soft affinity to hard
affinity only, then that move is not considered for load balancing.

Signed-off-by: Justin T. Weaver <jtweaver@hawaii.edu>
---
 xen/common/sched_credit2.c |  222 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 218 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 90e9cdf..ad867f2 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -127,6 +127,15 @@
 #define CSCHED2_CREDIT_RESET         0
 /* Max timer: Maximum time a guest can be run for. */
 #define CSCHED2_MAX_TIMER            MILLISECS(2)
+/* Two step balancing logic; consider soft affinity first. */
+#define CSCHED2_BALANCE_SOFT_AFFINITY 0
+#define CSCHED2_BALANCE_HARD_AFFINITY 1
+/* vcpu runq migration away from vcpu's soft affinity. */
+#define CSCHED2_MIGRATE_SOFT_TO_HARD 0
+/* vcpu runq migration to vcpu's soft affinity. */
+#define CSCHED2_MIGRATE_HARD_TO_SOFT 1
+/* vcpu runq migration soft to soft or vcpu has no soft affinity. */
+#define CSCHED2_MIGRATE_ANY_TO_ANY   2
 
 
 #define CSCHED2_IDLE_CREDIT                 (-(1<<30))
@@ -176,6 +185,8 @@ integer_param("sched_credit2_migrate_resist", opt_migrate_resist);
 #define c2r(_ops, _cpu)     (CSCHED2_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
 #define RQD(_ops, _cpu)     (&CSCHED2_PRIV(_ops)->rqd[c2r(_ops, _cpu)])
+#define for_each_csched2_balance_step(step) \
+    for ( (step) = 0; (step) <= CSCHED2_BALANCE_HARD_AFFINITY; (step)++ )
 
 /*
  * Shifts for load average.
@@ -268,6 +279,35 @@ struct csched2_dom {
     uint16_t nr_vcpus;
 };
 
+/*
+ * A vcpu has meaningful soft affinity if...
+ * - its soft affinity mask is not full, and
+ * - the passed in mask (usually its hard affinity mask) intersects
+ *   with its soft affinity mask
+ */
+static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
+                                           const cpumask_t *mask)
+{
+    if ( cpumask_full(vc->cpu_soft_affinity) ||
+        !cpumask_intersects(vc->cpu_soft_affinity, mask) )
+        return 0;
+
+    return 1;
+}
+
+static void
+csched2_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
+{
+    if ( step == CSCHED2_BALANCE_SOFT_AFFINITY )
+    {
+        cpumask_and(mask, vc->cpu_soft_affinity, vc->cpu_hard_affinity);
+
+        if ( unlikely(cpumask_empty(mask)) )
+            cpumask_copy(mask, vc->cpu_hard_affinity);
+    }
+    else /* step == CSCHED2_BALANCE_HARD_AFFINITY */
+        cpumask_copy(mask, vc->cpu_hard_affinity);
+}
 
 /*
  * Time-to-credit, credit-to-time.
@@ -474,6 +514,9 @@ __runq_remove(struct csched2_vcpu *svc)
 }
 
 void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_vcpu *, s_time_t);
+static void __runq_deassign(struct csched2_vcpu *svc);
+static void __runq_assign(struct csched2_vcpu *svc,
+                          struct csched2_runqueue_data *rqd);
 
 /* Check to see if the item on the runqueue is higher priority than what's
  * currently running; if so, wake up the processor */
@@ -485,6 +528,9 @@ runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *
     struct csched2_runqueue_data *rqd = RQD(ops, cpu);
     cpumask_t mask;
     struct csched2_vcpu * cur;
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
+    int balance_step = CSCHED2_BALANCE_SOFT_AFFINITY;
+    bool_t prv_lock_held = 0;
 
     d2printk("rqt %pv curr %pv\n", new->vcpu, current);
 
@@ -513,6 +559,68 @@ runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *
         goto tickle;
     }
 
+    /* Look for idle cpus in other runqs; consider soft affinity first. */
+    for_each_csched2_balance_step( balance_step )
+    {
+        cpumask_t balance_mask;
+
+        /* Skip the soft affinity balance step if new doesn't have any. */
+        if ( balance_step == CSCHED2_BALANCE_SOFT_AFFINITY &&
+            !__vcpu_has_soft_affinity(
+                new->vcpu, new->vcpu->cpu_hard_affinity) )
+            continue;
+
+        /* Skip this step if can't get a lock on the credit2 private data. */
+        if ( !prv_lock_held || !spin_trylock(&prv->lock) )
+            continue;
+        prv_lock_held = 1;
+
+        csched2_balance_cpumask(new->vcpu, balance_step, &balance_mask);
+
+        for_each_cpu(i, &prv->active_queues)
+        {
+            struct csched2_runqueue_data *temp_rqd;
+
+            temp_rqd = prv->rqd + i;
+
+            if ( temp_rqd == rqd || !spin_trylock(&temp_rqd->lock) )
+                continue;
+
+            /* Find idle cpus in the balance mask that are not tickled. */
+            cpumask_andnot(&mask, &temp_rqd->idle, &temp_rqd->tickled);
+            cpumask_and(&mask, &mask, &balance_mask);
+
+            if ( !cpumask_empty(&mask) )
+            {
+                /* Found an idle cpu on another run queue; move new. */
+                s_time_t now = 0;
+
+                ipid = cpumask_any(&mask);
+                new->vcpu->processor = ipid;
+                __runq_remove(new);
+                now = NOW();
+                update_load(ops, rqd, new, -1, now);
+                __runq_deassign(new);
+                __runq_assign(new, temp_rqd);
+                update_load(ops, temp_rqd, new, 1, now);
+                runq_insert(ops, ipid, new);
+                cpumask_set_cpu(ipid, &temp_rqd->tickled);
+                cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
+
+                spin_unlock(&temp_rqd->lock);
+                spin_unlock(&prv->lock);
+                return;
+            }
+            else
+                /* No suitable idlers found in runq temp_rqd. */
+                spin_unlock(&temp_rqd->lock);
+        }
+
+        if ( prv_lock_held && balance_step == CSCHED2_BALANCE_HARD_AFFINITY )
+            /* No suitable other-runq idlers found; unlock private data. */
+            spin_unlock(&prv->lock);
+    }
+
     /* Otherwise, look for the non-idle cpu with the lowest credit,
      * skipping cpus which have been tickled but not scheduled yet,
      * that new is allowed to run on. */
@@ -1039,12 +1147,22 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
 {
     struct csched2_private *prv = CSCHED2_PRIV(ops);
     int i, min_rqi = -1, new_cpu;
+    int max_soft_cpus = 0, max_soft_cpus_rqi = -1;
+    bool_t consider_soft_affinity = 0;
     struct csched2_vcpu *svc = CSCHED2_VCPU(vc);
     s_time_t min_avgload;
-    cpumask_t temp_mask;
+    cpumask_t temp_mask, vc_soft_affinity;
 
     BUG_ON(cpumask_empty(&prv->active_queues));
 
+    /* Consider soft affinity in the cpu descision? */
+    if ( __vcpu_has_soft_affinity(vc, vc->cpu_hard_affinity) )
+    {
+        consider_soft_affinity = 1;
+        cpumask_and(&vc_soft_affinity, vc->cpu_soft_affinity,
+            vc->cpu_hard_affinity);
+    }
+
     /* Locking:
      * - vc->processor is already locked
      * - Need to grab prv lock to make sure active runqueues don't
@@ -1075,6 +1193,13 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
             /* Can't be assigned to current runqueue; return a safe pcpu. */
             cpumask_and(&temp_mask, vc->cpu_hard_affinity,
                 cpupool_online_cpumask(vc->domain->cpupool));
+            if ( consider_soft_affinity )
+            {
+                cpumask_t safe_soft_mask;
+                cpumask_and(&safe_soft_mask, &vc_soft_affinity, &temp_mask);
+                if ( !cpumask_empty(&safe_soft_mask) )
+                    cpumask_copy(&temp_mask, &safe_soft_mask);
+            }
             return cpumask_any(&temp_mask);
         }
         else
@@ -1112,11 +1237,15 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
 
     min_avgload = MAX_LOAD;
 
-    /* Find the runqueue with the lowest instantaneous load */
+    /*
+     * Find the run queue with the most cpus in vc's soft affniity, or the
+     * the lowest instantaneous load if not considering soft affinity.
+     */
     for_each_cpu(i, &prv->active_queues)
     {
         struct csched2_runqueue_data *rqd;
         s_time_t rqd_avgload;
+        int rqd_soft_cpus = 0;
 
         rqd = prv->rqd + i;
 
@@ -1131,6 +1260,11 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
             cpumask_and(&temp_mask, vc->cpu_hard_affinity, &rqd->active);
             if ( cpumask_empty(&temp_mask) )
                 continue;
+            if ( consider_soft_affinity )
+            {
+                cpumask_and(&temp_mask, &vc_soft_affinity, &rqd->active);
+                rqd_soft_cpus = cpumask_weight(&temp_mask);
+            }
             rqd_avgload = rqd->b_avgload - svc->avgload;
         }
         else if ( spin_trylock(&rqd->lock) )
@@ -1141,6 +1275,11 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
                 spin_unlock(&rqd->lock);
                 continue;
             }
+            if ( consider_soft_affinity )
+            {
+                cpumask_and(&temp_mask, &vc_soft_affinity, &rqd->active);
+                rqd_soft_cpus = cpumask_weight(&temp_mask);
+            }
             rqd_avgload = rqd->b_avgload;
             spin_unlock(&rqd->lock);
         }
@@ -1152,9 +1291,14 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
             min_avgload = rqd_avgload;
             min_rqi=i;
         }
+        if ( consider_soft_affinity && rqd_soft_cpus > max_soft_cpus )
+        {
+            max_soft_cpus = rqd_soft_cpus;
+            max_soft_cpus_rqi = i;
+        }
     }
 
-    if ( min_rqi == -1 )
+    if ( min_rqi == -1 && max_soft_cpus_rqi == -1 )
     {
         /* No runqs found (most likely because of spinlock contention). */
         cpumask_and(&temp_mask, vc->cpu_hard_affinity, &svc->rqd->active);
@@ -1163,6 +1307,13 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
             /* Can't be assigned to current runqueue; return a safe pcpu. */
             cpumask_and(&temp_mask, vc->cpu_hard_affinity,
                 cpupool_online_cpumask(vc->domain->cpupool));
+            if ( consider_soft_affinity )
+            {
+                cpumask_t safe_soft_mask;
+                cpumask_and(&safe_soft_mask, &vc_soft_affinity, &temp_mask);
+                if ( !cpumask_empty(&safe_soft_mask) )
+                    cpumask_copy(&temp_mask, &safe_soft_mask);
+            }
             new_cpu = cpumask_any(&temp_mask);
         }
         else
@@ -1173,8 +1324,16 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
                 /* Same runq, different cpu; affinity must have changed. */
                 new_cpu = cpumask_any(&temp_mask);
     }
+    else if ( max_soft_cpus_rqi != -1 )
+    {
+        /* Prefer soft affinity here over minimizing run queue load. */
+        cpumask_and(&temp_mask, &vc_soft_affinity,
+            &prv->rqd[max_soft_cpus_rqi].active);
+        new_cpu = cpumask_any(&temp_mask);
+    }
     else
     {
+        /* vc does not have soft affinity; use the rq that minimizes load. */
         cpumask_and(&temp_mask, vc->cpu_hard_affinity,
             &prv->rqd[min_rqi].active);
         new_cpu = cpumask_any(&temp_mask);
@@ -1197,6 +1356,46 @@ typedef struct {
     struct csched2_runqueue_data *orqd;                  
 } balance_state_t;
 
+static int classify_vcpu_migration(const struct vcpu *vc,
+    const struct csched2_runqueue_data *src_rqd,
+    const struct csched2_runqueue_data *dst_rqd)
+{
+    cpumask_t soft_mask, temp_mask;
+
+    /*
+     * Must already hold the locks on src_rqd and dst_rqd.
+     * Function assumes vc has at least hard affinity with one or more
+     * pcpus in both the source and destination run queues.
+     */
+
+    /* Does vcpu not have soft affinity? */
+    if ( !__vcpu_has_soft_affinity(vc, vc->cpu_hard_affinity) )
+        return CSCHED2_MIGRATE_ANY_TO_ANY;
+    else
+        cpumask_and(&soft_mask, vc->cpu_soft_affinity, vc->cpu_hard_affinity);
+
+    /* Does vcpu have soft affinity with pcpu(s) in the source runq? */
+    cpumask_and(&temp_mask, &soft_mask, &src_rqd->active);
+    if ( !cpumask_empty(&temp_mask) )
+    {
+        /* ... and soft affinity with the destination runq? */
+        cpumask_and(&temp_mask, &soft_mask, &dst_rqd->active);
+        if ( !cpumask_empty(&temp_mask) )
+            return CSCHED2_MIGRATE_ANY_TO_ANY;
+        else
+            return CSCHED2_MIGRATE_SOFT_TO_HARD;
+    }
+    else
+    {
+        /* Does vcpu only have soft affinity with the destination runq? */
+        cpumask_and(&temp_mask, &soft_mask, &dst_rqd->active);
+        if ( !cpumask_empty(&temp_mask) )
+            return CSCHED2_MIGRATE_HARD_TO_SOFT;
+        else
+            return CSCHED2_MIGRATE_ANY_TO_ANY;
+    }
+}
+
 static void consider(balance_state_t *st, 
                      struct csched2_vcpu *push_svc,
                      struct csched2_vcpu *pull_svc)
@@ -1294,7 +1493,7 @@ static void balance_load(const struct scheduler *ops, int cpu, s_time_t now)
     cpumask_t temp_mask;
 
     balance_state_t st = { .best_push_svc = NULL, .best_pull_svc = NULL };
-    
+
     /*
      * Basic algorithm: Push, pull, or swap.
      * - Find the runqueue with the furthest load distance
@@ -1450,6 +1649,11 @@ retry:
         if ( cpumask_empty(&temp_mask) )
             continue;
 
+        /* Skip if result is moving vcpu away from its soft affinity. */
+        if ( classify_vcpu_migration(push_svc->vcpu, st.lrqd, st.orqd) ==
+            CSCHED2_MIGRATE_SOFT_TO_HARD )
+            continue;
+
         list_for_each( pull_iter, &st.orqd->svc )
         {
             struct csched2_vcpu * pull_svc = list_entry(pull_iter, struct csched2_vcpu, rqd_elem);
@@ -1469,6 +1673,11 @@ retry:
             if ( cpumask_empty(&temp_mask) )
                 continue;
 
+            /* Skip if result is moving vcpu away from its soft affinity. */
+            if ( classify_vcpu_migration(pull_svc->vcpu, st.orqd, st.lrqd) ==
+                CSCHED2_MIGRATE_SOFT_TO_HARD )
+                continue;
+
             consider(&st, push_svc, pull_svc);
         }
 
@@ -1492,6 +1701,11 @@ retry:
         if ( cpumask_empty(&temp_mask) )
             continue;
 
+        /* Skip if result is moving vcpu away from its soft affinity. */
+        if ( classify_vcpu_migration(pull_svc->vcpu, st.orqd, st.lrqd) ==
+            CSCHED2_MIGRATE_SOFT_TO_HARD )
+            continue;
+
         /* Consider pull only */
         consider(&st, NULL, pull_svc);
     }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 04:22:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 04:22:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xuw1M-0001I7-Rk; Sun, 30 Nov 2014 04:22:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xuw1K-0001I2-8Y
	for xen-devel@lists.xensource.com; Sun, 30 Nov 2014 04:22:02 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	F8/D7-02696-96B9A745; Sun, 30 Nov 2014 04:22:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417321319!7324752!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2922 invoked from network); 30 Nov 2014 04:22:00 -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;
	30 Nov 2014 04:22:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,486,1413244800"; d="scan'208";a="198086719"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 23:21:58 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xuw1G-0002Dl-3G;
	Sun, 30 Nov 2014 04:21:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xuw1F-0008W4-Rf;
	Sun, 30 Nov 2014 04:21:57 +0000
Date: Sun, 30 Nov 2014 04:21:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31922-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31922: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31922 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31922/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail pass in 31889
 test-armhf-armhf-xl           3 host-install(3)  broken in 31889 pass in 31922

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 33063 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 Nov 30 04:22:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 04:22:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xuw1M-0001I7-Rk; Sun, 30 Nov 2014 04:22:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xuw1K-0001I2-8Y
	for xen-devel@lists.xensource.com; Sun, 30 Nov 2014 04:22:02 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	F8/D7-02696-96B9A745; Sun, 30 Nov 2014 04:22:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417321319!7324752!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2922 invoked from network); 30 Nov 2014 04:22:00 -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;
	30 Nov 2014 04:22:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,486,1413244800"; d="scan'208";a="198086719"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sat, 29 Nov 2014 23:21:58 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xuw1G-0002Dl-3G;
	Sun, 30 Nov 2014 04:21:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xuw1F-0008W4-Rf;
	Sun, 30 Nov 2014 04:21:57 +0000
Date: Sun, 30 Nov 2014 04:21:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31922-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.10 test] 31922: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31922 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31922/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail pass in 31889
 test-armhf-armhf-xl           3 host-install(3)  broken in 31889 pass in 31922

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                252f23ea5987a4730e3399ef1ad5d78efcc786c9
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
774 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 33063 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 Nov 30 04:39:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 04: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 1XuwI3-0001og-RB; Sun, 30 Nov 2014 04:39:19 +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 1XuwI2-0001ob-EA
	for xen-devel@lists.xenproject.org; Sun, 30 Nov 2014 04:39:18 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	7B/8C-02957-57F9A745; Sun, 30 Nov 2014 04:39:17 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417322356!8630628!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19058 invoked from network); 30 Nov 2014 04:39:16 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-11.tower-27.messagelabs.com with SMTP;
	30 Nov 2014 04:39:16 -0000
Received: from localhost (unknown [172.56.29.234])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 5EBF358C469;
	Sat, 29 Nov 2014 20:39:13 -0800 (PST)
Date: Sat, 29 Nov 2014 20:43:23 -0800 (PST)
Message-Id: <20141129.204323.1338545932639792456.davem@davemloft.net>
To: seth.forshee@canonical.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <20141127035350.GA10833@ubuntu-mba51>
References: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
	<20141126.122812.223757363894961994.davem@davemloft.net>
	<20141127035350.GA10833@ubuntu-mba51>
X-Mailer: Mew version 6.4 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Sat, 29 Nov 2014 20:39:15 -0800 (PST)
Cc: zoltan.kiss@linaro.org, eric.dumazet@gmail.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Remove BUGs on paged skb data
 which crosses a page boundary
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Seth Forshee <seth.forshee@canonical.com>
Date: Wed, 26 Nov 2014 21:53:50 -0600

> On Wed, Nov 26, 2014 at 12:28:12PM -0500, David Miller wrote:
>> From: Seth Forshee <seth.forshee@canonical.com>
>> Date: Tue, 25 Nov 2014 20:28:24 -0600
>> 
>> > These BUGs can be erroneously triggered by frags which refer to
>> > tail pages within a compound page. The data in these pages may
>> > overrun the hardware page while still being contained within the
>> > compound page, but since compound_order() evaluates to 0 for tail
>> > pages the assertion fails. The code already iterates through
>> > subsequent pages correctly in this scenario, so the BUGs are
>> > unnecessary and can be removed.
>> > 
>> > Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
>> > Cc: <stable@vger.kernel.org> # 3.7+
>> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
>> 
>> Can I get some Xen developer reviews?
> 
> Fwiw this issue was discussed previously and this was the recommended
> fix.
> 
>  http://article.gmane.org/gmane.linux.kernel/1825381
> 
> Since then I got some feedback from a tester that he didn't see any
> problems with the BUGs removed (actually replaced with a WARN so I know
> that he actually saw the condition which triggered the BUG).

That's fine, but I still want a xen-netfront developer to review and
ACK this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 04:39:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 04: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 1XuwI3-0001og-RB; Sun, 30 Nov 2014 04:39:19 +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 1XuwI2-0001ob-EA
	for xen-devel@lists.xenproject.org; Sun, 30 Nov 2014 04:39:18 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	7B/8C-02957-57F9A745; Sun, 30 Nov 2014 04:39:17 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417322356!8630628!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19058 invoked from network); 30 Nov 2014 04:39:16 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-11.tower-27.messagelabs.com with SMTP;
	30 Nov 2014 04:39:16 -0000
Received: from localhost (unknown [172.56.29.234])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 5EBF358C469;
	Sat, 29 Nov 2014 20:39:13 -0800 (PST)
Date: Sat, 29 Nov 2014 20:43:23 -0800 (PST)
Message-Id: <20141129.204323.1338545932639792456.davem@davemloft.net>
To: seth.forshee@canonical.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <20141127035350.GA10833@ubuntu-mba51>
References: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
	<20141126.122812.223757363894961994.davem@davemloft.net>
	<20141127035350.GA10833@ubuntu-mba51>
X-Mailer: Mew version 6.4 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
	(shards.monkeyblade.net [149.20.54.216]);
	Sat, 29 Nov 2014 20:39:15 -0800 (PST)
Cc: zoltan.kiss@linaro.org, eric.dumazet@gmail.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Remove BUGs on paged skb data
 which crosses a page boundary
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Seth Forshee <seth.forshee@canonical.com>
Date: Wed, 26 Nov 2014 21:53:50 -0600

> On Wed, Nov 26, 2014 at 12:28:12PM -0500, David Miller wrote:
>> From: Seth Forshee <seth.forshee@canonical.com>
>> Date: Tue, 25 Nov 2014 20:28:24 -0600
>> 
>> > These BUGs can be erroneously triggered by frags which refer to
>> > tail pages within a compound page. The data in these pages may
>> > overrun the hardware page while still being contained within the
>> > compound page, but since compound_order() evaluates to 0 for tail
>> > pages the assertion fails. The code already iterates through
>> > subsequent pages correctly in this scenario, so the BUGs are
>> > unnecessary and can be removed.
>> > 
>> > Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
>> > Cc: <stable@vger.kernel.org> # 3.7+
>> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
>> 
>> Can I get some Xen developer reviews?
> 
> Fwiw this issue was discussed previously and this was the recommended
> fix.
> 
>  http://article.gmane.org/gmane.linux.kernel/1825381
> 
> Since then I got some feedback from a tester that he didn't see any
> problems with the BUGs removed (actually replaced with a WARN so I know
> that he actually saw the condition which triggered the BUG).

That's fine, but I still want a xen-netfront developer to review and
ACK this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 07:43:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 07:43:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xuz9I-0003EU-Tc; Sun, 30 Nov 2014 07:42: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@citrix.com>) id 1Xuz9G-0003EP-On
	for xen-devel@lists.xensource.com; Sun, 30 Nov 2014 07:42:26 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	2D/BC-28865-16ACA745; Sun, 30 Nov 2014 07:42:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417333343!14102563!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16443 invoked from network); 30 Nov 2014 07:42:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 07:42:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,486,1413244800"; d="scan'208";a="198116259"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 30 Nov 2014 02:42:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xuz9B-0003EO-Hi;
	Sun, 30 Nov 2014 07:42:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xuz9B-00013a-5z;
	Sun, 30 Nov 2014 07:42:21 +0000
Date: Sun, 30 Nov 2014 07:42:21 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31928-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31928: 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 31928 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31928/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              6085d917d5c5839b7ed351e99fadbbb56f5178fe
baseline version:
 libvirt              7296e896c92c64ec5653095bcc2ed86b6a72a7d5

------------------------------------------------------------
People who touched revisions under test:
  Jiri Denemark <jdenemar@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=6085d917d5c5839b7ed351e99fadbbb56f5178fe
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 6085d917d5c5839b7ed351e99fadbbb56f5178fe
+ branch=libvirt
+ revision=6085d917d5c5839b7ed351e99fadbbb56f5178fe
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 6085d917d5c5839b7ed351e99fadbbb56f5178fe:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   7296e89..6085d91  6085d917d5c5839b7ed351e99fadbbb56f5178fe -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 07:43:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 07:43:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xuz9I-0003EU-Tc; Sun, 30 Nov 2014 07:42: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@citrix.com>) id 1Xuz9G-0003EP-On
	for xen-devel@lists.xensource.com; Sun, 30 Nov 2014 07:42:26 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	2D/BC-28865-16ACA745; Sun, 30 Nov 2014 07:42:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417333343!14102563!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16443 invoked from network); 30 Nov 2014 07:42:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 07:42:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,486,1413244800"; d="scan'208";a="198116259"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 30 Nov 2014 02:42:21 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xuz9B-0003EO-Hi;
	Sun, 30 Nov 2014 07:42:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xuz9B-00013a-5z;
	Sun, 30 Nov 2014 07:42:21 +0000
Date: Sun, 30 Nov 2014 07:42:21 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31928-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 31928: 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 31928 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31928/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              6085d917d5c5839b7ed351e99fadbbb56f5178fe
baseline version:
 libvirt              7296e896c92c64ec5653095bcc2ed86b6a72a7d5

------------------------------------------------------------
People who touched revisions under test:
  Jiri Denemark <jdenemar@redhat.com>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=6085d917d5c5839b7ed351e99fadbbb56f5178fe
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 6085d917d5c5839b7ed351e99fadbbb56f5178fe
+ branch=libvirt
+ revision=6085d917d5c5839b7ed351e99fadbbb56f5178fe
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.libvirt
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.libvirt
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/libvirt
+ git push osstest@xenbits.xensource.com:/home/xen/git/libvirt.git 6085d917d5c5839b7ed351e99fadbbb56f5178fe:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   7296e89..6085d91  6085d917d5c5839b7ed351e99fadbbb56f5178fe -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 10:16:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 10:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xv1XV-0004XE-Rr; Sun, 30 Nov 2014 10:15: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@citrix.com>) id 1Xv1XU-0004X9-P1
	for xen-devel@lists.xensource.com; Sun, 30 Nov 2014 10:15:36 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	DD/4E-24124-74EEA745; Sun, 30 Nov 2014 10:15:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417342532!10714880!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21312 invoked from network); 30 Nov 2014 10:15:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 10:15:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,486,1413244800"; d="scan'208";a="198137740"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 30 Nov 2014 05:15:30 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xv1XO-0003yN-G9;
	Sun, 30 Nov 2014 10:15:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xv1XO-00079z-AX;
	Sun, 30 Nov 2014 10:15:30 +0000
Date: Sun, 30 Nov 2014 10:15:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31925-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31925: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31925 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31925/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl           11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                88910638717dd195cff1dd1ea74772b159632bba
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
695 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 30392 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 Nov 30 10:16:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 10:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xv1XV-0004XE-Rr; Sun, 30 Nov 2014 10:15: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@citrix.com>) id 1Xv1XU-0004X9-P1
	for xen-devel@lists.xensource.com; Sun, 30 Nov 2014 10:15:36 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	DD/4E-24124-74EEA745; Sun, 30 Nov 2014 10:15:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417342532!10714880!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21312 invoked from network); 30 Nov 2014 10:15:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 10:15:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,486,1413244800"; d="scan'208";a="198137740"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 30 Nov 2014 05:15:30 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xv1XO-0003yN-G9;
	Sun, 30 Nov 2014 10:15:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xv1XO-00079z-AX;
	Sun, 30 Nov 2014 10:15:30 +0000
Date: Sun, 30 Nov 2014 10:15:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31925-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 31925: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31925 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31925/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start           fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl           11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass

version targeted for testing:
 linux                88910638717dd195cff1dd1ea74772b159632bba
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
695 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-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-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 30392 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 Nov 30 13:21:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 13: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 1Xv4Qw-00066t-O0; Sun, 30 Nov 2014 13:21:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xv4Qu-00066o-SD
	for xen-devel@lists.xensource.com; Sun, 30 Nov 2014 13:21:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6C/93-25276-CB91B745; Sun, 30 Nov 2014 13:21:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417353658!12358957!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16988 invoked from network); 30 Nov 2014 13:20:59 -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;
	30 Nov 2014 13:20:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,487,1413244800"; d="scan'208";a="197841422"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 30 Nov 2014 08:20:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xv4Qp-0004t4-Vq;
	Sun, 30 Nov 2014 13:20:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xv4Qp-0005cR-Iw;
	Sun, 30 Nov 2014 13:20:55 +0000
Date: Sun, 30 Nov 2014 13:20:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31932-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31932: 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 31932 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31932/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31853

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  188336bb86d0992a2a034ece5f39eccc5d10f337
baseline version:
 xen                  104072fc1c7e6ed117c70fa7f91ecc9946f8f654

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Chunyan Liu <cyliu@suse.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  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>
  Julien Grall <julien.grall@linaro.org>
  Olaf Hering <olaf@aepfle.de>
  Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wei.liu2@citrix.com>
  Zhigang Wang <zhigang.x.wang@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=188336bb86d0992a2a034ece5f39eccc5d10f337
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 188336bb86d0992a2a034ece5f39eccc5d10f337
+ branch=xen-unstable
+ revision=188336bb86d0992a2a034ece5f39eccc5d10f337
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 188336bb86d0992a2a034ece5f39eccc5d10f337:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   104072f..188336b  188336bb86d0992a2a034ece5f39eccc5d10f337 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 13:21:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 13: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 1Xv4Qw-00066t-O0; Sun, 30 Nov 2014 13:21:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xv4Qu-00066o-SD
	for xen-devel@lists.xensource.com; Sun, 30 Nov 2014 13:21:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6C/93-25276-CB91B745; Sun, 30 Nov 2014 13:21:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417353658!12358957!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16988 invoked from network); 30 Nov 2014 13:20:59 -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;
	30 Nov 2014 13:20:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,487,1413244800"; d="scan'208";a="197841422"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
	14.3.181.6; Sun, 30 Nov 2014 08:20:56 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xv4Qp-0004t4-Vq;
	Sun, 30 Nov 2014 13:20:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xv4Qp-0005cR-Iw;
	Sun, 30 Nov 2014 13:20:55 +0000
Date: Sun, 30 Nov 2014 13:20:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31932-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 31932: 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 31932 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31932/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31853

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  188336bb86d0992a2a034ece5f39eccc5d10f337
baseline version:
 xen                  104072fc1c7e6ed117c70fa7f91ecc9946f8f654

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Chunyan Liu <cyliu@suse.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  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>
  Julien Grall <julien.grall@linaro.org>
  Olaf Hering <olaf@aepfle.de>
  Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wei.liu2@citrix.com>
  Zhigang Wang <zhigang.x.wang@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=188336bb86d0992a2a034ece5f39eccc5d10f337
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 188336bb86d0992a2a034ece5f39eccc5d10f337
+ branch=xen-unstable
+ revision=188336bb86d0992a2a034ece5f39eccc5d10f337
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"GitCacheProxy"} or die $!;
        '
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_MAINLINE=osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 188336bb86d0992a2a034ece5f39eccc5d10f337:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   104072f..188336b  188336bb86d0992a2a034ece5f39eccc5d10f337 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 14:52:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 14:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xv5r5-0007cL-OV; Sun, 30 Nov 2014 14:52:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xv5r3-0007bj-ND
	for xen-devel@lists.xensource.com; Sun, 30 Nov 2014 14:52:05 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	EA/D8-26740-41F2B745; Sun, 30 Nov 2014 14:52:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417359122!14769721!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31495 invoked from network); 30 Nov 2014 14:52:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 14:52:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,487,1413244800"; d="scan'208";a="198167329"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 30 Nov 2014 09:52:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xv5qy-0005K4-TA;
	Sun, 30 Nov 2014 14:52:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xv5qy-0000jX-Ls;
	Sun, 30 Nov 2014 14:52:00 +0000
Date: Sun, 30 Nov 2014 14:52:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31934-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31934 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31934/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31811
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 31811

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a
baseline version:
 xen                  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 e0921ec746410f0a07eb3767e95e5eda25d4934a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:15:27 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 5e687e7da367827344db3965b8a5f5f761a8431a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:14:15 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 14:52:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 14:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xv5r5-0007cL-OV; Sun, 30 Nov 2014 14:52:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xv5r3-0007bj-ND
	for xen-devel@lists.xensource.com; Sun, 30 Nov 2014 14:52:05 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	EA/D8-26740-41F2B745; Sun, 30 Nov 2014 14:52:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417359122!14769721!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31495 invoked from network); 30 Nov 2014 14:52:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 14:52:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,487,1413244800"; d="scan'208";a="198167329"
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id
	14.3.181.6; Sun, 30 Nov 2014 09:52:01 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xv5qy-0005K4-TA;
	Sun, 30 Nov 2014 14:52:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xv5qy-0000jX-Ls;
	Sun, 30 Nov 2014 14:52:00 +0000
Date: Sun, 30 Nov 2014 14:52:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31934-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.3-testing test] 31934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 31934 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31934/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31811
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 31811

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a
baseline version:
 xen                  62f1b78417f3a9afe8d40ee3c0d2f0495240cf47

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      fail    
 build-i386-rumpuserxen                                       fail    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 e0921ec746410f0a07eb3767e95e5eda25d4934a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:15:27 2014 +0100

    x86/HVM: confine internally handled MMIO to solitary regions
    
    While it is generally wrong to cross region boundaries when dealing
    with MMIO accesses of repeated string instructions (currently only
    MOVS) as that would do things a guest doesn't expect (leaving aside
    that none of these regions would normally be accessed with repeated
    string instructions in the first place), this is even more of a problem
    for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
    made dereference NULL "entry" pointers this way) as well as undersized
    (1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
    space beyond the one memory page set up for holding LAPIC register
    values).
    
    Since those functions validly assume to be called only with addresses
    their respective checking functions indicated to be okay, it is generic
    code that needs to be fixed to clip the repetition count.
    
    To be on the safe side (and consistent), also do the same for buffered
    I/O intercepts, even if their only client (stdvga) doesn't put the
    hypervisor at risk (i.e. "only" guest misbehavior would result).
    
    This is CVE-2014-8867 / XSA-112.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>

commit 5e687e7da367827344db3965b8a5f5f761a8431a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Nov 27 14:14:15 2014 +0100

    x86: limit checks in hypercall_xlat_continuation() to actual arguments
    
    HVM/PVH guests can otherwise trigger the final BUG_ON() in that
    function by entering 64-bit mode, setting the high halves of affected
    registers to non-zero values, leaving 64-bit mode, and issuing a
    hypercall that might get preempted and hence become subject to
    continuation argument translation (HYPERVISOR_memory_op being the only
    one possible for HVM, PVH also having the option of using
    HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
    switched to use compat_memory_op() - neither that nor
    hypercall_xlat_continuation() were originally intended to be used by
    other than PV guests (which can't enter 64-bit mode and hence have no
    way to alter the high halves of 64-bit registers).
    
    This is CVE-2014-8866 / XSA-111.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 21:55:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 21: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 1XvCSA-0002Gv-L9; Sun, 30 Nov 2014 21:54:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvCS9-0002Gq-Ns
	for xen-devel@lists.xen.org; Sun, 30 Nov 2014 21:54:49 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	A0/72-14727-8229B745; Sun, 30 Nov 2014 21:54:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417384486!14089141!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15237 invoked from network); 30 Nov 2014 21:54:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 21:54:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,488,1413244800"; d="scan'208";a="197904270"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Sun, 30 Nov 2014 16:54:45 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XvCS5-0008LZ-6h;
	Sun, 30 Nov 2014 21:54:45 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Sun, 30 Nov 2014 21:54:45 +0000
Message-ID: <1417384485-20874-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] xl: fix two memory leaks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are two invocations of libxl_basename, which returns a malloc'ed
string. Those strings should be freed after used.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9afef3f..716a865 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -920,6 +920,7 @@ static void parse_config_data(const char *config_source,
     int pci_permissive = 0;
     int pci_seize = 0;
     int i, e;
+    const char *basename;
 
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
@@ -1116,13 +1117,16 @@ static void parse_config_data(const char *config_source,
 
     switch(b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        if (!strcmp(libxl_basename(b_info->kernel), "hvmloader")) {
+        basename = libxl_basename(b_info->kernel);
+        if (!strcmp(basename, "hvmloader")) {
             fprintf(stderr, "WARNING: you seem to be using \"kernel\" "
                     "directive to override HVM guest firmware. Ignore "
                     "that. Use \"firmware_override\" instead if you "
                     "really want a non-default firmware\n");
             b_info->kernel = NULL;
         }
+        free((void*)basename);
+        basename = NULL;
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
@@ -7021,7 +7025,7 @@ int main_cpupoolcreate(int argc, char **argv)
     int config_len = 0;
     XLU_Config *config;
     const char *buf;
-    const char *name;
+    const char *name = NULL;
     uint32_t poolid;
     libxl_scheduler sched = 0;
     XLU_ConfigList *cpus;
@@ -7196,6 +7200,7 @@ out_cfg:
     xlu_cfg_destroy(config);
 out:
     free(config_data);
+    free((void*)name);
     return rc;
 }
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Nov 30 21:55:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Nov 2014 21: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 1XvCSA-0002Gv-L9; Sun, 30 Nov 2014 21:54:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvCS9-0002Gq-Ns
	for xen-devel@lists.xen.org; Sun, 30 Nov 2014 21:54:49 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	A0/72-14727-8229B745; Sun, 30 Nov 2014 21:54:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417384486!14089141!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15237 invoked from network); 30 Nov 2014 21:54:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 21:54:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,488,1413244800"; d="scan'208";a="197904270"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.181.6;
	Sun, 30 Nov 2014 16:54:45 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47]
	helo=dt47.uk.xensource.com.)	by ukmail1.uk.xensource.com with esmtp
	(Exim
	4.69)	(envelope-from <wei.liu2@citrix.com>)	id 1XvCS5-0008LZ-6h;
	Sun, 30 Nov 2014 21:54:45 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Sun, 30 Nov 2014 21:54:45 +0000
Message-ID: <1417384485-20874-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] xl: fix two memory leaks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are two invocations of libxl_basename, which returns a malloc'ed
string. Those strings should be freed after used.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9afef3f..716a865 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -920,6 +920,7 @@ static void parse_config_data(const char *config_source,
     int pci_permissive = 0;
     int pci_seize = 0;
     int i, e;
+    const char *basename;
 
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
@@ -1116,13 +1117,16 @@ static void parse_config_data(const char *config_source,
 
     switch(b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        if (!strcmp(libxl_basename(b_info->kernel), "hvmloader")) {
+        basename = libxl_basename(b_info->kernel);
+        if (!strcmp(basename, "hvmloader")) {
             fprintf(stderr, "WARNING: you seem to be using \"kernel\" "
                     "directive to override HVM guest firmware. Ignore "
                     "that. Use \"firmware_override\" instead if you "
                     "really want a non-default firmware\n");
             b_info->kernel = NULL;
         }
+        free((void*)basename);
+        basename = NULL;
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
@@ -7021,7 +7025,7 @@ int main_cpupoolcreate(int argc, char **argv)
     int config_len = 0;
     XLU_Config *config;
     const char *buf;
-    const char *name;
+    const char *name = NULL;
     uint32_t poolid;
     libxl_scheduler sched = 0;
     XLU_ConfigList *cpus;
@@ -7196,6 +7200,7 @@ out_cfg:
     xlu_cfg_destroy(config);
 out:
     free(config_data);
+    free((void*)name);
     return rc;
 }
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel